Izolarea multi-tenant in SaaS pentru aparare: separarea clientilor clasificati in infrastructura partajata

Platformele SaaS pentru aparare se confrunta cu o tensiune structurala pe care software-ul civil multi-tenant nu o are. Un furnizor comercial de SaaS se preocupa de separarea logica a datelor intre clienti pentru a preveni expunerea accidentala. Un furnizor de SaaS pentru aparare trebuie sa obtina o garantie mult mai puternica: ca datele apartinand unui tenant clasificat sunt in mod demonstrabil inaccesibile altui tenant, chiar daca un atacator a compromis codul de la nivelul aplicatiei sau a obtinut acreditari de administrator. Limbajul de reglementare este strict, divulgarea neautorizata a datelor SECRET catre un tenant fara autorizatie nu este un incident de confidentialitate, ci un eveniment de scurgere (spillage) cu consecinte juridice si operationale. Acest articol examineaza modul in care izolarea multi-tenant este proiectata, implementata si demonstrata in platformele SaaS pentru aparare care deservesc tenanti cu niveluri de clasificare diferite, cu cerinte diferite de rezidenta a datelor si limite de acreditare independente, pe infrastructura cloud clasificata bazata pe Kubernetes.

De ce este complexa multi-tenanta cand tenantii au niveluri de clasificare diferite

Arhitectura multi-tenant in software-ul comercial este in primul rand o decizie economica: partajarea resurselor de calcul, a bazelor de date si a costurilor operationale intre clienti reduce costul de livrare per client. In SaaS pentru aparare, economia este in continuare relevanta, dar cerintele de izolare impuse de clasificare introduc constrangeri pe care tiparele comerciale multi-tenant nu le pot satisface din start. Cand doi tenanti opereaza la niveluri de clasificare diferite, sa zicem, unul la SECRET si unul la UNCLASSIFIED, ei nu pot partaja un motor de baze de date, un pool de programare a containerelor sau un namespace de chei criptografice, deoarece oricare dintre aceste straturi partajate ar putea deveni un canal de transfer neautorizat de date, fie printr-o configurare gresita a interogarilor directe, fie prin atacuri de tip side-channel temporizat, fie prin instrumente de operare compromise.

Diferenta de nivel de clasificare nu este singurul factor complicat. Chiar si tenantii cu acelasi nivel de clasificare pot avea cerinte incompatibile care impun o izolare puternica: legi nationale diferite privind rezidenta datelor, reguli diferite privind pastrarea jurnalelor si accesul la audit, populatii diferite de utilizatori autorizati si suite de cifruri aprobate diferite. Un tenant al Ministerului Apararii din Regatul Unit si un tenant al Departamentului Apararii din SUA pot opera ambii la nivelul RESTRICTED/SENSITIVE, dar pot fi interzisi prin acord bilateral sa aiba datele procesate pe acelasi hardware fizic. Modelul de izolare trebuie, prin urmare, proiectat in raport cu o matrice de atribute ale tenantilor, nivelul de clasificare, jurisdictia nationala, autoritatea de audit si materialul criptografic aprobat, mai degraba decat un simplu binar inalt/scazut.

Cadrele de reglementare amplifica mizele. In cadrul unor cadre precum Ghidul privind cerintele de securitate pentru cloud computing al Departamentului Apararii al SUA si ghidul Secure by Design al Regatului Unit, un sistem care pretinde ca izoleaza tenantii clasificati trebuie sa demonstreze izolarea prin controale documentate, testare independenta si monitorizare continua, nu doar sa o afirme. Un responsabil de autorizare va cere dovezi: capturi de trafic de retea care arata absenta fluxurilor intre tenanti, jurnale ale serviciului de gestionare a cheilor care arata absenta utilizarii cheilor intre tenanti si jurnale de interogare a bazei de date care arata absenta seturilor de rezultate intre tenanti. Alegerile de arhitectura care fac dificila producerea acestor dovezi nu sunt doar incomode din punct de vedere tehnic; sunt blocaje de acreditare.

Strategii de izolare a bazei de date: schema-per-tenant, baza-de-date-per-tenant si instanta-per-tenant

