Limita el alcance del cumplimiento de los entornos de PCI en Google Cloud

En este documento, se describen las prácticas recomendadas para diseñar tu entorno de nube para que cumpla con los requisitos del Consejo sobre Normas de Seguridad de la Industria de Tarjetas de Pago (PCI). Estas prácticas recomendadas son útiles para las organizaciones que migran o diseñan sistemas en la nube que están sujetos a los requisitos de cumplimiento de PCI. En este documento, se hace referencia a los requisitos de las PCI DSS 4.0 cuando corresponda.

Comprende el alcance de la evaluación de PCI DSS

Si tu organización participa en el comercio a través de Internet, debes respaldar y mantener el cumplimiento de PCI. La forma en que diseñas y administras tu entorno en la nube afecta el alcance de tus sistemas para la evaluación del Estándar de seguridad de datos (DSS) de PCI. El alcance tiene implicaciones importantes para la seguridad de tus recursos de TI y la capacidad de respaldar y mantener el cumplimiento de la PCI. Para asegurarte de que tu entorno de PCI tenga un alcance adecuado, debes comprender cómo lo afectan tus procesos empresariales y decisiones de diseño.

¿Qué es el alcance?

Todos los sistemas que almacenan, procesan o transmiten datos de titulares de tarjetas (CHD) están dentro del alcance de tu evaluación de PCI DSS. La seguridad es importante para todo tu entorno de nube, pero los ataques a los sistemas dentro del alcance pueden causar una violación de la seguridad de los datos y una exposición de los CHD.

En la figura 1, el entorno de datos del titulares de tarjetas (CDE), los sistemas conectados a este y los sistemas relacionados con la seguridad se encuentran dentro del límite del alcance de la evaluación, mientras que los sistemas no confiables y fuera del alcance están fuera del límite del alcance de la evaluación.

Según PCI DSS, los sistemas dentro del alcance son confiables. Los sistemas dentro del alcance incluyen tu CDE y cualquier sistema que esté conectado a tu CDE o que pueda generar un impacto en su seguridad.

Un sistema está conectado al entorno si está en la misma red, comparte bases de datos o almacenamiento de archivos, o tiene acceso o conectividad a cualquier sistema o proceso que reside en el CDE, pero no tiene acceso directo a los CHD.

Un sistema genera un impacto en la seguridad si al verse afectado permite que un atacante obtenga acceso al CDE. Todos los sistemas conectados al entorno y los sistemas relacionados con la seguridad siempre están dentro del alcance.

Los sistemas fuera del alcance no son de confianza por definición en PCI DSS y tienen valor cero para un atacante que quiere obtener acceso a los CHD o a datos de autenticación sensibles (SAD). Un sistema está fuera del alcance si no puede afectar la seguridad de un sistema dentro del alcance, incluso si el sistema fuera del alcance se ve comprometido. Si bien los sistemas fuera del alcance no se evalúan directamente, el Asesor de seguridad calificado de PCI (QSA) verifica que el alcance sea preciso y protege los CHD de acuerdo con PCI DSS. Por lo tanto, es importante que los límites de tu alcance estén bien protegidos, se supervisen de forma exhaustiva y se documenten con claridad.

Conexiones en el contexto de PCI

Varios requisitos de PCI DSS hacen referencia a conexiones, pero PCI DSS no define explícitamente las conexiones. Puedes interpretar el significado de las conexiones en este contexto si comprendes el árbol de decisión de los alcances de la Guía de PCI SSC para establecer alcance y segmentación de redes de PCI DSS (PDF).

Para evaluar tu alcance de PCI, se define una conexión según los siguientes elementos:

• Un transporte de información activo que conecta dos computadoras o sistemas
• Cuál de las dos partes inicia la llamada

