أفضل طريقة لتخزين كلمة مرور قاعدة البيانات في ملف البرنامج النصي/التكوين لبدء التشغيل؟

Question

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

ما هي أفضل طريقة لتخزين الاسم/كلمة المرور لهذه التطبيقات، من حيث

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

كل من حلول Windows و Linux موضع تقدير!

Answer 1

أفضل طريقة لتأمين كلمة المرور الخاصة بك هي التوقف عن استخدام واحدة.استخدم اتصالاً موثوقًا به:كيف:الاتصال بـ SQL Server باستخدام مصادقة Windows في ASP.NET 2.0.إذن ليس لديك ما تخفيه - انشر ملف web.config والمصدر للعالم، وما زالوا غير قادرين على الوصول إلى قاعدة البيانات الخاصة بك.

إذا لم ينجح ذلك بالنسبة لك، فاستخدم المدمج نظام تشفير التكوين في ASP.NET.

Answer 2

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

1. تقييد الوصول إلى المنفذ المحلي، مثل السماح لمستخدم معين فقط بالاتصال به.
2. قم بإعداد اتصال بدون كلمة مرور بمضيف PostgreSQL باستخدام ssh كمستخدم معين.
3. السماح للمستخدم ssh بالاتصال بالوصول المحلي إلى PostgreSQL بدون كلمة مرور.

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

يحرر:يجب أن أضيف أن هذا سيعمل مع أي قاعدة بيانات تستمع إلى منفذ TCP/IP.لقد تم وصفه في PostgreSQL.وستحتاج إلى iptables (أو ما يعادله من Linux) للقيام بقيود المنافذ.يرى هذا.

Answer 3

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

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

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

Answer 4

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

Answer 5

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

@لوماكس:ربما لا أرغب في أن يتمكن الجميع من الوصول إلى الخادم الفعلي (على سبيل المثال.مسؤولي النظام) لرؤية كلمة المرور.

شكرًا!

Answer 6

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

البديل الأكثر تعقيدًا هو إعداد خادم كلمة مرور آمن مخصص إما:

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

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

Answer 7

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

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

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

يمكنك أيضًا قفل خادم قاعدة البيانات لقبول الاتصالات من أجهزة تطبيقات الويب الخاصة بك فقط عبر IP.

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