Stratul bazei de date este locul unde isi au originea majoritatea esecurilor de izolare multi-tenant. Exista trei tipare, iar alegerea corecta depinde de cerintele de clasificare si de audit ale populatiei de tenanti. Schema-per-tenant plaseaza tabelele fiecarui tenant intr-o schema separata in cadrul unei singure instante a motorului de baze de date. Controlul accesului este aplicat prin roluri de baza de date cu scop limitat la fiecare schema, iar politicile de securitate la nivel de rand ofera un strat secundar de aplicare. Acest tipar are cele mai reduse costuri operationale, un singur motor de baze de date de patch-uit, monitorizat si de back-up-uit, si este adecvat atunci cand toti tenantii au acelasi nivel de clasificare, iar cerinta de izolare este logica, nu fizica. Punctul slab este ca un rol configurat gresit, o vulnerabilitate de escaladare a privilegiilor in baza de date sau o interogare care ocoleste politica de securitate la nivel de rand poate expune date intre tenanti. Pentru mediile clasificate, unde un eveniment de scurgere are consecinte grave, bazarea exclusiv pe izolarea logica la nivel de schema este o pozitie dificil de aparat in fata unui responsabil de autorizare.

Baza-de-date-per-tenant aloca o instanta de baza de date dedicata pentru fiecare tenant, dar permite acelor instante sa ruleze pe infrastructura de calcul partajata. Procesul motorului de baze de date este izolat la nivelul sistemului de operare, astfel incat o schema configurata gresit sau o acreditare de aplicatie compromisa nu poate ajunge la datele altui tenant fara o escaladare separata a privilegiilor la nivel de OS. Acest tipar reduce semnificativ suprafata de atac intre tenanti si este modelul minim viabil de izolare pentru SaaS de aparare care deserveste tenanti cu niveluri de clasificare diferite. Costul operational este proportional cu numarul de tenanti: fiecare instanta de baza de date necesita propriul program de back-up, configuratie de monitorizare, flux de migrare a schemei si pool de conexiuni. La cateva zeci de tenanti acest lucru este gestionabil cu o automatizare a platformei bine proiectata; la sute, impune un strat de abstractizare de tip baza-de-date-ca-serviciu pentru a mentine efortul operational sub control.

Instanta-per-tenant duce separarea mai departe prin dedicarea nu doar a procesului bazei de date, ci a intregului nod de calcul sarcinilor de lucru ale unui singur tenant. Aceasta este necesara atunci cand documentatia de acreditare a tenantului impune separare fizica, cand canalele laterale temporizate intre tenanti sunt un model de amenintare credibil sau cand datele tenantului nu trebuie sa traverseze niciodata o tesatura de retea partajata cu alti tenanti. Costul este factura completa de infrastructura per tenant: noduri dedicate, stocare dedicata, hardware de retea dedicat in unele configuratii. Pentru tenantii cu cea mai inalta clasificare, acest cost nu este negociabil, cerinta de securitate determina arhitectura, nu economia. Platformele care deservesc un amestec de niveluri de clasificare implementeaza adesea un model pe niveluri: schema-per-tenant pentru UNCLASSIFIED, baza-de-date-per-tenant pentru SECRET, instanta-per-tenant pentru TS/SCI, cu pipeline-uri automate de provizionare care construiesc nivelul corect pornind de la un fisier de configurare a integrarii tenantului.

Izolarea namespace-urilor in Kubernetes: RBAC, politici de retea si cote de resurse per tenant

Orchestrarea containerelor introduce propriul set de vectori de expunere intre tenanti pe care izolarea bazei de date singura nu ii abordeaza. Intr-un cluster Kubernetes, un pod dintr-un namespace poate, in mod implicit, sa trimita trafic de retea catre poduri din orice alt namespace, sa listeze resurse la nivel de cluster daca contul sau de serviciu are permisiuni excesive si sa consume CPU si memorie la nivel de cluster pana cand infometeaza sarcinile de lucru vecine. Pentru o platforma SaaS de aparare, niciuna dintre aceste valori implicite nu este acceptabila. Postura de izolare trebuie aplicata ca o baza obligatorie la momentul provizionarii clusterului, aplicata de controlere de admitere care resping definitiile de sarcini de lucru neconforme si validata continuu de un motor de politici care alerteaza la abaterile de configurare.

Politica RBAC pentru Kubernetes multi-tenant de aparare porneste de la principiul ca conturile de serviciu ale fiecarui tenant au zero vizibilitate intre namespace-uri in mod implicit. Rolurile cu scop limitat la namespace sunt preferate fata de rolurile la nivel de cluster; legaturile de tip cluster-admin sunt interzise in afara namespace-ului de management dedicat al operatorului platformei. Resursele NetworkPolicy implementeaza o pozitie de respingere implicita in fiecare namespace de tenant: niciun ingress si niciun egress decat daca este permis explicit de o regula de politica. Fluxurile permise sunt inguste, podul de aplicatie al unui tenant poate comunica cu propriul pod de baza de date, cu controlerul de ingress partajat si cu endpoint-ul serviciului de gestionare a cheilor, si cu nimic altceva. Principiile arhitecturii de retea zero trust se aplica direct acestui model: fiecare flux de trafic este verificat, nimic nu este de incredere implicit pentru ca isi are originea in interiorul limitei clusterului.

