Présentation du masquage des données

Remarque : 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.

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 :

• Cela 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, il n'est pas nécessaire 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 :

1. Configurez une taxonomie et un ou plusieurs tags avec stratégie.

2. 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.

3. Attribuez des tags avec stratégie aux colonnes de vos tables BigQuery afin d'appliquer les règles de données.

4. 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 que STRING et BYTES 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 et TIMESTAMP. 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

  Remarque : L'heure de troncation est basée sur le fuseau horaire UTC. Pour modifier ce comportement, ajustez le fuseau horaire par défaut en utilisant la variable système @@time_zone.

• 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ées STRING. Exemple :

  Données	Masqué
  [e-mail]	[e-mail]
  randomtext	jQHDyQuj7vJcveEe59ygb3Zcvj0B5FJINBzgM6Bypgw=
  test@[e-mail]	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ées STRING.

• 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ées STRING ou BYTES.

  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 possède également un type de données STRING.

  Important : SHA-256 est une fonction de hachage déterministe ; une valeur initiale est toujours résolue avec la même valeur de hachage. Toutefois, aucune clé de chiffrement n'est requise. Cela permet à un individu malveillant d'utiliser une attaque par force brute pour déterminer la valeur d'origine, en utilisant toutes les valeurs d'origine possibles avec l'algorithme SHA-256 et en identifiant celle qui génère un hachage correspondant au hachage renvoyé par le masquage de données.

• 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ées STRING.

• 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érations JOIN de requête pour les utilisateurs disposant d'un accès en lecture masquée. En effet, une valeur NULL 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 stratégies est réservée aux paramètres de contrôle des accès au niveau de la colonne. 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 :

1. Routine de masquage personnalisée
2. Hachage (SHA-256)
3. Masque d'adresse e-mail
4. Quatre derniers caractères
5. Quatre premiers caractères
6. Masque d'année de date
7. Valeur de masquage par défaut
8. 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 : Créer, lire, mettre à jour et supprimer des taxonomies et des tags avec stratégie Obtenir et définir des stratégies IAM au niveau de tags avec stratégie

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 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 bigquery.dataPolicies.create et bigquery.dataPolicies.list s'appliquent au niveau du projet. Les autres autorisations s'appliquent au niveau de la stratégie de données. Ce rôle permet d'effectuer les opérations suivantes : Créer, lire, mettre à jour et supprimer des stratégies de données Obtenir et définir des stratégies IAM sur des stratégies de données

Vous avez également besoin de l'autorisation 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 [e-mail] et [e-mail]. 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 [e-mail], 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

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 des 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 [e-mail]. 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 [e-mail]. 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 [e-mail]. 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 :

• [e-mail] : ce groupe a obtenu le rôle Lecteur masqué BigQuery sur les tags avec stratégie PII et Confidential. 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

• [e-mail] : 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

• [e-mail] : 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

• [e-mail] : 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 dans SELECT * 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 stratégies est réservée aux paramètres de contrôle des accès au niveau de la colonne.
• Les stratégies de données, les tags avec stratégie associés et toutes les routines qui les utilisent doivent appartenir au 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 le masquage des données ne peut être appliqué qu'aux champs feuille du type de données STRUCT.
• 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é" sur d'autres stratégies de données portant 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, "[e-mail]");

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 :

1. Un utilisateur dispose du rôle Lecteur détaillé Data Catalog sur une colonne.
2. L'utilisateur exécute une requête qui inclut la colonne restreinte et les données sont mises en cache.
3. 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.
4. 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.