مشاركة عبر

البنية المرجعية لـAzure Spring Apps

  • مقالة

ملاحظة

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

تنطبق هذه المقالة على: ✔️ Standard ✔️ Enterprise

هذه البنية المرجعية هي أساس يستخدم مركز مؤسسة نموذجياً وتصميماً محورياً لاستخدام Azure Spring Apps. في التصميم، يتم توزيع Azure Spring Apps في مكبر واحد يعتمد على الخدمات المشتركة المستضافة في المركز. تم إنشاء البنية باستخدام مكونات لتحقيق المبادئ في Microsoft Azure Well-Architected Framework.

هناك نوعان من Azure Spring Apps: الخطة القياسية وخطة المؤسسة.

تتكون خطة Azure Spring Apps Standard من خادم تكوين Spring Cloud وسجل خدمة Spring Cloud وخدمة بناء kpack.

تتكون خطة Azure Spring Apps Enterprise من خدمة™ بناء VMware Tanzu® وخدمة تكوين التطبيق ل VMware Tanzu® وسجل خدمة VMware Tanzu® وبوابة Spring Cloud ل VMware Tanzu® ومدخل واجهة برمجة التطبيقات ل VMware Tanzu®.

لتنفيذ هذه البنية، راجع البنية المرجعية ل Azure Spring Apps على GitHub.

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

تخطيط مساحة العنوان

تتطلب Azure Spring Apps شبكتين فرعيتين مخصصتين:

  • وقت تشغيل الخدمة
  • تطبيقات Spring Boot

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

تحذير

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

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

تتضمن الاستخدامات النموذجية لهذه البنية الأساسية هذه الحَالات:

  • التطبيقات الخاصة: التطبيقات الداخلية الموزعة في البيئات السحابية المختلطة
  • التطبيقات العامة: التطبيقات الخارجية

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

التطبيقات الخاصة

تصف القائمة التالية متطلبات البنية الأساسية للتطبيقات الخاصة. هذه المتطلبات نموذجية في البيئات شديدة التنظيم.

  • يجب أن تحتوي الشبكة الفرعية على مثيل واحد فقط من Azure Spring Apps.
  • يجب فرض الالتزام بـSecurity Benchmark واحد على الأقل.
  • يجب تخزين مضيف التطبيق Domain Name Service (DNS) في Azure Private DNS.
  • يجب أن تتواصل تبعيات خدمة Azure من خلال Service Endpoints أو Private Link.
  • يجب تشفير البيانات الثابتة.
  • يجب تشفير البيانات التي يتم نقلها.
  • يمكن استخدام بنى أساسية لتوزيع DevOps (على سبيل المثال، Azure DevOps) وتتطلب اتصال الشبكة بـAzure Spring Apps.
  • يجب أن تنتقل نسبة استخدام الشبكة الخارجة من خلال جهاز افتراضي للشبكة المركزية (NVA) (على سبيل المثال، Azure Firewall).
  • إذا تم استخدام Azure Spring Apps Config Server لتحميل خصائص التكوين من أحد المستودعات، يجب أن يكون المستودع خاصاً.
  • يتطلب نهج أمان Microsoft's Zero Trust تخزين البيانات السرية والشهادات وبيانات الاعتماد في مخزن آمن. الخدمة الموصى بها هي Azure Key Vault.
  • يجب أن يكون تحليل الاسم للمضيفين في أماكن العمل وفي Cloud ثنائي الاتجاه.
  • لا يوجد خروج مباشر إلى الإنترنت العام باستثناء حركة مرور بيانات مسطحة.
  • يجب عدم تعديل مجموعات الموارد المُدارة بواسطة توزيع Azure Spring Apps.
  • يجب عدم تعديل الشبكات الفرعية المُدارة بواسطة توزيع Azure Spring Apps.

توضح القائمة التالية المكونات التي يتكون منها التصميم:

  • شبكة داخلي
    • Domain Name Service (DNS)
    • ‏‏البوابة
  • اشتراك المركز
    • Application Gateway Subnet
    • Azure Firewall Subnet
    • Shared Services Subnet
  • اشتراك متصل
    • Azure Bastion Subnet
    • Virtual Network Peer

تصف القائمة التالية خدمات Azure في هذه البنية للمرجع:

  • Azure Key Vault: خدمة إدارة بيانات اعتماد مدعومة بالأجهزة وتتميز بتكامل وثيق مع خدمات الهوية وموارد الحساب من Microsoft.

  • Azure Monitor: مجموعة شاملة من خدمات المراقبة للتطبيقات التي يتم توزيعها في Azure وفي أماكن العمل.

  • Azure Pipelines: خدمة متكاملة / تطوير مستمر (CI/CD) مميزة بالكامل يمكنها توزيع تطبيقات Spring Boot المحدثة تلقائياً إلى Azure Spring Apps.

  • Microsoft Defender لـCloud: نظام إدارة أمان موحد وحماية من التهديدات لأحمال العمل عبر أماكن العمل والسحابات المتعددة وAzure.

  • Azure Spring Apps: خدمة مُدارة تم تصميمها وتحسينها خصوصاً لتطبيقات Spring Boot المستندة إلى Java وتطبيقات Steeltoe المستندة إلى .NET.

