Conformidade com o padrão de segurança de dados do PCI

Neste guia, ajudamos você a implementar o padrão de segurança de dados do setor de cartões de pagamento (PCI DSS, na sigla em inglês) para sua empresa no Google Cloud. O guia vai além das diretrizes de computação em nuvem do PCI SSC (PDF) para fornecer informações básicas sobre o padrão, explicar seu papel na conformidade baseada em nuvem e fornecer as diretrizes para projetar, implantar e configurar um aplicativo de processamento de pagamentos usando o PCI DSS. Neste tutorial, também discutimos métodos para monitorar, registrar e validar seu aplicativo.

O padrão de segurança de dados PCI, criado pelo PCI Security Standards Council, é um padrão de segurança de informações para empresas do setor de cartões de pagamento, de crédito, débito (links em inglês) e afins. Esse conselho inclui todas as principais empresas de cartões de pagamento. As empresas que usam Visa, MasterCard, Discover, American Express ou JCB precisam estar em conformidade com o PCI DSS, estando sujeitas a multa ou penalidade se não o fizerem.

O PCI DSS inclui classificações para vários tipos de comerciantes, desde os que coletam informações de pagamentos pessoalmente até os que terceirizam inteiramente o processamento dos pagamentos. Neste guia, você fica conhecendo os tipos de comerciantes SAQ A, SAQ A-EP, e SAQ D.

Objetivos

  • Analisar a arquitetura do aplicativo de processamento de pagamentos.
  • Configurar o ambiente de processamento de pagamentos.
  • Implementar e configurar os servidores de aplicativos.
  • Configurar a geração de registros e o monitoramento.
  • Validar o ambiente de processamento de pagamentos.

Definições

Neste guia, usamos vários termos exclusivos. Veja a seguir os mais comuns. Para ver mais informações, consulte o glossário do PCI DSS.

CDE: acrônimo de cardholder data environment (ambiente de dados do titular do cartão). Refere-se a qualquer parte do aplicativo que mantenha ou transfira quaisquer dados do titular do cartão, incluindo o número da conta para pagamento ou informações de identificação pessoal relativas ao cartão.

Controles de compensação: soluções alternativas para qualquer requisito que atenda fielmente ao requisito original e que forneça um nível semelhante de defesa. A definição oficial afirma que os controles de compensação precisam prevalecer sobre outros requisitos de PCI DSS e estar em consonância com o risco adicional resultante da não adesão ao requisito original.

PAN: acrônimo de primary account number (número da conta principal), sendo também chamado de número da conta. É um número exclusivo do cartão de pagamento que identifica o emissor e a conta do titular do cartão.

QSA: acrônimo de Qualified Security Assessor (avaliador de segurança qualificado). Os QSAs são qualificados pelo conselho de padrões de segurança do PCI (SSC) para realizar avaliações do PCI DSS no local. Consulte os requisitos de qualificação QSA para saber detalhes sobre os requisitos de QSA para empresas e funcionários.

SAQ: acrônimo de Self-Assessment Questionnaire (questionário de autoavaliação), a ferramenta de relatórios usada para documentar os resultados de autoavaliação gerados na avaliação do PCI DSS de uma entidade.

Escopo: os sistemas, procedimentos e pessoas a serem incluídas em uma avaliação do PCI DSS.

Tokenização: um processo que substitui o número da conta principal (PAN) por um valor alternativo denominado token. O PAN é armazenado em uma pesquisa segura. Destokenização é o processo inverso de pesquisar um PAN pelo respectivo token. Um token pode ser um hash ou um valor atribuído.

Contexto

O PCI DSS fornece uma lista de requisitos projetados para aprimorar a segurança do titular do cartão. Esses requisitos se dividem em 12 principais partes numeradas e muitas subpartes. Neste documento, mencionamos esses números de partes para fins de contexto, mas as referências de seção não são uma lista completa de requisitos aplicáveis.

Os requisitos de conformidade com o PCI DSS variam conforme a empresa processa transações de cartões de pagamento (tipo) e quantas transações ela gerencia a cada ano (nível).

À medida que o número de transações aumenta, o nível de comerciante PCI DSS sobe e as diretrizes de conformidade do PCI DSS ficam mais rígidas. No nível de comerciante mais alto, o nível 1, o PCI DSS requer uma auditoria. Os níveis variam de acordo com a marca do cartão. O nível 1 é definido pela American Express como 2,5 milhões de transações por ano. Já Visa, Mastercard e Discover o definem como 6 milhões de transações por ano. Cada marca de cartão tem requisitos de nível adicionais que estão além do escopo deste documento. Certifique-se de que seu ambiente de processamento de pagamentos seja auditado para aceitar o nível de comerciante.

Como o Google Cloud é um provedor de serviços compatível com PCI DSS 3.2 nível 1, é possível que ele atenda às necessidades de conformidade com PCI DSS, independentemente do nível de comerciante da sua empresa. A seção Compromisso com a conformidade mostra quais áreas são cobertas pelo Google.

A outra variável fundamental é o tipo de SAQ. A SAQ descreve os critérios que você precisa atender para cumprir o PCI DSS. O tipo de SAQ é determinado pela arquitetura do app e pela maneira precisa de lidar com os dados do cartão de pagamento. A maioria dos comerciantes na nuvem inclui:

Tipo de SAQ Descrição
A Comerciantes que terceirizaram totalmente o processamento de cartões de pagamento para outro site. Os clientes saem do seu domínio (inclusive por meio de um formulário da Web <iframe>), concluem o pagamento e retornam ao aplicativo.

