الأمان على مستوى الصف في Power BI: الوصول إلى بيانات المستأجرين المتعددين

الأمان على مستوى الصف (RLS) هو الآلية التي تضمن أن يرى كل مستخدم فقط البيانات المصرح له بالوصول إليها. في بيئة متعددة المستأجرين أو متعددة الأقسام، لا يعد RLS اختياريًا --- إنه الفرق بين منصة التحليلات المحكومة وخرق البيانات الذي ينتظر حدوثه. ومع ذلك، تشير قياسات الاستخدام عن بعد الخاصة بشركة Microsoft إلى أن أقل من 30 بالمائة من المؤسسات التي تستخدم Power BI Premium قامت بتطبيق RLS على مجموعات بيانات الإنتاج الخاصة بها.

السبب ليس أن RLS صعب من الناحية النظرية. والسبب هو أن تفاصيل التنفيذ دقيقة، وعملية الاختبار يدوية، والتفاعل بين RLS وميزات Power BI الأخرى (DirectQuery، والنماذج المركبة، والتضمين، والتجميعات) ينشئ حالات حافة تفاجئ الفرق. يغطي هذا الدليل كل جانب من جوانب تنفيذ RLS، بدءًا من الدور الثابت الأبسط وحتى الأمان الديناميكي المعقد من خلال تكامل Azure Active Directory.

---

الوجبات السريعة الرئيسية

• يقوم الأمان على مستوى الصف في Power BI بتصفية البيانات على مستوى النموذج باستخدام تعبيرات DAX، مما يضمن عدم تمكن المستخدمين من تجاوز الأمان عن طريق تعديل التقارير أو العناصر المرئية
• قيم تصفية رموز RLS الثابتة (مناسبة لمجموعات المستخدمين الصغيرة والمستقرة)، بينما يستخدم RLS الديناميكي وظائف DAX مثل USERNAME() وUSERPRINCIPALNAME() للتصفية ديناميكيًا بناءً على المستخدم الذي قام بتسجيل الدخول
• يعمل RLS فقط في وضعي الاستيراد والاستعلام المباشر --- ولا ينطبق على الاتصالات المباشرة بخدمات التحليل (التي لها RLS الخاصة بها)
• يقوم الأمان على مستوى الكائن (OLS) بإخفاء الجداول أو الأعمدة بأكملها، مما يكمل RLS للسيناريوهات التي لا ينبغي للمستخدمين حتى معرفة وجود بيانات معينة فيها
• يتطلب اختبار RLS ميزة "العرض كـ" في Power BI Desktop and Service --- لا تفترض أبدًا أن RLS يعمل بدون اختبار صريح لكل دور
• يتطلب RLS في السيناريوهات المضمنة (Power BI Embedded) تمرير الهوية الفعالة في الرمز المميز للتضمين، وهو مصدر شائع لأخطاء التنفيذ
• عادةً ما يكون تأثير أداء RLS أقل من 5 بالمائة للنماذج جيدة التصميم، ولكن مرشحات DAX المكتوبة بشكل سيئ يمكن أن تؤدي إلى انخفاض الأداء بنسبة 50 بالمائة أو أكثر

---

فهم الأمان على مستوى الصف

ما يفعله RLS

يطبق RLS تعبيرات عامل تصفية DAX على جدول واحد أو أكثر في نموذج بيانات Power BI. عندما يفتح مستخدم تقريرًا، يقوم Power BI بتقييم قواعد RLS ويقوم بتصفية الصفوف التي لا يحق للمستخدم رؤيتها بصمت. يواجه المستخدم تقريرًا عاديًا --- لا يمكنه ببساطة رؤية البيانات خارج نطاقه.

والأهم من ذلك، أن RLS يعمل في طبقة نموذج البيانات، وليس طبقة التقرير. هذا يعني:

• لا يمكن للمستخدمين تجاوز RLS عن طريق إنشاء تقارير خاصة بهم على نفس مجموعة البيانات
• تنتشر عوامل تصفية RLS من خلال العلاقات (يقوم عامل التصفية الموجود في Dim_Region تلقائيًا بتصفية Fact_Sales من خلال العلاقة)
• تحترم مقاييس DAX سياق RLS (تعمل الوظائف CALCULATE وSUMX والوظائف الأخرى على المجموعة الفرعية التي تمت تصفيتها)
• التصدير إلى Excel أو CSV أو PowerPoint يصدر فقط البيانات المسموح للمستخدم برؤيتها

RLS مقابل آليات الأمن الأخرى

