إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
يتمثل أحد التحديات الهامة في تشغيل نظام معقد مثل Microsoft Azure في ضمان تشغيل البرامج المعتمدة فقط في النظام. يقدم البرنامج غير المصرح به العديد من المخاطر لأي عمل:
- المخاطر الأمنية، مثل أدوات الهجوم المخصصة والبرامج الضارة المخصصة وبرامج الجهات الخارجية ذات الثغرات الأمنية المعروفة
- مخاطر التوافق عندما لا يتم استخدام عملية إدارة التغيير المعتمدة لجلب برامج جديدة
- المخاطر العالية من البرمجيات المطورة خارجيا، والتي قد لا تلبي المتطلبات التشغيلية للأعمال
يواجه Azure نفس التحدي بتعقيد كبير. آلاف الخوادم تشغل برامج يطورها ويصانتها آلاف المهندسين. هذا الحجم يشكل سطح هجوم كبير لا تستطيع العمليات التجارية وحدها إدارته.
إضافة بوابة تخويل
يستخدم Azure عملية هندسية غنية تنفذ بوابات على الأمان والامتثال وجودة البرمجيات المنتشرة. تشمل هذه العملية التحكم في الوصول إلى الشيفرة المصدرية، ومراجعات الشيفرة النظرية، والتحليل الثابت للثغرات الأمنية، ودورة حياة تطوير الأمان (SDL) من Microsoft، والاختبارات الوظيفية والجودة. تحتاج Microsoft إلى ضمان تدفق البرمجيات المنشورة عبر هذه العملية. تساعد سلامة الكود في تحقيق هذا الضمان.
تكامل التعليمات البرمجية كبوابة تخويل
سلامة الكود هي خدمة على مستوى النواة أصبحت متاحة بدءا من Windows Server 2016. يمكن أن تطبق تكامل التعليمات البرمجية نهج تحكم تنفيذ صارمًا كلما تم تحميل برنامج تشغيل أو مكتبة مرتبطة ديناميكيا (DLL) أو تنفيذ ثنائي قابل للتنفيذ أو تشغيل برنامج نصي. توجد أنظمة مماثلة، مثل DM-Verity، لنظام Linux. تتكون سياسة سلامة الكود من مجموعة من مؤشرات التفويض، إما شهادات توقيع الشيفرة أو تجزئات ملفات SHA-256 ، والتي تطابق النواة قبل تحميل أو تنفيذ ملف ثنائي أو سكريبت.
تسمح سلامة الشيفرة لمسؤولي النظام بتحديد سياسة تخول فقط الملفات الثنائية والسكريبتات التي توقع عليها الشهادات المحددة أو التي تطابق تجزئات SHA-256 المحددة. تفرض النواة هذا النهج عن طريق حظر تنفيذ كل ما لا يفي بنهج المجموعة.
يمكن لسياسة سلامة الكود أن تمنع البرمجيات الحيوية في الإنتاج وتتسبب في انقطاع ما لم تكن السياسة صحيحة تماما. وبالنظر إلى هذا القلق، قد تتساءل لماذا المراقبة الأمنية غير كافية لاكتشاف تنفيذ البرامج غير المصرح بها. لدى سلامة الكود وضع تدقيق يمكنه بدلا من منع التنفيذ، تنبيه عند تشغيل برامج غير مصرح بها. يمكن أن تضيف التنبيهات قيمة كبيرة في معالجة مخاطر الامتثال. ومع ذلك، بالنسبة للمخاطر الأمنية مثل برامج الفدية أو البرمجيات الخبيثة المخصصة، فإن تأخير الاستجابة حتى لبضع ثوان قد يكون الفرق بين الحماية وحصول العدو على موطئ قدم دائم في أسطولك. في Azure، تستثمر Microsoft بشكل كبير لإدارة أي خطر من سلامة الشيفرة قد تساهم في انقطاع يؤثر على العملاء.
عملية الإنشاء
كما ذكر سابقا، يحتوي نظام بناء Azure على مجموعة غنية من الاختبارات لضمان أن التغييرات البرمجية آمنة ومتوافقة. بعد تقدم البناء عبر التحقق، يوقع نظام البناء عليه باستخدام شهادة بناء Azure. تشير الشهادة إلى أن البناء اجتاز كامل عملية إدارة التغيير. الاختبار النهائي الذي يمر به البناء هو التحقق من توقيع الشيفرة (CSV). تؤكد CSV أن الملفات الثنائية الجديدة تفي بسياسة سلامة الكود قبل أن تنشرها Microsoft في الإنتاج. هذا التحقق يمنح Microsoft ثقة عالية بأن الملفات الثنائية الموقعة بشكل خاطئ لن تسبب انقطاعا يؤثر على العملاء. إذا وجد CSV مشكلة، يتعطل البناء ويتم استدعاء المهندسين المعنيين للتحقيق وإصلاح المشكلة.
الأمان أثناء التوزيع
على الرغم من أن Azure ينفذ CSV لكل بناء، إلا أن بعض التغييرات أو عدم الاتساق في الإنتاج قد يسبب انقطاعا متعلقا بسلامة الكود. على سبيل المثال، قد يشغل جهاز نسخة قديمة من سياسة سلامة الكود، أو قد يكون في حالة غير صحية تنتج نتائج إيجابية كاذبة في سلامة الكود. على نطاق Azure، رأت Microsoft كل شيء. تواصل Azure الحماية من خطر الانقطاع أثناء الانتشار.
يجب أن تنتشر جميع التغييرات في Azure عبر سلسلة من المراحل. المراحل الأولى هي مثيلات اختبار داخلية في Azure. المرحلة التالية تخدم فقط فرق منتجات Microsoft الأخرى. تخدم المرحلة النهائية عملاء الجهات الخارجية. عندما ينشر Azure تغييرا، ينتقل التغيير إلى كل مرحلة بالتتابع ويتوقف لقياس صحة المرحلة. إذا لم يكن للتغيير أي تأثير سلبي، ينتقل إلى المرحلة التالية. إذا قامت Microsoft بإجراء تغيير سيء في سياسة سلامة الكود، فإن النشر المرحلي يكتشف التغيير ويعيده للخلف.
الاستجابة للحدث
حتى مع هذه الحماية الطبقية، قد يمنع خادم في الأسطول البرمجيات المصرح بها بشكل صحيح ويسبب مشكلة تواجه العملاء، وهو أحد أسوأ سيناريوهات Microsoft. الطبقة الأخيرة من الدفاع هي التحقيق البشري. في كل مرة تحظر فيها تكامل التعليمات البرمجية ملفاً، فإنه يثير تنبيهاً للمهندسين عند الطلب للتحقيق. يتيح هذا التنبيه للمهندسين بدء تحقيقات أمنية والتدخل، سواء كانت المشكلة مؤشرا على هجوم حقيقي، أو نتيجة إيجابية كاذبة، أو حالة تؤثر على العملاء. يقلل هذا التنبيه من الوقت اللازم للتخفيف من أي مشاكل تتعلق بسلامة الكود.
الخطوات التالية
لمعرفة المزيد عن كيفية دفع Microsoft لسلامة وأمان المنصة، انظر: