AiHummer
Беларуская▾
УвайсціАсабісты кабінет
v1.0.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Бяспека/Сховішча сакрэтаў

Сховішча сакрэтаў

v1.0.x · абноўлена 2026-06-26

AiHummer захоўвае ўсе ўліковыя даныя — токены каналаў, паролі SMTP/IMAP, токены OAuth, ключы LLM для кожнага арандатара (BYOK) — у зашыфраваны сейф сакрэтаўВыкарыстанне шифравання канверта дазваляе захоўваць значэнне ў стане спакою такім чынам, каб яго нельга было прачытаць толькі з базы дадзеных, і гэта распрацавана для захавання сакрэту ніколі не ўключаўся ў кантэкст мадэлі або ў журналы.

Шыфраванне канверта

Сховішча выкарыстоўвае двухузроўневую іерархію ключоў:

  • А асноўны ключ (KEK) — пастаўляецца як AIHUMMER_MASTER_KEY, закодаваны ў base64 32-байтны значэнне — абгортвае і разгортае ключы даных. Яно ніколі не пакідае хост і нікалі не запісваецца ў базу даных.
  • А ключ шыфравання дадзеных для кожнага арандатара (DEK) шыфруе сапраўдныя сакрэтныя значэнні з AES-256-GCM (аўтэнтыфікаванае шыфраванне). Кожны арандатар мае ўласны DEK так што ключы аднаго арандата не могуць расшыфраваць сакрэты іншага арандата.

Сакрэтныя значэнні захоўваюцца ў выглядзе шыфратэксту; DEK захоўваецца ў акрузе KEK. Дэшыфраванне адбываецца ў памяці ў момант неабходнасці сакрэта (напрыклад, калі аўтэнтыфікуецца злучальнік), пасля чаго адкрыты тэкст выдаляецца.

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

[!NOTE] Сховішча абапіраецца на PostgreSQL pgcrypto пашырэнне. Пераканайцеся, што яно даступна ў вашай базе даных — гэта частка стандартных патрабаванняў сістэмы.

Галоўны ключ

Галоўны ключ з’яўляецца значэннем bootstrap: ён счытваецца з асяроддзя пры запуску і з’яўляецца не можна наладзіць праз адміністрацыйны інтэрфейс. Устаноўшчык (і шлюз пры першым запуску) заўсёды стварае AIHUMMER_MASTER_KEY — гэта не опцыя, бо на гэтым залежаць захоўванне сакрэтаў у стане спакою, сховішча ўліковых дадзеных і BYOK для кожнага арандатара. Таму стандартная ўстаноўка заўсёды ўтрымлівае адзін.

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

Вы можаце стварыць адзін з дапамогай:

openssl rand -base64 32

[!WARNING] Для расшыфроўкі ўсяго ў сховішчы патрэбны галоўны ключ. Лячыце яго як корань тваіх таямніц і захоўваць асобна з базы даных — калі калі вы яго страціце, шыфраваныя значэнні не могуць быць адноўлены. Глядзіце Аперацыі для рэзервовых указанняў

Калі галоўны ключ адсутнічае

Паколькі ключ заўсёды прадугледжаны, стандартная ўстаноўка заўсёды мае працуючы сховішча. Паводзіны тут — гэта ахоўны механізм з закрыццём на выпадак незвычайнай сітуацыі AIHUMMER_MASTER_KEY як бы ні быў не ўстаноўлены (напрыклад, ручна рэдагаваны файл env): сейф і ўсё, што на ім залежыць, інвалід — сховішчы секрэтаў у стане спакою, сховішча пасведчанняў і ключы BYOK для кожнага арандатара усе адключаныя. Гэта зроблена наўмысна — прадукт не пераходзіць ціхамірна да захоўвання секрэтаў у адкрытым выглядзе.

Сакрэты ніколі не даходзяць да мадэлі

Гэта самая важная ўласцівасць сейфа, і яна мае структуральны, а не палітычны характар.

[!DANGER] Сакрэты ёсць нікалі ўведзены ў сістэмны падказку, размова гісторыя або любы тэкст, бачаны мадэллю, і яны нікалі запісана ў журналы Інструменты, якія патрабуюць аўтэнтыфікацыю, атрымліваюць яе з сховішча падчас выкліку, унутры шлюз і выкарыстоўваць яго для аўтэнтыфікацыі зыходнага запыту — толькі мадэль бачыць толькі вынік выкліку інструмента, а не сакрэт.

Паколькі інтэрактыўнасць кіруецца выклікам інструмента (глядзі Бар’еры бяспекі і абарона ад хуткай ін’екцыіНе існуе спосабу, каб запыт мог прымусіць мадэль «прачытаць» захаваны сакрэт: у мадэлі няма яго копіі, каб прачытаць.

Сумесныя і індывідуальныя рэквізіты

Сейф адрознівае паміж сумесны (на ўзроўні працоўнага прастору) рэквізіты і асабісты (па карыстальніку) ўліковыя даныя. Токены OAuth2, атрыманыя праз працэс Connections для асобнага карыстальніка, захоўваюцца ў сховішчы і апрацоўваюцца выканаўчым карыстальнікам, з магчымай перазагрузкай працоўнага прастору, калі гэта неабходна. Гэта дазваляе адной і той жа праграме дзейнічаць ад імя розных карыстальнікаў з іх уласным дазволам, ніколі не раскрываючы токен аднаго карыстальніка іншаму.

Куды далей