🔒 AWS IAM – Identity & Access Management

Le Jargon IAM (Indispensable)

Anatomie d'une Policy

Une Policy est une liste de "Statements". Voici la structure standard :

                            {
                            "Version": "2012-10-17",
                            "Statement": [
                            {
                            "Sid": "AllowS3Read",
                            "Effect": "Allow",
                            "Action": [
                            "s3:GetObject",
                            "s3:ListBucket"
                            ],
                            "Resource": [
                            "arn:aws:s3:::mon-bucket",
                            "arn:aws:s3:::mon-bucket/*"
                            ],
                            "Condition": {
                            "IpAddress": {
                            "aws:SourceIp": "192.0.2.0/24"
                            }
                            }
                            }
                            ]
                            }

L'Algorithme de Décision AWS

Quand une requête arrive, AWS évalue TOUTES les policies applicables (Identity-based, Resource-based, SCP, Boundaries). Voici l'ordre logique :

• 1. Explicit Deny : Si N'IMPORTE QUELLE policy dit "Effect": "Deny", c'est fini. Le refus l'emporte toujours. (C'est le "Veto").
• 2. Explicit Allow : S'il n'y a pas de Deny, AWS cherche au moins un "Effect": "Allow". Si trouvé, accès accordé.
• 3. Implicit Deny : Si rien n'est dit (ni Allow, ni Deny), c'est refusé par défaut.

IAM vs The World

IAM est le moteur interne, mais comment gérer vos utilisateurs humains ?

IAM Groups : La Gestion à l'échelle

N'attachez JAMAIS de Policy directement à un User ("Inline Policy"). C'est ingérable. Utilisez toujours des Groupes.

IAM Roles : L'Identité Temporaire

Un Rôle est un "chapeau" qu'on peut porter temporairement. Il n'a pas de mot de passe ni de clé permanente.

Le Compte Root : "Break Glass Only"

Checklist de sécurisation Root

• MFA Hardware : Utilisez une clé physique (YubiKey) stockée dans un coffre.
• Supprimer les Access Keys : Le root ne doit JAMAIS avoir de clés API.
• Pas d'usage quotidien : Ne l'utilisez que pour changer le plan de support ou récupérer un compte cassé.
• Alarme CloudWatch : Configurez une alerte SMS/Slack si le compte Root se connecte ("RootAccountUsage").

Types de Credentials (Identifiants)

Où stocker la Policy ?

Il existe trois façons d'attacher des droits. Le choix impacte la maintenabilité.

Le Flux de Décision : "Ai-je le droit ?"

Quand une requête arrive, AWS compile TOUTES les policies (SCP, Resource, Identity, Boundary).

Variables & Conditions : L'IAM Dynamique

Au lieu de créer 1000 policies pour 1000 utilisateurs, créez une seule policy générique avec des variables.

Permissions Boundaries : La "Laisse" pour Admin

Comment déléguer la création de Rôles à un développeur sans qu'il ne se crée un rôle "Admin" pour lui-même ?

Formule : Droits Effectifs = (Identity Policy) ∩ (Permissions Boundary).

MFA : Ne demandez pas, obligez !

Cycle de vie des clés (Hygiène)

Une clé de plus de 90 jours est une faille de sécurité.

S'authentifier en CLI comme un Pro

N'utilisez pas aws configure avec des Access Keys statiques. Utilisez SSO.

                            # 1. Configurer le profil
                            aws configure sso
                            > SSO start URL: https://my-org.awsapps.com/start
                            > SSO Region: us-east-1
                            > Account: Production
                            > Role: Developer

                            # 2. Se loguer (Ouvre le navigateur)
                            aws sso login --profile prod-dev

                            # 3. Utiliser (Valide 8h)
                            aws s3 ls --profile prod-dev

IAM Credential Report : L'Audit

Comment savoir qui n'a pas activé son MFA ou qui a une clé vieille de 3 ans ?

• Credential Report : Un fichier CSV téléchargeable qui liste tous les users, status du MFA, date de dernière rotation de mot de passe, et date de dernière utilisation des clés.
• Access Analyzer : Détecte les ressources (S3, KMS, Roles) qui sont accessibles publiquement ou depuis un autre compte AWS.

Service Roles : Donner des droits aux machines

Ne mettez jamais de clés d'accès (AKIA) en dur dans le code de vos applications. Utilisez des rôles.

Accès Cross-Account : Le Pattern "Jumphole"

Comment permettre à un développeur du compte A (Dev) d'accéder au S3 du compte B (Prod) ?

Fédération OIDC : GitHub Actions sans Clés !

En 2025, on ne stocke plus de AWS_ACCESS_KEY_ID dans les secrets GitHub. On utilise OIDC.

                            {
                            "Effect": "Allow",
                            "Principal": {
                            "Federated": "arn:aws:iam::123:oidc-provider/token.actions.githubusercontent.com"
                            },
                            "Action": "sts:AssumeRoleWithWebIdentity",
                            "Condition": {
                            "StringLike": {
                            "token.actions.githubusercontent.com:sub": "repo:mon-org/mon-repo:*"
                            }
                            }
                            }

Comment devenir quelqu'un d'autre (CLI)

Commande indispensable pour tester des droits ou accéder à la Prod.

L'Intersection des Droits

SCP n'accorde JAMAIS de permissions. C'est un filtre (Guardrail).
Pour qu'une action soit autorisée, elle doit être permise par la SCP ET par IAM.

Deny List vs Allow List

Il existe deux façons de configurer vos SCPs.

Les "Must-Have" en Production

1. Region Lock (Conformité RGPD)