تمثل الرسومات التخطيطية التالية تصميما محوريا ومهندسا جيدا يعالج المتطلبات المذكورة أعلاه:

التطبيقات العامة

تصف القائمة التالية متطلبات البنية الأساسية للتطبيقات العامة. هذه المتطلبات نموذجية في البيئات شديدة التنظيم.

  • يجب أن تحتوي الشبكة الفرعية على مثيل واحد فقط من Azure Spring Apps.
  • يجب فرض الالتزام بـSecurity Benchmark واحد على الأقل.
  • يجب تخزين مضيف التطبيق Domain Name Service (DNS) في Azure Private DNS.
  • يجب تمكين Azure DDoS Protection.
  • يجب أن تتواصل تبعيات خدمة Azure من خلال Service Endpoints أو Private Link.
  • يجب تشفير البيانات الثابتة.
  • يجب تشفير البيانات التي يتم نقلها.
  • يمكن استخدام بنى أساسية لتوزيع DevOps (على سبيل المثال، Azure DevOps) وتتطلب اتصال الشبكة بـAzure Spring Apps.
  • يجب أن تنتقل نسبة استخدام الشبكة الخارجة من خلال جهاز افتراضي للشبكة المركزية (NVA) (على سبيل المثال، Azure Firewall).
  • يجب إدارة نسبة استخدام الشبكة الوافدة بواسطة Application Gateway أو Azure Front Door على الأقل.
  • يجب تخزين عناوين الإنترنت القابلة للتوجيه في Azure Public DNS.
  • يتطلب نهج أمان Microsoft's Zero Trust تخزين البيانات السرية والشهادات وبيانات الاعتماد في مخزن آمن. الخدمة الموصى بها هي Azure Key Vault.
  • يجب أن يكون تحليل الاسم للمضيفين في أماكن العمل وفي Cloud ثنائي الاتجاه.
  • لا يوجد خروج مباشر إلى الإنترنت العام باستثناء حركة مرور بيانات مسطحة.
  • يجب عدم تعديل مجموعات الموارد المُدارة بواسطة توزيع Azure Spring Apps.
  • يجب عدم تعديل الشبكات الفرعية المُدارة بواسطة توزيع Azure Spring Apps.

توضح القائمة التالية المكونات التي يتكون منها التصميم:

  • شبكة داخلي
    • Domain Name Service (DNS)
    • ‏‏البوابة
  • اشتراك المركز
    • Application Gateway Subnet
    • Azure Firewall Subnet
    • Shared Services Subnet
  • اشتراك متصل
    • Azure Bastion Subnet
    • Virtual Network Peer

تصف القائمة التالية خدمات Azure في هذه البنية للمرجع:

  • Azure Application Firewall: أحد ميزات Application Gateway التي توفر حماية واردة مركزية لتطبيقات الويب الخاصة بك من الثغرات الأمنية وعمليات الاستغلال المتداولة.

  • Azure Application Gateway: موازن تحميل مسؤول عن حركة مرور التطبيق مع إلغاء تحميل Transport Layer Security (TLS) الذي يعمل في الطبقة 7.

  • Azure Key Vault: خدمة إدارة بيانات اعتماد مدعومة بالأجهزة وتتميز بتكامل وثيق مع خدمات الهوية وموارد الحساب من Microsoft.

  • Azure Monitor: مجموعة شاملة من خدمات المراقبة للتطبيقات التي يتم توزيعها في Azure وفي أماكن العمل.

  • Azure Pipelines: خدمة متكاملة / تطوير مستمر (CI/CD) مميزة بالكامل يمكنها توزيع تطبيقات Spring Boot المحدثة تلقائياً إلى Azure Spring Apps.

  • Microsoft Defender لـCloud: نظام إدارة أمان موحد وحماية من التهديدات لأحمال العمل عبر أماكن العمل والسحابات المتعددة وAzure.

  • Azure Spring Apps: خدمة مُدارة تم تصميمها وتحسينها خصوصاً لتطبيقات Spring Boot المستندة إلى Java وتطبيقات Steeltoe المستندة إلى .NET.

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

اتصال محلي في Azure Spring Apps

