Eilutės lygio saugumas — AiHummer Dokumentai

AiHummer yra daugnuominis, o jo stipriausia izoliacijos riba yra pačioje duomenų bazėje: PostgreSQL eilutės lygio saugumas (RLS). Su įjungtu RLS, duomenų bazė — ne tik programos kodas — užtikrina, kad užklausa matytų tik tas eilutes, kurios priklauso dabartiniam nuomininkui.

Lygis: Eilutės lygio saugumas yra ribojamas mokamu versijos Įmonė lygis — tai nėra nemokamos / Bendruomenės platformos dalis.

Kodėl RLS

Programos lygio filtravimas (WHERE tenant_id = ...) yra būtinas, bet trapus: viena pamiršta nuostata gali praleisti duomenis tarp nuomininkų. RLS perkelia garantiją į PostgreSQL, todėl net nefiltrovanas užklausa grąžina tik dabartinio nuomininko eilutes. Tai gynybos gilumo sluoksnis po pačios programos aprėpties. Didesniam daugiabučio modelio kontekstui — ir kaip jis dera su idempotentiniais šalutiniais poveikiais — žr. Daugiabūtiškumas ir nepakartojamumas.

Apribota rolė (pasirinktinė)

RLS yra prisijungti ir suaktyvinamas suteikiant vartų sistemai antrą duomenų bazės ryšį, kuris naudoja ribotą rolę, o ne savininko:

# /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

Tas aihummer_app vaidmuo yra ne lentelės savininkas, todėl PostgreSQL taiko RLS politiką jai. Programos užklausos eina per šį ribotą baseiną. RLS įjungimas yra klausimas nustatymo AIHUMMER_DB_APP_URL — ir vietinės/standartinės (šeimininko gimtosios) diegimo versijos automatiškai nustato tą kintamąjį, todėl RLS yra aktyvi iš karto. Ji „pasirenkama“ tik tokiu prasme, kad reikia nustatyti pritaikytą arba rankinę diegimo versiją AIHUMMER_DB_APP_URL pats.

[!NOTE] Be AIHUMMER_DB_APP_URL, vartai naudoja savininko baseiną viskam ir RLS yra praktiškai neįgyvendinama. Nustatykite ribotą baseiną (kuris standartinis diegėjas tai daro už jus), kad įjungtumėte duomenų bazės lygio izoliaciją.

[!IMPORTANT] RLS nepriklauso nuo plano. Jis veikia vienodai visuose planuose, įskaitant Community. Jei licencijos lange „Eilutės lygio sauga“ rodoma kaip neprieinama, tai to lango netikslumas, o ne jūsų duomenų bazės būsena.

Kur RLS jau veikia, o kur jį reikia įjungti

Kaip įdiegėte	RLS būsena po įdiegimo
Įprastas įdiegimas, PostgreSQL paruošia diegimo programa	Veikia. Ribota rolė ir `AIHUMMER_DB_APP_URL` sukuriami automatiškai
Savas ar valdomas PostgreSQL (duomenų bazės adresas nurodytas iš anksto)	Neveikia. Rolę ir `AIHUMMER_DB_APP_URL` sukuria operatorius
Įdiegimas be administratoriaus teisių (rootless)	Neveikia. Tas pat

[!WARNING] Dvi klaidos, po kurių RLS „įjungtas“, bet nieko neapsaugo. Pirma: AIHUMMER_DB_APP_URL nurodo lentelių savininką arba supernaudotoją — PostgreSQL tokias roles atleidžia nuo politikų, o šliuzas vis tiek praneš, kad RLS veikia. Naudokite atskirą ribotą rolę. Antra: savame PostgreSQL ribota rolė gali būti sukurta automatiškai su nuspėjamu slaptažodžiu — suteikite jai savo slaptažodį, kol duomenų bazė dar nepasiekiama tinkle.

Nuomininko aprėpties nustatymas

Užklausoje programa nustato dabartinį nuomininką ryšyje prieš vykdant nuomininkui skirtas užklausas – konceptualiai db.WithTenant. Kai nustatoma sritis, RLS taisyklės dėl ribotos rolės apriboja kiekvieną skaitymą ir rašymą tik tų nuomininkų eilutėms. Sritis susieta su darbo vienetu, todėl ji neišsiplečia tarp lygiagrečių užklausų.

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

Sistemos / apeinimo režimas darbuotojams

Kai kurie darbai yra teisėtai tarpnuomininkiški arba nepriklausomi nuo nuomininko — foniniai darbuotojai, planuotojai, pristatymo atkūrimas ir panaši priežiūra. Tam gateway naudoja sistemos (apeiti) režimas kuri veikia savininko bazėje, nepriklausomai nuo kiekvieno nuomininko RLS taisyklių, todėl infrastruktūros užduotys gali veikti per visą duomenų rinkinį.

[!WARNING] Aplinkos režimas skirtas tik patikimiems vidiniams darbuotojams. Užklausų apdorojimo kodo keliukai veikla vartotojo vardu visada turi vykti per apribotą nuomininko apribotas baseinas — niekada nepraeinantis apeinamuoju keliu.

Migracijos vykdomos savininko basele

Schemos pakeitimams reikalingos teisės, kurių apribota rolė neturi, todėl migracijos visada vykdomos savininko pagrindiniame bloke (AIHUMMER_DATABASE_URL), su patarimu užraktu, paleidžiant. Apribotas aihummer_app Vaidmuo naudojamas tik įprastam programos srautui. Tai palaiko privilegijų atskyrimą tvarkingą: schemą keičiantys veiksmai naudoja savininką; nuomininko duomenų prieiga naudoja ribotą vaidmenį su taikomu RLS.

Kur toliau

Daugiabūtiškumas ir nepakartojamumas — pilnas nuomininko modelis ir kaip šalutiniai poveikiai lieka saugūs atkūrimo metu.
Slaptų dokumentų saugykla — per-nuomininko DEK’ai stiprina tą patį izoliacija paslapčių sluoksnyje.
RBAC ir apriboti API raktai — autorizacija virš duomenų sluoksnis.