0Pricing
Security+ Academy · Leçon

Identité cloud : rôles IAM et comptes de service

Configurez des rôles IAM et des comptes de service appliquant le moindre privilège sur les plateformes cloud, et évitez les erreurs courantes telles que les autorisations génériques et les clés à longue durée de vie.

Identité cloud : rôles IAM et comptes de service est une leçon Security+ Academy gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Security+ Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Security+ Academy comprend 4 leçons au total.

Principes fondamentaux de l’identité cloud

Dans les environnements cloud, l’identité constitue le nouveau périmètre. Chaque action — démarrer une VM, lire une base de données, appeler une API — est autorisée en fonction de l’identité appelante. Les systèmes IAM cloud (gestion des identités et des accès) définissent qui peut faire quoi sur quelles ressources. Contrairement aux environnements sur site, où l’emplacement réseau fournissait une confiance implicite, l’IAM cloud considère que chaque requête nécessite une autorisation explicite, quelle que soit son origine.

Utilisateurs, groupes et rôles dans AWS IAM

AWS IAM comporte trois principaux types d’identités. Les utilisateurs IAM représentent des personnes ou des applications individuelles disposant d’identifiants à long terme (clé d’accès et clé secrète). Les groupes IAM regroupent les utilisateurs et leur attribuent des permissions communes. Les rôles IAM sont des identités dotées d’identifiants temporaires qui peuvent être assumées par des utilisateurs, des services AWS (EC2, Lambda) ou d’autres comptes. Les rôles sont préférables aux clés d’accès à long terme, car leurs identifiants expirent automatiquement, ce qui réduit le risque d’exposition des identifiants.

# IAM role trust policy — allows EC2 to assume this role
{
  'Version': '2012-10-17',
  'Statement': [{
    'Effect': 'Allow',
    'Principal': { 'Service': 'ec2.amazonaws.com' },
    'Action': 'sts:AssumeRole'
  }]
}

# EC2 instance with this role attached can call AWS APIs
# using temporary credentials from the instance metadata service

Principe du moindre privilège dans les policies IAM

Les policies IAM définissent quelles actions une identité peut effectuer sur quelles ressources. Le principe du moindre privilège exige que les policies accordent uniquement les actions précises nécessaires à la tâche. Violations courantes : utiliser des caractères génériques * pour les actions (accorde toutes les actions d’un service), utiliser * pour les ressources (accorde l’accès à toutes les ressources) et associer des policies gérées trop larges comme AdministratorAccess à des comptes de service. Chaque caractère générique doit être justifié et régulièrement réexaminé.

# Overly permissive policy (AVOID)
{
  'Effect': 'Allow',
  'Action': 's3:*',      # all S3 actions
  'Resource': '*'         # all buckets
}

# Least-privilege policy (PREFERRED)
{
  'Effect': 'Allow',
  'Action': ['s3:GetObject', 's3:ListBucket'],
  'Resource': [
    'arn:aws:s3:::my-specific-bucket',
    'arn:aws:s3:::my-specific-bucket/*'
  ]
}

Comptes de service dans GCP

Dans Google Cloud Platform (GCP), les charges de travail non humaines s’authentifient à l’aide de comptes de service — des entités d’identité gérées utilisant des fichiers de clés JSON ou la fédération d’identités des charges de travail. Chaque compte de service doit respecter le principe du moindre privilège : liez-le uniquement aux services GCP qu’il doit appeler. Les clés des comptes de service (fichiers JSON téléchargés depuis la console) sont des identifiants à longue durée de vie qui doivent être traités comme des mots de passe : faites-les régulièrement tourner et ne les incluez jamais dans le code source ni ne les téléversez dans des dépôts publics.

# Check service account permissions (gcloud)
gcloud projects get-iam-policy my-project \
  --flatten='bindings[].members' \
  --format='table(bindings.role, bindings.members)' \
  --filter='bindings.members:serviceAccount'

# Prefer Workload Identity over service account keys
# (no downloadable key files — uses workload federation tokens)

