مدیریت هویت و دسترسی

خلاصه ای کوتاه

IAM مجموعه ای از فرآیندها، سیاست ها و ابزارهایی است که ارائه می دهد چه کسی به چه چیزی، تحت چه شرایطی و چگونه کنترل می شود. اهداف: به حداقل رساندن حقوق اضافی، کاهش سطح حمله، تسریع در ورود و حسابرسی، انطباق (PCI DSS، GDPR و غیره) و قابلیت اطمینان دسترسی قابل اندازه گیری.

مفاهیم پایه

هویت: شخص (کارمند، پیمانکار)، سرویس/برنامه، دستگاه.
احراز هویت (AuthN): چه کسی بررسی می کند (رمز عبور → MFA → طرح های FIDO2/passkeys بدون رمز عبور).
مجوز (AuthZ): تصمیم «آنچه مجاز است» (RBAC/ABAC/ReBAC، سیاست ها).
اعتبار: کلمات عبور، کلید ها، نشانه ها، گواهینامه ها (mTLS).
مدیریت مخفی: KMS/HSM/Vault، چرخش، TTL کوتاه، اسرار پویا.
چرخه زندگی: Joiner-Mover-Leaver (JML) - ایجاد، تغییر نقش، یادآوری.

معماری IAM هدف

• IdP (ارائه دهنده هویت): SSO، MFA، دایرکتوری، فدراسیون (OIDC/SAML)، سیاست های ریسک.
• PDP/PEP: تصمیم/اجرای - موتور سیاست (OPA/سرو) + نقاط برنامه (دروازه API, پروکسی, مش خدمات).
• کاتالوگ/سیستم HR: منبع حقیقت توسط کارمند و نقش
• تأمین: SCIM/اتوماسیون برای ایجاد/اصلاح/لغو دسترسی.
• حسابرسی: گزارش های متمرکز، UEBA، گزارش های نقش و دسترسی.

• SSO (+ MFA) → token issue (OIDC/JWT/SAML) → PEP token/context → PDP تصمیم می گیرد در سیاست (نقش/ویژگی/خطر) → مسائل مربوط به برنامه/انکار دسترسی.

احراز هویت: از کلمه عبور به کلید های عبور

کلمه عبور: فقط با مدیران رمز عبور، حداقل 12-14 کاراکتر، بدون چرخش «با توجه به تقویم»، اما با اجباری در مورد یک حادثه.
MFA پیش فرض: TOTP/WebAuthn/Push ؛ اجتناب از SMS به عنوان یک عامل مهم.
ورود بدون رمز عبور: FIDO2/passkeys برای دامنه های بحرانی.
Adaptive AuthN: در نظر گرفتن سیگنال خطر (جغرافیایی، ASN، دستگاه، ناهنجاری ها) → نیاز به عامل/بلوک اضافی.

مجوز: RBAC، ABAC، ReBAC

RBAC: نقش های مربوط به توابع (پشتیبانی، مالی، DevOps). ساده و قابل درک، اما «در حال رشد».

ABAC: قوانین مربوط به ویژگی ها (بخش، سطح خطر، زمان، منطقه، برچسب منابع). مقیاس پذیر

ReBAC: «چه کسی به چه چیزی تعلق دارد» روابط (صاحبان پروژه، اعضای تیم). مناسب برای سناریوهای چند مستاجر.

• ترکیب RBAC (شبکه پایه) + ABAC/ReBAC (زمینه/محدوده).
• JIT (Just-In-Time): صدور امتیازات موقت از طریق درخواست/برنامه، لغو خودکار.
• JEA (Just Enough Access): حداقل حقوق کافی برای عملیات.
• PAM: دسترسی جداگانه «قوی» (مدیران DB/cloud) با کارگزار جلسه، ضبط صفحه/فرمان و صدور اعتبار کوتاه مدت.

فدراسیون و SSO

پروتکل ها: OIDC (نشانه های JWT)، SAML 2. 0 (اظهارات XML) - برای ارائه دهندگان/شرکای خارجی.
SSO: یک نقطه ورود با MFA، کاهش فیشینگ، فراخوان متمرکز.
B2B/B2C: فدراسیون با شرکا، محدودیت دامنه، سیاست های مبتنی بر دامنه.
mTLS/m2m: برای خدمات، از x.509 کوتاه مدت (SPIFFE/SVID) یا اعتبار مشتری OAuth2 استفاده کنید.

