RBAC — Role-Based Access Control
RBAC (Role-Based Access Control) je model riadenia prístupov, v ktorom sú oprávnenia priradené roliam — napríklad admin, manažér, člen tímu — a nie priamo jednotlivým používateľom. Používateľ získa prístupy pridelením roly, nie individuálnymi povoleniami pre každú akciu.
Ako to funguje
Predstavte si systém bez RBAC: každý používateľ má zoznam konkrétnych povolení — môže čítať faktúry, nemôže ich mazať, môže vidieť pacientov oddelenia A, nemôže vidieť oddelenie B. Pri piatich používateľoch to zvládnete. Pri päťdesiatich je správa povolení plnohodnotná práca a chyby sú nevyhnutné — zabudnete odobrať prístup prepustenému zamestnancovi, alebo omylom pridelíte prístup k citlivým dátam. RBAC tento problém rieši iným úrovňom abstrakcie: definujete role, role majú povolenia, používateľom prideľujete role.
Základné koncepty RBAC: rola je pomenovaná množina oprávnení (admin smie všetko, fyzioterapeut smie čítať a upravovať záznamy pacientov, pacient smie čítať len svoje vlastné záznamy). Oprávnenie je konkrétna akcia na konkrétnom zdroji (read:patient-records, write:invoices, delete:users). Guard je overenie, ktoré prebehne na serveri pred každou citlivou operáciou — nie len v UI, kde ho používateľ môže obísť. Toto rozlíšenie je kritické: skrytie tlačidla v UI nie je bezpečnosť, overenie na serveri je.
Multi-tenant systémy pridávajú ďalšiu dimenziu: používateľ môže byť adminom v jednom workspace a radovým členom v druhom. Táto tenant-level izolácia sa implementuje kombináciou RBAC a row-level security v databáze — používateľ fyzicky nemôže vidieť dáta iného tenanta ani keď obíde UI. Pre zdravotnícke systémy, kde dochádza k spracovaniu osobných a zdravotných dát, je táto izolácia nielen best practice, ale aj regulatórna požiadavka.
Implementácia RBAC má niekoľko úrovní prísnosti. Základná úroveň: rola je atribút v databáze, každý API endpoint overuje rolu z tokenu. Pokročilejšia úroveň: atribútový prístup (ABAC) rozširuje RBAC o kontext — napríklad fyzioterapeut smie meniť záznamy len svojich pacientov, nie všetkých pacientov v systéme. Najprísnejšia úroveň kombinuje RBAC v aplikačnej vrstve s row-level security v PostgreSQL — aj keby kód mal chybu, databáza odmietne vrátiť záznamy, ku ktorým používateľ nemá prístup.
Z našej praxe
V Strange Loops je RBAC štandardnou súčasťou každého projektu s viacerými typmi používateľov. Implementujeme ho cez Better Auth s vlastnou rozšíriteľnou vrstvou rolí a oprávnení. Pre rehabit (klinický IS pre SylvoRehab) sme definovali role admin, fyzioterapeut a pacient — každá s presnou hranicou toho, čo smie čítať, upravovať a mazať. Fyzioterapeut vidí len svojich pacientov, nie všetkých v systéme. Pre QualiTravel je RBAC multi-tenant: každá cestovná kancelária je tenant, v rámci nej existujú role admin a agent. V Ovulogy máme jednoduché role používateľ a admin, ale s presnou izoláciou dát — jedna používateľka nikdy neuvidí záznamy inej. Všetky guardy sú na úrovni tRPC middlewaru a sú testované automaticky.
Kedy to potrebujete
- Zdravotnícky informačný systém kde lekár, sestra, fyzioterapeut a pacient vidia úplne iné časti systému a pracujú s rôznou úrovňou citlivých dát
- Multi-tenant SaaS kde každý klient (tenant) je izolovaný — jeho administrátor spravuje vlastných používateľov, ale nevidí dáta iných tenantov
- B2B portál kde obchodný zástupca vidí len svojich klientov a ich objednávky, manažér vidí všetko a má schvaľovacie právomoci
- Interný podnikový systém kde HR vidí mzdy, obchodné oddelenie vidí pipeline, ale nikto okrem finančného riaditeľa nevidí oboje naraz
Najčastejšie otázky
Čo je rozdiel medzi RBAC a ABAC?
RBAC prideľuje oprávnenia na základe roly — ak ste admin, máte prístup X. ABAC (Attribute-Based Access Control) rozhoduje na základe atribútov používateľa, zdroja a kontextu — fyzioterapeut má prístup k záznamu pacienta, len ak je tento pacient priradený práve k nemu. ABAC je flexibilnejší, ale zložitejší na implementáciu. V praxi sa kombinujú: RBAC pre hrubé rozdelenie prístupov, ABAC pre jemné dolaďovanie.
Stačí skryť tlačidlo v UI ak používateľ nemá oprávnenie?
Nie. Skrytie tlačidla v UI je len UX, nie bezpečnosť. Skúsený používateľ môže priamo zavolať API endpoint bez použitia UI. Každá citlivá operácia musí byť chránená na úrovni servera — guard, ktorý overí oprávnenie z autentifikačného tokenu pred vykonaním operácie. Skrytie v UI je príjemné, ale nie postačujúce.
Ako sa RBAC implementuje technicky?
Typicky: rola je uložená pri používateľovi v databáze a zakódovaná v JWT tokene alebo session. Na každom chránenom API endpointe prebehne middleware, ktorý overí rolu z tokenu a porovná ju s požadovaným oprávnením pre daný endpoint. Pri tRPC sa guard implementuje ako reusable middleware procedúra, ktorú zahrniete do každej chránenej procedúry. Pre jemnejšiu kontrolu sa rola overuje aj v databázovom dotaze cez WHERE podmienku alebo PostgreSQL row-level security.
Súvisiace pojmy
TypeScript
TypeScript je programovací jazyk od Microsoftu — JavaScript rozšírený o statický typový systém. Kompilátor overí, že funkcie dostávajú správne parametre a objekty majú správnu štruktúru ešte pred spustením kódu, čím zachytí celú triedu chýb, ktoré by inak objavil až používateľ v produkcii.
tRPC
tRPC je framework, ktorý umožňuje volať serverové funkcie z frontendu s plnou typovou bezpečnosťou — bez generovania kódu, bez REST schém, bez manuálnej synchronizácie typov. TypeScript overí správnosť volania pri kompilácii.
OWASP Top 10
OWASP Top 10 je autoritatívny zoznam desiatich najrozšírenejších a najkritickejších bezpečnostných zraniteľností webových aplikácií, ktorý vydáva Open Worldwide Application Security Project — slúži ako základ pre bezpečnostné audity aj vývojové štandardy.
Potrebujete s tým pomôcť?
Ak riešite niečo z toho, čo tu opisujeme, ozvite sa. Povieme vám, či a ako vieme pomôcť.