Risk-Based Authentication چیست؟ احراز هویت مبتنی بر ریسک چگونه کار می‌کند؟

احراز هویت مبتنی بر ریسک (Risk-Based Authentication یا RBA) روشی هوشمند برای کنترل ورود کاربران است که با بررسی عواملی مانند موقعیت جغرافیایی، آدرس IP، دستگاه، سابقه ورود و رفتار کاربر، میزان خطر هر درخواست را ارزیابی می‌کند. این سیستم متناسب با سطح ریسک می‌تواند ورود عادی را بپذیرد، احراز هویت چندمرحله‌ای درخواست کند یا دسترسی مشکوک را محدود سازد.

مقدمه: چرا رمز عبور صحیح همیشه به معنای ورود امن نیست؟

تصور کنید مدیر یک فروشگاه اینترنتی هر روز با لپ‌تاپ شخصی خود وارد پیشخوان سایت می‌شود. او معمولاً از یک مرورگر مشخص استفاده می‌کند و فعالیت مدیریتی خود را در ساعات نسبتاً ثابتی انجام می‌دهد.

اکنون فرض کنید شخص دیگری با نام کاربری و رمز عبور صحیح همان مدیر تلاش می‌کند از دستگاهی ناشناس و یک شبکه غیرمعمول وارد حساب شود.

اگر سیستم احراز هویت فقط صحت رمز عبور را بررسی کند، احتمال دارد هر دو درخواست را معتبر تشخیص دهد.

درحالی‌که شرایط این دو ورود کاملاً متفاوت است.

در درخواست اول، اطلاعات ورود با الگوی شناخته‌شده کاربر هماهنگی دارد. اما در درخواست دوم، چند نشانه غیرعادی وجود دارد که می‌تواند احتمال دسترسی غیرمجاز را افزایش دهد.

البته استفاده از دستگاه جدید یا تغییر کشور اتصال لزوماً نشانه حمله نیست. کاربر ممکن است سفر کرده باشد، VPN خود را تغییر داده باشد یا از گوشی جدید استفاده کند.

چالش اصلی دقیقاً همین‌جاست: چگونه می‌توان میان تغییرات طبیعی رفتار کاربر و تلاش‌های احتمالی برای تصاحب حساب تفاوت قائل شد؟

احراز هویت مبتنی بر ریسک برای پاسخ به این مسئله طراحی شده است.

به‌جای اعمال یک روش ثابت برای تمام درخواست‌ها، سیستم شرایط هر ورود را بررسی می‌کند و براساس میزان حساسیت آن تصمیم می‌گیرد.

برای مثال، ممکن است یک کاربر در شرایط عادی فقط با روش احراز هویت اصلی خود وارد شود، اما هنگام ورود از دستگاه ناشناس به تأیید اضافی نیاز داشته باشد.

این رویکرد می‌تواند امنیت را افزایش دهد، بدون اینکه برای تمام کاربران و در تمام شرایط مراحل غیرضروری ایجاد کند.

بااین‌حال، Risk-Based Authentication به‌تنهایی تضمین‌کننده امنیت حساب نیست. کیفیت داده‌های ورودی، نحوه امتیازدهی، سیاست‌های احراز هویت و روش مدیریت خطاها بر نتیجه آن تأثیر مستقیم دارند.

در ادامه، سازوکار احراز هویت مبتنی بر ریسک، اجزای فنی، کاربرد در وردپرس و ووکامرس، مزایا، محدودیت‌ها و روش پیاده‌سازی امن این معماری را بررسی می‌کنیم.

Risk-Based Authentication چیست؟

Risk-Based Authentication یا احراز هویت مبتنی بر ریسک، رویکردی در امنیت هویت دیجیتال است که سطح الزامات احراز هویت را براساس خطر احتمالی یک درخواست تعیین می‌کند.

در این معماری، سیستم علاوه بر بررسی اعتبارنامه‌های کاربر، اطلاعات محیطی، سابقه فعالیت و ویژگی‌های درخواست را نیز تحلیل می‌کند.

برای مثال، ورود از دستگاهی که قبلاً استفاده شده است ممکن است نسبت به ورود از یک دستگاه ناشناس ریسک کمتری داشته باشد.

همچنین درخواست تغییر رمز عبور، افزودن حساب بانکی یا حذف اطلاعات حساس می‌تواند حتی در یک نشست معتبر نیز به تأیید مجدد نیاز داشته باشد.

بنابراین RBA فقط مربوط به لحظه ورود نیست؛ بلکه می‌تواند در طول نشست و هنگام انجام عملیات حساس نیز مورد استفاده قرار گیرد.

مفهوم ریسک در احراز هویت

ریسک در این زمینه نشان‌دهنده میزان نگرانی سیستم درباره مشروع بودن درخواست یا پیامد احتمالی اعطای دسترسی است.

این نگرانی براساس یک یا چند نشانه امنیتی شکل می‌گیرد.

برای مثال:

• دستگاه استفاده‌شده برای حساب ناشناخته باشد.
• درخواست از شبکه‌ای با سابقه فعالیت مخرب دریافت شود.
• تعداد زیادی تلاش ناموفق پیش از ورود موفق رخ داده باشد.
• الگوی فعالیت با رفتار معمول حساب تفاوت قابل‌توجهی داشته باشد.
• کاربر قصد انجام عملیات مالی یا مدیریتی حساس داشته باشد.

هرکدام از این نشانه‌ها می‌توانند در تحلیل خطر مؤثر باشند.

اما هیچ‌کدام به‌تنهایی اثبات نمی‌کنند که یک حمله رخ داده است.

تفاوت احراز هویت و تشخیص ریسک

احراز هویت یا Authentication فرایندی است که هویت ادعاشده کاربر را بررسی می‌کند.

در مقابل، Risk Assessment به ارزیابی خطر احتمالی درخواست می‌پردازد.

برای نمونه، بررسی اینکه کاربر کلید امنیتی معتبر دارد، بخشی از احراز هویت است.

اما تشخیص اینکه ورود از یک شبکه غیرمعمول انجام می‌شود، یک نشانه ریسک محسوب می‌شود.

این دو مفهوم مکمل یکدیگرند.

سیستم نباید صرفاً به دلیل کم‌ریسک بودن یک درخواست، بدون بررسی معتبر هویت به کاربر دسترسی بدهد.

چرا استفاده از احراز هویت مبتنی بر ریسک اهمیت دارد؟

در بسیاری از وب‌سایت‌ها، ورود کاربران هنوز عمدتاً به نام کاربری و رمز عبور وابسته است.

این ساختار اگرچه ساده و قابل‌فهم است، در برابر برخی تهدیدها محدودیت دارد.

مقابله با تصاحب حساب کاربری

Account Takeover یا تصاحب حساب زمانی رخ می‌دهد که شخص غیرمجاز بتواند کنترل حساب کاربر را به دست بگیرد.

این وضعیت ممکن است بر اثر افشای اعتبارنامه‌ها، فیشینگ، بدافزار یا سوءاستفاده از نشست‌های معتبر ایجاد شود.

احراز هویت مبتنی بر ریسک می‌تواند هنگام مشاهده شرایط غیرمعمول، کنترل‌های بیشتری فعال کند.

برای مثال، اگر ورود با رمز صحیح از دستگاهی ناشناس انجام شود، سیستم می‌تواند تأیید دومرحله‌ای درخواست کند.

این کنترل ممکن است مانع استفاده مستقیم از یک رمز عبور سرقت‌شده شود.

کاهش خطر Credential Stuffing

Credential Stuffing به استفاده خودکار از ترکیب نام کاربری و رمز عبور افشاشده در سرویس‌های دیگر گفته می‌شود.

در این حملات، مهاجم الزاماً رمز عبور را حدس نمی‌زند؛ بلکه اعتبارنامه‌های موجود را روی سرویس هدف آزمایش می‌کند.

سیستم RBA می‌تواند نشانه‌هایی مانند تعداد زیاد درخواست‌ها، شبکه‌های مشکوک و الگوهای غیرعادی تلاش برای ورود را تحلیل کند.

البته برای مقابله مؤثر با این تهدید، استفاده از Rate Limiting، احراز هویت چندمرحله‌ای و کنترل‌های ضدبات نیز اهمیت دارد.

کاهش اصطکاک برای کاربران معتبر

الزام تمام کاربران به انجام مراحل اضافی در هر ورود می‌تواند تجربه کاربری را دشوار کند.

برای مثال، درخواست مکرر کد تأیید از کاربری که به‌طور مرتب از دستگاه شخصی خود استفاده می‌کند، ممکن است غیرضروری باشد.

RBA می‌تواند در شرایط کم‌ریسک از درخواست تأییدهای اضافی و اختیاری جلوگیری کند.

بااین‌حال، کنترل‌های احراز هویت اجباری نباید صرفاً به دلیل پایین بودن امتیاز ریسک حذف شوند.

محافظت از عملیات حساس

ورود موفق به حساب لزوماً به معنای مجاز بودن تمام عملیات حساس بدون بررسی مجدد نیست.

برای مثال، تغییر ایمیل حساب، افزودن دستگاه قابل اعتماد، تغییر اطلاعات برداشت یا ارتقای مجوز مدیریتی ممکن است به تأیید تازه نیاز داشته باشد.

احراز هویت مبتنی بر ریسک امکان اعمال چنین کنترل‌هایی را فراهم می‌کند.

احراز هویت مبتنی بر ریسک چگونه کار می‌کند؟

عملکرد Risk-Based Authentication را می‌توان به چند مرحله اصلی تقسیم کرد.

هر مرحله نقش مشخصی در شناسایی خطر و انتخاب پاسخ امنیتی دارد.

مرحله اول: دریافت درخواست ورود

