AiHummer
Dansk
Log indKonto
v1.2.x
{ }Swagger

Hemmelighedskammer

v1.2.x · opdateret 2026-06-26

AiHummer gemmer alle legitimationsoplysninger — kanal-token, SMTP/IMAP-adgangskoder, OAuth-token, per-lejer LLM-nøgler (BYOK) — i en krypteret hemmelighedsboks. Hvelvet bruger konvolutkryptering, så værdien i hvile aldrig kan læses fra databasen alene, og det er konstrueret, så en hemmelighed er aldrig placeret i modelkonteksten eller i logs.

Kuvertkryptering

Kælderen bruger en to-niveau nøglehierarki:

  • A hovednøgle (KEK) — leveret som AIHUMMER_MASTER_KEY, en base64-kodet 32-byte værdi — omslutter og afomslutter datanøglerne. Den forlader aldrig værten og skrives aldrig til databasen.
  • A per-lejer datakrypteringsnøgle (DEK) krypterer de faktiske hemmelige værdier med AES-256-GCM (autentificeret kryptering). Hver lejer har sin egen DEK, så en lejers nøgler ikke kan dekryptere en anden lejers hemmeligheder.

Hemmelighedsfulde værdier gemmes som krypteret tekst; DEK gemmes indpakket af KEK. Dekryptering sker i hukommelsen på det tidspunkt, hvor en hemmelighed er nødvendig (for eksempel når en connector autentificerer), og den almindelige tekst kasseres bagefter.

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

[!NOTE] Hvælvingen er afhængig af PostgreSQL’s pgcrypto udvidelse. Sørg for, at den er tilgængelig i din database — det er en del af standard systemkravene.

Hovednøglen

Hovednøglen er en bootstrap-værdi: den læses fra miljøet ved opstart og er ikke konfigurerbar fra administrationsgrænsefladen. Installatøren (og gatewayen ved første start) skaber altid AIHUMMER_MASTER_KEY — det er ikke valgfrit, fordi secrets-at-rest, credential vault og per-tenant BYOK alle afhænger af det. En standardinstallation har derfor altid é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øglen er nødvendig for at dekryptere alt i hvelvet. Behandl den som roden af dine hemmeligheder og sikkerhedskopier det separat fra databasen — hvis hvis du mister det, kan de krypterede værdier ikke gendannes. Se Operationer til backup-vejledning.

Hvis hovednøglen mangler

Fordi nøglen altid er leveret, har en standardinstallation altid et fungerende hvælv. Adfærden her er en fail-closed vagt for det usædvanlige tilfælde, hvor AIHUMMER_MASTER_KEY er på en eller anden måde ikke indstillet (for eksempel en manuelt redigeret env-fil): hvelvet og alt, der afhænger af det, er handicappet — secrets-at-rest-lagring, legitimationsopbevaringsskabet og BYOK-nøgler pr. lejer er alle slået fra. Dette er bevidst — produktet falder ikke stille tilbage til at gemme hemmeligheder i klartekst.

Hemmeligheder når aldrig modellen

Dette er den vigtigste egenskab ved hvelvet, og det er strukturelt frem for en påmindelse om politik.

[!DANGER] Hemmeligheder er aldrig injekteret i systemprompten, samtalen historie, eller enhver model-synlig tekst, og de er aldrig skrevet til logfiler. Værktøjer, der har brug for en legitimationsoplysning, henter den fra kassen på tidspunktet for opkaldet, indeni gatewayen, og brug den til at autentificere den udgående anmodning — modellen kun ser nogensinde resultatet af værktøjsopkaldet, ikke hemmeligheden.

Fordi interaktivitet drives af værktøjskald (se Vejafspærringer og forsvar mod prompt-injektion), der er ingen vej, hvorpå en prompt kan få modellen til at “læse” en gemt hemmelighed op: modellen har ingen kopi af den at læse.

Delte og per-bruger legitimationsoplysninger

Bunkeren skelner mellem delt (arbejdsområde-niveau) legitimationsoplysninger og personlig (per-bruger) legitimationsoplysninger. Per-bruger OAuth2-token opnået gennem Connections-flowet gemmes i hvelvet og håndteres af den handlende bruger, med en workspace-fallback hvor det er relevant. Dette gør det muligt for det samme værktøj at handle på vegne af forskellige brugere med deres egen autorisation, uden nogensinde at udsætte én brugers token for en anden.

Hvor til næste