シークレット管理の設計判断 — どこに置き、どう渡すか

シークレット管理の問題は「どのツールを使うか」ではなく、「誰が・いつ・どこで渡すか」という設計判断の欠如から起きる。環境変数・専用ストア・暗号化ファイルのいずれを選ぶにしても、構築・デプロイ・実行のどのフェーズで注入するかを先に定め、stateやログへの漏洩経路を塞ぐ線を引かなければ、ツールを入れても認証情報はコードに舞い戻ってくる。本記事では、構築担当者が設計段階で直面する判断のポイントを体系的に整理する。

認証情報が「気づけばコードに」入り込む構造

ハードコードが始まる設計上の起点

「とりあえず動かす」フェーズで書いた認証情報が、そのまま本番コードに残るケースは構築現場で珍しくない。開発初期にデータベース接続文字列やAPIキーをソースに直書きし、後で外出しすることを技術的負債として先送りにするうちに、リポジトリの履歴に認証情報が残り続ける。特に問題になるのは、構築担当者とアプリケーション開発者が分離している環境だ。30台・50台を超えるような構成では担当が分かれ、「シークレットをどう渡すかの設計責任」が曖昧になりやすい。誰がどのタイミングで注入するかを決めずに構築を始めると、開発者が手っ取り早い方法として.envファイルにべた書きし、それがデプロイスクリプトに取り込まれるという経路で本番に紛れ込む。

.envファイルの本番混入が起きる経路

ローカル開発用の.envファイルは「便利な出発点」として広く使われているが、本番環境への混入リスクを設計段階で閉じておかなければ意味がない。よく見られるパターンとして、開発環境でしか使わないはずの.envをCI/CDパイプラインのアーティファクトに含めてしまうケースがある。ビルドジョブの中でコンテナイメージに.envをコピーし、そのイメージをそのまま本番レジストリにプッシュするという流れで、イメージ内に認証情報が封じ込められる。レイヤーキャッシュが有効な状態でこれが起きると、後でDockerfileを修正しても古いレイヤーに認証情報が残り続ける。「.envは開発環境ローカルのみ、CI以降は別の経路で注入する」というルールを構成管理ドキュメントに明示することが最初の設計判断になる。

「後で直す」が積み重なる構造的背景

認証情報のハードコードが問題と知りながら放置される背景には、修正コストの先送りという構造がある。初期構築を3〜5人のチームで進めるとき、シークレット管理の設計に割く工数は後回しにされがちだ。スプリントの優先度はアプリケーションの動作確認に集中し、「シークレット管理は次フェーズで整理する」という言葉が繰り返される。しかし本番リリース後に対処しようとすると、アプリケーション・インフラ・CI/CDの三層にわたる修正が同時に必要になり、工数は初期設計の3〜4倍に膨らむという話を複数の現場で聞く。設計の起点でシークレットの注入経路を決めておくことが、後のリファクタリングコストを最も効果的に抑える選択だ。

どこに置くか（環境変数／専用ストア／ファイル）の判断

選択肢ごとの特性と適用場面

シークレットの保管先は大きく4種類に分かれる。環境変数、クラウドマネージドの専用シークレットストア（AWS Secrets Manager・Azure Key Vault・GCP Secret Managerなど）、セルフホスト型のストア（HashiCorp Vaultなど）、そして暗号化ファイル（sopsやgit-crypt）だ。どれが正解かは環境の規模と運用体制によって異なるため、特性を比較した上で判断する必要がある。

保管方式	適した場面	主なリスク	運用コスト
環境変数	単一値の注入・小規模（5サービス以下）	ログへの混入・変数の散在管理	低
暗号化ファイル（sops等）	構築時のみ使用・オフライン・閉域網環境	鍵管理・ファイル配布時のリスク	中
クラウドマネージドストア	本番・外部公開系・ローテーション必要な環境	通信経路の確保・サービス依存	中〜高
セルフホスト型ストア	閉域網・オンプレ・マルチクラウド統合	ストア自体の可用性・運用負荷	高