يمكن للتطبيقات في Azure Spring Apps التواصل مع مختلف موارد Azure الداخلية والخارجية. باستخدام تصميم المحور والتحدث، يمكن للتطبيقات توجيه نسبة استخدام الشبكة خارجياً أو إلى الشبكة المحلية باستخدام Express Route أو Site-to-Site Virtual Private Network (VPN).

اعتبارات Azure Well-Architured Framework

إن Azure Well-Architected Framework عبارة عن مجموعة من المبادئ التوجيهية التي يجب اتباعها في إنشاء أساس بنية أساسية قوي. يحتوي إطار العمل على الفئات التالية: تحسين التكلفة والتميز التشغيلي وكفاءة الأداء والاعتمادية والأمان.

تحسين التكلفة

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

يمكنك توزيع تطبيقات وأنواع تطبيقات مختلفة في مثيل واحد من Azure Spring Apps. تدعم الخدمة القياس التلقائي للتطبيقات التي يتم تشغيلها بواسطة القياسات أو الجداول الزمنية التي يمكنها تحسين الاستخدام وكفاءة التكلفة.

يمكنك أيضاً استخدام Application Insights وAzure Monitor لخفض تكلفة العملية. من خلال الرؤية التي يوفرها حل التسجيل الشامل، يمكنك تنفيذ التنفيذ التلقائي لتوسيع نطاق مكونات النظام في الوقت الفعلي. يمكنك أيضاً تحليل بيانات السجل للكشف عن أوجه القصور في التعليمة البرمجية للتطبيق التي يمكنك معالجتها لتحسين التكلفة الإجمالية وأداء النظام.

التميز التشغيلي

تتناول Azure Spring Apps جوانب متعددة من التميز التشغيلي. يمكنك دمج هذه الجوانب لضمان تشغيل الخدمة بكفاءة في بيئات الإنتاج، كما هو موضح في القائمة التالية:

  • يمكنك استخدام Azure Pipelines للتأكد من أن عمليات التوزيع يمكن الاعتماد عليها ومتسقة مع مساعدتك في تجنب الخطأ البشري.
  • يمكنك استخدام Azure Monitor وApplication Insights لتخزين بيانات السجل وبيانات تتبع الاستخدام. يمكنك تقييم بيانات السجل والقياسات التي تم جمعها لضمان سلامة تطبيقاتك وأدائها. تم دمج مراقبة أداء التطبيق (APM) بالكامل في الخدمة من خلال عامل Java. يوفر هذا العامل رؤية لجميع التطبيقات والتبعيات المنشورة دون الحاجة إلى تعليمة برمجية إضافية. لمزيد من المعلومات، راجع منشور المدونة راقب التطبيقات والتبعيات بسهولة في Azure Spring Apps.
  • يمكنك استخدام Microsoft Defender لـCloud للتأكد من أن التطبيقات تحافظ على الأمان من خلال توفير نظام أساسي لتحليل البيانات المقدمة وتقييمها.
  • تدعم الخدمة أنماط توزيع مختلفة. لمزيد من المعلومات، راجع إعداد البيئة المرحلية في Azure Spring Apps.

الموثوقيه

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

من خلال البناء فوق مركز محدد جيداً وتصميم المتحدث، يضمن أساس هذه البنية أنه يمكنك توزيعها في مناطق متعددة. بالنسبة لحالة استخدام التطبيق الخاص، تستخدم البنية Azure Private DNS لضمان التوافر المستمر أثناء الفشل الجغرافي. بالنسبة لحالة استخدام التطبيق العام، يضمن Azure Front Door وAzure Application Gateway التوافر.

الأمان

تتم معالجة أمان هذه البنية من خلال التزامها بالضوابط والمعايير المحددة في الصناعة. في هذا السياق، يُقصد بمصطلح "التحكم" أفضل ممارسة مختصرة ومحددة جيداً، مثل "استخدام كيان أقل امتيازاً عند تنفيذ الوصول إلى نظام المعلومات. IAM-05 "عناصر التحكم في هذه البنية مأخوذة من Cloud Control Matrix (CCM) بواسطة Cloud Security Alliance (CSA) وMicrosoft Azure Foundations Benchmark (MAFB) بواسطة Center for Internet Security (CIS). في الضوابط المطبقة، ينصب التركيز على كيانات تصميم الأمان الأساسية للإدارة والشبكات وأمن التطبيقات. تقع على عاتقك مسؤولية التعامل مع كيانات تصميم الهوية وإدارة الوصول والتخزين من حيث صلتها بالبنية الأساسية المستهدفة.

الإدارة

