Google ACE: Hiérarchie des ressources, IAM et administration de la facturation — Guide d'étude

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Fait partie du Google Associate Cloud Engineer — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

La hiérarchie des ressources, la gestion des identités et des accès (IAM) et l’administration de la facturation constituent le plan de contrôle des opérations Google Cloud. Une conception résiliente commence par une hiérarchie claire (organisation, dossiers, projets) pour définir la portée des règles et des responsabilités ; applique le principe du moindre privilège IAM avec une administration centrée sur les groupes et des identifiants éphémères pour les charges de travail ; utilise des budgets, des exportations et des libellés pour l’attribution des coûts ; et impose la gouvernance avec des règles d’organisation et une journalisation d’audit complète. L’excellence opérationnelle découle de la standardisation de l’héritage, de la centralisation de la facturation et des journaux, et de l’utilisation de l’usurpation d’identité de compte de service plutôt que de clés à longue durée de vie. Cette section détaille les concepts fondamentaux, leur utilisation prévue et les modes de défaillance courants à éviter.

Hiérarchie des ressources et modèle d’identité

• Hiérarchie des ressources

  • Organisation : Nœud racine, créé avec Cloud Identity ou Google Workspace. Détient les règles globales (IAM, règles d’organisation, tags).
  • Dossiers : Regroupement facultatif pour les départements, les environnements (par ex., dev, prod) ou les applications. Utile pour l’administration déléguée et la définition de la portée des règles.
  • Projets : Frontière administrative pour les ressources, les API, les quotas, l’IAM et l’association à la facturation. La plupart des ressources Google Cloud sont des enfants de projets.
  • Héritage : Les stratégies IAM et les règles d’organisation héritent de haut en bas. Les refus et les contraintes aux niveaux supérieurs ont la priorité. Planifiez le placement (organisation → dossiers → projets) pour minimiser les exceptions et les besoins d’accès d’urgence.

• Identités

  • Comptes Google (utilisateurs), Groupes Google, comptes de service et identités externes via Workload Identity Federation.
  • Les Groupes Google devraient être la cible de liaison principale pour l’accès humain afin de simplifier les changements de cycle de vie et les révisions.
  • Les comptes de service représentent des applications ou des services ; préférez l’identité de charge de travail aux clés.

• Identités de charge de travail

  • Dans Google Cloud : GCE/GAE/Cloud Run/GKE utilisent le serveur de métadonnées pour créer des jetons éphémères pour le compte de service associé.
  • En dehors de Google Cloud : Workload Identity Federation mappe les identités externes (OIDC/SAML/AWS) à des comptes de service sans clés statiques.

• Compromis de conception et modes de défaillance

  • La prolifération de projets sans structure de dossiers entraîne la duplication et la dérive des règles.
  • L’attribution de rôles directement aux utilisateurs augmente la charge de travail manuelle ; préférez les liaisons basées sur des groupes.
  • L’utilisation du compte de service par défaut de Compute Engine avec des autorisations étendues augmente le risque ; créez des comptes de service à moindre privilège par charge de travail.
  • Placer un projet dans le mauvais dossier lui fait hériter de règles incorrectes ; utilisez des tags ou déplacez les projets avec précaution en suivant un processus de contrôle des changements.

Rôles IAM et conception des stratégies

• Types de rôles

  • Rôles de base (Lecteur, Éditeur, Propriétaire) : Larges, hérités. À éviter sauf pour un accès d’urgence étroitement contrôlé.
  • Rôles prédéfinis : Spécifiques à chaque service ; à privilégier pour la plupart des cas d’usage.
  • Rôles personnalisés : Agrégation d’autorisations au niveau de l’organisation ou du projet pour des besoins sur mesure.
  • Rôles conditionnels : Les conditions IAM (CEL) ajoutent du contexte tel que le nom de la ressource, le dossier, les tags ou l’heure ; à utiliser pour restreindre les rôles puissants.

• Principes des stratégies

  • Moindre privilège : N’accordez que le rôle minimal à la portée la plus restreinte (ressource/projet/dossier).
  • Séparation des tâches : Divisez les responsabilités (par ex., administrateur réseau vs administrateur de la sécurité vs administrateur de la facturation). Ne couplez pas les actions de déploiement et d’approbation dans une seule identité.
  • Conscience de l’héritage : Une liaison au niveau de l’organisation/dossier affecte tous les descendants ; documentez le rayon d’impact prévu avant de l’appliquer.

