खरीदने से पहले पहुंच नियंत्रण, ऑडिट लॉग और किरायेदार अलगाव का आकलन करें

एक प्रमाणित नियंत्रण सीमा खरीदें

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

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

पहले खरीदार की पहुंच मैट्रिक्स को परिभाषित करें

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

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

इंटरफ़ेस से परे किरायेदार बाइंडिंग को सत्यापित करें

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

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

पूछें कि ऑडिट लॉग वास्तव में क्या रिकॉर्ड करता है

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

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

नियंत्रण के रूप में लॉग पहुंच और अखंडता की समीक्षा करें

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

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

जीवनचक्र परिवर्तन और सेवा पहुंच का परीक्षण करें

भूमिका में कमी, उपयोगकर्ता अक्षमता और क्रेडेंशियल निरस्तीकरण अलग-अलग घटनाएँ हैं। RFC 7643 एससीआईएम सक्रिय विशेषता का वर्णन करता है जबकि इसका निश्चित अर्थ सेवा प्रदाता पर छोड़ता है। यह दर्शाता है कि कोई खरीदार यह क्यों नहीं मान सकता कि प्रोविजनिंग अपडेट सभी मौजूदा सत्रों या एकीकरण क्रेडेंशियल्स को रद्द कर देता है। उत्पाद के सत्र और गैर-इंटरएक्टिव-एक्सेस व्यवहार की वर्तमान व्याख्या की आवश्यकता है।

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

एक क्रेता स्वीकृति कार्यपत्रक

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

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

काल्पनिक निदान: एक दर्शक जो निर्यात कर सकता है

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

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

क्रय निष्कर्ष को सीमित रखें

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

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