Sotilaallinen datajärvi ja kaupallinen datajärvi jakavat saman ydinajatuksen — halpa, skaalautuva objektitallennus analytiikan perustana — mutta ne erottuvat terävästi jokaisessa operatiivisesti merkityksellisessä rajoitteessa. Turvallisuusluokan valvonta, osastotietoinen käyttö, erillään toimiminen ja elintärkeät kysely-SLA:t eivät ole lisäominaisuuksia puolustuksen käyttöönotoille; ne ovat kantavia vaatimuksia, jotka muotoilevat jokaisen arkkitehtuurikerroksen tallennuskorien nimikäytännöstä kyselymoottorin kokoonpanoon. Arkkitehtuuri, joka kohtelee niitä jälkikäteen tehtyinä — lisäämällä turvallisuusluokkamerkinnän olemassa oleviin kaupallisiin datajärven kaavoihin — epäonnistuu turvallisuusauditoinneissa parhaimmillaan ja tuottaa vaatimusyhteensopivuusrikkomuksia pahimmillaan.

Tämä artikkeli käy läpi tuotantotason sotilaallisen datajärven täydellisen suunnittelun: tallennuskerroksen, keräysputken C2-, ISR- ja logistiikkalähteistä, sotilaallisen datakatalogin metatietojenhallinnan, osastojakoisen käyttöoikeudenhallinnan ja analytiikan työkuormien kaavat. Jokainen osio käsittelee suunnittelupäätöksiä, jotka erottavat operatiivisesti käyttöön otettavan järjestelmän referenssiarkkitehtuurista, joka näyttää oikealta valkoisessa kirjassa mutta murtuu koskettaessaan todellista salastettua dataa.

Mitä sotilaallisen datajärven on tehtävä, mitä kaupallinen datajärvi ei tee — turvallisuusluokan valvonta, osastotietoinen käyttö, erillään toimiminen, elintärkeät SLA:t

Perustavin ero kaupallisen ja sotilaallisen datajärven välillä ei ole teknologian valinta — se on uhkamalli. Kaupallinen datajärvi suojaa ulkoisia hyökkääjiä ja sisäisiä dataeksfiltrointeja vastaan. Sotilaallisen datajärven on myös suojattava hienovaraisemmalta virheeltä: oikeutettu käyttäjä käyttää dataa, johon hänellä on turvallisuusvaltuus mutta johon hänellä ei ole oikeutta nykyisessä kontekstissa. Signaalianalytikolla, jolla on erittäin salainen turvallisuusvaltuus, ei saa olla mahdollisuutta kysellä osastojakoista HUMINT-datasarjaa, ellei hänellä ole tiettyä osastokoodia. Logistiikkaupseerilla, jolla on salainen turvallisuusvaltuus, ei saa olla mahdollisuutta nähdä ISR-tiedustelutietoa, vaikka se olisi myös luokiteltu salaiseksi. Turvallisuustaso ja osastojäsenyys ovat ortogonaalisia käyttöoikeusulottuvuuksia, ja molemmat on valvottava jokaisessa järjestelmän kerroksessa.

Erillään toimiminen poistaa jokaisen pilvipohjaisen palvelun riippuvuuden. Ei hallittua Kafkaa, ei pilvipohjaista katalogia, ei toimittajan ylläpitämää avainhallintapalvelua. Jokaisen komponentin — objektitallennuksen, suoratoistovälittimen, kyselymoottorin, metatietoluettelon, avainhallintalaitteiston — on oltava käyttöön otettavissa paikallisesti paketeista, jotka voidaan siirtää erillään toimivaan ympäristöön hyväksyttyjen medioiden kautta. Tämä rajoite poistaa arkkitehtuurit, jotka olettavat internet-yhteydellä saavutettavat päivityspisteet, lisenssinvahvistuspalvelimet tai telemetrian keräyspalvelut. Se tarkoittaa myös, että operaatiotiimi omistaa jokaisen komponentin täyden päivitys- ja korjauselinkaaren ilman toimittajan ylläpitämää polkua.

Elintärkeät SLA:t koskevat sekä datan tuoreutta että kyselyviivettä. ISR-fuusioanalytikko, joka kysyy viimeisintä sensorikeräystä, ei voi hyväksyä useiden tuntien Spark-erätyöikkunaa. Logistiikkaupseeri, joka rakentaa uudelleenhuolto-mallia, tarvitsee kyselytuloksia minuuteissa, ei päivissä. Nämä vaatimukset pakottavat arkkitehtuurivalintoihin, jotka kaupalliset datajärvet usein lykkäävät: pysyvät kyselymoottorit, jotka ovat jo kääntäneet kyselysuunnitelmat ajan tasaisilla katalogitilastoilla, kuuma taso tuoreelle datalle ja suoratoistokeräys, joka tekee uudesta datasta kyseltävän sekunneissa vastaanotosta — ei seuraavassa eräikkunassa. Syvällisempään taustatietoon tässä kuvatuissa kerroksissa käytetyistä peruskaavoista katso opastamme puolustusalan dataintegraatiokaavoista.