RLS هي الآلية الوحيدة التي تتحكم في صفوف البيانات المحددة التي يمكن للمستخدم الوصول إليها. تتحكم الآليات الأخرى في الوصول على مستوى مساحة العمل أو التقرير أو الكائن.

---

أمان ثابت على مستوى الصف

تقوم خدمة RLS الثابتة بتعيين المستخدمين لأدوار ذات قيم مرشح مضمنة. يعد هذا أبسط تطبيق ويعمل بشكل جيد مع السيناريوهات التي تحتوي على عدد صغير من المناطق أو الأقسام أو وحدات الأعمال الثابتة.

إنشاء دور ثابت

في Power BI Desktop:

1. انتقل إلى النمذجة، ثم إدارة الأدوار
2. انقر فوق "إنشاء" لإضافة دور جديد
3. قم بتسمية الدور (على سبيل المثال، "مبيعات أمريكا الشمالية")
4. حدد الجدول المراد تصفيته (على سبيل المثال، Dim_Region)
5. اكتب تعبير مرشح DAX:

[Region] = "North America"

يعني هذا التعبير: عندما يتم تعيين دور "مبيعات أمريكا الشمالية" للمستخدم، فإن كل جدول متعلق بـ Dim_Region سيعرض فقط الصفوف التي تكون فيها المنطقة هي أمريكا الشمالية. سيشاهد المستخدم الذي يشاهد تقرير المبيعات مبيعات أمريكا الشمالية فقط. المستخدم الذي يعرض لوحة معلومات الموارد البشرية (إذا كانت متصلة عبر بُعد إقليمي) سيشاهد فقط الموظفين في أمريكا الشمالية.

أدوار متعددة

يمكنك إنشاء أدوار متعددة باستخدام مرشحات مختلفة:

• مبيعات أوروبا والشرق الأوسط وأفريقيا: [Region] = "EMEA"
• مبيعات آسيا والمحيط الهادئ: [Region] = "APAC"
• المدير التنفيذي العالمي: لا يوجد مرشح (يرى جميع البيانات)

يمكن تعيين المستخدم لأدوار متعددة. عند تعيينها لأدوار متعددة، تدمج المرشحات مع منطق OR --- يرى المستخدم اتحاد بيانات جميع الأدوار. على سبيل المثال، يرى المستخدم المعين لكل من "مبيعات أمريكا الشمالية" و"مبيعات أوروبا والشرق الأوسط وأفريقيا" البيانات من كلتا المنطقتين.

حدود RLS الثابتة

يصبح RLS الثابت غير قابل للإدارة عندما:

• لديك أكثر من 10 إلى 15 قيمة مرشح مميزة (إنشاء أكثر من 15 دورًا والحفاظ عليها أمر شاق)
• تتغير تعيينات المستخدم إلى الدور بشكل متكرر (يتطلب كل تغيير مسؤول Power BI)
• منطق التصفية أكثر تعقيدًا من المساواة البسيطة (على سبيل المثال، يجب على المديرين الاطلاع على بيانات فريقهم بالإضافة إلى بياناتهم الخاصة)
• لديك مئات المستخدمين عبر العشرات من وحدات الأعمال

بالنسبة لهذه السيناريوهات، فإن RLS الديناميكي هو الحل.

---

الأمان الديناميكي على مستوى الصف

يستخدم RLS الديناميكي وظائف DAX التي يتم تقييمها في وقت التشغيل لتحديد المستخدم الذي قام بتسجيل الدخول وتطبيق عوامل التصفية المناسبة. الوظيفتان الرئيسيتان هما:

• USERNAME() — إرجاع المجال\اسم المستخدم أو UPN للمستخدم الحالي
• USERPRINCIPALNAME() — إرجاع البريد الإلكتروني/UPN للمستخدم الحالي (موصى به لعمليات النشر السحابية)

إعداد RLS الديناميكي

الخطوة 1: إنشاء جدول تعيين الأمان

يقوم هذا الجدول بتعيين المستخدمين لنطاق البيانات المعتمد الخاص بهم. ويمكن تخزينها في مصدر البيانات (قاعدة البيانات)، أو قائمة SharePoint، أو ملف Excel:

قم باستيراد هذا الجدول إلى نموذج Power BI الخاص بك كـ SecurityMapping.

الخطوة 2: إنشاء دور RLS

قم بإنشاء دور واحد (على سبيل المثال، "DynamicSecurity") باستخدام عامل تصفية DAX في جدول تعيين الأمان:

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

الخطوة 3: إنشاء العلاقات

أنشئ علاقات من SecurityMapping إلى جداول الأبعاد الخاصة بك:

• رسم الخرائط الأمنية [المنطقة] إلى Dim_Region [المنطقة]
• رسم الخرائط الأمنية [القسم] إلى Dim_Department [القسم]
• SecurityMapping [CompanyId] إلى Dim_Company [CompanyId]

يجب أن تكون هذه العلاقات رأس برأس من البعد إلى جدول تعيين الأمان، أو يمكنك استخدام عامل تصفية مشترك ثنائي الاتجاه. ومع ذلك، فإن عوامل التصفية ثنائية الاتجاه لها تأثيرات على الأداء --- يستخدم الأسلوب الأفضل CROSSFILTER أو TREATAS في تعبير DAX.

الخطوة 4: البديل بدون علاقات (نهج TREATAS)

بدلاً من إنشاء علاقات من جدول تعيين الأمان، يمكنك استخدام TREATAS في تعبير RLS في جدول الحقائق مباشرةً:

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

يتجنب هذا الأسلوب تعقيد العلاقات الإضافية ويحافظ على منطق الأمان مستقلاً بذاته.

RLS ديناميكي مع التسلسل الهرمي للمدير

أحد المتطلبات الشائعة هو أن يرى المديرون بيانات سلسلة التقارير بأكملها. يتطلب ذلك وجود تسلسل هرمي بين الأصل والفرع في جدول الموظف أو المستخدم.

** النهج 1: وظيفة PATH **

إذا كان جدول المستخدم الخاص بك يحتوي على عمود ManagerId، فاستخدم وظيفة PATH الخاصة بـ DAX:

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

• إخفاء أعمدة الرواتب في مجموعات بيانات الموارد البشرية عن المستخدمين غير المتخصصين في الموارد البشرية
• إخفاء الجداول المرتبطة بالتكلفة عن فرق المبيعات التي يجب أن ترى الإيرادات فقط
• إخفاء معلومات تحديد الهوية الشخصية (PII) للعميل (البريد الإلكتروني والهاتف والعنوان) عن المحللين الذين يحتاجون فقط إلى بيانات مجمعة
• إخفاء أعمدة التسعير الاستراتيجي عن عامة المستخدمين

تكوين OLS

يتم تكوين OLS من خلال Tabular Editor (أداة خارجية) أو نقاط نهاية XMLA، وليس من خلال Power BI Desktop UI.

في المحرر الجدولي:

1. افتح النموذج عبر شريط الأدوات الخارجية
2. انتقل إلى الجدول أو العمود الذي تريد تقييده
3. في جزء الخصائص، ابحث عن أذونات الجدول أو أذونات العمود ضمن كل دور
4. اضبط الإذن على "لا شيء" (الافتراضي هو "قراءة")

على سبيل المثال، لإخفاء عمود "الراتب" في جدول "الموظفين" من دور "المبيعات":

• الدور: المبيعات
• الجدول: الموظفون
• العمود: الراتب
• الإذن: لا يوجد

لن يتمكن المستخدمون الذين تم تعيينهم لدور المبيعات من رؤية عمود "الراتب" في قائمة الحقول ولا يمكنهم الرجوع إليه في حسابات DAX.

قيود خدمة الحياة البرية

• يتطلب OLS استخدام Power BI Premium أو Pro مع تمكين نقاط نهاية XMLA
• لا يمكن تكوين OLS في واجهة المستخدم الأصلية لـ Power BI Desktop
• OLS هو على مستوى البيانات التعريفية فقط --- ولا يقوم بتصفية الصفوف
• إذا كان المقياس يشير إلى عمود مخفي، فسيظهر خطأ في المقياس نفسه للمستخدمين المقيدين

---

RLS مع DirectQuery

يعمل RLS مع DirectQuery، لكن السلوك يختلف عن وضع الاستيراد في جوانب مهمة.

كيف يعمل

في وضع DirectQuery، يقوم Power BI بترجمة عامل تصفية RLS DAX إلى جملة SQL WHERE وإرساله إلى مصدر البيانات. يقوم مصدر البيانات بإجراء التصفية، ويتم إرجاع الصفوف المعتمدة فقط.

تمرير الدخول الموحد (SSO).

