AWS STS 完全ガイド v2.0

初心者から実務者向けの包括的解説

AWS STS（Security Token Service） は、一時的なセキュリティ認証情報 を発行するマネージド認証サービスです。AssumeRole・AssumeRoleWithWebIdentity・AssumeRoleWithSAML・GetSessionToken・GetFederationToken API により、短期間（15 分～12 時間）有効な AccessKeyId・SecretAccessKey・SessionToken を発行。クロスアカウントアクセス・フェデレーション・CI/CD・コンテナワークロード・Lambda 実行ロールなど、あらゆる IAM 認証基盤を支える核心サービスです。本ドキュメントは、STS の仕組み・API・ユースケース・ベストプラクティスを体系的に解説する完全ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています：

• セキュリティ初心者向け：一時認証情報とは何か、なぜ必要か
• クラウドアーキテクト向け：クロスアカウント・フェデレーション設計
• DevOps・SRE 向け：OIDC Workload Identity・CI/CD 認証
• 開発者向け：SDK での STS 活用（Python・Node.js・Java）
• セキュリティ管理者向け：長期キー廃止・一時認証情報ポリシー

2025-2026 年の STS エコシステム

• OIDC Federation 強化：Google・GitHub・CircleCI・OCI クレーム検証
• IAM Identity Center 統合：企業 SSO と STS ネイティブ統合
• Source Identity ラベリング：監査ログでのアクショントレーサビリティ向上
• Session Policies 動的生成：AI ベース権限絞り込み
• Workload Identity Federation：EC2・Lambda 外の汎用 OIDC サポート

定義

AWS 公式による定義：

“AWS Security Token Service (AWS STS) is a service that provides temporary security credentials.”

長期的な IAM ユーザーキーより、一時認証情報による Just-In-Time Access Control を実現。

目次

1. 概要
2. STS が解決する課題
3. 主な特徴
4. アーキテクチャ
5. AssumeRole（クロスアカウント）
6. AssumeRoleWithWebIdentity（OIDC Federation）
7. AssumeRoleWithSAML（SAML Federation）
8. GetSessionToken（MFA）
9. GetFederationToken（ユーザーベース）
10. Source Identity・Session Tags
11. Session Policies
12. External ID・信頼ポリシー
13. 主要ユースケース
14. 設定・操作の具体例
15. Workload Identity Federation
16. IAM Identity Center
17. 類似サービス比較
18. ベストプラクティス
19. トラブルシューティング
20. 2025-2026 最新動向
21. 学習リソース
22. 実装例・ロードマップ
23. 実装チェックリスト
24. まとめ

概要

初心者向けメモ： STS は「AWS の一時通行証 発行機構」です。「Alice が Bob というロールを 1 時間使いたい」という要求に対し、STS が「この 1 時間有効な通行証（AccessKey + Token）を使いなさい」と発行。時間経過で自動無効化され、長期キー管理の手間を排除します。

STS は、以下を実現する統合認証・認可プラットフォームです：

