بحلول عام 2025 ، المجموع إنشاء البيانات العالمية سيصل إلى 181 زيتابايت. بالنسبة للمؤسسات، تعتبر هذه البيانات أحد الأصول، مما يسمح لها بالاستفادة من مجموعة متنوعة من منصات التكنولوجيا لإنشاء تجارب عملاء مخصصة للغاية تولد الولاء وتجذب أعمالًا جديدة. ومع ذلك، تعتمد هذه التجارب على البنى التحتية السحابية التي تستخدم أوضاع الأمان المشتركة. وهنا تكمن المخاطرة، وهي تتزايد مع نمو التكنولوجيا لدمج جيش جديد من المطورين المواطنين الذين يستخدمون منصات منخفضة التعليمات البرمجية ومن دون تعليمات برمجية.
فهم والتغلب على عقلية الميراث
غارتنر تشير التقديرات إلى أنه بحلول عام 2025، سيتم إنشاء 70% من تطبيقات المؤسسات من منصات منخفضة التعليمات البرمجية وبدون تعليمات برمجية مثل Salesforce وServiceNow. تعد الاستجابة بعقلية قائمة على الميراث طريقة أكيدة لضبط أكثر من ثلثي تطبيقات المؤسسة للفشل.
إن "عقلية الميراث" هي وصف مناسب للمشاكل التي تعاني منها البنية التحتية. إنه يعيد إلى الأذهان الأطفال الأغنياء والمدللين الذين يعتمدون بشكل كامل على العمل المنجز والأشخاص الذين سبقوهم. هذه ليست طريقة جيدة لبناء إرث، وهي أيضًا طريقة سيئة أيضًا لبناء النظام.
عندما يكون لديك عقلية قديمة، فإنك تفترض أن البنية التحتية قد تم إعدادها. النظام الأساسي آمن، والأمان مدمج فيه. الثقة مفترضة ببساطة لأن التكنولوجيا كانت موجودة قبل المسؤول.
إن عقلية الميراث هذه تصيب الأنظمة الأساسية منخفضة التعليمات البرمجية والتي لا تحتوي على تعليمات برمجية. يعتمد المستخدمون على أمان النظام الأساسي لنقلهم عبر البنية التحتية للمؤسسة بأكملها. وبدلاً من ذلك، يجب أن ينطبق أمان تلك المنصة على تلك المنصة فقط.
لنفترض أن مطوري Salesforce قاموا بإنشاء برنامج تعيين تلقائي للعملاء المحتملين الجدد. إنهم يستخدمونه داخل Salesforce للمهام الداخلية، ولا بأس بذلك. يمكنهم الاعتماد على سلامة المنصة. قرروا توسيعه لتحسين الأتمتة. يقومون بتوصيل هذا البرنامج بإدارة علاقات العملاء (CRM) ذات واجهة خارجية مثل ServiceNow أو SAP أو Oracle. تتولى عقلية الميراث المسؤولية: Salesforce آمنة. ServiceNow أو SAP أو الجهة الخارجية آمنة.
لذلك، Salesforce + طرف ثالث = آمن.
ولكن، هناك قدر كبير من المجهول في علامة الزائد تلك. كيف يمكنك ربط البرنامج الداخلي الذي تم إنشاؤه في Salesforce بشكل آمن ومتوافق مع البرنامج الخارجي الذي تم إنشاؤه في النظام الأساسي لجهة خارجية؟ هناك مجال كبير للخطأ في تلك الشخصية الفردية.
وهذا اتصال واحد فقط. العديد من البرامج التي تم إنشاؤها في Salesforce تمس مئات البرامج الأخرى. يتم التعامل مع المئات من الأشياء المجهولة مثل علامة الزائد الموضحة أعلاه من قبل أشخاص ليس لديهم خبرة في التطوير أو ليس لديهم خبرة في التطوير.
الحل الوحيد هو إعادة هذا التطوير إلى أرض الواقع مع العودة إلى مبادئ DevSecOps.
إنشاء إطار عمل DevSecOps
DevSecOps تمت كتابة الأطر وإعادة كتابتها وكتابتها مرة أخرى منذ إنشاء المفهوم. ليست هناك حاجة لإعادة اختراع العجلة عند تأسيسها، خاصة عندما SAFEcode وتحالف الأمن السحابي وقد بني ستة أعمدة:
- مسؤوليات جماعية: يعد الأمان مسؤولية كل شخص في المؤسسة — ولكن لا يستطيع الأشخاص تلبية المعايير التي لا يعرفونها. يجب تعيين العملاء المحتملين لدفع سياسة الأمن السيبراني والتأكد من نشرها عبر المؤسسة.
- التعاون والتكامل: يجب مشاركة المعرفة ونقلها. نصف سبب سقوط الشركات في العقلية القديمة هو أن كل من عرف النظام القديم قد رحل. يساعد تبادل المعرفة المستمر في القضاء على هذه المشكلة.
- التنفيذ العملي: روابط التنفيذ العملي في تجربة المطور. العمليات الصعبة والدنيوية وغير العملية لا يتم اتباعها لفترة طويلة. يجب دمج الأمان في ممارسات التطوير، أي أن كل سطر من التعليمات البرمجية يتطلب سطرًا من الاختبار. يمكن للمؤسسات عالية الأداء أن تأخذ هذا الأمر إلى أبعد من ذلك باستخدام أداة لأتمتة كل سطر من تعليمات برمجية الاختبار.
- الإمتثال والتطوير: يجب أن توجه متطلبات الامتثال عملية التطوير بطريقة لا تسمح للمطورين بالانحراف عنها. على سبيل المثال، سيعمل مطور مؤسسة مالية على منصة مصممة لتكون متوافقة مع قانون جرام-ليتش-بليلي. لا يتعين على المطور معرفة خصوصيات وعموميات القانون ليكون متوافقًا، لأنها مدمجة في النظام الأساسي.
- الأتمتة: يجب أتمتة المهام التي يمكن التنبؤ بها والتكرار وذات الحجم الكبير كلما أمكن ذلك لإزالة العبء عن المطورين وتقليل مخاطر الخطأ البشري.
- رصد: البنى التحتية السحابية الحديثة تتغير وتنمو. من الضروري تتبع ذلك - من الناحية المثالية، من خلال شكل من أشكال التنسيق الذي يسمح برؤية سريعة لجميع الترابطات المختلفة.
في باقة رمز منخفض أو بدون رمز ومع البيئة، فإن هذه الركائز ليست واضحة كما يتوقع المرء. غالبًا ما يكون الأشخاص الذين يستخدمون هذه الأدوات خبراء أعمال وليس لديهم سوى القليل من المعرفة بأساسيات DevSecOps.
الجمع بين الأشخاص والعمليات والتكنولوجيا
يمكن أن يساعد استخدام الأنظمة الأساسية ذات التعليمات البرمجية المنخفضة والتي لا تحتوي على تعليمات برمجية في الواقع على سد فجوة المهارات هذه. يريد الموظفون تعلم مهارات جديدة. ويمكن للمؤسسات دعم ذلك من خلال إنشاء إطار عمل DevSecOps يركز على الأشخاص والعمليات والتكنولوجيا.
- العمليات: في بيئة انعدام الثقة، لا يتعين على المطورين ذوي التعليمات البرمجية المنخفضة والذين لا يستخدمون التعليمات البرمجية القلق بشأن إجراء اتصالات تعرض سلامة النظام للخطر لأنهم غير قادرين على القيام بذلك. ليس لديهم أي سلطة أساسية خارج نظامهم المعزول.
- الناس: إن ثقافة المساءلة تختلف عن ثقافة اللوم. تعني المساءلة أن الأفراد يشعرون بالارتياح عند طرح مشكلة أو خطأ لأن التركيز ينصب على القضية وليس على الشخص.
- تكنولوجيا: تعد التكنولوجيا أكبر عائق أمام التنفيذ السليم لمبادئ DevSecOps لأنها خارج أيدي المطورين. يجب عليهم استخدام ما تقدمه لهم المنظمة. إذا لم تنجح هذه التقنية، فسوف يتوصل المطورون إلى حلول غير آمنة ولا آمنة. في الأساس، تصبح التكنولوجيا مولدًا كبيرًا لتكنولوجيا المعلومات في الظل.
نحن نعيش في وقت مثير للتنمية. تتاح الفرصة لعدد متزايد من الأشخاص لبناء البرامج واختبار الاستراتيجيات وتحسين قيمة الأعمال. ولكن مع ذلك تأتي المخاطر. والشركات التي تبحث عن طرق لتفريغ هذه المخاطر على التكنولوجيا سوف تحافظ على تطورها على أرض الواقع مع ترك مجال للاستكشاف.
