En septiembre de 2025 el PCI SSC publicó un nuevo suplemento informativo para la definición del alcance y segmentación en arquitecturas de red modernas (Information Supplement – PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures). En este artÃculo analizamos los cinco puntos clave de ese nuevo documento y el impacto en los criterios para la identificación de activos y servicios dentro y fuera del alcance de cumplimiento de PCI DSS 4.x.
Una de las actividades más complicadas y que generan más confusión entre las entidades afectadas por el cumplimiento de PCI DSS es la definición del alcance de cumplimiento (scope). Este proceso le permite a la entidad identificar todos los componentes del sistema, personas y procesos a ser incluidos en una validación de cumplimiento de PCI DSS.
Criterios de identificación de activos en el alcance de cumplimiento de PCI DSS
Con el fin de facilitar esta tarea, en mayo de 2017 se publicó el documento «Guidance for PCI DSS Scoping and Segmentation», que describÃa en detalle los conceptos de alcance de cumplimiento, la identificación de terceras entidades involucradas en el entorno, la gestión de responsabilidades y el uso de controles de segmentación para minimizar el alcance. No obstante, desde esa época muchas cosas en el entorno tecnológico han cambiado, incluyendo el uso de virtualización, contenedores y orquestación, servicios en la nube, uso de nuevos enfoques como DevOps y cambios en las arquitecturas operativas.
Algunos de estos conceptos fueron analizados en otros suplementos informativos como «PCI DSS Virtualization Guidelines» y «PCI SSC Cloud Computing Guidelines«, pero siempre quedaban «zonas grises» en los criterios de identificación de activos, que podÃan llevar a confusiones y errores en el momento de definir el alcance y confirmar si los conceptos de segmentación y aislamiento estaban correctamente implementados. Igualmente, con la introducción de nuevas tecnologÃas y servicios en la nube, los conceptos tradicionales de segmentación y filtrado se quedaban cortos y su implementación técnica muchas veces no era la apropiada para asegurar nuevas tecnologÃas.
Suplemento informativo: Alcance y segmentación en arquitecturas de red modernas
Con la publicación de la versión 4.0 de PCI DSS y el ingreso del concepto de Network Security Controls (NCS) se dio el primer paso para extender el concepto de filtrado de tráfico más allá de los firewalls tradicionales e incluir cualquier solución que permita el análisis de tráfico entrante y saliente entre dos o más segmentos de red lógicos o fÃsicos basados en reglas o polÃticas predefinidas, dentro de los cuales se pueden encontrar dispositivos virtuales, controles de acceso a servicios en la nube, controles en entornos de contenedores y tecnologÃas de red definidas por software (Software Defined Networking – SDN). Con ello, ya se aceptaba desde el punto de vista de cumplimiento que no solamente los firewalls tradicionales servÃan para filtrar tráfico entre redes (como ocurrÃa en versiones anteriores del estándar PCI DSS), por lo que los lÃmites del entorno de cumplimiento podrÃan estar protegidos mediante otros controles y era necesario redefinir los criterios de segmentación y aislamiento.
Siendo asÃ, el suplemento informativo para la definición del alcance y segmentación en arquitecturas de red modernas (Information Supplement – PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures) entra a complementar los conceptos analizados en otros suplementos informativos sin que ello implique que esos documentos queden obsoletos. Como su nombre lo indica, este documento está enfocado hacia arquitecturas de red modernas en las que las fronteras del entorno podrÃan no ser fÃsicas sino lógicas y en donde se pueden incluir tecnologÃas como servicios en la nube, virtualización y uso de contenedores.
Nota PCI Hispano: La segmentación (o aislamiento) del CDE del resto de la red de la entidad no es un requerimiento de PCI DSS, pero sirve para reducir el alcance, el coste, la dificultad de implementación y el riesgo, consolidando los datos en ubicaciones controladas.
Este suplemento informativo es uno de los más largos y complejos, por lo que, a continuación, destacaremos los cinco puntos mas relevantes de este documento.
1. Entornos multi-cloud y segmentación
Los conceptos de seguridad a ser implementados en entornos en la nube (cloud) cuando el entorno procesa, almacena o transmite datos de tarjetas de pago ya fueron ampliamente analizados en el suplemento informativo «PCI SSC Cloud Computing Guidelines«. Sin embargo, para las entidades que hacen uso de múltiples proveedores de servicio en la nube (Cloud Service Providers – CSP) y necesitaban reglas especÃficas para decidir qué recursos estaban o no en el alcance, probablemente ese documento no era suficiente.
El suplemento informativo para la definición del alcance y segmentación en arquitecturas de red modernas lista como analizar estos entornos (Multi-Cloud Environments – MCE) y determinar el impacto en conexiones vÃa VPN, enlaces dedicados o direccionamiento IP expuesto en internet entre servicios en la nube. Adicionalmente, se brindan recomendaciones para la ejecución de pruebas de penetración (penetration testing) en virtual private clouds (VPCs) y el uso de múltiples cuentas en el mismo CSP o en múltiples CSPs.
2. Arquitecturas de Confianza Cero (Zero-Trust Architecture – ZTA)
La confianza cero (Zero Trust – ZT) es el término que designa un conjunto de paradigmas de ciberseguridad en evolución que desplazan las defensas de los perÃmetros estáticos basados en la red para centrarse en los usuarios, los activos y los recursos. Una arquitectura de confianza cero (Zero-Trust Architecture – ZTA) utiliza principios de confianza cero para planificar la infraestructura y los flujos de trabajo industriales y empresariales. La confianza cero asume que no hay confianza implÃcita concedida a activos o cuentas de usuario basada únicamente en su ubicación fÃsica o de red (es decir, redes de área local frente a Internet) o basada en la propiedad de los activos (propiedad de la empresa o personal). La autenticación y la autorización (tanto del sujeto como del dispositivo) son funciones discretas que se realizan antes de establecer una sesión con un recurso de la empresa. La confianza cero se centra en proteger los recursos (activos, servicios, flujos de trabajo, cuentas de red, etc.), no los segmentos de red, ya que la ubicación de la red ya no se considera el componente principal de la postura de seguridad del recurso.
Accesos de la confianza cero
Este concepto fue definido en el documento NIST SP 800-207 y ha marcado un punto de inflexión en la forma en cómo se entiende e implementa el acceso a los recursos. En el caso de PCI DSS, esta es la primera vez en la que se realiza un análisis de este paradigma y su implementación en entornos de protección de datos de tarjetas, mostrando la voluntad del PCI SSC de incorporar nuevos conceptos más allá de los controles tradicionales. En este caso, la confianza cero no remplaza los controles de red tradicionales en el perÃmetro, sino que refuerza el foco sobre la gestión de permisos. Siendo asÃ, en una entidad lo suficientemente madura y con controles de filtrado tradicionales desplegados de forma satisfactoria, la confianza cero (ZT) reforzará y complementará sus polÃticas, procesos y estrategia de seguridad para ayudar a determinar, en tiempo real, si se debe permitir el acceso de los usuarios, dispositivos y servicios a los recursos del CDE y a sus entornos conectados empleando puntos de inspección definidos por software (software-defined inspection points).
En el suplemento informativo para la definición del alcance y segmentación en arquitecturas de red modernas se brindan instrucciones detalladas acerca de cómo evaluar controles de confianza cero (ZT) en entornos PCI DSS, cómo documentar estos controles y cómo implementarlos de forma satisfactoria, incluyendo la identificación de los datos a ser protegidos, la implementación de controles ZT (verificación y autenticación, limitación de acceso, microsegmentación, monitorización, cifrado y registro de eventos), la creación de diagramas de red y flujos de datos, la documentación de polÃticas y procedimientos, la ejecución de análisis de riesgos, la revisión de terceros y la creación de planes de respuesta a incidentes.
Finalmente, también se listan algunos criterios importantes a la hora de ejecutar pruebas de penetración (penetration testing) en entornos en donde existen controles de confianza cero (ZT), ya que el uso del enfoque tradicional de filtrados perimetrales puede no ser el más óptimo para evaluar el nivel de seguridad provisto por estas soluciones.
3. Entornos hÃbridos de datos de titulares de tarjetas
Si ya es complicado establecer los lÃmites de un entorno de datos de titulares de tarjetas en entornos locales (on-premises), esta complejidad se incrementa cuando existen conexiones entre entornos locales y en la nube (cloud), en donde las fronteras se difuminan y los controles de filtrado, segmentación y aislamiento se mezclan entre fÃsicos y lógicos (software-based). En el suplemento informativo para la definición del alcance y segmentación en arquitecturas de red modernas se describen los pasos estratégicos para garantizar una correcta conexión entre estos entornos (on-premises y cloud-based), identificando de forma correcta los elementos que permiten la separación entre activos, incluyendo servidores locales, instancias en la nube, dispositivos de red tradicionales y componentes intermedios.
4. TecnologÃas de virtualización de red
Teniendo en cuenta que las tecnologÃas tradicionales de red han pasado de ser fÃsicas a ser basadas en software (Software-Defined Networking – SDN), era necesario que el PCI SSC estableciera los criterios bajo los cuales dichos controles podrÃan ser tenidos en cuenta por una entidad a la hora de establecer mecanismos de filtrado, segmentación y aislamiento, asà como para definir su alcance de cumplimiento. En una arquitectura de red definida por software (SDN) se realiza una separación entre el plano de control (control plane) y el plano de datos (data plane), lo que permite controlar y administrar la infraestructura de red de forma central y programática. Con SDN, en lugar de aplicar la seguridad perimetral tradicional mediante firewalls, las aplicaciones se ejecutan dentro de sus propios segmentos detrás de un entorno de red virtualizado superpuesto a la red fÃsica. Este nivel de segmentación de la red permite crear microsegmentos entre los componentes del sistema de procesamiento de pagos y los sistemas que no son de pago, reduciendo el alcance de PCI DSS y mejorando la seguridad mediante el aislamiento de los datos confidenciales, la simplificación del cumplimiento y la minimización del impacto potencial de las brechas de seguridad en la red.
Por otro lado, también se analiza el impacto del concepto de «malla de servicios» (service mesh) en arquitecturas basadas en microservicios. En este caso, una malla de servicios entra a complementar los controles de filtrado tradicionales añadiendo nuevas capas de seguridad como cifrado TLS mutuo (mTLS), autenticación, autorización entre servicios, enrutamiento dinámico de tráfico, descubrimiento de servicios, balanceo de carga, verificación de estado (health checking) y más. En una malla de servicios ya no es necesario segmentar los sistemas a nivel de red mediante VLAN y subredes especÃficas de confianza frente a las que no lo son. La malla de servicios sirve como punto central para la autenticación y autorización del tráfico, lo que se consigue mediante la aplicación de polÃticas de autorización en la capa de aplicación.
5. Despliegue de software y DevOps
Finalmente, el uso de funcionalidades de redes definidas por software involucra la necesidad de definir, aprovisionar y soportar la infraestructura de red de la organización usando código en vez de configuraciones manuales en cada dispositivo fÃsico, lo que se conoce como Infraestructura como Código (Infrastructure as Code – IaC). La gestión de este código (que no pertenece a una aplicación de software como tal sino a la descripción lógica del estado de la infraestructura) debe ser incorporada dentro de los procesos de gestión del ciclo de vida de software (Software Development Lifecycle – SDLC).
Por otro lado, las organizaciones que usan modelos como DevOps con procesos automatizados para la integración continua (Continuous Integration – CI) y la implementación (o entrega) continua (Continuous Delivery) a través de «canales de CI/CD» deben tener en cuenta que el alcance de PCI DSS se extiende también a esos elementos. Esto incluye todos los artefactos que son creados, construidos (build) y desplegados al CDE, asà como las cuentas de servicio con privilegios elevados para gestionar despliegues y repositorios de código y de imágenes. Es imprescindible la realización de análisis detallados para verificar los controles de segmentación y aislamiento entre entornos.
Integración Continua (CI) y Distribución Continua (CD)
Conclusión
A pesar de no ser un documento técnico ni entrar en el detalle especÃfico de implementación de controles, el suplemento informativo para la definición del alcance y segmentación en arquitecturas de red modernas ofrece un conjunto de conceptos de alto nivel y generalizados para guiar tanto a la entidad como a los asesores QSA en la identificación del alcance de cumplimiento cuando se hace uso de nuevas tecnologÃas como virtualización, uso de contenedores y servicios en la nube. Muchas de estas tecnologÃas no entran a remplazar a las tecnologÃas tradicionales sino que complementan sus niveles de seguridad, requiriendo nuevas pautas para su evaluación.
Aparte de esto, esta guÃa también incluye recomendaciones para la ejecución de pruebas de penetración (penetration testing) en estos nuevos entornos, en donde las herramientas y enfoques tradicionales pueden no aplicar totalmente.
Se trata de una guÃa indispensable que debe ser leÃda y analizada antes, durante y después de la implementación de nuevas tecnologÃas en la organización para confirmar que los controles de segmentación, aislamiento y filtrado están alineados con los requerimientos de PCI DSS para evitar riesgos vinculados con activos crÃticos no asegurados al no haber sido incluidos en el alcance de cumplimiento.
ES 
EN