# SEC09-BP04 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 souhaité :** une charge de travail avec des flux de trafic bien définis entre les services au niveau du plan de données et du plan de contrôle. 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 à l'instauration 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 de risque exposé 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 le trafic entre les services qui constituent une charge de travail.
+ Le *trafic nord-sud* représente le 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 des services AWS utilisent le protocole de [signature des demandes d'API AWS 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'origine de 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 comme [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 SigV4, vous pouvez utiliser [Gestion des identités et des accès AWS (IAM) Roles Anywhere ](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) sur la ressource non 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 comme [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) et [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/mutual-tls.html) pour fournir une authentification mTLS pour les communications entre les charges de travail ou à l'intérieur de celles-ci. 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 [mécanisme d'autorisation 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 API à l'aide de JWT émis par les fournisseurs d'identité OIDC et 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éfinir et documenter les flux de réseau de votre 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 d'un exercice de modélisation des menaces, comme décrit dans [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).
+ **Mettre en place des contrôles de réseau :** tenez compte de capacités d'AWS pour mettre en place 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 restreindre 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 avec les services d'assistance AWS et 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.
+ **Mettre en œuvre un système d'authentification et d'autorisation pour tous les services de votre charge de travail :** choisissez l'ensemble de services AWS le plus approprié pour authentifier et chiffrer les flux de trafic de votre charge de travail.
+ Envisagez d'utiliser [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html) pour sécuriser les communications de service à service. VPC Lattice peut utiliser l'[authentification SigV4 et des stratégies d'authentification](https://docs.aws.amazon.com/vpc-lattice/latest/ug/auth-policies.html) pour contrôler les 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 [App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/mutual-tls.html). [AWS CA privée](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) peut être utilisé pour établir une hiérarchie des autorités de certification privées capables d'émettre des certificats à utiliser avec mTLS.
+ Pour l'intégration à des services utilisant OAuth 2.0 ou OIDC, envisagez d'utiliser [API Gateway avec les mécanismes d'autorisation JWT](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html).
+ Pour les communications entre votre charge de travail et des appareils IoT, [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/client-authentication.html) propose plusieurs options de chiffrement et d'authentification du trafic réseau.
+ **Surveiller les accès non autorisés :** surveillez en permanence les canaux de communication involontaires, les personnes non autorisées qui tentent d'accéder à des ressources protégées et autres schémas d'accès inappropriés.
+ Si vous utilisez VPC Lattice pour gérer l'accès à vos services, envisagez d'activer et de 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 du réseau et passer régulièrement en revue les anomalies.
+ Consultez le [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 livre blanc Pilier de sécurité - AWS Well-Architected Framework pour plus de conseils sur la planification et la simulation des incidents de sécurité, ainsi que la réponse qui y est apportée.
## Ressources
**Bonnes pratiques associées :**
+ [SEC03-BP07 Analyser l'accès public et entre les comptes](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 :**
+ [ Evaluating access control methods to secure Amazon API Gateway APIs ](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)
+ [ How to secure API Gateway HTTP endpoints with JWT authorizer ](https://aws.amazon.com/blogs/security/how-to-secure-api-gateway-http-endpoints-with-jwt-authorizer/)
+ [ Authorizing direct calls to AWS services using AWS IoT Core credential provider ](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)
+ [AWS Security Incident Response Guide ](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 :**
+ [ Amazon VPC Lattice Workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/9e543f60-e409-43d4-b37f-78ff3e1a07f5/en-US)
+ [ Zero-Trust Episode 1 – The Phantom Service Perimeter workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/dc413216-deab-4371-9e4a-879a4f14233d/en-US)