AWS Solutions Architect — Conception d’architectures sécurisées : 85 questions d'entraînement

Step 1: Créer un rôle IAM dans le compte central et appliquer le moindre privilège - Raisonnement AWS : La meilleure pratique pour fournir un accès cross-account est de créer un rôle IAM dans la compte cible (ici le compte des services partagés) et autoriser des principals provenant des comptes membres à l'assumer. Le rôle contient une policy IAM (permissions) qui définit exactement quelles actions sont permises (par ex. accès à CodeDeploy, CloudWatch) et rien de plus. Cela permet de centraliser la gestion des permissions et d'appliquer le principe du moindre privilège.

Step 2: Restreindre la trust policy à l’Organisation - Raisonnement AWS : Utiliser des conditions telles que aws:PrincipalOrgID dans la trust policy du rôle limite l'assume-role uniquement aux comptes appartenant à votre AWS Organization, évitant que des comptes externes (même avec des IDs similaires) puissent abuser du rôle. Vous pouvez aussi combiner aws:SourceAccount ou aws:SourceArn pour lier la demande d'assume-role à un rôle spécifique d'un compte membre.

Step 3: Contrôles additionnels et séparation des responsabilités - Raisonnement AWS : Conserver la gestion des rôles et de la key rotation centralisée (par l'équipe SRE/Security) tout en autorisant les équipes applicatives à assumer uniquement les rôles nécessaires renforce la séparation des responsabilités. Évitez le partage de credentials et documentez les rôles, leurs permissions et les procédures d’audit (CloudTrail) afin d’assurer traçabilité. Trap: erreur fréquente - Beaucoup pensent qu’il suffit de partager un rôle ou d’accorder des permissions larges pour simplifier le flux. L’examen piège ici est la tentation d’ouvrir trop de droits (admin) ou d’utiliser des méthodes de contournement (clés statiques). Ces approches compromettent la sécurité, la traçabilité et le principe du moindre privilège. Pourquoi chaque réponse incorrecte échoue : - Déployer une policy globale donnant des droits d’administrateur (option 3) : C’est contraire au principe du moindre privilège et augmente grandement la surface d’attaque. L’examen attend que vous promouviez la séparation des responsabilités et la limitation des droits administratifs. Une policy globale admin rend difficile l’audit et facilite la propagation d’erreurs humaines ou d’attaques. - Partager des clés d’accès statiques entre comptes (option 4) : C’est une mauvaise pratique de sécurité majeure — les clés statiques sont difficiles à auditer, à révoquer et peuvent être extraites. AWS recommande fortement l’usage d’assume-role via STS, rôles IAM ou AWS SSO/Identity Federation plutôt que le partage de long-lived credentials. Conclusion opérationnelle : Créez des rôles dans le compte cible, appliquez un modèle least-privilege et restreignez la trust policy à votre Organization avec aws:PrincipalOrgID ; cela offre la séparation d’accès souhaitée et une traçabilité propre.

Step 1: Mettre en place une approche centralisée. Créer un compte d'identité central (ou utiliser IAM Identity Center) et, dans chaque compte membre, créer des rôles IAM qui ont des policies minimales nécessaires pour les tâches des administrateurs ou auditeurs. Configurer la relation de confiance (trust policy) pour permettre à l'entité centrale (compte d'identité ou Identity Center) d'assumer ces rôles.

Step 2: Appliquer le moindre privilège et gérer l'accès. Avec AWS IAM Identity Center, définir des Permission Sets qui reflètent exactement les permissions requises, et attacher ces permission sets aux comptes cibles via AWS Organizations. Si on utilise AssumeRole, limiter les permissions du rôle et ajouter des conditions (par exemple sourceAccount, MFA ou externalId si nécessaire).

Step 3: Gouvernance et auditing. Activer CloudTrail organisationnel pour loguer les opérations d'assume-role et les activités d'administration, utiliser les journaux pour revue d'accès. Ajouter des SCPs (Service Control Policies) pour interdire les actions sensibles globales (ex: suppression de logs) et des permission boundaries au besoin pour limiter les droits maximum que des rôles peuvent obtenir. Trap: Beaucoup pensent que créer des utilisateurs IAM dans chaque compte ou partager des clés d'accès suffit; c'est un piège car cela empêche une gestion centralisée, augmente la surface d'attaque et casse le principe du moindre privilège. Pourquoi chaque mauvaise réponse échoue: Réponse 3 échoue parce que consolider tous les admins dans un seul compte puis créer des utilisateurs IAM locaux signifie distribution d'identifiants permanents, difficulté de rotation, absence d'audit cross-account propre et responsabilités mal séparées. Réponse 4 échoue car les clés d'accès long terme augmentent le risque de compromission, rendent la rotation et la révocation plus compliquées et violent le principe du moindre privilège; stocker ces clés centralement ne supprime pas le risque de fuite. Les bonnes réponses fonctionnent ensemble: AssumeRole offre isolation par compte sans comptes locaux, et IAM Identity Center simplifie la gestion d'identité centralisée et le provisioning d'accès temporaire, tout en intégrant les meilleures pratiques d'audit et MFA.

Step 1: Identifier la cause probable — Dans une architecture centralisée de logs, les erreurs d'écriture liées au chiffrement KMS sont courantes: même si le bucket S3 accepte les PutObject, KMS peut empêcher l'opération si la key policy ne permet pas au service CloudTrail ou aux comptes donneurs/destinataires d'utiliser la clé. CloudTrail utilise souvent le service principal de CloudTrail et le role/compte destination pour chiffrer et écrire les objets. Si la key policy est trop restrictive, la livraison échouera.

Step 2: Corriger la key policy KMS — Modifier la key policy pour inclure explicitement les permissions nécessaires pour le service CloudTrail (ex: principal 'cloudtrail.amazonaws.com' avec conditionaire de délégation) et pour le compte central (ou le rôle IAM utilisé pour l'écriture). Autorisez kms:Encrypt pour la livraison et kms:Decrypt pour la lecture par le compte central. Si vous utilisez AWS Organizations, vous pouvez aussi inclure une condition aws:PrincipalOrgID ou limiter l'accès aux comptes membres autorisés.

Step 3: Vérifier et monitorer — Tester la livraison après modification, consulter CloudTrail pour les erreurs KMS:AccessDenied, et configurer des alertes et des dashboards d'intégrité pour la livraison des logs. Gardez la key policy la plus restrictive possible tout en permettant les actions nécessaires. Trap: Une erreur commune est de penser que des ACLs publiques ou la désactivation de features S3 (comme versioning) résoudront le problème — ce sont des non-issues pour des erreurs liées à KMS. Pourquoi les mauvaises réponses échouent: - Mettre les ACLs S3 en 'public-read': cela n'a aucun rapport avec l'écriture cross-account sécurisée et introduit un risque de sécurité majeur en rendant les objets lisibles publiquement. - Désactiver le versioning: versioning n'empêche pas la livraison par CloudTrail; au contraire, versioning est recommandé pour conserver l'historique des objets et la résilience. - Supprimer tous les IAM roles: solution destructrice et non ciblée qui casse les opérations normales; le problème est de key policy KMS, pas des roles S3 génériques.

Step 1: Connaître les types d'endpoints VPC — AWS propose deux principaux types d'endpoints VPC : Gateway Endpoint (utilisé principalement pour S3 et DynamoDB) qui s'insère dans la table de routage, et Interface Endpoint (basé sur AWS PrivateLink) qui crée des ENI privés pour l'accès à des services supportés (KMS, EC2 API, SSM, etc.).

Step 2: Mapper les services aux endpoints appropriés — Amazon S3 supporte les Gateway Endpoints ; c'est efficace et sans coût d'interface (aucun tarif par heure/GB pour l'endpoint lui‑même). AWS KMS, en revanche, utilise des Interface Endpoints (PrivateLink) qui créent des ENI dans chaque AZ et entraînent des coûts liés à l'interface et au trafic. Ainsi la combinaison correcte est : Gateway Endpoint pour S3 + Interface Endpoint pour KMS.

Step 3: Configuration et sécurité — Après création, associez le Gateway Endpoint S3 aux tables de routage des sous‑réseaux privés pour assurer que les requêtes vers les préfixes S3 transitent par l'endpoint. Pour KMS, créez l'Interface Endpoint dans les AZ requises et utilisez des Security Groups attachés aux ENI pour restreindre quelles instances peuvent appeler KMS. Utilisez des policies de endpoint pour limiter les actions et empêcher le contournement par d'autres routes. Trap: Supposer que tous les services supportent Gateway Endpoints est une erreur fréquente ; KMS nécessite un Interface Endpoint (PrivateLink). Confondre types conduit à une mauvaise conception réseau. Pourquoi chaque réponse incorrecte échoue : - Option 2 (Gateway pour KMS + Interface pour S3) : Incorrect car KMS ne supporte pas Gateway Endpoints ; S3 supporte Gateway Endpoints et pas d'Interface Endpoint dédiée pour usage courant. Inversement configurer l'interface pour S3 serait possible via PrivateLink seulement pour certains services mais n'est pas la pratique ni le service supporté classique. - Option 3 (NAT Gateway pour redirection) : Le NAT Gateway route le trafic vers Internet public via une Internet Gateway (IGW) — le trafic sortant vers S3/KMS passerait par Internet public si vous n'utilisez pas endpoints, ce qui va à l'encontre de l'exigence. De plus NAT augmente les coûts et l'exposition. - Option 4 (IP publiques + VPN) : Donner des IP publiques aux instances augmente la surface d'attaque ; utiliser un VPN pour rediriger vers l'extérieur est inutilement complexe et ne garantit pas que le trafic ne quitte l'infrastructure AWS. C'est aussi coûteux, moins performant et non standard pour accéder aux services AWS internes. Considérations coût/performance/sécurité : Gateway Endpoint pour S3 est performant et sans coût d'interface, mais ne protège pas les appels API autres que S3. Interface Endpoints (PrivateLink) pour KMS ont un coût par heure et par GB mais offrent isolation réseau fine (ENI), sécurité par SG et compatibilité cross‑AZ si provisionnés correctement. Toujours appliquer des endpoint policies et security groups pour limiter les accès et auditer via CloudTrail.

Step 1: Identifier la cause racine et limiter l'exposition immédiate — Dès qu'un bucket S3 est accessible publiquement, la priorité est de couper l'accès non intentionnel. Activer les contrôles Bloquer l'accès public au niveau du compte et du bucket empêche les ACLs, politiques de bucket et URLs pré-signées mal configurées d'ouvrir l'accès public. C'est le mécanisme recommandé par AWS pour un remède rapide et centralisé.

Step 2: Assurer le chiffrement au repos et un contrôle d'accès fin — Configurer SSE‑KMS par défaut pour le bucket garantit que tous les objets nouveaux ou copiés sont chiffrés avec une clé KMS. En utilisant une Customer Managed CMK et en attachant une stratégie de clé (key policy) et/ou des politiques IAM, on peut limiter qui peut chiffrer/déchiffrer, ajouter l'audit via CloudTrail et appliquer des conditions (par exemple, utilisateur, VPC endpoint, contexte de chiffrement).

Step 3: Valider et migrer les usages existants — Tester les applications pour s'assurer qu'elles ont les permissions KMS nécessaires; mettre en place des VPC endpoints S3 pour restreindre l'accès réseau; remplacer les URLs pré-signées trop larges par des mécanismes contrôlés (durée courte, distribution via IAM-authenticated services). Automatiser la découverte de buckets publics et mettre en place des contrôles (AWS Config, GuardDuty, Amazon Macie) pour la prévention et la détection continue. Trap: Une idée reçue est de penser que les ACLs seules suffisent; or Block Public Access est la protection la plus globale et doit être utilisée pour éviter des erreurs humaines. De plus, SSE‑S3 (SSE avec clés gérées par AWS) chiffre mais ne fournit pas le même contrôle d'accès granulaire et l'audit côté clé que SSE‑KMS; pour des données sensibles, SSE‑KMS est souvent requis. Pourquoi chaque option incorrecte échoue: Option 3 (Supprimer versioning et archiver vers Glacier) — cela n'empêche pas l'accès public aux objets actuels et peut compliquer la récupération; l'archivage n'est pas une correction de sécurité. Option 4 (Continuer avec ACLs publiques + logging) — Les ACLs publiques sont la racine du problème; le logging n'empêche pas l'accès et n'est qu'une mesure réactive; autoriser des ACLs publiques reste dangereux. En résumé, bloquer l'accès public et appliquer SSE‑KMS fournit un remède immédiat et une gouvernance sur qui peut déchiffrer les données, tandis que les autres choix ne corrigent pas l'exposition ni n'améliorent suffisamment le contrôle d'accès et l'audit.

Step 1: Détection proactive avec IAM Access Analyzer — Activez IAM Access Analyzer (qui inclut la validation de politique et l'analyse des resource policies) pour détecter les politiques qui autorisent l'accès public ou cross-account ainsi que les statements excessivement permissifs. Access Analyzer produit des findings exploitables qui indiquent potentiellement des principaux externes ou des allow rules trop larges.

Step 2: Surveillance continue via AWS Config — Déployez des règles AWS Config (gérées ou personnalisées) pour détecter la présence de statements avec Action="*" ou Resource="*" dans les politiques IAM. Les règles Config permettent un monitoring continu, peuvent déclencher des notifications (SNS) et servir de point d'intégration pour automatiser la remédiation.

Step 3: Automatisation et remédiation contrôlée — Lorsque Config ou Access Analyzer signale une politique problématique, déclenchez une Lambda/Runbook qui applique des mesures (notifier propriétaires, appliquer tags, éventuellement atténuer en remplaçant la policy par une version plus restrictive dans un workflow approuvé). Assurez-vous d'avoir une phase de validation humaine pour éviter blocages opérationnels. Trap: Un piège courant est d'imaginer que la suppression de la journalisation (CloudTrail) ou l'utilisation du compte root simplifie la gestion ; au contraire, CloudTrail est indispensable pour l'investigation et le compte root ne doit pas être utilisé pour des actions courantes. Pourquoi chaque mauvaise réponse échoue : - Exiger que tous les admins utilisent le compte root (mauvais) : le root a des privilèges illimités et son usage augmente le risque de compromission large ; la pratique recommandée est d'utiliser des rôles IAM ou des comptes administrateurs délégués avec MFA et least privilege. - Supprimer CloudTrail et réduire la journalisation (mauvais) : cela dégrade la capacité d'audit et d'investigation et empêche de déterminer l'origine des changements; cela masque les problèmes plutôt que de les résoudre. En résumé, combiner IAM Access Analyzer et AWS Config pour détection + workflows d'automatisation fournit un cadre robuste et évolutif pour identifier et corriger les politiques IAM trop permissives tout en gardant traçabilité et gouvernance.

Step 1: Comprendre le mécanisme d'autorisation SG/ALB — Les Application Load Balancers (ALB) et Network Load Balancers (NLB) communiquent avec les instances cibles via des flux réseau dont les adresses IP peuvent varier; AWS recommande d'autoriser l'accès par référence au groupe de sécurité du Load Balancer plutôt que par IP. Les Security Groups sont stateful : autoriser une source SG signifie que toute instance associée à ce SG pourra initier le trafic autorisé, et les réponses seront automatiquement permises.

Step 2: Application correcte — Mettre à jour le groupe de sécurité des instances back-end pour autoriser l'inbound sur le port de health-check (par ex. 80 ou 443 selon la config) depuis le groupe de sécurité du Load Balancer (sélectionner la référence SG comme source). Cela garantit que seules entités associées au SG du ALB peuvent atteindre le port de santé des instances, évitant d'exposer le port à Internet ou à des IPs changeantes.

Step 3: Validation et bonnes pratiques — Après modification, validez les health checks depuis la console ALB et vérifiez CloudWatch metrics. Conservez des logs d'accès (ALB access logs) et surveillez les tentatives refusées. Pour les environnements multi-AZ, appliquez la règle sur tous les SGs des instances afin de garantir résilience. Trap: Certains pensent à tort qu'autoriser l'adresse IP publique du ALB résout le problème ; toutefois, les ALB n'ont pas des IPs fixes stables et peuvent utiliser plusieurs adresses. Autoriser 0.0.0.0/0 est dangereux car il expose le port à Internet. Pourquoi chaque mauvaise réponse échoue : 1) Autoriser 0.0.0.0/0 — C'est une grave faille de sécurité : le port de health-check serait accessible publiquement, augmentant la surface d'attaque et enfreignant le principe du moindre privilège. 2) Autoriser l'adresse IP publique du ALB — Les ALB n'ont pas d'adresse IP publique statique garantie et peuvent changer d'IPs ou utiliser plusieurs; autoriser une IP spécifique peut entraîner une solution non fiable et brisée lors d'opérations de maintenance/scale. 4) Désactiver le groupe de sécurité sur les instances — Supprimer ou désactiver un SG supprime les contrôles de sécurité essentiels; cela expose les instances à tout le trafic et n'est jamais acceptable en production, même temporairement. Conclusion : la meilleure pratique est d'autoriser l'accès de health-check depuis la référence du groupe de sécurité du Load Balancer ; cette méthode est dynamique, fiable en multi-AZ, et conforme aux bonnes pratiques de sécurité AWS.

Step 1: Centraliser l’authentification — AWS IAM Identity Center (ex AWS SSO) intégré à AWS Organizations est la méthode recommandée pour gérer les accès multi-comptes. En connectant votre IdP (SAML/OIDC) vous obtenez une authentification fédérée, provisionnement (via SCIM) et attribution de permissions multi-comptes depuis une interface centrale. Cela réduit la création de comptes IAM locaux, facilite la gouvernance, améliore la rotation d’accès et la traçabilité, et s’intègre aux logs CloudTrail.

Step 2: Standardiser les rôles via automation — plutôt que créer manuellement des rôles dans 50 comptes, utilisez AWS CloudFormation StackSets (ou AWS Control Tower Account Factory dans certains cas) pour déployer des modèles IAM cohérents (principes least-privilege) et les maintenir centralement. L’automatisation réduit les erreurs humaines, assure la conformité et baisse le temps de mise en œuvre.

Step 3: Gouvernance et trade-offs — Identity Center réduit la gestion de clés et d’utilisateurs locaux ; StackSets impose une charge d’ingénierie initiale mais diminue le coût opérationnel long terme. Surveillance via CloudTrail/Config complète le modèle. Trap: croire qu’on peut partager des rôles IAM via RAM — AWS RAM partage des ressources supportées (ex: Transit Gateway, subnets associés), mais pas des entités IAM (utilisateurs/roles). Beaucoup pensent à tort que RAM est une solution de partage IAM. Why each wrong answer fails: - Option 2 (AWS RAM pour partager des rôles IAM) : AWS RAM ne permet pas de partager directement des rôles IAM entre comptes. Les rôles doivent être présents dans chaque compte et des relations de confiance cross-account doivent être créées. RAM est conçu pour partager certaines ressources managées (ex: Transit Gateway attachments, License Manager), pas pour déléguer ou partager des entités IAM. - Option 4 (créer un utilisateur IAM par ingénieur dans le compte central et utiliser des policies cross-account) : centraliser des utilisateurs IAM dans un seul compte et leur donner accès cross-account n’est pas scalable ni recommandé. Cela implique la gestion de comptes IAM locaux, rotation de credentials, et des défis d’audit ; de plus, cela crée un point central de compromis si le compte central est compromis. L’approche moderne est la fédération via Identity Center et le provisionnement de rôles IAM dans chaque compte (automatisés). Pourquoi les bonnes réponses fonctionnent : - Option 1 (IAM Identity Center) : offre gestion centralisée, fédération IdP, provisioning SCIM, interface d’attribution multi-comptes et journalisation, réduisant l’empreinte IAM locale. - Option 3 (CloudFormation StackSets) : garantit que les rôles et politiques déployés dans chaque compte sont cohérents, versionnés et maintenables. Conclusion : combiner IAM Identity Center pour l’authentification/attribution et StackSets pour le déploiement standardisé de rôles/profiles fournit une solution sécurisée, évolutive et conforme pour gérer 50 comptes d’entreprise.

Step 1: Besoin d’audit et de contrôle granulaire — vous devez pouvoir déterminer quels principaux (roles/users) ont exécuté des opérations de déchiffrement et limiter ces opérations à des rôles spécifiques. KMS fournit des opérations Decrypt/GenerateDataKey qui sont enregistrées dans CloudTrail (KMS API events) et peut être contrôlé par key policies et grants.

Step 2: Sélectionner SSE‑KMS (CMK customer‑managed) — en choisissant une CMK gérée par le client, vous pouvez écrire une key policy qui accorde explicitement les droits Decrypt à certains rôles et refuse à d’autres, imposer la séparation des responsabilités, et voir chaque appel KMS dans CloudTrail pour vérifier qui a fait quoi et quand.

Step 3: Implémentation et gouvernance — créez des key policies restreintes, utilisez des grants temporaires pour délégation, activez CloudTrail pour loguer les appels KMS, et configurez des alertes SIEM sur les appels Decrypt non attendus. Trap: confondre chiffrement « au repos » géré par AWS avec contrôle d’accès et audit détaillé — SSE‑S3 masque la gestion des clés et ne permet pas un contrôle aussi fin ou la même visibilité sur les opérations de déchiffrement. Pourquoi chaque mauvaise réponse échoue : 1) SSE‑S3 est simple mais ne fournit pas la granularité ni la possibilité d’appliquer des key policies ou d’auditer les opérations KMS; vous dépendez d’un mécanisme géré sans visibilité détaillée des déchiffrements. 3) SSE‑C (customer provided keys) exige que l’application fournisse la clé à chaque requête HTTP à S3; bien que cela donne du contrôle, c’est difficile à opérer, dangereux pour la rotation et ne fournit pas l’intégration CloudTrail/KMS nécessaire pour un audit centralisé. 4) Le chiffrement côté client garantit que seules les applications disposant des clés peuvent lire les données, mais complique l’audit centralisé et la gestion des clés (rotation, révocation) ; de plus, vous perdez la possibilité d’utiliser les primitives KMS pour le contrôle d’accès et la journalisation standardisée. Conclusion : SSE‑KMS avec une CMK customer‑managed offre le compromis requis entre contrôle d’accès granulaire, audit (CloudTrail) et gestion opérable des clés.

