تطبيق Service Fabric وأمان الخدمة
يمكن أن تجلب تصميم الخدمات المصغرة العديد من الفوائد. ومع ذلك، فإن إدارة أمن الخدمات المصغرة يمثل تحديا ومختلفا عن إدارة أمن التطبيقات المتجانسة التقليدية.
باستخدام وحدة متراصة، يعمل التطبيق عادة على خادم واحد أو أكثر داخل الشبكة ومن الأسهل تحديد المنافذ المكشوفة وواجهات برمجة التطبيقات وعنوان IP. غالبا ما يكون هناك محيط أو حد واحد وقاعدة بيانات واحدة لحمايتها. إذا تم اختراق هذا النظام بسبب خرق أمني أو هجوم، فمن المحتمل أن يكون كل شيء داخل النظام متاحا للمهاجم. مع الخدمات المصغرة، يكون النظام أكثر تعقيدا. الخدمات لامركزية وموزعة عبر العديد من المضيفين وتنتقل من مضيف إلى مضيف. من خلال الأمان المناسب، يمكنك الحد من الامتيازات التي يمكن للمهاجم الحصول عليها وكمية البيانات المتاحة في هجوم واحد عن طريق اختراق خدمة واحدة. الاتصال ليس داخليا، ولكنه يحدث عبر شبكة، وهناك العديد من المنافذ المكشوفة والتفاعلات بين الخدمات. إن معرفة ما هي تفاعلات الخدمة هذه ومتى تحدث أمر بالغ الأهمية لأمن التطبيق الخاص بك.
هذه المقالة ليست دليلا لأمن الخدمات المصغرة، فهناك العديد من هذه الموارد المتاحة عبر الإنترنت، ولكنها تصف كيف يمكن تحقيق جوانب مختلفة من الأمان في Service Fabric.
المصادقة والتخويل
غالبا ما يكون من الضروري أن تقتصر الموارد وواجهات برمجة التطبيقات التي تعرضها الخدمة على بعض المستخدمين أو العملاء الموثوق بهم. المصادقة هي عملية التحقق بشكل موثوق من هوية المستخدم. التفويض هو العملية التي تجعل واجهات برمجة التطبيقات أو الخدمات متاحة لبعض المستخدمين المصادق عليهم دون غيرهم.
المصادقة
الخطوة الأولى لاتخاذ قرارات الثقة على مستوى واجهة برمجة التطبيقات هي المصادقة. المصادقة هي عملية التحقق بشكل موثوق من هوية المستخدم. في سيناريوهات الخدمة المصغرة، عادة ما تتم معالجة المصادقة مركزيا. إذا كنت تستخدم بوابة واجهة برمجة التطبيقات، فيمكنك إلغاء تحميل المصادقة إلى البوابة. إذا كنت تستخدم هذا النهج، فتأكد من أنه لا يمكن الوصول إلى الخدمات الفردية مباشرة (بدون بوابة واجهة برمجة التطبيقات) ما لم يكن هناك أمان إضافي لمصادقة الرسائل سواء كانت قادمة من البوابة أم لا.
إذا كان يمكن الوصول إلى الخدمات مباشرة، يمكن استخدام خدمة مصادقة مثل معرف Microsoft Entra أو خدمة مصادقة مصغرة مخصصة تعمل كخدمة رمز أمان (STS) لمصادقة المستخدمين. تتم مشاركة قرارات الثقة بين الخدمات التي تحتوي على رموز أمان أو ملفات تعريف ارتباط.
بالنسبة ASP.NET Core، فإن الآلية الأساسية لـ مصادقة المستخدمين هي نظام عضوية ASP.NET Core Identity. ASP.NET Core Identity بتخزين معلومات المستخدم (بما في ذلك معلومات تسجيل الدخول والأدوار والمطالبات) في مخزن بيانات تم تكوينه بواسطة المطور. تدعم ASP.NET Core Identity المصادقة الثنائية. يتم أيضا دعم موفري المصادقة الخارجيين، بحيث يمكن للمستخدمين تسجيل الدخول باستخدام عمليات المصادقة الحالية من موفرين مثل Microsoft أو Google أو Facebook أو X.
التصريح
بعد المصادقة، تحتاج الخدمات إلى تفويض وصول المستخدم أو تحديد ما يمكن للمستخدم القيام به. تسمح هذه العملية للخدمة بإتاحة واجهات برمجة التطبيقات لبعض المستخدمين المصادق عليهم، ولكن ليس للجميع. التفويض متعامد ومستقل عن المصادقة، وهي عملية التحقق من هوية المستخدم. قد تؤدي المصادقة إلى إنشاء هوية واحدة أو أكثر للمستخدم الحالي.
يمكن إجراء التفويض الأساسي ASP.NET استنادا إلى أدوار المستخدمين أو استنادا إلى السياسة المخصصة، والتي قد تتضمن فحص المطالبات أو الاستدلالات الأخرى.
تقييد الوصول وتأمينه باستخدام بوابة واجهة برمجة التطبيقات
تحتاج التطبيقات السحابية عادة إلى بوابة أمامية لتوفير نقطة دخول واحدة للمستخدمين أو الأجهزة أو التطبيقات الأخرى. تقع بوابة واجهة برمجة التطبيقات بين العملاء والخدمات وهي نقطة الدخول إلى جميع الخدمات التي يقدمها تطبيقك. وهو بمثابة وكيل عكسي، يوجّه الطلبات من العملاء إلى الخدمات. وقد ينفذ أيضا مهاما تتقاطع مع أجزاء مختلفة مثل المصادقة والتفويض وإنهاء TLS والحد من المعدلات. إذا لم تقم بتوزيع بوابة، يجب على العملاء إرسال الطلبات مباشرةً إلى الخدمات الأمامية.
في Service Fabric، يمكن أن تكون البوابة أي خدمة عديمة الجنسية مثل تطبيق ASP.NET Core أو خدمة أخرى مصممة لدخول حركة المرور، مثل Traefik أو Event Hubs أو IoT Hub أو Azure API Management.
تتكامل إدارة واجهة برمجة التطبيقات مباشرة مع Service Fabric، مما يسمح لك بنشر واجهات برمجة التطبيقات مع مجموعة غنية من قواعد التوجيه إلى خدمات Service Fabric الخلفية. يمكنك تأمين الوصول إلى خدمات الواجهة الخلفية أو منع هجمات DOS باستخدام الاختناق أو التحقق من مفاتيح واجهة برمجة التطبيقات ورموز JWT المميزة والشهادات وبيانات الاعتماد الأخرى. لمعرفة المزيد، اقرأ Service Fabric مع نظرة عامة على إدارة واجهة برمجة تطبيقات Azure.
إدارة أسرار التطبيقات
يمكن أن تكون البيانات السرية أي معلومات حساسة، مثل سلاسل اتصال التخزين أو كلمات المرور أو القيم الأخرى التي لا يجب معالجتها في نص عادي. تستخدم هذه المقالة Azure Key Vault لإدارة المفاتيح والأسرار. ومع ذلك، فإن استخدام الأسرار في تطبيق ما هو نظام أساسي سحابي غير مدرك للسماح بنشر التطبيقات على مجموعة مستضافة في أي مكان.
الطريقة الموصى بها لإدارة إعدادات تكوين الخدمة هي من خلال حزم تكوين الخدمة. يتم إصدار حزم التكوين وتحديثها من خلال الترقيات المتداولة المدارة مع التحقق من الصحة والتراجع التلقائي. يفضل هذا على التكوين العالمي لأنه يقلل من فرص انقطاع الخدمة العالمية. الأسرار المشفرة ليست استثناء. يحتوي Service Fabric على ميزات مضمنة لتشفير القيم وفك تشفيرها في حزمة تكوين Settings.xml ملف باستخدام تشفير الشهادة.
يوضح الرسم التخطيطي التالي التدفق الأساسي للإدارة السرية في تطبيق Service Fabric:
هناك أربع خطوات رئيسية في هذا التدفق:
- الحصول على شهادة تشفير البيانات.
- ثبِّت الشهادة في مجموعتك.
- تشفير القيم السرية عند نشر تطبيق مع الشهادة وحقنها في ملف تكوين Settings.xml للخدمة.
- اقرأ القيم المشفرة خارج Settings.xml عن طريق فك التشفير باستخدام شهادة التشفير نفسها.
يتم استخدام Azure Key Vault هنا كموقع تخزين آمن للشهادات وكطريقة للحصول على الشهادات المثبتة على مجموعات Service Fabric في Azure. إذا كنت لا تقوم بالنشر في Azure، فلن تحتاج إلى استخدامKey Vault لإدارة الأسرارفي تطبيقات Service Fabric.
على سبيل المثال، راجع إدارة أسرار التطبيقات.
تأمين بيئة الاستضافة
باستخدام Azure Service Fabric، يمكنك تأمين التطبيقات التي يتم تشغيلها في نظام المجموعة ضمن حسابات المستخدمين المختلفة. يساعد Service Fabric أيضا على تأمين الموارد التي تستخدمها التطبيقات في وقت النشر ضمن حسابات المستخدمين - على سبيل المثال، الملفات والدلائل والشهادات. هذا يجعل التطبيقات الموجودة قيد التشغيل، حتى في بيئة مستضافة مشتركة، أكثر أماناً من بعضها البعض.
يعلن بيان التطبيق عن مبادئ الأمان (المستخدمون والمجموعات) المطلوبة لتشغيل الخدمة (الخدمات) والموارد الآمنة. تتم الإشارة إلى مبادئ الأمان هذه في النهج، على سبيل المثال سياسات التشغيل باسم، أو ربط نقطة النهاية، أو مشاركة الحزمة، أو الوصول إلى الأمان. ثم يتم تطبيق النهج على موارد الخدمة في قسم ServiceManifestImport من بيان التطبيق.
عند الإعلان عن المبادئ الأساسية، يمكنك أيضا تحديد مجموعات المستخدمين وإنشائها بحيث يمكن إضافة مستخدم واحد أو أكثر إلى كل مجموعة لإدارتها معا. يكون هذا مفيدا عندما يكون هناك مستخدمون متعددون لنقاط دخول خدمة مختلفة ويحتاجون إلى الحصول على امتيازات مشتركة معينة متوفرة على مستوى المجموعة.
بشكل افتراضي، يتم تشغيل تطبيقات Service Fabric ضمن الحساب الذي يتم تشغيل عملية Fabric.exe تحته. يوفر Service Fabric أيضا القدرة على تشغيل التطبيقات ضمن حساب مستخدم محلي أو حساب نظام محلي، والذي يتم تحديده في بيان التطبيق. لمزيد من المعلومات، راجع تشغيل خدمة كحساب مستخدم محلي أو حساب نظام محلي. يمكنك أيضًا تشغيل برنامج نصي لبدء تشغيل خدمة كمستخدم محلي أو حساب نظام.
عند تشغيل Service Fabric على نظام مجموعة مستقلة Windows، يمكنك تشغيل خدمة ضمن حسابات مجال Active Directory أو حسابات الخدمة المدارة للمجموعة.
الحاويات الآمنة
يوفر تصميم الخدمة آلية للخدمات داخل حاوية للوصول إلى شهادة مثبتة على العُقَد في نظام مجموعة Windows أو Linux (الإصدار 5.7 أو ما بعده). يمكن استخدام شهادة PFX هذه لمصادقة التطبيق أو الخدمة أو الاتصال الآمن مع الخدمات الأخرى. لمزيد من المعلومات، راجع استيراد شهادة إلى حاوية.
بالإضافة إلى ذلك، يدعم Service Fabric أيضا gMSA (حسابات الخدمة المدارة للمجموعة) لحاويات Windows. لمزيد من المعلومات، راجع إعداد gMSA لحاويات Windows.
الاتصال الآمن بالخدمة
في Service Fabric، يتم تشغيل خدمة في مكان ما في مجموعة Service Fabric، وعادة ما يتم توزيعها عبر أجهزة ظاهرية متعددة. يوفر Service Fabric العديد من الخيارات لتأمين اتصالات الخدمة الخاصة بك.
يمكنك تمكين نقاط نهاية HTTPS في خدمات الويب ASP.NET Core أو Java.
يمكنك إنشاء اتصال آمن بين الوكيل العكسي والخدمات، وبالتالي تمكين قناة آمنة من طرف إلى طرف. يتم دعم الاتصال بالخدمات الآمنة فقط عند تكوين الوكيل العكسي للاستماع على HTTPS. للحصول على معلومات حول تكوين الوكيل العكسي، اقرأ الوكيل العكسي في Azure Service Fabric. يصف الاتصال إلى خدمة آمنة كيفية إنشاء اتصال آمن بين الوكيل العكسي والخدمات.
يوفر إطار عمل تطبيق الخدمات الموثوقة عدداً قليلاً من مكدسات وأدوات الاتصال المنشأة مسبقاً والتي يمكنك استخدامها لتحسين الأمان. تعرف على كيفية تحسين الأمان عند استخدام خدمة الاتصال عن بعد (في C# أو Java) أو باستخدام WCF.
تضمين شهادة نقطة النهاية في تطبيقات Service Fabric
لتكوين شهادة نقطة نهاية التطبيق، قم بتضمين الشهادة عن طريق إضافة عنصر EndpointCertificate جنبا إلى جنب مع عنصر المستخدم للحساب الأساسي إلى بيان التطبيق. الحساب الأساسي هو NetworkService بشكل افتراضي. سيوفر هذا إدارة المفتاح الخاص لشهادة التطبيق ACL للمدير المقدم.
<ApplicationManifest … >
...
<Principals>
<Users>
<User Name="Service1" AccountType="NetworkService" />
</Users>
</Principals>
<Certificates>
<EndpointCertificate Name="MyCert" X509FindType="FindByThumbprint" X509FindValue="[YourCertThumbprint]"/>
</Certificates>
</ApplicationManifest>
تشفير البيانات الثابتة للتطبيق
يتم دعم كل نوع عقدة في مجموعة Service Fabric الذي يتم تشغيله في Azure بواسطة مجموعة مقياس جهاز ظاهري. باستخدام قالب Azure Resource Manager، يمكنك إرفاق أقراص البيانات بمجموعة (مجموعات) المقاييس التي تشكل مجموعة Service Fabric. إذا كانت خدماتك تحفظ البيانات على قرص بيانات مرفق، فيمكنك تشفير أقراص البيانات هذه لحماية بيانات التطبيق.