عند استخدام DirectQuery مع SSO لقاعدة بيانات مثل Azure SQL أو Azure Synapse، يقوم Power BI بتمرير هوية المستخدم إلى قاعدة البيانات. إذا كانت قاعدة البيانات لها أمان خاص بها على مستوى الصف (على سبيل المثال، CREATE SECURITY POLICY الخاص بـ SQL Server)، فسيتم تطبيق هذا الأمان بالإضافة إلى RLS الخاص بـ Power BI.

هام: إذا قمت بتمكين تمرير SSO، فسيتم تجاوز RLS الخاص بـ Power BI لأن قاعدة البيانات تتعامل مع الأمان. يجب عليك اختيار واحد أو آخر:

• Power BI RLS (المحدد في DAX، والمدار في Power BI)
• RLS على مستوى قاعدة البيانات (المحددة في SQL، وتتم إدارتها في قاعدة البيانات)
• كلاهما (يتم تطبيق Power BI RLS وقاعدة البيانات RLS --- يرى المستخدم التقاطع)

اعتبارات الأداء

تضيف عوامل تصفية RLS في DirectQuery عبارات WHERE إلى كل استعلام. إذا لم تتم فهرسة أعمدة التصفية في قاعدة البيانات، فقد ينخفض ​​الأداء بشكل ملحوظ. تأكد من أن:

• تحتوي أعمدة مرشح RLS على فهارس قاعدة البيانات
• تعبير عامل تصفية DAX بسيط بما يكفي لترجمته إلى SQL فعال
• يمكنك اختبار أداء الاستعلام باستخدام "محلل الأداء" في Power BI Desktop

---

RLS في Power BI Embedded

يحتوي Power BI Embedded (تضمين التقارير في التطبيقات المخصصة) على متطلبات RLS فريدة لأن المستخدمين النهائيين قد لا يكون لديهم حسابات Power BI أو Azure AD.

يمتلك التطبيق سيناريو البيانات

في نمط التضمين "التطبيق يمتلك البيانات"، يقوم الحساب الأساسي أو الرئيسي للخدمة بالمصادقة على Power 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 الديناميكي مع دور واحد (على سبيل المثال، "DynamicSecurity")، فقم دائمًا بتمرير اسم الدور هذا. لا تقم بإنشاء أدوار منفصلة لكل مستخدم --- فهذا يتعارض مع غرض RLS الديناميكي.

---

اختبار الأمان على مستوى الصف

عرض كدور (Power BI Desktop)

في Power BI Desktop، انتقل إلى النمذجة، ثم عرض باسم:

1. حدد الدور (الأدوار) المراد اختباره
2. أدخل اسم مستخدم بشكل اختياري لاختبار RLS الديناميكي (وهذا يحاكي قيمة USERPRINCIPALNAME())
3. انقر فوق موافق

يعرض التقرير الآن البيانات كما لو كنت المستخدم المحدد بالدور المحدد. التحقق:

• تعرض بطاقات KPI الإجماليات الصحيحة التي تمت تصفيتها
• تعرض الجداول الصفوف الموجودة ضمن نطاق المستخدم فقط
• الرسوم البيانية تعكس البيانات التي تمت تصفيتها
• التصفية المتقاطعة بين العناصر المرئية تحترم حدود RLS
• تحافظ صفحات التصفح على سياق RLS

عرض باسم (خدمة Power BI)

في خدمة Power BI، افتح إعدادات مجموعة البيانات وحدد الأمان. يمكنك اختبار الأدوار مباشرة عن طريق تحديد "اختبار كدور" وإدخال اسم المستخدم.

قائمة مراجعة الاختبار الآلي

قم بإنشاء مصفوفة اختبار بالسيناريوهات التالية:

---

تحسين الأداء لـ RLS

قياس التأثير

قبل وبعد تنفيذ RLS، استخدم محلل الأداء في Power BI Desktop لقياس أوقات الاستعلام. افتح جزء محلل الأداء، وابدأ التسجيل، وتفاعل مع التقرير، وقارن أوقات استعلام DAX مع RLS وبدونه.

يضيف تطبيق RLS المصمم جيدًا أقل من 5 بالمائة من النفقات العامة. إذا رأيت تدهورًا يزيد عن 10 بالمائة، فافحص تعبيرات عامل تصفية DAX.

تقنيات التحسين

حافظ على بساطة تعبيرات المرشح. تعبير RLS المثالي هو مقارنة عمود واحد:

[Region] = USERPRINCIPALNAME()

تجنب التعبيرات المعقدة التي تحتوي على استدعاءات CALCULATE أو FILTER أو LOOKUPVALUE المتعددة في عامل تصفية RLS نفسه.

