
درخواست پیش از تأیید بررسی میشود
درخواست ورود روی تلفن همراه نمایش داده میشود و پس از بررسی، تأیید یا رد میشود. به این ترتیب، تأیید ورود روزمره در همان دستگاه انجام میشود.
- درخواست باز میشود
- جزئیات ورود بررسی میشود
- درخواست تأیید یا رد میشود
گروه فناوری و تحول دیجیتال سدید
احراز هویت چندعاملی سدید
دسترسی به سامانههای سازمانی با یک مرحلهٔ تأیید مستقل از گذرواژه محافظت میشود؛ هویت درخواستکننده، پیش از اعطای دسترسی بررسی میشود.


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

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

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

کد QR میتواند در جریان ثبت عامل یا تأیید درخواست استفاده شود؛ رفتار دقیق آن به پیادهسازی سامانه وابسته است.

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

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

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

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

برای گمشدن گوشی، تعویض دستگاه یا از دسترفتن عامل، مسیر بازیابی از پیش تعریف میشود و پیش از استقرار به کاربران اعلام میشود.
نکات فنی و اجرایی پیش از انتخاب و استقرار بررسی میشوند.
در MFA، از دو یا چند دستهٔ مستقل عامل هویتی استفاده میشود. در احراز هویت دوعاملی یا 2FA، دو عامل به کار گرفته میشود.
پس از ثبت حساب، کد TOTP بدون اتصال اینترنت تولید میشود؛ دسترسی به سامانهٔ مقصد ممکن است همچنان از طریق شبکه انجام شود. اعلان موبایل از طریق ارتباط شبکه دریافت میشود.
مسیر بازیابی باید از پیش تعریف شود: هویت دوباره بررسی، عامل قبلی غیرفعال و عامل جدید مطابق سیاست سازمان ثبت میشود.
امکان اتصال به پروتکلها، نسخه و معماری سامانه وابسته است. سازگاری باید در مرحلهٔ ارزیابی و پایلوت بررسی شود.
خیر. تأیید هویت بهمعنای مجازبودن همهٔ عملیات نیست. سطح دسترسی به دادهها و عملیات باید جداگانه و بر اساس نقش کاربر اعمال شود.
ثبت عامل، ورود موفق و ناموفق، محدودیت شبکه، تعویض دستگاه، بازیابی و تجربهٔ تماس با پشتیبانی باید در گروهی نماینده از کاربران ارزیابی شود.
خیر. دو مدرک از یک دسته لزوماً بهعنوان دو عامل مستقل پذیرفته نمیشوند. گذرواژه و پرسش امنیتی در دستهٔ «دانستنی» طبقهبندی میشوند.
درخواست مشاوره برای ارزیابی نیازهای سازمان ثبت میشود.