شبكة 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 المخصصة في شبكة فرعية في الشبكة الظاهرية. سيتلقى كل جهاز Dedicated HSM يتم نشره في الشبكة الفرعية للعميل عنوان IP خاصا من هذه الشبكة الفرعية. يجب تفويض الشبكة الفرعية التي يتم فيها نشر جهاز HSM بشكل صريح إلى الخدمة: Microsoft.HardwareSecurityModules/dedicatedHSMs. وهذا يمنح أذونات معينة لخدمة HSM للنشر في الشبكة الفرعية. يفرض التفويض إلى Dedicated HSMs قيودا معينة على السياسة على الشبكة الفرعية. مجموعات أمان الشبكة (NSGs) والمسارات المعرفة من قبل المستخدم (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 بدلا من ذلك.

قيود الشبكات

إشعار

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

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

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

مصمم الحلول

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

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

نظرا لأن إضافة حل وكيل 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 يوجه حركة المرور المتجهة إلى prem إلى جدار حماية Azure. سيتم تطبيق جدول التوجيه هذا على الشبكة الفرعية لوكيل NVA.
5. تم تطبيق NSG على الشبكة الفرعية ل Proxy 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)

3. نشر UDRs لحركة مرور الدخول إلى طبقة NVA.
4. وفقا للتصميم، لن تبدأ الشبكات الفرعية ل HSM طلب اتصال صادر إلى طبقة النظام الأساسي.

بديل لاستخدام نظير VNET العمومي

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

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

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

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

• الأسئلة الشائعة
• إمكانية الدعم
• توفُّر عالٍ
• الأمن المادي
• رصد
• بنية النشر