Række-niveau sikkerhed — AiHummer Dokumenter

AiHummer er multitentant, og dens stærkeste isolationsgrænse findes i selve databasen: PostgreSQL række-niveau sikkerhed (RLS). Med RLS aktiveret håndhæver databasen — ikke kun applikationskoden — at en forespørgsel kun nogensinde ser de rækker, der tilhører den aktuelle lejer.

Dyreklasse: Række-niveau sikkerhed er begrænset af den betalte Foretagende niveau — det er ikke en del af den gratis/Community-platform.

Hvorfor RLS

Anvendelsesniveau-filtrering (WHERE tenant_id = ...) er nødvendigt, men skrøbeligt: en enkelt glemt klausul kan lække data mellem lejere. RLS flytter garantien ind i PostgreSQL, så selv en ufiltreret forespørgsel kun returnerer den aktuelle lejers rækker. Det er et forsvar-i-dybden-lag under applikationens eget scoped område. For den bredere multitenancy-model — og hvordan den parres med idempotente side-effekter — se Multitenancy og idempotens.

Den begrænsede rolle (tilvalg)

RLS er tilmelde sig og aktiveres ved at give gatewayen en anden databaseforbindelse, der bruger en begrænset rolle i stedet for ejeren:

# /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 bordejeren, så PostgreSQL anvender RLS-politikker på det. Applikationsforespørgsler flyder gennem denne begrænsede pool. Aktivering af RLS er et spørgsmål om at indstille AIHUMMER_DB_APP_URL — og lokal/standard (værts-native) installationer opsætter den variabel automatisk, så RLS er aktivt fra starten. Det er kun “tilvalg” i den forstand, at en tilpasset eller manuel implementering skal indstilles AIHUMMER_DB_APP_URL sig selv.

[!NOTE] Uden AIHUMMER_DB_APP_URL, gatewayet bruger ejer-poolen til alt og RLS håndhæves i praksis ikke. Indstil den begrænsede pulje (som standardinstallatøren gør for dig) for at slå databaseniveau-isoleringen til.

[!IMPORTANT] RLS afhænger ikke af abonnementet. Det virker ens på alle abonnementer, Community inklusive. Viser licensskærmen «Sikkerhed på rækkeniveau» som utilgængelig, er det en unøjagtighed i den visning og ikke databasens tilstand.

Hvor RLS allerede er aktivt, og hvor du selv skal slå det til

Sådan installerede du	RLS efter installationen
Standardinstallation, installationsprogrammet opsætter PostgreSQL	Aktivt. Den begrænsede rolle og `AIHUMMER_DB_APP_URL` oprettes for dig
Egen eller hosted PostgreSQL (databaseadressen var angivet på forhånd)	Ikke aktivt. Rollen og `AIHUMMER_DB_APP_URL` opretter du selv
Installation uden administratorrettigheder (rootless)	Ikke aktivt. Det samme

[!WARNING] To fejl, der lader RLS stå «til» uden at beskytte noget. Den første: AIHUMMER_DB_APP_URL peger på tabelejeren eller en superbruger — PostgreSQL undtager sådanne roller fra politikkerne, og gatewayen melder alligevel RLS som aktivt. Brug en separat begrænset rolle. Den anden: på din egen PostgreSQL kan den begrænsede rolle blive oprettet automatisk med et forudsigeligt kodeord — giv den dit eget kodeord, før databasen bliver tilgængelig over netværket.

Per-lejer afgrænsning

Inde i en forespørgsel etablerer applikationen den aktuelle lejer på forbindelsen, før der køres forespørgsler med lejer-scope — konceptuelt db.WithTenant. Når de er afgrænset, begrænser RLS-politikker på den begrænsede rolle hver læse- og skrivehandling til den lejers rækker. Afgrænsningen er knyttet til enheden af arbejde, så den ikke lækker mellem samtidige forespørgsler.

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

System / omgåelsestilstand for arbejdere

Noget arbejde er legitimt tvær-lejer eller lejer-agnostisk — baggrundsarbejdere, planlæggere, leveringgenopretning og lignende vedligeholdelse. For disse bruger gatewayen en system (omgå) tilstand der kører på ejerpoolen, uden for de enkelte lejer-RLS-politikker, så infrastrukturopgaver kan fungere på tværs af datasættet.

[!WARNING] Bypass-tilstand er kun for betroede interne medarbejdere. Anmodningshåndteringskodebaner der handler på vegne af en bruger, skal altid køre gennem de begrænsede, lejer-skopet pulje — aldrig omgåelsesstien.

Migrationer kører på ejerpoolen

Skemaforandringer kræver privilegier, som den begrænsede rolle ikke har, så migrationer kører altid på ejerpuljen (AIHUMMER_DATABASE_URL), under en rådgivende lås, ved opstart. Den begrænsede aihummer_app rollen bruges kun til almindelig applikationstrafik. Dette holder privilegieskillelsen ren: skemaændrende operationer bruger ejeren; adgang til lejerdata bruger den begrænsede rolle med RLS anvendt.

Hvor til næste

Multitenancy og idempotens — det fulde lejermodel, og hvordan bivirkninger forbliver sikre under genopretning.
Hemmelighedskammer — per-lejer DEK’er forstærker det samme isolation på hemmelighedslaget.
RBAC og scoped API-nøgler — bemyndigelse over datalag.