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