概要
AWS 環境で複数のアカウントを運用する場合、あるアカウントのユーザーが別のアカウントのリソースにアクセスする必要が生じることがあります。アカウントごとに IAM ユーザーを作成して長期的な認証情報を配布する方法では、認証情報の管理負荷が高く、漏洩リスクも増大します。
AWS Security Token Service(AWS STS)は、IAM ユーザーやフェデレーションユーザーに対して一時的な認証情報(一時的なアクセスキー、シークレットキー、セッショントークン)を発行するサービスです。一時的な認証情報には有効期限があり、期限が切れると自動的に無効化されるため、長期的な認証情報に比べてセキュリティリスクが低減されます。
本記事では、STS の基本概念を理解し、AssumeRole によるクロスアカウントアクセスの設定と実行を体験します。

この記事のメリット
- AWS STS の仕組みと一時的な認証情報の特徴を理解できる
- AssumeRole を使ったクロスアカウントアクセスの設定方法を習得できる
- IAM ロールの信頼ポリシーとアクセス許可ポリシーの使い分けを理解できる
- マネジメントコンソールでのスイッチロール操作を体験できる
- 一時的な認証情報を活用したセキュリティのベストプラクティスを把握できる
執筆者とキャラクター紹介
執筆者:土肥(とひ)
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。

クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。



基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。



猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説



とひさん、AWS STS ってどんなサービスなんですか?
AWS Security Token Service、略して AWS STS は、AWS リソースへのアクセスを制御するための一時的な認証情報を発行するサービスだよ。STS はグローバルサービスで、デフォルトでは https://sts.amazonaws.com のエンドポイントが利用されるけど、リージョナルエンドポイントも使えるんだ。主な API アクションを見てみよう。
| API アクション | 説明 |
|---|---|
AssumeRole | IAM ロールを引き受けて一時的な認証情報を取得する |
AssumeRoleWithSAML | SAML 認証を使ってロールを引き受ける |
AssumeRoleWithWebIdentity | Web ID プロバイダー(Google、Facebook 等)を使ってロールを引き受ける |
GetSessionToken | MFA を使って一時的な認証情報を取得する |
GetCallerIdentity | 呼び出し元の IAM エンティティ情報を取得する |



いろんな API があるんですね。「一時的な認証情報」ってよく聞きますけど、具体的には何が含まれてるんですか?
STS が発行する一時的な認証情報は、以下の 3 つの要素で構成されるんだ。
| 要素 | 説明 |
|---|---|
| アクセスキー ID | 一時的なアクセスキー(ASIA で始まる) |
| シークレットアクセスキー | 一時的なシークレットキー |
| セッショントークン | セッションを識別するトークン(API リクエスト時に必須) |



通常のアクセスキーとは違うんですか?ちゃんと区別できるか心配です…。
大丈夫だよ。一時的な認証情報にはいくつかの特徴があるから、長期的な認証情報とは性質が全然違うんだ。
- 有効期限がある: デフォルトは 1 時間(AssumeRole の場合、最大 12 時間まで延長可能)
- 自動失効: 有効期限が切れると自動的に無効化される
- ローテーション不要: 有効期限による自動失効のため、手動でのローテーションが不要
- IAM ユーザーに紐づかない: ユーザーに永続的なアクセスキーを発行する必要がない



有効期限が切れたら自動で無効化されるんですね!ローテーションも不要なら、セキュリティ面でかなり安心ですね。
そうなんだ。だから AWS としても、長期的なアクセスキーよりも STS の一時的な認証情報を使うことを推奨しているよ。次に、よく使われる AssumeRole とクロスアカウントアクセスについて説明するね。



AssumeRole、聞いたことあります。どういう仕組みなんですか?
AssumeRole は、IAM ロールを引き受ける、つまりロールの権限を一時的に取得する API アクションだよ。クロスアカウントアクセスでは以下の設定が必要になるんだ。まずは 信頼ポリシー(Trust Policy)。これはロール側に設定するもので、「誰がこのロールを引き受けられるか」を定義するよ。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:root"
},
"Action": "sts:AssumeRole"
}
]
}
次に アクセス許可ポリシー(Permissions Policy)。これもロール側に設定するんだけど、「ロールを引き受けた後に何ができるか」を定義するものだよ。そして最後に IAM ポリシー(呼び出し元)。呼び出し元のユーザーやロールに sts:AssumeRole アクションを許可するポリシーをアタッチする必要があるんだ。





ロール側に2つのポリシーがあって、呼び出し元にもポリシーが必要… ちょっと複雑ですね。
整理すると、信頼ポリシーが「誰に使わせるか」、アクセス許可ポリシーが「何をさせるか」、呼び出し元のポリシーが「使っていいよという許可」なんだ。この 3 つが揃って初めてクロスアカウントアクセスが成立するよ。



なるほど、役割が分かれてるんですね。コンソールから AssumeRole を使うこともできるんですか?
マネジメントコンソールでは「スイッチロール」という機能で AssumeRole を GUI で実行できるよ。別のアカウントの IAM ロールに切り替えることで、そのロールに付与された権限でリソースを操作できるんだ。今回の実践でも体験してみよう。