Em outras palavras, sua empresa não pode tocar nos dados do cartão do cliente de forma alguma.
A-EP Comerciantes que terceirizam o processamento de pagamentos para um provedor, mas que podem acessar os dados do cartão do cliente em qualquer ponto do processo. Esses comerciantes que têm a possibilidade de acessar os dados do cartão incluem elementos de página controlados por eles, como JavaScript ou CSS, que estão incorporados à página de pagamento de terceiros.

Em outras palavras, o aplicativo de processamento de pagamentos encaminha os dados do cartão para um processador do cliente, ou o processador renderiza qualquer conteúdo hospedado por você.
D Comerciantes que aceitam pagamentos on-line e não se qualificam para SAQ A ou SAQ A-EP. Esse tipo inclui todos os comerciantes que chamam uma API de processador de pagamentos dos próprios servidores, independentemente da tokenização.

Em outras palavras, se você não é SAQ A ou SAQ A-EP, então é SAQ D.

O SAQ D diferencia os Comerciantes dos Provedores de serviços. Os provedores de serviços não são discutidos neste documento, e todas as referências a SAQ D tratam de comerciantes conforme definidos no PCI DSS.
Diagrama de Venn dos requisitos de SAQ. SAQ A-EP é um superconjunto de SAQ A, e SAQ D é um superconjunto de SAQ A-EP.
Diagrama de Venn dos requisitos de SAQ. SAQ A-EP é um superconjunto de SAQ A, e SAQ D é um superconjunto de SAQ A-EP.

Os comerciantes podem ser qualquer combinação de nível e tipo, e os requisitos de conformidade variam muito dependendo das circunstâncias.

Compromisso com a conformidade

O Google usa uma variedade de tecnologias e processos para proteger as informações armazenadas nos nossos servidores. O Google validou independentemente os requisitos do PCI DSS que se aplicam às tecnologias e à infraestrutura do Google Cloud gerenciadas pelo Google. Ainda que o Google ofereça aos comerciantes muito controle sobre as instâncias de computação executadas na infraestrutura do Google, o Google não controla a segurança do sistema operacional, dos pacotes ou dos aplicativos que os comerciantes implantam no Google Cloud. É sua responsabilidade obedecer aos requisitos do PCI DSS para pacotes e aplicativos do sistema operacional implantados, além de outras personalizações exigidas pela arquitetura.

O Google Cloud segue os requisitos do PCI DSS estabelecidos para um provedor de serviços de nível 1 e todos os requisitos aplicáveis. A Matriz de responsabilidade do cliente do Google Cloud descreve as obrigações de conformidade do PCI DSS. É possível que a matriz de responsabilidade seja uma referência útil à medida que você segue a conformidade com o PCI DSS e realiza suas próprias auditorias.

Orientação do produto

App Engine

As regras de firewall de entrada no App Engine estão disponíveis, mas as regras de saída não estão disponíveis no momento. De acordo com os requisitos 1.2.1 e 1.3.4, você precisa garantir que todo o tráfego de saída seja autorizado. Os comerciantes dos tipos SAQ A-EP e SAQ D precisam fornecer controles de compensação ou usar um produto diferente do Google Cloud. O Compute Engine e o GKE são as melhores alternativas.

Cloud Functions

Assim como o App Engine, o Cloud Functions não aceita regras de firewall de saída no momento. Os comerciantes dos tipos SAQ A-EP e SAQ D precisam fornecer controles de compensação ou usar um produto diferente do Google Cloud. O Compute Engine e o GKE são as melhores alternativas.

Google Kubernetes Engine

Use os nós e os pods em um cluster do GKE da mesma maneira que qualquer servidor gerenciado pelo comerciante. Implemente geração de registros, instrumentação e aplicação de patches nos níveis de nó e de pod. Você não mantém os dados do titular do cartão no nível do nó. No entanto, os nós ainda estarão no escopo se contiverem ou puderem conter quaisquer pods nele.

Para restringir o acesso ao mestre do cluster, use redes autorizadas para bloquear endereços IP não confiáveis de fora do Google Cloud. Essas regras CIDR são compatíveis com clusters particulares e funcionam como uma lista de permissões.

Implemente políticas de rede no cluster do GKE quando os projetos em escopo contiverem diferentes tipos de pods. As políticas de rede funcionam como os firewalls de nuvem privada virtual (VPC, na sigla em inglês) que talvez você já conheça. É possível permitir ou negar o tráfego com base em rótulos ou regras de IP.

O requisito 2.2.1 estipula que apenas uma função primária pode ser implementada por servidor. Esse requisito não proíbe o caso de um único cluster do GKE que hospede mais de um tipo de pod. A principal função dos nós do GKE é disponibilizar e gerenciar contêineres. Se projetados adequadamente, os pods individuais também podem aderir a essa regra de função principal em um único cluster.

Cloud Storage

O requisito 3.4 estipula que um PAN precisa estar ilegível em qualquer lugar onde esteja armazenado. O Google oferece automaticamente a criptografia em repouso, mas não realiza automaticamente hashes unidirecionais, truncamento ou tokenização, também exigidos pelas regras.

Exemplos de arquiteturas

Esta seção ilustra as abordagens para implementar um ambiente que está em conformidade com SAQ A, SAQ A-EP e SAQ D.

Visão geral da arquitetura

SAQ A

SAQ A é a arquitetura de processamento de pagamentos mais básica. Os pagamentos são processados por terceiros, e nenhum dado do cartão é acessado por aplicativos ou páginas do comerciante.

