هل يجب تنفيذ أمن البيانات من جانب قاعدة البيانات؟

Question

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

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

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

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

في الوقت الحالي، نحن نستخدم LINQ لـ ORM الخاص بنا.يبدو الأمر خفيفًا وسريعًا، ولكن الأفضل من ذلك كله هو أنه من السهل جدًا تطويره بسرعة.

هل تكلفة الصيانة تستحق مكاسب الأداء؟هل نخدع أنفسنا بالاعتقاد أنه سيكون هناك مكاسب ملحوظة في الأداء؟أم أننا فقط نصنع كابوسا لأنفسنا؟

بيئتنا:

• تطبيقات الأعمال الداخلية وغير المهمة
• سي#/آسب.نت 3.5
• ويندوز 2003
• مايكروسوفت SQL خادم 2005
• 35 تطبيق ويب متوسط ​​الحجم مع حوالي 500 مستخدم

Answer 1

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

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

Answer 2

لسوء الحظ لا توجد "إجابة واحدة صحيحة".يعتمد الاختيار الذي يجب عليك اتخاذه على عوامل متعددة، مثل:

• إلمام الفريق بالحلول المقدمة (على سبيل المثال، إذا كان معظمهم مرتاحًا لكتابة SQL، فيمكن أن يكون ذلك في قاعدة البيانات، ولكن إذا كان أغلبهم أكثر راحة مع C#، فيجب أن يكون ذلك في الكود)
• "السلطة السياسية" لكل حزب
• إلخ

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

Answer 3

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

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

يعد اختبار الوحدة أكثر صعوبة نظرًا لأن الأطر المتاحة لاختبار الوحدات أقل تطورًا بكثير.

إن التصميم المناسب الذي يحركه المجال والمجال هو خارج النافذة.

وستكون مكاسب الأداء ضئيلة إن وجدت.تحدثنا عن هذا هنا.

أوصي بأنه إذا كنت تريد الحفاظ على سلامة عقلك كمطور، فعليك أن تقاتل بكل ما أوتيت من قوة للحفاظ على قاعدة البيانات كطبقة الثبات فقط

Answer 4

IMHO:

طبقة خدمة التطبيق -> منطق التطبيق والتحقق من صحته
طبقة بيانات التطبيق -> منطق البيانات وأمنها
قاعدة البيانات -> اتساق البيانات

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

Answer 5

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

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

تتمثل إحدى فوائد وجود DBA في منطق الأمان لتطبيقك في أنه يمكن تقسيم ميزات وأدوار التطبيق المختلفة في قاعدة البيانات إلى طرق عرض، لذلك حتى إذا كانت هناك حاجة إلى SQL ديناميكي وبيانات تحديد عامة، فإن الضرر الناتج عن ثغرة SQL يمكن أن تكون مقيدة.

والجانب الآخر من هذا، بطبيعة الحال، هو فقدان المرونة.من الواضح أن ORM سيكون أسرع في التطوير من التفاوض المستمر مع DBA حول معلمات الإجراء المخزن.ومع تزايد الضغط على تلك الإجراءات المخزنة، فمن المرجح أن تلجأ الإجراءات نفسها إلى SQL الديناميكية، والتي ستكون عرضة للهجوم مثل SQL المكونة من تطبيق.

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

من الواضح، أثناء كتابة تعليمات برمجية SQL في منطق التطبيق الخاص بك، تأكد من أنك تستخدم باستمرار البيانات المعدة ذات المعلمات، وأنك تقوم بتنقيح مدخلاتك، وأنك على دراية بالمدخلات الدولية (هناك العديد والعديد من الطرق لقول مفردة -quote over HTTP)، وأنك تدرك كيفية تصرف قاعدة بياناتك عندما تكون المدخلات كبيرة جدًا بالنسبة لعرض الأعمدة.

Answer 6

كل هذا يتوقف على حالتك، وربما يكون من الأفضل عدم اتباع مسار SP والقيام بكل شيء بطريقة DDD (قم بإنشاء نموذج المجال في الكود واستخدمه).

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

وإذا كان عليك التعامل مع الملايين والمليارات من السجلات، فسوف يسعدك أن يكون لديك خبير قواعد بيانات جيد يحل المشكلة لك.

Answer 7

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

Answer 8

لقد قمت ببناء تطبيقات تعتمد على الإجراءات المخزنة في الماضي.في حالتك، ربما تكون هناك طريقة للحفاظ على المصادقة في طبقة قاعدة البيانات وجعل منطق عملك في C#.استخدم طرق العرض للحد من البيانات (ترى فقط الصفوف التي لديك صلاحية لها).يمكن استخدام طرق العرض هذه في LINQ بنفس سهولة استخدام الجداول.يمكنك تعيين التحديثات الخاصة بك ليتم تنفيذها مع الإجراءات المخزنة.

يتيح ذلك linq ومنطق الأعمال في C# وطبقة مصادقة مشتركة في قاعدة البيانات التي تتحكم في الوصول إلى البيانات.