Хранение защищенного паролем хранилища ключей keytool для управления версиями

Этот вопрос, вероятно, задавали, но я не совсем понимаю, почему люди предлагают не хранить хранилище ключей, созданное с помощью java keytool, в системе контроля версий. Пока хранилище ключей, а также ключи защищены паролем, есть ли вред в хранении хранилища ключей в системе управления версиями?

Было бы полезно шифрование хранилища ключей вместе с другими настройками, такими как пароль базы данных, пароли почтового сервера и т. там?

Аналогичный вопрос, но не ясный / принятый ответ:

https://superuser.com/questions/749949/should-i-add-keystore-files-to-version-control


person Divick    schedule 15.12.2015    source источник


Ответы (1)


Пароли и другие учетные данные являются аспектами конфигурации приложения, которые по своей природе зависят от среды, всякий раз, когда управление версиями предназначено для сохранения кода и артефактов, которые не зависят от среды.

Для этого в приложении The-Twelve-Factor определен хороший принцип: http://12factor.net/config

Это только одна причина не хранить учетные данные в системе управления версиями. Не менее важны и многие другие аспекты.

person Ben Goldin    schedule 15.12.2015
comment
Спасибо за ответ, но помимо шаблона или практики, какой вред хранит хранилище ключей в системе контроля версий? Будет ли кто-нибудь, имеющий доступ к хранилищу ключей, делать что-либо, не имея хранилища ключей и паролей ключей, что может быть проблемой безопасности? - person Divick; 15.12.2015
comment
Есть несколько проблем, о которых я мог бы подумать: 1) Хранение учетных данных для конкретной среды привязано к одной среде, где на самом деле у вас всегда есть несколько 2) Ключ и пароль определяются во время разработки, что означает отсутствие разделения обязанностей 3) Ключи хранятся вместе с сертификатом, у которого есть дата истечения срока действия, и, следовательно, их необходимо время от времени перевыпускать - система управления версиями не является подходящим местом для управления его жизненным циклом - person Ben Goldin; 15.12.2015