Este guia destina-se a ajudar a resolver preocupações exclusivas das aplicações do Google Kubernetes Engine (GKE) quando implementa responsabilidades do cliente para os requisitos da Norma de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS).
Exclusão de responsabilidade: este guia destina-se apenas a fins informativos. A Google não pretende que as informações nem as recomendações neste guia constituam aconselhamento jurídico ou de auditoria. Cada cliente é responsável por avaliar independentemente a sua própria utilização específica dos serviços, conforme adequado, para apoiar as suas obrigações legais e de conformidade.
Introdução à conformidade com a PCI DSS e o GKE
Se processar dados de cartões de pagamento, tem de os proteger, quer residam numa base de dados nas instalações ou na nuvem. A PCI DSS foi desenvolvida para incentivar e melhorar a segurança dos dados dos titulares de cartões, bem como facilitar a ampla adoção de medidas de segurança de dados consistentes a nível global. A PCI DSS fornece uma base de requisitos técnicos e operacionais concebidos para proteger os dados de cartões de crédito. A PCI DSS aplica-se a todas as entidades envolvidas no processamento de cartões de pagamento, incluindo comerciantes, processadores, adquirentes, emissores e fornecedores de serviços. A PCI DSS também se aplica a todas as outras entidades que armazenam, processam ou transmitem dados do titular do cartão (CHD) ou dados de autenticação sensíveis (SAD), ou ambos.
As aplicações em contentores tornaram-se populares recentemente, com muitas cargas de trabalho antigas a migrarem de uma arquitetura baseada em máquinas virtuais (VMs) para uma arquitetura em contentores. O Google Kubernetes Engine é um ambiente gerido e pronto para produção para implementar aplicações em contentores. Oferece as mais recentes inovações da Google em termos de produtividade dos programadores, eficiência dos recursos, operações automatizadas e flexibilidade de código aberto para acelerar o tempo de colocação no mercado.
A conformidade é uma responsabilidade partilhada na nuvem. Google Cloud, incluindo o GKE (modos de funcionamento Autopilot e Standard), cumpre os requisitos da PCI DSS. Descrevemos as nossas responsabilidades na nossa matriz de responsabilidade partilhada.
Público-alvo
- Clientes que querem transferir cargas de trabalho em conformidade com a PCI para o Google Cloud que envolvem o GKE.
- Programadores, responsáveis de segurança, responsáveis de conformidade, administradores de TI e outros funcionários responsáveis pela implementação de controlos e pela garantia da conformidade com os requisitos da PCI DSS.
Antes de começar
Para as recomendações que se seguem, tem potencialmente de usar o seguinte:
- Google Cloud Recursos de organização, pasta e projeto
- Gestão de identidade e de acesso (IAM)
- Google Kubernetes Engine
- Google Cloud VPCs
- Google Cloud Armor
- A 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 que conhecem os contentores e o GKE.
Âmbito
Este guia identifica os seguintes requisitos da PCI DSS que são preocupações únicas para o GKE e fornece orientações para os cumprir. Foi escrita em conformidade com a versão 4.0 da norma. Este guia não abrange todos os requisitos da norma PCI DSS. As informações fornecidas neste guia podem ajudar as organizações na sua procura de conformidade com a norma PCI DSS, mas não constituem aconselhamento abrangente. As organizações podem contratar um avaliador de segurança qualificado (QSA) da PCI para validação formal.
Terminologia
Esta secção define os termos usados neste guia. Para mais detalhes, consulte o glossário da PCI DSS.
- CHD
dados do titular do cartão. No mínimo, consiste no número de conta principal completo (PAN). Os dados do titular do cartão também podem aparecer sob a forma do PAN completo, além de qualquer um dos seguintes elementos:
- Nome do titular do cartão
- Data de validade ou código de serviço
- Dados de autenticação confidenciais (SAD)
- 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 dados de autenticação confidenciais.
- PAN
número de conta principal. Um elemento fundamental dos dados do titular do cartão que é obrigatório proteger ao abrigo da PCI DSS. O PAN é geralmente um número de 16 dígitos exclusivo de um cartão de pagamento (crédito e débito) e que identifica o emissor e a conta do titular do cartão.
- PIN
número de identificação pessoal. Uma palavra-passe numérica conhecida apenas pelo utilizador e por um sistema; usada para autenticar o utilizador no sistema.
- QSA
avaliador de segurança qualificado. Uma pessoa certificada pelo PCI Security Standards Council para realizar auditorias e análises de conformidade.
- SAD
dados de autenticação confidenciais. Na conformidade com a PCI, os dados usados pelos emissores de cartões para autorizar transações. Tal como os dados do titular do cartão, a PCI DSS requer a proteção de SAD. Além disso, os dados de morada de faturação não podem ser retidos pelos comerciantes nem pelos respetivos processadores de pagamentos. A SAD inclui o seguinte:
- "Monitorize" dados de faixas magnéticas
- "Acompanhar dados equivalentes" gerados por cartões com chip e sem contacto
- Códigos de validação de segurança (por exemplo, o número de 3 a 4 dígitos impresso nos cartões) usados para transações online e transações sem cartão presente.
- PINs e bloqueios de PIN
- segmentação
No contexto da norma PCI DSS, a prática de isolar o AAD do resto da rede da entidade. A segmentação não é um requisito da norma PCI DSS. No entanto, é fortemente recomendado como um método que pode ajudar a reduzir o seguinte:
- O âmbito e o custo da avaliação da PCI DSS
- O custo e a dificuldade de implementar e manter os controlos da PCI DSS
- O risco para uma organização (reduzido através da consolidação dos dados do titular do cartão em menos localizações e mais controladas)
Segmente o seu ambiente de dados de titulares de cartões
O ambiente de dados do titular do cartão (CDE) compreende pessoas, processos e tecnologias que armazenam, processam ou transmitem dados do titular do cartão ou dados de autenticação confidenciais. No contexto do GKE, o CDE também compreende 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 virtuais privadas [VPCs] e sub-redes).
- Pods e clusters de aplicações que armazenam, processam ou transmitem dados de titulares de cartões. Sem uma segmentação adequada, toda a sua presença na nuvem pode ficar no âmbito da PCI DSS.
Para ser considerado fora do âmbito da norma PCI DSS, um componente do sistema tem de estar devidamente isolado do CDE, de modo que, mesmo que o componente do sistema fora do âmbito fosse comprometido, não afetaria a segurança do CDE.
Um pré-requisito importante para reduzir o âmbito do AAE é uma compreensão clara das necessidades e dos processos empresariais relacionados com o armazenamento, o processamento e a transmissão de dados do titular do cartão. Restringir os dados do titular do cartão ao menor número possível de localizações, eliminando dados desnecessários e consolidando os dados necessários, pode exigir que reconfigure práticas empresariais antigas.
Pode segmentar corretamente os seus dados de conversão estimados através de vários meios no Google Cloud. Esta secção aborda os seguintes meios:
- Segmentação lógica através da hierarquia de recursos
- Segmentação de rede através de VPCs e sub-redes
- Segmentação ao nível do serviço através da VPC
- Outras considerações para qualquer cluster dentro do âmbito
Segmentação lógica através da hierarquia de recursos
Existem várias formas de isolar o seu CDE na estrutura organizacional usando a hierarquia de recursos do Google Cloud. Os recursos do Google Cloud estão organizados hierarquicamente. Google CloudGoogle Cloud O recurso Organization é o nó de raiz na Google Cloud hierarquia de recursos. As pastas e os projetos pertencem ao recurso de organização. As pastas podem conter projetos e pastas. As pastas são usadas para controlar o acesso aos recursos na hierarquia de pastas através de autorizações de IAM ao nível da pasta. 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 da IAM.
Pode agrupar todos os projetos que estão no âmbito da PCI numa pasta para isolá-los ao nível da pasta. Também pode usar um projeto para todos os clusters e aplicações de âmbito da PCI, ou pode criar um projeto e um cluster para cada aplicação de âmbito da PCI e usá-los para organizar os seusGoogle Cloud recursos. Em qualquer caso, recomendamos que mantenha as cargas de trabalho no âmbito e fora do âmbito em projetos diferentes.
Segmentação de rede através de redes VPC e sub-redes
Pode usar a nuvem virtual privada (VPC) e as sub-redes para aprovisionar a sua rede e agrupar e isolar recursos relacionados com o CDE. A VPC é um isolamento lógico de uma secção de uma nuvem pública. As redes VPC oferecem uma rede escalável e flexível para as suas instâncias de máquinas virtuais (VMs) do Compute Engine e para os serviços que usam instâncias de VMs, incluindo o GKE. Para mais detalhes, consulte a vista geral da VPC e consulte as práticas recomendadas e as arquiteturas de referência.
Segmentação ao nível do serviço com os VPC Service Controls e o Cloud Armor
Embora a VPC e as sub-redes forneçam segmentação e criem um perímetro para isolar o seu AAD, o VPC Service Controls aumenta o perímetro de segurança na camada 7. Pode usar os VPC Service Controls para criar um perímetro em torno dos seus projetos de CDE no âmbito. Os VPC Service Controls oferecem-lhe os seguintes controlos:
- Controlo de entrada. Apenas são permitidas identidades e clientes autorizados no seu perímetro de segurança.
- Controlo de saída. Apenas são permitidos destinos autorizados para identidades e clientes dentro do seu perímetro de segurança.
Pode usar o Cloud Armor para criar listas de endereços IP para permitir ou negar o acesso ao seu balanceador de carga de HTTP(S) no limite da Google Cloud rede. Ao examinar os endereços IP o mais próximo possível do utilizador e do tráfego malicioso, ajuda a impedir que o tráfego malicioso consuma recursos ou entre nas suas redes VPC.
Use os VPC Service Controls para definir um perímetro de serviço em torno dos seus projetos no âmbito. Este perímetro rege os caminhos da VM para o serviço e do serviço para o serviço, bem como o tráfego de entrada e saída da VPC.
Crie e mantenha uma rede e sistemas seguros
A criação e a manutenção de uma rede segura abrangem os requisitos 1 e 2 da 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 que entra e sai do APE.
Os conceitos de rede para contentores e GKE diferem dos das VMs tradicionais. Os pods podem comunicar entre si diretamente, sem NAT, mesmo entre nós. Isto cria uma topologia de rede simples que pode ser surpreendente se estiver habituado a gerir sistemas mais complexos. O primeiro passo na segurança de rede para o GKE é informar-se sobre estes conceitos de rede.
Antes de analisar os requisitos individuais no Requisito 1, recomendamos que reveja 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 aos seus nós. Os nós do GKE são aprovisionados como instâncias do Compute Engine e usam os mesmos mecanismos de firewall que outras instâncias. Na sua rede, pode usar etiquetas para aplicar estas regras de firewall a cada instância. Cada conjunto de nós recebe o seu próprio conjunto de etiquetas que pode usar nas regras. Por predefinição, cada instância pertencente a um conjunto de nós recebe uma etiqueta que identifica um cluster do GKE específico do qual este conjunto de nós faz parte. Esta etiqueta é usada em regras de firewall que o GKE cria automaticamente para si. Pode adicionar etiquetas personalizadas no momento da criação do cluster ou do conjunto de nós através da flag
--tagsna CLI do Google Cloud.Políticas de rede. As políticas de rede permitem limitar as ligações de rede entre pods, o que pode ajudar a restringir a rotação de rede e o movimento lateral no interior do cluster em caso de um problema de segurança com um pod. Para usar políticas de rede, tem de ativar a funcionalidade explicitamente quando criar o cluster do GKE. Pode ativá-lo num cluster existente, mas fará com que os nós do cluster sejam reiniciados. O comportamento predefinido é que toda a comunicação entre pods está sempre aberta. Por conseguinte, se quiser segmentar a sua rede, tem de aplicar políticas de rede ao nível do pod. No GKE, pode definir uma política de rede através da API Kubernetes Network Policy ou através da ferramenta
kubectl. Estas regras de política de tráfego ao nível do pod determinam que pods e serviços podem aceder uns aos outros no seu cluster.Espaços de nomes. Os espaços de nomes permitem a segmentação de recursos no cluster do Kubernetes. O Kubernetes é fornecido com um espaço de nomes predefinido, mas pode criar vários espaços de nomes no cluster. Os espaços de nomes estão logicamente isolados uns dos outros. Fornecem âmbito para pods, serviços e implementações no cluster, para que os utilizadores que interagem com um espaço de nomes não vejam conteúdo noutro espaço de nomes. No entanto, os espaços de nomes no mesmo cluster não restringem a comunicação entre espaços de nomes. É aqui que entram as políticas de rede. Para mais informações sobre a configuração de espaços de nomes, consulte a publicação no blogue Práticas recomendadas para espaços de nomes.
O diagrama seguinte ilustra os conceitos anteriores em relação uns aos outros e a outros componentes do GKE, como o cluster, o nó e o pod.
Requisito 1.1
Os processos e os mecanismos para instalar e manter os controlos de segurança da rede estão definidos e são compreendidos.
Requisito 1.1.2
Descrever grupos, funções e responsabilidades para a gestão de componentes de rede.
Primeiro, tal como faria com a maioria dos serviços no Google Cloud, tem de configurar funções do IAM para configurar a autorização no GKE. Depois de configurar as funções do IAM, tem de adicionar a configuração do controlo de acesso baseado em funções do Kubernetes (CABF) como parte de uma estratégia de autorização do Kubernetes.
Essencialmente, toda a configuração da IAM aplica-se a todos os Google Cloud recursos e a todos os clusters num projeto. A configuração do RBAC do Kubernetes aplica-se aos recursos em cada cluster do Kubernetes e permite uma autorização detalhada ao nível do espaço de nomes. Com o GKE, estas abordagens à autorização funcionam em paralelo, com as capacidades de um utilizador a representarem efetivamente uma união das funções do IAM e do RBAC que lhe foram atribuídas:
- Use o IAM para controlar grupos, funções e responsabilidades para a gestão lógica de componentes de rede no GKE.
- Use o RBAC do Kubernetes para conceder autorizações detalhadas às políticas de rede em clusters do Kubernetes, para controlar o tráfego de pod para pod e para impedir alterações não autorizadas ou acidentais de utilizadores que não sejam do CDE.
- Ser capaz de justificar todas as autorizações e utilizadores de IAM e RBAC. Normalmente, quando os QSAs testam os controlos, procuram uma justificação empresarial para uma amostra de IAM e CABF.
Requisito 1.2
Os controlos de segurança de rede (NSCs) estão configurados e são mantidos.
Primeiro, configure as regras de firewall nas instâncias do Compute Engine que executam os seus nós do GKE. As regras de firewall protegem estes nós do cluster.
Em seguida, configure as políticas de rede para restringir os fluxos e proteger os pods num cluster. Uma política de rede é uma especificação de como os grupos de pods podem comunicar entre si e com outros pontos finais de rede. Pode usar a aplicação de políticas de rede do GKE para controlar a comunicação entre os pods e os serviços do cluster. Para segmentar ainda mais o cluster, crie vários espaços de nomes no mesmo. Os espaços de nomes estão logicamente isolados uns dos outros. Fornecem âmbito para pods, serviços e implementações no cluster, pelo que os utilizadores que interagem com um espaço de nomes não veem conteúdo noutro espaço de nomes. No entanto, os espaços de nomes no mesmo cluster não restringem a comunicação entre espaços de nomes. É aqui que entram as políticas de rede. Os espaços de nomes permitem a segmentação de recursos no cluster do Kubernetes. Para mais informações sobre a configuração de espaços de nomes, consulte a publicação no blogue Práticas recomendadas para espaços de nomes.
Por predefinição, se não existirem políticas num espaço de nomes, todo o tráfego de entrada e saída é permitido para e a partir de pods nesse espaço de nomes. Por exemplo, pode criar uma política de isolamento predefinida para um espaço de nomes criando uma política de rede que selecione todos os pods, mas não permita nenhum tráfego de entrada para esses pods.
Requisito 1.2.2
Todas as alterações às ligações de rede e às configurações dos NSCs são aprovadas e geridas de acordo com o processo de controlo de alterações definido no requisito 6.5.1.
Para tratar as suas configurações de rede e infraestrutura como código, tem de estabelecer um pipeline de integração contínua e entrega contínua (CI/CD) como parte dos seus processos de gestão e controlo de alterações.
Pode usar modelos do Cloud Deployment Manager ou do Terraform como parte do pipeline de CI/CD para criar políticas de rede nos seus clusters. Com o Deployment Manager ou o Terraform, pode tratar a configuração e a infraestrutura como código que pode reproduzir cópias consistentes da produção atual ou de outros ambientes. Em seguida, pode escrever testes unitários e outros testes para garantir que as alterações à rede funcionam como esperado. Um processo de controlo de alterações que inclui uma aprovação pode ser gerido através de ficheiros de configuração armazenados num repositório de versões.
Com o Terraform Config Validator, pode definir restrições para aplicar políticas de segurança e governação. Ao adicionar o Config Validator ao seu pipeline de CI/CD, pode adicionar um passo a qualquer fluxo de trabalho. Este passo valida um plano do Terraform e rejeita-o se forem encontradas violações.
Requisito 1.2.5
Todos os serviços, protocolos e portas permitidos são identificados, aprovados e têm uma necessidade empresarial definida.
Para ter controlos de entrada fortes para os seus clusters do GKE, pode usar redes autorizadas para restringir determinados intervalos de IP que podem alcançar o plano de controlo do seu cluster. O GKE usa o Transport Layer Security (TLS) e a autenticação para fornecer acesso seguro ao ponto final do plano de controlo do cluster a partir da Internet pública. Este acesso dá-lhe a flexibilidade de administrar o seu cluster a partir de qualquer lugar. Ao usar redes autorizadas, pode restringir ainda mais o acesso a conjuntos especificados de endereços IP.
Pode usar o Cloud Armor para criar listas de negação e listas de permissão de IPs, bem como políticas de segurança para aplicações alojadas no GKE. Num cluster do GKE, o tráfego de entrada é processado pelo balanceamento de carga de HTTP(S), que é um componente do Cloud Load Balancing. Normalmente, o balanceador de carga HTTP(S) é configurado pelo controlador de entrada do GKE, que recebe informações de configuração de um objeto Ingress do Kubernetes. Para mais informações, consulte o artigo como configurar políticas do 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, pode configurar comunicações privadas entre clusters do GKE nas suas redes VPC e implementações híbridas no local através dos VPC Service Controls e do acesso privado à Google.
Requisito 1.3.1
O tráfego de entrada para o CDE está restrito da seguinte forma:
- Para apenas o tráfego necessário.
- Todo o outro tráfego é especificamente recusado.
Considere implementar a configuração do Cloud NAT com o GKE para limitar o tráfego de Internet de entrada apenas a esse cluster. Pode configurar um cluster privado para os clusters não públicos no seu AFE. Num cluster privado, os nós têm apenas endereços IP RFC 1918 internos, o que garante que as respetivas cargas de trabalho estão isoladas da Internet pública.
Requisito 1.4
As ligações de rede entre redes fidedignas e não fidedignas são controladas.
Pode cumprir este requisito através dos mesmos métodos indicados para o requisito 1.3.
Requisito 1.4.3
São implementadas medidas antispoofing para detetar e bloquear endereços IP de origem falsificados que tentem entrar na rede fidedigna.
Implementa medidas anti-roubo de identidade usando endereços IP de alias em pods e clusters do GKE para detetar e bloquear endereços IP de origem falsificados de entrarem na rede. Um cluster que usa intervalos de IPs de alias é denominado cluster nativo de VPC.
Requisito 1.4.5
A divulgação de endereços IP internos e informações de encaminhamento está limitada apenas a partes autorizadas.
Pode usar um agente de mascaramento de IP do GKE para fazer a tradução de endereços de rede (NAT) para traduções de endereços IP de muitos para um num cluster. A ocultação mascara vários endereços IP de origem atrás de um único endereço.
Requisito 2
Aplique configurações seguras a todos os componentes do sistema.
O requisito 2 especifica como reforçar os parâmetros de segurança removendo as predefinições e as credenciais fornecidas pelo fornecedor. A proteção do cluster é da responsabilidade do cliente.
Requisito 2.2
Os componentes do sistema estão configurados e geridos de forma segura.
Certifique-se de que estas normas abordam todas as vulnerabilidades de segurança conhecidas e são consistentes com as normas de reforço do sistema aceites pela indústria. As origens das normas de reforço do sistema aceites pela indústria podem incluir, entre outras:Requisito 2.2.4
Apenas os serviços, os protocolos, os daemons e as funções necessários estão ativados, e todas as funcionalidades desnecessárias são removidas ou desativadas.
Requisito 2.2.5
- A justificação empresarial está documentada.
- São documentadas e implementadas funcionalidades de segurança adicionais que reduzem o risco de utilização de serviços, protocolos ou daemons não seguros.
Requisito 2.2.6
Os parâmetros de segurança do sistema estão configurados para evitar a utilização indevida.
Pré-implementação
Antes de mover contentores para o GKE, recomendamos o seguinte:
- Comece com uma imagem de base gerida por um contentor criada, mantida e com vulnerabilidades verificadas por uma fonte fidedigna. Pondere criar um conjunto de imagens base "conhecidas como boas" ou "ideais" que os seus programadores possam usar. Uma opção mais restritiva é usar uma imagem sem distribuição ou uma imagem base de raiz.
- Use a análise de artefactos para verificar se existem vulnerabilidades nas suas imagens de contentores.
- Estabeleça uma política interna de DevOps/SecOps para incluir apenas bibliotecas e ficheiros binários aprovados e fidedignos nos contentores.
Na configuração
Durante a configuração, recomendamos o seguinte:
- Use o SO otimizado para contentores predefinido como a imagem do nó para o GKE. O SO otimizado para contentores baseia-se no Chromium OS e está otimizado para a segurança dos nós.
- Ative a atualização automática de nós para os clusters que executam as suas aplicações. Esta funcionalidade atualiza automaticamente o nó para a versão do Kubernetes que está a ser executada no plano de controlo gerido, oferecendo melhor estabilidade e segurança.
- Ative os nós de autorreparação. Quando esta funcionalidade está ativada, o GKE verifica periodicamente e usa o estado de saúde do nó para determinar se um nó precisa de ser reparado. Se um nó precisar de reparação, esse nó é esvaziado e é criado um novo nó que é adicionado ao cluster.
- Ative o Cloud Monitoring e o Cloud Logging para ter visibilidade de todos os eventos, incluindo eventos de segurança e o estado de funcionamento dos nós. Crie políticas de alerta do Cloud Monitoring para receber uma notificação se ocorrer um incidente de segurança.
- Aplique contas de serviço com o menor número possível de privilégios para nós do GKE
- Reveja e aplique (quando aplicável) a secção do GKE no guia
Google Cloud CIS Benchmark. O registo de auditoria do Kubernetes já está ativado por predefinição e os registos de pedidos para
kubectle a API GKE são escritos nos registos de auditoria da nuvem. - Configure os registos de auditoria.
Proteja os dados da conta
A proteção dos dados dos titulares de cartões abrange os requisitos 3 e 4 da PCI DSS.
Requisito 3
Proteja os dados da conta armazenados.
O requisito 3 da PCI DSS estipula que as técnicas de proteção, como a encriptação, o corte, a ocultação e a aplicação de hash, são componentes críticos da proteção de dados dos titulares dos cartões. Se um intruso contornar outros controlos de segurança e obter acesso a dados encriptados, sem as chaves criptográficas adequadas, os dados são ilegíveis e inutilizáveis para essa pessoa.
Também pode considerar outros métodos de proteção dos dados armazenados como potenciais oportunidades de mitigação de riscos. Por exemplo, os métodos para minimizar o risco incluem não armazenar dados do titular do cartão, a menos que seja absolutamente necessário, truncar os dados do titular do cartão se o PAN completo não for necessário e não enviar PANs não protegidos através de tecnologias de mensagens para o utilizador final, como email e mensagens instantâneas.
Seguem-se exemplos de sistemas em que os DCH podem persistir como parte dos fluxos de processamento de pagamentos quando executados no Google Cloud :
- Contentores do Cloud Storage
- Instâncias do BigQuery
- Armazenamento de dados
- Cloud SQL
Tenha em atenção que os DCH podem ser armazenados inadvertidamente em registos de comunicação por email ou do serviço de apoio ao cliente. É prudente usar a proteção de dados confidenciais para filtrar estes fluxos de dados, de modo a limitar o seu ambiente no âmbito aos sistemas de processamento de pagamentos.
Tenha em atenção que, no Google Cloud, os dados são encriptados em repouso por predefinição, e encriptados em trânsito por predefinição quando atravessam limites físicos. Não é necessária nenhuma configuração adicional para ativar estas proteções.
Requisito 3.5
O número de conta principal (PAN) está protegido onde quer que seja armazenado.
Um mecanismo para tornar os dados do PAN ilegíveis é a tokenização. Para mais informações, consulte o guia de soluções sobre a tokenização de dados confidenciais do titular do cartão para a norma PCI DSS.
Pode usar a API DLP para analisar, descobrir e comunicar os dados do titular do cartão. A proteção de dados confidenciais tem suporte integrado para a análise e a classificação de dados de PAN de 12 a 19 dígitos no Cloud Storage, no BigQuery e no Datastore. Também tem uma API de conteúdo de streaming para ativar o suporte de origens de dados adicionais, cargas de trabalho personalizadas e aplicações. Também pode usar a API DLP para truncar (ocultar) ou aplicar hashs aos dados.
Requisito 3.6
As chaves criptográficas usadas para proteger os dados da conta armazenados estão seguras.
O Cloud Key Management Service (KMS) é um sistema de armazenamento gerido para chaves criptográficas. Pode gerar, usar, rodar e destruir chaves criptográficas. Embora o Cloud KMS não armazene diretamente segredos, como dados do titular do cartão, pode ser usado para encriptar esses dados.
Os segredos no contexto do Kubernetes são objetos secretos do Kubernetes que lhe permitem armazenar e gerir informações confidenciais, como palavras-passe, tokens e chaves.
Por predefinição, Google Cloud encripta o conteúdo do cliente armazenado em repouso. O GKE processa e gere esta encriptação predefinida por si sem qualquer ação adicional da sua parte. A encriptação de segredos da camada de aplicação oferece uma camada adicional de segurança para dados confidenciais, como segredos. Com esta funcionalidade, pode fornecer uma chave que gere no Cloud KMS, para encriptar dados na camada de aplicação. Isto protege contra atacantes que obtêm acesso a uma cópia da instância de armazenamento de configuração do Kubernetes do seu cluster.
Requisito 4
Proteger os dados de titulares de cartões com criptografia forte durante a transmissão através de redes públicas abertas.
Os dados no âmbito têm de ser encriptados durante a transmissão através de redes às quais os indivíduos maliciosos têm fácil acesso, por exemplo, redes públicas.
O Istio é uma malha de serviços de código aberto que se sobrepõe de forma transparente às aplicações distribuídas existentes. O Istio gere de forma escalável a autenticação, a autorização e a encriptação do tráfego entre microsserviços. É uma plataforma que inclui APIs que lhe permitem integrar-se em qualquer plataforma de registo, telemetria ou sistema de políticas. O conjunto de funcionalidades do Istio permite-lhe executar de forma eficiente uma arquitetura de microsserviços distribuídos e oferece uma forma uniforme de proteger, ligar e monitorizar microsserviços.
Requisito 4.1
Os processos e os mecanismos para proteger os dados de titulares de cartões com criptografia forte durante a transmissão através de redes públicas abertas estão definidos e documentados.
Pode usar o Istio para criar uma rede de serviços implementados com balanceamento de carga, autenticação de serviço a serviço e monitorização. Também pode usá-lo para oferecer comunicação segura entre serviços num cluster, com autenticação baseada na identidade forte e autorização baseada no TLS mútuo. O TLS mútuo (mTLS) é um handshake TLS realizado duas vezes, que estabelece o mesmo nível de confiança em ambas as direções (ao contrário da confiança cliente-servidor unidirecional).
O Istio permite-lhe implementar certificados TLS em cada um dos pods do GKE numa aplicação. Os serviços executados no pod podem usar o mTLS para identificar fortemente as respetivas identidades de pares. A comunicação entre serviços é encaminhada através de proxies Envoy do lado do cliente e do lado do servidor. O Envoy usa IDs SPIFFE para estabelecer ligações mTLS entre serviços. Para obter informações sobre como implementar o Istio no GKE, consulte a documentação do GKE. Para obter informações sobre as versões do TLS suportadas, consulte a referência de gestão de tráfego do Istio. Use a versão 1.2 e posteriores do TLS.
Se a sua aplicação estiver exposta à Internet, use o balanceamento de carga HTTP(S) do GKE com o encaminhamento de entrada definido para usar HTTP(S). O balanceamento de carga HTTP(S), configurado por um objeto Ingress, inclui as seguintes funcionalidades:
- Configuração flexível para serviços. Um objeto Ingress define como o tráfego chega aos seus serviços e como o tráfego é encaminhado para a sua aplicação. Além disso, um Ingress pode fornecer um único endereço IP para vários serviços no seu cluster.
- Integração com Google Cloud serviços de rede. Um objeto Ingress pode configurar Google Cloud funcionalidades como certificados SSL geridos pela Google (beta), Cloud Armor, Cloud CDN, e Identity-Aware Proxy.
- Suporte para vários certificados TLS. Um objeto Ingress pode especificar a utilização de vários certificados TLS para a terminação de pedidos.
Quando cria um objeto Ingress, o controlador de entrada do GKE cria um balanceador de carga HTTP(S) da nuvem e configura-o de acordo com as informações no Ingress e nos respetivos serviços associados.
Mantenha um programa de gestão de vulnerabilidades
A manutenção de um programa de gestão de vulnerabilidades abrange os requisitos 5 e 6 da PCI DSS.
Requisito 5
Proteger todos os sistemas e redes contra software malicioso.
O requisito 5 da PCI DSS estipula que o software antivírus tem de ser usado em todos os sistemas normalmente afetados por software malicioso para proteger os sistemas de ameaças de software malicioso atuais e em evolução, e os contentores não são exceção.
Requisito 5.2
O software malicioso é impedido ou detetado e resolvido.
Tem de implementar programas de gestão de vulnerabilidades para as suas imagens de contentores.
Recomendamos que efetue as seguintes ações:
- Verifique e aplique regularmente patches de segurança atualizados nos contentores.
- Realize análises de vulnerabilidades regulares em aplicações contentorizadas e binários/bibliotecas.
- Analise imagens como parte do pipeline de compilação.
- Subscreva um serviço de informações sobre vulnerabilidades para receber informações atualizadas sobre vulnerabilidades relevantes para o ambiente e as bibliotecas usadas nos contentores.
Google Cloud funciona com vários fornecedores de soluções de segurança de contentores para melhorar a postura de segurança nas implementações dos clientes Google Cloud . Recomendamos que tire partido de soluções e tecnologias 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 pela Google, consulte Parceiros de segurança.Google Cloud
Requisito 5.2.2
As soluções antimalware implementadas:
- Deteta todos os tipos conhecidos de software malicioso.
- Remove, bloqueia ou contém todos os tipos conhecidos de software malicioso.
Requisito 5.2.3
Todos os componentes do sistema que não estão em risco de software malicioso são avaliados periodicamente para incluir o seguinte:
- Uma lista documentada de todos os componentes do sistema que não estão em risco de software malicioso.
- Identificação e avaliação de ameaças de software malicioso em evolução para esses componentes do sistema.
- Confirmação de que esses componentes do sistema continuam a não exigir proteção anti-software malicioso.
Existem muitas soluções disponíveis para realizar análises de software malicioso, mas a norma PCI DSS reconhece que nem todos os sistemas têm a mesma probabilidade de serem vulneráveis. É comum os comerciantes declararem os respetivos servidores Linux, mainframes e máquinas semelhantes como não "afetados frequentemente por software malicioso" e, por isso, isentos do ponto 5.2.2. Nesse caso, aplica-se o ponto 5.2.3 e tem de implementar um sistema para avaliações periódicas de ameaças.
Tenha em atenção que estas regras se aplicam aos nós e aos pods num cluster do GKE.
Requisito 5.3
Os mecanismos e os processos antimalware estão ativos, são mantidos e monitorizados.
Os requisitos 5.2, 5.3 e 11.5 exigem análises antivírus e monitorização da integridade dos ficheiros (FIM) em qualquer anfitrião no âmbito. Recomendamos a implementação de uma solução em que todos os nós possam ser analisados por um agente fidedigno no cluster ou em que cada nó tenha um analisador que comunique a um único ponto final de gestão.
Para mais informações, consulte a vista geral da segurança do GKE e a vista geral da segurança do SO otimizado para contentores.
Uma solução comum para os requisitos de antivírus e FIM é bloquear o contentor para que apenas pastas permitidas específicas tenham acesso de escrita. Para o fazer, execute os seus contentores como um utilizador não root e use autorizações do sistema de ficheiros para impedir o acesso de escrita a todos os diretórios, exceto os diretórios de trabalho no sistema de ficheiros do contentor. Não permitir escalamento de privilégios para evitar a circumvenção das regras do sistema de ficheiros.
Requisito 6
Desenvolver e manter sistemas e software seguros.
O requisito 6 da PCI DSS estipula que estabeleça um ciclo de vida de desenvolvimento de software forte em que a segurança esteja integrada em cada passo do desenvolvimento de software.
Requisito 6.2
O software personalizado e feito à medida é desenvolvido em segurança.
Requisito 6.2.1
O software personalizado e feito à medida é desenvolvido de forma segura, da seguinte forma:
- Com base nas normas da indústria e/ou nas práticas recomendadas para o desenvolvimento seguro.
- De acordo com a PCI DSS (por exemplo, autenticação e registo seguros).
- Incorporar a consideração de problemas de segurança da informação durante cada fase do ciclo de vida de desenvolvimento de software.
Pode usar a autorização binária para ajudar a garantir que apenas os contentores fidedignos são implementados no GKE. Se quiser ativar apenas imagens autorizadas por um ou mais atestadores específicos, pode configurar a autorização binária para aplicar uma política com regras que exijam atestações com base nos resultados da análise de vulnerabilidades. Também pode escrever políticas que exijam que uma ou mais partes fidedignas (denominadas "atestadores") aprovem uma imagem antes de poder ser implementada. Para um pipeline de implementação de várias fases em que as imagens progridem de clusters de desenvolvimento para testes e produção, pode usar atestadores para garantir que todos os processos necessários foram concluídos antes de o software passar para a fase seguinte.
No momento da implementação, a Autorização Binária aplica a sua política verificando se a imagem do contentor passou em todas as restrições necessárias, incluindo se todos os atestadores necessários verificaram que a imagem está pronta para implementação. Se a imagem passar, o serviço permite a sua implementação. Caso contrário, a implementação é bloqueada e não é possível implementar a imagem até estar em conformidade.
Para mais informações sobre a autorização binária, consulte o artigo Configure para o GKE.
Numa emergência, pode ignorar uma política de autorização binária através do fluxo de trabalho de acesso de emergência. Todos os incidentes de acesso de emergência são registados nos registos de auditoria do Google Cloud.
O GKE Sandbox reduz a necessidade de o contentor interagir diretamente com o anfitrião, diminuindo a superfície de ataque para comprometimento do anfitrião e restringindo o movimento de atores maliciosos.
Requisito 6.3
As vulnerabilidades de segurança são identificadas e resolvidas.
Requisito 6.3.1
As vulnerabilidades de segurança são identificadas e geridas da seguinte forma:
- As novas vulnerabilidades de segurança são identificadas através de fontes reconhecidas pela indústria para informações de vulnerabilidades de segurança, incluindo alertas de equipas de resposta a emergências informáticas (CERTs) internacionais e nacionais.
- É atribuída uma classificação de risco às vulnerabilidades com base nas práticas recomendadas da indústria e na consideração do potencial impacto.
- As classificações de risco identificam, no mínimo, todas as vulnerabilidades consideradas de alto risco ou críticas para o ambiente.
- As vulnerabilidades para software personalizado e de terceiros (por exemplo, sistemas operativos e bases de dados) estão abrangidas.
A segurança na nuvem é uma responsabilidade partilhada entre o fornecedor de nuvem e o cliente.
No GKE, a Google gere o plano de controlo, que inclui as VMs principais, o servidor de API e outros componentes executados nessas VMs, bem como a base de dados etcd. Isto inclui atualizações e aplicação de patches, escalabilidade e reparações, tudo apoiado por um objetivo ao nível do serviço (SLO). Para o sistema operativo dos nós, como o SO otimizado para contentores ou o Ubuntu, o GKE disponibiliza imediatamente todos os patches para estas imagens. Se tiver a atualização automática ativada, estas correções são implementadas automaticamente. (Esta é a camada base do seu contentor. Não é igual ao sistema operativo em execução nos seus contentores.)
Para mais informações sobre o modelo de responsabilidade partilhada do GKE, consulte o artigo Explorar a segurança de contentores: o modelo de responsabilidade partilhada no GKE.
A Google oferece vários serviços de segurança para ajudar a incorporar segurança na sua pipeline de CI/CD. Para identificar vulnerabilidades nas suas imagens de contentores, pode usar a análise de vulnerabilidades do Google Artifact Analysis. Quando uma imagem de contentor é enviada para o Google Container Registry (GCR), a análise de vulnerabilidades analisa automaticamente as imagens quanto à existência de vulnerabilidades e exposições conhecidas de fontes CVE conhecidas. As vulnerabilidades são atribuídas a níveis de gravidade (crítico, elevado, médio, baixo e mínimo) com base nas pontuações CVSS.
Requisito 6.4
As aplicações Web viradas para o público estão protegidas contra ataques.
O Web Security Scanner permite-lhe analisar as aplicações Web do App Engine, Compute Engine e GKE acessíveis publicamente para detetar vulnerabilidades comuns, desde o cross-site scripting e as configurações incorretas até aos recursos vulneráveis. As análises podem ser realizadas a pedido e agendadas a partir da Google Cloud consola. Ao usar as APIs Security Scanner, pode automatizar a análise como parte do seu conjunto de testes de segurança no pipeline de compilação da aplicação.
Implemente medidas de controlo de acesso fortes
A implementação de medidas de controlo de acesso fortes abrange os requisitos 7, 8 e 9 da PCI DSS.
Requisito 7
Restrinja o acesso aos componentes do sistema e aos dados dos titulares de cartões com base na necessidade de conhecimento da empresa.
O requisito 7 centra-se no menor privilégio ou na necessidade de saber. A norma PCI DSS define-os como a concessão de acesso à menor quantidade de dados e a disponibilização do menor número de privilégios necessários para realizar uma tarefa.
Requisito 7.2
O acesso aos componentes e dados do sistema está devidamente definido e atribuído.
O IAM e o controlo de acesso baseado em funções (CABF) do Kubernetes funcionam em conjunto para fornecer um controlo de acesso detalhado ao seu ambiente do GKE. A IAM é usada para gerir o acesso e as autorizações dos utilizadores aos Google Cloud recursos no seu projeto do CDE. No GKE, também pode usar o IAM para gerir o acesso e as ações que os utilizadores e as contas de serviço podem realizar nos seus clusters, como criar e eliminar clusters.
O RBAC do Kubernetes permite-lhe configurar conjuntos detalhados de autorizações que definem como um determinado Google Cloud utilizador, Google Cloud contas de serviço ou grupo de utilizadores (Grupos Google) pode interagir com qualquer objeto do Kubernetes no seu cluster ou num namespace específico do seu cluster. Alguns exemplos de autorizações de RBAC incluem a edição de implementações ou mapas de configuração, a eliminação de pods ou a visualização de registos de um pod. Conceda aos utilizadores ou aos serviços autorizações de IAM limitadas, como o Visualizador de clusters do Google Kubernetes Engine ou funções personalizadas e, em seguida, aplique as associações de funções RBAC do Kubernetes, conforme adequado.
O Cloud Identity Aware Proxy (IAP) pode ser integrado através da entrada para o GKE para controlar o acesso ao nível da aplicação para funcionários ou pessoas que necessitam de acesso às suas aplicações PCI.
Além disso, pode usar as políticas da organização para restringir as APIs e os serviços disponíveis num projeto.
Requisito 7.2.2
O acesso é atribuído aos utilizadores, incluindo utilizadores privilegiados, com base no seguinte:
- Classificação e função do trabalho.
- Privilégios mínimos necessários para desempenhar as responsabilidades do trabalho.
Além de garantir que os utilizadores e as contas de serviço cumprem o princípio do menor privilégio, os contentores também devem fazê-lo. Uma prática recomendada quando executa um contentor é executar o processo com um utilizador não root. Pode realizar e aplicar esta prática através do controlador de admissão PodSecurity.
O PodSecurity é um controlador de admissão do Kubernetes que lhe permite aplicar normas de segurança de pods a pods em execução nos seus clusters do GKE. As normas de segurança de pods são políticas de segurança predefinidas que abrangem as necessidades de segurança de pods de alto nível no Kubernetes. Estas políticas variam entre altamente permissivas e altamente restritivas. O PodSecurity substitui o antigo controlador de admissão PodSecurityPolicy que foi removido no Kubernetes v1.25. Estão disponíveis instruções para migrar da PodSecurityPolicy para o controlador de admissão PodSecurity.
Requisito 8
Identificar utilizadores e autenticar o acesso aos componentes do sistema
O requisito 8 especifica que tem de ser atribuído um ID exclusivo a cada pessoa que tenha acesso a sistemas PCI no âmbito para garantir que cada indivíduo é exclusivamente responsável pelas suas ações.
Requisito 8.2
A identificação dos utilizadores e as contas relacionadas para utilizadores e administradores são rigorosamente geridas ao longo do ciclo de vida de uma conta.
Requisito 8.2.1
Todos os utilizadores têm um ID exclusivo atribuído antes de ser permitido o acesso a componentes do sistema ou dados do titular do cartão.
Requisito 8.2.5
O acesso dos utilizadores terminados é imediatamente revogado.
Pode usar o IAM e o RBAC do Kubernetes para controlar o acesso ao seu cluster do GKE e, em ambos os casos, pode conceder autorizações a um utilizador. Recomendamos que os utilizadores estejam associados ao seu sistema de identidade existente, para que possa gerir as contas de utilizador e as políticas num único local.
Requisito 8.3
A autenticação forte para utilizadores e administradores é estabelecida e gerida.
Requisito 8.3.1
- Algo que sabe, como uma palavra-passe ou uma frase secreta.
- Algo que o utilizador tem, como um dispositivo de token ou um cartão inteligente.
- Algo que é, como um elemento biométrico.
Os certificados estão associados à identidade de um utilizador quando
efetuam a autenticação no kubectl.
Todos os clusters do GKE estão configurados para aceitar identidades de utilizadores e contas de serviço, validando as credenciais e obtendo o endereço de email associado à identidade do utilizador ou da conta de serviço. Google Cloud Como resultado, as credenciais dessas contas têm de incluir o userinfo.email âmbito do OAuth
para a autenticação ser bem-sucedida.
Requisito 9
Restrinja o acesso físico aos dados do titular do cartão.
A Google é responsável pelos controlos de segurança física em todos os centros de dados da Google subjacentes ao Google Cloud.
Monitorizar e testar redes regularmente
A monitorização e os testes regulares de redes abrangem os requisitos 10 e 11 da PCI DSS.
Requisito 10
Registar e monitorizar todo o acesso aos componentes do sistema e aos dados de titulares de cartões.
Requisito 10.2
Os registos de auditoria são implementados para suportar a deteção de anomalias e atividade suspeita, bem como a análise forense de eventos.
Os clusters do Kubernetes têm o registo de auditoria do Kubernetes ativado por predefinição, o que mantém um registo cronológico das chamadas que foram feitas para o servidor da API Kubernetes. As entradas do registo de auditoria do Kubernetes são úteis para investigar pedidos de API suspeitos, recolher estatísticas ou criar alertas de monitorização para chamadas API indesejadas.
Os clusters do GKE integram uma configuração predefinida para o registo de auditoria do GKE com os registos de auditoria da nuvem e o registo. Pode ver as entradas do registo de auditoria do Kubernetes no seu Google Cloud projeto.
Além das entradas escritas pelo Kubernetes, os registos de auditoria do seu projeto têm entradas escritas pelo GKE.
Para diferenciar as cargas de trabalho de CDE e não CDE, recomendamos que adicione etiquetas aos seus pods do GKE que vão filtrar as métricas e os registos emitidos a partir dessas cargas de trabalho.
Requisito 10.2.2
- Identificação do utilizador
- Tipo de evento
- Data e hora
- Indicação de êxito ou falha
- Origem do evento
- Identidade ou nome dos dados, do componente do sistema, do recurso ou do serviço afetado (por exemplo, nome e protocolo)
Cada entrada do registo de auditoria no Logging é um objeto do tipo
LogEntry
que contém os seguintes campos:
- Uma carga útil, que é do tipo
protoPayload. A carga útil de cada entrada do registo de auditoria é um objeto do tipoAuditLog. Pode encontrar a identidade do utilizador no campoAuthenticationInfodos objetosAuditLog. - O evento específico, que pode encontrar no campo
methodNamedeAuditLog. - Uma indicação de tempo.
- O estado do evento, que pode encontrar nos objetos
responseno objetoAuditLog. - O pedido de operação, que pode encontrar nos objetos
requesterequestMetadatano objetoAuditLog. - O serviço que vai ser realizado, que pode encontrar no objeto
AuditDataemserviceData.
Requisito 11
Teste a segurança dos sistemas e das redes regularmente.
Requisito 11.3
As vulnerabilidades externas e internas são identificadas, priorizadas e resolvidas regularmente.
Requisito 11.3.1
- Pelo menos uma vez a cada três meses.
- As 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 feitas novas análises que confirmam que todas as vulnerabilidades críticas e de alto risco (conforme indicado acima) foram resolvidas.
- A ferramenta de análise é mantida atualizada com as informações de vulnerabilidade mais recentes.
- As análises são realizadas por pessoal qualificado e existe independência organizacional do testador.
A análise de artefactos análise de vulnerabilidades realiza os seguintes tipos de análise de vulnerabilidades para as imagens no Container Registry:
Análise inicial. Quando ativa a API Artifact Analysis pela primeira vez, esta analisa as suas imagens no Container Registry e extrai o gestor de pacotes, a base de imagens e as ocorrências de vulnerabilidades das imagens.
Análise incremental. A análise de artefactos analisa novas imagens quando são carregadas para o Container Registry.
Análise contínua: à medida que a análise de artefactos recebe informações de vulnerabilidade novas e atualizadas de origens de vulnerabilidades, volta a executar a análise de contentores para manter atualizada a lista de ocorrências de vulnerabilidades para imagens já analisadas.
Requisito 11.5
As intrusões na rede e as alterações inesperadas aos ficheiros são detetadas e respondidas.
Requisito 11.5.1
- Todo o tráfego é monitorizado no perímetro do CDE.
- Todo o tráfego é monitorizado em pontos críticos no CDE.
- O pessoal é alertado para suspeitas de compromissos.
- Todos os motores de deteção e prevenção de intrusões, as referências e as assinaturas são mantidos atualizados.
Google Cloud O espelhamento de pacotes pode ser usado com o IDS na nuvem para detetar intrusões na rede. Google Cloud O espelhamento de pacotes encaminha todo o tráfego de rede das suas VMs do Compute Engine ou Google Cloud clusters para um endereço designado. O Cloud IDS pode consumir este tráfego espelhado para detetar uma vasta gama de ameaças, incluindo tentativas de exploração, verificações de portas, sobrecargas do buffer, fragmentação de protocolos, tráfego de comando e controlo (C2) e software malicioso.
O Security Command Center oferece visibilidade centralizada do estado de segurança dos Google Cloud serviços (incluindo o GKE) e dos recursos em toda a sua organização, o que facilita a prevenção, a deteção e a resposta a ameaças. Ao usar o Security Command Center, pode ver quando foram detetadas ameaças de alto risco, como software malicioso, mineração de criptomoedas, acesso não autorizado a Google Cloud recursos, ataques DDoS de saída, análise de portas e SSH de força bruta com base nos seus registos do Cloud Logging.
Mantenha uma política de segurança da informação
Uma política de segurança forte define o tom de segurança e informa as pessoas sobre o que se espera delas. Neste caso, "pessoas" refere-se a funcionários a tempo inteiro e a tempo parcial, funcionários temporários, contratados e consultores que têm acesso ao seu CDE.
Requisito 12
Apoie a segurança da informação com políticas e programas organizacionais.
Para ver informações sobre o requisito 12, consulte a Google Cloud matriz de responsabilidade partilhada da PCI.
Limpar
Se usou recursos enquanto seguia este artigo, por exemplo, se iniciou novas VMs ou usou os scripts do Terraform, pode evitar incorrer em custos na sua Google Cloud conta eliminando o projeto onde 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.
O que se segue?
- Saiba mais acerca da conformidade com a norma de segurança de dados da PCI.
- Experimente o Terraform Starter Kit.
- Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.