بسیاری از مدیران امنیت با این تصور که تنها با فعال‌سازی Passkey یا کلیدهای امنیتی FIDO2، حساب‌های کاربری خود را در برابر حملات فیشینگ ایمن کرده‌اند، دچار اشتباه می‌شوند. واقعیت این است که فعال‌سازی (Enabling) یک متد احراز هویت با اجبار (Enforcing) به استفاده از آن تفاوت اساسی دارد. در سناریوهای واقعی، یک مدیر ممکن است یک کلید امنیتی جدید را ثبت کند و حساب را به عنوان “مقاوم در برابر فیشینگ” علامت‌گذاری کند، اما چند ماه بعد، همان حساب از طریق صفحات فیشینگ AiTM (Adversary-in-the-Middle) به دلیل وجود مسیرهای جایگزین و ضعیف‌تر، مورد نفوذ قرار می‌گیرد.
تفاوت دو موتور سیاست‌گذاری در Entra ID
برای مدیریت صحیح، باید درک کنید که Microsoft Entra ID دارای دو موتور سیاست‌گذاری مجزا است:
- سیاست‌های متدهای احراز هویت (Authentication Methods Policy): این بخش تعیین می‌کند که کاربر اصلاً اجازه دارد چه روش‌هایی را ثبت و استفاده کند.
- سیاست‌های دسترسی مشروط (Conditional Access): این بخش تعیین می‌کند که برای دسترسی به یک منبع خاص، چه روش‌هایی باید الزامی باشند.
اگر شما فقط متد جدید را در موتور اول فعال کنید اما در موتور دوم (Conditional Access) آن را به عنوان تنها روش مجاز تعیین نکنید، مهاجم می‌تواند با استفاده از روش‌های ضعیف‌تر مانند Push Notification یا SMS که همچگی در سیاست‌های پیش‌فرض پذیرفته شده‌اند، امنیت را دور بزند.
استفاده از Authentication Strengths برای امنیت حداکثری
راهکار اصلی، استفاده از قابلیت Authentication Strengths است. این قابلیت به شما اجازه می‌دهد به جای استفاده از گزینه کلی “Require multifactor authentication”، دقیقاً مشخص کنید که چه ترکیبی از روش‌ها مجاز است. مایکروسافت سه سطح پیش‌فرض ارائه می‌دهد:
- Multifactor authentication: شامل تمام روش‌ها از جمله رمز عبور، SMS، Push و غیره.
- Passwordless MFA: شامل روش‌هایی مانند Windows Hello for Business و FIDO2.
- Phishing-resistant MFA: سخت‌گیرانه‌ترین سطح که تنها روش‌های مقاوم در برابر فیشینگ مانند FIDO2 و Windows Hello for Business را می‌پذیرد.
همچنین می‌توانید با استفاده از Custom Strengths، محدودیت‌های خود را با استفاده از AAGUID اعمال کنید تا کاربران فقط مجاز به استفاده از مدل‌های خاصی از کلیدهای امنیتی باشند.
نقاط ضعف و محدودیت‌های حیاتی
در هنگام پیاده‌سازی، باید به چند نکته فنی توجه داشت:
- Device Code Flow: Passkeyها به تنهایی نمی‌توانند جلوی حملات Device Code Phishing را بگیرند. برای مقابله با این تهدید، باید در سیاست‌های Conditional Access، جریان Device Code را مسدود (Block) کنید.
- محدودیت‌های ثبت‌نام: سیاست‌هایی که احراز هویت مقاوم در برابر فیشینگ را اجبار می‌کنند، ممکن است مانع از ثبت‌نام اولیه کاربران در متدهای جدید شوند. بنابراین، فرآیند Onboarding باید با دقت طراحی شود.
- استفاده از حالت Report-only: قبل از اعمال سیاست‌های سخت‌گیرانه، حتماً از حالت Report-only استفاده کنید تا تأثیر سیاست بر کاربران واقعی و سرویس‌های مشترک (مانند Teams Rooms) را بسنجید و از مسدود شدن کاربران قانونی جلوگیری کنید.
در نهایت، توصیه می‌شود همیشه حساب‌های اضطراری (Break-glass accounts) را از این سیاست‌های سخت‌گیرانه مستثنی کنید تا در صورت بروز مشکل در سرویس احراز هویت، دسترسی مدیریت سازمان قطع نشود.
