AiHummer
Latviešu
PierakstītiesKonts
v1.0.x
{ }Swagger

Noslēpumu glabātava

v1.0.x · atjaunināts 2026-06-26

AiHummer glabā katru akreditācijas datus — kanāla tokenus, SMTP/IMAP paroles, OAuth tokenus, katra nomnieka LLM atslēgas (BYOK) — šifrētu noslēpumu glabātuve. Seifs izmanto aploksnes šifrēšanu, lai vērtība miera stāvoklī nekad nebūtu nolasāma tikai no datu bāzes, un tas ir izstrādāts tā, lai noslēpums būtu nekad netika ievietots modeļa kontekstā vai žurnālos.

Aploksnes šifrēšana

Seifs izmanto divpakāpju atslēgu hierarhiju:

  • A galvenā atslēga (KEK) — piegādāts kā AIHUMMER_MASTER_KEY, base64 kodēts 32 baitu vērtība — iesaiņo un atsaista datu atslēgas. Tā nekad neatstāj saimniekdatoru un nekad netiek ierakstīts datubāzē.
  • A katram nomniekam paredzētā datu šifrēšanas atslēga (DEK) šifrē faktiskās slepenās vērtības ar AES-256-GCM (autentificēta šifrēšana). Katrā nomniekā ir savs DEK, tādējādi viena nomnieka atslēgas nevar atšifrēt cita nomnieka noslēpumus.

Noslēpumvērtības tiek glabātas kā šifrteksts; DEK tiek glabāts, iesaiņots ar KEK. Dekriptēšana notiek atmiņā brīdī, kad noslēpums ir nepieciešams (piemēram, kad savienotājs autentificējas), un pēc tam skaidrteksts tiek iznīcināts.

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

[!NOTE] Seifs paļaujas uz PostgreSQL pgcrypto paplašinājums. Pārliecinieties, ka tas ir pieejams jūsu datubāzē — tas ir daļa no standarta sistēmas prasībām.

Galvenā atslēga

Galvenā atslēga ir starta vērtība: tā tiek nolasīta no vides palaišanas laikā un ir ne konfigurējams no administrēšanas lietotāja saskarnes. Instalētājs (un vārteja pirmajā startā) vienmēr rada AIHUMMER_MASTER_KEY — tas nav pēc izvēles, jo noslēpumi miera stāvoklī, akreditācijas datu glabātuve un katra nomnieka BYOK visi no tā ir atkarīgi. Standarta instalācijā tāpēc vienmēr ir.

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

Jūs varat to ģenerēt ar:

openssl rand -base64 32

[!WARNING] Lai atšifrētu visu glabātuvē, ir nepieciešama galvenā atslēga. Apieties ar to kā ar tavu noslēpumu sakne un rezervējiet to atsevišķi no datu bāzes — ja ja to pazaudējat, šifrētās vērtības nevar atgūt. Skatīt Operācijas rezerves vadībai.

Ja galvenā atslēga pazūd

Tā kā atslēga vienmēr ir nodrošināta, standarta instalācijā vienmēr ir darboties spējīgs seifs. Šeit uzvedība ir ‘fail-closed’ aizsardzība neparastajā gadījumā, kad AIHUMMER_MASTER_KEY ir kaut kādi nenoteikti (piemēram, manuāli rediģēts env fails): seifs un viss, kas no tā atkarīgs, ir nepilnspējīgs — secrets-at-rest krātuve, kredenciālo datu glabātuve un katra nomnieka BYOK atslēgas ir visas izslēgtas. Tas ir apzināti — produkts nemanāmi neatgriežas pie slepšanu glabāšanas skaidrā tekstā.

Noslēpumi nekad nesasniedz modeli

Tā ir svarīgākā seifa īpašība, un tā ir strukturāla, nevis politikas atgādinājums.

[!DANGER] Noslēpumi ir nekad ievadīts sistēmas uzvednē, saruna vēsture vai jebkāds modelim redzams teksts, un tie ir nekad pierakstīts žurnālos. Rīki, kam nepieciešama akreditācija, to iegūst no glabātuves izsaukuma laikā, iekšpusē vārteja un izmantojiet to, lai autentificētu izejošo pieprasījumu — tikai modelis vienmēr redz rīka izsaukuma rezultātu, nevis noslēpumu.

Tā kā interaktivitāti nosaka rīku izsaukšana (skatīt Aizsargbarjeras un uzvednes injekcijas aizsardzība), nav ceļa, pa kuru uzvedne var lūgt modelim “nolasīt” glabāto noslēpumu: modelim nav tā kopijas, ko lasīt.

Koplietoti un katram lietotājam atsevišķi akreditācijas dati

Seifs atšķir starp kopīgs (darba vietas līmeņa) akreditācijas dati un personāls (per-lietotāja) akreditācijas dati. Per-lietotāja OAuth2 žetoni, kas iegūti caur Savienojumu plūsmu, tiek glabāti seifā un tiek atrisināti pēc darbojošā lietotāja, ar darbvietas rezervi, kur tas ir piemērojami. Tas ļauj tam pašam rīkam darboties dažādu lietotāju vārdā ar viņu pašu autorizāciju, nekad neatklājot viena lietotāja žetonu citam.

Kur uz nākamo