STS が解決する課題 {#課題}

1. 長期 IAM キーの漏洩・管理困難

課題：IAM ユーザーキー漏洩 → 無期限アクセス可能 → 侵害被害拡大 STS の解決：短期トークン（1～12 時間）で自動失効、キーローテーション不要

2. クロスアカウント・複雑な権限委譲

課題：Account A のユーザーが Account B のリソース アクセス → IAM ユーザー複製 STS の解決：AssumeRole で Account A からアクセス、Account B ロール経由で委譲

3. 企業 SSO・フェデレーション構築困難

課題：AWS ネイティブ認証だけでは不足、企業 Active Directory・SAML 連携必要 STS の解決：SAML Federation で企業 IdP から直接 AWS アクセス

4. CI/CD・マイクロサービス認証

課題：CI/CD パイプラインに長期キー埋め込み → セキュリティリスク STS の解決：OIDC Federation で GitHub Actions・GitLab CI から一時トークン取得

主な特徴 {#特徴}

1. 複数の発行メカニズム

【AssumeRole】
  ├─ クロスアカウント + ロール引き受け
  └─ 最も一般的

【OIDC Federation】
  ├─ GitHub Actions・Google Cloud・CircleCI
  └─ クレデンシャル埋め込み不要

【SAML Federation】
  ├─ 企業 IdP（Active Directory・Okta）
  └─ 企業 SSO 統合

【MFA ベース】
  ├─ GetSessionToken + MFA 確認
  └─ デバイスセキュリティ層

【ユーザーベース】
  └─ GetFederationToken で細粒度制御

2. トークン有効期限自動管理

トークン発行
  ├─ 有効期限: 発行時に指定（15 分～12 時間）
  └─ 例：2026-04-26T16:00:00Z に無効化
  
自動失効: プロセスが失効トークン使用 → AccessDenied
  → 新トークン要求 → 再発行

3. Session Token の 3 つの構成要素

AccessKeyId: AKIA... (20 文字)
  └─ 一時的なアクセスキー ID

SecretAccessKey: ...(40 文字)
  └─ 一時的なシークレットキー

SessionToken: AQoDY... (バイナリ Base64 エンコード)
  └─ セッションの証明、署名確認用

アーキテクチャ {#アーキテクチャ}

【図1】STS フロー全体図

graph LR
    subgraph "Account A"
        User["IAM User/Role"]
        App["Application"]
    end

    subgraph "STS Service"
        Assume["AssumeRole API"]
        OIDC["OIDC Federation"]
        SAML["SAML Federation"]
        MFA["MFA + GetSessionToken"]
    end

    subgraph "Account B"
        Role["Target Role"]
        Resource["S3/RDS/EC2"]
    end

    subgraph "External IdP"
        GitHub["GitHub Actions<br/>OIDC Provider"]
        Okta["Okta<br/>SAML IdP"]
    end

    User -->|AssumeRole| Assume
    App -->|OIDC Token| OIDC
    GitHub -->|ID Token| OIDC

    User -->|SAML Assertion| SAML
    Okta -->|SAML Response| SAML

    User -->|MFA| MFA

    Assume -->|Temporary Credentials| Role
    OIDC -->|Temporary Credentials| Role
    SAML -->|Temporary Credentials| Role
    MFA -->|Temporary Credentials| User

    Role -->|API Call| Resource

【図2】AssumeRole フロー詳細

sequenceDiagram
    participant AccountA as Account A<br/>IAM User
    participant STS as AWS STS
    participant AccountB as Account B<br/>Target Role
    participant Resource as Resource<br/>S3/RDS/EC2

    AccountA->>STS: 1. AssumeRole Request<br/>(RoleArn, DurationSeconds)
    STS->>AccountB: 2. Validate Trust Policy<br/>Can AccountA assume?
    AccountB-->>STS: OK
    STS-->>AccountA: 3. Return Temporary Credentials<br/>(AccessKeyId, SecretAccessKey, SessionToken)

    AccountA->>Resource: 4. API Call with SessionToken<br/>s3:GetObject

    Resource->>Resource: 5. Validate SessionToken<br/>Signature Check

    Resource-->>AccountA: 6. Response 200 OK

AssumeRole（クロスアカウント） {#assumerole}

仕組み

Account A のユーザーが、Account B のロール を引き受け、Account B リソースにアクセス。

【Account A 側】
IAM User
  └─ AssumeRole 権限: Account B の特定ロール

【Account B 側】
Target Role
  └─ Trust Policy で Account A を信頼
     "Principal": { "AWS": "arn:aws:iam::AccountA:root" }

実装例

# Account A から Account B ロール引き受け
aws sts assume-role \
  --role-arn arn:aws:iam::AccountB:role/CrossAccountRole \
  --role-session-name alice-session \
  --duration-seconds 3600

# 出力：
# {
#   "Credentials": {
#     "AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
#     "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
#     "SessionToken": "AQoDYXdzEJr...",
#     "Expiration": "2026-04-26T17:00:00Z"
#   }
# }

# 取得した認証情報を環境変数に設定
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_SESSION_TOKEN="AQoDYXdzEJr..."

# Account B リソースにアクセス
aws s3 ls --region us-east-1

AssumeRoleWithWebIdentity（OIDC Federation） {#oidc}

仕組み

外部 OIDC プロバイダー（GitHub・Google・CircleCI）から ID トークンを取得し、STS に提示して AWS 認証情報を取得。

【フロー】
GitHub Actions
  ├─ ワークフロー実行
  └─ GitHub OIDC プロバイダーから ID トークン取得

AWS
  ├─ STS に ID トークン提示
  └─ trust-policy で GitHub を信頼 → OK
  └─ 一時認証情報発行

GitHub Actions での実装

name: AWS S3 Upload with OIDC

on:
  push:
    branches: [main]

permissions:
  id-token: write  # OIDC トークン要求権限

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
          aws-region: us-east-1
      
      - name: Upload to S3
        run: |
          aws s3 cp ./artifact.zip s3://my-bucket/

信頼ポリシー（AWS 側）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:myorg/myrepo:ref:refs/heads/main"
        }
      }
    }
  ]
}

