Perfis de dados

Esta página descreve o serviço de descoberta de dados sensíveis. Esse serviço ajuda a determinar onde os dados sensíveis e de alto risco estão armazenados na organização.

Visão geral

O serviço de descoberta permite proteger os dados em toda a organização, identificando onde estão os dados sensíveis e de alto risco. Quando você cria uma configuração de verificação de descoberta, a Proteção de Dados Sensíveis verifica seus recursos para identificar os dados no escopo para criação de perfil. Em seguida, ele gera perfis dos seus dados. Enquanto a configuração de descoberta estiver ativa, a Proteção de dados sensíveis cria perfis automáticos dos dados que você adicionar e modificar. É possível gerar perfis de dados em toda a organização, pastas individuais e projetos individuais.

Cada perfil de dados é um conjunto de insights e metadados que o serviço de descoberta coleta ao verificar um recurso compatível. Os insights incluem os infoTypes previstos e os níveis de risco e sensibilidade dos dados calculados. Use esses insights para tomar decisões conscientes sobre como você protege, compartilha e usa seus dados.

Os perfis de dados são gerados em vários níveis de detalhes. Por exemplo, quando você cria perfis de dados do BigQuery, eles são gerados nos níveis de projeto, tabela e coluna.

A imagem a seguir mostra uma lista de perfis de dados no nível da coluna. Clique na imagem para ampliar.

Captura de tela dos perfis de dados da coluna

Para uma lista de insights e metadados incluídos em cada perfil de dados, consulte a Referência de métricas.

Para mais informações sobre a hierarquia de recursos do Google Cloud, consulte Hierarquia de recursos.

Geração de perfil de dados

Para começar a gerar perfis de dados, crie uma configuração de verificação de descoberta, também chamada de configuração de perfil de dados. É nessa configuração de verificação que você define o escopo da operação de descoberta e o tipo de dados que quer analisar. Na configuração de verificação, é possível definir filtros para especificar subconjuntos de dados que você quer criar o perfil ou pular. Também é possível definir a programação de criação de perfil.

Ao criar uma configuração de verificação, você também define o modelo de inspeção a ser usado. O modelo de inspeção é onde você especifica os tipos de dados sensíveis (também chamados de infoTypes) que a Proteção de dados sensíveis precisa verificar.

Quando a Proteção de Dados Sensíveis cria perfis de dados, ela analisa seus dados com base na configuração de verificação e no modelo de inspeção.

A Proteção de Dados Sensíveis cria um novo perfil dos dados, conforme descrito em Frequência da geração de perfis de dados. É possível personalizar a frequência da criação de perfil na configuração de verificação criando uma programação. Para forçar o serviço de descoberta a criar um novo perfil dos seus dados, consulte Forçar uma operação de redefinição de perfil.

Tipos de descoberta

Esta seção descreve os tipos de operações de descoberta que você pode realizar e os recursos de dados compatíveis.

Discovery para BigQuery e BigLake

Quando você cria perfis de dados do BigQuery, eles são gerados nos níveis de projeto, tabela e coluna. Depois de criar o perfil de uma tabela do BigQuery, você pode investigar melhor as descobertas fazendo uma inspeção detalhada.

Tabelas de perfis de Proteção de dados sensíveis com suporte à API BigQuery Storage Read, incluindo:

  • Tabelas padrão do BigQuery
  • Snapshots da tabela
  • Tabelas do BigLake armazenadas no Cloud Storage

Não há compatibilidade com os seguintes recursos:

  • Tabelas do BigQuery Omni.
  • Tabelas em que o tamanho dos dados serializados de linhas individuais excede o tamanho máximo de dados serializados com suporte da API BigQuery Storage Read, ou seja, 128 MB.
  • Tabelas externas que não são do BigLake, como as Planilhas Google.

Para saber como criar perfis de dados do BigQuery, consulte:

Para mais informações sobre o BigQuery, consulte a documentação do BigQuery.

Discovery para Cloud SQL

Quando você cria perfis de dados do Cloud SQL, eles são gerados nos níveis do projeto, da tabela e da coluna. Antes de iniciar a descoberta, é necessário fornecer os detalhes de conexão de cada instância do Cloud SQL para criar o perfil.

Para saber como criar perfis de dados do Cloud SQL, consulte:

Para mais informações sobre o Cloud SQL, consulte a documentação do Cloud SQL.

Discovery para o Cloud Storage

