Ako pridať riadenie prístupu na základe rolí (RBAC) do aplikácie

Na pridanie riadenia prístupu na základe rolí dajte každému používateľovi jednu alebo viac rolí (napríklad admin, editor, divák), určite, ktoré akcie každá rola smie vykonať, a tieto oprávnenia kontrolujte na serveri pri každej požiadavke — nie len skrývaním tlačidiel. Overte tiež, či záznam, ku ktorému sa pristupuje, patrí účtu alebo tímu používateľa. Začnite s niekoľkými pevnými rolami vo vašej databáze a testujte tak, že sa pokúsite dostať k dátam iného používateľa priamo.

Autentifikácia vs autorizácia

Dve slová, ktoré sa často zamieňajú:

• Autentifikácia je kto ste? — prihlásenie. Pozrite si ako pridať prihlásenie do aplikácie.
• Autorizácia je čo smiete robiť? — ktoré stránky, záznamy a akcie môže prihlásený používateľ použiť.

RBAC je najbežnejší spôsob autorizácie. Záleží na tom: k septembru 2026 je Broken Access Control na prvom mieste v OWASP Top 10:2025, široko používanom zozname najzávažnejších bezpečnostných rizík webových aplikácií. Typické zlyhania sú, keď používatelia čítajú záznamy iných používateľov zmenou ID v URL, alebo bežní používatelia volajú API trasy vyhradené pre adminov.

Vyberte model

V praxi väčšina aplikácií kombinuje dve veci: roly pre to, aký druh akcií môže niekto robiť, a vlastníctvo pre to, na ktorých záznamoch ich môže robiť. „Editori môžu upravovať príspevky“ je pravidlo roly; „…príspevky vo svojom workspace“ je pravidlo vlastníctva. Potrebujete obe.

Začnite jednoduchšie, než si myslíte. Admin, člen a divák pokryjú prekvapivo veľa aplikácií. Je jednoduchšie rozdeliť rolu neskôr, než rozmotávať desať rolí, ktorým nikto nerozumie.

Navrhnite roly pred písaním kódu

Najprv napíšte tabuľku oprávnení v jednoduchom jazyku. Slúži zároveň ako špecifikácia pre AI a ako váš plán testov:

Rozhodnite aj hraničné prípady: môže posledný vlastník odísť? Môže admin odstrániť vlastníka? Čo vidí odstránený používateľ?

Postup krok za krokom

1. Najprv mať funkčné prihlásenie

RBAC stojí na autentifikácii. Server musí spoľahlivo vedieť, kto robí každú požiadavku, z relácie alebo overeného tokenu — nikdy z ID používateľa, ktoré pošle prehliadač v tele požiadavky.

2. Ukladajte roly v databáze

Pre aplikáciu jedného tímu stačí stĺpec role v tabuľke používateľov. Pre tímy použite tabuľku členstiev:

create table memberships (
  user_id uuid references users(id),
  organization_id uuid references organizations(id),
  role text not null check (role in ('owner','admin','member','viewer')),
  primary key (user_id, organization_id)
);

Nikdy nedovoľte používateľom nastaviť si vlastnú rolu bežnou aktualizáciou profilu. Zmeny rolí idú cez vyhradený koncový bod, ktorý kontroluje oprávnenia.

3. Kontrolujte oprávnenia na serveri, na jednom mieste

Napíšte jeden pomocný nástroj — niečo ako can(user, 'projects.delete', project) — a volajte ho v každej API trase, serverovej akcii a úlohe na pozadí, ktorá číta alebo mení dáta. Jedna centrálna funkcia sa ľahšie kontroluje a testuje než kontroly rozptýlené po kóde. Predvolene zamietajte: ak žiadne pravidlo akciu nepovoľuje, je zamietnutá.

4. Obmedzte každý dotaz

Každý dotaz na dáta tímu má obsahovať tím: where organization_id = :currentOrg, nie len where id = :id. Práve to bráni tomu, aby niekto zmenil /projects/123 na /projects/124 a videl projekt inej firmy. Pre záznamy v iných tímoch vracajte „nenájdené“ namiesto „zakázané“, aby ste neprezradili, že existujú.

5. Pridajte ochranu na úrovni databázy tam, kde záleží

Postgres bezpečnosť na úrovni riadkov (RLS) umožňuje databáze presadiť, ktoré riadky každý používateľ vidí. Je nevyhnutná, ak prehliadač komunikuje s databázou priamo (ako pri niektorých hostovaných backendoch), a inak je užitočnou druhou vrstvou pre citlivé tabuľky.

6. Odrážajte roly v rozhraní

Teraz skryte alebo deaktivujte to, čo používatelia nemôžu robiť, aby aplikácia nebola matúca. Je to len pre použiteľnosť; chránia kontroly na serveri.

