डेटा इंजीनियरिंग साक्षात्कार: आप PostgreSQL 18 के लिए सुरक्षित OAuth कनेक्शन्स कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और संदर्भ

आपकी टीम एक मल्टी-टेनेंट एनालिटिक्स प्लेटफॉर्म को PostgreSQL 18 में अपग्रेड कर रही है और चाहती है कि एप्लिकेशन लंबे समय तक चलने वाले पासवर्ड के बजाय OAuth 2.0 बेयरर टोकन के साथ कनेक्ट हों। PostgreSQL 18 की OAuth सीमा, कनेक्शन हैंडशेक, रोल मैपिंग और रोलआउट योजना की व्याख्या करें। उन स्थानों को इंगित करें जहाँ प्राधिकरण (ऑथराइजेशन) गलती से विस्तृत हो सकता है या किसी इश्यूअर को लेकर भ्रम की स्थिति उत्पन्न हो सकती है।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

क्या आप OAuth क्लाइंट, ऑथराइजेशन सर्वर, रिसोर्स सर्वर और डेटाबेस रोल के बीच अंतर स्पष्ट करते हैं।
क्या आप pg_hba.conf, वैलिडेटर्स, स्कोप्स, मैप्स और libpq सेटिंग्स को एक सिंगल डेटा फ्लो में जोड़ सकते हैं।
क्या आप डिस्कवरी, सटीक इश्यूअर मिलान, TLS और टोकन-लाइफटाइम जोखिमों को पहचानते हैं।
क्या आप केवल “पासवर्ड को टोकन से बदलें” कहने के बजाय एक रिवर्सिबल माइग्रेशन का प्रस्ताव दे सकते हैं।

स्पष्टीकरण के लिए प्रश्न

क्या कॉलर इंसान हैं, बैकएंड सेवाएं हैं, या दोनों हैं? प्रिंसिपल का प्रकार पब्लिक बनाम कॉन्फिडेंशियल क्लाइंट को प्रभावित करता है।
क्या प्रत्येक टेनेंट एक अलग डेटाबेस रोल में मैप होता है? क्या एक टोकन कई रोल्स का प्रतिनिधित्व कर सकता है?
क्या प्रदाता एक मानक डिस्कवरी डॉक्यूमेंट और बेयरर-टोकन वैलिडेटर प्रदान करता है?
क्या लेगेसी क्लाइंट SCRAM का उपयोग जारी रख सकते हैं, और ऑडिट तथा रोलबैक विंडो कितनी लंबी है?

30-सेकंड का उत्तर

मैं PostgreSQL को रिसोर्स सर्वर, libpq/psql को OAuth क्लाइंट, और बाहरी पहचान प्रणाली को ऑथराइजेशन सर्वर मानूँगा; डेटाबेस टोकन जारी नहीं करता है। सर्वर pg_hba.conf में सटीक इश्यूअर, स्कोप्स और वैलिडेटर के साथ oauth को सक्षम करता है, और जब बाहरी पहचानों को डेटाबेस रोल्स से मैप करना होता है तो map का उपयोग करता है। क्लाइंट डिस्कवरी का उपयोग करता है और एक बेयरर टोकन प्रस्तुत करता है; वैलिडेटर हस्ताक्षर, इश्यूअर, ऑडियंस, समाप्ति (एक्सपायरी) और स्कोप्स की जांच करता है। मैं टेनेंट-दर-टेनेंट रोलआउट के दौरान SCRAM को बनाए रखूँगा, रिजेक्शन कारणों को मापूँगा, और रोलबैक करने के लिए OAuth नियम को हटा दूँगा।

विस्तृत विश्लेषण

1. ट्रस्ट बाउंड्री को परिभाषित करें

