Nesta página, descrevemos o serviço de descoberta de dados sensíveis. Esse serviço ajuda a determinar onde estão os dados sensíveis e de alto risco na sua organização.
Visão geral
Com o serviço de descoberta, você protege os dados da 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 da criação de perfil. Em seguida, são gerados perfis dos dados. Enquanto a configuração de descoberta estiver ativa, a proteção de dados sensíveis criará automaticamente um perfil 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 da verificação de 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 detalhamento. Por exemplo, quando você cria um perfil de dados do BigQuery, os perfis são gerados nos níveis do projeto, da tabela e da coluna.
A imagem a seguir mostra uma lista de perfis de dados no nível da coluna. Clique na imagem para ampliá-la.
Para conferir uma lista de insights e metadados incluídos em cada perfil de dados, consulte Referência de métricas.
Para mais informações sobre a hierarquia de recursos do Google Cloud, consulte Hierarquia de recursos.
Descoberta de dados do BigQuery
Quando você cria perfis de dados do BigQuery, esses perfis são gerados nos níveis do projeto, da tabela e da coluna. Depois de criar o perfil de uma tabela do BigQuery, investigue melhor as descobertas executando uma inspeção profunda.
Para mais informações sobre o BigQuery, consulte a documentação do BigQuery.
Descoberta de dados do Cloud SQL
Quando você cria perfis de dados do Cloud SQL, os perfis de dados são gerados nos níveis do projeto, da tabela e da coluna. Antes que a descoberta possa começar, forneça os detalhes de conexão de cada instância do Cloud SQL para a criação de perfil.
Consulte a documentação do Cloud SQL para mais informações sobre ele.
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, você define o escopo da operação de descoberta e o tipo de dados para o qual você quer criar um perfil. Na configuração da verificação, é possível definir filtros para especificar subconjuntos de dados para os quais você quer criar um perfil ou pular. Também é possível definir a programação da 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.
Recursos suportados
Esta seção descreve os recursos que a proteção de dados sensíveis pode criar.
BigQuery e BigLake
Tabelas de perfis de proteção de dados confidenciais compatíveis com a API BigQuery Storage Read, incluindo:
- Tabelas padrão do BigQuery
- Tabelas do BigLake armazenadas no Cloud Storage
Não há suporte para as seguintes ações:
- Tabelas do BigQuery Omni.
- Tabelas em que o tamanho dos dados serializados de linhas individuais excedem o tamanho máximo de dados serializados compatível com a API BigQuery Storage Read: 128 MB.
- Tabelas externas que não são do BigLake, como as Planilhas Google.
Cloud SQL
A proteção de dados sensíveis pode criar perfis de tabelas do Cloud SQL.
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 e ver perfis de dados | Administrador do DLP (roles/dlp.admin)
|
|
| Crie um projeto para ser usado como o contêiner do agente de serviço1 | roles/resourcemanager.projectCreatorCriador do projeto |
|
| Conceder acesso à criação de perfil de dados2 | Uma das seguintes opções:
|
|
| Ver perfis de dados (somente leitura) | Leitor de perfis de dados da DLP (roles/dlp.dataProfilesReader) |
|
Leitor de DLP (roles/dlp.reader) |
|
1 Se você não tiver o papel Criador de projetos (roles/resourcemanager.projectCreator), ainda poderá criar uma configuração de verificação, mas o contêiner do agente de serviço usado precisará ser um projeto existente.
2Se você não tiver o papel de Administrador da organização (roles/resourcemanager.organizationAdmin) ou Administrador de segurança (roles/iam.securityAdmin), ainda poderá criar uma configuração de verificação. Depois que você criar a configuração da verificação, alguém em sua organização que tenha um desses papéis precisa conceder acesso de descoberta ao agente de serviço para o 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)
|
|
| Ver perfis de dados (somente leitura) | Leitor de perfis de dados da DLP (roles/dlp.dataProfilesReader) |
|
Leitor de DLP (roles/dlp.reader) |
|
Configuração da verificação de descoberta
Uma configuração de verificação de descoberta ou configuração de perfil de dados especifica qual recurso (uma organização, pasta ou projeto) criar, qual modelo de inspeção usar e o que fazer com os resultados. Ele também contém detalhes administrativos, como o contêiner do agente de serviços a ser associado à verificação e a conta de faturamento a ser usada.
Tipos de descoberta
O serviço de descoberta é compatível com os seguintes tipos de operações:
- Criação de perfil de dados do BigQuery
- Criação de perfil de dados do Cloud SQL
- Descoberta de secrets (nenhum perfil de dados gerado)
Escopos de configuração da verificação
É possível criar uma configuração de verificação nos seguintes níveis:
- Organização
- Pasta
- Projeto
- Tabela (modo de teste)
Nos níveis 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 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 para envolvidos no projeto sempre pode criar o perfil do projeto de destino e não compete com outras configurações no nível da pasta ou organização pai.
A configuração de verificação no nível da tabela ajuda a explorar e testar a criação de perfis em uma única tabela.
Local de configuração da verificação
Na primeira vez que você criar uma configuração de verificação, especifique onde quer que a Proteção de Dados Sensíveis armazene-a. 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 para criação de perfil 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 ou 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ção (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ê alterar um modelo de inspeção usado pela configuração de verificação, as alterações serão aplicadas apenas às verificações futuras. Essa ação não causa uma operação de reperfil nos dados.
Se você quiser que as alterações no modelo de inspeção acionem operações de criação de novo perfil nos dados afetados, adicione ou atualize uma programação na configuração de verificação e ative a opção para criar um novo perfil dos dados quando o modelo de inspeção mudar. Para mais informações, consulte Frequência de geração do perfil de dados.
Você precisa ter um modelo de inspeção em cada região em que há dados para criar um perfil. Se você quiser usar um único modelo para várias regiões, utilize um modelo armazenado na região global. Se as políticas organizacionais impedirem que você crie um modelo de inspeção global, defina um modelo de inspeção dedicado para cada região. Para mais
informações, consulte Considerações
sobre 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 utilizados 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
Ao criar 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 de 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 faturadas 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 é uma conta serviço gerenciado pelo Google que a Proteção de Dados Sensíveis usa para criar o perfil dos dados em seu nome. É necessário ter um agente de serviço para se autenticar 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 o perfil dos dados. O ID do agente de serviço está no seguinte formato:
service-PROJECT_NUMBER@dlp-api.iam.gserviceaccount.com
Aqui, o 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 tiver um agente de serviço, a proteção de dados sensíveis vai conceder as permissões do IAM necessárias a esse agente. Se o projeto não tiver um agente de serviço, a Proteção de Dados Sensíveis criará um e concederá automaticamente permissões de criação de perfil de dados a ele.
Outra opção é fazer com que a proteção de dados sensíveis crie automaticamente o contêiner 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 ao agente de serviço, um erro será mostrado ao visualizar os detalhes da 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 desse 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 acesso à criação de perfil de dados ao 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 essa ação em seu nome. Alguém com essas permissões na organização, como um administrador do Google Cloud, precisa conceder acesso de criação de perfil de dados ao agente de serviço.
Frequência de geração do perfil de dados
Por padrão, a proteção de dados sensíveis cria o perfil dos seus dados da seguinte maneira:
Depois de criar uma configuração de verificação para um recurso específico, a proteção de dados sensíveis realiza uma verificação inicial, criando o perfil dos dados no escopo da configuração da verificação. Após a verificação inicial, ele monitora continuamente esses dados em busca de quaisquer adições ou alterações.
A proteção de dados sensíveis cria o perfil das novas tabelas adicionadas logo depois de adicioná-las.
A cada 30 dias, a proteção de dados sensíveis recria um perfil das tabelas atuais que passaram por mudanças de esquema nos últimos 30 dias.
Na configuração da verificação, é possível personalizar a frequência da criação de perfil criando uma ou mais programações para diferentes subconjuntos de dados. É possível especificar subconjuntos de dados para os quais você nunca quer criar perfis. Também é possível especificar os tipos de eventos que acionam operações de reformulação de perfil. Exemplos desses eventos são as atualizações de esquema de tabelas e de modelos de inspeção.
As seguintes opções de criação de perfil estão disponíveis:
- Não criar novo perfil: nunca crie um novo perfil depois que os perfis iniciais forem gerados.
- Gerar um novo perfil diariamente: aguarde 24 horas antes de criar um novo perfil com dados atualizados.
- Gerar um novo perfil semanalmente: aguarde sete dias antes de criar um novo perfil com dados atualizados.
- Gerar um novo perfil mensalmente: aguarde 30 dias antes de criar um novo perfil dos dados atualizados.
A programação especifica o período mais longo que a proteção de dados sensíveis aguarda o acúmulo de atualizações antes de criar um novo perfil dos dados. Se nenhuma mudança aplicável, como alterações de esquema ou de modelo de inspeção, ocorrer no período especificado, nenhum dado será criado de novo. Quando ocorre a próxima mudança aplicável, os dados afetados recebem um novo perfil na próxima oportunidade, o que é determinado por vários fatores, como a capacidade da máquina disponível ou as unidades de assinatura compradas. A proteção de dados sensíveis começa a esperar que as atualizações sejam acumuladas novamente de acordo com a programação definida.
Por exemplo, suponha que sua configuração de verificação esteja definida para gerar um novo perfil mensalmente com base na mudança do esquema. Os perfis de dados foram criados no dia zero. Nenhuma mudança de esquema ocorre até o dia 30, então nenhum dado é criado de novo. No dia 35, ocorre a primeira mudança de esquema. 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 de esquema sejam acumuladas antes de criar um novo perfil dos dados atualizados.
A partir do momento em que a recriação de perfis começa, pode levar até 24 horas para a operação ser concluída. Se o atraso durar mais de 24 horas e você estiver no modo de preços da assinatura, confirme se há capacidade restante para o mês.
Para exemplos de cenários, consulte Exemplos de preços de criação de perfil de dados.
Desempenho da criação de perfil
O tempo necessário para criar o perfil dos dados varia de acordo com vários fatores, incluindo, entre outros:
- Número de tabelas com perfil sendo criado
- Tamanhos das tabelas
- Número de colunas nas tabelas
- Tipos de dados nas colunas
Portanto, o desempenho da proteção de dados sensíveis em uma inspeção ou tarefa de criação anterior não indica como ela será em futuras tarefas de criação de perfil.
Retenção de perfis de dados
A proteção de dados sensíveis mantém a versão mais recente de um perfil de dados por 13 meses. Quando a proteção de dados sensíveis recria um perfil de uma tabela atualizada, ela substitui os perfis de dados dessa tabela por novos.
Considere os cenários a seguir:
Em 1o de janeiro, a proteção de dados sensíveis cria o perfil da 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 manté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 cria o perfil da Tabela A. No decorrer do mês, alguém em sua organização atualiza o esquema dessa tabela. Por causa dessa mudança, no mês seguinte, a proteção de dados sensíveis recria automaticamente o perfil da 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 perfis de tabelas novas e modificadas, consulte Preços da criação de perfil de dados.
Se você quiser manter os perfis de dados indefinidamente ou manter um registro das alterações feitas, considere salvar os perfis de dados no BigQuery ao configurar a criação de perfil. 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
É possível criar apenas 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 em nível de organização para a criação de perfil de dados do BigQuery e uma configuração de verificação em nível de organização para descoberta de secrets. Da mesma forma, só é possível criar 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 secrets.
Se duas ou mais configurações de verificação ativas tiverem o mesmo projeto e tipo de descoberta no escopo, as regras a seguir 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 desse projeto. Essa regra é válida mesmo se também existir uma configuração de verificação para envolvidos no projeto com o mesmo tipo de descoberta.
- 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 perfil de dados do BigQuery.
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 perfis 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 confidenciais cria perfis de todas as tabelas em projetos na pasta Equipe B, incluindo as tabelas no projeto Production, de acordo com a Configuração de verificação 2.
- A proteção de dados confidenciais cria perfis de todas as tabelas no projeto Production 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 Production, um para cada uma das configurações de verificação a seguir:
- 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ó verá os perfis que foram gerados no recurso (organização, pasta ou projeto) e na região que 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 perfil de dados específico.
Considerações sobre a residência de dados
A proteção de dados sensíveis foi criada para oferecer suporte à residência de dados. Se você precisar obedecer aos requisitos de residência de dados, considere os seguintes pontos:
Regiões de inspeção
A proteção de dados sensíveis inspeciona seus dados na mesma região em que estão armazenados. Ou seja, os 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 o
Data Profiler 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 onde há dados.
Se você fornecer um modelo de inspeção armazenado na região global,
a Proteção de Dados Sensíveis vai usá-lo 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. |
Sem suporte |
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. |
Sem suporte |
Verificar dados na região us-east1 usando um modelo de inspeção da
região us. |
Sem suporte |
Verificar dados na região us usando um modelo de inspeção da
região asia. |
Sem suporte |
Configuração do perfil de dados
Quando a proteção de dados sensíveis cria perfis de dados, ela tira um snapshot da
configuração da verificação e
do modelo de inspeção e os armazena em cada perfil de dados da tabela. Se você configurar
o Data Profiler para usar um modelo de inspeção da
região global, a Proteção de Dados Sensíveis copiará esse modelo para qualquer
região que tenha dados para o 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 o 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
Depois de inspecionar seus dados, a proteção de dados sensíveis gera perfis de dados. Ele armazena cada perfil de dados na mesma região em que os dados de destino são armazenados, que também é onde a inspeção é processada. Para visualizar perfis de dados no Console do Google Cloud, primeiro é necessário selecionar a região em que eles residem. Se você tiver dados em várias regiões, será necessário trocar de região para visualizar cada conjunto de perfis.
Regiões incompatíveis
Se você tiver tabelas em uma região que a Proteção de Dados Sensíveis não oferece suporte, ela vai pular essas tabelas 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 um conjunto 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.
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
Leia a postagem do blog sobre Identidade e segurança Gerenciamento automático de risco de dados para o BigQuery usando a proteção de dados sensíveis.
Saiba como estimar o custo da criação de perfil de dados.
Saiba como criar o perfil de dados nos níveis da organização, pasta ou projeto.
Saiba como a proteção de dados sensíveis calcula os níveis de risco e sensibilidade dos dados das tabelas e colunas.
Saiba como mediar as descobertas do criador de perfil de dados.
Saiba como resolver problemas com o criador de perfil de dados.