AWS vs GCP vs Azure : hiérarchie de l'organisation, IAM et gestion des clés, côte à côte

Si vous connaissez déjà le modèle de gouvernance d'un cloud, vous connaissez 80 % des deux autres — les concepts sont identiques et seul le vocabulaire change. Chaque cloud vous oblige à répondre aux trois mêmes questions avant de déployer quoi que ce soit de réel : comment organiser mes comptes, qui est autorisé à faire quoi, et comment mes clés de chiffrement sont-elles créées et contrôlées ? Cet article met en parallèle AWS, Google Cloud et Azure, couche par couche, et souligne les quatre points où l'analogie ne tient pas entièrement.

Ces quatre couches — hiérarchie, garde-fous, identité et gestion des clés — constituent également l'épine dorsale de chaque examen d'architecture et de sécurité cloud. Ainsi, la même lecture qui vous épargne une semaine de confusion inter-cloud représente la majeure partie du programme d'une certification. Les certifications pour approfondir chaque couche sont liées à la fin.

Les trois problèmes que chaque cloud résout

Au-delà du marketing, toute discussion sur la gouvernance se résume à trois couches superposées :

• Structure — un ensemble de conteneurs imbriqués (organisation → regroupement → limite de charge de travail) vous permettant d'isoler les environnements, d'appliquer des garde-fous et de répartir les coûts.
• Identité et permissions — quels principals peuvent effectuer quelles actions sur quelles ressources, ainsi que le plafond qui limite ce que toute attribution peut jamais accorder.
• Gestion des clés — où résident les clés cryptographiques, qui peut les utiliser, et qui peut les administrer — deux questions différentes que les gens confondent constamment.

La plupart des ingénieurs peuvent énumérer les éléments du cloud qu'ils connaissent le mieux. La difficulté réside dans la vue d'ensemble : les couches faciles à oublier et la façon dont chaque élément se traduit dans les deux autres clouds.

Couche 1 — la hiérarchie des ressources

Chaque cloud possède un nœud d'organisation de niveau supérieur, une couche de regroupement intermédiaire facultative que vous imbriquez pour les départements ou les environnements, et une limite de charge de travail qui sert également d'unité de facturation et de rayon d'impact (blast radius). Les politiques définies en haut se propagent vers le bas dans les trois clouds.

• Racine d'organisation — AWS : une Organization avec un management account. GCP : le nœud d'organisation. Azure : le management group racine du tenant, soutenu par un tenant Microsoft Entra.
• Conteneur de regroupement (imbricable) — AWS : Organizational Unit (OU). GCP : folder. Azure : management group.
• Limite de charge de travail et de facturation — AWS : account. GCP : project. Azure : subscription.
• Regroupement de ressources à l'intérieur de la limite — AWS : aucun (tags, ou par account). GCP : aucun — le project est le conteneur. Azure : le resource group, qui est obligatoire ; chaque ressource réside dans un seul.

La première divergence réelle se cache ici. Dans AWS, l'account est une cloison rigide — l'unité de blast radius par défaut — c'est pourquoi les grandes infrastructures AWS gèrent des dizaines, voire des centaines d'accounts. Dans GCP, le project remplit deux fonctions à la fois : il est à la fois l'unité de regroupement et l'unité de facturation/d'isolation, il n'y a donc pas de concept distinct de "resource group". Azure ajoute un quatrième niveau que les autres n'ont pas — le resource group — qui se trouve sous la subscription en tant que conteneur de cycle de vie que vous déployez et supprimez comme une seule unité.

Couche 2 — les garde-fous préventifs (le plafond des permissions)

Avant d'accorder quoi que ce soit à qui que ce soit, chaque cloud vous permet de définir une limite supérieure sur les permissions qui peuvent exister sous un nœud — un plafond qu'aucune attribution individuelle ne peut percer. Ce n'est pas la même chose qu'accorder un accès ; c'est la couche "vous ne pouvez jamais, à l'échelle de l'organisation".

• Plafond sur ce que les principals peuvent faire — AWS : Service Control Policy (SCP). GCP : Organization Policy constraints plus IAM deny policies. Azure : Azure Policy.
• Plafond sur qui peut toucher une ressource — AWS : Resource Control Policy (RCP). GCP : IAM allow/deny policies sur la ressource. Azure : Azure Policy plus deny assignments.
• Appliquer la configuration du service — AWS : politiques déclaratives. GCP : Organization Policy constraints. Azure : Azure Policy (deny / audit / deployIfNotExists).

