Monivuokralaiseristys puolustusalan SaaS-ratkaisuissa: luokiteltujen asiakkaiden erottaminen jaetussa infrastruktuurissa

Puolustusalan SaaS-alustat kohtaavat rakenteellisen jännitteen, jota siviilipuolen monivuokralaisilla ohjelmistoilla ei ole. Kaupallinen SaaS-toimittaja huolehtii asiakkaiden välisestä loogisesta tietojen erottelusta vahingossa tapahtuvan paljastumisen estämiseksi. Puolustusalan SaaS-toimittajan on saavutettava paljon vahvempi takuu: että yhdelle luokitellulle vuokralaiselle kuuluvat tiedot ovat todistettavasti toisen vuokralaisen ulottumattomissa, vaikka hyökkääjä olisi vaarantanut sovelluskerroksen koodin tai hankkinut ylläpitäjän tunnukset. Sääntelyn kieli on tiukkaa: SECRET-tietojen luvaton paljastuminen turvaluokittelemattomalle vuokralaiselle ei ole yksityisyysloukkaus, vaan se on vuototapahtuma, jolla on oikeudellisia ja operatiivisia seurauksia. Tämä artikkeli tarkastelee, kuinka monivuokralaiseristys suunnitellaan, toteutetaan ja osoitetaan puolustusalan SaaS-alustoissa, jotka palvelevat eri turvaluokitustasoilla olevia vuokralaisia, joilla on eri tietojen sijaintivaatimukset ja itsenäiset akkreditointirajat, Kubernetes-pohjaisessa luokitellussa pilvi-infrastruktuurissa.

Miksi monivuokralaisuus on monimutkaista, kun vuokralaisilla on eri turvaluokitustasot

Monivuokralaisarkkitehtuuri kaupallisissa ohjelmistoissa on ensisijaisesti taloudellinen päätös: laskennan, tietokannan ja operatiivisen kuorman jakaminen asiakkaiden kesken vähentää toimituksen asiakaskohtaista kustannusta. Puolustusalan SaaS-ratkaisuissa talous on edelleen merkityksellistä, mutta turvaluokituksen asettamat eristysvaatimukset tuovat rajoituksia, joita kaupalliset monivuokralaismallit eivät pysty täyttämään valmiina. Kun kaksi vuokralaista toimii eri turvaluokitustasoilla, esimerkiksi toinen SECRET- ja toinen UNCLASSIFIED-tasolla, ne eivät voi jakaa tietokantamoottoria, konttien ajoitusvarantoa eivätkä kryptografista avainnimiavaruutta, koska mikä tahansa näistä jaetuista kerroksista voisi muodostua luvattoman tiedonsiirron kanavaksi joko suoran kyselyn virhekonfiguraation, sivukanava-ajoitushyökkäysten tai vaarannetun operaattorityökalun kautta.

Turvaluokitustasojen ero ei ole ainoa monimutkaistava tekijä. Jopa samalla turvaluokitustasolla olevilla vuokralaisilla voi olla yhteensopimattomia vaatimuksia, jotka edellyttävät vahvaa eristystä: eri kansalliset tietojen sijaintilait, eri säännöt lokien säilytyksestä ja valvontapääsystä, eri valtuutetut käyttäjäjoukot ja eri hyväksytyt salausalgoritmit. Ison-Britannian puolustusministeriön vuokralainen ja Yhdysvaltain puolustusministeriön vuokralainen voivat molemmat toimia RESTRICTED/SENSITIVE-tasolla, mutta kahdenvälinen sopimus voi kieltää heidän tietojensa käsittelyn samalla fyysisellä laitteistolla. Eristysmalli on siksi suunniteltava vuokralaisten ominaisuuksien matriisia vasten, johon kuuluvat turvaluokitustaso, kansallinen lainkäyttöalue, auditointiviranomainen ja hyväksytty kryptografinen materiaali, eikä yksinkertaista korkea/matala-binääriä vasten.

Sääntelykehykset korostavat panoksia. Yhdysvaltain puolustusministeriön Cloud Computing Security Requirements Guiden ja Ison-Britannian Secure by Design -ohjeistuksen kaltaisissa kehyksissä järjestelmän, joka väittää eristävänsä luokiteltuja vuokralaisia, on osoitettava eristys dokumentoiduilla kontrolleilla, riippumattomalla testauksella ja jatkuvalla valvonnalla, ei pelkästään väitettävä sitä. Valtuuttava viranomainen pyytää näyttöä: verkkoliikenteen tallenteita, jotka osoittavat, ettei vuokralaisten välisiä virtoja ole, avaintenhallintapalvelun lokeja, jotka osoittavat, ettei vuokralaisten välistä avaintenkäyttöä ole, ja tietokannan kyselylokeja, jotka osoittavat, ettei vuokralaisten välisiä tulosjoukkoja ole. Arkkitehtuurivalinnat, jotka tekevät tämän näytön tuottamisen vaikeaksi, eivät ole vain teknisesti hankalia; ne ovat akkreditoinnin esteitä.