Joiner: ارائه خودکار SCIM حساب ها و نقش های اساسی از HR/دایرکتوری.
حرکت: نقش ها به طور خودکار با ویژگی ها (بخش، پروژه، مکان) تغییر می کنند.
Leaver: فراخوان فوری SSO ها، کلید ها، نشانه ها، مخزن/ابر/CI/CD دسترسی.
فرآیندها: درخواست دسترسی (ITSM)، ماتریس SoD (تقسیم وظایف)، بررسی دسترسی دوره ای.

اسرار، کلید و چرخش

KMS/HSM: کلید های ریشه/بحرانی را ذخیره کنید، حسابرسی عملیات را فعال کنید.
مدیران Vault/Secrets: اعتبار پویا (DB، ابرها)، خودکار revok در تکمیل TTL.
چرخش: نشانه OAuth، کلید امضای JWT، کلمه عبور خدمات - در برنامه و در صورت حوادث.
mTLS: گواهینامه های کوتاه مدت (ساعت/روز)، چاپ مجدد خودکار.

سیاست ها و موتور راه حل

اعلام: سیاست های ذخیره در Git ؛ بررسی در CI (سیاست آزمون).
زمان/مکان/ASN/سطح خطر/وضعیت دستگاه (MDM/EDR).

rego package authz. payments default allow = false

allow {
input. user. role == "finance"
input. device. compliant == true input. action == "read"
input. resource. type == "report"
time. now_hh >= 8 time. now_hh <= 20
}

نظارت، SLO و حسابرسی

• موفقیت AuthN/AuthZ (٪)، زمان ورود/تصمیم گیری p95، سهم ورودی های MFA/بدون رمز عبور.
• تعداد افزایش JIT/PAM، مدت زمان امتیاز متوسط.
• پوشش دستگاه های سازگار، سهم اسرار کوتاه مدت.

• در دسترس بودن SSO/IDp ≥ 99. 95 درصد در ماه
• P95 AuthZ تصمیم گیری ≤ 50 мс.
• 100٪ خاموش کردن حساب ≤ 15 دقیقه پس از خروج.
• حسابرسی و UEBA: گزارش های غیر قابل تغییر متمرکز (دسترسی، تغییر نقش، ورودی های شکست خورده، راه حل های PDP)، تجزیه و تحلیل رفتاری و آلارم های ناهنجاری.

پاسخ حادثه در IAM

سازش نشانه/کلید: ابطال فوری, خروج از سیستم مجبور, چرخش کلید امضا, صدور مجدد اسرار کوتاه مدت.
سوء استفاده از حقوق: تعلیق حساب، مسدود کردن JIT/JEA، بررسی دسترسی به نهادهای همسایه.
IdP در دسترس نیست: حالت های آفلاین (اعتبار موقت حافظه پنهان نشانه ها با TTL کوتاه)، روش های بازیابی اولویت.
فیشینگ: MFA اجباری، بررسی ریسک جلسات، اطلاعیه ها به کاربران، آموزش.

ابرها و Kubernetes (الگوها)

ابر عمومی IAM: استفاده از نقش های بومی با حداقل امتیاز ؛ به جای «ابدی» کلید - بار کاری با فدراسیون OIDC به ابر (IRSA/بار کاری هویت).
Kubernetes: RBAC توسط neimspaces/roles، محدود کردن 'cluster-admin' ؛ اسرار - از طریق مدیران خارجی ؛ مش سرویس + OPA برای سیاست های L7 ؛ کنترل پذیرش (تصاویر امضا, ممنوعیت «: آخرین»).
دروازه های API: چک کردن JWT/mTLS، محدودیت نرخ، امضای درخواست (HMAC) برای نقاط حساس حساس.

تمرین برای iGaming/fintech

دامنه های دسترسی: پرداخت، ضد تقلب، PII، ارائه دهندگان محتوا - جدا شده با نقش ها و بخش های شبکه.
SoD: نقش های متضاد را ترکیب نکنید (به عنوان مثال ایجاد تبلیغی + تایید پرداخت).
PAM و JIT: برای دسترسی به PSP/بانک ها و prod-DB - فقط از طریق یک کارگزار جلسه، با ضبط و فراخوان خودکار.
انطباق: PCI DSS - MFA، حداقل امتیازات، تقسیم منطقه CHD ؛ GDPR - اصل به حداقل رساندن داده ها و سیاهههای مربوط به دسترسی به PII.
شرکا و ارائه دهندگان محتوا: سیاست های فدراسیون و هر مستاجر ؛ نشانه های کوتاه مدت و لیست مجاز IP/ASN.

خطاهای رایج

«ابدی» کلید و نشانه: هیچ چرخش و TTL → خطر بالای نشت وجود دارد.

اخراج دستی: تاخیر در لغو حقوق → دسترسی «ارواح»

