اختراق ShinyHunters لمنصة Canvas: درس لبنوك SAMA في أمن SaaS

في 7 مايو 2026، شوّهت مجموعة ShinyHunters صفحات تسجيل الدخول لآلاف المؤسسات التعليمية بعد ادعائها اختراق شركة Instructure المالكة لمنصة Canvas، مع سرقة ما تقول إنه 275 مليون سجل من 9,000 مدرسة وجامعة حول العالم. الحادثة ليست بعيدة عن واقع المؤسسات المالية السعودية: نفس آليات الهجوم على منصات SaaS تُستخدم اليوم ضد بنوك تعتمد على Salesforce وWorkday وServiceNow وغيرها.

تشريح هجوم ShinyHunters على Canvas

اكتشفت Instructure نشاطاً غير مصرح به على المنصة بتاريخ 29 أبريل 2026، وأكدت لاحقاً أن المهاجمين استغلوا ثغرة مرتبطة ببرنامج "Free-For-Teacher" — الحسابات المجانية المخصصة للمعلمين. عبر هذه النقطة الضعيفة، تمكنت ShinyHunters من الوصول إلى بيانات مؤسسية تشمل أسماء الطلاب، عناوين البريد الإلكتروني، أرقام الهوية الجامعية، ومحادثات خاصة. ثم وضعت المجموعة موعداً نهائياً للابتزاز هو 12 مايو 2026 لنشر البيانات إذا لم تتم تسوية مالية.

ما يميز هذا الهجوم هو أن نقطة الدخول لم تكن ثغرة حرجة في كود المنصة (RCE أو SQLi)، بل مسار عمل تجاري شرعي — حسابات تجريبية مجانية بضوابط أضعف من الحسابات المؤسسية. هذا تماماً النمط الذي رأيناه في اختراقات Snowflake عام 2024 وSalesforce 2025: المهاجمون لا يكسرون الجدار، بل يدخلون من باب جانبي تركته الشركة مفتوحاً.

لماذا تهم هذه الحادثة بنوك المملكة؟

المؤسسات المالية السعودية تشغّل اليوم عشرات من تطبيقات SaaS الحرجة: CRM (Salesforce/HubSpot)، إدارة الموارد البشرية (Workday/SAP SuccessFactors)، خدمات الدعم (ServiceNow/Zendesk)، وأنظمة التحليل والمراقبة. كل منصة من هذه تحتوي على بيانات عملاء، معلومات موظفين، أو بيانات تشغيلية حساسة. ShinyHunters تُعرف تاريخياً باستهداف قواعد بيانات Salesforce عبر هندسة اجتماعية صوتية (vishing) وحملات استهداف موظفي تكنولوجيا المعلومات لانتزاع رموز OAuth.

الإطار السيبراني SAMA CSCC في النطاق 3.3.14 يلزم المؤسسات بإدارة مخاطر مزودي الخدمة السحابية وتطبيقات الطرف الثالث، بما في ذلك تقييم الضوابط الأمنية لكل مزود قبل التعاقد ومراقبتها بشكل دوري. حادثة Canvas تكشف فجوة شائعة: المؤسسات تركز على تقييم المزود الرئيسي وتنسى الحسابات التجريبية أو حسابات الموردين الفرعيين أو واجهات API المخصصة للمطورين.

التأثير على المؤسسات المالية السعودية

وفق متطلبات SAMA CSCC والنطاق 3.3.5 الخاص بإدارة الهوية والوصول، أي اختراق لمنصة SaaS تستضيف بيانات عملاء البنك يُعتبر حادثة قابلة للإبلاغ خلال 72 ساعة. كذلك يُلزم نظام حماية البيانات الشخصية PDPL المؤسسات بإبلاغ هيئة البيانات والشخص المعني عند حدوث تسرب يؤثر على بيانات شخصية. اختراق بحجم Canvas، لو حدث لمزود CRM لبنك سعودي، قد يعرّض البنك لغرامات تنظيمية بملايين الريالات بالإضافة إلى أضرار سمعة لا يمكن تعويضها.

إطار NCA ECC في النطاق 4-2-1 يشترط أيضاً تطبيق ضوابط أمنية على واجهات API ومسارات التكامل مع الأطراف الخارجية، وهو ما تفشل فيه كثير من المؤسسات عند اعتمادها على إعدادات افتراضية لمنصات SaaS.

التوصيات العملية لفرق الأمن السيبراني

1. جرد كامل لمنصات SaaS: ابنِ سجلاً (CMDB) لكل تطبيق SaaS مستخدم، بما في ذلك تطبيقات "shadow IT" التي تم تفعيلها خارج نطاق فريق تكنولوجيا المعلومات. استخدم أدوات SSPM مثل AppOmni أو Adaptive Shield لاكتشاف الإعدادات الخاطئة.
2. إلغاء حسابات الاختبار والمجاني: راجع كل حساب free-tier أو trial أو sandbox مرتبط ببياناتك المؤسسية. أي حساب لا يحمل ضوابط الإنتاج يجب إغلاقه أو عزله.
3. تفعيل MFA المقاومة للتصيد: اعتمد FIDO2 / WebAuthn لجميع حسابات SaaS الإدارية، وليس فقط OTP عبر SMS. ShinyHunters معروفة بتجاوز MFA الضعيفة عبر هندسة اجتماعية.
4. مراقبة OAuth والرموز المميزة: راقب إنشاء تطبيقات OAuth جديدة، رموز API، ومفاتيح المطورين في كل منصة SaaS. اربط هذه الأحداث بمنصة SIEM مع قواعد كشف للسلوك الشاذ.
5. تشفير البيانات بمفاتيح مُدارة: فعّل Bring Your Own Key (BYOK) أو Hold Your Own Key (HYOK) لكل منصة SaaS تخزن بيانات عملاء مصنفة كـ "سرية" أو "سرية للغاية" وفق تصنيف SAMA.
6. اختبار اختراق سنوي على SaaS: لا تكتفِ بشهادة SOC 2 من المزود. اطلب اختبار اختراق مستقل سنوي يغطي إعداداتك الخاصة، صلاحيات المستخدمين، ومسارات التكامل.
7. خطة استجابة لحوادث SaaS: أضف سيناريوهات اختراق مزود SaaS إلى خطة الاستجابة (IRP)، مع تمرين سنوي يُختبر فيه إبلاغ SAMA وPDPL خلال المهل المحددة.

الخلاصة

اختراق Canvas ليس مجرد قصة عن قطاع التعليم — إنه دليل ميداني لما يمكن أن يحدث لأي مؤسسة مالية سعودية تعتمد على عشرات من تطبيقات SaaS دون رؤية أمنية موحدة. الإطار التنظيمي السعودي (SAMA CSCC وNCA ECC وPDPL) يضع المسؤولية على البنك حتى عندما يكون المخترَق هو المزود. الأمن السحابي لا يُشترى من المزود — يُبنى داخل المؤسسة عبر حوكمة، مراقبة، وضوابط فنية صارمة.

هل مؤسستك مستعدة؟ تواصل مع فريق فنترالينك لتقييم مجاني لمدى النضج السيبراني وفق SAMA CSCC.