Obiectele ResourceQuota impiedica un singur tenant sa declanseze o conditie de tip denial-of-service impotriva altor tenanti prin consumarea de resurse disproportionate ale clusterului. Fiecare namespace primeste cote pentru cererea si limita de CPU, cererea si limita de memorie, stocarea revendicarilor de volume persistente si numarul de poduri in executie. Obiectele LimitRange stabilesc cereri implicite de resurse pe podurile care nu le declara explicit, prevenind sarcinile de lucru neconstranse sa ocoleasca sistemul de cote. Pentru sarcinile de lucru clasificate, taint-urile de noduri si tolerantele podurilor extind izolarea in stratul fizic de programare: nodurile dedicate unui tenant de nivel SECRET poarta un taint care impiedica podurile UNCLASSIFIED sa fie programate pe ele, iar specificatiile podurilor tenantului SECRET poarta toleranta corespunzatoare. Combinatia de RBAC la nivel de namespace, NetworkPolicy, ResourceQuota si taint-uri de noduri ofera un model de izolare stratificat care este auditabil, fiecare strat este documentat, testabil si verificabil independent.

Izolarea cheilor de criptare: ierarhii de chei separate pentru fiecare tenant clasificat

Criptarea este controlul care face ca izolarea datelor sa se mentina chiar daca izolarea la nivel de infrastructura esueaza. Daca datele unui tenant SECRET sunt criptate cu o cheie la care doar procesele autorizate ale acelui tenant pot accesa, atunci o politica de retea configurata gresit sau un proces de container evadat nu poate citi datele chiar daca obtine acces la octetii bruti de stocare. Aceasta garantie impune ca cheile de criptare ale fiecarui tenant sa fie gestionate intr-un namespace criptografic inaccesibil altor tenanti, nu doar prin politica la nivelul aplicatiei, ci prin propria aplicare a controlului accesului de catre serviciul de gestionare a cheilor.

Implementarea practica foloseste o structura ierarhica de chei. La radacina se afla o cheie de criptare a cheilor (KEK) specifica tenantului, stocata intr-o partitie de modul de securitate hardware (HSM) sau intr-un namespace al serviciului de gestionare a cheilor cu scop limitat la conturile de serviciu ale acelui tenant. KEK-ul impacheteaza un set de chei de criptare a datelor (DEK) care sunt folosite de aplicatie pentru a cripta categorii specifice de date: un DEK pentru inregistrarile operationale, unul pentru jurnalele de audit, unul pentru atasamente si asa mai departe. DEK-urile sunt stocate criptate alaturi de datele pe care le protejeaza; ele pot fi despachetate doar de un proces caruia i s-a acordat acces la KEK-ul tenantului. Daca un atacator compromite un DEK izolat, poate decripta acea categorie de date. Daca compromite KEK-ul, poate decripta potential toate datele tenantului, dar nu il poate folosi pentru a accesa datele altui tenant, deoarece KEK-ul celuilalt tenant se afla intr-o partitie HSM separata sau un namespace de gestionare a cheilor cu politici de acces complet independente. Mediile de calcul confidential extind acest model prin protejarea operatiunii de despachetare a DEK-ului in sine in interiorul unui mediu de executie de incredere verificat hardware.

Politica de rotatie a cheilor este la fel de importanta ca structura cheilor. Un tenant al carui KEK nu a fost rotit de doi ani are o raza de explozie in expansiune: orice acreditare care a fost compromisa la un moment dat in ultimii doi ani acorda potential in continuare acces la toate datele criptate sub acel KEK. Platformele SaaS de aparare ar trebui sa aplice rotatia automata a KEK-ului dupa un program definit de autoritatea de clasificare a tenantului, de obicei anual pentru SECRET, mai frecvent pentru clasificari mai inalte, si sa ofere o pista de audit a rotatiei vizibila in timpul revizuirilor de acreditare. Evenimentul de rotatie in sine trebuie jurnalizat in fluxul de audit al tenantului, marcat temporal si atribuit politicii automate de rotatie sau contului specific de operator care l-a declansat.