Step 1: Centraliser la CMK dans le compte de logs et ajuster la key policy - Raisonnement AWS : CloudTrail écrit directement dans S3 et peut chiffrer les objets SSE-KMS avec une CMK. Pour que CloudTrail (ou un rôle/service dans un compte membre) utilise la CMK du compte central, la key policy de la CMK doit explicitement autoriser le principal (par exemple le service CloudTrail principal ou un rôle IAM utilisé par les comptes membres) à effectuer kms:Encrypt/kms:Decrypt/kms:ReEncrypt* actions nécessaires. La CMK étant dans le compte central, vous gardez le contrôle administratif et la rotation des clés au même endroit, renforçant la gouvernance.

Step 2: Exiger le chiffrement côté bucket S3 via une bucket policy/Condition - Raisonnement AWS : En plus de la key policy, le bucket S3 doit refuser les PutObject qui ne spécifient pas SSE-KMS (ou qui n’utilisent pas la CMK souhaitée). En ajoutant une condition dans la bucket policy qui vérifie x-amz-server-side-encryption ou aws:RequestKeyId, vous forcez l’utilisation de SSE-KMS et empêche les comptes membres d’écrire des objets non chiffrés ou chiffrés par une CMK différente.

Step 3: Garantir la traçabilité et empêcher les contournements - Raisonnement AWS : Combinez CloudTrail, S3 bucket policy et KMS key policy pour que seules les writes valides (chiffrées avec la bonne CMK, par CloudTrail/service autorisé) soient acceptées. Activez le verrouillage d’objets S3 (Object Lock) si nécessaire et configurez CloudTrail pour utiliser la CMK centrale lors de la création du trail. Testez la configuration avec des comptes membres pour vérifier que les PutObject non conformes sont rejetés. Trap: erreur fréquente - L’examen cherchera à piéger avec la suggestion d’utiliser des CMK locales par compte ou d’octroyer des permissions S3 larges. Beaucoup pensent qu’un simple PutObject sera accepté — sans la condition SSE-KMS et la key policy appropriée, des objets non chiffrés ou chiffrés avec des clés non contrôlées peuvent arriver, ruinent la centralisation du contrôle des clés. Pourquoi chaque réponse incorrecte échoue : - Utiliser des CMK locales dans chaque compte membre (option 3) : Si chaque compte chiffre ses journaux avec sa propre CMK, vous perdez le contrôle centralisé sur la gestion des clés, la révocation et la revue. De plus, CloudTrail configuré pour chiffrer avec des CMK locales ne garantit pas qu’un objet écrit dans le bucket central sera lisible par le compte central sans accords de key policy complexes ; ceci complique l’accès centralisé aux logs. - Donner s3:PutObject sans conditions (option 4) : Cela permet d’écrire des objets non chiffrés ou chiffrés avec des clés que vous ne contrôlez pas, ce qui annule l’objectif de sécurité. Sans une condition sur l’en-tête SSE-KMS ou sur la clé, vous ne pouvez pas empêcher le contournement du chiffrement. Conclusion opérationnelle : Déployez la CMK dans le compte central, adaptez la key policy pour autoriser le service CloudTrail (ou rôles nécessaires) et appliquez une bucket policy qui exige SSE-KMS (et idéalement la KeyId attendue) pour s’assurer que tous les logs dans le bucket sont chiffrés avec la CMK gérée centralement.

