La puissance du réseau minimum viable

Comprendre les réseaux cloud constitue l'un des plus grands ajustements pour les organisations qui débutent leur parcours vers le cloud. Lorsque l'on examine le plan d'adressage et les composants, cela ressemble à un réseau IP. Et de la plupart des points de vue, c'en est un — mais dans bien d'autres domaines, ce n'en est pas un. Un réseau défini par logiciel (SDN) – comme ceux proposés dans le cloud – n'est pas soumis aux mêmes contraintes qu'un réseau physique, ce qui peut s'avérer plutôt déroutant au démarrage.

Plutôt que de chercher à comprendre en quoi le SDN diffère de votre réseau physique, concentrons-nous davantage sur ce que vous attendez du réseau et, plus important encore, sur ce qui ne doit pas être autorisé. Vous êtes peut-être assez âgé pour vous souvenir d'un concept appelé « refus par défaut » : à moins d'autoriser explicitement une connexion, celle-ci était bloquée par défaut. Puis le web est arrivé, et il n'était plus possible de restreindre le port 80 ou 443, puisque pratiquement toutes les applications utilisaient ces ports. De plus, le « refus par défaut » n'a jamais réellement dépassé le périmètre : nos réseaux internes avaient tendance à être plats et ouverts, s'appuyant sur une DMZ pour filtrer le trafic malveillant provenant de l'extérieur. Comme l'ont montré les violations successives, ce modèle n'est que modérément efficace.

Mais le SDN nous permet de nous rapprocher bien davantage du refus par défaut, grâce à un concept que nous appelons le « réseau minimum viable », qui permet de construire des réseaux sur mesure comprenant uniquement les éléments nécessaires à la réalisation de la tâche, et rien de plus.

Un réseau minimum viable doit déterminer l'architecture applicative, puis créer UNIQUEMENT les éléments réseau nécessaires à la prise en charge de cette application, en appliquant un routage et des groupes de sécurité fondés sur le moindre privilège, tout en exploitant des composants PaaS tels que les équilibreurs de charge cloud. Cela transforme de fait le réseau à commutation de paquets en réseau à commutation de circuits, en ce sens que les composants applicatifs ne peuvent communiquer QU'avec les autres composants autorisés, et que rien ne peut intercepter le trafic intermédiaire (à l'exception, dans certains cas, du fournisseur cloud). Le réseau rejette tout autre trafic. Cela élimine le besoin de constructions telles que la DMZ traditionnelle ou les zones réseau, puisque le réseau entier repose lui-même sur le moindre privilège et le refus par défaut.

Rendons cela un peu plus concret à l'aide d'un exemple. Vous pouvez créer une pile applicative traditionnelle à 3 niveaux avec un Application Load Balancer exposé publiquement, adossé à un serveur web placé dans un sous-réseau privé qui n'accepte QUE le trafic provenant de l'équilibreur de charge. Les serveurs web ne peuvent se connecter qu'à des serveurs d'applications qui acceptent leurs connexions. De même, les serveurs d'applications ne peuvent envoyer du trafic qu'aux bases de données qui autorisent de telles connexions. Chaque niveau fonctionne en refus par défaut et n'autorise que les connexions entrantes depuis les équilibreurs de charge et les connexions sortantes vers les bases de données. Dans de nombreux cas, vous pouvez mettre cela en œuvre sans aucune connectivité Internet (dans des sous-réseaux privés), hormis les équilibreurs de charge publics, qui sont des constructions PaaS hautement sécurisées maintenues par le fournisseur cloud.

Plutôt que de construire le réseau puis d'y placer les applications, vous concevez les applications puis adaptez le réseau à leurs besoins. Cela réduit considérablement la surface d'attaque de la pile applicative et diminue d'autant votre risque.

Nous avons appliqué ces principes lors de la création du site securosis.com, comme le montre le schéma d'architecture ci-dessous. Si l'on examine cette conception sous l'angle de la sécurité réseau, on constate que :

• L'accès est restreint depuis le WAF cloud, de sorte que seul le trafic propre parvient au VPC.
• Les équilibreurs de charge applicatifs (ALB) sont les seules ressources situées dans les sous-réseaux publics et n'autorisent que le trafic 80/443.
• Toutes les instances se trouvent dans des sous-réseaux privés et n'acceptent que le trafic provenant des ALB.
• L'instance « admin » accepte les connexions, mais uniquement depuis un VPN hébergé dans un environnement différent.
• Ne figurent pas sur le schéma les sous-réseaux de la base de données RDS, eux aussi exclusivement privés, qui n'acceptent que le trafic provenant des instances. Si des connexions directes ou un accès RDBMS sont nécessaires pour le traitement des données, les règles des groupes de sécurité sont modifiées pour accorder un accès temporaire.
• Les connexions à S3 s'effectuent via un point de terminaison de service, ce qui élimine le besoin d'une passerelle NAT pour l'accès Internet.
• SSH est désactivé sur les instances non-admin. Celles-ci sont automatiquement mises à l'échelle et immuables ; elles ne sont modifiées qu'en changeant l'image de base.
• Il n'existe aucun groupe de sécurité autoréférencé (groupes de sécurité autorisant l'accès interne), afin d'empêcher les attaques horizontales. Dans AWS, les groupes de sécurité s'appliquent au niveau de la ressource et non du sous-réseau, ce qui est très efficace pour bloquer les attaques est-ouest.
• Cette architecture réduit considérablement la surface d'attaque globale. Le réseau n'autorise que la connectivité minimale requise et ne contient que les sous-réseaux et les tables de routage minimaux nécessaires pour permettre l'accès. Nous avons essentiellement adapté le réseau à l'application. De fait, le réseau n'a été conçu qu'après l'architecture de la pile applicative.
• Il s'agit d'un exemple très simple portant sur un petit site, mais ces principes s'appliquent à des architectures bien plus vastes comportant davantage de niveaux, des équilibreurs de charge internes, des passerelles API et des composants PaaS.

Comme vous pouvez le constater, les constructions réseau du cloud offrent une flexibilité considérable. Vous avez enfin la possibilité de construire le réseau dont l'application a besoin, au lieu d'adapter l'application au réseau dont vous disposez. Mais cette flexibilité s'accompagne du risque de configurations erronées susceptibles d'exposer de larges pans de votre infrastructure à l'Internet public. Nous recommandons donc toujours de surveiller votre posture de sécurité cloud et d'appliquer les bonnes pratiques à l'aide d'une plateforme d'opérations de sécurité cloud (comme celle proposée par DisruptOps).