چک‌لیست کامل امنیت صرافی ارز دیجیتال قبل از راه‌اندازی

چک‌لیست کامل امنیت صرافی ارز دیجیتال قبل از راه‌اندازی

یک صرافی ارز دیجیتال قبل از اینکه با اولین کاربر، اولین سفارش و اولین برداشت واقعی روبه‌رو شود، باید از چندین زاویه امنیتی بررسی شده باشد. مشکل اینجاست که «امن بودن سایت» با «آماده بودن یک صرافی برای Launch» یکسان نیست.

در یک پلتفرم معاملاتی، امنیت فقط به HTTPS، فایروال یا فعال‌کردن ورود دومرحله‌ای محدود نمی‌شود. API، کنترل دسترسی، Session، کیف پول، کلیدهای خصوصی، فرآیند برداشت، Matching Engine، پنل ادمین، زیرساخت، Secrets، لاگ‌ها، وابستگی‌های نرم‌افزاری و حتی فرآیندهای عملیاتی کارکنان می‌توانند بخشی از سطح حمله باشند.

این موضوع در اکوسیستم کریپتو اهمیت بیشتری دارد؛ گزارش TRM Labs درباره سال ۲۰۲۵ نشان می‌دهد حدود ۲.۸۷ میلیارد دلار در نزدیک به ۱۵۰ هک از دست رفته و بخش عمده خسارت‌ها به سمت حمله به زیرساخت، کلیدها، کیف پول‌ها و لایه‌های دسترسی رفته است.

بنابراین سؤال درست قبل از Launch این نیست که:

«آیا سایت ما تست شده است؟»

بلکه باید پرسید:

«آیا تمام مسیرهای ورود، دسترسی، معامله، نگهداری دارایی، برداشت، مدیریت و بازیابی سیستم در شرایط عادی و بحرانی آزمایش شده‌اند؟»

این راهنما یک چک‌لیست عملی برای پاسخ به همین سؤال است.

چرا امنیت صرافی ارز دیجیتال باید قبل از راه‌اندازی بررسی شود؟

رفع یک آسیب‌پذیری قبل از ورود پول و کاربر واقعی، معمولاً بسیار کم‌هزینه‌تر از مدیریت حادثه‌ای است که پس از Launch رخ می‌دهد.

بعد از راه‌اندازی، یک ضعف امنیتی می‌تواند به موارد زیر منجر شود:

• دسترسی غیرمجاز به حساب کاربران

• سرقت یا انتقال دارایی

• دستکاری سفارش‌ها

• سوءاستفاده از API

• دسترسی به اطلاعات KYC

• افشای کلیدها یا Secrets

• دسترسی به پنل مدیریت

• ایجاد برداشت‌های غیرمجاز

• دستکاری موجودی یا وضعیت تراکنش

• اختلال در Matching Engine

• توقف سرویس

• از دست رفتن داده

• آسیب اعتباری و مالی

• هزینه‌های incident response و recovery

• پیامدهای قراردادی یا قانونی، بسته به حوزه فعالیت و jurisdiction

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

در صرافی، این نگاه اهمیت ویژه‌ای دارد: امنیت باید بخشی از معماری و فرآیند کسب‌وکار باشد، نه مرحله‌ای که چند روز قبل از Launch به تیم فنی واگذار شود.

چک‌لیست امنیت صرافی ارز دیجیتال قبل از Launch

1. معماری و زیرساخت

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

چه خطری وجود دارد؟

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

• سرویس‌های غیرضروری در معرض اینترنت

• دسترسی مستقیم به Database

• مدیریت ضعیف Firewall

• نبود Network Segmentation

• استفاده از حساب‌های دارای دسترسی بیش از نیاز

• محیط Production مشترک با Development

• تنظیمات ناامن Cloud

• نبود کنترل مناسب روی Third-Party Services

چه چیزی باید بررسی شود؟

• Asset Inventory کامل باشد.

• تمام Serverها، Containerها، Databaseها و سرویس‌ها شناسایی شده باشند.

• محیط Development، Staging و Production از هم جدا باشند.

• دسترسی‌های شبکه حداقلی باشند.

• Management Interfaceها عمومی نباشند.

• SSH و سایر مسیرهای مدیریتی محدود شده باشند.

• IAM بر اساس Least Privilege تنظیم شده باشد.

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

• TLS به‌درستی پیکربندی شده باشد.

• Firewall و Security Groupها بازبینی شده باشند.

• نقاط Single Point of Failure شناسایی شده باشند.

CIS Controls یک مجموعه کنترل اولویت‌بندی‌شده و عملی برای دفاع در برابر حملات رایج ارائه می‌کند و نسخه 8.1 آن با محیط‌های Cloud و Hybrid نیز هم‌راستا شده است.

چگونه تست کنیم؟

• Configuration Review

• Infrastructure Vulnerability Assessment

• Cloud Security Review

• Network Segmentation Test

• بررسی IAM

• بررسی External Attack Surface

نشانه آماده نبودن

اگر تیم دقیقاً نمی‌داند چه سرویس‌هایی از اینترنت قابل دسترسی هستند، Launch هنوز زود است.

اقدام اصلاحی

یک Asset Inventory و Attack Surface Inventory ایجاد کنید و تمام دسترسی‌ها را بر اساس اصل Least Privilege بازطراحی کنید.

2. معماری نرم‌افزار و Backend

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

ریسک

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

بررسی کنید

• Serviceها مرز مشخص داشته باشند.

• عملیات حساس در Backend اعتبارسنجی شوند.

