Unité 3.2 : Sécurité réseau : pare-feu et groupes de sécurité

Introduction

La segmentation dans l'unité 3.1 a donné à FinCorp trois LAN : un bord public, un niveau d'application privé et un niveau de données privé uniquement. La topologie seule ne force pas qui peut parler à qui. La couche d'exécution est située sur les cartes réseau des serveurs, et c'est la prochaine décision dans la conception du réseau : un pare-feu par carte réseau et Network Security Groups sont tous deux liés aux interfaces réseau de machine virtuelle, et les deux refusent tout par défaut une fois activés.

Cette unité se termine par la construction de cette exécution dans le Data Center Designer pour l'environnement FinCorp : des règles de pare-feu qui n'autorisent que les flux inter-niveaux que l'architecture requiert, ainsi qu'un journal de flux écrit dans un seau Object Storage afin que l'équipe de sécurité puisse vérifier, a posteriori, exactement quels connexions ont été acceptées et lesquelles ont été rejetées. Avant la construction, deux choses doivent être claires : comment le pare-feu évalue le trafic, et où les constructions de pare-feu cessent de s'appliquer.

1. Mécanismes de pare-feu de la carte réseau et le contrat deny-by-default

Le pare-feu IONOS est une propriété d'une carte réseau individuelle, et non d'un sous-réseau, d'un LAN, ou du centre de données virtuel dans son ensemble. Une carte réseau sans pare-feu laisse passer tout le trafic. Dès que vous activez le pare-feu sur cette carte réseau, le contrat s'inverse : avec le pare-feu activé et sans règles définies, tout le trafic entrant est bloqué. Chaque connexion que vous souhaitez autoriser est alors une règle d'autorisation explicite. Il n'y a pas de règle "deny" séparée à écrire, et le principe du moindre privilège est atteint simplement en ne ajoutant pas de règle, ce qui reflète la posture de contrôle d'accès que vous avez vue dans la gouvernance.

Le pare-feu est étatique. Lorsqu'une règle autorise une connexion sortante, les paquets de retour correspondants sont autorisés automatiquement ; vous n'avez pas à écrire une règle miroir pour le trafic de réponse. Cela est important pour le niveau application de FinCorp : une règle qui permet aux serveurs d'application de rejoindre le point de terminaison PostgreSQL sur le niveau données autorise également les résultats de la requête à revenir, sans une deuxième règle d'entrée sur la carte réseau de l'application pour la réponse de la base de données.

Les règles peuvent être appliquées par direction. Lors de l'activation du pare-feu, vous choisissez Entrée, Sortie ou Bidirectionnel, et chaque règle elle-même porte une direction d'Entrée ou de Sortie. Une règle correspond au protocole et aux champs pertinents pour ce protocole. Les protocoles pris en charge sont TCP, UDP, ICMP, ICMPv6, VRRP, GRE, AH et ESP, ainsi qu'une option " Tout protocole ". Pour TCP et UDP, vous spécifiez les plages de ports ; pour ICMP et ICMPv6, vous spécifiez le type et le code (par exemple, le type 8 pour les requêtes d'écho). Une règle peut également restreindre l'adresse MAC source, l'adresse IP/CIDR source et l'adresse IP/CIDR de destination, où le champ de destination est utile lorsque une carte réseau transporte des adresses IP virtuelles.

Parce que la rédaction manuelle de règles pour les rôles courants est sujette aux erreurs, le DCD est livré avec des modèles de règles. Les modèles suivants sont disponibles et pré-remplissent un ensemble de règles typique :

Modèle	Ports d'entrée	Utilisation typique
Serveur Web générique	80 (HTTP), 443 (HTTPS)	HTTP/HTTPS d'entrée à partir de toutes les sources ; sortie vers les bases de données et les API externes
Serveur de messagerie	25 (SMTP), 143 (IMAP), 110 (POP3)	Règles de sortie pour l'envoi de courrier et la communication avec les serveurs de messagerie externes
Accès à distance Linux	22 (SSH)	SSH à partir de sources de confiance ; sortie pour les mises à jour et la gestion de packages
Accès à distance Windows	3389 (RDP)	RDP à partir d'IP spécifiés ; sortie pour les mises à jour