فرایند با درخواست کاربر برای ورود به حساب آغاز می‌شود.

در این مرحله، سیستم می‌تواند اطلاعات اولیه‌ای مانند شناسه درخواست، زمان، آدرس شبکه و مشخصات مرورگر را دریافت کند.

اگر کاربر قبلاً از دستگاه مشخصی استفاده کرده باشد، ممکن است اطلاعات مربوط به دستگاه شناخته‌شده نیز در دسترس باشد.

این داده‌ها باید از منابع قابل اعتماد دریافت و با توجه به الزامات حریم خصوصی پردازش شوند.

مرحله دوم: جمع‌آوری سیگنال‌های ریسک

سیستم مجموعه‌ای از نشانه‌های امنیتی یا Risk Signals را بررسی می‌کند.

این نشانه‌ها می‌توانند شامل سابقه ورود، اعتبار IP، وضعیت دستگاه، رفتار شبکه و حساسیت عملیات باشند.

برای مثال، اگر کاربر معمولاً از یک دستگاه مشخص وارد شود اما درخواست جدید از دستگاهی کاملاً متفاوت دریافت شود، سیستم این تغییر را در ارزیابی لحاظ می‌کند.

نکته مهم این است که داده‌های ورودی نباید بدون اعتبارسنجی پذیرفته شوند.

بعضی مشخصات مرورگر و درخواست به‌راحتی قابل تغییر هستند و نباید مبنای مستقل تصمیم‌های حساس قرار بگیرند.

مرحله سوم: محاسبه میزان خطر

پس از جمع‌آوری اطلاعات، موتور ارزیابی ریسک یا Risk Engine نشانه‌ها را تحلیل می‌کند.

نتیجه ممکن است به شکل امتیاز عددی، احتمال تخمینی یا سطح خطر ارائه شود.

برای مثال، سیستم می‌تواند درخواست‌ها را به سه گروه تقسیم کند:

• ریسک پایین یا Low Risk
• ریسک متوسط یا Medium Risk
• ریسک بالا یا High Risk

این دسته‌بندی به سیاست سازمان و طراحی موتور ریسک بستگی دارد.

هیچ مقیاس عددی ثابتی وجود ندارد که برای تمام سامانه‌های احراز هویت معتبر باشد.

مرحله چهارم: انتخاب سیاست امنیتی

پس از تعیین سطح ریسک، سیستم تصمیم می‌گیرد چه کنترلی اجرا شود.

برای درخواست کم‌ریسک، ممکن است احراز هویت اصلی کافی باشد.

در شرایط متوسط، سیستم می‌تواند یک عامل تأیید اضافی درخواست کند.

در شرایط پرخطر نیز ممکن است اتصال موقتاً محدود شود یا کاربر به فرایند بازیابی و بررسی امنیتی هدایت شود.

این تصمیم باید براساس سیاست‌های از پیش تعریف‌شده و قابل ارزیابی باشد.

مرحله پنجم: اجرای احراز هویت تکمیلی

در صورت نیاز، کاربر باید مرحله امنیتی دیگری را تکمیل کند.

این مرحله می‌تواند شامل استفاده از Passkey، کلید امنیتی، برنامه تولید رمز یک‌بارمصرف یا روش دیگری باشد که سازمان تأیید کرده است.

اگر تأیید موفقیت‌آمیز باشد، سیستم می‌تواند براساس مجوزهای واقعی کاربر و نتیجه ارزیابی ریسک، دسترسی مناسب را برقرار کند.

موفقیت در چالش امنیتی نباید به‌صورت خودکار مجوز دسترسی به منابعی ایجاد کند که کاربر اساساً حق استفاده از آن‌ها را ندارد.

مرحله ششم: ایجاد و مدیریت نشست

پس از احراز هویت موفق، یک نشست یا Session معتبر ایجاد می‌شود.

این نشست باید دارای شناسه امن، محدودیت زمانی و سازوکار ابطال باشد.

در طول استفاده از حساب نیز ممکن است بعضی نشانه‌های خطر دوباره بررسی شوند.

برای مثال، اگر یک نشست مدیریتی رفتار غیرعادی نشان دهد، سیستم می‌تواند درخواست تأیید مجدد کند یا نشست را خاتمه دهد.

مرحله هفتم: ثبت رویداد و بهبود سیاست‌ها

نتیجه ارزیابی ریسک و تصمیم امنیتی باید به‌صورت مناسب ثبت شود.

این اطلاعات برای بررسی هشدارها، تحلیل خطاهای تشخیص و تنظیم سیاست‌ها کاربرد دارند.

بااین‌حال، ثبت داده‌ها باید محدود و محافظت‌شده باشد تا گزارش‌های امنیتی به منبع افشای اطلاعات حساس تبدیل نشوند.

مهم‌ترین عوامل مؤثر در امتیاز ریسک ورود

دقت یک سیستم RBA تا حد زیادی به کیفیت سیگنال‌های استفاده‌شده وابسته است.

استفاده هم‌زمان از چند نشانه مستقل معمولاً تصویر کامل‌تری نسبت به بررسی یک عامل منفرد ارائه می‌دهد.

آدرس IP و اعتبار شبکه

آدرس IP یکی از داده‌های متداول در بررسی درخواست‌های ورود است.

سامانه می‌تواند بررسی کند که IP مربوط به چه نوع شبکه‌ای است و آیا سابقه فعالیت مشکوک دارد یا خیر.

برای مثال، ممکن است یک آدرس در گزارش‌های معتبر تهدیدات سایبری به‌عنوان منبع حملات خودکار شناسایی شده باشد.

بااین‌حال، IP به‌تنهایی هویت کاربر را مشخص نمی‌کند.

چند کاربر می‌توانند از یک IP مشترک استفاده کنند و یک کاربر نیز ممکن است در طول روز چندین IP متفاوت داشته باشد.

بنابراین تغییر IP نباید به‌صورت خودکار معادل نفوذ تلقی شود.

موقعیت جغرافیایی

Geolocation یا موقعیت جغرافیایی تخمینی می‌تواند یکی دیگر از سیگنال‌های ریسک باشد.

فرض کنید کاربری چند دقیقه قبل از یک منطقه وارد حساب شده و اکنون درخواست دیگری از منطقه‌ای بسیار دور ثبت می‌شود.

این وضعیت ممکن است مشکوک باشد، اما لزوماً وقوع حمله را اثبات نمی‌کند.

VPN، شبکه‌های موبایل، پراکسی‌ها و خطای پایگاه‌های داده موقعیت‌یابی می‌توانند نتایج غیرواقعی ایجاد کنند.

بهتر است موقعیت جغرافیایی همراه با سایر نشانه‌ها ارزیابی شود.

شناسایی دستگاه

Device Recognition به شناسایی دستگاه‌ها یا مرورگرهایی اشاره دارد که قبلاً برای ورود به حساب استفاده شده‌اند.

این قابلیت ممکن است از کوکی دستگاه شناخته‌شده، اطلاعات مرورگر یا شناسه‌های مدیریت‌شده استفاده کند.

اگر دستگاه برای حساب ناشناخته باشد، سیستم می‌تواند ارزیابی دقیق‌تری انجام دهد.

اما شناخته‌شده بودن دستگاه نباید به‌تنهایی اثبات‌کننده هویت کاربر باشد.

برای مثال، اگر کوکی دستگاه به سرقت برود، اتکا به آن به‌عنوان عامل احراز هویت خطرناک خواهد بود.

اثرانگشت دستگاه یا Device Fingerprinting

اثر انگشت دستگاه از ترکیب برخی ویژگی‌های فنی مرورگر یا محیط کاربر ساخته می‌شود.

این ویژگی‌ها ممکن است شامل نسخه مرورگر، سیستم‌عامل، زبان، وضوح نمایشگر و مشخصات اتصال باشند.

چنین اطلاعاتی می‌توانند در شناسایی تغییرات غیرمعمول کمک کنند.

بااین‌حال، بسیاری از آن‌ها قابل جعل یا تغییر هستند.

همچنین جمع‌آوری گسترده اطلاعات دستگاه می‌تواند پیامدهای مهمی برای حریم خصوصی کاربران داشته باشد.

زمان ورود

زمان ورود می‌تواند در کنار سایر اطلاعات استفاده شود.

برای مثال، حسابی که معمولاً در ساعات اداری فعال است، ممکن است در نیمه‌شب درخواست ورود جدیدی دریافت کند.

این تغییر می‌تواند دلیلی برای بررسی بیشتر باشد.

اما زمان غیرمعمول به‌تنهایی معیار قابل اعتمادی نیست؛ زیرا کاربران ممکن است شیفت کاری، برنامه خواب یا شرایط متفاوتی داشته باشند.

سابقه تلاش‌های ناموفق

تعداد و الگوی درخواست‌های ناموفق می‌تواند نشانه‌ای از فعالیت خودکار یا تلاش برای دسترسی غیرمجاز باشد.

برای نمونه، درخواست‌های متعدد برای حساب‌های مختلف از یک شبکه مشخص ممکن است با Password Spraying ارتباط داشته باشند.

در مقابل، چند تلاش ناموفق از یک کاربر واقعی ممکن است فقط نتیجه فراموش کردن رمز عبور باشد.

سامانه باید میان این شرایط تفاوت قائل شود و از مسدودسازی بی‌دلیل کاربران جلوگیری کند.

اطلاعات افشای اعتبارنامه‌ها

اگر شواهد معتبری وجود داشته باشد که اعتبارنامه‌های یک حساب افشا شده‌اند، سطح خطر ممکن است افزایش یابد.

در چنین شرایطی، درخواست تغییر اعتبارنامه و بررسی روش‌های احراز هویت می‌تواند ضروری باشد.

