it-swarm.asia

لماذا يعتبر السماح للجميع باستخدام تسجيل الدخول sa إجراءً سيئًا؟

حتى Microsoft لا يشجع على استخدام وضع مصادقة خادم SQL ، لكن تطبيقاتنا تتطلب ذلك.

لقد قرأت أنه من أفضل الممارسات عدم السماح للمستخدمين باستخدام تسجيل الدخول sa مباشرة ، بدلاً من ذلك باستخدام مصادقة Windows والسماح لتلك الحسابات (أو مجموعات الحسابات) بامتيازات مسؤول النظام.

  • أليس هذا هو نفس الشيء في الأساس؟ ما هي مزايا/عيوب؟
  • كيف تعمل أفضل الممارسات على زيادة أمان مثيلات SQL Server الخاصة بي؟
  • هل ينطبق هذا فقط على حالات الإنتاج ، أو على حالات التطوير الداخلي لدينا أيضًا؟
25
Jon Seigel

لديك العديد من الأسئلة المختلفة هنا ، لذلك سأطرقها بشكل فردي:

"لقد قرأت أنه من أفضل الممارسات عدم السماح للمستخدمين باستخدام تسجيل الدخول sa مباشرة ، بدلاً من استخدام مصادقة Windows"

أنت تخلط شيئين هنا: مفهوم SA ، ومفهوم مصادقة SQL ومصادقة Windows.

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

إذا اخترت استخدام مصادقة SQL ، فإن SA مجرد تسجيل دخول لمصادقة SQL. إنه اسم المستخدم الافتراضي للمسؤول ، تمامًا مثل المسؤول في مصادقة Windows. لديه قوى خارقة محلية في ذلك المثيل ، ولكن لا القوى العظمى العالمية في جميع الحالات.

"... والسماح لتلك الحسابات (أو مجموعات الحسابات) بامتيازات مسؤول النظام."

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

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

"كيف تزيد أفضل الممارسات من أمان مثيلات SQL Server الخاصة بي؟"

تريد أن تفعل شيئين:

  1. منع الناس من كسر الخادم
  2. عندما يكسر الخادم ، يكون قادرًا على تحديد من فعل ذلك بالضبط

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

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

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

"هل ينطبق هذا فقط على مثيلات الإنتاج ، أم على مثيلات التطوير الداخلي لدينا أيضًا؟"

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

52
Brent Ozar

في الواقع إذا قرأت هذا المستند التقني: SQL Server فصل الواجبات

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

أقوم بتعطيل حساب "sa" وإعادة تسميته ، تمامًا كما تفعل مع حساب المسؤول المضمن في نظام التشغيل. فقط لاستخدامها في حالات الطوارئ.

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

15
user507

إذا كنت تخضع لضوابط أو معايير تنظيمية خارجية (SOX ، PCI إلخ) ، فأنت

  • ستفشل المراجعة
  • تفشل في فحص PCI الشهري

يجب أن يكون لدى المطورين db_owner على شبكة SQL Server فقط للتطوير.

إذا كانت خوادم SQL الخاصة بك كلها على الشبكة ذات بنية قياسية (أي حساب الخدمة نفسه) ، فإن sa في واحد يمنح الحقوق عليها جميعًا.

إذا كان حساب الخدمة هو المسؤول المحلي ، فسيكون للمطورين التحكم الكامل في الخوادم أيضًا.

لا توجد محاسن.

8
gbn

sa = مسؤول النظام

تسجيل الدخول باستخدام sa يمنح المستخدم القدرة على القيام بكل ما يلي: - إسقاط وإنشاء قواعد البيانات - تعديل الكائنات في قاعدة البيانات - إسقاط وإنشاء تسجيلات الدخول - تغيير كلمات المرور - حذف جميع البيانات

إن منح امتيازات مسؤول النظام لحساب Windows يحقق نفس الشيء.

تستمر القائمة ، ولكن يجب أن يمنحك هذا بعض الأسباب الوجيهة لعدم السماح مطلقًا لغير المسؤول باستخدام sa.