Neljäs vaatimus, jota kaupalliset datajärvet myös alipalvelevat, on monialuedataintegraatio — C2-seurantadatan, ISR-sensoridatan, logistiikkatietueiden ja paikkatietoreferenssikerrosten yhdistäminen yhteen kyselyyn turvallisuusluokkien rajojen yli (asianmukaisilla säätimillä). Kaupallisessa datajärvessä alueiden väliset yhdistämiset ovat datatekniikan kätevyys. Sotilaallisessa datajärvessä ne ovat ensisijainen analytiikkakäyttötarkoitus — ja niiden on oltava mahdollisia ilman turvallisuusluokan valvonnan höllentämistä. Kyselymoottorin on kyettävä yhdistämään taulukoita eri data-alueilta soveltaen samanaikaisesti taulukohtaisia turvallisuussuodattimia läpinäkyvästi yhdistämisen kummallekin puolelle.

Tallennuskerroksen suunnittelu — objektitallennus (MinIO/Ceph paikalliselle), porrastettu tallennus (kuuma/lämmin/kylmä), objektien nimintä ja ositus sotilaallisille data-alueille

Objektitallennus on jokaisen modernin datajärven arkkitehtuurin perusta, ja erillään toimiville sotilaskäyttöönotoille valinta kapenee kahteen tuotantokokemuksen omaavaan alustaan: MinIO ja Ceph. MinIO toteuttaa koko AWS S3 -API:n AES-256-levynsalausilla, korikohtaisilla IAM-käytännöillä ja objektitasoisen versioinnin ja lukituksen — kaiken ilman pilviriippuvuutta. Sen suorituskyky modernissa NVMe-laitteistossa ylittää kaupallisen pilven objektitallennuksen peräkkäisissä kirjoitustyökuorissa, joka on hallitseva kaava sensoridatan keräykselle. Ceph tarjoaa objekti-, lohko- ja tiedostotallennuksen yhdestä klusterista RADOS Gatewayn kautta, mikä tekee siitä sopivan ympäristöihin, joissa saman fyysisen tallennusinfrastruktuurin on palveltava sekä datajärven objekti-työkuormaa että lohkovolyymejä virtuaalikoneille. Omistetulle datajärven käyttöönotolle MinIO on operatiivisesti yksinkertaisempaa; Ceph on oikea valinta, kun tallennusklusterin on palveltava myös lohko- ja tiedostorajapintoja.

Turvallisuuseristys toteutetaan koritasolla, ei objektitasolla. Jokaisella turvallisuusluokalla on oma korinimiavaruutensa:

# Bucket namespace by classification tier datalake-u-raw/ # Unclassified — raw landing zone datalake-u-structured/ # Unclassified — normalized Parquet/Delta datalake-u-curated/ # Unclassified — analyst-ready aggregates datalake-c-raw/ # Confidential datalake-c-structured/ datalake-c-curated/ datalake-s-raw/ # Secret datalake-s-structured/ datalake-s-curated/ datalake-ts-raw/ # Top Secret datalake-ts-structured/ datalake-ts-curated/ # Each bucket namespace uses a separate DEK stored in HSM # MinIO per-bucket KMS key configuration assigns the appropriate DEK

Vyöhykerakenne — raaka, strukturoitu, kuratoitu — jakaa datan käsittelyvaiheen mukaan jokaisessa turvallisuusluokassa. Raaka vyöhyke pitää datan täsmälleen kuten lähteistä vastaanotettuna, natiivissa muodossa (CoT XML, NIEM XML, binäärisensorivirrat, CSV-logistiikkaviennit). Mitään raa’assa vyöhykkeessä ei muuteta kirjoituksen jälkeen; se on muuttamaton auditointitietue siitä, mitä vastaanotettiin. Strukturoitu vyöhyke pitää datan normalisoinnin jälkeen Parquet-muotoon Delta Lake -taulukkomuodolla — skeema pakotettu, kentät kuvattu kanonisiin nimiin, alkuperäismetatieto liitetty. Kuratoitu vyöhyke pitää analytikoille valmiita aggregaatioita, esitäytettyjä monialuenäkymiä ja yhteenvetotaulukoita, jotka mahdollistavat nopeat interaktiiviset kyselyt ilman, että jokaisen analytikon on suoritettava sama yhdistämislogiikka itsenäisesti.

Strukturoidun vyöhykkeen objektiavainkäytäntö koodaa kaikki ositusulottuvuudet, joita tarvitaan tehokkaaseen kyselyn työntämiseen:

# Structured zone object key convention # {domain}/{source_system}/{year}/{month}/{day}/{hour}/{uuid}.parquet # Examples: c2/cotstreamer-alpha/2026/06/25/14/a3f82c11-....parquet isr/uav-sensor-bravo/2026/06/25/14/b91d4e7a-....parquet logistics/erp-export-charlie/2026/06/25/00/c5a21b3f-....parquet sigint/elint-delta/2026/06/25/14/d2f09c88-....parquet # Delta Lake table registration in Hive Metastore: # TABLE: c2.cot_events LOCATION: s3a://datalake-s-structured/c2/cotstreamer-alpha/ # PARTITIONED BY: year, month, day, hour # FORMAT: DELTA

