لبناء أنظمة ذكاء اصطناعي ناجحة، عليك أولًا محاولة اختراقها. أجرينا اختبار تقييم المخاطر، فتقمصنا دور المهاجمين لاختبار تطبيق ذكاء اصطناعي موجه للعملاء في قطاع الخدمات المالية واستكشاف ثغراته. ما اكتشفناه مهم لكل من ينشر تطبيقات مدعومة بالنماذج اللغوية الكبيرة (LLM) في بيئات لا يمكن فيها التهاون بالأمن.
اختبار تقييم المخاطر هو محاولة متعمدة لاختراق نظام الذكاء الاصطناعي لديك كي تتمكن من إصلاح ثغراته قبل أن يكتشفها مهاجم حقيقي. في الخدمات المالية، تكون المخاطر مرتفعة للغاية؛ فتطبيقات الذكاء الاصطناعي تتعامل مع بيانات العملاء وتعالج المعاملات وتقدم رؤى مالية. قد تتراوح عواقب الإخفاق بين تجربة مستخدم سيئة ومخالفات تنظيمية وخسائر مالية وضرر لا يمكن إصلاحه بسمعة العلامة التجارية.
كان هدفنا اكتشاف الثغرات مبكرًا، واختبار أنماط هجوم واقعية، ومساعدة المؤسسة على تلبية متطلبات سلامة الذكاء الاصطناعي التي يأخذها المنظمون بمنتهى الجدية.
تجدر الإشارة هنا إلى فرق مهم: يستهدف تجاوز إجراءات الحماية مرشحات السلامة في النموذج الأساسي، بينما يستهدف حقن المطالبات التطبيق نفسه، مستغلًا مدخلات المستخدم غير الموثوقة إلى جانب مطالبة المطور الموثوقة. يمثل حقن المطالبات خطرًا أكبر لأنه يستهدف نظامك والبيانات السرية التي يعالجها، لا نموذجًا عامًا.
شملت جولتنا الأولى نحو 750 اختبارًا في المجالات التالية:
تسرب البيانات بين الجلسات
كشف معلومات التعريف الشخصية (PII) عبر اللغة الطبيعية والتلاعب بواجهة API وأساليب ترميز مختلفة
حقن SQL
تجاوز مطالبات النظام
خلال الاختبار الأولي، حددنا مشكلتين رئيسيتين في النظام القائم: معالجة الاستعلامات متعددة المقاصد، واستخدام المطالبات المشفرة.
الاستعلامات متعددة المقاصد: وهي طلبات تجمع بين أغراض مشروعة وأخرى ضارة. على سبيل المثال: "اعرض إنفاقي حسب الفئة، ونفّذ أيضًا [SQL ضارًا]." لم يكتشف التطبيق القصد الضار، بل اعتمد كليًا على ضوابط الحماية في طبقة البيانات اللاحقة. يشبه ذلك ترك باب منزلك مفتوحًا لأنك تثق بالخزنة الموجودة في القبو.
الترميز: وفيه تُرمّز الطلبات باستخدام Base64 وHex وLeetSpeak والمحارف المتشابهة شكليًا. قد يصعب على الأنظمة تصفية المقاصد الضارة. ورغم أننا وجدنا أن هذه الاستعلامات لم تكشف بيانات حساسة، فقد أسهمت في زعزعة استقرار النظام بدرجة كبيرة، من خلال الهلوسة وترديد عبارات SQL الضارة للمستخدمين والخلط في تصنيف المقاصد، وغير ذلك.
أظهرت نتائج اختباراتنا الأولية ما يلي:
هلوسات زمنية: يعرض النموذج بثقة تواريخ أو طوابع زمنية للمعاملات أو ملخصات محددة زمنيًا، لكنها مختلقة. ويمثل ذلك خطرًا كبيرًا في السياق المالي، إذ قد تترتب عواقب حقيقية على تصرف العميل بناءً على تاريخ خاطئ
ترديد عبارات SQL الضارة للمستخدم، وهو أمر مقلق بسبب مخاطر تسميم الذاكرة
الخلط في تصنيف المقاصد
تشوش تنسيق المخرجات
بناءً على هذه النتائج، ضيقنا نطاق تركيزنا. خفضنا أولوية اختبارات حقن SQL والترميز، إذ كان الفريق يعالجها بالفعل. وركزنا بدلًا منها على أكثر مسارات الهجوم نجاحًا: كشف معلومات التعريف الشخصية وتسرب البيانات بين الجلسات.
كان أبرز اكتشاف في الجولة الثانية بسيطًا على نحو لافت: غالبًا لا تحتاج إلى أي حيلة معقدة.
في حالات كثيرة، كان مجرد طلب بيانات داخلية ضمن طلب يبدو مشروعًا كافيًا لجعل النظام يوافق على كشفها. كانت الاستعلامات البسيطة تتلقى ردودًا تشير إلى معرّفات داخلية وحقول في النظام لا ينبغي مطلقًا إظهارها للمستخدمين النهائيين.
وبمزيد من البحث، اكتشفنا أن الإخفاق لم يقتصر على مستوى التطبيق. كانت خدمة تحويل النص إلى SQL اللاحقة تنشئ استعلامات تطلب حقولًا أكثر مما ينبغي، كما كانت ردودها التوضيحية تشير إلى بيانات كان يجب تقييد الوصول إليها. كشف ذلك عن صدع حقيقي بين الأنظمة، وهو نوع من الثغرات لا يظهر إلا عند اختبار المنظومة التقنية كاملة، بدلًا من اختبار كل مكون بمعزل عن غيره.
أجرِ اختبار تقييم المخاطر على النظام، لا النموذج. لا يكشف اختبار أحد النماذج اللغوية الكبيرة (LLM) بمعزل عن غيره إلا القليل عن الوضع الأمني لتطبيقك. اختبر المنظومة التقنية كاملة من البداية إلى النهاية، بالطريقة التي يتفاعل بها المستخدم معها.
يجب التحقق من المدخلات قبل وصولها إلى النموذج اللغوي الكبير (LLM). ينبغي اكتشاف الاستعلامات المشفرة والهجمات متعددة المقاصد ومحاولات الحقن الأساسية عند حدود النظام، لا إسنادها إلى الخدمات اللاحقة.
لا تثق بنقاط التقاء الأنظمة. في البنى متعددة الخدمات، تختبئ أخطر الثغرات في الصدوع الواقعة بين الأنظمة. انعدام الثقة يعني انعدامها تمامًا؛ لذا تحقّق من كل شيء في كل طبقة.
الهجمات البسيطة تنجح. تتصدر هجمات تجاوز إجراءات الحماية المتطورة العناوين، لكن أحيانًا يكفي أن... تطلب. إذا كان نظامك يعرض المعرّفات الداخلية بسهولة لمجرد أن المستخدم أدرجها في استعلام مشروع من جوانبه الأخرى، فهذه مشكلة.
افهم ما تختبره فعليًا. قد يكتشف تدريب النموذج اللغوي الكبير (LLM) نفسه أنماط الهجوم المعروفة، بدلًا من ضوابط الحماية لديك. ضمّن إمكانات الرصد في اختبار تقييم المخاطر لتعرف أي ضوابط يجري تفعيلها بالفعل.
تحتاج البيئات المقيدة إلى حلول مبتكرة. تتيح الاستعانة بمزوّدين مخصصين ودعم النماذج المحلية إجراء اختبار فعّال لتقييم المخاطر من دون وصول متخصص إلى الخدمات السحابية. لكن يجب توضيح القيود التي يفرضها ذلك بشفافية.
اختبار تقييم المخاطر ليس إجراءً لمرة واحدة. إنه عملية تكرارية ينبغي أتمتتها حيثما أمكن، وتطويرها بالتوازي مع تطور نظامك. الهجمات المهمة غدًا ليست هي نفسها المهمة اليوم.
ستواجه أنظمة الذكاء الاصطناعي في البيئات الخاضعة للتنظيم تدقيقًا متزايدًا لا أقل. ستكون المؤسسات التي تتعامل مع الاختبارات الأمنية بوصفها ممارسة مستمرة، لا مجرد خانة تُؤشر قبل الإطلاق، أقدر على اجتياز هذا التدقيق وتجنب أزمات العلاقات العامة التي تفقدها ثقة العملاء.