Sepište zdroje a akce, přiřaďte je pracovním odpovědnostem, oddělte roli od vlastnictví konkrétního záznamu a přidělujte nejmenší oprávnění. Autorizaci vynucujte na serveru, citlivé akce auditujte a pravidelně kontrolujte účty, dočasné přístupy a testy zakázaných scénářů.
Role a oprávnění ve webové aplikaci určují, kdo smí vidět údaje a provést konkrétní akci. Jednoduché rozdělení na uživatele a administrátora se při růstu rychle rozpadne. Podpora potřebuje nahlédnout do případu bez možnosti změnit cenu, vedoucí schvalovat pouze svůj tým a externí spolupracovník přistupovat k vybranému projektu po omezenou dobu.
Bezpečný model vzniká z reálných úkolů, vlastnictví zdrojů a principu nejmenších oprávnění. Kontrola musí fungovat na serveru při každé operaci, ne pouze skrývat tlačítko v rozhraní. Zároveň má zůstat srozumitelná pro správce, testovatelná pro vývoj a auditovatelná při incidentu nebo personální změně.
Modelujte akce a zdroje před názvy rolí
Shromážděte uživatelské úlohy a rozložte je na zdroj, akci a rozsah. Nestačí oprávnění k objednávkám; rozlišujte čtení, vytvoření, úpravu, schválení, export a zrušení. Rozsahem může být vlastní záznam, tým, pobočka nebo celá organizace. Taková matice odhalí nebezpečné kombinace oprávnění i chybějící odpovědnost.
Teprve poté seskupte oprávnění do rolí odpovídajících skutečné práci. Název manažer může mít v různých odděleních odlišný význam, proto roli doplňte popisem a vlastníkem. Nezakládejte novou roli pro každého člověka. Výjimku řešte časově omezeným přístupem nebo jasným pravidlem, jinak model nebude udržitelný.
- zdroj a konkrétní povolená akce
- rozsah vlastních, týmových nebo firemních dat
- podmínky schválení a citlivosti
- odpovědná role a vlastník oprávnění
Kombinujte roli s vlastnictvím a kontextem
Samotná role často nestačí. Redaktor může upravovat pouze přidělené projekty a zákazník pouze vlastní objednávky. Server proto ověřuje i vazbu uživatele na konkrétní objekt, organizaci a stav. Pokud je záznam schválený, stejná role už nemusí smět měnit cenu. Kontextová pravidla dokumentujte jako součást doménového procesu.
Vyhněte se autorizaci založené na údajích od klienta, například na zaslaném ID organizace bez serverového ověření členství. Každý dotaz a mutace musí používat důvěryhodný kontext identity. U hromadné operace kontrolujte každý cíl nebo bezpečně omezenou kolekci, nikoli jen první záznam.
Navrhněte administraci a dočasný přístup
Správce potřebuje vidět, proč má uživatel konkrétní oprávnění, kdo ho přidělil a do kdy platí. Kritické role přidělujte přes schválený proces a chraňte je vícefaktorovým ověřením. Výchozí role nového účtu má být minimální. Pozvání, změna týmu a deaktivace musí aktualizovat přístup bez ručního zásahu do databáze.
Podpora může potřebovat dočasně zobrazit stav zákazníka nebo jednat jeho jménem. Takovou schopnost technicky omezte, časově ohraničte, viditelně označte a auditujte. Citlivá akce může vyžadovat další potvrzení. Nesdílejte zákaznické heslo ani univerzální administrátorský účet, který znemožní přiřadit zásah konkrétnímu člověku.
Vynucujte pravidla na serveru a auditujte citlivé akce
Rozhraní může skrýt nepovolené tlačítko, ale server musí přímý požadavek odmítnout. Autorizaci umístěte do opakovaně použitelné vrstvy blízko doménové operace, aby se na ni nezapomnělo v novém endpointu nebo dávce. Odpověď nemá prozrazovat existenci cizího citlivého objektu víc, než je nutné.
Auditní záznam při významné změně obsahuje aktéra, akci, objekt, čas, bezpečný důvod a výsledek. Zbytečně neuchovávejte celý citlivý obsah. Log chraňte před úpravou běžným správcem a nastavte retenci podle rizika a povinností. Audit pomáhá vyšetřovat, nenahrazuje prevenci.
Testujte zakázané cesty a pravidelně revidujte přístupy
Automatické testy pokrývají povolenou i zakázanou akci pro každou citlivou kombinaci role, vlastnictví a stavu. Zkuste změnit ID v URL, použít staré pozvání, přímo zavolat API a provést hromadnou operaci s jedním cizím záznamem. Regresní test přidejte při každém incidentu nebo novém pravidle.
Pravidelně kontrolujte aktivní účty, kritické role, dočasné výjimky a technické identity. Odchod člověka nebo zrušení projektu musí spustit odebrání přístupu. Sledujte neobvyklá zamítnutí a změny rolí, ale alarmy interpretujte v kontextu. Model aktualizujte spolu s procesem, ne až ve chvíli, kdy stará role začne znamenat všechno.
- povolený scénář pro každou pracovní roli
- zamítnutý přístup k cizímu zdroji
- vypršelá pozvánka a deaktivovaný uživatel
- revize dočasných a privilegovaných oprávnění
- audit každé změny kritické role
Časté dotazy
Jaký je rozdíl mezi rolí a oprávněním?
Oprávnění povoluje konkrétní akci nad zdrojem. Role seskupuje oprávnění podle pracovní odpovědnosti. Skutečný přístup může navíc záviset na vlastnictví, organizaci a stavu záznamu.
Stačí skrýt nepovolenou funkci v rozhraní?
Ne. Skrytí zlepšuje použitelnost, klienta však lze obejít. Server musí při každé operaci ověřit identitu, oprávnění i kontext cílového objektu.
Má mít podpora administrátorský účet?
Pouze práva potřebná pro podporu, ideálně dočasná a auditovaná. Univerzální sdílený administrátor zvyšuje dopad chyby a znemožňuje určit odpovědnost za konkrétní akci.
Zdroje a další čtení
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
