Kuidas lisada oma äppi rollipõhine ligipääsukontroll (RBAC)

Rollipõhise ligipääsukontrolli lisamiseks anna igale kasutajale üks või mitu rolli (näiteks administraator, toimetaja, vaataja), määra, milliseid tegevusi iga roll tohib teha, ja kontrolli neid õigusi serveris iga päringu puhul – mitte ainult nuppe peites. Kontrolli ka, et kirje, millele ligi pääsetakse, kuulub kasutaja kontole või meeskonda. Alusta mõne fikseeritud rolliga oma andmebaasis ja testi, proovides jõuda teise kasutaja andmeteni otse.

Autentimine vs autoriseerimine

Kaks sõna, mida sageli segi aetakse:

• Autentimine on kes sa oled? – sisselogimine. Vaata kuidas lisada äppi sisselogimine.
• Autoriseerimine on mida sul on lubatud teha? – millistele lehtedele, kirjetele ja tegevustele sisse logitud kasutaja pääseb.

RBAC on kõige levinum viis autoriseerimiseks. See on tähtis: seisuga september 2026 on Broken Access Control OWASP Top 10:2025 nimekirjas numbrina üks – see on laialdaselt kasutatav loend kõige tõsisematest veebirakenduste turvariskidest. Tüüpilised vead on kasutajad, kes loevad teiste kasutajate kirjeid, muutes URL-is ID-d, või tavakasutajad, kes kutsuvad administraatorile mõeldud API-marsruute.

Vali mudel

Praktikas kombineerib enamik äppe kaht asja: rollid, mis määravad, milliseid tegevusi inimene võib teha, ja omandiõigus, mis määrab, millistel kirjetel ta neid teha võib. „Toimetajad võivad muuta postitusi“ on rolli reegel; „…postitusi oma töötoas“ on omandiõiguse reegel. Vajad mõlemat.

Alusta lihtsamalt, kui arvad. Administraator, liige ja vaataja katavad üllatavalt palju äppe. Rolli on hiljem lihtsam jagada, kui lahti harutada kümme rolli, mida keegi ei mõista.

Kujunda rollid enne koodi kirjutamist

Kirjuta esmalt lihtsas keeles õiguste tabel. See on korraga spetsifikatsioon AI-le ja sinu testplaan:

Otsusta ka erijuhud: kas viimane omanik võib lahkuda? Kas administraator võib omaniku eemaldada? Mida näeb eemaldatud kasutaja?

Samm-sammult

1. Esmalt korrektne sisselogimine

RBAC toetub autentimisele. Server peab usaldusväärselt teadma, kes iga päringu teeb, sessiooni või kontrollitud tokeni põhjal – mitte kunagi kasutaja ID põhjal, mida brauser saadab päringu kehas.

2. Salvesta rollid andmebaasi

Ühe meeskonna äpi puhul sobib kasutajate tabelis role-veerg. Meeskondade puhul kasuta liikmelisuse tabelit:

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

Ära lase kasutajatel kunagi oma rolli ise muuta tavalise profiili uuendamisega. Rollimuudatused käivad läbi eraldi, õigusi kontrollivast lõpp-punktist.

3. Kontrolli õigusi serveris, ühes kohas

Kirjuta üks abifunktsioon – midagi sellist nagu can(user, 'projects.delete', project) – ja kutsu seda igas API-marsruudis, serveri tegevuses ja taustatöös, mis loeb või muudab andmeid. Üks keskne funktsioon on kergem üle vaadata ja testida kui kontrollid koodis laiali. Keela vaikimisi: kui ükski reegel ei luba tegevust, siis see keelatakse.

4. Piira iga päring

Iga meeskonna andmete päring peab sisaldama meeskonda: where organization_id = :currentOrg, mitte ainult where id = :id. See takistab, et keegi muudaks /projects/123 väärtuseks /projects/124 ja näeks teise ettevõtte projekti. Teistes meeskondades olevate kirjete puhul tagasta „ei leitud“, mitte „keelatud“, et mitte paljastada, et need olemas on.

5. Lisa andmebaasi tasemel kaitse, kui see loeb

Postgresi rea tasemel turve (row-level security, RLS) laseb andmebaasil endal jõustada, milliseid ridu iga kasutaja näeb. See on hädavajalik, kui brauser räägib andmebaasiga otse (nagu mõnel hostitud taustateenusel), ja muul juhul kasulik teine kiht tundlikele tabelitele.

6. Kajasta rolle liideses

Nüüd peida või keela see, mida kasutajad teha ei saa, et äpp poleks segadusttekitav. See on ainult kasutatavuse jaoks; kaitsevad serveri kontrollid.