Cuando documentas tu entorno, es mejor indicar claramente qué parte está autorizada para iniciar una conexión. Un firewall configurado para permitir el tráfico solo en una dirección puede implementar una conexión unidireccional. Por ejemplo, una aplicación de procesamiento de pagos dentro del alcance puede realizar consultas a un servidor de base de datos fuera del alcance sin que este último se coloque dentro del alcance si se cumplen las siguientes condiciones:

• La conexión y la base de datos fuera del alcance no almacenan, procesan ni transmiten CHD ni SAD.
• La base de datos se encuentra en una red independiente o está separada del CDE.
• La base de datos no puede iniciar llamadas al CDE de forma directa o indirecta.
• La base de datos no proporciona servicios de seguridad al CDE.
• La base de datos no afecta la configuración ni la seguridad del CDE.
• La base de datos admite los requisitos de PCI DSS.

En el siguiente diagrama, se muestran los factores que determinan el alcance del sistema:

En la figura 2, el alcance del sistema se determina de la siguiente manera:

• Componentes del sistema que están dentro del alcance de PCI DSS:

  • Sistemas que están en el CDE y que cumplen con una de las siguientes condiciones:
    • Un componente del sistema almacena, procesa o transmite CHD o SAD.
    • Un componente del sistema está en el mismo segmento de red, por ejemplo, en la misma subred o VLAN, que los sistemas que almacenan, procesan o transmiten CHD.
  • Sistemas que están conectados al entorno o que tienen algún impacto y que cumplen con una de las siguientes condiciones:
    • Un componente del sistema se conecta directamente con el CDE.
    • Un componente del sistema afecta la configuración o la seguridad del CDE.
    • Un componente del sistema segmenta los sistemas de CDE a partir de sistemas y redes fuera del alcance.
    • Un componente del sistema se conecta indirectamente con el CDE.
    • Un componente del sistema proporciona servicios de seguridad al CDE.
    • Un componente del sistema admite los requisitos de PCI DSS.

• Los componentes del sistema se pueden considerar no confiables y fuera del alcance de PCI DSS cuando todas las siguientes afirmaciones son verdaderas:

  • Un componente del sistema no almacena, procesa ni transmite CHD ni SAD.
  • Un componente del sistema no se encuentra en el mismo segmento de red, por ejemplo, en la misma subred o VLAN, como sistemas que almacenan, procesan o transmiten CHD o SAD.
  • Un componente del sistema no se puede conectar a ningún sistema del CDE.
  • Un componente del sistema no cumple con ninguno de los criterios para los sistemas conectados al entorno o los que afectan la seguridad.

  Los sistemas fuera del alcance pueden incluir sistemas que se conectan a un componente del sistema conectado al entorno o al que afecta la seguridad, en los que se usa el componente del sistema dentro del alcance a fin de implementan controles para evitar que el sistema fuera del alcance obtenga acceso al CDE.

En términos prácticos, la definición de PCI DSS del alcance del sistema puede implicar que el almacén de sesiones y la base de datos de comercio electrónico de tu aplicación web podrían calificarse como fuera del alcance si la segmentación se implementa y documenta de forma correcta. En el siguiente diagrama, se muestra cómo funcionan las conexiones de lectura y escritura entre los sistemas dentro del alcance y los sistemas fuera del alcance:

En la Figura 3, se muestran las siguientes conexiones:

• Solo lectura:
  • Una aplicación de procesamiento de pagos dentro del alcance lee un ID del carrito de una base de datos de carrito fuera del alcance y lee datos de un DNS y un NTP.
• Solo escritura:
  • Una aplicación de procesamiento de pagos dentro del alcance escribe en la base de datos principal de una aplicación fuera de alcance aplicación y en Cloud Logging.
  • La aplicación web principal fuera del alcance escribe datos en un servicio de registro. Estos datos no incluyen CHD ni SAD.
