أمان SQL Server لقاعدة بيانات ASP.NET2.0

الكاتب：Eve Cole وقت التحديث：2009-06-30 16:43:56

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

· تستخدم مصادقة Windows (المعروفة أيضًا باسم المصادقة الموثوقة أو الأمان المتكامل) هوية مستخدم Windows الذي يقدم طلب الاتصال لإجراء الترخيص لقاعدة البيانات. في هذه الحالة، ليس من الضروري أن توفر سلسلة الاتصال اسم مستخدم وكلمة مرور صريحين. يعمل ASP.NET كمستخدم محلي يسمى "ASPNET" (أو "خدمة الشبكة" في IIS 6.0)، لذلك عند استخدام مصادقة Windows، سيتحقق SQL مما إذا كان هذا المستخدم لديه إذن لاستخدام قاعدة البيانات. عند هذه النقطة، يتم تشغيل كافة تطبيقات ASP.NET مع نفس المستخدم، لذا فإن الوضع الآمن يعاملهم على قدم المساواة. على الرغم من أنه من الممكن تشغيل كل تطبيق في عملية ASP.NET منفصلة (مستخدم منفصل يقوم بتشغيل كل تطبيق)، أو انتحال هوية مستخدم Windows لعميل المتصفح الذي يقدم طلب الاتصال، إلا أن ذلك يقع خارج نطاق هذا الكتاب . ومع ذلك، يعد انتحال شخصية العميل هو الاستخدام الأكثر شيوعًا لمصادقة Windows في تطبيقات الويب.

· تقوم مصادقة SQL بالتحقق من أسماء المستخدمين وكلمات المرور المقدمة بشكل صريح ومقارنتها بالمستخدمين الذين تم تكوينهم داخل SQL Server (دون إشراك نظام التشغيل). في هذه الحالة، يمكن لكل تطبيق يعمل في عملية ASP.NET الاتصال بقاعدة البيانات بشهادة منفصلة، وبالتالي عزل التطبيقات بشكل معقول (لن يتمكن التطبيق أ من الاتصال بقاعدة البيانات إذا لم يكن لديه اسم المستخدم وكلمة المرور الخاصين بـ ب) لا يمكن الاتصال بقاعدة بيانات B). هذا هو وضع المصادقة الأكثر شيوعًا المستخدم لتطبيقات الويب المنشورة، خاصة في حالة الاستضافة المشتركة. العيب الصغير هو أنه يتطلب من التطبيق الاحتفاظ بكلمة المرور الخاصة بحساب المستخدم المستخدم للاتصال، وإذا تم الحصول على كلمة المرور هذه بواسطة مستخدم ضار، فسيتم اختراق أمان قاعدة البيانات. ومع ذلك، كما سترون لاحقًا في هذا الكتاب، يوفر ASP.NET طريقة آمنة لتخزين كلمة مرور مصادقة SQL بتنسيق مشفر في ملف Web.config، مما يقلل من خطر الحصول على كلمة المرور.

· الوضع المختلط هو تكوين SQL Server الذي يسمح بمصادقة Windows ومصادقة SQL.

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

إذا قمت بتثبيت SQL Server أو SSE، فيمكنك عرض وضع المصادقة المحدد عن طريق فتح RegEdit (بالطبع تحتاج إلى عمل نسخة احتياطية منه أولاً)، والعثور على HKey_Local_Machine/Software/Microsoft/Microsoft SQL Server وابحث عن LoginMode. يمثل مفتاح التسجيل الفرعي بقيمة 1 مصادقة Windows، بينما تمثل القيمة 2 وضع المصادقة المختلطة.

ويلخص الجدول 3-1 الاختلافات بين هذه الأوضاع.

الجدول 3-1

. التثبيت = =اسم المستخدم؛ يتمتع الأمان الأفضل؛

	مصادقة Windows،	مصادقة SQL،
اسم قابل للاستبدال،	مصادقة موثوقة الأمن المتكامل	لا، لكن مصادقة الوضع المختلط تسمح باستخدام
بيئة Windows أو SQL النموذجية	موقع	قائمة
مستخدمي	الإنترنت	وعمليات المصادقة.
يتطلب	التثبيت الافتراضي	تحديد
سلسلة اتصال	Trusted_connection=true أو Integrated Security	المستخدم	الحقيقي	كلمة المرور = كلمة المرور.
مستخدمو تطبيق الويب ASP.NET	بعملية ASP.NET أو ASPNET (IIS 5.x) أو خدمة الشبكة (IIS 6	)
بميزة	ويمكنهم	التحكم في أحداث SQL الخاصة بالمستخدم وتتبع نشاط Windows	يمكن نشرها على الجهاز المضيف دون إنشاء حساب جديد بشكل مستقل عن نظام التشغيل يتطلب موقع الإنترانت المستضاف مهارات متوسطة فقط يوفر طريقة أكثر مرونة للتطبيقات للاتصال بكل قاعدة بيانات بشهادات مختلفة
العيوب	إن منح شهادة Windows لتطبيق ويب لديه القدرة على تعيين نطاق الأذونات في نظام التشغيل بشكل كبير جدًا،	ويتم تخزين كلمات المرور في تطبيق الويب (وهو ليس الحل) الحالة في مصادقة Windows ). تأكد من حفظ كلمة المرور في ملف Web.config ومن تشفيرها. يسمح بعمليات منخفضة المستوى لتطبيقات الويب باستخدام شهادات SA. قم دائمًا بإنشاء شهادات جديدة لتطبيقات الويب ASP.NET ومنح الأذونات المطلوبة فقط

الآن بعد أن عرفنا الطريقة الآمنة لاستخدام SQL، فلنفكر في كيفية استيفاء مستهلك البيانات (عنصر تحكم مصدر البيانات) للمتطلبات. أولاً، استخدم البيانات التي تم الحصول عليها من VWD وVWD Web Server (Cassini)، بشكل أساسي أثناء التصميم والاختبار. ثانياً، يجب الوصول إلى البيانات من IIS بعد النشر. لدى مستهلكي البيانات أسماء مستخدمين مختلفة. يستخدم VWD وVWD Web Server اسم الشخص الذي قام بتسجيل الدخول إلى Windows، بينما يستخدم برنامج IIS اسم ASPNET.

إذا كان SQL Server يستخدم مصادقة Windows، فإن عنصر التحكم SqlDataSource يحتاج إلى تضمين التعليمة البرمجية التالية في سلسلة الاتصال: Integrated Security=true (أو Trusted_connection=true). ستقوم هذه المعلمة بإرشاد SQL Server لمصادقة طلبات البيانات بناءً على حساب تسجيل دخول Windows الخاص بالطالب. إذا قمت بتسجيل الدخول باعتبارك المستخدم الذي قام بتثبيت SSE، فستمنح شهادته حق الوصول إلى SSE. كل شيء سوف يسير بسلاسة باستخدام VWD وVWD Web Server، لأن مستخدمي VW Web Server يعتبرون مبرمجين قاموا بتسجيل الدخول إلى Windows وبالتالي لديهم حسابات على SSE. ومع ذلك، حتى إذا كان التطبيق يعمل بشكل جيد خارج VWD، فلن يعمل بشكل صحيح عند ترحيل الموقع إلى IIS. يتم تشغيل IIS ضمن حساب مستخدم يسمى ASPNET (أو خدمة الشبكة في IIS6/Windows 2003 Server). ولذلك، يجب على مسؤول الجهاز الذي يقوم بتشغيل IIS إضافة مستخدم ASP.NET ومنح الأذونات الخاصة به. تقع هذه العملية خارج نطاق هذا الكتاب، ولكنها موصوفة بالتفصيل في العديد من أدلة مسؤول IIS. باختصار، إذا كان SQL Server يستخدم مصادقة Windows، فيمكنك استخدام VWD وVWD Web Server لإجراء التمارين الواردة في هذا الكتاب. يمكن تشغيل صفحتك على IIS فقط بعد منح الإذن لحساب عملية ASP.NET الذي يصل إلى قاعدة البيانات.

إذا كان SQL Server يستخدم مصادقة SQL، فسيقوم SQL بإجراء عملية المصادقة الخاصة به. لن تعتمد هذه العملية على قائمة مستخدمي Windows. تحتوي سلسلة الاتصال على معلمتين: المستخدم = اسم المستخدم، كلمة المرور = كلمة المرور. يمكن الآن استخدام الصفحة من VWD أو VWD Web Server أو IIS، حيث ليست هناك حاجة لإنشاء حساب مستخدم في Windows. ومع ذلك، نحتاج أيضًا إلى استخدام حساب في SQL Server. الحساب الافتراضي الوحيد هو sa. قبل النشر، يجب إنشاء حساب آخر في SQL Server لديه الإذن فقط بتنفيذ صفحات ASPX. يؤدي الفشل في إنشاء حساب بديل غير sa (وكلمة المرور لحماية sa) إلى ترك الموقع مفتوحًا لواحدة من أكثر الثغرات الأمنية شهرةً وسهولة استغلالها. يعرف أي متسلل أنه يقوم بتسجيل الدخول باستخدام userID='sa' بكلمة مرور فارغة.

بالنسبة لكلا وضعي المصادقة، عند استخدام سلسلة الاتصال الموضحة مسبقًا، سيقوم المستخدم بتسجيل الدخول إلى SQL Server باستخدام الحساب الأولي. هذا الحساب هو sa، وهو ما يعني مسؤول النظام، كما يتبين من الاسم، لديه كافة الأذونات على كافة الكائنات. في الإصدار الحالي من SQL Server، لا يمكن تثبيت الخدمة باستخدام sa بكلمة مرور NULL. في SSE، يجب تثبيته باستخدام المعلمة SAPWD="MyStrongPassword". كلمة المرور القوية هنا تعني على الأقل ليست فارغة. من الأفضل استخدام سبعة أحرف على الأقل والتأكد من استخدام مزيج من الحروف والأرقام والرموز. في معظم الحالات، خارج تمارين الطلاب، يجب تعيين حساب لكل قاعدة بيانات وتطبيق. يجب تجنب منح إذن تطبيق واحد للوصول إلى البيانات من التطبيقات الأخرى.