Como limitar o escopo de conformidade para ambientes PCI no Google Cloud

Last reviewed 2023-11-29 UTC

Neste documento, descrevemos as práticas recomendadas para arquitetar seu ambiente de nuvem para conformidade com o Conselho de padrões de segurança do Setor de Cartões de Pagamento (PCI). Essas práticas recomendadas são úteis para organizações que estão migrando ou projetando sistemas na nuvem sujeitas aos requisitos de conformidade com o PCI. Este documento se refere aos requisitos do PCI DSS 4.0, quando aplicável.

Noções básicas sobre o escopo da avaliação do PCI DSS

Caso sua organização se envolva em comércio na Internet, é preciso oferecer suporte e manter a conformidade com o PCI. A maneira como você projeta e gerencia seu ambiente de nuvem afeta o escopo dos sistemas na avaliação do PCI Data Security Standard (DSS). O escopo tem implicações importantes para a segurança dos recursos de TI e a capacidade de dar suporte e manter a conformidade com o PCI. Para garantir que seu ambiente PCI tenha o escopo correto, é preciso entender como seus processos de negócios e decisões de design afetam o escopo.

O que é escopo?

Todos os sistemas que armazenam, processam ou transmitem dados do titular do cartão (CHD, na sigla em inglês) estão no escopo da avaliação do PCI DSS. A segurança é importante para todo o ambiente de nuvem, mas o comprometimento de sistemas em escopo pode causar uma violação de dados e exposição do CHD.

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

Na figura 1, o ambiente de dados do titular do cartão (CDE, na sigla em inglês), os sistemas conectados e os sistemas de impacto de segurança estão dentro do limite do escopo da avaliação, enquanto os sistemas não confiáveis e fora do escopo estão fora do limite do escopo da avaliação.

De acordo com o PCI DSS, os sistemas em escopo são confiáveis. Os sistemas em escopo incluem o CDE e qualquer sistema que esteja conectado ou que possa afetar a segurança do seu CDE.

Um sistema está conectado se está na mesma rede, compartilha bancos de dados ou armazenamento de arquivos ou tem acesso ou conectividade a qualquer sistema ou processo que reside no CDE, mas não tem acesso direto ao CHD.

Um sistema está afetando a segurança quando, se comprometido, permite que um invasor tenha acesso ao CDE. Todos os sistemas conectados e impactantes de segurança estão sempre no escopo.

Sistemas fora do escopo são não confiáveis por definição no PCI DSS e têm valor zero para um invasor que queira ter acesso a dados de autenticação confidenciais (SAD, na sigla em inglês) ou CHD. Um sistema está fora do escopo se não puder afetar a segurança de um sistema em escopo, mesmo que ele esteja comprometido. Embora os sistemas fora do escopo não sejam avaliados diretamente, o avaliador de segurança qualificado do PCI (QSA, na sigla em inglês) verifica se seu escopo é preciso e protege o CHD de acordo com o PCI DSS. Portanto, é importante que seus limites de escopo estejam fortemente protegidos, sejam continuamente monitorados de maneira completa e claramente documentados.

Conexões no contexto de PCI

Vários requisitos do PCI DSS fazem referência a conexões, mas ele não define conexões explicitamente. É possível interpretar o significado de conexões nesse contexto. Para isso, é preciso entender a árvore de decisão do escopo na Orientação do PCI SSC para definir o escopo de segmentação e de rede do PCI DSS (PDF).

Para fins de avaliação do escopo do PCI, uma conexão é definida pelo seguinte:

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

Ao documentar seu ambiente, é melhor indicar claramente qual parte está autorizada a iniciar uma conexão. Um firewall configurado para permitir tráfego apenas em uma direção pode impor uma conexão unidirecional. Por exemplo, um aplicativo de processamento de pagamentos no do escopo pode fazer consultas em um servidor de banco de dados fora do escopo, sem este entrar no escopo se todas as condições abaixo forem verdadeiras:

• O banco de dados de conexão e fora do escopo não armazena, processa ou transmite CHD ou SAD.
• O banco de dados está em uma rede separada ou é segmentado do DE.
• O banco de dados não pode iniciar nenhuma chamada para o CDE direta ou indiretamente.
• O banco de dados não fornece serviços de segurança para o CDE.
• O banco de dados não afeta a configuração nem a segurança do CDE.
• O banco de dados é compatível com os requisitos do PCI DSS.