• Escritura y lectura:
  • Un usuario de la Web pública lee y escribe metadatos de solicitudes de la siguiente manera:
    • El usuario lee y escribe en una aplicación de procesamiento de pagos dentro del alcance. Estos metadatos de solicitudes son el ID del carrito y la clave de autenticación del carrito que contienen CHD y SAD.
    • El usuario lee y escribe en la aplicación web principal fuera del alcance. Estos metadatos de solicitud son un ID de sesión que no contiene CHD ni SAD.
  • La aplicación web principal fuera del alcance lee y escribe datos en una base de datos de carrito fuera del alcance, el almacén de sesiones y la base de datos principal de la aplicación. Estos datos no incluyen CHD ni SAD.
  • Una aplicación de procesamiento de pagos dentro del alcance lee y escribe datos en un servicio de asignación de token dentro del alcance y en un procesador de tarjeta de crédito en la Web pública. Estos datos incluyen CHD y SAD.

En la arquitectura de la figura 3, se describen dos aplicaciones web discretas: la aplicación web principal (aplicación principal), que está fuera del alcance de PCI, y la aplicación de procesamiento de pagos (aplicación de confirmación de la compra), que está dentro del alcance. En esta arquitectura, se puede iniciar una conexión entre dos entidades solo direcciones descritas en la lista anterior. Las conexiones entre entidades pueden ser de solo lectura, lectura y escritura, o solo escritura desde la perspectiva del emisor. Cualquier ruta o dirección de solicitud que no se describa de forma explícita se bloquea por la segmentación. Por ejemplo, la aplicación de procesamiento de pagos puede leer en la base de datos de carrito y escribir en el servicio de registro, lo que implica iniciar una conexión con esas entidades.

Los sistemas que están dentro del alcance suelen llamar a sistemas y servicios fuera del alcance. Estas conexiones permanecen seguras porque la segmentación impide que cualquier emisor remoto (que no sea un titular de tarjeta) inicie una conexión al CDE de manera directa o indirecta. En la figura 3, se muestra que la única ruta de acceso de entrada a la aplicación de confirmación de la compra es del usuario.

En la figura 3, ningún servicio o aplicación fuera del alcance proporciona datos de configuración o seguridad a la aplicación de procesamiento de pagos. Los datos fluyen a través de la arquitectura de la siguiente manera:

1. La aplicación principal reenvía al usuario a la aplicación de confirmación de la compra y usa un POST HTTP para transmitir el CartID y un validador llamado CartAuthKey. CartAuthKey es un hash del CartID y un secreto ya compartido que solo se conocen las aplicaciones principales y de confirmación de la compra.
2. La aplicación de confirmación de la compra valida al usuario mediante el hash del CartID y el secreto, y compara ese valor con CartAuthKey.
3. Una vez que los datos del usuario se autentican, se usa el CartID para leer el contenido del carrito desde la base de datos de carrito. Todos los datos de titulares de tarjetas se envían directamente desde usuario a la aplicación de confirmación de la compra.
4. Si se usan perfiles de pago, los datos de titulares de tarjetas se almacenan en el servicio de asignación de token.
5. Una vez que se procesa el pago, el resultado se inserta en la base de datos principal de la aplicación con una cuenta de servicio de base de datos de solo escritura.

Consideraciones sobre el alcance

En la Orientación para el alcance de PCI DSS y la segmentación de red, el Consejo sobre Normas de Seguridad de la PCI (SSC) recomienda que supongas que todo está dentro del alcance hasta que se compruebe lo contrario. Esta recomendación del SSC no significa que tu alcance debería ser lo más amplio posible. Más bien, significa que la QSA evalúa todos los sistemas como si fueran confiables, a menos que puedas demostrar que un sistema no tiene conectividad a tu CDE o que no afecta su seguridad. Para cumplir con los requisitos de cumplimiento de las normativas y mantener seguros los elementos de TI, debes definir el alcance de tu entorno de acuerdo con el principio de privilegio mínimo confiando en la menor cantidad posible de sistemas.

