PCI DSS Security Maturity Model·AWS v1.1.0

Arrastra para explorar · pellizca para ampliar
Inicio / Matriz / Requisito 1 / c1.4
Efficient 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.4 Inspección de tráfico con AWS Network Firewall en el perímetro del CDE

Desplegar controles de seguridad de red con estado (stateful) e inspección profunda de paquetes en los límites del CDE para filtrar tráfico según reglas de aplicación y dominios, más allá de lo que ofrecen Security Groups y NACLs.

Quick Wins
Foundational
Efficient
Optimized
Esfuerzo: Alto Impacto: Medio 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

Implementar AWS Network Firewall en subredes de inspección dedicadas, con reglas Suricata para filtrado por dominio (FQDN) y firmas de amenazas. Activar la validación de IP resuelta de Route 53 para que la lista de permitidos por FQDN no se pueda evadir: el firewall comprueba que la IP de destino de cada conexión saliente fue realmente devuelta por el VPC Resolver, lo que bloquea conexiones directas a una IP y encabezados SNI/Host falsificados, y extiende el filtrado por dominio a protocolos como SSH y SFTP. Acotarla con un grupo de reglas de Route 53 Resolver DNS Firewall asociado solo a las VPCs del CDE. Centralizar la inspección en una VPC de inspección conectada vía Transit Gateway. Registrar el tráfico permitido y bloqueado hacia CloudWatch Logs o S3 para evidencia.

Implementación práctica

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

Añade inspección profunda de paquetes con estado en el límite del CDE con AWS Network Firewall, yendo más allá de lo que security groups y NACLs pueden expresar (reglas de FQDN y firmas), y haz que la lista de permitidos por FQDN no se pueda evadir con la validación de IP resuelta.

  1. Despliega AWS Network Firewall en subredes de inspección dedicadas en la VPC y actualiza las tablas de rutas para que la salida de las subredes del CDE pase por los endpoints del firewall.
    Subredes de inspección (en la VPC) Network Firewall Amazon VPC
  2. Crea una política con listas de permitidos por FQDN para los destinos que el CDE necesita legítimamente, más firmas de amenazas Suricata y reglas anti-spoofing.
    Ruta de salida del CDE Network Firewall
  3. Activa la validación de IP resuelta de Route 53 en la política del firewall, referenciando un grupo de reglas de DNS Firewall asociado solo a la VPC del CDE, para que una conexión a una IP que el VPC Resolver no devolvió (conexión directa a una IP, o un SNI/Host falsificado) no pase la lista de permitidos. Empieza en modo ALERT (requiere el logging del firewall), revisa los flujos marcados y luego cambia a DROP o REJECT. Enruta cada subred del CDE al endpoint del firewall de su propia zona de disponibilidad, porque las resoluciones se registran por zona y las conexiones entre zonas fallan la validación.
    Ruta de salida del CDE Network Firewall Route 53 DNS Firewall
  4. Envía los logs de alerta y de flujo del firewall a CloudWatch Logs o S3 para conservar el tráfico permitido y bloqueado como evidencia.
    Registro de la cuenta Network Firewall CloudWatch Amazon S3

Cómo validar: Las tablas de rutas muestran la salida del CDE atravesando el firewall, los logs del firewall muestran tráfico a FQDN no permitidos siendo descartado, y una conexión de prueba desde el CDE a una IP no relacionada usando un dominio permitido es bloqueada por la validación de IP resuelta.

Evita: Desplegar el firewall pero no cambiar las tablas de rutas, de modo que el tráfico lo evita, o confiar solo en una lista de permitidos por FQDN. La inspección solo funciona si el enrutamiento fuerza cada flujo por los endpoints del firewall, y una regla de dominio solo se sostiene si la IP de destino se valida contra lo que devolvió el VPC Resolver.

Una sola cuenta, 3 capas →

