Introducción al control de acceso a nivel de columna

.

BigQuery proporciona acceso granular a columnas sensibles mediante etiquetas de política o con una clasificación basada en tipos de datos. Con el control de acceso a nivel de columna de BigQuery, puedes crear políticas que comprueben, en el momento de la consulta, si un usuario tiene el acceso adecuado. Por ejemplo, una política puede aplicar comprobaciones 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 enmascaramiento dinámico de datos. El enmascaramiento de datos te permite enmascarar datos sensibles sustituyendo el valor real de una columna por contenido nulo, predeterminado o cifrado con hash.

Flujo de trabajo de control de acceso a nivel de columna

Para restringir el acceso a los datos a nivel de columna, sigue estos pasos:

1. Define una taxonomía y etiquetas de política. Crea y gestiona una taxonomía y etiquetas de política para tus datos. Para consultar las directrices, consulta Prácticas recomendadas para las etiquetas de política.

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

3. Aplica el control de acceso a la taxonomía. Al aplicar el control de acceso, se aplican las restricciones de acceso definidas para todas las etiquetas de política de la taxonomía.

4. Gestionar el acceso a las etiquetas de política. Usa políticas de Gestión de Identidades y Accesos (IAM) para restringir el acceso a cada etiqueta de política. La política se aplica a cada columna que pertenece a la etiqueta de política.

Cuando un usuario intenta acceder a los datos de una columna en el momento de la consulta, BigQuery comprueba 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.

Identificar qué se debe etiquetar

Para determinar los tipos de datos sensibles que tiene y qué columnas necesitan etiquetas de política, puede generar perfiles de sus datos en una organización, una carpeta o un proyecto con Protección de Datos Sensibles. Los perfiles de datos contienen métricas y metadatos sobre tus tablas, y te ayudan a determinar dónde se encuentran los datos sensibles y de alto riesgo. Protección de Datos Sensibles registra estas métricas a nivel de proyecto, tabla y columna. Para obtener más información, consulta el artículo sobre perfiles de datos de BigQuery.

En la siguiente imagen se muestra una lista de perfiles de datos de columnas (haz clic para ampliarla). Las columnas con valores de riesgo de datos altos pueden contener datos de alta sensibilidad y no tener controles de acceso a nivel de columna. También es posible que esas columnas contengan datos de sensibilidad moderada o alta a los que pueda acceder un gran número de personas.

Caso práctico de ejemplo

Imagina una organización que necesita clasificar los datos sensibles en dos categorías: Alto y Medio.

Para configurar la seguridad a nivel de columna, un administrador de datos que tenga los permisos adecuados debe seguir estos pasos para configurar una jerarquía de clasificación de datos.

1. El responsable de los datos crea una taxonomía llamada "Importancia para la empresa". La taxonomía incluye los nodos o etiquetas de política Alto y Medio.

2. El responsable de los datos decide que la política del nodo Alto incluya el acceso para un grupo llamado acceso-de-nivel-alto.

3. El responsable de los datos crea más niveles de nodos en la taxonomía, en Alto y Medio. El nodo de nivel más bajo es un nodo hoja, como el nodo hoja employee_ssn. El responsable de los datos puede crear una política de acceso diferente para el nodo hoja employee_ssn o no.

4. El responsable de los datos asigna una etiqueta de política a columnas de tabla específicas. En este ejemplo, el responsable de los datos asigna la política de acceso Alto a la columna employee_ssn de una tabla.

5. En la página Esquema actual de la consola, el responsable de los datos puede ver la etiqueta de política que rige una columna concreta. En este ejemplo, la columna employee_ssn está etiquetada con la etiqueta de política High. Por lo tanto, al ver el esquema de employee_ssn, la consola muestra el nombre de la taxonomía y la etiqueta de política en el campo Policy tags: Business criticality:High.

   

   Para obtener información sobre cómo usar la consola para definir una etiqueta de política, consulta Definir una etiqueta de política en una columna.

   También puedes definir la etiqueta de política con el comando bq update. El campo names de policyTags incluye el ID de la etiqueta de política High (Alto), 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"]
      }
    },
    ...
   ]

   Para obtener información sobre cómo usar el comando bq update para definir una etiqueta de política, consulta Definir una etiqueta de política en una columna.

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

