Microsoft Dataverse में सुरक्षा अवधारणाएँ

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

टिप

निम्नलिखित वीडियो देखें: Microsoft Dataverse - डेमो में दिखाए गए सुरक्षा अवधारणाएं।

भूमिका-आधारित सुरक्षा

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

व्यवसाय इकाइयाँ

टिप

निम्नलिखित वीडियो देखें: व्यावसायिक इकाइयों का आधुनिकीकरण।

व्यावसायिक इकाइयाँ सुरक्षा भूमिकाओं के साथ काम करके उपयोगकर्ता के लिए प्रभावी सुरक्षा निर्धारित करती हैं. व्यवसाय इकाइयाँ एक सुरक्षा मॉडलिंग निर्माण इकाई है जो उपयोगकर्ताओं और जिस डेटा तक वे पहुँच सकते हैं, उसे प्रबंधित करने में मदद करती हैं. व्यवसाय इकाइयाँ एक सुरक्षा सीमा निर्धारित करती हैं. प्रत्येक Dataverse डेटाबेस में एकल मूल व्यवसाय इकाई होती है.

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

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

पदानुक्रमित डेटा पहुंच संरचना

ग्राहक संगठन संरचना का उपयोग कर सकते हैं, जहां डेटा और उपयोगकर्ता को ट्री-समान पदानुक्रम में विभाजित किया जाता है.

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

उपयोगकर्ता A डिवीजन A से जुड़ा हुआ है और उसे डिवीजन A से Y की सुरक्षा भूमिका सौंपी गई है. यह उपयोगकर्ता A को संपर्क #1 और संपर्क #2 रिकॉर्ड तक पहुंचने की अनुमति देता है. जबकि डिवीजन B में उपयोगकर्ता B डिवीजन A के संपर्क रिकॉर्ड तक पहुंच नहीं कर सकता है लेकिन संपर्क #3 के रिकॉर्ड तक पहुंच सकते हैं.

मेट्रिक्स डेटा पहुंच संरचना (आधुनिक व्यावसायिक इकाई)

ग्राहक संगठन संरचना का उपयोग कर सकते हैं, जहां डेटा को ट्री-जैसे पदानुक्रम में विभाजित किया जाता है और उपयोगकर्ता किसी भी व्यावसायिक इकाई के डेटा पर काम कर सकते हैं और उस तक पहुंच सकते हैं, भले ही उपयोगकर्ता को किसी भी व्यावसायिक इकाई को असाइन किया गया हो.

जब हम किसी उपयोगकर्ता को इस परिवेश के साथ जोड़ते हैं, तो हम उस उपयोगकर्ता को इन तीन व्यवसाय इकाइयों में से किसी एक में होने के लिए सेट कर सकते हैं. प्रत्येक व्यावसायिक यूनिट के लिए जिसे उपयोगकर्ता को डेटा तक पहुंचने की आवश्यकता होती है, उस व्यावसायिक इकाई से सुरक्षा भूमिका उपयोगकर्ता को सौंपी जाती है. जब उपयोगकर्ता रिकॉर्ड बनाता है, तो उपयोगकर्ता व्यवसाय इकाई को रिकॉर्ड के मालिक के रूप में सेट कर सकता है.

उपयोगकर्ता A को किसी भी व्यावसायिक इकाई से जोड़ा जा सकता है, जिसमें मूल व्यावसायिक इकाई भी शामिल है. डिवीजन A से सुरक्षा भूमिका Y उपयोगकर्ता A को सौंपी जाती है, जो उपयोगकर्ता को संपर्क #1 और संपर्क #2 रिकॉर्ड तक पहुंच प्रदान करती है. डिवीजन B से सुरक्षा भूमिका Y उपयोगकर्ता A को सौंपी जाती है, जो उपयोगकर्ता को संपर्क #3 रिकॉर्ड तक पहुंच प्रदान करती है.

मेट्रिक्स डेटा पहुंच सरंचरना सक्षम करें

नोट

इससे पहले कि आप इस सुविधा को सक्षम करें, आपको सुविधा के लिए अपनी सभी नई अप्रकाशित तालिकाएँ सक्षम करने के लिए अपने सभी अनुकूलन प्रकाशित करने होंगे. यदि आप पाते हैं कि आपके पास ऐसी अप्रकाशित तालिकाएँ हैं जो इस सुविधा को चालू करने के बाद उसके साथ काम नहीं कर रही हैं, तो आप OrgDBOrgSettings tool for Microsoft Dynamics CRM का उपयोग करके RecomputeOwnershipAcrossBusinessUnits सेटिंग सेट कर सकते हैं. BusinessUnits में पुनर्गणना स्वामित्व सेट करना Owning Business Unit फ़ील्ड को सेट और अपडेट करने की अनुमति देता है।

