# Protection de l’infrastructure
La protection des infrastructures englobe les méthodes de contrôle, telles que la défense en profondeur, qui sont nécessaires pour répondre aux bonnes pratiques et aux obligations organisationnelles ou réglementaires. L’utilisation de ces méthodologies est essentielle au succès des opérations en cours, que ce soit dans le cloud ou sur site.
La protection de l’infrastructure est un aspect essentiel du programme de sécurité des informations. Elle garantit que les systèmes et les services de votre charge de travail sont protégés contre les accès involontaires et non autorisés, et les failles potentielles. Par exemple, vous définirez des frontières de confiance (par exemple, limites de réseau et de comptes), la configuration et la maintenance de la sécurité du système (par exemple, renforcement, minimisation et correction), l’authentification et les autorisations du système d’exploitation (par exemple, utilisateurs, clés et niveaux d’accès) et d’autres points d’application de stratégie appropriés (par exemple, pare-feu d’applications Web et/ou passerelles API).
**Régions, zones de disponibilité, AWS Local Zones et AWS Outposts**
Assurez-vous de connaître les régions, les zones de disponibilité, les [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) et les [AWS Outposts](https://aws.amazon.com/outposts/), qui sont des composants de l’infrastructure globale sécurisée AWS.
AWS utilise le concept de région, qui est un emplacement physique dans le monde où nous regroupons des centres de données. Nous appelons chaque groupe de centres de données logiques une zone de disponibilité (AZ). Chaque région AWS se compose de plusieurs AZ isolées et physiquement séparées au sein d’une zone géographique. Si vous devez respecter des exigences de situation géographique des données, vous pouvez choisir la région AWS la plus proche de l’emplacement souhaité. Vous conservez le contrôle total et la propriété de la région dans laquelle vos données se trouvent physiquement, ce qui facilite le respect des exigences locales de conformité et de localisation des données. Chaque AZ dispose de systèmes d’électricité, de climatisation et de sécurité physique indépendants. Si une application est partitionnée sur plusieurs AZ, vous êtes mieux isolé et protégé contre les problèmes tels que les pannes de courant, la foudre, les tornades, les tremblements de terre, etc. Les AZ sont physiquement séparées par une distance de plusieurs kilomètres des autres AZ, mais elles se trouvent toutes à 100 km de distance les unes des autres. Toutes les AZ d’une régionAWS sont interconnectées avec un réseau à large bande passante et à faible latence, qui utilise une fibre métropolitaine dédiée entièrement redondante fournissant un réseau à haut débit et à faible latence entre les AZ. Tout le trafic entre les AZ est chiffré. Les clients AWS axés sur la haute disponibilité peuvent concevoir leurs applications pour qu’elles s’exécutent dans plusieurs zones de disponibilité afin d’obtenir une tolérance aux pannes encore plus grande. AWS Les régions répondent aux niveaux les plus élevés de sécurité, de conformité et de protection des données.
AWS Local Zones placent le calcul, le stockage, la base de données et d’autres services AWS spécifiques plus près des utilisateurs finaux. Avec AWS Local Zones, vous pouvez facilement exécuter des applications très exigeantes qui nécessitent des latences de quelques millisecondes pour vos utilisateurs finaux, telles que la création de contenu multimédia et de divertissement, les jeux en temps réel, les simulations de réservoir, l’automatisation de la conception électronique et le machine learning. Chaque emplacement AWS Local Zone est une extension d’une région AWS dans laquelle vous pouvez exécuter vos applications sensibles à la latence, à l’aide de services AWS tels qu’Amazon EC2, Amazon VPC, Amazon EBS, Amazon File Storage et Elastic Load Balancing à proximité géographique des utilisateurs finaux. Les AWS Local Zones fournissent une connexion sécurisée à haut débit entre les charges de travail locales et celles qui s’exécutent dans la région AWS, vous permettant de vous connecter de manière transparente à la gamme complète de services dans la région via les mêmes API et ensembles d’outils.
AWS Outposts offre les services, l’infrastructure et les modèles d’exploitation AWS natifs à la quasi-totalité de centres de données, d’espaces de colocalisation d’infrastructures ou d’installations sur site. Vous pouvez utiliser les mêmes API, outils et infrastructures AWS dans les installations sur site et dans le cloud AWS pour offrir une expérience hybride vraiment cohérente. AWS Outposts est conçu pour les environnements connectés et permet de prendre en charge les charges de travail qui doivent rester sur site en raison d’une faible latence ou de besoins de traitement de données locaux.
Dans AWS, il existe un certain nombre d’approches pour protéger l’infrastructure. Les sections suivantes décrivent comment utiliser ces approches.
**Topics**
+ [Protection des réseaux](protecting-networks.md)
+ [Protection du calcul](protecting-compute.md)
# Protection des réseaux
Les utilisateurs, tant au sein de votre personnel que de vos clients, peuvent être situés n’importe où. Vous devez vous éloigner des modèles traditionnels visant à accepter tout le monde et tout ce qui a accès à votre réseau. Lorsque vous suivez le principe d’application de la sécurité à toutes les couches, vous adoptez une approche [confiance zéro](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/). La sécurité zéro confiance est un modèle dans lequel les composants d’application ou les microservices sont considérés comme distincts les uns des autres. Aucun composant ou microservice ne fait confiance à un autre.
La planification et la gestion minutieuses de la conception de votre réseau constituent la base même de votre action pour isoler les ressources dans le cadre de votre charge de travail. Comme de nombreuses ressources de votre charge de travail opèrent dans un VPC et héritent des propriétés de sécurité, il est essentiel que la conception soit soutenue par des mécanismes d’inspection et de protection basés sur l’automatisation. De même, pour les charges de travail qui fonctionnent en dehors d’un VPC, en utilisant des services purement périphériques et/ou sans serveur, les bonnes pratiques s’appliquent dans une approche plus simple. Reportez-vous à [AWS Well-Architected : Présentation à la loupe des applications sans serveur](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html) pour obtenir des conseils sur la sécurité sans serveur.
**Topics**
+ [SEC05-BP01 Créer des couches réseau](sec_network_protection_create_layers.md)
+ [SEC05-BP02 Contrôler le flux de trafic au sein de vos couches réseau](sec_network_protection_layered.md)
+ [SEC05-BP03 Mettre en œuvre une protection basée sur l'inspection](sec_network_protection_inspection.md)
+ [SEC05-BP04 Automatiser la protection du réseau](sec_network_auto_protect.md)
# SEC05-BP01 Créer des couches réseau
Segmentez la topologie de votre réseau en différentes couches en procédant à des regroupements logiques des composants de votre charge de travail en fonction de la sensibilité des données et de leurs exigences en matière d’accès. Faites la distinction entre les composants qui requièrent un accès entrant depuis Internet, comme les points de terminaison Web publics, et ceux qui requièrent uniquement un accès interne, comme les bases de données.
**Résultat souhaité :** les couches de votre réseau font partie d’une approche intégrée de défense en profondeur de la sécurité qui complète la stratégie d’authentification et d’autorisation des identités de vos charges de travail. Les couches sont positionnées en fonction de la sensibilité des données et des exigences d’accès, avec des mécanismes de flux de trafic et de contrôle appropriés.
**Anti-modèles courants :**
+ Vous créez toutes les ressources dans un seul VPC ou sous-réseau.
+ Vous construisez vos couches réseau sans tenir compte des exigences de sensibilité des données, du comportement des composants ou des fonctionnalités.
+ Vous utilisez les VPC et les sous-réseaux par défaut pour toutes les considérations relatives à la couche réseau et vous ne tenez pas compte de l’influence des services gérés par AWS sur votre topologie.
**Avantages du respect de cette bonne pratique :** la mise en place de couches réseau est la première étape pour limiter les chemins inutiles à travers le réseau, en particulier ceux qui mènent à des systèmes et à des données critiques. Il est donc plus difficile pour les acteurs non autorisés d’accéder à votre réseau et aux ressources supplémentaires qu’il contient. Les couches réseau individuelles présentent l’avantage de réduire la portée de l’analyse des systèmes d’inspection, par exemple pour la détection des intrusions ou la prévention des programmes malveillants. Cela réduit le risque de faux positifs et les frais de traitement inutiles.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Lors de la conception d’une architecture de charge de travail, il est courant de séparer les composants en différentes couches en fonction de leur responsabilité. Par exemple, une application Web peut comporter une couche de présentation, une couche d’application et une couche de données. Vous pouvez adopter une approche similaire lors de la conception de la topologie de votre réseau. Les contrôles réseau sous-jacents peuvent vous aider à faire respecter les exigences d’accès aux données de votre charge de travail. Par exemple, dans une architecture d’application Web à trois niveaux, vous pouvez stocker vos fichiers de couche de présentation statique sur [Amazon S3](https://aws.amazon.com/s3/) et les diffuser à partir d’un réseau de diffusion de contenu (CDN), tel qu’[Amazon CloudFront](https://aws.amazon.com/cloudfront/). La couche application peut comporter des points de terminaison publics qu’un [Application Load Balancer (ALB)](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/) sert dans un sous-réseau public [Amazon VPC](https://aws.amazon.com/vpc/) (similaire à une zone démilitarisée, ou DMZ), les services principaux étant déployés dans des sous-réseaux privés. La couche de données, qui héberge des ressources telles que des bases de données et des systèmes de fichiers partagés, peut résider dans des sous-réseaux privés différents des ressources de votre couche d’application. À chacune de ces limites de couche (CDN, sous-réseau public, sous-réseau privé), vous pouvez déployer des contrôles qui permettent uniquement au trafic autorisé de franchir ces limites.
Comme pour la modélisation des couches réseau en fonction de l’objectif fonctionnel des composants de votre charge de travail, tenez également compte de la sensibilité des données traitées. Dans l’exemple de l’application Web, bien que tous vos services de charge de travail puissent résider dans la couche d’application, différents services peuvent traiter des données avec des niveaux de sensibilité différents. Le cas échéant, il peut être approprié de diviser la couche d’application en utilisant plusieurs sous-réseaux privés, différents VPC dans le même Compte AWS, voire différents VPC dans différents Comptes AWS pour chaque niveau de sensibilité des données, en fonction de vos exigences de contrôle.
La cohérence du comportement des composants de votre charge de travail est un autre facteur à prendre en compte pour les couches réseau. Si nous poursuivons avec le même exemple, dans la couche d’application, vous pouvez avoir des services qui acceptent des entrées provenant d’utilisateurs finaux ou d’intégrations de systèmes externes qui sont intrinsèquement plus risquées que les entrées d’autres services. Il peut notamment s’agir du téléchargement de fichiers, de scripts de code à exécuter, de l’analyse d’e-mails, etc. Le fait de placer ces services dans leur propre couche réseau contribue à créer une limite d’isolation plus forte autour d’eux et peut empêcher leur comportement unique de créer des alertes faussement positives dans les systèmes d’inspection.
Dans le cadre de votre conception, réfléchissez à l’influence de l’utilisation des services gérés par AWS sur la topologie de votre réseau. Découvrez comment des services tels qu’[Amazon VPC Lattice](https://aws.amazon.com/vpc/lattice/) peuvent faciliter l’interopérabilité des composants de votre charge de travail entre les couches réseau. Lors de l’utilisation de [AWS Lambda](https://aws.amazon.com/lambda/), effectuez le déploiement dans vos sous-réseaux VPC, sauf s’il y a raisons spécifiques de ne pas le faire. Déterminez où les points de terminaison d’un VPC et [AWS PrivateLink](https://aws.amazon.com/privatelink/) peuvent simplifier le respect des politiques de sécurité qui limitent l’accès aux passerelles Internet.
### Étapes d’implémentation
1. Passez en revue l’architecture de votre charge de travail. Regroupez logiquement les composants et les services selon les fonctions qu’ils remplissent, la sensibilité des données traitées et leur comportement.
1. En ce qui concerne les composants qui répondent à des demandes provenant d’Internet, pensez à utiliser des équilibreurs de charge ou d’autres proxys pour fournir des points de terminaison publics. Explorez l’évolution des contrôles de sécurité en utilisant des services gérés, tels que CloudFront, [Amazon API Gateway](https://aws.amazon.com/api-gateway/), Elastic Load Balancing, et [AWS Amplify](https://aws.amazon.com/amplify/) pour héberger des points de terminaison publics.
1. Pour les composants exécutés dans des environnements informatiques, tels que les instances Amazon EC2, les conteneurs [AWS Fargate](https://aws.amazon.com/fargate/) ou les fonctions Lambda, déployez-les dans des sous-réseaux privés en fonction de vos groupes dès la première étape.
1. Pour les services AWS entièrement gérés, tels qu’[Amazon DynamoDB](https://aws.amazon.com/dynamodb/), [Amazon Kinesis](https://aws.amazon.com/kinesis/) ou [Amazon SQS](https://aws.amazon.com/sqs/), envisagez d’utiliser des points de terminaison d’un VPC par défaut pour l’accès via des adresses IP privées.
## Ressources
**Bonnes pratiques associées :**
+ [REL02 Planification de votre topologie réseau](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html)
+ [PERF04-BP01 Compréhension de l’impact de la mise en réseau sur les performances](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_networking_understand_how_networking_impacts_performance.html)
**Vidéos connexes :**
+ [AWS re:Invent 2023 - AWS networking foundations](https://www.youtube.com/watch?v=8nNurTFy-h4)
**Exemples connexes :**
+ [Exemples de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-examples-intro.html)
+ [Access container applications privately on Amazon ECS by using AWS Fargate, AWS PrivateLink, and a Network Load Balancer](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html)
+ [Serve static content in an Amazon S3 bucket through a VPC by using Amazon CloudFront](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.html)
# SEC05-BP02 Contrôler le flux de trafic au sein de vos couches réseau
Au sein des couches de votre réseau, segmentez davantage pour limiter le trafic uniquement aux flux nécessaires à chaque charge de travail. Tout d’abord, concentrez-vous sur le contrôle du trafic entre Internet ou d’autres systèmes externes vers une charge de travail et votre environnement (trafic *nord-sud*). Ensuite, examinez les flux entre les différents composants et systèmes (trafic *est-ouest*).
**Résultat souhaité :** vous autorisez uniquement les flux réseau nécessaires aux composants de vos charges de travail pour communiquer entre eux, avec leurs clients et avec tout autre service dont ils dépendent. Votre conception prend en compte des facteurs tels que les entrées et sorties publiques par rapport aux entrées et sorties privées, la classification des données, les réglementations régionales et les exigences en matière de protocole. Dans la mesure du possible, vous privilégiez les flux point à point par rapport à l’appairage réseau dans le cadre du *principe du moindre privilège*.
**Anti-modèles courants :**
+ Vous adoptez une approche de la sécurité du réseau basée sur le périmètre et vous ne contrôlez le flux de trafic qu’à la limite des couches de votre réseau.
+ Vous supposez que tout le trafic au sein d’une couche réseau est authentifié et autorisé.
+ Vous appliquez des contrôles à votre trafic d’entrée ou de sortie, mais pas aux deux.
+ Vous vous fiez uniquement aux composants de votre charge de travail et aux contrôles réseau pour authentifier et autoriser le trafic.
**Avantages du respect de cette bonne pratique :** cette pratique permet de réduire le risque de mouvements non autorisés au sein de votre réseau et ajoute une couche d’autorisation supplémentaire à vos charges de travail. En contrôlant le flux de trafic, vous pouvez limiter l’ampleur de l’impact d’un incident de sécurité et accélérer la détection et la réponse.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Alors que les couches réseau aident à définir les limites entre les composants de votre charge de travail qui remplissent une fonction, un niveau de sensibilité des données et un comportement similaires, vous pouvez créer un niveau de contrôle du trafic nettement plus précis en utilisant des techniques permettant de segmenter davantage les composants au sein de ces couches, conformément au principe du moindre privilège. Au sein de AWS, les couches de réseau se caractérisent avant tout selon des plages d’adresse IP au sein d’un VPC Amazon. Les couches peuvent également être définies à l’aide de différents VPC, par exemple pour regrouper les environnements de microservices par domaine d’activité. Lorsque vous utilisez plusieurs VPC, négociez le routage à l’aide d’un [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/). Bien que cela permette de contrôler le trafic au niveau de la couche 4 (adresses IP et plages de ports) à l’aide de groupes de sécurité et de tables de routage, vous pouvez renforcer le contrôle grâce à des services supplémentaires, tels que [AWS PrivateLink](https://aws.amazon.com/privatelink/), le [pare-feu DNS Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html), [AWS Network Firewall](https://aws.amazon.com/network-firewall/) et [AWS WAF](https://aws.amazon.com/waf/).
Comprenez et inventoriez le flux de données et les exigences de communication de vos charges de travail en termes de parties initiatrices de connexion, de ports, de protocoles et de couches réseau. Évaluez les protocoles disponibles pour établir des connexions et transmettre des données afin de sélectionner ceux qui répondent à vos exigences de protection (par exemple, HTTPS plutôt que HTTP). Capturez ces exigences à la fois aux limites de vos réseaux et au sein de chaque couche. Une fois ces exigences identifiées, explorez les options permettant d’autoriser uniquement le trafic requis à circuler à chaque point de connexion. Un bon point de départ consiste à utiliser des *groupes de sécurité* au sein de votre VPC, car ils peuvent être associés à des ressources utilisant une interface réseau Elastic (ENI), telles que des instances Amazon EC2, des tâches Amazon ECS, des pods Amazon EKS ou des bases de données Amazon RDS. Contrairement à un pare-feu de couche 4, un groupe de sécurité peut avoir une règle qui autorise le trafic provenant d’un autre groupe de sécurité en fonction de son identifiant, minimisant ainsi les mises à jour à mesure que les ressources du groupe changent au fil du temps. Vous pouvez également filtrer le trafic à l’aide de règles entrantes et sortantes à l’aide de groupes de sécurité.
Lorsque le trafic se déplace entre des VPC, il est courant d’utiliser l’appairage de VPC pour un routage simple ou AWS Transit Gateway pour un routage complexe. Grâce à ces approches, vous facilitez les flux de trafic entre la plage d’adresses IP des réseaux source et de destination. Toutefois, si votre charge de travail ne nécessite que des flux de trafic entre des composants spécifiques de différents VPC, envisagez d’utiliser une connexion point à point à l’aide de [AWS PrivateLink](https://aws.amazon.com/privatelink/). Pour ce faire, identifiez quel service doit agir en tant que producteur et lequel doit agir en tant que consommateur. Déployez un équilibreur de charge compatible pour le producteur, activez PrivateLink en conséquence, puis acceptez une demande de connexion du consommateur. Le service producteur se voit ensuite attribuer une adresse IP privée provenant du VPC du consommateur, que celui-ci peut utiliser pour effectuer des demandes ultérieures. Cette approche réduit le besoin d’appairage entre les réseaux. Incluez les coûts du traitement des données et de l’équilibrage de charge dans le cadre de l’évaluation de PrivateLink.
Bien que les groupes de sécurité et PrivateLink aident à contrôler le flux entre les composants de vos charges de travail, il est également important de savoir comment contrôler les domaines DNS auxquels vos ressources sont autorisées à accéder (le cas échéant). En fonction de la configuration DHCP de vos VPC, vous pouvez envisager deux services AWS différents à cette fin. La plupart des clients utilisent le service DNS Route 53 Resolver par défaut (également appelé serveur Amazon DNS ou AmazonProvideDDNS) disponible pour les VPC à l’adresse \$12 de leur plage d’adresses CIDR. Avec cette approche, vous pouvez créer des règles de pare-feu DNS et les associer à votre VPC afin de déterminer les actions à entreprendre pour les listes de domaines que vous fournissez.
Si vous n’utilisez pas le Route 53 Resolver, ou si vous souhaitez le compléter par des fonctionnalités d’inspection et de contrôle de flux plus approfondies allant au-delà du filtrage de domaine, envisagez de déployer un AWS Network Firewall. Ce service inspecte les paquets individuels en utilisant des règles sans ou avec état afin de déterminer s’il est nécessaire de refuser ou d’autoriser le trafic. Vous pouvez adopter une approche similaire pour filtrer le trafic Web entrant vers vos points de terminaison publics à l’aide de AWS WAF. Pour plus d’informations sur ces services, voir [SEC05-BP03 Mettre en œuvre une protection basée sur l’inspection](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html).
### Étapes d’implémentation
1. Identifiez les flux de données requis entre les composants de vos charges de travail.
1. Appliquez plusieurs contrôles avec une approche de défense en profondeur pour le trafic entrant et sortant, notamment en utilisant des groupes de sécurité et des tables de routage.
1. Utilisez des pare-feux pour définir un contrôle précis du trafic réseau entrant, sortant et transitant par vos VPC, comme Route 53 Resolver DNS Firewall, AWS Network Firewall et AWS WAF. Envisagez d’utiliser le [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/) pour configurer et gérer de manière centralisée les règles de pare-feu au sein de votre organisation.
## Ressources
**Bonnes pratiques associées :**
+ [REL03-BP01 Choisir comment segmenter votre charge de travail](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_service_architecture_monolith_soa_microservice.html)
+ [SEC09-BP02 Application du chiffrement en transit](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_data_transit_encrypt.html)
**Documents connexes :**
+ [Bonnes pratiques de sécurité pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html)
+ [Conseils d’optimisation du réseau AWS](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-network-optimization-tips/)
+ [Conseils pour la sécurité du réseau sur AWS](https://aws.amazon.com/solutions/guidance/network-security-on-aws/)
+ [Sécuriser le trafic réseau sortant de votre VPC dans le AWS Cloud](https://docs.aws.amazon.com/prescriptive-guidance/latest/secure-outbound-network-traffic/welcome.html)
**Outils associés :**
+ [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/)
**Vidéos connexes :**
+ [AWS Transit Gateway reference architectures for many VPCs](https://youtu.be/9Nikqn_02Oc)
+ [Accélération et protection des applications avec Amazon CloudFront, AWS WAF, et AWS Shield](https://youtu.be/0xlwLEccRe0)
+ [AWS re:Inforce 2023: Firewalls and where to put them](https://www.youtube.com/watch?v=lTJxWAiQrHM)
# SEC05-BP03 Mettre en œuvre une protection basée sur l'inspection
Configurez des points d’inspection du trafic entre les couches de votre réseau afin de vous assurer que les données en transit correspondent aux catégories et aux modèles attendus. Analysez les flux de trafic, les métadonnées et les modèles pour identifier et détecter les événements, et y répondre plus efficacement.
**Résultat souhaité :** le trafic qui passe d’une couche à l’autre de votre réseau est inspecté et autorisé. Les décisions d’autorisation et de refus sont basées sur des règles explicites, des informations sur les menaces et des écarts par rapport aux comportements de base. Les protections deviennent plus strictes à mesure que le trafic se rapproche des données sensibles.
**Anti-modèles courants :**
+ S’appuyer uniquement sur les règles de pare-feu basées sur les ports et les protocoles. Ne pas tirer parti des systèmes intelligents.
+ Créer des règles de pare-feu basées sur des modèles de menaces actuels spécifiques susceptibles de changer.
+ Inspecter uniquement le trafic transitant des sous-réseaux privés vers des sous-réseaux publics, ou des sous-réseaux publics vers Internet.
+ Ne pas disposer d’une vue de base de votre trafic réseau à utiliser à titre de comparaison afin de détecter les anomalies de comportement.
**Avantages du respect de cette bonne pratique :** les systèmes d’inspection vous permettent de créer des règles intelligentes, telles que l’autorisation ou le refus du trafic uniquement lorsque certaines conditions relatives aux données de trafic existent. Bénéficiez d'ensembles de règles gérés par les partenaires AWS et basés sur les informations les plus récentes sur les menaces, à mesure que le paysage des menaces évolue au fil du temps. Cela réduit les frais liés à la mise à jour des règles et à la recherche d’indicateurs de compromis, réduisant ainsi le risque de faux positifs.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Contrôlez avec précision votre trafic réseau dynamique et apatride à l'aide AWS Network Firewall d'autres [pare-feux](https://aws.amazon.com/marketplace/search/results?searchTerms=firewalls) et [systèmes de prévention des intrusions](https://aws.amazon.com/marketplace/search/results?searchTerms=Intrusion+Prevention+Systems) (IPS) AWS Marketplace que vous pouvez déployer derrière un Gateway Load [Balancer](https://aws.amazon.com/elasticloadbalancing/gateway-load-balancer/) (). GWLB AWS Network Firewall prend en charge les IPS spécifications open source [compatibles avec Suricata](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-ips.html) pour protéger votre charge de travail.
Les solutions AWS Network Firewall des fournisseurs qui utilisent un GWLB prennent en charge différents modèles de déploiement de l'inspection en ligne. Par exemple, vous pouvez effectuer une inspection sur une VPC base individuelle, la centraliser dans le cadre d'une inspection VPC ou la déployer dans un modèle hybride dans lequel le trafic est-ouest passe par une inspection VPC et où les entrées Internet sont inspectées par inspection. VPC Une autre considération est de savoir si la solution prend en charge le déballage de Transport Layer Security (TLS), permettant une inspection approfondie des paquets pour les flux de trafic initiés dans les deux sens. Pour plus d’informations et des détails détaillés sur ces configurations, consultez le [guide des bonnes pratiques AWS Network Firewall](https://aws.github.io/aws-security-services-best-practices/guides/network-firewall/).
[Si vous utilisez des solutions qui effectuent des out-of-band inspections, telles que l'analyse pcap des données par paquets provenant d'interfaces réseau fonctionnant en mode promiscuité, vous pouvez configurer VPC la mise en miroir du trafic.](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) Le trafic en miroir est pris en compte dans la bande passante disponible de vos interfaces et il est soumis aux mêmes frais de transfert de données que le trafic non mis en miroir. Vous pouvez voir si des versions virtuelles de ces appliances sont disponibles sur le [AWS Marketplace](https://aws.amazon.com/marketplace/solutions/infrastructure-software/cloud-networking), qui peut prendre en charge le déploiement en ligne derrière unGWLB.
Pour les composants qui effectuent des transactions via des protocoles HTTP basés, protégez votre application contre les menaces courantes à l'aide d'un pare-feu pour applications Web (WAF). [AWS WAF](https://aws.amazon.com/waf)est un pare-feu d'applications Web qui vous permet de surveiller et de bloquer les demandes HTTP (S) conformes à vos règles configurables avant de les envoyer à Amazon API Gateway CloudFront, Amazon AWS AppSync ou à un Application Load Balancer. Envisagez une inspection approfondie des paquets lorsque vous évaluez le déploiement de votre pare-feu d'applications Web, car certains nécessitent que vous vous arrêtiez TLS avant d'inspecter le trafic. Pour commencer AWS WAF, vous pouvez l'utiliser [AWS Managed Rules](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html#getting-started-wizard-add-rule-group)en combinaison avec les vôtres ou utiliser les [intégrations de partenaires](https://aws.amazon.com/waf/partners/) existantes.
Vous pouvez gérer de manière centralisée AWS WAF, AWS Shield Advanced AWS Network Firewall, et les groupes VPC de sécurité Amazon au sein de votre AWS organisation avec [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/).
## Étapes d’implémentation
1. Déterminez si vous pouvez élargir la portée des règles d'inspection, par exemple par le biais d'une inspectionVPC, ou si vous avez besoin d'une approche plus précise par VPC approche.
1. Pour les solutions d’inspection en ligne :
1. Si vous l'utilisez AWS Network Firewall, créez des règles, des politiques de pare-feu et le pare-feu lui-même. Une fois ceux-ci configurés, vous pouvez [acheminer le trafic vers le point de terminaison du pare-feu](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/) pour permettre l’inspection.
1. Si vous utilisez une appliance tierce avec un Gateway Load Balancer (GWLB), déployez et configurez votre appliance dans une ou plusieurs zones de disponibilité. Créez ensuite votreGWLB, le service de point de terminaison, le point de terminaison et configurez le routage de votre trafic.
1. Pour les solutions out-of-band d'inspection :
1. Activez la mise en miroir VPC du trafic sur les interfaces où le trafic entrant et sortant doit être reflété. Vous pouvez utiliser EventBridge les règles Amazon pour appeler une AWS Lambda fonction afin d'activer la mise en miroir du trafic sur les interfaces lorsque de nouvelles ressources sont créées. Dirigez les sessions de mise en miroir du trafic vers le Network Load Balancer situé devant votre appareil qui traite le trafic.
1. Pour les solutions de trafic Web entrant :
1. Pour configurer AWS WAF, commencez par configurer une liste de contrôle d'accès Web (WebACL). Le Web ACL est un ensemble de règles comportant une action par défaut (ALLOWouDENY) traitée en série qui définit la manière dont vous gérez le WAF trafic. Vous pouvez créer vos propres règles et groupes ou utiliser des groupes de règles AWS gérés sur votre site WebACL.
1. Une fois votre site Web ACL configuré, associez-le à une AWS ressource (Application Load Balancer, API Gateway REST API ou CloudFront distribution, par exemple) pour commencer à protéger le trafic Web. ACL
## Ressources
**Documents connexes :**
+ [Qu’est-ce que le Traffic Mirroring ?](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html)
+ [Mise en œuvre de l’inspection du trafic en ligne à l’aide d’appareils de sécurité tiers](https://docs.aws.amazon.com/prescriptive-guidance/latest/inline-traffic-inspection-third-party-appliances/welcome.html)
+ [AWS Network Firewall exemples d'architectures avec routage](https://docs.aws.amazon.com/network-firewall/latest/developerguide/architectures.html)
+ [Architecture d'inspection centralisée avec AWS Gateway Load Balancer et AWS Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/)
**Exemples connexes :**
+ [Bonnes pratiques pour le déploiement de Gateway Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/)
+ [TLSconfiguration d'inspection pour le trafic de sortie crypté et AWS Network Firewall](https://aws.amazon.com/blogs/security/tls-inspection-configuration-for-encrypted-egress-traffic-and-aws-network-firewall/)
**Outils associés :**
+ [AWS Marketplace IDS/IPS](https://aws.amazon.com/marketplace/search/results?prevFilters=%257B%2522id%2522%3A%25220ed48363-5064-4d47-b41b-a53f7c937314%2522%257D&searchTerms=ids%2Fips)
# SEC05-BP04 Automatiser la protection du réseau
Automatisez le déploiement des protections de votre réseau à l'aide de DevOps pratiques telles que l'*infrastructure sous forme de code* (IaC) et les pipelines CI/CD. Ces pratiques peuvent vous aider à suivre les modifications apportées aux protections de votre réseau via un système de contrôle de version, à réduire le temps nécessaire au déploiement des modifications et à détecter si les protections de votre réseau s’écartent de la configuration souhaitée.
**Résultat souhaité :** vous définissez les protections du réseau à l’aide de modèles et vous les validez dans un système de contrôle de version. Les pipelines automatisés sont lancés lorsque de nouvelles modifications sont apportées pour orchestrer les tests et le déploiement. Des vérifications des politiques et d’autres tests statiques sont en place pour valider les modifications avant le déploiement. Vous déployez les modifications dans un environnement intermédiaire afin de vérifier que les contrôles fonctionnent comme prévu. Le déploiement dans vos environnements de production est également effectué automatiquement une fois les contrôles approuvés.
**Anti-modèles courants :**
+ Attendre de chaque équipe responsable de la charge de travail qu’elle définisse individuellement sa pile réseau complète, ses protections et ses automatisations. Ne pas publier les aspects standard de la pile réseau et des protections de manière centralisée pour que les équipes chargées de la charge de travail puissent les utiliser.
+ S’appuyer sur une équipe réseau centrale pour définir tous les aspects du réseau, les protections et les automatisations. Ne pas déléguer les aspects spécifiques à la charge de travail de la pile réseau et des protections à l’équipe responsable de cette charge de travail.
+ Trouver le juste équilibre entre la centralisation et la délégation entre une équipe réseau et les équipes responsables des charges de travail, sans appliquer des normes de test et de déploiement cohérentes à vos modèles IaC et à vos pipelines CI/CD. Ne pas capturer les configurations requises dans les outils qui vérifient la conformité de vos modèles.
**Avantages du respect de cette bonne pratique :** l’utilisation de modèles pour définir les protections de votre réseau vous permet de suivre et de comparer les modifications au fil du temps avec un système de contrôle de version. L’utilisation de l’automatisation pour tester et déployer les modifications crée de la standardisation et de la prévisibilité, ce qui augmente les chances de réussite du déploiement et réduit les configurations manuelles répétitives.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Un certain nombre de contrôles de protection réseau décrits dans [SEC05-BP02 Contrôlez les flux de trafic au sein de vos couches réseau](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_layered.html) et [SEC05-BP03 Mettre en œuvre une protection basée sur l'inspection s'accompagnent de](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html) systèmes de règles gérés qui peuvent être mis à jour automatiquement en fonction des dernières informations sur les menaces. Les exemples de protection de vos points de terminaison Web incluent les [règles AWS WAF gérées](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups.html) et l'[DDoSatténuation AWS Shield Advanced automatique de la couche d'application](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-automatic-app-layer-response.html). Utilisez des [groupes de règles gérées AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/nwfw-managed-rule-groups.html) pour vous tenir au courant des listes de domaines de mauvaise réputation et des signatures de menaces.
Au-delà des règles gérées, nous vous recommandons d'utiliser DevOps des pratiques pour automatiser le déploiement des ressources de votre réseau, des protections et des règles que vous spécifiez. Vous pouvez capturer ces définitions dans [AWS CloudFormation](https://aws.amazon.com/cloudformation/) ou dans un autre outil d’*infrastructure en tant que code* (IaC) de votre choix, les valider dans un système de contrôle de version et les déployer à l’aide de pipelines CI/CD. Utilisez cette approche DevOps pour bénéficier des avantages traditionnels de la gestion des contrôles de votre réseau, tels que des versions plus prévisibles, des tests automatisés à l'aide d'outils tels que [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html), et la détection des écarts entre votre environnement déployé et la configuration souhaitée.
Sur la base des décisions que vous avez prises dans le cadre de [SEC05-BP01 Create network layers](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_create_layers.html), vous pouvez avoir adopté une approche de gestion centralisée pour créer VPCs des couches dédiées aux flux d'entrée, de sortie et d'inspection. Comme décrit dans l'[architecture AWS de référence de sécurité (AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture), vous pouvez les définir VPCs dans un [compte d'infrastructure réseau](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html) dédié. Vous pouvez utiliser des techniques similaires pour définir de manière centralisée les charges de travail VPCs utilisées dans d'autres comptes, leurs groupes de sécurité, leurs AWS Network Firewall déploiements, les règles du résolveur Route 53 et les configurations de DNS pare-feu, ainsi que d'autres ressources réseau. Vous pouvez partager ces ressources avec vos autres comptes grâce à [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html). Cette approche vous permet de simplifier les tests automatisés et le déploiement de vos contrôles réseau sur le compte Réseau, en ne gérant qu’une seule destination. Vous pouvez le faire dans un modèle hybride, dans lequel vous déployez et partagez certains contrôles de manière centralisée et déléguez d’autres contrôles aux différentes équipes responsables des charges de travail et à leurs comptes respectifs.
## Étapes d’implémentation
1. Déterminez quels aspects du réseau et des protections sont définis de manière centralisée et quels aspects peuvent être gérés par vos équipes qui s’occupent des charges de travail.
1. Créez des environnements pour tester et déployer les modifications apportées à votre réseau et à ses protections. Par exemple, utilisez un compte de test réseau et un compte de production réseau.
1. Déterminez comment vous allez stocker et gérer vos modèles dans un système de contrôle de version. Stockez les modèles centraux dans un référentiel distinct des référentiels de charge de travail, tandis que les modèles de charge de travail peuvent être stockés dans des référentiels spécifiques à cette charge de travail.
1. Créez des pipelines CI/CD pour tester et déployer des modèles. Définissez des tests pour vérifier les erreurs de configuration et vérifier que les modèles sont conformes aux normes de votre entreprise.
## Ressources
**Bonnes pratiques associées :**
+ [SEC01-BP06 Automatiser le déploiement des contrôles de sécurité standard](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls)
**Documents connexes :**
+ [AWS Security Reference Architecture - Network account](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html)
**Exemples connexes :**
+ [Architecture de référence des pipelines de déploiement d’AWS](https://pipelines.devops.aws.dev/)
+ [NetDevSecOpspour moderniser les déploiements AWS réseau](https://aws.amazon.com/blogs/networking-and-content-delivery/netdevsecops-to-modernize-aws-networking-deployments/)
+ [Intégration des tests AWS CloudFormation de sécurité AWS Security Hub CSPM et AWS CodeBuild des rapports](https://aws.amazon.com/blogs/security/integrating-aws-cloudformation-security-tests-with-aws-security-hub-and-aws-codebuild-reports/)
**Outils associés :**
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
+ [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)
+ [cfn\$1nag](https://github.com/stelligent/cfn_nag)
# Protection du calcul
Les ressources de calcul incluent les instances EC2, les conteneurs, les fonctions AWS Lambda, les services de base de données, les appareils IoT, etc. Chacun de ces types de ressources de calcul nécessite des approches de sécurisation différentes. Cependant, ils partagent des stratégies communes que vous devez prendre en compte : défense en profondeur, gestion des vulnérabilités, réduction de la surface d’attaque, automatisation de la configuration et de l’exploitation et réalisation d’actions à distance. Dans cette section, vous découvrirez des conseils généraux permettant de protéger les ressources de calcul pour les services clés. Pour chaque service AWS utilisé, il est important de vérifier les recommandations de sécurité correspondantes dans la documentation du service.
**Topics**
+ [SEC06-BP01 Gérer les vulnérabilités](sec_protect_compute_vulnerability_management.md)
+ [SEC06-BP02 Provisionner des calculs à partir d'images renforcées](sec_protect_compute_hardened_images.md)
+ [SEC06-BP03 Réduire la gestion manuelle et l’accès interactif](sec_protect_compute_reduce_manual_management.md)
+ [SEC06-BP04 Valider l'intégrité du logiciel](sec_protect_compute_validate_software_integrity.md)
+ [SEC06-BP05 Automatiser la protection du calcul](sec_protect_compute_auto_protection.md)
# SEC06-BP01 Gérer les vulnérabilités
Analysez et éliminez fréquemment les vulnérabilités dans votre code, vos dépendances et votre infrastructure afin de vous protéger contre les nouvelles menaces.
**Résultat escompté :** vous disposez d’une solution qui analyse en permanence votre charge de travail pour détecter les vulnérabilités logicielles, les défauts potentiels et l’exposition involontaire au réseau. Vous avez établi des processus et des procédures pour identifier, hiérarchiser et corriger ces vulnérabilités en fonction de critères d’évaluation des risques. En outre, vous avez mis en place une gestion automatisée des correctifs pour vos instances de calcul. Votre programme de gestion des vulnérabilités est intégré au cycle de vie de votre développement logiciel, avec des solutions pour analyser votre code source dans le cadre du pipeline CI/CD.
**Anti-modèles courants :**
+ Absence de programme de gestion des vulnérabilités.
+ Application de correctifs système sans tenir compte de la gravité ni de l’évitement des risques.
+ Utilisation d’un logiciel dont la date de fin de vie (EOL) a été dépassée.
+ Déploiement du code en production avant de l’analyser afin de détecter tout problème de sécurité.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
La gestion des vulnérabilités est essentielle au maintien d’un environnement cloud sécurisé et robuste. Elle implique un processus complet qui inclut des analyses de sécurité, l’identification et la hiérarchisation des problèmes, ainsi que des opérations d’application de correctifs pour résoudre les vulnérabilités identifiées. L’automatisation joue un rôle essentiel dans ce processus car elle facilite l’analyse continue des charges de travail pour détecter d’éventuels problèmes et une exposition involontaire du réseau, ainsi que les efforts de correction.
Le [modèle de responsabilité partagée AWS](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/shared-responsibility.html) est un concept fondamental qui sous-tend la gestion des vulnérabilités. Selon ce modèle, AWS est responsable de la sécurisation de l’infrastructure sous-jacente, y compris du matériel, des logiciels, de la mise en réseau et des installations exécutant les services AWS. À l’inverse, vous êtes responsable de la sécurisation de vos données, des configurations de sécurité et des tâches de gestion associées aux services tels que les instances Amazon EC2 et les objets Amazon S3.
AWS propose une gamme de services pour soutenir les programmes de gestion des vulnérabilités. [Amazon Inspector](https://aws.amazon.com/inspector/) analyse en permanence les charges de travail AWS pour détecter les vulnérabilités logicielles et les accès réseau involontaires, tandis que le [Gestionnaire de correctifs d’AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html) permet de gérer les correctifs sur l’ensemble des instances Amazon EC2. Ces services peuvent être intégrés à [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/), un service de gestion de la posture de sécurité dans le cloud qui automatise les contrôles de sécurité AWS, centralise les alertes de sécurité et fournit une vue complète de la posture de sécurité d’une organisation. De plus, la [sécurité Amazon CodeGuru](https://aws.amazon.com/codeguru/) utilise l’analyse du code statique pour identifier les problèmes potentiels dans les applications Java et Python pendant la phase de développement.
En incorporant les pratiques de gestion des vulnérabilités au cycle de vie du développement logiciel, vous pouvez traiter les vulnérabilités de manière proactive avant qu’elles soient introduites dans les environnements de production, ce qui réduit le risque d’événements de sécurité et minimise l’impact potentiel des vulnérabilités.
### Étapes d’implémentation
1. **Comprendre le modèle de responsabilité partagée :** passez en revue le modèle de responsabilité partagée AWS pour comprendre vos responsabilités en matière de sécurisation de vos charges de travail et de vos données dans le cloud. AWS est responsable de la sécurisation de l’infrastructure cloud sous-jacente, tandis que vous êtes responsable de la sécurisation de vos applications, de vos données et des services que vous utilisez.
1. **Mettre en œuvre une analyse des vulnérabilités :** configurez un service d’analyse des vulnérabilités, tel qu’Amazon Inspector, pour analyser automatiquement vos instances de calcul (par exemple, les machines virtuelles, les conteneurs ou les fonctions sans serveur) afin de détecter les vulnérabilités logicielles, les défauts potentiels et l’exposition involontaire du réseau.
1. **Établir des processus de gestion des vulnérabilités :** définissez des processus et des procédures pour identifier, hiérarchiser et corriger les vulnérabilités. Cela peut inclure la mise en place de programmes réguliers d’analyse des vulnérabilités, l’établissement de critères d’évaluation des risques et la définition de délais de correction en fonction de la gravité de la vulnérabilité.
1. **Configurer la gestion des correctifs :** utilisez un service de gestion des correctifs pour automatiser le processus d’application des correctifs à vos instances de calcul, tant pour les systèmes d’exploitation que pour les applications. Vous pouvez configurer le service pour rechercher les correctifs manquants dans les instances et les installer automatiquement selon un calendrier. Envisagez d’utiliser le Gestionnaire de correctifs d’AWS Systems Manager pour fournir cette fonctionnalité.
1. **Configurer une protection contre les programmes malveillants :** implémentez des mécanismes pour détecter les logiciels malveillants dans votre environnement. Par exemple, vous pouvez utiliser des outils tels qu’[Amazon GuardDuty](https://aws.amazon.com/guardduty/) pour analyser, détecter et signaler les logiciels malveillants dans les volumes EC2 et EBS. GuardDuty peut également analyser les objets récemment chargés sur Amazon S3 pour détecter d’éventuels logiciels malveillants ou virus et prendre des mesures pour les isoler avant qu’ils ne soient ingérés dans les processus en aval.
1. **Intégrer l’analyse des vulnérabilités dans les pipelines CI/CD :** si vous utilisez un pipeline CI/CD pour le déploiement de votre application, intégrez des outils d’analyse des vulnérabilités dans votre pipeline. Des outils tels que la sécurité Amazon CodeGuru et des options open source peuvent analyser votre code source, vos dépendances et vos artefacts pour détecter d’éventuels problèmes de sécurité.
1. **Configurer un service de surveillance de la sécurité :** configurez un service de surveillance de la sécurité, tel qu’AWS Security Hub CSPM, pour obtenir une vue complète de votre posture de sécurité sur plusieurs services cloud. Le service doit collecter les résultats de sécurité provenant de diverses sources et les présenter dans un format normalisé pour faciliter leur hiérarchisation et leur correction.
1. **Mettre en œuvre un test de pénétration des applications Web :** si votre application est une application Web et que votre organisation possède les compétences nécessaires ou peut engager une assistance extérieure, envisagez de mettre en œuvre un test de pénétration des applications Web afin d’identifier les vulnérabilités potentielles de votre application.
1. **Automatiser avec une infrastructure en tant que code :** utilisez des outils d’infrastructure en tant que code (IaC), tels qu’[AWS CloudFormation](https://aws.amazon.com/cloudformation/), pour automatiser le déploiement et la configuration de vos ressources, y compris les services de sécurité mentionnés précédemment. Cette pratique vous aide à créer une architecture de ressources plus cohérente et standardisée sur plusieurs comptes et environnements.
1. **Surveiller et améliorer continuellement** : surveillez en permanence l’efficacité de votre programme de gestion des vulnérabilités et apportez les améliorations nécessaires. Passez en revue les résultats de sécurité, évaluez l’efficacité de vos efforts de correction et ajustez vos processus et outils en conséquence.
## Ressources
**Documents connexes :**
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [Présentation de la sécurité de AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf)
+ [ Amazon CodeGuru ](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [ Gestion automatisée et améliorée des vulnérabilités pour les charges de travail dans le cloud grâce au nouvel Amazon Inspector ](https://aws.amazon.com/blogs/aws/improved-automated-vulnerability-management-for-cloud-workloads-with-a-new-amazon-inspector/)
+ [ Automatiser la gestion et la correction des vulnérabilités dans AWS à l’aide d’Amazon Inspector et AWS Systems Manager — Partie 1 ](https://aws.amazon.com/blogs/mt/automate-vulnerability-management-and-remediation-in-aws-using-amazon-inspector-and-aws-systems-manager-part-1/)
**Vidéos connexes :**
+ [Sécurisation des services sans serveur et de conteneur](https://youtu.be/kmSdyN9qiXY)
+ [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI)
# SEC06-BP02 Provisionner des calculs à partir d'images renforcées
Réduisez les possibilités d’accès involontaire à vos environnements d’exécution en les déployant à partir d’images renforcées. Acquérez uniquement les dépendances d’exécution, telles que les images de conteneurs et les bibliothèques d’applications, à partir de registres fiables et vérifiez leurs signatures. Créez vos propres registres privés pour stocker des images et des bibliothèques fiables à utiliser dans vos processus de création et de déploiement.
**Résultat souhaité :** vos ressources de calcul sont provisionnées à partir d’images de référence renforcées. Vous récupérez les dépendances externes, telles que les images de conteneurs et les bibliothèques d’applications, uniquement à partir de registres fiables et vous vérifiez leurs signatures. Celles-ci sont stockées dans des registres privés à des fins de référence pour vos processus de création et de déploiement. Vous analysez et mettez à jour régulièrement les images et les dépendances pour vous protéger contre les vulnérabilités récemment découvertes.
**Anti-modèles courants :**
+ Acquérir des images et des bibliothèques à partir de registres fiables, mais sans vérifier leur signature ni effectuer d’analyses de vulnérabilité avant de les utiliser.
+ Renforcer les images, mais ne pas les tester régulièrement pour détecter de nouvelles vulnérabilités ou ne pas les mettre à jour vers la dernière version.
+ Installer ou ne pas supprimer les packages logiciels qui ne sont pas nécessaires pendant le cycle de vie prévu de l’image.
+ S’appuyer uniquement sur l’application de correctifs pour maintenir à jour les ressources de calcul de production. L’application de correctifs à elle seule peut encore entraîner une dérive des ressources de calcul par rapport à la norme renforcée au fil du temps. Il est également possible que l’application de correctifs ne parvienne pas à supprimer les programmes malveillants qui ont pu être installés par un acteur malveillant lors d’un événement de sécurité.
**Avantages du respect de cette bonne pratique :** le renforcement des images permet de réduire le nombre de chemins disponibles dans votre environnement d’exécution susceptibles de permettre un accès involontaire à des utilisateurs ou à des services non autorisés. Cela peut également réduire l’ampleur de l’impact en cas d’accès involontaire.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Pour renforcer vos systèmes, utilisez les dernières versions des systèmes d’exploitation, des images de conteneurs et des bibliothèques d’applications. Appliquez des correctifs aux problèmes connus. Minimisez le système en supprimant la totalité des applications, services, pilotes d’appareils, utilisateurs par défaut et autres informations d’identification inutiles. Prenez toutes les autres mesures nécessaires, telles que la désactivation des ports pour créer un environnement disposant uniquement des ressources et des fonctionnalités requises pour vos charges de travail. À partir de cette situation de référence, vous pouvez ensuite installer les logiciels, les agents ou les autres processus dont vous avez besoin à des fins telles que la surveillance de la charge de travail ou la gestion des vulnérabilités.
Vous pouvez réduire le fardeau que représente le renforcement des systèmes en utilisant les conseils fournis par des sources fiables, tels que les [guides de mise en œuvre technique de [sécurité du Center for Internet Security](https://www.cisecurity.org/) (CISDISA) et de la Defense Information Systems Agency (STIGs) ()](https://public.cyber.mil/stigs/). Nous vous recommandons de commencer par une [Amazon Machine Image](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) (AMI) publiée par un partenaire AWS ou par un APN partenaire, et d'utiliser AWS [EC2Image Builder](https://aws.amazon.com/image-builder/) pour automatiser la configuration en fonction d'une combinaison appropriée de STIG contrôles CIS et de commandes.
Bien qu'il existe des images renforcées et des recettes EC2 Image Builder qui appliquent les CIS DISA STIG recommandations du mode opératoire, il se peut que leur configuration empêche le bon fonctionnement de votre logiciel. Dans ce cas, vous pouvez partir d'une image de base non renforcée, installer votre logiciel, puis appliquer progressivement CIS des contrôles pour tester leur impact. Pour tout CIS contrôle qui empêche l'exécution de votre logiciel, testez si vous pouvez plutôt mettre en œuvre les recommandations de renforcement plus précises. DISA Gardez une trace des différents CIS contrôles et DISA STIG configurations que vous êtes en mesure d'appliquer avec succès. Utilisez-les pour définir vos recettes de durcissement d'image dans EC2 Image Builder en conséquence.
[Pour les charges de travail conteneurisées, les images renforcées de Docker sont disponibles dans le référentiel public [Amazon Elastic Container Registry () ECR](https://aws.amazon.com/ecr/).](https://gallery.ecr.aws/docker) Vous pouvez utiliser EC2 Image Builder pour renforcer les images des conteneurs en parallèleAMIs.
Comme pour les systèmes d'exploitation et les images de conteneurs, vous pouvez obtenir des packages de code (ou *des bibliothèques*) à partir de référentiels publics, via des outils tels que pip, npm, Maven et. NuGet Nous vous recommandons de gérer les packages de code en intégrant des référentiels privés, comme dans [AWS CodeArtifact](https://aws.amazon.com/codeartifact/), à des référentiels publics fiables. Cette intégration peut gérer la récupération, le stockage et la conservation des packages up-to-date pour vous. Les processus de création de votre application peuvent ensuite obtenir et tester la dernière version de ces packages en même temps que votre application, à l'aide de techniques telles que l'analyse de la composition logicielle (SCA), les tests statiques de sécurité des applications (SAST) et les tests dynamiques de sécurité des applications (DAST).
[Pour les charges de travail sans serveur qui l'utilisent AWS Lambda, simplifiez la gestion des dépendances des packages à l'aide des couches Lambda.](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html) Utilisez des couches Lambda afin de configurer un ensemble de dépendances standard qui sont partagées entre différentes fonctions dans une archive autonome. Vous pouvez créer et gérer des couches par le biais de leur propre processus de création, ce qui permet à vos fonctions de rester centralisées up-to-date.
## Étapes d’implémentation
+ Renforcez les systèmes d’exploitation. Utilisez des images de base provenant de sources fiables comme base pour développer votre système renforcéAMIs. Utilisez [EC2Image Builder](https://aws.amazon.com/image-builder/) pour personnaliser le logiciel installé sur vos images.
+ Renforcez les ressources conteneurisées. Configurez les ressources conteneurisées de manière à respecter les bonnes pratiques en matière de sécurité. Lorsque vous utilisez des conteneurs, implémentez la [numérisation d'ECRimages](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html) dans votre pipeline de génération et régulièrement par rapport à votre référentiel d'images pour rechercher CVEs dans vos conteneurs.
+ Lorsque vous utilisez une implémentation sans serveur avec AWS Lambda, utilisez des couches [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html) pour séparer le code des fonctions de l'application et les bibliothèques dépendantes partagées. La [signature de code](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html) pour Lambda permet de s’assurer que seul du code approuvé s’exécute dans vos fonctions Lambda.
## Ressources
**Bonnes pratiques associées :**
+ [OPS05-BP05 Effectuer la gestion des correctifs](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_dev_integ_patch_mgmt.html)
**Vidéos connexes :**
+ [Une plongée approfondie dans le domaine de AWS Lambda la sécurité](https://www.youtube.com/watch?v=FTwsMYXWGB0)
**Exemples connexes :**
+ [Créez rapidement une version STIG conforme à AMI l'aide d'EC2Image Builder](https://aws.amazon.com/blogs/security/quickly-build-stig-compliant-amazon-machine-images-using-amazon-ec2-image-builder/)
+ [Création de meilleures images de conteneurs](https://aws.amazon.com/blogs/containers/building-better-container-images/)
+ [Utilisation de couches Lambda pour simplifier votre processus de développement](https://aws.amazon.com/blogs/compute/using-lambda-layers-to-simplify-your-development-process/)
+ [Développez et déployez des AWS Lambda couches à l'aide d'un framework sans serveur](https://github.com/aws-samples/aws-serverless-lambda-layers)
+ [Création d'un pipeline end-to-end AWS DevSecOps CI/CD avec des outils et des logiciels open source SCA SAST DAST](https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/)
# SEC06-BP03 Réduire la gestion manuelle et l’accès interactif
Utilisez l’automatisation pour effectuer des tâches de déploiement, de configuration, de maintenance et d’investigation dans la mesure du possible. Envisagez l’accès manuel aux ressources de calcul en cas de procédures d’urgence ou dans des environnements sécurisés (environnement de test [sandbox]), lorsque l’automatisation n’est pas disponible.
**Résultat escompté :** les scripts programmatiques et les documents d’automatisation (runbooks) capturent les actions autorisées sur vos ressources informatiques. Ces runbooks sont lancés soit automatiquement, par le biais de systèmes de détection des changements, soit manuellement, lorsque le jugement humain est requis. L’accès direct aux ressources de calcul n’est disponible qu’en cas d’urgence, lorsque l’automatisation n’est pas disponible. Toutes les activités manuelles sont enregistrées et intégrées à un processus de révision afin d’améliorer continuellement vos capacités d’automatisation.
**Anti-modèles courants :**
+ Accès interactif aux instances Amazon EC2 avec des protocoles tels que SSH ou RDP.
+ Gestion des connexions utilisateur individuelles, telles que celles des utilisateurs locaux `/etc/passwd` ou Windows.
+ Partage d’un mot de passe ou d’une clé privée pour accéder à une instance entre plusieurs utilisateurs.
+ Installation manuelle des logiciels et création ou mise à jour des fichiers de configuration.
+ Mise à jour ou correction manuelle des logiciels.
+ Connexion à une instance pour résoudre les problèmes.
**Avantages du respect de cette bonne pratique :** la réalisation d’actions automatisées vous aide à réduire le risque opérationnel lié à des modifications involontaires et à des erreurs de configuration. La suppression de l’utilisation de Secure Shell (SSH) et du protocole RDP (Remote Desktop Protocol) pour l’accès interactif réduit l’étendue de l’accès à vos ressources de calcul. Cette opération supprime un chemin commun pour les actions non autorisées. La saisie de vos tâches de gestion des ressources de calcul dans des documents d’automatisation et des scripts programmatiques fournit un mécanisme permettant de définir et d’auditer l’ensemble des activités autorisées à un niveau de détail précis.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
La connexion à une instance est une approche classique de l’administration du système. Après avoir installé le système d’exploitation du serveur, les utilisateurs se connectent généralement manuellement pour configurer le système et installer les logiciels souhaités. Pendant la durée de vie du serveur, les utilisateurs peuvent se connecter pour effectuer des mises à jour logicielles, appliquer des correctifs, modifier des configurations et résoudre des problèmes.
L’accès manuel présente toutefois un certain nombre de risques. Il requiert la présence d’un serveur qui écoute les requêtes, par exemple un service SSH ou RDP, capable de fournir un chemin potentiel vers un accès non autorisé. Cela augmente également le risque d’erreur humaine associée à l’exécution d’étapes manuelles. Ces étapes peuvent entraîner des incidents liés à la charge de travail, une corruption ou une destruction de données, ou d’autres problèmes de sécurité. L’accès humain requiert également des protections contre le partage d’informations d’identification, ce qui entraîne des frais de gestion supplémentaires.
Pour atténuer ces risques, vous pouvez implémenter une solution d’accès à distance basée sur des agents, comme [AWS Systems Manager](https://aws.amazon.com/systems-manager/). AWS Systems Manager Agent (SSM Agent) lance un canal chiffré et ne dépend donc pas de l’écoute des demandes émanant de l’extérieur. Envisagez de configurer l’agent SSM pour [établir ce canal sur un point de terminaison d’un VPC](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html).
Systems Manager vous permet de contrôler avec précision la manière dont vous pouvez interagir avec vos instances gérées. Vous définissez les automatisations à exécuter, qui peut les exécuter et quand elles peuvent être exécutées. Systems Manager peut appliquer des correctifs, installer des logiciels et apporter des modifications de configuration sans accès interactif à l’instance. Systems Manager peut également fournir un accès à un shell distant et enregistrer chaque commande invoquée, ainsi que sa sortie, pendant la session dans les journaux et [Amazon S3](https://aws.amazon.com/s3/). [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) enregistre les invocations d’API Systems Manager à des fins d’inspection.
### Étapes d’implémentation
1. [Installez AWS Systems Manager Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) (SSM Agent) sur vos instances Amazon EC2. Vérifiez si SSM Agent est inclus et démarré automatiquement dans le cadre de votre configuration d’AMI de base.
1. Vérifiez que les rôles IAM associés à vos profils d’instance EC2 incluent la [politique IAM gérée](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html) `AmazonSSMManagedInstanceCore`.
1. Désactivez SSH, RDP et les autres services d’accès à distance exécutés sur vos instances. Pour cela, exécutez des scripts configurés dans la section des données utilisateur de vos modèles de lancement ou créez des AMI personnalisées à l’aide d’outils tels qu’EC2 Image Builder.
1. Vérifiez que les règles d’entrée des groupes de sécurité applicables à vos instances EC2 n’autorisent pas l’accès sur le port 22/tcp (SSH) ni le port 3389/tcp (RDP). Mettez en œuvre la détection et l’alerte en cas de groupes de sécurité mal configurés à l’aide de services tels que AWS Config.
1. Définissez les automatisations, les runbooks et les commandes d’exécution appropriés dans Systems Manager. Utilisez les politiques IAM pour définir qui peut effectuer ces actions et les conditions dans lesquelles elles sont autorisées. Testez minutieusement ces automatisations dans un environnement hors production. Invoquez ces automatisations si nécessaire, au lieu d’accéder à l’instance de manière interactive.
1. Utilisez [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) pour fournir un accès interactif aux instances lorsque cela est nécessaire. Activez la journalisation des activités de session pour conserver une piste d’audit dans [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) ou [Amazon S3](https://aws.amazon.com/s3/).
## Ressources
**Bonnes pratiques associées :**
+ [REL08-BP04 Effectuer le déploiement à l’aide d’une infrastructure immuable](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_tracking_change_management_immutable_infrastructure.html)
**Exemples connexes :**
+ [Remplacement de l’accès SSH pour réduire les frais de gestion et de sécurité avec AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/)
**Outils associés :**
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
**Vidéos connexes :**
+ [Controlling User Session Access to Instances in AWS Systems Manager Session Manager](https://www.youtube.com/watch?v=nzjTIjFLiow)
# SEC06-BP04 Valider l'intégrité du logiciel
Utilisez la vérification cryptographique pour valider l’intégrité des artefacts logiciels (y compris les images) utilisés par votre charge de travail. Signez vos logiciels de manière cryptographique afin de vous protéger contre les modifications non autorisées exécutées dans vos environnements de calcul.
**Résultat souhaité :** tous les artefacts proviennent de sources fiables. Les certificats des sites Web des fournisseurs sont validés. Les artefacts téléchargés sont vérifiés cryptographiquement par leur signature. Vos propres logiciels sont signés cryptographiquement et vérifiés par vos environnements informatiques.
**Anti-modèles courants :**
+ Faire confiance aux sites Web de fournisseurs réputés pour obtenir des artefacts logiciels, mais ignorer les avis d’expiration des certificats. Procéder aux téléchargements sans confirmer la validité des certificats.
+ Valider les certificats des sites Web des fournisseurs, mais sans vérifier cryptographiquement les artefacts téléchargés depuis ces sites Web.
+ S’appuyer uniquement sur des condensés ou des hachages pour valider l’intégrité des logiciels. Les hachages établissent que les artefacts n’ont pas été modifiés par rapport à leur version d’origine, mais ils ne valident pas leur source.
+ Ne pas signer vos propres logiciels, codes ou bibliothèques, même s’ils ne sont utilisés que dans le cadre de vos propres déploiements.
**Avantages du respect de cette bonne pratique :** la validation de l’intégrité des artefacts dont dépend votre charge de travail permet d’empêcher les logiciels malveillants de pénétrer dans vos environnements informatiques. La signature de vos logiciels contribue à vous protéger contre toute exécution non autorisée dans vos environnements de calcul. Sécurisez votre chaîne d’approvisionnement logicielle en signant et en vérifiant le code.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Les images du système d’exploitation, les images de conteneurs et les artefacts de code sont souvent distribués avec des contrôles d’intégrité disponibles, par exemple via un condensé ou un hachage. Cela permet aux clients de vérifier l’intégrité en calculant leur propre hachage de la charge utile et en s’assurant qu’il est identique à celui publié. Bien que ces vérifications permettent de vérifier que la charge utile n’a pas été falsifiée, elles ne permettent pas de valider que la charge utile provient de la source d’origine (sa *provenance*). La vérification de la provenance nécessite un certificat délivré par une autorité de confiance pour signer numériquement l’artefact.
Si vous utilisez un logiciel téléchargé ou des artefacts dans votre charge de travail, vérifiez si le fournisseur fournit une clé publique pour la vérification des signatures numériques. Voici quelques exemples de la façon dont AWS fournit une clé publique et des instructions de vérification pour les logiciels que nous publions :
+ [EC2Image Builder : vérifier la signature du téléchargement de l' AWS TOEinstallation](https://docs.aws.amazon.com/imagebuilder/latest/userguide/awstoe-verify-sig.html)
+ [AWS Systems Manager: Vérification de la signature de l'SSMagent](https://docs.aws.amazon.com/systems-manager/latest/userguide/verify-agent-signature.html)
+ [Amazon CloudWatch : vérification de la signature du package d' CloudWatch agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/verify-CloudWatch-Agent-Package-Signature.html)
Intégrez la vérification des signatures numériques dans les processus que vous utilisez pour obtenir et renforcer les images, comme indiqué dans [SEC06-BP02 Provisionner le calcul à partir d'](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_hardened_images.html)images renforcées.
Vous pouvez utiliser [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) pour gérer la vérification des signatures, ainsi que votre propre cycle de vie de signature de code pour vos propres logiciels et artefacts. [AWS Lambda](https://aws.amazon.com/lambda/) et [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) proposent des intégrations avec Signer pour vérifier les signatures de votre code et de vos images. À l’aide des exemples de la section Ressources, vous pouvez intégrer Signer à vos pipelines d’intégration et de diffusion continues (CI/CD) afin d’automatiser la vérification des signatures et la signature de vos propres codes et images.
## Ressources
**Documents connexes :**
+ [Signature cryptographique pour les conteneurs](https://aws.amazon.com/blogs/containers/cryptographic-signing-for-containers/)
+ [Meilleures pratiques pour sécuriser votre pipeline de création d'images de conteneur en utilisant AWS Signer](https://aws.amazon.com/blogs/security/best-practices-to-help-secure-your-container-image-build-pipeline-by-using-aws-signer/)
+ [Annonce de la signature d'images de conteneurs avec AWS Signer et Amazon EKS](https://aws.amazon.com/blogs/containers/announcing-container-image-signing-with-aws-signer-and-amazon-eks/)
+ [Configuration de la signature de code pour AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html)
+ [Bonnes pratiques et modèles avancés pour la signature de code Lambda](https://aws.amazon.com/blogs/security/best-practices-and-advanced-patterns-for-lambda-code-signing/)
+ [Signature de code à l'aide d' AWS Certificate Manager une autorité de certification privée et de AWS Key Management Service clés asymétriques](https://aws.amazon.com/blogs/security/code-signing-aws-certificate-manager-private-ca-aws-key-management-service-asymmetric-keys/)
**Exemples connexes :**
+ [Automatisez la signature du code Lambda avec Amazon et CodeCatalyst AWS Signer](https://aws.amazon.com/blogs/devops/automate-lambda-code-signing-with-amazon-codecatalyst-and-aws-signer/)
+ [Signature et validation des OCI artefacts avec AWS Signer](https://aws.amazon.com/blogs/containers/signing-and-validating-oci-artifacts-with-aws-signer/)
**Outils associés :**
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html)
+ [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/)
+ [AWS Key Management Service](https://aws.amazon.com/kms/)
+ [AWS CodeArtifact](https://aws.amazon.com/codeartifact/)
# SEC06-BP05 Automatiser la protection du calcul
Automatisez les opérations de protection informatique afin de réduire le besoin d’intervention humaine. Utilisez l’analyse automatique pour détecter les problèmes potentiels au sein de vos ressources informatiques et y remédier grâce à des réponses programmatiques automatisées ou à des opérations de gestion de flotte. Intégrez l’automatisation à vos processus CI/CD pour déployer des charges de travail fiables avec des dépendances à jour.
**Résultat escompté :** les systèmes automatisés effectuent toutes les analyses et tous les correctifs des ressources informatiques. Vous utilisez la vérification automatique pour vérifier que les images logicielles et les dépendances proviennent de sources fiables et qu’elles n’ont pas été falsifiées. Les charges de travail sont automatiquement vérifiées pour détecter les dépendances à jour et sont signées pour garantir la fiabilité des environnements informatiques AWS. Des mesures correctives automatisées sont lancées lorsque des ressources non conformes sont détectées.
**Anti-modèles courants :**
+ Suivre la pratique d’une infrastructure immuable, mais ne pas avoir de solution en place pour l’application de correctifs d’urgence ou le remplacement des systèmes de production.
+ Utiliser l’automatisation pour corriger les ressources mal configurées, mais ne pas mettre en place de mécanisme de remplacement manuel. Dans certains cas, vous devrez ajuster les exigences et suspendre les automatisations jusqu’à ce que vous apportiez ces modifications.
**Avantages du respect de cette bonne pratique :** l’automatisation peut réduire le risque d’accès et d’utilisation non autorisés de vos ressources informatiques. Elle contribue à éviter que les erreurs de configuration soient transférées dans les environnements de production, et à détecter et corriger ces erreurs le cas échéant. L’automatisation facilite également la détection des accès et utilisations non autorisés des ressources de calcul afin de réduire le temps de réponse. Vous pouvez ainsi réduire la portée globale de l’impact du problème.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Vous pouvez appliquer les automatisations décrites dans les pratiques du pilier de sécurité pour protéger vos ressources de calcul. [SEC06-BP01 Gérer les failles](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_vulnerability_management.html) décrit comment vous pouvez utiliser [Amazon Inspector](https://aws.amazon.com/inspector/) dans vos pipelines CI/CD et pour analyser en permanence vos environnements d’exécution à la recherche de vulnérabilités et d’expositions courantes (CVE) connues. Vous pouvez utiliser [AWS Systems Manager](https://aws.amazon.com/systems-manager/) pour appliquer des correctifs ou effectuer des redéploiements à partir d’images récentes via des runbooks automatisés afin de maintenir votre flotte informatique à jour avec les derniers logiciels et bibliothèques. Utilisez ces techniques pour limiter la nécessité de mettre en place des processus manuels et des accès interactifs à vos ressources de calcul. Pour en savoir plus, consultez [SEC06-BP03 Réduire la gestion manuelle et l’accès interactif](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_reduce_manual_management.html).
L’automatisation joue également un rôle dans le déploiement de charges de travail fiables, comme décrit dans [SEC06-BP02 Provisionner le calcul à partir d’images renforcées](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_hardened_images.html) et [SEC06-BP04 Valider l’intégrité du logiciel](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_validate_software_integrity.html). Vous pouvez utiliser des services tels qu’[EC2 Image Builder](https://aws.amazon.com/image-builder/), [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html), [AWS CodeArtifact](https://aws.amazon.com/codeartifact/) et [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) pour télécharger, vérifier, construire et stocker des images et des dépendances de code renforcées et approuvées. Outre Inspector, chacun d’entre eux peut jouer un rôle dans votre processus CI/CD, de sorte que votre charge de travail n’est mise en production qu’après confirmation que ses dépendances sont à jour et proviennent de sources fiables. Votre charge de travail est également signée afin que les environnements informatiques AWS tels que [AWS Lambda](https://aws.amazon.com/lambda/) et [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) puissent vérifier qu’elle n’a pas été falsifiée avant de l’autoriser à s’exécuter.
Au-delà de ces contrôles préventifs, vous pouvez également utiliser l’automatisation dans vos contrôles de détection pour vos ressources de calcul. À titre d’exemple, [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) offre la norme [NIST 800-53 Rev. 5](https://docs.aws.amazon.com/securityhub/latest/userguide/nist-standard.html) qui inclut des contrôles tels que [[EC2.8] Les instances EC2 doivent utiliser Instance Metadata Service Version 2 (IMDSv2)](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-8). IMDSv2 utilise les techniques d’authentification de session, de blocage des requêtes contenant un en-tête HTTP X-Forwarded-For et un TTL réseau 1 pour arrêter le trafic provenant de sources externes afin de récupérer des informations sur l’instance EC2. Cette vérification dans Security Hub CSPM permet de détecter quand les instances EC2 utilisent IMDSv1 et de lancer une correction automatique. Apprenez-en plus sur la détection et les corrections automatisées dans [SEC04-BP04 Initier la correction des ressources non conformes](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_detect_investigate_events_noncompliant_resources.html).
### Étapes d’implémentation
1. Automatisez la création d’AMI sécurisées, conformes et renforcées avec [EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/integ-compliance-products.html). Vous pouvez produire des images qui intègrent des contrôles issus des références du Center for Internet Security (CIS) ou des normes du Security Technical Implementation Guide (STIG) à partir des images de base d’AWS et des partenaires APN.
1. Automatisez la gestion de la configuration. Appliquez et validez des configurations sécurisées dans vos ressources de calcul automatiquement à l’aide d’un service ou d’un outil de gestion de la configuration.
1. Gestion de configuration automatisée à l’aide de [AWS Config](https://aws.amazon.com/config/)
1. Gestion automatisée de la posture de sécurité et de conformité à l’aide de [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)
1. Automatisez l’application des correctifs ou le remplacement des instances Amazon Elastic Compute Cloud (Amazon EC2). AWS Le gestionnaire de correctifs Systems Manager automatise le processus d’application des correctifs aux instances gérées avec des types de mises à jour liés à la sécurité et d’autres types. Vous pouvez utiliser le Gestionnaire de correctifs pour appliquer des correctifs pour les systèmes d’exploitation et les applications.
1. [Gestionnaire de correctifs d’AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
1. Automatisez l’analyse des ressources de calcul pour détecter les vulnérabilités et risques communs (CVE), et intégrez des solutions d’analyse de sécurité à votre pipeline de création.
1. [Amazon Inspector](https://aws.amazon.com/inspector/)
1. [Analyse d’image ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html)
1. Pensez à Amazon GuardDuty pour la détection automatique des malwares et des menaces afin de protéger les ressources informatiques. GuardDuty peut également identifier les problèmes potentiels lorsqu’une fonction [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) est invoquée dans votre environnement AWS.
1. [Amazon GuardDuty](https://aws.amazon.com/guardduty/)
1. Envisagez les solutions des Partenaires AWS. AWS Les Partenaires proposent des produits leaders du secteur qui sont équivalents, identiques ou s’intègrent aux contrôles existants dans vos environnements sur site. Ces produits complètent les services AWS existants pour vous permettre de déployer une architecture de sécurité exhaustive et une expérience plus homogène dans vos environnements cloud et sur site.
1. [Sécurité de l’infrastructure](https://aws.amazon.com/security/partner-solutions/#infrastructure_security)
## Ressources
**Bonnes pratiques associées :**
+ [SEC01-BP06 Automatiser le déploiement des contrôles de sécurité standard](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls.html)
**Documents connexes :**
+ [Profiter de tous les avantages d’IMDSv2 et désactiver IMDSv1 sur l’ensemble de votre infrastructure AWS](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure/)
**Vidéos connexes :**
+ [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI)