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 प्लगइन और उस विशिष्ट सत्र को शुरू करने की अनुमति चाहिए। यह हर सबनेट में प्रवेश का मार्ग नहीं है, और यह टनल की तरह मनमाने प्रोटोकॉल नहीं ले जाएगा।
किसी भी स्थिति में डेटाबेस की अपनी पहचान अपनी जगह रखें। TLS सत्यापन और डेटाबेस प्रमाणीकरण इसलिए नहीं गायब होते कि मार्ग को IAM द्वारा अधिकृत किया गया, और स्वीकृत सत्र इस बारे में कुछ नहीं कहता कि उपयोगकर्ता कौन-सी तालिकाएँ पढ़ सकता है।
दायरे और जीवनचक्र के आधार पर चुनें: टनल तब जब कई उपयोगकर्ताओं को कई गंतव्य चाहिए और आप प्रमाणपत्र या निर्देशिका जीवनचक्र चला सकते हैं; फ़ॉरवर्डिंग सत्र तब जब कुछ लोगों को एक सेवा चाहिए और आप नेटवर्क पते बाँटना नहीं चाहते। किसी भी स्थिति में, प्रमाणीकरण विधि, प्राधिकरण नियम और डेटाबेस लॉगिन को तीन अलग तथ्यों के रूप में दर्ज करें, क्योंकि वे अलग-अलग विफल होते हैं।