ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Surveillance de la dérive IAM pour GCP

Détecter la dette IAM avant qu'elle ne s'accumule — IAM Recommender, surveillance des jobs via INFORMATION_SCHEMA et requêtes sur les logs d'audit pour identifier les dérives de permissions trimestriellement.

Planté
gcpbigquerydata engineering

La dette IAM se réaccumule après un nettoyage initial : des rôles Editor accordés temporairement et jamais révoqués, de nouveaux workloads qui réutilisent des comptes de service existants, des permissions issues de projets terminés qui ne sont jamais supprimées. Trois signaux permettent de détecter la dérive de permissions : IAM Recommender pour le sur-provisionnement, BigQuery INFORMATION_SCHEMA pour les patterns d’accès inattendus, et les logs d’audit pour les modifications IAM elles-mêmes.

IAM Recommender

Le service IAM Recommender de GCP analyse 90 jours de données d’utilisation réelle pour identifier les principals disposant de plus de permissions qu’ils n’en utilisent :

Terminal window
gcloud recommender recommendations list \
  --project=YOUR_PROJECT_ID \
  --location=global \
  --recommender=google.iam.policy.Recommender

Le recommender peut faire remonter des constats tels que :

  • Un compte de service avec bigquery.dataEditor n’a effectué que des opérations de lecture pendant 90 jours — réduire à bigquery.dataViewer
  • Un utilisateur avec bigquery.admin n’a jamais modifié les paramètres BigQuery — réduire à bigquery.jobUser
  • Un principal dispose de roles/editor mais n’utilise que des permissions spécifiques à BigQuery — remplacer par des rôles BigQuery prédéfinis

Chaque recommandation inclut un score de confiance et les actions spécifiques à effectuer. Les recommandations à haute confiance peuvent être appliquées sans investigation. Celles à confiance moyenne méritent de vérifier si le pattern d’utilisation est représentatif — un data engineer qui n’a fait que de la lecture pendant 90 jours est peut-être simplement en phase intensive de lecture.

Exécutez cette commande mensuellement et traitez les recommandations. Le recommender fait l’analyse ; c’est vous qui prenez les décisions.

BigQuery INFORMATION_SCHEMA pour les accès inattendus

Les policies IAM indiquent quel accès les principals pourraient utiliser. INFORMATION_SCHEMA.JOBS indique ce qu’ils font réellement :

SELECT
  user_email,
  DATE(creation_time) AS query_date,
  COUNT(*) AS query_count,
  SUM(total_bytes_billed) / POW(10, 12) AS tb_billed
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
GROUP BY 1, 2
ORDER BY tb_billed DESC

Examinez ces données hebdomadairement ou mensuellement en vous posant deux questions :

Des identités inattendues apparaissent-elles ? Si un compte de service que vous n’avez jamais vu commence à exécuter des requêtes, quelque chose a changé — un nouveau déploiement, une credential mal utilisée, ou un ancien compte de service censé être désactivé qui tourne encore. Recherchez immédiatement les identités inattendues.

Le pattern d’accès correspond-il aux attentes ? Un compte de service qui exécutait 50 requêtes le trimestre dernier et en exécute maintenant 5 000 mérite une investigation. Un utilisateur qui lance normalement des requêtes d’analyste et qui soudainement effectue de grands scans de tables à 3h du matin mérite une conversation.

La version attribution des coûts de cette requête ajoute les octets traités à l’analyse — utile pour détecter les requêtes incontrôlées résultant de permissions larges donnant accès à des tables volumineuses et non partitionnées.

Logs d’audit pour les modifications IAM

BigQuery INFORMATION_SCHEMA couvre ce qui se passe à l’intérieur de BigQuery. Cloud Audit Logs couvre les modifications IAM sur l’ensemble de GCP. Exportez les logs d’audit vers BigQuery et interrogez-les pour suivre qui accorde des permissions et quand :

SELECT
  timestamp,
  protoPayload.authenticationInfo.principalEmail AS grantor,
  protoPayload.serviceData.policyDelta.bindingDeltas
FROM `your_audit_dataset.cloudaudit_googleapis_com_activity`
WHERE protoPayload.methodName = 'SetIamPolicy'
  AND timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
ORDER BY timestamp DESC

Cette requête fait remonter chaque modification de policy IAM au cours des 30 derniers jours. Ce que vous recherchez :

  • Des rôles Editor ou Owner qui sont accordés (cela ne devrait presque jamais arriver)
  • Des modifications IAM effectuées en dehors des heures de bureau (peut indiquer une compromission)
  • Des modifications effectuées par des principals inattendus (qui a la permission de modifier IAM ?)
  • Des pics de modifications (les grants en masse indiquent parfois une automatisation défaillante)

Pour configurer le sink de logs :

Terminal window
gcloud logging sinks create iam-audit-sink \
  bigquery.googleapis.com/projects/YOUR_PROJECT_ID/datasets/audit_logs \
  --log-filter='protoPayload.methodName="SetIamPolicy"' \
  --project=YOUR_PROJECT_ID

Le sink capture les nouvelles modifications IAM à partir de maintenant. Il ne rétroplante pas les événements historiques, donc configurez-le avant d’en avoir besoin.

Un processus de revue trimestrielle

Les signaux de surveillance sont plus utiles comme entrées d’une cadence de revue régulière que pour une investigation ponctuelle. Une revue IAM trimestrielle empêche la dérive de s’accumuler :

Mois 1 : Exécutez les requêtes d’audit complètes — rôles Editor/Owner, comptes de service avec des clés, comptes partagés. Traitez les résultats de la sortie du recommender du trimestre précédent.

Mois 2 : Examinez les patterns de jobs INFORMATION_SCHEMA. Identifiez les comptes de service avec des patterns d’accès inhabituels. Vérifiez que tous les comptes de service actifs suivent la convention de nommage (qui vous indique en un coup d’œil si quelque chose d’non autorisé a été créé).

Mois 3 : Examinez les modifications IAM dans les logs d’audit. Vérifiez que les modifications IAM se font par les mécanismes attendus (PRs Terraform, demandes d’accès approuvées) plutôt que de manière ad-hoc via la console ou la CLI.

La première revue après une période de négligence est la plus chronophage. Les revues trimestrielles suivantes sont plus courtes, car elles préviennent l’accumulation plutôt que de traiter des backlogs.

Le lien avec les coûts

Un IAM sur-provisionné n’est pas seulement un problème de sécurité. Lorsque les analystes ont accès à des tables dont ils n’ont pas besoin, ils exécutent accidentellement des requêtes coûteuses dessus. Lorsque des comptes de service disposent de rôles Editor au lieu d’un accès de dataset ciblé, ils peuvent lire et scanner n’importe quelle table du projet.

Les requêtes de coût INFORMATION_SCHEMA et les requêtes IAM INFORMATION_SCHEMA s’appuient sur les mêmes données. Les équipes qui surveillent les deux ensemble constatent que le nettoyage IAM produit souvent des réductions de 20 à 30 % des coûts de requêtes BigQuery — non pas parce qu’elles ont optimisé les requêtes, mais parce qu’elles ont supprimé les accès qui rendaient possible les plus coûteuses.