Introducción al enmascaramiento de datos

BigQuery admite el enmascaramiento de datos a nivel de columna. Puedes usar el enmascaramiento de datos para ocultar de manera selectiva los datos de las columnas para grupos de usuarios y, al mismo tiempo, permitirles el acceso a la columna. La funcionalidad 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.

Cuando usas el enmascaramiento de datos en combinación con el control de acceso a nivel de columna, puedes configurar un rango de acceso a los datos de la columna, desde acceso completo a ningún acceso, en función de las necesidades de los diferentes grupos de usuarios. Por ejemplo, en el caso de los datos de ID fiscal, te recomendamos otorgar acceso completo enmascarado a tu grupo de contabilidad y acceso enmascarado a tu grupo de analistas, y que tu grupo de ventas no tenga acceso.

Beneficios

El enmascaramiento de datos proporciona los siguientes beneficios:

  • Permite optimizar el proceso de uso compartido de datos. Puedes enmascarar columnas sensibles para permitir que se compartan tablas con grupos más grandes.
  • A diferencia del control de acceso a nivel de columna, no es necesario modificar las consultas existentes si se excluyen las columnas a las que el usuario no puede acceder. Cuando configuras el enmascaramiento de datos, las consultas existentes enmascaran de forma automática los datos de la columna dependiendo de las funciones que se otorgaron al usuario.
  • Puedes aplicar políticas de acceso a los datos a gran escala. Puedes escribir una política de datos, asociarla con una etiqueta de política y aplicarla a cualquier cantidad de columnas.
  • Habilita el control de acceso basado en atributos. Una etiqueta de política adjunta a una columna proporciona acceso a los datos contextuales, que se determina mediante la política de datos y los principales asociados con esa etiqueta de política.

Flujo de trabajo del enmascaramiento de datos

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

Si deseas habilitar el enmascaramiento de datos, debes crear una taxonomía, crear políticas de datos para las etiquetas de política de la taxonomía y, luego, asociar las etiquetas de política con las columnas de la tabla. Figura 1. Componentes del enmascaramiento de datos.

Para configurar el enmascaramiento de datos, sigue estos pasos:

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

    Cuando creas una política de datos mediante la consola de Google Cloud, debes crear la regla de enmascaramiento de datos y especificar los principales en un solo paso. Cuando creas una política de datos mediante la API de políticas de datos de BigQuery, creas la política de datos y la regla de enmascaramiento de datos en un paso y especificas los principales para 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 usuarios a los que deberían tener acceso a los datos enmascarados en la función de lector enmascarado de BigQuery. Como práctica recomendada, asigna el rol de Lector enmascarado de BigQuery a nivel de la política de datos. Asignar el rol a nivel del proyecto o superior otorga a los usuarios permisos para todas las políticas de datos del proyecto, lo que puede generar problemas debido a permisos excesivos.

    La etiqueta de política asociada con una política de datos también se puede usar para el control de acceso a nivel de la columna. En ese caso, la etiqueta de política también se asocia a uno o más principales a los que se les otorga la función de lector detallado de Data Catalog. Esto permite que estos principales accedan a los datos de la columna original sin enmascarar.

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

Las etiquetas de política se asocian con políticas de datos para configurar el enmascaramiento de datos y, luego, se asocian con columnas de tablas para habilitar el enmascaramiento. Figura 2. Componentes del enmascaramiento de datos.

Para obtener más información sobre la interacción de funciones, consulta Cómo interactúan las funciones de lector enmascarado y lector detallado. Para obtener más información sobre la herencia de etiquetas de política, consulta funciones 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 entorno de ejecución de consulta, según la función del usuario que ejecuta la consulta. El enmascaramiento tiene prioridad sobre cualquier otra operación involucrada 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.

