وصول محسّن بأمان إلى تطبيقات الويب متعددة العملاء من شبكة محلية

Azure App Service
Azure Virtual Network
Azure Private Link
Azure Key Vault
Azure Storage Accounts

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

بناء الأنظمة

رسم تخطيطي يوضح البنية المرجعية للوصول الآمن إلى تطبيقات الويب متعددة المستأجرين من شبكة محلية.

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

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

  • باستخدام تكامل الشبكة الظاهرية الإقليمية لـAzure App Service، يتصل تطبيق الويب بخدمات Azure من خلال الشبكة الفرعية المفوضة الشبكة الفرعية لتكامل الشبكة الظاهرية في شبكة Azure الظاهرية.

    • الشبكة الفرعية للتكامل VNet وشبكات الشبكة الفرعية لنقطة النهاية الخاصة هي شبكات ظاهرية منفصلة في اشتراكات مختلفة. يتم تناظر كلتا الشبكتين مع شبكة Hub الظاهرية كجزء من تكوين شبكة محورية. لتكامل الشبكة الظاهرية الإقليمية، يجب أن تكون الشبكات الظاهرية النظيرة في نفس منطقة Azure.
  • تقوم خدمة Azure Private Link بإعداد نقطة نهاية خاصة لخدمات PaaS وتطبيقات الويب وقاعدة بيانات Azure SQL وحساب تخزين Azure وخزنة مفاتيح Azure في الشبكة الظاهرية لنقطة النهاية الخاصة.

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

  • يمكن توصيل الشبكة المحلية وشبكات Azure الظاهرية عبر VPN من موقع لموقع (S2S) أو نظير Azure ExpressRoute الخاص. يصل المستخدمون في الشبكة المحلية إلى التطبيق بشكل خاص وبأمن معزز عبر الشبكة الخاصة فقط.

    في هذا المثال، يتم توصيل الشبكة المحلية وشبكات Azure الظاهرية عبر نظير ExpressRoute الخاص.

  • بالنسبة لشبكة محلية لديها بالفعل حل نظام أسماء المجالات (DNS)، يتم تكوين حل DNS المحلي لإعادة توجيه حركة مرور DNS إلى سجل DNS خاص Azure (على سبيل المثال، azurewebsites.net) عبر معاد توجيه شرطي يقوم بإعادة توجيه الطلب إلى نقطة النهاية الواردة لخدمة DNS Private Resolver التي تم نشرها في Azure. يستعلم DNS Private Resolver عن Azure DNS ويتلقى معلومات حول ارتباط شبكة Azure Private DNS الظاهرية. ثم يتم إجراء الدقة بواسطة منطقة DNS الخاصة المرتبطة بالشبكة الظاهرية.

    يتم أيضا نشر مناطق DNS الخاصة في نفس الاشتراك مثل الشبكة الظاهرية لنقطة النهاية الخاصة.

    في هذا المثال، يقوم جهاز إعادة توجيه DNS في عنوان IP 192.168.0.254 في الشبكة المحلية بإعادة توجيه جميع طلبات تحليل DNS إلى اسم المضيف azurewebsites.net إلى نقطة النهاية الواردة لخدمة DNS Private Resolver في Azure في العنوان 10.0.0.132. ثم يتم حل الطلبات بواسطة خدمة DNS التي توفرها Azure، والتي تحتوي على عنوان IP 168.63.129.16، عبر منطقة Azure Private DNS المرتبطة بالشبكة الظاهرية.

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

    تكوين مجموعة قواعد إعادة توجيه DNS غير مطلوب لهذا السيناريو.

    يجب أن يكون هذا التكوين لخدمة التطبيق موجودًا:

    مفتاح القيمة
    WEBSITE_DNS_SERVER 168.63.129.16
  • ترتبط الشبكات الظاهرية بجميع مناطق Azure Private DNS.

    • يتم ربط الشبكة الظاهرية التي تحتوي على نقاط نهاية خاصة تلقائيا بمناطق DNS الخاصة. تحتاج إلى ربط الشبكات الظاهرية الأخرى بشكل منفصل.
  • يتصل تطبيق الويب بنقاط النهاية الخاصة لخدمات PaaS في الشبكة الظاهرية لنقطة النهاية الخاصة عبر Azure Firewall.

  • في Azure Firewall، يتم تكوين قواعد التطبيق للسماح بالاتصال بين الشبكة الفرعية لتكامل الشبكة الظاهرية ونقاط النهاية الخاصة لموارد PaaS. أسماء المجالات المؤهلة بالكامل (FQDNs) المستهدفة هي:

    • *.azurewebsites.net
    • *.database.windows.net
    • *.core.windows.net
    • *.vaultcore.azure.net
  • يسمح جدار الحماية وتكوين الشبكة الظاهرية لـ Azure SQL وحساب Azure Storage وAzure Key Vault بحركة مرور فقط من الشبكة الفرعية لتكامل الشبكة الظاهرية. لا يسمح التكوين بالاتصال بأي شبكة ظاهرية أخرى أو بالإنترنت العام.

