पंक्ति-स्तर सुरक्षा

# /home/.aihummer/etc/gateway.env
# Owner pool — runs migrations, used for system/bypass operations
AIHUMMER_DATABASE_URL=postgres://owner:...@localhost/aihummer

# Restricted application pool — RLS policies apply (aihummer_app role)
AIHUMMER_DB_APP_URL=postgres://aihummer_app:...@localhost/aihummer

request ─▶ resolve tenant ─▶ db.WithTenant(tenant) ─▶ queries see only that tenant

AiHummer मल्टीटेनेंट है, और इसकी सबसे मजबूत आइसोलेशन सीमा स्वयं डेटाबेस में है: **पोस्टग्रेएसक्यूएल रो-लेवल सुरक्षा (RLS)**. RLS सक्षम होने पर, डेटाबेस — केवल एप्लिकेशन कोड ही नहीं — यह सुनिश्चित करता है कि कोई भी क्वेरी केवल वर्तमान टेनेंट से संबंधित पंक्तियों को ही देख सके। **स्तर:** रो-स्तरीय सुरक्षा भुगतान किए गए द्वारा नियंत्रित है **उद्यम** स्तर — यह मुफ्त/समुदाय प्लेटफ़ॉर्म का हिस्सा नहीं है। ## आरएलएस क्यों एप्लिकेशन-स्तरीय फ़िल्टरिंग (`WHERE tenant_id = ...`) आवश्यक लेकिन नाजुक है: एक ही भूल गया खंड डेटा को किरायेदारों के बीच लीक कर सकता है। RLS इस गारंटी को PostgreSQL में स्थानांतरित कर देता है, ताकि एक बिना फ़िल्टर किए गए क्वेरी भी केवल वर्तमान किरायेदार की पंक्तियों को ही लौटाए। यह एप्लिकेशन के अपने स्कोपिंग के नीचे एक गहन सुरक्षा परत है। व्यापक मल्टीटेनेस मॉडल — और यह कैसे आइडेम्पोटेंट साइड-इफेक्ट्स के साथ जोड़ता है — देखें [मल्टीटेनेंसी और आइडेम्पोटेंसी](/hi/v1.0/architecture/multitenancy-idempotency). ## प्रतिबंधित भूमिका (साइन-अप चुनें) आरएलएस है **सहमति देना** और इसे सक्रिय किया जाता है जब गेटवे को दूसरा डेटाबेस कनेक्शन दिया जाता है जो मालिक के बजाय *सीमित* भूमिका का उपयोग करता है: ```ini # /home/.aihummer/etc/gateway.env # Owner pool — runs migrations, used for system/bypass operations AIHUMMER_DATABASE_URL=postgres://owner:...@localhost/aihummer # Restricted application pool — RLS policies apply (aihummer_app role) AIHUMMER_DB_APP_URL=postgres://aihummer_app:...@localhost/aihummer ``` द `aihummer_app` भूमिका है **नहीं** टेबल मालिक, इसलिए PostgreSQL उस पर RLS नीतियां लागू करता है। एप्लिकेशन क्वेरी इस प्रतिबंधित पूल के माध्यम से प्रवाहित होती हैं। RLS सक्षम करना सेटिंग का मामला है **`AIHUMMER_DB_APP_URL`** — और **स्थानीय/मानक (होस्ट-देशी) इंस्टॉलेशन उस वेरिएबल को स्वचालित रूप से सेट कर देते हैं**, इसलिए RLS बॉक्स से ही सक्रिय है। यह केवल इस अर्थ में "ऑप्ट-इन" है कि एक कस्टम या मैनुअल डिप्लॉयमेंट को सेट करना चाहिए `AIHUMMER_DB_APP_URL` स्वयं। > [!NOTE] > बिना `AIHUMMER_DB_APP_URL`, गेटवे सब कुछ के लिए मालिक पूल का उपयोग करता है > और RLS प्रभावी ढंग से लागू नहीं है। प्रतिबंधित पूल सेट करें (जो कि > डाटाबेस-स्तरीय अलगाव को चालू करने के लिए स्टैंडर्ड इंस्टॉलर आपके लिए करता है। > [!IMPORTANT] > **RLS किसी टैरिफ़ पर निर्भर नहीं है।** यह Community सहित सभी योजनाओं पर एक जैसा काम > करता है। यदि लाइसेंस स्क्रीन पर «पंक्ति-स्तरीय सुरक्षा» अनुपलब्ध दिखती है, तो यह उसी > स्क्रीन की अशुद्धि है, आपके डेटाबेस की स्थिति नहीं। ### RLS कहाँ पहले से सक्रिय है और कहाँ आपको इसे चालू करना होगा | आपने कैसे इंस्टॉल किया | इंस्टॉल के बाद RLS | |---|---| | सामान्य इंस्टॉल, PostgreSQL इंस्टॉलर तैयार करता है | **सक्रिय।** सीमित भूमिका और `AIHUMMER_DB_APP_URL` अपने आप बन जाते हैं | | अपना या प्रबंधित PostgreSQL (डेटाबेस पता पहले से दिया गया) | **सक्रिय नहीं।** भूमिका और `AIHUMMER_DB_APP_URL` संचालक बनाता है | | प्रशासक अधिकारों के बिना इंस्टॉल (rootless) | **सक्रिय नहीं।** वही बात | > [!WARNING] > **दो गलतियाँ जिनके बाद RLS «चालू» तो दिखता है पर कुछ भी सुरक्षित नहीं करता।** > **पहली:** `AIHUMMER_DB_APP_URL` में तालिकाओं का स्वामी या सुपरयूज़र दिया गया है — > PostgreSQL ऐसी भूमिकाओं को नीतियों से छूट देता है, और गेटवे फिर भी बताएगा कि RLS > सक्रिय है। अलग सीमित भूमिका का उपयोग करें। **दूसरी:** अपने PostgreSQL पर सीमित > भूमिका अनुमान लगाने योग्य पासवर्ड के साथ अपने आप बन सकती है — डेटाबेस के नेटवर्क पर > उपलब्ध होने से पहले उसे अपना पासवर्ड दें। ## प्रति-किरायेदार स्कोपिंग एक अनुरोध के अंदर, एप्लिकेशन टेनेंट-स्कोप्ड क्वेरीज चलाने से पहले कनेक्शन पर वर्तमान टेनेंट स्थापित करता है — अवधारणात्मक रूप से `db.WithTenant`. एक बार स्कोप किए जाने के बाद, प्रतिबंधित भूमिका पर RLS नीतियाँ उस किरायेदार की पंक्तियों पर हर पढ़ाई और लिखाई को सीमित कर देती हैं। स्कोप कार्य की इकाई से जुड़ा होता है, इसलिए यह समानांतर अनुरोधों के बीच नहीं फैलता। ```text request ─▶ resolve tenant ─▶ db.WithTenant(tenant) ─▶ queries see only that tenant ``` ## कर्मचारियों के लिए सिस्टम / बायपास मोड कुछ कार्य उचित रूप से क्रॉस-टेनेंट या टेनेंट-एग्नोस्टिक होते हैं — बैकग्राउंड वर्कर, शेड्यूलर, डिलीवरी रिकवरी और समान रखरखाव। इनके लिए, गेटवे उपयोग करता है **सिस्टम (बायपास) मोड** जो मालिक पूल पर चलता है, प्रति-भाड़े RLS नीतियों के बाहर, ताकि इन्फ्रास्ट्रक्चर कार्य डेटासेट के पार संचालित हो सकें। > [!WARNING] > बायपास मोड केवल विश्वसनीय आंतरिक कर्मचारियों के लिए है। अनुरोध-प्रक्रिया कोड पथ > जो किसी उपयोगकर्ता की ओर से कार्य करते हैं उन्हें हमेशा प्रतिबंधित के माध्यम से चलना चाहिए, > किरायेदार-सीमित पूल — कभी भी बायपास पथ नहीं। ## माइग्रेशन मालिक पूल पर चलते हैं Schema में बदलाव के लिए विशेषाधिकारों की आवश्यकता होती है, जो प्रतिबंधित भूमिका के पास नहीं हैं, इसलिए **स्थानांतरण हमेशा मालिक पूल पर चलते हैं** (`AIHUMMER_DATABASE_URL`), स्टार्टअप पर, एक सलाहकारी लॉक के तहत। प्रतिबंधित `aihummer_app` भूमिका केवल सामान्य अनुप्रयोग ट्रैफ़िक के लिए उपयोग की जाती है। यह विशेषाधिकार पृथक्करण को साफ रखता है: स्कीमा-परिवर्तन संचालन मालिक का उपयोग करते हैं; किरायेदार डेटा एक्सेस RLS लागू किए गए प्रतिबंधित भूमिका का उपयोग करता है। ## अगला कहाँ - [मल्टीटेनेंसी और आइडेम्पोटेंसी](/hi/v1.0/architecture/multitenancy-idempotency) — पूर्ण किरायेदार मॉडल और यह कि साइड-इफेक्ट्स पुनर्प्राप्ति के दौरान कैसे सुरक्षित रहते हैं। - [सिक्रेट्स वॉल्ट](/hi/v1.0/security/vault) — प्रति-किरायेदार DEKs वही मजबूत करते हैं गुप्त परत पर अलगाव। - [RBAC और स्कोप्ड API कुंजियाँ](/hi/v1.0/security/rbac) — ऊपर प्राधिकरण डेटा लेयर.