Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 Les 22 & 23 novembre : Accès 100% GRATUIT
à la Bibliothèque Numérique ENI. Je m'inscris !
  1. Livres et vidéos
  2. Le réseau avec Microsoft Azure
  3. Groupes de sécurité réseau
Extrait - Le réseau avec Microsoft Azure Déployez, hybridez et sécurisez vos réseaux dans le cloud
Extraits du livre
Le réseau avec Microsoft Azure Déployez, hybridez et sécurisez vos réseaux dans le cloud
1 avis
Revenir à la page d'achat du livre

Groupes de sécurité réseau

Introduction

Les trois prochains chapitres s’articulent autour de la sécurité réseau dans Azure. Pour commencer, nous allons aborder ce qui constitue l’élément de base de la sécurité réseau dans Azure : les groupes de sécurité réseau.

Principe et description des NSG

Les groupes de sécurité réseau, ou Network Security Groups (NSG), ont pour objectif de filtrer les flux entrants et sortants des ressources situées dans vos réseaux virtuels Azure. Un NSG est une ressource Azure à part entière, constituée d’un ensemble de règles de filtrage de couches 3 et 4 du modèle OSI (Open System Interconnection). Ils sont utilisés pour assurer la segmentation de votre réseau Azure et s’appliquent sur un sous-réseau, ou plus spécifiquement sur l’interface réseau d’une machine virtuelle. Il est possible de déployer le même NSG sur plusieurs sous-réseaux ou machines virtuelles, mais chaque sous-réseau ou machine virtuelle ne peut avoir que zéro ou un NSG associé.

En résumé, les NSG sont un moyen simple et rapide d’intégrer une première couche de sécurité et de filtrage sur votre réseau Microsoft Azure. C’est pour cette raison qu’ils apparaissent comme presque indispensables dans vos déploiements Azure et qu’il est très fortement recommandé de les adopter. C’est en quelque sorte l’un des standards de sécurité proposés par Microsoft pour son cloud Azure. Ainsi, lors de la création d’une nouvelle machine virtuelle, le comportement par défaut consiste à appliquer un NSG dit "de base" sur l’interface réseau.

Cette dernière contient des règles prédéfinies sur lesquelles nous reviendrons plus tard dans ce chapitre. Il est également possible de ne pas en appliquer du tout ou d’en appliquer un créé précédemment. Dans notre cas, et à titre de démonstration, les NSG n’ont pas été appliqués à la création de la machine virtuelle et seront ajoutés lors du cas concret associé à ce chapitre.

Les règles de sécurité, entrantes ou sortantes, sont dites à état (stateful). Cela signifie qu’une table d’état est conservée lorsque des flux traversent le NSG et que le filtrage s’adapte de manière dynamique à cette dernière. Par exemple, lors de la création...

Cas concret - Partie 7

Pour rappel, le déploiement est actuellement constitué du socle réseau (réseaux virtuels, sous-réseaux), de son hybridation (VPN Site-to-Site, Point-to-Site, ExpressRoute), de service Azure (compte de stockage avec liaison privée) ainsi que de plusieurs ressources de type machines virtuelles sur lesquelles nous n’avions pour le moment pas déployé de NSG. Puisque l’hybridation et les accès entre le monde local et cloud sont maintenant possibles, la Dream Company souhaite déployer une première couche de sécurité afin de pouvoir rendre le déploiement plus sûr. Pour cela, la Dream Company souhaite miser sur une solution native à Azure, peu coûteuse et rapide à déployer pour sécuriser dans un premier temps les accès depuis les VPN utilisateurs. En effet, les sites Siège et Data Center étant équipés d’équipements de sécurité, une partie du filtrage peut être effectuée en local pour le moment. Ce n’est pas le cas pour les utilisateurs VPN. Il apparaît donc clair que les NSG et ASG se présentent comme la première solution à déployer.

Régulièrement, les NSG sont utilisés afin d’exposer directement les machines virtuelles sur Internet et ainsi limiter les ports ou IP pouvant y accéder. Ici, ce ne sera pas le cas, car l’exposition des machines virtuelles se fera, lors des prochains chapitres, au travers d’un pare-feu puis d’un Bastion.

À la création de votre machine virtuelle, si cette dernière est exposée en RDP ou SSH par exemple, le NSG est automatiquement configuré afin d’ajouter une règle supplémentaire autorisant ce trafic depuis Internet. Cependant, il n’est pas conseillé de conserver ce type d’ouverture publique et c’est pour cette raison que la règle apparaît en "warning". Il est a minima conseillé de limiter la source des requêtes lorsque cela est possible.

Pour commencer à sécuriser le déploiement, l’idée est donc d’appliquer un nouveau NSG sur les sous-réseaux Subnet_1A et Subnet_1B filtrant des accès internes depuis le réseau utilisateurs...