این قابلیت باید با روش‌های امن و بدون افشای گذرواژه‌های کاربران اجرا شود.

حساسیت نقش و عملیات

نوع حساب نیز در تصمیم امنیتی اهمیت دارد.

برای مثال، ورود یک مدیر کل سایت با ورود کاربری که فقط مجاز به مشاهده محتوای عمومی حساب خود است، پیامدهای احتمالی متفاوتی دارد.

همچنین تغییر حساب بانکی یا حذف نسخه پشتیبان می‌تواند از مشاهده یک صفحه عادی حساس‌تر باشد.

به همین دلیل، موتور ریسک باید علاوه بر شرایط اتصال، حساسیت منبع و عملیات را نیز در نظر بگیرد.

امتیازدهی ریسک یا Risk Scoring چگونه انجام می‌شود؟

یکی از اجزای اصلی احراز هویت مبتنی بر ریسک، تبدیل مجموعه نشانه‌های امنیتی به یک تصمیم قابل اجراست.

این فرایند با عنوان Risk Scoring شناخته می‌شود.

مدل امتیازدهی مبتنی بر قوانین

در مدل Rule-Based، مجموعه‌ای از قوانین مشخص برای تحلیل درخواست استفاده می‌شود.

برای مثال، سازمان می‌تواند تعیین کند که ورود از دستگاه جدید نیازمند بررسی بیشتر باشد یا درخواست‌های دارای نشانه‌های قوی سوءاستفاده، محدود شوند.

مزیت این روش، سادگی نسبی، قابلیت توضیح و امکان حسابرسی تصمیم‌هاست.

در مقابل، اگر قوانین بیش‌ازحد ساده باشند، ممکن است الگوهای پیچیده را به‌درستی تشخیص ندهند.

مدل مبتنی بر یادگیری ماشین

در بعضی سامانه‌های پیشرفته، از Machine Learning برای تحلیل ارتباط میان سیگنال‌های متعدد استفاده می‌شود.

مدل می‌تواند براساس داده‌های معتبر، الگوهای رفتاری را شناسایی و احتمال غیرمجاز بودن یک درخواست را تخمین بزند.

بااین‌حال، استفاده از یادگیری ماشین به‌خودی‌خود دقت بالاتر را تضمین نمی‌کند.

کیفیت داده‌های آموزشی، تغییر رفتار کاربران، خطاهای برچسب‌گذاری و توانایی توضیح تصمیم‌ها اهمیت زیادی دارند.

نمونه فرضی امتیازدهی

فرض کنید یک سیستم آزمایشی از مقیاس صفر تا صد استفاده می‌کند.

در این مدل فرضی، صفر نشان‌دهنده خطر کمتر و صد نشان‌دهنده خطر بیشتر است.

این جدول صرفاً نمونه آموزشی است و یک استاندارد صنعتی یا فرمول آماده پیاده‌سازی محسوب نمی‌شود.

در یک سیستم واقعی، نشانه‌ها لزوماً مستقل نیستند و جمع ساده آن‌ها ممکن است نتیجه گمراه‌کننده ایجاد کند.

برای مثال، تغییر IP و تغییر موقعیت جغرافیایی ممکن است از یک علت مشترک ناشی شده باشند.

اگر هر دو بدون توجه به هم‌بستگی امتیاز بگیرند، احتمال بیش‌برآورد خطر وجود دارد.

تعیین آستانه‌های تصمیم‌گیری

فرض کنید در یک طراحی آزمایشی، سه محدوده ریسک تعریف شده است.

این اعداد صرفاً برای توضیح مفهوم هستند.

در عمل، آستانه‌ها باید براساس داده‌های معتبر، حساسیت سرویس، نرخ خطا و الزامات امنیتی تنظیم شوند.

همچنین ممکن است برخی نشانه‌های بسیار حساس، مستقل از امتیاز کلی به اجرای یک سیاست ویژه منجر شوند.

احراز هویت تطبیقی یا Adaptive Authentication چیست؟

Adaptive Authentication به روشی گفته می‌شود که الزامات احراز هویت را متناسب با شرایط تغییر می‌دهد.

در بسیاری از کاربردها، این اصطلاح با Risk-Based Authentication ارتباط بسیار نزدیکی دارد و گاهی به‌جای آن استفاده می‌شود.

بااین‌حال، می‌توان میان ارزیابی ریسک و اجرای تصمیم تطبیقی تفاوت مفهومی قائل شد.

Risk Assessment خطر درخواست را بررسی می‌کند.

Adaptive Authentication براساس نتیجه این ارزیابی، نوع یا شدت بررسی هویت را تنظیم می‌کند.

نمونه احراز هویت تطبیقی

فرض کنید یک کاربر از دستگاه شناخته‌شده وارد حساب خود می‌شود.

سامانه نشانه غیرعادی مهمی مشاهده نمی‌کند و کاربر مراحل احراز هویت تعیین‌شده برای حساب را تکمیل می‌کند.

در درخواست بعدی، همان کاربر از مرورگری ناشناس وارد می‌شود.

این بار سیستم مرحله تأیید بیشتری درخواست می‌کند.

در شرایط سوم، اگر نشانه‌های قوی تصاحب حساب وجود داشته باشند، سامانه ممکن است ورود را موقتاً محدود کند.

این تغییر رفتار براساس سطح خطر، نمونه‌ای از احراز هویت تطبیقی است.

آیا احراز هویت تطبیقی همیشه هوشمند و مبتنی بر AI است؟

خیر.

یک سامانه مبتنی بر قوانین مشخص نیز می‌تواند رفتار تطبیقی داشته باشد.

برای مثال، قانونی که هنگام ورود از دستگاه جدید، Passkey یا عامل دوم درخواست می‌کند، بدون نیاز به مدل یادگیری ماشین قابل اجراست.

هوش مصنوعی ممکن است در تحلیل سیگنال‌ها کمک‌کننده باشد، اما شرط ضروری برای پیاده‌سازی RBA نیست.

تفاوت Risk-Based Authentication با احراز هویت دومرحله‌ای

احراز هویت چندمرحله‌ای یا Multi-Factor Authentication یکی از مهم‌ترین روش‌های محافظت از حساب‌های کاربری است.

در MFA، کاربر باید شواهدی از حداقل دو دسته مستقل عامل احراز هویت ارائه کند.

این عوامل معمولاً شامل چیزی که می‌دانید، چیزی که در اختیار دارید و ویژگی زیستی شما هستند.

برای مثال، رمز عبور و کلید امنیتی می‌توانند دو عامل مستقل باشند.

تفاوت هدف دو فناوری

MFA هویت کاربر را با استفاده از عوامل مستقل بررسی می‌کند.

در مقابل، RBA شرایط درخواست را تحلیل می‌کند و درباره نیاز به کنترل‌های اضافی تصمیم می‌گیرد.

بنابراین RBA یک عامل احراز هویت محسوب نمی‌شود.

آدرس IP، موقعیت جغرافیایی یا دستگاه شناخته‌شده نیز به‌تنهایی جایگزین عامل دوم نیستند.

احراز هویت مرحله‌ای یا Step-Up Authentication

Step-Up Authentication به درخواست احراز هویت قوی‌تر هنگام افزایش حساسیت یا ریسک اشاره دارد.

برای مثال، کاربری ممکن است با روش معمول وارد حساب شده باشد، اما برای تغییر رمز عبور به تأیید مجدد نیاز پیدا کند.

RBA می‌تواند مشخص کند چه زمانی چنین مرحله‌ای ضروری است.

البته برای حساب‌های دارای الزامات امنیتی بالا، استفاده از MFA مقاوم در برابر فیشینگ ممکن است به‌صورت دائمی الزامی باشد.

مقایسه RBA و MFA

بهترین معماری معمولاً از این دو رویکرد به‌صورت مکمل استفاده می‌کند.

نقش Passkey و FIDO2 در احراز هویت مبتنی بر ریسک

Passkey یکی از روش‌های مدرن احراز هویت مبتنی بر رمزنگاری کلید عمومی است.

در این روش، کلید خصوصی مرتبط با اعتبارنامه نزد احرازکننده کاربر نگهداری می‌شود و سرور از کلید عمومی برای بررسی پاسخ رمزنگاری‌شده استفاده می‌کند.

چرا Passkey اهمیت دارد؟

Passkey می‌تواند وابستگی به رمزهای عبور قابل افشا یا قابل استفاده مجدد را کاهش دهد.

در پیاده‌سازی‌های صحیح، احراز هویت مبتنی بر Passkey در برابر بسیاری از حملات فیشینگ سنتی مقاوم است؛ زیرا اعتبارنامه به دامنه معتبر سرویس وابسته است.

بااین‌حال، نوع احرازکننده و نحوه تأیید کاربر بر سطح اطمینان امنیتی تأثیر دارد.

ترکیب Passkey با RBA

فرض کنید کاربر با یک Passkey معتبر وارد حساب شده است.

اگر سیستم نشانه‌های خطر جدیدی مشاهده کند، می‌تواند متناسب با سیاست خود، تأیید اضافی، بررسی نشست یا محدودسازی عملیات حساس را اجرا کند.

RBA در اینجا نقش تحلیل‌کننده شرایط را دارد و Passkey یکی از ابزارهای احراز هویت است.

محدودیت استفاده از پیامک

کدهای پیامکی هنوز در بعضی سرویس‌ها برای احراز هویت تکمیلی استفاده می‌شوند.

بااین‌حال، این روش در معرض خطرهایی مانند انتقال غیرمجاز شماره و بعضی حملات مهندسی اجتماعی قرار دارد.

برای حساب‌های بسیار حساس، استفاده از روش‌های مقاوم در برابر فیشینگ مانند کلیدهای امنیتی و Passkey مناسب‌تر است.

