Introducción al enmascaramiento de datos

Nota: Es posible que esta función no esté disponible al usar reservas creadas con determinadas ediciones de BigQuery. Para obtener más información sobre las funciones habilitadas en cada edición, consulta el artículo Introducción a las ediciones de BigQuery

.

BigQuery admite el enmascaramiento de datos a nivel de columna. Puedes usar esta función para ocultar datos de las columnas a determinados grupos de usuarios, quienes podrán seguir accediendo a dichas columnas. La función de enmascaramiento de datos se basa en el control de acceso a nivel de columna, por lo que debes familiarizarte con esa función antes de continuar.

Si usas el enmascaramiento de datos junto con el control de acceso a nivel de columna, puedes configurar un intervalo de acceso a los datos de las columnas, desde acceso completo hasta ningún acceso, en función de las necesidades de los diferentes grupos de usuarios. Por ejemplo, en el caso de los datos del número de identificación fiscal, puedes conceder acceso completo a tu grupo de contabilidad, acceso enmascarado a tu grupo de analistas y ningún acceso a tu grupo de ventas.

Ventajas

El enmascaramiento de datos ofrece las siguientes ventajas:

• Simplifica el proceso de compartir datos. Puedes enmascarar columnas sensibles para poder compartir tablas con grupos más grandes.
• A diferencia del control de acceso a nivel de columna, no es necesario modificar las consultas excluyendo las columnas a las que el usuario no puede acceder. Cuando configuras el enmascaramiento de datos, las consultas que ya tengas enmascaran automáticamente los datos de las columnas en función de los roles que se hayan asignado al usuario.
• Puedes aplicar políticas de acceso a datos a gran escala. Puedes escribir una política de datos, asociarla a una etiqueta de política y aplicar la etiqueta de política a cualquier número de columnas.
• Permite el control de acceso basado en atributos. Una etiqueta de política asociada a una columna proporciona acceso a los datos contextuales, que se determina mediante la política de datos y las entidades asociadas a esa etiqueta de política.

Flujo de trabajo de enmascaramiento de datos

Hay dos formas de enmascarar datos. Puedes crear una taxonomía y etiquetas de política, y luego configurar políticas de datos en las etiquetas de política. También puede definir una política de datos directamente en una columna Vista previa. De esta forma, puede asignar una regla de enmascaramiento de datos a sus datos sin tener que gestionar etiquetas de políticas ni crear taxonomías adicionales.

Definir una política de datos directamente en una columna

Puede configurar el enmascaramiento dinámico de datos directamente en una columna (Vista previa). Para ello, sigue estos pasos:

1. Crea una política de datos.

2. Asigna una política de datos a una columna.

Máscara de datos con etiquetas de política

En la figura 1 se muestra el flujo de trabajo para configurar el enmascaramiento de datos:

Imagen 1. Componentes de enmascaramiento de datos.

Para configurar el enmascaramiento de datos, sigue estos pasos:

1. Configura una taxonomía y una o varias etiquetas de política.

2. Configura las políticas de datos de las etiquetas de políticas. Una política de datos asigna una regla de enmascaramiento de datos y uno o varios principales, que representan usuarios o grupos, a la etiqueta de la política.

   Cuando crea una política de datos con la consola Google Cloud , crea la regla de enmascaramiento de datos y especifica las entidades principales en un solo paso. Cuando creas una política de datos con la API Data Policy de BigQuery, creas la política de datos y la regla de enmascaramiento de datos en un solo paso, y especificas las entidades de la política de datos en un segundo paso.

3. Asigna las etiquetas de política a las columnas de las tablas de BigQuery para aplicar las políticas de datos.

4. Asigna el rol Lector enmascarado de BigQuery a los usuarios que deban tener acceso a los datos enmascarados. Como práctica recomendada, asigna el rol Lector enmascarado de BigQuery a nivel de política de datos. Si asignas el rol a nivel de proyecto o superior, los usuarios tendrán permisos para todas las políticas de datos del proyecto, lo que puede provocar problemas debido a un exceso de permisos.

   La etiqueta de política asociada a una política de datos también se puede usar para controlar el acceso a nivel de columna. En ese caso, la etiqueta de política también se asocia a uno o varios principales a los que se les ha concedido el rol Lector de datos pormenorizados de Cloud Data Catalog. De esta forma, estas entidades pueden acceder a los datos originales sin enmascarar de la columna.

