ما مدى أمان قاعدة بيانات postgresql إذا سُرق الخادم الخاص بي؟

Question

إذا كان لدي خادم يحتوي على قاعدة بيانات من أعلى البيانات السرية في postgresql وكان من المستحيل عملياً تخمين كلمة المرور الخاصة بي (128 حرفًا من جميع أنواع chars الغريبة ، التي تم إنشاؤها باليد). كلمة مرور الخادم لا يمكن تخمينها عمليا.

بصرف النظر عن تخمين كلمة المرور ، ما مدى سهولة إخراج البيانات من قاعدة البيانات هذه؟

الافتراضات:

1. فقط DB موجود على الخادم. لا توجد كلمة مرور في برنامج نصي PHP أو أي شيء من هذا القبيل
2. الشخص الذي سرق الخادم هو خادم / ديسيبل / خبير استرداد القرص الصلب
3. أنا لا أستخدم أي تشفير قوي أو أي شيء خارج المعيار للحماية
4. أنا أستخدم Ubuntu Hardy (أحدث إصدار مستقر)

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

Answer 1

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

كما سبق.

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

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

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

يعتبر TarmperPracking خيارًا آخر - إيجاد طريقة لمحو القرص الصلب إلكترونيًا في ظل ظروف معينة (مثل إزالته جسديًا من العلبة).

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

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

Answer 2

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

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

أعني ، إذا كان هذا سيناريو قد يحدث بشكل معقول ...

تعديل:

إذا كان لدي ملف Postgres DB الذي أردت الدخول إليه وكان لدي الموارد (أي إنفاق 4K لبعض Dells الرخيصة) ، فسأستخدم تكوين Beowulf وأداء تكسير القوة الغاشمة المتوازية. تزداد الأمور سوءًا إذا بدأت في الحصول على المزيد من المال ويمكنك تكوينها ، على سبيل المثال ، العديد من آلات Nvidia SuperiMputer-On-Desktop الحلوة التي تم توصيلها لبدء كلمة مرور.

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

Answer 3

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

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

Answer 4

يبدو أن هذه المقالة ذات صلة بشكل خاص بسؤالك:

إجمالي الأمان في قاعدة بيانات postgresql
http://www.ibm.com/developerworks/opensource/library/os-postgresecurity/

Answer 5

لا أعتقد أن هذه مشكلة postgresql ، أو أي عناوين قاعدة بيانات أخرى. حتى إذا كانت قاعدة البيانات الخاصة بها هي كلمة المرور ، فكل بيانات جميع البيانات في نص عادي وهذا ما يهم حقًا. لا شيء يمنع المهاجم من Cat'ing the Raw Database File وقم بتنشيطه على الرغم من الأوتار. أفضل حل لهذا النوع من الهجوم هو استخدام نظام الملفات المشفرة. سيتطلب منك ذلك كتابة كلمة مرور لتركيب القسم. هذا يزيد أيضا النفقات العامة.

Answer 6

بالنسبة للسؤال المحدد المنشور (والأسعار التي جئت إليها للبحث عن إجابة) ، PostgreSQL افتراضيًا لبيانات الجدول غير المشفرة. عند النظر حول الملفات في .../pgsql/9.2/بيانات/قاعدة/* أعتقد أن هذه الجداول المتاجر في قطع 1.1 جيجابت ، ويمكنني العثور على سلاسل ASCII بنجاح في تلك الملفات مع GREP. من فحص الملفات ، يبدو أن البيانات مخزنة في الأعمدة.

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

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

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

Answer 7

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