シークレット管理は置き場所だけでは決まらない
シークレット管理で実務上よく起きる問題は、「環境変数に入れているから安全」「設定ファイルをGitに入れていないから大丈夫」と判断してしまうことです。
もちろん、ソースコードにAPIキーやDBパスワードを直書きしないことは大前提です。ただし、事故は保管場所だけでなく、CI/CDの権限、ログ出力、レビュー漏れ、退職者や委託先のアクセス権、ローテーション未実施でも起きます。
この記事では、Java/Spring Bootなどの業務システムを想定し、環境変数、設定ファイル、CI/CDでシークレットを扱うときのレビュー観点を整理します。
シークレット管理でまず分類する情報
まず、何をシークレットとして扱うかを明確にします。DBパスワードやAPIキーだけでなく、署名鍵、OAuthクライアントシークレット、Webhook署名用キー、暗号鍵、管理画面の初期パスワードも対象です。
OWASPのSecrets Management Cheat Sheetでは、シークレットの保管、アクセス制御、ローテーション、監査の重要性が整理されています。実務レビューでも、この4つを分けて見ると漏れを減らせます。
| 分類 | 例 | レビュー観点 |
|---|---|---|
| 認証情報 | DBパスワード、外部APIキー | 利用先、権限範囲、有効期限を確認する |
| 署名・暗号鍵 | JWT署名鍵、暗号化キー | 鍵長、保管場所、更新手順を確認する |
| CI/CD secrets | デプロイトークン、クラウド認証情報 | ジョブ単位の権限とマスク設定を確認する |
| 運用情報 | 管理者初期パスワード、保守用鍵 | 共有方法、削除時期、監査ログを確認する |
環境変数と設定ファイルの使い分け
環境変数は便利ですが、万能ではありません。プロセス情報、クラッシュダンプ、デバッグログ、CIの実行ログに露出することがあります。設定ファイルも、権限や配置先を誤ると同じように漏えいします。
実務では、非機密の設定と機密情報を分けます。例えば、接続先ホスト名やタイムアウト値は設定ファイルでよい場合があります。一方で、パスワードやトークンはシークレットストアやCI/CDのsecrets機能で管理します。
- 本番シークレットをローカル開発用ファイルにコピーしない
- サンプル設定にはダミー値だけを置く
- Spring Bootの`application-prod.yml`に実値を入れない
- 設定値をログに出すデバッグコードをレビューで止める
CI/CDのsecretsは実行権限まで見る
CI/CDでは、ビルド、テスト、デプロイの各ジョブにシークレットが渡されます。ここで重要なのは、値を暗号化しているかだけではありません。誰がジョブを実行できるか、どのブランチで値が使えるか、ログにマスクされるかまで確認します。
GitHub DocsのSecret scanningは、リポジトリに混入したシークレット検知の仕組みを説明しています。検知は最後の砦です。レビューでは、誤コミットを前提に早期検知と無効化手順まで決めます。
CI/CDレビューで見るチェックリスト
- pull request from forkで本番secretsが参照されない
- デプロイ用credentialが最小権限になっている
- CIログに環境変数を一括表示する処理がない
- ブランチ保護と承認フローがsecrets利用条件と合っている
- 漏えい時の無効化、再発行、影響範囲確認の手順がある
ローテーションは事故後ではなく平時に設計する
シークレットは漏えいしない前提で終わらせず、漏えいしても復旧できる設計にします。NISTのSP 800-57 Part 1では、鍵管理のライフサイクルが整理されています。実務では、発行、配布、利用、更新、失効を運用手順に落とします。
例えば、DBパスワードを変えるだけでも影響は広がります。アプリケーション、バッチ、監視、データ移行ジョブ、緊急保守手順が同じcredentialを使っている場合があるためです。
ローテーション設計では、二重登録できるか、切り替え時間を短くできるか、失敗時に戻せるかを確認します。JWT署名鍵なら、古い鍵で発行済みトークンを一定期間検証する設計も必要です。
シークレット管理の失敗例とレビュー観点
| 失敗例 | 原因 | 予防策 |
|---|---|---|
| APIキーをGitに誤コミット | サンプル設定と実値の境界が曖昧 | secret scanning、pre-commit、ダミー値運用 |
| CIログにトークンが出る | 環境変数の一括表示 | マスク設定、ログレビュー、デバッグ手順の制限 |
| 退職後もクラウド操作可能 | 個人credentialと棚卸し不足 | SSO、定期棚卸し、退職時チェック |
| 漏えい後に止められない | ローテーション手順が未整備 | 再発行手順、影響範囲、復旧訓練を用意 |
まとめ: シークレット管理は運用まで含めてレビューする
シークレット管理では、環境変数や設定ファイルの選択だけを見ても不十分です。保管場所、アクセス権、CI/CD、ログ、検知、ローテーションを一つの運用設計として確認します。
Java/Spring Boot案件でも、設定管理やCI/CDの設計はコード品質と同じくらい重要です。案件選びでは、セキュリティレビューや運用改善に関われるかも、経験者エンジニアにとって大事な判断材料になります。
bluenaでは、Java/Spring Bootをはじめとした実務経験を活かせる案件や、設計・レビュー・運用改善に関わる働き方について相談できます。
一度カジュアル面談をしませんか？
株式会社bluenaは「高還元」と「伴走支援」を両立したSES企業です。単価の81〜86%を還元する報酬体系と、専任サポーターによる隔週1on1で、エンジニアが納得できるキャリアを実現します。
まとまっていなくてもOK——まずは現在地を聞かせてください。
カジュアル面談ですので、お気軽にお聞かせください。
