Introducción al control de acceso a nivel de columna

BigQuery proporciona un acceso detallado a columnas sensibles mediante 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 (vista previa) de forma opcional. El enmascaramiento de datos te permite enmascarar datos sensibles mediante 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

Flujo de trabajo

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. Usa Data Catalog a fin de crear y administrar una taxonomía y etiquetas de política para los 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 administración de identidades y accesos (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 a fin de ver si el usuario tiene autorización para acceder a los datos.

Ejemplo de caso de uso

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

Etiquetas de política

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 “Estado crítico de la empresa” en Data Catalog. 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.

    IU de la etiqueta de política

    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.

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

Con este acceso detallado, puedes administrar el acceso a muchas columnas mediante el 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.policyTagAdmin 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.

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 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.

Accede a las vistas

Impacto del viaje en el tiempo

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 SQL estándar, debes usar la cláusula FOR SYSTEM_TIME AS OF en la tabla para consultar los datos históricos.

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.

  • 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 explícitamente 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

  • 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'
    
  • 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.

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:

Audit Logging

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?