Conformidade com a HIPAA no Google Cloud

Neste guia, falamos sobre a conformidade com a HIPAA no Google Cloud. A conformidade com a HIPAA do Google Workspace é abordada separadamente.

Exoneração de responsabilidade

Este guia é apenas para fins informativos. Os dados e recomendações fornecidos aqui pelo Google não constituem assessoria jurídica. Cada cliente é responsável pela avaliação do próprio uso dos serviços, conforme apropriado, para cumprir as obrigações legais de conformidade.

Público-alvo

O Google Cloud possibilita a conformidade com a Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA, na sigla em inglês) para clientes sujeitos aos requisitos da revisão por meio dessa legislação. Ela foi retificada para incluir a Lei de Tecnologia da Informação em Integridade Econômica e Clínica (HITECH, na sigla em inglês). Este guia destina-se a agentes de segurança e de conformidade, administradores de TI e outros funcionários responsáveis pela implementação e conformidade com a HIPAA no Google Cloud. Depois de ler este guia, você entenderá como o Google é capaz de acomodar a conformidade HIPAA e entenderá como configurar os Projetos de Google Cloud de forma a ajudar a cumprir responsabilidades no âmbito da HIPAA.

Definições

Todos os termos com letras iniciais em caixa alta com significados não definidos neste documento terão o mesmo significado atribuído a eles na HIPAA (em inglês). Além disso, para os fins deste documento, o termo "Informações de Saúde Protegidas" (PHI) refere-se aos dados desse tipo que o Google recebe de uma Entidade coberta.

Visão geral

É importante observar que não há nenhuma certificação reconhecida pelo Departamento de Saúde e Serviços Humanos dos Estados Unidos para conformidade com a HIPAA. Além disso, o cumprimento dessa legislação é responsabilidade do cliente e do Google. Especificamente, a HIPAA exige conformidade com a Regra de segurança, a Regra de privacidade e a Regra de notificação de violação (todos os links em inglês). O Google Cloud possibilita a conformidade com a HIPAA (no âmbito de um Contrato de parceria comercial), mas, em última análise, os clientes são responsáveis por avaliar se cumprem a legislação.

O Google firmará Contratos de parceria comercial (BAA) com clientes, conforme necessidade expressa no texto da HIPAA. O Google Cloud foi criado com a orientação de uma equipe de engenharia de segurança com mais de 700 pessoas, maior que grande parte das equipes de segurança locais. Para ver detalhes específicos sobre a abordagem a segurança e proteção de dados, incluindo controles organizacionais e técnicos sobre o modo como o Google protege os dados, consulte o Whitepaper do Google sobre segurança e a Visão geral do design de segurança da infraestrutura do Google.

Além de documentar nossa abordagem da concepção de privacidade e segurança, o Google é submetido a várias auditorias de terceiros independentes regularmente para fornecer aos clientes verificação externa. Há links para relatórios e certificados abaixo. Isso significa que um auditor independente examinou os controles em data centers, infraestrutura e operações. O Google passa por auditorias anuais que seguem estes padrões:

  • SSAE 16 / ISAE 3402 Tipo II. trata-se do relatório SOC 3 público associado. O SOC 2 pode ser obtido por NDA.
  • ISO 27001: O Google recebeu as certificações ISO 27001 para sistemas, aplicativos, pessoas, tecnologia, processos e data centers que atendem ao Google Cloud. O certificado ISO 27001 está disponível na seção de conformidade do nosso site.
  • ISO 27017, Segurança na nuvem. Trata-se de um padrão internacional de conduta para controles de segurança de informações baseado no ISO/IEC 27002, especificamente para serviços de nuvem. O certificado ISO 27017 está disponível na seção de conformidade do nosso site.
  • ISO 27018, Privacidade na nuvem. Trata-se de um padrão internacional de conduta para proteção de informações de identificação pessoal (PII) em serviços de nuvem pública. O certificado ISO 27018 está disponível na seção de conformidade do nosso site.
  • FedRAMP ATO
  • PCI DSS v3.2.1

Além de assegurar confidencialidade, integridade e disponibilidade do ambiente do Google, nossa abordagem abrangente de auditoria de terceiros foi criada para fornecer garantias do compromisso do Google com a melhor segurança de informações da classe. Os clientes podem consultar esses relatórios de auditoria de terceiros para avaliar como os produtos do Google podem atender às necessidades de conformidade HIPAA.

Responsabilidades do cliente