احراز هویت مبتنی بر ریسک چه حملاتی را کاهش می‌دهد؟

RBA می‌تواند به شناسایی یا محدودسازی بعضی فعالیت‌های غیرعادی کمک کند.

اما اثر آن به کیفیت پیاده‌سازی و کنترل‌های تکمیلی وابسته است.

حملات Brute Force

در حملات Brute Force، مهاجم ترکیب‌های مختلفی از گذرواژه‌ها را آزمایش می‌کند.

موتور ریسک می‌تواند افزایش غیرعادی تلاش‌های ورود را شناسایی کند.

در پاسخ، سیستم ممکن است سرعت درخواست‌ها را محدود کند، تأیید تکمیلی بخواهد یا هشدار صادر کند.

بااین‌حال، RBA نباید جایگزین Rate Limiting و سایر دفاع‌های ضدحمله خودکار شود.

حملات Password Spraying

در این روش، یک یا چند گذرواژه پرکاربرد روی حساب‌های متعدد آزمایش می‌شوند.

تحلیل الگوی درخواست‌ها در سطح شبکه و حساب‌های مختلف می‌تواند در شناسایی این رفتار کمک‌کننده باشد.

استفاده از اعتبارنامه‌های افشاشده

اگر نام کاربری و رمز عبور یک حساب در سرویس دیگری افشا شده باشند، مهاجم ممکن است برای ورود تلاش کند.

RBA می‌تواند درخواست‌های غیرمعمول را شناسایی و مرحله تأیید اضافه فعال کند.

البته اگر مهاجم به عوامل احراز هویت دیگر نیز دسترسی داشته باشد، محافظت دشوارتر می‌شود.

سوءاستفاده از نشست کاربری

Session Hijacking زمانی رخ می‌دهد که شخص غیرمجاز بتواند از یک نشست معتبر استفاده کند.

احراز هویت مبتنی بر ریسک، در صورت پیاده‌سازی پایش نشست، ممکن است تغییرات رفتاری یا شبکه‌ای مشکوک را تشخیص دهد.

اما اگر نشست سرقت‌شده از محیطی مشابه کاربر واقعی استفاده شود، تشخیص حمله دشوار خواهد بود.

سوءاستفاده از حساب‌های مدیریتی

حساب‌های مدیریتی معمولاً مجوزهای حساس‌تری دارند.

RBA می‌تواند هنگام ورود غیرعادی، تغییر تنظیمات امنیتی یا اقدام برای افزایش مجوزها، تأیید اضافی درخواست کند.

بااین‌حال، کنترل سطح دسترسی یا Authorization باید مستقل و در سمت سرور اجرا شود.

کاربرد Risk-Based Authentication در امنیت وردپرس

وردپرس از سازوکارهای مشخصی برای احراز هویت و مدیریت نشست‌های کاربران استفاده می‌کند.

در سایت‌های دارای کاربران متعدد، افزودن کنترل‌های مبتنی بر ریسک می‌تواند بخشی از راهبرد دفاعی باشد.

محافظت از صفحه ورود وردپرس

صفحه ورود وردپرس ممکن است هدف حملات خودکار یا تلاش برای استفاده از اعتبارنامه‌های افشاشده قرار گیرد.

با استفاده از یک راهکار معتبر RBA می‌توان شرایط ورود را بررسی و برای درخواست‌های مشکوک کنترل‌های تکمیلی تعریف کرد.

برای مثال، ورود مدیر سایت از دستگاه جدید ممکن است به تأیید اضافی نیاز داشته باشد.

در مقابل، درخواست عادی یک کاربر باید براساس سیاست امنیتی تعیین‌شده و بدون مانع غیرضروری پردازش شود.

استفاده از Hookهای احراز هویت

وردپرس امکاناتی برای توسعه جریان احراز هویت دارد.

برای مثال، فیلتر authenticate و فیلتر wp_authenticate_user در کنترل فرایند تأیید اعتبارنامه نقش دارند.

هوک wp_login_failed نیز می‌تواند برای مشاهده رویدادهای ناموفق ورود استفاده شود.

اما پیاده‌سازی چالش امنیتی چندمرحله‌ای نباید صرفاً به ثبت یک هوک محدود شود.

لازم است وضعیت چالش، مجوز ایجاد نشست، انقضای درخواست و مسیرهای جایگزین ورود نیز به‌درستی مدیریت شوند.

حفاظت از حساب مدیرکل

حساب Administrator در وردپرس معمولاً به بخش‌های بسیار حساسی از سیستم دسترسی دارد.

برای چنین حسابی، استفاده از MFA قوی و ترجیحاً مقاوم در برابر فیشینگ اهمیت دارد.

RBA می‌تواند به‌عنوان کنترل مکمل برای تشخیص ورودهای غیرعادی و درخواست تأیید مجدد هنگام عملیات حساس استفاده شود.

نباید به دلیل شناخته‌شده بودن IP یا دستگاه، کنترل‌های اجباری حساب مدیر به‌طور کامل حذف شوند.

بررسی مسیرهای جایگزین احراز هویت

یکی از خطرهای پیاده‌سازی ناقص RBA در وردپرس، محافظت کردن از یک صفحه ورود و نادیده گرفتن سایر مسیرهاست.

بسته به ساختار سایت، ممکن است مسیرهایی مانند ورود اختصاصی قالب، برنامه موبایل، اتصال SSO یا سایر APIها وجود داشته باشند.

همچنین رفتار XML-RPC و REST API باید با توجه به تنظیمات واقعی سایت بررسی شود.

برای مثال، Application Passwords در وردپرس سازوکار مستقلی برای احراز هویت بعضی درخواست‌های برنامه‌ای فراهم می‌کنند.

سیاست امنیتی باید مشخص کند این روش‌ها چه مجوزهایی دارند و چگونه محدود می‌شوند.

مدیریت نشست‌های وردپرس

پس از تأیید هویت، امنیت نشست همچنان اهمیت دارد.

کوکی‌های احراز هویت باید محافظت شوند و نشست‌های مشکوک امکان ابطال داشته باشند.

در صورت وقوع رویدادهای پرخطر، سامانه باید بتواند کاربر را به تأیید مجدد هدایت کند.

همچنین باید میان بررسی هویت و بررسی مجوزهای وردپرس تفاوت قائل شد.

برای نمونه، استفاده از current_user_can() برای کنترل قابلیت‌های کاربر همچنان ضروری است.

Nonceهای وردپرس نیز ابزار کمک به حفاظت از درخواست‌ها در برابر برخی حملات CSRF هستند و نباید جایگزین احراز هویت یا بررسی مجوز شوند.

استفاده از احراز هویت مبتنی بر ریسک در ووکامرس

فروشگاه‌های اینترنتی علاوه بر اطلاعات حساب کاربران، ممکن است نشانی‌ها، سفارش‌ها، تنظیمات پرداخت و اطلاعات مرتبط با فرایند خرید را مدیریت کنند.

به همین دلیل، ارزیابی ریسک برای برخی فعالیت‌های حساب می‌تواند اهمیت زیادی داشته باشد.

ورود مشتریان از دستگاه جدید

فرض کنید مشتری معمولاً از گوشی شخصی خود وارد حساب می‌شود.

اکنون یک درخواست ورود از دستگاه ناشناس دریافت شده است.

سیستم می‌تواند برای این درخواست تأیید بیشتری بخواهد، بدون اینکه الزاماً حساب کاربر را مسدود کند.

این موضوع به کاهش احتمال سوءاستفاده از اعتبارنامه‌های افشاشده کمک می‌کند.

تغییر اطلاعات حساس حساب

برخی عملیات حساس‌تر از مشاهده تاریخچه سفارش هستند.

برای مثال:

• تغییر ایمیل حساب
• تغییر رمز عبور
• افزودن روش بازیابی
• تغییر اطلاعات دریافت وجه
• مشاهده یا دریافت اطلاعات بسیار حساس
• تغییر تنظیمات امنیتی حساب

این عملیات می‌توانند به احراز هویت تازه یا تأیید اضافی نیاز داشته باشند.

محافظت از حساب مدیر فروشگاه

حساب مدیر فروشگاه ممکن است به سفارش‌ها، اطلاعات مشتریان و تنظیمات حساس دسترسی داشته باشد.

به همین دلیل، سیاست امنیتی این حساب نباید الزاماً مشابه حساب مشتری عادی باشد.

برای مدیران فروشگاه، MFA قوی، محدودسازی مجوزها و نظارت بر تغییرات مهم باید در اولویت قرار بگیرند.

جلوگیری از اختلال در تجربه خرید

یکی از چالش‌های استفاده از RBA در فروشگاه‌ها، ایجاد اصطکاک غیرضروری برای مشتریان است.

اگر هر تغییر جزئی در IP باعث درخواست مکرر تأیید شود، احتمال نارضایتی یا رها شدن فرایند خرید افزایش پیدا می‌کند.

در نتیجه، سیاست‌ها باید میان حساسیت عملیات، احتمال خطر و تجربه کاربری تعادل برقرار کنند.

البته امنیت تراکنش‌های مالی و الزامات ارائه‌دهنده پرداخت همچنان باید مستقل رعایت شوند.

تفاوت احراز هویت مبتنی بر ریسک با Zero Trust

Zero Trust یا معماری اعتماد صفر بر این اصل تأکید دارد که اعتماد نباید صرفاً براساس محل قرار گرفتن کاربر در شبکه اعطا شود.

در این رویکرد، دسترسی به منابع باید براساس هویت، سیاست‌ها و شرایط درخواست ارزیابی شود.

RBA می‌تواند یکی از ابزارهای تصمیم‌گیری در معماری Zero Trust باشد.

ارتباط ارزیابی ریسک با اعتماد صفر