Antes de la evaluación, examina tu entorno para comprender y documentar el límite entre los sistemas que están dentro y fuera del alcance. La primera tarea del QSA es confirmar que tu alcance documentado encapsula razonablemente el CDE y los sistemas conectados. Como parte de la evaluación general, el QSA verifica que los sistemas fuera de alcance no puedan afectar de forma negativa a ningún sistema dentro del alcance.

Asegúrate de comprender las circunstancias especiales que son específicas de tu entorno, como las siguientes:

• Si recopilas datos del titular de la tarjeta por teléfono o a través de un sistema VOIP, considera los problemas de alcance adicionales que se describen en Protege los datos de tarjetas de pago obtenidos por teléfono (PDF).
• Si tu proveedor de servicios requiere acceso a tu CDE (PDF) para operar un sistema de punto de venta, el sistema que usa tu proveedor de servicios se puede considerar un sistema conectado al entorno. Esto podría requerir consideraciones adicionales sobre el alcance y la evaluación.

Las prácticas recomendadas de seguridad de Google pueden ayudarte a establecer y demostrar un límite claro y defendible entre los sistemas dentro del alcance y los que no son de confianza, lo que ayudará en tu evaluación. Cuando administras el acceso y la seguridad mediante la práctica de los principios de privilegio mínimo, ayudas a minimizar la cantidad de puntos de exposición de los datos de titulares de tarjetas, lo que minimiza la superficie de ataque de tu CDE y, en consecuencia, reduce tu alcance. Cuando reduces la huella de sistemas dentro del alcance, ayudas a reducir la complejidad del sistema y optimizar tu evaluación de PCI DSS.

Riesgos de un alcance incorrecto

Un alcance demasiado amplio puede generar evaluaciones costosas y mayores riesgos de cumplimiento. Para ayudar a mantener un alcance reducido, confía en la menor cantidad de sistemas posible y otorga acceso a solo unos pocos usuarios designados. A través de la evaluación diligente y la autoevaluación, puedes identificar los sistemas que no deben estar dentro del alcance de PCI DSS, verificar que cumplan con los lineamientos para sistemas fuera del alcance y reducir el alcance según corresponda. Este proceso de eliminación es la forma más segura de descubrir qué sistemas no son confiables y ayuda a garantizar que no puedan influir en los sistemas dentro del alcance.

Si necesitas una gran huella de infraestructura para cumplir con los requisitos de PCI DSS, puedes hacer que se incluyan sistemas externos al alcance de tu evaluación. Incluir sistemas externos en tu alcance implica riesgos para tu capacidad de cumplimiento. También puede degradar tu postura de seguridad general, mediante la ampliación de la superficie de ataque de tu entorno dentro del alcance confiable.

Un principio central de seguridad de red y PCI DSS es suponer que toda tu red o parte de ella ya está comprometida. Este principio se basa en el modelo de seguridad de confianza cero de Google, que rechaza la seguridad solo de perímetro en favor de un modelo en el que cada sistema es responsable de protegerse. El modelo de seguridad de Google está alineado con PCI DSS, que recomienda que el CDE y sus sistemas conectados se implementen en un espacio pequeño y confiable que se segmente desde tu entorno de TI más amplio y que no se mezcle con este.

En tu entorno de PCI dentro del alcance, no coloques tu CDE en un espacio de confianza grande y con un perímetro amplio. Hacer esto puede crear un sentido falso de seguridad y socavar una estrategia integral de defensa en profundidad. Si un atacante infringe la seguridad perimetral, puede operar con facilidad dentro de una intranet privada y de confianza. Considera maneras en las que puedas ajustar el espacio de confianza a fin de que contenga solo lo que necesita para operar y protegerse, y evitar depender solo de la seguridad perimetral. Si comprendes y sigues estos principios, puedes diseñar tu entorno de nube para proteger tus sistemas esenciales y reducir el riesgo de contaminación por los sistemas vulnerados.