1. एक व्यवस्थापक (Dynamics 365 व्यवस्थापक, ग्लोबल व्यवस्थापक, या Microsoft Power Platform व्यवस्थापक) के रूप में Power Platform व्यवस्थापक केंद्र में साइन इन करें.
2. परिवेश का चयन करें, और फिर वह परिवेश चुनें, जिसके लिए आप इस फ़ीचर को सक्षम करना चाहते हैं.
3. सेटिंग>उत्पाद>सुविधाएँ चुनें.
4. चालू चालू करें सभी व्यावसायिक इकाई में स्वामित्व दर्ज करें स्विच करें.

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

जब तक उपयोगकर्ता के पास सुरक्षा भूमिका है जिसके पास रिकॉर्ड तालिका में पढ़ने का विशेषाधिकार है, तब तक आप किसी उपयोगकर्ता को रिकॉर्ड की स्वामी व्यवसाय इकाई में सुरक्षा भूमिका असाइन करने की आवश्यकता के बिना किसी भी व्यावसायिक इकाई में रिकॉर्ड स्वामी के रूप में असाइन कर सकते हैं. आधुनिक व्यावसायिक इकाइयों में रिकॉर्ड स्वामित्व देखें.

नोट

यह सुविधा स्विच EnableOwnershipAcrossBusinessUnits सेटिंग्स में स्टोर है तथा इसे OrgDBOrgSettings tool for Microsoft Dynamics CRM का इस्तेमाल करके भी सेट किया जा सकता है.

किसी व्यावसायिक इकाई को किसी Microsoft Entra सुरक्षा समूह के साथ संबद्ध करें

आप अपने उपयोगकर्ता प्रशासन और भूमिका असाइनमेंट को सुव्यवस्थित करने के लिए अपनी व्यावसायिक इकाई को मैप करने के लिए एक Microsoft Entra सुरक्षा समूह का उपयोग कर सकते हैं।

प्रत्येक व्यवसाय इकाई के लिए एक Microsoft Entra सुरक्षा समूह बनाएं और प्रत्येक समूह टीम को संबंधित व्यवसाय इकाई सुरक्षा भूमिका असाइन करें।

प्रत्येक व्यवसाय इकाई के लिए, एक Microsoft Entra सुरक्षा समूह बनाएँ. प्रत्येक Dataverse सुरक्षा समूह के लिए एक समूह टीम Microsoft Entra बनाएँ. व्यवसाय इकाई से प्रत्येक Dataverse समूह टीम को संबंधित सुरक्षा भूमिका असाइन करें. उपयोगकर्ता द्वारा परिवेश तक पहुँचने पर उपरोक्त आरेख में उपयोगकर्ता को रूट व्यवसाय इकाई में बनाया जाएगा. उपयोगकर्ता और Dataverse समूह टीमों का रूट व्यवसाय इकाई में होना ठीक है. उनके पास केवल उस व्यवसाय इकाई में डेटा तक पहुंच होती है जहां सुरक्षा भूमिका असाइन किया गया है.

उपयोगकर्ताओं को व्यवसाय इकाई तक पहुँच प्रदान करने के लिए उन्हें संबंधित Microsoft Entra सुरक्षा समूह में जोड़ें. उपयोगकर्ता तुरंत ऐप चला सकते हैं और इसके संसाधनों/डेटा तक पहुंच सकते हैं.

मैट्रिक्स डेटा एक्सेस में, जहां उपयोगकर्ता काम कर सकते हैं और कई व्यावसायिक इकाइयों से डेटा तक पहुंच सकते हैं, उपयोगकर्ताओं को उन सुरक्षा समूहों में जोड़ें जो उन व्यावसायिक इकाइयों में Microsoft Entra मैप किए गए हैं।

व्यावसायिक इकाई पर स्वामित्व रखना

प्रत्येक रिकॉर्ड में एक स्वामित्व व्यवसाय इकाई स्तंभ होता है जो यह निर्धारित करता है कि कौन सी व्यवसाय इकाई रिकॉर्ड का मालिक है। जब रिकॉर्ड बनाया जाता है तो यह कॉलम उपयोगकर्ता की व्यावसायिक इकाई के लिए डिफ़ॉल्ट होती है और फ़ीचर स्विच चालू होने के अलावा इसे बदला नहीं जा सकता है.

नोट

जब आप बदलते हैं कि कौन सी व्यावसायिक इकाई रिकॉर्ड का मालिक है, तो कैस्केड प्रभावों के लिए निम्न की जांच करना सुनिश्चित करें: कैस्केडिंग व्यवहार को कॉन्फ़िगर करने के लिए .NET के लिए SDK का उपयोग करना।

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

अपने उपयोगकर्ता को यह कॉलम सेट करने की अनुमति देने के लिए, आप इस कॉलम को नीचे दिए गए में सक्षम कर सकते हैं:

