A DKIM निजी कुंजी हस्ताक्षर बनाने का अधिकार है जो मेल खाने वाले सार्वजनिक रिकॉर्ड के विरुद्ध सत्यापित कर सकता है। केवल DNS रिकॉर्ड की सुरक्षा करना उस प्राधिकरण की सुरक्षा नहीं करता है। हस्ताक्षर प्रणालियों की सूची, वे खाते जो उनका उपयोग कर सकते हैं और कुंजी तय करने से पहले रहस्य की प्रत्येक परिचालन प्रति को नियंत्रित किया जाता है।
हिरासत को मानने के बजाय उसकी पहचान करें
वास्तविक प्रदाता या हस्ताक्षरित सॉफ़्टवेयर से प्रारंभ करें। एक प्रबंधित सेवा कुंजियाँ उत्पन्न और बनाए रख सकती है; एक स्व-संचालित हस्ताक्षरकर्ता किसी फ़ाइल, गुप्त स्टोर या समर्थित हार्डवेयर-समर्थित इंटरफ़ेस को पढ़ सकता है। इन मॉडलों में अलग-अलग पहुंच और पुनर्प्राप्ति नियंत्रण हैं। हार्डवेयर सुरक्षा, गैर-निर्यात योग्यता या ग्राहक-प्रबंधित रोटेशन का वादा न करें जब तक कि चुने गए उत्पाद का दस्तावेजीकरण और कार्यान्वयन न हो।
RFC 6376 §8.3 निजी-कुंजी समझौते के परिणाम की व्याख्या करता है: एक घुसपैठिया उस डोमेन द्वारा हस्ताक्षरित मेल बना सकता है जो संबंधित सार्वजनिक कुंजी प्रकाशित करता है। यह एक नियंत्रित आउटगोइंग मेल सर्वर के मूल्य का भी वर्णन करता है जो सबमिटर्स को प्रमाणित करता है और भेजने पर नियंत्रण लागू करता है। नीचे दिए गए विशिष्ट भंडारण और समीक्षा चरण परिचालन अनुशंसाएं हैं, सार्वभौमिक DKIM प्रोटोकॉल आवश्यकताएं नहीं।
एक हिरासत मानचित्र बनाएं जो छिपी हुई प्रतियों को उजागर करे
प्रत्येक के लिए चयनकर्ता, हस्ताक्षर करने वाले डोमेन, सेवा स्वामी, कुंजी संरक्षक, सक्रिय हस्ताक्षर नोड्स, परिनियोजन पथ और समर्थित पुनर्प्राप्ति तंत्र को रिकॉर्ड करें। रहस्य के संदर्भ या पहचानकर्ता को ट्रैक करें, रहस्य को नहीं। संगठन की अनुमोदित गुप्त-हैंडलिंग प्रक्रिया के माध्यम से अनपेक्षित प्रतियों के लिए कॉन्फ़िगरेशन रिपॉजिटरी, कंटेनर निर्माण चरण, अस्थायी परिनियोजन फ़ाइलें, बैकअप और डायग्नोस्टिक बंडल की समीक्षा करें।
एक सिंथेटिक उदाहरण एक बिलिंग क्लस्टर है जिसमें दो हस्ताक्षर नोड्स और एक तैनाती कार्य है। DNS कुंजी सार्वजनिक और अपेक्षित है। निजी कुंजी का उद्देश्य केवल दो नोड्स तक पहुंचना है, लेकिन एक पुरानी बिल्ड पाइपलाइन इसे असंबंधित परियोजनाओं के लिए सुलभ छवि में भी एम्बेड करती है। वर्तमान नोड फ़ाइल अनुमतियों को सुरक्षित करने से वह पुराना एक्सपोज़र नहीं हटेगा। वितरण पथ की जांच करें और घटना प्रक्रिया के अनुसार संभावित रूप से उजागर रहस्य का इलाज करें।
सार्वजनिक DNS फ़ील्ड, टिकट, चैट या सार्वजनिक DKIM चेकर में कभी भी निजी कुंजी न चिपकाएँ। जब समर्थन को साक्ष्य की आवश्यकता हो, तो सार्वजनिक चयनकर्ता को जानकारी और उपयुक्त रूप से नियंत्रित निदान परिणाम प्रदान करें। कच्चे संदेशों में संवेदनशील सामग्री भी हो सकती है; जो साझा किया जाता है उसे कम करें और स्वीकृत चैनलों का उपयोग करें।
कम करें कि कौन हस्ताक्षर कर सकता है और कौन रहस्य प्राप्त कर सकता है
प्रशासन और रनटाइम पहुंच दोनों के लिए प्लेटफ़ॉर्म के समर्थित न्यूनतम-विशेषाधिकार नियंत्रण का उपयोग करें। एक खाता जो हस्ताक्षर का अनुरोध कर सकता है वह शक्तिशाली हो सकता है, भले ही वह कुंजी निर्यात न कर सके। समीक्षा करें कि भेजने की अनुमति वाली पहचान को कौन बदल सकता है, मेल सबमिट कर सकता है, कुंजियाँ घुमा सकता है, हस्ताक्षरकर्ता कॉन्फ़िगरेशन तैनात कर सकता है और बैकअप पुनर्प्राप्त कर सकता है।
विभिन्न स्वामियों या विश्वास स्तरों के साथ अलग-अलग सेवाएँ जहाँ आर्किटेक्चर स्वतंत्र कुंजी और चयनकर्ताओं का समर्थन करता है। प्रत्येक एप्लिकेशन में एक कुंजी कॉपी करने से किसी घटना का दायरा कठिन हो जाता है और सेवानिवृत्ति अधिक विघटनकारी हो जाती है। उच्च उपलब्धता के लिए वैध रूप से एक साझा हस्ताक्षर पहचान की आवश्यकता हो सकती है, लेकिन यह कॉपी की गई कॉन्फ़िगरेशन फ़ाइल के आकस्मिक परिणाम के बजाय नियंत्रित वितरण के साथ एक स्पष्ट डिज़ाइन होना चाहिए।
रहस्य को उजागर किए बिना पुनर्प्राप्ति का परीक्षण करें
पूछें कि क्या संरक्षित कुंजी को पुनर्स्थापित करके, प्रतिस्थापन उत्पन्न करके या प्रदाता के प्रबंधित पुनर्प्राप्ति पथ का उपयोग करके आउटेज पुनर्प्राप्त किया गया है। नियंत्रित वातावरण में समर्थित प्रक्रिया का परीक्षण करें। पुनर्प्राप्ति समय, DNS निर्भरताएँ रिकॉर्ड करें और क्या कतारबद्ध मेल अभी भी पुराने चयनकर्ता का उपयोग करता है। केवल कार्य को आसान बनाने के लिए अतिरिक्त असुरक्षित बैकअप प्रतियां न बनाएं।
हस्ताक्षर मंच और गुप्त-प्रबंधन प्रणाली से उपलब्ध लॉग और एक्सेस इवेंट की समीक्षा करें। उपयोगी प्रश्न यह है कि क्या किसी अनधिकृत परिवर्तन या उपयोग का पता लगाया जा सकता है और उसकी जांच की जा सकती है, न कि कोई विशेष डैशबोर्ड मौजूद है या नहीं। ऑडिट ट्रेल का आविष्कार करने के बजाय दस्तावेज़ लॉगिंग अंतराल।
एक क्रियाशील जीवनचक्र रिकॉर्ड के साथ समाप्त करें
हिरासत मानचित्र को रोटेशन और समझौता प्रक्रियाओं के बगल में रखें। कर्मचारियों या विक्रेताओं के चले जाने पर अप्रचलित पहुंच को हटा दें और बुनियादी ढांचे में बदलाव के बाद वितरण की दोबारा जांच करें। एक संदिग्ध जोखिम के दौरान, पहुंच रोकथाम, एक स्वच्छ प्रतिस्थापन और पुरानी-कुंजी सेवानिवृत्ति के सत्यापन परिणामों का समन्वय करें। एक संरक्षित वर्तमान फ़ाइल नियंत्रित हस्ताक्षर जीवनचक्र का केवल एक हिस्सा है।
हिरासत निर्णय वर्कशीट का उपयोग करें
प्रत्येक हस्ताक्षरित पहचान के लिए, इन गैर-गुप्त फ़ील्ड को रिकॉर्ड करें:
- उपयोग करें: कौन से सेवा खाते हस्ताक्षर प्रस्तुत या अनुरोध कर सकते हैं, और वे कौन सी पहचान का उपयोग कर सकते हैं।
- पुनर्प्राप्ति: कौन सी भूमिकाएँ निजी कुंजी को निर्यात या पुनर्स्थापित कर सकती हैं, और स्वीकृत प्रतियां कहाँ रहती हैं।
- परिवर्तन: हस्ताक्षरकर्ता कॉन्फ़िगरेशन, अनुमत पहचान या परिनियोजन कलाकृतियों को कौन बदल सकता है।
- पुनर्प्राप्ति: क्या समर्थित पथ एक संरक्षित कुंजी को पुनर्स्थापित करता है या DNS और कतारबद्ध-मेल निर्भरता के साथ प्रतिस्थापन उत्पन्न करता है।
- साक्ष्य: उपलब्ध पहुंच/हस्ताक्षर लॉग, कोई कवरेज अंतराल और समीक्षा के लिए जिम्मेदार मालिक।
यदि किसी पुराने बिल्ड आर्टिफैक्ट में एक उजागर कुंजी है, तो केवल लाइव नोड को सुरक्षित करना अपर्याप्त है: पुराने एक्सपोज़र को सीमित करें और घटना प्रक्रियाओं के तहत स्वच्छ प्रतिस्थापन पर निर्णय लें। यह वर्कशीट संपादकीय सुरक्षा मार्गदर्शन है, यह दावा नहीं है कि कोई विशेष प्लेटफ़ॉर्म इन नियंत्रणों की आपूर्ति करता है।
संबंधित पढ़ना
DKIM कुंजी को निरस्त करें और निरस्तीकरण को गुम DNS रिकॉर्ड से अलग करें · DKIM कुंजी लंबाई और एल्गोरिदम: वर्तमान रिसीवर समर्थन की जाँच करें.