RBAC naspram izolacije zakupaca: dve različite bezbednosne granice

RBAC i izolacija zakupaca rešavaju dva različita bezbednosna problema u sistemima sa više zakupaca. Kontrola pristupa zasnovana na ulogama (RBAC) određuje šta autentifikovani principal sme da radi, kao što je čitanje porudžbina, uređivanje proizvoda ili upravljanje korisnicima. Izolacija zakupaca određuje kojem zakupcu podaci, resursi i kontekst izvršavanja taj principal sme da pristupi. Korisnik može biti ispravno autentifikovan i ispravno mu dodeljena RBAC uloga, a ipak doživeti bezbednosni propust ako aplikacija dozvoli toj ulozi da radi sa resursima drugog zakupca.

Šta RBAC zaista kontroliše

RBAC je model autorizacije u kojem su dozvole povezane sa ulogama, a korisnici su dodeljeni tim ulogama. Uloga deluje kao administrativna apstrakcija između identiteta i dozvola.

NIST-ov klasičan rad o RBAC-u formalizuje ovo oko korisnika, uloga, dozvola, operacija i objekata. Praktična korist je da organizacija može da upravlja autorizacijom kroz relativno stabilne uloge zasnovane na poslu ili odgovornosti, umesto da svaku dozvolu direktno povezuje sa svakim korisnikom.

Uloga kao što je EDITOR može stoga da znači: može da čita sadržaj, piše sadržaj i objavljuje sadržaj. Uloga kao što je ACCOUNTANT može da znači: može da čita podatke za naplatu, usklađuje fakture i odobrava poravnanja.

Šta izolacija zakupaca zaista kontroliše

Izolacija zakupaca je skup mehanizama koji sprečavaju da jedan zakupac čita, menja, utiče na ili slučajno primi resurse drugog zakupca u deljenom sistemu.

Zaštićena granica je šira od redova u bazi podataka. Stanje specifično za zakupca može postojati u relacionim tabelama, objektnom skladištu, vektorskim indeksima, keševima, indeksima pretrage, porukama u redovima, fajlovima, privremenim artefaktima, pozadinskim poslovima, analitici, ograničenjima brzine i infrastrukturnim resursima.

AWS-ove SaaS smernice jasno prave razliku: autorizacija odobrava pristup resursima, dok izolacija zakupaca obezbeđuje da ti resursi ne mogu preći pogrešnu granicu zakupca čak i kada je infrastruktura deljena.

Najjednostavniji primer

Pretpostavimo da je Alice administrator za Zakupca A, a Bob administrator za Zakupca B. Oba korisnika legitimno imaju istu ADMIN ulogu.

RBAC može ispravno zaključiti da oba korisnika mogu izvršiti operaciju kao što je users.read. Ali kada Alice zatraži korisnika sa ID-jem 847, aplikacija i dalje mora da verifikuje da korisnik 847 pripada Zakupcu A.

Ako API proverava samo „Alice ima ADMIN” i zatim izvršava SELECT * FROM users WHERE id = 847, RBAC je uspeo, dok je izolacija zakupaca podbacila.

Gde se jednostavan primer zaustavlja

Stvarni sistemi često sadrže nekoliko klasa identiteta: korisnike zakupca, administratore platforme, pozadinske radnike, integracije, agente i operativne servise između zakupaca. Neki od njih legitimno prelaze granice zakupaca.

To ne uklanja potrebu za izolacijom. To znači da autoritet između zakupaca mora biti eksplicitan, uzak i odvojeno revidiran, a ne da nastaje slučajno iz globalne uloge ili neograničene veze sa bazom podataka.

Izolacija zakupaca takođe može varirati po sloju. Proizvod može deliti aplikacione servere dok razdvaja baze podataka, ili koristiti deljenu bazu podataka sa politikama na nivou reda dok premium zakupcima daje izolovano skladištenje ili računarske resurse. Ne postoji jedna univerzalna topologija izolacije.

RBAC naspram izolacije zakupaca