Puedes usar las siguientes reglas de enmascaramiento de datos:

  • Rutina de enmascaramiento personalizado. Muestra el valor de la columna después de aplicarle una función definida por el usuario (UDF). Se requieren permisos de rutina para administrar la regla de enmascaramiento. Esta regla, por su diseño, admite todos los tipos de datos de BigQuery, excepto el tipo de datos STRUCT. Sin embargo, la compatibilidad con los tipos de datos que no sean STRING ni BYTES es limitada. El resultado depende de la función definida.

    Si deseas obtener más información sobre cómo crear UDF para rutinas de enmascaramiento personalizado, consulta Crea rutinas de enmascaramiento personalizado.

  • Máscara del año de la fecha. Muestra el valor de la columna después de truncarlo al año y establecer todas las partes del valor que no sean de año al comienzo del año. Solo puedes usar esta regla con columnas que usen los tipos de datos DATE, DATETIME y TIMESTAMP. Por ejemplo:

    Tipo Original Oculto
    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
  • Valor de enmascaramiento predeterminado. Muestra un valor de enmascaramiento predeterminado para la columna según el tipo de datos de la columna. Usa esto cuando quieras ocultar el valor de la columna, pero revelar el tipo de datos. Cuando esta regla de enmascaramiento de datos se aplica a una columna, hace que sea menos útil en las operaciones JOIN de consulta para usuarios con acceso de lector enmascarado. Esto se debe a que un valor predeterminado no es lo suficientemente único para ser útil cuando se unen tablas.

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

    Tipo de datos Valor de enmascaramiento 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ítica no se pueden aplicar a las columnas que usan el tipo de datos STRUCT, pero se pueden asociar con los campos de hoja de esas columnas.

    JSON null
  • Máscara de correo electrónico. Muestra el valor de la columna después de reemplazar 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 electrónico válida, muestra el valor de la columna después de que se haya ejecutado a través de la función hash SHA-256. Solo puedes usar esta regla con columnas que usen el tipo de datos STRING. Por ejemplo:

    Original Oculto
    abc123@gmail.com XXXXX@gmail.com
    randomtext jQHDyQuj7vJcveEe59ygb3Zcvj0B5FJINBzgM6Bypgw=
    test@gmail@gmail.com Qdje6MO+GLwI0u+KyRyAICDjHbLF1ImxRqaW08tY52k=
  • Primeros cuatro caracteres. Muestra los primeros 4 caracteres del valor de la columna y reemplaza el resto de la string por XXXXX. Si el valor de la columna es igual o inferior a 4 caracteres, muestra el valor de la columna después de que se haya ejecutado a través de la función de hash SHA-256. Solo puedes usar esta regla con columnas que usen el tipo de datos STRING.

  • Hash (SHA-256). Muestra el valor de la columna después de que se haya ejecutado a través de la función de hash SHA-256. Usa esto cuando quieras que el usuario final pueda usar esta columna en una operación JOIN para una consulta. Solo puedes 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 preserva los tipos, por lo que el valor de hash que muestra tiene el mismo tipo de datos que el valor de la columna. Por ejemplo, el valor de hash para un valor de columna STRING también tiene un tipo de datos STRING.

  • Últimos cuatro caracteres. Muestra los últimos 4 caracteres del valor de la columna y reemplaza el resto de la string por XXXXX. Si el valor de la columna es igual o inferior a 4 caracteres, muestra el valor de la columna después de que se haya ejecutado a través de la función hash SHA-256. Solo puedes usar esta regla con columnas que usen el tipo de datos STRING.

  • Anular. Muestra NULL en lugar del valor de la columna. Usa esto cuando quieras ocultar el valor y el tipo de datos de la columna. Cuando esta regla de enmascaramiento de datos se aplica a una columna, hace que sea menos útil en las operaciones JOIN de consulta para usuarios con acceso de lector enmascarado. Esto se debe a que un valor NULL no es lo suficientemente único para ser útil cuando se unen tablas.

Jerarquía de las 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 está reservada para la configuración de control de acceso a nivel de columna. Esto permite que varias políticas de datos se apliquen a una columna en la consulta de un usuario, según los grupos a los que pertenece el usuario. Cuando esto sucede, BigQuery elige qué regla de enmascaramiento de datos aplicar en función de la siguiente jerarquía:

  1. Rutina de enmascaramiento personalizado
  2. Hash (SHA-256)
  3. Máscara de correo electrónico
  4. Últimos cuatro caracteres
  5. Primeros cuatro caracteres
  6. Máscara del año de la fecha
  7. Valor de enmascaramiento predeterminado
  8. Anular

