Limitar o âmbito da conformidade para ambientes PCI em Google Cloud

Last reviewed 2025-03-12 UTC

Este documento descreve as práticas recomendadas para arquitetar o seu ambiente na nuvem para a conformidade com o Payment Card Industry (PCI) Security Standards Council. Estas práticas recomendadas são úteis para organizações que estão a migrar ou a conceber sistemas na nuvem sujeitos aos requisitos de conformidade com a PCI. Este documento refere-se aos requisitos da PCI DSS 4.0, quando aplicável.

Compreender o âmbito da avaliação da PCI DSS

Se a sua organização realizar comércio através da Internet, tem de suportar e manter a conformidade com a PCI. A forma como concebe e gere o seu ambiente de nuvem afeta o âmbito dos seus sistemas para a avaliação da Norma de Segurança de Dados (DSS) da PCI. O âmbito tem implicações importantes para a segurança dos seus ativos de TI e para a sua capacidade de apoiar e manter a conformidade com a PCI. Para garantir que o seu ambiente de PCI está corretamente definido, tem de compreender como os seus processos empresariais e decisões de design afetam o âmbito.

O que é o âmbito?

Todos os sistemas que armazenam, processam ou transmitem dados do titular do cartão (CHD) estão no âmbito da sua avaliação da PCI DSS. A segurança é importante para todo o seu ambiente de nuvem, mas o comprometimento dos sistemas no âmbito pode causar uma violação de dados e a exposição de DPC.

Figura 1. Diagrama da definição do âmbito da PCI DSS.

Na figura 1, o ambiente de dados do titular do cartão (CDE), os sistemas ligados e os sistemas com impacto na segurança estão dentro do limite do âmbito da avaliação, enquanto os sistemas não fidedignos e fora do âmbito estão fora do limite do âmbito da avaliação.

De acordo com a PCI DSS, os sistemas no âmbito são fidedignos. Os sistemas no âmbito incluem o seu CDE e qualquer sistema que esteja ligado ou possa afetar a segurança do seu CDE.

Um sistema está ligado a se estiver na mesma rede, partilhar bases de dados ou armazenamento de ficheiros, ou tiver acesso ou ligação a qualquer sistema ou processo que resida no AAD, mas não tiver acesso direto a DSH.

Um sistema tem impacto na segurança se, em caso de comprometimento, permitir que um atacante obtenha acesso ao AAE. Todos os sistemas ligados e com impacto na segurança estão sempre no âmbito.

Os sistemas fora do âmbito são não fidedignos por definição na PCI DSS e não têm valor para um atacante que queira obter acesso a CHD ou dados de autenticação confidenciais (SAD). Um sistema está fora do âmbito se não puder ter impacto na segurança de um sistema no âmbito, mesmo que o sistema fora do âmbito esteja comprometido. Embora os sistemas fora do âmbito não sejam avaliados diretamente, o avaliador de segurança qualificado (QSA) do PCI verifica se o seu âmbito é preciso e protege os DCHs de acordo com a norma PCI DSS. Por conseguinte, é importante que os limites do âmbito estejam fortemente protegidos, monitorizados de forma contínua e exaustiva, e claramente documentados.

Ligações no contexto da PCI

Vários requisitos da PCI DSS fazem referência a ligações, mas a PCI DSS não define explicitamente as ligações. Pode interpretar o significado das ligações neste contexto compreendendo a árvore de decisão de âmbito no Guia do PCI SSC para a definição do âmbito e a segmentação de rede do PCI DSS (PDF).

Para efeitos de avaliação do seu âmbito da PCI, uma ligação é definida da seguinte forma:

• Um transporte de informações ativo que liga dois computadores ou sistemas
• Qual das duas partes inicia a chamada

Quando documenta o seu ambiente, é melhor indicar claramente que parte está autorizada a iniciar uma ligação. Uma firewall configurada para permitir apenas tráfego num sentido pode aplicar uma ligação unidirecional. Por exemplo, uma aplicação de processamento de pagamentos no âmbito pode fazer consultas a um servidor de base de dados fora do âmbito sem que o servidor fora do âmbito entre no âmbito se todas as seguintes condições forem verdadeiras:

