Claude Code يُبقي مفاتيح Datadog بعيدًا عن متناول الوكيل: الخادم الوكيل يضيف الرمز بنفسه

موقف مألوف: تريد من الوكيل أن يدخل إلى Datadog بنفسه، ويحلل التنبيهات، ويبحث عن سبب التعطل. أسهل طريقة هي وضع مفتاح API في متغير بيئة. تعمل هذه الطريقة فورًا، وتتحول بالسرعة نفسها إلى مشكلة أمنية.

ينقل منشور للحساب @timwork_notes تصريحًا أدلت به كات وو، التي تعمل على Claude Code، لسايمون ويليسون، مفاده أن بيانات اعتماد Datadog «متاحة لاستخدام الوكيل وحده، لكنها غير متاحة للوكيل نفسه». تبدو العبارة متناقضة، لكن وراءها فكرة هندسية بسيطة. وهناك تحفظ مهم: المتاح لدينا مجرد ملخص قصير للمحادثة، من دون تفاصيل التنفيذ. لذلك نناقش هنا النمط المعماري نفسه، لا إعدادًا داخليًا بعينه.

لماذا يشكّل وجود المفتاح بصورته الأصلية في البيئة خطرًا

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

يصوغ كاتب المنشور المسألة بوضوح حاد: وجود المفتاح بصورته الأصلية في بيئة الوكيل يعني أنه «لا يفصله عن التسريب سوى تعليمة محقونة واحدة». يصعب الاعتراض على ذلك. فالاعتماد على تعليمات مثل «لا تعرض المفاتيح أبدًا» ليس حماية موثوقة؛ إنه طلب، وليس حاجزًا.

كيف تعمل آلية الخادم الوكيل

الفكرة هي ألا يكون السر في حوزة الوكيل أصلًا. وبدلًا من ذلك، يحصل الوكيل على إمكانية الوصول إلى Datadog عبر خادم وكيل وسيط.

إليك مثالًا بسيطًا. يريد الوكيل جلب مقاييس خدمة ما، فيرسل طلبًا إلى عنوان الخادم الوكيل بلا أي رمز، أو بقيمة وهمية. يتحقق الخادم الوكيل، الذي يعمل خارج البيئة المعزولة للوكيل، من أن الطلب مسموح به، ثم يضيف الرمز الحقيقي إلى أحد ترويسات الطلب ويمرره إلى Datadog. وتعود الاستجابة إلى الوكيل. طوال هذه العملية، يبقى السر الحقيقي داخل عملية الخادم الوكيل وحدها.

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

ما الذي يمكن فعله عمليًا

يمكن تطبيق هذا النمط من دون أدوات خاصة:

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

القيود

الخادم الوكيل لا يحل كل شيء. ما دام الوكيل يملك إمكانية الوصول إلى API عبره، فقد تدفعه عملية حقن تعليمات إلى تنفيذ إجراءات مسموح بها، مثل قراءة سجلات حساسة ونقل محتواها إلى الخارج. لذلك يعمل الخادم الوكيل إلى جانب الصلاحيات المحدودة وضبط حركة البيانات الصادرة، ولا يحل محلهما.

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

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