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

Neste guia, você aprende a implementar o padrão de segurança de dados do setor de cartões de pagamento (PCI DSS, na sigla em inglês) do seu negócio no Google Cloud Platform (GCP). 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, explica sua função na conformidade baseada em nuvem e fornece as diretrizes para projetar, implantar e configurar um aplicativo de processamento de pagamentos usando o PCI DSS. O tutorial também discute métodos para monitorar, gerar registros e validar seu aplicativo.

O padrão de segurança de dados do PCI, criado pelo PCI Security Standards Council (em inglês), é aplicado a negócios que processam informações de cartões de pagamento (crédito e débito). 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 de conta para pagamentos 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 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 provenientes da 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.

Informações complementares

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 GCP é um provedor de serviços de nível 1 compatível com o PCI DSS 3.2, ele oferece suporte às suas necessidades de conformidade com o PCI DSS, seja qual for o nível de comerciante da empresa. Na seção Compromisso com a conformidade, são expostas as áreas abordadas pelo Google para você.

A outra variável fundamental é o tipo de SAQ. Ele descreve os critérios que você precisa seguir para atender ao PCI DSS. O tipo de SAQ é determinado pela arquitetura do aplicativo e pelo modo preciso com que você trata 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 deixam 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 maneira 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 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 a partir dos próprios servidores, sem depender da tokenização.

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

O SAQ D diferencia comerciantes de provedores de serviço. 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. Validamos de maneira independente os requisitos do PCI DSS que se aplicam às tecnologias do GCP e à infraestrutura gerenciadas por nós. Oferecemos aos comerciantes grande parte do controle sobre as instâncias de computação que são executadas na infraestrutura do Google. No entanto, não controlamos a segurança de sistema operacional, pacotes ou aplicativos que os comerciantes implantam no GCP. É sua responsabilidade atender aos requisitos do PCI DSS em relação a aplicativos e pacotes do sistema operacional que você implanta, além de outras personalizações exigidas pela arquitetura.

O GCP segue os requisitos do PCI DSS estabelecidos para um provedor de serviços de nível 1 e todos os requisitos aplicáveis de provedor de serviços. A matriz de responsabilidade do cliente do GCP descreve as obrigações de conformidade do PCI DSS. Ela é uma referência útil à medida que você busca a conformidade com o PCI DSS e conduz as próprias auditorias relacionadas.

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 outro produto do GCP. 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 outro produto do GCP. 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 seu cluster mestre, use redes autorizadas para bloquear endereços IP não confiáveis de fora do GCP. Essas regras CIDR são compatíveis com clusters particulares e atuam como whitelist.

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 confirmar os detalhes da transação.

Arquitetura de um ambiente de processamento de pagamentos SAQ A de terceiros

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 no Stackdriver Logging e no Stackdriver 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 processsamento 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 o cliente acessa o formulário de pagamento, o aplicativo apresenta um <iframe> hospedado pelo processador de pagamentos. O aplicativo não pode acessar nem monitorar o conteúdo do <iframe> devido às limitações de compartilhamento de recursos entre origens. Quando o cliente envia as próprias informações de cartão de pagamento, o processador aceita ou recusa o cartão, depois redireciona o cliente novamente para o aplicativo. Em seguida, o aplicativo 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 seu formulário de pagamento, o site apresenta um formulário hospedado pelo seu aplicativo de pagamento. Quando o cliente envia as próprias informações de cartão de pagamento, o formulário vai diretamente para o processador de pagamentos. O processador aceita ou recusa o cartão, depois redireciona o cliente novamente para o aplicativo. Em seguida, o aplicativo 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

O aplicativo de processamento de pagamentos recebe e analisa a resposta retornada pelo processador de pagamentos terceirizado e, em seguida, envia alguns ou todos os dados de resposta ao aplicativo principal. Nesse ponto, o aplicativo de processamento de pagamentos termina sua ação 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

O aplicativo de processamento de pagamentos valida as informações do cartão enviadas pelo cliente e as encaminha ao processador de pagamentos por meio de uma API de back-end. O processador tenta fazer a cobrança e responde com detalhes da transação. O aplicativo recebe e processa a resposta e envia alguns ou todos os dados ao aplicativo principal. Nesse ponto, o aplicativo de processamento de pagamentos termina sua ação 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 estas etapas:

  • Criar uma nova conta do GCP 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 de desenvolvimento/controle de qualidade (requisito 6.4.1). Para garantir o isolamento, crie e use uma conta do GCP separada da conta do ambiente de produção principal. Os usuários com experiência na configuração do Cloud Identity and Access Management (Cloud IAM) podem conseguir isolamento equivalente usando projetos separados para trabalho dentro do escopo.

