Limitar el ámbito de 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 de forma que cumpla los requisitos del Consejo de Estándares de Seguridad del Sector de las Tarjetas de Pago (PCI). Estas prácticas recomendadas son útiles para las organizaciones que están migrando o diseñando sistemas en la nube que están sujetos a los requisitos de cumplimiento del PCI. En este documento se hace referencia a los requisitos de PCI DSS 4.0 cuando procede.

Información sobre el ámbito de la evaluación PCI DSS

Si tu organización realiza transacciones comerciales a través de Internet, debes cumplir y mantener los requisitos de PCI. La forma en que diseñes y gestiones tu entorno de nube afectará al ámbito de tus sistemas en la evaluación del estándar de seguridad de datos para el sector de las tarjetas de pago (PCI DSS). El ámbito tiene implicaciones importantes para la seguridad de tus recursos de TI y tu capacidad para mantener y cumplir el estándar PCI. Para asegurarte de que tu entorno de PCI tiene el ámbito adecuado, debes saber cómo influyen en él tus procesos empresariales y tus decisiones de diseño.

¿Qué es el ámbito?

Todos los sistemas que almacenan, procesan o transmiten datos de titulares de tarjetas (CHD) están incluidos en tu evaluación de PCI DSS. La seguridad es importante para todo tu entorno de nube, pero si se vulneran los sistemas incluidos en el ámbito, se puede producir una brecha de seguridad de los datos y una exposición de la información de las tarjetas.

En la figura 1, el entorno de datos de los titulares de las tarjetas (CDE), los sistemas conectados y los sistemas que afectan a la seguridad se encuentran dentro del límite del ámbito de la evaluación, mientras que los sistemas no fiables y fuera del ámbito se encuentran fuera del límite del ámbito de la evaluación.

Según PCI DSS, los sistemas incluidos en el ámbito de aplicación son de confianza. Los sistemas incluidos en el ámbito de aplicación son tu CDE y cualquier sistema que esté conectado a él o que pueda afectar a su seguridad.

Un sistema está conectado si se encuentra en la misma red, comparte bases de datos o almacenamiento de archivos, o bien tiene acceso o conectividad a cualquier sistema o proceso que resida en el CDE, pero no tiene acceso directo a los datos de las tarjetas.

Un sistema tiene un impacto en la seguridad si, en caso de verse comprometido, puede permitir que un atacante obtenga acceso al CDE. Todos los sistemas conectados y que afecten a la seguridad siempre están incluidos.

Los sistemas fuera del ámbito de aplicación no son de confianza por definición en PCI DSS y no tienen ningún valor para un atacante que quiera acceder a la información de los titulares de las tarjetas o a datos de autenticación sensibles. Un sistema está fuera del ámbito si no puede afectar a la seguridad de un sistema incluido en el ámbito, aunque el sistema fuera del ámbito esté en peligro. Aunque los sistemas que no están incluidos en el ámbito no se evalúan directamente, el evaluador de seguridad cualificado (QSA) del PCI verifica que el ámbito sea preciso y proteja los datos de las tarjetas de pago de acuerdo con el PCI DSS. Por lo tanto, es importante que los límites de tu ámbito estén bien protegidos, que se monitoricen de forma continua y exhaustiva, y que se documenten claramente.

Conexiones en el contexto de PCI

En varios requisitos de PCI DSS se hace referencia a las conexiones, pero no se definen explícitamente. Para interpretar el significado de las conexiones en este contexto, consulta el árbol de decisiones de alcance en la guía del PCI SSC sobre el alcance y la segmentación de redes de PCI DSS (PDF).

Para evaluar el ámbito de PCI, una conexión se define de la siguiente manera:

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

Cuando documentes tu entorno, es mejor que indiques claramente qué parte está autorizada para iniciar una conexión. Un cortafuegos configurado para permitir el tráfico solo en una dirección puede establecer una conexión unidireccional. Por ejemplo, una aplicación de procesamiento de pagos que esté en el ámbito puede hacer consultas a un servidor de bases de datos que no esté en el ámbito sin que este último entre en el ámbito si se cumplen todas las condiciones siguientes:

• La conexión y la base de datos fuera del ámbito no almacenan, procesan ni transmiten datos de salud confidenciales ni datos personales sensibles.
• La base de datos está en una red independiente o está segmentada de otro modo de la CDE.
• La base de datos no puede iniciar ninguna llamada a la CDE de forma directa ni indirecta.
• La base de datos no proporciona servicios de seguridad al CDE.
• La base de datos no afecta a la configuración ni a la seguridad del CDE.
• La base de datos cumple los requisitos del PCI DSS.

En el siguiente diagrama se muestran los factores que determinan el ámbito del sistema:

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

• Componentes del sistema que están en el ámbito del PCI DSS:

  • Sistemas que se encuentran en el CDE y para los que se cumple una de las siguientes condiciones:
    • Un componente del sistema almacena, procesa o transmite datos de salud protegidos o datos de salud sensibles.
    • Un componente del sistema se encuentra en el mismo segmento de red (por ejemplo, en la misma subred o VLAN) que los sistemas que almacenan, tratan o transmiten datos de titulares de tarjetas.
  • Sistemas conectados o que influyen en la seguridad en los que se cumple una de las siguientes condiciones:
    • Un componente del sistema se conecta directamente a CDE.
    • Un componente del sistema afecta a la configuración o la seguridad del CDE.
    • Un componente del sistema segmenta los sistemas CDE de los sistemas y las redes que no están incluidos en el ámbito.
    • Un componente del sistema se conecta indirectamente a CDE.
    • Un componente del sistema proporciona servicios de seguridad al CDE.
    • Un componente del sistema cumple los requisitos del PCI DSS.

• Los componentes del sistema se pueden considerar no fiables y fuera del ámbito del estándar 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 está en el mismo segmento de red (por ejemplo, en la misma subred o VLAN) que los sistemas que almacenan, tratan o transmiten datos de titulares de tarjetas o datos sensibles de autenticación.
  • Un componente del sistema no puede conectarse a ningún sistema del CDE.
  • Un componente del sistema no cumple ningún criterio para conectarse a sistemas que afecten a la seguridad.

  Los sistemas fuera del ámbito pueden incluir sistemas que se conecten a un componente del sistema conectado o que afecte a la seguridad, en los que se hayan implementado controles para evitar que el sistema fuera del ámbito obtenga acceso al CDE mediante el componente del sistema dentro del ámbito.

En la práctica, la definición de ámbito del sistema del PCI DSS puede significar que el almacén de sesiones y la base de datos de comercio electrónico de su aplicación web pueden considerarse fuera del ámbito si la segmentación se implementa y documenta correctamente. En el siguiente diagrama se muestra cómo funcionan las conexiones de lectura y escritura entre sistemas incluidos y no incluidos en el ámbito:

En la figura 3 se muestran las siguientes conexiones:

• Solo lectura:
  • Una aplicación de procesamiento de pagos incluida en el ámbito lee un ID de carrito de una base de datos de carritos no incluida en el ámbito y lee datos de un DNS y un NTP.
• Solo escritura:
  • Una aplicación de tratamiento de pagos incluida en el ámbito escribe en la base de datos principal de una aplicación que no está incluida en el ámbito y en Cloud Logging.
  • La aplicación web principal fuera del ámbito escribe datos en un servicio de registro. Estos datos no incluyen la cardiopatía ni el trastorno afectivo estacional.
• Lectura y escritura:
  • Un usuario de la Web pública lee y escribe metadatos de solicitud de la siguiente manera:
    • El usuario lee y escribe en una aplicación de procesamiento de pagos incluida en el ámbito. Estos metadatos de la solicitud son el ID del carrito y la clave de autenticación del carrito, que contienen datos de la tarjeta y datos sensibles.
    • El usuario lee y escribe en la aplicación web principal fuera del ámbito. Estos metadatos de solicitud son un ID de sesión que no contiene CHD ni SAD.
  • La aplicación web principal fuera del ámbito lee y escribe datos en una base de datos de carrito, un almacén de sesiones y una base de datos principal de la aplicación fuera del ámbito. Estos datos no incluyen la cardiopatía ni el trastorno afectivo estacional.
  • Una aplicación de procesamiento de pagos incluida en el ámbito lee y escribe datos en un servicio de tokenización de tarjetas incluido en el ámbito y en un procesador de tarjetas de crédito en la Web pública. Estos datos incluyen la cardiopatía coronaria y el trastorno afectivo estacional.