المكونات

  • تستضيف Azure App Service تطبيقات الويب وتطبيقات الوظائف، ما يسمح بالتحجيم التلقائي وقابلية الوصول العالية دون مطالبتك بإدارة البنية الأساسية.
  • Azure SQL Database هي خدمة مدارة لقاعدة بيانات ارتباطية للأغراض العامة تدعم البيانات الارتباطية والبيانات المكانية وJSON وXML.
  • يوفر حساب Azure Storage مساحة اسم فريدة لبيانات Azure Storage التي يمكن الوصول إليها من أي مكان في العالم عبر HTTP أو HTTPS. ويحتوي على جميع عناصر بيانات Azure Storage: الكائنات الثنائية كبيرة الحجم ومشاركة الملفات وقوائم الانتظار والجداول والأقراص.
  • Azure Key Vault هي خدمة للتخزين والوصول بأمان إلى مفاتيح واجهة برمجة التطبيقات وكلمات المرور والشهادات ومفاتيح التشفير أو أي أسرار أخرى تستخدمها التطبيقات والخدمات السحابية.
  • Azure Virtual Network هي لبنة الإنشاء الأساسية للشبكات الخاصة في Azure. يمكن لموارد Azure مثل الأجهزة الظاهرية الاتصال بأمان مع بعضها البعض والإنترنت والشبكات المحلية من خلال الشبكات الظاهرية.
  • يوفر Azure Private Link نقطة نهاية خاصة في شبكة ظاهرية للاتصال بخدمات Azure PaaS مثل Azure Storage وقاعدة بيانات SQL، أو بخدمات العملاء أو الشركاء.
  • يوسع نظير Azure ExpressRoute الخاص الشبكات المحلية إلى سحابة Microsoft عبر اتصال خاص. يمكنك أيضا إنشاء VPN من موقع لموقع بين الشبكة المحلية وشبكة Azure بدلًا من استخدام Azure ExpressRoute.
  • Azure Firewall هو خدمة أمان شبكة مدارة مستندة إلى السحابة تساعد على حماية موارد شبكة Azure الظاهرية.
  • توفر منطقة Azure Private DNS خدمة DNS موثوقة وآمنة لإدارة أسماء المجالات وحلها في الشبكة الظاهرية.
  • يتيح محلل DNS الخاص الاستعلام عن مناطق Azure DNS الخاصة من بيئة محلية، والعكس صحيح، دون نشر خوادم DNS المستندة إلى الجهاز الظاهري.

البدائل

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

إذا كان لديك App Service Environment ولكنك لا تستخدم مثيل SQL المدار، فلا يزال بإمكانك استخدام نقطة نهاية خاصة للاتصال الخاص بقاعدة بيانات Azure SQL. إذا كان لديك بالفعل SQL Managed Instance ولكنك تستخدم خدمة التطبيقات متعددة المستأجرين، فلا يزال بإمكانك استخدام تكامل VNet الإقليمي للاتصال بالعنوان الخاص SQL Managed Instance.