GUI でできるなら分かりやすそうですね!やってみます!
実践
前提条件
- リージョン:
ap-northeast-1(東京) - IAM ユーザーまたはロールに IAM の操作権限(ロール・ポリシーの作成権限)があること
- 本記事では単一アカウント内でクロスアカウントアクセスの仕組みを体験します(2 つの AWS アカウントがなくても実施可能です)
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| IAM ロール | sts-hands-on-role | AssumeRole の対象ロール |
| IAM ポリシー(AWS マネージド) | AmazonS3ReadOnlyAccess | ロールにアタッチする S3 読み取り専用ポリシー(新規作成はしない) |
ステップ1: IAM ロールの作成
AssumeRole の対象となる IAM ロールを作成します。
- AWS マネジメントコンソールにログインし、リージョンが
ap-northeast-1(東京)であることを確認します - 上部の検索バーに
IAMと入力し、表示された「IAM」を選択します - 左側ナビゲーションの「アクセス管理」→「ロール」を選択します
- 「ロールを作成」をクリックします
- 「信頼されたエンティティを選択」画面の「信頼されたエンティティタイプ」で「AWS アカウント」を選択します
- 下に表示される「AWS アカウント」セクションで以下を設定します
- 「このアカウント (自身のアカウント ID)」を選択します(単一アカウントで体験するため。別アカウントのロールを作る場合は「別の AWS アカウント」を選びます)
- オプションの「外部 ID を要求する」「MFA が必要」のチェックは外したままにします
- 「次へ」をクリックします


ステップ2: アクセス許可ポリシーのアタッチ
- 「許可を追加」画面で「既存のポリシーを使用」が選ばれていることを確認します
- 「許可ポリシー」の検索ボックスに
AmazonS3ReadOnlyAccessと入力して Enter キーを押します - 表示された「AmazonS3ReadOnlyAccess」にチェックを入れます
- 「次へ」をクリックします


ステップ3: ロールの名前と確認
- 「名前、確認、および作成」画面の「ロール名」に
sts-hands-on-roleと入力します - 説明は空のままにします
- 「ステップ 1: 信頼されたエンティティを選択する」の「信頼ポリシー」に、自身のアカウント ID が
PrincipalのAWSに入った JSON が表示されていることを確認します - 「ロールを作成」をクリックします


ステップ4: 作成したロールの確認
- 「ロール sts-hands-on-role が作成されました。」のバナーで「ロールを表示」をクリックします(ロール一覧で検索して開いても同じです)
- 「概要」で以下の情報を確認します
- ARN:
arn:aws:iam::<アカウントID>:role/sts-hands-on-role - コンソールでロールを切り替えるためのリンク: このリンクを開くと、次のステップのスイッチロール画面がアカウント ID とロール名入力済みで開きます
- 最大セッション時間:
1 時間(一時的な認証情報の有効期限) - 「許可」タブにアタッチされた
AmazonS3ReadOnlyAccess、「信頼関係」タブに信頼ポリシーの内容が表示されることを確認します - ロール名とアカウント ID をメモしておきます


ステップ5: スイッチロールの実行
マネジメントコンソールからスイッチロールを実行します。
- コンソール右上のアカウント名(ユーザー名)をクリックします
- ドロップダウンメニューから「ロールの切り替え」を選択します(ステップ4 の「コンソールでロールを切り替えるためのリンク」を開いても同じ画面になります)
- 「Switch Role」画面(この画面は英語表示です)で以下の項目を入力します
- Account ID: 自身のアカウント ID(12 桁の数字)
- IAM role name:
sts-hands-on-role - Display name – optional:
STS-HandsOn(任意の表示名) - Display color – optional: 任意の色を選択(ロール使用中であることを視覚的に識別するため。
Noneのままでも構いません) - 「Switch Role」をクリックします


ステップ6: スイッチロール後の動作確認
スイッチロール後、コンソール右上のアカウント名の下に表示名 STS-HandsOn が表示され、現在ロールを引き受けていることが確認できます。リージョンが切り替わっている場合は ap-northeast-1(東京)に戻します。
- 上部の検索バーに
S3と入力し、「S3」を選択します - 「汎用バケット」に S3 バケットの一覧が表示されることを確認します(
AmazonS3ReadOnlyAccessの権限でアクセスできています)


- 試しに S3 で「バケットを作成」をクリックし、任意のバケット名を入力してページ下部の「バケットを作成」を実行してみます
- 「バケットを作成できませんでした」「バケットを作成するには、s3:CreateBucket アクセス許可が必要です。」というエラーが表示されます。これは
AmazonS3ReadOnlyAccessには書き込み権限が含まれていないためです


ステップ7: 元のユーザーに戻る
- コンソール右上のアカウント名(ロール表示名
STS-HandsOnが表示されている部分)をクリックします - 「スイッチバック」をクリックします
- 元の IAM ユーザーに戻り、通常の権限でコンソールを操作できることを確認します
まとめ
- AWS STS は、一時的な認証情報(アクセスキー、シークレットキー、セッショントークン)を発行するサービスです
- 一時的な認証情報には 有効期限 があり、期限切れで自動失効するため、長期的な認証情報より安全です
- AssumeRole を使うことで、IAM ロールを引き受けて別の権限セットでリソースにアクセスできます
- クロスアカウントアクセスには、ロール側の 信頼ポリシー と呼び出し元の IAM ポリシー の両方の設定が必要です
- マネジメントコンソールでは スイッチロール 機能で AssumeRole を GUI で実行できます
- ロールには必要最小限の権限のみを付与し、最小権限の原則 に従うことがベストプラクティスです
参照先
- 一時的なセキュリティ認証情報 – AWS Identity and Access Management
- AssumeRole – AWS Security Token Service
- IAM ロールの作成 – AWS Identity and Access Management
- ロールの切り替え(コンソール) – AWS Identity and Access Management
- クロスアカウントアクセスのためのロールの作成 – AWS Identity and Access Management
- 一時的なセキュリティ認証情報のリクエスト – AWS Identity and Access Management