Un entorno grande dentro del alcance con sistemas de confianza requiere un aparato de administración similar para mantener la supervisión, el mantenimiento, la auditoría y el inventario de estos sistemas de forma continua. La complejidad de la arquitectura del sistema, los procesos de administración de cambios y las políticas de control de acceso pueden crear riesgos de seguridad y cumplimiento. La dificultad en el mantenimiento de estos procesos de supervisión puede dar lugar a dificultades para cumplir con los requisitos de PCI DSS 10 y 11. Es importante comprender estos riesgos y, además, implementar estrategias para limitar el alcance de tu entorno evaluado. Para obtener más información, consulta Compatibilidad con el cumplimiento continuo más adelante en este documento.

Servicios de Google Cloud dentro del alcance de PCI DSS

Antes de comenzar a reducir el alcance de tu entorno de PCI, conoce qué servicios de Google Cloud están dentro del alcance de PCI DSS. Estos servicios proporcionan una infraestructura a partir de la cual puedes compilar tu propio servicio o aplicación que almacene, procese o transmita datos de titulares de tarjetas.

Estrategias para reducir el alcance

En esta sección, se analizan las siguientes estrategias para reducir el alcance de la evaluación: los controles de la jerarquía de recursos, la segmentación por Controles del servicio de VPC y la asignación de token. En lugar de elegir un enfoque, considera utilizar todas estas estrategias para maximizar la reducción potencial de tu alcance.

No hay una solución universal para el alcance de PCI. Es posible que ya uses una segmentación en una red local o una solución de procesamiento de tarjetas que pueda hacer que el diseño de tu infraestructura se vea distinto a lo descrito aquí. Usa estas estrategias como principios que puedes aplicar a tu propio entorno.

Establece controles de jerarquía de recursos

Los recursos de Google Cloud están organizados de manera jerárquica de la siguiente forma:

• El recurso de Organización es el nodo raíz en la jerarquía de recursos de Google Cloud. Los recursos de organización contienen carpetas y recursos de proyectos. Las políticas de control de acceso de la Identity and Access Management (IAM) que se aplican al recurso de organización se aplican en la jerarquía de todos los recursos de la organización.
• Las carpetas pueden contener proyectos y otras carpetas, y controlar el acceso a sus recursos mediante permisos de IAM a nivel de carpeta. Las carpetas suelen usarse para agrupar proyectos similares.
• Los proyectos son un límite de confianza para todos tus recursos y son un punto de aplicación de IAM.

A fin de reducir el alcance de tu evaluación, sigue las prácticas recomendadas de Google para definir la jerarquía de tus recursos. En la siguiente imagen, se muestra un ejemplo de jerarquía de recursos para el cumplimiento de PCI:

En la figura 4, todos los proyectos que están en el alcance de PCI se agrupan en una sola carpeta para aislarse a nivel de la carpeta. La carpeta con alcance de PCI contiene el CDE y otro proyecto que contiene servicios compartidos. Cuando implementas una jerarquía de recursos similar, la carpeta con alcance de PCI conforma una raíz lógica del alcance del cumplimiento de PCI. Si te aseguras de que solo los usuarios designados tengan acceso a esta carpeta y sus proyectos, puedes excluir del alcance de la evaluación otras carpetas, proyectos y recursos de tu jerarquía.

Cuando otorgas a los usuarios acceso solo a las carpetas y los proyectos que necesitan, según sea necesario, garantizas que solo los usuarios designados tengan acceso a los componentes dentro del alcance. Esto es compatible con los requisitos de PCI DSS 7.2 y 7.3 (PDF), entre otros. Para asegurarte de que los permisos para la organización y las carpetas superiores se configuren de forma correcta, debes comprender las implicaciones de la herencia de políticas. Para admitir el requisito de PCI DSS 8.4.1, asegúrate de aplicar la autenticación de varios factores (MFA) para usuarios designados y consulta la guía complementaria de PCI DSS que brinda orientación sobre la autenticación de varios factores (PDF). A fin de aplicar el cumplimiento en tu jerarquía de recursos, asegúrate de comprender cómo configurar restricciones de políticas de la organización. Estas restricciones admiten el cumplimiento continuo y pueden ayudarte a proteger tus entornos de confianza contra la elevación de privilegios.

Como todo cumplimiento de PCI, se requieren registros y supervisión adecuados de tu entorno y sus componentes con alcance para establecer un límite de alcance claro. La jerarquía de recursos está vinculada de forma indirecta con la administración de identidades y accesos, y se necesitan registro, auditoría y supervisión de las acciones de los usuarios eficaces para aplicar y mantener la separación.

Implementa la segmentación de red

La segmentación de red es un patrón de arquitectura importante que ayuda a proteger tu CDE y los sistemas conectados, como se describe en la guía complementaria de PCI SSC sobre la segmentación de red (PDF). Cuando se implementa de forma correcta, la segmentación de red reduce el alcance de la evaluación mediante la eliminación de las rutas de red que los sistemas no confiables podrían utilizar para acceder a tu CDE o a sus componentes conectados. Define solo las rutas necesarias para permitir la comunicación entre los componentes de confianza. Cuando los sistemas no confiables no tienen una ruta para enviar o recibir paquetes de sistemas confiables, los sistemas no confiables quedan fuera del alcance y no pueden afectar la seguridad de los componentes de tu alcance.

Para implementar la segmentación de red, coloca tu CDE en una nube privada virtual (VPC) dedicada con los Controles del servicio de VPC habilitados. Crea esta VPC en modo personalizado para garantizar que no se creen subredes o rutas innecesarias que habiliten el acceso predeterminado a redes confiables. Implementa restricciones de las políticas de la organización para asegurarte de que esta VPC no se pueda compartir con otros proyectos y que solo pueda intercambiar tráfico con otras redes de confianza.

En el siguiente diagrama, se muestra cómo se relaciona tu estrategia de segmentación de red con la jerarquía de recursos. En este diagrama representa una jerarquía de recursos con una sola carpeta para tu entorno de PCI dentro del alcance y dos proyectos en esa carpeta para el CDE y los servicios compartidos.

En la figura 5, el proyecto de servicios compartidos no forma parte del CDE, pero es un sistema conectado al entorno y, por lo tanto, está dentro del alcance de PCI. El balanceador de cargas restringe el acceso al CDE a nivel de la red mediante el balanceador de cargas y las reglas de firewall o políticas de firewall para proteger estas redes y cumplir con los requisitos de PCI DSS 1.2 y 1.3. El sistema de asignación de token y el sistema de pagos se colocan en subredes separadas, y su comunicación se rige por reglas de firewall entre cada subred para permitir solo las comunicaciones necesarias. Las funciones necesarias de registro, supervisión y alerta que cumplen con los requisitos 10.2, 10.4 y 10.5 de PCI DSS se encuentran en un proyecto aparte. Los servicios compartidos y el CDE se encuentran dentro de un perímetro de seguridad de los Controles del servicio de VPC para protegerse contra la configuración errónea o la vulneración de los controles de acceso de IAM.

Si tu implementación está en Google Kubernetes Engine (GKE), las siguientes son las formas en que puedes segmentar tu CDE y proteger los datos del titulares de tarjetas de los sistemas que no son de confianza:

• Los espacios de nombres ofrecen una capa adicional de aislamiento de control de acceso en la que los usuarios pueden tener acceso solo a ciertos pods, servicios e implementaciones de tu clúster de Kubernetes. Esto es útil para proporcionar un acceso más detallado a los usuarios designados.
• Las políticas de red pueden aislar pods y servicios entre sí para restringir los flujos de datos y proporcionar una capa adicional de segmentación de red dentro de tu clúster.
• PodSecurity es un controlador de admisión de Kubernetes que te permite aplicar Estándares de seguridad de Pods a los Pods que se ejecutan en tus clústeres de GKE.