Porrastettua tallennusta hallitaan MinIO:n elinkaarisääntöjen kautta. Kuuma taso käyttää NVMe-pohjaisia solmuja ja pitää dataa viimeiseltä 30 päivältä — riittävän tuoreena, että analytikot kysylevät sitä usein nykyiseen operatiiviseen analyysiin. 30 päivän jälkeen objektit siirtyvät lämpimään tasoon suuritiheyksisellä magneettilevyllä, missä ne pysyvät kyseltävinä mutta suuremmalla viiveellä. 180 päivän jälkeen objektit siirtyvät kylmään tasoon suuritiheyksisellä arkistotallennuksella, jossa on säädetävissä oleva hakoviive. Taso-kynnykset ovat säädetävissä alueen ja turvallisuustason mukaan — ISR-sensoridata aktiivisilta operatiivisilta alueilta voi olla lyhyempi lämpimästä kylmään siirtymä kuin logistiikka-arkistodata.

Keräysputken arkkitehtuuri — C2-järjestelmän syötteet (CoT/NIEM), ISR-sensoridatan keräys, logistiikkajärjestelmän ETL, suoratoisto vs eräkeräyksen kaavat

Keräyskerroksen on käsiteltävä kolmea perustavanlaatuisesti erilaista datan nopeusprofiilia samanaikaisesti: nopeita suoratoistosyötteitä C2- ja ISR-järjestelmiltä, jotka tuottavat tuhansia tapahtumia minuutissa; keskinopeita strukturoituja syötteitä logistiikka- ja suunnittelujärjestelmiltä, jotka tuottavat satoja tietueita tunnissa; ja hitaita erävientejä vanhentuneista järjestelmistä, jotka toimittavat päivittäisiä tai viikoittaisia tiedostodumppuja. Nämä profiilit vaativat erilaisia keräyskaavoja, joiden on toimittava saumattomasti yhdessä laskeutumisalueen rajalla.

Apache Kafka on suoratoiston selkäranka reaaliaikaisille syötteille. Aiheiden suunnittelu noudattaa samaa turvallisuusluokan mukaista käytäntöä kuin tallennus — jokaiseen aiheeseen liitetään etuliite turvallisuustasosta, ja Kafka ACL:t rajoittavat tuottajan ja kuluttajan käyttöoikeuden turvallisuusluokan mukaan. Aiheen nimikäytäntö koodaa lähdetyypin ja järjestelmän identiteetin:

# Kafka topic naming: {classification}.{domain}.{source_system}.{format} s.c2.cotstreamer-alpha.cot-xml s.isr.uav-sensor-bravo.protobuf s.isr.elint-delta.avro c.logistics.erp-charlie.avro # Normalized fusion topics (post-adapter, canonical schema) s.ingest.c2.normalized s.ingest.isr.normalized s.ingest.logistics.normalized # Dead-letter queues for schema validation failures s.dlq.c2.schema-violations s.dlq.isr.schema-violations

CoT/NIEM-sovituspalvelut tilaavat raakoja C2-aiheita, jäsentävät XML:n, kuvavat kentät kanoniseen keräysskeemaan, liittävät alkuperäismetadatan (lähdejärjestelmän tunnus, keräysaikaleima, turvallisuustaso, alkuperäinen yksikkö) ja julkaisevat normalisoituun aiheeseen. CoT-jäsennyksen on käsiteltävä sekä vakiomuotoisia CoT-kenttiä että Detail-elementin laajennuksia, joita tietyt C2-järjestelmät käyttävät — sovittimen ei saa hiljaisesti pudottaa laajennussisältöä; sen on joko kuvattava tunnetut laajennukset kanonisiin kenttiin tai säilytettävä ne strukturoidussa laajennussarakkeessa. NIEM-sovitukset käsittelevät huomattavasti monimutkaisempia skeemoja — NIEM:n modulaarinen suunnittelu tarkoittaa, että NIEM-vaihtoinstanssi voi viitata tyyppeihin useista NIEM-ydin- ja alueskeemoista, ja sovittimen on ratkaistava kaikki viittaukset ennen kenttäkuvausta. Sovitin tuottaa tasotetun rivi-raportti-rakenteen, joka sopii Parquet-tallennukseen.

ISR-sensorien keräys vaihtelee sensorityypin mukaan. UAV-videoanalytiikan syötteet tuottavat havaitsemistapahtumatietueita — rajauslaatikko, havaintoluokka, luottamuspiste, kehyksen aikaleima, sensorin sijainti — nopeuksilla, jotka voivat ylittää 10 000 tietuetta minuutissa monivirralta alustalla. Nämä on kerättävä Kafkan kautta Avro- tai Protobuf-skeeman pakotuksella tuottajan puolella, ei vain kuluttajan puolella. SIGINT-vastaanottimet tuottavat emitterin sieppaustietueita, joissa on taajuus, modulaatio, pulssiparametrit, suunta ja TDOA-data. Tutkasyötteet tuottavat seurantaraportteja, joissa on sijainti, nopeus ja seurannan laatumittarit. Jokaisella sensorityypillä on omistettu sovin, joka normalisoi sen natiivin muodon kanoniseksi ISR-havaintoskeemaksi ennen kuin tietue saavuttaa laskeutumisalueen. Syvälliseen käsittelyyn reaaliaikaisesta tiedustelufuusioarkkitehtuurista katso täydentävä artikkelimme monilähteisestä virtauskäsittelystä.

