Գաղտնիքների պահոց
AiHummer-ը պահում է յուրաքանչյուր հավատարմագիր — ալիքի թոքեններ, SMTP/IMAP գաղտնաբառեր, OAuth թոքեններ, ըստ-վարձակալի LLM բանալիներ (BYOK) — գաղտնագրված գաղտնիքների պահոցում։ Պահոցն օգտագործում է envelope գաղտնագրում, որպեսզի հանգստի վիճակում գտնվող արժեքը երբեք ընթեռնելի չլինի միայն տվյալների բազայից, և այն ճարտարագիտված է այնպես, որ գաղտնիքը երբեք չտեղադրվի մոդելի համատեքստ կամ լոգեր։
Envelope գաղտնագրում
Պահոցն օգտագործում է երկ-մակարդակ բանալիների հիերարխիա.
- Գլխավոր բանալին (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 արժեք է. այն կարդացվում է միջավայրից գործարկման ժամանակ և չի կարգավորվում ադմին UI-ից։
# /home/.aihummer/etc/gateway.env
# 32 random bytes, base64-encoded
AIHUMMER_MASTER_KEY=Base64Of32RandomBytes==Կարող եք գեներացնել մեկը հետևյալով.
openssl rand -base64 32[!WARNING] Գլխավոր բանալին պահանջվում է պահոցի ամեն ինչը ապակոդավորելու համար։ Վերաբերվեք դրան որպես ձեր գաղտնիքների արմատի և առանձին պահեստավորեք տվյալների բազայից — եթե կորցնեք այն, գաղտնագրված արժեքները չեն կարող վերականգնվել։ Տես Գործառնություններ պահեստավորման ուղեցույցի համար։
Առանց գլխավոր բանալու
Եթե AIHUMMER_MASTER_KEY-ը սահմանված չէ, պահոցը և ամեն ինչ, որ կախված է դրանից,
անջատված է. գաղտնիք-հանգստի վիճակում պահեստավորումը, հավատարմագրերի պահոցը և
ըստ-վարձակալի BYOK բանալիները բոլորն անջատված են։ Սա միտումնավոր fail-closed
վարքագիծ է — ապրանքը լուռ ձևով չի վերադառնում գաղտնիքները բացատեքստով պահելուն։
Գաղտնիքները երբեք չեն հասնում մոդելին
Սա պահոցի ամենակարևոր հատկությունն է, և այն կառուցվածքային է, այլ ոչ թե քաղաքականության հիշեցում։
[!DANGER] Գաղտնիքները երբեք չեն ներարկվում համակարգային prompt-ին, զրույցի պատմությանը կամ որևէ մոդելի-տեսանելի տեքստի, և դրանք երբեք չեն գրվում լոգերի մեջ։ Գործիքները, որոնց հավատարմագիր է պետք, լուծում են այն պահոցից կանչի պահին, gateway-ի ներսում, և օգտագործում են ելքային հարցումը նույնականացնելու համար — մոդելը երբևէ տեսնում է միայն գործիք-կանչի արդյունքը, ոչ թե գաղտնիքը։
Քանի որ ինտերակտիվությունն առաջնորդվում է գործիք-կանչմամբ (տես Պաշտպանական պատնեշներ և prompt-injection-ից պաշտպանություն), չկա ուղի, որով prompt-ը կարող է խնդրել մոդելին «բարձրաձայն կարդալ» պահված գաղտնիք. մոդելը դրա պատճենը չունի կարդալու համար։
Ընդհանուր և ըստ-օգտատիրոջ հավատարմագրեր
Պահոցը տարբերակում է ընդհանուր (աշխատանքային-տարածքի-մակարդակի) հավատարմագրերն ու անձնական (ըստ-օգտատիրոջ) հավատարմագրերը։ Ըստ-օգտատիրոջ OAuth2 թոքենները, որ ստացվել են Connections հոսքի միջոցով, պահվում են պահոցում և լուծվում գործող օգտատիրոջ կողմից, համապատասխան դեպքերում աշխատանքային-տարածքի հետադարձով։ Սա թույլ է տալիս նույն գործիքին գործել տարբեր օգտատերերի անունից նրանց սեփական իրավասությամբ, առանց երբևէ մի օգտատիրոջ թոքենը մյուսին բացահայտելու։
Ուր հաջորդ
- RBAC և շրջանակված API բանալիներ — ով կարող է կարդալ կամ փոխել պահոց-հենված կազմաձևումը։
- Տողի-մակարդակի անվտանգություն — ըստ-վարձակալի մեկուսացում տվյալների բազայում, որը հենում է պահոցին։
- Պաշտպանական պատնեշներ և prompt-injection-ից պաշտպանություն — ինչու մոդելը երբեք չի կարող խաբվել գաղտնիք թողարկելու։