Amazon S3 のアイデンティティベースのポリシー例
このセクションでは、Amazon S3 へのユーザーアクセスを管理するための AWS Identity and Access Management (IAM) アイデンティティベースポリシーをいくつか示します。バケットポリシー (リソースベースのポリシー) の例については、「Amazon S3 のバケットポリシー」を参照してください。IAM ポリシー言語については、「Amazon S3 のポリシーとアクセス許可」を参照してください。
次のサンプルポリシーは、プログラムで使用する場合に機能します。ただし、Amazon S3 コンソールでこれらを使用するには、コンソールに必要な追加のアクセス許可を付与する必要があります。このようなポリシーの Amazon S3 コンソールでの使用の詳細については、ユーザーポリシーを使用したバケットへのアクセスの制御 を参照してください。
S3 リソースタイプ別の S3 API オペレーションへのアクセス許可の詳細については、「Amazon S3 API オペレーションに必要なアクセス許可」を参照してください。
トピック
- バケット の 1 つへのアクセスを IAM ユーザーに許可する
- バケット内のフォルダへのアクセスを各 IAM ユーザーに許可する
- Amazon S3 で共有フォルダを持つことをグループに許可する
- すべてのユーザーに対し、バケットの特定部分のオブジェクトの読み取りを許可する
- パートナーに対し、バケットの特定部分へのファイルのドロップを許可する
- 特定の AWS アカウント の Amazon S3 バケットへのアクセスを制限する
- 組織単位内の Amazon S3 バケットへのアクセスを制限する
- 組織内の Amazon S3 バケットへのアクセスを制限する
- AWS アカウント に PublicAccessBlock 設定を取得するアクセス許可を付与する
- バケット作成を 1 つのリージョンに制限する
バケット の 1 つへのアクセスを IAM ユーザーに許可する
この例では、AWS アカウントの IAM ユーザーに amzn-s3-demo-bucket1
という 1 つのバケットに対する許可を付与して、ユーザーがオブジェクトを追加、更新、削除できるようにします。
このポリシーでは、ユーザーに s3:PutObject
、s3:GetObject
、s3:DeleteObject
のアクセス許可を付与するだけでなく、s3:ListAllMyBuckets
、s3:GetBucketLocation
、および s3:ListBucket
のアクセス許可も付与します。これらが、コンソールで必要とされる追加のアクセス許可です。またコンソール内のオブジェクトのコピー、カット、貼り付けを行うためには、s3:PutObjectAcl
および s3:GetObjectAcl
アクションが必要となります。コンソールを使用してユーザーにアクセス許可を付与してテストする例の解説については、ユーザーポリシーを使用したバケットへのアクセスの制御 を参照してください。
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action": "s3:ListAllMyBuckets", "Resource":"*" }, { "Effect":"Allow", "Action":["s3:ListBucket","s3:GetBucketLocation"], "Resource":"arn:aws:s3:::
amzn-s3-demo-bucket1
" }, { "Effect":"Allow", "Action":[ "s3:PutObject", "s3:PutObjectAcl", "s3:GetObject", "s3:GetObjectAcl", "s3:DeleteObject" ], "Resource":"arn:aws:s3:::amzn-s3-demo-bucket1
/*" } ] }
バケット内のフォルダへのアクセスを各 IAM ユーザーに許可する
次の例では、Mary と Carlos という 2 人の IAM ユーザーに amzn-s3-demo-bucket1
というバケットに対するアクセス許可を付与して、この 2 人がオブジェクトを追加、更新、削除できるようにします。ただし、バケット内の単一のプレフィックス (フォルダ) に全ユーザーのアクセスを制限したいとします。フォルダを作成する際、ユーザー名と同じフォルダ名にすることもできます。
amzn-s3-demo-bucket1
Mary
/Carlos
/
各ユーザーに本人のフォルダのみへのアクセス権を付与するには、各ユーザー用のポリシーを作成し、個別にアタッチします。例えば、Mary に次のポリシーをアタッチして、
フォルダに対する専用の Amazon S3 のアクセス許可を付与することができます。amzn-s3-demo-bucket1
/Mary
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "s3:PutObject", "s3:GetObject", "s3:GetObjectVersion", "s3:DeleteObject", "s3:DeleteObjectVersion" ], "Resource":"arn:aws:s3:::
amzn-s3-demo-bucket1
/Mary
/*" } ] }
その後、ユーザー Carlos に同様のポリシーをアタッチし、Resource
値のフォルダ
を指定します。Carlos
各ユーザーにポリシーをアタッチするのではなく、ポリシー変数を使用する単一のポリシーを作成し、そのポリシーをグループにアタッチできます。まずグループを作成し、Mary と Carlos をいずれもそのグループに追加する必要があります。次のポリシーの例では、
フォルダに対する Amazon S3 の一連のアクセス許可を付与しています。ポリシーが評価されると、ポリシー変数 amzn-s3-demo-bucket1
/${aws:username}${aws:username}
はリクエスタのユーザー名で置き換えられます。例えば、Mary がオブジェクトの PUT リクエストを送信した場合、Mary が
フォルダにオブジェクトをアップロードする PUT オペレーションのみが許可されます。amzn-s3-demo-bucket1
/Mary
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "s3:PutObject", "s3:GetObject", "s3:GetObjectVersion", "s3:DeleteObject", "s3:DeleteObjectVersion" ], "Resource":"arn:aws:s3:::
amzn-s3-demo-bucket1
/${aws:username}/*" } ] }
注記
ポリシー変数を使用する場合は、2012-10-17
をポリシー内で明示的に指定する必要があります。IAM ポリシー言語のデフォルトバージョンは 2008−10−17 です。このバージョンでは、ポリシー変数をサポートしていません。
Amazon S3 コンソールで前述のポリシーをテストする場合、次のポリシーに示すように、追加のアクセス許可が必要となります。これらのアクセス許可をコンソールで使用する方法については、ユーザーポリシーを使用したバケットへのアクセスの制御 を参照してください。
{ "Version":"2012-10-17", "Statement": [ { "Sid": "AllowGroupToSeeBucketListInTheConsole", "Action": [ "s3:ListAllMyBuckets", "s3:GetBucketLocation" ], "Effect": "Allow", "Resource": "arn:aws:s3:::*" }, { "Sid": "AllowRootLevelListingOfTheBucket", "Action": "s3:ListBucket", "Effect": "Allow", "Resource": "arn:aws:s3:::
amzn-s3-demo-bucket1
", "Condition":{ "StringEquals":{ "s3:prefix":[""], "s3:delimiter":["/"] } } }, { "Sid": "AllowListBucketOfASpecificUserPrefix", "Action": "s3:ListBucket", "Effect": "Allow", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1
", "Condition":{ "StringLike":{"s3:prefix":["${aws:username}/*"] } } }, { "Sid": "AllowUserSpecificActionsOnlyInTheSpecificUserPrefix", "Effect":"Allow", "Action":[ "s3:PutObject", "s3:GetObject", "s3:GetObjectVersion", "s3:DeleteObject", "s3:DeleteObjectVersion" ], "Resource":"arn:aws:s3:::amzn-s3-demo-bucket1
/${aws:username}/*" } ] }
注記
2012−10−17 バージョンのポリシーでは、ポリシー変数の先頭には $
が付きます。使用するオブジェクトキー (オブジェクト名) に $
が含まれている場合、この構文の変化により衝突が発生します。
この競合を回避するには、$
を使用して ${$}
文字を指定します。例えば、ポリシーにオブジェクトキー my$file
を含めるには、my${$}file
として指定します。
IAM ユーザー名は人間が読んで理解できるわかりやすい識別子ですが、グローバルで一意である必要はありません。例えば、Carlos が退職して別の Carlos が入社した場合、この別の Carlos が前の Carlos の情報にアクセスできます。
フォルダを作成する際に、ユーザー名の代わりに IAM ユーザー ID を使用することもできます。IAM ユーザー ID はそれぞれ一意であるためです。この場合、${aws:userid}
ポリシー変数を使用するように前述のポリシーを修正する必要があります。ユーザー ID の詳細については、「IAM ユーザーガイド」の「IAM 識別子」を参照してください。
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "s3:PutObject", "s3:GetObject", "s3:GetObjectVersion", "s3:DeleteObject", "s3:DeleteObjectVersion" ], "Resource":"arn:aws:s3:::
amzn-s3-demo-bucket1
/home/${aws:userid}/*" } ] }
バケット内のフォルダへのアクセスを非 IAM ユーザー (モバイルアプリユーザー) に許可する
ユーザーのデータを S3 バケットに保存するモバイルゲームアプリを開発するとします。バケットに各アプリユーザーのフォルダを作成します。また、各ユーザーには本人のフォルダのみにアクセスを制限します。 ただし、ユーザーがアプリをダウンロードしてゲームをプレイし始める前にフォルダを作成することはできません。お客様にはユーザーのユーザー ID がないためです。
この場合、ユーザーには、Login with Amazon、 Facebook、または Google などのパブリックアイデンティプロバイダを使用してアプリにサインインするよう要求できます。ユーザーがこれらのプロバイダの 1 つを使用してアプリにサインインすると、ユーザー ID が設定されるため、お客様はこれを使用して実行時にユーザー固有のフォルダを作成することができます。
これにより、AWS Security Token Service のウェブ認証フェデレーションを使用して、アイデンティプロバイダからの情報をアプリに組み入れ、各ユーザーの一時的なセキュリティ認証情報を取得することができます。続いて、IAM ポリシーを作成して、アプリがバケットにアクセスできるようにしたり、ユーザー固有のフォルダの作成、データのアップロードなどのオペレーションを実行できるようにすることができます。ウェブ ID フェデレーションの詳細については、IAM ユーザーガイドのウェブ ID フェデレーションについてを参照してください。
Amazon S3 で共有フォルダを持つことをグループに許可する
次のポリシーをグループにアタッチすることで、グループ内の全メンバーに Amazon S3 のフォルダ
へのアクセス権が付与されます。グループメンバーは、この指定のフォルダのオブジェクトに対してのみ、ポリシーに示されている Amazon S3 の特定のアクセス許可を付与されます。amzn-s3-demo-bucket1
/share/marketing
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "s3:PutObject", "s3:GetObject", "s3:GetObjectVersion", "s3:DeleteObject", "s3:DeleteObjectVersion" ], "Resource":"arn:aws:s3:::
amzn-s3-demo-bucket1
/share/marketing/*" } ] }
すべてのユーザーに対し、バケットの特定部分のオブジェクトの読み取りを許可する
次の例では、
というグループを作成し、AWS アカウントのすべての IAM ユーザーを含めます。次に、AllUsers
GetObject
フォルダ内のオブジェクトに対してのみ GetObjectVersion
と
のアクセス権をグループに付与するポリシーをアタッチします。amzn-s3-demo-bucket1
/readonly
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "s3:GetObject", "s3:GetObjectVersion" ], "Resource":"arn:aws:s3:::
amzn-s3-demo-bucket1
/readonly/*" } ] }
パートナーに対し、バケットの特定部分へのファイルのドロップを許可する
次の例では、パートナー会社を表す
というグループを作成します。パートナー会社でアクセス許可が必要な個人やアプリケーションのために IAM ユーザーを作成し、そのユーザーをグループに入れます。AnyCompany
次に、バケット内の次のフォルダに対する PutObject
アクセス権をグループに付与するポリシーをアタッチします。
amzn-s3-demo-bucket1
/uploads/anycompany
このバケットに対する他の操作を
グループに禁止するには、AnyCompany
PutObject
で Amazon S3 のリソースに対する AWS アカウント 以外の Amazon S3 のアクションを明示的に拒否するステートメントを追加します。
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":"s3:PutObject", "Resource":"arn:aws:s3:::
amzn-s3-demo-bucket1
/uploads/anycompany
/*" }, { "Effect":"Deny", "Action":"s3:*", "NotResource":"arn:aws:s3:::amzn-s3-demo-bucket1
/uploads/anycompany
/*" } ] }
特定の AWS アカウント の Amazon S3 バケットへのアクセスを制限する
Amazon S3 プリンシパルが信頼された内のリソースにのみアクセスしていることを確認する場合AWS アカウントでは、アクセスを制限できます。たとえば、このアイデンティティベースの IAM ポリシーは、Deny
効果を使用して Amazon S3 アクションへのアクセスをブロックします。ただし、アクセスされている Amazon S3 リソースがアカウント
内の場合は除きます。AWS アカウント の IAM プリンシパルがカウント外の Amazon S3 オブジェクトにアクセスすることを防止するには、次の IAM ポリシーをアタッチします。222222222222
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyS3AccessOutsideMyBoundary", "Effect": "Deny", "Action": [ "s3:*" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:ResourceAccount": [ "
222222222222
" ] } } } ] }
注記
このポリシーは、アクセス権を付与しないため、既存の IAM アクセスコントロールに置き換わるものではありません。代わりに、このポリシーは、他の IAM ポリシーによって付与されたアクセス権限に関係なく、他の IAM アクセス権限の追加ガードレールとして機能します。
ポリシーのアカウント ID
を自身のポリシー AWS アカウント に必ず置き換えます。この制限を維持しながら複数のアカウントにポリシーを適用するには、アカウント ID を 222222222222
aws:PrincipalAccount
条件キーに置き換えます。この条件では、プリンシパルとリソースが同じアカウントにある必要があります。
組織単位内の Amazon S3 バケットへのアクセスを制限する
AWS Organizations でセットアップされた組織単位 (OU)がある場合、Amazon S3 バケットのアクセスを組織の特定部分に制限することができます。この例では、aws:ResourceOrgPaths
キーを使って組織の OU へ Amazon S3 バケットのアクセスを制限します。この例では、OU ID は
です。自身のポリシーでこの値を自身の OU ID に置き換えてください。ou-acroot-exampleou
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3AccessOutsideMyBoundary", "Effect": "Allow", "Action": [ "s3:*" ], "Resource": "*", "Condition": { "ForAllValues:StringNotLike": { "aws:ResourceOrgPaths": [ "
o-acorg/r-acroot/ou-acroot-exampleou/
" ] } } } ] }
注記
このポリシーは、アクセス許可を付与しません。代わりに、このポリシーは、他の IAM アクセス権限のバックストップとして機能し、プリンシパルが OU 定義の境界外にある Amazon S3 オブジェクトにアクセスするのを防ぎます。
このポリシーは、アクセスされている Amazon S3 オブジェクトが組織内の
OU 内に存在しない場合、Amazon S3 アクションへのアクセスを拒否します。IAM ポリシー条件は、リストされた OU パスを含めるのに、複数値を持つ条件キー ou-acroot-exampleou
aws:ResourceOrgPaths
を要求します。このポリシーは、ForAllValues:StringNotLike
演算子を使用して aws:ResourceOrgPaths
の値をリストされた OU と比較します (大文字と小文字は区別しません)。
組織内の Amazon S3 バケットへのアクセスを制限する
組織内の Amazon S3 オブジェクトへのアクセスを制限するには、組織のルートに IAM ポリシーをアタッチし、組織内のすべてのアカウントに適用します。IAM プリンシパルにこのルールに従うように要求するには、サービスコントロールポリシー (SCP) を使用します。SCP を使用する場合は、組織のルートにポリシーをアタッチする前に、SCP のテストをしっかりと実行してください。
次のポリシー例では、アクセスされている Amazon S3 オブジェクトが、それにアクセスしている IAM プリンシパルと同じ組織内に存在しない限り、Amazon S3 アクションへのアクセスが拒否されます。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyS3AccessOutsideMyBoundary", "Effect": "Deny", "Action": [ "s3:*" ], "Resource": "arn:aws:s3:::*/*", "Condition": { "StringNotEquals": { "aws:ResourceOrgID": "${aws:PrincipalOrgID}" } } } ] }
注記
このポリシーは、アクセス許可を付与しません。代わりに、このポリシーは、他の IAM アクセス権限のバックストップとして機能し、プリンシパルが組織外にある Amazon S3 オブジェクトにアクセスするのを防ぎます。このポリシーは、ポリシーが有効になった後に作成される Amazon S3 リソースにも適用されます。
この例の IAM ポリシー条件では、互いに等しい aws:ResourceOrgID
および aws:PrincipalOrgID
が必要です。この要件では、リクエストを行うプリンシパルとアクセスされるリソースが同じ組織内になければなりません。
AWS アカウント に PublicAccessBlock 設定を取得するアクセス許可を付与する
以下のアイデンティティベースのポリシーの例は、ユーザーに s3:GetAccountPublicAccessBlock
のアクセス許可を付与します。これらのアクセス許可については、Resource
値を "*"
に設定します。リソース ARN については、「Amazon S3 のポリシーリソース」を参照してください。
{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Action":[ "s3:GetAccountPublicAccessBlock" ], "Resource":[ "*" ] } ] }
バケット作成を 1 つのリージョンに制限する
例えば、AWS アカウント の管理者がユーザー (Dave) に南米 (サンパウロ) リージョンでのみバケットを作成できる許可を付与するとします。アカウント管理者は、以下のように条件を指定して、s3:CreateBucket
のアクセス許可を付与する次のユーザーポリシーをアタッチします。Condition
ブロックのキーと値のペアは、s3:LocationConstraint
キーと、その値として sa-east-1
リージョンを指定します。
注記
この例では、バケット所有者はユーザーの 1 人にアクセス許可を付与するため、バケットポリシーまたはユーザーポリシーのどちらでも使用することができます。この例では、ユーザーポリシーを使用します。
Amazon S3 リージョンのリストについては、AWS 全般のリファレンス の「リージョンとエンドポイント」を参照してください。
{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Action": "s3:CreateBucket", "Resource": "arn:aws:s3:::*", "Condition": { "StringLike": { "s3:LocationConstraint": "sa-east-1" } } } ] }
明示的な拒否を追加する
上記のポリシーは、ユーザーが sa-east-1
以外のリージョンでバケットを作成することを制限します。ただし、他の一部のポリシーで、このユーザーに別のリージョンでバケットを作成するアクセス許可を付与する場合があります。例えば、ユーザーがグループに属している場合、グループのアクセス許可内にいるすべてのユーザーが別のリージョンでバケットを作成できるように、ポリシーがアタッチされている場合があります。ユーザーに別のリージョンでバケットを作成するアクセス許可が付与されないように、上記のポリシーに明示的な拒否のステートメントを追加します。
Deny
ステートメントは、StringNotLike
条件を使用します。つまり、場所の制約が sa-east-1
でない場合、バケットの作成リクエストは拒否されます。明示的な拒否を使用すれば、どのようなアクセス権限が付与されている場合でも、ユーザーは別のリージョンでバケットを作成できなくなります。次のポリシーには、明示的な拒否ステートメントが含まれています。
{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Action": "s3:CreateBucket", "Resource": "arn:aws:s3:::*", "Condition": { "StringLike": { "s3:LocationConstraint": "sa-east-1" } } }, { "Sid":"statement2", "Effect":"Deny", "Action": "s3:CreateBucket", "Resource": "arn:aws:s3:::*", "Condition": { "StringNotLike": { "s3:LocationConstraint": "sa-east-1" } } } ] }
AWS CLI でポリシーをテストする
このポリシーは、次の create-bucket
AWS CLI コマンドを使用してテストできます。この例では、bucketconfig.txt
ファイルを使用して場所の制約を指定しています。Windows ファイルパスに注目してください。バケットの名前とパスを適切に更新する必要があります。--profile
パラメータを使用して、ユーザーの認証情報を指定する必要があります。AWS CLI のセットアップと使用の詳細については、「Amazon S3 API リファレンス」の「Developing with Amazon S3 using the AWS CLI」を参照してください。
aws s3api create-bucket --bucket
examplebucket
--profile AccountADave --create-bucket-configuration file://c:/Users/someUser/bucketconfig.txt
bucketconfig.txt
ファイルは、次のように設定を指定します。
{"LocationConstraint": "sa-east-1"}