7. Logi tundlikud tegevused

Salvesta, kes muutis rolle, kustutas andmeid või eksportis kirjeid, ja millal. Auditilogi aitab tugiküsimustega ja intsidentidega.

8. Testi nagu ründaja

Logi sisse igas rollis ja proovi iga tegevust õiguste tabelist. Siis proovi asju, mis ei tohiks töötada: kutsu administraatori API-marsruute vaatajana, muuda ID-sid URL-is ja päringutes, eemalda ennast viimase omanikuna. Kui reeglid on paigas, on õiguste tabeli jaoks väärt kirjutada automaattestid.

Juhised, mis töötavad

Lisa rollipõhine ligipääsukontroll. Rollid organisatsiooni kaupa: owner, admin, member, viewer, salvestatud liikmelisuse tabelisse. Õigused on selles tabelis: [kleebi oma tabel]. Loo üks serveripoolne can(user, action, resource) abifunktsioon, keela vaikimisi ja kasuta seda igas API-marsruudis. Piira iga päring organization_id järgi. Peida liideses tegevused, mida kasutaja teha ei saa, aga turvalisuseks ära seda kunagi usalda.

Vaata üle iga selle äpi API-marsruut ja serverifunktsioon. Iga kohta loetle, milliseid andmeid see loeb või muudab, kas see kontrollib, et kasutaja on sisse logitud, kas see kontrollib tema rolli ja kas see piirab päringu tema organisatsiooniga. Paranda puuduvad kontrollid ja näita mulle nimekiri.

Lisa ainult administraatorile mõeldud leht /admin, kus omanik saab muuta liikmete rolle. Takista viimase omaniku eemaldamine või tagasiastmine, logi iga rollimuudatus koos tegija ja ajaga ning veendu, et rollimuudatuse lõpp-punkt lükkab tagasi kõik, kes ei ole omanik.

Levinud vead

• Rollide kontrollimine ainult esilõpus. API on endiselt avatud igaühele, kes seda kutsub.
• Kliendilt pärinevate ID-de usaldamine – userId või role päringu kehas sessiooni asemel.
• Piiramata päringud, mis toovad kirje ID järgi, ilma kontekstita.
• Rollid kontrollitakse lehtedel, aga mitte API-marsruutides, eksportides, failide allalaadimistes või webhook'ides.
• Administraator e-posti aadressi järgi, mis on koodi sisse kirjutatud (if email === 'me@...') – seda on lihtne unustada ja raske muuta.
• Liiga palju rolle liiga vara, mida keegi kuus kuud hiljem ei oska selgitada.
• Aegunud sessioonid: tagasiastmatud kasutaja säilitab administraatoriõigused, kuni ta välja logib. Kontrolli tundlike tegevuste puhul rolle andmebaasist või värskenda neid.

RBAC kontrollnimekiri

• Õiguste tabel on kirjutatud lihtsas keeles, erijuhud on otsustatud
• Server tunneb kasutajat sessiooni järgi, mitte päringu andmete järgi
• Rollid on salvestatud andmebaasi; kasutajad ei saa oma rolli ise muuta
• Üks keskne õiguste kontroll, vaikimisi keelav, kasutatakse igas marsruudis
• Iga päring on piiratud kasutaja organisatsiooni või omandiõigusega
• Rea tasemel turve seal, kus brauser pääseb andmebaasini
• Liides peidab need tegevused, mida kasutajad teha ei saa (ainult kasutatavuseks)
• Tundlikud tegevused on logitud
• Iga roll on testitud, sh otsesed API-päringud ja muudetud ID-d

Ligipääsukontroll on üks punkt pikemas nimekirjas; AI-ga ehitatud äppide turvanimekiri katab ülejäänu. Kui ehitad tööriista oma töötajatele, siis kuidas ehitada sisemist tööriista näitab, kuhu rollid sobivad.

RBAC Mythexis

Mythex ei paku sinu äpi kasutajatele sisseehitatud sisselogimis- ega rollisüsteemi. Valid autentimisteegi või teenuse ja kirjeldad rollid ning agent seob need sinu koodi ja projekti Postgresi andmebaasiga (lisa äppi sisselogimine). Mythexi enda töötsoonirollid, nagu Owner ja Member, määravad, kes saab muuta sinu Mythexi projekte, mitte seda, kes saab avaldatud äppi kasutada. Kasuta enne ehitamist plaanirežiimi (Plan mode), et leppida kokku õiguste tabel, siis kasuta ülaltoodud ülevaatuse prompti ja testi iga rolli eelvaates enne avaldamist. Dokumentatsiooni turvapromptid on hea järelkäik.

Küsimused