Row-Level Security in Power BI: Multi-Tenant Data Access

پاور BI میں قطار کی سطح کی سیکیورٹی: ملٹی ٹیننٹ ڈیٹا تک رسائی

قطار کی سطح کی سیکیورٹی (RLS) وہ طریقہ کار ہے جو اس بات کو یقینی بناتا ہے کہ ہر صارف صرف وہی ڈیٹا دیکھتا ہے جس تک وہ رسائی کے مجاز ہیں۔ کثیر کرایہ دار یا کثیر شعبہ جاتی ماحول میں، RLS اختیاری نہیں ہے --- یہ ایک زیر انتظام تجزیاتی پلیٹ فارم اور ڈیٹا کی خلاف ورزی کے ہونے کے انتظار میں فرق ہے۔ پھر بھی مائیکروسافٹ کا اپنا استعمال ٹیلی میٹری بتاتا ہے کہ پاور BI پریمیم کے ساتھ 30 فیصد سے کم تنظیموں نے اپنے پروڈکشن ڈیٹا سیٹس پر RLS لاگو کیا ہے۔

وجہ یہ نہیں ہے کہ RLS تصوراتی طور پر مشکل ہے۔ اس کی وجہ یہ ہے کہ عمل درآمد کی تفصیلات بہت اہم ہیں، جانچ کا عمل دستی ہے، اور RLS اور پاور BI کی دیگر خصوصیات (DirectQuery، کمپوزٹ ماڈلز، ایمبیڈنگ، ایگریگیشنز) کے درمیان تعامل ایج کیسز بناتا ہے جو ٹیموں کو چوکس کر دیتے ہیں۔ یہ گائیڈ RLS کے نفاذ کے ہر پہلو کا احاطہ کرتا ہے، آسان ترین جامد کردار سے لے کر Azure Active Directory کے انضمام کے ساتھ پیچیدہ متحرک سیکورٹی تک۔

---

اہم نکات

• پاور BI میں قطار کی سطح کی سیکیورٹی DAX ایکسپریشنز کا استعمال کرتے ہوئے ماڈل کی سطح پر ڈیٹا کو فلٹر کرتی ہے، اس بات کو یقینی بناتے ہوئے کہ صارف رپورٹس یا ویژول میں ترمیم کرکے سیکیورٹی کو نظرانداز نہیں کرسکتے ہیں۔
• جامد RLS ہارڈ کوڈز فلٹر اقدار (چھوٹے، مستحکم صارف گروپوں کے لیے موزوں)، جبکہ متحرک RLS لاگ ان صارف کی بنیاد پر متحرک طور پر فلٹر کرنے کے لیے DAX فنکشنز جیسے USERNAME() اور USERPRINCIPALNAME() کا استعمال کرتا ہے۔
• RLS صرف درآمد اور DirectQuery موڈز میں کام کرتا ہے --- یہ تجزیہ خدمات (جن کے اپنے RLS ہیں) کے لائیو کنکشنز پر لاگو نہیں ہوتا ہے۔
• آبجیکٹ لیول سیکیورٹی (OLS) پوری ٹیبلز یا کالموں کو چھپاتا ہے، ایسے منظرناموں کے لیے RLS کی تکمیل کرتا ہے جہاں صارفین کو یہ بھی معلوم نہیں ہونا چاہیے کہ کچھ ڈیٹا موجود ہے۔
• RLS کی جانچ کے لیے پاور BI ڈیسک ٹاپ اور سروس میں "دیکھیں بطور" خصوصیت کی ضرورت ہوتی ہے --- ہر کردار کے لیے واضح جانچ کے بغیر RLS کبھی بھی کام نہیں کرتا۔
• ایمبیڈڈ منظرناموں میں RLS (پاور BI ایمبیڈڈ) کو ایمبیڈ ٹوکن میں موثر شناخت پاس کرنے کی ضرورت ہوتی ہے، جو کہ نفاذ کی غلطیوں کا ایک عام ذریعہ ہے۔
• اچھی طرح سے ڈیزائن کیے گئے ماڈلز کے لیے RLS کی کارکردگی کا اثر عام طور پر 5 فیصد سے بھی کم ہوتا ہے، لیکن ناقص تحریر کردہ DAX فلٹرز کارکردگی کو 50 فیصد یا اس سے زیادہ کم کر سکتے ہیں۔

---

قطار کی سطح کی سیکیورٹی کو سمجھنا

RLS کیا کرتا ہے۔

RLS پاور BI ڈیٹا ماڈل میں ایک یا زیادہ ٹیبلز پر DAX فلٹر ایکسپریشنز کا اطلاق کرتا ہے۔ جب کوئی صارف رپورٹ کھولتا ہے، پاور BI RLS قوانین کا جائزہ لیتا ہے اور خاموشی سے ان قطاروں کو فلٹر کرتا ہے جنہیں دیکھنے کا صارف کو اختیار نہیں ہے۔ صارف ایک عام رپورٹ کا تجربہ کرتا ہے --- وہ اپنے دائرہ کار سے باہر ڈیٹا نہیں دیکھ سکتا۔

