در صرافی‌های رمزارز، سرقت حساب فقط از صفحه ورود آغاز نمی‌شود؛ Session Hijacking، سوءاستفاده از نشست معتبر و برداشت‌های پرریسک نشان می‌دهند که اعتماد باید از لحظه ورود تا انجام تراکنش‌های حساس به‌صورت مداوم بازسنجی شود. صرافی‌های رمزارز برای مقابله با Account Takeover نمی‌توانند امنیت را به رمز عبور، MFA یا حتی Passkey محدود کنند. معماری دفاعی مؤثر باید پس از ورود نیز با پایش Session، ارزیابی ریسک، Step-up Authentication و کنترل مستقل برداشت ادامه پیدا کند تا یک نشست معتبر به‌تنهایی مجوز انتقال دارایی نباشد.
به گزارش روابط عمومی شرکت ره‌آورد سامانه‌های امن (ره‌سا)، بخش مهمی از کنترل‌های امنیتی همچنان در نقطه Authentication متمرکز است: کاربر چگونه وارد می‌شود، چه عاملی برای احراز هویت دارد و آیا روش ورود در برابر فیشینگ مقاوم است یا نه. درباره محدودیت‌های مدل‌های مبتنی بر رمز عبور و حرکت به سمت FIDO و Passkey پیش‌تر صحبت کرده‌ایم. اما حتی اگر این لایه به‌درستی طراحی شده باشد، یک سؤال مهم همچنان باقی می‌ماند: بعد از ورود موفق چه اتفاقی می‌افتد؟
از لحظه‌ای که Session کاربر ایجاد می‌شود، سطح دیگری از ریسک آغاز می‌شود. سرقت Session، سوءاستفاده از یک نشست معتبر، تغییر ناگهانی تنظیمات امنیتی، افزودن آدرس برداشت جدید یا انجام یک Withdrawal غیرمعمول می‌توانند بدون شکست مستقیم مکانیزم Login رخ دهند. در چنین شرایطی، مسئله دیگر فقط «اثبات هویت در لحظه ورود» نیست؛ بلکه «تداوم اعتماد به همان هویت در طول Session و در زمان انجام عملیات حساس» است.
بخوانید: مسیر بانک‌ها به سوی Zero Trust
این همان نقطه‌ای است که Account Takeover از یک مسئله ساده Authentication به یک مسئله معماری Identity Security تبدیل می‌شود.
Account Takeover فقط قبل از Login اتفاق نمی‌افتد
برای تحلیل دقیق‌تر، می‌توان Account Takeover را در سه نقطه از چرخه هویت و دسترسی بررسی کرد.
نقطه اول، پیش از Authentication است؛ جایی که Credential Phishing، OTP Relay، SIM Swap، Credential Stuffing یا Social Engineering تلاش می‌کنند مهاجم را به جای کاربر واقعی وارد حساب کنند. درباره ضعف Password و OTP و تفاوت آن با روش‌های Phishing-resistant پیش‌تر صحبت کرده‌ایم و اینجا وارد جزئیات آن نمی‌شویم.
اما نقطه دوم، بعد از Authentication است؛ یعنی زمانی که کاربر قانونی قبلاً احراز هویت شده و یک Session معتبر ایجاد شده است. اگر Session Cookie، Refresh Token یا سایر Session Secretها سرقت شوند، مهاجم ممکن است بدون نیاز به تکرار مرحله ورود، خود را داخل یک نشست معتبر قرار دهد. NIST صراحتاً تأکید می‌کند که امنیت Session Management به اندازه Authentication اهمیت دارد، زیرا Session Hijacking می‌تواند به اندازه شکست احراز هویت مخرب باشد.
نقطه سوم حتی پیچیده‌تر است: سوءاستفاده از یک Session واقعاً معتبر. ممکن است مهاجم با بدافزار، Remote Access، Browser Injection یا مهندسی اجتماعی بتواند در همان محیطی که کاربر واقعی حضور دارد عملیات انجام دهد. در این حالت نه لزوماً Password سرقت شده، نه الزاماً MFA شکسته شده و نه حتی Session Token باید از دستگاه خارج شده باشد. مسئله این است که یک Session معتبر، رفتاری نامعتبر نشان می‌دهد.
Passkey لایه Authentication را تقویت می‌کند، نه کل Session را
FIDO و Passkey می‌توانند حملات مبتنی بر فیشینگ و سرقت Credential را به‌طور معناداری محدود کنند؛ موضوعی که در یادداشت «احراز هویت بدون رمز عبور؛ FIDO و Passkey در بانکداری» به تفصیل بررسی کرده‌ایم. اما این مزیت نباید با امنیت کامل Session اشتباه گرفته شود.
پس از Authentication، بسیاری از سرویس‌ها برای حفظ وضعیت ورود از Session Secret استفاده می‌کنند. در وب، این Secret معمولاً در قالب Session Cookie یا Token نگهداری می‌شود. اگر معماری به‌گونه‌ای باشد که صرف در اختیار داشتن این Token برای ادامه نشست کافی باشد، مهاجم با سرقت آن می‌تواند بخشی از ارزش Authentication قوی را دور بزند.
به همین دلیل، یکی از روندهای مهم امنیت هویت حرکت از Bearer Session به سمت Session هایی است که تا حد ممکن به دستگاه یا یک کلید رمزنگاری متصل باشند. هدف Device-bound Session این است که سرقت یک Token به‌تنهایی برای بازسازی Session روی دستگاه دیگر کافی نباشد. NIST نیز در راهنمای جدید خود به Device Bound Session Credentials به‌عنوان یکی از فناوری‌های قابل استفاده برای کاهش ریسک سرقت Session اشاره می‌کند.
Continuous Trust؛ اعتماد نباید در لحظه Login ثابت بماند
اگر صرافی تنها در لحظه ورود تصمیم بگیرد که کاربر قابل اعتماد است، عملاً یک تصمیم امنیتی چندثانیه‌ای را برای کل عمر Session معتبر فرض کرده است. در حالی که سطح ریسک می‌تواند چند دقیقه بعد کاملاً تغییر کند.
برای مثال، کاربری ممکن است با Passkey و از دستگاه همیشگی خود وارد حساب شود. چند دقیقه بعد، همان Session شروع به ثبت رفتارهایی کند که با الگوی معمول کاربر سازگار نیست: تغییر تنظیمات امنیتی، افزودن آدرس برداشت جدید، افزایش ناگهانی مبلغ تراکنش، دسترسی از IP غیر معمول، تغییر مشخصات مرورگر یا درخواست چند عملیات حساس پشت سر هم.
در چنین شرایطی، معماری باید بتواند Trust را دوباره محاسبه کند. NIST در بحث Session Monitoring به سیگنال‌هایی مانند Usage Pattern، زمان‌بندی فعالیت، ویژگی‌های Device و Browser، Geolocation و مشخصات IP اشاره می‌کند. این نگاه به‌جای اعتماد ایستا، به سمت Continuous یا Context-aware Trust حرکت می‌کند.
یعنی سؤال دیگر فقط این نیست که «آیا کاربر با موفقیت Login کرده است؟»؛ سؤال این است که «آیا این Session هنوز رفتاری متناسب با همان هویت مورد انتظار دارد؟»
Login Trust با Withdrawal Trust یکسان نیست
در صرافی، حساسیت عملیات مختلف به‌شدت متفاوت است. مشاهده موجودی، دریافت تاریخچه تراکنش، افزودن یک Wallet Address جدید، تغییر MFA، تغییر اطلاعات بازیابی و برداشت دارایی نباید تحت یک سطح Trust قرار بگیرند. به همین دلیل، Login موفق نباید مجوز ضمنی برای Withdrawal باشد. فرض کنیم کاربر با یک روش Phishing-resistant وارد حساب شده است. اگر همان Session بخواهد از یک دستگاه جدید آدرس برداشت ثبت کند و بلافاصله حجم بالایی دارایی منتقل کند، سیستم باید این تغییر را به‌عنوان یک Risk Transition ببیند. نتیجه Policy می‌تواند یکی از چند حالت باشد: اجازه عملیات، درخواست Step-up Authentication، اعمال Delay، نیاز به تأیید خارج از Session، توقف موقت برداشت یا ارجاع به بررسی دستی.
این همان نقطه‌ای است که Transaction-aware Access Control اهمیت پیدا می‌کند. در این مدل، Authentication فقط «چه کسی هستی؟» را پاسخ می‌دهد؛ اما تصمیم نهایی باید «در این لحظه، با این سطح ریسک، مجاز به انجام دقیقاً چه عملیاتی هستی؟» را نیز پاسخ دهد.
FIDO Alliance نیز در حوزه پرداخت و تراکنش‌های حساس بر استفاده از Credential های مقاوم در برابر فیشینگ برای Transaction Authentication تأکید دارد و در اسناد مرتبط با اکوسیستم رمزارز به استفاده از FIDO برای حفاظت اضافه از معاملات و تراکنش‌های حساس اشاره کرده است.
معماری دفاعی چند لایه برای صرافی
اگر بخواهیم این منطق را به یک معماری عملیاتی تبدیل کنیم، دفاع هویتی در صرافی را نباید مجموعه‌ای از کنترل‌های مستقل دید. این کنترل‌ها زمانی مؤثرند که به‌صورت زنجیره‌ای عمل کنند و هر مرحله بتواند سطح اعتماد ساخته‌شده در مرحله قبل را دوباره ارزیابی کند.
نقطه شروع، Authentication مقاوم در برابر فیشینگ است؛ یعنی تا جای ممکن احتمال اینکه مهاجم بتواند در همان لحظه ورود خود را به‌جای کاربر واقعی جا بزند کاهش پیدا کند. اما موفقیت این مرحله فقط به این معناست که هویت در ابتدای Session با سطح قابل‌قبولی اثبات شده است؛ نه اینکه کل نشست و همه عملیات بعدی نیز به همان اندازه قابل اعتماد باقی بمانند.
به همین دلیل، بلافاصله پس از ایجاد Session باید لایه حفاظت از نشست وارد عمل شود. کنترل عمر Session، Re-authentication در شرایط مشخص، Session Binding و در صورت امکان اتصال نشست به Device یا یک Key مشخص، کمک می‌کنند سرقت یک Token یا Cookie به‌تنهایی برای ادامه Session روی محیط دیگری کافی نباشد. این لایه عملاً فاصله میان «احراز هویت موفق» و «حفظ مالکیت Session» را پوشش می‌دهد.
اما حتی Session محافظت‌شده نیز باید در طول زمان تحت ارزیابی باقی بماند. Session Monitoring و Risk Evaluation با بررسی Context، Device، رفتار، IP، Velocity و سایر سیگنال‌های ریسک تلاش می‌کنند تشخیص دهند آیا الگوی فعلی همچنان با رفتار مورد انتظار همان هویت سازگار است یا نه. اگر سطح ریسک افزایش پیدا کند، سیستم نباید الزاماً Session را بدون قید و شرط معتبر فرض کند؛ بلکه می‌تواند کنترل بعدی را فعال کند.
در این نقطه Step-up Authentication معنا پیدا می‌کند. هدف Step-up این نیست که کاربر برای هر عملیات دوباره احراز هویت شود، بلکه زمانی فعال می‌شود که حساسیت عملیات یا ریسک Session نسبت به لحظه Login افزایش یافته باشد. به‌عنوان مثال، افزودن یک آدرس برداشت جدید، تغییر تنظیمات امنیتی یا درخواست برداشت با مبلغ بالا می‌تواند نیازمند سطح بالاتری از Assurance باشد.
در نهایت، خود Transaction یا Withdrawal باید به‌عنوان یک تصمیم امنیتی مستقل ارزیابی شود. یعنی سیستم نباید صرفاً به این دلیل که Login و Session معتبرند، انتقال دارایی را نیز مجاز بداند. در این مرحله، هویت، وضعیت Session، سطح ریسک، نوع عملیات، مبلغ، مقصد و سیاست‌های صرافی باید کنار هم قرار گیرند تا تصمیم نهایی گرفته شود؛ تصمیمی که می‌تواند اجازه، Step-up، Delay، محدودسازی، بررسی دستی یا مسدودسازی باشد.
در چنین معماری‌ای، Account Takeover دیگر فقط یک Event برای ثبت در SIEM نیست؛ بلکه یک زنجیره تصمیم‌گیری هویتی است که باید در چند نقطه امکان قطع، محدودسازی یا تشدید کنترل داشته باشد. ارزش واقعی معماری چند لایه نیز دقیقاً در همین پیوستگی است: شکست یا دورزدن یک کنترل نباید به معنای سقوط کل زنجیره اعتماد باشد.
صرافی‌های بزرگ چه کرده‌اند؟ از Passkey تا قفل برداشت
این الگوی چند لایه فقط یک مدل نظری نیست. بررسی کنترل‌های امنیتی صرافی‌های بزرگ نشان می‌دهد که بسیاری از آنها نیز امنیت حساب را به یک مرحله ورود محدود نکرده‌اند و برای تغییرات حساس، Session، آدرس برداشت و خود Withdrawal کنترل‌های جداگانه در نظر گرفته‌اند.
Binance در راهنمای امنیت حساب ۲۰۲۶ خود Passkey و بیومتریک را برای تقویت ورود توصیه می‌کند، اما مهم‌تر از آن توضیح می‌دهد که در صورت بالا بودن Risk Signal ها می‌تواند برداشت را به‌طور موقت متوقف کند و تنها پس از انجام بررسی‌های امنیتی و تأیید صاحب حساب آن را دوباره فعال کند. این دقیقاً نمونه‌ای از جدا کردن Login Trust از Withdrawal Trust است: حتی اگر کاربر وارد حساب شده باشد، رفتار پرریسک می‌تواند یک Hard Stop در لایه انتقال دارایی ایجاد کند.
Coinbase این تفکیک را صریح‌تر کرده است. علاوه بر توصیه Passkey یا Security Key برای احراز هویت، قابلیت Allowlisting اجازه می‌دهد برداشت فقط به آدرس‌های از پیش تأییدشده انجام شود و اضافه‌کردن آدرس جدید با دوره انتظار همراه است. در Transfer Protection نیز کاربر می‌تواند برای انتقال‌های خروجی Delay بین ۶ تا ۴۸ ساعت، آستانه روزانه و Verification جداگانه تعریف کند. Coinbase برای Account Protection نیز در برخی مناطق و برای کاربران واجد شرایط، استفاده از Passkey یا Security Key را شرط قرار داده است. مجموعه این کنترل‌ها نشان می‌دهد که Authentication، مقصد برداشت و خود Transaction سه حوزه امنیتی مستقل در نظر گرفته شده‌اند.
Kraken نیز مدل قابل‌توجهی دارد. Passkey را برای Sign-in 2FA توصیه می‌کند و برای تغییرات حساس از Step-up 2FA استفاده می‌کند. در کنار آن، Global Settings Lock یا GSL می‌تواند تغییرات مهم حساب، از جمله افزودن آدرس برداشت جدید یا تغییر تنظیمات 2FA را قفل کند. کاربر برای بازکردن این قفل می‌تواند یک دوره انتظار از ۱ تا ۳۰ روز تعیین کند. Kraken صراحتاً GSL را «آخرین خط دفاع» در شرایطی معرفی می‌کند که Password و Sign-in 2FA نیز در اختیار مهاجم قرار گرفته باشند. این طراحی نمونه خوبی از این اصل است که Compromise در Login نباید به‌طور خودکار امکان تغییر سیاست‌های امنیتی یا مسیر برداشت را فراهم کند.
Gemini نیز 2FA را برای دسترسی به حساب و برداشت به‌صورت پیش‌فرض الزامی اعلام می‌کند، از Hardware Security Key پشتیبانی دارد و Address Allowlisting را برای محدود کردن برداشت به آدرس‌های از پیش تعیین‌شده ارائه می‌دهد. در اینجا نیز کنترل هویت در نقطه ورود با کنترل مقصد و عملیات برداشت ترکیب شده است.
وجه مشترک این نمونه‌ها مهم‌تر از تفاوت جزئی پیاده‌سازی آنهاست: صرافی‌های بزرگ فرض نمی‌کنند که «Login موفق» برای ادامه همه عملیات کافی است. Passkey یا Security Key برای تقویت Authentication، Step-up برای تغییرات حساس، Session و Device Monitoring، Allowlisting برای مقصد برداشت و Delay یا Withdrawal Lock برای آخرین مرحله انتقال دارایی، لایه‌هایی هستند که روی یکدیگر قرار می‌گیرند. همین الگوی عملی تأیید می‌کند که معماری دفاع در برابر Account Takeover باید از یک کنترل واحد عبور کند و Trust را در طول چرخه دسترسی و تراکنش دوباره ارزیابی کند.
کلید امنیتی سخت‌افزاری FIDO کجا ارزش بیشتری پیدا می‌کند؟
برای بخش بزرگی از کاربران عمومی صرافی، Passkey روی تلفن همراه یا دستگاه شخصی می‌تواند سطح مناسبی از امنیت و تجربه کاربری ایجاد کند. اما برای همه نقش‌ها و همه عملیات، سطح Assurance یکسان نیست.
مدیر Treasury، اپراتور Hot Wallet، مدیر امنیت، حساب سازمانی با سقف برداشت بالا یا کاربری که عملیات پرارزش انجام می‌دهد، می‌تواند به سطح کنترل متفاوتی نیاز داشته باشد. در چنین سناریوهایی، Hardware-bound Credential اهمیت بیشتری پیدا می‌کند؛ Credentialی که کلید خصوصی آن روی یک سخت‌افزار مشخص باقی بماند و استفاده از آن نیز با PIN یا بیومتریک محلی محافظت شود.
در اینجا ارزش FIDO Security Key یا توکن FIDO2 بایومتریک فقط «داشتن عامل دوم» نیست. مسئله، داشتن یک Cryptographic Authenticator مستقل و سخت‌افزارمحور برای عملیات یا هویت‌هایی است که سطح اطمینان بالاتری می‌خواهند.
این تفکیک مهم است: برای کاربر عمومی ممکن است Passkey نرم‌افزاری بهترین تعادل را ایجاد کند، اما برای Privileged User یا عملیات حساس، سازمان می‌تواند سیاست متفاوتی اعمال کند.
نشانه؛ از Login Platform به Identity Policy Layer
در چنین معماری‌ای، نقش IAM نیز از مدیریت حساب و SSO فراتر می‌رود. صرافی به یک لایه هویتی نیاز دارد که بتواند اطلاعات Identity، Authentication Method، Context، Risk و حساسیت عملیات را به Policy متصل کند.
این یعنی پلتفرم هویت باید بتواند بر اساس Policy تصمیم بگیرد چه زمانی Authentication فعلی کافی است، چه زمانی Step-up لازم است، چه زمانی Session باید Revoke شود و چه رویدادهایی باید برای تحلیل امنیتی ثبت شوند. برای کارکنان و Privileged Account ها نیز همین منطق باید با سطح سخت‌گیری بالاتر اعمال شود.
پلتفرم نشانه نیز با همین جهت‌گیری قابل استفاده است؛ نه صرفاً به‌عنوان یک Login یا MFA Server، بلکه به‌عنوان لایه‌ای برای اتصال Identity، Authentication و Policy. در سناریوهای صرافی، این معماری می‌تواند در کنار FIDO، Adaptive MFA، سیاست‌های Context-aware و کلیدهای امنیتی سخت‌افزاری برای کاربران یا عملیات پرریسک قرار گیرد.
این نگاه ادامه همان منطق Zero Trust است که در مقاله قبلی مطرح کردیم: Trust نباید صرفاً با یک Login ساخته و تا پایان Session ثابت فرض شود؛ باید با تغییر Context و حساسیت عملیات، دوباره ارزیابی شود.
مسئله اصلی، تداوم اعتماد است
در Account Takeover مدرن، مهاجم همیشه Password را نمی‌شکند و همیشه از صفحه Login عبور نمی‌کند. گاهی Authentication کاملاً صحیح انجام شده اما Session بعداً سرقت شده است؛ گاهی Session هم سرقت نشده و مهاجم از همان نشست معتبر برای انجام عملیات سوءاستفاده می‌کند.
به همین دلیل، دفاع هویتی در صرافی باید سه سؤال جداگانه را پاسخ دهد: چه کسی وارد شده است؟ آیا Session هنوز متعلق به همان هویت و همان Context مورد انتظار است؟ و آیا این هویت، در همین لحظه، مجاز به انجام این برداشت مشخص است؟
هرچه معماری بتواند این سه تصمیم را از هم تفکیک کند و Trust را از یک وضعیت ثابت به یک متغیر پویا تبدیل کند، Account Takeover سخت‌تر می‌شود. در صرافی رمزارز، جایی که یک تصمیم اشتباه می‌تواند مستقیماً به انتقال دارایی منجر شود، این تفاوت صرفاً یک بهبود فنی نیست؛ بخشی از معماری پایه اعتماد است.
