La implementación adecuada de controles de alcance y segmentación es esencial para proteger los datos de tarjetas de pago y garantizar que los sistemas que gestionan esta información estén correctamente aislados. Las arquitecturas de red modernas, al integrar tecnologías avanzadas como proxies gestionados, gateways de API y mallas de servicios, permiten una segmentación eficiente y un control granular sobre el tráfico, asegurando el cumplimiento con los requisitos de PCI DSS.
A continuación, se presenta un resumen detallado de las mejores prácticas y consideraciones clave para aplicar controles de alcance y segmentación en el contexto de PCI DSS:
Mantenimiento de Diagramas de Red y Flujos de Datos (Requisitos 1.2.3-1.2.4)
Es fundamental mantener diagramas precisos de la red y los flujos de datos, cubriendo todos los segmentos de red, como VLANs, subredes y elementos críticos de la infraestructura (cortafuegos, WAFs, IDS/IPS, servidores DNS, entre otros). El uso de herramientas automatizadas para el descubrimiento y monitoreo continuo de la red facilita la actualización regular de estos diagramas, especialmente en entornos virtualizados y dinámicos.
Controles de Seguridad en Redes Confiables y No Confiables (Requisito 1.4.1)
Las organizaciones deben implementar controles de seguridad robustos en las conexiones entre redes confiables y no confiables. Esto incluye el uso de zonas de demilitarización (DMZ) o arquitecturas equivalentes en la nube, donde los WAFs y cortafuegos actúan como filtros perimetrales, protegiendo los servicios y aplicaciones internas de accesos no autorizados. La segmentación adecuada ayuda a aislar los sistemas dentro del CDE (entorno de datos de pago) de las redes externas, reduciendo la exposición de los datos sensibles.
Metodología de Pruebas de Penetración (Requisitos 11.4.1 y 11.4.5)
Las pruebas de penetración deben abarcar tanto la capa de aplicación como las capas de infraestructura, orquestación e hipervisores. Además, deben incluir la evaluación de vulnerabilidades en herramientas de código abierto y servicios en la nube que podrían introducir riesgos en la cadena de suministro, asegurando que las dependencias de software estén libres de fallos de seguridad.
Mantenimiento de Inventarios de Componentes en el Alcance (Requisito 12.5.1)
En entornos dinámicos de nube, es necesario gestionar un inventario actualizado de componentes y servicios a través de herramientas automatizadas, como bases de datos de gestión de configuración (CMDB). Estas herramientas permiten mantener visibilidad de los activos que participan en el alcance PCI DSS, incluso en entornos que pueden cambiar rápidamente.
Documentación y Confirmación del Alcance PCI DSS (Requisitos 12.5.2 y 12.5.2.1)
Definir y documentar los límites del alcance de PCI DSS es fundamental, especialmente en entornos de nube donde las responsabilidades pueden ser compartidas entre el proveedor de servicios en la nube (CSP) y la organización. Las metodologías de segmentación deben revisarse anualmente, y si se producen cambios significativos en la arquitectura, se debe realizar un análisis de riesgo para validar la efectividad de la segmentación.
Gestión de Relaciones con Proveedores de Servicios de Terceros (Requisito 12.8)
Es crucial mantener un inventario detallado de los proveedores de servicios de terceros, como los CSP, que gestionan datos de tarjetas de pago. Estos deben estar documentados junto con los contratos, acuerdos de nivel de servicio (SLA) y las responsabilidades compartidas en seguridad y cumplimiento, especialmente cuando se utilizan servicios gestionados o tecnologías de terceros.
La segmentación eficaz de redes es un pilar fundamental para reducir el alcance de PCI DSS, simplificando los procesos de cumplimiento y reduciendo los costos operativos. A continuación, se describen varias estrategias clave que emplean tecnologías avanzadas para lograr una segmentación efectiva y segura en redes modernas:
Patrón de Proxy
El Patrón de Proxy permite segmentar las redes al interponer un proxy que controla y autoriza el tráfico entre los sistemas fuera del CDE y los sistemas que manejan datos de tarjetas de pago. Este enfoque actúa como un punto central de control, asegurando que solo el tráfico autorizado acceda al CDE.
Criterios de implementación:
▪️ Ubicación Perimetral: El proxy debe situarse en el borde de la red, actuando como el punto de terminación de las conexiones entrantes.
▪️ De-Scoping: El tráfico que pasa por el proxy no debe incluir datos sensibles, verificándose mediante la clasificación de los datos en tránsito.
▪️ Terminación de Conexiones: El proxy es responsable de finalizar las conexiones entrantes para asegurar la integridad de los datos al entrar al CDE.
▪️ Gestión de Vulnerabilidades: En caso de utilizar un sistema IDS, el proxy puede limitarse a gestionar el tráfico sin necesidad de inspección profunda de vulnerabilidades.
Proxy Gestionado
El Proxy Gestionado es un servidor proxy administrado por un proveedor de servicios en la nube (CSP), el cual se convierte en un punto de control para el tráfico entre sistemas fuera y dentro del alcance PCI DSS.
Criterios de implementación:
▪️ Enrutamiento de Tráfico: El tráfico desde sistemas fuera del alcance PCI DSS debe pasar a través de un proxy antes de llegar a los sistemas sensibles.
▪️ Prohibición de Comunicación Directa: No debe permitirse la comunicación directa entre sistemas fuera del alcance y el CDE.
▪️ Ubicación del Proxy: El proxy debe residir en una VPC de desescalado fuera del CDE.
▪️ Redirección de Tráfico: Los sistemas fuera del alcance que necesiten datos deben pasar el tráfico a través del proxy utilizando un grupo de seguridad.
API Gateway
El API Gateway actúa como un proxy para gestionar y interrumpir el tráfico en arquitecturas de microservicios. Al implementar intercepción TLS, el API Gateway puede terminar la conexión original y establecer una nueva, segura.
Criterios de implementación:
▪️ Intercepción TLS: El API Gateway debe interceptar y reiniciar las conexiones TLS, asegurando que el tráfico se cifre correctamente antes de llegar a los servicios sensibles.
▪️ Actualización de Sistemas Tradicionales: Los sistemas tradicionales que aún dependen de conexiones TLS continuas deben actualizarse para ser compatibles con esta estrategia.
Servicios Gestionados Intermedios
Los Servicios Gestionados Intermedios proporcionados por los CSPs crean un corte en las conexiones para mitigar riesgos y permitir una segmentación adicional. Servicios como el almacenamiento en la nube y colas Pub/Sub pueden actuar como proxies mejorados.
Criterios de implementación:
▪️ Alcance de los Contenedores de Almacenamiento: Si los contenedores almacenan datos sensibles, deben estar dentro del alcance de PCI DSS.
▪️ Evaluación de Servicios: Los servicios intermedios deben ser evaluados y auditados para verificar su cumplimiento con PCI DSS.
Malla de Servicios Nativa
Una Malla de Servicios facilita la comunicación segura entre microservicios a través de políticas avanzadas de tráfico. Al implementar mTLS (TLS mutuo) a nivel de pod, se asegura que la comunicación sea autenticada y cifrada, garantizando que solo los servicios autorizados se comuniquen entre sí.
Beneficios:
▪️ Aislamiento a Nivel de Red: La malla segmenta las comunicaciones, garantizando que solo los servicios autenticados y cifrados puedan interactuar.
▪️ Verificación de Identidad: Mediante SPIFFE IDs, se valida la identidad de cada servicio, mejorando la seguridad de la infraestructura.
Gateways de Ingreso y Egreso en Mallas de Servicios
Los Gateways de Ingreso y Egreso gestionan el tráfico que entra y sale de un CDE, asegurando que solo el tráfico autorizado se comunique con sistemas internos o externos.
Criterios de implementación:
▪️ Gateway de Ingreso: Todo el tráfico entrante debe pasar por un gateway de ingreso que gestione y proteja el tráfico antes de distribuirlo a los servicios internos.
▪️ Gateway de Egreso: El tráfico saliente debe pasar por un gateway de egreso, asegurando que solo el tráfico autorizado salga del CDE.
▪️ Seguridad por Defecto: La malla de servicios debe estar configurada para denegar todas las conexiones por defecto, permitiendo solo las explícitamente autorizadas.
Políticas de Autenticación y Seguridad: Zero Trust
La implementación de Zero Trust en arquitecturas de microservicios implica el uso de mTLS para garantizar que cada servicio sea autenticado antes de permitirle acceso a otros servicios. Las políticas de autenticación en herramientas como Istio permiten definir cómo los workloads se comunican entre sí, especificando reglas estrictas para la autenticación y cifrado del tráfico.
Modos de Autenticación en Istio:
▪️ PERMISSIVE: Permite tanto tráfico TLS mutuo como no cifrado. Ideal para migraciones.
▪️ STRICT: Solo acepta tráfico TLS mutuo. Recomendado para entornos con estrictos controles de seguridad.
▪️ DISABLE: Deshabilita el tráfico TLS mutuo, lo cual no se recomienda debido a la falta de protección.
Políticas de Red en Kubernetes y Mallas de Servicios
Las Políticas de Red de Kubernetes proporcionan segmentación básica entre pods, mientras que una malla de servicios como Istio ofrece un control más detallado de la comunicación entre microservicios. Utilizar ambos mecanismos establece una defensa en profundidad, asegurando tanto la segmentación a nivel de red como el control avanzado del tráfico.
Las estrategias de segmentación como el Patrón de Proxy, Proxy Gestionado, API Gateway, Servicios Gestionados Intermedios, Malla de Servicios Nativa y Gateways de Ingreso y Egreso en mallas de servicios son esenciales para gestionar la seguridad en arquitecturas de red modernas y garantizar el cumplimiento de PCI DSS. Estas tecnologías no solo reducen el alcance de PCI DSS, sino que también optimizan la infraestructura, mejorando la seguridad general de la red. Además, la implementación de políticas de Zero Trust mediante autenticación mutua TLS y la integración de políticas de red en Kubernetes refuerzan la seguridad, asegurando que solo las conexiones seguras y autorizadas sean permitidas.
Referencias
📑 Estándar PCI DSS v4.0.1
📑 Guía para Alcance y segmentación de PCI DSS para arquitecturas de red modernas