Share via

شبكة Azure Dedicated HSM

  • مقالة

يتطلب Azure Dedicated HSM بيئة شبكة آمنة للغاية. هذا صحيح سواء كان من سحابة Azure مرة أخرى إلى بيئة تكنولوجيا المعلومات للعميل (محليا)، أو باستخدام التطبيقات الموزعة أو لسيناريوهات قابلية الوصول العالية. توفر Azure Networking هذا وهناك أربعة مجالات مميزة يجب معالجتها.

  • إنشاء أجهزة HSM داخل الشبكة الظاهرية (VNet) في Azure
  • الاتصال المحلي بالموارد المستندة إلى السحابة لتكوين وإدارة أجهزة HSM
  • إنشاء الشبكات الظاهرية وتوصيليها لموارد التطبيق وأجهزة HSM المترابطة
  • توصيل الشبكات الظاهرية عبر المناطق للاتصال البيني وأيضا لتمكين سيناريوهات قابلية الوصول العالية

الشبكة الظاهرية للأجهزة HSM المخصصة

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

الشبكات الظاهرية

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

الشبكات الفرعيه

تقوم الشبكات الفرعية بتقسيم الشبكة الظاهرية إلى مساحات عناوين منفصلة يمكن استخدامها بواسطة موارد Azure التي تضعها فيها. يتم نشر HSMs المخصصة في شبكة فرعية في الشبكة الظاهرية. سيتلقى كل جهاز HSM مخصص يتم نشره في الشبكة الفرعية للعميل عنوان IP خاصا من هذه الشبكة الفرعية. يجب تفويض الشبكة الفرعية التي يتم فيها نشر جهاز HSM بشكل صريح إلى الخدمة: Microsoft.HardwareSecurityModules/dedicatedHSMs. يمنح هذا أذونات معينة لخدمة HSM للتوزيع في الشبكة الفرعية. يفرض التفويض إلى أجهزة HSM المخصصة بعض قيود النهج على الشبكة الفرعية. مجموعات أمان الشبكة (NSGs) ومسارات User-Defined (UDRs) غير مدعومة حاليا على الشبكات الفرعية المفوضة. ونتيجة لذلك، بمجرد تفويض شبكة فرعية إلى HSMs مخصصة، يمكن استخدامها فقط لنشر موارد HSM. سيفشل نشر أي موارد عملاء أخرى في الشبكة الفرعية. لا توجد متطلبات بشأن مدى حجم الشبكة الفرعية ل Dedicated HSM أو صغيرها، ومع ذلك سيستهلك كل جهاز HSM عنوان IP خاصا واحدا، لذلك يجب التأكد من أن الشبكة الفرعية كبيرة بما يكفي لاستيعاب أكبر عدد من أجهزة HSM كما هو مطلوب للتوزيع.

بوابة ExpressRoute

أحد متطلبات البنية الحالية هو تكوين بوابة ExpressRoute في الشبكة الفرعية للعملاء حيث يجب وضع جهاز HSM لتمكين تكامل جهاز HSM في Azure. لا يمكن استخدام بوابة ExpressRoute هذه لتوصيل المواقع المحلية بأجهزة HSM للعملاء في Azure.

توصيل تكنولوجيا المعلومات المحلية ب Azure

عند إنشاء موارد مستندة إلى السحابة، يعد مطلبا نموذجيا لاتصال خاص مرة أخرى بموارد تكنولوجيا المعلومات المحلية. في حالة Dedicated HSM، سيكون هذا في الغالب لبرنامج عميل HSM لتكوين أجهزة HSM وأيضا للأنشطة مثل النسخ الاحتياطية وسحب السجلات من HSMs للتحليل. نقطة القرار الرئيسية هنا هي طبيعة الاتصال حيث توجد خيارات. الخيار الأكثر مرونة هو VPN من موقع إلى موقع حيث من المحتمل أن تكون هناك موارد محلية متعددة تتطلب اتصالا آمنا بالموارد (بما في ذلك HSMs) في سحابة Azure. سيتطلب هذا من مؤسسة العملاء أن يكون لديها جهاز VPN لتسهيل الاتصال. يمكن استخدام اتصال VPN من نقطة إلى موقع إذا كان هناك نقطة نهاية واحدة فقط في الموقع مثل محطة عمل إدارية واحدة. لمزيد من المعلومات حول خيارات الاتصال، راجع خيارات تخطيط بوابة VPN.

