Multi-tenant isolatie in defensie-SaaS: geclassificeerde klanten scheiden in gedeelde infrastructuur

Defensie-SaaS-platforms staan voor een structurele spanning die civiele multi-tenant software niet kent. Een commerciële SaaS-leverancier maakt zich zorgen over logische datascheiding tussen klanten om onbedoelde blootstelling te voorkomen. Een defensie-SaaS-leverancier moet een veel sterkere garantie realiseren: dat gegevens die toebehoren aan één geclassificeerde tenant aantoonbaar onbereikbaar zijn voor een andere tenant, zelfs als een aanvaller applicatiecode heeft gecompromitteerd of beheerdersinloggegevens heeft bemachtigd. De regelgevende taal is streng. Een ongeautoriseerde openbaarmaking van SECRET-gegevens aan een niet-gescreende tenant is geen privacyincident, het is een spillage-gebeurtenis met juridische en operationele gevolgen. Dit artikel onderzoekt hoe multi-tenant isolatie wordt ontworpen, geïmplementeerd en aangetoond in defensie-SaaS-platforms die tenants op verschillende classificatieniveaus bedienen, met verschillende datalokatie-eisen en onafhankelijke accreditatiegrenzen, over op Kubernetes gebaseerde geclassificeerde cloudinfrastructuur.

Waarom multi-tenancy complex is wanneer tenants verschillende classificatieniveaus hebben

Multi-tenant architectuur in commerciële software is primair een economische beslissing: het delen van rekenkracht, database en operationele overhead over klanten verlaagt de leveringskosten per klant. In defensie-SaaS zijn de economische aspecten nog steeds relevant, maar de isolatievereisten die door classificatie worden opgelegd introduceren beperkingen die commerciële multi-tenant patronen niet kant-en-klaar kunnen vervullen. Wanneer twee tenants op verschillende classificatieniveaus werken, bijvoorbeeld één op SECRET en één op UNCLASSIFIED, kunnen zij geen database-engine, container-planningspool of cryptografische sleutel-namespace delen, omdat elk van die gedeelde lagen een kanaal voor ongeautoriseerde dataoverdracht zou kunnen worden, hetzij door directe queryconfiguratiefouten, side-channel timingaanvallen of gecompromitteerd beheerderstooling.

De kloof in classificatieniveau is niet de enige complicerende factor. Zelfs tenants op hetzelfde classificatieniveau kunnen onverenigbare eisen hebben die sterke isolatie vereisen: verschillende nationale datalokatiewetten, verschillende regels voor logbewaring en audittoegang, verschillende geautoriseerde gebruikerspopulaties en verschillende goedgekeurde cipher suites. Een tenant van het Britse Ministerie van Defensie en een tenant van het Amerikaanse Ministerie van Defensie kunnen beide op het niveau RESTRICTED/SENSITIVE werken, maar door een bilaterale overeenkomst verboden zijn hun gegevens op dezelfde fysieke hardware te laten verwerken. Het isolatiemodel moet daarom worden ontworpen tegen een matrix van tenantattributen, namelijk classificatieniveau, nationale jurisdictie, auditbevoegdheid en goedgekeurd cryptografisch materiaal, in plaats van tegen een eenvoudige hoog/laag-binaire keuze.

Regelgevende kaders versterken de inzet. Onder kaders zoals de US Department of Defense Cloud Computing Security Requirements Guide en de Britse Secure by Design-richtlijn moet een systeem dat beweert geclassificeerde tenants te isoleren die isolatie aantonen via gedocumenteerde controles, onafhankelijke tests en continue monitoring, en niet slechts beweren. Een autoriserende functionaris zal om bewijs vragen: netwerkverkeeropnames die geen kruistenant-stromen tonen, sleutelbeheerdienst-logs die geen kruistenant-sleutelgebruik tonen, en databasequery-logs die geen kruistenant-resultaatsets tonen. Architectuurkeuzes die dit bewijs moeilijk produceerbaar maken, zijn niet alleen technisch onhandig; het zijn accreditatieblokkades.

Databasisolatiestrategieën: schema-per-tenant, database-per-tenant en instance-per-tenant

