كشف تطبيقات Azure Spring Apps من خلال وكيل عكسي

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

عند نشر خدمة وكيل عكسي شائعة مثل Azure Application Gateway أو Azure Front Door أمام Azure Spring Apps، يجب عليك التأكد من أنه لا يمكن الوصول إلى تطبيقاتك إلا من خلال الوكيل العكسي. تساعد هذه الحماية على منع المستخدمين الضارين من محاولة تجاوز WAF أو التحايل على حدود التقييد.

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

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

• نشر Azure Spring Apps داخل شبكة ظاهرية والوصول إلى تطبيقاتك بشكل خاص من داخل الشبكة.

  • يمكنك التحكم في الشبكة الظاهرية التي تعمل فيها تطبيقاتك. استخدم ميزات شبكة Azure الأصلية مثل مجموعات أمان الشبكة (NSGs) لتأمين الوصول للسماح بالوكيل العكسي فقط.

  • يمكنك عرض تطبيقاتك بشكل عام على الإنترنت باستخدام Azure Application Gateway ثم تطبيق قيود الوصول المناسبة لتأمينها. تم وصف هذا الأسلوب في السيناريو 1 لاحقا في هذه المقالة.

  • لا يمكنك استخدام Azure Front Door مباشرة لأنه لا يمكنه الوصول إلى مثيل Azure Spring Apps في شبكتك الظاهرية الخاصة. يمكن ل Azure Front Door الاتصال بالخلفيات فقط من خلال عنوان IP عام أو عبر الخدمات التي تستخدم نقطة نهاية خاصة. عندما يكون لديك نشر متعدد المناطق ل Azure Spring Apps وتتطلب موازنة تحميل عمومية، فلا يزال بإمكانك عرض مثيلات Azure Spring Apps من خلال Application Gateway. لتحقيق هذا السيناريو، يمكنك وضع Azure Front Door أمام بوابة التطبيق. يتم وصف هذا الأسلوب في السيناريو 2 لاحقا في هذه المقالة.

• انشر Azure Spring Apps خارج شبكة ظاهرية وانشر تطبيقاتك على الإنترنت مباشرة، إذا قمت بتعيين نقطة نهاية لها.

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

  • نظرا لأنه يمكن الوصول إلى تطبيقاتك بشكل عام، يمكنك استخدام Application Gateway أو Azure Front Door كوكيل عكسي. يتم وصف نهج Application Gateway في السيناريو 3 لاحقا في هذه المقالة. يتم وصف نهج Azure Front Door في السيناريو 4 لاحقا في هذه المقالة.

  • يمكنك استخدام مزيج من كلا النهجين، حسب الحاجة. إذا كنت تستخدم كل من Application Gateway وAzure Front Door، فاستخدم نفس قيود الوصول بين الوكلاء العكسيين اللذين يتم استخدامهما في السيناريو 2.

مقارنة السيناريو

يوفر الجدول التالي مقارنة موجزة لسيناريوهات تكوين الوكيل العكسي الأربعة ل Azure Spring Apps. للحصول على تفاصيل كاملة بشأن كل سيناريو، راجع القسم المناسب من هذه المقالة.

النشر داخل شبكتك الظاهرية

عند نشر Azure Spring Apps في شبكة ظاهرية، فإنه يستخدم شبكتين فرعيتين:

• شبكة فرعية لوقت تشغيل الخدمة تحتوي على موارد الشبكة ذات الصلة
• شبكة فرعية للتطبيقات تستضيف التعليمات البرمجية الخاصة بك

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

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

السيناريو 1: استخدام بوابة التطبيق كوكيل عكسي

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

يوضح الرسم التخطيطي التالي بنية السيناريو 1:

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

عندما تقع بوابة التطبيق أمام مثيل Azure Spring Apps، يمكنك استخدام نقطة النهاية المعينة لتطبيق Spring Cloud Gateway كتجمع خلفي. مثال على نقطة النهاية هو myspringcloudservice-myapp.private.azuremicroservices.io. يتم حل نقطة النهاية إلى عنوان IP خاص في الشبكة الفرعية لوقت تشغيل الخدمة. لذلك، لتقييد الوصول، يمكنك وضع NSG على الشبكة الفرعية لوقت تشغيل الخدمة بقواعد الأمان الواردة التالية (مع إعطاء قاعدة الرفض الأولوية الأقل):

يضمن تكوين السيناريو 1 أن الشبكة الفرعية لوقت تشغيل الخدمة تسمح بنسبة استخدام الشبكة فقط من المصادر التالية:

