الاستعداد لنشر حمل عمل تطبيق الويب Amazon Web Services (AWS) على Azure

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

نشر Yelb على AWS

يتم نشر نموذج تطبيق الويب Yelb على AWS باستخدام Bash، AWS CLI، eksctl، kubectl، Helm. يحتوي نموذج المصاحب على البرامج النصية Bash وبيانات YAML التي يمكنك استخدامها لأتمتة نشر تطبيق Yelb على AWS Elastic Kubernetes Service (EKS). يوضح هذا الحل كيفية تنفيذ جدار حماية تطبيق ويب باستخدام AWS WAF لحماية تطبيق ويب يعمل على Amazon Elastic Kubernetes Service (EKS). يمكنك استخدام البرامج النصية Bash لإنشاء نظام مجموعة EKS ونشر تطبيق Yelb. يتعرض تطبيق الويب Yelb للإنترنت العام باستخدام Amazon Application Load Balancer (ALB) ومحمي باستخدام قائمة التحكم في الوصول إلى الويب AWS WAF (web ACL). للحصول على إرشادات مفصلة، راجع تصدير تطبيق ويب من خدمة AWS Elastic Kubernetes (EKS) إلى خدمة Azure Kubernetes (AKS).

لقطة شاشة لواجهة خدمة Yelb.

نشر Yelb على Azure

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

يدعم نموذج المصاحب تثبيت وحدة تحكم دخول NGINX مدارة مع الوظيفة الإضافية لتوجيه التطبيق أو وحدة تحكم دخول غير مدارة NGINX باستخدام مخطط Helm. توفر الوظيفة الإضافية لتوجيه التطبيق مع وحدة تحكم دخول NGINX الميزات التالية:

  • تكوين سهل لوحدات تحكم دخول NGINX المدارة استنادا إلى وحدة تحكم دخول Kubernetes NGINX.
  • التكامل مع Azure DNS لإدارة المنطقة العامة والخاصة.
  • إنهاء SSL مع الشهادات المخزنة في Azure Key Vault.

للتكوينات الأخرى،

لتحسين الأمان، يتم حماية تطبيق Yelb بواسطة مورد Azure Application Gateway. يتم نشر هذا المورد في شبكة فرعية مخصصة داخل نفس الشبكة الظاهرية مثل نظام مجموعة AKS أو في شبكة ظاهرية نظيرة. يؤمن Azure Web Application Firewall (WAF) الوصول إلى تطبيق الويب المستضاف على خدمة Azure Kubernetes (AKS) وعرضها عبر بوابة تطبيق Azure ضد عمليات الاستغلال والثغرات الأمنية الشائعة.

المتطلبات الأساسية

بناء الأنظمة

يوفر هذا النموذج مجموعة من قوالب Bicep، تظهر البرامج النصية Bash وYAML لإنشاء مجموعة AKS، ونشر تطبيق Yelb، وكشف خدمة واجهة المستخدم باستخدام وحدة تحكم دخول NGINX، وحمايتها باستخدام Azure Application GatewayAzure Web Application Firewall (WAF).

يتضمن هذا النموذج أيضا ملفي معلمة Bicep منفصلين ومجموعتين من البرامج النصية Bash وبيانات YAML، كل منها موجه نحو نشر خيارين مختلفين للحل. لمزيد من المعلومات حول Bicep، راجع ما هو Bicep؟

إنهاء TLS في بوابة التطبيق واستدعاء Yelb عبر HTTP

في هذا الحل، يضمن Azure Web Application Firewall (WAF) أمان النظام عن طريق حظر الهجمات الضارة. يتلقى Azure Application Gateway المكالمات الواردة من تطبيقات العميل، وينفذ إنهاء TLS، ويعيد توجيه الطلبات إلى خدمة yelb-ui المستضافة من AKS. يتم تحقيق هذا الاتصال من خلال موازن التحميل الداخلي ووحدة تحكم دخول NGINX باستخدام بروتوكول نقل HTTP. يوضح الرسم التخطيطي التالي البنية:

رسم تخطيطي للحل استنادا إلى بوابة التطبيق WAFv2 ووحدة تحكم دخول NGINX عبر HTTP.

تدفق الرسالة كما يلي:

رسم تخطيطي لتدفق رسالة الحل استنادا إلى بوابة التطبيق WAFv2 ووحدة تحكم دخول NGINX عبر HTTP.

  1. يعالج Azure Application Gateway إنهاء TLS ويرسل المكالمات الواردة إلى خدمة yelb-ui المستضافة من AKS عبر HTTP.
  2. يستخدم مستمع بوابة التطبيق شهادة SSL التي تم الحصول عليها من Azure Key Vault لضمان الاتصال الآمن.
  3. يطبق نهج Azure WAF المقترن بوحدة الاستماع قواعد OWASP والقواعد المخصصة على الطلبات الواردة، ما يمنع بشكل فعال العديد من أنواع الهجمات الضارة.
  4. تستدعي إعدادات HTTP الخلفية لبوابة التطبيق تطبيق Yelb عبر HTTP باستخدام المنفذ 80.
  5. يستدعي تجمع الواجهة الخلفية لبوابة التطبيق والتحقيق الصحي وحدة تحكم دخول NGINX من خلال موازن التحميل الداخلي ل AKS باستخدام بروتوكول HTTP لإدارة حركة المرور.
  6. تستخدم وحدة تحكم دخول NGINX موازن التحميل الداخلي AKS لضمان الاتصال الآمن داخل نظام المجموعة.
  7. يستخدم عنصر دخول Kubernetes وحدة تحكم دخول NGINX لعرض التطبيق عبر HTTP من خلال موازن التحميل الداخلي.
  8. تقيد خدمة yelb-ui بنوع ClusterIP استدعاءها داخل نظام المجموعة أو من خلال وحدة تحكم دخول NGINX.

تنفيذ TLS من طرف إلى طرف باستخدام بوابة تطبيق Azure

إنهاء TLS

يدعم Azure Application Gateway إنهاء TLS على مستوى البوابة، ما يعني أنه يتم فك تشفير نسبة استخدام الشبكة في البوابة قبل إرسالها إلى خوادم الواجهة الخلفية. لتكوين إنهاء TLS، تحتاج إلى إضافة شهادة TLS/SSL إلى وحدة الاستماع. يجب أن تكون الشهادة بتنسيق تبادل المعلومات الشخصية (PFX)، والذي يحتوي على كل من المفتاحين الخاص والعام. يمكنك استيراد الشهادة من Azure Key Vault إلى بوابة التطبيق. لمزيد من المعلومات، راجع إنهاء TLS مع شهادات Key Vault.

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

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

TLS من طرف إلى طرف مع بوابة التطبيق

يمكنك تنفيذ نهج الثقة المعدومة عن طريق تكوين بوابة تطبيق Azure لتشفير TLS من طرف إلى طرف باستخدام خوادم الواجهة الخلفية. يسمح لك تشفير TLS من طرف إلى طرف بإرسال البيانات الحساسة بأمان إلى الخلفية مع الاستفادة من ميزات موازنة التحميل من الطبقة 7 ل Application Gateway، بما في ذلك ترابط الجلسة المستندة إلى ملفات تعريف الارتباط والتوجيه المستند إلى عنوان URL والتوجيه استنادا إلى المواقع والقدرة على إعادة كتابة أو إدخال عناوين X-Forwarded*.

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

لمزيد من المعلومات، راجع تشفير TLS من طرف إلى طرف لبوابة التطبيق وأفضل الممارسات لتأمينApplication Gateway.