クラウド環境とオンプレミスで判断軸が変わる点

クラウドネイティブな構成では、マネージドサービスのシークレットストアを使う選択肢が現実的になる。IAMロールとの連携でパスワードレス認証が実現でき、ローテーションも自動化の土台が整っているからだ。一方、オンプレミスや閉域網環境では外部ストアへの通信経路が制限される場合があり、HashiCorp VaultやCyberArk Conjurを自前で立てるか、暗号化ファイルで管理するかという判断になる。判断の分岐点は「シークレットの参照タイミングが実行時か構築時か」にある。実行時参照が必要なら専用ストアが必須になり、構築時のみ必要なら暗号化ファイルでも十分なケースがある。

「環境変数だけ」で済む範囲の見極め

環境変数は扱いやすいが、構造化データや複数の関連シークレットを扱う場面では限界がある。たとえば接続先の証明書・ユーザー名・パスワードの3値をそれぞれ環境変数に入れると、変数名の命名規則を統一しないまま増殖し、20〜30変数を超えたあたりで管理が行き詰まるケースが多い。「単一のシークレット値を1〜2個渡すだけ」という場面に環境変数を限定し、複数の関連値はストアから構造体としてまとめて取得する設計が、スケールしやすい。変数の数が増え始めたタイミングを、専用ストアへの移行を検討するシグナルとして捉えておく。

構築・デプロイ・実行のどの段階で渡すかの設計

ビルド時・デプロイ時・実行時の注入の違い

シークレットをいつ渡すかは、どこに置くかと同じくらい重要な判断だ。ビルド時に注入するとイメージやアーティファクトにシークレットが焼き込まれ、再利用や監査が困難になる。そのためビルド時の注入は「ビルドそのものに必要な認証（プライベートレジストリへのアクセスなど）」に限定し、アプリケーションが使うシークレットはデプロイ時か実行時に渡す設計の方が清潔だ。デプロイ時注入はKubernetesのSecretリソースやAnsibleのvaultを使ってマニフェストやプレイブックに展開するパターンで、構成管理と連動しやすい。ただし「デプロイ時に展開されたシークレットがどこに書き出されるか」を把握しておかないと、stateやログへの漏洩に直結する。

CI/CDパイプラインでの注入設計

CI/CDパイプラインでシークレットを扱うとき、「ジョブの環境変数として渡す」「ファイルとしてマウントする」「実行時に都度ストアから取得する」という3つの設計がある。ジョブの環境変数は最も手軽だが、デバッグモードやverboseログを有効にすると環境変数がすべてログに出力されるリスクがある。パイプラインのログ設定がデフォルトのままで本番シークレットが漏洩したケースは、CI/CDを運用する現場では繰り返し報告される問題だ。設計判断として「ジョブ内でシークレットを使う範囲を最小化する」ことが基本になる。ビルドジョブはレジストリ認証のみ、デプロイジョブはデプロイ対象の認証のみ、というように権限を分割する設計が望ましい。

コンテナ環境でのシークレット注入の設計判断

Kubernetesを使った構成では、SecretリソースをPodにマウントする方法と、実行時にサイドカーやinit containerからストアに接続して取得する方法の二択が基本になる。Kubernetes Secretはbase64エンコードに過ぎず、etcdに平文同然で保存されるため、etcdの暗号化設定が入っていない環境で「Secretを使っているから安全」と判断するのは誤りだ。外部ストアとの連携（Vault AgentやExternal Secrets Operatorなど）を使う場合、インフラの複雑性が一段上がる。5〜10サービス規模のシステムではKubernetes Secretをetcd暗号化の設定を入れた上で使い、規模が拡大したら外部ストアへ移行するというスモールスタートが現実的な選択になる。

stateやログへの漏洩を防ぐ設計の線引き

TerraformのstateにシークレットAAが残る問題

