Rolurile dintr-o aplicație: administrator, angajat, client

Cele mai multe aplicații de firmă au trei feluri de oameni: administratorul, care setează totul, angajații, care lucrează zilnic în ea, și clienții, care își văd doar comenzile sau programările lor. Fiecare primește strict ce îi trebuie, iar regula se verifică pe server, nu în meniu. Dacă stabilești rolurile înainte de primul ecran, aplicația iese mai simplă și mai sigură.

Trei roluri, trei întrebări

Pentru fiecare rol răspunzi la trei întrebări: ce vede, ce poate schimba și ce poate șterge. Un exemplu pentru o firmă cu programări:

Tabelul pare banal, dar pe el se construiește tot: ecranele, meniurile, testele. Când lipsește, drepturile se adaugă din mers, „că a cerut cineva”, iar după un an nimeni nu mai știe sigur cine ce vede.

Administratorul: puțini și bine păziți

Nu-i face pe toți colegii administratori ca să fie mai simplu. OWASP, organizația de referință pentru securitatea aplicațiilor, recomandă privilegiul minim: fiecare utilizator primește doar drepturile de care are nevoie ca să-și facă treaba. De obicei ajung două conturi de administrator, al patronului și al omului care se ocupă de aplicație.

Despre panoul în care lucrează ei, cu autentificarea în doi pași și jurnalul de activitate, am scris în articolul despre panoul de administrare.

Angajatul: drepturi după ce face, nu după cine e

Aici apar cele mai multe nuanțe. Recepția vede programările tuturor, un tehnician doar pe ale lui. O firmă cu două locații vrea ca fiecare echipă să-și vadă doar locația. Contabilul vede facturile, dar nu le modifică.

Câteva reguli care scutesc multe discuții:

• Drepturile se definesc pe sarcini („confirmă programări”, „exportă facturi”), apoi se grupează în roluri. Când apare un post nou, combini sarcini existente în loc să inventezi un rol de la zero.
• Un cont nou nu vede nimic până nu primește un rol. OWASP numește asta refuz din oficiu.
• Plecarea unui angajat se rezolvă dintr-un clic. Contul se dezactivează, istoricul rămâne. Dacă ștergi omul din aplicație, pierzi și urma a ce a făcut.
• Drepturile se revizuiesc din când în când. OWASP avertizează că, în timp, drepturile cresc peste ce s-a stabilit la început.

Clientul: vede doar ce e al lui

Clientul pare rolul cel mai simplu. Tot aici se greșește cel mai des.

Să zicem că un client își deschide programarea, iar adresa paginii se termină în „programare/1043”. Ce se întâmplă dacă scrie 1044? Dacă serverul verifică doar că omul e logat, nu și că programarea 1044 e a lui, vede datele altcuiva: nume, telefon, poate și motivul vizitei.

Problema are un nume, autorizare defectuoasă la nivel de obiect, și e pe primul loc în lista OWASP a riscurilor pentru API-uri din 2023. Remediul recomandat: la fiecare cerere care primește un identificator, serverul verifică dacă utilizatorul logat are voie să facă acțiunea cerută pe acea înregistrare anume. Identificatorii greu de ghicit ajută, dar nu înlocuiesc verificarea.

GDPR spune același lucru din partea datelor. Articolul 5 cere ca datele să fie „limitate la ceea ce este necesar” pentru scopul lor, iar articolul 25 cere ca, din setările implicite, să fie prelucrate doar datele necesare fiecărui scop. Un client care vede numai ce e al lui e exact asta.

Cum verifici înainte de lansare

Testul de mai jos îl poți cere oricui îți face aplicația. Îl faci în jumătate de oră:

1. Creezi câte un cont de test pentru fiecare rol.
2. Cu contul de angajat, scrii direct în browser adresele paginilor de administrator.
3. Cu contul clientului A, încerci să deschizi o comandă sau o programare a clientului B, schimbând numărul din adresă.
4. Dezactivezi un cont și verifici că nu mai poate face nimic, nici din aplicația de pe telefon, unde era poate deja logat.

Toate patru trebuie să eșueze. OWASP recomandă ca astfel de teste să existe și automat, ca o modificare care strică verificările să nu ajungă la clienți.

Ce influențează costul: câte roluri ai, cât de fine sunt drepturile (pe locație, pe client, pe tip de document) și dacă vrei să schimbi singur rolurile din panou. Cum lucrăm găsești pe pagina de servicii App Dev.