En la imagen 2 se muestra cómo funcionan conjuntamente el control de acceso a nivel de columna y el enmascaramiento de datos:

Imagen 2. Componentes de enmascaramiento de datos.

Para obtener más información sobre la interacción de los roles, consulta Cómo interactúan los roles Lector enmascarado y Lector detallado. Para obtener más información sobre la herencia de etiquetas de política, consulta Roles y jerarquía de etiquetas de política.

Reglas de enmascaramiento de datos

Cuando usas el enmascaramiento de datos, se aplica una regla de enmascaramiento de datos a una columna en el tiempo de ejecución de la consulta, en función del rol del usuario que ejecuta la consulta. El enmascaramiento tiene prioridad sobre cualquier otra operación implicada en la consulta. La regla de enmascaramiento de datos determina el tipo de enmascaramiento de datos que se aplica a los datos de la columna.

Puede usar las siguientes reglas de enmascaramiento de datos:

• Rutina de enmascaramiento personalizada. Devuelve el valor de la columna después de aplicar una función definida por el usuario (UDF) a la columna. Se necesitan permisos de rutina para gestionar la regla de enmascaramiento. Esta regla, por diseño, admite todos los tipos de datos de BigQuery, excepto el tipo de datos STRUCT. Sin embargo, la compatibilidad con tipos de datos distintos de STRING y BYTES es limitada. El resultado depende de la función definida.

  Para obtener más información sobre cómo crear funciones definidas por el usuario para rutinas de enmascaramiento personalizadas, consulte Crear rutinas de enmascaramiento personalizadas.

• Máscara de año de fecha. Devuelve el valor de la columna después de truncar el valor a su año, estableciendo todas las partes del valor que no corresponden al año al principio del año. Solo puedes usar esta regla con columnas que usen los tipos de datos DATE, DATETIME y TIMESTAMP. Por ejemplo:

  Tipo	Original	Enmascarado
  DATE	2030-07-17	2030-01-01
  DATETIME	2030-07-17T01:45:06	2030-01-01T00:00:00
  TIMESTAMP	2030-07-17 01:45:06	2030-01-01 00:00:00

  Nota: El truncamiento se produce según la zona horaria UTC. Para cambiarlo, ajusta la zona horaria predeterminada con la variable de sistema@@time_zone.

• Valor de máscara predeterminado. Devuelve un valor de enmascaramiento predeterminado para la columna en función del tipo de datos de la columna. Úsalo cuando quieras ocultar el valor de la columna, pero mostrar el tipo de datos. Cuando se aplica esta regla de enmascaramiento de datos a una columna, resulta menos útil en las operaciones de consulta JOIN para los usuarios con acceso de lector enmascarado. Esto se debe a que un valor predeterminado no es lo suficientemente único como para ser útil al combinar tablas.

  En la siguiente tabla se muestra el valor de enmascaramiento predeterminado de cada tipo de datos:

  Data type (Dato)	Valor de máscara predeterminado
  STRING	""
  BYTES	b''
  INTEGER	0
  FLOAT	0,0
  NUMERIC	0
  BOOLEAN	FALSE
  TIMESTAMP	1970-01-01 00:00:00 UTC
  DATE	1970-01-01
  TIME	00:00:00
  DATETIME	1970-01-01T00:00:00
  GEOGRAPHY	POINT(0 0)
  BIGNUMERIC	0
  ARRAY	[]
  STRUCT	NOT_APPLICABLE Las etiquetas de políticas no se pueden aplicar a columnas que usen el tipo de datos STRUCT, pero sí se pueden asociar a los campos hoja de dichas columnas.
  JSON	null

• Máscara de correo electrónico. Devuelve el valor de la columna después de sustituir el nombre de usuario de un correo electrónico válido por XXXXX. Si el valor de la columna no es una dirección de correo válida, devuelve el valor de la columna después de haberlo pasado por la función de hash SHA-256. Solo puedes usar esta regla con columnas que usen el tipo de datos STRING. Por ejemplo:

  Original	Enmascarado
  [e-mail]	[e-mail]
  randomtext	jQHDyQuj7vJcveEe59ygb3Zcvj0B5FJINBzgM6Bypgw=
  test@[e-mail]	Qdje6MO+GLwI0u+KyRyAICDjHbLF1ImxRqaW08tY52k=

