يُجرِّد Keychain خلفية التوقيع، غير أن تشغيل الموقِّع في بيئة الإنتاج يظل مسؤوليتك. تنطبق هذه الممارسات على جميع الخلفيات؛ راجع اختيار خلفية للتعرف على كيفية الاختيار.
فصل الموقِّعات الساخنة عن الباردة
استخدم موقِّعًا تشغيليًا برصيد منخفض ("ساخن") للمعاملات المتكررة والآلية، وموقِّعًا منفصلًا بقيمة عالية ("باردًا") لتحركات الخزينة. اعتمد على حضانة MPC أو HSM سحابي للموقِّع البارد، واشترط سياسات موافقة قبل أن يُوقِّع. ولأن الواجهة متطابقة، يمكن لكل دور استخدام خلفية مختلفة دون تغيير مواقع الاستدعاء.
تدوير المفاتيح بشكل متعمد
في سولانا، مفتاح التوقيع هو عنوان الحساب، لذا فإن تدوير المفتاح ينتج عنوانًا جديدًا. خطِّط للتدوير بوصفه عملية ترحيل: أنشئ مفتاحًا جديدًا، وأعد تعيين الصلاحيات ذات الصلة (أو انقل الأموال) إلى العنوان الجديد، ثم أوقف العمل بالقديم. استخدم مفاتيح مميزة لكل بيئة حتى لا تُعاد استخدام مفاتيح devnet على الشبكة الرئيسية.
منح أقل صلاحية وصول
حدِّد نطاق بيانات اعتماد كل خلفية بالحد الأدنى اللازم للتوقيع. بالنسبة إلى AWS KMS،
فهذه الصلاحيات هي kms:Sign وkms:DescribeKey وkms:GetPublicKey على المفتاح المحدد
(يستخدم فحص التوافر الصلاحيتين الأخيرتين)؛ ويُفضَّل استخدام أدوار IAM بدلاً من
بيانات الاعتماد الثابتة. وطبّق المبدأ نفسه على سياسات Vault ومفاتيح واجهة برمجة التطبيقات
الخاصة بالمحافظ المُدارة.
التخطيط للتوافر
تعتمد الخلفيات البعيدة على خدمة شبكية. تحقق من التوافر قبل الاعتماد
على جهة التوقيع (isAvailable() في TypeScript، وis_available() في Rust وPython،
وIsAvailable(ctx) في Go)، وأعد محاولة حالات الفشل الخاصة بالتوقيع فقط مع التراجع التدريجي، وحدِّد
مسارًا بديلًا لحالات الانقطاع. لا تعِد المحاولة بشكل أعمى مع خلفية تقوم بالبث
(Crossmint، ووضع Fordefi الأصلي التلقائي): راجع
التعامل مع عمليات البث غير المؤكدة. يفرض Keychain
استخدام HTTPS على عناوين URL الأساسية المهيّأة، ويرفض عمليات إعادة التوجيه، ويطبّق مهلة
افتراضية للطلبات.
التعامل مع عمليات البث غير المؤكدة
يقوم كل من Crossmint ووضع Fordefi الأصلي التلقائي بالتوقيع والبث من جهة الخادم، لذا فإن
فشل الاستدعاء لا يعني أن شيئًا لم يصل. عندما يكون المزوّد قد قبل
المعاملة، يُبلغ Keychain عن BROADCAST_UNCONFIRMED
(SignerError::BroadcastUnconfirmed في Rust). يحمل الخطأ معرّف معاملة
المزوّد عند قبول عملية الإنشاء، ويحمل دائمًا مفتاح
عدم التكرار (idempotency key) الذي أُرسل به طلب الإنشاء، والمشتق من الرسالة.
- قم بالمطابقة مع المزوّد باستخدام معرّف المعاملة قبل فعل أي شيء آخر.
- إعادة إرسال المعاملة المطابقة بايتًا ببايت آمنة: فمفتاح عدم التكرار يمنع تكرارها.
- إعادة بناء المعاملة (باستخدام blockhash جديد مثلًا) تنتج مفتاحًا جديدًا وبالتالي تحويلًا جديدًا.
حماية الأسرار والنقل
- تفرض الخلفيات البعيدة استخدام HTTPS على عناوين URL الأساسية المهيّأة وترفض عمليات إعادة التوجيه.
الاستثناء الوحيد هو Vault، الذي يقبل HTTP العادي على loopback كي يعمل الأمر المحلي
vault server -dev. - أمدَّ مفاتيح API والرموز المميزة وبيانات الاعتماد من مدير أسرار أو متغيرات بيئية — لا تُضمِّنها في الكود مباشرةً ولا تُودِعها في نظام التحكم بالإصدار.
- يُعقِّم Keychain استجابات الأخطاء لتفادي تسريب الأسرار إلى السجلات؛ احرص على أن تخلو سجلاتك من بيانات الاعتماد الخام ومواد المفاتيح.
مراقبة عمليات التوقيع وتدقيقها
تتبَّع معدل نجاح التوقيع والكمون وأعداد الأخطاء، ونبِّه عند الارتفاعات المفاجئة — راجع المقاييس في جاهزية الإنتاج. فعِّل سجلات التدقيق على جانب المزود (KMS أو Vault أو جهة الحضانة) وطابقها مع المعاملات التي تُرسلها تطبيقاتك.
اعرف ما الذي يتحقق منه Keychain
- يتحقق Keychain من مرحلة التوقيع، لا من معاملتك: فلا توجد محاكاة، ولا فحص لمحتوى المعاملة، ولا محرك سياسات. طبّق هذه الأمور في تطبيقك أو عبر ضوابط السياسات لدى المزوّد.
- يعيد وضع Fordefi الأصلي اليدوي كتابة المعاملة (blockhash، وتعليمات رسوم Compute Budget) قبل توقيعها. تابع من المعاملة التي يعيدها، وليس تلك التي أرسلتها، ونفّذه قبل أي جهة توقيع أخرى.
- يقوم Rust بتصفير مخازن المفاتيح الوسيطة (zeroize)، بينما لا تستطيع Python وGo ذلك. عند استخدام خلفية Memory في هاتين اللغتين، عامِل ذاكرة العملية بالكامل على أنها حساسة.
- مع Ledger، تُعد شاشة الجهاز الوصف الوحيد الموثوق لما
يجري توقيعه. لا تفعّل الميزة
unsafe-debugولا التسجيلTRACEلـsolana_remote_walletفي بيئة الإنتاج، لأن كليهما يسجّل تفاصيل الجهاز والمعاملة.
راجع نموذج الأمان للاطلاع على الصورة الكاملة.
Is this page helpful?