O diagrama a seguir mostra os fatores que determinam o escopo do sistema:

Figura 2. Fluxograma para determinar o escopo do sistema.

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

• Componentes do sistema que estão no escopo do PCI DSS:

  • Sistemas que estão no CDE, para os quais um dos seguintes itens é verdadeiro:
    • 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, como sistemas que armazenam, processam ou transmitem CHD.
  • Sistemas conectados ou que afetam a segurança para os quais um dos seguintes itens é verdadeiro:
    • Um componente do sistema se conecta diretamente ao CDE.
    • Um componente do sistema afeta a configuração ou a segurança do CDE.
    • Um componente do sistema segmenta sistemas CDE de sistemas e redes fora do escopo.
    • Um componente do sistema se conecta indiretamente ao CDE.
    • Um componente do sistema fornece serviços de segurança para o CDE.
    • Um componente do sistema é compatível com os requisitos do PCI DSS.

• Os componentes do sistema podem ser considerados não confiáveis e fora do escopo do PCI DSS quando todas as afirmações a seguir são verdadeiras:

  • Um componente do sistema não armazena, processa nem transmite CHD ou SAD.
  • Um componente do sistema não é o mesmo segmento de rede, por exemplo, na mesma sub-rede ou VLAN, como sistemas que armazenam, processam ou transmitem CHD ou SAD.
  • Um componente do sistema não pode se conectar a nenhum sistema no CDE.
  • Um componente do sistema não atende a nenhum critério para sistemas conectados ou que afetam a segurança.

  Sistemas fora do escopo podem incluir sistemas que se conectam a um componente de sistema conectado ou do sistema que afeta a segurança, em que os controles estão em vigor para impedir que o sistema fora do escopo tenha acesso ao CDE usando o componente do sistema no escopo.

Em termos práticos, a definição do escopo do sistema PCI DSS pode significar que o armazenamento de sessão do aplicativo da Web e o banco de dados de comércio eletrônico podem se qualificar como fora do escopo, se a segmentação for implementada e documentada corretamente. O diagrama a seguir mostra como as conexões de leitura e gravação funcionam entre sistemas no e fora do escopo:

Figura 3. Aplicativos em escopo capazes de chamar serviços e aplicativos fora do escopo.

A Figura 3 mostra as seguintes conexões:

• Somente leitura:
  • Um aplicativo de processamento de pagamentos no escopo lê um ID do carrinho de um banco de dados de carrinho fora do escopo e lê os dados de um DNS e NTP.
• Somente gravação:
  • Um aplicativo de processamento de pagamentos no escopo é gravado em um banco de dados principal do aplicativo fora do escopo e no Cloud Logging.
  • O principal aplicativo da Web fora do escopo grava dados em um serviço de geração de registros. Esses dados não incluem CHD ou SAD.
• Leitura e gravação:
  • Um usuário na Web pública lê e grava metadados de solicitação da seguinte maneira:
    • O usuário lê e grava em um aplicativo de processamento de pagamentos no escopo. Esses metadados de solicitação são o código do carrinho e a chave de autenticação do carrinho que contêm CHD e SAD.
    • O usuário lê e grava no aplicativo principal da Web fora do escopo. Esses metadados de solicitação são um código de sessão que não contém CHD ou SAD.
  • O aplicativo principal da Web fora do escopo lê e grava dados em um banco de dados de carrinho fora do escopo, no armazenamento de sessões e no banco de dados principal do aplicativo. Esses dados não incluem CHD ou SAD.
  • Um aplicativo de processamento de pagamentos no escopo lê e grava dados em um serviço de tokenização de cartão em escopo e em um processador de cartão de crédito na Web pública. Esses dados incluem CHD e SAD.

