Problemas conhecidos

Nesta página, listamos os problemas conhecidos da Proteção de Dados Sensíveis, além de maneiras de evitar ou se recuperar dos problemas a seguir.

Armazenar resultados no BigQuery

Quando um job ou uma verificação de descoberta está armazenando resultados no BigQuery, um erro Already exists aparece nos registros. O erro não indica que há um problema. Os resultados serão armazenados conforme o esperado.

Verificação do BigQuery

Nesta seção, descrevemos os problemas que podem ocorrer ao inspecionar ou criar perfis de dados do BigQuery.

Problemas comuns às operações de inspeção e criação de perfil

Os problemas a seguir são aplicáveis às operações de inspeção e criação de perfil do BigQuery.

Não é possível verificar linhas com segurança no nível da linha

As políticas de segurança no nível da linha podem impedir que a Proteção de Dados Sensíveis inspecione e crie perfis das tabelas protegidas do BigQuery. Se você tiver políticas de segurança no nível da linha aplicadas às tabelas do BigQuery, recomendamos definir um filtro TRUE e incluir o agente de serviço na lista de beneficiários:

Linhas duplicadas

Ao gravar dados em uma tabela do BigQuery, a Proteção de Dados Sensíveis pode gravar linhas duplicadas.

Dados transmitidos recentemente

A Proteção de Dados Sensíveis não verifica dados transmitidos recentemente (antes conhecidos como buffer de streaming). Para mais informações, consulte Disponibilidade de dados de streaming na documentação do BigQuery.

Problemas de inspeção do BigQuery

Os problemas a seguir são aplicáveis apenas a operações de inspeção em dados do BigQuery. Eles não afetam os perfis de dados.

As descobertas exportadas não têm valores para o campo row_number

Quando você configura a Proteção de Dados Sensíveis para salvar as descobertas no BigQuery, o campo location.content_locations.record_location.record_key.big_query_key.row_number na tabela do BigQuery gerada é inferido no momento em que a tabela de entrada é verificada. O valor é não determinístico, não pode ser consultado e pode ser nulo para jobs de inspeção.

Se você precisar identificar linhas específicas em que as descobertas estão presentes, especifique inspectJob.storageConfig.bigQueryOptions.identifyingFields no momento da criação do job.

Os campos de identificação podem ser encontrados na tabela do BigQuery gerada, no campo location.content_locations.record_location.record_key.id_values.

Como limitar as verificações ao novo conteúdo do BigQuery

Se você estiver limitando as verificações apenas a novos conteúdos e usar a API BigQuery Storage Write (gRPC) para preencher a tabela de entrada, a Proteção de Dados Sensíveis poderá pular a verificação de algumas linhas.

Para mitigar esse problema, no job de inspeção, verifique se o timestampField do objeto TimespanConfig é um carimbo de data/hora de confirmação gerado automaticamente pelo BigQuery. No entanto, ainda não há garantia de que nenhuma linha será ignorada, porque a Proteção de Dados Sensíveis não lê dados transmitidos recentemente.

Se você quiser gerar automaticamente carimbos de data/hora de confirmação para uma coluna e usar a API de streaming legada para preencher a tabela de entrada, faça o seguinte:

  1. No esquema da tabela de entrada, verifique se a coluna de carimbo de data/hora é do tipo TIMESTAMP.

    Esquema de exemplo

    O exemplo a seguir define o campo commit_time_stamp e define o tipo como TIMESTAMP:

    ...
{
 "name": "commit_time_stamp",
 "type": "TIMESTAMP"
}
...

  2. No campo rows[].json do método tabledata.insertAll, verifique se os valores na coluna de carimbo de data/hora estão definidos como AUTO.

    Exemplo de JSON

    O exemplo a seguir define o valor do campo commit_time_stamp como AUTO:

    {
  ...
  "commit_time_stamp": "AUTO",
  ...
}

Limitar as verificações definindo uma porcentagem ou um número máximo de linhas

Quando você define um limite de amostragem com base em uma porcentagem do número total de linhas da tabela (rowsLimitPercent), a Proteção de Dados Sensíveis pode inspecionar mais linhas do que o esperado. Se você precisar definir um limite rígido para o número de linhas a serem verificadas, recomendamos definir um número máximo de linhas (rowsLimit).

Problemas de criação de perfil do BigQuery

Os problemas a seguir são aplicáveis apenas a operações de criação de perfil em dados do BigQuery. Para saber mais, consulte Perfis de dados para dados do BigQuery.

Organizações ou projetos com mais de 500 milhões de tabelas

A Proteção de Dados Sensíveis vai retornar um erro se você tentar criar o perfil de uma organização ou um projeto com mais de 500 milhões de tabelas. Se você encontrar esse erro, siga as instruções na mensagem de erro.

Se a contagem de tabelas da sua organização tiver mais de 500 milhões de tabelas e você tiver um projeto com uma contagem de tabelas menor, tente fazer uma verificação no nível do projeto.

Para saber mais sobre os limites da tabela e da coluna, consulte Limites da criação de perfil de dados.

