Puolustusjärjestelmät tuottavat dataa tahdissa ja volyymissa, jota perinteiset pyyntö-vastaus-arkkitehtuurit eivät pysty absorboimaan. Yksi UAS syöttää kymmeniä telemetriparametreja sekunnissa. Prikaatitason C2-solmu käsittelee satoja sijaintiraportteja ja tilatapahtumaviestejä minuutissa. ISR-fuusiosolu vastaanottaa syötteitä tutkasta, signaalitiedustelusta ja inhimillisestä tiedustelusta samanaikaisesti — kaikki vaatien alle sekunnin korrelaatioaikaa. Kun näiden tietovirtojen on kuljettava luotettavasti vikasietoisen, auditoitavan ja luokitellun infrastruktuurin läpi, Apache Kafkasta on tullut arkkitehtuurin selkäranka.

Tässä artikkelissa käsitellään Kafkan käyttöönottoa erityisesti puolustuksen käyttötapauksiin: osiointistrategia moniluokitusympäristöissä, täydellinen salauskonfiguraatio, ilmavälikäyttöönotto KRaft-tilalla sekä kompromissi itsehostattujen klustereiden ja hallittujen vaihtoehtojen, kuten Azure Event Hubsin, välillä GovCloud-työkuormia varten.

Miksi tapahtumavirtaus sopii puolustusarkkitehtuureihin

Puolustuksen työnkulut ovat luonteeltaan tapahtumapohjaisia. Sensoritelemetria ei saavu siisteinä erينä — se on jatkuva lukemivirta, joka on käsiteltävä heti saapuessaan ollakseen operatiivisesti hyödyllinen. C2-tapahtumat — yksikön liike, tehtävänanto, tilapäivitykset — ovat erillisiä viestejä, joita useat kulutusjärjestelmät tarvitsevat samanaikaisesti: yhteinen operatiivinen kuva, logistiikka, tulikoordinaatio ja jälkianalyysi tarvitsevat kaikki saman taustatapahtuman ilman, että tuottajan tarvitsee tietää, kuka kuuntelee.

Kafkan julkaise-tilaa-malli vastaa tähän vaatimukseen selkeästi. Tuottaja kirjoittaa sensorilukeman tai C2-tapahtuman aiheeseen. Mikä tahansa määrä kuluttajaryhmiä — kukin edustaa eri alavirtasovellusta — toistaa tapahtuman itsenäisesti omassa tahdissaan. Tämä irrottaminen tarkoittaa, että uuden analytiikkatyökuorman lisääminen ei vaadi muutoksia tuottavaan järjestelmään, mikä on kriittistä puolustusympäristöissä, joissa ohjelmistomuutosten hallinta on hidasta ja hyväksyntäsyklit ovat pitkiä.

Irrottamisen lisäksi Kafkan kestävä loki tarjoaa vain-liitettävän auditointijäljen, joka täyttää useimpien puolustusjärjestelmien forensiikkavaatimukset. Jokainen viesti säilytetään levyllä konfiguroitavan ajanjakson ajan. Jos tapahtuma sattuu, operaattorit voivat toistaa tarkan tapahtumaketjun johtaen siihen turvautumatta sovellustasoisen lokituksen varaan.

Kafkan ydinarkitehtuuri luokitelluissa ympäristöissä

Välitintopologia

Tuotantovalmis luokiteltu Kafka-klusteri vaatii vähintään kolme välitinsolmua tukemaan replikointikerrointa kolme ja min.insync.replicas-asetusta kaksi. Tämä konfiguraatio sietää yhden välittimen häviämisen ilman datan menetystä tai tuottajavirheitä. Korkean saatavuuden luokitelluissa käyttöönotoissa viisi välitintä — hajautettuina vähintään kolmelle fyysiselle räkille tai saatavuusvyöhykkeelle — tarjoaa vahvemman vikasietoisuuden ja liikkumavaraa rullaaviin päivityksiin.

Kafka 3.3:sta lähtien KRaft-tila korvaa ZooKeeperin klusterien metatietohallinnassa. Ilmavälillisille puolustuskäyttöönotoille tämä ei ole valinnainen — se on oikea oletusasetus. Erillinen ZooKeeper-ensemble lisää kolme solmua lisää, erillisen vikaantumisalueen ja lisähyökkäyspinnan. KRaft konsolidoi metatietohallinnnan Kafka-välittimiin itsessään käyttäen Raft-pohjaista kvorumia ohjainsolmuista, jotka tyypillisesti ovat yhteissijoitettuina välittimien kanssa pienissä klustereissa tai eriytettyinä suurissa.

