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

.

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

¿Qué es la seguridad a nivel de fila?

La seguridad a nivel de fila le permite filtrar datos y acceder a filas específicas de una tabla en función de las condiciones de usuario que se cumplan.

BigQuery admite controles de acceso a nivel de proyecto, conjunto de datos y tabla, así como seguridad a nivel de columna mediante etiquetas de política. La seguridad a nivel de fila amplía el principio de privilegio mínimo al permitir un control de acceso granular a un subconjunto de datos de una tabla de BigQuery mediante políticas de acceso a nivel de fila.

Una tabla puede tener varias políticas de acceso a nivel de fila. Las políticas de acceso a nivel de fila pueden coexistir en una tabla con la seguridad a nivel de columna, así como con los controles de acceso a nivel de conjunto de datos, a nivel de tabla y a nivel de proyecto.

Cómo funciona la seguridad a nivel de fila

A grandes rasgos, la seguridad a nivel de fila implica la creación de políticas de acceso a nivel de fila en una tabla de BigQuery de destino. Estas políticas actúan como filtros para ocultar o mostrar determinadas filas de datos, en función de si un usuario o un grupo están en una lista de permitidos. Se deniega el acceso a los usuarios o grupos que no se incluyan específicamente en la lista de permitidos.

Un usuario autorizado con los roles de gestión de identidades y accesos Administrador de BigQuery o Propietario de datos de BigQuery puede crear políticas de acceso a nivel de fila en una tabla de BigQuery.

Cuando creas una política de acceso a nivel de fila, especificas la tabla por su nombre y qué usuarios o grupos (denominados grantee-list) pueden acceder a determinados datos de las filas. La política también incluye los datos por los que quieres filtrar, denominados filter_expression. La función filter_expression funciona como una cláusula WHERE en una consulta típica.

Para obtener instrucciones sobre cómo crear y usar una política de acceso a nivel de fila, consulta el artículo Gestionar la seguridad a nivel de fila.

Consulta la referencia de DDL para ver la sintaxis, el uso y las opciones completas al crear políticas de acceso a nivel de fila.

Ejemplos de casos prácticos

En los siguientes ejemplos se muestran posibles casos prácticos de seguridad a nivel de fila.

Filtrar datos de filas por región

Supongamos que la tabla dataset1.table1 contiene filas que pertenecen a diferentes regiones (indicadas en la columna region).

Puede crear y rellenar 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 declaración implementa una política que restringe a los usuarios del grupo de correo de APAC para que solo vean a los partners 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 resultado es que los usuarios del grupo sales-apac@example.com solo pueden ver las filas en las que el valor de region es APAC.

La siguiente declaración implementa una política que restringe tanto a personas como a grupos para que solo vean a los partners 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 resultado es que los usuarios del grupo sales-us@example.com y el usuario jon@example.com solo pueden ver las 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 práctico de seguridad a nivel de fila para regiones.

Los usuarios que no pertenezcan a los grupos APAC o US no verán ninguna fila.

Filtrar datos de filas en función de datos sensibles

Ahora, vamos a ver otro caso práctico en el que tienes una tabla con información sobre salarios.

Puede crear y rellenar 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 a las filas de la siguiente instrucción 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, en función de 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 a las filas restringe la tabla que contiene información sobre los salarios. En este ejemplo, el usuario se llama Jim y su dirección de correo es jim@example.com.

Caso práctico de seguridad a nivel de fila para salarios

.

Filtrar datos de filas en función de una tabla de consulta

Gracias a la compatibilidad con subconsultas, las políticas de acceso a las filas 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 a filas de subconsulta puede sustituir a varias políticas de acceso a filas configuradas. Para actualizar las políticas de acceso a las filas, solo tiene que actualizar la tabla de consulta, que sustituye a varias políticas de acceso a las filas. No es necesario actualizar cada política de acceso a filas individualmente.

Cuándo usar la seguridad a nivel de fila en lugar de otros métodos

Las vistas autorizadas, las políticas de acceso a nivel de fila y el almacenamiento de datos en tablas independientes ofrecen diferentes niveles de seguridad, rendimiento y comodidad. Elegir el mecanismo adecuado para tu caso práctico es importante para asegurar el nivel de seguridad adecuado de tus datos.

Comparación con vistas autorizadas: vulnerabilidades

Tanto la seguridad a nivel de fila como la aplicación obligatoria del acceso a nivel de fila con una vista autorizada pueden tener vulnerabilidades si se usan de forma inadecuada.

Cuando uses vistas autorizadas o políticas de acceso a nivel de fila para proteger los datos a nivel de fila, te recomendamos que monitorices la actividad sospechosa mediante el registro de auditoría.

Los canales laterales, como la duración de la consulta, pueden filtrar información sobre las filas que se encuentran en el límite de un fragmento de almacenamiento. Para llevar a cabo estos ataques, probablemente se necesite información sobre cómo se fragmenta la tabla o un gran número de consultas.

Para obtener más información sobre cómo evitar este tipo de ataques de canal lateral, consulta el artículo Prácticas recomendadas para una seguridad a nivel de fila.

Comparación de vistas autorizadas, seguridad a nivel de fila y tablas independientes

En la siguiente tabla se comparan la flexibilidad, el rendimiento y la seguridad de las vistas autorizadas, las políticas de acceso a nivel de fila y las tablas independientes.

