उपडोमेन अधिग्रहण और विरासत में मिला ईमेल विश्वास

जोखिम का नाम बताने से पहले निर्भरता का नक्शा तैयार करें

एक पुराना DNS संदर्भ एक ऐसी सेवा की ओर इशारा करते हुए एक उपडोमेन छोड़ सकता है जिसे संगठन अब नियंत्रित नहीं करता है। कोई अन्य पक्ष उस सेवा का दावा कर सकता है या नहीं, यह प्रदाता के आवंटन और डोमेन-सत्यापन नियमों पर निर्भर करता है। यहां तक ​​कि जब कोई टेकओवर एक्सपोज़र मौजूद होता है, तो परिणामी प्राधिकरण मूल संगठन के लिए सभी ईमेल पर स्वचालित रूप से नियंत्रण नहीं रखता है। एक उपयोगी जांच सटीक रिकॉर्ड, बाहरी निर्भरता और विश्वास संबंधों को मैप करती है जो एक्सपोज़र क्या सक्षम कर सकता है यह तय करने से पहले इसका उपभोग करता है।

Microsoft का Azure उपडोमेन-अधिग्रहण मार्गदर्शन का वर्णन करता है लटकता हुआ DNS संदर्भ, प्रदाता-विशिष्ट सुरक्षा और सफ़ाई। यह पुरानी निर्भरताओं की जांच का समर्थन करता है, न कि यह मानकर कि प्रत्येक अनसुलझा है CNAME शोषण योग्य है. यह आलेख केवल रक्षात्मक समीक्षा और परिवर्तन योजना का प्रस्ताव करता है। कोई तृतीय-पक्ष संसाधन पंजीकृत नहीं किया गया था, किसी नाम का दावा नहीं किया गया था, कोई DNS रिकॉर्ड नहीं बदला गया था और कोई परीक्षण संदेश नहीं भेजा गया था।

संदर्भ, प्रत्यायोजन और वास्तविक नियंत्रण में अंतर करें

RFC 1035 CNAME और को परिभाषित करता है एनएस रिकार्ड प्रारूप। एक CNAME एक विशेष DNS नाम को दूसरे नाम की ओर इंगित करता है; यह अपने आप में पूरे क्षेत्र का प्रतिनिधिमंडल नहीं है। चाइल्ड-ज़ोन प्रतिनिधिमंडल का एक अलग दायरा होता है क्योंकि प्रत्यायोजित सर्वर उस क्षेत्र के भीतर नामों के लिए उत्तर दे सकते हैं। एक पुराना वेब-होस्टिंग संदर्भ, एक प्रत्यायोजित विपणन उपडोमेन और एक DKIM चयनकर्ता इसलिए आपूर्तिकर्ता की ओर इशारा करते हुए अलग-अलग निर्भरता मानचित्रों की आवश्यकता होती है। उन सभी को "डोमेन पर कब्ज़ा कर लिया गया" मानने से निवारण के लिए आवश्यक जानकारी खारिज हो जाती है।

सटीक मालिक का नाम, प्रकार, मूल्य, क्षेत्र और आधिकारिक ऑपरेटर की सूची बनाएं। लक्ष्य को नियंत्रित करने के लिए अपेक्षित सेवा खाते या आपूर्तिकर्ता और उस संबंध के साक्ष्य को रिकॉर्ड करें। अनुपलब्ध लक्ष्य समाधान या सेवा स्थिति के बारे में एक अवलोकन है, यह प्रमाण नहीं है कि यह किसी अन्य ग्राहक के दावे के लिए उपलब्ध है। प्रदाता आरक्षण, सत्यापन टोकन और जीवनचक्र प्रतिबंध उस निष्कर्ष को बदल सकते हैं। जोखिम प्रदर्शित करने के लिए संसाधन दावे का प्रयास किए बिना वर्तमान दस्तावेज़ और अधिकृत स्वामित्व रिकॉर्ड की जाँच करें।

वेब नियंत्रण को ईमेल प्राधिकरण से अलग करें

किसी वेब एंडपॉइंट का नियंत्रण उस नाम पर परोसी जाने वाली सामग्री और उस पर भरोसा करने वाले किसी भी एप्लिकेशन को प्रभावित कर सकता है। यह आवश्यक रूप से मूल डोमेन को बदलने की अनुमति नहीं देता है SPF, मनमाना प्रकाशन DKIM चाबियाँ या इसके मेलबॉक्स का संचालन। इसके विपरीत, ईमेल-प्रासंगिक प्रत्यायोजित क्षेत्र या चयनकर्ता लक्ष्य के नियंत्रण का एक अलग सुरक्षा प्रभाव हो सकता है। जांच में यह पता लगाया जाना चाहिए कि ईमेल तंत्र वास्तव में किस DNS नाम से परामर्श करता है और कौन अपनी प्रतिक्रियाओं को बदल सकता है।

