AWS Client VPN: क्लाइंट प्रमाणपत्र कौन सा CA जारी करे?
मौजूदा CA, स्व-संचालित जारीकर्ता और AWS Private CA काम को अलग-अलग बाँटते हैं। शुरू करने से पहले तय करें कि क्लाइंट प्रमाणपत्रों को कौन स्वीकृत, नवीनीकृत और निरस्त करता है।
AWS Client VPN पर प्रमाणपत्र का सवाल उत्पाद का सवाल बनाकर पूछा जाता है, जबकि यह वास्तव में संचालन का सवाल है। तीन सामान्य सेटअप में से कोई भी काम करती टनल बनाए रखेगा: मौजूदा संगठनात्मक CA, समर्पित स्व-संचालित जारीकर्ता, या AWS Private CA। ये इस बात में अलग हैं कि डिवाइस कौन स्वीकृत करता है, साइनिंग कुंजी किसके पास रहती है, और असुविधाजनक घड़ी में लैपटॉप खो जाने पर जवाब कौन देता है। वह विकल्प चुनें जिसके मालिक का नाम आप बता सकें।
AWS प्रमाणपत्र-आधारित प्रमाणीकरण के लिए Private CA अनिवार्य नहीं करता। ACM में सर्वर प्रमाणपत्र रखना परिनियोजन का चरण है, नामांकन प्रक्रिया नहीं।
तीन शर्तें जो इसे तय करती हैं
तीन शर्तें विकल्पों को साफ़ अलग करती हैं: क्या पहले से स्वीकृत डिवाइस-नामांकन प्रक्रिया मौजूद है, क्या आप बैकअप और नामित मालिक के साथ साइनिंग कुंजी चला सकते हैं, और निरसन एंडपॉइंट तक कैसे पहुँचता है। हर शर्त हाँ या ना के करीब है, और पहला ना आमतौर पर आर्किटेक्चर तय कर देता है।
इन्हें क्रम से देखें। सीधे लागत तुलना पर कूदना वह तरीका है जिससे टीमें प्रबंधित CA के साथ रह जाती हैं और किसी को पता नहीं होता कि अगला लैपटॉप प्रमाणपत्र कौन जारी करेगा।
| Option | You still own | Fits when |
|---|---|---|
| Existing organizational CA | Enrollment, approvals, revocation list | A device process already exists |
| Self-run issuer | Signing-key custody, backups, revocation list | You can staff key custody |
| AWS Private CA | Policy, permissions, certificate delivery | Your PKI already lives in AWS |
पहली शर्त: क्या नामांकन पहले से है?
अगर आपका संगठन पहले से स्वीकृत डिवाइस-नामांकन मार्ग वाला CA चलाता है, तो उससे Client VPN क्लाइंट प्रमाणपत्र जारी करना सबसे छोटा रास्ता है। स्वीकृतियाँ, प्रक्रिया और संपत्ति रिकॉर्ड पहले से वहाँ हैं। उस पदानुक्रम के अंतर्गत समर्पित अधीनस्थ जारीकर्ता आम तौर पर सामान्य-उद्देश्य वाले जारीकर्ता CA से बेहतर होता है, क्योंकि यह VPN को अपनी विश्वास-सीमा और अपनी निरसन सूची देता है। उस सूची को पदानुक्रम के बाकी हिस्से से अलग रखें ताकि कोई VPN घटना पूरे PKI में बदलाव न थोपे।
अगर ऐसी प्रक्रिया नहीं है, तो असली सवाल यह है कि क्या आप एक बनाना चाहते हैं। CA शुरू करना आसान है और बुरी तरह रखरखाव करना महंगा।
दूसरी शर्त: क्या आप साइनिंग कुंजी चला सकते हैं?
स्व-संचालित जारीकर्ता प्रलेखित आयात मॉडल के साथ काम करता है, और EasyRSA या कोई छोटा आंतरिक उपकरण सामग्री बना सकता है। कमांड चलाना मुश्किल हिस्सा नहीं है। मुश्किल हिस्सा है साइनिंग कुंजी के ऑफ़लाइन बैकअप, कोई ऐसा रिकवरी मार्ग जिसे किसी ने वास्तव में जाँचा हो, ऐसा मालिक जो छुट्टी पर न हो, और यह नियम कि कुंजी कभी क्लाइंट बंडल या कॉन्फ़िगरेशन निर्यात में न पहुँचे। पहला प्रमाणपत्र जारी होने से पहले इसे प्रक्रिया के रूप में लिखें, पहली घटना के बाद नहीं।
AWS Private CA उस अभिरक्षा को प्रबंधित सेवा में ले जाता है। यह नामांकन नीति, स्वीकृति चरण या डिवाइस तक प्रमाणपत्र की डिलीवरी नहीं ले जाता।
तीसरी शर्त: निरसन कैसे आता है?
Client VPN क्लाइंट-प्रमाणपत्र निरसन सूची का उपभोग करता है जिसे आप एंडपॉइंट में आयात करते हैं, जैसा प्रमाणपत्र जीवनचक्र मार्गदर्शिका में वर्णित है। आपके PKI में कहीं और CRL प्रकाशित करना उसे सेवा में नहीं धकेलता। आयात एक अलग, निर्धारित कार्रवाई है, और समाप्त सूची चुपचाप कमज़ोर होने के बजाय कनेक्शन रोक देती है। नवीनीकरण को उन्हीं प्रमाणपत्रों के कैलेंडर पर रखें।
इससे नवीनीकरण मालिक वाला निगरानी मद बन जाता है, लॉन्च पर खत्म होने वाला काम नहीं। तंत्र की वास्तव में ज़रूरत पड़ने से पहले एक परीक्षण प्रमाणपत्र शुरू से अंत तक निरस्त करें।
जो कोई विकल्प नहीं हटाता
हर विकल्प को अब भी हर स्वतंत्र रूप से प्रबंधित डिवाइस के लिए एक अलग क्लाइंट प्रमाणपत्र और कुंजी चाहिए। जो ट्यूटोरियल सबको एक ही पहचान देता है वह ट्यूटोरियल की शॉर्टकट है, और यह चुनिंदा निरसन भी असंभव बना देता है।
ACM में आयातित सर्वर प्रमाणपत्रों में प्रबंधित नवीनीकरण नहीं है, इसलिए मालिक को प्रतिस्थापन लाना, उसे फिर से आयात करना और फिर पुष्टि करनी होती है कि एंडपॉइंट ने उसे अपना लिया। सर्वर प्रमाणपत्र का नवीनीकरण लैपटॉप पर पहले से मौजूद क्लाइंट क्रेडेंशियल का नवीनीकरण नहीं करता। ये अलग कैलेंडर वाले अलग जीवनचक्र हैं।
कुछ भी जारी करने से पहले जाँचें कि सेवा कौन-से कुंजी प्रकार और एक्सटेंशन स्वीकार करती है। CA का कोई एल्गोरिद्म समर्थन करना यह नहीं दर्शाता कि एंडपॉइंट उसे स्वीकार करेगा।
लॉन्च से पहले अपने चुने हुए वर्कफ़्लो से एक नवीनीकरण और एक क्लाइंट हटाना चलाएँ, और लिखें कि कौन-सा क्रेडेंशियल बदला, कौन-सी एंडपॉइंट सेटिंग बदली और सक्रिय सत्र के साथ क्या हुआ। अगर वह अभ्यास स्पष्ट मालिक के बिना खत्म होता है, तो जारीकर्ता का चुनाव पूरा नहीं हुआ।