Aiheen osiointi luokitustason mukaan

Tärkein arkkitehtuuripäätös moniluokitusisessa Kafka-käyttöönotossa on se, kuinka eristys eri herkkyystason datan välillä toteutetaan. On kaksi lähestymistapaa.

Ensimmäinen lähestymistapa käyttää yhtä klusteria aiheen tason ACL-eristyksellä. Aiheet nimetään luokituksen mukaan: ts.sensor.uav-telemetry erittäin salaisen tason telemetrialle, s.c2.position-reports salaisen tason C2-datalle, c.logistics.supply-events luottamukselliselle logistiikalle. Kullekin palvelutilille myönnetään tuottamis- ja kuluttamisoikeudet vain aiheisiin, jotka vastaavat sen selvitystasoa. Tämä lähestymistapa vähentää operatiivista monimutkaisuutta, mutta vaatii suurta luottamusta Kafkan ACL-täytäntöönpanoon ja huolellista verkkojen segmentointia sen varmistamiseksi, että välitinprosessit itsessään eivät ole sivuttaisliikkumisen polku.

Toinen lähestymistapa — suositeltava, kun käsitellään SALAINEN-tason yläpuolella olevaa dataa samalla fyysisellä infrastruktuurilla — käyttää erillisiä välitinklustereita per luokitusalue, yhdistettynä poikkialueratkaisulla (CDS) harvinaisissa tapauksissa, joissa alennetun luokituksen data tarvitsee kulkea rajan yli. Tämä eliminoi yhteisen välittimen riskin kokonaan lisääntyneen operatiivisen ylimääräisen työn kustannuksella. Syvempää käsittelyä poikkialuearkkitehtuureista löydät artikkelista poikkialueratkaisut puolustukseen.

Säilytys ja osioiden määrä

Aseta osioiden määrät odotetun läpimenon perusteella, ei käytännöllisyyden. Aihe, joka käsittelee 10 000 viestiä sekunnissa sensorijärjestelmästä, tulisi jakaa riittävään määrään osioita niin, että jokainen ryhmän kuluttaja voi käsitellä sille määritetyt osiot ilman viivästymistä. Nyrkkisääntö: osioiden määrän tulisi olla vähintään kuluttavien ryhmien kuluttajien määrä ja ihanteellisesti kaksi tai kolme kertaa enemmän salliakseen kuluttajaryhmien tasapainotuksen ilman kuumien pisteiden syntymistä.

Säilytyskäytäntöpäätösten on oltava dokumentoituja ja perusteltuja. Sensoritelemetria, jota analysoidaan lähes reaaliajassa, tarvitsee tyypillisesti vain 24–72 tunnin säilytystä, ennen kuin se voidaan siirtää kylmään tallennukseen tai poistaa. C2-tapahtumalokeja, joita tarvitaan jälkianalyysiä varten, tulisi säilyttää 30–90 päivää kuumassa tasossa, minkä jälkeen ne tulisi viedä salattuun, muuttumattomaan arkistoon. Älä luota pelkästään Kafkaan pitkäaikaisena auditointitallennuksena — se on tapahtumabussi, ei arkistotietokanta.

Salaus siirron aikana: TLS 1.3 ja SASL SCRAM

Luokitellut ympäristöt edellyttävät salausta jokaisella datapolulla. Kafkalle tämä tarkoittaa kahta erillistä ohjausta: kuljetussalausta ja asiakastodennusta.

TLS 1.3 -konfiguraatio

Konfiguroi jokainen Kafka-kuuntelija — mukaan lukien välittimien välinen kommunikaatio — TLS 1.3:lla. Tiedostossa server.properties:

listeners=SASL_SSL://0.0.0.0:9093
advertised.listeners=SASL_SSL://broker-1.internal:9093
ssl.protocol=TLSv1.3
ssl.enabled.protocols=TLSv1.3
ssl.keystore.location=/etc/kafka/ssl/broker.keystore.jks
ssl.keystore.password=${KEYSTORE_PASSWORD}
ssl.truststore.location=/etc/kafka/ssl/ca.truststore.jks
ssl.truststore.password=${TRUSTSTORE_PASSWORD}
ssl.client.auth=required