ملاحظة

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

شبكة ظاهرية خاصة من نقطة إلى موقع

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

شبكة ظاهرية خاصة من موقع إلى موقع

تسمح الشبكة الظاهرية الخاصة من موقع إلى موقع بالاتصال الآمن بين HSMs المخصصة المستندة إلى Azure و تكنولوجيا المعلومات المحلية. سبب للقيام بذلك هو وجود منشأة نسخ احتياطي ل HSM المحلي وتحتاج إلى اتصال بين الاثنين لتشغيل النسخة الاحتياطية.

توصيل الشبكات الظاهرية

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

قران الشبكة الظاهرية

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

تناظر الشبكة

الاتصال عبر مناطق Azure

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

قابلية الوصول العالية عبر المناطق باستخدام بوابة VPN

بالنسبة للتطبيقات الموزعة عالميا أو لسيناريوهات تجاوز الفشل الإقليمية عالية التوفر، يلزم توصيل الشبكات الظاهرية عبر المناطق. باستخدام Azure Dedicated HSM، يمكن تحقيق قابلية وصول عالية باستخدام بوابة VPN التي توفر نفقا آمنا بين الشبكتين الظاهريتين. لمزيد من المعلومات حول اتصالات Vnet-to-Vnet باستخدام بوابة VPN، راجع المقالة بعنوان ما هي بوابة VPN؟

ملاحظة

لا يتوفر نظير الشبكة الظاهرية العمومية في سيناريوهات الاتصال عبر المناطق باستخدام Dedicated HSMs في هذا الوقت ويجب استخدام بوابة VPN بدلا من ذلك.

يوضح الرسم التخطيطي منطقتين متصلتين ببوابة V P N. تحتوي كل منطقة على شبكات ظاهرية نظيرة.

قيود الشبكات

ملاحظة

يتم فرض قيود على خدمة Dedicated HSM باستخدام تفويض الشبكة الفرعية التي يجب مراعاتها عند تصميم بنية الشبكة الهدف لتوزيع HSM. استخدام تفويض الشبكة الفرعية يعني أن NSGs وUDRs و Global VNet Peering غير مدعومة ل Dedicated HSM. تقدم الأقسام أدناه المساعدة في التقنيات البديلة لتحقيق نفس النتيجة أو نتائج مماثلة لهذه القدرات.

لا يمكن ل HSM NIC الموجود في شبكة HSM الظاهرية المخصصة استخدام مجموعات أمان الشبكة أو المسارات المعرفة من قبل المستخدم. وهذا يعني أنه لا يمكن تعيين نهج الرفض الافتراضي من وجهة نظر الشبكة الظاهرية ل HSM المخصص، وأنه يجب السماح لشرائح الشبكة الأخرى بالوصول إلى خدمة Dedicated HSM.

تسمح إضافة حل وكيل الأجهزة الظاهرية للشبكة (NVA) أيضا بوضع جدار حماية NVA في مركز النقل/DMZ منطقيا أمام HSM NIC، وبالتالي توفير البديل المطلوب لمجموعات أمان الشبكة وUDRs.

هندسة الحلول

يتطلب تصميم الشبكات هذا العناصر التالية:

  1. نقل أو شبكة ظاهرية لمركز DMZ مع طبقة وكيل NVA. من الناحية المثالية يوجد اثنان أو أكثر من NVAs.
  2. دائرة ExpressRoute مع تمكين نظير خاص واتصال بشبكة VNet لمركز النقل.
  3. نظير VNet بين الشبكة الظاهرية لمركز النقل وشبكة HSM الظاهرية المخصصة.
  4. يمكن نشر جدار حماية NVA أو جدار حماية Azure تقديم خدمات DMZ في المركز كخيار.
  5. يمكن تناظر الشبكات الظاهرية الإضافية المحورية لحمل العمل مع الشبكة الظاهرية للمركز. يمكن لعميل Gemalto الوصول إلى خدمة HSM المخصصة من خلال الشبكة الظاهرية للمركز.

