Utiliser la sécurité au niveau des lignes avec d'autres fonctionnalités BigQuery

Ce document explique comment utiliser la sécurité et les accès au niveau des lignes avec d'autres fonctionnalités BigQuery.

Avant de lire ce document, familiarisez-vous avec la sécurité au niveau des lignes en consultant la page Présentation de la sécurité au niveau des lignes de BigQuery et Utiliser la sécurité au niveau des lignes.

Le filtre `TRUE`

Les règles d'accès au niveau des lignes peuvent filtrer les données de résultat que vous obtenez lors de l'exécution de requêtes. Pour exécuter des opérations non liées aux requêtes, telles que les instructions LMD, vous avez besoin d'un accès complet à toutes les lignes de la table. L'accès complet est accordé à l'aide d'une règle d'accès aux lignes avec l'expression de filtre définie sur TRUE. Cette règle d'accès au niveau des lignes est appelée filtre TRUE.

Tout utilisateur peut disposer du filtre TRUE, y compris d'un compte de service.

Exemples d'opérations non liées aux requêtes :

D'autres API BigQuery, telles que l'API BigQuery Storage Read.
Certaines commandes de l'outil de ligne de commande bq, telles que la commande bq head.
Copier une table

Exemple

Créer le filtre `TRUE`

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

Fonctionnalités compatibles avec le filtre `TRUE`

Tâches de copie

Pour copier une table avec une ou plusieurs règles d'accès au niveau des lignes, vous devez d'abord disposer d'un accès par filtre TRUE sur la table source. Toutes les règles d'accès au niveau des lignes de la table source sont également copiées dans la nouvelle table de destination. Si vous copiez une table source sans règles d'accès au niveau des lignes dans une table de destination qui dispose de règles d'accès au niveau des lignes, les règles d'accès au niveau des lignes sont supprimées de la table de destination, à moins d'utiliser l'option --append_table ou d'avoir défini "writeDisposition": "WRITE_APPEND".

Les copies interrégionales sont autorisées et toutes les règles sont copiées. Les requêtes suivantes peuvent être interrompues une fois la copie terminée si elles contiennent des références de table non valides dans les règles de sous-requêtes.

Les règles d'accès au niveau des lignes d'une table doivent porter des noms uniques. Un conflit entre les noms des règles d'accès au niveau des lignes lors de la copie entraîne une erreur de saisie non valide.

Autorisations requises pour copier une table avec une règle d'accès au niveau des lignes

Pour copier une table avec une ou plusieurs règles d'accès au niveau des lignes, vous devez disposer des autorisations suivantes, en plus des autorisations requises pour copier une table sans règle d'accès au niveau de la ligne.

Autorisation	Ressource
`bigquery.rowAccessPolicies.list`	La table source.
`bigquery.rowAccessPolicies.getIamPolicy`	La table source.
Le filtre `TRUE`	La table source.
`bigquery.rowAccessPolicies.create`	La table de destination.
`bigquery.rowAccessPolicies.setIamPolicy`	La table de destination.

Tabledata.list dans l'API BigQuery

Vous avez besoin d'un accès avec le filtre TRUE pour utiliser la méthode tabledata.list de l'API BigQuery sur une table dotée de règles d'accès au niveau des lignes.

LMD

Pour exécuter une instruction LMD qui met à jour une table disposant de règles d'accès au niveau des lignes, vous devez disposer d'un accès avec le filtre TRUE pour la table.

Plus précisément, les instructions MERGE interagissent avec les règles d'accès au niveau des lignes comme suit :

Si une table cible contient des règles d'accès au niveau des lignes, vous devez disposer d'un filtre TRUE pour accéder à la table cible.
Si une table source contient des règles d'accès au niveau des lignes, l'instruction MERGE n'agit que sur les lignes visibles par l'utilisateur.

Instantanés de table

Les instantanés de table sont compatibles avec la sécurité au niveau des lignes. Les autorisations dont vous avez besoin pour la table de base (table source) et l'instantané de la table (table de destination) sont décrites dans la section Autorisations requises pour copier une table avec une règle d'accès au niveau de la ligne.