Uma das principais responsabilidades de um cliente é determinar se é ou não uma Entidade Coberta (ou um Parceiro Comercial de uma Entidade Coberta) e, em caso afirmativo, se requer um Contrato de parceria comercial (BAA) com o Google para os fins das interações.

O Google oferece uma infraestrutura segura e compatível (conforme descrito acima) para armazenamento e processamento de PHI, mas o cliente é responsável por assegurar que o ambiente e os aplicativos que ele desenvolve no Google Cloud estejam devidamente configurados e protegidos de acordo com os requisitos da HIPAA. Isso geralmente é chamado de modelo de segurança compartilhado na nuvem.

Práticas essenciais:

  • Firme um Acordo de Parceiro de Negócios (BAA) do Google Cloud. Solicite um BAA diretamente ao gerente de conta.
  • Desative ou garanta que não sejam usados produtos do Google Cloud não incluídos explicitamente no BAA. Consulte Produtos cobertos ao trabalhar com PHI.
  • Não use as ofertas de Pré-GA (produtos ou serviços oferecidos no Programa de disponibilidade geral antecipada do Google Cloud ou outras ofertas pré-GA, conforme definido nos Termos Específicos de Serviço do Google) com PHI, a menos que expressamente indicado de outra forma em um aviso ou outros termos da oferta.

