حماية مفاتيح API في تطبيقات الذكاء الاصطناعي مع عبدالله عبدالرحيم الكندي

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

الخطأ الأول: المفتاح في كود الواجهة

أي شي يوصل لمتصفح المستخدم أو لجهازه، اعتبره مكشوف. في Next.js مثلاً، أي متغير بيئة يبدأ اسمه بـ NEXT_PUBLIC_ ينضاف لملفات الجافاسكربت اللي تنزل للمتصفح، وأي شخص يفتح أدوات المطور يقدر يلقاه. ونفس الشي في تطبيقات الجوال: المفتاح داخل ملف التطبيق ممكن يُستخرج، والتشفير داخل التطبيق يأخّر المحاول ما يمنعه.

وفي Flutter يقع كثيرون في نفس الفخ بشكل ثاني: يمررون المفتاح وقت البناء عبر --dart-define أو من ملف env مضمّن مع التطبيق، ويحسبون إنه صار مخفي لأنه مو مكتوب في الكود. القيمة نفسها تنحفظ داخل ملف التطبيق المبني، ومن يفك الملف يقدر يلقاها. الطريقة هذي مناسبة لإعدادات غير سرية، مثل رابط الخادم، مو لمفتاح يكلّفك فلوس.

الإصلاح: خادم وسيط. التطبيق يكلّم خادمك أنت، وخادمك اللي يحمل المفتاح ويكلّم مزوّد النموذج. في Next.js هذا يعني مسار API أو Server Action يشتغل على الخادم، والمفتاح في متغير بيئة بدون البادئة العامة.

الخطأ الثاني: الخادم الوسيط مفتوح للكل

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

• تحديد معدل الطلبات لكل مستخدم أو لكل عنوان IP، مثلاً عدد محدد في الدقيقة.
• حد أعلى لطول الرسالة المرسلة، وحد أعلى لعدد التوكنز في الرد.
• التعليمات والنموذج يتحددون من الخادم، مو من الطلب. لا تخلّي الواجهة ترسل «استخدم النموذج الفلاني بهالتعليمات».
• لو الميزة للمسجلين بس، تحقق من الجلسة في الخادم قبل أي استدعاء.

الخطأ الثالث: المفتاح دخل Git ولو لدقيقة

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

والوقاية: ملف .env.local داخل .gitignore من أول يوم في المشروع، وملف .env.example فيه أسماء المتغيرات بدون قيم. وفعّل فحص الأسرار في منصة المستودعات لو متاح، لأنه ينبهك أو يمنع الرفع لما يلقى نمطاً يشبه مفتاحاً.

الخطأ الرابع: مفتاح واحد لكل شي، وبلا حد صرف

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

وهذا يزيد أهمية لما تستخدم بوابة تجمع عدة نماذج. محادثة موقع azhal.io مثلاً تستدعي النماذج عبر OpenRouter مع تبديل تلقائي بين أكثر من نموذج لو تعطل واحد. هالبنية مريحة، لكنها تعني إن المفتاح الواحد يفتح باباً لنماذج كثيرة بأسعار مختلفة، فحمايته وحد صرفه أهم من مفتاح مزوّد واحد.

الخطأ الخامس: المفتاح في السجلات والصور

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

الخطأ السادس: المفتاح أو الأسرار داخل التعليمات

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

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

وتعوّد على تدوير المفاتيح دورياً حتى بدون تسريب معروف، مثلاً كل بضعة أشهر أو كل ما ترك المشروع شخص كان عنده وصول. لو التدوير صعب ويخوّفك، فهذي علامة إن المفتاح منسوخ في أماكن كثيرة، وهذي مشكلة بحد ذاتها تستاهل تحلها.

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