فرض کنید یکی از کاربران سازمان برای ورود به لپتاپ، VPN و Outlook Web Access از همان حساب Active Directory استفاده میکند. روی حساب او MFA فعال است، اما روش احراز هویت هنوز بر پایه رمز عبور و کد یکبارمصرف است. اگر کاربر وارد صفحه جعلی شود و هم رمز عبور و هم کد را در اختیار مهاجم بگذارد، دو عامل احراز هویت عملاً در همان حمله افشا شدهاند.
اینجا مسئله فقط «داشتن MFA» نیست؛ مسئله این است که عامل احراز هویت تا چه اندازه در برابر فیشینگ مقاوم است. FIDO2 و Passkey برای پاسخ به همین نیاز طراحی شدهاند. در ManageEngine ADSelfService Plus میتوان Passkey را بهعنوان یک روش احراز هویت مبتنی بر WebAuthn برای سناریوهایی مانند ورود به پورتال، ورود به سیستمهای Windows/macOS/Linux، RDP، VPN، OWA و عملیات Self-Service به کار گرفت.
برای آشنایی با جایگاه این محصول در معماری امنیت هویت، ابتدا صفحه ADSelfService Plus مدانت را ببینید. این مقاله بهجای معرفی کلی محصول، روی اجرای Passkey و تصمیمهای عملیاتی آن تمرکز دارد.
Passkey چه تفاوتی با رمز عبور و OTP دارد؟
Passkey بر پایه رمزنگاری کلید عمومی کار میکند. هنگام Enrollment یک جفت کلید ساخته میشود: کلید خصوصی روی دستگاه یا Security Key باقی میماند و کلید عمومی در سرویس ثبت میشود. هنگام ورود، کاربر بهجای ارسال یک Secret قابل کپی، یک Challenge را با کلید خصوصی امضا میکند.
نکته مهم این است که Passkey به دامنه یا Relying Party ID متصل است. بنابراین Credential ایجادشده برای دامنه معتبر روی یک سایت فیشینگ با دامنه متفاوت قابل استفاده نیست. CISA نیز FIDO/WebAuthn را بهعنوان یکی از روشهای اصلی MFA مقاوم در برابر فیشینگ توصیه میکند.
| روش | چیزی که کاربر ارائه میکند | ریسک فیشینگ | کاربرد مناسب |
|---|---|---|---|
| رمز عبور | Secret قابل تایپ و کپی | بالا | بهتنهایی برای دسترسی حساس کافی نیست |
| SMS / Email OTP | کد یکبارمصرف | متوسط تا بالا | Fallback یا محیطهای کمریسکتر |
| TOTP | کد زماندار | متوسط | MFA عمومی |
| Push MFA | تأیید درخواست | وابسته به طراحی | ورود روزمره با کنترل مناسب |
| FIDO2 Passkey | امضای رمزنگاریشده وابسته به دامنه | بسیار کمتر | دسترسی حساس، Endpoint، VPN، OWA و Zero Trust |
ADSelfService Plus در چه سناریوهایی از FIDO2 Passkey استفاده میکند؟
طبق مستندات رسمی ManageEngine، ADSelfService Plus در وضعیت فعلی میتواند FIDO2 Passkey را در چند مسیر مهم استفاده کند:
- ورود به پورتال ADSelfService Plus
- ورود به Cloud Applicationها
- Machine Login روی Windows، macOS و Linux
- VPN و RADIUS MFA در سناریوی پشتیبانیشده
- Outlook Web Access یا OWA
- Password Reset و Account Unlock از طریق پورتال وب ADSelfService Plus
این دامنه کاربرد مهم است، چون سازمان میتواند بهجای داشتن یک MFA جدا برای Self-Service، یک MFA دیگر برای Endpoint و یک راهکار متفاوت برای VPN، بخش قابل توجهی از سیاست احراز هویت را در یک لایه Identity Security مدیریت کند.
Security Key یا Device Passkey؛ کدام بهتر است؟
ADSelfService Plus دو مدل اصلی Passkey را پشتیبانی میکند.
Security Key
Security Key یک کلید سختافزاری FIDO2 مانند YubiKey یا Titan Security Key است. Credential روی خود سختافزار نگهداری میشود و معمولاً از طریق USB، NFC یا Bluetooth استفاده میشود.
برای حسابهای حساس، مدیران زیرساخت، ادمینهای امنیتی یا سناریوهایی که نمیخواهید Credential در Cloud Sync شود، Security Key انتخاب قابل کنترلتری است.
Device Passkey
در این مدل Authenticator داخل دستگاه قرار دارد و کاربر با PIN یا Biometrics هویت خود را تأیید میکند. Windows Hello، Touch ID، Face ID و قابلیتهای مشابه میتوانند در این الگو نقش داشته باشند.
Device Passkey ممکن است Device-bound باشد و فقط روی همان دستگاه بماند یا بسته به پلتفرم، بهصورت Synced Passkey بین چند دستگاه همگام شود. ADSelfService Plus امکان محدود کردن نوع Passkey مجاز را دارد و سازمان میتواند Syncable Passkey را در محیطهایی که نیازمند کنترل سختگیرانهتر هستند غیرفعال کند.
یک تصمیم مهم قبل از راهاندازی: Access URL و RP ID را نهایی کنید
یکی از حساسترین نکات فنی FIDO2 در ADSelfService Plus قبل از Enrollment کاربران اتفاق میافتد، نه بعد از آن.
بر اساس راهنمای ManageEngine، سرویس باید با HTTPS و گواهی SSL معتبر در دسترس باشد و Access URL باید نام دامنه معتبر داشته باشد؛ استفاده از IP Address برای این سناریو مناسب نیست. CN یا SAN گواهی نیز باید با Hostname آدرس دسترسی تطابق داشته باشد.
مهمتر اینکه Access URL و RP ID باید قبل از Rollout نهایی شوند. اگر بعداً Access URL تغییر کند، RP ID هم تغییر میکند و Enrollmentهای FIDO2 قبلی میتوانند از اعتبار بیفتند؛ نتیجه چنین تغییری میتواند Re-enrollment گسترده کاربران باشد.
برای مثال اگر آدرس سرویس این باشد:
https://selfservice.example.com
انتخاب RP ID باید با Scope امنیتی موردنظر هماهنگ باشد. استفاده از Hostname کامل معمولاً Scope را محدودتر نگه میدارد، در حالی که Parent Domain میتواند Passkey را برای Subdomainهای بیشتری معتبر کند. این تصمیم باید قبل از ورود کاربران به مرحله Enrollment گرفته شود.
سناریو: Passkey برای ورود RDP و Endpoint
فرض کنید تیم زیرساخت از RDP برای مدیریت Windows Serverها استفاده میکند. حسابها رمز عبور قوی دارند و MFA هم فعال است، اما هدف این است که Authentication به Credential مقاومتر در برابر فیشینگ منتقل شود.
در ADSelfService Plus میتوان FIDO2 را برای Machine Login و سناریوهای RDP پشتیبانیشده وارد جریان کرد. طبق مستندات فعلی ManageEngine، روی Windows میتوان Security Key و در برخی سناریوهای RDP، Windows Hello یا Mobile-based Passkey را نیز به کار گرفت. جزئیات دقیق به نسخه سیستمعامل، نوع Connection و پشتیبانی WebAuthn بستگی دارد.
برای Rollout سازمانی بهتر است ابتدا سه گروه از هم تفکیک شوند:
- کاربران عادی: استفاده از Device Passkey روی دستگاه سازمانی مدیریتشده.
- کاربران دارای دسترسی حساس: Security Key سختافزاری با User Verification اجباری.
- مدیران و ادمینها: Security Key اختصاصی به همراه سیاست Backup/Recovery و حداقل یک روش جایگزین کنترلشده.
این تفکیک باعث میشود Convenience کاربران عادی با نیاز امنیتی حسابهای Privileged یکسان فرض نشود.
Passkey برای VPN چه ارزشی دارد؟
VPN یکی از مهمترین نقاطی است که Credential سرقتشده میتواند مستقیماً به دسترسی شبکه تبدیل شود. ADSelfService Plus میتواند MFA برای VPNهایی که از RADIUS/NPS استفاده میکنند ارائه کند و در مستندات فعلی خود FIDO2 Passkey را نیز در سناریوی پشتیبانیشده VPN/RADIUS مطرح کرده است.
در معماری مبتنی بر Windows NPS، افزونه ADSelfService Plus روی NPS نقش واسط را برای اجرای MFA دارد. قبل از Production باید سازگاری VPN، NPS، روش Authentication و تجربه کاربر در سناریوی قطع اینترنت یا Failover آزمایش شود.
برای VPN بهتر است فقط «موفق بودن Login» معیار تست نباشد. این موارد را هم بررسی کنید:
- رفتار در صورت گم شدن Security Key
- فرآیند Enrollment مجدد
- Fallback مجاز و غیرمجاز
- تأثیر تغییر Access URL
- دسترسی کاربران خارج از شبکه سازمان
- High Availability سرویس ADSelfService Plus
Passkey برای Password Reset و Account Unlock
Self-Service Password Reset زمانی مفید است که کاربر برای اثبات هویت مجبور نباشد با Help Desk تماس بگیرد؛ اما اگر فرایند Reset با عامل ضعیف محافظت شود، همان Self-Service میتواند به نقطه حساس امنیتی تبدیل شود.
ADSelfService Plus اجازه میدهد FIDO2 Passkey در Password Reset و Account Unlock از طریق پورتال وب نقش Authentication Factor داشته باشد. این قابلیت بهخصوص برای سازمانی مفید است که میخواهد فرایند بازیابی حساب از سؤال امنیتی یا OTPهای ضعیفتر فاصله بگیرد.
یک محدودیت عملی مهم وجود دارد: طبق مستند فعلی ManageEngine، FIDO2 Passkey برای Password Reset و Account Unlock در اپلیکیشن موبایل ADSelfService Plus پشتیبانی نمیشود و این سناریو باید از مسیرهای پشتیبانیشده انجام شود.
رابطه Passkey با Conditional Access چیست؟
Passkey بهتنهایی جای سیاست دسترسی را نمیگیرد. ممکن است سازمان بخواهد برای یک کاربر داخل شبکه از یک سطح Authentication و برای همان کاربر خارج از کشور یا روی Device ناشناس از سطح سختگیرانهتری استفاده کند.
ADSelfService Plus علاوه بر MFA، قابلیت Conditional Access دارد و میتواند تصمیمهای دسترسی را با Contextهایی مانند IP Address، زمان، Device و Geolocation ترکیب کند. در نتیجه معماری قویتر معمولاً از ترکیب این سه لایه ساخته میشود:
- Credential مقاومتر مانند FIDO2
- Policy مبتنی بر Context
- Logging و Audit برای مشاهده رفتار Authentication
برای تکمیل این دید در اکوسیستم ManageEngine، مقاله نظارت هوشمند بر امنیت اکتیودایرکتوری نیز به نقش پایش و Audit فعالیتهای حساس Active Directory میپردازد.
چرا همه کاربران را از روز اول به Passkey منتقل نکنیم؟
از نظر فنی ممکن است وسوسهانگیز باشد که Migration را یکباره انجام دهید، اما در محیط سازمانی بهتر است Enrollment مرحلهای باشد.
| فاز | Scope پیشنهادی | هدف |
|---|---|---|
| Pilot | تیم IT و امنیت | تست Access URL، RP ID، Browser و Recovery |
| فاز ۲ | ادمینها و کاربران پرریسک | کاهش ریسک Credential Theft |
| فاز ۳ | Remote Workerها و VPN Userها | تقویت دسترسی راه دور |
| فاز ۴ | کاربران عمومی | گسترش Passwordless / Phishing-resistant MFA |
در Pilot باید حداقل یک سناریوی Failure هم آزمایش شود: کاربری که تلفن خود را عوض کرده، Security Key را گم کرده یا روی دستگاه ناسازگار وارد شده است. طراحی Recovery باید قبل از Rollout گسترده مشخص باشد.
چند Passkey برای هر کاربر؟
مستند فعلی ADSelfService Plus اجازه Enrollment چند Passkey را برای هر کاربر میدهد و سقف پیکربندیشده میتواند تا پنج Passkey باشد. این قابلیت برای حسابهای حساس مفید است؛ برای مثال میتوان یک Security Key اصلی و یک Key پشتیبان کنترلشده داشت.
اما داشتن چند Passkey فقط زمانی امن است که Lifecycle آنها مدیریت شود. سازمان باید بداند:
- چه کسی Passkey را Enroll کرده است؟
- Passkey روی چه Device یا Keyای قرار دارد؟
- اگر کاربر سازمان را ترک کرد، Enrollmentها چگونه حذف میشوند؟
- اگر Device گم شد، Revocation چطور انجام میشود؟
- چه کسی اجازه Re-enrollment دارد؟
این موضوع Passkey را به چرخه عمر هویت متصل میکند. در همین زمینه، مقاله Onboarding و Offboarding کاربران با ADManager Plus نشان میدهد چرا فرآیند ورود و خروج کاربر باید از ایجاد حساب تا حذف دسترسیها یکپارچه دیده شود.
Passkey جای Password Policy را میگیرد؟
در کوتاهمدت، در بیشتر سازمانها خیر. هنوز بسیاری از سرویسها، Legacy Applicationها و Workflowهای سازمانی Password را نیاز دارند. Passkey میتواند سطح Authentication را برای بخش مهمی از مسیرهای ورود تقویت کند، اما Password Hygiene همچنان برای حسابهایی که Password دارند لازم است.
مزیت ADSelfService Plus این است که Password Self-Service، Password Policy، MFA، SSO و Conditional Access را در کنار هم قرار میدهد؛ بنابراین گذار به Passwordless لازم نیست با حذف ناگهانی تمام کنترلهای موجود انجام شود.
Checklist پیشنهادی قبل از فعالسازی FIDO2
- Access URL نهایی را قبل از Enrollment مشخص کنید.
- HTTPS و SSL معتبر را فعال کنید.
- CN/SAN گواهی را با Hostname بررسی کنید.
- RP ID را با Scope امنیتی درست انتخاب کنید.
- نوع مجاز Passkey را تعیین کنید: Security Key، Device Passkey یا هر دو.
- در صورت نیاز Synced Passkey را غیرفعال کنید.
- User Verification را برای حسابهای حساس روی Required قرار دهید.
- Recovery و Lost Key Scenario را مستند کنید.
- Pilot را با IT و Security شروع کنید.
- RDP، VPN، OWA و Endpoint را جداگانه تست کنید.
- Browser و OSهای واقعی کاربران را در تست وارد کنید.
- فرآیند Offboarding و Revocation Passkey را مشخص کنید.
- قبل از Rollout، نسخه و Edition موجود ADSelfService Plus را با نیازهای MFA سازمان تطبیق دهید.
چه زمانی Security Key از Device Passkey بهتر است؟
اگر کاربر به سیستمهای Tier-0، زیرساخت هویتی، تجهیزات شبکه یا سامانههای بسیار حساس دسترسی دارد، Security Key اختصاصی معمولاً کنترل بیشتری ایجاد میکند؛ چون Credential میتواند روی سختافزار مشخص و بدون Cloud Sync نگهداری شود.
برای کاربران عمومی، Device Passkey تجربه سادهتری دارد و میتواند از Biometrics یا PIN همان دستگاه استفاده کند. انتخاب درست باید بر اساس Risk Tier باشد، نه یک Policy یکسان برای همه.
شاخصهایی که بعد از Rollout باید اندازه بگیرید
| KPI | چرا مهم است؟ |
|---|---|
| درصد کاربران Enrollشده | میزان Adoption واقعی را نشان میدهد |
| تعداد Password Reset Ticket | اثر Self-Service روی Help Desk را میسنجد |
| تعداد MFA Failure | مشکل تجربه کاربری یا سازگاری را آشکار میکند |
| Lost Key / Recovery Request | کیفیت فرآیند Recovery را نشان میدهد |
| درصد Loginهای FIDO2 | میزان مهاجرت از روشهای ضعیفتر را مشخص میکند |
| تعداد Account Lockout | اثر تغییر Authentication بر عملیات را میسنجد |
سخن پایانی
مقاوم کردن احراز هویت در برابر فیشینگ فقط با افزودن یک کد دوم به Password حل نمیشود. Passkey و FIDO2 مدل Authentication را از Secret قابل انتقال به یک Credential رمزنگاریشده و وابسته به دامنه تبدیل میکنند.
ADSelfService Plus این مدل را در کنار Self-Service Password Management، Endpoint MFA، VPN، OWA، SSO و Conditional Access قرار میدهد. مهمترین نکته برای یک استقرار موفق، انتخاب Authenticator نیست؛ طراحی درست Access URL، RP ID، Recovery، Lifecycle و Rollout مرحلهای است.
اگر قصد دارید ADSelfService Plus را برای Active Directory، Endpoint MFA، VPN یا Passwordless Authentication ارزیابی کنید، صفحه ADSelfService Plus مدانت نقطه شروع فنی و تجاری مناسبی است. برای برآورد لایسنس میتوانید از استعلام قیمت محصولات ManageEngine و برای طراحی سناریوی استقرار از درخواست دمو و مشاوره مدانت استفاده کنید.
منابع
- ManageEngine ADSelfService Plus - FIDO2 Passkeys
- ADSelfService Plus Resources
- ADSelfService Plus Solution Architecture
- CISA - More than a Password