• هیچ تصمیم امنیتی صرفاً به Frontend واگذار نشود.

• Business Logic در Server enforce شود.

• وضعیت تراکنش‌ها State Machine مشخص داشته باشد.

• عملیات مالی Idempotency مناسب داشته باشند.

• کنترل دسترسی در سطح Object و Function انجام شود.

• Error Handling اطلاعات حساس را افشا نکند.

OWASP ASVS 5.0 می‌تواند به‌عنوان چارچوب Verification برای بررسی الزامات امنیتی برنامه مورد استفاده قرار گیرد.

3. امنیت API

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

OWASP API Security Top 10 2023 مواردی مانند Broken Object Level Authorization، Broken Authentication، Broken Function Level Authorization، Unrestricted Resource Consumption، SSRF، Security Misconfiguration و Improper Inventory Management را در میان ریسک‌های اصلی API قرار می‌دهد.

چک‌لیست API

• ☐ تمام Endpointها Inventory شده‌اند.

• ☐ APIهای قدیمی و Debug Endpointها حذف یا محدود شده‌اند.

• ☐ Authentication برای تمام APIهای حساس بررسی شده است.

• ☐ Authorization در Backend enforce می‌شود.

• ☐ کاربر نمی‌تواند ID متعلق به کاربر دیگر را دستکاری کند.

• ☐ Object-level Authorization تست شده است.

• ☐ Function-level Authorization تست شده است.

• ☐ API Keyها دارای Scope هستند.

• ☐ API Keyهای بدون استفاده Revoked شده‌اند.

• ☐ Secretها داخل Source Code نیستند.

• ☐ Rate Limiting فعال است.

• ☐ محدودیت مصرف منابع وجود دارد.

• ☐ Validation ورودی‌ها انجام می‌شود.

• ☐ Error Responseها اطلاعات داخلی را افشا نمی‌کنند.

• ☐ API Versioning مشخص است.

• ☐ APIهای Third-Party نیز بررسی شده‌اند.

چگونه تست کنیم؟

برای API باید علاوه بر اسکن خودکار، Manual Security Testing انجام شود؛ به‌خصوص روی:

• Authorization

• Authentication

• Business Logic

• Rate Limit

• Resource Consumption

• Sensitive Data Exposure

نشانه خطرناک

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

4. احراز هویت، 2FA/MFA و مدیریت Session

احراز هویت قوی به‌تنهایی کافی نیست؛ Session بعد از Login نیز باید محافظت شود.

OWASP تأکید می‌کند Session ID عملاً نماینده وضعیت احراز هویت کاربر است و سرقت یا جعل آن می‌تواند به Session Hijacking منجر شود. همچنین برای عملیات حساس، Re-authentication می‌تواند یک لایه دفاعی مهم باشد.

بررسی کنید

• ☐ Password Policy مناسب است.

• ☐ Passwordها با الگوریتم مناسب و امن Hash می‌شوند.

• ☐ MFA برای عملیات حساس در نظر گرفته شده است.

• ☐ Session Tokenها تصادفی و غیرقابل حدس هستند.

• ☐ Session پس از تغییر سطح دسترسی مجدداً ایجاد می‌شود.

• ☐ Idle Timeout وجود دارد.

• ☐ Absolute Timeout تعریف شده است.

• ☐ Logout واقعاً Session را invalidate می‌کند.

• ☐ Sessionهای فعال قابل مشاهده و مدیریت هستند.

• ☐ Re-authentication برای عملیات حساس وجود دارد.

• ☐ Cookieها در صورت استفاده دارای Secure و HttpOnly و تنظیم مناسب SameSite هستند.

• ☐ Tokenهای حساس در URL قرار نمی‌گیرند.

عملیات حساس

حداقل این عملیات باید از نظر Authentication و Authorization ویژه بررسی شوند:

• تغییر Password

• تغییر Email

• تغییر شماره موبایل

• تغییر MFA

• ایجاد API Key

• تغییر تنظیمات امنیتی

• افزودن Withdrawal Address

• برداشت

• تغییر محدودیت‌های مالی

5. کنترل دسترسی و RBAC

RBAC یا Role-Based Access Control باید دقیقاً مشخص کند چه کسی چه کاری می‌تواند انجام دهد.

در یک صرافی، «Admin» نباید الزاماً به معنای «دسترسی به همه چیز» باشد.

نقش‌ها را تفکیک کنید

برای مثال:

• Super Admin

• Security Admin

• Finance

• Support

• Compliance

• Operations

• Developer

• Auditor

بررسی کنید

• ☐ هر Role حداقل دسترسی لازم را دارد.

• ☐ کاربران Support به اطلاعات مالی حساس دسترسی غیرضروری ندارند.

• ☐ Developerها به Production Secretها دسترسی پیش‌فرض ندارند.

• ☐ عملیات حساس نیازمند Approval جداگانه است.

• ☐ دسترسی کارکنان هنگام خروج فوراً لغو می‌شود.

• ☐ Access Review دوره‌ای انجام می‌شود.

• ☐ اقدامات Privileged در Audit Log ثبت می‌شوند.

OWASP API Security نیز نشان می‌دهد که Authorization یکی از اصلی‌ترین نقاط شکست در APIهای مدرن است؛ بنابراین RBAC نباید فقط در UI پیاده‌سازی شود و باید در Server enforce شود.

6. امنیت پنل مدیریت

پنل Admin یکی از جذاب‌ترین اهداف برای مهاجم است، چون compromise شدن یک حساب مدیریتی ممکن است دسترسی گسترده‌ای ایجاد کند.

