كيف حولت الخدمات المصغرة أمن المؤسسة
انضم إلى كبار المديرين التنفيذيين في سان فرانسيسكو يومي 11 و 12 يوليو ، لمعرفة كيف يدمج القادة استثمارات الذكاء الاصطناعي ويحسنونها لتحقيق النجاح.. يتعلم أكثر
اجتاحت ثورة الخدمات المصغرة عالم تكنولوجيا المعلومات على مدار السنوات العديدة الماضية ، حيث أبلغت 71٪ من المؤسسات عن تبنيها للهندسة المعمارية بحلول عام 2021. عند مناقشة الخدمات المصغرة ، غالبًا ما نسمع مزاياها في إطار المرونة والمرونة في تقديم الابتكارات للعملاء. لكن إحدى الزوايا التي لم يتم التحدث عنها بنفس القدر هي مخاوف أمان المؤسسة.
في عصر التطبيقات المتجانسة ، قد تعني مشكلة أمنية واحدة قضاء مئات أو آلاف ساعات العمل في إعادة إنشاء تطبيق من الصفر. إلى جانب الاضطرار إلى تصحيح ثغرة أمنية بحد ذاتها ، كان هذا يعني أيضًا أنه سيتعين على DevOps وفرق الأمان مراجعة التطبيق وإعادة بنائه لتعديل التبعيات – في بعض الأحيان يتعين عليك إجراء هندسة عكسية فعالة للتطبيقات بأكملها.
لقد قلبت الخدمات المصغرة هذا النموذج رأساً على عقب. إنها تسمح لـ DevOps بسد الثغرات الأمنية أو المخاوف ومعالجتها دون القلق بشأن كسر حزمة التطبيقات بالكامل. هذا لا يعني مجرد تحول أسرع لتصحيحات الأمان ، ولكن فرق DevOps أكثر مرونة وكفاءة ومكدسات تكنولوجيا المعلومات بشكل عام.
كيف تساعد الخدمات المصغرة في سد الثغرات الأمنية
بالعودة إلى الوراء ، يجدر تذكير أنفسنا بماهية بنية الخدمات المصغرة: مجموعة من الخدمات التي يمكن نشرها بشكل مستقل والمرتبطة ببعضها البعض بشكل غير محكم عبر وسطاء مثل واجهات برمجة التطبيقات. تعكس هذه الخدمات الفردية عادةً اللبنات الأساسية لتطبيقاتك.
حدث
تحويل 2023
انضم إلينا في سان فرانسيسكو يومي 11 و 12 يوليو ، حيث سيشارك كبار المسؤولين التنفيذيين في كيفية دمج استثمارات الذكاء الاصطناعي وتحسينها لتحقيق النجاح وتجنب المزالق الشائعة.
سجل الان
في الممارسة العملية ، الحاويات هي التقنية المستخدمة لتقديم بنى الخدمات المصغرة. تجمع هذه الحزم خفيفة الوزن والمستقلة رمز التطبيق مع أنظمة تشغيل خفيفة الوزن وأوقات تشغيل ومكتبات وبيانات التكوين. باستخدام نظام تزامن مثل Kubernetes ، يمكن للحاويات الفردية تبادل مخرجاتها مع بعضها البعض ، مما يمكنهم من أداء المهمة الشاملة التي كان من الممكن تحقيقها من خلال تطبيق أحادي.
بنية الخدمات المصغرة التي يتم تسليمها بشكل شائع بواسطة الحاويات تسييج العديد من مخاطر الأمان حسب التصميم. مع الخدمات الصغيرة الفردية التي تتبادل فقط مخرجاتها عبر الوسيط الذي ينظمها ، من الصعب جدًا لخرق أو حل وسط لخدمة صغيرة واحدة أن تتغلغل في التطبيق بأكمله.
اللعب بالتقويم
ولكن ماذا يعني ما ورد أعلاه في الممارسة؟ هذه تجربة فكرية.
قبل بضع سنوات ، اكتشف المصنعون أن العديد من الأجهزة الاستهلاكية أصبحت غير صالحة للاستعمال إذا تم تغيير تاريخها إلى 1/1/1970. تخيل لو أدخلنا هذا الخلل في تطبيق التقويم المستخدم في بيئة المؤسسة. الآن ، تخيل أن أحد المهاجمين ذوي القبعة السوداء اكتشف المشكلة قبل أن يفعلها فريق الأمان ، ثم تابع الحصول على بيانات اعتماد شخص ما وقام بتغيير التاريخ الحالي في تطبيق التقويم إلى 1/1/1970.
إذا عمل فريق DevOps في المؤسسة باستخدام تطبيق مترابط ، فسيتعين عليهم القيام بما يلي:
- أولاً ، سيتعين عليهم التعامل مع الأعطال واسعة النطاق في النظام الناتجة عن الهجوم ، والتي لا يمكنهم إصلاحها حتى يعالجوا الخلل.
- ثانيًا ، بافتراض أنهم اكتشفوا أن الخلل كان في تطبيق التقويم الخاص بهم ، فسيتعين عليهم فحص كود المصدر بالكامل للتطبيق والعثور يدويًا على مكان المشكلة.
- أخيرًا ، سيتعين عليهم مراجعة التعليمات البرمجية المصدر لتطبيق التقويم بالكامل لتغيير أي إشارات إلى المتغيرات أو العبارات المرتبطة بأسطر التعليمات البرمجية التي تم التنصت عليها.
كيف سيبدو هذا إذا عمل فريق DevOps نفسه مع بنية الخدمات المصغرة؟
- أولاً ، بمجرد تغيير مهاجم القبعة السوداء التاريخ ، سيلاحظون أن الخدمة المصغرة المعينة التي تحتوي على الخلل كانت معطلة.
- ثانيًا ، بافتراض أنهم يستخدمون الحاويات ، فإن توزيع Kubernetes الخاص بهم سيعلم أن الحاوية المعينة لا ترسل بيانات إخراج صالحة.
- أخيرًا ، إنها مسألة بسيطة تتمثل في قيام الفريق بإعادة إعدادات الحاوية المخالفة إلى ما قبل تغيير التاريخ الضار.
بمجرد الانتهاء من هذا التشخيص الأولي والحل البديل من خلال إعادة الإعداد ، يمكن للفريق بعد ذلك التحرك لإصلاح العيوب الأساسية التي أدت إلى ظهور الضعف. طوال هذه العملية بأكملها ، ظل تطبيق التقويم الأوسع – وكل ما يعتمد عليه – متصلاً بالإنترنت.
خدمات مصغرة لتحقيق الكفاءة والاستباقية
هناك خلاصة كبيرة من القصة أعلاه: في بنية الخدمات المصغرة ، يجب استبدال المكون المعيب فقط أو تحديثه ، وليس التطبيق بأكمله. وهذا يعني وقت تعطل أقل عند ظهور مشكلة أو ثغرة أمنية ، حيث يمكن للفرق تحديد وإرجاع خدمة مصغرة فردية تم اختراقها. علاوة على ذلك ، يؤدي هذا إلى عمل أقل لصالح DevOps وفرق الأمان في معالجة الخلل لأنهم يحتاجون فقط إلى إعادة صياغة خدمة مصغرة فردية ، والتي سيكون لها بالضرورة رمز تطبيق أقل من تطبيق monolithic كامل.
بالإضافة إلى ذلك ، تتيح الخدمات المصغرة للفرق أن تكون أكثر استباقية. تمكّن الخدمات المصغرة هذا الاستباقية من خلال المبارزة التي تمنع الاختراقات أو تسلسل نقاط الضعف. يحرر هذا المبارزة فرقًا لتحسين خدمة مصغرة فردية باستمرار دون الحاجة إلى التفكير في بقية التطبيق.
وهذا يعني أنه يمكن لمحترفي DevSecOps التركيز على مراقبة الثغرات الأمنية أو نشر تحديثات الأمان. ليست هناك حاجة لعمل إداري أو لوجستي لإيقاف التحديث الأمني من كسر خدمة مصغرة أخرى في التطبيق. عندما يتعلق الأمر بإصلاح ثغرات يوم الصفر أو تأمين تطبيقك ضد التهديدات الناشئة ، فإن هذه المرونة والحرية لا تقدر بثمن.
بسبب الخدمات المصغرة ، يمكن للفرق الاستجابة للتهديدات الأمنية بشكل أسرع وأكثر فعالية من أي وقت مضى. وعلى الجانب الاستباقي ، يمكن للخدمات المصغرة تمكين الفرق من تقوية أنظمتها بمعدل مذهل. إجمالاً ، هذا هو السبب في أن الخدمات المصغرة غيرت وجه أمن تكنولوجيا المعلومات للمؤسسات: فهي تتيح للمطورين والمشغلين وفرق الأمان العمل بشكل أسرع وبمرونة لا مثيل لها من قبل.
سيمون رايت هو مدير الحلول الإستراتيجية في المملكة المتحدة لشركة Red Hat.
صانعي القرار
مرحبًا بك في مجتمع VentureBeat!
DataDecisionMakers هو المكان الذي يمكن للخبراء ، بما في ذلك الأشخاص التقنيين الذين يقومون بعمل البيانات ، مشاركة الأفكار والابتكارات المتعلقة بالبيانات.
إذا كنت تريد أن تقرأ عن الأفكار المتطورة والمعلومات المحدثة ، وأفضل الممارسات ، ومستقبل البيانات وتكنولوجيا البيانات ، انضم إلينا في DataDecisionMakers.
يمكنك حتى التفكير في المساهمة بمقال خاص بك!
قراءة المزيد من DataDecisionMakers