中級では「隔離の選択肢」（環境変数・シークレットマネージャ・KMS）まで見ました。上級では発想を一段進めます——そもそも長期の秘密を配らない。エンベロープ暗号化・動的シークレット・ワークロードIDで、「漏れても被害が小さい」設計に踏み込みます。
概要 — まず全体をつかむ
アニメーション『秘密情報の扱い（隔離）』を開く
詳細 — 1段階ずつ追う
環境変数だけでは守り切れない
中級では「秘密は置き場所だけでなく経路でも漏れる」と押さえました。上級では、もっとも手軽な環境変数すら「隔離」としては弱いことを直視します。
- プロセスから覗ける — 環境変数はプロセス一覧やメモリダンプ、
/proc経由で読まれうる。同じホストの別プロセスや、クラッシュダンプにそのまま載る - 子プロセスへ継承される — 起動した外部コマンドに丸ごと引き継がれ、意図せぬ範囲へ広がる
- イメージや設定に焼き付く — コンテナイメージやCIの設定へ平文で埋め込まれやすい
つまり環境変数は「コードから分離する最低ライン」であって、上限ではありません。上級の目標は、実行時にだけ・必要な範囲にだけ・短命に秘密を渡すことです。
やさしく言うと（中級）
秘密（APIキー・DBパスワード・署名鍵）が漏れると、DBの中身を抜かれたり、外部サービスを勝手に使われて課金されたり——被害が直接的です。中級で押さえたいのは、秘密は「置き場所」だけでなく「経路」でも漏れるという視点です。
- コードに直書き — リポジトリの履歴に残り、公開・共有で流出
- フロントへの埋め込み — ブラウザに配るコードは全部読まれる前提
- ログ・エラー出力 — トークンをそのまま出すと保存先から漏れる
- CI/CDの設定 — ビルドログや設定ファイルに平文で残る
アニメーション『秘密情報の扱い（隔離）』を開く
シークレットマネージャとVault
中級の「隔離の選択肢」を、運用の仕組みとして深掘りします。専用基盤に集約する狙いは、単なる保管ではなく 集中管理・アクセス制御・監査 です。
- 一元管理 — Vault ※1 のような基盤に秘密を集め、誰がどの秘密をいつ読んだかを監査ログに残す
- 実行時取得 — アプリは起動時や実行時にAPIで取得し、ディスクに書かない。設定ファイルに平文を置かない
- リースとTTL — 貸し出しに期限を付け、「借りっぱなし」を防ぐ。失効すれば自動で無効になる
登場人物メモ（※の説明）:
- ※1 Vault — 秘密の保管・払い出し・監査・動的発行を担う専用基盤の代表格。アクセスは細かいポリシーで制御する
やさしく言うと（中級）
置き場所は用途と規模で選びます。
- 環境変数 — 小規模や単一サービスで手軽。ただしプロセスやログから見えやすい点に注意
- シークレットマネージャ（Vault・クラウドのSecrets Manager） — 一元管理・アクセス制御・監査・自動ローテーションを仕組み化できる
- KMS（鍵管理サービス） — 暗号鍵そのものを預け、鍵を取り出さずに暗号化や署名を実行させる
規模が大きくなるほど、誰が・いつ・どの鍵を使ったかを追える管理へ寄せるのが定石です。
KMSとエンベロープ暗号化
大量のデータをすべてマスタ鍵で直接暗号化すると、マスタ鍵を使う回数が増え、外に晒す機会も増えます。そこで 二段構えにします。これがエンベロープ暗号化です。
- DEK（データ鍵） ※1 でデータ本体を暗号化する（速い共通鍵暗号）
- その DEKを KEK（マスタ鍵） ※2 で暗号化し、暗号化済みDEKをデータのそばに保管する
- 復号時だけ、暗号化済みDEKを KMS に渡して「DEKだけ復号して」と頼む。KEKはKMSの外へ一度も出ない
こうすると、保管場所ごと漏れても中身はDEKで守られ、そのDEKもKEKなしでは開けません。KMSとの往復は小さなDEKだけで済むので、大量データでも軽い、という利点もあります。
登場人物メモ（※の説明）:
- ※1 DEK（Data Encryption Key） — 実データを暗号化する使い捨ての鍵。暗号化された状態でデータのそばに置ける
- ※2 KEK（Key Encryption Key／マスタ鍵） — DEKを暗号化する上位の鍵。KMSの内側に留め、決して平文で取り出さない
アニメーション『エンベロープ暗号化（鍵を鍵で包む）』を開く
ローテーションと動的シークレット
漏れを前提にするなら、鍵の寿命を短くするのが最も効きます。
- 自動ローテーション — 定期的な鍵の差し替えを人手に頼らず自動化する。手動だと必ず放置され、古い鍵が残り続ける
- 動的シークレット — DBユーザやクラウドの認証情報を 都度発行し、TTLが切れたら自動で失効させる。渡した瞬間から時限式で消える
- 短命クレデンシャル — 有効期間が数分〜数時間なら、漏れても悪用できる窓が極端に小さい
動的シークレットを活かすには、アプリ側も失効を前提に再取得・接続の張り直しができる設計が要ります。「一度取れば一生使える」前提のコードは、短命化と相性が悪いのです。
最小権限とワークロードID
長期キーを配らないための最終形が、実行主体そのものの身元で認証するワークロードID ※1 です。
- 身元で借りる — クラウド上のインスタンスやサービスアカウントは、キーを持たずとも「自分が誰か」をプラットフォームに証明し、その場限りの権限を得る
- CIは OIDC ※2 連携 — ビルドのたびにIDプロバイダが署名した短命トークンを提示し、クラウドが一時的な権限を発行する。長期キーをリポジトリにもシークレットストアにも置かない
- 最小権限の徹底 — 発行する権限は用途ごとに絞る。1つの主体に広い権限を与えると、乗っ取られたときの被害が跳ね上がる
認証そのものの仕組みは 認証 に、権限の絞り方の発想は同ユニット群に繋がります。
登場人物メモ（※の説明）:
- ※1 ワークロードID — 人ではなく実行中のプログラム（ワークロード）に与える身元。長期キーの代わりに使う
- ※2 OIDC（OpenID Connect） — 「この主体は本物」と署名付きで証明する仕組み。CIとクラウドの間で長期キーを介さない橋渡しに使う
IaCとCIでの秘密の扱い
自動化が進むほど、秘密はコードとパイプラインの中を通り抜けるようになります。ここでの原則は「実体を通さず、参照だけを通す」です。
⚠️ 上級で効く落とし穴
- TTLとライフサイクルの不整合 — 動的シークレットの有効期限より処理が長引き、途中で突然失効する。再取得の実装が要る
- KMS依存が単一障害点 — 復号のたびにKMSへ往復するため、KMSの停止や遅延、コストが効いてくる。適切なキャッシュとフォールバックを設計する
- 監査ログに秘密が漏れる — 秘密を守るはずのログに、値そのものを書いてしまう本末転倒
- デバッグ時のダンプ — 「一度も外に出さない」建前が、障害調査のメモリダンプや詳細ログで一気に崩れる
やさしく言うと（中級）
- リポジトリへの混入 — 一度でも公開されたら「漏れた」扱い。履歴を消すより先に無効化＆差し替え
- ビルドでフロントに露出 — 埋め込んだ鍵はブラウザから読める。サーバ側に寄せる
- ログに秘密を出す — エラーログやアクセスログにトークンを出さない
- 共有しすぎ・放置 — 1つの鍵を広く使い回すと被害が拡大。ローテーションされない鍵も危険
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. CIからクラウドへアクセスするとき 長期のアクセスキーを配らずに済ませる定番はどれ？
問2. エンベロープ暗号化（envelope encryption）の仕組みとして正しいのは？
問3. 環境変数に秘密を置くことの弱点として正しいのは？
問4. シークレットマネージャやVaultに秘密を集約する主眼はどれ？
問5. 「漏れても被害を小さくする」ために最も効くのはどれ？
問6. エンベロープ暗号化でKMSに依存する運用の注意点として正しいのは？
問7. エンベロープ暗号化で 実データを直接暗号化する使い捨ての鍵を英字3文字の略語で答えてください。
問8. 動的シークレットで貸し出しに付ける「有効期限」を表す英字3文字の略語は？