• الشبكة الفرعية المخصصة لبوابة التطبيق
• الشبكة الفرعية للتطبيقات (الاتصال ثنائي الاتجاه بين شبكتي Azure Spring Apps الفرعيتين مطلوب.)
• موازن تحميل Azure (وهو مطلب نظام أساسي عام ل Azure)

تم حظر جميع نسبة استخدام الشبكة الأخرى.

السيناريو 2: استخدام كل من Azure Front Door وApplication Gateway كوكيل عكسي

كما ذكر سابقا، لا يمكنك وضع Azure Front Door مباشرة أمام Azure Spring Apps لأنه لا يمكن الوصول إلى شبكتك الظاهرية الخاصة. (يمكن ل Azure Front Door Standard أو Premium الاتصال بنقاط النهاية الخاصة في شبكة ظاهرية، ولكن Azure Spring Apps لا تقدم حاليا دعم نقطة النهاية الخاصة.) إذا كنت لا تزال ترغب في استخدام Azure Front Door، مثل طلب موازنة تحميل عمومية عبر مثيلات متعددة من Azure Spring Apps في مناطق Azure مختلفة، فلا يزال بإمكانك عرض تطبيقاتك عبر Application Gateway. لتحقيق هذا السيناريو، يمكنك وضع Azure Front Door أمام بوابة التطبيق.

يوضح الرسم التخطيطي التالي بنية السيناريو 2:

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

ينفذ تكوين السيناريو 2 قيود الوصول بين Application Gateway وAzure Spring Apps بنفس طريقة السيناريو 1. يمكنك وضع NSG على الشبكة الفرعية لوقت تشغيل الخدمة مع القواعد المناسبة.

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

• على الشبكة الفرعية لبوابة التطبيق، قم بإنشاء NSG للسماح فقط بنسبة استخدام الشبكة التي تحتوي على AzureFrontDoor.Backend علامة الخدمة (لا شيء باستثناء Azure Front Door يمكنه الوصول إلى بوابة التطبيق). تأكد أيضا من تضمين علامات الخدمة المطلوبة الأخرى، كما هو موضح في قيود NSG لبوابة التطبيق.
• إنشاء قاعدة WAF مخصصة في بوابة التطبيق للتحقق من X-Azure-FDID تعيين عنوان HTTP إلى معرف مثيل Azure Front Door المحدد. يضمن هذا الأسلوب أنه لا يمكن لأي مثيلات Azure Front Door للمؤسسة الأخرى التي تستخدم نفس نطاقات IP الوصول إلى مثيل Application Gateway الخاص بك.

النشر خارج شبكتك الظاهرية

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

استخدام Spring Cloud Gateway لكشف تطبيقاتك والمساعدة في تأمينها

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

يستخدم هذا النمط بشكل شائع. لأغراض هذه المقالة، نفترض أنك تعرض تطبيقاتك من خلال Spring Cloud Gateway. نتوقع أن تستخدم دالات تقييم المسار الخاصة به لإعداد قيود الوصول الضرورية لضمان السماح فقط بالطلبات من الوكيل العكسي. حتى إذا كنت لا تستخدم Spring Cloud بوابة، تنطبق نفس الكيانات العامة. ومع ذلك، يجب عليك إنشاء قدرات تصفية الطلب الخاصة بك في تطبيقاتك استنادا إلى نفس X-Forwarded-For عنوان HTTP الذي تمت مناقشته لاحقا في هذه المقالة.

وصف كيفية عمل Spring Cloud بوابة خارج نطاق هذه المقالة. إنها خدمة مرنة للغاية يمكنك تخصيصها عبر التعليمة البرمجية أو التكوين. لإبقاء الأمور بسيطة، تصف هذه المقالة فقط نهجا يستند إلى التكوين البحت لا يتطلب تغييرات في التعليمات البرمجية. يمكنك تنفيذ هذا الأسلوب من خلال تضمين الملف التقليدي application.properties أو application.yml في تطبيق Spring Cloud بوابة المنشور. يمكنك أيضا تنفيذ النهج باستخدام خادم التكوين في Azure Spring Apps الذي يقوم بإضفاء الطابع الخارجي على ملف التكوين في مستودع Git. في الأمثلة التالية، ننفذ application.yml الأسلوب باستخدام بناء جملة YAML، ولكن بناء الجملة المكافئ application.properties يعمل أيضا.

توجيه الطلبات إلى تطبيقاتك

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

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