بالنسبة لبعض خدمات Azure الأخرى، مثل Key Vault أو Azure Storage، لا يوجد بديل لاستخدام نقاط النهاية الخاصة للاتصالات الآمنة والخاصة للغاية من Web Apps.

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

  • الوصول إلى تطبيق ويب متعدد المستأجرين أو تطبيق وظائف بشكل خاص مع تحسين الأمان عبر نقطة النهاية الخاصة به من شبكة محلية أو من داخل شبكات Azure الظاهرية.
  • الاتصال من تطبيق ويب أو تطبيق وظائف إلى عروض النظام الأساسي Azure كخدمة (PaaS):
    • تطبيق ويب آخر
    • قاعدة بيانات SQL
    • تخزين Azure
    • Key Vault
    • أي خدمة أخرى تدعم نقاط نهاية Azure الخاصة للاتصال الوارد

الاعتبارات

تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

الأمان

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

يتيح لك استخدام نقطة النهاية الخاصة لتطبيق الويب الخاص بك ما يلي:

  • المساعدة في تأمين تطبيق الويب الخاص بك عن طريق تكوين نقطة النهاية الخاصة، والقضاء على التعرض العام.
  • الاتصال بأمان معزز بـ Web Apps من الشبكات المحلية التي تتصل بالشبكة الظاهرية باستخدام VPN أو نظير ExpressRoute خاص. يسمح بالاتصالات الواردة إلى تطبيق الويب من الشبكة المحلية أو من داخل شبكة Azure الظاهرية فقط.
  • تجنب أي نقل غير مصرّح للبيانات من شبكتك الظاهرية.

يمكنك زيادة تعزيز أمان الاتصال الوارد بتطبيق الويب عن طريق إتاحة تطبيق به خدمة مثل Azure Application Gateway أو Azure Front Door، اختياريًا باستخدام Azure Web Application Firewall. عند تمكين نقطة النهاية الخاصة لتطبيق الويب الخاص بك، لا يتم تقييم تكوين قيود الوصول لتطبيق الويب.

يحسن هذا السيناريو أيضا أمان الاتصال الصادر من تطبيق ويب App Service إلى تبعية انتقال البيانات من الخادم مثل قاعدة بيانات أو Azure Storage أو Key Vault.

يمكنك تكوين توجيه التطبيق لتوجيه حركة المرور بالكامل أو حركة المرور الخاصة فقط (المعروفة أيضا باسم حركة مرورRFC1918) إلى شبكتك الظاهرية. يمكنك تكوين هذا السلوك باستخدام إعداد Route All. إذا تم تعطيل Route All، فإن تطبيق الويب يوجه حركة المرور الخاصة فقط إلى شبكتك الظاهرية. لحظر حركة المرور إلى العناوين العامة، قم بتمكين إعداد Route All إلى الشبكة الظاهرية. كما يمكنك استخدام مجموعة أمان الشبكة لحظر حركة المرور الصادرة إلى الموارد الموجودة في شبكتك الظاهرية أو الإنترنت. عندما لا يتم تمكين خيار Route All، يتم تطبيق مجموعات أمان الشبكة فقط على حركة مرور RFC1918.

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

أحد الاعتبارات الأمنية المهمة في هذا السيناريو هي تكوين جدار الحماية لموارد PaaS.