در یک معماری Zero Trust، دسترسی به منابع حساس ممکن است به عواملی مانند هویت کاربر، وضعیت دستگاه و نوع منبع وابسته باشد.

RBA می‌تواند اطلاعاتی درباره خطر احتمالی درخواست ارائه کند.

برای مثال، اگر یک نشست از دستگاهی ناشناخته درخواست دسترسی به اطلاعات حساس داشته باشد، سیستم می‌تواند تأیید بیشتری درخواست کند.

تفاوت مفهومی

Zero Trust یک رویکرد گسترده برای طراحی کنترل دسترسی است.

در مقابل، Risk-Based Authentication بر ارزیابی خطر و تطبیق مراحل احراز هویت تمرکز دارد.

بنابراین استفاده از RBA به‌تنهایی به معنای پیاده‌سازی کامل Zero Trust نیست.

برای تحقق معماری اعتماد صفر، کنترل مجوزها، بخش‌بندی دسترسی، محافظت از منابع و نظارت مستمر نیز اهمیت دارند.

معماری فنی سیستم احراز هویت مبتنی بر ریسک

یک سامانه RBA می‌تواند از چند مؤلفه مستقل تشکیل شود.

جداسازی این مؤلفه‌ها به نگهداری بهتر، حسابرسی و توسعه کنترل‌ها کمک می‌کند.

لایه دریافت درخواست

این بخش درخواست‌های ورود یا عملیات حساس را دریافت می‌کند.

اطلاعات اولیه باید به‌شکل استاندارد ثبت و برای ارزیابی آماده شوند.

در معماری دارای Reverse Proxy یا CDN، تشخیص IP واقعی کاربر نیازمند پیکربندی صحیح زنجیره پراکسی‌های مورد اعتماد است.

نباید مقدار سرآیندهای قابل تغییر توسط کاربر را بدون اعتبارسنجی به‌عنوان IP واقعی پذیرفت.

لایه جمع‌آوری سیگنال

در این قسمت، اطلاعات مرتبط با دستگاه، شبکه، سابقه فعالیت و شرایط حساب گردآوری می‌شوند.

هر داده باید همراه با سطح اعتماد، زمان ثبت و محدودیت اعتبار خود بررسی شود.

برای مثال، داده موقعیت جغرافیایی قدیمی یا اطلاعات ناقص دستگاه نباید بدون توجه به کیفیت آن در تصمیم نهایی استفاده شود.

موتور ارزیابی ریسک

Risk Engine اطلاعات دریافت‌شده را تحلیل می‌کند.

این موتور می‌تواند مبتنی بر قوانین، مدل‌های آماری یا ترکیبی از چند روش باشد.

خروجی باید به‌اندازه کافی قابل تفسیر باشد تا تیم امنیت بتواند علت تصمیم‌های مهم را بررسی کند.

موتور سیاست‌گذاری

Policy Engine تصمیم می‌گیرد براساس سطح خطر چه اقدامی لازم است.

این بخش ممکن است برای نقش‌های مختلف کاربران، سیاست‌های متفاوتی اعمال کند.

برای مثال، درخواست حساس یک مدیر می‌تواند مستقل از کم بودن ریسک شبکه، به MFA نیاز داشته باشد.

سرویس احراز هویت

این مؤلفه وظیفه بررسی واقعی عوامل احراز هویت را بر عهده دارد.

در صورت نیاز به Step-Up Authentication، سیستم باید چالش معتبر ایجاد و نتیجه را بررسی کند.

لایه مدیریت نشست

پس از احراز هویت موفق، نشست کاربر باید به‌صورت امن ایجاد و نگهداری شود.

محدودیت زمانی، ابطال نشست، محافظت از کوکی‌ها و ارزیابی رویدادهای حساس در این بخش اهمیت دارند.

لایه ثبت رویداد و مانیتورینگ

این مؤلفه اطلاعات لازم برای حسابرسی و تشخیص رفتار غیرعادی را نگهداری می‌کند.

بهتر است تصمیم‌های مهم شامل شناسه درخواست، سطح خطر، دلیل کلی تصمیم و نتیجه چالش باشند.

ثبت گذرواژه، کد یک‌بارمصرف یا داده محرمانه غیرضروری در گزارش‌ها نباید انجام شود.

پایش مداوم نشست و Continuous Authentication

در بعضی معماری‌ها، بررسی ریسک فقط هنگام ورود انجام نمی‌شود.

سیستم ممکن است در طول یک نشست معتبر نیز نشانه‌های غیرعادی را تحلیل کند.

این قابلیت با عنوان Session Monitoring یا در برخی کاربردها Continuous Authentication شناخته می‌شود.

چرا بررسی اولیه کافی نیست؟

ممکن است یک نشست در ابتدا کاملاً معتبر باشد، اما بعداً شرایط آن تغییر کند.

برای مثال، احتمال دارد نشست کاربر در معرض سوءاستفاده قرار بگیرد یا یک عملیات بسیار حساس در ادامه فعالیت انجام شود.

در چنین شرایطی، تصمیم اولیه ورود لزوماً برای تمام مدت نشست کافی نیست.

چه اطلاعاتی بررسی می‌شوند؟

بسته به طراحی سامانه، مواردی مانند الگوی زمانی درخواست‌ها، تغییرات شبکه، رفتار عملیاتی و مشخصات دستگاه قابل بررسی هستند.

اما جمع‌آوری این اطلاعات باید متناسب با هدف امنیتی و الزامات حریم خصوصی باشد.

واکنش به فعالیت مشکوک

سیستم می‌تواند متناسب با شدت خطر، یکی از اقدامات زیر را اجرا کند:

• درخواست احراز هویت مجدد
• محدودسازی موقت عملیات حساس
• ارسال هشدار به کاربر
• پایان دادن به نشست مشکوک
• ارجاع رخداد برای بررسی امنیتی

باید توجه داشت که صرف تغییر شبکه موبایل یا IP نباید بدون ارزیابی تکمیلی باعث خاتمه فوری تمام نشست‌ها شود.

تفاوت پایش نشست با ردیابی دائمی کاربر

پایش امنیتی باید بر داده‌های لازم برای حفاظت از حساب تمرکز داشته باشد.

جمع‌آوری گسترده رفتار شخصی کاربر بدون ضرورت امنیتی، می‌تواند مشکلات حقوقی، اخلاقی و فنی ایجاد کند.

به همین دلیل، سیاست نگهداری داده و محدوده پایش باید روشن باشد.

تأثیر احراز هویت مبتنی بر ریسک بر تجربه کاربری

یکی از اهداف مهم RBA، ایجاد تعادل میان امنیت و سهولت استفاده است.

اما پیاده‌سازی نامناسب می‌تواند نتیجه معکوس داشته باشد.

کاهش درخواست‌های غیرضروری

اگر سیستم بتواند درخواست‌های کم‌ریسک را با دقت مناسب شناسایی کند، ممکن است از فعال‌سازی چالش‌های اضافی اختیاری جلوگیری کند.

این موضوع برای کاربرانی که به‌طور مکرر وارد حساب می‌شوند اهمیت دارد.

بااین‌حال، هرگونه کاهش مراحل احراز هویت باید با سطح اطمینان موردنیاز سرویس سازگار باشد.

جلوگیری از مسدودسازی اشتباه

کاربران واقعی ممکن است به دلایل طبیعی از دستگاه یا موقعیت متفاوت استفاده کنند.

برای مثال، سفر، استفاده از اینترنت موبایل یا تغییر مرورگر می‌تواند نشانه‌هایی مشابه رفتار غیرعادی ایجاد کند.

اگر سیستم بیش‌ازحد حساس باشد، احتمال مسدودسازی کاربران معتبر افزایش می‌یابد.

طراحی مسیر بازیابی امن

کاربری که به عامل دوم خود دسترسی ندارد، باید مسیر بازیابی مشخصی داشته باشد.

اما این مسیر نباید از احراز هویت اصلی ضعیف‌تر و قابل سوءاستفاده باشد.

برای مثال، اتکای صرف به پرسش‌های امنیتی قابل حدس یا اطلاعات عمومی شخصی، راهکار مناسبی برای بازیابی حساب حساس نیست.

ارائه پیام‌های قابل‌فهم

هنگامی که سیستم به بررسی اضافی نیاز دارد، بهتر است پیام واضحی نمایش دهد.

برای مثال، می‌توان اعلام کرد که به دلیل تغییر شرایط ورود، تأیید امنیتی بیشتری لازم است.

بااین‌حال، نمایش جزئیات دقیق امتیازدهی و تمام قواعد امنیتی ممکن است اطلاعات مفیدی برای سوءاستفاده فراهم کند.

خطاهای تشخیص در Risk-Based Authentication

هیچ موتور تشخیص ریسکی کاملاً بدون خطا نیست.

در ارزیابی عملکرد باید دو نوع خطای مهم بررسی شوند.

False Positive یا تشخیص مثبت اشتباه

False Positive زمانی رخ می‌دهد که سیستم یک درخواست مشروع را مشکوک تشخیص دهد.

برای مثال، کاربر واقعی در سفر وارد حساب می‌شود اما سیستم درخواست او را بسیار پرخطر ارزیابی می‌کند.

پیامد چنین خطایی می‌تواند افزایش درخواست‌های تأیید، محدودسازی اشتباه حساب و نارضایتی کاربران باشد.

False Negative یا تشخیص منفی اشتباه

False Negative زمانی رخ می‌دهد که سیستم درخواست خطرناک را کم‌ریسک تشخیص دهد.

برای مثال، مهاجم ممکن است از محیطی استفاده کند که به الگوی معمول کاربر شباهت دارد.

