Cheat Sheet AWS SAA-C03 – IAM

1. Concepts de base IAM

• IAM signifie Identity and Access Management.
• IAM permet de gérer :
  • Les identités
  • Les accès
  • Les permissions
  • Les droits des utilisateurs, groupes, rôles et services AWS
• IAM est un service global :
  • Il n’est pas lié à une région AWS spécifique.
  • Les utilisateurs, groupes, rôles et policies IAM s’appliquent globalement au compte.
• IAM est un service gratuit.
• IAM répond principalement à la question :
  • Qui peut faire quoi ?
  • Sur quelle ressource ?
  • Dans quelles conditions ?

2. Utilisateur Root

• L’utilisateur root est créé automatiquement à l’ouverture d’un compte AWS.
• Il possède un accès complet et illimité à tous les services et ressources AWS.
• Il ne doit pas être utilisé pour les tâches quotidiennes.
• Il doit être réservé aux actions critiques qui nécessitent réellement le compte root.

Bonnes pratiques pour le compte root

• Activer obligatoirement le MFA.
• Ne pas utiliser le compte root pour administrer AWS au quotidien.
• Ne jamais partager les identifiants root.
• Ne pas créer de clés d’accès pour le compte root.
• Supprimer les clés d’accès root si elles existent.
• Utiliser plutôt :
  • IAM Identity Center
  • Des utilisateurs IAM administrateurs
  • Des rôles IAM adaptés

Cas typiques nécessitant root

• Fermeture du compte AWS.
• Modification de certains paramètres critiques du compte.
• Certaines actions liées à la facturation.
• Certaines opérations de support ou de sécurité au niveau du compte.

3. Utilisateurs IAM

• Un utilisateur IAM représente une personne, une application ou un service.
• Un utilisateur IAM peut avoir :
  • Un accès à la console AWS avec mot de passe.
  • Un accès programmatique avec Access Key ID et Secret Access Key.
• Un utilisateur IAM n’a aucune permission par défaut.
• Les permissions doivent être accordées via des policies IAM.

Bonnes pratiques pour les utilisateurs IAM

• Créer un utilisateur nominatif par personne.
• Ne pas partager les identifiants IAM.
• Activer MFA pour les utilisateurs sensibles.
• Éviter les permissions excessives.
• Faire tourner régulièrement les clés d’accès.
• Supprimer les clés inutilisées.
• Préférer les rôles IAM aux clés d’accès statiques lorsque c’est possible.

4. Groupes IAM

• Un groupe IAM permet de regrouper plusieurs utilisateurs IAM.
• Un groupe sert à gérer les permissions de manière centralisée.
• Un groupe IAM peut contenir uniquement des utilisateurs.
• Un groupe ne peut pas contenir d’autres groupes.
• Un utilisateur IAM peut appartenir à plusieurs groupes.
• Les policies attachées à un groupe sont héritées par tous les utilisateurs du groupe.

Exemples de groupes IAM

• Administrators
• Developers
• ReadOnlyUsers
• BillingTeam
• DevOpsTeam

Bonnes pratiques pour les groupes

• Utiliser les groupes pour gérer les permissions des utilisateurs.
• Éviter d’attacher trop de policies directement aux utilisateurs.
• Créer les groupes selon les fonctions métier ou techniques.
• Appliquer le principe du moindre privilège à chaque groupe.

5. Policies IAM

• Une policy IAM est un document JSON décrivant des permissions.
• Elle définit :
  • Les actions autorisées ou refusées.
  • Les ressources concernées.
  • Les conditions éventuelles.
  • L’effet de la règle : Allow ou Deny.
• Une policy peut être attachée à :
  • Un utilisateur IAM
  • Un groupe IAM
  • Un rôle IAM

6. Types de policies IAM

AWS Managed Policies

• Policies créées et maintenues par AWS.
• Réutilisables sur plusieurs entités IAM.
• Pratiques pour démarrer rapidement.
• Peuvent être trop larges pour certains besoins de sécurité.
• Exemple :
  • AdministratorAccess
  • ReadOnlyAccess
  • AmazonS3ReadOnlyAccess

Customer Managed Policies

