Conditional Access و PIM واقعاً چگونه از حملات محافظت می‌کنند؟

سیاست‌های رمزعبور از حملات حدس زدن جلوگیری می‌کنند. آنها برابر یک session token دزدیده‌شده، یک درخواست MFA فریب‌خورده، یا یک حساب admin دائمی که دو سال است با حقوق Global Administrator در حال نشستن است، کاری نمی‌کنند. Conditional Access و Privileged Identity Management (PIM) دو کنترل Azure AD / Entra ID هستند که واقعاً این شکاف‌ها را رفع می‌کنند، و هنگامی که با هم کار می‌کنند بهترین نتایج را می‌دهند.

Conditional Access پشت صحنه چه کاری انجام می‌دهد

Conditional Access یک موتور if-this-then-that است که در زمان ورود ارزیابی می‌شود. طرف "if" (سیگنال‌ها) شامل عضویت کاربر/گروه، وضعیت انطباق دستگاه، موقعیت شبکه، ریسک ورود (از Identity Protection)، برنامه‌ای که دسترسی می‌شود، و نوع برنامه کلاینت (مرورگر در مقابل پروتکل قدیمی) است. طرف "then" (کنترل‌ها) شامل: نیاز به MFA، نیاز به دستگاه منطبق، نیاز به برنامه کلاینت تایید‌شده، مسدود کردن دسترسی کاملاً، یا نیاز به پذیرش شرایط استفاده است.

سیاستی که در تقریباً هر tenant مهم است: legacy authentication را مسدود کنید. پروتکل‌هایی مانند POP، IMAP، و SMTP قدیمی‌تر از چالش‌های MFA مدرن پشتیبانی نمی‌کنند، بنابراین اولین چیزی هستند که ابزارهای credential-stuffing سعی می‌کنند. لاگ‌های ورود را فیلتر کردن شده توسط "Client App = Other clients" قبل از مسدود کردن بررسی کنید — اغلب یک scanner قدیمی یا یک دستگاه چاپگر چندکاره قدیمی را خواهید یافت که هنوز با basic auth احراز هویت می‌کند.

دومی که از روز اول برای داشتن آن ارزشمند است: MFA را برای تمام کاربران لازم کنید، با یک گروه استثنا برای حساب‌های break-glass فقط. MFA را به "فقط admins" محدود نکنید. حساب‌های کاربری استاندارد به‌خطرافتاده نحوه‌ای است که حمله‌کنندگان پای‌خود را قبل از اسکیل‌کردن امتیاز پا می‌گذارند.

ریسک ورود در مقابل ریسک کاربر — سیگنال‌های مختلف، پاسخ‌های مختلف

Identity Protection (بخشی از Entra ID P2) دو نمره ریسک جداگانه تولید می‌کند و درهم تنیدن آنها آسان است:

• Sign-in risk — این تلاش احراز هویت خاص نامنظم به نظر می‌رسد (سفر غیرممکن، IP ناشناس، خصوصیات ورود ناآشنا).
• User risk — این حساب برای دلیلی مرتبط با خود هویت پرچمگذاری شده است (اعتبارات نشتی‌شده در corpus breach پیدا‌شده، فعالیت مصرف‌شده تایید‌شده).

سیاست Conditional Access که به sign-in risk پاسخ می‌دهد معمولاً باید با MFA چالش کند — اگر کاربر واقعی می‌تواند چالش را انجام دهد، او را از طریق بگذارید. سیاستی که به user risk پاسخ می‌دهد باید یک reset رمزعبور را اجبار کند، زیرا اگر اعتبار خود قبلاً سوخته باشد، MFA به تنهایی کمک نمی‌کند.

چرا دسترسی admin دائمی مسئله بزرگ‌تری است

حتی با Conditional Access کامل، حسابی که Global Administrator را به‌طور دائمی نگه می‌دارد، هدفی است که به‌وضوح در دایرکتوری نشسته است. هرکسی که آن را به‌خطر بیندازد، کنترل کامل tenant را بدون هیچ مرحله اضافی به‌ارث می‌برد. PIM قسمت "دائمی" را حذف می‌کند.

با PIM، نقش‌های admin به‌عنوان eligible به‌جای active اختصاص داده می‌شوند. کاربر باید به‌طور صریح نقش را فعال کند، که یک توجیه لازمی، جریان تایید اختیاری، MFA re-confirmation، و یک پنجره محدود به‌زمان را اثارت می‌کند — معمولاً 1 تا 8 ساعت — بعد از آن نقش به‌طور خودکار غیرفعال می‌شود. هیچکس، حتی مالک حساب، Global Admin دائمی ندارد مگر اینکه آن را فعلاً استفاده می‌کنند.

پیکربندی حداقلی PIM که واقعاً قابل استفاده است

• هر نقش بالاتر از Helpdesk Administrator: eligible، نه دائمی.
• Global Administrator و Privileged Role Administrator: نیاز به تایید از یک admin دوم، نه فقط self-activation.
• Activation MFA لازمی، بدون استثنا.
• حداکثر مدت activation 4 ساعت مردم را مجبور می‌کند برای جلسات کار واقعاً جداگانه دوباره فعال کنند، که بررسی‌های audit تمیز‌تری نیز تولید می‌کند.
• Access reviews هر 90 روز در تمام eligible assignments — حساب‌ها برای یک project اضافه می‌شوند و وگرنه هرگز حذف نمی‌شوند.

کجای تیم‌ها این را اشتباه می‌کنند

شکست عام در طراحی سیاست نیست، در لیست استثنا است. یک سیاست Conditional Access با یک گروه "exclude these users because the app doesn't support MFA" به‌طور مداوم رشد‌کننده در نهایت نیمی از tenant را استثنا می‌کند. exclusion‌ها را یک backlog item با یک owner و تاریخ حذف پیگیری کنید، نه یک سطل دائمی.

شکست دوم break-glass account هایی هستند که واقعاً تست نشده‌اند. دو حساب اضطراری، استثنا‌شده از Conditional Access و PIM، با رمزهای عبور تصادفی طولانی ذخیره‌شده آفلاین و هشدار هر ورود — و کسی باید هر سه ماه یکبار سعی کند وارد آنها شود تا تأیید کند هنوز کار می‌کنند.

Conditional Access و PIM یک checkbox برای بررسی انطباق نیستند. آنها تفاوت میان یک اعتبار فریب‌خورده‌ای که یک ناراحتی است و آن‌که یک مصرف‌کردن کامل tenant است. اگر کنترل‌های هویت را به‌عنوان بخشی از یک ساخت Blue Team نقشه برداری می‌کنید، بخش‌های Cloud و Blue Team Korra Studio طرف تشخیص را پوشش می‌دهند — Identity Protection risk events واقعاً در Sentinel چگونه به‌نظر می‌رسند و نحوه هشدار برای الگوهای activation PIM غیرممکن.