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

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

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

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

بعد تحديد المتطلبات والبنية، يمكن الشروع في هندسة وظائف الأمن والبنية التحتية بما في ذلك اتِّباع مبدأ الأمن الافتراضي (Secure by default).

تمتلك IBM نهجًا طويل الأمد بشأن الأمن والخصوصية من خلال التصميم يُستخدم في تطوير المنتجات. من المفيد الاطِّلاع على مستند IBM Redpaper حول الأمن في التطوير: إطار IBM Secure Engineering Framework.

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

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

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

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

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

يؤكِّد التحقق المستمر أن الكيانات هي من تدعي أنها عليه، سواء أكانت شخصًا أم برنامجًا، باستخدام تحديات مثل طلب المصادقة بعامل ثانٍ. قد يتطلب عبء العمل تحديثات لدعم التحقق المستمر للمستخدمين والبرامج باستخدام حلول Zero Trust Network Architecture (ZTNA). تميل المؤسسات التي تركِّز على تقديم تجارب مستخدم ممتازة إلى تجنُّب إزعاج المستخدم بطلبات غير ضرورية؛ ومع ذلك، فإن هذا المستوى من ضمان الهوية أمر حيوي للثقة الصفرية.

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

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

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

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

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

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

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

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

2. يكشف سطح الهجوم المادي عن الأصول والمعلومات التي عادةً ما تكون متاحة فقط للمستخدمين الذين لديهم وصول مصرح به إلى مكتب المؤسسة الفعلي أو أجهزة نقاط النهاية. ويشمل هذا الهجمات الداخلية الخبيثة، وسرقة الأجهزة، والهجوم بطُعم "Baiting" - وهو هجوم تترك فيه عناصر التهديد محركات USB مصابة بالبرمجيات الخبيثة في أماكن عامة على أمل خداع المستخدمين لتوصيل الأجهزة بأجهزتهم وتحميل البرمجيات الضارة عن غير قصد.

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

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

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

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

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

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

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

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

قد يكون النظام مؤمَّنًا عند البداية، لكن يمكن للمطور لاحقًا إجراء تغييرات تؤدي إلى تعديل التكوين، أو يُجري عنصر التهديد تغييرًا عبر ثغرة أمنية تؤدي إلى اختراق النظام.

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

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

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

لكل بُعد تأثير مختلف في المسؤوليات المشتركة:

• نموذج الخدمة السحابية - يحدِّد تعريف NIST للحوسبة السحابية نطاق المسؤوليات المختلفة اعتمادًا على نموذج الخدمة السحابية، مثل البنية التحتية كخدمة (IaaS)، والمنصات كخدمة (PaaS)، والبرامج كخدمة (SaaS)، أو السحابة الموزعة. خدمات الأمن جزء من المسؤوليات المشتركة. على سبيل المثال، تشمل المسؤوليات المشتركة لـ IBM Cloud إدارة الهوية والوصول، وأمن الامتثال والتنظيم. تختلف المسؤوليات المشتركة لهذه الفئات حسب نموذج الخدمة السحابية.
   

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

• مزوِّد الخدمات السحابية – تتغير المسؤوليات أيضًا اعتمادًا على مزوِّد الخدمات السحابية. على سبيل المثال، تختلف منصة Kubernetes من كل مزوِّد خدمات سحابية (إلا إذا كنت تستخدم Red Hat OpenShift)، حيث يتكون كلٌّ منها من مجموعة مختلفة من الحِزم مفتوحة المصدر المجمَّعة بعناية.

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

على سبيل المثال، قد يستخدم فريق عمليات الأمن الداخلي تقنية مختلفة عن مزوِّد تكامل أنظمة عالمي (GSI) مثل IBM Consulting. بالنسبة إلى فريق الأمن الداخلي، قد تكون طبقة التحكم في الأمن التي تستضيف خدمات الأمن في الموقع، بينما قد يستخدم GSI خدمات الأمن السحابية المقدَّمة من مزوِّد خدمات سحابية آخر.

بالنسبة إلى نموذج الخدمة السحابية Software-as-a-Service (SaaS)، تتوفر فقط إدارة أمن التطبيق لمستهلك الخدمة السحابية. عادةً ما يتم دمج الأمن داخل التطبيق كجزء من الخدمة مع نطاق محدود للتحكم في تكوين الأمن. في هذه الحالة، يتحمَّل مزوِّد خدمة SaaS معظم مسؤوليات عمليات الأمن.

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

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

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

