Szerepkör alapú hozzáférés-szabályozás (RBAC) hozzáadása az appodhoz

Ahhoz, hogy szerepkör alapú hozzáférés-szabályozást adj hozzá, adj minden felhasználónak egy vagy több szerepkört (például adminisztrátor, szerkesztő, megtekintő), határozd meg, mit tehet meg az egyes szerepkörök, és ezeket a jogosultságokat a szerveren ellenőrizd minden kérésnél – nem csak a gombok elrejtésével. Ellenőrizd azt is, hogy az elérni kívánt rekord a felhasználó fiókjához vagy csapatához tartozik-e. Kezdd néhány rögzített szerepkörrel az adatbázisodban, és teszteld úgy, hogy megpróbálsz közvetlenül más felhasználó adatához hozzáférni.

Hitelesítés vs. engedélyezés

Két szó, amelyet gyakran összekevernek:

• Hitelesítés – ki vagy? – a bejelentkezés. Lásd: bejelentkezés hozzáadása az appodhoz.
• Engedélyezés – mit tehetsz? – hogy egy bejelentkezett felhasználó mely oldalakat, rekordokat és műveleteket érheti el.

Az RBAC az engedélyezés leggyakoribb módja. Fontos: 2026 szeptemberétől a Broken Access Control az első helyen áll az OWASP Top 10:2025 listán, amely a webalkalmazások legsúlyosabb biztonsági kockázatainak széles körben használt összefoglalója. Tipikus hibák: a felhasználók más felhasználók rekordjait olvassák úgy, hogy az URL-ben megváltoztatják az azonosítót, vagy hétköznapi felhasználók hívnak meg adminisztrátori API-útvonalakat.

Válassz modellt

A gyakorlatban a legtöbb app két dolgot kombinál: szerepköröket annak meghatározására, milyen típusú műveleteket végezhet valaki, és tulajdonjogot annak meghatározására, mely rekordokon végezheti azokat. A „szerkesztők szerkeszthetik a bejegyzéseket” szerepkör-szabály; a „…a saját munkaterületük bejegyzéseit” tulajdonjogi szabály. Mindkettőre szükséged van.

Kezdd egyszerűbben, mint gondolnád. Az adminisztrátor, a tag és a megtekintő egy meglepően sok appnál elég. Később könnyebb egy szerepkört szétbontani, mint tíz szerepkört utólag átlátni, amelyeket senki sem ért.

Tervezd meg a szerepköröket a kódolás előtt

Előbb írj egy jogosultsági táblát egyszerű nyelven. Ez egyszerre a specifikáció az MI-nek és a tesztterved:

Döntsd el a szélsőséges eseteket is: kiléphet-e az utolsó tulajdonos? Eltávolíthat-e egy adminisztrátor tulajdonost? Mit lát az eltávolított felhasználó?

Lépésről lépésre

1. Előbb legyen működő bejelentkezés

Az RBAC a hitelesítésre épül. A szervernek megbízhatóan kell tudnia, ki küldi az egyes kéréseket, munkamenetből vagy ellenőrzött tokenből – soha nem a böngésző által a kérés törzsében küldött felhasználói azonosítóból.

2. Tárold a szerepköröket az adatbázisban

Egy csapat nélküli appnál a felhasználók role oszlopa elegendő. Csapatokhoz használj tagsági táblát:

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)
);

Soha ne engedd, hogy a felhasználók a normál profilfrissítésen keresztül állítsák be a saját szerepkörüket. A szerepkörváltásoknak egy erre dedikált, jogosultság-ellenőrzött végponton kell keresztülmenniük.

3. Ellenőrizd a jogosultságokat a szerveren, egy helyen

Írj egy segédfüggvényt – valami ilyesmit: can(user, 'projects.delete', project) – és hívd meg minden API-útvonalon, szerveroldali műveletben és háttérfeladatban, amely adatot olvas vagy módosít. Egyetlen központi függvényt könnyebb átnézni és tesztelni, mint szétszórt ellenőrzéseket a kódban. Alapértelmezetten tiltsd: ha egyetlen szabály sem engedélyez egy műveletet, az megtagadódik.

4. Szűkítsd minden lekérdezést

Minden csapatadatra irányuló lekérdezésnek tartalmaznia kell a csapatot: where organization_id = :currentOrg, nem csak where id = :id. Ez akadályozza meg, hogy valaki a /projects/123 címet /projects/124-re módosítva más cég projektjét lássa. A más csapatok rekordjaira „nem található” választ adj, ne „tiltva” választ, hogy ne árulj el, hogy léteznek.

5. Adatbázis-szintű védelem ott, ahol számít

A Postgres sorszintű biztonság (row-level security, RLS) lehetővé teszi, hogy az adatbázis érvényesítse, mely sorokat láthatja az egyes felhasználók. Elengedhetetlen, ha a böngésző közvetlenül beszél az adatbázissal (ahogy egyes hosztolt háttérrendszereknél), és egyébként is hasznos második réteg az érzékeny táblákhoz.

6. Tükrözd a szerepköröket a felületen

Most rejtsd el vagy tiltsd le azt, amit a felhasználók nem tehetnek meg, hogy az app ne legyen zavaró. Ez csak a használhatóságot szolgálja; a védelmet a szerveroldali ellenőrzések adják.

7. Naplózd az érzékeny műveleteket