• Los cuatro primeros caracteres. Devuelve los cuatro primeros caracteres del valor de la columna y sustituye el resto de la cadena por XXXXX. Si el valor de la columna tiene una longitud de 4 caracteres o menos, se devuelve el valor de la columna después de haber pasado por la función de hash SHA-256. Solo puede usar esta regla con columnas que usen el tipo de datos STRING.

• Hash (SHA-256): Devuelve el valor de la columna después de que se haya ejecutado la función de hash SHA-256. Usa este valor cuando quieras que el usuario final pueda usar esta columna en una operación JOIN de una consulta. Solo puede usar esta regla con columnas que usen los tipos de datos STRING o BYTES.

  La función SHA-256 que se usa en el enmascaramiento de datos conserva el tipo, por lo que el valor de hash que devuelve tiene el mismo tipo de datos que el valor de la columna. Por ejemplo, el valor hash de un valor de columna STRING también tiene un tipo de datos STRING.

  Importante: SHA-256 es una función de cifrado con hash determinista. Un valor inicial siempre se resuelve en el mismo valor de hash. Sin embargo, no requiere claves de cifrado. De esta forma, un agente malintencionado puede usar un ataque de fuerza bruta para determinar el valor original. Para ello, ejecuta todos los valores originales posibles a través del algoritmo SHA-256 y comprueba cuál produce un hash que coincide con el hash devuelto por el enmascaramiento de datos.

• Últimos cuatro caracteres. Devuelve los últimos 4 caracteres del valor de la columna y sustituye el resto de la cadena por XXXXX. Si el valor de la columna tiene una longitud de 4 caracteres o menos, se devuelve el valor de la columna después de haber pasado por la función de hash SHA-256. Solo puede usar esta regla con columnas que usen el tipo de datos STRING.

• Anular. Devuelve NULL en lugar del valor de la columna. Úsalo cuando quieras ocultar tanto el valor como el tipo de datos de la columna. Cuando se aplica esta regla de enmascaramiento de datos a una columna, resulta menos útil en las operaciones de consulta JOIN para los usuarios con acceso de lector enmascarado. Esto se debe a que un valor NULL no es lo suficientemente único como para ser útil al combinar tablas.

Jerarquía de reglas de enmascaramiento de datos

Puedes configurar hasta nueve políticas de datos para una etiqueta de política, cada una con una regla de enmascaramiento de datos diferente asociada. Una de estas políticas se reserva para los ajustes de control de acceso a nivel de columna. De esta forma, se pueden aplicar varias políticas de datos a una columna de la consulta de un usuario en función de los grupos a los que pertenezca. Cuando esto ocurre, BigQuery elige qué regla de enmascaramiento de datos aplicar según la siguiente jerarquía:

1. Rutina de enmascaramiento personalizada
2. Hash (SHA-256)
3. Máscara de correo
4. Últimos cuatro caracteres
5. Los cuatro primeros caracteres
6. Máscara de año de fecha
7. Valor de enmascaramiento predeterminado
8. Anular

Por ejemplo, el usuario A es miembro de los grupos de empleados y de contabilidad. El usuario A ejecuta una consulta que incluye el campo sales_total, que tiene aplicada la etiqueta de política confidential. La etiqueta de política confidential tiene dos políticas de datos asociadas: una que tiene el rol de empleado como principal y aplica la regla de enmascaramiento de datos de anulación, y otra que tiene el rol de contabilidad como principal y aplica la regla de enmascaramiento de datos de cifrado con hash (SHA-256). En este caso, la regla de enmascaramiento de datos de hash (SHA-256) tiene prioridad sobre la regla de enmascaramiento de datos de anulación, por lo que se aplica al valor del campo sales_total de la consulta del usuario A.

En la figura 3 se muestra este caso:

Imagen 3. Priorización de reglas de enmascaramiento de datos.

Roles y permisos

Roles para gestionar taxonomías y etiquetas de política

Necesitas el rol Administrador de etiquetas de políticas de Data Catalog para crear y gestionar taxonomías y etiquetas de políticas.

