إدارة الشهادات في أنظمة مجموعات Service Fabric

مقالة
08/25/2024

تتناول هذه المقالة جوانب إدارة الشهادات المستخدمة لتأمين الاتصال في أنظمة مجموعات Azure Service Fabric. وهو يكمل المقدمة إلى أمان نظام مجموعة Service Fabric وشرح المصادقة المستندة إلى شهادة X.509 في Service Fabric.

المتطلبات الأساسية

قبل أن تبدأ، نفترض أنك على دراية بمفاهيم الأمان الأساسية، وكذلك بعناصر التحكم التي يعرضها Service Fabric لتكوين أمان نظام مجموعة.

إخلاء المسؤولية

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

تعريف إدارة الشهادات

كما تتعلم في المقالة المصاحبة المصادقة المستندة إلى شهادة X.509 في أنظمة مجموعات Service Fabric، فإن الشهادة هي عنصر تشفير يربط بشكل أساسي زوج مفاتيح غير متماثل بالسمات التي تصف الكيان الذي يمثله.

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

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

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

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

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

تقوم بقية المقالة أولاً بإلغاء هيكلة إدارة الشهادات، وتركز لاحقًا على تمكين التبديل التلقائي.

على وجه التحديد، يغطي الموضوعات التالية:

الافتراضات حول فصل الإسنادات بين المالك والنظام الأساسي
المسار الطويل للشهادات من الإصدار إلى الاستهلاك
تناوب الشهادة، لماذا وكيف ومتى
ما الذي قد يحدث بشكل خاطئ؟

لا تتناول المقالة هذه المواضيع:

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

للحصول على معلومات حول هذا الموضوع، ارجع إلى جهة التسجيل (RA) الخاصة بخدمة البنية الأساسية للمفتاح العام (PKI) المفضلة لديك. إذا كنت قارئًا داخليًا من Microsoft، يمكنك الوصول إلى أمان Azure.

الأدوار والكيانات المضمنة في إدارة الشهادات

نهج الأمان في نظام مجموعة Service Fabric هو حالة "يعلن عنها مالك نظام المجموعة، يفرضها وقت تشغيل Service Fabric." وهذا يعني أن أي من الشهادات أو المفاتيح أو بيانات الاعتماد الأخرى للهويات التي تشارك في عمل نظام المجموعة لا تأتي من الخدمة نفسها. تم الإعلان عنها جميعًا من قبل مالك نظام المجموعة. إن مالك نظام المجموعة مسؤول أيضًا عن تزويد الشهادات في نظام المجموعة، وتجديدها حسب الحاجة، وضمان أمان الشهادات في جميع الأوقات.

وبشكل أكثر تحديدًا، يجب على مالك نظام المجموعة التأكد من:

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

من جانبها، تتولى منصة Service Fabric المسؤوليات التالية:

تحديد موقع الشهادات التي تتطابق مع التعريفات في تعريف نظام المجموعة
منح حق الوصول إلى المفاتيح الخاصة المقابلة للكيانات التي يسيطر عليها Service Fabric على أساس الحاجة
التحقق من صحة الشهادات بما يتفق تمامًا مع أفضل ممارسات الأمان المعمول بها وتعريف نظام المجموعة
رفع تنبيهات حول انتهاء الصلاحية الوشيك للشهادات، أو الفشل في تنفيذ الخطوات الأساسية للتحقق من صحة الشهادة
التحقق (إلى حد ما) من أن الجوانب المتعلقة بالشهادة لتعريف نظام المجموعة يتم استيفاؤها من خلال التكوين الأساسي للمضيفين

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

الرحلة التي تمر بها الشهادة

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

يسجل مالك المجال لدى RA الخاص بـ PKI نطاقًا أو موضوعًا يريد ربطه بالشهادات اللاحقة. وتشكل الشهادات بدورها دليلاً على ملكية المجال أو الموضوع.
يعين مالك المجال أيضًا في RA هويات مقدمي الطلبات المعتمدين، والكيانات التي يحق لها طلب تسجيل الشهادات مع النطاق أو الموضوع المحدد.
ثم يقوم الطالب المعتمد بالتسجيل في شهادة عبر خدمة إدارة البيانات السرية. في Azure، خدمة إدارة البيانات السرية المفضلة هي Azure Key Vault، والتي تخزن البيانات السرية والشهادات بشكل آمن وتسمح باسترجاعها من قبل الكيانات المعتمدة. يقوم Key Vault أيضًا بتجديد الشهادة وإعادة إصدار مفاتيحها كما تم تكوينها في نهج الشهادة المقترنة. يستخدم Key Vault معرف Microsoft Entra كموفر الهوية.
يقوم المسترد المعتمد أو عامل التزويد، باسترداد الشهادة من مخزن المفاتيح، بما في ذلك مفتاحها الخاص، وتثبيتها على الأجهزة التي تستضيف نظام المجموعة.
تمنح خدمة Service Fabric (التي تعمل بشكل مرتفع على كل عقدة) حق الوصول إلى الشهادة لكيانات Service Fabric المسموح بها؛ يتم تعيينها من قبل المجموعات المحلية، ويتم تقسيمها بين ServiceFabricAdministrators وServiceFabricAllowedUsers.
يصل وقت تشغيل Service Fabric إلى الشهادة ويستخدمها لإنشاء اتحاد أو للمصادقة على الطلبات الواردة من العملاء المعتمدين.
يراقب عامل التزويد شهادة key vault، وعندما يكتشف التجديد، يقوم بتشغيل تدفق التزويد. ثم يقوم مالك نظام المجموعة بتحديث تعريف المجموعة، إذا لزم الأمر، للإشارة إلى هدف ترحيل الشهادة.
عامل التزويد أو مالك نظام المجموعة مسؤول أيضًا عن تنظيف وحذف الشهادات غير المستخدمة.

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

