Esta página apresenta problemas conhecidos com a proteção de dados confidenciais, juntamente com formas de evitar ou recuperar dos seguintes problemas.
Armazenar resultados no BigQuery
Quando uma tarefa ou uma análise de deteção está a armazenar resultados no BigQuery, é apresentado um erro Already exists
nos registos. O erro não indica que existe um problema. Os resultados são armazenados conforme esperado.
Análise do BigQuery
Esta secção descreve os problemas que pode encontrar ao inspecionar ou criar perfis de dados do BigQuery.
Problemas comuns às operações de inspeção e criação de perfis
Os seguintes problemas aplicam-se às operações de inspeção e criação de perfis do BigQuery.
Não é possível analisar linhas com segurança ao nível da linha
As políticas de segurança ao nível da linha podem impedir que a proteção de dados confidenciais inspecione e crie perfis das tabelas BigQuery protegidas. Se tiver políticas de segurança ao nível da linha aplicadas às tabelas do BigQuery, recomendamos que defina um filtro TRUE e inclua o agente de serviço na lista de beneficiários:
- Se estiver a criar perfis de dados ao nível da organização ou da pasta, inclua o agente de serviço do projeto do contentor na lista de beneficiários.
- Se estiver a analisar dados ao nível do projeto ou a executar uma tarefa de inspeção numa tabela, inclua o agente de serviço do projeto na lista de beneficiários.
Duplicar linhas
Ao escrever dados numa tabela do BigQuery, a proteção de dados confidenciais pode escrever linhas duplicadas.
Dados transmitidos recentemente
A Proteção de dados confidenciais não analisa dados transmitidos recentemente (anteriormente conhecidos como buffer de streaming). Para mais informações, consulte a disponibilidade dos dados de streaming na documentação do BigQuery.
Problemas de inspeção do BigQuery
Os seguintes problemas aplicam-se apenas a operações de inspeção em dados do BigQuery. Não afetam os perfis de dados.
As conclusões exportadas não têm valores para o campo row_number
Quando configura a Proteção de dados confidenciais para guardar 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 é analisada. O seu valor é não determinístico, não pode ser consultado e pode ser nulo para tarefas de inspeção.
Se precisar de identificar linhas específicas onde existem resultados, especifique-as inspectJob.storageConfig.bigQueryOptions.identifyingFields
no momento da criação da tarefa.
Pode encontrar os campos de identificação na tabela do BigQuery gerada, no campo location.content_locations.record_location.record_key.id_values
.
Limitar as análises a novo conteúdo do BigQuery
Se estiver a limitar as análises apenas a novo conteúdo e usar a API Storage Write do BigQuery para preencher a tabela de entrada, a Proteção de dados confidenciais pode ignorar a análise de algumas linhas.
Para mitigar este problema, na tarefa de inspeção, certifique-se de que o timestampField
do objeto
TimespanConfig
é uma data/hora de confirmação gerada automaticamente pelo BigQuery.
No entanto, ainda não existe garantia de que nenhuma linha seja ignorada, porque a proteção de dados confidenciais não lê dados transmitidos recentemente.
Se quiser gerar automaticamente as datas/horas de confirmação de uma coluna e usar a API de streaming antiga para preencher a tabela de entrada, faça o seguinte:
No esquema da tabela de entrada, certifique-se de que a coluna de data/hora é do tipo
TIMESTAMP
.Esquema de exemplo
O exemplo seguinte define o campo
commit_time_stamp
e define o respetivo tipo comoTIMESTAMP
:... { "name": "commit_time_stamp", "type": "TIMESTAMP" } ...
No campo
rows[].json
do métodotabledata.insertAll
, certifique-se de que os valores na coluna de data/hora estão definidos comoAUTO
.Exemplo de JSON
O exemplo seguinte define o valor do campo
commit_time_stamp
comoAUTO
:{ ... "commit_time_stamp": "AUTO", ... }
Limitar as análises definindo uma percentagem ou um número máximo de linhas
Quando define um limite de amostragem com base numa percentagem do número total de linhas da tabela (rowsLimitPercent
), a proteção de dados confidenciais pode inspecionar mais linhas do que o esperado. Se precisar de
colocar um limite rígido no número de linhas a analisar, recomendamos que defina um número máximo
de linhas
(rowsLimit
)
em alternativa.
Problemas de criação de perfis do BigQuery
Os seguintes problemas aplicam-se apenas a operações de criação de perfis em dados do BigQuery. Para mais informações, consulte o artigo Perfis de dados para dados do BigQuery.
Organizações ou projetos com mais de 500 milhões de tabelas
A proteção de dados confidenciais devolve um erro se tentar criar um perfil de uma organização ou um projeto que tenha mais de 500 milhões de tabelas. Se encontrar este 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 tiver um projeto com uma contagem de tabelas inferior, experimente fazer uma análise ao nível do projeto.
Para ver informações sobre os limites de tabelas e colunas, consulte o artigo Limites da análise detalhada de dados.
Modelos de inspeção
O modelo de inspeção tem de estar na mesma região que os dados a serem perfilados. Se tiver dados em várias regiões, use vários modelos de inspeção, um para cada região onde tem dados.
Também pode usar um modelo de inspeção armazenado na região global
.
Se incluir um modelo na região global
, a proteção de dados confidenciais usa-o para todos os dados que não tenham um modelo específico da região. Para mais informações,
consulte as Considerações sobre a residência de dados.
infoTypes armazenados
Um infoType armazenado (também conhecido como um detetor de dicionário personalizado armazenado) referenciado no seu modelo de inspeção tem de ser armazenado num dos seguintes locais:
- A região de
global
. - A mesma região que o modelo de inspeção.
Caso contrário, a operação de criação de perfis falha com o erro Resource not found
.
Visibilidade dos recursos
Num 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. Por conseguinte, se as autorizações IAM de uma tabela diferirem das autorizações IAM do conjunto de dados, a visibilidade dos recursos da tabela indicada no perfil de dados pode estar incorreta. Este problema afeta a descoberta para o BigQuery e a descoberta para o Vertex AI.
Na Google Cloud consola, a visibilidade dos recursos é indicada no campo Público do perfil
dos dados da tabela. Na API Cloud Data Loss Prevention, a visibilidade dos recursos é indicada no campo resourceVisibility
do TableDataProfile
.
Análise do Cloud Storage
Esta secção descreve os problemas que pode encontrar ao inspecionar ou desidentificar dados.
A inspeção de ficheiros XLSX rigorosos não é suportada
Um ficheiro com uma extensão .xlsx
pode ser de um de dois tipos. Um tipo é uma folha de cálculo Strict Office Open XML, que não é suportada pela proteção de dados confidenciais.
O outro tipo é um livro do Microsoft Excel predefinido, que é suportado.
Ficheiros estruturados a serem analisados no modo binário
Em determinados casos, os ficheiros que são normalmente analisados no modo de análise estruturada podem ser analisados no modo binário, que não inclui os melhoramentos do modo de análise estruturada. Para mais informações, consulte o artigo Analisar ficheiros estruturados no modo de análise estruturada.
Remover a identificação de ficheiros delimitados
Quando anula a identificação
de um ficheiro delimitado (por exemplo, um ficheiro CSV) com uma tarefa de inspeção,
a saída pode ter células vazias adicionais em algumas linhas. Uma solução alternativa para evitar estas células adicionais é desidentificar os dados através do método content.deidentify
.
Discovery para Cloud SQL
Resultados duplicados do Security Command Center
A criação de perfis de dados do Cloud SQL suporta a publicação de resultados no Security Command Center.
Antes de 25 de abril de 2024, um erro fazia com que a Proteção de dados confidenciais gerasse ocasionalmente resultados duplicados para instâncias do Cloud SQL no Security Command Center. Estas conclusões foram geradas com IDs de conclusões exclusivos, mas referem-se às mesmas instâncias do Cloud SQL. O problema foi resolvido, mas as conclusões duplicadas ainda existem. Pode desativar o som dos duplicados para os ocultar na página Resultados do Security Command Center.
Descoberta para o Amazon S3
As conclusões do Sensitive Data Protection enviadas para o Security Command Center relativas ao Amazon S3 podem não ter informações sobre o ID da conta da AWS ou o nome a apresentar do recurso afetado. Normalmente, isto acontece nos seguintes casos:
- O conetor da AWS só era válido durante cerca de 24 horas quando a descoberta foi enviada para o Security Command Center.
- A conta da AWS só tinha sido incluída no conector da AWS durante cerca de 24 horas quando a descoberta foi enviada para o Security Command Center.
Para resolver este problema, após aproximadamente 24 horas, volte a gerar os perfis de dados eliminando-os ou definindo uma programação de criação de perfis. Os detalhes completos da descoberta são enviados para o Security Command Center.
Análise inteligente de documentos
Esta secção contém problemas conhecidos relacionados com a análise de documentos.
O objeto DocumentLocation
não está preenchido
O campo location.content_locations.document_location.file_offset
não é preenchido para o modo de leitura de análise inteligente de documentos.
Deteção
Os seguintes problemas conhecidos descrevem problemas com a deteção, independentemente da operação que está a realizar: inspeção, anonimização ou deteção.
Palavras do dicionário
As palavras do dicionário que contêm carateres no Supplementary Multilingual Plane da norma Unicode podem gerar resultados inesperados. Exemplos de carateres deste tipo são emojis, símbolos científicos e escritas históricas.
Regras de exclusão
As regras de exclusão não podem ser aplicadas a infoTypes de objetos.