Decidir quién puede llegar a qué sistemas y datos

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.

• AWS · StandardOS lee si la cuenta raíz aún tiene una clave de acceso, una credencial que no se puede acotar y es difícil de atribuir a una persona.
• AWS · StandardOS lee si la cuenta raíz se usó en los últimos treinta días, y si IAM Access Analyzer vigila la región en busca de recursos compartidos fuera de la cuenta.
• Google Cloud · StandardOS lee si los buckets deciden el acceso a nivel de bucket solo por IAM, y si alguna persona tiene el rol básico Owner o Editor.
• Microsoft Entra ID · StandardOS lee si los invitados tienen el rol restringido o los mismos derechos de directorio que los miembros.

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.15. 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.18, A.8.2

Dónde encaja esto en NIS2

A.5.15 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.