Tietokannan eristysstrategiat: skeema-per-vuokralainen, tietokanta-per-vuokralainen ja instanssi-per-vuokralainen

Tietokantakerros on se, jossa useimmat monivuokralaiseristyksen epäonnistumiset saavat alkunsa. Kolme mallia on olemassa, ja oikea valinta riippuu vuokralaisjoukon turvaluokitus- ja auditointivaatimuksista. Skeema-per-vuokralainen sijoittaa kunkin vuokralaisen taulut erilliseen skeemaan yhden tietokantamoottori-instanssin sisällä. Pääsynhallinta toteutetaan kuhunkin skeemaan rajatuilla tietokantarooleilla, ja rivitason tietoturvakäytännöt tarjoavat toissijaisen valvontakerroksen. Tällä mallilla on pienin operatiivinen kuorma, eli yksi tietokantamoottori paikattavaksi, valvottavaksi ja varmuuskopioitavaksi, ja se on tarkoituksenmukainen, kun kaikki vuokralaiset toimivat samalla turvaluokitustasolla ja eristysvaatimus on looginen eikä fyysinen. Heikkous on, että virheellisesti konfiguroitu rooli, tietokannan oikeuksien laajennushaavoittuvuus tai kysely, joka ohittaa rivitason tietoturvakäytännön, voi paljastaa vuokralaisten välisiä tietoja. Luokitelluissa ympäristöissä, joissa vuototapahtumalla on vakavia seurauksia, pelkkään skeematason loogiseen eristykseen luottaminen on vaikea kanta puolustaa valtuuttavalle viranomaiselle.

Tietokanta-per-vuokralainen varaa erillisen tietokantainstanssin kullekin vuokralaiselle, mutta sallii näiden instanssien ajaa jaetussa laskentainfrastruktuurissa. Tietokantamoottoriprosessi on eristetty käyttöjärjestelmätasolla, joten virheellisesti konfiguroitu skeema tai vaarannettu sovellustunnus ei voi tavoittaa toisen vuokralaisen tietoja ilman erillistä käyttöjärjestelmätason oikeuksien laajennusta. Tämä malli vähentää merkittävästi vuokralaisten välistä hyökkäyspinta-alaa ja on vähimmäiskelpoinen eristysmalli puolustusalan SaaS-ratkaisuille, jotka palvelevat eri turvaluokitustasoilla olevia vuokralaisia. Operatiivinen kustannus on suhteessa vuokralaisten määrään: kukin tietokantainstanssi vaatii oman varmuuskopiointiaikataulunsa, valvontakonfiguraationsa, skeemamigraatioiden työnkulkunsa ja yhteyspoolinsa. Kymmenillä vuokralaisilla tämä on hallittavissa hyvin suunnitellulla alustan automaatiolla; sadoilla se edellyttää tietokanta-palveluna-abstraktiokerrosta operatiivisen raadannan pitämiseksi rajattuna.

Instanssi-per-vuokralainen vie erottelun pidemmälle omistamalla yhden vuokralaisen työkuormille paitsi tietokantaprosessin myös koko laskentasolmun. Tämä on tarpeen, kun vuokralaisen akkreditointidokumentaatio edellyttää fyysistä erottelua, kun vuokralaisten väliset ajoitussivukanavat ovat uskottava uhkamalli tai kun vuokralaisen tiedot eivät saa koskaan kulkea muiden vuokralaisten kanssa jaetun verkkokuituverkon kautta. Kustannus on täysi vuokralaiskohtainen infrastruktuurilasku: omistetut solmut, omistettu tallennustila, joissakin kokoonpanoissa omistettu verkkolaitteisto. Korkeimman turvaluokituksen vuokralaisille tämä kustannus ei ole neuvoteltavissa, sillä tietoturvavaatimus ohjaa arkkitehtuuria, ei talous. Eri turvaluokitustasoja palvelevat alustat toteuttavat usein porrastetun mallin: skeema-per-vuokralainen UNCLASSIFIED-tasolle, tietokanta-per-vuokralainen SECRET-tasolle, instanssi-per-vuokralainen TS/SCI-tasolle, automatisoiduilla provisiointiputkilla, jotka rakentavat oikean tason vuokralaisen käyttöönottokonfiguraatiotiedostosta.

