シークレット管理の実務。APIキー・認証情報をハードコードせず、Vaultやマネージドサービスで守りローテーションする

アプリケーションは単体で完結しません。データベースに接続し、外部APIを呼び、クラウドのリソースを操作します。その一つひとつに「自分が正規の利用者であること」を証明するための認証情報が必要です。DBのパスワード、外部サービスのAPIキー、クラウドのアクセスキー、TLS証明書の秘密鍵、署名用のトークン。こうした「漏れると不正利用に直結する秘密の値」をまとめてシークレット（secret）と呼びます。シークレット管理とは、これらを安全に保管し、必要なときだけ必要な相手に渡し、漏えいの兆候に備える一連の仕組みのことです。

シークレットの怖いところは、一つ漏れただけで被害が一気に広がる点にあります。DBのパスワードが漏れれば顧客データを引き抜かれ、クラウドのアクセスキーが漏れれば高額なリソースを勝手に立ち上げられ、外部APIキーが漏れれば自分の名義で不正なリクエストを大量に飛ばされます。しかも、ソースコードや設定ファイルに平文で書かれたシークレットは、リポジトリの共有、ログへの出力、バックアップの流出など、思いがけない経路から外へ出ていきます。コードレビューでうっかりキーを含んだままコミットし、公開リポジトリに上がってしまう事故は今も後を絶ちません。

この記事では、シークレット管理を「ハードコードの回避」「集中管理」「ローテーション」「最小権限とアクセス制御」という4つの軸で整理し、それぞれの原理と実務での判断基準を掘り下げます。手段としては環境変数、HashiCorp Vault のようなシークレット管理基盤、AWS Secrets Manager などクラウドのマネージドサービス、そして動的シークレットまでを扱い、何をどう使い分ければよいかを具体例とともに示します。特定の言語やクラウドに依存しない考え方を中心に据えるので、自分の現場に置き換えて読んでください。

シークレット管理の4つの軸（早見表）#

シークレット管理でやるべきことは多岐にわたりますが、目的で分けると次の4軸に整理できます。個別のツールの話に入る前に、まずこの全体像を押さえると、なぜその対策をするのかを見失わずに済みます。

この4つは独立しているようで、互いを補い合います。ハードコードをやめてシークレットをコードから切り離し、切り離した先を専用基盤で集中管理し、その値を定期的に入れ替えながら、誰に渡すかを最小権限で絞る。どれか一つだけでは不十分で、4つを組み合わせて初めて「漏れにくく、漏れても被害を抑えられる」状態になります。DevSecOpsの観点からこれらを開発フローに組み込む全体像は

なぜハードコードがそこまで危険なのか#

シークレット管理の出発点は、ハードコードをやめることです。ハードコードとは、APIキーやパスワードをソースコードや設定ファイルに直接書き込むことを指します。一見すると手早くて動くので、開発初期やプロトタイプでは安易に使われがちです。しかし、これは MITRE が CWE-798（Use of Hard-coded Credentials、ハードコードされた認証情報の使用）として定義する、明確なソフトウェアの弱点です。CWE-798 は MITRE の CWE Top 25（影響の大きい弱点ランキング）に2024年版まで継続的に掲載されてきた弱点で（2025年版ではTop 25圏外になったものの）、依然として軽視できない問題として広く認識されています。

なぜそこまで危険なのか。理由は、コードに書かれたシークレットがコードと運命を共にしてしまうからです。コードはバージョン管理され、コピーされ、共有され、ビルド成果物に取り込まれ、ログに出力されることもあります。その流れに乗ってシークレットも一緒に拡散します。具体的には、次のような経路で外に漏れます。

• Gitリポジトリへのコミット。一度コミットすると、後で消しても履歴に残り続ける。公開リポジトリならその瞬間に全世界へ露出する
• ビルド成果物やコンテナイメージへの埋め込み。配布物を解析すれば取り出せる
• ログ・エラーメッセージへの出力。デバッグ目的で接続文字列ごと出してしまう
• 設定ファイルのバックアップや、開発者間でのファイル共有

しかも CWE-798 の説明が指摘するように、ハードコードされた認証情報は管理者が検知しにくく、見つけても修正が難しいという厄介さがあります。製品に埋め込まれたキーを変えるには再ビルドや再配布が必要になり、すでに出回ったものは回収できません。だからこそ「最初から書かない」設計が重要になります。

MITREのCWE-798では、製品がパスワードや暗号鍵などのハードコードされた認証情報を持つことを弱点として定義し、それが認証の回避につながり、管理者にとって検知も修正も難しいことが説明されています（執筆時点の記載に基づく）。

環境変数は「入口」であって「保管庫」ではない#

ハードコードをやめる第一歩として、多くの現場でまず使われるのが環境変数です。シークレットをコードから切り離し、実行環境から注入する方法で、process.env.DB_PASSWORD のように読み出します。コードに値が残らないので、ハードコードよりは確実に前進です。ただし、環境変数を使えばシークレット管理が完成するわけではありません。ここを誤解すると、別の穴が開きます。

