اعتبارات الأمان لأحمال العمل الحرجة للمهام على Azure

الأمن هو أحد مبادئ التصميم الأساسي وأيضا مجال تصميم رئيسي يجب التعامل معه على أنه مصدر قلق من الدرجة الأولى في العملية المعمارية الحرجة للمهمة.

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

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

هام

هذه المقالة هي جزء من سلسلة حمل العمل الحرجة للمهام Well-Architected Azure . إذا لم تكن على دراية بهذه السلسلة، نوصيك بالبدء بما هو حمل العمل الحرج للمهمة؟

مشروع مصدر مفتوح المهمة الحرجة

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

المحاذاة مع نموذج ثقة معدومة

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

اعتبارات التصميم

أثناء تقييم الوضع الأمني للتطبيق، ابدأ بهذه الأسئلة كأساس لكل اعتبار.

• اختبار الأمان المستمر للتحقق من عوامل التخفيف من المخاطر للثغرات الأمنية الرئيسية.

  • هل يتم إجراء اختبار الأمان كجزء من عمليات CI/CD التلقائية؟
  • إذا لم يكن الأمر كما هو، فكم مرة يتم إجراء اختبار أمان محدد؟
  • هل يتم قياس نتائج الاختبار مقابل الوضع الأمني المطلوب ونموذج التهديد؟

• مستوى الأمان عبر جميع البيئات السفلية.

  • هل تتمتع جميع البيئات داخل دورة حياة التطوير بنفس الوضع الأمني مثل بيئة الإنتاج؟

• استمرارية المصادقة والتخويل في حالة حدوث فشل.

  • إذا كانت خدمات المصادقة أو التخويل غير متوفرة مؤقتا، هل سيتمكن التطبيق من الاستمرار في العمل؟

• التوافق والمعالجة الأمنية التلقائية.

  • هل يمكن الكشف عن التغييرات التي تطرأ على إعدادات الأمان الرئيسية؟
  • هل الاستجابات لمعالجة التغييرات غير المتوافقة مؤتمتة؟

• فحص البيانات السرية للكشف عن الأسرار قبل الالتزام بالتعليمات البرمجية لمنع أي تسرب سري من خلال مستودعات التعليمات البرمجية المصدر.

  • هل المصادقة على الخدمات ممكنة دون الحاجة إلى بيانات الاعتماد كجزء من التعليمات البرمجية؟

• تأمين سلسلة توريد البرامج.

  • هل من الممكن تتبع نقاط الضعف والتعرض الشائعة (CVEs) ضمن تبعيات الحزمة المستخدمة؟
  • هل هناك عملية تلقائية لتحديث تبعيات الحزمة؟

• دورات حياة مفتاح حماية البيانات.

  • هل يمكن استخدام المفاتيح المدارة بواسطة الخدمة لحماية تكامل البيانات؟
  • إذا كانت المفاتيح التي يديرها العميل مطلوبة، فكيف تكون دورة حياة المفتاح آمنة وموثوقة؟

• يجب أن تتطلب أدوات CI/CD Microsoft Entra أساسيات الخدمة مع وصول كاف على مستوى الاشتراك لتسهيل الوصول إلى مستوى التحكم لعمليات توزيع موارد Azure لجميع اشتراكات البيئة المدروسة.

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

توصيات التصميم

• استخدم نهج Azure لفرض تكوينات الأمان والموثوقية لجميع الخدمة، مع التأكد من معالجة أي انحراف أو حظره بواسطة وحدة التحكم في وقت التكوين، مما يساعد على التخفيف من التهديدات المرتبطة بسيناريوهات "المسؤول الضار".

• استخدم Microsoft Entra إدارة الهويات المتميزة (PIM) ضمن اشتراكات الإنتاج لإبطال الوصول المستمر لمستوى التحكم إلى بيئات الإنتاج. سيؤدي ذلك إلى تقليل المخاطر التي تشكلها سيناريوهات "المسؤول الضار" بشكل كبير من خلال "عمليات التحقق والأرصدة" الإضافية.

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

• استخدم Microsoft Entra التحكم في الوصول المستند إلى الدور (RBAC) لتخويل مستوى البيانات مع جميع الخدمات التي تدعم القدرة.

• استخدم مكتبات مصادقة النظام الأساسي للهويات في Microsoft الطرف الأول داخل التعليمات البرمجية للتطبيق للتكامل مع Microsoft Entra ID.

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

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