Rol/ID	Permisos	Descripción
Administrador de etiquetas de política de Data Catalog/datacatalog.categoryAdmin	datacatalog.categories.getIamPolicy datacatalog.categories.setIamPolicy datacatalog.taxonomies.create datacatalog.taxonomies.delete datacatalog.taxonomies.get datacatalog.taxonomies.getIamPolicy datacatalog.taxonomies.list datacatalog.taxonomies.setIamPolicy datacatalog.taxonomies.update resourcemanager.projects.get resourcemanager.projects.list	Se aplica a nivel de proyecto. Este rol permite hacer lo siguiente: Crear, leer, actualizar y eliminar taxonomías y etiquetas de política. Obtener y definir políticas de gestión de identidades y accesos en etiquetas de política.

Roles para crear y gestionar políticas de datos

Para crear y gestionar políticas de datos, debe tener uno de los siguientes roles de BigQuery:

Rol/ID	Permisos	Descripción
Administrador de políticas de datos de BigQuery/bigquerydatapolicy.admin Administrador de BigQuery/bigquery.admin Propietario de datos de BigQuery/bigquery.dataOwner	bigquery.dataPolicies.create bigquery.dataPolicies.delete bigquery.dataPolicies.get bigquery.dataPolicies.getIamPolicy bigquery.dataPolicies.list bigquery.dataPolicies.setIamPolicy bigquery.dataPolicies.update	Los permisos bigquery.dataPolicies.create y bigquery.dataPolicies.list se aplican a nivel de proyecto. Los demás permisos se aplican a nivel de política de datos. Este rol permite hacer lo siguiente: Crear, leer, actualizar y eliminar políticas de datos. Obtener y definir políticas de gestión de identidades y accesos en políticas de datos.

También necesitas el permiso datacatalog.taxonomies.get, que puedes obtener de varios roles predefinidos de Data Catalog.

Roles para adjuntar etiquetas de política a columnas

Necesitas los permisos datacatalog.taxonomies.get y bigquery.tables.setCategory para adjuntar etiquetas de políticas a las columnas. datacatalog.taxonomies.get se incluye en los roles Administrador y Lector de etiquetas de políticas de Data Catalog. bigquery.tables.setCategory se incluye en los roles Administrador de BigQuery (roles/bigquery.admin) y Propietario de datos de BigQuery (roles/bigquery.dataOwner).

Roles para consultar datos enmascarados

Necesita el rol Lector enmascarado de BigQuery para consultar los datos de una columna a la que se le haya aplicado el enmascaramiento de datos.

Rol/ID	Permisos	Descripción
Lector enmascarado/bigquerydatapolicy.maskedReader	bigquery.dataPolicies.maskedGet	Se aplica a nivel de la política de datos. Este rol permite ver los datos enmascarados de una columna asociada a una política de datos. Además, un usuario debe tener los permisos adecuados para consultar la tabla. Para obtener más información, consulta la sección Permisos necesarios.

Cómo interactúan los roles Lector enmascarado y Lector pormenorizado

El enmascaramiento de datos se basa en el control de acceso a nivel de columna. En una columna determinada, es posible que algunos usuarios tengan el rol Lector enmascarado de BigQuery, que les permite leer datos enmascarados; otros usuarios tengan el rol Lector pormenorizado de Data Catalog, que les permite leer datos sin enmascarar; otros tengan ambos roles y otros no tengan ninguno. Estos roles interactúan de la siguiente manera:

• Usuario con los roles de lector pormenorizado y lector anonimizado: lo que ve el usuario depende de la posición de cada rol en la jerarquía de etiquetas de política. Para obtener más información, consulta Herencia de autorizaciones en una jerarquía de etiquetas de políticas.
• Usuario con el rol Lector pormenorizado: puede ver los datos de las columnas sin máscara (sin ocultar).
• Usuario con el rol de lector enmascarado: puede ver los datos de las columnas enmascarados (ocultos).
• Usuario sin ninguno de los dos roles: permiso denegado.

En el caso de que una tabla tenga columnas protegidas o protegidas y enmascaradas, para ejecutar una instrucción SELECT * FROM en esa tabla, un usuario debe ser miembro de los grupos adecuados para que se le asignen los roles de lector enmascarado o lector detallado en todas esas columnas.

