اكتشف الباحث الأمني Frank Chu أن خدمة tl;dv — وهي خدمة لتدوين ملاحظات الاجتماعات مدعومة بالذكاء الاصطناعي وتتكامل مع Zoom و Teams — قد سربت 181,874 نصاً خاصاً للاجتماعات بسبب فقدان قاعدة أمان واحدة في Firebase، مما سمح لأي مستخدم مسجل الدخول بقراءة مجموعة السجلات بأكملها. طال الخرق 84,312 مستخدماً عبر 35,003 نطاقاً، وهو ما يعد تذكيراً بأن خطأً بسيطاً في الإعدادات يمكن أن يكشف أكثر المحادثات المؤسسية سرية.

كيف حدث التسريب

تخزن tl;dv الملاحظات في قاعدة بيانات Firestore التابعة لـ Google Firebase. في Firestore، يكتب المطورون قواعد أمان تحدد من يمكنه قراءة أو كتابة كل مستند. كانت معظم مجموعات (collections) tl;dv مغلقة بشكل صحيح، لكن مجموعة meetings افتقرت إلى قاعدة تتحقق من هوية مقدم الطلب. كانت النتيجة بسيطة: بمجرد تسجيل دخول المستخدم إلى التطبيق، تعيد واجهة برمجة التطبيقات (API) قائمة بكل مستند اجتماع مخزن بواسطة الخدمة.

لم يكن هناك استغلال معقد، ولا حمولة ضارة (malicious payload)، ولا اختراق لنموذج الذكاء الاصطناعي الأساسي. كان الضعف عبارة عن سهو كلاسيكي في التحكم في الوصول — سطر برمجي مفقود كان يجب أن يقول: "يمكن فقط للمالك أو المشاركين المدعوين عرض هذا الاجتماع". وبسبب فقدان القاعدة، تمكن أي مستخدم موثق من حصر وتنزيل كل نص، بغض النظر عن حالة الدعوة.

لماذا يهم هذا الأمر

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

التأخر في الاستجابة

أبلغ Chu فريق tl;dv عن القاعدة المفقودة في يناير. ولم يتم تطبيق الإصلاح — إضافة قيود القراءة المناسبة وإعادة نشر مجموعة القواعد — حتى أغسطس. إن الفجوة التي استغرقت ستة أشهر بين الاكتشاف والمعالجة تعتبر طويلة بشكل غير معتاد لثغرة تمنح وصولاً غير مقيد للقراءة للبيانات الحساسة. يسلط هذا التأخير الضوء على الفجوات في عملية إدارة الثغرات الأمنية في الشركة، بدءاً من التصنيف (triage) وصولاً إلى نشر التصحيحات (patch deployment).

درس أوسع للوكلاء المدفوعين بالذكاء الاصطناعي

غالباً ما يتم تأطير الحادثة على أنها "خطر ذكاء اصطناعي"، ومع ذلك فإن السبب الجذري هو خطأ تقليدي في التحكم في الوصول. يعمل وكلاء الذكاء الاصطناعي — سواء كانوا يفرغون الاجتماعات، أو يصيغون رسائل البريد الإلكتروني، أو يلخصون المستندات — بصلاحيات حساب الخدمة (service-account privileges) التي تسمح لهم بالوصول إلى نفس البيانات التي يصل إليها المستخدم البشري. عندما تكون هذه الصلاحيات واسعة للغاية، يصبح الذكاء الاصطناعي قناة لتسريب البيانات بسهولة مثل أي خدمة خلفية (backend service) أخرى.

ما يمكن للمؤسسات فعله اليوم

  • تدقيق منطق التفويض – التحقق من أن كل مجموعة قاعدة بيانات، أو نقطة نهاية API، أو حاوية تخزين سحابية تستخدمها أداة ذكاء اصطناعي تفرض فحوصات الحد الأدنى من الامتيازات (least-privilege). ابحث عن القواعد المفقودة أو المفرطة في السماحية مثل تلك التي تسللت في tl;dv.
  • تحديد نطاق التسجيل – تهيئة وكيل تدوين الملاحظات لالتقاط الاجتماعات التي تأذن بها صراحة فقط. إن إعداد التسجيل التلقائي يوسع سطح الهجوم؛ بينما تحافظ نماذج الاشتراك الاختياري (opt-in) على ضيق نطاق التعرض.
  • التعامل مع وكلاء الذكاء الاصطناعي كحسابات خدمة – فهرسة كل تكامل للذكاء الاصطناعي من طرف ثالث، وتخصيص هوية مخصصة له، ومنحه فقط الأذونات التي يحتاجها لأداء وظيفته. راجع واحذف الحسابات غير المستخدمة بانتظام.
  • اختبار قواعد الأمان تحت الضغط – تشغيل اختبارات مؤتمتة تحاول قراءة البيانات من المجموعات دون بيانات اعتماد مناسبة. قم بتضمين هذه الفحوصات في خطوط أنابيب CI/CD بحيث يتم اكتشاف القاعدة المفقودة قبل النشر.
  • تسريع الاستجابة للحوادث – وضع جداول زمنية واضحة للإقرار بالثغرات الأمنية المبلغ عنها وتصنيفها ومعالجتها. إن فترة المعالجة التي استغرقت ستة أشهر، كما رأينا هنا، هي فشل في العمليات يمكن أن يضاعف من تأثير خطأ برمجي بسيط.

ما يجب مراقبته لاحقاً

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

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