تنقیدی طور پر، RLS ڈیٹا ماڈل پرت پر کام کرتا ہے، رپورٹ پرت پر نہیں۔ اس کا مطلب ہے:

• صارفین اسی ڈیٹاسیٹ پر اپنی رپورٹیں بنا کر RLS کو نظرانداز نہیں کر سکتے
• RLS فلٹرز تعلقات کے ذریعے پھیلتے ہیں (Dim_Region پر ایک فلٹر خود بخود Fact_Sales کو رشتہ کے ذریعے فلٹر کرتا ہے)
• DAX اقدامات RLS سیاق و سباق کا احترام کرتے ہیں (calculate, SUMX، اور دیگر افعال فلٹر شدہ سب سیٹ پر کام کرتے ہیں)
• ایکسل، CSV، یا پاورپوائنٹ میں برآمد صرف وہی ڈیٹا برآمد کرتا ہے جسے صارف دیکھنے کا مجاز ہے۔

RLS بمقابلہ دیگر سیکیورٹی میکانزم

RLS واحد طریقہ کار ہے جو کنٹرول کرتا ہے کہ صارف ڈیٹا کی کن مخصوص قطاروں تک رسائی حاصل کر سکتا ہے۔ دوسرے میکانزم ورک اسپیس، رپورٹ، یا آبجیکٹ کی سطح پر رسائی کو کنٹرول کرتے ہیں۔

---

جامد قطار کی سطح کی سیکیورٹی

جامد RLS صارفین کو ہارڈ کوڈ شدہ فلٹر اقدار کے ساتھ کردار تفویض کرتا ہے۔ یہ سب سے آسان نفاذ ہے اور بہت کم تعداد میں مقررہ علاقوں، محکموں، یا کاروباری اکائیوں کے ساتھ اچھی طرح سے کام کرتا ہے۔

ایک جامد کردار بنانا

پاور BI ڈیسک ٹاپ میں:

1. ماڈلنگ پر جائیں، پھر کرداروں کا نظم کریں۔
2. نیا کردار شامل کرنے کے لیے تخلیق پر کلک کریں۔
3. کردار کا نام دیں (جیسے، "شمالی امریکہ سیلز")
4. فلٹر کرنے کے لیے جدول منتخب کریں (جیسے، Dim_Region)
5. DAX فلٹر اظہار لکھیں:

[Region] = "North America"

اس اظہار کا مطلب ہے: جب صارف کو "شمالی امریکہ سیلز" کا کردار تفویض کیا جاتا ہے، تو Dim_Region سے متعلق ہر ٹیبل صرف وہ قطاریں دکھائے گا جہاں خطہ شمالی امریکہ ہے۔ سیلز رپورٹ دیکھنے والا صارف صرف شمالی امریکہ کی سیلز دیکھے گا۔ HR ڈیش بورڈ دیکھنے والا صارف (اگر یہ علاقائی جہت سے جڑتا ہے) صرف شمالی امریکہ کے ملازمین کو دیکھے گا۔

متعدد کردار

آپ مختلف فلٹرز کے ساتھ متعدد کردار بنا سکتے ہیں:

• EMEA سیلز: [Region] = "EMEA"
• APAC سیلز: [Region] = "APAC"
• گلوبل ایگزیکٹو: کوئی فلٹر نہیں (تمام ڈیٹا دیکھتا ہے)

ایک صارف کو متعدد کرداروں کے لیے تفویض کیا جا سکتا ہے۔ متعدد کرداروں کو تفویض کیے جانے پر، فلٹرز OR منطق کے ساتھ مل جاتے ہیں --- صارف تمام کرداروں کے ڈیٹا کا اتحاد دیکھتا ہے۔ مثال کے طور پر، "شمالی امریکہ سیلز" اور "EMEA سیلز" دونوں کو تفویض کردہ صارف دونوں خطوں کا ڈیٹا دیکھتا ہے۔

جامد RLS کی حدود

جامد RLS غیر منظم ہو جاتا ہے جب:

• آپ کے پاس 10-15 سے زیادہ الگ الگ فلٹر اقدار ہیں (15+ کردار بنانا اور برقرار رکھنا مشکل ہے)
• یوزر ٹو رول اسائنمنٹ بار بار تبدیل ہوتے ہیں (ہر تبدیلی کے لیے پاور BI ایڈمن کی ضرورت ہوتی ہے)
• فلٹر منطق سادہ مساوات سے زیادہ پیچیدہ ہے (مثال کے طور پر، مینیجرز کو اپنی ٹیم کے ڈیٹا کے علاوہ ان کا اپنا بھی دیکھنا چاہیے)
• درجنوں کاروباری اکائیوں میں آپ کے سینکڑوں صارفین ہیں۔