La arquitectura de la figura 3 describe dos aplicaciones web independientes: la aplicación web principal (aplicación principal), que está fuera del ámbito de PCI, y la aplicación de procesamiento de pagos (aplicación de compra), que sí está incluida. En esta arquitectura, solo se puede iniciar una conexión entre dos entidades en las direcciones descritas en la lista anterior. Las conexiones entre entidades pueden ser de solo lectura, de lectura y escritura, o de solo escritura desde la perspectiva de la persona que llama. La segmentación bloquea cualquier ruta o dirección de solicitud que no se describa explícitamente. Por ejemplo, la aplicación de procesamiento de pagos puede leer de la base de datos del carrito y escribir en el servicio de registro, lo que implica iniciar una conexión con esas entidades.

Los sistemas incluidos en el ámbito suelen llamar a sistemas y servicios que no están incluidos. Estas conexiones siguen siendo seguras porque la segmentación impide que cualquier persona que llame de forma remota (que no sea el titular de la tarjeta) inicie una conexión con el CDE de forma directa o indirecta. En la figura 3 se muestra que la única ruta de entrada a la aplicación de tramitación de la compra es la del usuario.

En la figura 3, ningún servicio ni aplicación fuera del ámbito proporciona datos de configuración ni de 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 tramitación de la compra y usa un POST HTTP para transmitir el CartID y un validador llamado CartAuthKey. El CartAuthKey es un hash del CartID y un secreto precompartido que solo conocen las aplicaciones principal y de pago.
2. La aplicación de tramitación de la compra valida al usuario cifrando el CartID junto con el secreto y comparando ese valor con el CartAuthKey.
3. Una vez que se autentican los datos del usuario, se usa el CartID para leer el contenido del carrito de la base de datos del carrito. Todos los datos del titular de la tarjeta se envían directamente del usuario a la aplicación de pago.
4. Si se usan perfiles de pagos, los datos del titular de la tarjeta se almacenan en el servicio de tokenización.
5. Una vez procesado el pago, el resultado se inserta en la base de datos de la aplicación principal con una cuenta de servicio de base de datos de solo escritura.

Consideraciones sobre el ámbito

En la guía sobre el alcance y la segmentación de redes de PCI DSS, el consejo sobre Normas de Seguridad del PCI (SSC) recomienda que suponga que todo está incluido en el ámbito hasta que se verifique lo contrario. Esta recomendación de SSC no significa que debas hacer que tu ámbito sea lo más amplio posible. Más bien, significa que el evaluador de seguridad cualificado evalúa todos los sistemas como si fueran de confianza, a menos que puedas demostrar que un sistema no tiene conectividad con tu entorno de datos de las tarjetas o no afecta a su seguridad. Para cumplir los requisitos normativos y proteger tus recursos de TI, debes definir el ámbito de tu entorno de acuerdo con el principio de mínimos accesos, confiando en el menor número de sistemas posible.

Antes de realizar la evaluación, evalúa tu entorno para identificar y documentar el límite entre los sistemas incluidos y los no incluidos. La primera tarea del evaluador de seguridad cualificado es confirmar que el ámbito documentado abarca razonablemente el CDE y los sistemas conectados. Como parte de la evaluación general, el evaluador de seguridad cualificado verifica que los sistemas que no están incluidos en el ámbito no puedan afectar negativamente a los que sí lo están.

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

• Si recoges datos de titulares de tarjetas por teléfono o a través de un sistema VoIP, ten en cuenta los problemas de alcance adicionales que se describen en el documento Protección de datos de tarjetas de pago por teléfono (PDF).
• Si tu proveedor de servicios necesita acceder a tu CDE (PDF) para operar un sistema de punto de venta, el sistema que utilice tu proveedor de servicios se puede considerar un sistema conectado. Esto puede requerir consideraciones adicionales sobre el alcance y la diligencia debida.

Las prácticas recomendadas de seguridad de Google pueden ayudarte a establecer y demostrar un límite claro y defendible entre los sistemas incluidos y los no fiables, lo que te ayudará en tu evaluación. Si gestionas el acceso y la seguridad aplicando el principio de mínimos accesos, reduces el número de puntos de exposición de los datos de los titulares de las tarjetas, minimizas la superficie de ataque de tu CDE y, por lo tanto, reduces el alcance. Al reducir la superficie de los sistemas incluidos en el ámbito, se reduce la complejidad del sistema y se agiliza la evaluación de cumplimiento de PCI DSS.

