Usa la seguridad a nivel de las filas 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ízate con la seguridad a nivel de las filas mediante la lectura de la Introducción a la seguridad a nivel de las filas de BigQuery y de Trabaja con seguridad a nivel de las filas.

El filtro `TRUE`

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

Se puede otorgar el acceso de filtro TRUE a cualquier usuario, incluida una cuenta de servicio.

Estos son algunos ejemplos de operaciones que no son de consulta:

Otras API de BigQuery, como la API de BigQuery Storage Read
Algunos comandos de la herramienta de línea de comandos de bq, como el comando bq head.
Copia una tabla

Ejemplo

Crea el 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`

Trabajos de copia

Para copiar una tabla con una o más políticas de acceso a nivel de fila, primero debes tener acceso de filtro TRUE en la tabla de origen. Todas las políticas de acceso a nivel de las filas en la tabla de origen también se copian en la tabla de destino nueva. Si copias una tabla de origen sin políticas de acceso a nivel de fila en una tabla de destino que tiene políticas de acceso a nivel de fila, las políticas de acceso a nivel de fila se quitan de la tabla de destino, a menos que se use la marca --append_table o que se establezca "writeDisposition": "WRITE_APPEND".

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

Las políticas de acceso a nivel de las filas en una tabla deben tener nombres únicos. Una colisión en los nombres de políticas de acceso a nivel de las filas durante la copia da como resultado un error de entrada no válido.

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

Para copiar una tabla con una o más políticas de acceso a nivel de las filas, debes tener los siguientes permisos, además de los permisos necesarios para copiar una tabla sin una política de acceso a nivel de las filas.

Permiso	Recurso
`bigquery.rowAccessPolicies.list`	La tabla de origen.
`bigquery.rowAccessPolicies.getIamPolicy`	La tabla de origen.
El filtro `TRUE`	La tabla de origen.
`bigquery.rowAccessPolicies.create`	La tabla de destino.
`bigquery.rowAccessPolicies.setIamPolicy`	La tabla de destino.

Tabledata.list en la API de BigQuery

Necesitas el 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 declaración DML que actualiza una tabla que tiene políticas de acceso a nivel de fila, necesitas acceso de filtro TRUE en la tabla.

En particular, las declaraciones 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, necesitas TRUE para filtrar el acceso a la tabla de destino.
Si una tabla de origen contiene políticas de acceso a nivel de fila, la declaración MERGE solo actúa en las filas que son visibles para el usuario.

Instantáneas de tablas

Las instantáneas de tabla son compatibles con la seguridad a nivel de las filas. Los permisos que necesitas para la tabla base (tabla fuente) y la instantánea de tabla (tabla de destino) se describen en Permisos necesarios para copiar una tabla con una política de acceso a nivel de fila.

Las funciones retroactivas no son compatibles con las tablas base que tienen una o más políticas de seguridad a nivel de las filas.

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 fila, consulta Limitaciones.

BigQuery BI Engine y Looker Studio

BigQuery BI Engine no acelera las consultas que se ejecutan en tablas con una o más políticas de acceso a nivel de fila. Esas consultas se ejecutan como consultas estándar en BigQuery.

Los datos en un panel de Looker Studio se filtran de acuerdo con las políticas de acceso a nivel de las filas de la tabla de origen subyacente.

Seguridad a nivel de la columna

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

Los puntos clave son los siguientes:

Puedes aplicar una política de acceso a nivel de fila para filtrar datos en cualquier columna, incluso si no tienes acceso a los datos en esa columna.
- Los intentos de acceder a estas columnas con la política de acceso a nivel de las filas de la subconsulta da como resultado un error que indica que se denegó el acceso. Estas columnas no se consideran columnas a las que se hace referencia por el sistema.
- Los intentos de acceder a estas columnas con la política de acceso a nivel de las filas que no es de subconsulta omiten la seguridad a nivel de columna.
Si la columna está restringida debido a la seguridad a nivel de las columnas y se le asigna un nombre en la declaración SELECT o en las políticas de acceso de la subconsulta a nivel de las filas, recibirás un error.
La seguridad a nivel de columna también se aplica con una declaración de consulta SELECT *. SELECT * se trata del mismo modo que una consulta que asigna un nombre de forma explícita a una columna restringida.

Ejemplo de interacción entre seguridad a nivel de las filas y de las columnas

En este ejemplo, se explican los pasos para proteger una tabla y, luego, realizar consultas.

Los datos

Supongamos que tienes la función DataOwner para un conjunto de datos llamado my_dataset, que incluye una tabla con tres columnas, denominada my_table. La tabla contiene los datos que se muestran en la siguiente tabla.

En este ejemplo, un usuario es Alice, cuya dirección de correo electrónico es alice@example.com. Un segundo usuario es Bob, el colega de Alice.

rank	frutas	color
1	apple	rojo
2	orange	orange
3	limón	amarillo
4	verde lima	verde

La seguridad

Deseas que Alicia pueda ver todas las filas que tienen números impares en la columna rank, pero no las filas con números pares. No quieres que Bob vea ninguna fila, ni par ni impar. No quieres que nadie vea datos en la columna fruit.

Para evitar que Alice vea las filas con número par, crea una política de acceso a nivel de las filas que tenga una expresión de filtro basada en los datos que aparecen en la columna rank. Para evitar que Pedro vea 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 restringir el acceso de todos los usuarios en la columna fruit, debes crear una etiqueta de política de seguridad a nivel de las columnas que prohíba a todos los usuarios acceder a sus datos.

Por último, también debes restringir el acceso a la columna llamada color de dos maneras: la columna está regida por una etiqueta de política de seguridad a nivel de las columnas que prohíbe todo tipo de acceso por parte de cualquier persona, y se ve afectada por una política de acceso a nivel de las filas que filtra algunos de los datos de fila en la columna color.

Esta segunda política de acceso a nivel de fila solo muestra 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 su compañero de trabajo Bob intenta consultar datos de my_dataset.my_table, no ve ninguna fila, porque no se encuentra en la lista de beneficiarios de ninguna política de acceso a nivel de las filas en la tabla.

Consulta	`my_dataset.my_table`			Comentarios
	`rank` (Algunos datos se ven afectados por la política de acceso de fila `only_odd`)	`fruit` (Todos los datos están protegidos con una etiqueta de política de CLS)	`color` (Todos los datos están protegidos por una etiqueta de política de CLS y algunos datos se ven afectados por la política de acceso de fila `only_green`)
`SELECT rank FROM my_dataset.my_table`	(0) Filas mostradas.			Bob no está en la lista de beneficiarios de la política de acceso a nivel de las filas; por lo tanto, esta consulta se realiza de forma correcta, pero no se muestran los datos de las filas. Se muestra un mensaje a Bob que indica que sus resultados pueden filtrarse por la política de acceso de fila.

Consultas de Alice

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

Consulta	`my_dataset.my_table`			Comentarios
	`rank` (Algunos datos se ven afectados por la política de acceso de fila `only_odd`)	`fruit` (Todos los datos están protegidos con una etiqueta de política de CLS)	`color` (Todos los datos están protegidos por una etiqueta de política de CLS y algunos datos se ven afectados por la política de acceso de fila `only_green`)
`SELECT rank FROM my_dataset.my_table`	(2) Se muestran las filas de número impar.			Alice está en la lista de beneficiarios de la política de acceso a nivel de fila `only_odd` sobre los datos en la columna de clasificación. Por lo tanto, Alice solo ve los datos de las filas con número impar. Las filas con número par están ocultas por la política de acceso a nivel de fila llamada `only_odd`. Se muestra un mensaje a Alice que indica que sus resultados se pueden filtrar por la política de acceso de fila.
`SELECT fruit FROM my_dataset.my_table`		`access denied`		La columna `fruit` recibió un nombre explícito en la consulta. Se aplica la seguridad a nivel de la columna. El acceso está denegado.
`SELECT color FROM my_dataset.my_table`			`access denied`	La columna `color` recibió un nombre explícito en la consulta. La seguridad a nivel de la columna se aplica antes de que se active la política de acceso a nivel de las filas en los datos de la columna `color`. El acceso está denegado.
`SELECT rank, fruit FROM my_dataset.my_table`		`access denied`		A la columna “`fruit`” se le asignó un nombre de forma explícita en la consulta. La seguridad a nivel de la columna se aplica antes de que se active la política de acceso a nivel de las filas en los datos de la columna `rank`. El acceso está denegado.
`SELECT rank, color FROM my_dataset.my_table`			`access denied`	La columna `color` recibió un nombre explícito en la consulta Se aplica la seguridad a nivel de las columnas a la columna `color` antes de que se activen las políticas de acceso a nivel de las filas en los datos de `rank` y las columnas `color`. El acceso está denegado.
`SELECT fruit, color FROM my_dataset.my_table`		`access denied`	`access denied`	A las columnas `fruit` y `color` se les asigna un nombre de forma explícita en la consulta. Se aplica la seguridad a nivel de la columna en las columnas `fruit` y `color` antes de que se active la política de acceso a nivel de las filas en los datos en la columna `color`. El acceso está denegado.
`SELECT * FROM my_dataset.my_table`		`access denied`	`access denied`	A las columnas `fruit` y `color` se les asinga implícitamente un nombre mediante el uso de “`SELECT *`” en la consulta. Se aplica la seguridad a nivel de las columnas en las columnas `fruit` y `color`, antes de que se activen las políticas de acceso a nivel de las filas en los datos en las columnas `rank` o `color`. El acceso está denegado.

Acceso al filtro `TRUE`

Por último, como se explica en la sección sobre el acceso al filtro TRUE, si Alice o Bob tiene acceso de filtro TRUE, pueden ver todo el contenido de las filas en la tabla y usarla en trabajos que no sean de consulta. Sin embargo, si la tabla tiene seguridad a nivel de columnas, se aplica y puede afectar los resultados.

Extrae trabajos

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

SQL heredado

Las políticas de acceso a nivel de las filas 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.

Tablas particionadas y agrupadas en clústeres

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

Si bien la seguridad a nivel de fila es compatible con tablas particionadas y agrupadas en clústeres, las políticas de acceso a nivel de fila que filtran los datos de la fila no se aplican durante la reducción de la partición. Aún puedes usar la reducción de la partición en una tabla que usa seguridad a nivel de fila. Para hacerlo, especifica 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 crean ningún beneficio de rendimiento para las consultas en tablas agrupadas en clústeres, pero no interfieren en otros filtros que apliques.

La reducción de las consultas se realiza durante la ejecución de las políticas de acceso a nivel de las filas a través de los filtros con las políticas.

Cambia el nombre de una tabla

No necesitas acceso de filtro TRUE para cambiar el nombre de una tabla que contiene una o más políticas de acceso de fila. Puedes cambiar el nombre de una tabla con una declaración de DDL.

Como alternativa, también puedes copiar una tabla y asignarle un nombre diferente. Si la tabla de origen tiene una política de acceso a nivel de las filas, consulta los trabajos de copia de tablas en esta página para obtener más información.

Actualizaciones de transmisión

Para realizar operaciones UPDATE o DELETE de tabla de transmisión con la captura de datos modificados, debes tener acceso de filtro TRUE.

Viaje en el tiempo

Solo un administrador de tabla puede acceder a los datos históricos de una tabla que tiene o tuvo políticas de acceso a nivel de fila antes. Otros usuarios reciben un error access denied si usan un decorador de viajes temporales en una tabla que tuvo acceso a nivel de fila. Para obtener más información, consulta Viaje en el tiempo y acceso a nivel de fila.

Vistas y vistas materializadas

Los datos que se muestran en una vista o en una vista materializada se filtran según las políticas de acceso a nivel de las filas de la tabla de origen subyacente.

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

No puedes hacer referencia a vistas o vistas materializadas en las políticas de acceso a nivel de las filas.

Consultas comodín

Las consultas comodín en tablas con políticas de acceso a nivel de las filas fallan con un error INVALID_INPUT.

¿Qué sigue?

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