عندما ينتحل وكيل الذكاء الاصطناعي هويتك: الاعتمادات الموروثة تخلط بين الإنسان والآلة

عندما يستخدم وكيل ذكاء اصطناعي اعتماد مستخدم بشري للوصول إلى قواعد البيانات، لا يحصل النظام على «هوية وكيل» مخفية خلف الحساب؛ بل يرى المستخدم نفسه. هذا هو الاستنتاج المركزي من قياس أجراه Naseeb Ahmed Mian على بيئة إنتاج تستخدم Azure وAzure CLI وsqlcmd.

في الإعداد محل الفحص، كانت مهارات الوكيل البرمجية تتصل بقواعد البيانات عبر الأمر sqlcmd باستخدام المصادقة من خلال Azure CLI. يستخرج الأمر رمز الوصول المخزن مؤقتاً بعد تسجيل دخول المستخدم، ثم يقدمه إلى قاعدة البيانات. ونتيجة لذلك، ظهرت الاتصالات باسم المستخدم، مع اسم جهازه وأداة sqlcmd، سواء كتب الاستعلام بنفسه أم نفذه الوكيل.

سجل التدقيق يرى الاعتماد ولا يرى النية

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

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

ماذا يكشف رمز الوصول؟

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

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

العضوية في المجموعات توسّع الصورة

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

تكمن الخطورة في أن هذه العضويات قد تحمل الصلاحيات الفعلية في طبقة البيانات، ولا تظهر بالضرورة في فحوص أدوار طبقة التحكم. لذلك قد يبدو نطاق وصول الوكيل محدوداً عند مراجعة الطريقة التقليدية، بينما تمنحه عضوية المجموعات قدرة أكبر.

ما الذي يتغير عملياً؟

عند اختبار الهوية نفسها على مخزنين إنتاجيين بفارق ساعة، ظهرت نتيجتان متباينتان بشدة. في أحدهما امتلكت الهوية صلاحيتَي CONNECT وSELECT فقط، ولم تتمكن من الاتصال بالطبقة الآمنة. أما نقطة تحليلات إنتاجية أخرى فأظهرت 430 جدولاً و107 صلاحيات شملت القراءة والكتابة وتعريف المخطط وإدارة قاعدة البيانات.

توضح المقارنة أن نطاق الصلاحيات لا تحدده الهوية وحدها؛ فمسار الوصول والمحرك والضوابط المرتبطة بنقطة النهاية عوامل حاسمة أيضاً. وقد تكون نقطة نهاية للقراءة فقط وفق توثيقها، بينما لا تنتقل قواعدها الأمنية بالضرورة عندما تُستدعى البيانات عبر محرك آخر.

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