إدارة وضعية أمان SaaS: ما هي وماذا يجب أن تفحص

إدارة وضعية أمان SaaS (SSPM) هي ممارسة الفحص المستمر لإعدادات الأمان الخاصة بكل تطبيق SaaS تستخدمه مؤسستك — إعدادات المشاركة الافتراضية، وإعدادات المسؤول، ومنح OAuth، وصلاحيات وصول المستخدمين — بدلًا من افتراض أن كل تطبيق آمن منذ يوم إعداده. وهذا مهم لأن معظم حالات تسرّب بيانات SaaS تنشأ من إعداد ينحرف بهدوء عن مساره الصحيح، لا من اختراق للشبكة.

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

ماذا تفحص إدارة وضعية أمان SaaS فعليًا؟

عبر تطبيقات SaaS التي تشغّلها الشركة النموذجية، تشمل مجموعة فحوصات SSPM بشكل عام ما يلي:

• متطلبات المصادقة — ما إذا كانت المصادقة متعددة العوامل (MFA) مفروضة، وعلى من.
• إعدادات المشاركة الافتراضية — ما إذا كانت الملفات أو القنوات أو السجلات تُضبط افتراضيًا على عامة، أو على مستوى المؤسسة، أو خاصة.
• منح تطبيقات OAuth — ما هي التطبيقات الخارجية المصرَّح لها، وبأي صلاحيات (scopes).
• تضخم أدوار المسؤولين — عدد الأشخاص الذين يملكون صلاحيات مسؤول عام أو مالك، وما إذا كان ذلك يفوق حاجة المؤسسة.
• الحسابات القديمة أو اليتيمة — موظفون سابقون أو حسابات خدمة غير مستخدَمة لا تزال تحتفظ بصلاحيات وصول.
• وصول الضيوف والجهات الخارجية — أي الهويات الخارجية يمكنها الوصول إلى البيانات الداخلية، ومن خلال أي قناة.

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

كيف تفحص وضعية أمان SaaS يدويًا، تطبيقًا تلو الآخر؟

كل منصة SaaS رئيسية تعرض نسختها الخاصة من هذه المعلومات، في مكانها الخاص، وبصيغتها الخاصة:

• Google Workspace: وحدة تحكم المسؤول ← Security ← لوحة معلومات الأمان (Security dashboard)، وSecurity ← Access and data control ← ضوابط API لإعدادات المشاركة والوصول إلى التطبيقات.
• Microsoft 365: مركز إدارة Microsoft Entra، وSecure Score في Microsoft 365 Defender، الذي يقيّم إعدادات المستأجر بالكامل مقارنة بخط الأساس الخاص بمايكروسوفت.
• Slack: Settings & administration ← Manage apps لمراجعة التطبيقات المثبَّتة، وإعدادات أمان مساحة العمل للتحقق بخطوتين وضوابط Slack Connect.
• GitHub: صفحة Settings ← Security overview الخاصة بالمؤسسة لفرض التحقق بخطوتين، وSettings ← Third-party Access لسياسة تطبيقات OAuth.

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

ما الذي يجعل فحوصات الوضعية اليدوية، تطبيقًا تلو الآخر، صعبة المواكبة؟

هناك أربعة عوامل تتضافر ضد العملية اليدوية تحديدًا:

1. الوضعية تنحرف باستمرار. كل عملية مشاركة، وكل مسؤول جديد، وكل تطبيق يُصرَّح له حديثًا يغيّر الصورة لحظة حدوثه. المراجعة التي أُجريت الربع الماضي تصف مساحة عمل لم تعد موجودة.
2. لا شيء يتوحّد عبر التطبيقات. عبارة "MFA enforced" في Google Workspace وعبارة "Security defaults enabled" في Microsoft Entra تمثلان الضابط نفسه من حيث الجوهر، لكن بصياغة وإعداد مختلفَين — ولا توجد لغة مشتركة إلا إذا بناها شخص ما يدويًا.
3. كل وحدة تحكم تعرض مستوى مختلفًا من التفاصيل. بعضها يعرض سجل منح الصلاحيات لكل مستخدم؛ وأخرى تعرض أعدادًا إجمالية فقط. المراجعة اليدوية لا تكون أكمل من أقل وحدات التحكم تفصيلًا في مجموعتك.
4. قد يوزّع تطبيق واحد إعداداته الخاصة عبر عدة شاشات. Google Workspace وحده يضع إعدادات المشاركة الافتراضية تحت Security ← Sharing settings، ووصول تطبيقات OAuth تحت Security ← API controls، وملخص المخاطر على مستوى المستأجر تحت Security ← Security dashboard — ثلاث شاشات منفصلة لتطبيق واحد، قبل أن تدخل أداة SaaS ثانية في الصورة أصلًا.

بماذا تختلف SSPM عن قائمة تدقيق امتثال أو تدقيق لمرة واحدة؟

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

ماذا لا تستطيع المراجعة اليدوية لكل تطبيق أن تخبرك به، وكيف يجيب 8200.dev عن ذلك؟

المسح اليدوي يخبرك بالإعدادات كما كانت في يوم فحصك لها. فهو لا يخبرك أي النتائج تهم فعلًا أكثر من غيرها، ولا كيف تتجه الصورة، ولا يلتقط الإعداد الذي يتغيّر في اليوم التالي لانتهائك. تقوم أداة Posture Guard من 8200.dev باستخراج فئات الفحوصات ذاتها — المشاركة، ومنح OAuth، وأدوار المسؤولين، والوصول القديم، والوصول الخارجي — من كل مصدر متصل، ودمجها في عرض موحّد يُعاد فحصه باستمرار، وترتيب النتائج حسب المخاطر الفعلية (الحساسية مضروبة في نطاق الوصول مضروبة في مستوى الوصول) بدلًا من قائمة مسطحة. كل موصّل يعمل افتراضيًا بوضع القراءة فقط: النتائج والتوصيات هي الوضع القياسي، ولا يحدث أي تغيير في مصدر متصل إلا إذا فعّلت المؤسسة خاصية Auto-remediate لتلك القاعدة تحديدًا ومنحت صلاحية الكتابة (write scope) الخاصة بها بشكل منفصل — لا شيء هنا يتصرف من تلقاء نفسه.

ابدأ بـ موصّل Google Workspace أو تصفّح قائمة الموصّلات الكاملة، واطّلع على كيفية عمل نظام التقييم ومستويات السياسات من البداية إلى النهاية.