Գաղտնիքների պահոց

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 պահում է բոլոր հաշվի տվյալները՝ ալիքների տոկենները, SMTP/IMAP գաղտնաբառերը, OAuth-տոկենները, LLM բանալիները յուրաքանչյուր վարձանու համար (BYOK)՝ մեջ **կոդավորված գաղտնիքների պահպանակ**. Վահանակը օգտագործում է համապարփակ կոդավորում, որպեսզի ինֆորմացիան հանգստի վիճակում երբեք չկարողանար կարդացվել միայն տվյալների բազայից, և այն կառուցված է այնպես, որ գաղտնիք **հաճախ չի տեղավորվում մոդելի կոնտեքստում կամ լրագիրներում**. ## Ծածկագրային զտում Պահոցը օգտագործում է երկու մակարդակով բանալիի հիերարխիա՝ - Ա **մայր բանալի (KEK)** — հասանելի է որպես `AIHUMMER_MASTER_KEY`, base64-ով կոդավորված 32-բայթ արժեքը՝ փաթաթում և բացում է տվյալների բանալիները: Դա երբեք չի լքում հոսթը և կարծես բազայում երբեք չի գրանցվում: - Ա **տվյալների գաղտնագիր բանալի (DEK) ամեն մեկ վարձյալի համար** կոդավորում է փաստացի գաղտնի արժեքները ց **AES-256-GCM** (վավերացված կոդավորում): Յուրաքանչյուր վարձող ունի իր սեփական DEK-ը, այդպիսով, մեկ վարձուի բանալիները չեն կարող բացագրել մյուս վարձուի գաղտնիքները: Գաղտնի արժեքները պահվում են կոդավորված տեքստի տեսքով; DEK-ը պահվում է ծածկավորված տեսքով KEK-ի միջոցով: Տողանշանման գործընթացը տեղի է ունենում հիշողության մեջ այն պահին, երբ անհրաժեշտ է գաղտնիքը (օրինակ, երբ կոննեկտորը կատարում է նույնականացում), և սկզբնական տեքստը կործանվում է: այդից հետո: ```text AIHUMMER_MASTER_KEY (KEK) ──wraps──▶ per-tenant DEK ──AES-256-GCM──▶ secret value ``` > [!NOTE] > Պահոցը հիմնված է PostgreSQL-ի վրա `pgcrypto` բարցրացում. Հաստատեք, որ այն > հասանելի է ձեր տվյալների բազայում՝ սա ստանդարտ համակարգային պահանջների մասն է։ ## Գլխավոր բանալին Հիմնական բանալին հանդիսանում է բեռնման արժեքը՝ այն ընթերցվում է միջավայրից գործարկման ժամանակ և հանդիսանում է **ոչ** կարգավորվող ադմին UI-ից. Տեղադրողը (և անցակետը առաջին մեկնարկի ժամանակ) **այսպէ՛ս ստեղծում է `AIHUMMER_MASTER_KEY`** — սա պարտադիր չէ, քանի որ գաղտնիքների պահպանումը, հաշվի տվյալների պահոցն ու BYOK-ը յուրաքանչյուր վարձորդի համար բոլորն այսից են կախված: Ուստի ստանդարտ տեղադրումը միշտ այն ներառում է: ```ini # /home/.aihummer/etc/gateway.env # 32 random bytes, base64-encoded AIHUMMER_MASTER_KEY=Base64Of32RandomBytes== ``` Դուք կարող եք ստեղծել մեկը օգտագործելով՝ ```bash openssl rand -base64 32 ``` > [!WARNING] > Սեյֆում ամեն ինչ բացելու համար անհրաժեշտ է գլխավոր բանալին։ Մորարված միացեք դրա հետ այնպես, ինչպես > պատկերված է քո գաղտնիքների արմատում և **ստեղծեք առանձին բեկափուլ** հենքավորված տվյալների բազայից — եթե > եթե դուք այն կկորցնեք, կոդավորված արժեքները չեն կարող վերականգնվել։ Տեսեք > [Գործողություններ](/hy/v1.0/getting-started/installation) բարցրային կրկնօրինակի ուղեցույցի համար: ## Եթե գլխավոր բանալին բացակայում է Քանի որ բանալին միշտ տրամադրվում է, ստանդարտ տեղադրումը միշտ ունի աշխատող պահոց: Ուղղորդումը այստեղ անվտանգության ֆունկցիա է՝ փակվում է սխալի դեպքում անսովոր դեպքի համար, երբ `AIHUMMER_MASTER_KEY` ինչ-որ կերպ անհայտ է (օրինակ՝ ձեռքով խմբագրված env ֆայլում)` վաուլթը և այն ամենը, ինչը կախված է նրանից **անջատված** — Գաղտնիքների պահպանումը հանգստի վիճակում, հավատարմագրերի պահոցը և յուրաքանչյուր հաճախորդի համար BYOK բանալիներն ամբողջությամբ անջատված են: Դա մտադիր է արվել՝ արտադրանքը աննկատ չի վերադառնում բաց գաղտնիքների պահպանմանը: ## Գաղտնիքները երբեք չեն հասնում մոդելին Սա վավլետի ամենակարևոր հատկությունն է, և դա կառուցվածքային է, ոչ թե քաղաքականության հիշեցում։ > [!DANGER] > Գաղտնիքներ կան **երբեք** մտցված է համակարգային հարցում, զրույց > հետաքրքրություն կամ ցանկացած տեքստ, տեսանելի մոդելում, և նրանք **երբեք** գրանցված է հանրագրերում։ > Գործիքները, որոնց անհրաժեշտ են հավատարմագրեր, ստանում են դրանք պահոցից զանգի ժամանակ, ներսում > շպրտագիր և օգտագործել այն դուրսող հարցման համար վավերացման համար — միայն մոդել > ընտված մարդը տեսնում է *վերջնարդյունքը* գործիքի զանգի, ոչ թե գաղտնիքը։ Քանի որ ինտերակտիվությունն ապահովվում է գործիքների կանչմամբ (դիտեք [Պարիսպներ և առաջարկությունների ներմուծումից պաշտպանություն](/hy/v1.0/security/guardrails)), չկա ճանապարհ, որի միջոցով հարցումը կարող էր ստիպել մոդելին «կարդալ» պահած գաղտնի ինֆորմացիան․ մոդելը դրա պատճենը չունի՝ կարդալու համար։ ## Ընդհանուր և անհատական մուտքի տվյալներ Ապահովատուն տարբերակում է միջև **ընդհանուր** (աշխատանքային տարածքի մակարդակի գրանցումների տվյալներ) և **անձնական** (նրաւճարային տվյալներն ՅՈՒՐԱՔԱՆ ՅՈՒԶԵՐԻ ՀԱՄԱՐ): ՅՈՒԶԵՐԻ ՅՈՒՆԱՐՈՒԹՅԱՄԲ ստացած OAuth2 տոկենները Connections հոսքի միջոցով պահվում են պահոցում և օգտագործվում են *գործող օգտվողի կողմից*, հնարավոր լինելով օգտագործել աշխատանքային տարածքը որպես վերապահորոշված տարբերակ, որտեղ դա համապատասխան է: Սա թույլ է տալիս նույն գործիքին գործել տարբեր օգտատերերի անունից իրենց սեփական արտոնագրերով, երբեք չբացահայտելով մեկ օգտատիրոջ տոքենը մյուսին: ## Որտեղից հետո - [RBAC և սահմանափակ API-կոճակներ](/hy/v1.0/security/rbac) — ով կարող է կարդալ կամ փոփոխել կոնֆիգուրացիա՝ պահոցային աջակցությամբ - [Ապահովություն տողերի մակարդակով](/hy/v1.0/security/rls) — մեկուսացում յուրաքանչյուր վարձկանի համար տվյալների բազա, որը աջակցում է պահոցին։ - [Պարիսպներ և առաջարկությունների ներմուծումից պաշտպանություն](/hy/v1.0/security/guardrails) — ինչու մոդելը երբեք չի կարող խաբվել գաղտնիք տալու նպատակով։