PCI DSS Security Maturity Model·AWS v1.1.0

Arrastra para explorar · pellizca para ampliar
Inicio / Matriz / Requisito 1 / c1.2
Foundational Infrastructure ProtectionDominio de seguridad de la perspectiva de seguridad del AWS Cloud Adoption Framework (CAF), usado para organizar los controles. 🤝 CompartidaModelo de Responsabilidad Compartida de AWS: quién implementa y opera este control. Cliente = es tuyo; AWS = lo opera AWS y tú lo heredas; Compartida = ambos tienen obligaciones.

c1.2 Limitar el acceso de red hacia y desde el CDE

Restringir explícitamente el tráfico entrante y saliente del entorno de datos del titular de la tarjeta al mínimo necesario para las funciones de negocio, aplicando el principio de denegación por defecto.

Quick Wins
Foundational
Efficient
Optimized
Esfuerzo: Medio Impacto: Alto Aplica al CDE: Sí

Requisito 1

Install and Maintain Network Security Controls

Sub-requisitos PCI cubiertosCobertura mostrada por sub-control de PCI DSS v4.0.1. “Cubierto” = atendido por esta recomendación de AWS. “En roadmap” = técnico, planeado. “Tu responsabilidad” = control organizacional/de proceso. “Fuera de alcance” = control físico o de terceros no implementado en AWS.

1.3 Restricción del acceso de red hacia y desde el CDE
  • 1.3.1 Inbound traffic to the CDE is restricted to what is necessary Cubierto
  • 1.3.2 Outbound traffic from the CDE is restricted to what is necessary Cubierto
  • 1.3.3 NSCs installed between all wireless networks and the CDE Cubierto
1.4 Control de conexiones de red entre redes confiables y no confiables
  • 1.4.1 NSCs between trusted and untrusted networks Cubierto
  • 1.4.2 Inbound traffic from untrusted networks to trusted is restricted Cubierto
  • 1.4.3 Anti-spoofing measures detect and block forged source IPs Cubierto
  • 1.4.4 System components storing CHD not directly reachable from untrusted networks Cubierto
  • 1.4.5 Disclosure of internal IP/routing information is limited Cubierto

Cómo implementarlo en AWS

Diseñar subredes dedicadas para el CDE con Network ACLs restrictivas además de los Security Groups. Documentar y justificar cada regla permitida. Usar Security Groups con referencias entre grupos en lugar de rangos IP amplios. Restringir el tráfico saliente del CDE a destinos aprobados.

Implementación práctica

Cómo se implementa este control en cada arquitectura de referencia:

Envuelve las capas del CDE en una postura de denegación por defecto: security groups para la lista de permitidos, NACLs como respaldo a nivel de subred y salida privada solo hacia servicios de AWS.

  1. Coloca la capa de datos en sus propias subredes privadas y adjunta una Network ACL que permita solo el puerto de base de datos desde las subredes de app y deniegue todo lo demás (denegación por defecto en el límite de la subred).
    Capa de datos (CDE) Amazon VPC
  2. Mantén una matriz de flujos autorizados (origen, destino, puerto, justificación de negocio) que coincida exactamente con tus reglas de security group y NACL; trátala como el artefacto de evidencia para 1.3/1.4.
    Todas las capas del CDE Amazon VPC
  3. Restringe el tráfico de salida del CDE solo a los servicios de AWS que necesita (p. ej. Secrets Manager, KMS) usando VPC endpoints, de modo que ese tráfico nunca pase por internet público.
    Capa de app (CDE) / Capa de datos (CDE) Amazon VPC Secrets Manager AWS KMS

Cómo validar: Las exportaciones de NACL y security groups coinciden línea por línea con la matriz de flujos autorizados, y una prueba de conectividad desde la capa de datos a cualquier destino no aprobado es denegada.

Evita: Usar rangos CIDR amplios (p. ej. 10.0.0.0/8) en las reglas «para simplificar». Referencia security groups de origen en su lugar, para que la lista de permitidos se mantenga estricta a medida que crece la red.

Una sola cuenta, 3 capas →

Fuerza todo el tráfico del CDE por la ruta central de ingreso/inspección, refuerza la denegación por defecto con SCPs y mantén el tráfico a servicios de AWS privado con VPC endpoints compartidos.

  1. Enruta el ingreso a las cuentas de carga del CDE solo por la ruta de ingreso de la cuenta de red central; bloquea el ingreso directo desde internet en las VPC de las cuentas.
    Cuenta de red/inspección → OU de PCI Transit Gateway Amazon VPC
  2. Fuerza el tráfico este-oeste y de salida de cada cuenta del CDE a través de la VPC de inspección central para que una sola política los gobierne a todos.
    Cuenta de red/inspección Transit Gateway Network Firewall
  3. Refuerza la denegación por defecto con SCPs en la OU de PCI (p. ej. denegar crear internet gateways o recursos públicos en las cuentas del CDE).
    OU de PCI (guardarraíl) AWS Organizations
  4. Provee VPC endpoints centralizados (en la cuenta de red compartida) para que el tráfico del CDE a servicios de AWS no pase por internet público en ninguna cuenta.
    Cuenta de red/inspección Amazon VPC

Cómo validar: Las tablas de rutas de Transit Gateway muestran que las cuentas del CDE solo alcanzan la ruta de inspección, y un intento de adjuntar un internet gateway en una cuenta del CDE es denegado por la SCP.

Evita: Emparejar (peering) cuentas del CDE directamente entre sí por conveniencia. Mantén todas las rutas por la VPC de inspección para que la segmentación y el registro sigan siendo centralizados y demostrables.

Multi-cuenta con un OU dedicado a PCI →

Validación PCI

Métodos de comprobación: examineobserve

Procedimientos de prueba

  • Examinar los estándares y las configuraciones de los NSC para verificar que el tráfico entrante al CDE se restringe al mínimo necesario, denegando específicamente todo el demás tráfico (1.3.1.a, 1.3.1.b).
  • Examinar las configuraciones de los NSC para verificar que el tráfico saliente del CDE se restringe al mínimo necesario (1.3.2.a, 1.3.2.b).
  • Examinar los estándares de configuración y los diagramas de red para verificar que hay NSC entre las redes confiables y no confiables (1.4.1.a, 1.4.1.b).

Evidencia en AWS

  • Diagrama de red y matriz de flujos autorizados que corresponde con las reglas de Security Groups y NACLs implementadas.
  • Exportación de Network ACLs de las subredes del CDE mostrando reglas de denegación por defecto.
  • Registros de justificación de negocio por cada regla permitida (business justification).

Enfoque personalizado

Requiere un análisis de riesgo dirigido (Req 12.3.2).

Objetivo del enfoque personalizado

  • 1.3 — El tráfico no autorizado no puede entrar al CDE.
  • 1.4 — El tráfico no autorizado no puede atravesar los límites de red entre redes confiables y no confiables.

Servicios AWS

Amazon VPC Network ACLs Security Groups

Recursos de aprendizaje

Referencias

  • AWS Security Maturity Model: Limit Network Access