# Protection des données en transit
Les *données en transit* sont toutes les données envoyées d’un système à un autre. Cela inclut la communication entre les ressources dans votre charge de travail, ainsi que la communication entre d’autres services et vos utilisateurs finaux. En fournissant le niveau de protection approprié pour vos données en transit, vous protégez la confidentialité et l’intégrité des données de votre charge de travail.
**Données sécurisées entre des sites VPC ou sur site :** vous pouvez les utiliser [AWS PrivateLink](https://aws.amazon.com/privatelink/) pour créer une connexion réseau sécurisée et privée entre Amazon Virtual Private Cloud (Amazon VPC) ou une connectivité sur site avec des services hébergés dans AWS. Vous pouvez accéder aux services AWS, aux services tiers et aux services d’autres Comptes AWS comme s’ils se trouvaient sur votre réseau privé. Avec AWS PrivateLink, vous pouvez accéder aux services sur plusieurs comptes avec des blocs CIDR d’adresses IP qui se chevauchent sans avoir besoin d’une passerelle Internet ou d’un NAT. Vous n’avez pas non plus besoin de configurer des règles de pare-feu, des définitions de chemin ou des tables de routage. Le trafic reste sur le backbone d’Amazon et ne traverse pas Internet. Vos données sont donc protégées. Vous pouvez rester conforme aux réglementations de conformité sectorielles, telles que les lois HIPAA et EU/US Privacy Shield. AWS PrivateLink fonctionne de manière transparente avec des solutions tierces pour créer un réseau mondial simplifié, vous permettant d’accélérer la migration vers le cloud et de profiter des services AWS disponibles.
**Topics**
+ [SEC09-BP01 Implémenter la gestion sécurisée des clés et des certificats](sec_protect_data_transit_key_cert_mgmt.md)
+ [SEC09-BP02 Application du chiffrement en transit](sec_protect_data_transit_encrypt.md)
+ [SEC09-BP03 Authentifier les communications réseau](sec_protect_data_transit_authentication.md)
# SEC09-BP01 Implémenter la gestion sécurisée des clés et des certificats
Les certificats du protocole TLS (Transport Layer Security) permettent de sécuriser les communications réseau et établir l’identité des sites Web, des ressources et des charges de travail sur Internet, ainsi que sur les réseaux privés.
**Résultat escompté :** un système de gestion des certificats sécurisé qui peut provisionner, déployer, stocker et renouveler des certificats dans une infrastructure à clé publique (PKI). Un mécanisme sécurisé de gestion des clés et des certificats empêche la divulgation de la clé privée du certificat et renouvelle automatiquement et périodiquement le certificat. Il s’intègre également à d’autres services pour fournir des communications réseau et une identité sécurisées pour les ressources de la machine au sein de votre charge de travail. Les clés ne doivent jamais être accessibles aux identités humaines.
**Anti-modèles courants :**
+ Exécuter des étapes manuelles au cours des processus de déploiement ou de renouvellement des certificats.
+ Ne pas accorder suffisamment d’attention à la hiérarchie de l’autorité de certification (AC) lors de la conception d’une AC privée.
+ Utiliser des certificats auto-signés pour les ressources publiques.
**Avantages liés au respect de cette bonne pratique :**
+ Simplifiez la gestion des certificats en automatisant leur déploiement et leur renouvellement
+ Encouragez le chiffrage des données en transit à l’aide de certificats TLS
+ Amélioration de la sécurité et de l’auditabilité des actions de certification entreprises par l’autorité de certification
+ Organisation des tâches de gestion à différents niveaux de la hiérarchie de l’AC
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Les charges de travail modernes font un usage intensif des communications réseau chiffrées à l’aide de protocoles PKI tels que le protocole TLS. La gestion des certificats PKI peut être complexe, mais le provisionnement, le déploiement et le renouvellement automatisés des certificats peuvent réduire les inconvénients liés à la gestion des certificats.
AWS fournit deux services pour gérer les certificats PKI à usage général : [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) et [AWS Autorité de certification privée (AWS CA privée)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html). ACM est le principal service que les clients utilisent pour provisionner, gérer et déployer des certificats destinés à être utilisés dans des charges de travail AWS publiques et privées. ACM émet des certificats privés en utilisant AWS CA privée et [s’intègre](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) à de nombreux autres services gérés par AWS pour fournir des certificats TLS sécurisés pour les charges de travail. ACM peut également délivrer des certificats reconnus publiquement à partir d’[Amazon Trust Services](https://www.amazontrust.com/repository/). Les certificats publics d’ACM peuvent être utilisés sur des charges de travail destinées au public, car les navigateurs et les systèmes d’exploitation modernes approuvent par défaut ces certificats.
AWS CA privée vous permet d’établir votre propre autorité de certification racine ou subordonnée et d’émettre des certificats TLS par l’intermédiaire d’une API. Vous pouvez utiliser ce type de certificats dans des scénarios où vous contrôlez et gérez la chaîne de confiance du côté client de la connexion TLS. En plus des cas d’utilisation TLS, AWS CA privée peut émettre des certificats à des pods Kubernetes, des attestations produits pour appareils Matter, une signature de code et d’autres cas d’utilisation avec un [modèle personnalisé](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html). Vous pouvez également utiliser [Rôles Anywhere IAM](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) pour fournir des informations d’identification IAM temporaires aux charges de travail sur site qui ont reçu des certificats X.509 signés par votre autorité de certification privée.
Outre ACM et AWS CA privée, [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/what-is-aws-iot.html) fournit un support spécialisé pour le provisionnement, la gestion et le déploiement de certificats PKI sur les appareils IoT. AWS IoT Core fournit des mécanismes spécialisés pour [intégrer des appareils IoT](https://docs.aws.amazon.com/whitepapers/latest/device-manufacturing-provisioning/device-manufacturing-provisioning.html) dans votre infrastructure à clé publique à grande échelle.
Certains services AWS, tels qu’[Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) et [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html), proposent leurs propres fonctionnalités d’utilisation de certificats pour sécuriser les connexions des applications. Par exemple, API Gateway et Application Load Balancer (ALB) prennent en charge le protocole TLS mutuel (mTLS) à l’aide de certificats client que vous créez et exportez à l’aide de la AWS Management Console, de CLI ou des API.
**Considérations relatives à l’établissement d’une hiérarchie d’autorité de certification privée **
Lorsque vous devez établir une autorité de certification privée, il est important de prendre soin de concevoir correctement la hiérarchie de l’autorité de certification dès le départ. La bonne pratique consiste à déployer chaque niveau de votre hiérarchie d’autorité de certification dans des Comptes AWS distincts lorsque vous créez une hiérarchie d’autorité de certification privée. Cette étape intentionnelle réduit la surface de chaque niveau de la hiérarchie de l’autorité de certification, ce qui facilite la découverte d’anomalies dans les données de journalisation CloudTrail et réduit l’étendue de l’accès ou l’impact en cas d’accès non autorisé à l’un des comptes. L’autorité de certification racine doit résider dans son propre compte et ne doit être utilisée que pour émettre un ou plusieurs certificats d’autorité de certification intermédiaire.
Créez ensuite une ou plusieurs autorités de certification intermédiaires dans des comptes distincts du compte de l’autorité de certification racine afin d’émettre des certificats pour les utilisateurs finaux, les appareils ou d’autres charges de travail. Enfin, émettez des certificats à partir de votre autorité de certification racine vers les autorités de certification intermédiaires, qui émettront à leur tour des certificats vers vos utilisateurs finaux ou vos appareils. Pour plus d’informations sur la planification du déploiement des AC et la conception de la hiérarchie des AC, y compris la planification de la résilience, la réplication interrégionale, le partage des AC au sein de votre organisation et plus encore, voir [Planifier votre déploiement AWS CA privée](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html).
### Étapes d’implémentation
1. Déterminez les services AWS pertinents requis pour votre cas d’utilisation :
+ De nombreux cas d’utilisation peuvent s’appuyer sur l’infrastructure de clés publiques existante d’AWS à l’aide d’[AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html). ACM peut déployer des certificats TLS pour les serveurs Web, les équilibreurs de charge ou d’autres utilisations pour des certificats publiquement approuvés.
+ Envisagez [AWS CA privée](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) si vous devez établir votre propre hiérarchie d’autorité de certification privée ou si vous avez besoin d’accéder à des certificats exportables. ACM peut ensuite être utilisé pour émettre de [nombreux types de certificats d’entité finale](https://docs.aws.amazon.com/privateca/latest/userguide/PcaIssueCert.html) à l’aide du AWS CA privée.
+ Pour les cas d’utilisation où les certificats doivent être provisionnés à grande échelle pour les appareils de l’Internet des objets (IoT) embarqués, envisagez [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html).
+ Envisagez d’utiliser les fonctionnalités mTLS natives dans des services tels qu’[Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) ou [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html).
1. Mettez en œuvre le renouvellement automatisé des certificats dans la mesure du possible :
+ Utilisez le [renouvellement géré par ACM](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) pour les certificats émis par ACM, ainsi que les services intégrés gérés par AWS.
1. Établissez des journaux et des pistes d’audit :
+ Activez les [journaux CloudTrail](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html) pour suivre l’accès aux comptes détenant des autorités de certification. Envisagez de configurer la validation de l’intégrité des fichiers journaux dans CloudTrail pour vérifier l’authenticité des données du journal.
+ Vous pouvez générer des [rapports d’audit](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html) qui répertorient les certificats émis et révoqués par votre autorité de certification privée. Ces rapports peuvent être exportés vers un compartiment S3.
+ Lors du déploiement d’une autorité de certification privée, vous devrez également créer un compartiment S3 pour stocker la liste de révocation des certificats (CRL). Pour obtenir des conseils sur la configuration de ce compartiment S3 en fonction des exigences de votre charge de travail, voir [Planification d’une liste de révocation de certificats (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html).
## Ressources
**Bonnes pratiques associées:**
+ [SEC02-BP02 Utiliser des informations d’identification temporaires](sec_identities_unique.md)
+ [SEC08-BP01 Mise en œuvre de la gestion sécurisée des clés](sec_protect_data_rest_key_mgmt.md)
+ [SEC09-BP03 Authentifier les communications réseau](sec_protect_data_transit_authentication.md)
**Documents connexes:**
+ [Comment héberger et gérer une infrastructure complète de certificats privés dans AWS](https://aws.amazon.com/blogs/security/how-to-host-and-manage-an-entire-private-certificate-infrastructure-in-aws/)
+ [Comment garantir une hiérarchie d’autorités de certification privées ACM à l’échelle de l’entreprise pour l’automobile et la fabrication](https://aws.amazon.com/blogs/security/how-to-secure-an-enterprise-scale-acm-private-ca-hierarchy-for-automotive-and-manufacturing/)
+ [Bonnes pratiques en matière d’AC privée](https://docs.aws.amazon.com/privateca/latest/userguide/ca-best-practices.html)
+ [Comment utiliser AWS RAM pour partager votre compte croisé Private CA](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/)
**Vidéos connexes:**
+ [Activer Private CA AWS Certificate Manager (atelier)](https://www.youtube.com/watch?v=XrrdyplT3PE)
**Exemples connexes:**
+ [Atelier sur les autorités de certification privées](https://catalog.workshops.aws/certificatemanager/en-US/introduction)
+ [Atelier sur la gestion des appareils IoT](https://iot-device-management.workshop.aws/en/) (y compris le provisionnement des appareils)
**Outils associés:**
+ [Plugin pour Kubernetes cert-manager pour utiliser AWS CA privée](https://github.com/cert-manager/aws-privateca-issuer)
# SEC09-BP02 Application du chiffrement en transit
Appliquez vos exigences de chiffrement définies en fonction des politiques, des obligations réglementaires et des normes de votre entreprise afin de répondre aux exigences organisationnelles, juridiques et de conformité. Utilisez uniquement les protocoles avec chiffrement lors de la transmission de données sensibles en dehors de votre cloud privé virtuel (VPC). Le chiffrement permet de préserver la confidentialité des données, même lorsque celles-ci transitent par des réseaux non fiables.
**Résultat escompté :** vous chiffrez le trafic réseau entre vos ressources et Internet afin de limiter l’accès non autorisé aux données. Vous chiffrez le trafic réseau au sein de votre environnement AWS interne en fonction de vos exigences de sécurité. Vous chiffrez les données en transit à l’aide des protocoles TLS sécurisés et de suites de chiffrement.
**Anti-modèles courants :**
+ Utiliser des versions obsolètes de composants SSL, TLS et de suite de chiffrement (par exemple, SSL v3.0, clés RSA 1024 bits et chiffrement RC4).
+ Autoriser le trafic non chiffré (HTTP) vers ou depuis des ressources publiques.
+ Ne pas surveiller et ne pas remplacer les certificats X.509 avant leur expiration.
+ Utiliser des certificats X.509 auto-signés pour TLS.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Les services AWS fournissent des points de terminaison HTTPS utilisant TLS pour la communication, ce qui assure le chiffrement en transit lors de la communication avec les API AWS. Les protocoles HTTP non sécurisés peuvent être audités et bloqués dans un cloud privé virtuel (VPC) dans le cadre de l’utilisation de groupes de sécurité. Les requêtes HTTP peuvent être également [redirigées automatiquement vers HTTPS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html) dans Amazon CloudFront ou sur un [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#redirect-actions). Vous pouvez utiliser une [politique de compartiment Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/blogs/storage/enforcing-encryption-in-transit-with-tls1-2-or-higher-with-amazon-s3/) pour restreindre la possibilité de charger des objets via HTTP, en imposant l’utilisation du protocole HTTPS pour les chargements d’objets vers votre ou vos compartiments. Vous disposez d’un contrôle total sur vos ressources de calcul pour mettre en œuvre le chiffrement en transit dans l’ensemble de vos services. De plus, vous pouvez utiliser la connectivité VPN dans votre VPC à partir d’un réseau externe ou d’[AWS Direct Connect](https://aws.amazon.com/directconnect/) pour faciliter le chiffrement du trafic. Vérifiez que vos clients appellent les API AWS en utilisant au moins le protocole TLS 1.2, car [AWS a rendu en février 2024 obsolète l’utilisation des versions de TLS antérieures](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/). Nous vous recommandons d’utiliser TLS 1.3. Si vous avez des exigences particulières en matière de chiffrement en transit, vous pouvez trouver des solutions tierces dans AWS Marketplace.
### Étapes d’implémentation
+ **Appliquer le chiffrement en transit :** vos exigences en matière de chiffrement doivent être définies selon les dernières normes et bonnes pratiques en matière de sécurité, et doivent autoriser uniquement des protocoles sécurisés. Par exemple, configurez un groupe de sécurité afin d’autoriser uniquement le protocole HTTPS pour un Application Load Balancer ou une instance Amazon EC2.
+ **Configurez des protocoles sécurisés dans les services de périphérie :** [configurez le protocole HTTPS avec Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html) et utilisez un [profil de sécurité adapté à votre posture de sécurité et à votre cas d’utilisation](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html#secure-connections-supported-ciphers).
+ **Utiliser un [VPN pour la connectivité externe](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html) :** envisagez d’utiliser un VPN IPsec pour sécuriser les connexions point à point ou réseau à réseau afin d’assurer à la fois la confidentialité et l’intégrité des données.
+ **Configurer des protocoles sécurisés dans les équilibreurs de charge :** sélectionnez une politique de sécurité fournissant les suites de chiffrement les plus puissantes prises en charge par les clients qui se connecteront à l’écouteur. [Créez un écouteur HTTPS pour votre Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html).
+ **Configurer des protocoles sécurisés dans Amazon Redshift :** configurez votre cluster pour exiger une [connexion SSL (Secure Socket Layer) ou TLS (Transport Layer Security)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html).
+ **Configurer des protocoles sécurisés :** consultez la documentation de service AWS pour déterminer les capacités de chiffrement en transit.
+ **Configurez un accès sécurisé lors du téléchargement vers des compartiments Amazon S3 :** utilisez les contrôles de stratégie de compartiment Amazon S3 pour [garantir un accès sécurisé](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) aux données.
+ **Envisagez d’utiliser [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/) :** ACM vous permet de provisionner, de gérer et de déployer des certificats TLS publics à utiliser avec des services AWS.
+ **Envisagez d’utiliser [AWS Autorité de certification privée](https://aws.amazon.com/private-ca/) pour les besoins du PKI privé :** AWS CA privée vous permet de créer des hiérarchies d’autorités de certification (AC) privées pour délivrer des certificats X.509 d’entité finale qui peuvent être utilisés pour créer des canaux TLS cryptés.
## Ressources
**Documents connexes :**
+ [ Utilisation du protocole HTTPS avec CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html)
+ [ Connexion de votre VPC à des réseaux distants utilisant AWS Virtual Private Network](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html)
+ [ Création d’un écouteur HTTPS pour votre Application Load Balancer ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)
+ [ Didacticiel : Configurer SSL/TLS sur Amazon Linux 2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html)
+ [ Utilisation de SSL/TLS pour chiffrer une connexion à une instance de base de données ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html)
+ [ Configuration des options de sécurité des connexions ](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html)
# SEC09-BP03 Authentifier les communications réseau
Vérifiez l’identité des communications à l’aide de protocoles comme TLS (Transport Layer Security) ou IPsec qui prennent en charge l’authentification.
Concevez votre charge de travail de manière à utiliser des protocoles réseau sécurisés et authentifiés lors de la communication entre les services, les applications ou avec les utilisateurs. L’utilisation de protocoles réseau qui prennent en charge l’authentification et l’autorisation permet de mieux contrôler les flux du réseau et de réduire l’impact des accès non autorisés.
**Résultat escompté :** une charge de travail avec un plan de données et un plan de contrôle bien définis circulent entre les services. Les flux de trafic utilisent des protocoles réseau authentifiés et chiffrés lorsque cela est techniquement possible.
**Anti-modèles courants :**
+ Flux de trafic non chiffrés ou non authentifiés au sein de votre charge de travail.
+ Réutilisation des informations d’authentification par plusieurs utilisateurs ou entités.
+ S’appuyer uniquement sur les contrôles réseau pour contrôler les accès.
+ Créer un mécanisme d’authentification personnalisé au lieu d’utiliser des mécanismes d’authentification standard.
+ Flux de trafic trop permissifs entre les composants des services ou d’autres ressources dans le VPC.
**Avantages liés au respect de cette bonne pratique :**
+ Limite l’impact des accès non autorisés à une partie de la charge de travail.
+ Offre la garantie que les actions ne sont effectuées que par des entités authentifiées.
+ Améliore le découplage des services en définissant clairement et en appliquant les interfaces de transfert de données prévues.
+ Améliore la surveillance, la journalisation et la réponse aux incidents grâce à l’attribution des demandes et à des interfaces de communication bien définies.
+ Assure une défense approfondie de vos charges de travail en combinant des contrôles réseau avec des contrôles d’authentification et d’autorisation.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** faible
## Directives d’implémentation
Les modèles de trafic réseau de votre charge de travail peuvent être classés en deux catégories :
+ Le *trafic est-ouest* représente les flux de trafic entre les services qui constituent une charge de travail.
+ Le *trafic nord-sud* représente les flux de trafic entre votre charge de travail et les consommateurs.
Le chiffrement du trafic nord-sud est courant, mais la sécurisation du trafic est-ouest à l’aide de protocoles authentifiés l’est moins. Les pratiques modernes de sécurité recommandent que la conception du réseau ne permette pas à elle seule d’établir une relation de confiance entre deux entités. Lorsque deux services peuvent résider dans les limites d’un réseau commun, il est toujours recommandé de chiffrer, d’authentifier et d’autoriser les communications entre ces services.
Par exemple, les API de service AWS utilisent le protocole de signature [AWS Signature Version 4 (SigV4)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) pour authentifier l’appelant, quel que soit le réseau d’où provient la demande. Cette authentification garantit que les API AWS peuvent vérifier l’identité de la personne qui a demandé l’action, et cette identité peut ensuite être combinée avec des stratégies pour décider si l’action doit être autorisée ou non.
Des services tels qu’[Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/access-management-overview.html) et [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html) vous permettent d’utiliser le même protocole de signature SigV4 pour ajouter une authentification et une autorisation au trafic est-ouest dans vos propres charges de travail. Si des ressources extérieures à votre environnement AWS ont besoin de communiquer avec des services qui nécessitent une authentification et une autorisation basées sur le protocole SIGv4, vous pouvez utiliser [Gestion des identités et des accès AWS Rôles Anywhere (IAM)](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) sur la ressource hors AWS pour obtenir des informations d’identification AWS temporaires. Ces informations d’identification peuvent être utilisées pour signer les demandes de services utilisant SigV4 pour autoriser l’accès.
L’authentification mutuelle TLS (mTLS) est un autre mécanisme courant pour authentifier le trafic est-ouest. De nombreuses applications IoT (Internet des objets) et B2B, ainsi que des microservices utilisent mTLS pour valider l’identité des deux côtés d’une communication TLS à l’aide de certificats X.509 côté client et côté serveur. Ces certificats peuvent être émis par AWS Autorité de certification privée (AWS CA privée). Vous pouvez utiliser des services tels qu’[Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) pour fournir une authentification mTLS pour les communications inter-charges de travail ou intra-charge de travail. [Application Load Balancer prend également en charge mTLS](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html) pour les charges de travail orientées côté interne ou externe. mTLS fournit des informations d’authentification pour les deux côtés d’une communication TLS, mais elle ne fournit pas de mécanisme d’autorisation.
Enfin, OAuth 2.0 et OpenID Connect (OIDC) sont deux protocoles généralement utilisés pour contrôler l’accès aux services par les utilisateurs, mais ils sont également de plus en plus populaires pour le trafic de service à service. API Gateway fournit un [autorisateur JSON Web Token (JWT)](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html) permettant aux charges de travail de restreindre l’accès aux routes d’API à l’aide des JWT émis par des fournisseurs d’identité OIDC ou OAuth 2.0. Les champs d’application OAuth2 peuvent être utilisés comme source pour les décisions d’autorisation de base, mais les contrôles d’autorisation doivent encore être mis en œuvre dans la couche applicative, et les champs d’application OAuth2 ne peuvent pas à eux seuls répondre à des besoins d’autorisation plus complexes.
### Étapes d’implémentation
+ **Définissez et documentez les flux de votre réseau de charge de travail :** la première étape de la mise en œuvre d’une stratégie de défense en profondeur consiste à définir les flux de trafic de votre charge de travail.
+ Créez un diagramme de flux de données qui définit clairement la transmission des données entre les différents services qui constituent votre charge de travail. Ce schéma constitue la première étape de l’application de ces flux par le biais de réseaux authentifiés.
+ Instrumentez votre charge de travail lors des phases de développement et de test pour vérifier que le diagramme de flux de données reflète avec précision le comportement de la charge de travail lors de l’exécution.
+ Un diagramme de flux de données peut également être utile lors de l’exécution d’un exercice de modélisation des menaces, comme décrit dans [SEC01-BP07 Identifier les menaces et hiérarchiser les mesures d’atténuation à l’aide d’un modèle de menace](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html).
+ **Établissez des contrôles réseau :** tenez compte des capacités AWS permettant d’établir des contrôles réseau alignés sur vos flux de données. Les limites du réseau ne doivent pas représenter le seul contrôle de sécurité, mais elles constituent une couche de la stratégie de défense en profondeur visant à protéger votre charge de travail.
+ Utilisez des [groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/security-groups.html) pour établir, définir et limiter les flux de données entre les ressources.
+ Envisagez d’utiliser [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) pour communiquer à la fois avec AWS et les services tiers qui prennent en charge AWS PrivateLink. Les données envoyées via un point de terminaison d’interface AWS PrivateLink restent dans le réseau AWS et ne transitent pas par l’Internet public.
+ **Mettez en œuvre l’authentification et l’autorisation pour tous les services de votre charge de travail :** choisissez l’ensemble de services AWS le plus approprié pour fournir des flux de trafic authentifiés et cryptés dans votre charge de travail.
+ Pensez à [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html) pour sécuriser les communications entre services. VPC Lattice peut utiliser l’[authentification SigV4 combinée à des politiques d’authentification](https://docs.aws.amazon.com/vpc-lattice/latest/ug/auth-policies.html) pour contrôler l’accès de service à service.
+ Pour la communication de service à service à l’aide de mTLS, envisagez d’utiliser [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) ou [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html). [AWS CA privée](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) peut être utilisé pour établir une hiérarchie d’autorité de certification privée capable d’émettre des certificats à utiliser avec mTLS.
+ Lors de l’intégration à des services utilisant OAuth 2.0 ou OIDC, envisagez d’utiliser [API Gateway avec l’autorisateur JWT](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html).
+ Pour la communication entre votre charge de travail et les appareils IoT, envisagez [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/client-authentication.html), qui propose plusieurs options pour le chiffrement et l’authentification du trafic réseau.
+ **Surveillez les accès non autorisés :** surveillez en permanence les canaux de communication imprévus, les principaux non autorisés qui tentent d’accéder à des ressources protégées et les autres modèles d’accès inappropriés.
+ Si vous utilisez VPC Lattice pour gérer l’accès à vos services, pensez à activer et à surveiller les [journaux d’accès VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/monitoring-access-logs.html). Ces journaux contiennent des informations sur le demandeur et le réseau, notamment le VPC source et de destination, et les métadonnées des demandes.
+ Envisagez d’activer les [journaux de flux VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) pour capturer des métadonnées sur les flux réseau et vérifier régulièrement la présence d’anomalies.
+ Reportez-vous au [Guide de réponse aux incidents de sécurité AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html) et à la [section Réponse aux incidents](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html) du pilier Sécurité AWS Well-Architected Framework pour plus de conseils sur la planification, la simulation et la réponse aux incidents de sécurité.
## Ressources
**Bonnes pratiques associées :**
+ [ SEC03-BP07 Analyser l’accès public et intercompte](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [ SEC02-BP02 Utiliser des informations d’identification temporaires ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [ SEC01-BP07 Identifier les menaces et hiérarchiser les atténuations à l’aide d’un modèle de menaces ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)
**Documents connexes :**
+ [ Évaluation des méthodes de contrôle d’accès pour sécuriser les API Amazon API Gateway ](https://aws.amazon.com/blogs/compute/evaluating-access-control-methods-to-secure-amazon-api-gateway-apis/)
+ [ Configuration de l’authentification TLS mutuelle pour une API REST ](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html)
+ [ Comment sécuriser les points de terminaison HTTP API Gateway avec l’autorisateur JWT ](https://aws.amazon.com/blogs/security/how-to-secure-api-gateway-http-endpoints-with-jwt-authorizer/)
+ [ Autoriser les appels directs vers les services AWS à l’aide du fournisseur d’informations d’identification AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)
+ [Guide d’intervention en cas d’incident de sécurité AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
**Vidéos connexes :**
+ [AWS re:invent 2022: Introducing VPC Lattice ](https://www.youtube.com/watch?v=fRjD1JI0H5w)
+ [AWS re:invent 2020: Serverless API authentication for HTTP APIs on AWS](https://www.youtube.com/watch?v=AW4kvUkUKZ0)
**Exemples connexes :**
+ [ Atelier Amazon VPC Lattice ](https://catalog.us-east-1.prod.workshops.aws/workshops/9e543f60-e409-43d4-b37f-78ff3e1a07f5/en-US)
+ [ Épisode 1 de Zero-Trust — L’atelier Phantom Service Perimeter ](https://catalog.us-east-1.prod.workshops.aws/workshops/dc413216-deab-4371-9e4a-879a4f14233d/en-US)