Puolustuksen data lake -arkkitehtuuri: sensorin syötöstä analyytikon kyselyyn

Moderni puolustusorganisaatio tuottaa dataa sellaisella nopeudella, joka rikkoo perinteiset tietokantaolettamukset. Yksi ISR-alusta tuottaa gigatavuja kuvia lentotehtävää kohden. Sensoririkas saattue tuottaa tuhansia CoT-sijaintiraportteja minuutissa. Yksi SIGINT-keräysistunto voi tuottaa teratavuja raakaa I/Q-dataa ennen kuin signaalienkäsittelyäkään on tapahtunut. Kerro nämä volyymit koko yhteisjoukkovoimalla — satoja alustoja, kymmeniä sensorityökaluja, useita luokittelutasoja — ja syntyvä tietoongelma ei ole enää tietokantaongelma. Se on data lake -ongelma.

Tässä artikkelissa käydään läpi puolustuksen data laken koko arkkitehtuuri: miten data syötetään, miten se tallennetaan ja strukturoidaan, miten luokittelurajat pakotetaan, miten analyytikot kyselevät sitä ja miten luokiteltu data poistetaan turvallisesti. Tässä esitetyt mallit soveltuvat sekä paikallisiin luokiteltuihin järjestelmiin, hybridi-käyttöönottoihin että pilviyhdistetyihin analytiikka-alustoihin luokittelemattomalla tai kontrolloidun luokittelemattoman tason tasolla.

Miksi perinteiset tietokannat eivät pysty käsittelemään puolustuksen dataa mittakaavassa

Relaatiotietokannat on suunniteltu strukturoituihin, hyvin määriteltyihin skeemoihin. Ne loistavat transaktionaalisissa työkuormissa — tietueiden luomisessa, lukemisessa, päivittämisessä ja poistamisessa vahvoilla johdonmukaisuustakuilla. Suurin osa puolustuksen sensoridatasta ei ole mitään näistä. Se saapuu heterogeenisissa muodoissa: CoT XML maajoukoilta, binaariset tutkan raitaliedostot, pakattu video UAV-syötteistä, JSON ohjelmistoradioputkistoista, PDF-tiedusteluraportit ja äänitranskriptit viestinnänvalvonnasta. Kaiken tämän pakottaminen normalisoituun relaatioskeemaan ei ole ainoastaan operatiivisesti epäkäytännöllistä — se tuhoaa raakafideliteetin, johon analyytikot joskus tarvitsevat paluun.

NoSQL-tietokannat ratkaisevat skeemaongelman, mutta tuovat mukanaan uusia: useimpia ei ole suunniteltu analyyttisiin kyselymalleihin, joita tiedustelutyö vaatii (koko taulukon skannaukset, aggregoinnit miljoonien tietueiden yli, vektorisamankaltaisuushaut dokumenttipisteiden yli). Aikasarjatietokannat käsittelevät korkeataajuisia sensorivirtoja hyvin, mutta romahtavat ad-hoc-analyyttisten liitosten alla. Puolustuksen data lake -malli käsittelee kaikki nämä puutteet erottamalla syöttö-, tallennus- ja kyselynäkökulmat itsenäisesti skaalautuviin kerroksiin.

Syöttökerros: suoratoisto verrattuna eräkäsittelyyn

Syöttökerros on paikka, jossa raakadata syötetään lakeeseen. Kaksi erillistä mallia hallitsee puolustusympäristöjä, ja tuotantolake tarvitsee molemmat.

Suoratoistosyöttö

Reaaliaikaiset sensorisyötteet — sijaintiraportit, tutkan raidat, signaalitiedustelun hälytykset, chat-viestit, videoanalytiikkatapahtumat — saapuvat jatkuvasti ja ne on syötettävä pienellä viiveellä. Apache Kafka on hallitseva avoimen lähdekoodin valinta paikallisiin ja ilmaraollisiin ympäristöihin. Kafka-aiheet vastaavat luontaisesti tietolähteitä: yksi aihe per sensorityyppi tai syöte. Aiheen tason pääsynhallintaluettelot (ACL) tarjoavat ensimmäisen luokittelun pakottamislinjan — salainen-luokiteltu sensorisyöte päätyy salainen-luokiteltuun aiheeseen, ja vain sopivat tunnistetiedot omaavat kuluttajat voivat tilata sen.