Les fonctionnalités temporelles ne sont pas compatibles avec les tables de base qui ont une ou plusieurs règles de sécurité au niveau des lignes.

Table BigQuery avec colonnes JSON

Les règles d'accès au niveau des lignes ne peuvent pas être appliquées aux colonnes JSON. Pour en savoir plus sur les limites de la sécurité au niveau des lignes, consultez la section Limites.

BigQuery BI Engine et Looker Studio

BigQuery BI Engine n'accélère pas les requêtes exécutées sur les tables avec une ou plusieurs règles d'accès au niveau des lignes. Ces requêtes sont exécutées en tant que requêtes standards dans BigQuery.

Les données d'un tableau de bord Looker Studio sont filtrées en fonction des règles d'accès au niveau des lignes de la table source.

Sécurité au niveau des colonnes

La sécurité au niveau des lignes et au niveau des colonnes, qui inclut à la fois le contrôle des accès au niveau des colonnes et le masquage des données dynamiques, sont entièrement compatibles.

Les points essentiels sont les suivants :

Vous pouvez appliquer une règle d'accès au niveau des lignes pour filtrer les données de n'importe quelle colonne, même si vous n'avez pas accès aux données de cette colonne.
- Les tentatives d'accès à ces colonnes à l'aide de la règle d'accès au niveau des lignes de la sous-requête génèrent une erreur indiquant que l'accès est refusé. Ces colonnes ne sont pas considérées comme des colonnes référencées par le système.
- Les tentatives d'accès à ces colonnes avec la règle d'accès non liée aux sous-requêtes au niveau des lignes contournent la sécurité au niveau des colonnes.
Si la colonne est limitée en raison d'une sécurité au niveau des colonnes et que celle-ci est nommée dans l'instruction SELECT ou dans les règles d'accès au niveau des lignes de la sous-requête, vous recevez une erreur.
La sécurité au niveau des colonnes s'applique également aux instructions de requête SELECT *. La requête SELECT * est traitée de la même manière qu'une requête nommant explicitement une colonne restreinte.

Exemple d'interaction entre la sécurité au niveau des lignes et la sécurité au niveau des colonnes

Cet exemple décrit les étapes à suivre pour sécuriser une table, puis l'interroger.

Les données

Supposons que vous disposiez du rôle DataOwner pour un ensemble de données nommé my_dataset, qui inclut une table comportant trois colonnes, nommée my_table. La table contient les données présentées dans la table suivante.

Dans cet exemple, un utilisateur se nommeAlice, dont l'adresse e-mail est alice@example.com. Le deuxième utilisateur se nomme Bob, le collègue d'Alice.

rank	Fruit	color
1	pomme	rouge
2	orange	orange
3	citron	jaune
4	citron vert	green

La sécurité

Vous souhaitez qu'Alice affiche toutes les lignes impaires dans la colonne rank, mais pas des lignes paires. Vous ne souhaitez pas que Bob voie ces lignes, paires ou impaires. Vous ne voulez pas qu'un utilisateur soit en mesure de consulter les données de la colonne fruit.

Pour empêcher Alice de voir les lignes paires, vous devez créer une règle d'accès au niveau des lignes, qui comporte une expression de filtre basée sur les données de la colonne rank. Pour empêcher Bob de voir des lignes paires ou impaires, vous ne devez pas l'inclure pas dans la liste des bénéficiaires.
```
CREATE ROW ACCESS POLICY only_odd ON my_dataset.my_table GRANT
TO ('user:alice@example.com') FILTER USING (MOD(rank, 2) = 1);
```
Pour empêcher tous les utilisateurs d'accéder aux données de la colonne fruit, créez un tag avec stratégie de sécurité au niveau de la colonne qui interdit à tous les utilisateurs d'accéder à ses données.

Enfin, vous limitez également l'accès à la colonne color de deux manières : la colonne est régie par un tag avec stratégie de sécurité au niveau de la colonne qui interdit tout accès, et qui est affectée par une règle d'accès au niveau des lignes, filtrant ainsi certaines des données de ligne dans la colonne color.

