Share via

سيناريوهات أمان نظام مجموعة Service Fabric

  • مقالة

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

تتناول هذه المقالة نظرة عامة حول سيناريوهات الأمان لمجموعات Azure والمجموعات المستقلة، والتقنيات المختلفة التي يمكنك استخدامها لتنفيذها:

  • أمان العقدة إلى العقدة
  • أمان العميل إلى العقدة
  • التحكم في الوصول القائم على دور Service Fabric

أمان العقدة إلى العقدة

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

Diagram of node-to-node communication

يمكن للمجموعات التي تعمل على Azure والمجموعات المستقلة التي تعمل على Windows كلاهما استخدام أمان الشهادة أو أمان Windows لأجهزة كمبيوتر Windows Server.

أمان شهادة من عقدة إلى عقدة

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

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

لمعرفة كيفية إعداد أمان الشهادة في نظام مجموعة لـ Azure، راجع إعداد مجموعة باستخدام قالب Azure Resource Manager.

لمعرفة كيفية إعداد أمان الشهادة في نظام مجموعة لخادم Windows مستقل، راجع تأمين نظام مجموعة مستقلة على Windows باستخدام شهادات X.509.

أمان Windows من عقدة إلى عقدة

إشعار

تعتمد مصادقة Windows على Kerberos. NTLM غير معتمد كنوع مصادقة.

كلما كان ذلك ممكنًا، استخدم مصادقة شهادة X.509 لمجموعات «تصميم الخدمة».

لمعرفة كيفية إعداد أمان Windows لمجموعة خادم Windows مستقل، راجع تأمين مجموعة مستقلة على Windows باستخدام أمان Windows.

أمان العميل إلى العقدة

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

Diagram of client-to-node communication

يمكن للمجموعات التي تعمل على Azure والمجموعات المستقلة التي تعمل على Windows كلاهما استخدام أمان الشهادة أو أمان Windows، على الرغم من أن التوصية هي استخدام مصادقة شهادة X.509 كلما أمكن ذلك.

أمان شهادة العميل إلى العقدة

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

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

لمعرفة كيفية إعداد أمان الشهادة في نظام مجموعة لـ Azure، راجع إعداد مجموعة باستخدام قالب Azure Resource Manager.

لمعرفة كيفية إعداد أمان الشهادة في نظام مجموعة لخادم Windows مستقل، راجع تأمين نظام مجموعة مستقلة على Windows باستخدام شهادات X.509.

أمان Microsoft Entra من عميل إلى عقدة على Azure

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

بالنسبة للمجموعات التي تعمل على Azure، يمكنك أيضا استخدام معرف Microsoft Entra لتأمين الوصول إلى نقاط نهاية الإدارة. توفر مجموعة Service Fabric العديد من نقاط الإدخال إلى وظائف الإدارة الخاصة بها، بما في ذلك مستكشف Service Fabric المستند إلى الويب وVisual Studio. ونتيجة لذلك، للتحكم في الوصول إلى نظام المجموعة، يمكنك إنشاء تطبيقي Microsoft Entra: تطبيق ويب واحد وتطبيق أصلي واحد. لمعرفة كيفية إنشاء البيانات الاصطناعية المطلوبة من Microsoft Entra وكيفية ملؤها عند إنشاء نظام المجموعة، راجع إعداد معرف Microsoft Entra لمصادقة العملاء.

توصيات الأمان

بالنسبة لمجموعات "نسيج الخدمة" المنشورة في شبكة اتصال عامة مستضافة على Azure، تكون التوصية الخاصة بالمصادقة المتبادلة بين العميل والعقدة هي:

  • استخدام معرف Microsoft Entra لهوية العميل
  • شهادة لهوية الخادم وتشفير TLS لاتصال http

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

بالنسبة لمجموعات Windows Server المستقلة، إذا كان لديك Windows Server 2012 R2 وWindows Active Directory، نوصي باستخدام أمان Windows مع حسابات الخدمة المدارة للمجموعة. وإلا، استخدم الأمان Windows مع حسابات Windows.

التحكم في الوصول القائم على دور Service Fabric

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

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

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

X.509 الشهادات وService Fabric

تستخدم الشهادات الرقمية X.509 عادة لمصادقة العملاء والخوادم. كما أنها تستخدم لتشفير الرسائل وتوقيعها رقميا. تستخدم خدمة "Service Fabric" شهادات X.509 لتأمين مجموعة وتوفير ميزات أمان التطبيق. لمزيد من المعلومات حول الشهادات الرقمية X.509، راجع استخدام الشهادات. يمكنك استخدام Key Vault لإدارة الشهادات لمجموعات Service Fabric في Azure.