2025 年新機能：ID プロバイダー特定クレーム検証

{
  "Condition": {
    "StringEquals": {
      "github.com:aud": "sts.amazonaws.com",
      "google.com:sub": "user@example.com",
      "circleci.com:org_id": "12345678"
    }
  }
}

Google・GitHub・CircleCI・OCI 各プロバイダーの特定クレーム（aud・sub・org_id 等）で細粒度検証。

AssumeRoleWithSAML（SAML Federation） {#saml}

仕組み

企業 IdP（Active Directory・Okta・PingFederate）が SAML Assertion を発行し、STS に提示。

【フロー】
ユーザー
  └─ 企業 IdP にログイン

企業 IdP
  └─ SAML Assertion 生成（ユーザー情報・グループ含む）

AWS STS
  ├─ SAML Assertion 検証（署名確認）
  └─ ロール・セッション生成

Okta との統合例

# Okta から SAML Assertion 取得（オフライン）
curl -X POST https://tenant.okta.com/api/v1/authn \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{
    "username": "user@example.com",
    "password": "password",
    "options": {
      "warnBeforePasswordExpired": true
    }
  }'

# SAML Assertion → STS に提示
aws sts assume-role-with-saml \
  --role-arn arn:aws:iam::123456789012:role/OktaSAMLRole \
  --principal-arn arn:aws:iam::123456789012:saml-provider/Okta \
  --saml-assertion <base64-encoded-assertion>

GetSessionToken（MFA） {#getsessiontoken}

仕組み

MFA デバイスで認証後、一時トークン発行。高権限オペレーションの追加セキュリティ層。

# MFA シリアル番号を指定して一時トークン要求
aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 3600

# 出力：一時認証情報（MFA 確認済み）

ユースケース

【長期キーの代わり】
IAM User で長期キーを生成しない
  └─ GetSessionToken で MFA 確認後のトークン のみ使用

【高権限操作の保護】
ルートアカウント操作
  └─ MFA + GetSessionToken で強化
  
【監査ログの分かりやすさ】
CloudTrail で「mfa_authenticated: true」のマーク
  └─ MFA を経た操作を明確区別

GetFederationToken（ユーザーベース） {#getfederationtoken}

仕組み

IAM ユーザーが、カスタムセッションポリシー付きの一時トークンを生成。

# カスタムポリシー付きトークン生成
aws sts get-federation-token \
  --name alice-session \
  --policy file://session-policy.json \
  --duration-seconds 3600

# session-policy.json（S3 読み取り限定）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

AssumeRole との違い

【GetFederationToken】
└─ IAM ユーザー自身が権限制限したトークン生成
   └─ アプリケーションに配布（一時的）

【AssumeRole】
└─ ロール を引き受け、別アカウント・リソース アクセス
   └─ クロスアカウント・権限昇格用

Source Identity・Session Tags {#sourceid}

Source Identity

一時認証情報を誰が生成したかを CloudTrail ログに記録。

aws sts assume-role \
  --role-arn arn:aws:iam::AccountB:role/CrossAccountRole \
  --role-session-name alice-session \
  --source-identity alice \
  --duration-seconds 3600

# CloudTrail ログに記録
# "sourceIdentity": "alice"

Session Tags

セッションにメタデータ付与。ポリシーで条件付け制御可能。

aws sts assume-role \
  --role-arn arn:aws:iam::AccountB:role/CrossAccountRole \
  --role-session-name alice-session \
  --tags Key=Department,Value=Engineering Key=CostCenter,Value=1234

Session Policies {#sessionpolicies}

概要

AssumeRole・AssumeRoleWithWebIdentity 時に、ロールの権限を さらに絞り込む ポリシーを指定。

aws sts assume-role \
  --role-arn arn:aws:iam::AccountB:role/FullAccessRole \
  --role-session-name alice-limited \
  --policy file://session-policy.json

# session-policy.json（S3・特定バケットのみ）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::restricted-bucket/*"
    }
  ]
}

ポリシー評価ロジック

AssumeRole → Role Trust Policy OK
        ↓
Session Policy との AND 条件（AND Logic）
        ↓
最終的な権限: Role Policy ∩ Session Policy

External ID・信頼ポリシー {#externalid}

External ID とは

クロスアカウントアクセス時、Account A が外部パーティー（第三者）を信頼する場合、盗まれた認証情報からのアクセスを防ぐための 追加認証鍵。

【シナリオ】
Account A（顧客）が
Account B（SaaS ベンダー）にアクセス権を委譲

盗まれた Account B 認証情報 × Account A リソース不正アクセス防止
  → External ID として秘密鍵を指定
  → Account B から AssumeRole 時に External ID も提示（マッチ必須）

実装例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/SaaS-Provider-Role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "7a1d5-3b9c-4f2e"  # 秘密の External ID
        }
      }
    }
  ]
}

