Microsegmentation zero trust pour les réseaux de défense : politique et application

La sécurité périmétrique a été bâtie autour d'une hypothèse simple : le trafic provenant de l'intérieur de la frontière pouvait être considéré comme fiable. Dans un réseau de défense, cette hypothèse n'a jamais été pleinement valable, et dans un environnement moderne de cloud hybride ou multi-enclaves, elle est architecturalement intenable. L'attaquant qui a compromis un seul point de terminaison ou volé des identifiants de service ne s'arrête pas au périmètre – il se déplace latéralement, escaladant des charges de travail à faible valeur vers des cibles de grande valeur. La microsegmentation dans le cadre d'une architecture zero trust est le contrôle qui limite le mouvement latéral à la seule charge de travail compromise plutôt qu'à l'ensemble de l'enclave. Cet article examine comment concevoir, appliquer et maintenir une politique de microsegmentation basée sur l'identité dans les réseaux de défense, en accordant une attention particulière aux charges de travail hébergées sur Kubernetes, à l'approvisionnement de l'identité de charge de travail et aux mécanismes d'application est-ouest.

Pourquoi les contrôles uniquement périmétriques échouent dans les environnements de défense

La sécurité réseau traditionnelle dans les environnements de défense repose sur une segmentation physique et logique à grande granularité : des réseaux distincts pour différents niveaux de classification, des frontières VLAN entre zones fonctionnelles et des règles de pare-feu au périmètre de chaque segment. Ce modèle présente deux faiblesses structurelles que la microsegmentation est conçue pour traiter.

Trafic est-ouest plat. Au sein d'un VLAN ou d'un sous-réseau, les charges de travail communiquent généralement sans restriction. Un serveur d'application compromis peut atteindre la base de données, le service d'authentification, le système de gestion de clés et tout autre service du même sous-réseau – non pas parce qu'une politique l'autorise, mais parce qu'aucune politique ne l'interdit. Le coût du mouvement latéral de l'attaquant à l'intérieur d'un segment plat est faible.

La compromission basée sur les identifiants traverse les périmètres. Les pare-feu périmétriques inspectent les en-têtes de paquets, pas l'identité de la charge de travail. Un jeton de compte de service ou un certificat volé qui était valide pour la communication entre deux services est tout aussi valide pour la communication depuis le processus de l'attaquant s'exécutant en tant que ce service. Le pare-feu autorise le trafic car il provient de l'adresse IP source correcte. La microsegmentation avec identité cryptographique de charge de travail y remédie : le principal de la politique n'est pas une adresse IP mais une identité de charge de travail attestée cryptographiquement que l'attaquant ne peut usurper sans accès au matériel de clé privée – qui est éphémère et lié à la charge de travail.

Architecture de microsegmentation : domaines de confiance et frontières de politique

La conception de la microsegmentation pour un réseau de défense commence par la cartographie des flux de communication et le regroupement des charges de travail en domaines de confiance. Un domaine de confiance est un ensemble de charges de travail qui partagent une frontière d'autorisation commune et communiquent librement au sein du groupe, mais qui nécessitent une politique explicite pour communiquer en dehors. Dans un contexte de défense, les frontières naturelles des domaines de confiance s'alignent à la fois sur le niveau de classification et sur le rôle fonctionnel.

Pour une application de défense typique hébergée sur un cluster Kubernetes classifié, les domaines de confiance pourraient être :

Domaines de niveau de classification. Chaque enclave de classification – non classifié, CUI, SECRET – est un domaine de confiance distinct. Aucune communication est-ouest ne traverse les frontières de classification au sein du plan de microsegmentation. La communication inter-domaines est acheminée exclusivement via une solution cross-domain accréditée qui effectue l'inspection du contenu et le réétiquetage.

Domaines de rôle fonctionnel au sein d'un niveau de classification. Au sein de l'enclave SECRET, une segmentation supplémentaire par fonction : services d'ingestion (acceptant des données de capteurs externes), services de traitement (analytique et enrichissement), services de stockage (bases de données et magasins d'objets), services command-plane (orchestration et planification) et services d'audit (journalisation immuable). Chaque domaine fonctionnel ne peut recevoir du trafic que des domaines pairs spécifiques dont les flux de communication sont documentés et approuvés par la politique.

La carte des flux de communication qui résulte de cet exercice – chaque domaine source, domaine destination, port et protocole justifié par le métier – devient l'entrée faisant autorité pour la rédaction de la politique. Tout flux ne figurant pas sur la carte est refusé par défaut.

Identité de charge de travail : SPIFFE/SPIRE dans les environnements Kubernetes