Logistiikan ETL toimii tyypillisesti erätilassa — useimmat logistiikan ERP-järjestelmät tuottavat säännöllisiä vientejä eivätkä reaaliaikaisia muutosvirtoja. ETL-putki poimii datan lähdejärjestelmän vientirajapinnasta (SFTP-tiedoston pudotus, tietokantakysely tai REST API -haku), validoii skeeman, soveltaa kenttäkuvausta kanoniseen logistiikkaskeemaan ja kirjoittaat Parquet-tiedostot raa’alle laskeutumisalueelle. Spark-työ käsittelee sitten raa’at tiedostot strukturoiduksi vyöhykkeeksi aikataululla, joka on synkronoitu lähdejärjestelmän vientitahtiin. Logistiikkajärjestelmille, jotka tukevat muutosdatan kaappausta (CDC) tietokannan lokivirran kautta, suoratoistopolku on suositeltava — se vähentää ajan logistiikkatapahtuman ja sen analytiikkakyselyihin saatavuuden välillä tunneista minuutteihin.

Datan laadun validointi keräysvaiheessa ei ole valinnaista — se on mekanismi, joka estää virheellisen datan pääsyn strukturoituun vyöhykkeeseen ja analytiikan turmelemisen. Jokaisen keräyssovitimen on suoritettava vähintään: skeeman yhteensopivuusvalidointi, alkuperätietojen täydellisyystarkistukset, ajalliset järkevyystarkistukset (tapahtumien aikaleimat uskottavissa rajoissa) ja paikkatiedon datalle koordinaattialueen validointi. Validointivirheet reitetään kuollut kirje -jonoon, jossa on koko alkuperäinen viestirunko ja strukturoitu virhetietue, joka tunnistaa epäonnistuneen tarkistuksen.

Metatietoluettelo ja datan löytäminen — turvallisuus- ja varausmerkinnät metatiedoissa, skeemarekisteri, datan linjan seuranta, analytikoiden haku- ja löytämis-UX

Metatietoluettelo on komponentti, joka tekee datajärvestä käytettävän analytikoille, jotka eivät rakentaneet sitä. Ilman katalogia datajärvi on kokoelma läpinäkyviä Parquet-tiedostoja objektitallennuksessa, joita vain keräyssovitimet kirjoittaneet insinöörit osaavat kysellä. Hyvin täytetyn katalogin avulla jokainen asianmukaisen turvallisuusvaltuuden omaava analytikko voi löytää saatavilla olevat datasarjat, ymmärtää niiden skeemat ja alkuperätiedot ja rakentaa kyselyjä niitä vastaan — ilman teknisen tuen vaatimusta jokaiselle uudelle analyysikysymykselle. Sotilaallisen datakatalogin metatietojenhallinnan opas kattaa katalogin suunnittelun yksityiskohtaisesti; tämä osio käsittelee sen integrointia datajärven arkkitehtuuriin.

Apache Atlas on tuotantokokemuksen omaava avoimen lähdekoodin katalogi ympäristöihin, jotka vaativat laajennettavia metatietotyyppejä, linjan seurantaa ja integraatiota Hadoop-ekosysteemin työkaluihin. Atlas-tyyppijärjestelmä antaa mahdollisuuden määrittää räätälöityjä metatietoentiteettityyppejä ensisijaisina skeemaobjekteina — eivätkä vapaatekstihuomautuksina — mikä on olennaista puolustusalan erityiskentille, joiden on oltava pakollisia datasarjan rekisteröintihetkellä:

  • ClassificationLevel — lueteltu tyyppi: UNCLASSIFIED, CONFIDENTIAL, SECRET, TOP_SECRET. Pakollinen jokaisessa datasarjaentiteetissä. Ohjaa tallennuskorin reititystä ja käyttöoikeudenhallinnan käytäntöarviointia.
  • CaveatCodes — moniarvoinen merkkijonoluettelo. Tallentaa sovellettavat varaukset, kuten NOFORN, osastotunnukset ja käsittelyohjeet. Täytettävä keräyksessä tai jätettävä tyhjäksi nimenomaisena ilmoituksena — null ei ole sallittu.
  • DataOwnerUnit — merkkijonoviittaus organisaatioyksikköön, joka vastaa datasarjasta. Käytetään datan omistajuuden reititykseen ja yhteyshenkilön määrittämiseen datahakemuksille.
  • RetentionPolicy — viittaus sovellettavaan säilytyssääntöön, joka määrittää maksimisäilytysajan, turvallisen poistomenettelyn ja valtuutuksen, joka hyväksyi säilytysjakson.
  • OriginatingSystem — lähdejärjestelmän tunniste, joka tuotti datan. Käytetään linjan jäljittämiseen ja data-laatuongelmien reitittämiseen takaisin lähdejärjestelmän operaattorille.

