Google PCA: Conception de l'organisation, IAM et gouvernance du cloud — Guide d'étude

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Architect — 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 conception de l’organisation, l’IAM et la gouvernance établissent la fondation sur laquelle reposent toutes les architectures Google Cloud. Une bonne conception crée des frontières administratives claires, minimise le rayon d’impact, met en œuvre le principe de moindre privilège, contrôle les coûts et permet une mise à l’échelle opérationnelle pour de nombreuses équipes et environnements. La gouvernance doit privilégier les garde-fous plutôt que les barrières : automatiser des configurations par défaut qui sont sécurisées, mesurables et réversibles, tout en déléguant le contrôle quotidien aux équipes les plus proches de la charge de travail (workload).

Hiérarchie des ressources et fondations de l’identité

Les ressources Google Cloud forment une arborescence stricte : Organisation → Dossiers (Folders) → Projets → Ressources (par exemple, des instances Compute Engine, des buckets). Les stratégies IAM et les contraintes de la stratégie d’organisation (Organization Policy) sont héritées le long de l’arborescence.

Principes de conception clés :

• Utiliser une seule Organisation pour centraliser la gouvernance. Créer des Dossiers (Folders) de premier niveau pour les principales frontières administratives (par exemple, les unités commerciales, les régions, ou la distinction entre réglementé et non réglementé).
• À l’intérieur de chaque frontière, créer des Dossiers d’environnement (prod, nonprod) pour appliquer des stratégies différenciées. Maintenir les projets centrés sur une charge de travail (workload-scoped) et éphémères lorsque c’est possible pour réduire le rayon d’impact et faciliter la refacturation.
• Héritage : les autorisations (allow grants) s’accumulent (union des liaisons d’autorisation des ancêtres et du nœud). Les stratégies de refus IAM (IAM Deny), si elles sont utilisées, prévalent et peuvent bloquer l’accès même si une autorisation existe. Éviter de placer des rôles larges en haut de l’arborescence ; le rayon d’impact est important et difficile à défaire.

Sources d’identité :

• Cloud Identity est le plan d’identité pour les employés (workforce). Intégrer avec votre IdP d’entreprise (SAML/OIDC) pour centraliser l’authentification et le cycle de vie des utilisateurs (arrivées, mobilités, départs). Utiliser Google Cloud Directory Sync pour la synchronisation des attributs et des groupes si nécessaire.
• Les groupes sont les principaux sujets (subjects) IAM. L’accès basé sur les groupes permet des changements à grande échelle et une propriété auditable. Utiliser un modèle de groupes de groupes (par exemple, net-admins, sec-admins, app-team-A) et restreindre qui peut gérer l’appartenance aux groupes.
• Les comptes de service (service accounts) représentent les charges de travail. Préférer l’emprunt d’identité de compte de service (impersonation) avec des identifiants éphémères plutôt que des clés stockées. Éviter les clés de compte de service gérées par l’utilisateur ; les traiter comme des exceptions avec des approbations strictes et une rotation.
• Modèles d’identité pour les charges de travail :
  • GKE Workload Identity lie les comptes de service Kubernetes aux comptes de service Google, éliminant ainsi les identifiants à l’échelle du nœud.
  • Workload Identity Federation permet aux identités externes (sur site, autres clouds, GitHub Actions) d’obtenir un accès Google éphémère sans clés. Utiliser le ciblage par pool/fournisseur (pool/provider scoping) et les conditions sur les attributs pour restreindre l’accès.

Modes d’échec courants et mesures d’atténuation :

• L’octroi de rôles primitifs (Owner/Editor/Viewer) au niveau du Dossier ou de l’Organisation conduit à un sur-privilège généralisé. N’utiliser que dans des projets d’accès d’urgence (break-glass) au périmètre très restreint.
• La prolifération de groupes avec une propriété peu claire compromet le principe de moindre privilège. Imposer des conventions de nommage, des tags de finalité et des métadonnées de propriétaire sur les groupes.
• Les comptes de service orphelins et les liaisons obsolètes accumulent les risques. Planifier des revues d’accès récurrentes et utiliser IAM Recommender pour réduire les permissions inutilisées.

Modèles IAM, rôles et opérations d’accès

Rôles et liaisons (bindings) :