• A ligação e a base de dados fora do âmbito não armazenam, processam nem transmitem CHD nem SAD.
• A base de dados está numa rede separada ou está segmentada de outra forma a partir do CDE.
• A base de dados não pode iniciar chamadas para o CDE direta ou indiretamente.
• A base de dados não fornece serviços de segurança ao AEP.
• A base de dados não afeta a configuração nem a segurança do CDE.
• A base de dados suporta os requisitos da PCI DSS.

O diagrama seguinte mostra os fatores que determinam o âmbito do sistema:

Figura 2. Fluxograma para determinar o âmbito do sistema.

Na figura 2, o âmbito do sistema é determinado da seguinte forma:

• Componentes do sistema que estão no âmbito da PCI DSS:

  • Sistemas que estão no CDE para os quais uma das seguintes afirmações é verdadeira:
    • Um componente do sistema armazena, processa ou transmite CHD ou SAD.
    • Um componente do sistema está no mesmo segmento de rede, por exemplo, na mesma sub-rede ou VLAN, que os sistemas que armazenam, processam ou transmitem DHC.
  • Sistemas ligados ou sistemas com impacto na segurança para os quais uma das seguintes opções é verdadeira:
    • Um componente do sistema liga-se diretamente ao CDE.
    • Um componente do sistema afeta a configuração ou a segurança do CDE.
    • Um componente do sistema segmenta os sistemas de CDE dos sistemas e das redes fora do âmbito.
    • Um componente do sistema liga-se indiretamente ao AEF.
    • Um componente do sistema fornece serviços de segurança ao AEP.
    • Um componente do sistema suporta os requisitos da PCI DSS.

• Os componentes do sistema podem ser considerados não fidedignos e fora do âmbito da norma PCI DSS quando todas as seguintes condições se aplicam:

  • Um componente do sistema não armazena, processa nem transmite CHD nem SAD.
  • Um componente do sistema não está no mesmo segmento de rede, por exemplo, na mesma sub-rede ou VLAN, que os sistemas que armazenam, processam ou transmitem CHD ou SAD.
  • Um componente do sistema não consegue estabelecer ligação a nenhum sistema no AAD.
  • Um componente do sistema não cumpre nenhum critério para sistemas ligados ou que afetam a segurança.

  Os sistemas fora do âmbito podem incluir sistemas que se ligam a um componente do sistema ligado ou com impacto na segurança, onde existem controlos para impedir que o sistema fora do âmbito obtenha acesso ao AAD através do componente do sistema no âmbito.

Em termos práticos, a definição do âmbito do sistema da PCI DSS pode significar que a loja de sessões e a base de dados de comércio eletrónico da sua aplicação Web podem ser consideradas fora do âmbito se a segmentação for implementada e documentada corretamente. O diagrama seguinte mostra como funcionam as ligações de leitura e escrita entre sistemas dentro do âmbito e sistemas fora do âmbito:

Figura 3. Aplicações abrangidas capazes de chamar serviços e aplicações não abrangidos.

A Figura 3 mostra as seguintes associações:

• Só de leitura:
  • Uma aplicação de processamento de pagamentos no âmbito lê um ID do carrinho de uma base de dados de carrinhos fora do âmbito e lê dados de um DNS e um NTP.
• Apenas escrita:
  • Uma aplicação de processamento de pagamentos no âmbito escreve na base de dados principal de uma aplicação fora do âmbito e no Cloud Logging.
  • A aplicação Web principal fora do âmbito escreve dados num serviço de registo. Estes dados não incluem CHD nem SAD.