Hybridi- tai pilviyhdistetyissä käyttöönotoissa Azure Event Hubs tarjoaa Kafka-yhteensopivan API-pinnan, jossa on natiivi integraatio Azure Data Lake Storage Gen2:een ja Azure Synapse Analyticsiin. Event Hubs Capture kirjoittaa saapuvat tapahtumat suoraan ADLS Gen2:een Avro- tai Parquet-muodossa, elimoimalla erillisen kuluttajaprosessin raakalaskeutumisalueelle. Operatiivinen rasitus on huomattavasti pienempi kuin itse hallitussa Kafkassa, mutta hintana on heikennetty hallinta aiheen tason pääsykäytäntöihin.

Skeemarekisterit — joko Confluent Schema Registry (Kafkalle) tai Azure Schema Registry — tulisi olla pakollisia suoratoistosyöttöön. Skeemojen rekisteröinti syöttöpisteessä estää vääränmuotoisia viestejä leviämästä alavirtaan ja tarjoaa versioidun sopimuksen skeeman kehitykselle. Sensorin laiteohjelmistopäivitys, joka muuttaa kenttänimen tai lisää uusia telemetriakenttiä, ei saisi koskaan äänettömästi rikkoa alavirtaan tapahtuvaa analytiikkaa.

Eräsyöttö

Kaikki puolustuksen data ei saavu reaaliajassa. Päivittäiset tiedustelutietoyhteenvetodumppit, arkistoidut signaaliäänitteet, historialliset rattatietokannat ja liittolaisjärjestelmistä tuodut tiedot saapuvat tyypillisesti bulkiksi siirtoina määritellyn aikataulun mukaisesti. Eräsyöttöputkistot ovat yksinkertaisempia kuin suoratoistokutkistot, mutta niillä on omat haasteensa: tiedostot voivat saapua vanhoissa muodoissa (NITF-kuvat, STANAG 4607 GMTI, CSV-viennit vanhentuneista C2-järjestelmistä), ja tiedostojen koot voivat vaihdella kilotavuista satoihin gigatavuihin siirtoa kohden.

Vankka eräsyöttökerros tarvitsee muodon tunnistamisen ja validoinnin syöttöpisteessä, tarkistussummaverifikaation siirron eheyden varmistamiseksi ja kuolleenkirjeen polun tiedostoille, jotka epäonnistuvat validoinnissa. Syötön tulisi olla idempotentista — saman erätyön ajaminen kahdesti ei saisi duplikoida tietueita strukturoituun vyöhykkeeseen. Delta Laken transaktioloki tekee idempotenteista eräsyötöistä suoraviivaisia: kirjoitustyöt tarkistavat transaktiolokin ennen liittämistä, ja duplikaattien tunnistus voidaan toteuttaa deterministisellä riviavaimella, joka on johdettu lähdejärjestelmätunnisteista ja aikaleimoista.

Tallennuskerros: laskeutumisalueelta strukturoituun vyöhykkeeseen

Puolustuksen data lake käyttää monivyöhykeistä tallennusmallia. Data liikkuu vyöhykkeiden läpi sitä mukaa kuin se validoidaan, muunnetaan ja asetetaan saataville analyysejä varten.

Raakalaskeutumisalue

Raakalaskeutumisalue on kaiken saapuvan datan ensimmäinen kohde — suoratoistotapahtumat kirjoitetaan Avro- tai JSON-rivitiedostoina, eräsiirrot tallennetaan alkuperäisessä muodossaan. Mitään ei muokata täällä. Laskeutumisalue on forensinen tietue: jos käsittelyvirhe korruptoi alavirtaan olevan tietojoukon, raakalaskeutumisalue on palautuspiste. Tallennus on S3-yhteensopivaa objektitallennusta — AWS S3, Azure Data Lake Storage Gen2, MinIO paikallisiin ilmaraollisiin käyttöönottotilanteisiin tai Ceph laajamittaiseen paikalliseen objektitallennukseen.

