[ उद्यम संचालन ]

प्रमाणीकरण सेवा छोड़ने से पहले आवश्यक डेटा निर्यात करें

सेवा पहुंच समाप्त होने से पहले एक उपयोगी, सत्यापित निर्यात बनाएं, न कि केवल डाउनलोड की गई फ़ाइलों का एक फ़ोल्डर।

EmailAuth अनुसंधान टीम द्वारा · 3 मिनट पढ़ा

[ प्रमुख बिंदु ]

  • सेवा पहुंच समाप्त होने से पहले एक उपयोगी, सत्यापित निर्यात बनाएं, न कि केवल डाउनलोड की गई फ़ाइलों का एक फ़ोल्डर।
  • एक सत्यापित संग्रह हैश बाइट संगतता साबित करता है, न कि संपूर्ण डेटा या पुनर्प्राप्ति योग्य हस्ताक्षर; पुरानी सेवा के बिना परीक्षण पुनर्प्राप्ति।
इस पेज पर

निर्यात मौजूद होने पर सेवा निकास अधूरा होता है लेकिन कोई भी इसे समझा या पुनर्स्थापित नहीं कर सकता है। भावी ऑपरेटर के प्रश्नों से प्रारंभ करें: कौन से डोमेन और प्रेषक स्वीकृत हैं, कौन सी निर्भरताएँ लाइव हैं, अपवाद क्यों मौजूद हैं, और कौन से परिवर्तन अधिकृत थे? एक निर्यात को रहस्यों या अनावश्यक व्यक्तिगत डेटा को अनियंत्रित संग्रह में स्थानांतरित किए बिना उन उत्तरों को संरक्षित करना चाहिए।

निर्यात सीमा को परिभाषित करें

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

समग्र-रिपोर्ट संरचना में निर्दिष्ट है RFC 9990; डैशबोर्ड अपना स्वयं का एट्रिब्यूशन या सामान्यीकरण जोड़ सकते हैं। मानक फ़ील्ड को आपूर्तिकर्ता व्याख्या से अलग करने के लिए पर्याप्त कच्ची सामग्री सुरक्षित रखें। किसी परिचित प्रदाता लेबल को इस बात का प्रमाण न मानें कि व्यवसाय ने किसी विशेष भेजने वाले खाते को मंजूरी दे दी है।

कॉन्फ़िगरेशन को क्रेडेंशियल से अलग करें

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

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

किसी निर्यात को डेटा के रूप में सत्यापित करें

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

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

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

पहुंच समाप्त होने के बाद संग्रह को उपयोगी रखें

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

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

[ ले लेना ]

एक सत्यापित संग्रह हैश बाइट संगतता साबित करता है, न कि संपूर्ण डेटा या पुनर्प्राप्ति योग्य हस्ताक्षर; पुरानी सेवा के बिना परीक्षण पुनर्प्राप्ति।

[भूमिका के अनुसार]

आपके लिए इसका क्या मतलब है

व्यावहारिक अगले चरणों के लिए अपनी भूमिका चुनें।

आईटी/मेल एडमिन

फ़ाइलें और संबंध सत्यापित करें

अखंडता, पंक्ति कवरेज और एक व्यावहारिक पुनर्प्राप्ति कार्य की जाँच करें।

अगले कदम

  1. पार्सर सम्मेलनों को सुरक्षित रखें.
  2. निजी क्रेडेंशियल को मेटाडेटा से अलग करें.
  3. दिनांकित इन्वेंट्री के साथ निर्यात की गई पंक्तियों का मिलान करें।

सीआईएसओ/सेकऑप्स

एक्सपोज़र को सीमित रखें

संवेदनशील डेटा की अनियंत्रित प्रतियों के बिना साक्ष्य को उपयोगी रखें।

अगले कदम

  1. प्रतिधारण और पहुंच को मंजूरी दें.
  2. स्वीकृत अंतराल और उत्पत्ति को रिकॉर्ड करें।
  3. दस्तावेज़ अनुपलब्ध डेटा और स्वीकृत प्रभाव।

संस्थापक/गैर-तकनीकी

एक व्यवस्थित निकास खरीदें

निर्यात प्रयोज्यता को स्वीकृति शर्त बनाएं।

