पावर बीआई में पंक्ति-स्तरीय सुरक्षा: मल्टी-टेनेंट डेटा एक्सेस

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

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

मुख्य बातें

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

पंक्ति-स्तरीय सुरक्षा को समझना

आरएलएस क्या करता है

RLS Power BI डेटा मॉडल में एक या अधिक तालिकाओं पर DAX फ़िल्टर अभिव्यक्तियाँ लागू करता है। जब कोई उपयोगकर्ता कोई रिपोर्ट खोलता है, तो Power BI RLS नियमों का मूल्यांकन करता है और उन पंक्तियों को चुपचाप फ़िल्टर कर देता है जिन्हें देखने के लिए उपयोगकर्ता अधिकृत नहीं है। उपयोगकर्ता को एक सामान्य रिपोर्ट का अनुभव होता है --- वे अपने दायरे से बाहर डेटा नहीं देख सकते हैं।

गंभीर रूप से, आरएलएस डेटा मॉडल परत पर काम करता है, रिपोर्ट परत पर नहीं। इसका मतलब है:

उपयोगकर्ता एक ही डेटासेट पर अपनी रिपोर्ट बनाकर आरएलएस को बायपास नहीं कर सकते
आरएलएस फ़िल्टर रिश्तों के माध्यम से प्रचारित होते हैं (Dim_Region पर एक फ़िल्टर रिश्ते के माध्यम से Fact_Sales को स्वचालित रूप से फ़िल्टर करता है)
DAX माप RLS संदर्भ का सम्मान करते हैं (CALCULATE, SUMX, और अन्य फ़ंक्शन फ़िल्टर किए गए सबसेट पर काम करते हैं)
Excel, CSV, या PowerPoint में निर्यात केवल वही डेटा निर्यात करता है जिसे देखने के लिए उपयोगकर्ता अधिकृत है

आरएलएस बनाम अन्य सुरक्षा तंत्र

तंत्र	दायरा	प्रवर्तन
कार्यक्षेत्र पहुंच	कार्यक्षेत्र को कौन देख सकता है	पावर बीआई सेवा
ऐप अनुमतियाँ	प्रकाशित ऐप्स तक कौन पहुंच सकता है	पावर बीआई सेवा
पंक्ति-स्तरीय सुरक्षा	उपयोगकर्ता कौन सी पंक्तियाँ देखता है	डेटा मॉडल (DAX)
वस्तु-स्तर की सुरक्षा	उपयोगकर्ता कौन सी तालिकाएँ/कॉलम देखता है	डेटा मॉडल (मेटाडेटा)
संवेदनशीलता लेबल	वर्गीकरण एवं सुरक्षा	माइक्रोसॉफ्ट Purview
डेटा निर्यात प्रतिबंध	क्या उपयोगकर्ता डेटा निर्यात कर सकते हैं	रिपोर्ट/कार्यस्थान सेटिंग्स

आरएलएस एकमात्र तंत्र है जो नियंत्रित करता है कि उपयोगकर्ता डेटा की कौन सी विशिष्ट पंक्तियों तक पहुंच सकता है। अन्य तंत्र कार्यक्षेत्र, रिपोर्ट या ऑब्जेक्ट स्तर पर पहुंच को नियंत्रित करते हैं।

स्थैतिक पंक्ति-स्तरीय सुरक्षा

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

एक स्थिर भूमिका बनाना

पावर बीआई डेस्कटॉप में:

मॉडलिंग पर जाएँ, फिर भूमिकाएँ प्रबंधित करें
नई भूमिका जोड़ने के लिए Create पर क्लिक करें
भूमिका का नाम बताएं (उदाहरण के लिए, "उत्तरी अमेरिका बिक्री")
फ़िल्टर करने के लिए तालिका का चयन करें (जैसे, Dim_Region)
DAX फ़िल्टर अभिव्यक्ति लिखें:

[Region] = "North America"

