Kuinka lisätä roolipohjainen käyttöoikeuksien hallinta (RBAC) sovellukseesi

Kun haluat lisätä roolipohjaisen käyttöoikeuksien hallinnan, anna jokaiselle käyttäjälle yksi tai useampi rooli (esimerkiksi ylläpitäjä, muokkaaja, katselija), määritä mitä toimintoja kukin rooli saa tehdä ja tarkista nämä oikeudet palvelimella jokaisessa pyynnössä — älä vain piilottamalla painikkeita. Tarkista myös, että käsiteltävä tietue kuuluu käyttäjän tiliin tai tiimiin. Aloita muutamalla kiinteällä roolilla tietokannassasi ja testaa yrittämällä päästä suoraan toisen käyttäjän tietoihin.

Todennus vs. valtuutus

Kaksi sanaa, joita sekoitetaan usein:

• Todennus on kuka sinä olet? — kirjautuminen. Katso kuinka lisätä kirjautuminen sovellukseesi.
• Valtuutus on mitä saat tehdä? — mitkä sivut, tietueet ja toiminnot kirjautunut käyttäjä voi avata.

RBAC on yleisin tapa toteuttaa valtuutus. Sillä on merkitystä: syyskuusta 2026 alkaen Broken Access Control on OWASP Top 10:2025:n (laajasti käytetty lista vakavimmista verkkosovellusten turvallisuusriskeistä) ykkösenä. Tyypillisiä virheitä ovat käyttäjät, jotka lukevat toisten tietueita muuttamalla URL-osoitteen tunnusta, tai tavalliset käyttäjät, jotka kutsuvat vain ylläpitäjille tarkoitettuja API-reittejä.

Valitse malli

Käytännössä useimmat sovellukset yhdistävät kaksi asiaa: roolit sen mukaan, minkälaisia toimia joku voi tehdä, ja omistajuuden sen mukaan, mihin tietueisiin hän voi niitä kohdistaa. "Muokkaajat voivat muokata kirjoituksia" on roolisääntö; "…kirjoituksia omassa työtilassaan" on omistajuussääntö. Tarvitset molempia.

Aloita yksinkertaisemmin kuin luulet. Ylläpitäjä, jäsen ja katselija riittävät yllättävän moneen sovellukseen. On helpompi jakaa rooli myöhemmin kuin purkaa kymmenen roolin sekava kokonaisuus, jota kukaan ei ymmärrä.

Suunnittele roolit ennen koodaamista

Kirjoita oikeustaulukko ensin selkokielellä. Se toimii samalla tekoälyn speksinä ja testisuunnitelmanasi:

Päätä myös reunatapaukset: voiko viimeinen omistaja poistua? Voiko ylläpitäjä poistaa omistajan? Mitä poistettu käyttäjä näkee?

Vaihe vaiheelta

1. Varmista, että kirjautuminen toimii

RBAC istuu todennuksen päällä. Palvelimen täytyy tietää luotettavasti, kuka pyynnön tekee, istunnosta tai vahvistetusta tunnuksesta — ei koskaan käyttäjätunnuksesta, jonka selain lähettää pyyntöön.

2. Tallenna roolit tietokantaan

Yhden tiimin sovelluksessa role-sarake käyttäjissä riittää. Tiimeille käytä jäsentaulua:

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

Älä koskaan anna käyttäjien asettaa omaa rooliaan tavallisen profiilin päivityksen kautta. Roolimuutokset kulkevat erilliseen, oikeudet tarkistavaan päätepisteeseen.

3. Tarkista oikeudet palvelimella yhdessä paikassa

Kirjoita yksi apufunktio — esimerkiksi can(user, 'projects.delete', project) — ja kutsu sitä jokaisessa API-reitissä, palvelinfunktiossa ja taustatehtävässä, joka lukee tai muuttaa tietoja. Yksi keskitetty funktio on helpompi tarkastaa ja testata kuin tarkistukset hajallaan koodissa. Kiellä oletuksena: jos mikään sääntö ei salli toimintoa, se evätään.

4. Rajaa jokainen kysely

Jokaisen tiimidatan kyselyn pitää sisältää tiimi: where organization_id = :currentOrg, ei pelkkä where id = :id. Tämä estää ihmistä vaihtamasta /projects/123 muotoon /projects/124 ja näkemästä toisen yrityksen projektia. Vastaa "ei löydy" eikä "kielletty" muiden tiimien tietueille, jotta et paljasta niiden olemassaoloa.

5. Lisää suojaus tietokantatasolle, missä se merkitsee

Postgresin rivitason suojaus (row-level security, RLS) antaa tietokannan valvoa, mitä rivejä kukin käyttäjä näkee. Se on välttämätön, jos selain puhuu suoraan tietokannan kanssa (kuten joissakin hostatuissa taustajärjestelmissä), ja hyödyllinen toinen kerros arkaluonteisille tauluille muuten.

6. Näytä roolit käyttöliittymässä

Nyt piilota tai poista käytöstä ne toiminnot, joita käyttäjä ei voi tehdä, jotta sovellus ei hämmennä. Tämä on vain käytettävyyden vuoksi; palvelimen tarkistukset suojaavat.

7. Kirjaa arkaluonteiset toimet