AWS a divisé cette tâche en deux. Les SCP sont centrées sur les principals ("nos collaborateurs ne peuvent pas faire X") et les RCP, plus récentes, sont centrées sur les ressources ("personne — pas même un compte externe — ne peut toucher ce bucket S3, cette clé KMS ou ce rôle à moins d'appartenir à notre organisation"). Utilisées ensemble, elles comblent les lacunes qu'aucune ne couvre seule. Le piège : dans AWS et GCP, une SCP ou une Org Policy n'accorde jamais rien — elle ne fait que soustraire. Azure est câblé différemment, séparant clairement les RBAC (permissions) des Azure Policy (conformité et configuration), de sorte que la tâche de garde-fou appartient principalement à Azure Policy, tandis que "qui peut faire quoi" appartient entièrement aux RBAC.

Couche 3 — identité et permissions

Chaque cloud exprime une attribution comme le même triple — un principal, un rôle (un ensemble de permissions) et une portée (scope) — mais assemble les éléments différemment.

• Annuaire d'identités — AWS : IAM plus IAM Identity Center (SSO). GCP : Cloud Identity / Google Workspace plus IAM. Azure : Microsoft Entra ID.
• Ensemble de permissions (le "rôle") — AWS : une IAM policy, gérée ou inline. GCP : un IAM role — basic, prédéfini ou personnalisé. Azure : une RBAC role definition, intégrée ou personnalisée.
• L'attribution elle-même — AWS : une policy attachée à un user, group ou role. GCP : une IAM binding (member + role, éventuellement une condition) sur une ressource. Azure : un role assignment (principal + role + scope).
• Conditions et refus explicite — AWS : IAM condition keys et Deny explicite. GCP : IAM Conditions et deny policies. Azure : RBAC conditions et deny assignments.

La différence la plus profonde réside dans l'endroit où réside l'attribution. Dans AWS, vous attachez principalement la policy à l'identité — un role ou un user — et la permission voyage avec eux. Dans GCP, la politique d'autorisation (allow policy) s'attache à la ressource : vous attribuez le principal P au rôle R sur la ressource X, et elle est héritée le long de la hiérarchie. L'attribution de rôle (role assignment) d'Azure ressemble au binding de GCP mais s'ancre à une portée (scope) dans la chaîne management-group → subscription → resource-group → resource. Intégrez "AWS = attachée à l'identité, GCP et Azure = attachée à la ressource/portée" et une grande partie de la confusion inter-cloud disparaîtra.

Couche 3b — identité des charges de travail (la partie que les gens oublient)

Les humains ne sont pas les seuls principals. Votre code a également besoin d'une identité, et bien la configurer est le levier le plus important pour le moindre privilège (least privilege). La règle d'or partout : ne jamais déployer de clés statiques à longue durée de vie — attachez plutôt une managed identity à la charge de travail.

• Identité pour une charge de travail en cours d'exécution — AWS : un IAM role, assumé via instance profile, task role ou OIDC. GCP : un service account attaché à la ressource. Azure : une managed identity, system- ou user-assigned.
• Principal d'application / non-humain — AWS : IAM role. GCP : service account. Azure : service principal.
• Confiance sans clé depuis l'extérieur du cloud — AWS : IAM roles avec OIDC/SAML federation. GCP : Workload Identity Federation. Azure : workload identity federation.

Attention à la confusion de terminologie qui égare tout le monde : un "IAM role" dans AWS est une identité de charge de travail que vous assumez, tandis qu'un "role" dans GCP et Azure est seulement un ensemble de permissions — l'identité est un service account ou une managed identity. Même mot, deux fonctions différentes. Les clés de service account GCP et les secrets de service principal Azure existent toujours, mais les deux clouds poussent désormais fortement vers la fédération sans clé pour tout ce qui s'exécute en dehors de leur périmètre.

Couche 4 — gestion des clés

Enfin, le chiffrement. Chaque cloud dispose d'un service de gestion de clés (managed key service), organise les clés dans une petite hiérarchie et — surtout — sépare l'utilisation d'une clé (chiffrement/déchiffrement) de l'administration d'une clé (rotation, désactivation, définition de politique).

• Service — AWS : KMS, plus CloudHSM pour le matériel dédié. GCP : Cloud KMS, plus Cloud HSM / external. Azure : Key Vault, plus Managed HSM pour le matériel dédié.
• Organisation des clés — AWS : KMS keys (CMKs), aliases, multi-Region keys. GCP : key ring → key → key version. Azure : vault → key / secret / certificate.
• Contrôle d'accès — AWS : key policy + grants + IAM (les trois se combinent). GCP : Cloud KMS IAM bindings au niveau du project, du key-ring ou de la key. Azure : RBAC par défaut, ou politiques d'accès héritées par vault ; Managed HSM utilise son propre RBAC local.
• Séparation Utilisation vs. Administration — AWS : actions d'encrypt/decrypt vs. actions d'administration de clé (key-admin actions). GCP : cryptoKeyEncrypterDecrypter vs. admin roles. Azure : rôles de type "Crypto User" vs. "Crypto Officer".

