प्रत्येक उपकरण लॉक आउट न करता VPN पासवर्ड बदला

तीन फोन, एक राउटर आणि एक देखरेख तपासणी अजूनही जुना पासवर्ड धरून आहेत, आणि त्यापैकी एक दर नव्वद सेकंदाला पुन्हा जोडतो। खात्याचा पासवर्ड दहा मिनिटांपूर्वी बदलला, त्यामुळे त्या क्लायंटपैकी प्रत्येकजण आता सर्व्हर नाकारत असलेले मूल्य पाठवत आहे। तोच क्षण मिथकाचा भंग होतो: पासवर्ड बदल खात्याला स्पर्श करतो, प्रत्येक उपकरणावर बसलेल्या जुन्या मूल्याच्या प्रतींना नाही। पुढे जे येते ते त्या बदलाने न केलेले काम आहे।

मिथक: एक बदल, सर्वत्र एकाच वेळी

पासवर्ड बदलल्याने सर्व काही साइन आउट होते आणि स्वच्छ पुन्हा लॉगिन भाग पाडते, अशी धारणा आहे। तसे होत नाही, कारण सर्व्हरने शेवटी कोणते क्रेडेन्शियल स्वीकारले हेच तो पाहतो, तर क्लायंटने साठवलेले ते धरून ठेवतात। साठवलेला पासवर्ड असलेले उपकरण तो स्वतःच्या वेळापत्रकानुसार पुन्हा प्रयत्न करते आणि खाते लॉक झाल्याचे कोणाला लक्षात येईपर्यंत शांतपणे अपयशी होते। प्रती खात्याबाहेर राहतात हे स्वीकारल्यावर, रोटेशन एकच कृती वाटणे थांबते।

यातील काहीही रोटेशनविरुद्ध नाही। हे साठवलेल्या प्रती नंतरचा विचार नव्हे तर बदलाचा भाग मानण्याच्या बाजूने आहे। लॉक आउट सामान्यतः समांतर पुन्हा प्रयत्नांमधून येते: काउंटर चालू होईपर्यंत प्रत्येक उपकरण स्वतःच्या वेळापत्रकानुसार जुने मूल्य पाठवत राहते। मग खात्यावर हल्ला झाल्यासारखे वाटते, पण कोणीही न बदललेली क्रेडेन्शियल्सच दिली जात असतात। हा फरक महत्त्वाचा आहे, कारण उपाय कडक लॉक आउट धोरण नाही, उपकरणांची यादी आहे।

रोटेशनपूर्वी प्रतींची यादी करा

पासवर्ड फॉर्म उघडण्यापूर्वी यादी लिहा। या खात्याप्रमाणे प्रमाणित होणाऱ्या प्रत्येक क्लायंट, स्क्रिप्ट, ऑटोमेशन आणि व्यवस्थापित प्रोफाइलची यादी करा: स्वतः जोडणारा फोन, दोन वर्षांपूर्वी कॉन्फिगर केलेला राउटर, फक्त सोमवारी जागा होणारा लॅपटॉप, आणि दर मिनिटाला प्रयत्न करणारी देखरेख तपासणी। प्रत्येकासाठी क्रेडेन्शियल कुठे साठवले आहे, बदलाच्या वेळी उपकरणापर्यंत पोहोचता येते का, आणि पुन्हा जोडता येत नसेल तर कोणता पुनर्प्राप्ती मार्ग आहे ते नोंदवा। हीच यादी जोखमीचा बदल नियोजित बदलात बदलते, आणि जुना पासवर्ड काम करणे थांबण्यापूर्वी ती असली पाहिजे।

ऑफलाइन उपकरणे ही नेहमीची चूक आहे। ड्रॉवरमधील लॅपटॉप तीन आठवड्यांनंतर परत येतो आणि सर्वात वाईट क्षणी जुने मूल्य सादर करतो। त्याचे स्थान आणि वेळापत्रकही नोंदवा, कारण प्रतीक्षा न करता त्याचा पाठलाग करावा लागेल।

लिनक्स ताफ्यात शोध बुद्धिमान नाही, यांत्रिक आहे। क्रेडेन्शियल फाइलचा संदर्भ देणारी प्रोफाइल शोधा, नंतर क्रेडेन्शियल फाइल्स स्वतः शोधा, कारण दुसरी यादीच पुन्हा लिहायची आहे। डेस्कटॉप क्लायंट आणि फोनसाठीही हा सराव पुन्हा करा, जिथे साठा मार्ग नाही, प्रोफाइल किंवा कीचेन नोंद आहे। उद्दिष्ट अशी यादी आहे ज्यावर काम करता येईल, प्रत्येक प्रत सापडल्याचा दावा करणारे स्कॅन नाही।

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

प्रती त्यांच्या मालकांशी तोलून पाहा। कोणीही दावा न करणारे उपकरण असे उपकरण आहे जे कोणीही अपडेट करणार नाही, आणि पुन्हा प्रयत्न सुरू ठेवण्याची सर्वाधिक शक्यता त्याचीच आहे।

तुम्ही प्रत्यक्षात कोणते रहस्य फिरवत आहात

