Chiffrer les flux est-ouest dans un data center

Le trafic est-ouest traverse des commutateurs, des hyperviseurs, des équipements de stockage et parfois des frontières de tenant avant d’atteindre son destinataire. Le considérer comme fiable parce qu’il ne sort pas du bâtiment revient à confondre localisation physique et contrôle de sécurité, une confusion qui vieillit moins bien qu’un pare-feu périmétrique de 2008.

→ Lire l’explication complète de la marmotte

La confiance implicite du réseau physique est morte

Le data center historique reposait sur une hypothèse commode : l’accès au réseau physique était réservé aux administrateurs et aux serveurs légitimes. Cette hypothèse justifiait le chiffrement au périmètre, typiquement entre le navigateur et le frontal HTTPS, puis le retour au HTTP ou au protocole natif sur le réseau interne. Le câble était supposé être une frontière. Un câble n’est pas une frontière, c’est un support de transport avec une excellente réputation marketing.

Cette confiance ne tient plus dès qu’un même plan de commutation transporte plusieurs zones de sécurité. Virtualisation, conteneurs, réseau défini par logiciel, interconnexion de baies, liens de réplication, administration hors bande et fournisseurs d’infrastructure multiplient les points où un flux peut être observé ou injecté. Une compromission d’hyperviseur, d’agent réseau, de compte d’administration ou de port de commutateur suffit à sortir du modèle.

Le risque n’est pas limité à l’écoute passive. Un attaquant placé sur le chemin peut rejouer une session non protégée, altérer une réponse DNS (Domain Name System), détourner une résolution ARP (Address Resolution Protocol), empoisonner un cache ou injecter des trames. Une segmentation par VLAN (Virtual Local Area Network) réduit le rayon d’action, mais ne fournit ni confidentialité ni intégrité. Elle sépare des domaines de diffusion, pas des adversaires déterminés.

Le chiffrement est-ouest vise donc trois garanties :

confidentialité du contenu transporté ;
intégrité des paquets ou des messages ;
authentification du pair réseau ou applicatif.

Il ne garantit pas qu’un service compromis traite correctement une requête déchiffrée. Il ne rend pas non plus invisibles les métadonnées nécessaires au routage : adresses, volumes, horaires et parfois ports restent observables selon la couche choisie. Pour traiter l’autorisation applicative, les identités et les politiques d’accès, il faut compléter avec l’architecture des identités et une segmentation explicite.

MACsec, IPsec et TLS : choisir la couche qui porte le risque

Le compromis central est brutal : chiffrer bas dans la pile protège largement et sans modifier les applications, mais réduit la visibilité opérationnelle et complique la gestion des clés. Chiffrer haut conserve des politiques fines par service, mais impose que chaque application, bibliothèque et intermédiaire fasse son travail. Le choix ne dépend pas d’un concours de sigles, il dépend du point où l’on veut arrêter un attaquant.

MACsec (Media Access Control Security) protège les trames Ethernet entre deux équipements directement connectés. C’est le bon choix pour les liens physiques entre serveurs, commutateurs de feuille, équipements de stockage ou frontières de tenant lorsque le matériel le prend en charge. MACsec chiffre après la décision Ethernet : les adresses MAC restent utilisables, le contenu de la trame est protégé, et l’attaque par écoute sur le lien devient stérile.

MACsec n’est toutefois pas un tunnel de bout en bout à travers un fabric. À chaque saut, la trame est déchiffrée puis rechiffrée. Un commutateur intermédiaire compromis voit donc le trafic en clair. Cette propriété est acceptable pour protéger les liens et les zones physiques distinctes, pas pour traiter un domaine d’administration réseau comme implicitement digne de confiance.

IPsec (Internet Protocol Security) protège des paquets IP (Internet Protocol), généralement entre hôtes, passerelles ou routeurs. En mode tunnel, il encapsule un paquet entier dans un nouveau paquet chiffré. En mode transport, il protège la charge utile IP tout en conservant l’en-tête de routage. IPsec est le choix de référence pour joindre des réseaux routés, protéger une interconnexion entre baies ou isoler des locataires quand l’infrastructure sous-jacente ne peut pas garantir MACsec de bout en bout.

La négociation repose habituellement sur IKEv2 (Internet Key Exchange version 2). Elle doit authentifier les pairs par certificats ou clés asymétriques, renouveler les associations de sécurité et limiter la durée de vie des clés de trafic. Une clé prépartagée unique pour tout le fabric est une dette de sécurité, pas une configuration de départ. Elle transforme toute fuite locale en capacité d’usurpation globale.