Step 1: Identifier les besoins réels des instances EC2 en analysant les accès effectifs (IAM Access Advisor, CloudTrail, VPC Flow Logs) pour déterminer quelles actions S3 et quels buckets/objets sont réellement utilisés. Ne pas supprimer brutalement les rôles si cela interrompt la production.

Step 2: Remplacer les politiques permissives (s3:*) par des politiques granulaires qui limitent les actions (ex: GetObject, PutObject) et spécifient des ressources ARN S3 précises. Appliquer des conditions si possible (par adresse IP, par balises, par contexte de session) et utiliser des permissions boundaries ou des policies managées centralisées pour uniformiser le modèle.

Step 3: Valider et monitorer: utiliser IAM Access Analyzer pour détecter les permissions excessives, exécuter des tests fonctionnels sur un environnement pilote, puis déployer la politique mise à jour. Mettre en place des alertes CloudTrail pour usages anormaux et planifier des revues régulières des permissions. Trap: Penser que la seule solution est d'utiliser SCP pour bloquer S3 globalement ou d'attendre les alertes. Les SCP sont utiles pour des restrictions organisationnelles, mais un blocage global peut casser des flux légitimes. De même, se contenter d'alertes sans corriger le principe du moindre privilège ne réduit pas le risque initial. Why each wrong answer fails: - Option 1: Retirer le rôle et utiliser des clés d'accès temporaires pour un utilisateur IAM est moins sûr (clés, même temporaires, augmentent la surface d'attaque) et provoque une opération manuelle et fragile. Les rôles IAM temporaires via instance profiles sont le bon modèle; il faut restreindre leur politique, pas les remplacer par des clés manuelles. - Option 3: Appliquer une SCP qui interdit toute action S3 est trop large et disruptif; cela casse potentiellement des flux business légitimes (depuis d'autres services, pipelines, etc.). Les SCP doivent être utilisées judicieusement et non comme panacée pour des rôles mal configurés. - Option 4: Se contenter d'alertes sans corriger les permissions laisse une vulnérabilité active. La détection est importante, mais la remédiation proactive (least privilege) est requise pour réduire le risque. En somme, la correction appropriée est de restreindre les politiques IAM au minimum nécessaire, valider via outils d'analyse et monitorer pour prévenir les régressions.