A arquitetura na figura 3 descreve dois aplicativos da Web distintos: o principal (aplicativo principal), que está fora do escopo do PCI, e o aplicativo de processamento de pagamentos (aplicativo de finalização da compra), que está no escopo. Nessa arquitetura, só é possível iniciar uma conexão entre duas entidades nas direções descritas pela lista anterior. As conexões entre entidades podem ser somente leitura, leitura e gravação ou apenas gravação do ponto de vista do autor da chamada. Qualquer caminho ou direção de solicitação que não esteja explicitamente descrito é bloqueado pela segmentação. Por exemplo, o aplicativo de processamento de pagamentos pode ler no banco de dados do carrinho e gravar no serviço de geração de registros, o que envolve o início de uma conexão com essas entidades.

Os sistemas em escopo geralmente chamam sistemas e serviços fora do escopo. Essas conexões permanecem seguras porque a segmentação impede que qualquer autor remoto da chamada (que não seja um titular do cartão) inicie uma conexão diretamente ou indiretamente com o CDE. A Figura 3 mostra que o único caminho de entrada para o aplicativo de finalização da compra é do usuário.

Na figura 3, nenhum serviço ou aplicativo fora do escopo fornece dados de configuração ou de segurança ao aplicativo de processamento de pagamentos. Os dados fluem pela arquitetura da seguinte maneira:

1. O aplicativo principal encaminha o usuário para o aplicativo de finalização de compra e usa um HTTP POST para transmitir o CartID e um validador chamado CartAuthKey. O CartAuthKey é um hash do CartID e um secret pré-compartilhado conhecido apenas pelos aplicativos principal e de finalização da compra.
2. O aplicativo de finalização de compra valida o usuário gerando um hash no CartID junto com o secret e comparando esse valor com o CartAuthKey.
3. Depois que os dados do usuário são autenticados, o CartID é usado para ler o conteúdo do carrinho no banco de dados do carrinho. Todos os dados do titular do cartão são enviados do usuário diretamente ao aplicativo de finalização de compra.
4. Se os perfis para pagamentos forem usados, os dados do titular do cartão serão armazenados no serviço de tokenização.
5. Depois que o pagamento é processado, o resultado é inserido no banco de dados do aplicativo principal com uma conta de serviço de banco de dados somente de gravação.

Considerações sobre escopo

Na Orientação para escopo e segmentação de rede do PCI DSS, o PCI Security Standards Council (SSC) recomenda que você considere que tudo está no escopo até ser verificado de outra forma. Essa recomendação do SSC não significa que você deve tornar seu escopo o mais amplo possível, significa que o QSA avalia todos os sistemas como confiáveis, a menos que você possa mostrar que um sistema não tem conectividade ou impacto de segurança no seu CDE. Para atender aos requisitos de conformidade normativa e manter seus recursos de TI seguros, você precisa definir um escopo do seu ambiente de acordo com o princípio do menor privilégio, confiando no mínimo de sistemas possível.

Antes da avaliação, avalie seu ambiente para entender e documentar o limite entre seus sistemas no e fora do escopo. A primeira tarefa do QSA é confirmar que o escopo documentado encapsula o CDE e os sistemas conectados. Como parte da avaliação geral, o QSA verifica se os sistemas fora do escopo não podem afetar negativamente os sistemas em escopo.

Esteja ciente de todas as circunstâncias especiais específicas do seu ambiente, como as seguintes:

• Se você coletar dados do titular do cartão por telefone ou por meio de um sistema VOIP, considere os outros problemas de escopo descritos em Como proteger dados de cartões de pagamento por telefone (PDF).
• Se seu provedor de serviços exigir acesso ao CDE (PDF) para operar um sistema de ponto de venda, o sistema usado pelo provedor de serviços poderá ser considerado como um sistema conectado. Isso pode exigir outras considerações de escopo e investigação.

As práticas recomendadas de segurança do Google podem ajudar você a estabelecer e demonstrar um limite claro e defendível entre sistemas em escopo e não confiáveis que ajudarão na sua avaliação. Ao gerenciar o acesso e a segurança praticando o princípio de privilégio mínimo, você ajuda a minimizar o número de pontos de exposição de dados do titular do cartão, minimizar a superfície de ataque do CDE. e, consequentemente, reduzir seu escopo. Ao reduzir a abrangência de sistemas em escopo, você ajuda a reduzir a complexidade do sistema e simplificar a avaliação do PCI DSS.

Riscos de escopo incorreto