PostgreSQL 18 एक OAuth प्रमाणीकरण विधि जोड़ता है, कोई ऑथराइजेशन सर्वर नहीं। प्रदाता उपयोगकर्ताओं को अधिकृत करता है और टोकन जारी करता है; PostgreSQL एक टोकन को मान्य करता है और तय करता है कि क्या कोई कनेक्शन डेटाबेस रोल ग्रहण कर सकता है। डेटाबेस को लॉगिन UI के रूप में मानना या वहां रिफ्रेश टोकन स्टोर करना इसकी ज़िम्मेदारी को अत्यधिक बढ़ा देगा।

2. सर्वर नियम कॉन्फ़िगर करें

लक्षित नेटवर्क और डेटाबेस के लिए pg_hba.conf में एक oauth नियम जोड़ें, जिसमें issuer, scope, वैकल्पिक validator और वैकल्पिक map शामिल हों। इश्यूअर को डिस्कवरी डॉक्यूमेंट से अक्षर-दर-अक्षर मेल खाना चाहिए। यदि कई वैलिडेटर्स इंस्टॉल हैं, तो स्पष्ट रूप से एक का चयन करें। इस नियम को व्यापक पासवर्ड नियमों से पहले रखें ताकि अनुरोध किसी अनपेक्षित विधि पर न चला जाए।

3. डिस्कवरी और हैंडशेक को संभालें

libpq डिस्कवरी मेटाडेटा प्राप्त करने के लिए oauth_issuer का उपयोग करता है और फिर सर्वर द्वारा आवश्यक टोकन प्राप्त करता है। क्लाइंट का इश्यूअर HBA के इश्यूअर के बराबर होना चाहिए। PostgreSQL इस सटीक तुलना को मिक्स-अप हमलों के खिलाफ एक सुरक्षा उपाय के रूप में प्रलेखित करता है। कनेक्शन लॉग्स, प्रोसेस आर्गुमेंट्स या स्थायी कॉन्फ़िगरेशन में कभी भी बेयरर टोकन न रखें।

4. टोकन और रोल्स को मान्य करें

एक वैलिडेटर को हस्ताक्षर, इश्यूअर, लाइफटाइम, ऑडियंस और आवश्यक स्कोप्स की जांच करनी चाहिए, और फिर एक ऑडिट योग्य बाहरी पहचान लौटानी चाहिए। map के बिना, मान्य उपयोगकर्ता नाम अनुरोधित रोल के बिल्कुल बराबर होना चाहिए। मल्टी-टेनेंसी के लिए, डिफ़ॉल्ट-बाय-डिनाई (deny-by-default) व्यवहार के साथ एक स्पष्ट न्यूनतम-विशेषाधिकार (least-privilege) मैप का उपयोग करें। delegate_ident_mapping मानक pg_ident.conf मैपिंग को बायपास करता है और इसका उपयोग केवल तभी किया जाना चाहिए जब वैलिडेटर स्वयं पूर्ण रोल ऑथराइजेशन करता हो।

5. रोल आउट और रोल बैक करें

प्रोडक्शन से बाहर डिस्कवरी, TLS, स्कोप्स और समाप्त हो चुके टोकन के व्यवहार को सत्यापित करें। SCRAM को बनाए रखते हुए एक छोटे सर्विस समूह के लिए OAuth HBA नियम जोड़ें। सफलता, समाप्ति, इश्यूअर मिसमैच और मैपिंग रिजेक्शन को अलग-अलग मापें। पूल्स, जॉब्स और ऑपरेशंस स्क्रिप्ट्स द्वारा टोकन रीफ्रेश करने में सक्षम होने के बाद इसका विस्तार करें। OAuth नियम को हटाकर या SCRAM को पुनर्स्थापित करके रोल बैक करें, जबकि हर पूल के स्विच होने तक पुराने क्रेडेंशियल्स को बनाए रखें।

उच्च-गुणवत्ता वाला नमूना उत्तर