Em um nível superior, este é o fluxo de processamento de pagamentos:

  1. O cliente faz as seleções dele e prossegue para finalizar a compra.

  2. O aplicativo de finalização redireciona o cliente para um processador de pagamentos de terceiros.

  3. O cliente insere as informações do cartão de pagamento em um formulário que é fornecido e mantido pelo processador terceirizado.

  4. O processador de pagamentos terceirizado verifica as informações e cobra ou recusa o cartão.

  5. Depois de cuidar da transação, o processador de pagamentos terceirizado envia o cliente de volta ao aplicativo do comerciante junto com os detalhes da transação.

  6. O aplicativo do comerciante envia uma solicitação de verificação ao processador de pagamentos para confirmar a transação.

  7. O processador de pagamentos responde para verificar os detalhes da transação.

Arquitetura de um ambiente de processamento de pagamentos SAQ A

SAQ A-EP

A arquitetura de processamento de pagamentos SAQ A-EP gira em torno de um aplicativo do mesmo tipo que é executado nas instâncias de máquina virtual do Compute Engine. Essas instâncias estão em uma rede privada segura e usam canais protegidos para se comunicar com serviços que estão fora da rede.

Em linhas gerais, este é o fluxo de processamento de pagamentos:

  1. O cliente insere as informações do cartão de pagamento em um formulário que é fornecido e mantido pela sua empresa.

  2. Quando o cliente envia as próprias informações, as informações do formulário são transmitidas de modo seguro para um processador de pagamentos terceirizado.

  3. O processador de pagamentos terceirizado verifica as informações e cobra ou recusa o cartão.

  4. O processador de pagamentos envia uma resposta para o aplicativo de pagamento, que transmite uma mensagem ao aplicativo principal.

Todas essas interações são registradas e monitoradas com o Cloud Logging e o Cloud Monitoring.

Arquitetura de um ambiente de processamento de pagamentos SAQ A-EP
Arquitetura de um ambiente de processamento de pagamentos SAQ A-EP

SAQ D

A arquitetura de processamento de pagamentos SAQ D gira em torno de um aplicativo do mesmo tipo que é executado nas instâncias de máquina virtual do Compute Engine. Essas instâncias estão em uma rede privada segura e usam canais protegidos para se comunicar com serviços que estão fora da rede.

Em linhas gerais, este é o fluxo de processamento de pagamentos:

  1. O cliente insere as informações do cartão de pagamento em um formulário que é fornecido e mantido pela sua empresa.

  2. Quando o cliente envia as próprias informações, o aplicativo de pagamento recebe as informações do formulário.

  3. Seu aplicativo de pagamento valida as informações de pagamento e as transmite com segurança para um processador de pagamentos terceirizado por meio de uma API de back-end.

  4. O processador de pagamentos terceirizado verifica as informações e cobra ou recusa o cartão.

  5. O processador de pagamentos envia uma resposta para o aplicativo de pagamento, que transmite uma mensagem ao aplicativo principal.

Todas essas interações são registradas e monitoradas no Logging e no Monitoring.

Arquitetura de um ambiente de processamento de pagamentos SAQ D
Arquitetura de um ambiente de processamento de pagamentos SAQ D

Fluxo do cliente no processamento de pagamentos

SAQ A

Nesta seção, é descrito o fluxo de processamento de pagamentos de terceiros na perspectiva dos clientes que usam o aplicativo.

Fluxo do cliente no processamento de pagamentos SAQ A de terceiros
Fluxo do cliente no processamento de pagamentos SAQ A de terceiros

Quando seu cliente acessa seu formulário de pagamento, o aplicativo apresenta um <iframe> hospedado pelo processador de pagamento. Não é possível acessar ou monitorar o conteúdo de <iframe> devido a limitações de compartilhamento de recursos de origem cruzada por parte do aplicativo. Quando o cliente envia as informações do cartão de pagamento, o processador de pagamentos aceita ou recusa o cartão e, em seguida, envia o cliente de volta ao app. Em seguida, seu app verifica a resposta da transação do processador de pagamentos e age de acordo. Seu aplicativo não acessou nem manipulou nenhuma informação do cartão de pagamento.

SAQ A-EP

Nesta seção, descrevemos o mesmo fluxo interno de processamento de pagamentos, conforme descrito anteriormente, mas da perspectiva dos clientes que usam o aplicativo.

Fluxo do cliente no processamento de pagamentos SAQ A-EP de terceiros
Fluxo do cliente no processamento de pagamentos SAQ A-EP de terceiros

Quando o cliente acessa o URL do formulário de pagamento, o site apresenta um formulário hospedado pelo aplicativo de pagamento. Quando o cliente envia as informações do cartão de pagamento, o formulário vai diretamente para o processador de pagamentos. O processador aceita ou recusa o cartão e envia o cliente de volta para seu app. Em seguida, seu app verifica a resposta da transação do processador de pagamentos e age de acordo. O cliente pode não ver o processador de pagamentos terceirizado, mas seu aplicativo não acessou nenhuma informação de cartão de pagamento do servidor.

SAQ D

Nesta seção, é descrito o fluxo interno de processamento de pagamentos na perspectiva dos clientes que usam seu aplicativo.

Fluxo do cliente no processamento de pagamentos SAQ D de terceiros
Fluxo do cliente no processamento de pagamentos SAQ D de terceiros

Quando o cliente acessa o URL do formulário de pagamento, ele é encaminhado para o formulário de modo seguro, por meio de um balanceador de carga HTTPS. Quando o cliente envia as próprias informações de cartão de pagamento, o aplicativo de processamento de pagamentos encaminha essas informações com segurança a um processador de pagamentos terceirizado. O processador de pagamentos terceirizado aceita ou recusa o cartão, depois retorna uma resposta ao aplicativo de processamento de pagamentos.

