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

مكتمل

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

بدون الأدوار، أي مستخدم لديه صلاحية استعلام إلى النموذج الدلالي يرى جميع البيانات. يطبق RLS على جميع مسارات الاستهلاك: تقارير Power BI، التقارير المرجحة، دردشة Copilot، ووكلاء بيانات Fabric. هذا يعني أن إعداد الأمان الخاص بك يحمي البيانات باستمرار بغض النظر عن كيفية وصول المستخدمين إليها.

افهم كيف يعمل RLS مع مخططات النجوم

يعمل RLS بشكل أفضل مع تصاميم مخططات النجوم حيث ترتبط جداول الأبعاد بجداول الحقائق من خلال علاقات النماذج. تقوم بإنشاء تعبيرات مرشح على جداول الأبعاد، وينقل Power BI تلك الفلاتر إلى جداول حقائق عبر العلاقات. هذا النهج أكثر كفاءة من تصفية جداول الحقائق مباشرة لأن جداول الأبعاد عادة ما تحتوي على صفوف أقل بكثير.

على سبيل المثال، اعتبر نموذجا يحتوي على جدول أبعاد المنطقة وجدول حقائق المبيعات . عند تطبيق مرشح RLS على جدول Region ل "Midwest"، Power BI تتبع الخطوات التالية:

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

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

Tip

جداول أبعاد التصفية، وليس جداول الحقائق. تنشر علاقات النماذج مرشحات الأبعاد إلى جداول الحقائق بكفاءة، مما يوفر أداء استعلام أسرع.

إنشاء أدوار أمنية

تقوم بإنشاء الأدوار في Power BI سطح المكتب من تبويب Modeling باختيار إدارة الأدوار. يمكنك أيضا إنشاء وإدارة أدوار في تجربة نمذجة الويب في Fabric. لكل دور اسم فريد وتعبير أو أكثر من تعبيرات مرشح DAX على جداول محددة.

لإنشاء دور في Power BI Desktop:

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

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

استخدم الأمان الديناميكي مع USERPRINCIPALNAME()

الأمان الديناميكي هو النهج الموصى به لمعظم السيناريوهات. بدلا من إنشاء أدوار منفصلة لكل مستخدم أو مجموعة، تقوم بإنشاء دور واحد مع تعبير DAX يقيم هوية المستخدم المسجل.

تعيد الوظيفة USERPRINCIPALNAME() عنوان البريد الإلكتروني للمستخدم المصادق عليه بصيغة user@domain.com . تستخدم هذه الوظيفة لمطابقة المستخدم الحالي مع عمود في نموذج بياناتك.

-- Filter the Salesperson table to the current user
[SalesPersonEmail] = USERPRINCIPALNAME()

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

يتوسع الأمان الديناميكي لأن إضافة أو إزالة المستخدمين هو تغيير بيانات وليس تغيير نموذجي. لا تحتاج إلى إنشاء أدوار جديدة أو إعادة نشر النموذج الدلالي عندما يتغير أعضاء الفريق.

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

تنفيذ نمط جدول الأمان

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

-- Filter through a security table that maps users to regions
CONTAINS(
    SecurityTable,
    SecurityTable[UserEmail], USERPRINCIPALNAME(),
    SecurityTable[Region], [Region]
)

يقوم هذا النمط بتعيين كل مستخدم إلى منطقة أو أكثر في جدول الأمان. عندما يسجل المستخدم الدخول، يقوم Power BI بتقييم دالة CONTAINS مقابل جدول الأمان ويعيد فقط الصفوف التي تطابق المناطق المخصصة له.

يقدم نمط جدول الأمان عدة مزايا:

• الإدارة المركزية. جميع عمليات التعيين بين المستخدم والبيانات موجودة في جدول واحد.
• مهام متعددة القيم. يمكن لمستخدم واحد أن يربط بين عدة مناطق أو أقسام.
• تحديثات قائمة على البيانات. تغيير الوصول يتطلب تحديث بيانات جدول الأمان، وليس تعريف النموذج.

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

فهم قواعد RLS الثابتة

تستخدم القواعد الثابتة تعبيرات DAX التي تشير إلى القيم الثابتة بدلا من هوية المستخدم. على سبيل المثال، يمكنك إنشاء قاعدة تقيد الدور على منطقة الغرب الأوسط فقط:

-- Static filter: only Midwest data is visible
[Region] = "Midwest"

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

ملاحظة

القواعد الديناميكية مع USERPRINCIPALNAME() هي النهج الموصى به لمعظم نماذج الإنتاج. استخدم قواعد ثابتة فقط في السيناريوهات الصغيرة والثابتة حيث من غير المرجح أن ينمو عدد الأقسام الداخلية.

فهم USERNAME() مقابل USERPRINCIPALNAME()

كلتا الدالتين تعيدان هوية المستخدم المسجل، لكنهما تختلفان في الشكل:

الوظيفة	سطح مكتب Power BI	خدمة Power BI
USERNAME()	DOMAIN\username	user@domain.com
USERPRINCIPALNAME()	user@domain.com	user@domain.com

USERNAME() يعيد صيغ مختلفة حسب البيئة. USERPRINCIPALNAME() دائما ما يعيد صيغة اسم المستخدم. استخدم USERPRINCIPALNAME() لتحقيق الاتساق عند الاختبار في سطح المكتب والنشر على الخدمة.

ملاحظة

RLS الثابت: بالنسبة للسيناريوهات الصغيرة والثابتة يمكنك ترميز فلاتر مثل [Region] = "West". القواعد الثابتة بسيطة لكنها لا تتوسع. كل منطقة جديدة تتطلب دورا جديدا أو تحديثا لقواعد. القواعد الديناميكية مع USERPRINCIPALNAME() هي النهج الموصى به لمعظم نماذج الإنتاج.

فكر في DirectQuery مع تسجيل دخول واحد

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

ملاحظة

عند استخدام SSO مع DirectQuery، يتحكم مصدر البيانات في تطبيق الأمن. للتفاصيل، راجع أمان مستوى الصف مع Power BI.

تحسين أداء RLS

يمكن أن تؤثر تعبيرات مرشح DAX المعقدة على سرعة الاستعلام. اتبع هذه الممارسات للحفاظ على سرعة الاستفسارات:

• جداول أبعاد التصفية. تقوم العلاقات بنقل المرشحات إلى جداول الحقائق بكفاءة أكبر من الترشيح المباشر لجداول الحقائق.
• تجنب LOOKUPVALUE. استخدم علاقات النماذج لنشر الفلاتر بدلا من ذلك.
• اختبر ببيانات واقعية. قد يتباطأ المرشح الذي يؤدي أداء جيدا على مجموعة بيانات صغيرة مع بيانات على نطاق الإنتاج.
• قس تأثير متلازمة تململ ساقي. استخدم محلل الأداء في Power BI Desktop لمقارنة مدة الاستعلام مع وبدون تطبيق RLS.

Tip

استخدم Copilot لإنشاء تعبيرات مرشح DAX لأدوار RLS. على سبيل المثال، اطلب من Copilot إنشاء فلتر جدول أمني باستخدام USERPRINCIPALNAME() لنموذج بياناتك المحدد.