☁️ Architecture de Gouvernance AWS : Le Guide Complet
Cette synthèse regroupe les concepts clés de la gestion multi-comptes, de la sécurité des identités et de la conformité automatisée sur AWS.
🏗️ 1. Structure de l’Organisation (AWS Organizations)
AWS Organizations permet de gérer centralement plusieurs comptes au sein d’une structure hiérarchique.
Hiérarchie des Composants
-
Compte de Gestion (Management Account) : Le compte “Maître”. Il gère la facturation consolidée et la création/invitation de comptes. Il n’est jamais limité par les SCP.
-
Unités Organisationnelles (OU) : Conteneurs permettant de regrouper des comptes par environnement (Prod, Dev, Sécurité) ou par fonction. Les politiques appliquées à une OU sont héritées par tous les comptes et sous-OU qu’elle contient.
-
Comptes Membres : Comptes AWS standards hébergeant les ressources.
🛡️ 2. Contrôle et Garde-fous (SCP)
Les Service Control Policies (SCP) sont des politiques de contrôle centralisées qui définissent les permissions maximales pour une OU ou un compte.
-
Logique de Filtre : Une SCP ne donne pas de droits, elle restreint ce que même un administrateur peut faire dans un compte membre.
-
Priorité du DENY : Un
Explicit Deny(Refus explicite) l’emporte toujours sur n’importe quelAllow(Autorisation). -
Cible : Les SCP s’appliquent à tous les utilisateurs du compte, y compris l’utilisateur Root.
👤 3. Gestion des Identités (IAM & Fédération)
L’identité repose sur la confiance et l’usage de credentials éphémères via AWS STS.
IAM Identity Center (ex-SSO)
C’est le pont entre votre annuaire d’entreprise (Active Directory) et AWS.
-
Permission Sets : Modèles de droits assignés à des groupes AD sur des comptes spécifiques de l’organisation.
-
STS AssumeRole : Génère des jetons valides de 15 min à 12h, évitant l’usage de clés d’accès permanentes.
RBAC vs ABAC
-
RBAC (Role-Based) : Accès basé sur la fonction. Facile à auditer mais entraîne une “explosion” du nombre de rôles à mesure que l’entreprise grandit.
-
ABAC (Attribute-Based) : Accès basé sur les Tags. Un seul rôle “Développeur” peut donner accès à des milliers de ressources différentes si les tags (ex:
Project: Phoenix) correspondent entre l’utilisateur et la ressource.
📊 4. Conformité et Remédiation (Config & SSM)
La sécurité est un cycle continu de détection et de correction.
-
AWS Config : Le “radar”. Il surveille les changements de ressources et vérifie leur conformité par rapport à des règles (ex: “Buckets S3 privés uniquement”).
-
Agrégateur (Aggregator) : Collecte les données de conformité de tous les comptes et régions de l’organisation dans une vue unique.
-
AWS Systems Manager (SSM) : Le bras armé. Lorsqu’une règle Config est violée, un document SSM Automation peut être déclenché pour corriger automatiquement la ressource (ex: forcer le chiffrement).
🔄 5. Cycle de Vie et Transfert de Comptes
Déplacement (Move)
Déplacer un compte entre deux OU est instantané. Le compte perd immédiatement les SCP de l’ancienne OU et adopte celles de la nouvelle.
Transfert / Sortie (Standalone)
Pour qu’un compte quitte une organisation et devienne indépendant :
-
Root Account : Le compte doit avoir un mot de passe Root défini.
-
Facturation : Une méthode de paiement (carte bancaire) doit être ajoutée au compte.
-
Handshake : L’organisation libère le compte, et le compte accepte les conditions de sortie.
⚖️ 6. Algorithme de Décision Final
Lorsqu’une requête est effectuée, AWS vérifie la hiérarchie suivante :
Si un seul élément de cette chaîne contient un DENY, l’accès est refusé. Si aucun ALLOW n’est trouvé, l’accès est refusé par défaut.
💡 Aide-mémoire Obsidian
-
Tagging : Toujours taguer les comptes et ressources pour permettre l’ABAC.
-
Gouvernance : Déléguer l’administration de Config et GuardDuty à un compte de “Sécurité” dédié.
-
Prévention : Utiliser les SCP pour bloquer les régions non utilisées (ex:
eu-central-1uniquement).