Hvernig bætir þú aðgangsstýringu byggðri á hlutverkum (RBAC) við appið þitt

Til að bæta við aðgangsstýringu byggðri á hlutverkum skaltu gefa hverjum notanda eitt eða fleiri hlutverk (til dæmis stjórnandi, ritstjóri, lesandi), skilgreina hvaða aðgerðir hvert hlutverk má framkvæma og athuga þessar heimildir á netþjóninum fyrir hverja beiðni, ekki bara með því að fela hnappa. Athugaðu líka að skráin sem verið er að nálgast tilheyri reikningi eða teymi notandans. Byrjaðu með nokkur föst hlutverk í gagnagrunninum þínum og prófaðu með því að reyna að ná í gögn annars notanda beint.

Auðkenning og heimildarveiting

Tvö orð sem eru oft ruglað saman:

• Auðkenning er hver ert þú?, það er innskráning. Sjá hvernig bætir þú innskráningu við appið þitt.
• Heimildarveiting er hvað máttu gera? það er hvaða síður, skrár og aðgerðir innskráður notandi getur náð í.

RBAC er algengasta leiðin til heimildarveitingar. Það skiptir máli: frá og með september 2026 er Broken Access Control í 1. sæti á OWASP Top 10:2025, sem er víða notaður listi yfir alvarlegustu öryggisáhættur vefforrita. Dæmigerðar bilanir eru að notendur lesi skrár annarra með því að breyta auðkenni í slóðinni, eða að venjulegir notendur kalli á API-leiðir sem eru eingöngu fyrir stjórnendur.

Veldu líkan

Í framkvæmd sameina flest öpp tvennt: hlutverk fyrir hvers konar aðgerðir notandinn má framkvæma, og eignarhald fyrir hvaða skrár hann má framkvæma þær á. „Ritstjórar mega breyta færslum“ er hlutverksregla; „…færslum í eigin vinnusvæði“ er eignarhaldsregla. Þú þarft hvort tveggja.

Byrjaðu einfaldara en þú heldur. Stjórnandi, meðlimur og lesandi duga í ótrúlega mörg öpp. Auðveldara er að skipta hlutverki síðar en að greiða úr tíu hlutverkum sem enginn skilur.

Hannaðu hlutverkin áður en þú skrifar kóða

Skrifaðu heimildatöflu á venjulegu máli fyrst. Hún virkar sem forskrift fyrir gervigreindina og sem prófunaráætlun:

Ákveddu jaðartilvikin líka: má síðasti eigandinn hætta? Getur stjórnandi fjarlægt eigandann? Hvað sér notandi sem hefur verið fjarlægður?

Skref fyrir skref

1. Hafðu virka innskráningu fyrst

RBAC liggur ofan á auðkenningu. Netþjónninn verður áreiðanlega að vita hver gerir hverja beiðni, út frá setu eða staðfestu auðkenni, aldrei út frá auðkenni notanda sem vafrinn sendir í beiðnigögnunum.

2. Geymdu hlutverk í gagnagrunninum

Fyrir app sem þjónar einu teymi er role-dálkur á notendum nóg. Fyrir teymi notarðu aðildartöflu:

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

Leyfðu notendum aldrei að stilla eigið hlutverk með venjulegri prófílbreytingu. Hlutverksbreytingar fara í gegnum sérstakan endapunkt sem athugar heimildir.

3. Athugaðu heimildir á netþjóninum, á einum stað

Skrifaðu eitt hjálparfall, eitthvað eins og can(user, 'projects.delete', project), og kallaðu á það í hverri API-leið, þjónustuaðgerð og bakgrunnsverki sem les eða breytir gögnum. Eitt miðlægt fall er auðveldara að yfirfara og prófa en athuganir dreifðar um kóðann. Hafnaðu sjálfgefið: ef engin regla leyfir aðgerð er henni hafnað.

4. Afmarkaðu hverja fyrirspurn

Hver fyrirspurn um gögn teymisins ætti að innihalda teymið: where organization_id = :currentOrg, ekki bara where id = :id. Þetta kemur í veg fyrir að einhver breyti /projects/123 í /projects/124 og sjái verkefni annars fyrirtækis. Skilaðu „fannst ekki“ frekar en „bannað“ fyrir skrár í öðrum teymum, svo þú opinberir ekki að þær séu til.

5. Bættu vernd í gagnagrunninum þar sem hún skiptir máli

Öryggi á línustigi í Postgres (RLS) gerir gagnagrunninum kleift að framfylgja því hvaða línur hver notandi sér. Það er nauðsynlegt ef vafrinn talar beint við gagnagrunninn (eins og með suma hýsta bakenda), og gagnlegt annað lag fyrir viðkvæmar töflur annars.

6. Endurspeglaðu hlutverk í viðmótinu

Feldu nú eða gerðu óvirkt það sem notendur mega ekki gera, svo appið verði ekki ruglingslegt. Þetta er aðeins til notagildis; athuganirnar á netþjóninum eru það sem verndar.

7. Skráðu viðkvæmar aðgerðir

