El fin de esta guía es ayudarte a resolver inquietudes específicas de las aplicaciones de Google Kubernetes Engine (GKE) cuando implementes responsabilidades del cliente para los requisitos de Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS).
Renuncia de responsabilidad: Esta guía solo tiene fines informativos. Google no pretende que la información ni las recomendaciones incluidas se consideren asesoramiento legal ni de auditoría. Cada cliente es responsable de evaluar de manera independiente el uso particular que hace de los servicios según corresponda para satisfacer las obligaciones legales y de cumplimiento normativo.
Introducción al cumplimiento de PCI DSS y GKE
Si administras datos de tarjetas de pago, debes protegerlos, ya sea que residan en una base de datos local o en la nube. PCI DSS se diseñó para fomentar y mejorar la seguridad de los datos del titular de la tarjeta y facilitar la adopción generalizada de medidas coherentes de seguridad de datos de forma global. PCI DSS proporciona un modelo de referencia de requisitos técnicos y operativos diseñados para proteger los datos de la tarjeta de crédito. PCI DSS se aplica a todas las entidades involucradas en el procesamiento de tarjetas de pago, incluidos los comerciantes, procesadores, adquirentes, entidades emisoras y proveedores de servicios. PCI DSS también se aplica a todas las demás entidades que almacenan, procesan o transmiten datos de titulares de tarjetas (CHD), datos de autenticación sensibles (SAD) o ambos.
Las aplicaciones en contenedores se volvieron populares en el último tiempo y muchas cargas de trabajo heredadas se migraron de una arquitectura basada en máquinas virtuales (VM) a una basada en contenedores. Google Kubernetes Engine es un entorno administrado listo para la producción que permite implementar aplicaciones en contenedores. Ofrece las innovaciones más recientes de Google en productividad para desarrolladores, eficiencia de recursos, automatización de operaciones y flexibilidad de código abierto para acelerar su tiempo de salida al mercado.
El cumplimiento es una responsabilidad compartida en la nube. Google Cloud, incluido GKE (los modos de operación Autopilot y Standard), cumple con los requisitos de PCI DSS. En nuestra matriz de responsabilidad del cliente, detallamos nuestras responsabilidades.
Público objetivo
- Clientes que desean llevar cargas de trabajo compatibles con PCI a Google Cloud y que involucran el uso de GKE.
- Desarrolladores, oficiales de seguridad, oficiales de cumplimiento, administradores de TI y otros empleados responsables de implementar los controles y garantizar el cumplimiento de los requisitos de las PCI DSS.
Antes de comenzar
Para las siguientes recomendaciones, es posible que debas usar lo siguiente:
- Recursos de organización, carpeta y proyecto de Google Cloud
- Administración de identidades y accesos (IAM)
- Google Kubernetes Engine
- VPC de Google Cloud
- Google Cloud Armor
- La API de Cloud Data Loss Prevention (parte de la Protección de datos sensibles)
- Identity-Aware Proxy (IAP)
- Security Command Center
Esta guía está dirigida a los usuarios que ya sepan usar contenedores y GKE.
Alcance
En esta guía, se identifican los siguientes requisitos de PCI DSS que son inquietudes exclusivas de GKE y se proporciona orientación para cumplirlos. Está escrita con base en la versión 4.0 del estándar. En esta guía, no se abarcan todos los requisitos de PCI DSS. La información proporcionada en esta guía puede ayudar a las organizaciones en su cumplimiento de las PCI DSS, pero no es un asesoramiento integral. Las organizaciones pueden contratar a un evaluador de seguridad calificado de PCI (QSA) para la validación formal.
Terminología
En esta sección, se definen los términos usados en esta guía. Para obtener más detalles, consulta el glosario de PCI DSS.
- CHD
datos del titular de la tarjeta. Como mínimo, consta del número de cuenta principal (PAN) completo. Los datos del titular de la tarjeta también pueden aparecer en forma del 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 del titular de la tarjeta. Las personas, los procesos y la tecnología que almacenan, procesan o transmiten datos de titulares de tarjetas o datos de autenticación sensibles.
- PAN
número de cuenta principal. Una pieza clave de los datos del titular de la tarjeta que debes proteger conforme a PCI DSS. Por lo general, el PAN es un número de 16 dígitos que es exclusivo de una tarjeta de pago (crédito y débito) y que identifica a la entidad emisora y a la cuenta del titular de la tarjeta.
- PIN
número de identificación personal. Una contraseña numérica que solo conocen el usuario y un sistema, y que se usa para autenticar al usuario en el sistema.
- QSA
asesor de seguridad calificado. Persona certificada por el Consejo sobre Normas de Seguridad (SSC) de la PCI para realizar auditorías y análisis de cumplimiento.
- SAD
datos de autenticación sensibles. Los datos que usan las entidades emisoras de tarjetas para autorizar transacciones, en el cumplimiento de la PCI. Al igual que los datos del titular de la tarjeta, PCI DSS requiere proteger los SAD. Además, los comerciantes y sus procesadores de pagos no pueden retener los SAD. Los SAD incluyen lo siguiente:
- Datos de "seguimiento" de bandas magnéticas
- "Datos equivalentes al seguimiento" que generan las tarjetas sin contacto y con chip
- Códigos de validación de seguridad (por ejemplo, el número de 3 o 4 dígitos impreso en las tarjetas) que se usa para transacciones en línea y sin tarjeta.
- PIN y bloques de PIN
- 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 pueda ayudar a reducir lo siguiente:
- El alcance y el costo de la evaluación de PCI DSS
- El costo y la dificultad de implementar y mantener los controles de PCI DSS
- El riesgo para una organización (reducido mediante la consolidación de los datos del titular de la tarjeta en menos ubicaciones que están más controladas)
Segmentar el entorno de datos del titular de la tarjeta
El entorno de datos del titular de la tarjeta (CDE) abarca personas, procesos y tecnologías que almacenan, procesan o transmiten datos del titular de la tarjeta o datos de autenticación sensibles. En el contexto de GKE, el CDE también abarca lo siguiente:
- Sistemas que proporcionan servicios de seguridad (por ejemplo, IAM)
- Sistemas que facilitan la segmentación (por ejemplo, proyectos, carpetas, firewalls, nubes privadas virtuales [VPC] y subredes)
- Grupos de aplicaciones y clústeres que almacenan, procesan o transmiten datos de titulares de tarjetas Sin una segmentación adecuada, toda tu huella en la nube puede entrar en el alcance de PCI DSS.
Un componente del sistema, para que se lo considere fuera del alcance de PCI DSS, debe aislarse correctamente del CDE de modo que, incluso si el componente fuera del alcance del sistema se ve comprometido, no pueda afectar la seguridad del CDE.
Un requisito previo importante para reducir el alcance del CDE es una comprensión clara de las necesidades y los procesos empresariales relacionados con el almacenamiento, el procesamiento y la transmisión de los datos del titular de la tarjeta. Restringir los datos del titular de la tarjeta a la menor cantidad de ubicaciones posible mediante la eliminación de datos innecesarios y la consolidación de los datos necesarios puede requerir que vuelvas a diseñar prácticas comerciales de larga duración.
Puedes segmentar correctamente tu CDE a través de varios medios en Google Cloud. En esta sección, se analizan los siguientes medios:
- Segmentación lógica mediante la jerarquía de recursos
- Segmentación de redes mediante VPC y subredes
- Segmentación de nivel de servicio mediante VPC
- Otras consideraciones para cualquier clúster dentro del alcance
Segmentación lógica mediante la jerarquía de recursos
Hay varias formas de aislar tu CDE dentro de tu estructura organizativa mediante la jerarquía de recursos de Google Cloud. Los recursos de Google Cloud están organizados de forma jerárquica. El recurso de Organización es el nodo raíz en la jerarquía de recursos de Google Cloud. Las carpetas y proyectos son parte del recurso de Organización. Las carpetas pueden contener proyectos y carpetas. Las carpetas se usan para controlar el acceso a los recursos en la jerarquía de carpetas a través de los permisos de IAM 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 alcance de PCI dentro de una carpeta para obtener un aislamiento a nivel de carpeta. También puedes usar un proyecto destinado a todos los clústeres y aplicaciones de PCI dentro del alcance o puedes crear un proyecto y un clúster para cada aplicación de PCI dentro del alcance y usarlos a fin de organizar tus recursos de Google Cloud. En cualquier caso, te recomendamos que mantengas tus cargas de trabajo dentro y fuera del alcance en proyectos diferentes.
Segmentación de redes mediante redes y subredes de VPC
Puedes usar una nube privada virtual (VPC) y subredes para aprovisionar tu red, además de agrupar y aislar recursos relacionados con CDE. VPC es un aislamiento lógico de una sección de una nube pública. Las redes de VPC proporcionan herramientas de redes escalables y flexibles para tus instancias de máquinas virtuales (VM) de Compute Engine y los servicios que aprovechan las instancias de VM, incluido GKE. Para obtener más detalles, consulta la Descripción general de VPC y las prácticas recomendadas y arquitecturas de referencia.
Segmentación a nivel de servicio mediante los Controles del servicio de VPC y Google Cloud Armor
Mientras que la VPC y las subredes proporcionan segmentación y crean un perímetro para aislar tu CDE, los Controles del servicio de VPC aumentan el perímetro de seguridad en la capa 7. Puedes usar los Controles del servicio de VPC para crear un perímetro alrededor de tus proyectos de CDE dentro del alcance. Los Controles del servicio de VPC te proporcionan lo siguiente:
- Control de entrada. Solo se permiten las identidades y los clientes autorizados en el perímetro de seguridad.
- Control de salida. Solo se permiten destinos autorizados para identidades y clientes dentro del perímetro de seguridad.
Puedes usar Google Cloud Armor para crear listas de direcciones IP a fin de permitir o denegar el acceso al balanceador de cargas HTTP(S) en el perímetro de la red de Google Cloud. Mediante la examinación de las direcciones IP lo más cerca posible del usuario y del tráfico malicioso, se ayuda a evitar que el tráfico malicioso consuma recursos o ingrese a tus redes de VPC.
Usa los Controles del servicio de VPC para definir un perímetro de servicio alrededor de tus proyectos dentro del alcance. Este perímetro rige las rutas de VM a servicio y de servicio a servicio, además del tráfico de entrada y salida de VPC.
Compila y mantén una red y sistemas seguros
La creación y el mantenimiento de una red segura abarca los requisitos 1 y 2 de PCI DSS.
Requisito 1
Instalar y mantener una configuración de firewall para proteger los datos del titular de la tarjeta y el tráfico que ingresa y sale del CDE.
Los conceptos de Herramientas de redes para contenedores y GKE difieren de los de las VM tradicionales. Los pods pueden comunicarse entre sí directamente, sin NAT, incluso entre distintos nodos. Esto crea una topología de red simple que puede sorprenderte si acostumbras administrar sistemas más complejos. El primer paso en la seguridad de la red para GKE es aprender sobre estos conceptos de red.
Antes de entrar en los requisitos individuales del Requisito 1, es posible que desees revisar los siguientes conceptos de redes en relación con GKE:
Reglas de firewall Las reglas de firewall 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. Dentro de tu red, puedes usar rótulos identificadores para aplicar estas reglas de firewall a cada instancia. Cada grupo de nodos recibe su propio conjunto de rótulos identificadores que puedes usar en las reglas. De forma predeterminada, cada instancia que pertenece a un grupo de nodos recibe un rótulo identificador que identifica un clúster específico de GKE del que forma parte este grupo de nodos. Este rótulo identificador se usa en las reglas de firewall que GKE crea de forma automática para ti. Puedes agregar rótulos identificadores personalizados durante la creación del grupo de nodos o el clúster con la marca
--tagsen la Google Cloud CLI.Políticas de red Las políticas de red te permiten limitar las conexiones de red entre pods, lo que puede restringir la dinamización de red y el movimiento lateral dentro del clúster en caso de problemas de seguridad en un pod. Para usar políticas de red, debes habilitar la característica de forma explícita cuando creas el clúster de GKE. Puedes habilitarlo en un clúster existente, pero eso hará que los nodos del clúster se reinicien. El comportamiento predeterminado es que toda la comunicación de pod a pod siempre está abierta. Por lo tanto, si deseas 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ítica de red de Kubernetes o la herramienta de
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 la segmentación de recursos dentro de tu clúster de Kubernetes. Kubernetes viene con un espacio de nombres predeterminado listo para usar, pero puedes crear múltiples espacios de nombres dentro de tu clúster. Los espacios de nombres están aislados de forma lógica unos de otros. Proporcionan alcance para implementaciones, pods y servicios en el clúster, de modo que los usuarios que interactúan con un espacio de nombres no verán el contenido de otro espacio de nombres. Sin embargo, los espacios de nombres dentro del mismo clúster no restringen la comunicación entre espacios de nombres; aquí es donde entran en juego las políticas de red. Para obtener más información sobre la configuración de espacios de nombres, consulta la entrada de blog Prácticas recomendadas de espacios de nombres.
En el siguiente diagrama, se ilustran los conceptos anteriores en relación con cada uno y con otros componentes de GKE, como el clúster, el nodo y el pod.
Requisito 1.1
Se definen y comprenden los procesos y mecanismos para instalar y mantener los controles de seguridad de red.
Requisito 1.1.2
Describir los grupos, los roles y las responsabilidades de la administración de los componentes de red.
Primero, como lo harías con la mayoría de los servicios en Google Cloud, debes configurar las funciones de IAM para configurar la autorización en GKE. Cuando configures tus funciones de IAM, deberás agregar la configuración de control de acceso basado en funciones de Kubernetes (RBAC) como parte de una estrategia de autorización de Kubernetes.
En esencia, toda la configuración de IAM se aplica a cualquier recurso de Google Cloud y a todos los clústeres dentro de un proyecto. La configuración de RBAC de Kubernetes se aplica a los recursos en cada clúster de Kubernetes y permite una autorización detallada al nivel del espacio de nombres. Con GKE, estos enfoques de autorización funcionan en paralelo, y las capacidades de un usuario representan de forma efectiva una unión de funciones de IAM y RBAC asignadas a ellos:
- Usa IAM para controlar grupos, funciones y responsabilidades en la administración lógica de los componentes de red en GKE.
- Usa Kubernetes RBAC a fin de otorgar permisos detallados para políticas de red dentro de los clústeres de Kubernetes, controlar el tráfico de pod a pod y evitar cambios no autorizados o accidentales de usuarios que no pertenecen a CDE.
- Permite justificar todos los usuarios y permisos de IAM y RBAC. Por lo general, cuando los QSA prueban los controles, buscan una justificación empresarial para una muestra de IAM y RBAC.
Requisito 1.2
Los controles de seguridad de red (NSC) se configuran y mantienen.
Primero, debes configurar reglas de firewall en las instancias de Compute Engine que ejecutan tus nodos de GKE. Las reglas de firewall protegen estos nodos del clúster.
A continuación, configura las políticas de red para restringir los flujos y proteger los pods en 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 extremos de la red. Puedes usar la aplicación de la política de red de GKE para controlar la comunicación entre los pods y los servicios del clúster. Para segmentar aún más tu clúster, crea varios espacios de nombres dentro de él. Los espacios de nombres están aislados de forma lógica unos de otros. Proporcionan alcance para implementaciones, pods y servicios en el clúster, de modo que los usuarios que interactúan con un espacio de nombres no verán el contenido de otro espacio de nombres. Sin embargo, los espacios de nombres dentro del mismo clúster no restringen la comunicación entre espacios de nombres; aquí es donde entran en juego las políticas de red. Los espacios de nombres permiten la segmentación de recursos dentro de tu clúster de Kubernetes. Para obtener más información sobre la configuración de espacios de nombres, consulta la entrada de blog Prácticas recomendadas de espacios de nombres.
De forma predeterminada, si no hay políticas en un espacio de nombres, todo el tráfico de entrada y salida se permite desde y hacia los pods en ese espacio de nombres. Por ejemplo, puedes crear una política de aislamiento predeterminada para un espacio de nombres si creas una política de red que seleccione todos los pods, pero que no permita el tráfico de entrada a esos pods.
Requisito 1.2.2
Todos los cambios en las conexiones de red y los parámetros de configuración de NSC están aprobados y administrados de acuerdo con el proceso de control de cambio definido en el Requisito 6.5.1.
Para tratar la infraestructura y la configuración de red como código, debes establecer una canalización de integración continua y entrega continua (CI/CD) como parte de los procesos de administración y control de cambios.
Puedes usar las plantillas de Cloud Deployment Manager o Terraform como parte de la canalización de IC/EC para crear políticas de red en tus clústeres. Con Deployment Manager o Terraform, puedes tratar la configuración y la infraestructura como un código que puede reproducir copias coherentes de la producción actual o de otros entornos. Luego, puedes escribir pruebas de unidades y otras pruebas para asegurarte de que los cambios en tu red funcionen como se espera. Un proceso de control de cambios que incluye una aprobación se puede administrar mediante archivos de configuración almacenados en un repositorio de versiones.
Con Terraform Config Validator, puedes definir restricciones para hacer cumplir las políticas de seguridad y administración. Si agregas Config Validator a tu canalización de IC/EC, puedes agregar un paso a cualquier flujo de trabajo. Este paso valida un plan de Terraform y lo rechaza si se encuentran violaciones.
Requisito 1.2.5
Todos los servicios, protocolos y puertos permitidos se identifican, aprueban y tienen una necesidad empresarial definida.
Si deseas obtener controles de entrada sólidos para tus clústeres de GKE, puedes usar redes autorizadas a fin de restringir ciertos rangos de IP que pueden alcanzar el plano de control de tu clúster. GKE usa la seguridad de la capa de transporte (TLS) y la autenticación para ofrecer acceso seguro al extremo de la instancia principal del clúster desde la Internet pública. Este acceso te brinda la flexibilidad de administrar tu clúster desde cualquier lugar. Con las redes autorizadas, puedes restringir el acceso solo a conjuntos específicos de direcciones IP.
Puedes usar Google Cloud Armor a fin de crear listas de admisión y denegación de IP, y políticas de seguridad para las aplicaciones alojadas en GKE. En un clúster de GKE, el balanceo de cargas de HTTP(S), que es un componente de Cloud Load Balancing, controla el tráfico entrante. Por lo general, el balanceador de cargas de HTTP(S) se configura con un controlador de entrada de GKE, que obtiene la información de configuración de un objeto Ingress de Kubernetes. Para obtener más información, consulta cómo configurar las políticas de Google 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 las comunicaciones privadas entre los clústeres de GKE dentro de tus redes de VPC y las implementaciones híbridas locales mediante los Controles del servicio de VPC y el Acceso privado a Google.
Requisito 1.3.1
El tráfico entrante al CDE está restringido de la siguiente manera:
- Solo al tráfico necesario.
- El resto del tráfico se rechaza de forma específica.
Considera implementar la configuración de Cloud NAT con GKE para limitar el tráfico de Internet entrante solo a ese clúster. Puedes configurar un clúster privado para los clústeres no públicos en tu CDE. En un clúster privado, los nodos solo tienen direcciones IP internas RFC 1918, lo que garantiza que sus cargas de trabajo estén aisladas de la Internet pública.
Requisito 1.4
Se controlan las conexiones de red entre redes confiables y no confiables.
Puedes abordar este requisito mediante los mismos métodos que se indican en el Requisito 1.3.
Requisito 1.4.3
Las medidas contra la falsificación de identidad se implementan para detectar y bloquear la entrada de direcciones IP de origen falsificadas en la red de confianza.
Implementa medidas contra la Falsificación de identidad mediante direcciones IP de alias en grupos y clústeres de GKE para detectar y bloquear direcciones IP de origen falsificadas. Un clúster que usa rangos de IP de alias se denomina clúster nativo de la VPC.
Requisito 1.4.5
La divulgación de las direcciones IP internas y la información de enrutamiento se limita solo a las partes autorizadas.
Puedes usar un agente de enmascaramiento de IP de GKE a fin de realizar la traducción de direcciones de red (NAT) para las traducciones de direcciones IP de muchos a uno en un clúster. Así, se enmascaran múltiples direcciones IP de origen en una sola dirección.
Requisito 2
Aplicar parámetros de configuración seguros a todos los componentes del sistema.
En el Requisito 2, se especifica cómo endurecer los parámetros de seguridad si se quitan los valores predeterminados y las credenciales que proporciona el proveedor. Endurecer el clúster es una responsabilidad del cliente.
Requisito 2.2
Los componentes del sistema están configurados y administrados 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 endurecimiento del sistema aceptados en la industria. Entre las fuentes de estándares de endurecimiento del sistema aceptados en la industria, se incluyen las siguientes:Requisito 2.2.4
Solo los servicios, protocolos, daemons y funciones necesarios están habilitados, y se quita o inhabilita toda la funcionalidad innecesaria.
Requisito 2.2.5
- La justificación empresarial está documentada.
- 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 están configurados para evitar el uso inadecuado.
Antes de la implementación
Antes de mover contenedores a GKE, recomendamos lo siguiente:
- Comienza con una imagen base administrada de contenedor que sea compilada, mantenida y verificada por una fuente confiable. Considera crear un conjunto de imágenes base “bien conocidas” o “doradas” que tus desarrolladores puedan usar. Una opción más restrictiva es usar una imagen sin distro o una imagen base desde cero.
- Usa Artifact Analysis para analizar las imágenes de tus contenedores en busca de vulnerabilidades.
- Establece una política interna de DevOps/SecOps para incluir solo las bibliotecas y los objetos binarios aprobados y confiables en los contenedores.
Durante la configuración
Durante la configuración, recomendamos lo siguiente:
- Usa el Container-Optimized OS predeterminado como imagen de nodo para GKE. Container-Optimized OS se basa en Chromium OS y está optimizado para la seguridad de nodos.
- Habilita los nodos de actualización automática para los clústeres que ejecutan tus aplicaciones. Esta característica actualiza de forma automática el nodo a la versión de Kubernetes que se ejecuta en el plano de control administrado, lo que proporciona una mayor estabilidad y seguridad.
- Habilita los nodos de reparación automática. Cuando esta característica está habilitada, GKE verifica de forma periódica el estado de salud del nodo para determinar si necesita reparación. Si un nodo requiere reparación, se lo vacía y se crea un nodo nuevo que se agrega 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 ocurre un incidente de seguridad.
- Aplica cuentas de servicio con privilegios mínimos para los nodos de GKE.
- Revisa y aplica (cuando corresponda) la sección de GKE en la guía de CIS Benchmark para Google Cloud. El registro de auditoría de Kubernetes ya está habilitado de forma predeterminada y los registros de ambas solicitudes a
kubectly a la API de GKE se escriben en Cloud Audit Logs. - Configura el registro de auditoría.
Protege los datos de la cuenta
La protección de los datos del titular de la tarjeta abarca los requisitos 3 y 4 de PCI DSS.
Requisito 3
Proteger los datos almacenados de la cuenta.
El Requisito 3 de PCI DSS estipula que las técnicas de protección, como la encriptación, el truncamiento, el enmascaramiento y el hash, son componentes fundamentales de la protección de los datos del titular de la tarjeta. Si un intruso elude otros controles de seguridad y obtiene acceso a datos encriptados, sin las claves criptográficas adecuadas, los datos son ilegibles para esa persona y no podrán usarse.
También puedes considerar otros métodos para proteger los datos almacenados como posibles oportunidades de mitigación de riesgos. Por ejemplo, los métodos para minimizar el riesgo incluyen no almacenar los datos del titular de la tarjeta si no es absolutamente necesario, truncar los datos del titular de la tarjeta si no se necesita el PAN completo y no enviar PAN sin protección mediante tecnologías de mensajería para el usuario final, como correo electrónico y mensajería instantánea.
Estos son algunos ejemplos de sistemas en los que CHD puede persistir como parte de los flujos de procesamiento de pagos cuando se ejecutan en Google Cloud:
- Depósitos de Cloud Storage
- Instancias de BigQuery
- Datastore
- Cloud SQL
Ten en cuenta que CHD podría almacenarse de forma inadvertida en correos electrónicos o registros de comunicación de atención al cliente. Es prudente usar la protección de datos sensibles para filtrar estas transmisiones de datos, de modo que limites tu entorno dentro del permiso a los sistemas de procesamiento de pagos.
Ten en cuenta que, en Google Cloud, los datos están encriptados en reposo de forma predeterminada y encriptados en tránsito de forma predeterminada cuando traspasan límites físicos. No es necesaria ninguna configuración adicional para habilitar estas protecciones.
Requisito 3.5
El número de cuenta principal (PAN) se protege donde sea que se almacene.
Un mecanismo para hacer que los datos PAN sean ilegibles es la tokenización. A fin de obtener más información, consulta la guía de soluciones sobre la tokenización de datos sensibles del titular de la tarjeta para PCI DSS.
Puedes usar la API de DLP para escanear, descubrir y, además, informar los datos del titular de la tarjeta. La protección de datos sensibles tiene compatibilidad nativa con el análisis y la clasificación de datos PAN de 12 a 19 dígitos en Cloud Storage, BigQuery y Datastore. También tiene una API de contenido de transmisión para habilitar la compatibilidad con fuentes de datos adicionales, cargas de trabajo personalizadas y aplicaciones. También puedes usar la API de DLP para truncar (ocultar) o hacer un hash de los datos.
Requisito 3.6
Las claves criptográficas que se usan para proteger los datos de la cuenta almacenada están protegidas.
Cloud Key Management Service (KMS) es un sistema de almacenamiento administrado para claves criptográficas. Puede generar, usar, rotar y destruir claves criptográficas. Aunque Cloud KMS no almacena secretos directamente, como los datos del titular de la tarjeta, se puede usar para encriptar dichos datos.
Los secretos en el contexto de Kubernetes son objetos secretos que te permiten almacenar y administrar información sensible, como contraseñas, tokens y claves.
De forma predeterminada, Google Cloud encripta el contenido del cliente almacenado en reposo. GKE controla y administra esta encriptación predeterminada sin que debas realizar ninguna acción adicional. La encriptación de secretos de la capa de aplicación proporciona una capa adicional de seguridad para datos sensibles, como los secretos. Con esta funcionalidad, puedes proporcionar una clave que administres en Cloud KMS para encriptar datos en la capa de aplicación. Esto otorga protección contra los atacantes que obtienen acceso a una copia de la instancia de almacenamiento de configuración de Kubernetes de tu clúster.
Requisito 4
Proteger los datos del titular de la tarjeta con criptografía sólida durante la transmisión en redes abiertas y públicas.
Los datos dentro del alcance deben encriptarse durante la transmisión a través de redes a las que acceden con facilidad las personas malintencionadas, por ejemplo, las redes públicas.
Istio es una malla de servicios de código abierto que se aplica de manera transparente a las aplicaciones distribuidas existentes. Istio administra de forma escalable la autenticación, la autorización y la encriptación del tráfico entre microservicios. Es una plataforma que incluye API que te permiten integrarte en cualquier plataforma de registro, telemetría o sistema de políticas. El conjunto de características de Istio te permite ejecutar con eficiencia una arquitectura de microservicios distribuidos y proporciona una manera uniforme de proteger, conectar y supervisar microservicios.
Requisito 4.1
Los procesos y mecanismos para proteger los datos del titular de la tarjeta con criptografía sólida durante la transmisión en redes abiertas y públicas se definen y documentan.
Puedes usar Istio para crear una red de servicios implementados con balanceo de cargas, autenticación de servicio a servicio y supervisión. También puedes usarlo para entregar comunicaciones seguras de servicio a servicio en un clúster con autenticación sólida basada en la identidad y autorización basada en TLS mutua. La TLS mutua (mTLS) es un protocolo de enlace TLS que se realiza dos veces y establece el mismo nivel de confianza en ambas direcciones (en lugar de la confianza unidireccional entre cliente y servidor).
Istio te permite implementar certificados TLS en cada uno de los pods de GKE dentro de una aplicación. Los servicios que se ejecutan en el pod pueden usar mTLS para identificar con claridad sus identidades de intercambio de tráfico. La comunicación de servicio a servicio se canaliza a través de los proxies de Envoy del cliente y del servidor. Envoy usa ID de SPIFFE para establecer conexiones mTLS entre servicios. Para obtener información sobre la implementación de Istio on GKE, consulta la documentación de GKE. Para obtener información sobre las versiones compatibles de TLS, consulta la referencia de administración de tráfico de Istio. Usa la versión 1.2 de TLS y las posteriores.
Si tu aplicación está expuesta a Internet, usa el balanceo de cargas HTTP(S) de GKE con el enrutamiento de entrada configurado para usar HTTP(S). El balanceo de cargas HTTP(S), configurado mediante un objeto Ingress, incluye las siguientes características:
- Configuración flexible para servicios Un objeto Ingress define cómo el tráfico llega a tus servicios y cómo se enruta el tráfico a tu aplicación. Además, un objeto Ingress puede proporcionar una única dirección IP para varios servicios en el clúster.
- Integración con servicios de red de Google Cloud. Un objeto Ingress puede configurar características de Google Cloud como Certificados SSL administrados por Google (Beta), Google Cloud Armor, Cloud CDN y Identity-Aware Proxy.
- Compatibilidad con múltiples certificados TLS Un objeto Ingress puede especificar el uso de múltiples certificados TLS para la terminación de las solicitudes.
Cuando creas un objeto Ingress, el controlador de entrada de GKE crea un balanceador de cargas HTTP(S) de Cloud y lo configura según la información en el Ingress y sus servicios asociados.
Mantener un programa de administración de vulnerabilidades
El mantenimiento de un programa de administración de vulnerabilidades abarca los requisitos 5 y 6 de PCI DSS.
Requisito 5
Proteger todos los sistemas y las redes de software malicioso.
El requisito 5 de PCI DSS estipula que el software antivirus debe usarse en todos los sistemas que suelen verse afectados por software malicioso para proteger los sistemas de amenazas de software malicioso actuales y cambiantes. Los contenedores no son una excepción.
Requisito 5.2
El software malicioso (software malicioso) se evita, o se detecta y se aborda.
Debes implementar programas de administración de vulnerabilidades para tus imágenes de contenedor.
Recomendamos las siguientes acciones:
- Verifica y aplica con regularidad parches de seguridad actualizados en los contenedores.
- Realiza análisis de vulnerabilidades con regularidad en aplicaciones en contenedores y archivos binarios o bibliotecas.
- Analiza las imágenes como parte de la canalización de compilación.
- Suscríbete a un servicio de inteligencia de vulnerabilidad para recibir información actualizada de vulnerabilidad que sea relevante para el entorno y las bibliotecas que se usan en los contenedores
Google Cloud trabaja con varios proveedores de soluciones de seguridad de contenedores para mejorar la postura de seguridad dentro de las implementaciones de Google Cloud de los clientes. Recomendamos aprovechar las soluciones y tecnologías de seguridad validadas para aumentar la profundidad de la defensa en tu entorno de GKE. Para obtener la lista más reciente de socios de seguridad validados por Google Cloud, consulta la sección Socios de seguridad.
Requisito 5.2.2
Las soluciones contra software malicioso que se implementaron:
- Detecta todos los tipos conocidos de software malicioso.
- Quita, bloquea o contiene todos los tipos conocidos de software malicioso.
Requisito 5.2.3
Todos los componentes del sistema que no están en riesgo de software malicioso se evalúan de forma periódica a fin de incluir lo siguiente:
- Una lista documentada de todos los componentes del sistema que no están en riesgo de software malicioso.
- Identificación y evaluación de las amenazas de software malicioso en evolución para esos componentes del sistema.
- La confirmación de si esos componentes del sistema continúan no requieren protección contra software malicioso.
Hay muchas soluciones disponibles para realizar análisis de software malicioso, pero PCI DSS reconoce que no todos los sistemas tienen la misma probabilidad de ser vulnerables. Es común que los comerciantes declaren que sus servidores Linux, mainframes y máquinas similares no suelen verse afectados por software malicioso y, por lo tanto, están exentos del requisito 5.2.2. En ese caso, se aplica el 5.2.3 y debes implementar un sistema para las evaluaciones periódicas de amenazas.
Ten en cuenta que estas reglas se aplican a los nodos y a los pods dentro de un clúster de GKE.
Requisito 5.3
Los mecanismos y procesos contra software malicioso están activos, mantenidos y supervisados.
Los requisitos 5.2, 5.3 y 11.5 requieren análisis antivirus y supervisión de integridad de archivos (FIM) en cualquier host dentro del alcance. Recomendamos implementar una solución en la que todos los nodos puedan ser analizados mediante un agente de confianza dentro del clúster o en la que cada nodo tenga un escáner que envíe los informes a un único extremo de administración.
Si deseas obtener más información, consulta la descripción general de seguridad para GKE y la descripción general de seguridad para Container-Optimized OS.
Una solución común para los requisitos de antivirus y FIM es bloquear tu contenedor para que solo las carpetas permitidas específicas tengan acceso de escritura. Para ello, debes ejecutar tus contenedores como usuario no raíz y usar permisos del sistema de archivos para evitar el acceso de escritura a todos los directorios que funcionan dentro del sistema contenedor de archivos. No permitir la elevación de privilegios para evitar la evasión de las reglas del sistema de archivos.
Requisito 6
Desarrollar y mantener sistemas y aplicaciones seguros.
El requisito 6 de PCI DSS estipula que establezcas un ciclo de vida de desarrollo de software sólido en el que se incorpore la seguridad en cada paso del desarrollo de software.
Requisito 6.2
Los software personalizados y personalizados se desarrollan de manera segura.
Requisito 6.2.1
El software a medida y personalizado se desarrolla de forma segura, de la siguiente manera:
- Basado en estándares de la industria o prácticas recomendadas para el desarrollo seguro.
- De acuerdo con PCI DSS (por ejemplo, autenticación y registro seguros).
- Incorporar la consideración de los problemas de seguridad de la información durante cada etapa del ciclo de vida del desarrollo de software.
Puedes usar la autorización binaria para garantizar que solo se implementen los contenedores de confianza en GKE. Si solo quieres habilitar imágenes autorizadas por uno o más certificadores específicos, puedes configurar la autorización binaria para aplicar una política con reglas que requieran certificaciones según los resultados del análisis de vulnerabilidades. También puedes escribir políticas que requieran que una o más partes de confianza (denominadas “certificadores”) aprueben una imagen antes de implementarla. Para una canalización de implementación de etapas múltiples en la que las imágenes progresan desde el desarrollo hasta las pruebas y los clústeres de producción, puedes usar certificadores a fin de asegurarte de que todos los procesos necesarios se hayan completado antes de que el software pase a la siguiente etapa.
En el momento de la implementación, la autorización binaria aplica tu política porque verifica que la imagen del contenedor satisface todas las restricciones obligatorias, incluso la de que todos los certificadores requeridos hayan verificado que la imagen esté lista para la implementación. Si la imagen se aprueba, el servicio permite que se implemente. De lo contrario, la implementación se bloquea y la imagen no se puede implementar hasta que satisfaga los requisitos.
Para obtener más información sobre la autorización binaria, consulta Configura GKE.
En una emergencia, puedes omitir una política de autorización binaria mediante el flujo de trabajo de emergencia. Todos los incidentes que requieren flujos de trabajo de emergencia se registran en Cloud Audit Logs.
GKE Sandbox disminuye la necesidad de que el contenedor interactúe directamente con el host. De esta forma, se reduce la superficie de ataque para la vulneración de esta máquina y se limitan las acciones de personas maliciosas.
Requisito 6.3
Las vulnerabilidades de seguridad se identifican y abordan.
Requisito 6.3.1
Las vulnerabilidades de seguridad se identifican y administran de la siguiente manera:
- Las vulnerabilidades de seguridad nuevas se identifican mediante fuentes reconocidas por la industria para la información de vulnerabilidad de seguridad, que incluyen alertas de equipos de respuesta ante emergencias informáticas internacionales y nacionales.
- A las vulnerabilidades se les asigna una clasificación de riesgos según las prácticas recomendadas de la industria y el impacto del posible impacto.
- 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 para software personalizado y de terceros, y el software 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 administra el plano de control, que incluye las VM principales, el servidor de API y otros componentes que se ejecutan en esas VM, además de la base de datos de etcd. Esto incluye actualizaciones y parches, escalamiento y reparaciones, todo respaldado por un objetivo de nivel de servicio (SLO). En el sistema operativo de los nodos, como Container-Optimized OS o Ubuntu, GKE pone a disposición cualquier parche para estas imágenes con rapidez. Si habilitaste la actualización automática, estos parches se implementarán de forma automática. Esta es la capa base de tu contenedor; 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 Explora la seguridad del contenedor: el modelo de responsabilidad compartida en GKE.
Google proporciona varios servicios de seguridad para ayudar a generar la seguridad en tu canalización de IC/EC. Para identificar las vulnerabilidades en tus imágenes de contenedor, puedes usar el análisis de vulnerabilidades de Google Artifact Analysis. Cuando una imagen de contenedor se envía a Google Container Registry (GCR), el análisis de vulnerabilidades escanea de forma automática las imágenes en busca de vulnerabilidades y exposiciones conocidas de fuentes conocidas de CVE. A las vulnerabilidades se les asignan niveles de gravedad (crítico, alto, medio, bajo y mínimo) según las puntuaciones de CVSS.
Requisito 6.4
Las aplicaciones web públicas están protegidas contra ataques.
Web Security Scanner te permite analizar aplicaciones web orientadas al público de App Engine, Compute Engine y GKE en busca de vulnerabilidades comunes que van desde secuencias de comandos entre sitios y configuraciones incorrectas hasta recursos vulnerables. Los análisis se pueden realizar a pedido y programar desde la consola de Google Cloud. Con las API de Security Scanner, puedes automatizar el análisis como parte de tu conjunto de pruebas de seguridad en la canalización de compilación de tu aplicación.
Implementa medidas sólidas de control de acceso
La implementación de medidas sólidas de control de acceso abarca los requisitos 7, 8 y 9 de PCI DSS.
Requisito 7
Restringe el acceso a los componentes del sistema y a los datos del titular de la tarjeta por parte de la empresa.
El requisito 7 se enfoca en los principios de privilegio mínimo o acceso mínimo. PCI DSS define estos principios como aquellos que otorgan acceso a la menor cantidad de datos y proporcionan la menor cantidad de privilegios necesarios para realizar un trabajo.
Requisito 7.2
El acceso a los componentes y datos del sistema se define y asigna de forma adecuada.
IAM y el el control de acceso basado en funciones (RBAC) de Kubernetes trabajan en conjunto para proporcionar un control de acceso detallado a tu entorno de GKE. IAM se usa para administrar el acceso de los usuarios y los permisos de los recursos de Google Cloud en tu proyecto de CDE. En GKE, también puedes usar IAM para administrar el acceso y las acciones que los usuarios y las cuentas de servicio pueden realizar en tus clústeres, como crearlos y borrarlos.
RBAC de Kubernetes te permite configurar conjuntos de permisos detallados que definen cómo un usuario determinado de Google Cloud, las cuentas de servicio de Google Cloud o los grupos de usuarios (Grupos de Google) pueden interactuar con cualquier objeto de Kubernetes o espacio de nombres específico de tu clúster. Los ejemplos de permisos RBAC incluyen la edición de implementaciones o mapas de configuración, la eliminación de pods o la visualización de registros desde un pod. Debes otorgar a los usuarios o servicios permisos limitados de IAM, como Visualizador de clústeres de Google Kubernetes Engine o funciones personalizadas, y luego aplicar Kubernetes RBAC RoleBindings según corresponda.
Cloud Identity Aware Proxy (IAP) se puede integrar a través de la entrada para que GKE controle el acceso a nivel de aplicación de los empleados o personas que necesitan acceso a tus aplicaciones de PCI.
Además, puedes usar políticas de la organización para restringir las APIs y los servicios que están disponibles dentro de un proyecto.
Requisito 7.2.2
El acceso se asigna a los usuarios, incluidos los usuarios privilegiados, en función de lo siguiente:
- Clasificación y función de trabajos.
- Privilegios mínimos necesarios para cumplir con las responsabilidades del trabajo.
Debes asegurarte de que los usuarios, las cuentas de servicio y, también, los contenedores cumplan con el principio de privilegio mínimo. Una práctica recomendada para la ejecución de un contenedor es ejecutar el proceso con un usuario no raíz. Para cumplir y aplicar esta práctica, puedes usar 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 abarcan las necesidades de alto nivel de la seguridad de Pods en Kubernetes. Estas políticas van desde muy permisivas hasta muy restrictivas. PodSecurity reemplaza al controlador de admisión PodSecurityPolicy anterior que se quitó en Kubernetes v1.25. Las instrucciones están disponibles para migrar de PodSecurityPolicy al controlador de admisión PodSecurity.
Requisito 8
Identifica usuarios y autentica 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 de PCI dentro del alcance para garantizar que cada individuo sea el único responsable de sus acciones.
Requisito 8.2
La identificación de usuarios y las cuentas relacionadas para usuarios y administradores se administran de forma estricta durante 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 permita el acceso a los componentes del sistema o a los datos del titular de la tarjeta.
Requisito 8.2.5
El acceso de los usuarios rescindidos se revoca de inmediato.
IAM y RBAC de Kubernetes se pueden usar para controlar el acceso a tu clúster de GKE y, en ambos casos, puedes otorgar permisos a un usuario. Recomendamos que los usuarios se vinculen a tu sistema de identidad existente para que puedas administrar las cuentas de usuario y las políticas en una ubicación.
Requisito 8.3
Se establece y administra una autenticación sólida para los usuarios y administradores.
Requisito 8.3.1
- Algo que conoces, como una contraseña o frase de contraseña.
- Algo que tienes, como un dispositivo de token o una tarjeta inteligente.
- Algo que eres, como un elemento biométrico.
Los certificados están vinculados a la identidad de un usuario cuando se realiza la autenticación en kubectl.
Todos los clústeres de GKE están configurados para aceptar las identidades de las cuentas de servicio y usuarios de Google Cloud, mediante la validación de las credenciales y la recuperación de la dirección de correo electrónico asociada con la identidad de la cuenta de servicio o usuario. Como resultado, las credenciales de esas cuentas deben incluir el alcance de OAuth userinfo.email para autenticarse de forma correcta.
Requisito 9
Restringe el acceso físico a los datos del titular de la tarjeta.
Google es responsable de los controles de seguridad física en todos los Centros de datos de Google subyacentes a Google Cloud.
Supervisa y prueba las redes con regularidad
Supervisar y probar las redes con regularidad abarca los requisitos 10 y 11 de PCI DSS.
Requisito 10
Registra y supervisa todo el acceso a los componentes del sistema y a los datos del titular de la tarjeta.
Requisito 10.2
Los registros de auditoría se implementan para admitir la detección de anomalías y la actividad sospechosa, y el análisis forense de los eventos.
Los clústeres de Kubernetes tienen los registros de auditoría de Kubernetes habilitados de forma predeterminada, lo que mantiene un registro cronológico de las llamadas que se hicieron al servidor de la API de Kubernetes. Las entradas de registro de auditoría de Kubernetes son útiles a fin de investigar solicitudes a la API sospechosas, recopilar estadísticas o crear alertas de supervisión para llamadas a la API no deseadas.
Los clústeres de GKE integran una configuración predeterminada para el registro de auditoría de GKE con Cloud Audit Logs y Logging. Puedes ver las entradas de registro de auditoría de Kubernetes en el proyecto de Google Cloud.
Además de las entradas que escriba Kubernetes, los registros de auditoría de tu proyecto tienen entradas escritas por GKE.
Para diferenciar tus cargas de trabajo de CDE de las que no lo son, te recomendamos que agregues etiquetas a tus pods de GKE que se filtrarán a las métricas y registros que emitan esas cargas de trabajo.
Requisito 10.2.2
- Identificación del usuario
- Tipo de evento
- Fecha y hora
- Indicación de éxito o falla
- Origen del evento
- Identidad o nombre de los datos, los componentes del sistema, los recursos o los servicios afectados (por ejemplo, el nombre y el 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 de registro de auditoría es un objeto de tipoAuditLog. Puedes encontrar la identidad del usuario en el campoAuthenticationInfode los objetosAuditLog. - El evento específico, que se puede encontrar en el campo
methodNamedeAuditLog. - Una marca de tiempo.
- El estado del evento, que se puede encontrar en los objetos
responsedel objetoAuditLog. - La solicitud de operación, que se puede encontrar en los objetos
requestyrequestMetadatadel objetoAuditLog. - El servicio que se realizará, que se puede encontrar en el objeto
AuditDatadeserviceData.
Requisito 11
Prueba la seguridad de los sistemas y las redes con regularidad.
Requisito 11.3
Las vulnerabilidades internas y externas se identifican, priorizan y abordan con regularidad.
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 del riesgo de vulnerabilidad de la entidad definidas en el Requisito 6.3.1).
- Se realizan análisis nuevos que confirman que se resolvieron todas las vulnerabilidades críticas y de alto riesgo (como se mencionó antes).
- La herramienta de análisis se mantiene actualizada con la información más reciente sobre las vulnerabilidades.
- El personal calificado y la independencia organizacional del verificador realizan los análisis.
El análisis de vulnerabilidades de Artifact Analysis realiza los siguientes tipos de análisis de vulnerabilidades para las imágenes en Container Registry:
Análisis inicial. Cuando activas por primera vez la API de Artifact Analysis, analiza tus imágenes en Container Registry y extrae el administrador de paquetes, la base de imágenes y los casos 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 de vulnerabilidad nueva y actualizada de fuentes de vulnerabilidad, vuelve a ejecutar el análisis de contenedores a fin de mantener actualizada la lista de casos de vulnerabilidad para imágenes ya analizadas.
Requisito 11.5
Se detectan y se responden las intrusiones en la red y los cambios inesperados en los archivos.
Requisito 11.5.1
- Todo el tráfico se supervisa en el perímetro del CDE.
- Todo el tráfico se supervisa en puntos críticos del CDE.
- Se alerta al personal sobre posibles sospechas.
- Todos los motores de detección y prevención de intrusiones, los modelos de referencia y las firmas se mantienen actualizados.
La duplicación de paquetes de Google Cloud se puede usar con IDS de Cloud para detectar intrusiones en la red. La duplicación de paquetes de Google Cloud reenvía todo el tráfico de red de tus VM de Compute Engine o clústeres de Google Cloud a una dirección designada. IDS de Cloud puede consumir este tráfico duplicado para detectar un amplio rango de amenazas, como intentos de explotación, análisis de puertos, desbordamiento de búfer, fragmentación de protocolos, tráfico de comando y control (C2) y software malicioso.
Security Command Center te brinda visibilidad centralizada del estado de seguridad de los servicios de Google Cloud (incluido GKE) y los activos en toda tu organización, lo que facilita la prevención, detección y respuesta de amenazas. Mediante Security Command Center, puedes ver si se detectaron amenazas de alto riesgo, como software maliciosos, criptominería, acceso no autorizado a recursos de Google Cloud, ataques salientes de DSD, análisis de puertos y conexiones SSH por fuerza bruta en función de los registros de Cloud Logging.
Mantén una política de seguridad de la información
Una política de seguridad sólida establece el tono de seguridad y, además, informa a las personas qué se espera de ellos. En este caso, “personas” hace referencia a empleados de tiempo completo y parcial, empleados temporales, contratistas y consultores que tienen acceso a tu CDE.
Requisito 12
Respalda la seguridad de la información con los programas y políticas de la organización.
Para obtener información sobre el requisito 12, consulta la Matriz de responsabilidad compartida de PCI de Google Cloud.
Realiza una limpieza
Si usaste algún recurso mientras seguías este artículo (por ejemplo, si iniciaste VM nuevas o usaste las secuencias de comandos de Terraform), puedes evitar incurrir en cargos en tu cuenta de Google Cloud si borras el proyecto en el que usaste esos recursos.
- En la consola de Google Cloud, ve a la página Administrar recursos.
- En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
- En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.
¿Qué sigue?
- Obtén más información sobre el cumplimiento de los estándares de seguridad de los datos de PCI.
- Prueba el kit de inicio de Terraform.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.