AWS

Gouvernance et Gestion des User aws

☁️ 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

1. 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.

2. 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.

3. 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 quel Allow (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.

1. 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”).

2. Agrégateur (Aggregator) : Collecte les données de conformité de tous les comptes et régions de l’organisation dans une vue unique.

3. 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 :

1. Root Account : Le compte doit avoir un mot de passe Root défini.

2. Facturation : Une méthode de paiement (carte bancaire) doit être ajoutée au compte.

3. 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 :

$\text{Deˊcision}=(\text{SCP})\cap (\text{Permission Boundary})\cap (\text{IAM Policy})\cap (\text{Resource Policy})$

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-1 uniquement).

Link to original

Architecture Reseau multi compte

🌐 Architecture Réseau AWS : Connectivité, Partage et Gestion IP

1. Le Réseau Multi-Comptes : Connecter les VPC

Lorsque tu as des dizaines de VPC répartis dans plusieurs comptes, il faut les relier efficacement. Deux grands modèles s’affrontent.

Le VPC Peering (La connexion point à point)**

C’est la méthode la plus simple pour relier deux VPC, même s’ils sont dans des comptes ou des régions différentes.

• Le principe : Une connexion directe 1-à-1 entre un VPC A et un VPC B. Le trafic passe par le réseau privé d’AWS.

• La limite majeure (Pas de transitivité) : Si le VPC A est connecté au VPC B, et le VPC B est connecté au VPC C… Le VPC A ne peut pas communiquer avec le VPC C. Il faut créer une connexion Peering directement entre A et C.

• Le problème à l’échelle : Pour connecter tous les VPC entre eux (architecture “Full Mesh”), le nombre de connexions explose selon la formule mathématique $N(N-1)/2$ (où $N$ est le nombre de VPC). À 10 VPC, tu as déjà 45 connexions à gérer manuellement.

AWS Transit Gateway (Le routeur centralisé)**

C’est la solution moderne et évolutive pour le réseau multi-comptes.

• Le principe (Hub-and-Spoke) : Le Transit Gateway (TGW) agit comme un hub central. Tous tes VPC, tes VPN sur site, et tes connexions Direct Connect s’attachent au TGW.

• Routage centralisé : Le TGW possède des tables de routage. Il décide quel VPC peut parler à quel autre VPC, simplifiant drastiquement l’architecture.

• Support du multicast : Contrairement au VPC classique, le TGW supporte le trafic réseau Multicast.

---

2. Le Partage de Ressources : AWS RAM

Plutôt que de recréer les mêmes ressources dans chaque compte, AWS a créé un service dédié : AWS Resource Access Manager (RAM).

• Le rôle de RAM : Il permet à un compte AWS de partager des ressources spécifiques avec d’autres comptes de l’organisation.

• Intégration avec Organizations : Tu peux partager une ressource directement avec une Unité Organisationnelle (OU) entière. Si un nouveau compte rejoint cette OU, il reçoit automatiquement l’accès à la ressource partagée.

• Ce qu’on peut partager (Exemples clés) : Des sous-réseaux (Subnets), un Transit Gateway, des règles de pare-feu (Route 53 Resolver rules, Network Firewall policies), des licences (License Manager).

---

3. Le cas d’usage ultime : Le VPC Sharing

C’est une pratique de gouvernance très populaire, rendue possible par AWS RAM.

• Le concept : Un compte centralisé (ex: “Compte Network”) crée un grand VPC avec plusieurs sous-réseaux (Subnets). Il utilise AWS RAM pour partager certains sous-réseaux avec les comptes applicatifs (“Compte Dev A”, “Compte Dev B”).

• Séparation stricte des responsabilités (Separation of Duties) :

• L’équipe Réseau (Compte Network) : Gère le VPC, les plages d’adresses IP, les tables de routage, les passerelles (Internet Gateway, NAT) et les pare-feux (NACL).

• L’équipe Applicative (Comptes Dev) : Ne voit que le sous-réseau partagé. Elle peut y lancer ses instances EC2 ou bases de données RDS, et elle gère uniquement ses propres Security Groups (SG).

• L’avantage économique : Les ressources comme les NAT Gateways coûtent cher. En partageant le VPC, toutes les applications utilisent la même NAT Gateway gérée par le compte réseau, ce qui réduit considérablement la facture.

---

4. L’Overlapping IP : L’Ennemi du Réseau Multi-Comptes

L’overlapping se produit lorsque deux réseaux (VPC, ou un VPC et ton réseau sur site) utilisent la même plage d’adresses IP (le même bloc CIDR), par exemple 10.0.0.0/16.