نقش های یکپارچه: یک «نقش فوق العاده» به جای ترکیب و ویژگی ها.
MFA فقط در پنل مدیریت: MFA باید برای تمام ورودی ها و عملیات بحرانی باشد.
سیاهههای مربوط «به هیچ جا»: هیچ تمرکز و UEBA → تشخیص بعد از حوادث وجود دارد.

نقشه راه پیاده سازی IAM

1. فهرست کاربران/خدمات/منابع ؛ داده ها و نقشه حساسیت.
2. SSO + MFA برای همه، شامل عوامل مقاوم در برابر فیشینگ است.

3. مدل نقش: ویژگی های RBAC + پایه (ABAC) برای زمینه ؛ ماتریس SoD

4. تأمین SCIM: ایجاد خودکار/تغییر/لغو حقوق از HR/کاتالوگ ؛ برنامه های کاربردی و به روز رسانی در ITSM.
5. PAM و JIT/JEA: برای دسترسی های ممتاز ؛ جلسات ضبط، TTL های کوتاه.
6. مدیریت مخفی: رد کلید های استاتیک ؛ اسرار پویا، چرخش، mTLS با گواهینامه های کوتاه.
7. سیاست ها در Git + CI: آزمون قانون، کنترل تغییر، استقرار سیاست قناری.
8. قابلیت مشاهده و SLO: داشبورد AuthN/AuthZ، هشدارها، بررسی دسترسی منظم.

نمونه هایی از مصنوعات

AWS IAM سیاست (حداقل برای خواندن گزارش S3)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ReadOnlyReports",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports-bucket",
"arn:aws:s3:::reports-bucket/"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203. 0. 113. 0/24" }
}
}]
}

Kubernetes RBAC (توسعه دهنده فضای نام)

yaml apiVersion: rbac. authorization. k8s. io/v1 kind: Role metadata:
name: dev-read-write namespace: app-prod rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments","services","configmaps"]
verbs: ["get","list","watch","create","update","patch","delete"]
apiVersion: rbac. authorization. k8s. io/v1 kind: RoleBinding metadata:
name: dev-bind namespace: app-prod subjects:
- kind: User name: alice@example. com roleRef:
kind: Role name: dev-read-write apiGroup: rbac. authorization. k8s. io

OIDC: مصوبات برای ABAC (به عنوان مثال)

json
{
"sub": "d81f0b5c-...",
"email": "bob@example. com",
"dept": "finance",
"role": "analyst",
"device_compliant": true,
"tenant": "casino-eu"
}

این سیاست ممکن است نیاز به «device _ compliant = true» و «tenant» برای مطابقت با منبع داشته باشد.

چک لیست

• SSO برای همه برنامه ها فعال است ؛ MFA به طور پیش فرض، کلیدهای عبور در اولویت.
• RBAC تعریف شده است ؛ ABAC/ReBAC اضافه کردن زمینه ؛ ساخته شده توسط JIT/JEA
• PAM از دسترسی های خاص محافظت می کند ؛ جلسات ضبط می شود.
• تأمین SCIM از HR ؛ حمل و نقل کاملا اتوماتیک است.
• اسرار پویا هستند، با TTL کوتاه ؛ چرخش ها به صورت اتوماتیک انجام می شود.
• سیاست ها در Git versioned، تست شده در CI ؛ محاسبات قناري وجود داره.
• داشبورد و SLO با توجه به AuthN/AuthZ ؛ لاگ های متمرکز و UEBA
• بررسی دسترسی دوره ای و چک های SoD ؛ گزارش های مربوط به انطباق

سوالات متداول

آیا اوباما به همه نیاز دارد ؟

نه، اينطور نيست RBAC + ABAC برای محیط های ساده کافی است. ReBAC در یک سلسله مراتب پیچیده مالکیت منابع و چند اجاره ای مفید است.

آیا می توانم حساب های محلی را ترک کنم ؟

فقط برای سناریوهای شیشه ای و آفلاین، با محدودیت های شدید و تأیید دوره ای.

چگونه «انفجار نقش ها» را کاهش دهیم ؟

افزایش دانه دانه بودن منابع، استفاده از ABAC/قالب، به طور خودکار بررسی، و دور انداختن نقش های استفاده نشده.

مجموع

معماری IAM بالغ SSO + MFA، حداقل حقوق لازم، JML خودکار، سیاست های متمرکز و قابلیت مشاهده است. با ترکیب RBAC با مدل های ویژگی و رابطه ای، استفاده از JIT/JEA و PAM و خودکار سازی تأمین و چرخش های مخفی، دسترسی مدیریت شده، قابل حسابرسی و مقیاس پذیر را مطابق با نیازهای امنیتی و تجاری دریافت می کنید.