Introducción al control de acceso a nivel de columna

Nota: Es posible que esta función no esté disponible cuando se usan reservas que se crearon con determinadas ediciones de BigQuery. Para obtener más información sobre qué funciones están habilitadas en cada edición, consulta Introducción a las ediciones de BigQuery.

BigQuery proporciona un acceso detallado a columnas sensibles a través de etiquetas de política, o clasificación basada en tipos de datos. Con el control de acceso a nivel de columna de BigQuery, puedes crear políticas que verifiquen, en el momento de la consulta, si un usuario tiene acceso adecuado. Por ejemplo, una política puede aplicar verificaciones de acceso, como las siguientes:

• Debes estar en group:high-access para ver las columnas que contienen TYPE_SSN.

Para mejorar el control de acceso a nivel de columna, puedes usar el enmascaramiento de datos dinámico de forma opcional. El enmascaramiento de datos te permite enmascarar datos sensibles a través de la sustitución del contenido nulo, predeterminado o con codificación hash en lugar del valor real de la columna.

Flujo de trabajo del control de acceso a nivel de columna

Para restringir el acceso a los datos a nivel de la columna, debes realizar las siguientes acciones:

1. Define una taxonomía y etiquetas de política. Crear y administrar una taxonomía y etiquetas de política para tus datos. Si deseas conocer los lineamientos, consulta Prácticas recomendadas para las etiquetas de política.

2. Asigna etiquetas de política a las columnas de BigQuery. En BigQuery, usa las anotaciones de esquema para asignar una etiqueta de política a cada columna en la que desees restringir el acceso.

3. Aplica el control de acceso a la taxonomía. La aplicación del control de acceso hace que se apliquen las restricciones de acceso definidas para todas las etiquetas de política en la taxonomía.

4. Administra el acceso a las etiquetas de política Usa políticas de Identity and Access Management (IAM) para restringir el acceso a cada etiqueta de política. La política está vigente para cada columna que pertenece a la etiqueta de política.

Cuando un usuario intenta acceder a los datos de la columna en el momento de la consulta, BigQuery verifica la etiqueta de política de la columna y su política para ver si el usuario tiene autorización para acceder a los datos.

Nota: Se aplica el control de acceso a nivel de la columna, además de las LCA de conjuntos de datos existentes. Un usuario necesita tanto el permiso del conjunto de datos como el de la etiqueta de política para acceder a los datos protegidos por el control de acceso a nivel de columna.

Identifica lo que se debe etiquetar

Para determinar los tipos de datos sensibles que tienes y qué columnas necesitan etiquetas de política, considera generar perfiles de tus datos en una organización, una carpeta o un proyecto con Sensitive Data Protection. Los perfiles de datos contienen métricas y metadatos sobre tus tablas y te ayudan a determinar dónde residen los datos sensibles y de alto riesgo. Sensitive Data Protection informa estas métricas a nivel de proyecto, tabla y columna. Si deseas obtener más información, consulta Perfiles de datos para datos de BigQuery.

En la siguiente imagen, se muestra una lista de perfiles de datos de columnas (haz clic para ampliar). Las columnas con valores altos de riesgo de datos pueden contener datos de alta sensibilidad y no tienen controles de acceso a nivel de columna. Como alternativa, esas columnas pueden contener datos moderados o de alta sensibilidad a los que puede acceder una gran cantidad de personas.

Ejemplo de caso de uso

Considera una organización que necesita clasificar datos sensibles en dos categorías: Alta y Media.

Para configurar la seguridad a nivel de la columna, un administrador de datos, que tiene los permisos apropiados, realizará los siguientes pasos para configurar una jerarquía de clasificación de datos.

1. El administrador de datos crea una taxonomía llamada “Importancia empresarial”. La taxonomía incluye los nodos o las etiquetas de política Alta y Media.

2. El administrador de datos decide que la política para el nodo Alta incluye acceso para un grupo llamado acceso de alto nivel.

3. El administrador de datos crea más niveles de nodos en la taxonomía, en Alta y Media. El nodo de nivel más bajo es un nodo de hoja, como employee_ssn. Los datos pueden crear una política de acceso diferente para el nodo hoja employee_ssn, o no.