• Leitura e escrita:
  • Um utilizador na Web pública lê e escreve metadados de pedidos da seguinte forma:
    • O utilizador lê e escreve numa aplicação de processamento de pagamentos no âmbito. Estes metadados do pedido são o ID do carrinho e a chave de autenticação do carrinho que contêm CHD e SAD.
    • O utilizador lê e escreve na aplicação Web principal fora do âmbito. Estes metadados do pedido são um ID da sessão que não contém CHD nem SAD.
  • A aplicação Web principal fora do âmbito lê e escreve dados numa base de dados de carrinho, num armazenamento de sessões e numa base de dados principal da aplicação fora do âmbito. Estes dados não incluem CHD nem SAD.
  • Uma aplicação de processamento de pagamentos no âmbito lê e escreve dados num serviço de tokenização de cartões no âmbito e num processador de cartões de crédito na Web pública. Estes dados incluem a doença coronária e a doença arterial.

A arquitetura na figura 3 descreve duas aplicações Web discretas: a aplicação Web principal (aplicação principal), que está fora do âmbito da PCI, e a aplicação de processamento de pagamentos (aplicação de pagamento), que está no âmbito. Nesta arquitetura, uma ligação só pode ser iniciada entre duas entidades nas direções descritas na lista anterior. As associações entre entidades podem ser só de leitura, de leitura e escrita, ou só de escrita na perspetiva do autor da chamada. Qualquer caminho ou direção de pedido que não seja descrito explicitamente é bloqueado pela segmentação. Por exemplo, a aplicação de processamento de pagamentos pode ler a partir da base de dados do carrinho e escrever no serviço de registo, o que envolve iniciar uma ligação a essas entidades.

Os sistemas no âmbito chamam frequentemente sistemas e serviços fora do âmbito. Estas ligações permanecem seguras porque a segmentação impede que qualquer autor da chamada remoto (que não seja um titular do cartão) inicie uma ligação ao AAD direta ou indiretamente. A Figura 3 mostra que o único caminho de entrada para a aplicação de pagamento é a partir do utilizador.

Na figura 3, nenhum serviço ou aplicação fora do âmbito fornece dados de configuração ou de segurança à aplicação de processamento de pagamentos. Os dados fluem através da arquitetura da seguinte forma:

1. A aplicação principal encaminha o utilizador para a aplicação de pagamento e usa um POST HTTP para transmitir o CartID e um validador denominado CartAuthKey. O CartAuthKey é um hash do CartID e um segredo pré-partilhado conhecido apenas pelas aplicações principal e de pagamento.
2. A aplicação de pagamento valida o utilizador através da aplicação de hash ao CartID juntamente com o segredo e comparando esse valor com o CartAuthKey.
3. Depois de os dados do utilizador serem autenticados, o CartID é usado para ler o conteúdo do carrinho na base de dados do carrinho. Todos os dados do titular do cartão são enviados do utilizador diretamente para a aplicação de pagamento.
4. Se forem usados perfis de pagamentos, os dados do titular do cartão são armazenados no serviço de tokenização.
5. Após o processamento do pagamento, o resultado é inserido na base de dados da aplicação principal com uma conta de serviço da base de dados apenas de escrita.

Considerações sobre o âmbito

Nas orientações para o âmbito e a segmentação de rede da PCI DSS, o PCI Security Standards Council (SSC) recomenda que considere que tudo está no âmbito até ser verificado o contrário. Esta recomendação de SSC não significa que deve tornar o seu âmbito o mais amplo possível. Em vez disso, significa que o QSA avalia todos os sistemas como se fossem fidedignos, a menos que possa demonstrar que um sistema não tem conetividade com o seu AEP nem impacto na segurança do mesmo. Para cumprir os requisitos de conformidade regulamentar e manter os seus recursos de TI seguros, deve definir o âmbito do seu ambiente em conformidade com o princípio do menor privilégio, confiando no menor número possível de sistemas.

Antes da avaliação, avalie o seu ambiente para compreender e documentar o limite entre os sistemas no âmbito e fora do âmbito. A primeira tarefa do QSA é confirmar se o âmbito documentado abrange razoavelmente o CDE e os sistemas ligados. Como parte da avaliação geral, o QSA verifica então se os sistemas fora do âmbito não podem afetar negativamente os sistemas dentro do âmbito.

