Guia de configuração do PCI para nuvem pública de borda

Você está visualizando a documentação do Apigee Edge.
Acesse a documentação da Apigee X.
info

Para que um cliente seja compatível com o PCI na nuvem pública do Apigee Edge, há algumas ações e processos que o cliente possui no "Modelo de responsabilidade compartilhada". Os itens a seguir precisam ser revisados pelos clientes que compraram o pacote de compliance com a PCI e precisam estar em compliance com a PCI. Esses itens são de autoatendimento no Edge e precisam ser abordados para que a organização do cliente (org) esteja em conformidade com a PCI. O conceito geral é "O Google protege a plataforma, o cliente protege seus dados".

Matriz de responsabilidade do cliente

Os clientes precisam consultar a Matriz de responsabilidade do PCI-DSS 3.2.1 do Google Apigee e compartilhá-la com o avaliador de segurança qualificado do PCI ao realizar a própria auditoria do PCI.

Mapeamento de requisitos de PCI

Requisito de PCI Section
Requisito 7: restringir o acesso aos dados do titular do cartão por necessidade de saber corporativa

Uso/autorizações

Requisito 3: proteger os dados armazenados do titular do cartão

Mascaramento de dados

Requisito 10: rastrear e monitorar todo o acesso a recursos de rede e dados do titular do cartão

Trilha de auditoria

Requisito 8: atribuir um ID exclusivo a cada pessoa com acesso ao computador

Requisitos de senha complexa ou SAML

Requisito 11: testar regularmente os sistemas e processos de segurança

Verificação de endpoints

Requisito 4: criptografar a transmissão de dados do titular do cartão em redes públicas abertas

Configuração de TLS

Requisito 3: proteger os dados armazenados do titular do cartão

Armazenamento de dados

Requisito 4: criptografar a transmissão de dados do titular do cartão em redes públicas abertas

Criptografia de dados

Para conseguir um atestado de conformidade (AOC, na sigla em inglês) com a norma de segurança de dados de PCI, abra um tíquete com o suporte da Apigee ou entre em contato com a equipe de vendas da Apigee.

Rastrear / depurar

O Trace/Debug é uma ferramenta de solução de problemas que permite ao usuário visualizar o status e o conteúdo de uma chamada de API conforme ela é processada pelo processador de mensagens da Apigee. Trace e Debug são dois nomes para o mesmo serviço, mas acessados por mecanismos diferentes. Trace é o nome desse serviço na interface do Edge. O depurador é o nome do mesmo serviço quando usado em chamadas de API. O uso do termo "Trace" neste documento é válido para "Trace" e "Debug".

Durante uma sessão de rastreamento, o "mascaramento de dados" é aplicado. Essa ferramenta pode impedir a exibição de dados durante um rastreamento. Consulte a seção Mascaramento de dados abaixo.

Os mapas de valores-chave (KVMs) criptografados podem ser usados para clientes PCI. Se uma KVM criptografada estiver em uso, o Trace ainda poderá ser usado, mas algumas variáveis não vão aparecer na tela de exibição do Trace. É possível seguir outras etapas para mostrar essas variáveis durante um trace.

Confira instruções detalhadas sobre o uso do Trace em Como usar a ferramenta Trace.

Confira detalhes sobre KVMs, incluindo KVMs criptografadas, em Como trabalhar com mapas de chave-valor.

Uso/autorizações

O acesso ao Trace é gerenciado pelo sistema de controle de acesso baseado em função (RBAC) para contas de usuário no Edge. Instruções detalhadas sobre como usar o sistema RBAC para conceder e revogar privilégios do Trace estão disponíveis em Atribuição de papéis e Criação de papéis personalizados na IU. Com as permissões de rastreamento, o usuário pode iniciar e interromper um rastreamento e acessar a saída de uma sessão de rastreamento.

