Errores conocidos

En esta página, se enumeran los problemas conocidos de la Protección de datos sensibles, junto con las formas en que puedes evitarlos o solucionarlos.

Problemas generales

Almacenamiento de 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 creas perfiles de datos de BigQuery.

Problemas comunes de 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 las filas pueden impedir que Sensitive Data Protection inspeccione y genere perfiles de las tablas de BigQuery protegidas. Si tienes políticas de seguridad a nivel de las filas aplicadas a tus tablas de BigQuery, te recomendamos que establezcas un filtro VERDADERO y que incluyas al agente de servicio en la lista de beneficiarios:

Filas duplicadas

Cuando se escriben datos en una tabla de BigQuery, la Protección de datos sensibles puede escribir filas duplicadas.

Datos transmitidos recientemente

La Protección de datos sensibles 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 en los 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, es posible que la Protección de datos sensibles omita el análisis de algunas filas.

Para mitigar este problema, en tu trabajo 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, aún no hay garantía de que no se omitan filas, ya que la Protección de datos sensibles no lee los datos transmitidos recientemente.

Si deseas generar marcas de tiempo de confirmación automáticamente 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 configures una cantidad máxima de filas (rowsLimit).

Problemas de generación de perfiles de BigQuery

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

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

La Protección de datos sensibles 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 que se indican en el mensaje.

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 para 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 usará para los datos que no tengan 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 las siguientes ubicaciones:

  • 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 fallará con el error Resource not found.

Visibilidad de recursos

En un perfil de datos de tabla, la clasificación de visibilidad de los recursos que se le asigna a una tabla de BigQuery depende de la visibilidad del conjunto de datos que la contiene, 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 los recursos de la tabla indicada en el perfil de datos puede ser incorrecta. Este problema afecta el descubrimiento de BigQuery y el descubrimiento de Vertex AI.

En la consola de Google Cloud, la visibilidad de los 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 los recursos se indica en el campo resourceVisibility de TableDataProfile.

Análisis de Cloud Storage

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

Inspección de archivos XLSX con detectores de diccionarios personalizados grandes

Cuando usas un detector de diccionario personalizado grande (también conocido como detector de diccionario personalizado almacenado) para inspeccionar un archivo .xlsx de Microsoft Excel, el trabajo de inspección puede ejecutarse con lentitud, parecer bloqueado y generar una gran cantidad de operaciones de clase B de Cloud Storage. Esto se debe a que Sensitive Data Protection puede leer la lista de términos de origen del diccionario personalizado grande una vez para cada celda del archivo .xlsx. El volumen de operaciones de lectura puede hacer que el trabajo de inspección de Protección de datos sensibles muestre poco progreso y parezca estar bloqueado.

Para obtener más información sobre los cargos de facturación relevantes de Cloud Storage, consulta los cargos de las operaciones de clase B en Cargos por operaciones.

Archivos estructurados que se analizan en modo binario

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

Desidentificación de 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 método content.deidentify.

Descubrimiento para Cloud SQL

Hallazgos duplicados de Security Command Center

El perfilado de datos de Cloud SQL admite la publicación de resultados en Security Command Center.

Antes del 25 de abril de 2024, un error hacía que Sensitive Data Protection generara, en ocasiones, resultados duplicados para las instancias de Cloud SQL en Security Command Center. Estos resultados se generaron con IDs de resultados ú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 la Protección de datos sensibles envía a Security Command Center no tengan información sobre el ID de cuenta de AWS o el nombre visible del recurso afectado. Esto suele ocurrir en los siguientes casos:

  • El conector de AWS solo era 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 borrando o configurando un programa de generación de perfiles. Los detalles completos de los resultados se envían a Security Command Center.

Análisis inteligente de documentos

En esta sección, se incluyen 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

Las palabras del diccionario que contienen caracteres del Plano multilingüe complementario del estándar Unicode pueden generar resultados inesperados. Algunos ejemplos de estos caracteres son los emojis, los símbolos científicos y las escrituras históricas.