RFC 6376 चयनकर्ता और हस्ताक्षर डोमेन का उपयोग करके DKIM कुंजी पुनर्प्राप्ति का वर्णन करता है। इसलिए एक पुरानी चयनकर्ता निर्भरता एक पुरानी असंबंधित वेबसाइट CNAME के ​​बराबर नहीं है। संभावित हस्ताक्षर संबंधी निहितार्थ मुख्य सामग्री, लुकअप पथ और वैध हस्ताक्षर तैयार करने की क्षमता पर निर्भर करते हैं; उनका दावा केवल एक टूटे हुए वेब पेज से नहीं किया जाना चाहिए। यहां प्रस्तावित दस्तावेजी निर्भरता समीक्षा के लिए किसी निजी कुंजी या हस्ताक्षर परीक्षण की आवश्यकता नहीं है।

संरेखण और विरासत में मिली धारणाओं का सावधानीपूर्वक मूल्यांकन करें

RFC 9989 को परिभाषित करता है संरेखण और नीति खोज के लिए DMARC. संबंधित डोमेन शिथिल या सख्त संरेखण के तहत अलग-अलग तरीके से इंटरैक्ट कर सकते हैं, इसलिए दृश्यमान डोमेन और प्रमाणित डोमेन को सटीक रूप से रिकॉर्ड किया जाना चाहिए। यह न मानें कि प्रत्येक उपडोमेन प्रत्येक मूल पहचान से अलग है, या कि एक उपडोमेन का नियंत्रण स्वचालित रूप से मनमाने पैरेंट-डोमेन मेल को प्रमाणित करता है। वास्तविक तंत्र और नीति संबंध निर्धारित करते हैं।

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

प्रदाता सुरक्षा को उनके दस्तावेजी दायरे में लागू करें

Azure का मार्गदर्शन asuid का उपयोग करके ऐप सेवा कस्टम-डोमेन सत्यापन का वर्णन करता है TXT रिकॉर्ड और एक डोमेन सत्यापन आईडी। यह यह भी बताता है कि किसी अन्य सदस्यता को कस्टम डोमेन को मान्य करने से रोकना एक मेल खाते सेवा नाम के साथ ऐप सेवा उदाहरण के निर्माण को रोकने से अलग है। ये प्रदाता-विशिष्ट सुरक्षाएँ हैं। वे यह स्थापित नहीं करते हैं कि प्रत्येक Azure सेवा, प्रत्येक DNS रिकॉर्ड या कोई अन्य क्लाउड प्रदाता समान जीवनचक्र नियमों का उपयोग करता है।

वही मार्गदर्शन Azure DNS उपनाम रिकॉर्ड्स का वर्णन करता है जो समर्थित लक्ष्यों की सीमा के साथ कुछ समर्थित संसाधन जीवनचक्रों को DNS संदर्भों से जोड़ता है। उस व्यवहार को सामान्य CNAME रिकॉर्ड या सभी प्रदाताओं के लिए सामान्यीकृत न करें। प्रत्येक निर्भरता के लिए, लागू सुरक्षा को रिकॉर्ड करें, जहां इसका वर्तमान साक्ष्य बरकरार रखा गया है और जो असत्यापित है। एक दस्तावेजी सुरक्षा यह साबित किए बिना किसी विशेष जोखिम को कम कर सकती है कि सभी एप्लिकेशन या ईमेल ट्रस्ट रिश्ते सुरक्षित हैं।

एक सटीक-रिकॉर्ड परिवर्तन कार्यपत्रक

वर्तमान संपूर्ण रिकॉर्ड सेट, इच्छित अंतर, लक्ष्य निर्भरता, व्यवसाय स्वामी, सक्रिय उपभोक्ताओं और पुनर्स्थापित सामग्री के साथ एक अनुमोदित परिवर्तन योजना तैयार करें। सेवानिवृत्ति या सुधार का कारण, वर्तमान प्रदाता बाधाएं, सत्यापन योजना और रोलबैक निर्णय मानदंड शामिल करें। केवल इसलिए कोई विलोपन स्वचालित रूप से सुरक्षित नहीं है क्योंकि कोई सेवा अप्रयुक्त दिखाई देती है; कतारबद्ध मेल, सक्रिय चयनकर्ता, ग्राहक वर्कफ़्लो या प्रतिस्थापन सेवा अभी भी नाम पर निर्भर हो सकती है।