अगले कदम

  1. एक संग्रह स्वामी नियुक्त करें.
  2. रद्द करने से पहले गुम डेटा का समाधान करें।
  3. भावी ऑपरेटर के साथ हैंडओवर प्रश्न का परीक्षण करें।

[ पूछे जाने वाले प्रश्न ]

अक्सर पूछे जाने वाले प्रश्नों

क्या डैशबोर्ड स्क्रीनशॉट पर्याप्त निर्यात है?

नहीं, भविष्य की जांच और प्रवासन के लिए आवश्यक परिचालन रिकॉर्ड और कच्चे साक्ष्य को सुरक्षित रखें।

क्या निजी DKIM कुंजियाँ सामान्य संग्रह में जानी चाहिए?

नहीं, यदि निर्यात समर्थित है और आवश्यक है तो अलग से अनुमोदित गुप्त-हस्तांतरण प्रक्रिया का उपयोग करें।

क्या सार्वजनिक कुंजी हस्ताक्षर को पुनर्स्थापित कर सकती है?

नहीं, यह सत्यापन का समर्थन करता है, निजी-कुंजी हस्ताक्षर का नहीं।

चेकसम क्या सिद्ध करता है?

वह बाइट्स रिकॉर्ड किए गए डाइजेस्ट से मेल खाता है, न कि यह कि निर्यात प्रामाणिक या पूर्ण है।

लुप्त इतिहास को कैसे संभाला जाना चाहिए?

अंतर, उसके प्रभाव और उस मालिक को रिकॉर्ड करें जो पहुंच समाप्त होने से पहले इसे स्वीकार करता है।

डेटा डिक्शनरी क्यों रखें?

फ़ील्ड अर्थ, पहचानकर्ता और सामान्यीकरण नियम प्रस्थान सेवा के लिए विशिष्ट हो सकते हैं।

पुरालेख पुनर्प्राप्ति परीक्षण को क्या करना चाहिए?

पुराने डैशबोर्ड पर निर्भर हुए बिना वास्तविक परिचालन संबंधी प्रश्न हल करें।

क्या अनिश्चितकालीन प्रतिधारण सबसे सुरक्षित विकल्प है?

स्वचालित रूप से नहीं. प्रतिधारण और पहुंच को अनुमोदित व्यवसाय, गोपनीयता और कानूनी आवश्यकताओं का पालन करना चाहिए।

[ सूत्रों का कहना है ]

सूत्रों का कहना है

  1. RFC 9990 : DMARC समग्र रिपोर्टिंग

    धारा §3.1 · §3.1.1 · §7

  2. RFC 6376: DKIM

    धारा §3.3 · §3.6 · §5.2 · §6.1.2

  3. NIST एसपी 800-34 रेव. 1: आकस्मिक योजना गाइड (11 नवंबर 2010 को अद्यतन)

    धारा §3.2 व्यावसायिक प्रभाव विश्लेषण; पीपी. 15-19 · §3.5 योजना परीक्षण, प्रशिक्षण और अभ्यास; पीपी. 27-30 · §3.6 योजना रखरखाव; पी। 31

[ शब्दकोष ]

शब्दकोष

घोषणापत्र
कलाकृतियों और उनकी अखंडता मेटाडेटा की एक सूची।
उत्पत्ति
रिकॉर्ड किया गया स्रोत और साक्ष्य का प्रबंधन इतिहास।

उद्यम उद्गम

शीर्ष वित्तीय संस्थान और सरकारें ही क्यों? अपने ईमेल सुरक्षा डैशबोर्ड हटा दिए।

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

EmailAuth एजेंटिक ईमेल उद्गम मंच है। हमारे एजेंट लागू करते हैं p=reject, तृतीय-पक्ष प्रेषकों को संरेखित रखें और अपने डोमेन को पूर्ण रूप से स्थानांतरित करें RFC 9989 अनुपालन, नया DMARC मानक, मानव-इन-द-लूप ऑडिटेबिलिटी के साथ।

सरकारों बड़े उद्यम टियर-1 वित्तीय संस्थान

सास · समर्पित किरायेदारी · एयर-गैप्ड ऑन-प्रिमाइसेस · BYOK एन्क्रिप्शन

ज्ञानधार