Fluxo interno de processamento de pagamentos

SAQ A e A-EP

Nesta seção, é descrito o fluxo de processamento de pagamentos na perspectiva dos servidores que executam o aplicativo.

Fluxo interno de SAQ A e SAQ A-EP
Fluxo interno de SAQ A e SAQ A-EP

Seu aplicativo de processamento de pagamentos recebe e analisa a resposta retornada pelo processador de pagamentos de terceiros e, em seguida, envia alguns ou todos os dados de resposta para o aplicativo principal. Nesse momento, o aplicativo de processamento de pagamentos será concluído com a transação. O aplicativo principal processa a tarefa de notificar seus clientes.

SAQ D

Nesta seção, descrevemos o fluxo interno de processamento de pagamentos na perspectiva dos servidores que executam o aplicativo.

Fluxo interno de SAQ D
Fluxo interno de SAQ D

Seu aplicativo de processamento de pagamentos valida as informações do cartão de pagamento enviadas pelo cliente e as envia ao processador de pagamentos por meio de uma API de back-end. O processador tenta fazer a cobrança e responde com os detalhes da transação. Seu app recebe e processa a resposta e, em seguida, envia alguns ou todos os dados de resposta para o app principal. Nesse momento, o aplicativo de processamento de pagamentos será concluído com a transação. O aplicativo principal processa a tarefa de notificar o cliente e entregar o produto.

Fluxo de dados de monitoramento e geração de registros

O fluxo de geração de registros e monitoramento foi projetado da seguinte forma:

Fluxo de geração de registros e monitoramento
Fluxo de geração de registros e monitoramento

Como configurar o ambiente de processamento de pagamentos

Nesta seção, descrevemos como configurar o ambiente de processamento de pagamentos. A configuração inclui o seguinte:

  • Criar uma nova conta do Google Cloud para isolar o ambiente de processamento de pagamentos do ambiente de produção.
  • Restringir o acesso ao ambiente.
  • Configurar os recursos virtuais.
  • Projetar a imagem Linux de base que você usará para configurar os servidores de aplicativos.
  • Implementar uma solução de gerenciamento de pacotes segura.

Como configurar uma nova conta

Para simplificar a restrição de acesso e a auditoria de conformidade, crie um ambiente de processamento de pagamentos com qualidade de produção que seja totalmente isolado do ambiente de produção padrão e quaisquer ambientes dev/QA (requisito 6.4.1). Para garantir o isolamento, crie e use uma conta do Google Cloud separada da conta do ambiente de produção principal. É possível que os usuários com experiência na configuração do Cloud Identity and Access Management (Cloud IAM) consigam isolamento equivalente usando projetos separados para trabalho dentro do escopo.

Restringir o acesso ao ambiente

Permita acesso ao ambiente de processamento de pagamentos somente para quem implementa o código do seu sistema de pagamento ou gerencia as máquinas do seu sistema de pagamento (seção 7.1 e requisito 8.1.1). Isso é conhecido como princípio do menor privilégio. Use os papéis do Cloud IAM para restringir o acesso. As práticas recomendadas incluem o uso de papéis sempre que possível, concedendo apenas as permissões necessárias para executar o trabalho esperado e concedendo apenas o papel de Proprietário aos membros que legitimamente precisam de acesso raiz completo aos serviços. Consulte o Guia de segurança do Cloud IAM para ver mais informações.

O acesso automatizado a qualquer serviço gerenciado deve se basear em contas de serviço. Elas simplificam o ciclo de vida do gerenciamento de aplicativos ao fornecer uma maneira de gerenciar a autenticação e a autorização deles. Essas contas oferecem uma maneira flexível e segura de agrupar instâncias de máquina virtual com aplicativos e funções semelhantes que tenham uma identidade em comum. É possível aplicar o controle de acesso e segurança no nível da conta de serviço por meio de papéis do Cloud IAM e regras de firewall VPC.

As regras do Cloud IAM aplicadas às pastas são herdadas por todos os itens contidos nessas pastas. As permissões padrão são "deny-all" (requisito 7.2.3), e todas as regras aplicadas apenas adicionam permissões.

O requisito 8.2.3 fornece algumas regras básicas para senhas de usuários. O Instituto Nacional de Padrões e Tecnologia (NIST, na sigla em inglês) define um conjunto mais seguro de regras para senhas seguras na seção 5.1.1 do NIST SP800-63B (em inglês). O Google recomenda seguir as diretrizes de identidade digital do NIST sempre que possível.

O PCI DSS SAQ D seção 12.7 exige que seja feita uma verificação de antecedentes, nos termos da legislação local, dos indivíduos que receberão acesso ao seu ambiente em escopo. Visando a reduzir o risco de violações de conformidade, pense em realizar essas verificações de antecedentes criminais e de referências para cada indivíduo, independentemente do tipo de conformidade.

Como proteger a rede

Para proteger o tráfego de entrada e saída na rede de aplicativos de processamento de pagamentos, você precisa criar o seguinte:

  • regras de firewall do Compute Engine
  • um túnel de rede privada virtual (VPN, na sigla em inglês) do Compute Engine
  • Um balanceador de carga HTTPS do Compute Engine

Para criar sua VPC, recomendamos o Cloud NAT para uma camada extra de segurança de rede. Há muitas opções avançadas disponíveis para proteger as redes das instâncias do Compute Engine e do GKE.

Criar regras de firewall

