Spíšte zdroje a akcie, priraďte ich pracovným zodpovednostiam, oddeľte rolu od vlastníctva konkrétneho záznamu a prideľujte najmenšie práva. Autorizáciu vynucujte na serveri, citlivé akcie auditujte a pravidelne kontrolujte účty, dočasné prístupy a testy zakázaných scenárov.
Roly a oprávnenia vo webovej aplikácii určujú, kto smie vidieť údaje a vykonať konkrétnu akciu. Jednoduché rozdelenie používateľ a administrátor sa pri raste rýchlo rozpadne. Podpora potrebuje nahliadnuť do prípadu bez zmeny ceny, vedúci schvaľovať iba svoj tím a externý spolupracovník pristupovať k vybranému projektu na obmedzený čas.
Bezpečný model vzniká z reálnych úloh, vlastníctva zdrojov a princípu najmenších práv. Kontrola musí fungovať na serveri pri každej operácii, nie iba skrývať tlačidlo v rozhraní. Zároveň má zostať zrozumiteľná pre správcu, testovateľná pre vývoj a auditovateľná pri incidente alebo personálnej zmene.
Modelujte akcie a zdroje pred názvami rolí
Zozbierajte používateľské úlohy a rozložte ich na zdroj, akciu a rozsah. Nestačí právo objednávky; rozlišujte čítanie, vytvorenie, úpravu, schválenie, export a zrušenie. Rozsah môže byť vlastný záznam, tím, pobočka alebo celá organizácia. Takáto matica odhalí nebezpečné spojenie práv aj chýbajúcu zodpovednosť.
Až potom zoskupte oprávnenia do rolí zodpovedajúcich skutočnej práci. Názov manažér môže mať v oddeleniach odlišný význam, preto rolu doplňte popisom a vlastníkom. Nezakladajte novú rolu pre každého človeka. Výnimku riešte časovo obmedzeným prístupom alebo jasným pravidlom, inak model nebude udržateľný.
- zdroj a konkrétna povolená akcia
- rozsah vlastných, tímových alebo firemných dát
- podmienky schválenia a citlivosti
- zodpovedná rola a vlastník oprávnenia
Kombinujte rolu s vlastníctvom a kontextom
Rola sama často nestačí. Redaktor môže upravovať iba pridelené projekty a zákazník iba vlastné objednávky. Server preto overuje aj väzbu používateľa na konkrétny objekt, organizáciu a stav. Ak je záznam schválený, rovnaká rola už nemusí smieť meniť cenu. Kontextové pravidlá dokumentujte ako súčasť doménového procesu.
Vyhnite sa autorizácii založenej na údajoch od klienta, napríklad na poslanom ID organizácie bez serverového overenia členstva. Každý dotaz a mutácia musia používať dôveryhodný kontext identity. Pri hromadnej operácii kontrolujte každý cieľ alebo bezpečne obmedzenú kolekciu, nie iba prvý záznam.
Navrhnite administráciu a dočasný prístup
Správca potrebuje vidieť, prečo má používateľ konkrétne právo, kto ho pridelil a dokedy platí. Kritické roly prideľujte cez schválený proces a chráňte viacfaktorovým overením. Predvolená rola nového účtu má byť minimálna. Pozvanie, zmena tímu a deaktivácia musia aktualizovať prístup bez ručného zásahu do databázy.
Podpora môže potrebovať dočasne zobraziť stav zákazníka alebo konať v jeho mene. Takú schopnosť technicky obmedzte, časovo ohraničte, viditeľne označte a auditujte. Citlivá akcia môže vyžadovať ďalšie potvrdenie. Nezdieľajte zákaznícke heslo ani univerzálny administrátorský účet, ktorý znemožní priradiť zásah človeku.
Vynucujte pravidlá na serveri a auditujte citlivé akcie
Rozhranie môže skryť nepovolené tlačidlo, no server musí odmietnuť priamu požiadavku. Autorizáciu umiestnite do opakovateľnej vrstvy blízko doménovej operácie, aby sa na ňu nezabudlo v novom endpoint-e alebo dávke. Odpoveď nemá prezradiť existenciu cudzieho citlivého objektu viac, než je potrebné.
Auditný záznam pri významnej zmene obsahuje aktéra, akciu, objekt, čas, bezpečný dôvod a výsledok. Neuchovávajte zbytočne celý citlivý obsah. Log chráňte pred úpravou bežným správcom a nastavte retenciu podľa rizika a povinností. Audit pomáha vyšetrovať, nie nahrádzať prevenciu.
Testujte zakázané cesty a pravidelne revidujte prístupy
Automatické testy pokrývajú povolenú aj zakázanú akciu pre každú citlivú kombináciu roly, vlastníctva a stavu. Skúste zmeniť ID v URL, použiť staré pozvanie, priamo zavolať API a vykonať hromadnú operáciu s jedným cudzím záznamom. Regresný test pridajte pri každom incidente alebo novom pravidle.
Pravidelne kontrolujte aktívne účty, kritické roly, dočasné výnimky a technické identity. Odchod človeka alebo zrušenie projektu musí spustiť odobratie prístupu. Sledujte neobvyklé zamietnutia a zmeny rolí, ale alarmy interpretujte v kontexte. Model aktualizujte s procesom, nie až keď stará rola začne znamenať všetko.
- povolený scenár pre každú pracovnú rolu
- zamietnutý prístup k cudziemu zdroju
- vypršané pozvanie a deaktivovaný používateľ
- revízia dočasných a privilegovaných oprávnení
- audit každej zmeny kritickej roly
Časté otázky
Aký je rozdiel medzi rolou a oprávnením?
Oprávnenie povoľuje konkrétnu akciu nad zdrojom. Rola zoskupuje oprávnenia podľa pracovnej zodpovednosti. Skutočný prístup môže navyše závisieť od vlastníctva, organizácie a stavu záznamu.
Stačí skryť nepovolenú funkciu v rozhraní?
Nie. Skrytie zlepšuje použiteľnosť, ale klient možno obísť. Server musí pri každej operácii overiť identitu, oprávnenie aj kontext cieľového objektu.
Má mať podpora administrátorský účet?
Iba práva potrebné na podporu, ideálne dočasné a auditované. Univerzálny zdieľaný administrátor zvyšuje dopad chyby a znemožňuje určiť zodpovednosť za konkrétnu akciu.
Zdroje a ďalšie čítanie
Web developer zo Spišskej Novej Vsi. Venuje sa WordPressu, WooCommerce, vlastným pluginom, API integráciám, webovým aplikáciám a praktickým AI automatizáciám.
