Kako dodati nadzor dostopa na podlagi vlog (RBAC) v svojo aplikacijo

Da dodate nadzor dostopa na podlagi vlog, dajte vsakemu uporabniku eno ali več vlog (na primer skrbnik, urednik, bralec), določite, katera dejanja sme izvajati posamezna vloga, in ta dovoljenja preverite na strežniku pri vsaki zahtevi — ne samo s skrivanjem gumbov. Preverite tudi, ali zapis, do katerega se dostopa, pripada uporabnikovemu računu ali ekipi. Začnite z nekaj fiksnimi vlogami v bazi podatkov in preizkusite tako, da poskusite neposredno doseči podatke drugega uporabnika.

Overitev proti pooblastilu

Dve besedi, ki se pogosto zamenjata:

• Overitev je kdo si? — prijava. Glejte kako dodati prijavo v svojo aplikacijo.
• Pooblastilo je kaj smeš narediti? — katere strani, zapise in dejanja lahko doseže prijavljeni uporabnik.

RBAC je najpogostejši način pooblastila. To je pomembno: od septembra 2026 je Broken Access Control na 1. mestu v OWASP Top 10:2025, široko uporabljenem seznamu najresnejših tveganj za varnost spletnih aplikacij. Tipične napake so, da uporabniki berejo zapise drugih uporabnikov tako, da spremenijo ID v URL-ju, ali da navadni uporabniki kličejo API poti, namenjene samo skrbnikom.

Izberite model

V praksi večina aplikacij združuje dve stvari: vloge za to, kakšna dejanja lahko nekdo opravi, in lastništvo za to, na katerih zapisih jih lahko opravi. „Uredniki lahko urejajo objave“ je pravilo vloge; „…objave v njihovem delovnem prostoru“ je pravilo lastništva. Potrebujete obe.

Začnite preprosteje, kot mislite. Skrbnik, član in bralec pokrijejo presenetljivo število aplikacij. Pozneje je laže razdeliti eno vlogo kot razplesti deset vlog, ki jih nihče ne razume.

Oblikujte vloge, preden pišete kodo

Najprej v preprostem jeziku zapišite tabelo dovoljenj. Služi kot specifikacija za UI in kot načrt testiranja:

Odločite tudi o robnih primerih: ali lahko zadnji lastnik odide? Ali lahko skrbnik odstrani lastnika? Kaj vidi odstranjen uporabnik?

Korak za korakom

1. Najprej imejte delujočo prijavo

RBAC sloni na overitvi. Strežnik mora zanesljivo vedeti, kdo pošilja vsako zahtevo, iz seje ali preverjenega žetona — nikoli iz ID-ja uporabnika, ki ga brskalnik pošlje v telesu zahteve.

2. Shranjujte vloge v bazi podatkov

Za aplikacijo z eno ekipo je stolpec role v tabeli uporabnikov v redu. Za ekipe uporabite tabelo članstev:

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

Nikoli ne dovolite, da uporabniki sami nastavijo svojo vlogo z običajno posodobitvijo profila. Spremembe vlog gredo prek namenske končne točke, ki preverja dovoljenja.

3. Preverjajte dovoljenja na strežniku, na enem mestu

Napišite eno pomožno funkcijo — nekaj takega kot can(user, 'projects.delete', project) — in jo pokličite v vsaki poti API-ja, strežniški akciji in ozadjskem opravilu, ki bere ali spreminja podatke. Ena osrednja funkcija je lažja za pregled in testiranje kot preverjanja, raztresena po kodi. Privzeto zavrnite: če nobeno pravilo ne dovoli dejanja, je zavrnjeno.

4. Omejite vsako poizvedbo

Vsaka poizvedba za podatke ekipe mora vključevati ekipo: where organization_id = :currentOrg, ne samo where id = :id. Tako preprečite, da bi nekdo spremenil /projects/123 v /projects/124 in videl projekt druge družbe. Za zapise v drugih ekipah vrnite „ni najdeno“ namesto „prepovedano“, da ne razkrijete, da obstajajo.

5. Dodajte zaščito na ravni baze tam, kjer šteje

Postgres varnost na ravni vrstic (RLS) omogoča, da baza sama uveljavi, katere vrstice lahko vidi posamezen uporabnik. Bistvena je, če brskalnik neposredno komunicira z bazo (kot pri nekaterih gostovanih zaledjih), sicer pa je koristna druga plast za občutljive tabele.

6. Odražajte vloge v vmesniku

Zdaj skrijte ali onemogočite to, česar uporabniki ne smejo narediti, da aplikacija ni zmedena. To je samo za uporabnost; zaščito zagotavljajo preverjanja na strežniku.

7. Beležite občutljiva dejanja

