Simplifier le routage réseau et la sécurité avec les Listes de Préfixes VPC

En 2020, nous annoncions la fonctionnalité Liste de Préfixes pour Amazon Virtual Private Cloud (VPC). Celle-ci rend plus facile la création de postures de sécurité et elle simplifie la gestion du routage. Une Liste de Préfixes est un ensemble de plages d’adresses IP (IPv4 ou IPv6); communément nommé CIDR (« Classless Inter-Domain Routing », pour le routage inter-domaine sans classe); qui peuvent être utilisées pour configurer des groupes de sécurité VPC, des tables de routage VPC et des tables de routage AWS Transit Gateway et peuvent être partagées avec d’autres comptes AWS avec le service AWS Resource Access Manager (RAM). Au fur et à mesure que vous faites évoluer votre réseau, vous pouvez utiliser les Listes de Préfixes pour simplifier les audits et l’administration de vos groupes de sécurité et tables de routage.

Dans cet article, nous discutons des différentes façons d’utiliser les Listes de Préfixes pour simplifier la gestion de votre environnement, à l’aide de l’exemple illustré dans le diagramme de la Figure 1. Il est à noter qu’AWS dispose aussi également des Listes de Préfixes gérées pour Amazon S3 et Amazon DynamoDB qui sont principalement destinées à être utilisées avec les points de terminaison Amazon VPC Gateway, mais nous ne couvrons pas cette rubrique dans cet article.

Figure 1: Exemple de Diagramme d’un réseau d’entreprise avec 2 succursales, un compte AWS de Production sur 2 régions, un compte AWS de Management, ainsi qu’un réseau de partenaire le tout interconnecté avec le service AWS Transit Gateway.

Rendre les Audits et l’administration plus facile

Consolidation des règles pour les groupes de sécurité

Vous pouvez consolider plusieurs règles de groupe de sécurité avec la même politique d’accès en une seule règle à l’aide de la fonctionnalité de Liste de Préfixes. Cela simplifiera votre audit, en n’auditant qu’une seule règle au lieu de plusieurs règles. Dans ce premier exemple, nous allons nous concentrer uniquement sur le Compte de Production figurant dans le diagramme de réseau (Figure 2). Dans ce scénario, nous avons un site web intranet hébergé dans le VPC A accédé depuis les VPC D, E et F. Nous avons un groupe de sécurité existant avec 6 règles permettant ce flux de trafic. Nous optimiserons ce groupe de sécurité qui autorise la connectivité HTTP et HTTPS aux trois VPC D, E et F, comme le montre la figure 2 ci-dessous :

Figure 2: La section Compte de Production de l’exemple précédent avec le flux réseau des VPCs de la région us-east-1 vers les serveurs web du VPC A se trouvant dans la région us-east-2

Figure 3: Capture d’écran du groupe de sécurité “serveurs web intranet” avec 6 règles permettant du traffic HTTP et HTTPS depuis les 3 VPCs de la région us-east-1 avant l’optimisation avec les Listes de Préfixes.

On peut consolider ces règles en créant une Liste de Préfixes IPv4 dans la région us‑east‑2, que nous appellerons « réseaux vpc us‑east-1 » et définirons une valeur maximale de nombre d’entrées à 6 pour prendre en compte de futures entrées, comme indiqué dans la figure 4 ci-dessous.

Figure 4: Capture d’écran de la Liste de Préfixes “ réseaux vpc us east-1 ” créée dans la région us-east-2 avec des entrées des 3 VPCs de la région us-east-1.

Notes importantes :

• Les Listes de Préfixes sont des ressources régionales, donc il faut les créer dans la région où on compte les utiliser, qui dans notre cas est us‑east‑2,
• Une Liste de Préfixes peut contenir soit des entrées IPv4, soit des entrées IPv6, mais pas les deux dans la même Liste de Préfixes,
• Planifiez la taille de chaque Liste de Préfixes à l’avance. En créant une Liste de Préfixes, vous devez spécifier le nombre maximal d’entrées que la Liste de Préfixes peut avoir. il ne sera pas possible de modifier le nombre maximal d’entrées ultérieurement,
• Faites en sorte que le contenu de vos Listes de Préfixes soit intuitif pour qu’il soit réutilisable. Par exemple, une liste de serveurs Web, de sous-réseaux publics, ou; comme dans notre cas; de réseaux VPC dans la région us‑east-1.

On va utiliser notre nouvelle Liste de Préfixes pour optimiser notre groupe de sécurité en consolidant les 6 règles qu’on avait précédemment à 2 règles (Figure 5).