TLS (Transport Layer Security) protège une session de transport entre deux processus. Il reste indispensable lorsque la menace inclut l’hôte intermédiaire ou lorsque l’identité du service doit être vérifiée dans le protocole applicatif. Mais cette page ne remplace pas le travail décrit dans TLS, HTTPS et authentification mutuelle. Chiffrer le réseau avec IPsec ne dispense pas d’authentifier une API sensible : une machine autorisée à joindre le sous-réseau n’est pas automatiquement autorisée à appeler l’API.

La recommandation est nette :

imposer MACsec sur les liens physiques et les frontières de domaine lorsque les équipements le supportent matériellement ;
utiliser IPsec avec IKEv2 et certificats pour les segments routés, les interconnexions et les réseaux partagés ;
conserver TLS au niveau applicatif pour les services à forte sensibilité, les appels traversant plusieurs domaines d’administration et les protocoles exposant des secrets métier.

Cette combinaison coûte du matériel compatible, des cycles processeur, une PKI (Public Key Infrastructure) exploitable et une discipline d’exploitation. Elle coûte moins qu’une architecture où un port miroir oublié devient une station d’écoute à durée indéterminée.

Exemple MACsec entre deux hôtes Linux

L’exemple suivant configure un lien MACsec avec iproute2 sur une interface ens192. Il démontre le mécanisme, pas une politique de production : les clés statiques affichées ici doivent être remplacées par une distribution automatisée ou par MKA (MACsec Key Agreement), le protocole de négociation prévu à cet effet.

# Sur les deux hôtes : créer l'interface MACsec liée au lien Ethernet.
# La clé de 128 bits est volontairement identique dans cet exemple de laboratoire.
sudo ip link add link ens192 macsec0 type macsec \
  encrypt on protect on send_sci on \
  cipher gcm-aes-128 \
  port 1

# Ajouter une association de sécurité sortante.
sudo ip macsec add macsec0 tx sa 0 pn 1 on \
  key 01 00112233445566778899aabbccddeeff

# Déclarer le pair distant et sa clé de réception.
# Remplacer 02:00:00:00:00:02 par la SCI du pair réel.
sudo ip macsec add macsec0 rx port 2 address 02:00:00:00:00:02
sudo ip macsec add macsec0 rx port 2 address 02:00:00:00:00:02 sa 0 pn 1 on \
  key 01 00112233445566778899aabbccddeeff

# Activer l'interface puis vérifier les compteurs MACsec.
sudo ip link set macsec0 up
ip -s macsec show

Le numéro de paquet, ou PN (Packet Number), interdit la réutilisation silencieuse d’une trame protégée. Il doit progresser sans retour arrière. Restaurer une machine ou une configuration avec un compteur réinitialisé peut provoquer une collision de nonce avec AES-GCM (Advanced Encryption Standard, Galois/Counter Mode), ce qui affaiblit gravement la confidentialité et l’intégrité. Le chiffrement adore les compteurs persistants, beaucoup moins les restaurations faites au marteau.

Sur un équipement de production, vérifier le support matériel de MACsec, la capacité de chiffrement à débit nominal, les compteurs d’erreurs et le comportement lors d’une bascule de lien. Une implémentation logicielle peut plafonner bien avant la capacité annoncée de l’interface, particulièrement avec des petits paquets.

Surface d’attaque et limites du chiffrement est-ouest

Le chiffrement de lien bloque l’écoute et l’injection sur le segment protégé, mais laisse l’attaquant agir depuis un endpoint légitime compromis. Un serveur infecté possède les clés de session nécessaires à ses propres communications. Aucun protocole de transport ne peut distinguer une requête malveillante émise par un processus autorisé d’une requête normale sans contrôle d’identité et d’autorisation au-dessus.

Les attaques suivantes restent à traiter :

Compromission de clés : voler une clé IPsec ou MACsec permet d’usurper un pair jusqu’à expiration ou révocation effective. Limiter les droits d’accès aux clés, isoler les comptes de service et protéger les clés de certification dans un HSM (Hardware Security Module) quand le niveau de menace le justifie.
Déni de service : négociations IKEv2, renouvellements simultanés et chiffrement logiciel consomment CPU et tables d’état. Filtrer les pairs autorisés, borner les tentatives et échelonner les renouvellements.
Dégradation silencieuse : certains équipements reviennent au trafic non chiffré après une erreur de négociation si le mode permissif est activé. Interdire le fallback. Un lien qui ne chiffre plus doit être indisponible, pas vaguement discret.
Inspection aveugle : un capteur réseau placé après chiffrement ne voit plus la charge utile. Déplacer la détection vers les endpoints, exporter les journaux applicatifs et instrumenter les points de terminaison avant chiffrement.
Mauvaise segmentation : IPsec entre deux passerelles protège le transport, mais peut relier deux réseaux beaucoup trop largement. Définir des sélecteurs de trafic minimaux et des règles de filtrage indépendantes.

