Radnivåsäkerhet

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

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

AiHummer är multitenant, och dess starkaste isoleringsgräns finns i själva databasen: **PostgreSQL radnivåsäkerhet (RLS)**. Med RLS aktiverat ser till att databasen — inte bara applikationskoden — att en fråga endast någonsin ser de rader som tillhör den aktuella hyresgästen. **Nivå:** Radnivåsäkerhet är begränsad av den betalade **Företag** nivå — det är inte en del av den gratis/Community-plattformen. ## Varför RLS Filtrering på applikationsnivå (`WHERE tenant_id = ...`) är nödvändig men skör: en enda bortglömd klausul kan läcka data mellan hyresgäster. RLS flyttar garantin in i PostgreSQL, så att även en ofiltrerad fråga endast returnerar den aktuella hyresgästens rader. Det är ett försvar-i-djupets-lager under applikationens egna avgränsningar. För den bredare multitenansmodellen — och hur den kombineras med idempotenta bieffekter — se [Fleranvändarsystem och idempotens](/sv/v1.0/architecture/multitenancy-idempotency). ## Den begränsade rollen (valfri) RLS är **anmäla sig** och aktiveras genom att ge gatewayen en andra databaskoppling som använder en *begränsad* roll istället för ägaren: ```ini # /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` roll är **inte** bordägaren, så PostgreSQL tillämpar RLS-policyer på det. Applikationsförfrågningar går igenom denna begränsade pool. Att aktivera RLS är en fråga om att ställa in **`AIHUMMER_DB_APP_URL`** — och **lokala/standard (värd-nativa) installationer ställer in den variabeln automatiskt**, så RLS är aktivt direkt. Det är "valfritt" endast i den meningen att en anpassad eller manuell distribution måste ställa in `AIHUMMER_DB_APP_URL` självt. > [!NOTE] > Utan `AIHUMMER_DB_APP_URL`, gatewayn använder ägarpoolen för allt > och RLS genomförs i praktiken inte. Ställ in den begränsade poolen (vilken > standardinstallatören gör åt dig) för att slå på databassnivåisoleringen. > [!IMPORTANT] > **RLS beror inte på prisplanen.** Det fungerar likadant på alla planer, > Community inräknad. Om licenssidan visar ”Säkerhet på radnivå” som otillgänglig > är det en felaktighet i den vyn, inte databasens tillstånd. ### Var RLS redan är aktivt och var du måste slå på det | Så installerade du | RLS efter installationen | |---|---| | Standardinstallation, installeraren sätter upp PostgreSQL | **Aktivt.** Den begränsade rollen och `AIHUMMER_DB_APP_URL` skapas åt dig | | Egen eller hanterad PostgreSQL (databasadressen angavs i förväg) | **Inte aktivt.** Rollen och `AIHUMMER_DB_APP_URL` skapar du själv | | Installation utan administratörsrättigheter (rootless) | **Inte aktivt.** Samma sak | > [!WARNING] > **Två misstag som lämnar RLS ”på” utan att skydda något.** > **Det första:** `AIHUMMER_DB_APP_URL` pekar på tabellägaren eller en > superanvändare — PostgreSQL undantar sådana roller från policyerna, och > gatewayen rapporterar ändå RLS som aktivt. Använd en separat begränsad roll. > **Det andra:** på din egen PostgreSQL kan den begränsade rollen skapas > automatiskt med ett förutsägbart lösenord — ge den ett eget lösenord innan > databasen blir nåbar över nätet. ## Per-hyresgästanpassad avgränsning Inom en förfrågan etablerar applikationen den aktuella hyresgästen på anslutningen innan den kör hyresgästsspecifika frågor — konceptuellt `db.WithTenant`. När den har avgränsats begränsar RLS-policyer på den begränsade rollen varje läs- och skrivoperation till den hyresgästens rader. Avgränsningen är kopplad till arbetsenheten, så den läcker inte mellan samtidiga förfrågningar. ```text request ─▶ resolve tenant ─▶ db.WithTenant(tenant) ─▶ queries see only that tenant ``` ## System / kringgå läge för arbetare Viss verksamhet är legitimt tvärgående mellan hyresgäster eller hyresgäst-oberoende — bakgrundsarbetare, schemaläggare, leveransåterställning och liknande underhåll. För dessa använder gatewayn en **system (omgå) läge** som körs på ägarpoolen, utanför RLS-policyerna för varje hyresgäst, så att infrastruktursuppgifter kan fungera över datasetet. > [!WARNING] > Bypass-läge är endast för betrodda interna arbetare. Begäran-hanteringskodvägar > som agerar å en användares vägnar måste alltid köras genom det begränsade, > hyresgäståtkomstpool — aldrig kringgående väg. ## Migrationer körs på ägarpoolen Schematändringar kräver privilegier som den begränsade rollen inte har, så **migreringar körs alltid på ägarpoolen** (`AIHUMMER_DATABASE_URL`), under ett rådgivande lås, vid start. Den begränsade `aihummer_app` rollen används endast för vanlig applikationstrafik. Detta håller privilegieskillnaden ren: schemaändrande operationer använder ägaren; åtkomst till hyresgästsdata använder den begränsade rollen med RLS tillämpad. ## Vart härnäst - [Fleranvändarsystem och idempotens](/sv/v1.0/architecture/multitenancy-idempotency) — den fullständiga hyresmodellen och hur bieffekter förblir säkra vid återställning. - [Hemlighetsvalv](/sv/v1.0/security/vault) — per-hyresgäst DEK:er förstärker samma isolering vid hemlighetslagret. - [RBAC och begränsade API-nycklar](/sv/v1.0/security/rbac) — auktorisation ovanför datalager.