Proveedores con acceso privilegiado y su control

Un administrador empleado pasa por alta, cambios y baja con recursos humanos, firma una política de uso y trabaja en equipos que la empresa gestiona. Un administrador de un proveedor no hace nada de eso: su alta la pide un jefe de área, su baja depende de que el proveedor avise, y su equipo es el de otra empresa.

Por eso los controles sobre el acceso privilegiado de terceros se concentran en lo que la aerolínea sí puede controlar: que el privilegio exista solo cuando hay trabajo (justo a tiempo), que haya segunda capa de verificación, que cada sesión tenga un ticket que la justifique y que quede grabada para revisarla.

Un privilegio permanente significa que la cuenta administra el sistema las 24 horas del día, trabaje o no el proveedor. Si alguien roba sus credenciales a las tres de la madrugada de un domingo, el robo encuentra la puerta abierta. Con privilegio justo a tiempo, la cuenta existe pero sin derechos hasta que se abre una sesión aprobada, y los pierde al cerrarla.

Abre cuentas-privilegiadas.txt y mira el tipo de privilegio de cada cuenta. La política es justo a tiempo; hay una que no la cumple.

El ticket liga cada sesión con un cambio aprobado: qué se iba a hacer, quién lo pidió y quién lo autorizó. Una sesión sin ticket es trabajo de un tercero sobre un sistema crítico sin una razón que alguien haya escrito: no se puede revisar si lo hecho fue lo pedido, y es la sesión que más cuesta explicar en una auditoría.

Cuenta en sesiones.txt las filas cuya columna «ticket» dice sin-ticket.

El acuerdo con cada proveedor fija una ventana: las horas del día en que puede trabajar sobre un sistema, normalmente las de menor tráfico de la aerolínea. Una sesión es válida si cae entera dentro; si empieza antes o termina después, se salió. Una sesión en pleno día sobre el sistema de reservas es una anomalía incluso con ticket: o la ventana cambió y nadie lo anotó, o alguien usó la cuenta sin aviso.

Compara, para cada proveedor, las horas de sesiones.txt con las de ventanas.txt (cada proveedor tiene su ventana propia).

La grabación es la única forma de saber qué se hizo en la sesión, no solo que ocurrió. Si no hay grabación, la revisión posterior es una confianza en la palabra del proveedor. Un fallo de grabación aislado puede ser técnico; que se repita en el mismo proveedor suele indicar otro problema: un camino de acceso que no pasa por la herramienta de sesiones.

Cuenta en sesiones.txt las sesiones con grabada no de cada proveedor y compara.