تطبيقات الويب المُدارة بأمان

Azure App Service
Azure Application Gateway
Azure SQL Database
Azure VPN Gateway
Azure Web Application Firewall

توفر هذه المقالة نظرة عامة على نشر التطبيقات الآمنة باستخدام بيئة خدمة تطبيقات Azure. لتقييد الوصول إلى التطبيق من الإنترنت، يتم استخدام خدمة Azure Application Gateway وAzure Web Application Firewall . توفر هذه المقالة أيضاً إرشادات حول التكامل المستمر والنشر المستمر (CI/CD) لبيئات خدمة التطبيقات باستخدام Azure DevOps.

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

حالات الاستخدام المحتملة

يجب وضع هذا السيناريو في الاعتبار لحالات الاستخدام التالية:

  • إنشاء Azure Web App حيث يلزم توفر أمان إضافي.
  • توفير الإيجار المخصص، بدلاً من خطط خدمة التطبيقات للمستأجر المشترك.
  • استخدام Azure DevOps مع بيئة خدمة تطبيق متوازنة التحميل داخليا (ILB).

الهندسة

Diagram featuring the sample scenario architecture for Secure ILB App Service Environment Deployment.

قم بتنزيل ملف Visio لهذه البنية.

تدفق البيانات

  1. تصل طلبات HTTP/HTTPS أولاً إلى Application Gateway.
  2. اختياريا (غير موضح في الرسم التخطيطي)، يمكنك تمكين مصادقة Microsoft Entra لتطبيق الويب. بعد أن تصل حركة المرور أولا إلى بوابة التطبيق، ستتم مطالبة المستخدم بتوفير بيانات الاعتماد للمصادقة مع التطبيق.
  3. تتدفق طلبات المستخدم من خلال موازن التحميل الداخلي (ILB) للبيئة، والذي بدوره يوجه حركة المرور إلى Expenses Web App.
  4. ثم ينتقل المستخدم لإنشاء تقرير نفقات.
  5. باعتباره جزء من إنشاء تقرير النفقات، يتم استدعاء تطبيق API المنشور لاسترداد اسم مدير المستخدم وعنوان البريد الإلكتروني.
  6. يتم تخزين تقرير النفقات الذي تم إنشاؤه في قاعدة بيانات Azure SQL.
  7. لتسهيل النشر المستمر، يتم إيداع التعليمات البرمجية في مثيل Azure DevOps.
  8. يحتوي الجهاز الظاهري للإنشاء على عامل Azure DevOps مثبت، مما يسمح للجهاز الظاهري للبناء بسحب وحدات البت لتطبيق الويب للتوزيع في بيئة خدمة التطبيقات (حيث يتم نشر إنشاء الجهاز الظاهري في شبكة فرعية داخل نفس الشبكة الظاهرية).