Ejecuta un único AWS Network Firewall gestionado centralmente en la VPC de inspección de la cuenta de red, para que una sola política consistente proteja a todas las cuentas del CDE, con la validación de IP resuelta acotada a las VPCs del CDE.

  1. Despliega AWS Network Firewall en la VPC de inspección de la cuenta de red central.
    Cuenta de red/inspección Network Firewall
  2. Usa el enrutamiento de Transit Gateway para enviar todo el tráfico este-oeste y de salida del CDE por la VPC de inspección, para que ninguna cuenta del CDE necesite su propio firewall.
    Cuenta de red/inspección Transit Gateway
  3. Activa la validación de IP resuelta en la política central con un grupo de reglas de DNS Firewall asociado solo a las VPCs del CDE, y define sus rangos de IP de origen con los CIDR de las VPCs del CDE. Por defecto solo se valida el CIDR de la propia VPC del firewall, así que sin esto el tráfico del CDE que llega por Transit Gateway nunca se comprueba. Usa un firewall conectado al Transit Gateway, que conserva la zona de disponibilidad del cliente junto con el tráfico. Deja las VPCs que no son del CDE fuera del grupo de reglas: todas las VPCs asociadas aportan a un mismo pool compartido de IPs resueltas.
    Cuenta de red/inspección Network Firewall Route 53 DNS Firewall Transit Gateway
  4. Opcionalmente distribuye y aplica la política de Network Firewall en las cuentas con Firewall Manager, y entrega los logs del firewall a la cuenta central de log-archive.
    Cuenta de herramientas de seguridad → Cuenta de log-archive Firewall Manager Amazon S3

Cómo validar: Las rutas de Transit Gateway prueban que todo el tráfico del CDE transita la VPC de inspección, Firewall Manager reporta la política de Network Firewall aplicada a cada cuenta del CDE, y la validación de IP resuelta de la política lista los CIDR de las VPCs del CDE como rangos de origen, con un grupo de reglas de DNS Firewall asociado solo a VPCs del CDE.

Evita: Levantar un firewall separado por cada cuenta del CDE, o activar la validación de IP resuelta de forma central sin definir los rangos de origen del CDE. Lo primero multiplica el costo y la desviación de políticas; lo segundo no valida, sin avisar, nada de lo que llega desde las VPCs del CDE.

Multi-cuenta con un OU dedicado a PCI →

Validación PCI

Métodos de comprobación: examineobserve

Procedimientos de prueba

  • Examinar la documentación del proveedor y las configuraciones de los NSC para verificar que el tráfico entrante desde redes no confiables hacia redes confiables está restringido (1.4.2).
  • Examinar las configuraciones de los NSC para verificar que el tráfico saliente del CDE se restringe al mínimo necesario (1.3.2.b).
  • Examinar la política del firewall para verificar que las restricciones de salida basadas en dominio no se pueden evadir conectándose directamente a una dirección IP o falsificando el SNI/Host (validación de IP resuelta en DROP o REJECT), y que cualquier rango de destino exceptuado está documentado y justificado (1.3.2.b).
  • Examinar las configuraciones de los NSC para verificar que las medidas anti-spoofing detectan y bloquean direcciones IP de origen falsificadas (1.4.3).

Evidencia en AWS

  • Grupos de reglas (policy) de AWS Network Firewall mostrando filtrado por dominio y firmas.
  • Ajustes de validación de IP resuelta de la política del firewall: acción, grupo de reglas de DNS Firewall acotado a las VPCs del CDE, rangos de IP de origen y rangos exceptuados documentados.
  • Logs de flujo del firewall en CloudWatch/S3 evidenciando tráfico permitido y denegado, incluidas las conexiones que fallaron la validación de IP resuelta.
  • Arquitectura de la VPC de inspección con las rutas que fuerzan el tráfico a través del firewall.

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

AWS Network Firewall Amazon Route 53 Resolver DNS Firewall AWS Transit Gateway Amazon CloudWatch Logs

Recursos de aprendizaje

Referencias

  • AWS Security Maturity Model: Outbound Traffic Control