Esta página aplica-se ao Apigee e ao Apigee Hybrid.
Veja a documentação do
Apigee Edge.
Para que um cliente esteja em conformidade com a norma da indústria de cartões de pagamento (PCI) no Apigee, existem algumas ações e processos que o cliente possui ao abrigo do "Modelo de responsabilidade partilhada". Os seguintes itens devem ser revistos pelos clientes que pretendem estar em conformidade com a PCI. Estes itens são de autosserviço no Apigee e têm de ser resolvidos para que a organização do cliente (org) cumpra os requisitos da PCI. O conceito geral é "A Google protege a plataforma, o cliente protege os respetivos dados".
Mapeamento dos requisitos da PCI
A tabela seguinte mapeia os requisitos da PCI para a documentação do Apigee relacionada. Para mais informações acerca dos requisitos, consulte o Guia de referência rápida da PCI DSS v3.2.1.
| Requisito da PCI | Secção |
| Requisito 3: proteger os dados do titular do cartão armazenados | Ocultação de dados |
| Requisito 3: proteger os dados do titular do cartão armazenados | Armazenamento de dados |
| Requisito 4: encriptar a transmissão de dados de titulares de cartões através de redes públicas abertas | Configuração do TLS |
| Requisito 4: encriptar a transmissão de dados de titulares de cartões através de redes públicas abertas | Encriptação de dados |
| Requisito 7: restringir o acesso aos dados sobre titulares de cartões por necessidade de conhecimento da empresa | Utilização/autorizações |
| Requisito 8: atribua um ID exclusivo a cada pessoa com acesso ao computador | Requisitos de palavras-passe complexas ou SAML |
| Requisito 10: acompanhar e monitorizar todo o acesso aos recursos da rede e aos dados de titulares de cartões | Registo de auditoria |
| Requisito 11: testar regularmente os sistemas e os processos de segurança | Análise de pontos finais |
Para obter uma atestação de conformidade (AOC) da norma de segurança de dados PCI, visite o Gestor de relatórios de conformidade da Google ou contacte a equipa de vendas do Apigee.
Sessões de depuração
As sessões de depuração são uma ferramenta de resolução de problemas que permite ao utilizador ver o estado e o conteúdo de uma chamada API à medida que é processada através da plataforma Apigee.
Durante uma sessão de depuração, a ocultação de dados é aplicada. A ocultação de dados pode impedir a apresentação de dados durante uma sessão de depuração. Consulte a secção Ocultação de dados abaixo.
Estão disponíveis instruções detalhadas sobre a utilização da ferramenta Debug em Usar a ferramenta Debug.
Utilização/autorizações
O acesso à sessão de depuração é gerido através do sistema CABF (controlo de acesso baseado em funções) da IAM (gestão de identidade e de acesso) do Cloud. Estão disponíveis instruções detalhadas sobre a utilização do sistema RBAC para conceder e revogar privilégios de sessão de depuração em Funções do Apigee e Gerir utilizadores na IU do Apigee. As autorizações de sessão de depuração permitem ao utilizador iniciar uma sessão de depuração e aceder ao resultado de uma sessão de depuração.
Uma vez que a sessão de depuração tem acesso à carga útil das chamadas API (formalmente denominada "Corpo da mensagem"), é importante considerar quem tem acesso à execução de uma sessão de depuração. Uma vez que a gestão de utilizadores é da responsabilidade do cliente, a concessão de autorizações da sessão de depuração também é da responsabilidade do cliente.
Ocultação de dados
A ocultação de dados impede a apresentação de dados confidenciais apenas durante uma sessão de depuração, tanto na ferramenta de depuração (IU do Apigee) como no back-end através da depuração (API do Apigee). Os detalhes sobre como configurar a ocultação estão disponíveis em Ocultação e ocultação de dados. A ocultação de dados confidenciais faz parte do requisito 3 da PCI: proteger os dados dos titulares de cartões armazenados.
A ocultação de dados NÃO impede que os dados sejam visíveis em locais como ficheiros de registo, a cache e as estatísticas. Normalmente, os dados confidenciais não devem ser escritos na cache nem no Analytics sem uma forte justificação empresarial e uma revisão por parte das equipas legais e de segurança do cliente.
A colocar em cache
O armazenamento em cache está disponível para todos os clientes. Para mais informações, consulte o artigo Funcionamento interno da cache.
Registo de auditoria
Os clientes têm a capacidade de rever a trilha de auditoria de todas as atividades administrativas realizadas na organização do cliente, incluindo a utilização da depuração. Para obter instruções detalhadas, consulte os artigos Registo de auditoria e Usar a depuração. Requisito 10 da PCI: acompanhar e monitorizar todo o acesso aos recursos da rede e aos dados de titulares de cartões).
Requisitos de palavras-passe complexas ou SAML
Para clientes da PCI, as palavras-passe dos utilizadores são configuradas para cumprir a maioria dos requisitos exigidos pela PCI DSS. O Cloud ID também oferece autenticação multifator (PCI Requirement 8: Assign a unique ID to each person with computer access). O SAML, conforme descrito em Vista geral do SAML, pode ser usado como uma alternativa para os controlos de autenticação.
Nota: recomenda-se que os clientes com requisitos de palavras-passe específicos usem SAML para cumprir os seus requisitos individuais.
Segurança de pontos finais
Análise de pontos finais
A análise e os testes de anfitriões são necessários para a conformidade com a PCI (Requisito 11: testar regularmente os sistemas e os processos de segurança). No Apigee, os clientes são responsáveis pela análise e pelos testes dos respetivos pontos finais da API (por vezes denominados "componentes de tempo de execução") no Apigee. Os testes de clientes devem abranger os serviços de proxy da API reais alojados no Apigee, onde o tráfego da API é enviado para o Apigee antes de ser processado e, em seguida, entregue no centro de dados do cliente. Os testes de recursos partilhados, como a IU do portal de gestão, não são aprovados para clientes individuais (está disponível para os clientes um relatório de terceiros que abrange os testes dos serviços partilhados ao abrigo de um acordo de confidencialidade e mediante pedido).
Os clientes devem testar os respetivos pontos finais da API e são incentivados a fazê-lo. O seu contrato com o Apigee não proíbe os testes dos seus pontos finais da API, mas não lhe permitimos testar a IU de gestão partilhada. A notificação prévia à Apigee é apreciada para que possamos estar cientes do tráfego de testes.
Os clientes que testam os respetivos pontos finais devem procurar problemas específicos da API, problemas relacionados com os serviços Apigee e também verificar o TLS e outros itens configuráveis. Todos os itens relacionados com os serviços Apigee devem ser comunicados ao Apigee através de um pedido de apoio técnico.
A maioria dos itens relacionados com o ponto final são itens self-service do cliente e podem ser corrigidos revendo a documentação do Apigeee. Se existirem itens cuja correção não seja clara, abra um pedido de apoio técnico.
Configuração de TLS
De acordo com as normas PCI, o SSL e o TLS inicial têm de ser migrados para versões seguras. Os clientes são responsáveis por definir e configurar os seus próprios pontos finais TLS para proxies de API. Esta é uma funcionalidade self-service no Apigee. Os requisitos dos clientes relativos à encriptação, ao protocolo e às seleções de algoritmos variam muito e são específicos de exemplos de utilização individuais. Uma vez que o Apigee não conhece os detalhes da conceção da API e das cargas úteis de dados de cada cliente, os clientes têm a responsabilidade de determinar a encriptação adequada para os dados em trânsito. Pode encontrar instruções detalhadas sobre a configuração do TLS em TLS/SSL.
Armazenamento de dados
O armazenamento de dados no Apigee não é necessário para que o Apigee funcione corretamente. No entanto, existem serviços disponíveis para o armazenamento de dados no Apigee. Os clientes podem optar por usar a cache, os mapas de chaves-valores ou as estatísticas para o armazenamento de dados. O Analytics não está autorizado para o armazenamento de dados do titular do cartão (CHD) de acordo com a auditoria PCI do Apigee. De acordo com o requisito 3 da PCI (proteger os dados do titular do cartão armazenados), os dados da PCI devem ser armazenados apenas em localizações em conformidade com a PCI. A utilização destes serviços está disponível para os clientes armazenarem dados não PCI ou outros dados não restritos sujeitos aos requisitos legais e de segurança do cliente. Estes serviços são itens de self-service do cliente, pelo que é da responsabilidade do cliente configurá-los para não capturar nem armazenar dados de titulares de cartões. Recomendamos que os administradores dos clientes revejam a configuração, as políticas e as implementações para evitar a utilização acidental ou maliciosa de serviços de armazenamento de dados no Apigee de forma não compatível .
Encriptação de dados
As ferramentas de encriptação de dados não são oferecidas aos clientes para utilização no Apigee. No entanto, os clientes podem encriptar os respetivos dados de PCI antes de os enviar para o Apigee. Requisito 4 da PCI: (encriptar a transmissão de dados de titulares de cartões através de redes públicas abertas) recomenda a encriptação de dados de titulares de cartões através de redes públicas abertas. Os dados encriptados na carga útil (ou no corpo da mensagem) não impedem o funcionamento do Apigee. Algumas políticas do Apigee podem não conseguir interagir com os dados se forem recebidos encriptados pelo cliente. Por exemplo, uma transformação não é possível se os próprios dados não estiverem disponíveis para o Apigee para alteração. No entanto, outras políticas, políticas criadas pelo cliente e pacotes funcionam mesmo que a carga útil de dados esteja encriptada.
Captura de dados
Os clientes podem usar a política de captura de dados para enviar atributos personalizados para a plataforma de estatísticas do Apigee. O Apigee recomenda não usar a captura de dados para armazenar informações do titular do cartão.
Exposição de informações através de strings de consulta no URL
A Apigee recomenda designs de APIs que evitam dados confidenciais (incluindo, entre outros, informações do titular do cartão) através de strings de consulta em URLs.