Por ejemplo, el usuario A es miembro de los empleados y los grupos de contabilidad. El usuario A ejecuta una consulta que incluye el campo sales_total, que tiene la etiqueta de política confidential aplicada. La etiqueta de política confidential tiene dos políticas de datos asociadas: una que tiene la función de empleado como el principal y aplica la regla de enmascaramiento de datos de anulación, y otra que tiene la función de contabilidad como el principal y aplica la regla de enmascaramiento de datos de 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 la regla de hash (SHA-256) al valor del campo sales_total en la consulta del usuario A.

En la figura 3, se muestra esta situación:

Cuando hay un conflicto entre la aplicación de las reglas de enmascaramiento de datos de anulación y de hash (SHA-256) debido a los grupos en los que se encuentra un usuario, se prioriza la regla de enmascaramiento de datos de hash (SHA-256).

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

Funciones y permisos

Funciones para administrar taxonomías y etiquetas de políticas

Necesitas la función de administrador de etiquetas de política de Data Catalog para crear y administrar 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 del proyecto.

Este rol otorga la capacidad de hacer lo siguiente:

  • Crear, leer, actualizar y borrar taxonomías y etiquetas de política.
  • Obtener y establecer políticas de IAM en etiquetas de política.

Funciones para crear y administrar políticas de datos

Necesitas una de los siguientes funciones de BigQuery para crear y administrar políticas de datos:

Rol/ID Permisos Descripción
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 del proyecto. Los otros permisos se aplican a nivel de la política de datos.

Este rol otorga la capacidad de hacer lo siguiente:

  • Crear, leer, actualizar y borrar políticas de datos.
  • Obtener y establecer políticas de IAM en políticas de datos.
También necesitas el permiso datacatalog.taxonomies.get, que puedes obtener de varios de las funciones predefinidos de Data Catalog.

Funciones para adjuntar etiquetas de política a las columnas

Necesitas los permisos datacatalog.taxonomies.get y bigquery.tables.setCategory para adjuntar etiquetas de política a las columnas. datacatalog.taxonomies.get se incluye en las funciones de visualizador y de administrador de etiquetas de política de Data Catalog. bigquery.tables.setCategory se incluye en las funciones de administrador de BigQuery (roles/bigquery.admin) y propietario de datos de BigQuery (roles/bigquery.dataOwner).

Funciones para consultar datos enmascarados

Necesitas la función de lector enmascarado de BigQuery para consultar los datos de una columna en la que se aplicó 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.

Esta función permite ver los datos enmascarados de una columna asociada a una política de datos.

Además, el usuario debe tener los permisos adecuados para consultar la tabla. Para obtener más información, consulta Permisos necesarios.

Cómo interactúan las funciones de lector enmascarado y de lector detallado

El enmascaramiento de datos se basa en el control de acceso a nivel de columna. Para una columna determinada, es posible tener algunos usuarios con la función de lector enmascarado de BigQuery que les permita leer datos enmascarados, algunos usuarios con la función de lector detallado de Data Catalog que les permite leer datos sin enmascarar, algunos usuarios con ambos y algunos usuarios con ninguno. Estas funciones interactúan de la siguiente manera:

  • Usuario con las funciones de lector detallado y de lector enmascarado: lo que ve el usuario depende del lugar en la jerarquía de etiquetas de política que se otorga a cada función Para obtener más información, consulta Herencia de autorizaciones en una jerarquía de etiquetas de política.
  • Usuario con la función de lector detallado: puede ver datos de columnas sin enmascarar.
  • Usuario con la función de lector enmascarado: puede ver datos de columnas enmascaradas.
  • Usuario sin estas funciones: permiso denegado.

En el caso de que una tabla tenga columnas que estén protegidas o enmascaradas, para que se ejecute una sentencia SELECT * FROM en esa tabla, un usuario debe ser un miembro de grupos adecuados de modo que se le otorguen las funciones de lector enmascarado o de lector detallado en todas estas columnas.

En cambio, un usuario al que no se les otorgan estas funciones debe especificar solo las columnas a las que tiene acceso en la declaración SELECT o usar SELECT * EXCEPT (restricted_columns) FROM para excluir las columnas protegidas o enmascaradas.

Herencia de autorización en una jerarquía de etiquetas de política