La topologie doit aussi traiter les flux souvent oubliés : sauvegardes, réplication de bases, stockage bloc, hyperviseurs, orchestration, métrologie et administration. Les données les plus sensibles passent volontiers par le flux qualifié de « temporaire », juste avant de devenir une exception permanente. La page réseaux aide à replacer ces flux dans une segmentation cohérente.

Clés, rotation, supervision et reprise

MACsec et IPsec ne deviennent exploitables qu’avec une gestion de clés industrialisée. Pour IPsec, préférer des certificats à durée limitée, émis par une autorité dédiée aux équipements ou aux workloads. La clé privée doit être non exportable lorsque la plateforme le permet, ou chiffrée au repos par une KEK (Key Encryption Key) gérée hors de l’hôte. Une clé de trafic ne doit jamais être sauvegardée comme un secret applicatif ordinaire.

La rotation doit être testée sous charge. IKEv2 renouvelle les associations de sécurité avant expiration, mais une divergence d’horloge, une liste de certificats révoqués inaccessible ou une autorité de certification indisponible peut empêcher l’établissement d’une nouvelle session. Les sessions déjà établies ne sont pas automatiquement coupées par la révocation d’un certificat. La révocation prépare le prochain établissement ou renouvellement ; elle ne remonte pas le temps, même avec un tableau de bord très coloré.

Superviser au minimum :

l’état des associations IPsec et des sessions MACsec ;
les expirations de certificats et les erreurs de validation ;
les compteurs de paquets rejetés, rejoués ou non protégés ;
la charge CPU liée au chiffrement ;
les changements de configuration sur les commutateurs, passerelles et hôtes.

La sauvegarde doit couvrir les autorités de certification, les politiques, les identifiants de clés et les procédures de réémission, jamais seulement les fichiers de configuration. Restaurer une autorité sans registre fiable des certificats émis transforme une reprise en chasse au trésor cryptographique. Prévoir un mode de reprise qui réémet des identités, révoque les anciennes et reconstruit les tunnels sans réintroduire de clés compromises.

🐝 Ce qui arrive si on s’en passe

Sans chiffrement est-ouest, un flux capturé une seule fois reste exploitable après coup : les identifiants, jetons de session et mots de passe de base de données qui circulent en clair dans les protocoles internes deviennent réutilisables depuis n’importe quel point du réseau, bien après la perte de la position d’écoute. Un flux de réplication ou de sauvegarde intercepté livre une copie complète des données, sans requête ni journal côté application. La détection perd aussi un signal : sans contrôle d’intégrité sur le lien, une trame altérée ou injectée n’incrémente aucun compteur de rejet, et une interception ne laisse aucune trace dans la supervision réseau. Enfin, l’analyse après incident ne peut pas borner l’exposition : faute de savoir quels segments étaient observés, tout secret ayant transité doit être considéré comme compromis et renouvelé.

🦫 Explication de la marmotte 🍫

Les serveurs d’un centre informatique échangent beaucoup de données entre eux : demandes d’applications, copies de sauvegarde, informations de stockage et commandes d’administration. Sans protection, une machine ou un équipement placé sur le trajet peut lire ces données, les modifier ou envoyer de faux messages.

Le chiffrement du trafic interne protège ces échanges pendant leur transport. Une première méthode protège directement le lien entre deux équipements reliés par un câble. Une autre protège les paquets qui passent par plusieurs équipements et plusieurs réseaux. Dans les deux cas, les deux extrémités possèdent des secrets permettant de transformer les données en contenu illisible pour les autres et de vérifier qu’elles n’ont pas été modifiées.

Avant de communiquer, les équipements doivent prouver leur identité et obtenir des clés de courte durée. Ces clés sont renouvelées régulièrement. Si une clé expire, est volée ou si les deux équipements ne sont plus d’accord, la communication doit être refusée plutôt que continuer sans protection.

Cette protection ne corrige pas une application compromise. Un serveur infecté peut toujours lire les données qu’il est autorisé à recevoir. Il faut donc aussi limiter les droits de chaque service, séparer les réseaux, surveiller les erreurs et conserver les moyens de remplacer rapidement les clés. Le chiffrement protège le trajet ; les autres contrôles protègent ce qui arrive avant et après.

Pages voisines

La citent

Chiffrer les flux est-ouest dans un data center

Elle cite

Chiffrer les flux est-ouest dans un data center

Chiffrer les flux est-ouest dans un data center

La confiance implicite du réseau physique est morte

MACsec, IPsec et TLS : choisir la couche qui porte le risque

Exemple MACsec entre deux hôtes Linux

Surface d’attaque et limites du chiffrement est-ouest

Clés, rotation, supervision et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines