Slovník pojmů

RBAC

RBAC mapuje uživatele přes role na oprávnění. Udržuje správu přístupů čitelnou, pokud role odpovídají skutečné práci a kontrola probíhá na serveru.

Stručná definice

Role jsou zkratka pro opakující se odpovědnost.

Role-Based Access Control (RBAC), česky řízení přístupu podle rolí, organizuje oprávnění do pojmenovaných rolí. Místo ručního přiřazování každého povolení všem uživatelům dostane například pracovník skladu roli s oprávněním číst objednávky a měnit expedici, zatímco účetní vidí doklady a platby.

RBAC řeší autorizaci, tedy otázku, zda smí už ověřený uživatel provést konkrétní akci nad konkrétním zdrojem. Není to autentizace: přihlášení zjistí, kdo uživatel je; RBAC rozhodne, co smí dělat. V multi-tenant systému se navíc role obvykle váže na organizaci nebo účet, nikoli globálně na člověka.

Použití

Kde jsou oprávnění součástí business pravidel

Model dává smysl, když se stejné pracovní pravomoci opakují u více uživatelů.

e-shopová administrace pro sklad, zákaznickou podporu, účetní a správce
interní systém s oddělením prodeje, provozu a finance
multi-tenant SaaS, kde má stejný uživatel jinou úlohu v různých organizacích
API administrace, které musí na serveru ověřit akci i hranici organizace
audit správy oprávnění, onboardingu a odebrání přístupu

Praktický příklad

Jedna osoba, dvě organizace

Uživatelka Jana je vlastník v organizaci Alfa a čtenář v organizaci Beta. V Alfě může přiřadit pracovníka skladu a schválit export objednávek. V Betě smí jen číst přehled. Aplikace proto nedrží jedinou globální roli Jana = vlastník, ale vazbu uživatel–organizace–role.

Při požadavku na expedici objednávky server nejprve načte objednávku, určí její organizaci a až potom ověří oprávnění order.ship v této organizaci. Frontend může tlačítko skrýt pro lepší UX, ale stejná kontrola musí proběhnout v API či controlleru, protože request lze poslat i bez tlačítka.

Jak funguje

Jednoduchý diagram rozhodnutí o přístupu

Každý krok potřebuje jasný zdroj pravdy a vazbu na aktuální kontext organizace.

Uživatel se ověří Relace nebo identity provider doloží identitu, ne automaticky oprávnění k operaci.
Aplikace určí tenant Z URL, vybrané organizace nebo vlastnictví zdroje zjistí, ve kterém účtu uživatel pracuje.
Načtou se aktuální role Přiřazení uživatel–organizace poskytne jednu nebo více rolí pro daný kontext.
Role se přeloží na oprávnění Například order.read, order.ship nebo invoice.export představují konkrétní povolené akce.
Server povolí nebo zamítne akci Kontrola ověří oprávnění i vlastnictví zdroje; skryté tlačítko ve frontendu samo nestačí.

Důležité pojmy

Model musí mít hranice i provozní pravidla.

Názvy rolí mají být srozumitelné lidem i kódu, ale nemají suplovat všechny detaily business pravidel.

Role a oprávnění

Role seskupuje oprávnění. Oprávnění popisuje konkrétní akci, například změnit stav zásilky. Jeden uživatel může mít více rolí, pokud jejich kombinace odpovídá pracovním povinnostem.

Výchozí zákaz a nejmenší oprávnění

Akce se povolí jen při explicitní kontrole. Nová role nemá zdědit vše jen pro pohodlí; přístup se rozšiřuje podle ověřené potřeby.

Systémová a kontextová role

Globální administrátor platformy a správce jedné organizace mají jiný dosah. Ten samý člověk může být vlastník v jedné firmě a čtenář v jiné.

Audit a změny

Přiřazení rolí, jejich změna i odebrání má mít dohledatelný záznam. U citlivých akcí se vyplatí ověřit aktuální stav, ne jen dlouho platný token.

Vztah k podobným pojmům

Role nejsou login, scope ani samotný token.

