اقتصاد دیجیتال فقط به اپلیکیشن، درگاه و اتصال API نیاز ندارد؛ به زیرساختی نیاز دارد که بداند چه شخص یا موجودیتی، با چه میزان اعتبار و تا کجا مجاز به عمل است. کد ملی، شماره همراه و پیامک در این زنجیره مفیدند، اما هیچکدام بهتنهایی «هویت دیجیتال» نیستند.
به گزارش روابط عمومی شرکت رهآورد سامانههای امن (رهسا)، در مطلب پیشین با عنوان «رمز عبور، گلوگاه امنیت دیجیتال؛ وقت تغییر مدل احراز هویت است» درباره محدودیتهای گذرواژه و ضرورت حرکت بهسوی روشهای مقاومتر صحبت شد. بااینحال، عبور از رمز عبور فقط بخشی از مسئله است. حتی قویترین روش ورود نیز نمیتواند ضعف در اثبات اولیه هویت، مدیریت دسترسی، بازیابی حساب یا چرخه عمر کاربران را جبران کند.
بانکداری غیرحضوری، پرداخت، اعتباردهی دیجیتال، بیمه آنلاین، امضای الکترونیکی و خدمات دولت هوشمند، همگی بر یک پرسش مشترک بنا شدهاند: سامانه با چه میزان اطمینان میداند طرف مقابل چه کسی است و چه اختیاری دارد؟ هرچه ارزش تراکنش یا حساسیت داده بیشتر باشد، پاسخ به این پرسش نیز اهمیت بیشتری پیدا میکند.
در ایران، بخش بزرگی از این اطمینان همچنان با ترکیبی از کد ملی، شماره همراه، گذرواژه، تصویر مدرک و کد پیامکی ساخته میشود. این ابزارها در جای درست خود کاربرد دارند؛ مسئله از جایی آغاز میشود که شناسه، کانال ارتباطی و عامل احراز هویت بهجای یک معماری منسجم هویت به کار گرفته شوند. نتیجه، زنجیرهای است که ممکن است در ظاهر دیجیتال باشد، اما در برابر جعل، فیشینگ، بازیابی غیرمجاز و خطاهای عملیاتی شکننده باقی میماند.
هویت دیجیتال، فقط احراز هویت نیست
در گفتوگوهای روزمره، هویت دیجیتال اغلب با «احراز هویت» یا همان ورود کاربر یکی دانسته میشود. این برداشت، بخش بزرگی از مسئله را نادیده میگیرد. هویت دیجیتال زنجیرهای از شناسایی، اثبات هویت، صدور و اتصال اعتبارنامه، احراز هویت، مجوزدهی، مدیریت چرخه عمر، بازیابی و حسابرسی است.
شناسایی مشخص میکند کاربر ادعا میکند چه کسی است. اثبات هویت میسنجد این ادعا با شواهد و منابع معتبر سازگار است یا نه. احراز هویت در مراجعات بعدی بررسی میکند ارائهکننده اعتبارنامه همان هویتی است که پیشتر ثبت شده است. مجوزدهی نیز تعیین میکند آن هویت پس از ورود، به کدام داده یا عملیات دسترسی دارد.
این تمایز فقط یک بحث واژگانی نیست. اگر مرحله اثبات هویت ضعیف باشد، ممکن است اعتبارنامهای قوی برای فردی نادرست صادر شود. اگر مجوزدهی دقیق نباشد، یک کاربر کاملاً احرازشده میتواند بیش از نیاز خود دسترسی داشته باشد. اگر بازیابی حساب آسانتر از ورود اصلی باشد، مهاجم بهجای شکستن روش احراز هویت، ضعیفترین مسیر بازگشت به حساب را هدف میگیرد.
راهنمای هویت دیجیتال NIST نیز هویت را به یک لحظه ورود تقلیل نمیدهد و میان سطح اطمینان در اثبات هویت، احراز هویت و فدراسیون تمایز قائل میشود. پیام عملی این نگاه روشن است: برای همه خدمات، کاربران و عملیات نمیتوان یک سطح کنترل ثابت تعریف کرد. یک خدمت کمریسک ممکن است به حداقل اطلاعات نیاز داشته باشد، اما افتتاح حساب، تغییر شماره همراه، دسترسی به داده حساس یا تأیید یک عملیات مالی، سطح اطمینان بالاتری میطلبد.
کد ملی و پیامک کجای زنجیره اعتماد قرار میگیرند؟
کد ملی یک شناسه است؛ یعنی کمک میکند رکورد یک فرد از دیگران متمایز شود. شماره همراه نیز معمولاً یک کانال ارتباطی و در برخی فرایندها نشانهای از دسترسی به سیمکارت است. تطبیق این دو میتواند یکی از کنترلهای شناسایی یا اثبات هویت باشد، اما نشان نمیدهد فردی که اکنون پشت دستگاه قرار دارد، همان صاحب واقعی هویت است.
همین مرز درباره اطلاعاتی مانند تاریخ تولد، شماره کارت، تصویر کارت ملی یا نشانی نیز وجود دارد. این دادهها درباره فرد اطلاعات میدهند، اما لزوماً حضور و اراده او را در لحظه تعامل اثبات نمیکنند. بخشی از آنها ممکن است عمومی، قابل حدس یا در نشتهای اطلاعاتی قابل دسترس باشند. بنابراین نباید به راز مشترکی تبدیل شوند که امنیت حساب به محرمانهماندن آنها وابسته است.
پیامک نیز به دلیل فراگیری و سادگی پیادهسازی، سالها به ابزار پیشفرض بسیاری از خدمات تبدیل شده است. بااینحال، کد پیامکی یک عامل قابلانتقال است. کاربر میتواند آن را در صفحه جعلی وارد کند، در تماس مهندسی اجتماعی افشا کند یا در حمله واسطهگری، همان لحظه در اختیار مهاجم قرار دهد. یکبارمصرفبودن کد، فرصت استفاده مجدد را محدود میکند؛ اما آن را ذاتاً در برابر فیشینگ مقاوم نمیسازد.
این محدودیتها به معنای حذف فوری کد ملی، شماره همراه یا پیامک از تمام فرایندها نیست. هر کدام میتوانند در جایگاه مناسب خود مفید باشند. مسئله، تبدیلکردن آنها به ستون اصلی اعتماد یا استفاده دوباره از همان کانال برای ثبتنام، ورود، بازیابی حساب و تایید عملیات حساس است. معماری بالغ میان شناسه، مدرک هویتی، کانال ارتباطی، اعتبارنامه و ابزار بازیابی تفاوت قائل میشود.
هویت ضعیف چگونه به هزینه کسبوکار تبدیل میشود؟
هزینه معماری ضعیف هویت فقط در رخدادهای امنیتی یا تقلب دیده نمیشود. بخشی از آن در ریزش کاربران هنگام ثبتنام، ناتمامماندن افتتاح حساب، شکست در ورود، تماس برای بازنشانی گذرواژه، نرسیدن پیامک، مراجعه حضوری برای رفع مغایرت و توسعه اتصالهای تکراری میان سامانهها پنهان است.
برای بانک، فینتک یا کسبوکار دیجیتال، هر مرحله اضافی میتواند نرخ تکمیل فرایند را کاهش دهد. در مقابل، حذف بیقاعده کنترلها نیز احتمال تقلب و تصاحب حساب را بالا میبرد. چالش اصلی انتخاب میان امنیت و تجربه کاربری نیست؛ مسئله، طراحی کنترلی است که متناسب با ریسک عمل کند. ورود عادی از دستگاه شناختهشده نباید الزاماً همان مسیری را طی کند که تغییر اطلاعات حساس، بازیابی حساب یا انتقال مبلغ بالا طی میکند.
وقتی زیرساخت هویت توان تشخیص وضعیت دستگاه، سابقه نشست، الگوی رفتار و حساسیت عملیات را ندارد، ناچار است از همه کاربران مدارک و تأییدهای یکسان بخواهد. این همان نقطهای است که تجربه کاربری به آینه بلوغ معماری هویت تبدیل میشود. اصطکاک بیشتر همیشه نشانه امنیت بیشتر نیست؛ گاهی فقط نشانه آن است که سامانه نمیتواند ریسک را دقیق تشخیص دهد.
مسئله بازیابی نیز به همان اندازه مهم است. اگر مسیر بازیابی برای کاهش هزینه پشتیبانی بیش از حد آسان شود، ممکن است به ضعیفترین حلقه امنیت تبدیل شود. اگر بیش از حد سخت باشد، کاربر، مرکز تماس و عملیات سازمان همزمان هزینه میپردازند. معماری هویت باید ورود و بازیابی را یک مسئله واحد ببیند، نه دو فرایند جدا با سطوح امنیتی متفاوت.
مسئله فقط مشتری نیست؛ سازمان با شبکهای از هویتها روبهروست
هویت دیجیتال در رسانهها معمولاً از زاویه مشتری دیده میشود؛ اما بانکها و سازمانهای بزرگ با مجموعه متنوعتری از هویتها سروکار دارند: کارکنان، مدیران، پیمانکاران، شرکای تجاری، اپراتورها، حسابهای ممتاز، سرویسها، APIها، بارهای کاری و عاملهای نرمافزاری یا هوش مصنوعی. هر کدام چرخه عمر، سطح ریسک و الگوی دسترسی متفاوتی دارند.
هویت مشتری باید ساده، در دسترس و متناسب با کانال باشد؛ درحالیکه هویت سازمانی به کنترل نقش و مجوز، تفکیک وظایف، ثبت رویداد و قطع بهموقع دسترسی نیاز دارد. حسابهای ممتاز نیز به کنترلهای سختگیرانهتری مانند دسترسی حداقلی، احراز هویت مقاومتر، تایید مرحلهای و نظارت بر نشست نیازمندند. استفاده از یک الگوی ثابت برای همه این گروهها، نه از نظر امنیتی مناسب است و نه از نظر عملیاتی.
در محیط سازمانی، ورود کارمند، تغییر سمت، جابهجایی واحد یا خاتمه همکاری باید بهطور مستقیم بر دسترسیها اثر بگذارد. باقیماندن حساب افراد خارجشده، انباشت دسترسیهای قدیمی و ایجاد حسابها با فرایندهای دستی، فقط مشکل ممیزی نیست؛ فرصتی برای حرکت مهاجم با یک هویت ظاهراً معتبر ایجاد میکند.
هویتهای غیرانسانی نیز دیگر حاشیهای نیستند. سرویسها و APIها نباید برای مدت طولانی به کلیدها و اسرار ثابت تعبیهشده در کد یا فایل پیکربندی وابسته بمانند. گواهیها، کلیدهای مدیریتشده، توکنهای کوتاهعمر و هویت بار کاری باید متناسب با تعامل ماشینی طراحی شوند. پرسش آینده فقط این نیست که «چه کسی وارد شده است؟»؛ بلکه باید پرسید «چه موجودیتی، از کدام مبدأ و با چه اختیاری در حال عمل است؟»
جزیرههای هویتی چگونه رشد بازار را کند میکنند؟
هر بانک، شرکت پرداخت، فینتک و پلتفرم بزرگ معمولاً مسیر مستقلی برای ثبتنام، اثبات هویت، ورود، مدیریت دسترسی و بازیابی حساب ساخته است. بخشی از این استقلال به تفاوت مدل کسبوکار و سطح ریسک بازمیگردد؛ اما نبود زبان مشترک، بسیاری از این سامانهها را به جزیرههایی تبدیل کرده که اتصال آنها دشوار و پرهزینه است.
برای کاربر، نتیجه این پراکندگی تکرار مداوم اطلاعات و عبور از فرایندهای ناسازگار است. برای سازمان، نتیجه نگهداری چندین مخزن هویت، توسعه اتصالهای اختصاصی، اجرای سیاستهای متفاوت و ناتوانی در ایجاد دید یکپارچه است. هر اتصال سفارشی نیز هزینه توسعه و نگهداری دارد و در صورت طراحی نادرست، سطح حمله تازهای ایجاد میکند.
تعاملپذیری به معنای ایجاد یک پایگاه متمرکز برای تمام دادههای هویتی یا حذف استقلال سازمانها نیست. هدف این است که بازیگران اکوسیستم بتوانند با قراردادهای مشخص، درباره هویت، اعتبارنامه، سطح اطمینان و مجوز تبادل اطلاعات کنند. هر سازمان همچنان مسئول سیاست و داده خود باقی میماند، اما برای هر خدمت تازه مجبور نیست مسئله هویت را از ابتدا حل کند.
همین منطق در داخل سازمان نیز صادق است. منابع انسانی، دایرکتوریها، سامانههای کسبوکار، خدمات ابری و ابزارهای امنیتی باید تغییر وضعیت یک هویت را بهموقع دریافت و اعمال کنند. اگر هر سامانه چرخه عمر جداگانهای داشته باشد، تصویر واقعی دسترسیها همیشه از تغییرات سازمانی عقب میماند.
استانداردها چگونه زبان مشترک هویت را میسازند؟
بدون استانداردهای باز، بازار هویت دیجیتال به مجموعهای از راهکارهای بسته و وابستگیهای بلندمدت تبدیل میشود. استانداردها مشخص میکنند سامانهها چگونه ورود یکپارچه ایجاد کنند، مجوز دسترسی بگیرند، اطلاعات هویتی را منتقل کنند، حسابها را همگام سازند و از اعتبارنامههای رمزنگاریشده استفاده کنند.
OAuth 2.0 چارچوب واگذاری مجوز است و OpenID Connect لایه هویتی و احراز هویت را بر آن بنا میکند. SAML همچنان در بسیاری از ارتباطات سازمانی به کار میرود و SCIM ایجاد، بهروزرسانی و حذف حسابها را استاندارد میکند. در لایه احراز هویت نیز FIDO2 که WebAuthn و CTAP را در کنار هم قرار میدهد، امکان استفاده از اعتبارنامههای کلید عمومی و احرازگرهای سازگار را فراهم میسازد.
ارزش این استانداردها فقط در سازگاری فنی نیست. زبان مشترک، حق انتخاب سازمان را افزایش میدهد، مهاجرت مرحلهای را ممکن میکند و وابستگی به یک محصول یا تأمینکننده را کاهش میدهد. همچنین نقش اجزا را روشنتر میکند: یک استاندارد برای ورود و تبادل هویت، استانداردی دیگر برای مدیریت چرخه عمر و استانداردی برای احراز هویت مقاومتر.
البته درج نام یک استاندارد در فهرست قابلیتهای محصول، تضمینکننده معماری درست نیست. کیفیت پیادهسازی، حفاظت از کلیدها، اعتبارسنجی توکنها، مدیریت نشست، بازیابی، ثبت رویداد و تنظیم صحیح سیاستها همچنان تعیینکنندهاند. استاندارد زبان مشترک را فراهم میکند؛ اما اعتماد، محصول طراحی و بهرهبرداری صحیح از کل زنجیره است.
احراز هویت مقاوم در برابر فیشینگ چه چیزی را تغییر میدهد؟
گذرواژه، کد پیامکی و بسیاری از رمزهای یکبارمصرف میتوانند در یک صفحه جعلی دریافت و همان لحظه برای ورود به سرویس واقعی استفاده شوند. افزودن عامل دوم، اگر هر دو عامل قابل انتقال باشند، ریسک را کاهش میدهد؛ اما الزاماً مقاومت ذاتی در برابر فیشینگ ایجاد نمیکند.
در احراز هویت مبتنی بر FIDO، سرویس بهجای نگهداری یک راز مشترک، کلید عمومی کاربر را ثبت میکند. کلید خصوصی در احراز گر یا محیط محافظتشده باقی میماند و برای پاسخ به یک چالش اختصاصی به کار میرود. اعتبارنامه به مبدأ واقعی سرویس وابسته است؛ بنابراین یک دامنه جعلی نمیتواند پاسخ قابلاستفادهای برای دامنه اصلی دریافت کند.
کاربر استفاده از اعتبارنامه را با تعاملی محلی مانند لمس احراز گر، وارد کردن PIN یا تأیید زیستسنجی مجاز میکند. در این مدل، داده خام اثر انگشت یا چهره برای سرویس ارسال نمیشود؛ سرویس نتیجه موفقیت بررسی محلی و پاسخ رمزنگاریشده را دریافت میکند. این همان نکتهای است که روشهای FIDO و گذر کلیدها را همزمان برای امنیت و تجربه کاربری مهم میکند.
گذر کلید همگامشونده، اعتبارنامه متصل به دستگاه و کلید امنیتی سختافزاری، همگی میتوانند بر الگوی کلید عمومی عمل کنند؛ اما سطح حفاظت، روش بازیابی و مدل مالکیت آنها یکسان نیست. برای مشتری عمومی، دسترسپذیری و بازیابی ساده اهمیت بیشتری دارد؛ برای حساب ممتاز یا دسترسی مدیریتی، ممکن است اعتبارنامه متصل به سختافزار و سیاستهای سختگیرانهتر مناسبتر باشد.
بااینحال، FIDO جایگزین تمام معماری هویت نیست. اگر ثبت اولیه هویت اشتباه باشد، اگر بازیابی حساب ضعیف طراحی شود، اگر نشست پس از ورود محافظت نشود یا اگر مجوزها بیش از نیاز باشند، احراز هویت مقاوم در برابر فیشینگ نیز بهتنهایی کافی نیست. FIDO لایه ورود را تقویت میکند؛ امنیت پایدار زمانی شکل میگیرد که این لایه با چرخه عمر، کنترل دسترسی و حسابرسی همراه شود.
گذار از کجا باید آغاز شود؟
اصلاح معماری هویت به معنای حذف یکشبه روشهای موجود نیست. سامانههای قدیمی، محدودیتهای یکپارچهسازی، تنوع کاربران و الزامات تداوم خدمت، مهاجرت مرحلهای را ضروری میکنند. اما مرحلهایبودن نباید به ادامه نامحدود راهحلهای موقت تبدیل شود؛ سازمان باید تصویر مقصد و برنامه روشن کاهش وابستگی به کنترلهای پرریسک را داشته باشد.
نقطه شروع بهتر است بر اساس ریسک انتخاب شود: حسابهای ممتاز، دسترسیهای مدیریتی، ورود از راه دور، پنلهای حساس، عملیات مالی مهم، تغییر اطلاعات حساب و مسیرهای بازیابی معمولاً در اولویت قرار میگیرند. در این نقاط، احراز هویت مقاومتر، تأیید مجدد عملیات، دسترسی حداقلی و ثبت دقیق رویدادها سریعتر بازده امنیتی ایجاد میکنند.
همزمان، سازمان باید منابع هویت و چرخه عمر آنها را بشناسد: هویت از کجا ایجاد میشود؟ کدام سامانه مرجع هر ویژگی است؟ دسترسی بر چه اساسی تخصیص مییابد؟ چه رویدادی آن را تغییر میدهد و چه زمانی باید لغو شود؟ بدون پاسخ به این پرسشها، جایگزینی روش ورود فقط یک جزیره را نوسازی میکند و مسئله پراکندگی باقی میماند.
معیار موفقیت نیز نباید صرفاً تعداد کاربران مهاجرتکرده باشد. کاهش تصاحب حساب، کاهش بازنشانی گذرواژه، بهبود نرخ تکمیل ثبتنام، زمان قطع دسترسی، پوشش حسابهای پرریسک، نرخ استفاده از روشهای مقاوم در برابر فیشینگ و کیفیت تجربه بازیابی، تصویر دقیقتری از نتیجه میدهند.
هویت باید به زیرساخت کسبوکار تبدیل شود
هویت دیجیتال را نمیتوان به کد ملی، شماره همراه، تصویر مدرک یا یک مرحله ورود تقلیل داد. این مفهوم زنجیرهای است که از اثبات هویت آغاز میشود و تا اعتبارنامه، احراز هویت، مجوزدهی، چرخه عمر، بازیابی و حسابرسی ادامه پیدا میکند. ضعف در هر حلقه میتواند امنیت، تجربه مشتری و توان رشد خدمت را تحت تاثیر قرار دهد.
مدل رایج متکی بر دادههای عمومی، گذرواژه و کدهای قابلانتقال، در دوره گذار همچنان باقی خواهد ماند؛ اما نباید نقطه اتکای آینده باشد. گسترش خدمات غیرحضوری، افزایش تهدیدهای فیشینگ و رشد هویتهای انسانی و ماشینی، به کنترلهایی نیاز دارد که متناسب با ریسک، تعاملپذیر و قابل مدیریت در مقیاس بالا باشند.
استانداردهای باز و احراز هویت مبتنی بر کلید عمومی، امکان ساخت لایهای مقاومتر را فراهم میکنند؛ اما تحول واقعی زمانی رخ میدهد که این ابزارها درون معماری کامل هویت قرار گیرند. سازمانی که هویت را فقط یک صفحه ورود میبیند، هر بار برای خدمت جدید بخشی از مسئله را دوباره حل میکند. سازمانی که آن را زیرساخت کسبوکار میداند، میتواند اعتماد را یکبار بسازد و در کانالها و خدمات مختلف با سیاستهای روشن گسترش دهد.
اقتصاد دیجیتال بدون چنین زیرساختی ممکن است بزرگ شود، اما قابل اتکا و مقیاسپذیر نمیشود. مزیت سازمانهایی که زودتر معماری هویت خود را منسجم میکنند، فقط ریسک کمتر نیست؛ آنها میتوانند خدمات را سریعتر، با اصطکاک کمتر و هزینه عملیاتی پایینتر عرضه کنند. در این نقطه، هویت دیجیتال دیگر یک پروژه امنیتی نیست؛ بخشی از مدل رشد کسبوکار است.
