AiHummer
Norsk
Logg påKonto
v1.1.x
{ }Swagger

Hemmelighets hvelv

v1.1.x · oppdatert 2026-06-26

AiHummer lagrer alle legitimasjoner — kanalnøkler, SMTP/IMAP-passord, OAuth-nøkler, per-leietaker LLM-nøkler (BYOK) — i en kryptert hemmelighetsarkiv. Hvelvet bruker konvoluttkryptering slik at verdien i ro aldri kan leses fra databasen alene, og det er konstruert slik at en hemmelighet er aldri plassert i modellkonteksten eller loggene.

Konvoluttkryptering

Hvelvet bruker en to-nivås nøkkelhierarki:

  • A hovednøkkel (KEK) — levert som AIHUMMER_MASTER_KEY, en base64-kodet 32-bytes verdi — pakker inn og pakker ut datanøklene. Den forlater aldri verten og blir aldri skrevet til databasen.
  • A per-leietaker datakrypteringsnøkkel (DEK) krypterer de faktiske hemmelige verdiene med AES-256-GCM (autentisert kryptering). Hver leietaker har sin egen DEK, slik at en leietakers nøkler ikke kan dekryptere en annen leietakers hemmeligheter.

Hemmelighetsverdier lagres som kryptert tekst; DEK lagres innpakket av KEK. Dekryptering skjer i minnet i det øyeblikket en hemmelighet trengs (for eksempel når en tilkobling autentiserer), og klarteksten kastes etterpå.

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

[!NOTE] Hvelvet er avhengig av PostgreSQLs pgcrypto utvidelse. Sørg for at den er tilgjengelig i databasen din — det er en del av standard systemkrav.

Hovednøkkelen

Hovednøkkelen er en bootstrap-verdi: den leses fra miljøet ved oppstart og er ikke konfigurerbar fra admin-grensesnittet. Installereren (og gatewayen ved første oppstart) alltid skaper AIHUMMER_MASTER_KEY — det er ikke valgfritt, fordi secrets-at-rest, kredentialhvelvet og per-leietaker BYOK alle er avhengige av det. Et standardoppsett har derfor alltid én.

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

Du kan generere en med:

openssl rand -base64 32

[!WARNING] Hovednøkkelen kreves for å dekryptere alt i hvelvet. Behandle den som roten til dine hemmeligheter og sikkerhetskopier det separat fra databasen — hvis du mister det, de krypterte verdiene kan ikke gjenopprettes. Se Operasjoner for sikkerhetsveiledning.

Hvis hovednøkkelen mangler

Fordi nøkkelen alltid er levert, har en standardinstallasjon alltid et fungerende hvelv. Oppførselen her er en fail-closed-beskyttelse for det uvanlige tilfellet der AIHUMMER_MASTER_KEY er på en eller annen måte ikke satt (for eksempel en manuelt redigert env-fil): hvelvet og alt som er avhengig av det er funksjonshemmet — secrets-at-rest-lagring, kredensialhvelvet og per-leietaker BYOK-nøkler er alle slått av. Dette er bevisst — produktet faller ikke stille tilbake til å lagre hemmeligheter i klartekst.

Hemmeligheter når aldri modellen

Dette er den viktigste egenskapen til hvelvet, og den er strukturell snarere enn en påminnelse om retningslinjer.

[!DANGER] Hemmeligheter er aldri injektert i systemprompten, samtalen historie, eller hvilken som helst modell-synlig tekst, og de er aldri skrevet til logger. Verktøy som trenger en legitimaskjema løser det fra hvelvet ved kalltidspunktet, inni porten, og bruk den til å autentisere den utgående forespørselen — modellen bare ser noen gang resultatet av verktøyanropet, ikke hemmeligheten.

Fordi interaktivitet drives av verktøy-anrop (se Rekkverk og forsvar mot prompt-injeksjon), finnes det ingen vei hvor en prompt kan be modellen om å “lese ut” en lagret hemmelighet: modellen har ingen kopi av den å lese.

Delte og per-bruker legitimasjoner

Hvelvet skiller mellom delt (arbeidsområde-nivå) legitimasjon og personlig (per-bruker) legitimasjon. Per-bruker OAuth2-tokener som er oppnådd gjennom Connections-strømmen, lagres i hvelvet og håndteres av den handlende brukeren, med en arbeidsområde-backup der det er hensiktsmessig. Dette lar det samme verktøyet handle på vegne av ulike brukere med deres egen autorisasjon, uten å noensinne eksponere en brukers token for en annen.

Hvor til neste