Kubernetesin nimiavaruuseristys: RBAC, verkkokäytännöt ja resurssikiintiöt per vuokralainen

Konttien orkestrointi tuo oman joukkonsa vuokralaisten välisiä altistumisvektoreita, joita pelkkä tietokannan eristys ei käsittele. Kubernetes-klusterissa yhden nimiavaruuden pod voi oletusarvoisesti lähettää verkkoliikennettä minkä tahansa toisen nimiavaruuden podeille, listata klusterin laajuisia resursseja, jos sen palvelutilillä on liialliset oikeudet, ja kuluttaa klusterin laajuista suoritin- ja muistikapasiteettia, kunnes se näännyttää naapurityökuormat. Puolustusalan SaaS-alustalle mikään näistä oletuksista ei ole hyväksyttävä. Eristysasetus on sovellettava pakollisena perustasona klusterin provisioinnin yhteydessä, valvottava admission controllereilla, jotka hylkäävät vaatimusten vastaiset työkuormamäärittelyt, ja validoitava jatkuvasti käytäntömoottorilla, joka hälyttää konfiguraatiopoikkeamista.

Monivuokralaisen puolustusalan Kubernetesin RBAC-käytäntö lähtee periaatteesta, että kunkin vuokralaisen palvelutileillä on oletusarvoisesti nolla nimiavaruuksien välistä näkyvyyttä. Nimiavaruuteen rajattuja rooleja suositaan klusteriroolien sijaan; cluster-admin-sidonnat ovat kiellettyjä alustan operaattorin omistaman hallintanimiavaruuden ulkopuolella. NetworkPolicy-resurssit toteuttavat oletusarvoisesti estävän asetuksen jokaisessa vuokralaisen nimiavaruudessa: ei sisääntulevaa eikä ulosmenevää liikennettä, ellei käytäntösääntö sitä nimenomaisesti salli. Sallitut virrat ovat kapeita: vuokralaisen sovelluspod voi viestiä oman tietokantapodinsa, jaetun sisääntulokontrollerin ja avaintenhallintapalvelun päätepisteen kanssa, eikä minkään muun. Zero trust -verkkoarkkitehtuurin periaatteet kuvautuvat suoraan tähän malliin: jokainen liikennevirta varmennetaan, mihinkään ei luoteta implisiittisesti pelkästään siksi, että se on peräisin klusterirajan sisältä.

ResourceQuota-objektit estävät yhtä vuokralaista aiheuttamasta palvelunestotilannetta muita vuokralaisia vastaan kuluttamalla suhteettomasti klusteriresursseja. Kukin nimiavaruus saa kiintiöt suorittimen pyynnölle ja rajalle, muistin pyynnölle ja rajalle, pysyvän taltion varauksen tallennustilalle sekä käynnissä olevien podien määrälle. LimitRange-objektit asettavat oletusresurssipyynnöt podeille, jotka eivät niitä nimenomaisesti määrittele, estäen rajoittamattomia työkuormia ohittamasta kiintiöjärjestelmää. Luokitelluissa työkuormissa solmu-taintset ja podin toleranssit laajentavat eristyksen fyysiseen ajoituskerrokseen: SECRET-tason vuokralaiselle omistetuissa solmuissa on taint, joka estää UNCLASSIFIED-podien ajoittamisen niihin, ja SECRET-vuokralaisen pod-määrittelyissä on vastaava toleranssi. Nimiavaruus-RBAC:n, NetworkPolicyn, ResourceQuotan ja solmu-taintsien yhdistelmä antaa kerroksellisen eristysmallin, joka on auditoitavissa: kukin kerros on dokumentoitu, testattava ja itsenäisesti todennettavissa.

Salausavainten eristys: erilliset avainhierarkiat kullekin luokitellulle vuokralaiselle

Salaus on kontrolli, joka saa tietojen eristyksen pitämään, vaikka infrastruktuurikerroksen eristys epäonnistuisi. Jos SECRET-vuokralaisen tiedot on salattu avaimella, jota vain kyseisen vuokralaisen valtuutetut prosessit voivat käyttää, virheellisesti konfiguroitu verkkokäytäntö tai karannut konttiprosessi ei voi lukea tietoja, vaikka se pääsisi käsiksi raakoihin tallennustavuihin. Tämä takuu edellyttää, että kunkin vuokralaisen salausavaimia hallitaan kryptografisessa nimiavaruudessa, joka on muiden vuokralaisten ulottumattomissa, ei pelkästään sovelluskerroksen käytännöllä vaan avaintenhallintapalvelun oman pääsynhallinnan valvonnalla.

