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