Aplicarea rezidentei datelor: pastrarea datelor tenantilor in jurisdictiile autorizate

Cerintele de rezidenta a datelor pentru tenantii de aparare sunt adesea obligatii juridice obligatorii mai degraba decat preferinte. Un tenant care opereaza sub legislatia de securitate nationala poate fi interzis sa aiba datele procesate sau stocate pe infrastructura situata in afara jurisdictiei sale nationale, indiferent de asigurarile contractuale ale furnizorului de cloud. Aplicarea acestor cerinte intr-o platforma SaaS multi-tenant necesita mai mult decat etichetarea datelor cu o eticheta de jurisdictie, necesita controale arhitecturale care impiedica datele sa paraseasca fizic regiunea autorizata, combinate cu dovezi de audit ca acele controale au functionat corect pe intreaga perioada de pastrare a datelor.

Controlul principal este topologia infrastructurii: instantele de baze de date, bucket-urile de stocare si pool-urile de noduri de calcul specifice tenantului sunt provizionate exclusiv in regiunea cloud a jurisdictiei autorizate. Replicarea intre regiuni este dezactivata la straturile de stocare si de baze de date pentru tenantii constransi de rezidenta, chiar si in scopuri de recuperare in caz de dezastru, o replica intr-o jurisdictie neautorizata este o incalcare a rezidentei indiferent de scopul ei. Modelul de recuperare in caz de dezastru pentru acesti tenanti trebuie sa foloseasca redundanta in cadrul jurisdictiei: implementari pe mai multe zone de disponibilitate in cadrul unei singure regiuni cloud nationale, cu replicare sincrona intre zone. Aceasta constrangere obliga arhitectii de SaaS de aparare sa trateze tenantii constransi de rezidenta ca partitii de infrastructura distincte, mai degraba decat sa ii trateze ca parametri intr-un model unificat de implementare globala.

Controalele secundare abordeaza caile de date care sunt mai putin evident relevante pentru rezidenta: redirectionarea jurnalelor, telemetria de monitorizare si instrumentele de suport. O platforma care constrange corect stocarea datelor la o regiune autorizata, dar redirectioneaza jurnalele aplicatiei catre un SIEM operat in alta tara, are o lacuna de rezidenta. In mod similar, sesiunile de administrare la distanta care tranziteaza statia de lucru a unui inginer de suport intr-o jurisdictie neautorizata pot transporta fragmente de date in starea sesiunii. Platformele SaaS de aparare trebuie sa traseze fiecare cale de date, nu doar calea principala a datelor aplicatiei, si sa aplice controale de rezidenta tuturor acestora. Acest lucru necesita de obicei o infrastructura de monitorizare separata per zona de rezidenta si controale stricte privind ce conturi de operator pot initia sesiuni administrative impotriva caror medii de tenant.

Gestionarea limitelor de acreditare: cine detine ATO-ul cand tenantii partajeaza infrastructura

Limitele autorizatiei de operare (ATO) devin ambigue structural intr-o platforma SaaS multi-tenant de aparare. Furnizorul platformei opereaza infrastructura partajata, planul de control Kubernetes, serviciul de gestionare a cheilor, tesatura de retea, furnizorul de identitate, si detine un ATO care acopera acele componente. Fiecare tenant opereaza sarcini de lucru ale aplicatiei si date care se afla deasupra acelei infrastructuri si poate detine un ATO separat pentru propria limita de sistem. Intrebarea unde se termina ATO-ul platformei si unde incepe ATO-ul tenantului nu este o preocupare teoretica: ea determina cine este responsabil pentru fiecare control de securitate, cine este responsabilul de autorizare pentru modificarile aduse acelui control si cine isi asuma raspunderea daca un control esueaza.

Modelul standard este o matrice de responsabilitate stratificata. ATO-ul furnizorului platformei acopera toate controalele la nivel de infrastructura: securitatea fizica a instalatiilor centrelor de date, patch-uirea hypervisorului si a runtime-ului de containere, configurarea grupurilor de securitate a retelei, disponibilitatea si jurnalizarea accesului serviciului de gestionare a cheilor, precum si controalele de izolare documentate mai sus. Programul de monitorizare continua al furnizorului platformei trebuie sa produca dovezi ca aceste controale functioneaza corect pentru toti tenantii simultan, fara a expune datele de monitorizare ale unui tenant catre altul. ATO-ul fiecarui tenant mosteneste controalele platformei prin referinta, planul de securitate al sistemului tenantului citeaza pachetul ATO al platformei ca dovada ca controalele de infrastructura sunt satisfacute, si documenteaza doar controalele specifice tenantului: configurarea de securitate la nivelul aplicatiei, marcajele de clasificare a datelor, populatia de utilizatori autorizati si politica de chei de criptare specifica tenantului.