تُبين الرسومات التخطيطية التالية إصدار الشهادة وتدفق التزويد:

للشهادات التي تم تعريفها بواسطة بصمة الإبهام

رسم تخطيطي لتوفير الشهادات المُعرفة ببصمة الإبهام.

بالنسبة للشهادات التي تم الإعلان عنها بواسطة الاسم الشائع للموضوع

رسم تخطيطي لتوفير الشهادات المُعرفة بالاسم الشائع للموضوع.

تسجيل الشهادات

يتم تناول موضوع تسجيل الشهادة بالتفصيل في وثائق Key Vault. يتم تضمين ملخص هنا للاستمرارية والرجوع إليها بسهولة.

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

ينشئ مقدم الطلب نهج شهادة في Key Vault، والتي تحدد مجال/موضوع الشهادة، والمصدر المطلوب، ونوع المفتاح وطوله، واستخدام المفتاح المقصود، والمزيد. لمزيد من المعلومات، راجع الشهادات في Azure Key Vault.
ينشئ الطالب شهادة في نفس المخزن مع النهج المحدد في الخطوة السابقة. وهذا بدوره ينشئ زوجًا من المفاتيح ككائنات مخزن وطلب توقيع شهادة موقع باستخدام المفتاح الخاص، والذي يتم إعادة توجيهه بعد ذلك إلى جهة الإصدار المعينة للتوقيع.
بمجرد رد المُصدر (المرجع المصدق) بالشهادة الموقعة، يتم دمج النتيجة في المخزن، وتكون بيانات الشهادة متوفرة على النحو التالي:
- ضمن {vaultUri}/certificates/{name}: الشهادة وتشمل المفتاح العام وبيانات التعريف
- ضمن {vaultUri}/keys/{name}: مفتاح الشهادة الخاص، متوفر لعمليات التشفير (تضمين/ إلغاء تضمين، التوقيع/ التحقق)
- ضمن {vaultUri}/secrets/{name}: الشهادة، تشمل مفتاحها الخاص، وهي متوفرة للتنزيل كملف PFX أو PEM غير محمي.

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

تزويد الشهادة

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

في سياق هذه المقالة، سيُستضاف نظام المجموعة على مجموعة من أجهزة Azure الظاهرية (VMs) أو مجموعات مقياس الجهاز الظاهري. في Azure، يمكنك توفير شهادة من مخزن إلى VM/VMSS باستخدام الآليات التالية. يفترض هذا، كما كان من قبل، أن عامل التزويد تم منحه مسبقًا أذونات الحصول على البيانات السرية على مخزن المفاتيح من قبل مالك مخزن المفاتيح.

