SEC09-BP03 Authentifier les communications réseau - Pilier Sécurité
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 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 de la mise en place 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 établie : 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) 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 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 SigV4, vous pouvez utiliser AWS Identity and Access Management (IAM) Roles Anywhere 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 Private Certificate Authority (AWS Private CA). Vous pouvez utiliser des services comme Amazon API Gateway et AWS App Mesh 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), 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.

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

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

  • 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. 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 du réseau et passer régulièrement en revue les anomalies.

    • Consultez le guide de réponse aux incidents de sécurité AWS et la section Réponse aux incidents 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 :

Documents connexes :

Vidéos connexes :

Exemples connexes :