Tapahtumastriimausalustan valitseminen puolustussektorin ohjelmaan on muutakin kuin läpisykykyvertailujen vertailua. Dataresidenssijärjestelyt, ilmarakovaatimukset, vaatimustenmukaisuuskehykset ja luokitustasot rajoittavat päätöstä tavoilla, joilla ei ole vastinetta kaupallisissa käyttöönotoissa. Tiimi, joka valitsee hallinnoidun pilvipalvelun tarkistamatta vaikutustason valtuutuksia tai ottaa käyttöön itse isännöidyn Kafkan suunnittelematta operatiivista taakkaa, kohtaa ongelmia, joita ei voi korjata sen jälkeen kun järjestelmä on tuotannossa.

Tämä artikkeli esittää päätöskehyksen Azure Event Hubsin ja paikallisen Apache Kafkan välillä valitsemiseen puolustussektorin työkuormille, käsittelee kunkin vaatimustenmukaisuus- ja arkkitehtuuriimplikaatioita, kuvaa hybridimallin, joka käyttää molempia alustoja eri luokitustasoilla, ja selittää siirtymispolun niiden välillä kun vaatimukset muuttuvat.

Miksi striimausalustan valinta on tärkeä puolustussektorilla

Kaupallisessa käyttöönotossa hallinnoidun striimauspalvelun ja itse isännöidyn klusterin välinen valinta on ensisijaisesti operatiivinen kompromissi: hallinnoidut palvelut maksavat enemmän per tapahtuma, mutta poistavat klusterinhallinnan kuormituksen. Puolustussektorilla päätös on myös vaatimustenmukaisuus- ja turva-arkkitehtuuripäätös, jonka seuraukset kestävät pidempään kuin mikään yksittäinen sprintti.

Luokitellun tiedon dataresidenssisäännöt määräävät paitsi missä dataa voidaan säilyttää myös mitkä infrastruktuurintarjoajat ovat valtuutettuja käsittelemään sitä. IL5-rajoitusten alainen ohjelma voi käyttää vain niitä Azure Government -alueita, jotka ovat saaneet IL5-ennakkovaltuutuksen — ei jokainen Azure-palvelu Azure Governmentissa täytä vaatimuksia, eikä jokaisella alueella ole samoja valtuutuksia. Ohjelmalla, jolla on kova ilmarakovaatimus, ei ole polkua hallinnoidulle pilvipalvelulle riippumatta sen FedRAMP-asemasta, koska edes FedRAMP High -valtuutettu palvelu vaatii verkkoyhteyden toimiakseen.

Striimausalusta on myös se paikka, jossa tarkastuslokkien, salausavainten omistajuuden ja datan säilytyksen vaatimustenmukaisuusvelvoitteet täytetään infrastruktuuritasolla. Oikein tehty arkkitehtuuri alusta alkaen säästää kuukausia uudelleentyöltä kun valtuuttava virkamies tarkastaa järjestelmän turvasuunnitelman.

Azure Event Hubs: hallinnoidtu striimaus GovCloud-työkuormille

Kafka-yhteensopiva API ja nolla klusterinhallintaa

Azure Event Hubs Premium- ja Dedicated-tasot tarjoavat Kafka-yhteensopivan protokollapäätepisteen. Tuottajat ja kuluttajat, jotka on rakennettu Apache Kafka -asiakaskirjastoa vasten, yhdistävät Event Hubs -nimiavaruuteen muuttamalla kaksi konfigurointiarvoa: bootstrap.servers osoittaa <namespace>.servicebus.usgovcloudapi.net:9093 Azure Governmentissa, ja sasl.mechanism on asetettu PLAIN-arvoon yhteysmerkkijonon kirjautumistiedoilla tai Azure Active Directory -tokeniin OAuth-haltijamekanismilla. Kafka-spesifisiä koodimuutoksia ei vaadita. API on yhteensopiva Kafka 1.0:n ja sitä uudempien asiakaskirjastojen kanssa.

