Как вы защищаете database.yml?

Question

В приложениях Ruby on Rails database.yml представляет собой обычный текстовый файл, в котором хранятся учетные данные базы данных.

Когда я развертываю свои приложения Rails, у меня есть обратный вызов after deploy в моем Capistrano рецепт, который создает символическую ссылку в каталоге приложения / config на файл database.yml.Сам файл хранится в отдельном каталоге, который находится за пределами стандартной структуры каталогов Capistrano / releases.Я модифицирую файл таким образом, чтобы он был доступен для чтения только пользователю, который его создал.

• Достаточно ли этого, чтобы заблокировать его?Если нет, то что еще вы делаете?
• Кто-нибудь шифрует свои файлы database.yml?

Answer 1

Вы также захотите убедиться, что ваша SSH-система хорошо защищена, чтобы люди не могли войти в систему как ваш бот Capistrano.Я бы предложил ограничить доступ к парам ключей, защищенных паролем.

Шифровать файл .yml на сервере бесполезно, так как вы должны передать боту ключ, который будет сохранен ...на том же сервере.Зашифровать его на вашем компьютере, вероятно, хорошая идея.Capistrano может расшифровать его перед отправкой.

Answer 2

Способ, которым я решил эту проблему, заключается в том, чтобы поместить пароль базы данных в файл с правами на чтение только для пользователя, от имени которого я запускаю свое приложение.Затем в database.yml я использую ERB для чтения файла:

production:
  adapter: mysql
  database: my_db
  username: db_user
  password: <%= begin IO.read("/home/my_deploy_user/.db") rescue "" end %>

Работает с удовольствием.

Answer 3

Взгляните на это решение github: https://github.com/NUBIC/bcdatabase.bcdatabase предоставляет зашифрованное хранилище, в котором пароли могут храниться отдельно от файлов yaml.

база данных bcd

bcdatabase - это библиотека и утилита которая обеспечивает настройку базы данных управление параметрами для приложений Ruby on Rails .Он предоставляет простой механизм отделения базы данных атрибутов конфигурации от исходного кода приложения, чтобы не возникало соблазна проверять пароли в системе управления версиями .И это централизует параметры для одного сервера, так что ими можно легко обмениваться между несколькими приложениями и легко обновлять одним администратором.

Answer 4

Даже если вы защитите файл database.yml, люди все равно смогут написать, в котором используются те же учетные данные, если они смогут изменить код вашего приложения.

Другой способ взглянуть на это -:имеет ли веб-приложение большой доступ к базе данных?Если значение true, уменьшите разрешения.Предоставьте приложению ровно столько разрешений, сколько необходимо.Таким образом, злоумышленник может делать только то, что могло бы сделать веб-приложение.

Answer 5

Если вы очень обеспокоены безопасностью файла yml, я должен спросить:Хранится ли он в вашем системе управления версиями?Если это так, то это еще один момент, когда злоумышленник может добраться до него.Если вы выполняете проверку через не-SSL, кто-то может это перехватить.

Кроме того, с некоторым контролем версий (svn, например), даже если вы удалите его, он все равно останется в истории.Таким образом, даже если вы удалили его в какой-то момент в прошлом, все равно рекомендуется сменить пароли.