ان منظرناموں کے لیے، متحرک RLS حل ہے۔

---

متحرک قطار کی سطح کی سیکیورٹی

ڈائنامک RLS DAX فنکشنز کا استعمال کرتا ہے جو لاگ ان صارف کا تعین کرنے اور مناسب فلٹرز لاگو کرنے کے لیے رن ٹائم پر جائزہ لیتے ہیں۔ دو اہم افعال ہیں:

• USERNAME() — موجودہ صارف کا ڈومین\username یا UPN لوٹاتا ہے۔
• USERPRINCIPALNAME() — موجودہ صارف کا ای میل/UPN لوٹاتا ہے (کلاؤڈ تعیناتیوں کے لیے تجویز کردہ)

متحرک RLS ترتیب دینا

مرحلہ 1: سیکیورٹی میپنگ ٹیبل بنائیں

یہ جدول صارفین کو ان کے مجاز ڈیٹا کے دائرہ کار میں نقشہ بناتا ہے۔ اسے ڈیٹا سورس (ڈیٹا بیس)، شیئرپوائنٹ کی فہرست، یا ایکسل فائل میں محفوظ کیا جا سکتا ہے:

اس ٹیبل کو اپنے پاور BI ماڈل میں SecurityMapping کے بطور درآمد کریں۔

مرحلہ 2: RLS رول بنائیں

سیکیورٹی میپنگ ٹیبل پر DAX فلٹر کے ساتھ ایک واحد کردار (جیسے "DynamicSecurity") بنائیں:

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

مرحلہ 3: تعلقات بنائیں

سیکیورٹی میپنگ سے اپنے ڈائمینشن ٹیبلز تک تعلقات قائم کریں:

• سیکیورٹی میپنگ[علاقہ] سے مدھم_علاقہ[علاقہ]
• سیکورٹی میپنگ[ڈیپارٹمنٹ] سے ڈیم_ڈپارٹمنٹ[محکمہ]
• سیکیورٹی میپنگ[CompanyId] سے Dim_Company[CompanyId]

یہ تعلقات طول و عرض سے لے کر سیکیورٹی میپنگ ٹیبل تک ایک سے زیادہ ہونے چاہئیں، یا آپ دو طرفہ کراس فلٹر استعمال کر سکتے ہیں۔ تاہم، دو طرفہ فلٹرز میں کارکردگی کے مضمرات ہوتے ہیں --- ایک بہتر نقطہ نظر DAX اظہار میں CROSSFILTER یا TREATAS کا استعمال کرتا ہے۔

مرحلہ 4: تعلقات کے بغیر متبادل (TREATAS اپروچ)

سیکیورٹی میپنگ ٹیبل سے تعلقات بنانے کے بجائے، آپ براہ راست فیکٹ ٹیبل پر RLS اظہار میں TREATAS استعمال کرسکتے ہیں:

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

یہ نقطہ نظر اضافی تعلقات کی پیچیدگی سے بچتا ہے اور حفاظتی منطق کو خود پر مشتمل رکھتا ہے۔

مینیجر درجہ بندی کے ساتھ متحرک RLS

ایک عام ضرورت یہ ہے کہ مینیجرز اپنی پوری رپورٹنگ چین کا ڈیٹا دیکھیں۔ اس کے لیے ملازم یا صارف کی میز میں والدین اور بچے کا درجہ بندی درکار ہے۔

** نقطہ نظر 1: PATH فنکشن**

اگر آپ کے صارف ٹیبل میں مینیجر آئی ڈی کالم ہے، تو DAX کا PATH فنکشن استعمال کریں:

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

پھر RLS اظہار میں:

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

یہ اظہار موجودہ صارف کے اپنے ڈیٹا اور ان کی براہ راست اور بالواسطہ رپورٹس سے تعلق رکھنے والے تمام ڈیٹا کے لیے TRUE لوٹاتا ہے۔

** نقطہ نظر 2: چپٹا حفاظتی میز**

اپنے ETL عمل میں درجہ بندی کی پہلے سے گنتی کریں اور ایک فلیٹ سیکیورٹی میپنگ بنائیں جہاں ہر مینیجر کو ان کی تمام رپورٹس کے ڈیٹا اسکوپس کے ساتھ درج کیا جائے۔ یہ استفسار کے وقت زیادہ پرفارمنس ہے کیونکہ یہ PATH تشخیص کے اوور ہیڈ سے گریز کرتا ہے۔

---

آبجیکٹ لیول سیکیورٹی (OLS)