Záměna těchto vrstev vede k příliš širokým nebo naopak nečitelným pravidlům.

Autentizace: Prokazuje identitu uživatele. Bez ní RBAC neví, komu přístup vyhodnotit, ale sama nezaručuje povolení akce.
OAuth 2.0 scope: Scope vymezuje delegovaný přístup klienta k API. Aplikační RBAC řeší interní oprávnění uživatele v businessovém kontextu; někdy se doplňují, nejsou zaměnitelné.
ACL a ABAC: ACL může přiřazovat přístup přímo ke zdroji, ABAC rozhoduje podle atributů a pravidel. RBAC je jednodušší model rolí; systémy je mohou kombinovat.
JWT: Token může nést identitu nebo krátkodobý kontext, ale role zapsaná v dlouho platném tokenu může po změně oprávnění zastarat.

Výhody a omezení

Přehlednost mizí, když se role začnou větvit podle každé výjimky.

Přínosy

opakované pravomoci se spravují po skupinách místo po uživatelích
serverová kontrola lze sjednotit do čitelných pravidel
audit přiřazení a rychlé odebrání přístupu jsou jednodušší
tenantový kontext brání záměně mezi organizacemi

Rizika

role explosion vzniká z mnoha téměř stejných rolí a výjimek
příliš obecná role administrátor obchází princip nejmenších oprávnění
pouhé schování tlačítka nechrání API ani formulář
hierarchie rolí může skrýt nečekané zděděné povolení

Hranice použití

Role mají odrážet práci, ne strukturu menu.

Pro menší administraci mohou stačit tři až čtyři stabilní role. U složitějšího systému se vyplatí oddělit oprávnění od zobrazení navigace, specifikovat hranici organizace a popsat citlivé akce v kódu i dokumentaci. Když se rozhodnutí odvíjí hlavně od vlastností samotného záznamu, času nebo smluvního vztahu, RBAC může potřebovat doplnit další pravidla.

Role se nemají stát jediným místem pro každou business výjimku. Například účetní může mít invoice.export, ale export stále patří jen do aktuální organizace a může vyžadovat další kontrolu stavu objednávky. Pravidelná revize přístupů a audit jsou součástí návrhu, ne administrativní dodatek.

Na co myslet

Oprávnění testovat na serverové hranici.

Bezpečný návrh počítá se změnou rolí, více tenanty i pokusem obejít uživatelské rozhraní.

výchozí zákaz přístupu a explicitní oprávnění pro chráněnou akci
kontrola tenanta a vlastnictví zdroje vedle kontroly role
jednotné pojmenování oprávnění a testy povolených i zamítnutých cest
audit změn role a rychlé odebrání přístupu při změně pracovní pozice
krátká platnost nebo nové vyhodnocení citlivého oprávnění místo slepé důvěry dlouhému tokenu

Časté otázky

Jak RBAC používat bez falešné jistoty

Je role administrátor vždy neomezený přístup?

Ne. Administrátor jedné organizace nemusí spravovat jiného tenanta ani provozní nastavení celé platformy. Rozsah se má pojmenovat a kontrolovat explicitně.

Stačí role uložená v JWT?

Záleží na délce platnosti a riziku. Po odebrání role může dlouho platný token nést zastaralý údaj; citlivé akce často potřebují aktuální vyhodnocení.

Je OAuth scope role?

Ne. Scope vymezuje oprávnění klienta k rozhraní. Role typicky popisuje pracovní pravomoc uživatele v konkrétní aplikaci či organizaci.

Kdy RBAC nestačí?

Pokud rozhodnutí závisí hlavně na atributech zdroje, vztahu uživatele k němu nebo čase, je vhodné RBAC doplnit cílenými business pravidly či jiným modelem.

Jak navrhuji přístup v praxi

Oprávnění patří do serverové a datové hranice aplikace.

U interních systémů, API a e-commerce řeším, kdo může provést konkrétní akci a v jakém kontextu organizace.

Prohlédnout znalosti Nezávazně probrat projekt