環境変数の注意点を押さえておきましょう。

• 値の出どころが必要。環境変数に入れる値は、結局どこかに保管されている。.envファイルに書いて運用するなら、その.envを絶対にリポジトリにコミットしないこと（.gitignoreへの登録は必須）
• プロセス全体から見える。環境変数はそのプロセスとその子プロセスから参照できる。サードパーティのライブラリやクラッシュレポートが環境変数を丸ごと送信してしまう事故もある
• ログ・ダンプに出やすい。エラー時に環境変数一覧を出力する仕組みがあると、そこにシークレットが混ざる
• 監査やローテーションの仕組みがない。環境変数自体は「誰がいつ使ったか」を記録しないし、自動で入れ替えてもくれない

つまり環境変数は、アプリにシークレットを「渡す入口」としては有効ですが、それ自体が安全な「保管庫」や「管理の仕組み」になるわけではありません。OWASP の Secrets Management Cheat Sheet も、シークレットの保管・配布・監査・ローテーション・失効を担う集中管理の仕組みを推奨しています。小規模な構成では環境変数と厳重な.env管理で始めつつ、規模や重要度が上がったら専用基盤に移すのが現実的な道筋です。

集中管理。専用基盤で保管・配布・監査をまとめる#

シークレットの数が増え、扱うサービスが増えてくると、値を一か所で集中管理する専用基盤が効いてきます。代表例が HashiCorp Vault や、クラウド各社のマネージドサービス（AWS Secrets Manager、Google Cloud Secret Manager、Azure Key Vault など）です。これらは単なる「暗号化された置き場」ではなく、保管・配布・監査・ローテーション・失効までをまとめて担う点に価値があります。

専用基盤を使うと、次のことが実現できます。

• 暗号化保管。シークレットは暗号化された状態で保管され、平文がそのまま置かれない
• アクセス制御。どのサービス・どの人がどのシークレットを読めるかを、シークレット単位で細かく設定できる
• 監査ログ。誰がいつどのシークレットを取得したかが記録される。漏えいの調査や不審なアクセスの検知に使える
• 中央でのローテーション。値の入れ替えを一元的に管理でき、後述の自動ローテーションにつなげられる

OWASP の Secrets Management Cheat Sheet は、シークレットの集中管理（centralization）、最小権限に基づくアクセス制御、ライフサイクル（作成・ローテーション・失効・期限）の管理、そして CI/CD パイプラインでの安全な取り扱いを、横断的なベストプラクティスとして整理しています。重要なのは、どの基盤を選ぶかよりも、「保管・配布・監査・ローテーションを仕組みとして一元化する」という発想です。

OWASPのSecrets Management Cheat Sheetでは、シークレットの集中管理・高可用性・アクセス制御・監査・ライフサイクル管理（作成からローテーション・失効まで）や、CI/CDパイプライン・クラウド・コンテナでの取り扱いがまとめられています（執筆時点の構成に基づく）。

ここでつまずきやすいのが、「基盤に保管したシークレットを、アプリがどう受け取るか」という部分です。基盤に値を置いても、アプリがそれを取りに行く際の認証情報がまた必要になります。これを再びハードコードしてしまうと本末転倒です。実務では、クラウドのIAMロールやKubernetesのサービスアカウント、OIDC（OpenID Connect）連携といった「IDに基づく認証」を使い、長期間有効な固定キーを持たずに基盤へアクセスする方法が推奨されます。OWASP の Cheat Sheet も、OIDC のようなパスワードレス認証や、CI/CD で使う認証情報をジョブ完了後に失効する短命な運用を推奨しています。実装例としては、GitHub Actions などから OIDC で基盤に認証すれば、長寿命のキーをシークレットとして保存せずに済みます。

ローテーション。漏えいの「被害が及ぶ期間」を区切る#

どれだけ厳重に管理しても、シークレットが漏れる可能性をゼロにはできません。そこで効いてくるのがローテーション、すなわちシークレットを定期的に新しい値へ入れ替える運用です。ローテーションの本質は、漏えいそのものを防ぐことではなく、「漏れた値が有効である期間」を短く区切ることにあります。仮に値が漏れても、次のローテーションで無効になれば、攻撃者がそれを使える窓は限られます。

AWS Secrets Manager を例にとると、ローテーションは「シークレットの値と、接続先（DBやサービス）側の認証情報を、両方とも周期的に更新するプロセス」と定義されています。Secrets Manager では、対応するマネージドシークレット（RDSやAuroraなど）に対してサービス側が自動でローテーションを行うマネージドローテーションと、それ以外の対象に対して Lambda 関数を使って更新するローテーションが用意されています。ローテーション中は、現在有効な版を AWSCURRENT、検証中の新しい版を AWSPENDING というステージングラベルで区別し、新しい値の作成・接続先への設定・検証・切り替えを段階的に進めます。これにより、新旧の切り替え中にアプリが接続できなくなる事態を避けます。