• Les rôles prédéfinis sont conçus pour des services spécifiques et devraient être le choix par défaut.
• Les rôles personnalisés comblent les lacunes lorsque les rôles prédéfinis sont trop larges. Les construire à partir de l’ensemble minimal de permissions observées comme nécessaires ; les versionner et les tester.
• Les rôles de base (Viewer/Editor/Owner) sont hérités et trop larges. À éviter aux périmètres de l’Organisation et du Dossier. Ne pas utiliser le rôle Owner pour les opérations quotidiennes ; le réserver pour les accès d’urgence (break-glass) à la plateforme avec des contrôles compensatoires stricts.
• Les liaisons de rôles conditionnelles (IAM Conditions) limitent quand et où une liaison s’applique en utilisant des attributs tels que resource.name, resource.matchTag, request.time ou request.auth.audiences. Utiliser les conditions pour un accès limité dans le temps, un accès à la production basé sur des tags, ou des actions restreintes par emplacement.

Moindre privilège et élévation de privilèges :

• Séparer les responsabilités de « lecture », « opération » et « administration ». Par exemple, les équipes réseau, sécurité et applicatives obtiennent des rôles distincts sur des périmètres distincts.
• Utiliser l’élévation de privilèges juste-à-temps (just-in-time) avec des workflows Access Approval ou une automatisation basée sur des tickets pour lier des rôles limités dans le temps via des conditions.

Stratégies de refus (Deny) et risques associés :

• IAM Deny peut bloquer de manière centralisée des permissions risquées (par exemple, resourcemanager.projects.delete). Le refus (Deny) supplante l’autorisation (allow) et s’applique à toute la sous-arborescence. Valider minutieusement ; des stratégies de refus mal configurées peuvent bloquer l’automatisation ou interrompre les déploiements.

Auditabilité et revues :

• Activer les journaux d’activité d’administration (Admin Activity logs) au niveau de l’Organisation ; ils sont conservés 400 jours par défaut. Pour les services sensibles, activer les journaux d’accès aux données (Data Access logs) et les acheminer vers BigQuery pour une conservation et un audit à long terme.
• Mettre en œuvre des revues d’accès périodiques : énumérer les liaisons avec Cloud Asset Inventory, comparer aux registres de propriété, supprimer les rôles inutilisés suggérés par IAM Recommender et vérifier l’expiration des exceptions.

Exemple utile (liaison limitée dans le temps et par tag) :

undefined

Gouvernance financière et garde-fous des règles d’organisation

Architecture de facturation :

• Centraliser un ou plusieurs comptes de facturation sous la responsabilité du service financier. N’utiliser plusieurs comptes de facturation que lorsque cela est légalement ou opérationnellement requis (par exemple, entités distinctes ou modèles de revendeurs).
• Associer les projets aux comptes de facturation via l’automatisation ; ne pas autoriser l’association manuelle en dehors des workflows approuvés.

Refacturation et visibilité des coûts :

• Utiliser les libellés et les tags d’allocation des coûts de manière cohérente. Les libellés sont des métadonnées de forme libre pour le filtrage et le reporting ; les tags sont hiérarchiques et utilisables dans les conditions et les règles IAM. Activer l’allocation des coûts pour les tags sélectionnés afin qu’ils apparaissent dans les exportations de facturation.
• Exporter les données de facturation vers BigQuery pour l’analyse ; créer des tableaux de bord par propriétaire, centre de coûts et environnement. Exiger que chaque projet ait un propriétaire responsable et un budget.

Budgets et détection d’anomalies :

• Créer des budgets avec des alertes au niveau des dossiers (Folders) et des projets. Ajouter des réactions programmatiques (par exemple, notifier l’astreinte, ouvrir des tickets ou désactiver les nouvelles augmentations de quota) pour maîtriser les dépenses excessives.
• Utiliser les quotas et les engagements (CUDs) en adéquation avec l’utilisation prévue ; surveiller l’utilisation.

Contraintes des règles d’organisation (sécurisé par défaut) :

• Appliquer les garde-fous au niveau de l’organisation ou des dossiers (Folders) et ne les assouplir que lorsque cela est justifié. Contraintes courantes :
  • constraints/iam.disableServiceAccountKeyCreation = true
  • constraints/compute.requireOsLogin = true
  • constraints/compute.trustedImageProjects restreignant les images de VM
  • constraints/sql.restrictPublicIp = true
  • constraints/storage.uniformBucketLevelAccess = true
  • constraints/compute.disableSerialPortAccess = true
• Utiliser VPC Service Controls pour réduire le risque d’exfiltration de données pour les services pris en charge au sein de périmètres sensibles.