Le problème de routage : Si une machine dans le VPC A (10.0.0.5) veut parler à une machine dans le VPC B (10.0.0.8) mais que les deux VPC utilisent la plage 10.0.0.0/16, le routeur est incapable de savoir si le paquet doit rester en local ou être envoyé vers l’autre VPC.

L’impact sur tes architectures AWS :

• VPC Peering : AWS bloque purement et simplement la création d’une connexion Peering si les blocs CIDR des deux VPC se chevauchent, même partiellement. C’est une impossibilité technique.

• Transit Gateway (TGW) : Le TGW te laissera attacher deux VPC avec des IP identiques, mais le routage entre eux sera impossible directement. Le trafic sera asymétrique ou se perdra.

• VPC Sharing : Comme tout se passe dans un seul grand VPC, l’overlapping est impossible par design (AWS empêche de créer deux Subnets avec la même plage dans un même VPC).

La solution de Gouvernance : AWS IPAM

Pour éviter que chaque équipe crée son VPC dans son coin avec le sempiternel 10.0.0.0/16, AWS propose un service dédié à la gouvernance réseau : Amazon VPC IP Address Manager (IPAM).

• Centralisation : IPAM s’intègre parfaitement avec AWS Organizations. Tu l’actives dans le compte réseau central.

• Pools d’adresses (IP Pools) : Tu définis ton méga-bloc d’IP d’entreprise (ex: 10.0.0.0/8), puis tu le découpes en sous-pools par région ou par environnement (Prod, Dev).

• Allocation automatisée : Quand un développeur crée un VPC, il ne tape plus d’adresse IP manuellement. Il demande simplement “Donne-moi un /24 depuis le pool de Dev”. IPAM lui attribue une plage unique, garantissant zéro chevauchement.

Comment faire quand l’overlapping est inévitable ? (Plan B)**

Parfois, tu n’as pas le choix (ex: ton entreprise rachète une autre entreprise qui a utilisé exactement les mêmes plages IP que toi).

• Private NAT Gateway : Tu peux utiliser des passerelles NAT privées pour faire de la traduction d’adresses (Network Address Translation). Les machines communiqueront via de fausses adresses IP qui seront traduites à la volée pour éviter le conflit. C’est complexe, coûteux, mais parfois indispensable.

---

💡 Aide-mémoire Obsidian (Réseau & IP)

• Peering vs TGW : Privilégier le VPC Peering pour 2 à 3 VPC isolés (coût très faible). Passer au Transit Gateway dès que l’architecture devient complexe ou nécessite du routage transitif.

• Limites de RAM : On ne partage jamais un VPC entier via RAM, on partage uniquement ses sous-réseaux (Subnets).

• Security Groups dans un VPC partagé : Bien qu’ils soient dans le même réseau, les comptes membres d’un VPC partagé ne peuvent pas se référencer mutuellement via l’ID de leurs Security Groups (à moins de faire des configurations spécifiques complexes).

• Transit Gateway inter-région : Pour connecter des régions (ex: Paris et Francfort), on crée un TGW dans chaque région, et on établit un “TGW Peering” entre les deux.

• Règle de base IP : Toujours planifier son adressage IP (Plan d’adressage) avant de créer des comptes et des VPC.

• Gouvernance IPAM : Utiliser AWS IPAM délégué à un compte “Network” pour automatiser la distribution des CIDR sans conflit à travers toute l’organisation.

• Taille des VPC : Ne jamais créer de VPC trop grands (comme des /16) si on n’a pas besoin de 65 536 IP. Préférer des /20 ou /24 pour économiser l’espace d’adressage.

• IPv6 : Si l’espace IPv4 vient à manquer ou que l’overlapping devient un cauchemar, le passage à IPv6 (qui offre une quantité quasi infinie d’adresses publiques uniques) est la recommandation d’AWS à long terme.

Link to original

Aws Vpc

🌐 La Bible du Réseau : Du Matériel Physique au Cloud AWS

Ce guide détaille comment les données circulent, sont protégées et routées, en comparant le monde traditionnel (On-Premise) et l’infrastructure moderne d’AWS.

---

1. Fondations : Le Matériel vs le Logiciel (SDN)

Pour comprendre AWS, il faut visualiser ce que le Cloud remplace.

L’Internet Gateway (IGW)

• Hors Cloud : Un Routeur de Bordure physique (Cisco/Juniper) dans une baie. Un câble fibre en sort pour aller chez l’opérateur. C’est un point de défaillance unique (si le boîtier grille, plus d’Internet).

• Sur AWS : Un service Software Defined Networking (SDN). C’est une porte logique redondante à l’échelle de la Région. Elle ne sature jamais et ne tombe pas en panne physiquement.

La Table de Routage