Figure 5: Capture d’écran du groupe de sécurité “serveurs web intranet” optimisé, avec maintenant 2 règles permettant du traffic HTTP et du HTTPS depuis les 3 VPCs via la Liste de Préfixe

Maintenant, on a nos règles de groupes de sécurité qui sont consolidées et qui sont plus faciles à lire et à gérer. Si un nouveau VPC est provisionné dans la région us‑east‑1 et qu’on vous demande de l’autoriser parmi dans les connexions entrantes vers vos serveurs Web intranet, il suffit d’ajouter une entrée à la Liste de Préfixes « réseaux vpc us‑east-1 » et les règles de groupe de sécurité des serveurs Web intranet seront automatiquement mises à jour (ainsi que les groupes de sécurité qui le référencent).

On vient de voir un exemple basique d’utilisation de la fonctionnalité de Liste de Préfixes, mais on peut facilement l’étendre pour s’adapter à des cas d’utilisation plus complexes. Imaginez un scénario dans lequel vous disposez d’un groupe de sécurité avec 52 règles autorisant la connectivité HTTP et HTTPS à partir de 6 sous-réseaux VPC et de 20 adresses IP individuelles. L’une des façons pour y voir plus clair consiste à créer une Liste de Préfixes pour les sous-réseaux et une autre pour les adresses IP individuelles. Si la réutilisation de chaque Liste de Préfixes indépendamment de l’autre n’a pas de sens, il vaut mieux les grouper en une seule Liste de Préfixes. Quoi qu’il en soit, en consolidant les 52 règles existantes à 4 ou 2 règles, ceci facilitera l’audit et l’administration de ce groupe de sécurité.

Tables de routage AWS Transit Gateway simplifiés pour l’appairage entre régions

AWS Transit Gateway supporte l’appairage entre régions via un routage statique. Cela signifie qu’il faut ajouter des routes dans la table de routage de la Transit Gateway pour les CIDR des VPCs de la région distante avec comme destination la connexion d’appairage. Ce processus est simplifié en créant une Liste de Préfixes pour les CIDR de la région distante et en référençant la Liste de Préfixes dans la table de routage. Toute modification (ajout ou suppression de CIDR) apportée à une Liste de Préfixes est automatiquement propagée vers la table de routage Transit Gateway. Les Listes de Préfixes sont des ressources régionales. Par conséquent, la Liste de Préfixes d’une région distante doit être créée et référencée dans la région dans laquelle elle a été créée.

Dans l’exemple suivant, nous avons créé une Liste de Préfixes dans la région us-east-2 nommée « pl‑us‑east‑1‑vpcs », qui contient le CIDR des VPC dans la région us-east-1. Cette Liste de Préfixes sera référencée dans la table de routage TGW A avec comme destination la connexion d’appairage. De même, une Liste de Préfixes est créée dans la région us‑east‑1 sera utilisée dans la table de routage TGW B.

Figure 6: Diagramme avec les Listes de Préfixes dans leurs régions respectives et utilisés dans l’appairage des Transit Gateway

Avec cette méthode, on améliore l’efficacité opérationnelle en procédant à des changements de manière centralisée en toute confiance, tout en sachant que le changement sera pris en compte par toutes les ressources l’utilisant. En effet, ceci simplifie encore davantage l’administration des CIDR en disposant d’un seul emplacement pour les mettre à jour et les administrer.

Simplification des tables de routage VPC Périphérique

Dans un environnement multi-VPC, il n’est pas rare de voir les clients choisir une centralisation du traffic d’entrée/sortie vers Internet via un VPC Périphérique où tous les VPC voulant accéder à Internet passent leur traffic par ce VPC commun, qui se trouve en périphérie des connexions avec Internet. Dans ce type d’architecture avec VPC Périphérique, la route par défaut dans la table de routage du VPC Périphérique pointe vers la passerelle Internet (IGW) pour tout ce qui est trafic vers Internet (0.0.0.0/0), en plus des routes plus spécifiques vers d’autres VPC qui pointent vers la Transit Gateway en destination. Avec ce modèle utilisant le service AWS Transit Gateway, il est recommandé que les VPC qui se trouvent en coupure pour les autres VPC disposent d’une route par défaut pointant vers la Transit Gateway. Cependant, pour le VPC Périphérique; qui dans notre cas agit en coupure avec Internet; la route par défaut pointe vers la passerelle Internet (VPC Internet Gateway). Les routes vers les autres VPC ou autres réseaux doivent être configurées explicitement. Les Listes de Préfixes simplifient justement la table de routage du VPC Périphérique, qui souvent est volumineuse et sujette à une mauvaise configuration lors des mises à jour. L’image suivante (Figure 7) est une représentation du VPC Périphérique avec AWS Transit Gateway ainsi que les VPCs en étoile :

