Kaip pridėti vaidmenimis pagrįstą prieigos valdymą (RBAC) į savo programėlę

Kad pridėtumėte vaidmenimis pagrįstą prieigos valdymą, kiekvienam vartotojui priskirkite vieną ar kelis vaidmenis (pavyzdžiui administratorius, redaktorius, peržiūrėtojas), nustatykite, kokius veiksmus kiekvienas vaidmuo gali atlikti, ir tuos leidimus tikrinkite serveryje kiekvienai užklausai – ne tik slėpdami mygtukus. Taip pat patikrinkite, ar pasiekiamas įrašas priklauso vartotojo paskyrai ar komandai. Pradėkite nuo keleto fiksuotų vaidmenų savo duomenų bazėje ir testuokite bandydami tiesiogiai pasiekti kito vartotojo duomenis.

Autentifikavimas ir autorizavimas

Du žodžiai, kurie dažnai painiojami:

• Autentifikavimas – tai kas tu esi? – prisijungimas. Žr. kaip pridėti prisijungimą prie programėlės.
• Autorizavimas – tai ką tau leidžiama daryti? – kuriuos puslapius, įrašus ir veiksmus prisijungęs vartotojas gali pasiekti.

RBAC yra dažniausias autorizavimo būdas. Tai svarbu: nuo 2026 m. rugsėjo Broken Access Control užima 1 vietą OWASP Top 10:2025 sąraše – plačiai naudojamame sąraše su rimčiausiomis žiniatinklio programėlių saugumo rizikomis. Tipiški gedimai: vartotojai skaito kitų vartotojų įrašus pakeisdami ID URL, arba paprasti vartotojai kviečia tik administratoriams skirtus API maršrutus.

Pasirinkite modelį

Praktikoje dauguma programėlių sujungia du dalykus: vaidmenis, nusakančius, kokius veiksmus kas nors gali atlikti, ir nuosavybę, nusakančią, kuriuos įrašus jis gali juose atlikti. „Redaktoriai gali redaguoti įrašus“ – tai vaidmens taisyklė; „…įrašus savo darbo erdvėje“ – nuosavybės taisyklė. Reikia abiejų.

Pradėkite paprasčiau nei manote. Administratorius, narys ir peržiūrėtojas apima stebėtinai daug programėlių. Vėliau vaidmenį lengviau suskaidyti, nei išpainioti dešimt vaidmenų, kurių niekas nesupranta.

Suprojektuokite vaidmenis prieš rašant kodą

Pirmiausia užrašykite leidimų lentelę paprasta kalba. Ji tarnauja ir kaip DI specifikacija, ir kaip testavimo planas:

Nuspręskite ir kraštutinius atvejus: ar paskutinis savininkas gali išeiti? Ar administratorius gali pašalinti savininką? Ką mato pašalintas vartotojas?

Žingsnis po žingsnio

1. Pirmiausia veikiantis prisijungimas

Vaidmenų valdymas stovi ant autentifikavimo pamato. Serveris turi patikimai žinoti, kas daro kiekvieną užklausą, iš sesijos ar patikrinto žetono – niekada iš vartotojo ID, kurį naršyklė siunčia užklausos turinyje.

2. Saugokite vaidmenis duomenų bazėje

Vienos komandos programėlei tinka stulpelis role vartotojams. Komandoms naudokite narystės lentelę:

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

Neleiskite vartotojams patiems nustatyti savo vaidmens įprastu profilio atnaujinimu. Vaidmenų pakeitimai turi eiti per atskirą, leidimus tikrinantį galinį tašką.

3. Tikrinkite leidimus serveryje, vienoje vietoje

Parašykite vieną pagalbinę funkciją – kažką panašaus į can(user, 'projects.delete', project) – ir ją kvieskite kiekviename API maršrute, serverio veiksme ir fono užduotyje, kuri skaito ar keičia duomenis. Viena centrinė funkcija lengviau peržiūrima ir testuojama nei tikrinimai, išbarstyti po kodą. Numatytasis atsakymas – uždrausti: jei joks taisyklė neleidžia veiksmo, jis atmetamas.

4. Apribokite kiekvieną užklausą

Kiekviena komandos duomenų užklausa turi apimti komandą: where organization_id = :currentOrg, o ne tik where id = :id. Tai neleidžia kam nors pakeisti /projects/123 į /projects/124 ir pamatyti kitos įmonės projektą. Kitų komandų įrašams grąžinkite „nerasta“, o ne „draudžiama“, kad neatskleistumėte, jog jie egzistuoja.

5. Pridėkite apsaugą duomenų bazės lygiu ten, kur tai svarbu

Postgres eilučių lygio saugumas (RLS) leidžia duomenų bazei užtikrinti, kokias eilutes kiekvienas vartotojas mato. Tai būtina, jei naršyklė bendrauja su duomenų baze tiesiogiai (kaip kai kurie talpinami backend), o kitais atvejais – naudingas antrasis sluoksnis jautrioms lentelėms.

6. Atspindėkite vaidmenis sąsajoje

Dabar paslėpkite arba išjunkite tai, ko vartotojai negali daryti, kad programėlė nebūtų painialynė. Tai tik patogumui; apsaugą užtikrina serverio patikros.