IaCツールとして広く使われるTerraformは、リソースの全属性をstateファイルに平文で保持する。データベースのマスターパスワードやAPIキーをTerraformリソースの引数に渡すと、それがterraform.tfstateにそのまま書き込まれる。リモートバックエンド（S3・GCS）を使っていてもバケットのアクセス制御が甘ければ、stateを読める立場の人間は全シークレットを参照できる状態になる。この問題に対する設計判断は「Terraformにシークレットの値を持たせない」ことだ。シークレットの値そのものはストアに格納し、Terraformからはストアへの参照（ARNやパス）だけを扱う設計にする。シークレットの初期値をTerraformで設定する場合でも、後続のローテーションでstateを経由しない仕組みを設計段階で決めておく必要がある。

ログへの混入を防ぐ設計

アプリケーションやミドルウェアのログは、デバッグや障害対応に不可欠な一方で、シークレットの漏洩経路としても機能する。HTTPクライアントのリクエストログを有効にした状態でAuthorizationヘッダーが記録される、アプリケーションエラーのスタックトレースに接続文字列が含まれる、といったケースはよく報告される。ログ設計の判断ポイントは「シークレットが流れる経路をログの対象から外す」ことだ。認証ヘッダーや接続文字列のパラメータ部分のマスキングを、ミドルウェアまたはロギングライブラリの設定で有効にすることを構築完了条件に含めておく。構築後に「ログに出ていた」と気づく事例は、チェックリストにログマスキングの確認項目がなかったケースがほとんどだ。

デバッグ・監査証跡との両立

ログのマスキングを強化しすぎると、障害対応時に必要な情報が取れなくなる問題が発生する。「シークレットは出さないが、それを使った接続が成功したか失敗したかは記録する」という粒度の設計が現実的だ。接続のsuccess/failureと、使用したシークレットの識別子（ARNやバージョンID）だけをログに残し、値そのものは記録しないという設計で、セキュリティと可観測性を両立できる。監査ログに「どのシークレットが・いつ・誰によって使われたか」を残すことは、インシデント対応の前提条件として設計に組み込む。

ローテーション前提で組むかどうかの判断

ローテーションを設計に組み込む判断基準

すべてのシークレットに自動ローテーションを設定すべきかというと、判断は環境の特性と運用体制による。外部に公開されているAPIキーや、マルチテナント環境でテナント間の分離に使われる認証情報は、ローテーション設計を最初から組み込む価値がある。一方、閉域網内のみで使われる内部サービス間のシークレットや、変更頻度が極めて低い長期証明書は、ローテーションよりも保管先のアクセス制御を強化する方が現実的な場合もある。判断の基準は「漏洩したとして、どの程度の被害時間を許容できるか」だ。数分以内に検知・無効化できる体制があれば短いローテーション周期に意味がある。そうでなければ、90日〜180日のローテーション周期をポリシーとして定めた上で、手動でも確実に実行できるプロセスを整える方が現実的な設計になる。

ローテーションを設計せずに進んだ場合のコスト

ローテーション非対応で構築した場合、後から対応しようとするとアプリケーション・インフラ・監視の三層での修正が必要になる。データベースパスワードをローテーションしようとして、接続プールの設定が対応していないためにアプリケーションが接続エラーを起こし、深夜のインシデント対応に発展したという話は複数の現場で聞く。設計段階で「ローテーション時にゼロダウンタイムで切り替えられるか」という問いを立てておくだけで、接続プールの設定・アプリケーションの再接続ロジック・シークレット更新のタイミングなど、設計上の考慮点が具体的に見えてくる。

自動ローテーションの設計パターン

自動ローテーションを設計するとき、「新旧どちらのシークレットも一定期間有効にする」というdual-secret（二重有効期間）パターンが基本になる。データベースパスワードのローテーションであれば、新しいパスワードを生成してDBに設定し、アプリケーションが新パスワードに切り替わったことを確認してから旧パスワードを無効化する2ステップの設計だ。このパターンを前提にすると、ローテーションのトリガー（スケジュール or イベント駆動）・切り替えの確認方法・失敗時のロールバック設計という3点が設計要件として確定する。これらを「後から考える」にすると、後から追加するコストは相当なものになる。

