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

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X.
informações

Para que um cliente esteja em conformidade com o PCI na nuvem pública do Apigee Edge, existem algumas ações e processos que ele possui no "Modelo de responsabilidade compartilhada". Os itens a seguir devem ser analisados por clientes que compraram o pacote de conformidade com o PCI e precisam estar em conformidade com a PCI. Esses itens são de autoatendimento no Edge e precisam ser resolvidos para que a organização do cliente (organização) esteja em conformidade com o PCI. O conceito geral é "O Google protege a plataforma, e o cliente protege os dados".

Matriz de responsabilidade do cliente

Os clientes precisam consultar a Matriz de responsabilidade PCI-DSS 3.2.1 do Google Apigee e compartilhá-la com o assessor de segurança qualificado do PCI ao conduzir 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 aos recursos de rede e aos 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 dos 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 dos dados do titular do cartão em redes públicas abertas

Criptografia de dados

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

Rastreamento / depuração

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. Depuração é o nome do mesmo serviço quando usado por chamadas de API. O uso do termo "trace" neste documento é válido para o Trace e o Debug.

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

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

Instruções detalhadas sobre o uso do Trace estão disponíveis em Uso da ferramenta Trace.

Detalhes sobre KVMs, incluindo KVMs criptografadas, estão disponíveis em Como trabalhar com mapas de chave-valor.

Uso/autorizações

O acesso ao Trace é gerenciado pelo sistema de controle de acesso baseado em papéis (RBAC, na sigla em inglês) para contas de usuários no Edge. Veja instruções detalhadas sobre como usar o sistema RBAC para conceder e revogar privilégios do Trace em Como atribuir funções e Como criar papéis personalizados na IU. As permissões de trace permitem que o usuário inicie um trace, interrompa um trace e acesse a saída de uma sessão do trace.

Como o Trace tem acesso ao payload das chamadas de API (anteriormente chamado de "Corpo da mensagem"), é importante considerar quem tem acesso para executar um Trace. Como o gerenciamento de usuários é responsabilidade do cliente, a concessão de permissões do Trace também é uma responsabilidade do cliente. A Apigee, como proprietária da plataforma, pode adicionar um usuário a uma organização do cliente e atribuir os privilégios. Esse recurso só é usado mediante solicitação de suporte do cliente em uma situação em que parece que o atendimento ao cliente está falhando e que a revisão de uma sessão do Trace fornece as melhores informações sobre a causa raiz.

Mascaramento de dados

O mascaramento de dados impede a exibição de dados confidenciais apenas durante uma sessão do Trace/Debug, tanto no Trace (IU do Edge) quanto no back-end pelo Debug (API Edge). Os detalhes sobre como configurar o mascaramento estão disponíveis em Mascaramento e ocultação de dados. O mascaramento de dados confidenciais faz parte do Requisito 3 do PCI: proteger dados armazenados do titular do cartão

O mascaramento de dados NÃO impede que eles fiquem visíveis em arquivos de registros, no cache, nas análises etc. Para receber ajuda com o mascaramento de dados nos registros, adicione um padrão regex ao arquivo logback.xml. Geralmente, os dados confidenciais não devem ser gravados em cache ou análises sem uma forte justificativa comercial e análise das equipes jurídicas e de segurança do cliente.

Cache L1 e L2

O armazenamento em cache está disponível aos clientes do PCI para uso somente com dados não regulamentados. O cache não pode ser usado para dados do titular do cartão PCI (CHD, na sigla em inglês). Ele não é aprovado pela auditoria de conformidade do PCI da Apigee como local de armazenamento de CHD. De acordo com a orientação do PCI (requisito 3: proteger os dados armazenados do titular do cartão) , os dados do PCI só podem ser armazenados em um local compatível com o PCI. Ao usar o cache L1, o cache L2 também é automaticamente usado. 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 em todo o mundo. No momento, não é possível ativar o cache L1 sem um cache L2 por trás dele. O cache L2 grava dados no disco para que eles possam ser sincronizados com outros processadores de mensagens da organização do cliente. Como o cache L2 grava os dados no disco, não é possível usar o cache para CHD ou outros dados restritos.

