أبلغت Braintrust، وهي شركة ناشئة متخصصة في تقييم الذكاء الاصطناعي وتستخدمها فرق هندسية تبني منتجات ذكاء اصطناعي، العملاءَ بضرورة إبطال واستبدال مفاتيح واجهة برمجة التطبيقات المخزنة على منصتها بعد حادث أمني شمل أحد حساباتها السحابية على Amazon Web Services.
وبحسب TechCrunch، أكدت الشركة وجود «وصول غير مصرح به» إلى حساب على AWS كان يحتوي على مفاتيح واجهة برمجة التطبيقات الخاصة بالعملاء والمستخدمة للوصول إلى نماذج ذكاء اصطناعي قائمة على السحابة. وقالت Braintrust إنها تواصلت مع أحد العملاء المتأثرين ولم تجد في وقت إخطار العملاء أدلة على تعرض أوسع.
كما كشفت الشركة عن الحادث في مركز الثقة لديها، وقالت إنها احتوت المشكلة، وأغلقت الحساب المخترق، وقيّدت الوصول عبر الأنظمة ذات الصلة، ودوّرت الأسرار الداخلية.
الدرس المفيد ليس أن شركة ناشئة واحدة في مجال الذكاء الاصطناعي تعرضت لحادث أمني. بل إن البنية التحتية للذكاء الاصطناعي تعتمد الآن على سلاسل من الثقة يسهل الاستهانة بها.
قد يستدعي المنتج OpenAI أو Anthropic أو Google أو Mistral أو AWS أو Azure أو أدوات المراقبة أو قواعد البيانات المتجهة أو منصات التقييم أو خدمات التكامل والنشر المستمر أو الأنظمة الإدارية الداخلية. وكل اتصال من هذه الاتصالات قد يعتمد على سر. وإذا كانت هذه الأسرار مخزنة بشكل سيئ، أو ممنوحة صلاحيات زائدة، أو نادرة التدوير، أو موزعة عبر عدد كبير جدًا من الأدوات، يصبح المنتج أكثر هشاشة مما يبدو.
بالنسبة إلى المطورين، لم تعد مفاتيح واجهة برمجة التطبيقات تفصيلة صغيرة تخص المطورين فقط. إنها جزء من المحيط الأمني.
ماذا حدث
ذكرت TechCrunch أن Braintrust أرسلت إلى العملاء رسالة إلكترونية تطلب من كل عميل تدوير مفاتيح واجهة برمجة التطبيقات المخزنة لدى الشركة. وشمل الحادث أحد حسابات Braintrust السحابية على AWS، والذي كان يحتوي على مفاتيح يستخدمها العملاء للوصول إلى نماذج ذكاء اصطناعي قائمة على السحابة.
وقال المتحدث باسم Braintrust مارتن بيرغمان لـ TechCrunch إن الشركة أرسلت الرسالة «من باب الحيطة والحذر» وأضاف أن Braintrust أكدت وقوع حادث أمني لكنها لم تكن تملك أدلة على اختراق في وقت التصريح.
وتلك الصياغة مهمة. فالحوادث الأمنية غالبًا ما تمر بمراحل: نشاط مريب، ثم وصول غير مصرح به مؤكد، ثم الاحتواء، ثم التحقيق، ثم إخطار العملاء، ثم المعالجة، ثم المراجعة النهائية لما بعد الحادث. وعادة ما تكون الحقائق المبكرة محدودة.
لكن بالنسبة إلى العملاء، فإن الاستجابة العملية بسيطة: دوّروا الأسرار المكشوفة أو التي ربما تكون قد كُشفت قبل أن يتمكن شخص آخر من استخدامها.
ولهذا السبب طلبت Braintrust من العملاء استبدال المفاتيح.
لماذا مفاتيح واجهة برمجة التطبيقات قوية
مفتاح واجهة برمجة التطبيقات ليس مجرد كلمة مرور بصيغة مختلفة. ففي كثير من الأنظمة، هو بيانات الاعتماد التي تسمح للبرنامج بالتصرف.
وباستخدام المفتاح الصحيح، يمكن للنظام استدعاء نموذج، أو الوصول إلى بيانات، أو تشغيل تدفقات عمل، أو استهلاك موارد سحابية، أو قراءة السجلات، أو التفاعل مع البنية التحتية للإنتاج. وإذا سُرق هذا المفتاح، فقد لا يحتاج المهاجم إلى اختراق النظام الرئيسي للعميل. فالمفتاح قد يسمح له بأن يبدو شرعيًا.
وقد أوضحت TechCrunch هذه النقطة بجلاء: غالبًا ما يستهدف المهاجمون حسابات السحابة المؤسسية والمنصات الخارجية، لأن سرقة الأسرار يمكن أن تمنحهم وصولًا من دون اختراق أنظمة الشركة المستهدفة نفسها مباشرة.
وهذا ما يجعل مفاتيح واجهة برمجة التطبيقات خطيرة جدًا عندما يُتعامل معها باستخفاف.
فالمفتاح المسرب قد يؤدي إلى كشف بيانات، أو تضخم فواتير السحابة أو النماذج، أو إساءة استخدام النموذج، أو اختراق العملاء، أو وصول أعمق إذا كان السر نفسه يتمتع بصلاحيات واسعة. وفي منتجات الذكاء الاصطناعي، قد يكون الخطر أوسع لأن المفاتيح قد تتصل بمزودي النماذج، ومجموعات بيانات العملاء، وسجلات المطالبات، ومخرجات التقييم، والأدوات الداخلية.
مشكلة المخاطر الخاصة بالأطراف الثالثة
تصف Braintrust نفسها بأنها منصة للمهندسين الذين يبنون برمجيات ذكاء اصطناعي. وقد وصفها مؤسسها والرئيس التنفيذي، أنكور غويال، سابقًا لـ TechCrunch بأنها «نظام تشغيل للمهندسين الذين يبنون برمجيات ذكاء اصطناعي».
وهذه المكانة بالذات هي ما يجعل الحادث مهمًا.
فرق الذكاء الاصطناعي الحديثة نادرًا ما تبني كل شيء بنفسها. بل تقوم بتركيب الأدوات معًا. منصة تفحص المخرجات. وأخرى تخزن التمثيلات المتجهة. وأخرى تسجل المطالبات. وأخرى تستضيف النماذج. وأخرى تدير النشر. وأخرى تدير دعم العملاء. وهذا فعال، لكنه يوزع الثقة على عدد كبير من الموردين.
وعندما يخزن أحد الموردين أسرار العملاء، يصبح هذا المورد جزءًا من الحدود الأمنية للعميل.
وقال جايمي بلاسكو، المؤسس المشارك في Nudge Security، لـ TechCrunch إن الحادث قد تكون له «آثار لاحقة على العملاء المتأثرين»، بما في ذلك شركات الذكاء الاصطناعي التي تعتمد على Braintrust.
وهذه هي العبارة التي ينبغي للمطورين التوقف عندها: الآثار اللاحقة.
فخرق أداة واحدة يمكن أن ينتقل عبر كامل البنية. وقد يؤثر في الوصول إلى النماذج، وبيانات العملاء، والتعرض في الفواتير، والعمليات الداخلية في أماكن أخرى. وكلما أصبحت البنية أكثر ترابطًا، أصبحت أمنية الموردين أكثر أهمية.
ماذا يجب أن يتعلمه منشئو الذكاء الاصطناعي من هذا
الدرس ليس تجنب الأدوات الخارجية. فهذا غير واقعي. فالشركات الناشئة تستخدم منصات خارجية لأنها تحتاج إلى السرعة والموثوقية والقدرات المتخصصة.
الدرس هو التصميم على أساس احتمال الفشل.
افترض أن موردًا قد يتعرض للاختراق. وافترض أن مهندسًا قد يكشف سرًا عن طريق الخطأ. وافترض أن مفتاحًا قد يُنسخ. وافترض أن حسابًا سحابيًا قد يصل إليه الشخص الخطأ. ثم ابنِ أنظمة تحد من مدى انتشار الضرر.
القاعدة الأولى هي أقل قدر من الصلاحيات. يجب ألا يملك المفتاح إلا الوصول الذي يحتاجه. فإذا كان المفتاح مخصصًا فقط لاستدعاء نموذج معين، فلا ينبغي أن يملك أيضًا وصولًا واسعًا إلى أنظمة لا علاقة لها بذلك.
القاعدة الثانية هي التدوير. يجب أن تكون الأسرار قابلة للاستبدال من دون فوضى. وإذا كان تدوير مفتاح يربك المنتج ليوم كامل، فالمشكلة في العملية نفسها.
القاعدة الثالثة هي الفصل. يجب ألا تكون مفاتيح الإنتاج ومفاتيح التطوير والمفاتيح الخاصة بالعملاء ومفاتيح الأدوات الداخلية كلها في المكان نفسه وبنمط الوصول نفسه.
القاعدة الرابعة هي الرؤية. يجب أن تعرف الفرق ما هي المفاتيح الموجودة، وأين تُخزَّن، ومن يستطيع الوصول إليها، ومتى استُخدمت آخر مرة، وما إذا كان الاستخدام قد تغير فجأة.
القاعدة الخامسة هي مراجعة الموردين. قبل تخزين أسرار العملاء لدى أداة خارجية، ينبغي للفرق طرح أسئلة صعبة حول التشفير، وضبط الوصول، وسجلات التدقيق، والاستجابة للحوادث، وعزل المفاتيح، وإخطار العملاء.
لا شيء من هذا براق. لكنه العمل الذي يحافظ على بقاء المنتج عندما يحدث خطأ ما.
زاوية الشركات الناشئة الأفريقية
بالنسبة إلى الشركات الناشئة الأفريقية في مجال الذكاء الاصطناعي، يستحق حادث Braintrust الانتباه لأن كثيرًا من الفرق تبني بسرعة فوق بنى تحتية عالمية.
قد تستخدم شركة ذكاء اصطناعي في لاغوس أو نيروبي مزود نماذج في الولايات المتحدة، وأداة تحليلات أوروبية، وحسابًا سحابيًا في منطقة أخرى، وحزمًا مفتوحة المصدر، ومتعاقدين خارجيين، وعدة خدمات من دون كتابة أو بكتابة منخفضة. وهذا أمر طبيعي. لكن كل طبقة تضيف اعتمادًا جديدًا.
والخطر هو أن الفرق المبكرة تتحرك بسرعة من دون رسم خريطة لسلسلة الثقة الخاصة بها.
من يملك الوصول إلى أسرار الإنتاج؟ ما هي الجهات التي تخزن المفاتيح؟ هل ترتبط مفاتيح واجهة برمجة التطبيقات بمطورين أفراد أم بحسابات خدمة؟ ماذا يحدث عندما يغادر مطور الفريق؟ هل يستطيع الفريق تدوير بيانات الاعتماد بسرعة؟ هل تختلط أسرار العملاء بالمفاتيح الداخلية؟ هل تخزن السجلات مطالبات أو رموزًا حساسة؟
تزداد أهمية هذه الأسئلة مع انتقال منتجات الذكاء الاصطناعي من العروض التجريبية إلى الأعمال الحقيقية.
في التقنية المالية، والتقنية الصحية، والتقنية التعليمية، والتقنية القانونية، وتقنية الموارد البشرية، والذكاء الاصطناعي المؤسسي، لن يسأل العملاء فقط عما إذا كان المنتج يعمل. بل سيسألون ما إذا كانت الشركة موثوقة بما يكفي للتعامل مع بياناتهم وتدفقات عملهم وبيانات اعتمادهم.
الأمن أصبح جزءًا من مصداقية المنتج.
قائمة تحقق عملية للفرق
قبل أن تخزن شركة ناشئة في مجال الذكاء الاصطناعي مفاتيح واجهة برمجة التطبيقات أو تشاركها عبر بنيتها، ينبغي أن تكون قادرة على الإجابة عن بضعة أسئلة أساسية.
من المسؤول عن إدارة الأسرار داخل الشركة؟
أين تُخزن مفاتيح واجهة برمجة التطبيقات؟
ما المفاتيح النشطة؟
ما المفاتيح الممنوحة صلاحيات زائدة؟
ما الأدوات أو الموردين الذين يمكنهم الوصول إلى أسرار العملاء؟
هل يمكن تدوير المفاتيح من دون كسر الإنتاج؟
هل تخزن السجلات عن طريق الخطأ رموزًا أو مطالبات أو بيانات عملاء أو بيانات اعتماد؟
هل توجد خطة للحوادث إذا تعرض أحد الموردين للاختراق؟
هل يُبلغ العملاء بوضوح ما الأسرار المخزنة ولماذا؟
هذه ليست أسئلة تخص المؤسسات الكبرى فقط. إنها مهمة أيضًا في مرحلة التمويل الأولي. وكلما بنت الشركة عادات نظيفة في وقت أبكر، كان توسيعها أسهل.
الحقيقة الأصعب بشأن بنية الذكاء الاصطناعي التحتية
قد تبدو منتجات الذكاء الاصطناعي بسيطة بشكل مضلل من الخارج. يدخل المستخدم مطالبة. ويعيد النموذج إجابة. وتعرض لوحة التحكم نتيجة تقييم. وتكتمل إحدى العمليات.
لكن خلف هذه التجربة البسيطة توجد سلسلة من الأنظمة.
واجهات برمجة التطبيقات للنماذج. الحسابات السحابية. الأسرار. السجلات. أدوات المراقبة. طبقات التقييم. مخازن المطالبات. قواعد البيانات المتجهة. مزودو المصادقة. لوحات الإدارة الداخلية. المراجعون البشريون. مجموعات بيانات العملاء.
كل جزء يمكن أن يفشل. وكل جزء يمكن أن يتسرب. وكل جزء يمكن أن يصبح طريقًا إلى بقية النظام.
ولهذا فإن الانضباط في إدارة مفاتيح واجهة برمجة التطبيقات مهم. فالأمر لا يتعلق فقط بتجنب عنوان سيئ. بل ببناء منتجات تستطيع الصمود عند الاحتكاك مع عملاء حقيقيين، ومهاجمين حقيقيين، وضغط تشغيلي حقيقي.
ما الذي يجب مراقبته لاحقًا
تقول Braintrust إن سبب الحادث لا يزال قيد التحقيق. وسيكون ذلك التحقيق مهمًا، خاصة للعملاء الذين يحاولون فهم نطاق التعرض وما إذا كانت المشكلة ناجمة عن ضوابط الوصول، أو إعدادات السحابة، أو التعامل مع بيانات الاعتماد، أو اختراق موظف، أو اعتماد على مورد، أو مسار آخر.
بالنسبة إلى المطورين، الخلاصة الفورية واضحة بالفعل.
إذا كان منتجك يعتمد على أدوات ذكاء اصطناعي تابعة لأطراف ثالثة، فيجب أن يشمل نموذجك الأمني تلك الأدوات. وإذا كانت منصتك تخزن أسرار العملاء، فأنت جزء من سطح المخاطر لدى عميلك. وإذا لم يستطع فريقك تدوير المفاتيح بسرعة، فأنت غير مستعد لحادث جدي.
أصبحت حزمة الذكاء الاصطناعي أكثر قوة. كما أنها أصبحت أكثر ترابطًا.
وهذا يجعل الثقة مشكلة تقنية، لا مجرد وعد للعلامة التجارية.