Skeemarekisterin integrointi Apache Kafkan kanssa varmistaa, että jokaisen aiheen skeema on rekisteröity ja versioitu ennen kuin mikään tuottaja aloittaa kirjoittamisen. Confluent Schema Registry (käyttöön otettavissa paikallisesti ilman pilviyhteyttä) pakottaa Avro- tai Protobuf-skeeman yhteensopivuussäännöt — BACKWARD-yhteensopivuus kuluttajan puolen aiheille tarkoittaa, että uudet skeemaversiot voivat lisätä valinnaisia kenttiä rikkomatta olemassa olevia kuluttajia. Jokainen skeemaversio on linkitetty Atlas-katalogi-entiteetistä vastaavaan datasarjaan, mikä tarjoaa täydellisen historian siitä, miten datasarjan rakenne on kehittynyt ajan myötä.

Datan linjan seuranta Atlasissa tallentaa muunnosketjun raa’asta keräyksestä kuratoituun analytiikkataulukkoon. Sparkin Atlas-koukku lähettää automaattisesti linjatapahtumia, kun Spark-työ lukee yhdestä Atlas-rekisteröidystä datasarjasta ja kirjoittaa toiseen. Trinon Atlas-integraatio vaatii räätälöidyn tapahtumakuuntelijan, joka tallentaa, mitkä lähdeaulukot käytettiin kyselytuloksen tuottamiseen. Atlasin näistä tapahtumista rakentama linjakaava antaa analytikolle mahdollisuuden jäljittää mikä tahansa arvo kuratoidussa analytiikkataulukossa takaisin jokaisen muunnosvaiheen läpi raa’aan tietueeseen laskeutumisalueella ja edelleen lähdejärjestelmään ja alkuperäiseen keräystapahtumaan. Tämä ketju on operatiivisesti tärkeä — analytikkojen on usein arvioitava, onko tietty analytiikkatulos jäljitettävissä luotettavaan lähteeseen — ja se on vaatimusyhteensopivuuden vaatimus salastetulle datalle.

Analytikkojen haku- ja löytäminen vaatii, että katalogi on kyseltävissä attribuuttien mukaan, joita analytikot todella käyttävät: data-alue (C2, ISR, logistiikka, paikkatieto), kattama aikaväli, turvallisuustaso ja varaukset (suodatettu siihen, mitä käyttäjä on oikeutettu näkemään) ja avainsanahaku datasarjan kuvausten ja sarakkeiden nimien yli. Atlas-haku-API tukee kaikkia näitä ulottuvuuksia, mutta käyttöoikeudenhallintakerroksen on varmistettava, että katalogin hakutulokset itsessään suodatetaan käyttäjän turvallisuusvaltuuksien ja osastojäsenyyksien mukaan — analytikon ei saa voida löytää osastojakoisen datasarjan olemassaoloa, johon hänellä ei ole käyttöoikeutta, vaikka katalogimerkintä ei paljastaisi datasarjan sisältöä.

Osastojakoinen käyttöoikeudenhallinta — attribuuttipohjainen käyttöoikeudenhallinta (ABAC) osastojen valvontaan, rivi-/saraketason turvallisuus kyselymoottoreissa, auditointilokitus

Käyttöoikeudenhallinta sotilaallisessa datakasossa ei ole yksi käytäntö — se on kerrostettu valvontapino, jossa jokainen kerros tarttuu siihen, mitä sen yläpuolella oleva kerros voi jäädä kaipaamaan. Kerrokset ovat: tallennustason korikäytännöt (kuka voi lukea ja kirjoittaa mitkä korit), katalogitasolla näkyvyyskäytännöt (kuka voi löytää mitkä datasarjat), kyselymoottoritason rivi- ja sarakevahvuus (mitä rivejä ja sarakkeita käyttäjä näkee datasarjassa, johon hänellä on käyttöoikeus) ja auditointilokitus (mitä käytettiin, kuka, milloin ja mitä palautettiin). Kaikkien neljän kerroksen on oltava aktiivisia samanaikaisesti — yksikään kerros yksin tarjoaa vain osittaisen suojan.

Attribuuttipohjainen käyttöoikeudenhallinta (ABAC) on oikea malli turvallisuus- ja osastoulottuvuuksille, koska RBAC-roolien räjähdys tekee siitä hallitsemattoman mittakaavassa. ABAC-käytäntö arvioi käyttöoikeuden laskemalla käytäntöfunktion käyttäjän attribuuteista ja resurssiattribuuteista:

# OPA (Open Policy Agent) policy — Rego language example # Grants read access to a dataset if: # - User's clearance level >= dataset classification level, AND # - All dataset caveat codes are in the user's authorized caveat set package datalake.access default allow_read = false allow_read { # Clearance hierarchy: TS > S > C > U clearance_rank[input.user.clearance] >= clearance_rank[input.resource.classification] # All caveats on the resource must be present in user's authorized list required_caveats := {c | c := input.resource.caveats[_]} authorized_caveats := {c | c := input.user.caveats[_]} required_caveats_satisfied := required_caveats - authorized_caveats count(required_caveats_satisfied) == 0 } clearance_rank := { "UNCLASSIFIED": 0, "CONFIDENTIAL": 1, "SECRET": 2, "TOP_SECRET": 3 }