「重すぎる管理」で運用が止まる境界

過剰なシークレット管理が開発速度を止める場面

セキュリティへの配慮から、全シークレットを専用ストアに集中管理し、アクセスに多段の承認プロセスを設けた構成を採用したところ、開発環境でシークレットを取得するだけで担当者が30分以上かかる状況になった事例がある。承認フローが複雑なため開発者がローカルにシークレットをキャッシュし始め、結果的に「管理が厳しいはずなのにシークレットが個人PCに散在する」という逆効果を招いた。管理の「重さ」は、そのシークレットの漏洩リスクと影響範囲に比例して設計すべきだ。本番データベースの認証情報と開発環境のテストAPIキーに同じ承認フローを適用するのは設計として過剰だ。

管理コストとセキュリティレベルのバランス設計

シークレットを分類し、分類ごとに管理の重さを変える「階層型シークレット管理」が実用的な設計になる。たとえば「本番・外部公開系」は専用ストア＋自動ローテーション＋アクセスログ必須、「ステージング・内部系」は専用ストア＋手動ローテーション、「開発・テスト系」は環境変数または暗号化ファイル、という階層を設けることで、管理コストを影響の大きいシークレットに集中させられる。環境数が多い構成（本番・ステージング・開発・テストで10環境以上）では、この分類を設計初期に定義しないまま全シークレットを同一ストアで管理し始めると、アクセス制御ポリシーが複雑に絡み合い、後から整理できなくなる問題が起きやすい。

スモールスタートで始める設計戦略

シークレット管理の理想形を初日から実装しようとすると、構築が立ち止まる。現実的な設計戦略は「今の規模で確実に動かせる最低限の管理から始め、リスクが高い領域だけ先に強化する」ことだ。5サービス以下の規模なら、まず環境変数と.envのGitコミット禁止の徹底から始め、本番シークレットだけを専用ストアに移す。10サービスを超えたあたりで全体をストアに統合し、20サービス規模でローテーション自動化を検討するという段階的な設計が、継続しやすい現実解になる。

シークレット管理チェックリスト

設計・構築・運用の各フェーズで確認すべき判断点をまとめた。手を動かす前に設計フェーズの項目を埋め、構築完了時に構築フェーズの項目を通過条件として使う。

設計フェーズ

• 各シークレットの保管先（環境変数・ファイル・ストア）と注入タイミングを設計ドキュメントに記載したか
• シークレットのリスク分類（本番／ステージング／開発）を定義し、管理の重さを分けたか
• ローテーション要否を各シークレットごとに判断し、自動化の対象を特定したか
• IaC（TerraformなどのstateにシークレットAAの値が残らない設計になっているか確認したか
• ローテーション時にゼロダウンタイムで切り替えられる接続・再接続の設計を確認したか

構築フェーズ

• .envファイルが.gitignoreに含まれ、Gitの履歴にシークレットが残っていないか
• コンテナイメージのビルドレイヤーにシークレットが焼き込まれていないか
• CI/CDのログ設定でシークレットがマスキングされているか（ジョブ環境変数のマスク設定を含む）
• etcd暗号化またはリモートバックエンドの暗号化が有効になっているか
• Kubernetesを使う場合、SecretリソースへのアクセスRBACが最小権限で設定されているか

運用フェーズ

• シークレットのアクセスログ（誰が・いつ・どのシークレットを取得したか）が記録・監視されているか
• ローテーション手順（自動または手動）が文書化され、実際に手順を通したテストを実施したか
• 不要になったシークレット（退職者・廃止サービス分）の削除プロセスが定義されているか
• インシデント発生時にシークレットを迅速に無効化できる手順が明文化されているか