Row-Level Security (RLS)، Dynamic RLS و طراحی امنیت سازمانی در Power BI

شروع جلسه؛ همه نباید همه داده‌ها را ببینند

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

RLS یا Row-Level Security کمک می‌کند یک Semantic Model مشترک داشته باشیم، ولی هر کاربر فقط Rowهایی را ببیند که مجاز است.

۴۲.۱. RLS دقیقاً چه کاری می‌کند؟

RLS ردیف‌های قابل مشاهده برای کاربر را محدود می‌کند. یعنی Measure و Visual روی همان زیرمجموعه مجاز از داده محاسبه می‌شوند.

۴۲.۲. RLS با مخفی کردن Visual فرق دارد

پنهان کردن یک Chart امنیت نیست. اگر داده در Model برای کاربر قابل دسترس باشد، صرفاً Hide کردن Visual جلوی دسترسی واقعی را نمی‌گیرد. امنیت باید در لایه مناسب Model/Service اعمال شود.

۴۲.۳. Static RLS

در Static RLS یک Role با Rule ثابت می‌سازیم؛ مثلاً Role مربوط به Region = "North" فقط داده منطقه North را ببیند.

۴۲.۴. نمونه Rule ثابت

DimBranch[Region] = "North"

۴۲.۵. مشکل Static RLS

اگر ۳۰ منطقه، ۱۰۰ شعبه یا صدها فروشنده داشته باشیم، ساخت Role جدا برای همه آن‌ها نگهداری سختی ایجاد می‌کند.

۴۲.۶. Dynamic RLS

در Dynamic RLS هویت کاربر وارد منطق امنیت می‌شود. یک Role عمومی داریم و جدول Mapping تعیین می‌کند هر User به چه Region، Branch یا Entity دسترسی دارد.

۴۲.۷. جریان Dynamic RLS

۴۲.۸. USERPRINCIPALNAME

USERPRINCIPALNAME()

۴۲.۹. کاربرد USERPRINCIPALNAME

این تابع هویت کاربر جاری را در Context امنیتی برمی‌گرداند و معمولاً برای تطبیق با Email/UPN ذخیره‌شده در جدول Security استفاده می‌شود.

۴۲.۱۰. جدول Security Mapping

۴۲.۱۱. یک کاربر، چند دسترسی

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

۴۲.۱۲. Rule روی جدول Security

SecurityUserRegion[UserUPN] = USERPRINCIPALNAME()

۴۲.۱۳. Relationship Security

بعد از Filter شدن Mapping، Relationship باید اجازه دهد Regionهای مجاز و سپس FactSales محدود شوند. طراحی Relationship بخش اصلی امنیت پویاست.

۴۲.۱۴. مدل امنیت سازمانی

۴۲.۱۵. Security Dimension

در پروژه‌های حرفه‌ای بهتر است امنیت را مثل بخشی از Data Model طراحی کنیم، نه یک فرمول لحظه آخری.

۴۲.۱۶. مثال Branch Security

۴۲.۱۷. Security روی Salesperson

اگر فروشنده فقط مشتری‌ها یا سفارش‌های خودش را ببیند، Mapping می‌تواند UserUPN را به SalespersonKey متصل کند.

۴۲.۱۸. Customer-level Security

در B2B ممکن است Account Manager فقط Accountهای خودش را ببیند. این سطح از RLS می‌تواند تعداد Mapping Rowها را زیاد کند و باید Performance آن تست شود.

۴۲.۱۹. Hierarchical Security

گاهی ساختار مدیرعامل → مدیر منطقه → مدیر شعبه → فروشنده داریم. باید مشخص شود دسترسی از Hierarchy سازمانی محاسبه می‌شود یا در Mapping از قبل Expand شده است.

۴۲.۲۰. Expand Access در ETL

یک راه عملی این است که ETL تمام دسترسی‌های مؤثر را به صورت User-Entity Row تولید کند؛ سپس RLS در Model ساده‌تر می‌شود.

۴۲.۲۱. چرا ETL مهم است؟

منطق پیچیده سازمانی، جانشینی، چندسمتی و استثناهای دسترسی را گاهی بهتر است خارج از DAX و در لایه Data Engineering حل کنیم.

۴۲.۲۲. Security Mapping نمونه

۴۲.۲۳. ALL به چه معنی؟

ALL در جدول بالا فقط یک Concept است؛ خود Power BI با دیدن متن ALL جادویی عمل نمی‌کند. باید Rule و Data Model مشخص کند دسترسی سراسری چگونه پیاده می‌شود.

۴۲.۲۴. الگوی مدیرعامل

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

۴۲.۲۵. Roleهای کم، Mapping بیشتر

