AZURE : Network Security Groups

by Mickaël LOPES
0 comment

Bonjour,

Aujourd’hui nous rentrons dans une fonctionnalité bien sympathique dans Azure : les Network Security Groups (ou NSG pour les intimes).

Revenons plutôt au besoin : Quand nous créons un Virtual Network dans Azure, nous pouvons créer des Subnets qui sont des sous réseaux du Virtual Network.

D’ailleurs quand vous créez une Gateway pour un VPN, Azure crée un subnet dédié.

Malheureusement on veut parfois limiter la communication entre tous les subnets. On se dit qu’il faut créer un Virtual Network pour chaque « zone » mais malheureusement, il vous faudra créer une Gateway pour chaque Virtual Network pour les faire communiquer ensemble.

C’est ici que les NSG entrent en jeux.

Le but des NSG est de limiter les connexions entre les différents Subnets, chose que ne pouvais par faire les ACLs car elles ne limitent que sur les Endpoints externes.

Afin de vous expliquer tout cela, mettons en place une petite plateforme de démo.

J’ai actuellement ceci comme configuration réseau :

adressage-virtuelChacun de mes sous réseaux à une fonctionnalité particulière.

– Le FrontEnd-Subnet contient des VM hébergeant un site WEB en HA + Scale Out

– Le BackEnd-Subnet contient des machines de Développement.

– Le Replica-Subnet contient quand à lui des VMs répliquées, au niveau logiciel, de services On-Premises (AD, SQL)

– La passerelle contient donc une VM Gateway avec un VPN site à site vers chez moi

Nous avons des VMs n’ayant pas du tout les mêmes cibles.

On va donc bloquer tout ça avec des NSG

Généralités sur les NSG

Voici un petit descriptif sur les NSG

  • 100 NSG par Subscripton Azure
  • Une seule NSG par VM/Subnet
  • Une NSG peut contenir 200 règles
  • Une règle est caractérisée par :
    • Nom
    • Type: Inbound/Outbound
    • Priorité : De 100 à 4096
    • Source IP : En notation CIDR ou une plage d’adresses
    • Source Port : Un seul port, ou un range compris en 0 et 65000
    • Destination IP : En notation CIDR ou une plage d’adresses
    • Destination Port : Un seul port, ou un range compris en 0 et 65000
    • Protocole : TCP, UDP
    • Access : Allow/Deny

Les règles s’appliquent dans l’ordre de priorité donné par le critère Priority, et dans l’ordre croissant.

La notion de Type (Inbound et Outbound) est sensible à la case ! Donc il ne faut pas oublier la majuscule au début.

Le numéro du critère priorité est différent entre les Inbound et les Outbound.On peut donc avoir un 100 Inbound et un 100 Outbound.

La table de règles

Pour ceux qui ont déjà touché à la configuration d’ACL sous CISCO, vous allez être ravis de voir que la méthode est sensiblement la même.

Je vous conseille de réfléchir à cela avec un fichier Excel afin que ça soit plus simple pour réfléchir par la suite.

Mon fichier Excel est disponible ici : NSG

En voici un extrait :

NSG-EXCELSi nous prenons tout les besoins exprimés dans le fichier Excel, voici ce que cela va donner au niveau d’un schéma :

plan_visioPassons à la mise en place

Configurer des Network Security Groups

On va  voir si une Network Security Group existe :

1 GET NSG 0Aucune NSG n’existe actuellement dans ma Subscription.

Nous allons commencer par la partie Front End, avec la configuration du NSG-FE

Il faut tout d’abord créer un Network Security Group dans la même zone géographique que notre Virtual Network.

Pour avoir le nom des zones, c’est comme ceci :

2Location AzureLa création d’un Network Security Group :

3New NSG
Par défaut, un NSG possède des règles que vous pouvez obtenir comme ceci :

4 default rule nsgPassons aux besoins exprimés dans le fichier Excel.
La première règle autorisant le trafic entrant sur le port 80 depuis INTERNET

5 premier eNSG
Le reste des règles :

Ceci vous donne le résultat suivant :

6 FE FULLPour la règle FE-DNS-AZURE, nous avons comme destination 192.168.9.132/32. Vous pouvez faire des règles très précises sur les accès d’un Subnet vers une machine, voir d’une VM vers une autre VM.

Maintenant on applique notre NSG au Subnet

Testons nos règles. D’après le document je suis capable d’aller :

– sur Internet faire ce que je veux

FE vers 443– faire une requête DNS sur mes deux serveurs DNS

FE vers 53– me connecter depuis mon LAN vers ce subnet

FE depuis interneMais je ne suis pas capable de :

– me connecter au réseau de BackEnd

FE vers BE– me connecter à une machine de Replica

FE vers REPEt bien ça ne fonctionne pas si mal !

Si nous voulons savoir si un NSG est appliqué sur un subnet :

get-nsg to subnetOn continue avec les autres NSG.

Voici toutes les commandes PowerShell que j’ai utilisé :

Les modifier et supprimer

Bien entendu, il est possible de modifier et supprimer une règle d’un Network Security Group, l’application d’un NSG sur un subnet, ou encore la suppression totale d’un NSG.

Voici les commandes :

Supprimer une règle au sein du NSG :

Supprimer le NSG d’un subnet :

Supprimer un NSG :

Conclusion

Les Network Security Groups rentrent complétement dans le monde de la sécurisation des environnements dans Azure. Grâce à ça et aux ACLs, il est possible de créer des environnements sécurisés dans le Cloud Azure.

Le scénario que j’ai déroulé n’est absolument pas une Best Practice d’environnement de Production, il s’agit juste d’un test que j’ai voulu faire pour découvrir la fonctionnalité.

-Mickaël

You may also like

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations

Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.

Fermer