لقد رأيت هذا السيناريو كثيراً. التطبيق جاهز. العرض التوضيحي رائع. ثم تظهر قائمة التحقق الأمنية: إزالة التخزين من الإنترنت العام، والتشغيل داخل شبكة افتراضية، وتوفير عناوين IP الصادرة لقائمة السماح لدى الشريك، وإثبات أن الشبكات الفرعية الصحيحة فقط تتواصل مع الخدمات الصحيحة.
عند هذه النقطة، يبدأ نموذج التطبيق ونموذج البنية التحتية في الانحراف بطرق يصعب الحفاظ عليها.
يعالج دعم Aspire الجديد لشبكات Azure المؤسسية هذه المشكلة مباشرةً. تصف شكل الشبكة في AppHost بجانب الموارد التي تستخدمها.
المكونات الأساسية
فيما يلي ما يخدمه كل مفهوم من مفاهيم شبكات Azure، موجزاً:
| الميزة | متى تستخدمها | لماذا هي مهمة |
|---|---|---|
| الشبكة الافتراضية | عندما تحتاج إلى مساحة عناوين خاصة | حدود الشبكة للشبكات الفرعية ونقاط النهاية الخاصة والتوجيه |
| الشبكة الفرعية | عندما تحتاج إلى فصل أحمال العمل داخل الشبكة الافتراضية | تحصل كل جزء من النظام على نطاق عناوينه الخاص وسطح سياسته |
| الشبكة الفرعية المفوضة | عندما تحتاج خدمة النظام الأساسي (مثل ACA) إلى إدارة الشبكة الفرعية | تسمح للخدمة بوضع البنية التحتية المدارة بأمان في شبكتك الافتراضية |
| بوابة NAT | عندما تحتاج إلى عناوين IP عامة صادرة يمكن التنبؤ بها | عنوان مستقر لقوائم السماح والتدقيق |
| نقطة النهاية الخاصة | عندما تريد إمكانية الوصول إلى مورد PaaS بشكل خاص | يضع عنوان IP خاصاً لتلك الخدمة داخل شبكتك الافتراضية، ويزيل التعرض العام |
| مجموعة أمان الشبكة | عندما تحتاج إلى قواعد حركة مرور على مستوى الشبكة الفرعية | السماح/الرفض الصريح لحركة المرور الواردة والصادرة لكل شبكة فرعية |
الوصف في AppHost
التحول الرئيسي هنا هو أنك تنمذج الشبكة بجانب الموارد التي تستخدمها، وليس في ملف Bicep منفصل ينحرف مع نموذج التطبيق بمرور الوقت.
من AppHost يمكنك:
- إنشاء شبكات افتراضية وشبكات فرعية باستخدام
AddVirtualNetwork()وAddSubnet() - إرفاق بوابة NAT بالشبكات الفرعية للحصول على عناوين IP صادرة مستقرة
- إنشاء نقاط نهاية خاصة للتخزين وKey Vault وSQL وخدمات PaaS الأخرى
- تعريف مجموعات أمان الشبكة بقواعد أمان واردة وصادرة
- تكوين حدود أمان الشبكة لسياسات عبر الموارد
والنتيجة هي أنه عند تشغيل azd up، تتطابق البنية التحتية مع ما يقوله نموذج التطبيق أنه يحتاجه. وليس ما يقوله القالب المُدار يدوياً.
لماذا هذا مهم للتطبيقات الحقيقية
بعض الأشياء التي تصبح أسهل بكثير بمجرد نمذجة الشبكة في Aspire:
نقاط النهاية الخاصة لـ Key Vault والتخزين — تصف WithPrivateEndpoint() على تلك الموارد، ويتولى Aspire تكوين منطقة DNS وإرفاق نقطة النهاية. لن يتغير التطبيق أبداً.
عناوين IP صادرة متسقة — أضف بوابة NAT إلى الشبكة الفرعية ذات الصلة، وسيمر كل طلب صادر من تطبيقك عبر عنوان IP معروف ومستقر. يمكن للشركاء إضافته إلى قائمة السماح. يمكن للمدققين تتبعه.
قواعد مجموعة أمان الشبكة من الكود — بدلاً من النقر في البوابة أو الحفاظ على مقتطف Bicep، تعيش قواعد الأمان الخاصة بك في AppHost بجانب الموارد التي تحميها.
هذا هو نوع التكامل الذي لا يجعل العروض التوضيحية مثيرة، لكنه يجعل أنظمة الإنتاج قابلة للصيانة.
خلاصة
ظهور أمان الشبكة في مرحلة متأخرة من دورة حياة المشروع هو مشكلة محلولة إذا نمذجتها مع التطبيق من البداية. يجعل دعم شبكات Aspire المؤسسية هذا ممكناً دون الحاجة إلى مسار بنية تحتية منفصل.
التفاصيل الكاملة في المنشور الأصلي: Securing Azure apps with Aspire enterprise networking
