PCI DSS 4.0 en la nube: la única estrategia que funciona es reducir el alcance

PCI DSS tiene unos 300 requisitos y aplican a cada componente del entorno de datos de titulares de tarjeta, más a cada sistema conectado a él, más a cada sistema que pueda afectar a su seguridad. Esa última cláusula es la que convierte una funcionalidad de pago en un proyecto de toda la empresa.

Así que el primer trabajo, y el más valioso, no es implantar controles. Es decidir qué está en alcance, y después hacer ese conjunto lo más pequeño posible.

La pregunta de alcance, con precisión

Un sistema está en alcance si almacena, procesa o transmite datos de titular de tarjeta; si está en el mismo segmento de red que algo que lo hace; o si puede afectar a la seguridad del entorno de datos de tarjeta, lo que incluye tu proveedor de identidad, tu sistema de CI, tu monitorización, tus bastiones y cualquier cosa con acceso administrativo.

Esa última categoría sorprende. Tu pipeline de CI despliega en el servicio de pagos, luego tu pipeline de CI está en alcance. Tu SSO controla quién puede entrar, luego está en alcance. El agente de monitorización que corre en los servidores de pago está en alcance.

Cuando ves esto, la estrategia se vuelve obvia: saca los datos de tarjeta de tus sistemas por completo y aísla lo que quede.

Sacar alcance: los tres movimientos que importan

Una página de pago alojada o campos alojados. Si los datos de tarjeta van del navegador del cliente directamente al proveedor de pago y nunca tocan tu infraestructura, tu validación baja a SAQ A: un puñado de requisitos sobre tu web, la integridad de la redirección y la gestión de proveedores. Es la mayor reducción disponible y es una decisión de arquitectura, no de seguridad.

Ten en cuenta que PCI DSS 4.0 añadió los requisitos 6.4.3 y 11.6.1 sobre scripts en páginas de pago y detección de cambios en ellos, motivados por los ataques de robo de tarjeta en el navegador. Incluso SAQ A tiene más trabajo que antes: necesitas un inventario de los scripts de la página de pago, justificación de cada uno y un mecanismo para detectar cambios no autorizados.

Tokenización. Si necesitas tarjeta guardada para pagos recurrentes, almacena el token del proveedor, no la tarjeta. Un token que es inútil fuera de tu cuenta de comercio no es dato de titular de tarjeta, y la base de datos que lo guarda queda fuera de alcance.

Segmentación de red. Para lo que quede, segméntalo de verdad: una cuenta o suscripción cloud separada, no un grupo de seguridad. Las fronteras entre cuentas son más fáciles de evidenciar ante un evaluador que las reglas dentro de una VPC, y evitan la expansión gradual de alcance que ocurre cuando alguien pone un servicio "temporal" en la subred equivocada. Si usas la segmentación para reducir alcance, hay que probarla anualmente (cada seis meses para proveedores de servicio), así que haz que sea una frontera simple de describir y de probar.

Qué cambió en 4.0 y afecta a equipos cloud

Los requisitos de 4.0 pasaron a ser obligatorios el 31 de marzo de 2025, tras una transición larga. Los que dan trabajo de forma fiable:

Requisito 8.3.6: contraseñas de 12 caracteres mínimo con complejidad, donde se usen contraseñas. Muchas cuentas de servicio heredadas no lo cumplen.

Requisito 8.4.2: MFA para todo acceso al entorno de datos de tarjeta, no solo administrativo y no solo remoto. Es más amplio de lo que exigía 3.2.1 y a menudo obliga a rehacer el acceso entre servicios.

Requisito 8.6: las cuentas usadas por aplicaciones y sistemas necesitan credenciales gestionadas y rotadas, con justificación para el uso interactivo. En términos cloud: federación de identidad de carga de trabajo en vez de claves estáticas.

Requisito 12.3.1: un análisis de riesgo dirigido para cada requisito que permita flexibilidad en la frecuencia. Si eliges hacer algo trimestralmente en vez de mensualmente, necesitas un análisis documentado que lo justifique. Es papeleo nuevo pegado a muchos controles existentes.

Requisito 11.6.1: detección de cambios y manipulación en páginas de pago, como arriba.

El enfoque personalizado. La 4.0 permite cumplir el objetivo de un requisito por otros medios, con análisis de riesgo documentado y evidencia de eficacia, acordado con tu evaluador. Es genuinamente útil para arquitecturas cloud-native donde el control prescriptivo asume un servidor en el que puedes iniciar sesión. También cuesta más tiempo de evaluador, así que úsalo donde importe y no en todas partes.

Responsabilidad compartida, documentada por servicio

La Atestación de Cumplimiento PCI DSS de tu proveedor cloud cubre su infraestructura y unos servicios concretos. Heredas esos controles, pero tienes que documentar cuáles, para qué servicios, y confirmar que el servicio está en el alcance PCI del proveedor: no todos lo están, y la lista cambia.

Guarda la matriz de responsabilidad del proveedor junto a tu propia documentación y revísala en cada evaluación anual. Un evaluador preguntará qué controles consideras heredados y esperará que la atestación respalde esa afirmación para los servicios y regiones concretos que usas.

La secuencia práctica

Mapea primero el flujo de datos de tarjeta, en un único diagrama, incluyendo el navegador. Después quita lo que puedas: campos alojados, tokenización, borrar datos históricos de tarjeta que nunca necesitaste. Después segmenta lo que quede. Y entonces, solo entonces, recorre los requisitos para el entorno mucho más pequeño que sobrevive.

Los equipos que lo hacen al revés —implantar 300 requisitos por todo el entorno y descubrir después que podrían haber usado una página de pago alojada— gastan un año en un proyecto que podía haber sido un trimestre. La disciplina de evidencia es la misma que en cualquier otro marco, así que un programa existente de ISO 27001 o SOC 2 aligera bastante el trabajo restante.