動的シークレットとリース

静的シークレットは一度作成されると、その後も無期限に再利用されるものです。たとえば、10 個のサービスが同じデータベースパスワードを何年も共有するケースです。静的シークレットは初期設定として使われますが、それが問題の原因にもなります。長期間有効で広く共有され、ローテーションが困難だからです。

動的シークレットは要求に応じて生成され、1 つの利用者に固有で、自動的に期限切れになります。パスワードを保存する代わりに、Vault は要求されるたびにまったく新しい認証情報を作成します。

この転換だけで、シークレット管理における最も難しい課題を解決できます。ローテーションが自動化され、漏洩した場合の被害範囲をほぼゼロに縮小できます。

動的シークレットを使用するには、Vault がバックエンドシステムに対する特権アクセスを持っている必要があります。データベースの場合の流れは次のとおりです。

• 管理者が、ルート DB 認証情報と作成用テンプレートを Vault に設定します。
• アプリが認証を行い、認証情報を要求します。
• Vault がデータベース上で CREATE USER を実行し、新しいユーザー名とパスワードを返します。
• リースの期限が切れると、Vault が自動的に DROP USER を実行します。

アプリは長期間有効なパスワードを見ることがありません。アプリの ID とリースに紐づいた一時的な認証情報を受け取ります。

アプリケーションがデータベースへのアクセスを必要とするとき、Vault に認証情報を要求します。応答には、新しく作成された固有のユーザー名とパスワードに加えて、その認証情報が有効な期間を示すリースが含まれます。

利用者ごとに固有の認証情報が付与されます。同じサービスのポッドが 2 つ起動した場合、それぞれ異なるユーザー名を受け取るため、データベースレベルで利用者ごとの監査が可能になります。

リースとは、このシークレットがこの期間だけ有効であることを示す契約です。すべての動的シークレットにはTTL（有効期間）と、任意で最大 TTLが設定されます。

• default_ttl：認証情報が期限切れになるまでの期間です。
• max_ttl：更新を行った場合でも超えられない絶対的な上限です。

リースの期限が切れると、Vault は認証情報を失効させます。つまり、データベースユーザーを実際に削除します。期限切れは単なるフラグではなく、実際のクリーンアップを発生させます。これにより、漏洩した動的シークレットは自動的に無効化されます。盗まれた認証情報も TTL の期間内には役に立たなくなります。

リースの有効期間を超えて動作し続けるアプリは、期限が切れる前にリースを更新する必要があります。更新によって TTL は最大 TTL まで延長されます。それを超えた場合、アプリは新しい認証情報を要求する必要があります。

運用担当者は、インシデント時のキルスイッチとして、リースを即座に失効させることもできます。リースを失効させると、残りの TTL に関係なく、基となる認証情報が直ちに削除されます。

プレフィックス配下にあるすべてのリースを失効させて、サービス全体や環境全体を即座に遮断することもできます。

動的シークレットはデータベースに限られません。Vault などのツールは、さまざまなシステム向けに短期間だけ有効な認証情報を生成します。

• Cloud IAM：STS 形式の assume-role による一時的な AWS/GCP/Azure アクセスキー。
• SSH：静的キーの代わりとなる、署名済みで短期間だけ有効な SSH 証明書。
• PKI/TLS：短い有効期間でオンデマンドに発行される証明書。
• RabbitMQ、MongoDB、Consul：一時的なサービス認証情報。

どのシステムでもパターンは同じです。要求し、短期間だけ使用し、自動的に期限切れにします。長期間有効な静的クラウドキーは侵害の主な原因になりやすく、動的 IAM 認証情報によって排除できます。

それぞれのモデルで認証情報が漏洩した場合を考えてみましょう。

• 静的：人が漏洩に気づき、ローテーションを行い、すべての利用者を更新するまでパスワードは有効です。露出期間は数日から数か月に及びます。
• 動的：認証情報は TTL の期間内（多くの場合、数分から 1 時間）に期限切れになり、最小限の権限で 1 つの利用者に限定されています。露出期間は非常に短く、被害も限定されます。

