Guide

Une instance EC2 potentiellement compromise dans un groupe Auto Scaling nécessite une investigation avec une interruption minimale.

→Désenregistrer du groupe cible ELB, supprimer du groupe Auto Scaling et appliquer un groupe de sécurité "forensic" restrictif qui refuse tout le trafic à l'exception de l'accès à la station de travail d'investigation.

Pourquoi: Cela isole l'instance du réseau tout en préservant son état volatile (mémoire, processus en cours) pour l'analyse forensique. Terminer immédiatement détruit les preuves.

Automatiser un flux de travail de réponse aux incidents en plusieurs étapes (par exemple, capture instantanée, isolation, notification) déclenché par une détection GuardDuty.

→Utiliser une règle EventBridge pour capturer la détection spécifique et déclencher une machine à états AWS Step Functions. La machine à états orchestre la séquence d'actions avec gestion des erreurs et logique de nouvelle tentative.

Pourquoi: Step Functions offre une orchestration robuste pour les flux de travail en plusieurs étapes, garantissant la fiabilité et la gestion de l'état, ce qui est supérieur à une seule fonction Lambda monolithique.

Détecter les menaces d'exécution (par exemple, cryptominage, élévation de privilèges) au sein des conteneurs ECS Fargate ou EC2 en cours d'exécution sans déployer d'agents sidecar.

→Activer la surveillance d'exécution Amazon GuardDuty ECS. Pour EC2, déployer l'agent de sécurité GuardDuty en tant que DaemonSet. Pour Fargate, utiliser la configuration d'agent automatisée.

Pourquoi: Cela fournit une détection des menaces d'exécution sans agent (pour Fargate) ou gérée de manière centralisée (pour EC2), capturant le comportement intra-conteneur sans modifier les tâches d'application.

Référence↗

Remédier automatiquement à une détection spécifique d'AWS Security Hub, telle qu'un compartiment S3 accessible publiquement.

→Créer une règle EventBridge qui correspond au type de détection spécifique (par exemple, `S3.1`) et déclenche une fonction Lambda ou un document d'automatisation SSM pour effectuer la remédiation.

Pourquoi: Il s'agit du modèle natif, basé sur les événements, pour la réponse automatisée de Security Hub, offrant une remédiation ciblée et quasi en temps réel.

Une clé d'accès IAM a été exposée publiquement. Contenir l'incident et évaluer le rayon d'impact.

→1. Désactiver la clé d'accès exposée. 2. Attacher une politique en ligne de type "deny-all" à l'utilisateur/rôle pour invalider les sessions STS actives. 3. Examiner les journaux CloudTrail pour tous les appels API effectués avec la clé. 4. Éradiquer toutes les ressources non autorisées ou les principaux IAM créés par l'attaquant.

Pourquoi: La désactivation de la clé empêche toute utilisation future. La politique "deny-all" est essentielle pour révoquer les sessions actives créées *avant* la désactivation de la clé. CloudTrail fournit la piste d'audit pour l'évaluation des dommages.

Améliorer la détection des menaces de GuardDuty avec des flux de renseignements sur les menaces spécifiques à l'entreprise ou à l'industrie.

→Télécharger un fichier texte brut d'adresses IP/CIDR malveillantes vers S3. Créer et activer un nouvel ensemble de renseignements sur les menaces dans GuardDuty, pointant vers le fichier S3.

Pourquoi: Cela vous permet d'augmenter les renseignements sur les menaces gérés par GuardDuty avec des IOC personnalisés, générant des détections lorsque vos ressources communiquent avec ces IP spécifiées.

Identifier les instances EC2 avec des chemins réseau ouverts vers Internet sur des ports spécifiques, en tenant compte de toutes les configurations réseau.

→Activer Amazon Inspector et examiner ses détections de joignabilité réseau.

Pourquoi: Inspector effectue une analyse complète du chemin réseau des IGW aux instances, évaluant les groupes de sécurité, les NACL et les tables de routage pour déterminer la joignabilité réelle. C'est plus précis que de simplement vérifier les règles de groupe de sécurité individuelles.