يتمثل الجانب الأساسي للإدارة الذي تتناوله هذه البنية في الفصل من خلال عزل موارد الشبكة. في CCM، يوصي DCS-08 بالتحكم في الدخول والخروج لمركز البيانات. لإرضاء التحكم، تستخدم البنية تصميماً مركزياً وتحدثاً باستخدام Network Security Groups (NSGs) لتصفية نسبة استخدام الشبكة بين الشرق والغرب بين الموارد. تقوم البنية أيضاً بتصفية نسبة استخدام الشبكة بين الخدمات المركزية في المركز والموارد الموجودة في الكلام. تستخدم البنية مثيل Azure Firewall لإدارة نسبة استخدام الشبكة بين الإنترنت والموارد داخل البنية.

تعرض القائمة التالية عنصر التحكم الذي يعالج أمان مركز البيانات في هذا المرجع:

CSA CCM Control ID CSA CCM Control Domain
DCS-08 Datacenter Security Unauthorized Persons Entry

الشبكة

تصميم الشبكة الذي يدعم هذه البنية مستمد من نموذج المحور والتحدث التقليدي. يضمن هذا القرار أن عزل الشبكة هو بناء أساسي. التحكم في CCM يوصي IVS-06 بتقييد نسبة استخدام الشبكة بين الشبكات والأجهزة الظاهرية ومراقبتها بين البيئات الموثوقة وغير الموثوقة. تتبنى هذه البنية التحكم من خلال تنفيذ NSGs لنسبة استخدام الشبكة بين الشرق والغرب (داخل "مركز البيانات")، وجدار الحماية Azure لنسبة استخدام الشبكة بين الشمال والجنوب (خارج "مركز البيانات"). يوصي IPY-04 بالتحكم في CCM بأن البنية الأساسية يجب أن تستخدم بروتوكولات شبكة آمنة لتبادل البيانات بين الخدمات. تستخدم خدمات Azure التي تدعم هذه البنية بروتوكولات آمنة قياسية مثل TLS لـHTTP وSQL.

تعرض القائمة التالية عناصر تحكم CCM التي تتناول أمان الشبكة في هذا المرجع:

CSA CCM Control ID CSA CCM Control Domain
IPY-04 Network Protocols
IVS-06 أمان الشبكة

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

تعرض القائمة التالية عناصر تحكم CIS التي تتناول أمان الشبكة في هذا المرجع:

CIS Control ID CIS Control Description
6.2 تأكد من أن الوصول إلى SSH مقيد من الإنترنت.
6.3 تأكد من عدم وجود SQL Databases تسمح بإدخال 0.0.0.0/0 (أي عنوان IP).
6.5 تأكد من 'تفعيل' Network Watcher.
6.6 تأكد من أن الدخول باستخدام UDP محظور من الإنترنت.

تتطلب Azure Spring Apps نسبة استخدام شبكة الإدارة للخروج من Azure عند توزيعها في بيئة آمنة. يجب السماح بقواعد الشبكة والتطبيق المدرجة في مسؤوليات العملاء لتشغيل Azure Spring Apps في شبكة ظاهرية.

أمان التطبيق

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

توضح القائمة التالية عناصر تحكم CCM التي تتناول إدارة المفاتيح في هذا المرجع:

CSA CCM Control ID CSA CCM Control Domain
EKM-01 Encryption وKey Management Entitlement
EKM-02 Encryption وKey Management Key Generation
EKM-03 Encryption وKey Management Sensitive Data Protection
EKM-04 Encryption وKey Management Storage and Access

يوصي كل من CCM وEKM-02 وEKM-03 بنُهج وإجراءات لإدارة المفاتيح واستخدام بروتوكولات التشفير لحماية البيانات الحساسة. توصي EKM-01 بأن يكون لجميع مفاتيح التشفير مالكون يمكن التعرف عليهم حتى يمكن إدارتها. توصي EKM-04 باستخدام الخوارزميات القياسية.

توضح القائمة التالية عناصر تحكم CIS التي تتناول إدارة المفاتيح في هذا المرجع:

CIS Control ID CIS Control Description
8.1 تأكد من تحديد تاريخ انتهاء الصلاحية على جميع المفاتيح.
8.2 تأكد من تحديد تاريخ انتهاء الصلاحية على جميع البيانات السرية.
8.4 تأكد من أن مخزن المفتاح قابل للاسترداد.

توصي ضوابط CIS 8.1 و8.2 بتعيين تواريخ انتهاء الصلاحية لبيانات الاعتماد لضمان تنفيذ التناوب. يضمن التحكم في نظام CIS 8.4 إمكانية استعادة محتويات مخزن المفتاح للحفاظ على استمرارية الأعمال.

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

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

استكشف هذه البنية للمرجع من خلال عمليات توزيع ARM وTerraform وAzure CLI المتوفرة في مستودع Azure Spring Apps Reference Architecture.