मैं चार पक्षों की रूपरेखा तैयार करूँगा: सेवा क्लाइंट है, पहचान प्लेटफ़ॉर्म ऑथराइजेशन सर्वर है, PostgreSQL रिसोर्स सर्वर है, और डेटाबेस रोल स्थानीय ऑथराइजेशन लक्ष्य है। HBA oauth विधि इश्यूअर, स्कोप्स और वैलिडेटर को नामित करती है और टोकन पहचान को टेनेंट रोल में मैप करती है। मैं delegate_ident_mapping से तब तक बचूँगा जब तक कि वैलिडेटर स्वयं रोल ऑथराइजेशन सिद्ध न कर दे। क्लाइंट oauth_issuer डिस्कवरी का उपयोग करेंगे, TLS लागू करेंगे, और टोकन को लॉग्स से बाहर रखेंगे। टेनेंट-दर-टेनेंट रोलआउट के दौरान, SCRAM उपलब्ध रहता है, जबकि डैशबोर्ड इश्यूअर, स्कोप, समाप्ति और मैपिंग विफलताओं को अलग करते हैं। OAuth नियम को हटाना एक त्वरित रोलबैक प्रदान करता है। यह टोकन जारी करने, डेटाबेस ऑथराइजेशन और माइग्रेशन नियंत्रण को अलग रखते हुए नेटिव PostgreSQL 18 क्षमता का उपयोग करता है।

सामान्य गलतियां

यह दावा करना कि PostgreSQL OAuth टोकन जारी करता है, रिसोर्स और ऑथराइजेशन सर्वर में भ्रमित होना।
केवल JWT हस्ताक्षर की जांच करना और इश्यूअर, ऑडियंस, समाप्ति या स्कोप जांच को छोड़ देना।
यह मान लेना कि एक ही डोमेन का इश्यूअर पर्याप्त है और सटीक डिस्कवरी मिलान की अनदेखी करना।
वैलिडेटर-साइड रोल ऑथराइजेशन की व्याख्या किए बिना delegate_ident_mapping को सक्षम करना।
कनेक्शन लॉग्स, ट्रेस या लंबे समय तक चलने वाले एनवायरनमेंट वेरिएबल्स में बेयरर टोकन लिखना।
एक ही चरण में SCRAM को हटाना और पूल्स तथा बैच जॉब्स को बिना रोलबैक पाथ के छोड़ देना।

फॉलो-अप प्रश्न और उत्तर

इश्यूअर का बिल्कुल सटीक मेल खाना क्यों आवश्यक है?

क्लाइंट इश्यूअर से एक डिस्कवरी URL बनाता है और प्राप्त इश्यूअर की तुलना अपने कॉन्फ़िगरेशन से करता है। केस (अक्षर के आकार), फॉर्मेटिंग और पाथ में बदलाव कनेक्शन को विफल कर सकते हैं; सख्त तुलना क्लाइंट को किसी अनपेक्षित ऑथराइजेशन सर्वर पर रीडायरेक्ट होने से भी बचाती है।

बिना मैप के रोल कैसे चुना जाता है?

वैलिडेटर द्वारा लौटाया गया उपयोगकर्ता नाम कनेक्शन द्वारा अनुरोधित रोल के बिल्कुल बराबर होना चाहिए। मल्टी-टेनेंट डिप्लॉयमेंट्स में आमतौर पर डिफ़ॉल्ट-बाय-डिनाई व्यवहार वाले एक स्पष्ट मैप की आवश्यकता होती है ताकि कोई पहचान स्वचालित रूप से किसी विशेषाधिकार प्राप्त रोल में न चली जाए।

OAuth विफल होने पर आप उपलब्धता कैसे बनाए रखते हैं?

रोलबैक के लिए कम समय के SCRAM क्रेडेंशियल्स रखें और पूल्स को धीरे-धीरे माइग्रेट करें। प्रकार के आधार पर विफलताओं की निगरानी करें, फिर यदि डिस्कवरी, स्कोप्स या वैलिडेटर का व्यवहार गलत है तो OAuth HBA नियम को हटाएं और पूर्व नियम को पुनर्स्थापित करें।