საიდუმლოების საცავი
AiHummer ინახავს ყველა სარწმუნებელს — არხის ტოკენებს, SMTP/IMAP პაროლებს, OAuth ტოკენებს, თითო-მოიჯარის LLM გასაღებებს (BYOK) — დაშიფრულ საიდუმლოების საცავში. საცავი იყენებს კონვერტის დაშიფვრას ისე, რომ მნიშვნელობა მოსვენების მდგომარეობაში არასოდეს არის წაკითხვადი მხოლოდ ბაზიდან, და ის ისეა შემუშავებული, რომ საიდუმლო არასოდეს თავსდება მოდელის კონტექსტში ან ლოგებში.
კონვერტის დაშიფვრა
საცავი იყენებს ორ-დონიან გასაღების იერარქიას:
- მთავარი გასაღები (KEK) — მიწოდებული როგორც
AIHUMMER_MASTER_KEY, base64-კოდირებული 32-ბაიტიანი მნიშვნელობა — ახვევს და ხსნის მონაცემთა გასაღებებს. ის არასოდეს ტოვებს ჰოსტს და არასოდეს იწერება ბაზაში. - თითო-მოიჯარის მონაცემთა დაშიფვრის გასაღები (DEK) შიფრავს ფაქტობრივ საიდუმლო მნიშვნელობებს AES-256-GCM-ით (ავთენტიფიცირებული დაშიფვრა). თითოეულ მოიჯარეს აქვს საკუთარი DEK, ასე რომ ერთი მოიჯარის გასაღებებს არ შეუძლიათ სხვა მოიჯარის საიდუმლოების გაშიფვრა.
საიდუმლო მნიშვნელობები ინახება შიფრ-ტექსტად; DEK ინახება KEK-ით შეხვეული. გაშიფვრა ხდება მეხსიერებაში იმ მომენტში, როცა საიდუმლო საჭიროა (მაგალითად, როცა connector ახდენს ავთენტიფიკაციას), და ღია-ტექსტი შემდეგ უგულებელყოფა.
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] საიდუმლოები არასოდეს ინჯექტირდება სისტემურ პრომპტში, საუბრის ისტორიაში ან რომელიმე მოდელისთვის-ხილულ ტექსტში, და არასოდეს იწერება ლოგებში. ხელსაწყოები, რომელთაც სჭირდებათ სარწმუნებელი, წყვეტენ მას საცავიდან გამოძახების დროს, gateway-ის შიგნით, და იყენებენ მას გამავალი მოთხოვნის ავთენტიფიკაციისთვის — მოდელი ხედავს მხოლოდ ხელსაწყოს გამოძახების შედეგს, და არა საიდუმლოს.
რადგან ინტერაქტიულობას მართავს tool-calling (იხ. Guardrail-ები და prompt-injection დაცვა), არ არსებობს გზა, რომლითაც პრომპტს შეუძლია სთხოვოს მოდელს “წაიკითხოს” შენახული საიდუმლო: მოდელს არ აქვს მისი ასლი წასაკითხად.
საზიარო და თითო-მომხმარებლის სარწმუნებლები
საცავი განასხვავებს საზიარო (სამუშაო სივრცის-დონის) სარწმუნებლებსა და პერსონალურ (თითო-მომხმარებლის) სარწმუნებლებს. თითო-მომხმარებლის OAuth2 ტოკენები, მიღებული Connections ნაკადით, ინახება საცავში და წყდება მოქმედი მომხმარებლის მიერ, სამუშაო სივრცის fallback-ით სადაც შესაფერისია. ეს საშუალებას აძლევს ერთსა და იმავე ხელსაწყოს იმოქმედოს სხვადასხვა მომხმარებლის სახელით მათი საკუთარი ავტორიზაციით, ისე, რომ ერთი მომხმარებლის ტოკენი არასოდეს გამოამჟღავნოს მეორესთვის.
სად შემდეგ
- RBAC და არეალირებული API გასაღებები — ვის შეუძლია წაიკითხოს ან შეცვალოს საცავით-მხარდაჭერილი კონფიგურაცია.
- Row-Level Security — თითო-მოიჯარის იზოლაცია ბაზაში, რომელიც მხარს უჭერს საცავს.
- Guardrail-ები და prompt-injection დაცვა — რატომ ვერ მოატყუებენ მოდელს საიდუმლოს გამოცემაში.