AWS STS と IAM ロールによる一時認証

AWS Security Token Service（AWS STS）は、AWSリソースへアクセスするための一時的なセキュリティ認証情報を発行するサービスです。アプリケーションや利用者に長期間有効なアクセスキーを配り続ける代わりに、必要な主体がIAMロールを引き受け、必要な期間だけ使える認証情報を取得できます。

一時認証情報を使うと、認証情報の有効期間を限定できます。仮に値が漏れても、長期アクセスキーを失効・ローテーションするまで使われ続ける状況に比べ、悪用できる時間を短くできます。ただし、一時認証情報も期限までは有効な秘密情報です。ログやソースコードへ記録せず、許可範囲を必要最小限にし、漏えい時には関連するセッションを失効させるなど適切に対応します。

長期認証情報と一時認証情報

IAMユーザーのアクセスキーは、利用者が無効化・削除するまで有効な長期認証情報です。アプリケーションの設定ファイルやサーバーに固定してしまうと、保管場所・配布先が増え、ローテーションのたびに更新する負担も生じます。

STSが発行する一時認証情報は、あらかじめ定められたセッション期限を持ちます。期限を過ぎると認証情報は無効になり、再利用できません。認証情報は固定ユーザーの永続的なアクセスキーとして保存して使うものではなく、ロール引き受けなどの要求に応じて動的に取得します。アプリケーションは利用可能な認証情報を安全に保持し、有効期限が近づいたら新しいものを取得する仕組みを使います。

比較	IAMユーザーのアクセスキー	STSの一時認証情報
有効期間	明示的に無効化・削除するまで有効	セッション期限まで有効
認証情報の管理	利用者が発行・保管・ローテーションする	STSが要求に応じて発行し、期限後に失効する
主な用途	長期的な主体のプログラムアクセスなど、必要性を検討した用途	IAMロール、フェデレーション、短時間の委任アクセス
漏えい時の考え方	無効化・削除や置き換えが必要	利用可能時間は期限で制限されるが、期限前の悪用対策は必要

AWSでは、アプリケーションやAWSサービスに権限を与える際、長期アクセスキーを直接埋め込むより、IAMロールと一時認証情報を使用する設計が基本です。実行環境に応じて、EC2インスタンスプロファイル、Lambda実行ロール、ECSタスクロールなどから認証情報を取得できます。

一時認証情報を構成する3つの値

STSの一時認証情報には、次の3つが含まれます。

1. Access key ID：アクセスキーID。認証情報を識別する値。
2. Secret access key：シークレットアクセスキー。署名計算に用いる秘密の値。
3. Session token：セッショントークン。一時認証情報であることを示し、AWSへの要求に含める値。

これらの値と、有効期限を示す Expiration がSTSの応答に含まれます。API要求では3つを正しく組み合わせる必要があり、セッショントークンを省くと認証できません。AWS SDKやAWS CLIの標準的な認証情報プロバイダーを使うと、実行環境のロール認証情報を取得・更新する処理をアプリケーションで個別に実装せずに済みます。

一時認証情報は**認証（誰として呼び出すか）**を可能にしますが、それだけで任意のAWS操作を許可するわけではありません。実行できる操作は、引き受けたロールのポリシー、セッションポリシー、権限境界、組織ポリシー、リソースポリシーなどの評価で決まります。

IAMロールを引き受ける

IAMロールは、ユーザーやAWSサービスなどが一時的に使用する権限の集合です。IAMユーザーのように長期アクセスキーを直接持つ主体とは異なり、ロール自体に永続的なアクセスキーはありません。許可された主体がロールを引き受けると、STSがロールセッションを作り、そのセッションに対応する一時認証情報を返します。

ロールには、意味の異なる二種類のポリシーが関係します。

設定	答える問い	例
信頼ポリシー（trust policy）	どの主体がこのロールを引き受けられるか	特定のアカウントのデプロイ担当ロール、Lambdaサービスなど
権限ポリシー（permissions policy）	ロールを引き受けたセッションで何ができるか	指定したS3バケットから成果物を読む

信頼ポリシーはロールに付属するリソースベースポリシーです。信頼ポリシーに許可があるだけでは、ロールを引き受けた後のAWS API操作は許可されません。逆に権限ポリシーが十分でも、信頼されている主体でなければロールセッションを取得できません。

IAMユーザーや別のIAMロールが AssumeRole APIを呼び出す場合は、通常、次の二つの許可が必要です。

