Você está vendo a documentação do Apigee Edge.
Acesse a
documentação da Apigee X. informações
Compliance com a HIPAA no Apigee Edge
Uma das nossas maiores prioridades é garantir que os dados dos clientes estejam seguros, protegidos e sempre disponíveis. Para demonstrar nossa conformidade com os padrões de segurança do setor, o Google solicitou e recebeu certificações de segurança, como a certificação ISO 27001, SOC 2 e SOC 3 Tipo II. Para clientes que estão sujeitos aos requisitos da Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA, na sigla em inglês), o Apigee Edge também está em conformidade com a HIPAA.
De acordo com a HIPAA, determinadas informações sobre a saúde e os serviços de assistência médica de uma pessoa são classificadas como Informações protegidas de saúde (PHI). Os clientes do Apigee Edge que estiverem sujeitos à HIPAA e quiserem usar o Apigee Edge com PHI precisarão assinar um Contrato de parceria comercial (BAA) com o Google.
Os clientes do Apigee Edge são responsáveis por determinar se estão sujeitos aos requisitos da HIPAA e se usam ou pretendem usar os serviços do Google em conexão com PHI. Os clientes que não assinaram um BAA com o Google não podem usar os Serviços do Google em conexão com PHI.
Os administradores precisam analisar e aceitar um BAA antes de usar os Serviços do Google com PHI.
Publicamos nosso Guia de configuração da HIPAA da Apigee neste tópico para ajudar os clientes a entender como organizar dados nos serviços do Google ao lidar com PHI. Este guia é destinado a funcionários em organizações responsáveis pela implementação da HIPAA e conformidade com o Apigee Edge.
Guia de configuração da HIPAA para nuvem pública de borda
Este guia é apenas informativo. As informações e recomendações disponibilizadas aqui pela Apigee não constituem assessoria jurídica. Cada cliente é responsável por avaliar, de forma independente, o próprio uso dos serviços, conforme apropriado, para cumprir as obrigações legais de compliance.
Os itens a seguir precisam ser analisados por clientes sujeitos à Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA, na sigla em inglês), conforme alterada, incluindo a Lei de Tecnologia da Informação para Saúde Econômica e Clínica (HITECH, na sigla em inglês) que compraram o pacote de conformidade com a HIPAA. Esses itens são de autoatendimento no Edge e podem ajudar a apoiar a organização do cliente (organização) no cumprimento de suas obrigações de conformidade com a HIPAA. O conceito geral é "o Google protege a plataforma, e o cliente protege os dados".
| Requisitos da HIPAA | Seções |
|---|---|
| Compliance com HIPAA: segurança – controle de acesso | Uso/autorizações |
| Compliance com HIPAA: processo de gerenciamento de segurança - análise da atividade do sistema de informações | Trilha de auditoria |
| Compliance com a HIPAA: gerenciamento de senhas de segurança | Requisitos de senha complexos ou SAML |
| Compliance com a HIPAA: segurança – processo de gerenciamento de segurança | Verificação de endpoints |
| Compliance com a HIPAA: segurança - transmissão | Configuração de TLS |
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 dentro da IU 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" será aplicado se for ativado e configurado pelo cliente. Essa ferramenta pode bloquear a exibição de dados durante um Trace. Consulte a seção Mascaramento de dados abaixo.
Os mapas de chave-valor criptografados (KVMs) são usados para clientes que exigem compliance com a HIPAA. Com uma KVM criptografada em uso, o Trace ainda pode 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 exibir 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 por meio do sistema RBAC (controle de acesso baseado em papéis) para contas de usuário no Edge (conformidade com a HIPAA: segurança - controle de acesso). Confira 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 é 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 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 NÃO impede que eles fiquem visíveis em arquivos de registros, no cache, em análises etc. Para receber ajuda com o mascaramento de dados nos registros, adicione um padrão de 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 suas equipes de segurança e jurídica.
Cache L1 e L2
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 em disco para que possam ser sincronizados com outros processadores de mensagens da organização do cliente. 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 (compliance com a HIPAA: processo de gerenciamento de segurança – análise da atividade do sistema de informações). Instruções detalhadas estão disponíveis aqui e em Como usar a ferramenta Trace.
Requisitos de senha complexa ou SAML
Para clientes HIPAA, as senhas de usuário são configuradas para atender a requisitos avançados, como duração, complexidade e vida útil. (Compliance com a HIPAA: gerenciamento de senhas de segurança)
O Edge também oferece autenticação multifator, descrita em Ativar a autenticação de dois fatores para sua conta da Apigee, e SAML, descrito em Como ativar a autenticação SAML para Edge, como alternativas para controles de autenticação.
Segurança de endpoint
Verificação de endpoints
Os clientes do Edge Cloud são responsáveis por verificar e testar os endpoints de API (às vezes chamados de "componentes de ambiente de execução") no Edge ( compliance com HIPAA: Segurança - Processo de gerenciamento de segurança). 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 ao Edge antes do processamento e da entrega 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 os testes 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 solicita que você não teste a interface de gerenciamento compartilhado. Caso seja necessário mais esclarecimentos, abra um tíquete de suporte referente aos testes planejados. É importante 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 ou relacionados aos serviços da Apigee e também verificar o TLS e outros itens configuráveis. Todos os itens encontrados e relacionados aos serviços da Apigee precisam ser comunicados à Apigee por um tíquete 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
Os clientes são responsáveis por definir e configurar os próprios endpoints TLS para proxies de API. Este é um recurso de autoatendimento no Edge. Os requisitos do cliente em relação às seleções de criptografia, protocolo e algoritmo são amplamente variáveis e específicos para os 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 são responsáveis por determinar a criptografia apropriada para os dados em trânsito ( compliance com a HIPAA: segurança - transmissão).
Veja instruções detalhadas sobre a configuração do TLS 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 o cache ou o Analytics para armazenamento de dados. 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 do payload
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 antes de enviar para o Edge. 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.
PII em URIs
A plataforma de análise unificada (UAP, na sigla em inglês) da Apigee captura dados de análise, incluindo PHI ou outros dados sensíveis incluídos no identificador uniforme de recursos (URI, na sigla em inglês) de uma chamada de API no Apigee Edge e os mantém por 13 meses. A PHI no URI é compatível com os padrões de Recursos de interoperabilidade rápida de saúde (FHIR, na sigla em inglês) e, portanto, é aceita pela Apigee. Os dados do Google Analytics no UAP são criptografados em repouso por padrão.
No momento, a Apigee não oferece suporte a:
- Mascaramento de dados para o UAP
- Como alterar o ciclo de retenção
- Como desativar a UAP
- Como descartar o URI da coleta de dados do UAP