امنیت در Power BI؛ RLS، Dynamic RLS و کنترل دسترسی

کتاب جامع Power BI — آموزش پروژه‌محور، تصویری و کاربردی

مقدمه؛ همه نباید همه‌چیز را ببینند

در فصل قبل گزارش شرکت هانا را منتشر کردیم. حالا فرض کن مدیر شعبه تهران وارد گزارش می‌شود. آیا باید فروش اصفهان و تبریز را هم ببیند؟ معمولاً نه. اینجا امنیت سطح داده وارد ماجرا می‌شود.

در این فصل با زبان ساده یاد می‌گیریم RLS چیست، چطور Role می‌سازیم، Dynamic RLS چه مشکلی را حل می‌کند و چطور دسترسی گزارش را از امنیت ردیف‌های داده جدا کنیم.

۱۰.۱. دو سؤال امنیتی متفاوت

شکل ۱۰-۱ — تفاوت مجوز باز کردن گزارش و امنیت داده

سؤال اول این است که آیا کاربر اصلاً اجازه باز کردن Report یا App را دارد؟ سؤال دوم این است که اگر وارد شد، کدام ردیف‌های داده را باید ببیند؟ این دو را نباید یکی فرض کنیم.

۱۰.۲. RLS چیست؟

Row-Level Security یا RLS یعنی محدود کردن ردیف‌های قابل مشاهده بر اساس Role یا هویت کاربر.

شکل ۱۰-۲ — مفهوم ساده Row-Level Security

مثلاً Role تهران فقط رکوردهایی را ببیند که BranchName برابر تهران است.

۱۰.۳. Static RLS

در مدل ساده می‌توانیم برای هر گروه یک Role ثابت تعریف کنیم.

[BranchName] = "تهران"

این روش برای تعداد کم نقش‌ها قابل فهم است، اما اگر ۱۰۰ شعبه داشته باشیم ساختن ۱۰۰ Role معمولاً راه‌حل خوبی نیست.

۱۰.۴. Manage Roles

در Power BI Desktop از بخش مدیریت Roleها می‌توانیم فیلتر امنیتی تعریف کنیم. بهتر است فیلتر روی Dimension مناسب قرار بگیرد تا از طریق Relationship به Fact منتقل شود.

DimBranch filtered
      ↓
Relationship
      ↓
FactSales filtered

۱۰.۵. Test as Role

قبل از انتشار باید Role را تست کنیم. با View as / Test as Role بررسی می‌کنیم که کاربر فرضی واقعاً فقط داده مجاز را می‌بیند.

نکته: امنیت را با نگاه کردن به فرمول تأیید نکن؛ خروجی واقعی Role را تست کن.

۱۰.۶. مشکل Static RLS در سازمان بزرگ

اگر برای هر شعبه، منطقه یا کارشناس Role جدا بسازیم، نگهداری مدل سخت می‌شود. با تغییر نیروی انسانی هم باید Roleها را مرتب ویرایش کنیم.

اینجا Dynamic RLS معمولاً انتخاب مقیاس‌پذیرتری است.

۱۰.۷. Dynamic RLS چیست؟

در Dynamic RLS به جای اینکه Role برای هر فرد بسازیم، هویت کاربر را می‌خوانیم و از یک جدول نگاشت می‌فهمیم او اجازه دیدن چه داده‌ای را دارد.

۱۰.۸. جدول Security Mapping

این جدول نشان می‌دهد هر کاربر به کدام شعبه‌ها دسترسی دارد. یک مدیر منطقه‌ای می‌تواند چند ردیف داشته باشد.

۱۰.۹. USERPRINCIPALNAME

در سناریوهای رایج Dynamic RLS از هویت کاربر جاری استفاده می‌کنیم.

Security[UserEmail] = USERPRINCIPALNAME()