Use regras de firewall para restringir o tráfego de entrada para cada instância do Compute Engine (requisitos 1.2.1 e 1.3.2). Permita tráfego de entrada apenas destas três origens:

  • HTTPS público. Assim, os clientes podem acessar a página de pagamentos.
  • A rede de aplicativos. Assim, o aplicativo de processamento de pagamentos pode receber respostas do processador de pagamentos terceirizado.
  • A rede interna de escritórios. Assim, é possível acessar as instâncias para fins de auditoria e gerenciamento.

Use regras de firewall em instâncias individuais para restringir o tráfego de saída. Você pode implementar essas regras localmente com iptables ou, de forma mais ampla, usando regras de firewall VPC e tags de rede. Permita tráfego de saída apenas do seu formulário de pagamentos para o processador de pagamentos terceirizado. Essa conexão precisa ser somente HTTPS. Consulte a seção "Geração de registros de regras de firewall" abaixo para testar seu trabalho.

O Cloud DNS oferece zonas DNS particulares para que seja possível nomear com segurança hosts no CDE sem o potencial de vazar dados de topologia de rede confidenciais para o público.

Restrinja o tráfego da seguinte forma:

Origem Destino Porta Direção e motivo
Balanceador de carga público Formulário de pagamentos terceirizado tcp:443 Entrada
Acesso público ao aplicativo de processamento de pagamentos
Formulário de pagamento terceirizado Processador de pagamentos terceirizado tcp:443 Saída
Envio de solicitações AUTH para o provedor de serviços de pagamento
Processador de pagamentos terceirizado Aplicativo de processamento de pagamento tcp:5480 Entrada
Aceitação de solicitações AUTH de sistemas de pagamento (não contém dados do titular do cartão)
A rede de escritórios da empresa vpn-gateway tcp:8000 Entrada
Acesso ao ambiente de processamento de pagamentos para acesso a registros e máquinas de desenvolvimento

Além disso, o seguinte tráfego ocorre com segurança na rede interna do aplicativo de processamento de pagamentos:

Origem Destino Porta Motivo
Formulário de cartão Proxy PCI tcp:5480 Troca de dados de cartão criptografados para token como instrumento de pagamento
Todos os hosts Servidores NTP do Google udp:123 Sincronização de tempo
Gateway VPN Todos os hosts tcp:22 Conexões SSH (Secure Shell)

Como estabelecer um túnel VPN seguro

O Compute Engine fornece um serviço de VPN. É possível usá-lo para estabelecer um túnel VPN seguro entre o ambiente local e o ambiente de processamento de pagamentos (seções 2.3 e 4.1).

Como criar um balanceador de carga HTTPS

Garanta a segurança do tráfego de entrada de clientes criando um balanceador de carga HTTP(S) do Compute Engine (seções 2.3 e 4.1). Para criá-lo, você precisa de:

  • um subdomínio de seu site que é usado no formulário de processamento de pagamentos, por exemplo, payments.your-domain-name.com;
  • um certificado SSL válido, assinado e registrado para seu subdomínio.

Verifique se o domínio é válido analisando as respectivas configurações de DNS na interface de configuração de domínio do registrador da Web.

Como criar uma imagem Linux de base

O PCI DSS contém requisitos que descrevem como configurar máquinas que compõem uma arquitetura de processamento de pagamentos em conformidade com os padrões. É possível implementar esses requisitos de várias maneiras, mas a abordagem mais fácil é esta:

  1. Crie uma lista dos softwares e bibliotecas que precisam ser instalados em cada servidor no escopo do seu aplicativo de processamento de pagamentos. Para evitar a introdução de vulnerabilidades desnecessárias no seu sistema (requisito 2.2.2), inclua apenas o mínimo de software e bibliotecas necessárias para executar o aplicativo. Os candidatos podem incluir o SDK do Cloud, bibliotecas e ambientes de execução específicos da linguagem ou um servidor da Web.

  2. Crie uma instância do Compute Engine que use uma das imagens pré-configuradas do sistema operacional do Compute Engine.

  3. Instale as bibliotecas e o software listados anteriormente.

  4. Instale e configure ntp para manter os relógios do sistema sincronizados. O gerenciamento de relógios do servidor com o Network Time Protocol garante a integridade dos carimbos de data/hora nos registros (seção 10.4).

  5. Verifique se a imagem segue as práticas recomendadas para criar uma imagem segura do Compute Engine (toda a seção 2.2).

  6. Depois de configurar a imagem de base, crie uma imagem do disco personalizada do Compute Engine a partir da sua imagem. Essa imagem permite que você use sua imagem Linux de base ao criar instâncias de máquina virtual.

Como usar o gerenciamento seguro de pacotes

O gerenciamento de pacotes é um componente essencial de um ambiente de hospedagem com aumento de proteção. Conforme a seção 2.2, você precisa implementar padrões de aumento de proteção aceitos pelo setor. A menos que use o SO Container-Optimized do Google, talvez você tenha instalado um gerenciador de pacotes como RPM, Yum ou Apt. O aplicativo pode usar o gerenciador de pacotes específico da própria linguagem de programação, como NPM, PyPi ou Composer, e fazer o download das dependências na primeira execução.

Se o aplicativo puder buscar atualizações na Internet, você precisará tratar as origens de atualização como um potencial risco de segurança. Ataques de fornecimento ou upstream, que são maliciosamente incluídos em pacotes de hospedagem pública, estão se tornando mais comuns. Imagine os efeitos da instalação de uma atualização no SSH que contenha código malicioso.

