Django korisničke uloge i prava pristupa

Poslovne web aplikacije rijetko imaju samo jednu vrstu korisnika. Administrator, zaposlenik, voditelj i vanjski klijent trebaju različite mogućnosti. Django nudi korisničke račune, grupe i dozvole, ali sigurnu kontrolu pristupa treba projektirati prema stvarnim poslovnim pravilima, ne samo prema izgledu izbornika.

Autentifikacija nije autorizacija

Prijava odgovara na pitanje tko je korisnik. Autorizacija odgovara na pitanje smije li otvoriti, vidjeti ili promijeniti određeni podatak. Korisnik može biti uspješno prijavljen i svejedno ne smjeti pristupiti tuđoj rezervaciji ili financijskom izvještaju. Provjera mora biti na poslužitelju pri svakom zahtjevu.

Django omogućuje rad s grupama i modelskim dozvolama poput dodavanja, mijenjanja, brisanja i pregledavanja modela. To je dobar početak, ali u mnogim sustavima nije dovoljno. „Zaposlenik smije mijenjati samo naloge svojeg odjela” pravilo je na razini pojedinog zapisa, a ne samo modela.

Primjer korisničkih uloga

Zamislimo evidenciju radnih naloga. Administrator održava korisnike, voditelj vidi naloge vlastitog tima, zaposlenik vidi samo one koji su mu dodijeljeni, a klijent prati status svojih zahtjeva. U aplikaciji se mora provesti filtriranje querysetova i dodatna provjera prije svake promjene.

Sakrivanje gumba za uređivanje u HTML-u korisno je za korisničko iskustvo, ali nije sigurnosna kontrola. Korisnik može ručno poslati HTTP zahtjev na istu adresu. Zato se pravila moraju provjeravati u viewovima ili servisima, uz dosljednu arhitekturu aplikacije.

Princip najmanjih ovlasti

Početno dodijelite najniži skup prava i proširujte ga samo po potrebi. Izbjegavajte da svaki zaposlenik bude staff ili superuser zato što je tako najbrže riješiti problem s pristupom. Posebno kontrolirajte izvoz podataka, masovne akcije, brisanje i administratorske funkcije.

Postupak dodjeljivanja i ukidanja prava treba biti dokumentiran. Kada zaposlenik promijeni odjel ili napusti organizaciju, njegove ovlasti treba promijeniti ili ukinuti bez odgode. Za osjetljivije sustave razmotrite i višefaktorsku autentifikaciju.

Audit log nije isto što i običan log

Za važne promjene korisno je voditi evidenciju tko je, kada i što promijenio. Ta evidencija treba biti dovoljno pouzdana za objašnjenje poslovne promjene, ali istodobno ne smije nepotrebno izlagati osjetljive podatke. Za kritične radnje može se koristiti zapis prethodne i nove vrijednosti ili povijest izmjena.

Samo bilježenje nije dovoljno: definirajte tko može pregledati zapise, koliko dugo se čuvaju i kako se postupak incidenta istražuje.

Testirajte prava negativnim scenarijima

Nije dovoljno provjeriti da voditelj može otvoriti nalog. Treba provjeriti da zaposlenik ne može otvoriti nalog drugog odjela, izmijeniti zabranjeni status ili dohvatiti podatke preko API-ja. Automatizirani testovi takvih zabrana često spriječe najskuplje regresije pri nadogradnji.

Dobra autorizacija ne vidi se nužno na naslovnici aplikacije, ali određuje koliko joj organizacija može vjerovati.

Negativni test koji otkriva ozbiljan propust

Pretpostavimo da zaposlenik iz odjela A pokušava otvoriti detalje naloga odjela B ručnom promjenom identifikatora u adresi preglednika. Ako aplikacija provjerava samo da je korisnik prijavljen, može nehotice vratiti tuđe podatke. Ispravno rješenje provjerava pripadnost naloga i prava korisnika pri dohvaćanju objekta. Isti test treba ponoviti za uređivanje, brisanje i API.

Takvi scenariji trebaju ući u automatizirane testove, ne ostati samo u ručnom testiranju. Nakon dodavanja nove funkcionalnosti moguće je slučajno zaobići postojeću provjeru, pa testovi zabrane pristupa imaju trajnu vrijednost.

Česta pitanja

Jesu li Django grupe dovoljne? Za jednostavne sustave mogu biti. Za prava na pojedinim zapisima treba dodatna logika.

Može li se pravo sakriti u sučelju? Gumb se može sakriti, ali to nije sigurnost; server mora odbiti nedopušten zahtjev.

Treba li bilježiti svaku promjenu? Ovisi o važnosti podataka i pravilima zadržavanja. Za osjetljive poslovne radnje audit log je često vrlo koristan.

Kontrolna lista za Django prava pristupa

Prava pristupa treba definirati u poslovnom jeziku prije tehničke implementacije. Ako zaposlenici koriste izraze poput „može vidjeti vlastite naloge” ili „smije odobriti zahtjev do određene vrijednosti”, ta pravila treba prevesti u dosljedne server-side provjere. Tablica uloga i akcija dobar je početak razgovora s klijentom.

• Je li za svaku korisničku ulogu jasno opisano koje zapise smije vidjeti, mijenjati, odobriti i izvesti?
• Jesu li model-level Django dozvole dopunjene provjerama na pojedinim objektima kad poslovna pravila to zahtijevaju?
• Mogu li korisnici pristupiti tuđim podacima ručnom promjenom ID-a u URL-u ili parametrima API zahtjeva?
• Jesu li izvozi, masovne akcije i administracijske naredbe podvrgnuti istim ili strožim pravilima kao obični obrasci?
• Postoji li jednostavan proces dodjeljivanja i ukidanja prava pri dolasku, premještaju i odlasku zaposlenika?
• Bilježe li se osjetljive promjene na način koji omogućuje provjeru bez nepotrebnog čuvanja osobnih podataka?

Pravilno definirana prava štite korisnike i smanjuju broj ručnih intervencija potrebnih za svakodnevni rad.