Usar la seguridad a nivel de fila con otras funciones de BigQuery

En este documento se describe cómo usar la seguridad de acceso a nivel de fila con otras funciones de BigQuery.

Antes de leer este documento, familiarícese con la seguridad a nivel de fila leyendo los artículos Introducción a la seguridad a nivel de fila de BigQuery y Trabajar con la seguridad a nivel de fila.

El filtro TRUE

Las políticas de acceso a nivel de fila pueden filtrar los datos de los resultados que ves al ejecutar consultas. Para ejecutar operaciones que no sean consultas, como DML, necesitas acceso completo a todas las filas de la tabla. El acceso completo se concede mediante una política de acceso a filas con la expresión de filtro definida como TRUE. Esta política de acceso a nivel de fila se denomina filtro TRUE.

Se puede conceder acceso de TRUE a cualquier usuario, incluida una cuenta de servicio.

Estos son algunos ejemplos de operaciones que no son consultas:

• Otras APIs de BigQuery, como la API Storage Read de BigQuery.
• Algunos comandos de la bqherramienta de línea de comandos, como el comando bq head.
• Copiar una tabla

Ejemplo de filtro TRUE

CREATE ROW ACCESS POLICY all_access ON project.dataset.table1
GRANT TO ("group:all-rows-access@example.com")
FILTER USING (TRUE);

Funciones que funcionan con el filtro TRUE

Cuando usas una operación de DML en una tabla protegida por políticas de acceso a las filas, debes usar un filtro TRUE, lo que implica el acceso a toda la tabla. Las operaciones que no modifiquen el esquema de la tabla conservarán las políticas de acceso a filas de la tabla.

Por ejemplo, la instrucción ALTER TABLE RENAME TO copia las políticas de acceso a filas de la tabla original en la nueva. Otro ejemplo es la instrucción TRUNCATE TABLE que elimina todas las filas de una tabla, pero mantiene el esquema de la tabla y las políticas de acceso a filas.

Tareas de copia

Para copiar una tabla que tenga una o varias políticas de acceso a nivel de fila, primero debes tener TRUEacceso de filtroTRUE en la tabla de origen. Todas las políticas de acceso a nivel de fila de la tabla de origen también se copian en la nueva tabla de destino. Si copias una tabla de origen sin políticas de acceso a nivel de fila en una tabla de destino que sí las tiene, estas políticas se eliminarán de la tabla de destino, a menos que se use la marca --append_table o se defina "writeDisposition": "WRITE_APPEND".

Se permiten las copias entre regiones y se copian todas las políticas. Es posible que las consultas posteriores no funcionen después de completar la copia si contienen referencias de tabla no válidas en las políticas de subconsultas.

Las políticas de acceso a nivel de fila de una tabla deben tener nombres únicos. Si se produce un conflicto en los nombres de las políticas de acceso a nivel de fila durante la copia, se produce un error de entrada no válida.

Permisos necesarios para copiar una tabla con una política de acceso a nivel de fila

Para copiar una tabla con una o varias políticas de acceso a nivel de fila, debes tener los siguientes permisos, además de los roles para copiar tablas y particiones.

Tabledata.list en la API de BigQuery

Necesitas acceso de filtro TRUE para usar el método tabledata.list en la API de BigQuery en una tabla con políticas de acceso a nivel de fila.

DML

Para ejecutar una instrucción DML que actualice una tabla que tenga políticas de acceso a nivel de fila, necesitas TRUE acceso de filtro a la tabla.

En concreto, las instrucciones MERGE interactúan con las políticas de acceso a nivel de fila de la siguiente manera:

• Si una tabla de destino contiene políticas de acceso a nivel de fila, debes tener acceso de filtro TRUE a la tabla de destino.
• Si una tabla de origen contiene políticas de acceso a nivel de fila, la instrucción MERGE solo se aplica a las filas que son visibles para el usuario.

Capturas de tablas

Las capturas de tablas admiten la seguridad a nivel de fila. Los permisos que necesitas para la tabla base (tabla de origen) y la captura de tabla (tabla de destino) se describen en Permisos necesarios para copiar una tabla con una política de acceso a nivel de fila.

Tabla de BigQuery con columnas JSON

