RBAC: مدیریت نقش ها و مجوز ها

1) اهداف و اصول RBAC

هدف: دسترسی قابل کنترل، قابل تایید و حداقل در حجم برای محافظت از پول/PII و انطباق (GDPR/AML/PCI/ISO).
اصول: حداقل امتیاز· نیاز به دانستن· جداسازی وظایف (SoD)· اعتماد صفر· قابلیت اطمینان (فراخوانی سریع)· قابلیت اطمینان (قابلیت اطمینان).

2) طبقه بندی حقوق و نقش ها

• داده: «خواندن»، «نوشتن»، «صادرات»، «حذف»، «MASKED _ READ» (به طور پیش فرض برای PII).
• Операции: «تأیید _ برداشت»، «تغییر _ FRM _ RULE»، «KYC _ DECISION»، «SANCTIONS _ OVERRIDE».
• Админ: 'ROLE _ UPDATE'، 'USER _ PROVISION'، 'SECRET _ ROTATE'، 'BREAK _ GLASS'.
• ادغام: "API _ CALL:"، WEBHOOK _ SIGN "،" SERVICE _ CONFIG _ UPDATE ".

• هسته (сквозные): «کارمند _ اساسی»، «بیننده _ داخلی»، «حسابرس _ حریم خصوصی».
• Доменные: «support _ agent», «vip _ manager», «payments _ ops», «aml _ officer», «kyc _ operator», «fraud _ analyst», «rg _ specialist», «bi _ analyst».
• سیستم/کسانی که: 'devops _ admin', 'dba _ admin', 'service _ account _',' read _ only _ prod '.
• ممتاز (از طریق PAM/JIT): 'break _ glass _ admin'، 'prod _ db _ jit _ editor'.

3) مهندسی نقش

1. فهرست منابع: سیستم ها/جداول/نقاط پایانی، کلاس های داده (عمومی/داخلی/محرمانه/محدود/بسیار محدود).
2. داستان های کاربر توسط توابع: چه کسی و چرا (هدف).
3. نگاشت وظیفه → مجوزها - حداقل مجموعه در هر تابع.

4. گروه بندی در نقش: یک نقش = یک دامنه مسئولیت ؛ اجتناب از «نقش های فوق العاده»

5. تست SoD: بررسی ناسازگاری ها (به عنوان مثال 'payments _ ops' ≠ 'fraud _ rule _ admin').
6. خلبان و اندازه گیری: ما صادر یک گروه به طور موقت محدود، جمع آوری یک دنباله حسابرسی.
7. Versioning: هر تغییر نقش از طریق CAB با changelog است.

4) تعامل RBAC ↔ ABAC ↔ SoD

RBAC پاسخ می دهد «چه کسی در اصل می تواند»، ABAC - «در چه شرایطی» (محیط، جغرافیایی، دستگاه/MDM، زمان، سطح KYC، «هدف»).
SoD ترکیب نقش های خطرناک را ممنوع می کند و برای اقدامات مهم نیاز به 4 چشم دارد.
تمرین: به طور پیش فرض، نقش ها به PII MASKED_READ می کنند ؛ دسترسی بدون پوشش نیاز به یک ویژگی «هدف» + JIT و یک تصمیم سیاست ABAC مثبت دارد.

5) چند اجاره و جغرافیایی

دامنه مستاجر: نقش ها به اجاره نامه/نام تجاری/صلاحیت («نقش: payments _ ops @ EEA») گره خورده است.
Geo-keys: کلیدهای رمزگذاری فردی و بخش های دسترسی در هر منطقه (EC/UK/...).
دانه بندی: فیلتر کردن توسط ستون 'region _ code' (RLS) و صلاحیت بازیکن.

6) امنیت ردیف/ستون و پوشش

• RLS (strings): دسترسی به سوابق کشور/نام تجاری/تیم شما.
• CLS (ستون ها): زمینه های حساس ماسک در دسترس هستند ؛ بدون پوشش - فقط با امتیاز «pii _ unmask» + «هدف».

sql
CREATE POLICY rls_tx
ON dwh. transactions
USING (region_code = current_setting('app. region'));

SELECT
CASE WHEN has_priv('pii_unmask') THEN email ELSE mask_email(email) END AS email_view
FROM dwh. users;

7) JIT، شکستن شیشه и PAM в RBAC

JIT: نقش ممتاز موقت (15-120 دقیقه) تحت بلیط ؛ بازخورد خودکار ؛ حسابرسی کامل

شکستن شیشه: دسترسی اضطراری با MFA + تایید دوم و ضبط جلسه ؛ پس از بررسی با امنیت + DPO.
PAM: فروشگاه مخفی، پروکسی جلسه، چرخش رمز عبور/کلید.

8) چرخه عمر نقش (SOP)

SOP-1: ایجاد/تغییر نقش

1. پرس و جو از صاحب دامنه → لیست وظایف → نقشه برداری از مجوز → SoD-check → خلبان → CAB → انتشار + اسناد و مدارک.

