Segmentation réseau sur site et dans le cloud : VLANs, pare-feux, groupes de sécurité et bonnes pratiques

La segmentation réseau est l’une des mesures les plus efficaces pour réduire la surface d’attaque, limiter la propagation d’incidents et séparer proprement les opérations. Le terme Netzwerksegmentierung désigne la création réfléchie de zones logiques ou physiques dans le réseau, où les équipements, services et utilisateurs ne peuvent communiquer qu’avec un contrôle. Dans les entreprises, cela recouvre typiquement une combinaison de VLANs (Virtual LANs), de zones Router/Layer‑3, de firewalls ainsi que de mécanismes spécifiques au cloud comme les Security Groups ou les Network ACLs. Cet article explique de manière pragmatique comment concevoir, déployer, tester et exploiter en toute sécurité la segmentation on‑prem et dans le cloud.

Grundbegriffe kurz und prägnant

Avant de passer à la configuration et au déploiement, voici une brève mise en correspondance des principaux termes :

• VLAN (Virtual Local Area Network) : séparation logique sur Layer‑2 (datalink). Les VLANs isolent les domaines de broadcast sur les ports de switch et nécessitent du routage (Layer‑3) pour la communication inter‑VLAN.
• Firewall : équipement ou logiciel qui autorise ou refuse le trafic selon des règles. Peut être stateful (orienté connexion) ou stateless.
• Security Group : concept cloud (p. ex. AWS/Azure) pour regrouper des règles ; généralement stateful et attaché aux instances.
• Network ACL : jeu de règles cloud ou on‑prem, qui fonctionne le plus souvent en stateless et s’applique au niveau du subnet/réseau.
• Mikrosegmentierung : contrôle fin des connexions jusqu’au niveau des processus ou de l’hôte (p. ex. via pare‑feu hôte, iptables/nftables ou politiques eBPF).

Netzwerksegmentierung: Grundprinzipien und Ziele

Une bonne segmentation suit des objectifs opérationnels clairs : limiter la propagation des attaques, isoler les données sensibles, améliorer la répartition de la charge réseau et séparer les responsabilités opérationnelles. Les principes sont :

• Principe du moindre privilège : n’autoriser que les connexions strictement nécessaires.
• Trust zoning : structurer les zones réseau selon le niveau de confiance (p. ex. DMZ, App‑Tier, DB‑Tier).
• Journalisation et monitoring : toutes les frontières de zones doivent être consignées de manière traçable.
• Automatisation : politiques en tant que code (IaC), pipelines de revue et tests automatisés préviennent le drift et les erreurs de configuration.

On‑Prem: VLANs praktisch gestalten und betreiben

Les VLANs sont la méthode classique pour la segmentation on‑prem. Un VLAN regroupe des ports et constitue une propre domaine de broadcast ; le routage entre VLANs s’effectue via un routeur ou un commutateur L3 (Inter‑VLAN‑Routing).

Voraussetzungen und Planung

Prérequis importants : switches trunk‑capables (IEEE 802.1Q) pour la transmission des VLANs, un plan d’adressage IP cohérent, des IDs VLAN et des conventions de nommage documentés, ainsi qu’une politique de routage au niveau du L3‑gateway. Sans un plan IP propre, on rencontre rapidement des chevauchements d’adresses, des passerelles mal positionnées ou des tempêtes de broadcast.

Beispiel: VLAN an einem Switch anlegen (Cisco IOS)

Configuration d’un port trunk et d’un port access :

configure terminal
vlan 10
 name VLAN-APP
interface GigabitEthernet1/0/1
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
interface GigabitEthernet1/0/2
 switchport mode access
 switchport access vlan 10
end
write memory

Pourquoi cela fonctionne : le trunk transporte plusieurs VLANs entre les switches ; les ports access appartiennent exactement à un VLAN. Quand cela échoue : configuration de trunk manquante sur le contre‑poste, native VLANs différents ou problèmes de MTU (à prendre en compte pour la voix/tagging VLAN).

Linux‑Hôte en tant que routeur / interface VLAN

Pour les petits sites ou environnements de test, une passerelle Linux peut traiter directement les interfaces VLAN :

ip link add link eth0 name eth0.10 type vlan id 10
ip addr add 192.168.10.1/24 dev eth0.10
ip link set eth0.10 up
sysctl -w net.ipv4.ip_forward=1

Risque : limites de performance et absence de support de l’offload matériel sur des hôtes commodity. Pour des charges en production, privilégiez des commutateurs L3 ou des routeurs/pare‑feu dédiés.

Concepts cloud : Security Groups, NACLs et routage

Dans les clouds publics comme AWS, Azure ou Google Cloud, on trouve d’autres primitives. Les Security Groups (SG) sont des règles typiques, rattachées aux instances, généralement stateful. Les Network ACLs (NACL) opèrent au niveau des sous‑réseaux et sont souvent stateless, c.-à-d. qu’elles nécessitent des règles séparées pour l’entrée et la sortie.

Stateful vs. stateless — explication brève