يجب عليك إنشاء حساب windows أو SQL مع الحد الأدنى من الامتيازات اللازمة لتشغيل التطبيقات. (أي تسجيل الدخول والوصول إلى الإجراءات والآراء المخزنة)

6
datagod

أفضل ممارسة هي وضع بعض كلمات المرور القوية ونسيانها.

5
garik

لدي خياران في ذهني الآن ، لماذا لا ينبغي للمرء أن يكون لديه حساب ضعيف SA. إذا كان لديك كلمة مرور ضعيفة/فارغة لـ SA = شخص شرير (يترجم ذلك إلى "زميل ودود") يمكنه:

  • قم بتمكين إجراء نظام xp_cmdshell ، وباستخدام امتيازات حساب خدمة SQL Server ، قم بإلحاق الضرر بصندوقك المحلي (إنشاء/إزالة الملفات ..). انخفاض مستوى الأمان لـ SA لا يقول الكثير عن إعدادات المثيل ، ولكنه قد يعني ضمنيًا أن مستخدم الخدمة يمكن أن يتبع ممارسات سيئة (مثل كونه مسؤولًا :-)) ؛

  • تمكين البريد على المثيل الخاص بك والتقديم السريع لبرنامج نصي صغير ممتع للرسائل غير المرغوب فيها (من المحتمل أن يسبب لك بعض المشاكل إما مع مزود الإنترنت أو مع زملائك .. اعتمادًا على المكان الذي تذهب إليه الرسائل ؛-)) ؛

لن أشير إلى الحقائق الواضحة التي يمكن أن تسقط قواعد البيانات وتسجيلات الدخول ... إلخ.

  • أليس هذا في الأساس نفس الشيء؟ ما هي المزايا/العيوب؟
  • ليس بالضرورة: على سبيل المثال - في مثيل SQL Server من الكمبيوتر المحمول ، فإن الفرق بين مصادقة Windows ومصادقة SQL يعني أنه ، نظريًا ، يمكن للمهاجم الخارجي استخدام حساب SQL فقط ، لأنه لا يمكن استخدام مصادقة Windows خارج نطاقك الخاص الحساب. يمكن للمستخدم مسح أجهزة الكمبيوتر المحمولة المجاورة من المركز التجاري حيث تشرب قهوتك وقد يرى أن لديك نسخة SQL مثبتة وقد بدأت ويمكن أن تحاول الحصول على بعض المتعة مجانًا. ليس الأمر أنه يمكن أن يحدث في كثير من الأحيان ... ولكنه احتمال :-).

  • كيف تزيد أفضل الممارسات من أمان مثيلات SQL Server الخاصة بي؟

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

  • هل ينطبق هذا فقط على مثيلات الإنتاج ، أم على مثيلات التطوير الداخلي لدينا أيضًا؟

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

في معالجة سؤالك الأخير ، نستخدم SA الحسابات في جميع قواعد بيانات التطوير لدينا (مع كلمة المرور "sa" ، في ذلك!)

ومع ذلك ، من المهم ملاحظة أننا لا نخزن البيانات ولا ننشئها. يتم استخدام قواعد البيانات الخاصة بنا فقط لمخزن البيانات لتطبيق C/C++. قواعد بيانات التطوير هذه تحتوي فقط على بيانات الاختبار ويتم إنشاؤها وإسقاطها وتعديلها ، إلخ.

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

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

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

0
Richard

يجب تعديل أي معلمة أمان نظام SQL Server افتراضي. يوصى بعدم استخدام الوضع المختلط (يمكّن مصادقة Windows و SQL Server) للمصادقة. بدلاً من ذلك ، قم بالتبديل إلى مصادقة Windows فقط - التي ستفرض سياسة كلمة مرور Windows - التحقق من طول كلمة المرور ومدة الحياة والتاريخ. ميزة سياسة كلمة مرور Windows التي تجعلها مختلفة عن مصادقة SQL Server هي تأمين تسجيل الدخول - بعد عدد من محاولات تسجيل الدخول الفاشلة المتتالية يصبح تسجيل الدخول مؤمنًا وغير قابل للاستخدام لمزيد من الاستخدام

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

0
Ivan Stankovic