É possível reduzir o risco de ataques de fornecimento ao criar uma lista de destinatários seguros para os pacotes e verificar se eles correspondem a ela. Mantenha uma lista de números de versão testados e aprovados para cada pacote que você usa. Registre o número da versão junto ao respectivo hash ou assinatura. Garanta que o gerenciador de pacotes valide o hash ou a assinatura antes de instalar ou atualizar um aplicativo.

A maioria dos sistemas de gerenciamento de pacotes permite hospedagem particular. Se possível, inicie seu próprio servidor particular de gerenciamento de pacotes e hospede somente software testado e aprovado. Bloqueie o gerenciador de pacotes para que ele não acesse outros servidores em busca de atualizações.

O ideal é que o processo de criação de aplicativos busque e valide todos os pacotes e, em seguida, crie uma revisão da imagem de disco personalizada incluindo tudo o que o contêiner precisa. Dessa forma, os servidores são inicializados e ampliados sem atraso do instalador, e há uma chance reduzida de erros aleatórios no momento da inicialização. Para revisitar qualquer versão anterior do aplicativo exatamente como estava em produção, basta iniciar a respectiva imagem. Isso pode ser útil para diagnóstico e perícia forense.

Implantação e configuração

Em seguida, configure a implantação e a configuração das instâncias a partir da imagem de base.

Como implantar o ambiente

Para atender aos requisitos do PCI DSS, verifique se você está implantando o aplicativo correto sempre e com segurança e se não está instalando nenhum outro pacote de software durante a implantação. Para simplificar o processo de implantação, crie uma implantação automatizada do aplicativo usando o Cloud Deployment Manager.

Com o Deployment Manager, é possível descrever todo o ambiente de processamento de pagamentos, incluindo regras de firewall, gateways, balanceadores de carga e instâncias. Ele também ajuda a criar uma trilha de auditoria que mostra como cada ambiente de aplicativo foi criado. Assim, é possível controlar as versões dos ambientes à medida que os aprimora e modifica.

Em uma implantação automatizada, é preciso verificar a integridade do software a ser implantado, seja ele de terceiros ou seu. É possível verificar o software executando um hash automatizado em cada pacote durante a instalação. Após a verificação de um hash, é possível usar uma biblioteca de testes automatizados para executar testes de segurança, entre outros, e ver se eles são aprovados.

Por fim, ao implantar instâncias do Compute Engine, crie um plano de recuperação para o caso de falhas nas instâncias. Se a janela de inatividade aceitável for grande o suficiente, talvez um plano de recuperação manual seja suficiente. Caso contrário, projete um plano de recuperação automatizado. Para ver orientações, consulte o guia de Planejamento de recuperação de desastres, Como desenvolver sistemas escalonáveis e robustos e Como criar aplicativos da Web escalonáveis e resilientes.

Como configurar o ambiente

Depois que suas instâncias forem implantadas, verifique se estão configuradas corretamente. Instale software e bibliotecas adicionais na imagem de base de cada instância, conforme necessário. Para evitar a complexidade, sobrecarga e o risco geral da configuração manual, use uma ferramenta de gestão de configuração automatizada como Skaffold, Chef, Puppet, Ansible ou Salt (em inglês).

Ataques à cadeia de suprimentos em origens upstream estão se tornando uma preocupação maior. Portanto, além de usar imagens Linux de base, utilize uma ferramenta como a API Grafeas para auditar o código upstream.

Como implementar o Forseti Security

O Forseti Security (em inglês) é uma coleção de ferramentas de código aberto orientadas pela comunidade para ajudar você a melhorar a segurança dos seus ambientes do Google Cloud. Sua arquitetura modular permite que você habilite componentes individuais, vários dos quais podem atender a requisitos específicos dentro do PCI DSS.

O Inventory (em inglês) cria um snapshot do inventário dos recursos do Google Cloud para que você tenha um registro histórico da arquitetura.

O Scanner (em inglês) usa as informações coletadas pelo Forseti Inventory para comparar regularmente as políticas de acesso com base em papéis dos seus recursos do Google Cloud. O Scanner aplica regras para auditar recursos do Google Cloud como o seguinte:

  • Políticas do Cloud Identity and Access Management (Cloud IAM) para organizações, pastas e projetos
  • ACLs de bucket
  • ACLs do conjunto de dados do BigQuery
  • Redes autorizadas do Cloud SQL

Com o Scanner, é possível especificar usuários, grupos e domínios que são permitidos, obrigatórios ou excluídos dos recursos e pode garantir que essas políticas de acesso permaneçam consistentes. Se o Scanner encontrar alguma política de acesso que não corresponda às regras dele, poderá salvar informações sobre essas violações no Cloud SQL ou no Cloud Storage. Isso ajuda a protegê-lo contra alterações inseguras ou não intencionais.

O Enforcer usa as políticas que você cria para comparar o estado atual do seu firewall do Compute Engine a um estado especificado. O Enforcer é uma ferramenta de linha de comando sob demanda que compara políticas no modo em lote em todos os projetos gerenciados ou em projetos selecionados. Se o Enforcer encontrar alguma diferença na política, ele usará as APIs do Google Cloud para fazer alterações e exibir a saída dos resultados.

O módulo adicional Explain fornece visibilidade das suas políticas do Cloud IAM. O Explain pode ajudar você a entender:

  • quem tem acesso a quais recursos e como esse usuário pode interagir com o recurso;
  • por que um diretor tem permissão em um recurso ou por que ele não tem uma permissão e como corrigir isso;
  • quais papéis concedem uma permissão e quais papéis não estão em sincronia com as alterações recentes.

