Geheimnisse Tresor

v1.0.x · aktualisiert 2026-06-26

AiHummer speichert jede Anmeldeinformation — Kanal-Token, SMTP/IMAP-Passwörter, OAuth-Token, pro-Mandanten-LLM-Schlüssel (BYOK) — in einem verschlüsselter Geheimnis-Safe. Der Tresor verwendet Umschlagverschlüsselung, sodass der gespeicherte Wert niemals allein aus der Datenbank lesbar ist, und er ist so konzipiert, dass ein Geheimnis niemals in den Modellkontext oder in die Protokolle eingefügt.

Umschlagverschlüsselung

Der Tresor verwendet eine zweistufige Schlüsselhierarchie:

A Hauptschlüssel (KEK) — geliefert als AIHUMMER_MASTER_KEY, eine Base64-kodierte 32-Byte-Wert — verpackt und entpackt die Daten-Schlüssel. Er verlässt niemals den Host und wird niemals in die Datenbank geschrieben.
A pro-Mandanten-Datenverschlüsselungsschlüssel (DEK) verschlüsselt die tatsächlichen geheimen Werte mit AES-256-GCM (authentifizierte Verschlüsselung). Jeder Mieter hat seinen eigenen DEK, damit die Schlüssel eines Mieters nicht die Geheimnisse eines anderen Mieters entschlüsseln können.

Geheime Werte werden als Chiffretext gespeichert; der DEK wird von dem KEK umhüllt gespeichert. Die Entschlüsselung erfolgt im Speicher, sobald ein Geheimnis benötigt wird (zum Beispiel, wenn ein Connector sich authentifiziert), und der Klartext wird danach verworfen.

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

[!NOTE] Das Archiv basiert auf PostgreSQL’s pgcrypto Erweiterung. Stellen Sie sicher, dass sie es ist In Ihrer Datenbank verfügbar — es ist Teil der Standard-Systemanforderungen.

Der Generalschlüssel

Der Hauptschlüssel ist ein Bootstrap-Wert: Er wird beim Start aus der Umgebung gelesen und ist nicht konfigurierbar über die Admin-Oberfläche. Der Installer (und das Gateway beim ersten Start) erzeugt immer AIHUMMER_MASTER_KEY — es ist nicht optional, weil Secrets-at-Rest, der Credential Vault und pro-Mandant BYOK alle davon abhängen. Eine Standardinstallation hat daher immer eines.

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

Sie können einen erstellen mit:

openssl rand -base64 32

[!WARNING] Der Generalschlüssel wird benötigt, um alles im Tresor zu entschlüsseln. Behandle ihn wie die Wurzel deiner Geheimnisse und sichere es separat aus der Datenbank — wenn Wenn Sie es verlieren, können die verschlüsselten Werte nicht wiederhergestellt werden. Siehe Operationen zur Sicherungsanleitung.

Wenn der Generalschlüssel fehlt

Da der Schlüssel immer bereitgestellt wird, hat eine Standardinstallation immer einen funktionierenden Tresor. Das Verhalten hier ist ein fail-closed-Schutz für den ungewöhnlichen Fall, in dem AIHUMMER_MASTER_KEY ist irgendwie nicht gesetzt (zum Beispiel eine von Hand bearbeitete env-Datei): der Tresor und alles, was davon abhängt, sind behindert — Secrets-at-Rest-Speicherung, das Credential-Tresor und pro-Mandanten BYOK-Schlüssel sind alle deaktiviert. Dies ist beabsichtigt — das Produkt fällt nicht stillschweigend darauf zurück, Geheimnisse im Klartext zu speichern.

Geheimnisse erreichen das Modell niemals

Dies ist die wichtigste Eigenschaft des Tresors, und sie ist strukturell eher als eine Erinnerung an die Richtlinie.

[!DANGER] Geheimnisse sind niemals in das Systemprompt eingefügt, das Gespräch Geschichte oder irgendein modell-sichtbarer Text, und sie sind niemals in Protokolle geschrieben. Werkzeuge, die eine Anmeldeinformation benötigen, lösen diese zur Aufrufzeit aus dem Tresor auf, innen das Gateway und verwenden Sie es, um die ausgehende Anfrage zu authentifizieren — nur das Modell sieht jemals das Ergebnis des Werkzeugaufrufs, nicht das Geheimnis.

Weil Interaktivität durch Werkzeugaufrufe gesteuert wird (siehe Leitplanken & Schutz vor Prompt-Injektionen), es gibt keinen Weg, wie eine Eingabeaufforderung das Modell dazu bringen könnte, ein gespeichertes Geheimnis „vorzulesen“: Das Modell hat keine Kopie davon, die es vorlesen könnte.

Geteilte und benutzerspezifische Anmeldedaten

Der Tresor unterscheidet zwischen geteilt (Arbeitsbereichsbezogene) Anmeldeinformationen und persönlich (Pro-Benutzer) Anmeldeinformationen. Pro-Benutzer OAuth2-Token, die über den Connections-Flow erhalten werden, werden im Tresor gespeichert und vom handelnden Benutzer aufgelöst, mit einer Workspace-Alternative, wo dies zutreffend ist. Dies ermöglicht es demselben Tool, im Auftrag verschiedener Benutzer mit ihrer eigenen Autorisierung zu handeln, ohne jemals das Token eines Benutzers einem anderen offenzulegen.

Wohin als Nächstes

RBAC & begrenzte API-Schlüssel — wer lesen oder ändern darf Vault-gestützte Konfiguration.
Zeilenebenen-Sicherheit — mandantenbezogene Isolation in der Datenbank, die das Archiv unterstützt.
Leitplanken & Schutz vor Prompt-Injektionen — warum Das Modell kann niemals dazu gebracht werden, ein Geheimnis preiszugeben.