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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

bcdatabase

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

Ответ 4

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

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

Ответ 5

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

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