امنیت Enterprise در Power BI؛ RLS، OLS، Least Privilege و Audit

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

مقدمه؛ امنیت یعنی «چه کسی دقیقاً چه چیزی را ببیند؟»

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

در این فصل امنیت را لایه‌ای نگاه می‌کنیم؛ از Identity و دسترسی Workspace تا RLS، OLS، منبع داده، Gateway و Audit.

۱۸.۱. Defense in Depth

یک Rule در RLS کل امنیت سازمان نیست. امنیت قوی از چند کنترل مکمل تشکیل می‌شود تا شکست یک لایه به معنی دسترسی آزاد نباشد.

۱۸.۲. Authentication و Authorization

این دو را قاطی نکن؛ ورود موفق کاربر به معنی مجاز بودن او برای دیدن همه داده‌ها نیست.

۱۸.۳. اصل Least Privilege

کاربر باید فقط حداقل دسترسی لازم برای انجام وظیفه‌اش را داشته باشد؛ نه دسترسی اضافه برای اینکه تنظیمات راحت‌تر شود.

نکته: دسترسی اضافه‌ای که امروز بی‌خطر به نظر می‌رسد، فردا می‌تواند تبدیل به ریسک امنیتی شود.

۱۸.۴. لایه‌های دسترسی

۱۸.۵. Workspace Role

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

برای مصرف‌کننده نهایی معمولاً تجربه App یا روش توزیع کنترل‌شده مناسب‌تر از دادن دسترسی توسعه‌ای است.

۱۸.۶. Security Matrix

Security Matrix را قبل از نوشتن DAX امنیتی طراحی کن.

۱۸.۷. RLS چیست؟

Row-Level Security یعنی کاربر فقط ردیف‌هایی را ببیند که مجاز است.

BranchKey = 10
→ user sees only rows related to Branch 10

۱۸.۸. Static RLS

در Static RLS برای Role یک شرط ثابت تعریف می‌کنیم؛ مثلاً Role تهران فقط BranchKey مربوط به تهران را ببیند.

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

۱۸.۹. Dynamic RLS

در Dynamic RLS هویت کاربر با یک جدول Security Mapping به محدوده مجاز متصل می‌شود.

۱۸.۱۰. جدول Security Mapping

SecurityUserScope
UserEmail              ScopeType   ScopeKey
manager.a@company.com  Region      10
branch1@company.com    Branch      101

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

۱۸.۱۱. USERPRINCIPALNAME

SecurityUserScope[UserEmail] = USERPRINCIPALNAME()

در سناریوهای Dynamic RLS از هویت جاری برای پیدا کردن Scope مجاز استفاده می‌شود. مقدار واقعی هویت را در محیط مقصد تست کن.

۱۸.۱۲. یک کاربر با چند Scope

ممکن است یک مدیر مسئول چند شعبه باشد. در این حالت جدول Mapping می‌تواند چند ردیف برای همان User داشته باشد.

manager@company.com | Branch | 101
manager@company.com | Branch | 102
manager@company.com | Branch | 107

۱۸.۱۳. Hierarchical Security

گاهی Scopeها سلسله‌مراتبی‌اند: مدیر کشور، مدیر منطقه، مدیر شعبه. مدل امنیت باید بتواند این ساختار را بدون صدها Rule تکراری مدیریت کند.

طراحی دقیق آن به مدل سازمان و Relationshipهای مدل بستگی دارد.

۱۸.۱۴. Default Deny

برای کاربر ناشناخته رفتار امن تعریف کن. در بسیاری از سناریوها بهتر است اگر Mapping معتبر پیدا نشد داده‌ای نمایش داده نشود.

Known user → allowed scope
Unknown user → no business rows

این سیاست باید با نیاز سازمان تأیید شود.

۱۸.۱۵. RLS را با UX اشتباه نکن

مخفی کردن Slicer یا Page امنیت نیست. اگر کاربر از راه دیگری بتواند داده را Query کند، امنیت واقعی نداریم.

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

۱۸.۱۶. OLS چیست؟

Object-Level Security برای محدود کردن دسترسی به Objectهایی مثل Table یا Column در مدل کاربرد دارد.

مثلاً گروهی از کاربران نباید ستون Cost یا Salary را در مدل ببینند.