Certifique-se de que compreende quaisquer circunstâncias especiais específicas do seu ambiente, como as seguintes:

• Se recolher dados de titulares de cartões por telefone ou através de um sistema VOIP, considere os problemas de âmbito adicionais descritos no documento Proteção de dados de cartões de pagamento baseados em telefone (PDF).
• Se o seu fornecedor de serviços exigir acesso ao seu CDE (PDF) para operar um sistema de ponto de venda, o sistema que o seu fornecedor de serviços usa pode ser considerado um sistema ligado. Isto pode exigir considerações adicionais de âmbito e diligência devida.

As práticas recomendadas de segurança da Google podem ajudar a estabelecer e demonstrar um limite claro e defensável entre os sistemas no âmbito e não fidedignos, o que vai ajudar na sua avaliação. Quando gere o acesso e a segurança praticando o princípio do menor privilégio, ajuda a minimizar o número de pontos de exposição dos dados do titular do cartão, minimiza a superfície de ataque do seu CDE e, consequentemente, reduz o seu âmbito. Quando reduz a dimensão dos sistemas no âmbito, ajuda a reduzir a complexidade do sistema e a simplificar a sua avaliação da norma PCI DSS.

Riscos de segmentação incorreta

Um âmbito demasiado amplo pode levar a avaliações dispendiosas e a um aumento dos riscos de conformidade. Para ajudar a manter um âmbito restrito, confie no menor número possível de sistemas e conceda acesso apenas a um grupo selecionado de utilizadores designados. Através de uma avaliação diligente e da autoavaliação, pode identificar sistemas que não devem estar no âmbito da norma PCI DSS, verificar se cumprem as diretrizes para sistemas fora do âmbito e reduzir o âmbito em conformidade. Este processo de eliminação é a forma mais segura de descobrir que sistemas não são fidedignos e ajudar a garantir que não afetam os sistemas no âmbito.

Se precisar de uma grande área de infraestrutura para cumprir os requisitos da PCI DSS, pode fazer com que sistemas externos sejam incluídos no âmbito da sua avaliação. Quando inclui sistemas externos no seu âmbito, coloca em risco a sua capacidade de alcançar a conformidade. Também pode degradar a sua postura de segurança geral, ampliando a superfície de ataque do seu ambiente fidedigno no âmbito.

Um princípio fundamental da segurança de rede e da PCI DSS é assumir que parte ou toda a sua rede já foi comprometida. Este princípio está consagrado no modelo de segurança de confiança zero da Google, que rejeita a segurança apenas no perímetro em favor de um modelo em que cada sistema é responsável pela sua própria segurança. O modelo de segurança da Google está alinhado com a norma PCI DSS, que recomenda que o AAD e os respetivos sistemas ligados sejam implementados num espaço pequeno e fidedigno segmentado do seu ambiente de TI mais amplo e não misturado com este.

No seu ambiente de PCI no âmbito, não coloque o CDE num espaço grande e fidedigno com um perímetro amplo. Se o fizer, pode criar uma falsa sensação de segurança e prejudicar uma estratégia de defesa em profundidade holística. Se um atacante violar a segurança do perímetro, pode operar facilmente numa intranet privada e fidedigna. Considere formas de restringir o espaço fidedigno para que contenha apenas o que precisa para funcionar e proteger-se, e evite depender apenas da segurança do perímetro. Ao compreender e seguir estes princípios, pode conceber o seu ambiente na nuvem para ajudar a proteger os seus sistemas críticos e reduzir o risco de contaminação por sistemas comprometidos.