در Dynamic RLS معمولاً هدف این است که تعداد Roleها کم بماند و تفاوت دسترسی کاربران از Data Mapping بیاید.

۴۲.۲۶. Manage Roles

در Power BI Desktop از Manage roles برای تعریف Role و Filter Expression استفاده می‌کنیم.

۴۲.۲۷. View as

با View as می‌توان Role را در Desktop تست کرد. برای Dynamic RLS باید سناریوی هویت کاربر را هم شبیه‌سازی و بررسی کنی.

۴۲.۲۸. تست فقط با یک User کافی نیست

حداقل User با یک دسترسی، چند دسترسی، بدون دسترسی و Full Access را تست کن.

۴۲.۲۹. Test Matrix

۴۲.۳۰. Unknown User

یکی از مهم‌ترین تصمیم‌ها این است که User ناشناخته چه ببیند. الگوی امن معمولاً Fail Closed است؛ یعنی نبود Mapping باعث دسترسی باز نشود.

۴۲.۳۱. Fail Closed

امنیت را طوری طراحی کن که خطا یا نبود Mapping منجر به داده کمتر شود، نه داده بیشتر.

۴۲.۳۲. Email Normalization

UPNهای Mapping باید با هویت واقعی کاربران سازگار باشند. Space، Case، Alias و تغییر Domain می‌توانند Mapping را خراب کنند.

۴۲.۳۳. Normalized User Key

اگر سازمان Identity پیچیده دارد، بهتر است کلید استاندارد کاربر و فرآیند Sync مشخصی داشته باشی.

۴۲.۳۴. Security Table Source

Mapping می‌تواند از SQL Server، HR System، Active Directory export یا سیستم مجوزهای سازمان بیاید؛ منبع باید Owner مشخص داشته باشد.

۴۲.۳۵. Security Ownership

BI Developer نباید خودش به صورت سلیقه‌ای تعیین کند چه کسی به چه داده‌ای دسترسی دارد. Business/Data Owner باید Rule را تأیید کند.

۴۲.۳۶. RLS و Star Schema

Star Schema تمیز، مسیر انتشار Filter امنیت را قابل فهم‌تر می‌کند. Relationshipهای مبهم و چندمسیره Security را خطرناک می‌کنند.

۴۲.۳۷. Bidirectional Security

اعمال Security Filter در Relationshipهای دوطرفه نیاز به دقت زیادی دارد. هر مسیر Filter باید از نظر اثر امنیتی تست شود.

۴۲.۳۸. Ambiguous Paths

اگر دو مسیر از Security Table به Fact وجود داشته باشد، نتیجه ممکن است پیچیده و غیرقابل پیش‌بینی شود. Model را ساده نگه دار.

۴۲.۳۹. Fact-level RLS

می‌توان مستقیماً Fact را Filter کرد، ولی در بسیاری از سناریوها Security روی Dimension/Mapping طراحی تمیزتر و قابل استفاده مجددتری دارد.

۴۲.۴۰. Multiple Facts

اگر Sales، Budget و Service چند Fact هستند، Security باید روی همه Factهای حساس به شکل سازگار منتشر شود.

۴۲.۴۱. Target Security

مدیر شعبه نباید Target شعب دیگر را ببیند فقط چون FactTarget جدا از FactSales است. Security Coverage همه Factها را بررسی کن.

۴۲.۴۲. RLS و Measures

Measure به صورت طبیعی روی داده Filterشده توسط RLS محاسبه می‌شود. ولی DAX پیچیده و Relationshipها را باید تست کرد تا Security Context ناخواسته دور زده نشود.

۴۲.۴۳. REMOVEFILTERS و امنیت

توابعی مثل REMOVEFILTERS برای Filter Context تحلیلی هستند؛ RLS را مثل یک Slicer معمولی فرض نکن. امنیت باید با تست واقعی Role بررسی شود.

۴۲.۴۴. Security Through Relationships

به جای تلاش برای نوشتن Filter در تک‌تک Measureها، امنیت را در Model حل کن. Measure نباید مسئول Authorization باشد.

۴۲.۴۵. RLS و Drill-through

Drill-through فقط جزئیاتی را نشان می‌دهد که RLS اجازه می‌دهد. با این حال Page مقصد را برای Data Leakage از طریق Title، Tooltip یا جدول‌های دیگر تست کن.

۴۲.۴۶. RLS و Tooltip

Tooltip هم باید فقط داده مجاز را نشان دهد. Custom Tooltip را با Roleهای مختلف تست کن.

۴۲.۴۷. RLS و Export

دسترسی به Export و سایر قابلیت‌های Service را جدا از RLS در Governance بررسی کن. RLS تعیین می‌کند چه Rowهایی مجازند، ولی سیاست انتشار و Export هم مهم است.

