Skarbiec sekretów — AiHummer Dokumenty

AiHummer przechowuje wszystkie poświadczenia — tokeny kanałów, hasła SMTP/IMAP, tokeny OAuth, klucze LLM dla każdego najemcy (BYOK) — w zaszyfrowany sejf na sekrety. Skarbiec używa szyfrowania kopertowego, dzięki czemu przechowywana wartość nigdy nie jest czytelna tylko z samej bazy danych, a jego konstrukcja jest taka, że sekret jest nigdy nie umieszczano w kontekście modelu ani w logach.

Szyfrowanie kopertowe

Sejf używa dwupoziomowej hierarchii kluczy:

A klucz główny (KEK) — dostarczone jako AIHUMMER_MASTER_KEY, zakodowany w formacie base64 Wartość 32-bajtowa — owija i rozwija klucze danych. Nigdy nie opuszcza hosta i nigdy nie jest zapisywane w bazie danych.
A klucz szyfrowania danych (DEK) dla każdego najemcy szyfruje rzeczywiste wartości tajne z AES-256-GCM (szyfrowanie uwierzytelnione). Każdy najemca ma swój własny DEK, więc klucze jednego najemcy nie mogą odszyfrować tajemnic innego najemcy.

Wartości poufne są przechowywane jako tekst zaszyfrowany; DEK jest przechowywany owinięty przez KEK. Deszyfrowanie odbywa się w pamięci w momencie, gdy potrzebny jest sekret (na przykład, gdy konektor się uwierzytelnia), a następnie tekst jawny jest usuwany.

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

[!NOTE] Skarbiec opiera się na PostgreSQL pgcrypto rozszerzenie. Upewnij się, że jest dostępne w twojej bazie danych — jest częścią standardowych wymagań systemowych.

Klucz główny

Klucz główny jest wartością bootstrap: jest odczytywany ze środowiska podczas uruchamiania i jest nie konfigurowalne z poziomu interfejsu administracyjnego. Instalator (oraz brama przy pierwszym uruchomieniu) zawsze tworzy AIHUMMER_MASTER_KEY — nie jest to opcjonalne, ponieważ tajemnice w spoczynku, sejf na dane uwierzytelniające i BYOK dla każdego najemcy w dużej mierze od tego zależą. Standardowa instalacja zawsze go więc posiada.

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

Możesz wygenerować jeden za pomocą:

openssl rand -base64 32

[!WARNING] Główny klucz jest wymagany do odszyfrowania wszystkiego w skarbcu. Traktuj go jak korzeń twoich tajemnic i zrób kopię zapasową osobno z bazy danych — jeśli jeśli go utracisz, zaszyfrowanych wartości nie można odzyskać. Zobacz Operacje dla wskazówek dotyczących tworzenia kopii zapasowej.

Jeśli brak klucza głównego

Ponieważ klucz jest zawsze zapewniony, standardowa instalacja zawsze ma działający sejf. Zachowanie tutaj działa jako stróż działający w trybie awaryjnym w przypadku rzadkiej sytuacji, gdy AIHUMMER_MASTER_KEY jest w pewien sposób nieustawiony (na przykład ręcznie edytowany plik env): sejf i wszystko, co od niego zależy, są niepełnosprawny — przechowywanie sekretów w spoczynku, sejf na dane uwierzytelniające oraz klucze BYOK dla poszczególnych najemców są wszystkie wyłączone. Jest to celowe — produkt nie przechodzi potajemnie do przechowywania sekretów w formie niezaszyfrowanej.

Sekrety nigdy nie docierają do modelu

To jest najważniejsza cecha skarbca i ma charakter strukturalny, a nie przypomnienie o zasadach.

[!DANGER] Tajne są nigdy wstrzyknięty do podpowiedzi systemowej, rozmowa historia lub jakikolwiek tekst widoczny w modelu, i oni są nigdy zapisane w logach. Narzędzia, które potrzebują poświadczeń, rozwiązują je z sejfu w czasie wywołania, wewnątrz brama i użyj jej do uwierzytelnienia wychodzącego żądania — tylko model zawsze widzi wynik wywołania narzędzia, nie sekret.

Ponieważ interaktywność jest napędzana wywoływaniem narzędzi (zobacz Barierki ochronne i ochrona przed wstrzykiwaniem promptu), nie ma żadnej drogi, dzięki której polecenie mogłoby nakazać modelowi „odczytanie” przechowywanej tajemnicy: model nie ma jej kopii do odczytania.

Wspólne i przypisane do użytkownika poświadczenia

Skrytka rozróżnia pomiędzy wspólny (poziom przestrzeni roboczej) poświadczenia i osobisty Poświadczenia (dla każdego użytkownika). Tokeny OAuth2 dla poszczególnych użytkowników uzyskane w ramach przepływu połączeń są przechowywane w sejfie i rozwiązywane przez użytkownika działającego, z możliwością użycia ustawień zapasowych przestrzeni roboczej tam, gdzie jest to odpowiednie. Pozwala to temu samemu narzędziu działać w imieniu różnych użytkowników z ich własnym upoważnieniem, bez nigdy ujawniania tokena jednego użytkownika innemu.

Dokąd dalej

RBAC i klucze API o ograniczonym zakresie — kto może czytać lub zmieniać konfiguracja wspierana przez skarbiec.
Bezpieczeństwo na poziomie wiersza — izolacja na poziomie najemcy w baza danych, która obsługuje sejf.
Barierki ochronne i ochrona przed wstrzykiwaniem promptu — dlaczego model nigdy nie może zostać oszukany, aby ujawnił sekret.