Conceder, revisar y retirar permisos

Cómo lo verifica StandardOS

Conectado en solo lectura, según un calendario. Una comprobación superada mantiene fresca una entrada de evidencia; una fallida la deja caducar, para que una regresión salga a la luz en lugar de esperar a la auditoría. Cada integración, y qué puede ver cada credencial.

• Personio · StandardOS lee quién se ha ido según el sistema de RR. HH. mientras conserva una fila activa en el registro de empleados, que es la brecha de la baja en el momento en que se abre.
• Microsoft Entra ID · StandardOS lee cuántas cuentas tienen el rol de administrador global, y si los invitados están identificados.
• Google Workspace · StandardOS lee quién es superadministrador, y si esas personas usan la verificación en dos pasos.
• Okta · StandardOS lee cuentas atascadas a medias en la incorporación, y cuentas suspendidas y olvidadas.
• AWS · StandardOS lee las credenciales sin uso durante noventa días, que son los derechos de acceso que nadie revisa.
• Google Cloud · StandardOS lee qué vinculaciones de usuarios o grupos conceden Owner o Editor en un proyecto.
• Microsoft Entra ID · StandardOS lee las cuentas habilitadas que nadie ha usado en noventa días.
• Okta · StandardOS lee las cuentas activas que nadie ha usado en noventa días, y cuántas cuentas tienen un rol de administrador de cualquier tipo.
• Google Workspace · StandardOS lee las cuentas activas que nadie ha usado en noventa días, y cuántas cuentas tienen un rol de superadministrador o administrador delegado.
• Personio · StandardOS lee qué bajas se fueron sin fecha registrada, quién sigue activo con el contrato vencido, y quién no tiene supervisor que apruebe a qué puede acceder.

Riesgos que trata este control

Del registro de riesgos inicial que StandardOS propone en la configuración. Usted conserva, edita o elimina cada uno; estos son los que citan A.5.18 como tratamiento.

• Un empleado que se va conserva el accesoCuentas

Lo que pone en su calendario

Un control no se implementa una sola vez. Estas tareas se programan desde el día en que se configura, con un responsable y una fecha límite, para que la evidencia exista antes de que alguien la pida.

• Revisión de accesos de usuariocada trimestre

Qué preguntan los clientes sobre este control

Los cuestionarios de seguridad no usan números de control. Estas son las preguntas, tal como las plantean los clientes, que desembocan en A.5.18. Cada una se responde a partir de los mismos cuatro registros: el estado en la DdA, la política aprobada, evidencia fechada y una comprobación en vivo. El mapa completo de los treinta temas.

• ¿Cómo se concede, revisa y revoca el acceso de usuario cuando alguien se va?

  Control de acceso, mínimo privilegio, altas y bajas, acceso de administrador · también A.5.15, A.8.2

Dónde encaja esto en NIS2

A.5.18 es parte de lo que exige el artículo 21, apartado 2, letra j), Access control. Implementarlo una vez cuenta para ambos, y esa es toda la razón de que exista la correspondencia con NIS2.