← AWSサービスの内部原理 コース
59. STSは期限付きの鍵の発行所である — AssumeRoleが返す3点セット
前レッスンで「ロールをかぶる」と言ったその瞬間、AWSの内部で何が返ってくるのか——AssumeRoleのレスポンスに詰まった一時認証情報の中身と、なぜそれが「配らない・埋め込まない・取り消さなくていい」を同時に満たすのかを、図で追っていきます。
① AssumeRoleが返すのは3点セット + 有効期限
AssumeRoleRoleArn を指定して要求
Credentials オブジェクトを返す
STS(発行所)その場で動的に生成
AccessKeyId誰か(ID)
ASIA...SecretAccessKey署名鍵(秘密)
wJalr...SessionToken第3の要素
AQoDYXdz...Expiration失効時刻
2019-11-09T13:34:41Z- 公式レスポンス例の <Credentials> は AccessKeyId / SecretAccessKey / SessionToken / Expiration の4フィールド。ドキュメントは「an access key ID, a secret access key, and a security (or session) token」と表現し、"security token" と "session token" は同じものを指す。
- 長期のIAMユーザーアクセスキー(AKIA...で始まる2点セット)との決定的な違いは、SessionTokenという第3の要素と、明示的なExpirationが付くこと。
- AccessKeyIdの接頭辞は公式に規定があり、AKIAは(長期の)アクセスキー、ASIAは一時(AWS STS)アクセスキーIDを示す。ただしASIAのIDは「シークレットアクセスキーとセッショントークンとの組み合わせでのみ一意」とされ、単体では鍵として成立しない(根拠: reference_identifiers.html「Understanding unique ID prefixes」)。
一時認証情報は「2点セット + トークン + 期限」。長期キーが誰か(ID)と署名鍵(秘密)の2点だったのに対し、STSはそこにセッショントークンと失効時刻を足した4点を返す。この2つの追加要素が、以降のすべての利点の源になる。
② 保存しない・動的生成 — だから「配る」問題が消える
長期アクセスキー従来
一時認証情報STS
どこかに保存保存されている
どこにも保存しない保存されていない
埋め込む・配布アプリに配る必要がある
その場で生成要求のたびに作られる
手で無効化revoke を忘れると生き続ける
自動で失効期限が来れば revoke 不要
- 公式の言い回し——「Temporary security credentials are not stored with the user but are generated dynamically and provided to the user when requested」。
- 利点として「You do not have to distribute or embed long-term AWS security credentials with an application」「you do not have to update them or explicitly revoke them when they're no longer needed. After temporary security credentials expire, they cannot be reused」。
これが「配らない・埋め込まない・取り消さなくていい」の3大利点。鍵をどこにも保管しないから盗む対象がなく、要求のたびに作り直すから配布経路もなく、期限が失効を保証するから取り消し操作そのものが不要になる。
③ 期限そのものが安全を保証する — 時限リースの原理
t=0 発行AssumeRole が Expiration を刻む
期限切れ後の要求
t=Expiration失効時刻が到来
もう認識しない"AWS no longer recognizes them"
アクセスも許さない- 「After the credentials expire, AWS no longer recognizes them or allows any kind of access from API requests made with them」。取り消しリストを引く必要はなく、時刻の比較だけで失効が決まる。
- 既習との接続: これはメッセージング編で見た可視性タイムアウトとまったく同じ原理。あそこでもキューは「取り消し通知」を配らず、タイムアウトという期限そのものがメッセージの再配信を保証していた。STSも同じで、期限が来たという事実が安全性を担保し、明示的なrevoke操作を不要にする——認証情報のライフタイムを最小化するというセキュリティの基礎(時限リース)そのもの。
安全性を「取り消しの仕組み」ではなく「期限の経過」で担保する。だからこそ運用に失効管理という重い機構が要らない。
④ DurationSeconds — 15分から12時間、ただし上限は二重にかかる
DurationSecondsセッション長の要求値
ただし実際の上限は…
値の枠下限900秒(15分)〜上限43,200秒(12時間)
未指定時のデフォルトは3,600秒(1時間)ロール側の上限maximum session duration(1〜12時間で管理者が設定)
要求値がこれを超えると操作は失敗する- 公式——「The value specified can range from 900 seconds (15 minutes) up to the maximum session duration set for the role. The maximum session duration setting can have a value from 1 hour to 12 hours」「By default, the value is set to 3600 seconds」「Valid Range: Minimum value of 900. Maximum value of 43200」。
- 要求値が管理者の設定した上限を超えると操作は失敗する——公式の例では「12時間のセッションを要求しても、管理者が maximum session duration を6時間に設定していれば操作は失敗する」。
- 別枠の例外: ロールチェーン(ロールから次のロールをかぶる)ではセッションは最大1時間に制限——「Role chaining limits your AWS CLI or AWS API role session to a maximum of one hour ... if you assume a role using role chaining and provide a DurationSeconds parameter value greater than one hour, the operation fails」。
900秒〜43,200秒(12時間)が値の枠、既定は3,600秒。ただし実効上限はロール側のmaximum session duration(1〜12時間)で頭打ちになり、ロールチェーン時は問答無用で1時間。「短命ほど安全」の原則が、そのまま設定値の設計思想になっている。
⑤ セッショントークン = 署名に必ず添える第3の要素(次回への伏線)
APIを呼ぶとき一時認証情報で要求を組み立てる
これが署名リクエストにどう乗るか
AccessKeyId「誰の要求か」を示す
SecretAccessKey要求に署名する(鍵そのものは送らない)
SessionToken一時セッションが本物である証として要求に必ず添付
長期キーには存在しない第3の要素次回: SigV4署名アルゴリズムを分解する
- Credentialsは「an access key ID, a secret access key, and a security (or session) token」の3点で構成され、一時認証情報を使うAPI呼び出しではこのセッショントークンが要求に添付される(具体的な署名ヘッダー名と署名アルゴリズムの分解は次のSigV4レッスンで扱う)。
- 長期のアクセスキー(2点セット)にはセッショントークンが存在しないため、この第3要素の有無が「一時か長期か」を見分ける実質的な指標になる。
- トークンのサイズについて公式は「The size of the security token that AWS STS API operations return is not fixed. We strongly recommend that you make no assumptions about the maximum size」と明記——固定長を仮定してはいけない。
シークレットアクセスキーが署名鍵、セッショントークンはその署名が一時セッション由来であることを示す添え状。長期キーにはない3つ目の要素で、これがどう署名に組み込まれるかが次回のSigV4の核心になる。
⑥ STSはどこで発行しても、鍵はグローバルに効く
グローバル窓口sts.amazonaws.com(デフォルト)
リージョン窓口sts.<region>.amazonaws.com(近い方が低遅延)
応用: EC2インスタンスロールも同じ仕組み
グローバルに効くリージョンを問わず使える "they work globally"
EC2ロール起動時にインスタンスへ一時認証情報が渡される
長期キーをインスタンスに保存しなくてよく、期限が来れば自動で更新される- 「By default, AWS STS is a global service with a single endpoint at https://sts.amazonaws.com. However, you can also choose to make AWS STS API calls to endpoints in any other supported Region ... No matter which Region your credentials come from, they work globally」。
- EC2について——「you can provide temporary security credentials to your instances when you launch them. These temporary security credentials are available to all applications that run on the instance, so you don't need to store any long-term credentials on the instance」。
発行の窓口(グローバル/リージョナル)は遅延の都合で選べるが、出てきた鍵はどこでも通用する。そしてEC2インスタンスロールも中身はまさにこのAssumeRoleの仕組み——前レッスンで「ロールをかぶる」と呼んだ動作の、実際に返ってくる中身がこの4点セットだった。