Quando você cria perfis de dados do Cloud Storage, eles são gerados no nível do bucket. A Proteção de Dados Sensíveis agrupa os arquivos detectados em grupos de arquivos e fornece um resumo para cada grupo.

Para saber como criar perfis de dados do Cloud Storage, consulte estes artigos:

Para mais informações sobre o Cloud Storage, consulte a documentação do Cloud Storage.

Discovery para Vertex AI

Quando você cria o perfil de um conjunto de dados da Vertex AI, a Proteção de dados sensíveis gera um perfil de dados de armazenamento de arquivos ou um perfil de dados de tabela, dependendo de onde os dados de treinamento são armazenados: Cloud Storage ou BigQuery.

Para ver mais informações, consulte os seguintes tópicos:

Para mais informações sobre a Vertex AI, consulte a documentação da Vertex AI.

Discovery para o Amazon S3

Quando você cria perfis de dados do S3, eles são gerados no nível do bucket. A Proteção de Dados Sensíveis agrupa os arquivos detectados em grupos de arquivos e fornece um resumo para cada grupo.

Para mais informações, consulte Descoberta de dados sensíveis para dados do Amazon S3.

Variáveis de ambiente do Cloud Run

O serviço de descoberta pode detectar a presença de secrets nas funções do Cloud Run e nas variáveis de ambiente de revisão do serviço do Cloud Run e enviar as descobertas para o Security Command Center. Nenhum perfil de dados é gerado.

Para mais informações, consulte Relatar segredos em variáveis de ambiente para o Security Command Center.

Papéis necessários para configurar e visualizar perfis de dados

As seções a seguir listam os papéis do usuário obrigatórios, categorizados de acordo com a finalidade deles. Dependendo de como sua organização está configurada, é possível decidir que diferentes pessoas realizem tarefas diferentes. Por exemplo, a pessoa que configura os perfis de dados pode ser diferente da pessoa que os monitora regularmente.

Papéis necessários para trabalhar com perfis de dados no nível da organização ou da pasta

Com esses papéis, é possível configurar e visualizar perfis de dados no nível da organização ou da pasta.

Certifique-se de que esses papéis sejam concedidos às pessoas adequadas no nível da organização. Como alternativa, o administrador do Google Cloud pode criar papéis personalizados que tenham apenas as permissões relevantes.

Finalidade Papel predefinido Permissões relevantes
Criar uma configuração de verificação de descoberta e conferir perfis de dados Administrador do DLP (roles/dlp.admin)
  • dlp.columnDataProfiles.list
  • dlp.fileStoreProfiles.list
  • dlp.inspectTemplates.create
  • dlp.jobs.create
  • dlp.jobs.list
  • dlp.jobTriggers.create
  • dlp.jobTriggers.list
  • dlp.projectDataProfiles.list
  • dlp.tableDataProfiles.list
Crie um projeto para ser usado como o contêiner do agente de serviço1 roles/resourcemanager.projectCreatorCriador do projeto
  • resourcemanager.organizations.get
  • resourcemanager.projects.create
Conceder acesso à descoberta2 Uma das seguintes opções:
  • Administrador da organização (roles/resourcemanager.organizationAdmin)
  • Administrador de segurança (roles/iam.securityAdmin)
  • resourcemanager.organizations.getIamPolicy
  • resourcemanager.organizations.setIamPolicy
Acessar perfis de dados (somente leitura) Leitor de perfis de dados da DLP (roles/dlp.dataProfilesReader)
  • dlp.columnDataProfiles.list
  • dlp.fileStoreProfiles.list
  • dlp.projectDataProfiles.list
  • dlp.tableDataProfiles.list
Leitor de DLP (roles/dlp.reader)
  • dlp.jobs.list
  • dlp.jobTriggers.list

1 Se você não tiver o papel de criador de projeto (roles/resourcemanager.projectCreator), ainda poderá criar uma configuração de verificação, mas o contêiner do agente de serviço usado precisa ser um projeto existente.

2 Se você não tiver o papel de administrador da organização (roles/resourcemanager.organizationAdmin) ou de administrador de segurança (roles/iam.securityAdmin), ainda poderá criar uma configuração de verificação. Depois de criar a configuração de verificação, alguém na sua organização que tenha uma dessas funções precisa conceder acesso de descoberta ao agente de serviço.

Papéis necessários para trabalhar com perfis de dados no nível do projeto