Modelos de inspeção

O modelo de inspeção precisa estar na mesma região que os dados a serem analisados. Se você tiver dados em várias regiões, use vários modelos de inspeção, um para cada região em que você tem dados. Também é possível usar um modelo de inspeção armazenado na região global. Se você incluir um modelo na região global, a Proteção de Dados Sensíveis o usará para todos os dados que não tiverem um modelo específico da região. Para mais informações, consulte Considerações sobre residência de dados.

InfoTypes armazenados

Um infoType armazenado (também conhecido como detector de dicionário personalizado armazenado) referenciado no modelo de inspeção precisa ser armazenado em um dos seguintes locais:

  • A região global.
  • A mesma região do modelo de inspeção.

Caso contrário, a operação de criação de perfil falhará com o erro Resource not found.

Visibilidade de recursos

Em um perfil de dados de tabela, a classificação de visibilidade de recursos atribuída a uma tabela do BigQuery depende da visibilidade do conjunto de dados que contém a tabela, e não da visibilidade da tabela. Portanto, se as permissões do IAM de uma tabela forem diferentes das permissões do IAM do conjunto de dados, a visibilidade do recurso da tabela indicada no perfil de dados poderá estar incorreta. Esse problema afeta a descoberta do BigQuery e a descoberta da Vertex AI.

No console do Google Cloud , a visibilidade do recurso é indicada no campo Público do perfil de dados da tabela. Na API Cloud Data Loss Prevention, a visibilidade do recurso é indicada no campo resourceVisibility do TableDataProfile.

Carimbo de data/hora de expiração incorreto para tabelas que não expiram

Entre julho de 2025 e junho de 2026, alguns perfis de dados de tabela salvos no BigQuery continham um carimbo de data/hora 1970-01-01 incorreto em vez de NULL em expiration_time para tabelas que não expiram.

Verificação do Cloud Storage

Nesta seção, descrevemos os problemas que podem ocorrer ao inspecionar ou desidentificar dados.

Não é possível inspecionar arquivos XLSX estritos

Um arquivo com uma extensão .xlsx pode ser de um dos dois tipos. Um tipo é uma planilha Strict Office Open XML, que não é compatível com a Proteção de Dados Sensíveis. O outro tipo é uma pasta de trabalho padrão do Microsoft Excel, que é compatível.

Arquivos estruturados sendo verificados no modo binário

Em alguns casos, os arquivos que normalmente são verificados no modo de análise estruturada podem ser verificados no modo binário, que não inclui as melhorias do modo de análise estruturada. Para mais informações, consulte Como verificar arquivos estruturados no modo de análise estruturada.

Como desidentificar arquivos delimitados

Quando você desidentifica um arquivo delimitado (por exemplo, um arquivo CSV) com um job de inspeção, a saída pode ter células vazias adicionais em algumas linhas. Uma solução alternativa para evitar essas células extras é desidentificar os dados usando o método content.deidentify.

Descoberta para o Cloud SQL

Descobertas duplicadas do Security Command Center

A criação de perfis de dados do Cloud SQL é compatível com a publicação de descobertas no Security Command Center.

Antes de 25 de abril de 2024, um bug fazia com que a Proteção de Dados Sensíveis gerasse descobertas duplicadas para instâncias do Cloud SQL no Security Command Center. Essas descobertas foram geradas com IDs exclusivos, mas pertencem às mesmas instâncias do Cloud SQL. O problema foi resolvido, mas as descobertas duplicadas ainda existem. É possível silenciar as duplicatas para ocultá-las na página Descobertas do Security Command Center.

Descoberta para o Amazon S3

As descobertas do Amazon S3 que a Proteção de Dados Sensíveis envia ao Security Command Center podem não ter informações sobre o ID da conta da AWS ou o nome de exibição do recurso afetado. Isso geralmente acontece nos seguintes casos:

  • O conector da AWS era válido apenas por cerca de 24 horas quando a descoberta foi enviada ao Security Command Center.
  • A conta da AWS foi incluída no conector da AWS por apenas cerca de 24 horas quando a descoberta foi enviada ao Security Command Center.

Para resolver esse problema, após aproximadamente 24 horas, gere novamente os perfis de dados excluindo-os ou definindo uma programação de criação de perfil. Os detalhes completos da descoberta são enviados ao Security Command Center.

Análise inteligente de documentos

Esta seção contém problemas conhecidos relacionados à análise de documentos.

O objeto DocumentLocation não foi preenchido

O campo location.content_locations.document_location.file_offset não é preenchido para o modo de verificação de Análise inteligente de documentos.

Detecção

Os problemas conhecidos a seguir descrevem problemas com a detecção, independentemente da operação que você está realizando: inspeção, desidentificação ou descoberta.

Palavras do dicionário

Palavras do dicionário que contêm caracteres no Plano Multilíngue Suplementar do padrão Unicode podem gerar descobertas inesperadas. Exemplos desses caracteres são emojis, símbolos científicos e scripts históricos.