Как Вы Защищаете database.yml?

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

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

Работает лакомство.

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

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

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

bcdatabase

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

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

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

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

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