لماذا يعمل أمان مستوى الصف (RLS) في Power BI Desktop لكنه يتسرب في Fabric

By Mirko Peters · 2026-08-11

مرحبًا بعودتكم إلى مدونة هندسة البيانات والتحليلات! إذا سبق لكم أن بنيتم لوحة معلومات متقنة، وتحققتم من أمان مستوى الصف (Row-Level Security) محليًا في Power BI Desktop، ثم نشرتموها على السحابة، وفزعتم عندما تمكّن مستخدم عادي من الوصول إلى معلومات لا يحق له رؤيتها، فأنتم بالتأكيد لستم وحدكم. تُعد بنية الأمان في بيئات التحليلات الحديثة معقدة بشكل معروف. وعند الانتقال من التطوير المحلي إلى منصات واسع

Automatically translated with AI from the original post. Read the English original

Titelbild: Why Your Power BI RLS Works in Desktop But Leaks in Fabric

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

المفاهيم الأساسية (النموذج الذهني)

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

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

تصميم مرشحات قادرة على الصمود (أنماط DAX)

كتابة تعبيرات DAX آمنة لأدوارکم هي حجر الأساس في عزل البيانات بفعالية. وبحسب البنية التنظيمية للمؤسسة وحجمها، ستختارون على الأرجح بين أنماط التصفية الثابتة والديناميكية.

أمان مستوى الصف الثابت (بسيط، وجمهور محدد)

مثال على DimRegion:
DimRegion[Region] = "US"

أمان مستوى الصف الديناميكي عبر جدول الربط (موصى به)

الجداول: Users (UPN, UserKey)، UserRegion (UserKey, RegionKey)، DimRegion (RegionKey, Region)
مرشح الدور على Users:
Users[UPN] = USERPRINCIPALNAME()
يمكنكم اختياريًا تقييد DimRegion باستخدام علاقة من Users > UserRegion > DimRegion.

تجنبوا

الأمان القائم على الأعمدة المحسوبة، لأنه يُقيَّم وقت تحديث البيانات وليس ديناميكيًا حسب سياق كل مستخدم.
استخدام USERNAME() في Fabric (استخدموا USERPRINCIPALNAME() دائمًا، واختبروا تنسيقات البريد الإلكتروني ولواحق UPN بدقة).
ترميز عناوين بريد إلكتروني فردية أو نطاقات مباشرة داخل تعبيرات التصفية.

أنماط ديناميكية مفيدة

النماذج متعددة المستأجرين: اربطوا TenantId من جدول Users المركزي مباشرة إلى جداول الحقائق والأبعاد.
التسلسلات الهرمية: خزّنوا روابط المدير والمرؤوسين، وأنشئوا جدول وصول فعليًا، وصفّوا حسب جميع المستويات الهيكلية التابعة للمستخدم الحالي.

تصميم الأدوار والعلاقات

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

الإسنادات بلا مفاجآت (المستخدمون والمجموعات)

إدارة التعيينات بكفاءة أمر حيوي للصحة التشغيلية على المدى الطويل. اربط أدوارك دائمًا بمجموعات Azure AD بدلًا من حسابات المستخدمين الفردية، لضمان أن يتوسع النظام بسلاسة مع تنقل الموظفين بين الفرق. احترس من عضويات المجموعات المتداخلة، فالمستخدمون المنتمون إلى عدة مجموعات أمان قد يوسّعون وصولهم إلى البيانات دون قصد. وتجنب العضويات القديمة بجدولة مراجعات وصول ربع سنوية مع مالكي المجموعات.

Desktop مقابل Fabric: ما الذي يتغير بعد النشر

هنا تحدث معظم تسربات الأمان. في Power BI Desktop، أنت تعمل ضمن بيئة محلية مضبوطة ومعزولة. وبمجرد النشر إلى Microsoft Fabric، تتولى السحابة إدارة الهوية. تُرجع الدالة USERPRINCIPALNAME() عنوان البريد الإلكتروني السحابي في Fabric، بينما قد تختلف معاينات Desktop وفقًا لبيانات الاعتماد المحلية. علاوةً على ذلك، يمكن لمالك مجموعة البيانات، وبيانات اعتماد التحديث، وإعدادات مساحة العمل، والتأخر في مزامنة المجموعات في Azure AD أن تغيّر جميعها ما يُسمح للمستخدم فعلًا برؤيته.