Depois de configurá-lo, as notificações por e-mail podem enviar notificações por e-mail para Inventory e Scanner.

Como implementar registro de auditoria imutável

O Logging produz registros de auditoria automaticamente para uma grande variedade de atividades em muitos produtos. Em longo prazo, é possível armazenar registros imutáveis com segurança usando bloqueios de bucket do Cloud Storage (seção 10.5). Bloqueios de bucket permitem definir uma política que torne todos os objetos imutáveis e não excluíveis por um período de tempo especificado por você, de segundos a anos. Se você precisar de acesso ao programa de acesso antecipado, entre em contato com seu representante do Google Cloud.

Como implementar os registros de fluxo de nuvem privada virtual

O serviço de registros de fluxo de VPC é projetado para gravar os fluxos de rede enviados de instâncias de máquina virtual ou recebidos por elas. É possível usar esses registros para monitoramento de rede (seção 10.2), perícia forense (requisito 10.6.3) e análise de segurança em tempo real.

Como instalar o agente do Logging

Depois que você configurar iptables nos servidores, cada servidor registrará todas as atividades no armazenamento em blocos. Confira a página de preços do Logging para ver detalhes sobre a cota gratuita e os preços de transferência de dados. Para manter esses registros e gerar alertas com base na atividade anormal, direcione-os para o Logging e o Monitoring instalando o agente do Logging em cada servidor (requisito 10.5.3).

Como integrar um sistema de detecção de intrusão

Para garantir a segurança do ambiente de processamento de pagamentos, descrito na seção 11.4, use um sistema de detecção de intrusões (IDS, na sigla em inglês) para saber quando ocorrem tentativas de ataque ao sistema. Há duas maneiras de colocar um IDS em um ambiente de processamento de pagamentos: colocação em cada ponto de entrada ou instalação em cada servidor.

Para reduzir a complexidade da arquitetura do ambiente e simplificar a conformidade com o requisito 11.5, instale um IDS em cada servidor. Depois de pesquisar e escolher o software IDS a ser usado, inclua a instalação dele no script de instalação de inicialização de cada servidor.

Os registros de IDS se enquadram no escopo da conformidade com o PCI DSS e precisam ser enviados ao Logging e ao Monitoring para fins de relatórios, alertas e auditorias.

Como implementar o Security Command Center

O serviço do Security Command Center (Beta) ajuda as equipes de segurança a coletar dados, identificar ameaças e responder às ameaças antes que elas resultem em danos ou perdas aos negócios. Ele oferece insights detalhados sobre o risco de aplicativos e dados, para que você possa reduzir rapidamente as ameaças aos recursos de nuvem e avaliar a integridade geral. O Security Command Center permite ver e monitorar um inventário dos ativos na nuvem, verificar os sistemas de armazenamento quanto a dados confidenciais, detectar vulnerabilidades comuns na Web e analisar os direitos de acesso aos seus recursos essenciais, tudo em um único painel centralizado. Você entra em conformidade com vários requisitos, incluindo as seções 5 e 6.6.

Como automatizar a implantação do aplicativo

Crie sua ferramenta de gestão de configurações para recuperar e lançar com segurança a versão mais recente do seu aplicativo. Recupere o aplicativo de qualquer local, assim como o Cloud Storage, desde que esse local seja seguro.

Muitas das ferramentas de gestão de configuração mencionadas acima aceitam fluxos de trabalho de integração e implantação contínuas (CI/CD), que também podem ser usados para executar a verificação automatizada (requisito 11.2.3) e garantir que o código seja revisado (requisito 6.3.2).

Como capturar registros do gerenciador de configuração

Ao configurar seu gerenciador de configuração, assegure-se de que ele registre todos os detalhes da instalação. Depois de concluir o processo de configuração, assegure-se de que ele envie os registros ao Logging e ao Monitoring.

Geração de registros e monitoramento

Para garantir a conformidade com o PCI DSS nos termos da seção 10, assegure-se de que todas as etapas realizadas no ambiente de processamento de pagamentos sejam monitoradas e registradas. Toda atividade do servidor em todas as instâncias precisa ser registrada, e toda ação do usuário precisa ser passível a análise em momento posterior.

Como ativar a transparência no acesso

Por meio de um recurso chamado transparência no acesso, o Logging agora oferece registros quase em tempo real quando os administradores do Google Cloud acessam seu conteúdo. Os registros de auditoria do Cloud já fornecem visibilidade sobre as ações dos próprios administradores. No entanto, essa trilha de auditoria costuma excluir as ações tomadas pelo suporte ou pela equipe de engenharia do provedor de nuvem. Por exemplo, antes da geração de registros da transparência no acesso, se você abrisse um tíquete no Suporte do Google que exigisse acesso a dados, ele não seria rastreado nos registros de auditoria do Cloud. A transparência no acesso preenche essa lacuna, capturando registros quase em tempo real do acesso manual e segmentado por parte do suporte ou da engenharia.

O Google recentemente lançou a Aprovação de acesso. Esse recurso está no estágio de lançamento de acesso antecipado. Enquanto a transparência no acesso fornece informações sobre acessos do Suporte e Engenharia do Google, a Aprovação de acesso permite que você aprove explicitamente o acesso aos dados ou configurações no Google Cloud antes que esse acesso ocorra. Para ver mais detalhes e solicitar acesso antecipado, consulte a página no link.

Como ativar a geração de registros de regras de firewall