Um escopo excessivamente amplo pode levar a avaliações caras e a riscos de conformidade. Para ajudar a manter um escopo restrito, confie no menor número possível de sistemas e conceda acesso a apenas alguns usuários designados. Com a avaliação de investigação e autoavaliação é possível identificar os sistemas que não devem estar no escopo do PCI DSS, verificar se eles atendem às diretrizes de sistemas fora do escopo e reduzir esse escopo. Esse processo de eliminação é a maneira mais segura de descobrir quais sistemas não são confiáveis e ajudar a garantir que eles não afetem os sistemas no escopo.

Se você precisar de uma grande extensão de infraestrutura para atender aos requisitos do PCI DSS, poderá fazer com que sistemas externos sejam incluídos no escopo da avaliação. Quando você inclui sistemas externos no seu escopo, isso representa riscos à sua capacidade de manter a conformidade. Isso também pode prejudicar a postura de segurança geral, interferindo a superfície de ataque do ambiente confiável em escopo.

Um princípio fundamental da segurança de rede e do PCI DSS é assumir que parte ou toda sua rede já tenha sido comprometida. Esse princípio faz parte do modelo de segurança de confiança zero do Google, que rejeita a segurança somente de perímetro em favor de um modelo em que cada sistema é responsável por se proteger. O modelo de segurança do Google está de acordo com o PCI DSS, que recomenda que o CDE e os sistemas conectados sejam implantados em um espaço pequeno e confiável segmentado do ambiente de TI mais amplo e não interferindo nele.

No ambiente PCI no escopo, não coloque o CDE em um espaço grande e confiável com um perímetro amplo. Isso pode criar uma falsa sensação de segurança e prejudicar uma estratégia holística de segurança avançada. Se um invasor violar a segurança do perímetro, ele poderá operar com facilidade em uma intranet confiável e privada. Pense em maneiras de reduzir o espaço confiável que contém apenas o que é necessário para operar e se proteger e evitar confiar apenas na segurança do perímetro. Ao compreender e seguir esses princípios, você pode projetar seu ambiente de nuvem para ajudar a proteger seus sistemas essenciais e reduzir o risco de contaminação de sistemas comprometidos.

Um ambiente grande e no escopo de sistemas confiáveis requer um aparelho de gerenciamento que seja igualmente grande para manter o monitoramento, a manutenção, a auditoria e o inventário contínuos desses sistemas. A complexidade da arquitetura do sistema, os processos de gestão da mudança e as políticas de controle de acesso podem criar riscos de segurança e conformidade. A dificuldade em manter esses processos de monitoramento pode levar a dificuldades no cumprimento dos requisitos 10 e 11 do PCI DSS. É importante entender esses riscos e implementar estratégias para limitar o escopo do ambiente avaliado. Para mais informações, consulte Compatibilidade com conformidade contínua posteriormente neste documento.

Serviços do Google Cloud no escopo do PCI DSS

Antes de começar a reduzir o escopo do seu ambiente PCI, entenda quais serviços do Google Cloud estão no escopo do PCI DSS. Esses serviços fornecem infraestrutura para criar um serviço ou aplicativo que armazene, processe ou transmita dados do titular do cartão.

Estratégias para reduzir o escopo

Nesta seção, abordamos as seguintes estratégias para reduzir o escopo da avaliação: controles da hierarquia de recursos, segmentação do VPC Service Controls e tokenização. Em vez de escolher uma abordagem, considere implementar todas essas estratégias para maximizar a possível redução do escopo.

Não há uma solução universal para o escopo de PCI. Você pode ter a segmentação em vigor em uma rede local ou uma solução de processamento de cartões que possa fazer com que o design da sua infraestrutura seja um pouco diferente do descrito aqui. Use essas estratégias como princípios que podem ser aplicados ao seu próprio ambiente.

Estabelecer controles de hierarquia de recursos

Os recursos do Google Cloud são organizados hierarquicamente da seguinte maneira:

• O recurso "Organização" é o nó raiz na hierarquia de recursos do Google Cloud. Os recursos da organização contêm recursos de pasta e projeto. As políticas de controle de acesso do gerenciamento de identidade e acesso (IAM, na sigla em inglês) aplicadas aos recursos da Organização são válidas para toda a hierarquia em todos os recursos da organização.
• As pastas podem conter projetos e outras pastas e controlar o acesso aos recursos usando permissões de IAM no nível da pasta. As pastas são comumente usadas para agrupar projetos semelhantes.
• Os projetos são um limite de confiança para todos os seus recursos e são um ponto de aplicação do IAM.