استخدم مفاتيح الأعداد الصحيحة بدلاً من مقارنات النص. التصفية على [CompanyId] = 1 أسرع من [CompanyName] = "ECOSIRE Private Limited". قم بتعيين رسائل البريد الإلكتروني للمستخدم على مفاتيح الأعداد الصحيحة في جدول تعيين الأمان.

تقليل عدد الجداول باستخدام مرشحات RLS. قم بتطبيق RLS على جداول الأبعاد ودع نشر العلاقة يتعامل مع جداول الحقائق. يؤدي تطبيق RLS مباشرةً على جداول البيانات الفعلية الكبيرة إلى إجبار Power BI على تقييم عامل التصفية في كل صف في جدول البيانات الفعلية.

التجميع المسبق عندما يكون ذلك ممكنًا. إذا كان المستخدم يحتاج فقط إلى بيانات على مستوى الملخص، ففكر في إنشاء جدول مجمع مسبقًا باستخدام مرشح الأمان المطبق أثناء ETL. يؤدي ذلك إلى تقليل حجم البيانات التي يحتاج Power BI إلى تصفيتها في وقت الاستعلام.

تجنب عوامل التصفية المتبادلة ثنائية الاتجاه. تزيد العلاقات ثنائية الاتجاه من تعقيد الاستعلام ويمكن أن تتعارض مع RLS. استخدم العلاقات أحادية الاتجاه (من البعد إلى الحقيقة) وقم بتطبيق RLS على جانب البعد.

---

المخاطر والحلول الشائعة

المأزق 1: لا يتم تطبيق RLS على مسؤولي مساحة العمل

يتجاوز مسؤولو مساحة العمل والأعضاء الذين لديهم إذن التحرير RLS. يرون دائمًا جميع البيانات. هذا حسب التصميم --- يحتاج المسؤولون إلى الوصول الكامل لإدارة مساحة العمل.

الحل: استخدم دور "العارض" لمستخدمي الأعمال الذين يجب أن يخضعوا لـ RLS. قم بمنح أدوار المسؤول/العضو/المساهم لفريق ذكاء الأعمال فقط.

المأزق 2: إزالة ALL() مرشحات RLS

تقوم الدالة DAX ALL() بإزالة كافة عوامل التصفية من الجدول، بما في ذلك عوامل تصفية RLS. إذا كان المقياس يستخدم ALL() في جدول تمت تصفيته بواسطة RLS، فقد يعرض بيانات لا ينبغي للمستخدم رؤيتها.

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

الحل: استخدم ALLSELECTED() بدلاً من ALL() عندما تريد إزالة مرشحات التقطيع/المرئية مع الحفاظ على مرشحات RLS:

-- 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 بشكل منفصل لجداول الاستيراد وجداول DirectQuery. يمكن أن يحتوي دور RLS واحد على مرشحات لكليهما، ولكن السلوك يختلف:

• استيراد الجداول: يتم تقييم مرشح RLS بواسطة محرك Power BI
• جداول DirectQuery: تتم ترجمة مرشح RLS إلى SQL وإرساله إلى المصدر

إذا كان مصدر DirectQuery لا يدعم وظيفة DAX المستخدمة في عامل تصفية RLS، فسوف يفشل الاستعلام.

المأزق 5: التقارير المرقّمة تتجاهل RLS

يمكن لتقارير Power BI المقسمة على صفحات (التي تم إنشاؤها في Report Builder) تجاوز RLS لمجموعة البيانات إذا كانت متصلة مباشرة بمصدر البيانات. لفرض RLS، يجب أن تتصل التقارير المقسمة إلى صفحات من خلال مجموعة بيانات Power BI (وليس مباشرة بقاعدة البيانات) ويجب أن يكون لدى المستخدم دور RLS معين.

---

نمط بنية RLS للمؤسسة

بالنسبة للمؤسسات الكبيرة، توصي ECOSIRE ببنية RLS موحدة:

تصميم طبقة الأمان

1. جدول تعيين الأمان المخزن في قاعدة بيانات مركزية (قائمة Azure SQL أو SharePoint)
2. ** دور RLS واحد ** يسمى "DynamicSecurity" باستخدام USERPRINCIPALNAME()
3. مزامنة مجموعة Azure AD التي تقوم تلقائيًا بملء جدول تعيين الأمان بناءً على عضوية المجموعة
4. دعم التسلسل الهرمي باستخدام جدول الوالدين والفرع الذي تم تسويته مسبقًا
5. مسار التدقيق لتسجيل المستخدمين الذين وصلوا إلى البيانات (عبر سجلات نشاط Power BI وREST API)

