چرخه عمر کلید API کریپتو: ساخت، تست، چرخش و لغو
هر کلید را دسترسی موقت برای یک کار مشخص بدان. برایش مالک، کاربرد، سطح مجوز، تاریخ بازبینی و شرط لغو تعیین کن. تست موفق فقط این نیست که درخواست مجاز جواب…
کلید API امن یک تنظیم یک‌باره نیست. این کلید یک اعتبارنامه با عمر مشخص است: ابتدا نیاز آن تعریف می‌شود، سپس با کمترین مجوز ساخته و در محیط امن آزمایش می‌شود، استفاده‌اش زیر نظر می‌رود، در زمان مناسب می‌چرخد و وقتی کارش تمام شد لغو می‌شود. حذف مراحل آخر باعث می‌شود کلیدی که برای یک تست کوتاه ساخته شده، ماه‌ها بعد همچنان در حساب فعال بماند.
پاسخ کوتاه: هر کلید را دسترسی موقت برای یک کار مشخص بدان. برایش مالک، کاربرد، سطح مجوز، تاریخ بازبینی و شرط لغو تعیین کن. تست موفق فقط این نیست که درخواست مجاز جواب بدهد؛ باید مطمئن شوی درخواست معامله، انتقال یا برداشت که خارج از نیاز ابزار است، رد می‌شود.
نکات کلیدی
- هر کلید باید یک هدف روشن و یک مالک پاسخ‌گو داشته باشد.
- ابزار بررسی ریسک به مجوز برداشت و معمولاً به مجوز معامله نیاز ندارد.
- تست امن باید شکست عملیات غیرمجاز را هم ثابت کند.
- چرخش، جایگزینی کنترل‌شده کلید قدیمی با کلید جدید است.
- پایان همکاری، تغییر مسئول، افشای احتمالی یا ترافیک ناشناس، دلیل لغو فوری است.
- نقش DRKN بررسی ریسک با حداقل دسترسی است؛ کنترل اجرا باید جدا بماند.
چرا کلید API به چرخه عمر نیاز دارد؟
ریسک کلید بعد از ساخت ثابت نمی‌ماند. ممکن است IP سرور عوض شود، کلید به‌اشتباه داخل لاگ برود، توسعه‌دهنده از تیم جدا شود یا سرویس آزمایشی بی‌خبر به بخشی از محیط اصلی تبدیل شود. صفحه دسترسی فقط می‌گوید کلید امروز چه قدرتی دارد؛ چرخه عمر مشخص می‌کند این قدرت تا چه زمانی و زیر مسئولیت چه کسی باقی می‌ماند.
فهرست دقیق کلیدها واکنش به حادثه را هم سریع می‌کند. وقتی برای هر اعتبارنامه نام، شناسه، هدف، محیط، مالک، سرویس مصرف‌کننده، زمان ساخت و آخرین چرخش ثبت شده باشد، می‌توان فقط همان مسیر مشکوک را قطع کرد. کلید مشترک و بی‌نام برعکس عمل می‌کند: تیم نمی‌داند با لغو آن کدام سرویس می‌خوابد و در نتیجه دسترسی خطرناک دیرتر بسته می‌شود.
کلید API را چطور بسازیم؟
قبل از ورود به پنل صرافی یک قرارداد دسترسی کوتاه بنویس: این کلید برای کدام مسیر کاری است، دقیقاً کدام اندپوینت‌ها لازم‌اند، در چه محیطی استفاده می‌شود، مسئول آن کیست و چه زمانی باید بازبینی شود. سپس فقط دسترسی‌های متناظر با همان قرارداد را روشن کن.
برای ابزار بررسی حساب، دیدن موجودی، مارجین و پوزیشن‌های باز ممکن است لازم باشد؛ ثبت سفارش، انتقال داخلی و برداشت لازم نیست. برای بات اجرایی شاید دسترسی سفارش لازم باشد، اما این نیاز مجوز برداشت را توجیه نمی‌کند. اگر صرافی فهرست IP مجاز دارد و سرویس آدرس خروجی ثابت ارائه می‌دهد، محدودیت IP را فعال کن. کلید محرمانه نباید داخل سورس‌کد، اسکرین‌شات، تیکت پشتیبانی، پیام‌رسان یا رویداد تحلیل داده قرار بگیرد.
در inventory فقط شناسه یا fingerprint را نگه دار، نه خود کلید محرمانه. این کار شناسایی کلید را بدون ساختن یک نسخه قابل سرقت ممکن می‌کند.
تست امن چه چیزهایی را باید ثابت کند؟
ابتدا در محیط آزمایشی یا حساب کم‌ریسک تست کن. یک اندپوینت مجاز را فراخوانی کن و مطمئن شو اطلاعات همان حساب مورد انتظار برمی‌گردد. بعد آزمایش منفی انجام بده: ساخت سفارش، انتقال و برداشت باید شکست بخورند. اگر کلید با برچسب فقط‌خواندنی بتواند سفارش ثبت کند، تست شکست خورده است؛ حتی اگر خواندن موجودی بدون خطا انجام شده باشد.
رفتار مهلت، اختلاف ساعت درخواست، نرخ سقف، تلاش مجدد و حذف کلید محرمانه از لاگ را هم بررسی کن. خطای مبهم نباید به تکرار نامحدود تبدیل شود. نتیجه تست را با شناسه کلید، نسخه نرم‌افزار و زمان ثبت کن، اما مقدار محرمانه یا داده کامل حساب را داخل گزارش نگذار.
بررسی حساب با DRKN را بر پایه حداقل دسترسی شروع کن. مجوز معامله، انتقال، برداشت و حضانت را از مسیر بررسی جدا نگه دار و هر اقدام حساس را خودت در صرافی تأیید کن.
کلید را چه زمانی و چگونه بچرخانیم؟
فاصله چرخش باید با سطح مجوز، محل نگهداری و میزان اکسپوژر متناسب باشد. بعد از احتمال افشا، تغییر نیروی انسانی، پایان همکاری با ارائه‌دهنده، مهاجرت سرور یا مشاهده درخواست ناشناس منتظر تقویم نمان. ابتدا کلید جایگزین را با دسترسی برابر یا محدودتر بساز، آن را فقط روی سرویس هدف deploy کن و سلامت سرویس را بسنج.
در دوره کوتاه هم‌پوشانی، ترافیک هر دو شناسه را ببین. درخواست روی کلید قدیمی بعد از cutover معمولاً یک dependency فراموش‌شده را نشان می‌دهد. وقتی سرویس با کلید جدید پایدار شد، کلید قبلی را لغو کن. باز گذاشتن آن به‌عنوان «پشتیبان» یعنی حفظ یک مسیر اضافی برای حمله.
چه زمانی لغو کلید اجباری است؟
پایان کاربرد، حذف سرویس، تغییر مالک، گم‌شدن دستگاه، انتشار احتمالی در repository یا لاگ، و درخواست‌هایی که توضیح ندارند، همگی شرط لغو هستند. بعد از لغو، فقط به سبز شدن پیام پنل اکتفا نکن؛ یک درخواست کنترل‌شده بفرست و رد شدن کلید را بررسی کن.
نسخه‌های کلید محرمانه را از کلید محرمانه manager، متغیرهای محیطی و تنظیمات استقرار پاک کن. سپس فعالیت حساب، سفارش‌های باز و انتقال‌های اخیر را جداگانه مرور کن، چون لغو کلید سفارش‌هایی را که قبلاً ثبت شده‌اند خودکار خنثی نمی‌کند. برای audit، زمان، شناسه، مالک و علت لغو را نگه دار، نه مقدار کلید محرمانه را.
چک‌لیست عملی چرخه کامل چیست؟
فرض کن تیم می‌خواهد یک داشبورد بررسی ریسک را برای چهارده روز امتحان کند:
1. هدف را «خواندن وضعیت حساب برای بررسی ریسک» بنویس و مالک تعیین کن. 2. کلید اختصاصی با خواندن دسترسی بساز و معامله، انتقال و برداشت را ببند. 3. در صورت امکان IP را محدود و کلید محرمانه را خارج از کد نگهداری کن. 4. یک درخواست خواندن مجاز و یک درخواست معامله غیرمجاز را تست کن. 5. در طول آزمایش، خطای احراز هویت و مبدا ناشناس را پایش کن. 6. روز چهاردهم یا نیاز دائمی و تاریخ چرخش را ثبت کن یا کلید را لغو کن. 7. شکست درخواست بعد از لغو، حذف نسخه‌های runtime و فعالیت حساب را بررسی کن.
این مسیر، عبارت مبهم «اتصال امن» را به مجموعه‌ای از شواهد قابل کنترل تبدیل می‌کند.
DRKN در این چرخه چه جایگاهی دارد؟
پیام محصول باید محدود و دقیق بماند: DRKN برای بررسی حساب باید فقط داده لازم را ببیند و نباید اختیار معامله یا برداشت را بخواهد. این به معنی بی‌خطر بودن داده خواندنی نیست؛ کاربر همچنان باید دامنه دسترسی را در صرافی تأیید، فعالیت حساب را بررسی و در پایان کلید را لغو کند.
در ادامه بخوان: کلید read-only چه داده‌ای افشا می‌کند؟، چرا باید کلید بات و ابزار ریسک جدا باشد و چگونه جلوی سفارش تکراری webhook را بگیریم.
پرسش‌های متداول
کلید API را هر چند وقت یک‌بار بچرخانیم؟
عدد واحدی وجود ندارد. فاصله را با قدرت دسترسی، اکسپوژر و هزینه عملیاتی تعیین کن و بعد از احتمال افشا یا تغییر مالک فوراً بچرخان.
برای چرخش اول کلید قدیمی را حذف کنیم؟
معمولاً یک هم‌پوشانی کوتاه از قطعی جلوگیری می‌کند؛ اما پس از تأیید کلید جدید، قبلی باید سریع لغو شود.
غیرفعال کردن همان لغو دائمی است؟
رفتار صرافی‌ها متفاوت است. بررسی کن کلید غیرفعال دوباره قابل فعال‌سازی هست یا نه و بعد از پایان کاربرد، حذف دائمی را ترجیح بده.
آیا DRKN کلید صرافی من را می‌چرخاند یا لغو می‌کند؟
چنین فرضی نکن. مدیریت اعتبارنامه در پنل صرافی با کاربر است و جایگاه DRKN، بررسی آموزشی و حداقل‌دسترسی است.
منابع
هشدار ریسک: این مطلب آموزش امنیت و مدیریت ریسک است و توصیه مالی، حقوقی یا تضمین امنیت محسوب نمی‌شود. API صرافی‌ها تغییر می‌کند و محتوا پیش از انتشار یا اجرای عملی باید توسط انسان متخصص بازبینی شود.