• Règles de refus (Deny)

  • IAM Deny bloque explicitement les autorisations même si elles sont accordées ailleurs ; à utiliser comme garde-fous (par ex., refuser iam.serviceAccountKeys.create).
  • Le refus a la priorité ; assurez-vous d’avoir un accès d’urgence documenté avec des processus d’exception limités dans le temps.

• Exemples

  • Copier un rôle personnalisé de dev à prod :

undefined

• Accorder un accès administrateur SSH basé sur un groupe avec OS Login :

undefined

• Modes de défaillance
  • Le rôle Éditeur accordé au niveau de l’organisation ou d’un dossier se propage involontairement à tous les projets.
  • Des rôles conditionnels avec des conditions trop strictes peuvent casser silencieusement les automatisations ; testez avec Policy Troubleshooter avant le déploiement.
  • Les rôles personnalisés ne sont pas toujours mis à jour avec les nouvelles autorisations ; révisez-les périodiquement.

Administration de la facturation et des coûts

• Comptes de facturation et association

  • Un projet doit être lié à un seul et unique compte de facturation pour les services facturables.
  • Rôles : L’administrateur de compte de facturation (Billing Account Administrator) gère le compte et les moyens de paiement ; l’utilisateur de compte de facturation (Billing Account User) lie les projets ; le gestionnaire de facturation de projet (Project Billing Manager) gère le lien de facturation d’un projet.
  • Centralisez sur un compte de facturation d’entreprise ; migrez les projets en mettant à jour l’association de facturation du projet.

• Budgets, alertes et attribution

  • Les budgets génèrent des alertes, pas des plafonds de dépenses. Utilisez une correction programmatique avec Pub/Sub et Cloud Functions/Cloud Run si une application stricte est nécessaire.
  • Exportez les données de facturation vers BigQuery pour l’analyse et la prévision des coûts quotidiens/mensuels ; combinez avec les libellés et les tags de ressources pour l’attribution.
  • Libellés et tags : Standardisez les clés (par ex., cost_center, env, app). Des libellés manquants réduisent la précision de l’attribution.

• Analyse des coûts

  • Utilisez l’exportation BigQuery pour calculer des prévisions glissantes par SKU/service avec SQL. Joignez avec les métadonnées des ressources (par ex., les libellés GCE) pour des rapports granulaires.
  • Pour une analyse multi-projets, agrégez les exportations de tous les projets ou exportez vers un seul ensemble de données central.

• Pièges courants

  • Budgets non configurés pour les nouveaux projets ; établissez une règle pour créer automatiquement des budgets lors de la création de projet.
  • L’absence d’exportation BigQuery signifie une vision historique limitée ; activez-la tôt pour constituer un historique.
  • Les cartes de crédit personnelles sur les projets fragmentent la responsabilité ; consolidez sous le compte de facturation de l’entreprise avec les profils IAM et de paiement appropriés.
  • Les anomalies de coûts dans les projets de services partagés nécessitent un étiquetage et une politique de refacturation interne.

Modèles d’authentification et d’accès sécurisés pour les workloads

• Usurpation d’identité de compte de service (impersonation)

  • Préférez l’usurpation d’identité aux clés. Accordez le rôle roles/iam.serviceAccountTokenCreator à une identité appelante ; l’appelant obtient des jetons à durée de vie limitée pour agir en tant que compte de service.
  • Exemple : gcloud auth print-access-token
    –impersonate-service-account sa-deployer@PROJECT_ID.iam.gserviceaccount.com

• Clés et rotation

  • Évitez les clés gérées par l’utilisateur. Si nécessaire, stockez-les dans Secret Manager, effectuez une rotation au moins tous les 90 jours, surveillez leur utilisation et restreignez-les avec VPC Service Controls et CMEK.
  • Appliquez des contraintes pour bloquer la création de clés : constraints/iam.disableServiceAccountKeyCreation = true

• OS Login et SSH

  • Utilisez OS Login avec des rôles IAM basés sur des groupes (compute.osLogin, compute.osAdminLogin). Chaque utilisateur télécharge sa clé SSH publique sur son compte Google pour un accès attribuable. Auditez via les journaux d’activité d’administration (Admin Activity) et d’accès aux données (Data Access).
  • Évitez d’intégrer des clés SSH partagées dans les images.