چک‌لیست

• ☐ Admin Panel روی مسیر و معماری امن قرار دارد.

• ☐ MFA اجباری است.

• ☐ دسترسی بر اساس Role محدود است.

• ☐ IP Restriction یا Access Control متناسب با مدل عملیاتی بررسی شده است.

• ☐ Session Timeout مناسب وجود دارد.

• ☐ اقدامات حساس نیازمند تأیید مجدد هستند.

• ☐ تغییرات مهم Audit می‌شوند.

• ☐ عملیات مالی حساس Dual Control یا Approval Workflow دارند.

• ☐ Adminها نمی‌توانند بدون Traceability داده‌های مالی را تغییر دهند.

• ☐ Debug و Test Functionها در Production غیرفعال هستند.

اصل مهم: اگر یک کارمند بتواند موجودی، مقصد برداشت و وضعیت تراکنش را بدون ثبت ردپا تغییر دهد، مشکل فقط «امنیت پنل» نیست؛ معماری کنترل مالی نیز نیاز به بازنگری دارد.

7. امنیت کیف پول و کلیدهای خصوصی

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

گزارش TRM Labs درباره ۲۰۲۵ نشان می‌دهد حملات زیرساختی شامل compromise شدن Keyها، Walletها و Access Control بخش عمده خسارت‌های هکی را تشکیل داده‌اند.

Hot Wallet و Cold Wallet

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

Cold Wallet سطح دسترسی آنلاین را کاهش می‌دهد و معمولاً برای بخش عمده ذخایر مناسب‌تر است، البته معماری دقیق باید بر اساس مدل کسب‌وکار و ریسک تعیین شود.

بررسی کنید

• ☐ Private Key در Source Code یا فایل Configuration نگهداری نمی‌شود.

• ☐ Secretها در Secret Management مناسب نگهداری می‌شوند.

• ☐ دسترسی به Key محدود و Audit می‌شود.

• ☐ Hot Wallet Exposure محدود شده است.

• ☐ سقف موجودی Hot Wallet مشخص است.

• ☐ فرآیند انتقال بین Hot و Cold Wallet تعریف شده است.

• ☐ برای عملیات حساس Approval وجود دارد.

• ☐ Backupهای Key با همان سطح امنیت Production نگهداری نمی‌شوند.

• ☐ Key Rotation و Recovery Plan تعریف شده است.

• ☐ در صورت استفاده از Multisig یا MPC، فرآیندهای آن تست شده‌اند.

• ☐ سناریوی Compromise شدن یک Credential به‌صورت جداگانه بررسی شده است.

OWASP در راهنمای Secrets Management نیز بر مدیریت متمرکز، کنترل دسترسی، Audit و Rotation برای Secretهایی مانند API Key، Credential و SSH Key تأکید دارد.

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

در صرافی، Withdrawal یکی از حساس‌ترین Business Flowها است.

نباید فرض کرد چون کاربر Password و 2FA دارد، برداشت نیز خودبه‌خود امن است.

بررسی کنید

• ☐ برداشت نیازمند Authentication مناسب است.

• ☐ Transaction Authorization جدا از Login بررسی شده است.

• ☐ مقصد برداشت قابل اعتبارسنجی است.

• ☐ Withdrawal Limit وجود دارد.

• ☐ Rate Limit مالی وجود دارد.

• ☐ رفتار غیرعادی برداشت Detection می‌شود.

• ☐ تغییر Withdrawal Address دارای کنترل امنیتی است.

• ☐ برای تغییرات حساس Re-authentication وجود دارد.

• ☐ در شرایط پرریسک Withdrawal Delay یا Review امکان‌پذیر است.

• ☐ Whitelist در صورت مناسب بودن مدل کسب‌وکار در نظر گرفته شده است.

• ☐ Approval Workflow برای مبالغ بالا وجود دارد.

• ☐ تراکنش‌های حساس Audit Trail دارند.

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

9. سیستم ضدتقلب و تشخیص رفتار مشکوک

امنیت صرافی فقط جلوگیری از Exploit فنی نیست.

ممکن است حساب کاربر بدون Exploit مستقیم، از طریق Credential Theft یا Social Engineering در اختیار مهاجم قرار گرفته باشد.

Signalهای قابل بررسی

• Login از موقعیت غیرمعمول

• تغییر ناگهانی Device

• تغییر Password و سپس Withdrawal

• تغییر Email و سپس Withdrawal

• ایجاد API Key جدید

• افزایش ناگهانی حجم معاملات

• الگوی غیرعادی سفارش‌ها

• چندین تلاش Login ناموفق

• تغییر تنظیمات امنیتی پشت سر هم

• برداشت‌های غیرمعمول

• تغییر Withdrawal Address قبل از برداشت

سیستم باید بتواند این رویدادها را Correlate کند، نه اینکه هرکدام را به‌صورت جداگانه ببیند.

10. Rate Limiting و DDoS Protection

Rate Limiting باید فقط برای Login نباشد.

برای مواردی مانند:

• Login

• OTP

• Password Reset

• API

• Order Creation

• Withdrawal

• Address Addition

• Sensitive Admin Actions

محدودیت مناسب تعریف کنید.

در کنار آن، برای مقابله با DDoS باید مشخص باشد:

• چه چیزی در CDN/WAF متوقف می‌شود؟

• چه چیزی در Application Layer کنترل می‌شود؟

• چگونه ترافیک غیرعادی شناسایی می‌شود؟

