データベース接続文字列のセキュリティ

セキュリティのベストプラクティス

データベース接続文字列には機密性の高い認証情報が含まれています。不適切な取り扱いはデータベース全体を不正アクセスに晒す可能性があります。

ルール1：認証情報をハードコードしない

悪い例：

// これはやめてください
const db = new Pool({
  connectionString: 'postgresql://admin:SuperSecret123@db.example.com/prod'
});

良い例：

const db = new Pool({
  connectionString: process.env.DATABASE_URL
});

ルール2：環境変数を使用する

接続文字列を環境変数に保存します。一般的なアプローチ：

.envファイル（ローカル開発のみ）：

DATABASE_URL="postgresql://user:pass@localhost:5432/dev"

.envファイルは絶対にコミットしないでください。 .gitignoreに追加：

.env
.env.local
.env.production

ルール3：本番ではシークレットマネージャーを使用する

本番環境では専用のシークレット管理を使用してください：

• AWS Secrets Manager / AWS SSM Parameter Store
• Google Cloud Secret Manager
• Azure Key Vault
• HashiCorp Vault
• Doppler、Infisical、または類似のSaaS

これらは環境変数だけでは提供できない監査ログ、自動ローテーション、アクセス制御を提供します。

ルール4：最小権限の原則

必要最低限の権限を持つデータベースユーザーを作成してください：

-- PostgreSQL：レポーティング用の読み取り専用ユーザー
CREATE USER reporter WITH PASSWORD 'readonly_pass';
GRANT CONNECT ON DATABASE myapp TO reporter;
GRANT USAGE ON SCHEMA public TO reporter;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO reporter;

異なるサービスには別々の認証情報を使用してください。アプリケーション接続にスーパーユーザー（postgres、root、sa）を使用しないでください。

ルール5：認証情報のローテーション

データベースパスワードは定期的にローテーションしてください。シークレットマネージャーを使えば自動化できます：

1. 新しいパスワードを生成
2. データベースユーザーを更新
3. シークレットマネージャーのシークレットを更新
4. アプリケーションが次のコネクションプールリフレッシュ時に新しい認証情報を取得

よくあるミス

ミス	リスク	対策
.envをgitにコミット	認証情報の流出	.gitignore
接続文字列のログ出力	ログファイル内の認証情報	ログでパスワードをマスク
本番でroot/adminを使用	侵害時のフルDBアクセス	専用アプリユーザー
開発/本番で同じ認証情報	開発の侵害 = 本番の侵害	別々の認証情報
本番でSSLなし	認証情報が平文で送信	常にSSLを使用