Amazon DVA-C02: Sécurité, IAM, KMS et Gestion des secrets (Cognito, Secrets Manager, SSM) — Guide d'étude

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Fait partie du AWS Developer Associate DVA-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

IAM, Rôles, Politiques et Accès Inter-comptes

La gestion des identités et des accès doit être conçue autour du moindre privilège, d’informations d’identification à courte durée de vie et d’une séparation claire entre les identités de service et humaines. Pour les applications s’exécutant sur EC2, ECS ou Lambda, préférez les rôles d’instance/de tâche/de fonction plutôt que d’intégrer des clés d’accès ; les SDK AWS utilisent automatiquement la chaîne de fournisseurs d’informations d’identification fournie par l’environnement et actualisent les informations d’identification temporaires. L’accès inter-comptes doit utiliser AWS STS AssumeRole (API : sts:AssumeRole) avec une politique d’approbation de rôle explicite dans le compte cible et une politique IAM dans le compte appelant qui limite les ARN de rôle pouvant être assumés. Lorsque vous exigez l’authentification multifacteur (MFA) pour les opérations sensibles, appliquez-la avec une condition dans la politique de rôle ou de ressource en utilisant aws:MultiFactorAuthPresent ou exigez sts:GetSessionToken pour les utilisateurs humains. Pour les clients web ou mobiles, utilisez AssumeRoleWithWebIdentity (sts:AssumeRoleWithWebIdentity) via Cognito Identity ou des fournisseurs fédérés pour éviter les informations d’identification à long terme. Méfiez-vous des pièges courants : des actions/ressources génériques (wildcard) trop permissives, se fier aux politiques basées sur les ressources sans conditions de principal correspondantes, et oublier d’inclure les conditions SourceAccount ou aws:SourceVpc pour l’accès inter-comptes à S3 ou KMS. Utilisez le simulateur de politique IAM et sts:GetCallerIdentity pour le débogage. Envisagez d’utiliser des politiques de contrôle de service (SCP) au niveau de l’organisation pour appliquer des garde-fous et un refus explicite pour les actions à risque comme kms:CreateGrant ou iam:CreateAccessKey le cas échéant.

KMS, Modèles de Chiffrement et Contrôle d’Accès aux Clés

