Zero-trust-microsegmentatie voor defensienetwerken: beleid en handhaving

Perimeterbeveiliging is gebouwd rond een eenvoudige aanname: verkeer dat binnen de grens ontstaat, kon worden vertrouwd. In een defensienetwerk was die aanname nooit volledig geldig, en in een moderne hybride cloud- of multi-enclave-omgeving is ze architectonisch onhoudbaar. De aanvaller die één endpoint heeft gecompromitteerd of servicecredentials heeft gestolen, stopt niet bij de perimeter – hij beweegt lateraal en escaleert van workloads van lage waarde naar doelwitten van hoge waarde. Microsegmentatie binnen een zero-trust-architectuur is de controle die laterale beweging beperkt tot de ene gecompromitteerde workload in plaats van de hele enclave. Dit artikel onderzoekt hoe identiteitsgebaseerd microsegmentatiebeleid in defensienetwerken te ontwerpen, te handhaven en te onderhouden, met specifieke aandacht voor op Kubernetes gehoste workloads, het voorzien van workloadidentiteit en oost-west-handhavingsmechanismen.

Waarom alleen-perimeter-controles falen in defensieomgevingen

Traditionele netwerkbeveiliging in defensieomgevingen steunt op fysieke en logische segmentatie met grove granulariteit: gescheiden netwerken voor verschillende classificatieniveaus, VLAN-grenzen tussen functionele gebieden en firewallregels aan de perimeter van elk segment. Dit model heeft twee structurele zwakheden die microsegmentatie is ontworpen aan te pakken.

Plat oost-west-verkeer. Binnen een VLAN of subnet communiceren workloads doorgaans zonder beperking. Een gecompromitteerde applicatieserver kan de database, de authenticatiedienst, het sleutelbeheersysteem en elke andere dienst op hetzelfde subnet bereiken – niet omdat er een beleid is dat het toestaat, maar omdat er geen beleid is dat het weigert. De kosten van laterale beweging van de aanvaller binnen een plat segment zijn laag.

Credentialgebaseerde compromittering overschrijdt perimeters. Perimeterfirewalls inspecteren pakketheaders, niet de workloadidentiteit. Een gestolen serviceaccounttoken of certificaat dat geldig was voor communicatie tussen twee diensten is evenzo geldig voor communicatie vanuit het proces van de aanvaller dat als die dienst draait. De firewall staat het verkeer toe omdat het van het juiste bron-IP komt. Microsegmentatie met cryptografische workloadidentiteit pakt dit aan: de beleidsprincipal is geen IP-adres maar een cryptografisch geattesteerde workloadidentiteit die de aanvaller niet kan nabootsen zonder toegang tot het privésleutelmateriaal – dat efemeer en workload-gebonden is.

Microsegmentatiearchitectuur: vertrouwensdomeinen en beleidsgrenzen

Een microsegmentatieontwerp voor een defensienetwerk begint met het in kaart brengen van communicatiestromen en het groeperen van workloads in vertrouwensdomeinen. Een vertrouwensdomein is een verzameling workloads die een gemeenschappelijke autorisatiegrens delen en vrij communiceren binnen de groep, maar expliciet beleid vereisen om buiten de groep te communiceren. In een defensiecontext sluiten de natuurlijke grenzen van vertrouwensdomeinen aan op zowel het classificatieniveau als de functionele rol.

Voor een typische defensieapplicatie gehost op een geclassificeerd Kubernetes-cluster zouden de vertrouwensdomeinen kunnen zijn:

Domeinen op classificatieniveau. Elke classificatie-enclave – ongeclassificeerd, CUI, SECRET – is een afzonderlijk vertrouwensdomein. Geen enkele oost-west-communicatie overschrijdt classificatiegrenzen binnen het microsegmentatievlak. Communicatie tussen domeinen wordt uitsluitend gerouteerd via een geaccrediteerde cross-domain-oplossing die inhoudsinspectie en herlabeling uitvoert.