Skráðu hver breytti hlutverkum, eyddi gögnum eða flutti út skrár, og hvenær. Atburðaskrá hjálpar við fyrirspurnir frá stuðningi og atvik.

8. Prófaðu eins og árásarmaður

Skráðu þig inn sem hvert hlutverk og reyndu hverja aðgerð í heimildatöflunni. Prófaðu síðan það sem ætti ekki að virka: kallaðu á API-leiðir stjórnenda sem lesandi, breyttu auðkennum í slóðum og beiðnum, fjarlægðu sjálfan þig sem síðasta eiganda. Sjálfvirk próf fyrir heimildatöfluna eru þess virði þegar reglurnar hafa fest sig í sessi.

Fyrirmæli sem virka

Bættu við aðgangsstýringu byggðri á hlutverkum. Hlutverk fyrir hverja stofnun: owner, admin, member, viewer, geymd í aðildartöflu. Heimildirnar eru í þessari töflu: [límdu töfluna þína]. Búðu til eitt þjónustumegin hjálparfall can(user, action, resource), hafnaðu sjálfgefið, og notaðu það í hverri API-leið. Afmarkaðu hverja fyrirspurn með organization_id. Feldu aðgerðir sem notandinn má ekki framkvæma í viðmótinu, en treystu aldrei á það hvað öryggi varðar.

Yfirfarðu hverja API-leið og þjónustufall í þessu appi. Fyrir hverja skráðu hvaða gögn hún les eða breytir, hvort hún athugar að notandinn sé innskráður, hvort hún athugar hlutverk hans og hvort hún afmarkar fyrirspurnina við stofnun hans. Lagaðu allar sem vantar athugun og sýndu mér listann.

Bættu við stjórnendasíðu (/admin) sem aðeins eigandinn getur notað til að breyta hlutverkum meðlima. Komdu í veg fyrir að fjarlægja eða lækka síðasta eigandann, skráðu hverja hlutverksbreytingu með því hver gerði hana og hvenær, og gakktu úr skugga um að endapunkturinn fyrir hlutverksbreytingar hafni öllum sem eru ekki eigendur.

Algeng mistök

• Athuga hlutverk aðeins í framendanum. API-ið er samt opið hverjum sem kallar á það.
• Treysta auðkennum frá viðskiptavininum, til dæmis userId eða role í beiðnigögnunum í stað setunnar.
• Ófyrirspurnir sem eru ekki afmarkaðar, sem sækja eftir eingöngu auðkenni skráar.
• Hlutverk athuguð á síðum en ekki á API-leiðum, útflutningi, skráaniðurhali eða webhook.
• Stjórnandi eftir netfangi sem er harðkóðað í kóðanum (if email === 'me@...'), sem er auðvelt að gleyma og erfitt að breyta.
• Of mörg hlutverk of snemma, sem enginn getur útskýrt sex mánuðum síðar.
• Gamlar setur: lækkaður notandi heldur stjórnandaréttindum þar til hann skráir sig út. Athugaðu hlutverk í gagnagrunninum, eða endurnýjaðu þau, í viðkvæmum aðgerðum.

Gátlisti fyrir RBAC

• Heimildatafla skrifuð á venjulegu máli, jaðartilvik ákveðin
• Netþjónninn þekkir notandann út frá setunni, aldrei út frá gögnum beiðninnar
• Hlutverk geymd í gagnagrunninum; notendur geta ekki breytt eigin hlutverkum
• Ein miðlæg heimildaathugun, hafnar sjálfgefið, notuð í hverri leið
• Hver fyrirspurn afmörkuð við stofnun eða eignarhald notandans
• Öryggi á línustigi þar sem vafrinn nær í gagnagrunninn
• Viðmótið felur það sem notendur mega ekki gera (aðeins til notagildis)
• Viðkvæmar aðgerðir skráðar
• Sérhvert hlutverk prófað, þar á meðal beint API-kall og breytt auðkenni

Aðgangsstýring er einn liður á lengri lista; öryggisgátlistinn fyrir öpp smíðuð með gervigreind nær yfir hitt. Ef þú ert að smíða verkfæri fyrir eigið starfsfólk sýnir hvernig býrð þú til innra verkfæri hvar hlutverk eiga heima.

RBAC í Mythex

Mythex býður ekki upp á innbyggða innskráningu eða hlutverkakerfi fyrir notendur appsins þíns. Þú velur auðkenningarsafn eða veitu og lýsir hlutverkunum, og aðstoðarmaðurinn tengir þau við kóðann þinn og Postgres-gagnagrunn verkefnisins (bættu innskráningu við appið þitt). Hlutverk Mythex sjálfs, eins og Eigandi og Meðlimur, stjórna hverjir mega breyta Mythex-verkefnum þínum, ekki hverjir mega nota appið sem þú birtir. Notaðu áætlunarham til að samþykkja heimildatöfluna áður en smíðað er, notaðu síðan yfirferðarfyrirmælin hér að ofan og prófaðu hvert hlutverk í Preview áður en þú birtir. Öryggisfyrirmæli í skjölunum eru gagnlegt framhald.

Spurningar