Cada una de estas capas constituye una parte importante de tu seguridad en profundidad y ayuda a limitar tu alcance mediante el aislamiento y la protección de los componentes de confianza del entorno circundante. Si quieres implementar todo tu CDE o parte de él con Kubernetes, obtén más información sobre cómo ejecutar tu entorno que cumple con PCI en GKE.

Implementa la asignación de token

La asignación de token es el proceso de ocultamiento irreversible de un número de cuenta principal (PAN). Un PAN con asignación de token o token no se puede canjear para un PAN con medios matemáticos. PCI SSC ofrece orientación sobre el impacto de la asignación de tokens en el Capítulo 3 de la guía complementaria sobre los lineamientos de la asignación de token (PDF). El conjunto de componentes que almacenan y transmiten datos del titulares de tarjetas influyen fuertemente en el alcance de PCI DSS. Cuando se implementa correctamente, la asignación de token puede ayudar a reducir el alcance de la evaluación, ya que minimiza la aparición y la transmisión de los números de cuenta principal.

La asignación de token también es una forma de segmentación por flujo de datos, porque separa los sistemas que almacenan y transmiten datos de titulares de tarjetas de los que pueden realizar operaciones solo con tokens. Por ejemplo, es posible que los sistemas que analizan las actividades de los consumidores en busca de fraudes no necesiten PAN, y que puedan ejecutar estos análisis con datos con asignación de token. La asignación de token también agrega una capa de separación entre los sistemas que almacenan y transmiten PAN y tu aplicación web de comercio electrónico. Cuando tu aplicación web solo interactúa con sistemas que usan tokens, la aplicación web puede quitarse del conjunto de sistemas conectados al entorno, lo que reduce el alcance.

El siguiente diagrama muestra cómo los CHD, un PAN y los datos con asignación de token se manejan en un sistema típico de asignación de token:

En la figura 6, se recibe un PAN y otros datos de titular de tarjeta del usuario y, luego, estos se envían de inmediato al servicio de asignación de token. El servicio de asignación de tokens encripta el PAN, genera un token y, luego, los almacena en un almacén de tokens seguro. Solo los servicios designados, como el servicio de pago, pueden acceder al almacén en la red y están autorizados para canjear un PAN mediante el uso de un token generado. El servicio de pago solo usa el PAN para enviarlo al procesador de pagos. Ni el PAN ni ningún otro dato del titular de la tarjeta se producen fuera de este flujo de datos muy controlado. Como parte de una estrategia de defensa en profundidad, la arquitectura también usa la Protección de datos sensibles como otra capa de defensa contra filtraciones involuntarias de números PAN o de otros datos de titulares de tarjetas.

En la figura 6, el sistema de asignación de tokens usa Hashicorp Vault, un almacén de secretos muy protegido, para administrar las asignaciones de PAN a token. Solo los usuarios y servicios autorizados pueden canjear un PAN de un token mediante un proceso de búsqueda. Los componentes que están autorizados a acceder al almacén de tokens pueden obtener acceso restringido para que el componente solo pueda canjear un PAN durante el período específico que necesite para llevar a cabo su función. Otros almacenes de datos también pueden ser apropiados según los requisitos de tu empresa.

Arquitectura de ejemplo

En el siguiente diagrama, se ilustra un ejemplo de arquitectura para procesar transacciones con asignación de token mediantePub/Sub yDataflow, y para almacenar registros de transacciones con asignación de token enSpanner.

En la figura 7, el proyecto de procesamiento de transacciones es un sistema conectado al entorno y está dentro del alcance de PCI. No afecta a la seguridad, porque la vulneración de los componentes del proyecto de procesamiento de transacciones no proporciona a los atacantes acceso a los CHD. El proyecto de aplicación web está fuera del alcance, ya que no se conecta al CDE y solo interactúa con datos limpios.