Interdire de créer des ressources hors de l'Europe (sauf services globaux).

                    {
                    "Version": "2012-10-17",
                    "Statement": [
                    {
                    "Sid": "DenyOutsideEU",
                    "Effect": "Deny",
                    "NotAction": [
                    "iam:*", "route53:*", "cloudfront:*", "waf:*" // Services globaux exclus
                    ],
                    "Resource": "*",
                    "Condition": {
                    "StringNotEquals": {
                    "aws:RequestedRegion": [ "eu-west-1", "eu-west-3" ]
                    }
                    }
                    }
                    ]
                    }

2. Protection de l'Audit (Anti-Hacker)

Interdire la désactivation de CloudTrail ou Config, même pour un Admin.

Debugger un "Explicit Deny"

Quand une SCP bloque, le message d'erreur est souvent vague : "User is not authorized to perform: ec2:RunInstances with an explicit deny".

Le Casse-tête : Comment AWS décide ?

La logique change radicalement selon que l'accès se fait dans le même compte ou entre comptes différents.

Exemples S3 (JSON)

1. Accès Cross-Account (Le classique)

Autoriser le compte de "Prod" (111...) à lire le bucket de "Backup" (222...).

                    {
                    "Version": "2012-10-17",
                    "Statement": [
                    {
                    "Sid": "AllowProdAccount",
                    "Effect": "Allow",
                    "Principal": {
                    "AWS": "arn:aws:iam::111111111111:root" 
                    },
                    "Action": "s3:GetObject",
                    "Resource": "arn:aws:s3:::mon-bucket-backup/*"
                    }
                    ]
                    }

Note : Mettre ":root" délègue la gestion à l'admin IAM du compte 111. Il devra ensuite créer une IAM Policy pour ses users.

2. Force HTTPS (Sécurité)

Refuser toute connexion non chiffrée.

KMS : L'Exception qui confirme la règle

                            {
                            "Sid": "Enable IAM User Permissions",
                            "Effect": "Allow",
                            "Principal": {
                            "AWS": "arn:aws:iam::111122223333:root"
                            },
                            "Action": "kms:*",
                            "Resource": "*"
                            }

Pourquoi ? Cela permet de déléguer la gestion de la clé à IAM. Sans cette ligne, la Key Policy devient la seule source de vérité, et si vous vous en excluez, la clé est perdue (appel au support requis).

The Confused Deputy Problem

Un problème de sécurité critique quand un service AWS agit en votre nom.

Les 3 Variables Clés

Pour écrire du ABAC, il faut comprendre ces trois concepts :

La Policy "Magique"

Voici une policy qui permet à un développeur de démarrer/arrêter/modifier n'importe quelle ressource... SI et seulement SI elle lui appartient.

                    {
                    "Version": "2012-10-17",
                    "Statement": [
                    {
                    "Sid": "AccessSameProject",
                    "Effect": "Allow",
                    "Action": [ "ec2:StartInstances", "ec2:StopInstances" ],
                    "Resource": "*",
                    "Condition": {
                    "StringEquals": {
                    "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}",
                    "aws:ResourceTag/CostCenter": "${aws:PrincipalTag/CostCenter}"
                    }
                    }
                    }
                    ]
                    }

La Faille de Sécurité (et sa solution)

                            {
                            "Sid": "DenyCreateWithoutMyTags",
                            "Effect": "Deny",
                            "Action": "ec2:RunInstances",
                            "Resource": "arn:aws:ec2:*:*:instance/*",
                            "Condition": {
                            "StringNotEquals": {
                            "aws:RequestTag/Project": "${aws:PrincipalTag/Project}"
                            }
                            }
                            }

SSO & Session Tags : L'Industrialisation

Comment gérer les tags des utilisateurs s'ils viennent de l'Active Directory (AD) ou d'Okta ?

• Principe : Votre IdP (Identity Provider) envoie les attributs (Department, CostCenter) lors de l'authentification SAML/OIDC.
• Transitivité : AWS STS transforme ces attributs en Session Tags.
• Résultat : L'utilisateur arrive dans AWS avec ses tags déjà collés sur son front.

IAM Access Analyzer : La Preuve Mathématique

Ce n'est pas un simple scanner. Il utilise le "Raisonnement Automatisé" (méthodes formelles) pour prouver mathématiquement qui peut accéder à vos ressources.

Atteindre le "Moindre Privilège"

Comment savoir si un utilisateur a vraiment besoin des droits "Admin" qu'il vous réclame ?

IAM Policy Simulator : Debugger l'invisible

SecOps : Alertes Temps Réel (EventBridge)

N'attendez pas l'audit trimestriel. Soyez notifié sur Slack/Email 2 secondes après une action suspecte.

Pattern EventBridge : "Alerte Création Admin"

Architecture : CloudTrail -> EventBridge Rule -> SNS Topic -> Lambda (Slack) ou Email.

Le Principe du Moindre Privilège (Least Privilege)

C'est facile à dire, difficile à faire. Voici la méthode pragmatique.

IAM is Code (GitOps)

Ne cliquez jamais dans la console pour changer des droits en Prod. Traitez IAM comme du code applicatif.

Ceinture et Bretelles : SCPs Indispensables

Si vous utilisez AWS Organizations, appliquez ces SCPs sur vos comptes membres pour empêcher le pire.

1. Interdire de quitter la région (Region Lock)

2. Empêcher le Root User d'agir (Root Lock)

Cela oblige à utiliser des rôles IAM, même si on a le mot de passe root !

Faire le ménage (Hygiène)

Un environnement IAM sain est un environnement propre.