Gobierno de la plataforma, quién puede qué y qué queda registrado

Las integraciones, el escáner que importa, el pipeline que sube resultados, el tablero que lee, necesitan credenciales. Atarlas a la cuenta personal de alguien causa dos problemas: cuando esa persona cambia de puesto la integración se rompe, y un permiso personal suele ser más amplio que lo que el trabajo exige.

La práctica sensata es una cuenta de servicio por integración, con un dueño responsable y solo el permiso mínimo que esa integración necesita. Así, si algo se comporta mal, se sabe de quién es y qué podía hacer.

Abre integraciones.csv. Cada fila compara el permiso que tiene la integración con el que necesita. Cuando coinciden no hay nada que hacer. Una integración con un permiso mayor del necesario es un riesgo gratuito: si su credencial se filtra, quien la use podrá hacer más de lo que el trabajo exigía.

La política exige MFA a los administradores de plataforma, porque son las cuentas cuyo robo causaría más daño. En usuarios.csv hay una persona con ese rol que no lo tiene activado. Fíjate en que otra cuenta también sin MFA existe, pero con un rol de menor alcance: no es ella la que se busca.

Las cuentas sin uso son puertas abiertas que nadie vigila. La política dice que una cuenta sin acceso en más de 90 días se desactiva y se revisa con su jefe. Desactivar no es borrar: la cuenta deja de funcionar, pero su historial y sus acciones previas siguen en el registro de auditoría.

Hoy es 2026-10-07. Una cuenta con último acceso el 2026-07-20 tiene 79 días y no entra en la cuenta; mira las demás con cuidado.

Abre registro-auditoria.txt. Un buen registro responde quién hizo qué, cuándo y con qué justificación. La política exige un motivo escrito para cerrar hallazgos como falsos positivos, porque es la vía más fácil para hacer desaparecer trabajo pendiente sin que nadie lo note. Una de las dos personas que cerró hallazgos ese día no dejó ninguno, y el número cerrado fue mucho mayor.