Partage de données BigQuery entre organisations

BigQuery propose plusieurs mécanismes pour partager des données entre frontières organisationnelles, chacun adapté à différents modèles de confiance et exigences de sensibilité des données. Cette note couvre le pattern agence/client, Analytics Hub, les vues autorisées, et la sécurité au niveau des lignes et des colonnes.

Pattern Agence/Client : Travailler dans les Organisations Clients

Le pattern recommandé pour les agences et les cabinets de conseil : chaque client possède son organisation GCP. L’agence y accède selon les besoins.

Organisation Client Alpha (appartient au client)
├── client-alpha-analytics
│   └── Toutes les ressources BigQuery, modèles dbt, données
└── IAM : Équipe agence avec accès accordé

Organisation Client Beta (appartient au client)
├── client-beta-analytics
│   └── Toutes les ressources BigQuery, modèles dbt, données
└── IAM : Équipe agence avec accès accordé

Organisation Agence (appartient à l'agence)
└── agency-internal
    └── Outillage interne, templates, documentation uniquement

Cela assure une propriété des données claire. Les données client restent dans l’infrastructure client. Quand les missions se terminent, les clients conservent le contrôle complet sans migration de données. La facturation s’écoule naturellement vers les comptes clients. Les exigences de conformité sont sous la responsabilité du client à définir et de l’agence à suivre.

L’équipe agence s’authentifie séparément dans chaque organisation client. Maintenez des comptes de service séparés par client, des identifiants séparés, des profils dbt séparés. Cela ajoute de la charge opérationnelle mais prévient les fuites de données entre clients et garde les pistes d’audit propres.

Solution de Repli : Projet par Client dans l’Organisation de l’Agence

Certains clients ne peuvent pas ou ne veulent pas maintenir leur propre organisation GCP — petites entreprises sans infrastructure IT, missions courte durée, ou clients qui veulent explicitement que l’agence gère tout.

Organisation Agence
├── agency-admin
│   └── Logs d'audit, exports de facturation, outillage partagé
├── client-alpha-analytics
│   └── Toutes les ressources BigQuery pour Client Alpha
└── client-beta-analytics
    └── Toutes les ressources BigQuery pour Client Beta

Ce pattern nécessite une attention particulière. Documentez clairement que l’agence possède l’infrastructure. Définissez la propriété des données et les droits d’export dans les contrats. Planifiez l’offboarding : si un client veut partir, vous devrez exporter ses données et potentiellement migrer son projet dbt vers sa propre organisation.

Utilisez les labels et des projets séparés pour suivre précisément les coûts par client. La facturation peut s’écouler vers le compte de facturation du client (lié au projet de l’agence) ou l’agence peut facturer sur la base des coûts.

Analytics Hub pour le Partage Formel de Données

Analytics Hub permet le partage de données sans copie entre frontières organisationnelles. C’est le bon outil quand vous avez besoin d’un partage structuré et auditable avec des rôles clairement définis d’éditeur/abonné.

Un propriétaire de données publie un dataset dans une annonce Analytics Hub. Les abonnés d’autres organisations demandent l’accès. Une fois approuvés, ils obtiennent un dataset lié — une référence en lecture seule qui pointe vers les données source sans les copier.

Caractéristiques clés :

• Les coûts de stockage restent chez l’éditeur. Les coûts de requête vont à l’abonné.
• Les abonnés ne peuvent pas modifier les données, ne peuvent pas définir l’IAM sur les tables individuelles, ne peuvent rien faire d’autre que lire.
• Les éditeurs peuvent restreindre entièrement l’egress de données, bloquant EXPORT, CREATE TABLE AS SELECT, et les opérations de copie.
• Tout accès est journalisé pour l’audit.

Pour le travail d’agence, créez un échange privé dans Analytics Hub. Ajoutez des principals spécifiques (utilisateurs, groupes ou comptes de service) comme abonnés. Les clients s’abonnent aux annonces et interrogent via leurs datasets liés.

Analytics Hub est particulièrement utile quand la relation de données est vraiment unidirectionnelle : un fournisseur de données partage des datasets sélectionnés avec des consommateurs qui ne devraient que lire, jamais modifier. Pour la collaboration bidirectionnelle (où les deux parties créent et partagent des données), les patterns d’organisations séparées ci-dessus sont plus appropriés.

Vues Autorisées pour un Accès Contrôlé

Les vues autorisées résolvent un problème courant : exposer des données filtrées ou agrégées sans accorder l’accès aux tables sous-jacentes. Elles fonctionnent entre frontières organisationnelles.

Le pattern :

1. Créer une vue dans un dataset dédié qui interroge des tables source sensibles
2. Autoriser le dataset de la vue à accéder au dataset source
3. N’accorder aux utilisateurs que l’accès au dataset de la vue

-- Dans le dataset : shared_views
CREATE VIEW shared_views.analyst_orders AS
SELECT
  order_id,
  order_date,
  total_amount
  -- customer_ssn exclu
  -- internal_notes exclu
FROM sensitive_data.mrt__sales__orders
WHERE region = 'EMEA';  -- Filtrage des lignes

La vue référence sensitive_data.mrt__sales__orders, mais les utilisateurs n’ont besoin que d’accéder à shared_views. Dans la console BigQuery, vous autorisez shared_views à accéder à sensitive_data. Quiconque peut interroger shared_views.analyst_orders obtient la vue filtrée et à colonnes restreintes sans aucune permission sur sensitive_data.

Les datasets autorisés étendent ce concept. Plutôt que d’autoriser des vues individuelles, vous autorisez un dataset entier. Toutes les vues actuelles et futures de ce dataset peuvent accéder aux données source. Cela réduit la charge de gestion quand vous créez de nombreuses vues pour différents patterns d’accès.

Les vues autorisées sont le mécanisme le plus simple pour les cas d’usage de filtrage de colonnes et de lignes. Elles ne nécessitent pas d’infrastructure Analytics Hub et fonctionnent au sein d’un seul projet ou entre projets.

Sécurité au Niveau des Lignes et des Colonnes

Pour les environnements véritablement multi-tenants où différents utilisateurs voient différentes lignes de la même table, BigQuery offre la sécurité au niveau des lignes :

CREATE ROW ACCESS POLICY client_a_only
ON multi_tenant.mrt__shared__orders
GRANT TO ('group:client-a-analysts@clienta.com')
FILTER USING (client_id = 'CLIENT_A');

CREATE ROW ACCESS POLICY client_b_only
ON multi_tenant.mrt__shared__orders
GRANT TO ('group:client-b-analysts@clientb.com')
FILTER USING (client_id = 'CLIENT_B');

Les analystes du Client A interrogeant multi_tenant.mrt__shared__orders ne voient que leurs lignes. Le Client B ne voit que les siennes. La table est la même ; l’accès diffère. C’est transparent pour la requête — les utilisateurs n’ont pas besoin d’ajouter des clauses WHERE client_id = ..., et ils ne peuvent pas contourner le filtre même s’ils essaient.

La sécurité au niveau des colonnes utilise les policy tags Data Catalog. Vous créez un tag (comme PII), l’appliquez aux colonnes sensibles, puis accordez à des utilisateurs spécifiques le rôle Fine-Grained Reader pour ce tag. Les utilisateurs sans ce rôle voient ces colonnes comme null ou reçoivent des erreurs d’accès.

Le masquage dynamique de données va plus loin. Les utilisateurs avec le rôle Masked Reader voient des valeurs hachées ou partiellement masquées plutôt que des null. Utile pour les scénarios où les analystes ont besoin de voir qu’une valeur existe et peuvent faire des jointures dessus, mais ne devraient pas voir le contenu réel — pensez aux adresses e-mail hachées pour le matching entre datasets sans exposer les PII.

Choisir le Bon Mécanisme

Commencez par le mécanisme le plus simple qui répond à vos exigences. Les vues autorisées couvrent la plupart des cas. La sécurité au niveau des lignes apporte de la valeur quand vous ne pouvez pas séparer les tenants dans différents datasets. Analytics Hub apporte de la valeur quand vous avez besoin d’une gouvernance formelle sur qui peut s’abonner à quoi.