• Policies créées et gérées par vous.
• Réutilisables sur plusieurs utilisateurs, groupes ou rôles.
• Recommandées pour les environnements professionnels.
• Plus adaptées au principe du moindre privilège.

Inline Policies

• Policies attachées directement à une seule entité IAM.
• Non réutilisables.
• Supprimées lorsque l’entité IAM est supprimée.
• À utiliser uniquement pour des cas très spécifiques.

7. Structure d’une policy IAM JSON

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::mon-bucket/*",
      "Condition": {
        "StringEquals": {
          "aws:username": "alice"
        }
      }
    }
  ]
}

Champs importants à connaître

• Version
  • Version du langage de policy.
  • La valeur actuelle est généralement "2012-10-17".
• Statement
  • Bloc contenant une ou plusieurs règles de permission.
• Effect
  • Définit si la règle autorise ou refuse une action.
  • Valeurs possibles :
    • Allow
    • Deny
• Action
  • Définit les actions API concernées.
  • Exemple :
    • ec2:StartInstances
    • s3:GetObject
    • dynamodb:PutItem
• Resource
  • Définit les ressources concernées par la policy.
  • Exemple :
    • arn:aws:s3:::mon-bucket
    • arn:aws:s3:::mon-bucket/*
• Principal
  • Définit qui est concerné par la policy.
  • Souvent utilisé dans :
    • Les resource-based policies
    • Les trust policies des rôles IAM
  • Généralement absent dans les identity-based policies attachées à un utilisateur, groupe ou rôle.
• Condition
  • Permet d’ajouter une logique conditionnelle.
  • Exemples de conditions :
    • Adresse IP source
    • Utilisation de MFA
    • Tags
    • Heure
    • Région AWS
    • Nom d’utilisateur

8. Logique d’évaluation des permissions IAM

• Par défaut, tout est refusé.
• Une permission doit être explicitement autorisée par un Allow.
• Un Deny explicite est toujours prioritaire.
• La logique générale est :
  • Refus implicite par défaut
  • Autorisation explicite si une policy contient Allow
  • Refus explicite si une policy contient Deny
• Un Deny explicite l’emporte toujours sur un Allow.

À retenir pour l’examen

• Si aucune policy n’autorise une action, l’action est refusée.
• Si une policy autorise une action mais qu’une autre la refuse explicitement, l’action est refusée.
• Le Deny explicite est prioritaire dans tous les cas.

9. Principe du moindre privilège

• Le principe du moindre privilège consiste à accorder uniquement les permissions nécessaires.
• Il faut éviter :
  • Les permissions trop larges
  • Les wildcards inutiles
  • Les accès administrateur par défaut
  • Les policies attachées directement à trop d’utilisateurs
• Exemple à éviter :
  • Action: "*"
  • Resource: "*"
• À privilégier :
  • Des actions précises
  • Des ressources précises
  • Des conditions de sécurité
  • Des permissions temporaires lorsque possible

10. IAM Roles

• Un rôle IAM est une identité IAM sans identifiants permanents.
• Un rôle ne possède pas de mot de passe ni de clés d’accès statiques.
• Un rôle est assumé temporairement par :
  • Un service AWS
  • Un utilisateur IAM
  • Un utilisateur fédéré
  • Un compte AWS externe
• Les permissions sont fournies via des credentials temporaires.

Cas d’usage des rôles IAM

• Autoriser une instance EC2 à accéder à un bucket S3.
• Autoriser une fonction Lambda à écrire dans CloudWatch Logs.
• Autoriser ECS Task à accéder à Amazon ECR ou DynamoDB.
• Accorder un accès cross-account.
• Accorder un accès temporaire à un prestataire.
• Permettre l’accès via fédération d’identité.

Exemple classique à l’examen

• Besoin : une instance EC2 doit lire des objets dans S3.
• Mauvaise solution :
  • Stocker des access keys sur l’instance EC2.
• Bonne solution :
  • Créer un rôle IAM avec les permissions S3 nécessaires.
  • Attacher le rôle IAM à l’instance EC2 via un instance profile.

11. Trust Policy

• Une trust policy définit qui peut assumer un rôle IAM.
• Elle est utilisée avec les rôles IAM.
• Elle contient généralement :
  • Un Principal
  • Une action sts:AssumeRole
• Elle ne définit pas ce que le rôle peut faire.
• Elle définit uniquement qui peut utiliser le rôle.

Exemple simplifié de trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

12. AWS STS

• STS signifie Security Token Service.
• STS permet de générer des identifiants temporaires.
• Les credentials temporaires ont une durée limitée.
• STS est utilisé avec :
  • Les rôles IAM
  • Le cross-account access
  • La fédération d’identité
  • IAM Identity Center
  • Les accès temporaires à des prestataires

À retenir pour l’examen

• Pour un accès temporaire, penser à :
  • IAM Role
  • STS
  • AssumeRole
• Ne pas créer d’utilisateur IAM permanent pour un prestataire temporaire.
• Ne pas partager de clés d’accès longues durées.

13. MFA

• MFA signifie Multi-Factor Authentication.
• MFA ajoute un second facteur d’authentification.
• MFA est fortement recommandé pour tous les utilisateurs.
• MFA est indispensable pour le compte root.
• Types de MFA :
  • Application virtuelle MFA
  • Clé de sécurité matérielle
  • Token hardware

Cas d’usage des conditions MFA

• Il est possible d’exiger MFA dans une policy IAM.
• Exemple :
  • Autoriser certaines actions sensibles uniquement si MFA est activé.
• Condition fréquente :
  • aws:MultiFactorAuthPresent

14. IAM Access Analyzer

• IAM Access Analyzer permet d’identifier les ressources accessibles depuis l’extérieur.
• Il détecte les accès accordés à :
  • Internet
  • D’autres comptes AWS
  • Une organisation AWS Organizations
  • Des identités externes
• Il est utile pour :
  • La sécurité
  • La conformité
  • L’audit
  • La détection d’expositions involontaires

À retenir pour l’examen

• Si une question parle d’analyse des accès externes ou publics, penser à IAM Access Analyzer.
• Il aide à identifier les permissions trop larges sur les ressources.

15. IAM Policy Simulator

• IAM Policy Simulator permet de tester les policies IAM.
• Il permet de vérifier si une action est autorisée ou refusée.
• Il est utile avant de déployer une policy en production.
• Il aide à comprendre pourquoi une permission est accordée ou refusée.

À retenir pour l’examen

• Pour tester une policy IAM avant application ou diagnostiquer une permission, penser à IAM Policy Simulator.

16. Identity-Based Policies et Resource-Based Policies

Identity-Based Policies

• Attachées à une identité IAM :
  • Utilisateur
  • Groupe
  • Rôle
• Définissent ce que l’identité peut faire.
• Exemple :
  • Un rôle IAM peut lire les objets d’un bucket S3.

Resource-Based Policies

• Attachées directement à une ressource AWS.
• Définissent qui peut accéder à cette ressource.
• Exemples :
  • S3 Bucket Policy
  • KMS Key Policy
  • SQS Queue Policy
  • SNS Topic Policy
  • Lambda Resource-Based Policy

À retenir pour l’examen

• Une policy attachée à un utilisateur, groupe ou rôle est une identity-based policy.
• Une policy attachée à un bucket S3 est une resource-based policy.
• Les resource-based policies utilisent souvent le champ Principal.

17. Permissions Boundary

• Une permissions boundary définit la permission maximale qu’une identité IAM peut obtenir.
• Elle ne donne pas de permissions à elle seule.
• Elle limite seulement les permissions effectives.
• Même si une policy autorise une action, cette action doit aussi être permise par la permissions boundary.

Cas d’usage

• Déléguer la création d’utilisateurs ou de rôles à une équipe sans leur permettre d’accorder n’importe quelles permissions.
• Limiter les permissions maximales des développeurs.
• Encadrer les rôles créés par des équipes applicatives.

À retenir pour l’examen

• Une permissions boundary ne remplace pas une policy IAM.
• Elle agit comme une limite maximale.
• Elle est utile pour la délégation sécurisée.

18. Service Control Policies

• Les Service Control Policies, ou SCP, sont utilisées avec AWS Organizations.
• Elles permettent de définir les permissions maximales au niveau :
  • D’un compte AWS
  • D’une Organizational Unit
  • D’une organisation
• Une SCP ne donne pas de permissions.
• Elle limite ce que les comptes peuvent faire.
• Même un administrateur du compte est limité par les SCP.

À retenir pour l’examen

• Pour limiter les permissions sur plusieurs comptes AWS, penser à AWS Organizations et SCP.
• Une SCP définit une limite maximale.
• Elle ne s’applique pas directement aux utilisateurs du compte de management de la même manière qu’aux comptes membres.
• Une action doit être autorisée par IAM et non bloquée par une SCP.

19. Session Policies

• Une session policy limite les permissions d’une session temporaire.
• Elle est utilisée lors de l’assumation d’un rôle ou d’une fédération.
• Elle ne donne pas de permissions supplémentaires.
• Elle restreint les permissions de la session.

À retenir pour l’examen

• Les session policies sont utiles pour réduire temporairement les permissions.
• Elles fonctionnent avec STS et les credentials temporaires.

20. IAM Identity Center

• IAM Identity Center est le service recommandé pour gérer l’accès centralisé aux comptes AWS.
• Il remplace l’ancien nom AWS Single Sign-On.
• Il permet :
  • L’accès SSO à plusieurs comptes AWS
  • L’intégration avec des fournisseurs d’identité externes
  • La gestion centralisée des utilisateurs et groupes
  • L’attribution de permission sets
• Il est particulièrement important dans les architectures multi-comptes.

À retenir pour l’examen

• Pour un accès centralisé à plusieurs comptes AWS, penser à IAM Identity Center.
• Pour intégrer AWS avec un fournisseur d’identité d’entreprise, penser à fédération d’identité ou IAM Identity Center.
• Pour éviter la gestion d’utilisateurs IAM dans chaque compte, utiliser IAM Identity Center.

21. Access Keys

• Les access keys permettent l’accès programmatique à AWS.
• Elles sont composées de :
  • Access Key ID
  • Secret Access Key
• Elles sont utilisées avec :
  • AWS CLI
  • SDK AWS
  • APIs AWS
• Elles ne doivent pas être partagées.
• Elles ne doivent pas être stockées en clair dans du code source.

Bonnes pratiques

• Faire tourner les clés régulièrement.
• Supprimer les clés inutilisées.
• Ne jamais utiliser de clés root.
• Ne jamais commiter des clés dans Git.
• Utiliser IAM Roles pour les workloads AWS.
• Utiliser des secrets managers ou mécanismes sécurisés si nécessaire.

22. Tags IAM et conditions

• Les tags peuvent être utilisés pour contrôler les permissions.
• Ils permettent de mettre en place de l’ABAC.
• ABAC signifie Attribute-Based Access Control.
• L’accès est accordé selon les attributs, par exemple :
  • Tags utilisateur
  • Tags ressource
  • Tags de session

Exemple de logique ABAC

• Un utilisateur avec le tag Department=Finance peut accéder uniquement aux ressources avec le tag Department=Finance.

À retenir pour l’examen

• Si une question parle de permissions dynamiques basées sur des tags, penser à ABAC.
• ABAC est utile à grande échelle pour réduire le nombre de policies à maintenir.

23. IAM Credential Report

• IAM Credential Report fournit un rapport sur les identifiants IAM du compte.
• Il permet de voir :
  • Les utilisateurs IAM
  • L’état MFA
  • L’âge des mots de passe
  • L’âge des access keys
  • La dernière utilisation des identifiants
• Il est utile pour l’audit et la sécurité.

À retenir pour l’examen

• Pour auditer les utilisateurs IAM et leurs credentials, penser à IAM Credential Report.

24. Access Advisor

• IAM Access Advisor montre les services utilisés récemment par une identité IAM.
• Il aide à identifier les permissions inutilisées.
• Il est utile pour réduire les permissions et appliquer le moindre privilège.

À retenir pour l’examen

• Pour savoir quelles permissions peuvent être retirées, penser à Access Advisor.
• Pour auditer les credentials, penser à Credential Report.

25. Bonnes pratiques IAM à retenir

• Ne pas utiliser l’utilisateur root pour les tâches quotidiennes.
• Activer MFA sur root.
• Activer MFA pour les utilisateurs sensibles.
• Appliquer le principe du moindre privilège.
• Utiliser des groupes pour gérer les utilisateurs.
• Utiliser des rôles IAM pour les services AWS.
• Éviter les access keys longues durées.
• Faire tourner régulièrement les clés d’accès.
• Supprimer les utilisateurs, rôles et clés inutilisés.
• Utiliser IAM Access Analyzer pour détecter les accès externes.
• Utiliser IAM Policy Simulator pour tester les policies.
• Utiliser IAM Identity Center pour l’accès multi-comptes.
• Préférer les customer managed policies aux inline policies pour la réutilisabilité.
• Utiliser des conditions IAM pour renforcer la sécurité.
• Ne jamais stocker de secrets dans le code source.

26. Cas d’examen typiques AWS SAA-C03

EC2 doit accéder à S3

• Mauvaise réponse :
  • Stocker une access key sur l’instance EC2.
• Bonne réponse :
  • Créer un rôle IAM.
  • Attacher une policy S3 au rôle.
  • Associer le rôle à l’instance EC2.

Lambda doit écrire dans CloudWatch Logs

• Créer un rôle d’exécution Lambda.
• Ajouter les permissions nécessaires pour CloudWatch Logs.
• Attacher le rôle à la fonction Lambda.

Un prestataire externe a besoin d’un accès temporaire

• Ne pas créer d’utilisateur IAM permanent.
• Créer un rôle IAM.
• Utiliser STS AssumeRole.
• Ajouter une trust policy appropriée.
• Limiter les permissions au strict nécessaire.

Une entreprise utilise plusieurs comptes AWS

• Utiliser AWS Organizations.
• Utiliser IAM Identity Center pour l’accès centralisé.
• Utiliser des SCP pour limiter les permissions maximales.
• Éviter de créer des utilisateurs IAM séparés dans chaque compte.

Une ressource est exposée publiquement par erreur

• Utiliser IAM Access Analyzer.
• Vérifier les resource-based policies.
• Vérifier les bucket policies S3.
• Corriger les principals trop larges comme "Principal": "*".

Une équipe doit créer des rôles mais ne doit pas pouvoir devenir admin

• Utiliser une permissions boundary.
• Définir les permissions maximales autorisées.
• Autoriser la création de rôles uniquement dans cette limite.

Une action doit être autorisée uniquement avec MFA

• Ajouter une condition IAM basée sur MFA.
• Utiliser la clé de condition :
  • aws:MultiFactorAuthPresent

27. Pièges fréquents à l’examen

• IAM est global, pas régional.
• Les utilisateurs IAM n’ont aucune permission par défaut.
• Le compte root a tous les droits et doit être protégé par MFA.
• Un groupe IAM ne peut pas contenir un autre groupe.
• Un rôle IAM ne possède pas d’identifiants permanents.
• Un rôle IAM est la meilleure option pour donner des permissions à un service AWS.
• Un Deny explicite l’emporte toujours sur un Allow.
• Une permissions boundary ne donne pas de permissions.
• Une SCP ne donne pas de permissions.
• Une session policy ne donne pas de permissions.
• STS fournit des credentials temporaires.
• Les resource-based policies utilisent souvent le champ Principal.
• Les identity-based policies n’utilisent généralement pas le champ Principal.
• Pour un accès multi-comptes centralisé, privilégier IAM Identity Center.
• Pour auditer les accès externes, utiliser IAM Access Analyzer.
• Pour tester une policy, utiliser IAM Policy Simulator.

28. Résumé ultra-rapide

• IAM est le service AWS de gestion des identités et permissions.
• Root doit être protégé par MFA et peu utilisé.
• Les utilisateurs IAM représentent des personnes ou workloads spécifiques.
• Les groupes simplifient la gestion des permissions des utilisateurs.
• Les policies définissent les permissions.
• Les rôles IAM donnent des permissions temporaires sans credentials permanents.
• STS fournit des identifiants temporaires.
• MFA renforce l’authentification.
• Le moindre privilège est une règle fondamentale.
• IAM Access Analyzer détecte les accès externes.
• IAM Policy Simulator teste les permissions.
• IAM Identity Center est recommandé pour le SSO et les accès multi-comptes.
• SCP, permissions boundaries et session policies limitent les permissions maximales mais ne donnent pas de permissions.