ISO/IEC 27001:2022 · destino de mapeo derivado
A.5.15Access control
Set and enforce rules for who can access which information and systems, based on business and security needs. Granting only the access people actually require limits the damage from any single account.
El mapeo de un vistazo
A.5.15Access controlISO/IEC 27001:2022
RCF-0006Roles & responsibilitiesGovernance & Risk · TécnicaRCF-0061Identity lifecycleIdentity & Access Management · PolíticaRCF-0064Strong authentication (MFA)Identity & Access Management · PolíticaRCF-0067Least privilege / RBACIdentity & Access Management · PolíticaRCF-0069Least privilege / RBACIdentity & Access Management · Técnica
A.5.15 queda cubierto por 16 controles del Sekit CSF. +11 más en la tabla de abajo. Abrir en el grafo completo →
Mapeado desde el Sekit CSF
Los controles de Sekit que cubren este requisito, lente a lente.
RCF-0006Roles & responsibilities · TécnicaapoyaConfigurar los sistemas para que cada responsabilidad definida solo pueda ejercerla la persona asignada es control de acceso aplicado a roles de gobernanza, respaldando el requisito de A.5.15 de que el acceso responda a una necesidad genuina.RCF-0061Identity lifecycle · PolíticahabilitaUn ciclo de vida de identidad documentado le da al control de acceso algo estable sobre lo que actuar: sin una regla clara sobre cómo se crean y modifican las cuentas, las decisiones de acceso de A.5.15 no tienen dónde apoyarse de forma confiable.RCF-0064Strong authentication (MFA) · PolíticaapoyaExigir un segundo factor en el correo, la plataforma de identidad y los sistemas con datos importantes es una regla concreta de control de acceso que A.5.15 pide aplicar según la necesidad de negocio.RCF-0067Least privilege / RBAC · PolíticaapoyaEl control de Mínimo privilegio / RBAC de Sekit define el acceso de cada rol y lo hace la asignación por defecto, la mitad de política del requisito de A.5.15; la aplicación a nivel de plataforma que la completa se mapea aparte.RCF-0069Least privilege / RBAC · TécnicaapoyaHacer cumplir los permisos a nivel de plataforma, sin inicios de sesión compartidos que sustituyan el control de acceso real, es lo que hace que las reglas basadas en roles de A.5.15 se sostengan en la práctica.RCF-0070Privileged access management · PolíticaapoyaMantener los privilegios administrativos en cuentas separadas, aprobadas y registradas es el principio de mínimo privilegio de A.5.15 aplicado específicamente a las cuentas capaces del mayor daño.RCF-0073SSO & federation · PolíticahabilitaEnrutar el inicio de sesión a través de un proveedor de identidad central le da a las reglas de acceso de A.5.15 un solo lugar donde aplicarse de forma consistente, en lugar de estar dispersas en el sistema de inicio de sesión de cada aplicación.RCF-0074SSO & federation · ProcesohabilitaConectar cada nueva aplicación al proveedor de identidad antes de que el personal empiece a usarla hace que el control de acceso aplique desde el primer día en lugar de agregarse después.RCF-0075SSO & federation · TécnicahabilitaAutenticar las aplicaciones críticas mediante el proveedor de identidad central en lugar de cuentas locales es la base técnica que hace exigibles las reglas de acceso de A.5.15 en todo el entorno.RCF-0079Session management · PolíticaapoyaFijar un tiempo máximo de inactividad antes de bloquear la sesión es una regla concreta de control de acceso sobre quién puede actuar en una sesión ya autenticada, no solo quién puede iniciarla.RCF-0082Remote access · PolíticaapoyaDefinir los métodos de conexión y dispositivos permitidos para el trabajo remoto extiende el principio de control de acceso de A.5.15 al caso en que la persona no está en la red de la oficina.RCF-0085Access reviews (recertification) · PolíticaapoyaComprometerse a una revisión periódica de acceso es lo que mantiene vigente con el tiempo el principio de acceso por necesidad de A.5.15, en lugar de revisarlo solo el día en que se crea una cuenta.RCF-0138API security · TécnicaapoyaExigir autenticación, autorización por endpoint y límites de tasa en las API es el principio de control de acceso de A.5.15 aplicado al acceso máquina a máquina, no solo a los inicios de sesión humanos.RCF-0184Zero Trust network access · PolíticaapoyaOtorgar el acceso en cada solicitud según identidad verificada y estado del dispositivo, en lugar de la ubicación de red, es una forma más estricta y explícita del control de acceso que exige A.5.15.RCF-0185Zero Trust network access · ProcesoapoyaVerificar la identidad y la postura del dispositivo en cada concesión de acceso, y revisar las reglas condicionales periódicamente, mantiene actualizadas las decisiones de acceso de A.5.15 en lugar de una revisión única.RCF-0334Cloud IAM · PolíticaapoyaGobernar los roles en la nube, restringir el acceso de administrador y revisar los derechos según un calendario extiende el requisito de control de acceso de A.5.15 específicamente a las plataformas en la nube.
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.
Del catálogo de evidencias de Sekit
En la práctica
El control de acceso en la práctica significa permisos basados en roles en el proveedor de identidad, MFA exigido en todo lo que importa, y ningún inicio de sesión compartido sustituyendo cuentas individuales. Los auditores toman la evidencia de inscripción a MFA y la contrastan con el listado completo de usuarios buscando vacíos: contratistas, cuentas de servicio o algunos empleados de larga data excluidos de la inscripción hace años y nunca retomados. El hallazgo más común es acceso otorgado copiando los permisos de otro compañero en lugar de partir de una definición de rol documentada, una práctica que acumula privilegios en silencio y que nadie logra explicar meses después.
Brechas habituales
Un puñado de cuentas de larga data nunca se inscribió en MFA cuando se implementó el requisito, y nadie ha vuelto a cerrar esa brecha.
El acceso de los nuevos empleados se copia de un colega en lugar de partir de una definición de rol documentada, así que nadie puede explicar por qué cada persona tiene lo que tiene.
Aún se usan inicios de sesión compartidos o genéricos para un sistema heredado porque migrarlo a cuentas individuales se postergó.
Preguntas que hará tu auditor
¿Cómo decides qué acceso debería tener cada persona?
Señala las definiciones de rol que indican el acceso que necesita cada rol, otorgado a partir de esa definición y no copiando los permisos de otro compañero.
¿Se exige autenticación multifactor en todos los lugares donde debería?
Muestra la evidencia de inscripción a MFA que cubre correo, la plataforma de identidad, el acceso remoto y todo sistema con datos de negocio importantes, incluyendo las brechas de cobertura conocidas y el plan para cerrarlas.
¿Cómo se maneja el acceso administrativo de forma distinta al acceso regular?
Describe las cuentas administrativas separadas y aprobadas, registradas en un inventario actualizado, distintas del inicio de sesión diario de cada persona.
¿Qué impide que el acceso se acumule a medida que las personas cambian de rol con el tiempo?
Remite a la revisión periódica de acceso que contrasta el acceso actual con las funciones actuales y elimina lo que un cambio de rol volvió innecesario.
Dónde lo exige la regulación
NIS2 art. 11.1 (política de control de acceso) exige el mismo enfoque de acceso por necesidad que A.5.15 pide aplicar.
ENS op.acc.2 (Requisitos de acceso) fija la expectativa equivalente de requisitos de acceso definidos y ligados a la necesidad de negocio.
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.15?»
También vía MCP, gratis con cuenta