AWS Client VPN प्रमाणीकरण: IAM परवानग्या लॉगिन पद्धत नाहीत
कन्सोल परवानग्या टनेलचे प्रमाणीकरण करत नाहीत. प्रमाणपत्र, AD आणि SAML पद्धतींची तुलना करा, नंतर SSM पोर्ट फॉरवर्डिंग एका खाजगी डेटाबेससाठी कधी योग्य आहे ते पहा.
वापरकर्त्याला AWS Client VPN एंडपॉइंट तयार करण्याची किंवा वर्णन करण्याची परवानगी देणे त्याला त्याला जोडण्याची परवानगी देत नाही. हे दोन वेगळ्या प्रकारचे ओळखपत्र आहेत: IAM AWS API कॉल नियंत्रित करते, आणि एंडपॉइंट फक्त त्यावर कॉन्फिगर केलेल्या क्लायंट प्रमाणीकरण पद्धती स्वीकारतो. त्यामुळे वापरकर्त्याकडे व्यापक कन्सोल अधिकार असू शकतात आणि तरीही VPN क्लायंटकडे सादर करण्यासारखे काही नसू शकते. एंडपॉइंट कोणत्या पद्धतीवर विश्वास ठेवतो हे ठरवा, नंतर तुम्ही देत असलेल्या प्रवेशासाठी पूर्ण टनेल योग्य आकार आहे का ते ठरवा.
API ओळख ही टनेल ओळख नाही
जेव्हा कोणी म्हणतो «IAM भूमिका जोडलेली आहे, तरी VPN का अयशस्वी होते», तेव्हा उत्तर सहसा असे असते की कनेक्शन प्रवाहातील कोणतेही पाऊल ती भूमिका कधीही वाचत नाही. क्लायंट प्रमाणपत्र, AD वापरकर्तानाव आणि संकेतशब्द, किंवा SAML दावा सादर करतो. एंडपॉइंट त्यापैकी एकाची पडताळणी करतो आणि नंतर पत्ता नियुक्त करतो.
IAM अजूनही महत्त्वाचे आहे, फक्त नंतर आणि दुसरीकडे: एंडपॉइंट तयार करणे, सबनेट जोडणे, मार्ग प्रकाशित करणे आणि अधिकृतता नियम लिहिणे या API क्रिया आहेत. त्या परवानग्या ज्यांना आवश्यक आहेत अशा ऑपरेटरपुरत्या मर्यादित ठेवा, प्रत्येक वापरकर्त्याला एंडपॉइंटचे प्रवेश नियम पुन्हा लिहिण्याची क्षमता देण्याऐवजी.
एंडपॉइंट ज्या पद्धतींना समर्थन देतो त्यातून निवडा
AWS Client VPN प्रमाणपत्र-आधारित परस्पर प्रमाणीकरण, Active Directory प्रमाणीकरण आणि SAML-आधारित संघीय प्रमाणीकरण स्वीकारते. तुम्ही कोणतीही क्लायंट पद्धत निवडली तरी सर्व्हर प्रमाणपत्र आवश्यक आहे, आणि पद्धती एकत्र करणाऱ्या कॉन्फिगरेशनमध्ये दोन्ही यशस्वी होणे आवश्यक आहे, एक नाही.
| Client method | What the user presents | Where the work sits |
|---|---|---|
| Mutual certificate | A client certificate the endpoint trusts | Certificate authority, issuing and revoking per user |
| Active Directory | Domain credentials | Directory reachable from the endpoint's VPC |
| SAML federation | An assertion from an identity provider | IdP application, attribute mapping, client support |
प्रमाणपत्रे स्थापित करण्यास सर्वात स्वस्त आणि मोठ्या प्रमाणात चुकण्यास सर्वात सोपी आहेत, कारण प्रत्येक वापरकर्त्याला क्रेडेन्शियल आवश्यक आहे आणि प्रत्येक निर्गमनासाठी रद्द करणे आवश्यक आहे. डिरेक्टरी प्रमाणीकरण ते जीवनचक्र विद्यमान प्रणालीत हलवते. संघ ते ओळख प्रदात्याकडे हलवते आणि क्लायंटमध्ये ब्राउझर पाऊल जोडते.
क्लायंट डीबग करण्यापूर्वी एंडपॉइंटचे स्वतःचे कॉन्फिगरेशन वाचा. वापरकर्ता-आधारित पद्धतीसोबत परस्पर प्रमाणीकरण सक्रिय असल्यास, वैध प्रमाणपत्र असलेला पण डिरेक्टरी खाते नसलेला क्लायंट तरीही अयशस्वी होईल, आणि त्रुटी सहसा सामान्य हँडशेक समस्येसारखी दिसते.
संघ म्हणजे प्रवेश की हस्तांतरित करणे नाही
SAML सेटअप IAM प्रवेश की किंवा गृहीत भूमिकेचे टोकन टनेलमध्ये टाकत नाही. ओळख प्रदाता व्यक्तीचे प्रमाणीकरण करतो, दावा परत करतो, आणि एंडपॉइंट तुम्ही कॉन्फिगर केलेल्या विश्वासाच्या अंतर्गत तो स्वीकारतो. परिणामी सत्र VPN सत्र आहे, AWS API सत्र नाही.
हा फरक ठरवतो की कोण काय निदान करू शकतो. IdP समस्या कोणत्याही टनेलच्या अस्तित्वापूर्वी ब्राउझर किंवा क्लायंट त्रुटी म्हणून दिसतात, तर टनेल समस्या यशस्वी दाव्यानंतर दिसतात. कोणतेही कन्सोल उघडण्यापूर्वी तुम्ही यापैकी कोणते पाहत आहात ते विचारा.
लॉगिननंतरही मार्ग आणि अधिकृतता ठरवतात
प्रमाणीकरण सत्राला पत्ता देते; ते सत्राला गंतव्य देत नाही. एंडपॉइंट मार्ग क्लायंटला कोणत्या सबनेटवर पाठवायचे ते सांगतात, अधिकृतता नियम ठरवतात की कोणते वापरकर्ते त्या सबनेटपैकी कोणत्या सबनेटपर्यंत पोहोचू शकतात, आणि सुरक्षा गट तसेच लक्ष्याच्या स्वतःच्या परवानग्या उर्वरित ठरवतात.
म्हणूनच यशस्वीरित्या प्रमाणित झालेला वापरकर्ता तरीही डेटाबेसपर्यंत पोहोचण्यात अयशस्वी होऊ शकतो. सबनेटसाठी मार्ग तक्त्याची संलग्नता, वापरकर्त्याच्या गटासाठी अधिकृतता नियम आणि लक्ष्यावरील सुरक्षा गट या क्रमाने तपासा, कारण प्रत्येकजण वेगळ्या प्रकारची मुदतसंप्ती निर्माण करतो.
एका खाजगी डेटाबेससाठी, पोर्ट फॉरवर्डिंगशी तुलना करा
जर खरे काम एका खाजगी डेटाबेसशी एक मंजूर कनेक्शन असेल, तर पूर्ण नेटवर्क टनेल आवश्यकता नाही, निवड आहे. AWS Systems Manager Session Manager IAM द्वारे व्यवस्थापित नोडवर पोर्ट फॉरवर्डिंग सत्र उघडू शकते, आणि तो नोड खाजगी नेटवर्कवरील डेटाबेसपर्यंत पोहोचतो. वापरकर्त्याला कधीही VPC पत्ता मिळत नाही. व्यवस्थापित नोड हाच डेटाबेस पोर्टपर्यंत पोहोचू शकणारा एकमेव होस्ट बनतो, आणि सुरक्षा पुनरावलोकन सहसा हेच मागत असे. नंतर वापरकर्त्यांना VPN प्रोफाइलऐवजी स्थानिक क्लायंट आणि सत्र आदेश आवश्यक असतो.
व्यवहार व्याप्ती विरुद्ध पूर्वअटी आहे. पोर्ट फॉरवर्डिंगसाठी व्यवस्थापित नोडवर SSM एजंट, त्या नोडपासून डेटाबेसपर्यंत नेटवर्क पोहोच, वापरकर्त्याच्या मशीनवर Session Manager प्लगइन आणि ते विशिष्ट सत्र सुरू करण्याची परवानगी आवश्यक आहे. हा प्रत्येक सबनेटमध्ये प्रवेशाचा मार्ग नाही, आणि तो टनेलप्रमाणे अनियंत्रित प्रोटोकॉल वाहून नेणार नाही.
कोणत्याही परिस्थितीत डेटाबेसची स्वतःची ओळख तिच्या जागी ठेवा. मार्ग IAM द्वारे अधिकृत झाला म्हणून TLS पडताळणी आणि डेटाबेस प्रमाणीकरण नाहीसे होत नाही, आणि मंजूर सत्र वापरकर्ता कोणते तक्ते वाचू शकतो याबद्दल काहीही सांगत नाही.
व्याप्ती आणि जीवनचक्रानुसार निवडा: अनेक वापरकर्त्यांना अनेक गंतव्ये आवश्यक असतील आणि तुम्ही प्रमाणपत्र किंवा डिरेक्टरी जीवनचक्र चालवू शकत असाल तर टनेल; काही लोकांना एक सेवा आवश्यक असेल आणि तुम्ही नेटवर्क पत्ते वाटप करू इच्छित नसाल तर फॉरवर्डिंग सत्र. कोणत्याही परिस्थितीत, प्रमाणीकरण पद्धत, अधिकृतता नियम आणि डेटाबेस लॉगिन तीन स्वतंत्र तथ्ये म्हणून नोंदवा, कारण ते स्वतंत्रपणे अयशस्वी होतात.