إطار تصنيف مخاطر التطبيقات للمؤسسات الخاضعة للتنظيم

لماذا يُعدّ تصنيف مخاطر التطبيقات أمراً جوهرياً للمؤسسات الخاضعة للتنظيم

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

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

بات المنظمون يتوقعون ذلك بصورة متزايدة. يشترط DORA (قانون المرونة التشغيلية الرقمية) على الكيانات المالية تصنيف أصول ICT حسب الأهمية. ويستلزم NIS2 تدابير أمنية متناسبة مع المخاطر. ويفرض PCI DSS ضوابط معززة لبيئات بيانات حاملي البطاقات. ودون إطار تصنيف قابل للدفاع، لا تستطيع المؤسسة إثبات امتثالها لأي من هذه الأنظمة.

يحول الإطار المطبَّق بفاعلية أيضاً دون حدوث إخفاقَي التدقيق الشائعَين: المبالغة في التصنيف (حين يُوسَم كل شيء بـ”حرج” فتُهدَر الموارد)، والتقصير في التصنيف (حين تُعامَل التطبيقات الحرجة حقاً معاملة روتينية).

معايير تصنيف المخاطر

يُقيِّم إطار التصنيف الراسخ التطبيقاتِ عبر أبعاد متعددة. لا يكفي معيار واحد وحده — يجب أن يعكس التصنيف ملف المخاطر المجمَّع.

حساسية البيانات

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

معلومات التعريف الشخصية (PII): الاسم والعنوان وأرقام الهوية الوطنية والبيانات البيومترية
البيانات المالية: أرقام بطاقات الدفع وتفاصيل الحسابات المصرفية وسجلات المعاملات
المعلومات الصحية: سجلات المرضى والبيانات التشخيصية ومعلومات الوصفات الطبية
البيانات التجارية السرية: الأسرار التجارية والخطط الاستراتيجية ونشاطات الاندماج والاستحواذ
بيانات اعتماد المصادقة: كلمات المرور والرموز المميزة ومفاتيح API والشهادات

النطاق التنظيمي

التطبيقات التي تقع ضمن تكاليف تنظيمية محددة تحمل التزامات امتثال متأصلة:

DORA: أنظمة ICT الداعمة للوظائف الحيوية أو الهامة في الخدمات المالية
NIS2: الأنظمة التي تشغّلها الكيانات الأساسية أو الهامة
PCI DSS: أي نظام ضمن بيئة بيانات حاملي البطاقات
GDPR: الأنظمة التي تعالج البيانات الشخصية لمقيمي الاتحاد الأوروبي
اللوائح القطاعية الخاصة: الرعاية الصحية (ما يعادل HIPAA)، والطاقة، والاتصالات

الأهمية التشغيلية للأعمال

ما مدى أهمية التطبيق للعمليات التجارية الجارية؟ يُراعى في ذلك:

الأثر على الإيرادات في حال عدم توفر التطبيق
التطبيقات الموجَّهة للعملاء مقابل وظائف الدعم الداخلية
هدف وقت الاسترداد (RTO) وهدف نقطة الاسترداد (RPO)
الالتزامات التعاقدية المرتبطة بتوفر التطبيق

مستوى التعرض

تتفاوت مساحة الهجوم تفاوتاً ملحوظاً بحسب طريقة الوصول إلى التطبيق:

مواجه للعموم: متاح عبر الإنترنت دون مصادقة
خارجي مع مصادقة: متاح عبر الإنترنت ولكنه يتطلب تسجيل دخول (بوابات العملاء وواجهات برمجة الشركاء)
داخلي: متاح فقط ضمن الشبكة الداخلية للمؤسسة
داخلي مقيَّد: متاح فقط من شرائح شبكة أو محطات عمل محددة

تعقيد التكاملات

التطبيقات ذات التكاملات العديدة تحمل مخاطر مرتفعة لأن الاختراق يمكن أن ينتشر:

عدد اتصالات الأنظمة الأولية والمصبّية
الوصول إلى قواعد بيانات مشتركة أو بحيرات بيانات
تعرض واجهة برمجة التطبيقات (API) للأطراف الثالثة
استخدام حسابات خدمة أو بيانات اعتماد مشتركة

مستويات التصنيف

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