Käytännön toteutus käyttää hierarkkista avainrakennetta. Juuressa on vuokralaiskohtainen avaimensalausavain (KEK), joka on tallennettu laitteistoturvamoduulin (HSM) partitioon tai avaintenhallintapalvelun nimiavaruuteen, joka on rajattu kyseisen vuokralaisen palvelutileihin. KEK kapseloi joukon datasalausavaimia (DEK), joita sovellus käyttää tiettyjen tietoluokkien salaamiseen: yksi DEK operatiivisille tietueille, yksi valvontalokeille, yksi liitteille ja niin edelleen. DEK:t tallennetaan salattuina niiden suojaamien tietojen rinnalle; ne voidaan avata vain prosessilla, jolle on myönnetty pääsy vuokralaisen KEK:hen. Jos hyökkääjä vaarantaa DEK:n erikseen, hän voi purkaa kyseisen tietoluokan salauksen. Jos hän vaarantaa KEK:n, hän voi mahdollisesti purkaa kaikkien vuokralaisen tietojen salauksen, mutta hän ei voi käyttää sitä päästäkseen toisen vuokralaisen tietoihin, koska toisen vuokralaisen KEK on erillisessä HSM-partitiossa tai avaintenhallinnan nimiavaruudessa, jolla on täysin itsenäiset pääsykäytännöt. Luottamuksellisen laskennan ympäristöt laajentavat tätä mallia suojaamalla itse DEK:n avausoperaation laitteistolla todennetussa luotetussa suoritusympäristössä.

Avainten kiertokäytäntö on yhtä tärkeä kuin avainrakenne. Vuokralaisella, jonka KEK:tä ei ole kierrätetty kahteen vuoteen, on laajeneva vaikutusalue: mikä tahansa tunnus, joka vaarantui jossain vaiheessa kahden viime vuoden aikana, antaa mahdollisesti edelleen pääsyn kaikkiin kyseisellä KEK:llä salattuihin tietoihin. Puolustusalan SaaS-alustojen tulisi pakottaa automaattinen KEK-kierto vuokralaisen turvaluokitusviranomaisen määrittelemällä aikataululla, tyypillisesti vuosittain SECRET-tasolle ja useammin korkeammille turvaluokituksille, ja tarjota kiertoauditointijälki, joka on näkyvissä akkreditointitarkastusten aikana. Kiertotapahtuma itsessään on lokitettava vuokralaisen valvontavirtaan, aikaleimattava ja kohdistettava automaattiseen kiertokäytäntöön tai siihen tiettyyn operaattoritiliin, joka sen laukaisi.

Tietojen sijaintivaatimusten valvonta: vuokralaisten tietojen pitäminen valtuutettujen lainkäyttöalueiden sisällä

Puolustusalan vuokralaisten tietojen sijaintivaatimukset ovat usein sitovia oikeudellisia velvoitteita eivätkä mieltymyksiä. Kansallisen turvallisuuslainsäädännön alaisuudessa toimivalta vuokralaiselta voidaan kieltää tietojensa käsittely tai tallennus kansallisen lainkäyttöalueensa ulkopuolella sijaitsevassa infrastruktuurissa pilvipalveluntarjoajan sopimusperäisistä vakuutuksista riippumatta. Näiden vaatimusten valvonta monivuokralaisessa SaaS-alustassa edellyttää enemmän kuin tietojen merkitsemistä lainkäyttöaluetunnisteella: se edellyttää arkkitehtonisia kontrolleja, jotka estävät tietoja fyysisesti poistumasta valtuutetulta alueelta, yhdistettynä auditointinäyttöön siitä, että nämä kontrollit toimivat oikein koko tietojen säilytysajan.