• در زمان حمله چه سرویس‌هایی باید حفظ شوند؟

• آیا Critical APIها در برابر Resource Exhaustion محافظت شده‌اند؟

OWASP API Security Top 10 نیز Unrestricted Resource Consumption را به‌عنوان یکی از ریسک‌های مهم API معرفی می‌کند.

11. SQL Injection، XSS، CSRF و SSRF

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

SQL Injection

از Queryهای Parameterized و Prepared Statement استفاده کنید و از Concatenation مستقیم داده کاربر با Query اجتناب کنید. OWASP استفاده از Prepared Statements و Parameterized Queries را یکی از دفاع‌های اصلی می‌داند.

XSS

ورودی کاربر باید بسته به Context به‌درستی Encode یا Sanitize شود. استفاده از Framework مدرن کمک‌کننده است اما به‌تنهایی تضمین‌کننده امنیت نیست.

CSRF

برای عملیات State-Changing، به‌خصوص در معماری‌های مبتنی بر Cookie، باید مکانیزم مناسب CSRF Protection وجود داشته باشد. OWASP استفاده از قابلیت‌های داخلی Framework یا CSRF Token را در چنین سناریوهایی توصیه می‌کند.

SSRF

اگر Backend بتواند URL خارجی را Fetch کند، این قابلیت باید با دقت بررسی شود. SSRF می‌تواند Application را به سمت شبکه داخلی یا سرویس‌هایی هدایت کند که نباید مستقیماً در دسترس کاربر باشند.

12. امنیت WebSocket

صرافی‌های معاملاتی برای قیمت لحظه‌ای، Order Book و رویدادهای بازار ممکن است از WebSocket استفاده کنند.

بنابراین WebSocket نیز باید در Scope تست امنیتی باشد.

بررسی کنید

• Authentication

• Authorization

• Origin Validation در معماری مناسب

• Session Management

• Rate Limiting

• Message Validation

• Connection Limits

• جلوگیری از دسترسی Cross-User

• جلوگیری از افشای اطلاعات خصوصی

• قطع Session پس از Logout یا Revoke

• Logging رویدادهای امنیتی

13. امنیت Database

Database صرافی ممکن است حاوی اطلاعات بسیار حساس باشد:

• User Data

• KYC Data

• Balances

• Orders

• Transactions

• Audit Logs

• API Metadata

OWASP در Database Security بر Transport Protection، Authentication امن، Credential Management، Permissions و Hardening تأکید دارد.

چک‌لیست

• ☐ Database مستقیماً از اینترنت قابل دسترسی نیست.

• ☐ Credentialها در Secret Manager هستند.

• ☐ Userهای Database Least Privilege دارند.

• ☐ Encryption مناسب برای داده‌های حساس بررسی شده است.

• ☐ Backup رمزنگاری شده است.

• ☐ دسترسی‌های Database Log می‌شوند.

• ☐ Queryهای حساس قابل Audit هستند.

• ☐ Data Retention مشخص است.

• ☐ Production Data بدون کنترل وارد محیط Development نمی‌شود.

14. Encryption و مدیریت Secrets

Encryption باید دقیقاً مشخص کند:

چه چیزی، در چه زمانی، با چه کلیدی و در کجا رمزنگاری می‌شود؟

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

بررسی کنید:

• TLS برای ارتباطات حساس

• Encryption at Rest در صورت نیاز

• Key Management

• Secret Rotation

• Access Control

• Secret Audit

• عدم Hardcode شدن Secretها

• عدم قرارگیری Secret در Git

• عدم Log شدن Password، Token، Private Key یا API Secret

OWASP هشدار می‌دهد که Secretها اغلب به‌صورت ناامن در Source Code، Configuration و ابزارهای مدیریت Configuration پراکنده می‌شوند و بر Centralized Storage، Provisioning، Auditing و Rotation تأکید دارد.

15. Logging، Monitoring و Alerting

اگر حادثه‌ای اتفاق بیفتد، باید بتوانید پاسخ دهید:

چه کسی، چه زمانی، از کجا و چه کاری انجام داد؟

Logging فقط فعال‌کردن Web Server Log نیست. OWASP نیز بر اهمیت Application Security Logging و ثبت رویدادهای امنیتی در سطح Application تأکید می‌کند.

حداقل رویدادهای مهم

• Login موفق و ناموفق

• MFA تغییر یافته

• Password تغییر یافته

• Email تغییر یافته

• API Key ایجاد/لغو شده

• Withdrawal Address تغییر کرده

• Withdrawal ایجاد شده

• Admin Login

• تغییر Role

• تغییر Permission

• تغییرات تنظیمات مالی

• دسترسی‌های Privileged

• خطاهای امنیتی

• فعالیت‌های مشکوک

Monitoring باید بتواند Alert کند

مثلاً:

چندین Login ناموفق → Login موفق → تغییر MFA → ایجاد API Key → Withdrawal

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

16. Backup و Disaster Recovery

Backup زمانی ارزش دارد که واقعاً قابل Restore باشد.

چک‌لیست:

• ☐ Backup برای داده‌های حیاتی فعال است.

• ☐ Backupها در محل جداگانه نگهداری می‌شوند.

• ☐ Backupها Access Control دارند.

• ☐ Backup Encryption بررسی شده است.

• ☐ Restore Test انجام شده است.

• ☐ RPO مشخص است.

• ☐ RTO مشخص است.

• ☐ سناریوی Database Corruption بررسی شده است.

• ☐ سناریوی Ransomware یا Compromise زیرساخت بررسی شده است.

