Sirrlər anbarı

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 hər bir şəhadətnaməni — kanal tokenlərini, SMTP/IMAP parollarını, OAuth tokenlərini, hər kirayəçi üçün LLM açarlarını (BYOK) — bir yerdə saxlayır **şifrələnmiş sirrlər anbarı**. Qazlı otaq qiymətlərin yalnız verilənlər bazasından oxuna bilməməsi üçün zərf şifrələməsindən istifadə edir və bu, bir sirrin qorunması üçün mühəndislik nümunəsi kimi hazırlanıb **heç vaxt model kontekstinə və ya qeydlərə daxil edilməmişdir**. ## Zərf şifrələməsi Sənədxana iki səviyyəli açar iyerarxiyasından istifadə edir: - A **əsas açar (KEK)** — təmin olunduğu kimi `AIHUMMER_MASTER_KEY`, base64 ilə şifrələnmiş 32 baytlıq dəyər — məlumat açarlarını bükür və açır. O heç vaxt ev sahibini tərk etmir və heç vaxt verilənlər bazasına yazılmır. - A **hər-icarədar üçün məlumatların şifrələmə açarı (DEK)** əsl sirli dəyərləri şifrələyir ilə **AES-256-GCM** (doğrulanmış şifrələmə). Hər bir kirayəçi öz DEK-ə malikdir, beləliklə, bir kirayəçinin açarları digər kirayəçinin sirlərini deşifrə edə bilməz. Gizli dəyərlər şifrli mətn kimi saxlanılır; DEK KEK tərəfindən qablanmış şəkildə saxlanılır. Şifrənin açılması yaddaşda, gizli bir məlumat lazım olduğu anda baş verir (məsələn, bir əlaqə vasitəsi ilə autentifikasiya edildikdə), və sonra açılmış mətn ləğv olunur. ```text AIHUMMER_MASTER_KEY (KEK) ──wraps──▶ per-tenant DEK ──AES-256-GCM──▶ secret value ``` > [!NOTE] > Kassa PostgreSQL-ə əsaslanır `pgcrypto` uzantı. Əmin olun ki, bu > sizin bazanızda mövcuddur — bu, standart sistem tələblərinin bir hissəsidir. ## Ümumi açar Əsas açar bir başlanğıc dəyərdir: o, işə salınarkən mühitdən oxunur və **yox** admin istifadəçi interfeysindən tənzimlənə bilən. Quraşdırıcı (və ilk başladıqda qapı) **həmişə yaradır `AIHUMMER_MASTER_KEY`** — bu seçmə deyil, çünki dinc vəziyyətdəki sirlər, etimadnamə anbarı və hər- kirayəçi üçün BYOK hamısı buna bağlıdır. Standart quraşdırmada buna görə həmişə biri var. ```ini # /home/.aihummer/etc/gateway.env # 32 random bytes, base64-encoded AIHUMMER_MASTER_KEY=Base64Of32RandomBytes== ``` Siz bunu ilə yarada bilərsiniz: ```bash openssl rand -base64 32 ``` > [!WARNING] > Kassadakı hər şeyi deşifr etmək üçün əsas açar tələb olunur. Onu belə qəbul edin > sirlərinizin və kökü **onu ayrıca ehtiyat nüsxəsini çıxarın** verilənlər bazasından — əgər > siz onu itirirsinizsə, şifrələnmiş dəyərləri bərpa etmək mümkün deyil. Bax > [Əməliyyatlar](/az/v1.0/getting-started/installation) ehtiyat nüsxə üzrə göstəriş üçün. ## Əgər əsas açar itibsə Çünki açar həmişə təmin edilir, standart quraşdırmada həmişə işləyən bir kasa olur. Buradakı davranış nadir halda baş verən vəziyyət üçün uğursuz-bağlanma qoruyucusudur `AIHUMMER_MASTER_KEY` nəyəsə görə təyin olunmayıb (məsələn, əl ilə redaktə edilmiş env faylı): qalay və ona bağlı hər şey **əngəllənmiş** — istirahət vəziyyətindəki gizliliklər üçün yaddaş, etimadnamə anbarı və hər kirayəçi üçün BYOK açarları hamısı söndürülüb. Bu məqsədli bir addımdır — məhsul gizlicə məlumatları açıq mətnlə saxlamağa geri qayıtmır. ## Gizli məlumatlar heç vaxt modelə çatmır Bu, zirzəminin ən vacib xüsusiyyətidir və bu, siyasət xatırlatmasından çox struktur xarakter daşıyır. > [!DANGER] > Sirlərdir **heç vaxt** sistem sualına, söhbətə yeridilmiş > tarix, və ya hər hansı model tərəfindən görünən mətn, və onlar **heç vaxt** jurnallara yazıldı. > Kredensiala ehtiyacı olan alətlər onu çağırış zamanı, vault daxilində həll edir > şlüzü və onu çıxdı tələbini autentifikasiya etmək üçün istifadə edin — yalnız model > heç kim alət çağırışının *nəticəsini*, sirrini görmür. Çünki qarşılıqlı əlaqə alət çağırışı ilə idarə olunur (bax [Mühafizə barmaqlıqları və sürətli-inyeksiya müdafiəsi](/az/v1.0/security/guardrails)), modeldən saxlanılan sirri “oxumaq” üçün prompt vasitəsi ilə bir yol yoxdur: modelin onu oxumaq üçün heç bir surəti yoxdur. ## Paylaşılan və hər-istifadəçi üçün olan giriş məlumatları Kassa arasında fərq qoyur **paylaşılan** (iş sahəsi səviyyəsində) etimadnamələr və **şəxsi** (istifadəçi üzrə) etimadnamələr. Connections axını vasitəsilə əldə edilmiş istifadəçi üzrə OAuth2 tokenləri kubokda saxlanılır və *fəaliyyət göstərən istifadəçi* tərəfindən həll olunur, lazımlı hallarda iş sahəsi ehtiyat variantı ilə. Bu, eyni alətin fərqli istifadəçilər adından öz səlahiyyətləri ilə fəaliyyət göstərməsinə imkan verir, bir istifadəçinin tokenini digərinə heç vaxt göstərmədən. ## Növbəti haradır - [RBAC və sahələndirilmiş API açarları](/az/v1.0/security/rbac) — kim oxuya və ya dəyişə bilər vault dəstəkli konfiqurasiya. - [Sətir Səviyyəli Təhlükəsizlik](/az/v1.0/security/rls) — icarədar başına izolasiya kassanı dəstəkləyən verilənlər bazası. - [Mühafizə barmaqlıqları və sürətli-inyeksiya müdafiəsi](/az/v1.0/security/guardrails) — niyə Model heç vaxt bir sirri yaymağa aldana bilməz.