Introducción a la seguridad a nivel de las filas de BigQuery

En este documento, se explica el concepto de seguridad a nivel de fila, cómo funciona en BigQuery, cuándo usar la seguridad a nivel de fila para proteger los datos y otros detalles.

¿Qué es la seguridad a nivel de las filas?

La seguridad a nivel de las filas te permite filtrar datos y habilita el acceso a filas específicas en una tabla, según las condiciones de usuario aptas.

BigQuery ya admite controles de acceso a nivel de proyecto, conjunto de datos y tabla, además deseguridad a nivel de la columna mediante etiquetas de política. La seguridad a nivel de las filas extiende el principio de privilegio mínimo mediante la habilitación del control de acceso detallado a un subconjunto de datos en una tabla de BigQuery, por medio de las políticas de acceso a nivel de las filas.

Una tabla puede tener varias políticas de acceso a nivel de las filas. Las políticas de acceso a nivel de las filas pueden coexistir en una tabla con seguridad a nivel de columna y controles de acceso a nivel de las tablas, nivel del conjunto de datos y a nivel de proyecto.

Cómo funciona la seguridad a nivel de las filas

En un nivel alto, la seguridad a nivel de las filas implica la creación de políticas de acceso a nivel de las filas en una tabla de BigQuery de destino. Estas políticas actúan como filtros para ocultar o mostrar ciertas filas de datos, según si un usuario o grupo está en una lista permitida. Se denegará el acceso a cualquier usuario o grupo no incluido específicamente en la lista de permitidos.

Un usuario autorizado, con las funciones de administración de identidades y accesos (IAM), Administrador de BigQuery o Propietario de datos de BigQuery, puede crear políticas de acceso a nivel de las filas en una tabla de BigQuery.

Cuando creas una política de acceso a nivel de fila, especificas la tabla por nombre y qué usuarios o grupos (lo que se denomina grantee-list) pueden acceder a ciertos datos de fila. La política también incluye los datos en los que deseas filtrar, llamados filter_expression. La filter_expression funciona como una cláusula WHERE en una consulta típica.

Si deseas obtener instrucciones para crear y usar una política de acceso a nivel de las filas, consulta Administra la seguridad a nivel de las filas.

Consulta la referencia de DDL para conocer la sintaxis, el uso y las opciones completas cuando se crean políticas de acceso a nivel de las filas.

Ejemplos de casos de uso

En los siguientes ejemplos, se muestran posibles casos de uso para la seguridad a nivel de las filas.

Filtra datos de las filas según la región

Considera el caso en el que una tabla dataset1.table1 contiene filas que pertenecen a diferentes regiones (denotadas por la columna region).

Puedes crear y propagar la tabla de ejemplo con la siguiente consulta:

CREATE TABLE IF NOT EXISTS
  dataset1.table1 (partner STRING,
    contact STRING,
    country STRING,
    region STRING);
INSERT INTO
  dataset1.table1 (partner,
    contact,
    country,
    region)
VALUES
  ('Example Customers Corp', 'alice@examplecustomers.com', 'Japan', 'APAC'),
  ('Example Enterprise Group', 'bob@exampleenterprisegroup.com', 'Singapore', 'APAC'),
  ('Example HighTouch Co.', 'carrie@examplehightouch.com', 'USA', 'US'),
  ('Example Buyers Inc.', 'david@examplebuyersinc.com', 'USA', 'US');

La seguridad a nivel de fila permite que un propietario o administrador de datos implemente políticas. La siguiente instrucción implementa una política que restringe a los usuarios del grupo de distribución de APAC a ver solo a los socios de la región de APAC:

CREATE ROW ACCESS POLICY
  apac_filter
ON
  dataset1.table1 GRANT TO ("group: sales-apac@example.com")
FILTER USING
  (region="APAC" );

El comportamiento resultante es que los usuarios del grupo sales-apac@example.com solo pueden ver filas en las que el valor de region es APAC.

La siguiente declaración implementa una política que restringe a las personas y a los grupos para que solo vean socios de la región de EE.UU.:

CREATE ROW ACCESS POLICY
  us_filter
ON
  dataset1.table1 GRANT TO ("group:sales-us@example.com",
"user: jon@example.com")
FILTER USING
  (region="US");

El comportamiento resultante es que los usuarios del grupo sales-us@example.com y el usuario jon@example.com solo pueden ver filas en las que el valor de region es US.

En la siguiente imagen, se muestra cómo las dos políticas de acceso anteriores restringen qué usuarios y grupos pueden ver qué filas de la tabla:

Caso de uso de seguridad a nivel de las filas para las regiones

Los usuarios que no estén en los grupos de APAC o US no verán ninguna fila.

Filtra datos de las filas según los datos sensibles

Ahora, consideremos un caso de uso diferente, en el que tienes una tabla que contiene información sobre los salarios.

Puedes crear y propagar la tabla de ejemplo con la siguiente consulta:

CREATE OR REPLACE TABLE
  dataset1.table1 (name STRING,
    department STRING,
    salary INT64,
    email STRING);