Stateful signifie que le pare‑feu garde la trace des connexions (p. ex. une connexion TCP autorisée permet ensuite le trafic de retour). Stateless traite chaque direction indépendamment et nécessite donc une gestion plus détaillée. Dans AWS, les SG sont stateful ; les NACL sont stateless. Dans Azure, les NSG (Network Security Groups) sont stateful.

Exemple : création d’une Security Group (AWS CLI)

aws ec2 create-security-group --group-name zammad-app-sg --description "Zammad App SG" --vpc-id vpc-123abc
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 443 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 5432 --source-group sg-0dbonly

La dernière règle illustre un schéma important : autoriser le port DB (5432) uniquement depuis l’Application‑SG. Ainsi, vous empêchez les accès directs depuis Internet vers les bases de données.

Déploiement stratégique des pare‑feu : zones, règles, journalisation

La segmentation est la plus efficace avec des zones clairement définies : périmètre/DMZ, couche applicative, couche base de données, management. Les pare‑feu appliquent la politique aux points de transition entre zones. Points importants :

• Règles basées sur le besoin fonctionnel, pas sur l’IP : regroupez des services, pas des hôtes individuels.
• Default‑Deny : politique de périmètre par défaut restrictive, ne permettre que les flux explicitement autorisés.
• Restriction de protocoles et de ports : n’ouvrir que les protocoles nécessaires (p. ex. HTTPS au lieu de HTTP, proxys applicatifs, mTLS).
• Journalisation et rétention : centraliser les logs de pare‑feu (SIEM) pour détecter les anomalies.

Exemple : chaîne input minimale nftables (pare‑feu hôte)

nft add table inet filter
nft 'add chain inet filter input { type filter hook input priority 0 ; }'
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input iifname "lo" accept
nft add rule inet filter input tcp dport 443 accept
nft add rule inet filter input tcp dport 22 ct state new limit rate 10/second accept
nft add rule inet filter input drop

Pourquoi cela fonctionne : stratégie simple de type Default‑Deny autorisant les connexions établies et les services nécessaires. Quand cela échoue : absence de règles de journalisation, laisser la console (SSH) trop ouverte ou placer les règles dans le mauvais ordre.

Bonnes pratiques : conception, automatisation et exploitation

Directives concrètes qui font régulièrement la différence dans les projets :

1. Tagging et conventions de nommage: Utilisez des tags cohérents dans le cloud (p. ex. environment, role, owner) et une structure de nommage VLAN on‑prem (p. ex. VLAN-APP-10).
2. Policy as Code: gérer les pare‑feu et les Security Groups via IaC (Terraform, ARM, CloudFormation), y compris revue de code et tests.
3. Change‑Control: Jede Policyänderung durchläuft automatisierte Tests (Connectivity‑Smoke, Regression) und eine Rollback‑Option.
4. Least‑Privilege und explizite Regeln: Keine offenen 0.0.0.0/0‑Regeln außer wenn wirklich nötig.
5. Monitoring & Alerts: Signaler les anomalies telles que des pics soudains du East‑West‑Traffic ou des scans de ports inhabituels.
6. Dokumentation: Maintenir à jour le plan d’adressage IP, la carte VLAN, la matrice de pare‑feu (Qui peut atteindre qui ?).

Plan de migration et de déploiement : étape par étape

Lors de la migration de réseaux plats vers des architectures segmentées, il est recommandé d’avoir un chemin de rollback garanti. Une séquence exemplaire :

1. Analyse : collecter les flux actuels avec NetFlow/sFlow, tcpdump et les dépendances de services.
2. Conception : établir une carte des zones et des services, documenter les ports et les endpoints.
3. Déploiement automatisé : générer les templates IaC, dry‑run, revue et déploiement en staging.
4. Canary : appliquer la segmentation sur un petit sous‑ensemble et observer.
5. Déploiement en production : cutover par phases avec monitoring et rollback d’urgence.

Commandes de test importantes

Utilisez ces commandes de manière systématique pour vérifier la connectivité et les règles :

# Verbindungstest TCP (Netcat)
nc -vz 192.168.10.5 5432

# Paketmitschnitt (z. B. DB‑Traffic)
tcpdump -i eth0 -n 'host 192.168.10.5 and port 5432'

# Firewall‑Rules anzeigen
nft list ruleset

# Route/Next‑Hop prüfen
ip route show

# Traceroute für Pfaddiagnose
traceroute -n 10.0.0.5

# HTTP‑Check
curl -v --connect-timeout 5 https://app.example.local/health

Supervision, Logging und Détection de dérive

La segmentation n’est efficace que si elle est surveillée. Exigences centrales :

• Flow‑Logging : activez NetFlow/sFlow sur les commutateurs et les VPC Flow Logs dans le cloud pour analyser le East‑West‑Traffic.
• Firewall Logs : orienter des logs structurés (JSON) vers un SIEM pour permettre des corrélations.
• Drift Detection : comparez en continu les configurations actuelles avec l’état IaC (p. ex. terraform plan dans le CI). Des outils cloud comme AWS Config ou Azure Policy peuvent signaler les changements non gérés.