Figure 7: Diagramme montrant le VPC Périphérique avec les autres VPCs sans Liste de Préfixes.

La table de routage du VPC Périphérique est ainsi simplifiée en créant une liste de préfixes, par exemple pl‑edge‑vpc, peut contenir les CIDR de VPC et d’autres réseaux, selon votre architecture réseau. La table de routage du VPC utilise la Liste des Préfixes comme destination avec la Transit Gateway comme prochain point de passage. Cela simplifie grandement la table de routage du VPC et facilite l’administration des CIDR réseau du VPC Périphérique (qui est la cible du traffic) en consolidant les CIDR de destination dans la Liste des Préfixes. Si nécessaire, la même Liste de Préfixes peut être réutilisée pour configurer des règles dans le groupe de sécurité. Le diagramme suivant (Figure 8) montre la table de routage du VPC Périphérique avec la Liste de Préfixes. Cette Liste de Préfixes contient des CIDR VPC pour les VPC D, E et F.

Figure 8: Diagramme montrant l’utilisation de la Liste de Préfixes dans la table de routage du VPC Périphérique.

Si vous voulez mettre à jour la table de routage d’un VPC avec un autre CIDR d’un autre VPC ou tout autre réseau, vous pouvez mettre à jour la Liste des Préfixes, la modification sera automatiquement appliquée au trafic du VPC Périphérique.

Cohérence des postures de sécurité

Homogénéité

Toutes les instances ayant la même posture de sécurité réseau, et qui remplissent le même rôle, doivent avoir des politiques d’accès identiques, réduisant ainsi l’impact des erreurs humaines. Les Listes de Préfixes peuvent aider à atteindre et à maintenir ce niveau d’homogénéité. Lorsque vous utilisez une Liste de Préfixes avec plusieurs CIDR dans une règle de groupe de sécurité, chaque CIDR de la Liste de Préfixes dispose du même niveau d’accès aux instances qui utilisent le groupe de sécurité. Lorsque vous utilisez une Liste de Préfixes dans une table de routage d’une Transit Gateway, chaque destination de la Liste de Préfixes passera par le même point de passage suivant. L’intégration de Listes de Préfixes dans votre politique de sécurité réseau peut réduire le risque d’erreurs, ou de modification qui peuvent générer des incidents. L’exemple type pour illustrer ce cas de figure est qu’il n’est pas nécessaire de mettre à jour plusieurs règles dans plusieurs groupes de sécurité. Il suffit de mettre à jour la liste des préfixes, les groupes de sécurité l’utilisant seront mis à jour en conséquence.

Prévention des erreurs

Si un ID de Liste de Préfixes qui n’existe pas dans un compte est entré dans une règle de groupe de sécurité, une erreur apparaîtra, empêchant d’avoir une configuration incorrecte, comme le montre l’image dans la Figure 9. Cette fonctionnalité peut sembler anodine, mais elle peut vous aider à ne pas passer des heures à résoudre les problèmes de connectivité. Si on prend l’exemple où quelqu’un a saisi 25 au lieu d’un 24 dans la longueur du préfixe du CIDR dans une règle de groupe de sécurité. Si le même utilisateur a entré un « 5 » au lieu d’un « 4 » dans l’ID de Liste de Préfixes, la modification ne sera pas autorisée à être enregistrée, à moins d’avoir un autre ID existant dans le même compte ayant le « 5 » à la place du « 4 » ce qui est très peu probable. Bien sûr, le CIDR doit toujours être saisi correctement dans la liste des préfixes, mais vous n’aurez à le faire qu’une seule fois, à un seul endroit, au lieu de plusieurs fois de manière cohérente. Même en ayant recours à des mécanismes d’automatisation, tels que des outils de gestion de la configuration ou des scripts, pour garantir une certaine cohérence de votre politique de sécurité réseau, l’utilisation de Listes de Préfixes sera toujours bénéfique. Vous réduirez ainsi les risques et améliorez encore l’efficacité opérationnelle, de part la nature des Listes de Préfixes qui assurent toujours cette cohérence. Ils réduisent le nombre de modifications apportées aux règles de votre groupe de sécurité et à vos routes statiques, et font de tel sorte qu’il y ait moins de risque d’échec de modification, en facilitant la lecture, l’audit et la gestion de votre politique de sécurité réseau.