De databaselaag is waar de meeste multi-tenant isolatiefouten ontstaan. Er bestaan drie patronen, en de juiste keuze hangt af van de classificatie- en auditeisen van de tenantpopulatie. Schema-per-tenant plaatst de tabellen van elke tenant in een afzonderlijk schema binnen één enkele database-engine-instance. Toegangscontrole wordt afgedwongen door databaserollen die zijn afgebakend per schema, en row-level security-beleid biedt een secundaire handhavingslaag. Dit patroon heeft de laagste operationele overhead, namelijk één database-engine om te patchen, te monitoren en back-uppen, en is geschikt wanneer alle tenants hetzelfde classificatieniveau delen en de isolatie-eis logisch is in plaats van fysiek. De zwakte is dat een verkeerd geconfigureerde rol, een kwetsbaarheid voor escalatie van databaseprivileges of een query die het row-level security-beleid omzeilt, kruistenant-gegevens kan blootstellen. In geclassificeerde omgevingen waar een spill-gebeurtenis ernstige gevolgen heeft, is uitsluitend vertrouwen op logische isolatie op schemaniveau een moeilijk te verdedigen positie tegenover een autoriserende functionaris.

Database-per-tenant wijst een toegewijde database-instance toe aan elke tenant, maar staat toe dat die instances op gedeelde rekeninfrastructuur draaien. Het database-engine-proces is geïsoleerd op besturingssysteemniveau, zodat een verkeerd geconfigureerd schema of een gecompromitteerde applicatie-inloggegeven de gegevens van een andere tenant niet kan bereiken zonder een afzonderlijke escalatie van privileges op OS-niveau. Dit patroon vermindert het kruistenant-aanvalsoppervlak aanzienlijk en is het minimaal levensvatbare isolatiemodel voor defensie-SaaS die tenants op verschillende classificatieniveaus bedient. De operationele kosten zijn evenredig met het aantal tenants: elke database-instance vereist zijn eigen back-upschema, monitoringconfiguratie, schemamigratie-workflow en connection pool. Bij tientallen tenants is dit beheersbaar met goed ontworpen platformautomatisering; bij honderden vraagt het om een database-as-a-service-abstractielaag om de operationele last begrensd te houden.

Instance-per-tenant voert de scheiding verder door door niet alleen het databaseproces maar het volledige rekenknooppunt te wijden aan de workloads van één enkele tenant. Dit is vereist wanneer de accreditatiedocumentatie van de tenant fysieke scheiding eist, wanneer kruistenant-timing-side-channels een geloofwaardig dreigingsmodel vormen, of wanneer de gegevens van de tenant nooit netwerk-fabric mogen passeren die met andere tenants wordt gedeeld. De kosten zijn de volledige infrastructuurrekening per tenant: toegewijde knooppunten, toegewijde opslag, in sommige configuraties toegewijde netwerkhardware. Voor de tenants met de hoogste classificatie is deze kostenpost niet onderhandelbaar. De beveiligingseis bepaalt de architectuur, niet de economie. Platforms die een mix van classificatieniveaus bedienen, implementeren vaak een gelaagd model: schema-per-tenant voor UNCLASSIFIED, database-per-tenant voor SECRET, instance-per-tenant voor TS/SCI, met geautomatiseerde provisioning-pijplijnen die het juiste niveau bouwen vanuit een configuratiebestand voor tenant-onboarding.

Kubernetes-namespace-isolatie: RBAC, netwerkbeleid en resourcequota's per tenant

Containerorchestratie introduceert zijn eigen reeks kruistenant-blootstellingsvectoren die databasisolatie alleen niet aanpakt. In een Kubernetes-cluster kan een pod in één namespace standaard netwerkverkeer sturen naar pods in elke andere namespace, clusterbrede resources opsommen als zijn serviceaccount overmatige rechten heeft, en clusterbrede CPU en geheugen verbruiken totdat het naburige workloads uithongert. Voor een defensie-SaaS-platform is geen van deze standaardinstellingen aanvaardbaar. De isolatiehouding moet als verplichte basislijn worden toegepast op het moment van clusterprovisioning, afgedwongen door admission controllers die niet-conforme workloaddefinities weigeren, en continu gevalideerd door een beleidsengine die waarschuwt bij configuratieafwijking.

RBAC-beleid voor multi-tenant defensie-Kubernetes begint met het principe dat de serviceaccounts van elke tenant standaard nul kruis-namespace-zichtbaarheid hebben. Namespace-scoped rollen verdienen de voorkeur boven clusterrollen; cluster-admin-bindingen zijn verboden buiten de toegewijde beheer-namespace van de platformbeheerder. NetworkPolicy-resources realiseren een standaard-weigerhouding in elke tenant-namespace: geen ingress en geen egress tenzij expliciet toegestaan door een beleidsregel. Toegestane stromen zijn smal: de applicatiepod van een tenant mag communiceren met zijn eigen databasepod, de gedeelde ingress-controller en het sleutelbeheerdienst-eindpunt, en niets anders. Principes van zero trust-netwerkarchitectuur sluiten direct aan op dit model: elke verkeersstroom wordt geverifieerd, niets wordt impliciet vertrouwd omdat het binnen de clustergrens ontstaat.

ResourceQuota-objecten voorkomen dat één enkele tenant een denial-of-service-toestand tegen andere tenants veroorzaakt door onevenredige clusterresources te verbruiken. Elke namespace ontvangt quota's op CPU-request en -limiet, geheugen-request en -limiet, persistent volume claim-opslag, en het aantal draaiende pods. LimitRange-objecten stellen standaard resource-requests in op pods die deze niet expliciet declareren, waardoor wordt voorkomen dat onbeperkte workloads het quotasysteem omzeilen. Voor geclassificeerde workloads breiden node-taints en pod-toleraties de isolatie uit naar de fysieke planningslaag: knooppunten die zijn toegewijd aan een SECRET-tenant dragen een taint die voorkomt dat UNCLASSIFIED-pods erop worden ingepland, en de pod-specs van de SECRET-tenant dragen de bijbehorende toleratie. De combinatie van namespace-RBAC, NetworkPolicy, ResourceQuota en node-taints geeft een gelaagd isolatiemodel dat auditeerbaar is. Elke laag is gedocumenteerd, testbaar en onafhankelijk verifieerbaar.

Versleutelingssleutelisolatie: afzonderlijke sleutelhiërarchieën voor elke geclassificeerde tenant

Versleuteling is de controle die datascheiding laat standhouden zelfs als isolatie op infrastructuurniveau faalt. Als de gegevens van een SECRET-tenant zijn versleuteld met een sleutel die alleen de geautoriseerde processen van die tenant kunnen benaderen, dan kan een verkeerd geconfigureerd netwerkbeleid of een ontsnapt containerproces de gegevens niet lezen, zelfs niet als het toegang krijgt tot de ruwe opslagbytes. Deze garantie vereist dat de versleutelingssleutels van elke tenant worden beheerd in een cryptografische namespace die ontoegankelijk is voor andere tenants, niet alleen via beleid op de applicatielaag, maar via de eigen toegangscontrolehandhaving van de sleutelbeheerdienst.