SaaS ベンダーが AssumeRole 時：

aws sts assume-role \
  --role-arn arn:aws:iam::AccountA:role/SaaSProviderRole \
  --role-session-name saas-session \
  --external-id "7a1d5-3b9c-4f2e"  # External ID 提示

主要ユースケース {#usecases}

1. クロスアカウント監査：スタンドアロン監査アカウントから全メンバーアカウント監査
2. GitHub Actions CI/CD：OIDC Federation で長期キー埋め込み排除
3. 企業 SSO：Active Directory・Okta から AWS コンソール・API アクセス
4. ハイブリッド環境：オンプレミス + AWS リソース統一認証
5. マイクロサービス：ECS/Lambda ロール で自動トークン取得
6. パートナー統合：第三者アプリケーション （SaaS）への安全な委譲
7. Lambda 実行ロール：Lambda が S3・DynamoDB にアクセス（自動トークン）

設定・操作の具体例 {#cli}

1. クロスアカウント AssumeRole

# Account B でロール作成・信頼ポリシー設定
aws iam create-role \
  --role-name CrossAccountRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {"AWS": "arn:aws:iam::AccountA:root"},
        "Action": "sts:AssumeRole"
      }
    ]
  }' \
  --region us-east-1

# Account A ユーザーに AssumeRole 権限付与
aws iam put-user-policy \
  --user-name alice \
  --policy-name AssumeRolePolicy \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::AccountB:role/CrossAccountRole"
      }
    ]
  }'

# Account A から AssumeRole
aws sts assume-role \
  --role-arn arn:aws:iam::AccountB:role/CrossAccountRole \
  --role-session-name alice-session

2. OIDC Provider 設定（GitHub）

# OIDC Provider 作成
aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --client-id-list sts.amazonaws.com \
  --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1

# ロール作成（GitHub OIDC 信頼）
aws iam create-role \
  --role-name GitHubActionsRole \
  --assume-role-policy-document file://github-trust-policy.json

3. Lambda 実行ロール自動トークン取得

import boto3

# Lambda 実行ロール で自動的にトークン取得
# 環境変数から認証情報読み込み
s3 = boto3.client('s3')
response = s3.list_buckets()
print(response)