Para reduzir o escopo da avaliação, siga as práticas recomendadas do Google para definir a hierarquia de recursos. Na imagem a seguir, mostramos um exemplo de hierarquia de recursos para conformidade com o PCI:

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

Na figura 4, todos os projetos que estão no escopo do PCI são agrupados em uma única pasta para isolar no nível da pasta. A pasta com escopo de PCI contém o CDE e outro projeto que contém serviços compartilhados. Ao implementar uma hierarquia de recursos semelhante, a pasta com escopo do PCI forma uma raiz lógica do escopo de conformidade com o PCI. Ao garantir que somente usuários designados tenham acesso a essa pasta e aos respectivos projetos, é possível excluir do escopo da avaliação as outras pastas, projetos e recursos da hierarquia.

Ao conceder aos usuários acesso apenas às pastas e aos projetos de que precisam conforme necessário, você garante que somente usuários designados tenham acesso aos seus componentes no escopo. Isso é compatível com os requisitos 7.2 e 7.3 do PCI DSS (PDF), entre outros. Para garantir que as permissões na organização pai e nas pastas estejam definidas corretamente, entenda as implicações da herança de política. Para ser compatível com o requisito 8.4.1 do PCI DSS, certifique-se de aplicar a autenticação multifator (MFA) para usuários designados e consulte o Suplemento do PCI DSS sobre orientação para autenticação multifator (PDF). Para garantir a conformidade na hierarquia de recursos, entenda como definir as restrições de política da organização. Essas restrições são compatíveis com a conformidade contínua e podem ajudar a proteger seus ambientes confiáveis contra o escalonamento de privilégios.

Como acontece com toda a conformidade com o PCI, a geração de registros e o monitoramento adequados do seu ambiente e os componentes com escopo são necessários para estabelecer um limite de escopo claro. A hierarquia de recursos está muito vinculada o gerenciamento de identidade e acesso. Além disso, é necessário gerar registros, auditorias e monitoramento das ações do usuário para impor e manter a separação.

Implementar a segmentação de rede

A segmentação de rede é um padrão de arquitetura importante para ajudar a proteger o CDE e os sistemas conectados, conforme descrito pelo guia complementar de segmentação de rede (PDF) do PCI SSC. Quando implementada corretamente, a segmentação de rede restringe o escopo da avaliação removendo rotas de rede que podem ser usadas por sistemas não confiáveis para acessar o CDE ou seus componentes conectados. Defina somente as rotas necessárias para permitir a comunicação entre os componentes confiáveis. Quando os sistemas não confiáveis não têm uma rota pela qual enviar ou receber pacotes de sistemas confiáveis, os sistemas não confiáveis ficam fora do escopo e não podem afetar a segurança dos seus componentes no escopo.

Para implementar a segmentação de rede, coloque o CDE em uma nuvem privada virtual (VPC, na sigla em inglês) dedicada com o VPC Service Controls ativado. Crie essa VPC no modo personalizado para garantir que não sejam criadas sub-redes ou rotas desconhecidas que possam ativar o acesso padrão a redes confiáveis. Implemente as restrições da política da organização para garantir que essa VPC não possa ser compartilhada com outros projetos e só possa ser conectada com outras redes confiáveis.

O diagrama a seguir mostra como sua estratégia de segmentação de rede está fortemente relacionada à sua hierarquia de recursos. Neste diagrama, consideramos uma hierarquia de recursos com uma única pasta para seu ambiente PCI no escopo e dois projetos nessa pasta para o CDE e serviços compartilhados.

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

