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

Introduction

La segmentation présentée dans l'unité 3.1 a doté FinCorp de trois LAN : une frontière publique, un niveau d'application privé et un niveau de données strictement privé. La topologie seule ne suffit pas à imposer qui peut communiquer avec qui. La couche d'application des règles se situe sur les cartes réseau des serveurs, et constitue la prochaine décision dans la conception du réseau : un pare-feu par carte réseau et les Network Security Groups sont tous deux liés aux interfaces réseau des machines virtuelles, et tous deux refusent tout par défaut une fois activés.

Cette unité se termine par la mise en œuvre de cette couche d'application dans Data Center Designer pour l'environnement FinCorp : des règles de pare-feu autorisant uniquement les flux entre niveaux exigés par l'architecture, ainsi qu'un journal de flux écrit dans un bucket Object Storage afin que l'équipe de sécurité puisse vérifier, a posteriori, exactement quelles connexions ont été acceptées et lesquelles ont été rejetées. Avant la mise en œuvre, deux points doivent être clairs : la manière dont le pare-feu évalue le trafic, et les limites au-delà desquelles les constructions du pare-feu cessent de s'appliquer.

1. Mécanique du pare-feu des NIC et le contrat de refus par défaut

Le pare-feu IONOS CLOUD est une propriété d'une NIC de serveur individuelle, et non d'un sous-réseau, d'un LAN ou de l'ensemble du VDC. Une NIC sans pare-feu laisse passer tout le trafic. Dès l'instant où vous activez le pare-feu sur cette NIC, le contrat s'inverse : avec le pare-feu activé et aucune règle définie, tout le trafic entrant est bloqué. Chaque connexion que vous souhaitez autoriser devient alors une règle d'autorisation explicite. Il n'y a pas de règle de « refus » distincte à rédiger, et le principe du moindre privilège est atteint simplement en n'ajoutant pas de règle, ce qui reflète la posture de contrôle d'accès que vous avez observée dans le domaine de la gouvernance.

Le pare-feu est à état. Lorsqu'une règle autorise une connexion sortante, les paquets de retour correspondants sont automatiquement autorisés ; vous n'avez pas à rédiger une règle miroir pour le trafic de réponse. Cela est important pour la couche applicative de FinCorp : une règle autorisant les serveurs d'application à atteindre le point de terminaison PostgreSQL sur la couche de données autorise également le retour des résultats de requêtes, sans une seconde règle entrante sur la NIC 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 Ingress, Egress ou Bidirectionnel, et chaque règle porte elle-même une direction Ingress ou Egress. Une règle correspond à un 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 des plages de ports ; pour ICMP et ICMPv6, vous spécifiez le type et le code (par exemple, le type 8 pour les requêtes echo). Une règle peut également restreindre la MAC source, l'IP/CIDR source et l'IP/CIDR destination, où le champ destination est utile lorsqu'une NIC porte des adresses IP virtuelles.

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

Un modèle est un point de départ, et non une politique achevée. Le modèle Serveur Web générique, par exemple, autorise HTTP et HTTPS depuis toutes les sources, ce qui est approprié pour une NIC de bordure exposée à Internet, mais incorrect pour une couche privée. Les règles peuvent également être clonées depuis une autre NIC, ce qui maintient la cohérence d'un parc de serveurs identiques. Le chemin de données du pare-feu est évalué à un débit maximal de 6 Gbps selon la matrice des faits, ce qui est suffisant pour le filtrage inter-couches, mais c'est un chiffre à garder à l'esprit pour les NIC à très haut débit.

2. NSGs par rapport au pare-feu de la NIC, et la frontière où aucun des deux ne s'applique

Le pare-feu par NIC est local : ses règles résident sur une NIC unique et y sont gérées. 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 VDC puis attaché à des serveurs ou des NIC, de sorte qu'une seule politique peut régir de nombreuses interfaces et qu'une modification du groupe se propage à tous les membres attachés. Les NSG peuvent être gérés via le DCD, l'API Cloud, le SDK Go Cloud et Terraform.

Chaque VM nouvellement créée dans un VDC est automatiquement ajoutée 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 VDC, et autoriser les entrées IPv6 uniquement à partir du CIDR IPv6 /56 alloué au centre de données. Ce réglage par défaut est permissif pour les sorties et le trafic est-ouest par conception, de sorte qu'un locataire réglementé tel que FinCorp remplace généralement ce réglage par des groupes personnalisés qui n'accordent que les flux nécessaires. Les NSG personnalisés sont en mode « tout refuser » par défaut, comme le pare-feu de la NIC, de sorte que chaque flux autorisé est à nouveau une règle explicite.

