Audit de la dette IAM pour les plateformes de données GCP

Les plateformes de données accumulent de la dette IAM avec le temps : rôles Editor accordés par commodité, comptes de service partagés, clés de comptes de service commitées dans des dépôts. Cette note fournit des requêtes bash et SQL pour identifier les formes les plus courantes de cette dette — une base de référence avant de renforcer les permissions.

Identifier les principaux sur-privilégiés

Lister tous les principaux disposant de rôles Editor ou Owner au niveau du projet :

gcloud projects get-iam-policy YOUR_PROJECT_ID \
  --flatten="bindings[].members" \
  --format="table(bindings.role,bindings.members)" \
  --filter="bindings.role:(roles/editor OR roles/owner)"

Cette commande unique fait apparaître les permissions les plus risquées de votre projet. Editor et Owner sont des rôles primitifs qui précèdent les rôles prédéfinis IAM — ils accordent un accès étendu à tous les services GCP, pas seulement BigQuery. Toute personne qui apparaît ici parce qu’elle « avait besoin d’un accès BigQuery » est un candidat au nettoyage. Le bon correctif est de passer au rôle prédéfini approprié (roles/bigquery.dataViewer, roles/bigquery.dataEditor) au périmètre adéquat (dataset, pas projet).

Ne vous attendez pas à corriger chaque résultat immédiatement. Priorisez d’abord les comptes de service — ce sont souvent des workloads automatisés qui ne remarqueront pas le changement. Les utilisateurs humains avec Editor « parce que l’IT l’avait configuré ainsi » nécessitent plus de coordination.

Identifier les comptes de service avec des clés

Les clés de comptes de service sont des credentials téléchargeables qui peuvent être copiés, committés dans le contrôle de version et utilisés depuis n’importe où. Ce sont les artefacts les plus risqués dans une configuration GCP typique.

gcloud iam service-accounts list --project=YOUR_PROJECT_ID \
  --format="value(email)" | while read sa; do
    keys=$(gcloud iam service-accounts keys list --iam-account="$sa" \
      --format="value(name)" --filter="keyType=USER_MANAGED" 2>/dev/null)
    if [ -n "$keys" ]; then
      echo "Compte de service avec clés : $sa"
    fi
done

Le --filter="keyType=USER_MANAGED" exclut les clés gérées par Google (clés système que Google fait tourner automatiquement). Vous recherchez les clés que des humains ont créées et téléchargées — ce sont celles qui peuvent être divulguées.

Pour chaque résultat, le chemin de remédiation est :

1. Déterminer ce qui utilise la clé (vérifier les configs de déploiement, les systèmes CI/CD, les machines de développement locales)
2. Migrer vers l’authentification sans clé : Workload Identity Federation pour CI pour les systèmes CI, impersonation de compte de service pour le développement local
3. Faire tourner ou supprimer la clé après avoir confirmé que rien n’en dépend

Détecter les comptes de service partagés

Le problème des comptes de service partagés est plus difficile à voir depuis les seules politiques IAM. Un seul etl-service-account peut sembler correctement périmétré, mais être utilisé par une douzaine de workloads différents. Les preuves apparaissent dans l’historique des jobs BigQuery :

SELECT
  user_email,
  COUNT(DISTINCT job_id) AS job_count,
  COUNT(DISTINCT REGEXP_EXTRACT(query, r'FROM `([^`]+)`')) AS tables_accessed
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND user_email LIKE '%.iam.gserviceaccount.com'
GROUP BY user_email
ORDER BY job_count DESC

Un compte de service exécutant des centaines de requêtes différentes sur des dizaines de tables est presque certainement partagé entre des workloads. Un nombre élevé de jobs et un nombre élevé de tables sont la signature caractéristique. C’est votre première cible de remédiation — non pas parce que c’est le correctif le plus facile, mais parce que les comptes de service partagés sont là où le rayon d’impact s’accumule. Quand les permissions d’un workload doivent changer, vous ne pouvez pas les changer sans affecter tout ce qui partage le compte.

Lire les résultats comme un backlog priorisé

Les trois requêtes ensemble vous donnent un backlog de remédiation ordonné par risque :

Commencez par les comptes de service. Ce sont des systèmes automatisés — vous pouvez mettre à jour les permissions et voir immédiatement si quelque chose se casse. Les utilisateurs humains nécessitent de la coordination et généralement un certain préavis.

Le pattern RBAC à 2 couches avec Google Groups est l’état cible pour les permissions des utilisateurs humains. Le pattern conventions de nommage des comptes de service par workload est l’état cible pour les comptes de service. Exécutez l’audit d’abord pour comprendre l’écart, puis progressez vers ces patterns un workload à la fois.