سيناريوهات النشر
تنشر Microsoft وحدات أمان أجهزة الدفع (HSM) في طوابع داخل منطقة ومتعددة المناطق لتمكين قابلية الوصول العالية (HA) والتعافي من الكوارث. في منطقة ما، يتم نشر HSMs عبر طوابع مختلفة لمنع فشل حامل واحد، ويجب على العملاء توفير جهازين في منطقة من طابعين منفصلين من أجل تحقيق قابلية وصول عالية. للتعافي من الكوارث، يجب على العميل توفير أجهزة HSM في منطقة بديلة.
لا توفر Thales PayShield SDK للعملاء، والتي تدعم HA عبر مجموعة (مجموعة من HSMs تمت تهيئتها بنفس LMK). ومع ذلك، فإن سيناريو استخدام العملاء لأجهزة Thales PayShield يشبه خادم عديم الحالة. وبالتالي، لا يلزم إجراء مزامنة بين HSMs أثناء وقت تشغيل التطبيق. يتعامل العملاء مع قابلية الوصول العالية باستخدام عميلهم المخصص. سيكون أحد التطبيقات هو موازنة التحميل بين HSMs السليمة المتصلة بالتطبيق. يتحمل العملاء مسؤولية تنفيذ قابلية وصول عالية عن طريق توفير أجهزة متعددة، وموازنة التحميل، واستخدام أي نوع من آلية النسخ الاحتياطي المتوفرة لنسخ المفاتيح احتياطيا.
هام
- تأكد من أن مهندس حلول السحابة من Microsoft قام بمراجعة تصميم تصميم توزيع HSM للدفع والاستعداد قبل إطلاق الإنتاج.
- راجع المخططات والقيود المدعومة المدرجة في تصميم الحل.
- مجموعات أمان الشبكة والمسارات المعرفة من قبل المستخدم غير مدعومة لشبكات HSM الفرعية للدفع.
- لا يدعم تناظر الشبكة الظاهرية الاتصال عبر المناطق مع مثيلات الدفع HSM. لا يمكن للجهاز الظاهري في منطقة واحدة الاتصال بمثيل HSM للدفع في منطقة أخرى دون استخدام ExpressRoute أو بوابة VPN.
- يمكن للعملاء تخصيص اثنين كحد أقصى من وحدات HSM للدفع من كل طابع في منطقة واحدة ضمن نفس الاشتراك.
- إذا لم يكن لدى العميل إعداد قابلية وصول عالية في بيئة الإنتاج الخاصة به، فلن يتمكن العميل من تلقي دعم S2 من جانب Microsoft.
توزيع قابلية الوصول المرتفعة
بالنسبة إلى قابلية الوصول العالية، يجب على العميل تخصيص HSMs بين الطابع 1 والطابع 2 (بمعنى آخر، لا يوجد وحدتا HSM من نفس الطابع)
نشر التعافي من الكوارث
يلبي هذا السيناريو الفشل على المستوى الإقليمي. الإستراتيجية المعتادة هي تبديل مكدس التطبيقات بالكامل (وHSMs الخاصة به)، بدلا من محاولة الوصول إلى HSM في المنطقة 2 من التطبيق في المنطقة 1 بسبب زمن الانتقال.