آبجیکٹ لیول سیکیورٹی صارفین سے پوری میزیں یا کالم چھپا دیتی ہے۔ RLS کے برعکس، جو قطاروں کو فلٹر کرتا ہے، OLS ٹیبلز یا کالموں کو مکمل طور پر پوشیدہ بنا دیتا ہے --- وہ فیلڈ کی فہرست میں ظاہر نہیں ہوتے ہیں، اور کسی بھی بصری کا حوالہ دینے سے پوشیدہ فیلڈ ایک خرابی ظاہر کرتا ہے۔

OLS کب استعمال کریں۔

• غیر HR صارفین سے HR ڈیٹاسیٹس میں تنخواہ کے کالم چھپانا۔
• سیلز ٹیموں سے لاگت سے متعلق جدولوں کو چھپانا جنہیں صرف آمدنی دیکھنا چاہیے۔
• تجزیہ کاروں سے کسٹمر PII (ای میل، فون، پتہ) کو چھپانا جنہیں صرف مجموعی ڈیٹا کی ضرورت ہے
• عام صارفین سے اسٹریٹجک قیمتوں کے کالم کو چھپانا۔

OLS کو ترتیب دینا

OLS کو ٹیبلر ایڈیٹر (ایک بیرونی ٹول) یا XMLA اینڈ پوائنٹس کے ذریعے ترتیب دیا گیا ہے، نہ کہ Power BI ڈیسک ٹاپ UI کے ذریعے۔

ٹیبلر ایڈیٹر میں:

1. ماڈل کو بیرونی ٹولز ربن کے ذریعے کھولیں۔
2. اس ٹیبل یا کالم پر جائیں جس پر آپ پابندی لگانا چاہتے ہیں۔
3. پراپرٹیز پین میں، ہر کردار کے تحت ٹیبل پرمیشنز یا کالم پرمیشنز تلاش کریں۔
4. اجازت کو "کوئی نہیں" پر سیٹ کریں (پہلے سے طے شدہ "پڑھنا" ہے)

مثال کے طور پر، ملازمین کی میز میں تنخواہ کے کالم کو "سیلز" کے کردار سے چھپانے کے لیے:

• کردار: فروخت
• ٹیبل: ملازمین کالم: تنخواہ
• اجازت: کوئی نہیں۔

سیلز رول تفویض کردہ صارفین کو فیلڈ لسٹ میں تنخواہ کا کالم نظر نہیں آئے گا اور وہ DAX حسابات میں اس کا حوالہ نہیں دے سکتے ہیں۔

OLS کی حدود

• OLS کو XMLA اینڈ پوائنٹس کے ساتھ پاور BI پریمیم یا پرو کی ضرورت ہے۔
• OLS کو Power BI ڈیسک ٹاپ کے مقامی UI میں کنفیگر نہیں کیا جا سکتا
• OLS صرف میٹا ڈیٹا لیول ہے --- یہ قطاروں کو فلٹر نہیں کرتا ہے۔
• اگر کوئی پیمائش کسی پوشیدہ کالم کا حوالہ دیتی ہے، تو پیمائش خود محدود صارفین کے لیے غلطی کرے گی۔

---

DirectQuery کے ساتھ RLS

RLS DirectQuery کے ساتھ کام کرتا ہے، لیکن برتاؤ اہم طریقوں سے امپورٹ موڈ سے مختلف ہے۔

یہ کیسے کام کرتا ہے۔

DirectQuery موڈ میں، Power BI RLS DAX فلٹر کا ترجمہ SQL WHERE شق میں کرتا ہے اور اسے ڈیٹا سورس کو بھیجتا ہے۔ ڈیٹا کا ذریعہ فلٹرنگ کرتا ہے، اور صرف مجاز قطاریں واپس کی جاتی ہیں۔

سنگل سائن آن (SSO) پاس-تھرو

Azure SQL یا Azure Synapse جیسے ڈیٹا بیس میں SSO کے ساتھ DirectQuery استعمال کرتے وقت، Power BI صارف کی شناخت کو ڈیٹا بیس میں منتقل کرتا ہے۔ اگر ڈیٹا بیس کی اپنی قطار کی سطح کی سیکیورٹی ہے (مثال کے طور پر، SQL سرور کی CREATE SECURITY POLICY)، تو یہ سیکیورٹی Power BI کے RLS کے علاوہ لاگو ہوتی ہے۔

اہم: اگر آپ SSO پاس تھرو کو فعال کرتے ہیں، تو پاور BI کا RLS بائی پاس ہوجاتا ہے کیونکہ ڈیٹا بیس سیکیورٹی کو سنبھالتا ہے۔ آپ کو ایک یا دوسرے کا انتخاب کرنا ہوگا:

• پاور BI RLS (DAX میں بیان کردہ، Power BI میں منظم)
• ڈیٹا بیس کی سطح کا RLS (SQL میں بیان کردہ، ڈیٹا بیس میں منظم)
• دونوں (پاور BI RLS اور ڈیٹابیس RLS لاگو ہوتے ہیں --- صارف چوراہے کو دیکھتا ہے)