Un modèle est un point de départ, et non une politique terminée. Le modèle de serveur Web générique, par exemple, autorise HTTP et HTTPS à partir de toutes les sources, ce qui est approprié pour une carte réseau de bordure orientée vers Internet, mais incorrect pour un niveau privé. Les règles peuvent également être clonées à partir d'une autre carte réseau, ce qui permet de maintenir une flotte de serveurs identiques cohérents. Le chemin de données du pare-feu est évalué jusqu'à 6 Gbps de débit, ce qui est ample pour le filtrage d'un niveau à l'autre, mais c'est un nombre à garder à l'esprit pour les cartes réseau à très haut débit.

2. NSGs versus le pare-feu de la carte réseau, et la limite où aucun des deux ne s'applique

Le pare-feu par carte réseau est local : ses règles vivent sur une carte réseau et sont gérées là. Les Network Security Groups résolvent le problème de mise à l'échelle. Un NSG est un ensemble de règles nommé et réutilisable créé au niveau du centre de données virtuel, puis attaché aux serveurs ou aux cartes réseau, de sorte qu'une seule politique peut gouverner de nombreuses interfaces et que les modifications apportées au groupe sont propagées à chaque membre attaché. Les NSGs peuvent être gérés via les DCD, le Cloud API, le Go Cloud SDK, et les Terraform.

Chaque nouveau VM créé dans un centre de données virtuel est automatiquement ajouté au NSG par défaut, qui est livré avec quatre règles prédéfinies : autoriser toutes les sorties IPv4, autoriser toutes les sorties IPv6, autoriser les entrées IPv4 uniquement à partir de la plage 10.0.0.0/24 du centre de données virtuel, et autoriser les entrées IPv6 uniquement à partir de la plage /56 IPv6 CIDR allouée au centre de données. Cette configuration par défaut est permissive pour les sorties et les communications est-ouest par conception, de sorte qu'un locataire réglementé comme FinCorp remplace généralement celle-ci par des groupes personnalisés qui n'autorisent que les flux requis. Les NSGs personnalisés sont, par défaut, de type "refuser tout", comme le pare-feu de la carte réseau, de sorte que chaque flux autorisé est à nouveau une règle explicite.

Les NSGs sont à état, prennent en charge les règles d'entrée et de sortie, et acceptent l'ensemble de protocoles UDP, TCP, ICMP, ICMPv6, GRE, VRRP, ESP, AH, et TOUT. Les limites de capacité sont importantes à connaître au moment de la conception : jusqu'à 10 NSGs par carte réseau, jusqu'à 10 par VM, jusqu'à 100 règles par NSG, et jusqu'à 200 NSGs par centre de données virtuel. L'attachement est granulaire : vous pouvez attacher un groupe au niveau du VM, où il couvre toutes les cartes réseau de ce VM, ou au niveau de la carte réseau individuelle pour un contrôle plus précis. Lorsqu'un VM est membre d'un NSG, toutes les cartes réseau de ce VM héritent implicitement des règles.

Le tableau suivant compare les deux concepts pour guider où chacun appartient :

Dimension	Pare-feu de la carte réseau	Groupe de sécurité réseau
Où défini	Sur la carte réseau individuelle	Au niveau du centre de données virtuel, puis attaché
Réutilisation	Aucune ; par carte réseau, éventuellement clonée	Un groupe attaché à de nombreuses machines virtuelles/carte réseau
Comportement par défaut une fois actif	Bloque tout le trafic entrant	Refuser tout (personnalisé) ; NSG par défaut est permissif
À état	Oui	Oui
Meilleur pour	Exceptions ponctuelles ou par serveur	Politique cohérente pour un ensemble de machines ou un niveau

Un instinct de conception courant est de combiner les deux pour une défense en profondeur. Soyez délibéré ici : la matrice des faits indique que l'utilisation parallèle de NSGs et du pare-feu de la carte réseau n'est pas le modèle recommandé, choisissez donc un modèle d'application des règles par environnement plutôt que d'exécuter des ensembles de règles superposés difficiles à comprendre. Pour FinCorp, les NSGs sont mieux adaptés car la posture de sécurité est définie par niveau et réutilisée sur de nombreuses machines virtuelles identiques.

Il existe une limite explicite qui régit l'utilisation des REST du Module 3. Les NSGs et les pare-feu de la carte réseau sont liés aux interfaces réseau des VM uniquement. Ils NE s'appliquent PAS aux équilibreurs de charge gérés (les Managed Application Load Balancer et les Managed Network Load Balancer) et ils NE s'appliquent PAS à l'abstraction Managed Kubernetes Cluster. Concrètement, vous ne pouvez pas ajouter des nœuds de pool Managed Kubernetes Node (ou des Cubes suspendus) à un NSG. C'est pourquoi l'architecture en couches isole le niveau des données avec la topologie et place le filtrage sur les cibles derrière un équilibreur de charge plutôt que sur l'équilibreur de charge lui-même : le Managed ALB n'a pas de pare-feu dédié, et le Managed NLB ne contient que des règles de pare-feu de base et immuables générées automatiquement à partir de ses règles de transfert, de sorte que toutes les règles d'autorisation configurables par le client vivent sur les cartes réseau des machines virtuelles de backend ou sur leurs NSGs. Traitez ceci comme une entrée de conception, et non comme une lacune : le modèle natif est le filtrage du côté de la cible plus le placement privé par défaut.

