Hemlighetsvalv

AIHUMMER_MASTER_KEY (KEK)  ──wraps──▶  per-tenant DEK  ──AES-256-GCM──▶  secret value

# /home/.aihummer/etc/gateway.env
# 32 random bytes, base64-encoded
AIHUMMER_MASTER_KEY=Base64Of32RandomBytes==

openssl rand -base64 32

AiHummer lagrar varje autentiseringsuppgift — kanal-token, SMTP/IMAP-lösenord, OAuth-token, per-tenant LLM-nycklar (BYOK) — i en **krypterad hemlighetsvalv**. Valvet använder kuvertkryptering så att värdet i vila aldrig kan läsas direkt från databasen, och det är utformat så att en hemlighet är **aldrig placerad i modellens kontext eller loggarna**. ## Kuvertkryptering Valvet använder en tvånivåig nyckelhierarki: - A **huvudnyckel (KEK)** — levererad som `AIHUMMER_MASTER_KEY`, en base64-kodad 32-byte värde — omsluter och avomsluter datanycklarna. Det lämnar aldrig värddatorn och skriver aldrig till databasen. - A **per-hyresgäst datakrypteringsnyckel (DEK)** krypterar de faktiska hemliga värdena med **AES-256-GCM** (autentiserad kryptering). Varje hyresgäst har sin egen DEK, så att en hyresgästs nycklar inte kan dekryptera en annan hyresgästs hemligheter. Heminformation lagras som chiffertext; DEK lagras inlindad av KEK. Avkryptering sker i minnet i det ögonblick en hemlighet behövs (till exempel när en anslutning autentiserar), och klartexten kastas därefter. ```text AIHUMMER_MASTER_KEY (KEK) ──wraps──▶ per-tenant DEK ──AES-256-GCM──▶ secret value ``` > [!NOTE] > Valvet förlitar sig på PostgreSQL:s `pgcrypto` tillägg. Se till att det är > tillgänglig i din databas — det är en del av de standardiserade systemkraven. ## Huvudnyckeln Huvudnyckeln är ett bootstrap-värde: det läses från miljön vid start och är **inte** konfigurerbar från administrationsgränssnittet. Installatören (och gatewayen vid första start) **skapar alltid `AIHUMMER_MASTER_KEY`** — det är inte valfritt, eftersom secrets-at-rest, credential vault och per-tenant BYOK alla beror på det. En standardinstallation har därför alltid en. ```ini # /home/.aihummer/etc/gateway.env # 32 random bytes, base64-encoded AIHUMMER_MASTER_KEY=Base64Of32RandomBytes== ``` Du kan generera en med: ```bash openssl rand -base64 32 ``` > [!WARNING] > Huvudnyckeln krävs för att dekryptera allt i valvet. Behandla den som > roten till dina hemligheter och **säkerhetskopiera det separat** från databasen — om > om du förlorar det, kan de krypterade värdena inte återställas. Se > [Operationer](/sv/v1.0/getting-started/installation) för säkerhetskopieringsvägledning. ## Om huvudnyckeln saknas Eftersom nyckeln alltid tillhandahålls har en standardinstallation alltid ett fungerande valv. Beteendet här är ett fail-closed-skydd för det ovanliga fallet där `AIHUMMER_MASTER_KEY` är på något sätt inte inställt (till exempel en handredigerad env-fil): valvet och allt som beror på det är **funktionshindrad** — lagring av hemligheter i vila, behörighetsvalvet och BYOK-nycklar per hyresgäst är alla avstängda. Detta är avsiktligt — produkten faller inte tyst tillbaka till att lagra hemligheter i klartext. ## Hemligheter når aldrig modellen Detta är den viktigaste egenskapen hos valvet, och den är strukturell snarare än en påminnelse om policyn. > [!DANGER] > Hemligheter är **aldrig** injekterad i systemprompten, konversationen > historia, eller någon modell-synlig text, och de är **aldrig** skrev till loggar. > Verktyg som behöver en referens hämtar den från valvet vid anropstid, inuti > gatewayen, och använd den för att autentisera den utgående begäran — modellen bara > ser någonsin *resultatet* av verktygsanropet, inte hemligheten. Eftersom interaktivitet drivs av verktygsanrop (se [Vägrenor och försvar mot promptinjektion](/sv/v1.0/security/guardrails)), det finns ingen väg genom vilken en prompt kan be modellen att "läsa upp" en sparad hemlighet: modellen har ingen kopia av den att läsa. ## Delade och per-användarkonton Valvet skiljer mellan **delad** (arbetsytans nivå) referenser och **personal** (per-användare) autentiseringsuppgifter. Per-användare OAuth2-token som erhålls genom Connections-flödet lagras i valvet och hanteras av *den agerande användaren*, med en arbetsytelösning där det är lämpligt. Detta gör att samma verktyg kan agera på uppdrag av olika användare med deras egen auktorisation, utan att någonsin exponera en användares token för en annan. ## Vart härnäst - [RBAC och begränsade API-nycklar](/sv/v1.0/security/rbac) — som kan läsa eller ändra valvstödd konfiguration. - [Radnivåsäkerhet](/sv/v1.0/security/rls) — per-tenantinrymning i databas som stöder valvet. - [Vägrenor och försvar mot promptinjektion](/sv/v1.0/security/guardrails) — varför modellen kan aldrig luras att avslöja en hemlighet.