Workload Identity Federation {#workload}

概要

従来は EC2 IAM Role だけだったが、Kubernetes・GitHub Actions・Google Cloud 等の外部ワークロードから、OIDC Federation で AWS リソースアクセス可能に。

【従来】
EC2 Instance Profile
  └─ EC2 のみ IAM Role 自動取得

【Workload Identity Federation】
GitHub Actions / GitLab CI / Google Cloud / Kubernetes
  └─ OIDC Token → STS AssumeRoleWithWebIdentity
  └─ 一時認証情報取得
  └─ AWS リソースアクセス

IAM Identity Center {#identitycenter}

概能

IAM Identity Center は STS を内部で活用し、企業 SSO からの AWS アクセスを簡素化。

【従来】
Active Directory
  → SAML → STS AssumeRoleWithSAML
  → 設定複雑

【IAM Identity Center】
Active Directory
  → SCIM 統期
  → 自動ロール割り当て
  → SSO ポータル
  → 内部で STS AssumeRole

類似サービス比較 {#comparison}

ベストプラクティス {#bestpractices}

✅ 推奨

✓ 長期 IAM キー廃止、STS トークンに統一
✓ AssumeRole は External ID と共に使用
✓ Session Policy で権限最小化
✓ MFA + GetSessionToken で高権限操作保護
✓ CloudTrail で STS API すべて ログ記録
✓ Source Identity でトレーサビリティ確保
✓ OIDC Federation で CI/CD にキー埋め込み排除

❌ アンチパターン

× 長期 IAM キーを CI/CD パイプラインに埋め込み
× AssumeRole を External ID なしで信頼
× Session Policy なしの無制限委譲
× トークン有効期限を上限（12 時間）に設定
× CloudTrail ロギングなし

トラブルシューティング {#troubleshooting}

2025-2026 最新動向 {#latest}

1. OIDC Federation マルチプロバイダー対応：Google・GitHub・CircleCI・OCI クレーム検証統一
2. IAM Identity Center 統合深化：STS AssumeRole が完全に IAM Identity Center に統合
3. AI ベース Session Policy 生成：操作パターン分析で権限自動提案
4. CloudTrail Insights で異常検知：STS トークン乱用検出
5. Workload Identity Federation 拡張：Kubernetes・OpenShift・Nomad ネイティブサポート

学習リソース・参考文献 {#resources}

公式ドキュメント

1. AWS STS API Reference
2. AWS STS User Guide
3. Assuming an IAM Role
4. Web Identity Federation
5. SAML Federation
6. AWS CloudTrail User Guide
7. IAM Identity Center
8. OIDC Specification

OSS・ベンダー資料

1. HashiCorp Vault
2. Okta SAML Integration
3. GitHub Actions OIDC
4. Google Cloud Workload Identity

実装例・ロードマップ {#roadmap}

Week 1-2：セットアップ

• Day 1-3: OIDC Provider 設定（GitHub）
• Day 4-7: AssumeRole・信頼ポリシー構築
• Day 8-10: Session Policy テスト
• Day 11-14: IAM Identity Center 統合（オプション）

Week 3-4：本運用

• Day 15-17: 既存長期キー廃止計画
• Day 18-21: CI/CD パイプライン OIDC 統合
• Day 22-28: CloudTrail 監視・アラート設定

実装チェックリスト {#checklist}

【基本セットアップ】
☐ OIDC Provider 作成（GitHub・Google・等）
☐ IAM ロール作成・信頼ポリシー設定
☐ Session Policy テンプレート準備
☐ CloudTrail ロギング有効化

【クロスアカウント】
☐ Account B ロール作成
☐ Account A ユーザー AssumeRole 権限
☐ External ID 設定・共有

【OIDC Federation】
☐ OIDC Provider Thumbprint 確認
☐ GitHub Actions 設定
☐ CI/CD パイプライン テスト

【本運用】
☐ 長期キー廃止スケジュール
☐ CloudTrail Alert 設定
☐ MFA + GetSessionToken 運用開始
☐ 監視ダッシュボード構築

まとめ

AWS STS は、短期認証情報による Just-In-Time Access Control の核心サービスです。AssumeRole・OIDC Federation・MFA・Session Policies により、長期キーのセキュリティ課題を解決し、クロスアカウント・企業 SSO・CI/CD・マイクロサービスにおける柔軟で安全な認証基盤を構築。IAM セキュリティポスチャーの最重要ピースです。

核心ポイント

1. 短期トークン：15 分～12 時間の自動失効で漏洩リスク低減
2. 複数発行メカニズム：AssumeRole・OIDC・SAML で多様なシーン対応
3. 権限最小化：Session Policy で権限さらに絞り込み
4. External ID：クロスアカウント時の追加セキュリティ層
5. CI/CD 統合：OIDC Federation でキー埋め込み排除

最終更新：2026-04-26
バージョン：v2.0