Um ambiente de grande dimensão no âmbito dos sistemas fidedignos requer um aparelho de gestão de dimensão semelhante para manter a monitorização, a manutenção, a auditoria e o inventário contínuos destes sistemas. A complexidade da arquitetura do sistema, dos processos de gestão de alterações e das políticas de controlo de acesso pode criar riscos de segurança e de conformidade. A dificuldade em manter estes processos de monitorização pode levar a dificuldades no cumprimento dos requisitos da norma PCI DSS 10 e 11. É importante compreender estes riscos e implementar estratégias para limitar o âmbito do seu ambiente avaliado. Para mais informações, consulte a secção Apoie a conformidade contínua mais adiante neste documento.

Google Cloud serviços no âmbito da PCI DSS

Antes de começar a reduzir o âmbito do seu ambiente de PCI, compreenda que Google Cloud serviços estão no âmbito da norma PCI DSS. Estes serviços fornecem uma infraestrutura na qual pode criar o seu próprio serviço ou aplicação que armazena, processa ou transmite dados de titulares de cartões.

Estratégias para reduzir o âmbito

Esta secção aborda as seguintes estratégias para reduzir o âmbito da avaliação: controlos da hierarquia de recursos, segmentação dos VPC Service Controls e tokenização. Em vez de escolher uma abordagem, considere usar todas estas estratégias para maximizar a potencial redução do âmbito.

Não existe uma solução universal para o âmbito da PCI. Pode ter uma segmentação existente implementada numa rede no local ou uma solução de processamento de cartões que pode fazer com que o design da sua infraestrutura seja ligeiramente diferente do descrito aqui. Use estas estratégias como princípios que pode aplicar ao seu próprio ambiente.

Estabeleça controlos de hierarquia de recursos

OsGoogle Cloud recursos estão organizados hierarquicamente da seguinte forma:

• O recurso Organization é o nó de raiz na Google Cloud hierarquia de recursos. Os recursos da organização contêm recursos de pastas e projetos. As políticas de controlo de acesso da Identity and Access Management (IAM) aplicadas ao recurso da organização aplicam-se em toda a hierarquia a todos os recursos da organização.
• As pastas podem conter projetos e outras pastas, e controlar o acesso aos respetivos recursos através de autorizações do IAM ao nível da pasta. As pastas são usadas com frequência para agrupar projetos semelhantes.
• Os projetos são um limite de confiança para todos os seus recursos e um ponto de aplicação do IAM.

Para ajudar a reduzir o âmbito da avaliação, siga as práticas recomendadas da Google para definir a hierarquia de recursos. A imagem seguinte mostra um exemplo de hierarquia de recursos para conformidade com a PCI:

Figura 4. Um exemplo de hierarquia de recursos para conformidade com a PCI.

Na figura 4, todos os projetos que estão no âmbito da PCI estão agrupados numa única pasta para isolar ao nível da pasta. A pasta no âmbito da PCI contém o CDE e outro projeto que contém serviços partilhados. Quando implementa uma hierarquia de recursos semelhante, a pasta no âmbito da PCI forma uma raiz lógica do âmbito de conformidade com a PCI. Ao garantir que apenas os utilizadores designados têm acesso a esta pasta e aos respetivos projetos, pode excluir outras pastas, projetos e recursos no âmbito da sua hierarquia da sua avaliação.

Quando concede aos utilizadores acesso apenas às pastas e aos projetos de que precisam, conforme necessário, garante que apenas os utilizadores designados têm acesso aos componentes no âmbito. Isto suporta os requisitos 7.2 e 7.3 da PCI DSS (PDF), entre outros. Para se certificar de que as autorizações para a organização principal e as pastas estão definidas corretamente, compreenda as implicações da herança de políticas. Para suportar o requisito 8.4.1 da PCI DSS, certifique-se de que aplica a autenticação multifator (MFA) aos utilizadores designados e consulte o suplemento da PCI DSS sobre orientações para a autenticação multifator (PDF). Para aplicar a conformidade na hierarquia de recursos, certifique-se de que compreende como definir restrições da política da organização. Estas restrições suportam a conformidade contínua e podem ajudar a proteger os seus ambientes fidedignos contra a escalada de privilégios.