Práticas técnicas recomendadas:

  • Use as práticas recomendadas de IAM ao configurar quem tem acesso ao projeto. Especificamente, como as contas de serviço podem ser usadas para acessar recursos, fiscalize o acesso a elas e às respectivas chaves de forma estritamente controlada.
  • Determine se a organização tem requisitos de criptografia além do que é exigido pela regra de segurança da HIPAA. Todo o conteúdo do cliente é criptografado em repouso no Google Cloud. Consulte nosso artigo sobre criptografia para mais detalhes e possíveis exceções.
  • Se você estiver usando o Cloud Storage, pense na possibilidade de ativar o controle de versões de objetos para criar um arquivo para esses dados e permitir o cancelamento de exclusão caso isso aconteça por acidente.
  • Configure os destinos de exportação do registro de auditoria. É muito importante exportar os registros de auditoria para o Cloud Storage e fazer um arquivamento de longo prazo, bem como para o BigQuery caso haja qualquer necessidade de análise, de monitoramento e/ou forense. Não esqueça de configurar o controle de acesso para os destinos apropriados à organização.
  • Configure o controle de acesso para os registros apropriados à organização. Os registros de auditoria de atividade de administrador podem ser acessados pelos usuários com o papel Visualizador de registros, e os registros de auditoria de acesso a dados podem ser acessados pelos usuários com o papel Visualizador de registros privados.
  • Analise regularmente os registros de auditoria para garantir segurança e conformidade com os requisitos. Como foi mencionado acima, o BigQuery é uma excelente plataforma para análise de registros em grande escala. Aproveite também as plataformas SIEM das integrações com parceiros para demonstrar conformidade por meio de análise de registros.
  • Ao criar ou configurar índices no Cloud Datastore, criptografe qualquer PHI, credencial de segurança ou outros dados confidenciais antes de usá-los como chave de entidade, chave de propriedade indexada ou valor da propriedade indexada para o índice. Consulte a Documentação do Cloud Datastore para ver informações sobre como criar e/ou configurar índices.
  • Ao criar ou atualizar agentes do Dialogflow, evite incluir PHI ou credenciais de segurança em qualquer lugar da definição do agente, incluindo intents, frases de treinamento e entidades.
  • Ao criar ou atualizar recursos, evite incluir PHI ou credenciais de segurança ao especificar os metadados de um recurso, já que essas informações podem ser capturadas nos registros. Os registros de auditoria nunca incluem o conteúdo de dados de um recurso ou os resultados de uma consulta aos registros, mas os metadados de recursos podem ser capturados.
  • Ao usar o Identity Platform no seu projeto, use as práticas da plataforma (em inglês).
  • Ao usar os serviços do Cloud Build para integração ou desenvolvimento contínuos, evite incluir ou armazenar PHI em arquivos de configuração de versão, arquivos de controle de origem ou outros artefatos de versão.
  • Se você estiver usando o Looker (Google Cloud Core), as pessoas designadas pelo Cliente para administrar as instâncias ou recursos precisam revisar as configurações de segurança de aplicativos e integrações de terceiros, além de qualquer documentação de segurança e privacidade correspondente fornecida pelo aplicativo de terceiros.
  • Se você estiver usando o Looker (Google Cloud Core) para estruturar consultas, evite incluir ou armazenar PHI na lógica de negócios usada para configurar essas consultas. Consulte a Documentação para obter informações sobre a estruturação de consultas.
  • Caso você use o Cloud CDN, não solicite o armazenamento em cache das PHI. Consulte a documentação do produto para informações sobre como impedir esse processo.
  • Se você usa o Cloud Speech-to-Text e firmou com o Google um BAA que inclui obrigações de PHI segundo a HIPAA, não ative o programa de geração de registros de dados.
  • Se você estiver usando o Google Cloud VMware Engine, é sua responsabilidade manter os registros de acesso no nível do aplicativo por um período apropriado, conforme necessário para atender aos requisitos da HIPAA.
  • Ao configurar jobs de proteção de dados sensíveis, certifique-se de que todos os dados de saída sejam gravados em destinos de armazenamento configurados como parte do ambiente seguro.
  • Revise e siga as orientações das Práticas recomendadas do Secret Manager ao armazenar secrets no Secret Manager.
  • O Artifact Registry criptografa dados em repositórios usando a criptografia padrão do Google ou chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês). Os metadados, como nomes de artefatos, são criptografados com a criptografia padrão do Google. Esses metadados podem aparecer nos registros e ficam visíveis para qualquer usuário com permissões de Leitor do Artifact Registry. Siga as orientações em Como proteger artefatos para ajudar a impedir o acesso não autorizado às PHI.
  • O Container Registry criptografa dados nos buckets de armazenamento dos registros usando a criptografia padrão do Google ou CMEK. Siga as práticas recomendadas para contêineres para ajudar a impedir o acesso não autorizado às PHI.
  • Se você estiver usando o Filestore, utilize o controle de acesso baseado em IP para restringir quais VMs do Compute Engine e clusters do GKE podem acessar a instância do Filestore. Considere usar backups para permitir a recuperação de dados em caso de exclusão acidental de dados.
  • Se você usa o Cloud Monitoring, não armazene PHI em metadados no Google Cloud, incluindo rótulos de métricas, rótulos de VM, anotações de recursos do GKE ou títulos/conteúdos de painéis. Qualquer pessoa autorizada pelo IAM a ver o console de monitoramento ou usar a API Cloud Monitoring pode ter acesso a esses dados. Não coloque PHI em configurações de alerta (por exemplo, nome de exibição ou documentação) que possam ser enviadas a destinatários de alerta.
  • Ao usar o reCAPTCHA Enterprise, evite incluir PHI em URIs ou ações.
  • Se você estiver usando o gateway de API, os cabeçalhos não poderão ter informações de PII ou PHI.
  • No Database Migration Service, use métodos de conectividade de IP privado para evitar a necessidade de expor à Internet um banco de dados que contenha PHI.
  • Se você estiver usando o Dataplex, os valores dos campos google.cloud.datacatalog.lineage.v1.Process.attributes e google.cloud.datacatalog.lineage.v1.Run.attributes não poderão ter nenhuma PHI ou PII.
  • Ao usar a Vertex AI para Pesquisa, use APIs regionais e locais de recursos para PHI.
  • Ao usar o Application Integration e o Integration Connectors, não inclua nenhuma PII, PHI ou outras informações sensíveis no parâmetro de integração, no nome da conexão ou na configuração da conexão, porque essas informações podem ser registradas. Configure o controle de acesso para registros se o payload solicitado contiver dados confidenciais. Alguns conectores baseados em arquivo e eventos baseados em webhook que são oferecidos pelo Integration Connectors armazenam os dados temporariamente. Os clientes recebem o controle de criptografar esses dados com a chave que escolherem usando a CMEK.

Produtos cobertos

