Introducción a la seguridad a nivel de la columna de BigQuery

BigQuery proporciona un acceso detallado a columnas sensibles mediante etiquetas de política, o clasificación basada en tipos de datos. Con la seguridad a nivel de la 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.

Flujo de trabajo de seguridad a nivel de la 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 de datos. 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. 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 la política que establece el nodo Alta incluye acceso a 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 la seguridad a nivel de la columna de BigQuery.

Funciones que se usan con la seguridad a nivel de la columna

Las siguientes funciones de Data Catalog se usan para la seguridad a nivel de la columna de BigQuery.

ID y nombre de la función Permisos incluidos Se aplica a Descripción
Administrador de etiquetas de políticas
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 		Proyecto Esta función tiene permiso para hacer lo siguiente:
  • Crear, leer, actualizar y borrar taxonomías
  • Establecer políticas de IAM en etiquetas de políticas
Por lo general, un usuario con esta función se encarga de establecer políticas de administración de datos para la organización.

Lector de categorías de recursos
datacatalog.categoryFineGrainedReader datacatalog.categories.fineGrainedGet Etiqueta de política Esta función tiene permiso para acceder al contenido de las columnas de BigQuery restringidas por una etiqueta de política.

Por lo general, un usuario con esta función consulta los datos.

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

Impacto de las escrituras

Para leer datos de una columna protegida por la seguridad a nivel de la 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 la seguridad 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 tendrá 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.

Un usuario no puede cargar datos de archivos locales o de Cloud Storage, a menos que tenga acceso de lectura detallado. Sin embargo, 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 tendrá 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 Genera un impacto en las escrituras con la seguridad a nivel de columna de BigQuery.

Consulta tablas

Si un usuario tiene acceso a un conjunto de datos y tiene la función de 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 *, recibirá un error que enumera las columnas a las que 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 las vistas

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

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

Si el usuario tiene acceso a nivel de columna a las columnas en 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:

El acceso se controla solo mediante la seguridad a nivel de la columna en las columnas de las tablas subyacentes de la vista. 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, este 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 de las instantáneas

BigQuery permite que los usuarios consulten una tabla en un estado anterior. Esta función te permite consultar las filas de una instantánea anterior de la tabla. También te permite revertir la tabla a la fecha en la que se tomó la instantánea.

En SQL heredado, debes usar el decorador de instantáneas en el nombre de la tabla para consultar una instantánea. En SQL estándar, debes usar la cláusula FOR SYSTEM_TIME AS OF en la tabla para consultar una instantánea.

El límite de tiempo para consultar una instantánea es la más reciente de las siguientes opciones:

  • Los últimos 7 días
  • El momento de creación de la tabla

No puedes consultar una tabla anterior si esta se borró y se volvió a crear con el mismo nombre.

Para ver cómo funcionan las instantáneas con la seguridad a nivel de columna, supongamos que se cumple lo siguiente:

  • Tienes un punto de origen, que es una tabla existente en el momento actual.

  • Tienes la instantánea de la misma tabla.

  • El esquema de la instantánea es idéntico al esquema del origen o es un subconjunto de este. Es decir, todas las columnas de la instantánea se incluyen en el origen.

Con estas suposiciones, los permisos dependen de la seguridad a nivel de la columna más reciente en la tabla de origen (actual). Si el usuario puede leer las columnas actuales, podrá consultar una instantánea de esas columnas.

Si el esquema del origen y la instantánea difieren en las columnas en la consulta, la solicitud para recuperar una instantánea fallará.

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 en sí 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 la seguridad a nivel de columna. Cualquier consulta de SQL heredado se rechaza si existen etiquetas de política en las tablas de destino.

Precios

La seguridad a nivel de columnas 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?