Functionele roldomeinen binnen een classificatieniveau. Binnen de SECRET-enclave verdere segmentatie op functie: ingestiediensten (die gegevens van externe sensoren accepteren), verwerkingsdiensten (analytics en verrijking), opslagdiensten (databases en objectstores), command-plane-diensten (orkestratie en planning) en auditdiensten (onveranderlijke logging). Elk functioneel domein kan alleen verkeer ontvangen van de specifieke peerdomeinen waarvan de communicatiestromen gedocumenteerd en beleidsmatig goedgekeurd zijn.

De communicatiestroomkaart die uit deze oefening voortkomt – elk brondomein, doeldomein, poort en protocol dat zakelijk gerechtvaardigd is – wordt de gezaghebbende input voor het opstellen van beleid. Elke stroom die niet op de kaart staat, wordt standaard geweigerd.

Workloadidentiteit: SPIFFE/SPIRE in Kubernetes-omgevingen

Identiteitsgebaseerde microsegmentatie vereist dat elke workload een verifieerbare identiteit bezit die het beleidshandhavingsvlak kan authenticeren. IP-adresgebaseerde identiteit is ontoereikend in dynamische containeromgevingen waar pods efemeer zijn en IP's worden hergebruikt. De SPIFFE-standaard (Secure Production Identity Framework For Everyone) definieert een draagbaar, cryptografisch workloadidentiteitsmodel dat onafhankelijk is van de onderliggende infrastructuur.

SPIFFE-identiteit wordt uitgedrukt als een URI: spiffe://trust-domain/path. In een Kubernetes-implementatie die SPIRE gebruikt (de referentie-implementatie van SPIFFE) ontvangt elke pod een X.509-SVID (SPIFFE Verifiable Identity Document) – een kortlevend certificaat dat zijn SPIFFE-ID bevat als Subject Alternative Name. Het vertrouwensdomein komt overeen met het Kubernetes-cluster of de federatiegrens. Het pad codeert de Kubernetes-namespace en het serviceaccount, bijv. spiffe://defense.cluster/ns/analytics/sa/enrichment-worker.

De kritieke eigenschap voor defensie-implementaties is de korte TTL. SVID's worden uitgegeven met een levensduur van 1 uur (of minder, configureerbaar) en automatisch geroteerd door de SPIRE-agent die op elke node draait. Als een certificaat wordt gecompromitteerd, wordt het blootstellingsvenster begrensd door de TTL. De privésleutel verlaat nooit het geheugen van de workload – hij wordt niet naar schijf geschreven en is niet toegankelijk voor andere processen op dezelfde node, zelfs niet in een gedeelde Kubernetes-clustercontext.

Node-attestatie in geclassificeerde clusters

De node-attestor van SPIRE is het mechanisme waarmee een nieuwe node die zich bij het cluster voegt zijn identiteit bewijst voordat hij SVID's aan workloads mag uitgeven. In een geclassificeerde Kubernetes-omgeving moet de node-attestor worden gekozen om bij het vertrouwensmodel te passen. Voor geclassificeerde on-premises-hardware is TPM-gebaseerde attestatie – met behulp van de Trusted Platform Module van de node om de hardware-identiteit te bewijzen – het voorkeursmodel. De SPIRE-server valideert de TPM-endorsementsleutel tegen een bekend goed manifest voordat hij de node autoriseert om als SVID-uitgever te fungeren. Dit betekent dat een aanvaller die een ongeautoriseerde node provisioneert geen geldige SVID's van de SPIRE-server kan verkrijgen, zelfs niet als hij netwerktoegang heeft tot de cluster-API-server.

Oost-west-handhaving: service mesh en eBPF

Het voorzien van workloadidentiteit is noodzakelijk maar niet voldoende – het handhavingsvlak moet die identiteiten daadwerkelijk gebruiken om verkeer toe te staan of te weigeren. In een geharde Kubernetes-omgeving wordt oost-west-handhaving doorgaans gelaagd over drie complementaire mechanismen.

