GH GambleHub

نمایندگی نقش و دسترسی

(بخش: عملیات و مدیریت)

1) چرا نمایندگی مبتنی بر نقش

هدف این است که به هر شرکت کننده (کارمند، شریک، خدمات) دقیقا به همان اندازه حقوق لازم و دقیقا به همان اندازه که لازم است، با ردیابی کامل اقدامات. این خطرات نشت و سوء استفاده را کاهش می دهد، سرعت حمل و نقل و عبور از ممیزی را افزایش می دهد.

2) مدل دسترسی: سطوح و دامنه ها

دسترسی به دامنه: مردم (کنسول/پانل)، خدمات (نشانه های ماشین)، داده ها (جداول/اشیاء)، زیرساخت ها (ابر/K8s)، پیمانکاران (ادغام خارجی)، مناطق/مستاجران.
سطح اعتماد: عمومی → داخلی → محافظت شده (PII/امور مالی) → به ویژه مهم (کلید/پرداخت).
مناطق عملیاتی: prod/staging/sandbox ؛ قانون «از پایین» به «بالا» - تنها از طریق خطوط لوله تایید شده است.

3) مدل های مجوز

RBAC: نقش ها با وظایف مرتبط هستند (ویرایشگر محتوا، اپراتور پرداخت). شروع ساده، آسان برای بررسی.
ABAC: سیاست های ویژگی های موضوع/منابع/زمینه (منطقه، مستاجر، تغییر، دستگاه، نمره ریسک).
ReBAC (مبتنی بر رابطه): حقوق از روابط (صاحب پروژه، عضو تیم) پیروی می کنند.
ترکیبی: RBAC برای ماتریس پایه، ABAC برای محدودیت های زمینه، ReBAC برای مالکیت.

تمرین: یک نمودار از حقوق (چه کسی → چرا) را برای شناسایی مسیرهای تشدید و «گره های فوق العاده» خطر نگه دارید.

4) حداقل دسترسی مورد نیاز (حداقل امتیاز)

شروع - حداقل نقش به طور پیش فرض (فقط خواندنی، بدون PII).
ارتقاء - تنها از طریق یک برنامه با توجیه, مدت و مالک.

محدودیت زمانی (TTL): حقوق «ذوب» به طور خودکار ؛ توسعه - آگاهانه

ریل گارد متنی: منطقه/مستاجر، ساعت باز، دستگاه، جغرافیایی.

5) تفکیک وظایف (SoD)

ماتریس SoD ترکیبات خطرناک را حذف می کند:
  • «محدودیت ها را تعیین می کند» ≠ «محدودیت ها را تصویب می کند».
  • «پرداخت را آماده می کند» ≠ «پرداخت را امضا می کند».
  • «نوشتن کد» ≠ «انتشار در prod».
  • «Admin DB» ≠ «PII را در تجزیه و تحلیل می خواند».
  • پیاده سازی SoD در سیاست ها و در فرآیندهای خود (دو امضا، M-از-N).

6) فرآیندهای JML (Joiner/Mover/Leaver)

Joiner: تخصیص خودکار نقش های اساسی توسط موقعیت/تیم/منطقه، چک لیست دسترسی به مدت 24 ساعت.

حرکت: بررسی نقش هنگام تغییر تیم/پروژه ؛ حذف کامل حقوق «قدیمی»

لیور: لغو جلسات، کلید ها، نشانه ها ؛ انتشار مجدد اسرار، انتقال مالکیت مصنوعات.

7) امتیازات موقت: JIT/PAM

Just-In-Time (JIT): افزایش حقوق در درخواست برای 15-240 دقیقه با MFA و توجیه بلیط.
PAM (مدیریت دسترسی ویژه): ورود پروکسی/پوسته، جلسات ضبط، ورود به سیستم فرمان.
Break-glass: دسترسی اضطراری با هشدار فوری، TTL کوتاه و اجباری پس از مرگ.

8) هویت خدمات و کلید

حساب های خدمات: برای هر سرویس و محیط جداگانه، هیچ اسرار مشترک وجود ندارد.

هویت حجم کار: نشانه های اتصال به غلاف/vir/عملکرد ؛ اعتبارات کوتاه مدت

