Présentation du masquage des données
BigQuery est compatible avec le masquage des données au niveau des colonnes. Vous pouvez utiliser le masquage de données pour masquer de manière sélective les données de colonne de groupes d'utilisateurs, tout en autorisant l'accès à la colonne. La fonctionnalité de masquage des données est basée sur le contrôle des accès au niveau des colonnes. Vous devez donc vous familiariser avec cette fonctionnalité avant de continuer.
Lorsque vous utilisez le masquage de données avec le contrôle d'accès au niveau des colonnes, vous pouvez configurer un ensemble d'accès aux données de colonne, de l'accès complet à l'absence d'accès, en fonction des besoins de différents groupes d'utilisateurs. Par exemple, pour les données d'identification fiscale, vous pouvez souhaiter accorder un accès complet à votre groupe de comptabilité, un accès masqué à votre groupe d'analystes et aucun accès à votre groupe de vente.
Avantages
Le masquage des données offre les avantages suivants :
- Il simplifie le processus de partage des données. Vous pouvez masquer les colonnes sensibles pour permettre le partage de tables avec des groupes plus importants.
- Contrairement au contrôle des accès au niveau des colonnes, vous n'avez pas besoin de modifier les requêtes existantes en excluant les colonnes auxquelles l'utilisateur n'a pas accès. Lorsque vous configurez le masquage de données, les requêtes existantes masquent automatiquement les données de colonne en fonction des rôles attribués à l'utilisateur.
- Vous pouvez appliquer des règles d'accès aux données à grande échelle. Vous pouvez rédiger une stratégie de données, l'associer à un tag avec stratégie et appliquer ce tag à un nombre quelconque de colonnes.
- Il permet le contrôle des accès basé sur les attributs. Un tag avec stratégie associé à une colonne fournit un accès contextuel aux données, déterminé par la stratégie de données et les comptes principaux associés à ce tag avec stratégie.
Workflow de masquage des données
La figure 1 illustre le workflow de configuration du masquage de données :
Figure 1. Composants de masquage de données
Pour configurer le masquage de données, procédez comme suit :
- Configurez une taxonomie et un ou plusieurs tags avec stratégie.
Configurez des règles de données pour les tags avec stratégie. Une stratégie de données mappe une règle de masquage de données et un ou plusieurs comptes principaux, qui représentent des utilisateurs ou des groupes, avec le tag avec stratégie.
Lorsque vous créez une règle de données à l'aide de la console Google Cloud, vous créez la règle de masquage de données et spécifiez les comptes principaux en une seule étape. Lorsque vous créez une règle de données à l'aide de l'API BigQuery Data Policy, vous créez la règle de données et la règle de masquage de données en une étape, et spécifiez les comptes principaux pour la règle de données à une deuxième étape.
Attribuez des tags avec stratégie aux colonnes de vos tables BigQuery afin d'appliquer les règles de données.
Attribuez le rôle Lecteur masqué BigQuery aux utilisateurs qui doivent avoir accès aux données masquées. Nous vous recommandons d'attribuer le rôle de lecteur masqué BigQuery au niveau de la stratégie de données. L'attribution du rôle au niveau du projet ou à un niveau supérieur accorde aux utilisateurs des autorisations sur toutes les stratégies de données du projet, ce qui peut entraîner des problèmes en raison d'autorisations en excès.
Le tag avec stratégie associé à une stratégie de données peut également être utilisé pour le contrôle des accès au niveau des colonnes. Dans ce cas, le tag avec stratégie est également associé à un ou plusieurs comptes principaux auxquels le rôle Lecteur détaillé Data Catalog est attribué. Cela permet à ces entités principales d'accéder aux données de colonne d'origine non masquées.
La figure 2 illustre l'interaction entre le contrôle des accès au niveau des colonnes et le masquage de données :
Figure 2 Composants de masquage de données
Pour en savoir plus sur l'interaction avec les rôles, consultez la page Interaction des rôles Lecteur masqué et Lecteur détaillé. Pour en savoir plus sur l'héritage des tags avec stratégie, consultez la page Hiérarchie des tags avec stratégie.
Règles de masquage des données
Lorsque vous utilisez le masquage de données, une règle de masquage de données est appliquée à une colonne au moment de l'exécution de la requête, en fonction du rôle de l'utilisateur exécutant la requête. Le masquage des données est prioritaire sur toutes les autres opérations impliquées dans la requête. La règle de masquage de données détermine le type de masquage appliqué aux données de la colonne.
Vous pouvez utiliser les règles de masquage de données suivantes :
Routine de masquage personnalisée Renvoie la valeur de la colonne après avoir appliqué une fonction définie par l'utilisateur (UDF) à la colonne. Les autorisations de routine sont nécessaires pour gérer la règle de masquage. De par sa conception, cette règle est compatible avec tous les types de données BigQuery, à l'exception du type
STRUCT
. Cependant, la compatibilité des types de données autres queSTRING
etBYTES
est limitée. Le résultat dépend de la fonction définie.Pour en savoir plus sur la création de fonctions définies par l'utilisateur pour les routines de masquage personnalisées, consultez la section Créer des routines de masquage personnalisées.
Masque d'année de date. Renvoie la valeur de la colonne après l'avoir tronquée à l'année, en définissant toutes les parties autres que l'année elle-même sur le début de l'année. Vous ne pouvez utiliser cette règle qu'avec des colonnes utilisant les types de données
DATE
,DATETIME
etTIMESTAMP
. Exemple :Type Données Masqué DATE
2030-07-17 2030-01-01 DATETIME
2030-07-17T01:45:06 2030-01-01T00:00:00 TIMESTAMP
2030-07-17 01:45:06 2030-01-01 00:00:00 Valeur de masquage par défaut. Renvoie une valeur de masquage par défaut de la colonne en fonction du type de données de la colonne. Utilisez-le lorsque vous souhaitez masquer la valeur de la colonne, mais révéler le type de données. Lorsque cette règle de masquage des données est appliquée à une colonne, elle est moins utile dans les opérations
JOIN
de requête pour les utilisateurs disposant d'un accès en Lecteur masqué. En effet, une valeur par défaut n'est pas suffisamment unique pour être utile lors de la jointure de tables.Le tableau suivant indique la valeur de masquage par défaut pour chaque type de données :
Type de données Valeur de masquage par défaut STRING
"" BYTES
b'' INTEGER
0 FLOAT
0.0 NUMERIC
0 BOOLEAN
FALSE
TIMESTAMP
1970-01-01 00:00:00 UTC DATE
1970-01-01 TIME
00:00:00 DATETIME
1970-01-01T00:00:00 GEOGRAPHY
POINT(0 0) BIGNUMERIC
0 ARRAY
[] STRUCT
NON APPLICABLE
Les tags avec stratégie ne peuvent pas être appliqués aux colonnes qui utilisent le type de données
STRUCT
. Ils peuvent également être associés aux champs feuilles de ces colonnes.JSON
nul Masque de messagerie. Renvoie la valeur de la colonne après avoir remplacé le nom d'utilisateur d'une adresse e-mail valide par
XXXXX
. Si la valeur de la colonne n'est pas une adresse e-mail valide, renvoie la valeur de la colonne après lui avoir appliqué la fonction de hachage SHA-256. Vous ne pouvez utiliser cette règle qu'avec des colonnes utilisant le type de donnéesSTRING
. Exemple :Données Masqué abc123@gmail.com
XXXXX@gmail.com
randomtext
jQHDyQuj7vJcveEe59ygb3Zcvj0B5FJINBzgM6Bypgw=
test@gmail@gmail.com
Qdje6MO+GLwI0u+KyRyAICDjHbLF1ImxRqaW08tY52k=
Quatre premiers caractères. Renvoie les quatre premiers caractères de la valeur de la colonne, en remplaçant le reste de la chaîne par
XXXXX
. Si la colonne comporte quatre caractères ou moins, cette règle renvoie la valeur de la colonne après lui avoir appliqué la fonction de hachage SHA-256. Vous ne pouvez utiliser cette règle qu'avec des colonnes utilisant le type de donnéesSTRING
.Hachage (SHA-256). Renvoie la valeur de la colonne après lui avoir appliqué la fonction de hachage SHA-256. Utilisez-le lorsque vous souhaitez que l'utilisateur final puisse utiliser cette colonne dans une opération
JOIN
pour une requête. Vous ne pouvez utiliser cette règle qu'avec des colonnes qui utilisent les types de donnéesSTRING
ouBYTES
.La fonction SHA-256 utilisée dans le masquage de données permet de conserver le type. Par conséquent, la valeur de hachage qu'elle renvoie a le même type de données que la valeur de colonne. Par exemple, la valeur de hachage d'une valeur de colonne
STRING
a également un type de donnéesSTRING
.Quatre derniers caractères. Renvoie les quatre derniers caractères de la valeur de la colonne, en remplaçant le reste de la chaîne par
XXXXX
. Si la colonne comporte quatre caractères ou moins, cette règle renvoie la valeur de la colonne après lui avoir appliqué la fonction de hachage SHA-256. Vous ne pouvez utiliser cette règle qu'avec des colonnes utilisant le type de donnéesSTRING
.Toujours "Null". Renvoie
NULL
au lieu de la valeur de colonne. Utilisez-le lorsque vous souhaitez masquer à la fois la valeur et le type de données de la colonne. Lorsque cette règle de masquage des données est appliquée à une colonne, elle est moins utile dans les opérationsJOIN
de requête pour les utilisateurs disposant d'un accès en lecture masquée. En effet, une valeurNULL
n'est pas suffisamment unique pour être utile lors de la jointure de tables.
Hiérarchie des règles de masquage de données
Vous pouvez configurer jusqu'à neuf règles de données pour un tag avec stratégie, chacune étant associée à une règle de masquage différente. L'une de ces règles est réservée aux paramètres de contrôle des accès au niveau des colonnes. Cela permet d'appliquer plusieurs règles de données à une colonne de la requête d'un utilisateur, en fonction des groupes dont il est membre. Dans ce cas, BigQuery choisit la règle de masquage de données à appliquer en fonction de la hiérarchie suivante :
- Routine de masquage personnalisée
- Hachage (SHA-256)
- Masque d'adresse e-mail
- Quatre derniers caractères
- Quatre premiers caractères
- Masque d'année de date
- Valeur de masquage par défaut
- Toujours "Null"
Par exemple, l'utilisateur A est membre des groupes de comptabilité et d'employés. L'utilisateur A exécute une requête qui inclut le champ sales_total
, auquel le tag avec stratégie confidential
est appliqué. Le tag avec stratégie confidential
est associé à deux stratégies de données : l'une avec le rôle d'employé et l'identité du compte principal, qui applique la règle de masquage des données Toujours "Null", et l'autre avec le rôle de responsable et l'identité du compte principal, qui applique la règle de masquage des données par hachage SHA-256. Dans ce cas, la règle de masquage de données (SHA-256) est prioritaire sur la règle de masquage de données Toujours "Null". Par conséquent, la règle de hachage (SHA-256) est appliquée à la valeur du champ sales_total
dans la requête de l'utilisateur A.
La figure 3 illustre ce scénario :
Figure 3. Priorisation des règles de masquage de données.
Rôles et autorisations
Rôles pour la gestion des taxonomies et des tags avec stratégie
Vous devez disposer du rôle Administrateur de tags avec stratégie Data Catalog pour créer et gérer des taxonomies et des tags avec stratégie.
Rôle/Identifiant | Autorisations | Description |
---|---|---|
Administrateur de tags avec stratégie Data Catalog/datacatalog.categoryAdmin
|
datacatalog.categories.getIamPolicy datacatalog.categories.setIamPolicy datacatalog.taxonomies.create datacatalog.taxonomies.delete datacatalog.taxonomies.get datacatalog.taxonomies.getIamPolicy datacatalog.taxonomies.list datacatalog.taxonomies.setIamPolicy datacatalog.taxonomies.update resourcemanager.projects.get resourcemanager.projects.list
|
S'applique au niveau du projet. Ce rôle permet d'effectuer les opérations suivantes :
|
Rôles pour la création et la gestion des stratégies de données
Vous devez disposer de l'un des rôles BigQuery suivants pour créer et gérer des stratégies de données :
Rôle/Identifiant | Autorisations | Description |
---|---|---|
Administrateur des règles de données BigQuery/bigquerydatapolicy.admin Administrateur BigQuery/ bigquery.admin Propriétaire de données BigQuery/ bigquery.dataOwner
|
bigquery.dataPolicies.create bigquery.dataPolicies.delete bigquery.dataPolicies.get bigquery.dataPolicies.getIamPolicy bigquery.dataPolicies.list bigquery.dataPolicies.setIamPolicy bigquery.dataPolicies.update
|
Les autorisations Ce rôle permet d'effectuer les opérations suivantes :
|
datacatalog.taxonomies.get
, que vous pouvez obtenir à partir de plusieurs rôles prédéfinis de Data Catalog.
Rôles permettant d'associer des tags avec stratégie aux colonnes
Vous avez besoin des autorisations datacatalog.taxonomies.get
et bigquery.tables.setCategory
pour associer des tags avec stratégie aux colonnes.
datacatalog.taxonomies.get
est inclus dans les rôles "Administrateur de tags avec stratégie Data Catalog" et "Lecteur".
bigquery.tables.setCategory
est inclus dans les rôles "Administrateur BigQuery" (roles/bigquery.admin
) et "Propriétaire de données BigQuery" (roles/bigquery.dataOwner
).
Rôles permettant d'interroger des données masquées
Vous avez besoin du rôle Lecteur masqués BigQuery pour interroger les données d'une colonne à laquelle le masquage de données est appliqué.
Rôle/Identifiant | Autorisations | Description |
---|---|---|
Lecteur masqué/bigquerydatapolicy.maskedReader |
bigquery.dataPolicies.maskedGet |
S'applique au niveau des stratégies de données. Ce rôle permet d'afficher les données masquées d'une colonne associée à une stratégie de données. De plus, un utilisateur doit disposer des autorisations appropriées pour interroger la table. Pour en savoir plus, consultez la section Autorisations requises. |
Interaction des rôles Lecteur masqué et Lecteur détaillé
Le masquage des données s'appuie sur le contrôle d'accès au niveau des colonnes. Pour une colonne donnée, il est possible que certains utilisateurs disposant du rôle Lecteur masqué BigQuery puissent lire les données masquées. Certains utilisateurs disposant du rôle Lecteur détaillé Data Catalog les autorisent à lire les données non masquées, certains utilisateurs avec les deux et d'autres non. Ces rôles interagissent comme suit :
- Utilisateur doté des rôles Lecteur détaillé et Lecteur masqué : ce que voit l'utilisateur dépend de l'emplacement dans la hiérarchie des tags avec stratégie pour chaque rôle. Pour en savoir plus, consultez la section Héritage des autorisations dans une hiérarchie de tags avec stratégie.
- Utilisateur disposant du rôle Lecteur détaillé : peut afficher les données de colonne non masquées.
- Utilisateur disposant du rôle Lecteur masqué : peut afficher les données de colonne masquées.
- Utilisateur sans rôle : autorisation refusée.
Dans le cas où une table comporte des colonnes sécurisées et masquées, afin d'exécuter une instruction SELECT * FROM
sur cette table, un utilisateur doit être membre des groupes appropriés de façon à ce que les rôles Lecteur masqué ou Lecteur détaillé sur toutes ces colonnes.
Un utilisateur qui ne dispose pas de ces rôles doit uniquement spécifier les colonnes auxquelles il a accès dans l'instruction SELECT
, ou utiliser SELECT * EXCEPT
(restricted_columns) FROM
pour exclure les colonnes sécurisées ou masquées.
Héritage d'autorisation dans une hiérarchie de tags avec stratégie
Les rôles sont évalués à partir du tag avec stratégie associé à une colonne, puis vérifiés à chaque niveau croissant de la taxonomie, jusqu'à ce que l'utilisateur soit déterminé à disposer des autorisations appropriées ou le sommet de la hiérarchie des tags avec stratégie est atteint.
Prenons l'exemple de la configuration de tags avec stratégie et de règles de données présentés à la figure 4 :
Figure 4. Configuration des tags avec stratégie et des stratégies de données.
Vous disposez d'une colonne de table annotée avec le tag avec stratégie Financial
, et d'un utilisateur membre des groupes ftes@example.com et analysts@example.com. Lorsque cet utilisateur exécute une requête qui inclut la colonne annotée, son accès est déterminé par la hiérarchie définie dans la taxonomie du tag avec stratégie. Étant donné que l'utilisateur se voit attribuer le rôle Lecteur détaillé Data Catalog par le tag avec stratégie Financial
, la requête renvoie des données de colonne non masquées.
Si un autre utilisateur, qui est uniquement membre du rôle ftes@example.com, exécute une requête qui inclut la colonne annotée, celle-ci renvoie les données de colonne hachées avec l'algorithme SHA-256, car l'utilisateur dispose du rôle Lecteur masqué BigQuery grâce au tag avec stratégie Confidential
, qui est le parent du tag avec stratégie Financial
.
Un utilisateur qui n'est pas membre de l'un de ces rôles reçoit une erreur d'accès refusé s'il tente d'interroger la colonne annotée.
Contrairement au scénario précédent, prenons la configuration des tags avec stratégie et des règles de données présentées à la figure 5 :
Figure 5. Configuration des tags avec stratégie et des stratégies de données.
Vous avez la même situation que celle illustrée par la figure 4, mais l'utilisateur se voit attribuer le rôle de Lecteur détaillé à un niveau supérieur de la hiérarchie des tags avec stratégie, et le rôle de Lecteur masqué à un niveau inférieur de la hiérarchie de la stratégie des tags. Par conséquent, la requête renvoie des données de colonne masquées pour cet utilisateur. Cela se produit même si l'utilisateur se voit attribuer le rôle de Lecteur détaillé en amont de la hiérarchie des tags, car le service utilise le premier rôle attribué qu'il rencontre lorsqu'il dépasse la hiérarchie des tags avec stratégie pour vérifier l'accès des utilisateurs.
Si vous souhaitez créer une seule règle de données et l'appliquer à plusieurs niveaux d'une hiérarchie de tags avec stratégie, vous pouvez définir la règle de données sur le tag avec stratégie qui représente le niveau de hiérarchie le plus élevé auquel elle doit s'appliquer. Prenons l'exemple d'une taxonomie avec la structure suivante :
- Tag avec stratégie 1
- Tag avec stratégie 1a
- Tag de stratégie 1ai
- Tag avec stratégie 1b
- Tag avec stratégie 1bi
- Tag avec stratégie 1bii
- Tag avec stratégie 1a
Si vous souhaitez qu'une règle de données s'applique à tous ces tags avec stratégie, définissez-la sur le tag avec stratégie 1. Si vous souhaitez qu'une règle de données s'applique au tag avec stratégie 1b et à ses enfants, définissez-la sur le tag avec stratégie 1b.
Masquage de données avec des fonctionnalités incompatibles
Lorsque vous utilisez des fonctionnalités BigQuery non compatibles avec le masquage de données, le service traite la colonne masquée comme une colonne sécurisée et n'accorde l'accès qu'aux utilisateurs disposant du rôle Lecteur détaillé Data Catalog.
Prenons l'exemple de la configuration de tags avec stratégie et de règles de données présentés à la figure 6 :
Figure 6. Configuration des tags avec stratégie et des stratégies de données.
Vous disposez d'une colonne de table annotée avec le tag avec stratégie Financial
et un utilisateur membre du groupe analysts@example.com. Lorsque cet utilisateur tente d'accéder à la colonne annotée via l'une des fonctionnalités incompatibles, il reçoit une erreur d'accès refusé. En effet, ils se voient attribuer le tag avec stratégie Financial
dans le rôle Lecteur masqué BigQuery, mais dans ce cas, ils doivent disposer du rôle Lecteur détaillé Data Catalog.
Étant donné que le service a déjà déterminé un rôle applicable pour l'utilisateur, il ne poursuit pas la vérification approfondie de la hiérarchie des tags avec stratégie pour obtenir des autorisations supplémentaires.
Exemple de masquage de données avec une sortie
Pour voir comment les tags, les comptes principaux et les rôles fonctionnent ensemble, prenons cet exemple.
Sur example.com, l'accès de base est accordé via le groupe data-users@example.com. Tous les employés qui ont besoin d'un accès régulier aux données BigQuery sont membres de ce groupe. Celui-ci dispose de toutes les autorisations nécessaires pour lire les données des tables, ainsi que du rôle Lecteur masqué BigQuery.
Les employés sont affectés à des groupes supplémentaires qui donnent accès aux colonnes sécurisées ou masquées qui sont nécessaires à leur travail. Tous les membres de ces groupes supplémentaires sont également membres de data-users@example.com. Vous pouvez voir comment ces groupes sont associés aux rôles appropriés à la figure 7 :
Figure 7. Tags avec stratégie et stratégies de données pour example.com.
Les tags avec stratégie sont ensuite associés à des colonnes de table, comme illustré à la figure 8 :
Figure 8. Tags avec stratégie example.com associés à des colonnes de table.
Étant donné les tags associés aux colonnes, l'exécution de SELECT * FROM Accounts;
entraîne les résultats suivants pour les différents groupes :
data-users@example.com : ce groupe a obtenu le rôle Lecteur masqué BigQuery sur les tags avec stratégie
PII
etConfidential
. Les résultats suivants sont renvoyés :SSN Priorité Valeur vie Date de création E-mail NULL "" 0 8 mars 1983 NULL NULL "" 0 29 décembre 2009 NULL NULL "" 0 14 juillet 2021 NULL NULL "" 0 5 mai 1997 NULL accounting@example.com : ce groupe dispose du rôle Lecteur détaillé Data Catalog sur le tag avec stratégie
SSN
. Les résultats suivants sont renvoyés :SSN Priorité Valeur vie Date de création NULL 123-45-6789 "" 0 8 mars 1983 NULL 234-56-7891 "" 0 29 décembre 2009 NULL 345-67-8912 "" 0 14 juillet 2021 NULL 456-78-9123 "" 0 5 mai 1997 NULL sales-exec@example.com : ce groupe a obtenu le rôle Lecteur détaillé Data Catalog sur le tag avec stratégie
Confidential
. Les résultats suivants sont renvoyés :SSN Priorité Valeur vie Date de création E-mail NULL Importante 90 000 8 mars 1983 NULL NULL Importante 84,875 29 décembre 2009 NULL NULL Moyenne 38,000 14 juillet 2021 NULL NULL Faibles 245 5 mai 1997 NULL fin-dev@example.com : le rôle Lecteur masqué BigQuery a été attribué au groupe sur le tag avec stratégie
Financial
. Les résultats suivants sont renvoyés :SSN Priorité Valeur vie Date de création E-mail NULL "" Zmy9vydG5q= 8 mars 1983 NULL NULL "" GhwTwq6Ynm= 29 décembre 2009 NULL NULL "" B6y7dsgaT9= 14 juillet 2021 NULL NULL "" Uh02hnR1sg= 5 mai 1997 NULL Tous les autres utilisateurs : tout utilisateur qui n'appartient pas à l'un des groupes répertoriés reçoit une erreur d'accès refusé, car il ne dispose pas du rôle Lecteur détaillé Data Catalog ou du rôle Lecteur masqué BigQuery. Pour interroger la table
Accounts
, ils ne doivent spécifier que les colonnes auxquelles elles ont accès dansSELECT * EXCEPT (restricted_columns) FROM Accounts
, à l'exception des colonnes sécurisées ou masquées.
Considérations liées au coût
Le masquage des données peut avoir une incidence indirecte sur le nombre d'octets traités, et donc sur le coût de la requête. Si un utilisateur interroge une colonne masquée avec les règles "Toujours Null" ou "Valeur de masquage par défaut", la colonne n'est pas analysée du tout, ce qui réduit le nombre d'octets traités.
Restrictions et limitations
Les sections suivantes décrivent les catégories de restrictions et de limites auxquelles le masquage de données est soumis.
Gestion des stratégies de données
- Cette fonctionnalité peut ne pas être disponible si vous utilisez des réservations créées avec certaines éditions BigQuery. Pour en savoir plus sur les fonctionnalités activées dans chaque édition, consultez la page Présentation des éditions BigQuery.
- Vous pouvez créer jusqu'à neuf stratégies de données pour chaque tag avec stratégie. L'une de ces règles est réservée aux paramètres de contrôle des accès au niveau des colonnes.
- Les règles de données, les tags avec stratégie associés et toutes les routines qui les utilisent doivent se trouver dans le même projet.
Tags avec stratégie
- Le projet contenant la taxonomie de tags avec stratégie doit appartenir à une organisation.
Une hiérarchie de tags avec stratégie ne peut pas dépasser cinq niveaux de profondeur du nœud racine au sous-tag de niveau le plus bas, comme illustré dans la capture d'écran suivante:
Définir le contrôle des accès
Une fois qu'une taxonomie est associée à au moins un de ses tags avec stratégie, le contrôle des accès est automatiquement appliqué. Si vous souhaitez désactiver le contrôle des accès, vous devez d'abord supprimer toutes les règles de données associées à la taxonomie.
Vues matérialisées et requêtes de masquage des enregistrements répétés
Si vous avez des vues matérialisées existantes, les requêtes de masquage des enregistrements répétée sur la table de base associée échouent. Pour résoudre ce problème, supprimez la vue matérialisée. Si la vue matérialisée est nécessaire pour d'autres raisons, vous pouvez la créer dans un autre ensemble de données.
Interroger des colonnes masquées dans des tables partitionnées
Les requêtes qui incluent un masquage de données sur des colonnes partitionnées ou en cluster ne sont pas acceptées.
Dialectes SQL
L'ancien SQL n'est pas compatible.
Routines de masquage personnalisées
Les routines de masquage personnalisées sont soumises aux limites suivantes :
- Le masquage des données personnalisé est compatible avec tous les types de données BigQuery, à l'exception de
STRUCT
, car il ne peut s'appliquer qu'aux champs de feuilles du type de donnéesSTRUCT
. - La suppression d'une routine de masquage personnalisée ne supprime pas toutes les stratégies de données qui l'utilisent. Toutefois, les stratégies de données qui utilisent la routine de masquage supprimée se voient attribuer une stratégie de masquage vide. Les utilisateurs disposant du rôle Lecteur masqué pour d'autres règles de données avec le même tag peuvent voir les données masquées. D'autres voient le message
Permission denied.
Des références bancales à des règles de masquage vides peuvent être nettoyées par des processus automatisés après sept jours.
Compatibilité avec d'autres fonctionnalités BigQuery
API BigQuery
Non compatible avec la méthode tabledata.list
. Pour appeler tabledata.list
, vous avez besoin d'un accès complet à toutes les colonnes renvoyées par cette méthode. Le rôle Lecteur détaillé Data Catalog accorde l'accès approprié.
Tables BigLake
Compatible. Les règles de masquage des données sont appliquées aux tables BigLake.
API BigQuery Storage Read
Compatible. Les règles de masquage des données sont appliquées dans l'API BigQuery Storage Read.
BigQuery BI Engine
Compatible. Les règles de masquage des données sont appliquées dans BI Engine. Les requêtes avec masquage de données en vigueur ne sont pas accélérées par BI Engine. L'utilisation de ce type de requêtes dans Looker Studio peut ralentir les coûts ou les tableaux de bord associés.
BigQuery Omni
et compatible. Les règles de masquage des données sont appliquées aux tables BigQuery Omni.
Classement
Incompatible. Le classement n'est pas compatible avec les colonnes masquées.
Tâches de copie
Incompatible. Pour copier une table de la source vers la destination, vous devez disposer d'un accès complet à toutes les colonnes de la table source. Le rôle Lecteur détaillé Data Catalog accorde l'accès approprié.
Exportation de données
Compatible. Si vous disposez du rôle Lecteur masqué BigQuery, les données exportées sont masquées. Si vous disposez du rôle Lecteur détaillé Data Catalog, les données exportées ne sont pas masquées.
Sécurité au niveau des lignes
Compatible. Le masquage des données est appliqué en plus de la sécurité au niveau des lignes. Par exemple, si une règle d'accès aux lignes est appliquée sur location = "US"
et que location
est masqué, les utilisateurs peuvent voir les lignes où location = "US"
est présent, mais le champ de localisation est masqué.
Effectuer une recherche dans BigQuery
Partiellement compatible. Vous pouvez appeler la fonction SEARCH
sur des colonnes indexées ou non indexées auxquelles le masquage de données est appliqué.
Lorsque vous appelez la fonction SEARCH
sur des colonnes auxquelles le masquage de données est appliqué, vous devez utiliser des critères de recherche compatibles avec votre niveau d'accès. Par exemple, si vous avez accès en Lecteur masqué avec une règle de masquage de données SHA-256, vous devez utiliser la valeur de hachage dans votre clause SEARCH
, comme suit :
SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "sg172y34shw94fujaweu");
Si vous avez un accès en Lecteur détaillé, vous devez utiliser la valeur de colonne réelle dans votre clause SEARCH
, comme suit :
SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "jane.doe@example.com");
La recherche est moins susceptible d'être utile si vous avez un accès en Lecteur masqué à une colonne pour laquelle la règle de masquage de données utilisée est Toujour "Null" ou Valeur de masquage par défaut. En effet, les résultats masqués que vous utilisez comme critères de recherche, tels que NULL
ou ""
, ne sont pas suffisamment uniques pour être utiles.
Lors de la recherche sur une colonne indexée pour laquelle le masquage de données est appliqué, l'index de recherche n'est utilisé que si vous avez un accès précis au lecteur dans la colonne.
Instantanés
Incompatible. Pour créer un instantané d'une table, vous avez besoin d'un accès complet à toutes les colonnes de la table source. Le rôle Lecteur détaillé Data Catalog accorde l'accès approprié.
Renommage des tables
Compatible. Le renommage de table n'est pas affecté par le masquage de données.
Fonctionnalité temporelle
Compatible avec les décorateurs d'heure et l'option FOR SYSTEM_TIME AS OF
dans les instructions SELECT
Les tags avec stratégie pour le schéma d'ensemble de données actuel sont appliqués aux données récupérées.
Mise en cache de requêtes
Partiellement compatible. BigQuery met en cache les résultats des requêtes pendant environ 24 heures, bien que le cache soit invalidé si des modifications sont apportées aux données ou au schéma de la table avant cette date. Dans les cas suivants, il est possible qu'un utilisateur ne disposant pas du rôle Lecteur détaillé Data Catalog sur une colonne puisse toujours voir les données de colonne lorsqu'il exécute une requête :
- Un utilisateur dispose du rôle Lecteur détaillé Data Catalog sur une colonne.
- L'utilisateur exécute une requête qui inclut la colonne restreinte et les données sont mises en cache.
- Dans les 24 heures suivant l'étape 2, l'utilisateur se voit attribuer le rôle Lecteur masqué BigQuery et se voit retirer le rôle Lecteur détaillé Data Catalog.
- Dans les 24 heures suivant l'étape 2, l'utilisateur exécute la même requête, et les données mises en cache sont renvoyées.
Requêtes de tables génériques
Incompatible. Vous avez besoin d'un accès complet à toutes les colonnes référencées sur toutes les tables correspondant à la requête générique. Le rôle Lecteur détaillé Data Catalog accorde l'accès approprié.
Étapes suivantes
- Obtenez des instructions détaillées pour activer le masquage des données.