SEC09-BP03 Authentifier les communications réseau - Framework AWS Well-Architected
Directives d’implémentationRessources

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) 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 et Amazon API Gateway 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 AWS Identity and Access Management Rôles Anywhere (IAM) 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 Private Certificate Authority (AWS Private CA). Vous pouvez utiliser des services tels qu’Amazon API Gateway et AWS App Mesh pour fournir une authentification mTLS pour les communications inter ou intra charges de travail. 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) 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.

  • É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é pour établir, définir et limiter les flux de données entre les ressources.

    • Envisagez d’utiliser AWS PrivateLink 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.

  • 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. 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 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 et à la section Réponse aux incidents 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 :

Documents connexes :

Vidéos connexes :

Exemples connexes :