इस अभिव्यक्ति का अर्थ है: जब किसी उपयोगकर्ता को "उत्तरी अमेरिका बिक्री" भूमिका सौंपी जाती है, तो Dim_Region से संबंधित प्रत्येक तालिका केवल उन पंक्तियों को दिखाएगी जहां क्षेत्र उत्तरी अमेरिका है। बिक्री रिपोर्ट देखने वाले उपयोगकर्ता को केवल उत्तरी अमेरिकी बिक्री दिखाई देगी। एचआर डैशबोर्ड देखने वाला उपयोगकर्ता (यदि यह क्षेत्रीय आयाम से जुड़ता है) केवल उत्तरी अमेरिकी कर्मचारियों को देखेगा।

एकाधिक भूमिकाएँ

आप विभिन्न फ़िल्टर के साथ अनेक भूमिकाएँ बना सकते हैं:

ईएमईए बिक्री: [Region] = "EMEA"
एपीएसी बिक्री: [Region] = "APAC"
वैश्विक कार्यकारी: कोई फ़िल्टर नहीं (सभी डेटा देखता है)

एक उपयोगकर्ता को कई भूमिकाएँ सौंपी जा सकती हैं। जब कई भूमिकाएँ सौंपी जाती हैं, तो फ़िल्टर OR तर्क के साथ संयोजित हो जाते हैं --- उपयोगकर्ता सभी भूमिकाओं के डेटा का संघ देखता है। उदाहरण के लिए, "उत्तरी अमेरिका बिक्री" और "ईएमईए बिक्री" दोनों को सौंपा गया उपयोगकर्ता दोनों क्षेत्रों से डेटा देखता है।

स्टेटिक आरएलएस की सीमाएं

स्थैतिक आरएलएस तब असहनीय हो जाता है जब:

आपके पास 10-15 से अधिक विशिष्ट फ़िल्टर मान हैं (15+ भूमिकाएँ बनाना और बनाए रखना कठिन है)
उपयोगकर्ता-से-भूमिका असाइनमेंट बार-बार बदलते हैं (प्रत्येक परिवर्तन के लिए Power BI व्यवस्थापक की आवश्यकता होती है)
फ़िल्टर तर्क साधारण समानता से अधिक जटिल है (उदाहरण के लिए, प्रबंधकों को अपनी टीम का डेटा और अपना डेटा देखना चाहिए)
आपके पास दर्जनों व्यावसायिक इकाइयों में सैकड़ों उपयोगकर्ता हैं

इन परिदृश्यों के लिए, गतिशील आरएलएस समाधान है।

गतिशील पंक्ति-स्तरीय सुरक्षा

डायनेमिक आरएलएस DAX फ़ंक्शंस का उपयोग करता है जो लॉग-इन उपयोगकर्ता को निर्धारित करने और उचित फ़िल्टर लागू करने के लिए रनटाइम पर मूल्यांकन करता है। दो प्रमुख कार्य हैं:

USERNAME() — वर्तमान उपयोगकर्ता का डोमेन\उपयोगकर्ता नाम या UPN लौटाता है
USERPRINCIPALNAME() - वर्तमान उपयोगकर्ता का ईमेल/UPN लौटाता है (क्लाउड परिनियोजन के लिए अनुशंसित)

डायनेमिक आरएलएस की स्थापना

चरण 1: एक सुरक्षा मानचित्रण तालिका बनाएं

यह तालिका उपयोगकर्ताओं को उनके अधिकृत डेटा दायरे में मैप करती है। इसे डेटा स्रोत (डेटाबेस), SharePoint सूची, या Excel फ़ाइल में संग्रहीत किया जा सकता है:

उपयोगकर्ताईमेल	क्षेत्र	विभाग	कंपनी आईडी
[email protected]	उत्तरी अमेरिका	बिक्री	1
[email protected]	ईएमईए	बिक्री	2
[email protected]	एपीएसी	संचालन	3
[email protected]	सभी	सभी	सभी

इस तालिका को अपने Power BI मॉडल में SecurityMapping के रूप में आयात करें।

चरण 2: आरएलएस भूमिका बनाएं

सुरक्षा मैपिंग तालिका पर DAX फ़िल्टर के साथ एक एकल भूमिका बनाएं (उदाहरण के लिए, "डायनामिक सिक्योरिटी"):

[UserEmail] = USERPRINCIPALNAME()
    || [UserEmail] = "ALL"

चरण 3: संबंध बनाएं

सिक्योरिटीमैपिंग से अपनी आयाम तालिकाओं तक संबंध स्थापित करें:

सिक्योरिटीमैपिंग[क्षेत्र] से Dim_Region[क्षेत्र] तक
सिक्योरिटीमैपिंग[विभाग] से Dim_Department[विभाग] तक
SecurityMapping[CompanyId] से Dim_Company[CompanyId]

ये संबंध आयाम से लेकर सुरक्षा मानचित्रण तालिका तक एक-से-अनेक होने चाहिए, या आप एक द्विदिश क्रॉस-फ़िल्टर का उपयोग कर सकते हैं। हालाँकि, द्विदिश फिल्टर के प्रदर्शन संबंधी निहितार्थ होते हैं --- एक बेहतर दृष्टिकोण DAX अभिव्यक्ति में क्रॉसफ़िल्टर या TREATAS का उपयोग करता है।

चरण 4: रिश्तों के बिना विकल्प (TREATAS दृष्टिकोण)

सुरक्षा मैपिंग तालिका से संबंध बनाने के बजाय, आप सीधे तथ्य तालिका पर आरएलएस अभिव्यक्ति में TREATAS का उपयोग कर सकते हैं:

VAR CurrentUser = USERPRINCIPALNAME()
VAR UserRegions =
    CALCULATETABLE(
        VALUES(SecurityMapping[Region]),
        SecurityMapping[UserEmail] = CurrentUser
            || SecurityMapping[UserEmail] = "ALL"
    )
RETURN
    [Region] IN UserRegions

यह दृष्टिकोण अतिरिक्त संबंधों की जटिलता से बचाता है और सुरक्षा तर्क को आत्मनिर्भर रखता है।

प्रबंधक पदानुक्रम के साथ गतिशील आरएलएस

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

दृष्टिकोण 1: पथ फ़ंक्शन

यदि आपकी उपयोगकर्ता तालिका में मैनेजरआईडी कॉलम है, तो DAX के PATH फ़ंक्शन का उपयोग करें:

UserPath = PATH(Users[UserId], Users[ManagerId])

फिर आरएलएस अभिव्यक्ति में:

VAR CurrentUserId =
    LOOKUPVALUE(Users[UserId], Users[Email], USERPRINCIPALNAME())
RETURN
    PATHCONTAINS([UserPath], CurrentUserId)

यह अभिव्यक्ति वर्तमान उपयोगकर्ता के स्वयं के डेटा और उनकी प्रत्यक्ष और अप्रत्यक्ष रिपोर्ट से संबंधित सभी डेटा के लिए TRUE लौटाती है।

दृष्टिकोण 2: चपटी सुरक्षा तालिका

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

वस्तु-स्तरीय सुरक्षा (ओएलएस)

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

ओएलएस का उपयोग कब करें

गैर-एचआर उपयोगकर्ताओं से एचआर डेटासेट में वेतन कॉलम छिपाना
बिक्री टीमों से लागत-संबंधी तालिकाएँ छिपाना, जिन्हें केवल राजस्व देखना चाहिए
ग्राहक पीआईआई (ईमेल, फोन, पता) को उन विश्लेषकों से छिपाना जिन्हें केवल एकत्रित डेटा की आवश्यकता है
सामान्य उपयोगकर्ताओं से रणनीतिक मूल्य निर्धारण कॉलम छिपाना

ओएलएस कॉन्फ़िगर करना