Enquêter sur l'étendue complète d'une détection de sécurité, en visualisant toutes les entités associées et le comportement historique.

→Utiliser Amazon Detective. Naviguer vers le profil de l'entité (par exemple, pour une instance EC2 ou un rôle IAM) pour afficher le graphique de comportement et la chronologie des appels API, des connexions réseau et des détections GuardDuty associés.

Pourquoi: Detective corrèle automatiquement les journaux de CloudTrail, VPC Flow Logs et GuardDuty, fournissant une analyse contextuelle qui accélère considérablement l'enquête sur les causes profondes par rapport à la corrélation manuelle des journaux.

Stocker les journaux d'audit (par exemple, CloudTrail, VPC Flow Logs) pour une rétention à long terme de manière inviolable et interrogeable afin de répondre aux exigences de conformité.

→Livrer les journaux à un compartiment S3 avec S3 Object Lock en mode Conformité activé. Utiliser Amazon Athena pour les requêtes.

Pourquoi: Object Lock en mode Conformité empêche la suppression ou la modification par quiconque, y compris l'utilisateur root, assurant l'immuabilité des journaux. Athena offre des capacités de requête SQL ad hoc sur les journaux stockés.

Référence↗

Collecter centralement tous les événements de gestion et de données pour une AWS Organization entière.

→Dans le compte de gestion, créer un journal d'organisation CloudTrail. Pour capturer des données au niveau des objets, utiliser des sélecteurs d'événements avancés pour enregistrer des types d'événements spécifiques (par exemple, S3 PutObject, Lambda Invoke) pour les ressources de grande valeur.

Pourquoi: Un journal d'organisation enregistre automatiquement les événements pour tous les comptes membres. Les sélecteurs d'événements avancés sont essentiels pour enregistrer efficacement et à moindre coût les événements de données à volume élevé en ciblant uniquement les ressources nécessaires.

Effectuer une analyse complexe basée sur SQL des événements CloudTrail de toute l'organisation sur plusieurs années.