المكونات

  • توفر بيئة خدمة التطبيقات بيئة مخصصة معزولة تماماً لتشغيل التطبيق بأمان على نطاق واسع. بالإضافة إلى ذلك، نظرا لأن App Service Environment وأحمال العمل التي تعمل عليها خلف شبكة ظاهرية، فإنها توفر أيضا طبقة إضافية من الأمان والعزل. أدى متطلبات النطاق العالي والعزلة إلى اختيار بيئة خدمة تطبيق ILB.
  • يستخدم حمل العمل هذا مستوى تسعير App Service المعزول، لذلك يعمل التطبيق في بيئة مخصصة خاصة في مركز بيانات Azure باستخدام معالجات أسرع وتخزين SSD ومضاعفة نسبة الذاكرة إلى الذاكرة الأساسية مقارنة ب Standard.
  • يستضيف تطبيق ويب خدمة تطبيق Azure وتطبيق API تطبيقات الويب وواجهات برمجة تطبيقات RESTful. تتم استضافة هذه التطبيقات وواجهات برمجة التطبيقات على خطة الخدمة المعزولة، والتي تقدم أيضا تغيير الحجم التلقائي والمجالات المخصصة وما إلى ذلك، ولكن في مستوى مخصص.
  • إن Azure Application Gateway هو موازن تحميل نسبة استخدام الشبكة على الويب يعمل في الطبقة 7 التي تدير نسبة استخدام الشبكة إلى تطبيقات الويب. يوفر إلغاء تحميل SSL، ما يزيل الحمل الإضافي من خوادم الويب التي تستضيف تطبيق الويب لفك تشفير حركة المرور مرة أخرى.
  • جدار حماية تطبيق الويب (WAF) هو إحدى ميزات Application Gateway. تمكين WAF في Application Gateway يعزز الأمان بصورة أكبر. يستخدم WAF قواعد OWASP لحماية تطبيق الويب من هجمات مثل البرمجة النصية عبر المواقع واختطاف الجلسة وإدخال SQL.
  • تم تحديد قاعدة بيانات Azure SQL لأن معظم البيانات في هذا التطبيق هي بيانات ارتباطية، مع بعض البيانات كمستندات والكائنات الثنائية كبيرة الحجم.
  • توفر شبكة Azure إمكانات شبكة مختلفة في Azure، ويمكن تناظر الشبكات مع الشبكات الظاهرية الأخرى في Azure. يمكن أيضا إنشاء الاتصال مع مراكز البيانات المحلية عبر ExpressRoute أو من موقع إلى موقع. في هذه الحالة، يتم تمكين نقطة تقديم الخدمة على الشبكة الظاهرية لضمان تدفق البيانات فقط بين شبكة Azure الظاهرية ومثيل قاعدة بيانات SQL.
  • يتم استخدام Azure DevOps لمساعدة الفرق على التعاون أثناء الدورات المتكررة، باستخدام الميزات التي تدعم التطوير السريع، وإنشاء البنية الأساسية لبرنامج ربط العمليات التجارية للإنشاء والإصدار.
  • تم إنشاء جهاز ظاهري لبنية Azure بحيث يمكن للعامل المثبت سحب البنية المعنية ونشر تطبيق الويب في البيئة.

البدائل

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

  • Azure Service Fabric: إذا كانت بيئتك مستندة في الغالب إلى Windows، وأحمال العمل الخاصة بك تستند في المقام الأول إلى .NET Framework، ولا تفكر في إعادة التصميم إلى .NET Core، فاستخدم Service Fabric لدعم حاويات Windows Server ونشرها. بالإضافة إلى ذلك، يدعم Service Fabric واجهات برمجة تطبيقات البرمجة C# أو Java، ومن أجل تطوير الخدمات المصغرة الأصلية، يمكن توفير المجموعات على Windows أو Linux.
  • خدمة Azure Kubernetes (AKS) هي مشروع مفتوح المصدر ومنصة تنسيق أكثر ملاءمة لاستضافة تطبيقات متعددة الحاويات المعقدة التي تستخدم عادة بنية مستندة إلى الخدمات المصغرة. AKS هي خدمة Azure مدارة تلخص تعقيدات توفير نظام مجموعة Kubernetes وتكوينها. ومع ذلك، يلزم معرفة كبيرة بمنصة Kubernetes لدعمها وصيانتها، لذلك قد لا تكون استضافة عدد قليل من تطبيقات الويب المعبأة في حاويات أحادية المثيل الخيار الأفضل.

تشمل الخيارات الأخرى لطبقة البيانات ما يلي:

  • Azure Cosmos DB: إذا كانت معظم بياناتك بتنسيق غير علائقي، فإن Azure Cosmos DB هو بديل جيد. توفر هذه الخدمة نظاما أساسيا لتشغيل نماذج بيانات أخرى مثل MongoDB أو Cassandra أو بيانات Graph أو تخزين جدول بسيط.

الاعتبارات

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

لا يمكنك إصدار CSR من موازن التحميل الداخلي (ILB) لبيئة خدمة التطبيقات. طريقة التعامل مع هذا القيد هي استخدام إجراء حرف البدل.

يسمح لك إجراء حرف البدل باستخدام إثبات ملكية اسم DNS بدلا من CSR. إذا كنت تملك مساحة اسم DNS، يمكنك وضع سجل DNS TXT خاص، يتحقق إجراء حرف البدل من وجود السجل، وإذا تم العثور عليه، يعرف أنك تملك خادم DNS لأن لديك السجل الصحيح. استناداً إلى هذه المعلومات، فإنه يصدر شهادة تم تسجيلها إلى جذر موثوق به، والتي يمكنك تحميلها بعد ذلك إلى ILB الخاص بك. لا يلزمك إجراءات مع مخازن الشهادات الفردية على تطبيقات الويب لأن لديك شهادة SSL جذر موثوق بها في ILB.