اختبار يكشف التسربات فعلًا

لا تعتمد أبدًا على ميزة "عرض كـ" في Power BI Desktop وحدها للموافقة على أمان بيئة الإنتاج. فهي مفيدة للفحوص السريعة، لكن يجب أن تختبر داخل Fabric. تحقق باستخدام مجموعات أمان حقيقية وحسابات مستخدمين حقيقية في مساحة عمل غير إنتاجية. اختبر كل دور على حدة في صفحات التقارير الأساسية والعناصر المرئية الحساسة. فكّر في جدولة فحوص عينية عبر نقاط نهاية XMLA أو أدوات الأتمتة لتصدير مجموعات نتائج صغيرة لحسابات اختبار معروفة.

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

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

أنماط الفشل الشائعة (والحلول)

إذا واجهت مشكلات، فتحقق من هذه أنماط الفشل الشائعة:

يعمل في Desktop ويتسرب في Fabric: يحدث بسبب استخدام USERNAME() أو تنسيقات هوية غير متطابقة. الحل: وحّد الاعتماد على USERPRINCIPALNAME() ومواءمة قيم Users[UPN].
يرى المستخدم أكثر مما ينبغي: يحدث بسبب مسار من نوع متعدد إلى متعدد يتجاوز الأمان. الحل: أضف بُعد أمان وشدّد العلاقات.
يستمر وصول الفريق السابق: يحدث بسبب عضويات قديمة في مجموعات Azure AD. الحل: أتمتة سير عمل إعادة الاعتماد وعمليات الإزالة.
استخدام عمود محسوب للهوية: يؤدي إلى عدم وجود أثر خاص بكل مستخدم. الحل: انقل المنطق إلى DAX لمرشح الدور على جداول النموذج.

قائمة التحقق السريعة للبدء (هذا الأسبوع)

أضف جدول Users مفهرسًا بـ USERPRINCIPALNAME() واربطه بجداول الوصول لديك.
حوّل المرشحات الثابتة المكتوبة يدويًا إلى مرشحات ديناميكية تعتمد على الجداول حيثما كان ذلك مناسبًا.
استبدل أي منطق يعتمد على USERNAME() بـ USERPRINCIPALNAME() وأعد الاختبار في Fabric.
اربط الأدوار بمجموعات AAD وجدول مراجعة وصول مع مالكي المجموعات.
انشر إلى مساحة عمل اختبار، وتحقق مع مستخدمين حقيقيين، وأصلح أي ثغرات في الهوية.
وثّق أدوارك وDAX والجداول داخل ملف README الخاص بالنموذج.

أصول تحسين محركات البحث المقترحة

المعرّف في الرابط (slug): power-bi-row-level-security-architecture
عنوان الصفحة للمحركات: أمان مستوى الصف في Power BI: البنية، وأنماط DAX، والحوكمة الجاهزة للسحابة
وصف الميتا: تجاوز مجرد خانة RLS. تعلّم أنماط DAX الديناميكية، وتصميم الأدوار، وربط Azure AD، والاختبار الخاص بـ Fabric للحفاظ على أمان البيانات الحساسة حقًا.
الكلمات المفتاحية: Power BI، Row-Level Security، RLS، USERPRINCIPALNAME، مجموعات Azure AD، Fabric، dynamic RLS، حوكمة البيانات

الخاتمة

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

لتعمّق أكثر في هذا الموضوع وتستمع إلى استراتيجيات تطبيق عملية، تأكد من الاطلاع على حلقة البودكاست ذات الصلة: Implement Power BI Row-Level Security in Microsoft Fabric. لا تكتفِ بتقييد الوصول إلى بياناتك، بل صمّم بنية أمنية مرنة تتكيّف مع تطور مؤسستك!