7. Registruokite jautrius veiksmus

Įrašykite, kas keitė vaidmenis, trynė duomenis ar eksportavo įrašus, ir kada. Audito žurnalas padeda atsakyti į pagalbos klausimus ir incidentus.

8. Testuokite kaip užpuolikas

Prisijunkite kaip kiekvienas vaidmuo ir išbandykite kiekvieną veiksmą leidimų lentelėje. Tada išbandykite tai, kas neturėtų veikti: kvieskite administratoriaus API maršrutus kaip peržiūrėtojas, keiskite ID URL ir užklausose, pašalinkite save kaip paskutinį savininką. Automatiniai leidimų lentelės testai verti parašymo, kai taisyklės nusistovi.

Veikiantys raginimai

Pridėk vaidmenimis pagrįstą prieigos valdymą. Vaidmenys pagal organizaciją: savininkas, administratorius, narys, peržiūrėtojas, saugomi narystės lentelėje. Leidimai yra šioje lentelėje: [įklijuok savo lentelę]. Sukurk vieną serverio pusės funkciją can(user, action, resource), numatytai drausk ir naudok ją kiekviename API maršrute. Kiekvieną užklausą riboki pagal organization_id. Sąsajoje slėpk veiksmus, kurių vartotojas negali atlikti, bet saugumui niekada į tai nesiremk.

Peržiūrėk kiekvieną šios programėlės API maršrutą ir serverio funkciją. Kiekvienam nurodyk, kokius duomenis jis skaito ar keičia, ar tikrina, ar vartotojas prisijungęs, ar tikrina jo vaidmenį ir ar riboja užklausą jo organizacija. Ištaisyk visus trūkstamus patikrinimus ir parodyk man sąrašą.

Pridėk tik administratoriui skirtą puslapį /admin, kuriame savininkas gali keisti narių vaidmenis. Neleisk pašalinti ar pažeminti paskutinio savininko, įrašyk kiekvieną vaidmens pakeitimą su tuo, kas ir kada jį padarė, ir užtikrink, kad vaidmens keitimo galinis taškas atmestų visus, kurie nėra savininkai.

Dažniausios klaidos

• Vaidmenų tikrinimas tik priekinėje dalyje. API vis tiek atviras bet kam, kas jį kviečia.
• Pasitikėjimas ID iš kliento – userId ar role užklausos turinyje vietoj sesijos.
• Neribotos užklausos, kurios ima įrašą tik pagal ID.
• Vaidmenys tikrinami puslapiuose, bet ne API maršrutuose, eksportuose, failų atsisiuntimuose ar webhook.
• Administratorius pagal el. pašto adresą, įrašytas kode (if email === 'me@...') – lengva pamiršti ir sunku pakeisti.
• Per daug vaidmenų per anksti, kurių niekas nepaaiškins po šešių mėnesių.
• Pasenusios sesijos: pažemintas vartotojas išlaiko administratoriaus teises, kol neatsijungia. Jautriems veiksmams tikrinkite vaidmenis iš duomenų bazės arba juos atnaujinkite.

RBAC kontrolinis sąrašas

• Leidimų lentelė parašyta paprasta kalba, kraštutiniai atvejai nuspręsti
• Serveris žino vartotoją iš sesijos, niekada iš užklausos duomenų
• Vaidmenys saugomi duomenų bazėje; vartotojai negali keisti savo
• Viena centrinė leidimų patikra, numatytai draudžianti, naudojama kiekviename maršrute
• Kiekviena užklausa apribota vartotojo organizacija ar nuosavybe
• Eilučių lygio saugumas ten, kur naršyklė gali pasiekti duomenų bazę
• Sąsaja slepia tai, ko vartotojai negali daryti (tik patogumui)
• Jautrūs veiksmai registruojami
• Išbandyti visi vaidmenys, įskaitant tiesioginius API kvietimus ir pakeistus ID

Prieigos valdymas yra vienas punktas ilgesniame sąraše; saugumo kontrolinis sąrašas DI kuriamoms programėlėms aprėpia likusius. Jei kuriate įrankį savo darbuotojams, kaip sukurti vidinį įrankį parodo, kur tinka vaidmenys.

RBAC Mythex

Mythex nesuteikia įmontuoto prisijungimo ar vaidmenų sistemos jūsų programėlės vartotojams. Pasirenkate autentifikavimo biblioteką ar teikėją ir aprašote vaidmenis, o agentas įjungia juos į jūsų kodą ir projekto Postgres duomenų bazę (pridėti prisijungimą prie programėlės). Mythex savo darbo erdvės vaidmenys, pavyzdžiui Savininkas ir Narys, kontroliuoja, kas gali redaguoti jūsų Mythex projektus, o ne kas gali naudotis jūsų publikuota programėle. Prieš kurdami naudokite Planavimo režimą, kad sutartumėte leidimų lentelę, tada naudokite aukščiau pateiktą peržiūros raginimą ir prieš publikuodami išbandykite kiekvieną vaidmenį Peržiūroje. Dokumentacijos saugumo raginimai yra naudingas tolesnis žingsnis.

Klausimai