A geração de registros de regras de firewall permite que você ative o registro no nível de regra individual. Ela pode gravar conexões TCP e UDP dentro de um VPC para qualquer regra que você mesmo criar. Isso pode ser útil para auditar o acesso à rede ou fornecer aviso antecipado de que a rede está sendo usada de maneira não aprovada.

Como usar VPC Service Controls

Os VPC Service Controls (Beta) permitem definir um perímetro de segurança em torno dos recursos do Google Cloud, como buckets do Cloud Storage, instâncias do Cloud Bigtable e conjuntos de dados do BigQuery, para restringir os dados em uma VPC e ajudar a reduzir os riscos de exfiltração de dados (requisitos 1.2.1 e 1.3.4). Com o VPC Service Controls, é possível manter seus dados confidenciais em sigilo enquanto aproveita os recursos totalmente gerenciados de armazenamento e processamento de dados do Google Cloud. Solicite acesso antecipado para ver mais informações.

Como configurar registros de fluxo de VPC

Ambiente de dados do titular do cartão com registros de fluxo de VPC ativados
CDE com registros de fluxo de VPC ativados

Os registros de fluxo de VPC registram os fluxos de tráfego de rede enviados ou recebidos por instâncias de VM. Os registros são úteis no PCI DSS para monitoramento, auditoria, análise forense e verificação de segurança em tempo real. Cada sub-rede VPC pode ter registros de fluxo ativados ou desativados independentemente. É possível minimizar a quantidade de dados de registro ativando apenas os registros de fluxo do CDE no escopo.

Com os registros de fluxo combinados a regras de firewall de saída, você limita o tráfego de saída a endpoints autorizados, para que ele seja auditável e difícil de burlar (requisitos 1.2.1 e 1.3.4).

Se você precisar de dados mais detalhados do que os registros de fluxo fornecem, como geração de registros de solicitações HTTP individuais, será possível implementar controles nas solicitações de saída de proxy ou aplicativo. Isso é feito por meio do seu próprio servidor proxy reverso configurado para encaminhar registros de acesso ao Logging. Para instruções sobre como configurar um servidor proxy Squid no Compute Engine, consulte Como configurar um proxy de rede. Para evitar gargalos, configure pelo menos dois servidores proxy redundantes.

Como registrar dados de acesso internos

Além de registrar ameaças externas, também monitore e registre a atividade das pessoas que têm acesso administrativo ao ambiente de processamento de pagamentos (seção 10.2). Para fazer isso, você pode registrar comandos de shell. Várias ferramentas de código aberto podem auditar comandos de shell e enviá-los para registro. As principais escolhas para essa tarefa incluem OSSEC ou Tripwire.

Como configurar alertas de monitoramento

Configure o Monitoring para enviar alertas se algo der errado no ambiente de processamento de pagamentos (seção 10.6). Garanta que seus alertas cubram eventos ambientais, de auditoria e de aplicativos internos. Baseie sua estratégia de alertas no risco em potencial ou em vetores de ataque para cada componente do aplicativo de processamento de pagamentos. Por exemplo, acione alertas do Monitoring se seu IDS detectar tentativas de invasão, sejam elas bem-sucedidas ou não. Também é possível usar a geração de registros de regras de firewall para acionar alertas em resposta a tentativas de violar políticas de rede específicas.

Como transmitir registros para o BigQuery

Como registrar registros de streaming no Cloud Storage e no BigQuery
Como registrar registros de streaming no Cloud Storage e no BigQuery

Opcionalmente, é possível exportar registros do Logging para o BigQuery para analisar mais tarde. Por ser otimizado para realizar consultas em grandes conjuntos de dados, o BigQuery é uma ferramenta ideal para análises de registros em grande escala. Existe a possibilidade do Logging até registrar diretamente no BigQuery para registros que exigem análise quase em tempo real (requisito 10.6.1).

Como usar o Cloud Data Loss Prevention para higienizar dados

Há muitos motivos para usar partes dos dados contidos no seu aplicativo em escopo que não estejam no escopo, como aqueles de análise ou desenvolvimento. Conceda aos aplicativos acesso aos dados do PCI somente após terem sido limpos com o Cloud Data Loss Prevention (requisito 6.4.3).

Segurança do aplicativo

Para proteger o aplicativo, primeiro você precisa avaliar a interface administrativa. Use também o Cloud Key Management Service.

Como avaliar a interface administrativa

A maioria dos aplicativos de comércio eletrônico tem sua própria interface administrativa sem console, como um portal de faturamento de atendimento ao cliente. Uma ferramenta assim precisa ter controles de acesso robustos, ter acesso individualizado que use autenticação multifatorial (seção 8.3) e ser instrumentada com registros de auditoria (seção 10.2).

Qualquer registro que você criar deve responder a estas perguntas: quem fez o quê? Onde foi feito? Quando foi feito? De acordo com a seção 2.3, todo acesso a essa ferramenta precisa usar uma forte criptografia de transporte. Use o Cloud Data Loss Prevention para filtrar informações confidenciais antes de exibi-las em qualquer ferramenta de administração.

Como usar o Cloud Key Management Service (Cloud KMS)

O Cloud KMS é um sistema de armazenamento gerenciado para secrets. Ele gera, usa, alterna e destrói chaves de criptografia AES-256. Também pode armazenar e gerenciar outras chaves secretas com até 64 KB de comprimento. O Cloud KMS permite remover senhas armazenadas em código ou arquivos de configuração, o que simplifica a conformidade com os requisitos 3.5, 3.6, 6.3.1 e 8.2.

Como validar seu ambiente

Depois de implantar o ambiente, mas antes que qualquer tráfego de produção passe por ele, é preciso validá-lo:

A seguir