シークレット管理を実装する方法

问题

シークレットが設定ファイル・環境変数・コードに散在しており、ローテーションや監査、保護が困難です。アクセスを制御し、ローテーションを可能にし、漏えいを防ぐ、一元化されたシークレット管理システムが必要です。

前提条件

• 認証と認可の理解
• 暗号化と鍵管理への習熟
• 環境設定とデプロイに関する知識

ステップ

1. 1. Inventory and classify all secrets

   Catalog every secret in your system: API keys, database passwords, TLS private keys, encryption keys, OAuth client secrets, service account credentials. Classify by sensitivity (critical, high, medium) and rotation frequency. Identify where each secret is currently stored (repo, env vars, config files, hardcoded). This inventory is the baseline for migration. Use the env parser and config validator to scan existing configurations.

   入力

   scan: .env, config.yml, docker-compose.yml

   输出

   secrets: 15 found | critical: 3 (db passwords) | high: 5 (API keys) | medium: 7

2. 2. Choose and configure a secrets manager

   Select a secrets manager: HashiCorp Vault (self-hosted), AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager. Store each secret with metadata: name, description, rotation policy, access policy. Encrypt secrets at rest with AES-256. Configure authentication to the secrets manager using short-lived tokens (Kubernetes service accounts, cloud IAM roles) rather than long-lived credentials. Use the AES encryption and hash tools to understand the underlying security.

   入力

   secret: db_password = hunter2

   输出

   stored: secret/db/prod/password | encrypted at rest | access: app-service-account

3. 3. Implement access control and injection

   Apply least-privilege: each application or service can access only the secrets it needs. Use role-based or identity-based access policies. Inject secrets at runtime as environment variables or mounted files — never bake them into images or artifacts. Secrets should be fetched on startup and refreshed before expiration. Audit every secret access: who, what, when. Use the JWT and bearer token tools for service authentication to the secrets manager.

   入力

   app: payment-service requests secret: db_password

   输出

   access: ALLOW (policy matches) | injected as env var | audit logged

4. 4. Automate rotation and monitor for leaks

   Define rotation policies: database passwords every 90 days, API keys every 30 days, TLS keys annually. Automate rotation where possible (dynamic database credentials in Vault, cloud-managed rotation). Monitor for secret leakage: scan git history, CI logs, and error messages for secret patterns. Set up alerts for anomalous access (bulk reads, access from new locations). Use the hash-compare tool to verify secret integrity and the file hash to detect changes.

   入力

   rotation policy: db_password every 90 days

   输出

   rotated: new password generated | old revoked | apps reloaded | audit logged

期待される結果

すべてのシークレットが保存時に暗号化され、最小権限でアクセス制御され、自動ローテーションされ、完全に監査される、集中型シークレット管理システム。

よくあるエラー

Storing secrets in environment variables or .env files in production

Env vars are visible in process listings, crash dumps, and container inspect. Use a secrets manager that injects secrets at runtime, or encrypted at rest with decryption keys managed separately.

Baking secrets into Docker images or build artifacts

Never include secrets in images. Use runtime injection via secrets manager, Docker secrets, or Kubernetes secrets (backed by external secrets manager).

Not rotating secrets regularly

Automate rotation. Long-lived secrets accumulate exposure risk. Dynamic secrets (short-lived, auto-generated) are preferable to static rotation where possible.

トラブルシューティング指引

• If applications can't access secrets, verify the service identity has the correct policy and the token hasn't expired.
• For local development, use a .env file with non-production secrets (clearly marked) and gitignore it. Never use production secrets locally.
• If rotation breaks applications, implement dual-key support (old and new key valid during transition) before revoking the old key.

セキュリティ上の制限

• The secrets manager is a critical single point of failure — deploy it highly available with backup and disaster recovery.
• All secret access is audited; secrets are never logged, returned in API responses, or included in error messages.
• Secrets in memory are cleared when no longer needed; memory dumps remain a risk for highly sensitive secrets.