🚦Guide d'accès, de gestion et du filtrage interne et externe

Le Gateway Firewall permet d’assurer une étanchéité entre les réseaux internes et les réseaux externes, aussi bien en entrée qu’en sortie. Il constitue une première ligne de défense pour contrôler les flux Nord-Sud.

Fonctionnement

• Il s’applique aux passerelles de type Nord-Sud, telles que :

  • Edge Gateway

  • Distributed Firewall (DFW), lorsqu’il est utilisé pour filtrer des flux dont la source ou la destination se trouve en dehors du cluster.

• Pour un filtrage inter-réseau ou intra-réseau (flux Est-Ouest), il est nécessaire d’utiliser le Distributed Firewall.

Distributed Firewall (DFW)

Le DFW permet de contrôler les communications entre plusieurs réseaux internes ou entre un réseau interne et un réseau externe, à condition que le trafic transite par le DFW.

Cas d’usage

• Principalement utilisé pour les connexions Est-Ouest.

• Fonctionne également avec des éléments de réseau externes, tant que le trafic passe par le DFW.

Utilisation des tags pour la sécurité

Il est possible d’associer des tags à différents objets (VM, réseaux, rôles, etc.) afin de :

• Créer des groupes dynamiques basés sur ces tags (recommandé).

• Définir des politiques de sécurité granulaires et automatisées.

• Éviter l’utilisation de plages d’adresses IP statiques.

Plus d’informations : https://public-sigma.atlassian.net/wiki/spaces/hostiz/pages/edit-v2/482156#Les-tags-(ou-balises-de-s%C3%A9curit%C3%A9)

Prérequis pour l’utilisation du DFW

Avant de pouvoir utiliser le Distributed Firewall, il est nécessaire de :

1. Octroyer les droits d’accès appropriés au profil utilisateur pour permettre la gestion du DFW.

2. Activer le DFW sur le VDC Group concerné.

Cas d’usage

Introduction

Portail cloud apporte un nouveau paradigme à la stratégie de firewall avec le distributed firewall. Du point de vue de la sécurité, cela signifie un contrôle et une politique centralisés avec une application distribuée omniprésente. Alors que les firewalls traditionnels sont des goulots d'étranglement discrets vers lesquels le trafic doit être dirigé (et qui peuvent être contournés), les distributed firewalls (DFW) fonctionnent sur chaque carte réseau virtuelle (VNIC) de chaque VM, voyant chaque paquet entrant ou sortant de la VM sans qu'il soit nécessaire de réacheminer ces paquets, et sans qu'il soit nécessaire de modifier l'adressage IP.

Lorsqu'un vMotion a lieu et qu'une VM est déplacée d'un hôte à un autre, les anciens firewall conçus pour une infrastructure statique imposent une charge plus importante à l'infrastructure pour diriger le trafic vers eux. Le DFW étant lié au vNIC de la VM, il est impossible de le contourner car il se déplace avec la VM dans le cadre de l'événement vMotion. Cela signifie également que seul l'administrateur du firewall peut désactiver sa fonctionnalité pour permettre au trafic de contourner le DFW.

Lorsque l'on compare le distributed firewall à l'ancienne architecture de firewall, il est important de noter certaines limitations qui faisaient partie de l'ancien modèle :

• ne peuvent pas sécuriser les points d'extrémité sur le même VLAN

• les anciens firewalls gèrent leurs politiques autour d'adresses IP ou de groupes d’adresses.

  • avec le portail cloud, les critères de regroupement peuvent être logiques et concerner le système d'exploitation, le nom de la machine virtuelle et/ou des tags.

En bref, contrairement aux firewalls matériels qui sont enveloppés dans une enveloppe logicielle pour devenir une VM, le firewall du portail cloud est né du logiciel et a une architecture logicielle. Le firewall du portail cloud est une architecture firewalls qui prend en charge les besoins divers et étendus de l'infrastructure moderne.

Il existe 2 types de firewall dans l'architecture du portail cloud:

• Le gateway firewall (Edge Gateway)

  • conçu pour fonctionner à la périphérie ou aux frontières ; il s’agit d’un firewalls nord-sud

  • fonctionne sur des nœuds NSX Edge ; les nœuds NSX Edge sont des appliances virtuelles gérés par le portail cloud (ils fournissent des services de réseau et de sécurité pour le trafic nord-sud, en interface avec les routeurs TOR)

  • a son propre firewall ou table de règles de sécurité ; il fonctionne individuellement tout en étant géré de manière centralisée par le portail cloud

  • facilite la création de zones de sécurité en fonction des limites du réseau et de la gestion des règles de firewall par zone ou par organisation

• Le distributed firewall (Datacenter Groups)

  • s'exécute dans chaque hyperviseur, conteneur ou serveur physique ; il s'agit d'un firewall est-ouest

  • intégré à l'hyperviseur comme si chaque VM avait son propre firewall

  • géré comme un firewall universel

  • est indépendant de la topologie du réseau et permet une micro-segmentation sans nécessiter de segmentation du réseau

Combinés ensemble, le gateway firewall et le distributed firewall peuvent sécuriser le trafic nord-sud et est-ouest du datacenter virtuel.

Fonctionnement du Gateway Firewall

Définition

Le gateway firewall (ou pare-feu de passerelle) est pris en charge au niveau des routeurs et joue un rôle clé dans la sécurité périmétrique des environnements cloud.

Fonctionnalités principales

Le gateway firewall fournit des services essentiels qui ne peuvent pas être distribués, notamment :

• Pare-feu périmétrique

• NAT (Network Address Translation)

• DHCP (Dynamic Host Configuration Protocol)

• VPN (Virtual Private Network)

• Équilibrage de charge (Load Balancing)

Architecture

Pour fonctionner, le gateway firewall s’appuie sur le composant Services Router (SR) du routeur. Cela implique qu’il est mis en œuvre au sein des nœuds de transport NSX Edge, qui sont des appliances dédiées à ces fonctions.

Firewalling périmétrique

Le gateway firewall étant conçu pour fonctionner aux frontières, il est idéal pour concevoir des zones entre les tenants.

Le gateway firewall est appliqué aux liaisons montantes et aux interfaces de services de la passerelle.

Dans cette figure, les Tenant 1 et Tenant 2 possèdent leur propre politique de sécurité. Les deux tenants peuvent disposer d'un espace d'adressage privé qui se chevauche.

La politique de sécurité est mise en œuvre au niveau de la passerelle pour tout le trafic entrant ou sortant des tenants. La passerelle T0 est l'endroit où la politique de sécurisation de l'environnement est appliquée. Cette politique est appliquée sur l'interface nord.

Comme le montre ce scénario, la passerelle T0 est également un connecteur inter-tenants. Pour le firewall entre les tenants, la politique est appliquée sur l'interface nord des T1. À ce niveau on peut définir la politique selon laquelle le Tenant 1 peut communiquer avec le Tenant 2, et inversement.

Par défaut, seules les communications au travers d’IP publiques sont autorisés sur la T0 entre les tenants (si les règles firewalls sur les tenants - T1 - le permettent). Les communications directes en adressage privé sont prohibées. Tous les flux en transitent sur la T0 sont uniquement des flux publics qui sont possibles au travers de règles de NAT.

Zone de services SIGMA

L’accès à la zone de services SIGMA est réalisée au travers de la provider gateway. Comme indiqué précédemment, le routage privé s’arrête à la provider gateway, donc tout flux sortant de la provider gateway par le gateway firewall est adressé publiquement.

L’intégralité des services SIGMA sont adressés en IP publique afin de rendre les communications possibles entre un tenant du portail cloud et les services d’infogérance/d’hébergement.

Plus d’infos : 🏢Accès aux services Cloud SIGMA

Fonctionnalités/Services

Le gateway firewall est l'endroit où les services sensibles à l'état tels que NAT, DHCP, VPN et LB sont mis en œuvre.

Distributed firewall

Définition

Le distributed firewall peut être utilisé pour la segmentation réseau et la micro-segmentation pour les serveurs virtuels et/ou physiques gérés par cloud. Le distributed firewall est un firewall est-ouest :

• il inspecte chaque paquet entrant et sortant d'une VM, en fonction d'un paquet voyageant sur la VNIC de la VM. Il existe dans le noyau de l'hyperviseur et sait s’adapter linéairement à l'ajout de calcul.