Step 1: Choisir la bonne option de clé — L'exigence de « maîtrise des clés » et la capacité à révoquer l'accès à des comptes spécifiques indique l'utilisation d'une Customer Managed CMK dans AWS KMS. Une CMK client vous permet de contrôler la politique de clé et d'octroyer ou retirer explicitement des permissions (grants) à des comptes, rôles ou services.

Step 2: Application du chiffrement et de la politique — Utiliser SSE‑KMS (Server‑Side Encryption with KMS) pour S3 et lier la CMK via la configuration SSE‑KMS sur le bucket/objets. Mettre en place la rotation automatique de la CMK (option disponible pour les CMK gérées par le client) pour respecter la rotation des clés réglementaire.

Step 3: Contrôle d'accès et gouvernance — Définir la politique de clé KMS (key policy) pour inclure/exclure des comptes, et utiliser des grants temporaires pour des accès transitoires. Appliquer une policy de bucket S3 qui exige SSE‑KMS et cette CMK spécifique afin d'empêcher le stockage en clair ou avec d'autres clés. Trap: Penser que SSE‑S3 (S3‑managed) suffit est une erreur courante — SSE‑S3 masque la gestion des clés à AWS et ne permet pas un contrôle granulaire ou la révocation d'accès cross‑account par la politique de clé KMS. Pourquoi chaque réponse incorrecte échoue : - Option 2 (SSE‑S3) : SSE‑S3 utilise des clés gérées par AWS et ne vous donne pas la maîtrise directe ni la possibilité d'ajuster la policy de clé pour révoquer l'accès à des comptes spécifiques. Rotation et conformité fine sont plus difficiles à prouver. - Option 3 (chiffrement côté client) : Bien que cela fournisse la maîtrise complète des clés, c'est opérationnellement plus lourd, comporte des risques de gestion des clés (perte, rotation, audits) et n'utilise pas KMS pour la gouvernance centralisée; il viole souvent les meilleures pratiques d'intégration dans AWS et augmente la complexité et le coût de maintenance. - Option 4 (SSE‑KMS avec aws/s3) : aws/s3 est une clé gérée par AWS, donc vous ne contrôlez pas la politique de clé ni la rotation; S3 Object Lock protège contre la suppression mais ne fournit pas le contrôle granulaire des clés nécessaires. Compter uniquement sur IAM ne suffit pas pour contrôler l'utilisation des clés côté KMS. Considérations coût/performance/sécurité : SSE‑KMS avec CMK a un léger coût additionnel par appel KMS (latence minime), mais fournit une gouvernance et traçabilité (CloudTrail) supérieures. La rotation automatique et la possibilité d'ajouter des grants limitent le blast radius en cas de compromission.