Problemas conocidos

En esta página se enumeran los problemas conocidos de Protección de Datos Sensibles, así como las formas de evitar o solucionar los siguientes problemas.

Almacenar resultados en BigQuery

Cuando una tarea o un análisis de descubrimiento almacena resultados en BigQuery, aparece un error Already exists en los registros. El error no indica que haya ningún problema; los resultados se almacenarán como es habitual.

Análisis de BigQuery

En esta sección se describen los problemas que pueden surgir al inspeccionar o crear perfiles de datos de BigQuery.

Problemas habituales en las operaciones de inspección y creación de perfiles

Los siguientes problemas se aplican tanto a las operaciones de inspección como a las de creación de perfiles de BigQuery.

No se pueden analizar las filas con seguridad a nivel de fila

Las políticas de seguridad a nivel de fila pueden impedir que Protección de Datos Sensibles inspeccione y cree perfiles de las tablas de BigQuery protegidas. Si tienes políticas de seguridad a nivel de fila aplicadas a tus tablas de BigQuery, te recomendamos que definas un filtro TRUE e incluyas al agente de servicio en la lista de beneficiarios:

Filas duplicadas

Al escribir datos en una tabla de BigQuery, Protección de Datos Sensibles puede escribir filas duplicadas.

Datos transmitidos recientemente

Protección de Datos Sensibles no analiza los datos transmitidos recientemente (antes conocidos como búfer de streaming). Para obtener más información, consulta la disponibilidad de la transmisión de datos en la documentación de BigQuery.

Problemas de inspección de BigQuery

Los siguientes problemas solo se aplican a las operaciones de inspección de datos de BigQuery. No afectan a los perfiles de datos.

Los hallazgos exportados no tienen valores en el campo row_number

Cuando configuras Protección de Datos Sensibles para guardar los resultados en BigQuery, el campo location.content_locations.record_location.record_key.big_query_key.row_number de la tabla de BigQuery generada se infiere en el momento en que se analiza la tabla de entrada. Su valor no es determinista, no se puede consultar y puede ser nulo en el caso de los trabajos de inspección.

Si necesitas identificar filas específicas en las que haya resultados, especifica inspectJob.storageConfig.bigQueryOptions.identifyingFields en el momento de crear la tarea.

Los campos de identificación se encuentran en la tabla de BigQuery generada, en el campo location.content_locations.record_location.record_key.id_values.

Limitar los análisis al contenido nuevo de BigQuery

Si limitas los análisis solo al contenido nuevo y usas la API Storage Write de BigQuery para rellenar la tabla de entrada, Protección de Datos Sensibles podría omitir el análisis de algunas filas.

Para mitigar este problema, en tu tarea de inspección, asegúrate de que el timestampField del objeto TimespanConfig sea una marca de tiempo de confirmación que BigQuery genera automáticamente. Sin embargo, no hay ninguna garantía de que no se omitan filas, ya que Protección de Datos Sensibles no lee los datos transmitidos recientemente.

Si quieres generar automáticamente marcas de tiempo de confirmación para una columna y usas la API de streaming antigua para rellenar tu tabla de entrada, haz lo siguiente:

  1. En el esquema de la tabla de entrada, asegúrate de que la columna de marca de tiempo sea de tipo TIMESTAMP.

    Esquema de ejemplo

    En el siguiente ejemplo se define el campo commit_time_stamp y se asigna el valor TIMESTAMP a su tipo:

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

  2. En el campo rows[].json del método tabledata.insertAll, asegúrate de que los valores de la columna de marca de tiempo estén definidos como AUTO.

    Ejemplo de JSON

    En el ejemplo siguiente se asigna el valor AUTO al campo commit_time_stamp:

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

Limitar los análisis definiendo un porcentaje o un número de filas máximos

Si define un límite de muestreo basado en un porcentaje del número total de filas de la tabla (rowsLimitPercent), Protección de Datos Sensibles puede inspeccionar más filas de las esperadas. Si necesitas poner un límite estricto al número de filas que se van a analizar, te recomendamos que definas un número máximo de filas (rowsLimit) en su lugar.

Problemas de creación de perfiles de BigQuery

Los siguientes problemas solo se aplican a las operaciones de creación de perfiles en datos de BigQuery. Para obtener más información, consulta el artículo Perfiles de datos de BigQuery.

Organizaciones o proyectos con más de 500 millones de tablas

Protección de Datos Sensibles devuelve un error si intentas crear un perfil de una organización o un proyecto que tenga más de 500 millones de tablas. Si se produce este error, sigue las instrucciones que se indican en el mensaje de error.

Si tu organización tiene más de 500 millones de tablas y tienes un proyecto con un número de tablas inferior, prueba a hacer un análisis a nivel de proyecto.

Para obtener información sobre los límites de tablas y columnas, consulta Límites de la creación de perfiles de datos.