يوضح الرسم التخطيطي الشبكة الظاهرية لمركز DMZ مع طبقة وكيل NVA لحل NSG وUDR

نظرا لأن إضافة حل وكيل NVA يسمح أيضا بوضع جدار حماية NVA في مركز النقل/DMZ منطقيا أمام HSM NIC، وبالتالي توفير نهج الرفض الافتراضي المطلوبة. في مثالنا، سنستخدم جدار حماية Azure لهذا الغرض وسنحتاج إلى العناصر التالية في مكانها:

  1. تم توزيع جدار حماية Azure في الشبكة الفرعية "AzureFirewallSubnet" في الشبكة الظاهرية لمركز DMZ
  2. جدول توجيه مع UDR يوجه نسبة استخدام الشبكة المتجهة إلى نقطة النهاية الخاصة ل Azure ILB في جدار حماية Azure. سيتم تطبيق جدول التوجيه هذا على GatewaySubnet حيث يوجد العميل ExpressRoute Virtual Gateway
  3. قواعد أمان الشبكة داخل AzureFirewall للسماح بإعادة التوجيه بين نطاق مصدر موثوق به ونقطة نهاية Azure IBL الخاصة الاستماع على منفذ TCP 1792. سيضيف منطق الأمان هذا نهج "الرفض الافتراضي" الضروري مقابل خدمة Dedicated HSM. بمعنى أنه سيتم السماح فقط لنطاقات IP المصدر الموثوق بها في خدمة Dedicated HSM. سيتم إسقاط جميع النطاقات الأخرى.
  4. جدول توجيه مع UDR يوجه نسبة استخدام الشبكة المتجهة إلى الإعدادات المسبقة في جدار حماية Azure. سيتم تطبيق جدول التوجيه هذا على الشبكة الفرعية لوكيل NVA.
  5. تم تطبيق NSG على الشبكة الفرعية NVA الوكيل للثقة فقط في نطاق الشبكة الفرعية لجدار حماية Azure كمصدر، والسماح فقط بإعادة التوجيه إلى عنوان IP HSM NIC عبر منفذ TCP 1792.

ملاحظة

نظرا لأن طبقة وكيل NVA ستقوم ب SNAT عنوان IP للعميل أثناء إعادة توجيهه إلى HSM NIC، لا يلزم وجود UDRs بين HSM VNet وDMZ hub VNet.

بديل ل UDRs

يعمل حل طبقة NVA المذكور أعلاه كبديل ل UDRs. هناك بعض النقاط الهامة التي يجب ملاحظتها.

  1. يجب تكوين ترجمة عنوان الشبكة على NVA للسماح بتوجيه نسبة استخدام الشبكة العائدة بشكل صحيح.
  2. يجب على العملاء تعطيل ip-check للعميل في تكوين Luna HSM لاستخدام VNA ل NAT. الأوامر التالية servce كمثال.
Disable:
[hsm01] lunash:>ntls ipcheck disable
NTLS client source IP validation disabled
Command Result : 0 (Success)

Show:
[hsm01] lunash:>ntls ipcheck show
NTLS client source IP validation : Disable
Command Result : 0 (Success)
  1. نشر UDRs لنسبة استخدام الشبكة للدخول إلى طبقة NVA.
  2. وفقا للتصميم، لن تبدأ الشبكات الفرعية HSM طلب اتصال صادر بطبقة النظام الأساسي.

بديل لاستخدام نظير الشبكة الظاهرية العمومية

هناك نوعان من البنيات التي يمكنك استخدامها كبديل لتناظر الشبكة الظاهرية العالمية.

  1. استخدام Vnet-to-Vnet VPN Gateway Connection
  2. قم بتوصيل HSM VNET بشبكة ظاهرية أخرى مع دائرة ER. يعمل هذا بشكل أفضل عندما يكون هناك حاجة إلى مسار محلي مباشر أو VPN VNET.

HSM مع اتصال Express Route المباشر

رسم تخطيطي يوضح HSM مع اتصال Express Route المباشر

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