Les NSG sont étatiques, prennent en charge à la fois les règles INGRESS et EGRESS, et acceptent l'ensemble de protocoles UDP, TCP, ICMP, ICMPv6, GRE, VRRP, ESP, AH et ANY. Les limites de capacité méritent d'être connues au moment de la conception : jusqu'à 10 NSG par NIC, jusqu'à 10 par VM, jusqu'à 100 règles par NSG, et jusqu'à 200 NSG par VDC. L'attachement est granulaire : vous pouvez attacher un groupe au niveau de la VM, où il couvre toutes les NIC de cette VM, ou au niveau de la NIC individuelle pour un contrôle plus strict. Lorsqu'une VM est membre d'un NSG, toutes les NIC de cette VM héritent implicitement des règles.

Le tableau suivant met en contraste les deux constructions pour guider l'endroit où chacune doit être utilisée :

Un instinct de conception courant consiste à superposer les deux pour une défense en profondeur. Soyez délibéré à cet égard : la matrice des faits indique que l'utilisation parallèle des NSG et du pare-feu de la NIC n'est pas le modèle recommandé, il convient donc de choisir un modèle d'application unique par environnement plutôt que d'exécuter des ensembles de règles qui se chevauchent et qui sont difficiles à analyser. Pour FinCorp, les NSG sont plus adaptés car la posture de sécurité est définie par couche et réutilisée sur de nombreux serveurs identiques.

Il existe une frontière explicite qui régit le reste du Module 3. Les NSG et les pare-feu de NIC se lient uniquement aux interfaces réseau des VM. Ils ne s'appliquent PAS aux équilibreurs de charge gérés (le Managed Application Load Balancer et le Managed Network Load Balancer) et ils ne s'appliquent PAS à l'abstraction de cluster Managed Kubernetes. Concrètement, vous ne pouvez pas ajouter des nœuds de pool de nœuds Managed Kubernetes (ou des Cubes suspendus) à un NSG. C'est pourquoi l'architecture en couches isole la couche de données par la topologie et place le filtrage sur les cibles derrière un équilibreur de charge plutôt que sur l'équilibreur lui-même : le Managed ALB n'a pas de pare-feu dédié propre à lui, et le Managed NLB ne porte que des règles de pare-feu de base, 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 résident sur les NIC des VM d'arrière-plan ou sur leurs NSG. Considérez cela comme une entrée de conception, et non comme une lacune : le modèle natif est le filtrage côté cible associé à un placement privé par défaut.

Une mise en garde opérationnelle concernant 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 encore accéder au centre de données pertinent peut continuer à gérer les NSG existants ; le privilège régit la création et l'utilisation des NSG, et non la gestion des groupes qui existent déjà. Planifiez la propriété des groupes et l'accès au centre de données ensemble.

Déroulement de la mise en œuvre de DCD

Vous appliquerez des règles de pare-feu entre les niveaux aux serveurs d'application de FinCorp, puis vous 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 met en œuvre la couche d'application sur la topologie à trois LAN de l'Unité 3.1. Prérequis : le VDC et ses cartes réseau de serveurs 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 du journal de flux doit disposer du privilège Create 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 Data Center Designer) :

