كيف تتجنب تخزين كلمات المرور في التحكم في الإصدار؟

Question

ما الإستراتيجية التي تستخدمها لتجنب تخزين كلمات المرور في التحكم في الإصدار؟

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

لا يعد تخزين كلمات المرور في قاعدة البيانات خيارًا رائعًا:

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

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

أريد أيضًا أن أقول إنني لا أريد الأمان المطلق:أريد فقط تجنب وجود كلمات مرور على قرص كل مطور وجعل الأمر سهلاً للغاية.

لذلك أنا أسأل عن تجاربك/أفضل الممارسات.كيف تقوم بذلك؟

Answer 1

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

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

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

Answer 2

لقد رأيت طريقتين لهذا:

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

Answer 3

لا ينجح هذا في جميع الحالات، ولكن هنا تكمن روعة استخدام NT AUTHORITY ETWORK SERVICE كهوية لخدماتك.إذا كنت تستخدم هذه الهوية، فلن تحتاج إلى الاحتفاظ بكلمة مرور لها - يمكنك فقط استخدام بيانات اعتماد AD للكمبيوتر في شكل DOMAINNAME\MACHINENAME$ للوصول إلى شبكتك المحمية وقاعدة البيانات.

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

Answer 4

ضع كلمات المرور في متغيرات بيئة المستخدم.

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

Answer 5

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

https://stackoverflow.com/a/21570849/1675586

Answer 6

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