Kā pievienot lomās balstītu piekļuves kontroli (RBAC) lietotnei

Lai pievienotu lomās balstītu piekļuves kontroli, katram lietotājam piešķiriet vienu vai vairākas lomas (piemēram, administrators, redaktors, skatītājs), definējiet, kādas darbības katra loma drīkst veikt, un šīs atļaujas pārbaudiet serverī katram pieprasījumam — ne tikai paslēpjot pogas. Pārbaudiet arī to, vai ieraksts, kuram piekļūst, pieder lietotāja kontam vai komandai. Sāciet ar dažām fiksētām lomām savā datubāzē un testējiet, mēģinot tieši piekļūt cita lietotāja datiem.

Autentifikācija pret autorizāciju

Divi vārdi, ko bieži sajauc:

• Autentifikācija ir kas tu esi? — pieteikšanās. Skatiet kā lietotnei pievienot pieteikšanos.
• Autorizācija ir ko tev drīkst darīt? — kurām lapām, ierakstiem un darbībām pieteicies lietotājs var piekļūt.

RBAC ir visbiežāk izmantotais autorizācijas veids. Tas ir svarīgi: no 2026. gada septembra Broken Access Control ir #1 OWASP Top 10:2025, plaši izmantotajā sarakstā ar nopietnākajiem tīmekļa lietotņu drošības riskiem. Tipiskas kļūmes ir lietotāji, kas lasa citu lietotāju ierakstus, mainot ID URL, vai parasti lietotāji, kas izsauc tikai administratoriem paredzētus API maršrutus.

Izvēlieties modeli

Praksē vairums lietotņu apvieno divas lietas: lomas tam, kāda veida darbības cilvēks var veikt, un īpašumtiesības tam, ar kuriem ierakstiem viņš tās var veikt. "Redaktori var rediģēt ziņas" ir lomas noteikums; "…ziņas savā darbtelpā" ir īpašumtiesību noteikums. Vajag abus.

Sāciet vienkāršāk, nekā šķiet vajadzīgs. Administrators, dalībnieks un skatītājs sedz pārsteidzoši daudzas lietotnes. Vieglāk vēlāk sadalīt lomu, nekā atšķetināt desmit lomas, ko neviens nesaprot.

Projektējiet lomas, pirms rakstāt kodu

Vispirms uzrakstiet atļauju tabulu vienkāršā valodā. Tā kalpo kā specifikācija MI un kā jūsu testu plāns:

Izlemiet arī īpašos gadījumus: vai pēdējais īpašnieks var aiziet? Vai administrators var noņemt īpašnieku? Ko redz noņemtais lietotājs?

Soli pa solim

1. Vispirms nodrošiniet darba pieteikšanos

RBAC balstās uz autentifikāciju. Serverim uzticami jāzina, kas veic katru pieprasījumu, no sesijas vai pārbaudīta marķiera — nekad no lietotāja ID, ko pārlūks nosūta pieprasījuma pamattekstā.

2. Glabājiet lomas datubāzē

Vienai komandai lietotnei pietiek ar kolonnu role lietotāju tabulā. Komandām izmantojiet dalības tabulu:

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

Nekad neļaujiet lietotājiem pašiem iestatīt savu lomu parastā profila atjaunināšanā. Lomu maiņa notiek caur atsevišķu, atļauju pārbaudītu galapunktu.

3. Pārbaudiet atļaujas serverī, vienuviet

Uzrakstiet vienu palīgfunkciju — kaut ko līdzīgu can(user, 'projects.delete', project) — un izsauciet to katrā API maršrutā, servera darbībā un fona uzdevumā, kas lasa vai maina datus. Viena centrāla funkcija ir vieglāk pārskatāma un testējama nekā pārbaudes, kas izkaisītas pa kodu. Noraidiet pēc noklusējuma: ja neviens noteikums neatļauj darbību, tā tiek noraidīta.

4. Ierobežojiet katru vaicājumu

Katram vaicājumam komandas datiem jāietver komanda: where organization_id = :currentOrg, nevis tikai where id = :id. Tieši tas neļauj kādam mainīt /projects/123 uz /projects/124 un redzēt cita uzņēmuma projektu. Citu komandu ierakstiem atgrieziet "nav atrasts", nevis "aizliegts", lai neatklātu, ka tie pastāv.

5. Pievienojiet aizsardzību datubāzes līmenī tur, kur tas svarīgi

Postgres rindu līmeņa drošība (RLS) ļauj datubāzei noteikt, kuras rindas katrs lietotājs redz. Tā ir būtiska, ja pārlūks sazinās ar datubāzi tieši (kā dažos mitinātos backend risinājumos), un citādi noderīgs otrais slānis jutīgām tabulām.

6. Atspoguļojiet lomas saskarnē

Tagad paslēpiet vai atspējojiet to, ko lietotāji nevar darīt, lai lietotne nebūtu mulsinoša. Tas ir tikai lietojamībai; aizsargā serveris.