طريقة سهلة لعرض جميع التطبيقات المسجلة من خلال Spring Cloud Gateway هي استخدام محدد موقع تعريف مسار DiscoveryClient كما يلي:

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true
          predicates:
          - Path="/"+serviceId+"/**" # Include the Path predicate to retain default behavior
          - (...)

بدلاً من ذلك، يمكنك عرض تطبيقات معينة بشكل انتقائي من خلال Spring Cloud بوابة من خلال تحديد المسارات الخاصة بالتطبيق:

spring:
  cloud:
    gateway:
      routes:
      - id: my_app1_route
        uri: lb://MY-APP1
        filters:
        - RewritePath=/myapp1(?<segment>/?.*), $\{segment}
        predicates:
        - (...)

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

تقييد الوصول باستخدام رأس X-Forwarded-For HTTP

عند نشر تطبيق في Azure Spring Apps، لا يتصل عميل HTTP أو الوكيل العكسي مباشرة إلى التطبيق. تمر حركة مرور الشبكة عبر وحدة تحكم دخول داخلية أولاً.

بسبب الخدمة الإضافية، يكون عنوان IP لعميل الشبكة المباشر دائما مكونا داخليا ل Azure Spring Apps. عنوان IP ليس أبدا العميل المنطقي مثل الوكيل العكسي الذي تتوقع الاتصال بتطبيقك. لا يمكنك استخدام عنوان IP للعميل لقيود الوصول. لا يمكنك أيضا استخدام دالة تقييم المسار المضمنة ل RemoteAddr Spring Cloud Gateway لتصفية الطلب لأنها تستخدم عنوان IP للعميل بشكل افتراضي.

لحسن الحظ، يضيف Azure Spring Apps دائما عنوان IP للعميل المنطقي إلى X-Forwarded-For عنوان HTTP عند الطلب إلى تطبيقك. تحتوي القيمة الأخيرة (الأكثر يمينا) للعنوان X-Forwarded-For دائما على عنوان IP للعميل المنطقي.

لتصفية الطلبات استنادا X-Forwarded-For إلى العنوان، يمكنك استخدام دالة تقييم المسار المضمنةXForwarded Remote Addr. يسمح لك هذا التقييم بتكوين قائمة بعناوين IP أو نطاقات IP للوكيل العكسي المسموح بها كقيمة صحيحة.

قم بتكوين تطبيقك لمشاهدة اسم المضيف الصحيح وعنوان URL للطلب

عند استخدام Spring Cloud Gateway، هناك عامل مهم يجب مراعاته. تقوم Spring Cloud Gateway بتعيين عنوان HTTP Host على الطلب الصادر إلى عنوان IP الداخلي لمثيل التطبيق الخاص بك، مثل Host: 10.2.1.15:1025. لم يعد اسم مضيف الطلب الذي تراه التعليمة البرمجية للتطبيق الخاص بك هو اسم المضيف الأصلي للطلب الذي أرسله المستعرض، مثل contoso.com. في بعض الحالات، يمكن أن تؤدي هذه النتيجة إلى مشاكل مثل ملفات تعريف الارتباط المقطوعة أو إعادة توجيه عناوين URL التي لا تعمل بشكل صحيح. لمزيد من المعلومات بشأن هذه الأنواع من المشكلات وكيفية تكوين خدمة وكيل عكسي مثل Application بوابة أو Azure Front Door لتجنبها، راجع الاحتفاظ باسم المضيف.

توفر Spring Cloud Gateway اسم المضيف الأصلي في Forwarded العنوان. كما أنه يعين عناوين أخرى مثل X-Forwarded-Port، X-Forwarded-Protoو X-Forwarded-Prefix ، و حتى يتمكن تطبيقك من استخدامها لإعادة إنشاء عنوان URL للطلب الأصلي. في تطبيقات Spring Framework، يمكنك تحقيق هذا التكوين تلقائيا عن طريق تعيين server.forward-headers-strategy الإعداد إلى FRAMEWORK في خصائص التطبيق الخاص بك. (لا تقم بتعيين هذه القيمة إلى NATIVE. وإلا، يتم استخدام رؤوس أخرى لا تأخذ العنوان المطلوب X-Forwarded-Prefix في الاعتبار.) لمزيد من المعلومات، راجع تشغيل خلف خادم وكيل أمامي. باستخدام هذا التكوين، يأخذ أسلوب HttpServletRequest.getRequestURL جميع هذه العناوين في الاعتبار ويعيد عنوان URL للطلب الدقيق كما تم إرساله بواسطة المستعرض.

السيناريو 3: استخدام Application Gateway مع Spring Cloud Gateway