Riesgos de un ámbito incorrecto

Un ámbito demasiado amplio puede dar lugar a evaluaciones costosas y a un aumento de los riesgos de cumplimiento. Para mantener un ámbito reducido, confía en el menor número de sistemas posible y concede acceso solo a unos pocos usuarios designados. Mediante una evaluación diligente y una autoevaluación, puede identificar los sistemas que no deberían estar incluidos en el ámbito de la norma PCI DSS, verificar que cumplen las directrices de los sistemas fuera del ámbito y reducir el ámbito en consecuencia. Este proceso de eliminación es la forma más segura de descubrir qué sistemas no son de confianza y de asegurarse de que no puedan afectar a los sistemas incluidos en el ámbito.

Si necesitas una gran infraestructura para cumplir los requisitos de PCI DSS, puedes hacer que se incluyan sistemas ajenos en el ámbito de tu evaluación. Si incluyes sistemas ajenos en tu ámbito, se corre el riesgo de no poder cumplir los requisitos. También puede empeorar tu estrategia de seguridad general al ampliar la superficie de ataque de tu entorno de confianza.

Un principio fundamental de la seguridad de redes y del PCI DSS es asumir que parte o la totalidad de tu red ya se ha visto comprometida. Este principio se recoge en el modelo de seguridad de confianza cero de Google, que rechaza la seguridad basada únicamente en el perímetro y apuesta por un modelo en el que cada sistema es responsable de protegerse a sí mismo. El modelo de seguridad de Google se ajusta al estándar PCI DSS, que recomienda que el CDE y sus sistemas conectados se implementen en un espacio pequeño y de confianza que esté segmentado del entorno de TI más amplio y no se mezcle con él.

En tu entorno de PCI, no coloques tu CDE en un espacio grande y de confianza con un perímetro amplio. Si lo haces, puedes crear una falsa sensación de seguridad y debilitar una estrategia de defensa reforzada integral. Si un atacante vulnera la seguridad del perímetro, puede operar con facilidad dentro de una intranet privada y de confianza. Piensa en cómo puedes reducir el espacio de confianza para que solo contenga lo que necesita para funcionar y protegerse, y evita depender únicamente de la seguridad perimetral. Si entiendes y sigues estos principios, podrás diseñar tu entorno de nube para proteger tus sistemas críticos y reducir el riesgo de contaminación de sistemas vulnerados.

Un entorno de gran tamaño y dentro del ámbito de sistemas de confianza requiere un aparato de gestión de tamaño similar para mantener la monitorización, el mantenimiento, la auditoría y el inventario continuos de estos sistemas. La complejidad de la arquitectura del sistema, los procesos de gestión de cambios y las políticas de control de acceso pueden generar riesgos de seguridad y cumplimiento. Si no se mantienen estos procesos de monitorización, puede resultar difícil cumplir los requisitos 10 y 11 del PCI DSS. Es importante conocer estos riesgos e implementar estrategias para limitar el alcance del entorno evaluado. Para obtener más información, consulta la sección Admite el cumplimiento continuo más adelante en este documento.

Google Cloud servicios incluidos en el PCI DSS

Antes de empezar a reducir el ámbito de tu entorno de PCI, debes saber qué Google Cloud servicios están incluidos en el PCI DSS. Estos servicios proporcionan una infraestructura en la que puede crear su propio servicio o aplicación que almacene, trate o transmita datos de titulares de tarjetas.

Estrategias para reducir el alcance

En esta sección se describen las siguientes estrategias para reducir el ámbito de la evaluación: controles de jerarquía de recursos, segmentación de Controles de Servicio de VPC y tokenización. En lugar de elegir un solo método, te recomendamos que apliques todas estas estrategias para maximizar la reducción del ámbito potencial.

No hay una solución universal para el ámbito de PCI. Es posible que ya tengas una segmentación en una red local o una solución de procesamiento de tarjetas que haga que el diseño de tu infraestructura sea algo diferente al que se describe aquí. Usa estas estrategias como principios que puedes aplicar a tu propio entorno.

Establecer controles de jerarquía de recursos