Figure 9: Capture d’écran illustrant ce qui se passe quand on essaye d’ajouter un ID de Préfixe incorrecte au groupe de sécurité “serveurs web Intranet”, ce qui déclenche une erreur et empêche la sauvegarde de la modification

Posture de sécurité centralisée à travers les comptes

Si vous souhaitez centraliser certains aspects de l’administration de la sécurité de votre réseau, dans l’objectif de maintenir une séparation des tâches, il est possible de le faire en partageant vos Listes de Préfixes avec d’autres comptes. Ceci peut être réalisé avec des comptes AWS, d’organisations AWS et/ou d’unités organisationnelles (UO). Et ceci est possible via le service AWS Resource Access Manager (RAM).

Dans cet exemple, nous allons introduire le concept de compte de gestion (qui, comme son nom l’indique permet de regrouper la gestion du reste des compte d’une manière centralisée). Dans notre exemple, le compte de gestion comporte 3 serveurs bastion provisionnées dans la région us-east-2, qui est représenté dans l’image suivante (Figure 10).

Figure 10: Les comptes de Production et de Gestion. Le traffic sort des serveurs de bastion depuis le compte de Gestion vers les instances protégées par le groupe de sécurité “gestion à distance” dans les VPCs A, B et C dans le compte de Production.

Si vous souhaitez centraliser la gestion de l’accès réseau de la connectivité du bastion sur les différents comptes, cela est possible grâce à la création d’une nouvelle Liste de Préfixes « serveurs bastion » dans le compte de gestion de us-east-2 avec les adresses IP des 3 bastions, puis la partager avec le compte Production via le service Resource Access Manager (RAM). Cela est illustré dans la Figure 11 ci-dessous :

Figure 11: Capture d’écran du partage de la ressource dans le service RAM, en partageant la Liste de Préfixes des “serveurs bastion” depuis le compte de Gestion avec le compte de Production.

Une fois l’invitation de partage de ressources envoyée et approuvée, vous pouvez créer les groupes de sécurité dans us‑east‑2 dans le compte Production avec des règles qui référencent cette Liste de Préfixes créée précédemment appelé « serveurs bastion ». Dans notre cas, nous avons créé un groupe de sécurité nommé « gestion distante » dans le VPC A qui autorise la connectivité SSH, RDP et ICMP à partir de la liste des préfixes des « hôtes bastion ».

Figure 12: Capture d’écran du Groupe de Sécurité “gestion distante” permettant une connectivité depuis les serveurs bastion définis dans le compte de Gestion.

Avec ce mécanisme, les administrateurs des serveurs bastion peuvent désormais mettre à jour la connectivité vers les ressources du compte de production sans avoir à accéder au compte de Production pour modifier les règles de groupe de sécurité correspondantes. Par exemple, si la connectivité de l’un des hôtes bastion vers le compte de Production doit être supprimée, il suffit de supprimer l’entrée d’adresse IP dans la Liste des Préfixes. Cela met à jour automatiquement les trois règles précédemment définis dans le groupe de sécurité « gestion distante » pour ne plus autoriser la connectivité SSH, RDP ou ICMP à l’adresse IP de cet hôte bastion. Avant de procéder à la modification, il est possible d’examiner où cette Liste de Préfixes est référencée dans un premier temps dans l’onglet Associations représenté dans l’image ci-dessous, ce qui va nous permettre de bien comprendre la portée de notre modification.

Figure 13: Capture d’écran de l’onglet Associations dans la Liste de Préfixe “serveurs bastion”, listant la référence du groupe de sécurité “gestion distante” dans le compte de Production.

Si nous n’avions pas utilisé de Liste de Préfixes, le groupe de sécurité « gestion à distance » aurait nécessité 9 règles pour permettre la même connectivité, et la modification souhaitée aurait nécessité de supprimer 3 règles. L’utilisation de Liste de Préfixes nous a permis de planifier cette modification dans l’onglet Associations, qui répertorie toutes les ressources dans lesquelles notre Liste de Préfixes est référencée, et la modification a été effectuée à un seul endroit d’une manière centralisée.

Voici un autre exemple qui pourrait être étendu pour s’adapter à des cas d’utilisation plus complexes. Imaginez si ces adresses IP des 3 bastions ont été référencées dans des centaines de groupes de sécurité sur plusieurs comptes AWS. Avec les Listes de Préfixes, la modification souhaitée peut être exécutée d’une manière centralisée avec une seule modification.

Simplifiez l’évolution de votre réseau