4. El conjunto de datos asigna una etiqueta de política a columnas de tablas específicas. En este ejemplo, los datos que se corresponden a cada uno asigna la política de acceso Alta a la columna employee_ssn en una tabla.

5. En la página Esquema actual de la consola, los datos de la plantilla pueden ver la etiqueta de política que rige una columna específica. En este ejemplo, la columna employee_ssn se encuentra en la etiqueta de política Alta, por lo que, cuando consultas el esquema de employee_ssn, Console muestra el nombre de la taxonomía y la etiqueta de política en el campo Policy tags: Business criticality:High.

   

   Si quieres obtener detalles sobre cómo usar la consola para establecer una etiqueta de política, consulta Establece una etiqueta de política en una columna.

   Como alternativa, puedes establecer la etiqueta de política con el comando bq update. El campo names de policyTags incluye el ID de la etiqueta de política Alta, projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id:

   [
    ...
    {
      "name": "ssn",
      "type": "STRING",
      "mode": "REQUIRED",
      "policyTags": {
        "names": ["projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id"]
      }
    },
    ...
   ]

   Si deseas obtener detalles sobre cómo usar el comando bq update para configurar una etiqueta de política, consulta Establece una etiqueta de política en una columna.

   Nota: Solo puedes asignar una etiqueta de política por columna.

6. El administrador realiza pasos similares para la etiqueta de política Media.

Con este acceso detallado, puedes administrar el acceso a muchas columnas a través del control de solo una pequeña cantidad de etiquetas de política de clasificación de datos.

Para obtener detalles sobre estos pasos, consulta Restringe el acceso con el control de acceso a nivel de columna.

Roles que se usan con el control de acceso a nivel de columna

Los siguientes roles se usan para el control de acceso a nivel de columna de BigQuery.

El rol de administrador de etiquetas de política de Data Catalog es obligatorio para los usuarios que necesitan crear y administrar taxonomías y etiquetas de política.

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.

Se requiere el rol de administrador de BigQuery o el de propietario de datos de BigQuery para crear y administrar políticas de datos. Cuando usas la consola de Google Cloud para aplicar el control de acceso en una taxonomía, el servicio crea una política de datos de forma silenciosa.

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 los roles predefinidos de Data Catalog.

El rol de lector detallado de Data Catalog es obligatorio para los usuarios que necesitan acceso a los datos en columnas protegidas.

Rol/ID	Permisos	Descripción
Lector detallado/datacatalog.categoryFineGrainedReader	datacatalog.categories.fineGrainedGet	Se aplica a nivel de etiqueta de política. Este rol otorga la capacidad de acceder al contenido de las columnas restringidas por una etiqueta de política.

Para obtener más información sobre las funciones de Data Catalog, consulta Identity and Access Management de Data Catalog (IAM). Para obtener más información sobre los roles de BigQuery, consulta Control de acceso con IAM.

Impacto de las escrituras

Para leer datos de una columna protegida por el control de acceso a nivel de columna, el usuario siempre debe tener permiso de lectura, a través del acceso de lectura detallado, en las etiquetas de política de la columna.

Esto aplica para las siguientes situaciones:

• Tablas, incluidas las tablas comodín
• Vistas
• Copiar tablas

Para escribir datos en una fila de una columna protegida por el control de acceso a nivel de columna, el requisito del usuario depende del tipo de escritura.

Si la operación de escritura es una de inserción, no se requiere acceso de lectura detallado. Sin embargo, el usuario no tiene acceso para leer los datos que se insertaron, a menos que tenga un acceso de lectura detallado.

Si un usuario ejecuta una instrucción INSERT SELECT, se requiere el rol de lector detallado en la tabla consultada.

Si la operación de escritura es una de actualización, eliminación o combinación, el usuario no puede realizar la operación, a menos que tenga acceso de lectura detallado a las columnas de lectura.

Un usuario puede cargar datos desde archivos locales o desde Cloud Storage. Cuando cargas datos en una tabla, BigQuery no verifica el permiso detallado de lector en las columnas de la tabla de destino. Esto se debe a que la carga de datos no requiere la lectura de contenido de la tabla de destino. Del mismo modo, un usuario puede cargar datos desde una transmisión, ya que las cargas de transmisión no revisan las etiquetas de política. El usuario no tiene acceso para leer los datos que se cargaron desde una transmisión, a menos que tenga acceso de lectura detallado.

