सेवा खात्याचा VPN प्रवेश: प्रमाणपत्र की सामायिक लॉगिन
देखरेख नसलेल्या VPN प्रवेशासाठी मशीन प्रमाणपत्राची साठवलेल्या पासवर्डशी तुलना करा, आणि लॉगिननंतर चालणाऱ्या धोरणात खरी परवानगी मर्यादा ठेवा।
जवळपास प्रत्येक देखरेख नसलेल्या VPN सेटअपला दोन रचना व्यापतात: स्क्रिप्टमध्ये ठेवलेले सामायिक मानवी लॉगिन, किंवा होस्टशी बांधलेले मशीन प्रमाणपत्र। त्या वेगवेगळ्या ठिकाणी अयशस्वी होतात, आणि ते सेटअपच्या वेगापेक्षा अधिक महत्त्वाचे आहे। साठवलेला पासवर्ड त्याचा मालक तो बदलतो किंवा निघून जातो तेव्हा तुटतो; प्रमाणपत्र त्याची मुदत संपते तेव्हा किंवा कीशिवाय होस्ट पुन्हा बांधला जातो तेव्हा तुटते। तुम्ही कोणता खर्च पेलू शकता हे तीन अटी ठरवतात, आणि अनुमती धोरण तसे करेपर्यंत कोणतीही रचना काहीही मर्यादित करत नाही।
खात्यापासून नाही, कामापासून सुरुवात करा
काम मर्यादा ठरवते: कोणती गंतव्ये, कोणत्या सेवा, कोणत्या वेळा, सत्र किती काळ चालू शकते। बोगदा मार्ग त्या मर्यादेचा फक्त अर्धा आहे। गेटवे सत्राला परवानगी आहे का हे ठरवते; त्यामागील संसाधन सत्र काय करू शकते हे ठरवते। आधी यादी लिहा, नाव दिलेल्या मालकासह, कारण दोन्ही ओळख-रचनांनी ती पूर्ण करायची आहे।
ते लिहिताना प्रमाणीकरण आणि अनुमती वेगळे ठेवा। प्रमाणीकरण कोण जोडतो याचे उत्तर देते; अनुमती सत्र नंतर कुठपर्यंत पोहोचू शकते याचे उत्तर देते। RADIUS दुसरा भाग Filter-Id, Framed-IP-Address, Session-Timeout आणि Class यांसारख्या गुणधर्मांनी वाहतो, आणि लॉगिन यशस्वी होताच गेटवे ते जोडतो। लॉगिन बदलून अनुमतीला स्पर्श न करणाऱ्या रचनेने काहीही मर्यादित केले नाही।
सामायिक मानवी लॉगिन: पासवर्डच मर्यादा होतो
मानवी खाते पुन्हा वापरणे हा सर्वात वेगवान मार्ग आणि सर्वात वाईटपणे जुना होणारा मार्ग। ओळखपत्र पासवर्ड आहे, म्हणून तो स्क्रिप्ट, पर्यावरण फाइल आणि शेड्युलर कॉन्फिगमध्ये जातो, आणि प्रत्येक प्रतीला फिरती लागते। मालक त्याला शुक्रवारी बदलतो तेव्हा पुढील फेरीत काम अयशस्वी होते आणि कोणी पाहत नाही।
MFA ही ती जागा आहे जिथे ही रचना सहसा कोसळते। स्क्रिप्ट पुश विनंतीला उत्तर देऊ शकत नाही, म्हणून खाते धोरणातून वगळले जाते, आणि तेच ते खाते आहे जे हल्लेखोर निवडेल। अपवाद, विश्वासार्ह स्थानाचे बायपास आणि खात्यानुसार सवलती वाढतात, आणि भाडेकरूची सेटिंग्ज वाचणाऱ्या पुढील व्यक्तीला त्यापैकी एकही दिसत नाही।
श्रेय हा दुसरा खर्च आहे। गेटवे लॉगमधील प्रत्येक सत्र समान वापरकर्तानाव वाहते, म्हणून रात्रीच्या सिंकची ते लिहिणाऱ्या व्यक्तीच्या कामापासून वेगळी ओळख करता येत नाही, आणि काम मागे घेणे म्हणजे ती व्यक्ती मागे घेणे।
मशीन प्रमाणपत्र: होस्टशी बांधलेली ओळख
प्रमाणपत्र प्रश्न खात्याला काय माहीत आहे यावरून होस्ट काय आहे याकडे बदलते। EAP-TLS मध्ये क्लायंट प्रमाणपत्र सादर करतो आणि जुळणाऱ्या खाजगी कीचा ताबा सिद्ध करतो; धोरण सर्व्हर विषय किंवा संगणक खाते गटात मॅप करतो आणि त्या गटासाठी धोरण लागू करतो। विनंती नाही, मजकूर फाइलमध्ये बसलेले सामायिक रहस्य नाही।
ते तयार करणारी मर्यादा लोक अपेक्षित असलेल्यापेक्षा अरुंद आहे। प्रमाणपत्र होस्टचे प्रमाणीकरण करते, कामाचे नाही, आणि root किंवा स्थानिक प्रशासक अधिकार असलेला कोणीही त्या होस्टवर ती की वापरू शकतो। की तिथे ठेवा जिथे प्लॅटफॉर्म तिचे संरक्षण करते: Windows प्रमाणपत्र साठवणीत निर्यात न करता येणारी, प्रोफाइल परवानगी देत असेल तिथे TPM-आधारित, किंवा Linux वर root-मालकीची 0600 फाइल। होस्टची तडजोड म्हणजे ओळखपत्राची तडजोड।
मुदत संपणे हे वारंवार होणारे अपयश आहे। रविवारी मुदत संपणारे प्रमाणपत्र रविवारी काम थांबवते, आणि गेटवे सहसा तारीख न सांगता सामान्य प्रमाणीकरण अपयश नोंदवते। कामाच्या होस्टवरून तारखा runbook चा भाग म्हणून तपासा:
openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcertsमागे घेण्यासाठी गेटवे तपासतो असा मार्ग लागतो। OpenVPN crl-verify पर्यायाने CRL वाचते, आणि strongSwan कनेक्शन प्रोफाइल कसे बांधले आहे यावर CRL किंवा OCSP वर अवलंबून असते। दोन्ही जोडलेले नसल्यास होस्ट काढणे म्हणजे प्रमाणपत्राची मुदत संपण्याची वाट पाहणे।
त्यांच्यातील फरक ठरवणाऱ्या तीन अटी
तुलना तुमच्याकडील प्लॅटफॉर्मशी करा, संदर्भ रचनेशी नाही।
पहिली अट: गेटवे मशीन ओळखीला अनुमती देऊ शकतो का? जर तो फक्त RADIUS वापरकर्तानाव निर्देशिका वापरकर्त्याशी मॅप करत असेल, तर प्रमाणपत्र होस्टचे प्रमाणीकरण करते आणि नंतर अनुमतीवर अडकते। दुसरी अट: कामाला फक्त वापरकर्ता खाते वाहते अशा संसाधनाचा प्रवेश हवा आहे का, जसे मॅप केलेला शेअर किंवा प्रति-आसन परवाना? मग मशीन ओळख त्याची जागा घेऊ शकत नाही, आणि प्रामाणिक उत्तर मर्यादित धोरणासह समर्पित वापरकर्ता खाते आहे। तिसरी अट: चक्रात माणूस नसताना ओळखपत्र कोण फिरवू शकतो? स्वयंचलित नोंदणी प्रमाणपत्रे ठेवणे स्वस्त करते; एका व्यक्तीला माहीत असलेला पासवर्ड नाही।
| Constraint | Machine certificate | Dedicated user account with stored secret |
|---|---|---|
| Unattended login | Private key proof, no prompt | Only if the account is exempted from MFA |
| Resource expects a user identity | Works only when the resource accepts computer accounts | Matches the access a person would have |
| Rotation | Re-enrollment, often automated | Secret change plus redeploy of every copy |
| Revocation speed | Tied to CRL or OCSP refresh | Disable the account, immediate |
तक्ता क्रमवारी नाही, खर्चांची यादी म्हणून वाचा। साठवलेल्या रहस्याचा स्तंभ मागे घेण्याच्या वेगात आणि फक्त वापरकर्ता खाती समजणाऱ्या संसाधनांशी सुसंगतीत जिंकतो; प्रमाणपत्राचा स्तंभ फिरतीत आणि स्क्रिप्ट चालण्यासाठी MFA कमकुवत न करण्यात जिंकतो।
मर्यादा धोरणात ठेवा, प्रमाणीकरणानंतर
तुम्ही कोणतीही ओळख निवडा, परवानगीची मर्यादा प्रमाणीकरणानंतर चालणाऱ्या धोरणाची आहे। NPS मध्ये नेटवर्क धोरणे क्रमाने मूल्यांकन केली जातात आणि प्रत्येक अटीशी जुळणारे पहिले धोरण त्याची सेटिंग्ज लागू करते, म्हणून अरुंद धोरणाच्या वर ठेवलेले रुंद धोरण क्लायंट काहीही सादर करो, निकाल ठरवते। Microsoft अट आणि सेटिंगचे मॉडेल त्याच्या NPS धोरण विहंगावलोकनात।
कामाला स्वतःचा गट किंवा धोरण अट द्या, मशीन ओळख वाहते अशा एखाद्या गोष्टीवर आधारित: प्रमाणपत्र टेम्पलेट, कॉलिंग स्टेशन ओळखक, किंवा समर्पित पूलमधील पत्ता। नंतर गुणधर्मांनी सत्र मर्यादित करा: तुमचा गेटवे ज्या भूमिकेत ते मॅप करतो त्यासाठी Filter-Id, अडकलेले काम दिवसांनुसार सत्र धरून न ठेवता पुन्हा प्रमाणीकरण करण्यासाठी लहान Session-Timeout, आणि दुसऱ्या बाजूला तुम्ही फायरवॉल लावता अशा पूलमधून Framed-IP-Address। अनुप्रयोग अनुमती वेगळी राहते: डेटाबेस सर्व्हरकडे जाणारा बोगदा त्यातील तक्ता वाचण्याची परवानगी नाही।
नकार तपासा, नंतर काढण्याची योजना करा
जो प्रवेश चालतो तो किमान विशेषाधिकाराबद्दल काहीही सिद्ध करत नाही। त्याऐवजी नकार तपासा: कामाच्या ओळखीने जोडा आणि यादीबाहेरील गंतव्यापर्यंत पोहोचण्याचा प्रयत्न करा, गेटवेने फक्त एकाला परवानगी द्यायची असेल तर दुसरे समांतर सत्र उघडा, आणि ओळखपत्र मागे घेतल्यानंतर लॉगिन पुन्हा करा।
नंतर तेच सत्र दोन ठिकाणी पुष्टी करा। गेटवे लॉग प्रमाणीकृत ओळख दाखवतो; धोरण सर्व्हरचा लॉग कोणते धोरण जुळले आणि कोणते गुणधर्म परत केले ते दाखवतो। OpenVPN मध्ये सर्व्हर प्रमाणपत्राचे सामान्य नाव नोंदवतो, आणि strongSwan मधील ipsec statusall वापरात असलेल्या ओळखीसह प्रस्थापित बोगदा छापते। दोन्ही लॉग ओळखीबाबत सहमत नसतील, तर धोरण तुम्ही गृहीत धरता त्यापेक्षा वेगळ्या गोष्टीशी जुळत आहे।
काढणे ही रचनेचा भाग आहे, स्वच्छता स्प्रिंटचा नाही। जे काही हटवायचे आहे ते सर्व लिहा (प्रमाणपत्र किंवा खाते, गट सदस्यत्व, नेटवर्क धोरण, पूल नोंद, लक्ष्यावरील फायरवॉल नियम) आणि काम पुन्हा बांधणे सोपे असताना ते एकदा चालवा।
आज सुरुवात करत असाल, तर या क्रमाने काम करा: स्रोत यादी लिहा, तीन अटींनी ओळख निवडा, धोरणात मर्यादा ठेवा, आणि काम सुरू होण्यापूर्वी एक नकाराचा सराव करा।