Exemple : activer les VPC Flow Logs et une requête CloudWatch Logs Insights simple pour des adresses IP source inhabituelles :

# VPC Flow Logs (Kurzbefehls-Beispiel - CLI)
aws ec2 create-flow-logs --resource-type VPC --resource-ids vpc-123abc --traffic-type ALL --log-group-name /aws/vpc/flowlogs --deliver-logs-permission-arn arn:aws:iam::123456:role/flowlogs-role

# CloudWatch Logs Insights Beispielabfrage
fields @timestamp, srcAddr, dstAddr, action | filter action = 'REJECT' | stats count() by srcAddr | sort @timestamp desc

Performance, MTU und Latenz beachten

La segmentation peut avoir des effets secondaires sur la latence et le MTU. Les trames taggées augmentent la taille des paquets ; dans les VPN ou réseaux overlay (p. ex. VXLAN), les en‑têtes s’additionnent. Vérifiez les paramètres MTU le long du chemin et mesurez la latence/le débit avant et après les modifications.

Outils de mesure et commandes d’exemple :

# MTU prüfen
ip link show dev eth0

# Latenz und Durchsatz messen (iperf3)
iperf3 -c 10.0.0.5 -p 5201 --parallel 4 --time 30

Microsegmentierung, Host‑Firewall und eBPF

Si les Layer‑2/3 ne suffisent pas ou qu’un fonctionnement multi‑locataire est requis, la micro‑segmentation aide : basée sur l’hôte via nftables/iptables, basée sur des agents (p. ex. agents spécifiques à un domaine) ou approches modernes avec eBPF, qui apporte des filtres de paquets haute performance dans le noyau. Avantage : contrôle très fin ; inconvénient : complexité et charge opérationnelle accrues.

Compléments opérationnels et de dépannage spécifiques à Zammad

Pour les installations Zammad, concrétisez votre segmentation sur la base des points suivants :

• Liste des ports minimaux : Web (80/443), Postgres (5432), Elasticsearch (9200), Redis (6379).
• Sécurisation des chemins d’administration : SSH/gestion uniquement dans la zone de management, 2FA pour les comptes d’administration web et restrictions d’IP pour les panneaux d’administration.
• Health‑Checks et playbooks : des endpoints de santé simples vérifient le Web, les connexions à la base de données et la santé des index d’Elasticsearch.

Séquence de dépannage en cas de problèmes d’atteignabilité :

1. Vérifier les firewalls / groupes de sécurité (journaux pour ACCEPT/REJECT).
2. Tester le chemin réseau (traceroute, tcpdump sur l’hôte applicatif).
3. Vérifier les logs applicatifs (Zammad Rails Logs, Postgres Logs, Elasticsearch Logs).
4. Rollback vers la version antérieure du groupe de sécurité / firewall si la connectivité est démontrablement causée par la politique.

Exemple: Terraform‑Snippet für Security Group (Cloud‑Policy as Code)

resource "aws_security_group" "zammad_app" {
  name        = "zammad_app_sg"
  description = "App SG für Zammad"
  vpc_id      = var.vpc_id

  ingress {
    description = "Web"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description     = "DB Access aus App SG"
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.zammad_db.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "zammad_app_sg"
  }
}

Important : mettez en place la gestion des versions, des contrôles CI (terraform plan) et des approbations automatisées afin de garantir des déploiements sans dérive.

Runbook opérationnel et stratégie de repli

Un runbook précis réduit le stress lors d’un incident. Points clés :

• Commandes de test rapide (connectivité, logs, health‑checks).
• IDs des snapshots / backups et horodatage documentés.
• Commande de rollback ou playbook de revert IaC, incluant les interlocuteurs et la chaîne d’escalade.
• Plan de communication : mises à jour de statut aux équipes concernées et fenêtres de maintenance.

Checklist avant la mise en production

• Plan IP et cartographie VLAN finalisés et partagés dans l’équipe.
• Templates IaC créés, revue effectuée, tests automatisés réussis.
• Backup / snapshot créé avant le rollout.
• Monitoring (flows, logs de firewall) activé et seuils d’alerte définis.
• Playbook de rollback documenté et testé.
• Documentation des règles et des responsabilités disponible.

Conclusion

La segmentation réseau est un projet continu, et non une opération ponctuelle. La meilleure approche combine des principes de conception solides (principe du moindre privilège, zonage de confiance), l’automatisation (Policy as Code) et une procédure claire de test et de rollback. Les VLANs sur site (on‑prem) et les Cloud Security Groups se complètent souvent et doivent, en pratique, être considérés comme un ensemble de politiques cohérent. Pour des solutions numériques d’entreprise proches des processus comme Zammad, une segmentation soignée porte ses fruits : surface d’attaque réduite, responsabilités nettes et rollouts reproductibles. Commencez petit (Canary), mesurez les flux et automatisez la distribution des politiques — ainsi les projets de segmentation deviennent maîtrisables et durables.