Ensisijainen kontrolli on infrastruktuuritopologia: vuokralaiskohtaiset tietokantainstanssit, tallennussäiliöt ja laskentasolmuvarannot provisioidaan yksinomaan valtuutetun lainkäyttöalueen pilvialueelle. Alueiden välinen replikointi poistetaan käytöstä tallennus- ja tietokantakerroksissa sijaintirajoitteisille vuokralaisille, myös palautumistarkoituksiin, sillä replika valtuuttamattomalla lainkäyttöalueella on sijaintirikkomus käyttötarkoituksesta riippumatta. Näiden vuokralaisten palautumismallin on käytettävä lainkäyttöalueen sisäistä redundanssia: usean saatavuusvyöhykkeen toteutuksia yhden kansallisen pilvialueen sisällä, synkronisella replikoinnilla vyöhykkeiden välillä. Tämä rajoite pakottaa puolustusalan SaaS-arkkitehdit kohtelemaan sijaintirajoitteisia vuokralaisia erillisinä infrastruktuuripartitioina sen sijaan, että kohtelisivat niitä parametreina yhtenäisessä globaalissa käyttöönottomallissa.

Toissijaiset kontrollit käsittelevät tietopolkuja, jotka ovat vähemmän ilmeisen sijaintirelevantteja: lokien edelleenlähetys, valvontatelemetria ja tukityökalut. Alustalla, joka rajoittaa tietojen tallennuksen oikein valtuutetulle alueelle mutta lähettää sovelluslokit toisessa maassa toimivaan SIEM-järjestelmään, on sijaintiaukko. Vastaavasti etähallintaistunnot, jotka kulkevat tukiinsinöörin työaseman kautta valtuuttamattomalla lainkäyttöalueella, voivat kuljettaa tietofragmentteja istuntotilassa. Puolustusalan SaaS-alustojen on jäljitettävä jokainen tietopolku, ei vain ensisijainen sovellustietopolku, ja sovellettava sijaintikontrolleja kaikkiin niistä. Tämä edellyttää tyypillisesti erillistä valvontainfrastruktuuria per sijaintivyöhyke ja tiukkoja kontrolleja siitä, mitkä operaattoritilit voivat käynnistää hallintaistuntoja mitäkin vuokralaisympäristöjä vastaan.

Akkreditointirajojen hallinta: kuka omistaa ATO:n, kun vuokralaiset jakavat infrastruktuurin

Toimintavaltuutuksen (ATO) rajat muuttuvat rakenteellisesti epäselviksi monivuokralaisessa puolustusalan SaaS-alustassa. Alustantarjoaja operoi jaettua infrastruktuuria, eli Kubernetesin hallintatasoa, avaintenhallintapalvelua, verkkokuituverkkoa ja identiteetintarjoajaa, ja sillä on ATO, joka kattaa nämä komponentit. Kukin vuokralainen operoi sovellustyökuormia ja tietoja, jotka sijaitsevat tämän infrastruktuurin päällä, ja sillä voi olla erillinen ATO omalle järjestelmärajalleen. Kysymys siitä, missä alustan ATO päättyy ja vuokralaisen ATO alkaa, ei ole teoreettinen huoli: se määrää, kuka on vastuussa kustakin tietoturvakontrollista, kuka on valtuuttava viranomainen kyseisen kontrollin muutoksille ja kuka kantaa vastuun, jos kontrolli pettää.

Vakiomalli on kerroksellinen vastuumatriisi. Alustantarjoajan ATO kattaa kaikki infrastruktuurikerroksen kontrollit: datakeskustilojen fyysinen turvallisuus, hypervisorin ja konttiajonaikaisen ympäristön paikkaus, verkon tietoturvaryhmän konfiguraatio, avaintenhallintapalvelun saatavuus ja pääsylokitus sekä edellä dokumentoidut eristyskontrollit. Alustantarjoajan jatkuvan valvonnan ohjelman on tuotettava näyttöä siitä, että nämä kontrollit toimivat oikein kaikille vuokralaisille samanaikaisesti paljastamatta yhden vuokralaisen valvontatietoja toiselle. Kunkin vuokralaisen ATO perii alustan kontrollit viittauksella, eli vuokralaisen järjestelmän tietoturvasuunnitelma viittaa alustan ATO-pakettiin näyttönä siitä, että infrastruktuurikontrollit täyttyvät, ja dokumentoi vain ne kontrollit, jotka ovat vuokralaiskohtaisia: sovelluskerroksen tietoturvakonfiguraatio, tietojen turvaluokitusmerkinnät, valtuutettu käyttäjäjoukko ja vuokralaiskohtainen salausavainkäytäntö.