در چنین شرایطی، موتور ریسک احتمال دارد نشانه کافی برای فعال کردن کنترل اضافی پیدا نکند.

اهمیت تنظیم آستانه‌ها

اگر آستانه تشخیص بسیار حساس باشد، تعداد هشدارهای اشتباه افزایش می‌یابد.

اگر آستانه بیش‌ازحد آسان‌گیرانه باشد، برخی درخواست‌های خطرناک شناسایی نمی‌شوند.

بنابراین تنظیم آستانه‌ها باید براساس داده‌های واقعی و آزمون‌های کنترل‌شده انجام شود.

سنجش کیفیت تصمیم‌ها

برای ارزیابی عملکرد می‌توان از شاخص‌هایی مانند نرخ تشخیص، نرخ هشدار اشتباه و میزان موفقیت چالش‌های امنیتی استفاده کرد.

اما نباید صرفاً افزایش تعداد درخواست‌های مسدودشده را نشانه موفقیت دانست.

ممکن است بخشی از درخواست‌های مسدودشده متعلق به کاربران معتبر باشند.

حریم خصوصی و حفاظت از داده‌ها در RBA

احراز هویت مبتنی بر ریسک ممکن است برای تحلیل درخواست‌ها به اطلاعاتی مانند IP، مشخصات دستگاه، سابقه ورود و الگوهای رفتاری نیاز داشته باشد.

این داده‌ها می‌توانند از نظر حریم خصوصی حساس باشند.

اصل حداقل‌سازی داده

Data Minimization بیان می‌کند که فقط داده‌های ضروری برای هدف مشخص باید جمع‌آوری شوند.

برای مثال، اگر بررسی نوع شبکه و سابقه ورود برای تصمیم امنیتی کافی باشد، ممکن است نیازی به جمع‌آوری اطلاعات بسیار گسترده مرورگر وجود نداشته باشد.

محدودیت نگهداری اطلاعات

داده‌های ریسک نباید بدون سیاست مشخص برای مدت نامحدود ذخیره شوند.

مدت نگهداری باید متناسب با نیاز امنیتی، تعهدات قانونی و هدف پردازش تعیین شود.

محافظت از داده‌های ثبت‌شده

اطلاعات مربوط به دستگاه‌ها، نشست‌ها و رفتار کاربران باید در برابر دسترسی غیرمجاز محافظت شوند.

کنترل مجوزها، رمزگذاری مناسب و محدودسازی دسترسی کارکنان از اقدامات ضروری هستند.

شفافیت درباره پردازش اطلاعات

کاربران باید متناسب با قوانین قابل اعمال، از نحوه استفاده از داده‌های مرتبط با امنیت حساب آگاه شوند.

همچنین استفاده از اطلاعات برای اهداف نامرتبط نباید بدون مبنای مناسب انجام شود.

کاهش خطر تبعیض و تصمیم‌های ناعادلانه

استفاده نامناسب از موقعیت جغرافیایی، نوع شبکه یا ویژگی‌های دستگاه ممکن است باعث محدودیت غیرمنصفانه گروهی از کاربران شود.

برای مثال، استفاده از شبکه مشترک یا اینترنت با کیفیت پایین نباید به‌صورت پیش‌فرض باعث محرومیت دائمی از حساب شود.

بهتر است سیاست‌ها امکان بررسی مجدد و روش جایگزین امن برای کاربران واقعی فراهم کنند.

مهم‌ترین چالش‌های امنیتی پیاده‌سازی RBA

پیاده‌سازی Risk-Based Authentication علاوه بر مزایا، خطرهایی نیز دارد که باید از ابتدا در معماری بررسی شوند.

جعل بعضی سیگنال‌های امنیتی

بخش قابل‌توجهی از مشخصات مرورگر و درخواست توسط کلاینت ارائه می‌شود.

بنابراین مهاجم ممکن است بتواند برخی از این ویژگی‌ها را تغییر دهد.

به همین دلیل، اطلاعات دستگاه، User-Agent یا موقعیت تخمینی نباید مانند یک مدرک رمزنگاری‌شده هویت تلقی شوند.

آلوده شدن مدل رفتاری

اگر سامانه بدون بررسی کافی، هر ورود موفق را به‌عنوان رفتار کاملاً معتبر ثبت کند، احتمال دارد الگوی مورد انتظار حساب به‌تدریج تغییر کند.

برای کاهش این خطر، به‌روزرسانی الگوهای رفتاری باید براساس داده‌های دارای سطح اعتماد مناسب انجام شود.

ورود مشکوک نباید صرفاً به دلیل موفق بودن احراز هویت اولیه، به الگوی مورد اعتماد تبدیل شود.

کاهش امنیت مسیر بازیابی

گاهی سامانه ورود اصلی از MFA قوی استفاده می‌کند اما بازیابی حساب فقط به یک روش ضعیف وابسته است.

در چنین شرایطی، مهاجم ممکن است مسیر بازیابی را هدف قرار دهد.

به همین دلیل، تغییر عامل احراز هویت و بازیابی حساب باید تحت کنترل‌های امنیتی مناسب انجام شوند.

وابستگی به سرویس تشخیص ریسک

اگر موتور ریسک از سرویس خارجی استفاده کند، اختلال ارتباطی ممکن است بر فرایند ورود تأثیر بگذارد.

لازم است از قبل مشخص باشد در زمان عدم دسترسی به سرویس چه اتفاقی رخ دهد.

برای عملیات بسیار حساس، آزادسازی کامل دسترسی در شرایط خطا می‌تواند خطرناک باشد.

در مقابل، مسدودسازی تمام کاربران بدون مسیر جایگزین نیز می‌تواند مشکل عملیاتی ایجاد کند.

بنابراین سیاست Fail-Safe باید متناسب با حساسیت عملیات، قابلیت احراز هویت مستقل و نیاز تداوم سرویس طراحی شود.

افشای اطلاعات از طریق پیام‌های خطا

اگر سیستم برای حساب موجود و حساب ناموجود پیام‌های کاملاً متفاوت نمایش دهد، ممکن است امکان شناسایی حساب‌های معتبر فراهم شود.

بهتر است پاسخ‌های عمومی احراز هویت تا حد امکان از افشای اطلاعات غیرضروری جلوگیری کنند.

جزئیات امنیتی باید در گزارش‌های محافظت‌شده نگهداری شوند.

مراحل پیاده‌سازی احراز هویت مبتنی بر ریسک در سایت

راه‌اندازی RBA بهتر است به‌صورت تدریجی انجام شود.

اجرای ناگهانی قوانین سخت‌گیرانه روی تمام کاربران می‌تواند باعث اختلال در دسترسی و افزایش هشدارهای اشتباه شود.

مرحله اول: شناسایی حساب‌ها و منابع حساس

ابتدا باید مشخص شود چه حساب‌هایی در سایت وجود دارند و هرکدام چه سطح دسترسی دارند.

برای مثال، حساب مدیرکل، مدیر فروشگاه، پشتیبان و مشتری عادی ممکن است نیازهای متفاوتی داشته باشند.

همچنین عملیات حساس مانند تغییر رمز، مدیریت درگاه پرداخت و تغییر مجوزها باید شناسایی شوند.

مرحله دوم: تعیین هدف امنیتی

باید مشخص شود سامانه قرار است چه خطرهایی را کاهش دهد.

برای مثال، هدف می‌تواند کاهش خطر تصاحب حساب، محافظت از ورود مدیران یا کنترل عملیات مالی حساس باشد.

بدون تعریف هدف، انتخاب سیگنال‌ها و ارزیابی موفقیت دشوار خواهد بود.

مرحله سوم: انتخاب داده‌های ضروری

در این مرحله، سیگنال‌هایی انتخاب می‌شوند که برای هدف امنیتی ارزش واقعی دارند.

بهتر است از مجموعه‌ای محدود و قابل اعتماد شروع شود.

افزودن تعداد زیاد سیگنال کم‌کیفیت لزوماً دقت سیستم را افزایش نمی‌دهد.

مرحله چهارم: طراحی سیاست‌های ریسک

برای هر گروه حساب و نوع عملیات باید پاسخ امنیتی مشخصی تعریف شود.

برای مثال، ورود کم‌ریسک کاربر عادی، ورود پرخطر مدیر و تغییر اطلاعات مالی نباید الزاماً یک سیاست یکسان داشته باشند.

مرحله پنجم: انتخاب روش احراز هویت تکمیلی

در این مرحله، روش‌های Step-Up Authentication تعیین می‌شوند.

Passkey، کلید امنیتی یا سایر عوامل معتبر می‌توانند متناسب با سطح حساسیت استفاده شوند.

همچنین باید مسیر بازیابی امن برای کاربرانی که به عامل خود دسترسی ندارند طراحی شود.

مرحله ششم: یکپارچه‌سازی با سیستم ورود

موتور ریسک باید با جریان احراز هویت واقعی سایت هماهنگ شود.

در وردپرس، این موضوع شامل بررسی سازگاری با افزونه‌های ورود، نشست‌ها، حساب‌های مدیریتی و مسیرهای API است.

همچنین باید اطمینان حاصل شود که هیچ مسیر جایگزینی کنترل‌های اصلی را دور نمی‌زند.

مرحله هفتم: اجرای آزمایشی بدون مسدودسازی

یکی از روش‌های مناسب برای شروع، اجرای سامانه در حالت مشاهده یا Monitor Mode است.

در این حالت، موتور ریسک تصمیم‌های احتمالی خود را ثبت می‌کند اما هنوز محدودیت‌های جدیدی بر کاربران اعمال نمی‌شود.

این روش کمک می‌کند نرخ هشدار اشتباه و کیفیت سیگنال‌ها بررسی شوند.

مرحله هشتم: آزمایش سناریوهای مختلف