Utilisez AWS KMS pour le chiffrement d’enveloppe : GenerateDataKey/GenerateDataKeyWithoutPlaintext pour produire une clé de données pour le chiffrement côté client ou côté serveur, puis appelez Encrypt/Decrypt pour les petites charges utiles (payloads) ou utilisez la clé de données pour le chiffrement en masse. Choisissez la bonne CMK : détenue par AWS pour la commodité, gérée par AWS (aws/*) pour l’intégration de services, ou gérée par le client pour un contrôle total et une rotation complète. Les politiques de clé sont le contrôle principal pour KMS ; attachez des politiques IAM qui autorisent kms:Decrypt, kms:Encrypt et utilisez des grants lorsque vous avez besoin d’une utilisation de clé temporaire et déléguée pour des services comme les opérations s’appuyant sur CloudHSM ou l’invocation Lambda inter-comptes. Incluez un EncryptionContext pour lier le texte chiffré au contexte d’utilisation et exigez-le via une condition kms:EncryptionContextEquals pour une assurance supérieure. L’utilisation de KMS inter-comptes nécessite des entrées explicites dans la politique de clé accordant des permissions au principal ou au rôle externe et, dans certains cas, les permissions CreateGrant/RetireGrant. Pour l’audit et l’analyse forensique, activez les événements de données CloudTrail pour KMS et S3 afin de capturer les appels GenerateDataKey et Decrypt ; les journaux CloudTrail incluront arn:aws:kms et des détails sur le principal qui a utilisé la clé. Les pièges courants incluent l’oubli d’autoriser kms:CreateGrant pour les services qui utilisent des grants en arrière-plan, le fait de ne pas effectuer la rotation des clés gérées par le client, et de supposer que les politiques IAM seules peuvent autoriser les opérations KMS sans les entrées appropriées dans la politique de clé.

Gestion des Secrets : Secrets Manager vs Parameter Store

Secrets Manager et Systems Manager Parameter Store fournissent tous deux un stockage de secrets chiffrés mais diffèrent par leurs fonctionnalités et leur profil de coût : Secrets Manager prend en charge la rotation automatique (avec des modèles de rotation Lambda), le versionnage intégré et la réplication intégrée, et facture par secret ; Parameter Store (SecureString) est dans le niveau gratuit (free-tier) pour de nombreux paramètres et est meilleur pour une configuration simple. L’accès est contrôlé par des politiques IAM accordant secretsmanager:GetSecretValue ou ssm:GetParameter avec WithDecryption=true, et la clé KMS sous-jacente doit autoriser le déchiffrement pour le principal. Utilisez des politiques basées sur les ressources sur Secrets Manager pour les secrets inter-comptes, ou la réplication avec la réplication de secrets. Lorsque vous utilisez les SDK, appelez

undefined

et évitez de journaliser les valeurs des secrets ; définissez les variables d’environnement Lambda pour utiliser des références à Secrets Manager ou Parameter Store avec une résolution dynamique dans CloudFormation ou SAM, ou utilisez une récupération via le SDK au démarrage. Les erreurs courantes des développeurs incluent le stockage de secrets en texte clair dans le contrôle de code source, le fait de se fier aux variables d’environnement Lambda pour des données très sensibles sans protection KMS, et des politiques IAM trop permissives telles que l’octroi de secretsmanager:* à des rôles étendus. Pour la rotation, assurez-vous que la Lambda de rotation dispose des permissions correctes secretsmanager:RotateSecret et kms:GenerateDataKey et que le code de l’application peut réinitialiser les connexions de manière transparente lorsque les informations d’identification changent.

Authentification, autorisation et intégration d’API avec Cognito

Amazon Cognito fournit des pools d’utilisateurs (user pools) pour l’authentification et des pools d’identités (identity pools) pour les identifiants AWS temporaires. Utilisez les Cognito User Pools pour gérer l’inscription, l’authentification multifacteur (MFA) et l’émission de JWT (jetons d’ID, d’accès et de rafraîchissement). Les applications monopages (SPA) basées sur un navigateur doivent utiliser des clients d’application sans secret client et devraient utiliser l’interface utilisateur hébergée ou le SDK Amazon Cognito (amazon-cognito-identity-js) qui implémente le flux SRP pour éviter d’exposer les mots de passe. Vérifiez les JWT sur le serveur ou sur API Gateway en récupérant l’URI JWKS depuis le pool d’utilisateurs et en validant la signature, l’émetteur (issuer), l’audience (aud) et l’expiration du jeton ; les autorisateurs JWT d’API Gateway ou les autorisateurs personnalisés Lambda peuvent effectuer cette validation. Pour l’authentification de serveur à serveur, échangez le jeton du pool d’utilisateurs contre des identifiants temporaires via un Cognito Identity Pool avec sts:AssumeRoleWithWebIdentity. Les pièges incluent des URL de rappel (callback) ou de déconnexion mal configurées, la non-validation des portées (scopes) ou des groupes du jeton, et s’attendre à ce que les jetons d’ID soient directement utilisables pour les appels d’API AWS (vous devez les échanger via un pool d’identités). Pour une autorisation affinée, utilisez des groupes ou des revendications personnalisées (custom claims) et combinez Cognito avec des politiques basées sur les ressources et des clés de condition IAM telles que aws:userid ou cognito-identity.amazonaws.com:sub lors du mappage d’une identité à des rôles AWS. Auditez les connexions et les actions d’administration via CloudTrail, et activez les fonctionnalités de sécurité avancées dans Cognito pour la détection d’identifiants compromis.

Problème pratique : Scénario d’utilisation

Scénario : PixelForge, un studio de jeux vidéo, exploite un backend sans serveur dans un seul compte AWS avec Lambda, API Gateway, S3, DynamoDB et des Cognito user pools. Des clés d’API et des identifiants de base de données sensibles sont stockés pour plusieurs étapes de déploiement, et une équipe d’audit tierce doit accéder à des sous-ensembles d’images de production dans S3 pour une durée de 1 à 24 heures.

Défi : Fournir un accès éphémère et auditable aux images de production pour les auditeurs externes, s’assurer que les secrets de l’application font l’objet d’une rotation et sont accessibles de manière sécurisée par Lambda, et imposer le MFA pour l’accès administratif inter-comptes.

Approche recommandée :

Créez une clé KMS gérée par le client avec une politique de clé autorisant le déchiffrement pour le compte PixelForge et des autorisations (grants) pour un rôle IAM d’auditeur ; activez la rotation de la clé et exigez un EncryptionContext lors des opérations de déchiffrement.
Stockez les identifiants dans Secrets Manager (secrets distincts par étape) et attachez un rôle IAM aux fonctions Lambda avec la permission minimale secretsmanager:GetSecretValue et kms:Decrypt pour la clé KMS ; implémentez un code de démarrage Lambda pour appeler secretsmanager.getSecretValue({ SecretId }) en utilisant le SDK AWS.
Pour l’accès des auditeurs, créez un rôle de compte AWS d’auditeur distinct et autorisez sts:AssumeRole depuis le compte de l’auditeur dans une politique de compartiment S3 basée sur les ressources, limitée par aws:PrincipalArn et un mappage de rôle préconfiguré et limité dans le temps ; générez des identifiants à durée de vie limitée via sts:AssumeRole et imposez le MFA avec une condition aws:MultiFactorAuthPresent lors de l’assumption du rôle.
Journalisez tous les accès avec CloudTrail (événements de gestion et de données pour S3 et KMS) et activez la journalisation au niveau de l’objet S3 et Amazon Macie ou les journaux d’accès S3 (S3 Access Logs) pour une analyse forensique supplémentaire ; exigez que les sessions temporaires des auditeurs utilisent un EncryptionContext spécifique et taguez les objets/requêtes pour la traçabilité.

Justification : L’utilisation de Secrets Manager avec KMS et des identifiants STS à durée de vie limitée applique le principe du moindre privilège, permet une rotation automatisée et évite d’intégrer des secrets en dur. Les modèles d’assumption de rôle (assume-role) limités dans le temps avec MFA et les événements de données CloudTrail fournissent un accès auditable et révocable pour les tiers tout en préservant la séparation des tâches.

← Déploiement et CI · Tous les domaines · Surveillance →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →