Identifiants et sécurité dans Looker Studio

Le modèle d’identification de Looker Studio a des implications en matière de sécurité et de coûts qui affectent le comportement du cache, le contrôle d’accès et l’attribution de la facturation BigQuery.

Les deux modes d’identification

Identifiants du propriétaire signifie que tous les visiteurs accèdent à BigQuery via l’identité du propriétaire du tableau de bord. Quand quelqu’un ouvre votre rapport Looker Studio, son navigateur effectue des appels API authentifiés sous votre identité (ou le compte utilisé lors de la création de la connexion à la source de données). BigQuery ne voit qu’une seule identité, qu’il y ait 1 ou 1 000 personnes qui consultent le rapport.

Identifiants du visiteur signifie que chaque visiteur s’authentifie avec son propre compte Google. BigQuery voit l’identité réelle de chaque personne qui ouvre le rapport. Cela exige que les visiteurs disposent d’un accès direct à BigQuery, ce qui ajoute une charge de gestion IAM.

La vulnérabilité LeakyLooker

En mars 2026, Tenable a publié un rapport de sécurité intitulé « LeakyLooker » démontrant une exfiltration de données sans clic via des rapports Looker Studio publics utilisant les identifiants du propriétaire. Le vecteur d’attaque : un rapport public (accessible à toute personne disposant du lien) utilisant les identifiants du propriétaire expose les données sous-jacentes à quiconque peut consulter le rapport — y compris des personnes que le propriétaire n’avait jamais eu l’intention de partager, et sans que l’attaquant ait besoin de s’authentifier.

Parce que les paramètres de partage de Looker Studio et les contrôles d’accès de BigQuery sont indépendants, un rapport peut être partagé publiquement même si les données BigQuery sous-jacentes sont contrôlées. Les identifiants du propriétaire contournent entièrement l’IAM de BigQuery du point de vue du visiteur. Toutes les données auxquelles le propriétaire peut accéder, tout visiteur d’un rapport public peut les extraire en construisant la bonne configuration de graphique.

Les implications pour la politique de sécurité :

Ne jamais utiliser les identifiants du propriétaire sur des rapports publics. Si un rapport est publiquement accessible (toute personne disposant du lien peut le consulter), utilisez les identifiants du visiteur afin que l’accès soit conditionné par les propres permissions BigQuery du visiteur.
Auditez les rapports publics de votre organisation. Accédez à Google Workspace Admin > Rapports > Looker Studio, ou effectuez un audit via le panneau d’administration Looker Studio. Identifiez les rapports utilisant les identifiants du propriétaire accessibles en dehors de votre domaine.
Utilisez les identifiants du visiteur pour tout rapport contenant des données sensibles ou confidentielles, même s’il est partagé uniquement au sein de votre organisation.

Attribution des coûts avec les identifiants du propriétaire

La dimension coût est distincte de la sécurité mais tout aussi importante à comprendre. Avec les identifiants du propriétaire, toutes les requêtes BigQuery de Looker Studio sont facturées sur le projet du propriétaire des identifiants. Si 200 personnes ouvrent un tableau de bord avec 10 graphiques, 2 000 requêtes BigQuery s’exécutent sur le compte de facturation du propriétaire.

Si votre organisation a plusieurs équipes qui partagent des tableaux de bord et que chaque équipe utilise ses propres identifiants propriétaire, les coûts sont silencieusement répartis sur plusieurs projets sans visibilité centrale. Les coûts du tableau de bord de l’équipe technique apparaissent dans un projet, ceux de l’équipe marketing dans un autre, et personne n’a une image complète du coût global de Looker Studio.

Vous pouvez suivre les coûts par propriétaire de rapport en utilisant INFORMATION_SCHEMA.JOBS filtré sur le label de requête de Looker Studio :

SELECT
  user_email,
  COUNT(*) AS query_count,
  SUM(total_bytes_processed) / POW(1024, 4) AS total_tb_processed,
  SUM(total_bytes_processed) / POW(1024, 4) * 6.25 AS estimated_cost_usd
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND (
    SELECT l.value
    FROM UNNEST(labels) l
    WHERE l.key = 'requestor'
  ) = 'looker_studio'