1. प्रपत्र - बॉडी और हेडर दोनों.
2. दृश्य.
3. कॉलम मैपिंग. अगर आप AutoMapEntity का इस्तेमाल कर रहे हैं, तो आप अपने कॉलम मैपिंग में कॉलम निर्दिष्ट कर सकते हैं.

नोट

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

आप या तो स्रोत स्कीमा से स्वामित्व वाली व्यावसायिक इकाई कॉलम को हटा सकते हैं या लक्ष्य की किसी भी व्यावसायिक इकाई के लिए स्रोत के स्वामित्व वाली व्यावसायिक इकाई कॉलम मान को अपडेट कर सकते हैं.

अगर आपके पास किसी परिवेश से डेटा को किसी बाहरी संसाधन में कॉपी करने का कार्य/प्रक्रिया है, जैसे PowerBI, तो आपको अपने स्रोत से स्वामित्व वाली व्यावसायिक इकाई कॉलम को चुनना या चुनें हुए को रद्द करना होगा. अगर आपका संसाधन इसे प्राप्त कर सकता है तो इसे चुनें या इसे अचयनित करें.

तालिका/रिकॉर्ड स्वामित्व

Dataverse दो प्रकार के रिकॉर्ड स्वामित्वों का समर्थन करती है. संगठन के स्वामित्व वाले और उपयोगकर्ता या टीम के स्वामित्व वाले. यह एक विकल्प है जो तालिका बनाए जाने के समय मिलता है और इसे बदला नहीं जा सकता है. सुरक्षा उद्देश्यों के लिए, रिकॉर्ड जो संगठन के स्वामित्व में हैं, उनमें एक्सेस स्तर के विकल्प केवल या तो उपयोगकर्ता संचालित कर सकता है या नहीं कर सकता है. उपयोगकर्ता और टीम के स्वामित्व वाले रिकॉर्ड के लिए, अधिकांश विशेषाधिकारों के लिए एक्सेस स्तर के विकल्प संगठन, व्यावसायिक इकाई और चाइल्ड व्यावसायिक इकाई या केवल उपयोगकर्ता के अपने रिकॉर्ड हैं. इसका मतलब है कि संपर्क पर पठन विशेषाधिकार के लिए, मैं उपयोगकर्ता स्वामित्व को सेट कर सकता हूँ, और उपयोगकर्ता को केवल स्वयं अपने रिकॉर्ड्स दिखाई देंगे.

एक और उदाहरण देने के लिए, मान लीजिए कि उपयोगकर्ता A डिवीज़न A से संबद्ध है, और हम उसे संपर्क पर व्यवसाय इकाई स्तर की पढ़ने की पहुँच दे रहे हैं. वे केवल संपर्क #1 और #2 देख पाएंगे लेकिन संपर्क #3 नहीं.

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

उपर्युक्त में आप प्रत्येक तालिका के लिए मानक विशेषाधिकार प्रकार पढ़ना, लिखना, हटाना, जोड़ना, में जोड़ना, असाइन करना और साझा करना देख सकते हैं. आप इनमें से प्रत्येक को अलग-अलग संपादित कर सकते हैं. प्रत्येक का विज़ुअल डिस्प्ले निम्न कुंजी से मेल खाता है कि आपने किस स्तर तक पहुँच प्रदान की है.

उपरोक्त उदाहरण में, हमने संपर्क के लिए संगठन स्तर की पहुँच दी है जिसका मतलब यह है कि डिवीज़न A का उपयोगकर्ता किसी के भी स्वामित्व वाले संपर्कों को देखकर उनका अद्यतन कर सकता है. वास्तव में, सबसे सामान्य व्यवस्थापकीय गलतियों में से एक अनुमतियों के साथ निराश होना और केवल ज़रूरत से ज़्यादा पहुँच प्रदान करना है. बहुत जल्दी एक अच्छी तरह से बनाया गया सुरक्षा मॉडल स्विस चीज़ (छिद्रों से भरा हुआ!) की तरह दिखने लगता है.

आधुनिक व्यावसायिक इकाइयों में रिकॉर्ड स्वामित्व

आधुनिक व्यावसायिक इकाइयां में, आप किसी भी व्यावसायिक इकाई के रिकॉर्ड के स्वामी होने के नाते उपयोगकर्ता रख सकते हैं. सभी उपयोगकर्ताओं को एक सुरक्षा भूमिका (कोई भी व्यावसायिक इकाई) चाहिए, जिसके पास रिकॉर्ड तालिका में पढ़ने का विशेषाधिकार हो. उपयोगकर्ताओं को उस प्रत्येक व्यवसाय इकाई में सुरक्षा भूमिका असाइन करने की आवश्यकता नहीं है जहाँ रिकॉर्ड रहता है.

