Modelo de Madurez de Seguridad PCI DSS para AWS

El eje vertical son los 12 requisitos de PCI DSS (agrupados en 6 objetivos de control). El eje horizontal son 4 fases de madurez priorizadas por facilidad/costo frente a impacto: Quick Wins, Foundational, Efficient y Optimized. Cada celda contiene una o más recomendaciones de control en AWS. Las fases son una hoja de ruta, no una calificación de madurez: empieza por los Quick Wins (alto impacto, bajo esfuerzo) y avanza hacia Optimized (cumplimiento continuo y automatizado). Las recomendaciones están alineadas a PCI DSS v4.0.1; consulta el Historial de cambios para ver la versión del modelo y las actualizaciones futuras.

Cada recomendación indica qué es el control y por qué importa (resumen), cómo implementarlo en AWS (guía de implementación y servicios AWS), cómo se validaría (métodos de comprobación PCI y procedimientos de prueba) y qué evidencia puedes aportar en AWS. Cada recomendación también está etiquetada con su fase de madurez, su dominio de seguridad AWS, los sub-requisitos PCI que cubre, el esfuerzo/impacto, si aplica al CDE y su clasificación de responsabilidad compartida.

El modelo ofrece dos caminos de arquitectura de referencia para alojar un entorno de datos del titular de la tarjeta (CDE) en AWS: un diseño de una sola cuenta y tres capas para entornos pequeños o iniciales, y un diseño multi-cuenta con una unidad organizativa (OU) dedicada a PCI para escala, segregación de funciones y reducción de alcance.

No son solo diagramas de contexto. En la página de detalle de cada recomendación, una sección de Implementación práctica muestra cómo se aplica ese control específico en cada arquitectura, para que veas la diferencia entre, por ejemplo, aislar el CDE con subredes en una sola cuenta frente a aislarlo en una cuenta dedicada bajo una OU de PCI. Empieza en la página de Arquitecturas de referencia para entender los dos caminos, y luego usa la matriz y la guía práctica de cada control para planear tu implementación.

En AWS, el cumplimiento de PCI DSS es una responsabilidad compartida. Cada recomendación se clasifica como 'cliente' (tú la implementas y la evidencias), 'aws' (AWS opera el control; tú lo heredas y lo evidencias con el Attestation of Compliance PCI DSS de AWS obtenido en AWS Artifact) o 'compartida' (ambas partes tienen obligaciones). Esta clasificación se deriva del System Security Plan de AWS en formato OSCAL. La seguridad física (Requisito 9.2, 9.3) es un ejemplo típico de 'aws'; las políticas y la gestión de riesgos (Requisito 12) suelen ser de 'cliente'.

PCI DSS v4.0.1 permite dos formas de cumplir la mayoría de los requisitos.

• Enfoque definido (Defined Approach): implementas el requisito tal como está escrito y se valida contra los procedimientos de prueba definidos por el estándar. Es lo que describen los campos de 'procedimientos de prueba' y 'evidencia en AWS' de cada recomendación, y es el camino que sigue la mayoría de las organizaciones.

• Enfoque personalizado (Customized Approach): en lugar de seguir el método prescrito, diseñas tus propios controles que cumplen el Objetivo del Enfoque Personalizado del requisito. Este camino es para organizaciones maduras con una función robusta de gestión de riesgos. Exige un análisis de riesgo dirigido documentado (Requisito 12.3.2), y el evaluador deriva procedimientos de prueba a la medida para confirmar que tus controles cumplen el objetivo.

Por eso, cada recomendación elegible incluye el Objetivo del Enfoque Personalizado de el/los sub-requisito(s) que cubre, para que un equipo que elija el camino personalizado sepa qué resultado deben lograr sus controles a medida. No todos los controles son elegibles: algunos son solo de enfoque definido (por ejemplo, no almacenar datos sensibles de autenticación bajo el Requisito 3.3). Los enfoques personalizados suelen aparecer en la fase Optimized, donde las organizaciones optimizan cómo cumplen los objetivos en lugar de cómo está escrito el requisito.

Como cada recomendación lleva etiquetas estructuradas, el mismo contenido puede verse por requisito PCI (la matriz por defecto), por fase de madurez (una hoja de ruta), por dominio de seguridad AWS (una vista transversal) o por responsabilidad compartida (cliente vs heredado de AWS). También puedes filtrar por si un control aplica al CDE y por esfuerzo/impacto.

El modelo está disponible en inglés (idioma fuente), español y portugués. El texto de los requisitos y los procedimientos de prueba están alineados con el estándar oficial PCI DSS v4.0.1; la clasificación de responsabilidad compartida y el catálogo de controles provienen del paquete OSCAL de PCI DSS de AWS; y la guía de AWS se apoya en la guía de PCI DSS en AWS, la AWS Security Reference Architecture y el AWS Security Maturity Model.