7. Reģistrējiet jutīgās darbības

Ierakstiet, kas mainīja lomas, dzēsa datus vai eksportēja ierakstus un kad. Auditācijas žurnāls palīdz atbildēt uz atbalsta jautājumiem un risināt incidentus.

8. Testējiet kā uzbrucējs

Pieteikieties katrā lomā un izmēģiniet katru darbību atļauju tabulā. Pēc tam izmēģiniet to, kam nevajadzētu strādāt: izsauciet administratoru API maršrutus kā skatītājs, mainiet ID URL un pieprasījumos, noņemiet sevi kā pēdējo īpašnieku. Automatizētus testus atļauju tabulai ir vērts uzrakstīt, kad noteikumi ir nostabilizējušies.

Uzvednes, kas darbojas

Pievieno lomās balstītu piekļuves kontroli. Lomas katrai organizācijai: owner, admin, member, viewer, glabātas tabulā memberships. Atļaujas ir šajā tabulā: [ielīmējiet savu tabulu]. Izveido vienu servera puses palīgfunkciju can(user, action, resource), noraidi pēc noklusējuma, un izmanto to katrā API maršrutā. Ierobežo katru vaicājumu pēc organization_id. Paslēp lietotājam neatļautās darbības saskarnē, bet drošībai nekad uz to nepaļaujies.

Pārskati katru API maršrutu un servera funkciju šajā lietotnē. Katrai uzskaiti, kādus datus tā lasa vai maina, vai pārbauda, ka lietotājs ir pieteicies, vai pārbauda viņa lomu un vai ierobežo vaicājumu pēc viņa organizācijas. Labo visas, kurām trūkst pārbaudes, un parādi man sarakstu.

Pievieno tikai administratoriem paredzētu lapu /admin, kur īpašnieks var mainīt dalībnieku lomas. Neļauj noņemt vai pazemināt pēdējo īpašnieku, ieraksti katru lomas maiņu ar to, kas to veica un kad, un pārliecinies, ka lomas maiņas galapunkts noraida ikvienu, kas nav īpašnieks.

Biežākās kļūdas

• Lomu pārbaude tikai priekšgalā. API joprojām ir atvērts ikvienam, kas to izsauc.
• Uzticēšanās ID no klienta — userId vai role pieprasījuma pamattekstā sesijas vietā.
• Neierobežoti vaicājumi, kas ņem ierakstu tikai pēc ieraksta ID.
• Lomas pārbaudītas lapās, bet ne API maršrutos, eksportos, failu lejupielādēs vai webhooks.
• Administrators pēc e-pasta adreses, kas iekodēta kodā (if email === 'me@...') — to viegli aizmirst un grūti mainīt.
• Pārāk daudz lomu pārāk agri, ko neviens sešus mēnešus vēlāk nevar izskaidrot.
• Novecojušas sesijas: pazemināts lietotājs joprojām var būt administrators, līdz izrakstās. Jutīgās darbībās pārbaudiet lomas datubāzē vai tās atjaunojiet.

RBAC kontrolsaraksts

• Atļauju tabula uzrakstīta vienkāršā valodā, īpašie gadījumi izlemti
• Serveris zina lietotāju no sesijas, nekad no pieprasījuma datiem
• Lomas glabātas datubāzē; lietotāji nevar mainīt savas
• Viena centrāla atļauju pārbaude, noraida pēc noklusējuma, izmantota katrā maršrutā
• Katrs vaicājums ierobežots pēc lietotāja organizācijas vai īpašumtiesībām
• Rindu līmeņa drošība tur, kur pārlūks var piekļūt datubāzei
• Saskarne paslēpj to, ko lietotāji nevar darīt (tikai lietojamībai)
• Jutīgās darbības reģistrētas
• Katra loma pārbaudīta, tostarp tiešie API izsaukumi un mainīti ID

Piekļuves kontrole ir viens punkts garākā sarakstā; drošības kontrolsaraksts MI veidotām lietotnēm aptver pārējo. Ja veidojat rīku savam personālam, kā izveidot iekšēju rīku parāda, kur lomas ietilpst.

RBAC Mythex

Mythex nenodrošina iebūvētu pieteikšanās vai lomu sistēmu jūsu lietotnes lietotājiem. Jūs izvēlaties autentifikācijas bibliotēku vai sniedzēju un aprakstāt lomas, un aģents tās iestrādā jūsu kodā un projekta Postgres datubāzē (pievienot pieteikšanos lietotnei). Mythex pašas darbtelpas lomas, piemēram, Owner un Member, kontrolē, kas var rediģēt jūsu Mythex projektus, nevis to, kas var izmantot publicēto lietotni. Izmantojiet plānošanas režīmu, lai saskaņotu atļauju tabulu pirms veidošanas, pēc tam izmantojiet iepriekš minēto pārskatīšanas uzvedni un pārbaudiet katru lomu priekšskatījumā, pirms publicējat. Dokumentācijas drošības uzvednes ir noderīgs turpinājums.

Jautājumi