Este guia destina-se a ajudá-lo a resolver problemas específicos dos aplicativos do Google Kubernetes Engine (GKE) ao implementar as responsabilidades dos clientes sobre os requisitos do Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS, na sigla em inglês).
Exoneração de responsabilidade: este guia é apenas informativo. As informações e recomendações fornecidas aqui pelo Google não constituem assessoria jurídica ou de auditoria. Cada cliente é responsável pela avaliação do próprio uso dos serviços, conforme apropriado, para conciliar suas obrigações legais e de conformidade.
Introdução à conformidade com o PCI DSS e o GKE
Se você manipula dados do cartão de pagamento, é preciso protegê-los, independentemente de onde eles residem, em um banco de dados local ou na nuvem. O PCI DSS foi desenvolvido para incentivar e aprimorar a segurança dos dados do titular do cartão e facilitar a ampla adoção de medidas de segurança de dados consistentes em todo o mundo. Ele proporciona um valor de referência dos requisitos técnicos e operacionais desenvolvidos para proteger dados de cartão de crédito. O PCI DSS aplica-se a todas as entidades envolvidas no processamento de cartões de pagamento, incluindo comerciantes, processadores, adquirentes, emissores e provedores de serviços. O PCI DSS também se aplica a todas as outras entidades que armazenam, processam ou transmitem dados do titular do cartão (CHD, na sigla em inglês) ou dados de autenticação confidenciais (SAD, na sigla em inglês), ou ambos.
Os aplicativos em contêineres tornaram-se muito usados recentemente com muitas cargas de trabalho legadas migrando de uma arquitetura baseada em máquina virtual (VM, na sigla em inglês) para uma em contêiner. O Google Kubernetes Engine é um ambiente gerenciado, pronto para produção para implantação de aplicativos em contêineres. Ele inclui as mais recentes inovações do Google em produtividade para desenvolvedores, eficiência de recursos, operações automatizadas e a flexibilidade do código aberto para acelerar o tempo de lançamento.
A conformidade é uma responsabilidade compartilhada na nuvem. O Google Cloud, incluindo o GKE (modos de operação Autopilot e Standard), adere aos requisitos do PCI DSS. As nossas responsabilidades estão descritas na matriz de responsabilidade compartilhada.
Público-alvo
- Clientes que queiram levar cargas de trabalho compatíveis com PCI para o Google Cloud que envolvam o GKE.
- Desenvolvedores, agentes de segurança e de conformidade, administradores de TI e outros funcionários responsáveis pela implementação de controles e pela garantia da conformidade com os requisitos do PCI DSS.
Antes de começar
Para as próximas recomendações, provavelmente será necessário usar o seguinte:
- Recursos de projeto, pasta e organização do Google Cloud
- Identity and Access Management (IAM)
- Google Kubernetes Engine
- VPCs do Google Cloud
- Google Cloud Armor
- API Cloud Data Loss Prevention (parte da proteção de dados confidenciais)
- Identity-Aware Proxy (IAP)
- Security Command Center
Este guia destina-se a pessoas familiarizadas com contêineres e o GKE.
Escopo
Neste guia, você verá os seguintes requisitos do PCI DSS que são preocupações exclusivas do GKE e as orientações para solucioná-las. Ele foi redigido na versão 4.0 da norma. Este guia não abrange todos os requisitos do PCI DSS. As informações fornecidas neste guia podem ajudar as organizações a manter a conformidade com o PCI DSS, mas não são um conselho abrangente. As organizações podem usar um avaliador de segurança qualificado do PCI (QSA, na sigla em inglês) para validação formal.
Terminologia
Nesta seção, são definidos os termos usados neste guia. Para mais informações, consulte o glossário do PCI DSS.
- CHD
Dados do titular do cartão: consiste, pelo menos, no número completo da conta principal (PAN, na sigla em inglês). Os dados do titular do cartão também podem aparecer na forma do PAN completo, mais algum destes itens:
- Nome do titular do cartão
- Data de validade e/ou código de serviço
- Dados de autenticação confidenciais (SAD, na sigla em inglês)
- CDE
ambiente de dados do titular do cartão. As pessoas, os processos e a tecnologia que armazenam, processam ou transmitem dados do titular do cartão ou de autenticação confidenciais.
- PAN
Número da conta principal: um item fundamental dos dados do titular de cartão que precisa ser protegido no âmbito do PCI DSS. O PAN geralmente é um número de 16 dígitos exclusivo de um cartão de pagamento (crédito e débito) que identifica o emissor e a conta do titular do cartão.
- PIN
número de identificação pessoal. Uma senha numérica conhecida apenas pelo usuário e pelo sistema, que serve para autenticar esse usuário no sistema.
- QSA
assessor de segurança qualificado. Pessoa certificada pelo PCI Security Standards Council para realizar auditorias e análises de conformidade.
- SAD
Dados de autenticação confidenciais: em conformidade com o PCI, dados usados pelos emissores de cartões para autorizar transações. Semelhante aos dados do titular do cartão, o PCI DSS requer a proteção do SAD. Além disso, os comerciantes e seus processadores de pagamento não podem retê-lo. O SAD inclui o seguinte:
- "Rastreamento" de dados de tarjas magnéticas
- "Rastreamento de dados equivalentes" gerados pelo chip e por cartões por aproximação
- Códigos de validação de segurança (por exemplo, o número de 3 a 4 dígitos impresso em cartões) usado para transações on-line e sem o cartão.
- PINs e blocos de PIN
- segmentação
No contexto do PCI DSS, é a prática de isolar o CDE do restante da rede da entidade. A segmentação não é um requisito do PCI DSS. No entanto, é recomendável como um método para ajudar a reduzir o seguinte:
- O escopo e o custo da avaliação do PCI DSS
- O custo e a dificuldade de implementar e manter os controles PCI DSS
- O risco para uma organização (reduzido pela consolidação dos dados do titular do cartão em menos locais mais controlados)
Segmentar o ambiente de dados do titular do cartão
O ambiente de dados do titular do cartão (CDE, na sigla em inglês) é composto por pessoas, processos e tecnologias que armazenam, processam ou transmitem dados do titular do cartão ou de autenticação confidenciais. No contexto do GKE, o CDE também abrange o seguinte:
- Sistemas que fornecem serviços de segurança, por exemplo, IAM.
- Sistemas que facilitam a segmentação, por exemplo, projetos, pastas, firewalls, nuvens privadas virtuais (VPCs, na sigla em inglês) e sub-redes.
- Pods de aplicativos e clusters que armazenam, processam ou transmitem dados do titular do cartão. Sem uma segmentação adequada, toda a abrangência da nuvem pode entrar no escopo do PCI DSS.
Para ser considerado fora do escopo do PCI DSS, é necessário isolar adequadamente do CDE um componente do sistema de modo que, mesmo se o componente de sistema fora do escopo for comprometido, não afetará a segurança do CDE.
Um pré-requisito importante para reduzir o escopo do CDE é o entendimento claro das necessidades de negócios e dos processos relacionados ao armazenamento, processamento e transmissão dos dados do titular do cartão. A restrição dos dados do titular do cartão ao menor número possível de locais, eliminando dados desnecessários e consolidando os dados necessários, pode exigir a reformulação de práticas comerciais de longa data.
É possível segmentar adequadamente seu CDE de várias maneiras no Google Cloud. Nesta seção, abordamos as seguintes formas:
- Segmentação lógica usando a hierarquia de recursos
- Segmentação de rede usando VPCs e sub-redes
- Segmentação de nível de serviço usando VPC
- Outras considerações para qualquer cluster no escopo
Segmentação lógica usando a hierarquia de recursos
Há várias maneiras de isolar o CDE na estrutura organizacional usando a hierarquia de recursos do Google Cloud. Os recursos do Google Cloud são organizados hierarquicamente. O recurso "Organização" é o nó raiz na hierarquia de recursos do Google Cloud. As pastas e os projetos enquadram-se no recurso "Organização". As pastas podem conter projetos e pastas. Elas são usadas para controlar o acesso a recursos na hierarquia de pastas por meio de permissões de IAM no nível da pasta. Elas também são usadas para agrupar projetos semelhantes. Um projeto é um limite de confiança para todos os seus recursos e um ponto de aplicação do IAM.
Você talvez queira agrupar todos os projetos que estão no escopo do PCI dentro de uma pasta para isolar no nível da pasta. Também é possível usar um projeto para todos os clusters do PCI e aplicativos no escopo ou criar um projeto e um cluster para cada aplicativo do PCI no escopo, e usá-los para organizar seus recursos do Google Cloud. De qualquer forma, recomendamos que você mantenha as cargas de trabalho dentro e fora do escopo em diferentes projetos.
Segmentação de rede usando redes VPC e sub-redes
É possível usar a nuvem privada virtual (VPC, na sigla em inglês) e sub-redes para provisionar sua rede e agrupar e isolar recursos relacionados a CDE. A VPC é um isolamento lógico de uma seção em uma nuvem pública. As redes VPC fornecem redes escalonáveis e flexíveis para suas instâncias de máquina virtual (VM, na sigla em inglês) do Compute Engine e para os serviços que aproveitam as instâncias de VM, incluindo o GKE. Para mais informações, consulte a visão geral da VPC e consulte as práticas recomendadas e as arquiteturas de referência.
Segmentação no nível do serviço usando o VPC Service Controls e o Google Cloud Armor
Enquanto a VPC e as sub-redes fornecem segmentação e criam um perímetro para isolar seu CDE, os VPC Service Controls aumentam o perímetro de segurança na camada 7. É possível usar os controles de serviço da VPC para criar um perímetro ao redor dos projetos CDE no escopo. Os VPC Service Controls oferecem os seguintes controles:
- Controle de entrada: somente identidades e clientes autorizados podem acessar o perímetro de segurança.
- Controle de saída: somente destinos autorizados têm permissão para identidades e clientes dentro do perímetro de segurança.
É possível usar o Google Cloud Armor para criar listas de endereços IP para permitir ou negar acesso ao balanceador de carga HTTP(S) na extremidade da rede do Google Cloud. Ao examinar endereços IP o mais perto possível do usuário e do tráfego malicioso, você ajuda a impedir que o tráfego malicioso consuma recursos ou acesse suas redes VPC.
Use os VPC Service Controls para definir um perímetro de serviço em torno dos projetos em escopo. Esse perímetro rege os caminhos da VM ao serviço e do serviço ao serviço, bem como o tráfego de entrada e de saída da VPC.
Criar e manter uma rede e sistemas seguros
A criação e manutenção de uma rede segura engloba os requisitos 1 e 2 do PCI DSS.
Requisito 1
Instale e mantenha uma configuração de firewall para proteger os dados do titular do cartão e o tráfego de entrada e saída do CDE.
Os conceitos de rede para contêineres e GKE diferem daqueles para VMs tradicionais. Os pods podem comunicar-se diretamente, sem NAT, mesmo entre nós. Isso cria uma topologia de rede simples que pode surpreender se você estiver acostumado a gerenciar sistemas mais complexos. A primeira etapa na segurança de rede para o GKE é aprender sobre esses conceitos de rede.
Antes de se aprofundar nos requisitos individuais do requisito 1, convém revisar os seguintes conceitos de rede em relação ao GKE:
Regras de firewall: as regras de firewall são usadas para restringir o tráfego para seus nós. Os nós do GKE são provisionados como instâncias do Compute Engine e usam os mesmos mecanismos de firewall que outras instâncias. Em sua rede, é possível usar tags para aplicar essas regras de firewall a cada instância. Cada pool de nós recebe o próprio conjunto de tags que pode ser usado nas regras. Por padrão, cada instância pertencente a um pool de nós recebe uma tag que identifica um cluster específico do GKE do qual esse pool de nós faz parte. Essa tag é usada em regras de firewall que o GKE cria automaticamente para você. É possível adicionar tags personalizadas no momento da criação do pool de nós ou do cluster usando a sinalização
--tagsna Google Cloud CLI.Políticas de rede: com as políticas de rede, é possível limitar as conexões de rede entre os pods, o que pode ajudar a restringir a dinamização da rede e a movimentação lateral dentro do cluster caso ocorra algum problema de segurança. Para usar políticas de rede, é preciso ativar o recurso explicitamente ao criar o cluster do GKE. É possível ativá-lo em um cluster atual, mas isso fará com que os nós do cluster sejam reiniciados. O comportamento padrão é que toda a comunicação entre pods esteja sempre aberta. Portanto, se precisar segmentar sua rede, será necessário aplicar políticas de rede no nível do pod. No GKE, é possível definir uma política de rede usando a API Network Policy do Kubernetes ou a ferramenta
kubectl. Essas regras de política de tráfego no nível do pod determinam quais pods e serviços podem acessar uns aos outros dentro do cluster.Namespaces: os namespaces (em inglês) permitem a segmentação de recursos dentro do seu cluster do Kubernetes. O Kubernetes é fornecido com um namespace padrão pronto para uso, mas é possível criar vários namespaces no cluster. Os namespaces são logicamente isolados uns dos outros. Eles proporcionam escopo para pods, serviços e implantações no cluster, para que os usuários que interagem com um namespace não vejam o conteúdo em outro namespace. No entanto, os namespaces dentro do mesmo cluster não restringem a comunicação entre eles e é por isso que as políticas de rede são necessárias. Para mais informações sobre a configuração de namespaces, consulte a postagem do blog Práticas recomendadas para namespaces (em inglês).
No diagrama a seguir ilustramos os conceitos anteriores em relação a eles mesmos e a outros componentes do GKE, como cluster, nó e pod.
Requisito 1.1
Os processos e mecanismos para instalar e manter os controles de segurança de rede são definidos e compreendidos.
Requisito 1.1.2
Descreva grupos, papéis e responsabilidades para gerenciar componentes de rede.
Primeiramente, assim como você faria com a maioria dos serviços no Google Cloud, é necessário configurar os papéis do IAM para configurar a autorização no GKE. Depois de configurar seus papéis de IAM, será necessário adicionar a configuração do controle de acesso baseado em papéis do Kubernetes (RBAC, na sigla em inglês) [link em inglês] como parte de uma estratégia de autorização do Kubernetes.
Basicamente, toda a configuração do IAM aplica-se a todos os recursos do Google Cloud e a todos os clusters de um projeto. A configuração RBAC do Kubernetes aplica-se aos recursos de cada cluster do Kubernetes e possibilita uma autorização mais refinada no nível do namespace. Com o GKE, essas abordagens de autorização funcionam em paralelo, com os recursos de um usuário representando efetivamente uma união de papéis de IAM e RBAC atribuídos a eles:
- Usar o IAM para controlar grupos, papéis e responsabilidades de gerenciamento lógico de componentes de rede no GKE.
- Usar o RBAC do Kubernetes para conceder permissões granulares às políticas de rede (em inglês) nos clusters do Kubernetes, controlar o tráfego entre pods e evitar alterações não autorizadas ou acidentais de usuários que não sejam do CDE.
- Ser capaz de justificar todos os usuários e permissões do IAM e do RBAC. Geralmente, quando os QSAs testam os controles, eles procuram uma justificativa comercial para uma amostra de IAM e RBAC.
Requisito 1.2
Os controles de segurança de rede (NSCs, na sigla em inglês) são configurados e mantidos.
Primeiro, configure as regras de firewall em instâncias do Compute Engine que executam seus nós do GKE. As regras de firewall protegem esses nós do cluster.
Em seguida, configure as políticas de rede para restringir fluxos e proteger pods em um cluster. Uma política de rede é uma especificação de como grupos de pods podem comunicar-se uns com os outros e com outros endpoints da rede. Use a aplicação da política de rede do GKE para controlar a comunicação entre os pods e os serviços do cluster. Para segmentar ainda mais seu cluster, crie vários namespaces nele. Os namespaces são logicamente isolados uns dos outros. Eles oferecem escopo para pods, serviços e implantações no cluster, de modo que os usuários que interagem com um namespace não verão o conteúdo em outro namespace. No entanto, os namespaces dentro do mesmo cluster não restringem a comunicação entre eles e é por isso que as políticas de rede são necessárias. Os namespaces permitem a segmentação de recursos dentro do seu cluster do Kubernetes. Para mais informações sobre a configuração de namespaces, consulte a postagem do blog Práticas recomendadas para namespaces (em inglês).
Por padrão, se não existirem políticas em um namespace, todo tráfego de entrada e saída será permitido entre os pods nesse namespace. Por exemplo, é possível criar uma política de isolamento padrão para um namespace criando uma política de rede que selecione todos os pods, mas não permita tráfego de entrada para esses pods.
Requisito 1.2.2
Todas as mudanças nas conexões de rede e nas configurações de NSCs são aprovadas e gerenciadas de acordo com o processo de controle de mudanças definido no requisito 6.5.1.
Para tratar suas configurações de rede e a infraestrutura como código, é necessário estabelecer um pipeline de integração contínua e entrega contínua (CI/CD, na sigla em inglês) como parte de seus processos de gestão da mudança e controle de mudança.
É possível usar modelos do Cloud Deployment Manager ou do Terraform (em inglês) como parte do pipeline de CI/CD para criar políticas de rede nos seus clusters. Com o Deployment Manager ou o Terraform, é possível tratar a configuração e a infraestrutura como um código capaz de reproduzir cópias consistentes da produção atual ou de outros ambientes. Em seguida, os testes de unidade, entre outros, serão gravados para garantir que suas alterações de rede funcionem conforme o esperado. Um processo de controle de mudança que inclui uma aprovação pode ser gerenciado por meio de arquivos de configuração armazenados em um repositório de versões.
Com o Terraform Config Validator (em inglês), é possível definir restrições para impor políticas de segurança e de governança. Ao adicionar o Config Validator ao pipeline de CI/CD, é possível incluir uma etapa em qualquer fluxo de trabalho. Esta etapa valida um plano do Terraform e o rejeita se surgirem violações.
Requisito 1.2.5
Todos os serviços, protocolos e portas permitidos são identificados, aprovados e têm uma necessidade comercial definida.
Em casos de controles de entrada fortes para os clusters do GKE, é possível usar redes autorizadas para restringir determinados intervalos de IP que podem chegar ao plano de controle do cluster. O GKE usa o Transport Layer Security (TLS) e a autenticação para fornecer acesso seguro ao endpoint do cluster mestre a partir da Internet pública. Esse acesso permite administrar seu cluster de qualquer lugar. Ao usar redes autorizadas, é possível restringir ainda mais o acesso a conjuntos específicos de endereços IP.
É possível usar o Google Cloud Armor para criar listas de negação de IP e listas de permissão e políticas de segurança para aplicativos hospedados no GKE. Em um cluster do GKE, o tráfego de entrada é processado pelo balanceamento de carga HTTP(S), que é um componente do Cloud Load Balancing. Normalmente, o balanceador de carga HTTP(S) é configurado pelo controlador Ingress do GKE (em inglês), que recebe informações de configuração de um objeto Ingress do Kubernetes. Para mais informações, veja como configurar as políticas do Google Cloud Armor com o GKE.
Requisito 1.3
O acesso à rede de e para o ambiente de dados do titular do cartão é restrito.
Para manter os dados confidenciais privados, é necessário configurar comunicações particulares entre clusters do GKE nas redes VPC e em implantações híbridas locais usando o VPC Service Controls e o Acesso privado do Google.
Requisito 1.3.1
O tráfego de entrada para o CDE é restrito da seguinte maneira:
- Para apenas o tráfego necessário.
- Todos os outros tipos de tráfego são especificamente negados.
Pense em implementar a configuração do Cloud NAT com o GKE para limitar o tráfego de entrada da Internet a somente esse cluster. É possível configurar um cluster particular para os clusters que não são públicos em seu CDE. Em um cluster particular, os nós têm apenas endereços IP RFC 1918 internos. Isso garante que as cargas de trabalho fiquem isoladas da Internet pública.
Requisito 1.4
As conexões entre redes confiáveis e não confiáveis são controladas.
Você pode resolver esse requisito usando os mesmos métodos listados no Requisito 1.3.
Requisito 1.4.3
As medidas antispoofing são implementadas para detectar e impedir que endereços IP de origem forjados entrem na rede confiável.
Para implementar medidas anti-spoofing, use endereços IP de alias em pods e clusters do GKE para detectar e impedir que endereços IP de origem forjados entrem na rede. O cluster que usa intervalos de IP de alias é chamado de cluster nativo de VPC.
Requisito 1.4.5
A divulgação de endereços IP internos e informações de roteamento é limitada somente a partes autorizadas.
É possível usar um agente de mascaramento de IP do GKE para fazer conversão de endereços de rede (NAT, na sigla em inglês) para conversões de endereços IP muitos para um em um cluster. Com ele, crie uma máscara de endereço único para vários endereços IP de origem.
Requisito 2
Aplique configurações seguras a todos os componentes do sistema.
O requisito 2 especifica como proteger os parâmetros de segurança removendo os padrões e as credenciais oferecidas pelo fornecedor. O aumento da proteção do cluster é uma responsabilidade do cliente.
Requisito 2.2
Os componentes do sistema são configurados e gerenciados com segurança.
Certifique-se de que esses padrões atendam a todas as vulnerabilidades de segurança conhecidas e sejam consistentes com os padrões de proteção de sistema aceitos pelo setor. Origens de padrões de aumento de proteção de sistemas aceitos pelo setor podem incluir, entre outros:- Centro de Segurança da Internet (CIS, na sigla em inglês) [em inglês]
- Organização Internacional de Normalização (ISO, na sigla em inglês) [em inglês]
- Instituto SysAdmin Audit Network Security (SANS, na sigla em inglês) [em inglês]
- Instituto Nacional de Padrões e Tecnologia (NIST, na sigla em inglês) [em inglês]
Requisito 2.2.4
Apenas os serviços, protocolos, daemons e funções necessários são ativados, e todas as funcionalidades desnecessárias são removidas ou desativadas.
Requisito 2.2.5
- A justificativa comercial está documentada.
- Recursos de segurança adicionais são documentados e implementados para reduzir o risco de usar serviços, protocolos ou daemons não seguros.
Requisito 2.2.6
Os parâmetros de segurança do sistema são configurados para evitar o uso indevido.
Pré-implantação
Antes de mover contêineres para o GKE, recomendamos o seguinte:
- Comece com uma imagem de base gerenciada do contêiner, de fonte confiável, que seja criada, mantida e que tenha verificação de vulnerabilidades. Considere a criação de um conjunto de imagens de base "conhecidas" ou "valiosas" que seus desenvolvedores possam usar. Uma opção mais restritiva é usar uma imagem distroless ou uma imagem de base de rascunho (links em inglês).
- Use o Artifact Analysis para verificar vulnerabilidades em imagens do contêiner.
- Estabeleça uma política DevOps/SecOps interna para incluir apenas bibliotecas e binários confiáveis e aprovados nos contêineres.
Durante a configuração
Na configuração, recomendamos o seguinte:
- Use o Container-Optimized OS padrão como a imagem de nó do GKE. Ele é baseado no Chromium OS e está otimizado para a segurança do nó.
- Ative os nós de upgrade automático para os clusters que executam seus aplicativos. Esse recurso atualiza automaticamente o nó para a versão do Kubernetes em execução no plano de controle gerenciado, proporcionando mais estabilidade e segurança.
- Ative os nós de reparo automático. Quando esse recurso é ativado, o GKE verifica periodicamente e usa o status de integridade do nó para determinar se algum nó precisa ser reparado. Se exigir reparo, esse nó será esvaziado e um novo nó será criado e adicionado ao cluster.
- Ative o Cloud Monitoring e o Cloud Logging para ter visibilidade de todos os eventos, incluindo ocorrências de segurança e o status de integridade do nó. Crie políticas de alertas do Cloud Monitoring para receber notificações em caso de incidentes de segurança.
- Aplique contas de serviços de privilégios mínimos para nós do GKE
- Analise e aplique, quando necessário, a seção do GKE no guia comparativo de mercado CIS do Google Cloud (em inglês). A geração de registros de auditoria do Kubernetes já está ativada por padrão, e os registros das solicitações para a
kubectle a API do GKE são gravados nos registros de auditoria do Cloud. - Configure o registro de auditoria.
Proteger os dados da conta
A proteção dos dados do titular do cartão abrange os requisitos 3 e 4 do PCI DSS.
Requisito 3
Proteger os dados armazenados da conta.
O requisito 3 do PCI DSS determina que as técnicas de proteção, como criptografia, truncamento, mascaramento e hash, são componentes críticos da proteção de dados do titular do cartão. Se um invasor enganar outros controles de segurança e conseguir acesso a dados criptografados, sem as chaves criptográficas adequadas, os dados estarão ilegíveis e não poderão ser usados por essa pessoa.
Pense também em outros métodos de proteção de dados armazenados como possíveis oportunidades de redução de riscos. Por exemplo, métodos para minimizar riscos incluem: não armazenar dados do titular, a menos que seja absolutamente necessário, truncar dados do titular se não precisar do PAN completo e não enviar PANs desprotegidos usando tecnologias de mensagens do usuário final, como e-mail e mensagens instantâneas.
Exemplos de sistemas em que o CHD pode persistir como parte de seus fluxos de processamento de pagamentos ao ser executado no Google Cloud:
- Buckets do Cloud Storage
- Instâncias do BigQuery
- Datastore
- Cloud SQL
Esteja ciente de que o CHD pode ser armazenado inadvertidamente em registros de e-mail ou de comunicação de atendimento ao cliente. É prudente usar a Proteção de dados confidenciais para filtrar esses fluxos de dados para limitar o ambiente em escopo aos sistemas de processamento de pagamentos.
No Google Cloud, observe que os dados são criptografados em repouso por padrão e criptografados em trânsito por padrão quando passam por limites físicos. Nenhuma configuração extra é necessária para ativar essas proteções.
Requisito 3.5
O número da conta principal (PAN) fica protegido onde quer que esteja.
Um mecanismo para tornar os dados do PAN ilegíveis é a tokenização. Para mais informações, consulte o guia da solução sobre a tokenização dos dados confidenciais do titular do cartão para PCI DSS.
É possível usar a API DLP para verificar, descobrir e informar os dados do titular do cartão. A Proteção de dados confidenciais tem suporte nativo para verificar e classificar dados PAN de 12 a 19 dígitos no Cloud Storage, no BigQuery e no Datastore. Ele também tem uma API de conteúdo de streaming para permitir a compatibilidade com outras fontes de dados, cargas de trabalho personalizadas e aplicativos. Também é possível usar a API DLP para truncar (editar) ou gerar hash [em inglês] dos dados.
Requisito 3.6
As chaves criptográficas usadas para proteger os dados da conta armazenados são protegidas.
O Cloud Key Management Service (KMS) é um sistema de armazenamento gerenciado para chaves criptográficas. Ele pode gerar, usar, rotacionar e destruir chaves criptográficas. Embora o Cloud KMS não armazene chaves secretas diretamente, como os dados do titular do cartão, ele pode ser usado para criptografar esses dados.
Os secrets no contexto do Kubernetes são objetos secret do Kubernetes que permitem armazenar e gerenciar informações confidenciais, como senhas, tokens e chaves.
Por padrão, o Google Cloud criptografa o conteúdo do cliente armazenado em repouso. O GKE executa e gerencia essa criptografia sem nenhuma outra ação da sua parte. A criptografia de secrets da camada de aplicativos fornece uma camada extra de segurança para dados confidenciais, como secrets. Essa funcionalidade permite o uso de uma chave gerenciada no Cloud KMS para criptografar dados na camada do aplicativo. Isso protege contra invasores que tentam conseguir acesso a uma cópia da instância de armazenamento de configuração do Kubernetes no cluster.
Requisito 4
Proteja os dados do titular do cartão com criptografia forte durante a transmissão em redes públicas abertas.
Os dados em escopo precisam ser criptografados durante a transmissão em redes que são facilmente acessadas por indivíduos mal-intencionados, por exemplo, em redes públicas.
O Istio (em inglês) é uma malha de serviço de código aberto que se espalha em camadas de forma transparente em aplicativos distribuídos existentes. Ele gerencia de maneira escalonável a autenticação, autorização e criptografia do tráfego entre microsserviços. É uma plataforma que inclui APIs que permitem a integração em qualquer plataforma de registro, telemetria ou sistema de políticas. O conjunto de recursos do Istio permite executar com eficiência uma arquitetura de microsserviços distribuída e fornece uma maneira uniforme de proteger, conectar e monitorar esses microsserviços.
Requisito 4.1
Os processos e mecanismos para proteger os dados do titular do cartão com criptografia forte durante a transmissão por redes públicas abertas são definidos e documentados.
É possível usar o Istio para criar uma rede de serviços implantados, com balanceamento de carga, autenticação de serviço a serviço e monitoramento. Ele também pode ser usado para fornecer comunicação de serviço a serviço segura em um cluster, com autenticação baseada em identidade e autorização baseadas em TLS mútuo. O TLS mútuo (mTLS, na sigla em inglês) é um handshake de TLS realizado duas vezes, estabelecendo o mesmo nível de confiança em ambas as direções (ao contrário da confiança unidirecional cliente-servidor).
O Istio permite implantar certificados TLS em cada um dos pods do GKE em um aplicativo. Os serviços executados no pod podem usar mTLS para identificar fortemente suas identidades de peer. A comunicação de serviço a serviço é enviada em túnel por meio de proxies Envoy (em inglês) do cliente e do servidor. O Envoy usa IDs SPIFFE (em inglês) para estabelecer conexões mTLS entre serviços. Para mais informações sobre como implantar o Istio no GKE, consulte a documentação do GKE. Para mais informações sobre as versões de TLS compatíveis, consulte a documentação de referência de gerenciamento de tráfego do Istio (em inglês). Use o TLS versão 1.2 e posterior.
Se seu aplicativo for exposto à Internet, use o Balanceamento de carga HTTP(S) do GKE com roteamento de entrada definido para usar HTTP(S). O balanceamento de carga HTTP(S), configurado por um objeto de entrada, inclui o seguinte:
- Configuração flexível para serviços: um objeto Ingress define como o tráfego chega aos seus serviços e como ele é roteado para seu aplicativo. Além disso, um Ingress pode fornecer um único endereço IP para vários serviços no cluster.
- Integração com os serviços de rede do Google Cloud: um objeto Ingress pode configurar recursos do Google Cloud como certificados SSL gerenciados pelo Google (beta), Google Cloud Armor, Cloud CDN e Identity-Aware Proxy.
- Suporte para vários certificados TLS: um objeto Ingress pode especificar o uso de vários certificados TLS para o encerramento da solicitação.
Ao criar um objeto Ingress, o controlador Ingress do GKE (em inglês) gera um balanceador de carga HTTP(S) do Cloud e o configura de acordo com as informações no Ingress e nos respectivos serviços associados.
Manter um programa de gerenciamento de vulnerabilidades
A manutenção de um programa de gerenciamento de vulnerabilidades abrange os requisitos 5 e 6 do PCI DSS.
Requisito 5
Proteger todos os sistemas e redes contra softwares maliciosos.
O requisito 5 do PCI DSS determina que o software antivírus precisa ser usado em todos os sistemas afetados por malware para protegê-los contra ameaças de software atuais e em desenvolvimento, e os contêineres não são exceção.
Requisito 5.2
Softwares maliciosos (malware) são evitados, detectados e resolvidos.
É necessário implementar programas de gerenciamento de vulnerabilidades para suas imagens de contêiner.
Recomendamos o seguinte:
- Verificar e aplicar regularmente patches de segurança atualizados nos contêineres.
- Fazer verificações de vulnerabilidade frequentes em aplicativos em contêineres e em binários/bibliotecas.
- Verificar imagens como parte do pipeline da versão.
- Inscrever-se em um serviço de inteligência de vulnerabilidade para receber informações atualizadas sobre vulnerabilidades relevantes para o ambiente e as bibliotecas usadas nos contêineres.
O Google Cloud trabalha com vários provedores de soluções de segurança de contêineres para melhorar a postura de segurança nas implantações do GCP dos clientes. Recomendamos o uso de tecnologias e soluções de segurança validadas para aumentar a profundidade da defesa no seu ambiente do GKE. Para ver a lista mais recente de parceiros de segurança validados pelo Google Cloud, consulte Parceiros de segurança.
Requisito 5.2.2
As soluções antimalware implantadas:
- Detecta todos os tipos conhecidos de malware.
- Remove, bloqueia ou contém todos os tipos conhecidos de malware.
Requisito 5.2.3
Todos os componentes do sistema que não apresentam risco de malware são avaliados periodicamente para incluir os seguintes elementos:
- Uma lista documentada de todos os componentes do sistema sem risco de malware.
- Identificação e avaliação de novas ameaças de malware para esses componentes do sistema.
- Confirmação se esses componentes do sistema continuam a não exigir a proteção contra malware.
Existem muitas soluções disponíveis para a realização de verificações de malware, mas o PCI DSS reconhece que nem todos os sistemas têm a mesma vulnerabilidade. É comum os comerciantes declararem que seus servidores Linux, mainframes e máquinas semelhantes não são “comumente afetados por softwares maliciosos” e, portanto, estão fora do requisito 5.2.2. Nesse caso, aplica-se o 5.2.3, e por isso torna-se necessário implementar um sistema para avaliações periódicas contra ameaças.
Lembre-se de que essas regras aplicam-se a nós e pods dentro de um cluster do GKE.
Requisito 5.3
Os mecanismos e processos antimalware estão ativos, mantidos e monitorados.
Os requisitos 5.2, 5.3 e 11.5 exigem a realização de verificações de antivírus e o monitoramento de integridade de arquivos (FIM, na sigla em inglês) em qualquer host em escopo. Recomendamos implementar uma solução em que todos os nós possam ser verificados por um agente confiável no cluster ou em que cada nó tenha um scanner que relate até um único endpoint de gerenciamento.
Para mais informações, consulte a visão geral de segurança do GKE e a visão geral de segurança do Container-Optimized OS.
Uma solução comum para os requisitos do antivírus e do FIM é bloquear seu contêiner para que somente pastas específicas permitidas tenham acesso de gravação. Para isso, execute seus contêineres como um usuário não raiz e use permissões do sistema de arquivos para impedir o acesso de gravação a todos os diretórios, exceto aqueles de trabalho contidos no sistema de arquivos de contêiner. Não permita o escalonamento de privilégios para evitar violação das regras do sistema de arquivos.
Requisito 6
Desenvolva e mantenha sistemas e aplicativos seguros.
O requisito 6 do PCI DSS exige que você estabeleça um ciclo de vida forte de desenvolvimento de software, em que a segurança seja incorporada em todas as etapas de desenvolvimento de software.
Requisito 6.2
Softwares sob medida e personalizados são desenvolvidos com segurança.
Requisito 6.2.1
Os softwares sob medida e personalizados são desenvolvidos com segurança da seguinte maneira:
- Baseado em padrões do setor e/ou práticas recomendadas para desenvolvimento seguro.
- De acordo com o PCI DSS (por exemplo, autenticação e geração de registros seguras).
- Incorporar a consideração de problemas de segurança das informações durante cada etapa do ciclo de vida de desenvolvimento do software.
É possível usar a autorização binária para ajudar a garantir que somente contêineres confiáveis sejam implantados no GKE. Se quiser ativar somente imagens autorizadas por um ou mais atestadores específicos, configure a autorização binária para aplicar uma política a regras que exigem atestadores com base nos resultados da verificação de vulnerabilidades. Também é possível criar políticas que exigem que uma ou mais partes confiáveis (chamadas “atestadores”) para aprovar uma imagem antes de implantá-la. Para um pipeline de implantação de vários estágios em que as imagens avançam do desenvolvimento para testes e clusters de produção, é possível usar os atestadores para garantir que todos os processos necessários sejam concluídos antes de o software passar para o próximo estágio.
Durante a implantação, a autorização binária impõe sua política, verificando se a imagem do contêiner superou todas as restrições necessárias, incluindo que todos os atestadores obrigatórios verificaram se a imagem está pronta para implantação. Se a imagem for aprovada, o serviço permitirá que ela seja implantada. Caso contrário, a implantação será bloqueada e a imagem não poderá ser implantada até que esteja em conformidade.
Para mais informações sobre a autorização binária, consulte Configurar para o GKE.
Em uma situação de emergência, é possível ignorar uma política de autorização binária usando o fluxo de trabalho de acesso de emergência (em inglês). Todos os incidentes de acesso de emergência ficam registrados nos registros de auditoria do Cloud.
O GKE Sandbox reduz a necessidade de o contêiner interagir com o host, diminuindo a probabilidade de ataques que causam o comprometimento do host e restringindo a movimentação de agentes mal-intencionados.
Requisito 6.3
Vulnerabilidades de segurança são identificadas e corrigidas.
Requisito 6.3.1
As vulnerabilidades de segurança são identificadas e gerenciadas da seguinte maneira:
- Novas vulnerabilidades de segurança são identificadas usando fontes reconhecidas pelo setor para informações sobre vulnerabilidades de segurança, incluindo alertas de equipes de emergência de computadores (CERTs, na sigla em inglês) internacionais e nacionais.
- As vulnerabilidades recebem uma classificação de risco com base nas práticas recomendadas do setor e na consideração do possível impacto.
- As classificações de risco identificam, no mínimo, todas as vulnerabilidades consideradas de alto risco ou críticas para o ambiente.
- Vulnerabilidades para softwares sob medida, personalizados e de terceiros (por exemplo, sistemas operacionais e bancos de dados) são cobertas.
A segurança na nuvem é uma responsabilidade compartilhada entre o provedor de nuvem e o cliente.
No GKE, o Google gerencia o plano de controle, que inclui as VMs mestres, o servidor de API e outros componentes executados nessas VMs, bem como o banco de dados etcd. Isso inclui atualizações e patches, dimensionamento e reparos, todos apoiados por um objetivo de nível de serviço (SLO, na sigla em inglês). Para o sistema operacional dos nós, como Container-Optimized OS ou Ubuntu, o GKE disponibiliza imediatamente todos os patches para essas imagens. Se o upgrade automático estiver ativado, esses patches serão implantados automaticamente. Essa é a camada de base de seu contêiner, não é o mesmo sistema operacional em execução nos seus contêineres.
Para mais informações sobre o modelo de responsabilidade compartilhada do GKE, consulte Como explorar a segurança do contêiner: o modelo de responsabilidade compartilhada no GKE.
O Google oferece vários serviços de segurança para ajudar a aumentar a segurança no pipeline de CI/CD. Para identificar vulnerabilidades nas suas imagens de contêiner, use a Verificação de vulnerabilidades no Google Artifact Analysis. Quando uma imagem de contêiner é enviada ao Google Container Registry (GCR), a verificação de vulnerabilidade analisa automaticamente as imagens em busca de vulnerabilidades e exposições conhecidas de origens CVEs conhecidas (em inglês). As vulnerabilidades recebem níveis de gravidade (crítico, alto, médio, baixo e mínimo) com base nas pontuações do CVSS (em inglês).
Requisito 6.4
Os aplicativos da Web voltados ao público são protegidos contra ataques.
O Web Security Scanner permite fazer a varredura de aplicativos públicos da Web, como App Engine, Compute Engine e GKE, por vulnerabilidades comuns que variam de scripts entre sites e configurações incorretas a recursos vulneráveis. As verificações podem ser feitas sob demanda e programadas no Console do Google Cloud. Ao usar as APIs do Security Scanner, é possível automatizar a verificação como parte do conjunto de testes de segurança no pipeline de criação do seu aplicativo.
Implementar medidas de controle de acesso eficientes
A implementação de medidas de controle de acesso eficientes abrange os requisitos 7, 8 e 9 do PCI DSS.
Requisito 7
Restrinja o acesso aos componentes do sistema e dados do titular do cartão por necessidade comerciais.
O requisito 7 é voltado para o menor privilégio ou a necessidade de saber. O PCI DSS define como conceder acesso à menor quantidade de dados e fornecer o menor número de privilégios necessários para executar um job.
Requisito 7.2
O acesso aos componentes e dados do sistema é definido e atribuído adequadamente.
O IAM e o Controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes trabalham em conjunto para fornecer controle de acesso minucioso ao seu ambiente do GKE. O IAM é usado para gerenciar o acesso de usuários e as permissões dos recursos do Google Cloud no projeto do CDE. No GKE, também é possível usar o IAM para gerenciar o acesso e as ações que os usuários e as contas de serviço podem executar nos seus clusters, como criar e excluir clusters.
O RBAC do Kubernetes permite configurar conjuntos detalhados de permissões que definem como um determinado usuário do Google Cloud, contas de serviço do Google Cloud ou grupo de usuários (Grupos do Google) podem interagir com qualquer objeto do Kubernetes no seu cluster ou em um namespace específico de seu cluster. Exemplos de permissões do RBAC incluem edição de implantações ou configmaps, exclusão de pods ou visualização de registros de um pod. Conceda permissões de IAM limitadas aos usuários ou serviços, como o leitor de cluster do Google Kubernetes Engine ou papéis personalizados e aplique o Kubernetes RBAC RoleBindings conforme apropriado.
O Cloud Identity Aware Proxy (IAP) pode ser integrado por meio da entrada do GKE para controlar o acesso de aplicativos para funcionários ou pessoas que precisam de acesso aos aplicativos do PCI.
Além disso, é possível usar as políticas da organização para restringir as APIs e os serviços que estão disponíveis em um projeto.
Requisito 7.2.2
O acesso é atribuído a usuários, incluindo usuários privilegiados, com base no seguinte:
- Classificação e função do cargo.
- Privilégios mínimos necessários para executar as responsabilidades do trabalho.
Além de garantir que os usuários e as contas de serviço obedeçam ao princípio do menor privilégio, os contêineres precisam obedecer também. Uma prática recomendada ao executar um contêiner é executar o processo com um usuário não raiz. É possível realizar e aplicar essa prática usando o controlador de admissão do PodSecurity.
PodSecurity é um controlador de admissão do Kubernetes que permite aplicar os padrões de segurança de pods aos pods em execução nos clusters do GKE. Os padrões de segurança de pods são políticas de segurança predefinidas que abrangem as necessidades de alto nível de segurança do pod no Kubernetes. Essas políticas variam de altamente permissivas a altamente restritivas. O PodSecurity substitui o antigo controlador de admissão PodSecurityPolicy que foi removido no Kubernetes v1.25. Há instruções disponíveis para migrar do PodSecurityPolicy para o controlador de admissão do PodSecurity.
Requisito 8
Identificar usuários e autenticar o acesso aos componentes do sistema
O requisito 8 especifica que um ID exclusivo precisa ser atribuído a cada pessoa que tem acesso aos sistemas do PCI em escopo para garantir que cada pessoa seja a única responsável por suas ações.
Requisito 8.2
A identificação de usuários e as contas relacionadas para usuários e administradores são estritamente gerenciadas ao longo do ciclo de vida de uma conta.
Requisito 8.2.1
Todos os usuários recebem um ID exclusivo antes de permitir o acesso aos componentes do sistema ou aos dados do titular do cartão.
Requisito 8.2.5
O acesso para usuários encerrados é imediatamente revogado.
O IAM e o RBAC do Kubernetes podem ser usados para controlar o acesso ao seu cluster do GKE e, em ambos os casos, conceder permissões a um usuário. Recomendamos que os usuários vinculem-se ao sistema de identidade existente (em inglês) para que seja possível gerenciar contas e políticas de usuários em um único local.
Requisito 8.3
Uma autenticação forte para usuários e administradores é estabelecida e gerenciada.
Requisito 8.3.1
- Algo que você conhece, como uma senha ou uma senha longa.
- Algo que você tem, como um dispositivo de token ou cartão inteligente.
- Algo que você tem em si, como um elemento de biometria.
Os certificados são vinculados à identidade do usuário quando eles se autenticam na kubectl.
Todos os clusters do GKE são configurados para aceitar identidades de usuário e de conta de serviço do Google Cloud. Para isso, eles validam as credenciais e recuperam o endereço de e-mail associado à identidade de conta de serviço ou usuário. Como resultado, as credenciais dessas contas precisam incluir o escopo userinfo.email do OAuth para realizar a autenticação com êxito.
Requisito 9
Restrinja o acesso físico aos dados do titular do cartão.
O Google é responsável pelos controles de segurança física em todos os data centers do Google subjacentes ao Google Cloud.
Monitorar e testar regularmente as redes
O monitoramento e o teste de redes regularmente abrangem os requisitos 10 e 11 do PCI DSS.
Requisito 10
Registre e monitore todo o acesso a componentes do sistema e dados do titular do cartão.
Requisito 10.2
Os registros de auditoria são implementados para ajudar na detecção de anomalias e atividades suspeitas, além da análise forense de eventos.
Os clusters do Kubernetes têm a geração de registros de auditoria do Kubernetes (em inglês) ativada por padrão, o que mantém um registro cronológico das chamadas feitas ao servidor da API Kubernetes. As entradas de registro de auditoria do Kubernetes são úteis para investigar solicitações de API suspeitas, coletar estatísticas ou criar alertas de monitoramento para chamadas de API indesejadas.
Os clusters do GKE integram uma configuração padrão para geração de registros de auditoria do GKE com registros de auditoria do Cloud e do Logging. É possível ver as entradas de registro de auditoria do Kubernetes no seu projeto do Google Cloud.
Além das entradas gravadas pelo Kubernetes, os registros de auditoria do seu projeto têm entradas gravadas pelo GKE.
Para diferenciar suas cargas de trabalho CDE das que não são CDE, recomendamos que você adicione rótulos aos seus pods do GKE que se infiltrarão em métricas e registros emitidos por essas cargas de trabalho.
Requisito 10.2.2
- Identificação do usuário
- Tipo de evento
- Data e hora
- Indicação de sucesso ou falha
- Origem do evento
- Identidade ou nome dos dados, componentes do sistema, recurso ou serviço afetados (por exemplo, nome e protocolo)
Toda entrada de registro de auditoria no Logging é um objeto do tipo LogEntry que contém os seguintes campos:
- Um payload, que é o tipo
protoPayload. O payload de cada entrada de registro de auditoria é um objeto do tipoAuditLog. É possível encontrar a identidade do usuário no campoAuthenticationInfodos objetosAuditLog. - O evento específico, que pode ser encontrado no campo
methodNamedeAuditLog. - Um carimbo de data/hora.
- O status do evento, que pode ser encontrado nos objetos
responsedo objetoAuditLog. - A solicitação de operação, que pode ser encontrada nos objetos
requesterequestMetadatado objetoAuditLog. - O serviço que será executado, que pode ser encontrado no objeto
AuditDatadoserviceData.
Requisito 11
Testar a segurança dos sistemas e das redes regularmente.
Requisito 11.3
Vulnerabilidades externas e internas são identificadas, priorizadas e tratadas regularmente.
Requisito 11.3.1
- Pelo menos uma vez a cada três meses.
- Vulnerabilidades críticas e de alto risco (de acordo com as classificações de risco de vulnerabilidade da entidade definidas no requisito 6.3.1) são resolvidas.
- São realizadas novas verificações para confirmar que todas as vulnerabilidades críticas e de alto risco (conforme indicado acima) foram resolvidas.
- A ferramenta de verificação é atualizada com as informações mais recentes sobre vulnerabilidade.
- As verificações são realizadas por pessoal qualificado, e há independência organizacional do testador.
A verificação de vulnerabilidade do Artifact Analysis executa os seguintes tipos de verificação de vulnerabilidades para as imagens no Container Registry:
Verificação inicial: quando você ativa pela primeira vez a API Artifact Analysis, ela verifica as imagens no Container Registry e extrai o gerenciador de pacotes, a base da imagem e as ocorrências de vulnerabilidade das imagens.
Verificação incremental: o Artifact Analysis verifica as novas imagens quando elas são enviadas para o Container Registry.
Análise contínua: conforme o Artifact Analysis recebe informações novas e atualizadas sobre vulnerabilidade de origens de vulnerabilidade, ele executa novamente a análise de contêineres para manter a lista de ocorrências de vulnerabilidades de imagens atualizada.
Requisito 11.5
Intrusões de rede e alterações inesperadas nos arquivos são detectadas e respondidas.
Requisito 11.5.1
- Todo o tráfego é monitorado no perímetro do CDE.
- Todo o tráfego é monitorado em pontos críticos do CDE.
- A equipe é alertada sobre suspeitas de comprometimento.
- Todos os mecanismos de detecção e prevenção de intrusões, valores de referência e assinaturas estão atualizados.
É possível usar o Espelhamento de pacotes do Google Cloud com o Cloud IDS para detectar intrusões de rede. O espelhamento de pacotes do Google Cloud encaminha todo o tráfego de rede das VMs do Compute Engine ou dos clusters do Google Cloud para um endereço designado. O Cloud IDS pode consumir esse tráfego espelhado para detectar uma ampla variedade de ameaças, incluindo tentativas de exploração, verificações de porta, estouros de buffer, fragmentação de protocolo, tráfego de comando e controle (C2) e malware.
O Security Command Center oferece visibilidade centralizada do estado de segurança dos serviços do Google Cloud (incluindo o GKE) e recursos em toda a organização, o que facilita a prevenção, detecção e resposta a ameaças. Use o Security Command Center para saber quando ameaças de alto risco, como malware, criptomineração, acesso não autorizado a recursos do Google Cloud, ataques DDoS de saída, verificação de portas e SSH de força bruta foram detectadas com base nos registros do Cloud Logging.
Manter uma política de segurança das informações
Uma política forte define o tom da segurança e informa às pessoas o que se espera delas. Nesse caso, "pessoas" referem-se a funcionários em tempo integral e de meio período, funcionários temporários, prestadores de serviços e consultores que têm acesso ao seu CDE.
Requisito 12
Dê suporte à segurança das informações com programas e políticas da organização.
Para mais informações sobre o requisito 12, consulte a Matriz de responsabilidade compartilhada do PCI do Google Cloud (em inglês).
Como fazer a limpeza
Se você usou algum recurso ao seguir este artigo, por exemplo, iniciou novas VMs ou usou os scripts Terraform, evite cobranças na sua conta do Google Cloud excluindo o projeto que usou esses 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.
A seguir
- Saiba mais sobre a conformidade com o padrão de segurança de dados do PCI.
- Teste o Kit básico do Terraform.
- Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.