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

Question

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

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

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

Answer 1

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

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

Работает угощение.

Answer 2

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

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

Answer 3

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

bcdatabase

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

Answer 4

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

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

Answer 5

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

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