las funciones se evalúan a partir de la etiqueta de política asociada con una columna y, luego, se verifican en cada nivel ascendente de la taxonomía, hasta que se determine que el usuario tiene los permisos adecuados o se alcance la parte superior de la jerarquía de etiquetas de política.

Por ejemplo, considera la etiqueta de política y la configuración de la política de datos que se muestra en la Figura 4:

Evaluación del acceso de los usuarios cuando se otorga la función de lector enmascarado en un nivel superior de la taxonomía y el de lector detallado en un nivel inferior de la taxonomía.

Figura 4. Configuración de la política de datos y las etiquetas de política.

Tienes una columna de tabla que está anotada con la etiqueta de política Financial y un usuario que es miembro de los grupos ftes@example.com y analysts@example.com. Cuando este usuario ejecuta una consulta que incluye la columna anotada, su acceso se determina por la jerarquía definida en la taxonomía de etiqueta de datos. Debido a que la etiqueta de política Financial otorga al usuario la función de lector detallado de Data Catalog, la consulta muestra datos de columna sin enmascarar.

Si otro usuario que solo es miembro de la función ftes@example.com ejecuta una consulta que incluye la columna anotada, la consulta muestra los datos de la columna con un hash mediante el algoritmo SHA-256, porque al usuario se le otorga la función de lector enmascarado de BigQuery mediante la etiqueta de política Confidential, que es la superior de la etiqueta de política Financial.

Un usuario que no es miembro de ninguno de estas funciones recibe un error de acceso denegado si intenta consultar la columna anotada.

Al contrario de la situación anterior, toma la etiqueta de política y la configuración de política de datos que se muestra en la Figura 5:

Evalúa el acceso de los usuarios cuando se otorga la función de lector detallado en un nivel superior de la taxonomía y el de lector enmascarado se otorga en un nivel inferior de la taxonomía.

Figura 5. Configuración de la política de datos y las etiquetas de política.

Tienes la misma situación que se muestra en la figura 4, pero al usuario se le otorga la función de lector detallado en un nivel superior de la jerarquía de etiquetas de política y la función de lector enmascarado en un nivel inferior de la jerarquía de etiquetas de política. Debido a esto, la consulta muestra datos de la columna enmascarada para este usuario. Esto sucede aunque el usuario tenga la función de lector detallado en un nivel superior de la jerarquía de etiquetas, porque el servicio usa la primera función asignada que encuentra a medida que asciende en la jerarquía de etiquetas de política a fin de verificar el acceso de los usuarios.

Si deseas crear una sola política de datos y que se aplique a varios niveles de una jerarquía de etiquetas de política, puedes establecer la política de datos en la etiqueta de política que representa el nivel de jerarquía más alto al que se debe aplicar. Por ejemplo, considera 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 deseas que una política de datos se aplique a todas estas etiquetas de política, establece la política de datos en la etiqueta de política 1. Si deseas que una política de datos se aplique a la etiqueta de política 1b y sus secundarios, establece 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 otorga acceso a los usuarios que tienen la función de lector detallado de Data Catalog.

Por ejemplo, considera la etiqueta de política y la configuración de la política de datos que se muestra en la Figura 6:

La etiqueta de política asociada con la columna se evalúa para determinar si el usuario tiene permiso para acceder a los datos sin enmascarar.

Figura 6. Configuración de la política de datos y las etiquetas de política.

Tienes una columna de tabla que está anotada con la etiqueta de política Financial, y un usuario que es miembro del grupo analysts@example.com. Cuando este usuario intenta acceder a la columna anotada a través de una de las características incompatibles, obtiene un error de acceso denegado. Esto se debe a que se le otorga la etiqueta de política Financial del lector enmascarado de BigQuery, pero en este caso debe tener la función de lector detallado de Data Catalog. Debido a que el servicio ya determinó una función aplicable para el usuario, no continúa verificando más arriba en la jerarquía de etiquetas de política a fin de obtener permisos adicionales.

Ejemplo de enmascaramiento de datos con salida

Para ver cómo las etiquetas, los principales y las funciones trabajan en conjunto, considera este ejemplo.

En example.com, el acceso básico se otorga a través del grupo data-users@example.com. Todos los empleados que necesitan acceso regular a los datos de BigQuery son miembros de este grupo, que tienen asignados todos los permisos necesarios para leer desde las tablas, junto con la función de lector enmascarado de BigQuery.