ओएलएस को टेबुलर एडिटर (एक बाहरी उपकरण) या एक्सएमएलए एंडपॉइंट के माध्यम से कॉन्फ़िगर किया गया है, पावर बीआई डेस्कटॉप यूआई के माध्यम से नहीं।

सारणीबद्ध संपादक में:

बाहरी टूल रिबन के माध्यम से मॉडल खोलें
उस तालिका या कॉलम पर नेविगेट करें जिसे आप प्रतिबंधित करना चाहते हैं
गुण फलक में, प्रत्येक भूमिका के अंतर्गत तालिका अनुमतियाँ या कॉलम अनुमतियाँ खोजें
अनुमति को "कोई नहीं" पर सेट करें (डिफ़ॉल्ट "पढ़ें" है)

उदाहरण के लिए, कर्मचारी तालिका में वेतन कॉलम को "बिक्री" भूमिका से छिपाने के लिए:

भूमिका: बिक्री
तालिका: कर्मचारी
कॉलम: वेतन
अनुमति: कोई नहीं

विक्रय भूमिका निर्दिष्ट करने वाले उपयोगकर्ताओं को फ़ील्ड सूची में वेतन कॉलम नहीं दिखाई देगा और वे इसे DAX गणना में संदर्भित नहीं कर सकते हैं।

ओएलएस सीमाएँ

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

डायरेक्टक्वेरी के साथ आरएलएस

RLS DirectQuery के साथ काम करता है, लेकिन व्यवहार महत्वपूर्ण तरीकों से आयात मोड से भिन्न है।

यह कैसे काम करता है

DirectQuery मोड में, Power BI RLS DAX फ़िल्टर को SQL WHERE क्लॉज़ में अनुवादित करता है और इसे डेटा स्रोत पर भेजता है। डेटा स्रोत फ़िल्टरिंग करता है, और केवल अधिकृत पंक्तियाँ लौटाई जाती हैं।

सिंगल साइन-ऑन (एसएसओ) पास-थ्रू

Azure SQL या Azure Synapse जैसे डेटाबेस में SSO के साथ DirectQuery का उपयोग करते समय, Power BI उपयोगकर्ता की पहचान को डेटाबेस में भेजता है। यदि डेटाबेस की अपनी पंक्ति-स्तरीय सुरक्षा है (उदाहरण के लिए, SQL सर्वर की CREATE SECURITY POLICY), तो वह सुरक्षा Power BI के RLS के अतिरिक्त लागू होती है।

महत्वपूर्ण: यदि आप SSO पास-थ्रू सक्षम करते हैं, तो Power BI का RLS बायपास हो जाता है क्योंकि डेटाबेस सुरक्षा संभालता है। आपको इनमें से किसी एक को चुनना होगा:

पावर बीआई आरएलएस (डीएएक्स में परिभाषित, पावर बीआई में प्रबंधित)
डेटाबेस-स्तरीय आरएलएस (एसक्यूएल में परिभाषित, डेटाबेस में प्रबंधित)
दोनों (पावर बीआई आरएलएस और डेटाबेस आरएलएस लागू होते हैं --- उपयोगकर्ता इंटरसेक्शन देखता है)

प्रदर्शन संबंधी विचार

DirectQuery में RLS फ़िल्टर प्रत्येक क्वेरी में WHERE क्लॉज़ जोड़ते हैं। यदि फ़िल्टर कॉलम डेटाबेस में अनुक्रमित नहीं हैं, तो प्रदर्शन में काफी गिरावट आ सकती है। सुनिश्चित करें कि:

आरएलएस फ़िल्टर कॉलम में डेटाबेस इंडेक्स होते हैं
कुशल SQL में अनुवाद करने के लिए DAX फ़िल्टर अभिव्यक्ति काफी सरल है
आप Power BI डेस्कटॉप में "प्रदर्शन विश्लेषक" के साथ क्वेरी प्रदर्शन का परीक्षण करते हैं

पावर बीआई एंबेडेड में आरएलएस