Laskeutumisalueen objektit nimetään deterministisellä avainrakenteella, joka koodaa lähdejärjestelmän, luokittelutason, tietotyypin ja saapumisajan. Nimeämiskäytäntö kuten raw/{luokittelu}/{lähde}/{vuosi}/{kuukausi}/{päivä}/{tunti}/{uuid}.{ext} antaa muunnosputkistolle luotettavan osioinnin rakenteen ja mahdollistaa tietyn aikaikkunan uudelleenkäsittelyn yhdelle lähteelle koskematta liittymättömään dataan.

Strukturoitu vyöhyke: Parquet ja Delta Lake

Strukturoitu vyöhyke on paikka, jossa raakadata muunnetaan muotoon, jota analyyttiset moottorit voivat kysyä tehokkaasti. Nykyinen standardi on sarakkeelliset Parquet-tiedostot, joita hallitaan Delta Lake- tai Apache Iceberg -taulukkomuotolayerillä. Parquetin sarakkeinen rakenne vähentää dramaattisesti I/O:ta analyyttisille kyselyille, jotka käyttävät vain osaa kentistä — mikä on normi tiedusteluanalyysissa. Kysely kaikille ilmaradoille 50 km säteellä kuuden tunnin aikaikkunassa tarvitsee vain leveysaste-, pituusaste-, korkeus-, aikaleima- ja rattatunnus-sarakkeet, ei koko 80-kenttäistä sensoriskeemaa.

Delta Lake lisää neljä ominaisuutta, jotka ovat kriittisiä luokitellussa ympäristössä. Ensinnäkin ACID-transaktiot varmistavat, että useiden Spark-töiden samanaikaiset kirjoitukset eivät tuota osittaisia tai korruptoituneita tietojoukkoja. Toiseksi transaktioloki tarjoaa täydellisen historian jokaisesta kirjoitus-, päivitys- ja poistooperaatiosta — vaatimus datan alkuperälle luokitelluissa järjestelmissä. Kolmanneksi aikamatkailukyselyt mahdollistavat analyytikkojen rekonstruoida tietojoukon tilan missä tahansa menneessä ajankohdassa, mikä tukee sekä forensista analyysia että jälkitoimintakatsauksia. Neljänneksi skeeman pakottaminen estää alavirtaan tapahtuvat syöttövirheet kirjoittamasta äänettömästi vääränmuotoisia tietueita tuotantotaulukkoon.

Luokittelueristys

Luokittelurajat on pakotettava tallennuskerroksessa, ei pelkästään sovelluskerroksessa. Jokainen luokittelutaso (Luokittelematon, Kontrolloitu luokittelematon tieto, Luottamuksellinen, Salainen, Erittäin salainen/SCI) vaatii fyysisesti erilliset tallennusämpärit tai nimiavaruudet. Jaetut ämpärit polkupohjaisella erottelulla eivät riitä — väärin konfiguroitu IAM-käytäntö tai ohjelmistovika pääsynhallinnan kerroksessa voi paljastaa ristiin luokiteltua dataa, jos objektit jakavat saman ämpärin.

Jokainen luokittelutaso käyttää erillistä datansalausavainta (DEK), jota hallitaan laitteistoturvayksikön (HSM) tai FIPS 140-2 Level 3 -sertifioidun avaintenhallintapalvelun avulla. Salaus sovelletaan palvelinpuolella tallennuskerroksessa, jotta edes tallennusmedian poistaminen ei paljasta selkotekstiä. Avaintenkiertoaikataulut on määritelty luokittelutasoittain, ja niiden on oltava automaattisia — manuaalinen avaintenkierto luokiteltuun dataan vaadittavalla taajuudella on operatiivisesti epäkäytännöllistä.

Datakataloogi ja luokittelun pakottaminen

Data lake ilman kataloogia on dataneva. Puolustuksen analyytikkojen on löydettävä mitä tietojoukkoja on olemassa, mitä ne sisältävät, milloin niitä on viimeksi päivitetty ja mitä luokittelutasoa ne kantavat — ennen kuin lähetetään kysely, joka saattaa tahattomasti pyytää dataa yli heidän turvalupatasonsa. Metatietokatalogikäytäntö toimii laken sisällön hakemistona.

