CNAPP وCSPM: من النتيجة المنفردة إلى مسار الهجوم

يفحص CSPM ‏(Cloud Security Posture Management) إعدادات السحابة باستمرار مقابل السياسات والمعايير المرجعية ويكشف الإعدادات الخاطئة وانحرافات الامتثال. ويحمي CWPP ‏(Cloud Workload Protection Platform) أحمال العمل نفسها – الأجهزة الافتراضية والحاويات والوظائف عديمة الخوادم – عبر تحليل الثغرات الأمنية ومراقبة وقت التشغيل. ويجرد CIEM ‏(Cloud Infrastructure Entitlement Management) الهويات السحابية مع صلاحياتها ويفرض مبدأ الحد الأدنى من الصلاحيات. وينقل KSPM فكرة الوضع الأمني إلى عناقيد Kubernetes؛ ويعثر DSPM ‏(Data Security Posture Management) على البيانات الحساسة في وحدات التخزين السحابية ويقيّم مدى تعرّضها.

بدلًا من تشغيل CSPM وCWPP وCIEM وماسحات الثغرات بشكل منفصل، تدمج CNAPP هذه الوظائف في منصة واحدة بنموذج بيانات مشترك – من الشيفرة مرورًا بخط الإنتاج وصولًا إلى وقت التشغيل. ويُظهر مدى انتشار هذا النهج استطلاعٌ أجرته Cloud Security Alliance عام 2023 شمل 1,201 من مسؤولي تقنية المعلومات والأمن: إذ كانت ثلاث من كل أربع مؤسسات قد اعتمدت CNAPP أو تخطط لذلك – وذلك أساسًا للسيطرة على تعقيد بيئاتها متعددة السحابات. كما باتت كبرى شركات الحوسبة السحابية تقدّم حزمها الأمنية صراحةً بوصفها CNAPP، مثل Microsoft Defender for Cloud بمكوناته CSPM وDevSecOps وCWPP.

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

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

تبدأ CNAPP عملها قبل النشر: إذ يفحص IaC-Scanning ملفات Terraform أو ARM أو Kubernetes في خط CI/CD بحثًا عن الإعدادات الخاطئة والأسرار المكشوفة، بحيث تُعالج النتائج حيث تنشأ – في الشيفرة. ويساعد السياق السحابي في الوقت نفسه على معرفة أي نتائج الشيفرة ذات صلة أصلًا في بيئة الإنتاج. وفي الطرف الآخر من دورة الحياة تأتي الحماية في وقت التشغيل وCloud Detection & Response ‏(CDR)، اللتان تكتشفان التهديدات النشطة في أحمال العمل الجارية. وقد وصف دليل NIST ‏SP ⁦800-190⁩ بالفعل أن أمن الحاويات يجب أن يشمل دورة الحياة بأكملها من الصورة مرورًا بالسجل والتنسيق وصولًا إلى وقت التشغيل.

من المعايير الأساسية تغطية البيئة الخاصة (مزوّدو السحابة وKubernetes وServerless، وعند الاقتضاء On-Premises)، وبنية الفحص (دون وكلاء إضافةً إلى مستشعر)، وجودة تحليل الرسم البياني ومسارات الهجوم، وتعيينات الامتثال على أطر مثل CIS Benchmarks أو كتالوج BSI ‏C5، والتكامل مع SIEM وأنظمة التذاكر وسير عمل المطوّرين. ولا يقل أهمية عن ذلك نموذج التشغيل: فدون مسؤوليات محددة لمعالجة النتائج تبقى حتى أفضل منصة دون أثر. يُضاف إلى ذلك مخاطر المورّد، إذ تشهد سوق CNAPP اندماجًا – ففي مارس 2026 أتمّت Google الاستحواذ على Wiz مقابل نحو 32 مليار دولار أمريكي. لذلك يُستحسن التحقق بانتظام من تكافؤ الميزات عبر جميع السحابات المستخدمة، ومعالجة تكاليف التبديل والحياد متعدد السحابات تعاقديًا.