Radnivå-sikkerhet — AiHummer Dokumenter

AiHummer er flermotent, og dets sterkeste isolasjonsgrense finnes i selve databasen: **PostgreSQL radnivåsikkerhet (RLS)**Med RLS aktivert, sørger databasen — ikke bare applikasjonskoden — for at en spørring kun ser radene som tilhører den nåværende leietakeren.

Hvorfor RLS

Applikasjonsnivåfiltrering (WHERE tenant_id = ...) er nødvendig, men skjør: en enkelt glemt klausul kan lekke data mellom leietakere. RLS flytter garantien inn i PostgreSQL, slik at selv en ufiltrert spørring kun returnerer radene til den nåværende leietakeren. Det er et forsvar-i-dybden-lag under applikasjonens egen avgrensning. For den bredere multitenansmodellen – og hvordan den kombineres med idempotente sideeffekter – se Flerbrukerarkitektur og idempotens.

Den begrensede rollen (valgfritt)

RLS er meld deg på og aktiveres ved å gi gatewayen en andre databasen tilkobling som bruker en begrenset rolle i stedet for eieren:

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

Den aihummer_app rolle er ikke tabelleieren, slik at PostgreSQL anvender RLS-policyer på den. Applikasjonsspørringer går gjennom denne begrensede poolen. Å aktivere RLS er et spørsmål om å sette AIHUMMER_DB_APP_URL — og lokale/standard (verts-native) installasjoner setter opp den variabelen automatisk, så RLS er aktivt rett ut av boksen. Det er «valgfritt» bare i den forstand at en tilpasset eller manuell distribusjon må angi AIHUMMER_DB_APP_URL seg selv.

[!NOTE] Uten AIHUMMER_DB_APP_URL, porten bruker eierbassenget til alt og RLS håndheves i praksis ikke. Sett den begrensede puljen (som standardinstallatøren gjør for deg) for å slå på isolasjon på databasenivå.

[!IMPORTANT] RLS avhenger ikke av abonnementet. Det virker likt på alle planer, også Community. Viser lisenssiden «Sikkerhet på radnivå» som utilgjengelig, er det en unøyaktighet i den visningen og ikke tilstanden til databasen din.

Hvor RLS allerede er aktivt og hvor du må slå det på

Slik installerte du	RLS etter installasjonen
Standardinstallasjon, installasjonsprogrammet setter opp PostgreSQL	Aktivt. Den begrensede rollen og `AIHUMMER_DB_APP_URL` opprettes for deg
Egen eller administrert PostgreSQL (databaseadressen var oppgitt)	Ikke aktivt. Rollen og `AIHUMMER_DB_APP_URL` oppretter du selv
Installasjon uten administratorrettigheter (rootless)	Ikke aktivt. Det samme

[!WARNING] To feil som lar RLS stå «på» uten å beskytte noe. Den første: AIHUMMER_DB_APP_URL peker på tabelleieren eller en superbruker — PostgreSQL unntar slike roller fra reglene, og gatewayen melder likevel RLS som aktivt. Bruk en egen begrenset rolle. Den andre: på din egen PostgreSQL kan den begrensede rollen bli opprettet automatisk med et forutsigbart passord — gi den ditt eget passord før databasen blir tilgjengelig over nettet.

Per-leietaker avgrensning

Inne i en forespørsel etablerer applikasjonen den nåværende leietakeren på tilkoblingen før den kjører leietaker-avgrensede spørringer — konseptuelt db.WithTenant. Når de er avgrenset, begrenser RLS-policyer på den begrensede rollen hver lesing og skriving til den leietakerens rader. Omfanget er knyttet til arbeidsenheten, så det lekker ikke mellom samtidige forespørsler.

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

System / omgåelsesmodus for arbeidere

Noe arbeid er legitimt tverr-leietaker eller leietaker-agnostisk — bakgrunnsarbeidere, planleggere, leveringsgjenoppretting og lignende vedlikehold. For disse bruker gatewayen en system (omgå) modus som kjører på eierpoolen, utenfor per-leietaker RLS-policyene, slik at infrastrukturoppgaver kan operere på tvers av datasettet.

[!WARNING] Omkjøringsmodus er kun for betrodde interne arbeidere. Kodebaner for forespørselshåndtering som handler på vegne av en bruker må alltid gå gjennom den begrensede, leietaker-avgrenset basseng — aldri omgåelsesveien.

Migrasjoner kjører på eierbassenget

Skjemaendringer krever rettigheter som den begrensede rollen ikke har, så migrasjoner kjører alltid på eierpoolen (AIHUMMER_DATABASE_URL), under et rådgivende lås, ved oppstart. Den begrensede aihummer_app rollen brukes bare for vanlig applikasjonstrafikk. Dette holder privilegieskillet ryddig: skjema-endrende operasjoner bruker eieren; tilgang til leietakerdata bruker den begrensede rollen med RLS brukt.

Hvor til neste

Flerbrukerarkitektur og idempotens — den fullstendige leiemodellen og hvordan bivirkninger forblir trygge under gjenoppretting.
Hemmelighets hvelv — per-leietaker DEK-er forsterker det samme isolasjon på hemmelighetslaget.
RBAC og spesifiserte API-nøkler — autorisasjon over datalag.