यदि पूर्वावलोकन अवधि के दौरान आपके उत्पादन परिवेश में व्यावसायिक इकाइयों में रिकॉर्ड स्वामित्व सक्षम किया गया था, तो आपको व्यवसाय इकाई में इस रिकॉर्ड स्वामित्व को सक्षम करने के लिए निम्नलिखित कार्य करने होंगे.

1. संगठन सेटिंग्स संपादक स्‍थापित करें
2. RecomputeOwnershipAcrossBusinessUnits संगठन सेटिंग्स को सही पर सेट करें. जब यह सेटिंग सत्य पर सेट होती है, तो सिस्टम लॉक हो जाता है और क्षमता को सक्षम करने के लिए पुनर्गणना करने में 5 मिनट तक का समय लग सकता है, जहां उपयोगकर्ता अब प्रत्येक व्यवसाय इकाई से अलग-अलग सुरक्षा भूमिका असाइन किए जाने की आवश्यकता के बिना व्यावसायिक इकाइयों में रिकॉर्ड रख सकते हैं। यह एक रिकॉर्ड के मालिक को रिकॉर्ड की स्वामित्व वाली व्यवसाय इकाई के बाहर किसी को अपना रिकॉर्ड असाइन करने की अनुमति देता है।
3. AlwaysMoveRecordToOwnerBusinessUnit को गलत पर सेट करें. यह रिकॉर्ड के स्वामित्व को बदलने पर रिकॉर्ड को मूल स्वामित्व वाली व्यवसाय इकाई में बना देता है.

सभी गैर-संचालन परिवेशों के लिए, आपको इस क्षमता का उपयोग करने के लिए केवल AlwaysMoveRecordToOwnerBusinessUnit गलत पर सेट करने की आवश्यकता है.

नोट

यदि आप या तो व्यावसायिक इकाइयों की सुविधा में रिकॉर्ड स्वामित्व को बंद कर देते हैं या CRM के लिए OrgDBOrgSettings टूल का उपयोग करके रीकम्प्यूट ओनरशिप अक्रॉस BusinessUnits Microsoft Dynamics सेटिंग को गलत पर सेट करते हैं, तो आप Owning Business Unitफ़ील्ड सेट या अपडेट नहीं कर पाएँगे, और वे सभी रिकॉर्ड जहाँ स्वामी व्यवसाय इकाई फ़ील्ड स्वामी की व्यवसाय इकाई से भिन्न है, स्वामी की व्यवसाय इकाई में अद्यतन किए जाएँगे.

टीमें (समूह टीमों सहित)

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

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

रिकॉर्ड साझाकरण

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

Dataverse में रिकार्ड-स्तर की सुरक्षा

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

Dataverse में कॉलम-स्तरीय सुरक्षा

कभी-कभी कुछ व्यावसायिक परिदृश्यों के लिए पहुँच का रिकॉर्ड-स्तर नियंत्रण पर्याप्त नहीं होता. कॉलम स्तर पर सुरक्षा के अधिक विस्तृत नियंत्रण की अनुमति देने के लिए Dataverse में कॉलम-स्तर की सुरक्षा सुविधा है. सभी कस्टम कॉलम और अधिकांश सिस्टम कॉलम पर कॉलम-स्तर सुरक्षा को सक्षम किया जा सकता है. अधिकांश सिस्टम कॉलम, जिनमें व्यक्तिगत पहचान जानकारी (PII) शामिल है, व्यक्तिगत रूप से सुरक्षित होने में सक्षम हैं. प्रत्येक कॉलम का मेटाडेटा यह परिभाषित करता है कि वह सिस्टम कॉलम के लिए एक उपलब्ध विकल्प है या नहीं.

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

कई परिवेशों में सुरक्षा का प्रबंधन

Dataverse समाधानों का उपयोग करके सुरक्षा भूमिकाओं और कॉलम सुरक्षा प्रोफ़ाइल्स को पैक किया जा सकता है और एक परिवेश से अगले परिवेश में ले जाया जा सकता है. आवश्यक सुरक्षा घटकों में उपयोगकर्ताओं के असाइनमेंट के साथ प्रत्येक परिवेश में व्यवसाय इकाइयों और टीमों को बनाया और प्रबंधित किया जाना चाहिए.

उपयोगकर्ता परिवेश सुरक्षा कॉन्फ़िगर करना

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

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

यदि आपने कॉलम-स्तरीय सुरक्षा का उपयोग किया है, तो आपको उपयोगकर्ता या उपयोगकर्ता की टीम को किसी कॉलम सुरक्षा प्रोफ़ाइल में से किसी एक से संबद्ध करना होगा.

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

इसे भी देखें

परिवेश सुरक्षा कॉन्फ़िगर करें
सुरक्षा भूमिकाएँ और विशेषाधिकार