Neste guia, ajudamos você a implementar o Padrão de segurança de dados do setor de cartões de pagamento (PCI DSS) 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 na 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.
Este documento se refere aos requisitos do PCI DSS 4.0, quando aplicável.
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. Este cobre 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 que podem ser consideradas quando uma entidade não pode atender a um requisito explicitamente conforme declarado, devido a restrições de negócios técnicas ou documentadas legítimas. As entidades precisam reduzir o risco associado ao requisito ao implementar esses outros controles. Consulte os Apêndices B e C dos "Controles de compensação" em Requisitos do PCI DSS e Procedimentos de Avaliação de Segurança para orientações sobre o uso de controles de compensação.
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. Os Requisitos de qualificação para avaliadores de segurança qualificados (QSA) apresentam detalhes sobre os requisitos de empresas e funcionários QSA.
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. Isso só é válido para entidades qualificadas para autoavaliação.
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.
Segundo plano
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 4.0 de nível 1, é possível que ele atenda às necessidades de conformidade com PCI DSS, seja qual for o nível de comercialidade da sua empresa. Na seção Compromisso com a conformidade, mostramos as áreas que 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 se estiver qualificado para a autoavaliação. 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. |
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. É possível fazer o download dos relatórios de conformidade com o PCI DSS do Google no Gerenciador de relatórios de conformidade. 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 compartilhada 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
Esta seção contém orientações para os serviços do Google Cloud mais usados em arquiteturas usadas para ambientes PCI DSS.
App Engine
Use as regras de firewall de entrada do App Engine e os controles de tráfego de saída.
Cloud Run
Use as configurações de entrada do Cloud Run, os VPC Service Controls e os controles de saída nos conectores da VPC. Se necessário, configure um endereço IP de saída estático.
Funções do Cloud Run
Use as configurações de rede de entrada e saída das funções do Cloud Run.
Cloud Logging
Registre interações com o Cloud Logging.
Cloud Monitoring
Monitore interações com o Cloud Monitoring.
Google Kubernetes Engine
Para informações sobre como usar o Google Kubernetes Engine para ambientes PCI DSS, consulte conformidade com o PCI DSS no GKE.
Cloud Storage
O requisito 3.5 estipula que um número de conta principal (PAN) seja protegido sempre que estiver 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:
O cliente faz as seleções dele e prossegue para finalizar a compra.
O aplicativo de finalização redireciona o cliente para um processador de pagamentos de terceiros.
O cliente preenche as informações do cartão de pagamento dele em um formulário que é fornecido e mantido pelo processador terceirizado.
O processador de pagamentos terceirizado verifica as informações e cobra ou recusa o cartão.
Depois de cuidar da transação, o processador de pagamentos terceirizado envia o cliente de volta ao app do comerciante junto com os detalhes da transação.
O app do comerciante envia uma solicitação de verificação ao processador de pagamentos para confirmar a transação.
O processador de pagamentos responde para verificar os detalhes da transação.
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:
O cliente insere as informações do cartão de pagamento em um formulário que é fornecido e mantido pela sua empresa.
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.
O processador de pagamentos terceirizado verifica as informações e cobra ou recusa o cartão.
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.
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:
O cliente insere as informações do cartão de pagamento em um formulário que é fornecido e mantido pela sua empresa.
Quando o cliente envia as próprias informações, o aplicativo de pagamento recebe as informações do formulário.
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.
O processador de pagamentos terceirizado verifica as informações e cobra ou recusa o cartão.
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.
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.
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.
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.
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.
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.
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:
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.5.3). Para garantir o isolamento, crie e use uma conta do Google Cloud separada da conta do ambiente de produção principal. Os usuários com experiência na configuração do Gerenciamento de identidade e acesso (IAM) podem conseguir isolamento equivalente usando projetos separados para o 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.2 e requisito 8.2.1). Isso é conhecido como princípio de privilégio mínimo (em inglês). Use os papéis do 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 o papel de Proprietário somente aos principais que realmente precisam de acesso raiz completo aos serviços. Consulte o Guia de segurança do IAM para 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 apps e funções semelhantes que tenham uma identidade em comum. É possível impor a segurança e o controle de acesso no nível da conta de serviço por meio dos papéis do IAM e de regras de firewall VPC.
As regras do IAM aplicadas às pastas são herdadas por todos os itens contidos nessas pastas. As permissões padrão são do tipo "negar todos" (requisito 7.2.3), e todas as regras aplicadas apenas adicionam permissões.
O requisito 8.3.6 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:
- Políticas de firewall do Cloud de última geração ou regras de firewall do Compute Engine
- Um túnel do Cloud VPN
- Um balanceador de carga de aplicativo externo
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.
Como criar regras de firewall
Use as políticas de firewall do Cloud de última geração ou as regras de firewall da VPC para restringir o tráfego de entrada para cada uma das instâncias do Compute Engine (requisitos 1.3 e 1.4). 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. Para testar seu trabalho, consulte a seção sobre geração de registros de regras de firewall mais adiante neste documento.
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
É possível usar o Cloud VPN para estabelecer um túnel VPN seguro entre o ambiente local e o ambiente de processamento de pagamentos (seções 2.2.7 e 4.2).
Como criar um balanceador de carga de aplicativo externo
Garanta a segurança do tráfego de entrada de clientes criando um balanceador de carga de aplicativo externo (seções 2.2.7 e 4.2). Para criar um balanceador de carga de aplicativo externo, você precisa do seguinte:
- 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:
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.4), inclua apenas o mínimo de software e bibliotecas necessárias para executar o aplicativo. Os candidatos podem incluir o Google Cloud CLI, bibliotecas e ambientes de execução específicos da linguagem ou um servidor da Web.
Crie uma instância do Compute Engine que use uma das imagens pré-configuradas do sistema operacional do Compute Engine.
Instale as bibliotecas e o software listados anteriormente.
Instale e configure
ntppara 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.6).Verifique se a imagem segue as práticas recomendadas para criar uma imagem segura do Compute Engine (toda a seção 2.2).
Depois de configurar a imagem de base, crie uma imagem de disco personalizada do Compute Engine a partir da sua imagem. Ela permite usar a 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 seu app usando o Terraform. Ele permite descrever todo o ambiente de processamento de pagamentos, incluindo regras de firewall, gateways, balanceadores de carga e instâncias no código.
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. 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.
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).
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.3). 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.
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, perícia forense e análise de segurança em tempo real (seção 10.2).
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 (seção 10.3).
Como integrar um sistema de detecção de intrusão
Mantenha a segurança do ambiente de processamento de pagamentos descrito na seção 11.5 usando um sistema de detecção de intrusões (IDS) e saiba 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.
O Sistema de detecção de intrusões do Cloud (Cloud IDS) é um serviço de detecção de intrusões que detecta ameaças de intrusões, malware, spyware e ataques de comando e controle à sua rede. O Cloud IDS oferece total visibilidade do tráfego de rede, incluindo norte-sul e leste-oeste, para você monitorar a comunicação entre VMs e detectar o movimento lateral. Também é possível usar o Cloud IDS para simplificar a conformidade com o requisito 11.5.
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 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.4.
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 gerenciamento de configuração mencionadas anteriormente são compatíveis com 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 (seção 11.3) e garantir que o código seja revisado ( requisito 6.2.3).
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 da 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 Aprovação de 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 Aprovação de acesso lida com isso por meio da captura quase em tempo real de registros do acesso manual e segmentado por parte do suporte ou da equipe de engenharia.
A Aprovação de acesso permite aprovar explicitamente o acesso aos seus dados ou configurações no Google Cloud antes que ele ocorra. Ela também fornece insights sobre os acessos da equipe de engenharia e do Suporte do Google.
Como ativar a geração de registros de regras de firewall
A Geração de registros de regras de firewall permite ativar a geração de registros 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 permitem definir um perímetro de segurança em torno dos recursos do Google Cloud, como buckets do Cloud Storage, instâncias do Bigtable e conjuntos de dados do BigQuery, para restringir os dados em uma rede VPC e ajudar a reduzir os riscos de exfiltração de dados (requisitos 1.3.1 e 1.3.2). 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.
Como configurar registros de fluxo de VPC
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).
O diagrama a seguir mostra como os registros de fluxo de VPC registram os fluxos de tráfego de rede enviados ou recebidos por instâncias de VM."
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 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
Opcionalmente, é possível rotear os registros do Logging para o BigQuery para analisar posteriormente. Consulte Visão geral de roteamento e armazenamento: coletores para mais detalhes. 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 inclusive a possibilidade do Logging registrar diretamente no BigQuery para registros que exigem análise quase em tempo real (requisito 10.4.1).
Como usar a Proteção de dados sensíveis para apagar 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 depois de serem apagados com a Proteção de dados sensíveis (requisito 6.5.1).
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 do administrador
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.4) 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.2.7, todo o acesso a essa ferramenta precisa usar uma forte criptografia de transporte. Use a Proteção de dados sensíveis para filtrar informações sensíveis antes de exibi-las em qualquer ferramenta de administrador.
Como usar o Cloud Key Management Service (Cloud KMS)
O Cloud KMS é um serviço que permite gerenciar chaves de criptografia. Ele pode gerar, usar, alternar e destruir chaves de criptografia AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256 e EC P384. O Cloud KMS permite remover senhas de texto simples armazenadas em código ou arquivos de configuração, o que simplifica a conformidade com as seções 2.2.2, 3.6, 3.7 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:
- Se você for um comerciante de nível 1, seu ambiente precisará ser validado por um avaliador de segurança qualificado (QSA, na sigla em inglês). Um QSA é uma empresa ou um indivíduo aprovado pelo PCI Security Standards Council para validar ambientes PCI e conceder o selo de aprovação.
- Se você for um comerciante de nível 2 ou abaixo, valide o ambiente preenchendo o questionário de autoavaliação.
A seguir
- Biblioteca de documentos do PCI DSS (em inglês)
- Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.