و سپس «افزودن به صفحه اصلی» ضربه بزنید
و سپس «افزودن به صفحه اصلی» ضربه بزنید
اگر در یک سازمان متوسط یا بزرگ کار کرده باشید، احتمالاً با این صحنه آشنا هستید:
گزارشهای مختلف برای واحدهای مالی، فروش، عملیات و مدیریت تهیه میشود و هرکدام باید فقط بخش خاصی از داده را ببینند. مدیر فروش باید اطلاعات استان خودش را داشته باشد، کنترلر مالی باید تمام ارقام را ببیند، اما مثلاً نباید به برخی ستونهای HR دسترسی داشته باشد. از طرف دیگر تیم BI معمولا نمیخواهد برای هر گروه یک مدل جدا ایجاد کند، چون لایفسایکل پیچیده میشود و هزینه نگهداری بالا میرود.
اینجاست که ترکیب RLS و OLS تبدیل به یک راهکار ایدهآل میشود. RLS تعیین میکند «چه ردیفهایی» قابل مشاهده باشند و OLS تعیین میکند «چه جدولها و ستونهایی» برای چه گروهی نمایش داده شوند. اگر این دو بهدرستی کنار هم قرار بگیرند، نتیجه یک معماری تمیز، امن و قابل نگهداری است. اگر هم این معماری اشتباه طراحی شود، مدل در عرض چند ماه غیرقابل مدیریت خواهد شد.
چرا ترکیب RLS و OLS اهمیت دارد؟
برای اینکه موضوع روشن شود، بهتر است سه سناریوی واقعی را مرور کنیم؛ سناریوهایی که تقریباً هر تیم BI با آن روبهرو شده است:
سناریو ۱: دیدن دادههای فیلترشده اما پنهان کردن ستونهای حساس
کاربر فروش باید رکوردهای شهر خودش را ببیند.
اما نباید ستون “Margin” یا “Salary” برایش نمایش داده شود.
در اینجا RLS کافی نیست، چون کاربر به تمام ستونها دسترسی دارد. پس OLS لازم میشود.
سناریو ۲: نقشهای زیاد و مدیریت دشوار
وقتی فقط RLS استفاده میکنید، معمولاً تعداد نقشها زیاد میشود.
با اضافهشدن OLS بدون معماری درست، این تعداد چند برابر خواهد شد و مدیریت نقشها به کابوس تبدیل میشود.
سناریو ۳: مدلهای درهم و وابستگیهای ناخواسته
گاهی در تلاش برای ترکیب RLS و OLS، روابط و فیلترهای اشتباه ایجاد میشود.
نتیجه این است که یک کاربر هم داده نمیبیند، هم ستونهایی برایش ناپدید میشود که اصلاً نباید پنهان میشد.
برای اینکه این مشکلات پیش نیاید، معماری استاندارد، نقش اصلی را بازی میکند.
مرحله اول: ساماندهی مدل Tabular برای امنیت چندلایه
قبل از نوشتن حتی یک خط RLS یا OLS باید مدل را درست آماده کنید. این مرحله نادیده گرفته شود، همه چیز بعدها مشکلساز میشود.
ایجاد لایه امنیتی جداگانه
پیشنهاد حرفهای این است که یک جدول به نام SecurityUserAccess بسازید.
ستونهای پیشنهادی:
- UserPrincipalName
- Department
- Region
- PermissionGroup
- ObjectAccessLevel
این جدول باید مستقیماً به جدولهای Fact متصل نشود و صرفاً نقش مرجع امنیتی داشته باشد.
استفاده از ستونهای کمکاردینالیتی
برای RLS همیشه از ستونهایی با تعداد مقدار کم استفاده کنید.
مثلاً به جای فیلتر روی CustomerID، روی Region یا Branch فیلتر بگذارید. این کار سرعت و پایداری مدل را بالا میبرد.
تفکیک لایه Data و لایه Security
جدولهای امنیتی نباید با جدولهای تحلیل ادغام شوند.
این کار نگهداری را سادهتر میکند و احتمال خطا را کم میکند.
مرحله دوم: طراحی RLS عملی و قابل نگهداری
نقشهای ساده و عمومی بسازید
برای مثال:
- SalesRegionAccess
- FinanceAccess
- HRLimitedAccess
هر نقش باید یک وظیفه مشخص داشته باشد؛ نه بیشتر.
فیلتر RLS با الگوی استاندارد
نمونه DAX تمیز:
[Region] = LOOKUPVALUE(SecurityUserAccess[Region], SecurityUserAccess[UserPrincipalName], USERPRINCIPALNAME())
این ساختار:
- ساده است
- دیرتر خراب میشود
- در پروژههای بزرگ قابل نگهداری میماند
مدیریت کاربران
گروههای Azure AD را به نقشها وصل کنید.
هیچ کاربری را مستقیم داخل نقشها وارد نکنید.
مرحله سوم: اضافهکردن OLS بهصورت کنترلشده
OLS به شدت قدرتمند است اما اگر بدون برنامه استفاده شود، ساختار مدل را پیچیده میکند.
پنهان کردن ستونهای حساس
مثلاً در مدل فروش:
- ستون Margin
- ستون DiscountRate
- ستون InternalScore
این ستونها فقط برای گروه Finance دیده شوند.
پنهان کردن جدولهای مپینگ
مثلاً:
- جدول Mapping برای KPIهای داخلی
- جدول HRMapping
- جدولهای Budget تخصصی
اینها باید به OLS سپرده شوند نه RLS.
OLS باید بر اساس گروههای پرمیژن اجرا شود
ساختار پیشنهادی:
- OLS_Finance
- OLS_Management
- OLS_FieldUsers
- OLS_PowerUsers
مرحله چهارم: جلوگیری از پیچیدگی مدل
ترکیب RLS و OLS بهراحتی میتواند از کنترل خارج شود.
برای جلوگیری از این مشکل باید سه قانون را همیشه رعایت کنید:
قانون ۱: عدم ترکیب نقشهای RLS و OLS در یک Role
هر نقش باید فقط یک وظیفه داشته باشد.
در غیر این صورت رفع خطا بسیار سخت میشود.
قانون ۲: عدم ایجاد فیلترهای چندگانه روی یک جدول
این کار منجر به رفتارهای غیرقابل پیشبینی میشود.
قانون ۳: مستندسازی ساده و مداوم
یک فایل ساده Excel با این ستونها کافی است:
- نام Role
- نوع Role (RLS یا OLS)
- جدولهای درگیر
- ستونهای درگیر
- گروههای AD متصل شده
مرحله پنجم: مثال کامل و واقعی از یک معماری استاندارد
فرض کنید سازمان شما این نیازها را دارد:
- مدیران فروش باید کل فروش را ببینند اما نه ستون Margin
- کارمندان فروش فقط داده استان خودشان را ببینند
- واحد مالی همه چیز را ببیند
- مدیر پروژه فقط برخی ستونهای HR را نبیند
- مدیرعامل Full Access داشته باشد
در این حالت:
RLS
- SalesRegionAccess: فیلتر روی Region
- ManagerAccess: بدون فیلتر ردیفی
- FinanceAccess: بدون فیلتر ردیفی
- FieldSales: Region = UserRegion
OLS
- OLS_MarginRestricted: ستون Margin پنهان
- OLS_HRRestricted: ستونهای HRHidden پنهان
- OLS_Executive: بدون محدودیت
نتیجه:
- مدل ساده
- نقشها کم
- امنیت بسیار بالا
- نگهداری آسان
- توسعه گزارش سریع
مرحله ششم: تست امنیتی
تست بسیار مهم است.
چکلیست:
تست با View As
برای هر Role یک بار View As اجرا کنید و کل مدل را با دقت مرور کنید.
تست در Service
در Power BI Service ممکن است رفتار کمی متفاوت باشد.
حتماً تست سرویسی را جداگانه انجام دهید.
تست سناریوهای ترکیبی
مثلاً کاربری که هم عضو Sales و هم عضو Managers است.
در این حالت مجوزهای او باید Union شود.
مرحله هفتم: نگهداری طولانیمدت
برای اینکه مدل شما در ماههای آینده خراب نشود، باید یک چرخه نگهداری داشته باشید:
- ماهی یک بار بازبینی نقشها
- بررسی ستونهای جدید
- بررسی گروههای AD
- بررسی گزارشهایی که از مدل اشتراک گرفتهاند
- تست دسترسی پلن Release
سوالات پرتکرار (FAQ)
آیا میتوان RLS و OLS را روی یک Role اعمال کرد؟
توصیه نمیشود. باعث پیچیدگی میشود و نگهداری را دشوار میکند.
آیا OLS روی DirectQuery هم کار میکند؟
بله، اما با محدودیتهایی که باید در دیتا سورس بررسی شود.
آیا ستون پنهان شده در OLS قابل حدس توسط کاربر است؟
خیر. ستون کاملاً از دید کاربر حذف میشود و حتی در Metadata هم نمایان نیست.
اگر کاربر عضو دو Role باشد چه اتفاقی میافتد؟
RLS اعمال Union میشود و OLS اعمال Intersection.
آیا این معماری برای Power BI Pro مناسب است؟
بله، اما برای تعداد کاربر زیاد، ظرفیت Premium گزینه بهتری است.
مشاوره و تماس
اگر قصد دارید یک معماری امنیتی پایدار و استاندارد برای مدلهای Tabular طراحی کنید، توسعه فناوری اطلاعات لاندا میتواند برای شما یک ساختار دقیق، قابل نگهداری و ۱۰۰ درصد تستشده آماده کند.
از طراحی RLS و OLS گرفته تا پیادهسازی، مستندسازی، تست و آموزش تیم شما.
برای دریافت ارزیابی امنیت مدل یا طراحی معماری دسترسی سازمانی هوشمند کافی است با ما تماس ✆ بگیرید تا جلسه اولیه برای شما تنظیم شود.
نظری داده نشده