هل يحمي موقعك السحابي عملك أم يفتح بابًا للهجمات؟

كثير من الشركات في السعودية والخليج انتقلت إلى الويب والسحابة بسرعة. متجر إلكتروني، بوابة عملاء، لوحة تحكم داخلية، نظام حجوزات، تطبيق عيادة، أو واجهات برمجة تربط الفروع والمورّدين. المشكلة أن بعض الإدارات تنظر إلى الأمان من زاوية ضيقة: هل الخادم محمي؟ هل لدينا شهادة SSL؟ هل مزوّد السحابة معروف؟

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

نشرت Microsoft في 9 سبتمبر 2026 عبر مدونتها الأمنية إطارًا باسم Cloud Web Applications Threat Matrix، وهو مصفوفة تساعد فرق الحماية على فهم تهديدات تطبيقات الويب المستضافة على السحابة والمنصات دون خوادم، مع مواءمة مع إطار MITRE ATT&CK المعروف في مجال الأمن السيبراني. القيمة العملية لصاحب العمل ليست في الاسم التقني، بل في السؤال الأهم: هل نفهم مسارات الهجوم المحتملة حول أنظمتنا الرقمية قبل أن يعتمد عليها العملاء والموظفون؟

الأمن ليس خادمًا فقط بل رحلة كاملة داخل التطبيق

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

الفكرة التي تبرزها مصفوفة Microsoft أن الخطر يتحرك عبر طبقات مختلفة. يبدأ المهاجم أحيانًا من نقطة بسيطة ثم ينتقل خطوة بعد خطوة. قد يجرّب كلمات مرور مسرّبة. قد يستغل رابطًا قديمًا لواجهة برمجة التطبيقات (APIs). قد يصل إلى لوحة إدارة لم تُقيّد جيدًا. وقد يستخدم صلاحية مفرطة للوصول إلى بيانات لا يحتاجها صاحب الحساب أصلًا.

لذلك، قبل تحديث موقعك أو بناء نظام جديد، لا تسأل فقط: أين سنستضيف التطبيق؟ اسأل أيضًا: كيف سيدخل المستخدم؟ ماذا يستطيع أن يرى؟ ماذا يحدث إذا سُرّبت كلمة المرور؟ ما الأجزاء المكشوفة للإنترنت؟ كيف نعرف أن هناك نشاطًا غير طبيعي؟

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

أسئلة المصادقة والصلاحيات قبل الإطلاق

أول باب في معظم الأنظمة هو تسجيل الدخول. لذلك تبدأ مراجعة الأمان من المصادقة (Authentication). في السوق المحلي، كثير من الأنظمة تخدم موظفين وفروعًا وعملاء ومورّدين. كل فئة تحتاج مستوى وصول مختلفًا.

اسأل فريقك التقني عن 5 نقاط واضحة:

1. هل ندعم التحقق متعدد العوامل للحسابات الحساسة، مثل حسابات الإدارة والمالية؟
2. هل توجد سياسة قوية لكلمات المرور ومحاولات الدخول الفاشلة؟
3. هل تنتهي الجلسات تلقائيًا عند الخمول أو عند الاشتباه في نشاط غريب؟
4. هل يستطيع موظف سابق الدخول بعد خروجه من الشركة؟
5. هل لدينا فصل دقيق للصلاحيات بين الموظف، المشرف، المدير، والمحاسب؟

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

الأفضل أن يُبنى النظام على مبدأ بسيط: كل مستخدم يحصل على أقل صلاحية يحتاجها لإنجاز عمله. هذا المبدأ يحمي الشركة إذا اختُرق حساب واحد أو استُخدم من شخص غير مخوّل.

النقاط المكشوفة والتكاملات قد تكون الطريق الأسهل

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

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

اسأل قبل الإطلاق أو التحديث:

• ما الواجهات العامة المكشوفة للإنترنت؟
• هل توجد واجهات قديمة لم تعد مستخدمة؟
• أين تُحفظ مفاتيح الربط مع مزودي الدفع والشحن والرسائل؟
• هل نتحقق من البيانات القادمة من الأنظمة الخارجية؟
• هل نستطيع إيقاف تكامل معيّن بسرعة إذا ظهرت مشكلة؟

التطبيقات دون خوادم (Serverless) تحتاج السؤال نفسه. صحيح أنها تقلل عبء إدارة الخوادم، لكنها لا تلغي مسؤولية تصميم الصلاحيات، حماية الدوال، ضبط الوصول إلى التخزين، ومراقبة الاستدعاءات غير الطبيعية.

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

السجلات والاستجابة للحوادث جزء من المنتج لا إضافة لاحقة

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

السجلات ليست ترفًا تقنيًا. هي ذاكرة النظام. تحتاجها لتعرف من دخل، من عدّل، من صدّر، من غيّر الصلاحيات، ومن حاول الوصول إلى جزء ممنوع.

قبل تشغيل نظام مهم، اطلب إجابات عن هذه الأسئلة:

1. ما الأحداث التي نسجلها؟ تسجيل الدخول، تغيير كلمة المرور، تعديل الصلاحيات، تصدير البيانات، حذف السجلات، وأخطاء الدفع أم لا؟
2. من يستطيع الاطلاع على السجلات؟
3. هل تصل تنبيهات عند حدوث نشاط غير معتاد؟
4. كم نحتفظ بالسجلات؟
5. ما خطة التصرف إذا اشتبهنا في اختراق؟

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

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

كيف يستفيد صاحب العمل من فكرة مصفوفة التهديدات؟

لا تحتاج أن تعتمد إطارًا عالميًا كاملًا منذ اليوم الأول. لكن يمكنك استخدام فكرة مصفوفة التهديدات كطريقة تفكير عند بناء أو تحديث أي تطبيق ويب.

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

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

الأمن الجيد لا يعني تعطيل المشروع. بالعكس، عندما يدخل ضمن التصميم من البداية، يقلل إعادة العمل، ويحسن ثقة المستخدمين، ويجعل التوسع أسهل.

أهم الخلاصات

• إعلان Microsoft عن Cloud Web Applications Threat Matrix يسلط الضوء على تهديدات تطبيقات الويب السحابية، لا البنية التحتية فقط.
• أي موقع أو بوابة أو لوحة تحكم أو واجهة برمجة قد تصبح مسار هجوم إذا لم تُراجع المصادقة والصلاحيات والتكاملات.
• الحسابات الإدارية تحتاج حماية أقوى، خصوصًا في الأنظمة التي تدير بيانات عملاء أو مدفوعات أو عمليات داخلية.
• التكاملات مع الدفع والشحن والرسائل والأنظمة الخارجية يجب أن تكون محدودة وموثقة وقابلة للإيقاف.
• السجلات والتنبيهات وخطة الاستجابة للحوادث يجب أن تكون جزءًا من المشروع منذ البداية.

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