Como o Trace tem acesso ao payload das chamadas de API (formalmente chamado de "Corpo da mensagem"), é importante considerar quem tem acesso para executar um Trace. Como o gerenciamento de usuários é de responsabilidade do cliente, a concessão de permissões de rastreamento também é de responsabilidade do cliente. A Apigee, como proprietária da plataforma, pode adicionar um usuário a uma organização de cliente e atribuir os privilégios. Essa capacidade só é usada quando o cliente solicita suporte em uma situação em que parece que o atendimento ao cliente está falhando e a análise de uma sessão de rastreamento é considerada a melhor informação sobre a causa raiz.

Mascaramento de dados

O mascaramento de dados impede a exibição de dados confidenciais apenas durante uma sessão de rastreamento/depuração, tanto na ferramenta de rastreamento (interface do Edge) quanto no back-end pela depuração (API do Edge). Confira detalhes sobre como configurar o mascaramento em Mascaramento e ocultação de dados. O mascaramento de dados sensíveis faz parte do Requisito 3 de PCI: proteger os dados armazenados do titular do cartão.

O mascaramento de dados NÃO impede que os dados fiquem visíveis em arquivos de registro, cache, análises etc. Para receber ajuda com o mascaramento de dados em registros, adicione um padrão de regex ao arquivo logback.xml. Os dados sensíveis geralmente não devem ser gravados em cache ou análises sem uma forte justificativa comercial e uma revisão feita pelas equipes de segurança do cliente e jurídicas.

Cache L1 e L2

O armazenamento em cache está disponível para clientes do PCI apenas para uso com dados não regulamentados. O cache não deve ser usado para dados do titular do cartão (CHD, na sigla em inglês) do PCI. Ele não é aprovado pela auditoria de compliance do PCI da Apigee como um local de armazenamento para CHD. De acordo com as orientações do PCI (Requisito 3: proteger os dados armazenados do titular do cartão) , os dados do PCI devem ser armazenados apenas em um local em conformidade com a PCI. O uso do cache L1 também vai usar automaticamente o cache L2. O cache L1 é "somente memória", enquanto o cache L2 grava dados no disco para sincronizar em vários caches L1. O cache L2 é o que mantém vários processadores de mensagens sincronizados em uma região e globalmente. No momento, não é possível ativar o cache L1 sem um cache L2. O cache L2 grava dados no disco para que possam ser sincronizados com outros processadores de mensagens da organização do cliente. Como o cache L2 grava os dados no disco, o uso de cache para CHD ou outros dados restritos não é compatível.

O uso do cache por clientes é permitido para dados não CHD e outros dados irrestritos. Não desativamos o cache por padrão para clientes do PCI porque alguns clientes executam chamadas de API relacionadas a PCI e não relacionadas a PCI em uma única organização. Como o recurso ainda está ativado para clientes PCI, é responsabilidade do cliente usar o serviço adequadamente e treinar os usuários para não usar o cache quando os dados do PCI provavelmente estiverem na chamada de API. A auditoria de compliance do PCI da Apigee não oferece suporte a CHD armazenado no cache.

Confira instruções detalhadas sobre o uso do cache em Como adicionar armazenamento em cache e persistência.

Trilha de auditoria

Os clientes podem analisar a trilha de auditoria de todas as atividades administrativas realizadas na organização do cliente, incluindo o uso do Trace. Confira instruções detalhadas aqui e em Como usar a ferramenta Trace. (Requisito 10 de PCI: rastrear e monitorar todo o acesso a recursos de rede e dados do titular do cartão)

Requisitos de senha complexa ou SAML

Clientes com requisitos de senha específicos devem usar SAML para atender aos requisitos individuais deles. Consulte Como ativar a autenticação SAML para o Edge. O Edge também oferece autenticação multifator (Requisito 8 de PCI: atribuir um ID exclusivo a cada pessoa com acesso ao computador). Consulte Ativar a autenticação de dois fatores na sua conta da Apigee.

Segurança de endpoint

Verificação de endpoints