Autentifikacija, autorizacija i izolacija su tri različite provere

Ove provere su povezane ali se ne mogu međusobno zameniti. Autentifikacija može biti savršena dok autorizacija ne uspe. Autorizacija može biti ispravna dok izolacija zakupaca ne uspe. Bezbedna SaaS putanja zahteva sve primenljive granice.

Uloge zahtevaju opseg

Reč ADMIN je nepotpuna bez opsega. Može značiti administrator platforme, administrator zakupca, administrator projekta, administrator radnog prostora ili administrator jednog podsistema.

U sistemima sa više zakupaca, dodela uloga bi normalno trebalo da bude povezana sa članstvom u zakupcu ili drugim eksplicitnim opsegom resursa. Isti korisnik može legitimno biti ADMIN u zakupcu A i VIEWER u zakupcu B.

Globalni model uloga koji ignoriše ovu razliku može stvoriti curenje privilegija čak i kada je sama mapa dozvola ispravna.

Kontekst zakupca mora doći iz pouzdanog puta

ID zakupca koji dostavlja klijent je koristan kao selektor, ali nije dokaz autoriteta. Server mora izvesti ili verifikovati članstvo u zakupcu na osnovu autentifikovanog identiteta i trenutnih podataka o autorizaciji.

OWASP-ove trenutne smernice za multi-tenant preporučuju uspostavljanje konteksta zakupca rano u životnom ciklusu zahteva i eksplicitno upozoravaju da se klijentski zaglavlja ili parametri zahteva ne tretiraju kao dokaz autorizacije.

Ovo je važno jer trivijalna izmena zahteva sa tenant=A na tenant=B ne sme biti dovoljna da se pređe granica izolacije.

Opseg zakupca pripada pretrazi resursa

Uobičajen obrazac izolacije na nivou aplikacije je uključivanje opsega zakupca u isti upit koji razrešava resurs.

Ovaj obrazac nije jedini mogući mehanizam izolacije, ali zadržava vlasništvo nad zakupcem blizu operacije pristupa podacima i sprečava da ID objekta postane sposobnost za pristup drugim zakupcima.

Provere u aplikaciji su korisne, ali izolacija ne bi trebalo da zavisi od savršenog ponašanja programera

AWS smernice za izolaciju eksplicitno upozoravaju da se sprovođenje izolacije ne prepušta samo programerima servisa. U velikoj bazi koda, vremenom će neki upit, keš ključ ili putanja radnika možda izostaviti opseg zakupca.

Odbrana u dubinu stoga može preneti izolaciju u deljeni middleware, slojeve repozitorijuma/servisa, mehanizme politika, bezbednost na nivou redova baze podataka, namenske akreditive, odvojene šeme ili odvojene baze podataka u zavisnosti od rizika i arhitekture.

Strategije izolacije baze podataka

OWASP-ova aktuelna Multi-Tenant Security Cheat Sheet navodi odvojene baze podataka, odvojene šeme, deljene tabele sa kontrolama na nivou redova i hibridne modele. Ispravan model zavisi od nivoa pretnje, usaglašenosti, performansi i operativnih troškova.

PostgreSQL Row-Level Security može pružiti odbranu u dubinu

Sa deljenim tabelama, PostgreSQL Row-Level Security može sprovesti predikat zakupca na nivou baze podataka tako da obični upiti ne mogu videti redove van aktivne politike zakupca.

Međutim, RLS nije magija. PostgreSQL superkorisnici i uloge sa BYPASSRLS mogu zaobići politike redova. OWASP stoga preporučuje korišćenje uloge sa najmanjim privilegijama na putu zahteva i testiranje istog režima konekcije/pooling-a koji se koristi u produkciji.

Ponovno korišćenje konekcije je još jedna važna ivica: kontekst zakupca mora biti bezbedno postavljen i resetovan za svaku transakciju/zahtev kako jedna pooled konekcija ne bi mogla da procuri prethodno stanje zakupca.

Izolacija zakupca mora uključivati keševe

