Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Le réseau avec Microsoft Azure
  3. Pare
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

Pare-feu

Introduction

À l’image des réseaux traditionnels, les pare-feux sont un élément clé de la sécurisation de votre réseau Azure. Présents dans la majorité des architectures locales, les pare-feux sont également largement répandus dans le cloud. Une fois déployés dans Azure, ils permettent de sécuriser les accès depuis et vers vos réseaux hybridés, depuis et vers Internet, ou encore entre vos réseaux virtuels par exemple.

Nous étudierons donc au long de ce chapitre les possibilités offertes par Azure en termes de pare-feu, qu’il s’agisse de les déployer ou de les administrer.

Service de pare-feu Azure Standard

1. Principe et description du pare-feu Azure Standard

Azure Firewall, ou Pare-Feu Azure, est un service de sécurité cloud de type FWaaS (Firewall as a Service) sécurisant vos ressources déployées dans les réseaux virtuels Azure. À l’image d’un service PaaS (Platform as a Service), les solutions de FWaaS permettent de tirer parti des services managés et de s’exempter de la gestion de l’infrastructure sous-jacente aux pare-feux (virtualisation, système d’exploitation, versioning…). L’Azure Firewall est disponible en versions Standard et Premium. La première partie de ce chapitre est orientée sur les concepts globaux et les fonctionnalités standards, disponibles dans les deux versions. La dernière partie, elle, se concentrera sur les fonctionnalités supplémentaires associées au SKU Premium.

Abordons à présent les nombreux avantages d’une solution FWaaS.

Scalabilité, redondance et performance

Cette approche de pare-feu, nativement cloud, offre dans ses deux SKU une scalabilité que l’on pourrait qualifier d’illimitée et une haute disponibilité par défaut.

La scalabilité de la solution est assurée par des fonctionnalités dites d’auto-scaling (mise à l’échelle automatique), assurant l’évolutivité et l’adaptabilité automatique du pare-feu lors d’une montée en charge. Ce concept de mise à l’échelle automatique est un élément majeur des architectures modernes puisqu’il offre aux entreprises un niveau de service continuellement stable et évite ainsi toute congestion, quelles que soient la charge absorbée et la durée de cette dernière.

Ainsi le déploiement d’une solution scalable sous forme de service managé évite l’acquisition d’équipements surdimensionnés, soumis à licences et très souvent taillés pour répondre aux potentiels pics d’usage parfois très complexes à estimer ou à anticiper dans le temps.

Concernant la haute disponibilité et lorsqu’il est déployé dans une seule et même zone de disponibilité...

Cas concret - Partie 8

La Dream Company ambitionne d’augmenter son niveau de sécurité concernant le déploiement en cours et de s’assurer que l’ensemble des communications entrantes, sortantes ou circulant au travers des différents réseaux virtuels soient sécurisées. Parmi les prérequis associés à cette demande, on trouve les suivants :

  • Du filtrage de niveau 7 est nécessaire pour certains flux.

  • Des ressources devront être exposées (DNAT).

Au vu des premiers prérequis, les NSG ne semblent pas être une solution satisfaisante. L’objectif sera donc de déployer un pare-feu, pour le moment standard, centralisé et permettant de sécuriser les accès internes et externes. Ce pare-feu devra pouvoir être géré de manière centralisée en utilisant des stratégies de sécurité.

De manière générale, le déploiement d’un pare-feu Azure peut se faire dans n’importe lequel de vos réseaux virtuels. Cependant, il est le plus souvent intégré dans des modèles d’architecture dits "Hub-and-Spoke" et donc situé dans un réseau virtuel central "hub".

Le pare-feu Azure Standard sera donc ici positionné au sein du réseau virtuel nommé vNet_Hub, dans lequel est déjà configuré le sous-réseau GatewaySubnet. Sous-réseau, rappelons-le, par lequel arrivent les utilisateurs locaux ainsi que les utilisateurs en VPN point à site lorsqu’ils communiquent avec notre environnement Azure. Le pare-feu Azure Standard pourra donc sécuriser les flux provenant ou à destination de ces réseaux et compléter les NSG déjà en place, ou remplacer certaines de ces règles.

De plus, pour répondre aux attentes d’exposition sécurisée de la société, le pare-feu portera une IP publique permettant d’exposer de manière sécurisée des services hébergés dans Azure en utilisant de la traduction d’adresses DNAT.

Finalement, le pare-feu sera utilisé pour sécuriser les flux de réseaux virtuels à réseaux virtuels. Comme il existe actuellement du peering entre nos réseaux...

Azure Firewall Manager

1. Principe et description de l’Azure Firewall Manager

Lorsque plusieurs pare-feux sont déployés au travers de différentes souscriptions ou régions, il peut vite s’avérer contraignant de maintenir chacun d’entre eux individuellement. De même, à l’image du cas concret, la création de routes et de règles, ainsi que leur maintien dans le temps peut s’avérer chronophage et complexe.

