Zero trust -mikrosegmentointi puolustusverkoissa: käytäntö ja valvonta

Perimetriturvallisuus rakennettiin yksinkertaisen oletuksen varaan: rajan sisäpuolelta peräisin olevaan liikenteeseen voitiin luottaa. Puolustusverkossa tämä oletus ei ollut koskaan täysin pätevä, ja nykyaikaisessa hybridipilvi- tai monienklaaviympäristössä se on arkkitehtonisesti kestämätön. Hyökkääjä, joka on kompromittoinut yhden päätepisteen tai varastanut palvelutunnukset, ei pysähdy perimetriin – hän liikkuu sivuttain, eskaloituen matalan arvon työkuormista korkean arvon kohteisiin. Mikrosegmentointi zero trust -arkkitehtuurin puitteissa on kontrolli, joka rajoittaa sivuttaisliikkeen yksittäiseen kompromittoituneeseen työkuormaan koko enklaavin sijaan. Tämä artikkeli tarkastelee, kuinka suunnitella, valvoa ja ylläpitää identiteettipohjaista mikrosegmentointikäytäntöä puolustusverkoissa, kiinnittäen erityistä huomiota Kubernetes-isännöityihin työkuormiin, työkuorman identiteetin tuottamiseen ja itä-länsi-valvontamekanismeihin.

Miksi pelkät perimetrikontrollit epäonnistuvat puolustusympäristöissä

Perinteinen verkkoturvallisuus puolustusympäristöissä nojaa fyysiseen ja loogiseen segmentointiin karkealla rakeisuudella: erilliset verkot eri luokitustasoille, VLAN-rajat toiminnallisten alueiden välillä ja palomuurisäännöt kunkin segmentin perimetrissä. Tällä mallilla on kaksi rakenteellista heikkoutta, joihin mikrosegmentointi on suunniteltu vastaamaan.

Tasainen itä-länsi-liikenne. VLAN:in tai aliverkon sisällä työkuormat viestivät tyypillisesti rajoituksetta. Kompromittoitunut sovelluspalvelin voi tavoittaa tietokannan, todennuspalvelun, avaintenhallintajärjestelmän ja kaikki muut saman aliverkon palvelut – ei siksi, että on sen salliva käytäntö, vaan koska ei ole sen estävää käytäntöä. Hyökkääjän sivuttaisliikkeen kustannus tasaisen segmentin sisällä on alhainen.

Tunnuksiin perustuva kompromittointi ylittää perimetrit. Perimetripalomuurit tarkastavat pakettien otsikoita, eivät työkuorman identiteettiä. Varastettu palvelutilin token tai varmenne, joka oli pätevä kahden palvelun väliseen viestintään, on yhtä pätevä viestintään hyökkääjän prosessista, joka toimii kyseisenä palveluna. Palomuuri sallii liikenteen, koska se tulee oikeasta lähde-IP:stä. Mikrosegmentointi kryptografisella työkuormaidentiteetillä puuttuu tähän: käytännön pääsubjekti ei ole IP-osoite vaan kryptografisesti todistettu työkuorman identiteetti, jota hyökkääjä ei voi jäljitellä ilman pääsyä yksityiseen avainmateriaaliin – joka on lyhytikäinen ja työkuormaan sidottu.

Mikrosegmentointiarkkitehtuuri: luottamustoimialueet ja käytäntörajat

Puolustusverkon mikrosegmentointisuunnittelu alkaa viestintävirtojen kartoittamisella ja työkuormien ryhmittelyllä luottamustoimialueisiin. Luottamustoimialue on joukko työkuormia, jotka jakavat yhteisen valtuutusrajan ja viestivät vapaasti ryhmän sisällä, mutta edellyttävät nimenomaista käytäntöä viestiäkseen sen ulkopuolelle. Puolustuskontekstissa luonnolliset luottamustoimialueiden rajat linjautuvat sekä luokitustason että toiminnallisen roolin kanssa.

Tyypilliselle luokitellulla Kubernetes-klusterilla isännöidylle puolustussovellukselle luottamustoimialueet voisivat olla:

Luokitustason toimialueet. Jokainen luokitusenklaavi – luokittelematon, CUI, SECRET – on erillinen luottamustoimialue. Mikään itä-länsi-viestintä ei ylitä luokitusrajoja mikrosegmentointitasolla. Toimialueiden välinen viestintä reititetään yksinomaan akkreditoidun cross-domain-ratkaisun kautta, joka suorittaa sisällön tarkastuksen ja uudelleenmerkinnän.

