Concevoir des solutions pour la segmentation du réseau

Effectué

Fonctionnalités de segmentation Azure

Lorsque vous travaillez dans Azure, vous disposez de nombreuses options de segmentation.

1. Abonnement: construction de haut niveau qui fournit une séparation des entités reposant sur une plateforme. Celle-ci est destinée à définir les limites entre les grandes organisations d’une entreprise. En outre, la communication entre les ressources de différents abonnements doit être explicitement provisionnée.
2. Réseau virtuel : créé au sein d’un abonnement dans des espaces d’adressage privés. Il fournit aux ressources une autonomie au niveau du réseau. Par défaut, aucun trafic n’est autorisé entre deux réseaux virtuels. Comme les abonnements, toute communication entre les réseaux virtuels doit être approvisionnée de manière explicite.
3. Groupes de sécurité réseau (NSG) : mécanismes de contrôle d’accès permettant de contrôler le trafic entre les ressources au sein d’un réseau virtuel, et également avec les réseaux externes, comme Internet, d’autres réseaux virtuels, etc. Les groupes de sécurité réseau permettent une stratégie de segmentation précise, grâce à la création de périmètres pour un sous-réseau, une machine virtuelle ou un groupe de machines virtuelles. Pour plus d’informations sur les opérations qu’il est possible d’effectuer avec les sous-réseaux dans Azure, consultez Sous-réseaux (réseaux virtuels Azure).
4. Groupes de sécurité d’application (ASG) : similaires aux groupes de sécurité réseau, mais référencés avec un contexte d’application. Cela vous permet de regrouper un ensemble de machines virtuelles sous une balise d’application et de définir des règles de trafic qui sont ensuite appliquées à chacune des machines virtuelles sous-jacentes.
5. Pare-feu Azure : pare-feu natif cloud avec état fourni en tant que service, qui peut être déployé dans un réseau virtuel ou dans des déploiements de hubs Azure Virtual WAN pour le filtrage du trafic entre les ressources cloud, Internet et locales. Vous créez des règles ou des stratégies (à l’aide du Pare-feu Azure ou d’Azure Firewall Manager) en spécifiant l’autorisation/refus du trafic à l’aide des contrôles de couche 3 à 7. Vous pouvez également filtrer le trafic vers Internet en utilisant à la fois le Pare-feu Azure et des tiers en dirigeant tout ou partie du trafic via des fournisseurs de sécurité tiers pour le filtrage avancé et la protection de l’utilisateur.

Modèles de segmentation

Voici quelques modèles courants permettant de segmenter une charge de travail dans Azure. Chaque modèle fournit un type d’isolation et de connectivité différent. Choisissez un modèle répondant aux besoins de votre organisation.

Modèle 1 : Réseau virtuel unique

Tous les composants de la charge de travail se trouvent dans un même réseau virtuel. Ce modèle convient si vous exercez dans une seule région, car un réseau virtuel ne peut pas s’étendre sur plusieurs régions.

Les méthodes courantes permettant de sécuriser des segments, comme des sous-réseaux ou des groupes d’applications, consistent à utiliser des groupes de sécurité réseau et des groupes de sécurité d’application. Vous pouvez également utiliser une appliance virtuelle réseau issue de la Place de marché Azure ou du Pare-feu Azure, afin d’appliquer et de sécuriser cette segmentation.

Dans cette image, Subnet1 comprend la charge de travail de la base de données. Subnet2 comprend les charges de travail web. Vous pouvez configurer des groupes de sécurité réseau qui autorisent Subnet1 à communiquer uniquement avec Subnet2, et Subnet2 à ne communiquer qu’avec Internet.

Prenons l’exemple d’un cas d’usage impliquant plusieurs charges de travail placées dans des sous-réseaux distincts. Vous pouvez placer des contrôles qui permettront à une charge de travail de communiquer avec le back-end d’une autre charge de travail.

Modèle 2 : Plusieurs réseaux virtuels qui communiquent par le biais d’un peering

