Egy multi-tenant ERP-rendszerben a jogosultsagok rosszul tervezett rendszere kepes egy ugyfel bizalmat 5 perc alatt elveszteni. A Netorigo Admin RBAC-modulja (Role-Based Access Control) ket evnyi vasarlo-feedback alapjan epult fel. Az alabbiakban a strukturat es a kompromisszumokat irjuk le.
14 alapertelmezett szerep
A platform 14 szerepet hoz minden uj tenanthez:
- super_admin - csak Netorigo-belso fejlesztoknek (lasd lent).
- tenant_admin - a tenant tulajdonosa, mindent lat es mindent valtoztathat a tenanten belul.
- catalog_manager - csak a katalogus modul (termekek, kategoriak, arak).
- order_manager - rendelesek lifecycle-je, refundok, visszakuldesek.
- finance_admin - szamlazas, befizetesek, fokonyvek (a Finance app fele tovabbitva).
- finance_viewer - csak read.
- logistics_admin - raktarkezelés, szállítók (Logistics app).
- logistics_picker - mobil-elsodlegesen, csak rendeles-pick + scan.
- support_agent - ugyfel-tickets, rendelesek read + komment.
- content_editor - blog, oldalak, CMS.
- marketing_manager - kampanyok, promociok, email-templatek.
- analytics_viewer - dashboardok, jelenteseket.
- integration_developer - API kulcsok, webhookok, technikai integraciok.
- custom_role - sablon, a tenant_admin altal masolhato es szabadon szerkesztheto.
A jogosultsag-kulcsok
Minden jogosultsag egy <modul>.<resource>.<action> tripletettel azonositott. Peldak:
catalog.product.readcatalog.product.writecatalog.product.deletefinance.invoice.viewfinance.invoice.createlogistics.shipment.scantenant.user.invite
Osszesen 184 kulcs van jelenleg. A backendben minden controller-method egy @RequiresPermission('catalog.product.write') decoratorrel van jelolve, es a NestJS guard ellenorzi a kerest a sessionen levo szerep-kulcsokhoz.
A matrix UI
A /admin/roles/[roleId] oldalon egy nagy tablazat: sorok = szerepek (a 14 alapertelmezett + a custom-okat), oszlopok = modulok (catalog, finance, logistics, stb.). Egy cella megnyitasa egy modal-t hoz fel, ahol a modulhoz tartozo resource-ok es az allow/deny/inherit allapotokat lehet beallitani:
- allow - explicit engedely (zold pipa)
- deny - explicit tiltas (piros X), feluljarja az allow-ot, ha a szerep tobb forrasbol orokol
- inherit - alapertelmezett, az ososztalybol orokol
A tristate-megkozelites az inheritance miatt kell: egy custom_role indulhat egy alapszerep masolatabol (peldaul a catalog_manager-bol), majd az operator explicit deny-vel tilthat le egy egyedi jogosultsagot anelkul, hogy a tobbit valtoztatni kellene.
A super_admin hardcoded marad
A super_admin-t szandekosan nem lehet UI-bol letrehozni vagy modositani. A user-rekord adatbazisban van (user.is_super_admin = true), de a felhasznalokezelo oldal nem mutatja a super_admin szerepet a dropdown-ban, es nem engedi atlepetni a fokovsenyt.
Ezt egyetlen security audit utan ragaszkodott a CTO-nk: ha egy szabalytalan SQL-injection-tel egy tenant_admin a sajat user-rekordjat super_admin-na tudna allitani, az egesz multi-tenant izolaciot elveszitenenk. Igy a super_admin-t csak psql direkt write-tel lehet beallitani, es az audit-log minden ilyen modositast rogzit egy kulon super_admin_grants tablaban, ami csak append.
Delegate-only mod
Neha egy szerepet csak akkor szeretnek aktivalni, ha egy magasabb szerep explicit delegalja egy konkret userre. Peldaul egy finance_viewer szerepkel rendelkezo user lehet, hogy csak a CFO altal megnevezett 3 ugyfel szamlait lathatja, nem mindenkit.
A delegate-only flag a szerep szintjen allithat be: role.delegation_required = true. Ekkor a guard nem a szerep-kulcsait nezi, hanem a user-en levo specifikus delegation-recordot (user_resource_delegation tabla, ahol minden sor egy user_id + resource_type + resource_id triplet, mondjuk customer:12345).
Audit-baratsag: minden valtoztatas audit-eventet ir
Minden RBAC-valtoztatas (szerep-hozzaadas userhez, jogosultsag-beallitas, delegation-grant) egy audit_events rekordot ir egy diff-fel: ki, mit, mikor, mi volt elotte, mi most. Ezt a 4. cikkben (Operator audit log) reszletezzuk.