A verificação e o teste de hosts são necessários para manter a conformidade com o PCI (Requisito 11: testar regularmente os sistemas e processos de segurança). Para a Edge Cloud, os clientes são responsáveis pela verificação e pelo teste dos endpoints da API (às vezes chamados de "componentes do ambiente de execução") no Edge. Os testes do cliente precisam cobrir os serviços reais de proxy da API hospedados no Edge, em que o tráfego da API é enviado ao Edge antes de ser processado e entregue ao data center do cliente. Os testes de recursos compartilhados, como a interface do portal de gerenciamento, não são aprovados para clientes individuais. Um relatório de terceiros que abrange testes de serviços compartilhados está disponível para os clientes por meio de um contrato de não divulgação e mediante solicitação.

Os clientes devem testar os endpoints da API, e são incentivados a fazer isso. Seu contrato com a Apigee não proíbe o teste dos endpoints da API, mas não permitimos o teste da IU de gerenciamento compartilhada. Se for necessário mais esclarecimentos, abra uma solicitação de suporte com referência ao teste planejado. Envie uma notificação com antecedência à Apigee para que possamos tomar conhecimento do tráfego de teste.

Os clientes que testam os endpoints precisam procurar problemas específicos da API, problemas relacionados aos serviços da Apigee e verificar o TLS e outros itens configuráveis. Todos os itens relacionados aos serviços da Apigee precisam ser comunicados à Apigee por uma solicitação de suporte.

A maioria dos itens relacionados ao endpoint são itens de autoatendimento do cliente. Para corrigir o problema, consulte a documentação do Edge. Se o modo de correção de algum item não for claro, abra uma solicitação de suporte.

Configuração de TLS

De acordo com os padrões de PCI, é necessário migrar o SSL e o TLS com antecedência para versões protegidas. Os clientes são responsáveis por definir e configurar os próprios endpoints de TLS para proxies de API. Esse é um recurso de autoatendimento no Edge. Os requisitos do cliente sobre seleções de criptografia, protocolo e algoritmo são amplamente variáveis e específicos para casos de uso individuais. Como a Apigee não conhece os detalhes do design da API e dos payloads de dados de cada cliente, os clientes têm a responsabilidade de determinar a criptografia apropriada para os dados em trânsito. As instruções detalhadas sobre a configuração de TLS estão disponíveis em TLS/SSL.

Armazenamento de dados

O armazenamento de dados no Edge não é necessário para que ele funcione corretamente. No entanto, há serviços disponíveis para armazenamento de dados no Edge. Os clientes podem optar por usar cache, mapas de chave-valor ou análises para armazenamento de dados. Nenhum desses serviços está autorizado para armazenamento de CHD de acordo com a auditoria de PCI da Apigee. De acordo com o Requisito 3 de PCI (proteger dados do titular do cartão armazenados), os dados de PCI devem ser armazenados apenas em locais em conformidade com a PCI. O uso desses serviços está disponível para clientes que armazenam dados não PCI ou outros dados irrestritos sujeitos aos requisitos legais e de segurança do cliente. Esses serviços são itens de autoatendimento para clientes. Portanto, é responsabilidade do cliente configurá-los para não capturar ou armazenar CHD. São recomendadas análises da configuração, das políticas e das implantações pelos administradores dos clientes para evitar o uso acidental ou mal-intencionado de serviços de armazenamento de dados no Edge de maneira não compatível .

Criptografia de dados

As ferramentas de criptografia de dados não são oferecidas aos clientes para uso no Edge. No entanto, os clientes têm a liberdade de criptografar os dados de PCI antes de enviá-los ao Edge. Requisito 4 de PCI (criptografar a transmissão dos dados do titular do cartão em redes públicas abertas) recomenda criptografar os dados do titular do cartão em redes públicas abertas. Os dados criptografados no payload (ou corpo da mensagem) não impedem que o Edge funcione. Talvez algumas políticas do Edge não consigam interagir com os dados se eles forem criptografados pelo cliente. Por exemplo, uma transformação não é possível se os dados não estiverem disponíveis para o Edge mudar. No entanto, outras políticas e pacotes e políticas criados pelo cliente funcionarão mesmo que o payload de dados esteja criptografado.