AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

1. サービス概要

AWS STS（Security Token Service）は、一時的なセキュリティ認証情報（アクセスキーID・シークレットアクセスキー・セッショントークンのセット）を生成するAWSサービスです。

一時的な認証情報は有効期限付き（15分〜36時間）であり、長期的な認証情報（IAMユーザーのアクセスキー）に比べてセキュリティリスクが低くなります。クロスアカウントアクセス・フェデレーション・EC2上のアプリケーション認証等の幅広いユースケースで使用されます。

2. 主な特徴と機能

2.1 主なSTS APIアクション

• AssumeRole: IAMロールを引き受けて一時的な認証情報を取得。クロスアカウントアクセス・サービスロール・ECS/Lambdaの実行ロール等に使用。最も重要なAPI。
• AssumeRoleWithWebIdentity: OIDC IdP（Cognito・Google・Facebook等）のトークンを使ってロールを引き受ける。CognitoのIDプールはこれを内部で使用。
• AssumeRoleWithSAML: SAMLフェデレーション（Active Directory・Okta等）のアサーションを使ってロールを引き受ける。企業SSO環境でのAWSコンソールアクセスに使用。
• GetSessionToken: IAMユーザーがMFAを使って一時的な認証情報を取得。MFAデバイスによる追加認証が必要なAPIを呼び出す際に使用。
• GetFederationToken: フェデレーションユーザーに一時的な認証情報を発行（最大36時間）。

2.2 クロスアカウントアクセス

最も一般的なSTSの用途。アカウントA（信頼するアカウント）のIAMユーザー/ロールが、アカウントB（信頼されるアカウント）のIAMロールをAssumeRoleして一時的な認証情報を取得。アカウントBのリソースにアクセスできます。

1. アカウントBで「信頼ポリシー」（Trusted Entity = アカウントA）を設定したIAMロールを作成。
2. アカウントAのエンティティに「sts:AssumeRole」を許可するIAMポリシーを付与。
3. アカウントAのエンティティが `aws sts assume-role` を呼び出して一時的な認証情報を取得。

2.3 STSのリージョンエンドポイント

デフォルトはグローバルエンドポイント（sts.amazonaws.com）ですが、レイテンシ低減・STS呼び出しのリージョンに近いエンドポイントを使うためにリージョナルエンドポイントの使用を推奨。

3. アーキテクチャおよび技術要素

1. アプリケーション（EC2/Lambda/ECS）はIAMロールの一時的な認証情報をインスタンスメタデータサービス（IMDS）経由で自動取得（AssumeRoleの明示的な呼び出し不要）。
2. クロスアカウント: IAMロールの信頼ポリシーでアカウント間の信頼を確立→STSがAssumeRoleで一時的な認証情報を発行。
3. フェデレーション: SAML/OIDC IdPがSTSに認証情報を渡す→STSが一時的な認証情報を返す→ユーザーがAWS APIを使用。

4. セキュリティと認証・認可

• 有効期限: 一時的な認証情報は必ず有効期限があり（最小15分〜最大36時間）、有効期限後は無効。長期的な認証情報よりセキュリティリスクが低い。
• 条件キー（Condition Keys）: STSのAssumeRoleにConditionを追加してMFA必須・特定IPからのみ・特定時間帯のみ等のセキュリティポリシーを適用可能。
• CloudTrailでの追跡: すべてのSTS API呼び出しはCloudTrailに記録（どのエンティティがAssumeRoleしたかを追跡）。
• ExternalID: クロスアカウントのAssumeRoleにExternalIdを設定してConfused Deputy Problem（混乱した代理人の問題）を防止。

5. 料金形態

AWS STSは無料です（STS API呼び出し自体には料金がかかりません）。一時的な認証情報を使って実行するAWSサービスの操作に対して通常のAWSサービス料金が発生します。

6. よくあるアーキテクチャ・設計パターン

• クロスアカウントアクセス: 開発/本番アカウントを分離したマルチアカウント構成でSTSクロスアカウントAssumeRoleを使って安全にリソースアクセス。長期IAMキーの配布不要。
• モバイルアプリのAWSアクセス（Cognito）: モバイルアプリ → Cognito Identity Pool → STSのAssumeRoleWithWebIdentity → S3/DynamoDB等のAWSリソースに一時的な認証情報でアクセス。
• 企業SSO（SAML フェデレーション）: 社内AD/Okta → SAMLアサーション → STSのAssumeRoleWithSAML → AWSコンソール/APIに直接ログイン（IAMユーザー不要）。

7. 設定・デプロイ手順（ハンズオン例）

1. アカウントBでIAMロールを作成（信頼ポリシーにアカウントAのルートまたは特定IAMユーザーを指定）。
2. アカウントAのIAMユーザー/ロールにsts:AssumeRole権限を付与（ポリシーのResourceにアカウントBのロールARN）。
3. CLIで実行: aws sts assume-role --role-arn arn:aws:iam::ACCOUNT_B:role/RoleName --role-session-name session1
4. 返ってきたAccessKeyId/SecretAccessKey/SessionTokenを環境変数にセット→アカウントBのリソースに対してAWS CLIコマンドを実行。

8. 試験で問われやすいポイント