Na figura 5, o projeto de serviços compartilhados não faz parte do CDE, mas é um sistema conectado e, portanto, está no escopo do PCI. O acesso ao CDE é restrito no nível da rede pelo balanceador de carga e regras de firewall oupolíticas de firewall para proteger essas redes e atender aos Requisitos do PCI DSS 1.2 e 1.3. O sistema de tokenização e o sistema de pagamento são colocados em sub-redes separadas e a comunicação delas é regida pelas regras de firewall entre cada sub-rede para permitir apenas as comunicações necessárias. As funções necessárias de geração de registros, monitoramento e alerta que atendem aos requisitos 10.2, 10.4 e 10.5 do PCI DSS estão em um projeto separado. Os serviços compartilhados e o CDE estão dentro de um perímetro de segurança do VPC Service Controls para se proteger contra erros acidentais de configuração ou comprometimento dos controles de acesso do IAM.

Se a implantação estiver no Google Kubernetes Engine (GKE), veja mais maneiras de segmentar o CDE e proteger os dados do titular do cartão de sistemas não confiáveis:

• Namespaces oferecem uma camada extra de isolamento de controle de acesso em que os usuários podem receber acesso apenas a determinados pods, serviços e implantações no seu cluster do Kubernetes. Isso é útil para fornecer acesso mais refinado aos usuários 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.
• PodSecurity é um controlador de admissão do Kubernetes que permite aplicar os padrões de segurança de pods aos pods em execução no cluster do GKE.

Cada uma dessas camadas representa uma parte importante da postura de segurança de defesa completa e ajuda a restringir o escopo isolando e protegendo ainda mais seus componentes confiáveis do ambiente circundante. Se você estiver implantando todo ou parte do CDE com o Kubernetes, saiba mais detalhes sobre como executar o ambiente em conformidade com o PCI no GKE.

Implementar a tokenização

A tokenização é o processo para remover permanentemente um número de conta principal (PAN, na sigla em inglês). Um PAN tokenizado, ou token, não pode ser resgatado para um PAN usando meios matemáticos. O PCI SSC oferece orientações sobre o impacto do escopo da tokenização no capítulo 3 do suplemento de diretrizes de tokenização (PDF). O escopo do 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 escopo da avaliação minimizando a ocorrência e a transmissão de números da conta principal.

A tokenização também é uma forma de segmentação por fluxo de dados, porque ela separa os sistemas que armazenam e transmitem dados do titular daqueles que podem executar operações usando apenas tokens. Por exemplo, sistemas que analisam a atividade do consumidor quanto a fraudes podem não precisar de PANs, mas podem executar essas análises usando dados tokenizados. A tokenização também adiciona uma camada de separação entre os sistemas que armazenam e transmitem PANs e o aplicativo da Web de comércio eletrônico. Quando seu aplicativo da Web interage apenas com sistemas que usam tokens, ele pode ser removido do conjunto de sistemas conectados, o que reduz o escopo.

O diagrama a seguir mostra como o CHD, um PAN e dados tokenizados são processados em um sistema de tokenização típico:

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

Na figura 6, um PAN e outros dados do titular do cartão são recebidos do usuário e, em seguida, são enviados imediatamente ao serviço de tokenização. O serviço de tokenização criptografa o PAN, gera um token e os armazena em um cofre de token. Somente serviços designados, como o de liquidação, podem acessar o cofre na rede e estão autorizados a resgatar um PAN usando um token gerado. O serviço de liquidação só usa o PAN para enviá-lo ao processador de pagamentos. Nem o PAN nem quaisquer outros dados do titular do cartão ocorrem fora desse fluxo de dados rigorosamente controlado. Como parte de uma estratégia de defesa profunda, a arquitetura também usa a Proteção de dados confidenciais como outra camada de defesa contra vazamento 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 armazenamento secreto altamente protegido, para gerenciar os mapeamentos PAN para token. Somente usuários e serviços autorizados podem resgatar um PAN de um token usando um processo de pesquisa. Os componentes autorizados a acessar o cofre de token podem receber acesso com restrição de tempo, para que o componente só possa resgatar um PAN durante a janela de tempo específica que ele precisa para realizar sua função. Outros armazenamentos de dados também podem ser apropriados, dependendo dos requisitos de negócios. Para mais informações sobre como implementar a tokenização com segurança no seu ambiente, consulte Como tokenizar dados confidenciais do titular do cartão do PCI DSS.

Exemplo de arquitetura

No diagrama a seguir, ilustramos um exemplo de arquitetura para processar transações tokenizadas usando o Pub/Sub e o Dataflow e armazenar registros de transações tokenizadas no Spanner.