Con este acceso pormenorizado, puedes gestionar el acceso a muchas columnas controlando solo un pequeño número de etiquetas de política de clasificación de datos.

Para obtener más información sobre estos pasos, consulta Restringir el acceso con el control de acceso a nivel de columna.

Roles usados 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 Administrador de etiquetas de política de Data Catalog es necesario para los usuarios que quieran crear y gestionar 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 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.

Para crear y gestionar políticas de datos, se necesita el rol Administrador de políticas de datos de BigQuery, Administrador de BigQuery o Propietario de datos de BigQuery. Cuando usas la consola deGoogle Cloud para aplicar el control de acceso a una taxonomía, el servicio crea una política de datos automáticamente.

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.

Los usuarios que necesiten acceder a los datos de columnas protegidas deben tener el rol de lector pormenorizado de Data Catalog.

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

Para obtener más información sobre los roles de Data Catalog, consulta Gestión de Identidades y Accesos (IAM) de Data Catalog. Para obtener más información sobre los roles de BigQuery, consulta el artículo sobre el control de acceso con gestión de identidades y accesos.

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 mediante el acceso de lectura detallado en las etiquetas de política de la columna.

Esto se aplica a:

• 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, los requisitos del usuario dependen del tipo de escritura.

Si la operación de escritura es una inserción, no se requiere acceso de lectura pormenorizado. Sin embargo, el usuario no tiene acceso de lectura a los datos insertados, a menos que tenga 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 actualización, una eliminación o una combinación, el usuario no podrá realizarla a menos que tenga acceso de lectura detallado a las columnas de lectura.

Un usuario puede cargar datos de archivos locales o de Cloud Storage. Al cargar datos en una tabla, BigQuery no comprueba el permiso de lectura detallado en las columnas de la tabla de destino. Esto se debe a que la carga de datos no requiere leer contenido de la tabla de destino. Del mismo modo, un usuario puede cargar datos de streaming, ya que las cargas de streaming no comprueban las etiquetas de política. El usuario no tiene acceso de lectura a los datos que se han cargado desde un flujo, a menos que tenga acceso de lectura detallado.

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

Consultar tablas

Si un usuario tiene acceso a un conjunto de datos y el rol Lector con control pormenorizado de Data Catalog, podrá acceder a los datos de las columnas. El usuario ejecuta una consulta como de costumbre.

Si un usuario tiene acceso al conjunto de datos, pero no tiene el rol de lector con control pormenorizado de Data Catalog, no podrá acceder a los datos de la columna. Si un usuario de este tipo ejecuta SELECT *, recibe un error que muestra las columnas a las que no puede acceder. Para resolver el error, puedes hacer lo siguiente:

• 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 sí al resto, puede ejecutar la siguiente consulta:

  SELECT * EXCEPT (ssn) FROM ...

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

• Pide a un administrador de Data Catalog que añada al usuario como lector de datos pormenorizados de Data Catalog a la clase de datos pertinente. El mensaje de error proporciona el nombre completo de la etiqueta de política a la que el usuario necesita acceder.

Consultar vistas

El impacto de la seguridad a nivel de 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 de forma transparente.

Una vista autorizada es una de las siguientes:

• Una vista que tiene autorización explícita para acceder a las tablas de un conjunto de datos.
• Una vista que tiene autorización implícita para acceder a las tablas de un conjunto de datos porque está incluida 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:

Si el usuario tiene acceso de gestión de identidades y accesos a las tablas y al conjunto de datos subyacentes de la vista, así como acceso a nivel de columna a las tablas subyacentes de la vista, podrá consultar las columnas de la vista. De lo contrario, el usuario no podrá consultar las columnas de la vista.