Plantillas de inspección

La plantilla de inspección debe estar en la misma región que los datos que se van a crear. Si tiene datos en varias regiones, utilice varias plantillas de inspección, una por cada región en la que tenga datos. También puede usar una plantilla de inspección almacenada en la región global. Si incluyes una plantilla en la región global, Protección de Datos Sensibles la usará para cualquier dato que no tenga una plantilla específica de la región. Para obtener más información, consulta Consideraciones sobre la residencia de los datos.

infoTypes almacenados

Un infoType almacenado (también conocido como detector de diccionario personalizado almacenado) al que se haga referencia en tu plantilla de inspección debe almacenarse en uno de los siguientes lugares:

  • La región global.
  • La misma región que la de la plantilla de inspección.

De lo contrario, se producirá un error en la operación de creación de perfil y aparecerá el mensaje Resource not found.

Visibilidad de los recursos

En un perfil de datos de una tabla, la clasificación de visibilidad de recursos que se asigna a una tabla de BigQuery depende de la visibilidad del conjunto de datos que contiene la tabla, en lugar de la visibilidad de la tabla. Por lo tanto, si los permisos de gestión de identidades y accesos de una tabla son diferentes de los del conjunto de datos, la visibilidad de los recursos de la tabla que se indica en el perfil de datos puede ser incorrecta. Este problema afecta a la detección de BigQuery y a la detección de Vertex AI.

En la Google Cloud consola, la visibilidad del recurso se indica en el campo Público del perfil de datos de la tabla. En la API Cloud Data Loss Prevention, la visibilidad de los recursos se indica en el campo resourceVisibility del TableDataProfile.

Análisis de Cloud Storage

En esta sección se describen los problemas que pueden surgir al inspeccionar o anonimizar datos.

No se admite la inspección de archivos XLSX estrictos

Un archivo con la extensión .xlsx puede ser de dos tipos. Uno de los tipos es una hoja de cálculo de Strict Office Open XML, que no es compatible con Protección de Datos Sensibles. El otro tipo es un libro de trabajo predeterminado de Microsoft Excel, que sí se admite.

Archivos estructurados que se analizan en modo binario

En algunos casos, los archivos que normalmente se analizan en el modo de análisis estructurado se pueden analizar en el modo binario, que no incluye las mejoras del modo de análisis estructurado. Para obtener más información, consulta Analizar archivos estructurados en el modo de análisis estructurado.

Desidentificar archivos delimitados

Cuando anonimizas un archivo delimitado (por ejemplo, un archivo CSV) con un trabajo de inspección, es posible que el resultado tenga celdas vacías adicionales en algunas filas. Una solución alternativa para evitar estas celdas adicionales es desidentificar los datos con el método content.deidentify.

Discovery para Cloud SQL

Resultados duplicados de Security Command Center

La creación de perfiles de datos de Cloud SQL admite la publicación de resultados en Security Command Center.

Antes del 25 de abril del 2024, un error provocaba que Protección de Datos Sensibles generara ocasionalmente resultados duplicados para las instancias de Cloud SQL en Security Command Center. Estos resultados se han generado con IDs únicos, pero pertenecen a las mismas instancias de Cloud SQL. El problema se ha resuelto, pero las detecciones duplicadas siguen existiendo. Puedes silenciar los duplicados para ocultarlos en la página Resultados de Security Command Center.

Detección de Amazon S3

Es posible que las detecciones de Amazon S3 que Protección de Datos Sensibles envía a Security Command Center no incluyan información sobre el ID o el nombre visible de la cuenta de AWS del recurso afectado. Esto suele ocurrir en los siguientes casos:

  • El conector de AWS solo había sido válido durante unas 24 horas cuando se envió la detección a Security Command Center.
  • La cuenta de AWS solo se había incluido en el conector de AWS durante unas 24 horas cuando se envió el hallazgo a Security Command Center.

Para solucionar este problema, después de aproximadamente 24 horas, vuelve a generar los perfiles de datos eliminándolos o configurando una programación de creación de perfiles. Los detalles completos de la detección se envían a Security Command Center.

Análisis inteligente de documentos

En esta sección se describen los problemas conocidos relacionados con el análisis de documentos.

El objeto DocumentLocation no se rellena

El campo location.content_locations.document_location.file_offset no se rellena en el modo de escaneo de análisis inteligente de documentos.

Detección

Los siguientes problemas conocidos describen problemas con la detección, independientemente de la operación que estés realizando (inspección, anonimización o descubrimiento).

Palabras del diccionario

Las palabras del diccionario que contengan caracteres del plano multilingüe suplementario del estándar Unicode pueden dar resultados inesperados. Algunos ejemplos de estos caracteres son los emojis, los símbolos científicos y los alfabetos históricos.

Reglas de exclusión

Las reglas de exclusión no se pueden aplicar a los infoTypes de objeto.