چرا کلید API بات و ابزار بررسی ریسک باید جدا باشد؟
چرا ربات اجرایی و ابزار بررسی حساب نباید یک کلید API مشترک داشته باشند، و جداسازی کلیدها چطور دامنه آسیب یک حادثه امنیتی را کوچک می‌کند.
بات اجرایی و ابزار بررسی ریسک دو وظیفه متفاوت دارند؛ پس نباید یک کلید API مشترک داشته باشند. بات ممکن است لازم باشد سفارش بسازد یا لغو کند، اما ابزار بررسی معمولاً فقط مشاهده می‌خواهد. ترکیب این دسترسی‌ها باعث می‌شود یک داشبورد کم‌ریسک هم ناخواسته مسیر دسترسی به معامله را در اختیار داشته باشد.
پاسخ کوتاه: برای هر سرویس، محیط و هدف یک اعتبارنامه اختصاصی بساز. بات فقط دامنه دسترسی ضروری اجرا را بگیرد، ابزار ریسک فقط خواندن دسترسی داشته باشد، برداشت برای هر دو بسته بماند و هر کلید بدون خاموش کردن سرویس دیگر قابل لغو باشد.
نکات کلیدی
- جداسازی اعتبارنامه یک مرز امنیتی است، نه مرتب‌کاری اداری.
- ابزار خواندنی نباید چون سرویس دیگری نیاز دارد، دسترسی معامله به ارث ببرد.
- کلید جدا، لاگ، مالک، نرخ سقف و رخداد پاسخ را شفاف می‌کند.
- محیط توسعه و محیط عملیاتی هم باید اعتبارنامه مستقل داشته باشند.
- کلید مشترک، منبع یک درخواست مشکوک را پنهان می‌کند.
- DRKN باید در مسیر بررسی حداقل‌دسترسی بماند و اختیار بات را share نکند.
کلید مشترک چه مشکلی می‌سازد؟
کلید مشترک مجبور است مجموع دسترسی‌های هر دو ابزار را داشته باشد. اگر بات ایجاد سفارش بخواهد و داشبورد موجودی بخواند، هر دو سیستمی به اعتبارنامه دسترسی دارند که می‌تواند معامله کند. آسیب‌پذیری در داشبورد، مرورگر، فرایند support یا زیرساخت ارائه‌دهنده، قدرتی را لو می‌دهد که آن ابزار هرگز لازم نداشته است.
ردیابی هم خراب می‌شود. لاگ صرافی همان کلید ID را برای درخواست‌های بررسی و سفارش‌های بات نشان می‌دهد. با دیدن سفارش ناشناس، تیم سریع نمی‌فهمد کدام سیستم آن را فرستاده است. لغو کلید نیز هر دو سرویس را قطع می‌کند و همین وابستگی ممکن است تصمیم امنیتی را عقب بیندازد. حتی نرخ سقف مشترک خطر دارد؛ گزارش‌گیری سنگین داشبورد می‌تواند ظرفیت بات را مصرف و تلاش مجدد خطرناک ایجاد کند.
جداسازی چگونه دامنه حادثه را کم می‌کند؟
هر اعتبارنامه به یک محدوده کوچک تبدیل می‌شود. افشای کلید فقط‌خواندنی فقط همان داده‌های مستند را در معرض خطر می‌گذارد و کلید اجرا جدا می‌ماند. اگر رفتار بات مشکوک شود، می‌توان کلید اجرایی را لغو کرد و دسترسی خواندنی لازم برای بررسی حساب را حفظ کرد.
کنترل‌های متفاوت هم ممکن می‌شوند. کلید بات به IP سرور اجرا محدود می‌شود و کلید بررسی به سرویس دیگری. برای هرکدام چرخش، هشدار و مالک مستقل تعریف می‌شود. نام‌هایی مثل prod-bot-orders و prod-risk-read در رخداد پاسخ مفیدند، به شرط آنکه نام شامل کلید محرمانه یا اطلاعات حساس نباشد.
هر سرویس چه دسترسی‌هایی لازم دارد؟
دسترسی را از روی job description سطح اندپوینت تعیین کن. ابزار بررسی شاید فعلی موجودی، مارجین وضعیت و باز پوزیشن بخواهد؛ ایجاد سفارش، لغو سفارش، transfer و برداشت برای آن بی‌معنی است. بات احتمالاً بازار data، ساخت و لغو سفارش و سفارش وضعیت لازم دارد، اما در اکثر استراتژی‌ها به برداشت یا انتقال داخلی نیازی ندارد.
گزینه کلی معامله را قبل از شناخت پوشش آن روشن نکن. صرافی‌ها اقدام‌ها را متفاوت دسته‌بندی می‌کنند. اگر بات فقط روی ساب‌اکانت یا نماد مشخص کار می‌کند و صرافی چنین مرزی دارد، آن را اعمال کن. کمبود مستندات دلیل روشن کردن همه دسترسی‌ها نیست؛ دلیل توقف و تست بیشتر است.
اتصال DRKN برای بررسی حساب را با کلید اختصاصی و حداقل دسترسی نگه دار. برای سرعت setup، کلید بات اجرایی را استفاده دوباره نکن و اختیار معامله را وارد مسیر تحلیل نکن.
محیط‌ها و مالک‌ها چطور جدا شوند؟
محیط عملیاتی، staging، توسعه محلی و اسکریپت یک‌باره نباید اعتبارنامه یکسان داشته باشند. لپ‌تاپ توسعه‌دهنده threat model متفاوتی از سرور محیط عملیاتی دارد. برای توسعه از محیط آزمایشی استفاده کن و اجازه نده محیط تست به حساب اصلی دسترسی پیدا کند.
برای هر کلید یک مسئول و یک نفر جایگزین ثبت کن. مسئول باید هدف، dependency، دسترسی، آخرین چرخش و زمان حذف را به‌روز نگه دارد. service حساب مسئولیت انسانی را حذف نمی‌کند؛ یک نفر باید تصمیم بگیرد که دسترسی هنوز توجیه دارد یا نه.
هر ارائه‌دهنده شخص ثالث نیز کلید خودش را می‌خواهد. حتی اگر دو ارائه‌دهنده کار مشابهی انجام دهند، اعتبارنامه جدا اجازه می‌دهد یکی را بدون آسیب به دیگری offboard کنی و الگوی ترافیک هرکدام را ببینی.
مهاجرت از کلید مشترک چطور انجام می‌شود؟
فرض کن بات سفارش و داشبورد حساب هر دو از main-api استفاده می‌کنند:
1. از روی کد و لاگ، اندپوینت‌های واقعی هر سرویس را فهرست‌برداری کن. 2. کلید risk-review-read را فقط با دامنه دسترسی خواندن لازم بساز. 3. روی داشبورد deploy و درخواست مجاز و غیرمجاز را تست کن. 4. کلید bot-orders را به بازار و سفارش دامنه دسترسی لازم محدود کن و برداشت را ببند. 5. بات را منتقل و خطای auth، تلاش مجدد و نرخ سقف را پایش کن. 6. وقتی ترافیک main-api صفر شد، آن را لغو کن. 7. مالک، IP، تاریخ چرخش و اقدام رخداد هر دو کلید را ثبت کن.
کلید قدیمی را «برای روز مبادا» نگه ندار. اعتبارنامه قدرتمند و خاموش هم اکسپوژر است.
جداسازی چگونه اتوماسیون را قابل پایش می‌کند؟
با کلید جدا، create-order روی اعتبارنامه خواندنی فوراً یک سیاست violation است. افزایش شدید balance-read روی کلید اجرا نیز می‌تواند loop یا compromise را نشان دهد. در کلید مشترک هر دو الگو به‌اندازه کافی عادی به نظر می‌رسند و تشخیص دیر می‌شود.
این معماری کلید توقف اضطراری بهتری می‌سازد. لغو کلید بات جلوی درخواست جدید را می‌گیرد، درحالی‌که اپراتور سفارش و پوزیشن را دستی بررسی می‌کند. البته revocation اثر سفارش قبلی، پرشدن یا اهرم را برنمی‌گرداند؛ برنامه حادثه باید وضعیت واقعی حساب را هم پوشش دهد.
DRKN در این معماری کجاست؟
جایگاه قابل دفاع DRKN تفسیر ریسک حساب با کمترین دسترسی است، نه ارث بردن اختیار بات. مسیر اتصال باید دسترسی را شفاف کند و تصمیم معامله و اقدام حساس را نزد کاربر نگه دارد. این تفکیک هم اعتماد محصول و هم طراحی فنی را روشن‌تر می‌کند. در عمل یعنی [اتصال Toobit](/connections) با کلیدی که فقط دامنه دسترسی خواندن موجودی و پوزیشن دارد — همان اصل جداسازی که این مقاله برایش استدلال می‌کند، روی اتصال خود DRKN هم اعمال شده.
مالکیت اعتبارنامه را با چرخه عمر کلید API برنامه‌ریزی کن، ریسک حریم خصوصی داده read-only را بشناس و در اجرا برای ریسک partial fill آماده باش.
پرسش‌های متداول
دو بات می‌توانند یک کلید مشترک داشته باشند؟
ممکن است از نظر فنی کار کند، اما کلید جدا برای دسترسی، لاگ، نرخ سقف، لغو و مالکیت امن‌تر است.
هر ابزار ریسک کلید فقط‌خواندنی جدا می‌خواهد؟
اگر صرافی اجازه می‌دهد، بله. اعتبارنامه اختصاصی دامنه حادثه و ابهام offboarding را کم می‌کند.
بات معامله‌گر به برداشت نیاز دارد؟
اکثر استراتژی‌های ثبت سفارش نیازی ندارند. برداشت و انتقال را بدون مسیر کاری جداگانه و بازبینی‌شده فعال نکن.
می‌توانم کلید فعلی بات را به DRKN بدهم؟
استفاده دوباره کردن کلید اجرا خلاف حداقل دسترسی است. برای بررسی حساب، اتصال اختصاصی و محدود بساز.
منابع
هشدار ریسک: این راهنما تضمین امنیت یا توصیه مالی نیست. دسترسی و رفتار اتوماسیون در صرافی‌ها متفاوت است و محتوا پیش از انتشار و استقرار به بازبینی انسانی امنیت و محصول نیاز دارد.