საიდუმლოებების საცავი

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` გაფართოება. დარწმუნდით, რომ ის > ხელმისაწვდომია თქვენს მონაცემთა ბაზაში — ეს სტანდარტული სისტემური მოთხოვნების ნაწილი არის. ## მთავარი გასაღები მთავარი კლავი წარმოადგენს დატვირთვის მნიშვნელობას: ის იკითხება გარემოდან გაშვების დროს და არის **არა** კონფიგურირდება ადმინისტრაციული ინტერფეისის საშუალებით. დაყენებადი პროგრამა (და გეიტვეი პირველ გაშვებისას) **ყოველთვის ქმნის `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] > სეიფში ყველაფრის გახსნისთვის საჭიროა მთავარი გასაღები. მოეპყრეთ მას როგორც > შენი საიდუმლოების ძირი და **შეავსეთ რეზერვული კოპია ცალ-ცალკე** მონაცემთა ბაზიდან — თუ > თუ დაკარგავთ მას, დაშიფრული მნიშვნელობების აღდგენა შეუძლებელი იქნება. ნახეთ > [ოპერაციები](/ka/v1.0/getting-started/installation) სარეზერვო ასლის შექმნის სახელმძღვანელოსთვის. ## თუ მთავარ გასაღები არ არის იმიტომ, რომ გასაღები ყოველთვის მიწოდებულია, სტანდარტულ ინსტალაციას ყოველთვის აქვს მოქმედი საცავი. აქ არსებული მოქმედება არის შეცდომისას დახურული დაცვის მექანიზმი უცნაური შემთხვევისთვის, როდესაც `AIHUMMER_MASTER_KEY` საერთოდ არ არის დაყენებული (მაგალითად, ხელით შეცვლილ env ფაილში): საცავი და ყველაფერი, რაც მასზეა დამოკიდებული, **გათიშულია** — შენახული საიდუმლოებების დაცვა, ავტორიზაციის მონაცემთა საცავი და BYOK გასაღებები თითოეული კლიენტისთვის მთლიანად გამორთულია. ეს გაკეთდა მიზანმიმართულად — პროდუქტი ჩუმად არ დაუბრუნდება საიდუმლოებების ღია ტექსტით შენახვას. ## საიდუმლოებები არასდროს აღწევენ მოდელამდე ეს არის საცავის ყველაზე მნიშვნელოვანი მახასიათებელი და მას კონსტრუქციული ხასიათი აქვს, პოლიტიკის შეხსენების ფუნქცია კი არ ასრულებს. > [!DANGER] > საიდუმლოებები არსებობს **არასდროს** შესული სისტემური კითხვაში, საუბარში > ისტორია ან ნებისმიერი ტექსტი, რომელსაც მოდელი ხედავს, და ისინი **არასდროს** ჩაწერილია ჟურნლებში. > ინსტრუმენტები, რომლებსაც სჭირდებათ ავტორიზაციის მონაცემები, იღებენ მათ საცავიდან გამოძახების დროს, შიგნით > პორტალი და ის გამოიყენოთ გამავალი მოთხოვნის ავთენტიფიკაციისთვის — მხოლოდ მოდელი > ვინმეს სხედავს ინსტრუმენტის გამოძახების *შედეგი*, არა სერეტი. რადგან ინტერაქტიულობა უზრუნველყოფილია ინსტრუმენტების გამოძახებით (იხ. [ღობეები და რჩევების შეღწევისგან დაცვა](/ka/v1.0/security/guardrails)), არ არსებობს გზა, რომელი გზითაც მოთხოვნა შეძლებდა მოდელის «დაკითხვას» შენახული საიდუმლო: მოდელს არ აქვს მისი ასლი, რომ წაიკითხოს ის. ## საერთო და ინდივიდუალური შესვლის მონაცემები სეიფი ეცნობა განსხვავებას **საერთო** (სამუშაო სხრილაზე სასარგებლო მონაცემები) და **პირადი** (მომხმარებელზე) სერთიფიკატები. მომხმარებლის მიხედვით მიღებული OAuth2 ტოკენები Connections ნაკადის საშუალებით ინახება კარადში და იხსნება *მოქმედი მომხმარებლის მიერ*, საჭიროების შემთხვევაში სამუშაო სივრცის ჩანაცვლებით. ეს საშუალებას აძლევს ერთსა იმავე ხელსაწყოს იმოქმედოს სხვადასხვა მომხმარებლის სახელით, მათი საკუთარი ავტორიზაციით, არასდროს გაზიარება ერთი მომხმარებლის ტოკენი მეორესთან. ## სად შემდეგ? - [RBAC და შეზღუდული API გასაღებები](/ka/v1.0/security/rbac) — ვინ შეიძლება წაიკითხოს ან შეცვალოს კონფიგურაცია შენახვის მხარდაჭერით - [სტრიქონების დონეზე უსაფრთხოება](/ka/v1.0/security/rls) — იზოლაცია თითოეული ქირავნილისთვის მონაცემთა ბაზა, რომელიც მხარდაჭერას უწევს საცავს. - [ღობეები და რჩევების შეღწევისგან დაცვა](/ka/v1.0/security/guardrails) — რატომ მოდელი არასოდეს გახდება შეცდომაში შეყვანილი საიდუმლოს გაცემის მიზნით.