Une particularité actuelle à connaître : pour les nouveaux Key Vaults sur les versions d'API récentes, Azure RBAC est désormais le modèle d'accès par défaut, et les anciennes politiques d'accès par vault sont le chemin hérité — ce qui aligne enfin Key Vault avec la façon dont le reste d'Azure gère les permissions. AWS reste l'exception : la key policy d'une clé KMS fait autorité et peut accorder l'accès indépendamment d'IAM, de sorte qu'un piège classique d'AWS est de se bloquer l'accès à une clé en modifiant IAM tout en oubliant la key policy. Dans GCP, l'accès KMS est un IAM ordinaire comme tout le reste.

Où le modèle mental échoue

Une correspondance trop nette est dangereuse si vous la prenez trop au pied de la lettre. Les quatre points où l'analogie ne tient pas :

• "IAM role" a deux significations différentes. Dans AWS, c'est une identité assumable ; dans GCP et Azure, un "role" n'est qu'un ensemble de permissions, l'identité étant séparée. Ne jamais le traduire mot à mot.
• AWS attache les permissions aux identités ; GCP et Azure les attachent aux ressources et aux portées (scopes). Votre instinct "où dois-je regarder pour auditer l'accès ?" doit s'inverser lorsque vous changez de cloud.
• Account, project et subscription n'ont pas le même rayon d'impact (blast radius). Un account AWS est une cloison solide ; un project GCP est à la fois une cloison, une facture et un regroupement ; une subscription Azure est principalement une limite de facturation et d'échelle, le resource group gérant le cycle de vie quotidien.
• Les garde-fous soustraient, les attributions ajoutent — sauf qu'Azure sépare les tâches. Les SCP et les Org Policies ne font que limiter les permissions ; Azure limite via Policy et attribue via RBAC comme deux systèmes distincts.

Le principe sous-jacent aux trois est le même : le moindre privilège (least privilege), appliqué par la structure. Placez les garde-fous en haut (org, OU, folder, management group), accordez des permissions restreintes et préférez les rôles aux clés statiques, et séparez "peut utiliser une clé" de "peut administrer une clé". Les noms changent d'un cloud à l'autre ; la discipline, elle, ne change pas.

Leçons pratiques

• Concevez la hiérarchie avant la première charge de travail. Rétrograder des accounts, projects ou subscriptions plus tard est douloureux dans tous les clouds.
• Définissez des plafonds élevés, accordez des permissions limitées. SCP/RCP, Org Policy ou Azure Policy en haut ; rôles spécifiques à la portée la plus étroite possible.
• Par défaut, utilisez les managed identities. IAM roles sur AWS, service accounts sur GCP, managed identities sur Azure — et la fédération sans clé pour tout ce qui traverse une limite de cloud.
• Considérez l'administration des clés comme privilégiée. Séparez l'encrypt/decrypt de la rotation/désactivation/définition de politique, et sur AWS, vérifiez toujours la key policy, pas seulement IAM.
• Si vous utilisez Terraform ou OpenTofu, ces primitives sont exactement ce que vous allez codifier — aws_organizations_*, google_folder, azurerm_management_group, et les ressources IAM/RBAC et KMS qui en dépendent.

Approfondissez chaque couche, par cloud

Les certifications d'architecture et de sécurité de chaque cloud sont entièrement basées sur la hiérarchie des ressources, IAM/RBAC et la gestion des clés. Si vous souhaitez les pratiquer avec de vraies questions d'examen, CertLabPro propose un parcours pour chacune :

• AWS — AWS Certified Solutions Architect – Associate (SAA-C03) pour la hiérarchie et IAM, et Security Specialty (SCS-C03) pour les SCP, RCP et KMS. Nouveau sur AWS ? Commencez avec Cloud Practitioner (CLF-C02).
• Google Cloud — Professional Cloud Architect pour l'organisation, les folders, les projects et IAM, et Professional Cloud Security Engineer pour les IAM deny policies, Org Policy et Cloud KMS.
• Azure — Solutions Architect Expert (AZ-305) pour les management groups et la gouvernance, et Security Engineer (AZ-500) pour RBAC, Azure Policy et Key Vault. Nouveau sur Azure ? Commencez avec Azure Fundamentals (AZ-900).

En résumé

AWS, Google Cloud et Azure ne sont pas aussi différents que leurs documentations le suggèrent. Chacun vous offre une hiérarchie pour organiser les comptes, un modèle d'identité basé sur le principal-rôle-portée (scope), une couche de garde-fou qui plafonne les permissions pouvant exister, et un service de clés qui sépare l'utilisation des clés de leur administration. Apprenez les quatre couches une fois pour toutes et la traduction inter-cloud est principalement une question de vocabulaire — et apprenez les quatre points où l'analogie ne tient pas, et vous éviterez les erreurs que ce vocabulaire dissimule. Ces fondamentaux sont exactement ce sur quoi les banques de questions de CertLabPro sont conçues pour s'exercer, à travers les trois clouds.