Votre environnement sera inévitablement amené à croître avec le temps, que ça soit votre environnement AWS ou en dehors d’AWS, avec l’évolution des besoins métier ou d’intégration. Lorsque vous y serez confronté, vous préférerez faire évoluer votre environnement d’une manière simple et efficace en termes de besoins de sécurité ou de routage. Typiquement, vous allez peut-être commencer par un environnement AWS isolé, puis avoir besoin de vous connecter à vos environnements d’entreprise ou non AWS d’une manière générale. La sécurité ou le routage que vous avez déjà mis en place doit être capable d’évoluer de manière transparente avec l’ajout de nouveaux réseaux. L’utilisation des Listes de Préfixes vous aident à atteindre cet objectif.

Réseau hybride

Jusqu’à maintenant, nous avons discuté de l’utilisation des Listes de Préfixes en référençant des ressources réseau AWS seulement. Si on souhaite référencer des réseaux externes, tels que votre siège social, votre succursale, ou votre centre de données, vous pouvez le faire avec les Listes de Préfixes, de la même manière qu’on peut le faire avec les ressources réseaux AWS et les adresses IP.

Si on revient à notre premier exemple où nous avons autorisé la connectivité entre les trois réseaux VPC situés dans us-east-1 vers les serveurs Web intranet du VPC A. Si vous souhaitez autoriser la même connectivité de vos réseaux d’entreprise aux mêmes serveurs Web intranet, l’une des façons de le faire consiste à les ajouter dans la Liste de Préfixes existante « réseaux vpc us‑east-1 », comme illustré dans l’image suivante.

Figure 14: Suite de l’exemple du diagramme de la Figure 2, en ajoutant les réseaux du Siège Social et des succursales, en montrant de la trafic vers les serveurs Web intranet dans le VPC A dans la région us-east-2

Si le réseau du siège social et deux réseaux de succursales nécessitent une connectivité similaire, il est donc logique de passer par l’utilisation de Liste de Préfixes. D’une manière générale, les exigences du siège social sont différentes de celles des deux succursales. Nous allons donc créer deux nouvelles Listes de Préfixes : « siege social » et « succursales », puis nous les référencerons dans les groupes de sécurité de la même manière qu’on a référencé la liste des préfixes des VPC D, E, F. Après, toute modification aux réseaux du siège social ou des succursales est régi par une seule mise à jour de la lListe de Préfixes correspondante.

Figure 15: Capture d’écran du groupe de sécurité ‘“serveurs web intranet” mis à jour, avec maintenant 6 règles permettant du traffic HTTP et HTTPS depuis les VPCs de la région us-east-1, ainsi que les siège social et les succursales via les Listes de Préfixes.

Si on continue dans notre exemple précédent, après avoir ajouté le réseau de l’entreprise, examinons l’ajout un réseau de partenaire. Les entreprises travaillent souvent avec des fournisseurs ou des partenaires tiers pour des projets conjoints ou des besoins métiers, et vous devrez peut-être leur donner accès à des parties de vos environnements AWS. Le niveau d’accès est généralement différent pour les réseaux partenaires des réseaux appartenant à l’entreprise. Par exemple, l’accès de votre partenaire peut être étendu à des ports spécifiques ou à des adresses IP pour certaines applications ou environnements, tandis votre réseau d’entreprise peut avoir accès au ping ouvert à toutes vos ressources.

Figure 16: Diagramme en ajoutant un partenaire à la précédente architecture réseau.

Afin de maintenir une certaine ségrégation des accès, une Liste de Préfixes distincte est créée pour les CIDR du réseau partenaire, par exemple « Mon_Reseau_Partenaire_LP » et l’accès est accordé en modifiant cette Liste de Préfixes. Cela facilite le déploiement des modifications dans les groupes de sécurité. La capture d’écran suivante (Figure 17) présente une Liste de Préfixes avec les CIDR du partenaire.

Figure 17: Capture d’écran de la Liste de Préfixes dédiée aux partenaires.

Conclusion

Dans cet article, nous avons décrit comment les Listes de Préfixes simplifient la lecture et la gestion de vos règles de groupe de sécurité, ainsi qu’une simplification des tables de routage, en donnant des exemples dans lesquels les Listes de Préfixes vous aident à simplifier la configuration de votre réseau ainsi que la simplification de votre politique de sécurité. Les Listes de Préfixes sont un excellent outil pour simplifier votre réseau et réduire temps d’administration ainsi que sa complexité opérationnelle.

Article original contribué par Vinod Kataria, Senior Partner Solution Architect, Troy Lindsay, Senior Partner Solutions Architect et Shovan Das, Senior Product Manager. Adapté par Zakaria Lamliki, Solutions Architect dans les équipes AWS France.