Maker-checker i SoD: zašto „role i prava” nisu autorizacija

Gotovo svaki ERP koji smo zatekli kod klijenta ima ekran „Korisnici i prava”: matrica uloga i modula, čekboksovi za pregled, unos, izmenu i brisanje. Taj ekran nije pogrešan. On je samo prvi od šest slojeva, a u većini implementacija jedini koji zaista radi na serveru.

Šta uloge ne mogu da odgovore

Uzmite rečenicu iz interne procedure bilo koje distributivne firme: „Komercijalista odobrava rabat do 8%, iznad toga direktor prodaje, a ko je pripremio nalog za plaćanje ne sme i da ga pusti u banku.” U toj rečenici su četiri pitanja. RBAC odgovara na jedno.

• Sme li korisnik uopšte da odobrava rabat? Pitanje uloge — jedino koje matrica čekboksova rešava.
• Do kog iznosa? Pitanje limita, koje ne zavisi od korisnika nego od podatka na dokumentu.
• Nad kojim dokumentima? Pitanje opsega podataka — komercijalista Zapada nema posla sa nalozima Istoka, a uloga im je ista.
• Da li je to isti čovek koji je nalog i napravio? Pitanje razdvajanja dužnosti: odgovor stoji u istoriji dokumenta, ne u profilu korisnika.

Kad sistem ima samo prvi sloj, ostala tri se ne gube — sele se. Limiti završe u Excel tabeli koju održava neko iz finansija. Opseg podataka postane dogovor da se ne otvaraju tuđi dokumenti. Razdvajanje dužnosti postane rečenica u proceduri koju svi potpišu jednom godišnje. Sva tri mesta su neproverljiva. Kad revizor pita kako sistem sprečava da isti čovek unese dobavljača, izmeni mu tekući račun i plati ga, „imamo proceduru” nije odgovor.

Šest slojeva

Autorizacija koja izdrži reviziju sastoji se od šest provera koje se izvršavaju redom, na serveru, pri svakoj radnji. Ne biraju se — prva koja odbije zaustavlja radnju, a razlog ulazi u dnevnik zajedno sa slojem koji ga je izazvao.

1. 1

   Uloge i dozvole (RBAC)

   Šta korisnik sme kao tip radnje: kreiraj porudžbenicu, proknjiži nalog, izmeni cenovnik. Ne zna ništa o iznosima, partnerima ni istoriji dokumenta. Ovde počinje, ovde ne sme da se završi.

2. 2

   Opseg podataka

   Nad kojim redovima dozvola važi: po pravnom licu, magacinu, sektoru, mestu troška ili kanalu prodaje. Odluka baze, ne filter u interfejsu — ako opseg živi u upitu koji šalje frontend, prvi klijent sa REST pristupom ga zaobiđe.

3. 3

   Limiti odobravanja

   Do kog iznosa i po kojoj dimenziji: rabat do 8%, porudžbenica do 500.000 dinara, otpis zaliha do praga rukovodioca magacina. Limit se računa iz dokumenta u trenutku odluke, po pravilu koje je važilo tog dana.

4. 4

   Razdvajanje dužnosti (SoD)

   Koja ovlašćenja ne smeju da se skupe kod jednog naloga i koje dve radnje ne sme da izvede isti čovek nad istim dokumentom. Jedini sloj koji gleda unazad.

5. 5

   Maker-checker

   Kada je potreban drugi par očiju pre nego što radnja postane stvarna. Nije odobravanje po limitu: limit pita „koliko”, maker-checker pita „ko još”.

6. 6

   Delegacije i zamene

   Šta se dešava kad je odobravalac na godišnjem odmoru. Izgleda kao administrativna sitnica, a najčešća je rupa kroz koju ostalih pet iscuri.

Razdvajanje dužnosti nije spisak uloga koje se ne kombinuju

SoD se najčešće implementira kao statička matrica: uloge A i B ne mogu na istom korisniku. To je lakša polovina posla. Statička provera radi pri dodeli uloge i hvata grešku administratora; dinamička radi pri samoj radnji i hvata ono zbog čega SoD postoji. Statički, isti korisnik sme da ima i ulogu referenta nabavke i ulogu likvidatora — male firme drugačije ne mogu. Dinamički, ne sme da likvidira baš onu fakturu koju je sam uneo. Prvo je pitanje organizacije, drugo pitanje jednog dokumenta.

Parovi koji se u domaćoj praksi ponavljaju:

• Izmena matičnog podatka dobavljača i puštanje plaćanja. Najskuplji par: promeni se tekući račun, novac ode na tuđi, a nalog i dalje ima uredan poziv na broj po modelu 97 i ispravan IPS QR.
• Prijem robe i knjiženje ulazne fakture. Bez razdvajanja je 3-way matching formalnost — isti čovek podešava obe strane koje se porede.
• Popis i knjiženje razlike. Manjak koji ide u interni obračun PDV-a ne sme da odobrava onaj ko je brojao: odluka o manjku je i odluka o poreskoj obavezi.
• Obračun zarada i odobrenje isplate. PPP-PD prijava i nalog banci nisu ista radnja, ma koliko računovodstvo bilo malo.
• Izmena cenovnika i odobrenje nivelacije. U maloprodaji nivelacija menja vrednost zaliha — to nije administracija cena.
• Kreiranje naloga i dodela uloga. Administrator koji sme sebi da doda ulogu ima sve uloge, samo ne odjednom.