• les règles DFW se déplacent avec la VM lors des événements vMotion. Cela signifie que l'état du flux de trafic est préservé, quel que soit l'hôte vers lequel une VM est déplacée.

• il fournit une politique centrale, appliquée de manière distribuée.

• il peut activer à la fois IPv4 et IPv6 pour chaque règle firewall. Pour optimiser les ressources, il est recommandé de n'activer IPv4 que dans les règles firewall où IPv4 est le seul protocole utilisé.

Firewalling interne

Le DFW est utilisé pour créer des zones. Les conteneurs de couleurs représentent les zones. Chaque zone peut être définie selon la politique de sécurité établie :

• Segmentation par environnement (prod/non prod)

• Segmentation par application et/ou par type d’exposition (front/back)

Toutes ces VM peuvent être positionnées sur les mêmes segments et être sécurisées par la politique DFW, sans qu'il soit nécessaire de modifier l'infrastructure réseau sous-jacente.

Exemple :

Le paquet quittant la VM doit traverser le DFW de la VM. Cela signifie que le DFW doit autoriser la sortie de ce protocole. Dans ce cas, il existe une règle qui l'autorise. Grâce au routage distribué, le paquet ne quitte jamais l’ESX mais apparaît à la VM de destination qui, par coïncidence, se trouve sur le même ESX. Le paquet arrive maintenant au VNIC de la VM de destination, mais il doit passer par le DFW de la VM de destination.

Segmentation et Micro-segmentation

Exigences et contraintes

Durant ces dernières années, les pirates ont profité de l'accès au maillon le plus faible pour s'introduire dans le reste de l'infrastructure. La segmentation couvre le cas où l'on souhaite créer une zone de dispersion plus petite en cas de violation.