Os clientes podem usar o cache para dados que não são CHD e outros dados irrestritos. Não desativamos o cache por padrão para clientes PCI, porque alguns deles executam chamadas de API PCI e não relacionadas a PCI por uma única organização. Como o recurso ainda está ativado para clientes do PCI, é responsabilidade do cliente usar o serviço adequadamente e treinar os usuários para não usar o cache quando houver probabilidade de os dados do PCI estarem na chamada de API. A auditoria de conformidade com o PCI da Apigee não aceita CHD armazenado no cache.

Instruções detalhadas sobre como usar o cache estão disponíveis em Como adicionar armazenamento em cache e persistência.

Trilha de auditoria

Os clientes podem revisar 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 do PCI: rastrear e monitorar todo o acesso a recursos de rede e dados do titular do cartão)

Requisitos de senha complexa ou SAML

Os clientes com requisitos de senha específicos precisam usar o SAML para atender aos próprios requisitos. Consulte Como ativar a autenticação SAML para o Edge. O Edge também oferece autenticação multifator (requisito do PCI 8: atribuir um ID exclusivo a cada pessoa com acesso ao computador). Consulte Ativar a autenticação de dois fatores para sua conta da Apigee.

Segurança de endpoints

Verificação de endpoints

A verificação e o teste de hosts são necessários para a conformidade com o PCI (Requisito 11: testar regularmente os sistemas e os processos de segurança). Para o Edge Cloud, os clientes são responsáveis pela verificação e pelo teste dos endpoints de API (às vezes chamados de "componentes de ambiente de execução") no Edge. O teste do cliente precisa abranger os serviços de proxy de API reais hospedados no Edge para onde o tráfego da API é enviado antes do processamento e depois entregue ao data center do cliente. O teste de recursos compartilhados, como a interface do portal de gerenciamento, não é aprovado para clientes individuais. Um relatório de terceiros que cobre o teste dos serviços compartilhados está disponível para os clientes de acordo com um contrato de confidencialidade 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 interface de gerenciamento compartilhado. Se precisar de mais esclarecimentos, abra uma solicitação de suporte mencionando os testes planejados. Recomendamos notificar a Apigee com antecedência para que possamos estar cientes 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 encontrados relacionados aos serviços da Apigee precisam ser comunicados à Apigee por uma solicitação de suporte.

A maioria dos itens relacionados ao endpoint é de autoatendimento do cliente e pode ser corrigida na documentação do Edge. Se não estiver claro como corrigir alguns itens, 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. Este é 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. Instruções detalhadas sobre a configuração do TLS estão disponíveis em TLS/SSL.

Armazenamento de dados

O armazenamento de dados no Edge não é necessário para que o Edge 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 armazenar o CHD de acordo com a auditoria do PCI da Apigee. De acordo com o Requisito 3 do PCI (Proteger os dados armazenados do titular do cartão), os dados do PCI só podem ser armazenados em locais que obedecem à PCI. O uso desses serviços está disponível para os clientes armazenarem 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 do cliente. Portanto, é responsabilidade do cliente configurá-los para não capturar ou armazenar o CHD. Revisões de configuração, políticas e implantações pelos administradores do cliente são recomendadas para evitar o uso acidental ou mal-intencionado dos 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 no Edge. No entanto, os clientes são livres para criptografar os dados PCI antes de enviar ao Edge. Requisito do PCI 4: criptografar a transmissão dos dados do titular do cartão em redes públicas abertas (em inglês) recomenda criptografar os dados do titular do cartão em redes públicas abertas. Os dados criptografados no payload (ou no corpo da mensagem) não impedem o Edge de funcionar. Algumas políticas de borda podem não conseguir interagir com os dados se eles forem recebidos criptografados pelo cliente. Por exemplo, uma transformação não será possível se os dados em si não estiverem disponíveis para alteração no Edge. No entanto, outras políticas, políticas e pacotes criados pelo cliente funcionarão mesmo se o payload de dados for criptografado.