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 commandebq 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.
DML
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 avec la règle d'accès au niveau des lignes de la sous-requête entraînent 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 une règle d'accès au niveau des lignes qui ne sont pas des sous-requêtes 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 qu'elle est nommée dans l'instruction
SELECT
de la requête 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êteSELECT *
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 | couleur |
---|---|---|
1 | apple | rouge |
2 | orange | orange |
3 | citron | jaune |
4 | citron vert | vert |
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 colonnecolor
.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
|
Commentaires | ||
---|---|---|---|---|
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
|
Commentaires | ||
---|---|---|---|---|
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 ) |
||
|
(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. |
||
|
|
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é. |
||
|
|
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é. |
||
|
|
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é. |
||
|
|
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é. |
||
|
|
|
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é. |
|
|
|
|
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 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 des règles d'accès au niveau des lignes à l'aide des filtres avec les 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 ni 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.