Qualifying Observation Integrity for Selective Authorization in PostgreSQL

डिजिटल दुनिया में, डेटाबेस बैंक खातों से लेकर ऑनलाइन शॉपिंग कार्ट तक सब कुछ के लिए केंद्रीय स्मृति (सेंट्रल मेमोरी) के रूप में कार्य करते हैं। वे दुनिया की वर्तमान स्थिति को संग्रहीत करते हैं: एक खाते में कितने पैसे हैं, स्टॉक में कितनी वस्तुएं हैं, या किसी उपयोगकर्ता के पास किसी इमारत में प्रवेश करने की अनुमति है या नहीं। जब कोई कंप्यूटर प्रोग्राम किसी क्रिया को करने की अनुमति के लिए डेटाबेस से पूछता है, तो डेटाबेस वर्तमान तथ्यों की जांच करता है। यदि तथ्य पिछली बार की जांच के बाद बदल गए हैं, तो उत्तर अलग हो सकता है। उदाहरण के लिए, एक खरीद तब स्वीकृत हो सकती है जब उपयोगकर्ता के पास पर्याप्त धन हो, लेकिन यदि कोई अन्य लेनदेन एक सेकंड के भीतर उस धन को खर्च कर देता है, तो स्वीकृति वापस ली जानी चाहिए। सुरक्षित रहने के लिए, सिस्टम अक्सर हर बार कोई भी क्रिया होने से ठीक पहले तथ्यों की पुन: जांच करते हैं। यह विश्वसनीय है, लेकिन यह धीमा हो सकता है, विशेष रूप से जब एक ही तथ्यों को बिना बदले लगातार हजारों बार जांचा जाता है।

शोधकर्ताओं ने तथ्यों को पिछली बार जांचे जाने के समय को याद रखकर इसे तेज करने के तरीकों की तलाश लंबे समय से की है। यदि सिस्टम यह सिद्ध कर सके कि अंतर्निहित डेटा बदला नहीं है, तो वह बिना दोबारा पूछे पुराने अनुमति निर्णय का पुन: उपयोग कर सकता है। इसे 'सिलेक्टिव ऑथोराइजेशन' (चयनात्मक प्राधिकरण) कहा जाता है। हालांकि, यह शॉर्टकट तभी काम करता है जब सिस्टम पूरी तरह से आश्वत हो सके कि डेटा वास्तव में नहीं बदला है। यदि सिस्टम को यह सोचने के लिए धोखा दिया जाता है कि डेटा स्थिर है जबकि वह वास्तव में बदल रहा है, तो यह उस लेनदेन के लिए अनुमति दे सकता है जिसे रोका जाना चाहिए था। मुख्य चुनौती केवल डेटा की जांच करना नहीं है, बल्कि यह सत्यापित करना भी है कि परिवर्तन को ट्रैक करने के लिए डिज़ाइन किए गए तंत्र स्वयं सही ढंग से काम कर रहे हैं और सही लोगों के लिए दृश्यमान हैं।

एक शोधकर्ता अलेक्सांद्र मिहाइलोविक ने पोस्टग्रेसक्यूएल (PostgreSQL) नामक एक विशिष्ट प्रकार के डेटाबेस सिस्टम के भीतर इन ट्रैकिंग तंत्रों को सत्यापित करने की एक विधि विकसित की है। लक्ष्य नियमों का एक सख्त सेट बनाना था जिसका पालन डेटाबेस इंस्टालेशन को इस शॉर्टकट के भरोसे के लिए करना चाहिए। 'ओन्टोकमिट' (OntoCommit) नामक यह सिस्टम एक द्वारपाल (गेटकीपर) के रूप में कार्य करता है। किसी डेटाबेस को पुराने अनुमति निर्णयों का पुन: उपयोग करने की अनुमति देने से पहले, यह द्वारपाल कोड और कॉन्फ़िगरेशन का निरीक्षण करता है ताकि यह सुनिश्चित किया जा सके कि डेटा में प्रत्येक परिवर्तन को ठीक से रिकॉर्ड किया गया है और रिकॉर्ड की जांच करने वाला व्यक्ति उन रिकॉर्डों को वास्तव में देख सकता है। शोध एक विशिष्ट सीमा पर केंद्रित है: वह क्षण जब एक परिवर्तन किया जाता है और वह क्षण जब उसे देखा जाता है। यदि इन दोनों के बीच कोई अंतर है, तो पूरे सिस्टम की सुरक्षा खतरे में पड़ जाती है।

