Amazon S3 での IAM の機能
IAM を使用して Amazon S3 へのアクセスを管理する前に、Amazon S3 で利用できる IAM 機能について理解しておく必要があります。
IAM の機能 | Amazon S3 のサポート |
---|---|
あり |
|
可能 |
|
あり |
|
はい |
|
はい |
|
はい |
|
部分的 |
|
可能 |
|
可能 |
|
あり |
|
部分的 |
Amazon S3 およびその他の AWS サービスがほとんどの IAM 機能との連携する方法の詳細については、「IAM ユーザーガイド」の「IAM と連携する AWS サービス」を参照してください。
S3 リソースタイプ別の S3 API オペレーションへのアクセス許可の詳細については、「Amazon S3 API オペレーションに必要なアクセス許可」を参照してください。
Amazon S3 のアイデンティティベースのポリシー
アイデンティティベースのポリシーのサポート: あり
アイデンティティベースポリシーは、IAM ユーザーグループ、ユーザーのグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースのポリシーを作成する方法については、「IAM ユーザーガイド」の「カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する」を参照してください。
IAM アイデンティティベースのポリシーでは、許可または拒否するアクションとリソース、およびアクションを許可または拒否する条件を指定できます。プリンシパルは、それが添付されているユーザーまたはロールに適用されるため、アイデンティティベースのポリシーでは指定できません。JSON ポリシーで使用できるすべての要素について学ぶには、IAM ユーザーガイドのIAM JSON ポリシーの要素のリファレンスを参照してください。
Amazon S3 のアイデンティティベースのポリシー例
Amazon S3 のアイデンティティベースのポリシー例を確認するには、「Amazon S3 のアイデンティティベースのポリシー」を参照してください。
Amazon S3 内のリソースベースのポリシー
リソースベースのポリシーのサポート: はい
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM ロールの信頼ポリシー や Amazon S3 バケットポリシー があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーでは、プリンシパルを指定する必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーションユーザー、または AWS のサービス を含めることができます。
クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。リソースベースのポリシーにクロスアカウントのプリンシパルを追加しても、信頼関係は半分しか確立されない点に注意してください。プリンシパルとリソースが異なる AWS アカウント にある場合、信頼できるアカウントの IAM 管理者は、リソースにアクセスするための権限をプリンシパルエンティティ (ユーザーまたはロール) に付与する必要もあります。IAM 管理者は、アイデンティティベースのポリシーをエンティティにアタッチすることで権限を付与します。ただし、リソースベースのポリシーで、同じアカウントのプリンシパルへのアクセス権が付与されている場合は、アイデンティティベースのポリシーをさらに付与する必要はありません。詳細については、「IAM ユーザーガイド」の「IAM でのクロスアカウントリソースアクセス」を参照してください。
Amazon S3 サービスは、バケットポリシー、アクセスポイントポリシー、およびアクセス許可をサポートします。
-
バケットポリシーは、Amazon S3 バケットにアタッチされるリソースベースのポリシーです。リソースポリシーは、バケットに対してアクションを実行できるプリンシパルを定義します。
-
アクセスポイントポリシーは、基になるバケットポリシーと組み合わせて評価されるリソースベースのポリシーです。
-
アクセス許可は、Amazon S3 内のデータへのアクセス許可をプレフィックス、バケット、またはオブジェクトごとに定義するための簡略化されたモデルです。S3 Access Grants の詳細については、「S3 Access Grants でのアクセス管理」を参照してください。
バケットポリシーのプリンシパル
Principal
エレメントは、リソースへのアクセスを許可または拒否するユーザー、アカウント、サービス、または他のエンティティを指定します。Principal
を指定する例を以下に示します。詳細については、IAM ユーザーガイドのプリンシパルプリンシパル を参照してください。
AWS アカウントに許可を付与する
AWS アカウントに許可を付与するには、以下の形式を使用してアカウントを指定します。
"AWS":"
account-ARN
"
次に例を示します。
"Principal":{"AWS":"arn:aws:iam::
AccountIDWithoutHyphens
:root"}
"Principal":{"AWS":["arn:aws:iam::
AccountID1WithoutHyphens
:root","arn:aws:iam::AccountID2WithoutHyphens
:root"]}
IAM ユーザーにアクセス許可を付与する
アカウントの IAM ユーザーにアクセス許可を付与するには、"AWS":"
の名前と値のペアを指定する必要があります。user-ARN
"
"Principal":{"AWS":"arn:aws:iam::
account-number-without-hyphens
:user/username
"}
ステップバイステップの手順を説明する詳細な例については、例 1: バケット所有者がユーザーにバケットのアクセス許可を付与する および 例 3: バケット所有者が自分の所有していないオブジェクトに対するアクセス許可を付与する を参照してください。
注記
バケットポリシーを更新した後に IAM ID を削除すると、バケットポリシーのプリンシパル要素には ARN の代わりに一意の ID が表示されます。これらの一意な ID は再利用されることがないため、すべてのポリシーステートメントから一意の ID を持つプリンシパルを安全に削除できます。一意の ID の詳細については、IAM ユーザーガイドの「IAM ID」を参照してください。
匿名アクセス許可を付与する
警告
Simple Storage Service (Amazon S3) バケットへの匿名アクセスを付与するときは注意が必要です。匿名アクセスを付与すると、世界中のすべてのユーザーがバケットにアクセスできます。種類にかかわらず、S3 バケットへの匿名書き込みアクセスは一切付与しないことを強くお勧めします。
匿名アクセスと呼ばれるアクセス許可を全員に付与するには、Principal
の値としてワイルドカード ("*"
) を設定します。例えば、バケットを Web サイトとして設定する場合、以下のように、バケット内のすべてのオブジェクトを公開し、誰でもアクセスできるようにすることができます。
"Principal":"*"
"Principal":{"AWS":"*"}
リソースベースのポリシーで、"Principal": "*"
効果と共に Allow
を使用すると、AWS にサインしていなくても、誰でもリソースにアクセスできるようになります。
リソースベースのポリシーで、Allow
効果と共に "Principal" : { "AWS" : "*" }
を使用すると、同じパーティションのどのアカウントのルートユーザー、IAM ユーザー、引き受けたロールのセッション、フェデレーティッドユーザーでも、リソースにアクセスできるようになります。
匿名ユーザーの場合、これら 2 つの方法は同等です。詳細については、「IAM ユーザーガイド」の「すべてのプリンシパル」を参照してください。
ワイルドカードとして使用して、プリンシパルの名前または ARN の一部に一致させることはできません。
重要
誰でも AWS アカウント を作成できるため、この 2 つの方法は機能は異なりますが、セキュリティレベルについては同等です。
リソースのアクセス許可の制限
リソースポリシーを使用して、それ以外の場合は IAM プリンシパルで利用できるリソースへのアクセスを制限することもできます。Deny
ステートメントを使用してアクセスを防止します。
次の例では、安全な転送プロトコルが使用されていない場合はアクセスをブロックします。
{"Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": <bucket ARN>, "Condition": { "Boolean": { "aws:SecureTransport" : "false"} } }
このポリシーでは、この方法を使用して特定のアカウントやプリンシパルのみへのアクセスの拒否を試みるのではなく、"Principal": "*"
を使用して、この制限をすべてのユーザーに適用することがベストプラクティスです。
CloudFront の URL を使用したアクセスの要求
Amazon S3 の URL の代わりに CloudFront の URL を使用することで、ユーザーが Amazon S3 のコンテンツのみにアクセスするように制限することができます。これを行うには、CloudFront オリジンアクセスコントロール (OAC) を作成します。その後、S3 データのアクセス許可を変更します。バケットポリシーでは、次のように CloudFront をプリンシパルとして設定できます。
"Principal":{"Service":"cloudfront.amazonaws.com"}
ポリシーの Condition
要素を使用して、S3 オリジンを含む CloudFront ディストリビューションに代わってリクエストが行われた場合にのみ CloudFront がバケットにアクセスできるようにします。
"Condition": { "StringEquals": { "AWS:SourceArn": "arn:aws:cloudfront::
111122223333
:distribution/CloudFront-distribution-ID
" } }
CloudFront URL を使用した S3 アクセスの制限の詳細については、「Amazon CloudFront 開発者ガイド」の「Amazon Simple Storage Service オリジンへのアクセスの制限」を参照してください。Amazon CloudFront を使用する場合のセキュリティとプライバシーのメリットの詳細については、「コンテンツへのセキュアなアクセスとアクセス制限の設定」を参照してください。
Amazon S3 のリソースベースポリシーの例
Amazon S3 バケットポリシーの例については、「Amazon S3 のバケットポリシー」を参照してください。
アクセスポイントのポリシーの例については、「アクセスポイントを使用するための IAM ポリシーの設定」を参照してください。
Amazon S3 のポリシーアクション
ポリシーアクションのサポート: あり
管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどんなリソースにどんな条件でアクションを実行できるかということです。
JSON ポリシーのAction
要素には、ポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。ポリシーアクションの名前は通常、関連する AWS API オペレーションと同じです。一致する API オペレーションのない許可のみのアクションなど、いくつかの例外があります。また、ポリシーに複数のアクションが必要なオペレーションもあります。これらの追加アクションは、依存アクションと呼ばれます。
このアクションは、関連付けられたオペレーションを実行するための権限を付与するポリシーで使用されます。
以下に、S3 API オペレーションと必要なポリシーアクション間のさまざまなタイプのマッピング関係を示します。
同じ名前の 1 対 1 のマッピング。例えば、
PutBucketPolicy
API オペレーションを使用するには、s3:PutBucketPolicy
ポリシーアクションが必要です。異なる名前の 1 対 1 のマッピング。例えば、
ListObjectsV2
API オペレーションを使用するには、s3:ListBucket
ポリシーアクションが必要です。1 対多のマッピング。例えば、
HeadObject
API オペレーションを使用するには、s3:GetObject
が必要です。また、S3 オブジェクトロックを使用し、オブジェクトのリーガルホールドステータスまたは保持設定を取得したい場合は、HeadObject
API オペレーションを使用する前に、対応するs3:GetObjectLegalHold
またはs3:GetObjectRetention
ポリシーアクションも必要です。1 対多のマッピング。例えば、
ListObjectsV2
またはHeadBucket
API オペレーションを使用するには、s3:ListBucket
ポリシーアクションが必要です。
ポリシーで使用する Amazon S3 アクションの一覧については、「サービス認可リファレンス」の「Amazon S3 で定義されるアクション」を参照してください。Amazon S3 API オペレーションの完全なリストについては、「Amazon Simple Storage Service API リファレンス」の「Amazon S3 API アクション」を参照してください。
S3 リソースタイプ別の S3 API オペレーションへのアクセス許可の詳細については、「Amazon S3 API オペレーションに必要なアクセス許可」を参照してください。
Amazon S3 のポリシーアクションは、アクションの前に次のプレフィックスを使用します。
s3
単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。
"Action": [ "s3:
action1
", "s3:action2
" ]
バケットオペレーション
バケットオペレーションは、バケットリソースタイプで動作する S3 API オペレーションです。例: CreateBucket
、ListObjectsV2
、PutBucketPolicy
。バケットオペレーションの S3 ポリシーアクションでは、バケットポリシーの Resource
要素または IAM アイデンティティベースのポリシーが、次の例形式の S3 バケットタイプの Amazon リソースネーム (ARN) 識別子である必要があります。
"Resource": "arn:aws:s3:::
amzn-s3-demo-bucket
"
次のバケットポリシーは、アカウント
のユーザー 12345678901
に ListObjectsV2 API オペレーションを実行し、S3 バケット内のオブジェクトを一覧表示する Akua
s3:ListBucket
アクセス許可を付与します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Allow Akua to list objects in the bucket", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
12345678901
:user/Akua" }, "Action": [ "s3:ListBucket" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket
" } ] }
アクセスポイントポリシーでのバケットオペレーション
アクセスポイントポリシーで付与されるアクセス許可は、基になるバケットで同じアクセス許可が許可される場合にのみ有効です。S3 アクセスポイントを使用する場合は、バケットからアクセスポイントにアクセスコントロールを委任するか、アクセスポイントポリシーで同じアクセス許可を基礎となるバケットのポリシーに追加する必要があります。詳細については、「アクセスポイントを使用するための IAM ポリシーの設定」を参照してください。アクセスポイントポリシーでは、バケットオペレーションの S3 ポリシーアクションで、次の形式の Resource
要素にアクセスポイント ARN を使用する必要があります。
"Resource": "arn:aws:s3:
us-west-2
:123456789012
:accesspoint/example-access-point
"
次のアクセスポイントポリシーは、
という名前の S3 アクセスポイントを介して ListObjectsV2 API オペレーションを実行する example-access-point
s3:ListBucket
アクセス許可をアカウント
のユーザー 12345678901
に付与します。このアクセス許可により、Akua
は Akua
に関連付けられているバケット内のオブジェクトを一覧表示できます。example-access-point
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Allow
Akua
to list objects in the bucket through access point", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::12345678901
:user/Akua
" }, "Action": [ "s3:ListBucket" ], "Resource": "arn:aws:s3:us-west-2
:123456789012
:accesspoint/example-access-point
" } ] }
注記
すべてのバケットオペレーションが S3 アクセスポイントでサポートされているわけではありません。詳細については、「S3 オペレーションとアクセスポイントの互換性」を参照してください。
オブジェクト操作
オブジェクトオペレーションは、オブジェクトリソースタイプに基づいて実行される S3 API オペレーションです。例: GetObject
、PutObject
、DeleteObject
。オブジェクトオペレーションの S3 ポリシーアクションでは、ポリシーの Resource
要素を次の例の形式で S3 オブジェクト ARN にする必要があります。
"Resource": "arn:aws:s3:::
amzn-s3-demo-bucket
/*"
"Resource": "arn:aws:s3:::
amzn-s3-demo-bucket
/prefix
/*"
注記
前の例に示すように、オブジェクト ARN にはバケット名の後にスラッシュが含まれている必要があります。
以下のバケットポリシーは、アカウント
のユーザー 12345678901
に Akua
s3:PutObject
の許可を付与します。このアクセス許可により、
は PutObject API オペレーションを使用して、Akua
という名前の S3 バケットにオブジェクトをアップロードできるようになります。amzn-s3-demo-bucket
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Allow
Akua
to upload objects", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::12345678901
:user/Akua
" }, "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket
/*" } ] }
アクセスポイントポリシーでのオブジェクトオペレーション
S3 アクセスポイントを使用してオブジェクトオペレーションへのアクセスを制御する場合、アクセスポイントポリシーを使用できます。アクセスポイントポリシーを使用するとき、オブジェクトオペレーションの S3 ポリシーアクションで、arn:aws:s3:
形式の region
:account-id
:accesspoint/access-point-name
/object/resource
Resource
要素にアクセスポイント ARN を使用する必要があります。アクセスポイントを使用するオブジェクトオペレーションの場合、アクセスポイント ARN 全体の後に /object/
値を Resource
要素に含める必要があります。次に例を示します。
"Resource": "arn:aws:s3:
us-west-2
:123456789012
:accesspoint/example-access-point
/object/*"
"Resource": "arn:aws:s3:
us-west-2
:123456789012
:accesspoint/example-access-point
/object/prefix
/*"
次のアクセスポイントポリシーは、アカウント
のユーザー 12345678901
に Akua
s3:GetObject
アクセス許可を付与します。このアクセス許可により、
は、アクセスポイントに関連付けられているバケット内のすべてのオブジェクトに対して、Akua
という名前のアクセスポイントを介して GetObject API オペレーションを実行できます。example-access-point
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Allow
Akua
to get objects through access point", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::12345678901
:user/Akua
" }, "Action": [ "s3:GetObject" ], "Resource": "arn:aws:s3:us-west-2
:123456789012
:accesspoint/example-access-point
/object/*" } ] }
注記
すべてのオブジェクトオペレーションがアクセスポイントでサポートされているわけではありません。詳細については、「S3 オペレーションとアクセスポイントの互換性」を参照してください。
アクセスポイントオペレーション
アクセスポイントオペレーションは、accesspoint
リソースタイプで動作する S3 API オペレーションです。例: CreateAccessPoint
、DeleteAccessPoint
、GetAccessPointPolicy
。アクセスポイントオペレーションの S3 ポリシーアクションは、バケットポリシーやアクセスポイントポリシーではなく、IAM アイデンティティベースのポリシーでのみ使用できます。アクセスポイントオペレーションでは、Resource
要素を次の例の形式のアクセスポイント ARN にする必要があります。
"Resource": "arn:aws:s3:
us-west-2
:123456789012
:accesspoint/example-access-point
"
次の IAM アイデンティティベースのポリシーは、
という名前の S3 アクセスポイントで GetAccessPointPolicy API オペレーションを実行する example-access-point
s3:GetAccessPointPolicy
アクセス許可を付与します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Grant permission to retrieve the access point policy of access point
example-access-point
", "Effect": "Allow", "Action": [ "s3:GetAccessPointPolicy" ], "Resource": "arn:aws:s3:*:123456789012
:accesspoint/example-access-point
" } ] }
アクセスポイントを使用してバケットオペレーションへのアクセスを制御する場合は、「アクセスポイントポリシーでのバケットオペレーション」を参照してください。オブジェクトオペレーションへのアクセスを制御するには、「アクセスポイントポリシーでのオブジェクトオペレーション」を参照してください。アクセスポイントポリシーの設定方法の詳細については、「アクセスポイントを使用するための IAM ポリシーの設定」を参照してください。
Object Lambda アクセスポイントオペレーション
Amazon S3 Object Lambda を使用すると、Amazon S3 GET
、LIST
、HEAD
リクエストに独自のコードを追加して、データがアプリケーションに返されるときにそのデータを変更および処理できます。Object Lambda アクセスポイントを介したリクエストは、他のアクセスポイントを介したリクエストと同様に行うことができます。詳細については、「S3 Object Lambda を使用したオブジェクトの変換」を参照してください。
Object Lambda アクセスポイントオペレーションのポリシーを設定する方法についての詳細は、「Object Lambda アクセスポイントの IAM ポリシーの設定」を参照してください。
マルチリージョンアクセスポイントオペレーション
マルチリージョンアクセスポイントを使用すると、複数の AWS リージョン にある S3 バケットからのリクエストをアプリケーションが実行するために使用できるグローバルエンドポイントを作成できます。マルチリージョンアクセスポイントを使用して、単一のリージョンで使用するのと同じシンプルなアーキテクチャでマルチリージョンアプリケーションを構築し、世界中のどこでもこれらのアプリケーションを実行することができます。詳細については、「マルチリージョンアクセスポイントを使用したマルチリージョントラフィックの管理」を参照してください。
マルチリージョンアクセスポイントオペレーションのポリシーを設定する方法の詳細については、「マルチリージョンアクセスポイントポリシーの例」を参照してください。
バッチジョブオペレーション
(バッチオペレーション) ジョブオペレーションは、ジョブリソースタイプで動作する S3 API オペレーションです。例えば、DescribeJob
と CreateJob
です。ジョブオペレーションの S3 ポリシーアクションは、バケットポリシーではなく、IAM アイデンティティベースのポリシーでのみ使用できます。また、ジョブオペレーションでは、IAM アイデンティティベースのポリシーの Resource
要素を次の例の形式の job
ARN にする必要があります。
"Resource": "arn:aws:s3:*:
123456789012
:job/*"
次の IAM アイデンティティベースのポリシーは、
という名前の S3 バッチオペレーションジョブに対して DescribeJob API オペレーションを実行する example-job
s3:DescribeJob
アクセス許可を付与します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Allow describing the Batch operation job
example-job
", "Effect": "Allow", "Action": [ "s3:DescribeJob" ], "Resource": "arn:aws:s3:*:123456789012
:job/example-job
" } ] }
S3 Storage Lens 設定オペレーション
S3 Storage Lens 設定オペレーションの設定方法の詳細については、「Amazon S3 ストレージレンズアクセス許可の設定」を参照してください。
アカウントオペレーション
アカウントオペレーションは、アカウントレベルで実行される S3 API オペレーションです。例えば、GetPublicAccessBlock
(アカウント用) です。アカウントは、Amazon S3 で定義されるリソースタイプではありません。アカウントオペレーションの S3 ポリシーアクションは、バケットポリシーではなく、IAM アイデンティティベースのポリシーでのみ使用できます。また、アカウントオペレーションでは、IAM アイデンティティベースのポリシーの Resource
要素が "*"
である必要があります。
次の IAM アイデンティティベースのポリシーは、アカウントレベルの GetPublicAccessBlock API オペレーションを実行し、アカウントレベルのパブリックアクセスブロック設定を取得するために s3:GetAccountPublicAccessBlock
アクセス許可を付与します。
{ "Version":"2012-10-17", "Statement":[ { "Sid":"Allow retrieving the account-level Public Access Block settings", "Effect":"Allow", "Action":[ "s3:GetAccountPublicAccessBlock" ], "Resource":[ "*" ] } ] }
Amazon S3 のポリシーの例
-
Amazon S3 のアイデンティティベースのポリシー例を確認するには、「Amazon S3 のアイデンティティベースのポリシー」を参照してください。
-
Amazon S3 のリソースベースのポリシー例を確認するには、「Amazon S3 のバケットポリシー」および「アクセスポイントを使用するための IAM ポリシーの設定」を参照してください。
Amazon S3 のポリシーリソース
ポリシーリソースのサポート: あり
管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどのリソースにどのような条件でアクションを実行できるかということです。
Resource
JSON ポリシー要素は、アクションが適用されるオブジェクトを指定します。ステートメントには、Resource
または NotResource
要素を含める必要があります。ベストプラクティスとして、Amazon リソースネーム (ARN) を使用してリソースを指定します。これは、リソースレベルの許可と呼ばれる特定のリソースタイプをサポートするアクションに対して実行できます。
オペレーションのリスト化など、リソースレベルの権限をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (*) を使用します。
"Resource": "*"
一部の Amazon S3 API アクションは複数のリソースをサポートします。例えば、s3:GetObject
は
と example-resource-1
にアクセスするため、プリンシパルには両方のリソースにアクセスする許可が必要です。1 つのステートメントで複数のリソースを指定するには、次の例に示すように、ARN をカンマで区切ります。example-resource-2
"Resource": [ "
example-resource-1
", "example-resource-2
"
Amazon S3 のリソースは、バケット、オブジェクト、アクセスポイント、またはジョブです。ポリシーでは、バケット、オブジェクト、アクセスポイント、またはジョブの Amazon リソースネーム (ARN) を使用してリソースを識別します。
Amazon S3 リソースタイプとその ARN の完全なリストについては、「サービス認可リファレンス」の「Resources defined by Amazon S3」を参照してください。どのアクションで各リソースの ARN を指定できるかについては、「Amazon S3 で定義されるアクション」を参照してください。
S3 リソースタイプ別の S3 API オペレーションへのアクセス許可の詳細については、「Amazon S3 API オペレーションに必要なアクセス許可」を参照してください。
リソース ARN のワイルドカード文字
リソース ARN の一部にワイルドカードを使用できます。ARN セグメント (コロンで区切られている部分) でワイルドカード文字 (*
と ?
) を使用できます。アスタリスク (*
) は 0 個以上の文字の任意の組み合わせを表し、疑問符 (?
) は任意の 1 文字を表します。各セグメントで複数の *
または ?
文字を使用できます。ただし、ワイルドカード文字はセグメントをまたぐことはできません。
-
以下の ARN は ARN の
relative-ID
の部分でワイルドカード文字*
を使用して、
バケット内のすべてのオブジェクトを識別します。amzn-s3-demo-bucket
arn:aws:s3:::
amzn-s3-demo-bucket
/* -
次の ARN は
*
を使用して、S3 のすべてのバケットとオブジェクトを示しています。arn:aws:s3:::*
-
以下の ARN は、
relative-ID
の部分で、*
および?
の両方のワイルドカード文字を使用します。この ARN により、
、amzn-s3-demo-example1bucket
、amzn-s3-demo-example2bucket
など、バケット内のすべてのオブジェクトを識別します。amzn-s3-demo-example3bucket
arn:aws:s3:::
amzn-s3-demo-example
?bucket
/*
リソース ARN のポリシー変数
Amazon S3 の ARN では、ポリシー変数を使用することもできます。あらかじめ定義されているこれらの変数は、ポリシーの評価時に対応する値で置き換えられます。例えば、バケットをフォルダのコレクションとして構成し、ユーザーごとに別のフォルダを使用するとします。フォルダ名はユーザー名と同じです。各ユーザーに自分のフォルダに対するアクセス許可を付与するには、リソース ARN で以下のようにポリシー変数を指定します。
arn:aws:s3:::
bucket_name
/developers
/${aws:username}/
実行時にポリシーが評価されると、リソース ARN の変数 ${aws:username}
には、リクエストを行うユーザーのユーザー名が挿入されます。
Amazon S3 のポリシーの例
-
Amazon S3 のアイデンティティベースのポリシー例を確認するには、「Amazon S3 のアイデンティティベースのポリシー」を参照してください。
-
Amazon S3 のリソースベースのポリシー例を確認するには、「Amazon S3 のバケットポリシー」および「アクセスポイントを使用するための IAM ポリシーの設定」を参照してください。
Amazon S3 のポリシー条件キー
サービス固有のポリシー条件キーのサポート: あり
管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどんなリソースにどんな条件でアクションを実行できるかということです。
Condition
要素 (または Condition
ブロック) を使用すると、ステートメントが有効な条件を指定できます。Condition
要素はオプションです。イコールや未満などの 条件演算子 を使用して条件式を作成することで、ポリシーの条件とリクエスト内の値を一致させることができます。
1 つのステートメントに複数の Condition
要素を指定する場合、または 1 つの Condition
要素に複数のキーを指定する場合、AWSでは AND
論理演算子を使用してそれらを評価します。単一の条件キーに複数の値を指定する場合、AWS では OR
論理演算子を使用して条件を評価します。ステートメントの権限が付与される前にすべての条件が満たされる必要があります。
条件を指定する際にプレースホルダー変数も使用できます。例えば IAM ユーザーに、IAM ユーザー名がタグ付けされている場合のみリソースにアクセスできる権限を付与することができます。詳細については、IAM ユーザーガイドのIAM ポリシーの要素: 変数およびタグを参照してください。
AWS はグローバル条件キーとサービス固有の条件キーをサポートしています。すべての AWS グローバル条件キーを確認するには、IAM ユーザーガイド の「AWS グローバル条件コンテキストキー」を参照してください。
各 Amazon S3 条件キーは、その条件を設定できる API でサポートされている同じ名前のリクエストヘッダーに対応します。Amazon S3 固有の条件キーでは、同じ名前のリクエストヘッダーの動作が指定されます。例えば、アクセス許可 s3:GetObjectVersion
に対して条件付きのアクセス許可を付与する条件キー s3:VersionId
は、GET Object リクエストで設定する versionId
クエリパラメータの動作を定義します。
Amazon S3 の条件キーのリストを確認するには、「サービス認可リファレンス」の「Condition keys for Amazon S3」を参照してください。https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html#amazons3-policy-keysどのアクションおよびリソースで条件キーを使用できるかについては、「Amazon S3 で定義されるアクション」を参照してください。
例: オブジェクトのアップロードを特定のストレージクラスのオブジェクトに制限する
アカウント ID
で表されているアカウント A がバケットを所有しているとします。アカウント A の管理者は、アカウント A のユーザーである 123456789012
に対して、Dave
STANDARD_IA
ストレージクラスにオブジェクトが保存されている場合にのみ
がバケットにオブジェクトをロードすることを許可するとします。オブジェクトのアップロードを特定のストレージクラスに制限するために、アカウント A の管理者は、次のバケットポリシーの例に示すように Dave
s3:x-amz-storage-class
条件キーを使用できます。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
123456789012
:user/Dave
" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1
/*", "Condition": { "StringEquals": { "s3:x-amz-storage-class": [ "STANDARD_IA" ] } } } ] }
この例で、Condition
ブロックは指定されたキーと値のペア "s3:x-amz-acl":["public-read"]
に適用される StringEquals
条件を指定します。条件の表現に使用できる、事前に定義された一連のキーがあります。この例では、s3:x-amz-acl
条件キーを使用しています。この条件では、public-read
の値が指定された x-amz-acl
ヘッダーをすべての PutObject
リクエストに含めることがユーザーに求められます。
Amazon S3 のポリシーの例
-
Amazon S3 のアイデンティティベースのポリシー例を確認するには、「Amazon S3 のアイデンティティベースのポリシー」を参照してください。
-
Amazon S3 のリソースベースのポリシー例を確認するには、「Amazon S3 のバケットポリシー」および「アクセスポイントを使用するための IAM ポリシーの設定」を参照してください。
Amazon S3 での ACL
ACL のサポート: あり
Amazon S3 のアクセスコントロールリスト (ACL) は、どの AWS アカウント がリソースへのアクセス許可を持つかをコントロールします。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
重要
Amazon S3 の最新のユースケースの大部分では ACL を使用する必要がなくなっています。
Amazon S3 での ACL を使用したアクセスコントロールについては、「ACL によるアクセス管理」を参照してください。
Amazon S3 での ABAC
ABAC (ポリシー内のタグ) のサポート: 一部
属性ベースのアクセス制御 (ABAC) は、属性に基づいてアクセス許可を定義する認可戦略です。AWS では、属性は タグ と呼ばれます。タグは、IAM エンティティ (ユーザーまたはロール)、および多数の AWS リソースにアタッチできます。エンティティとリソースのタグ付けは、ABAC の最初の手順です。その後、プリンシパルのタグがアクセスしようとしているリソースのタグと一致した場合にオペレーションを許可するように ABAC ポリシーをします。
ABAC は、急成長する環境やポリシー管理が煩雑になる状況で役立ちます。
タグに基づいてアクセスを管理するには、aws:ResourceTag/
、key-name
aws:RequestTag/
、または key-name
aws:TagKeys
の条件キーを使用して、ポリシーの 条件要素でタグ情報を提供します。
サービスがすべてのリソースタイプに対して 3 つの条件キーすべてをサポートする場合、そのサービスの値はありです。サービスが一部のリソースタイプに対してのみ 3 つの条件キーのすべてをサポートする場合、値は「部分的」になります。
ABAC の詳細については、「IAM ユーザーガイド」の「ABAC 認可で属性に基づいてアクセス許可を定義する」を参照してください。ABAC をセットアップするステップを説明するチュートリアルについては、IAM ユーザーガイドの属性に基づくアクセスコントロール (ABAC) を使用するを参照してください。
タグに基づいて S3 バッチオペレーションジョブへのアクセスを制限するためのアイデンティティベースのポリシー例を確認するには、「ジョブタグを使用したバッチオペレーションのアクセス許可の制御」を参照してください。
ABAC とオブジェクトタグ
ABAC ポリシーでは、オブジェクトは aws:
タグの代わりに s3:
タグを使用します。オブジェクトタグに基づいてオブジェクトへのアクセスをコントロールするには、以下のタグを使用してポリシーの Condition 要素でタグ情報を指定します。
-
s3:ExistingObjectTag/
tag-key
-
s3:s3:RequestObjectTagKeys
-
s3:RequestObjectTag/
tag-key
アクセス許可ポリシーの例など、オブジェクトタグを使用したアクセスコントロールについては、「タグ付けとアクセスコントロールポリシー」を参照してください。
Amazon S3 での一時的な認証情報の使用
一時的な認証情報のサポート: あり
AWS のサービス には、一時的な認証情報を使用してサインインしても機能しないものがあります。一時的な認証情報を利用できる AWS のサービス を含めた詳細情報については、「IAM ユーザーガイド」の「IAM と連携する」AWS のサービスを参照してください。
ユーザー名とパスワード以外の方法で AWS Management Console にサインインする場合は、一時的な認証情報を使用していることになります。例えば、会社のシングルサインオン (SSO) リンクを使用して AWS にアクセスすると、そのプロセスは自動的に一時認証情報を作成します。また、ユーザーとしてコンソールにサインインしてからロールを切り替える場合も、一時的な認証情報が自動的に作成されます。ロールの切り替えに関する詳細については、「IAM ユーザーガイド」の「ユーザーから IAM ロールに切り替える (コンソール)」を参照してください。
一時認証情報は、AWS CLIまたは AWS API を使用して手動で作成できます。作成後、一時認証情報を使用して AWS にアクセスできるようになります。AWSは、長期的なアクセスキーを使用する代わりに、一時認証情報を動的に生成することをお勧めします。詳細については、IAM の一時的セキュリティ認証情報を参照してください。
Amazon S3 の転送アクセスセッション
転送アクセスセッション (FAS) のサポート: あり
IAM ユーザーまたはロールを使用して AWS でアクションを実行するユーザーは、プリンシパルとみなされます。一部のサービスを使用する際に、アクションを実行してから、別のサービスの別のアクションを開始することがあります。FAS は、AWS のサービスを呼び出すプリンシパルの権限を、AWS のサービスのリクエストと合わせて使用し、ダウンストリームのサービスに対してリクエストを行います。FAS リクエストは、サービスが、完了するために他の AWS のサービス またはリソースとのやりとりを必要とするリクエストを受け取ったときにのみ行われます。この場合、両方のアクションを実行するためのアクセス許可が必要です。FAS リクエストを行う際のポリシーの詳細については、「転送アクセスセッション」を参照してください。
SSE-KMS を使用してオブジェクトを暗号化した場合、Amazon S3 は FAS を使用してオブジェクトを復号化するための呼び出しを AWS KMS に対して行います。詳細については、「AWS KMS キーによるサーバー側の暗号化 (SSE-KMS) の使用」を参照してください。
S3 Access Grants も FAS を使用します。特定の ID の S3 データへのアクセス許可を作成すると、被付与者は S3 Access Grants に一時的な認証情報を要求します。S3 Access Grants は、AWS STS からリクエスタの一時的な認証情報を取得し、その認証情報をリクエスタに提供します。詳細については、「S3 Access Grants を介して Amazon S3 データへのアクセスをリクエストする」を参照してください。
Amazon S3 のサービスロール
サービスロールのサポート: あり
サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける IAM ロールです。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、「IAM ユーザーガイド」の「AWS のサービス にアクセス許可を委任するロールの作成」を参照してください。
警告
サービスロールのアクセス許可を変更すると、Amazon S3 が機能しなくなる可能性があります。サービスロールは、Amazon S3 で指示された場合のみ編集してください。
Amazon S3 のサービスリンクロール
サービスにリンクされたロールをサポート: 一部
サービスにリンクされたロールは、AWS のサービスにリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント に表示され、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。
Amazon S3 では、Amazon S3 Storage Lens 用のサービスにリンクされたロールをサポートしています。Amazon S3 でのサービスリンクロールの作成または管理の詳細については、「Amazon S3 ストレージレンズでのサービスにリンクされたロールの使用」を参照してください。
プリンシパルとしての Amazon S3 サービス
ポリシー内のサービス名 | S3 機能 | 詳細情報 |
---|---|---|
|
S3 レプリケーション |
|
|
S3 イベント通知 |
|
|
S3 インベントリ |
|
|
S3 Access Grants |
|
|
S3 バッチオペレーション |
|
|
S3 サーバーアクセスのログ記録 |
|
|
S3 Storage Lens |