पावर बीआई एंबेडेड (कस्टम एप्लिकेशन में रिपोर्ट एम्बेड करना) के लिए अद्वितीय आरएलएस आवश्यकताएं हैं क्योंकि अंतिम उपयोगकर्ताओं के पास पावर बीआई या एज़्योर एडी खाते नहीं हो सकते हैं।

ऐप डेटा परिदृश्य का स्वामी है

"ऐप ओन डेटा" एम्बेडिंग पैटर्न में, एक सर्विस प्रिंसिपल या मास्टर खाता पावर बीआई को प्रमाणित करता है, और एप्लिकेशन एम्बेड टोकन में उपयोगकर्ता की पहचान को पास करता है।

आरएलएस के साथ एक एम्बेड टोकन उत्पन्न करना:

एम्बेड टोकन उत्पन्न करने के लिए Power BI REST API को कॉल करते समय, identities पैरामीटर शामिल करें:

{
  "datasets": [
    {
      "id": "dataset-guid-here"
    }
  ],
  "reports": [
    {
      "id": "report-guid-here"
    }
  ],
  "identities": [
    {
      "username": "[email protected]",
      "roles": ["DynamicSecurity"],
      "datasets": ["dataset-guid-here"]
    }
  ]
}

username मान वह है जो USERPRINCIPALNAME() DAX अभिव्यक्ति में लौटाता है। roles सरणी निर्दिष्ट करती है कि कौन सी RLS भूमिकाएँ लागू की जानी हैं। आप किसी भी स्ट्रिंग को उपयोगकर्ता नाम के रूप में पास कर सकते हैं --- इसके लिए वास्तविक Azure AD खाता होना आवश्यक नहीं है।

आम एम्बेडिंग गलतियाँ

गलती 1: प्रभावी पहचान पारित नहीं करना। यदि आप identities पैरामीटर के बिना एक एम्बेड टोकन उत्पन्न करते हैं, तो एम्बेडेड रिपोर्ट सभी डेटा दिखाती है। यह सबसे आम आरएलएस एम्बेडिंग त्रुटि है।

गलती 2: भूमिकाएं पास करना लेकिन उपयोगकर्ता नाम नहीं। गतिशील आरएलएस के लिए उपयोगकर्ता नाम आवश्यक है। इसके बिना, USERPRINCIPALNAME() खाली लौटता है, और DAX फ़िल्टर किसी पंक्ति से मेल नहीं खाता --- रिपोर्ट खाली दिखाई देती है।

गलती 3: सेवा प्रिंसिपल की पहचान का उपयोग करना। सेवा प्रिंसिपल एक कार्यक्षेत्र व्यवस्थापक है और आरएलएस को बायपास करता है। आपको अंतिम उपयोगकर्ता की पहचान स्पष्ट रूप से बतानी होगी।

गलती 4: डायनेमिक आरएलएस के लिए एम्बेड टोकन में हार्डकोडिंग भूमिकाएँ। यदि आप एकल भूमिका के साथ डायनेमिक आरएलएस का उपयोग करते हैं (उदाहरण के लिए, "डायनामिक सिक्योरिटी"), तो हमेशा उस भूमिका का नाम पास करें। प्रत्येक उपयोगकर्ता के लिए अलग-अलग भूमिकाएँ न बनाएँ --- जो गतिशील आरएलएस के उद्देश्य को विफल करता है।

पंक्ति-स्तरीय सुरक्षा का परीक्षण

भूमिका के रूप में देखें (पावर बीआई डेस्कटॉप)

Power BI डेस्कटॉप में, मॉडलिंग पर जाएँ, फिर इस रूप में देखें:

परीक्षण के लिए भूमिका(भूमिकाओं) का चयन करें
गतिशील आरएलएस का परीक्षण करने के लिए वैकल्पिक रूप से एक उपयोगकर्ता नाम दर्ज करें (यह USERPRINCIPALNAME() मान का अनुकरण करता है)
ठीक क्लिक करें