کارکردگی کے تحفظات

DirectQuery میں RLS فلٹرز ہر سوال میں WHERE شقیں شامل کرتے ہیں۔ اگر ڈیٹا بیس میں فلٹر کالموں کی ترتیب نہیں دی جاتی ہے، تو کارکردگی نمایاں طور پر گر سکتی ہے۔ یقینی بنائیں کہ:

• RLS فلٹر کالم میں ڈیٹا بیس انڈیکس ہوتے ہیں۔
• DAX فلٹر کا اظہار اتنا آسان ہے کہ موثر SQL میں ترجمہ کیا جا سکے۔
• آپ پاور BI ڈیسک ٹاپ میں "پرفارمنس اینالائزر" کے ساتھ استفسار کی کارکردگی کو جانچتے ہیں۔

---

پاور BI ایمبیڈڈ میں RLS

پاور BI ایمبیڈڈ (کسٹم ایپلی کیشنز میں رپورٹس کو ایمبیڈ کرنا) میں منفرد RLS تقاضے ہوتے ہیں کیونکہ آخری صارفین کے پاس Power BI یا Azure AD اکاؤنٹس نہیں ہوتے ہیں۔

ایپ ڈیٹا کے منظر نامے کی مالک ہے۔

"ایپ اونز ڈیٹا" ایمبیڈنگ پیٹرن میں، سروس پرنسپل یا ماسٹر اکاؤنٹ پاور BI کو تصدیق کرتا ہے، اور ایپلیکیشن صارف کی شناخت ایمبیڈ ٹوکن میں پاس کرتی ہے۔

RLS کے ساتھ ایمبیڈ ٹوکن بنانا:

ایمبیڈ ٹوکن بنانے کے لیے 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 پیرامیٹر کے بغیر ایمبیڈ ٹوکن تیار کرتے ہیں تو ایمبیڈڈ رپورٹ تمام ڈیٹا دکھاتی ہے۔ یہ سب سے عام RLS ایمبیڈنگ کی خرابی ہے۔

غلطی 2: کردار پاس کرنا لیکن صارف نام نہیں۔ متحرک RLS کے لیے صارف نام درکار ہے۔ اس کے بغیر، USERPRINCIPALNAME() خالی لوٹاتا ہے، اور DAX فلٹر کسی قطار سے میل نہیں کھاتا --- رپورٹ خالی دکھائی دیتی ہے۔

غلطی 3: سروس پرنسپل کی شناخت کا استعمال کرنا۔ سروس پرنسپل ورک اسپیس ایڈمن ہے اور RLS کو نظرانداز کرتا ہے۔ آپ کو حتمی صارف کی شناخت واضح طور پر پاس کرنی ہوگی۔

غلطی 4: ڈائنامک RLS کے لیے ایمبیڈ ٹوکن میں ہارڈ کوڈنگ رولز۔ اگر آپ ڈائنامک RLS کو ایک رول کے ساتھ استعمال کرتے ہیں (مثلاً، "ڈائینامک سیکیورٹی")، تو ہمیشہ اس رول کا نام پاس کریں۔ ہر صارف کے لیے الگ الگ کردار نہ بنائیں --- جو متحرک RLS کے مقصد کو ناکام بناتا ہے۔

---

قطار کی سطح کی سیکیورٹی کی جانچ کرنا

کردار کے طور پر دیکھیں (Power BI ڈیسک ٹاپ)

پاور BI ڈیسک ٹاپ میں، ماڈلنگ پر جائیں، پھر اس طرح دیکھیں:

1. جانچنے کے لیے کردار (کرداروں) کو منتخب کریں۔
2. ڈائنامک RLS کو جانچنے کے لیے اختیاری طور پر ایک صارف نام درج کریں (یہ USERPRINCIPALNAME() ویلیو کی تقلید کرتا ہے)
3. ٹھیک ہے پر کلک کریں۔

رپورٹ اب ڈیٹا کو اس طرح دکھاتی ہے جیسے آپ مخصوص کردار کے ساتھ مخصوص صارف ہوں۔ تصدیق کریں:

• KPI کارڈز درست فلٹر شدہ کل دکھاتے ہیں۔
• میزیں صرف صارف کے دائرہ کار میں قطاریں دکھاتی ہیں۔
• چارٹس فلٹر شدہ ڈیٹا کی عکاسی کرتے ہیں۔
• بصریوں کے درمیان کراس فلٹرنگ RLS کی حدود کا احترام کرتی ہے۔
• ڈرل کے ذریعے صفحات RLS سیاق و سباق کو برقرار رکھتے ہیں۔

دیکھیں بطور (Power BI سروس)

