Izolarea tenanților pentru MSP: un tenant ID sau o autentificare nu înseamnă autorizare

Un tenant ID furnizat de client, un antet X-Tenant-ID, o autentificare care funcționează, o politică de Acces Condiționat sau o conexiune SSO transmit fiecare o informație utilă — dar niciuna, luată separat, nu dovedește că apelantul are voie să vadă datele unui anumit client. Acest ghid este pentru MSP și echipele IT care operează sau cumpără platforme multi-tenant: arată, mecanism cu mecanism, unde trebuie să se afle de fapt o verificare de autorizare pe server, de la prima cerere până în ziua în care un cont este dezactivat.

Un tenant ID doar selectează un client, nu îl autorizează

Un tenant ID furnizat de client — în corpul cererii, într-un parametru de query, sau dedus dintr-un subdomeniu — este un selector. Îi spune aplicației ce context de client să deschidă. OWASP Multi-Tenant Security Cheat Sheet stabilește regula de bază: leagă fiecare cerere de un principal autentificat, dedu apartenența la tenant a acelui principal din starea de pe server, aplică verificări la nivel de obiect în interiorul tenantului și păstrează căile de administrare sau de urgență separate de accesul obișnuit la tenant. Această verificare trebuie să funcționeze oriunde contează o graniță de tenant, nu doar la intrarea în API: la citiri și scrieri, la acțiuni administrative și la sarcinile de fundal care preiau lucrul după ce cererea inițială s-a încheiat. O sarcină declanșată dintr-o coadă, care moștenește un tenant ID dintr-un mesaj fără a-l reverifica, redeschide exact breșa pe care verificarea inițială trebuia s-o închidă.

Un antet X-Tenant-ID sau un câmp din corpul cererii ascund aceeași capcană

Aceeași greșeală reapare sub numele unui antet. API-urile multi-tenant acceptă frecvent un antet X-Tenant-ID sau un câmp tenant în corpul cererii pentru a alege datele cărui client trebuie să le atingă un apel, și e tentant să tratezi acea valoare ca suficientă imediat ce este interpretată corect. Ghidul OWASP semnalează două capcane înrudite: a presupune că un identificator de tenant este sigur pentru că este lung sau greu de ghicit, în loc să execuți o verificare de autorizare reală; și a permite ca o cale de cod limitată de obicei la tenant să revină în tăcere la o interogare nelimitată atunci când valoarea așteptată lipsește sau este malformată. Oricare dintre aceste greșeli permite unui apelant autentificat, dar care nu aparține tenantului cerut, să ajungă la date care aparțin altcuiva.

Autentificarea dovedește cine ești, nu ce tenant poți atinge

Autentificarea răspunde la o întrebare diferită de izolare. NIST Special Publication 800-210, privind controlul accesului pentru sistemele cloud, tratează izolarea tenanților ca pe o proprietate pe care platforma însăși trebuie să o aplice pe fiecare cale de API și de date atunci când o singură instanță de software deservește mulți tenanți, pentru că respectivul client nu controlează infrastructura de bază. Well-Architected SaaS Lens al AWS descrie două moduri în care furnizorii construiesc acest lucru: într-un model „silo”, fiecare tenant primește resurse dedicate și un rol de execuție limitat, mai simplu de înțeles dar mai greu de operat la scară largă; într-un model „pool”, tenanții partajează infrastructura, iar izolarea trebuie aplicată în interiorul logicii aplicației la fiecare cerere. Niciunul dintre modele nu este în mod inerent mai sigur. Ceea ce contează este dacă un furnizor poate arăta concret cum este legată o cerere de tenantul apelantului înainte ca vreo dată să fie atinsă — nu faptul că apelantul are o autentificare funcțională.

Accesul Condiționat securizează autentificarea, nu calea datelor

Microsoft descrie Accesul Condiționat ca un motor de politici Zero Trust bazat pe logică de tipul dacă-atunci: dacă un utilizator, sau tot mai des un agent AI, încearcă să ajungă la o resursă, atunci o condiție precum conformitatea dispozitivului, riscul de autentificare sau locația trebuie îndeplinită mai întâi. Este o poartă cu adevărat utilă — poate opri o credențială compromisă să pornească o sesiune sau poate întrerupe o sesiune care începe să se comporte suspect. Dar nu are nicio vizibilitate asupra modului în care backend-ul unei aplicații decide, odată ce există o sesiune, ce înregistrări ale cărui client are voie să le citească sau să le scrie un anumit apel API. Dacă o platformă se bazează pe o valoare a tenantului furnizată de client pentru a lua această decizie, Accesul Condiționat și-a terminat deja treaba, cu succes și în mod irelevant pentru eroare, până în momentul în care decizia este luată. O poartă de autentificare bine configurată în fața unui API prost izolat produce aceeași scurgere pe care ar produce-o și fără acea poartă. Licența Agent 365 a Microsoft extinde Accesul Condiționat la agenții AI, dar aceeași distincție dintre autentificare și accesul la date se va aplica și acolo.

