AWS Security Token Service (STS)
一時的な credential の発行
AssumeRole、AssumeRoleWithWebIdentity、GetSessionToken などの API を通じて一時的な credential（access key、secret、有効期限付きの session token）を発行し、長期の key を使わずに AWS にアクセスできるようにします。
- コスト$ 安い
- 難易度●●●●●
- 未使用でも課金？いいえ
- サーバーレス
- 出題試験SAA · DVA · SOA
たとえるなら当日限り有効で、時間が過ぎると自動的に無効になるゲストパスのようなものです。
いつ使う？
✓ 使うべき場面
クロスアカウントアクセス、フェデレーション、または短期の credential が必要なアプリケーション。
✗ 避けるべき場面
サードパーティのパスワードや API key の保管 → Secrets Manager。
よくある使い方
- 別アカウントへの AssumeRole
- SAML/OIDC IdP からのフェデレーション
- 機密性の高い操作への MFA の強制
料金はいくら？
- 課金方式: 無料です。
「長期アクセスキーを使わないクロスアカウントアクセス」なら IAM ロールと STS AssumeRole、「企業 IdP (SAML) のユーザーが AWS にサインイン」ならフェデレーション (AssumeRoleWithSAML)、「モバイルアプリで Google/Facebook ログイン後に AWS を呼ぶ」なら Cognito を選びます。
よくある質問
IAM ユーザーのアクセスキーではなく STS の一時的な認証情報を使うのはなぜですか?
一時的な認証情報は自動的に失効するため、漏えいしても被害が限定されます。長期のアクセスキーは誰かが削除するまで有効です。そのため AWS 上のアプリケーションには IAM ロールを使い (EC2、Lambda、ECS などは STS 経由で自動的に認証情報を取得します)、人はフェデレーションや IAM Identity Center でサインインします。
AssumeRole はいつ使い、何を設定しますか?
AssumeRole は、ユーザーやサービスが別のロールの権限を引き受けるための操作で、最も一般的なのはクロスアカウントアクセスです。両側の設定が必要で、ロールの信頼ポリシーで呼び出し元を許可し、呼び出し元の ID ポリシーで sts:AssumeRole を許可します。組織外のサードパーティには、confused deputy 問題を避けるため external ID も使います。
STS は外部 ID とのフェデレーションをどうサポートしますか?
AssumeRoleWithSAML は企業の IdP (SAML 経由の Active Directory など) 向け、AssumeRoleWithWebIdentity は Google や Facebook などの Web ID ログイン向けです。Web やモバイルアプリでは、直接呼び出すより Amazon Cognito の利用が推奨されます。いずれも有効期限付きの一時的な認証情報を返します。
関連サービス
SAA-C03 対策
STS は次の対策モジュールで扱っています：