هل تعمل مثيلات SQL Server المتعددة على زيادة الأمان؟

Question

سياق

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

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

يتم تشغيل خادم الويب وخدمات الويب على Windows Server مع IIS + ASP.NET وقواعد البيانات موجودة في مثيل SQL Server واحد.افترض أن النظام محدث دائمًا، ويتم تقييم السجلات بعناية وتم تكوين النظام بشكل صحيح ولا يتمتع المهاجم بإمكانية الوصول الفعلي إلى الجهاز نفسه.

العمارة الحالية

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

حتى لو لم يكن مرتبطًا بشكل مباشر بقاعدة البيانات، تذكر أيضًا ما يلي:

• الإدارة الصحيحة لكلمات المرور (تخزين التجزئة باستخدام خوارزمية تجزئة جيدة وبطيئة، موصوفة أيضًا كيفية تجزئة كلمات المرور بشكل آمن؟) وقواعد الأمان (يتم تشجيع عبارات المرور عبر كلمة المرور القصيرة/المعقدة، لا يلزم تغيير كلمة المرور إلا بعد العديد من محاولات تسجيل الدخول الفاشلة، راجع أيضًا كيف يؤدي تغيير كلمة المرور الخاصة بك كل 90 يومًا إلى زيادة الأمان؟).
• التعامل مع الهجوم الموازي (تأخيرات تدريجية لكل تسجيل دخول فاشل - سواء من نفس عنوان IP أو من نفس اسم المستخدم - والقوائم السوداء).متعلق ب: كيف يمكن التعرف بشكل فريد على المستخدمين الذين لديهم نفس عنوان IP الخارجي؟.
• انتهت مهلة الجلسات (إعادة تعيين نشاط المستخدم لفترة قصيرة، وتم إصلاح الجلسة الطويلة).يوجد أيضًا جانب العميل ضعيف الحماية التي تقوم بفصل المستخدم تلقائيًا (كما هو موضح في يستعيد Google Chrome ملفات تعريف الارتباط للجلسة بعد حدوث عطل، كيف يمكن تجنب ذلك؟ ولكن أيضًا لتسجيل الخروج تلقائيًا عند الابتعاد) إذا انتقل بعيدًا دون قطع الاتصال.
• تتم مراقبة السجلات يدويًا ولكن هناك قواعد تؤدي إلى تشغيل التنبيهات تلقائيًا.

يتم تخزين البيانات في قواعد بيانات مختلفة ومختلفة N+3 (تم تكوين كل قاعدة بالأذونات المطلوبة بالضبط، لا sa-مثل الوصول، كما هو موضح كيفية تأمين جدول قاعدة بيانات المستخدمين لتطبيق ما؟).

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

سؤال

هل سيؤدي استخدام ثلاث مثيلات مختلفة لـ SQL Server (واحدة للسجلات وواحدة للحسابات والتعيين وواحدة لجميع قواعد بيانات المستخدم) إلى زيادة الأمان أم التعقيد فقط؟

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

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

اعتبارات

أعلم أنه في مجال الأمان غالبًا ما يكون "الأكثر أفضل" (على الأقل هذا شعار شائع) ولكن العيوب قد تكون أكبر من أي فائدة (إن وجدت):

• زيادة تكلفة الأجهزة والبرمجيات.
• زيادة التعقيد (سواء بالنسبة للإعداد أو الصيانة)، يعد هذا عيبًا كبيرًا في المنظمة البحرية الدولية (IMO)، لأن النظام (المحتمل) الأكثر أمانًا مع التكوين غير الأمثل قد يكون أقل أمانًا بكثير من النظام الأبسط.

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

---

لا أعرف ما إذا كان هذا السؤال يتعلق بالموضوع بشكل صارم هنا، ويبدو أنه يمتد عبر العديد من مواقع SE ولست متأكدًا من أي منهما هو الصحيح.

Answer 1

بشكل عام، الحالات المتعددة لا تزيد من الأمان، بل من التعقيد فقط.هناك أسباب لاستخدام مثيلات متعددة ولكن لا أعتقد أنها تناسب موقفك.

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

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

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