• Workload Identity Federation

  • Pour les environnements sur site (on-prem) ou d’autres clouds, configurez la fédération d’identité pour accorder l’accès à Google Cloud sans créer de clés, réduisant ainsi le risque d’exfiltration.

• Modes de défaillance et mesures d’atténuation

  • Le stockage de clés dans des dépôts ou des variables CI/CD mène à des compromissions ; passez à l’usurpation d’identité ou à la fédération.
  • Les comptes de service par défaut avec des rôles étendus sont risqués ; restreignez-les avec la contrainte constraints/iam.allowedPolicyMemberDomains et supprimez les rôles primitifs.
  • Un scope manquant sur les anciennes instances GCE peut bloquer l’accès à l’API ; préférez l’utilisation de permissions IAM par API ainsi que les identifiants par défaut de l’application (default application credentials).

Gouvernance, Règles d’organisation, Audit et Dépannage

• Règles d’organisation et contraintes

  • Appliquer des garde-fous à l’aide de contraintes : interdire les adresses IP externes sur les VM, restreindre les régions, empêcher la création de clés, limiter les services autorisés, exiger un accès uniforme au niveau du bucket, restreindre le partage de domaines.
  • Cibler par hiérarchie de ressources et affiner avec des tags pour les exceptions spécifiques à un environnement.

• Cloud Identity et cycle de vie

  • Cloud Identity fournit l’annuaire d’utilisateurs, le SSO et les rôles administratifs. Déléguez de manière restreinte (par ex., Group Admin, User Management Admin) et automatisez les workflows d’arrivée-mobilité-départ pour mettre à jour l’appartenance aux groupes et les accès.
  • Utilisez Access Approvals et Access Transparency pour les environnements sensibles.

• Journalisation d’audit

  • Les journaux d’activité d’administration (Admin Activity) et d’événements système (System Event) sont toujours activés ; les journaux d’accès aux données (Data Access) doivent être activés explicitement et peuvent entraîner des coûts.
  • Centralisez en routant les récepteurs agrégés depuis les dossiers/l’organisation vers un projet de sécurité. Protégez avec CMEK et un accès restreint.
  • Surveillez les journaux de refus de règles (Policy Denied) pour détecter les conflits de règles d’organisation.

• Boîte à outils de dépannage multi-projets

  • Policy Troubleshooter : Diagnostiquez pourquoi un accès est autorisé ou refusé en fonction des règles IAM et de refus effectives.
  • Cloud Asset Inventory : Interrogez les liaisons IAM (bindings) et l’historique des règles à travers l’organisation, les dossiers et les projets. Exemple : gcloud asset search-all-iam-policies
    –scope=organizations/ORG_ID
    –query=‘policy:roles/storage.objectAdmin AND “bucket-name”’
  • Logs Explorer : Filtrez par principal, méthode et ressource pour tracer les actions à travers les projets.
  • Configurations gcloud pour le changement de contexte opérateur : gcloud config configurations activate PROD
  • Modes de défaillance courants : des règles d’organisation conflictuelles bloquant les déploiements, l’absence de journaux d’accès aux données (Data Access) entravant les enquêtes, et des permissions IAM accordées à la mauvaise portée. Établissez des guides opératoires (runbooks) et des prévisualisations avant modification pour réduire le MTTR des incidents.

Scénario de problème pratique

Aurelia Retail consolide plusieurs équipes et projets après une acquisition. Ils doivent centraliser la facturation, appliquer une administration IAM et SSH cohérente sur des centaines de VM Compute Engine, et établir une gouvernance avec une perturbation minimale.

1. Créer un compte de facturation d’entreprise et lier les projets

• Justification : Un compte de facturation unique centralise les méthodes de paiement, les crédits et les budgets. Accordez le rôle Billing Account User à un groupe de migration de projet et Project Billing Manager aux chefs d’équipe pour relier à nouveau les projets sans accorder de privilèges excessifs.
• Action : Dans la console, créez le compte de facturation. Pour chaque projet, mettez à jour son association de facturation. Activez immédiatement l’exportation de la facturation (Billing export) vers BigQuery dans un projet d’analyse central.

2. Standardiser la hiérarchie des ressources avec des dossiers et des tags