Gestion des exceptions aux règles :

• Les exceptions doivent pouvoir être demandées, approuvées, limitées dans le temps et auditables. Préférer les conditions IAM pour limiter la portée des exceptions par tag/heure. Réconcilier périodiquement les exceptions et les faire expirer automatiquement via des pipelines de policy-as-code.

Exemple de règle d’organisation (YAML) pour désactiver les clés de compte de service :

undefined

undefined

undefined

-

undefined

Puis appliquer :

undefined

Zones d’atterrissage, services partagés, automatisation et modèles opérationnels

Zone d’atterrissage (Landing zone) :

• Fournir un socle pré-sécurisé : Politiques d’organisation, récepteurs de journaux, stratégie CMEK, VPC partagés, DNS privé, Cloud NAT, Private Service Connect, projets d’audit et de sécurité, et catalogues d’images restreints.
• Séparer les projets hôtes par environnement pour le VPC partagé. Les administrateurs réseau contrôlent les projets hôtes ; les équipes applicatives déploient dans des projets de service rattachés au bon hôte.

Usine à projets :

• Automatiser la création de projets avec l’infrastructure-as-code. Créer des projets à la chaîne avec :
  • Placement dans le bon Dossier et liaison à la facturation
  • Groupes et rôles pré-associés
  • Comptes de service par défaut désactivés ou restreints
  • Récepteurs de journaux vers des projets centraux et des buckets de rétention
  • Budgets, libellés et tags prédéfinis
• Utiliser des modules Terraform ou Cloud Config Controller pour codifier l’usine. Appliquer la validation des politiques dans la CI avant d’appliquer les changements.

Services partagés et isolation :

• Centraliser l’identité, le réseau, la CI/CD, les registres d’artefacts et les outils de sécurité dans des projets dédiés. Isoler les environnements par Dossier et VPC ; bloquer les mouvements latéraux avec des politiques de pare-feu, des périmètres de service distincts et des trousseaux de clés Cloud KMS distincts par environnement.
• Utiliser Private Service Connect et des projets producteurs pour publier des services partagés pour les consommateurs sans exposer de points de terminaison publics.

Journalisation d’audit et automatisation de la gouvernance :

• Acheminer les journaux d’activité d’administration (Admin Activity) et d’accès aux données (Data Access) vers un projet d’audit. Configurer les buckets de journaux avec CMEK et des politiques de rétention conformes aux exigences de conformité.
• Utiliser les flux Cloud Asset Inventory vers Pub/Sub ainsi que Cloud Functions/Cloud Run pour détecter la dérive (par exemple, des buckets publics) et y remédier automatiquement ou ouvrir des tickets.
• Pile de politique en tant que code (Policy-as-code) :
  • Politiques d’organisation et IAM sous forme de code stockés dans un dépôt
  • Config Validator/Policy Controller pour les ressources KRM
  • Vérifications de politique pré-déploiement dans la CI/CD
  • Tâches de réconciliation planifiées pour réappliquer l’état désiré

Nommage des ressources et tags :

• Appliquer des conventions de nommage courtes et lisibles qui encodent l’environnement, l’application, la région et une séquence (par exemple, appA-prd-usw2-web-01). Réserver les tags pour la gouvernance (env=prod, pii=true, owner=team-x). Valider la présence des libellés/tags requis lors de la création du projet.

Opérations multi-équipes et administration déléguée :

• Établir des équipes plateforme, sécurité et réseau avec des périmètres et des rôles clairement définis. Déléguer l’administration au niveau du projet aux équipes applicatives à l’intérieur de la limite de leur Dossier. Fournir un libre-service encadré par des garde-fous via des catalogues et des modèles.
• Équilibrer l’autonomie et le risque en déléguant aux équipes les décisions à faible rayon d’impact et en centralisant les décisions qui affectent de nombreux projets ou l’infrastructure partagée.

Scénario de problème pratique

Contoso Retail prévoit d’intégrer huit équipes produit sur Google Cloud en trois mois. Chaque équipe a besoin d’environnements de production et de non-production, d’un réseau isolé, d’une journalisation de sécurité centralisée et d’une responsabilisation en matière de coûts. L’équipe plateforme doit empêcher la prolifération des clés de compte de service, restreindre les images de VM et permettre un accès avec élévation de privilèges limité dans le temps pour la réponse aux incidents.

Approche :

1. Établir la hiérarchie et les dossiers

