Jan Mikoláš
Slovník pojmů
Autorizace
Autorizace chrání data a akce po přihlášení. Přihlášený uživatel není automaticky oprávněný číst cizí objednávku, upravit cenu ani měnit roli jiného uživatele.
Stručná definice
Oprávnění se vyhodnocuje nad akcí, zdrojem a kontextem.
Server nejprve rozpozná subjekt z relace, tokenu nebo jiného ověřeného credentialu. Potom vyhodnotí politiku: může role umožnit akci, ale často rozhoduje i příslušnost k organizaci, vlastnictví objednávky, stav záznamu, obchodní pravidlo nebo rozsah přístupového tokenu. Toto rozhodnutí se nesmí přenechat jen uživatelskému rozhraní.
Autorizace má být vynucena u každé vstupní cesty, zejména u API endpointů, background jobů a hromadných operací. Odkaz skrytý ve frontendu není ochrana: klient může request vytvořit přímo. Stejně tak platný JWT nebo session pouze určí subjekt; jeho aktuální oprávnění server ověřuje znovu pro prováděnou operaci.
K čemu slouží
Ochrana zdrojů, tenantů a rizikových operací
Přístupové pravidlo se vyplatí pojmenovat podle skutečné business akce, ne podle toho, které tlačítko ji zrovna spouští.
- zobrazení a úprava objednávky jen v organizaci, ke které operátor patří
- oddělení zákaznického účtu, skladu, účetnictví a administrace v e-shopu
- omezení integračního tokenu na konkrétní API scope, obchod nebo typ operace
- schválení vrácení peněz, exportu osobních údajů nebo změny uživatelských rolí
- kontrola přístupu v API, UI controlleru, CLI příkazu i asynchronním workeru
Praktický příklad
Zrušení objednávky v konkrétní organizaci
Operátor může mít obecné oprávnění rušit objednávky, ale to nestačí. Server musí po načtení objednávky ověřit i její organizaci, stav a případné pravidlo, že daná role už nesmí zasahovat do již expedované objednávky. Teprve po tomto rozhodnutí zavolá aplikační službu, která změnu provede.
Příklad ukazuje záměrně explicitní serverovou hranici. V konkrétním frameworku může být politika zapsaná jako voter, policy nebo aplikační služba; podstatné je, že kontrola proběhne před mutací a pracuje s reálným zdrojem, ne jen s hodnotou z klienta.
$authorization->assertCan(
actor: $currentUser,
permission: 'order.cancel',
organizationId: $order->organizationId,
);
$orderService->cancel($order);Jak funguje
Od requestu k rozhodnutí, které vynucuje server
Spolehlivá autorizace používá důvěryhodnou identitu i serverem načtený stav zdroje.
- Request předloží credential Session nebo token dovolí serveru určit subjekt. Neplatný či prošlý credential se odmítne ještě před rozhodováním o právech.
- Server načte cílový zdroj Objednávku, účet nebo jiný objekt hledá podle bezpečné cesty a zná jeho vlastníka, organizaci, stav i citlivost.
- Politika vyhodnotí kontext Spojí identitu, roli, tenant, požadovanou akci, scope a business omezení. Nejde jen o podmínku isAdmin.
- Server akci povolí nebo odmítne Kontrola běží před změnou nebo zveřejněním dat. U zamítnutí API vrátí vhodný stav bez prozrazení cizích citlivých údajů.
- Citlivý krok se dohledá Pro důležité operace se zaznamená kdo, co a kdy provedl. Audit nenahrazuje prevenci, ale pomáhá incident vyšetřit.
Modely a pojmy
Role jsou začátek, zdrojová pravidla rozhodují v praxi
Systém obvykle kombinuje několik úrovní pravidel. Jedna univerzální role s přístupem ke všemu se v dlouhodobém projektu rychle stane problémem.
RBAC
Role-based access control přiřazuje oprávnění rolím, například order.cancel. Zjednodušuje správu běžných pracovních rolí, ale neřeší automaticky vlastnictví zdroje.
Kontrola zdroje a tenantu
Aplikace zjišťuje, zda objednávka patří do organizace aktuálního operátora a zda má k danému zákazníkovi vztah. Chrání před IDOR a únikem mezi tenanty.
Scope a delegované tokeny
Scope omezuje účel tokenu, například čtení katalogu. Je užitečný na API hranici, ale nenahradí detailní politiku pro konkrétní záznam.
Princip nejmenších oprávnění
Subjekt dostává jen přístupy potřebné pro svou práci. Výchozí stav je zamítnutí a nová oprávnění se přidávají vědomě.
Centrální politika
Pojmenovaná policy, voter či aplikační služba zabraňuje tomu, aby stejné pravidlo bylo v controllerech, jobech a formulářích napsáno různě.
Vztah k ostatním nástrojům
Credential, role a aplikační pravidlo mají vlastní odpovědnost
Bezpečnostní návrh je čitelnější, pokud se role jednotlivých mechanismů nemíchají.
- Autentizace
- Řekne, který uživatel nebo služba request poslala. Neuděluje sama právo na konkrétní data.
- RBAC
- Dává opakovaně použitelný model pro role a oprávnění. U více tenantů jej doplňuje kontrola vlastnictví a organizace.
- OAuth 2.0
- Deleguje omezený přístup mezi klientem a resource serverem. Lokální aplikace stále ověřuje, co scope dovoluje nad konkrétním zdrojem.
- Session a JWT
- Jsou způsoby, jak předat ověřenou identitu nebo tvrzení. Ani jeden nenahrazuje autorizaci v business vrstvě.
Výhody a omezení
Pravidla mají chránit skutečný systém, ne jen jeho URL
Přínosy
- chrání citlivé zdroje i tehdy, když klient obejde uživatelské rozhraní
- zlepšuje oddělení tenantů, pracovních rolí a strojových integrací
- pojmenované politiky jsou testovatelné a použitelné v API, UI i workerech
- audit citlivých operací podporuje dohledatelnost a správu incidentů
Rizika a časté chyby
- schovat tlačítko ve frontendu a neověřit stejnou akci na serveru
- ověřit obecnou roli, ale ne vlastnictví objektu, organizaci nebo aktuální stav
- důvěřovat ID organizace, roli nebo ceně zaslané klientem místo serverového zdroje pravdy
- stavět příliš složitý model rolí dříve, než jsou jasné reálné akce a odpovědnosti
Kde je nejdůležitější
Každá cesta k datům potřebuje stejnou serverovou hranici
Autorizace je kritická všude, kde aplikace obsluhuje více uživatelů, organizací nebo služeb. V e-commerce typicky rozlišuje zákazníka, sklad, zákaznickou podporu, finance, administrátora a marketplace integraci. Každá z těchto identit pracuje s jiným druhem dat a má odlišné dovolené změny.
Jednoduchý projekt může začít několika srozumitelnými oprávněními a kontrolou vlastnictví. S růstem je vhodné pravidla centralizovat, testovat negativní scénáře a zavést audit pro rizikové operace. Komplikovaný model ABAC nebo vlastní policy engine není užitečný jen proto, že existuje; hranice mají odpovídat reálným procesům.
Na co myslet
Oprávnění se kontroluje vždy na serveru a nad skutečným zdrojem
Při změně endpointu, workeru nebo UI je bezpečnější znovu použít politiku než ji kopírovat do nové vrstvy.
- vyhodnocovat oprávnění před akcí v API, controlleru, CLI i asynchronním jobu
- načítat ownership, tenant a stav objektu na serveru; nepřebírat je nekriticky z requestu
- používat výchozí zamítnutí a dávat rolím i tokenům jen potřebný minimální rozsah
- testovat zejména negativní scénáře: cizí tenant, cizí zdroj, prošlá role a obejití UI
- u citlivých změn přidat audit, přiměřenou reautentizaci a srozumitelnou správu oprávnění
Časté otázky
Rozhodování o přístupu v praxi
Jaký je rozdíl mezi autorizací a autentizací?
Autentizace ověří identitu. Autorizace posoudí, zda ověřený subjekt smí vykonat konkrétní akci nad konkrétním zdrojem.
Stačí skrýt tlačítko uživateli bez role?
Ne. Skrytí tlačítka jen upraví rozhraní. Uživatel nebo jiný klient může poslat request přímo, proto musí stejnou akci odmítnout server.
Je RBAC dostatečný pro multitenant aplikaci?
Často ne. Role popisuje obecné oprávnění, ale vedle ní je potřeba ověřit vztah ke konkrétní organizaci, objednávce nebo zákazníkovi.
Nahrazuje scope v OAuth autorizaci aplikace?
Scope omezuje účel delegovaného tokenu. Resource server však stále vyhodnocuje lokální pravidla a vztah subjektu ke konkrétnímu zdroji.
Jak řeším architekturu v praxi
Pravidla přístupu držím blízko aplikačním akcím a zdrojům.
Při návrhu backendu odděluji přihlášení, role, tenantová pravidla a business operace tak, aby šly bezpečně znovu použít i otestovat.