ssl.client.auth=required-asetus pakottaa molemminpuolisen TLS:n (mTLS): jokaisen yhdistyvän asiakkaan on esitettävä sisäisen varmentamisviranomaisen allekirjoittama sertifikaatti. Tämä varmistaa, että vain tunnetut, provisioidut järjestelmät voivat yhdistää klusteriin — vaatimus missä tahansa luokitellussa enklaavissa. Älä käytä requested- tai none-asetuksia luokitelluissa ympäristöissä.

Sertifikaattien on tultava sisäiseltä PKI:ltä. Älä käytä julkisten CA:iden allekirjoittamia sertifikaatteja ilmavälillisessä ympäristössä — äläkä salli julkisten CA-juurien välittimen luotamusvarastossa, koska tämä voisi sallia vaarantuneen ulkoisen sertifikaatin esiintyä laillisena asiakkaana.

SASL SCRAM-SHA-512

mTLS:n lisäksi käytä SASL SCRAM-SHA-512:ta käyttäjätason todentamiseen. Tämä sitoo nimetyn identiteetin — kuten tietyn sovelluksen palvelutilin — TLS-yhteyteen, mahdollistaen hienojakoisen ACL-täytäntöönpanon päämiehen nimen perusteella eikä pelkästään sertifikaatin subjektin perusteella.

sasl.enabled.mechanisms=SCRAM-SHA-512
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512
security.inter.broker.protocol=SASL_SSL

Provisioi tunnistetiedot kafka-configs.sh:llä ja tallenna ne salausavaintenhallintajärjestelmääsi — HashiCorp Vault tai vastaava ilmavälillinen salaisvarasto — eikä konfiguraatiotiedostoihin. Kierrätä tunnistetiedot aikataulussa, joka on linjassa akkreditaatiosi avainten hallintakäytännön kanssa — tyypillisesti 90 päivän välein tai henkilöstömuutosten yhteydessä.

Salaus lepotilassa: AES-256 ja tallennuskerroksen ohjaukset

Kafka ei natiivisti salaa lokisegmentteihinsä kirjoittamaansa dataa. Salaus lepotilassa on tallennuskerroksen vastuulla. Bare-metal- tai virtuaalikone-käyttöönotoissa käytä LUKS:ia (Linux Unified Key Setup) AES-256:lla XTS-tilassa lohkolaitteilla, jotka isännöivät Kafkan log.dirs-hakemistoja. Kubernetes-pohjaisissa käyttöönotoissa provisioi StorageClass-resursseja salattujen volyymien tuella — Azure Governmentissa käytä palvelinpuolen salausta asiakkaan hallitsemilla avaimilla (SSE-CMK) Azure Diskillä. Paikalla olevat vastaavat sisältävät NetAppin NSE-asemilla tai puhtaan ohjelmisto-LUKS:in standardeilla NVMe-levyillä.

Työkuormille, joissa edes tallennustilan operaattorin ei pidä pystyä lukemaan viestisisältöä — erityisesti relevantti erityisohjelmille — toteuta sovellustason salaus: tuottaja salaa viestikuorman ennen kirjoittamista ja vain valtuutetuilla kuluttajilla on purkamisavain. Tämä lähestymistapa on riippumaton Kafkan konfiguraatiosta ja tarjoaa päästä päähän -luottamuksellisuuden, joka säilyy, vaikka välittimen tallennustila vaarantuu. Kompromissi on, että välittimenpuoleinen suodatus ja tiivistys muuttuvat mahdottomiksi salatuille kuormille, koska välittimet eivät pysty tarkistamaan sisältöä.

Ilmavälillinen Kafka-käyttöönotto KRaft-tilalla

Ilmavälillisellä Kafka-käyttöönotolla ei ole internet-yhteyttä, ei ulkoista DNS-selvitystä eikä pääsyä julkisiin konttiohjelmistorekistereihin tai pakettipalvelimiin. Jokaisen komponentin on oltava saatavilla paikallisesti ennen kuin klusteri voi käynnistyä. Tässä osiossa käsitellään erityisiä ongelmakohtia, jotka kohtaavat insinöörejä tässä ympäristössä käyttöönoton yhteydessä.

KRaft-tila ja toiminta ilman ZooKeeperia

Käytä Kafka 3.6:ta tai uudempaa KRaft-tilan ollessa käytössä. Klusteri vaatii ohjainkvorum — tyypillisesti kolme ohjainsolmua, jotka voivat olla yhteissijoitettuina välittimien kanssa kolmen tai viiden solmun käyttöönotoissa. Kullekin solmulle määritetään node.id ja process.roles-arvo controller, broker tai molemmat.

Käynnistä klusteri kafka-storage.sh format-komennolla klusterin UUID:n generoimiseksi ja alkuperäisen metadatalokin kirjoittamiseksi. Tämä vaihe on suoritettava jokaisella solmulla samalla UUID:lla ennen välitinprosessien käynnistämistä. Ilmavälillisessä ympäristössä generoi UUID yhdellä solmulla, kopioi se muille, sitten suorita format kullakin.

CLUSTER_ID=$(kafka-storage.sh random-uuid)
kafka-storage.sh format -t $CLUSTER_ID -c /etc/kafka/server.properties

Sisäinen DNS ja sertifikaattien hallinta

Konfiguroi advertised.listeners käyttämään täysin määriteltyjä isäntänimiä, jotka ovat selvitettävissä enklaavin sisällä — joko sisäisen DNS-palvelimen tai /etc/hosts-tiedoston kautta jokaisella isännällä, joka yhdistää klusteriin. IP-osoitteiden suoran käytön advertised.listeners-asetuksessa toimii, mutta monimutkaistaa sertifikaattien hallintaa, koska sertifikaatin SAN:ien on listattava jokainen IP.

Suorita offline root CA käyttäen step-caa tai CFSSL:ää, joista kummallakaan ei ole ulkoisia riippuvuuksia ajon aikana. Generoi välitinsertifikaatit SAN:eilla, jotka kattavat välittimen isäntänimen. Jaa CA-juursertifikaatti jokaisen asiakkaan luotamusvarastoon. Aseta sertifikaatin voimassaoloajat linjaan uudelleenakkreditointiaikataulun kanssa ja pidä sertifikaatti-inventaario, jotta uusinnat eivät aiheuta odottamattomia käyttökatkoja.

Konttikuvien ja artefaktien hallinta

Vedä kaikki tarvittavat kuvat — Kafka, seurantapinosi ja Kafka Connect -liitännäiset — internet-yhteydellisellä koneella, vie ne docker save-komennolla, siirrä ilmavälilliseen ympäristöön hyväksytyn datadiodin tai siirrettävän median prosessin avulla, ja lataa paikalliseen rekisteriin docker load-komennolla. Kiinnitä kuvien tagit tiettyihin digesteihin käyttöönottomanifestissasi estääksesi odottamattomat muutokset, jos paikallinen rekisteri päivitetään. Lisätietoja ilmavälillisistä Kubernetes-käyttöönotoista puolustuskonteksteissa löydät artikkelista ilmavälikäyttöönottokuviot puolustukseen.

Azure Event Hubs Kafka-yhteensopivana vaihtoehtona

Kaikki puolustuksen työkuormat eivät vaadi täysin irrotettua, itsehallittua klusteria. Ohjelmille, jotka toimivat GovCloud-rajojen sisällä — Azure Government, IL4 tai IL5 — Azure Event Hubs Premium ja Dedicated -tasot tarjoavat Kafka-yhteensopivan päätepisteen, joka hyväksyy standardi-Kafka-tuottajat ja -kuluttajat ilman koodimuutoksia. Protokollapinta on yhteensopiva Kafka 1.0:n ja sitä uudempien asiakaskirjastojen kanssa.

Event Hubs Azure Governmentissa täyttää FedRAMP High -valtuutuksen ja Dedicated-tason osalta tukee asiakkaan hallitsemia avaimia Azure Key Vault Managed HSM:n kautta, tarjoten AES-256-lepotilanteen salauksen, jonka luokitellut työkuormat vaativat. Operatiivinen hyöty on merkittävä: ei välittimien provisiointia, ei klusterin sertifikaattikierrätystä, sisäänrakennettu maantieteellinen redundanssi ja SLA-taattu saatavuus.