1. 呼び出し元のアイデンティティベースポリシーが、対象ロールのARNに対する sts:AssumeRole を許可する。
2. 対象ロールの信頼ポリシーが、呼び出し元のアカウントまたはプリンシパルを信頼し、ロール引き受けを許可する。

要求がこの条件を満たすと、STSはロールセッション用の一時認証情報を返します。以降のAWS API呼び出しでは、その認証情報で署名し、引き受けたロールの権限に基づいて認可されます。セッションポリシーを指定してロールセッションの権限を絞ることもできますが、セッションポリシーはロールの権限を拡張するものではありません。

セッションの有効期間

ロールセッションの期間は、STS APIに指定するセッション時間とロール側の最大セッション期間などに従います。IAMロールでは最大セッション期間を設定でき、一般には1時間から最大12時間の範囲で設定します。実際の要求可能時間は、使用するSTS API、呼び出し元の種類、ロールチェーンの有無などの条件に従うため、要件とAPI仕様を確認してください。

すでにロールを引き受けたセッションの認証情報でさらに別のロールを引き受ける操作を**ロールチェーン（role chaining）**と呼びます。ロールチェーンではセッション時間が最大1時間に制限されます。ロールの最大セッション期間を長く設定していても、この上限は回避できません。

クロスアカウントのロール引き受け

別のAWSアカウントのリソースを扱う際は、対象アカウントにアクセス用ロールを作り、元のアカウントの主体がそのロールを引き受ける方式がよく使われます。元のアカウントにある利用者ごとに、対象アカウント側でIAMユーザーと長期キーを作る必要はありません。

たとえば、開発アカウントのリリース担当ロールが、運用アカウントにある限定されたデプロイ用バケットへ成果物を配置するケースを考えます。運用アカウントに ArtifactPublisher ロールを作成し、信頼ポリシーで開発アカウントの指定ロールを信頼します。開発アカウント側では、リリース担当ロールのポリシーに、運用アカウントの ArtifactPublisher を対象とした sts:AssumeRole を許可します。対象ロールの権限ポリシーは、必要なバケットと操作だけを許可します。

クロスアカウント引き受けの手順

1. 運用アカウントに、必要なAWS操作を行うIAMロールを作る。
2. ロールの信頼ポリシーで、開発アカウント全体または必要な特定プリンシパルだけを信頼する。
3. 開発アカウント側の呼び出し元ロールに、対象ロールARNに対する sts:AssumeRole を許可する。
4. 呼び出し元がSTSの AssumeRole APIを呼び出し、必要に応じてセッション名やセッション時間を指定する。
5. STSから一時認証情報を受け取り、その認証情報で運用アカウントのリソースへ要求を送る。
6. 運用アカウントのロールに付与された権限と、リソース側のポリシーや各種制限に基づいて操作が認可される。

この方式では、ロールはアクセス先のアカウントに存在し、ロールセッションは呼び出し元がそのロールを引き受けることで得られます。呼び出し元の権限が自動的にロールへ加算されるわけではありません。ロールセッションで有効な権限は、引き受け先ロールの権限を基礎として評価されます。

なお、アカウントBのロールを引き受けた後で同アカウントのリソースにアクセスするケースと、ロールを引き受けずに別アカウントのリソースポリシーから直接アクセスを許可するケースは別の認可パターンです。後者ではリソースポリシーに加えて呼び出し元側の許可も必要になることがあります。設問では「先にロールを引き受ける構成か」「リソースに直接クロスアカウント許可を設定する構成か」を見分けます。

CLIから一時認証情報を利用する

AWS CLIの sts assume-role コマンドを実行すると、許可されたロールについてSTSから一時認証情報を取得できます。以下は架空のアカウントIDとロール名を使った呼び出し例です。

aws sts assume-role \
  --role-arn arn:aws:iam::444455556666:role/ArtifactPublisher \
  --role-session-name release-job-2026

応答には Credentials として AccessKeyId、SecretAccessKey、SessionToken、Expiration が含まれます。この一時認証情報を使ってAWS CLIやSDKからアクセス先のリソースを操作します。CLIでは、用途ごとに名前付きプロファイルと role_arn / source_profile を設定して認証情報取得を委譲する方法や、環境変数を一時的に利用する方法があります。

環境変数で指定する場合は、次の3つをそろえます。