Método Consideraciones de seguridad Recomendación
Vistas
autorizadas
Se recomienda para disfrutar de flexibilidad. Puede ser vulnerable a consultas cuidadosamente diseñadas, duraciones de consultas y otros tipos de ataques de canal lateral. Las vistas autorizadas son una buena opción cuando necesitas compartir datos con otros usuarios y la flexibilidad y el rendimiento son importantes. Por ejemplo, puedes usar vistas autorizadas para compartir datos con tu grupo de trabajo.
Políticas de acceso a nivel de fila Se recomienda esta opción para lograr un equilibrio entre flexibilidad y seguridad. Puede ser vulnerable a ataques de canal lateral de duración de consulta. Las políticas de acceso a nivel de fila son una buena opción cuando necesitas compartir datos con otros usuarios y quieres proporcionar seguridad adicional a las vistas o a las porciones de tablas. Por ejemplo, puedes usar políticas de acceso a nivel de fila para compartir datos con personas que usen el mismo panel de control, aunque algunas tengan acceso a más datos que otras.
Tablas independientes Se recomienda por motivos de seguridad. Los usuarios no pueden inferir datos sin acceso a la tabla. Las tablas independientes son una buena opción cuando necesitas compartir datos con otros usuarios y mantenerlos aislados. Por ejemplo, puedes usar tablas independientes para compartir datos con partners y proveedores externos cuando el número total de filas deba ser secreto.

Crear y gestionar políticas de acceso a nivel de fila

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

Cuotas

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

Precios

La seguridad a nivel de fila se incluye en BigQuery sin coste adicional. Sin embargo, una política de acceso a nivel de fila puede afectar al coste de ejecutar una consulta de las siguientes formas:

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

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

  • Con los filtros de políticas de acceso a nivel de fila, no todos los filtros de usuario se aplican al principio. Esto puede aumentar la cantidad de datos leídos de las tablas y puede leer y facturar más filas.

Para obtener más información sobre los precios de las consultas de BigQuery, consulta la página Precios de BigQuery.

Limitaciones

Para obtener información sobre los límites de la seguridad a nivel de fila, consulta los límites de la seguridad a nivel de fila de BigQuery. En las siguientes secciones se documentan limitaciones adicionales de la seguridad 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, como BigQuery BI Engine y las vistas materializadas.

  • La seguridad a nivel de fila no participa en la poda de consultas, que es una función de las tablas particionadas. Para obtener más información, consulta el artículo sobre tablas con particiones y en clúster. Esta limitación no ralentiza la ejecución de la consulta principal.

  • Es posible que el rendimiento se vea ligeramente afectado al consultar tablas con seguridad a nivel de fila.

Para obtener más información sobre cómo interactúa la seguridad a nivel de fila con algunas funciones y servicios de BigQuery, consulta el artículo Usar la seguridad a nivel de fila con otras funciones de BigQuery.

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

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

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

  • No se admiten las consultas de tablas con comodines en tablas que tengan políticas de acceso a las filas.

  • Las políticas de acceso a filas no se pueden aplicar a tablas temporales.

  • No puede 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 fila. Para obtener más información, consulta Usar la seguridad a nivel de las filas.

  • Las operaciones que no son consultas, incluidas las tareas de cuentas de servicio, que necesiten acceso completo a los datos de la tabla pueden usar la seguridad a nivel de fila con el filtro TRUE. Por ejemplo, se pueden copiar tablas, flujos de trabajo de Dataproc y más. Para obtener más información, consulta Usar la seguridad a nivel de las filas.

  • Puedes crear, sustituir o eliminar políticas de acceso a nivel de fila con instrucciones DDL o APIs de políticas de acceso a filas. También puedes realizar todas las acciones disponibles en las APIs de políticas de acceso a las filas con la herramienta de línea de comandos bq. Puede enumerar y ver las políticas de acceso a nivel de fila en laGoogle Cloud consola.

  • La vista previa o la navegación por las tablas no son compatibles con la seguridad a nivel de fila.

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

  • Los resultados de las políticas de las subconsultas de nivel superior están limitados a 100 MB. Este límite se aplica a cada política de acceso a nivel de fila.

  • Las INsubconsultas de nivel superior en las que el tipo de search_value es FLOAT, STRUCT, ARRAY, JSON o GEOGRAPHY no están disponibles en las políticas de acceso a las filas.

  • Si no se puede evaluar el predicado de la política de acceso a nivel de fila debido a la eliminación de alguna tabla de referencia, la consulta falla.

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

  • No se permiten las instrucciones de cambio de nombre y eliminación de columnas que modifiquen el esquema de la tabla y puedan afectar a las políticas de acceso a las filas.

Registro y monitorización de auditoría

Cuando se leen datos de una tabla con una o varias políticas de acceso a nivel de fila, las políticas de acceso a nivel de fila autorizadas para el acceso de lectura y las tablas correspondientes a las que se haga referencia en las subconsultas aparecen en la información de autorización de IAM de esa solicitud de lectura.

La creación y la eliminación de políticas de acceso a nivel de fila se registran en los registros de auditoría 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 fila. Sin embargo, las definiciones de filter_expression y grantee_list de una política de acceso a nivel de fila se omiten de los registros, ya que pueden contener información sensible de usuarios u otra información sensible. No se registran en auditoría las acciones de enumeración y visualización de políticas de acceso a nivel de fila.

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