Un usuario al que no se le hayan concedido estos roles debe especificar únicamente las columnas a las que tenga acceso en la instrucción SELECT o usar SELECT * EXCEPT (restricted_columns) FROM para excluir las columnas protegidas o enmascaradas.

Herencia de autorizaciones en una jerarquía de etiquetas de política

Los roles se evalúan empezando por la etiqueta de política asociada a una columna y, a continuación, se comprueban en cada nivel ascendente de la taxonomía hasta que se determina que el usuario tiene los permisos adecuados o se alcanza la parte superior de la jerarquía de etiquetas de política.

Por ejemplo, tomemos la etiqueta de política y la configuración de la política de datos que se muestran en la figura 4:

Imagen 4. Configuración de etiquetas de políticas y políticas de datos.

Tiene una columna de tabla anotada con la etiqueta de política Financial y un usuario que es miembro de los grupos [e-mail] y [e-mail]. Cuando este usuario ejecuta una consulta que incluye la columna anotada, su acceso se determina en función de la jerarquía definida en la taxonomía de etiquetas de política. Como el usuario tiene el rol Lector pormenorizado de Data Catalog por la etiqueta de política Financial, la consulta devuelve datos de columna sin máscara.

Si otro usuario que solo es miembro del rol [e-mail] ejecuta una consulta que incluye la columna anotada, la consulta devuelve datos de la columna que se han cifrado con el algoritmo SHA-256, ya que el usuario tiene asignado el rol Lector enmascarado de BigQuery mediante la etiqueta de política Confidential, que es la principal de la etiqueta de política Financial.

Un usuario que no sea miembro de ninguno de esos roles recibirá un error de acceso denegado si intenta consultar la columna anotada.

A diferencia del caso anterior, considere la etiqueta de política y la configuración de la política de datos que se muestran en la figura 5:

Imagen 5. Configuración de etiquetas de políticas y políticas de datos.

Te encuentras en la misma situación que en la figura 4, pero al usuario se le ha asignado el rol Lector con control pormenorizado en un nivel superior de la jerarquía de etiquetas de política y el rol Lector anonimizado en un nivel inferior de la jerarquía de etiquetas de política. Por este motivo, la consulta devuelve datos de columna enmascarados para este usuario. Esto ocurre aunque al usuario se le haya concedido el rol Lector de datos pormenorizados más arriba en la jerarquía de etiquetas, porque el servicio usa el primer rol asignado que encuentra a medida que asciende por la jerarquía de etiquetas de política para comprobar el acceso del usuario.

Si quiere crear una sola política de datos y que se aplique a varios niveles de una jerarquía de etiquetas de política, puede definir la política de datos en la etiqueta de política que represente el nivel superior de la jerarquía al que se debe aplicar. Por ejemplo, supongamos que tiene una taxonomía con la siguiente estructura:

• Etiqueta de política 1
  • Etiqueta de política 1a
    • Etiqueta de política 1ai
  • Etiqueta de política 1b
    • Etiqueta de política 1bi
    • Etiqueta de política 1bii

Si quieres que una política de datos se aplique a todas estas etiquetas de política, define la política de datos en la etiqueta de política 1. Si quieres que una política de datos se aplique a la etiqueta de política 1b y a sus elementos secundarios, define la política de datos en la etiqueta de política 1b.

Enmascaramiento de datos con funciones incompatibles

Cuando usas funciones de BigQuery que no son compatibles con el enmascaramiento de datos, el servicio trata la columna enmascarada como una columna segura y solo concede acceso a los usuarios que tienen el rol Lector de datos pormenorizados de Data Catalog.

Por ejemplo, tomemos la etiqueta de política y la configuración de la política de datos que se muestran en la figura 6:

Imagen 6. Configuración de etiquetas de políticas y políticas de datos.

Tienes una columna de tabla anotada con la etiqueta de política Financial y un usuario que es miembro del grupo [e-mail]. Cuando este usuario intenta acceder a la columna anotada a través de una de las funciones incompatibles, recibe un error de acceso denegado. Esto se debe a que se les ha concedido el rol Lector enmascarado de BigQuery mediante la etiqueta de política Financial, pero, en este caso, deben tener el rol Lector pormenorizado de Data Catalog. Como el servicio ya ha determinado un rol aplicable para el usuario, no sigue comprobando más arriba en la jerarquía de etiquetas de política para buscar permisos adicionales.

