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 ती मानिस र उपकरणहरूका लागि सही रहन्छ जसको स्वीकृत कामले यसलाई आवश्यक ठान्छ। त्यो डिजाइनलाई भूमिका, नेटवर्क दायरा र सञ्चालन सीमाले बाँध्नुहोस्, र बाँकी ग्राहकले साँघुरो इन्टरफेस राखून्। दुई समूहलाई एउटै भूमिकामा मिसाउनु नै बहस सुरु हुने ठाउँ हो।