PCI DSS Security Maturity Model·AWS v1.0.0
Inicio / Arquitecturas de referencia

Arquitecturas de referencia

Dos caminos de referencia para alojar un entorno de datos del titular de la tarjeta (CDE) de PCI DSS en AWS. La página de detalle de cada recomendación muestra cómo se implementa el control en ambos caminos. Empieza con el diseño de una sola cuenta y 3 capas para entornos pequeños o iniciales, y adopta el diseño multi-cuenta a medida que crecen las necesidades de escala, segregación de funciones y reducción de alcance.

Una sola cuenta, 3 capas
Ideal para equipos pequeños, pruebas de concepto o una sola carga de trabajo donde aún no se justifica la sobrecarga operativa de varias cuentas. Todas las responsabilidades de PCI DSS se concentran en una cuenta.
Multi-cuenta con un OU dedicado a PCI
Ideal para organizaciones con múltiples cargas de trabajo, equipos o entornos que necesitan una fuerte segregación de funciones, aislamiento del radio de impacto y reducción del alcance de PCI DSS. Recomendado como estado objetivo para CDEs de producción a escala.

Una sola cuenta, 3 capas

Una única cuenta de AWS que aloja una aplicación clásica de tres capas (web, aplicación y datos) dentro de una VPC, con el CDE aislado en subredes privadas dedicadas. El punto de partida más simple para operar un CDE conforme en AWS.

AWS account VPC Public subnet ALB WAF CloudFront Private subnet · App tier (CDE) EC2 App Private subnet · Data tier (CDE) RDS KMS Account-wide logging & detection CloudTrail Config GuardDuty Security Hub Internet ▲ (users)
Una sola cuenta de AWS con una VPC. La subred pública aloja el balanceador; las subredes privadas alojan las capas de aplicación y base de datos (el CDE). Los guardrails y la detección aplican a toda la cuenta.

Cuándo usarla

Ideal para equipos pequeños, pruebas de concepto o una sola carga de trabajo donde aún no se justifica la sobrecarga operativa de varias cuentas. Todas las responsabilidades de PCI DSS se concentran en una cuenta.

Principios de diseño

  • Separar las capas en sus propias subredes: pública (balanceador), aplicación privada y datos privados.
  • Ubicar el CDE (sistemas que almacenan, procesan o transmiten datos de cuenta) en subredes privadas dedicadas, sin acceso entrante directo desde internet.
  • Controlar el tráfico entre capas con security groups por capa que se referencian entre sí, más network ACLs restrictivas.
  • Anteponer un Application Load Balancer y AWS WAF a los puntos de entrada públicos; terminar TLS con certificados de ACM.
  • Cifrar los datos en reposo con claves administradas por el cliente de AWS KMS y habilitar registro y detección a nivel de cuenta (CloudTrail, Config, GuardDuty, Security Hub).

Servicios AWS

Amazon VPC Elastic Load Balancing Amazon EC2 Amazon RDS AWS WAF AWS KMS AWS CloudTrail AWS Config Amazon GuardDuty AWS Security Hub

Multi-cuenta con un OU dedicado a PCI

Una landing zone de AWS Organizations donde el CDE reside en cuentas de carga de trabajo bajo una unidad organizativa (OU) dedicada a PCI, separada de las cargas no PCI. Cuentas centralizadas de seguridad, registro y red proveen guardrails, agregación e inspección.

AWS Organizations Shared / foundational accounts Security tooling Log archive Network / inspection PCI OU (dedicated) CDE workload account CDE in isolated VPC / subnets CDE workload account (2) Additional CDE workloads, same guardrails SCPs applied at the PCI OU enforce guardrails (deny disabling logging/encryption, restrict Regions).
AWS Organizations con una OU dedicada a PCI para las cuentas de carga del CDE, más cuentas compartidas de seguridad, log-archive y red. El tráfico se inspecciona de forma central; los guardrails se aplican vía SCPs.

Cuándo usarla

Ideal para organizaciones con múltiples cargas de trabajo, equipos o entornos que necesitan una fuerte segregación de funciones, aislamiento del radio de impacto y reducción del alcance de PCI DSS. Recomendado como estado objetivo para CDEs de producción a escala.

Principios de diseño

  • Aislar el CDE en cuentas de carga de trabajo dedicadas bajo una OU de PCI, separadas de las cuentas no PCI.
  • Usar service control policies (SCPs) en la OU de PCI para imponer guardrails (p. ej. denegar la desactivación de logging o cifrado, restringir regiones).
  • Centralizar los registros de auditoría en una cuenta de log-archive dedicada, con acceso restringido y resistente a alteraciones.
  • Centralizar la detección y la postura en una cuenta de herramientas de seguridad (GuardDuty, Security Hub, agregador de Config) como administrador delegado.
  • Enrutar e inspeccionar el tráfico entre VPCs y el egress a través de una cuenta de red central (Transit Gateway + AWS Network Firewall).
  • Aprovisionar la landing zone y las líneas base de las cuentas de forma consistente con AWS Control Tower e infraestructura como código.

Servicios AWS

AWS Organizations AWS Control Tower AWS Transit Gateway AWS Network Firewall Amazon VPC AWS CloudTrail AWS Config Amazon GuardDuty AWS Security Hub AWS KMS