رفض صارم لمفاتيح API المفعّلة للسحب: الدراسة التقنية العميقة

معظم منصات التداول تقبل مفاتيح API مع تفعيل إذن السحب. تعرض لافتة تحذير صفراء، تطلب منك كتابة "أفهم", وتخزّن المفتاح على أي حال. نحن لا نفعل ذلك. إذا كان مفتاحك يتمتع بإذن السحب، نرفضه أثناء الإعداد ولا نخزّنه أبداً. توضح هذه المقالة السبب والكيفية وما الذي يكلفك هذا البديل فعلاً.

نموذج التهديد في فقرة واحدة

أي نظام يحتفظ بمفتاح API مفعّل للسحب هو نقطة واحدة بعيدة عن تسريب بيانات اعتماديّ واحد قبل تفريغ حسابات المستخدمين. التسريب لا يجب أن يكون خرق قاعدة بيانات — يمكن أن يكون جهاز كمبيوتر موظف مخترق، أو نسخة احتياطية مُعدّة بشكل خاطئ، أو قناة جانبية في تبعية طرف ثالث، أو ملف dump لذاكرة العملية ينتهي به الحال في سجل غير مشفّر. كل واحد من هذه حدث لشركات أكبر منا. الدفاع الوحيد الدائم هو: عدم الاحتفاظ بمفاتيح أموال أي شخص في المقام الأول.

كيفية عمل الكشف

في أول استدعاء مصرّح به بعد لصق المستخدم لمفتاح، نقوم باستدعاء خاص بالبورصة للاستعلام عن الأذونات. معظم الأماكن الرئيسية تكشف إما:

• نقطة نهاية مخصصة "الاستعلام عن معلومات مفتاح API" تُرجع مجموعة الأذونات كحقل منظّم، أو
• نقطة نهاية معلومات الحساب حيث يتم تضمين نطاق إذن المفتاح كجزء من حمل الاستجابة.

نبحث عن أي علم يمنح السحب، أو التحويل الداخلي، أو تحويل الحساب الفرعي للخارج، أو التحويل الشامل للخارج — تستخدم البورصات أسماء مختلفة لنفس الفكرة. إذا كان أي من هذه موجوداً، نتخلى عن السر في الذاكرة فوراً، نُرجع خطأ منظّم للـ UI، ولا نكتب المفتاح أبداً في قاعدة البيانات الخاصة بنا.

لماذا الرفض الصارم بدلاً من التحذير

التحذيرات يتم النقر عليها. راقبنا البيانات على هذا لسنوات عبر منتجات متعددة. معدل القاعدة للمستخدمين الذين يكتبون "أفهم" دون قراءة كلمة واحدة فوقه هو في مكان ما فوق 80%. تحذير يتجاهله 80% من المستخدمين ليس عنصر تحكم أمان؛ إنه درع مسؤولية.

الرفض الصارم هو العكس. يضع الاحتكاك في المكان الصحيح: المستخدم يعود إلى البورصة، ينشئ مفتاح جديد برخصة تداول فقط، يعود، ويلصق هذا. الحلقة كلها تكلف المستخدم حوالي دقيقتين. تكلف المهاجم — في سيناريو تسريب بيانات اعتماديّ أسوأ الحالات — الحساب بأكمله.

ما الذي يكلفك فعلاً مسار التحذير والتخزين

نمط التحذير والتخزين يبدو صديق المستخدم حتى تسأل: ما الذي تبدو عليه أسوأ الحالات؟ تحصل على موظف واحد معادي، أو تسوية في سلسلة التوريد، أو قناة جانبية في تبعية متعدية، أو سجل غير صحيح الحدود، والإجابة هي أن مفاتيح السحب المفعّلة جيدة تماماً مثل أضعف شخص وأضعف قطعة من التعليمات البرمجية التي لمستها على الإطلاق.

الرفض الصارم يقلب هذا الحساب. حتى في حالة خرق قاعدة بيانات كامل في أسوأ الأحوال، المهاجم يمشي بعيداً بمفاتيح قراءة+تداول. مفاتيح التداول فقط يمكنها إحداث أضرار — يمكنها تفجير المراكز، تحريك الرسوم، إغراق المراكز المفتوحة في أزواج غير سائلة — لكنها لا يمكنها السحب. الأموال تبقى على البورصة. هذا ليس خطراً صفراً، لكنه الخطر الذي وافقت عليه عندما وصّلت وكيل تداول آلي في المقام الأول.

ما الذي لا يزال بإمكاننا الدفاع عنه

نحن لا ندّعي أن الرفض الصارم هو موقف أمان كامل. إنه عنصر تحكم واحد. المجموعة الكاملة موثّقة على صفحة الأمان الخاصة بنا: تشفير KMS مع مفاتيح بيانات خاصة بكل مستخدم، أسرار فك تشفيرها تعيش فقط في ذاكرة العملية وفقط لمدة استدعاء API، سجل تدقيق مرتب السلسلة القابل للإضافة فقط، عزل متقاطع تم اختباره في CI، وبرنامج الكشف عن الثغرات. الرفض الصارم لإذن السحب هو مجرد أكثر الأجزاء وضوحاً في هذا الكومة — والأسهل للتحقق منه بنفسك، لأنك يمكنك مشاهدتنا نرفض مفتاح مفعّل للسحب في الوقت الفعلي أثناء الإعداد.