Kompromissi on selvä: Event Hubs ei tue täyttä Kafka API:n pintaa (ei transaktioita, ei tarkalleen-kerran-semantiikkaa aiheiden välillä välitintasolla, eikä mukautettua ACL-mallia nimiavaruustason RBAC:n ulkopuolella). Ja työkuormille, joiden on oltava täysin ilmavälillisiä — ilman yhteyttä mihinkään ulkoiseen verkkoon — Event Hubs ei ole vaihtoehto. Niille ohjelmille itsehostatut KRaft-klusterit ovat edelleen ainoa toteuttamiskelpoinen polku.

Zero-trust-integraatio Kafka-kuluttajille

Kafkan ACL-malli on välttämätön mutta ei riittävä tietoturvavalvonta zero-trust-ympäristössä. Jokaisen kuluttajapalvelun tulisi todentaa käyttäen lyhytaikaista tunnistetietoa, jonka identiteettitarjoaja myöntää pod- tai prosessin käynnistyshetkellä, eikä pitkäaikaista staattista salasanaa. Vaultin Kafka-salausmoottori voi myöntää lyhytaikaisia SCRAM-tunnistetietoja dynaamisesti, automaattisella peruutuksella vuokra-ajan umpeutuessa. Yhdistettynä mTLS-asiakassertifikaatteihin, joita kierrätetään aikataulussa, tämä varmistaa, että vaarantuneella palvelutilitunnistetiedolla on rajallinen operatiivinen ikkuna hyökkääjälle.

Sovella verkkokäytäntöjä Kubernetes- tai palomuurikerroksella varmistaaksesi, että vain oikeilla etiketillä varustetut podit voivat saavuttaa Kafka-välittimien portit. Kafkan natiivien ACL:ien tulisi olla toinen puolustuslinja, ei ensimmäinen. Kattava käsittely zero-trust-arkkitehtuurista puolustusverkkoihin sovellettuna löytyy artikkelista zero-trust-arkkitehtuuri sotilasverkkoihin.

Corvus.Quantum: Kafka-pohjainen tietovirta post-kvanttisalauksella

Corvus.Quantum on taistelutestattu tapahtumavirtausplatforma, joka on rakennettu Kafkan päälle ja otettu operatiivisesti käyttöön Ukrainassa reaaliaikaiseen puolustusdatan käsittelyyn. Se laajentaa standardia Kafkaa post-kvanttisalauksella sovellustasolla — käyttäen CRYSTALS-Kyberiä avainten kapselointiin ja AES-256-GCM:ää kuormasalaukseen — jotta viestit ovat suojattuna sekä nykyiseltä vastustajan sieppaukselta että tulevaisuuden kvanttipohjaisia purkuhyökkäyksiä vastaan. Tämä käsittelee "kerää nyt, pura myöhemmin" -uhkaa, joka on erityisen relevantti signaali- ja ISR-datalle, jolla on pitkä herkkyyskausi.

Salauksen lisäksi Corvus.Quantum tarjoaa esikarkaisun välitinkonfiguraation luokitelluille käyttöönotoille: KRaft-tila-klusterimallit, TLS 1.3 -sertifikaattiautomaatio upotetulla step-ca-instanssilla, SCRAM-tunnistetietojen kierrätys integroituna HashiCorp Vaultiin ja luokitustietoiset aihe-ACL-mallit. Platforma on validoitu ympäristöissä ilman internet-yhteyttä, käsitellen tuhansia sensoratapahtumia sekunnissa alle 100 ms:n päästä päähän -viiveellä.

Puolustusohjelmiensa Kafkaa arvioinneille hankintatiimeille Corvus.Quantum vähentää Kafka-klusterin suojaamisen insinöörityötä kuukausista päiviin, tarjoten auditoitavan konfiguraatiolähtötilanteen, joka on linjassa CNSA 2.0 -vaatimusten kanssa ja tukee integraatiota olemassa olevien poikkialueratkaisujen kanssa.

Aiheeseen liittyvät artikkelit

Corvus.Quantum tarjoaa tuotantovalmiin, post-kvanttisuojatun Kafka-virtausplatforman — esikarkaistuun luokiteltuihin ympäristöihin, validoitu aktiivisissa operatiivisissa käyttöönotoissa ja valmis GovCloud- tai ilmaväli-integraatioon. Jos ohjelmasi vaatii korkean suorituskyvyn puolustuksen tietovirtaa ilman kuukausien tietoturvatekniikkaa, ota yhteyttä tiimiimme.

Tutustu Corvus.Quantumiin →