Upit baze podataka može biti savršeno ograničen i ipak procuriti podatke kroz deljeni keš ključ.

Ako user:42 postoji i kod Zakupca A i kod Zakupca B, globalni keš ključ može vratiti vrednost pogrešnog zakupca. Keš ključevi osetljivi na zakupca treba da uključe svaki atribut koji menja vidljivost ili semantiku rezultata, obično zakupca, korisnika, lokal, skup funkcija ili verziju dozvole.

Particionisanje keša je odbrana u dubinu, a ne zamena za autorizaciju. Zahtev i dalje mora biti autorizovan pre nego što se vrati zaštićeni keširani sadržaj.

Skladištenje datoteka i objekata zahteva sopstvenu granicu tenanta

Skladištenje objekata treba da razlikuje globalne, objekte u okviru tenanta i objekte u okviru korisnika. Sam prefiks foldera je samo konvencija imenovanja osim ako politika pristupa zaista ograničava čitanje i pisanje.

Robusniji dizajni mogu koristiti ključeve objekata svesne tenanta, politike bucket-a, odvojene bucket-e/naloge ili ključeve za šifrovanje specifične za tenanta kada rizik ili usklađenost zahtevaju jaču izolaciju.

Potpisani URL-ovi moraju biti autorizovani pre izdavanja i ograničeni na tačan objekat i operaciju. posedovanje identifikatora objekta samo po sebi ne bi trebalo da daje pristup između tenanata.

Pozadinski poslovi i redovi mogu narušiti izolaciju

Asinhroni poslovi često napuštaju kontekst originalnog HTTP zahteva, što olakšava pogrešno rukovanje propagacijom tenanta. Poruka u redu koja sadrži tenantId nije dovoljan dokaz da je producent bio autorizovan.

Radnik treba da nosi verifikovani identitet servisa/korisnika ili pouzdan omot posla, ponovo uspostavi kontekst tenanta i ponovo autorizuje posledične operacije na granici potrošača.

Izolacija tenanta takođe uključuje dostupnost. Jedan tenant ne bi trebalo da može monopolizovati deljene radnike, redove, bazene konekcija ili računske resurse na način koji materijalno degradira druge tenante.

Pretraga i RAG zahtevaju preuzimanje svesno tenanta

Multi-tenant AI uvodi još jednu kopiju problema izolacije. Dokumenti mogu biti podeljeni u delove, ugrađeni i sačuvani u vektorskom indeksu nakon unosa.

OWASP-ove trenutne smernice za RAG bezbednost navode da kontrola pristupa mora biti sprovedena u trenutku preuzimanja i da delovi od Tenanta A ne smeju biti preuzeti upitima od Tenanta B. Ne može se jednostavno pretpostaviti da dozvole na nivou dokumenta automatski preživljavaju deljenje.

Vektorski indeks stoga zahteva metapodatke o tenantu/pristupu ili fizički/logički odvojene kolekcije u skladu sa dizajnom izolacije. Filteri za preuzimanje treba da se primenjuju pre nego što neovlašćeni sadržaj može ući u kontekst modela.

Izvedeni podaci nasleđuju osetljivost tenanta

Ugrađivanja, indeksi pretrage, sličice, generisani rezimei, keševi, redovi analitike i AI odgovori izvedeni su iz izvornih podataka. Njihov obim tenanta treba da prati izvor osim ako eksplicitna transformacija stvara legitiman deljeni/globalni artefakt.

Brisanje i odjava stoga moraju da se propagiraju izvan kanonskog reda. Uklanjanje dokumenta tenanta dok ostaju delovi koji se mogu pretraživati ili keširani rezimei može zadržati izloženost između tenanata ili nakon perioda zadržavanja.

Nije sve vlasništvo tenanta

Multi-tenant platforme često imaju namerno globalne resurse: taksonomije proizvoda, javne šablone, sistemske dozvole, definicije funkcija ili javni sadržaj.

Najbezbedniji model je eksplicitna klasifikacija: globalno, u okviru zakupca, u okviru korisnika ili eksplicitno između zakupaca. Nejasni resursi su mesto gde počinje slučajno curenje.

