Masquage dynamique de données BigQuery

Les policy tags au niveau des colonnes créent une frontière stricte : les utilisateurs voient soit la colonne, soit ils ne la voient pas. Ce binaire fonctionne bien pour les données très sensibles (numéros de sécurité sociale, numéros de compte financier) où il n’y a pas de raison légitime pour la plupart des utilisateurs de voir même la structure des valeurs.

Mais parfois les analystes ont besoin de travailler avec des données sensibles sans voir les valeurs réelles. Ils construisent des requêtes qui joignent sur des adresses e-mail, testent si leur logique gère correctement les valeurs null, ou valident que les comptages de lignes correspondent entre environnements. Bloquer entièrement la colonne empêche un travail légitime. Exposer les valeurs réelles viole la politique de confidentialité.

Le masquage dynamique de données couvre cet écart. Au lieu de bloquer l’accès, il montre des valeurs obscurcies — hachages, valeurs par défaut ou null — qui permettent aux analystes de travailler avec la forme de la colonne sans en voir le contenu.

Comment Fonctionne le Masquage

Le masquage se construit au-dessus des policy tags au niveau des colonnes. La colonne doit déjà être taguée avec un policy tag. Vous créez ensuite une politique de données sur cette colonne qui définit ce que les utilisateurs masqués voient :

CREATE DATA POLICY pii_email_mask
ON project.dataset.customers
COLUMN email
USING SHA256;

Accordez le rôle maskedReader aux groupes qui doivent voir des données masquées :

gcloud bigquery data-policies add-iam-policy-binding \
  --data-policy=pii_email_mask \
  --location=us \
  --member="group:data-analysts@yourdomain.com" \
  --role="roles/bigquery.maskedReader"

Maintenant, quand les analystes interrogent la colonne email, ils voient a7f3d2e1b4c5... au lieu de user@example.com. Le hash est toujours le même pour la même entrée, ce qui compte pour les jointures.

Les utilisateurs avec l’octroi complet categoryFineGrainedReader sur le policy tag sous-jacent voient les valeurs réelles. Les utilisateurs avec maskedReader voient le masque. Les utilisateurs sans aucun des deux reçoivent une erreur.

Options de Masquage

Trois approches de masquage, chacune avec des cas d’usage différents :

SHA256 — hachage déterministe. Le même e-mail produit toujours le même hash. Cela signifie que les analystes peuvent :

• Écrire des requêtes qui font des JOIN sur l’e-mail (la jointure fonctionne parce que le hash est cohérent)
• Compter les e-mails distincts
• Identifier si deux lignes ont le même e-mail

Ils ne peuvent pas récupérer l’e-mail original à partir du hash, et ils ne peuvent pas faire correspondre le hash à des e-mails dans d’autres systèmes (listes d’e-mails externes, exports CRM) où les valeurs sont non masquées.

Utilisez SHA256 quand la colonne est utilisée comme clé de jointure et que les analystes ont légitimement besoin de faire des jointures dessus, juste pas de lire la valeur réelle.

DEFAULT_MASKING_VALUE — retourne des valeurs par défaut appropriées au type. Les chaînes deviennent des chaînes vides, les nombres deviennent 0, les dates deviennent l’epoch, les booléens deviennent false. Cela obscurcit à la fois la valeur et le fait qu’une valeur existe.

Utilisez le masquage par défaut quand les analystes ont besoin de savoir que la colonne existe et son type, mais n’ont pas besoin de distinguer entre des lignes masquées spécifiques.

NULLIFY — retourne toujours NULL. La colonne apparaît dans le schéma, mais chaque ligne affiche NULL pour les utilisateurs masqués.

Utilisez la nullification quand vous voulez que la colonne soit complètement invisible en termes de valeurs, mais que vous souhaitez toujours que les analystes puissent référencer le nom de la colonne dans des requêtes sans erreurs.

Accorder au Niveau de la Politique de Données, Pas du Projet

L’erreur de sur-permission courante avec le masquage :

# NE PAS faire ça — accorde maskedReader sur TOUTES les colonnes masquées du projet
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member="group:data-analysts@yourdomain.com" \
  --role="roles/bigquery.maskedReader"

maskedReader au niveau du projet donne un accès masqué à toutes les politiques de données du projet. Si vous ajoutez une nouvelle politique de données pour une colonne plus sensible le trimestre prochain, tout le monde avec un accès au niveau projet voit automatiquement cette colonne (masquée). Ce n’est pas du moindre privilège.

Accordez au niveau de la politique de données :

gcloud bigquery data-policies add-iam-policy-binding \
  --data-policy=pii_email_mask \
  --location=us \
  --member="group:data-analysts@yourdomain.com" \
  --role="roles/bigquery.maskedReader"

Cela accorde l’accès masqué uniquement à cette politique de données spécifique. L’ajout de nouvelles politiques de données n’étend pas automatiquement l’accès.

Concevoir les Niveaux d’Accès

Avec le masquage en place, vous avez trois niveaux pour les colonnes sensibles :

Assignez les niveaux aux groupes selon le besoin légitime :

• Les data analysts obtiennent l’accès masqué pour les colonnes qu’ils doivent interroger mais pas lire
• Les data engineers obtiennent l’accès complet pour les colonnes impliquées dans les transformations
• La conformité / le service juridique obtiennent l’accès complet selon les besoins pour des investigations spécifiques
• Les outils BI et dashboards dépendent de ce que le dashboard affiche — masqué pour les agrégats, complet pour les enregistrements individuels

Avec le masquage en place, les analystes peuvent effectuer des jointures, des agrégations, des comptages de lignes et des validations de requêtes sans accès PII complet. L’accès complet devient une escalade délibérée et auditable plutôt que l’octroi par défaut.

Combinaison avec les Politiques de Lignes

Le masquage et les politiques d’accès aux lignes se composent. Un analyste peut ne voir que les lignes de sa région (politique de lignes) et voir la colonne e-mail comme un hash (masquage). Les deux politiques s’appliquent au moment de la requête, indépendamment.

Un modèle d’accès complexe :

• Les analystes ne voient que les lignes de leur région assignée
• Ils voient l’e-mail sous forme de SHA256 (joinable mais illisible)
• Ils sont entièrement bloqués pour la colonne SSN

Ce sont trois contrôles séparés : une politique d’accès aux lignes, une politique de données avec masquage SHA256, un policy tag sans octroi de masked reader. Chacun est géré et audité indépendamment.