Errores conocidos

En esta página, se enumeran los problemas conocidos de Sensitive Data Protection, junto con las formas en que puedes evitarlos o recuperarte de ellos.

Almacena resultados en BigQuery

Cuando un trabajo o un análisis de descubrimiento almacena resultados en BigQuery, aparece un error Already exists en los registros. El error no indica que haya un problema; tus resultados se almacenarán como se espera.

Análisis de BigQuery

En esta sección, se describen los problemas que puedes encontrar cuando inspeccionas o generas perfiles de datos de BigQuery.

Problemas comunes para las operaciones de inspección y generación de perfiles

Los siguientes problemas se aplican a las operaciones de inspección y generación de perfiles de BigQuery.

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

Las políticas de seguridad a nivel de la fila pueden impedir que Sensitive Data Protection inspeccione y genere perfiles de las tablas protegidas de BigQuery. Si tienes políticas de seguridad a nivel de la fila aplicadas a tus tablas de BigQuery, te recomendamos que establezcas un filtro TRUE y que incluyas el agente de servicio en la lista de beneficiarios:

Filas duplicadas

Cuando escribes datos en una tabla de BigQuery, Sensitive Data Protection puede escribir filas duplicadas.

Datos transmitidos recientemente

Sensitive Data Protection no analiza los datos transmitidos recientemente (antes conocidos como búfer de transmisión). Para obtener más información, consulta Disponibilidad de datos de transmisión 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 los perfiles de datos.

Los resultados exportados no tienen valores para el campo row_number

Cuando configuras Sensitive Data Protection 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 para los trabajos de inspección.

Si necesitas identificar filas específicas donde se encuentran los resultados, especifica inspectJob.storageConfig.bigQueryOptions.identifyingFields en el momento de la creación del trabajo.

Los campos de identificación se pueden encontrar en la tabla de BigQuery que se generó en el campo location.content_locations.record_location.record_key.id_values.

Limita los análisis al contenido nuevo de BigQuery

Si limitas los análisis solo al contenido nuevo y usas la API de BigQuery Storage Write para propagar la tabla de entrada, Sensitive Data Protection podría omitir el análisis de algunas filas.

Para mitigar este problema, en tu trabajo de inspección, asegúrate de que el timestampField del TimespanConfig objeto sea una marca de tiempo de confirmación que BigQuery genere automáticamente. Sin embargo, aún no hay garantía de que no se omitan filas, ya que Sensitive Data Protection no lee datos transmitidos recientemente.

Si deseas generar automáticamente marcas de tiempo de confirmación para una columna y usas la API de transmisión heredada para propagar 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 establece su tipo en TIMESTAMP:

    ...
    {
     "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 configurados en AUTO.

    Ejemplo de JSON

    En el siguiente ejemplo, se establece el valor del campo commit_time_stamp en AUTO:

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

Limita los análisis estableciendo un porcentaje o filas máximos

Cuando estableces un límite de muestreo basado en un porcentaje de la cantidad total de filas de la tabla (rowsLimitPercent), Sensitive Data Protection puede inspeccionar más filas de lo esperado. Si necesitas establecer un límite estricto en la cantidad de filas que se deben analizar, te recomendamos que establezcas una cantidad máxima de filas (rowsLimit) en su lugar.

Problemas de generación de perfiles de BigQuery

Los siguientes problemas solo se aplican a las operaciones de generación de perfiles de datos de BigQuery. Si deseas obtener más información, consulta Perfiles de datos para datos de BigQuery.

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

Sensitive Data Protection muestra un error si intentas generar un perfil de una organización o proyecto que tiene más de 500 millones de tablas. Si encuentras este error, sigue las instrucciones del mensaje de error.

Si el recuento de tablas de tu organización tiene más de 500 millones de tablas y tienes un proyecto con un recuento de tablas más bajo, prueba realizar un análisis a nivel de proyecto.

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

Plantillas de inspección

La plantilla de inspección debe estar en la misma región que los datos de los que se generará el perfil. Si tienes datos en varias regiones, usa varias plantillas de inspección, una para cada región en la que tengas datos. También puedes usar una plantilla de inspección que se almacene en la región global. Si incluyes una plantilla en la región global, Sensitive Data Protection la usa 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.

Infotipos almacenados

Un Infotipo almacenado (también conocido como detector de diccionario personalizado almacenado) al que se hace referencia en tu plantilla de inspección debe almacenarse en cualquiera de los siguientes:

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

De lo contrario, la operación de generación de perfiles falla con el error Resource not found.

Visibilidad de recursos

En un perfil de datos de tabla, la clasificación de visibilidad de recursos que se le otorga 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 IAM de una tabla difieren de los permisos de IAM del conjunto de datos, la visibilidad de recursos de la tabla indicada en el perfil de datos puede ser incorrecta. Este problema afecta el descubrimiento para BigQuery y el descubrimiento para la plataforma de agentes.

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

Análisis de Cloud Storage

En esta sección, se describen los problemas que puedes encontrar cuando inspeccionas o desidentificas datos.

No se admite la inspección de archivos XLSX estrictos

Un archivo con una extensión .xlsx puede ser de dos tipos. Un tipo es una hoja de cálculo de Strict Office Open XML, que no es compatible con Sensitive Data Protection. El otro tipo es un libro de trabajo predeterminado de Microsoft Excel, que sí es compatible.

Archivos estructurados que se analizan en modo binario

En ciertos casos, los archivos que suelen analizarse en modo de análisis estructurado pueden analizarse en modo binario, que no incluye las mejoras del modo de análisis estructurado. Para obtener más información, consulta Analiza archivos estructurados en modo de análisis estructurado.

Desidentifica archivos delimitados

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

Descubrimiento para Cloud SQL

Hallazgos duplicados de Security Command Center

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

Antes del 25 de abril de 2024, un error provocaba que Sensitive Data Protection generara ocasionalmente resultados duplicados para las instancias de Cloud SQL en Security Command Center. Estos hallazgos se generaron con IDs de hallazgo únicos, pero pertenecen a las mismas instancias de Cloud SQL. El problema se resolvió, pero los resultados duplicados aún existen. Puedes silenciar los duplicados para ocultarlos en la página Resultados de Security Command Center.

Descubrimiento para Amazon S3

Es posible que los resultados de Amazon S3 que Sensitive Data Protection envía a Security Command Center no tengan información sobre el ID de cuenta de AWS o el nombre visible del recurso afectado. Por lo general, esto sucede en los siguientes casos:

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

Para resolver este problema, después de aproximadamente 24 horas, vuelve a generar los perfiles de datos borrándolos o estableciendo una programación de generación de perfiles. Los detalles completos de los hallazgos se envían a Security Command Center.

Análisis inteligente de documentos

Esta sección contiene problemas conocidos relacionados con el análisis de documentos.

El objeto DocumentLocation no se propaga

El campo location.content_locations.document_location.file_offset no se propaga para el modo de Análisis inteligente de documentos.

Detección

En los siguientes problemas conocidos, se describen problemas con la detección, independientemente de la operación que realices: inspección, desidentificación o descubrimiento.

Palabras del diccionario

Las palabras del diccionario que contienen caracteres en el Plano Multilingüe Complementario del estándar Unicode pueden generar resultados inesperados. Algunos ejemplos de estos caracteres son emojis, símbolos científicos y secuencias de comandos históricas.