AWS STSをSCS視点で完全理解する

この記事はAWS公式ドキュメントを前提に、SCS-C03で問われるSTSの仕様と判断軸をまとめます。

AWS STS、正式にはAWS Security Token Serviceは、一時的なセキュリティ認証情報を発行するサービスです。返ってくる認証情報は、アクセスキーID、シークレットアクセスキー、セッショントークン、有効期限を持ちます。

STSの本質は「一時キーを発行する便利API」ではありません。SCS視点では、STSは 認証済みの主体を、短命で監査可能なAWS権限セッションに変換する境界 です。

まず結論

STSで見るべき軸は5つです。

1. 誰が呼ぶのか
2. どのAPIを呼ぶのか
3. どのロールまたはフェデレーション先へ変換するのか
4. セッションの権限は何で絞られるのか
5. CloudTrail上で誰として追跡できるのか

この5つを見れば、STSの選択肢はほぼ整理できます。

IAM user/roleが別ロールへ
  -> AssumeRole

SAML IdPからAWSロールへ
  -> AssumeRoleWithSAML

OIDC tokenからAWSロールへ
  -> AssumeRoleWithWebIdentity

IAM userのMFA後に一時キー化
  -> GetSessionToken

独自identity brokerが連合ユーザーを作る
  -> GetFederationToken

STSが発行する認証情報

STSのレスポンスには、基本的に次の要素があります。

{
  "Credentials": {
    "AccessKeyId": "ASIA...",
    "SecretAccessKey": "...",
    "SessionToken": "...",
    "Expiration": "2026-05-01T12:00:00Z"
  }
}

ここで重要なのは SessionToken です。一時認証情報では、AccessKeyIdとSecretAccessKeyだけでは不十分です。AWS API署名時にはSessionTokenも含めます。これを忘れると、認証情報は合っているのにリクエストが失敗します。

また、AWSはSTSが返すセッショントークンのサイズを固定だと仮定しないように案内しています。実装では「トークンはこの長さまで」と決め打ちしないことが大事です。

APIごとの使い分け

AssumeRole

AssumeRoleは最重要です。IAM user、IAM role、または既存の一時認証情報を持つrole sessionが、別のIAM roleを引き受けます。

典型例は次の通りです。

• 管理アカウントから本番アカウントの監査ロールを引き受ける
• CI/CDロールがデプロイ先アカウントのロールを引き受ける
• Lambda実行ロールが限定作業用ロールを引き受ける
• 運用者がMFA付きでBreak Glassロールを引き受ける

AssumeRoleでは、呼び出し側に sts:AssumeRole 権限が必要で、引き受け先ロールのtrust policyでも呼び出し側を信頼している必要があります。

AssumeRoleWithSAML

SAML IdPで認証されたユーザーがAWS roleを引き受けるAPIです。企業IdP、Active Directory Federation Services、外部IdPからAWSへ入る場合に使います。

SCSでの読み方は、ユーザー管理をIAM userで増やさず、IdP認証をAWS権限に変換する方式です。SAML assertionに含まれる属性をsession tagsとして使い、ABACへつなげる問題もあります。

AssumeRoleWithWebIdentity

OIDCに基づくWeb Identityからroleを引き受けます。代表例はEKSのIRSA、GitHub ActionsのOIDC、モバイルアプリやWebアプリの外部ID連携です。

ポイントはtrust policyのConditionです。OIDCでは aud や sub の条件が弱いと、想定外のリポジトリ、サービスアカウント、アプリからロールを引き受けられる危険があります。

GetSessionToken

GetSessionTokenは、IAM userの長期認証情報を使い、MFA情報を含む一時認証情報を取得する用途で使います。たとえば「MFA認証済みの場合だけEC2停止を許可したい」という設計です。

公式仕様上、IAM userのGetSessionTokenは15分から36時間まで指定でき、デフォルトは12時間です。root認証情報に基づく場合は最大1時間ですが、rootで使う設計は推奨されません。

GetFederationToken

GetFederationTokenは、独自のidentity brokerがAWS STSフェデレーションユーザーの一時認証情報を発行する用途です。AssumeRoleと違い、ロールを引き受けるというより、連合ユーザーセッションを作るイメージです。

現代的な構成ではSAML/OIDCやIAM Identity Centerを選ぶことが多いため、SCSでは「独自broker」という文脈が出たときに意識します。

セッション期間の考え方

STSのセッション期間はAPIとロール設定で変わります。

最重要の落とし穴はロールチェーンです。

User -> RoleA
RoleA session -> RoleB

このように一時認証情報からさらにAssumeRoleする場合、ロールチェーンになります。ロールチェーンではセッションは最大1時間です。RoleBの最大セッション期間を12時間にしていても、チェーン時に12時間を指定すると失敗します。

SCSでは「長時間のバッチ処理がロールチェーンで失敗する」という形で出ます。この場合、最終ロールを直接引き受ける設計にする、EC2/ECS/Lambdaの実行ロールを使う、または認証経路を見直す判断になります。