Figura 7. Um exemplo de arquitetura de processamento de transações tokenizadas.

Na figura 7, o projeto de processamento de transações é um sistema conectado e está no escopo do PCI. Não há impacto de segurança, porque o comprometimento de qualquer componente no projeto de processamento de transações não pode fornecer a um invasor acesso ao CHD. O projeto webapp está fora do escopo, porque não se conecta ao CDE e interage apenas com dados limpos.

Os dados tokenizados são enviados do CDE para o Pub/Sub. Antes que os dados tokenizados sejam publicados para outros assinantes, a proteção de dados confidenciais verifica se não contém CHD. Os dados tokenizados são processados pelo Dataflow e armazenados no banco de dados de transações do Spanner. As transações podem ser associadas a usuários específicos por tokens sem acessar os PANs. O banco de dados de transações do Spanner também pode ser usado para gerar relatórios e fazer análises usando ferramentas de inteligência de negócios (BI, na sigla em inglês), como o Looker.

Acomodar a conformidade contínua

Segurança e conformidade são mais do que uma arquitetura correta e uma boa engenharia. Na teoria, uma arquitetura correta pode mostrar que o ambiente foi projetado com segurança. Mas, na prática, processos de auditoria, geração de registros, monitoramento e remediação eficientes também são necessários para ajudar a garantir que o ambiente permaneça seguro.

Para apoiar o cumprimento de cada uma das 12 categorias de requisitos do PCI DSS, é preciso monitorar a implementação desses requisitos continuamente. Você precisa comprovar a você e seu avaliador que qualquer componente em escopo permanecerá seguro no futuro, depois que a avaliação do PCI DSS for concluída. A supervisão adequada combinada com ação rápida de remediação é chamada de conformidade contínua. A conformidade contínua é um requisito do PCI DSS e, quando implementada corretamente, pode ajudar a maximizar o efeito das outras estratégias de redução de escopo.

O Google Cloud permite registrar tudo que está acontecendo na sua rede usando Geração de registros de firewall, Registros de fluxo de VPC, Registros do VPC Service Controls e Registros do Cloud Load Balancing. É possível monitorar a atividade dos seus sistemas e usuários usando o Cloud Audit Logs. O monitoramento regular desses registros ajuda a cumprir com o Requisito 10.4 do PCI DSS, além de permitir responder e corrigir rapidamente a possíveis ameaças de segurança. Para mais informações, consulte o suplemento do PCI DSS sobre monitoramento efetivo diário de registros (PDF).

O Security Command Center permite entender sua superfície de segurança e ataque de dados fornecendo inventário de recursos, descoberta, pesquisa e gerenciamento. O Security Command Center pode analisar os resultados da verificação da Proteção de dados confidenciais para identificar dados vazados do titular do cartão e verificar se o sistema de tokenização não está sendo usado indevidamente para resgatar PANs mal-intencionados. Usando a Detecção de ameaças de evento, o Security Command Center pode ajudar a detectar ameaças e atividades incomuns na rede e nas VMs, o que pode indicar que um invasor pode estar sondando seu sistema para identificar os recursos defensivos dele. O Security Command Center também permite criar origens de segurança personalizadas específicas para seu ambiente.

O Google Cloud Armor pode fornecer proteção adicional para seus aplicativos da Web públicos no Google Cloud e ajudar você a cumprir com o requisito 6.4 do PCI DSS. O Google Cloud Armor avalia as solicitações recebidas de uma variedade de ataques comuns da Web e pode evitar as revisões manuais e trabalhosas dos códigos especificadas no requisito 6.4. Ter um WAF em vigor ajuda a manter a conformidade contínua e reduzir os custos e riscos de conformidade.

A seguir

• Leia as práticas recomendadas para gerenciar obrigações de conformidade.
• Leia Conformidade com o padrão de segurança de dados do PCI no Google Cloud.
• Orientação do PCI SSC para definir o escopo de segmentação e de rede do PCI DSS do Conselho do PCI (PDF).
• Teste o blueprint do PCI no GKE.
• Proteja suas cargas de trabalho do Kubernetes para PCI DSS.
• Tokenização de dados confidenciais do titular do cartão do PCI DSS
• Implante o projeto do PCI Starter Terraform.
• Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.