خيارات جدار حماية SQL Database

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

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

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

  • إنشاء قاعدة شبكة ظاهرية تسمح فقط بحركة المرور من الشبكة الفرعية الإقليمية المفوضة بواسطة تكامل الشبكة الظاهرية، الشبكة الفرعية لتكامل الشبكة الظاهرية في هذا المثال. يجب أن تحتوي الشبكة الفرعية المفوَّضة على نقطة تقديم الخدمة مهيأة لـ Microsoft.Sql، حتى تتمكن قاعدة البيانات من تحديد حركة المرور من تلك الشبكة الفرعية.
  • تكوين جدار الحماية لرفض الوصول إلى الشبكة العامة. يؤدي القيام بذلك إلى إيقاف تشغيل جميع قواعد جدار الحماية الأخرى ويجعل قاعدة البيانات غير متاحة إلا من خلال نقطة النهاية الخاصة بها فقط.

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

على سبيل المثال، لا يمكن لعمليات التوزيع أو الاتصالات اليدوية العاجلة من Server Management Studio (SSMS) على الأجهزة المحلية الوصول إلى قاعدة البيانات إلا من خلال اتصال VPN أو ExpressRoute بالشبكة الظاهرية. يمكنك أيضًا الاتصال عن بعد بجهاز ظاهري في الشبكة الظاهرية واستخدام SSMS من هناك. في حالات استثنائية، يمكنك السماح مؤقتاً بالوصول إلى الشبكة العامة وتقليل المخاطر باستخدام خيارات التكوين الأخرى.

خيارات حساب Azure Storage وجدار الحماية Key Vault

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

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

التوافر

يتوفر دعم الارتباط الخاص لخدمة التطبيقات وقاعدة بيانات Azure SQL وتخزين Azure وAzure Key Vault في جميع المناطق العامة. للتحقق من التوفر في مناطق أخرى، راجع توفر Azure Private Link

يقدم Private Link مكونا آخر واعتبار التوفر في البنية. تحتوي خدمة Private Link على اتفاقية مستوى خدمة عالية التوفر. تحتاج إلى أخذ اتفاقية مستوى الخدمة هذه في الاعتبار عند حساب اتفاقية مستوى الخدمة المركبة للحل بأكمله.

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

للحصول على معلومات حول دمج Azure Private Link لخدمات PaaS مع مناطق Azure Private DNS في بنيات شبكة النظام المحوري والمركزي، راجع تكامل Private Link وDNS على نطاق واسع.

التناظر العمومي

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

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

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

التسجيل والمراقبة

يتم دمج Azure Private Link مع Azure Monitor، والذي يسمح لك بمعرفة ما إذا كانت البيانات تتدفق.

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

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

يركز تحسين التكلفة على البحث عن طرق للحد من النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، راجع نظرة عامة على ركيزة تحسين التكلفة.

لا توجد تكلفة إضافية لتكامل VNet الإقليمي لخدمة التطبيقات في مستويات التسعير المدعومة في خطط Basic وStandard وPremium v2 وPremium v3 و Isolated v2 App Service وAzure Functions Premium.

تتوفر نقطة النهاية الخاصة لتطبيقات ويب Windows وتطبيقات ويب Linux، في حاوية أم لا، مستضافة على خطط Basic وStandard وPremium v2 وPremium v3 و Isolated v2 App Service، وأيضا لتطبيقات الوظائف المنشورة على خطة Premium.

تحتوي خدمة Azure Private Link التي تمكن نقاط النهاية الخاصة لخدمات PaaS على تكلفة مقترنة بناءً على رسوم بالساعة بالإضافة إلى قسط على النطاق الترددي. راجع صفحة أسعار الرابط الخاص للحصول على التفاصيل. تُفرض رسوم على الاتصالات من شبكة ظاهرية للعميل إلى جدار حماية Azure في الشبكة الظاهرية المركزية. لا يتم تحصيل رسوم منك مقابل الاتصالات من Azure Firewall في الشبكة الظاهرية المركزية بنقاط النهاية الخاصة في شبكة ظاهرية متناظرة.

تكلفة منطقة Azure Private DNS تعتمد على عدد مناطق DNS المستضافة في Azure وعلى عدد استعلامات DNS المتلقاة.

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

المساهمون

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

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

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

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