1405/06/14
آریا گستران
بدون دیدگاه

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

یک صرافی ارز دیجیتال قبل از اینکه با اولین کاربر، اولین سفارش و اولین برداشت واقعی روبه‌رو شود، باید از چندین زاویه امنیتی بررسی شده باشد. مشکل اینجاست که «امن بودن سایت» با «آماده بودن یک صرافی برای 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 برای سناریوهایی مانند این داشته باشید:

Compromise شدن Admin
Compromise شدن API Key
Suspicious Withdrawal
Private Key Compromise
Database Breach
Cloud Account Compromise
DDoS
Ransomware
Dependency Vulnerability
Insider Threat

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

چه کسی Incident را اعلام می‌کند؟
چه کسی تصمیم‌گیرنده است؟
چه دسترسی‌هایی باید Revoke شوند؟
چه سرویس‌هایی باید Isolate شوند؟
چگونه دارایی‌ها محافظت می‌شوند؟
چگونه Evidence حفظ می‌شود؟
چگونه کاربران مطلع می‌شوند؟
چه زمانی Recovery آغاز می‌شود؟

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

مدل	تمرکز امنیتی اصلی	ریسک‌های شاخص
Spot	Order و Ledger	Race Condition، Balance Integrity، API Abuse
Futures	Risk/Margin Engine	Liquidation Logic، Leverage، Position Integrity
CEX	کنترل متمرکز	Wallet، Admin، Withdrawal، Internal Access
P2P	Escrow و معامله کاربر با کاربر	Fraud، Dispute، State Manipulation
OTC	Settlement و عملیات دستی	Privileged Access، Approval، High-value Transactions

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

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

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

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

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 یا تأیید نشده» ثبت شود.

شرکت آریا گستران