Ruby-on-rails 您如何保护 database.yml？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/18290/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How Do You Secure database.yml?
提问by John Topley
Within Ruby on Rails applications database.yml is a plain text file that stores database credentials.
在 Ruby on Rails 应用程序中，database.yml 是一个存储数据库凭据的纯文本文件。
When I deploy my Rails applications I have an after deploy callback in my Capistrano recipe that creates a symbolic link within the application's /config directory to the database.yml file. The file itself is stored in a separate directory that's outside the standard Capistrano /releases directory structure. I chmod 400 the file so it's only readable by the user who created it.
当我部署我的 Rails 应用程序时，我在我的 Capistrano 配方中有一个部署后回调，它在应用程序的 /config 目录中创建一个指向 database.yml 文件的符号链接。文件本身存储在标准 Capistrano /releases 目录结构之外的单独目录中。我 chmod 400 文件所以它只能由创建它的用户读取。
- Is this sufficient to lock it down? If not, what else do you do?
- Is anyone encrypting their database.yml files?
- 这足以锁定它吗？如果没有，你还做什么？
- 有人在加密他们的 database.yml 文件吗？
采纳答案by James A. Rosen
You'll also want to make sure that your SSH system is well secured to prevent people from logging in asyour Capistrano bot. I'd suggest restricting access to password-protected key pairs.
您还需要确保您的 SSH 系统受到良好保护，以防止人们以您的 Capistrano 机器人身份登录。我建议限制对受密码保护的密钥对的访问。
Encrypting the .yml file on the server is useless since you have to give the bot the key, which would be stored . . . on the same server. Encrypting it on your machine is probably a good idea. Capistrano can decrypt it before sending.
加密服务器上的 .yml 文件是没有用的，因为您必须向机器人提供密钥，该密钥将被存储。. . 在同一台服务器上。在您的机器上加密它可能是一个好主意。Capistrano 可以在发送前对其进行解密。
回答by Olly
The way I have tackled this is to put the database password in a file with read permissions only for the user I run my application as. Then, in database.yml I use ERB to read the file:
我解决这个问题的方法是将数据库密码放在一个文件中，该文件仅对我运行应用程序的用户具有读取权限。然后，在 database.yml 中，我使用 ERB 读取文件：
production:
adapter: mysql
database: my_db
username: db_user
password: <%= begin IO.read("/home/my_deploy_user/.db") rescue "" end %>
Works a treat.
很好用。
回答by slm
Take a look at this github solution: https://github.com/NUBIC/bcdatabase. bcdatabase provides an encrypted store where the passwords can be kept separated from the yaml files.
看看这个 github 解决方案：https: //github.com/NUBIC/bcdatabase。bcdatabase 提供了一个加密存储，可以将密码与 yaml 文件分开保存。
bcdatabase
bcdatabase is a library and utility which provides database configuration parameter management for Ruby on Rails applications. It provides a simple mechanism for separating database configuration attributes from application source code so that there's no temptation to check passwords into the version control system. And it centralizes the parameters for a single server so that they can be easily shared among multiple applications and easily updated by a single administrator.
数据库
bcdatabase 是一个库和实用程序，它为 Ruby on Rails 应用程序提供数据库配置参数管理。它提供了一种将数据库配置属性与应用程序源代码分离的简单机制，这样就没有诱惑将密码检查到版本控制系统中。并且它集中了单个服务器的参数，以便它们可以在多个应用程序之间轻松共享，并由单个管理员轻松更新。
回答by Peter Stuifzand
Even if you secure the database.yml file, people can still write that uses the same credentials if they can change the code of your application.
即使您保护了 database.yml 文件，如果人们可以更改您的应用程序的代码，他们仍然可以使用相同的凭据编写。
An other way to look at this is: does the web application have to much access to the database. If true lower the permissions. Give just enough permissions to the application. This way an attacker can only do what the web application would be able to do.
看待这个问题的另一种方式是：Web 应用程序是否需要大量访问数据库。如果为 true，则降低权限。为应用程序授予足够的权限。通过这种方式，攻击者只能执行 Web 应用程序能够执行的操作。
回答by Micah
If you're very concerned about security of the yml file, I have to ask: Is it stored in your version control? If so, that's another point where an attacker can get at it. If you're doing checkout/checkin over non-SSL, someone could intercept it.
如果你很在意yml文件的安全性，我不得不问：它是否存储在你的版本控制中？如果是这样，这是攻击者可以获取的另一个点。如果您通过非 SSL 进行结账/签入，有人可能会拦截它。
Also, with some version control (svn, for exampl), even if you remove it, it's still there in the history. So, even if you removed it at some point in the past, it's still a good idea to change the passwords.
此外，通过一些版本控制（例如 svn），即使您将其删除，它仍然存在于历史记录中。因此，即使您在过去的某个时候删除了它，更改密码仍然是一个好主意。