अध्ययन की शुरुआत यह पहचानने से हुई कि यह विश्वास कितनी आसानी से टूट सकता है, भले ही कोड सतह पर सही दिख रहा हो। शोधकर्ता ने पाया कि दो विशिष्ट तरीके थे जिनसे सिस्टम चुपचाप विफल हो सकता था। पहले मामले में, एक हेल्पर फंक्शन जिसे परिवर्तन काउंटर को अपडेट करने के लिए डिज़ाइन किया गया था, उसके इनपुट नामों को आपस में बदल दिया गया था। कोड अभी भी चल रहा था, और डेटा के प्रकार जो उसने स्वीकार किए थे वे भी सही थे, लेकिन क्योंकि नाम आपस में मिल गए थे, इसलिए एक प्रकार के परिवर्तन के लिए काउंटर अपडेट हुआ जबकि दूसरे प्रकार का काउंटर स्थिर रहा। यह एक ट्रैफिक लाइट सिस्टम की तरह था जहाँ उत्तर-दक्षिण लेन के सेंसर को गलती से पूर्व-पश्चिम बटन से जोड़ दिया गया था; लाइटें बदलती तो थीं, लेकिन उन कारों के लिए नहीं जिन्हें उनकी आवश्यकता थी। दूसरे मामले में, सिस्टम को एक सुरक्षा सुविधा के साथ कॉन्फ़गर किया गया था जो नियमित उपयोगकर्ताओं से डेटा की कुछ पंक्तियों (rows) को छिपाती थी। सिस्टम एडमिनिस्ट्रेटर द्वारा परिवर्तन काउंटर को सही ढंग से अपडेट किया गया था, लेकिन अनुमति की जांच करने वाला व्यक्ति उस अपडेट को देखने से बाधित था। जांचकर्ता के लिए, काउंटर शून्य दिखाई दे रहा था, भले ही वह वास्तव में बढ़ चुका था। इसने सुरक्षा की एक झूठी भावना पैदा की।

इन विफलताओं को रोकने के लिए, शोधकर्ता ने एक योग्यता उपकरण (qualification tool) बनाया जो शॉर्टकट का उपयोग करने से पहले डेटाबेस इंस्टालेशन की जांच करता है। यह टूल केवल कोड की उपस्थिति को नहीं देखता; यह फंक्शन नामों के सटीक बंधन (binding), तालिकाओं के स्वामित्व और प्रत्येक उपयोगकर्ता भूमिका के लिए दृश्यता सेटिंग्स को सत्यापित करता है। यह इस बात पर जोर देता है कि परिवर्तन काउंटरों को अपडेट करने के लिए जिम्मेदार कोड का सिग्नेचर बिल्कुल वैसा ही होना चाहिए जैसा सिस्टम अपेक्षित करता है। यह उन तालिकाओं पर रो-लेवल सिक्योरिटी (पंक्ति-स्तर की सुरक्षा) के उपयोग को भी वर्जित करता है जो इन परिवर्तनों को ट्रैक करती हैं, यह सुनिश्चित करता है कि अनुमति की जांच करने वाला व्यक्ति हमेशा काउंटर की वास्तविक स्थिति देख सके। यह टूल एक कठोर निरीक्षक की तरह कार्य करता है, जो किसी भी ऐसे इंस्टालेशन को अस्वीकार कर देता है जो असमर्थ विविधताओं का उपयोग करने की कोशिश करता है या परिवर्तन के साक्ष्य को छिपाता है।

शोधकर्ता ने इस दृष्टिकोण का परीक्षण एक नियंत्रित वातावरण का उपयोग करके किया जो एक पूर्ण खरीद प्रक्रिया का अनुकरण (simulate) करता है। सिस्टम को एक परिदृश्य को संभालने के लिए सेट किया गया था जहाँ एक उपयोगकर्ता कुछ खरीदने की कोशिश करता है, अपने खाते के शेष धन और अपने फंड पर किसी भी मौजूदा रोक (holds) की जांच करता है। प्रयोग दो विधियों की तुलना करता है: एक जहाँ सिस्टम हर बार शून्य से पूरी नीति का पुनर्मूल्यांकन करता है, और दूसरा जहाँ सिस्टम 'सिलेक्टिव ऑथोराइजेशन' शॉर्टकट का उपयोग करता है। परीक्षण डेटाबेस सॉफ्टवेयर के एक मानक संस्करण पर चलाए गए थे, लेकिन सटीक नियंत्रण सुनिश्चित करने के लिए एक सिम्युलेटेड कंप्यूटर वातावरण के भीतर। अध्ययन में एक सौ आठ अलग-अलग कॉन्फ़िगरेशन जोड़े शामिल थे, जिनमें से कुछ को सुरक्षित और कुछ को असुरक्षित डिज़ाइन किया गया था, ताकि यह देखा जा सके कि क्या योग्यता उपकरण अंतर बता सकता है।

