أمان الابتكار

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

يتطلب تطوير قدرات وتطبيقات جديدة تلبية ثلاثة أنواع مختلفة من المتطلبات بنجاح:

• تطوير الأعمال (Dev): يجب أن يلبي تطبيقك احتياجات الأعمال والمستخدمين، والتي غالبا ما تتطور بسرعة.
• الأمان (Sec): يجب أن يكون تطبيقك مرنا في مواجهة الهجمات من المهاجمين الذين يتطورون بسرعة والاستفادة من الابتكارات في الدفاعات الأمنية.
• عمليات تكنولوجيا المعلومات (Ops): يجب أن يكون تطبيقك موثوقا به وأن يعمل بكفاءة.

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

شاهد الفيديو التالي لمعرفة المزيد حول أسلوب DevSecOps للابتكار الآمن والسريع.

ما هو DevSecOps؟

غالبا ما يتم تطوير الابتكار التكنولوجي في سياق نهج تطوير سريع رشيق يجمع بين التطوير والعمليات معا في عملية DevOps . لقد تعلمنا أن دمج الأمان في تلك العملية أمر بالغ الأهمية للتخفيف من المخاطر التي تتعرض لها عملية الابتكار ونمو المؤسسة والأصول الموجودة في المؤسسة. يؤدي دمج الأمان في العملية إلى إنشاء عملية DevSecOps .

آمنة عن طريق التصميم والتحول إلى اليسار

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

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

في نموذج الشلال، كان الأمن تقليديا بوابة جودة بعد انتهاء التطوير.

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

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

توفر منهجية تنظيم إطار عمل اعتماد السحابة مزيدا من السياق حول بنيات DevSecOps في المؤسسة. لمزيد من المعلومات، راجع فهم أمان التطبيق ووظائف DevSecOps.

لماذا DevSecOps؟

DevOps يجلب خفة الحركة، DevSecOps يجلب سرعة آمنة.

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

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

قد يستغل المهاجمون نقاط الضعف في:

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

رحلة DevSecOps

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

يوضح هذا الرسم التخطيطي دورة حياة هذا النوع من نهج مصنع الابتكار:

الابتكار الآمن هو نهج متكامل لكلا المرحلتين:

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

حتمية القيادة: مزج الثقافات

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

قد يكون دمج هذه الثقافات والأهداف معا في نهج DevSecOps الحقيقي أمرا صعبا، ولكنه يستحق الاستثمار. تواجه العديد من المؤسسات مستوى عاليا من الاحتكاك غير الصحي من التطوير وعمليات تكنولوجيا المعلومات وفرق الأمان التي تعمل بشكل مستقل، مما يخلق مشكلات مع:

• تسليم القيمة البطيئة وخفة الحركة المنخفضة
• مشكلات الجودة والأداء
• مشكلات الأمان

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

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

تقنيات القيادة

يمكن أن تساعد هذه التقنيات الرئيسية القيادة في بناء ثقافة مشتركة:

1. لا أحد يفوز بكل الحجج: يجب على القادة ضمان عدم هيمنة أي عقلية واحدة على جميع القرارات التي قد تسبب عدم توازن يؤثر سلبا على الأعمال التجارية.

2. توقع التحسين المستمر، وليس الكمال: يجب على القادة تحديد توقع التحسين المستمر والتعلم المستمر. لا يحدث إنشاء برنامج DevSecOps ناجح بين عشية وضحاها. إنها رحلة مستمرة مع تقدم تدريجي.

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

4. تطوير فهم مشترك: يجب أن يكون لدى كل فرد في الفريق فهم أساسي لما يلي:

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

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

6. مراقبة مستوى الاحتكاك الأمني: الأمن يخلق بشكل طبيعي الاحتكاك الذي يبطئ العمليات. من الضروري للقادة مراقبة مستوى ونوع الاحتكاك الذي يولده الأمان:

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

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

8. وضع أهداف مشتركة: تأكد من أن مقاييس الأداء والنجاح لأحمال عمل التطبيق تعكس أهداف التطوير والأمان والعمليات.

ملاحظة

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

تحديد DevSecOps MVP

أثناء الانتقال من فكرة إلى إنتاج، من الضروري التأكد من أن القدرة تفي بالحد الأدنى من المتطلبات، أو الحد الأدنى من المنتج القابل للتطبيق (MVP)، لكل نوع من أنواع المتطلبات:

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

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

دمج الأمان في الأصل في العملية

يجب أن تركز متطلبات الأمان على التكامل أصلا مع العملية والأدوات الحالية. على سبيل المثال:

• يجب دمج أنشطة التصميم مثل نمذجة المخاطر في مرحلة التصميم
• يجب دمج أدوات فحص الأمان في أنظمة التكامل المستمر والتسليم المستمر (CI/CD) مثل Azure DevOps وGitHub و Jenkins
• يجب الإبلاغ عن مشكلات الأمان باستخدام نفس أنظمة وعمليات تعقب الأخطاء، على سبيل المثال، نظام تحديد الأولويات، مثل الأخطاء الأخرى.

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

لمزيد من المعلومات حول DevSecOps، راجع عناصر التحكم التقنية في DevSecOps.

تلميحات حول التنقل في الرحلة

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

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

ملاحظة

تجمع بعض عمليات التنفيذ بين مسؤوليات العمليات والأمان في دور مهندس موثوقية الموقع (SRE ).

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

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

الخطوات التالية

راجع عناصر التحكم التقنية في DevSecOps للحصول على إرشادات أكثر تفصيلا حول DevSecOps.

للحصول على معلومات حول كيفية دمج أمان GitHub المتقدم للأمان في البنية الأساسية لبرنامج ربط العمليات التجارية للتكامل المستمر والتسليم المستمر (CI/CD)، راجع حول أمان GitHub المتقدم.

لمزيد من المعلومات والأدوات حول كيفية تنفيذ مؤسسة تكنولوجيا المعلومات من Microsoft ل DevSecOps، راجع مجموعة أدوات DevOps الآمنة.