Poslednja stavka objašnjava zašto se SoD proverava na dva mesta. Ako se proverava samo pri dodeli uloge, konflikt se sklapa u vremenu: dodaj ulogu, uradi radnju, skini ulogu — snimak u petak uveče izgleda čisto. Ako se proverava samo pri radnji, matrica nikad ne prijavi nespojive kombinacije koje čekaju povod.

Maker-checker: drugi par očiju, ali samo gde vredi

Maker-checker je pravilo da radnja ne postaje stvarna dok je drugi čovek ne potvrdi. Zvuči kao odobravanje, ali odgovara na drugo pitanje. Odobravanje po limitu pita da li iznos prelazi prag. Maker-checker ne pita za iznos — pita da li je radnja takva da je jedan čovek ne sme izvesti sam, bez obzira na to koliko je mala.

Tu spadaju: promena tekućeg računa partnera, storniranje proknjiženog dokumenta, ručna korekcija zaliha, otvaranje zatvorenog perioda, izmena mapiranja poreskog tretmana, brisanje bilo čega. Nemaju iznos, ili im je iznos varljivo mali u odnosu na posledicu — promena jednog polja u matičnom podatku ne prelazi nijedan limit. Zapis odluke se najčešće uradi loše; da bi imao smisla godinu dana kasnije, mora da sadrži:

1. Ko je predložio, ko je potvrdio i kada — u UTC, sa vremenskom zonom korisnika sačuvanom odvojeno.
2. Šta je potvrđivalac video tada: stara i nova vrednost, iznos, partner, verzija pravila. Ne referencu na dokument koji se u međuvremenu promenio deset puta.
3. Zašto — obrazloženje kao obavezno polje na odbijanju i na odobrenju iznad praga koji klijent definiše.
4. Iz kog konteksta: sesija, IP adresa, i da li je radnja došla kroz ekran, API ili automatsko pravilo.
5. Koji sloj je tražio potvrdu i po kom konfiguracionom zapisu — konfiguracija se menja, dnevnik mora da ostane čitljiv i posle toga.

Delegacije — sloj koji ruši ostalih pet

Direktor prodaje ide na godišnji odmor i porudžbenice iznad 500.000 dinara staju. Ako sistem nema delegacije, rešenje je uvek isto i uvek najgore: neko dobije njegovu lozinku. U dnevniku onda piše da je direktor odobravao dok je bio na moru, i to je jedini trag. Delegacija je zato bezbednosni mehanizam, ne kalendarska pogodnost:

• Delegat ne dobija više nego što delegant ima. Delegacija prenosi pravo, ne uvećava ga.
• Delegacija ne sme da zaobiđe SoD. Ako je delegat baš onaj ko je dokument napravio, delegirano pravo na tom dokumentu ne važi — prava se proveravaju, poreklo dokumenta ne.
• Delegacija ima rok i ističe sama. Bez toga se posle tri godine ne zna ko šta stvarno odobrava.
• Dnevnik pamti oba imena: odobrio je delegat, u ime deleganta — dve činjenice, dva polja.
• Delegacija se odobrava, ne dodeljuje samovoljno. Prenos ovlašćenja iznad praga zaslužuje maker-checker.

Nepromenljiv dnevnik

Pet slojeva iznad rade unapred i sprečavaju radnju. Dnevnik radi unazad i odgovara na pitanje koje dolazi mesecima kasnije: ko, šta, kada, po kom pravilu. Reč „nepromenljiv” nije stilska — dnevnik u kome sistem sme da izmeni red je tabela, ne dnevnik. Bez prava na UPDATE i DELETE, sa upisom iz iste transakcije kao i radnja, jer dnevnik koji se piše asinhrono ćuti baš o radnjama koje su pukle.

Četvrti red se najčešće izostavi i najviše košta. Ako odobrenje pamti samo referencu na dokument, revizor godinu dana kasnije otvara odobrenje od 300.000 dinara i vidi dokument od 2,4 miliona, jer je stavka dodata posle. Odobrenje je formalno tu i ne dokazuje ništa. Zato zapis odluke nosi snimak vrednosti iz trenutka odluke — i zato izmena dokumenta posle odobrenja mora da poništi odobrenje.

Kako NG One postavlja ovih šest slojeva

Autorizacija je u NG One-u deo jezgra, uz multitenant izolaciju sa RLS-om na nivou baze i dokument-framework, i to je redosled po nužnosti: sloj koji ne postoji dok se piše prvi use-case znači da su svi use-case-ovi do tada pisani bez njega, a naknadno dodavanje SoD-a u tri stotine ekrana je prepisivanje, ne nadogradnja. Zato svih šest provera radi u sloju usluge, iza istog API-ja kojim se koristi i interfejs: ista odluka važi kad radnju pozove ekran, OpenAPI klijent ili MCP alat. Šta je kritično — koje radnje traže maker-checker, gde su pragovi, koji parovi su nespojivi — određuje klijent konfiguracijom, verzionisano, uz change log koji pamti staru i novu vrednost. Izuzetak je platformska strana, gde je spisak fiksan, jer njime nismo ograničili klijenta nego sebe.