بالنسبة للمؤسسات الوليدة في السحابة، يمكن استضافة مستوى التحكم في سحابة أخرى، أو في نقطة تواجد (POP)، أو في مركز بيانات مشترك. قد يلزم أن يكون مستوى التحكم الأمني متاحاً، حتى لو حدث فشل لدى مزود الخدمة السحابية.

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

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

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

عند انتقال المهندسين إلى مرحلة التنفيذ، يفحصون تدفقات البيانات بين العناصر المنشورة على بنية السحابة باستخدام مخطط بنية السحابة. أنشأت IBM لغة تصميم المخططات الفنية تمكِّن من تصميم مستقل عن مزوِّد الخدمة السحابية.

لتحديد التهديدات لتدفقات البيانات هذه، يمكن استخدام نموذج التهديدات لكلٍّ من العناصر الوظيفية لعبء العمل والبنية التحتية لعبء العمل.

توفِّر هذه التقنيات والموارد معًا نهجًا قابلًا للتكرار ومتسقًا للتفكير البنائي فيما يخص الأمن والامتثال.

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

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

اتَّبِع هذه الخطوات لإدارة الامتثال بشكل أكثر فاعلية:

1. إنشاء إطار امتثال واحد مع إمكانية التتبُّع إلى المصادر الأصلية.
2. ربط المتطلبات في إطار الامتثال بمجموعة من القدرات التقديمية.
3. ضمان امتثال القدرات في جميع مراحل التصميم والبناء والاختبار والتشغيل.
4. الاستمرار في الامتثال للمتطلبات أثناء الإنتاج.

يجب على مهندس الأمن التأكد من أن قدرات الأمن مرتبطة بأهداف مستوى الخدمة (SLOs)، واتفاقيات المسؤوليات، وما إلى ذلك.

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

توفِّر السحابة الهجينة العديد من الخيارات لفرض فصل معالجة البيانات. يجب أن يتم الفصل بين:

1. أعباء العمل أو التطبيقات – على سبيل المثال، المحاسبة مقابل الموارد البشرية
2. البيئات – على سبيل المثال، التطوير والاختبار والإنتاج
3. العملاء – على سبيل المثال، العميل أ مقابل العميل ب
4. الموقع – على سبيل المثال، المملكة المتحدة مقابل الولايات المتحدة

هناك العديد من الخيارات المختلفة للفصل في البيئة السحابية الهجينة، والتي تقدِّم قدرات وضمانات مختلفة:

1. حساب المؤسسة
2. حساب السحابة
3. مجموعة الموارد
4. السحابة الخاصة الافتراضية
5. مجال التنفيذ – على سبيل المثال، حاوية أو صورة خادم
6. المشروع
7. مجال إدارة المفاتيح
8. الأجهزة المادية

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

يرتبط بموضوع فصل البيانات بموضوع سيادة البيانات. تفرض بعض الدول قيودًا على أماكن معالجة البيانات والوصول إليها. يوفر منشور المدونة "Addressing Regulations and Driving Innovation with Sovereign Cloud" مناقشة حول تسلسل احتياجات سيادة البيانات.

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

ومع ذلك، لنمذجة التهديدات غرض ثانٍ – وهو تحديد التهديدات للمراقبة في نظام مراقبة التهديدات. يجب على مهندس الأمن العمل على تحديد قائمة أولويات للتهديدات. ثم تحديد حالات استخدام الكشف عن التهديدات المطلوبة لقدرة الكشف عن التهديدات. تنفيذ واختبار حالات الاستخدام للكشف مع أدلة للاستجابة للحوادث لتمكين الاستجابة الفعَّالة للتهديدات.

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

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

حدِّد لكل قدرة أو خدمة أمنية ما يلي:

1. ساعات الخدمة
2. أوقات الاستجابة للحوادث والمشكلات والتغييرات
3. مهارات وخبرات فريق العمليات
4. إجراءات تفصيلية ومختبرة لتتناسب مع متطلبات الخدمة
5. الأتمتة لتتناسب مع متطلبات الخدمة

إذا لم يتمكن فريق عمليات الأمن الداخلي من تلبية متطلبات عبء عمل أصلي للسحابة، فكِّر فيما إذا كان مزوِّد الخدمات الأمنية المُدارة مناسبًا.

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

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

1. مضمَّنة في بيئات التطوير والاختبار.
2. متسقة من التطوير الأوَّلي وحتى الإنتاج الكامل.
3. تخضع للاختبار باستمرار لضمان الامتثال المستمر.

يجب أن تمنع عمليات البناء النشر غير الآمن لعبء العمل في جميع مراحل التطوير والتشغيل لضمان أن الأمن لا يكون أمرًا ثانويًا.