Kubernetes NetworkPolicy: L3/L4-basislijn

Kubernetes NetworkPolicy-resources bieden een declaratieve manier om te specificeren welke pods kunnen communiceren, met behulp van podlabelselectors en namespaceselectors om bron en bestemming te identificeren. NetworkPolicy-handhaving wordt afgehandeld door de CNI-plugin (Container Network Interface). De belangrijkste beperking van standaard NetworkPolicy is dat ze op L3/L4 opereert – ze kan verkeer tussen podgroepen toestaan of weigeren op basis van IP en poort, maar ze kan de identiteit van de verbinding makende workload, de aangeroepen HTTP-methode of de inhoud van het verzoek niet inspecteren. Voor een defensie-microsegmentatiemodel dat cryptografische identiteit vereist, is NetworkPolicy een noodzakelijke basislijn maar niet de volledige controle.

Service mesh met wederzijdse TLS: L7-identiteitsbewuste handhaving

Een service mesh geïnstalleerd in strikte wederzijdse TLS-modus voegt cryptografische identiteitsverificatie toe aan elke oost-west-verbinding. Elke dienst-naar-dienst-aanroep wordt geauthenticeerd op de transportlaag: de client presenteert zijn SVID, de server presenteert zijn SVID, en elk verifieert de ander tegen de SPIFFE-trustbundle. Het autorisatiebeleid van de service mesh evalueert vervolgens de geauthenticeerde principal (de geverifieerde SPIFFE-ID) tegen een beleidsregel voordat het verzoek wordt toegestaan.

Voor defensie-implementaties moet de service mesh worden geconfigureerd met FIPS 140-2- of FIPS 140-3-gevalideerde cryptografische bibliotheken. Zowel Istio als Linkerd kunnen worden gecompileerd tegen BoringCrypto (FIPS-gevalideerd) of een equivalent. De voor mTLS onderhandelde cipher suites moeten worden beperkt tot de goedgekeurde set – TLS 1.3 met AES-256-GCM-SHA384 als minimum voor geclassificeerde omgevingen. De volledige lijst van toegestane suites moet worden gedocumenteerd als onderdeel van de beveiligingsconfiguratie-baseline van het systeem.

eBPF-gebaseerde handhaving: beleid op kernelniveau

Service mesh-handhaving opereert op de sidecar-proxylaag, die binnen de netwerknamespace van de container draait. Een voldoende geprivilegieerde aanvaller die de containerruntime of de pod zelf kan compromitteren, kan mogelijk sidecar-proxy's omzeilen. eBPF-gebaseerde netwerkhandhaving (geïmplementeerd door CNI-plugins zoals Cilium) opereert onder de containerruntime, op de netwerkstack van de Linux-kernel. eBPF-programma's die aan kernel-hooks zijn gekoppeld, evalueren het netwerkbeleid voordat pakketten aan enig userspace-proces worden afgeleverd – inclusief de sidecar-proxy. Een workload die zijn sidecar-proxy omzeilt, kan nog steeds geen ongeautoriseerde bestemmingen bereiken omdat de eBPF-handhavingslaag het pakket op kernelniveau weigert.

De combinatie van NetworkPolicy + service mesh-mTLS + eBPF-handhaving creëert een defense-in-depth-microsegmentatiestack waarin elke laag het beleid onafhankelijk handhaaft. Een falen in één enkele laag resulteert niet in onbeperkte laterale beweging.

Beleidslevenscyclus: opstellen, testen en onderhouden van microsegmentatieregels

Microsegmentatiebeleid is geen eenmalige configuratie. Defensieapplicaties evolueren, workloads worden toegevoegd en verwijderd, en communicatiepatronen veranderen naarmate functies worden ontwikkeld. Een microsegmentatiemodel dat correct is bij de initiële implementatie verslechtert in de loop van de tijd als het niet actief wordt onderhouden.