• استخدم البنية الأساسية كتعلم برمجي (IaC) وتدفقات CI/CD التلقائية لدفع التحديثات لجميع مكونات التطبيق، بما في ذلك في ظروف الفشل.

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

• حدد وضعا أمنيا مناسبا لجميع البيئات السفلية لضمان تخفيف الثغرات الأمنية الرئيسية.

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

• تمكين Microsoft Defender للسحابة (المعروف سابقا باسم Azure Security Center) لجميع الاشتراكات التي تحتوي على الموارد لحمل عمل مهم للمهمة.

  • استخدم نهج Azure لفرض التوافق.
  • تمكين Azure Defender لجميع الخدمات التي تدعم الإمكانية.

• احتضان DevSecOps وتنفيذ اختبار الأمان داخل البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD.

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

• تمكين مسح البيانات السرية وفحص التبعية داخل مستودع التعليمات البرمجية المصدر.

نماذج التهديدات

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

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

1. النظام الأساسي ل Azure مع قدرات وعناصر تحكم أمان أساسية.
2. تصميم بنية التطبيق والأمان.
3. ميزات الأمان المضمنة والممكنة والقابلة للتوزيع المطبقة لتأمين موارد Azure.
4. التعليمات البرمجية للتطبيق ومنطق الأمان.
5. العمليات التشغيلية وDevSecOps.

ملاحظة

عند النشر داخل منطقة هبوط Azure، يجب أن تدرك أن طبقة تخفيف المخاطر الإضافية من خلال توفير قدرات الأمان المركزية يتم توفيرها من خلال تنفيذ المنطقة المنتقل إليها.

اعتبارات التصميم

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

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

توصيات التصميم

• تخصيص ميزانية هندسية داخل كل دورة متكررة لتقييم التهديدات الجديدة المحتملة وتنفيذ عوامل التخفيف من المخاطر.

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

• ابدأ بخدمة حسب نمذجة التهديد على مستوى الخدمة وتوحيد النموذج عن طريق دمج نموذج مؤشر الترابط على مستوى التطبيق.

حماية اختراق الشبكة

يعد منع الوصول غير المصرح به إلى تطبيق مهم للغاية والبيانات الشاملة أمرا حيويا للحفاظ على التوفر وحماية سلامة البيانات.

اعتبارات التصميم

• يفترض ثقة معدومة حالة خرق ويتحقق من كل طلب كما لو كان ينشأ من شبكة غير خاضعة للرقابة.

  • يستخدم تنفيذ شبكة الثقة المعدومة المتقدمة التجزئة الصغيرة والموزعة في محيط صغير للدخول/الخروج.

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

  • توفر Azure Private Link/Private Endpoints وصولا مخصصا إلى مورد Azure PaaS باستخدام عناوين IP الخاصة واتصال الشبكة الخاصة.
  • توفر نقاط نهاية خدمة الشبكة الظاهرية وصولا على مستوى الخدمة من الشبكات الفرعية المحددة إلى خدمات PaaS المحددة.
  • يوفر إدخال الشبكة الظاهرية عمليات نشر خاصة مخصصة للخدمات المدعومة، مثل App Service من خلال App Service Environment.
    • لا تزال نسبة استخدام الشبكة لمستوى الإدارة تتدفق عبر عناوين IP العامة.

• بالنسبة للخدمات المدعومة، يعالج Azure Private Link باستخدام نقاط النهاية الخاصة Azure مخاطر النقل غير المصرح للبيانات المرتبطة بنقاط نهاية الخدمة، مثل مسؤول ضار يكتب البيانات إلى مورد خارجي.

• عند تقييد الوصول إلى الشبكة إلى خدمات Azure PaaS باستخدام نقاط النهاية الخاصة أو نقاط نهاية الخدمة، ستكون هناك حاجة إلى قناة شبكة آمنة للبنية الأساسية لبرنامج ربط العمليات التجارية للتوزيع للوصول إلى كل من مستوى التحكم في Azure ومستوى البيانات لموارد Azure من أجل نشر التطبيق وإدارته.

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

• يعد إكمال مهام الإدارة والصيانة سيناريو آخر يتطلب الاتصال بمستوى بيانات موارد Azure.

• يمكن استخدام Connections الخدمة مع كيان خدمة Microsoft Entra مطابق داخل Azure DevOps لتطبيق التحكم في الوصول استنادا إلى الدور من خلال Microsoft Entra ID.