المستوى	التصنيف	المعايير	أمثلة	الضوابط المطلوبة
المستوى 1	حرج	يعالج بيانات بالغة الحساسية (PII على نطاق واسع، معاملات مالية)؛ خاضع لتكاليف تنظيمية متعددة؛ مواجه للعموم؛ حرج تشغيلياً مع RTO أقل من 4 ساعات؛ تكاملات واسعة مع الأطراف الثالثة	منصة الخدمات المصرفية الأساسية، نظام معالجة المدفوعات، بوابة الصحة الموجَّهة للعملاء، منصة التداول	مجموعة اختبار أمني متكاملة (SAST وDAST وSCA واختبار الاختراق)؛ النمذجة التهديدية إلزامية؛ موافقة الأمن لكل إصدار؛ مراقبة مستمرة؛ مراجعة تدقيق ربع سنوية
المستوى 2	مرتفع	يعالج بيانات حساسة؛ خاضع لتكليف تنظيمي واحد على الأقل؛ خارجي مع مصادقة؛ تأثير تجاري جسيم في حال الاختراق؛ تعقيد تكامل معتدل	نظام إدارة علاقات العملاء، منصة الموارد البشرية مع PII للموظفين، بوابة API للشركاء، التقارير المالية الداخلية	SAST وSCA في كل عملية بناء؛ DAST ربع سنوي؛ اختبار اختراق سنوي؛ نمذجة تهديدية للتغييرات الجوهرية؛ مراجعة أمنية للإصدارات الهامة
المستوى 3	معتدل	بيانات حساسة محدودة؛ نطاق تنظيمي مباشر ضئيل؛ موجَّه داخلياً؛ تأثير تجاري معتدل؛ تكاملات محدودة	أدوات إدارة المشاريع الداخلية، الإنترانت المؤسسية، نظام إدارة الوثائق، منصات التواصل الداخلية	SAST وSCA في كل عملية بناء؛ DAST سنوي؛ مراجعة أمنية لتغييرات البنية؛ إدارة تغييرات معيارية
المستوى 4	منخفض	لا بيانات حساسة؛ لا نطاق تنظيمي مباشر؛ موجَّه داخلياً بوصول مقيَّد؛ تأثير تجاري منخفض؛ نظام معزول	البيئات التجريبية للتطوير، الويكي الداخلي بمحتوى غير حساس، بيئات الاختبار (دون بيانات إنتاجية)	SCA للثغرات في التبعيات؛ ممارسات الترميز الآمن المعيارية؛ مراجعة دورية

كيف يقود التصنيف متطلبات ضوابط الأمن

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

يجب توثيق هذا التعيين في السياسات، وعدم تركه للاجتهاد الفردي. سيبحث المدققون عن معيار مكتوب وواضح يحدد الضوابط الإلزامية في كل مستوى.

مجال الضبط	المستوى 1 (حرج)	المستوى 2 (مرتفع)	المستوى 3 (معتدل)	المستوى 4 (منخفض)
تكرار SAST	كل commit / pull request	كل عملية بناء	كل عملية بناء	دوري / عند الطلب
تكرار DAST	أسبوعي آلي + قبل كل إصدار	ربع سنوي	سنوي	غير مطلوب
تكرار SCA	مراقبة مستمرة	كل عملية بناء	كل عملية بناء	ربع سنوي
اختبار الاختراق	مرتين سنوياً (كحد أدنى)	سنوي	قائم على المخاطر / كل سنتين	غير مطلوب
النمذجة التهديدية	إلزامية؛ تُحدَّث مع كل تغيير جوهري	إلزامية للتغييرات الجوهرية	موصى بها	غير مطلوبة
موافقة الإصدار	موافقة قائد الأمن إلزامية	مراجعة أمنية للتغييرات الهامة	إدارة تغييرات معيارية	إدارة تغييرات معيارية
الاحتفاظ بالأدلة	7 سنوات (أو الحد الأدنى التنظيمي)	5 سنوات	3 سنوات	سنة واحدة
دورية مراجعة التدقيق	ربع سنوية	نصف سنوية	سنوية	ضمن المراجعة الدورية للبرنامج

نموذج الحوكمة للتصنيف

التصنيف ليس تمريناً لمرة واحدة. يستلزم نموذج حوكمة يحدد الملكية ودورية المراجعة وإجراءات التصعيد.

من يصنِّف

يقترح مالك التطبيق (مدير خط الأعمال أو مالك المنتج عادةً) التصنيف الأولي بناءً على المعايير أعلاه. لا ينبغي ترك ذلك حصراً لفرق التطوير التي قد تفتقر إلى الرؤية الكاملة للأبعاد التنظيمية ومخاطر الأعمال.

من يراجع ويوافق

يجب مراجعة التصنيف المقترح والموافقة عليه من:

فريق أمن المعلومات / أمن التطبيقات: التحقق من صحة تقييم المخاطر التقنية
وظيفة الامتثال / المخاطر: التأكد من الاستيعاب الصحيح للنطاق التنظيمي
قيادة الأعمال: التأكد من تقييم الأهمية التشغيلية للأعمال

عملية التصعيد

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

مثيرات إعادة التصنيف

يجب إعادة تصنيف التطبيقات عند:

بدء التطبيق في معالجة فئة جديدة من البيانات الحساسة
سريان تكليف تنظيمي جديد (مثلاً خضوع المؤسسة لـ DORA)
انتقال التطبيق من التعرض الداخلي إلى الخارجي
وقوع حادثة أمنية جسيمة تتعلق بالتطبيق
إجراء تغييرات معمارية جوهرية تغير ملف التكامل
رصد دورة المراجعة السنوية لتغيير في الأهمية التشغيلية للأعمال

ما يجب على المدققين التحقق منه

عند تقييم إطار تصنيف مخاطر التطبيقات في المؤسسة، يجب على المدققين التحقق مما يلي:

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

المؤشرات التحذيرية

النتائج التالية يجب أن تُثير قلقاً فورياً أثناء التدقيق:

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

قراءة إضافية

للاطلاع على توجيهات ذات صلة بحوكمة أمن التطبيقات وممارسات التدقيق، راجع:

ذو صلة للمدققين

المسرد — تعريفات بلغة مبسطة للمصطلحات التقنية
بنية أمن NIS2 موضَّحة
DORA المادة 28 موضَّحة
ضوابط أمن CI/CD الأساسية

هل أنت جديد على تدقيق CI/CD؟ ابدأ بـدليل المدقق.