۱۸.۱۷. RLS در برابر OLS

۱۸.۱۸. داده حساس

ستون‌هایی مثل حقوق، اطلاعات شخصی، شماره‌های شناسایی یا Margin محرمانه باید فقط در صورت نیاز واقعی وارد مدل شوند.

بهترین امنیت برای داده‌ای که لازم نیست، وارد نکردن آن به مدل است.

۱۸.۱۹. Data Minimization

Need Customer Name? Yes
Need National ID? No
→ Do not load National ID

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

۱۸.۲۰. Source Security

اگر Power BI از SQL Server داده می‌گیرد، امنیت منبع هم مهم است. حساب اتصال باید فقط دسترسی لازم را داشته باشد.

دادن db_owner برای اینکه اتصال سریع راه بیفتد نمونه خوبی از نقض Least Privilege است.

۱۸.۲۱. Gateway Security

Gateway یک پل بین Cloud Service و منابع داخل شبکه است؛ پس Host، Credential، دسترسی مدیریتی و Patch آن باید جدی گرفته شود.

مالکیت Gateway را سازمانی تعریف کن، نه وابسته به یک نفر.

۱۸.۲۲. Service Account

در اتصال‌های سازمانی معمولاً بهتر است Credentialهای حیاتی به حساب شخصی توسعه‌دهنده وابسته نباشند.

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

۱۸.۲۳. Service Principal؛ مفهوم

برای بعضی سناریوهای Automation و Integration می‌توان از هویت برنامه‌ای به جای حساب انسانی استفاده کرد.

جزئیات مجوزها و پشتیبانی قابلیت‌ها وابسته به سرویس و تنظیمات جاری است و باید مستندات رسمی همان زمان بررسی شود.

۱۸.۲۴. Secure Sharing

قبل از Share کردن Report بپرس: مخاطب کیست؟ داخل سازمان است یا بیرون؟ آیا فقط View لازم دارد؟ آیا Export مجاز است؟

روش توزیع باید بر اساس طبقه‌بندی داده و سیاست سازمان انتخاب شود.

۱۸.۲۵. App به جای اشتراک پراکنده

در سناریوهای سازمانی، App می‌تواند تجربه توزیع کنترل‌شده‌تری نسبت به Shareهای پراکنده ایجاد کند.

اما App هم جای RLS و سیاست امنیتی را نمی‌گیرد.

۱۸.۲۶. Export Risk

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

کنترل‌های دقیق در سطح Tenant و سرویس ممکن است تغییر کنند؛ تنظیمات جاری سازمان را بررسی کن.

۱۸.۲۷. Audit

برای محیط سازمانی باید بتوانیم تا حد مناسب بفهمیم چه کسی چه عملی انجام داده یا چه تغییری روی محتوا رخ داده است.

۱۸.۲۸. چه چیزهایی برای Audit مهم‌اند؟

۱۸.۲۹. Separation of Duties

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

Developer → Reviewer → Release approval

۱۸.۳۰. Break Glass Access

برای شرایط اضطراری ممکن است سازمان دسترسی ویژه‌ای تعریف کند، اما باید محدود، ثبت‌شده و قابل Audit باشد.

این دسترسی نباید تبدیل به راه عادی دور زدن Security Process شود.

۱۸.۳۱. Security Testing

۱۸.۳۲. Test as Role

قبل از انتشار، Roleها را با سناریوهای واقعی تست کن. فقط اینکه DAX Rule بدون Error ذخیره شده کافی نیست.

بعد از تغییر Relationshipها هم تست امنیت را تکرار کن.

۱۸.۳۳. Relationship و Security

مسیر Filter در مدل روی RLS اثر دارد. Relationshipهای پیچیده یا دوطرفه باید با دقت بررسی شوند تا Scope امنیتی ناخواسته گسترش پیدا نکند.

۱۸.۳۴. Performance و RLS

Security Filter هم بخشی از Query است و در مدل‌های بزرگ می‌تواند روی Performance اثر داشته باشد.

اول امنیت را درست طراحی کن، سپس با سناریوی واقعی کاربران Benchmark بگیر.

۱۸.۳۵. Security Review دوره‌ای