O BAA do Google Cloud abrange toda a infraestrutura do Google Cloud (todas as regiões, todas as zonas, todos os caminhos de rede, todos os pontos de presença) e os seguintes produtos:

  • Aprovação de acesso
  • Access Context Manager
  • Transparência no acesso
  • Rotulagem de dados do AI Platform
  • ao AI Platform Training e Prediction
  • AlloyDB para PostgreSQL
  • API Gateway
  • Apigee
  • App Engine
  • Application Integration
  • Artifact Registry
  • Assured Workloads
  • AutoML Natural Language
  • AutoML Tables
  • AutoML Translation
  • AutoML Video
  • AutoML Vision
  • Solução Bare Metal
  • Lote
  • BigQuery
  • Serviço de transferência de dados do BigQuery
  • BigQuery Omni
  • Bigtable
  • Autorização binária
  • Inventário de recursos do Cloud
  • Backup e DR do Cloud
  • Cloud Build
  • Cloud CDN
  • Cloud Composer
  • console do Cloud
  • Cloud Data Fusion
  • Cloud Deploy
  • Cloud Deployment Manager
  • Cloud DNS
  • Cloud Endpoints
  • Cloud Filestore
  • Cloud Functions
  • API Cloud Healthcare
  • Cloud HSM
  • Cloud Identity
  • Cloud IDS
  • Cloud Interconnect
  • Cloud Key Management Service
  • Cloud Life Sciences (antigo Google Genomics)
  • Cloud Load Balancing
  • Cloud Logging
  • Cloud Monitoring
  • Cloud NAT (conversão de endereços de rede)
  • API Cloud Natural Language
  • Cloud Profiler
  • Cloud Router
  • Cloud Run (totalmente gerenciado)
  • Cloud Run para Anthos
  • Cloud Scheduler
  • Cloud Shell
  • Cloud Source Repositories
  • Cloud SQL
  • Cloud Storage
  • Cloud Tasks
  • Cloud Trace
  • Cloud Translation
  • Cloud Vision
  • Cloud VPN
  • Colab Enterprise
  • Compute Engine
  • Gerenciamento de configurações
  • Conectar
  • Contact Center AI
  • Contact Center AI Insights
  • Agent Assist da Contact Center AI
  • Container Registry
  • Database Migration Service
  • Data Catalog
  • Dataflow
  • Dataform
  • Datalab
  • Dataplex
  • Dataproc
  • Datastore
  • Datastream
  • Dialogflow
  • Document AI
  • Document AI Warehouse
  • Eventarc
  • Firestore
  • IA generativa na Vertex AI
  • Hub do GKE
  • App Google Cloud
  • Google Cloud Armor
  • Google Cloud Identity-Aware Proxy
  • Google Cloud VMware Engine (GCVE)
  • Google Kubernetes Engine
  • Healthcare Data Engine
  • Looker (Google Cloud Core)
  • Looker Studio*
  • Gerenciamento de identidade e acesso (IAM)
  • Identity Platform
  • Conectores de integração
  • IoT Core
  • Justificativas de acesso às chaves (KAJ, na sigla em inglês)
  • Serviço gerenciado para o Microsoft Active Directory (AD)
  • Memorystore
  • Níveis de serviço de rede
  • Persistent Disk
  • Pub/Sub
  • Gerenciador de Risco
  • reCAPTCHA Enterprise
  • API Resource Manager
  • Secret Manager
  • Security Command Center
  • Proteção de dados sensíveis
  • Gestão de consumidores de serviço
  • Service Control
  • Diretório de serviços
  • Gerenciamento de serviços
  • Malha de serviço
  • Spanner
  • Speech-to-Text
  • Serviço de transferência do Cloud Storage
  • Text-to-Speech
  • Traffic Director
  • Transfer Appliance
  • Vertex AI Platform (antiga Vertex AI)
  • Vertex AI para Pesquisa
  • API Video Intelligence
  • Nuvem privada virtual
  • VPC Service Controls
  • Web Security Scanner
  • Instâncias do Vertex AI Workbench
  • Fluxos de trabalho

* Desde que o Cliente tenha optado por usar o Looker Studio de acordo com o Contrato do Google Cloud.

Essa lista é atualizada à medida que novos produtos ficam disponíveis para o programa HIPAA.

Características exclusivas

As práticas de segurança do Google Cloud nos permitem ter um BAA sujeito à HIPAA que cobre toda a infraestrutura do Google Cloud, não uma parte separada da nuvem. Como resultado, você não fica restrito a uma região específica que tenha benefícios de escalonamento, operações e arquitetura. Você também pode se beneficiar da redundância de serviços de várias regiões, bem como da capacidade de usar VMs preemptivas para reduzir custos.

As medidas de segurança e conformidade que nos permitem acomodar a conformidade com a HIPAA estão profundamente enraizadas na infraestrutura, no projeto de segurança e nos produtos. Desse modo, podemos oferecer aos clientes regulamentados pela HIPAA os mesmos produtos com os mesmos preços disponíveis para todos os clientes, incluindo descontos por uso prolongado. Outras nuvens públicas cobram a mais pela nuvem HIPAA. Nós não fazemos isso.

Conclusão

O Google Cloud é a infraestrutura de nuvem em que os clientes podem armazenar, analisar e ter insights de informações de saúde de modo seguro, sem preocupação com infraestrutura.

Outros recursos