A los empleados se les asignan grupos adicionales que proporcionan acceso a columnas seguras o enmascaradas en las que es necesario para su trabajo. Todos los miembros de estos grupos adicionales también son miembros de data-users@example.com. Puedes ver cómo estos grupos se asocian con las funciones adecuados en la Figura 7:

Etiquetas de política y políticas de datos para example.com.

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

Luego, las etiquetas de política se asocian con las columnas de la tabla, como se muestra en la Figura 8:

Etiquetas de política example.com asociadas con columnas de tabla.

Figura 8. Etiquetas de política example.com asociadas con columnas de tabla.

Debido a las etiquetas asociadas con las columnas, ejecutar SELECT * FROM Accounts; genera los siguientes resultados para los diferentes grupos:

  • data-users@example.com: A este grupo se le otorgó la función de lector enmascarado de BigQuery en las etiquetas de política PII y Confidential. Se muestran los siguientes resultados:

    SSN Prioridad Valor del ciclo de vida del cliente Fecha de creación Correo electrónico
    NULL "" 0 8 de marzo de 1983 NULL
    NULL "" 0 29 de diciembre de 2009 NULL
    NULL "" 0 14 de julio de 2021 NULL
    NULL "" 0 5 de mayo de 1997 NULL
  • accounting@example.com: A este grupo se le otorgó la función de lector detallado de Data Catalog en la etiqueta de política SSN. Se muestran los siguientes resultados:

    SSN Prioridad Valor del ciclo 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 de 2009 NULL
    345-67-8912 "" 0 14 de julio de 2021 NULL
    456-78-9123 "" 0 5 de mayo de 1997 NULL
  • sales-exec@example.com: A este grupo se le otorgó la función de lector detallado de Data Catalog en la etiqueta de política Confidential. Se muestran los siguientes resultados:

    SSN Prioridad Valor del ciclo 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 de 2009 NULL
    NULL Media 38,000 14 de julio de 2021 NULL
    NULL Bajo 245 5 de mayo de 1997 NULL
  • fin-dev@example.com: A este grupo se le otorgó la función de lector enmascarado de BigQuery en la etiqueta de política Financial. Se muestran los siguientes resultados:

    SSN Prioridad Valor del ciclo de vida del cliente Fecha de creación Correo electrónico
    NULL "" Zmy9vydG5q= 8 de marzo de 1983 NULL
    NULL "" GhwTwq6Ynm= 29 de diciembre de 2009 NULL
    NULL "" B6y7dsgaT9= 14 de julio de 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 enumerados recibe un error de acceso denegado, ya que no se le otorgó la función de lector detallado de Data Catalog ni el de lector enmascarado de BigQuery. Para consultar la tabla Accounts, solo deben especificar columnas a las que tienen acceso en SELECT * EXCEPT (restricted_columns) FROM Accounts para excluir las columnas protegidas o enmascaradas.

Consideraciones de costo

El enmascaramiento de datos puede afectar de forma indirecta la cantidad de bytes procesados y, por lo tanto, afectar el costo de la consulta. Si un usuario consulta una columna enmascarada para ellos con las reglas de anulación o de valor de enmascaramiento predeterminado, esa columna no se analiza en absoluto y se procesan menos bytes.

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.

Administración de políticas de datos

  • Es posible que este atributo no esté disponible cuando se usan reservas que se crearon con determinadas ediciones de BigQuery. Para obtener más información sobre qué atributos están habilitados en cada edición, consulta Introducción a las ediciones de BigQuery.
  • Puedes crear hasta nueve políticas de datos para cada etiqueta de política. Una de estas políticas está reservada para la configuración de control de acceso a nivel de columna.
  • Las políticas de datos, sus etiquetas de política asociadas y cualquier rutina que las use 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ítica no puede tener más de cinco niveles desde el nodo raíz hasta la subetiqueta de nivel más bajo, como se muestra en la siguiente captura de pantalla:

    Profundidad de la etiqueta de política.

Cómo configurar el control de acceso

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

Vistas materializadas y consultas de enmascaramiento de registros repetidas

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

Consulta columnas enmascaradas en tablas particionadas

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

