Marcos de cumplimiento
Traducir CIS, NIST CSF 2.0, ISO 27001, SOC 2 y PCI DSS a controles técnicos concretos en AWS.
La primera vez que oyes «tenemos que cumplir SOC 2 y PCI» da vértigo: cientos de páginas, abogados, auditores. Pero como ingeniero de seguridad tu trabajo no es ser auditor. Es mucho más concreto: traducir cada requisito a un control técnico en AWS y dejar que ese control produzca la evidencia que el auditor pedirá. Los marcos son el «qué» y el «por qué»; tú aportas el «cómo» en la nube. Esta nota es ese diccionario de traducción.
El patrón: requisito → control → evidencia#
Casi todo el cumplimiento encaja en una misma cadena. Un marco exige un requisito («cifra los datos en reposo»). Tú lo implementas con un control técnico de AWS (KMS cifrando el bucket). Y ese control emite evidencia (una regla de AWS Config que confirma que no hay buckets sin cifrar), que demuestra que cumples. Lo mejor: un mismo control suele satisfacer requisitos de varios marcos a la vez.
Paso 1 de 5La cadena
No necesitas ser auditor: necesitas traducir cada requisito a un control técnico. La cadena es requisito → control de AWS → evidencia → marco que se satisface.
Mapea una vez, demuestra en todos. Por eso conviene mantener una tabla viva de requisito → control, que también alimenta la postura y el cumplimiento que operas con Security Hub y Config.
Los marcos que te vas a encontrar#
No todos son iguales: unos son guías técnicas, otros son certificaciones de proceso, otros son obligaciones contractuales. Saber de qué tipo es cada uno te dice qué espera de ti.
El CIS AWS Foundations BenchmarkCIS BenchmarkGuías de configuración segura, consensuadas por la comunidad, con recomendaciones concretas y niveles de perfil para sistemas, servicios y nubes. es el más cercano a tu teclado: una lista prescriptiva de configuraciones seguras para una cuenta de AWS (MFA en root, CloudTrail activo en todas las regiones, sin security groups con 0.0.0.0/0 en SSH, cifrado por defecto…). Cada recomendación dice cómo auditarla y cómo remediarla.
Es el mejor punto de partida porque es directamente comprobable: Security Hub trae el estándar CIS AWS Foundations y te da una puntuación automática. No es una certificación; es higiene de configuración.
El NIST Cybersecurity FrameworkNIST Cybersecurity FrameworkMarco voluntario del NIST que organiza la gestión de riesgo de ciberseguridad en seis funciones; la versión 2.0 añadió Govern. es un marco voluntario que organiza la gestión de riesgo en seis funciones. La versión 2.0 (febrero de 2024) añadió Govern al centro:
| Función | Qué cubre | Ejemplo de control AWS |
|---|---|---|
| Govern | Políticas, roles, gestión de riesgo | SCP/RCP de la org, panel de Security Hub |
| Identify | Conocer activos y riesgos | AWS Config inventory, Resource Explorer |
| Protect | Salvaguardas | IAM mínimo privilegio, KMS, WAF, Security Groups |
| Detect | Detección de eventos | GuardDuty, CloudTrail, Config rules |
| Respond | Respuesta a incidentes | EventBridge + Lambda, playbooks, aislamiento |
| Recover | Recuperación | Backups, versionado S3, DR multi-AZ/multi-región |
No es certificable: es un lenguaje común para describir tu postura y hablar con dirección.
ISO/IEC 27001ISO/IEC 27001Norma internacional certificable para un Sistema de Gestión de Seguridad de la Información (SGSI); versión vigente 27001:2022. es una norma certificable de un Sistema de Gestión de Seguridad de la Información (SGSI). No te dice «usa KMS»: te exige un proceso de gestión del riesgo (identificar, evaluar, tratar, mejorar) y elegir controles de su Anexo A (93 controles en la versión 2022) justificados por tu análisis de riesgo.
Para ti, se traduce en demostrar que tus decisiones técnicas nacen de un riesgo documentado: por qué ciertos datos van cifrados con claves gestionadas, por qué hay segregación de cuentas, por qué los accesos se revisan.
SOC 2 es un informe de atestación (lo emite un auditor, típicamente un CPA) contra los Trust Services Criteria de la AICPA: Seguridad (obligatorio), Disponibilidad, Integridad del procesamiento, Confidencialidad y Privacidad. Es el que tus clientes B2B te pedirán antes de firmar.
Hay dos tipos: Type I evalúa el diseño de los controles en un momento dado; Type II evalúa que esos controles funcionaron de forma efectiva durante un periodo (normalmente 6–12 meses). Por eso SOC 2 vive de la evidencia continua: necesitas demostrar que el control operó todo el tiempo, no solo el día de la foto.
PCI DSS (v4.x, la revisión vigente es la 4.0.1) es un estándar contractual de las marcas de pago: aplica si almacenas, procesas o transmites datos de tarjetas. Es muy prescriptivo (segmentación de red, cifrado, control de acceso, registro, pruebas periódicas) y su alcance se reduce drásticamente si minimizas dónde viven los datos de tarjeta (por ejemplo, delegando el pago en un proveedor tokenizado y no tocando nunca el PAN).
La tabla de traducción#
Este es el corazón del trabajo. Algunos requisitos típicos y el control de AWS que los cubre:
| Requisito (lo que exige el marco) | Control técnico en AWS | Marcos que lo piden |
|---|---|---|
| Cifrar datos en reposo | KMS en S3/RDS/EBS; Config rule que detecta lo no cifrado | CIS, ISO, SOC 2, PCI |
| Cifrar datos en tránsito | TLS forzado (política S3 aws:SecureTransport), ACM |
ISO, SOC 2, PCI |
| Registrar quién accede a qué | CloudTrail organizacional → cuenta log-archive | CIS, NIST, ISO, SOC 2, PCI |
| Mínimo privilegio y revisión de acceso | IAM Identity Center, Access Analyzer, revisión periódica | ISO, SOC 2, PCI |
| MFA en cuentas privilegiadas | MFA obligatorio; SCP que exige MFA; sin usuario root diario | CIS, ISO, PCI |
| Detectar configuración no conforme | AWS Config + conformance pack; Security Hub | CIS, NIST, SOC 2 |
| Segmentar la red | VPC, subredes privadas/aisladas, Security Groups, NACL | NIST, PCI |
| Detección de amenazas | GuardDuty, Security Hub, alertas por EventBridge | NIST, SOC 2 |
| Retención y no repudio de logs | S3 Object Lock en log-archive, CloudTrail validación de logs | ISO, SOC 2, PCI |
Un ejemplo concreto en Citas#
El requisito PCI/SOC 2 «los datos sensibles deben estar cifrados y el acceso registrado» se traduce en Citas a controles muy tangibles. Fuerza TLS en el bucket de adjuntos para no aceptar tráfico sin cifrar:
Bucket sin forzar cifrado en tránsito
Deniega cualquier petición no-TLS
{ "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::citas-adjuntos/*" } ]}{ "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": ["arn:aws:s3:::citas-adjuntos", "arn:aws:s3:::citas-adjuntos/*"], "Condition": { "Bool": { "aws:SecureTransport": "false" } } } ]}Y una regla de AWS Config vigila que no se cuele nada sin cifrar, generando la evidencia continua que SOC 2 Type II necesita:
aws configservice put-config-rule --config-rule '{ "ConfigRuleName": "s3-bucket-server-side-encryption-enabled", "Source": { "Owner": "AWS", "SourceIdentifier": "S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED" }}'Trampas habituales#
Tu turno
Traduce tres requisitos de tu entorno
Elige un marco que te afecte (o te podría afectar) y toma tres requisitos concretos. Para cada uno, rellena la cadena:
| Requisito | Control técnico (AWS u otro) | Evidencia que lo demuestra | ¿Es continua? |
|---|---|---|---|
Marca con honestidad la última columna. Las filas donde la evidencia no es continua son tu lista de trabajo pendiente.
Reto
¿Por qué NIST CSF no se «certifica» pero ISO 27001 sí?
▸Mostrar solución
Porque son cosas distintas. El NIST CSF es un marco descriptivo y voluntario: te da un vocabulario de resultados para entender y comunicar tu riesgo, sin un organismo que emita un sello. ISO 27001 define los requisitos de un sistema de gestión auditable, y un organismo acreditado puede certificar que lo cumples. Uno te ayuda a pensar; el otro te da un papel que enseñar.
Reto
Tienes un informe SOC 2 Type I. ¿Qué te falta para el Type II y por qué importa?
▸Mostrar solución
El Type I solo dice que tus controles estaban bien diseñados en una fecha. El Type II exige demostrar que operaron de forma efectiva durante un periodo (6–12 meses). Lo que te falta es evidencia continua de ese periodo: logs, resultados de reglas de Config, registros de revisiones de acceso. Es la diferencia entre «monté la cerradura» y «la cerradura estuvo echada todo el año».
En resumen#
- Tu trabajo no es ser auditor: es traducir requisitos a controles de AWS que emitan evidencia.
- La cadena universal es requisito → control → evidencia, y un control suele cubrir varios marcos.
- CIS es higiene de configuración comprobable; NIST CSF 2.0 es un lenguaje de riesgo en seis funciones; ISO 27001 certifica un proceso de gestión; SOC 2 atestigua controles (Type I diseño, Type II operación); PCI DSS es contractual para datos de tarjeta.
- Invierte primero en los controles transversales (CloudTrail, cifrado por defecto, identidad fuerte, detección): marcan casillas en todos los marcos a la vez.
- Cumplir es el suelo mínimo, no la seguridad real.