→Activer AWS CloudTrail Lake et créer un magasin de données d'événements au niveau de l'organisation avec la période de rétention requise (jusqu'à 7 ans). Utiliser l'éditeur de requêtes SQL intégré pour l'analyse.

Pourquoi: CloudTrail Lake fournit un magasin de données géré et immuable ainsi qu'un moteur de requête spécialement conçus pour les événements CloudTrail, éliminant la nécessité de gérer S3, Glue et Athena pour l'analyse des journaux.

Surveiller toutes les requêtes DNS effectuées par les ressources au sein d'un VPC pour la recherche de menaces ou le dépannage.

→Activer la journalisation des requêtes DNS du résolveur Route 53 et la configurer pour envoyer les journaux à CloudWatch Logs, S3 ou Kinesis Data Firehose.

Pourquoi: Cela offre une visibilité détaillée sur l'activité de résolution DNS au sein de vos VPC, capturant le domaine interrogé, l'instance source et la réponse, ce qui est crucial pour détecter les menaces basées sur DNS.

Centraliser et normaliser les journaux de sécurité de diverses sources AWS et tierces dans un lac de données à l'aide d'un schéma standard.

→Déployer Amazon Security Lake. Il collecte et normalise automatiquement les données dans l'Open Cybersecurity Schema Framework (OCSF) et les stocke au format Parquet dans S3.

Pourquoi: Security Lake automatise la création et la gestion d'un lac de données de sécurité, réduisant la charge opérationnelle liée à la création de pipelines ETL personnalisés pour la normalisation.

Automatiser la collecte de preuves pour les audits de conformité par rapport à des cadres comme SOC 2, PCI DSS ou HIPAA.

→Utiliser AWS Audit Manager. Sélectionner un cadre prédéfini, qui collecte automatiquement des preuves auprès des services AWS (CloudTrail, Config, Security Hub) et les mappe aux contrôles de conformité spécifiques.

Pourquoi: Audit Manager automatise et centralise le processus de collecte de preuves, réduisant considérablement l'effort manuel nécessaire pour préparer et réaliser des audits de conformité.

Découvrir et classer automatiquement les données sensibles (PII, PHI, financières) dans tous les compartiments S3.

→Activer Amazon Macie et configurer des tâches automatisées de découverte de données sensibles. Utiliser des identifiants de données gérés pour les types de données courants et créer des identifiants de données personnalisés pour les formats propriétaires.

Pourquoi: Macie fournit une solution gérée et évolutive pour la classification des données S3. Pour supprimer les détections de données non sensibles connues (par exemple, données de test), utiliser les listes d'autorisation Macie.

Appliquer plusieurs contrôles de sécurité sur un compartiment S3, tels que l'exigence de SSE-KMS avec une clé spécifique et le refus des requêtes HTTP.

→Utiliser une politique de compartiment avec plusieurs instructions `Deny` et clés de condition : `aws:SecureTransport: false`, `s3:x-amz-server-side-encryption: "aws:kms"`, et `s3:x-amz-server-side-encryption-aws-kms-key-id: "key-arn"`.

Pourquoi: Les politiques de compartiment offrent un contrôle granulaire au niveau des ressources. L'utilisation de plusieurs clés de condition dans les instructions Deny est le moyen standard d'appliquer une posture de sécurité en couches sur un compartiment.

S'assurer que tous les nouveaux volumes EBS sont chiffrés avec une clé KMS gérée par le client spécifique, à l'échelle de l'organisation.

→Activer le chiffrement EBS par défaut dans les paramètres du compte pour chaque région, en spécifiant la CMK. Appliquer une SCP qui refuse `ec2:CreateVolume` si le paramètre `encrypted` est `false` comme garde-fou préventif.

Pourquoi: Le paramètre par défaut offre une commodité, tandis que la SCP fournit un garde-fou d'application strict, créant une approche de défense en profondeur pour le chiffrement des données au repos pour EBS.

Chiffrer de grands objets de données (> 4 Ko) à l'aide d'AWS KMS.

→Utiliser le chiffrement par enveloppe. Appeler `KMS:GenerateDataKey` pour obtenir une clé de données en texte clair et une clé de données chiffrée. Utiliser la clé en texte clair pour chiffrer le grand objet localement. Stocker l'objet chiffré et la clé de données chiffrée ensemble. Jeter la clé en texte clair.

Pourquoi: L'API KMS Encrypt a une limite de 4 Ko. Le chiffrement par enveloppe permet de chiffrer des données de toute taille tandis que la petite clé de données est protégée par KMS, réduisant les coûts et la latences par rapport à la diffusion de données via KMS.

Référence↗

Utiliser la même clé de chiffrement dans plusieurs régions AWS pour la reprise après sinistre ou la cohérence globale des applications.

→Créer une clé primaire multi-régions KMS dans une région et créer des clés répliques dans d'autres régions. Les données chiffrées avec une clé dans une région peuvent être déchiffrées avec la réplique dans une autre.

Pourquoi: Les clés multi-régions partagent le même matériel de clé et le même ID de clé, permettant la portabilité des données entre régions sans appels API inter-régions pour le déchiffrement.

Stocker et faire pivoter automatiquement les informations d'identification (par exemple, mots de passe de base de données, clés API) utilisées par les applications.

→Stocker les informations d'identification dans AWS Secrets Manager. Configurer la rotation automatique à l'aide d'une fonction de rotation Lambda personnalisée ou fournie par AWS. Les applications récupèrent les secrets au moment de l'exécution via un rôle IAM.

Pourquoi: Secrets Manager est un service spécialement conçu pour l'ensemble du cycle de vie des secrets, y compris le stockage sécurisé, le contrôle d'accès, l'audit et la rotation automatisée, réduisant le risque d'informations d'identification codées en dur ou périmées.

Gérer à la fois les certificats TLS publics pour les sites web et les certificats privés pour la communication interne des microservices (mTLS).

→Utiliser AWS Certificate Manager (ACM) pour des certificats publics gratuits intégrés à ELB/CloudFront. Créer une autorité de certification privée à l'aide d'ACM Private CA pour émettre et gérer des certificats privés pour les services internes.

Pourquoi: Cela sépare les PKI publiques et privées, en utilisant l'outil approprié pour chaque cas d'utilisation. ACM gère le cycle de vie des certificats publics, tandis qu'ACM Private CA fournit une hiérarchie PKI privée entièrement gérée.

Stocker des données de manière immuable pendant une période de rétention fixe, où même l'utilisateur root ne peut pas les supprimer.

→Activer S3 Object Lock sur le compartiment. Placer les objets sous une période de rétention en mode Conformité.

Pourquoi: Le mode Conformité est le contrôle WORM (Write-Once-Read-Many) le plus strict, empêchant la suppression par tout utilisateur. Le mode Gouvernance peut être contourné par des principaux autorisés.

Protéger les sauvegardes contre la suppression (par exemple, en raison d'un ransomware ou de crédiantaux compromis) pendant une période de rétention obligatoire.

→Activer AWS Backup Vault Lock en mode Conformité avec une période de rétention minimale.

Pourquoi: Vault Lock en mode Conformité rend le coffre de sauvegarde conforme WORM, empêchant tout utilisateur, y compris l'utilisateur root, de supprimer les points de récupération avant l'expiration de la période de rétention.

Traiter des données très sensibles où les données ne doivent jamais être exposées au système d'exploitation, à l'hyperviseur ou aux opérateurs AWS.

→Utiliser AWS Nitro Enclaves pour créer un environnement de calcul cryptographiquement isolé. Utiliser l'attestation KMS pour garantir que seules les enclaves vérifiées peuvent déchiffrer les données.

Pourquoi: Nitro Enclaves offre le plus haut niveau de protection des données en cours d'utilisation sur AWS, en utilisant une attestation au niveau matériel pour créer un environnement d'exécution fiable.

Utiliser des services AWS avec des clés de chiffrement physiquement stockées et gérées dans un HSM sur site, en dehors d'AWS.

→Configurer un KMS External Key Store (XKS) qui proxifie les opérations cryptographiques de KMS vers un gestionnaire de clés externe.

Pourquoi: XKS permet aux clients de conserver le contrôle de leur matériel de clé en dehors d'AWS pour répondre aux exigences de souveraineté ou de conformité, tout en s'intégrant aux services AWS compatibles KMS.

Appliquer une politique stricte "pas de compartiments S3 publics" à l'échelle de toute une organisation avec des contrôles préventifs et de détection.

→Activer le blocage de l'accès public S3 au niveau de l'organisation depuis le compte de gestion. Compléter avec une SCP qui refuse des actions comme `s3:PutBucketPolicy` si la politique autorise l'accès public. Utiliser AWS Config pour détecter les dérives.

Pourquoi: Cette approche en couches fournit un blocage par défaut (paramètre d'organisation), un garde-fou préventif qui empêche les mauvaises configurations (SCP) et un contrôle de détection pour une surveillance continue (Config).

Inspecter tout le trafic inter-VPC et sortant vers Internet à l'aide d'une appliance de sécurité centralisée (par exemple, AWS Network Firewall).

→Créer un VPC d'inspection dédié. Utiliser une Transit Gateway pour connecter tous les VPC. Configurer les tables de routage TGW pour envoyer tout le trafic via le VPC d'inspection. Activer le mode appliance sur l'attachement TGW pour le routage symétrique.

Pourquoi: Il s'agit du modèle hub-and-spoke standard pour l'inspection centralisée du trafic, offrant une évolutivité et une application cohérente des politiques sans maillages complexes de peering de VPC.

Protéger une application web (sur CloudFront/ALB) contre l'OWASP Top 10, les bots et les attaques de prise de contrôle de compte.

→Attacher AWS WAF avec les règles gérées par AWS (par exemple, `AWSManagedRulesCommonRuleSet`), le groupe de règles gérées Bot Control et le groupe de règles gérées de prévention de prise de contrôle de compte (ATP).

Pourquoi: Cette approche multicouche utilise plusieurs groupes de règles gérées pour une protection étendue (Commun), une détection automatisée du trafic (Bot Control) et une sécurité spécialisée des points d'accès de connexion (ATP).

Fournir un accès sécurisé et privé à un service API SaaS depuis les VPC clients sans exposer le service à Internet.

→Créer un service de point de terminaison AWS PrivateLink adossé à un Network Load Balancer (NLB). Les clients créent des points de terminaison d'interface VPC dans leurs VPC pour accéder au service.

Pourquoi: PrivateLink maintient le trafic sur le backbone privé d'AWS, évitant l'Internet public et éliminant le besoin de peering VPC complexes, de VPN ou de listes blanches d'IP. C'est le modèle standard et évolutif pour la connectivité SaaS privée.

Restreindre l'accès au compartiment S3 afin que le contenu ne soit accessible que via une distribution CloudFront.

→Utiliser CloudFront Origin Access Control (OAC). Mettre à jour la politique du compartiment S3 pour n'autoriser l'accès qu'à partir du principal de service de la distribution CloudFront, conditionné par l'ARN spécifique de la distribution.

Pourquoi: OAC est la méthode actuellement recommandée, supérieure à l'ancienne Origin Access Identity (OAI). Elle prend en charge toutes les fonctionnalités S3, y compris SSE-KMS, et suit les meilleures pratiques de sécurité.

Fournir un accès shell sécurisé et auditable aux instances EC2 dans des sous-réseaux privés sans ouvrir les ports SSH/RDP ni gérer des hôtes bastion.

→Installer l'agent SSM sur les instances EC2. Utiliser AWS Systems Manager Session Manager pour l'accès. Les politiques IAM contrôlent qui peut démarrer des sessions. L'activité de session peut être journalisée dans CloudWatch Logs et S3.

Pourquoi: Session Manager fournit un accès sécurisé, basé sur un navigateur ou une CLI, via un tunnel chiffré, éliminant le besoin de ports entrants, d'hôtes bastion et de clés SSH, tout en offrant une auditabilité complète.

Implémenter un filtrage au niveau DNS pour empêcher les ressources VPC de résoudre des domaines malveillants connus.

→Configurer Route 53 Resolver DNS Firewall avec des listes de domaines gérées (pour les malwares, C2) et des listes de blocage personnalisées. Associer le groupe de règles du pare-feu aux VPC.

Pourquoi: Cela fournit un service de filtrage DNS centralisé et géré au niveau du VPC, bloquant l'activité malveillante au point le plus précoce (résolution DNS) sans nécessiter d'agents basés sur l'hôte.

Implémenter des contrôles réseau à privilège minimum pour une application web à trois niveaux.

→Créer des groupes de sécurité distincts pour chaque niveau. Le SG ALB autorise le trafic entrant sur le port 443 depuis `0.0.0.0/0`. Le SG App autorise le trafic entrant uniquement depuis le SG ALB. Le SG DB autorise le trafic entrant uniquement depuis le SG App sur le port de la base de données.

Pourquoi: L'utilisation de références de groupes de sécurité comme sources offre une micro-segmentation dynamique et agnostique à l'IP, garantissant que chaque niveau ne peut être accédé que par son niveau adjacent et autorisé.

Accorder des autorisations AWS granulaires, au niveau du pod, aux applications s'exécutant sur EKS, en évitant l'utilisation de rôles IAM de nœud partagés.

→Activer IAM Roles for Service Accounts (IRSA) sur le cluster EKS. Créer un rôle IAM avec des autorisations spécifiques pour l'application. Annoter le compte de service Kubernetes de l'application avec l'ARN du rôle IAM.

Pourquoi: IRSA fournit des informations d'identification temporaires directement aux pods en fonction de leur compte de service, implémentant le principe du moindre privilège au niveau du pod et éliminant le risque de sécurité lié aux rôles de nœud trop permissifs.

Fournir un accès sans VPN aux applications web internes basé à la fois sur l'identité de l'utilisateur et la posture de sécurité de l'appareil.

→Déployer AWS Verified Access. Intégrer avec l'IdP d'entreprise comme fournisseur de confiance utilisateur et une solution de gestion des appareils comme fournisseur de confiance appareil. Créer des politiques d'accès par application.

Pourquoi: Verified Access est conçu spécifiquement pour l'accès zéro-confiance, évaluant chaque requête par rapport à des politiques qui prennent en compte le contexte de l'utilisateur et de l'appareil, éliminant la dépendance à la sécurité du périmètre réseau.

Permettre aux développeurs de créer des rôles IAM mais les empêcher de créer des rôles qui pourraient élever leurs propres privilèges.

→Créer une politique de limite de permissions qui définit les permissions maximales autorisées. Dans la politique IAM des développeurs, conditionner la permission `iam:CreateRole` pour exiger l'attachement de cette limite spécifique via la clé de condition `iam:PermissionsBoundary`.

Pourquoi: Les limites de permissions définissent les permissions maximales qu'une entité IAM peut avoir. Cela empêche l'élévation de privilèges en garantissant que tout rôle créé par un développeur est limité par la frontière, quelle que soit la politique d'identité qu'il attache.

Référence↗

Empêcher tout utilisateur de n'importe quel compte membre (y compris les administrateurs) d'effectuer des actions à haut risque, telles que la désactivation de CloudTrail ou la suppression d'un compartiment S3 commun.

→Appliquer une politique de contrôle des services (SCP) à la racine ou à l'unité d'organisation pertinente qui contient une instruction `Deny` pour les actions restreintes (par exemple, `cloudtrail:StopLogging`, `s3:DeleteBucket`).

Pourquoi: Les SCP sont le garde-fou ultime dans AWS Organizations. Ils définissent les permissions maximales pour tous les principaux d'un compte, et un Deny explicite dans une SCP ne peut être outrepassé par aucune politique IAM au sein du compte.

Fournir un accès inter-comptes sécurisé et auditable pour une application ou un utilisateur.

→Dans le compte cible, créer un rôle IAM avec une politique de confiance qui spécifie l'ARN du principal du compte source. Dans le compte source, accorder au principal la permission `sts:AssumeRole` sur le rôle cible. L'application utilise STS AssumeRole pour obtenir des informations d'identification temporaires.

Pourquoi: C'est le modèle standard pour l'accès inter-comptes. Il utilise des informations d'identification temporaires, de courte durée, et est entièrement auditable dans les deux comptes via CloudTrail.

Intégrer IAM Identity Center avec un IdP externe (par exemple, Okta, Azure AD) et automatiser le provisionnement des utilisateurs/groupes.

→Configurer l'IdP externe comme source d'identité dans IAM Identity Center. Activer le provisionnement automatique via SCIM pour synchroniser les utilisateurs et les groupes. Attribuer des ensembles de permissions aux groupes synchronisés.

Pourquoi: SCIM (System for Cross-domain Identity Management) fournit une synchronisation automatisée et quasi en temps réel des identités, éliminant la gestion manuelle des utilisateurs et garantissant que l'accès AWS est piloté par l'IdP.

Accorder l'accès aux ressources (par exemple, EC2) basé sur des balises, où les principaux ne peuvent gérer que les ressources balisées avec le nom de leur propre équipe/département.

→Baliser les principaux IAM (utilisateurs/rôles) et les ressources (instances EC2) avec une clé commune (par exemple, `Team`). Créer une seule politique IAM qui autorise les actions avec une condition comparant `aws:PrincipalTag/Team` à `aws:ResourceTag/Team`.

Pourquoi: Le contrôle d'accès basé sur les attributs (ABAC) offre un modèle de permissions évolutif qui ne nécessite pas de mises à jour de politique lorsque de nouvelles ressources ou équipes sont ajoutées. Les permissions sont déterminées dynamiquement en fonction des balises.

Un principal du Compte B doit lire un objet S3 du Compte A qui est chiffré avec une clé KMS également dans le Compte A.

→Trois permissions sont requises : 1) La politique de compartiment S3 du Compte A doit autoriser le principal du Compte B. 2) La politique de clé KMS du Compte A doit autoriser le principal du Compte B pour `kms:Decrypt`. 3) Le principal du Compte B a besoin d'une politique IAM autorisant `s3:GetObject` et `kms:Decrypt`.