La microsegmentation basée sur l'identité exige que chaque charge de travail possède une identité vérifiable que le plan d'application de politique peut authentifier. L'identité basée sur l'adresse IP est insuffisante dans les environnements de conteneurs dynamiques où les pods sont éphémères et les IP recyclées. La norme SPIFFE (Secure Production Identity Framework For Everyone) définit un modèle d'identité de charge de travail portable et cryptographique, indépendant de l'infrastructure sous-jacente.

L'identité SPIFFE est exprimée sous forme d'URI : spiffe://trust-domain/path. Dans un déploiement Kubernetes utilisant SPIRE (l'implémentation de référence de SPIFFE), chaque pod reçoit un SVID X.509 (SPIFFE Verifiable Identity Document) – un certificat de courte durée contenant son identité SPIFFE comme Subject Alternative Name. Le domaine de confiance correspond au cluster Kubernetes ou à la frontière de fédération. Le chemin encode l'espace de noms Kubernetes et le compte de service, par ex. spiffe://defense.cluster/ns/analytics/sa/enrichment-worker.

La propriété critique pour les déploiements de défense est le TTL court. Les SVID sont émis avec une durée de vie de 1 heure (ou moins, configurable) et automatiquement renouvelés par l'agent SPIRE s'exécutant sur chaque nœud. Si un certificat est compromis, la fenêtre d'exposition est bornée par le TTL. La clé privée ne quitte jamais la mémoire de la charge de travail – elle n'est pas écrite sur le disque et n'est pas accessible aux autres processus du même nœud, même dans un contexte de cluster Kubernetes partagé.

Attestation de nœud dans les clusters classifiés

L'attesteur de nœud de SPIRE est le mécanisme par lequel un nouveau nœud rejoignant le cluster prouve son identité avant d'être autorisé à émettre des SVID aux charges de travail. Dans un environnement Kubernetes classifié, l'attesteur de nœud doit être choisi pour correspondre au modèle de confiance. Pour le matériel classifié sur site, l'attestation basée sur TPM – utilisant le module Trusted Platform Module du nœud pour prouver l'identité matérielle – est le modèle privilégié. Le serveur SPIRE valide la clé d'endossement TPM par rapport à un manifeste connu et fiable avant d'autoriser le nœud à agir en tant qu'émetteur de SVID. Cela signifie qu'un attaquant qui provisionne un nœud non autorisé ne peut obtenir de SVID valides du serveur SPIRE, même s'il dispose d'un accès réseau au serveur API du cluster.

Application est-ouest : maillage de services et eBPF

L'approvisionnement de l'identité de charge de travail est nécessaire mais pas suffisant – le plan d'application doit effectivement utiliser ces identités pour autoriser ou refuser le trafic. Dans un environnement Kubernetes durci, l'application est-ouest est généralement superposée sur trois mécanismes complémentaires.

Kubernetes NetworkPolicy : base L3/L4

Les ressources Kubernetes NetworkPolicy fournissent un moyen déclaratif de spécifier quels pods peuvent communiquer, en utilisant des sélecteurs d'étiquettes de pods et des sélecteurs d'espaces de noms pour identifier la source et la destination. L'application de NetworkPolicy est gérée par le plugin CNI (Container Network Interface). La principale limitation de la NetworkPolicy standard est qu'elle opère au niveau L3/L4 – elle peut autoriser ou refuser le trafic entre groupes de pods selon l'IP et le port, mais elle ne peut pas inspecter l'identité de la charge de travail établissant la connexion, la méthode HTTP appelée ni le contenu de la requête. Pour un modèle de microsegmentation de défense qui exige une identité cryptographique, NetworkPolicy est une base nécessaire mais pas le contrôle complet.

Maillage de services avec TLS mutuel : application L7 consciente de l'identité

Un maillage de services installé en mode TLS mutuel strict ajoute une vérification cryptographique d'identité à chaque connexion est-ouest. Chaque appel service à service est authentifié au niveau de la couche de transport : le client présente son SVID, le serveur présente son SVID, et chacun vérifie l'autre par rapport au paquet de confiance SPIFFE. La politique d'autorisation du maillage de services évalue ensuite le principal authentifié (l'identité SPIFFE vérifiée) par rapport à une règle de politique avant d'autoriser la requête.

Pour les déploiements de défense, le maillage de services doit être configuré avec des bibliothèques cryptographiques validées FIPS 140-2 ou FIPS 140-3. Istio et Linkerd peuvent tous deux être compilés avec BoringCrypto (validé FIPS) ou équivalent. Les suites de chiffrement négociées pour le mTLS doivent être restreintes à l'ensemble approuvé – TLS 1.3 avec AES-256-GCM-SHA384 comme minimum pour les environnements classifiés. La liste complète des suites autorisées doit être documentée dans le cadre de la configuration de sécurité de référence du système.

Application basée sur eBPF : politique au niveau du noyau

