Sécurité au niveau des colonnes BigQuery avec les policy tags

L’approche traditionnelle pour masquer des colonnes sensibles est une vue qui les omet :

-- Ne plus faire ça
CREATE VIEW safe_customers AS
SELECT customer_id, signup_date, country
-- SSN et email délibérément omis
FROM raw_customers

Cela crée trois problèmes : la charge de maintenance (chaque nouvelle colonne nécessite des mises à jour de vues), la surcharge de performance (les vues sur des vues s’accumulent), et les lacunes de gouvernance (qui sait quelles vues masquent quelles colonnes, et pourquoi ?). Quand votre table raw_customers ajoute une colonne date_of_birth, cette vue l’expose silencieusement jusqu’à ce que quelqu’un le remarque.

Les policy tags Data Catalog résolvent cela au niveau de la couche de stockage. La colonne elle-même devient taguée, et l’accès à cette colonne est gouverné par IAM — indépendamment de la façon dont la table est interrogée. Pas de maintenance de vue requise.

Configurer une Taxonomie

Les policy tags vivent dans une taxonomie — une classification hiérarchique des niveaux de sensibilité. Concevez votre taxonomie pour correspondre à vos exigences réelles de gouvernance des données, pas à des aspirations théoriques.

Une taxonomie PII pratique :

# Créer la taxonomie
gcloud data-catalog taxonomies create "PII" \
  --location=us \
  --description="Personally identifiable information"

# Créer les niveaux de sensibilité
gcloud data-catalog taxonomies policy-tags create "High_Sensitivity" \
  --taxonomy="projects/YOUR_PROJECT/locations/us/taxonomies/PII" \
  --description="SSN, passport numbers, financial account numbers"

gcloud data-catalog taxonomies policy-tags create "Medium_Sensitivity" \
  --parent-policy-tag="projects/YOUR_PROJECT/locations/us/taxonomies/PII/policyTags/High_Sensitivity" \
  --description="Email, phone number, home address"

La relation parent-enfant compte pour les octrois de permissions : accorder l’accès à High_Sensitivity se propage aux tags enfants. Concevez la hiérarchie de façon à ce que « plus d’accès » signifie être accordé à un niveau plus élevé dans l’arbre, pas par accumulation d’octrois de tags individuels.

Activer le Contrôle d’Accès

Créer la taxonomie n’applique pas automatiquement le contrôle d’accès. Vous devez activer le contrôle d’accès pour activer les policy tags :

gcloud data-catalog taxonomies set-iam-policy \
  "projects/YOUR_PROJECT/locations/us/taxonomies/PII" \
  policy.json

Où policy.json spécifie qui peut gérer la taxonomie (votre équipe de gouvernance des données) mais omet délibérément categoryFineGrainedReader — cet octroi va sur les policy tags individuels, pas sur la taxonomie elle-même.

Tagger les Colonnes

Taguez les colonnes dans les définitions de schéma BigQuery. Terraform est l’approche la plus maintenable pour les schémas en production :

resource "google_bigquery_table" "customers" {
  dataset_id = "raw"
  table_id   = "customers"
  project    = var.project_id

  schema = jsonencode([
    {
      name = "customer_id"
      type = "STRING"
      # Pas de policy tag — l'identifiant n'est pas sensible
    },
    {
      name = "email"
      type = "STRING"
      policyTags = {
        names = ["projects/${var.project_id}/locations/us/taxonomies/PII/policyTags/Medium_Sensitivity"]
      }
    },
    {
      name = "ssn"
      type = "STRING"
      policyTags = {
        names = ["projects/${var.project_id}/locations/us/taxonomies/PII/policyTags/High_Sensitivity"]
      }
    }
  ])
}

Une fois taguée, tout utilisateur qui interroge la table sans le rôle approprié de lecteur fin reçoit une erreur sur cette colonne. Le tag applique le contrôle d’accès au moment de la requête — pas au moment de l’octroi des permissions.

Accorder l’Accès

Accordez datacatalog.categoryFineGrainedReader sur le policy tag spécifique, pas sur le projet :

# Accorder l'accès Medium_Sensitivity au groupe des analystes
gcloud data-catalog taxonomies policy-tags add-iam-policy-binding \
  "projects/YOUR_PROJECT/locations/us/taxonomies/PII/policyTags/Medium_Sensitivity" \
  --member="group:data-analysts@yourdomain.com" \
  --role="roles/datacatalog.categoryFineGrainedReader"

# Accorder l'accès High_Sensitivity uniquement aux data engineers
gcloud data-catalog taxonomies policy-tags add-iam-policy-binding \
  "projects/YOUR_PROJECT/locations/us/taxonomies/PII/policyTags/High_Sensitivity" \
  --member="group:data-engineers@yourdomain.com" \
  --role="roles/datacatalog.categoryFineGrainedReader"

L’erreur courante est d’accorder categoryFineGrainedReader au niveau du projet — ce qui donne accès à tous les policy tags du projet. Si vous ajoutez ultérieurement une taxonomie Financial_Data, tout le monde avec un accès au niveau projet peut la voir automatiquement. Accordez au niveau du tag pour un vrai moindre privilège.

Propriétés de Gouvernance

Avec les policy tags, la sécurité au niveau des colonnes est centralisée dans Data Catalog plutôt que distribuée dans des définitions de vues. Vous pouvez répondre à la question « qui peut voir les adresses e-mail ? » en regardant les liaisons IAM du policy tag Medium_Sensitivity — un seul endroit, réponse complète.

Quand vous ajoutez une nouvelle colonne sensible à une table, taguez-la à la création. Le contrôle d’accès est immédiat et ne nécessite pas de créer ou mettre à jour des vues. Quand la classification de sensibilité d’une colonne change — par exemple, une colonne qui contenait autrefois des identifiants anonymisés contient maintenant de vrais identifiants — mettez à jour le tag et la protection est instantanée sur toutes les tables l’utilisant.

Pour le cas d’usage dbt, les policy tags doivent survivre aux reconstructions de tables. Quand dbt supprime et recrée une table, les policy tags assignés via la définition de schéma sont préservés si le schéma de la table est géré via Terraform ou explicitement dans les fichiers de schéma BigQuery. Si vous gérez entièrement les tables via dbt, voir Matérialisation de tables sécurisées dans dbt pour le pattern qui réapplique explicitement les policy tags après chaque reconstruction.

Les tags se combinent également avec les politiques d’accès aux lignes BigQuery et le masquage dynamique de données BigQuery. Un utilisateur peut ne voir que certaines lignes (politique de lignes), avoir l’e-mail visible sous forme de hash plutôt qu’en clair (masquage), et être entièrement bloqué pour la colonne SSN (policy tag). Chaque couche s’applique indépendamment.