Kirjaa, kuka muutti rooleja, poisti tietoja tai vei tietueita, ja milloin. Tapahtumaloki auttaa tukikysymyksissä ja häiriötilanteissa.

8. Testaa kuin hyökkääjä

Kirjaudu sisään jokaisella roolilla ja kokeile jokaista toimintoa oikeustaulukossa. Kokeile sitten asioita, joiden ei pitäisi onnistua: kutsu ylläpitäjän API-reittejä katselijana, vaihda tunnuksia URL-osoitteissa ja pyynnöissä, poista itsesi viimeisenä omistajana. Oikeustaulukon automaattiset testit kannattaa kirjoittaa, kun säännöt ovat vakiintuneet.

Kehotteet, jotka toimivat

Lisää roolipohjainen käyttöoikeuksien hallinta. Roolit organisaatiokohtaisesti: omistaja, ylläpitäjä, jäsen, katselija, tallennettuna jäsentauluun. Oikeudet ovat tässä taulukossa: [liitä taulukkosi]. Luo yksi palvelinpuolen can(user, action, resource) -apufunktio, joka kieltää oletuksena, ja käytä sitä jokaisessa API-reitissä. Rajaa jokainen kysely organization_id:llä. Piilota käyttöliittymässä toiminnot, joita käyttäjä ei voi tehdä, mutta älä koskaan luota siihen turvallisuuden vuoksi.

Käy läpi jokainen API-reitti ja palvelinfunktio tässä sovelluksessa. Listaa kullekin, mitä dataa se lukee tai muuttaa, tarkistaako se, että käyttäjä on kirjautunut, tarkistaako se roolin ja rajaako se kyselyn hänen organisaatioonsa. Korjaa puuttuvat tarkistukset ja näytä minulle lista.

Lisää vain ylläpitäjälle tarkoitettu /admin-sivu, jolla omistaja voi vaihtaa jäsenten roolit. Estä viimeisen omistajan poistaminen tai alentaminen, kirjaa jokainen roolimuutos siihen kuka teki sen ja milloin, ja varmista, että roolimuutospäätepiste hylkää kaikki muut paitsi omistajat.

Yleisimmät virheet

• Roolien tarkistaminen vain käyttöliittymässä. API on yhä avoin kenelle tahansa, joka sen kutsuu.
• Tunnusten luottaminen asiakkaan lähettämiin tietoihin — userId tai role pyynnön rungossa istunnon sijaan.
• Rajaamattomat kyselyt, jotka hakevat pelkällä tietueen tunnuksella.
• Roolit tarkistetaan sivuilla mutta ei API-reiteissä, vienneissä, tiedostolatauksissa tai webhookeissa.
• Ylläpitäjyys sähköpostiosoitteen perusteella kovakoodattuna koodiin (if email === 'me@...'), mikä on helppo unohtaa ja vaikea muuttaa.
• Liian monta roolia liian aikaisin, joita kukaan ei osaa selittää kuuden kuukauden päästä.
• Vanhentuneet istunnot: alennettu käyttäjä säilyttää ylläpitäjän oikeudet, kunnes kirjautuu ulos. Tarkista roolit tietokannasta tai päivitä ne arkaluonteisissa toimissa.

RBAC-tarkistuslista

• Oikeustaulukko kirjoitettu selkokielellä, reunatapaukset päätetty
• Palvelin tunnistaa käyttäjän istunnosta, ei pyynnön tiedoista
• Roolit tallennettu tietokantaan; käyttäjät eivät voi muuttaa omiaan
• Yksi keskitetty oikeustarkistus, kieltää oletuksena, käytössä jokaisessa reitissä
• Jokainen kysely rajattu käyttäjän organisaatioon tai omistajuuteen
• Rivitason suojaus siellä, missä selain yltää tietokantaan
• Käyttöliittymä piilottaa, mitä käyttäjät eivät voi tehdä (vain käytettävyyden vuoksi)
• Arkaluonteiset toimet kirjattu
• Jokainen rooli testattu, mukaan lukien suorat API-kutsut ja vaihdetut tunnukset

Käyttöoikeuksien hallinta on yksi kohta pidemmässä listassa; tekoälyllä rakennettujen sovellusten turvallisuuslista kattaa muun. Jos rakennat työkalua omalle henkilöstöllesi, kuinka rakentaa sisäinen työkalu näyttää, mihin roolit kuuluvat.

RBAC Mythexissä

Mythex ei tarjoa sisäänrakennettua kirjautumis- tai roolijärjestelmää sovelluksesi käyttäjille. Valitset todennuskirjaston tai -palvelun ja kuvaat roolit, ja agentti kytkee ne koodiisi ja projektisi Postgres-tietokantaan (lisää kirjautuminen sovellukseesi). Mythexin omat työtilaroolit, kuten Owner ja Member, hallitsevat sitä, kuka voi muokata Mythex-projektejasi, eivät sitä, kuka voi käyttää julkaisemaasi sovellusta. Käytä Suunnittelutilaa (Plan mode) sopiaksesi oikeustaulukosta ennen rakentamista, käytä yllä olevaa tarkistuskehotetta ja testaa jokainen rooli Previewssa ennen julkaisua. Dokumentaation turvallisuuskehotteet ovat hyödyllinen jatko.

Kysymykset