• Justification : Placer les projets sous des dossiers d’environnement (prod, nonprod) permet l’héritage des garde-fous et des exceptions ciblées. Les tags permettent un ciblage fin des règles d’organisation sans dupliquer les arborescences de dossiers.
• Action : Créez des dossiers pour prod et nonprod ; déplacez les projets en conséquence. Définissez les tags env=prod|nonprod et des identifiants d’application.

3. Mettre en œuvre une gestion IAM basée sur les groupes avec le moindre privilège et la séparation des tâches

• Justification : Les groupes simplifient le cycle de vie et l’audit. Répartir les rôles entre les déployeurs, la sécurité et les administrateurs réseau réduit le rayon d’impact (blast radius).
• Action : Créez des groupes Google pour app-operators, net-admins, sec-admins et billing-managers. Liez les rôles prédéfinis au niveau du dossier/projet selon les besoins ; évitez les rôles de base.

4. Appliquer une administration SSH basée sur OS Login

• Justification : Les clés SSH individuelles attachées aux comptes utilisateurs fournissent un accès attribuable et révocable. Les rôles OS Login gèrent les comptes Linux via IAM, éliminant ainsi les clés partagées.
• Action : Dans chaque projet, activez les métadonnées OS Login. Accordez le rôle compute.osAdminLogin au groupe ops-admins. Exemple : gcloud compute project-info add-metadata
  –metadata enable-oslogin=TRUE

5. Remplacer les clés de compte de service par l’emprunt d’identité (impersonation)

• Justification : Les identifiants éphémères atténuent le risque d’exfiltration de clés et simplifient la rotation. Les journaux d’audit capturent qui a emprunté l’identité de qui, améliorant la traçabilité.
• Action : Accordez le rôle roles/iam.serviceAccountTokenCreator aux identités des exécuteurs CI/CD sur les comptes de service des charges de travail. Supprimez les clés gérées par l’utilisateur et appliquez une règle d’organisation pour bloquer les nouvelles clés.

6. Appliquer des règles d’organisation comme garde-fous

• Justification : Les contraintes empêchent les configurations risquées sur tous les projets tout en autorisant des exceptions basées sur des tags là où c’est justifié.
• Action : Appliquez des contraintes pour interdire les adresses IP externes en production, restreindre les régions aux emplacements approuvés et désactiver la création de clés de compte de service. Utilisez des tags pour autoriser des exceptions pour des projets spécifiques avec des approbations documentées.

7. Établir une gouvernance des coûts

• Justification : Les budgets alertent les propriétaires avant les dépassements de dépenses ; l’exportation vers BigQuery permet l’attribution et la prévision. Les libellés (labels) et les tags associent les dépenses en ressources aux centres de coûts.
• Action : Créez des budgets par dossier et par application majeure avec des notifications Pub/Sub. Appliquez des règles de libellés (label policies) via des modèles de déploiement et la validation des règles en CI.

8. Centraliser l’audit et accélérer le dépannage

• Justification : La journalisation agrégée et l’inventaire des ressources (asset inventory) à l’échelle de l’organisation accélèrent les enquêtes et les rapports de conformité.
• Action : Créez des récepteurs agrégés vers un projet de sécurité avec des buckets protégés par CMEK. Activez les journaux d’accès aux données (Data Access) pour les services critiques (Cloud Storage, BigQuery). Utilisez Cloud Asset Inventory pour analyser régulièrement les liaisons IAM. Formez les opérateurs à utiliser Policy Troubleshooter en cas d’échec d’accès et Logs Explorer pour tracer les activités d’administration (Admin Activity) et les accès aux données (Data Access).

9. Opérationnaliser le changement avec des prévisualisations et un déploiement par étapes

• Justification : La validation des effets des règles IAM et d’organisation avant leur application réduit les pannes.
• Action : Testez d’abord les règles IAM et d’organisation en non-production. Utilisez des exécutions à blanc (dry-runs) et la simulation de règles lorsque cela est possible. Pour l’automatisation du déploiement, mettez en œuvre des déploiements canary et des plans de retour en arrière.

Cette approche aboutit à une facturation et une visibilité des coûts centralisées, une administration SSH attribuable via OS Login, une gestion IAM basée sur le moindre privilège avec l’emprunt d’identité, des contrôles préventifs forts grâce aux règles d’organisation, ainsi qu’un audit et un dépannage robustes dans le nouvel environnement multi-projets.

Tous les domaines · Compute Engine et opérations sur les machines virtuelles →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Google →