Los datos con asignación de token se envían del CDE a Pub/Sub. Antes de que los datos con asignación de token se publiquen para otros suscriptores, la Protección de datos sensibles verifica que no contengan CHD. Dataflow procesa los datos con asignación de token que se almacenan en la base de datos de transacciones de Spanner. Las transacciones se pueden asociar con usuarios específicos mediante tokens sin acceder a los PAN. La base de datos de transacciones de Spanner también se puede usar para generar informes y análisis mediante herramientas de inteligencia empresarial (IE), como Looker.

Asistencia para el cumplimiento continuo

La seguridad y el cumplimiento son más que una arquitectura correcta y una buena ingeniería. Una arquitectura correcta puede mostrar que tu entorno está diseñado de manera segura según la teoría. También necesitas procesos de auditoría, registro, supervisión y solución eficaces para garantizar que tu entorno permanezca seguro en la práctica.

Para respaldar el cumplimiento de cada una de las 12 categorías de requisitos de PCI DSS, debes supervisar la implementación de ese requisito de manera continua. Debes demostrarte a ti mismo y a tu evaluador que todos los componentes dentro del alcance permanecerán seguro en el futuro, mucho después de que se complete la evaluación de PCI DSS. La combinación de una supervisión adecuada y acciones inmediatas para brindar soluciones se llama cumplimiento continuo. El cumplimiento continuo es un requisito de PCI DSS y, cuando se implementa de manera correcta, puede maximizar el efecto de las otras estrategias de reducción de alcance.

Google Cloud te permite registrar todo lo que ocurre en tu red con los registros de reglas de firewall, los registros de flujo de VPC, los registros de Controles del servicio de VPC y los registros de Cloud Load Balancing. Puedes supervisar la actividad de tus sistemas y usuarios mediante los registros de auditoría de Cloud. La supervisión periódica de estos registros te ayuda a cumplir con el Requisito 10.4 de PCI DSS y te permite responder y solucionar con rapidez las posibles amenazas a la seguridad. Para obtener más información, consulta la guía complementaria de PCI DSS sobre la supervisión diaria de registros (PDF).

Security Command Center te permite comprender la superficie de ataque de datos y tu seguridad, ya que brinda un inventario, un descubrimiento, una búsqueda y una administración de recursos. Security Command Center puede analizar los resultados de análisis de la Protección de datos sensibles para identificar los datos de titulares de tarjetas que se filtraron y ayudar a verificar que el sistema de asignación de tokens no se esté usando de forma inadecuada para canjear números PAN de forma maliciosa. Con Event Threat Detection, Security Command Center puede ayudarte a detectar de forma proactiva amenazas y actividades inusuales en tu red y en tus VM, que podrían indicar que un atacante sondea tu sistema para que identificar sus capacidades defensivas. Security Command Center también te permite crear fuentes de seguridad personalizadas que son específicas de tu entorno.

Google Cloud Armor puede proporcionar protección adicional para tus aplicaciones web públicas de Google Cloud y ayudarte a cumplir con el requisito 6.4 del PCI DSS. Google Cloud Armor evalúa las solicitudes entrantes teniendo en cuenta una variedad de ataques web comunes y puede ayudarte a evitar revisiones de código manuales laboriosas que se especifican en el requisito 6.4. Tener un WAF implementado te ayuda a mantener el cumplimiento continuo y reduce los costos y riesgos del cumplimiento en curso.

¿Qué sigue?

• Revisa las prácticas recomendadas para administrar las obligaciones de cumplimiento.
• Lee el cumplimiento estándar de seguridad de datos de PCI en Google Cloud.
• Orientación acerca de PCI sobre el alcance de PCI DSS y la segmentación de red (PDF).
• Prueba el plano de PCI en GKE.
• Protege las cargas de trabajo de Kubernetes para PCI DSS.
• Implementa el proyecto de PCI Starter de Terraform.
• Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.