Pourquoi: L'accès aux données chiffrées par KMS nécessite des permissions du service de données (S3) et du service de chiffrement (KMS). La politique de clé KMS est une politique de ressource et est essentielle pour accorder un accès inter-comptes.

Comprendre le résultat final des permissions lorsque plusieurs politiques (IAM, Ressource, SCP, Limite) s'appliquent.

→La logique d'évaluation est la suivante : Un refus explicite dans n'importe quelle politique l'emporte toujours sur toute autorisation. S'il n'existe aucun refus, une autorisation explicite dans toute politique applicable accorde l'accès. Les permissions effectives sont l'intersection de toutes les politiques applicables.

Pourquoi: Ceci est un concept IAM fondamental. Un refus explicite est l'instruction la plus puissante et sert de "non" catégorique. Comprendre cela est essentiel pour le dépannage des problèmes d'accès.

Empêcher un utilisateur ou un rôle IAM de transmettre un rôle hautement privilégié à un service AWS (par exemple, EC2), ce qui élèverait ses privilèges.

→Définir la portée de la permission `iam:PassRole` dans la politique IAM de l'utilisateur/rôle. Restreindre l'élément `Resource` aux seuls ARN de rôle spécifiques et à privilège minimum que l'entité est autorisée à transmettre.

Pourquoi: `iam:PassRole` avec un joker (`"Resource": "*"`) est un risque majeur d'élévation de privilèges. Le restreindre à des rôles spécifiques et moins privilégiés est un contrôle de sécurité essentiel.

