ما هو DBMS مناسب للحفاظ على مخطط خاص حتى عند تثبيته "في البرية"

Question

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

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

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

ومع ذلك ، عندما بدأت في البحث ، تعلمت أنه بالنسبة لـ postgresql ، حتى لو قمت بتثبيت قاعدة البيانات بصمت ولا أقدم بيانات الاعتماد للمستخدم-يمكنهم ببساطة تغيير ملف التكوين المستند إلى النص (pg_hba.conf) ، و أعد تشغيل الخادم ، وتمكين الوصول الكامل إلى قاعدة البيانات دون بيانات الاعتماد.

هل هذا السيناريو مضمون في DBMs الأخرى؟ كيف تحمي معظم المنتجات التجارية مخططاتها في هذا السيناريو؟ هل تستخدم معظم المنتجات قواعد البيانات المدمجة؟

---

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

Answer 1

معظم المنتجات التجارية لا تحمي مخططاتها. يسقطون في أحد معسكرين:

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

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

Answer 2

بقدر ما أتذكر ، لا توجد منتجات تجارية "يحمي" مخططاتهم. ماذا تريد أن يكون المخطط محميًا؟

النظر في النقاط التالية:

• بعد كل شيء ، الشخص الوحيد الذي يمكنه حماية أي شيء في RDBMS هو مسؤول خادم قاعدة البيانات. وتريد أن يكون المخطط محميًا ضد هذا الشخص؟

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

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

---

تحرير: تعليق إضافي:

لا يهمني معظم قواعد البيانات الداخلية للمنتجات التي أستخدمها. هذا سبب آخر أعتقد أن معظمهم لا يتخذون أي إجراء لحمايتهم. معظمهم ليسوا مثيرة للاهتمام.

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

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

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

لكن قضيتك قد تكون مختلفة.

Answer 3

أي المشكلات التي تسعى إلى حلها؟ لا شيء يمكن أن يمنع DBA* من القيام بكل ما يريده لقواعد البيانات القياسية ، وكما أشار الآخرون إلى أنه من المعاداة بشكل نشط أن يتدخل مع الاحتياجات الخاصة بالموقع مثل النسخ الاحتياطية وترقيات قاعدة البيانات. على الأكثر ، يمكنك تشفير محتويات قاعدة البيانات الخاصة بك ، ولكن حتى ذلك الحين ، يجب عليك توفير مفتاح فك التشفير لتطبيقك لتشغيله بالفعل ويمكن أن يؤدي DBA المحفوظ والمعادٍ إلى تخريبه.

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

(*) DBA أو مسؤول النظام قادر على تعديل الملفات مثل pg_hba.conf.

Answer 4

كيف تحمي معظم المنتجات التجارية مخططاتها في هذا السيناريو؟

لا أعتقد أن معظم المنتجات التجارية تفعل أي شيء لحماية مخططاتها.

Answer 5

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

Answer 6

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

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

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

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