AiHummer
Română▾
AutentificareCont personal
v1.0.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Securitate/Seiful secretelor

Seiful secretelor

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

AiHummer stochează fiecare acreditiv — tokenuri de canal, parole SMTP/IMAP, tokenuri OAuth, chei LLM per chiriaș (BYOK) — într-un seif de secrete criptate. Seiful folosește criptarea învelișului, astfel încât valoarea stocată să nu poată fi citită doar din baza de date, și este proiectat astfel încât un secret să fie niciodată plasat în contextul modelului sau în jurnale.

Criptarea plicului

Seiful folosește o ierarhie de chei pe două niveluri:

  • A cheie principală (KEK) — furnizat ca AIHUMMER_MASTER_KEY, codificat în base64 Valoare de 32 de octeți — învelește și dezvelește cheile de date. Nu părăsește niciodată gazda și nu este niciodată scris în baza de date.
  • A cheie de criptare a datelor (DEK) pentru fiecare chiriaș criptografiază valorile reale ale secretului cu AES-256-GCM (criptare autentificată). Fiecare chiriaș are propria sa DEK, astfel încât cheile unui chiriaș să nu poată decripta secretele altui chiriaș.

Valorile secrete sunt stocate ca text cifrat; DEK-ul este stocat învelit de KEK. Decriptarea are loc în memorie în momentul în care este necesar un secret (de exemplu, când un conector se autentifică), iar textul clar este eliminat ulterior.

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

[!NOTE] Seiful se bazează pe PostgreSQL pgcrypto extensie. Asigură-te că este disponibil în baza ta de date — face parte din cerințele standard ale sistemului.

Cheia principală

Cheia principală este o valoare bootstrap: este citită din mediul de operare la pornire și este nu configurabil din interfața de administrare. Programul de instalare (și gateway-ul la prima pornire) creează întotdeauna AIHUMMER_MASTER_KEY — nu este opțional, deoarece secretele în repaus, seiful de acreditive și BYOK pe client depind toate de acesta. Prin urmare, o instalare standard are întotdeauna unul.

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

Poți genera unul cu:

openssl rand -base64 32

[!WARNING] Este nevoie de cheia principală pentru a decripta totul din seif. Tratați-o ca pe rădăcina secretelor tale și salvează-l separat din baza de date — dacă dacă îl pierzi, valorile criptate nu pot fi recuperate. Vezi Operațiuni pentru ghidaj de rezervă.

Dacă cheia principală lipsește

Deoarece cheia este întotdeauna provisionată, o instalare standard are întotdeauna un seif funcțional. Comportamentul aici este un gardă fail-close pentru cazul neobișnuit în care AIHUMMER_MASTER_KEY este cumva neconfigurat (de exemplu, un fișier env editat manual): seiful și tot ce depinde de el sunt dezactivat — stocarea secretelor la repaus, seiful de acreditive și cheile BYOK per chiriaș sunt toate dezactivate. Acest lucru este intenționat — produsul nu revine în mod silențios la stocarea secretelor în text clar.

Secretele nu ajung niciodată la model

Aceasta este cea mai importantă proprietate a seifului și este structurală mai degrabă decât un memento de politică.

[!DANGER] Secretele sunt niciodată injected în promptul sistemului, conversația istorie, sau orice text vizibil în model, și ei sunt niciodată scris în jurnale. Instrumentele care necesită o acreditare o rezolvă din seif în momentul apelului, intern poarta și folosește-o pentru a autentifica cererea de ieșire — doar modelul vede vreodată rezultatul apelului instrumentului, nu secretul.

Deoarece interactivitatea este determinată de apelarea instrumentelor (vezi Parapete și apărare împotriva injecției de prompt), nu există niciun mod prin care un prompt să poată determina modelul să „citească” un secret stocat: modelul nu deține o copie a acestuia pentru a o citi.

Acreditări partajate și per utilizator

Seiful face distincție între partajat (la nivel de spațiu de lucru) acreditări și personal Credentiale (per utilizator). Token-urile OAuth2 pe utilizator obținute prin fluxul Connections sunt stocate în seif și sunt rezolvate de utilizatorul care acționează, cu o soluție de rezervă a spațiului de lucru atunci când este cazul. Acest lucru permite aceluiași instrument să acționeze în numele diferiților utilizatori cu propria lor autorizare, fără a expune vreodată token-ul unui utilizator altuia.

Unde următor?