Les ressources sont réparties ou répliquées sur plusieurs réseaux virtuels. Les réseaux virtuels peuvent communiquer par le biais d’un peering. Ce modèle convient si vous devez regrouper des applications dans des réseaux virtuels séparés, ou si vous avez besoin de plusieurs régions Azure. L’un des avantages de ce modèle est la segmentation intégrée, car vous devez appairer explicitement un réseau virtuel avec un autre. Le peering de réseaux virtuels n’est pas transitif. Vous pouvez effectuer une segmentation supplémentaire à l’intérieur d’un réseau virtuel en utilisant des groupes de sécurité réseau et des groupes de sécurité d’application, comme indiqué dans le modèle 1.

Modèle 3 : Plusieurs réseaux virtuels dans un modèle hub-and-spoke

Un réseau virtuel est désigné comme hub dans une région donnée pour tous les autres réseaux virtuels qui sont désignés comme des spokes dans cette même région. Le hub et ses spokes sont connectés par le biais d’un peering. Tout le trafic transite par le hub et peut servir de passerelle pour les hubs d’autres régions. Dans ce modèle, les contrôles de sécurité sont configurés au niveau des hubs afin de pouvoir segmenter et contrôler le trafic entre les autres réseaux virtuels de façon scalable. L’un des avantages de ce modèle est que, lorsque votre topologie de réseau s’étend, les frais liés à la posture de sécurité n’augmentent pas (sauf lorsque vous effectuez une extension vers de nouvelles régions).

L’option native recommandée est le Pare-feu Azure. Cette option fonctionne à la fois sur les réseaux virtuels et sur les abonnements et a pour but de régir les flux de trafic à l’aide des contrôles des couches 3 à 7. Vous pouvez définir vos règles de communication et les appliquer de manière cohérente. Voici quelques exemples :

• Le réseau virtuel 1 ne peut pas communiquer avec le réseau virtuel 2, mais il peut communiquer avec le réseau virtuel 3.
• Le réseau virtuel 1 ne peut pas accéder à l’Internet public, sauf à *.github.com.

Avec la préversion d’Azure Firewall Manager, vous pouvez gérer de façon centralisée des stratégies sur plusieurs Pare-feu Azure et permettre aux équipes DevOps de personnaliser davantage les stratégies locales.

Comparaison des modèles

Considérations	Modèle 1	Modèle 2	Modèle 3
Connectivité/Routage : comment chacun des segments communique avec les autres	Le routage système fournit une connectivité par défaut à n’importe quelle charge de travail d’un sous-réseau.	Identique au modèle 1.	Aucune connectivité par défaut entre les réseaux spokes. Pour permettre la connectivité, le hub doit comprendre un routeur de couche 3, comme le Pare-feu Azure.
Filtrage du trafic au niveau du réseau	Le trafic est autorisé par défaut. Utilisez des groupes de sécurité réseau et des groupes de sécurité d’application pour filtrer le trafic.	Identique au modèle 1.	Le trafic entre les réseaux virtuels Spoke est refusé par défaut. Ouvrez les chemins sélectionnés pour autoriser le trafic via la configuration du Pare-feu Azure.
Journalisation centralisée	Journaux des groupes de sécurité réseau et des groupes de sécurité d’application pour le réseau virtuel.	Agrégez les journaux des groupes de sécurité réseau et des groupes de sécurité d’application de tous les réseaux virtuels.	Le Pare-feu Azure journalise tout le trafic accepté ou refusé qui est envoyé au hub. Affichez les journaux dans Azure Monitor.
Points de terminaison publics ouverts involontaires	DevOps peut ouvrir accidentellement un point de terminaison public par le biais de règles NSG/ASG incorrectes.	Identique au modèle 1.	Un point de terminaison public ouvert accidentellement dans un spoke ne permettra pas l’accès, car le paquet de retour sera supprimé via un pare-feu avec état (routage asymétrique).
Protection au niveau de l’application	Les groupes de sécurité réseau et les groupes de sécurité d’application fournissent uniquement la prise en charge de la couche réseau.	Identique au modèle 1.	Le Pare-feu Azure prend en charge le filtrage de nom de domaine complet pour HTTP/S et MSSQL pour le trafic sortant et entre les réseaux virtuels.