Netorigo
Belépés
Vissza a Journal-hoz
netorigohu

Cross-tenant superuser jogosultsag — RBAC tervezesi minta

global_role_tier=superuser minta: ket dimenzio, audit log minden tenant-switchnel, RLS vegso vedelem, MFA + auto-expire + 4 oras break-glass.

A multi-tenant SaaS-ban a legkockazatosabb szerep a cross-tenant superuser. Egy ember, aki nyitja a Netorigo Admin-t, es minden tenant adatat lathatja — egy kattintassal valt tenantok kozott. Egy felig megirott guard, egy elfelejtett RLS-policy, es az adatbazisbol kifut egy „Tenant A adatai Tenant B-nek”. Az alabbiakban a globalRoleTier=superuser tervezesi mintajat irjuk le, ahogy a Netorigon megtanultuk megoldani.

A ket dimenzio

A Netorigo user-modell ket fuggetlen dimenziot kombinal:

  1. Tenant-szintu szerep — tenant_user_roles tabla, sorai (user_id, tenant_id, role_id). Egy user lehet egyszerre 5 tenanton, mindegyiken mas szerep.
  2. Globalis tier — a users.global_role_tier enum: member (default), support, superuser.

A member userek csak azokat a tenanteket latjak, ahol explicit szerepuk van. A support userek lathatjak az osszes tenantet, de csak read-only modban. A superuser mindent lathat es modositthat.

A kettos dimenzio azert kell, mert a global_role_tier nem helyettesiti a tenant-szintu szerepeket — `kiegesziti_ azokat. Egy superuser is konkret tenanton dolgozik, csak nem kell rajta tenant-szintu szerepe.

A jelenlevo tenant_id

Minden bejelentkezett user-sessionnek van egy „jelenlevo tenant_id”-ja — a backend RequestContext.tenant_id ertek. A member user esetében ez az URL-bol jon (/admin/[tenantId]/...) es egy guard ellenorzi, hogy a user-nek tenyleg van-e szerepe ezen a tenanten.

A superuser esetében a jelenlevo tenant_id az URL-bol jon, nincs extra ellenorzés. De ket dolgot tudunk hozzaadunk:

  1. A header-bus minden ujabb tenant-belepest auditol. Egy superuser_tenant_switch esemeny iratkozik be (audit log) minden alkalommal, amikor egy superuser belep egy uj tenantra. Mezok: user_id, from_tenant_id, to_tenant_id, at_timestamp, ip_address, user_agent, reason (opcionalis text — UI-bol kitoltheto „Miert lepsz be?”).
  2. A RequestContext.actor_role-ban a superuser_override flag. Egy lekerdezes a Catalog modulban tudja, hogy az aktualis user superuser, akkor is ha a tenant member lenne — es az audit-logban ez megjelenik.

RLS a vegso vedelem

A PostgreSQL Row-Level Security (RLS) policy minden multi-tenant tablaba el van helyezve. A policy a current_setting('netorigo.tenant_id') session-valtozot olvassa. A backend minden HTTP-keres elejen ezt beallitja a connection-poolbol felemelt connection-on. Ha a tenant_id nem stimmel, a SELECT 0 sort ad vissza.

A superuser eseteben specialis: a backend a connection-on egy netorigo.is_superuser=true ertekt is beallit, es a RLS-policy: tenant_id = current_setting('netorigo.tenant_id') OR current_setting('netorigo.is_superuser')::bool = true. Igy a superuser at tud lepni tenantok kozott anelkul, hogy az RLS-t kikapcsolnánk.

Ez a két soros policy mentett meg minket harom audit-bol. Ha valaki elfelejt a backend kodban guard-ot, az RLS akkor is megfogja a leak-et.

A „ne valj sajat incidense” mintazat

A superuser-t mintegy ket kezzel kezelni kell. A mi praktikank:

  1. Total 6 ember van globalisan superuser. Nem 30, nem 100. A CTO + 2 senior backend dev + 2 SRE + a security lead.
  2. Kotelezo MFA. Hardware-key (YubiKey) WebAuthn, nem SMS, nem TOTP.
  3. Auto-expire szerep. Egy superuser-t nem permanently allitunk be — minden manifest-frissites utan 90 nappal lejar. Megerositest kell rendszerszintu emailen kemi tovabbra is fenntartani.
  4. Tenant-switch-emaileket a tenant tulajdonosanak. Ha egy superuser belep a tenant adminjába, a tenant fooperatora kap egy emailt: „Netorigo support tag belepett az admin felületére. Reason: <text>. Ha nem ismered, azonnal lepj a security@netorigo.com-mal.”
  5. Audit-log retention 7 ev. A superuser tenant-switch eventek soha nincsenek torolve.

A „break-glass” mod

Veszhelyzeti scenario: egy nagy ugyfel kritikus hibat jelez vasarnap este, es minden senior superuser nyaralasban. Ekkor egy 7. "break-glass" superuser-t lehet aktivalni egy ket-kulcsos folyamattal: a CTO + a CFO is meghivja a sajat YubiKey-evel a Vault-bol egy ideiglenes credential-t, ami 4 oraig el. Minden actiont audit-logol, es a session zarasakor (vagy 4 ora utan) automatikusan torolt.

Ket ev alatt egyszer hasznaltuk. Mukodott.

Vegszo

A superuser hatalma minden multi-tenant SaaS-ban kritikus. Ket dimenzio (tenant-role + global-tier), audit-log minden tenant-switch-en, RLS mint vegso védőhalo, kotelezo MFA, auto-expire, break-glass mod. Ezt a teljes mintazatot a Netorigo enterprise-szerzodéseknel pontosan ezert szoktak audit-elni — egy senior CISO 30 percben megerti, miert nem leszünk a kovetkezo headline.

Vissza a Journal-hoz