اسرار: KMS/Vault، چرخش، رمزگذاری دو حلقه، ممنوعیت ورود به سیاهههای مربوط.
کلید های امضا/پرداخت: آستانه/MPC، HSM های سخت افزاری، تنوع در حوزه های اعتماد.

9) SSO/MFA/SCIM و چرخه عمر حساب

SSO: IdP (SAML/OIDC), single sign-on, سیاست های رمز عبور/دستگاه متمرکز.
MFA: اجباری برای مدیران/امور مالی/PII ؛ ترجیحاً FIDO2.
SCIM: ایجاد خودکار/حذف/اصلاح حساب ها و گروه ها.
وضعیت دستگاه: دسترسی مشروط به وضعیت دستگاه (رمزگذاری دیسک، EDR، تکه های فعلی).

10) سیاست به عنوان کد و تایید

OPA/خدمات مجوز: سیاست ها در قالب کد (Rego/JSON)، بررسی از طریق PR، تست ها.
کنترل رانش: مقایسه های منظم «اعلام شده در مقابل در واقع».
بررسی های قبل از پرواز: «آیا سیاست اجازه این عملیات را می دهد ؟» - موارد تست قبل از انتشار.

11) دسترسی به داده ها

طبقه بندی: عمومی/داخلی/محدود/PII/امور مالی.
فشار «حداقل»: aggregates/masks به جای داده های «خام» ؛ درخواست PII - فقط از طریق jabs تایید شده است.
Tokenization/DE-ID - شناسه های جایگزین، درخواست های حسابرسی.
لایه ها: مواد غذایی → کپی → ویترین → مصالح ؛ دسترسی مستقیم به پایگاه داده تولید - فقط JIT/PAM.

12) ابر، K8s، شبکه ها

IAM ابر: نقش در هر حساب/پروژه ؛ «مدیر» ممنوعیت به طور پیش فرض; محدود کردن اقدامات در برچسب ها/پوشه ها.
Kubernetes: RBAC در neimspaces، PSP/سیاست های مشابه بدون «ممتاز»، تصویر allowlist، اسرار از طریق CSI، حساب خدمات در هر غلاف.
شبکه: اعتماد صفر (mTLS، هویت آگاه)، دسترسی به پرش میزبان - JIT تنها، ضبط جلسات SSH.

13) شرکای خارجی و ادغام

مستاجران/کلیدهای جدا شده، حداقل محدوده OAuth2، نشانه های TTL کوتاه.
Webhooks: امضا (HMAC/EdDSA)، «nonce + timestamp»، پنجره پذیرش باریک.
چرخش کلید در یک برنامه، به یاد آوردن بر سازش، نقطه پایانی وضعیت برای «سلامت».

14) حسابرسی، جواز مجدد، گزارش

ایمنی: سیاهههای مربوط به WORM، امضاهای انتشار سیاست، برش های Merkle.
جواز مجدد: بررسی سه ماهه از نقش های مهم، ماهانه - حقوق مدیر.
حقوق قرنطینه: «استفاده نشده 60 روز» → حذف خودکار.
بسته شواهد: آپلود ماتریس نقش، SoD باعث، درخواست JIT، ضبط جلسات PAM.

15) معیارها و SLO

TTG (Time-to-Grant): زمان متوسط برای اعطای دسترسی به یک برنامه استاندارد (≤ هدف 4 ساعت).
سهم دسترسی JIT در میان «ممتاز» (هدف 80٪ ≥).
SoD-نقض: 0 در prod، زمان حذف ≤ 24 ساعت.

حقوق یتیم: ٪ از کاربران با حقوق بیش از حد (هدف → 0. 0x%)

چرخش اسرار: میانگین سن راز (هدف ≤ 30 روز برای حساس).
پوشش حسابرسی: اقدامات ممتاز 100٪ با مصنوعات (سوابق، رسید).

16) داشبورد

دسترسی به سلامت: نقش های فعال، حقوق یتیم، JIT در مقابل دائمی.
PAM و جلسات: تعداد جلسات ممتاز، مدت زمان، موفقیت MFA.
SoD & حوادث: آمار قفل, علل, MTTR.
اسرار و کلید: سن، چرخش آینده، کلید قرمز.
JML: SLA از برنامه های onboarding/offboarding، عقب افتاده.
شواهد حسابرسی: وضعیت جواز مجدد سه ماهه، کامل 100٪.