रिपोर्ट अब डेटा प्रदर्शित करती है जैसे कि आप निर्दिष्ट भूमिका वाले निर्दिष्ट उपयोगकर्ता थे। सत्यापित करें:

KPI कार्ड सही फ़िल्टर किए गए योग दिखाते हैं
तालिकाएँ केवल उपयोगकर्ता के दायरे में पंक्तियाँ प्रदर्शित करती हैं
चार्ट फ़िल्टर किए गए डेटा को दर्शाते हैं
दृश्यों के बीच क्रॉस-फ़िल्टरिंग आरएलएस सीमाओं का सम्मान करती है
ड्रिल-थ्रू पेज आरएलएस संदर्भ को बनाए रखते हैं

इस रूप में देखें (पावर बीआई सेवा)

Power BI सेवा में, डेटासेट सेटिंग खोलें और सुरक्षा चुनें। आप "भूमिका के रूप में परीक्षण करें" का चयन करके और उपयोगकर्ता नाम दर्ज करके सीधे भूमिकाओं का परीक्षण कर सकते हैं।

स्वचालित परीक्षण चेकलिस्ट

निम्नलिखित परिदृश्यों के साथ एक परीक्षण मैट्रिक्स बनाएं:

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

आरएलएस के लिए प्रदर्शन अनुकूलन

प्रभाव को मापें

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

एक अच्छी तरह से डिज़ाइन किया गया आरएलएस कार्यान्वयन 5 प्रतिशत से कम ओवरहेड जोड़ता है। यदि आप 10 प्रतिशत से अधिक गिरावट देखते हैं, तो DAX फ़िल्टर अभिव्यक्तियों की जाँच करें।

अनुकूलन तकनीकें

फ़िल्टर अभिव्यक्ति को सरल रखें। आदर्श आरएलएस अभिव्यक्ति एक एकल स्तंभ तुलना है:

[Region] = USERPRINCIPALNAME()

आरएलएस फ़िल्टर में ही एकाधिक CALCULATE, FILTER, या LOOKUPVALUE कॉल के साथ जटिल अभिव्यक्तियों से बचें।

पाठ तुलना के बजाय पूर्णांक कुंजियों का उपयोग करें। [CompanyId] = 1 पर फ़िल्टर करना [CompanyName] = "ECOSIRE Private Limited" से तेज़ है। सुरक्षा मैपिंग तालिका में उपयोगकर्ता ईमेल को पूर्णांक कुंजियों में मैप करें।

आरएलएस फ़िल्टर के साथ तालिकाओं की संख्या कम करें। आयाम तालिकाओं पर आरएलएस लागू करें और संबंध प्रसार को तथ्य तालिकाओं को संभालने दें। बड़ी तथ्य तालिकाओं पर सीधे आरएलएस लागू करने से पावर बीआई को तथ्य तालिका की प्रत्येक पंक्ति पर फ़िल्टर का मूल्यांकन करने के लिए मजबूर होना पड़ता है।

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

द्विदिशात्मक क्रॉस-फ़िल्टर से बचें। द्विदिशात्मक संबंध क्वेरी जटिलता को बढ़ाते हैं और आरएलएस के साथ टकराव पैदा कर सकते हैं। यूनिडायरेक्शनल संबंधों का उपयोग करें (आयाम से तथ्य तक) और आयाम पक्ष पर आरएलएस लागू करें।

सामान्य नुकसान और समाधान

ख़तरा 1: आरएलएस कार्यस्थान व्यवस्थापकों पर लागू नहीं होता

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

समाधान: उन व्यावसायिक उपयोगकर्ताओं के लिए "दर्शक" भूमिका का उपयोग करें जिन्हें आरएलएस के अधीन होना चाहिए। बीआई टीम को केवल व्यवस्थापक/सदस्य/योगदानकर्ता भूमिकाएँ प्रदान करें।

ख़तरा 2: सभी() आरएलएस फ़िल्टर हटाना