• ☐ مسئول Recovery مشخص است.

• ☐ Runbook بازیابی وجود دارد.

یک Backup که هیچ‌وقت Restore Test نشده، از نظر عملی «فرضیه Backup» است، نه الزاماً یک قابلیت Recovery اثبات‌شده.

17. Dependency Security و Supply Chain

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

ممکن است وابسته باشد به:

• Framework

• Package

• SDK

• Docker Image

• Cloud Service

• Blockchain Node

• RPC Provider

• KYC Provider

• Email/SMS Provider

• Analytics

• Monitoring

• Payment Provider

بررسی کنید

• Dependency Inventory دارید؟

• نسخه‌های آسیب‌پذیر شناسایی می‌شوند؟

• Dependency Update Process دارید؟

• Packageهای بلااستفاده حذف شده‌اند؟

• Source و Integrity Packageها کنترل می‌شود؟

• Third-Party Risk Assessment انجام شده؟

• در صورت اختلال سرویس‌دهنده خارجی، رفتار سیستم مشخص است؟

18. Code Review و تست امنیتی

Security Testing نباید به یک Automated Scanner محدود شود.

ترکیب مناسب‌تر

SAST + DAST + Dependency Scanning + Manual Review + Penetration Testing

و در صورت نیاز:

• API Testing

• Business Logic Testing

• Infrastructure Testing

• Cloud Configuration Review

• Wallet Security Review

• Access Control Review

OWASP ASVS برای تبدیل الزامات امنیتی به معیارهای قابل Verification گزینه مناسبی است.

19. تست نفوذ صرافی ارز دیجیتال

تست نفوذ یا Penetration Testing باید قبل از Launch در Scope مشخص انجام شود.

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

گزارش باید مشخص کند:

• Scope چه بوده؟

• چه Assetهایی تست شده‌اند؟

• چه APIهایی بررسی شده‌اند؟

• آیا Authentication تست شده؟

• آیا Authorization تست شده؟

• آیا Business Logic بررسی شده؟

• آیا Withdrawal Flow بررسی شده؟

• آیا Admin Panel بررسی شده؟

• آیا WebSocket در Scope بوده؟

• آیا Infrastructure تست شده؟

• Severity یافته‌ها چیست؟

• آیا یافته‌های Critical و High رفع و Retest شده‌اند؟

یک معیار مهم

Pentest بدون Retest برای یافته‌های مهم، نشانه کافی برای Go-Live نیست.

20. امنیت Matching Engine و معاملات

Matching Engine قلب عملیاتی صرافی معاملاتی است.

باید بررسی شود:

• Order Validation

• Price/Quantity Validation

• جلوگیری از Manipulation

• Race Conditions

• Atomicity

• Idempotency

• وضعیت Order

• Cancel/Replace

• همگام‌سازی Balance و Order

• Consistency بین Trading Engine و Ledger

در این قسمت، امنیت و Correctness به یکدیگر نزدیک می‌شوند؛ چون یک نقص منطقی ممکن است مستقیماً اثر مالی داشته باشد.

21. امنیت Spot Trading

در Spot باید به‌طور ویژه موارد زیر بررسی شوند:

• Order Validation

• Balance Locking

• Double Spending در سطح داخلی

• Race Conditions

• Order Cancellation

• Fee Calculation

• Precision/Decimal Handling

• Ledger Consistency

• Market Data Integrity

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

22. امنیت صرافی Futures ارز دیجیال

Futures نسبت به Spot، منطق مالی و ریسک پیچیده‌تری دارد.

مواردی مانند:

• Margin

• Leverage

• Liquidation

• Mark Price

• Funding

• Position State

• Risk Engine

• Order Matching

• Insurance Mechanism

باید در تست امنیتی و Business Logic Testing قرار بگیرند.

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

23. امنیت صرافی CEX ارز دیحجیتال

در Centralized Exchange یا CEX علاوه بر امنیت Application، یک نقطه تمرکز بزرگ وجود دارد:

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

بنابراین مواردی مانند:

• Privileged Access

• Wallet Security

• Ledger Integrity

• Admin Security

• Internal Fraud

• Withdrawal Controls

• Segregation of Duties

اهمیت بیشتری پیدا می‌کنند.

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

برای پروژه‌ای که استفاده از راهکار آماده را مدنظر دارد نیز، اسکریپت صرافی متمرکز (CEX) ارز دیجیتال می‌تواند در مرحله ارزیابی گزینه‌های فنی مورد بررسی قرار گیرد؛ البته وجود قابلیت امنیتی در یک محصول باید با Audit و Testing مستقل Verify شود.

24. امنیت صرافی p2p ارز دیجیتال

در P2P علاوه بر Application Security، مسئله اصلی اعتماد و کنترل فرآیند معامله است.

باید موارد زیر بررسی شوند:

• Escrow Logic

• Release Conditions

• Dispute Handling

• Identity/Account Integrity

• Fraud Detection

• Payment Verification

• Timeout Rules

• State Transition

• Admin Override

• Audit Trail

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

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

25. امنیت صرافی OTC ارز دیجیتال

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

تمرکز امنیتی باید روی:

• Approval Workflow

• Deal Authorization

• Settlement

• Identity Verification

• Manual Operations

• Role Separation

• Auditability

• Payment/Asset Reconciliation

باشد.

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

26. امنیت KYC/AML از منظر فنی

KYC و AML فقط موضوع Compliance نیستند؛ داده‌های KYC نیز Asset حساس هستند.