في هذا الحل، يضمن Azure Web Application Firewall (WAF) أمان النظام عن طريق حظر الهجمات الضارة. يعالج Azure Application Gateway المكالمات الواردة من تطبيقات العميل، وينفذ إنهاء TLS، وينفذ TLS من طرف إلى طرف عن طريق استدعاء خدمة yelb-ui الأساسية المستضافة من AKS باستخدام بروتوكول نقل HTTPS عبر موازن التحميل الداخلي ووحدة تحكم دخول NGINX. يوضح الرسم التخطيطي التالي البنية:

رسم تخطيطي للحل استنادا إلى بوابة التطبيق WAFv2 ووحدة تحكم دخول NGINX عبر HTTPS.

تدفق الرسالة كما يلي:

  1. يعالج Azure Application Gateway إنهاء TLS ويتصل بتطبيق الواجهة الخلفية عبر HTTPS.
  2. يستخدم مستمع بوابة التطبيق شهادة SSL التي تم الحصول عليها من Azure Key Vault.
  3. يقوم نهج Azure WAF المقترن بوحدة الاستماع بتشغيل قواعد OWASP والقواعد المخصصة ضد الطلبات الواردة لمنع الهجمات الضارة.
  4. يتم تكوين إعدادات HTTP الخلفية لبوابة التطبيق لاستدعاء خدمة yelb-ui المستضافة من AKS عبر HTTPS على المنفذ 443.
  5. يستدعي تجمع الواجهة الخلفية لبوابة التطبيق والتحقيق الصحي وحدة تحكم الدخول NGINX من خلال موازن التحميل الداخلي ل AKS باستخدام HTTPS.
  6. يتم نشر وحدة تحكم دخول NGINX لاستخدام موازن التحميل الداخلي ل AKS.
  7. تم تكوين مجموعة SAKS مع موفر Azure Key Vault لبرنامج تشغيل CSI مخزن الأسرار الإضافية لاسترداد الأسرار والشهادات والمفاتيح من Azure Key Vault عبر وحدة تخزين CSI.
  8. يتم استخدام secretProviderClass لاسترداد الشهادة المستخدمة من قبل بوابة التطبيق من Key Vault.
  9. يستخدم عنصر دخول Kubernetes وحدة تحكم دخول NGINX لعرض التطبيق عبر HTTPS من خلال موازن التحميل الداخلي ل AKS.
  10. تحتوي خدمة yelb-ui على نوع ClusterIP، والذي يقيد استدعاءها داخل نظام المجموعة أو من خلال وحدة تحكم دخول NGINX.

للمساعدة في ضمان أمن النظام واستقراره، ضع في اعتبارك التوصيات التالية:

  • قم بتحديث نهج Azure WAF بانتظام بأحدث القواعد لضمان الأمان الأمثل.
  • تنفيذ آليات المراقبة والتسجيل لتتبع وتحليل الطلبات الواردة والهجمات المحتملة.
  • إجراء الصيانة والتحديثات بانتظام لمجموعة AKS ووحدة تحكم دخول NGINX وبوابة التطبيق لمعالجة أي ثغرات أمنية والحفاظ على بنية أساسية آمنة.
  • تنفيذ آليات المراقبة والتسجيل لتتبع وتحليل الطلبات الواردة والهجمات المحتملة.
  • إجراء الصيانة والتحديثات بانتظام لمجموعة AKS ووحدة تحكم دخول NGINX وبوابة التطبيق لمعالجة أي ثغرات أمنية والحفاظ على بنية أساسية آمنة.

اسم المضيف