• Créer des Dossiers de premier niveau pour les départements et des Dossiers imbriqués pour la production et la non-production. Justification : des limites administratives claires permettent des garde-fous et des budgets ciblés tout en autorisant l’administration déléguée aux équipes produit sans accorder de pouvoirs à l’échelle de l’organisation.

2. Déployer une zone d’atterrissage avec un VPC partagé

• Créer des projets hôtes pour les réseaux de production et de non-production gérés par l’équipe réseau. Rattacher les projets de service des équipes via le VPC partagé. Justification : centralise le routage, le NAT et la politique de pare-feu tout en isolant les charges de travail par projet ; empêche la mise en réseau ad hoc qui mène à la prolifération et à une sécurité incohérente.

3. Mettre en œuvre des garde-fous via les politiques d’organisation

• Appliquer des contraintes : désactiver la création de clés de compte de service, exiger OS Login, restreindre les adresses IP publiques pour Cloud SQL, limiter les images de VM aux projets de confiance et activer l’accès uniforme au niveau du bucket. Justification : une approche sécurisée par défaut réduit les erreurs de configuration fréquentes ; les exceptions peuvent être limitées dans le temps si nécessaire.

4. Mettre en place l’identité et les groupes

• Intégrer Cloud Identity avec l’IdP de l’entreprise ; créer des groupes pour les profils de développeur, d’opérateur et d’administrateur de chaque équipe, ainsi que des groupes au niveau de la plateforme pour les administrateurs réseau et sécurité. Justification : l’IAM basé sur les groupes est évolutif et s’aligne sur la séparation des tâches ; le cycle de vie suit les événements RH.

5. Définir l’IAM avec le moindre privilège et une élévation conditionnelle

• Associer des rôles prédéfinis à des groupes au niveau du Dossier ou du projet ; permettre l’élévation pour la réponse aux incidents via des liaisons conditionnelles limitées aux ressources taguées ‘prod’ et expirant après 24 heures. Justification : le moindre privilège pour les opérations quotidiennes, avec une escalade sûre et auditable en cas de besoin.

6. Construire un pipeline d’usine à projets

• Utiliser des modules Terraform pour créer des projets avec les libellés/tags requis (env, owner, cost-center), lier la facturation, rattacher au bon VPC partagé, créer des récepteurs de journaux vers un projet d’audit central et définir des budgets. Justification : un provisionnement cohérent et conforme à grande échelle élimine la dérive manuelle et accélère l’intégration.

7. Centraliser la journalisation d’audit et les revues d’accès

• Acheminer les journaux d’activité d’administration et d’accès aux données vers BigQuery avec CMEK ; planifier des requêtes mensuelles pour énumérer les liaisons IAM et les comparer à l’appartenance aux groupes et aux données de dernier accès de IAM Recommender. Justification : une piste d’audit durable et un ajustement continu des accès réduisent le risque et les coûts.

8. Gouvernance des coûts et alertes

• Activer les tags et libellés d’allocation des coûts, exporter les données de facturation vers BigQuery, et définir des budgets par Dossier et par projet avec des notifications pour les finances et les chefs d’équipe. Justification : une refacturation transparente favorise la responsabilisation ; des alertes précoces freinent les dépenses excessives.

9. Identité de charge de travail et automatisation sans clé

• Pour GKE, activer Workload Identity ; pour une CI externe (GitHub), configurer Workload Identity Federation avec une portée limitée à des dépôts spécifiques et avec des conditions. Justification : élimine les clés à longue durée de vie et contraint l’utilisation aux charges de travail prévues.

10. Processus d’exception et automatisation

• Mettre en œuvre un flux de demande qui crée des liaisons IAM conditionnelles ou des assouplissements de politique temporaires avec une expiration automatique via la CI. Justification : donne de l’autonomie aux équipes sans sacrifier le contrôle ; chaque exception est limitée dans le temps et auditable.

Résultats techniques :

• Les équipes créent de nouveaux projets en libre-service en moins de 15 minutes avec des paramètres par défaut conformes.
• Aucune clé de compte de service gérée par l’utilisateur n’est autorisée ; l’élévation pour la réponse aux incidents est limitée dans le temps et par tag.
• Les coûts sont consolidés par équipe et par environnement, avec des budgets automatisés et des alertes d’anomalie.
• Les journaux d’audit et les revues d’accès valident en continu que les permissions et les politiques correspondent à l’intention initiale.

Tous les domaines · Calcul →

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

Parcourir Google →