بررسی کنید:

• چه داده‌ای ذخیره می‌شود؟

• چه کسانی به آن دسترسی دارند؟

• آیا Data Minimization رعایت شده؟

• داده‌ها در Transit و در صورت نیاز At Rest محافظت می‌شوند؟

• Retention Policy چیست؟

• Export داده چگونه کنترل می‌شود؟

• دسترسی Support چگونه ثبت می‌شود؟

• Third-Party KYC Provider چه سطح دسترسی دارد؟

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

27. مدیریت Incident Response

هیچ معماری امنیتی را نباید با فرض «هیچ‌وقت نفوذ نمی‌شویم» طراحی کرد.

سؤال درست این است:

اگر فردا یکی از Credentialهای مهم ما compromise شد، دقیقاً چه می‌کنیم؟

باید Runbook برای سناریوهایی مانند این داشته باشید:

1. Compromise شدن Admin

2. Compromise شدن API Key

3. Suspicious Withdrawal

4. Private Key Compromise

5. Database Breach

6. Cloud Account Compromise

7. DDoS

8. Ransomware

9. Dependency Vulnerability

10. Insider Threat

برای هر سناریو مشخص کنید:

• چه کسی Incident را اعلام می‌کند؟

• چه کسی تصمیم‌گیرنده است؟

• چه دسترسی‌هایی باید Revoke شوند؟

• چه سرویس‌هایی باید Isolate شوند؟

• چگونه دارایی‌ها محافظت می‌شوند؟

• چگونه Evidence حفظ می‌شود؟

• چگونه کاربران مطلع می‌شوند؟

• چه زمانی Recovery آغاز می‌شود؟

تفاوت امنیت Spot، Futures، CEX، P2P و OTC

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

اگر هنوز زیرساخت صرافی را انتخاب نکرده‌اید،

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

اشتباهات رایج در امنیت صرافی ارز دیجیتال قبل از راه‌اندازی

1. «فقط SSL داریم، پس سایت امن است»

HTTPS برای محافظت از ارتباط ضروری است، اما فقط یکی از لایه‌های امنیت است.

راهکار: Application، API، Infrastructure، Wallet و Business Logic را نیز تست کنید.

2. فعال کردن 2FA و پایان دادن به تست امنیت

MFA مهم است، اما اگر مهاجم بتواند Session، API Key یا Workflow برداشت را دور بزند، MFA به‌تنهایی کافی نیست.

راهکار: Authentication و Transaction Authorization را جداگانه بررسی کنید.

3. تست فقط روی Frontend

مخفی کردن Button در Frontend کنترل دسترسی نیست.

راهکار: تمام Authorizationها باید در Backend enforce شوند.

4. نگهداری Secret داخل .env و Git

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

راهکار: Secret Management، Rotation و Access Audit داشته باشید. OWASP نیز بر همین چرخه مدیریت Secret تأکید می‌کند.

5. نگهداری بیش از حد دارایی در Hot Wallet

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

راهکار: Hot Wallet Exposure، Limits و فرآیند Cold Storage را بر اساس Risk Model طراحی کنید.

6. اعتماد کامل به WAF

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

راهکار: Root Cause را در Code و Architecture برطرف کنید.

7. انجام Pentest بدون Retest

گزارش Pentest با چند Finding باز، معیار مناسبی برای Go-Live نیست.

راهکار: برای یافته‌های مهم Remediation و Retest را به Definition of Done امنیتی تبدیل کنید.

8. تست نکردن سناریوی برداشت

ممکن است Login امن باشد ولی Withdrawal Flow آسیب‌پذیر باشد.

راهکار: کل Transaction Lifecycle را End-to-End تست کنید.

9. Backup بدون Restore Test

Backup خراب یا غیرقابل‌بازیابی در زمان بحران کمکی نمی‌کند.

راهکار: Restore Drill دوره‌ای داشته باشید.

10. دادن دسترسی کامل به یک Admin

تمرکز بیش از حد Privilege، Impact compromise را افزایش می‌دهد.

راهکار: RBAC، Least Privilege، Segregation of Duties و Approval Workflow.

از کجا بفهمیم اسکریپت صرافی ارز دیجیتال برای Launch آماده است؟

«آماده Launch» بودن را باید با معیار قابل بررسی تعریف کرد.

یک صرافی زمانی به Go-Live نزدیک است که حداقل این شرایط برقرار باشند:

از نظر فنی

• Asset Inventory کامل است.

• Production Environment مشخص و Harden شده است.

• Attack Surface شناخته شده است.

• Dependencyهای بحرانی بررسی شده‌اند.

• APIها تست شده‌اند.

• Authentication و Authorization تست شده‌اند.

• Admin Panel بررسی شده است.

• Wallet Architecture Review شده است.

• Withdrawal Flow تست شده است.

• Logging و Monitoring فعال است.

• Alerting آزمایش شده است.

از نظر امنیتی

• Vulnerability Assessment انجام شده است.

• Penetration Test انجام شده است.

• Critical و High Findings بدون Risk Acceptance معتبر باقی نمانده‌اند.

• Retest انجام شده است.

• Secrets مدیریت‌شده هستند.

• Key Management فرآیند مشخص دارد.

• MFA برای دسترسی‌های حساس فعال است.

• Incident Response Plan وجود دارد.

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

• Backup وجود دارد.

• Restore Test انجام شده است.

• RTO/RPO مشخص است.

• Runbookهای Incident وجود دارند.

• مسئول هر Incident مشخص است.

