الملخص: يقدم هذا المقال بشكل رئيسي أنواع نماذج الأمان لتطبيقات ASP.NET WEB، ويقارن مزاياها وعيوبها، ويقترح آلية الاختيار.
الكلمات الرئيسية: نموذج الأمان محاكاة النموذج الفرعي الموثوق به / نموذج التفويض الفرعي ASP.NET WEB
1. مقدمة
تنتمي تطبيقات ASP.NET WEB عادةً إلى بنية متعددة الطبقات، وبشكل عام، يمكن تقسيم البنية المنطقية إلى طبقة العرض التقديمي وطبقة منطق الأعمال وطبقة الوصول إلى البيانات، للوصول إلى موارد التطبيق، يجب أن تمتد مصادقة هوية العميل والترخيص إلى طبقات متعددة. مستوى. تتناول هذه المقالة بشكل أساسي نموذج أمان الوصول إلى الموارد لتطبيقات SP.NET
2. تعريف الوصول إلى الموارد
تتضمن الموارد النموذجية التي توفرها تطبيقات الويب للعملاء خارجيًا ما يلي:
موارد خادم الويب، مثل صفحات الويب وخدمات الويب والموارد الثابتة (صفحات وصور HTML).
موارد قاعدة البيانات، مثل البيانات لكل مستخدم أو البيانات على مستوى التطبيق.
موارد الشبكة، مثل موارد نظام الملفات البعيدة، وما إلى ذلك.
موارد النظام، مثل السجل وسجلات الأحداث وملفات التكوين وما إلى ذلك.
يصل العملاء إلى هذه الموارد عبر طبقات التطبيق، مع تدفق الهوية عبر كل طبقة. تتكون هذه الهوية المستخدمة للوصول إلى الموارد من:
هوية المتصل الأصلي يتم الحصول على هوية المتصل الأصلي ثم تتدفق عبر كل طبقة من طبقات النظام.
معرف العملية يتم إجراء الوصول إلى الموارد المحلية والمكالمات النهائية باستخدام معرف العملية الحالي. وتعتمد جدوى هذا النهج على الحدود التي سيتم تجاوزها، حيث يجب التعرف على هوية العملية من قبل النظام المستهدف. ويجب استدعاء ذلك بإحدى طريقتين:
عبور مجالات أمان Windows ضمن مجال أمان Windows نفسه - استخدم حسابات الثقة والمجال، أو استخدم أسماء مستخدمين وكلمات مرور مكررة حيث لا توجد علاقة ثقة.
حساب الخدمة يستخدم هذا الأسلوب حساب خدمة (ثابت). على سبيل المثال، للوصول إلى قاعدة البيانات، قد يتم تمثيل حساب الخدمة بواسطة اسم مستخدم وكلمة مرور SQL ثابتين بواسطة مكون متصل بقاعدة البيانات.
عندما تكون هوية Windows الثابتة مطلوبة، يجب استخدام تطبيق خادم Enterprise Services.
الهوية المخصصة في حالة عدم توفر حساب Windows، يمكنك استخدام Iprincipal وIidentity لإنشاء هويتك الخاصة، والتي يمكن أن تتضمن تفاصيل حول سياق الأمان.
3. نموذج الوصول إلى الموارد
3.1 نموذج النظام الفرعي الموثوق به
كما هو موضح في الشكل 1، في هذا النموذج، لا يتدفق سياق الأمان للمتصل الأصلي عبر الخدمة على مستوى نظام التشغيل، ولكن يتم استخدام هوية ثابتة في طبقة الخدمة الوسيطة للوصول إلى الخدمات والموارد النهائية. يحصل نموذج النظام الفرعي الموثوق على اسمه من حقيقة أن الخدمة النهائية (ربما قاعدة بيانات) تثق في الخدمة الأولية لتخويل المتصلين بها. في المثال الموضح في الشكل 1، تثق قاعدة البيانات بتفويض المتصل من خلال الطبقة الوسطى، وتسمح فقط للمتصلين المعتمدين بالوصول إلى قاعدة البيانات باستخدام الهويات الموثوقة.
3.1.1 وضع الوصول إلى الموارد
في نموذج النظام الفرعي الموثوق به، يكون نموذج الوصول إلى الموارد كما يلي:
مصادقة المستخدمين تعيين المستخدمين إلى الأدوار التفويض بناءً على عضوية الدور استخدام هوية موثوقة ثابتة للوصول إلى الموارد النهائية
3.1.2 التعريف الثابت
هوية ثابتة تستخدم للوصول إلى الأنظمة النهائية ومديري الموارد، والتي يمكن توفيرها باستخدام هوية العملية أو حساب خدمة حساب Windows المعين مسبقًا. بالنسبة لـ SQL Server Explorer، فهذا يعني مصادقة Windows لـ SQL Server.
عند استخدام هوية العملية، عادةً ما تستخدم هوية عملية ASP.NET (الحساب الافتراضي هو حساب ASPNET). في التطبيقات العملية، غالبًا ما يكون من الضروري تغيير حساب ASPNET إلى كلمة مرور أكثر أمانًا وإنشاء حساب Windows على كمبيوتر SQL Server الذي يطابق حساب عملية ASP.NET. الطريقة المحددة هي كما يلي:
قم بتحرير ملف Machine.config الموجود في الدليل %windr%Microsoft.NETFrameworkv1.1.4322CONFIG وأعد تكوين سمة كلمة المرور على عنصر <processModel> إلى قيمته الافتراضية <!-UserName="machine" كلمة المرور = "AutoGenerate" --> قم بالتغيير إلى <!-UserName="machine"password="NewPassword" -->; أو استخدم أداة ASPNET_setreg.exe لحفظ اسم المستخدم وكلمة المرور في السجل، وقم بتغيير التكوين إلى: < !- تمكين = "true" UserName = "Registry:HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,userName" كلمة المرور = "التسجيل: HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,كلمة المرور " -->
تستخدم التطبيقات الأخرى حساب SQL معينًا (يتم تحديده بواسطة اسم المستخدم وكلمة المرور في سلسلة الاتصال) للوصول إلى SQL Server. في هذه الحالة، يجب تكوين قاعدة البيانات لمصادقة SQL. يجب حماية سلسلة الاتصال المحفوظة في ملف التكوين عن طريق التشفير.
3.2 نموذج المحاكاة/التفويض
كما هو موضح في الشكل 2، عند استخدام نموذج الانتحال/الحذف، تستخدم الخدمة أو المكون (الموجود عادةً في طبقة خدمات الأعمال المنطقية) إمكانات انتحال هوية نظام التشغيل لانتحال هوية العميل قبل الوصول إلى الخدمة التالية. إذا كانت الخدمة على نفس الجهاز، فإن استخدام الانتحال يكفي، وإذا كانت الخدمة المتلقين للمعلومات على جهاز بعيد، فأنت بحاجة أيضًا إلى استخدام التفويض، وسياق الأمان للوصول إلى الموارد المتلقين للمعلومات هو سياق العميل.
3.3 حدد نموذج الوصول إلى الموارد
تظهر المقارنة بين نموذجي الوصول إلى الموارد في الجدول 1.
تثق الواجهة الخلفية لمحاكاة نموذج النظام الفرعي الموثوق به/وظيفة تدقيق النموذج المفوض في خدمات الطبقة العليا. إذا تم اختراق الطبقة الوسطى، فستكون موارد الواجهة الخلفية عرضة للهجوم. يمكن للخدمة الخلفية مصادقة كل متصل وتفويضه بأمان جيد.
تدعم قابلية التوسع تجميع الاتصالات وتتميز بقابلية التوسع الجيدة. لا يدعم تجميع الاتصالات وقابلية التوسع ضعيفة.
يتم تكوين قائمة التحكم بالوصول (ACL) الخاصة بإدارة قائمة التحكم بالوصول (ACL) لكيان واحد، مما يتطلب عملاً إداريًا أقل. يجب منح كل مستخدم مستوى الوصول المقابل. عندما يزيد عدد الموارد الخلفية والمستخدمين، يصبح عمل الإدارة مرهقًا.
لا حاجة لتفويض المسائل الفنية. التفويض مطلوب. لا يدعم معظم موفري خدمات الأمان التفويض.
يتم استخدام نموذج النظام الفرعي الموثوق به في معظم تطبيقات الإنترنت بالإضافة إلى تطبيقات الإنترانت الكبيرة، ويرجع ذلك أساسًا إلى أن هذا النموذج يمكنه دعم قابلية التوسع بشكل جيد. يميل نموذج المحاكاة/التفويض إلى الاستخدام في الأنظمة الأصغر. بالنسبة لهذه التطبيقات، لا تعتبر قابلية التوسع هي الاعتبار الأساسي؛