परिणामों ने दिखाया कि योग्यता उपकरण असुरक्षित कॉन्फ़िगरेशन की पहचान करने में अत्यधिक प्रभावी था। इसने जानबूझकर बनाए गए पांच असुरक्षित सेटअपों को सफलतापूर्वक खारिज कर दिया, जिसमें बदले हुए पैरामीटर नाम और छिपे हुए डेटा रो (rows) वाले मामले भी शामिल थे। साथ ही, इसने उन पैंतालीस वैध, सुरक्षित कॉन्फ़िगरेशन को स्वीकार किया जो सही थे। इसने दो ऐसे कॉन्फ़िगरेशन को भी सही ढंग से अस्वीकार कर दिया जो सुरक्षित थे लेकिन टूल के सख्त नियमों में फिट नहीं बैठते थे, जिससे यह प्रदर्शित होता है कि यह सुविधा से अधिक सुरक्षा को प्राथमिकता देता है। प्रदर्शन परीक्षणों में, जब डेटा अपरिवर्तित रहता है, तो सिलेक्टिव ऑथोराइजेशन विधि काफी तेज़ साबित हुई। दस हजार पंक्तियों के डेटासेट के लिए, शॉर्टकट का उपयोग करने वाले सिस्टम ने चक्र को साठ-छियासठ मिलीसेकंड के औसत समय में पूरा किया, जबकि सब कुछ फिर से जांचने वाले सिस्टम ने अस्सी-सत्तानवे मिलीसेकंड का समय लिया। यह समय में चौबीस प्रतिशत की कमी थी। हालांकि, अध्ययन में यह भी पाया गया कि जब डेटा वास्तव में बदल गया, तो शॉर्टकट ने कोई गति लाभ नहीं दिया और यह थोड़ा धीमा भी हो सकता था, क्योंकि सिस्टम को नीति का पुनर्मूल्यांकन करना पड़ता था।

शोध ने परीक्षण की सीमाओं को भी उजागर किया। शोधकर्ता ने प्रदर्शित किया कि केवल कुछ परीक्षण चलाना कि सिस्टम काम करता है, यह गारंटी देने के लिए पर्याप्त नहीं है कि यह हमेशा काम करेगा। ऐसी स्थिति बनाना संभव है जहाँ एक सिस्टम हर परीक्षण में पास हो जाता है लेकिन फिर भी एक विशिष्ट, अनदेखी स्थिति में विफल हो जाता है। अध्ययन ने दिखाया कि एक सिस्टम कई जांचों को पास कर सकता है जबकि अभी भी एक महत्वपूर्ण परिवर्तन को पर्यवेक्षक से छिपा सकता है। इसका अर्थ यह है कि सुरक्षा सुनिश्चित करने का एकमात्र तरीका यह है कि सिस्टम कैसे बनाया गया है इसके बारे में सख्त नियम लागू किए जाएं, न कि केवल त्रुटियों को खोजने के लिए परीक्षण पर निर्भर रहना। यह टूल यह दावा नहीं करता है कि वह हर संभावित ब्रह्मांड में सिस्टम को पूर्ण साबित कर देगा, बल्कि यह एक सत्यापन योग्य अनुबंध (verifiable contract) प्रदान करता है कि इंस्टालेशन एक विशिष्ट, सुरक्षित पैटर्न का पालन करता है।

अंत में, यह कार्य डेटाबेस को सुरक्षा से समझौता किए बिना तेज़ बनाने का एक व्यावहारिक तरीका प्रदान करता है। यह परिभाषित करके कि परिवर्तन ट्रैकिंग को कैसे लागू और सत्यापित किया जाना चाहिए, शोधकर्ता ने यह विश्वास करने का एक तरीका बनाया है कि डेटाबेस अपने स्वयं के राज्य के बारे में सच बोल रहा है। अध्ययन यह दावा नहीं करता है कि यह डेटाबेस सुरक्षा की हर समस्या को हल करता है, न ही यह सुझाव देता है कि इस विधि को हर स्थिति में उपयोग किया जाना चाहिए। यह एक विशिष्ट प्रकार के डेटाबेस सेटअप के लिए एक विशेष समाधान है, जो निश्चितता के उच्च स्तर के लिए कुछ लचीलेपन का त्याग करता है। निष्कर्ष यह है कि जहाँ गति और सुरक्षा दोनों महत्वपूर्ण हैं, जैसे कि वित्तीय लेनदेन, वहाँ एक सावधानीपूर्वक योग्य प्रणाली एक विश्वसनीय शॉर्टकट प्रदान कर सकती है। शोध यह निष्कर्ष निकालता है कि इन शॉर्टकट्स की सुरक्षा पूरी तरह से अवलोकन पथ (observation path) की अखंडता पर निर्भर करती है, जो परिवर्तन किए जाने के क्षण से लेकर उसे देखे जाने के क्षण तक है, और इस पथ को डेटा की तरह ही कठोरता के साथ जांचा जाना चाहिए।