Toiminnallisen roolin toimialueet luokitustason sisällä. SECRET-enklaavin sisällä lisäsegmentointi toiminnon mukaan: ingestointipalvelut (ottavat dataa ulkoisilta antureilta), prosessointipalvelut (analytiikka ja rikastus), tallennuspalvelut (tietokannat ja objektivarastot), command-plane-palvelut (orkestrointi ja aikataulutus) ja auditointipalvelut (muuttumaton lokitus). Jokainen toiminnallinen toimialue voi vastaanottaa liikennettä vain niiltä tietyiltä vertaistoimialueilta, joiden viestintävirrat on dokumentoitu ja käytännöllä hyväksytty.

Tästä harjoituksesta syntyvä viestintävirtakartta – jokainen lähdetoimialue, kohdetoimialue, portti ja liiketoiminnallisesti perusteltu protokolla – tulee käytännön laatimisen auktoritatiiviseksi syötteeksi. Jokainen virta, joka ei ole kartalla, estetään oletusarvoisesti.

Työkuorman identiteetti: SPIFFE/SPIRE Kubernetes-ympäristöissä

Identiteettipohjainen mikrosegmentointi edellyttää, että jokaisella työkuormalla on todennettavissa oleva identiteetti, jonka käytännön valvontataso voi todentaa. IP-osoitepohjainen identiteetti on riittämätön dynaamisissa konttiympäristöissä, joissa podit ovat lyhytikäisiä ja IP:t kierrätettyjä. SPIFFE (Secure Production Identity Framework For Everyone) -standardi määrittelee siirrettävän, kryptografisen työkuormaidentiteettimallin, joka on riippumaton taustalla olevasta infrastruktuurista.

SPIFFE-identiteetti ilmaistaan URI:nä: spiffe://trust-domain/path. Kubernetes-käyttöönotossa, joka käyttää SPIRE:ä (SPIFFE:n referenssitoteutus), jokainen pod saa X.509-SVID:n (SPIFFE Verifiable Identity Document) – lyhytikäisen varmenteen, joka sisältää sen SPIFFE-tunnuksen Subject Alternative Name -nimenä. Luottamustoimialue vastaa Kubernetes-klusteria tai federaatiorajaa. Polku koodaa Kubernetes-nimiavaruuden ja palvelutilin, esim. spiffe://defense.cluster/ns/analytics/sa/enrichment-worker.

Kriittinen ominaisuus puolustuskäyttöönotoissa on lyhyt TTL. SVID:t myönnetään 1 tunnin (tai vähemmän, konfiguroitava) eliniällä ja niitä rotatoidaan automaattisesti kullakin solmulla toimivan SPIRE-agentin toimesta. Jos varmenne kompromittoituu, altistumisikkunaa rajoittaa TTL. Yksityinen avain ei koskaan poistu työkuorman muistista – sitä ei kirjoiteta levylle eikä se ole saman solmun muiden prosessien saatavilla, ei edes jaetussa Kubernetes-klusterikontekstissa.

Solmun attestointi luokitelluissa klustereissa

SPIRE:n solmun attestoija on mekanismi, jolla klusteriin liittyvä uusi solmu todistaa identiteettinsä ennen kuin sille sallitaan SVID:ien myöntäminen työkuormille. Luokitellussa Kubernetes-ympäristössä solmun attestoija on valittava luottamusmallia vastaavaksi. Luokitellulle on-premises-laitteistolle TPM-pohjainen attestointi – käyttäen solmun Trusted Platform Module -moduulia laitteistoidentiteetin todistamiseen – on suositeltu malli. SPIRE-palvelin validoi TPM:n endorsement-avaimen tunnettua hyvää manifestia vasten ennen kuin se valtuuttaa solmun toimimaan SVID:n myöntäjänä. Tämä tarkoittaa, että hyökkääjä, joka provisioi luvattoman solmun, ei voi saada päteviä SVID:itä SPIRE-palvelimelta, vaikka hänellä olisi verkkopääsy klusterin API-palvelimelle.

Itä-länsi-valvonta: palveluverkko ja eBPF