Com esses papéis, é possível configurar e visualizar perfis de dados no nível do projeto.

Certifique-se de que esses papéis sejam concedidos às pessoas adequadas no nível do projeto. Como alternativa, o administrador do Google Cloud pode criar papéis personalizados que tenham apenas as permissões relevantes.

Finalidade Papel predefinido Permissões relevantes
Configurar e ver perfis de dados Administrador do DLP (roles/dlp.admin)
  • dlp.columnDataProfiles.list
  • dlp.fileStoreProfiles.list
  • dlp.inspectTemplates.create
  • dlp.jobs.create
  • dlp.jobs.list
  • dlp.jobTriggers.create
  • dlp.jobTriggers.list
  • dlp.projectDataProfiles.list
  • dlp.tableDataProfiles.list
Acessar perfis de dados (somente leitura) Leitor de perfis de dados da DLP (roles/dlp.dataProfilesReader)
  • dlp.columnDataProfiles.list
  • dlp.fileStoreProfiles.list
  • dlp.projectDataProfiles.list
  • dlp.tableDataProfiles.list
Leitor de DLP (roles/dlp.reader)
  • dlp.jobs.list
  • dlp.jobTriggers.list

Configuração da verificação de descoberta

Uma configuração de verificação de descoberta (às vezes chamada de configuração de descoberta ou configuração de verificação) especifica como a Proteção de dados sensíveis deve criar o perfil dos seus dados. Ela inclui as seguintes configurações:

Para informações sobre como criar uma configuração de verificação de descoberta, consulte as páginas a seguir:

Escopos de configuração da verificação

É possível criar uma configuração de verificação nos seguintes níveis:

  • Organização
  • Pasta
  • Projeto
  • Recurso de dados único

No nível da organização e da pasta, se duas ou mais configurações de verificação ativas tiverem o mesmo projeto no escopo, a Proteção de Dados Sensíveis vai determinar qual configuração de verificação pode gerar perfis para esse projeto. Para mais informações, consulte Como substituir configurações de verificação nesta página.

Uma configuração de verificação no nível do projeto sempre pode criar o perfil do projeto de destino e não compete com outras configurações no nível da pasta ou da organização mãe.

Uma configuração de verificação de recurso único tem como objetivo ajudar você a analisar e testar a criação de perfil em um único recurso de dados.

Local da configuração da verificação

Ao criar uma configuração de verificação pela primeira vez, especifique onde quer que a Proteção de Dados Sensíveis seja armazenada. Todas as configurações de verificação subsequentes que você criar serão armazenadas na mesma região.

Por exemplo, se você criar uma configuração de verificação para a Pasta A e armazená-la na região us-west1, qualquer configuração de verificação criada posteriormente para qualquer outro recurso também será armazenada nessa região.

Os metadados sobre os dados a serem criados são copiados para a mesma região que as configurações de verificação, mas os dados em si não são movidos nem copiados. Para mais informações, consulte Considerações sobre a residência de dados.

Modelo de inspeção

Um modelo de inspeção especifica quais tipos de informações (ou infoTypes) a Proteção de dados sensíveis procura ao verificar seus dados. Aqui, você oferece uma combinação de InfoTypes integrados e InfoTypes personalizados opcionais.

Também é possível fornecer um nível de probabilidade para restringir o que a Proteção de dados sensíveis considera uma correspondência. É possível adicionar conjuntos de regras para excluir descobertas indesejadas ou incluir outras descobertas.

Por padrão, se você mudar um modelo de inspeção usado pela configuração da verificação, as alterações serão aplicadas somente às verificações futuras. Sua ação não causa uma operação de redefinição de perfil nos seus dados.

Se você quiser que as mudanças no modelo de inspeção acionem operações de reformulação de perfil nos dados afetados, adicione ou atualize uma programação na configuração da verificação e ative a opção de reformular o perfil dos dados quando o modelo de inspeção mudar. Para mais informações, consulte Frequência de geração de perfil de dados.

É necessário ter um modelo de inspeção em cada região com dados para criar o perfil. Se você quiser usar um único modelo para várias regiões, use um modelo armazenado na região global. Se as políticas organizacionais impedirem a criação de um modelo de inspeção na região global, você precisará definir um modelo de inspeção dedicado para cada região. Para mais informações, consulte Considerações sobre a residência de dados.

