يقود الذكاء الاصطناعي تحولًا هائلًا في إنتاجية المؤسسات، بدءًا من إكمال الأكواد في “GitHub Copilot” وصولًا إلى روبوتات الدردشة التي تستخرج الإجابات الفورية من قواعد المعرفة الداخلية. يحتاج كل عميل جديد إلى المصادقة على الخدمات الأخرى، مما يزيد بصمت من أعداد الهويات غير البشرية (NHIs) عبر السحابات المؤسسية.
لقد أصبح هذا العدد كبيرًا لدرجة تعجز المؤسسات عن إدارته: فالكثير من الشركات تتعامل الآن مع 45 هوية آلية على الأقل لكل مستخدم بشري. تحتاج حسابات الخدمة، وروبوتات التكامل والنشر المستمر (CI/CD)، والحاويات، وعملاء الذكاء الاصطناعي إلى أسرار، غالبًا ما تكون على شكل مفاتيح واجهة برمجة التطبيقات (API)، أو رموز (Tokens)، أو شهادات (Certificates)، للاتصال الآمن بالأنظمة الأخرى. يكشف تقرير “GitGuardian” لعام 2025 عن انتشار الأسرار أن أكثر من 23.7 مليون سرّ ظهرت على “GitHub” العام الماضي وحده. والأسوأ أن المستودعات التي تعمل بـ”Copilot” تسربت فيها الأسرار بنسبة 40% أكثر.
الهويات غير البشرية ليست أشخاصًا
على عكس المستخدمين البشريين، نادرًا ما تُفرض سياسات على الهويات غير البشرية لتغيير بيانات الاعتماد بانتظام، أو تقييد الصلاحيات بدقة، أو إيقاف الحسابات غير المستخدمة. وعند إهمال إدارتها، تنسج هذه الهويات شبكة معقدة وخطرة من الاتصالات التي يمكن للمهاجمين استغلالها حتى بعد نسيان وجود تلك الأسرار.
يزيد تبني الذكاء الاصطناعي، وخاصة نماذج اللغة الكبيرة (LLMs) والجيل المعزز بالاسترجاع (RAG)، من سرعة وحجم هذا الانتشار الخطير.
تخيل روبوت دعم داخلي يعمل بنموذج لغة كبير. عند سؤاله عن كيفية الاتصال ببيئة تطوير، قد يسترجع صفحة “Confluence” تحتوي على بيانات اعتماد صالحة. يمكن للروبوت أن يكشف الأسرار دون قصد لأي شخص يطرح السؤال المناسب، وقد تسجل السجلات هذه المعلومات وتكشفها لمن لديه صلاحية الوصول. الأسوأ أن النموذج قد يوجه المطورين لاستخدام بيانات الاعتماد هذه مباشرة، مما يزيد المشكلات الأمنية تعقيدًا.
لكن الوضع ليس ميؤوسًا منه. في الواقع، إذا تم تطبيق نماذج حوكمة مناسبة لإدارة الهويات غير البشرية والأسرار، يمكن للمطورين الابتكار والنشر بسرعة أكبر.
خمس ضوابط عملية لتقليل مخاطر الهويات غير البشرية المرتبطة بالذكاء الاصطناعي
ينبغي للمؤسسات التي تسعى للتحكم في مخاطر الهويات غير البشرية المعززة بالذكاء الاصطناعي التركيز على هذه الممارسات العملية:
-
مراجعة وتنظيف مصادر البيانات
-
توحيد إدارة الهويات غير البشرية الحالية
-
منع تسرب الأسرار في عمليات نشر نماذج اللغة الكبيرة
-
تحسين أمان السجلات (Logging)
-
تقييد وصول الذكاء الاصطناعي إلى البيانات
لنلقِ نظرة فاحصة على كل منها.
1. مراجعة وتنظيف مصادر البيانات
كانت نماذج اللغة الكبيرة الأولى مقيدة بمجموعات البيانات التي دُرّبت عليها فقط، مما جعلها أدوات محدودة الإمكانيات. غيرت تقنية “الجيل المعزز بالاسترجاع” (RAG) هذا الواقع بتمكين النماذج من الوصول إلى مصادر بيانات إضافية عند الحاجة. لسوء الحظ، إذا كانت هذه المصادر تحتوي على أسرار، تصبح الهويات المرتبطة بها عرضة للاستغلال.
لم تُصمم منصات مثل “Jira” أو “Slack” أو “Confluence” بحيث تتنبه للذكاء الاصطناعي أو الأسرار. إذا أضاف أحدهم مفتاح واجهة برمجة تطبيقات (API) كنص عادي، لن ينبهه النظام إلى خطورة ذلك. يمكن لروبوت الدردشة أن يتحول بسهولة إلى أداة لتسريب الأسرار إذا تلقى الأوامر المناسبة.
الطريقة الوحيدة الفعالة لمنع نموذجك من تسريب الأسرار هي إزالتها من المصادر أو إبطال صلاحياتها. لا يشكل المفتاح الملغى أي خطر فوري. من الأفضل حذف هذه الأسرار تمامًا قبل أن يتمكن الذكاء الاصطناعي من استردادها. لحسن الحظ، توجد أدوات مثل “GitGuardian” لتبسيط هذه العملية.
2. توحيد إدارة الهويات غير البشرية الحالية
كما قال اللورد كلفن: “إذا لم تستطع قياس شيء، فلن تستطيع تحسينه”. ينطبق هذا تمامًا على حوكمة الهويات غير البشرية. دون حصر جميع حسابات الخدمة والروبوتات والأنابيب (Pipelines) الحالية، يصعب تطبيق قواعد فعالة على الهويات الجديدة المرتبطة بالذكاء الاصطناعي.
تشترك جميع هذه الهويات في شيء واحد: لديها “سر”. سواء كانت حسابات خدمة أو روبوتات، فإن آلية المصادقة واحدة: السر. عند إدارة المخزون عبر هذا المنظور، نركز على التخزين الآمن للأسرار، وهي مشكلة ليست جديدة.
توجد أدوات مثل “HashiCorp Vault” و”CyberArk” و”AWS Secrets Manager” لتحقيق ذلك. بمجرد توحيد إدارتها، يمكن الانتقال من عالم الاعتماد على بيانات اعتماد طويلة الأجل إلى نظام يتم فيه تدوير الأسرار آليًا وفقًا للسياسات.
3. منع تسرب الأسرار في عمليات نشر نماذج اللغة الكبيرة
أصبحت خوادم “بروتوكول سياق النموذج” (MCP) المعيار الجديد لوصول الذكاء الاصطناعي إلى الخدمات ومصادر البيانات. في السابق، كان على المطورين تهيئة الاتصالات يدويًا، مما زاد من احتمالية تضمين الأسرار في الأكواد. يُقلل MCP هذا الخطر بتبسيط الاتصال عبر واجهة موحدة.
لكن في ورقة بحثية صادمة من “GitGuardian”، وُجد أن 5.2% من خوادم MCP تحتوي على سرّ واحد على الأقل مُدرج مباشرة في الكود، وهي نسبة أعلى من المتوسط العام لتسرب الأسرار (4.6%).
يكمن الحل في كشف الأسرار مبكرًا في دورة حياة التطوير. يمكن لفحص الأكواد في مرحلة “الفروع” (Branches) أو عبر أدوات المطورين منع تسرب البيانات قبل وصولها إلى المستودعات المشتركة.
4. تحسين أمان السجلات
نماذج الذكاء الاصطناعي صناديق سوداء تقدم إجابات احتمالية. لتطويرها، يسجل المهندسون كل شيء: المدخلات، والسياق المسترجع، والإجابات. لكن إذا تسرب سرّ في أي خطوة، فقد يتكرر في السجلات، التي تُخزن غالبًا في سحابات غير مؤمنة جيدًا.