Si la vista es una vista autorizada:

Solo la seguridad a nivel de columna de 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 comprobar el acceso. Si el usuario tiene acceso a las etiquetas de políticas usadas en las tablas subyacentes de la vista autorizada, puede consultar las columnas de la vista autorizada.

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

Impacto de los viajes 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 restaurar una tabla a un momento dado.

En el SQL antiguo, las consultas de datos históricos se realizan mediante decoradores de tiempo en el nombre de la tabla. En GoogleSQL, puedes consultar el historial de datos mediante la cláusula FOR SYSTEM_TIME AS OF en la tabla.

Las vistas materializadas con la opción max_staleness definida devuelven datos históricos de su intervalo de obsolescencia. Este comportamiento es similar al de una consulta que usa FOR SYSTEM_TIME AS OF en el momento de la última actualización de la vista, ya que permite a BigQuery consultar registros que se han eliminado o actualizado. Supongamos que consultas el historial de datos 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 un subconjunto de este, BigQuery comprueba la seguridad a nivel de columna más reciente de la tabla actual. Si el usuario tiene permiso para leer las columnas actuales, podrá consultar el historial de datos de esas columnas. Para eliminar o enmascarar datos sensibles de columnas protegidas por la seguridad a nivel de columna, esta se puede reducir de forma segura solo después de que haya transcurrido el periodo de conservación configurado desde la limpieza de los datos sensibles.

• Si el esquema en el momento t es diferente del esquema actual de las columnas de la consulta, esta fallará.

Consideraciones de ubicación

Cuando elija una ubicación para su taxonomía, tenga 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 la ubicación de la taxonomía.

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

Aunque no puedes aplicar una etiqueta de política a una columna de una tabla que se encuentre en otra ubicación, puedes copiar la taxonomía a otra ubicación replicándola explícitamente allí.

Si quieres usar la misma taxonomía y las mismas etiquetas de política en varias ubicaciones regionales, consulta más información sobre cómo replicar taxonomías en el artículo Gestionar etiquetas de política en varias ubicaciones.

Organizaciones

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

Limitaciones

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

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

• Si sobrescribes una tabla de destino, se eliminarán todas las etiquetas de política 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 se producen en una operación independiente de la ejecución de la consulta. Si escribe los resultados de una consulta en una tabla especificando la marca --destination_table y la consulta genera una excepción posteriormente, es posible que se omitan los cambios de esquema. Si esto ocurre, comprueba el esquema de la tabla de destino y actualízalo manualmente si es necesario.

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

• Una tabla puede tener un máximo de 1000 etiquetas de políticas únicas.

• No puedes usar el SQL antiguo si has habilitado el control de acceso a nivel de columna. Se rechazarán las consultas de SQL antiguas si hay etiquetas de política en las tablas de destino.

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

  

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

• No puedes copiar una tabla entre regiones si has habilitado el control de acceso a nivel de columna o de fila. Se rechazarán las copias de tablas entre regiones si las tablas de origen tienen etiquetas de política.

Precios

Para controlar el acceso a nivel de columna, es necesario usar 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 datos de una tabla con etiquetas de política, guardamos las etiquetas de política a las que se hace referencia en Cloud Logging. Sin embargo, la comprobación de la etiqueta de política no está asociada a la consulta que la ha activado.

Con Cloud Logging, los auditores pueden saber quién tiene acceso a qué categorías de datos sensibles. Para obtener más información, consulta el artículo sobre auditoría de etiquetas de políticas.

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

Para obtener más información sobre el registro, consulta Google CloudCloud Logging.

Siguientes pasos

• Para obtener más información sobre cómo usar el control de acceso a nivel de columna, consulta Restringir el acceso con el control de acceso a nivel de columna.

• Para obtener información sobre las prácticas recomendadas para las etiquetas de política, consulta el artículo Prácticas recomendadas de BigQuery: usar etiquetas de política.