Gestionarea modificarilor la nivelul platformei declanseaza obligatii de re-acreditare care se propaga catre tenanti. Cand furnizorul platformei modifica o componenta partajata, actualizeaza versiunea Kubernetes, schimba mecanismul de aplicare a politicii de retea, modifica modelul de politica de acces al serviciului de gestionare a cheilor, responsabilul de autorizare al fiecarui tenant trebuie sa revizuiasca modificarea si sa confirme ca controalele mostenite ale tenantului sunt inca valide. Acest lucru creeaza un cost de coordonare care creste odata cu numarul de tenanti: o singura actualizare a platformei poate necesita notificarea si obtinerea confirmarii de la zeci de responsabili de autorizare independenti. Platformele SaaS de aparare care gestioneaza bine acest lucru investesc intr-un proces formal de comunicare a modificarilor, termene de notificare convenite in prealabil si formulari de tip sablon pe care responsabilii de autorizare ai tenantilor le pot folosi pentru a-si documenta deciziile de re-acreditare cu minim de refacere.

Jurnalizarea de audit per tenant: piste de audit segregate pentru investigatii intre tenanti

Jurnalizarea de audit intr-un mediu clasificat multi-tenant trebuie sa satisfaca doua cerinte aparent contradictorii. Jurnalele de audit ale fiecarui tenant trebuie sa fie izolate, accesibile auditorilor autorizati ai acelui tenant si nu vreunui alt tenant, iar operatorul platformei trebuie sa pastreze accesul la jurnalele tuturor tenantilor pentru raspuns la incidente si investigatii criminalistice la nivel de platforma. Rezolvarea acestei tensiuni necesita un model de date clar: jurnalele de audit ale tenantului sunt date detinute de tenant, accesul la care de catre operatorul platformei este el insusi o actiune jurnalizata si responsabila, supusa acelorasi cerinte de audit ca orice alt eveniment de acces privilegiat.

Tiparul arhitectural este o destinatie de jurnal per tenant cu controale de imutabilitate si jurnalizare a accesului la nivelul destinatiei. Evenimentele de aplicatie si de infrastructura ale fiecarui tenant sunt directionate catre un grup de jurnale dedicat sau o partitie de stocare a obiectelor cu o politica de doar-scriere pentru stratul de aplicatie si o politica de doar-citire pentru auditorii autorizati ai tenantului. Politicile de blocare a obiectelor impiedica stergerea sau modificarea inregistrarilor de jurnal pe durata perioadei de pastrare. Operatorul platformei detine un rol administrativ separat care acorda acces de citire la toate destinatiile de jurnale ale tenantilor, dar fiecare exercitare a acelui rol genereaza un eveniment de acces care este adaugat in propriul flux de audit al tenantului, vizibil auditorilor tenantului in timpul urmatoarei lor revizuiri. Acest design inseamna ca un tenant poate raspunde intotdeauna la intrebarea „a citit cineva din afara organizatiei noastre jurnalele noastre de audit?” examinandu-si propriul flux de audit.

Investigatia criminalistica intre tenanti, reconstruirea unui incident care ar fi putut implica mai multi tenanti, impune ca operatorul platformei sa coreleze evenimentele intre mai multe destinatii de jurnale izolate. Aceasta corelare trebuie efectuata folosind instrumente cu privilegii de operator al platformei care ele insele genereaza inregistrari de audit, mai degraba decat prin imbinarea fluxurilor de jurnale ale tenantilor intr-un strat de stocare partajat. O baza de date de audit partajata care stocheaza evenimente de la mai multi tenanti ar recrea problema amestecarii datelor intre tenanti pe care arhitectura cu destinatii de jurnale izolate a fost proiectata sa o previna. In schimb, instrumentele criminalistice interogheaza independent destinatia de jurnal a fiecarui tenant si asambleaza cronologia intre tenanti in memorie, intr-un mediu de operator izolat de toate mediile tenantilor si el insusi supus jurnalizarii de audit. Acest tipar pastreaza izolarea jurnalelor tenantilor, permitand in acelasi timp capacitatea criminalistica la nivel de platforma de care au nevoie echipele de operatiuni de securitate.