7. Zaznamenávajte citlivé akcie

Zaznamenajte, kto menil roly, mazal dáta alebo exportoval záznamy, a kedy. Auditný záznam pomáha pri otázkach podpory a incidentoch.

8. Testujte ako útočník

Prihláste sa ako každá rola a vyskúšajte každú akciu z tabuľky oprávnení. Potom vyskúšajte veci, ktoré nemajú fungovať: volajte administrátorské API trasy ako divák, meňte ID v URL a požiadavkách, odstráňte sa ako posledný vlastník. Automatizované testy pre tabuľku oprávnení stoja za napísanie, keď sa pravidlá ustália.

Prompty, ktoré fungujú

Pridaj riadenie prístupu na základe rolí. Roly na organizáciu: owner, admin, member, viewer, uložené v tabuľke memberships. Oprávnenia sú v tejto tabuľke: [vložte svoju tabuľku]. Vytvor jeden serverový pomocný nástroj can(user, action, resource), predvolene zamietaj a použi ho v každej API trase. Každý dotaz obmedz podľa organization_id. Akcie, ktoré používateľ nemôže robiť, skry v UI, ale nikdy sa na to nespoliehaj pri bezpečnosti.

Prejdi každú API trasu a serverovú funkciu v tejto aplikácii. Pri každej vypíš, aké dáta číta alebo mení, či kontroluje, že je používateľ prihlásený, či kontroluje jeho rolu a či obmedzuje dotaz na jeho organizáciu. Doplň chýbajúce kontroly a ukáž mi zoznam.

Pridaj stránku /admin, na ktorej môže vlastník meniť roly členov. Zabráň odstráneniu alebo degradovaniu posledného vlastníka, každú zmenu roly zaznamenaj s tým, kto ju urobil a kedy, a over, že koncový bod na zmenu roly odmietne každého, kto nie je vlastník.

Časté chyby

• Kontrola rolí len vo front ende. API je stále otvorené pre každého, kto ho zavolá.
• Dôverovanie ID od klienta — userId alebo role v tele požiadavky namiesto relácie.
• Neobmedzené dotazy, ktoré získavajú záznam len podľa ID.
• Roly kontrolované na stránkach, ale nie na API trasách, exportoch, sťahovaní súborov alebo webhookoch.
• Admin podľa e-mailovej adresy napevno zapísanej v kóde (if email === 'me@...'), na ktorú sa ľahko zabudne a ktorú je ťažko zmeniť.
• Príliš veľa rolí príliš skoro, ktoré nikto nedokáže vysvetliť o šesť mesiacov.
• Zastarané relácie: degradovaný používateľ si ponechá admin práva, kým sa neodhlási. Pri citlivých akciách kontrolujte roly z databázy alebo ich obnovujte.

Kontrolný zoznam RBAC

• Tabuľka oprávnení napísaná v jednoduchom jazyku, hraničné prípady rozhodnuté
• Server pozná používateľa z relácie, nikdy z údajov v požiadavke
• Roly uložené v databáze; používatelia nemôžu meniť vlastné
• Jedna centrálna kontrola oprávnení, predvolene zamietavá, použitá v každej trase
• Každý dotaz obmedzený na organizáciu alebo vlastníctvo používateľa
• Bezpečnosť na úrovni riadkov tam, kde sa databáze môže dostať prehliadač
• Rozhranie skrýva, čo používatelia nemôžu robiť (len pre použiteľnosť)
• Citlivé akcie zaznamenané
• Každá rola otestovaná, vrátane priamych volaní API a zmenených ID

Riadenie prístupu je jedna položka dlhšieho zoznamu; bezpečnostný kontrolný zoznam pre aplikácie vytvorené AI pokrýva zvyšok. Ak staviate nástroj pre vlastných zamestnancov, ako vytvoriť interný nástroj ukazuje, kde roly zapadajú.

RBAC v Mythex

Mythex neposkytuje vstavaný systém prihlasovania ani rolí pre používateľov vašej aplikácie. Vyberiete knižnicu alebo poskytovateľa autentifikácie a popíšete roly; agent ich zapojí do vášho kódu a do Postgres databázy projektu (pridanie prihlásenia do aplikácie). Pracovné roly Mythex, ako Owner a Member, riadia, kto môže upravovať vaše projekty v Mythex, nie kto môže používať publikovanú aplikáciu. Pred stavbou použite režim plánu, aby ste sa dohodli na tabuľke oprávnení, potom použite vyššie uvedený prompt na kontrolu a pred publikovaním otestujte každú rolu v náhľade. Užitočným ďalším krokom sú bezpečnostné prompty v dokumentácii.

Otázky