Tal como acontece com toda a conformidade com a PCI, é necessário um registo e uma monitorização adequados do seu ambiente e dos respetivos componentes no âmbito para estabelecer um limite de âmbito claro. A hierarquia de recursos está inextricavelmente ligada à gestão de identidades e acessos, e o registo, a auditoria e a monitorização eficazes das ações dos utilizadores são necessários para aplicar e manter a separação.

Implemente a segmentação de rede

A segmentação de rede é um padrão de arquitetura importante para ajudar a proteger o seu CDE e os sistemas ligados, conforme descrito no guia suplementar do PCI SSC sobre a segmentação de rede (PDF). Quando implementada corretamente, a segmentação de rede restringe o âmbito da sua avaliação removendo rotas de rede que os sistemas não fidedignos podem usar para aceder ao seu AAD ou aos respetivos componentes ligados. Defina apenas as rotas necessárias para permitir a comunicação entre componentes fidedignos. Quando os sistemas não fidedignos não têm uma rota através da qual enviar ou receber pacotes de sistemas fidedignos, os sistemas não fidedignos estão fora do âmbito e não podem afetar a segurança dos seus componentes no âmbito.

Para implementar a segmentação de rede, coloque o seu CDE numa nuvem virtual privada (VPC) dedicada com os VPC Service Controls ativados. Crie esta VPC no modo personalizado para garantir que não são criadas sub-redes nem rotas estranhas que possam permitir o acesso predefinido a redes fidedignas. Implemente restrições de políticas de organização para garantir que esta VPC não pode ser partilhada com outros projetos e só pode ser trocada com outras redes fidedignas.

O diagrama seguinte mostra como a sua estratégia de segmentação da rede se relaciona estreitamente com a hierarquia de recursos. Este diagrama pressupõe uma hierarquia de recursos com uma única pasta para o seu ambiente de PCI no âmbito e dois projetos nessa pasta para o CDE e os serviços partilhados.

Figura 5. Hierarquia de recursos que usa a segmentação de rede para conformidade com a PCI.

Na figura 5, o projeto de serviços partilhados não faz parte do CDE, mas é um sistema ligado a e, por isso, está no âmbito da PCI. O acesso ao CDE está restrito ao nível da rede pelo equilibrador de carga e pelas regras de firewall ou políticas de firewall para proteger estas redes e cumprir os requisitos 1.2 e 1.3 da PCI DSS. O sistema de tokenização e o sistema de pagamento são colocados em sub-redes separadas e a respetiva comunicação é regida por regras de firewall entre cada sub-rede para permitir apenas as comunicações necessárias. As funções de registo, monitorização e alerta necessárias que satisfazem os requisitos 10.2, 10.4 e 10.5 da PCI DSS estão num projeto separado. Os serviços partilhados e o AFE estão dentro de um perímetro de segurança do VPC Service Controls para salvaguardar contra a configuração incorreta acidental ou a violação dos controlos de acesso do IAM.

Se a sua implementação estiver no Google Kubernetes Engine (GKE), seguem-se mais formas de segmentar o seu AAE e proteger os dados dos titulares de cartões de sistemas não fidedignos:

• Os namespaces oferecem uma camada adicional de isolamento do controlo de acesso através da qual os utilizadores podem receber acesso apenas a determinados pods, serviços e implementações no seu cluster do Kubernetes. Isto é útil para conceder acesso mais detalhado a utilizadores designados.
• As políticas de rede podem isolar pods e serviços uns dos outros para restringir os fluxos de dados e podem fornecer uma camada adicional de segmentação de rede no cluster.
• O PodSecurity é um controlador de admissão do Kubernetes que lhe permite aplicar normas de segurança de pods a pods em execução no seu cluster do GKE.

Cada uma destas camadas forma uma parte importante da sua postura de segurança em profundidade e ajuda a restringir o seu âmbito, isolando e protegendo ainda mais os seus componentes fidedignos do ambiente circundante. Se estiver a implementar toda ou parte da sua CDE com o Kubernetes, saiba mais detalhes sobre como executar o seu ambiente em conformidade com a PCI no GKE.