Työkuorman identiteetin tuottaminen on välttämätöntä mutta ei riittävää – valvontatason on todella käytettävä näitä identiteettejä liikenteen sallimiseen tai estämiseen. Kovennetussa Kubernetes-ympäristössä itä-länsi-valvonta kerrostetaan tyypillisesti kolmelle toisiaan täydentävälle mekanismille.

Kubernetes NetworkPolicy: L3/L4-perustaso

Kubernetes NetworkPolicy -resurssit tarjoavat deklaratiivisen tavan määrittää, mitkä podit voivat viestiä, käyttäen pod-tunnistevalitsimia ja nimiavaruusvalitsimia lähteen ja kohteen tunnistamiseen. NetworkPolicy-valvontaa hoitaa CNI-laajennus (Container Network Interface). Standardi NetworkPolicyn keskeinen rajoitus on, että se toimii L3/L4-tasolla – se voi sallia tai estää liikennettä pod-ryhmien välillä IP:n ja portin perusteella, mutta se ei voi tarkastaa yhteyttä muodostavan työkuorman identiteettiä, kutsuttua HTTP-menetelmää tai pyynnön sisältöä. Puolustuksen mikrosegmentointimallille, joka edellyttää kryptografista identiteettiä, NetworkPolicy on välttämätön perustaso mutta ei täydellinen kontrolli.

Palveluverkko molemminpuolisella TLS:llä: L7-identiteettitietoinen valvonta

Tiukkaan molemminpuoliseen TLS-tilaan asennettu palveluverkko lisää kryptografisen identiteetin todennuksen jokaiseen itä-länsi-yhteyteen. Jokainen palvelu-palvelu-kutsu todennetaan kuljetuskerroksella: asiakas esittää SVID:nsä, palvelin esittää SVID:nsä, ja kumpikin todentaa toisensa SPIFFE-luottamuspakettia vasten. Palveluverkon valtuutuskäytäntö arvioi sitten todennetun pääsubjektin (todennetun SPIFFE-tunnuksen) käytäntösääntöä vasten ennen pyynnön sallimista.

Puolustuskäyttöönotoissa palveluverkko on määritettävä FIPS 140-2- tai FIPS 140-3 -validoiduilla kryptografisilla kirjastoilla. Sekä Istio että Linkerd voidaan kääntää BoringCryptoa (FIPS-validoitu) tai vastaavaa vasten. mTLS:lle neuvotellut salausyhdistelmät on rajoitettava hyväksyttyyn joukkoon – TLS 1.3 ja AES-256-GCM-SHA384 minimivaatimuksena luokitelluille ympäristöille. Täydellinen luettelo sallituista yhdistelmistä on dokumentoitava osana järjestelmän tietoturvakonfiguraation perustasoa.

eBPF-pohjainen valvonta: ytimen tason käytäntö

Palveluverkon valvonta toimii sidecar-välityspalvelinkerroksella, joka toimii kontin verkkonimiavaruuden sisällä. Riittävän etuoikeutettu hyökkääjä, joka voi kompromittoida kontin ajonaikaisen ympäristön tai itse podin, saattaa pystyä ohittamaan sidecar-välityspalvelimet. eBPF-pohjainen verkkovalvonta (toteutettu CNI-laajennuksilla kuten Cilium) toimii kontin ajonaikaisen ympäristön alapuolella, Linux-ytimen verkkopinossa. Ytimen koukkuihin liitetyt eBPF-ohjelmat arvioivat verkkokäytännön ennen kuin paketit toimitetaan millekään käyttäjätilan prosessille – mukaan lukien sidecar-välityspalvelin. Työkuorma, joka ohittaa sidecar-välityspalvelimensa, ei silti voi tavoittaa luvattomia kohteita, koska eBPF-valvontakerros estää paketin ytimen tasolla.

NetworkPolicyn + palveluverkon mTLS:n + eBPF-valvonnan yhdistelmä luo syväpuolustus-mikrosegmentointipinon, jossa jokainen kerros valvoo käytäntöä itsenäisesti. Minkä tahansa yksittäisen kerroksen vika ei johda rajoittamattomaan sivuttaisliikkeeseen.

Käytännön elinkaari: mikrosegmentointisääntöjen laatiminen, testaaminen ja ylläpito

Mikrosegmentointikäytäntö ei ole kertaluonteinen konfiguraatio. Puolustussovellukset kehittyvät, työkuormia lisätään ja poistetaan, ja viestintätavat muuttuvat ominaisuuksien kehittyessä. Mikrosegmentointimalli, joka on oikea alkukäyttöönotossa, heikkenee ajan myötä, jos sitä ei aktiivisesti ylläpidetä.