Las políticas de acceso a nivel de fila no se pueden aplicar a las columnas JSON. Para obtener más información sobre las limitaciones de la seguridad a nivel de las filas, consulta Limitaciones.

BigQuery BI Engine y Looker Studio

BigQuery BI Engine no acelera las consultas que se ejecutan en tablas con una o varias políticas de acceso a nivel de las filas. Estas consultas se ejecutan como consultas estándar en BigQuery.

Los datos de un panel de control de Looker Studio se filtran según las políticas de acceso a nivel de fila de la tabla de origen subyacente.

Seguridad a nivel de columna

La seguridad a nivel de fila y la seguridad a nivel de columna, que incluye tanto el control de acceso a nivel de columna como el enmascaramiento dinámico de datos, son totalmente compatibles.

Los puntos clave son los siguientes:

• Puede aplicar una política de acceso a nivel de fila para filtrar datos de cualquier columna, incluso si no tiene acceso a los datos de esa columna.
  • Si se intenta acceder a estas columnas con la política de acceso a nivel de fila de la subconsulta, se produce un error que indica que se ha denegado el acceso. Estas columnas no se consideran columnas referenciadas por el sistema.
  • Los intentos de acceder a estas columnas con la política de acceso a nivel de fila que no es de subconsulta eluden la seguridad a nivel de columna.
• Si la columna está restringida debido a la seguridad a nivel de columna y se menciona en la instrucción SELECT de la consulta o en las políticas de acceso a nivel de fila de la subconsulta, recibirás un error.
• La seguridad a nivel de columna también se aplica con una instrucción de consulta SELECT *. El SELECT * se trata igual que una consulta que nombra explícitamente una columna restringida.

Ejemplo de interacción entre la seguridad a nivel de fila y la seguridad a nivel de columna

En este ejemplo se muestran los pasos para proteger una tabla y, a continuación, consultarla.

Los datos

Supongamos que tienes el rol DataOwner en un conjunto de datos llamado my_dataset, que incluye una tabla con tres columnas llamada my_table. La tabla contiene los datos que se muestran en la siguiente tabla.

En este ejemplo, un usuario es Alicia, cuya dirección de correo es alice@example.com. El segundo usuario es Borja, compañero de Alicia.

La seguridad

Quieres que Alice pueda ver todas las filas que tengan números impares en la columna rank, pero no las que tengan números pares. No quieres que vea ninguna fila, ni las pares ni las impares. No quieres que nadie vea los datos de la columna fruit.

• Para evitar que Alice vea las filas con números pares, crea una política de acceso a nivel de fila que tenga una expresión de filtro basada en los datos que aparecen en la columna rank. Para evitar que Bob vea las filas pares o impares, no lo incluyas en la lista de beneficiarios.

  CREATE ROW ACCESS POLICY only_odd ON my_dataset.my_table GRANT
  TO ('user:alice@example.com') FILTER USING (MOD(rank, 2) = 1);
  

• Para impedir que todos los usuarios vean los datos de la columna llamada fruit, crea una etiqueta de política de seguridad a nivel de columna que prohíba a todos los usuarios acceder a cualquiera de sus datos.

Por último, también restringe el acceso a la columna color de dos formas: la columna se rige por una etiqueta de política de seguridad a nivel de columna que prohíbe el acceso a cualquier usuario y se ve afectada por una política de acceso a nivel de fila, que filtra algunos de los datos de las filas de la columna color.

• Esta segunda política de acceso a nivel de fila solo muestra las filas con el valor green en la columna color.

  CREATE ROW ACCESS POLICY only_green ON my_dataset.my_table
  GRANT TO ('user:alice@example.com') FILTER USING (color="green");
  

Consulta de Bob

Si Bob, compañero de trabajo de Alicia, intenta consultar datos de my_dataset.my_table, no verá ninguna fila, ya que no está en la lista de beneficiarios de ninguna política de acceso a nivel de fila de la tabla.

Consultas de Alicia

Cuando Alicia ejecuta consultas para acceder a los datos de my_dataset.my_table, los resultados dependen de la consulta que ejecute y de la seguridad, tal como se muestra en la siguiente tabla.

Acceso al filtro TRUE

