ADSelfService Plus
Self-Service Password Reset وقتی خوب است که کاربر بدون تماس با Help Desk مشکلش را حل کند؛ ولی اگر احراز هویت ضعیف باشد، همان قابلیت می‌تواند مسیر حمله شود.
تیکت‌های فراموشی رمز عبور ساده‌اند اما زمان زیادی می‌گیرند. SSPR این بار را کم می‌کند، مشروط بر این‌که Enrollment و روش‌های احراز هویت از ابتدا درست طراحی شوند.
هدف فقط کم‌کردن تماس‌ها نیست؛ باید تجربه کاربر، امنیت هویت و امکان Audit در کنار هم دیده شوند.
سناریو: کاربر دورکار در اولین ساعت صبح
کاربر دورکار رمز خود را فراموش کرده و به VPN هم دسترسی ندارد. Help Desk هنوز شیفت کامل را شروع نکرده است. اگر SSPR درست پیاده شده باشد، کاربر با چند عامل معتبر هویت خود را اثبات و رمز را بازیابی می‌کند.
اما اگر تنها عامل یک سؤال امنیتی قدیمی یا ایمیل شخصی تأییدنشده باشد، مهاجم هم ممکن است همان مسیر را طی کند. تفاوت میان «خودخدمتی» و «خودخدمتی امن» در همین طراحی است.
مسئله را درست تعریف کنیم
SSPR باید بر اساس Risk و نوع کاربر Policy داشته باشد. حساب ادمین، کاربر عادی و پیمانکار لزوماً نباید مسیر بازیابی یکسانی داشته باشند.
MFA نیز باید از عامل‌هایی استفاده کند که مقاومت مناسبی در برابر فیشینگ و سوءاستفاده دارند و Enrollment آن‌ها قابل‌اعتماد است.
| مولفه | پرسش طراحی | ریسک بی‌توجهی |
|---|---|---|
| Enrollment | چطور هویت اولیه تأیید می‌شود؟ | ثبت عامل توسط فرد غیرمجاز |
| MFA | چند عامل و با چه سطح اعتمادی؟ | تصاحب حساب |
| Policy | برای چه گروه‌هایی متفاوت است؟ | سطح امنیت یکسان برای ریسک‌های متفاوت |
| Audit | چه رویدادهایی ثبت و هشدار می‌شوند؟ | نبود شواهد |
| Fallback | اگر عامل اصلی در دسترس نبود چه می‌شود؟ | بازگشت به روش ناامن |
مسیر اجرایی پیشنهادی
1. گروه‌های کاربری را جدا کنید
ادمین‌ها، کاربران حساس، پیمانکاران و کاربران عادی را با Policy متفاوت مدیریت کنید. یک الگوی واحد معمولاً یا بیش از حد سخت است یا بیش از حد باز.
2. Enrollment را کنترل‌شده انجام دهید
روش ثبت شماره، Authenticator یا عامل دیگر باید خودش قابل‌اعتماد باشد. اگر Enrollment ضعیف است، MFA قوی هم بعداً مشکل را کامل حل نمی‌کند.
3. حداقل دو مسیر معتبر داشته باشید
کاربر نباید با خرابی یک عامل کاملاً قفل شود، اما مسیر جایگزین نیز نباید به یک سؤال ساده یا تماس بدون احراز هویت ختم شود.
4. هشدارهای پرریسک را مشخص کنید
تعداد زیاد تلاش ناموفق، تغییر عامل احراز هویت یا Reset برای حساب حساس باید قابل‌مشاهده و قابل‌پیگیری باشد.
5. کاهش تیکت را با امنیت بسنجید
اگر تعداد تیکت کم شد ولی موارد Lockout یا خطای Enrollment بالا رفت، تجربه کاربر هنوز بهینه نشده است.
از کجا بفهمیم مسیر درست است؟
نرخ Self-Service موفق، کاهش تماس Help Desk، نرخ Enrollment کامل و تعداد رخدادهای مشکوک را هم‌زمان ببینید.
یک SSPR موفق باید کاربر را سریع‌تر به کار برگرداند، بدون این‌که Help Desk به نقطه دورزدن کنترل‌های امنیتی تبدیل شود.
خطاهای رایج
- اتکا به سؤال امنیتی ساده.
- Policy یکسان برای حساب‌های پرریسک و عادی.
- Enrollment بدون کنترل هویت اولیه.
- Fallback تلفنی بدون Runbook احراز هویت.
لینک‌های داخلی برای ادامه مطالعه
جمع‌بندی
SSPR یک پروژه Help Desk و Identity Security به‌طور هم‌زمان است. اگر فقط از زاویه کاهش تیکت دیده شود، بخشی از ریسک نادیده می‌ماند.
طراحی درست Enrollment، MFA، Policy و Audit کمک می‌کند سرعت بازیابی رمز و امنیت حساب با هم بهتر شوند.
کلیدواژه‌های این راهنما: SSPR و MFA در ADSelfService Plus، Self-Service Password Reset، MFA، Active Directory، مدیریت رمز عبور
