Securitate la nivel de rând — AiHummer Documentație

AiHummer este multitentant, iar cea mai puternică limită de izolare se află în baza de date însăși: Securitate la nivel de rând PostgreSQL (RLS). Cu RLS activat, baza de date — nu doar codul aplicației — impune ca o interogare să vadă doar rândurile care aparțin chiriașului curent.

Nivel: Securitatea la nivel de rând este restricționată de versiunea plătită Întreprindere nivel — nu face parte din platforma gratuită/Comunitate.

De ce RLS

Filtrare la nivel de aplicație (WHERE tenant_id = ...) este necesar, dar fragil: o singură clauză uitată poate scurge date între chiriași. RLS mută garanția în PostgreSQL, astfel încât chiar și o interogare nefiltrată să returneze doar rândurile chiriașului curent. Este un strat de apărare în profunzime sub propria delimitare a aplicației. Pentru modelul mai larg de multitenanță – și modul în care acesta se combină cu efectele secundare idempotente – vezi Multichiria & idempotență.

Rolul restricționat (participare opțională)

RLS este a opta și este activat prin acordarea gateway-ului unei a doua conexiuni la baza de date care folosește un rol restricționat în locul proprietarului:

# /home/.aihummer/etc/gateway.env
# Owner pool — runs migrations, used for system/bypass operations
AIHUMMER_DATABASE_URL=postgres://owner:...@localhost/aihummer

# Restricted application pool — RLS policies apply (aihummer_app role)
AIHUMMER_DB_APP_URL=postgres://aihummer_app:...@localhost/aihummer

aihummer_app rol este nu proprietarul tabelului, astfel încât PostgreSQL aplică politici RLS asupra acestuia. Interogările aplicației trec prin acest pool restricționat. Activarea RLS este o chestiune de configurare AIHUMMER_DB_APP_URL — și instalările locale/standard (pe gazdă) configurează automat acea variabilă, deci RLS este activ din fabrică. Este „opțional” doar în sensul că o implementare personalizată sau manuală trebuie să seteze AIHUMMER_DB_APP_URL în sine.

[!NOTE] Fără AIHUMMER_DB_APP_URL, gateway-ul folosește pool-ul proprietarului pentru tot și RLS nu este aplicat efectiv. Setează grupul restricționat (care installer-ul standard face pentru tine) pentru a activa izolarea la nivel de bază de date.

[!IMPORTANT] RLS nu depinde de plan. Funcționează identic pe toate planurile, inclusiv Community. Dacă ecranul licenței arată „Securitate la nivel de rând” ca indisponibilă, este o imprecizie a acelui ecran, nu starea bazei dumneavoastră.

Unde RLS este deja activ și unde trebuie pornit

Cum ați instalat	Starea RLS după instalare
Instalare standard, instalatorul ridică PostgreSQL	Activ. Rolul restrâns și `AIHUMMER_DB_APP_URL` se creează automat
PostgreSQL propriu sau administrat (adresa bazei dată dinainte)	Inactiv. Rolul și `AIHUMMER_DB_APP_URL` le creează operatorul
Instalare fără drepturi de administrator (rootless)	Inactiv. La fel

[!WARNING] Două greșeli după care RLS este „pornit”, dar nu protejează nimic. Prima: AIHUMMER_DB_APP_URL indică proprietarul tabelelor sau un superutilizator — PostgreSQL scutește astfel de roluri de politici, iar gateway-ul va raporta totuși RLS ca activ. Folosiți un rol restrâns separat. A doua: pe PostgreSQL propriu rolul restrâns poate fi creat automat cu o parolă previzibilă — dați-i o parolă proprie înainte ca baza să fie accesibilă din rețea.

Definirea domeniului per chiriaș

În cadrul unei cereri, aplicația stabilește chiriașul curent pe conexiune înainte de a rula interogări limitate la chiriaș — conceptual db.WithTenant. Odată stabilite, politicile RLS pentru rolul restricționat limitează fiecare citire și scriere la rândurile acelui chiriaș. Domeniul este legat de unitatea de lucru, astfel încât nu se transmite între cererile concurente.

request ─▶ resolve tenant ─▶ db.WithTenant(tenant) ─▶ queries see only that tenant

Sistem / modul de ocolire pentru lucrători

O parte din muncă este în mod legitim cross-tenant sau independentă de tenant — lucrători de fundal, programatori, recuperarea livrărilor și întreținere similară. Pentru acestea, gateway-ul folosește un mod sistem (ocolire) care rulează pe pool-ul proprietarului, în afara politicilor RLS per-chiriaș, astfel încât sarcinile de infrastructură să poată opera peste întregul set de date.

[!WARNING] Modul de ocolire este doar pentru lucrătorii interni de încredere. Căile de cod pentru gestionarea cererilor acele acțiuni efectuate în numele unui utilizator trebuie să treacă întotdeauna prin restricționat, pool cu domeniu de locatar — niciodată calea de ocolire.

Migrațiile rulează pe pool-ul proprietarului

Modificările schemei necesită privilegii pe care rolul restricționat nu le are, așa că migrațiile rulează întotdeauna pe pool-ul proprietarului (AIHUMMER_DATABASE_URL), sub un blocaj consultativ, la pornire. Restricționat aihummer_app rolul este folosit numai pentru traficul obișnuit al aplicației. Aceasta menține separarea privilegiilor curată: operațiunile care schimbă schema folosesc proprietarul; accesul la datele chiriașului folosește rolul restricționat cu RLS aplicat.

Unde următor?

Multichiria & idempotență — modelul complet al chiriașului și cum efectele secundare rămân sigure în timpul recuperării.
Seiful secretelor — DEK-urile per-chiriaș consolidează același lucru izolare la stratul de secrete.
RBAC și chei API cu domeniu limitat — autorizare mai sus de strat de date.