• يمكن تطبيق علامات الخدمة على مجموعات أمان الشبكة لتسهيل الاتصال بخدمات Azure PaaS.

• لا تمتد مجموعات أمان التطبيقات عبر شبكات ظاهرية متعددة.

• يقتصر التقاط الحزمة في Azure Network Watcher على فترة أقصاها خمس ساعات.

توصيات التصميم

• تقييد وصول الشبكة العامة إلى الحد الأدنى المطلق المطلوب للتطبيق لتحقيق الغرض من عمله لتقليل سطح الهجوم الخارجي.

  • استخدم Azure Private Link لإنشاء نقاط نهاية خاصة لموارد Azure التي تتطلب تكامل شبكة آمنة.
  • استخدم عوامل الإنشاء الخاصة المستضافة لأأداة CI/CD لتوزيع موارد Azure المحمية بواسطة Azure Private Link وتكوينها.
    • لن يتمكن الوكلاء المستضافون من Microsoft من الاتصال مباشرة بالموارد المتكاملة للشبكة.

• عند التعامل مع وكلاء البناء الخاصين، لا تفتح أبدا منفذ RDP أو SSH مباشرة على الإنترنت.

  • استخدم Azure Bastion لتوفير وصول آمن إلى أجهزة Azure الظاهرية وتنفيذ المهام الإدارية على Azure PaaS عبر الإنترنت.

• استخدم خطة حماية قياسية ل DDoS لتأمين جميع عناوين IP العامة داخل التطبيق.

• استخدم Azure Front Door مع نهج جدار حماية تطبيق الويب لتقديم تطبيقات HTTP/S العالمية التي تمتد عبر مناطق Azure المتعددة والمساعدة في حمايتها.

  • استخدم التحقق من صحة معرف الرأس لتأمين نقاط نهاية التطبيق العامة بحيث تقبل نسبة استخدام الشبكة التي تنشأ من مثيل Azure Front Door فقط.

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

• إذا كانت متطلبات التقاط الحزم موجودة، فاستخدم حزم Network Watcher لالتقاطها على الرغم من نافذة الالتقاط المحدودة.

• استخدم مجموعات أمان الشبكة ومجموعات أمان التطبيقات لنسبة استخدام الشبكة للتطبيقات الصغيرة.

  • تجنب استخدام جهاز أمان لتصفية تدفقات نسبة استخدام الشبكة داخل التطبيق.
  • ضع في اعتبارك استخدام نهج Azure لفرض قواعد NSG محددة ترتبط دائما بالشبكات الفرعية للتطبيق.

• تمكين سجلات تدفق NSG وإطعامها في تحليلات نسبة استخدام الشبكة للحصول على رؤى حول تدفقات نسبة استخدام الشبكة الداخلية والخارجية.

• استخدم Azure Private Link/Private Endpoints، حيثما كان ذلك متاحا، لتأمين الوصول إلى خدمات Azure PaaS ضمن تصميم التطبيق. للحصول على معلومات حول خدمات Azure التي تدعم Private Link، راجع توفر Azure Private Link.

• إذا لم تكن نقطة النهاية الخاصة متوفرة ومخاطر النقل غير المصرح للبيانات مقبولة، فاستخدم نقاط نهاية خدمة الشبكة الظاهرية لتأمين الوصول إلى خدمات Azure PaaS من داخل شبكة ظاهرية.

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

• بالنسبة لسيناريوهات التطبيق المختلط، قم بالوصول إلى خدمات Azure PaaS من أماكن العمل عبر ExpressRoute مع التناظر الخاص.

ملاحظة

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

حماية تكامل البيانات

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

اعتبارات التصميم

• يحتوي Azure Key Vault على حدود المعاملات للمفاتيح والأسرار، مع تطبيق التقييد لكل مخزن خلال فترة معينة.

• يوفر Azure Key Vault حد أمان حيث يتم تطبيق أذونات الوصول للمفاتيح والأسرار والشهادات على مستوى المخزن.

  • Key Vault تمنح تعيينات نهج الوصول أذونات بشكل منفصل للمفاتيح أو الأسرار أو الشهادات.
    • أصبح من الممكن الآن الحصول على أذونات دقيقة على مستوى الكائن لمفتاح أو سر أو شهادة معينة.

• بعد تغيير تعيين الدور، هناك زمن انتقال يصل إلى 10 دقائق (600 ثانية) للدور الذي سيتم تطبيقه.

  • هناك حد يبلغ 2000 تعيين دور Azure لكل اشتراك.