Muutoksenhallinta alustakerroksessa laukaisee uudelleenakkreditointivelvoitteita, jotka kaskautuvat vuokralaisille. Kun alustantarjoaja muuttaa jaettua komponenttia, eli päivittää Kubernetes-version, vaihtaa verkkokäytännön valvontamekanismin tai muuttaa avaintenhallintapalvelun pääsykäytäntömallin, kunkin vuokralaisen valtuuttavan viranomaisen on tarkistettava muutos ja vahvistettava, että vuokralaisen perimät kontrollit ovat edelleen voimassa. Tämä luo koordinointikuormaa, joka kasvaa vuokralaisten määrän myötä: yksi alustapäivitys saattaa edellyttää ilmoittamista kymmenille itsenäisille valtuuttaville viranomaisille ja kuittauksen saamista heiltä. Puolustusalan SaaS-alustat, jotka hallitsevat tämän hyvin, investoivat muodolliseen muutosviestintäprosessiin, ennalta sovittuihin ilmoitusaikatauluihin ja mallikieleen, jota vuokralaisten valtuuttavat viranomaiset voivat käyttää uudelleenakkreditointipäätöstensä dokumentointiin mahdollisimman vähäisellä uudelleentyöllä.

Vuokralaiskohtainen valvontalokitus: erotellut valvontajäljet vuokralaisten väliseen forensiikkaan

Valvontalokituksen monivuokralaisessa luokitellussa ympäristössä on täytettävä kaksi näennäisesti ristiriitaista vaatimusta. Kunkin vuokralaisen valvontalokit on eristettävä, eli niiden on oltava kyseisen vuokralaisen valtuutettujen auditoijien saatavilla eikä minkään muun vuokralaisen, ja alustan operaattorin on säilytettävä pääsy kaikkien vuokralaisten lokeihin alustatason poikkeamiin reagoimista ja forensista tutkintaa varten. Tämän jännitteen ratkaiseminen edellyttää selkeää tietomallia: vuokralaisen valvontalokit ovat vuokralaisen omistamaa tietoa, jonka käyttö alustan operaattorin toimesta on itsessään lokitettu, vastuullinen toiminto, johon sovelletaan samoja valvontavaatimuksia kuin mihin tahansa muuhun etuoikeutettuun pääsytapahtumaan.

Arkkitehtoninen malli on vuokralaiskohtainen lokinielu, jossa on muuttumattomuuskontrollit ja pääsylokitus nielun tasolla. Kunkin vuokralaisen sovellus- ja infrastruktuuritapahtumat reititetään omistettuun lokiryhmään tai objektitallennuspartitioon, jossa on vain-kirjoitus-käytäntö sovelluskerrokselle ja vain-luku-käytäntö vuokralaisen valtuutetuille auditoijille. Object-lock-käytännöt estävät lokitietueiden poiston tai muuttamisen säilytysajan keston ajan. Alustan operaattorilla on erillinen hallintarooli, joka myöntää lukuoikeuden kaikkiin vuokralaisten lokinieluihin, mutta jokainen tuon roolin käyttö generoi pääsytapahtuman, joka liitetään vuokralaisen omaan valvontavirtaan ja joka on näkyvissä vuokralaisen auditoijille heidän seuraavassa tarkastuksessaan. Tämä rakenne tarkoittaa, että vuokralainen voi aina vastata kysymykseen: luuko kukaan organisaatiomme ulkopuolinen valvontalokejamme, tarkastelemalla omaa valvontavirtaansa.

Vuokralaisten välinen forensinen tutkinta, eli usean vuokralaisen mahdollisesti koskettaneen poikkeaman rekonstruointi, edellyttää alustan operaattorilta tapahtumien korreloimista useiden eristettyjen lokinielujen välillä. Tämä korrelointi on suoritettava alustan operaattorin etuoikeutetuilla työkaluilla, jotka itse generoivat valvontatietueita, eikä yhdistämällä vuokralaisten lokivirtoja jaettuun tallennuskerrokseen. Jaettu valvontatietokanta, joka tallentaa useiden vuokralaisten tapahtumia, loisi uudelleen vuokralaisten välisen tietojen sekoittumisongelman, jonka estämiseen eristetyn lokinielun arkkitehtuuri suunniteltiin. Sen sijaan forensiset työkalut kyselevät kunkin vuokralaisen lokinielua itsenäisesti ja kokoavat vuokralaisten välisen aikajanan muistissa, operaattoriympäristössä, joka on eristetty kaikista vuokralaisympäristöistä ja itse valvontalokituksen alainen. Tämä malli säilyttää vuokralaisten lokien eristyksen ja mahdollistaa samalla alustatason forensisen kyvykkyyden, jota tietoturvaoperaatiotiimit tarvitsevat.