Implemente a conversão em tokens

A tokenização é o processo de ocultação irreversível de um número de conta principal (PAN). Não é possível resgatar um PAN tokenizado, ou token, por um PAN através de meios matemáticos. O PCI SSC oferece orientações sobre o impacto do âmbito da tokenização no capítulo 3 do suplemento de diretrizes de tokenização (PDF). O âmbito da PCI DSS é fortemente influenciado pelo conjunto de componentes que armazenam e transmitem dados do titular do cartão. Quando implementada corretamente, a tokenização pode ajudar a reduzir o âmbito da sua avaliação, minimizando a ocorrência e a transmissão de números de conta principais.

A tokenização também é uma forma de segmentação por fluxo de dados, porque separa os sistemas que armazenam e transmitem dados do titular do cartão daqueles que podem realizar operações usando apenas tokens. Por exemplo, os sistemas que analisam a atividade dos consumidores para detetar fraudes podem não precisar de PANs, mas podem realizar estas análises através de dados tokenizados. A tokenização também adiciona uma camada de separação entre os sistemas que armazenam e transmitem os NPAs e a sua aplicação Web de comércio eletrónico. Quando a sua aplicação Web interage apenas com sistemas que usam tokens, a aplicação Web pode ser potencialmente removida do conjunto de sistemas ligados, reduzindo assim o âmbito.

O diagrama seguinte mostra como os dados de CHD, um PAN e dados tokenizados são processados num sistema de tokenização típico:

Figura 6. Uma arquitetura típica para um sistema de tokenização.

Na figura 6, é recebido um PAN e outros dados do titular do cartão do utilizador e, em seguida, os dados são enviados imediatamente para o serviço de tokenização. O serviço de conversão em tokens encripta o PAN, gera um token e, em seguida, armazena ambos num cofre de tokens seguro. Apenas os serviços designados, como o serviço de liquidação, podem aceder ao cofre na rede e estão autorizados a resgatar um PAN através de um token gerado. O serviço de liquidação usa apenas o PAN para o enviar ao processador de pagamentos. Nem o PAN nem quaisquer outros dados do titular do cartão ocorrem fora deste fluxo de dados rigorosamente controlado. Como parte de uma estratégia de defesa em profundidade, a arquitetura também usa a proteção de dados confidenciais como outra camada de defesa contra a fuga não intencional de PANs ou outros dados do titular do cartão.

Na figura 6, o sistema de tokenização usa o Hashicorp Vault, um repositório de segredos rigorosamente protegido, para gerir os mapeamentos de PAN para tokens. Apenas os utilizadores e os serviços autorizados podem resgatar um PAN a partir de um token através de um processo de pesquisa. Os componentes autorizados a aceder ao cofre de tokens podem receber acesso com restrições de tempo para que o componente só possa resgatar um PAN durante o período específico de que necessita para realizar a sua função. Outras bases de dados também podem ser adequadas, consoante os requisitos da sua empresa. Para mais informações sobre a implementação segura da tokenização no seu ambiente, consulte o artigo Tokenização de dados confidenciais de titulares de cartões para a PCI DSS.

Exemplo de arquitetura

O diagrama seguinte ilustra uma arquitetura de exemplo para o processamento de transações tokenizadas através do Pub/Sub e do Dataflow, e o armazenamento de registos de transações tokenizadas no Spanner.

Figura 7. Uma arquitetura de exemplo para o tratamento de transações tokenizadas.

Na figura 7, o projeto de processamento de transações é um sistema ligado a e está no âmbito da PCI. Não é impactante para a segurança, porque a comprometimento de qualquer componente no projeto de processamento de transações não pode dar a um atacante acesso a dados de titulares de cartões. O projeto da app Web está fora do âmbito, porque não se liga ao CDE e interage apenas com dados limpos.