Une mise en garde opérationnelle sur le contrôle d'accès : désactiver le privilège NSG pour un sous-utilisateur ne le verrouille pas complètement. Un utilisateur qui peut toujours accéder au centre de données pertinent peut continuer à gérer les NSGs existants ; le privilège contrôle la création et l'utilisation des NSGs, et non la gestion des groupes qui existent déjà. Planifiez la propriété du groupe et l'accès au centre de données ensemble.

DCD Marche à suivre pour la mise en œuvre

Vous appliquerez des règles de pare-feu de niveau à niveau aux serveurs d'application FinCorp, puis activerez un journal de flux sur une carte réseau (NIC) afin que l'équipe de sécurité puisse vérifier ce que le pare-feu accepte et rejette. Cela réalise la couche d'exécution sur la topologie à trois LAN de l'Unité 3.1. Prérequis : le centre de données virtuel (VDC) et ses cartes réseau (NIC) de l'Unité 3.1 doivent déjà exister, et un seau Object Storage appartenant à l'utilisateur doit exister avant que le journal de flux puisse le cibler (seuls les administrateurs de contrat et les propriétaires peuvent activer Object Storage, et le créateur de journal de flux a besoin du privilège Créer Flow Logs).

Objectif de construction : Appliquer des règles de pare-feu entre les niveaux ; activer un journal de flux vers un seau Object Storage.

Étapes (dans le Data Center Designer) :