يصف السيناريو 3 كيفية استخدام Application Gateway كوكيل عكسي للتطبيقات التي يمكن الوصول إليها بشكل عام من خلال نقطة نهاية Spring Cloud Gateway.

يوضح الرسم التخطيطي التالي بنية السيناريو 3:

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

عندما تقع بوابة التطبيق أمام مثيل Azure Spring Apps، يمكنك استخدام نقطة النهاية المعينة لتطبيق Spring Cloud Gateway كتجمع خلفي. مثال على نقطة النهاية هو myspringcloudservice-mygateway.azuremicroservices.io. نظرا لنشر Azure Spring Apps خارج شبكة ظاهرية، يتم حل عنوان URL هذا إلى عنوان IP عام. عندما يكون تجمع النهاية الخلفية نقطة نهاية عامة، فإن Application بوابة تستخدم عنوان IP العام للواجهة الأمامية للوصول إلى خدمة النهاية الخلفية.

للسماح فقط للطلبات من مثيل Application Gateway بالوصول إلى Spring Cloud Gateway، يمكنك تكوين دالة XForwarded Remote Addr تقييم المسار. قم بتكوين دالة التقييم للسماح فقط بالطلبات من عنوان IP العام المخصص لبوابة التطبيق الخاصة بك كما هو موضح في المثال التالي:

(...)
predicates:
- XForwardedRemoteAddr="20.103.252.85"

السيناريو 4: استخدام Azure Front Door مع Spring Cloud Gateway

يصف السيناريو 4 كيفية استخدام Azure Front Door كوكيل عكسي للتطبيقات التي يمكن الوصول إليها بشكل عام من خلال نقطة نهاية Spring Cloud Gateway.

يوضح الرسم التخطيطي التالي بنية السيناريو 4:

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

على غرار السيناريو 3، يستخدم هذا التكوين عنوان URL العام لتطبيق Spring Cloud Gateway كتجمع خلفي أو أصل في Azure Front Door. مثال على نقطة النهاية هو https://myspringcloudservice-mygateway.azuremicroservices.io.

نظرا لأن Azure Front Door هي خدمة عمومية بها العديد من مواقع الحافة، فإنها تستخدم العديد من عناوين IP للاتصال بتجمعها الخلفي. توضح وثائق Azure Front Door كيفية تأمين الوصول إلى الواجهة الخلفية للسماح بنسبة استخدام الشبكة ل Azure Front Door فقط. ومع ذلك، في هذا السيناريو، لا تتحكم في شبكة Azure التي يتم نشر تطبيقاتك فيها. لسوء الحظ، لا يمكنك استخدام AzureFrontDoor.Backend علامة الخدمة للحصول على قائمة كاملة بعناوين IP الصادرة ل Azure Front Door التي تضمن أن تكون حديثة. بدلا من ذلك، يجب عليك تنزيل نطاقات IP Azure وعلامات الخدمة، والعثور على AzureFrontDoor.Backend القسم، ونسخ جميع نطاقات IP من addressPrefixes الصفيف إلى XForwarded Remote Addr تكوين تقييم المسار.

نظرا لأنه تتم مشاركة نطاقات IP ل Azure Front Door مع مؤسسات أخرى، يجب عليك أيضا التأكد من تأمين الوصول إلى مثيل Azure Front Door المحدد فقط، استنادا X-Azure-FDID إلى عنوان HTTP الذي يحتوي على الخاص بك الفريد Front Door ID. يمكنك تقييد الوصول باستخدام دالة Header تقييم المسار، التي ترفض طلبا ما لم يكن لعنوان HTTP محدد قيمة معينة.

في هذا السيناريو، قد يبدو تكوين دالة تقييم مسار Spring Cloud Gateway مثل المثال التالي:

(...)
predicates:
- XForwardedRemoteAddr="13.73.248.16/29","20.21.37.40/29","20.36.120.104/29","20.37.64.104/29", ...(and many more)...
- Header="X-Azure-FDID", "e483e3cc-e7f3-4e0a-9eca-5f2a62bde229"

المساهمون

تحتفظ Microsoft بهذا المحتوى. قام المساهم التالي بتطوير المحتوى الأصلي.

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

• جيل درويتس | مهندس العملاء الرئيسي

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

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

• البنية المرجعية ل Azure Spring Apps
• مسؤوليات العملاء لتشغيل Azure Spring Apps في شبكات Azure الظاهرية

الموارد ذات الصلة

• الاحتفاظ باسم المضيف
• خيارات موازنة التحميل
• نمط البنية للخدمات المصغرة