فهم النتائج المنشودة: كيف اخترنا مجموعة ميزات Cloud Defense Free

عندما قررنا إطلاق نسخة مجانية من FireMon Cloud Defense، كنا ندرك أن علينا الموازنة بين تحديين رئيسيين:

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

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

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

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

تحديد النتائج المرجوة

نحن في FireMon من أشد المعجبين بإطار عمل Jobs to be Done لاستراتيجية المنتج. الاسم يكشف الكثير، لكن هذا الإطار يوجّه قرارات المنتج عبر التركيز على المهمة التي يحاول العميل إنجازها، والنتائج المحددة التي يتوقعها. وهذا تبسيط مُفرط لإطار JTBD، لكن الفكرة واضحة. فبدلًا من التركيز على الميزات، تركّزون على النتائج التي يرجوها العميل المحتمل عند استخدام المنتج، ثم تستخدمون ذلك لتصميم الميزات.

وبعد عملية معمّقة شملت البحث والخبرة والمقابلات، توصلنا إلى مسودة مجموعة من النتائج المرجوة المحتملة لمتخصصي أمن السحابة:

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

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

ترجمة النتائج إلى ميزات

بوجود تلك القائمة، حان وقت معرفة ما يمكننا تكييفه أو بناؤه:

• تحسين معرفتي وفهمي لوضعية السحابة لدينا عبر بصمتنا السحابية بالكامل. (الرؤية)

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

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

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

• تقليل احتمالية حدوث خطأ في إعدادات السحابة عبر بصمتنا السحابية. (الوقاية)

منع الأخطاء في إعدادات السحابة مشكلة أصعب بكثير من اكتشافها. هل تحجبونها في خط أنابيب CI/CD إذا كانوا يستخدمون البنية التحتية ككود؟ وماذا عن التغييرات اليدوية؟ وكيف تديرون سير العمل دون إضافة احتكاك مفرط أو تعطيل الأمور؟

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

• تقليل حالات الانكشاف الأمني والامتثالي في السحابة لدينا (من حيث الحجم والزمن) عبر بصمتنا السحابية في بيئة لامركزية. (المعالجة)

كان هذا جوهر عمل Cloud Defense منذ الإصدارات الأولى للمنتج. ورغم أن المعالجة الآلية لن تصلح لفئتنا المجانية (مرة أخرى، موازنةً بين التكلفة والتعقيد)، لم يكن هناك ما يمنع من تشغيل مجموعتنا الكاملة من الفحوصات الأمنية.

لكن الحصول على قائمة طويلة من المشكلات الأمنية المحتملة لا يساعدكم بالضرورة على المعالجة. ومن القدرات الأساسية الأخرى في منتجنا التكامل العميق مع ChatOps. فنحن ندعم جاهزًا Slack وTeams، لكن Teams سيتطلب دعمًا أكبر لأنه… حسنًا… إنه Teams. لذا قررنا التفعيل الكامل لإشعارات Slack الدقيقة (لكل حساب أو مشروع) لأنها لا تكلّفنا شيئًا يُذكر وتقدم قيمة كبيرة للمستخدمين.

• تحسين قدرتنا على إيصال قضايا أمن السحابة إلى الإدارة والجهات التنظيمية.

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

• إبقاء أمننا محدّثًا مع التغييرات في الخدمات والمنصات السحابية لدى مزودين متعددين.

ولأن منتجينا المجاني والتجاري يستخدمان المكتبة نفسها من الفحوصات التي نحدّثها باستمرار، فقد كان ذلك متاحًا جاهزًا. وقد ركّز جهدنا الهندسي الأولي على تحسين التكلفة لـ AWS، لذا قررنا الإطلاق دون دعم Azure أو GCP في البداية. ودعم Azure أوشك على الجاهزية، وبذلك سيحصل المستخدمون في النهاية على دعم كامل متعدد السحابات مجانًا.

• تقليل احتمالية فقدان وإساءة استخدام صلاحيات IAM في عمليات النشر السحابية لدينا.

لدينا ميزة رائعة تُسمى Authorization Control تُحسّن أمن IAM بشكل ملموس، لكن الاعتبارات الاقتصادية لم تسمح بإدراجها في المنتج المجاني.

• تحسين قدرتنا على منع الهجمات السحابية واكتشافها والاستجابة لها

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

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

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

تجميع مجموعة الميزات

ساعدتنا النتائج المرجوة، إلى جانب تحليلنا للتكاليف، في تحديد الميزات التي سنضمّها:

• عمليات فحص مرة واحدة يوميًا
• جرد الموارد مع سجل لمدة 30 يومًا
• المجموعة الكاملة من الفحوصات الأمنية
• تقارير الامتثال الأساسية
• التكامل مع Slack
• AWS في الوقت الحالي، وAzure وGCP مع تحديثنا للمنصة

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

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

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

جرّبوها، وأخبرونا برأيكم. إن FireMon Cloud Defense عمل قيد التطوير، وهي وسيلة ممتازة لنا لتحسين قدرتنا على مساعدة المتخصصين في أمن السحابة على إنجاز أعمالهم.