Ouvrez le VDC, et dans l'espace de travail, sélectionnez un serveur de niveau d'application qui a une carte réseau (NIC) sur le réseau d'application privé LAN.
Dans le volet Inspector, ouvrez l'onglet Réseau, puis ouvrez les propriétés de la carte réseau que vous souhaitez protéger.
Activez le pare-feu sur cette carte réseau en choisissant le type de flux de trafic à appliquer : Entrant, Sortant ou Bidirectionnel. Une fois actif sans règles, la carte réseau bloque tout le trafic entrant, donc définissez des règles avant de vous fier à elle.
Cliquez sur Gérer les règles, puis sur Créer une règle de pare-feu, et choisissez le protocole pour la règle (TCP, UDP, ICMP, ICMPv6, VRRP, GRE, AH, ESP ou n'importe quel protocole). Pour le flux d'application vers la base de données, créez une règle TCP.
Remplissez les champs de la règle : un nom ; Direction (Sortant pour le serveur d'application qui atteint la base de données) ; Source IP/CIDR et Destination IP/CIDR limités aux plages privées ; et le port de destination pour la base de données. Laissez la version IP sur Auto, sauf si vous fixez une famille. Le pare-feu à état permet le trafic de retour automatiquement, donc aucune règle de réponse entrante n'est nécessaire.
Pour les serveurs basés sur des rôles, utilisez facultativement des règles à partir d'un modèle (Serveur Web générique, Serveur de messagerie, Accès à distance Linux, Accès à distance Windows) comme point de départ, puis resserrez les sources ; ou utilisez Clonez les règles à partir d'une autre carte réseau pour garder les serveurs identiques cohérents. Cliquez sur Enregistrer.
Pour activer un journal de flux sur la même carte réseau, ouvrez le menu déroulant du journal de flux des propriétés de la carte réseau (pour un NLB géré ou Managed NAT Gateway, vous utiliseriez à la place l'onglet Paramètres de l'élément) et entrez un nom. Ce nom devient la première partie du préfixe de nom d'objet dans le seau.
Définissez la Direction (Entrant, Sortant ou Bidirectionnel), l'Action (Rejeté pour capturer uniquement le trafic bloqué, Accepté pour capturer uniquement le trafic autorisé, ou N'importe quel) et le seau Object Storage cible : un nom de seau existant et valide appartenant à l'utilisateur, ainsi qu'un préfixe de nom d'objet facultatif. Choisissez Ajouter un journal de flux.
Une lumière verte sur les propriétés de la carte réseau confirme que la configuration est validée. Sélectionnez PROVISIONNER LES MODIFICATIONS. Après la fin de la mise en service, les règles de pare-feu et le journal de flux sont actifs, et les enregistrements de flux commencent à atterrir dans le seau sous forme de fichiers .log.gz compressés gzip.

Chaque enregistrement de flux est par flux, agrégé sur une période fixe de 10 minutes sans échantillonnage (tous les flux de la période sont enregistrés), et les intervalles sans trafic sont ignorés. Chaque enregistrement comporte des champs, notamment l'adresse et le port source et de destination, le numéro de protocole IANA, les comptes de paquets et d'octets, les horodatages de début et de fin, et un champ action d'ACCEPT ou REJECT. Le champ action est précisément le signal de vérification : définissez l'action du journal de flux sur Rejeté lorsque vous souhaitez voir uniquement ce que le pare-feu est en train de rejeter, ce qui est le moyen le plus rapide de trouver une règle d'autorisation manquante, ou Accepté pour confirmer que seuls les flux prévus passent.

Erreurs courantes :

Activer le pare-feu sur une carte réseau, puis s'en aller. Avec le pare-feu activé et sans règles, la carte réseau bloque tout le trafic entrant ; définissez les règles d'autorisation dans le même changement.
Écrire une règle de trafic de retour. Le pare-feu et les groupes de sécurité réseau (NSG) sont à état, donc une connexion sortante autorisée a des réponses autorisées automatiquement. Une règle entrante miroir est redondante et encombre la politique.
Exécuter des NSG et le pare-feu de la carte réseau en parallèle pour les mêmes cartes réseau. L'utilisation parallèle n'est pas le modèle recommandé ; choisissez un modèle d'exécution par environnement.
Laisser le groupe de sécurité réseau (NSG) par défaut en place pour un niveau réglementé. Il autorise tout le trafic sortant et est-ouest à l'intérieur du VDC ; remplacez-le par des groupes de déni personnalisés qui accordent uniquement les flux requis.
S'attendre à ce qu'un pare-feu ou un NSG protège un nœud Load Balancer ou Kubernetes géré. Aucune de ces constructions ne s'y rattache. Placez les règles d'autorisation sur les cartes réseau VM de backend et utilisez des politiques de réseau dans Cluster pour Kubernetes.
Pointer un journal de flux vers un seau qui n'existe pas encore, ou un seau qui n'est pas détenu par votre contrat. La destination doit être un seau Object Storage existant et appartenant à l'utilisateur ; créez-le d'abord.
Supposer que la suppression de la règle de journal de flux nettoie les données. La suppression de la règle arrête les nouveaux enregistrements, mais ne supprime pas les objets de journal existants du seau, ni ne modifie leurs politiques ou ACL.
Traiter Flow Logs comme un service de rétention géré. Il y a un journal de flux par ressource, le format d'enregistrement et la configuration sont immuables après la création, et la rétention est entièrement gérée par le client : définissez une politique de cycle de vie Object Storage sur le seau de destination (ou supprimez-le manuellement). Rien n'expire automatiquement, à moins que vous ne le configuriez.

Un court ionosctl après la mise en service confirme les règles de pare-feu attachées à la carte réseau, ce qui est utile dans un script d'audit :

ionosctl firewallrule list --datacenter-id "$DC_ID" \
  --server-id "$SRV_ID" --nic-id "$NIC_ID"

Le point architectural est que l'ensemble de règles est interrogable et donc auditable en tant que configuration ; la décision d'application réside toujours dans la conception ci-dessus, et non dans la commande.

Résumé

La topologie à trois niveaux de FinCorp devient une limite de sécurité uniquement lorsque l'application est appliquée aux cartes réseau des serveurs. Les pare-feu par carte réseau et les Network Security Groups liés aux interfaces VM sont à l'état d'origine, et refusent par défaut une fois actifs (à l'exception notable de la règle NSG par défaut permissive). Les NSG sont utiles lorsque une politique doit gouverner de nombreuses interfaces ; le pare-feu par carte réseau convient aux exceptions ponctuelles. De manière critique, aucune de ces constructions n'atteint les équilibreurs de charge gérés ou l'abstraction Managed Kubernetes Cluster, ce qui force le filtrage sur les cibles et renforce le placement privé par défaut. Les Flow Logs ferment la boucle : ils écrivent des enregistrements ACCEPT/REJECT immuables, par flux, sur un seau Object Storage appartenant au client, transformant "que fait réellement le pare-feu" d'une supposition en preuve.

Points clés :