動的シークレットにより、ローテーションは困難な手動作業から、システムに組み込まれた自動的かつ継続的な仕組みへと変わります。

動的シークレットは強力ですが、Vault が認証情報を作成する各バックエンドについて、ユーザーを作成できる非常に高い権限を持つルート認証情報を保持する必要があります。これにより、リスクが Vault に集中します。

対策：

• ルート認証情報自体をローテーションし、Vault でさえ元の管理者パスワードを保持しないようにします。
• ルートアカウントの権限を、ユーザーの作成と削除に必要なものだけに正確に限定します。それ以上の権限は与えません。
• Vault ホストは価値の高い標的になるため、厳格に隔離し、積極的に監視します。

Vault は自身のルート認証情報をローテーションできるため、セットアップ後は誰もその認証情報を知らない状態にできます。

アプリは認証情報が変わることを前提に作成する必要があります。静的シークレットでは、コードは起動時に一度だけパスワードを読み取ります。動的シークレットでは、コードで次の処理を行う必要があります。

• 認証情報を取得し、そのリース TTL を確認します。
• リースを更新するか、期限が切れる前に新しい認証情報を再取得します。
• 古い認証情報が失効したときに、適切に再接続します。

よく使われるパターンは、リースのライフサイクルを処理してローカルのシークレットファイルを書き換えるサイドカーエージェントです。これにより、アプリは設定を再読み込みするだけで済みます。接続プールも更新し、期限切れの認証情報を使い続けないようにする必要があります。

すべてのシークレットを動的にできるわけではありません。オンデマンドで生成できない、長期間有効なキーを 1 つだけ発行するサードパーティ API もあります。このような静的シークレットには、補完的な対策を適用してください。

• コードには保存せず、必ず Vault に保存します。
• 最小権限に限定します。
• 定期的にローテーションします（次のレッスンで扱います）。
• 異常がないか使用状況を監視します。

基本原則は、動的シークレットを優先し、静的シークレットを使わざるを得ない場合は、徹底的にローテーションと監査を行うことです。

CI/CD パイプラインは、動的シークレットの代表的な用途です。従来、パイプラインは長期間有効なデプロイキーを保持しており、攻撃者にとって格好の標的でした。動的シークレットを使う場合、パイプラインは次のように動作します。

• OIDC ID（例：GitHub Actions OIDC トークン）を使って Vault に認証します。
• ジョブの実行中だけ有効な、短期間のクラウド認証情報を要求します。
• ジョブの終了時に、それらを自動的に期限切れにします。

長期間有効なデプロイキーが存在することはありません。侵害されたパイプラインのログから認証情報が漏洩しても、誰かが読む頃にはすでに無効になっています。

リースと動的シークレットについての理解度を確認しましょう。

短期間だけ有効で自動的に期限切れになる認証情報が、シークレット管理をどのように変えるかを学びました。

• 動的シークレットは要求に応じて生成され、利用者ごとに固有で、自動的に期限切れになります。再利用される静的シークレットとは異なります。
• リースは TTL と最大 TTL を定義し、期限切れになると Vault は実際のクリーンアップを伴って認証情報を失効させます。
• 長時間実行されるアプリはリースを更新でき、インシデント時にはキルスイッチとして即座に失効させることもできます。
• 動的シークレットはデータベース、クラウド IAM、SSH、PKI などで利用でき、被害範囲を縮小し、ローテーションを自動化します。
• トレードオフとして、Vault 内に特権を持つルート認証情報が必要になります。これをローテーションし、権限を厳密に限定してください。
• アプリと CI/CD は期限切れに対応できるように作成する必要があります。動的シークレットを優先し、避けられない場合は静的シークレットをローテーションしてください。

次は、キーをローテーションし、漏洩を防ぎきれなかった場合にそれを検知する方法を扱います。