مقدار هویت باید با ساختار داده جدول Security هماهنگ باشد. اختلاف قالب نام کاربری و ایمیل می‌تواند باعث شود کاربر هیچ داده‌ای نبیند.

۱۰.۱۰. Relationship امنیتی

جدول Security باید از طریق مدل به Dimension و Fact مناسب وصل شود. طراحی Relationship در امنیت خیلی مهم است؛ چون مسیر فیلتر تعیین می‌کند محدودیت تا کجا منتقل شود.

SecurityUserBranch → DimBranch → FactSales

۱۰.۱۱. مدیرعامل چه می‌شود؟

مدیرعامل ممکن است نیاز به دیدن همه شعب داشته باشد. می‌توانیم طراحی Mapping را طوری انجام دهیم که نقش مدیریتی مناسب همه محدوده‌های مجاز را پوشش دهد.

راه‌حل باید بر اساس ساختار واقعی سازمان طراحی شود، نه با استثناهای پراکنده و غیرقابل نگهداری.

۱۰.۱۲. چند سطح سازمانی

گاهی ساختار فقط شعبه نیست: کشور، منطقه، استان، شعبه و تیم فروش داریم.

Country
 └── Region
      └── Province
           └── Branch
                └── Sales Team

مدل امنیتی باید با Hierarchy واقعی کسب‌وکار هماهنگ باشد.

۱۰.۱۳. امنیت مشتری

سناریوی دیگر این است که هر Account Manager فقط مشتریان خودش را ببیند. جدول نگاشت می‌تواند User ↔ Customer یا User ↔ SalesTerritory باشد.

پس RLS فقط برای شعبه نیست؛ هر بعدی که مالکیت یا محدوده دسترسی دارد می‌تواند بخشی از طراحی امنیت باشد.

۱۰.۱۴. امنیت و Many-to-Many

وقتی یک کاربر به چند شعبه و هر شعبه به چند ساختار دیگر مرتبط است، مدل امنیت می‌تواند پیچیده شود. Many-to-Many و Bidirectional Filter را بدون تحلیل وارد امنیت نکن.

مدل امنیت باید قابل توضیح، تست‌پذیر و قابل ممیزی باشد.

۱۰.۱۵. RLS جای Permission را نمی‌گیرد

اگر کاربری اصلاً نباید گزارش مالی را ببیند، فقط RLS کافی نیست؛ دسترسی به App یا محتوای مربوطه هم باید کنترل شود.

Content Permission + Data Security = Complete Access Design

۱۰.۱۶. اصل Least Privilege

اصل حداقل دسترسی می‌گوید کاربر فقط همان دسترسی لازم برای انجام کارش را داشته باشد. این اصل را هم در Workspace Role و هم در داده رعایت کن.

۱۰.۱۷. امنیت در Workspace

توسعه‌دهنده، مدیر BI و مصرف‌کننده نهایی نقش‌های یکسانی ندارند. کاربران نهایی معمولاً نباید صرفاً برای دیدن گزارش، سطح مدیریتی Workspace دریافت کنند.

۱۰.۱۸. App Audience

برای گروه‌های مختلف می‌توان تجربه مصرف مناسب طراحی کرد. مدیرعامل، مدیر فروش و مدیر شعبه ممکن است صفحات یا محتوای متفاوتی نیاز داشته باشند.

اما Audience و RLS را یکی ندان؛ Audience روی ارائه محتوا اثر دارد و RLS روی ردیف‌های قابل مشاهده.

۱۰.۱۹. تست امنیتی سناریومحور

برای هر Role یا گروه امنیتی Test Case مشخص داشته باش.

۱۰.۲۰. کاربر بدون Mapping

باید از قبل تصمیم بگیریم اگر کاربر در جدول Security نبود چه اتفاقی بیفتد. طراحی امن معمولاً نباید به شکل ناخواسته دسترسی کامل بدهد.

نکته: Fail closed: نبود Mapping نباید به معنی «همه داده‌ها را نشان بده» باشد.