Namerno deljeni objekat treba da ima dokumentovan razlog zašto je globalan, a ne da mu jednostavno nedostaje povezanost sa zakupcem.

Administratori platforme zahtevaju drugačiji model ovlašćenja

Operater platforme može morati da pregleda više zakupaca radi podrške, usklađenosti ili infrastrukturnih operacija. Modelovanje ovoga kao običnog ADMIN-a zakupca sa slučajnim globalnim pristupom bazi podataka slabi i bezbednost i mogućnost revizije.

Bolji dizajn koristi poseban identitet platforme ili eksplicitnu dozvolu između zakupaca, jaču autentifikaciju, ograničenje svrhe, detaljnu reviziju i, gde je prikladno, kontrole odobrenja ili prinudnog pristupa.

Pristup između zakupaca bi stoga trebalo da bude imenovana sposobnost, a ne odsustvo filtera zakupca.

RBAC se može kombinovati sa atributima

Neke odluke zavise od više od uloge. Članstvo u zakupcu, region, vlasnik resursa, nivo pretplate, vreme, članstvo u projektu ili klasifikacija podataka mogu uticati na pristup.

RBAC i ABAC se ne isključuju međusobno. AWS-ove trenutne smernice za autorizaciju u više zakupaca razmatraju RBAC, ABAC i hibridne modele. Uloga može definisati široku odgovornost dok atributi ograničavaju kojoj konkretnoj instanci resursa se može pristupiti.

Ključno arhitektonsko pravilo ostaje: ne kodirajte izolaciju zakupaca samo kao slučajni naziv uloge ako je identitet zakupca granica resursa prvog reda.

Odluke o autorizaciji su najmanje dvodimenzionalne

Dokaz originalne implementacije: Aaasaasa AI CMS

RBAC servis definiše tipizirane kodove dozvola kao što su cms.content.read, shop.orders.write, billing.reconcile i users.roles. Sistemske uloge mapiraju te dozvole u imenovane skupove odgovornosti.

Zapisi uloga se kreiraju i razrešavaju sa tenantId. Sistemske uloge se ažuriraju ili ubacuju korišćenjem složenog identiteta zakupac/kod, a listanje uloga je filtrirano po zakupcu.

Ažuriranje i brisanje uloge prvo razrešava ulogu koristeći i ID uloge i ID zakupca. Dodele uloga korisnicima se takođe čuvaju i zamenjuju u okviru trenutnog konteksta zakupca.

Razrešavanje dozvola čita eksplicitne dodele uloga korisnicima ograničene i tenantId i userId. Ovo sprečava da dodela uloge jednog zakupca automatski postane dodela uloge drugog zakupca.

Na API nivou, administrativne RBAC rute razrešavaju kontekst zakupca pre kreiranja ili izmene uloga. To je ispravan smer: administracija dozvola i sama mora poštovati zakupništvo.

Zašto je ova razlika još važnija za AI agente

AI agenti mogu pretvoriti grešku u dozvolama u niz akcija. Ako agent dobije široki alat orders.read bez prinude ograničene na zakupca, greška u rezonovanju ili prompt-injection može izazvati čitanje između zakupaca mašinskom brzinom.

Opisi alata agenta mogu pominjati ograničenja zakupca, ali prinuda se i dalje mora odvijati u pouzdanom sloju izvršavanja/usluge/podataka. Uputstva na prirodnom jeziku nisu granica autorizacije.

Isto važi i za RAG: agent može imati dozvolu da koristi alat za pretragu, dok pozadina pretrage i dalje mora sprečiti da upit Zakupca A vrati delove Zakupca B.

Testirajte RBAC i izolaciju zakupaca odvojeno

OWASP smernice za regresiju autorizacije posebno ističu testove granica između zakupaca jer promene koda u keširanju, upitima ili deljenim uslugama mogu tiho pokvariti izolaciju čak i kada testovi uloga nastave da prolaze.