17) کتاب های حادثه

سازش توکن/کلید: یادآوری فوری، جستجوی استفاده جهانی، چرخش وابستگی، حسابرسی مجدد در N روز.
نقض SoD: بلوک عملیات، قطع موقت نقش، پس از مرگ و تغییر سیاست.
دسترسی غیر مجاز به PII: جداسازی، اطلاع رسانی DPO، موجودی نشت، مراحل قانونی.
سوء استفاده از تشدید: انجماد JIT برای موضوع/تیم، تجزیه و تحلیل برنامه ها/توجیه، تنظیم محدودیت TTL.

18) شیوه های عملیاتی

چهار چشم در صدور/تغییر حقوق بحرانی.
کاتالوگ نقش با شرح وظایف، خطرات و عملیات مجاز.
محیط های تست با داده های ناشناس و نقش های دیگر.
سیاست خشک اجرا: شبیه سازی اثرات تغییرات قبل از کاربرد.
GameDays با دسترسی: «از دست دادن IdP»، «شکست PAM»، «نشت مخفی».

19) چک لیست پیاده سازی

  • ایجاد یک طبقه بندی نقش و ماتریس SoD برای فرآیندهای کلیدی.
  • فعال کردن SSO + MFA برای همه، جریان SCIM برای JML.
  • PAM/JIT را مستقر کنید، شیشه شیشه ای را با هشدار و TTL کوتاه پیکربندی کنید.
  • سیاست ها به عنوان کد (OPA)، تجدید نظر از طریق PR و autotests را وارد کنید.
  • جداگانه حساب خدمات و حجم کار هویت ؛ ممنوعیت اسرار مشترک
  • Vault/KMS، چرخش منظم اسرار و کلیدها، ممنوعیت اسرار در کد/سیاهههای مربوط.
  • محیط ها و مناطق جداگانه، قوانین دسترسی بین منطقه ای را تقویت می کنند.
  • داشبورد ها و SLO ها را اجرا کنید، گزارش های تأیید مجدد ماهانه.
  • انجام یک اسکن SoD از نمودار حقوق و از بین بردن مسیرهای تشدید.
  • تمرینات منظم و پس از مرگ با موارد عمل.

20) سوالات متداول

RBAC یا ABAC ؟

RBAC - لایه خوانایی پایه، ABAC - زمینه و دینامیک. از يه دورگه استفاده کن

آیا PAM مورد نیاز است اگر یک JIT وجود دارد ؟

بله: PAM ضبط جلسه و کانال های دسترسی اختصاصی را مدیریت می کند.

چگونه می توان «چسبندگی» حقوق را کاهش داد ؟

TTL برای نقش ها، خودکار حذف استفاده نشده، جواز مجدد ماهانه و هشدار SoD.

با پیمانکاران خارجی چه کنیم ؟

مستاجران/گروه های اختصاصی، حوزه های محدود، TTL های کوتاه، گزارش های اجباری و تأیید مجدد.

نمایندگی نقش و دسترسی ها یک «مجموعه جعبه تیک» نیست، بلکه یک چرخه زندگی حقوق است: حداقل نقش های مورد نیاز، SoD، JIT/PAM، سیاست به عنوان کد، مشاهده پذیری و مجوز مجدد منظم. چنین طرحی به تیم ها کار سریع و امنیت قابل پیش بینی برای کسب و کار و حسابرسی می دهد.

Contact

با ما در تماس باشید

برای هرگونه سؤال یا نیاز به پشتیبانی با ما ارتباط بگیرید.ما همیشه آماده کمک هستیم!

شروع یکپارچه‌سازی

ایمیل — اجباری است. تلگرام یا واتساپ — اختیاری.

نام شما اختیاری
ایمیل اختیاری
موضوع اختیاری
پیام اختیاری
Telegram اختیاری
@
اگر تلگرام را وارد کنید — علاوه بر ایمیل، در تلگرام هم پاسخ می‌دهیم.
WhatsApp اختیاری
فرمت: کد کشور و شماره (برای مثال، +98XXXXXXXXXX).

با فشردن این دکمه، با پردازش داده‌های خود موافقت می‌کنید.