ISO/IEC 27001:2022, anexo A — vista de preparación de controles
Esta página se genera a partir de la tabla de requisitos que el motor de AiSSAY incluye para este marco. Cuando el motor produce un paquete de evidencias, cada fila de abajo recibe un estado calculado a partir de los propios registros del operador en ese momento. Esta página muestra la tabla, no los resultados de nadie.
Correspondencia informativa preparada con las propias herramientas del operador. No es un dictamen jurídico, ni una certificación, ni sustituye el asesoramiento de un abogado. Organiza los registros del operador en relación con los requisitos citados; determinar si esos registros cumplen los requisitos corresponde al operador, a su asesor jurídico y al examinador.
ISO 27001 certifica un sistema de gestión de la seguridad de la información, auditado por un organismo acreditado. Esta vista relaciona los mecanismos distribuidos con los temas del anexo A y señala claramente las carencias del SGSI.
La tabla de requisitos
12 filas: 6 de mecanismo, 4 organizativas, 1 carencia señalada, 1 calculada
| Requisito | Mecanismo, obligación o carencia | Tipo |
|---|---|---|
| A.5.1 — políticas de seguridad de la información | organizativo: el conjunto de documentos del SGSI | organizativo |
| A.5.19–5.22 — relaciones con los proveedores | organizativo: registro de subencargados (el diseño autoalojado mantiene el registro breve por construcción) | organizativo |
| A.6 — controles de personas (verificación de antecedentes, formación, acuerdos de confidencialidad) | organizativo | organizativo |
| A.8.15 — registro de eventos | registro de accesos encadenado por hashes con el actor, la acción y el motivo; cada lectura de cada registro queda en él | mecanismo |
| A.8.16 — actividades de seguimiento | verificación de la cadena, verificación del anclaje incluida la detección de sustitución de claves, sellado de las carencias de captura | mecanismo |
| A.8.24 — uso de la criptografía | AES-256-GCM en reposo, atestación y aprobaciones con Ed25519, cadenas SHA-256; las claves nunca salen de los equipos del operador | mecanismo |
| A.8.13 — copias de seguridad de la información | mecanismo de restauración a partir del testigo distribuido; la programación y las pruebas de las copias de seguridad son organizativas | organizativo |
| A.8.32 — gestión de cambios | sellos VERSION, conjuntos de pruebas de regresión fijados, registro firmado del perfil del instrumento | mecanismo |
| A.5.15/A.8.3 — control de acceso y restricción del acceso a la información | DELEGADO cuando el almacén está sellado por su gestor de claves (el proveedor kms): quien sea rechazado por su gestor de claves no podrá abrir el almacén en absoluto, y cada apertura aparece en el propio registro de auditoría de su gestor de claves. El almacén en sí no tiene autenticación, roles ni permisos y no rechaza ninguna lectura: una vez que se desenvuelve una clave, el proceso que la tiene puede leer todos los registros. Con cualquier otro proveedor, NO IMPLEMENTADO: los permisos de archivos del sistema operativo son el único control de acceso. El estado se calcula a partir del proveedor que declara este almacén, no se da por supuesto. | calculado |
| A.8.24 — uso de la criptografía, incluido el ciclo de vida de las claves | ceremonia de cambio de clave: se sella una clave sucesora a través del mismo proveedor, todos los registros pasan a estar bajo ella, cada uno declarando su clave, y la clave antigua solo se destruye después de que cada registro se haya vuelto a leer con la nueva; las concesiones y las participaciones de custodia de la clave retirada ya no abren nada. La rotación de la propia clave de envoltura del gestor de claves corresponde al gestor de claves. LÍMITE: quien tenga a la vez la clave antigua y una copia antigua del texto cifrado todavía puede leer esa copia. | mecanismo |
| A.8.8 (identificación) — vulnerabilidades conocidas en las dependencias de Python | cada paquete de Python resuelto a partir de requirements.txt y del archivo opcional requirements-aws.txt se compara, cada archivo en su propio bloque, con una base de datos pública de avisos de seguridad EN EL MOMENTO DE LA PUBLICACIÓN, y el informe se distribuye con su hash (depscan.py, DEPSCAN.json). No puede ejecutarse en su equipo, porque la base de datos de avisos está en la red. No abarca los paquetes del sistema operativo ni el intérprete, y no es continuo. | mecanismo |
| A.8.8/A.8.29 — corrección, seguimiento y pruebas de seguridad | IMPLEMENTADO EN PARTE, y las partes están identificadas. Presente: un análisis de dependencias en el momento de la publicación, con una comprobación de antigüedad que impide que un análisis desactualizado pase por actual; un verificador estático sobre este árbol para un conjunto breve y enumerado de clases de defectos, probado en cada versión con un archivo que contiene uno de cada tipo introducido a propósito; y fuzzing por mutación de los analizadores que leen entradas que no escribimos nosotros, probado con un analizador roto a propósito. Ausente: pruebas de penetración, análisis de los paquetes del sistema operativo, seguimiento continuo entre versiones y revisión por terceros del diseño criptográfico. Decidir qué hacer ante un hallazgo es un procedimiento, y el procedimiento corresponde al operador. | carencia señalada |
Cómo se obtiene un estado
- Acreditado
- se ejecutó una comprobación determinista sobre sus registros y los recuentos respaldan la fila. Un almacén que no contiene registros pertinentes figura como no acreditado: una afirmación verdadera, no un aprobado. Vacío nunca cuenta como limpio.
- Delegado
- el mecanismo lo hace cumplir un sistema en el que usted ya confía: un almacén sellado por su propio gestor de claves le delega a este el control de acceso, y el paquete indica que el registro que lo hace cumplir es el de su gestor de claves, no el nuestro. El paquete nombra el endpoint en el que se contactó con el gestor de claves. Un endpoint de AWS distinto del predeterminado de AWS para la región figura como delegado a ese endpoint, con una solicitud para que usted confirme que es su servicio de gestión de claves. Un backend —AWS KMS— se ha ejecutado contra el servicio real de AWS KMS; ningún otro backend lo ha hecho.
- Punto de integración de prueba
- sellado por un backend de prueba dentro del proceso —un stub, o un sustituto del cliente de AWS— y el estado indica cuál. Ningún gestor de claves controla el acceso. El punto de integración está construido y probado, y el paquete se niega a llamar a eso delegación.
- Parcialmente acreditado
- el mecanismo está construido y algunas de sus ejecuciones llevan su evidencia, pero no todas, normalmente porque se sellaron antes de que existiera el mecanismo. El paquete indica cuántas ejecuciones hay en cada grupo y nunca cuenta como aprobadas las que faltan.
- Organizativo
- el requisito es un procedimiento que solo pueden llevar a cabo personas. El paquete lo señala como responsabilidad suya en lugar de disfrazar una política de mecanismo.
- Carencia señalada
- el paquete no puede acreditarlo —o bien el mecanismo no está construido, o bien ningún software puede aportarlo— y dice cuál de los dos casos es. La carencia se imprime, porque un revisor debería leerla aquí y no descubrirla después.
Ningún estado se introduce a mano: cada estado se recalcula a partir del almacén cada vez que se produce un paquete, el texto de los requisitos y de los mecanismos se redacta y revisa como parte del motor, y la evidencia sobre dependencias procede de nuestro análisis de cada versión. Un mecanismo que falla nunca puede interpretarse como evidencia de que el control funciona.
Las filas marcadas como “calculado” son las de control de acceso. Su estado se calcula a partir del proveedor que declara su almacén: una carencia salvo que su gestor de claves selle el almacén, “punto de integración de prueba” con un backend stub o sustituto, y “delegado” solo con uno real. Hoy nunca pueden figurar como acreditadas, y marcarlas como un mecanismo construido las exageraría.