Een militaire data lake en een commerciële data lake delen hetzelfde kernidee — goedkope, schaalbare objectopslag als fundament voor analyses — maar lopen sterk uiteen op elke beperking die operationeel van belang is. Classificatiehandhaving, compartimentbewuste toegang, werking in air-gapped omgevingen en missiekritieke query-SLA's zijn voor een defensie-implementatie geen optionele extra's; het zijn dragende eisen die elke laag van de architectuur bepalen, van de naamgeving van opslagbuckets tot de configuratie van de query-engine. Een architectuur die ze als bijzaak behandelt — door een classificatielabel toe te voegen aan bestaande patronen voor commerciële data lakes — zal in het beste geval beveiligingsaudits niet doorstaan en in het slechtste geval compliance-overtredingen veroorzaken.
Dit artikel doorloopt het volledige ontwerp van een militaire data lake in productie: de opslaglaag, de ingestpipeline vanuit C2-, ISR- en logistieke bronnen, metadatabeheer voor militaire datacatalogi, gecompartimenteerde toegangscontrole en patronen voor analytische workloads. Elke sectie behandelt de ontwerpkeuzes die een operationeel inzetbaar systeem onderscheiden van een referentiearchitectuur die er in een whitepaper correct uitziet, maar bij contact met echte geclassificeerde data uit elkaar valt.
Wat een militaire data lake moet kunnen en een commerciële data lake niet — classificatiehandhaving, compartimentbewuste toegang, werking in air-gapped omgevingen, missiekritieke SLA's
Het meest fundamentele verschil tussen een commerciële en een militaire data lake is geen technologiekeuze — het is een dreigingsmodel. Een commerciële data lake beschermt tegen externe aanvallers en data-exfiltratie door insiders. Een militaire data lake moet ook beschermen tegen een subtielere fout: een geautoriseerde gebruiker die toegang krijgt tot data waarvoor een veiligheidsmachtiging is verleend, maar die in de huidige context niet ingezien mag worden. Een signaalanalist met een veiligheidsmachtiging voor Zeer geheim mag geen gecompartimenteerde HUMINT-dataset kunnen bevragen, tenzij die analist de specifieke compartimentcode bezit. Een logistiek officier met een machtiging voor Geheim mag geen ISR-inlichtingen kunnen zien, ook al zijn die eveneens als Geheim geclassificeerd. Classificatieniveau en lidmaatschap van een compartiment zijn orthogonale toegangsdimensies, en beide moeten op elke laag van het systeem worden afgedwongen.
Werking in een air-gapped omgeving sluit elke afhankelijkheid van door de cloud beheerde diensten uit. Er is geen managed Kafka, geen in de cloud gehoste catalogus en geen door een leverancier beheerde sleutelbeheerdienst. Elk onderdeel — objectopslag, streaming broker, query-engine, metadatacatalogus, sleutelbeheerhardware — moet on-premises kunnen worden ingezet vanuit pakketten die via goedgekeurde media naar de air-gapped omgeving kunnen worden overgebracht. Deze beperking sluit architecturen uit die uitgaan van via internet bereikbare update-endpoints, licentievalidatieservers of telemetrieverzamelingsdiensten. Het betekent ook dat het beheerteam de volledige upgrade- en patchcyclus van elk onderdeel zelf in handen heeft, zonder een door een leverancier beheerd pad.
Missiekritieke SLA's gelden zowel voor de actualiteit van de data als voor de querylatentie. Een ISR-fusieanalist die de laatst ingelezen sensordata bevraagt, kan geen venster van meerdere uren voor een Spark-batchjob accepteren. Een logistiek officier die een bevoorradingsmodel opstelt, heeft queryresultaten nodig in minuten, niet in dagen. Deze eisen dwingen architectuurkeuzes af die commerciële data lakes vaak uitstellen: permanent draaiende query-engines die hun queryplannen al hebben gecompileerd op basis van actuele catalogusstatistieken, opslag in de hot-laag voor recente data en streaming-ingest waardoor nieuwe data binnen enkele seconden na ontvangst bevraagbaar is — niet pas in het volgende batchvenster. Voor meer achtergrond over de basispatronen die in de hier beschreven lagen worden gebruikt, zie onze gids over integratiepatronen voor defensiedata.
Een vierde eis waaraan commerciële data lakes eveneens onvoldoende tegemoetkomen, is integratie van multidomeindata — het samenvoegen van C2-trackdata, ISR-sensordata, logistieke gegevens en geospatiale referentielagen in één query over classificatiegrenzen heen (met passende controles). In een commerciële data lake zijn cross-domain joins een gemak voor data engineers. In een militaire data lake zijn ze de belangrijkste analytische use case — en ze moeten mogelijk zijn zonder de handhaving van de classificatie te versoepelen. De query-engine moet tabellen uit verschillende datadomeinen kunnen joinen en daarbij per tabel transparant classificatiefilters toepassen op elke zijde van de join.
Ontwerp van de opslaglaag — objectopslag (MinIO/Ceph voor on-prem), gelaagde opslag (hot/warm/cold), objectnaamgeving en partitionering voor militaire datadomeinen
Objectopslag is het fundament van elke moderne data lake-architectuur, en voor militaire implementaties in air-gapped omgevingen beperkt de keuze zich tot twee in productie bewezen platforms: MinIO en Ceph. MinIO implementeert de volledige AWS S3-API met AES-256-encryptie in rust, IAM-beleid per bucket en versiebeheer en locking op objectniveau — allemaal zonder enige cloudafhankelijkheid. De prestaties ervan op moderne NVMe-hardware overtreffen die van commerciële cloudobjectopslag voor sequentiële schrijfworkloads, wat het dominante patroon is bij de ingest van sensordata. Ceph biedt object-, block- en bestandsopslag vanuit één cluster via de RADOS Gateway en is daarmee geschikt voor omgevingen waar dezelfde fysieke opslaginfrastructuur zowel de objectworkload van de data lake als de blockvolumes voor virtuele machines moet bedienen. Voor een dedicated data lake-implementatie is MinIO operationeel eenvoudiger; Ceph is de juiste keuze wanneer het opslagcluster ook block- en bestandsinterfaces moet bieden.
Classificatie-isolatie wordt geïmplementeerd op bucketniveau, niet op objectniveau. Elk classificatieniveau heeft zijn eigen bucket-namespace:
De zonestructuur — raw, structured, curated — verdeelt de data binnen elk classificatieniveau naar verwerkingsfase. De raw zone bevat data precies zoals die van de bronsystemen is ontvangen, in het oorspronkelijke formaat (CoT-XML, NIEM-XML, binaire sensorstreams, CSV-logistiekexports). Niets in de raw zone wordt na het schrijven gewijzigd; het is een onveranderlijk auditrecord van wat er is ontvangen. De structured zone bevat data na normalisatie naar Parquet met het Delta Lake-tabelformaat — schema afgedwongen, velden toegewezen aan canonieke namen, herkomstmetadata toegevoegd. De curated zone bevat voor analisten direct bruikbare aggregaten, vooraf gejoinde multidomeinviews en samenvattingstabellen die snelle interactieve queries mogelijk maken, zonder dat elke analist dezelfde joinlogica zelf hoeft uit te voeren.
Het ontwerp van de objectsleutels voor de structured zone codeert alle partitiedimensies die nodig zijn voor efficiënte query-pushdown:
Gelaagde opslag wordt beheerd via het lifecyclebeleid van MinIO. De hot-laag gebruikt nodes met NVMe-opslag en bevat data van de afgelopen 30 dagen — recent genoeg om door analisten regelmatig te worden bevraagd voor actuele operationele analyses. Na 30 dagen gaan objecten over naar de warm-laag op draaiende schijven met hoge dichtheid, waar ze bevraagbaar blijven maar met een hogere latentie. Na 180 dagen gaan objecten over naar de cold-laag op archiefopslag met hoge dichtheid en een configureerbare ophaallatentie. De drempels voor de lagen zijn per domein en per classificatieniveau configureerbaar — ISR-sensordata uit actieve operatiegebieden kan een kortere overgang van warm naar cold hebben dan logistieke archiefdata.
Architectuur van de ingestpipeline — feeds van C2-systemen (CoT/NIEM), ingest van ISR-sensordata, ETL van logistieke systemen, patronen voor streaming versus batch-ingest
De ingestlaag moet drie fundamenteel verschillende profielen van datasnelheid tegelijk verwerken: streamingfeeds met hoge snelheid van C2- en ISR-systemen die duizenden gebeurtenissen per minuut produceren; gestructureerde feeds met gemiddelde snelheid van logistieke en planningssystemen die honderden records per uur produceren; en batchexports met lage snelheid van legacysystemen die dagelijkse of wekelijkse bestandsdumps leveren. Deze profielen vereisen verschillende ingestpatronen die bij de grens van de landing zone naadloos moeten samenwerken.
Apache Kafka is de streamingbackbone voor realtimefeeds. Het topicontwerp volgt dezelfde, op classificatie gebaseerde conventie als de opslag — elk topic heeft het classificatieniveau als voorvoegsel, en Kafka-ACL's beperken de toegang van producers en consumers per classificatieniveau. De naamgevingsconventie voor topics codeert het brontype en de identiteit van het systeem:
CoT/NIEM-adapterservices abonneren zich op de ruwe C2-topics, parseren de XML, wijzen velden toe aan het canonieke ingestschema, voegen herkomstmetadata toe (ID van het bronsysteem, verzameltijdstip, classificatieniveau, oorspronkelijke eenheid) en publiceren naar het genormaliseerde topic. De CoT-parsing moet zowel standaard CoT-velden als extensies van het Detail-element verwerken die door specifieke C2-systemen worden gebruikt — de adapter mag de inhoud van extensies niet stilzwijgend weglaten; hij moet bekende extensies toewijzen aan canonieke velden of ze bewaren in een gestructureerde extensiekolom. NIEM-adapters verwerken aanzienlijk complexere schema's — door het modulaire ontwerp van NIEM kan een NIEM-uitwisselingsinstantie verwijzen naar typen uit meerdere NIEM-kern- en domeinschema's, en de adapter moet alle verwijzingen oplossen vóór de veldtoewijzing. De adapter levert een afgevlakte structuur met één rij per rapport, geschikt voor Parquet-opslag.
De ingest van ISR-sensoren verschilt per sensortype. Feeds met videoanalyse van UAV's produceren detectiegebeurtenisrecords — bounding box, detectieklasse, betrouwbaarheidsscore, frametijdstempel, sensorpositie — met snelheden die voor een multistreamplatform meer dan 10.000 records per minuut kunnen bedragen. Deze moeten via Kafka worden ingelezen, met afdwinging van het Avro- of Protobuf-schema aan de kant van de producer, niet alleen aan die van de consumer. SIGINT-ontvangers produceren intercept-records van zenders met frequentie, modulatie, pulsparameters, peiling en TDOA-data. Radarfeeds produceren trackrapporten met positie, snelheid en trackkwaliteitsmetrieken. Elk sensortype heeft een eigen adapter die het oorspronkelijke formaat normaliseert naar het canonieke ISR-waarnemingsschema voordat het record de landing zone bereikt. Voor een uitgebreide behandeling van architectuur voor realtime inlichtingenfusie verwijzen wij naar ons aanvullende artikel over de verwerking van streams uit meerdere bronnen.
Logistieke ETL werkt doorgaans in batchmodus — de meeste logistieke ERP-systemen produceren periodieke exports in plaats van realtime wijzigingsstreams. De ETL-pipeline haalt data op via de exportinterface van het bronsysteem (SFTP-bestandsdrop, databasequery of REST API-pull), valideert het schema, past veldtoewijzing toe op het canonieke logistieke schema en schrijft Parquet-bestanden naar de raw landing zone. Vervolgens verwerkt een Spark-job de ruwe bestanden naar de structured zone, volgens een schema dat is gesynchroniseerd met het exportritme van het bronsysteem. Voor logistieke systemen die change data capture (CDC) via database-logstreaming ondersteunen, heeft het streamingpad de voorkeur — het verkort de tijd tussen een logistieke gebeurtenis en de beschikbaarheid ervan voor analytische queries van uren naar minuten.
Validatie van de datakwaliteit bij ingest is niet optioneel — het is het mechanisme dat voorkomt dat misvormde data de structured zone bereikt en de analyses aantast. Elke ingestadapter moet minimaal het volgende uitvoeren: validatie van de schemaconformiteit, controles op volledigheid van de herkomst, temporele plausibiliteitscontroles (tijdstempels van gebeurtenissen binnen aannemelijke grenzen) en, voor geospatiale data, validatie van het coördinatenbereik. Validatiefouten worden doorgestuurd naar een dead-letter queue met de volledige oorspronkelijke berichttekst en een gestructureerd foutrecord dat de specifieke mislukte controle aanduidt.
Metadatacatalogus en data discovery — classificatie- en caveatlabels in metadata, schema registry, tracking van data lineage, UX voor zoeken en ontdekken door analisten
De metadatacatalogus is het onderdeel dat de data lake bruikbaar maakt voor analisten die deze niet zelf hebben gebouwd. Zonder catalogus is de data lake een verzameling ondoorzichtige Parquet-bestanden in objectopslag, waarvan alleen de engineers die de ingestadapters hebben geschreven weten hoe ze moeten worden bevraagd. Met een goed gevulde catalogus kan elke analist met de juiste veiligheidsmachtiging beschikbare datasets ontdekken, hun schema's en herkomst begrijpen en er queries op opstellen — zonder dat voor elke nieuwe analytische vraag technische ondersteuning nodig is. De gids metadatabeheer voor militaire datacatalogi behandelt het catalogusontwerp in detail; dit gedeelte gaat in op de integratie ervan met de data lake-architectuur.
Apache Atlas is de in productie bewezen open-sourcecatalogus voor omgevingen die uitbreidbare metadatatypen, lineage-tracking en integratie met tools uit het Hadoop-ecosysteem vereisen. Dankzij het typesysteem van Atlas kunnen aangepaste metadata-entiteitstypen worden gedefinieerd als volwaardige schema-objecten — niet als annotaties in vrije tekst — wat essentieel is voor de defensiespecifieke velden die bij het registreren van een dataset verplicht moeten zijn:
- ClassificationLevel — opsommingstype: UNCLASSIFIED, CONFIDENTIAL, SECRET, TOP_SECRET. Verplicht voor elke datasetentiteit. Bepaalt de routering naar opslagbuckets en de evaluatie van het toegangscontrolebeleid.
- CaveatCodes — lijst met meerdere tekenreeksen. Legt toepasselijke caveats vast, zoals NOFORN, compartimentidentificaties en behandelinstructies. Moet bij ingest worden ingevuld of als expliciete lege verklaring worden gelaten — null is niet toegestaan.
- DataOwnerUnit — tekenreeksverwijzing naar de organisatie-eenheid die verantwoordelijk is voor de dataset. Wordt gebruikt voor de routering van data stewardship en voor het aanwijzen van een aanspreekpunt bij verzoeken om toegang tot data.
- RetentionPolicy — verwijzing naar de toepasselijke bewaarregel die de maximale bewaartermijn, de procedure voor veilig verwijderen en de instantie die de bewaartermijn heeft goedgekeurd vastlegt.
- OriginatingSystem — identificatie van het bronsysteem dat de data heeft geproduceerd. Wordt gebruikt voor het traceren van lineage en voor het terugsturen van datakwaliteitsproblemen naar de beheerder van het bronsysteem.
Integratie van de schema registry met Apache Kafka zorgt ervoor dat het schema van elk topic is geregistreerd en van een versie is voorzien voordat een producer begint te schrijven. De Confluent Schema Registry (on-premises te implementeren zonder cloudverbinding) dwingt de compatibiliteitsregels voor Avro- of Protobuf-schema's af — BACKWARD-compatibiliteit voor consumentgerichte topics betekent dat nieuwe schemaversies optionele velden kunnen toevoegen zonder bestaande consumers te breken. Elke schemaversie is gekoppeld aan de Atlas-catalogusentiteit van de bijbehorende dataset, waardoor een volledige historie ontstaat van hoe de structuur van de dataset zich in de loop van de tijd heeft ontwikkeld.
De tracking van data lineage in Atlas legt de transformatieketen vast van de raw ingest tot de curated analysetabel. De Atlas-hook van Spark verzendt automatisch lineage-events wanneer een Spark-job uit de ene bij Atlas geregistreerde dataset leest en naar een andere schrijft. De Atlas-integratie van Trino vereist een aangepaste event listener die vastlegt welke brontabellen zijn geraadpleegd om een queryresultaat te produceren. Met de lineagegraaf die Atlas uit deze events opbouwt, kan een analist elke waarde in een curated analysetabel via elke transformatiestap terugvolgen naar het oorspronkelijke ruwe record in de landing zone en verder terug naar het bronsysteem en de oorspronkelijke verzamelgebeurtenis. Deze keten is operationeel belangrijk — analisten moeten vaak beoordelen of een bepaald analyseresultaat tot een betrouwbare bron herleidbaar is — en is een compliance-eis voor geclassificeerde data.
Zoeken en ontdekken door analisten vereist dat de catalogus kan worden bevraagd op de kenmerken die analisten daadwerkelijk gebruiken: datadomein (C2, ISR, logistiek, geospatiaal), bestreken tijdsbereik, classificatieniveau en caveats (gefilterd op wat de gebruiker mag zien) en trefwoordzoekopdrachten in datasetbeschrijvingen en kolomnamen. De zoek-API van Atlas ondersteunt al deze dimensies, maar de toegangscontrolelaag moet ervoor zorgen dat de zoekresultaten van de catalogus zelf worden gefilterd op de veiligheidsmachtiging en de compartimentlidmaatschappen van de gebruiker — een analist mag het bestaan van een gecompartimenteerde dataset waartoe die analist geen toegang heeft niet kunnen ontdekken, ook niet als de catalogusvermelding de inhoud van de dataset niet toont.
Gecompartimenteerde toegangscontrole — attribuutgebaseerde toegangscontrole (ABAC) voor handhaving van compartimenten, beveiliging op rij- en kolomniveau in query-engines, auditlogging
Toegangscontrole in een militaire data lake is geen enkel beleid — het is een gelaagde handhavingsstack waarin elke laag opvangt wat de laag erboven mogelijk mist. De lagen zijn: bucketbeleid op opslagniveau (wie welke buckets mag lezen en beschrijven), zichtbaarheidsbeleid op catalogusniveau (wie welke datasets kan ontdekken), rij- en kolombeveiliging op query-engineniveau (welke rijen en kolommen een gebruiker mag zien binnen een dataset waartoe die toegang heeft) en auditlogging (wat is geraadpleegd, door wie, wanneer en wat is teruggegeven). Alle vier de lagen moeten tegelijk actief zijn — elke laag die afzonderlijk werkt, biedt slechts gedeeltelijke bescherming.
Attribuutgebaseerde toegangscontrole (ABAC) is het juiste model voor de dimensies classificatie en compartiment, omdat rolexplosie RBAC op schaal onbeheersbaar maakt. Een ABAC-beleid evalueert toegang door een beleidsfunctie te berekenen over gebruikerskenmerken en resourcekenmerken:
OPA wordt als sidecar bij de Trino-coördinator ingezet. Wanneer een analist een SQL-query indient, roept de toegangscontrole-plugin van Trino OPA aan voor elke tabelverwijzing in de query, waarbij de identiteitskenmerken van de geauthenticeerde gebruiker (van de identity provider) en de resourcekenmerken van de tabel (uit de catalogus) worden meegegeven. OPA geeft een toestaan/weigeren-beslissing terug en levert voor toegestane tabellen het rijfilterpredicaat en de definities van kolommaskers die in de sessie van deze gebruiker op die tabel moeten worden toegepast. Trino past de rijfilters en kolommaskers transparant toe — de query van de analist wordt uitgevoerd zoals geschreven, maar de resultaatset bevat alleen de rijen en kolommen die de analist mag zien.
Beveiliging op rijniveau in Trino voegt een predicaat toe aan de WHERE-clausule van elke query op een beschermde tabel. Voor een tabel met records op meerdere classificatieniveaus beperkt het rijfilter de query tot rijen waarvan het classificatieniveau binnen het geautoriseerde bereik van de gebruiker valt. Maskering op kolomniveau vervangt kolomwaarden door NULL of een tekenreeksliteraal voor kolommen die de gebruiker niet volledig mag zien — een veld met een compartimentidentificatie kan bijvoorbeeld zichtbaar zijn voor gebruikers met de juiste compartimentautorisatie en voor gebruikers zonder die autorisatie worden gemaskeerd tot NULL.
Auditlogging moet elke queryactie vastleggen met voldoende detail om te kunnen reconstrueren wat de gebruiker heeft gezien. De minimale velden van een auditrecord zijn: de identiteit van de geauthenticeerde gebruiker (niet alleen de gebruikersnaam — alle kenmerken van de identity provider), het tijdstip van indiening van de query, de querytekst, de lijst van geraadpleegde tabellen met hun classificatieniveaus, het aantal teruggegeven rijen per tabel, eventuele toegepaste beleidsregels voor rijfilters of kolommaskers en de afrondingsstatus van de query. Auditrecords moeten worden geschreven naar append-only objectopslag met ingeschakelde object lock, zodat ook opslagbeheerders auditrecords niet kunnen wijzigen of verwijderen. De opslag van het auditlog moet zich op het hoogste classificatieniveau bevinden dat in een query kan voorkomen, zodat de auditrecords zelf geen datakanaal tussen classificatieniveaus vormen.
Patronen voor query- en analytics-workloads — Trino/Presto voor ad-hoc SQL op objectopslag, Spark voor batchanalyses, notebookomgevingen voor analisten
Een militaire data lake bedient twee afzonderlijke queryworkloadprofielen die verschillende uitvoeringsengines vereisen, geoptimaliseerd voor verschillende kostenfuncties. Ad-hocqueries van analisten geven prioriteit aan lage latentie — een analist die een targetingbeoordeling opstelt, heeft binnen seconden tot minuten een antwoord nodig, niet na uren. Batchanalysejobs geven prioriteit aan doorvoer — een data-engineeringpipeline die het volledige historische corpus aan sensorrecords verwerkt voor pattern-of-life-analyse, kan langere looptijden accepteren als dit nauwkeurige, volledige resultaten oplevert. Door zowel Trino als Spark op dezelfde objectopslag in te zetten, worden beide profielen zonder compromis bediend.
Trino is de query-engine bij uitstek voor ad-hocanalyses met SQL op een data lake. Het leest Parquet- en Delta Lake-bestanden rechtstreeks uit objectopslag via de Hive-connector — geen laadstap, geen ETL naar een afzonderlijke database. De gedistribueerde queryuitvoeringsengine van Trino splitst de query in fragmenten die parallel op worker-nodes worden uitgevoerd, waarbij tussenresultaten via het netwerk worden uitgewisseld. Voor typische analistenqueries — het filteren van recente sensorrecords, het joinen van C2-tracks met geospatiale referentielagen, het aggregeren van logistiek verbruik per eenheid en tijdsperiode — levert Trino binnen seconden tot minuten resultaten op datasets die honderden gigabytes aan Parquet-bestanden beslaan. De belangrijkste afstemmingsparameters voor een implementatie van een militaire data lake zijn: de configuratie van partition pruning (Trino moet WHERE-predicaten op partitiekolommen tot aan de listing van de objectopslag doorgeven, zodat volledige bucketscans worden vermeden), de frequentie van het verzamelen van statistieken (de kostengebaseerde optimizer van Trino heeft nauwkeurige tabelstatistieken nodig om efficiënte joinplannen te maken) en de geheugenlimieten van workers (grote joinqueries kunnen het geheugen per worker overschrijden; het configureren van spill-to-disk voorkomt out-of-memory-fouten ten koste van een hogere querylatentie).
Apache Spark is de batchanalyse-engine voor workloads die verwerking van het volledige corpus of complexe iteratieve berekeningen vereisen. De Delta Lake-integratie van Spark biedt ACID-schrijfsemantiek — batchjobs kunnen met exactly-once-garanties naar Delta Lake-tabellen schrijven, en gelijktijdige Spark- en Trino-lezers zien via het MVCC-protocol van Delta Lake altijd een consistente snapshot van de tabel. Gangbare Spark-workloads in een militaire data lake zijn onder meer:
- Nachtelijke ETL-jobs die de bestanden uit de raw landing zone van de afgelopen 24 uur verwerken naar de structured zone — parseren, valideren, normaliseren en Parquet schrijven met partitiemetadata
- Pattern-of-life-analyse over weken of maanden aan historische trackdata — het identificeren van regelmatige bewegingspatronen, frequente co-locatiegebeurtenissen en gedragsveranderingen in de tijd
- Batchjobs voor entity resolution die dubbele records uit verschillende bronnen consolideren voor de curated entiteitsmastertabel
- Pipelines voor het voorbereiden van trainingsdata voor ML-modellen — feature-extractie uit ruwe sensordata, het koppelen van labels en het exporteren van datasets naar het formaat dat het trainingsframework verwacht
- Datakwaliteitssweeps die statistische profilering uitvoeren over de volledige structured zone om schema-drift, afwijkingen in waardeverdelingen en hiaten in herkomstmetadata te detecteren
JupyterHub biedt de notebookomgeving voor analisten. Notebooks maken verbinding met Trino voor SQL-queries en met Spark voor programmatische datamanipulatie, en combineren de verkennende flexibiliteit van Python met de gestructureerde querymogelijkheden van beide engines. In een geclassificeerde implementatie moet de JupyterHub-server worden geïsoleerd binnen het passende netwerksegment voor het classificatieniveau — elk classificatieniveau vereist een eigen JupyterHub-instantie die is verbonden met de Trino- en Spark-clusters binnen dat niveau. Door analisten gemaakte notebooks moeten worden opgeslagen in de curated zone van de data lake (niet op de lokale schijf van de JupyterHub-server), zodat ze onder hetzelfde bewaar- en auditbeleid vallen als andere inhoud van de data lake. Kant-en-klare notebooksjablonen voor veelvoorkomende multidomein-joinpatronen — een C2-track gejoind met ISR-sensordetecties, logistiek verbruik gejoind met operationele rapporten — verkorten de tijd die een analist kwijt is aan standaardcode voor het opstellen van queries voordat de analist toekomt aan de eigenlijke analytische vraag.
Datakwaliteit en governance — datakwaliteitscontroles bij ingest, stamgegevensbeheer (MDM) voor entiteitsverwijzingen, bewaar- en verwijderingsbeleid voor geclassificeerde data
Datagovernance in een militaire data lake is geen documentatieoefening — het is een operationele discipline die bepaalt of de analyses van de data lake kunnen worden vertrouwd voor besluitvorming. Een analist die ontdekt dat een targetingbeoordeling was gebaseerd op data die de kwaliteitscontroles niet doorstond maar toch naar de curated zone mocht doorstromen, heeft het vertrouwen in het hele analyseplatform verloren. Governancemechanismen moeten automatisch worden afgedwongen, zonder te vertrouwen op het besef van analisten over de status van de datakwaliteit.
Datakwaliteitscontroles bij ingest (beschreven in het gedeelte over de ingestpipeline) vormen de eerste governancepoort. De tweede poort is een dagelijkse datakwaliteitssweep over de structured zone met Apache Spark. De sweep voert een configureerbare reeks controles uit op elke geregistreerde dataset:
- Volledigheidscontroles — percentage waarden dat niet null is in verplichte velden; elke dataset waarin een verplicht veld onder de 95% volledigheid zakt, activeert een waarschuwing aan de data steward
- Controles op waardeverdeling — statistische profilering van numerieke kolommen detecteert plotselinge verschuivingen in de verdeling die kunnen wijzen op verkeerde sensorkalibratie, wijzigingen in het coördinatensysteem of ETL-bugs
- Controles op referentiële integriteit — foreign key-relaties tussen datasets (bijvoorbeeld: track-entiteits-ID's waarnaar in sensorrecords wordt verwezen, moeten in de C2-entiteitsmaster bestaan) worden dagelijks gevalideerd om verweesde verwijzingen te detecteren die door problemen met de ingestvolgorde zijn ontstaan
- Controles op actualiteit — elke dataset heeft een maximaal verwachte ingestlatentie; datasets die binnen dat venster geen nieuwe records hebben ontvangen, activeren een waarschuwing die kan wijzen op een storing in het bronsysteem of een netwerkpartitie
Stamgegevensbeheer (MDM) voor entiteitsverwijzingen is het governancemechanisme dat de wildgroei van inconsistente entiteitsidentificaties tussen datadomeinen voorkomt. In een militaire context zijn de belangrijkste entiteiten die MDM vereisen: eenheden en formaties (met hun hiërarchische relaties en huidige taakorganisatie), materieelitems (met model, variant en toegewezen eenheid), geografische objecten en faciliteiten (met geclassificeerde en niet-geclassificeerde namen) en personeel (met gegevens over veiligheidsmachtiging en plaatsing). Elk van deze entiteitstypen vereist een golden record in de entiteitsmastertabel die dient als gezaghebbende referentie voor joins tussen datadomeinen. Zonder een onderhouden entiteitsmaster zullen analisten die ISR-sensorrecords met C2-eenheidsrecords joinen, joinfouten of onjuiste resultaten krijgen wanneer dezelfde eenheid in verschillende bronsystemen onder verschillende identificaties bekend staat — een veelvoorkomend probleem in militaire dataomgevingen met meerdere bronnen.
Bewaring en verwijdering van geclassificeerde data gebruiken cryptografisch wissen als standaardmechanisme. De data-encryptiesleutel (DEK) van elk classificatieniveau wordt opgeslagen in een hardwarebeveiligingsmodule (HSM). Wanneer een bewaarbeleid de verwijdering van een dataset in gang zet, vernietigt de HSM de DEK van de betreffende objecten, in plaats van potentieel petabytes aan versleutelde data object voor object te overschrijven. Na vernietiging van de DEK zijn de versleutelde objecten rekenkundig onherstelbaar — aan de eis voor veilig verwijderen wordt voldaan zonder de operationele last van overschrijfprocedures met meerdere passes op petabyteschaal. De purge-service die de DEK-vernietiging uitvoert, moet elke purge-gebeurtenis vastleggen in een onveranderlijke audittrail waarin het volgende wordt geregistreerd:
- De identificatie van de getroffen dataset en het voorvoegsel van het getroffen objectpad
- Het aantal objecten waarvan de versleutelingssleutel is vernietigd
- De bewaarbeleidsregel die de verwijdering in gang zette (aangeduid met regel-ID en versie)
- De identiteit van de geautomatiseerde dienst of menselijke principal die de verwijdering heeft geautoriseerd
- Een cryptografische hash van de DEK op het moment van vernietiging (als bewijs dat de sleutel vóór de vernietiging bestond, zonder de sleutel zelf te bewaren)
- Het tijdstip van de DEK-vernietiging en het attestatierecord van de HSM dat de vernietiging bevestigt
Het governanceraamwerk is alleen effectief als de uitkomsten ervan zichtbaar zijn voor de mensen die verantwoordelijk zijn voor de datakwaliteit. Een dagelijks governancedashboard — opgebouwd uit de resultaten van de datakwaliteitssweep, metrieken voor de volledigheid van catalogusregistraties, de naleving van het bewaarbeleid en samenvattingen van het auditlog — geeft data stewards het inzicht dat nodig is om problemen te signaleren en aan te pakken voordat ze doorstromen naar curated datasets voor analisten. Het dashboard zelf moet worden ingezet binnen het passende netwerksegment voor het classificatieniveau en de data ervan moet uitsluitend uit dat segment afkomstig zijn — een governancedashboard voor data die als Geheim is geclassificeerd mag geen metrieken ophalen uit niet-geclassificeerde monitoringinfrastructuur. Governance behandelen als een bijzaak die infrastructuur kan delen met diensten van een lager classificatieniveau is een veelvoorkomende architectuurfout die zowel compliance-risico's als een operationele blinde vlek oplevert voor de datakwaliteit van de gevoeligste inhoud van de data lake.