SekitCrosswalk
ISO/IEC 27001:2022 · destino de mapeo derivado

A.5.17Authentication information

Manage passwords, keys and other authentication secrets securely, and guide users in choosing and protecting them. Strong, well-handled credentials are a first line of defense.

Mapeado desde el Sekit CSF

Los controles de Sekit que cubren este requisito, lente a lente.

RCF-0064Strong authentication (MFA) · PolíticaapoyaExigir un segundo factor de autenticación es un control sobre cómo se verifica la autenticación misma, una de las salvaguardas concretas que A.5.17 pide poner alrededor de las credenciales.RCF-0065Strong authentication (MFA) · ProcesoapoyaRastrear la inscripción a MFA para que ninguna cuenta se escape sin inscribir convierte el requisito de MFA en algo que protege cada credencial, no solo las que alguien recordó configurar.RCF-0076Password policy · PolíticaapoyaDocumentar la longitud mínima, la no reutilización, el uso obligatorio del gestor de contraseñas y el manejo de credenciales compartidas respalda el requisito de información de autenticación de A.5.17, aunque la emisión de credenciales y los secretos no humanos los cubren otros controles.RCF-0077Password policy · ProcesoapoyaLograr que todo empleado use el gestor de contraseñas es lo que hace reales las reglas escritas de contraseñas, en lugar de reglas que la gente elude reutilizando contraseñas.RCF-0078Password policy · TécnicaapoyaRechazar contraseñas débiles o cortas en la configuración del sistema aplica técnicamente las reglas de credenciales de A.5.17, cerrando la brecha entre lo que dice la política y lo que el sistema permite.RCF-0079Session management · PolíticarelacionadoLos tiempos de espera de sesión inactiva protegen una sesión ya autenticada y no la credencial en sí, una salvaguarda relacionada que se ubica junto a los controles de información de autenticación de A.5.17.RCF-0112Secrets management · PolíticaapoyaExigir que toda contraseña, clave de API y credencial viva en una bóveda aprobada respalda el requisito de información de autenticación de A.5.17 al cubrir los secretos de máquina, pero no orienta a los usuarios sobre elegir y proteger sus credenciales.RCF-0113Secrets management · ProcesoapoyaEmitir, rotar y revocar credenciales mediante una rutina gestionada, con las personas que se van perdiendo el acceso el mismo día, mantiene vigente el requisito de manejo de credenciales de A.5.17 en lugar de fijarlo una sola vez.RCF-0114Secrets management · TécnicaapoyaDesplegar una bóveda con acceso por persona y sin credenciales incrustadas en código es el control técnico que hace exigible, y no solo escrita, la regla de manejo de secretos de A.5.17.

Correspondencias en NIST CSF 2.0

Alcanzadas a través de los controles del Sekit CSF que ambos mapean: un mapeo, no una equivalencia formal.

Correspondencias en Cyber Essentials

Evidencia que demuestra este control

Lo que pide un auditor, o el motor de evidencias de Sekit.

Evidencia de doble factor (MFA) activado
La prueba de que se exige un segundo factor de verificación (más allá de la contraseña) para acceder a los sistemas importantes.
Política de contraseñas y gestor
Las reglas de contraseñas de la empresa (longitud, complejidad, caducidad) y si se usa un gestor de contraseñas, más cómo se aplican técnicamente.
Del catálogo de evidencias de Sekit

En la práctica

En la práctica este control se reduce a dos cosas que funcionan juntas: un gestor de contraseñas corporativo que todos usan, y MFA exigido en todo sistema que importa y no solo en los que un proveedor dejó seguros por defecto. Los auditores piden la política de contraseñas y la evidencia del gestor y verifican al azar algunas cuentas para ver si el proveedor de identidad rechaza una contraseña débil, no solo si el documento de política dice que debería. El fallo recurrente son credenciales que viven fuera de la bóveda: claves de API pegadas en un canal de chat, o una contraseña compartida para un sistema heredado anotada porque nadie la migró.

Brechas habituales

La política de contraseñas exige un gestor para todos, pero la adopción es inconsistente y varios empleados aún guardan contraseñas en una hoja de cálculo o en el autocompletado del navegador.
Las claves de API y credenciales de servicio de un sistema heredado están codificadas en un script en lugar de guardarse en la bóveda aprobada, pese a que la política de secretos lo prohíbe.
MFA se exige en el correo y el proveedor de identidad, pero no en un puñado de sistemas más antiguos anteriores a la implementación.

Preguntas que hará tu auditor

¿Dónde guardan los empleados sus contraseñas?
Señala el gestor de contraseñas corporativo y confirma la adopción del personal con registros de uso, no solo con el mandato en la política de contraseñas.
¿Se exige autenticación multifactor para todas las cuentas con acceso a sistemas sensibles?
Muestra la evidencia de inscripción a MFA que cubre la plataforma de identidad, el correo y todo sistema con datos de negocio importantes, y nombra cualquier excepción documentada y con plazo definido.
¿Cómo se protegen las claves de API y otras credenciales no humanas?
Describe la bóveda de secretos usada para claves de API y credenciales de servicio, con control de acceso por persona y ninguna credencial incrustada en código o scripts.

Dónde lo exige la regulación

NIS2 art. 11.6 (autenticación) y art. 11.7 (autenticación multifactor) exigen las mismas salvaguardas de credenciales y MFA que A.5.17 pide aplicar.
ENS op.acc.5 (Mecanismo de autenticación, usuarios externos) fija la línea base equivalente para los mecanismos de autenticación.

Controles relacionados

Vía el tema compartido del Sekit CSF, no el índice del propio marco.

Pregúntale a Sekura: «¿Qué evidencia demuestra A.5.17?»
También vía MCP, gratis con cuenta