DAX ALL() फ़ंक्शन RLS फ़िल्टर सहित तालिका से सभी फ़िल्टर हटा देता है। यदि कोई माप आरएलएस-फ़िल्टर की गई तालिका पर ALL() का उपयोग करता है, तो यह उस डेटा को उजागर कर सकता है जिसे उपयोगकर्ता को नहीं देखना चाहिए।

-- DANGEROUS: This measure ignores RLS on Dim_Region
Total Global Sales =
CALCULATE(SUM(Fact_Sales[Revenue]), ALL(Dim_Region))

समाधान: जब आप स्लाइसर/विज़ुअल फ़िल्टर हटाना चाहते हैं लेकिन आरएलएस फ़िल्टर संरक्षित करना चाहते हैं तो ALL() के बजाय ALLSELECTED() का उपयोग करें:

-- SAFE: This measure preserves RLS filters
Total Sales for Context =
CALCULATE(SUM(Fact_Sales[Revenue]), ALLSELECTED(Dim_Region))

नुकसान 3: ओवरराइडिंग आरएलएस की गणना करें

स्पष्ट फ़िल्टर तर्कों के साथ गणना करना कुछ परिदृश्यों में आरएलएस को ओवरराइड कर सकता है, विशेष रूप से रिमूवफ़िल्टर के साथ:

-- DANGEROUS: REMOVEFILTERS is equivalent to ALL
Total Revenue All Regions =
CALCULATE(SUM(Fact_Sales[Revenue]), REMOVEFILTERS(Dim_Region[Region]))

समाधान: सभी, रिमूवफ़िल्टर, और ALLEXCEPT उपयोग के लिए सभी DAX उपायों का ऑडिट करें। सुनिश्चित करें कि वे आरएलएस-फ़िल्टर किए गए कॉलम का संदर्भ नहीं देते हैं।

ख़तरा 4: समग्र मॉडल और आरएलएस

मिश्रित मॉडल (आयात और DirectQuery को मिलाकर) में, RLS को आयात तालिकाओं और DirectQuery तालिकाओं के लिए अलग से परिभाषित किया जाना चाहिए। एक एकल आरएलएस भूमिका में दोनों के लिए फ़िल्टर हो सकते हैं, लेकिन व्यवहार भिन्न होता है:

आयात तालिकाएँ: आरएलएस फ़िल्टर का मूल्यांकन पावर बीआई इंजन द्वारा किया जाता है
DirectQuery टेबल: RLS फ़िल्टर को SQL में अनुवादित किया जाता है और स्रोत पर भेजा जाता है

यदि DirectQuery स्रोत RLS फ़िल्टर में प्रयुक्त DAX फ़ंक्शन का समर्थन नहीं करता है, तो क्वेरी विफल हो जाएगी।

ख़तरा 5: आरएलएस को नज़रअंदाज करने वाली पृष्ठांकित रिपोर्ट

पावर बीआई पेजिनेटेड रिपोर्ट (रिपोर्ट बिल्डर में बनाई गई) डेटासेट आरएलएस को बायपास कर सकती हैं यदि वे सीधे डेटा स्रोत से कनेक्ट होते हैं। आरएलएस को लागू करने के लिए, पृष्ठांकित रिपोर्ट को पावर बीआई डेटासेट (सीधे डेटाबेस से नहीं) के माध्यम से कनेक्ट होना चाहिए और उपयोगकर्ता के पास एक निर्दिष्ट आरएलएस भूमिका होनी चाहिए।

एंटरप्राइज आरएलएस आर्किटेक्चर पैटर्न

बड़े संगठनों के लिए, ECOSIRE अनुशंसा करता है एक मानकीकृत आरएलएस आर्किटेक्चर:

सुरक्षा परत डिज़ाइन

सुरक्षा मैपिंग तालिका एक केंद्रीय डेटाबेस में संग्रहीत (Azure SQL या SharePoint सूची)
एकल आरएलएस भूमिका को USERPRINCIPALNAME() का उपयोग करके "डायनामिक सिक्योरिटी" नाम दिया गया है।
Azure AD समूह सिंक जो समूह सदस्यता के आधार पर सुरक्षा मैपिंग तालिका को स्वचालित रूप से पॉप्युलेट करता है
पदानुक्रम समर्थन पूर्व-चपटा पैरेंट-चाइल्ड तालिका का उपयोग करना
ऑडिट ट्रेल लॉगिंग करना कि किस उपयोगकर्ता ने कौन सा डेटा एक्सेस किया (पावर बीआई गतिविधि लॉग और आरईएसटी एपीआई के माध्यम से)

शासन प्रक्रिया

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

यह आर्किटेक्चर सुरक्षा प्रशासन के एक बिंदु को बनाए रखते हुए सैकड़ों डेटासेट में हजारों उपयोगकर्ताओं तक पहुंचता है।

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

क्या आरएलएस पावर बीआई फ्री लाइसेंस के साथ काम करता है?

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

क्या मैं व्यक्तिगत उपयोगकर्ताओं के बजाय Azure AD समूहों के आधार पर RLS लागू कर सकता हूँ?

प्रत्यक्ष नहीं। Power BI का RLS USERPRINCIPALNAME() के विरुद्ध DAX अभिव्यक्तियों का मूल्यांकन करता है, जो व्यक्तिगत उपयोगकर्ता का ईमेल लौटाता है। हालाँकि, आप एक सुरक्षा मैपिंग तालिका बना सकते हैं जो Azure AD समूहों को डेटा स्कोप में मैप करती है और Microsoft ग्राफ़ API या Azure AD समूह सदस्यता सिंक का उपयोग करके इसे पॉप्युलेट करती है। DAX अभिव्यक्ति अभी भी उपयोगकर्ता के ईमेल द्वारा फ़िल्टर होती है, लेकिन सुरक्षा मैपिंग तालिका समूह-से-डेटा मैपिंग प्रदान करती है।

यदि किसी उपयोगकर्ता को कोई आरएलएस भूमिका नहीं सौंपी गई है तो क्या होगा?

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

क्या आरएलएस वास्तविक समय डैशबोर्ड में डेटा फ़िल्टर कर सकता है?

हाँ। आरएलएस आयात और डायरेक्टक्वेरी दोनों मोड के साथ काम करता है। DirectQuery मोड में, RLS फ़िल्टर को SQL WHERE क्लॉज़ में अनुवादित किया जाता है और प्रत्येक क्वेरी के साथ डेटाबेस में भेजा जाता है, इसलिए फ़िल्टरिंग वास्तविक समय में होती है। आयात मोड में, जब उपयोगकर्ता रिपोर्ट खोलता है तो फ़िल्टरिंग को मेमोरी में लागू किया जाता है। दोनों मोड समान सुरक्षा गारंटी प्रदान करते हैं --- उपयोगकर्ता केवल अधिकृत डेटा देखता है।

मैं कैसे ऑडिट करूं कि आरएलएस के माध्यम से किसने कौन सा डेटा एक्सेस किया?

Power BI Microsoft 365 व्यवस्थापन केंद्र और Power BI REST API के माध्यम से गतिविधि लॉग प्रदान करता है। ये लॉग उपयोगकर्ता की पहचान सहित रिपोर्ट दृश्य, डेटासेट रीफ्रेश और निर्यात संचालन रिकॉर्ड करते हैं। हालाँकि, लॉग यह रिकॉर्ड नहीं करते कि उपयोगकर्ता ने कौन सी विशिष्ट पंक्तियाँ देखीं। विस्तृत डेटा एक्सेस ऑडिटिंग के लिए, लागू RLS फ़िल्टर के साथ DirectQuery द्वारा उत्पन्न वास्तविक प्रश्नों को लॉग करने के लिए डेटाबेस-स्तरीय ऑडिटिंग (उदाहरण के लिए, PostgreSQL pgaudit या Azure SQL ऑडिटिंग) सक्षम करें।