खाते पासवर्ड हे VPN तैनातीतील फक्त एक क्रेडेन्शियल आहे। की पासफ्रेज, प्रमाणपत्र ओळख आणि ऐच्छिक समवयस्क रहस्य यापैकी प्रत्येकाचा स्वतःचा बदलण्याचा मार्ग आणि स्वतःचा मालक आहे। खाते पासवर्ड बदलल्याने प्रमाणपत्राने प्रमाणित होणाऱ्या उपकरणासाठी काहीही होत नाही, आणि प्रमाणपत्र पुन्हा जारी केल्याने साठवलेला पासवर्ड असलेल्या क्लायंटसाठी काहीही होत नाही। उपायाला नाव देण्यापूर्वी रहस्याला नाव द्या।

रोटेशन धोरणाने नव्हे तर संशयाने चालत असेल, तर घटना प्रक्रिया सोयीच्या योजनेपेक्षा वरचढ आहे। पुरावे जे मागतात ते रद्द करा आणि उपकरण यादीवरील अतिरिक्त काम स्वीकारा। तो निर्णय घटनेच्या मालकाचा आहे, पासवर्ड रीसेट फॉर्म संयोगाने धरलेल्याचा नाही।

साठवलेले मूल्य जिथे राहते तिथेच बदला

सेवा ज्या यंत्रणेचे दस्तऐवजीकरण करते त्याद्वारे क्रेडेन्शियल बदला, नंतर साठवलेली प्रत अपडेट करा किंवा ठेवू इच्छित असलेल्या प्रत्येक उपकरणावर साइन-इन प्रवाह चालवा। ते पुन्हा लिहिणाऱ्या व्यवस्थापकामागील व्युत्पन्न कॉन्फिगरेशन संपादित करू नका, कारण व्यवस्थापक पुढच्या वेळी जुने मूल्य पुनर्संचयित करतो आणि संपादन विलंबित बिघाड बनते। व्यवस्थापक जो स्रोत वाचतो तो अपडेट करा, किंवा क्लायंटचा स्वतःचा क्रेडेन्शियल साठा वापरा। कोणत्याही प्रकारे, उपकरणाकडे क्लायंट प्रत्यक्षात जिथे वाचतो तिथे नवे मूल्य असले पाहिजे।

पासवर्ड फाइल साठवणाऱ्या क्लायंटला फाइल पुन्हा लिहिलेली हवी, तर विचारणाऱ्या क्लायंटला पूर्ण साइन-इन हवे। NetworkManager रहस्य जोडणी प्रोफाइलमध्ये ठेवतो, त्यामुळे बदल टेक्स्ट एडिटरऐवजी nmcli मधून जातो:

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

क्रेडेन्शियल फाइल वाचणारी प्रोफाइल ही तिसरी परिस्थिती आहे। त्या फाइलचा मजकूर बदला, तिच्या परवानग्या बंद ठेवा, आणि तिच्याकडे निर्देश करणारी प्रोफाइल संपादित करण्याऐवजी क्लायंट पुन्हा लोड करा। प्रोफाइल बदलली नाही; फक्त ती जे रहस्य वाचते ते बदलले।

प्रत्येक इच्छित उपकरण एकदा जाणीवपूर्वक पुन्हा जोडा आणि कोणते अपयशी होतात ते पाहा। उपकरण अपयशी होत राहिले, तर पासवर्ड पुन्हा बदलण्यापूर्वी ते ज्या खात्याकडे निर्देश करते आणि जो साठा वाचते तो पाहा, कारण दुसरा बदल अपडेट कराव्या लागणाऱ्या प्रतींचा गुणाकार करतो। दोनदा अपयशी होणारे उपकरण सामान्यतः चुकीच्या खात्याकडे निर्देश करते किंवा तुम्हाला अजून न सापडलेला साठा वाचते। ते दुरुस्त करा, मग पुन्हा जोडा।

सत्रे आणि टोकन पासवर्डपेक्षा जास्त जगतात

पासवर्ड बदलल्याने विद्यमान सत्रे किंवा वेगळी प्रमाणपत्रे रद्द झाली आहेत हे सिद्ध होत नाही। काही सेवा सत्र संपेपर्यंत किंवा स्पष्टपणे बंद होईपर्यंत ते जिवंत ठेवतात, आणि जारी केलेल्या टोकनना स्वतःचे आयुष्य असते। बदल जागतिक होता असे गृहीत धरण्याऐवजी सेवा प्रत्यक्षात काय करते ते तपासा। बदल संशयाने प्रेरित असल्यास सत्रे स्पष्टपणे संपवा आणि निकालाची पुष्टी करा।

NIST SP 800-63B मधील क्रेडेन्शियल जीवनचक्र मार्गदर्शन प्रमाणक आणि सत्रे वेगळ्या श्रेणींमध्ये ठेवते, म्हणूनच पासवर्ड बदल आणि जागतिक लॉगआउट वेगवेगळे ऑपरेशन आहेत। त्यांना दोन पूर्णत्व निकष असलेली दोन कार्ये माना। पहिले नवे मूल्य काम करताच संपते, आणि दुसरे जुनी सत्रे गेल्यावर संपते।

नवीन पासवर्ड नोंदीत न लिहिता पूर्णत्व नोंदवा। क्रेडेन्शियल असलेला रोटेशन लॉग सामायिक ड्राइव्हवर प्रतीक्षेत असलेली नवी घटना आहे। तारीख, अपडेट केलेली उपकरणे आणि अजून बाकी असलेली उपकरणे नोंदवा।