AWS Secrets Managerの公式ドキュメントでは、ローテーションがシークレットと接続先の認証情報を周期的に更新するプロセスであること、マネージドローテーションとLambda関数によるローテーションがあること、AWSCURRENT/AWSPENDINGというステージングラベルで版を管理することが説明されています（執筆時点の記載に基づく）。

ローテーションを設計するうえでの実務的なポイントは次のとおりです。

• 切り替え時のダウンタイムを避ける設計にする。古い値と新しい値が一時的に両方有効な「重複期間」を設けると、アプリが切り替わるまで接続が切れない
• 自動化を前提にする。手作業のローテーションは、忘れられたり、夜間に障害を起こしたりしがちで、結局回らなくなる
• 漏えい時は周期を待たず即時にローテーションする。定期ローテーションは「平常時の入れ替え」、緊急時は別枠の即時失効として扱う
• アプリ側がローテーションに追従できることを確認する。値をプロセス起動時に一度だけ読む実装だと、ローテーション後に古い値を握り続けてしまう

動的シークレット。そもそも長生きさせない#

ローテーションの考え方を突き詰めると、「短い周期で入れ替える」よりさらに進んで、「使うたびに発行して短時間で捨てる」という発想に行き着きます。これが動的シークレット（dynamic secrets）です。固定のパスワードを共有し続けるのではなく、アクセスが必要になった瞬間に、その用途専用の使い捨て認証情報を生成します。

HashiCorp Vault の Database secrets engine がわかりやすい例です。公式ドキュメントによれば、この仕組みでは、DBへアクセスしたいサービスが認証情報をハードコードする必要がなくなり、必要なときに Vault へ要求して受け取れます。発行される認証情報にはリース（lease）と TTL(time-to-live、有効期間)が紐づき、期限が切れると Vault が内部の失効の仕組みによって、対応するDBユーザーを自動的に無効化します。つまり、人手で後始末をしなくても、使い終わった認証情報が時間とともに消えていきます。

HashiCorp VaultのDatabase secrets engineの公式ドキュメントでは、サービスがDB認証情報をハードコードせずVaultから動的に取得できること、発行された認証情報にリースとTTLが付き、期限切れでVaultが自動的に該当ユーザーを失効させることが説明されています（執筆時点の記載に基づく）。

動的シークレットには、固定シークレットにはない利点があります。

• 漏えい時の影響が小さい。発行された値は短時間で失効するため、漏れても使える窓が極めて短い
• 利用元を特定しやすい。サービスごとに別々の認証情報が発行されるため、不審なアクセスがあったときに「どのサービス・どのインスタンスが原因か」を、使われたユーザー名から追える
• 後始末が自動。リース満了で自動失効するので、使われなくなった認証情報が居座らない

一方で、動的シークレットは万能ではありません。接続先がオンデマンドの認証情報発行に対応している必要があり、対応していない外部サービスのAPIキーなどは、結局のところ固定シークレットとして集中管理し、定期ローテーションで守ることになります。動的にできるものは動的に、できないものは集中管理とローテーションで、という使い分けが現実的です。

最小権限とアクセス制御。渡す範囲を絞る#

最後の軸が、シークレットを「誰に・どこまで」渡すかを絞る最小権限とアクセス制御です。集中管理基盤に保管しても、全サービス・全開発者がすべてのシークレットを読める設定では、一つの侵入で全シークレットが抜かれてしまいます。OWASP の Cheat Sheet も、シークレット単位のきめ細かいアクセス制御と、シークレット管理に触れるすべてのユーザー・サービスへの最小権限の適用を推奨しています。

実務での観点は次のとおりです。

• シークレット単位で権限を分ける。サービスAはサービスA用のシークレットだけ読める、というように、利用範囲に応じて読み取り権限を分割する
• IDに基づく認証を使う。固定キーで基盤にアクセスするのではなく、IAMロール・サービスアカウント・OIDC連携など、IDで認証して短命なトークンを得る
• 人とマシンを区別する。開発者が手元で使う権限と、本番のサービスが使う権限を分け、本番シークレットへの人手のアクセスは最小限にする
• 失効を即時に効かせられるようにする。退職・委託終了・漏えい時に、対象のアクセスを速やかに止められる経路を用意する

最小権限は「最初に絞る」のが鉄則で、後から絞ろうとすると何が動かなくなるか分からず、結局広い権限のまま放置されがちです。これはサーバーの権限設計と同じ考え方で、サービス全体での最小権限の徹底については

よくある質問#

まとめ#

シークレット管理は、派手な新技術を入れる話ではなく、「コードから秘密を切り離し、専用の場所で集中管理し、定期的に入れ替え、必要な相手にだけ渡す」という当たり前を仕組みとして回し続けることです。ハードコードをやめるだけでも事故の多くは防げますが、そこで止まらず、集中管理・ローテーション・最小権限まで積み上げて初めて、「漏れにくく、漏れても被害を抑えられる」状態になります。まずは手元のリポジトリに平文のシークレットが残っていないかを確認し、.envの管理を固め、重要なものから集中管理とローテーションへ移していく。この順で着実に進めることが、長くアプリを安全に運用する近道です。