اجعل شهادة SSL موقعة ذاتيا أو صادرة داخليا تعمل إذا كنت تريد إجراء مكالمات آمنة بين الخدمات التي تعمل في بيئة خدمة تطبيق ILB. حل آخر للنظر في كيفية جعل ILB App Service Environment تعمل مع شهادة SSL الصادرة داخليا وكيفية تحميل المرجع المصدق الداخلي إلى مخزن الجذر الموثوق به.

أثناء توفير App Service Environment، ضع في اعتبارك القيود التالية عند اختيار اسم مجال للبيئة. لا يمكن أن تكون أسماء المجالات:

  • net
  • azurewebsites.net
  • p.azurewebsites.net
  • nameofthease.p.azurewebsites.net

بالإضافة إلى ذلك، لا يمكن أن يتداخل اسم المجال المخصص المستخدم للتطبيقات واسم المجال المستخدم من قبل بيئة خدمة تطبيق ILB. بالنسبة لبيئة خدمة تطبيق ILB مع اسم المجال contoso.com، لا يمكنك استخدام أسماء مجالات مخصصة لتطبيقاتك مثل:

  • www.contoso.com
  • abcd.def.contoso.com
  • abcd.contoso.com

اختر مجالا لبيئة خدمة تطبيقات ILB التي لن تتعارض مع أسماء المجالات المخصصة هذه. يمكنك استخدام شيء مثل contoso-internal.com لمجال البيئة الخاصة بك لهذا المثال، لأن ذلك لن يتعارض مع أسماء المجالات المخصصة التي تنتهي ب .contoso.com.

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

التوافر

قابلية التوسع

الأمان

مرونة

نشر هذا السيناريو

لنشر هذا السيناريو، اتبع هذا البرنامج التعليمي خطوة بخطوة الذي يوضح كيفية نشر كل مكون يدويا. حدد App Service Environment v3 بدلا من v2، عند اتباع البرنامج التعليمي. يوفر هذا البرنامج التعليمي أيضاً نموذج تطبيق .NET الذي يشغّل تطبيق إعداد بسيط لتقارير نفقات Contoso.

التسعير

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

لقد قدمنا ثلاثة نماذج من ملفات تعريف التكلفة استنادا إلى مقدار نسبة استخدام الشبكة التي تتوقع الحصول عليها:

  • صغير: يمثل مثال التسعير هذا المكونات الضرورية للحد الأدنى لمثيل مستوى الإنتاج الذي يخدم بضعة آلاف من المستخدمين شهريا. يستخدم التطبيق مثيلاً واحداً لتطبيق ويب قياسي سيكون كافياً لتمكين التحجيم التلقائي. يتم تحجيم كل مكون من المكونات الأخرى إلى مستوى أساسي يقلل من التكلفة ولكنه لا يزال يضمن وجود دعم اتفاقية مستوى الخدمة والقدرة الكافية للتعامل مع حمل العمل على مستوى الإنتاج.
  • متوسط: يمثل مثال التسعير هذا المكونات المطلوبة لنشر متوسط الحجم. هنا نقدر ما يقرب من 100,000 مستخدم على مدار شهر. تتم معالجة نسبة استخدام الشبكة المتوقعة في مثيل خدمة تطبيق واحد بطبقة قياسية متوسطة. بالإضافة إلى ذلك، تُضاف مستويات متوسطة من الخدمات المعرفية وخدمات البحث إلى الحاسبة.
  • كبير: يوضح مثال التسعير هذا تطبيقاً معنيًا بالتحجيم العالي، بترتيب ملايين المستخدمين شهرياً، عند نقل تيرابايت من البيانات. في هذا المستوى من الاستخدام، يلزم وجود تطبيقات ويب عالية الأداء وطبقة متميزة موزعة في مناطق متعددة أمام إدارة نسبة استخدام الشبكة. تتكون البيانات من المكونات التالية: التخزين وقواعد البيانات وCDN، وكلها تم تكوينها لتيرا بايت من البيانات.

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكاتب الرئيسي:

  • فيصل مصطفى | مهندس عملاء أول

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