• دسترسی کارکنان Review شده است.

از نظر مالی

• Withdrawal Limits مشخص هستند.

• Approval Workflow برای عملیات حساس وجود دارد.

• Ledger و Balance Reconciliation تست شده است.

• Fraud Monitoring فعال است.

اگر تیم نتواند برای هرکدام از این موارد مدرک، تست یا شواهد قابل بررسی ارائه کند، عبارت «آماده Launch» هنوز اثبات نشده است.

مسیر پیشنهادی Security Gate قبل از Go-Live

می‌توان فرآیند را در چند Gate تعریف کرد:

Gate 1 — Architecture Review

بررسی معماری، Trust Boundary، Infrastructure و Threat Model.

Gate 2 — Secure Development Review

بررسی Code، Dependencies، Authentication، Authorization و Secrets.

Gate 3 — Security Testing

Vulnerability Assessment، API Testing، DAST/SAST و Manual Testing.

Gate 4 — Penetration Testing

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

Gate 5 — Remediation & Retest

رفع Findings و اعتبارسنجی مجدد.

Gate 6 — Operational Security

Logging، Monitoring، Alerting، Backup، Recovery و Incident Response.

Gate 7 — Go-Live Approval

ثبت Risk Acceptanceهای باقی‌مانده و تأیید رسمی Stakeholderهای مسئول.

این رویکرد با نگاه Risk-Based در NIST CSF 2.0 هم‌راستا است؛ NIST این چارچوب را برای کمک به سازمان‌ها در درک، ارزیابی و مدیریت ریسک سایبری ارائه کرده است.

اگر هنوز زیرساخت صرافی را انتخاب نکرده‌اید،

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

11. چک‌لیست نهایی قابل استفاده قبل از Launch

زیرساخت

• ☐ Asset Inventory کامل شده است.

• ☐ Production از Development جداست.

• ☐ Network Segmentation بررسی شده است.

• ☐ Firewall/Security Groupها Review شده‌اند.

• ☐ Management Access محدود شده است.

• ☐ Patch Management انجام شده است.

• ☐ Cloud Configuration بررسی شده است.

Application

• ☐ Code Review امنیتی انجام شده است.

• ☐ SAST انجام شده است.

• ☐ DAST انجام شده است.

• ☐ Dependency Scan انجام شده است.

• ☐ Input Validation بررسی شده است.

• ☐ SQL Injection تست شده است.

• ☐ XSS تست شده است.

• ☐ CSRF بررسی شده است.

• ☐ SSRF بررسی شده است.

API

• ☐ API Inventory کامل است.

• ☐ APIهای قدیمی حذف یا محدود شده‌اند.

• ☐ Authentication تست شده است.

• ☐ Authorization تست شده است.

• ☐ Object-level Authorization تست شده است.

• ☐ Function-level Authorization تست شده است.

• ☐ Rate Limiting فعال است.

• ☐ API Key Management امن است.

• ☐ API Secretها خارج از Source Code هستند.

Authentication

• ☐ Password Policy مناسب است.

• ☐ MFA برای دسترسی‌های حساس فعال است.

• ☐ Session Management تست شده است.

• ☐ Session Timeout وجود دارد.

• ☐ Re-authentication برای عملیات حساس وجود دارد.

• ☐ Logout Session را invalidate می‌کند.

Admin

• ☐ RBAC پیاده‌سازی شده است.

• ☐ Least Privilege رعایت شده است.

• ☐ Admin MFA فعال است.

• ☐ Privileged Actions Log می‌شوند.

• ☐ دسترسی کارکنان Review شده است.

• ☐ دسترسی افراد خارج‌شده Revoked شده است.

Wallet

• ☐ Private Key در Source Code نیست.

• ☐ Secret Management وجود دارد.

• ☐ Hot Wallet Limit تعریف شده است.

• ☐ Cold Storage Strategy مشخص است.

• ☐ Key Access محدود است.

• ☐ Key Recovery Plan وجود دارد.

• ☐ Multisig/MPC در صورت استفاده تست شده است.

Withdrawal

• ☐ Withdrawal Authentication تست شده است.

• ☐ Transaction Authorization تست شده است.

• ☐ Withdrawal Limit فعال است.

• ☐ Rate Limit فعال است.

• ☐ Address Change Security بررسی شده است.

• ☐ Withdrawal Monitoring فعال است.

• ☐ Approval برای تراکنش‌های حساس وجود دارد.

• ☐ سناریوی Suspicious Withdrawal تست شده است.

Trading

• ☐ Matching Engine تست شده است.

• ☐ Order Validation بررسی شده است.

• ☐ Race Condition بررسی شده است.

• ☐ Balance/Order Consistency تست شده است.

• ☐ Ledger Integrity بررسی شده است.

• ☐ Fee Calculation تست شده است.

Monitoring

• ☐ Security Logging فعال است.

• ☐ Admin Actions ثبت می‌شوند.

• ☐ Withdrawal Events ثبت می‌شوند.

• ☐ Authentication Events ثبت می‌شوند.

• ☐ Alerting فعال است.

• ☐ Monitoring Dashboard آماده است.

• ☐ Log Integrity و Access Control بررسی شده‌اند.

Recovery

• ☐ Backup فعال است.

• ☐ Backup رمزنگاری و محافظت شده است.

• ☐ Restore Test انجام شده است.

• ☐ RTO مشخص است.

• ☐ RPO مشخص است.

• ☐ Disaster Recovery Runbook وجود دارد.

Testing

• ☐ Vulnerability Assessment انجام شده است.

