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 de sécurité intégrée, axée sur la défense en profondeur, qui complète la stratégie d’authentification et d’autorisation de l’identité 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 créez 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 de la mise en place de cette bonne pratique : la mise en place de couches réseau constitue la première étape pour limiter les voies inutiles à travers le réseau, en particulier celles 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 établie : é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 le cadre d’une architecture d’application Web à trois niveaux, vous pouvez stocker vos fichiers de la couche de présentation statique sur Amazon S3
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
Étapes d’implémentation
-
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.
-
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 les contrôles de sécurité en mutation à l’aide des services gérés, par exemple CloudFront, Amazon API Gateway
, Elastic Load Balancing et AWS Amplify , pour héberger des points de terminaison publics. -
Pour les composants exécutés dans des environnements de calcul, par exemple des instances Amazon EC2, des conteneurs AWS Fargate
ou des fonctions Lambda, effectuez le déploiement dans des sous-réseaux privés en fonction de vos groupes dès la première étape. -
Pour les services AWS entièrement gérés, comme Amazon DynamoDB
, Amazon Kinesis ou Amazon SQS , envisagez d’utiliser les points de terminaison VPC par défaut pour l’accès via des adresses IP privées.
Ressources
Bonnes pratiques associées :
Vidéos connexes :
Exemples connexes :
