Rails 5生产环境中database.yml的正确权限设置及安全文件咨询

Great question—locking down sensitive files on your EC2 Rails instance is key to protecting your database, credentials, and overall server security. Let’s break this down step by step.

Fixing database.yml Permissions #

Your current permissions (-rw-rw-r-- / 664) are too permissive: this lets any user in the deploy group and all other users on the server read the file, which exposes your database username and password to unnecessary risk.

The correct permission for database.yml is 600 (read/write access only for the file owner). Run this command to update it:

chmod 600 /path/to/your/rails/app/config/database.yml

Good news: your file is already owned by deploy—the user running your Rails app—so you don’t need to adjust ownership here. This lock ensures only the user that needs database access can read the credentials.

Other Critical Security Files to Secure #

Here are the key files you should lock down, along with their recommended permissions:

• .env (if using dotenv or similar tools)
  This file stores sensitive environment variables like API keys, third-party service tokens, and AWS credentials. Set permissions to 600 with chmod 600 /path/to/your/app/.env—never let non-authorized users read these values.

• config/master.key (Rails 5+) or config/secrets.yml
master.key decrypts your Rails encrypted credentials; if this leaks, an attacker can unlock all your sensitive configs. Set permissions to 600 and never commit this file to version control (add it to .gitignore immediately if you haven’t already). For older Rails versions using secrets.yml, treat it exactly like database.yml—lock it to 600.

• SSH Private Keys (~/.ssh/id_rsa, ~/.ssh/id_ed25519, etc.)
  These keys grant access to your server and remote services (like Git repos). They must have permissions set to 600—SSH will actually refuse to use them if permissions are too open. The corresponding authorized_keys file can safely be set to 644.

• SSL Certificates & Private Keys
  If your app uses HTTPS, your SSL private key (usually stored in /etc/ssl/private/) should be set to 600 (only root can read/write). SSL certificates (in /etc/ssl/certs/) can be 644 since they’re public, but keep the private key locked down tight to prevent man-in-the-middle attacks.

• Server Configuration Files (Nginx, Puma, etc.)
  Files like /etc/nginx/sites-available/your-app or config/puma.rb may contain sensitive settings (proxy details, process permissions). Set these to 640 so only root and the server’s group (e.g., nginx) can read them—stopping unauthorized users from modifying or accessing sensitive configs.

Extra Security Best Practices #

• Never commit sensitive files to Git: Add database.yml, master.key, .env, and SSH keys to your .gitignore to avoid accidental exposure.
• Use IAM Roles for AWS access: Instead of hardcoding AWS credentials in your app, assign an IAM role to your EC2 instance. This lets your app access AWS services without storing keys locally.
• Run Rails as a non-root user: You’re already using deploy, which is smart—running apps as root increases the risk of full server compromise if the app is exploited.
• Regularly audit permissions: Periodically check for overexposed files with commands like find /path/to/your/app -type f -perm /o+r to catch files readable by all users.

内容的提问来源于stack exchange，提问作者matQ