Nebula ब्लॉकलिस्ट: ती वितरित करा, लाइटहाउस ते करणार नाही
ब्लॉकलिस्ट नोंद केवळ ती लोड केलेल्या होस्टवर लागू होते। सूचीच्या वितरणाची CA फिरवण्याशी तुलना करा, नंतर नाकारलेला पीअर आणि कार्यरत पीअर तपासा।
ब्लॉकलिस्टची अंमलबजावणी तपासणी करणाऱ्या होस्टचा गुणधर्म आहे, तपासल्या जात असलेल्या प्रमाणपत्राचा नाही। ज्या मशीनने ती नोंद कधीही लोड केली नाही ती ओळख स्वीकारत राहते, आणि हातमिळवणीत दोन पीअर असहमत आहेत याची कोणतीही सूचना मिळत नाही। एकाच उघड झालेल्या क्रेडेन्शियलसाठी स्वस्त आणि महाग उपाय व्याप्ती आणि उलट करण्याच्या क्षमतेत वेगळे आहेत, म्हणून जाणीवपूर्वक निवडा। खालील विभाग नोंद काय करते, ती कुठे पोहोचवायची, फिरवणे कधी चांगले उत्तर आहे आणि दोन्हीपैकी एक काम करून गेले हे कसे सिद्ध करायचे याचा आढावा घेतात।
ब्लॉकलिस्ट नोंद प्रत्यक्षात काय करते
प्रमाणपत्र वैधरित्या स्वाक्षरीत आणि कालबाह्य नसलेले असूनही होस्टने नाकारले पाहिजे असे बोटांचे ठसे PKI संरचना सूचीबद्ध करते। अंमलबजावणी स्थानिक पातळीवर, सेवा सुरू झाली तेव्हा होस्टने लोड केलेल्या सूचीच्या विरुद्ध होते। नोंदीबद्दल काहीही प्रमाणपत्राच्या आत प्रवास करत नाही, म्हणून पीअरला दाखवलेल्या क्रेडेन्शियलवरून निर्णय कळू शकत नाही। म्हणूनच येथे लाइटहाउसची कोणतीही भूमिका नाही: लाइटहाउस पीअरना एकमेकांना शोधण्यास आणि थेट मार्ग अयशस्वी होतो तिथे रहदारी पुढे पाठवण्यास मदत करतात। ते शोध आणि पुढे पाठवण्याचा स्तर आहेत, संरचना वितरणाचा मार्ग नाही।
एक मशीन अद्ययावत केल्याने त्या मशीनचे निर्णय बदलतात आणि इतर प्रत्येक पीअर अगदी पूर्वीप्रमाणेच राहतो। स्वाक्षरी करणाऱ्या प्राधिकरणावर विश्वास ठेवणाऱ्या आणि नोंद कधीही न पाहिलेल्या पीअरला काहीही नाकारण्याचे कारण नाही। म्हणून लाइटहाउस पाहून रद्दीकरण तपासणे काहीही सिद्ध करत नाही, कारण तुम्ही पाहत असलेल्या घटकाला सूची अंमलात आणण्यास कधीही सांगितले गेले नाही।
प्रमाणपत्र ओळखा, उपकरण नाही
तुम्हाला नाकारायचे असलेल्या क्रेडेन्शियलचा बोटांचा ठसा वापरा, कारण होस्टनाव, उपकरणाचे लेबल किंवा सध्याचा पत्ता आज एका मशीनची ओळख करतो आणि पुढच्या महिन्यात दुसऱ्या गोष्टीची। यापैकी कोणतीही अक्षरमाला ब्लॉकलिस्टमध्ये दिसत नाही आणि यापैकी कोणतीही पुनर्स्थापनेनंतर टिकत नाही। प्रमाणपत्र छापा, बोटांचा ठसा वाचा आणि तो सेवानिवृत्त होत असलेल्या क्रेडेन्शियलचा आहे, त्याच्या बदलीचा नाही याची खात्री करा। बदली आधीच जारी झाली असेल तर दोन्ही फाइली वाचणे महत्त्वाचे आहे, कारण जुने आणि नवीन प्रमाणपत्र नाव सामायिक करू शकतात आणि इतर प्रत्येक क्षेत्रात वेगळे असू शकतात।
कोणता बोटांचा ठसा कधी ब्लॉक झाला ते नोंदवा, जेणेकरून नंतरचे ऑडिट पूर्ण झालेला बदल हेतू असलेल्या बदलापासून वेगळा करू शकेल। नोंद काय करत नाही तेही नोंदवा: ती स्वाक्षरी करणाऱ्या प्राधिकरणाला अवैध करत नाही आणि त्या प्राधिकरणाच्या भविष्यातील प्रमाणपत्राला स्वीकारले जाण्यापासून थांबवत नाही। होस्टचे प्रमाणपत्र ब्लॉक करणे आणि तडजोड झालेले प्राधिकरण बदलणे या वेगवेगळ्या परिणामांसह वेगवेगळ्या क्रिया आहेत।
nebula-cert print -path /etc/nebula/host.crt
pki:
blocklist:
- "a1b2c3d4e5f6"इतर कोणत्याही संरचनेप्रमाणे ती वितरित करा
सूचीला कोणी आठवल्यावर संपादित करणारी फाइल म्हणून नाही, तर वितरण यंत्रणा असलेली संरचना म्हणून पहा। डेल्टाऐवजी पूर्ण सूची पाठवा, जेणेकरून पूर्वीचे अद्ययावतन चुकलेला होस्ट अंतर साचवण्याऐवजी एकवटेल। Nebula PKI दस्तऐवज नेमके हेच सुचवतो, आणि सल्ला हाताने करण्याच्या प्रक्रियेत रूपांतरित करण्याऐवजी शब्दशः पाळणे योग्य आहे।
चालू सेवेने सामग्री पुन्हा लोड केली याची खात्री करा, केवळ डिस्कवरील फाइल बदलली एवढेच नाही। कोणत्या मशीननी बदल लागू केला याचा मागोवा घ्या आणि उर्वरित सूची रिकामी होईपर्यंत दृश्य ठेवा। आठवडाभर बंद लॅपटॉप हा निर्णय कधीही न शिकलेला पीअर आहे, आणि कोणीही अपेक्षा न केलेल्या नेटवर्कवरून तो पुन्हा जोडला जाऊ शकतो। बोटांच्या ठशाच्या शेजारी वितरण पद्धत नोंदवा, कारण पुढील रद्दीकरण तीच पुन्हा वापरेल आणि पहिल्यावरच प्रक्रियेचे दोषमुक्तीकरण होते।
ब्लॉकलिस्ट की प्राधिकरण फिरवणे
ब्लॉकलिस्ट नोंद अरुंद आहे: एक ओळख काम करणे थांबवते आणि बाकी सर्व सुरू राहते। स्वाक्षरी करणाऱ्या प्राधिकरणाला फिरवणे रुंद आहे: त्याने जारी केलेले प्रत्येक प्रमाणपत्र अविश्वासार्ह होते आणि प्रत्येक होस्टला नवीन क्रेडेन्शियल व नवीन विश्वासाचा आधार हवा असतो। पहिले लक्ष्यित रद्दीकरण आहे आणि दुसरे स्थलांतर, म्हणून त्यांना वेगवेगळ्या मंजुऱ्या आणि वेगवेगळ्या देखभाल कालावधी लागतात। तक्ता दोन्हींना व्याप्ती, श्रम आणि उलट करण्याच्या क्षमतेवर शेजारी शेजारी ठेवतो।
| Question | Blocklist entry | Authority rotation |
|---|---|---|
| What stops working | One identity | Every certificate from that authority |
| Fleet work | Push one file and confirm a reload | New credentials and a new trust anchor everywhere |
| Reversible | Yes, remove the line | No, the old authority stays distrusted |
| Fits | A lost or stolen device | A leaked authority key |
हरवलेल्या लॅपटॉपसाठी ब्लॉकलिस्ट योग्य आहे, कारण नुकसानाची त्रिज्या एक ओळख आहे आणि चुकीचा बोटांचा ठसा ब्लॉक केला असेल तर बदल उलट करता येतो। गळलेल्या प्राधिकरणाच्या कीसाठी फिरवणे आवश्यक आहे, कारण अजून जारी न झालेल्या प्रमाणपत्रांमध्ये ब्लॉकलिस्ट मदत करू शकत नाही। या टोकांमध्ये, उघड झालेल्या क्रेडेन्शियलने दुसरे काही स्वाक्षरीत करू शकले असते का विचारा, कारण प्राधिकरण एका होस्टपेक्षा मोठे आहे।
घटनेपूर्वी निर्णय लिहून ठेवा, कारण दबावाखाली निवड केल्यास डीफॉल्टने रुंद पर्याय मिळतो। तुम्ही कोणताही मार्ग घ्या, उरलेले काम समान आहे: महत्त्वाच्या होस्टवर अंमलबजावणी झाली हे सिद्ध करणे। त्याच क्षणी बोटांचा ठसा आणि तारीख नोंदवणे हेच नंतर पुरावा शक्य करते।
नकार आणि उर्वरित तपासा
ब्लॉक केलेल्या ओळखीतून जोडा आणि अपयशाची खात्री करा, नंतर अधिकृत पीअरमधून जोडा आणि तो अजूनही आवश्यक तेथे पोहोचतो याची खात्री करा। सर्वांना तोडणारा बदल यशस्वी रद्दीकरण नाही। दोन्ही नवीन सत्रांमधून करा, कारण कॅशे केलेली स्थिती निकाल लपवू शकते।
बदलानंतर प्रस्थापित सत्र संपते का ते तपासा, आणि फाइल संपादित केल्याने काही थांबते असे गृहीत धरण्याऐवजी तुमच्या आवृत्ती व संरचनेसाठी वर्तन नोंदवा। disconnect_invalid पर्याय कालबाह्य किंवा अवैध प्रमाणपत्र असलेल्या क्लायंटना समाविष्ट करतो, म्हणून त्यावर अवलंबून राहण्यापूर्वी तो तुमच्या प्रकरणाला कसा लागू होतो याची खात्री करा। तात्काळ समाप्ती आवश्यकता असेल तर ती विशेषतः तपासा आणि तुम्ही काय पाहिले ते नोंदवा। नंतर पुनर्प्रारंभानंतर चाचणी पुन्हा करा, कारण सूची पुढील रीबूटपर्यंतच लागू करणाऱ्या होस्टमध्ये पहिल्या चाचणीने लपवलेली वितरण समस्या असते। निरोगी लाइटहाउस शोध काम करतो असे सांगतो, कोणत्या पीअरने धोरण लागू केले हे नाही।