Izolarea tenanturilor SaaS înseamnă că un client poate accesa numai înregistrările și operațiunile pe care organizația sa are dreptul să le folosească. Un selector de tenant în interfață nu este suficient. Limita trebuie respectată când cererile, sarcinile de fundal, cache-urile și descărcările de fișiere ajung la sistemele subiacente.
Testați izolarea tenanturilor folosind organizații separate, roluri obișnuite de utilizator și încercări deliberate de traversare a limitelor. Verificați citirile, scrierile, fișierele, răspunsurile din cache și lucrările de fundal după aceleași reguli de acces. Solicitați dovezi de la limita impusă în backend înainte de a primi clienți cu înregistrări sensibile sau importante comercial.
Imaginați-vă un portal de clienți în care fiecare organizație își vede propriile comenzi de achiziție. Ecranul listei pare corect, dar un export descărcat conține rândurile altei organizații. Acesta este un eșec de izolare chiar dacă autentificarea și ruta obișnuită a paginii funcționează conform intenției.
Acest ghid ajută un responsabil să definească domeniul verificării și remedierii. Nu afirmă că o anumită organizare a bazei de date garantează securitatea sau că o listă de verificare înlocuiește evaluarea completă a aplicației.
Definiți izolarea tenanturilor SaaS înainte de alegerea stocării
Identificați ce înseamnă un tenant în produs. Poate fi o organizație client, o entitate juridică sau un spațiu de lucru. Înregistrați cum utilizatorii se alătură, părăsesc și schimbă tenanturile și ce roluri de suport pot acționa între ele. Ambiguitatea acestor reguli devine ambiguitate în teste.
Ghidul OWASP de securitate multi-tenant descrie izolarea la limitele bazei de date, cache-ului, stocării și procesării. Distinge și între un selector de tenant furnizat de client și autoritatea verificată de server. Folosiți această distincție când evaluați traseul real al cererii din produs.
Definiți explicit proprietatea datelor. Un catalog comun de produse poate fi deliberat vizibil pentru mai mulți clienți, în timp ce notele comenzilor aparțin tenantului. Testele trebuie să cunoască diferența, pentru a identifica scurgerile fără să clasifice informațiile partajate deliberat ca defecte.
Cartografiați excepția administrativă. Dacă personalul de suport poate examina înregistrările unui client, explicați cine acordă accesul, cum este delimitat și cum se înregistrează utilizarea. Un traseu puternic de suport trebuie testat ca funcție intenționată, nu ascuns în afara modelului normal de tenant.
Urmăriți contextul tenantului prin cerere
Începeți cu un utilizator autentificat și verificați apartenența actuală sau autoritatea de serviciu. Urmăriți tenantul selectat în logica de afaceri și accesul la date. Verificați dacă schimbarea unui antet, a unei valori din rută sau a corpului cererii nu poate substitui autoritatea altei organizații.
Identificatorii aparent aleatorii pot îngreuna ghicitul, dar nu stabilesc permisiunea. Ghidul OWASP privind autorizarea recomandă verificarea accesului la fiecare cerere. Testați un identificator obținut legitim de la alt tenant, în loc să vă bazați pe capacitatea testerului de a-l ghici.
| Limită | Schimbare încercată, ilustrativă | Rezultat acceptat |
|---|---|---|
| Căutarea înregistrării | Solicitați identificatorul cunoscut al comenzii altui tenant | Refuz fără divulgarea înregistrării |
| Actualizare | Trimiteți identificatorul altui tenant într-un payload valid | Nicio modificare neautorizată |
| Schimbarea tenantului | Selectați o organizație fără apartenență | Serverul respinge domeniul solicitat |
| Endpoint în masă | Includeți identificatori de la tenanturi diferite | Respingere definită fără scurgere parțială |
| Acțiune de suport | Folosiți un rol obișnuit pe o rută privilegiată | Refuz și dovezi utile de investigație |
Repetați raționamentul pentru căutare, exporturi și API-uri alternative. Primul ecran de detalii corect nu dovedește că un raport în masă, un endpoint mobil sau o rută veche de compatibilitate impune aceeași limită.
Comparați abordările bazei de date prin controalele reale
Bazele de date separate, schemele și tabelele comune creează compromisuri operaționale diferite. Niciuna nu elimină nevoia verificării acreditărilor, rolurilor, interogărilor și traseelor administrative. Propunerea trebuie să identifice unde este impusă limita și ce s-ar întâmpla dacă aplicația omite un filtru.
| Abordare | Limită de examinat | Lucrări operaționale de inclus |
|---|---|---|
| Baze de date separate | Autoritatea conexiunilor și acreditărilor | Provisionare, migrări și separarea backupurilor |
| Scheme separate | Roluri de bază de date și selectarea spațiului de nume | Permisiuni, disciplină de migrare și acces administrativ |
| Tabele comune | Proprietatea tenantului și politicile impuse de acces | Acoperirea interogărilor, rolurile cererilor și teste negative |
| Hibrid | Regula documentată pentru fiecare clasă de date | Rutare clară și investigarea consecventă a incidentelor |
Evitați tratarea migrării la baze de date separate ca soluție implicită pentru fiecare defect. O eroare de autorizare delimitată poate avea o reparație țintită. În egală măsură, adăugarea unui filtru într-un singur controller este insuficientă dacă exporturile, sarcinile și instrumentele de suport folosesc în continuare acces nerestricționat.
Testați rolul folosit efectiv de cererile de producție
Documentația PostgreSQL pentru securitatea la nivel de rând explică excepții importante, inclusiv rolurile privilegiate și proprietatea tabelelor. Când produsul se bazează pe politici de rând, verificați-le cu rolul restricționat real al cererii. Un test executat ca administrator al bazei de date nu reprezintă limita aplicației obișnuite.
Includeți conturile de implementare și migrare în inventar. Acestea pot necesita legitim un acces mai larg, dar nu trebuie să devină identitatea obișnuită pentru cererile clienților. Documentați cum obține runtime-ul autoritatea urmărită și cum este verificat aranjamentul după implementare.
Verificați cache-urile, fișierele și rezultatele derivate
Examinați cheile cache-ului și domeniul rezultatelor memorate. O intrare creată pentru o organizație nu trebuie să devină răspuns pentru alta deoarece ambele cereri folosesc o rută sau un filtru comod. Testați al doilea tenant după ce primul a populat cache-ul.
Fișierele necesită propriile dovezi de acceptare. Verificați proprietatea încărcărilor, accesul la previzualizări, descărcările și rapoartele generate. O pagină poate refuza corect accesul, în timp ce URL-ul unui atașament rămâne disponibil printr-o rută neînrudită. Includeți linkurile vechi și cele emise anterior în domeniul convenit al testelor.
Verificați datele derivate, precum indexurile de căutare, recomandările și exporturile analitice. Stabiliți dacă sistemul impune restricțiile tenantului la recuperarea datelor, nu doar la inserare. Informațiile pot traversa o limită printr-un rezumat chiar dacă endpointul înregistrării sursă este protejat.
Folosiți date de test controlate care aparțin unor organizații distincte. Oferiți fiecăreia suficient conținut recognoscibil pentru identificarea contaminării fără copierea documentelor reale ale clienților în evaluare. Astfel este mai ușor de diagnosticat un rezultat neașteptat din cache sau un export amestecat.
Testați sarcinile de fundal și schimbările de apartenență
Lucrările de fundal trebuie să transmită contextul verificat al tenantului prin coadă până la operațiune. Verificați ce se întâmplă dacă o sarcină este întârziată, reîncercată sau preluată de alt worker. Un domeniu valid de tenant în cererea web nu dovedește că sarcina ulterioară îl păstrează.
Testați schimbările de apartenență. Un utilizator eliminat dintr-o organizație nu trebuie să păstreze accesul obișnuit printr-o sesiune din cache, un export salvat sau o operațiune în așteptare, contrar politicii convenite. Definiți comportamentul urmărit pentru lucrările deja acceptate înainte de revocare.
Impersonarea pentru suport și ștergerea tenantului merită și ele acoperire deliberată. Explicați cum operatorii ies dintr-o sesiune privilegiată și cum sunt gestionate fișierele, sarcinile și referințele reziduale. Politica corectă de ștergere depinde de obligațiile de păstrare ale produsului; evaluarea trebuie să verifice politica aleasă, nu să inventeze una.
Ghidul nostru de preluare a proiectelor software este relevant când echipa actuală nu poate explica aceste trasee. Recuperarea responsabilității implementării, accesului la date și documentației operaționale poate face parte din transformarea limitei într-una care poate fi întreținută.
Specificați un raport util de verificare
Solicitați constatări care arată actorul, tenantul, operațiunea și efectul observat. Includeți cererea relevantă și dovezile din destinație, cu valori sensibile controlate adecvat. O constatare etichetată controlul accesului fără traseu reproductibil este dificil de reparat și retestat.
OWASP ASVS poate susține cerințele mai ample de securitate a aplicației. Păstrați matricea de acceptare specifică tenanturilor alături de această lucrare, astfel încât evaluatorul să vadă ce organizații, roluri și tipuri de resurse au fost testate.
Separați defectele confirmate de traseele netestate. Dacă evaluatorul nu a putut examina un serviciu privat de stocare sau un export administrativ, precizați acest lucru. O limitare onestă a domeniului este mai utilă decât concluzia nesusținută că toate datele tenanturilor sunt izolate.
După remediere, repetați cazul inițial care eșua și cazurile legitime apropiate. O reparație care blochează toate descărcările poate opri scurgerea, dar poate strica produsul. Acceptarea necesită atât refuzul accesului neautorizat, cât și continuarea lucrărilor permise ale clienților.
Bugetați limita reală a produsului
Definiți evaluarea prin tipuri de resurse, roluri și trasee operaționale, nu doar prin numărul paginilor. Includeți fișiere externe, cache-uri, sarcini de fundal și acces de suport dacă pot expune informații ale tenantului. Un portal mic poate avea o limită mai largă decât sugerează interfața.
| Pachet de lucru | Livrabil | Ipoteză de clarificat |
|---|---|---|
| Cartografierea limitei | Modelul tenanturilor și rolurilor | Disponibilitatea cunoștințelor de arhitectură |
| Verificare | Dovezi pozitive și negative de acces | Conturi și medii controlate |
| Remediere | Aplicare corectată și verificări de regresie | Dacă sunt necesare schimbări structurale |
| Predare | Teste repetabile și excluderi cunoscute | Responsabilitatea după onboarding |
Solicitați propuneri în GBP care disting evaluarea de remediere. Evitați acceptarea unei asigurări universale bazate numai pe un test de autentificare sau o scanare automată. Livrabilul valoros este dovada privind limitele de acces de care vor depinde clienții.
Serviciul nostru de securitate a aplicațiilor oferă un punct de pornire pentru acest domeniu. Trimiteți-ne modelul de tenant al produsului și decizia de onboarding pentru a discuta verificarea, reparațiile țintite și dovezile necesare înainte de deschiderea următorului cont de client.
Întrebări frecvente
Ce este izolarea tenanturilor SaaS? Este separarea impusă a datelor organizațiilor client și a operațiunilor permise. Limita trebuie să reziste între cererile aplicației, stocare, cache-uri, fișiere și lucrări de fundal, inclusiv excepțiile administrative definite de produs.
Bazele de date separate garantează izolarea? Nu. Acreditările, rutarea, instrumentele de suport, exporturile și backupurile pot traversa în continuare limitele. Bazele separate pot face parte din proiectare, dar traseele reale de acces necesită testare.
Sunt suficienți identificatorii aleatorii ai înregistrărilor? Nu. Pot reduce enumerarea ușoară, dar nu sunt verificări de permisiune. Testați accesul folosind un identificator real de la alt tenant controlat și confirmați că serverul îl refuză.
Trebuie să testăm accesul permis și refuzurile? Da. O remediere care respinge fiecare cerere poate ascunde un produs defect. Verificați dacă utilizatorii obișnuiți își păstrează operațiunile urmărite, în timp ce încercările între tenanturi sunt respinse.
De ce cache-urile necesită teste separate? Pot returna date fără repetarea traseului inițial de acces la date. Populați un cache sub un tenant și examinați rezultatul sub altul. Confirmați că domeniul cache-ului păstrează autoritatea urmărită, nu doar o cheie comodă comună.
Cum trebuie să funcționeze accesul de suport? Definiți cine îl poate obține, ce domeniu acordă, cât durează și cum se înregistrează acțiunile. Testați intrarea, utilizarea și ieșirea din contextul privilegiat. Proiectarea trebuie să facă excepția explicită și verificabilă.
Ce se întâmplă dacă folosim securitate la nivel de rând? Testați-o cu rolul real al cererilor aplicației și includeți operațiuni care ocolesc controllerii obișnuiți. Rolurile privilegiate ale bazei de date și alte trasee pot avea comportamente diferite. Politicile de rând sunt un control de verificat, nu un motiv de a omite evaluarea.
Ce trebuie să primească furnizorul înainte de ofertare? O descriere a tenanturilor și rolurilor, tipurilor de resurse, stocării externe și operațiunilor de fundal. Identificați mediile și conturile controlate disponibile pentru testare, împreună cu decizia pe care evaluarea trebuie să o susțină.