بعض الأمور الهامة التي يجب عليك التفكير فيها:

  • لإنشاء شهادات للمجموعات التي تقوم بتشغيل أحمال عمل الإنتاج، استخدم خدمة شهادات خادم Windows تم تكوينها بشكل صحيح، أو شهادة من مرجع مصدق معتمد (CA).
  • لا تستخدم أبدا أي شهادات مؤقتة أو اختبارية تقوم بإنشائها باستخدام أدوات مثل MakeCert.exe في بيئة إنتاج.
  • يمكنك استخدام شهادة موقعة ذاتيا، ولكن فقط في مجموعة اختبار. لا تستخدم شهادة موقعة ذاتيا في الإنتاج.
  • عند إنشاء بصمة إبهام على الشهادة، تأكد من إنشاء بصمة إبهام لوغاريتم التجزئة الآمن 1. SHA1 هو ما يتم استخدامه عند تكوين بصمات إبهام على شهادة العميل والمجموعة.

شهادة نظام المجموعة والخادم (مطلوبة)

هذه الشهادات (واحدة أساسية وثانوية اختياريا) مطلوبة لتأمين مجموعة ومنع الوصول غير المصرح به إليها. توفر هذه الشهادات مصادقة المجموعة والخادم.

تقوم مصادقة المجموعة بمصادقة اتصال العقدة إلى العقدة لاتحاد المجموعة. يمكن فقط للعقد التي يمكنها إثبات هويتها باستخدام هذه الشهادة الانضمام إلى المجموعة. تقوم مصادقة الخادم بمصادقة نقاط نهاية إدارة المجموعة إلى عميل إدارة، بحيث يعرف عميل الإدارة أنه يتحدث إلى المجموعة الحقيقية وليس "اختراق الدخيل". توفر هذه الشهادة أيضاً TLS لواجهة برمجة تطبيقات إدارة HTTPS وService Fabric Explorer عبر HTTPS. عندما يقوم عميل أو عقدة بمصادقة عقدة، فإن أحد عمليات التحقق الأولية هو قيمة الاسم الشائع في الحقل الموضوع. يجب أن يكون هذا الاسم الشائع أو أحد الأسماء البديلة للموضوع (SANs) الخاصة بالشهادات موجودا في قائمة الأسماء الشائعة المسموح بها.

يجب أن تلبي الشهادة المتطلبات التالية:

  • يجب أن تحتوي الشهادة على مفتاح خاص. تحتوي هذه الشهادات عادة على امتدادات .pfx أو .pem
  • يجب إنشاء الشهادة لتبادل المفاتيح، الذي يمكن تصديره إلى ملف المعلومات الشخصية Exchange (pfx.).
  • يجب أن يتطابق اسم موضوع الشهادة مع المجال الذي تستخدمه للوصول إلى نظام مجموعة Service Fabric. هذه المطابقة مطلوبة لتوفير TLS لنقطة نهاية إدارة HTTPS وS مستكشف Service Fabric في المجموعة. لا يمكنك الحصول على شهادة TLS/SSL من مرجع شهادات (CA) للمجال *.cloudapp.azure.com. يجب الحصول على اسم مجال مخصص لنظام المجموعة الخاصة بك. عند طلب شهادة من CA، يجب مطابقة اسم موضوع الشهادة مع اسم مجال نظام المجموعة الذي تستخدمه لنظام المجموعة الخاص بك.

بعض الأمور الأخرى التي يجب عليك التفكير فيها:

  • يمكن أن يحتوي حقل الموضوع على قيم متعددة. كل قيمة مسبوقة بتهيئة للإشارة إلى نوع القيمة. عادة ما تكون التهيئة هي CN ( للاسم الشائع)؛ على سبيل المثال، CN = www.contoso.com.
  • يمكن أن يكون حقل الموضوع فارغا.
  • إذا كان الحقل الاسم البديل للموضوع الاختياري مملوءا، فيجب أن يحتوي على كل من الاسم الشائع للشهادة وإدخال واحد لكل SAN. يتم إدخالها كقيم اسم DNS. لمعرفة كيفية إنشاء شهادات تحتوي على شبكات SAN، راجع كيفية إضافة اسم بديل للموضوع إلى شهادة LDAP آمنة.
  • يجب أن تتضمن قيمة حقل الأغراض المقصودة في الشهادة قيمة مناسبة، مثل مصادقة الخادم أو مصادقة العميل.

شهادات التطبيق (اختياري)

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

  • تشفير وفك تشفير قيم تكوين التطبيق.
  • تشفير البيانات عبر العقد أثناء النسخ المتماثل.

مفهوم إنشاء مجموعات آمنة هو نفسه، سواء كانت Linux أو Windows مجموعات.

شهادات مصادقة العميل (اختياري)

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

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

إشعار

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

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