Slaptų dokumentų saugykla

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

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

openssl rand -base64 32

AiHummer saugo kiekvieną kredencialą — kanalo žetonus, SMTP/IMAP slaptažodžius, OAuth žetonus, kiekvieno nuomininko LLM raktus (BYOK) — **užšifruotas paslapčių saugykla**. Saugykla naudoja vokų šifravimą, kad vertė ramybės būsenoje niekada nebūtų skaitoma vien tik iš duomenų bazės, ir ji sukurta taip, kad paslaptis būtų **niekada nepateikta modelio kontekste ar žurnaluose**. ## Vokų šifravimas Saugykla naudoja dviejų lygių raktų hierarchiją: - A **pagrindinis raktas (KEK)** — tiekiama kaip `AIHUMMER_MASTER_KEY`, base64 koduotas 32 baitų vertė — apvynioja ir atpalaiduoja duomenų raktus. Ji niekada nepalieka šeimininko ir niekada neįrašomas į duomenų bazę. - A **nuomininko duomenų šifravimo raktas (DEK)** šifruoja tikrąsias slaptojo vertes su **AES-256-GCM** (patvirtinta šifravimas). Kiekvienas nuomininkas turi savo DEK, taigi vieno nuomininko raktai negali iššifruoti kito nuomininko paslapčių. Slapti duomenys saugomi kaip šifruotas tekstas; DEK yra saugomas apvyniotas KEK. Iššifravimas vyksta atmintyje tuo momentu, kai reikia slapto duomenų (pavyzdžiui, kai autentifikuojasi jungiklis), o po to tekstas atvirkštiniu pavidalu yra išmetamas. ```text AIHUMMER_MASTER_KEY (KEK) ──wraps──▶ per-tenant DEK ──AES-256-GCM──▶ secret value ``` > [!NOTE] > Seifas remiasi PostgreSQL `pgcrypto` plėtinys. Įsitikinkite, kad tai yra > galimas jūsų duomenų bazėje — tai yra standartinių sistemos reikalavimų dalis. ## Pagrindinis raktas Pagrindinis raktas yra paleidimo vertė: jis skaitomas iš aplinkos paleidimo metu ir yra **ne** konfigūruojamas per administratoriaus sąsają. Diegėjas (ir vartų įrenginys pirmojo paleidimo metu) **visada sukuria `AIHUMMER_MASTER_KEY`** — tai nėra neprivaloma, nes ramybės būsenoje esantys slaptažodžiai, kredencialų saugykla ir kiekvienam nuomininkui skirtas BYOK visi priklauso nuo to. Todėl standartinė diegimo versija visada turi vieną. ```ini # /home/.aihummer/etc/gateway.env # 32 random bytes, base64-encoded AIHUMMER_MASTER_KEY=Base64Of32RandomBytes== ``` Jūs galite sugeneruoti vieną su: ```bash openssl rand -base64 32 ``` > [!WARNING] > Norint dešifruoti viską sefe, reikalingas pagrindinis raktas. Elkitės su juo kaip su > tavo paslapčių šaknis ir **atsargiai nukopijuokite atskirai** iš duomenų bazės — jei > jei ją prarandate, užšifruotų reikšmių atkurti nebus galima. Žr. > [Operacijos](/lt/v1.0/getting-started/installation) atsarginiam vadovavimui. ## Jei pagrindinis raktas dingęs Kadangi raktas visada yra teikiamas, standartinė įdiegimo versija visada turi veikiančią saugyklą. Čia elgsena yra uždaryta apsauga neįprastam atvejui, kai `AIHUMMER_MASTER_KEY` kaip nors nustatyta (pavyzdžiui, rankomis redaguotame env faile): saugykla ir viskas, kas nuo jos priklauso, yra **negaliojantis** — ramybės būsenoje saugoma informacija, kredencialų saugykla ir kiekvieno nuomininko BYOK raktai visi yra išjungti. Tai tyčinė — produktas neslėpia sandėliavimo slaptos informacijos paprastuoju tekstu. ## Paslaptys niekada nepasiekia modelio Tai yra svarbiausia saugyklos savybė, ir ji yra struktūrinė, o ne politikos priminimas. > [!DANGER] > Paslaptys yra **niekada** įpurškiamas į sistemos užklausą, pokalbis > istorija arba bet koks modeliui matomas tekstas, ir jie yra **niekada** rašyta į žurnalus. > Įrankiai, kuriems reikia kredencialų, juos gauna iš saugyklos kvietimo metu, viduje > vartai ir naudokite juos išvykstantiems užklausoms autentifikuoti — tik modelis > bet kuris mato įrankio kvietimo *rezultatą*, o ne paslaptį. Kadangi interaktyvumas yra varomas įrankių kvietimo (žr. [Apsauginės tvorelės ir apsauga nuo signalų injekcijos](/lt/v1.0/security/guardrails)), nėra jokio būdo, kad užklausa galėtų paprašyti modelio „perskaityti“ saugomą paslaptį: modelis neturi jos kopijos, kad galėtų perskaityti. ## Bendri ir kiekvieno vartotojo kredencialai Saugumo kamera skiria tarp **bendrai naudojamas** (darbo vietos lygio) kredencialai ir **asmeninis** (pagal vartotoją) kredencialai. Pagal vartotoją gauti OAuth2 žetonai per Connection srautą saugomi seife ir naudojami *veikiančio vartotojo*, su darbo srities atsarginiu variantu, kai tai tinkama. Tai leidžia tam pačiam įrankiui veikti skirtingų vartotojų vardu su jų autorizacija, niekada neatskleidžiant vieno vartotojo žetono kitam. ## Kur toliau - [RBAC ir apriboti API raktai](/lt/v1.0/security/rbac) — kas gali skaityti arba keisti konfigūracija, paremta seifu - [Eilutės lygio saugumas](/lt/v1.0/security/rls) — nuomininko izoliacija duomenų bazė, palaikanti saugyklą. - [Apsauginės tvorelės ir apsauga nuo signalų injekcijos](/lt/v1.0/security/guardrails) — kodėl modelio niekada neįmanoma apgauti, kad jis atskleistų paslaptį.