A चयनकर्ता मॉनिटर आपको बता सकता है कि सत्यापन डेटा बदल गया है या गायब हो गया है। यह स्थापित नहीं कर सकता कि कोई सेवा अभी भी भेज रही है, कि उसकी निजी कुंजी प्रकाशित कुंजी से मेल खाती है, या उसके संदेश संरेखित के साथ आते हैं DKIM. प्रकाशित कॉन्फ़िगरेशन और देखे गए संदेश व्यवहार के लिए अलग-अलग जाँच बनाएँ।
ज्ञात प्रेषण मार्गों से प्रारंभ करें
अधिकृत प्रेषक कॉन्फ़िगरेशन और प्रतिनिधि द्वारा प्राप्त संदेशों से एक सूची बनाएं। प्रत्येक रूट के लिए व्यवसाय स्वामी, डी डोमेन, चयनकर्ता, DNS स्वामी, अपेक्षित TXT या रिकॉर्ड करें CNAME व्यवस्था, अंतिम बार देखे गए हस्ताक्षर का समय और जीवनचक्र स्थिति। यह न मानें कि अनुमान लगाने वाले सामान्य चयनकर्ता प्रत्येक हस्ताक्षरकर्ता को खोज लेते हैं। DKIM संपूर्ण DNS गणना सेवा को परिभाषित करने के बजाय प्रत्येक हस्ताक्षर में चयनकर्ता प्रदान करता है।
s=invoice2 और d=brand.example, invoice2._domainkey.brand.example का निरीक्षण करें RFC 6376 §3.6.2.1. इसके सत्यापन डेटा के लिए अपेक्षित CNAME अनुसरण करें। एक अवलोकन टाइमस्टैम्प और एक सार्वजनिक-कुंजी फ़िंगरप्रिंट संग्रहीत करें ताकि किसी परिवर्तन की तुलना स्वीकृत रोटेशन से की जा सके। निगरानी प्रणाली में कभी भी निजी कुंजियाँ एकत्रित न करें।
मॉनिटर के निष्कर्षों को अलग करें
एक अनुपलब्ध उत्तर, DNS टाइमआउट, निरस्त कुंजी और परिवर्तित कुंजी अलग-अलग घटनाएं हैं। RFC 6376 §6.1.2 कुंजी-क्वेरी विफलता को अनुपस्थित कुंजी से अलग करता है, और एक खाली पी मान निरस्तीकरण का प्रतिनिधित्व करता है RFC 6376 §3.6.1. प्रत्येक त्रुटि को सामान्य आउटेज में बदलने के बजाय प्रतिक्रिया विवरण रिकॉर्ड करें।
वर्तमान कुंजी को अभी भी सिंटैक्स और एल्गोरिदम जांच की आवश्यकता है। RFC 8301 §3.1 आरएसए-एसएचए1 पर हस्ताक्षर और सत्यापन को प्रतिबंधित करता है; RFC 8301 §3.2 अद्यतन आरएसए आकार की आवश्यकताएँ: हस्ताक्षरकर्ताओं को कम से कम 1024 बिट्स का उपयोग करना चाहिए और कम से कम 2048 का उपयोग करना चाहिए। उत्पाद समर्थन और वर्तमान संगठनात्मक क्रिप्टोग्राफ़िक नीति सख्त हो सकती है। अकेले फिंगरप्रिंट परिवर्तन आपको यह नहीं बता सकता कि रोटेशन अधिकृत था या नहीं।
एक लाइव साक्ष्य लूप जोड़ें
प्रत्येक महत्वपूर्ण उत्पादन मार्ग के माध्यम से नियंत्रित संदेशों को एक मेलबॉक्स पर भेजें जिसका कच्चा संदेश और विश्वसनीय प्रमाणीकरण परिणाम आप निरीक्षण कर सकते हैं। देखे गए डी और एस, सत्यापन परिणाम और रिकॉर्ड करें संरेखण से के साथ. उन संदेश प्रकारों का उपयोग करें जो डाउनस्ट्रीम प्रसंस्करण को प्रभावित कर सकते हैं, जैसे HTML और अनुलग्नक।
उदाहरणात्मक मॉनिटर: DNS इनवॉइस2 प्रस्तुत करना जारी रखता है, लेकिन एक ताज़ा संदेश में कोई नहीं है DKIM-Signature. प्रकाशन चेक पास हो जाता है जबकि हस्ताक्षर चेक विफल हो जाता है। दूसरे मामले में, हस्ताक्षर मौजूद है लेकिन यह है बॉडी हैश गेटवे फ़ूटर परिवर्तन के बाद विफल हो जाता है। DNS रिकॉर्ड को स्वस्थ घोषित करने से किसी भी घटना का समाधान नहीं होता है। ये सिंथेटिक परीक्षण मामले हैं, मापी गई सेवा घटनाएं नहीं।
सिंथेटिक परीक्षणों की भी सीमाएँ हैं। एक दैनिक जांच पारित जांच के बीच हर संदेश को साबित नहीं करती है। रिपोर्टिंग कवरेज और देरी को स्वीकार करते हुए इसे प्राप्तकर्ता रिपोर्ट और घटना साक्ष्य के साथ मिलाएं।
कार्रवाई योग्य अलर्ट रूट करें
किसी मार्ग और स्वामी के लिए अलर्ट संलग्न करें. केवल स्पष्ट रूप से अनुमोदित रखरखाव विंडो को दबाएं, घटना इतिहास को संरक्षित करें और रोटेशन के बाद नए हस्ताक्षरकर्ता की नए मेल से पुष्टि करें। अकेले परिवर्तन से समझौता किए बिना अप्रत्याशित प्रमुख परिवर्तनों को संभावित सुरक्षा घटनाओं के रूप में बढ़ाएं।
पुरानी इन्वेंट्री पंक्तियों को जानबूझकर रिटायर करें। एक पुरानी सार्वजनिक कुंजी विलंबित-संदेश सत्यापन के लिए तब भी बनी रह सकती है जब नए हस्ताक्षर बंद हो गए हों। उस नियोजित राज्य को एक परित्यक्त प्रतिनिधिमंडल से अलग करें। डैशबोर्ड को यह बताना चाहिए कि क्या देखा गया, कब और किस विधि से देखा गया, ताकि DNS स्वास्थ्य कभी भी लाइव हस्ताक्षर के प्रमाण के रूप में सामने न आए।
चेतावनी निर्णय पुन: प्रस्तुत करें
चेतावनी परतों को अलग रखने के लिए चार सिंथेटिक जांच का उपयोग करें। d=brand.example और s=invoice2 के साथ एक हस्ताक्षर invoice2._domainkey.brand.example को मैप करता है। यदि इसकी सार्वजनिक कुंजी मौजूद है, लेकिन आपूर्ति किए गए रिसीवर का परिणाम बॉडी-हैश विफलता है, तो संदेश-सत्यापन चेतावनी जारी करें। यदि इसकी कुंजी अनुपस्थित है, तो कुंजी-अनुपस्थिति चेतावनी जारी करें। यदि अपेक्षित रिकॉर्ड मौजूद है लेकिन संदेश पर कोई हस्ताक्षर नहीं है, तो हस्ताक्षर न होने की चेतावनी जारी करें। एक वर्तमान कुंजी और एक आपूर्ति किया गया उत्तीर्ण परिणाम अकेले उस जांच के लिए कोई चेतावनी नहीं देता है।
ये चार निर्णय आविष्कृत DNS स्थितियों और आपूर्ति किए गए रिसीवर परिणामों के साथ एक उदाहरणात्मक निर्णय मॉडल हैं। इस समीक्षा के लिए कोई लाइव DNS क्वेरी, हस्ताक्षर परीक्षण या क्रिप्टोग्राफ़िक सत्यापन नहीं किया गया था। मॉनिटर को चालू करने के लिए, उन्हें दिनांकित सार्वजनिक उत्तरों और आपके विश्वसनीय प्राप्त सीमा से परिणाम वाले कच्चे संदेशों से बदलें। किसी मार्ग को परिचालनात्मक रूप से सत्यापित बताने से पहले उस जुड़े हुए साक्ष्य को सुरक्षित रखें।
अगले फैसले के लिए सबूत जरूरी
बॉडी-हैश अलर्ट के लिए, आपूर्ति किए गए परिणाम को सुरक्षित रखें और बॉडी प्रतिनिधित्व, सी/एल सेटिंग्स, बीएच मान और कार्यान्वयन व्यवहार की जांच करें; अकेले बेमेल होने से गेटवे संशोधित सामग्री साबित नहीं होती है। बिना किसी नई जांच वाले मार्ग को अवलोकित के रूप में चिह्नित करें, भले ही उसकी कुंजी मौजूद हो। अलग से रिकॉर्ड करें कि क्या संरेखण की जाँच की गई थी, क्योंकि अकेले DKIM पास संरेखित पास नहीं है।