TLS, नेटवर्क प्रवेश और SQL विशेषाधिकार अलग-अलग प्रश्नों का उत्तर देते हैं
कनेक्शन एन्क्रिप्ट करना, किसी स्रोत को अनुमति देना और तालिका देना तीन निर्णय हैं। TLS क्या VPN की जगह ले सकता है, यह पूछने से पहले इन्हें क्रम से देखें।
कोई व्यक्ति ग्राहक को PostgreSQL लॉगिन देने का सुझाव देता है ताकि व्यय दावा शुरू से अंत तक एन्क्रिप्ट होकर जाए। डेटाबेस प्रशासक को वास्तविक SQL सत्र चाहिए, और कोई दूसरा इसके बजाय वेब फ़ॉर्म का सुझाव देता है। दोनों सुझाव गलत समस्या हल करते हैं, क्योंकि इनमें से कोई भी उस क्रिया से शुरू नहीं हुआ जो ग्राहक वास्तव में करता है। तीनों निर्णय क्रम से देखें और TLS क्या VPN की जगह ले सकता है, यह प्रश्न स्वयं उत्तर दे देगा।
उस क्रिया से शुरू करें जो ग्राहक को चाहिए
लिखें कि ग्राहक को क्या हासिल करना है। दावा जमा करना, रिपोर्ट की एक पंक्ति पढ़ना और तत्काल क्वेरी चलाना तीन अलग क्रियाएँ हैं जिनके तीन अलग जोखिम प्रोफ़ाइल हैं।
फिर लिखें कि अनुरोध कौन कर रहा है। ग्राहक, सहायता एजेंट और प्रशासक एक ही तालिका छूने पर भी एक-दूसरे के स्थान पर नहीं आ सकते। यही अंतर तय करता है कि ग्राहक को क्वेरी भाषा का कितना हिस्सा कभी देखना चाहिए।
उत्तरों की जोड़ी इंटरफ़ेस तय करती है। इसके बाद सब कुछ कार्यान्वयन है, और एन्क्रिप्शन पर अधिकांश बहस वास्तव में इस बात की बहस है कि कौन-सा इंटरफ़ेस चुना गया।
तीन नियंत्रण, तीन निर्णय
प्रमाणित TLS कनेक्शन की रक्षा करता है और तय करता है कि कौन-सी TLS पहचान स्वीकार की जाएँगी। नेटवर्क प्रवेश तय करता है कि कौन-से स्रोत सुनने वाले तक पहुँच सकते हैं। डेटाबेस प्राधिकरण तय करता है कि कोई भूमिका किन वस्तुओं और क्रियाओं का उपयोग कर सकती है।
तीनों में से कोई भी दूसरों का स्थान नहीं लेता, जो तालिका स्पष्ट करती है।
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
दूसरी पंक्ति हटाने से पहले उस पंक्ति को पढ़ें जिस पर आप निर्भर हैं। इनमें से अधिकांश डिज़ाइन इसलिए विफल होते हैं क्योंकि किसी नियंत्रण को कॉन्फ़िगर करने के बजाय मान लिया गया था।
सीधा SQL डेटाबेस नीति को उत्तरदायी रखता है
स्वीकृत सीधे कनेक्शन के साथ सेवा पहचान का सत्यापन और इच्छित प्रवेश नीति दोनों रखें। TLS चालू करने से एन्क्रिप्टेड कनेक्शन उपलब्ध होते हैं; यह अनएन्क्रिप्टेड कनेक्शन को अस्वीकार नहीं करता जब तक प्रवेश कॉन्फ़िगरेशन hostssl प्रविष्टियों के माध्यम से ऐसा न कहे।
यह अंतर टेम्पलेट में नहीं, चल रहे कॉन्फ़िगरेशन में जाँचने योग्य है। TLS देने वाला और सादा पाठ स्वीकार करने वाला सर्वर वह डिज़ाइन नहीं है जिसे अधिकांश लोग तैनात मानते हैं। प्रवेश नियम पढ़ें और देखें कि कौन-सी प्रविष्टियाँ वास्तव में इसकी मांग करती हैं। यही एक जाँच एन्क्रिप्शन-सक्षम सर्वर को केवल-एन्क्रिप्टेड सर्वर से अलग करती है।
केवल वे भूमिकाएँ उपयोग करें जिनमें काम के लिए आवश्यक विशेषाधिकार हों, और स्वामित्व, विरासत में मिली सदस्यता तथा व्यापक रूप से दी गई अनुमतियों की समीक्षा करें। PostgreSQL विशेषाधिकार मॉडल डेटाबेस वस्तुओं के लिए अधिकार की सीमा है।
VPN यह सीमित कर सकता है कि डेटाबेस प्रमाणीकरण से पहले कौन-से उपकरण सेवा तक पहुँचें, और प्रवेश गेटवे भी कुछ ऐसा कर सकता है। दोनों में से कोई भी उजागर घटक के रखरखाव, क्रेडेंशियल प्रबंधन और संसाधन उपयोग सीमित करने की आवश्यकता नहीं हटाता।
क्लाइंट प्रमाणपत्र एक क्रेडेंशियल है, ACL नहीं
क्लाइंट प्रमाणपत्र कनेक्शन के समय एक शर्त जोड़ सकता है। clientcert सेटिंग विश्वसनीय प्रमाणपत्र और कठोर मोड में प्रमाणपत्र के नाम और डेटाबेस उपयोगकर्ता के बीच संबंध मांग सकती है।
वह अधिक मजबूत क्रेडेंशियल है। वह प्राधिकरण सूची नहीं है, और वह सर्वर को अदृश्य नहीं बनाता, क्योंकि कनेक्शन स्वीकार करने वाला घटक अभी भी नेटवर्क ट्रैफ़िक और हैंडशेक संसाधित करता है। प्रमाणपत्र को प्रवेश सूची मानने से वास्तविक अनुमतियाँ अछूती रहती हैं। यह प्रमाणपत्र वितरण को चौड़ा करने की प्रवृत्ति भी रखता है, जो अगली समस्या पैदा करता है।
अत्यधिक विशेषाधिकार वाली भूमिका से जुड़ा मजबूत प्रमाणपत्र अच्छी तरह प्रमाणित प्रशासक बनाता है। प्रमाणपत्र का उत्सव मनाने से पहले भूमिका जाँचें।
जब उपयुक्त हो तो संकीर्ण इंटरफ़ेस चुनें
व्यय दावे के लिए, वह एप्लिकेशन एंडपॉइंट जो दावा स्वीकार करता है, व्यावसायिक नियम लागू करता है और उस उपयोगकर्ता का अनुमत परिणाम लौटाता है, सामान्य SQL खाते की तुलना में क्रिया को बेहतर ढंग से निरूपित करता है।
फिर एप्लिकेशन अपनी प्रतिबंधित डेटाबेस पहचान उपयोग करता है, और ग्राहक को कभी सुविधा के रूप में क्वेरी भाषा नहीं मिलती। यह छोटी सतह है जिसमें गलत होने के कम रास्ते हैं।
यह डिज़ाइन विकल्प है, यह दावा नहीं कि एप्लिकेशन कोड स्वतः अधिक सुरक्षित है। उस कोड को अपने कॉलर का प्रमाणन करना, हर क्रिया को अधिकृत करना और अपने इनपुट को सत्यापित करना होता है, और उसकी अपनी डेटाबेस अनुमतियाँ अब भी मायने रखती हैं।
सीधा SQL उन लोगों और उपकरणों के लिए सही रहता है जिनके स्वीकृत कार्य को इसकी आवश्यकता होती है। उस डिज़ाइन को भूमिकाओं, नेटवर्क दायरे और परिचालन सीमाओं से बाँधें, और बाकी क्लाइंट संकीर्ण इंटरफ़ेस रखें। दोनों आबादियों को एक भूमिका में मिलाना ही वह जगह है जहाँ बहस शुरू होती है।