Os dados tokenizados são enviados do CDE para o Pub/Sub. Antes de os dados tokenizados serem publicados para outros subscritores, a proteção de dados confidenciais verifica se não contêm DPC. Os dados tokenizados são processados pelo Dataflow e armazenados na base de dados de transações do Spanner. As transações podem ser associadas a utilizadores específicos através de tokens sem aceder a PANs. A base de dados de transações do Spanner também pode ser usada para relatórios e análises através de ferramentas de Business Intelligence (BI), como o Looker.

Apoio técnico para conformidade contínua

A segurança e a conformidade são mais do que uma arquitetura correta e uma boa engenharia. Uma arquitetura correta pode mostrar que o seu ambiente foi concebido de forma segura em teoria. Também precisa de processos de auditoria, registo, monitorização e correção eficazes para ajudar a garantir que o seu ambiente permanece seguro na prática.

Para suportar a conformidade com cada uma das 12 categorias de requisitos da PCI DSS, tem de monitorizar continuamente a implementação desse requisito. Tem de provar a si mesmo e ao seu avaliador que qualquer componente no âmbito vai permanecer seguro no futuro, muito depois de a avaliação da PCI DSS estar concluída. A supervisão adequada, juntamente com uma ação de correção rápida, denomina-se conformidade contínua. A conformidade contínua é um requisito da norma PCI DSS e, quando implementada corretamente, pode ajudar a maximizar o efeito das outras estratégias de redução do âmbito.

Google Cloud permite-lhe registar tudo o que está a acontecer na sua rede através do registo de regras de firewall, registos de fluxo de VPC, registos do VPC Service Controls> e registos do Cloud Load Balancing. Pode monitorizar a atividade dos seus sistemas e utilizadores através dos registos de auditoria do Google Cloud. A monitorização regular destes registos ajuda a agir em conformidade com o requisito 10.4 da PCI DSS e permite-lhe responder e corrigir rapidamente potenciais ameaças de segurança. Para mais informações, consulte o suplemento da PCI DSS sobre a monitorização eficaz dos registos diários (PDF).

O Security Command Center permite-lhe compreender a sua superfície de ataque de segurança e dados, fornecendo inventário, deteção, pesquisa e gestão de recursos. O Security Command Center pode analisar os resultados da análise da Proteção de dados confidenciais para ajudar a identificar dados de titulares de cartões roubados e ajudar a validar que o seu sistema de tokenização não está a ser usado indevidamente para resgatar PANs de forma maliciosa. Com a deteção de ameaças de eventos, o Security Command Center pode ajudar a detetar proativamente ameaças e atividade invulgar na sua rede e nas suas VMs, o que pode indicar que um atacante pode estar a analisar o seu sistema para identificar as respetivas capacidades defensivas. O Security Command Center também lhe permite criar origens de segurança personalizadas específicas do seu ambiente.

O Google Cloud Armor pode oferecer proteção adicional para as suas aplicações Web Google Cloud públicas e ajudar a agir em conformidade com o requisito 6.4 da norma PCI DSS. O Cloud Armor avalia os pedidos recebidos para uma variedade de ataques Web comuns e pode ajudar a evitar revisões de código manuais que exigem muito trabalho, especificadas no requisito 6.4. A existência de uma FAP ajuda a manter a conformidade contínua, ao mesmo tempo que reduz os custos e os riscos de conformidade contínuos.

O que se segue?

• Reveja as práticas recomendadas para gerir as obrigações de conformidade.
• Leia o artigo sobre a conformidade com a norma de segurança de dados da PCI no Google Cloud.
• Orientações do Conselho PCI para o âmbito de aplicação da PCI DSS e a segmentação de rede (PDF).
• Experimente o projeto do PCI no GKE.
• Proteja as suas cargas de trabalho do Kubernetes para a PCI DSS.
• Converter em tokens dados confidenciais do titular do cartão para a PCI DSS.
• Implemente o projeto do Terraform PCI Starter.
• Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.