सिक्रेट्स वॉल्ट

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`, एक बेस64-कोडित 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`** — यह वैकल्पिक नहीं है, क्योंकि secrets-at-rest, credential vault और प्रति-टेनेंट BYOK सभी इस पर निर्भर करते हैं। इसलिए एक मानक स्थापना में हमेशा एक होता है। ```ini # /home/.aihummer/etc/gateway.env # 32 random bytes, base64-encoded AIHUMMER_MASTER_KEY=Base64Of32RandomBytes== ``` आप इसे इस प्रकार उत्पन्न कर सकते हैं: ```bash openssl rand -base64 32 ``` > [!WARNING] > वॉल्ट में सब कुछ डिक्रिप्ट करने के लिए मास्टर की की आवश्यकता होती है। इसका व्यवहार ऐसा करें जैसे > आपके रहस्यों की जड़ और **इसे अलग से बैकअप करें** डेटाबेस से — अगर > अगर आप इसे खो देते हैं, तो एन्क्रिप्टेड मान पाए नहीं जा सकते। देखें > [संचालन](/hi/v1.0/getting-started/installation) बैकअप मार्गदर्शन के लिए। ## अगर मास्टर कुंजी गायब है क्योंकि कुंजी हमेशा प्रोविज़न की जाती है, एक मानक इंस्टालेशन में हमेशा एक कार्यशील वॉल्ट होता है। यहां व्यवहार असामान्य मामले के लिए एक फेल-क्लोज़ गार्ड है जहां `AIHUMMER_MASTER_KEY` किसी न किसी तरह असेट है (उदाहरण के लिए, एक हाथ से संपादित किया गया env फाइल): वॉल्ट और उस पर निर्भर सब कुछ **अक्षम** — secrets-at-rest स्टोरेज, क्रेडेंशियल वॉल्ट और प्रति-टेनेंट BYOK कुंजी सभी बंद हैं। यह जानबूझकर किया गया है — उत्पाद गुप्त जानकारी को प्लेनटेक्स्ट में स्टोर करने के लिए चुपचाप वापस नहीं जाता। ## राज़ कभी मॉडल तक नहीं पहुँचते यह तिजोरी की सबसे महत्वपूर्ण विशेषता है, और यह नीति की याद दिलाने के बजाय संरचनात्मक है। > [!DANGER] > रहस्य हैं **कभी नहीं** सिस्टम प्रॉम्प्ट में इंजेक्ट किया गया, बातचीत > इतिहास, या कोई भी मॉडल-दृश्य पाठ, और वे हैं **कभी नहीं** लॉग में लिखा गया। > ऐसे उपकरण जिन्हें क्रेडेंशियल की आवश्यकता होती है, उसे कॉल समय पर वॉल्ट से हल करते हैं, अंदर > गेटवे, और इसे आउटबाउंड अनुरोध को प्रमाणित करने के लिए उपयोग करें — केवल मॉडल > कभी भी टूल कॉल का *परिणाम* देखता है, न कि रहस्य। क्योंकि इंटरैक्टिविटी टूल-कॉलिंग द्वारा संचालित होती है (देखें [गार्डरेल्स और प्रॉम्प्ट-इंजेक्शन सुरक्षा](/hi/v1.0/security/guardrails)ऐसा कोई तरीका नहीं है जिससे कोई प्रॉम्प्ट मॉडल से संग्रहीत रहस्य को "पढ़ने" के लिए कह सके: मॉडल के पास इसे पढ़ने की कोई प्रति नहीं है। ## साझा और प्रति-उपयोगकर्ता क्रेडेंशियल्स वॉल्ट के बीच अंतर करता है **साझा किया** (वर्कस्पेस-स्तरीय) क्रेडेंशियल और **व्यक्तिगत** (प्रति-उपयोगकर्ता) प्रमाण-पत्र। कनेक्शंस फ्लो के माध्यम से प्राप्त प्रति-उपयोगकर्ता OAuth2 टोकन वॉल्ट में संग्रहित किए जाते हैं और *कार्यकर्ता उपयोगकर्ता* द्वारा हल किए जाते हैं, जहां उपयुक्त हो वहां वर्कस्पेस फॉलबैक के साथ। इससे एक ही टूल विभिन्न उपयोगकर्ताओं की अपनी अधिकृतता के साथ उनकी ओर से कार्य कर सकता है, बिना कभी किसी एक उपयोगकर्ता के टोकन को दूसरे के सामने उजागर किए। ## अगला कहाँ - [RBAC और स्कोप्ड API कुंजियाँ](/hi/v1.0/security/rbac) — कौन पढ़ सकता है या बदल सकता है वॉल्ट-समर्थित कॉन्फ़िगरेशन। - [पंक्ति-स्तर सुरक्षा](/hi/v1.0/security/rls) — प्रति-किरायेदार अलगाव में डेटाबेस जो वॉल्ट का समर्थन करता है। - [गार्डरेल्स और प्रॉम्प्ट-इंजेक्शन सुरक्षा](/hi/v1.0/security/guardrails) — क्यों मॉडल को कभी भी किसी रहस्य को प्रकट करने के लिए धोखा नहीं दिया जा सकता।