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 ज्यांच्या मंजूर कामासाठी ते आवश्यक आहे अशा लोकांसाठी आणि साधनांसाठी योग्य राहते। त्या रचनेला भूमिका, नेटवर्क व्याप्ती आणि कार्यवाही मर्यादांनी बांधून ठेवा, आणि उर्वरित क्लायंटनी अरुंद इंटरफेस ठेवावा। दोन्ही गट एका भूमिकेत मिसळणे हेच वाद सुरू होण्याचे ठिकाण आहे।