Apache Atlas (yleisesti käytetty Hadoop-ekosysteemipinon kanssa) ja AWS Glue Data Catalog (pilvi- tai hybridikäyttöönottoja varten) ovat kaksi laajimmin käytettyä vaihtoehtoa. Molemmat tukevat skeeman rekisteröintiä, alkuperäseurantaa ja mukautettuja metatietomääritteitä. Luokittelutason tulisi olla pakollinen skeemamäärite — ei valinnainen tunniste — jotta jokaisella tietojoukon merkinnällä kataloogissa on eksplisiittinen luokittelumerkintä, jonka kyselykerros voi pakottaa.

Katalogin näkyvyyden tulisi itsessään noudattaa pääsykäytäntöä: salaiselle tasolle turvaluvan omaava analyytikko ei saisi pystyä selaamaan erittäin salaisten tietojoukkojen kataloogimerkintöjä, vaikka hän ei voisikaan kysyä pohjana olevaa dataa. Tämä edellyttää katalogin valtuutuskerroksen integroimista organisaation identiteetintarjoajaan (Active Directory, LDAP tai SAML-yhteensopiva IdP). Jokainen katalogin käyttötapahtuma on kirjattava keskitettyyn auditointikokoajaan kyselytapahtumien rinnalle.

Kyselykerros: SQL, eräanalytiikka ja vektorihaku

Kyselykerros on paikka, jossa analyytikot ja alavirtaan olevat järjestelmät kuluttavat dataa lakesta. Tuotantopuolustuksen data lake tarvitsee vähintään kolme kyselymuotoa.

Ad-hoc SQL Trinolla

Trino (aiemmin PrestoSQL) on standardivalinta ad-hoc SQL-kyselyihin suurten Parquet- tai Delta Lake -tietojoukkojen yli. Trinon yhdistinarkkitehtuuri mahdollistaa yhden kyselyn liittää dataa useista lähteistä — Delta Laken strukturoitu vyöhyke, live PostgreSQL -operatiivinen tietokanta ja Elasticsearch-indeksi — yhdessä SQL-lauseessa. Puolustuksen analytiikan kannalta tämä tarkoittaa, että analyytikko voi kirjoittaa kyselyn, joka korreloi laken historiallisen raitatiedon live-kontaktiraportteihin operatiivisesta kuvasta ilman datan vientiä järjestelmien välillä.

Trinon pääsynhallinnan kerros tukee rivityötason suodatusta ja saraketason peittämistä yhdistintason käytäntöjen kautta. Rivisuodatin voi rajoittaa kyselyn vain niihin tietueisiin, jotka vastaavat analyytikon valtuutettua maantieteellistä vastuualuetta. Saraketason peittäminen voi peittää arkaluonteiset kentät — lähdejärjestelmätunnisteet, keräysmenetelmäkoodit — analyytikkojen turvaluvan ulkopuolelle jäävälle metatiedolle. Kaikki kyselytapahtumat kirjataan auditointikokoajaan, joka tallentaa kyselytekstin, todennetun käyttäjän henkilöllisyyden, käytetyt taulukot ja palautetun datan luokittelutason.

Laajamittainen eräanalytiikka Sparkilla

Jotkin tiedusteluanalyysitehtävät ovat liian suuria interaktiiviselle SQL:lle. Elintapa-analyysi kuuden kuukauden sijaintidatan yli, signaalitiedustelun korrelointi maaliikkeen kanssa koko teatterin tasolla tai koneoppimismallin koulutus merkityillä raitatiedoilla vaativat kaikki hajautettua eräkäsittelyä. Apache Spark YARN- tai Kubernetes-klusterilla on näiden työkuormien standardimoottori.

Spark integroituu natiivisti Delta Laken kanssa ja voi lukea Parquetia suoraan S3-yhteensopivasta tallennuksesta. Luokiteltuihin ympäristöihin Spark-töiden tulisi ajaa luokittelutason mukaan eriytetyissä klustereissa tai nimiavaruuksissa, jotta salainen-tason työ ei vahingossa viittaa luokittelemattomaan tietojoukkoon väärin konfiguroituun polkumuuttujaan. Töiden suoritus tulisi kirjata samalla auditointitarkkuudella kuin interaktiiviset kyselyt: työn omistaja, syöttötietojoukkojen luokittelutaso, tulostietojoukkojen luokittelutaso ja suoritusaikaleima.