Käytäntö koodina. Mikrosegmentointikäytäntö tulisi versioida sovelluskoodin rinnalla. Jokaisen NetworkPolicy-, AuthorizationPolicy- ja CiliumNetworkPolicy-resurssin tulisi sijaita sovelluksen käyttöönottorepositoriossa. Käytäntömuutokset noudattavat samaa tarkistus- ja hyväksyntäprosessia kuin koodimuutokset – mukaan lukien tietoturvatarkistus jokaiselle säännölle, joka laajentaa sallintarajaa. Tämä estää tilapäisten palomuuripoikkeusten kertymisen version hallinnan ulkopuolelle.

Varjotilatestaus. Ennen uuden tai muokatun käytännön soveltamista valvontatilassa testaa se varjotilassa (vain lokitus). Sekä palveluverkko että eBPF-valvontataso voivat toimia auditointitilassa, jossa käytäntörikkomukset lokitetaan mutta ei estetä. Varjotilassa ajaminen määritellyn ajanjakson ajan (tyypillisesti yhdestä kahteen viikkoa tuotantoliikennetapoja heijastavassa staging-ympäristössä) tuo esiin dokumentoimattomat virrat, jotka käytäntö estäisi, ennen kuin ne aiheuttavat tuotantokatkoja. Varjotestauksessa löydetyt dokumentoimattomat virrat on tarkistettava – oikeutetut virrat laukaisevat käytäntölisäyksiä, kun taas oikeudettomat virrat ovat todiste olemassa olevasta tietoturvaongelmasta.

Automaattinen käytännön ajautumisen havaitseminen. Palveluverkon virta-telemetria (Istion Hubble, Linkerdin Viz) tarjoaa reaaliaikaisen näkymän kaikkeen itä-länsi-liikenteeseen. Automaattinen työkalu, joka vertaa havaittua liikennettä hyväksyttyyn virtakarttaan ja hälyttää poikkeamista, on puolustuksen mikrosegmentointikäyttöönoton vakio-operatiivinen vaatimus. Uudet virrat, jotka ilmaantuvat ilman vastaavaa käytäntöpäivitystä, ovat välittömiä hälytyskandidaatteja – joko sovellus muuttui päivittämättä käytäntödokumentaatiotaan, tai luvaton toimija tuottaa odottamatonta liikennettä.

Mikrosegmentointi monienklaavi- ja ilmaeristetyissä (air-gapped) ympäristöissä

Puolustusverkot ulottuvat usein useisiin enklaaveihin eri luokitustasoilla, joista osa on täysin ilmaeristettyjä (air-gapped) ulkoisista verkoista. Mikrosegmentointikäytännön on oltava johdonmukainen kaikissa enklaaveissa, vaikka yhteistä hallintatasoa ei olisikaan.

Ilmaeristetyssä luokitellussa klusterissa SPIRE-palvelimen on toimittava kokonaan on-premises. PKI-juuri, joka ankkuroi SVID-luottamuksen, ei voi nojata mihinkään ulkoiseen varmenneviranomaiseen. SPIRE-palvelimen juuri-CA ja väli-CA:t generoidaan ja hallitaan ilmaeristetyillä HSM:illä (Hardware Security Modules) luokitellun ympäristön sisällä. Varmenteiden sulkulistojen ja OCSP-palvelujen on niin ikään toimittava ilmaeristyksen sisällä – verkkokutsut ulkoiseen infrastruktuuriin PKI-toimintoja varten eivät ole sallittuja luokitelluissa verkkoarkkitehtuureissa.

Enklaavien välinen mikrosegmentoinnin koordinointi – sen varmistaminen, että CUI-enklaavista luokittelemattomaan enklaaviin virran salliva käytäntö on peilattu molempien enklaavien käytäntöjoukkoihin – on useimmissa ohjelmissa manuaalinen ja auditoitavissa oleva prosessi. Enklaavien välistä liikennettä välittävä cross-domain-ratkaisu on auktoritatiivinen lähde sille, mitkä virrat ovat sallittuja rajan yli; molempien puolten mikrosegmentointikäytäntöjen on oltava johdonmukaisia CDS-konfiguraation kanssa ja tarkistettava yhtenä kokonaisuutena käytäntömuutosten hallinnan aikana.