C’est pourquoi Microsoft propose l’Azure Firewall Manager, un service de gestion de la sécurité permettant de déployer et d’administrer vos pare-feux Azure standard ou Premium, de manière centralisée. Le Firewall Manager permet de gérer depuis un même endroit l’ensemble de vos pare-feux, des règles et des routes, et ce même si les pare-feux sont déployés dans des régions ou souscriptions différentes.

Nous verrons également dans la dernière partie de ce chapitre que le pare-feu Azure Premium s’appuie également sur le Firewall Manager.

L’offre Azure Firewall Manager inclut trois principaux éléments :

  • La création de stratégie de pare-feu Azure.

  • La sécurisation de pare-feu Azure déployés dans des réseaux virtuels, qu’ils soient nouvellement créés ou convertis, par l’application des stratégies.

  • La sécurisation de pare-feu Azure déployés dans des hubs virtuels (Virtual WAN), nouvellement créés ou convertis, ainsi que la gestion de partenaire de sécurité tiers, par l’application des stratégies.

a. Gestion centralisée des politiques de sécurité

Pour gérer les politiques de sécurité, Azure Firewall Manager repose sur la création de stratégies. Une stratégie correspond à un ensemble de règles (NAT, application, réseau, Threat Intelligence, DNS…) packagées, vue comme une ressource Azure indépendante et pouvant être attachées à différents pare-feux. La mise en place de stratégies facilite grandement la création et le maintien des règles grâce à un point de gestion unique pour toute création ou modification....

Cas concret - Partie 9

La Dream Company souhaite migrer ses règles vers un modèle plus centralisé et prône l’évolutivité. Dès lors, l’Azure Firewall Manager apparaît comme l’unique solution permettant de répondre à ce type de problématique.

1. Création d’une stratégie de pare-feu

La première étape consiste à mettre en place une nouvelle stratégie. Pour créer une nouvelle stratégie de pare-feu en partant de zéro, depuis le portail Azure, procédez comme suit :

 Recherchez et sélectionnez Firewall Manager.

 Rendez-vous dans Stratégies de pare-feu Azure.

Lors du premier déploiement, il est également possible de sélectionner l’option Mise en route qui regroupe l’ensemble des éléments permettant de débuter sur le Firewall Manager puis de sélectionner Voir les stratégies de pare-feu Azure.

images/07EP76.png

 Cliquez sur Créer une stratégie de pare-feu Azure.

 Complétez l’Abonnement, le Groupe de ressources, le Nom et la Région.

À nouveau, nous nous appuierons sur le groupe de ressources dédié aux ressources réseau, à savoir NETWORK-RG. La politique sera nommée Politique_Standard car cette dernière correspondra au socle minimum de sécurité standard de la société. Finalement, la stratégie est déployée en Europe occidentale.

Une stratégie déployée dans une région peut toujours être attachée sur un pare-feu déployé dans une autre région.

images/07EP77.png

Le niveau de stratégie est conservé sur Standard pour le moment, et aucune stratégie parente n’est configurée.

 Cliquez sur Suivant : Paramètres DNS.

 Cliquez sur Activé.

 Pour Serveurs DNS, sélectionnez Par défaut.

 Pour Proxy DNS, sélectionnez Activé.

images/07EP78.png

La stratégie déployée étant standard, les onglets Inspection TLS et IdP ne sont pas disponibles.

 Cliquez sur Règles.

 Cliquez sur Ajouter une collection de règles.

 Complétez les champs Nom, Type de collection de règles, Priorité et Action de collection...

Service de pare-feu Azure Premium

Azure Firewall Premium, ou Pare-feu Azure Premium, est une évolution du modèle Standard précédemment étudié. Cette nouvelle version inclut l’ensemble des fonctionnalités et caractéristiques du pare-feu standard, telles que la haute disponibilité native, la flexibilité, ou encore le panel de règles de sécurité déjà évoquées.

Toutefois, cette version est enrichie de nombreuses fonctionnalités rendant la solution plus complète et destinée aux entreprises pour lesquelles le niveau de sécurité offert par un pare-feu standard ne serait pas suffisant.

Parmi les fonctionnalités clés disponibles en version Premium du pare-feu, on retrouve les suivantes :

  • L’inspection TLS.

  • L’IDPS (Intrusion Detection and Prevention System).

  • Le filtrage d’URL.

  • La catégorisation web.

Très récurrentes dans les réseaux d’entreprises, ces fonctionnalités étaient fortement sollicitées par les utilisateurs de pare-feux Azure. Revenons sur chacune d’entre elles.

1. Inspection TLS

L’inspection TLS (ou déchiffrement TLS/SSL) permet le déchiffrement des connexions sécurisées en TLS (ou anciennement SSL) dans le but d’inspecter le contenu et de potentiellement y découvrir des menaces au sein du trafic chiffré.