Para obtener más información, consulta Impacto en las operaciones de escritura con el control de acceso a nivel de columna.

Consulta tablas

Si un usuario tiene acceso a un conjunto de datos y tiene la función Lector detallado de Data Catalog, los datos de la columna estarán disponibles para el usuario. El usuario ejecuta una consulta como de costumbre.

Si un usuario tiene acceso a un conjunto de datos, pero no tiene la función Lector detallado de Data Catalog, los datos de la columna no están disponibles para el usuario. Si ese usuario ejecuta SELECT *, recibe un error que enumera las columnas a las que el usuario no puede acceder. Para resolver el error, puedes realizar una de las siguientes acciones:

• Modifica la consulta para excluir las columnas a las que el usuario no puede acceder. Por ejemplo, si el usuario no tiene acceso a la columna ssn, pero tiene acceso a las columnas restantes, puede ejecutar la siguiente consulta:

  SELECT * EXCEPT (ssn) FROM ...

  En el ejemplo anterior, la cláusula EXCEPT excluye la columna ssn.

• Solicita a un administrador de Data Catalog que agregue al usuario como un lector detallado de Data Catalog a la clase de datos relevantes. El mensaje de error proporciona el nombre completo de la etiqueta de política a la que el usuario necesitaría acceder.

Consulta vistas

El impacto de la seguridad a nivel de columna en las vistas es independiente de si la vista es autorizada o no. En ambos casos, la seguridad a nivel de columna se aplica con transparencia.

Una vista autorizada es una de las siguientes opciones:

• Una vista que está autorizada de forma explícita para acceder a las tablas en un conjunto de datos.
• Una vista que está autorizada de forma implícita para acceder a las tablas en un conjunto de datos porque está contenida en un conjunto de datos autorizado.

Para obtener más información, consulta Vistas autorizadas y Conjuntos de datos autorizados.

Si la vista no es una vista autorizada, sucede lo siguiente:

Si el usuario tiene acceso de IAM al conjunto de datos y las tablas subyacentes de la vista, así como acceso a nivel de columna a las tablas subyacentes de la vista, el usuario puede consultar las columnas en la vista. De lo contrario, no puede consultar las columnas en la vista.

Si la vista es una vista autorizada, sucede lo siguiente:

Solo la seguridad a nivel de la columna en las columnas de las tablas subyacentes de la vista controla el acceso. Las políticas de IAM a nivel de tabla y de conjunto de datos, si las hay, no se usan para verificar el acceso. Si el usuario tiene acceso a las etiquetas de política que se usan en las tablas subyacentes de la vista autorizada, entonces puede consultar las columnas en la vista autorizada.

En el siguiente diagrama, se muestra cómo se evalúa el acceso a una vista.

Impacto del viaje en el tiempo y las vistas materializadas con max_staleness

BigQuery te permite consultar una tabla en un estado anterior. Esta función te permite consultar las filas de un momento anterior. También te permite restablecer una tabla desde un momento determinado.

En SQL heredado, debes usar decoradores de tiempo en el nombre de la tabla para consultar los datos históricos. En GoogleSQL, debes usar la cláusula FOR SYSTEM_TIME AS OF en la tabla para consultar los datos históricos.

Las vistas materializadas con la opción max_staleness establecida muestran los datos históricos desde su intervalo de inactividad. Este comportamiento es similar a una consulta que usa FOR SYSTEM_TIME AS OF en el momento de la última actualización de la vista, ya que permite que BigQuery consulte registros que se borraron o actualizaron. Supongamos que consultas los datos históricos de una tabla en el momento t. En ese caso:

• Si el esquema en el momento t es idéntico al esquema actual de la tabla, o es un subconjunto de este, BigQuery verifica la seguridad a nivel de columna más reciente en la tabla actual. Si el usuario puede leer las columnas actuales, puede consultar los datos históricos de esas columnas. Para borrar o enmascarar datos sensibles de columnas que están protegidas por la seguridad a nivel de la columna, la seguridad a nivel de la columna se puede relajar de forma segura solo después de que haya transcurrido el período de viaje en el tiempo configurado desde la limpieza de los datos sensibles.