Beleid-als-code. Microsegmentatiebeleid moet samen met de applicatiecode worden geversioneerd. Elke NetworkPolicy-, AuthorizationPolicy- en CiliumNetworkPolicy-resource moet in de implementatierepository van de applicatie leven. Wijzigingen aan het beleid volgen hetzelfde beoordelings- en goedkeuringsproces als codewijzigingen – inclusief een beveiligingsbeoordeling voor elke regel die een toestaan-grens uitbreidt. Dit voorkomt dat ad-hoc firewalluitzonderingen zich buiten versiebeheer ophopen.

Schaduwmodustesten. Voordat u een nieuw of gewijzigd beleid in handhavingsmodus toepast, test het in schaduwmodus (alleen logging). Zowel de service mesh als het eBPF-handhavingsvlak kunnen in een auditmodus opereren waarin beleidsschendingen worden gelogd maar niet geblokkeerd. Draaien in schaduwmodus gedurende een bepaalde periode (doorgaans één tot twee weken in een stagingomgeving die productieverkeerspatronen weerspiegelt) brengt ongedocumenteerde stromen aan het licht die het beleid zou blokkeren voordat ze productiestoringen veroorzaken. Ongedocumenteerde stromen die in de schaduwtest worden ontdekt, moeten worden beoordeeld – legitieme stromen leiden tot beleidstoevoegingen, terwijl illegitieme stromen bewijs zijn van een bestaand beveiligingsprobleem.

Geautomatiseerde detectie van beleidsdrift. Service mesh-stroomtelemetrie (Hubble van Istio, Viz van Linkerd) biedt een realtime overzicht van al het oost-west-verkeer. Geautomatiseerde tooling die waargenomen verkeer vergelijkt met de goedgekeurde stroomkaart en alert op afwijkingen is een standaard operationele vereiste voor een defensie-microsegmentatie-implementatie. Nieuwe stromen die verschijnen zonder een bijbehorende beleidsupdate zijn onmiddellijke alertkandidaten – ofwel is de applicatie veranderd zonder de beleidsdocumentatie bij te werken, ofwel genereert een ongeautoriseerde actor onverwacht verkeer.

Microsegmentatie in multi-enclave- en air-gapped-omgevingen

Defensienetwerken strekken zich vaak uit over meerdere enclaves op verschillende classificatieniveaus, waarvan sommige volledig zijn afgeschermd (air-gapped) van externe netwerken. Microsegmentatiebeleid moet coherent zijn over alle enclaves, zelfs wanneer er geen gedeeld beheervlak is.

In een air-gapped geclassificeerd cluster moet de SPIRE-server volledig on-premises opereren. De PKI-root die het SVID-vertrouwen verankert, kan niet steunen op enige externe certificeringsinstantie. De root-CA en intermediaire CA's van de SPIRE-server worden gegenereerd en beheerd op air-gapped HSM's (Hardware Security Modules) binnen de geclassificeerde omgeving. Certificaatintrekkingslijsten en OCSP-diensten moeten eveneens binnen de air gap opereren – netwerkaanroepen naar externe infrastructuur voor PKI-operaties zijn niet toegestaan in geclassificeerde netwerkarchitecturen.

Coördinatie van microsegmentatie tussen enclaves – ervoor zorgen dat een beleid dat een stroom van de CUI-enclave naar de ongeclassificeerde enclave toestaat, wordt gespiegeld in de beleidssets van beide enclaves – is in de meeste programma's een handmatig en auditeerbaar proces. De cross-domain-oplossing die het verkeer tussen enclaves bemiddelt, is de gezaghebbende bron van welke stromen over de grens zijn toegestaan; de microsegmentatiebeleidsregels aan beide zijden moeten consistent zijn met de CDS-configuratie en als een geheel worden beoordeeld tijdens de beleidswijzigingscontrole.