Session policyは権限を増やさない

AssumeRole系APIでは、inline session policyやmanaged session policy ARNを渡せます。ここでSCS的に最重要なのは、session policyは権限を追加しないことです。

最終権限 = Role permissions ∩ Session policy

つまり、ロールがS3 ReadOnlyを持っていて、session policyで特定バケットだけ許可すれば、そのセッションは特定バケットに絞られます。しかしロールがS3権限を持っていないのに、session policyでS3許可を書いても使えません。

この性質は、次のユースケースで強力です。

• CI/CDがデプロイ対象リソースだけを操作する
• SaaSが顧客ごとのリソースプレフィックスに限定する
• 一時的な調査セッションを読み取り専用にする
• 本番ロールを引き受けても、チケット単位で操作範囲を絞る

APIにはセッションポリシーやタグを圧縮した内部サイズ制限もあります。PackedPolicySize が100%を超えると失敗するため、大量のタグや長いポリシーを詰め込む設計は避けます。

Session tagsとABAC

Session tagsは、STSでセッションを作るときに渡すキー値です。発行後のリクエストでは aws:PrincipalTag として参照でき、ABACに使えます。

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/ProjectOperator \
  --role-session-name alice-ticket-4832 \
  --tags Key=Project,Value=alpha Key=CostCenter,Value=cc100 \
  --transitive-tag-keys Project

ユースケースは、プロジェクト単位の権限制御です。

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::example-project-bucket/*",
  "Condition": {
    "StringEquals": {
      "s3:ExistingObjectTag/Project": "${aws:PrincipalTag/Project}"
    }
  }
}

注意点は、session tagsを渡すには追加で sts:TagSession が必要になることです。trust policy側で sts:TagSession を許可していないと、AssumeRole自体が失敗します。

SourceIdentityとRoleSessionName

監査で重要なのが RoleSessionName と SourceIdentity です。

RoleSessionNameはassumed-role ARNに現れます。

arn:aws:sts::123456789012:assumed-role/SecurityAuditRole/alice-ticket-4832

SourceIdentityは、元のユーザー識別子をロールチェーン後も追いやすくするための値です。CloudTrailではAssumeRole時のrequestParametersや、その後のservice APIイベントのsessionContextに現れます。

SCSでは「誰がそのロールで操作したか追跡したい」という要件が出たら、RoleSessionName、SourceIdentity、session tags、CloudTrailを見ます。

STS endpointはregionalを使う

AWSはSTSのregional endpoint利用を推奨しています。理由は低レイテンシ、障害影響範囲の限定、冗長性です。

以前の感覚では https://sts.amazonaws.com がグローバルエンドポイントとして語られがちでしたが、現在はデフォルト有効リージョンではグローバルエンドポイントへのリクエスト処理にも変更が入っています。それでも設計上は、ワークロードのリージョンに合わせてregional STS endpointを使うのが基本です。

aws configure set sts_regional_endpoints regional

SCSで「特定リージョン障害の影響を小さくしたい」「レイテンシを下げたい」「オプトインリージョンを使う」と出たら、regional STS endpointが判断材料になります。

実務ユースケース

監査アカウントから全アカウントを読む

Organizations配下の各アカウントに監査用ロールを置き、監査アカウントのロールからAssumeRoleします。セッション名に担当者やチケットIDを入れ、CloudTrailで追えるようにします。

GitHub ActionsからAWSへデプロイする

長期アクセスキーをGitHub Secretsに置くのではなく、OIDCでAssumeRoleWithWebIdentityを使います。trust policyではリポジトリ、ブランチ、environmentをConditionで絞ります。

MFA済みのときだけ危険操作を許す

IAM userがGetSessionTokenでMFA付き一時認証情報を取得し、ポリシー側で aws:MultiFactorAuthPresent を要求します。EC2停止やIAM変更のような操作に使います。

SaaSが顧客AWSにアクセスする

顧客アカウントにロールを作り、SaaSベンダーのAWSアカウントをPrincipalにします。External IDでConfused Deputyを防ぎ、session policyやtagsで操作範囲を絞ります。

SCSの引っかけ

試験直前チェック

• STSの認証情報はAccessKeyId、SecretAccessKey、SessionToken、Expirationを持つ
• SessionTokenのサイズを固定長と仮定しない
• AssumeRoleのsession policyは権限を追加せず、ロール権限を縮小する
• session policyの平文サイズやPackedPolicySizeに注意する
• session tagsはABACに使えるが sts:TagSession が必要
• SourceIdentityはロールチェーン後の追跡に効く
• regional STS endpoint利用が推奨
• role chainingの最大セッションは1時間

参考

• AWS公式: Compare AWS STS credentials
• AWS公式: AssumeRole API
• AWS公式: GetSessionToken API
• AWS公式: AWS STS Regions and endpoints
• AWS公式: Pass session tags in AWS STS
• AWS公式: CloudTrail userIdentity element