Os modelos de inspeção são um componente essencial da plataforma de proteção de dados sensíveis. Os perfis de dados usam os mesmos modelos de inspeção que podem ser usados em todos os serviços de Proteção de Dados Sensíveis. Para mais informações sobre modelos de inspeção, consulte Modelos.

Contêiner e agente de serviço

Quando você cria uma configuração de verificação para sua organização ou para uma pasta, a Proteção de dados sensíveis exige que você forneça um contêiner do agente de serviço. Um contêiner de agente de serviço é um projeto do Google Cloud que a Proteção de dados sensíveis usa para rastrear cobranças relacionadas a operações de criação de perfil no nível da organização e da pasta.

O contêiner do agente de serviço contém um agente de serviço, que a Proteção de dados sensíveis usa para criar perfis de dados em seu nome. Você precisa de um agente de serviço para fazer a autenticação na Proteção de dados sensíveis e em outras APIs. Seu agente de serviço precisa ter todas as permissões necessárias para acessar e criar perfis dos seus dados. O ID do agente de serviço tem o seguinte formato:

service-PROJECT_NUMBER@dlp-api.iam.gserviceaccount.com

Aqui, PROJECT_NUMBER é o identificador numérico do contêiner do agente de serviço.

Ao configurar o contêiner do agente de serviço, é possível escolher um projeto atual. Se o projeto selecionado contiver um agente de serviço, a Proteção de dados sensíveis concederá as permissões do IAM necessárias a esse agente de serviço. Se o projeto não tiver um agente de serviço, a Proteção de Dados Sensíveis vai criar um e conceder automaticamente permissões de criação de perfil de dados a ele.

Como alternativa, você pode fazer com que a Proteção de dados sensíveis crie automaticamente o contêiner do agente de serviço e o agente de serviço. A Proteção de dados sensíveis concede automaticamente permissões de criação de perfil de dados ao agente de serviço.

Em ambos os casos, se a Proteção de Dados Sensíveis não conceder acesso à criação de perfil de dados para o agente de serviço, um erro será exibido quando você visualizar os detalhes de configuração da verificação.

Para configurações de verificação no nível do projeto, não é preciso um contêiner do agente de serviço. O projeto para o qual você está criando um perfil atende ao propósito do contêiner do agente de serviço. Para executar operações de criação de perfil, a Proteção de dados sensíveis usa o próprio agente de serviço do projeto.

Acesso à criação de perfil de dados no nível da organização ou da pasta

Quando você configura a criação de perfil no nível da organização ou da pasta, a Proteção de dados sensíveis tenta conceder automaticamente o acesso à criação de perfil de dados para o agente de serviço. No entanto, se você não tiver as permissões para conceder papéis do IAM, a Proteção de dados sensíveis não poderá fazer isso em seu nome. Alguém com essas permissões na sua organização, como um administrador do Google Cloud, precisa conceder acesso de criação de perfil de dados ao seu agente de serviço.

Frequência da geração de perfis de dados

Depois de criar uma configuração de verificação de descoberta para um recurso específico, a Proteção de Dados Sensíveis executa uma verificação inicial, criando perfis dos dados no escopo da configuração.

Após a verificação inicial, a proteção de dados sensíveis monitora continuamente o recurso de perfil. Os dados adicionados no recurso são criado automaticamente logo após a adição.

Frequência padrão de reenvio

A frequência padrão de reprocessamento varia de acordo com o tipo de detecção da configuração da verificação:

  • Criação de perfil do BigQuery: para cada tabela, aguarde 30 dias e crie o perfil novamente se houver mudanças no esquema, nas linhas da tabela ou no modelo de inspeção.
  • Perfil do Cloud SQL: para cada tabela, aguarde 30 dias e faça um novo perfil da tabela se ela tiver mudanças no esquema ou no modelo de inspeção.
  • Criação de perfil do Cloud Storage: para cada bucket, aguarde 30 dias e crie o perfil novamente se o modelo de inspeção tiver mudado.
  • Perfil da Vertex AI: para cada conjunto de dados, aguarde 30 dias e redefina o perfil se o modelo de inspeção tiver mudado.
  • Criação de perfil do Amazon S3: para cada bucket, aguarde 30 dias e crie o perfil novamente se o modelo de inspeção tiver mudado.

Como personalizar a frequência de reenvio

Na configuração da verificação, é possível personalizar a frequência de reenvio de dados criando uma ou mais programações para diferentes subconjuntos de dados.