SSO lasă oamenii să intre; doar SCIM îi scoate pe cei care pleacă

Federația răspunde la întrebarea „cine se poate autentifica acum?”. System for Cross-domain Identity Management, standardizat ca RFC 7644, răspunde la o întrebare diferită: ce conturi ar trebui să mai existe. Documentația de provisioning SCIM a Microsoft descrie fluxul obișnuit: o ștergere logică la furnizorul de identitate setează atributul active al unei resurse de utilizator pe false, iar aplicația care primește acest semnal ar trebui să dezactiveze sau să arhiveze locul respectiv. Fără o integrare SCIM, autentificarea unică a unei persoane care pleacă încetează să funcționeze, dar locul său — și orice acces API rezidual legat de el — poate rămâne neatins. Partea de provisioning are nevoie și ea de propriul domeniu: un token bearer SCIM ar trebui emis pentru fiecare tenant client și acceptat doar la punctul terminal SCIM propriu al acelui tenant. Partajarea unui singur secret SCIM multi-tenant între mai mulți clienți transformă un singur token scurs într-un risc de deprovisionare și de preluare a contului între clienți diferiți.

Dezactivarea contului nu încheie sesiunea sau tokenul

Când cineva pleacă, iar un administrator dezactivează contul respectivei persoane la furnizorul de identitate, e ușor să presupui că treaba e gata. Chiar ghidul Microsoft privind revocarea accesului spune altceva: dezactivarea unui cont blochează autentificările noi, dar nu invalidează automat token-urile de reîmprospătare, sesiunile active sau cookie-urile de browser deja emise. A tăia efectiv accesul înseamnă a revoca separat sesiunile și token-urile și a șterge acreditările din cache — iar acolo unde este disponibilă, Continuous Access Evaluation aplică tăierea mai repede decât așteptarea expirării naturale a unui token. Ghidul de proiect NIST privind gestionarea sesiunilor face o observație înrudită: deținerea unui token de acces valid nu este o dovadă că o sesiune este încă deschisă în mod legitim, iar sesiunile furnizorului de identitate și cele ale aplicației sunt independente una de alta, astfel încât încheierea uneia nu o încheie automat pe cealaltă. De aceea OWASP Session Management Cheat Sheet cere invalidarea sesiunii pe server, cu timpi limită atât de inactivitate, cât și absoluți, în loc să se bazeze pe faptul că aplicația client renunță la acreditări.

Unii MSP preferă să încredințeze această muncă de plan de control unui furnizor dedicat, în loc să o construiască și să o auditeze singuri; Auris este o platformă europeană de IAM-as-a-Service pentru MFA adaptiv, SSO federat și jurnale de audit imuabile.

Ce e de făcut

• Dedu apartenența la tenant din date de identitate de pe server la fiecare cerere; nu te baza niciodată doar pe un ID, antet sau câmp din corpul cererii furnizat de client.
• Aplică această verificare pe fiecare cale în care contează o graniță de tenant: citiri, scrieri, acțiuni administrative și sarcini de fundal sau declanșate din coadă.
• Respinge orice selector de tenant care nu a fost confirmat în raport cu apartenențele reale ale apelantului autentificat, în loc să presupui că un identificator lung este sigur.
• Tratează Accesul Condiționat, SSO și legarea de tenant ca pe controale separate, cu moduri de eșec separate, și testează-le pe fiecare în parte.
• Configurează SCIM alături de SSO, limitează fiecare token SCIM la un singur tenant și confirmă că este dezactivat contul unei persoane care pleacă și în sistemul sursă, nu doar la furnizorul de identitate.
• La offboarding, revocă explicit sesiunile și token-urile de reîmprospătare din fiecare aplicație folosită de persoana respectivă, în loc să te oprești la „cont dezactivat”.

Surse: OWASP Multi Tenant Security Cheat Sheet, NIST SP 800-210, AWS Well-Architected SaaS Lens, Microsoft Learn — prezentare generală Acces Condiționat, Microsoft Learn — Use SCIM to provision users and groups, OWASP Session Management Cheat Sheet.