Ejemplo de enmascaramiento de datos con salida

Para ver cómo funcionan conjuntamente las etiquetas, las entidades y los roles, consulta este ejemplo.

En example.com, el acceso básico se concede a través del grupo [e-mail]. Todos los empleados que necesitan acceder con regularidad a los datos de BigQuery son miembros de este grupo, al que se le han asignado todos los permisos necesarios para leer datos de las tablas, así como el rol Lector anonimizado de BigQuery.

Los empleados se asignan a grupos adicionales que les dan acceso a columnas protegidas u ocultas cuando es necesario para su trabajo. Todos los miembros de estos grupos adicionales también son miembros de [e-mail]. En la figura 7 se muestra cómo se asocian estos grupos a las funciones correspondientes:

Imagen 7. Etiquetas de política y políticas de datos de example.com.

Las etiquetas de política se asocian a las columnas de la tabla, como se muestra en la figura 8:

Imagen 8. Etiquetas de política de example.com asociadas a columnas de tabla.

Teniendo en cuenta las etiquetas asociadas a las columnas, al ejecutar SELECT * FROM Accounts; se obtienen los siguientes resultados para los distintos grupos:

• [e-mail] a este grupo se le ha concedido el rol Lector enmascarado de BigQuery en las etiquetas de política PII y Confidential. Se devuelven los siguientes resultados:

  SSN	Prioridad	Valor del tiempo de vida del cliente	Fecha de creación	Correo electrónico
  NULL	""	0	8 de marzo de 1983	NULL
  NULL	""	0	29 de diciembre del 2009	NULL
  NULL	""	0	14 de julio del 2021	NULL
  NULL	""	0	5 de mayo de 1997	NULL

• [e-mail] a este grupo se le ha concedido el rol Lector pormenorizado de Data Catalog en la etiqueta de política SSN. Se devuelven los siguientes resultados:

  SSN	Prioridad	Valor del tiempo de vida del cliente	Fecha de creación	NULL
  123-45-6789	""	0	8 de marzo de 1983	NULL
  234-56-7891	""	0	29 de diciembre del 2009	NULL
  345-67-8912	""	0	14 de julio del 2021	NULL
  456-78-9123	""	0	5 de mayo de 1997	NULL

• [e-mail] a este grupo se le ha concedido el rol Lector pormenorizado de Data Catalog en la etiqueta de política Confidential. Se devuelven los siguientes resultados:

  SSN	Prioridad	Valor del tiempo de vida del cliente	Fecha de creación	Correo electrónico
  NULL	Alta	90.000	8 de marzo de 1983	NULL
  NULL	Alta	84.875	29 de diciembre del 2009	NULL
  NULL	Medio	38.000	14 de julio del 2021	NULL
  NULL	Bajo	245	5 de mayo de 1997	NULL

• [e-mail] a este grupo se le ha concedido el rol Lector enmascarado de BigQuery en la etiqueta de política Financial. Se devuelven los siguientes resultados:

  SSN	Prioridad	Valor del tiempo de vida del cliente	Fecha de creación	Correo electrónico
  NULL	""	Zmy9vydG5q=	8 de marzo de 1983	NULL
  NULL	""	GhwTwq6Ynm=	29 de diciembre del 2009	NULL
  NULL	""	B6y7dsgaT9=	14 de julio del 2021	NULL
  NULL	""	Uh02hnR1sg=	5 de mayo de 1997	NULL

• Todos los demás usuarios: cualquier usuario que no pertenezca a uno de los grupos indicados recibirá un error de acceso denegado porque no se le han concedido los roles Lector pormenorizado de Data Catalog o Lector anonimizado de BigQuery. Para consultar la tabla Accounts, deben especificar solo las columnas a las que tienen acceso en SELECT * EXCEPT (restricted_columns) FROM Accounts para excluir las columnas protegidas o enmascaradas.

Consideraciones sobre el coste