Grâce à la segmentation, tout point de terminaison compromis aura moins d'accès à d'autres points de terminaison, même si les informations d'identification sont compromises. La segmentation peut être une segmentation de zone (séparation de l'environnement en deux ou trois parties - production et non-production, par exemple), une segmentation par VLAN, une segmentation par application ou une micro-segmentation (où chaque point d'extrémité est segmenté).

Avec l'approche traditionnelle utilisant des firewalls physiques, la segmentation était limitée aux zones et aux VLANs. Tout paquet ou flux devant être inspecté en vue d'un accès devait être dirigé vers le firewall, qui déterminait alors l'accès en fonction de la matrice de flux implémentée. Ce modèle de segmentation présente plusieurs limites :

• Manque de flexibilité de la segmentation / manque de visibilité intra-VLAN (moins efficace)

  • les applications peuvent s'étendre sur plusieurs VLANs ; un VLAN peut contenir plus d'une application

  • toute modification de la segmentation nécessite une réorganisation du réseau et un réadressage potentiel des applications

  • deux points d'extrémité sur le même VLAN ne sont pas isolés l'un de l'autre

• Le trafic doit être inévitablement dirigé vers le firewall (complexité)

  • une ingénierie du trafic est nécessaire pour éviter que les firewalls ne soient contournés

• Manque d'évolutivité de la plateforme (coût élevé)

Une infrastructure moderne doit pouvoir suivre la création, la mise à jour et la suppression des applications modernes. Les anciens firewalls n'ont jamais été conçus pour des environnements dynamiques.

Types de segmentation

En utilisant le DFW, il est possible de segmenter le réseau comme on le souhaite. Il existe quatre types de segmentation de base, dont plusieurs coexistent, chacun étant appliqué à différentes sections de l'environnement :

• Segmentation par zone

Peut être aussi générale qu'une segmentation entre la production et la non-production, ou beaucoup plus détaillée, par unité commerciale, fonction ou offre de produits. L'important est que chaque zone soit définie indépendamment des segments, des VLAN, des centres de données ou d'autres structures. Les zones sont des définitions entièrement logiques qui peuvent être utilisées pour définir une politique de sécurité.

• Segmentation VLAN

Il s’agit du type de segmentation le plus couramment utilisé. Dans ce modèle, un segment IP est l'élément qui définit la source ou la destination de la politique de sécurité.

• Segmentation des applications

Utilisée pour définir un anneau de sécurité logique autour d'une application. Comme les applications ne sont pas souvent comprises en détail, il peut être pratique de définir simplement un tag pour une application donnée et d'appliquer ce tag à tous ses composants, puis d'autoriser une communication totale entre ces éléments. Cela apporte une plus grande sécurité que la définition d'une grande zone qui peut être constituée de plusieurs applications, sans nécessiter la compréhension détaillée requise pour la micro-segmentation.

• Micro-segmentation

Modèle de sécurité dans lequel la communication entre les éléments est définie de la manière la plus explicite possible. À l'extrême, la micro-segmentation est la définition explicite de la communication entre des éléments appariés. Cela est complexe d'un point de vue opérationnel, c'est pourquoi cloud offre une micro-segmentation basée sur des balises qui permettent une définition explicite par groupes.

La proposition de valeur du portail cloud dans la segmentation est qu'il s'adapte à toutes les stratégies de segmentation afin qu'elles puissent coexister. Le passage d'un modèle de sécurité à un autre s'effectue par une simple impulsion de politique, sans qu'il soit nécessaire de réimprimer ou de réarchitecturer une quelconque infrastructure réseau, contrairement aux firewalls traditionnels qui ne peuvent pas aller plus loin dans la segmentation que la segmentation VLAN en raison de leurs limitations architecturales.

Implémentation

Le firewall du portail cloud permet aux organisations d'atteindre le modèle d'accès du moindre privilège en utilisant la segmentation par phases. L'idée est de réduire progressivement la surface d'attaque par étapes.

Phase 1 : Segmentation des zones

Commencer par une segmentation plus large du réseau en créant des zones virtuelles pour diviser le centre de données en zones plus petites et les entourer d'une barrière de sécurité. Définir la politique cloud de firewalling nécessaire en fonction des exigences de sécurité de la zone de l'organisation. Par exemple, le regroupement dynamique portail cloud basé sur les tags peut être utilisé pour créer des zones DMZ, Prod, Non-Prod ou Services et utiliser ce groupe de zones pour définir les contrôles/politiques de sécurité respectifs pour le trafic inter-zones.

Phase 2 : Segmentation des applications

La segmentation des applications constitue l'étape suivante pour parvenir à un modèle Zero Trust afin de réduire davantage la surface d'attaque. Cette phase permet d'entourer une application d'une clôture. Ainsi, tous les workloads au sein d'une application peuvent communiquer, mais toute communication avec l'extérieur est limitée par la politique de segmentation des applications. Il est possible de commencer par quelques applications critiques ou faciles à segmenter et de mettre en place ce dispositif de sécurité pour toutes les applications au fil du temps.

Phase 3 : Micro-segmentation

Il s'agit de l'étape finale pour fournir un modèle Zero Trust dans lequel seul le trafic nécessaire est autorisé entre les applications, les niveaux d'application et les services. C'est la phase la plus complexe, car il faut pouvoir référencer tous les ports et les protocoles de chaque applications. Comme pour la segmentation des applications, cette phase se fera également par étapes, en commençant par quelques applications et en s'étendant à toutes les applications au fil du temps.

Élaboration des politiques de sécurité de votre espace Cloud

Bien qu'il soit possible d'élaborer une politique cloud de la même manière qu’une politique de firewall traditionnelle, cela reste fortement déconseillé notamment dans les environnements à grande échelle si l'objectif est d'obtenir une solution solide et à long terme.

La politique de distributed firewall est livrée avec un “Allow” dans la règle par défaut. Cela s'explique par le déni de service potentiel qu'un refus par défaut impliquerait dans un environnement est-ouest. L'action de la règle par défaut peut être modifiée pour “drop” ou “reject” (ICMP Unreachable). Il néanmoins recommandé de définir cette règle à “drop” afin de construire une politique explicite avec un refus implicite.

Consultation des règles

Les firewalls mettent en œuvre un ordre de recherche des règles de haut en bas. Lorsqu'un paquet correspond, il sort de la recherche en fonction du traitement indiqué dans la règle correspondante.

Par défaut, le DFW implémente le modèle de table de règles et de table de flux que la plupart des firewalls utilisent.

Le traitement d'un paquet se déroule comme suit :

Un paquet IP identifié comme pkt1 correspond à la règle numéro 2. L'ordre des opérations est le suivant :

• Une recherche est effectuée dans la table de suivi des connexions pour déterminer s'il existe déjà une entrée pour le flux.

• Comme le flux 3 n'est pas présent dans la table de suivi des connexions, une recherche est effectuée dans la table des règles pour identifier la règle applicable au flux 3. La première règle qui correspond au flux sera appliquée.

• La règle 2 correspond au flux 3 et l'action est définie sur "Allow".

• Comme l'action est définie sur "Allow" pour le flux 3, une nouvelle entrée est créée dans la table de suivi des connexions. Le paquet est ensuite transmis hors de DFW.

Les paquets suivants sont traités dans cet ordre :

• Une recherche est effectuée dans la table de suivi des connexions pour vérifier si une entrée pour le flux existe déjà.

• Une entrée pour le flux 3 existe dans la table de suivi des connexions. Le paquet est transmis hors de DFW

Champ d’application

Dans cloud, le champ “Applied To” peut limiter la politique à un cluster, un hôte, une VM ou même un vNIC individuel (chacun réduisant considérablement la taille de l'ensemble de règles appliquées). Ainsi, la politique portée est d'emblée inférieure à la norme.

LA pratique la plus importante est l'utilisation du champ “Applied To”.

“Applied To” est le champ qui indique quelles VNICs recevront la règle en question. Il limite la portée d'une règle donnée. Par défaut, chaque règle est appliquée à chaque réseau virtuel. Cela signifie que s'il y a 1 000 VM dans l'environnement et qu'une règle permet à la VM A de parler à la VM B, toutes les 1 000 VM recevront cette règle au lieu de seulement A et B, soit 998 VM de trop.

Dans Portail cloud, ce champ n’est disponible que sur le gateway firewall et celui-ci peut être appliqué unitairement par règle. Sur le distributed firewall, ce champ n’existe pas car il est implicite à toute la politique (par défaut).

La règle suivante clarifie ce qu'il faut mettre dans le champ “Applied To” :

• Si la source est quelconque (externe à l'environnement cloud), appliquer la règle aux destinations

• Si la source est quelconque, et peut inclure des sources à l'intérieur de l'environnement cloud, appliquer la règle à tout (DFW).

• Si la source et les destinations sont clairement définies dans la règle, appliquer la règle à la source et destinations.

Cette simple étape permettra à votre politique cloud de partir du bon pied.

Limites

La limitation du nombre de règles est grandement améliorée par le champ “Applied To” décrit précédemment. Les limites sont définies ici https://configmax.vmware.com/..

Groupes de sécurité

Les groupes de sécurité sont très utiles pour définir la source ou la destination dans une règle. Bien que le concept de regroupement soit trivial (un terme utilisé pour décrire de nombreux objets), l'utilisation des groupes peut être optimisée si les bonnes pratiques sont connues dès le départ.

Bonnes pratiques

Lors de la définition de la structure de regroupement des ressources, les principes suivants s’appliquent :

• Utilisation des blocs CIDR :
  Si les environnements de production et non-production utilisent des blocs CIDR distincts, ces blocs doivent servir de base pour structurer les regroupements.

• Regroupement par environnement et zone :
  Il est recommandé de créer des regroupements plus larges selon l’environnement (prod, dev, test…) et la zone de disponibilité, en s’appuyant sur les sous-réseaux ou segments IP.

• Regroupement au niveau applicatif :
  Pour les regroupements plus fins, au niveau des applications, privilégier l’usage de groupes dynamiques basés sur :

  • les tags des machines virtuelles (VM) 🚦Guide d'accès, de gestion et du filtrage interne et externe | Tags,

  • le nom des VM,

  • ou une combinaison des deux.

• Simplicité des critères dynamiques :
  Lors de l’utilisation de critères multiples (AND/OR) dans les regroupements dynamiques, il est important de limiter la complexité pour éviter l’inclusion de membres inattendus.

• Filtrage précis :
  L’utilisation de critères de type “Equal to” sur les tags ou les noms permet de mieux contrôler les membres inclus dans un regroupement.

Types de groupes

Statique

Les Static Groups permettent de créer des groupes logiques contenant des réseaux d’organisations. Toutes les VMs présentes dans ces réseaux seront implicitement inclues dans ce groupe.

Utilisation recommandée : sur le DFW dans le cadre d’une migration vers cloud

IP Sets

Les IP Sets permettent de déclarer des IP, des réseaux et des ranges.

Utilisation recommandée : sur le GFW pour renseigner des IP Publiques / sur le DFW dans le cadre d’une migration vers cloud

Dynamique (recommandé)

Les Dynamic Groups permettent d’utiliser des balises de sécurité (tags) pour obtenir une appartenance dynamique à un groupe. En utilisant une combinaison de plusieurs balises à l’aide de l’opérateur « AND », il est possible d’instaurer des limites de sécurité ou des zones virtuelles à la profondeur nécessaire (application, niveaux d’application ou au niveau des VM individuelles).

Utilisation recommandée : sur le GFW, et sur le DFW dans le cadre d’une segmentation/micro-segmentation

Les tags (ou balises de sécurité)

L’utilisation de tags (appelés aussi balises de sécurité) dans la définition des politiques de sécurité présente de nombreux bénéfices, notamment en matière d’automatisation, de cohérence et de simplification de la gestion des règles. Lorsqu’ils sont correctement utilisés, les tags :

• Accélèrent l’automatisation des déploiements et de la gestion des politiques.

• Permettent de définir des politiques cohérentes et réutilisables.

• Évitent la prolifération des règles en réduisant la dépendance à des critères statiques comme les adresses IP ou la topologie réseau.

Comment ?

• Indépendance vis-à-vis de l’infrastructure :
  Les politiques ne dépendent ni des adresses IP (IPv4/IPv6), ni de la topologie physique ou logique du réseau.

• Automatisation du cycle de vie des politiques :
  Les règles de sécurité peuvent être automatiquement appliquées aux nouvelles applications dès leur approvisionnement.

• Granularité et flexibilité :
  Les politiques peuvent être dynamiques et spécifiques à un niveau d’application, à une application donnée, à une zone ou à un tenant.

• Facilité de réplication :
  Les politiques peuvent être facilement répliquées et automatisées pour différents environnements (dev, test, prod…).

Pour utiliser les Tags, vous pouvez consulter notre procédure de configuration ici : 📈Passez à l'échelle | 🔐Security-TAG

Les tags : pour une sécurité automatisée

Les tags jouent un rôle essentiel dans l’automatisation de la sécurité dans les environnements cloud. Ils permettent de définir des politiques dynamiques, cohérentes et adaptées aux besoins spécifiques de chaque ressource.

Principaux usages et avantages :

• Automatisation de la sécurité :
  Grâce aux tags, les politiques de sécurité peuvent être automatiquement appliquées aux nouvelles machines virtuelles (VM) dès leur création, sans intervention manuelle.

• Appartenance dynamique aux groupes de sécurité :
  Les tags de sécurité permettent de regrouper dynamiquement les VM selon des critères définis, facilitant la gestion des accès et des règles.

• Personnalisation avancée :
  Il est possible de créer des tags personnalisés pour identifier les VM selon :

  • l’environnement (prod, dev, test…),

  • la zone de disponibilité,

  • le tenant,

  • l’application,

  • le niveau (frontend, backend…),

  • le système d’exploitation,

  • et bien d’autres attributs.

• Flexibilité et granularité :
  Jusqu’à 30 tags par VM peuvent être utilisés, permettant une grande finesse dans la définition des politiques.

• Politiques différenciées :
  Les tags permettent d’appliquer des règles spécifiques selon l’OS, l’environnement ou tout autre attribut pertinent, assurant une sécurité adaptée à chaque contexte.

Tags multiples vs Tags combinés

Les tags combinés aident à :

• insérer plus de tags que les 30 maximum par VM

• avoir indirectement plus de 4 critères AND et plus de 3 critères OR dans un groupe (ce qui est la limite)

Néanmoins :

• Cela nécessite une bonne planification et induit moins de flexibilité si le tag doit être mise à jour.

• Il faut également utiliser des critères de correspondance de type regex (contains/starts-with/end-with) pour construire un groupe plus large, contrairement aux tags multiples pour lesquelles la définition du groupe utilise toujours l'opérateur &&.

• Cela augmente le nombre de tags à configurer

  • Par exemple, si un tenant possède 3 000 applications à trois niveaux dans trois environnements (Dev, Test et Prod). Si ce tenant adopte uniquement une approche de tagging combiné (en définissant un tag pour chaque combinaison), il aura 3 000 (applications) x 3 (environnements) x 3 (niveaux) = 27 000 tags nécessitant 27 000 règles ou plus. En revanche, s'ils utilisent trois tags (une pour l'environnement, une pour l'application et une pour le niveau), ils obtiendront 3 006 tags.

La meilleure pratique est, si le nombre d'exigences de tags et de critères de groupe sont dans la limite supportée, de rester simple (d'avoir de multiples tags individuels et de ne pas avoir de tag combiné).

Tagging des machines virtuelles

Les tags peuvent être appliqués sur un serveur. Le tableau ci-dessous démontre les fonctionnalités possibles en ce qui concerne le cas d'utilisation, les options de regroupement, la rétention des tags et d'autres opérations de tagging. Cela permet de comprendre la mise en œuvre globale et d'avoir une meilleure stratégie de tagging.

Timers de sessions

Les timers de session définissent la durée pendant laquelle la session est conservée après une période d'inactivité. À l'expiration de ce délai, la session est fermée. Par défaut, le distributed firewall et les gateways firewalls ont des timers de session de firewall indépendantes et séparées. Ceci est configurable par passerelle Tier-0/Tier-1 ou par groupe de VM pour DFW à l'aide de Groupes. En d'autres termes, les valeurs de session par défaut peuvent être définies en fonction des besoins. Si une valeur trop faible peut entraîner des dépassements de délai fréquents, une valeur trop élevée consommera inutilement des ressources.

La customisation d’un profil de sécurité ne peut être réalisé que par le provider.

Les figures ci-dessous indiquent les valeurs par défaut des timers de session :

Bonnes pratiques

Les firewalls jouent un rôle essentiel dans la sécurité du réseau en surveillant et en contrôlant son trafic sur la base de règles de sécurité définies. Un firewall est la première ligne de défense contre les activités malveillantes, ce qui en fait un élément indispensable de toute stratégie complète de sécurité réseau.

S’il est essentiel de disposer d’un firewall, son efficacité est directement liée à une configuration adéquate et à une gestion continue. En l’absence d’un ensemble de règles bien définies et d’une surveillance attentive, un firewall peut trop facilement autoriser un trafic malveillant ou empêcher une communication légitime.

Politiques de sécurité

• Politique de refus par défaut : adopter une politique de refus par défaut pour le trafic entrant. N’autoriser explicitement que le trafic nécessaire au fonctionnement de l'entreprise et des applications. 

• Principe de moindre privilège : suivre le principe de moindre privilège lors de la spécification des ports autorisés. N’ouvrir que les ports nécessaires aux services ou applications spécifiques. Adopter une approche Zero Trust.

• Règles basées sur les applications : créer des politiques basées sur l’identité des applications plutôt que les adresses IP. Cela simplifie la gestion des règles et les rend plus compréhensibles.

• Utilisation de groupes et balises : gérer les objets et les règles de firewall de manière plus efficace, ce qui simplifie la gestion et améliore la performance.

• Documentation : conserver une documentation détaillée des règles firewalls, y compris l’objectif de chaque règle et la justification de sécurité associée.

Chiffrement des flux

• Flux sensibles : les flux contenant des données sensibles (au sens CNIL : https://www.cnil.fr/fr/definition/donnee-sensible ) ou classifiées au niveau « Secret » doivent être chiffrés à partir du moment où ils entrent ou sortent du SI.

• Mots de passe : les flux contenant des mots de passe doivent être chiffrés, y compris sur le réseau interne.

• SSL/TLS : les protocoles TLSv1.2 et TLSv1.3 doivent être utilisés systématiquement pour chiffrer les communications HTTP, sauf si une problématique de compatibilité impose l’usage d’une version antérieure. Les protocoles SSLv2, SSLv3, TLSv1.0, TLSv1.1 sont interdits pour les communications HTTP.

• Protocoles faibles : l’usage de protocoles faibles (FTP, telnet, TFTP…) est interdit, puisque ne permettant pas le transfert sécurisé des mots de passe de connexion.

• Monitoring : si SNMP est utilisé, il est recommandé d’utiliser la version 3 : les communautés publiques et privées de SNMP ne doivent pas être utilisées.

Gestion des règles

• Segmentation du réseau : diviser le réseau en zones distinctes basées sur des niveaux de sécurité et de fonction (par exemple, DMZ, zone interne, zone de gestion).

• Micro-Segmentation : appliquer des politiques de sécurité granulaire au niveau des machines virtuelles (VM) individuelles pour isoler les charges de travail et limiter les mouvements latéraux des menaces.

• Principe du moindre privilège : appliquer le principe du moindre privilège en ne permettant que le trafic nécessaire. Chaque règle doit avoir une justification claire.

• Positionnement des règles : placer les règles les plus critiques plus haut afin de s’assurer qu’elles sont évaluées en premier, et veiller à revoir et à adapter régulièrement les règles pour répondre à l’évolution des besoins en matière de sécurité, ainsi qu’à supprimer les règles obsolètes pour rationaliser les performances.

• Contrôle du trafic entrant : indiquer les adresses IP sources ou les plages d’adresses IP à partir desquelles le trafic entrant est attendu. Cela ajoute une couche supplémentaire de sécurité en limitant les sources autorisées.

• Contrôle du trafic sortant : spécifier les adresses IP de destination ou les plages d’adresses pour le trafic sortant. Cela ajoute une couche supplémentaire de contrôle, empêchant l’envoi de données vers des destinations non autorisées. N’autoriser que des adresses IP sources légitimes à s'évader.

• Consolidation des règles : éviter la duplication des règles et les consolider autant que possible pour simplifier la gestion et réduire les risques d’erreurs et la latence de traitement.

• Optimisation des Règles : organiser les règles de firewall de manière hiérarchique et optimisée pour minimiser l'impact sur la performance. Exemple : les règles les plus “larges” et les plus sollicitées sont positionnées en tête de liste.

• Documentation et commentaires : documenter chaque règle de firewall avec des descriptions et des commentaires pour faciliter la compréhension et la gestion future.

• Scripts et API : utiliser les API pour automatiser les tâches répétitives et intégrer la gestion des firewalls dans les workflows DevOps/NetOps.

• Collaboration inter-fonctionnelle : favoriser la collaboration entre les équipes dans le processus de définition des règles. Les équipes disposent d’informations précieuses sur les besoins opérationnels, et les équipes chargées de la sécurité contribuent à l’évaluation des risques.

• Testez les règles dans un environnement contrôlé : avant de déployer de nouvelles règles dans un environnement de production, si possible les tester dans un environnement de recette. Cela permet d’identifier les conséquences imprévues et de garantir le maintien des services critiques.

Surveillance et Audit

• Journalisation : activer les logs sur les règles afin de faciliter la surveillance et l’analyse du trafic autorisé, et donc les analyses légales et la réponse aux incidents.

• Surveillance Continue : implémenter une surveillance continue du trafic réseau et des logs de firewall pour détecter les anomalies et les tentatives d'intrusion. Analyser régulièrement les schémas de trafic entrant afin d’identifier les anomalies ou les incidents de sécurité potentiels.

• Alertes : mettre en place des mécanismes d’alerte en cas d’activité sortante inhabituelle (exemple : transferts de données importants ou connexions à des adresses IP réputées comme malveillantes).

• Centralisation des Logs : centraliser les logs de firewall dans une solution SIEM (Security Information and Event Management) pour une analyse approfondie et une réponse rapide aux incidents.

• Audits Réguliers : effectuez des audits réguliers des configurations de firewall pour vérifier leur conformité avec les politiques de sécurité de l'entreprise et les standards réglementaires.

La gestion des firewalls cloud nécessite une approche bien structurée qui intègre la sécurité, la gestion, et la performance. En suivant ces bonnes pratiques, il est possible de créer un environnement sécurisé et efficace, capable de s’adapter aux besoins changeants de l’entreprise et aux menaces émergentes.

Ressources