• تحتوي وحدات أمان الأجهزة الأساسية (HSMs) في Azure Key Vault على التحقق من صحة FIPS 140.

  • يتوفر Azure Key Vault HSM مدار مخصص للسيناريوهات التي تتطلب توافق FIPS 140-2 المستوى 3.

• يوفر Azure Key Vault قابلية وصول وتكرار عالية للمساعدة في الحفاظ على التوفر ومنع فقدان البيانات.

• أثناء تجاوز فشل المنطقة، قد يستغرق الأمر بضع دقائق حتى تتجاوز خدمة Key Vault الفشل.

  • أثناء تجاوز الفشل، سيكون Key Vault في وضع القراءة فقط، لذلك لن يكون من الممكن تغيير خصائص مخزن المفاتيح مثل تكوينات جدار الحماية والإعدادات.

• إذا تم استخدام ارتباط خاص للاتصال ب Azure Key Vault، فقد يستغرق الأمر ما يصل إلى 20 دقيقة لإعادة إنشاء الاتصال أثناء تجاوز الفشل الإقليمي.

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

  • قد يتم تجديد الأسرار أثناء النسخ الاحتياطي، مما يتسبب في عدم التطابق.

• باستخدام المفاتيح المدارة بواسطة الخدمة، سيقوم Azure بأداء وظائف إدارة المفاتيح، مثل التدوير، وبالتالي تقليل نطاق عمليات التطبيق.

• قد تنص الضوابط التنظيمية على استخدام المفاتيح التي يديرها العميل لوظائف تشفير الخدمة.

• عندما تنتقل نسبة استخدام الشبكة بين مراكز بيانات Azure، يتم استخدام تشفير طبقة ارتباط بيانات MACsec على أجهزة الشبكة الأساسية لتأمين البيانات أثناء النقل خارج الحدود المادية التي لا تتحكم فيها Microsoft أو نيابة عن Microsoft.

توصيات التصميم

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

  • استخدم المفاتيح التي يديرها العميل فقط عندما يكون هناك شرط تنظيمي واضح للقيام بذلك.

• استخدم Azure Key Vault كمستودع آمن لجميع الأسرار والشهادات والمفاتيح إذا كانت هناك حاجة إلى مراعاة آليات تشفير إضافية أو مفاتيح يديرها العميل.

  • توفير Key Vault Azure مع تمكين نهج الحذف والإزالة المبدئية للسماح بحماية الاستبقاء للكائنات المحذوفة.
  • استخدم Azure Key Vault SKU المدعوم من HSM لبيئات إنتاج التطبيقات.

• توزيع مثيل Azure Key Vault منفصل داخل كل طابع توزيع إقليمي، ما يوفر مزايا عزل الخطأ والأداء من خلال الترجمة، بالإضافة إلى التنقل في حدود المقياس التي يفرضها مثيل Key Vault واحد.

  • استخدم مثيل Azure Key Vault مخصص للموارد العمومية للتطبيق.

• اتبع نموذج الامتياز الأقل عن طريق تقييد التخويل لحذف البيانات السرية والمفاتيح والشهادات بشكل دائم إلى أدوار Microsoft Entra مخصصة متخصصة.

• تأكد من نسخ مفاتيح التشفير والشهادات المخزنة داخل Key Vault احتياطيا، ما يوفر نسخة غير متصلة في الحدث غير المحتمل Key Vault يصبح غير متوفر.

• استخدم شهادات Key Vault لإدارة شراء الشهادات وتوقيعها.

• إنشاء عملية تلقائية لتناوب المفاتيح والشهادات.

  • أتمتة إدارة الشهادات وعملية التجديد مع المراجع المصدقة العامة لتسهيل الإدارة.
    • قم بتعيين التنبيه والإعلامات، لتكملة عمليات تجديد الشهادة التلقائية.

• مراقبة استخدام المفتاح والشهادة والبيانات السرية.

  • حدد التنبيهات للاستخدام غير المتوقع داخل Azure Monitor.

التحكم المستند على السياسات

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

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

اعتبارات التصميم

• يوفر نهج Azure آلية لدفع التوافق من خلال فرض اصطلاحات الأمان والموثوقية، مثل استخدام نقاط النهاية الخاصة أو استخدام مناطق التوفر.

ملاحظة

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