Operatiivinen seuraus on, että kenenkään tiimissäsi ei tarvitse hallita välittäjien provisiointia, ohjainkvoorumin konfigurointia, klusterin TLS-varmenteiden kierrätystä, SCRAM-kirjautumistietoja tai kapasiteetin skaalausta. Läpisyysyksiköt skaalautuvat kysynnän mukaan. Saatavuudella on palvelutasosopimusperusteinen tuki. Maantieteellinen redundanssi on konfigurointiasetus eikä monipaikkainen käyttöönottoprojekti.

FedRAMP High, IL4 ja IL5 -valtuutus

Azure Event Hubsilla Azure Governmentissa on FedRAMP High -valtuutus. Dedicated-taso, joka tarjoaa yksitenanttisen infrastruktuurin, tukee IL4- ja IL5-vaikutustasoja Azure Governmentin palvelujen saatavuusmatriisin mukaisesti. Asiakkaan hallinnoimia avaimia voidaan käyttää Azure Key Vault Managed HSM:n kautta, mikä täyttää IL5-työkuormien AES-256-levossa -vaatimuksen. Event Hubs Dedicatedissa Azure Governmentissa käsitelty ja tallennettu data ei poistu hallituspilvirajojen ulkopuolelle.

Ohjelmille, joiden luokituskatto on CONFIDENTIAL tai FOUO — tai SECRET-työkuormat, joilla on hyväksytty pilvipääsypiste — Event Hubs Dedicated Azure Governmentissa on usein nopein polku vaatimustenmukaiseen striimausinfrastruktuuriin. Välittäjäinfrastruktuuri on Microsoftin FedRAMP-valtuutuspaketin kattama, mikä vähentää pintaa, jota tiimisi täytyy dokumentoida ja puolustaa järjestelmän turvasuunnitelmassa.

API:n rajoitukset ja niiden merkitys puolustussovelluksille

Event Hubs ei toteuta täydellistä Kafka API:a. Transaktioita ja exactly-once-semantiikkaa useiden aiheiden välillä ei tueta välittäjätasolla. AdminClientin ACL-hallinnan API:t puuttuvat — pääsynhallinta hoidetaan Azure RBAC -kerroksella (Data Sender ja Data Receiver -roolit nimiavaruuden tai entiteetin laajuudessa) eikä Kafka-natiivien ACL:ien kautta. Kuluttajaryhmien offseteja hallitsee palvelu, eikä niitä voi suoraan manipuloida Kafkan offset commit API:n kautta samalla tavoin kuin itse isännöidyssä klusterissa.

Puolustussovelluksille, jotka rakennetaan alusta alkaen Event Hubsia vasten, nämä puutteet voidaan kiertää suunnittelemalla niiden ympärille. Sovelluksille, jotka siirtyvät itse isännöidystä Kafkasta ja jotka tukeutuvat transaktioihin tai ohjelmalliseen ACL-hallintaan, ne vaativat koodimuutoksia. Tarkasta tämä riippuvuuslista ennen kuin sitoudut Event Hubsiin pitkäaikaisena alustana.

Paikallinen Kafka: ilmarakokyky ja täysi luokitushallinta

Ainoa toimiva polku koviin ilmarakovaatimuksiin

Ohjelmilla, joilla on valtuutus toimia ilman ulkoista verkkoyhteyttä — fyysisen turvallisuuden, operatiivisen turvallisuuden tai akkreditointisyiden vuoksi — on täsmälleen yksi toimiva striimausalusta: itse isännöity Kafka paikallisinfrastrukturilla. Ei ole olemassa hallinnoitua palveluekvivalenttia, joka toimisi ilman internet-yhteyttä. Azure Event Hubs vaatii riippumatta vaatimustenmukaisuusasemastaan yhteyden Azure Governmentin ohjaustasoon resurssien provisiointia, SAS-tokeneiden kierrätystä ja hallinta-API-kutsuja varten.