• Si el esquema en el momento t difiere del esquema actual para las columnas en la consulta, esta falla.

Consideraciones de ubicación

Cuando elijas una ubicación para tu taxonomía, ten en cuenta las siguientes limitaciones.

Etiquetas de política

Las taxonomías son recursos regionales, como los conjuntos de datos y las tablas de BigQuery. Cuando creas una taxonomía, especificas la región, o ubicación, para la taxonomía.

Puedes crear una taxonomía y aplicar etiquetas de política a las tablas en todas las regiones donde BigQuery está disponible. Sin embargo, para aplicar etiquetas de política de una taxonomía a una columna de tabla, la taxonomía y la tabla deben existir en la misma ubicación regional.

Aunque no puedes aplicar una etiqueta de política a una columna de tabla que existe en una ubicación diferente, puedes copiar la taxonomía a otra ubicación si la replicas de forma explícita allí.

Si quieres usar la misma taxonomía y las mismas etiquetas de política en varias ubicaciones regionales, obtén más información sobre la replicación de taxonomías en Administra etiquetas de política en las ubicaciones.

Organizaciones

No puedes usar referencias entre organizaciones. Una tabla y las etiquetas de política que deseas aplicar a sus columnas deben existir dentro de la misma organización.

Limitaciones

• Es posible que esta función no esté disponible cuando se usan reservas que se crearon con determinadas ediciones de BigQuery. Para obtener más información sobre qué funciones están habilitadas en cada edición, consulta Introducción a las ediciones de BigQuery.

• BigQuery solo admite el control de acceso a nivel de columna para las tablas de BigLake, las tablas de BigQuery y las tablas de BigQuery Omni.

• Si reemplazas en una tabla de destino, las etiquetas de política existentes se quitarán de la tabla, a menos que uses la marca --destination_schema para especificar un esquema con etiquetas de política. En el siguiente ejemplo, se muestra cómo usar --destination_schema.

  bq query --destination_table mydataset.mytable2 \
    --use_legacy_sql=false --destination_schema=schema.json \
    'SELECT * FROM mydataset.mytable1'
  

  Los cambios en el esquema ocurren en una operación independiente de la ejecución de consulta. Si escribes los resultados de las consultas en una tabla a través de la especificación de la marca --destination_table y, luego, la consulta genera una excepción, es posible que se omitan los cambios de esquema. Si esto ocurre, verifica el esquema de la tabla de destino y actualízalo de forma manual si es necesario.

• Una columna puede tener solo una etiqueta de política.

• Una tabla puede tener como máximo 1,000 etiquetas de política únicas.

• No puedes usar SQL heredado si habilitaste el control de acceso a nivel de columna. Cualquier consulta de SQL heredado se rechaza si existen etiquetas de política en las tablas de destino.

• 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:

  

• Los nombres de las taxonomías deben ser únicos entre todos los proyectos de una organización.

• No puedes copiar una tabla entre regiones si habilitaste el control de acceso a nivel de columna o de fila. Cualquier copia de las tablas entre regiones se rechaza si existen etiquetas de política en las tablas de origen.

Precios

El control de acceso a nivel de columna requiere el uso de BigQuery y Data Catalog. Para obtener información sobre los precios de estos productos, consulta los siguientes temas:

• Precios de BigQuery
• Precios de Data Catalog

Registros de auditoría

Cuando se leen los datos de tablas con etiquetas de política, guardamos las etiquetas de política a las que se hace referencia en Cloud Logging. Sin embargo, la verificación de las etiquetas de política no está asociada con la consulta que activó la verificación.

A través de Cloud Logging, los auditores pueden comprender quién tiene qué tipo de acceso a qué categorías de datos sensibles. Para obtener más información, consulta Cómo auditar las etiquetas de política.

Para obtener más información sobre el registro en BigQuery, consulta Introducción a la supervisión de BigQuery.

Para obtener más información sobre el acceso en Google Cloud, consulta Cloud Logging.

¿Qué sigue?

• Para obtener detalles sobre el uso del control de acceso a nivel de columna, consulta Restringe el acceso con el control de acceso a nivel de columna.

• Para obtener información acerca de las prácticas recomendadas de las etiquetas de política, consulta Prácticas recomendadas de BigQuery sobre el uso de las etiquetas de política.