LosGoogle Cloud recursos se organizan jerárquicamente de la siguiente manera:

• El recurso de organización es el nodo raíz de la jerarquía de recursos de Google Cloud . Los recursos de organización contienen recursos de carpetas y proyectos. Las políticas de control de acceso de Gestión de Identidades y Accesos (IAM) aplicadas al recurso Organization se aplican en toda la jerarquía a todos los recursos de la organización.
• Las carpetas pueden contener proyectos y otras carpetas, así como controlar el acceso a sus recursos mediante permisos de gestión de identidades y accesos a nivel de carpeta. Las carpetas se suelen usar para agrupar proyectos similares.
• Los proyectos son un límite de confianza para todos tus recursos y un punto de aplicación de gestión de identidades y accesos.

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

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

Si solo das acceso a los usuarios a las carpetas y los proyectos que necesiten, te asegurarás de que solo los usuarios designados tengan acceso a los componentes incluidos en el ámbito. De esta forma, se cumplen los requisitos 7.2 y 7.3 de PCI DSS (PDF), entre otros. Para asegurarte de que los permisos de la organización superior y de las carpetas se han configurado correctamente, consulta las implicaciones de la herencia de políticas. Para cumplir el requisito 8.4.1 del PCI DSS, aplica la autenticación multifactor (MFA) a los usuarios designados y consulta el suplemento del PCI DSS sobre la autenticación multifactor (PDF). Para aplicar el cumplimiento en tu jerarquía de recursos, asegúrate de saber cómo definir restricciones de políticas de la organización. Estas restricciones admiten el cumplimiento continuo y pueden ayudar a proteger tus entornos de confianza frente a la escalada de privilegios.

Al igual que con todos los requisitos de cumplimiento de PCI, es necesario registrar y monitorizar adecuadamente tu entorno y sus componentes incluidos en el ámbito para establecer un límite claro. La jerarquía de recursos está intrínsecamente relacionada con la gestión de identidades y accesos, y es necesario registrar, auditar y monitorizar de forma eficaz las acciones de los usuarios para aplicar y mantener la separación.

Implementar la segmentación de red

La segmentación de la red es un patrón de arquitectura importante que ayuda a proteger tu CDE y los sistemas conectados, tal como se describe en la guía complementaria sobre segmentación de redes (PDF) del PCI SSC. Si se implementa correctamente, la segmentación de la red reduce el ámbito de la evaluación, ya que elimina las rutas de red que los sistemas no fiables podrían usar para acceder a tu CDE o a sus componentes conectados. Define solo las rutas necesarias para permitir la comunicación entre componentes de confianza. Cuando los sistemas no fiables no tienen una ruta por la que enviar o recibir paquetes de sistemas fiables, los sistemas no fiables quedan fuera del ámbito y no pueden afectar a la seguridad de los componentes incluidos en el ámbito.

Para implementar la segmentación de la red, coloca tu CDE en una nube privada virtual (VPC) dedicada con controles de servicio de VPC habilitados. Crea esta VPC en modo personalizado para asegurarte de que no se creen subredes ni rutas extrañas que puedan habilitar el acceso predeterminado a redes de confianza. Implementa restricciones de políticas de la organización para asegurarte de que esta VPC no se pueda compartir con otros proyectos y solo se pueda emparejar con otras redes de confianza.

En el siguiente diagrama se muestra cómo se relaciona estrechamente tu estrategia de segmentación de red con tu jerarquía de recursos. En este diagrama se presupone una jerarquía de recursos con una sola carpeta para tu entorno PCI incluido en el ámbito 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 y, por lo tanto, está incluido en el ámbito del PCI. El acceso al CDE está restringido a nivel de red por el balanceador de carga y las reglas de cortafuegos o las políticas de cortafuegos para proteger estas redes y cumplir los requisitos 1.2 y 1.3 de PCI DSS. El sistema de tokenización y el sistema de pago se colocan en subredes independientes, y su comunicación se rige por reglas de firewall entre cada subred para permitir solo las comunicaciones necesarias. Las funciones de registro, monitorización y alertas necesarias para cumplir los requisitos 10.2, 10.4 y 10.5 de PCI DSS se encuentran en un proyecto independiente. Los servicios compartidos y el CDE se encuentran dentro de un perímetro de seguridad de Controles de Servicio de VPC para evitar errores de configuración accidentales o que se ponga en peligro el acceso a los controles de gestión de identidades y accesos.