۱۰.۲۱. تغییر سمت سازمانی

فرض کن مدیر تهران به اصفهان منتقل شده است. اگر امنیت مبتنی بر جدول Mapping باشد، تغییر دسترسی می‌تواند از طریق داده مرجع امنیتی مدیریت شود و لازم نیست ده‌ها Measure یا صفحه را تغییر دهیم.

۱۰.۲۲. مستندسازی امنیت

مدل امنیت باید مستند شود: منبع هویت چیست؟ Mapping کجاست؟ چه کسی مالک آن است؟ تغییر دسترسی با تأیید چه کسی انجام می‌شود؟

امنیت فقط DAX نیست؛ یک فرایند سازمانی هم هست.

۱۰.۲۳. خطاهای رایج RLS

خطای اول: ساخت Role جدا برای تعداد زیادی کاربر.

خطای دوم: فیلتر امنیتی روی جدول اشتباه.

خطای سوم: Relationship نامناسب که فیلتر را منتقل نمی‌کند.

خطای چهارم: ناهماهنگی Email و User Principal Name.

خطای پنجم: تست نکردن کاربر بدون Mapping.

خطای ششم: دادن Workspace Permission زیاد و امید بستن فقط به RLS.

خطای هفتم: استفاده بی‌دلیل از Bidirectional Security Filter.

۱۰.۲۴. Best Practiceهای امنیت

امنیت را از مرحله طراحی مدل در نظر بگیر.

Static RLS را برای سناریوهای واقعاً ساده نگه دار.

برای ساختارهای بزرگ Dynamic RLS را بررسی کن.

جدول Mapping را منبع قابل اعتماد و مدیریت‌شده قرار بده.

همه سناریوهای کاربری را تست کن.

اصل Least Privilege را رعایت کن.

تغییرات دسترسی را مستند و قابل ممیزی نگه دار.

۱۰.۲۵. تمرین پایه

برای DimBranch دو Role ثابت تهران و اصفهان تعریف کن و هر کدام را با View as Role تست کن.

۱۰.۲۶. تمرین متوسط

یک جدول UserBranch با Email و BranchKey بساز. Dynamic RLS را بر اساس USERPRINCIPALNAME طراحی کن و دو کاربر فرضی را تست کن.

۱۰.۲۷. تمرین کاربردی

یک مدیر منطقه‌ای بساز که به سه شعبه دسترسی دارد. بررسی کن ساختار Mapping چگونه باید باشد تا بدون ساخت Role جدید کار کند.

۱۰.۲۸. تمرین چالشی

سناریوی امنیتی طراحی کن که مدیرعامل همه داده‌ها، مدیر منطقه چند شعبه، مدیر شعبه یک شعبه و فروشنده فقط مشتریان خودش را ببیند.

مدل و جدول‌های Mapping لازم را روی کاغذ رسم کن.

۱۰.۲۹. پروژه نهایی فصل؛ Security Model شرکت هانا

برای داشبورد شرکت هانا یک مدل امنیت سازمانی طراحی کن.

در خروجی پروژه باید Diagram، جدول Mapping، Rule امنیتی و Test Case هر نقش مشخص باشد.

جمع‌بندی فصل دهم

امنیت Power BI فقط این نیست که چه کسی لینک گزارش را دارد. باید مشخص کنیم چه کسی وارد محتوا می‌شود و بعد از ورود دقیقاً چه داده‌ای می‌بیند.

Identity
   ↓
Permission
   ↓
RLS / Dynamic RLS
   ↓
Filtered Data
   ↓
Secure Analytics

در فصل بعد وارد Performance Optimization می‌شویم: چرا بعضی گزارش‌ها کند می‌شوند، مدل را چطور سبک کنیم، DAX را چگونه بررسی کنیم و چه چیزهایی روی سرعت Refresh و Visualها اثر می‌گذارند.