OPA käyttöönnään rinnakkaispalveluna Trinon koordinaattorille. Kun analytikko lähettää SQL-kyselyn, Trinon käyttöoikeudenhallintaliitännäinen kutsuu OPA:ta jokaisesta kyselyn tauluviittauksesta, välittäen todennetun käyttäjän identiteettiattribuutit (identiteetintarjoajalta) ja taulun resurssiattribuutit (katalogista). OPA palauttaa salli/kiellä-päätöksen ja sallituille tauluille rivisuodatin- ja sarakepeittemääritykset, jotka on sovellettava kyseiseen tauluun tässä käyttäjän istunnossa. Trino ruiskuttaa rivisuodattimet ja sarakepeitteet läpinäkyvästi — analytikon kysely suoritetaan kuten kirjoitettu, mutta tulosjoukko sisältää vain rivit ja sarakkeet, joita analytikko on oikeutettu näkemään.

Rivitason turvallisuus Trinoissa liittää ehdon jokaisen suojatun taulun kyselyn WHERE-lauseeseen. Taululle, joka sisältää tietueita useilla turvallisuustasoilla, rivisuodatin rajoittaa kyselyn riveihin, joissa tietueen turvallisuustaso on käyttäjän oikeutetulla alueella. Sarakepeittäminen korvaa sarakearvot NULL:lla tai merkkijonolitteraalilla sarakkeille, joita käyttäjä ei ole oikeutettu näkemään kokonaan — esimerkiksi kenttä, joka sisältää osastotunnuksen, voi olla näkyvissä käyttäjille, joilla on asianmukainen osastovaltuutus, ja peitetty NULL:ksi käyttäjille, joilla sitä ei ole.

Auditointilokituksen on kerättävä jokainen kyselytapahtuma riittävällä yksityiskohdilla sen jäljittämiseksi, mitä käyttäjä näki. Vähimmäisauditointitietueen kentät ovat: todennettu käyttäjän identiteetti (ei vain käyttäjänimi — koko identiteetintarjoajan attribuutit), kyselyn lähetyksen aikaleima, kyselyteksti, käytettyjen taulujen luettelo niiden turvallisuustasoilla, palautettu rivimäärä per taulu, mahdolliset rivisuodatin- tai sarakepeitekäytännöt, jotka sovellettiin, ja kyselyn valmistumistila. Auditointitietueet on kirjoitettava vain-lisättävään objektitallennukseen, jossa objektilukitus on käytössä, mikä estää auditointitietueiden muuttamisen tai poistamisen jopa tallennusjärjestelmän ylläpitäjiltä. Auditointilokin on oltava korkeimmalla turvallisuustasolla, joka voi esiintyä missään kyselyssä, mikä varmistaa, etteivät auditointitietueet ole itse ylirajainen datakanava.

Kysely- ja analytiikan työkuormien kaavat — Trino/Presto ad hoc SQL:lle objektitallennuksen yllä, Spark eräanalytiikalle, analytikoiden muistikirjaympäristöt

Sotilaallinen datajärvi palvelee kahta erillistä kyselytyökuormaprofiilia, jotka vaativat erilaisia suoritusmoottoreita, jotka on optimoitu eri kustannusfunktioille. Ad hoc -analytikoiden kyselyt priorisoivat matalaa viivettä — analytikko, joka rakentaa kohdennusarviota, tarvitsee vastauksen sekunneista minuutteihin, ei tunteihin. Eräanalytiikan työt priorisoivat läpimenoa — datatekniikka-putki, joka käsittelee koko historiallisen sensoritietueiden aineiston elämäntapa-analyysiin, voi hyväksyä pidempiä suoritusaikoja, jos se tuottaa tarkat ja kattavat tulokset. Molempien Trino- ja Spark-käyttöönotto samaa objektitallennusta vastaan palvelee molempia profiileja ilman kompromissia.

Trino on ad hoc -kyselymoottoriksi valittu datajärven SQL-analytiikalle. Se lukee Parquet- ja Delta Lake -tiedostoja suoraan objektitallennuksesta Hive-liitännäisen kautta — ei datakuormitusvaihetta, ei ETL:ää erilliseen tietokantaan. Trinon hajautettu kyselysuoritusmoottori jakaa kyselyn osiin, jotka suoritetaan rinnakkain työsolmuissa, ja väliaineistot vaihdetaan verkon yli. Tyypillisille analytikoiden kyselyille — viimeisempien sensoritietueiden suodatus, C2-seurantojen yhdistäminen paikkatietoreferenssikerroksiin, logistiikan kulutuksen aggregointi yksikön ja aikajakson mukaan — Trino toimittaa tuloksia sekunneista minuutteihin datasarjoille, jotka ulottuvat satoihin gigatavuihin Parquet-tiedostoja. Keskeiset säätöparametrit sotilaallisen datajärven käyttöönotolle ovat: osituksen karsintakokoonpano (Trinon on työnnettävä WHERE-lauseen ehdot ositussarakkeille objektitallennuksen luettelointiin välttäen koko korin skannauksia), tilastojen keräystiheys (Trinon kustannuspohjainen optimoija vaatii tarkat taulukkotilastot tehokkaiden yhdistämissuunnitelmien tuottamiseen) ja työsolmujen muistirajat (suuret yhdistämis-kyselyt voivat ylittää työsolmukohtaisen muistin; levylle siirtymisen konfigurointi estää muistin loppumisvirheet lisääntyneen kyselyviiveen kustannuksella).