Si tu implementación se encuentra en Google Kubernetes Engine (GKE), puedes segmentar tu CDE y proteger los datos de los titulares de tarjetas de sistemas no fiables de las siguientes formas:

• Los espacios de nombres ofrecen una capa adicional de aislamiento del control de acceso, de forma que los usuarios solo pueden acceder a determinados pods, servicios e implementaciones de tu clúster de Kubernetes. Esto resulta ú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, así como proporcionar una capa adicional de segmentación de red en 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 tu clúster de GKE.

Cada una de estas capas forma una parte importante de tu postura de seguridad de defensa en profundidad y te ayuda a reducir el alcance aislando y protegiendo aún más tus componentes de confianza del entorno circundante. Si vas a implementar todo o parte de tu CDE con Kubernetes, consulta más información sobre cómo ejecutar tu entorno compatible con PCI en GKE.

Implementar la tokenización

La tokenización es el proceso de ocultar de forma irreversible un número de cuenta principal (PAN). Un PAN tokenizado, o token, no se puede canjear por un PAN mediante operaciones matemáticas. El PCI SSC ofrece directrices sobre el impacto de la tokenización en el ámbito de aplicación en el capítulo 3 del suplemento de las directrices de tokenización (PDF). El ámbito de PCI DSS se ve muy influido por el conjunto de componentes que almacenan y transmiten datos de titulares de tarjetas. Si se implementa correctamente, la tokenización puede ayudarte a reducir el alcance de tu evaluación minimizando la aparición y la transmisión de números de cuenta principales.

La tokenización también es una forma de segmentación por flujo de datos, ya que separa los sistemas que almacenan y transmiten datos de titulares de tarjetas de los que pueden realizar operaciones usando solo tokens. Por ejemplo, los sistemas que analizan la actividad de los consumidores para detectar fraudes no necesitan PANs, sino que pueden realizar estos análisis con datos tokenizados. La tokenización también añade una capa de separación entre los sistemas que almacenan y transmiten PANs y tu aplicación web de comercio electrónico. Si tu aplicación web solo interactúa con sistemas que usan tokens, es posible que se pueda eliminar del conjunto de sistemas conectados, lo que reduciría el alcance.

En el siguiente diagrama se muestra cómo se gestionan los datos de la CHD, la PAN y los datos tokenizados en un sistema de tokenización típico:

En la figura 6, se recibe del usuario un PAN y otros datos del titular de la tarjeta, y, a continuación, los datos se envían inmediatamente al servicio de tokenización. El servicio de tokenización cifra el PAN, genera un token y, a continuación, almacena ambos en un almacén de tokens seguro. Solo los servicios designados, como el servicio de liquidación, pueden acceder a la cámara acorazada en la red y están autorizados para canjear un PAN mediante un token generado. El servicio de liquidación solo usa el PAN para enviarlo al procesador de pagos. Ni el PAN ni ningún otro dato del titular de la tarjeta se produce nunca fuera de este flujo de datos estrictamente controlado. Como parte de una estrategia de defensa en profundidad, la arquitectura también usa Protección de Datos Sensibles como otra capa de defensa contra la filtración accidental de PANs u otros datos de titulares de tarjetas.

En la figura 6, el sistema de tokenización usa HashiCorp Vault, un almacén de secretos muy protegido, para gestionar 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 tengan autorización para acceder al almacén de tokens pueden recibir acceso con restricciones de tiempo para que solo puedan canjear un PAN durante el periodo específico que necesiten para llevar a cabo su función. También se pueden usar otros almacenes de datos, en función de los requisitos de tu empresa. Para obtener más información sobre cómo implementar la tokenización de forma segura en tu entorno, consulta Tokenizar datos sensibles de titulares de tarjetas en el ámbito del PCI DSS.

Arquitectura de ejemplo

En el siguiente diagrama se muestra un ejemplo de arquitectura para procesar transacciones tokenizadas mediante Pub/Sub y Dataflow, así como para almacenar registros de transacciones tokenizadas en Spanner.

