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:
- Si generas perfiles de datos a nivel de la organización o de la carpeta, incluye el agente de servicio del proyecto de contenedor en la lista de beneficiarios.
- Si creas perfiles de datos a nivel del proyecto o ejecutas un trabajo de inspección en una tabla, incluye el agente de servicio del proyecto 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:
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 enTIMESTAMP
:... { "name": "commit_time_stamp", "type": "TIMESTAMP" } ...
En el campo
rows[].json
del métodotabledata.insertAll
, asegúrate de que los valores de la columna de marca de tiempo estén configurados enAUTO
.Ejemplo de JSON
En el siguiente ejemplo, se establece el valor del campo
commit_time_stamp
enAUTO
:{ ... "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 los 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 causaba 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 o el nombre visible de la cuenta de AWS 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 esos caracteres son los emojis, los símbolos científicos y las escrituras históricas.