Demander la MFA aux utilisateurs uniquement lorsqu'une tentative de connexion est considérée comme risquée (par exemple, nouvel appareil, emplacement inhabituel).

→Activer les fonctionnalités de sécurité avancées dans le pool d'utilisateurs Cognito et configurer l'authentification adaptative avec une application de la MFA basée sur les risques.

Pourquoi: Cela offre une meilleure expérience utilisateur que d'exiger la MFA pour chaque connexion, tout en améliorant la sécurité en appliquant des défis uniquement aux tentatives de connexion anormales.

Permettre aux serveurs sur site utilisant une PKI privée d'accéder aux services AWS sans informations d'identification AWS à long terme.

→Configurer IAM Roles Anywhere. Créer une ancre de confiance en utilisant le certificat de l'AC privée. Créer des profils associant les certificats aux rôles IAM. Les serveurs utilisent leurs certificats pour obtenir des informations d'identification AWS temporaires.

Pourquoi: Cela étend les rôles IAM aux charges de travail externes en tirant parti de la PKI existante, éliminant le besoin de gérer les clés d'accès AWS sur site.

Empêcher le déploiement de ressources non conformes définies dans les modèles CloudFormation *avant* qu'elles ne soient provisionnées.

→Activer les contrôles proactifs d'AWS Control Tower. Ceux-ci utilisent des hooks CloudFormation pour valider les configurations de ressources par rapport aux politiques (écrites en cfn-guard) avant le provisionnement.

Pourquoi: Il s'agit d'un contrôle "shift-left" qui prévient les erreurs de configuration à la source, ce qui est plus efficace que de les détecter et de les corriger après leur déploiement.