L'application du maillage de services opère au niveau du proxy sidecar, qui s'exécute dans l'espace de noms réseau du conteneur. Un attaquant suffisamment privilégié qui peut compromettre l'environnement d'exécution du conteneur ou le pod lui-même peut être en mesure de contourner les proxys sidecar. L'application réseau basée sur eBPF (implémentée par des plugins CNI tels que Cilium) opère sous l'environnement d'exécution du conteneur, au niveau de la pile réseau du noyau Linux. Les programmes eBPF attachés aux hooks du noyau évaluent la politique réseau avant que les paquets ne soient livrés à un processus de l'espace utilisateur – y compris le proxy sidecar. Une charge de travail qui contourne son proxy sidecar ne peut toujours pas atteindre des destinations non autorisées car la couche d'application eBPF refuse le paquet au niveau du noyau.

La combinaison de NetworkPolicy + mTLS du maillage de services + application eBPF crée une pile de microsegmentation en défense en profondeur où chaque couche applique la politique indépendamment. Une défaillance d'une seule couche n'entraîne pas un mouvement latéral illimité.

Cycle de vie de la politique : rédaction, test et maintenance des règles de microsegmentation

La politique de microsegmentation n'est pas une configuration ponctuelle. Les applications de défense évoluent, des charges de travail sont ajoutées et supprimées, et les schémas de communication changent à mesure que des fonctionnalités sont développées. Un modèle de microsegmentation correct au déploiement initial se dégrade au fil du temps s'il n'est pas activement maintenu.

Politique en tant que code. La politique de microsegmentation devrait être versionnée aux côtés du code de l'application. Chaque ressource NetworkPolicy, AuthorizationPolicy et CiliumNetworkPolicy devrait résider dans le dépôt de déploiement de l'application. Les modifications de politique suivent le même processus de revue et d'approbation que les modifications de code – y compris une revue de sécurité pour toute règle qui étend une frontière d'autorisation. Cela empêche les exceptions de pare-feu ad hoc de s'accumuler en dehors du contrôle de version.

Test en mode fantôme. Avant d'appliquer une politique nouvelle ou modifiée en mode d'application, testez-la en mode fantôme (journalisation uniquement). Le maillage de services et le plan d'application eBPF peuvent tous deux fonctionner dans un mode d'audit où les violations de politique sont journalisées mais non bloquées. L'exécution en mode fantôme pendant une période définie (généralement une à deux semaines dans un environnement de préproduction reflétant les schémas de trafic de production) fait apparaître les flux non documentés que la politique bloquerait avant qu'ils ne provoquent des pannes de production. Les flux non documentés découverts lors du test fantôme doivent être examinés – les flux légitimes déclenchent des ajouts de politique, tandis que les flux illégitimes sont la preuve d'un problème de sécurité existant.

Détection automatisée de la dérive de politique. La télémétrie de flux du maillage de services (Hubble d'Istio, Viz de Linkerd) fournit une vue en temps réel de tout le trafic est-ouest. Un outillage automatisé qui compare le trafic observé à la carte des flux approuvés et alerte sur les écarts est une exigence opérationnelle standard pour un déploiement de microsegmentation de défense. Les nouveaux flux qui apparaissent sans mise à jour de politique correspondante sont des candidats d'alerte immédiats – soit l'application a changé sans mettre à jour sa documentation de politique, soit un acteur non autorisé génère du trafic inattendu.

Microsegmentation dans les environnements multi-enclaves et isolés (air-gapped)

Les réseaux de défense s'étendent fréquemment sur plusieurs enclaves à différents niveaux de classification, dont certaines sont entièrement isolées (air-gapped) des réseaux externes. La politique de microsegmentation doit être cohérente à travers toutes les enclaves même lorsqu'il n'existe aucun plan de gestion partagé.

Dans un cluster classifié air-gapped, le serveur SPIRE doit fonctionner entièrement sur site. La racine PKI qui ancre la confiance des SVID ne peut s'appuyer sur aucune autorité de certification externe. La CA racine et les CA intermédiaires du serveur SPIRE sont générées et gérées sur des HSM (Hardware Security Modules) isolés au sein de l'environnement classifié. Les listes de révocation de certificats et les services OCSP doivent également fonctionner au sein de l'isolement – les appels réseau vers une infrastructure externe pour les opérations PKI ne sont pas autorisés dans les architectures réseau classifiées.

La coordination de la microsegmentation inter-enclaves – garantir qu'une politique autorisant un flux de l'enclave CUI vers l'enclave non classifiée est reflétée dans les ensembles de politiques des deux enclaves – est un processus manuel et auditable dans la plupart des programmes. La solution cross-domain qui médiatise le trafic inter-enclaves est la source faisant autorité de ce que les flux sont autorisés à travers la frontière ; les politiques de microsegmentation des deux côtés doivent être cohérentes avec la configuration de la CDS et examinées comme une unité lors du contrôle des changements de politique.