AWS Client VPN वरील प्रमाणपत्राचा प्रश्न उत्पादनाचा प्रश्न म्हणून विचारला जातो, पण प्रत्यक्षात तो कार्यचालनाचा प्रश्न आहे. नेहमीच्या तीन संरचनांपैकी कोणतीही कार्यरत टनेल टिकवेल: विद्यमान संस्थात्मक CA, समर्पित स्वयं-चालित जारीकर्ता, किंवा AWS Private CA. ते उपकरण कोण मंजूर करते, सही की कोणाकडे असते आणि गैरसोयीच्या वेळी लॅपटॉप हरवल्यास कोण उत्तर देते यात भिन्न आहेत. ज्याचा मालक तुम्ही नावाने सांगू शकता तो पर्याय निवडा.

AWS प्रमाणपत्र-आधारित प्रमाणीकरणासाठी Private CA अनिवार्य करत नाही. ACM मध्ये सर्व्हर प्रमाणपत्र ठेवणे हे तैनातीचे पाऊल आहे, नोंदणी प्रक्रिया नाही.

निर्णय देणाऱ्या तीन अटी

तीन अटी पर्याय स्पष्टपणे वेगळे करतात: मंजूर उपकरण-नोंदणी प्रक्रिया आधीच आहे का, बॅकअप आणि नामनिर्देशित मालकासह सही की चालवू शकता का, आणि रद्दीकरण अंतिम बिंदूपर्यंत कसे पोहोचते. प्रत्येक होय किंवा नाहीच्या जवळ आहे, आणि पहिले नाही सहसा स्थापत्य ठरवते.

ते क्रमाने पाहा. थेट खर्चाच्या तुलनेकडे उडी मारणे म्हणजे संघ व्यवस्थापित CA सह राहतात आणि पुढील लॅपटॉप प्रमाणपत्र कोण जारी करेल हे कोणालाही माहीत नसते.

OptionYou still ownFits when
Existing organizational CAEnrollment, approvals, revocation listA device process already exists
Self-run issuerSigning-key custody, backups, revocation listYou can staff key custody
AWS Private CAPolicy, permissions, certificate deliveryYour PKI already lives in AWS

पहिली अट: नोंदणी आधीच आहे का?

तुमची संस्था आधीच मंजूर उपकरण-नोंदणी मार्ग असलेला CA चालवत असेल, तर तिथून Client VPN क्लायंट प्रमाणपत्रे जारी करणे हा सर्वात लहान मार्ग आहे. मंजुरी, प्रक्रिया आणि मालमत्ता नोंदी आधीच तिथे आहेत. त्या श्रेणीखालील समर्पित अधीनस्थ जारीकर्ता सामान्य उद्देशाच्या जारीकर्ता CA पेक्षा सहसा चांगला असतो, कारण तो VPN ला स्वतःची विश्वास सीमा आणि स्वतःची रद्दीकरण सूची देतो. ती सूची श्रेणीच्या उर्वरित भागापासून वेगळी ठेवा, जेणेकरून VPN घटना संपूर्ण PKI मध्ये बदल लादणार नाही.

अशी प्रक्रिया नसल्यास, खरा प्रश्न असा आहे की तुम्हाला ती तयार करायची आहे का. CA सुरू करणे सोपे आणि वाईटरीत्या धारण करणे महाग आहे.

दुसरी अट: तुम्ही सही की चालवू शकता का?

स्वयं-चालित जारीकर्ता दस्तऐवजीकृत आयात मॉडेलसह कार्य करतो, आणि EasyRSA किंवा लहान अंतर्गत साधन साहित्य तयार करू शकते. आदेश चालवणे हा कठीण भाग नाही. कठीण भाग म्हणजे सही कीचे ऑफलाइन बॅकअप, कोणीतरी प्रत्यक्ष तपासलेला पुनर्प्राप्ती मार्ग, सुट्टीवर नसलेला मालक, आणि की कधीही क्लायंट बंडल किंवा संरचना निर्यातीत जाऊ नये हा नियम. पहिले प्रमाणपत्र जारी होण्यापूर्वी हे प्रक्रिया म्हणून लिहा, पहिल्या घटनेनंतर नाही.

AWS Private CA ती जपणूक व्यवस्थापित सेवेत हलवते. ते नोंदणी धोरण, मंजुरीचे पाऊल किंवा उपकरणापर्यंत प्रमाणपत्र पोहोचवणे हलवत नाही.

तिसरी अट: रद्दीकरण कसे येते?

Client VPN तुम्ही अंतिम बिंदूमध्ये आयात करता ती क्लायंट-प्रमाणपत्र रद्दीकरण सूची वापरते, प्रमाणपत्र जीवनचक्र मार्गदर्शकात वर्णन केल्याप्रमाणे. तुमच्या PKI मध्ये दुसरीकडे CRL प्रकाशित करणे ते सेवेत ढकलत नाही. आयात ही स्वतंत्र, नियोजित क्रिया आहे, आणि मुदत संपलेली सूची शांतपणे कमजोर होण्याऐवजी कनेक्शन थांबवते. नूतनीकरण प्रमाणपत्रांच्याच दिनदर्शिकेत ठेवा.

यामुळे नूतनीकरण मालक असलेली देखरेख बाब बनते, सुरुवातीला संपणारे काम नाही. यंत्रणा खरोखर आवश्यक होण्यापूर्वी एक चाचणी प्रमाणपत्र सुरुवातीपासून शेवटपर्यंत रद्द करा.

कोणताही पर्याय जे काढून टाकत नाही

प्रत्येक पर्यायाला अजूनही प्रत्येक स्वतंत्रपणे व्यवस्थापित उपकरणासाठी स्वतंत्र क्लायंट प्रमाणपत्र आणि की आवश्यक आहे. सर्वांना एकच ओळख देणारे प्रशिक्षण म्हणजे प्रशिक्षणाचा शॉर्टकट, आणि ते निवडक रद्दीकरणही अशक्य करते.

ACM मध्ये आयात केलेल्या सर्व्हर प्रमाणपत्रांना व्यवस्थापित नूतनीकरण नाही, म्हणून मालकाला बदली मिळवावी लागते, ती पुन्हा आयात करावी लागते आणि नंतर अंतिम बिंदूने ती स्वीकारली याची पुष्टी करावी लागते. सर्व्हर प्रमाणपत्राचे नूतनीकरण लॅपटॉपवर आधीच असलेल्या क्लायंट ओळखपत्रांचे नूतनीकरण करत नाही. हे वेगळ्या दिनदर्शिका असलेले वेगळे जीवनचक्र आहेत.

काहीही जारी करण्यापूर्वी सेवा कोणत्या की प्रकार आणि विस्तार स्वीकारते ते तपासा. CA एखादा अल्गोरिदम समर्थित करते याचा अर्थ अंतिम बिंदू तो स्वीकारेल असा नाही.

सुरुवातीपूर्वी तुम्ही निवडलेल्या कार्यप्रवाहातून एक नूतनीकरण आणि एक क्लायंट काढणे चालवा, आणि कोणते ओळखपत्र बदलले, कोणती अंतिम बिंदू सेटिंग बदलली आणि सक्रिय सत्राला काय झाले ते लिहा. तो सराव स्पष्ट मालकाशिवाय संपला तर जारीकर्त्याची निवड पूर्ण झालेली नाही.

संबंधित लेख