پیش از اجرای گسترده باید سناریوهایی مانند ورود از دستگاه جدید، تغییر شبکه، ورود ناموفق متعدد و بازیابی حساب آزمایش شوند.

همچنین عملکرد سیستم برای کاربران واقعی، دستگاه‌های مختلف و شرایط ارتباطی متفاوت اهمیت دارد.

این آزمایش‌ها باید در محیط مجاز و کنترل‌شده انجام شوند.

مرحله نهم: فعال‌سازی تدریجی

پس از ارزیابی نتایج، می‌توان سیاست‌ها را ابتدا برای حساب‌های منتخب یا عملیات مشخص فعال کرد.

برای مثال، ممکن است ابتدا حساب‌های مدیریتی تحت کنترل‌های جدید قرار بگیرند.

سپس با بررسی نرخ خطا، دامنه سیاست‌ها توسعه پیدا کند.

مرحله دهم: بازبینی و بهبود مداوم

پس از استقرار، سامانه باید به‌صورت دوره‌ای ارزیابی شود.

رفتار کاربران، الگوهای تهدید و ابزارهای احراز هویت در طول زمان تغییر می‌کنند.

بنابراین سیاست‌ها و مدل‌های ریسک نیز به بازبینی نیاز دارند.

شاخص‌های ارزیابی موفقیت احراز هویت مبتنی بر ریسک

برای مشخص شدن اثربخشی RBA، باید از معیارهای قابل اندازه‌گیری استفاده شود.

نرخ شناسایی درخواست‌های مشکوک

این معیار نشان می‌دهد سامانه چه بخشی از رویدادهای خطرناک تأییدشده را شناسایی کرده است.

ارزیابی باید براساس داده‌های معتبر انجام شود، نه صرفاً تعداد هشدارهای تولیدشده.

نرخ False Positive

این شاخص مشخص می‌کند چند درخواست مشروع به‌اشتباه مشکوک تشخیص داده شده‌اند.

بالا بودن این نرخ می‌تواند باعث افزایش هزینه پشتیبانی و نارضایتی کاربران شود.

نرخ موفقیت چالش‌های امنیتی

این معیار نشان می‌دهد چه تعداد از کاربران پس از دریافت تأیید اضافی، فرایند را با موفقیت تکمیل کرده‌اند.

تحلیل این اطلاعات می‌تواند مشکلات فنی یا تجربه کاربری را آشکار کند.

زمان پاسخ موتور ریسک

ارزیابی خطر نباید باعث تأخیر غیرقابل قبول در ورود کاربران شود.

به همین دلیل، زمان پردازش درخواست و وابستگی به سرویس‌های خارجی باید بررسی شود.

نرخ تصاحب حساب تأییدشده

در صورت وجود داده‌های قابل اعتماد، روند رخدادهای تصاحب حساب می‌تواند یکی از معیارهای مهم اثربخشی کنترل‌ها باشد.

البته کاهش این رخدادها ممکن است ناشی از چند اقدام امنیتی هم‌زمان باشد و نباید بدون تحلیل به RBA نسبت داده شود.

میزان اصطکاک تجربه کاربری

تعداد درخواست‌های MFA اضافی، نرخ رها شدن فرایند ورود و تعداد درخواست‌های پشتیبانی می‌توانند در ارزیابی تجربه کاربری مؤثر باشند.

هدف، کاهش مراحل غیرضروری بدون تضعیف کنترل‌های امنیتی اجباری است.

مقایسه احراز هویت سنتی و احراز هویت مبتنی بر ریسک

برای درک بهتر تفاوت‌ها، می‌توان دو معماری را از چند جنبه بررسی کرد.

این مقایسه به معنای ناامن بودن تمام روش‌های ثابت نیست.

برای مثال، احراز هویت با Passkey مقاوم در برابر فیشینگ و سیاست‌های مناسب می‌تواند حتی بدون موتور RBA پیشرفته نیز سطح امنیت بالایی فراهم کند.

همچنین یک موتور ریسک پیچیده با داده‌های نامعتبر ممکن است عملکرد نامناسبی داشته باشد.

اشتباهات رایج در استفاده از Risk-Based Authentication

بعضی خطاهای طراحی می‌توانند اثربخشی احراز هویت مبتنی بر ریسک را کاهش دهند.

۱. اعتماد کامل به IP

آدرس IP به‌تنهایی هویت کاربر را اثبات نمی‌کند.

استفاده از IP باید به‌عنوان یکی از نشانه‌های ریسک باشد، نه مبنای قطعی تصمیم.

۲. حذف MFA برای تمام درخواست‌های کم‌ریسک

کم بودن امتیاز خطر نباید باعث حذف کنترل‌های اجباری حساب‌های حساس شود.

سیاست حداقل سطح احراز هویت باید مستقل از امتیاز ریسک رعایت شود.

۳. مسدودسازی خودکار هر دستگاه جدید

دستگاه جدید لزوماً نشانه حمله نیست.

بهتر است سیستم در بسیاری از چنین شرایطی امکان تأیید امن هویت را فراهم کند.

۴. استفاده از اطلاعات غیرقابل اعتماد

بعضی سرآیندها و مشخصات کلاینت قابل جعل هستند.

اعتماد کامل به این داده‌ها می‌تواند باعث تصمیم‌های امنیتی اشتباه شود.

۵. نداشتن روش بازیابی امن

اگر کاربر نتواند عامل تأیید خود را بازیابی کند، ممکن است از حساب خارج بماند.

در مقابل، مسیر بازیابی بسیار ضعیف نیز خطر سوءاستفاده ایجاد می‌کند.

۶. ثبت بیش‌ازحد اطلاعات

ذخیره گسترده اطلاعات دستگاه و رفتار کاربران بدون ضرورت می‌تواند خطرهای حریم خصوصی ایجاد کند.

داده‌ها باید محدود، محافظت‌شده و دارای مدت نگهداری مشخص باشند.

۷. اجرای مستقیم روی تمام کاربران

فعال‌سازی ناگهانی قوانین جدید بدون آزمون می‌تواند باعث مسدودسازی گسترده کاربران واقعی شود.

بهتر است استقرار مرحله‌ای انجام شود.

۸. نادیده گرفتن APIها

اگر سیستم فقط فرم ورود اصلی را محافظت کند، ممکن است مسیرهای دیگر همچنان کنترل‌های ضعیف‌تری داشته باشند.

تمام روش‌های احراز هویت باید در محدوده طراحی امنیتی بررسی شوند.

۹. اتکای کامل به هوش مصنوعی

استفاده از AI بدون داده معتبر، نظارت و امکان بررسی نتایج لزوماً امنیت را افزایش نمی‌دهد.

قابلیت توضیح و کنترل تصمیم‌های مهم ضروری است.

۱۰. نداشتن معیار ارزیابی

بدون بررسی نرخ خطا و اثر واقعی کنترل‌ها، مشخص نمی‌شود سیستم تا چه اندازه مفید بوده است.

چک‌لیست امنیتی پیاده‌سازی Risk-Based Authentication

پیش از راه‌اندازی یا ارزیابی یک سیستم احراز هویت مبتنی بر ریسک، موارد زیر باید بررسی شوند.

سیاست‌های احراز هویت

• روش اصلی احراز هویت از امنیت کافی برخوردار باشد.
• حساب‌های حساس دارای MFA متناسب با سطح خطر باشند.
• عوامل احراز هویت مستقل از سیگنال‌های ریسک تعریف شوند.
• عملیات حساس امکان درخواست تأیید مجدد داشته باشند.
• مسیر بازیابی حساب از نظر امنیتی بررسی شده باشد.

مدیریت داده‌ها

• سیگنال‌های مورد استفاده مشخص و مستند باشند.
• منابع داده از نظر اعتبار بررسی شوند.
• اطلاعات غیرضروری جمع‌آوری نشوند.
• مدت نگهداری داده‌ها مشخص باشد.
• دسترسی به داده‌های ریسک محدود شود.

موتور ریسک

• سیاست‌های تصمیم‌گیری قابل بازبینی باشند.
• آستانه‌ها براساس آزمون تنظیم شوند.
• نشانه‌های هم‌بسته باعث امتیازدهی گمراه‌کننده نشوند.
• خطاهای تشخیص به‌صورت دوره‌ای بررسی شوند.
• رفتار سیستم هنگام اختلال سرویس مشخص باشد.

مدیریت نشست و مجوزها

• نشست‌ها دارای محدودیت زمانی مناسب باشند.
• امکان ابطال نشست مشکوک وجود داشته باشد.
• مجوزهای دسترسی در سمت سرور بررسی شوند.
• تغییرات حساس به احراز هویت تازه نیاز داشته باشند.
• مسیرهای API از سیاست‌های امنیتی مناسب پیروی کنند.

نظارت و عملیات

• رویدادهای مهم ثبت شوند.
• اطلاعات محرمانه در گزارش‌ها افشا نشوند.
• هشدارهای امنیتی قابل بررسی باشند.
• مسیر پشتیبانی و بازیابی تعریف شده باشد.
• سیاست‌ها پس از تغییر شرایط تهدید بازبینی شوند.

این چک‌لیست باید با توجه به نوع سایت، حساسیت اطلاعات و معماری واقعی تکمیل شود.

چه سایت‌هایی بیشتر به احراز هویت مبتنی بر ریسک نیاز دارند؟

Risk-Based Authentication برای تمام وب‌سایت‌ها به یک اندازه ضروری نیست.

در بعضی محیط‌ها، استفاده از احراز هویت قوی ثابت و کنترل‌های پایه می‌تواند پاسخ‌گوی نیاز امنیتی باشد.

اما در برخی سامانه‌ها، تحلیل شرایط ورود ارزش بیشتری دارد.

فروشگاه‌های اینترنتی