Apache Spark on eräanalytiikan moottori työkuormille, jotka vaativat koko aineiston käsittelyä tai monimutkaista iteratiivista laskentaa. Sparkin Delta Lake -integraatio tarjoaa ACID-kirjoitussemantiikan — erätyöt voivat kirjoittaa Delta Lake -taulukoihin täsmälleen kerran -takeilla, ja samanaikaiset Spark- ja Trino-lukijat näkevät johdonmukaisen kuvauksen taulusta jatkuvasti Delta Lake:n MVCC-protokollan kautta. Yleisiä Spark-työkuormia sotilaallisessa datakasossa ovat:

  • Yölliset ETL-työt, jotka käsittelevät raa’an laskeutumisalueen tiedostot edelliseltä 24 tunnilta strukturoituun vyöhykkeeseen — jäsentäen, validoiden, normalisoiden ja kirjoittaen Parquet-ositusmetatiedoilla
  • Elämäntapa-analyysi viikoista kuukausiin historiallisesta seurantadatasta — säännöllisten liikkumiskaavojen, usein yhtäaikaisten tapahtumien ja käyttäytymisen muutosten tunnistaminen ajan myötä
  • Entiteettien ratkaisun erätyöt, jotka konsolidoivat päällekkäiset tietueet lähteiden välillä kuratoitua entiteettipäätaulukkoa varten
  • Koulutusdatan valmisteluputket ML-malleille — piirrekeräys raa’asta sensordatasta, merkintöjen yhdistäminen, datasarjan vienti koulutuskehyksen odottamaan muotoon
  • Datan laadun tarkistukset, jotka suorittavat tilastollisen profiloinnin koko strukturoidulla vyöhykkeellä skeeman liukumisen, arvojen jakauman poikkeamien ja alkuperäismetatietojen aukkojen havaitsemiseksi

JupyterHub tarjoaa analytikoille suunnatun muistikirjaympäristön. Muistikirjat yhdistyvät Trinoon SQL-kyselyihin ja Sparkiin ohjelmoitavaan datankäsittelyyn, yhdistäen Pythonin tutkimuksellisen joustavuuden molempien moottorien strukturoituihin kyselyominaisuuksiin. Salastetussa käyttöönotossa JupyterHub-palvelimen on oltava eristetty asianmukaiseen turvallisuusluokan verkkosegmenttiin — jokainen turvallisuustaso vaatii oman JupyterHub-instanssinsa, joka on yhdistetty Trino- ja Spark-klustereihin kyseisellä tasolla. Analytikoiden luomat muistikirjat on tallennettava datajärven kuratoituun vyöhykkeeseen (ei JupyterHub-palvelimen paikalliselle levylle), jotta ne kuuluvat samoihin säilytys- ja auditointikäytäntöihin kuin muu datajärven sisältö. Valmiiksi rakennetut muistikirjapohjat yleisiin monialueyhdistämiskaavoihin — C2-seuranta yhdistettynä ISR-sensorihavaintoihin, logistiikan kulutus yhdistettynä operatiivisiin raportteihin — vähentävät aikaa, jonka analytikko käyttää valmiiseen kyselyrakenteeseen ennen kuin pääsee varsinaiseen analyysikysymykseensä.

Datan laatu ja hallinto — datan laatutarkistukset keräyksessä, päädatanhallinta entiteettiviittauksille, datan säilytys- ja hävityskäytännöt salastetulle datalle

Datan hallinto sotilaallisessa datakasossa ei ole dokumentointiharjoitus — se on operatiivinen kurinalaisuus, joka määrittää, voiko datajärven tuottamaan analytiikkaan luottaa päätöksenteossa. Analytikko, joka löytää, että kohdennusarvio perustui dataan, joka epäonnistui laaduntarkistuksissaan mutta sai levitä kuratoituun vyöhykkeeseen, on menettänyt luottamuksen koko analytiikka-alustaan. Hallintomekanismit on pakotettava automaattisesti, ei nojaten analytikon tietoisuuteen datan laadun tilasta.