پاور BI سروس میں، ڈیٹا سیٹ کی ترتیبات کھولیں اور سیکیورٹی کو منتخب کریں۔ آپ "رول کے طور پر ٹیسٹ کریں" کو منتخب کرکے اور صارف نام درج کر کے براہ راست کرداروں کی جانچ کر سکتے ہیں۔

خودکار ٹیسٹنگ چیک لسٹ

درج ذیل منظرناموں کے ساتھ ایک ٹیسٹ میٹرکس بنائیں:

---

RLS کے لیے کارکردگی کی اصلاح

اثر کی پیمائش کریں۔

RLS کو لاگو کرنے سے پہلے اور بعد میں، استفسار کے اوقات کی پیمائش کرنے کے لیے پاور BI ڈیسک ٹاپ میں پرفارمنس اینالائزر کا استعمال کریں۔ پرفارمنس اینالائزر پین کھولیں، ریکارڈنگ شروع کریں، رپورٹ کے ساتھ تعامل کریں، اور RLS کے ساتھ اور اس کے بغیر DAX استفسار کے اوقات کا موازنہ کریں۔

ایک اچھی طرح سے ڈیزائن کردہ RLS کا نفاذ 5 فیصد سے بھی کم اوور ہیڈ کا اضافہ کرتا ہے۔ اگر آپ کو 10 فیصد سے زیادہ تنزلی نظر آتی ہے، تو DAX فلٹر کے تاثرات کی چھان بین کریں۔

اصلاح کی تکنیک

فلٹر اظہار کو سادہ رکھیں۔ مثالی RLS اظہار ایک کالم کا موازنہ ہے:

[Region] = USERPRINCIPALNAME()

RLS فلٹر میں ہی متعدد CALCULATE، FILTER، یا LOOKUPVALUE کالز کے ساتھ پیچیدہ تاثرات سے پرہیز کریں۔

متن کے موازنہ کے بجائے عددی کلیدیں استعمال کریں۔ [CompanyId] = 1 پر فلٹرنگ [CompanyName] = "ECOSIRE Private Limited" سے تیز ہے۔ سیکیورٹی میپنگ ٹیبل میں صارف کی ای میلز کو انٹیجر کیز پر نقشہ بنائیں۔

RLS فلٹرز کے ساتھ ٹیبلز کی تعداد کو کم سے کم کریں۔ ڈائمینشن ٹیبلز پر RLS کا اطلاق کریں اور ریلیشن شپ پروپیگیشن کو حقائق کی میزیں سنبھالنے دیں۔ بڑی فیکٹ ٹیبلز پر براہ راست RLS کا اطلاق پاور BI کو فیکٹ ٹیبل کی ہر قطار پر فلٹر کا جائزہ لینے پر مجبور کرتا ہے۔

ممکن ہونے پر پہلے سے جمع کریں۔ اگر کسی صارف کو صرف سمری لیول ڈیٹا کی ضرورت ہو، تو ETL کے دوران لاگو سیکیورٹی فلٹر کے ساتھ ایک پری ایگریگیٹ ٹیبل بنانے پر غور کریں۔ یہ پاور BI کو استفسار کے وقت فلٹر کرنے کے لیے درکار ڈیٹا کا حجم کم کر دیتا ہے۔

دو طرفہ کراس فلٹرز سے پرہیز کریں۔ دو طرفہ تعلقات استفسار کی پیچیدگی کو بڑھاتے ہیں اور RLS سے متصادم ہوسکتے ہیں۔ یک طرفہ تعلقات (جہت سے حقیقت تک) استعمال کریں اور طول و عرض کی طرف RLS کا اطلاق کریں۔

---

مشترکہ نقصانات اور حل

نقصان 1: RLS کا اطلاق ورک اسپیس ایڈمنز پر نہیں ہوتا ہے۔

ورک اسپیس کے منتظمین اور ممبران جن میں ترمیم کی اجازت RLS کو نظرانداز کرتے ہیں۔ وہ ہمیشہ تمام ڈیٹا دیکھتے ہیں۔ یہ ڈیزائن کے لحاظ سے ہے --- منتظمین کو ورک اسپیس کا انتظام کرنے کے لیے مکمل رسائی کی ضرورت ہے۔

حل: کاروباری صارفین کے لیے "دیکھنے والے" کا کردار استعمال کریں جنہیں RLS کے تابع ہونا چاہیے۔ BI ٹیم کو صرف ایڈمن/ ممبر/ کنٹریبیوٹر کے رولز دیں۔

نقصان 2: ALL() RLS فلٹرز کو ہٹانا

DAX ALL() فنکشن ٹیبل سے تمام فلٹرز کو ہٹاتا ہے، بشمول RLS فلٹرز۔ اگر کوئی پیمانہ RLS-فلٹرڈ ٹیبل پر ALL() کا استعمال کرتا ہے، تو یہ ڈیٹا کو بے نقاب کر سکتا ہے جسے صارف کو نہیں دیکھنا چاہیے۔

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

