【AWS中級へのステップ】ACL 無効化時代の S3 へのクロスアカウントアクセス 2 選
はじめに
猫とアポロチョコとSystems Managerが好きな m.hayakawa です。
本記事は、AWS サービスの基本設計には慣れてきたものの、「この構成で問題ないのか」「より良い設計方法はないのか」といった実務的な課題に直面している方向けの内容となります。
AWS 初学者が中級者へとステップアップするために押さえておきたい実践的な知識や TIPS のひとつを紹介し、初学者の方が知識をより深めるため、またベテランの方が知識を再確認するための一助となることを目指しています。
前知識:ACL 無効化とはどういうことか
S3 の ACL（アクセスコントロールリスト）は、バケットやオブジェクトごとに「誰がどのような操作をできるか」を設定するアクセス制御の仕組みです。例えば、特定のAWSアカウントに読み取り権限を与えたり、インターネット上の全ユーザーに公開したりといった細かな権限設定が可能です。
バケット全体に対して設定するバケットACLと、個々のファイル（オブジェクト）に対して設定するオブジェクトACLの2種類があり、それぞれ独立して権限を管理できます。ACLでは読み取り、書き込み、ACL自体の読み取りや書き込みといった基本的な権限を付与することができます。
詳細は下記の記事が詳しいです。
数年前は、S3 の ACL について考慮をする必要がありましたが、現在は ACL の有効化は非推奨となっております。そのため、S3 へのアクセスコントロールは、S3 バケットポリシーとアクセス元の IAM ポリシーの 2 つのパターンを考慮するのみとなることが、一般的になりました。
S3 バケットポリシーとアクセス元の IAM ポリシーの使い分けについては、手前味噌ですが、下記の記事が詳しいです。
なお、評価論理は下記となります。
同一アカウントでのアクセスの場合
| バケットポリシー | IAMポリシー | 結果 |
|---|---|---|
| 指定なし | 指定なし | 失敗 |
| 許可 | 指定なし | 成功 |
| 指定なし | 許可 | 成功 |
| 許可 | 許可 | 成功 |
| 明示的な拒否 | 許可 | 失敗 |
| 許可 | 明示的な拒否 | 失敗 |
| 明示的な拒否 | 明示的な拒否 | 失敗 |
クロスアカウントアクセスの場合
| バケットポリシー | IAMポリシー | 結果 |
|---|---|---|
| 指定なし | 指定なし | 失敗 |
| 許可 | 指定なし | 失敗 |
| 指定なし | 許可 | 失敗 |
| 許可 | 許可 | 成功 |
| 明示的な拒否 | 許可 | 失敗 |
| 許可 | 明示的な拒否 | 失敗 |
| 明示的な拒否 | 明示的な拒否 | 失敗 |
クロスアカウントアクセスの場合は、バケットポリシーと IAM ポリシーの両方を許可する必要があります。
上記前提で S3 にクロスアカウントアクセスをする際に、どういう方法を取るのが正解であるか、という問い合わせをテクニカルサポート宛てに受けることがあります。
今回は、2 通りの方法について解説します。
前提
登場するリソースは下記とします。
- アクセス元のアカウント A
- アクセス先のアカウント B
- アカウントB(アクセス先)の S3 バケット S
- アカウントA(アクセス元)の IAM ユーザー X
- アカウントB(アクセス先)の IAM ロール Z
パターン1. S3が存在するアカウントのIAMロールにスイッチする
具体的な方法
アクセス元の IAM ユーザー X から、アクセス先の IAM ロール Z にスイッチロールをし、IAM ロール Z の認証情報を用いてアクセスすることで、最終的にクロスアカウントでのアクセスを実現します。
各リソースは下記のように設定します。
アクセス元 IAM ユーザー X の アクセス許可ポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::<AccountB>:role/RoleZ"
}
]
}
アクセス先 IAM ロール Z の信頼ポリシー（アクセス許可ポリシーではありません。）
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<AccountA>:user/UserX"
},
"Action": "sts:AssumeRole"
}
]
}
なお、この場合、アカウントB(アクセス先)の S3 バケット S と アカウントB(アクセス先)の IAM ロール Z は同一アカウントに存在するという扱いになるため、S3 バケット S のバケットポリシーと、IAM ロール Z の許可ポリシーの内、どちらかが許可されていればアクセス可能になります。
利点
この方法の利点としては、クロスアカウントアクセスをはく奪したい場合、または、特定の期間のみアクセスさせたいなどの用途が、比較的に容易にできる点です。
クロスアカウントアクセスをはく奪したい場合
IAM ロールの信頼関係を編集するのみで済みます。実際には記述を削除すればOKですが、あえて明示的に拒否する場合は下記のように記述します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": {
"AWS": "arn:aws:iam::<AccountA>:user/UserX"
},
"Action": "sts:AssumeRole"
}
]
}
特定の期間のみアクセスさせたい
IAM ロールの信頼関係で、Condition 要素を使用して特定の期間のみスイッチロールを許可しています。この期間外ではスイッチロールが拒否されます。
例：2026年1月1日0時（UTC）から2026年2月1日0時（UTC）のみ許可する場合
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<AccountA>:user/UserX"
},
"Action": "sts:AssumeRole",
"Condition": {
"DateGreaterThan": {
"aws:CurrentTime": "2026-01-01T00:00:00Z"
},
"DateLessThan": {
"aws:CurrentTime": "2026-02-01T00:00:00Z"
}
}
}
]
}
上記のように、アクセス先 IAM ロール Z の設定のみを変えればいいため、作業量が少なく、また、何か問題が発生した場合のロールバックも容易となります。
パターン2. S3バケットポリシーで他アカウントからのアクセスを許可する
具体的な方法
アクセス先アカウント B の S3 バケットポリシーを編集して、アクセス元の IAM ユーザー X からのアクセスを明示的に許可するという方法です。（加えて、アクセス元の IAM ユーザー X 自身も S3 バケットへのアクセスを許可する必要があります）
上図は、下記ドキュメントより引用いたしました。
例えば、下記の S3 バケットポリシーのように設定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<AccountA>:user/UserX"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucket-name/*"
}
]
}
アカウントA(アクセス元)の IAM ユーザー X にも下記のように IAM ポリシーを付与します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucket-name/*"
}
]
}
この方法はスイッチロールをしないので、一見楽なように見えますが、下記の点に注意する必要があります。
- アクセス先のアカウント B の S3 バケットに対して、すべてのバケットポリシーの編集が必要
- アクセス元のアカウント A の IAM ユーザーに対して、バケットへのアクセス許可が必要
上記が何を意味するかというと、クロスアカウントでのアクセスを中止させたいときにも同様の操作が必要ということです。
例えば、S3 バケットが 10 個あるとしたらどうでしょうか。対象の S3 バケット 10 個分のバケットポリシーについて、クロスアカウントでのアクセスができないように編集しなおす必要があります。
また、アクセス元のアカウント A が取引先であった場合は、権限付与やはく奪が難しくなります。
作業の抜け漏れが発生する可能性や、権限付与やはく奪を簡便にするといった要件から、通常の場合は「パターン1. S3が存在するアカウントのIAMロールにスイッチする」 が推奨されます。
パターン2. が考えられるケース
パターン2. が採用されるケースとしては、少ないですが下記が考えられます。
- アカウントA(アクセス元)の IAM ユーザー X に スイッチロール を可能とする権限を付けたくない。
- アカウントB(アクセス先)の IAM ロール Z に外部アカウントからスイッチさせたくない。
まとめ
S3 へのクロスアカウントアクセスについて、2 パターンを紹介しました。
それぞれの特徴を捉えて、要件に沿った方法を選択ください。
参考資料
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AI をフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026 年 1 月 アノテーション㈱から社名変更しました