Paikallinen Kafka KRaft-tilassa, ilman enklaavirajojen ulkopuolelle reititettyjä verkkoliitäntöjä, täyttää kovan ilmarakovaatimuksen. Kaikki riippuvuudet — JVM, Kafka-binaarit, kontainerikuvat, TLS-varmenteet — esivaiheistetaan paikallisesti ennen verkon katkaisemista. Klusteri toimii sen jälkeen toistaiseksi ilman lähtevää yhteyttä. Yksityiskohtaisen katsauksen kontainerikuvien esivaiheistamiseen ja ilmaraon käyttöönottomalleihin, katso artikkeli ilmaraon käyttöönottomalleja puolustussektorin työkuormille.

KRaft-tila ja itsenäinen klusteritoiminta

Kafka 3.3 esitteli KRaft-tilan ZooKeeper-pohjaisen metadatanhallinnan korvaajana. Puolustussektorin käyttöönotoissa KRaft on oikea oletus jokaiselle uudelle klusterille. Erillinen ZooKeeper-kokoonpano lisää kolme tai useampia solmuja, erillisen vikavyöhykkeen, erillisen konfigurointipinnan ja ylimääräisen prosessin paikattavaksi ja suojattavaksi. KRaft yhdistää ohjainkvoorumin hallinnan Kafka-välittäjäprosessiin itseensä Raft-pohjaista konsensuslokkia käyttäen.

Pienessä tai keskikokoisessa luokitellussa käyttöönotossa — kolmesta viiteen välittäjäsolmua — ohjain- ja välittäjäroolit voidaan sijoittaa samaan solmuun, pitäen kokonaissolmujen määrän kolmessa. Suuremmissa käyttöönotoissa omistautunut kolmen solmun ohjainkvorum erillään välittäjäsolmuista tarjoaa selkeämmät operatiiviset rajat. Joka tapauksessa klusterilla ei ole ulkoisia palveluriippuvuuksia käyntiaikana kerran käynnistyksen jälkeen.

Operatiivinen taakka ja henkilöstövaikutukset

Itse isännöity Kafka ei ole operatiivisesti ilmainen. Tuotantoluokan luokiteltu Kafka-klusteri vaatii jatkuvaa huomiota: käyttöjärjestelmän kovennos ja paikkakierrot, TLS-varmenteiden elinkaarenhallinta sisäisen PKI:n uusimisjärjestyksen mukaisesti, SCRAM-kirjautumistietojen kierrätys, välittäjälokien säilytyksen virittely, osioiden tasapainottaminen aiheiden läpisykyn kasvaessa ja kapasiteettisuunnittelu välittäjän levytilalle. Vaiheittaiset päivitykset Kafkan aliversioissa vaativat huolellista sekvenssointia protokollayhteensopivuusongelmien välttämiseksi.

Ohjelmat, jotka aliarvioivat tämän taakan, päätyvät klustereihin, jotka ajan myötä ajautuvat pois hyväksytystä konfigurointiperuslinjastaan — ongelma, joka tulee tuskallisesti esiin uudelleenakkreditointikatselmusten yhteydessä. Jos ohjelmalla ei ole omistautunutta alustatekniikkafunktiota, suunnittele eksplisiittisesti etukäteen, kuka omistaa Kafka-operaatiot ennen kuin klusteri menee tuotantoon.

Päätösmatriisi

Alla oleva taulukko kartoittaa tärkeimmät käyttöönottotekijät sopivaan alustavalintaan.

Tekijä Azure Event Hubs Paikallinen Kafka
Kova ilmarakovaatimus Ei toimiva Täysin tuettu
FedRAMP High / IL4/IL5 Periytyy Azure Gov:lta Operaattorin vastuulla
Dataluokituksen katto IL5 / FOUO (GovCloud) SECRET / TS (ilmarako)
Vaadittu ops-kapasiteetti Minimaalinen (hallinnoidtu) Korkea (täysi klusteriops)
Klusterinhallinta Ei mitään (täysin hallinnoidtu) Täysi (TLS, KRaft, päivitykset)
Läpisykyn joustavuus Elastinen (läpisyysyksiköt) Manuaalinen välittäjäskaalaus
Täysi Kafka API -pinta Osittainen (ei transaktioita) Täydellinen

Hybridiarkkitehtuuri: porrastettu striimaus luokitustason mukaan