1. Ouvrez le VDC, puis, dans l'Espace de travail, sélectionnez un serveur du niveau d'application qui possède une carte réseau sur le LAN d'application privé.
2. Dans le volet Inspecteur, ouvrez l'onglet Réseau, puis ouvrez les propriétés de la carte réseau que vous souhaitez protéger.
3. Activez le pare-feu sur cette carte réseau en choisissant le type de flux de trafic à appliquer : Ingress, Egress ou Bidirectionnel. Une fois actif et sans règles, la carte réseau bloque tout le trafic entrant ; définissez donc des règles avant de vous y fier.
4. Cliquez sur Manage Rules, puis sur Create Firewall Rule, et choisissez le protocole pour la règle (TCP, UDP, ICMP, ICMPv6, VRRP, GRE, AH, ESP ou Any Protocol). Pour le flux de l'application vers la base de données, créez une règle TCP.
5. Remplissez les champs de la règle : un Nom ; la Direction (Egress pour le serveur d'application accédant à la base de données) ; l'IP/CIDR source et l'IP/CIDR destination limitées aux plages privées ; et le port de destination pour la base de données. Laissez IP Version sur Auto, sauf si vous fixez une famille. Le pare-feu avec état autorise automatiquement le trafic de retour, donc aucune règle de réponse entrante n'est nécessaire.
6. Pour les serveurs basés sur des rôles, utilisez éventuellement Rules from Template (Generic Webserver, Mailserver, Remote Access Linux, Remote Access Windows) comme point de départ, puis restreignez les sources ; ou utilisez Clone Rules depuis une autre carte réseau pour maintenir la cohérence entre les serveurs identiques. Cliquez sur Save.
7. Pour activer un journal de flux sur la même carte réseau, ouvrez la liste déroulante Flow Log des propriétés de la carte réseau (pour un Managed NLB ou un Managed NAT Gateway, vous utiliseriez à la place l'onglet Settings de l'élément) et saisissez un Nom. Ce nom devient la première partie du préfixe de nom d'objet dans le seau.
8. Définissez la Direction (Ingress, Egress ou Bidirectionnel), l'Action (Rejected pour capturer uniquement le trafic bloqué, Accepted pour capturer uniquement le trafic autorisé, ou Any), 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 Add flow log.
9. Un voyant vert sur les propriétés de la carte réseau confirme que la configuration a été validée. Sélectionnez PROVISION CHANGES. Une fois le provisionnement terminé, les règles de pare-feu et le journal de flux sont actifs, et les enregistrements par flux commencent à arriver dans le seau sous forme de fichiers .log.gz compressés en gzip.

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

Erreurs courantes :

• Activer le pare-feu sur une carte réseau puis s'éloigner. 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 la même modification.
• Écrire une règle de trafic de retour. Le pare-feu et les NSG sont avec état, donc les réponses d'une connexion sortante autorisée sont autorisées automatiquement. Une règle entrante miroir est redondante et encombre la politique.
• Exécuter les 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'application par environnement.
• Laisser le NSG par défaut en place pour un niveau réglementé. Il autorise tout le trafic sortant et est-ouest au sein du VDC ; remplacez-le par des groupes de refus par défaut personnalisés qui n'accordent que les flux nécessaires.
• S'attendre à ce qu'un pare-feu ou un NSG protège un équilibreur de charge géré ou des nœuds Kubernetes. Aucune de ces constructions ne s'y lie. Placez les règles d'autorisation sur les cartes réseau des VM backend et utilisez des politiques réseau intra-cluster pour Kubernetes.
• Pointeur un journal de flux vers un seau qui n'existe pas encore, ou qui n'appartient pas à votre contrat. La destination doit être un seau Object Storage existant 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.
• Considérer les journaux de flux comme un service de rétention géré. Il y a un journal de flux par ressource, le format des enregistrements 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 manuellement). Rien n'expire automatiquement, sauf si vous le configurez.

Une vérification ionosctl brève après le provisionnement 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"

L'aspect architectural est que l'ensemble de règles est interrogeable et donc auditable en tant que configuration ; la décision d'application reste dans la conception décrite ci-dessus, et non dans la commande.

Résumé

La topologie à trois niveaux de FinCorp ne constitue une frontière de sécurité que lorsque l'application des contrôles est effectuée au niveau des cartes réseau des serveurs. À la fois le pare-feu par carte réseau et les Network Security Groups sont liés aux interfaces des VM, sont état, et refusent par défaut une fois activés (avec l'exception notable du Default NSG permissif). Les NSG sont privilégiés lorsqu'une seule politique doit régir de nombreuses interfaces ; le pare-feu par carte réseau convient aux exceptions ponctuelles. Il est essentiel de noter que ni l'une ni l'autre de ces constructions ne s'étend aux équilibreurs de charge gérés ni à l'abstraction de cluster Managed Kubernetes, ce qui impose le filtrage sur les cibles et renforce le placement privé par défaut. Les journaux de flux ferment la boucle : ils écrivent des enregistrements immuables ACCEPT/REJECT par flux dans un bucket Object Storage appartenant au client, transformant la question « que fait réellement le pare-feu » d'une supposition en une preuve.

Points clés :

• Le pare-feu par carte réseau et les NSG personnalisés sont en mode refus par défaut une fois activés ; chaque flux autorisé est une règle explicite, et le principe du moindre privilège est atteint en n'accordant rien par défaut.
• Les deux sont état, de sorte que le trafic de retour pour une connexion autorisée est automatiquement permis ; ne rédigez pas de règles miroir.
• Les NSG sont des politiques réutilisables au niveau du VDC (jusqu'à 10 par carte réseau/VM, 100 règles chacune, 200 par VDC) ; le pare-feu par carte réseau est local. L'utilisation parallèle des deux n'est pas recommandée.
• Les NSG et les pare-feux par carte réseau ne s'appliquent pas aux équilibreurs de charge gérés ni aux nœuds des pools de nœuds Managed Kubernetes ; le filtrage est transféré vers les cibles et vers les politiques réseau intra-cluster.
• Les journaux de flux publient des enregistrements par flux (agrégation de 10 minutes, sans échantillonnage) avec un champ d'action ACCEPT/REJECT dans un bucket Object Storage appartenant à l'utilisateur ; il y a un journal de flux par ressource, le format est immuable, et la rétention est gérée par le client via une politique de cycle de vie.