Esta guía tiene como objetivo ayudarte a abordar las cuestiones específicas de las aplicaciones de Google Kubernetes Engine (GKE) cuando implementes las responsabilidades del cliente para cumplir los requisitos del estándar de seguridad de los datos del sector de las tarjetas de pago (PCI DSS).
Renuncia de responsabilidad: Esta guía tiene únicamente fines informativos. Google no pretende que la información ni las recomendaciones que se incluyen en esta guía sirvan de asesoramiento legal o de auditoría. Cada cliente tiene la responsabilidad de evaluar de forma independiente el uso que hace de los servicios según proceda para cumplir las obligaciones legales que correspondan.
Introducción al cumplimiento del PCI DSS y a GKE
Si gestionas datos de tarjetas de pago, debes protegerlos, tanto si se encuentran en una base de datos local como en la nube. PCI DSS se desarrolló para fomentar y mejorar la seguridad de los datos de los titulares de tarjetas, así como para facilitar la adopción generalizada de medidas de seguridad de datos coherentes en todo el mundo. PCI DSS proporciona una base de requisitos técnicos y operativos diseñados para proteger los datos de las tarjetas de crédito. El PCI DSS se aplica a todas las entidades implicadas en el tratamiento de tarjetas de pago, incluidos los comerciantes, los procesadores, las entidades adquirentes, las entidades emisoras y los proveedores de servicios. El estándar PCI DSS también se aplica a todas las demás entidades que almacenan, tratan o transmiten datos de titulares de tarjetas (CHD) o datos de autenticación sensibles (SAD), o ambos.
Las aplicaciones en contenedores se han vuelto populares recientemente, y muchas cargas de trabajo antiguas están migrando de una arquitectura basada en máquinas virtuales a una en contenedores. Google Kubernetes Engine es un entorno gestionado y listo para producción, diseñado para desplegar aplicaciones en contenedores. Esta solución incorpora las últimas innovaciones de Google en cuanto a productividad para desarrolladores, eficiencia de recursos y operaciones automatizadas, junto con la flexibilidad del código abierto, para que reduzcas el tiempo de lanzamiento.
El cumplimiento es una responsabilidad compartida en la nube. Google Cloud, incluido GKE (tanto en el modo de funcionamiento Autopilot como en el Standard), cumple los requisitos de PCI DSS. En nuestra matriz de responsabilidades compartidas, se detallan nuestras responsabilidades.
Audiencia objetivo
- Clientes que quieran trasladar cargas de trabajo que cumplan el estándar PCI a Google Cloud que impliquen GKE.
- Desarrolladores, responsables de seguridad, responsables de cumplimiento, administradores de TI y otros empleados responsables de implementar controles y garantizar el cumplimiento de los requisitos del PCI DSS.
Antes de empezar
Para las recomendaciones que se indican a continuación, es posible que tengas que usar lo siguiente:
- Google Cloud Recursos de organización, carpeta y proyecto
- Gestión de identidades y accesos (IAM)
- Google Kubernetes Engine
- Google Cloud VPCs
- Google Cloud Armor
- La API Cloud Data Loss Prevention (que forma parte de Protección de Datos Sensibles)
- Identity‑Aware Proxy
- Security Command Center
Esta guía está dirigida a usuarios que estén familiarizados con los contenedores y con GKE.
Ámbito
En esta guía se identifican los siguientes requisitos del estándar PCI DSS que son específicos de GKE y se ofrecen directrices para cumplirlos. Se ha escrito para la versión 4.0 del estándar. En esta guía no se incluyen todos los requisitos de PCI DSS. La información proporcionada en esta guía puede ayudar a las organizaciones a cumplir el estándar PCI DSS, pero no es un asesoramiento exhaustivo. Las organizaciones pueden contratar a un evaluador de seguridad cualificado (QSA) de PCI para obtener una validación formal.
Terminología
En esta sección se definen los términos que se usan en esta guía. Para obtener más información, consulta el glosario de PCI DSS.
- CHD
datos de titulares de tarjetas. Como mínimo, consta del número de cuenta principal completo (PAN). Los datos del titular de la tarjeta también pueden aparecer en forma de PAN completo más cualquiera de los siguientes elementos:
- Nombre del titular de la tarjeta
- Fecha de vencimiento o código de servicio
- Datos de autenticación sensibles (SAD)
- CDE
Entorno de datos de titulares de tarjetas. Las personas, los procesos y la tecnología que almacenan, tratan o transmiten datos de titulares de tarjetas o datos de autenticación sensibles.
- PAN
número de cuenta principal. Un elemento clave de los datos de los titulares de tarjetas que debes proteger según el estándar PCI DSS. El PAN suele ser un número de 16 dígitos único para una tarjeta de pago (de crédito o débito) que identifica a la entidad emisora y a la cuenta del titular de la tarjeta.
- PIN
Número de identificación personal. Contraseña numérica que solo conocen el usuario y el sistema. Se usa para autenticar al usuario en el sistema.
- QSA
evaluador de seguridad cualificado. Persona certificada por el Consejo de Estándares de Seguridad de PCI para realizar auditorías y análisis de cumplimiento.
- SAD
datos de autenticación sensibles. En el cumplimiento de la normativa PCI, datos utilizados por las entidades emisoras de tarjetas para autorizar transacciones. Al igual que los datos de los titulares de tarjetas, el estándar PCI DSS requiere que se protejan los datos sensibles de autenticación. Además, los comerciantes y sus procesadores de pagos no pueden conservar los datos sensibles de autenticación. El SAD incluye lo siguiente:
- Registrar datos de bandas magnéticas
- "Monitorizar datos equivalentes" generados por tarjetas con chip y sin contacto
- Códigos de validación de seguridad (por ejemplo, el número de 3 o 4 dígitos impreso en las tarjetas) que se usan en transacciones online y en transacciones en las que no se presenta la tarjeta.
- PINs y bloques de PINs
- segmentación
En el contexto de PCI DSS, la práctica de aislar el CDE del resto de la red de la entidad. La segmentación no es un requisito de PCI DSS. Sin embargo, se recomienda encarecidamente como método que puede ayudar a reducir lo siguiente:
- El alcance y el coste de la evaluación de PCI DSS
- El coste y la dificultad de implementar y mantener los controles de PCI DSS
- El riesgo para una organización (que se reduce al consolidar los datos de los titulares de tarjetas en menos ubicaciones y más controladas)
Segmentar tu entorno de datos de titulares de tarjetas
El entorno de datos de los titulares de las tarjetas (CDE) incluye a las personas, los procesos y las tecnologías que almacenan, tratan o transmiten datos de los titulares de las tarjetas o datos de autenticación sensibles. En el contexto de GKE, el CDE también incluye lo siguiente:
- Sistemas que proporcionan servicios de seguridad (por ejemplo, IAM).
- Sistemas que facilitan la segmentación (por ejemplo, proyectos, carpetas, cortafuegos, nubes privadas virtuales [VPCs] y subredes).
- Pods y clústeres de aplicaciones que almacenan, tratan o transmiten datos de titulares de tarjetas. Si no se segmenta adecuadamente, toda tu infraestructura en la nube puede quedar incluida en el ámbito del PCI DSS.
Para que se considere que un componente del sistema está fuera del ámbito de PCI DSS, debe estar aislado correctamente del CDE de forma que, aunque se viera comprometido, no afectara a la seguridad del CDE.
Un requisito previo importante para reducir el ámbito del CDE es comprender claramente las necesidades y los procesos empresariales relacionados con el almacenamiento, el tratamiento y la transmisión de los datos de los titulares de las tarjetas. Restringir los datos de los titulares de tarjetas a la menor cantidad de ubicaciones posible eliminando los datos innecesarios y consolidando los necesarios puede requerir que rediseñes prácticas empresariales consolidadas.
Puede segmentar correctamente su CDE de varias formas en Google Cloud. En esta sección se describen los siguientes medios:
- Segmentación lógica mediante la jerarquía de recursos
- Segmentación de red mediante VPCs y subredes
- Segmentación a nivel de servicio mediante VPC
- Otras consideraciones para cualquier clúster incluido
Segmentación lógica mediante la jerarquía de recursos
Hay varias formas de aislar tu CDE en tu estructura organizativa mediante la jerarquía de recursos de Google Cloud. Los recursos deGoogle Cloud se organizan jerárquicamente. El recurso de organización es el nodo raíz de la jerarquía de recursos de Google Cloud . Las carpetas y los proyectos dependen del recurso de organización. Las carpetas pueden contener proyectos y carpetas. Las carpetas se usan para controlar el acceso a los recursos de la jerarquía de carpetas mediante permisos de gestión de identidades y accesos a nivel de carpeta. También se usan para agrupar proyectos similares. Un proyecto es un límite de confianza para todos tus recursos y un punto de aplicación de IAM.
Puedes agrupar todos los proyectos que estén en el ámbito de PCI en una carpeta para aislarlos a nivel de carpeta. También puedes usar un proyecto para todos los clústeres y aplicaciones PCI incluidos en el ámbito, o bien crear un proyecto y un clúster para cada aplicación PCI incluida en el ámbito y usarlos para organizar tusGoogle Cloud recursos. En cualquier caso, te recomendamos que mantengas las cargas de trabajo incluidas y excluidas en proyectos diferentes.
Segmentación de red mediante redes y subredes de VPC
Puedes usar nubes privadas virtuales (VPCs) y subredes para aprovisionar tu red, así como para agrupar y aislar los recursos relacionados con el CDE. Una VPC es un aislamiento lógico de una sección de una nube pública. Las redes de VPC proporcionan redes escalables y flexibles para tus instancias de máquina virtual (VM) de Compute Engine y para los servicios que usan instancias de VM, como GKE. Para obtener más información, consulta la descripción general de VPC y las prácticas recomendadas y las arquitecturas de referencia.
Segmentación a nivel de servicio con Controles de Servicio de VPC y Cloud Armor
Aunque las VPCs y las subredes proporcionan segmentación y crean un perímetro para aislar tu CDE, Controles de Servicio de VPC aumenta el perímetro de seguridad en la capa 7. Puedes usar Controles de Servicio de VPC para crear un perímetro alrededor de tus proyectos de CDE incluidos en el ámbito. Controles de Servicio de VPC te ofrece los siguientes controles:
- Control de acceso. Solo las identidades y los clientes autorizados pueden acceder a tu perímetro de seguridad.
- Control de salida. Solo se permiten destinos autorizados para las identidades y los clientes que se encuentren dentro de tu perímetro de seguridad.
Puedes usar Cloud Armor para crear listas de direcciones IP que permitan o denieguen el acceso a tu balanceador de carga HTTP(S) en el perímetro de la red de Google Cloud . Al examinar las direcciones IP lo más cerca posible del usuario y del tráfico malicioso, puedes evitar que el tráfico malicioso consuma recursos o entre en tus redes VPC.
Usa Controles de Servicio de VPC para definir un perímetro de servicio en torno a los proyectos incluidos en el ámbito. Este perímetro rige las rutas de máquina virtual a servicio y de servicio a servicio, así como el tráfico de entrada y salida de VPC.
Desarrollar y mantener una red y unos sistemas seguros
Para crear y mantener una red segura, se deben cumplir los requisitos 1 y 2 de PCI DSS.
Requisito 1
Instalar y mantener una configuración de cortafuegos para proteger los datos de los titulares de las tarjetas y el tráfico que entra y sale del CDE.
Los conceptos de redes de los contenedores y GKE son diferentes de los de las máquinas virtuales tradicionales. Los pods pueden comunicarse entre sí directamente, sin NAT, incluso entre nodos. De esta forma, se crea una topología de red sencilla que puede sorprenderte si estás acostumbrado a gestionar sistemas más complejos. El primer paso para proteger la red de GKE es familiarizarse con estos conceptos de redes.
Antes de analizar los requisitos individuales del requisito 1, puede que te interese revisar los siguientes conceptos de redes en relación con GKE:
Reglas de cortafuegos. Las reglas de cortafuegos se usan para restringir el tráfico a tus nodos. Los nodos de GKE se aprovisionan como instancias de Compute Engine y usan los mismos mecanismos de firewall que otras instancias. En tu red, puedes usar etiquetas para aplicar estas reglas de cortafuegos a cada instancia. Cada grupo de nodos recibe su propio conjunto de etiquetas que puedes usar en las reglas. De forma predeterminada, cada instancia que pertenece a un grupo de nodos recibe una etiqueta que identifica un clúster de GKE específico del que forma parte este grupo de nodos. Esta etiqueta se usa en las reglas de firewall que GKE crea automáticamente. Puedes añadir etiquetas personalizadas al crear un clúster o un grupo de nodos mediante la marca
--tagsen Google Cloud CLI.Políticas de la red. Las políticas de red te permiten limitar las conexiones de red entre pods, lo que puede ayudar a restringir el pivote de red y el movimiento lateral dentro del clúster en caso de que haya un problema de seguridad con un pod. Para usar las políticas de red, debes habilitar la función de forma explícita al crear el clúster de GKE. Puedes habilitarlo en un clúster, pero los nodos del clúster se reiniciarán. El comportamiento predeterminado es que toda la comunicación entre pods esté siempre abierta. Por lo tanto, si quieres segmentar tu red, debes aplicar políticas de red a nivel de pod. En GKE, puedes definir una política de red mediante la API de políticas de red de Kubernetes o la herramienta
kubectl. Estas reglas de política de tráfico a nivel de pod determinan qué pods y servicios pueden acceder entre sí dentro de tu clúster.Espacios de nombres. Los espacios de nombres permiten segmentar los recursos de tu clúster de Kubernetes. Kubernetes incluye un espacio de nombres predeterminado, pero puedes crear varios espacios de nombres en tu clúster. Los espacios de nombres están aislados lógicamente entre sí. Proporcionan un ámbito para pods, servicios y despliegues en el clúster, de forma que los usuarios que interactúen con un espacio de nombres no vean contenido de otro espacio de nombres. Sin embargo, los espacios de nombres de un mismo clúster no restringen la comunicación entre ellos. Aquí es donde entran en juego las políticas de red. Para obtener más información sobre cómo configurar espacios de nombres, consulta la entrada de blog Prácticas recomendadas para usar espacios de nombres.
En el siguiente diagrama se ilustran los conceptos anteriores en relación con otros componentes de GKE, como clústeres, nodos y pods.
Requisito 1.1
Se definen y comprenden los procesos y mecanismos para instalar y mantener los controles de seguridad de la red.
Requisito 1.1.2
Describe los grupos, los roles y las responsabilidades para gestionar los componentes de la red.
En primer lugar, como harías con la mayoría de los servicios de Google Cloud, debes configurar los roles de gestión de identidades y accesos para configurar la autorización en GKE. Una vez que hayas configurado tus roles de gestión de identidades y accesos, tendrás que añadir la configuración del control de acceso basado en roles de Kubernetes (RBAC) como parte de una estrategia de autorización de Kubernetes.
Básicamente, toda la configuración de IAM se aplica a todos los Google Cloud recursos y a todos los clústeres de un proyecto. La configuración de RBAC de Kubernetes se aplica a los recursos de cada clúster de Kubernetes y permite una autorización detallada a nivel de espacio de nombres. Con GKE, estos enfoques de autorización funcionan en paralelo, y las funciones de un usuario representan una unión de los roles de IAM y RBAC que se le han asignado:
- Usa IAM para controlar grupos, roles y responsabilidades para gestionar de forma lógica los componentes de la red en GKE.
- Usa RBAC de Kubernetes para conceder permisos pormenorizados a las políticas de red en los clústeres de Kubernetes, controlar el tráfico entre pods y evitar que los usuarios que no pertenecen al CDE hagan cambios no autorizados o accidentales.
- Poder justificar todos los usuarios y permisos de IAM y RBAC. Normalmente, cuando los auditores de seguridad cualificados prueban los controles, buscan una justificación empresarial para una muestra de gestión de identidades y accesos y control de acceso basado en roles.
Requisito 1.2
Se configuran y mantienen controles de seguridad de red (CSNs).
Primero, configura las reglas de cortafuegos en las instancias de Compute Engine que ejecutan tus nodos de GKE. Las reglas de cortafuegos protegen estos nodos del clúster.
A continuación, configura las políticas de red para restringir los flujos y proteger los pods de un clúster. Una política de red es una especificación de cómo los grupos de pods pueden comunicarse entre sí y con otros endpoints de red. Puedes usar la aplicación de políticas de red de GKE para controlar la comunicación entre los pods y los servicios de tu clúster. Para segmentar aún más el clúster, crea varios espacios de nombres en él. Los espacios de nombres están aislados entre sí de forma lógica. Proporcionan un ámbito para pods, servicios y despliegues en el clúster, de modo que los usuarios que interactúen con un espacio de nombres no verán el contenido de otro. Sin embargo, los espacios de nombres de un mismo clúster no restringen la comunicación entre ellos. Aquí es donde entran en juego las políticas de red. Los espacios de nombres permiten segmentar los recursos dentro de tu clúster de Kubernetes. Para obtener más información sobre cómo configurar espacios de nombres, consulta la entrada de blog Prácticas recomendadas para usar espacios de nombres.
De forma predeterminada, si no hay ninguna política en un espacio de nombres, se permite todo el tráfico de entrada y salida hacia y desde los pods de ese espacio de nombres. Por ejemplo, puede crear una política de aislamiento predeterminada para un espacio de nombres creando una política de red que seleccione todos los pods, pero que no permita que entre tráfico en esos pods.
Requisito 1.2.2
Todos los cambios en las conexiones de red y en las configuraciones de los NSCs se aprueban y gestionan de acuerdo con el proceso de control de cambios definido en el requisito 6.5.1.
Para tratar tus configuraciones de red e infraestructura como código, debes establecer un flujo de procesamiento de integración continua y entrega continua (CI/CD) como parte de tus procesos de gestión y control de cambios.
Puedes usar plantillas de Cloud Deployment Manager o de Terraform como parte de la canalización de CI/CD para crear políticas de red en tus clústeres. Con Deployment Manager o Terraform, puedes tratar la configuración y la infraestructura como código que puede reproducir copias coherentes del entorno de producción actual u otros entornos. Después, podrás escribir pruebas unitarias y de otro tipo para asegurarte de que los cambios en la red funcionan como se espera. Se puede gestionar un proceso de control de cambios que incluya una aprobación mediante archivos de configuración almacenados en un repositorio de versiones.
Con Terraform Config Validator, puedes definir restricciones para aplicar políticas de seguridad y gobernanza. Si añades Config Validator a tu flujo de procesamiento de CI/CD, puedes añadir un paso a cualquier flujo de trabajo. Este paso valida un plan de Terraform y lo rechaza si se detectan infracciones.
Requisito 1.2.5
Todos los servicios, protocolos y puertos permitidos se identifican, se aprueban y tienen una necesidad empresarial definida.
Para tener un control de acceso más exhaustivo en tus clústeres de GKE, puedes usar redes autorizadas para restringir determinados intervalos de IP que pueden acceder al plano de control de tu clúster. GKE usa tanto Seguridad en la capa de transporte (TLS) como la autenticación para proporcionar acceso seguro al endpoint del plano de control del clúster desde Internet público. Este acceso te ofrece la flexibilidad de administrar tu clúster desde cualquier lugar. Si usas redes autorizadas, puedes restringir aún más el acceso a conjuntos de direcciones IP específicos.
Puedes usar Cloud Armor para crear listas de IPs denegadas y permitidas, así como políticas de seguridad para aplicaciones alojadas en GKE. En un clúster de GKE, el tráfico entrante se gestiona mediante el balanceo de carga HTTP(S), que es un componente de Cloud Load Balancing. Normalmente, el balanceador de carga HTTP(S) lo configura el controlador de Ingress de GKE, que obtiene información de configuración de un objeto Ingress de Kubernetes. Para obtener más información, consulta cómo configurar políticas de Cloud Armor con GKE.
Requisito 1.3
El acceso a la red desde y hacia el entorno de datos del titular de la tarjeta está restringido.
Para mantener la privacidad de los datos sensibles, puedes configurar comunicaciones privadas entre los clústeres de GKE de tus redes de VPC y los despliegues híbridos on-premise mediante los Controles de Servicio de VPC y el acceso privado de Google.
Requisito 1.3.1
El tráfico entrante a la CDE está restringido de la siguiente manera:
- Solo al tráfico necesario.
- El resto del tráfico se deniega específicamente.
Te recomendamos que implementes la configuración de Cloud NAT con GKE para limitar el tráfico de Internet entrante a ese clúster. Puedes configurar un clúster privado para los clústeres no públicos de tu CDE. En un clúster privado, los nodos solo tienen direcciones IP RFC 1918 internas, lo que asegura que sus cargas de trabajo estén aisladas de Internet público.
Requisito 1.4
Se controlan las conexiones de red entre redes de confianza y no de confianza.
Puedes cumplir este requisito con los mismos métodos que se indican en el requisito 1.3.
Requisito 1.4.3
Se implementan medidas contra la suplantación de identidad para detectar y bloquear las direcciones IP de origen falsificadas que intentan acceder a la red de confianza.
Para implementar medidas contra la suplantación de identidad, usa direcciones IP de alias en pods y clústeres de GKE para detectar y bloquear las direcciones IP de origen falsificadas que intenten acceder a la red. Un clúster que usa intervalos de IPs con alias se denomina clúster nativo de VPC.
Requisito 1.4.5
La divulgación de direcciones IP internas e información de enrutamiento se limita únicamente a las partes autorizadas.
Puedes usar un agente de enmascaramiento de IP de GKE para hacer una traducción de direcciones de red (NAT) de muchas a una en un clúster. El enmascaramiento oculta varias direcciones IP de origen tras una sola dirección.
Requisito 2
Aplica configuraciones seguras a todos los componentes del sistema.
El requisito 2 especifica cómo reforzar los parámetros de seguridad eliminando los valores predeterminados y las credenciales proporcionadas por el proveedor. Reforzar la seguridad de tu clúster es responsabilidad del cliente.
Requisito 2.2
Los componentes del sistema se configuran y gestionan de forma segura.
Asegúrate de que estos estándares aborden todas las vulnerabilidades de seguridad conocidas y sean coherentes con los estándares de protección de sistemas aceptados en el sector. Entre las fuentes de estándares de protección de sistemas aceptados en el sector se incluyen las siguientes (esta lista no es exhaustiva):Requisito 2.2.4
Solo se habilitan los servicios, protocolos, daemons y funciones necesarios, y se elimina o inhabilita toda la funcionalidad innecesaria.
Requisito 2.2.5
- Se documenta la justificación empresarial.
- Se documentan e implementan funciones de seguridad adicionales que reducen el riesgo de usar servicios, protocolos o daemons no seguros.
Requisito 2.2.6
Los parámetros de seguridad del sistema se han configurado para evitar un uso inadecuado.
Antes de la implementación
Antes de mover contenedores a GKE, te recomendamos que hagas lo siguiente:
- Empieza con una imagen base gestionada de contenedor que haya sido creada, mantenida y comprobada en cuanto a vulnerabilidades por una fuente de confianza. Crea un conjunto de imágenes base "correctas" o "de referencia" que puedan usar tus desarrolladores. Una opción más restrictiva es usar una imagen sin distribución o una imagen base scratch.
- Usa Artifact Analysis para analizar tus imágenes de contenedor en busca de vulnerabilidades.
- Establece una política interna de DevOps o SecOps para incluir solo bibliotecas y archivos binarios aprobados y de confianza en los contenedores.
Durante la configuración
Durante la configuración, te recomendamos que hagas lo siguiente:
- Usa el sistema operativo optimizado para contenedores predeterminado como imagen de nodo de GKE. Container-Optimized OS se basa en Chromium OS y está optimizado para la seguridad de los nodos.
- Habilita la actualización automática de los nodos de los clústeres que ejecutan tus aplicaciones. Esta función actualiza automáticamente el nodo a la versión de Kubernetes que se está ejecutando en el plano de control gestionado, lo que proporciona una mayor estabilidad y seguridad.
- Habilita la opción para reparar nodos automáticamente. Cuando esta función está habilitada, GKE comprueba periódicamente el estado de los nodos y lo usa para determinar si es necesario reparar un nodo. Si un nodo necesita repararse, se vacía y se crea un nodo nuevo que se añade al clúster.
- Activa Cloud Monitoring y Cloud Logging para ver todos los eventos, incluidos los eventos de seguridad y el estado de los nodos. Crea políticas de alertas de Cloud Monitoring para recibir notificaciones si se produce un incidente de seguridad.
- Aplicar cuentas de servicio con el número mínimo de privilegios necesarios a los nodos de GKE
- Consulta y aplica (si procede) la sección de GKE de la guía Google Cloud CIS Benchmark. El registro de auditoría de Kubernetes ya está habilitado de forma predeterminada y los registros de las solicitudes a
kubectly a la API de GKE se escriben en los registros de auditoría de Cloud. - Configura los registros de auditoría.
Proteger los datos de la cuenta
La protección de los datos de los titulares de las tarjetas abarca los requisitos 3 y 4 de PCI DSS.
Requisito 3
Protege los datos de las cuentas almacenadas.
El requisito 3 de PCI DSS estipula que las técnicas de protección, como el cifrado, la truncación, el enmascaramiento y el cifrado hash, son componentes fundamentales de la protección de los datos de los titulares de tarjetas. Si un intruso elude otros controles de seguridad y obtiene acceso a datos cifrados, sin las claves criptográficas adecuadas, esos datos serán ilegibles e inutilizables para esa persona.
También puedes plantearte otros métodos para proteger los datos almacenados como posibles oportunidades para mitigar los riesgos. Por ejemplo, los métodos para minimizar los riesgos incluyen no almacenar datos de titulares de tarjetas a menos que sea absolutamente necesario, truncar los datos de titulares de tarjetas si no se necesita el PAN completo y no enviar PANs sin protección mediante tecnologías de mensajería para usuarios finales, como el correo electrónico y la mensajería instantánea.
Estos son algunos ejemplos de sistemas en los que la información de la tarjeta de crédito, débito o prepago puede conservarse como parte de los flujos de procesamiento de pagos al ejecutarse en Google Cloud :
- Segmentos de Cloud Storage
- Instancias de BigQuery
- Datastore
- Cloud SQL
Ten en cuenta que la información de CHD puede almacenarse por error en los registros de correo electrónico o de comunicaciones del servicio de atención al cliente. Es recomendable usar Protección de Datos Sensibles para filtrar estos flujos de datos y limitar el entorno de tu ámbito a los sistemas de procesamiento de pagos.
Ten en cuenta que, en Google Cloud, los datos se encriptan en reposo de forma predeterminada y se encriptan en tránsito de forma predeterminada cuando atraviesan límites físicos. No es necesario configurar nada más para habilitar estas protecciones.
Requisito 3.5
El número de cuenta principal (PAN) está protegido en cualquier lugar en el que se almacene.
Uno de los mecanismos para hacer que los datos de PAN sean ilegibles es la tokenización. Para obtener más información, consulta la guía de soluciones sobre tokenización de datos sensibles de titulares de tarjetas en el ámbito del PCI DSS.
Puede usar la API DLP para escanear, descubrir y registrar los datos de los titulares de tarjetas. Protección de Datos Sensibles tiene funciones de serie para analizar y clasificar datos de PAN de 12 a 19 dígitos en Cloud Storage, BigQuery y Datastore. También tiene una API de transmisión de contenido para habilitar la compatibilidad con más fuentes de datos, además de aplicaciones y cargas de trabajo personalizadas. También puede usar la API DLP para truncar (ocultar) o cifrar con hash los datos.
Requisito 3.6
Las claves criptográficas que se usan para proteger los datos de las cuentas almacenados están protegidas.
Cloud Key Management Service (KMS) es un sistema de almacenamiento gestionado para claves criptográficas. Puede generar, usar, rotar y destruir claves criptográficas. Aunque Cloud KMS no almacena secretos directamente, como datos de titulares de tarjetas, se puede usar para encriptar esos datos.
En el contexto de Kubernetes, los secretos son objetos secretos de Kubernetes que te permiten almacenar y gestionar información sensible, como contraseñas, tokens y claves.
De forma predeterminada, Google Cloud cifra el contenido del cliente almacenado en reposo. GKE gestiona este cifrado predeterminado por ti sin que tengas que hacer nada más. El encriptado de secretos de la capa de aplicación ofrece una capa adicional de seguridad para los datos sensibles, como los secretos. Con esta función, puedes proporcionar una clave que gestiones en Cloud KMS para cifrar datos en la capa de aplicación. De esta forma, se protege contra los atacantes que obtengan acceso a una copia de la instancia de almacenamiento de configuración de Kubernetes de tu clúster.
Requisito 4
Protege los datos de los titulares de tarjetas con una criptografía sólida durante la transmisión a través de redes públicas abiertas.
Los datos incluidos en el ámbito deben cifrarse durante la transmisión a través de redes a las que puedan acceder fácilmente personas malintencionadas, como las redes públicas.
Istio es una malla de servicios de código abierto que se integra de forma transparente en aplicaciones distribuidas. Istio gestiona de manera escalable la autenticación, la autorización y el cifrado del tráfico entre microservicios. Es una plataforma que incluye APIs que te permiten integrarte en cualquier plataforma de registro, telemetría o sistema de políticas. El conjunto de funciones de Istio te permite ejecutar de forma eficiente una arquitectura de microservicios distribuida y ofrece un sistema uniforme para proteger, conectar y monitorizar microservicios.
Requisito 4.1
Se definen y documentan los procesos y mecanismos para proteger los datos de los titulares de tarjetas con una criptografía sólida durante la transmisión a través de redes públicas abiertas.
Puedes usar Istio para crear una red de servicios implementados con balanceo de carga, autenticación entre servicios y monitorización. También puedes usarlo para ofrecer una comunicación segura de servicio a servicio en un clúster, con una autenticación basada en identidades sólida y una autorización basada en TLS mutuo. TLS mutuo (mTLS) es un handshake TLS que se realiza dos veces para establecer el mismo nivel de confianza en ambas direcciones (a diferencia de la confianza unidireccional entre cliente y servidor).
Istio te permite desplegar certificados TLS en cada uno de los pods de GKE de una aplicación. Los servicios que se ejecutan en el pod pueden usar mTLS para identificar de forma segura las identidades de sus pares. La comunicación entre servicios se canaliza a través de proxies Envoy del lado del cliente y del lado del servidor. Envoy usa IDs de SPIFFE para establecer conexiones mTLS entre servicios. Para obtener información sobre cómo desplegar Istio en GKE, consulta la documentación de GKE. Para obtener información sobre las versiones de TLS admitidas, consulta la referencia de gestión del tráfico de Istio. Usa la versión 1.2 de TLS o una posterior.
Si tu aplicación está expuesta a Internet, usa el balanceo de carga HTTP(S) de GKE con el enrutamiento de Ingress configurado para usar HTTP(S). El balanceo de carga HTTP(S), configurado por un objeto Ingress, incluye las siguientes funciones:
- Configuración flexible de los servicios. Un objeto Ingress define cómo llega el tráfico a tus servicios y cómo se enruta a tu aplicación. Además, un Ingress puede proporcionar una sola dirección IP para varios servicios de tu clúster.
- Integración con Google Cloud servicios de red. Un objeto Ingress puede configurar Google Cloud funciones como certificados SSL gestionados por Google (beta), Cloud Armor, Cloud CDN e Identity-Aware Proxy.
- Compatibilidad con varios certificados TLS. Un objeto Ingress puede especificar el uso de varios certificados TLS para la finalización de solicitudes.
Cuando creas un objeto Ingress, el controlador de Ingress de GKE crea un balanceador de carga HTTP(S) de Cloud y lo configura según la información de Ingress y sus servicios asociados.
Mantener un programa de gestión de vulnerabilidades
Mantener un programa de gestión de vulnerabilidades abarca los requisitos 5 y 6 del estándar PCI DSS.
Requisito 5
Protege todos los sistemas y redes frente al software malicioso.
El requisito 5 del estándar de seguridad de los datos de las tarjetas de pago (PCI DSS) estipula que se debe usar software antivirus en todos los sistemas que suelen verse afectados por malware para protegerlos de las amenazas de software malicioso actuales y futuras. Los contenedores no son una excepción.
Requisito 5.2
Se evita el software malicioso (malware) o se detecta y se soluciona.
Debes implementar programas de gestión de vulnerabilidades para tus imágenes de contenedor.
Te recomendamos que hagas lo siguiente:
- Comprueba y aplica periódicamente parches de seguridad actualizados en los contenedores.
- Realiza análisis de vulnerabilidades periódicos en aplicaciones en contenedores y archivos binarios o bibliotecas.
- Analiza imágenes como parte del flujo de procesamiento de compilación.
- Suscríbete a un servicio de información sobre vulnerabilidades para recibir información actualizada sobre las vulnerabilidades relevantes para el entorno y las bibliotecas que se usan en los contenedores.
Google Cloud colabora con varios proveedores de soluciones de seguridad de contenedores para mejorar la postura de seguridad en las implementaciones de los clientes. Google Cloud Te recomendamos que utilices soluciones y tecnologías de seguridad validadas para aumentar la profundidad de la defensa en tu entorno de GKE. Para ver la lista más reciente de partners de seguridad validados porGoogle Cloud, consulta Partners de seguridad.
Requisito 5.2.2
Las soluciones antimalware implementadas:
- Detecta todos los tipos de malware conocidos.
- Elimina, bloquea o contiene todos los tipos conocidos de malware.
Requisito 5.2.3
Los componentes del sistema que no estén en riesgo de sufrir ataques de malware se evalúan periódicamente para incluir lo siguiente:
- Una lista documentada de todos los componentes del sistema que no corren riesgo de sufrir ataques de malware.
- Identificación y evaluación de las amenazas de malware en evolución para esos componentes del sistema.
- Confirmación de si los componentes del sistema siguen sin requerir protección antimalware.
Hay muchas soluciones disponibles para realizar análisis de malware, pero PCI DSS reconoce que no todos los sistemas tienen la misma probabilidad de ser vulnerables. Es habitual que los comerciantes declaren que sus servidores Linux, mainframes y máquinas similares no se ven "afectados habitualmente por software malicioso" y, por lo tanto, están exentos del punto 5.2.2. En ese caso, se aplica la sección 5.2.3 y debes implementar un sistema para realizar evaluaciones periódicas de las amenazas.
Ten en cuenta que estas reglas se aplican tanto a los nodos como a los pods de un clúster de GKE.
Requisito 5.3
Los mecanismos y procesos antimalware están activos, se mantienen y se monitorizan.
Los requisitos 5.2, 5.3 y 11.5 exigen análisis antivirus y monitorización de la integridad de los archivos (FIM) en cualquier host incluido en el ámbito. Te recomendamos que implementes una solución en la que un agente de confianza pueda analizar todos los nodos del clúster o en la que cada nodo tenga un analizador que envíe informes a un único endpoint de gestión.
Para obtener más información, consulta la descripción general de la seguridad de GKE y la descripción general de la seguridad de Container-Optimized OS.
Una solución habitual para cumplir los requisitos de antivirus y de FIM es bloquear el contenedor para que solo determinadas carpetas permitidas tengan acceso de escritura. Para ello, ejecuta los contenedores como un usuario que no sea root y usa permisos del sistema de archivos para impedir el acceso de escritura a todos los directorios, excepto a los de trabajo, del sistema de archivos del contenedor. No permitir apropiación de privilegios para evitar que se eludan las reglas del sistema de archivos.
Requisito 6
Desarrollar y mantener sistemas y software seguros.
El requisito 6 de PCI DSS estipula que debes establecer un ciclo de vida de desarrollo de software sólido en el que la seguridad se integre en cada paso del desarrollo de software.
Requisito 6.2
El software personalizado se desarrolla de forma segura.
Requisito 6.2.1
El software personalizado se desarrolla de forma segura, de la siguiente manera:
- Basado en los estándares del sector o en las prácticas recomendadas para el desarrollo seguro.
- De conformidad con PCI DSS (por ejemplo, autenticación y registro seguros).
- Incorporar la consideración de los problemas de seguridad de la información en cada fase del ciclo de vida del desarrollo de software.
Puedes usar la autorización binaria para asegurarte de que solo se desplieguen contenedores de confianza en GKE. Si quieres habilitar solo las imágenes autorizadas por uno o varios certificadores específicos, puedes configurar la autorización binaria para aplicar una política con reglas que requieran certificaciones basadas en los resultados de análisis de vulnerabilidades. También puedes escribir políticas que requieran que una o varias partes de confianza (denominadas "atestadores") aprueben una imagen antes de que se pueda desplegar. En una canalización de implementación de varias fases en la que las imágenes pasan de los clústeres de desarrollo a los de pruebas y, después, a los de producción, puedes usar attestors para asegurarte de que se han completado todos los procesos necesarios antes de que el software pase a la siguiente fase.
En el momento del despliegue, la autorización binaria aplica tu política comprobando que la imagen de contenedor haya superado todas las restricciones necesarias, incluido que todos los certificadores necesarios hayan verificado que la imagen está lista para el despliegue. Si la imagen cumple los requisitos, el servicio permite que se implemente. De lo contrario, la implementación se bloqueará y la imagen no se podrá implementar hasta que cumpla los requisitos.
Para obtener más información sobre la autorización binaria, consulta el artículo Configuración para GKE.
En caso de emergencia, puedes omitir una política de Autorización binaria mediante el flujo de trabajo de acceso de emergencia. Todos los incidentes de acceso de emergencia se registran en Registros de auditoría de Cloud.
GKE Sandbox reduce la necesidad de que el contenedor interactúe directamente con el host, lo que disminuye la superficie de ataque del host vulnerable y limita el alcance de las acciones malintencionadas.
Requisito 6.3
Se identifican y se solucionan las vulnerabilidades de seguridad.
Requisito 6.3.1
Las vulnerabilidades de seguridad se identifican y gestionan de la siguiente manera:
- Se identifican nuevas vulnerabilidades de seguridad mediante fuentes reconocidas del sector para obtener información sobre vulnerabilidades de seguridad, incluidas alertas de equipos de respuesta ante emergencias informáticas (CERTs) internacionales y nacionales.
- A las vulnerabilidades se les asigna una clasificación de riesgo basada en las prácticas recomendadas del sector y en la consideración del impacto potencial.
- Las clasificaciones de riesgo identifican, como mínimo, todas las vulnerabilidades que se consideran de alto riesgo o críticas para el entorno.
- Se cubren las vulnerabilidades del software personalizado y de terceros (por ejemplo, sistemas operativos y bases de datos).
La seguridad en la nube es una responsabilidad compartida entre el proveedor de servicios en la nube y el cliente.
En GKE, Google gestiona el plano de control, que incluye las VMs principales, el servidor de la API y otros componentes que se ejecutan en esas VMs, así como la base de datos etcd. Esto incluye actualizaciones y parches, escalado y reparaciones, todo ello respaldado por un objetivo de nivel de servicio. En cuanto al sistema operativo de los nodos, como Container-Optimized OS o Ubuntu, GKE pone a disposición los parches de estas imágenes rápidamente. Si tienes habilitada la actualización automática, estos parches se implementarán automáticamente. Esta es la capa base de tu contenedor, que no es lo mismo que el sistema operativo que se ejecuta en tus contenedores.
Para obtener más información sobre el modelo de responsabilidad compartida de GKE, consulta el artículo Explorar la seguridad de los contenedores: el modelo de responsabilidad compartida en GKE.
Google ofrece varios servicios de seguridad para ayudarte a integrar la seguridad en tu flujo de procesamiento de CI/CD. Para identificar vulnerabilidades en tus imágenes de contenedor, puedes usar Google Artifact Analysis Vulnerability Scanning. Cuando se envía una imagen de contenedor a Google Container Registry (GCR), el análisis de vulnerabilidades busca automáticamente vulnerabilidades y riesgos conocidos en las imágenes a partir de fuentes de CVE conocidas. A las vulnerabilidades se les asignan niveles de gravedad (crítica, alta, media, baja y mínima) en función de las puntuaciones CVSS.
Requisito 6.4
Las aplicaciones web públicas están protegidas frente a ataques.
Web Security Scanner te permite analizar las aplicaciones web de App Engine, Compute Engine y GKE que están expuestas públicamente para detectar vulnerabilidades comunes, que van desde el cross-site scripting y las configuraciones incorrectas hasta los recursos vulnerables. Los análisis se pueden realizar bajo demanda y programar desde la Google Cloud consola. Con las APIs de Security Scanner, puedes automatizar el análisis como parte de tu conjunto de pruebas de seguridad en el flujo de compilación de tu aplicación.
Implementar medidas de control de acceso sólidas
La implementación de medidas de control de acceso sólidas abarca los requisitos 7, 8 y 9 de PCI DSS.
Requisito 7
Restringe el acceso a los componentes del sistema y a los datos de los titulares de tarjetas según las necesidades de la empresa.
El requisito 7 se centra en el principio de mínimos accesos o en la necesidad de conocer. PCI DSS define estos conceptos como la concesión de acceso a la menor cantidad de datos y la asignación de los privilegios mínimos necesarios para desempeñar un trabajo.
Requisito 7.2
El acceso a los componentes y los datos del sistema se define y se asigna de forma adecuada.
IAM y el control de acceso basado en roles (RBAC) de Kubernetes funcionan conjuntamente para proporcionar un control de acceso detallado a tu entorno de GKE. La gestión de identidades y accesos se usa para gestionar el acceso de los usuarios y los permisos de losGoogle Cloud recursos de tu proyecto de CDE. En GKE, también puedes usar IAM para gestionar el acceso y las acciones que los usuarios y las cuentas de servicio pueden realizar en tus clústeres, como crear y eliminar clústeres.
El control de acceso basado en roles (RBAC) de Kubernetes te permite configurar conjuntos de permisos detallados que definen cómo puede interactuar un Google Cloud usuario Google Cloud, una cuenta de servicio o un grupo de usuarios (Grupos de Google) con cualquier objeto de Kubernetes de tu clúster o en un espacio de nombres específico de tu clúster. Algunos ejemplos de permisos de RBAC son editar implementaciones o configmaps, eliminar pods o ver registros de un pod. Concede a los usuarios o servicios permisos de gestión de identidades y accesos limitados, como Lector de clústeres de Google Kubernetes Engine o roles personalizados, y, a continuación, aplica los enlaces de roles de control de acceso basado en roles (RBAC) de Kubernetes que correspondan.
Cloud Identity-Aware Proxy (IAP) se puede integrar a través del tráfico de entrada de GKE para controlar el acceso a nivel de aplicación de los empleados o de las personas que necesiten acceder a tus aplicaciones PCI.
Además, puedes usar políticas de la organización para restringir las APIs y los servicios que están disponibles en un proyecto.
Requisito 7.2.2
El acceso se asigna a los usuarios, incluidos los usuarios con privilegios, en función de lo siguiente:
- Clasificación y función del puesto.
- Los privilegios mínimos necesarios para desempeñar las responsabilidades del puesto.
Además de asegurarse de que los usuarios y las cuentas de servicio cumplan el principio de privilegio mínimo, los contenedores también deberían hacerlo. Una práctica recomendada al ejecutar un contenedor es ejecutar el proceso con un usuario que no sea root. Puedes llevar a cabo y aplicar esta práctica mediante el controlador de admisión PodSecurity.
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. Los estándares de seguridad de pods son políticas de seguridad predefinidas que cubren las necesidades de alto nivel de seguridad de los pods en Kubernetes. Estas políticas van desde muy permisivas hasta muy restrictivas. PodSecurity sustituye al controlador de admisión PodSecurityPolicy, que se retiró en Kubernetes v1.25. Consulta las instrucciones para migrar de PodSecurityPolicy al controlador de admisión PodSecurity.
Requisito 8
Identificar a los usuarios y autenticar el acceso a los componentes del sistema
El requisito 8 especifica que se debe asignar un ID único a cada persona que tenga acceso a los sistemas PCI incluidos en el ámbito para asegurarse de que cada persona sea responsable de sus acciones.
Requisito 8.2
La identificación de los usuarios y las cuentas relacionadas de los usuarios y los administradores se gestionan de forma estricta durante todo el ciclo de vida de una cuenta.
Requisito 8.2.1
A todos los usuarios se les asigna un ID único antes de que se les permita acceder a los componentes del sistema o a los datos del titular de la tarjeta.
Requisito 8.2.5
El acceso de los usuarios que se hayan dado de baja se revoca de inmediato.
Tanto IAM como RBAC de Kubernetes se pueden usar para controlar el acceso a tu clúster de GKE. En ambos casos, puedes conceder permisos a un usuario. Recomendamos que los usuarios se vinculen a tu sistema de identidad para que puedas gestionar las cuentas de usuario y las políticas en un mismo lugar.
Requisito 8.3
Se establece y gestiona una autenticación sólida para los usuarios y los administradores.
Requisito 8.3.1
- Algo que sabes, como una contraseña o una frase de contraseña.
- Algo que tengas, como un dispositivo de token o una tarjeta inteligente.
- Algo que eres, como un elemento biométrico.
Los certificados se asocian a la identidad de un usuario cuando se autentica en kubectl.
Todos los clústeres de GKE están configurados para aceptar identidades de Google Cloud usuario y de cuenta de servicio. Para ello, validan las credenciales y recuperan la dirección de correo asociada a la identidad de usuario o de cuenta de servicio. Por lo tanto, las credenciales de esas cuentas deben incluir el ámbito de OAuth userinfo.email para autenticarse correctamente.
Requisito 9
Restringir el acceso físico a los datos de los titulares de las tarjetas.
Google es responsable de los controles de seguridad física de todos los centros de datos de Google que sustentanGoogle Cloud.
Monitoriza y prueba las redes con regularidad
La monitorización y las pruebas periódicas de las redes abarcan los requisitos 10 y 11 de PCI DSS.
Requisito 10
Registra y monitoriza todos los accesos a los componentes del sistema y a los datos de los titulares de tarjetas.
Requisito 10.2
Los registros de auditoría se implementan para detectar anomalías y actividad sospechosa, así como para llevar a cabo análisis forenses de eventos.
Los clústeres de Kubernetes tienen habilitado de forma predeterminada el registro de auditoría de Kubernetes, que mantiene un registro cronológico de las llamadas que se han realizado al servidor de la API de Kubernetes. Las entradas de registro de auditoría de Kubernetes son útiles para investigar solicitudes de API sospechosas, recopilar estadísticas o crear alertas de monitorización para llamadas a la API no deseadas.
Los clústeres de GKE integran una configuración predeterminada para registros de auditoría de GKE con Registros de auditoría de Cloud y Logging. Puedes ver las entradas del registro de auditoría de Kubernetes en tu Google Cloud proyecto.
Además de las entradas escritas por Kubernetes, los registros de auditoría de tu proyecto tienen entradas escritas por GKE.
Para diferenciar las cargas de trabajo de CDE y las que no lo son, te recomendamos que añadas etiquetas a tus pods de GKE que se propaguen a las métricas y los registros emitidos por esas cargas de trabajo.
Requisito 10.2.2
- Identificación de usuario
- Tipo de evento
- Fecha y hora
- Indicación de éxito o error
- Origen del evento
- Identidad o nombre de los datos, el componente del sistema, el recurso o el servicio afectados (por ejemplo, nombre y protocolo)
Cada entrada de registro de auditoría de Logging es un objeto de tipo LogEntry
que contiene los siguientes campos:
- Una carga útil, que es del tipo
protoPayload. La carga útil de cada entrada del registro de auditoría es un objeto de tipoAuditLog. Puede encontrar la identidad del usuario en el campoAuthenticationInfode los objetosAuditLog. - El evento específico, que puede encontrar en el campo
methodNamedeAuditLog. - Una marca de tiempo.
- El estado del evento, que se encuentra en los objetos
responsedel objetoAuditLog. - La solicitud de operación, que se encuentra en los objetos
requestyrequestMetadatadel objetoAuditLog. - El servicio que se va a realizar, que puedes encontrar en el objeto
AuditDatadeserviceData.
Requisito 11
Prueba la seguridad de los sistemas y las redes con regularidad.
Requisito 11.3
Las vulnerabilidades externas e internas se identifican, priorizan y solucionan periódicamente.
Requisito 11.3.1
- Al menos una vez cada tres meses.
- Se resuelven las vulnerabilidades críticas y de alto riesgo (según las clasificaciones de riesgo de vulnerabilidades de la entidad definidas en el requisito 6.3.1).
- Se realizan nuevos análisis para confirmar que se han resuelto todas las vulnerabilidades críticas y de alto riesgo (como se ha indicado anteriormente).
- La herramienta de análisis se mantiene actualizada con la información más reciente sobre vulnerabilidades.
- Las exploraciones las realiza personal cualificado y el examinador tiene independencia organizativa.
El análisis de vulnerabilidades de Artifact Analysis realiza los siguientes tipos de análisis de vulnerabilidades en las imágenes de Container Registry:
Análisis inicial. La primera vez que activas la API Artifact Analysis, analiza tus imágenes en Container Registry y extrae el gestor de paquetes, la base de la imagen y las incidencias de vulnerabilidades de las imágenes.
Análisis incremental. Artifact Analysis analiza las imágenes nuevas cuando se suben a Container Registry.
Análisis continuo: a medida que Artifact Analysis recibe información nueva y actualizada sobre vulnerabilidades de fuentes de vulnerabilidades, vuelve a analizar los contenedores para mantener actualizada la lista de vulnerabilidades de las imágenes ya analizadas.
Requisito 11.5
Se detectan las intrusiones en la red y los cambios inesperados en los archivos, y se responde a ellos.
Requisito 11.5.1
- Todo el tráfico se monitoriza en el perímetro del CDE.
- Todo el tráfico se monitoriza en puntos críticos de la CDE.
- Se alerta al personal de las posibles brechas de seguridad.
- Todos los motores, las líneas de base y las firmas de detección y prevención de intrusiones se mantienen actualizados.
Google Cloud Replicación de paquetes se puede usar con Cloud IDS para detectar intrusiones en la red. Google Cloud Replicación de paquetes reenvía todo el tráfico de red de tus VMs de Compute Engine o de tus Google Cloud clústeres a una dirección designada. Cloud IDS puede consumir este tráfico reflejado para detectar una amplia gama de amenazas, como intentos de vulneración, análisis de puertos, desbordamientos de búfer, fragmentación de protocolos, tráfico de comando y control (C2) y malware.
Security Command Center te ofrece una visibilidad centralizada del estado de seguridad de losGoogle Cloud servicios (incluido GKE) y los recursos de toda tu organización, lo que facilita la prevención, la detección y la respuesta ante amenazas. Con Security Command Center, puedes ver cuándo se han detectado amenazas de alto riesgo, como software malicioso, minería de criptomonedas, acceso no autorizado a recursos de Google Cloud , ataques DDoS salientes, escaneo de puertos y ataques de fuerza bruta SSH, en función de tus registros de Cloud Logging.
Mantener una política de seguridad de la información
Una política de seguridad sólida marca la pauta en materia de seguridad e informa a los usuarios de lo que se espera de ellos. En este caso, "personas" se refiere a los empleados a tiempo completo y parcial, los empleados temporales, los contratistas y los consultores que tienen acceso a tu CDE.
Requisito 12
Apoyar la seguridad de la información con políticas y programas de la organización.
Para obtener información sobre el requisito 12, consulta la Google Cloud matriz de responsabilidad compartida del PCI.
Eliminar los recursos utilizados
Si has usado algún recurso mientras seguías este artículo (por ejemplo, si has iniciado máquinas virtuales o has usado las secuencias de comandos de Terraform), puedes evitar que se te cobren cargos en tu cuenta de Google Cloud eliminando el proyecto en el que has usado esos recursos.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Siguientes pasos
- Más información sobre el cumplimiento del estándar de seguridad de datos PCI
- Prueba el kit de inicio de Terraform.
- Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.