Monet puolustussektorin ohjelmat toimivat samanaikaisesti useilla luokitusalueilla. Taisteluavaruuden hallintaalusta saattaa niellä luokittelemattomia OSINT-syötteitä, FOUO-logistiikkadataa ja SECRET-anturitietoja samasta operatiivisesta kuvasta. Yhden striimausinfrastruktuurin rakentaminen, joka täyttää kaikkien kolmen tason vaatimukset, on mahdotonta — SECRET-datan ilmarakovaatimus on yhteensopimaton hallinnoidun pilvilähestymistavan kanssa, joka toimii hyvin FOUO-datalle.

Käytännön vastaus on porrastettu arkkitehtuuri: Azure Event Hubs Azure Governmentissa käsittelee UNCLASSIFIED- ja FOUO-tason, jossa FedRAMP High -valtuutus kattaa vaatimustenmukaisuusvaatimuksen ja hallinnoidtu skaalaus käsittelee vaihtelevat ingestointinopeudet. Paikallinen Kafka ilmarajatun enklaavon takana käsittelee SECRET- ja TS-tason, jossa ulkoinen verkkoaliippuvuus ei ole hyväksyttävää. Kaksi tasoa eivät ole suoraan yhteydessä toisiinsa.

Alueiden väliset ratkaisut tasoluiden rajoilla

Kun alennettu tai julkaisukelpoinen data täytyy siirtyä luokitellulta tasolta luokittelemattomalle — esimerkiksi puhdistettu sijaintiraportti SECRET-yhdistetystä jäljityksestä — sertifioitu alueiden välinen ratkaisu (CDS) täytäntöönpanee rajan. CDS tarkastaa lähtevän datan määriteltyä sisältöpolitiikkaa vasten, poistaa luokitusmerkinnät ja arkaluonteiset kentät, ja julkaisee tuloksen luokittelemattomaan Event Hubs -nimiavaruuteen. Kahden Kafka-ympäristön välillä ei ole suoraa verkkoyhteyttä. CDS on ainoa yhdystie, ja sen tietovirrat dokumentoidaan järjestelmän turvasuunnitelmassa ja validoidaan akkreditoinnin yhteydessä.

Tämä arkkitehtuuri on monimutkaisempi operoida kuin yksitasoinen ratkaisu, mutta se heijastaa monialueen puolustussektorin ohjelmien todellisuutta. Syvällisempää käsittelyä alueiden välisistä suunnittelumalleista, katso artikkeli alueiden väliset ratkaisut puolustukselle.

Siirtymispolku: Event Hubsista paikalliselle Kafkalle

Ohjelmat alkavat joskus Event Hubsilla — koska työkuorma alun perin täyttää GovCloud-käyttöönoton vaatimukset — ja huomaavat myöhemmin, että luokitusvaatimukset kasvavat, ilrakomandaatti lisätään tai ohjelma siirtyy rajoittavampaan verkkoenklaaviin. Kafka-yhteensopiva API tarkoittaa, että tämä siirtyminen on konfiguraatiomuutos eikä koodin uudelleenkirjoitus.

Mitä muuttuu siirtymisessä

Tuottaja- ja kuluttajapuolella kolme konfigurointiarvoa muuttuvat. Ensinnäkin, bootstrap.servers siirtyy Event Hubs -nimiavaruuden päätepisteestä paikallisen Kafka-klusterin sisäiseen osoitteeseen. Toiseksi, security.protocol ja sasl.mechanism muuttuvat SASL_SSL:stä PLAIN-arvolla SASL_SSL:ksi SCRAM-SHA-512-arvolla. Kolmanneksi, truststore-konfiguraatio muuttuu Azure-palvelun julkisesta varmenneketjusta paikallisklusterin sisäiselle CA-varmenteelle. Kuluttajaryhmätunnukset, aiheiden nimet ja kaikki sovelluslogiikka pysyvät muuttumattomina.