عملية الحوكمة

1. يحافظ مشرفو البيانات على جدول تعيين الأمان
2. تتم مراجعة التغييرات والموافقة عليها من خلال عملية إدارة التغيير
3. تقوم عمليات التدقيق الشهرية بمقارنة تعيينات Power BI RLS مع سجل نظام الموارد البشرية
4. يتحقق اختبار الاختراق ربع السنوي من فعالية RLS

تتسع هذه البنية لتشمل آلاف المستخدمين عبر مئات مجموعات البيانات مع الحفاظ على نقطة واحدة لإدارة الأمان.

---

الأسئلة الشائعة

هل يعمل RLS مع تراخيص Power BI المجانية؟

لا. يتطلب RLS تراخيص Power BI Pro أو Premium لكل مستخدم لجميع المستخدمين الذين يستخدمون التقارير المحمية بواسطة RLS. يمكن لمستخدمي الترخيص المجاني الوصول فقط إلى المحتوى الموجود في مساحة عمل ذات سعة مميزة، وحتى في هذه الحالة، فإنهم يحتاجون إلى ترخيص Pro أو PPU لتعيين أدوار RLS. في سيناريوهات Power BI Embedded، لا يحتاج المستخدمون النهائيون إلى تراخيص Power BI --- يتم فرض RLS من خلال الرمز المميز للتضمين.

هل يمكنني تنفيذ RLS استنادًا إلى مجموعات Azure AD بدلاً من المستخدمين الفرديين؟

ليس مباشرة. يقوم RLS الخاص بـ Power BI بتقييم تعبيرات DAX مقابل USERPRINCIPALNAME()، الذي يقوم بإرجاع البريد الإلكتروني للمستخدم الفردي. ومع ذلك، يمكنك إنشاء جدول تعيين أمان يقوم بتعيين مجموعات Azure AD إلى نطاقات البيانات وتعبئتها باستخدام Microsoft Graph API أو مزامنة عضوية مجموعة Azure AD. لا يزال تعبير DAX يقوم بالتصفية حسب البريد الإلكتروني للمستخدم، لكن جدول تعيين الأمان يوفر تعيين المجموعة إلى البيانات.

ماذا يحدث إذا لم يتم تعيين المستخدم لأي دور RLS؟

إذا تم تعريف RLS في مجموعة بيانات ولم يتم تعيين مستخدم لأي دور، فلن يرى المستخدم أي بيانات. يتم تحميل التقرير ولكن تظهر كافة العناصر المرئية فارغة أو صفر. هذا هو الإعداد الافتراضي الآمن --- يفترض Power BI عدم الوصول ما لم يتم منحه صراحةً. ومع ذلك، فإن مسؤولي مساحة العمل والأعضاء الذين لديهم إذن تحرير يتجاوزون RLS ويرون دائمًا جميع البيانات بغض النظر عن تعيينات الأدوار.

هل يمكن لـ RLS تصفية البيانات في لوحات المعلومات في الوقت الفعلي؟

نعم. يعمل RLS مع كل من وضعي الاستيراد وDirectQuery. في وضع DirectQuery، تتم ترجمة مرشح RLS إلى جملة SQL WHERE وإرساله إلى قاعدة البيانات مع كل استعلام، بحيث تتم التصفية في الوقت الفعلي. في وضع الاستيراد، يتم تطبيق التصفية في الذاكرة عندما يفتح المستخدم التقرير. يوفر كلا الوضعين نفس ضمان الأمان --- يرى المستخدم فقط البيانات المصرح بها.

كيف يمكنني تدقيق من وصل إلى البيانات من خلال RLS؟

يوفر Power BI سجلات الأنشطة من خلال مركز إدارة Microsoft 365 وPower BI REST API. تسجل هذه السجلات طرق عرض التقارير وتحديثات مجموعة البيانات وعمليات التصدير، بما في ذلك هوية المستخدم. ومع ذلك، لا تسجل السجلات الصفوف المحددة التي شاهدها المستخدم. للحصول على تدقيق تفصيلي للوصول إلى البيانات، قم بتمكين التدقيق على مستوى قاعدة البيانات (على سبيل المثال، PostgreSQL pgaudit أو تدقيق Azure SQL) لتسجيل الاستعلامات الفعلية التي تم إنشاؤها بواسطة DirectQuery مع تطبيق عوامل تصفية RLS.