استفاده از Passkeyها ثابت می‌کند که کاربر در لحظه ورود، همان کسی است که ادعا می‌کند. پس از آن، Entra ID توکن‌هایی (Tokens) را صادر می‌کند تا کاربر برای هر ایمیل یا پیام در Teams مجبور به احراز هویت مجدد نباشد. نکته کلیدی این است که هدف نهایی مهاجمان، سرقت همین توکن‌هاست و بسیاری از روش‌های سرقت توکن، هرگز با صفحه ورود (Sign-in page) برخورد نمی‌کنند.
تفاوت احراز هویت و مدیریت نشست‌ها
بسیاری از سازمان‌ها تصور می‌کنند Passkeyها تمام مشکلات را حل می‌کنند، اما باید بین احراز هویت (Authentication) و نشست (Session) تفاوت قائل شد. توکن‌های مختلفی در این چرخه نقش دارند:
- Session Cookie: نشست مرورگر با Entra ID که توسط AiTM Proxy یا Infostealerها سرقت می‌شود.
- Refresh Token: اجازه می‌دهد اپلیکیشن‌ها به‌صورت بی‌صدا توکن‌های دسترسی جدید دریافت کنند و هدف Infostealerها یا اپلیکیشن‌های مخرب هستند.
- Primary Refresh Token (PRT): توکن SSO در سطح دستگاه (Windows, macOS, iOS) که توسط بدافزارهای دارای دسترسی Admin یا تلاش برای دور زدن TPM هدف قرار می‌گیرد.
- Access Token: توکنی که به سرویس‌هایی مانند Exchange یا SharePoint ارائه می‌شود و عمر کوتاهی دارد.
لایه‌های دفاعی برای مقابله با سرقت توکن
لایه ۱: اتصال دسترسی به دستگاه‌های مورد اعتماد
پیاده‌سازی سیاست‌های Conditional Access که برای اپلیکیشن‌های حساس، داشتن دستگاه Compliant (مدیریت شده توسط Intune) یا Hybrid Joined را الزامی می‌کند، کارایی توکن‌های سرقت شده را به‌شدت کاهش می‌دهد. در این حالت، اگر توکن در لپ‌تاپ مهاجم Replay شود، به دلیل عدم تطابق Device Claim، درخواست رد می‌شود.
لایه ۲: محافظت از توکن (Token Protection)
قابلیت Token Protection یک کنترل نشست در Conditional Access است که توکن نشست را به‌صورت رمزنگاری شده به دستگاه متصل (Bind) می‌کند. در نتیجه، توکنی که به ماشین دیگری کپی شده باشد، پذیرفته نمی‌شود. این قابلیت برای اپلیکیشن‌های Native در ویندوز، macOS و iOS (با شرایط خاص) در دسترس است و نیازمند لایسنس Entra ID P1 است.
لایه ۳: ارزیابی مستمر دسترسی (CAE) و طول عمر نشست
قابلیت Continuous Access Evaluation (CAE) به منابعی مانند Exchange و SharePoint اجازه می‌دهد تا به جای انتظار برای انقضای توکن، به رویدادهای بحرانی به‌صورت آنی واکنش نشان دهند. این رویدادها شامل مواردی چون حذف یا غیرفعال شدن حساب، تغییر رمز عبور، یا شناسایی ریسک بالای کاربر توسط Identity Protection است.
لایه ۴: شناسایی و پاسخ (Detection and Response)
پس از استقرار Passkeyها، رصد موارد زیر ضروری است:
- شناسایی ریسک‌های Identity Protection (مانند ناهنجاری در صادرکننده توکن).
- هشدار‌های Infostealer و Credential-access در Defender for Endpoint و Defender XDR.
- مانیتورینگ تغییر در متد ورود؛ برای مثال، کاربری که ماه‌ها با Passkey وارد شده و ناگهان از SMS برای MFA استفاده می‌کند، باید بررسی شود.
ترتیب صحیح پاسخ به حادثه (Incident Response)
در هنگام مواجهه با سرقت توکن، ترتیب اقدامات حیاتی است. اگر ابتدا نشست‌ها را Revoke کنید اما مهاجم هنوز دسترسی به یک متد ثبت شده یا اعتبارنامه فعال داشته باشد، می‌تواند مجدداً وارد شود. ترتیب پیشنهادی عبارت است از:
- حصر (Contain): شناسایی و حذف متدهای احرازی که توسط مهاجم ثبت شده‌اند.
- پاکسازی: بازنشانی (Reset) رمز عبور و اعتبارنامه‌ها.
- ابطال: Revoke کردن تمامی نشست‌های فعال (Revoke Sessions).
- تایید: بررسی اینکه ورودهای جدید حتماً از طریق متدهای Phishing-resistant و دستگاه‌های شناخته شده باشد.
اندازه‌گیری نرخ استفاده واقعی
یک اشتباه رایج، تکیه بر گزارش‌های ثبت‌نام (Registration Reports) است. اینکه ۸۰٪ کاربران Passkey ثبت کرده‌اند به این معنا نیست که از آن استفاده می‌کنند. برای تحلیل دقیق، باید از APIهای Beta در Microsoft Graph استفاده کرد تا متد احرازی واقعی (Actual Method) که در لحظه ورود استفاده شده است، استخراج شود. تفاوت بین «تعداد ثبت‌نام‌ها» و «تعداد استفاده‌های واقعی» دقیق‌ترین معیار برای سنجش موفقیت برنامه مهاجرت به Passkey است.