Zapišite, kdo je spremenil vloge, izbrisal podatke ali izvozil zapise, in kdaj. Dnevnik revizije pomaga pri vprašanjih podpore in incidentih.

8. Preizkusite kot napadalec

Prijavite se kot vsaka vloga in poskusite vsako dejanje iz tabele dovoljenj. Nato poskusite stvari, ki ne bi smele delovati: kličite skrbniške poti API-ja kot bralec, spreminjajte ID-je v URL-jih in zahtevah, odstranite sebe kot zadnjega lastnika. Avtomatizirani testi za tabelo dovoljenj so vredni pisanja, ko se pravila ustalijo.

Pozivi, ki delujejo

Dodaj nadzor dostopa na podlagi vlog. Vloge na organizacijo: lastnik, skrbnik, član, bralec, shranjene v tabeli memberships. Dovoljenja so v tej tabeli: [prilepi svojo tabelo]. Ustvari eno strežniško pomožno funkcijo can(user, action, resource), privzeto zavrni in jo uporabi v vsaki poti API-ja. Vsako poizvedbo omeji z organization_id. V vmesniku skrij dejanja, ki jih uporabnik ne sme izvesti, vendar se za varnost nikoli ne zanašaj samo na to.

Pregledaj vsako pot API-ja in vsako strežniško funkcijo v tej aplikaciji. Za vsako navedi, katere podatke bere ali spreminja, ali preveri, da je uporabnik prijavljen, ali preveri njegovo vlogo in ali poizvedbo omeji na njegovo organizacijo. Popravi tiste, kjer manjka preverjanje, in mi pokaži seznam.

Dodaj stran /admin, dostopno samo skrbnikom, kjer lahko lastnik spreminja vloge članov. Prepreči odstranitev ali znižanje zadnjega lastnika, vsako spremembo vloge zabeleži s tem, kdo jo je naredil in kdaj, ter poskrbi, da končna točka za spremembo vlog zavrne vsakogar, ki ni lastnik.

Pogoste napake

• Preverjanje vlog samo v sprednjem delu. API je še vedno odprt za vsakogar, ki ga pokliče.
• Zaupanje ID-jem iz odjemalca — userId ali role v telesu zahteve namesto v seji.
• Neomejene poizvedbe, ki pridobijo podatke samo po ID-ju zapisa.
• Vloge preverjene na straneh, ne pa na poteh API-ja, izvozih, prenosih datotek ali webhookih.
• Skrbnik po e-poštnem naslovu, trdo zapisan v kodi (if email === 'me@...'), kar je lahko pozabljeno in težko spremenljivo.
• Preveč vlog prezgodaj, ki jih po šestih mesecih nihče ne zna razložiti.
• Zastarele seje: znižan uporabnik obdrži skrbniške pravice, dokler se ne odjavi. Pri občutljivih dejanjih preverite vloge iz baze ali jih osvežite.

Kontrolni seznam RBAC

• Tabela dovoljenj zapisana v preprostem jeziku, robni primeri določeni
• Strežnik pozna uporabnika iz seje, nikoli iz podatkov zahteve
• Vloge shranjene v bazi podatkov; uporabniki jih ne morejo spreminjati sami
• Ena osrednja preverba dovoljenj, privzeto zavrnjena, uporabljena v vsaki poti
• Vsaka poizvedba omejena na organizacijo ali lastništvo uporabnika
• Varnost na ravni vrstic tam, kjer brskalnik lahko doseže bazo
• Vmesnik skriva, kar uporabniki ne smejo (samo za uporabnost)
• Občutljiva dejanja zabeležena
• Vsaka vloga preizkušena, vključno z neposrednimi klici API-ja in spremenjenimi ID-ji

Nadzor dostopa je ena postavka na daljšem seznamu; kontrolni seznam varnosti za aplikacije, zgrajene z UI, pokriva ostalo. Če gradite orodje za lastne sodelavce, kako zgraditi notranje orodje pokaže, kje pridejo vloge v poštev.

RBAC na Mythexu

Mythex ne ponuja vgrajenega sistema prijave ali vlog za uporabnike vaše aplikacije. Izberete knjižnico ali ponudnika za overitev in opišete vloge, agent pa jih poveže z vašo kodo in Postgres bazo projekta (dodajanje prijave v aplikacijo). Vloge Mythexovega delovnega prostora, kot sta Lastnik in Član, nadzorujejo, kdo lahko ureja vaše projekte na Mythexu, ne pa, kdo lahko uporablja objavljeno aplikacijo. Pred gradnjo z načinom načrtovanja uskladite tabelo dovoljenj, nato uporabite zgornji poziv za pregled in pred objavo preizkusite vsako vlogo v predogledu. Uporaben nadaljnji korak so varnostni pozivi v dokumentaciji.

Vprašanja