As seguintes frequências de reenvio estão disponíveis:

  • Não gerar um novo perfil: nunca gere um novo perfil depois que os perfis iniciais forem gerados.
  • Redefinir perfil diariamente: aguarde 24 horas antes de redefinir o perfil.
  • Gerar um novo perfil semanalmente: aguarde 7 dias antes de gerar um novo perfil.
  • Gerar um novo perfil mensalmente: aguarde 30 dias antes de gerar um novo perfil.

Redefinir o perfil em uma programação

Na configuração da verificação, é possível especificar se um subconjunto de dados precisa ser redefinido regularmente, independentemente de ter passado por mudanças. A frequência definida especifica quanto tempo precisa passar entre as operações de criação de perfil. Por exemplo, se você definir a frequência como semanal, a Proteção de Dados Sensíveis vai criar o perfil de um recurso de dados sete dias depois do último perfil.

Redefinição de perfil na atualização

Na configuração de verificação, é possível especificar eventos que podem acionar operações de reprofilagem. Exemplos desses eventos são atualizações de modelos de inspeção.

Quando você seleciona esses eventos, a programação definida especifica o tempo mais longo que a Proteção de dados sensíveis espera para que as atualizações se acumulem antes de redefinir o perfil dos dados. Se nenhuma mudança relevante, como alterações no esquema ou no modelo de inspeção, ocorrer no período especificado, nenhum dado será redefinido. Quando a próxima mudança aplicável ocorre, os dados afetados são redefinidos na próxima oportunidade, que é determinada por vários fatores, como a capacidade de máquina disponível ou as unidades de assinatura compradas. A Proteção de dados sensíveis vai começar a esperar que as atualizações se acumulem novamente de acordo com a programação definida.

Por exemplo, suponha que a configuração da verificação esteja definida para gerar um novo perfil mensalmente na mudança de esquema. Os perfis de dados foram criados pela primeira vez no dia 0. Nenhuma mudança de esquema ocorre até o dia 30, então nenhum dado é refeito. No dia 35, a primeira mudança de esquema ocorre. A Proteção de Dados Sensíveis cria um novo perfil dos dados atualizados na próxima oportunidade. Em seguida, o sistema aguarda mais 30 dias para que as atualizações do esquema se acumulem antes de redefinir o perfil de todos os dados atualizados.

A partir do início da repetição, pode levar até 24 horas para que a operação seja concluída. Se o atraso durar mais de 24 horas e você estiver no modo de preço de assinatura, confirme se você tem capacidade restante para o mês.

Para exemplos de cenários, consulte Exemplos de preços de criação de perfil de dados.

Para forçar o serviço de descoberta a criar um novo perfil dos seus dados, consulte Forçar uma operação de redefinição de perfil.

Criação de perfis de desempenho

O tempo necessário para criar o perfil dos seus dados varia de acordo com vários fatores, incluindo, mas não se limitando a:

  • Número de recursos de dados que estão sendo perfilados
  • Tamanhos dos recursos de dados
  • Para tabelas, o número de colunas
  • Para tabelas, os tipos de dados nas colunas

Portanto, o desempenho da Proteção de Dados Sensíveis em uma inspeção ou tarefa de criação de perfil anterior não indica como ela vai se comportar em tarefas de criação de perfil futuras.

Retenção de perfis de dados

A Proteção de Dados Sensíveis retém a versão mais recente de um perfil de dados por 13 meses. Quando a Proteção de Dados Sensíveis reformula um recurso de dados, o sistema substitui os perfis atuais desse recurso por novos.

Nos exemplos de cenários a seguir, suponhamos que a frequência de criação de perfil padrão do BigQuery esteja em vigor:

  • Em 1o de janeiro, a Proteção de Dados Sensíveis criou a Tabela A. A Tabela A não muda em mais de um ano e, por isso, não tem perfis novamente. Nesse caso, a Proteção de dados sensíveis retém os perfis de dados da tabela A por 13 meses antes de excluí-los.

  • Em 1o de janeiro, a Proteção de Dados Sensíveis criou a Tabela A. Dentro do mês, alguém na sua organização atualiza o esquema dessa tabela. Devido a essa alteração, o mês seguinte, a Proteção de Dados Sensíveis reformula automaticamente a Tabela A. Os perfis de dados recém-gerados substituem os que foram criados em janeiro.

Para informações sobre como a Proteção de Dados Sensíveis cobra pela criação de perfil de dados, consulte Preços de descoberta.