حل: جب آپ سلیسر/بصری فلٹرز کو ہٹانا چاہتے ہیں لیکن RLS فلٹرز کو محفوظ کرنا چاہتے ہیں تو ALL() کی بجائے ALLSELECTED() استعمال کریں:

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

نقصان 3: RLS اوور رائیڈنگ کا حساب لگائیں۔

واضح فلٹر آرگیومینٹس کے ساتھ کیلکولیٹ بعض منظرناموں میں RLS کو اوور رائیڈ کر سکتا ہے، خاص طور پر REMOVEFILTERS کے ساتھ:

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

حل: سبھی، ہٹانے والے فلٹرز، اور تمام استعمال کے لیے تمام DAX اقدامات کا آڈٹ کریں۔ یقینی بنائیں کہ وہ RLS فلٹر شدہ کالم کا حوالہ نہیں دیتے ہیں۔

نقصان 4: جامع ماڈلز اور RLS

کمپوزٹ ماڈلز میں (امپورٹ اور ڈائریکٹ کوری کو ملانا)، امپورٹ ٹیبلز اور ڈائریکٹ کیوری ٹیبلز کے لیے RLS کو الگ سے بیان کیا جانا چاہیے۔ ایک واحد RLS رول دونوں کے لیے فلٹرز پر مشتمل ہو سکتا ہے، لیکن برتاؤ مختلف ہے:

• ٹیبلز درآمد کریں: RLS فلٹر کی جانچ پاور BI انجن کے ذریعے کی جاتی ہے۔
• DirectQuery ٹیبلز: RLS فلٹر کا ترجمہ SQL میں کیا جاتا ہے اور ماخذ کو بھیجا جاتا ہے۔

اگر DirectQuery ذریعہ RLS فلٹر میں استعمال ہونے والے DAX فنکشن کو سپورٹ نہیں کرتا ہے، تو استفسار ناکام ہو جائے گا۔

نقصان 5: صفحہ بندی شدہ رپورٹس آر ایل ایس کو نظر انداز کر رہی ہیں۔

پاور BI صفحہ بندی والی رپورٹس (رپورٹ بلڈر میں بنائی گئی) ڈیٹاسیٹ RLS کو نظرانداز کر سکتی ہیں اگر وہ ڈیٹا سورس سے براہ راست جڑ جاتی ہیں۔ RLS کو نافذ کرنے کے لیے، صفحہ بندی شدہ رپورٹس کو Power BI ڈیٹاسیٹ کے ذریعے مربوط ہونا چاہیے (براہ راست ڈیٹا بیس سے نہیں) اور صارف کے پاس ایک تفویض کردہ RLS رول ہونا چاہیے۔

---

انٹرپرائز RLS آرکیٹیکچر پیٹرن

بڑی تنظیموں کے لیے، ECOSIRE تجویز کرتا ہے ایک معیاری RLS فن تعمیر:

سیکیورٹی لیئر ڈیزائن

1. سیکیورٹی میپنگ ٹیبل ایک مرکزی ڈیٹا بیس میں محفوظ ہے (Azure SQL یا SharePoint فہرست)
2. ** سنگل RLS رول** جس کا نام USERPRINCIPALNAME() کا استعمال کرتے ہوئے "DynamicSecurity" ہے
3. Azure AD گروپ کی مطابقت پذیری جو گروپ ممبرشپ کی بنیاد پر سیکیورٹی میپنگ ٹیبل کو خود بخود تیار کرتی ہے۔
4. پہلے سے چپٹی ہوئی والدین کے بچے کی میز کا استعمال کرتے ہوئے حیراکی معاونت
5. آڈٹ ٹریل لاگنگ جس میں صارفین نے کس ڈیٹا تک رسائی حاصل کی (بذریعہ Power BI سرگرمی لاگ اور REST API)

گورننس کا عمل

1. ڈیٹا اسٹیورڈ سیکیورٹی میپنگ ٹیبل کو برقرار رکھتے ہیں۔
2. تبدیلیوں کا جائزہ لیا جاتا ہے اور تبدیلی کے انتظام کے عمل کے ذریعے منظور کیا جاتا ہے۔
3. ماہانہ آڈٹ پاور BI RLS اسائنمنٹس کا HR سسٹم آف ریکارڈ سے موازنہ کرتے ہیں۔
4. سہ ماہی دخول کی جانچ RLS کی تاثیر کی تصدیق کرتی ہے۔

سیکیورٹی انتظامیہ کے ایک نقطہ کو برقرار رکھتے ہوئے یہ فن تعمیر سینکڑوں ڈیٹا سیٹس میں ہزاروں صارفین تک پہنچتا ہے۔

---

اکثر پوچھے گئے سوالات