Cette deuxième règle d'accès au niveau des lignes n'affiche que les lignes dont la valeur est green dans la colonne color.

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

Requête de Bob

Si le collègue d'Alice, Bob, tente d'interroger les données de my_dataset.my_table, aucune ligne ne s'affiche, car Bob ne figure pas dans la liste des bénéficiaires de toute règle d'accès au niveau de la table.

Query	`my_dataset.my_table`			Comments
	`rank` (Certaines données sont concernées par la règle d'accès aux lignes `only_odd`)	`fruit` (Toutes les données sont sécurisées par un tag avec stratégie CLS)	`color` (Toutes les données sont sécurisées par un tag avec stratégie CLS et certaines données sont concernées par la règle d'accès aux lignes `only_green`)
`SELECT rank FROM my_dataset.my_table`	(0) lignes renvoyées.			Bob n'est pas membre de la liste des bénéficiaires de la règle d'accès au niveau des lignes. Par conséquent, cette requête aboutit, mais aucune donnée de ligne n'est renvoyée. Un message est envoyé à Bob, indiquant que ses résultats peuvent être filtrés par la règle d'accès aux lignes.

Requêtes d'Alice

Lorsqu'Alice exécute des requêtes pour accéder aux données de my_dataset.my_table, ses résultats dépendent de la requête qu'elle exécute et de la sécurité, comme indiqué dans la table suivante.

Query	`my_dataset.my_table`			Comments
	`rank` (Certaines données sont concernées par la règle d'accès aux lignes `only_odd`)	`fruit` (Toutes les données sont sécurisées par un tag avec stratégie CLS)	`color` (Toutes les données sont sécurisées par un tag avec stratégie CLS et certaines données sont concernées par la règle d'accès aux lignes `only_green`)
`SELECT rank FROM my_dataset.my_table`	(2) lignes impaires sont renvoyées.			Alice est membre de la liste des bénéficiaires de la règle d'accès au niveau de la ligne `only_odd` concernant les données de la colonne "rank". Par conséquent, Alice ne voit que les données de lignes impaires. Les lignes paires sont masquées par la règle d'accès au niveau des lignes nommée `only_odd`. Un message s'affiche pour Alice, indiquant que ses résultats peuvent être filtrés par la règle d'accès aux lignes.
`SELECT fruit FROM my_dataset.my_table`		`access denied`		La colonne `fruit` a été explicitement nommée dans la requête. La sécurité au niveau des colonnes s'applique. L'accès est refusé.
`SELECT color FROM my_dataset.my_table`			`access denied`	La colonne `color` a été explicitement nommée dans la requête. La sécurité au niveau des colonnes s'applique avant que la règle d'accès au niveau des lignes des données de la colonne `color` ne soit engagée. L'accès est refusé.
`SELECT rank, fruit FROM my_dataset.my_table`		`access denied`		La colonne ``fruit`` a été explicitement nommée dans la requête. La sécurité au niveau des colonnes s'applique avant que la règle d'accès au niveau des lignes des données de la colonne `rank` ne soit engagée. L'accès est refusé.
`SELECT rank, color FROM my_dataset.my_table`			`access denied`	La colonne `color` a été explicitement nommée dans la requête . La sécurité au niveau des colonnes de la colonne `color` s'applique avant que les règles d'accès au niveau des lignes des données des colonnes `rank` et `color` ne soient engagées. L'accès est refusé.
`SELECT fruit, color FROM my_dataset.my_table`		`access denied`	`access denied`	Les colonnes `fruit` et `color` ont été explicitement nommées dans la requête. La sécurité au niveau des colonnes des colonnes `fruit` et `color` s'applique, avant que la règle d'accès au niveau des lignes des données de la colonne `color` ne soit engagée. L'accès est refusé.
`SELECT * FROM my_dataset.my_table`		`access denied`	`access denied`	Les colonnes `fruit` et `color` ont été nommées implicitement en utilisant "`SELECT *`" dans la requête. La sécurité au niveau des colonnes des colonnes `fruit` et `color` s'applique avant que les règles d'accès au niveau des lignes des données des colonnes `rank` ou `color` ne soient engagées. L'accès est refusé.