Sans déchiffrement, et bien qu’ils soient routés au travers des pare-feux, les flux (en-tête et/ou corps de message) restent chiffrés et il s’avère donc impossible d’appliquer une partie des mécanismes de sécurité avancée tels que l’IDPS ou l’application de règles de filtrage sur des chemins d’URL complets. Seules des règles de type filtrage FQDN sont possibles car ces dernières reposent sur des extensions visibles sur les flux chiffrés.

L’inspection TLS fonctionne dans un modèle de sécurité connu, appelé le Man-in-the-middle. Ainsi, les pare-feux se placent en coupure des échanges entre vos clients ou clients et serveurs et c’est ce dernier qui se charge de déchiffrer le trafic pour l’inspecter. Le processus d’inspection TLS pour un flux sortant...

Cas concret - Partie 10

La Dream Company souhaite donc renforcer sa sécurité et tirer bénéfice des nouvelles fonctionnalités associées au pare-feu Azure Premium. Puisqu’un pare-feu Standard avec stratégie de sécurité est déjà déployé, il semble plus cohérent de migrer cette dernière vers une politique Premium et d’y ajouter les nouvelles règles avancées. De même, une migration du pare-feu vers un modèle Premium est nécessaire.

Si aucun pare-feu n’est en place dans votre environnement, il est tout à fait possible, et même recommandé, de déployer directement un pare-feu Azure Premium avec une stratégie adéquate.

Pour rappel, la stratégie actuelle est une stratégie Standard ne permettant pas de configurer les fonctionnalités d’inspection TLS ou d’IDPS :

images/07EP108.png
images/07EP109.png

Plusieurs étapes sont obligatoires pour migrer votre architecture vers un modèle Premium. La première étape consiste à migrer votre stratégie Standard. Pour ce faire, Microsoft met à disposition un script PowerShell disponible sur leur site internet pour vous accompagner à migrer de manière automatique votre stratégie Standard vers une seconde stratégie, différenciée cette fois par le suffixe "_premium", de type Premium. Une fois cette politique disponible, elle peut être utilisée pour déployer votre nouveau pare-feu Premium, s’appuyant sur le modèle existant.

Puisqu’il est question de redéployer un pare-feu Premium en lieu et place du pare-feu Standard, une coupure de service est à prévoir.

Le script, nommé Transform-Policy.ps1, fonctionne en plusieurs parties :

  • Il valide premièrement qu’une stratégie Standard existe.

param ( 
   #Resource id of the azure firewall policy. 
   [Parameter(Mandatory=$true)] 
   [string] 
   $PolicyId, 
 
   #New filewallpolicy name, if not specified will be 
the previous name with the '_premium' suffix 
   [Parameter(Mandatory=$false)] 
   [string] 
   $NewPolicyName = "" 
) 
$ErrorActionPreference...

Azure Firewall ou Network Virtual Appliance

Jusqu’à présent, l’ensemble de ce chapitre s’est orienté sur le modèle nativement cloud de Firewall as a Service proposé par le pare-feu Azure Standard ou Premium. Toutefois, la sécurisation de vos environnements au travers de pare-feux peut également se faire au travers de déploiement de NVA (Network Virtual Appliance). Pour rappel, les NVA sont des machines virtuelles de solutions réseau tierces, totalement packagées, disponibles au travers de la place de marché (Marketplace) et directement déployables depuis votre portail Azure. Cette fois, nous parlerons donc plutôt de modèle IaaS.

De nombreuses NVA sont supportées par Azure et fournissent un panel très large de fonctionnalités réseau : pare-feu, équilibreur de charge, WAF (Web Application Firewall), optimisation WAN (Wide Area Network), SD-WAN (Software-Defined Wide Area Network), routeur, IPS… Elles proviennent d’éditeurs importants du marché (Palo Alto, F5, Fortinet, Cisco, Watchguard…) et sont globalement les solutions que l’on retrouve dans les réseaux d’entreprise locaux habituels.

Il est important de noter que les images NVA disponibles dans le Marketplace font l’objet d’un processus très strict et doivent répondre à un certain niveau d’exigence en termes de documentation, de spécification, de mise à jour de sécurité ou encore de support afin de pouvoir être rendues publiques.

De manière générale, les NVA sont un élément très courant dans les déploiements réseau importants sur Azure. Suivant le besoin, elles peuvent venir se substituer aux composants natifs cloud ou simplement les compléter.

Afin d’illustrer ce propos et de vous accompagner dans le choix d’un pare-feu nativement cloud ou d’une NVA, la suite de ce chapitre est consacrée aux avantages et inconvénients de chacun des modèles, ainsi qu’à leurs limitations respectives.

1. Pourquoi et quand choisir une NVA plutôt  qu’un pare-feu Azure ?

Premièrement, l’un des avantages principaux des pare-feux de type IaaS/NVA n’est autre que le fait d’utiliser...