Identités managées Azure

Les identités managées Azure (anciennement MSI) sont l’équivalent Azure des rôles IAM AWS pour les services — elles permettent aux ressources Azure (machines virtuelles, App Services, Functions) de s’authentifier auprès des API Azure sans stocker d’identifiants. Il en existe deux types : les identités managées attribuées au système sont liées à une ressource spécifique et supprimées lorsque celle-ci est supprimée. Les identités managées attribuées par l’utilisateur sont des objets autonomes qui peuvent être partagés entre plusieurs ressources. Les identités managées éliminent le besoin de stocker des clés ou des secrets.

# Azure CLI — assign managed identity to a VM
az vm identity assign \
  --name myVM \
  --resource-group myRG \
  --identities /subscriptions/.../userAssignedIdentities/myIdentity

# The VM can now call Azure Key Vault without any stored credentials:
# Token is fetched automatically from the Instance Metadata Service

Identifiants à longue durée de vie : le risque

Les identifiants à longue durée de vie — clés d’accès statiques, jetons d’API et fichiers de clés de comptes de service qui n’expirent jamais — comptent parmi les éléments les plus risqués des environnements cloud. S’ils sont divulgués (par l’intermédiaire de GitHub, d’un compartiment S3, de journaux ou d’un ordinateur portable de développeur compromis), ces identifiants accordent un accès immédiat jusqu’à leur révocation manuelle. Les organisations doivent : auditer tous les identifiants à longue durée de vie, les faire tourner selon un calendrier défini, privilégier l’accès basé sur les rôles ou fédéré qui produit des jetons à courte durée de vie, et déclencher immédiatement une alerte lorsque des identifiants apparaissent dans des dépôts publics.

# Find IAM access keys older than 90 days (AWS)
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | \
  base64 -d | grep -v 'N/A' | \
  awk -F',' '$10 > 90 {print $1, $10}'

# Keys older than 90 days should be rotated or deleted

Chaînage de rôles IAM et élévation de privilèges

L’élévation de privilèges IAM se produit lorsqu’une identité utilise une combinaison d’autorisations pour s’accorder des autorisations supplémentaires. Les chemins d’élévation classiques comprennent : associer une politique plus permissive à son propre utilisateur, créer un nouvel utilisateur IAM avec des autorisations élevées, transmettre un rôle (iam:PassRole) à un service et mettre à jour le rôle d’exécution d’une fonction Lambda. IAM Access Analyzer d’AWS peut détecter ces schémas, et les limites d’autorisations IAM peuvent plafonner strictement les autorisations maximales pouvant être accordées à toute identité.

# Dangerous permission combination (enables privilege escalation):
# iam:CreatePolicyVersion + iam:SetDefaultPolicyVersion
# Attacker can create a new policy version with AdministratorAccess

# Or: iam:PassRole + lambda:CreateFunction + lambda:InvokeFunction
# Attacker creates Lambda with a privileged role, invokes it

# Defense: permission boundaries limit maximum grantable permissions

Prise en charge de rôles entre comptes

Les organisations cloud utilisent souvent plusieurs comptes (développement, préproduction, production, sécurité) pour limiter le rayon d’impact. La prise en charge de rôles entre comptes permet aux identités d’un compte d’assumer des rôles dans un autre, ce qui permet aux outils centralisés d’opérer entre plusieurs comptes. Les contrôles de sécurité comprennent : exiger un External ID dans la politique de confiance afin d’empêcher les attaques par adjoint confus, limiter les comptes autorisés à assumer un rôle au moyen de l’ARN du Principal, et journaliser toutes les prises en charge de rôles entre comptes dans CloudTrail à des fins d’audit.

# Trust policy with External ID (confused deputy protection)
{
  'Effect': 'Allow',
  'Principal': { 'AWS': 'arn:aws:iam::PARTNER-ACCOUNT-ID:root' },
  'Action': 'sts:AssumeRole',
  'Condition': {
    'StringEquals': {
      'sts:ExternalId': 'unique-shared-secret-12345'
    }
  }
}

IMDS et sécurité du service de métadonnées

Les instances EC2 AWS peuvent récupérer les identifiants de leur rôle IAM depuis le Instance Metadata Service (IMDS) à l’adresse http://169.254.169.254. La catégorie de vulnérabilités SSRF est particulièrement dangereuse dans ce contexte : si une application est vulnérable aux SSRF, un attaquant peut exfiltrer les identifiants du rôle IAM de l’instance en faisant en sorte que le serveur récupère le contenu de l’URL IMDS. IMDSv2 (qui exige un jeton de session) atténue le vol d’identifiants fondé sur les SSRF et doit être imposé sur toutes les instances EC2.

# Enforce IMDSv2 on a new EC2 instance (requires token for IMDS)
aws ec2 run-instances \
  --metadata-options 'HttpTokens=required,HttpEndpoint=enabled' \
  ...

# IMDSv1 (insecure) just needs a GET request:
# curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# IMDSv2 requires a PUT to get a session token first

IAM Access Analyzer et examen des politiques

IAM Access Analyzer (AWS) identifie automatiquement les ressources partagées avec des principaux externes ainsi que les politiques IAM qui accordent davantage d’autorisations que prévu. Il analyse les politiques de compartiment, les politiques de confiance des rôles et les politiques de clés KMS afin de signaler les accès externes qui n’étaient pas explicitement prévus. Les examens réguliers des politiques IAM — manuels ou réalisés avec des outils tels que Cloudsplaining, PMapper ou Permissions Boundary Analyzer — sont essentiels pour identifier les chemins d’élévation de privilèges avant que les attaquants ne les trouvent.

Fédération des identités des charges de travail

La fédération des identités des charges de travail permet aux charges de travail externes (GitHub Actions, systèmes sur site, autres fournisseurs cloud) de s’authentifier auprès de l’IAM cloud à l’aide de jetons OIDC à courte durée de vie plutôt qu’avec des clés de comptes de service à longue durée de vie. Un flux de travail GitHub Actions peut assumer un rôle IAM AWS à l’aide de son jeton OIDC pendant la durée de la tâche, puis le jeton expire. Cette approche élimine toute la catégorie des fuites d’identifiants à longue durée de vie dans les pipelines CI/CD.

Vérification rapide

Testez votre compréhension des concepts de CompTIA Security+ (SY0-701) présentés dans cette leçon.

Récapitulatif de la leçon

Dans cette leçon, vous avez appris que : les rôles IAM fournissent des identifiants temporaires et sont préférables aux clés d’accès à longue durée de vie pour les charges de travail cloud, que les politiques appliquant le moindre privilège doivent éviter les caractères génériques et n’accorder que des actions précises sur des ressources précises, et que IMDSv2, les limites d’autorisations et la fédération des identités des charges de travail éliminent les voies courantes d’exposition des identifiants. Nous allons maintenant explorer la gestion de la posture de sécurité cloud (CSPM).

Questions Fréquemment Posées

La leçon « Identité cloud : rôles IAM et comptes de service » est-elle gratuite ?

Oui — le texte complet de « Identité cloud : rôles IAM et comptes de service » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Security+ Academy, passe à CoddyKit PRO. Le cours Security+ Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Identité cloud : rôles IAM et comptes de service » ?

Configurez des rôles IAM et des comptes de service appliquant le moindre privilège sur les plateformes cloud, et évitez les erreurs courantes telles que les autorisations génériques et les clés à lon… Tu pratiques Security+ Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Security+ Academy ?

Aucune expérience préalable n'est requise. Security+ Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.

Combien de temps prend la leçon « Identité cloud : rôles IAM et comptes de service » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Security+ Academy ?

Oui. Chaque leçon Security+ Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Modèle de responsabilité partagée : IaaS, PaaS et SaaS
  2. Sécurité du stockage cloud et risques d’exposition des données
  3. Identité cloud : rôles IAM et comptes de service
  4. Gestion de la posture de sécurité cloud (CSPM)
← Retour à Security+ Academy