Dialectos de SQL

No se admite SQL heredado.

Rutinas de enmascaramiento personalizado

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

  • El enmascaramiento de datos personalizado admite todos los tipos de datos de BigQuery, excepto STRUCT, ya que el enmascaramiento de datos solo se puede aplicar a los campos de nivel inferior del tipo de datos STRUCT.
  • Si borras una rutina de enmascaramiento personalizada, no se borrarán todas las políticas de datos que la usan. Sin embargo, las políticas de datos que usan la rutina de enmascaramiento borrada quedan con una regla de enmascaramiento vacía. Los usuarios con la función de lector enmascarado en otras políticas de datos con la misma etiqueta pueden ver los datos enmascarados. Otros ven el mensaje Permission denied. Las referencias a reglas de enmascaramiento vacías pueden limpiarse mediante procesos automatizados después 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, necesitas acceso completo a todas las columnas que muestra este método. la función de lector detallado de Data Catalog otorga el acceso adecuado.

Tablas de BigLake

y compatible. Las políticas de enmascaramiento de datos se aplican en las tablas de BigLake.

API de BigQuery Storage Read

y compatible. Las políticas de enmascaramiento de datos se aplican en la API de lectura de almacenamiento de BigQuery.

BigQuery BI Engine

y compatible. Las políticas de enmascaramiento de datos se aplican en BI Engine. BI Engine no acelera las consultas que tienen enmascaramiento de datos vigente. El uso de esas consultas en Looker Studio puede hacer que los informes o paneles relacionados sean más lentos y costosos.

BigQuery Omni

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

Intercalación

No compatible. La intercalación no es compatible con las columnas enmascaradas.

Trabajos de copia

No compatible. Para copiar una tabla de la fuente al destino, debes tener acceso completo a todas las columnas de la tabla de origen. la función de lector detallado de Data Catalog otorga el acceso adecuado.

Exportación de datos

y compatible. Si tienes la función de lector enmascarado de BigQuery, los datos exportados se enmascaran. Si tienes la función de lector detallado de Data Catalog, los datos exportados no se enmascaran.

Seguridad a nivel de la fila

y compatible. El enmascaramiento de datos se aplica sobre la seguridad a nivel de fila. Por ejemplo, si se aplica una política de acceso de fila en location = "US" y location se enmascara, entonces los usuarios podrán ver 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 enmascarado de datos aplicado.

Cuando llamas a la función SEARCH en las columnas en las que se aplica 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), debes usar el valor de hash en tu cláusula SEARCH, que es similar al siguiente:

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

Si tienes acceso detallado de lector, debes usar el valor real de la columna en tu cláusula SEARCH, de manera similar a lo siguiente:

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "jane.doe@example.com");

Es menos probable que la búsqueda sea útil si tienes acceso de lector enmascarado a una columna en la que la regla de enmascaramiento de datos que se usa es Anulación 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 para ser útiles.

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

Instantáneas

No compatible. Para crear una instantánea de una tabla, necesitas acceso completo a todas las columnas de la tabla de origen. la función de lector detallado de Data Catalog otorga el acceso adecuado.

Cambio de nombre de tabla

y compatible. El enmascaramiento de datos no afecta el cambio de nombre de tabla.

Viaje en el tiempo

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

Almacena consultas en caché

Parcialmente compatible. BigQuery almacena en caché los resultados de la consulta durante aproximadamente 24 horas, aunque la caché se invalida si se realizan cambios en los datos o el esquema de la tabla antes de eso. En la siguiente circunstancia, es posible que un usuario que no tiene la función de lector detallado de Data Catalog en una columna aún pueda ver los datos de la columna cuando ejecute una consulta:

  1. Un usuario al que se le otorgó la función de lector detallado de 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 le otorga la función de lector enmascarado de BigQuery y se revoca su función de lector detallado de Data Catalog.
  4. En un plazo de 24 horas desde el paso 2, el usuario ejecuta esa misma consulta y se muestran los datos almacenados en caché.

Consultas de tablas comodín

No compatible. Necesitas acceso completo a todas las columnas a las que se hace referencia en todas las tablas que coinciden con la consulta comodín. La función de lector detallado de Data Catalog otorga el acceso adecuado.

¿Qué sigue?