يتم تكوين مستمع بوابة التطبيق دخول Kubernetes لاستخدام نفس اسم المضيف. من المهم استخدام نفس اسم المضيف لوكيل خدمة وتطبيق ويب خلفي للأسباب التالية:

  • الحفاظ على حالة جلسة العمل: عند استخدام اسم مضيف مختلف للوكيل وتطبيق الواجهة الخلفية، يمكن أن تفقد حالة جلسة العمل. وهذا يعني أن جلسات عمل المستخدم قد لا تستمر بشكل صحيح، ما يؤدي إلى ضعف تجربة المستخدم وفقدان محتمل للبيانات.
  • فشل المصادقة: إذا كان اسم المضيف يختلف بين الوكيل وتطبيق الواجهة الخلفية، فقد تفشل آليات المصادقة. يمكن أن يؤدي هذا الأسلوب إلى عدم تمكن المستخدمين من تسجيل الدخول أو الوصول إلى الموارد الآمنة داخل التطبيق.
  • التعرض غير المقصود لعناوين URL: إذا لم يتم الاحتفاظ باسم المضيف، فهناك خطر من أن تتعرض عناوين URL الخلفية للمستخدمين النهائيين. يمكن أن يؤدي هذا إلى ثغرات أمنية محتملة ووصول غير مصرح به إلى المعلومات الحساسة.
  • مشاكل ملفات تعريف الارتباط: تلعب ملفات تعريف الارتباط دورا حاسما في الحفاظ على جلسات عمل المستخدم وتمرير المعلومات بين العميل والخادم. عندما يختلف اسم المضيف، قد لا تعمل ملفات تعريف الارتباط كما هو متوقع، مما يؤدي إلى مشكلات مثل فشل المصادقة ومعالجة الجلسة غير الصحيحة وإعادة التوجيه غير الصحيحة.
  • متطلبات TLS/SSL من طرف إلى طرف: إذا كانت TLS/SSL من طرف إلى طرف مطلوبة للاتصال الآمن بين الوكيل وخدمة الواجهة الخلفية، فمن الضروري الحصول على شهادة TLS مطابقة لاسم المضيف الأصلي. يؤدي استخدام نفس اسم المضيف إلى تبسيط عملية إدارة الشهادات وضمان تأسيس الاتصال الآمن بسلاسة.

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

تدفق الرسائل

يوضح الرسم التخطيطي التالي خطوات تدفق الرسالة أثناء النشر ووقت التشغيل.

رسم تخطيطي لتدفق رسالة الحل استنادا إلى بوابة التطبيق WAFv2 ووحدة تحكم دخول NGINX عبر HTTPS.

سير عمل التوزيع

تصف الخطوات التالية عملية التوزيع. يتوافق سير العمل هذا مع الأرقام الخضراء في الرسم التخطيطي السابق.

  1. ينشئ مهندس الأمان شهادة للمجال المخصص الذي يستخدمه حمل العمل، ويحفظها في مخزن مفاتيح Azure. يمكنك الحصول على شهادة صالحة من مرجع مصدق معروف (CA).
  2. يحدد مهندس النظام الأساسي المعلومات الضرورية في main.bicepparams ملف معلمات Bicep وينشر قوالب Bicep لإنشاء موارد Azure. وتشمل المعلومات الضرورية ما يلي:
    • بادئة لموارد Azure.
    • اسم ومجموعة الموارد ل Azure Key Vault الموجود الذي يحتوي على شهادة TLS لاسم مضيف حمل العمل والمجال المخصص لمستمع بوابة التطبيق.
  3. يمكنك تكوين البرنامج النصي لنشر لتثبيت الحزم التالية إلى نظام مجموعة AKS. لمزيد من المعلومات، تحقق من قسم المعلمات في وحدة Bicep.
  4. يسترد مستمع بوابة التطبيق شهادة TLS من Azure Key Vault.
  5. يستخدم عنصر دخول Kubernetes الشهادة التي تم الحصول عليها من موفر Azure Key Vault لبرنامج تشغيل CSI مخزن الأسرار لعرض خدمة واجهة مستخدم Yelb عبر HTTPS.
  6. يسترد مستمع بوابة التطبيق شهادة TLS من Azure key Vault.
  7. يستخدم عنصر دخول Kubernetes الشهادة التي تم الحصول عليها من موفر azure Key Vault برنامج تشغيل CSI لمخزن الأسرار لعرض خدمة واجهة مستخدم Yelb عبر HTTPS.