El enmascaramiento de datos puede afectar indirectamente al número de bytes procesados y, por lo tanto, al coste de la consulta. Si un usuario consulta una columna que está enmascarada para él con las reglas de valor de enmascaramiento predeterminado o de anulación, esa columna no se analiza en absoluto, lo que se traduce en un menor número de bytes procesados.

Restricciones y limitaciones

En las siguientes secciones se describen las categorías de restricciones y limitaciones a las que está sujeto el enmascaramiento de datos.

Gestión de políticas de datos

• Puede que esta función no esté disponible si usas reservas creadas con determinadas ediciones de BigQuery. Para obtener más información sobre las funciones habilitadas en cada edición, consulta el artículo Introducción a las ediciones de BigQuery.
• Puede crear hasta nueve políticas de datos por cada etiqueta de política. Una de estas políticas se reserva para los ajustes de control de acceso a nivel de columna.
• Las políticas de datos, las etiquetas de políticas asociadas y las rutinas que las usen deben estar en el mismo proyecto.

Etiquetas de política

• El proyecto que contiene la taxonomía de etiquetas de política debe pertenecer a una organización.

• Una jerarquía de etiquetas de políticas no puede tener más de cinco niveles de profundidad desde el nodo raíz hasta la subetiqueta de nivel más bajo, como se muestra en la siguiente captura de pantalla:

  

Definir el control de acceso

Una vez que una taxonomía tiene una política de datos asociada a al menos una de sus etiquetas de política, se aplica automáticamente el control de acceso. Si quieres desactivar el control de acceso, primero debes eliminar todas las políticas de datos asociadas a la taxonomía.

Vistas materializadas y consultas de enmascaramiento de registros repetidos

Si tienes vistas materializadas, las consultas repetidas de enmascaramiento de registros en la tabla base asociada fallarán. Para solucionar este problema, elimina la vista materializada. Si la vista materializada es necesaria por otros motivos, puedes crearla en otro conjunto de datos.

Consultar columnas enmascaradas en tablas con particiones

No se admiten las consultas que incluyen el enmascaramiento de datos en las columnas particionadas o agrupadas.

Dialectos de SQL

No se admite el SQL antiguo.

Rutinas de enmascaramiento personalizadas

Las rutinas de enmascaramiento personalizadas están sujetas a las siguientes limitaciones:

• El enmascaramiento de datos personalizado admite todos los tipos de datos de BigQuery, excepto STRUCT, ya que solo se puede aplicar a los campos hoja del tipo de datos STRUCT.
• Si eliminas una rutina de enmascaramiento personalizada, no se eliminarán todas las políticas de datos que la usen. Sin embargo, las políticas de datos que usan la rutina de enmascaramiento eliminada se quedan con una regla de enmascaramiento vacía. Los usuarios con el rol de lector enmascarado en otras políticas de datos con la misma etiqueta pueden ver los datos enmascarados. Otros usuarios verán el mensaje Permission denied. Los procesos automatizados podrían eliminar las referencias huérfanas a reglas de enmascaramiento vacías al cabo de siete días.

Compatibilidad con otras funciones de BigQuery

API de BigQuery

No es compatible con el método tabledata.list. Para llamar a tabledata.list, debes tener acceso completo a todas las columnas devueltas por este método. El rol Lector pormenorizado de Data Catalog concede el acceso adecuado.

Tablas de BigLake

Compatible. Las políticas de enmascaramiento de datos se aplican a las tablas de BigLake.

API Storage Read de BigQuery

Compatible. Las políticas de enmascaramiento de datos se aplican en la API Storage Read de BigQuery.

BigQuery BI Engine

Compatible. Las políticas de enmascaramiento de datos se aplican en BI Engine. BI Engine no acelera las consultas que tienen en vigor el enmascaramiento de datos. El uso de estas consultas en Looker Studio puede provocar que los informes o los paneles de control relacionados sean más lentos y caros.

BigQuery Omni

Compatible. Las políticas de enmascaramiento de datos se aplican a las tablas de BigQuery Omni.

Recopilación