GROUP BY 1
ORDER BY estimated_cost_usd DESC;

Le champ user_email correspond ici au propriétaire des identifiants, pas au visiteur. Cette requête vous indique quels propriétaires de rapports génèrent le plus de dépenses BigQuery, ce qui vous permet d’identifier les rapports les plus coûteux à optimiser.

Utilisation des comptes de service pour les tableaux de bord en production

La bonne pratique pour les tableaux de bord Looker Studio en production est d’utiliser un compte de service dédié comme propriétaire des identifiants plutôt qu’un compte personnel. Cela résout simultanément deux problèmes :

1. Continuité organisationnelle : quand une personne quitte l’organisation, son compte personnel est désactivé. Chaque rapport utilisant ses identifiants tombe en panne immédiatement — les visiteurs voient des erreurs, les données cessent de se charger. Avec un compte de service, le rapport continue de fonctionner indépendamment des changements de personnel.

2. Principe du moindre privilège : un compte personnel dispose généralement d’un accès BigQuery bien plus large qu’un tableau de bord donné n’en a besoin. Un compte de service dédié peut se voir accorder exactement les permissions requises pour les sources de données de ce rapport, et rien de plus. Si les identifiants du compte de service sont détournés, le rayon d’impact est limité aux données auxquelles ce compte peut accéder.

Configuration d’un compte de service pour Looker Studio :

Créez un compte de service dans le projet où résident les données : looker-studio-prod@project.iam.gserviceaccount.com
Accordez-lui roles/bigquery.dataViewer sur les datasets ou tables spécifiques dont le tableau de bord a besoin
Accordez-lui roles/bigquery.jobUser sur le projet où les requêtes s’exécuteront
Dans Looker Studio, lors de la création ou de la modification de la source de données, choisissez « Compte de service » comme type d’identification et importez le fichier de clé

Pour les organisations gérant plusieurs tableaux de bord, envisagez une convention de nommage qui rende l’objet du compte de service clair : ls-marketing-dashboard@project.iam.gserviceaccount.com vs ls-ops-monitoring@project.iam.gserviceaccount.com. Cela rend les audits IAM lisibles et les attributions d’accès intentionnelles.

Les schémas IAM à moindre privilège pour GCP couvrent l’approche plus globale, mais le compte de service Looker Studio est l’un des quick wins à ROI le plus élevé : il prend 20 minutes à configurer, élimine la fragilité des identifiants, et fournit une attribution des coûts plus claire.

Identifiants du visiteur : quand le compromis en vaut la peine

Les identifiants du visiteur impliquent un volume de requêtes plus élevé (chaque visiteur obtient son propre cache plutôt que d’en partager un), mais c’est le bon choix dans des scénarios spécifiques :

Filtrage par ligne selon l’identité du visiteur : chaque commercial devrait voir uniquement ses propres comptes. Avec les identifiants du visiteur, BigQuery peut appliquer la sécurité au niveau des lignes car la requête s’exécute sous l’identité réelle de l’utilisateur. Avec les identifiants du propriétaire, la sécurité par ligne est impossible — le propriétaire des identifiants voit tout, et les visiteurs aussi.
Données sensibles ou réglementées : données RH, données financières, tout ce qui nécessite une journalisation des accès par individu. Les identifiants du visiteur garantissent que les journaux d’audit de BigQuery montrent qui a réellement accédé aux données, et pas seulement le propriétaire des identifiants.
Exigences de conformité : certaines réglementations exigent que les accès aux données soient journalisés et attribuables à un individu spécifique. Les identifiants du visiteur satisfont à cette exigence ; les identifiants du propriétaire non.

Si vous utilisez les identifiants du visiteur, planifiez le volume de requêtes plus élevé. Chaque visiteur est effectivement un nouveau contexte de cache. Un tableau de bord avec 100 visiteurs quotidiens peut générer 5 à 10 fois plus de requêtes BigQuery que le même tableau de bord avec les identifiants du propriétaire et un cache partagé. Définissez des limites max_bytes_billed agressives sur la connexion et envisagez BI Engine pour maintenir les coûts par requête bas même à des volumes plus élevés.