短期クレデンシャル

短期クレデンシャルとは

短期クレデンシャルは、数分〜数時間で自動的に失効する認証情報(トークンやアクセスキー)です。有効期限のない(または非常に長い)APIキーやパスワードの対極にあり、クラウド時代のセキュリティ設計の基本になっています。

考え方は単純で、「漏れない前提ではなく、漏れても被害が小さい前提で設計する」です。長期キーが漏えいすると、無効化するまで攻撃者はずっと使えます。短期クレデンシャルなら、たとえ漏れても期限が来れば勝手に使えなくなるため、被害の窓が数分〜数時間に縮まります。

長期キーの何が問題か

• リポジトリへの誤コミットやログ出力で漏えいしても、気づくまで有効なまま
• 定期ローテーション(付け替え)が必要だが、手作業になりがちで放置されやすい
• 退職者や停止したサービスのキーが残り続け、[[最小権限の原則]] から外れた「誰も把握していない鍵」になる

[[シークレット管理]] は「長期の秘密情報を安全に保管・配布する」対策ですが、短期クレデンシャルはさらに進めて「そもそも長期の秘密を持たない」ことを目指します。

代表的な仕組み

• クラウドの一時認証情報 — AWS STS の AssumeRole などで、ロールを引き受けて期限付きのアクセスキーを発行してもらう。EC2 や Lambda に付けるIAMロールも、裏では短期クレデンシャルの自動発行・自動更新で動いている
• OIDCフェデレーション — GitHub Actions などのCIからクラウドへ、固定キーを一切登録せずにアクセスする方式。CI実行時に発行される [[JWT]] 形式のIDトークンをクラウド側が検証し、期限付きの認証情報と交換する([[OAuth・OIDC]] の応用)
• アクセストークンの短命化+リフレッシュトークン — Webの [[認証と認可]] でも、アクセストークンを数分〜1時間で失効させ、更新用のリフレッシュトークンと組み合わせるのが定石
• SSH証明書 — 恒久的な公開鍵の代わりに、認証局が数時間だけ有効なSSH証明書を発行する運用

初学者向けポイント

• まず狙うべきは「CIやサーバーに置いた固定APIキーをなくす」こと。GitHub Actions からクラウドへのデプロイは OIDC フェデレーションへの置き換えが定番
• 「短期クレデンシャル+[[最小権限の原則]]」はセット — 期限を絞り、権限も必要最小限に絞る
• 期限切れによる失敗はエラーではなく仕様。自動で再取得する前提でアプリや運用を組む

関連技術とのつながり

• [[シークレット管理]] — 長期の秘密を守る対策の先にある「長期の秘密を持たない」設計
• [[認証と認可]] — アクセストークンの短命化は認証設計の定石
• [[JWT]] — 有効期限(exp)を埋め込んだ自己完結型トークンとして短期クレデンシャルの実装によく使われる
• [[OAuth・OIDC]] — OIDCフェデレーションによるキーレス認証の土台
• [[最小権限の原則]] — 期限と権限の両方を絞ることで漏えい時の被害を最小化する
• [[CI/CD]] — 固定APIキーが置かれやすい場所であり、OIDCフェデレーションによるキーレス化の主な適用先

Q: 短期クレデンシャルの狙いとして正しいのはどれ?
- [x] 漏えいしても期限切れで自動的に使えなくなり、被害の窓を短くする
- [ ] 認証情報を暗号化して絶対に漏れないようにする
- [ ] パスワードの文字数を短くして覚えやすくする
解説: 「漏れても被害が小さい前提で設計する」のが短期クレデンシャルの考え方です。漏えい自体を防ぐのではなく、漏れたときの有効期間を絞ります。

Q: 長期キーの問題点として本文で挙げられているのはどれ?
- [ ] 有効期限が短すぎて頻繁に再発行が必要になる
- [x] 漏えいしても気づくまで有効なままで、ローテーションも放置されやすい
- [ ] 短期クレデンシャルより発行に時間がかかる
解説: 長期キーは漏えい時に無効化するまで使われ続け、定期ローテーションも手作業で放置されがちという運用上の弱点があります。

Q: OIDCフェデレーションの説明として正しいのはどれ?
- [ ] CIのシークレットに長期アクセスキーを登録して使い回す方式
- [x] CI実行時に発行されるIDトークンを検証し、固定キーなしで期限付き認証情報と交換する方式
- [ ] SSHの公開鍵をクラウドに恒久登録する方式
解説: GitHub Actions などのOIDCフェデレーションは、固定キーを一切置かずにJWT形式のIDトークンを期限付きクレデンシャルへ交換するキーレスの仕組みです。