En la figura 7, el proyecto de procesamiento de transacciones es un sistema conectado a y está incluido en el ámbito del PCI. No es un problema de seguridad, ya que la vulneración de cualquier componente del proyecto de procesamiento de transacciones no puede proporcionar a un atacante acceso a los datos de la tarjeta de crédito. El proyecto de aplicación web está fuera del ámbito, ya que no se conecta a la CDE y solo interactúa con datos depurados.

Los datos tokenizados se envían desde el CDE a Pub/Sub. Antes de que los datos tokenizados se publiquen para otros suscriptores, Protección de Datos Sensibles verifica que no contengan datos de tarjetas de crédito, débito o prepago. Dataflow procesa los datos tokenizados y los almacena en la base de datos de transacciones de Spanner. Las transacciones se pueden asociar a usuarios específicos mediante tokens sin acceder a los PANs. La base de datos de transacciones de Spanner también se puede usar para generar informes y análisis con herramientas de inteligencia empresarial (BI) como Looker.

Cumplimiento continuo

La seguridad y el cumplimiento son más que una arquitectura correcta y una buena ingeniería. Una arquitectura correcta puede demostrar que tu entorno se ha diseñado de forma segura en teoría. También necesitas procesos eficaces de auditoría, registro, monitorización y corrección para asegurarte de que tu entorno sigue siendo seguro en la práctica.

Para cumplir cada una de las 12 categorías de requisitos del PCI DSS, debe monitorizar su implementación de forma continua. Debes demostrarte a ti mismo y al evaluador que cualquier componente incluido en el ámbito seguirá siendo seguro en el futuro, mucho después de que se complete la evaluación de PCI DSS. La supervisión adecuada junto con una acción de corrección rápida se denomina cumplimiento continuo. El cumplimiento continuo es un requisito de PCI DSS y, si se implementa correctamente, puede ayudar a maximizar el efecto de las otras estrategias de reducción del ámbito.

Google Cloud te permite registrar todo lo que ocurre en tu red mediante Almacenamiento de registros de reglas de cortafuegos, Registros de flujo de VPC, Registros de controles de servicio de VPC y Registros de Cloud Load Balancing. Puedes monitorizar la actividad de tus sistemas y usuarios con registros de auditoría de Cloud. Monitorizar estos registros con regularidad te ayuda a cumplir el requisito 10.4 de PCI DSS y te permite responder rápidamente a posibles amenazas de seguridad y solucionarlas. Para obtener más información, consulta el suplemento del PCI DSS sobre la monitorización eficaz de los registros diarios (PDF).

Security Command Center te permite conocer a fondo tu seguridad y la superficie de ataque contra los datos, ya que ofrece el inventario, la detección, la búsqueda y la gestión de los recursos. Security Command Center puede analizar los resultados de los análisis de Protección de Datos Sensibles para identificar datos de titulares de tarjetas filtrados y verificar que tu sistema de tokenización no se esté usando de forma inadecuada para canjear PANs de forma malintencionada. Con Event Threat Detection, Security Command Center puede ayudarte a detectar de forma proactiva amenazas y actividades inusuales en tu red y en tus máquinas virtuales, lo que podría indicar que un atacante está analizando tu sistema para identificar sus defensas. Security Command Center también te permite crear fuentes de seguridad personalizadas específicas para tu entorno.

Google Cloud Armor puede proporcionar protección adicional a tus aplicaciones web públicas y ayudarte a cumplir el requisito 6.4 del PCI DSS. Google Cloud Cloud Armor evalúa las solicitudes entrantes para detectar diversos ataques web comunes y puede ayudarte a evitar las revisiones de código manuales que requieren mucho trabajo y que se especifican en el requisito 6.4. Tener un WAF te ayuda a mantener el cumplimiento continuo y, al mismo tiempo, a reducir los costes y los riesgos de cumplimiento.

Siguientes pasos

• Consulta las prácticas recomendadas para gestionar las obligaciones de cumplimiento.
• Consulta la página Cumplimiento de las normas de seguridad de datos de la PCI Google Cloud.
• Guía del Consejo del PCI sobre el alcance y la segmentación de redes del PCI DSS (PDF)
• Prueba el plano técnico de PCI en GKE.
• Protege tus cargas de trabajo de Kubernetes para cumplir el estándar PCI DSS.
• Tokenizar datos sensibles de titulares de tarjetas en el ámbito del PCI DSS.
• Despliega el proyecto de Terraform inicial de PCI.
• Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.