• ☐ Penetration Test انجام شده است.

• ☐ API Security Test انجام شده است.

• ☐ Business Logic Test انجام شده است.

• ☐ Critical Findings رفع شده‌اند.

• ☐ High Findings تعیین تکلیف شده‌اند.

• ☐ Retest انجام شده است.

Incident Response

• ☐ Incident Response Plan وجود دارد.

• ☐ مسئول Incident مشخص است.

• ☐ سناریوی Admin Compromise تست شده است.

• ☐ سناریوی API Key Compromise تست شده است.

• ☐ سناریوی Wallet Compromise بررسی شده است.

• ☐ سناریوی Database Breach بررسی شده است.

• ☐ سناریوی DDoS بررسی شده است.

• ☐ Communication Plan وجود دارد.

 سوالات متداول درباره امنیت صرافی ارز دیجیتال

آیا قبل از راه‌اندازی صرافی ارز دیجیتال حتماً باید تست نفوذ انجام شود؟

برای یک پلتفرم مالی با ریسک بالا، تست نفوذ بخش مهمی از فرآیند اعتبارسنجی امنیت است؛ اما به‌تنهایی کافی نیست و باید کنار Code Review، Vulnerability Assessment، API Testing و بررسی معماری انجام شود.

آیا فعال کردن 2FA برای امن شدن صرافی کافی است؟

خیر. 2FA فقط بخشی از Authentication است. Session، Authorization، API، Withdrawal و Transaction Authorization نیز باید به‌صورت جداگانه بررسی شوند.

مهم‌ترین بخش امنیت صرافی چیست؟

یک بخش واحد وجود ندارد. اما Wallet/Key Management، Withdrawal، Privileged Access، API Authorization، Authentication و Business Logic معمولاً از حساس‌ترین حوزه‌ها هستند.

Hot Wallet بهتر است یا Cold Wallet؟

این دو جایگزین مطلق یکدیگر نیستند. Hot Wallet برای عملیات آنلاین کاربرد دارد و Cold Storage می‌تواند Exposure آنلاین ذخایر را کاهش دهد. معماری مناسب به مدل کسب‌وکار، نقدینگی، فرآیند برداشت و Risk Model بستگی دارد.

آیا WAF جلوی هک صرافی را می‌گیرد؟

خیر. WAF یک لایه دفاعی است و جایگزین Secure Coding، Authorization، Patch Management، Penetration Testing و کنترل‌های معماری نمی‌شود.

آیا API صرافی باید جداگانه تست شود؟

بله. APIها سطح حمله بسیار مهمی هستند و ریسک‌هایی مانند Broken Object Level Authorization، Broken Authentication و Unrestricted Resource Consumption باید بررسی شوند.

آیا Backup به‌تنهایی برای Disaster Recovery کافی است؟

خیر. Backup باید قابل Restore باشد و برای آن RTO، RPO و Runbook مشخص داشته باشید.

آیا استفاده از اسکریپت آماده صرافی امنیت را تضمین می‌کند؟

خیر. هیچ محصول یا اسکریپتی صرفاً به دلیل آماده بودن، امنیت را تضمین نمی‌کند. باید Source/Architecture، Configuration، Dependencies، API، Wallet Integration و Business Logic متناسب با محیط واقعی بررسی و تست شوند.

امنیت CEX با P2P چه تفاوتی دارد؟

CEX معمولاً ریسک بیشتری در نقاط متمرکز مانند Admin، Wallet، Ledger و Withdrawal دارد؛ در P2P، علاوه بر امنیت فنی، Escrow، Fraud، Dispute و State Transition اهمیت زیادی پیدا می‌کنند.

چه زمانی می‌توان گفت صرافی آماده Go-Live است؟

زمانی که کنترل‌های حیاتی پیاده‌سازی، تست و مستندسازی شده باشند، Findings مهم تعیین تکلیف شده باشند، Recovery و Incident Response آزمایش شده باشند و مالک کسب‌وکار و تیم فنی از Riskهای باقی‌مانده آگاه و مسئولیت آن‌ها مشخص باشد.

آیا امنیت را می‌توان بعد از Launch انجام داد؟

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

جمع‌بندی

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

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

یک صرافی برای Launch باید بتواند هم‌زمان نشان دهد که:

• زیرساخت آن Hardening شده است؛

• API و Authorization تست شده‌اند؛

• Authentication و Session درست طراحی شده‌اند؛

• دسترسی Adminها کنترل شده است؛

• Private Key و Secrets به شکل مناسب مدیریت می‌شوند؛

• Withdrawal دارای کنترل‌های چندلایه است؛

• Trading و Ledger از نظر Business Logic بررسی شده‌اند؛

• Logging و Monitoring فعال هستند؛

• Backup واقعاً قابل بازیابی است؛

• Incident Response آماده است؛

• و یافته‌های مهم تست‌های امنیتی رفع و Retest شده‌اند.

هدف امنیت این نیست که ادعا کنیم صرافی «غیرقابل هک» است؛ چنین تضمینی واقع‌بینانه نیست. هدف، کاهش سطح حمله، محدودکردن Impact، شناسایی سریع حادثه و ایجاد توانایی پاسخ و بازیابی است.

اگر قرار است صرافی پیش از Launch ارزیابی شود، بهتر است همین چک‌لیست به یک Security Gate رسمی تبدیل شود و هر مورد با وضعیت «انجام شده، نیازمند اصلاح، مستثنی با Risk Acceptance یا تأیید نشده» ثبت شود.

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