Uobičajeni načini neuspeha

Uobičajene zablude

Praktičan redosled dizajna

RBAC + kontrolna lista izolacije zakupaca

Rubni slučajevi i ograničenja

Korisnik može pripadati većem broju tenanata. Trenutni tenant bi stoga trebalo da bude eksplicitni kontekst izvršavanja, a ne da se trajno izvodi iz korisničkog naloga.

Neki resursi se namerno dele između odabranih tenanata, kao što su prostori za saradnju ili podaci konzorcijuma. To zahteva eksplicitni model deljenja; pretvaranje da resurs pripada jednom tenantu i dodavanje izuzetaka kasnije obično stvara dvosmislenu autorizaciju.

Izolacija od bučnih suseda je povezana, ali različita od izolacije poverljivosti. Tenant možda nikada neće videti podatke drugog tenanta, ali i dalje može da iscrpi deljene CPU resurse, kapacitet reda čekanja ili veze sa bazom podataka. Ograničenja brzine i kvote resursa stoga mogu biti svesne tenanta kao granica dostupnosti.

Fizička izolacija nije automatski bezbedna ako akreditivi kontrolne ravni ili administrativne putanje mogu preći granice. Logička izolacija nije automatski slaba ako se politike centralno sprovode, uz najmanje privilegije i temeljno testiranje.

Zahtevi za izolaciju tenanata mogu se razlikovati po klasi podataka. Podaci javnog kataloga, evidencija naplate i privatni AI dokumenti mogu opravdati različite granice skladištenja i enkripcije unutar istog SaaS proizvoda.

Šta bi promenilo ovaj odgovor?

Tačna implementacija se menja u zavisnosti od arhitekture: serverless API-ji, Kubernetes, PostgreSQL, skladištenje objekata, vektorske baze podataka i mehanizmi politika izlažu različite primitive izolacije.

Potrebna snaga se takođe menja u zavisnosti od regulative, ugovora sa klijentima, osetljivosti podataka, modela pretnji i operativnog obima. Neki tenanti mogu opravdati izolovane baze podataka ili infrastrukturu, dok drugi dele zajedničke resurse.

Konceptualna razlika se ne menja: dozvola za izvršavanje operacije nije isto što i dozvola za prelazak granice tenanta.

Povezano kanonsko znanje

S01 je preduslov bezbednosne granice za Enterprise AI Architecture i AI Governance. Kada AI alati, RAG ili agenti rade nad podacima više tenanata, identitet tenanta mora da putuje kroz pretragu, izvršavanje alata, memoriju, keševe i revizorske tragove.

Takođe se direktno povezuje sa Agentic AI: sposobnost alata i dozvola uloge i dalje moraju biti ograničene vlasništvom tenanta pre nego što agent može da čita ili menja poslovne resurse.

Za RAG, izolacija tenanata mora biti sprovedena pre nego što zaštićeni delovi dođu u kontekst modela.

Često postavljana pitanja

Pojmovnik

Zaključak

RBAC i izolacija zakupaca su komplementarni, a ne konkurentski bezbednosni mehanizmi. RBAC strukturira operativne dozvole; izolacija zakupaca ograničava granicu resursa unutar koje te dozvole mogu da se primenjuju.

Robustan zahtev sa više zakupaca stoga zahteva više od „korisnik ima ulogu ADMIN“. Potreban je verifikovani subjekat, verifikovani kontekst zakupca, dozvoljena operacija, cilj u okviru zakupca i primena na svakom sloju resursa koji može da nosi podatke u vlasništvu zakupca.

Najkraće pouzdano pravilo je: autorizuj radnju, zatim izoluj obim — i nikada ne pretpostavljaj da jedno dokazuje drugo.

Primarni izvori i aktuelne smernice

Izvori navedeni u nastavku podržavaju definiciju RBAC-a i aktuelne smernice za izolaciju zakupaca. Odsek Aaasaasa AI CMS predstavlja originalne dokaze o implementaciji i namerno je ograničen na obrasce koda koji su verifikovani.