Se você quiser manter os perfis de dados por tempo indeterminado ou manter um registro das mudanças realizadas, avalie a possibilidade de salvar os perfis de dados no BigQuery ao configurar a criação de perfis. Você escolhe em qual conjunto de dados do BigQuery salvar os perfis e controla a política de expiração da tabela para esse conjunto de dados.

Como substituir configurações de verificação

Só é possível criar uma configuração de verificação para cada combinação de escopo e tipo de descoberta. Por exemplo, é possível criar apenas uma configuração de verificação no nível da organização para criar perfis de dados do BigQuery e uma configuração de verificação no nível da organização para a descoberta de segredos. Da mesma forma, é possível criar apenas uma configuração de verificação para envolvidos no projeto para a criação de perfil de dados do BigQuery e uma configuração de verificação para envolvidos no projeto para a descoberta de segredos.

Se duas ou mais configurações de verificação ativas tiverem o mesmo projeto e tipo de descoberta no escopo, as seguintes regras serão aplicadas:

  • Entre as configurações de verificação no nível da organização e da pasta, a mais próxima do projeto poderá executar a descoberta para esse projeto. Essa regra se aplica mesmo que uma configuração de verificação no nível do projeto com o mesmo tipo de descoberta também exista.
  • A Proteção de dados sensíveis trata as configurações de verificação no nível do projeto independentemente das configurações no nível da organização e da pasta. Uma configuração de verificação criada para envolvidos no projeto não pode substituir uma configuração criada para uma pasta ou organização mãe.

Considere o exemplo a seguir, em que há três configurações de verificação ativas. Suponha que todas essas configurações de verificação sejam para a criação de perfis de dados do BigQuery.

Diagrama de uma hierarquia de recursos com uma configuração de verificação aplicada
              a uma organização, uma pasta e um projeto

Aqui, a Configuração de verificação 1 se aplica a toda a organização, a Configuração de verificação 2 se aplica à pasta Equipe B e a Configuração de verificação 3 se aplica ao projeto Produção. Neste exemplo:

  • A Proteção de dados sensíveis cria um perfil de todas as tabelas em projetos que não estão na pasta Equipe B de acordo com a Configuração de verificação 1.
  • A Proteção de dados sensíveis cria um perfil de todas as tabelas em projetos na pasta Equipe B, incluindo tabelas no projeto Produção, de acordo com a Configuração de verificação 2.
  • A Proteção de dados sensíveis cria um perfil de todas as tabelas no projeto Produção de acordo com a Configuração de verificação 3.

Neste exemplo, a Proteção de dados sensíveis gera dois conjuntos de perfis para o projeto Produção, um conjunto para cada uma das seguintes configurações de verificação:

  • Configuração da verificação 2
  • Configuração da verificação 3

No entanto, mesmo que haja dois conjuntos de perfis para o mesmo projeto, eles não serão exibidos juntos no painel. Você só vai encontrar os perfis que foram gerados no recurso (organização, pasta ou projeto) e na região que você está visualizando.

Para mais informações sobre a hierarquia de recursos do Google Cloud, consulte Hierarquia de recursos.

Snapshot de perfis de dados

Cada perfil de dados inclui um snapshot da configuração da verificação e do modelo de inspeção usado para gerá-lo. Use esse snapshot para verificar as configurações usadas para gerar um determinado perfil de dados.

Considerações sobre a residência de dados do Google Cloud

Esta seção se aplica apenas à descoberta de dados sensíveis para recursos do Google Cloud. Para considerações sobre a residência de dados relacionadas aos dados do Amazon S3, consulte Descoberta de dados sensíveis para dados do Amazon S3.

A Proteção de Dados Sensíveis foi projetada para oferecer suporte à residência de dados. Se você precisar obedecer aos requisitos de residência de dados, considere os seguintes pontos:

Modelos de inspeção regional

Esta seção se aplica apenas à descoberta de dados sensíveis para recursos do Google Cloud. Para considerações sobre a residência de dados relacionadas aos dados do Amazon S3, consulte Descoberta de dados sensíveis para dados do Amazon S3.

A Proteção de Dados Sensíveis processa seus dados na mesma região em que eles são armazenados. Ou seja, seus dados não saem da região atual.