• Hors Cloud : Un fichier stocké dans la mémoire vive (RAM) d’un routeur. Le processeur du boîtier analyse chaque paquet pour l’envoyer vers le bon câble.

• Sur AWS : Une base de données de configuration. AWS injecte ces règles directement dans la carte réseau Nitro de chaque serveur physique. Le routage est fait à la “source” par le logiciel.

L’ENI (Elastic Network Interface)

C’est la carte réseau virtuelle. Chaque ressource (EC2, Lambda) en possède une pour avoir une IP privée, une adresse MAC et des Security Groups. On peut la détacher d’une instance pour la mettre sur une autre : l’identité réseau “suit” la carte.

---

2. Le NAT : Masquage et Gestion des Flux Sortants

Le NAT permet à des machines privées (sans IP publique) d’accéder à Internet.

Le Principe du PAT (Port Address Translation)

C’est le concept du “Plusieurs pour Un”.

• Mécanisme : Le NAT utilise les numéros de ports pour différencier les requêtes. (Ex: L’instance A utilise le port 10001, l’instance B le port 10002).

• NAT Instance (Legacy) : Une EC2 classique qui fait le job. Limitée par sa RAM/CPU. Si elle a trop de demandes, la table de ports sature et le réseau coupe.

• NAT Gateway (AWS) : Service managé surpuissant. Gère 55 000 connexions simultanées vers une destination unique. On peut ajouter jusqu’à 8 IPs pour monter à 440 000 connexions.

---

3. Sécurité : La Double Ligne de Défense (SG vs NACL)

Caractéristique	Security Group (SG)	Network ACL (NACL)
Niveau	L’Instance (ENI).	Le Subnet (le quartier).
État (Stateful)	OUI : Si le paquet entre, il sort d’office.	NON (Stateless) : Il faut autoriser l’aller ET le retour.
Type de règle	Uniquement “Allow” (Autoriser).	”Allow” ET “Deny” (Refuser).
Application	S’applique à la ressource.	S’applique à tout le sous-réseau.

---

4. Architectures Multi-VPC : Peering vs Hub & Spoke

VPC Peering (Le Maillage)

• Routage : Connexion directe 1-à-1. Pas de transitivité (Si A→B et B→C, alors A ne voit pas C).

• Internet : Chaque VPC possède sa propre IGW (1 sortie Internet par VPC).

Hub & Spoke (Transit Gateway)

• Routage : Un routeur central (Hub) où l’on branche tous les VPC (Spokes). Supporte la transitivité totale.

• Internet : Permet de centraliser la sortie Internet. Une seule IGW dans le Hub sert à tous les Spokes. Idéal pour l’inspection de sécurité centralisée.

---

5. Le VPN Site-to-Site (Hybride)

Connecte ton bureau physique à AWS via un tunnel chiffré sur Internet.

Mise en place technique :

1. CGW (Customer Gateway) : Tu enregistres l’IP publique de ton routeur de bureau dans AWS.

2. VGW (Virtual Private Gateway) : Tu crées cette “prise” VPN et tu l’attaches à ton VPC.

3. VPN Connection : Tu lies la CGW et la VGW. AWS te donne alors les IPs des tunnels et la clé de sécurité (PSK).

4. Routage : Tu ajoutes une route dans ton VPC : “Pour 192.168.1.0/24 (Bureau), vise la VGW”.

5. Configuration Physique : Tu configures ton routeur (Cisco, Fortinet) avec les paramètres d’AWS.

L’Encapsulation (La double enveloppe) :

Le paquet privé (10.x) est chiffré, puis mis dans une enveloppe publique adressée à l’IP de ton routeur. Internet ne voit que le trajet entre les deux routeurs, pas le contenu.

---

6. VPC Endpoints (Accès Privé aux Services AWS)

Pour parler à S3 ou SQS sans passer par Internet ni payer une NAT Gateway.

• Gateway Endpoint (S3, DynamoDB) : Gratuit. C’est juste une règle dans la Table de Routage.

• Interface Endpoint (PrivateLink) : Payant. AWS dépose une ENI (IP privée) dans ton subnet. Ton EC2 croit parler à un voisin local, mais elle parle directement au service AWS via le réseau interne (BackboError uploading file: net::ERR_NAME_NOT_RESOLVEDne).

---

💡 Aide-mémoire pour l’Architecte

• L’IGW est pour ce qui doit être vu.

• Le NAT est pour ce qui doit voir sans être vu.

• Le VPN est pour fusionner ton bureau et le Cloud.

• L’Endpoint est pour économiser de l’argent et rester 100% privé.

Link to original

🗼 AWS Control Tower : L’Orchestrateur de Gouvernance