Por último, tal como se explica en la sección sobre el acceso de TRUE a los filtros, si Alicia o Juan tienen acceso de TRUE a los filtros, podrán ver todas las filas de la tabla y usarlas en trabajos que no sean de consulta. Sin embargo, si la tabla tiene seguridad a nivel de columna, esta se sigue aplicando y puede afectar a los resultados.

Gráfico de ejecución

No puedes usar el gráfico de ejecución de consultas en trabajos con políticas de acceso a nivel de fila.

Tareas de extracción

Si una tabla tiene políticas de acceso a nivel de fila, solo se exportarán a Cloud Storage los datos que puedas ver cuando ejecutes un trabajo de extracción.

SQL antiguo

Las políticas de acceso a nivel de fila no son compatibles con el SQL antiguo. Las consultas en tablas con políticas de acceso a nivel de fila deben usar GoogleSQL. Se rechazan las consultas de SQL antiguo.

Tablas con particiones y agrupadas en clústeres

La seguridad a nivel de fila no participa en la poda de consultas, que es una función de las tablas particionadas.

Aunque la seguridad a nivel de fila es compatible con las tablas particionadas y en clúster, las políticas de acceso a nivel de fila que filtran los datos de las filas no se aplican durante la eliminación de particiones. Puedes seguir usando el recorte de particiones en una tabla que use seguridad a nivel de las filas especificando una cláusula WHERE que opere en la columna de partición. Del mismo modo, las políticas de acceso a nivel de fila no mejoran el rendimiento de las consultas en tablas agrupadas, pero no interfieren con otros filtros que apliques.

La poda de consultas se lleva a cabo durante la ejecución de las políticas de acceso a nivel de fila mediante los filtros de las políticas.

Cambiar el nombre de una tabla

No necesitas acceso de filtro TRUE para cambiar el nombre de una tabla que tenga una o varias políticas de acceso a filas. Puedes cambiar el nombre de una tabla con una declaración de DDL.

También puedes copiar una tabla y darle un nombre diferente a la tabla de destino. Si la tabla de origen tiene una política de acceso a nivel de fila, consulta la sección sobre tareas de copia de tablas de esta página para obtener más información.

Actualizaciones del flujo de actividades

Para realizar operaciones de UPDATE o DELETE en tablas de streaming con captura de datos de cambios, debes tener acceso de filtro TRUE.

Viaje en el tiempo

Solo un administrador de la tabla puede acceder al historial de datos de una tabla que tenga o haya tenido políticas de acceso a nivel de fila. Otros usuarios recibirán un error access denied si usan un decorador de viaje en el tiempo en una tabla que tenga acceso a nivel de fila. Para obtener más información, consulta Desplazamiento en el tiempo y acceso a nivel de fila.

Vistas lógicas, materializadas y autorizadas

En esta sección se describen los distintos tipos de vistas de BigQuery y cómo interactúan con la seguridad a nivel de fila.

Vistas lógicas o materializadas

Las vistas lógicas o materializadas se crean a partir de consultas en tablas. Los resultados de la consulta suelen ser un subconjunto de los datos de la tabla.

Los datos que se muestran en ambos tipos de vistas se filtran según las políticas de acceso a nivel de fila de la tabla de origen subyacente. Sin embargo, no puedes hacer referencia a vistas ni a vistas materializadas en políticas de acceso a nivel de fila.

Rendimiento de las vistas materializadas

Además, cuando una vista materializada se deriva de una tabla subyacente que tiene políticas de acceso a nivel de fila, el rendimiento de las consultas es el mismo que cuando se consulta la tabla de origen directamente. En otras palabras, si la tabla de origen tiene seguridad a nivel de fila, no verás las ventajas de rendimiento típicas de consultar una vista materializada en comparación con la consulta de la tabla de origen.

Vistas autorizadas

También puedes autorizar una vista lógica o materializada, lo que significa compartir la vista con usuarios o grupos (principales) específicos. Los principales pueden consultar una vista, pero no tienen acceso a la tabla subyacente. Para obtener más información, consulta Vistas autorizadas.

Consultas con comodines

Las consultas con comodines en tablas con políticas de acceso a nivel de fila fallan y devuelven un error INVALID_INPUT.

Siguientes pasos

• Para obtener información sobre las prácticas recomendadas para las políticas de acceso a nivel de fila, consulta Prácticas recomendadas para la seguridad a nivel de fila en BigQuery.