• يمكن استخدام نهج Azure لدفع أنشطة الإدارة التلقائية، مثل التوفير والتكوين.

  • تسجيل موفر الموارد.
  • التحقق من صحة تكوينات موارد Azure الفردية والموافقة عليها.

• يحدد نطاق تعيين نهج Azure التغطية ويعلم موقع تعريفات نهج Azure إمكانية إعادة استخدام النهج المخصصة.

• يحتوي نهج Azure على عدة حدود، مثل عدد التعريفات في أي نطاق معين.

• قد يستغرق تنفيذ نهج Deploy If Not Exist (DINE) عدة دقائق.

• يوفر Azure Policy إدخالا مهما لإعداد تقارير التوافق وتدقيق الأمان.

توصيات التصميم

• تعيين المتطلبات التنظيمية والامتثال إلى تعريفات نهج Azure.

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

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

  • على سبيل المثال، قم بتطبيق نهج Azure لفرض استخدام مناطق التوفر لجميع الخدمات ذات الصلة، ما يضمن تكوينات توزيع موثوقة داخل المنطقة.

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

• مراقبة انحراف تكوين الخدمة، بالنسبة لمعايير الهندسة الشائعة، باستخدام نهج Azure.

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

• استخدم النهج المضمنة حيثما أمكن لتقليل النفقات التشغيلية للحفاظ على تعريفات النهج المخصصة.

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

  • عند محاذاة مخطط التطبيق مع مخططات Azure، استخدم موارد Microsoft المتوفرة لاستكشاف ما إذا كان يمكن دمج التعريفات المخصصة الهامة كتعريفات مضمنة.

ملاحظة

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

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

إذا كان التطبيق مشتركا في دعم Microsoft Mission-Critical، فتأكد من أن مخطط وضع العلامات المطبق يوفر سياقا ذا معنى لإثراء تجربة الدعم بفهم عميق للتطبيق.

• تصدير سجلات نشاط Microsoft Entra إلى مساحة عمل Log Analytics العمومية التي يستخدمها التطبيق.
  • تأكد من أرشفة سجلات نشاط Azure داخل حساب التخزين العمومي جنبا إلى جنب مع البيانات التشغيلية للاحتفاظ بها على المدى الطويل.

في منطقة Azure المنتقل إليها، سيتم أيضا استيعاب سجلات نشاط Microsoft Entra في مساحة عمل Log Analytics للنظام الأساسي المركزي. يجب تقييمه في هذه الحالة إذا كانت Microsoft Entra ID لا تزال مطلوبة في مساحة عمل Log Analytics العمومية.

• دمج معلومات الأمان وإدارة الأحداث مع Microsoft Defender للسحابة (المعروف سابقا باسم مركز أمان Azure).

اعتبارات خاصة ب IaaS عند استخدام الأجهزة الظاهرية

في السيناريوهات التي يكون فيها استخدام أجهزة IaaS الظاهرية مطلوبا، يجب مراعاة بعض التفاصيل.

اعتبارات التصميم

• لا يتم تحديث الصور تلقائيا بمجرد نشرها.
• لا يتم تثبيت التحديثات تلقائيا على تشغيل الأجهزة الظاهرية.
• عادة ما لا يتم تقوية الصور والأجهزة الظاهرية الفردية خارج الصندوق.

توصيات التصميم

• لا تسمح بالوصول المباشر عبر الإنترنت العام إلى الأجهزة الظاهرية من خلال توفير الوصول إلى SSH أو RDP أو بروتوكولات أخرى. استخدم دائما Azure Bastion و jumpboxes مع وصول محدود إلى مجموعة صغيرة من المستخدمين.
• تقييد الاتصال المباشر بالإنترنت باستخدام مجموعات أمان الشبكة أو جدار الحماية (Azure) أو Application Gateways (المستوى 7) لتصفية حركة الخروج وتقييدها.
• بالنسبة للتطبيقات متعددة المستويات، ضع في اعتبارك استخدام شبكات فرعية مختلفة واستخدام مجموعات أمان الشبكة لتقييد الوصول بينهما.
• تحديد أولويات استخدام مصادقة المفتاح العام، عندما يكون ذلك ممكنا. تخزين البيانات السرية في مكان آمن مثل Azure Key Vault.
• حماية الأجهزة الظاهرية باستخدام المصادقة والتحكم في الوصول.
• تطبيق نفس الممارسات الأمنية كما هو موضح لسيناريوهات التطبيقات الحرجة للمهام.

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

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

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

الإجراءات التشغيلية