Além disso, os modelos de inspeção só podem ser usados para criar perfis de dados que residem na mesma região desse modelo. Por exemplo, se você configurar a descoberta para usar um modelo de inspeção armazenado na região us-west1, a Proteção de dados sensíveis só poderá criar o perfil de dados nessa região.

É possível definir um modelo de inspeção dedicado para cada região com dados. Se você fornecer um modelo de inspeção armazenado na região global, a Proteção de Dados Sensíveis vai usar esse modelo para dados em regiões sem um modelo de inspeção dedicado.

A tabela a seguir mostra exemplos de cenários:

Cenário Suporte
Verificar dados na região us usando um modelo de inspeção da região us. Compatível
Verificar dados na região global usando um modelo de inspeção da região us. Incompatível
Verificar dados na região us usando um modelo de inspeção da região global. Compatível
Verificar dados na região us usando um modelo de inspeção da região us-east1. Incompatível
Verificar dados na região us-east1 usando um modelo de inspeção da região us. Incompatível
Verificar dados na região us usando um modelo de inspeção da região asia. Incompatível

Configuração do perfil de dados

Esta seção se aplica apenas à descoberta de dados sensíveis para recursos do Google Cloud. Para considerações sobre a residência de dados relacionadas aos dados do Amazon S3, consulte Descoberta de dados sensíveis para dados do Amazon S3.

Quando a Proteção de dados sensíveis cria perfis de dados, ela tira um snapshot da configuração de verificação e do modelo de inspeção e os armazena em cada perfil de dados da tabela ou perfil de dados do armazenamento de arquivos. Se você configurar a descoberta para usar um modelo de inspeção da região global, a Proteção de dados sensíveis vai copiar esse modelo para qualquer região que tenha dados para os quais você quer criar um perfil. Da mesma forma, ele copia a configuração de verificação para essas regiões.

Considere este exemplo: o Projeto A contém a Tabela 1. A Tabela 1 está na região us-west1. A configuração de verificação está na região us-west2, e o modelo de inspeção está na região global.

Quando a Proteção de Dados Sensíveis verifica o Projeto A, ela cria perfis de dados para a Tabela 1 e os armazena na região us-west1. O perfil de dados da tabela da Tabela 1 contém cópias da configuração de verificação e do modelo de inspeção usado na operação de criação do perfil.

Se você não quiser que seu modelo de inspeção seja copiado para outras regiões, não configure a Proteção de dados sensíveis para verificar dados nessas regiões.

Armazenamento regional de perfis de dados

Esta seção se aplica apenas à descoberta de dados sensíveis para recursos do Google Cloud. Para considerações sobre a residência de dados relacionadas aos dados do Amazon S3, consulte Descoberta de dados sensíveis para dados do Amazon S3.

A Proteção de dados sensíveis processa seus dados na região ou multirregião em que eles estão e armazena os perfis de dados gerados na mesma região ou multirregião.

Para visualizar perfis de dados no console do Google Cloud, primeiro é necessário selecionar a região em que eles estão. Se você tiver dados em várias regiões, será necessário alternar as regiões para visualizar cada conjunto de perfis.

Regiões incompatíveis

Esta seção se aplica apenas à descoberta de dados sensíveis para recursos do Google Cloud. Para considerações sobre a residência de dados relacionadas aos dados do Amazon S3, consulte Descoberta de dados sensíveis para dados do Amazon S3.

Se você tiver dados em uma região que não é compatível com a Proteção de dados sensíveis, o serviço de descoberta vai ignorar esses recursos de dados e mostrar um erro quando você visualizar os perfis de dados.

Locais multirregionais

A Proteção de dados sensíveis trata uma multirregião como uma região, e não uma coleção de regiões. Por exemplo, a multirregião us e a região us-west1 são tratadas como duas regiões distintas no que diz respeito à residência de dados.

Recursos zonais

A Proteção de dados sensíveis é um serviço regional e multirregional. Ela não distingue as zonas. Para um recurso zonal compatível, como uma instância do Cloud SQL, os dados são processados na região atual, mas não necessariamente na zona atual. Por exemplo, se uma instância do Cloud SQL for armazenada na zona us-central1-a, a Proteção de Dados Sensíveis processará e armazenará os perfis de dados na região us-central1.

Para informações gerais sobre locais do Google Cloud, consulte Geografia e regiões.

Compliance

Para informações sobre como a Proteção de dados sensíveis processa seus dados e ajuda você a atender aos requisitos de compliance, consulte Segurança de dados.

A seguir