Un cont valid nu trebuie să poată citi orice rezervare sau modifica orice factură. Pentru securitatea unei aplicații B2B, autentificarea și rolurile trebuie evaluate împreună cu limitele asupra datelor și cu modul în care accesul este retras. Un ecran de login funcțional nu dovedește că aceste controale sunt corecte.
Autentificare și autorizare: două verificări diferite
Autentificarea verifică identitatea contului. Autorizarea decide dacă acel cont poate efectua o anumită operațiune asupra unei anumite resurse. Într-o aplicație cu mai multe companii, rolul utilizatorului trebuie evaluat și în contextul organizației căreia îi aparține resursa.
Ca exemplu ipotetic, un recepționer poate înregistra sosiri la hotelul său, fără dreptul de a exporta datele altei proprietăți. Permisiunile exacte se stabilesc cu operatorul; denumirea postului nu reprezintă o regulă universală de acces.
Cum alegi parolele, MFA și SSO
Pentru parole, urmărește lungimea adecvată, blocarea valorilor cunoscute ca fiind compromise și recuperarea sigură a contului. Expirarea arbitrară și regulile de tip „o majusculă și un simbol” nu înlocuiesc aceste măsuri. Ghidul OWASP pentru autentificare recomandă evitarea schimbării periodice obligatorii a parolelor și schimbarea lor când există indicii de compromitere.
Autentificarea multifactor, MFA, combină factori diferiți. Verifică metoda oferită efectiv, înrolarea unui dispozitiv nou și recuperarea accesului. Un cod prin SMS și o cheie de securitate nu oferă aceeași protecție. Un cod primit prin e-mail nu trebuie prezentat automat ca factor independent, deoarece depinde de securitatea contului de e-mail. NIST SP 800-63B tratează explicit aceste diferențe; documentul este un reper tehnic, nu o obligație legală universală pentru orice companie.
SSO centralizează autentificarea între aplicații. Cere demonstrarea dezactivării accesului și a gestionării sesiunilor din aplicațiile conectate; simpla existență a butonului SSO nu dovedește că toate sesiunile sunt revocate.
Rolurile trebuie legate de operațiuni și date
RBAC grupează permisiunile pe roluri. Pentru un proiect concret, pregătește o matrice cu operațiuni precum citire, modificare, aprobare și export, apoi stabilește cine le poate efectua și asupra căror date. Rolul poate necesita restricții suplimentare după companie, locație sau responsabilitatea asupra unui document.
Ghidul OWASP pentru autorizare recomandă accesul minim necesar, refuzul implicit și verificarea permisiunilor la fiecare cerere. Ascunderea unui buton în interfață nu este suficientă: controlul trebuie aplicat și pe server, inclusiv pentru fișiere și exporturi.
Teste de acceptanță pentru un scenariu concret
Într-un scenariu ipotetic cu două companii și un consultant extern, cere demonstrarea următoarelor situații:
Consultantul vede numai documentele companiei care i-a acordat acces.
Modificarea identificatorului unui document din cerere nu deschide datele celeilalte companii.
O operațiune interzisă rămâne interzisă când este solicitată direct prin API.
Retragerea dreptului de export este verificată și pentru fișierele deja pregătite pentru descărcare.
Dezactivarea contului este testată atât la o autentificare nouă, cât și cu o sesiune deja deschisă.
Pentru fiecare test, notează contul, resursa, acțiunea, rezultatul așteptat și dovada obținută. Acest set devine o parte verificabilă a acceptanței, fără a pretinde că reprezintă un audit complet de securitate.
Ce stabilești pentru administrarea accesului
Desemnează cine aprobă accesul inițial, cine validează schimbarea rolului și cine îl retrage la încetarea colaborării. Alege frecvența revizuirilor după riscurile și schimbările organizației, fără a transforma un interval arbitrar într-o regulă universală.
Documentează și conturile tehnice folosite de integrări. Jurnalul de audit trebuie proiectat astfel încât să poți investiga schimbările importante fără a înregistra parole sau secrete de autentificare. Jurnalul ajută investigarea incidentelor, dar nu înlocuiește testarea tehnică a controalelor de acces.
Ce discuți cu AB Solutions
Pentru un proiect de software la comandă sau de integrare API, pregătește lista rolurilor, aplicațiile conectate și exemplele de acces permis și interzis. Alex Bedeleu este contactul tehnic direct pentru AB Solutions; partenerii specializați pot participa în funcție de proiect.
Discuția utilă pornește de la un flux real și de la dovezile necesare pentru acceptanță, nu de la promisiunea unei aplicații „complet sigure”.
Infographic