export AWS_ACCESS_KEY_ID="一時アクセスキーID"
export AWS_SECRET_ACCESS_KEY="一時シークレットアクセスキー"
export AWS_SESSION_TOKEN="一時セッショントークン"

値をシェル履歴、CIログ、ソース管理、共有端末の設定ファイルなどへ不用意に残さないでください。期限を過ぎれば同じ値では操作できません。手動で値をコピーする運用より、AWS CLIのロールプロファイルやSDKの認証情報プロバイダーを使い、更新を自動化する方が安全で管理しやすくなります。

外部IDプロバイダーとフェデレーション

アプリケーション利用者や従業員がすでに社内ディレクトリや外部IDプロバイダー（IdP）で認証されているなら、利用者一人ずつのIAMユーザーを作らず、フェデレーションによってAWSへのアクセスを与えられます。外部で本人確認を行い、AWSではIAMロールを通して権限を管理し、STSの一時認証情報でAWS APIを呼び出す考え方です。

SAML 2.0

企業のIdPがSAML 2.0に対応している場合、IdPとAWSの間に信頼関係を設定し、認証済み利用者がAWSへフェデレーテッドアクセスできます。AWS Management Consoleへのシングルサインオンや、AWS APIへのプログラムアクセスに利用できます。SAMLアサーションを使うフローでは、STSの AssumeRoleWithSAML などを通じて、信頼ポリシーで許可されたIAMロールの一時認証情報を取得します。

OpenID Connect（OIDC）とWeb ID

公開Web IDプロバイダーやOIDC互換IdPで認証された主体には、OIDCフェデレーションによってIAMロールを引き受けさせる構成があります。信頼ポリシーでは、信頼するOIDCプロバイダーとトークンの条件（たとえば対象クライアントや対象者）を適切に制限します。WebアプリケーションにAWSの長期アクセスキーを埋め込むのではなく、検証されたIDトークンをもとにSTSから一時認証情報を取得させます。

Amazon Cognitoを使うモバイル／Webアプリ

モバイルアプリやブラウザアプリのユーザーにAWSリソースへの限定アクセスが必要な場合、Amazon Cognitoを利用する方法があります。Cognito User Poolsはユーザー認証を担い、Identity Poolsは認証された利用者やゲストにAWS認証情報を提供するフェデレーションの役割を担います。Identity Poolに関連付けるIAMロールの権限を、ユーザーが必要とする操作とリソースだけに絞ります。

この設計では、利用者の認証情報やアプリケーション固有のセッション状態・ユーザーデータを、要件に応じてDynamoDBなどへ保存する場合があります。しかし、DynamoDBにユーザーデータを置くだけでAWSの認証や認可が成立するわけではありません。利用者の本人確認、ロールの引き受け、一時認証情報の権限設定はそれぞれ適切な仕組みで行います。

フェデレーション処理の概略

1. 利用者は企業IdP、OIDCプロバイダー、またはCognitoなどで認証を受ける。
2. アプリケーションまたは認証フローが、認証結果を使ってSTSに一時認証情報を要求する。
3. STSはロールの信頼ポリシーと要求内容を評価し、許可された場合に期限付きの認証情報を返す。
4. 利用者側のアプリケーションは、その認証情報で許可されたAWS APIだけを呼び出す。
5. 期限が近づいたら、認証・フェデレーションの手順に従って新しい認証情報を取得する。

フェデレーションは、外部で認証されたからAWSのすべての操作が可能になる仕組みではありません。認証された利用者が引き受けられるロールを信頼ポリシーで制御し、ロールの権限ポリシーでAWS上の操作範囲を制限します。

コンソールのSwitch Role

**Switch Role（ロールの切り替え）**は、AWS Management Consoleでログイン中の利用者が、現在のコンソールセッションからIAMロールの権限へ一時的に切り替える操作です。これはSTSの AssumeRole をコンソールから利用しやすくするためのユーザーインターフェイスと捉えられます。

切り替え後、元のユーザー権限とロール権限は合算されません。ロールを使用している間は、原則としてそのロールセッションに付与された権限で作業します。元のユーザーがEC2を操作できても、切り替え先ロールにその権限がなければ、ロール利用中にEC2操作はできません。ロールから元のセッションへ戻ると、元の権限が再び有効になります。

一人の利用者が、日常業務用の権限と、監査・デプロイ・障害対応など限定された職務向けの権限を使い分ける用途に適しています。同一アカウント内の切り替えだけでなく、別アカウントに用意されたロールへのクロスアカウント切り替えもできます。