۴۲.۴۸. RLS و Workspace

امنیت Workspace و RLS یک موضوع واحد نیستند. Roleهای Workspace می‌توانند سطح دسترسی متفاوتی به محتوا بدهند؛ طراحی Service را در Session 43 بررسی می‌کنیم.

۴۲.۴۹. App Consumers

برای مصرف‌کنندگان Report معمولاً تجربه انتشار از طریق App/Sharing با سیاست‌های سازمانی طراحی می‌شود و RLS روی Model اعمال می‌شود.

۴۲.۵۰. Security ≠ Obscurity

Hide کردن Column، Page یا Button جای RLS را نمی‌گیرد.

۴۲.۵۱. Object-Level Security

RLS درباره Rowهاست. اگر لازم باشد بعضی کاربران اصلاً Column/Table خاصی را نبینند، موضوع به Object-Level Security و معماری امنیتی گسترده‌تر مربوط می‌شود.

۴۲.۵۲. Sensitive Columns

Salary، National ID یا Costهای محرمانه را فقط با حذف Visual محافظت نکن. نیاز امنیتی Column باید در معماری داده و Semantic Model بررسی شود.

۴۲.۵۳. Security Layers

۴۲.۵۴. Defense in Depth

امنیت Power BI باید چندلایه باشد. RLS یک لایه مهم است، نه کل برنامه امنیت اطلاعات.

۴۲.۵۵. پروژه شرکت هانا؛ سناریو

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

۴۲.۵۶. جداول پیشنهادی

۴۲.۵۷. ساده‌سازی Mapping

اگر چند جدول Mapping باعث پیچیدگی زیاد می‌شود، می‌توان یک Security Bridge استاندارد طراحی کرد؛ انتخاب به Grain و ساختار سازمان بستگی دارد.

۴۲.۵۸. Security Bridge

۴۲.۵۹. Bridge پیچیده

یک Bridge عمومی انعطاف بالایی دارد ولی Relationship و DAX آن می‌تواند پیچیده‌تر شود. برای پروژه کوچک، جدول‌های Mapping مشخص گاهی بهترند.

۴۲.۶۰. Security Audit Table

در سیستم Enterprise بهتر است تغییر دسترسی‌ها Audit شود: چه کسی، چه دسترسی‌ای، از چه تاریخی و توسط چه مدیری تأیید شده.

۴۲.۶۱. Effective Date

اگر دسترسی افراد با زمان تغییر می‌کند، باید تصمیم بگیری RLS بر اساس دسترسی فعلی است یا دسترسی تاریخی.

۴۲.۶۲. Current Access vs Historical Access

اغلب مدیر جدید باید داده تاریخی شعبه جدیدش را هم ببیند؛ ولی در بعضی صنایع Rule متفاوت است. این تصمیم Business/Security است.

۴۲.۶۳. Temporary Access

جانشینی مدیر، مأموریت یا دسترسی موقت را با StartDate/EndDate در سیستم مجوزها قابل مدیریت کن.

۴۲.۶۴. Mapping با تاریخ

۴۲.۶۵. RLS و Performance

RLS می‌تواند Query Plan و Cache Behavior را تحت تأثیر قرار دهد. Mapping بزرگ و Relationshipهای پیچیده را با حجم واقعی تست کن.

۴۲.۶۶. Cardinality

User-Entity Mapping با میلیون‌ها Row ممکن است نیاز به طراحی Data Engineering، Aggregation یا ساختار امنیتی متفاوت داشته باشد.

۴۲.۶۷. Integer Keys

برای Relationshipهای بزرگ معمولاً کلیدهای عددی کارآمدتر از Textهای طولانی‌اند؛ UPN را برای شناسایی User نگه دار و Entityها را با Key مدل کن.

۴۲.۶۸. DirectQuery

در DirectQuery، RLS و Query Folding/Source Security باید با دقت بیشتری بررسی شوند. رفتار و محدودیت‌ها را با معماری واقعی تست کن.

۴۲.۶۹. Import

در Import Mode داده داخل Semantic Model است و RLS هنگام Query مصرف‌کننده اعمال می‌شود. امنیت Workspace و Dataset همچنان حیاتی است.

۴۲.۷۰. Composite Models

در مدل‌های ترکیبی، مسیرهای امنیتی بین Import/DirectQuery و Sourceها پیچیده‌تر می‌شوند؛ Test Matrix را گسترده‌تر کن.

۴۲.۷۱. Test as User

فقط Role را تست نکن؛ در محیط Service با Userهای آزمایشی و Permissionهای واقعی هم UAT امنیت انجام بده.

۴۲.۷۲. Negative Testing

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