فروشگاه‌هایی که حساب‌های مشتریان، سفارش‌ها و اطلاعات حساس را مدیریت می‌کنند، می‌توانند از کنترل‌های تطبیقی بهره ببرند.

به‌خصوص هنگام تغییر اطلاعات حساب و عملیات مالی حساس، تأیید متناسب با ریسک می‌تواند مفید باشد.

پنل‌های مدیریتی

حساب‌های مدیر سیستم، مدیر فروشگاه و سایر نقش‌های دارای مجوز بالا از اهداف مهم حملات حساب کاربری هستند.

RBA می‌تواند در کنار MFA و کنترل مجوزها، لایه دیگری برای تشخیص رفتار غیرعادی فراهم کند.

سامانه‌های مالی

در سامانه‌هایی که عملیات مالی یا تغییر اطلاعات برداشت انجام می‌شود، ارزیابی شرایط درخواست اهمیت زیادی دارد.

البته الزامات قانونی و استانداردهای اختصاصی صنعت مالی باید مستقل رعایت شوند.

سرویس‌های دارای کاربران متعدد

در سرویس‌هایی با تعداد زیاد کاربر، بررسی دستی تمام ورودهای مشکوک عملی نیست.

موتور ریسک می‌تواند به اولویت‌بندی رویدادها و فعال‌سازی کنترل‌های متناسب کمک کند.

زیرساخت‌های سازمانی

در سازمان‌ها، دسترسی کارکنان ممکن است به دستگاه، نقش شغلی و حساسیت منبع وابسته باشد.

RBA می‌تواند با IAM، SSO و سامانه‌های Conditional Access ترکیب شود.

سؤالات متداول درباره Risk-Based Authentication

Risk-Based Authentication چیست؟

Risk-Based Authentication یا احراز هویت مبتنی بر ریسک روشی برای تحلیل شرایط ورود و تعیین کنترل امنیتی متناسب با خطر درخواست است. این روش از نشانه‌هایی مانند دستگاه، شبکه، سابقه ورود و حساسیت عملیات استفاده می‌کند.

آیا احراز هویت مبتنی بر ریسک همان MFA است؟

خیر. MFA برای اثبات هویت از عوامل مستقل استفاده می‌کند، درحالی‌که RBA خطر درخواست را ارزیابی می‌کند. این دو روش می‌توانند به‌صورت مکمل استفاده شوند.

آیا RBA بدون هوش مصنوعی کار می‌کند؟

بله. می‌توان یک سیستم احراز هویت مبتنی بر ریسک را با قوانین مشخص پیاده‌سازی کرد. استفاده از یادگیری ماشین اختیاری است و به نیاز و پیچیدگی سامانه بستگی دارد.

آیا تغییر IP باعث مسدود شدن حساب می‌شود؟

الزاماً خیر. تغییر IP ممکن است به دلایل طبیعی مانند استفاده از اینترنت موبایل، VPN یا تغییر شبکه رخ دهد. یک سامانه مناسب باید این موضوع را همراه با سایر نشانه‌ها بررسی کند.

آیا Risk-Based Authentication برای وردپرس قابل استفاده است؟

بله. می‌توان با راهکارهای سازگار با معماری وردپرس، شرایط ورود و بعضی عملیات حساس را ارزیابی کرد. بااین‌حال، محافظت از مسیرهای جایگزین ورود، نشست‌ها و مجوزها نیز ضروری است.

آیا RBA جلوی حملات Brute Force را می‌گیرد؟

این روش می‌تواند به شناسایی الگوهای مشکوک و فعال‌سازی کنترل‌های اضافی کمک کند، اما باید همراه با Rate Limiting و سایر اقدامات محافظتی استفاده شود.

آیا دستگاه شناخته‌شده به معنای ورود امن است؟

خیر. شناخته‌شده بودن دستگاه تنها یک نشانه است. اطلاعات دستگاه یا کوکی‌های مرتبط ممکن است تغییر کنند یا در معرض سرقت قرار بگیرند.

آیا RBA جایگزین رمز عبور است؟

خیر. RBA به‌تنهایی روش اثبات هویت نیست. البته می‌تواند همراه با روش‌های بدون رمز عبور مانند Passkey استفاده شود.

تفاوت Adaptive Authentication و Risk-Based Authentication چیست؟

این دو اصطلاح ارتباط نزدیک دارند. RBA بر ارزیابی خطر تأکید می‌کند و Adaptive Authentication به تغییر مراحل احراز هویت براساس شرایط اشاره دارد. در بسیاری از سامانه‌ها هر دو مفهوم بخشی از یک فرایند هستند.

آیا احراز هویت مبتنی بر ریسک امنیت را صددرصد تضمین می‌کند؟

خیر. هیچ موتور ریسکی بدون خطا نیست. مهاجم ممکن است از اعتبارنامه معتبر یا نشست سرقت‌شده استفاده کند و بعضی درخواست‌ها نیز ممکن است اشتباه طبقه‌بندی شوند.

آیا RBA باعث کند شدن ورود کاربران می‌شود؟

ارزیابی ریسک مقداری پردازش اضافی ایجاد می‌کند، اما تأثیر واقعی به طراحی معماری و منابع مورد استفاده بستگی دارد. پیاده‌سازی مناسب می‌تواند با کاهش چالش‌های غیرضروری، تجربه کلی ورود را بهتر کند.

آیا استفاده از VPN باعث افزایش امتیاز ریسک می‌شود؟

ممکن است بعضی سامانه‌ها استفاده از شبکه‌های ناشناس‌ساز را یکی از نشانه‌ها بدانند. اما استفاده از VPN به‌تنهایی اثبات‌کننده فعالیت مخرب نیست و نباید تنها معیار تصمیم باشد.

آیا RBA برای فروشگاه ووکامرسی مناسب است؟

بله، به‌ویژه برای حساب‌های مدیریتی و عملیات حساس مرتبط با حساب مشتری یا فروشگاه. البته طراحی باید به‌گونه‌ای باشد که فرایند خرید کاربران واقعی بی‌دلیل مختل نشود.

آیا می‌توان RBA را فقط برای مدیران فعال کرد؟

بله. سیاست‌ها می‌توانند براساس نقش و حساسیت منبع متفاوت باشند. برای حساب‌های مدیریتی، استفاده از احراز هویت قوی اجباری در کنار تحلیل ریسک مناسب است.

آیا موقعیت جغرافیایی کاربر دقیق تشخیص داده می‌شود؟

خیر. موقعیت مبتنی بر IP تقریبی است و ممکن است به دلیل VPN، پراکسی یا ساختار شبکه خطا داشته باشد. نباید آن را معادل موقعیت فیزیکی قطعی کاربر دانست.

چه زمانی احراز هویت مجدد لازم است؟

رویدادهایی مانند تغییر رمز عبور، بازیابی حساب، افزودن عامل احراز هویت و انجام عملیات حساس می‌توانند نیازمند تأیید مجدد باشند. سیاست دقیق به سطح حساسیت سرویس بستگی دارد.

آیا RBA برای سایت‌های کوچک ضروری است؟

الزاماً خیر. برای بسیاری از سایت‌های کوچک، استفاده از احراز هویت قوی، MFA، به‌روزرسانی و مدیریت مناسب نشست‌ها در اولویت قرار دارد. با افزایش تعداد کاربران و حساسیت اطلاعات، استفاده از RBA می‌تواند ارزش بیشتری داشته باشد.

جمع‌بندی: احراز هویت مبتنی بر ریسک چه نقشی در امنیت سایت دارد؟

احراز هویت مبتنی بر ریسک یکی از رویکردهای کاربردی برای هوشمندتر کردن تصمیم‌های امنیتی در سامانه‌های ورود و کنترل حساب‌های کاربری است.

در این روش، سیستم فقط به صحیح بودن نام کاربری و رمز عبور توجه نمی‌کند؛ بلکه شرایط درخواست، سابقه فعالیت، دستگاه، شبکه و حساسیت عملیات را نیز بررسی می‌کند.

نتیجه این تحلیل می‌تواند به انتخاب کنترل‌های متناسب با خطر کمک کند.

برای مثال، در شرایط عادی ممکن است نیازی به تأیید اضافی اختیاری نباشد، اما هنگام ورود از دستگاه ناشناس یا انجام عملیات حساس، سیستم احراز هویت قوی‌تری درخواست کند.

بااین‌حال، ارزش واقعی Risk-Based Authentication به کیفیت طراحی آن وابسته است.

اگر موتور ریسک بر داده‌های قابل جعل تکیه کند، آستانه‌ها بدون آزمایش تنظیم شوند یا مسیرهای بازیابی امنیت کافی نداشته باشند، ممکن است سامانه در برابر تهدیدهای مهم آسیب‌پذیر باقی بماند.

همچنین استفاده از RBA نباید باعث تضعیف کنترل‌های اجباری مانند MFA برای حساب‌های حساس شود.

بهترین رویکرد، ترکیب تحلیل ریسک با احراز هویت معتبر، مدیریت ایمن نشست، کنترل مجوزهای سمت سرور، محافظت از داده‌های کاربران و پایش رویدادهای امنیتی است.

برای سایت‌های وردپرسی، فروشگاه‌های ووکامرسی و سامانه‌های دارای حساب‌های حساس، این معماری می‌تواند به کاهش خطر تصاحب حساب، تشخیص رفتارهای غیرمعمول و افزایش کنترل بر عملیات مدیریتی کمک کند.

در نهایت، هدف Risk-Based Authentication این نیست که به هر ورود غیرعادی برچسب حمله بزند؛ بلکه باید خطر واقعی را با دقت بیشتری ارزیابی کند و متناسب با آن، کنترل امنیتی مناسب را اجرا کند.