Vektorihaku tiedusteludokumenteille

Strukturoimattomat tiedusteludokumentit — raportit, transkriptit, käännetyt viestintäsisällöt — eivät sovi hyvin SQL-kyselymalleihin. Analyytikot tarvitsevat semanttista hakua: löydä kaikki raportit, jotka käsittelevät huoltoreittihäiriöitä tämän ruudukkoviitteen lähellä, ei LIKE-kyselyä. Kielimallin tuottamat vektoriupotukset, jotka tallennetaan vektoritietokantaan (pgvector PostgreSQL:ssa tai Qdrant paikalliseen käyttöönottoon), mahdollistavat tämäntyyppisen semanttisen haun.

Vektorihaun kerroksen on noudatettava luokittelurajoja samalla tavoin kuin SQL- ja Spark-kerrosten. Upotuksen luomisputkistojen tulisi ajaa lähdedokumenttien luokittelutasolla, ja tuloksena olevat vektori-indeksit tulisi eriyttää luokittelutasoittain. Ristiin luokiteltu semanttinen haku vaatii eksplisiittisen risteävienalueiden ratkaisun (CDS) arkkitehtuuriarvioinnin eikä ole oletusominaisuus.

Säilytys, tuhoaminen ja auditointiketju

Puolustuksen data lakessa oleva data ei kerry loputtomiin. Luokittelulähtöiset säilytyskäytännöt määrittelevät, kuinka kauan kutakin datatyyppiä pidetään kullakin luokittelutasolla. Operatiivisella sensoridatalla voi olla 90 päivän säilytys salaisella tasolla; strategisia tiedustelutietoja voidaan säilyttää 10 vuotta. Säilytyskäytännöt on määritelty käytäntörekisterissä ja pakotettu automaattisilla elinkaarenhallintatehtävillä, jotka ajetaan määritellyllä aikataululla.

Luokiteltujen tietojen turvallinen poistaminen ei voi tukeutua tavalliseen tiedostojärjestelmän poistamiseen tai objektin vanhenemiseen. Tavallinen poistaminen merkitsee tallennuslohkot uudelleenkäytettäviksi, mutta ei ylikirjoita niitä. Luokitellun datan osalta vaadittu lähestymistapa on kryptografinen tuhoaminen, kutsutaan myös avainten hävittämiseksi: jokainen luokittelutaso käyttää erillistä DEK:iä, ja kun säilytyskäytäntö käynnistää poistamisen, DEK kierretään ja edellinen avainversio tuhotaan. Ilman DEK:iä tallennettu salateksti on laskennallisesti erottamaton satunnaisesta kohinasta.

Jokaisen tuhoamistapahtuman on tuotettava muuttumaton auditointilokin merkintä. Auditointimerkinnän on tallennettava tuhotut objektiavaimet tai osiotunnisteet, tuhoamisen käynnistänyt säilytyskäytäntö, avainten tuhoamisaikaleima sekä operaation valtuuttaneen automaattisen tai inhimillisen toimijan henkilöllisyys. Auditointiloki itsessään on tallennettava kerran kirjoitettavassa, väärinkäytöstä todistavassa konfiguraatiossa.

Operatiiviset näkökohdat

Ilmaraon yhteensopivuus: kaikkien komponenttien on oltava käyttöönotettavissa paikallisista pakettipeilistä ja konttinrekistereistä. Skeeman kehityksen hallinta: sensorin laiteohjelmistopäivitykset ja muuttuvat raportointivaatimukset muuttavat skeemoja ajan myötä, ja sekä Delta Laken skeeman pakottamisen hallintaominaisuudet että muutoksenhallintaprosessi ovat molemmat vaadittavia. Suorituskyvyn seuranta luokittelutasoittain: kyselysuorituskyky voi erota merkittävästi tasojen välillä, ja tasokohtainen kapasiteetin suunnittelu vaatii tasokohtaisia käyttömittareita.