Uloge i dozvole u CMS-u treba organizovati prema odgovornostima, a ne prema pojedinačnim ljudima. Editor može da priprema i menja sadržaj, reviewer proverava kvalitet i odobrava objavu, dok administrator upravlja sistemom, korisnicima i konfiguracijom. Te uloge ne moraju uvek biti dodeljene različitim osobama, ali njihove dozvole treba da ostanu logički odvojene.
Najpraktičniji pristup je da se najpre definišu sadržajni objekti i faze rada, a tek onda korisnici i grupe. Tako se izbegava česta greška u kojoj svaki novi član tima dobija širok administratorski pristup samo zato što CMS nema jasno razrađen model autorizacije. Kod custom CMS rešenja ovaj model može da se prilagodi stvarnom procesu rada, bez gomilanja nejasnih izuzetaka.
Razlika između autentikacije, autorizacije, uloga i dozvola
Ova četiri pojma se često koriste kao sinonimi, iako rešavaju različite probleme:
- Autentikacija proverava ko je korisnik, na primer lozinkom, jednokratnim kodom ili prijavom preko identity provajdera.
- Autorizacija odlučuje šta autentifikovani korisnik sme da uradi.
- Dozvola je konkretna radnja ili pravo, kao što su čitanje, kreiranje, izmena, slanje na pregled, odobravanje ili brisanje.
- Uloga je skup povezanih dozvola dodeljen određenoj odgovornosti.
U praksi, korisnik se najčešće ne proverava direktno za svaku pojedinačnu radnju, već se njegove uloge i kontekst koriste za donošenje odluke. To olakšava održavanje sistema, ali samo ako su uloge dovoljno uske i razumljive.
Bezbednosni deo ovog modela ne treba posmatrati izolovano od prijave korisnika i zaštite aplikacije. Za širi pregled odnosa između autentikacije i autorizacije pogledajte vodič Bezbednost custom CMS-a: autentikacija, autorizacija i hardening.
Počnite od odgovornosti, ne od naziva funkcije
Nazivi poput editor, manager ili administrator mogu značiti različite stvari u različitim organizacijama. Pre kreiranja uloga zapišite ko je odgovoran za pojedine odluke:
- Ko priprema tekst, slike i metapodatke?
- Ko proverava pravopis, činjenice, pravne elemente i ton komunikacije?
- Ko sme da objavi sadržaj na produkciji?
- Ko menja strukturu sadržaja i polja?
- Ko dodaje korisnike i podešava njihove pristupe?
- Ko prati audit log i reaguje na incident?
Ovaj spisak otkriva da „upravljanje sadržajem“ nije jedna aktivnost. Uređivanje članka, odobravanje objave i menjanje CMS konfiguracije zahtevaju različit nivo poverenja. Kada ih spojite u jednu ulogu, dobijate jednostavniji početni setup, ali i veći rizik od grešaka, slučajnih izmena i nejasne odgovornosti.
Primer osnovnog modela: editor, reviewer i administrator
Editor: priprema i održavanje sadržaja
Editor bi trebalo da može da radi sa sadržajem koji mu je dodeljen ili za koji je odgovoran. Tipične dozvole uključuju:
- pregled relevantnih sadržajnih tipova;
- kreiranje novog nacrta;
- izmenu sopstvenog ili dodeljenog sadržaja;
- dodavanje medija u dozvoljenim formatima;
- čuvanje nacrta i slanje sadržaja na pregled;
- pregled statusa i komentara vezanih za rad.
Editoru obično nije potreban pristup korisničkim nalozima, sistemskim podešavanjima, produkcionim tajnama ili strukturi baze. Posebno odlučite da li editor može da menja već objavljen sadržaj. U nekim timovima ta izmena odmah ide u novu verziju na pregled; u drugima se dozvoljava samo uz odobrenje. Važan je predvidiv proces, a ne univerzalno pravilo.
Reviewer: kontrola kvaliteta i odluka o objavi
Reviewer proverava da li je sadržaj spreman za objavu. Njegove dozvole mogu da obuhvate čitanje nacrta, ostavljanje komentara, vraćanje na doradu i odobravanje. Ako je moguće, reviewer treba da vidi šta se promenilo između verzija, a ne samo poslednju verziju dokumenta.
Odvojite odobravanje od tehničkog objavljivanja samo ako to odgovara vašem procesu. Na primer, reviewer može da odobri sadržaj, dok publisher ili automatizovani workflow obavlja objavu u zakazano vreme. U manjem timu jedna osoba može imati obe odgovornosti, ali model i dalje treba da ih razlikuje kako bi se kasnije mogao proširiti.
Administrator: sistemska, ne urednička odgovornost
Administrator upravlja okruženjem u kojem CMS radi. To može uključivati korisnike i grupe, konfiguraciju, integracije, sadržajne tipove, dozvole, logove i oporavak sistema. Administrator ne bi automatski trebalo da bude i glavni urednik svakog sadržaja.
U manjim organizacijama ista osoba može biti administrator i reviewer. To je operativni kompromis, ali treba ga svesno dokumentovati. Ako administrator može da menja workflow, briše logove ili dodaje sebi dozvole, audit i periodična provera pristupa postaju još važniji.
RBAC kao osnova, atributi kao dopuna
Za većinu CMS implementacija dobar početak je role-based access control (RBAC): korisnik dobija ulogu, a uloga skup dozvola. Na primer, uloga „editor za blog“ može da dozvoli kreiranje i izmenu članaka, ali ne i upravljanje korisnicima.
Čist RBAC ponekad nije dovoljan. Ista uloga može da zahteva različit pristup u zavisnosti od:
- odeljenja ili brenda kojem sadržaj pripada;
- jezika i tržišta;
- statusa sadržaja;
- vlasnika ili autora zapisa;
- okruženja, na primer staging naspram produkcije;
- tipa sadržaja ili osetljivosti podataka.
Tada se uloga kombinuje sa atributima i pravilima. Editor može da menja samo sadržaj svog brenda, reviewer samo sadržaj određenog tržišta, a administrator da vidi sve, ali bez automatskog prava na objavu. Ovakav model je fleksibilniji, ali zahteva jasnu dokumentaciju i testove, jer pravila postaju teža za razumevanje.
Dozvole treba vezati za radnje i objekte
Ne definišite dozvolu samo kao „pristup člancima“. Preciznije je razdvojiti objekat i radnju:
| Objekat | Primer dozvole | Moguća uloga |
|---|---|---|
| Članak | kreiranje, izmena, pregled, odobravanje, objava | editor, reviewer |
| Medija | otpremanje, zamena, brisanje | editor, media manager |
| Korisnik | pozivanje, deaktivacija, promena uloge | administrator |
| Konfiguracija | izmena polja, workflow-a i integracija | administrator |
| Audit log | pregled i izvoz zapisa | administrator, compliance reviewer |
Odobrite samo ono što je potrebno za konkretan posao. Princip najmanjih privilegija ne znači da korisnik mora imati što manje mogućnosti po svaku cenu, već da dobije dovoljno pristupa da izvrši odgovornost bez nepotrebnih sistemskih ovlašćenja.
Workflow i dozvole moraju da rade zajedno
Uloga nema smisla ako statusi sadržaja omogućavaju zaobilaženje kontrole. Minimalni workflow može imati statuse draft, in review, changes requested, approved i published. Za svaki prelaz definišite ko ga pokreće i šta se beleži.
Na primer, editor može da pošalje nacrt na pregled, reviewer da ga vrati na doradu ili odobri, a publisher da ga objavi. Ako editor može da pređe direktno iz drafta u published, reviewer je samo neobavezni korak. Ako reviewer nema mogućnost da vrati sadržaj na doradu, komentari će se verovatno pretvoriti u neformalnu komunikaciju van CMS-a.
Detaljniji prikaz statusa, approval koraka i odgovornosti nalazi se u tekstu Editorial workflow: draft, review i approval u custom CMS-u. Workflow takođe treba uskladiti sa strukturom sadržaja: ako nisu jasno definisani tipovi, obavezna polja i odnosi, reviewer proverava neujednačene zapise. To je razlog da se pre implementacije razradi i content model u custom CMS-u.
Kako sprečiti preširoke i nasleđene privilegije
Najčešći problemi nastaju kada se pristup širi neprimetno. Korisnik dobije novu ulogu za privremeni zadatak, promeni se tim, a stari pristup ostane aktivan. Drugi problem je kombinovanje više širokih uloga bez prikaza ukupnih efektivnih dozvola.
Uvedite nekoliko praktičnih kontrola:
- vodite registar uloga, dozvola i vlasnika procesa;
- prikažite efektivne dozvole kada se uloge kombinuju;
- ograničite ko sme da dodeljuje privilegovane uloge;
- uvedite datum isteka za privremeni pristup;
- deaktivirajte naloge koji više nisu potrebni;
- periodično proveravajte članstvo u grupama;
- beležite promene dozvola, sadržaja i statusa.
Ne treba svaku izmenu rešavati ručnim odobravanjem ako bi to usporilo rad bez jasne koristi. Za osetljive radnje, kao što su promena administratorskog pristupa, brisanje većeg broja zapisa ili promena produkcione konfiguracije, dodatna potvrda i audit trag imaju više smisla.
Testiranje: proverite šta korisnik ne sme da uradi
Testiranje dozvola nije samo provera da li editor može da sačuva članak. Jednako su važne negativne provere: da li editor može da objavi sadržaj, vidi tuđe tržište, promeni workflow, preuzme administratorsku ulogu ili pristupi zapisu direktnim URL-om?
Napravite matricu uloga i očekivanih ishoda. Za svaku kombinaciju navedite da li je radnja dozvoljena, odbijena ili dozvoljena samo u određenom kontekstu. Testirajte i prelaze između statusa, pristup kroz API ako postoji, masovne akcije, izvoz podataka i rad sa obrisanim ili arhiviranim sadržajem.
Posebno proverite scenarije sa više uloga. Korisnik koji je istovremeno editor i reviewer može nenamerno dobiti mogućnost samostalnog odobravanja sopstvenog sadržaja. To možda jeste prihvatljivo za mali tim, ali mora biti svesna poslovna odluka, a ne posledica slučajnog sabiranja dozvola.
Šta se menja kada CMS podržava više jezika, brendova ili lokacija
Višejezični i multi-brand sistemi zahtevaju dodatni sloj konteksta. Uloga „editor“ nije dovoljna ako jedna osoba sme da uređuje srpsku verziju, ali ne i nemačku, ili jedan brend, ali ne i drugi. Pravila mogu da se zasnivaju na lokalizaciji, organizacionoj jedinici, brendu ili vlasniku sadržaja.
Pri tome pazite na nasleđivanje. Ako se globalna promena automatski prenosi na lokalne verzije, treba jasno odrediti ko sme da menja izvorni sadržaj i ko potvrđuje lokalizaciju. Isto važi za medije, SEO polja, navigaciju i reusable komponente. Sadržajni model i dozvole treba projektovati zajedno, jer previše generički objekti otežavaju precizno ograničavanje pristupa.
Praktičan redosled za uvođenje modela dozvola
- Popišite objekte i radnje. Uključite sadržaj, medije, korisnike, konfiguraciju, logove i integracije.
- Opišite workflow. Zabeležite statuse, prelaze i odgovorne osobe.
- Definišite osnovne uloge. Krenite sa najmanjim brojem uloga koji realno pokriva proces.
- Dodajte kontekst tek kada je potreban. Brend, jezik, odeljenje ili vlasništvo uvodite zbog konkretne potrebe, ne kao apstraktnu kompleksnost.
- Testirajte dozvoljene i zabranjene radnje. Uključite direktne URL-ove, API i kombinovanje uloga.
- Dokumentujte i revidirajte. Model treba proveriti pri promeni tima, sadržaja ili integracija.
Ako organizacija tek planira CMS, dozvole ne treba dodavati na kraju razvoja. One utiču na strukturu sadržaja, workflow, korisnički interfejs, API i audit log. Zato je korisno da budu deo šireg projektovanja i izrade sajta, umesto naknadnog zakrpljivanja administratorskog panela.
Zaključak: jednostavan model je bolji od nejasnog modela
Dobar model uloga u CMS-u ne pokušava da predvidi svaku moguću kombinaciju korisnika. On jasno razdvaja urednički rad, kontrolu kvaliteta i sistemsku administraciju, a zatim dodaje ograničenja po sadržaju, tržištu ili statusu samo tamo gde su potrebna.
Sledeći korak je da napravite jednu tabelu sa kolonama: objekat, radnja, uloga, kontekst i dozvoljeni workflow prelaz. Ako ta tabela nije razumljiva uredniku, administratoru i vlasniku procesa, implementacija će verovatno biti teška za održavanje. Kada je model jasan, lakše je proceniti da li je potreban gotov sistem sa prilagođavanjem ili custom CMS sa precizno projektovanim ulogama i dozvolama.