SOP-2: درخواست و اعطای دسترسی

1. درخواست (IDM/ITSM) با «هدف» و مهلت → تایید خودکار SoD/صلاحیت → تایید مالک داده + امنیت (برای محدود +) → صدور (اغلب JIT) → ورود رجیستری.

SOP-3: بازخورد/خروج

عوامل: خاتمه، تغییر نقش، عدم فعالیت> 30/60 روز، JIT منقضی شده است.
فراخوان خودکار و ورود به سیستم.

SOP-4: صدور گواهینامه مجدد

Semalt، صاحبان تایید می کنند که نقش کاربر هنوز مورد نیاز است ؛ سیستم حذف «حلق آویز» حقوق.

9) مثال ماتریس نقش (قطعه)

10) ابزار و پیاده سازی (الگوها)

کاتالوگ نقش به عنوان کد: YAML/JSON در مخزن + اعتبار سنج CI، changelog.
IdP/SSO مرکزی: تأمین SCIM، گروه نقشهکشی «نقش → گروه».
نقطه تصمیم گیری سیاست: موتور سیاست (ABAC) با ویژگی های زمینه.
اسرار/KMS: جداسازی کلیدی در هر محیط/منطقه/مستاجر.
دروازه داده: یک لایه واحد از پوشش/حسابرسی برای DWH/BI/صادرات.
SIEM/SOAR: همبستگی 'ROLE _ UPDATE '/' READ _ PII '/' EXPORT _ DATA'، بلیط خودکار.

11) حسابرسی و ورود به سیستم

Обязательные события: «ROLE _ ASSIGN»، «ROLE _ REVOKE»، «ROLE _ UPDATE»، «BREAK _ GLASS»، «JIT _ GRANT»، «READ _ PII»، «EXPORT _ DATA»، «پرداخت _ تایید»، «KYC _ DECISION».
مورد نیاز: کپی WORM، زنجیره هش، امضای بسته، 'هدف '/' ticket _ id' در هر رویداد، هماهنگ سازی زمان.

12) معیارها و KPI/KRI

پوشش:٪ از سیستم های تحت RBAC ≥ 95٪.
نقض SoD: = 0 ؛ تلاش برای اختصاص نقشهای ناسازگار - بلوک خودکار.
نرخ JIT: ≥ 80٪ از افزایش JIT است.
TTR Offboarding: لغو حقوق ≤ 15 دقیقه.
Masked reads ratio: ≥ 95% تماسها با PII با ماسک انجام میشود.
جواز مجدد: 100٪ نقش تایید سه ماهه.
صادرات امضا شده: 100٪ صادرات با امضا/ورود.

13) RACI (بزرگ شده)

14) چک لیست

قبل از ایجاد یک نقش

• توصیف داستان های کاربر و «هدف»
• فهرست منابع و کلاس های داده
• نقشه برداری حداقل مجوز
• بررسی SoD/درگیری
• پوشش و RLS/CLS سیاست
• طرح صدور گواهینامه مجدد و صاحبان

قبل از اعطای دسترسی

• هدف و تاریخ ثابت
• SoD/حوزه های قضایی/MDM/MFA تکمیل شده است
• ماسک پیش فرض، JIT در ارتقاء
• مجله و تاریخ تجدید نظر گنجانده شده است

15) خطاهای مکرر و ضد الگوهای

«نقش های فوق العاده» با حقوق گسترده به جای دامنه های کوچک.
دسترسی مستقیم به PII بدون پوشش و «هدف».
بدون SoD/چشم چهارم برای «پرداخت _ تایید »/« KYC _ تایید».
تمدید حقوق موقت «برای همیشه».
کپی داده prod به dev/stage.
صادرات مات بدون امضا و ورود به سیستم.

16) نقشه راه پیاده سازی

هفته 1-2: موجودی دارایی/طبقه بندی داده ها ؛ یک ماتریس پیش نویس از نقش ها ؛ میز SoD

هفته 3-4: RBAC به عنوان کد (مخزن)، گروه IdP/SCIM، موتور ABAC (ویژگی های اساسی: محیط زیست/جغرافیایی/MDM/زمان)، JIT/PAM، لایه ماسک برای DWH/BI.
ماه 2: صدور گواهینامه مجدد، اتوماسیون خارج از منزل، هشدارهای SOAR برای نقض RBAC/SoD/ABAC، سیاهههای مربوط به صادرات/WORM.
ماه 3 +: گسترش ویژگی (خطر دستگاه، سطح KYC)، ممیزی تعصب دسترسی، بهینه سازی هزینه و تمرین های منظم تبلت.

TL ؛ دکتر متخصص

RBAC قوی = نقشهای دامنه کوچک + شرایط ویژگی (ABAC) + SoD و JIT/PAM + پوشش و RLS/CLS + ممیزی سخت و صدور گواهینامه مجدد. این خطر نشت/سوء استفاده را کاهش می دهد، حسابرسی را سرعت می بخشد و پلت فرم را در مرزهای حریم خصوصی و الزامات انطباق نگه می دارد.