Invitații și roluri într-un SaaS B2B: cine poate vedea datele clientului

Invitația într-un produs SaaS B2B trebuie legată de o organizație, un rol și o persoană care o acceptă. O adresă de e-mail introdusă în formular nu este dovada că destinatarul poate vedea toate proiectele clientului. Pentru un fondator, problema practică este să poată arăta cine a acordat accesul, la ce date, când și cum poate fi retras.

Imagine editorială generată cu OpenAI; scenă ilustrativă.

Începe cu operațiunile, nu cu numele rolurilor

Scrie mai întâi lista acțiunilor din produs: citirea proiectelor, modificarea lor, exportul datelor, invitarea colegilor, schimbarea facturării și ștergerea spațiului de lucru. Pentru fiecare acțiune, stabilește ce obiect atinge și cine are motiv să o execute. Un rol numit „administrator” este prea vag dacă poate schimba cardul de plată, dar nu poate aproba exportul unor documente confidențiale. Un client poate avea nevoie de un administrator pentru facturare și de altul pentru date.

Ghidul OWASP pentru autorizare recomandă drepturi minime, refuzarea accesului atunci când nu există o regulă explicită și verificarea permisiunilor la fiecare cerere. Folosește aceste principii ca punct de plecare pentru matricea de roluri. În loc să bifezi automat toate drepturile pentru fiecare rol nou, notează de ce i se acordă fiecare operațiune. Revizuiește matricea când introduci o funcție nouă; o acțiune adăugată după lansare nu ar trebui să moștenească implicit accesul tuturor administratorilor.

Separă drepturile asupra organizației de cele asupra unui proiect. De exemplu, un consultant extern poate primi acces la proiectul de implementare fără să poată vedea contractele și facturile din celelalte proiecte. Această diferență trebuie să existe în modelul de date și în verificările de pe server. Ascunderea unor secțiuni din meniu nu protejează un API apelat direct.

Invitația are o stare, nu doar un e-mail trimis

La trimitere, salvează identitatea persoanei care invită, organizația, rolul propus și momentul expirării. Afișează invitația ca „în așteptare” până când destinatarul se autentifică și o acceptă. Documentația Microsoft Entra despre acceptarea invitațiilor B2B distinge explicit starea inițială PendingAcceptance de starea Accepted; acesta este un model util, deși produsul tău poate avea altă implementare. Nu prezenta o invitație trimisă drept utilizator activ în rapoartele de acces.

Verifică la acceptare că adresa sau identitatea autentificată corespunde politicii tale de invitație. Dacă persoana folosește un alias, definește o cale de recuperare care cere confirmare, fără a atașa automat contul greșit. Nu pune rolul și identificatorul organizației într-un link care poate fi modificat fără verificare. Un link expirat sau revocat trebuie să dea un răspuns clar și să nu activeze un acces rămas dintr-o încercare anterioară.

Un caz de test revelator este invitația trimisă din greșeală către un nume aproape identic, cu o singură literă diferită în domeniu. Administratorul trebuie să poată anula invitația înainte de acceptare, iar produsul să arate că vechiul link nu mai funcționează. Dacă trimiți apoi invitația corectă, cele două înregistrări trebuie să rămână distincte în jurnal, fără ca noul destinatar să preia vechiul identificator.

Verifică organizația și resursa la fiecare cerere

Un utilizator care aparține a două companii poate schimba spațiul de lucru în interfață. Serverul trebuie totuși să verifice că același utilizator are dreptul asupra fiecărui proiect cerut. Ghidul OWASP despre tiparele de autorizare arată că punctul de aplicare a politicii trebuie să protejeze operațiunea aproape de resursă și să țină cont de acțiune, obiect și organizație. Nu te baza doar pe faptul că utilizatorul s-a autentificat sau că un identificator de proiect pare valid.

Testează în mod deliberat traversarea dintre două organizații de probă. Conectează un utilizator la prima, copiază identificatorul unui proiect din a doua și încearcă să-l citești prin API. Repetă pentru export, modificare și ștergere. Verifică și conturile de serviciu: un token folosit de o integrare trebuie să aibă o organizație și drepturi definite, nu acces global doar pentru că nu aparține unui utilizator obișnuit.

Notează separat rezultatul testelor pentru interfață și pentru API. O pagină care afișează „acces interzis” poate coexista cu un endpoint care încă returnează datele. Dacă produsul oferă un jurnal de audit al acțiunilor, înregistrează schimbarea rolului și revocarea accesului fără a salva secrete sau conținutul documentelor.

Revocarea trebuie să închidă și căile rămase deschise

Administratorul clientului trebuie să poată vedea utilizatorii activi, invitațiile neacceptate și rolurile fiecăruia. Microsoft Entra descrie revizuiri periodice ale accesului invitaților, inclusiv eliminarea persoanelor care nu mai au nevoie de acces. Pentru un SaaS mic, poți începe cu o listă exportabilă și o verificare periodică făcută de administratorul organizației. Frecvența potrivită depinde de sensibilitatea datelor și de contract, nu de o regulă universală.

Când un angajat pleacă de la client, elimină-i apartenența la organizație, invalidează sesiunile și verifică tokenurile ori integrările emise în numele lui. Testează cu un apel real după revocare. Dacă persoana aparține și unei alte organizații, revocarea din prima nu trebuie să îi închidă accesul legitim din a doua. Ghidul despre plecarea unui client SaaS B2B tratează cazul mai amplu în care se închide întregul contract.

Înainte de lansare, pune în aceeași verificare matricea de drepturi, acceptarea invitației, anularea ei și încercările de acces între organizații. Rezultatul minim pe care trebuie să-l poți demonstra clientului este simplu: o persoană vede numai datele și acțiunile aprobate pentru organizația ei, iar drepturile retrase nu mai funcționează nici prin API.