クロスアカウントのSwitch Role設定

クロスアカウントでは、アクセスされるアカウントに対象ロールを作り、そのロールの信頼ポリシーでアクセス元アカウントの主体を信頼します。アクセス元アカウントでは、実際に切り替えるユーザーまたはロールへ、対象ロールARNに対する sts:AssumeRole を許可します。信頼ポリシーだけ、または呼び出し元ポリシーだけを設定しても通常は不十分で、双方の条件が成立していることを確認します。

利用者は対象アカウントID（またはアカウントエイリアス）とロール名を指定して切り替えます。ロールにパスが設定されている場合、コンソールではパスを含む完全なロール名が必要です。操作終了後は「Switch back」で元のセッションに戻ります。ルートユーザーはコンソールのSwitch Roleを利用できず、ExternalId を必要とするロールもコンソールのSwitch Roleではなく、ExternalId を指定できるSTS APIから引き受ける必要があります。

コンソールのロールセッション時間はロールの最大セッション期間や元のログインセッションの残り時間などの制約を受けます。さらに、すでに引き受けたロールの認証情報から別のロールを引き受けるロールチェーンでは、セッション時間は最大1時間です。

STS・ロール利用時の確認ポイント

ロール引き受けや AccessDenied の問題を調べる場合は、次の順に確認すると原因を切り分けやすくなります。

1. 実際の呼び出し元は誰か：IAMユーザー、IAMロール、ロールセッション、SAML/OIDCフェデレーテッド主体、AWSサービスのいずれかを特定する。
2. 対象ロールはどのアカウントにあるか：同一アカウントかクロスアカウントか、ロールARNに誤りがないかを確認する。
3. 引き受け許可が両側にあるか：呼び出し元の sts:AssumeRole 許可と、ロールの信頼ポリシーのPrincipal・Conditionを照合する。
4. ロールセッションに必要な操作権限があるか：権限ポリシー、セッションポリシー、権限境界、SCPなどを確認する。
5. 一時認証情報を正しく渡しているか：アクセスキーID・シークレットアクセスキー・セッショントークンの3つがそろい、期限内か確認する。
6. ロールチェーンやセッション時間の制約に抵触していないか：最大セッション期間やSTS APIごとの制約を確認する。
7. リソース側にも許可が必要か：クロスアカウントリソースへの直接アクセスなど、ロール引き受け以外の認可要件がある構成かを区別する。

信頼ポリシーのPrincipalをアカウント全体に広げると、そのアカウント内で別途許可を得た主体が対象になる可能性があります。可能な範囲で特定ロールや条件に絞り、セッション名や SourceIdentity を使った監査上の識別も検討します。最小権限と追跡可能性を両立する設定が重要です。

DVA試験で押さえるポイント

• IAMユーザーのアクセスキーは長期認証情報、STSが発行する値は期限付きの一時認証情報である。
• 一時認証情報はアクセスキーID、シークレットアクセスキー、セッショントークンの3つで構成される。期限を示す値も確認する。
• 信頼ポリシーは「誰がロールを引き受けられるか」、権限ポリシーは「引き受けた後に何を実行できるか」を定義する。
• IAM主体による AssumeRole では、呼び出し元の sts:AssumeRole 許可と、引き受け先ロールの信頼ポリシーの双方を確認する。
• クロスアカウントでは、アクセス先アカウントにロールを作成し、アクセス元の主体を信頼する。呼び出し元にも対象ロールを引き受ける許可が必要。
• STSの一時認証情報を得ただけでは、全AWS操作が許可されるわけではない。引き受けたロールの実効権限が操作範囲を決める。
• SAML、OIDC、Cognitoなどは外部認証をAWSロールに結び付けるフェデレーションの選択肢であり、外部認証とAWS上の認可は別に設計する。
• Switch Roleは元の権限と切り替え先ロールの権限を合算しない。切り替え中はロールの権限を使い、戻ると元のセッションへ戻る。
• ロールチェーンではセッション期間が最大1時間に制限される。
• 長期アクセスキーをアプリケーションへ固定せず、実行環境のIAMロールとSDK／CLIの認証情報プロバイダーを使う。

AWS公式ドキュメント

• AWS STS API Reference
• 一時的なセキュリティ認証情報
• IAMロールの用語と概念
• ロール切り替えに必要な権限
• コンソールでIAMロールに切り替える
• 外部認証された利用者のフェデレーション
• IAMロールを引き受けるための権限