Datan laatutarkistukset keräysvaiheessa (kuvattu keräysputken osiossa) ovat ensimmäinen hallintaportti. Toinen portti on päivittäinen datan laadun tarkistus strukturoidulla vyöhykkeellä käyttäen Apache Sparkia. Tarkistus suorittaa säädetävissä olevan tarkistusjoukon jokaista rekisteröityä datasarjaa vastaan:

  • Täydellisyystarkistukset — ei-null-arvojen prosenttiosuus pakollisille kentille; datasarja, jossa pakollinen kenttä putoaa alle 95 % täydellisyydestä, laukeaa hälytyksen data-omistajalle
  • Arvojen jakaumatarkistukset — numeeristen sarakkeiden tilastollinen profilointi havaitsee äkilliset jakauman siirtymät, jotka voivat viitata sensorin virhekalibrointiin, koordinaattijärjestelmän muutoksiin tai ETL-virheisiin
  • Viite-eheystarkistukset — vierasavainsuhteet datasarjojen välillä (esim. seurantaentiteetin tunnukset, joihin viitataan sensortietueissa, on oltava olemassa C2-entiteettipäätaulukossa) validoidaan päivittäin orpojen viittausten havaitsemiseksi, jotka aiheutuvat keräyksen järjestämisongelmista
  • Tuoreustarkistukset — jokaisella datasarjalla on enimmäisodotettu keräysviive; datasarjat, jotka eivät ole vastaanottaneet uusia tietueita tässä ikkunassa, laukeavat hälytyksen, joka voi viitata lähdejärjestelmän vaurioon tai verkon ositukseen

Päädatanhallinta (MDM) entiteettiviittauksille on hallintomekanismi, joka estää epäjohdonmukaisten entiteetintunnusten leviämisen data-alueiden välillä. Sotilaallisessa kontekstissa ensisijaiset entiteetit, jotka vaativat MDM:ää, ovat: yksiköt ja muodostelmat (niiden hierarkkisilla suhteilla ja nykyisellä tehtäväorganisoinnilla), kalustoyksiköt (mallilla, variantilla ja sijoitetulla yksiköllä), maantieteelliset piirteet ja laitokset (salastetuilla ja salattomilla nimillä) ja henkilöstö (turvallisuusvaltuuksilla ja sijoitustietueilla). Jokainen näistä entiteettityypeistä vaatii kultaisen tietueen entiteettipäätaulukossa, joka toimii luotettavana referenssinä yhdistämisille data-alueiden välillä. Ilman ylläpidettyä entiteettipäätaulukkoa analytikot, jotka yhdistävät ISR-sensoritietueet C2-yksikkötietueisiin, tuottavat yhdistämisvirheitä tai virheellisiä tuloksia aina, kun sama yksikkö tunnistetaan eri tunnuksilla eri lähdejärjestelmissä — yleinen ongelma monilähteisissä sotilaallisissa dataympäristöissä.

Salastetun datan säilytys ja hävitys käyttää kryptografista pyyhkimistä standardimekanismina. Jokaisen turvallisuusluokan data-salausavain (DEK) tallennetaan laitteistoturvallisuusmoduuliin (HSM). Kun säilytyskäytäntö laukeaa datasarjan hävitykseen, HSM tuhoaa vaikutuksen alaisten objektien DEK:n sen sijaan, että se suorittaisi objektitason ylikirjoituksen mahdollisesti petatavuittain salattua dataa. DEK:n tuhoamisen jälkeen salatut objektit ovat laskennallisesti palautumattomia — turvallisen poiston vaatimus tyydytetään ilman moninkertaisten ylikirjoitusmenettelyjen operatiivista rasitetta petatavun mittakaavassa. Puhdistuspalvelu, joka suorittaa DEK:n tuhoamisen, on kirjattava jokainen puhdistustapahtuma muuttamattomaan auditointijälkeen, joka tallentaa:

  • Datasarjan tunniste ja vaikutuksen alainen objektipolku-etuliite
  • Objektien määrä, joiden salausavain tuhottiin
  • Säilytyskäytännön sääntö, joka laukaisi hävityksen (sääntötunnuksen ja version mukaan)
  • Hävityksen hyväksyneen automaattisen palvelun tai inhimillisen pääkäyttäjän identiteetti
  • DEK:n kryptografinen tiiviste tuhoamishetkellä (todistaa, että avain oli olemassa ennen tuhoamista ilman avaimen itse säilyttämistä)
  • DEK:n tuhoamisen aikaleima ja HSM:n todistuskirja, joka vahvistaa tuhoutumistapahtuman

Hallintakehys on tehokas vain, jos sen tulokset ovat näkyvissä datan laadusta vastaaville ihmisille. Päivittäinen hallintanäkymä — joka rakentuu datan laadun tarkistustuloksista, katalogin rekisteröinnin täydellisyysmittareista, säilytyskäytännön noudattamisen tilasta ja auditointilokien yhteenvedoista — antaa data stewardeille näkyvyyden, joka tarvitaan ongelmien havaitsemiseen ja korjaamiseen ennen kuin ne leviävät analyytikoille tarjottaviin valmisteltuihin tietoaineistoihin. Itse näkymä on otettava käyttöön asianmukaisessa turvaluokituksen mukaisessa verkkosegmentissä, ja sen tiedot on haettava yksinomaan kyseisestä segmentistä — salassa pidettävälle (Secret) datalle tarkoitettu hallintanäkymä ei saa hakea mittareita luokittelemattoman (Unclassified) valvonnan infrastruktuurista. Hallinnon käsittely toisen luokan asiana, joka voi jakaa infrastruktuurin alemman turvaluokan palveluiden kanssa, on yleinen arkkitehtuurivirhe, joka luo sekä vaatimustenmukaisuusriskin että operatiivisen sokean pisteen järven herkimmän sisällön datan laadulle.