Parcialmente compatible. Puedes aplicar DDM a las columnas combinadas, pero el enmascaramiento se aplica antes de la combinación. Este orden de las operaciones puede dar lugar a resultados inesperados, ya que la ordenación puede no afectar a los valores enmascarados como se espera (por ejemplo, es posible que la coincidencia que no distingue entre mayúsculas y minúsculas no funcione después del enmascaramiento). Se pueden usar soluciones alternativas, como rutinas de enmascaramiento personalizadas que normalicen los datos antes de aplicar la función de enmascaramiento.

Tareas de copia

No es compatible. Para copiar una tabla del origen al destino, debe tener acceso completo a todas las columnas de la tabla de origen. El rol Lector de datos pormenorizados de Data Catalog concede el acceso adecuado.

Exportación de datos

Compatible. Si tienes el rol Lector enmascarado de BigQuery, los datos exportados se enmascaran. Si tienes el rol Lector detallado de Data Catalog, los datos exportados no se enmascaran.

Seguridad a nivel de fila

Compatible. El enmascaramiento de datos se aplica sobre la seguridad a nivel de fila. Por ejemplo, si se aplica una política de acceso a las filas en location = "US" y location está enmascarado, los usuarios podrán ver las filas en las que location = "US", pero el campo de ubicación está enmascarado.

Buscar en BigQuery

Parcialmente compatible. Puedes llamar a la función SEARCH en columnas indexadas o no indexadas que tengan aplicada la función de enmascaramiento de datos.

Cuando llames a la función SEARCH en columnas a las que se haya aplicado el enmascaramiento de datos, debes usar criterios de búsqueda compatibles con tu nivel de acceso. Por ejemplo, si tienes acceso de lector enmascarado con una regla de enmascaramiento de datos de hash (SHA-256), usarías el valor de hash en tu cláusula SEARCH, de forma similar a la siguiente:

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "sg172y34shw94fujaweu");

Si tienes acceso de lectura detallado, usarías el valor de la columna real en tu cláusula SEARCH, como en el siguiente ejemplo:

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "[e-mail]");

Es menos probable que la búsqueda sea útil si tienes acceso de lector enmascarado a una columna en la que se haya usado la regla de enmascaramiento de datos Anular o Valor de enmascaramiento predeterminado. Esto se debe a que los resultados enmascarados que usarías como criterios de búsqueda, como NULL o "", no son lo suficientemente únicos como para ser útiles.

Cuando se busca en una columna indexada que tiene aplicada una máscara de datos, el índice de búsqueda solo se usa si tienes acceso de lector detallado a la columna.

Capturas

No es compatible. Para crear una copia de una tabla, debes tener acceso completo a todas las columnas de la tabla de origen. El rol Lector con control pormenorizado de Data Catalog concede el acceso adecuado.

Cambio de nombre de tablas

Compatible. El cambio de nombre de las tablas no se ve afectado por el enmascaramiento de datos.

Viaje en el tiempo

Compatible con decoradores de tiempo y con la opción FOR SYSTEM_TIME AS OF en las instrucciones SELECT. Las etiquetas de política del esquema del conjunto de datos actual se aplican a los datos obtenidos.

Almacenamiento en caché de consultas

Parcialmente compatible. BigQuery almacena en caché los resultados de las consultas durante aproximadamente 24 horas, aunque la caché se invalida si se hacen cambios en los datos o en el esquema de la tabla antes de ese periodo. En la siguiente circunstancia, es posible que un usuario que no tenga el rol Lector pormenorizado de Data Catalog concedido en una columna pueda ver los datos de la columna al ejecutar una consulta:

1. Se ha concedido a un usuario el rol de lector de datos pormenorizados de Cloud Data Catalog en una columna.
2. El usuario ejecuta una consulta que incluye la columna restringida y los datos se almacenan en caché.
3. En un plazo de 24 horas desde el paso 2, se asigna al usuario el rol Lector anonimizado de BigQuery y se le revoca el rol Lector pormenorizado de Data Catalog.
4. En un plazo de 24 horas desde el paso 2, el usuario ejecuta la misma consulta y se devuelven los datos almacenados en caché.

Consultas de tablas comodín

No es compatible. Debes tener acceso completo a todas las columnas a las que se hace referencia en todas las tablas que coincidan con la consulta comodín. El rol Lector con control pormenorizado de Data Catalog concede el acceso adecuado.

Siguientes pasos

• Consulta las instrucciones paso a paso para habilitar el enmascaramiento de datos.