Rögzítsd, ki változtatott szerepkört, ki törölt adatot vagy exportált rekordokat, és mikor. Egy auditnapló segít a támogatási kérdéseknél és az incidenseknél.

8. Teszteld úgy, mint egy támadó

Jelentkezz be minden szerepkörrel, és próbáld ki a jogosultsági táblában szereplő összes műveletet. Utána próbáld ki azt is, aminek nem szabad működnie: adminisztrátori API-útvonalak hívása megtekintőként, azonosítók módosítása az URL-ekben és kérésekben, saját magad eltávolítása utolsó tulajdonosként. Az automatikus tesztek a jogosultsági táblához megérik a megírás fáradságát, amint a szabályok stabilak.

Promptok, amelyek működnek

Adj hozzá szerepkör alapú hozzáférés-szabályozást. Szervezetenként szerepkörök: owner, admin, member, viewer, egy memberships táblában tárolva. A jogosultságok ebben a táblázatban vannak: [illeszd be a táblázatodat]. Hozz létre egy központi, szerveroldali can(user, action, resource) segédfüggvényt, alapértelmezetten tiltva, és használd minden API-útvonalon. Minden lekérdezést szűkíts organization_id szerint. A felületen rejtsd el azokat a műveleteket, amelyeket a felhasználó nem végezhet, de a biztonságot sose erre alapozd.

Vizsgáld át ennek az appnak minden API-útvonalát és szerveroldali függvényét. Mindegyikhez sorold fel, milyen adatot olvas vagy módosít, ellenőrzi-e, hogy a felhasználó be van-e jelentkezve, ellenőrzi-e a szerepkörét, és szűkíti-e a lekérdezést a szervezetére. Javítsd azokat, amelyekből hiányzik az ellenőrzés, és mutasd meg a listát.

Adj hozzá egy csak adminisztrátoroknak szóló /admin oldalt, ahol a tulajdonos módosíthatja a tagok szerepköreit. Akadályozd meg az utolsó tulajdonos eltávolítását vagy lefokozását, naplózd minden szerepkörváltoztatást azzal, hogy ki és mikor végezte, és győződj meg róla, hogy a szerepkör-módosító végpont elutasít mindenkit, aki nem tulajdonos.

Gyakori hibák

• Szerepkörök ellenőrzése csak a frontenden. Az API továbbra is nyitva áll bárkinek, aki meghívja.
• A kliensről érkező azonosítókban bízás – userId vagy role a kérés törzsében a munkamenet helyett.
• Szűkítetlen lekérdezések, amelyek csak a rekord azonosítója alapján kérnek le adatot.
• Szerepkörök ellenőrzése oldalakon, de nem az API-útvonalakon, exportoknál, fájlletöltéseknél vagy webhookoknál.
• Adminisztrátor e-mail-cím alapján, a kódba égetve (if email === 'me@...'), amit könnyű elfelejteni, és nehéz megváltoztatni.
• Túl sok szerepkör túl korán, amelyeket hat hónap múlva senki sem tud megmagyarázni.
• Elavult munkamenetek: a lefokozott felhasználó az adminisztrátori jogait addig megtartja, amíg ki nem jelentkezik. Érzékeny műveleteknél ellenőrizd a szerepköröket az adatbázisból, vagy frissítsd őket.

RBAC-ellenőrzőlista

• A jogosultsági táblázat egyszerű nyelven megírva, a szélsőséges esetekkel együtt eldöntve
• A szerver a munkamenetből tudja, ki a felhasználó, soha nem a kéréskből
• A szerepkörök az adatbázisban vannak; a felhasználók nem módosíthatják a saját szerepkörüket
• Egy központi jogosultság-ellenőrzés, alapértelmezetten tiltva, minden útvonalon használva
• Minden lekérdezés a felhasználó szervezetére vagy tulajdonjogára szűkítve
• Sorszintű biztonság ott, ahol a böngésző elérheti az adatbázist
• A felület elrejti, amit a felhasználók nem tehetnek meg (csak a használhatóságért)
• Az érzékeny műveletek naplózva
• Minden szerepkör tesztelve, beleértve a közvetlen API-hívásokat és a módosított azonosítókat

A hozzáférés-szabályozás a hosszabb lista egyik eleme; a biztonsági ellenőrzőlista AI-val épített appokhoz a többit is lefedi. Ha a saját munkatársaid számára készítesz eszközt, a belső eszköz építése útmutató megmutatja, hova illenek a szerepkörök.

RBAC a Mythexen

A Mythex nem biztosít beépített bejelentkezési vagy szerepkörrendszert az app felhasználóinak. Te választasz egy hitelesítő könyvtárat vagy szolgáltatót, és leírod a szerepköröket, az ügynök pedig bekötözi a kódodba és a projekt Postgres-adatbázisába (bejelentkezés hozzáadása az appodhoz). A Mythex saját munkaterületi szerepkörei, például a Tulajdonos és a Tag, a Mythex-projekteid szerkesztését szabályozzák, nem azt, ki használhatja a közzétett appodat. Használd a Terv módot, hogy a jogosultsági táblázatban megegyezz az építés előtt, majd használd a fenti átnézési promptot, és teszteld minden szerepkört az előnézetben, mielőtt közzéteszed. A dokumentáció biztonsági promptjai hasznos további lépések.

Kérdések