Secrets 漏洩は『1回で会社が傾く』リスク
APIキー・DBパスワード・暗号鍵の漏洩は、長期にわたる被害と信用失墜を招きます。本記事では編集部の視点で、Secrets 管理の実務を公開情報をもとに整理します。Web セキュリティ実践 もご参考に。
絶対やってはいけないこと
(1) Git に平文で保存。(2) 環境変数に平文 export してログ。(3) 共有Slack/メールでの送信。(4) 長期間ローテーションなし。(5) 退職者の権限放置。上記は人為的な事故の典型パターンです。
主要ツールの選択肢
(1) HashiCorp Vault：機能豊富・マルチクラウド。(2) AWS Secrets Manager / Parameter Store：AWS 内なら一体感あり。(3) GCP Secret Manager：GCP 内同様。(4) Azure Key Vault：Azure 内。(5) SOPS：Git にコミット可能な暗号化ファイル。チームと環境次第ですが、複数を併用するケースも多いです。
取得フロー設計
(1) アプリ起動時に取得：環境変数経由がシンプル。(2) 動的シークレット：使うたびに発行(Vault が得意)。(3) キャッシュ戦略：取得頻度の制御。(4) 失敗時のフェイルセーフ：起動時に明確に失敗。(5) 監査ログ：取得イベントを記録。
ローテーション
(1) 自動ローテーション：30〜90日サイクル。(2) DB パスワード：マネージドサービスで自動可。(3) APIキー：交換時のダウンタイム最小化策。(4) 証明書：cert-manager / ACM で自動更新。(5) 緊急ローテ手順：漏洩疑い時の即時切替。
CI/CD との統合
(1) GitHub Actions Secrets：repository/environment スコープ。(2) OIDC で短期トークン：長期キー不要に。(3) ログマスキング：set-secret-output の活用。(4) Pull Request では本番 Secrets を渡さない。(5) シークレットスキャン：trufflehog / gitleaks。CI/CD 実践 もご参考に。
失敗しがちなパターン
(1) .env を間違って push。(2) 同じシークレットを全環境共有。(3) ローテーション無し。(4) 権限が広すぎる：全員が本番Secrets参照可。(5) 削除手順がない：退職者の権限残存。対策は、(1)pre-commit hook、(2)環境別シークレット、(3)自動ローテ、(4)権限最小化、(5)オンボーディング/オフボーディング手順、です。