INSERT INTO
  dataset1.table1 ( name,
    department,
    salary,
    email)
VALUES
  ('Jim D', 'HR', 100000, 'jim@example.com'),
  ('Anna K', 'Finance', 100000, 'anna@example.com'),
  ('Bruce L', 'Engineering', 100000, 'bruce@example.com'),
  ('Carrie F', 'Business', 100000, 'carrie@example.com');

La política de acceso de filas en la siguiente sentencia restringe las consultas a los miembros del dominio de la empresa. Además, el uso de la función SESSION_USER() restringe el acceso solo a las filas que pertenecen al usuario que ejecuta la consulta, según su dirección de correo electrónico.

CREATE ROW ACCESS POLICY
  salary_personal
ON
  dataset1.table1 GRANT TO ("domain:example.com")
  FILTER USING
  (Email=SESSION_USER());

En la siguiente imagen, se muestra cómo la política de acceso de fila restringe la tabla que contiene información sobre los salarios. En este ejemplo, el usuario se llama Jim y tiene la dirección de correo electrónico jim@example.com.

Caso de uso de seguridad a nivel de las filas para los salarios

Filtra los datos de las filas según la tabla de consulta

Para enviar comentarios o solicitar asistencia con esta función, envía un correo electrónico a bigquery-row-level-security-support@google.com.

Con la compatibilidad con subconsulta, las políticas de acceso de fila pueden hacer referencia a otras tablas y usarlas como tablas de consulta. Los datos que se usan en las reglas de filtrado se pueden almacenar en una tabla, y una sola política de acceso de fila de subconsulta puede reemplazar varias políticas de acceso de fila configuradas. Para actualizar las políticas de acceso de fila, solo necesitas actualizar la tabla de consulta, que reemplaza varias políticas de acceso de fila. No es necesario que actualices cada política de acceso de fila individual.

Cuándo usar la seguridad a nivel de las filas y otros métodos

Las vistas autorizadas, las políticas de acceso a nivel de las filas y el almacenamiento de datos en tablas separadas proporcionan diferentes niveles de seguridad, rendimiento y conveniencia. Elegir el mecanismo adecuado para tu caso de uso es importante a fin de garantizar el nivel adecuado de seguridad de tus datos.

Comparación con las vistas autorizadas: vulnerabilidades

La seguridad a nivel de las filas y la aplicación forzosa del acceso a nivel de las filas con una vista autorizada pueden tener vulnerabilidades si se usan de forma inadecuada.

Cuando usas las vistas autorizadas o las políticas de acceso a nivel de las filas para la seguridad a nivel de las filas, te recomendamos supervisar cualquier actividad sospechosa mediante el registro de auditoría.

Canales secundarios, como la duración de la consulta, pueden filtrar información sobre las filas que se encuentran en el perímetro de un fragmento de almacenamiento. Es probable que estos ataques requieran información sobre cómo la tabla está fragmentada o una gran cantidad de consultas.

Si quieres obtener más información para evitar esos ataques en el canal secundario, consulta Prácticas recomendadas para la seguridad a nivel de fila.

Comparación de las vistas autorizadas, la seguridad a nivel de las filas y las tablas separadas

En la siguiente tabla, se compara la flexibilidad, el rendimiento y la seguridad de las vistas autorizadas, las políticas de acceso a nivel de las filas y las tablas separadas.

Método Consideraciones de seguridad Recomendación
Vistas
autorizadas		 Recomendado para flexibilidad. Puede ser vulnerable a consultas hechas con cuidado, las duraciones de las consultas y otros tipos de ataques de canal lateral. Las vistas autorizadas son una buena opción cuando necesitas compartir datos con otras personas, y la flexibilidad y el rendimiento son importantes. Por ejemplo, puedes usar vistas autorizadas para compartir datos dentro de tu grupo de trabajo.
Políticas de acceso a nivel de las filas Se recomienda para lograr un equilibrio entre flexibilidad y seguridad. Puede ser vulnerable a ataques de canal lateral de duración de consultas. Las políticas de acceso a nivel de las filas son una buena opción cuando necesitas compartir datos con otras personas y deseas proporcionar seguridad adicional a las vistas o las porciones de tabla. Por ejemplo, puedes usar políticas de acceso a nivel de fila para compartir datos con personas que usan el mismo panel, incluso si algunas tienen acceso a más datos que otros.
Tablas separadas Se recomienda por seguridad. Los usuarios no pueden inferir datos sin acceso a la tabla. Las tablas separadas son una buena opción cuando necesitas compartir datos con otras personas y mantenerlos aislados. Por ejemplo, puedes usar tablas separadas para compartir datos con socios y proveedores externos, cuando la cantidad total de filas debe ser secreta.

Crea y administra políticas de acceso a nivel de fila

Para obtener información sobre cómo crear, actualizar (volver a crear), enumerar, ver y borrar políticas de acceso a nivel de fila en una tabla, y cómo consultar tablas con políticas de acceso a nivel de fila, consulta Trabaja con la seguridad de acceso a nivel de la fila.

Cuotas

Para obtener más información sobre las cuotas y los límites de seguridad a nivel de las filas, consulta Cuotas y límites de BigQuery.

Precios

La seguridad a nivel de las filas se incluye en BigQuery sin costo adicional. Sin embargo, una política de acceso a nivel de fila puede afectar el costo de la ejecución una consulta de las siguientes maneras:

  • La facturación adicional puede deberse a políticas de acceso a nivel de fila, en particular, políticas que incluyen subconsultas que hacen referencia a otras tablas.

  • Los filtros de políticas de acceso a nivel de las filas no participan en la reducción de consultas de las tablas particionadas y agrupadas. Esto no significa que lee más datos durante la ejecución de la consulta principal. No aprovecha los predicados de la política de acceso de fila para reducir aún más.

  • Con los filtros de políticas de acceso a nivel de las filas, no todos los filtros de usuario se aplican antes. Esto podría aumentar la lectura de datos de las tablas, y podría leer y facturar más filas.

Si deseas obtener más información sobre los precios de las consultas de BigQuery, consulta Precios de BigQuery.

Limitaciones

Para obtener información sobre los límites de seguridad a nivel de la fila, consulta Límites de seguridad a nivel de la fila de BigQuery. En las siguientes secciones, se documentan las limitaciones de seguridad adicionales a nivel de las filas.

Limitaciones de rendimiento

  • Algunas funciones de BigQuery no se aceleran cuando se trabaja con tablas que contienen políticas de acceso a nivel de fila, comoBigQuery BI Engine y vistas materializadas.

  • La seguridad a nivel de las filas no participa en la reducción de consultas, que es una función de las tablas particionadas. Para obtener más información, consulta Tablas particionadas y agrupadas en clústeres. Esta limitación no ralentiza la ejecución de la consulta principal.

  • Es posible que experimentes una pequeña degradación del rendimiento cuando consultes tablas con seguridad a nivel de fila.

Si quieres más información sobre cómo interactúa la seguridad a nivel de las filas con algunas funciones y servicios de BigQuery, consulta Usa la seguridad a nivel de las filas con otras funciones de BigQuery.

Otras limitaciones

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

  • Las políticas de acceso de fila no son compatibles con SQL heredado. Las consultas de tablas con políticas de acceso a nivel de las filas deben usar GoogleSQL. Las consultas de SQL heredado se rechazan con un error.

  • No puedes aplicar políticas de acceso a nivel de fila en las columnas JSON.

  • No puedes aplicar políticas de acceso a nivel de fila a tablas que hagan referencia a otras tablas que tengan seguridad a nivel de fila.

  • Algunas funciones de BigQuery no son compatibles con la seguridad a nivel de las filas. Para obtener más información, consulta Usa la seguridad a nivel de fila.

  • Las operaciones que no son de consulta, incluidos los trabajos de cuentas de servicio, que necesitan acceso completo a los datos de las tablas pueden usar la seguridad a nivel de fila con el filtro TRUE. En los ejemplos, se incluyen copia de tablas, flujos de trabajo de Dataproc y mucho más. Para obtener más información, consulta Usa la seguridad a nivel de fila.

  • La creación, el reemplazo o la eliminación de políticas de acceso a nivel de las filas deben realizarse con declaraciones DDL. Las listas y la visualización de las políticas de acceso a nivel de fila se pueden realizar a través de la consola de Google Cloud o la herramienta de línea de comandos de bq.

  • La vista previa o la navegación de tablas no es compatible con la seguridad a nivel de las filas.

  • El muestreo de tablas no es compatible con la seguridad a nivel de fila.

  • Los resultados de la política de subconsulta de nivel superior tienen un límite de 100 MB. Este límite se aplica por política de acceso a nivel de fila.

  • Si el predicado de la política de acceso a nivel de las filas no se puede evaluar debido a la eliminación de ninguna tabla a la que se hace referencia, la consulta falla.

  • Las políticas de acceso a nivel de las filas de las subconsultas solo admiten tablas de BigQuery, tablas externas de BigLake y tablas administradas de BigLake.

Registros y supervisión de auditoría

Cuando se leen los datos de una tabla con una o más políticas de acceso a nivel de las filas, las políticas de acceso a nivel de las filas autorizadas para el acceso de lectura y cualquier tabla correspondientes a las que se hace referencia en las subconsultas aparecen en la información de autorización de IAM. para esa solicitud de lectura.

La creación y la eliminación de las políticas de acceso a nivel de las filas se registran, y se puede acceder a ellas a través de Cloud Logging. Los registros de auditoría incluyen el nombre de la política de acceso a nivel de las filas. Sin embargo, las definiciones filter_expression y grantee_list de una política de acceso a nivel de las filas se omiten en los registros, ya que pueden contener información del usuario o cualquier otra información sensible. Las listas y la visualización de las políticas de acceso a nivel de las filas no se registran en la auditoría.

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?