Como 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 de regras mais seguro para senhas seguras na seção 5.1.1 do NIST SP800-63B. 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 (Beta) para uma camada extra de segurança de rede. Existem 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
Encaminhamento 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 dos 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 visualizar 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 que você pode usar 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 do site 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 do software e das bibliotecas que precisam ser instalados em cada servidor no escopo do aplicativo de processamento de pagamentos. Para evitar a introdução de vulnerabilidades desnecessárias no sistema (requisito 2.2.2), inclua apenas o mínimo de software e bibliotecas que você precisa para executar o aplicativo. Os candidatos podem incluir o SDK do Cloud, bibliotecas e ambientes de execução específicos de uma 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 o 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 de 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, você pode 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. Consulte o guia de planejamento de recuperação de desastres, Como desenvolver sistemas robustos e Como criar aplicativos da Web escalonáveis e resilientes para ver orientações.

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, a sobrecarga e o risco geral da configuração manual, use uma ferramenta de gerenciamento de configuração automatizada como Skaffold, Chef, Puppet, Ansible ou Salt.

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 é uma coleção de ferramentas de código aberto orientadas à comunidade para ajudar você a melhorar a segurança de seus ambientes do GCP. 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 cria um instantâneo de inventário de seus recursos do GCP para que você tenha um registro histórico de sua arquitetura.

O Scanner usa as informações coletadas pelo Forseti Inventory para comparar regularmente as políticas de acesso baseadas em papéis aos recursos do GCP. O Scanner aplica regras para auditar recursos do GCP, como estas:

  • Políticas do Cloud Identity and Access Management (Cloud IAM) para organizações, pastas e projetos
  • ACLs de intervalo
  • 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 GCP 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 email podem enviar notificações por email para Inventory e Scanner.

Como implementar um registro de auditoria imutável

O Stackdriver produz registros de auditoria automaticamente para uma grande variedade de atividades em muitos produtos. Em longo prazo, você pode armazenar registros imutáveis com segurança usando bloqueios de intervalo do Cloud Storage (seção 10.5). Bloqueios de intervalo 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 GCP.

Como implementar os registros de fluxo de nuvem privada virtual

O serviço de registros de fluxo de VPC (Beta) é 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 Stackdriver 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 Cloud Security Command Center

Com o serviço Cloud SCC (Beta), as equipes de segurança reúnem dados, identificam ameaças e respondem a elas antes que gerem danos ou perdas à empresa. 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. Com o Cloud SCC, é possível 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 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 a ferramenta de gerenciamento de configuração para recuperar e iniciar com segurança a versão mais recente do aplicativo. É possível recuperá-lo de qualquer local, como o Cloud Storage, contanto que ele seja seguro.

Muitas das ferramentas de gerenciamento de configuração mencionadas acima aceitam fluxos de trabalho de integração e implementaçã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 denominado transparência no acesso, o Stackdriver agora oferece registros quase em tempo real quando os administradores do GCP 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. A transparência de acesso fornece informações sobre os acessos do suporte e engenharia do Google, mas a Aprovação de acesso permite que você aprove explicitamente o acesso a seus dados ou configurações no GCP 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 Platform, como intervalos do Cloud Storage, instâncias do Cloud Bigtable e conjuntos de dados do BigQuery para restringir dados em um VPC e ajudar a reduzir os riscos de exportação de dados (requisitos 1.2.1 e 1.3.4). Com os VPC Service Controls, é possível manter a privacidade dos dados confidenciais enquanto aproveita os recursos de armazenamento e processamento de dados totalmente gerenciados do Google Cloud Platform. 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 pontos de extremidade 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 podem fornecer, como registros de solicitações HTTP individuais, poderá implementar controles nas solicitações de saída de proxy ou aplicativo. Isso é feito por meio do próprio servidor proxy reverso configurado para encaminhar registros de acesso ao Stackdriver. Para ver 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 opções conhecidas para esta tarefa são OSSEC ou Tripwire (páginas em inglês).

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 provável ou em vetores de ataque para cada componente do aplicativo de processamento de pagamentos. Por exemplo, acione alertas do Monitoring se o 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

Stackdriver transmitindo registros para o Cloud Storage e o BigQuery
Stackdriver transmitindo registros para o Cloud Storage e o BigQuery

Como opção, é possível exportar os registros do Stackdriver para o BigQuery para análise posterior. Por ser otimizado para realizar consultas em grandes conjuntos de dados, o BigQuery é uma ferramenta ideal para análises de registros em grande escala. O Stackdriver pode até registrar diretamente no BigQuery os 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 chaves secretas. 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 implementado o ambiente, mas, antes que qualquer tráfego de produção passe por ele, é preciso validá-lo:

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…