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 intégrée de défense en profondeur de la sécurité qui complète la stratégie d’authentification et d’autorisation des identités 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 :

Avantages du respect de cette bonne pratique : la mise en place de couches réseau est la première étape pour limiter les chemins inutiles à travers le réseau, en particulier ceux 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 respectée : é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 une architecture d’application Web à trois niveaux, vous pouvez stocker vos fichiers de couche de présentation statique sur Amazon S3 et les diffuser à partir d’un réseau de diffusion de contenu (CDN), tel qu’Amazon CloudFront. La couche application peut comporter des points de terminaison publics qu’un Application Load Balancer (ALB) sert dans un sous-réseau public Amazon VPC (similaire à une zone démilitarisée, ou DMZ), les services principaux étant déployés dans des sous-réseaux privés. La couche de données, qui héberge des ressources telles que des bases de données et des systèmes de fichiers partagés, peut résider dans des sous-réseaux privés différents des ressources de votre couche d’application. À chacune de ces limites de couche (CDN, sous-réseau public, sous-réseau privé), vous pouvez déployer des contrôles qui permettent uniquement au trafic autorisé de franchir ces limites.

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 peuvent faciliter l’interopérabilité des composants de votre charge de travail entre les couches réseau. Lors de l’utilisation de AWS Lambda, effectuez le déploiement dans vos sous-réseaux VPC, sauf s’il y a raisons spécifiques de ne pas le faire. Déterminez où les points de terminaison d’un VPC et AWS PrivateLink peuvent simplifier le respect des politiques de sécurité qui limitent l’accès aux passerelles Internet.

Étapes d’implémentation

Ressources

Bonnes pratiques associées :

Vidéos connexes :

Exemples connexes :