Este guia ajuda a saber como implementar a Norma de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS) para a sua empresa no Google Cloud. O guia vai além das diretrizes de computação na nuvem do PCI SSC (PDF) para fornecer informações gerais sobre a norma, explicar o seu papel na conformidade baseada na nuvem e, em seguida, dar-lhe as diretrizes para conceber, implementar e configurar uma app de processamento de pagamentos através do PCI DSS. O tutorial também aborda métodos para monitorizar, registar e validar a sua app.
Este documento refere-se aos requisitos da PCI DSS 4.0, quando aplicável.
A Norma de Segurança de Dados do PCI, criada pelo PCI Security Standards Council, é uma norma de segurança de informações para empresas que tratam informações de cartões de pagamento (tanto de crédito como de débito). O PCI Security Standards Council inclui todas as principais empresas de cartões de pagamento. As empresas que aceitam Visa, MasterCard, Discover, American Express, JCB ou UnionPay têm de agir em conformidade com a norma PCI DSS e podem ser multadas ou penalizadas se não o fizerem.
A PCI DSS inclui classificações para vários tipos de comerciantes, desde comerciantes que recolhem informações de pagamento pessoalmente a comerciantes que externalizam totalmente o processamento de pagamentos. Este guia abrange os tipos de comerciantes SAQ A, SAQ A-EP e SAQ D.
Objetivos
- Reveja a arquitetura da app de processamento de pagamentos.
- Configure o ambiente de processamento de pagamentos.
- Implemente e configure os servidores de apps.
- Configure o registo e a monitorização.
- Valide o seu ambiente de processamento de pagamentos.
Definições
Este guia usa muitas expressões únicas. Seguem-se alguns dos mais comuns. Para mais informações, consulte o glossário da PCI DSS.
CDE: acrónimo de ambiente de dados do titular do cartão. Esta sigla refere-se a qualquer parte da sua app que detenha ou transfira dados do titular do cartão, incluindo o número da conta de pagamentos ou quaisquer informações de identificação pessoal relacionadas com o cartão.
Controlos compensatórios: soluções alternativas que podem ser consideradas se uma entidade não conseguir cumprir um requisito explicitamente conforme indicado, devido a restrições técnicas ou empresariais legítimas documentadas. As entidades têm de mitigar suficientemente o risco associado ao requisito quando implementam estes outros controlos. Consulte os apêndices B e C de "Controlos compensatórios" nos requisitos da PCI DSS e nos procedimentos de avaliação de segurança para obter orientações sobre a utilização de controlos compensatórios.
PAN: acrónimo de primary account number e também conhecido como número de conta. É o número do cartão de pagamento exclusivo 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 PCI Security Standards Council (SSC) para realizar avaliações no local da PCI DSS. Os Requisitos de qualificação para avaliadores de segurança qualificados (QSA) fornecem detalhes sobre os requisitos para empresas e funcionários de QSA.
SAQ: acrónimo de Questionário de autoavaliação, a ferramenta de relatórios que é usada para documentar os resultados da autoavaliação da avaliação PCI DSS de uma entidade. Isto aplica-se apenas a entidades elegíveis para autoavaliação.
Âmbito: os sistemas, os procedimentos e as pessoas a incluir numa avaliação da norma PCI DSS.
Tokenização: um processo que substitui o número de conta principal (PAN) por um valor substituto denominado token. O PAN é, em seguida, armazenado numa pesquisa segura. A desconversão em tokens é o processo inverso de procurar um PAN pelo respetivo token. Um token pode ser um hash ou um valor atribuído.
Contexto
A PCI DSS fornece uma lista de requisitos concebidos para melhorar a segurança dos titulares de cartões. Estes requisitos estão divididos em doze partes numeradas principais e muitas subpartes. Este documento faz referência a estes números de peças para adicionar contexto, mas as referências das secções não são uma lista exaustiva dos requisitos aplicáveis.
Os seus requisitos de conformidade com a PCI DSS variam consoante a forma como a sua empresa processa as transações de cartões de pagamento (tipo) e o número de transações que realiza anualmente (nível).
À medida que o número de transações aumenta, o seu nível de comerciante da PCI DSS aumenta e as diretrizes de conformidade com a PCI DSS tornam-se mais rigorosas. Ao nível de comerciante mais elevado, o nível 1, a norma PCI DSS requer uma auditoria. Os níveis variam consoante a marca do cartão. O Nível 1 é definido pela American Express como 2,5 milhões de transações anuais e pela Visa, Mastercard e Discover como 6 milhões de transações anuais. Cada marca de cartão tem requisitos de nível adicionais que estão fora do âmbito deste documento. Certifique-se de que o seu ambiente de processamento de pagamentos é auditado para suportar o seu nível de comerciante.
Uma vez que Google Cloud é um fornecedor de serviços em conformidade com o Nível 1 da norma PCI DSS 4.0, pode dar resposta às suas necessidades de conformidade com a norma PCI DSS, independentemente do nível de comerciante da sua empresa. A secção Comprometidos com a conformidade indica as áreas que são cobertas pela Google.
A outra variável fundamental é o tipo de SAQ. O SAQ descreve os critérios que tem de cumprir para estar em conformidade com a PCI DSS se for elegível para a autoavaliação. O seu tipo de SAQ é determinado pela arquitetura da sua app e pela forma precisa como processa os dados dos cartões de pagamento. A maioria dos comerciantes na nuvem é uma das seguintes opções:
| Tipo de SAQ | Descrição |
|---|---|
| A | Comerciantes que subcontrataram totalmente o processamento de cartões de pagamento a um site de terceiros. Os clientes saem do seu domínio (inclusive através de um
<iframe> formulário Web), concluem o pagamento e, em seguida, regressam à sua
app.Por outras palavras, a sua empresa não pode aceder aos dados do cartão do cliente de forma alguma. |
| A-EP | Comerciantes que externalizam o processamento de pagamentos para um fornecedor externo, mas que podem aceder aos dados dos cartões dos clientes em qualquer ponto do processo. Os comerciantes que podem aceder aos dados dos cartões incluem elementos da página controlados pelo comerciante, como JavaScript ou CSS, que estão incorporados na página de pagamento de terceiros. Por outras palavras, a sua app de processamento de pagamentos encaminha os dados do cartão para um processador no lado do cliente, ou o processador renderiza qualquer conteúdo alojado por si. |
| D | Comerciantes que aceitam pagamentos online e não são elegíveis para o SAQ A nem o SAQ A-EP. Este tipo inclui todos os comerciantes que invocam uma API de processador de pagamentos a partir dos seus próprios servidores, independentemente da tokenização. Por outras palavras, se não for SAQ A nem SAQ A-EP, é SAQ D. O SAQ D distingue entre comerciantes e fornecedores de serviços. Os fornecedores de serviços não são abordados neste documento e todas as referências à SAQ D dirigem-se aos comerciantes, conforme definido na PCI DSS. |
Comprometidos com a conformidade
A Google utiliza várias tecnologias e processos para proteger as informações armazenadas nos servidores da Google. A Google validou de forma independente os requisitos da norma PCI DSS que se aplicam às Google Cloud tecnologias e infraestrutura Google Cloud geridas pela Google. Pode transferir os relatórios de conformidade com a norma PCI DSS da Google a partir do Gestor de relatórios de conformidade. Embora a Google ofereça aos comerciantes um grande controlo sobre as respetivas instâncias de computação executadas na infraestrutura da Google, a Google não controla a segurança do sistema operativo, dos pacotes nem das apps que os comerciantes implementam no Google Cloud. É da sua responsabilidade agir em conformidade com os requisitos da norma PCI DSS para os pacotes do sistema operativo e as apps que implementa, além de outras personalizações exigidas pela sua arquitetura.
Google Cloud Segue os requisitos da PCI DSS estabelecidos para um fornecedor de serviços de nível 1 e todos os requisitos de fornecedores de serviços aplicáveis. A Google Cloud matriz de responsabilidade partilhada descreve as obrigações de conformidade da PCI DSS. A matriz de responsabilidades pode ser uma referência útil à medida que procura a conformidade com a PCI DSS e realiza as suas próprias auditorias PCI DSS.
Orientação sobre produtos
Esta secção contém orientações para os Google Cloud serviços usados frequentemente em arquiteturas usadas para ambientes PCI DSS.
App Engine
Use regras de firewall de entrada do App Engine e controlos de tráfego de saída.
Cloud Run
Use as definições de entrada do Cloud Run, os VPC Service Controls e os controlos de saída nos conetores de VPC. Se necessário, configure um endereço IP estático de saída.
Funções do Cloud Run
Use as definições de rede de entrada e saída das funções do Cloud Run.
Cloud Logging
Registe interações com o Cloud Logging.
Cloud Monitoring
Monitorize as interações com o Cloud Monitoring.
Google Kubernetes Engine
Para obter informações sobre a utilização do Google Kubernetes Engine para ambientes PCI DSS, consulte o artigo Conformidade com a PCI DSS no GKE.
Cloud Storage
O requisito 3.5 estipula que um número de conta principal (PAN) está protegido onde quer que seja armazenado. Embora a Google ofereça automaticamente a encriptação em repouso, não realiza automaticamente hashes unidirecionais, truncagem nem tokenização, que as regras também exigem.
Exemplos de arquiteturas
Esta secção ilustra as abordagens para implementar um ambiente que esteja em conformidade com a SAQ A, a SAQ A-EP e a SAQ D.
Vista geral da arquitetura
SAQ A
O SAQ A é a arquitetura de processamento de pagamentos mais básica. Os pagamentos são processados por terceiros, e as apps ou as páginas do comerciante não acedem aos dados dos cartões.
A um nível elevado, o fluxo de processamento de pagamentos é o seguinte:
O cliente faz as suas seleções e avança para o pagamento.
A app de pagamento redireciona o cliente para um processador de pagamentos de terceiros.
O cliente introduz as informações do seu cartão de pagamento num formulário de pagamento que o processador de terceiros detém e mantém.
O processador de pagamentos de terceiros verifica as informações do cartão de pagamento e, em seguida, cobra ou recusa o cartão.
Após o processamento da transação, o processador de pagamentos de terceiros envia o cliente de volta para a app do comerciante juntamente com os detalhes da transação.
A app do comerciante envia um pedido de validação ao processador de pagamentos para confirmar a transação.
O processador de pagamentos responde para validar os detalhes da transação.
SAQ A-EP
A arquitetura de processamento de pagamentos SAQ A-EP centra-se numa app de processamento de pagamentos executada em instâncias de máquinas virtuais do Compute Engine. Estas instâncias encontram-se numa rede privada segura e usam canais seguros para comunicar com serviços que estão fora da rede.
A um nível elevado, o fluxo de processamento de pagamentos é o seguinte:
O cliente introduz as informações do respetivo cartão de pagamento num formulário de pagamento que a sua empresa detém e mantém.
Quando o cliente envia as respetivas informações, estas são transmitidas de forma segura a um processador de pagamentos de terceiros.
O processador de pagamentos de terceiros verifica as informações do cartão de pagamento e, em seguida, cobra ou recusa o cartão.
O processador de pagamentos envia uma resposta à sua app de pagamentos, que, em seguida, transmite uma mensagem à sua app principal.
Todas estas interações são registadas e monitorizadas com o Cloud Logging e o Cloud Monitoring.
SAQ D
A arquitetura de processamento de pagamentos SAQ D centra-se numa app de processamento de pagamentos executada em instâncias de máquinas virtuais do Compute Engine. Estas instâncias encontram-se numa rede privada segura e usam canais seguros para comunicar com serviços que estão fora da rede.
A um nível elevado, o fluxo de processamento de pagamentos é o seguinte:
O cliente introduz as informações do respetivo cartão de pagamento num formulário de pagamento que a sua empresa detém e mantém.
Quando o cliente envia as respetivas informações, a sua app de pagamento recebe as informações do formulário.
A sua app de pagamentos valida as informações de pagamento e transmite-as em segurança a um processador de pagamentos de terceiros através de uma API de back-end.
O processador de pagamentos de terceiros verifica as informações do cartão de pagamento e, em seguida, cobra ou recusa o cartão.
O processador de pagamentos envia uma resposta à sua app de pagamentos, que, em seguida, transmite uma mensagem à sua app principal.
Todas estas interações são registadas e monitorizadas com o Registo e a Monitorização.
Fluxo de processamento de pagamentos virado para o cliente
SAQ A
Esta secção descreve o fluxo de processamento de pagamentos de terceiros na perspetiva dos clientes que usam a sua app.
Quando o cliente acede ao seu formulário de pagamento, a app apresenta um
<iframe> alojado pelo processador de pagamentos. A sua app não pode aceder nem monitorizar o conteúdo do
<iframe> devido a
limitações de partilha de recursos de origem cruzada.
Quando o cliente envia as informações do respetivo cartão de pagamento, o processador de pagamentos aceita ou recusa o cartão e, em seguida, envia o cliente de volta para a sua app. Em seguida, a sua app verifica a resposta da transação do processador de pagamentos e age em conformidade. A sua app não acedeu nem
tratou informações de cartões de pagamento.
SAQ A-EP
Esta secção descreve o mesmo fluxo de processamento de pagamentos interno descrito anteriormente, mas na perspetiva dos clientes que usam a sua app.
Quando o cliente acede ao URL do seu formulário de pagamento, o site apresenta um formulário alojado pela sua app de pagamento. Quando o cliente envia as informações do cartão de pagamento, o formulário é enviado diretamente para o processador de pagamentos. O processador aceita ou recusa o cartão e, em seguida, envia o cliente de volta para a sua app. Em seguida, a app verifica a resposta da transação do processador de pagamentos e age em conformidade. O cliente pode não ver o processador de pagamentos de terceiros, mas a sua app não acedeu a nenhuma informação do cartão de pagamento no lado do servidor.
SAQ D
Esta secção descreve o fluxo de processamento de pagamentos interno na perspetiva dos clientes que usam a sua app.
Quando o cliente acede ao URL do seu formulário de pagamento, é encaminhado de forma segura para o formulário através de um equilibrador de carga HTTPS. Quando o cliente envia as informações do cartão de pagamento, a sua app de processamento de pagamentos envia as informações de forma segura para um processador de pagamentos de terceiros. O processador de pagamentos de terceiros aceita ou recusa o cartão e, em seguida, devolve uma resposta à sua app de processamento de pagamentos.
Fluxo interno de processamento de pagamentos
SAQ A e A-EP
Esta secção descreve o fluxo de processamento de pagamentos na perspetiva dos servidores que executam a sua app.
A sua app de processamento de pagamentos recebe e analisa a resposta devolvida pelo processador de pagamentos de terceiros e, em seguida, envia alguns ou todos os dados de resposta para a app principal. Neste momento, a sua app de processamento de pagamentos concluiu a transação. A app principal processa a tarefa de notificar os seus clientes.
SAQ D
Esta secção descreve o fluxo de processamento de pagamentos interno na perspetiva dos servidores que executam a sua app.
A sua app de processamento de pagamentos valida as informações do cartão de pagamento enviadas pelo cliente e, em seguida, envia-as para o processador de pagamentos através de uma API de back-end. O processador tenta a cobrança e responde com os detalhes da transação. A sua app recebe e processa a resposta e, em seguida, envia alguns ou todos os dados de resposta para a app principal. Neste ponto, a sua app de processamento de pagamentos concluiu a transação. A app principal processa a tarefa de notificar o seu cliente e entregar o produto.
Monitorização e registo do fluxo de dados
O fluxo de monitorização e registo foi concebido da seguinte forma:
Configurar o ambiente de processamento de pagamentos
Esta secção descreve como configurar o seu ambiente de processamento de pagamentos. A configuração inclui o seguinte:
- Criar uma nova Google Cloud conta para isolar o seu ambiente de processamento de pagamentos do ambiente de produção.
- Restringir o acesso ao seu ambiente.
- Configurar os recursos virtuais.
- Conceber a imagem base do Linux que vai usar para configurar os seus servidores de apps.
- Implementar uma solução de gestão de pacotes segura.
Configurar uma nova conta
Para simplificar a restrição de acesso e a auditoria de conformidade, crie um ambiente de processamento de pagamentos de qualidade de produção totalmente isolado do seu ambiente de produção padrão e de quaisquer ambientes de desenvolvimento e controlo de qualidade (requisito 6.5.3). Para garantir o isolamento, crie e use uma Google Cloud conta separada da conta do seu ambiente de produção principal. Os utilizadores com experiência na configuração da gestão de identidade e de acesso (IAM) podem alcançar um isolamento equivalente através da utilização de projetos separados para o trabalho no âmbito.
Restringir o acesso ao seu ambiente
Permita o acesso ao ambiente de processamento de pagamentos apenas a indivíduos que implementem o código do seu sistema de pagamentos ou geram as máquinas do seu sistema de pagamentos (secção 7.2 e requisito 8.2.1). Isto é conhecido como o princípio do menor privilégio. Use funções da IAM para restringir o acesso. As práticas recomendadas incluem a utilização de funções sempre que possível, a concessão apenas das autorizações necessárias para realizar o trabalho esperado e a concessão da função de proprietário apenas a responsáveis que necessitem legitimamente de acesso root total aos seus serviços. Consulte o guia de segurança do IAM para mais informações.
O acesso automatizado a qualquer serviço gerido deve basear-se em contas de serviço. As contas de serviço simplificam o ciclo de vida de gestão de apps, oferecendo-lhe uma forma de gerir a autenticação e a autorização de apps. Estas contas oferecem-lhe uma forma flexível, mas segura, de agrupar instâncias de máquinas virtuais com apps e funções semelhantes que têm uma identidade comum. Pode aplicar a segurança e o controlo de acesso ao nível da conta de serviço através de funções da IAM e de regras de firewall da VPC.
As regras da IAM que aplica às pastas são herdadas por todos os itens contidos nessa pasta. As autorizações predefinidas são de recusa total (requisito 7.2.3) e todas as regras que aplica apenas adicionam autorizações.
O requisito 8.3.6 fornece algumas regras básicas para as palavras-passe dos utilizadores. O Instituto Nacional de Padrões e Tecnologia (NIST) define um conjunto de regras mais seguro para palavras-passe seguras na secção 5.1.1 da NIST SP800-63B. A Google recomenda que siga as diretrizes de identidade digital do NIST sempre que possível.
A secção 12.7 da SAQ D da PCI DSS exige que os indivíduos com acesso ao seu ambiente no âmbito da norma passem uma verificação de antecedentes, em conformidade com as leis locais, antes de lhes ser concedido acesso ao ambiente. Para reduzir o risco de violações de conformidade, considere realizar estas verificações de antecedentes criminais e verificações de referências em cada indivíduo, independentemente do seu tipo de conformidade.
Proteger a sua rede
Para proteger o tráfego de entrada e saída para e a partir da sua rede de apps de processamento de pagamentos, tem de criar o seguinte:
- Políticas de firewall de nova geração da nuvem ou regras de firewall do Compute Engine
- Um túnel do Cloud VPN
- Um balanceador de carga de aplicações externo
Para criar a sua VPC, também recomendamos o Cloud NAT para uma camada adicional de segurança de rede. Existem muitas opções poderosas disponíveis para proteger as redes das instâncias do Compute Engine e do GKE.
Criar regras de firewall
Use políticas da firewall de próxima geração da nuvem ou regras de firewall da VPC para restringir o tráfego de entrada a cada uma das suas instâncias do Compute Engine (requisitos 1.3 e 1.4). Permita o tráfego de entrada apenas das seguintes três origens:
- HTTPS público, para que os clientes possam aceder à sua página de pagamento.
- A sua rede de apps, para que a app de processamento de pagamentos possa receber respostas do seu processador de pagamentos de terceiros.
- A sua rede de escritório interna, para que possa aceder às instâncias para fins de auditoria e gestão.
Use regras de firewall em instâncias individuais para restringir o tráfego de saída. Pode implementar estas regras localmente com o iptables ou, de forma mais abrangente, usando regras de firewall da VPC e etiquetas de rede. Permita o tráfego de saída apenas do seu formulário de pagamentos para o processador de pagamentos de terceiros. Esta ligação tem de ser apenas HTTPS. Para testar o seu trabalho, consulte a secção sobre o registo de regras de firewall mais adiante neste documento.
O Cloud DNS oferece zonas DNS privadas para que possa atribuir nomes de anfitriões de forma segura no seu CDE sem o potencial de divulgação de dados confidenciais da topologia de rede ao 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 de terceiros | tcp:443 | Entrada Acesso público à app de processamento de pagamentos |
| Formulário de pagamento de terceiros | Processador de pagamentos de terceiros | tcp:443 | Saída Encaminhamento de pedidos AUTH para o fornecedor de serviços de pagamento |
| Processador de pagamentos de terceiros | A sua app de processamento de pagamentos | tcp:5480 | Entrada Aceitar pedidos AUTH de sistemas de pagamento (não contém dados de titulares de cartões) |
| A rede do escritório da sua empresa | vpn-gateway | tcp:8000 | Entrada Acesso ao ambiente de processamento de pagamentos para acesso a registos e máquinas de desenvolvimento |
Além disso, o seguinte tráfego ocorre de forma segura na rede interna da app de processamento de pagamentos:
| Origem | Destino | Porta | Motivo |
|---|---|---|---|
| Formulário de cartão | Proxy PCI | tcp:5480 | Troca de dados do cartão encriptados por um token do meio de pagamento |
| Todos os anfitriões | Servidores NTP da Google | udp:123 | Sincronização de tempo |
| Gateway de VPN | Todos os anfitriões | tcp:22 | Ligações Secure Shell (SSH) |
Estabelecer um túnel de VPN seguro
Pode usar o Cloud VPN para estabelecer um canal de VPN seguro entre o seu ambiente no local e o seu ambiente de processamento de pagamentos (secções 2.2.7 e 4.2).
Criar um balanceador de carga de aplicações externo
Pode ajudar a garantir que o tráfego de clientes recebido é seguro criando um equilibrador de carga de aplicações externo (secções 2.2.7 e 4.2). Para criar um Application Load Balancer externo, precisa do seguinte:
- Um subdomínio do seu Website que é usado para o formulário de processamento de pagamentos, por exemplo,
payments.your-domain-name.com. - Um certificado SSL válido e assinado que tenha sido registado para o seu subdomínio.
Certifique-se de que o seu domínio é válido consultando as respetivas definições de DNS na interface de configuração do domínio do registador Web.
Criar uma imagem base do Linux
A PCI DSS contém requisitos que descrevem como configurar máquinas que fazem parte de uma arquitetura de processamento de pagamentos em conformidade. Pode implementar estes requisitos de várias formas, mas a abordagem mais fácil é a seguinte:
Crie uma lista do software e das bibliotecas que têm de ser instalados em cada servidor que esteja no âmbito da sua app 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 de que precisa para executar a sua app. Os candidatos podem incluir a CLI do Google Cloud, os tempos de execução e as bibliotecas específicos do idioma ou um servidor Web.
Crie uma instância do Compute Engine que use uma das imagens do sistema operativo pré-configuradas do Compute Engine.
Instale as bibliotecas e o software que listou anteriormente.
Instale e configure o
ntppara manter os relógios do sistema sincronizados. A gestão dos relógios do servidor com o Network Time Protocol garante a integridade das datas/horas nos registos (secção 10.6).Certifique-se de que a imagem segue as práticas recomendadas para criar uma imagem segura do Compute Engine (toda a secção 2.2).
Depois de configurar a imagem base, crie uma imagem de disco personalizada do Compute Engine a partir da sua imagem. Esta imagem permite-lhe usar a sua imagem Linux base quando cria instâncias de máquinas virtuais.
Usar gestão de pacotes segura
A gestão de pacotes é um componente fundamental de um ambiente de alojamento com segurança reforçada. De acordo com a secção 2.2, tem de implementar normas de reforço aceites pela indústria. A menos que use o SO otimizado para contentores da Google, é provável que tenha um gestor de pacotes instalado, como o RPM, o Yum ou o Apt. A sua app pode usar o seu próprio gestor de pacotes específico da linguagem de programação, como o NPM, o PyPi ou o Composer, e transferir dependências na primeira execução.
Se a sua app puder obter atualizações da Internet, tem de tratar as origens das atualizações como um potencial risco de segurança. Os ataques do lado da oferta ou a montante, que são incluídos maliciosamente em pacotes alojados publicamente, estão a tornar-se mais comuns. Imagine os efeitos da instalação de uma atualização do SSH que contenha código malicioso.
Pode mitigar o risco de ataques do lado da oferta criando uma lista de destinatários seguros para os seus pacotes e verificando se correspondem à lista. Mantenha uma lista dos números de versão testados e aprovados para cada pacote que usa. Registe o número da versão juntamente com o respetivo hash ou assinatura. Certifique-se de que o gestor de pacotes valida o hash ou a assinatura antes de instalar ou atualizar uma app.
A maioria dos sistemas de gestão de pacotes permite o alojamento privado. Se possível, inicie o seu próprio servidor de gestão de pacotes privado e aloje apenas software testado e aprovado. Bloqueie o gestor de pacotes para que não possa contactar outros servidores para atualizações.
Idealmente, o processo de compilação da app obtém e valida todos os pacotes e, em seguida, cria uma revisão da imagem de disco personalizada que inclui tudo o que o contentor precisa. Desta forma, os seus servidores são iniciados e dimensionados sem atrasos na instalação, e existe uma menor probabilidade de erros aleatórios no momento do lançamento. Também pode rever qualquer versão anterior da sua app exatamente como estava em produção iniciando a respetiva imagem, o que pode ser útil para diagnósticos e análise forense.
Implementação e configuração
Em seguida, configure a implementação e a configuração das suas instâncias a partir da imagem base.
Implementar o seu ambiente
Para cumprir os requisitos da norma PCI DSS, certifique-se de que implementa sempre a app correta, que a implementa de forma segura e que não instala outros pacotes de software durante a implementação. Para simplificar o processo de implementação, considere criar uma implementação automática para a sua app através do Terraform. O Terraform permite-lhe descrever todo o seu ambiente de processamento de pagamentos, incluindo as respetivas regras de firewall, gateways, balanceadores de carga e instâncias em código.
Numa implementação automatizada, tem de validar a integridade do software que está a ser implementado, quer seja de terceiros ou seu. Pode validar o software executando um hash automático em cada pacote à medida que o pacote é instalado. Depois de validar um hash, pode usar uma framework de testes automatizada para executar testes de segurança e outros testes, e para verificar se os testes foram aprovados.
Por último, quando implementar instâncias do Compute Engine, crie um plano de recuperação caso as instâncias falhem. Se a sua janela de tempo de inatividade aceitável for suficientemente grande, um plano de recuperação manual pode ser suficiente. Caso contrário, tem de criar um plano de recuperação automático. Consulte o Guia de planeamento de recuperação de desastres, Conceber sistemas robustos e Criar apps Web escaláveis e resilientes para receber orientações.
Configurar o seu ambiente
Depois de as instâncias terem sido implementadas, certifique-se de que estão configuradas corretamente. Instale software e bibliotecas adicionais na imagem base de cada instância, conforme necessário. Para evitar a complexidade, os custos gerais e o risco geral da configuração manual, use uma ferramenta de gestão de configuração automatizada, como o Skaffold, o Chef, o Puppet, o Ansible ou o Salt.
Implementar o registo de auditoria imutável
O registo produz registos de auditoria automaticamente para uma grande variedade de atividades em muitos produtos. A longo prazo, pode armazenar registos imutáveis em segurança através de bloqueios de contentores do Cloud Storage (secção 10.3). Os bloqueios de contentores permitem-lhe definir uma política para tornar todos os objetos imutáveis e não elimináveis durante um período especificado, que pode variar entre segundos e anos.
Implementar registos de fluxo da nuvem virtual privada
O serviço VPC Flow Logs foi concebido para registar fluxos de rede enviados ou recebidos por instâncias de máquinas virtuais. Pode usar estes registos para monitorização de rede, análise forense e análise de segurança em tempo real (secção 10.2).
Instalar o agente de registos
Depois de configurar o iptables nos seus servidores, cada servidor regista todas as atividades no armazenamento de blocos do servidor. Consulte a página de preços de Registo para ver detalhes sobre a atribuição gratuita e os preços de transferência de dados. Para reter estes registos e gerar alertas com base em atividade suspeita, transmita-os para o Logging and Monitoring instalando o agente de registo em cada servidor (secção 10.3).
Integrar um sistema de deteção de intrusões
Para ajudar a garantir a segurança do seu ambiente de processamento de pagamentos, descrito na secção 11.5, use um sistema de deteção de intrusões (IDS), para saber quando os autores de ataques tentam atacar o sistema. Existem duas formas de colocar um IDS num ambiente de processamento de pagamentos: colocar um IDS em todos os pontos de entrada ou instalar um IDS em todos os servidores.
Para reduzir a complexidade da arquitetura do seu ambiente e simplificar a conformidade com o ponto 11.5, instale um IDS em cada servidor. Depois de pesquisar e escolher o software IDS a usar, torne a instalação do IDS parte do script de instalação de arranque para cada servidor.
O Cloud Intrusion Detection System (Cloud IDS), um serviço de deteção de intrusões, oferece deteção de ameaças para intrusões, software malicioso, spyware e ataques de comando e controlo na sua rede. O Cloud IDS oferece visibilidade total do tráfego de rede, incluindo o tráfego norte-sul e leste-oeste, o que lhe permite monitorizar a comunicação de VM para VM para detetar o movimento lateral. Também pode usar o Cloud IDS para simplificar a conformidade com o requisito 11.5.
Os registos de IDS estão no âmbito da conformidade com a PCI DSS e têm de ser enviados para o registo e a monitorização para fins de relatórios, alertas e auditorias.
Implementar o Security Command Center
O Security Command Center ajuda as equipas de segurança a recolher dados, identificar ameaças e responder a ameaças antes que resultem em danos ou perdas para a empresa. Oferece estatísticas detalhadas sobre o risco de apps e dados para que possa mitigar rapidamente as ameaças aos seus recursos na nuvem e avaliar o estado geral. Com o Security Command Center, pode ver e monitorizar um inventário dos seus recursos na nuvem, analisar os sistemas de armazenamento em busca de dados confidenciais, detetar vulnerabilidades Web comuns e rever os direitos de acesso aos seus recursos críticos, tudo a partir de um único painel de controlo centralizado. Pode ajudar a agir em conformidade com vários requisitos, incluindo as secções 5 e 6.4.
Automatizar a implementação da sua app
Crie a sua ferramenta de gestão de configuração para obter e iniciar em segurança a versão mais recente da sua app. A app pode ser obtida a partir de qualquer localização, como o Cloud Storage, desde que essa localização seja segura.
Muitas das ferramentas de gestão de configuração mencionadas anteriormente suportam fluxos de trabalho de integração e implementação contínuas (CI/CD), que também podem ser usados para realizar análises automatizadas (secção 11.3) e garantir que o código é revisto (requisito 6.2.3).
Capturar registos do gestor de configuração
Quando configurar o gestor de configuração, certifique-se de que regista todos os detalhes de instalação. Após concluir o processo de configuração, certifique-se de que envia os registos para o Logging and Monitoring.
Registo e monitorização
Para garantir a conformidade com a PCI DSS ao abrigo da secção 10, certifique-se de que todos os passos dados no seu ambiente de processamento de pagamentos são monitorizados e registados. Todas as atividades do servidor em todas as instâncias têm de ser registadas e todas as ações do utilizador têm de poder ser examinadas posteriormente.
Ativar a Transparência de acesso
Através da Transparência de acesso, o registo oferece agora registos quase em tempo real quando os Google Cloud administradores acedem ao seu conteúdo. Os registos de auditoria do Google Cloud já oferecem visibilidade das ações dos seus próprios administradores. No entanto, esta trilha de auditoria exclui normalmente as ações realizadas pela equipa de apoio técnico ou de engenharia do seu fornecedor de nuvem. Por exemplo, antes do registo da Aprovação de acesso, se abrisse um pedido junto do apoio técnico da Google que exigisse acesso a dados, este não seria monitorizado nos registos de auditoria do Cloud. A Aprovação de acesso colmata essa lacuna, captando registos quase em tempo real do acesso manual e segmentado por parte do apoio técnico ou da engenharia.
A aprovação de acesso permite-lhe aprovar explicitamente o acesso aos seus dados ou configurações no Google Cloudantes de esse acesso ocorrer. A aprovação de acesso também fornece estatísticas sobre os acessos por parte do Apoio técnico e da engenharia da Google.
Ativar o registo de regras de firewall
O registo de regras de firewall permite-lhe ativar o registo ao nível da regra individual. Pode registar ligações TCP e UDP numa VPC para quaisquer regras que crie. Estas podem ser úteis para auditar o acesso à rede ou fornecer um aviso antecipado de que a rede está a ser usada de forma não aprovada.
Usar os VPC Service Controls
Os VPC Service Controls permitem-lhe definir um perímetro de segurança em torno de Google Cloud recursos como contentores do Cloud Storage, instâncias do Bigtable e conjuntos de dados do BigQuery para restringir os dados numa rede VPC e ajudar a mitigar os riscos de exfiltração de dados (requisitos 1.3.1 e 1.3.2). Com os VPC Service Controls, pode manter os seus dados confidenciais privados enquanto tira partido das capacidades de armazenamento e processamento de dados totalmente geridas do Google Cloud.
Configurar os registos de fluxo da VPC
Os registos de fluxo da VPC registam os fluxos de tráfego de rede enviados ou recebidos por instâncias de VMs. Os registos são úteis ao abrigo da norma PCI DSS para monitorização, auditoria, análise forense e análise de segurança em tempo real. Cada sub-rede da rede VPC pode ter os registos de fluxo ativados ou desativados de forma independente. Pode minimizar a quantidade de dados de registo ativando apenas os registos de fluxo na sua CDE no âmbito. Os registos de fluxo, combinados com regras de firewall de saída, permitem-lhe limitar o tráfego de saída para pontos finais autorizados de uma forma auditável e difícil de contornar (requisitos 1.2.1 e 1.3.4).
O diagrama seguinte mostra como os registos de fluxo da VPC registam os fluxos de tráfego de rede enviados ou recebidos por instâncias de VMs."
Se precisar de dados mais detalhados do que os registos de fluxo podem fornecer, como o registo de pedidos HTTP individuais, pode implementar controlos na sua app ou pedidos de saída de proxy. Isto é feito através do seu próprio servidor de proxy inverso configurado para encaminhar os registos de acesso para o Logging. Para ver instruções sobre como configurar um servidor proxy Squid no Compute Engine, consulte o artigo Configurar um proxy de rede. Para evitar gargalos, configure, pelo menos, dois servidores proxy redundantes.
Registo de dados de acesso interno
Além de registar ameaças externas, também deve monitorizar e registar a atividade de indivíduos que tenham acesso de administrador ao seu ambiente de processamento de pagamentos (secção 10.2). Para o fazer, pode registar comandos de shell. Várias ferramentas de código aberto podem auditar comandos de shell e enviá-los para o registo. As escolhas populares para esta tarefa incluem OSSEC ou Tripwire.
Configurar alertas de monitorização
Configure a monitorização para enviar alertas se algo correr mal no seu ambiente de processamento de pagamentos (secção 10.6). Certifique-se de que os seus alertas abrangem eventos ambientais, de auditoria e de apps internas. Baseie a sua estratégia de alertas no potencial risco ou vetores de ataque para cada componente da sua app de processamento de pagamentos. Por exemplo, acione alertas de monitorização se o seu IDS detetar tentativas de intrusão, quer sejam bem-sucedidas ou não. Também pode usar o registo de regras da firewall para acionar alertas em resposta a tentativas de violar políticas de rede específicas.
Streaming de registos para o BigQuery
Opcionalmente, pode encaminhar os registos do Logging para o BigQuery para análise posterior. Consulte o artigo Vista geral do encaminhamento e armazenamento: destinos para obter detalhes. Uma vez que o BigQuery está otimizado para consultar grandes conjuntos de dados, é uma ferramenta ideal para a análise de registos em grande escala. O registo pode até ser feito diretamente no BigQuery para registos que requerem análise quase em tempo real (requisito 10.4.1).
Usar a Proteção de dados confidenciais para limpar dados
Existem muitos motivos para usar partes dos dados contidos na sua app no âmbito que não estão, por si só, no âmbito, como para estatísticas ou desenvolvimento. Conceda às apps acesso aos dados de PCI apenas depois de terem sido limpos com a proteção de dados confidenciais (requisito 6.5.1).
Segurança das apps
Para ajudar a proteger a sua app, tem de avaliar primeiro a interface do administrador. Também pode usar o Cloud Key Management Service.
Avaliar a interface do administrador
A maioria das apps de comércio eletrónico tem a sua própria interface de administrador não pertencente à consola, como um portal de faturação do serviço de apoio ao cliente. Essa ferramenta tem de ter controlos de acesso robustos, tem de ter acesso individualizado que use a autenticação multifator (secção 8.4) e tem de ser instrumentada com registo de auditoria (secção 10.2).
Todos os registos que criar devem responder a estas perguntas: quem fez o quê? Onde é que o fizeram? Quando o fez? De acordo com a secção 2.2.7, todo o acesso a essa ferramenta tem de usar uma encriptação de transporte forte. Use a proteção de dados confidenciais para filtrar informações confidenciais antes de as apresentar em qualquer ferramenta de administração.
Usar o Cloud Key Management Service (Cloud KMS)
O Cloud KMS é um serviço que lhe permite gerir chaves de encriptação. Pode gerar, usar, rodar e destruir chaves de encriptação AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256 e EC P384. O Cloud KMS permite-lhe remover palavras-passe em texto não codificado armazenadas em código ou ficheiros de configuração, o que simplifica a conformidade com as secções 2.2.2, 3.6, 3.7 e 8.2.
Validar o seu ambiente
Após a implementação do ambiente, mas antes de qualquer fluxo de tráfego de produção, tem de validar o ambiente:
- Se for um comerciante de Nível 1, o seu ambiente tem de ser validado por um Avaliador de Segurança Qualificado (QSA). 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 for um comerciante de nível 2 ou inferior, pode validar o seu ambiente preenchendo o questionário de autoavaliação.
O que se segue?
- Biblioteca de documentos PCI DSS
- Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.