۴۲.۷۳. Security QA Checklist

۴۲.۷۴. Data Leakage از Dimension

گاهی Fact محدود است ولی Dimension کامل نمایش داده می‌شود و نام Entityهای غیرمجاز لو می‌رود. Slicer و Dimensionها را هم تست کن.

۴۲.۷۵. Show items with no data

گزینه‌هایی که Categoryهای بدون Fact را نشان می‌دهند می‌توانند UX یا حتی افشای Metadata ایجاد کنند؛ با RLS تست شوند.

۴۲.۷۶. Aggregated KPIs

کاربر شعبه نباید KPI کل سازمان را از Measure جداگانه ببیند مگر اینکه Business عمداً اجازه داده باشد.

۴۲.۷۷. Benchmark بدون افشا

گاهی می‌خواهیم مدیر شعبه بداند نسبت به Average شرکت کجاست ولی داده شعب دیگر را نبیند. این نیاز باید با طراحی Aggregation/Benchmark امن حل شود، نه دور زدن RLS.

۴۲.۷۸. Security Documentation

برای هر Role/Mapping بنویس: هدف، Source، Owner، Rule، Entity Grain، Exceptionها و Test Cases.

۴۲.۷۹. Naming Convention

۴۲.۸۰. خطای رایج؛ Role برای هر User

برای تعداد زیاد کاربر معمولاً مقیاس‌پذیر نیست. Dynamic Mapping را بررسی کن.

۴۲.۸۱. خطای رایج؛ امنیت با Slicer

Slicer ابزار تحلیل است، نه Authorization.

۴۲.۸۲. خطای رایج؛ Mapping ناقص

کاربر جدید اضافه شده ولی Mapping ندارد؛ رفتار Fail Closed باید مشخص باشد.

۴۲.۸۳. خطای رایج؛ مسیر دوطرفه بدون تست

Bidirectional Filter ممکن است نتایج امنیتی پیچیده ایجاد کند.

۴۲.۸۴. خطای رایج؛ فقط FactSales امن

Budget، Target، Customer Detail یا Factهای دیگر ممکن است هنوز اطلاعات غیرمجاز نشان دهند.

۴۲.۸۵. خطای رایج؛ تست با Admin

تجربه Admin/Workspace Member لزوماً تجربه Consumer را نشان نمی‌دهد. با User واقعی یا Test Account بررسی کن.

۴۲.۸۶. Best Practiceها

امنیت را از مرحله Data Model طراحی کن.

Dynamic RLS را برای کاربران زیاد بررسی کن.

Mapping را از منبع رسمی نگه دار.

Fail Closed طراحی کن.

Roleها را کم و معنادار نگه دار.

همه Factها و Dimensionها را تست کن.

Drill-through و Tooltip را تست امنیتی کن.

Negative Testing انجام بده.

Access Change را Audit کن.

Performance را با حجم واقعی بسنج.

RLS را بخشی از Defense in Depth بدان.

۴۲.۸۷. تمرین ۱

Static RLS برای یک Region بساز و با View as Role تست کن.

۴۲.۸۸. تمرین ۲

جدول User-Branch Mapping بساز و Dynamic RLS با USERPRINCIPALNAME پیاده کن.

۴۲.۸۹. تمرین ۳

برای یک Area Manager دو Branch مجاز تعریف کن و مطمئن شو هر دو دیده می‌شوند.

۴۲.۹۰. تمرین ۴

یک User ناشناخته تست کن و بررسی کن هیچ داده غیرمجازی نمایش داده نشود.

۴۲.۹۱. تمرین ۵

Customer 360 و Tooltipهای Session 40 را زیر RLS دوباره تست کن.

۴۲.۹۲. تمرین ۶

FactSales و FactTarget را همزمان امن کن و Target Achievement را با Role شعبه بررسی کن.

۴۲.۹۳. تمرین چالشی

ساختار CEO → Area Manager → Branch Manager → Seller را طراحی کن. Mapping، Relationship، Role، Test Matrix و Audit Rule را مستند کن.

۴۲.۹۴. پروژه Session؛ Enterprise RLS Pack

هدف پروژه این است که یک Report واحد برای کل سازمان داشته باشیم ولی هر نفر فقط همان بخشی را ببیند که طبق Rule رسمی سازمان مجاز است.

جمع‌بندی Session 42

RLS یعنی Authorization را وارد مدل تحلیلی کنیم. بهترین پیاده‌سازی آن مدلی است که ساده، قابل Audit، قابل تست و Fail Closed باشد.

Identity → Mapping → Allowed entities → Secure filter propagation → Authorized insight

Session 43: Power BI Service، Workspace، App، Publish، Sharing، Permission Model و معماری انتشار سازمانی.