کاربرانی که سمتشان تغییر کرده، گروه‌های قدیمی، حساب‌های بلااستفاده و Mappingهای منسوخ باید دوره‌ای بررسی شوند.

Joiner → grant
Mover → review/change
Leaver → revoke

۱۸.۳۶. Joiner-Mover-Leaver

این چرخه ساده یکی از مهم‌ترین فرایندهای Identity Governance است: ورود کارمند، تغییر سمت و خروج او باید روی دسترسی BI اثر مشخص داشته باشد.

۱۸.۳۷. امنیت شرکت هانا

در شرکت هانا CEO همه شرکت را می‌بیند، مدیر منطقه فقط شعب منطقه خودش، مدیر شعبه فقط شعبه خودش و کارشناس فروش فقط Customerهای تخصیص‌یافته را.

Cost و Margin جزئی برای برخی گروه‌ها محدود می‌شوند.

۱۸.۳۸. مدل پیشنهادی شرکت هانا

Identity
  ↓
SecurityUserScope
  ↓
Region / Branch / Customer Scope
  ↓
FactSales

Sensitive Objects
  ↓
OLS / controlled access

۱۸.۳۹. Incident امنیتی فرضی

فرض کن مدیر شعبه بعد از تغییر سمت هنوز داده شعبه قبلی را می‌بیند. این یک مشکل Access Governance است.

Mapping اصلاح می‌شود، دسترسی Validate می‌شود و علت اینکه فرایند Mover اجرا نشده ثبت می‌شود.

۱۸.۴۰. Security Checklist قبل از Go-Live

۱۸.۴۱. خطاهای رایج

خطای اول: مخفی کردن Page را Security دانستن.

خطای دوم: Workspace Admin دادن به مصرف‌کننده.

خطای سوم: Dynamic RLS بدون Default Deny روشن.

خطای چهارم: حساب شخصی برای اتصال حیاتی.

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

خطای ششم: تست نکردن RLS بعد از تغییر مدل.

خطای هفتم: فراموش کردن دسترسی کارمند بعد از تغییر سمت.

۱۸.۴۲. Best Practiceها

Least Privilege را مبنا قرار بده.

Security Matrix را قبل از پیاده‌سازی بساز.

Dynamic RLS را Data-driven طراحی کن.

داده غیرضروری حساس را وارد نکن.

Gateway و Source Security را جزو معماری BI بدان.

Access Review دوره‌ای داشته باش.

Security Test Case را مثل تست DAX نگه دار.

تغییرات دسترسی را قابل Audit کن.

۱۸.۴۳. تمرین پایه

برای CEO، مدیر منطقه و مدیر شعبه یک Security Matrix طراحی کن و Scope هرکدام را مشخص کن.

۱۸.۴۴. تمرین متوسط

یک جدول SecurityUserScope طراحی کن که یک کاربر بتواند به چند شعبه دسترسی داشته باشد و رفتار Unknown User را هم تعریف کن.

۱۸.۴۵. تمرین کاربردی

برای مدلی که Sales و Cost دارد تصمیم بگیر کدام گروه‌ها به Cost دسترسی دارند و RLS/OLS چه نقشی خواهند داشت.

۱۸.۴۶. تمرین چالشی

سناریوی تغییر سمت یک مدیر از Region A به Region B را طراحی کن. تمام تغییرات Identity، Mapping، Test، Audit و Revocation را بنویس.

۱۸.۴۷. پروژه نهایی فصل؛ Enterprise Security Blueprint شرکت هانا

در پایان باید بتوانی برای مدیر امنیت توضیح بدهی هر کاربر از چه مسیری احراز هویت می‌شود، چه Scopeای دارد، کجا فیلتر می‌شود و چطور دسترسی او بازبینی می‌شود.

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

امنیت Power BI یک DAX Rule تنها نیست. Identity، Workspace، App، Semantic Model، RLS، OLS، Source، Gateway، Audit و فرایندهای سازمانی همه کنار هم امنیت واقعی را می‌سازند.

Authenticate
→ Authorize
→ Minimize
→ Filter
→ Monitor
→ Review

در فصل بعد سراغ CI/CD و DevOps برای Power BI می‌رویم: Version Control، Deployment Pipeline، تست، Release Management، Automation و ساخت Workflow تیمی برای توسعه Enterprise BI.