إصلاح المخاطر من خلال ملكية الخدمة مع Wiz

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

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

وهذا ما جعل كتالوج الخدمة مقنعًا جدًا لفريقنا هنا في Wiz.

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

لماذا تعتبر الخدمات هي العدسة المناسبة للأمان

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

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

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

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

وكما قال إيريكو فوسكو، كبير مهندسي الأمن في شركة Wiz: “إذا كنت تمتلك خدمة، فيجب أن تكون قادرًا على رؤية المشكلات الأمنية المرتبطة بها، والتصرف بناءً عليها، وتكون مسؤولاً عن حلها. هذا هو الاتجاه الذي نبني نحوه”.

البناء على ما هو موجود بالفعل

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

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

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

• وضع العلامات لم يكن متسقا بما فيه الكفاية

• ملكية لم يكن دائما صريحا

• الأتمتة كانت هناك حاجة للحفاظ على كل شيء محدثًا

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

تحويل الخدمات إلى نموذج تشغيلي

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

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

• مالك

• قناة سلاك

• مهمة عند الطلب

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

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

من النتائج الصاخبة إلى مشكلات الخدمة

إحدى أهم الفوائد بالنسبة لنا في Wiz هي الطريقة التي يحول بها Service Catalog العديد من المخاطر ذات الصلة إلى مشكلة خدمة واحدة.

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

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

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

ما هي الخطوة التالية بالنسبة لكتالوج الخدمة في Wiz

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

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

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