Conformidade com a HIPAA no Cloud de Confiance e no Google Workspace

Determine se a organização tem requisitos de criptografia além do que é exigido pela regra de segurança da HIPAA. O conteúdo do cliente é criptografado em repouso no Cloud de Confiance. Se você tiver requisitos de criptografia extra, use o Cloud KMS.

Use as práticas recomendadas do IAM ao configurar quem tem acesso ao seu projeto. Como as contas de serviço podem ser usadas para acessar recursos, controle rigorosamente o acesso a essas contas e às chaves conta de serviço.

• Armazene apenas o mínimo de dados necessários para fornecer autenticação e autorização para seu aplicativo ou serviço. Ao criar um usuário no Identity Platform, o único atributo obrigatório é um endereço de e-mail ou um número de telefone. Se você precisar armazenar PHI, use uma solução de banco de dados de uso geral no Cloud de Confiance.
• Não armazene PHI em atributos opcionais ou personalizados, como nomes de exibição ou URLs de fotos. Se você precisar armazenar PHI, use uma solução de banco de dados de uso geral no Cloud de Confiance.
• Não transmita PHI de provedores de identidade externos federados (IdPs) para o Identity Platform em tokens, declarações, afirmações ou por qualquer outro mecanismo.
• Não sincronize PHI de sistemas de identidade externos com o Identity Platform. O Google não garante a segurança dessas informações em trânsito ou após o recebimento por terceiros.
• Não use contas anônimas ao interagir, gerenciar ou armazenar PHI.
• Não use os SDKs e as bibliotecas de cliente do Identity Platform ao interagir, gerenciar ou armazenar PHI. Como esse código é executado fora do Identity Platform, o Google não garante a segurança dessas informações, por exemplo, no dispositivo do usuário final.

Ao armazenar secrets no Secret Manager, revise e siga as práticas recomendadas do Secret Manager.

• Configure os destinos de exportação do registro de auditoria. Exporte registros de auditoria para o Cloud Storage para arquivamento de longo prazo e para o BigQuery para qualquer necessidade analítica, de monitoramento e forense. Configure os controles de acesso apropriados para esses destinos.
• Configure os controles de acesso aos registros. Os usuários com o papel de Leitor de registros (roles/logging.viewer) podem acessar os registros de auditoria de atividades do administrador, e os usuários com o papel de Visualizador de registros particulares (roles/logging.privateLogViewer) podem acessar os registros de auditoria de acesso a dados.
• Revise regularmente os registros de auditoria para garantir a segurança e a conformidade com os requisitos. Para análise de registros em grande escala, use o BigQuery ou uma plataforma SIEM para demonstrar conformidade por meio da análise de registros.

• Não armazene PHI em metadados, como rótulos de métricas, rótulos de VM, anotações de recursos do GKE ou títulos ou conteúdo de painéis. Qualquer pessoa com as permissões do IAM adequadas pode ver o console de monitoramento ou usar a API Cloud Monitoring para ver esses dados.
• Não coloque PHI em configurações de alerta (por exemplo, em nomes de exibição ou documentação) que possam ser enviadas a destinatários de alerta.

Não use os seguintes serviços ou recursos:

• Serviços de terceiros que não sejam fornecidos por um Afiliado do Google ou um provedor de infraestrutura baseado na nuvem.
• Suporte de analista sob demanda.
• Serviços, software ou hardware que não são do Google fornecidos à equipe do Google em relação a um contrato de Serviços de Consultoria da Mandiant.
• Ferramentas de integração de API que não são seguras.

Ao configurar jobs de Proteção de Dados Sensíveis, verifique se todos os dados de saída são gravados em destinos de armazenamento configurados como parte do ambiente seguro.

Ative o controle de versões de objeto para ajudar a preservar arquivos históricos e recuperar objetos após a exclusão acidental.

Use métodos de conectividade de IP privado para evitar a exposição de um banco de dados que contenha PHI à Internet.

• Use 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.
• Use backups do Filestore para recuperar dados após uma exclusão acidental.

Ao criar ou configurar índices, criptografe PHI, credenciais de segurança ou outros dados sensíveis antes de usá-los como chave de entidade, chave de propriedade indexada ou valor de propriedade indexada. Para mais informações, consulte Índices do Datastore.

Você precisa aceitar que o Data Studio seja regido pelo seu Contrato do Cloud de Confiance .

Não inclua PHI ou PII nos valores dos campos google.cloud.datacatalog.lineage.v1.Process.attributes e google.cloud.datacatalog.lineage.v1.Run.attributes.

• Os administradores precisam analisar as configurações de segurança de aplicativos e integrações de terceiros, bem como a documentação de segurança e privacidade correspondente do aplicativo de terceiros.
• Ao criar consultas estruturadas, evite incluir ou armazenar PHI na lógica de negócios que configura essas consultas.