निर्भरता मानचित्र को प्राधिकरण रिकॉर्ड से अलग रखें। एक शोधकर्ता किसी संभावित पुराने संदर्भ को हटाने के लिए अधिकृत किए बिना उसकी पहचान कर सकता है। स्वीकृत परिवर्तन के बाद, परिचालन टीम समय, नाम और रिकॉर्ड प्रकारों के साथ आधिकारिक और पुनरावर्ती लुकअप साक्ष्य बनाए रखेगी। कैश्ड उत्तर और प्रदाता स्थिति परिवर्तन को समाप्त कर सकती है, इसलिए अकेले हटाना तत्काल सार्वभौमिक निरस्तीकरण का प्रमाण नहीं है। इस पांडुलिपि के लिए ऐसा कोई अंतर, लुकअप या रोलबैक निष्पादित नहीं किया गया था।

काल्पनिक निदान: एक सेवानिवृत्त अभियान सेवा

एक काल्पनिक संगठन एक अभियान प्लेटफ़ॉर्म को बंद कर देता है लेकिन दो DNS संदर्भ छोड़ देता है: एक वेबसाइट CNAME और एक DKIM चयनकर्ता CNAME । एक इन्वेंट्री टूल रिपोर्ट करता है कि वेबसाइट लक्ष्य अनुपलब्ध है। टीम शुरू में मानती है कि दोनों रिकॉर्ड समान अधिग्रहण जोखिम पैदा करते हैं। इसके बजाय प्रस्तावित समीक्षा लक्ष्य, प्रदाता खाता स्वामित्व, कस्टम-डोमेन सत्यापन नियम और ईमेल-हस्ताक्षर निर्भरता को अलग से मैप करती है। अनुपलब्ध वेबसाइट परिणाम चयनकर्ता की स्थिति या किसी अन्य पक्ष की किसी भी संसाधन पर दावा करने की क्षमता स्थापित नहीं करता है।

मेल स्वामी सेवानिवृत्ति का प्रस्ताव देने से पहले जाँच करेगा कि चयनकर्ता अभी भी सक्रिय या कतारबद्ध हस्ताक्षर वर्कफ़्लो का समर्थन करता है या नहीं। वेब स्वामी अभियान समापन बिंदु और उससे जुड़े किसी भी एप्लिकेशन ट्रस्ट की समीक्षा करेगा। दोनों प्रस्तावित परिवर्तनों के लिए सटीक पुनर्स्थापना सामग्री और अनुमोदित सत्यापन की आवश्यकता होगी। यह एक काल्पनिक जीवनचक्र अभ्यास है, न कि खोजा गया लटकता हुआ रिकॉर्ड, संसाधन का दावा, सफल अधिग्रहण या पूर्ण ऑफबोर्डिंग। कोई वास्तविक सेवा पहचानकर्ता या क्रेडेंशियल एकत्र नहीं किया गया था।

साक्ष्य के साथ नियंत्रण सीमा को बंद करें

एक बचाव योग्य रिपोर्ट में पुरानी निर्भरता, इसकी सत्यापित नियंत्रण स्थिति, वह तंत्र जिसके माध्यम से विश्वास प्रभावित हो सकता है और अनुमोदित सुधारात्मक कार्रवाई का नाम दिया गया है। यह संभावित जोखिम को पुष्ट शोषण से अलग करता है। यह अवशिष्ट अनिश्चितताओं को भी रिकॉर्ड करता है, जैसे अधूरे आपूर्तिकर्ता स्वामित्व साक्ष्य या न देखे गए कैश व्यवहार। किसी प्रदाता-विशिष्ट सुरक्षा को सार्वभौमिक गारंटी या हटाए गए रिकॉर्ड को सबूत के रूप में वर्णित करने से बचें कि ऐतिहासिक दुरुपयोग कभी नहीं हुआ।

कैटलॉग के लिए अनुमोदित सटीक-रिकॉर्ड अंतर, निर्भरता मानचित्र, पुनर्स्थापना सामग्री और परिवर्तन के बाद के लुकअप साक्ष्य की आवश्यकता होती है। वे मूल कलाकृतियाँ खुली रहती हैं। प्रस्तावित वर्कशीट उन्हें संतुष्ट नहीं करती है, और अन्य सभी रिलीज़ गेट खुले रहते हैं। प्रकाशन से पहले मानव विशेषज्ञ समीक्षा, स्रोत प्रयोज्यता, उत्पादन मार्ग, पहुंच और मालिक की मंजूरी पूरी की जानी चाहिए। इसका उद्देश्य टेकओवर प्रदर्शन किए बिना या विरासत में मिली ईमेल अथॉरिटी को बढ़ा-चढ़ाकर बताए बिना सफ़ाई को सुरक्षित और अधिक सटीक बनाना है।