Accès au filtre `TRUE`

Enfin, comme expliqué dans la section à propos du filtre TRUE, si Alice ou Bob dispose d'un accès au filtre TRUE, ils peuvent voir toutes les lignes de la table et les utiliser dans des tâches non liées aux requêtes. Toutefois, si la table dispose d'une sécurité au niveau des colonnes, elle s'applique toujours et peut affecter les résultats.

Tâches d'extraction

Si une table dispose de règles d'accès au niveau des lignes, seules les données que vous pouvez afficher sont exportées vers Cloud Storage lorsque vous exécutez une tâche d'extraction.

Ancien SQL

Les règles d'accès au niveau des lignes ne sont pas compatibles avec l'ancien SQL. Les requêtes sur les tables avec des règles d'accès au niveau des lignes doivent utiliser le langage GoogleSQL. Les requêtes en ancien SQL sont refusées.

Tables partitionnées et en cluster

La sécurité au niveau des lignes ne participe pas à l'élimination des requêtes, qui constitue une fonctionnalité des tables partitionnées.

Bien que la sécurité au niveau des lignes soit compatible avec les tables partitionnées et en cluster, les règles d'accès au niveau des lignes qui filtrent les données des lignes ne sont pas appliquées lors de l'élimination des partitions. Vous pouvez toujours éliminer des partitions dans une table qui utilise la sécurité au niveau des lignes en spécifiant une clause WHERE qui agit sur la colonne de partition. De même, les règles d'accès au niveau des lignes ne créent aucun avantage en termes de performances pour les requêtes sur les tables en cluster, mais elles n'interfèrent pas avec les autres filtres que vous appliquez.

L'élimination des requêtes est effectuée lors de l'exécution de règles d'accès au niveau des lignes à l'aide des filtres associés aux règles.

Renommer une table

Vous n'avez pas besoin d'accéder au filtre TRUE pour renommer une table avec une ou plusieurs règles d'accès aux lignes. Vous pouvez renommer une table avec une instruction LDD.

Vous pouvez également copier une table et lui attribuer un nom différent. Si la table source est associée à une règle d'accès au niveau des lignes, consultez la section Tâches de copie de table de cette page pour plus d'informations.

Mises à jour en continu

Pour effectuer des opérations UPDATE ou DELETE de table de flux avec la capture des données modifiées, vous devez disposer d'un accès avec le filtre TRUE.

Fonctionnalité temporelle

Seul un administrateur de table peut accéder aux données de l'historique d'une table qui dispose ou a déjà eu des règles d'accès au niveau des lignes. Les autres utilisateurs obtiennent une erreur access denied s'ils utilisent un décorateur de fonctionnalité temporelle sur une table qui a eu un accès au niveau des lignes. Pour en savoir plus, consultez la section Fonctionnalité temporelle et accès au niveau des lignes.

Vues et vues matérialisées

Les données affichées dans une vue ou dans une vue matérialisée sont filtrées en fonction des règles d'accès au niveau des lignes de la table source sous-jacente.

En outre, lorsqu'une vue matérialisée est dérivée d'une table sous-jacente dotée de règles d'accès au niveau des lignes, les performances des requêtes sont identiques à celles obtenues lorsque vous interrogez la source. directement. Entre autres, si la table source présente une sécurité au niveau des lignes, vous ne verrez pas les avantages en termes de performances consistant à interroger une vue matérialisée par rapport à l'interrogation de la table source.

Vous ne pouvez pas référencer de vues ou de vues matérialisées dans des règles d'accès au niveau des lignes.

Requêtes génériques

Les requêtes génériques sur les tables contenant des règles d'accès au niveau des lignes échouent et renvoient une erreur INVALID_INPUT.

Étape suivante

Pour en savoir plus sur les bonnes pratiques concernant les règles d'accès au niveau des lignes, consultez la page Bonnes pratiques en matière de sécurité au niveau des lignes dans BigQuery.