Infrastruktuuripuolella paikallinen Kafka-klusteri on provisioitava, kovennettava ja testattava edustavalla kuormalla ennen tuottajien siirtämistä. Aiheenkonfiguraatio — osioiden määrät, replikointikertoimet, säilytyskäytännöt — täytyy replikoida Event Hubs -nimiavaruudesta paikalliseen klusteriin. Kuluttajaryhmien offseteja Event Hubsista ei voi siirtää suoraan; suunnittele siirtymisikkuna, jossa kuluttajat käsittelevät uudelleen säilytysikkunan alusta tai tunnetusta tarkistuspisteestä.

Esimigraatiotarkistuslista

Ennen siirtymisen suorittamista vahvista, että paikallinen klusteri on läpäissyt tietoturvatarkistuksen: TLS 1.3 varmennettu kaikilla kuuntelijoilla openssl s_client -komennolla, ACL-tarkistus valmis kafka-acls.sh --list -komennolla, välittäjäportit vahvistettu saavuttamattomiksi enklaavista ulkopuolelta verkkoskannauksella, ja kaikki palvelutilin SCRAM-kirjautumistiedot tallennettu salaisuudenhallintajärjestelmään kierrätys konfiguroituna. Dokumentoi siirtymismenettely suorituskirjaan ja tee kuiva-ajo ei-tuotannollisilla työkuormilla ennen luokiteltujen datavirtojen siirtämistä. Kafkan ympärille sopivien nollaluottamusverkko-ohjausten osalta, katso artikkeli nollaluottamusarkkitehtuuri sotilasverkoille.

Corvus.Quantum: kaksoistilainen striimaus luokitelluille puolustussektorin ohjelmille

Corvus.Quantum on puolustussektorille kovennettu tapahtumastriimausalusta, joka tukee molempia tässä artikkelissa kuvattuja käyttöönottotiloja. GovCloud-käyttöönotoissa se integroituu Azure Event Hubs Dedicatediin asiakkaan hallinnoimilla avaimilla ja Azure Active Directory -autentikoinnilla, tarjoten esikonfiguroidun tuottaja- ja kuluttajapinon post-kvanttisalauksella sovelluskerroksessa. Ilmarajattuihin käyttöönotoihin se toimii itsenäisellä KRaft-tilan Kafka-klusterilla, jossa on TLS 1.3, SCRAM-SHA-512 ja LUKS-salattu välittäjätallennustila — kaikki esikoveennettuna ja validoituna luokiteltuihin ympäristöihin.

Alusta on otettu käyttöön operatiivisesti reaaliaikaisen puolustussektorin datan käsittelyyn, käsitellen tuhansia tapahtumia sekunnissa alle 100 ms:n päästä päähän -viiveellä. Se lisää CRYSTALS-Kyber-avaintenkapseloinnin ja AES-256-GCM-hyötykuormasalauksen sovelluskerroksessa, suojaten viestin sisällön sekä nykyiseltä sieppaukselta että tulevalta kvanttikyvykkäältä salauksen purkamiselta — vaatimus anturi- ja ISR-datalle, jolla on pitkä herkkyysikä.

Ohjelmille, jotka navigoivat Event Hubsin ja paikallisen Kafkan välistä valintaa, Corvus.Quantum poistaa tarpeen rakentaa ja ylläpitää erillisiä kovennettuja konfigurointeja kummallekkin käyttöönottotilalle. Sama sovellus yhdistää kumpaan tahansa taustajärjestelmään saman abstraktiokerroksen kautta, ja siirtymispolku tilojen välillä ei vaadi sovelluskoodeita muutoksia. Kun ohjelmasi luokitusvaatimukset muuttuvat, striimausinfrastruktuuri muuttuu niiden mukana.

Aiheeseen liittyvät artikkelit

Corvus.Quantum tarjoaa tuotantovalmiin puolustussektorin striimausalustan, joka toimii Azure Event Hubsilla GovCloudissa tai itse isännöidyllä Kafkalla ilmaraon takana — esikoveennettu, post-kvanttisalattu ja validoitu aktiivisissa operatiivisissa käyttöönotoissa. Jos ohjelmasi tarvitsee suuriläpäisyistä luokiteltua striimausta ilman kuukausien tietoturvatekniikkatyötä, ota yhteyttä tiimiimme.

Tutustu Corvus.Quantumiin →