مخصص: يسترد عامل التشغيل الشهادة من مخزن المفاتيح (مثل PFX/PKCS #12 أو PEM) ويثبتها على كل عقدة.

لا يوصى باستخدام الآلية المخصصة، لأسباب متعددة، تتراوح من الأمان إلى التوافر، ولن تتم مناقشتها هنا بشكل أكبر. لمزيد من المعلومات، راجع الأسئلة المتداولة حول إنشاء شبكات لمجموعات تحجيم الجهاز الظاهري.
كـ بيانات سرية لمجموعة مقياس جهاز ظاهري أثناء التوزيع: باستخدام هوية الطرف الأول نيابةً عن عامل التشغيل، تسترد خدمة الحساب الشهادة من مخزن مُمكّن لتوزيع القوالب وتثبتها على كل عقدة من مجموعة مقياس الجهاز الظاهري كما هو موضح في الأسئلة المتداولة حول مجموعات مقياس الأجهزة الظاهرية في Azure.

إشعار

يسمح هذا النهج بتزويد البيانات السرية التي تم إصدارها فقط.
باستخدام ملحق الجهاز الظاهري لـ Key Vault. يتيح لك هذا تزويد الشهادات باستخدام إعلانات بدون إصدار، مع تحديث دوري للشهادات التي تمت ملاحظتها. في هذه الحالة، من المتوقع أن يكون لدى VM/VMSS هوية مدارة، وهي هوية تم منحها حق الوصول إلى مخازن المفاتيح التي تحتوي على الشهادات التي تمت ملاحظتها.

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

في المقابل، فإن التزويد المستند إلى ملحق الجهاز الظاهري لـ Key Vault يُثبت دائمًا أحدث إصدار من كل شهادة تمت ملاحظتها. ما يجعلها مناسبة فقط لأنظمة المجموعات المؤمنة بشهادات معلن عنها بالاسم الشائع للموضوع. للتأكيد، لا تستخدم آلية تزويد التحديث التلقائي (مثل ملحق الجهاز الظاهري لـ Key Vault) للشهادات التي يتم الإعلان عنها بواسطة مثيل (أي بواسطة بصمة الإبهام). خطر فقدان التوفر كبير.

توجد آليات تزويد أخرى، ولكن الأساليب المذكورة هنا هي الخيارات المقبولة حاليًا لأنظمة مجموعات Azure Service Fabric.

استهلاك الشهادات ومراقبتها

كما ذكرنا سابقًا، يكون وقت تشغيل Service Fabric مسؤولًا عن تحديد موقع الشهادات المعلنة في تعريف نظام المجموعة واستخدامها. تشرح مقالة المصادقة المستندة إلى شهادة X.509 في مجموعات Service Fabric بالتفصيل كيفية تنفيذ Service Fabric لقواعد العرض التقديمي والتحقق من الصحة، ولن تتم إعادة النظر فيها هنا. سنتظر هذه المقالة في الوصول ومنح الإذن، بالإضافة إلى المراقبة.

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

لكل شهادة مطابقة، يقع المفتاح الخاص المقابل، ويتم تحديث قائمة التحكم في الوصول التقديرية الخاصة به لتضمين الأذونات (القراءة والتنفيذ، عادة) التي يتم منحها للهوية التي تتطلبها.

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

تناوب الشهادة

إشعار

تحدد فرقة عمل هندسة الإنترنت (IETF) RFC 3647 بشكل رسمي التجديد على أنه إصدار شهادة بنفس سمات الشهادة التي يتم استبدالها. يتم الاحتفاظ بالمُصدر والمفتاح العام للموضوع والمعلومات. إعادة إصدار المفاتيح هي إصدار شهادة مع زوج مفاتيح جديد، دون قيود حول ما إذا كان يمكن لمصدر الشهادة أن يتغير. نظرًا لأن التمييز قد يكون مهمًّا (ضع في اعتبارك حالة الشهادات المعلنة بالاسم الشائع للموضوع مع تثبيت المصدر)، تستخدم هذه المقالة المصطلح المحايد التناوب لتغطية كلا السيناريوهين. ضع في اعتبارك أنه عند استخدام التجديد بشكل غير رسمي، فإنه يشير إلى إعادة إنشاء المفاتيح.

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

سيساعد Service Fabric من خلال رفع التحذيرات الصحية في وقت تاريخ انتهاء صلاحية الشهادة والذي يتم استخدامه حاليًّا في نظام المجموعة في وقت أقرب من الفاصل الزمني المحدد مسبقًا. عامل تزويد تلقائي، ملحق الجهاز الظاهري لـ Key Vault، الذي تم تكوينه لمراقبة شهادة مخزن المفاتيح، يستقصي بشكل دوري مخزن المفاتيح، ويكتشف التناوب، ويسترد الشهادة الجديدة ويثبتها. يتطلب التزويد الذي يحدث عبر ميزة البيانات السريةلـ VM/VMSS عامل تشغيل معتمد لتحديث VM/VMSS مع URI Key Vault الذي تم إصداره يتوافق مع الشهادة الجديدة.

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

بالنسبة للاتصالات الجديدة الداخلية، وكذلك داخل نظام المجموعة، سيحدد وقت تشغيل Service Fabric أحدث شهادة مطابقة تم إصدارها ويختارها (أكبر قيمة للخاصية NotBefore). هذا هو تغيير من الإصدارات السابقة من وقت تشغيل Service Fabric.
سيتم الحفاظ على تفعيل الاتصالات الحالية أو السماح لها بانتهاء صلاحيتها بشكل طبيعي أو إنهائها بطريقة أخرى؛ سيتم إخطار معالج داخلي بوجود تطابق جديد.

إشعار

حاليًا، اعتبارًا من الإصدار 7.2 CU4+، يحدد Service Fabric الشهادة مع قيمة الخاصية NotBefore الأكبر (الأحدث إصدارًا). قبل 7.2 CU4، اختار Service Fabric الشهادة الصالحة مع قيمة NotAfter الأكبر (منتهية الصلاحية مؤخرًا).

ويترجم هذا إلى الملاحظات الهامة التالية:

ويكون لتوفر نظام المجموعة أو التطبيقات المستضافة الأسبقية على التوجيه الخاص بتناوب الشهادة. سيتقارب نظام المجموعة على الشهادة الجديدة في النهاية، ولكن دون ضمانات توقيت. يترتب على ذلك ما يلي:
- وقد لا يكون من الواضح على الفور للمراقب أن الشهادة المتناوبة حلت محل سابقتها تمامًا. الطريقة الوحيدة لفرض الاستبدال الفوري للشهادة المستخدمة حاليًا هي إعادة تشغيل الأجهزة المضيفة. يكفي إعادة تشغيل عقد Service Fabric، حيث لن تتأثر مكونات وضع kernel التي تشكل اتصالات تأجير في نظام المجموعة. لاحظ أيضًا، أن إعادة تشغيل VM/VMSS قد يتسبب في فقدان مؤقت للتوافر. وبالنسبة لشهادات التطبيق، يكفي إعادة تشغيل مثيلات التطبيق المعنية فقط.
- يمكن أن يؤدي تقديم شهادة معاد إدخالها لا تفي بقواعد التحقق من الصحة إلى كسر نظام المجموعة بشكل فعال. المثال الأكثر شيوعًا على ذلك هو حالة مصدر شهادة غير متوقع: يتم الإعلان عن شهادات نظام المجموعة بالاسم الشائع للموضوع مع تثبيت مصدر الشهادة، ولكن تم إصدار الشهادة الدورية بواسطة مصدر الشهادة الجديد أو غير معلن.

تنظيف الشهادة

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

يتم توفير الشهادات التي يتم تعريفها على أنها بيانات سرية لـ VM/VMSS طالما تم الرجوع إليها في تعريف VM/VMSS ويمكن استردادها من مخزن المفاتيح. سيؤدي حذف البيانات السرية لمخزن المفاتيح أو الشهادة إلى فشل عمليات توزيع VM/VMSS اللاحقة. وبالمثل، سيؤدي تعطيل إصدار بيانات سرية في مخزن المفاتيح أيضًا إلى فشل عمليات توزيع VM/VMSS التي تشير إلى الإصدار البيانات السرية.
قد تكون الإصدارات السابقة من الشهادات التي يتم توفيرها عبر ملحق الجهاز الظاهري لـ Key Vault موجودة أو لا تكون موجودة على عقدة VM/VMSS. يقوم العامل باسترداد الإصدار الحالي وتثبيته فقط، ولا يقوم بإزالة أي شهادات. ستؤدي إعادة تصوير عقدة (التي تحدث عادةً كل شهر) إلى إعادة تعيين مخزن الشهادات إلى محتوى صورة نظام التشغيل، وبالتالي ستتم إزالة الإصدارات السابقة ضمنيًّا. ومع ذلك، ضع في اعتبارك أن توسيع نطاق مجموعة مقياس الجهاز الظاهري سيؤدي فقط إلى تثبيت الإصدار الحالي من الشهادات التي تم ملاحظتها. لا تفترض تجانس العقد فيما يتعلق بالشهادات المثبتة.

تبسيط الإدارة، مثال على التبديل التلقائي

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

يتم تغيير التحقق من صحة الشهادات من تثبيت بصمة الإبهام إلى الموضوع + تثبيت المصدر. أي شهادة ذات موضوع معين من مصدر معين موثوق بها على قدم المساواة.
يتم تسجيل الشهادات والحصول عليها من مخزن موثوق به (Key Vault)، ويتم تحديثها بواسطة عامل (في هذه الحالة، ملحق الجهاز الظاهري لـ KeyVault).
يتم تغيير تزويد الشهادات من وقت التوزيع والمستند إلى الإصدار (كما هو الحال بواسطة موفر موارد الحساب في Azure) إلى ما بعد التوزيع واستخدام عناوين KeyVault URI بدون إصدار.
يتم منح حق الوصول إلى مخزن المفاتيح عبر الهويات المدارة المعينة من قبل المستخدم. التي يتم إنشاءها وتعيينها إلى مجموعة مقياس الجهاز الظاهري الذي تم تعيينه أثناء التوزيع.
بعد التوزيع، يقوم العامل (ملحق الجهاز الظاهري لـ Key Vault) باستطلاع وتحديث الشهادات التي تمت ملاحظتها على كل عقدة من مجموعة مقياس الجهاز الظاهري. وبالتالي، فإن تناوب الشهادة تلقائي بالكامل، لأن Service Fabric يلتقط تلقائيًا أحدث شهادة صالحة.

التسلسل قابل للبرمجة النصية وتلقائي بالكامل ويسمح بالتوزيع الأولي بدون لمس من قبل المستخدم لنظام مجموعة تم تكوينها للتبديل التلقائي للشهادة. توفر الأقسام التالية خطوات مفصلة، والتي تحتوي على مزيج من PowerShell cmdlets وأجزاء من قوالب JSON. يمكن تحقيق الوظيفة نفسها باستخدام جميع الوسائل المدعومة للتفاعل مع Azure.

إشعار

يفترض هذا المثال وجود شهادة بالفعل في مخزن المفاتيح الخاص بك. يتطلب تسجيل شهادة مدارة من Key Vault وتجديدها، خطوات يدوية أساسية، كما هو موضح سابقًا في هذه المقالة. بالنسبة لبيئات التشغيل، استخدم الشهادات المدارة من Key Vault. لقد قمنا بإدراج نموذج برنامج نصي خاص بـ PKI داخلي من Microsoft.

إشعار

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

نقطة البدء

للإيجاز، سنفترض حالة البدء التالية:

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

فيما يلي مقتطف JSON من قالب يتوافق مع مثل هذه الحالة. يحذف المقتطف العديد من الإعدادات المطلوبة ويوضح الجوانب المتعلقة بالشهادة فقط.

  "resources": [
    {   ## VMSS definition
      "apiVersion": "[variables('vmssApiVersion')]",
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "name": "[variables('vmNodeTypeName')]",
      "location": "[variables('computeLocation')]",
      "properties": {
        "virtualMachineProfile": {
          "extensionProfile": {
            "extensions": [
            {
                "name": "[concat('ServiceFabricNodeVmExt','_vmNodeTypeName')]",
                "properties": {
                  "type": "ServiceFabricNode",
                  "autoUpgradeMinorVersion": true,
                  "publisher": "Microsoft.Azure.ServiceFabric",
                  "settings": {
                    "clusterEndpoint": "[reference(parameters('clusterName')).clusterEndpoint]",
                    "nodeTypeRef": "[variables('vmNodeTypeName')]",
                    "dataPath": "D:\\SvcFab",
                    "durabilityLevel": "Bronze",
                    "certificate": {
                        "thumbprint": "[parameters('primaryClusterCertificateTP')]",
                        "x509StoreName": "[parameters('certificateStoreValue')]"
                    }
                  },
                  "typeHandlerVersion": "1.1"
                }
            },}},
          "osProfile": {
            "adminPassword": "[parameters('adminPassword')]",
            "adminUsername": "[parameters('adminUsername')]",
            "secrets": [
            {
                "sourceVault": {
                    "id": "[resourceId('Microsoft.KeyVault/vaults', parameters('keyVaultName'))]"
                },
                "vaultCertificates": [
                {
                    "certificateStore": "[parameters('certificateStoreValue')]",
                    "certificateUrl": "[parameters('clusterCertificateUrlValue')]"
                },
            ]}]
        },
    },
    {   ## cluster definition
        "apiVersion": "[variables('sfrpApiVersion')]",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        "certificate": {
            "thumbprint": "[parameters('primaryClusterCertificateTP')]",
            "x509StoreName": "[parameters('certificateStoreValue')]"
        },
    }
  ]

تقول التعليمات البرمجية السابقة إن الشهادة ذات بصمة الإبهام json [parameters('primaryClusterCertificateTP')] والموجودة في KeyVault URIjson [parameters('clusterCertificateUrlValue')] يتم الإعلان عنها كشهادة نظام المجموعة الوحيدة، عن طريق بصمة الإبهام.

بعد ذلك سنقوم بإعداد الموارد الإضافية اللازمة لضمان تبديل الشهادة التلقائي.

إعداد الموارد الأساسية

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

يجب توزيع المقتطفات التالية في نفس الوقت. يتم سردها بشكل فردي فقط لتحليل التشغيل وشرحه.

أولاً، حدد هوية معينة من قبل المستخدم (يتم تضمين القيم الافتراضية كأمثلة). لمزيد من المعلومات، انظر الوثائق الرسمية.

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "userAssignedIdentityName": {
      "type": "string",
      "defaultValue": "sftstuaicus",
      "metadata": {
        "description": "User-assigned managed identity name"
      }
    },
  },
  "variables": {
      "vmssApiVersion": "2018-06-01",
      "sfrpApiVersion": "2018-02-01",
      "miApiVersion": "2018-11-30",
      "kvApiVersion": "2018-02-14",
      "userAssignedIdentityResourceId": "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', parameters('userAssignedIdentityName'))]"
  },    
  "resources": [
    {
      "type": "Microsoft.ManagedIdentity/userAssignedIdentities",
      "name": "[parameters('userAssignedIdentityName')]",
      "apiVersion": "[variables('miApiVersion')]",
      "location": "[resourceGroup().location]"
    },
  ]}

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

  "resources":
  [{
      "type": "Microsoft.KeyVault/vaults/accessPolicies",
      "name": "[concat(parameters('keyVaultName'), '/add')]",
      "apiVersion": "[variables('kvApiVersion')]",
      "properties": {
        "accessPolicies": [
          {
            "tenantId": "[reference(variables('userAssignedIdentityResourceId'), variables('miApiVersion')).tenantId]",
            "objectId": "[reference(variables('userAssignedIdentityResourceId'), variables('miApiVersion')).principalId]",
            "dependsOn": [
              "[variables('userAssignedIdentityResourceId')]"
            ],
            "permissions": {
              "secrets": [
                "get",
                "list"
              ]}}]}}]

في الخطوة التالية، ستقوم بما يلي:

تعيين الهوية التي تم تعيينها من قبل المستخدم إلى مجموعة مقياس الجهاز الظاهري.
الإعلان عن تبعية مجموعة مقياس الجهاز الظاهري على إنشاء الهوية المدارة، وعلى نتيجة منحها حق الوصول إلى المخزن.
تعريف ملحق الجهاز الظاهري لـ Key Vault وطلب استرداد الشهادات التي تمت ملاحظتها عند بدء التشغيل. لمزيد من المعلومات، راجع الوثائق الرسمية لـ ملحق الجهاز الظاهري لـ Key Vault لـ Windows.
حدث تعريف ملحق الجهاز الظاهري لـ Service Fabric للاعتماد على ملحق الجهاز الظاهري لـ Key Vault، وحول إعلان شهادة نظام المجموعة من بصمة الإبهام إلى الاسم الشائع.

إشعار

يتم إجراء هذه التغييرات كخطوة واحدة لأنها تندرج ضمن نطاق نفس المورد.

  "parameters": {
    "kvvmextPollingInterval": {
      "type": "string",
      "defaultValue": "3600",
      "metadata": {
        "description": "kv vm extension polling interval in seconds"
      }
    },
    "kvvmextLocalStoreName": {
      "type": "string",
      "defaultValue": "MY",
      "metadata": {
        "description": "kv vm extension local store name"
      }
    },
    "kvvmextLocalStoreLocation": {
      "type": "string",
      "defaultValue": "LocalMachine",
      "metadata": {
        "description": "kv vm extension local store location"
      }
    },
    "kvvmextObservedCertificates": {
      "type": "array",
      "defaultValue": [
                "https://sftestcus.vault.azure.net/secrets/sftstcncluster",
                "https://sftestcus.vault.azure.net/secrets/sftstcnserver"
            ],
      "metadata": {
        "description": "kv vm extension observed certificates versionless uri"
      }
    },
    "certificateCommonName": {
      "type": "string",
      "defaultValue": "cus.cluster.sftstcn.system.servicefabric.azure-int",
      "metadata": {
        "description": "Certificate Common name"
      }
    },
  },
  "resources": [
  {
    "apiVersion": "[variables('vmssApiVersion')]",
    "type": "Microsoft.Compute/virtualMachineScaleSets",
    "name": "[variables('vmNodeTypeName')]",
    "location": "[variables('computeLocation')]",
    "dependsOn": [
      "[variables('userAssignedIdentityResourceId')]",
      "[concat('Microsoft.KeyVault/vaults/', concat(parameters('keyVaultName'), '/accessPolicies/add'))]"
    ],
    "identity": {
      "type": "UserAssigned",
      "userAssignedIdentities": {
        "[variables('userAssignedIdentityResourceId')]": {}
      }
    },
    "virtualMachineProfile": {
      "extensionProfile": {
        "extensions": [
        {
          "name": "KVVMExtension",
          "properties": {
            "publisher": "Microsoft.Azure.KeyVault",
            "type": "KeyVaultForWindows",
            "typeHandlerVersion": "1.0",
            "autoUpgradeMinorVersion": true,
            "settings": {
                "secretsManagementSettings": {
                    "pollingIntervalInS": "[parameters('kvvmextPollingInterval')]",
                    "linkOnRenewal": false,
                    "observedCertificates": "[parameters('kvvmextObservedCertificates')]",
                    "requireInitialSync": true
                }
            }
          }
        },
        {
        "name": "[concat('ServiceFabricNodeVmExt','_vmNodeTypeName')]",
        "properties": {
          "type": "ServiceFabricNode",
          "provisionAfterExtensions" : [ "KVVMExtension" ],
          "publisher": "Microsoft.Azure.ServiceFabric",
          "settings": {
            "certificate": {
                "commonNames": [
                    "[parameters('certificateCommonName')]"
                ],
                "x509StoreName": "[parameters('certificateStoreValue')]"
            }
            },
            "typeHandlerVersion": "1.0"
          }
        },
  ] } ## extension profile
  },  ## VM profile
  "osProfile": {
    "adminPassword": "[parameters('adminPassword')]",
    "adminUsername": "[parameters('adminUsername')]",
  } 
  }
  ]

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

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

  "parameters": {
    "certificateCommonName": {
      "type": "string",
      "defaultValue": "cus.cluster.sftstcn.system.servicefabric.azure-int",
      "metadata": {
        "description": "Certificate Common name"
      }
    },
    "certificateIssuerThumbprint": {
      "type": "string",
      "defaultValue": "1b45ec255e0668375043ed5fe78a09ff1655844d,d7fe717b5ff3593764f4d90654d86e8362ec26c8,3ac7c3cac8de0dd392c02789c8be97474f456960,96ea05926e2e42cc207e358668be2c316857fb5e",
      "metadata": {
        "description": "Certificate issuer thumbprints separated by comma"
      }
    },
  },
  "resources": [
    {
      "apiVersion": "[variables('sfrpApiVersion')]",
      "type": "Microsoft.ServiceFabric/clusters",
      "name": "[parameters('clusterName')]",
      "location": "[parameters('clusterLocation')]",
      "properties": {
        "certificateCommonNames": {
          "commonNames": [{
              "certificateCommonName": "[parameters('certificateCommonName')]",
              "certificateIssuerThumbprint": "[parameters('certificateIssuerThumbprint')]"
          }],
          "x509StoreName": "[parameters('certificateStoreValue')]"
        },
  ]

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

التحليلات والملاحظات

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

حول تزويد الشهادات

يعمل ملحق الجهاز الظاهري لـ Key Vault، كعامل تزويد، بشكل مستمر على تردد محدد مسبقًا. عند الفشل في استرداد شهادة تمت ملاحظتها، ستستمر في الخط التالي، ثم السبات حتى الدورة التالية. سيتطلب ملحق الجهاز الظاهري لـ Service Fabric، كعامل نظام تمهيد لتشغيل نظام المجموعة، الشهادات المعلنة قبل تشكيل نظام المجموعة. وهذا بدوره يعني أنه لا يمكن تشغيل الجهاز الظاهري لـ Service Fabric إلا بعد الاسترداد الناجح لشهادة (شهادات) نظام المجموعة، المشار إليها هنا json "provisionAfterExtensions" : [ "KVVMExtension" ]"بالجملة، وإعداد ملحق الجهاز الظاهري لـ Key Vaultjson "requireInitialSync": true.

يشير هذا إلى ملحق الجهاز الظاهري لـ Key Vault أنه في التشغيل الأول (بعد التوزيع أو إعادة التشغيل) يجب أن يدور عبر شهاداته المرصودة حتى يتم تنزيل كل الشهادات بنجاح. سيؤدي تعيين هذه المعلمة إلى "خطأ"، مقترنًا بفشل في استرداد شهادة (شهادات) نظام المجموعة إلى فشل توزيع نظام المجموعة. وعلى العكس من ذلك، فإن طلب مزامنة أولية مع قائمة غير صحيحة/ غير صالحة من الشهادات المرصودة سيؤدي إلى فشل ملحق الجهاز الظاهري لـ Key Vault، وبالتالي، مرة أخرى، فشل في توزيع نظام المجموعة.

ربط الشهادة، موضح

ربما لاحظت علامة ملحق الجهاز الظاهري لـ Key VaultlinkOnRenewal، وحقيقة أنه تم تعيينه على false. يتناول هذا الإعداد السلوك الذي تتحكم فيه هذه العلامة وآثارها على عمل نظام المجموعة. هذا السلوك خاص بنظام التشغيل Windows.

وفقًا للتعريف:

"linkOnRenewal": <Only Windows. This feature enables auto-rotation of SSL certificates, without necessitating a re-deployment or binding. e.g.: false>,

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

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

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

إذا تم تمكين الربط، فسيحاول ملحق الجهاز الظاهري لـ KeyVault، عند استرداد شهادة تمت ملاحظتها من مخزن المفاتيح، العثور على شهادات مطابقة موجودة من أجل ربطها عبر خاصية ملحق التجديد. تستند المطابقة حصريًا إلى الاسم البديل للموضوع (SAN)، وتعمل، إذا كانت هناك شهادتان موجودتان، كما هو موضح في الأمثلة التالية: A: Certificate name (CN) = “Alice's accessories”, SAN = {“alice.universalexports.com”}, renewal = ‘’ B: CN = “Bob's bits”, SAN = {“bob.universalexports.com”, “bob.universalexports.net”}, renewal = ‘’

افترض أن الشهادة C تم استردادها بواسطة ملحق الجهاز الظاهري لـ Key Vault، وهو: CN = “Mallory's malware”, SAN = {“alice.universalexports.com”, “bob.universalexports.com”, “mallory.universalexports.com”}

يتم تضمين قائمة شبكة منطقة النظام للشهادة A بالكامل في C، وبالتالي A.renewal = C.thumbprint. تحتوي شبكة منطقة النظام (SAN) الخاصة بالشهادة B على تقاطع مشترك مع C، ولكنها غير مضمنة بالكامل فيها، لذلك يظل B.renewal فارغًا.

أي محاولة لاستدعاء AcquireCredentialsHandle (قناة S) في هذه الحالة إلى الشهادة A ستنتهي في الواقع بإرسال C إلى الطرف البعيد. في حالة Service Fabric، يستخدم النظام الفرعي للنقل الخاص بنظام مجموعة قناة S للمصادقة المتبادلة، وبالتالي فإن السلوك الموضح أعلاه يؤثر على الاتصال الأساسي لنظام المجموعة مباشرةً. بالاستمرار في المثال السابق، وبافتراض أن A هي شهادة نظام المجموعة، يعتمد ما يحدث بعد ذلك على:

إذا لم يكن المفتاح الخاص لشهادة C متصلًا بالحساب الذي يعمل عليه Service Fabric، فسنرى إخفاقات في الحصول على المفتاح الخاص (SEC_E_UNKNOWN_CREDENTIALS أو ما شابه).
إذا كان المفتاح الخاص لشهادة C قابلًا للوصول، فسنرى حالات فشل التخويل التي يتم إرجاعها بواسطة العقد الأخرى (شهادة غير مطابقة، غير مصرح بها، إلخ).

في كلتا الحالتين، يفشل النقل وقد ينخفض مستوى نظام المجموعة. تختلف الأعراض. ومما يزيد الأمر سوء، أن الربط يعتمد على ترتيب التجديد، الذي يمليه ترتيب قائمة الشهادات التي تم ملاحظتها لملحق الجهاز الظاهري لـ Key Vault، أو جدول التجديد في مخزن المفاتيح أو حتى الأخطاء العابرة التي من شأنها تغيير ترتيب الاسترجاع.

للتخفيف من حدة مثل هذه الأحداث، نوصي بما يلي:

لا تخلط الأسماء البديلة للموضوع لشهادات المخزن المختلفة. يجب أن تخدم كل شهادة مخزن غرضًا متميزًا، ويجب أن يعكس موضوعها وشبكة منطقة النظام (SAN) ذلك بدقة.
تضمين الاسم الشائع للموضوع في قائمة شبكة منطقة النظام (كما هو حرفيًّا، CN=<subject common name>).
إذا لم تكن متأكدًا من كيفية المتابعة، فقم بتعطيل الارتباط عند تجديد الشهادات التي يتم توفيرها مع ملحق الجهاز الظاهري لـ Key Vault.

إشعار

تعطيل الارتباط هو خاصية من المستوى الأعلى لملحق الجهاز الظاهري لـ Key Vault ولا يمكن تعيينها للشهادات الفردية التي تمت ملاحظتها.

لم يجب استخدام هوية مدارة معينة من قبل المستخدم؟ ما هي الآثار المترتبة على استخدامها؟

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

يعتمد ملحق الجهاز الظاهري لـ Service Fabric الذي يقوم بتمهيد تشغيل نظام المجموعة على إكمال ملحق الجهاز الظاهري لـ KeyVault، الذي يعتمد على الاسترداد الناجح للشهادات التي تمت ملاحظتها.

يستخدم ملحق الجهاز الظاهري لـ Key Vault هوية مجموعة مقياس الجهاز الظاهري للوصول إلى المخزن، مما يعني أنه يجب تحديث نهج الوصول الموجودة على المخزن بالفعل قبل توزيع مجموعة مقياس الجهاز الظاهري.

للتخلص من إنشاء هوية مدارة، أو لتعيينها إلى مورد آخر، يجب أن يكون لعامل تشغيل التوزيع الدور المطلوب (ManagedIdentityOperator) في الاشتراك أو مجموعة الموارد، بالإضافة إلى الأدوار المطلوبة لإدارة الموارد الأخرى المشار إليها في القالب.

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

استكشاف الأخطاء وإصلاحها والأسئلة المتداولة

س: كيفية التسجيل بشكل برمجي في شهادة مدارة من قبل KeyVault؟

تعرّف على اسم مصدر الشهادة من وثائق KeyVault، ثم استبدله في البرنامج النصي أدناه:

  $issuerName=<depends on your PKI of choice>
	$clusterVault="sftestcus"
	$clusterCertVaultName="sftstcncluster"
	$clusterCertCN="cus.cluster.sftstcn.system.servicefabric.azure-int"
	Set-AzKeyVaultCertificateIssuer -VaultName $clusterVault -Name $issuerName -IssuerProvider $issuerName
	$distinguishedName="CN=" + $clusterCertCN
	$policy = New-AzKeyVaultCertificatePolicy `
	    -IssuerName $issuerName `
	    -SubjectName $distinguishedName `
	    -SecretContentType 'application/x-pkcs12' `
	    -Ekus "1.3.6.1.5.5.7.3.1", "1.3.6.1.5.5.7.3.2" `
	    -ValidityInMonths 4 `
	    -KeyType 'RSA' `
	    -RenewAtPercentageLifetime 75        
	Add-AzKeyVaultCertificate -VaultName $clusterVault -Name $clusterCertVaultName -CertificatePolicy $policy
	
	# poll the result of the enrollment
	Get-AzKeyVaultCertificateOperation -VaultName $clusterVault -Name $clusterCertVaultName

س: ماذا يحدث عندما يتم إصدار شهادة من قبل مصدر شهادة غير معلن أو غير محدد؟ أين يمكنني الحصول على قائمة شاملة بالجهات المصدرة للشهادة النشطة لبنية PKI معينة؟

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

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

بالنسبة إلى واجهات PKIs الداخلية من Microsoft، تأكد من مراجعة الوثائق الداخلية حول نقاط النهاية وSDKs المستخدمة لاسترداد المصدرين المعتمدين. تقع على عاتق مالك نظام المجموعة مسؤولية مراجعة هذه القائمة بشكل دوري للتأكد من أن تعريف نظام المجموعة يتضمن جميع المصدرين المتوقعين.

س: هل يتم دعم العديد من PKI؟

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

س: ماذا لو لم يتم إصدار شهادة نظام المجموعة الحالية بواسطة CA، أو لم يكن لديها الموضوع المقصود؟

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

مشاركة عبر

إدارة الشهادات في أنظمة مجموعات Service Fabric

المتطلبات الأساسية

إخلاء المسؤولية

تعريف إدارة الشهادات

الأدوار والكيانات المضمنة في إدارة الشهادات

الرحلة التي تمر بها الشهادة

تسجيل الشهادات

تزويد الشهادة

استهلاك الشهادات ومراقبتها

تناوب الشهادة

تنظيف الشهادة

تبسيط الإدارة، مثال على التبديل التلقائي

نقطة البدء

إعداد الموارد الأساسية

التحليلات والملاحظات

حول تزويد الشهادات

ربط الشهادة، موضح

لم يجب استخدام هوية مدارة معينة من قبل المستخدم؟ ما هي الآثار المترتبة على استخدامها؟

استكشاف الأخطاء وإصلاحها والأسئلة المتداولة

الملاحظات

الموارد الإضافية