De praktische implementatie gebruikt een hiërarchische sleutelstructuur. Aan de wortel staat een key encryption key (KEK) die specifiek is voor de tenant, opgeslagen in een hardware security module (HSM)-partitie of een sleutelbeheerdienst-namespace die is afgebakend tot de serviceaccounts van die tenant. De KEK omhult een set data encryption keys (DEK's) die door de applicatie worden gebruikt om specifieke datacategorieën te versleutelen: één DEK voor operationele records, één voor auditlogs, één voor bijlagen, enzovoort. De DEK's worden versleuteld opgeslagen naast de gegevens die zij beschermen; zij kunnen alleen worden ontvouwd door een proces dat toegang heeft gekregen tot de KEK van de tenant. Als een aanvaller een DEK afzonderlijk compromitteert, kan hij die datacategorie ontsleutelen. Als hij de KEK compromitteert, kan hij mogelijk alle gegevens van de tenant ontsleutelen, maar hij kan deze niet gebruiken om toegang te krijgen tot de gegevens van een andere tenant, omdat de KEK van de andere tenant zich in een afzonderlijke HSM-partitie of sleutelbeheer-namespace bevindt met geheel onafhankelijk toegangsbeleid. Confidential computing-omgevingen breiden dit model uit door de DEK-ontvouwbewerking zelf te beschermen binnen een hardware-geverifieerde trusted execution environment.

Sleutelrotatiebeleid is even belangrijk als sleutelstructuur. Een tenant wiens KEK in twee jaar niet is geroteerd heeft een uitdijende blast radius: elke inloggegeven die op enig moment in de afgelopen twee jaar werd gecompromitteerd verleent mogelijk nog steeds toegang tot alle gegevens die onder die KEK zijn versleuteld. Defensie-SaaS-platforms moeten geautomatiseerde KEK-rotatie afdwingen volgens een schema dat is gedefinieerd door de classificatie-autoriteit van de tenant, doorgaans jaarlijks voor SECRET en frequenter voor hogere classificaties, en een rotatie-audittrail bieden die zichtbaar is tijdens accreditatiebeoordelingen. De rotatiegebeurtenis zelf moet worden gelogd in de auditstroom van de tenant, voorzien van een tijdstempel en toegeschreven aan het geautomatiseerde rotatiebeleid of aan het specifieke beheerdersaccount dat de rotatie heeft geactiveerd.

Handhaving van datalokatie: tenantgegevens binnen geautoriseerde jurisdicties houden

Datalokatie-eisen voor defensietenants zijn vaak bindende juridische verplichtingen in plaats van voorkeuren. Een tenant die opereert onder nationale veiligheidswetgeving kan verboden zijn zijn gegevens te laten verwerken of opslaan op infrastructuur buiten zijn nationale jurisdictie, ongeacht de contractuele garanties van de cloudaanbieder. Het handhaven van deze eisen in een multi-tenant SaaS-platform vereist meer dan het taggen van gegevens met een jurisdictielabel. Het vereist architectonische controles die voorkomen dat gegevens de geautoriseerde regio fysiek verlaten, gecombineerd met auditbewijs dat die controles correct functioneerden over de volledige bewaartermijn van de gegevens.

De primaire controle is infrastructuurtopologie: tenantspecifieke database-instances, opslag-buckets en reken-node-pools worden uitsluitend ingericht in de cloudregio van de geautoriseerde jurisdictie. Cross-region-replicatie wordt uitgeschakeld op de opslag- en databaselagen voor tenants met lokatiebeperkingen, zelfs voor disaster recovery-doeleinden. Een replica in een ongeautoriseerde jurisdictie is een lokatieschending ongeacht zijn doel. Het disaster recovery-model voor deze tenants moet redundantie binnen de jurisdictie gebruiken: multi-availability-zone-implementaties binnen één enkele nationale cloudregio, met synchrone replicatie tussen zones. Deze beperking dwingt defensie-SaaS-architecten om tenants met lokatiebeperkingen te behandelen als afzonderlijke infrastructuurpartities in plaats van als parameters in een uniform wereldwijd implementatiemodel.

Secundaire controles richten zich op de datapaden die minder voor de hand liggend lokatierelevant zijn: logdoorsturing, monitoringtelemetrie en supporttooling. Een platform dat dataopslag correct beperkt tot een geautoriseerde regio maar applicatielogs doorstuurt naar een SIEM die in een ander land wordt beheerd, heeft een lokatiekloof. Evenzo kunnen sessies voor extern beheer die het werkstation van een supportengineer in een ongeautoriseerde jurisdictie passeren datafragmenten in sessiestatus dragen. Defensie-SaaS-platforms moeten elk datapad traceren, niet alleen het primaire applicatiedatapad, en lokatiecontroles op alle toepassen. Dit vereist doorgaans afzonderlijke monitoringinfrastructuur per lokatiezone en strikte controles over welke beheerdersaccounts beheersessies tegen welke tenantomgevingen kunnen initiëren.

Beheer van accreditatiegrenzen: wie bezit de ATO wanneer tenants infrastructuur delen

Authorization to operate (ATO)-grenzen worden structureel dubbelzinnig in een multi-tenant defensie-SaaS-platform. De platformaanbieder beheert de gedeelde infrastructuur, namelijk het Kubernetes-control plane, de sleutelbeheerdienst, de netwerk-fabric en de identity provider, en houdt een ATO die die componenten dekt. Elke tenant beheert applicatieworkloads en gegevens die bovenop die infrastructuur zitten en kan een afzonderlijke ATO houden voor zijn eigen systeemgrens. De vraag waar de platform-ATO eindigt en de tenant-ATO begint is geen theoretische kwestie: deze bepaalt wie verantwoordelijk is voor elke beveiligingscontrole, wie de autoriserende functionaris is voor wijzigingen aan die controle, en wie aansprakelijk is als een controle faalt.

Het standaardmodel is een gelaagde verantwoordelijkheidsmatrix. De ATO van de platformaanbieder dekt alle controles op infrastructuurniveau: fysieke beveiliging van datacenterfaciliteiten, patching van hypervisor en container-runtime, configuratie van netwerkbeveiligingsgroepen, beschikbaarheid en toegangslogging van de sleutelbeheerdienst, en de hierboven gedocumenteerde isolatiecontroles. Het continue-monitoringprogramma van de platformaanbieder moet bewijs produceren dat deze controles voor alle tenants tegelijkertijd correct werken, zonder de monitoringgegevens van één tenant aan een andere bloot te stellen. De ATO van elke tenant erft de platformcontroles via verwijzing; het systeembeveiligingsplan van de tenant citeert het ATO-pakket van het platform als bewijs dat aan de infrastructuurcontroles is voldaan, en documenteert alleen de controles die tenantspecifiek zijn: applicatielaag-beveiligingsconfiguratie, dataclassificatiemarkeringen, geautoriseerde gebruikerspopulatie en tenantspecifiek versleutelingssleutelbeleid.

Wijzigingsbeheer op de platformlaag activeert heraccreditatieverplichtingen die naar tenants cascaderen. Wanneer de platformaanbieder een gedeelde component wijzigt, namelijk de Kubernetes-versie upgradt, het handhavingsmechanisme voor netwerkbeleid wijzigt of het toegangsbeleidsmodel van de sleutelbeheerdienst aanpast, moet de autoriserende functionaris van elke tenant de wijziging beoordelen en bevestigen dat de geërfde controles van de tenant nog geldig zijn. Dit creëert een coördinatieoverhead die groeit met het aantal tenants: één enkele platformupgrade kan vereisen dat tientallen onafhankelijke autoriserende functionarissen op de hoogte worden gesteld en bevestiging geven. Defensie-SaaS-platforms die dit goed beheren, investeren in een formeel wijzigingscommunicatieproces, vooraf overeengekomen kennisgevingstermijnen en sjabloontaal die autoriserende functionarissen van tenants kunnen gebruiken om hun heraccreditatiebeslissingen met minimale herbewerking te documenteren.

Auditlogging per tenant: gescheiden audittrails voor kruistenant-forensiek

Auditlogging in een multi-tenant geclassificeerde omgeving moet aan twee schijnbaar tegenstrijdige eisen voldoen. De auditlogs van elke tenant moeten worden geïsoleerd, toegankelijk voor de geautoriseerde auditors van die tenant en niet voor enige andere tenant, en de platformbeheerder moet toegang behouden tot de logs van alle tenants voor incidentrespons en forensisch onderzoek op platformniveau. Het oplossen van deze spanning vereist een helder datamodel: tenant-auditlogs zijn tenant-eigen gegevens waarvan de toegang door de platformbeheerder zelf een gelogde, verantwoordbare actie is die onderworpen is aan dezelfde auditeisen als elke andere geprivilegieerde toegangsgebeurtenis.

Het architectonische patroon is een logsink per tenant met onveranderlijkheidscontroles en toegangslogging op sinkniveau. De applicatie- en infrastructuurgebeurtenissen van elke tenant worden gerouteerd naar een toegewijde loggroep of object-storage-partitie met een write-only-beleid voor de applicatielaag en een read-only-beleid voor de geautoriseerde auditors van de tenant. Object-lock-beleid voorkomt verwijdering of wijziging van logrecords gedurende de bewaartermijn. De platformbeheerder houdt een afzonderlijke beheerdersrol die leestoegang verleent tot alle tenant-logsinks, maar elke uitoefening van die rol genereert een toegangsgebeurtenis die wordt toegevoegd aan de eigen auditstroom van de tenant, zichtbaar voor de auditors van de tenant tijdens hun volgende beoordeling. Dit ontwerp betekent dat een tenant altijd de vraag kan beantwoorden "heeft iemand buiten onze organisatie onze auditlogs gelezen?" door zijn eigen auditstroom te onderzoeken.

Kruistenant-forensisch onderzoek, het reconstrueren van een incident dat mogelijk meerdere tenants betrof, vereist dat de platformbeheerder gebeurtenissen correleert over meerdere geïsoleerde logsinks. Deze correlatie moet worden uitgevoerd met tooling die geprivilegieerd is voor de platformbeheerder en die zelf auditrecords genereert, in plaats van door tenant-logstromen samen te voegen in een gedeelde opslaglaag. Een gedeelde auditdatabase die gebeurtenissen van meerdere tenants opslaat, zou het kruistenant-datavermengingsprobleem opnieuw creëren dat de geïsoleerde logsink-architectuur was bedoeld te voorkomen. In plaats daarvan bevraagt forensische tooling elke tenant-logsink onafhankelijk en stelt de kruistenant-tijdlijn in het geheugen samen, in een beheerdersomgeving die geïsoleerd is van alle tenantomgevingen en zelf onderworpen is aan auditlogging. Dit patroon behoudt tenant-logisolatie en maakt tegelijkertijd de forensische capaciteit op platformniveau mogelijk die teams voor beveiligingsoperaties vereisen.