Use APIs regionais e locais de recursos para PHI.

Não inclua PHI ou credenciais de segurança na definição do agente, incluindo intents, frases de treinamento e entidades.

Se você tiver firmado um BAA com o Google que cubra quaisquer obrigações de PHI de acordo com a HIPAA, não ative a geração de registros de dados.

Não inclua PHI ou PII nos cabeçalhos.

• Não inclua PII, PHI ou outras informações sensíveis no IntegrationParameter, no campo de nome em projects.locations.connections ou nas definições de configuração no recurso Connection. Essas informações podem ser registradas.
• Configure o controle de acesso para registros se o payload solicitado contiver dados sensíveis.

Não inclua PHI em arquivos de configuração do build, arquivos de controle de origem ou outros artefatos de build.

Não solicite o armazenamento em cache de PHI. Para evitar o armazenamento em cache, consulte Evitar o armazenamento em cache.

Não inclua PHI em URIs ou ações.

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 conta de usuário com o papel de Leitor do Artifact Registry (roles/artifactregistry.reader) ou o papel de Leitor do Artifact Registry (roles/artifactregistry.viewer). Para ajudar a evitar o acesso não autorizado a PHI, consulte Controlar o acesso e proteger artefatos.

O Container Registry criptografa dados nos buckets de armazenamento dos registros usando a criptografia padrão do Google ou CMEK. Para ajudar a impedir o acesso não autorizado às PHI, consulte Práticas recomendadas para proteger contêineres.

Manter os registros de acesso no nível do aplicativo por um período apropriado para atender aos requisitos da HIPAA.

Ao implantar o Distributed Cloud conectado, você é responsável por determinados aspectos de segurança, principalmente a segurança física. Para ajudar a proteger sua implantação, consulte Práticas recomendadas de segurança física.

Não use os seguintes serviços, que não são cobertos pelo BAA:

• Qualquer serviço de terceiros (incluindo Serviços excluídos), exceto os fornecidos por um afiliado do Google ou um provedor de infraestrutura baseado na nuvem.
• Qualquer ferramenta de integração de API que não seja segura.

Considere o seguinte ao implementar controles de acesso:

• Use o parâmetro access filter com atributos do usuário para aplicar segurança de dados no nível da linha, da coluna ou do campo por usuário ou grupo de usuários.
• Minimize o acesso aos dados para seus usuários limitando os privilégios de acesso de administrador, desenvolvedor e SQL Runner.
• Crie um processo que ajude a evitar o compartilhamento de PHI com serviços excluídos e funcionários do Google, incluindo equipes de suporte técnico que usam o acesso de suporte ou equipes de serviços profissionais durante um contrato.
• Configure o uso da API entre o Google e seu fornecedor ou outros terceiros de forma segura.

Considere o seguinte ao compartilhar dados:

• Não compartilhe PHI nem instrua o Google a compartilhar PHI com terceiros, a menos que haja um BAA em vigor com o terceiro.
• Não compartilhe PHI por e-mail. Configure o Looker para redirecionar os destinatários de e-mails para a instância do Looker em que eles precisam fazer login para acessar PHI ou conteúdo sensível relacionado.
• Crie processos que garantam que as PHI não sejam anexadas ou enviadas usando qualquer funcionalidade de chat de suporte técnico.
• Armazene os resultados da consulta em cache apenas pelo tempo mínimo necessário para os conjuntos de dados e casos de uso.
• Restringir quando os usuários podem criar links públicos.
• Crie e mantenha registros quando permitir que terceiros usem PHI agregadas.

Considere o seguinte ao configurar a segurança:

• Implemente métodos padrão do setor para autenticar usuários, como autenticação de dois fatores ou SSO compatível com SAML. Se um usuário usar o SSO, restrinja a permissão login_special_email a no máximo dois usuários.
• Aplicar segurança de conjunto de dados no modelo do Looker.
• Pelo menos uma vez por trimestre, audite todos os usuários, grupos, permissões, papéis, chaves de API, links públicos e outros controles de acesso, compartilhamento e configuração de segurança.

Considere o seguinte ao configurar os controles de segurança do banco de dados:

• Ao conceder acesso aos seus bancos de dados, siga o princípio de privilégio mínimo para o banco de dados e as informações dele.
• Verifique se todas as conexões com o banco de dados estão criptografadas em trânsito e use um servidor de túnel para qualquer conexão de túnel SSH.
• Use uma lista de permissões para restringir o acesso externo e permitir apenas endereços IP específicos do Google.
• Configure os direitos do banco de dados para que o Google não tenha acesso de gravação ou acesso administrativo aos seus bancos de dados.