سير عمل وقت التشغيل

  1. يستدعي تطبيق العميل نموذج تطبيق الويب باستخدام اسم المضيف الخاص به. تستخدم منطقة DNS المقترنة بالمجال المخصص لمستمع بوابة التطبيق سجل A لحل استعلام DNS بعنوان IP العام Azure المستخدم بواسطة تكوين IP الأمامي لبوابة التطبيق.
  2. يتم إرسال الطلب إلى عنوان IP العام ل Azure المستخدم بواسطة تكوين IP للواجهة الأمامية لبوابة التطبيق.
  3. تنفذ بوابة التطبيق الإجراءات التالية:
    1. تعالج بوابة التطبيق إنهاء TLS وتتصل بتطبيق الواجهة الخلفية عبر HTTPS.
    2. يستخدم مستمع بوابة التطبيق شهادة SSL التي تم الحصول عليها من Azure Key Vault.
    3. يقوم نهج Azure WAF المقترن بوحدة الاستماع بتشغيل قواعد OWASP والقواعد المخصصة مقابل الطلب الوارد ويحظر الهجمات الضارة.
    4. يتم تكوين إعدادات HTTP الخلفية لبوابة التطبيق لاستدعاء نموذج تطبيق الويب عبر HTTPS على المنفذ 443.
  4. يستدعي تجمع الواجهة الخلفية لبوابة التطبيق وحدة تحكم دخول NGINX من خلال موازن التحميل الداخلي ل AKS باستخدام HTTPS.
  5. يتم إرسال الطلب إلى إحدى عقد العامل التي تستضيف جراب وحدة تحكم دخول NGINX.
  6. تعالج إحدى النسخ المتماثلة لوحدة تحكم دخول NGINX الطلب وترسل الطلب إلى إحدى نقاط نهاية الخدمة لخدمة yelb-ui.
  7. يستدعي yelb-ui خدمة yelb-appserver.
  8. يستدعي yelb-appserver خدمات yelb-dbyelb-cache.
  9. يستدعي yelb-ui خدمة yelb-appserver.
  10. يستدعي yelb-appserver خدمات yelb-dbyelb-cache.

نشر

بشكل افتراضي، تثبت قوالب Bicep مجموعة AKS مع المكون الإضافي Azure CNI Overlay الشبكة و مستوى بيانات Cilium. يمكنك استخدام مكون إضافي بديل للشبكة. بالإضافة إلى ذلك، يوضح المشروع كيفية نشر نظام مجموعة AKS مع الملحقات والميزات التالية:

في بيئة الإنتاج، نوصي بشدة بنشر مجموعة AKS خاصة مع وقت التشغيل SLA. لمزيد من المعلومات، راجع مجموعة AKS الخاصة مع عنوان DNS عام.

بدلا من ذلك، يمكنك نشر مجموعة AKS عامة وتأمين الوصول إلى خادم API باستخدام نطاقات عناوين IP المعتمدة . للحصول على معلومات مفصلة وإرشادات حول كيفية نشر البنية الأساسية على Azure باستخدام قوالب Bicep، راجع نموذج التعليمات البرمجية ل Azure المصاحب .

في بيئة الإنتاج، نوصي بشدة بنشر مجموعة AKS خاصة مع وقت التشغيل SLA. لمزيد من المعلومات، راجع مجموعة AKS الخاصة مع عنوان DNS عام. بدلا من ذلك، يمكنك نشر مجموعة AKS عامة وتأمين الوصول إلى خادم API باستخدام نطاقات عناوين IP المعتمدة . للحصول على معلومات مفصلة وإرشادات حول كيفية نشر البنية الأساسية على Azure باستخدام قوالب Bicep، راجع نموذج رمز Azure المصاحب .

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

نشر حمل عمل تطبيق ويب AWS إلى Azure

المساهمون

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

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

مساهمون آخرون:

  • Last updated on