کیا RLS پاور BI مفت لائسنس کے ساتھ کام کرتا ہے؟

نہیں. RLS کو RLS سے محفوظ رپورٹس استعمال کرنے والے تمام صارفین کے لیے پاور BI پرو یا پریمیم فی صارف لائسنس درکار ہے۔ مفت لائسنس استعمال کرنے والے صرف پریمیم صلاحیت والے ورک اسپیس میں مواد تک رسائی حاصل کر سکتے ہیں، اور اس کے بعد بھی، انہیں RLS کردار تفویض کرنے کے لیے پرو یا PPU لائسنس کی ضرورت ہے۔ پاور BI ایمبیڈڈ منظرناموں میں، آخری صارفین کو پاور BI لائسنس کی ضرورت نہیں ہے --- RLS کو ایمبیڈ ٹوکن کے ذریعے نافذ کیا جاتا ہے۔

کیا میں انفرادی صارفین کی بجائے Azure AD گروپس کی بنیاد پر RLS نافذ کر سکتا ہوں؟

براہ راست نہیں۔ Power BI کا RLS USERPRINCIPALNAME() کے خلاف DAX اظہار کی جانچ کرتا ہے، جو انفرادی صارف کا ای میل واپس کرتا ہے۔ تاہم، آپ ایک سیکیورٹی میپنگ ٹیبل بنا سکتے ہیں جو Azure AD گروپس کو ڈیٹا اسکوپس میں نقشہ بناتا ہے اور Microsoft Graph API یا Azure AD گروپ ممبرشپ سنک کا استعمال کرتے ہوئے اسے آباد کرتا ہے۔ DAX اظہار اب بھی صارف کے ای میل کے ذریعے فلٹر کرتا ہے، لیکن سیکیورٹی میپنگ ٹیبل گروپ ٹو ڈیٹا میپنگ فراہم کرتا ہے۔

اگر صارف کو کسی RLS رول کے لیے تفویض نہیں کیا جاتا ہے تو کیا ہوتا ہے؟

اگر ڈیٹاسیٹ پر RLS کی تعریف کی گئی ہے اور صارف کو کسی بھی کردار کے لیے تفویض نہیں کیا گیا ہے، تو صارف کو کوئی ڈیٹا نظر نہیں آتا ہے۔ رپورٹ لوڈ ہوتی ہے لیکن تمام ویژول خالی یا صفر دکھاتے ہیں۔ یہ محفوظ ڈیفالٹ ہے --- پاور BI کوئی رسائی نہیں مانتا جب تک کہ واضح طور پر اجازت نہ دی جائے۔ تاہم، ورک اسپیس کے منتظمین اور ترمیم کی اجازت والے اراکین RLS کو نظرانداز کرتے ہیں اور رول اسائنمنٹس سے قطع نظر تمام ڈیٹا کو ہمیشہ دیکھتے ہیں۔

کیا RLS ڈیٹا کو ریئل ٹائم ڈیش بورڈز میں فلٹر کرسکتا ہے؟

جی ہاں RLS درآمد اور DirectQuery دونوں طریقوں کے ساتھ کام کرتا ہے۔ DirectQuery موڈ میں، RLS فلٹر کا ترجمہ SQL WHERE شق میں کیا جاتا ہے اور ہر استفسار کے ساتھ ڈیٹا بیس کو بھیجا جاتا ہے، لہذا فلٹرنگ اصل وقت میں ہوتی ہے۔ امپورٹ موڈ میں، فلٹرنگ ان میموری میں لاگو ہوتی ہے جب صارف رپورٹ کھولتا ہے۔ دونوں موڈز یکساں حفاظتی ضمانت فراہم کرتے ہیں --- صارف صرف مجاز ڈیٹا دیکھتا ہے۔

میں کیسے آڈٹ کروں کہ کس نے RLS کے ذریعے کس ڈیٹا تک رسائی حاصل کی؟

Power BI Microsoft 365 ایڈمن سنٹر اور Power BI REST API کے ذریعے سرگرمی لاگ فراہم کرتا ہے۔ یہ لاگز رپورٹ کے نظارے، ڈیٹاسیٹ کی تازہ کاری، اور برآمدی کارروائیوں کو ریکارڈ کرتے ہیں، بشمول صارف کی شناخت۔ تاہم، نوشتہ جات ریکارڈ نہیں کرتے کہ صارف نے کن مخصوص قطاروں کو دیکھا۔ تفصیلی ڈیٹا تک رسائی کے آڈیٹنگ کے لیے، لاگو RLS فلٹرز کے ساتھ DirectQuery کے ذریعے پیدا کردہ اصل سوالات کو لاگ کرنے کے لیے ڈیٹا بیس کی سطح کی آڈیٹنگ (مثال کے طور پر، PostgreSQL pgaudit یا Azure SQL آڈیٹنگ) کو فعال کریں۔