バケットポリシーの例 - Amazon Simple Storage Service
匿名ユーザーへの読み取り専用アクセス許可の付与 暗号化が必要定型の ACL を使ったバケットの管理オブジェクトタグ付けによるオブジェクトアクセスの管理グローバル条件キーによるオブジェクトアクセスの管理特定の IP アドレスに基づくアクセス管理HTTP または HTTPS リクエストに基づくアクセス管理特定のフォルダへのユーザーアクセスの管理アクセスログへのアクセス管理Amazon CloudFront の OAI へのアクセス管理Amazon S3 ストレージレンズへのアクセス管理S3 インベントリ、S3 分析、および S3 インベントリレポートの権限管理MFA が必要

バケットポリシーの例

Amazon S3 バケットポリシーを使用すると、バケット内のオブジェクトへのアクセスを保護して、適切な権限を持つユーザーだけがアクセスできるようにすることができます。適切な権限を持たない認証済みユーザーが Amazon S3 リソースにアクセスできないようにすることもできます。

このセクションでは、バケットポリシーの一般的なユースケース例を紹介します。これらのサンプルポリシーは、DOC-EXAMPLE-BUCKET をリソース値として使用します。これらのポリシーをテストするには、user input placeholders をお客様の情報 (バケット名など) と置き換えます。

オブジェクトのセットに対するアクセス許可を付与または拒否するために、Amazon リソースネーム (ARN) やその他の値でワイルドカード文字 (*) を使用できます。例えば、共通のプレフィックスで始まるか、.html などの特定の拡張子で終わるオブジェクトのグループへのアクセスをコントロールできます。

AWS Identity and Access Management (IAM) ポリシー言語については、「Amazon S3 のポリシーとアクセス許可」を参照してください。

注記

Amazon S3 コンソールを使用して許可をテストするときには、コンソールに必要な s3:ListAllMyBuckets、s3:GetBucketLocation、s3:ListBucket を追加で付与する必要があります。コンソールを使用してユーザーにアクセス許可を付与してテストする例の解説については、「ユーザーポリシーを使用したバケットへのアクセスの制御」を参照してください。

バケットポリシーを作成するためのその他のリソース

匿名ユーザーへの読み取り専用アクセス許可の付与

ポリシー設定を使用して、一般の匿名ユーザーにアクセス権を付与できます。これは、バケットを静的ウェブサイトとして設定する場合に便利です。そのためには、バケットへのパブリックアクセスのブロックを無効にする必要があります。これを行う方法と必要なポリシーの詳細については、「ウェブサイトアクセスのアクセス許可の設定」を参照してください。同じ目的でより制限の厳しいポリシーを設定する方法については、「Amazon S3 バケット内の一部のオブジェクトへのパブリック読み取りアクセスを許可するにはどうすればよいですか?」を参照してください。

デフォルトでは、Amazon S3 はアカウントとバケットへのパブリックアクセスをブロックします。バケットを使用して静的ウェブサイトをホストする場合は、以下のステップを使用して、パブリックアクセスブロック設定を編集できます。

警告

このステップを完了する前に「Amazon S3 ストレージへのパブリックアクセスのブロック」を読んで、パブリックアクセスを許可することに伴うリスクを理解し、了承します。パブリックアクセスブロック設定をオフにしてバケットをパブリックにすると、インターネット上のだれでもバケットにアクセスできるようになります。バケットへのすべてのパブリックアクセスをブロックすることをお勧めします。

  1. https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。

  2. 静的ウェブサイトとして設定されたバケットの名前を選択します。

  3. [Permissions (アクセス許可)] を選択します。

  4. [Block public access (bucket settings) (ブロックパブリックアクセスの(バケット設定))] で [編集] を選択します。

  5. [Block all public access (すべてのパブリックアクセスをブロックする)] をクリアし、[Save changes (変更の保存)] を選択します。

    警告

    このステップを完了する前に、「Amazon S3 ストレージへのパブリックアクセスのブロック」を確認し、パブリックアクセスの許可に伴うリスクを理解したうえで了承してください。パブリックアクセスブロック設定をオフにしてバケットをパブリックにすると、インターネット上のだれでもバケットにアクセスできるようになります。バケットへのすべてのパブリックアクセスをブロックすることをお勧めします。

    Amazon S3 は、バケットのパブリックアクセスブロック設定をオフにします。パブリックで静的ウェブサイトを作成するには、バケットポリシーを追加する前に、アカウントのブロックパブリックアクセス設定を編集する必要があります。パブリックアクセスのブロックのアカウント設定が現在有効になっている場合は、[Block public access (bucket settings) (パブリックアクセスのブロック (バケット設定))] の下にメモが表示されます。

暗号化が必要

バケットに書き込まれるすべてのオブジェクトに SSE-KMS が必要

次のポリシー例では、バケットに書き込まれるすべてのオブジェクトを、AWS Key Management Service (AWS KMS) キーを使用したサーバー側の暗号化 (SSE-KMS) を使用して暗号化することを要求しています。オブジェクトが SSE-KMS で暗号化されていない場合、リクエストは拒否されます。

{
"Version": "2012-10-17",
"Id": "PutObjPolicy",
"Statement": [{
  "Sid": "DenyObjectsThatAreNotSSEKMS",
  "Principal": "*",
  "Effect": "Deny",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
  "Condition": {
    "Null": {
      "s3:x-amz-server-side-encryption-aws-kms-key-id": "true"
    }
  }
}]
}

バケットに書き込まれるすべてのオブジェクトに特定の AWS KMS key を使用する SSE-KMS が必要

次のポリシー例では、特定の KMS キー ID を使用して SSE-KMS で暗号化されていないオブジェクトはバケットに書き込まれません。オブジェクトがリクエストごとのヘッダーまたはバケットのデフォルト暗号化を使用して SSE-KMS で暗号化されている場合でも、特定の KMS キーで暗号化されていないオブジェクトはバケットに書き込めません。この例で使用している KMS キー ARN を必ずお客様の KMS キー ARN に置き換えてください。

{
"Version": "2012-10-17",
"Id": "PutObjPolicy",
"Statement": [{
  "Sid": "DenyObjectsThatAreNotSSEKMSWithSpecificKey",
  "Principal": "*",
  "Effect": "Deny",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
  "Condition": {
    "ArnNotEqualsIfExists": {
      "s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-2:111122223333:key/01234567-89ab-cdef-0123-456789abcdef"
    }
  }
}]
}

定型の ACL を使ったバケットの管理

オブジェクトをアップロードしたり、パブリックアクセス用のオブジェクト ACL を設定したりする権限を複数のアカウントに付与する

次のポリシーの例では、s3:PutObject および s3:PutObjectAcl 許可を複数の AWS アカウントに付与し、これらのオペレーションのリクエストに public-read という既定のアクセスコントロールリスト (ACL) が含まれることを要求しています。詳細については、Amazon S3 ポリシーアクションおよびAmazon S3 条件キーの例を参照してください。

警告

public-read という既定の ACL を使用すると、バケット内のオブジェクトを世界中の誰でも見ることができます。Amazon S3 のバケットへの匿名アクセスを許可したり、パブリックアクセスブロック設定を無効にしたりする場合は注意が必要です。匿名アクセスを付与すると、世界中のすべてのユーザーがバケットにアクセスできます。静的なウェブサイトのホスティングなどで特に必要な場合を除いて、Amazon S3 のバケットへの匿名アクセスは許可しないことをお勧めします。静的ウェブサイトホスティングのパブリックアクセスをブロックする設定を有効にする場合は、「チュートリアル: Amazon S3 での静的ウェブサイトの設定」を参照してください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AddPublicReadCannedAcl",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111122223333:root",
                    "arn:aws:iam::444455556666:root"
                ]
            },
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl"
            ],
            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": [
                        "public-read"
                    ]
                }
            }
        }
    ]
}

バケット所有者はフルコントロール権限を持ちながら、オブジェクトをアップロードするためのクロスアカウントアクセス許可を付与する

以下の例は、アップロードされたオブジェクトを完全に制御しながら、別の AWS アカウント がバケットにオブジェクトをアップロードできるようにする方法を示しています。このポリシーでは、特定の AWS アカウント (111122223333) に、アップロード時に bucket-owner-full-control の既定 ACL が含まれている場合にのみ、オブジェクトをアップロードする機能が付与されます。ポリシーの StringEquals 条件は、要件を表現する s3:x-amz-acl 条件キーを指定します。詳細については、「Amazon S3 条件キーの例」を参照してください。

{
   "Version":"2012-10-17",
   "Statement":[
     {
       "Sid":"PolicyForAllowUploadWithACL",
       "Effect":"Allow",
       "Principal":{"AWS":"111122223333"},
       "Action":"s3:PutObject",
       "Resource":"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
       "Condition": {
         "StringEquals": {"s3:x-amz-acl":"bucket-owner-full-control"}
       }
     }
   ]
}

オブジェクトタグ付けによるオブジェクトアクセスの管理

特定のタグキーと値を持つオブジェクトの読み取り権限のみをユーザーに許可する

以下のアクセス許可ポリシーでは、environment: production タグキーと値を持つオブジェクトのみを読み取れるように制限しています。このポリシーは s3:ExistingObjectTag 条件キーを使用してタグキーと値を指定します。

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Principal":{
            "AWS":"arn:aws:iam::111122223333:role/JohnDoe"
         },
         "Effect":"Allow",
         "Action":[
            "s3:GetObject",
            "s3:GetObjectVersion"
         ],
         "Resource":"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
         "Condition":{
            "StringEquals":{
               "s3:ExistingObjectTag/environment":"production"
            }
         }
      }
   ]
}

ユーザーが追加できるオブジェクトタグキーを制限する

次のポリシーの例では、s3:PutObjectTagging アクションを実行するアクセス許可をユーザーに付与します (ユーザーが既存のオブジェクトにタグを追加することができます)。この条件は s3:RequestObjectTagKeys 条件キーを使用して、Owner や CreationDate などの許可されたタグキーを指定します。詳細については、「IAM ユーザーガイド」の「複数のキーの値をテストする条件の作成」を参照してください。

このポリシーは、リクエストで指定されたすべてのタグキーが承認されたタグキーであることを保証します。条件の ForAnyValue 修飾子によって、指定したキーの少なくとも 1 つがリクエストに存在することが保証されます。

{
   "Version": "2012-10-17",
  "Statement": [
    {"Principal":{"AWS":[
            "arn:aws:iam::111122223333:role/JohnDoe"
         ]
       },
 "Effect": "Allow",
      "Action": [
        "s3:PutObjectTagging"
      ],
      "Resource": [
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
      ],
      "Condition": {"ForAnyValue:StringEquals": {"s3:RequestObjectTagKeys": [
            "Owner",
            "CreationDate"
          ]
        }
      }
    }
  ]
}

ユーザーにオブジェクトタグの追加を許可する場合は特定のタグキーと値が必要

次のポリシーの例では、s3:PutObjectTagging アクションを実行するアクセス許可をユーザーに付与します (ユーザーが既存のオブジェクトにタグを追加することができます)。この条件により、値が X に設定された特定のタグキー (Project など) をユーザーが含めることが求められます。

{
   "Version": "2012-10-17",
  "Statement": [
    {"Principal":{"AWS":[
       "arn:aws:iam::111122223333:user/JohnDoe"
         ]
       },
      "Effect": "Allow",
      "Action": [
        "s3:PutObjectTagging"
      ],
      "Resource": [
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
      ],
      "Condition": {"StringEquals": {"s3:RequestObjectTag/Project": "X"
        }
      }
    }
  ]
}

特定のオブジェクトタグキーと値を持つオブジェクトのみを追加することをユーザーに許可する

次のポリシーの例では、s3:PutObject アクションを実行する権限をユーザーに付与して、ユーザーがバケットにオブジェクトを追加できるようにします。ただし、Condition ステートメントは、アップロードされたオブジェクトで使用できるタグキーと値を制限します。この例では、ユーザーがバケットに追加できるのは、値が Finance に設定された特定のタグキー (Department) を持つオブジェクトだけです。

{
    "Version": "2012-10-17",
    "Statement": [{
        "Principal":{
            "AWS":[
                 "arn:aws:iam::111122223333:user/JohnDoe"
         ]
        },
        "Effect": "Allow",
        "Action": [
            "s3:PutObject"
        ],
        "Resource": [
            "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
        ],
        "Condition": {
            "StringEquals": {
                "s3:RequestObjectTag/Department": "Finance"
            }
        }
    }]
}

グローバル条件キーによるオブジェクトアクセスの管理

グローバル条件キーは、aws プレフィックスが付いた条件キーです。AWS のサービス のサービスは、グローバル条件キーをサポートするか、サービスプレフィックスを含むサービス固有のキーを提供できます。JSON ポリシーの Condition 要素を使用して、リクエストのキーを、ポリシーで指定したキー値と比較できます。

Amazon S3 サーバーアクセスログ配信のみに制限する

次の例のバケットポリシーでは、aws:SourceArn グローバル条件キーを使用して、サービス間リクエストを行っているリソースの Amazon リソースネーム (ARN) を、ポリシーで指定した ARN と比較します。aws:SourceArn 条件キーを使用して、サービス間のトランザクション中に Amazon S3 サービスが混乱した代理として使用されるのを防ぐことができます。Amazon S3 バケットにオブジェクトを追加できるのは Amazon S3 サービスのみです。

この例のバケットポリシーは、ロギングサービスプリンシパル (s3:PutObject) にのみ logging.s3.amazonaws.com 許可を付与します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPutObjectS3ServerAccessLogsPolicy",
            "Principal": {
                "Service": "logging.s3.amazonaws.com"
            },
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET-logs/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111111111111"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:s3:::EXAMPLE-SOURCE-BUCKET"
                }
            }
        },
        {
            "Sid": "RestrictToS3ServerAccessLogs",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET-logs/*",
            "Condition": {
                "ForAllValues:StringNotEquals": {
                    "aws:PrincipalServiceNamesList": "logging.s3.amazonaws.com"
                }
            }
        }
    ]
}

自分の組織にのみアクセスを許可

リソースにアクセスするすべての IAM プリンシパルが組織内の AWS アカウント (AWS Organizations管理アカウントを含む) からのアクセスのみに制限する場合は、aws:PrincipalOrgID グローバル条件キーを使用できます。

このタイプのアクセスを許可または制限するには、aws:PrincipalOrgID 条件を定義し、バケットポリシーの組織 ID に値を設定します。組織 ID は、バケットへのアクセスを制御するために使用されます。aws:PrincipalOrgID 条件を使用すると、バケットポリシーのアクセス許可は、組織に追加されるすべての新しいアカウントにも適用されます。

以下は、組織内の特定の IAM プリンシパルにバケットへの直接アクセス許可を付与できるリソースベースのバケットポリシーの例です。バケットポリシーに aws:PrincipalOrgID グローバル条件キーを追加すると、リソースにアクセスするにはプリンシパルアカウントが組織内に存在する必要があります。アクセスを許可するときに誤って間違ったアカウントを指定した場合でも、aws:PrincipalOrgID グローバル条件キーは追加の保護手段として機能します。このグローバルキーをポリシーで使用すると、指定した組織以外のすべてのプリンシパルが、Amazon S3 バケットにアクセスできないようにします。リソースへのアクセス権を取得できるのは、リストにある組織のアカウントのプリンシパルだけです。

{
    "Version": "2012-10-17",
    "Statement": [{
        "Sid": "AllowGetObject",
        "Principal": {
            "AWS": "*"
        },
        "Effect": "Allow",
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
        "Condition": {
            "StringEquals": {
                "aws:PrincipalOrgID": ["o-aa111bb222"]
            }
        }
    }]
}

特定の IP アドレスに基づくアクセス管理

特定の IP アドレスへのアクセスの制限

以下の例では、リクエストが指定した IP アドレス範囲からのものでない限り、指定したバケット内のオブジェクトに対してユーザーが Amazon S3 のオペレーションを実行できないようにします。

注記

特定の IP アドレスへのアクセスを制限する場合は、S3 バケットにアクセスできる VPC エンドポイント、VPC ソース IP アドレス、または外部 IP アドレスも必ず指定してください。そうしないと、適切な権限がまだ設定されていない限り、すべてのユーザーがバケット内のオブジェクトに対して S3 オペレーションを実行することをポリシーで拒否すると、バケットにアクセスできなくなる可能性があります。

このポリシーの Condition ステートメントは、許可されたインターネットプロトコルバージョン 4 (IPv4) の IP アドレスの範囲として、192.0.2.0/24 を識別します。

Condition ブロックでは、NotIpAddress 条件と aws:SourceIp 条件キー (AWS 全体をターゲットとする条件キー) を使用します。aws:SourceIp 条件キーは、パブリック IP アドレス範囲にのみ使用できます。これらの条件キーの詳細については、Amazon S3 条件キーの例 を参照してください。aws:SourceIp IPv4 値は標準の CIDR 表記を使用します。詳細については、IAM ユーザーガイドの「IAM JSON ポリシー要素のリファレンス」を参照してください。

警告

このポリシーを使用する前に、この例の 192.0.2.0/24 IP アドレス範囲をユースケースに適した値に置き換えてください。置き換えないと、バケットにアクセスできなくなります。

{
    "Version": "2012-10-17",
    "Id": "S3PolicyId1",
    "Statement": [
        {
            "Sid": "IPAllow",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
            ],
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": "192.0.2.0/24"
                }
            }
        }
    ]
}

IPv4 アドレスと IPv6 アドレスの許可

IPv6 アドレスの使用を開始する場合は、既存の IPv4 アドレス範囲に IPv6 アドレス範囲を追加して組織のすべてのポリシーを更新することをお勧めします。こうすることで、IPv6への移行後もポリシーが引き続き機能するようになります。

以下のバケットポリシーの例は、組織の有効な IP アドレスすべてを含めるために、IPv4 アドレス範囲と IPv6 アドレス範囲を混在させる方法を示しています。このポリシーの例では、サンプル IP アドレス (192.0.2.1 および 2001:DB8:1234:5678::1) へのアクセスを許可したり、アドレス 203.0.113.1 および 2001:DB8:1234:5678:ABCD::1 へのアクセスを拒否したりできます。

aws:SourceIp 条件キーは、パブリック IP アドレス範囲にのみ使用できます。aws:SourceIp の IPv6 の値は、標準の CIDR 形式で指定する必要があります。IPv6 では、0 の範囲を表すために :: の使用がサポートされています (例:2001:DB8:1234:5678::/64)。詳細については、IAM ユーザーガイドの IP アドレス条件演算子 を参照してください。

警告

このポリシーを使用する前に、この例の IP アドレス範囲をユースケースに適した値に置き換えます。置き換えないと、バケットにアクセスできなくなる可能性があります。

{
    "Id": "PolicyId2",
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowIPmix",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
            ],
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": [
                        "192.0.2.0/24",
                        "2001:DB8:1234:5678::/64"
                    ]
                },
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "203.0.113.0/24",
                        "2001:DB8:1234:5678:ABCD::/80"
                    ]
                }
            }
        }
    ]
}

HTTP または HTTPS リクエストに基づくアクセス管理

HTTPS リクエストのみにアクセスを制限

潜在的な攻撃者がネットワークトラフィックを操作するのを防ぎたい場合は、HTTPS (TLS) を使用して暗号化された接続のみを許可し、HTTP リクエストによるバケットへのアクセスを制限できます。リクエストが HTTP か HTTPS かを判断するには、S3 バケットポリシーの aws:SecureTransport グローバル条件キーを使用します。aws:SecureTransport 条件キーは、リクエストが HTTP を使用して送信されたかどうかをチェックします。

リクエストが true を返した場合、リクエストは HTTPS 経由の送信です。リクエストが false を返した場合、リクエストは HTTP 経由の送信です。その後、目的のリクエストスキームに基づいてバケットへのアクセスを許可または拒否することができます。

次の例で、バケットポリシーは HTTP リクエストを明示的に拒否しています。

{
    "Version": "2012-10-17",
    "Statement": [{
        "Sid": "RestrictToTLSRequestsOnly",
        "Action": "s3:*",
        "Effect": "Deny",
        "Resource": [
            "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
            "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
        ],
        "Condition": {
            "Bool": {
                "aws:SecureTransport": "false"
            }
        },
        "Principal": "*"
    }]
}

特定の HTTP Referer へのアクセスの制限

DOC-EXAMPLE-BUCKET というバケットに格納されている写真や動画へのリンクがある www.example.com または example.com というドメイン名のウェブサイトがあるとします。デフォルトでは、Amazon S3 のすべてのリソースはプライベートであるため、リソースを作成した AWS アカウント のみがアクセスできます。

これらのオブジェクトへのウェブサイトの読み取りアクセスを許可するには、s3:GetObject アクセス許可を条件付きで付与するバケットポリシーを追加する方法があります。条件としては、GET リクエストが特定のウェブページから発生する必要があることを指定します。次のポリシーでは、aws:Referer 条件キー付きの StringLike 条件を使用してリクエストを制限します。

{
  "Version":"2012-10-17",
  "Id":"HTTP referer policy example",
  "Statement":[
    {
      "Sid":"Allow only GET requests originating from www.example.com and example.com.",
      "Effect":"Allow",
      "Principal":"*",
      "Action":["s3:GetObject","s3:GetObjectVersion"],
      "Resource":"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
      "Condition":{
        "StringLike":{"aws:Referer":["http://www.example.com/*","http://example.com/*"]}
      }
    }
  ]
}

使用するブラウザのリクエストに HTTP referer ヘッダーが含まれていることを確認します。

警告

aws:Referer 条件キーを使用するときには、十分な注意が必要です。一般に知られている HTTP 参照子のヘッダー値を含めるのは危険です。不正な当事者は、変更されたブラウザまたはカスタムブラウザを使用して任意の aws:Referer 値を提供することができます。したがって、無許可の当事者が AWS リクエストを直接作成できないよう、aws:Referer を使用しないでください。

この aws:Referer 条件キーは、Amazon S3 に保存されているコンテンツなどのデジタルコンテンツが、無許可のサードパーティーサイトで参照されないよう保護する目的でのみ、お客様に提供されています。詳細については、IAM ユーザーガイドaws:Refererの を参照してください。

特定のフォルダへのユーザーアクセスの管理

特定のフォルダへのアクセス許可をユーザーに付与

特定のフォルダへのアクセスをユーザーに許可しようとしているとします。IAM ユーザーと S3 バケットが同じ AWS アカウント に属している場合は、IAM ポリシーを使用してユーザーに特定のバケットフォルダへのアクセス許可を付与できます。このアプローチを使用すると、バケットポリシーを更新してアクセスを付与する必要はありません。複数のユーザーが切り替えることができる IAM ロールに IAM ポリシーを追加できます。

IAM ID と S3 バケットの AWS アカウント が異なる場合は、IAM ポリシーとバケットポリシーの両方でクロスアカウントアクセスを許可する必要があります。クロスアカウントアクセスを付与する方法の詳細については、「バケット所有者がクロスアカウントのバケットのアクセス許可を付与する」を参照してください。

次のバケットポリシーの例では、自分のフォルダ (home/JohnDoe/) のみにJohnDoe のフルコンソールアクセスを許可しています。home フォルダを作成し、ユーザーに適切なアクセス許可を付与することで、複数のユーザーが 1 つのバケットを共有できます。このポリシーは、次の 3 つの Allow ステートメントで構成されています。

  • AllowRootAndHomeListingOfCompanyBucket: ユーザー (JohnDoe) が DOC-EXAMPLE-BUCKET バケットのルートレベルと home フォルダ内のオブジェクトを一覧表示できるようにします。このステートメントにより、ユーザーはコンソールを使用してプレフィックス home/ を検索することもできます。

  • AllowListingOfUserFolder: ユーザー (JohnDoe) が home/JohnDoe/ フォルダとサブフォルダ内のすべてのオブジェクトを一覧表示できるようにします。

  • AllowAllS3ActionsInUserFolder: Read、Write、Delete 権限を付与することで、ユーザーが Amazon S3 のすべてのアクションを実行できるようにします。権限はバケット所有者のホームフォルダに限定されます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowRootAndHomeListingOfCompanyBucket",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111122223333:user/JohnDoe"
                ]
            },
            "Effect": "Allow",
            "Action": ["s3:ListBucket"],
            "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET"],
            "Condition": {
                "StringEquals": {
                    "s3:prefix": ["", "home/", "home/JohnDoe"],
                    "s3:delimiter": ["/"]
                }
            }
        },
        {
            "Sid": "AllowListingOfUserFolder",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111122223333:user/JohnDoe"
                ]
            },
            "Action": ["s3:ListBucket"],
            "Effect": "Allow",
            "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET"],
            "Condition": {
                "StringLike": {
                    "s3:prefix": ["home/JohnDoe/*"]
                }
            }
        },
        {
            "Sid": "AllowAllS3ActionsInUserFolder",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111122223333:user/JohnDoe"
                ]
            },
            "Action": ["s3:*"],
            "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET/home/JohnDoe/*"]
        }
    ]
}

アクセスログへのアクセス管理

アクセスログを有効にするためのアクセス権限を Application Load Balancer に付与

Application Load Balancer のアクセスログを有効にする場合は、ロードバランサーがログを保存する S3 バケットの名前を指定する必要があります。このバケットは、バケットにアクセスログを書き込む許可を Elastic Load Balancing に付与するアタッチされたポリシーが必要です。

次の例では、バケットポリシーにより、バケットにアクセスログを書き込む許可を Elastic Load Balancing (ELB) に付与しています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Principal": {
        "AWS": "arn:aws:iam::elb-account-id:root"
      },
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/prefix/AWSLogs/111122223333/*"
    }
  ]
}
注記

必ず、elb-account-id を、ご利用の AWS リージョン における Elastic Load Balancing の AWS アカウント ID に置き換えてください。Elastic Load Balancing リージョンのリストについては、「Elastic Load Balancing ユーザーガイド」の「Amazon S3 バケットにポリシーをアタッチする」を参照してください。

ご利用の AWS リージョン がサポートされている Elastic Load Balancing リージョンのリストに表示されない場合は、次のポリシーを使用して、指定されたログ配信サービスにアクセス許可を付与します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
       "Principal": {
         "Service": "logdelivery.elasticloadbalancing.amazonaws.com"
          },
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/prefix/AWSLogs/111122223333/*"
    }
  ]
}

次に、必ず Elastic Load Balancing のアクセスログを有効にして設定してください。テストファイルを作成することで、バケットのアクセス許可を確認できます。

Amazon CloudFront の OAI へのアクセス管理

Amazon CloudFront の OAI へのアクセス許可の付与

次のバケットポリシーの例は、CloudFront のオリジンアクセスアイデンティティ (OAI) に S3 のバケット内のすべてのオブジェクトを取得 (読み取り) するアクセス許可を付与します。CloudFront の OAI を使用すると、バケット内のオブジェクトへの CloudFront からのアクセスは許可して、Amazon S3 からの直接アクセスは許可しないようにすることができます。詳細については、「Amazon CloudFront デベロッパーガイド」の「オリジンアクセス ID を使用して Amazon S3 コンテンツへのアクセスを制限する」を参照してください。

次のポリシーは、OAI の ID をポリシーの Principal として使用します。S3 のバケットポリシーを使用して CloudFront の OAI にアクセス許可を付与する方法の詳細については、「Amazon CloudFront デベロッパーガイド」の「オリジンアクセスアイデンティティ (OAI) からオリジンアクセスコントロール (OAC) への移行」を参照してください。

この例を使用するには:

{
    "Version": "2012-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EH1HDMB1FH2TC"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
        }
    ]
}

Amazon S3 ストレージレンズへのアクセス管理

Amazon S3 ストレージレンズへのアクセス許可の付与

S3 ストレージレンズはメトリクスを集約し、Amazon S3 コンソールの [Buckets] (バケット) ページの [Account snapshot] (アカウントスナップショット) セクションにこの情報を表示します。S3 Storage Lens は、インサイトと傾向を可視化したり、外れ値にフラグ付けしたり、ストレージコストの最適化やデータ保護のベストプラクティスの適用に関するレコメンデーション事項を受け取ったりするために使用できるインタラクティブダッシュボードも提供します。ダッシュボードには、組織、アカウント、AWS リージョン、バケット、オブジェクト、またはプレフィックス、または Storage Lens グループレベルでインサイトを生成して可視化できる、ドリルダウンオプションが用意されています。1 日 1 回のメトリクスのエクスポートを CSV 形式または Parquet 形式で S3 バケットに送信することもできます。

S3 ストレージレンズは、収集したストレージ使用量のメトリクスをさらなる分析のため Amazon S3 バケット内にエクスポートできます。S3 Storage Lens がメトリクスのエクスポートを配置するバケットは、送信先バケットとして知られています。S3 Storage Lens のメトリクスエクスポートを設定するとき、ターゲットバケットにバケットポリシーを作成する必要があります。詳細については、「Amazon S3 ストレージレンズを使用してストレージのアクティビティと使用状況を評価する」を参照してください。

次のバケットポリシーの例では、Amazon S3 が送信先バケットにオブジェクトを書き込む (PUT リクエスト) ためのアクセス許可が付与されます。S3 Storage Lens メトリクスのエクスポートを設定するときには、このようなバケットポリシーを送信先バケットに使用します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3StorageLensExamplePolicy",
            "Effect": "Allow",
            "Principal": {
                "Service": "storage-lens.s3.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": [
                "arn:aws:s3:::destination-bucket/destination-prefix/StorageLens/111122223333/*"
            ],
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control",
                    "aws:SourceAccount": "111122223333",
                    "aws:SourceArn": "arn:aws:s3:region-code:111122223333:storage-lens/storage-lens-dashboard-configuration-id"
                }
            }
        }
    ]
}

S3 ストレージレンズの組織レベルのメトリクスエクスポートを設定するときには、前述のバケットポリシーの Resource ステートメントに次の変更を加えます。


"Resource": "arn:aws:s3:::destination-bucket/destination-prefix/StorageLens/your-organization-id/*",

S3 インベントリ、S3 分析、および S3 インベントリレポートの権限管理

S3 インベントリおよび S3 分析に対するアクセス許可の付与

S3 インベントリでは、バケット内のオブジェクトのリストが作成され、S3 分析のエクスポートでは、分析に使用されるデータの出力ファイルが作成されます。インベントリによってオブジェクトがリストされるバケットは、ソースバケットと呼ばれます。インベントリファイルと、分析エクスポートファイルが書き込まれるバケットは、ターゲットバケットと呼ばれます。インベントリまたは分析のエクスポートを設定する場合、ターゲットバケットにバケットポリシーを作成する必要があります。詳細については、Amazon S3 インベントリおよびAmazon S3 分析 – ストレージクラス分析を参照してください。

次のバケットポリシーの例では、ソースバケットのアカウントからターゲットバケットにオブジェクトを書き込む (PUT リクエスト) ための Amazon S3 のアクセス許可が付与されます。このようなバケットポリシーは、S3 インベントリと S3 分析エクスポートをセットアップするときに、宛先バケットで使用します。

{  
      "Version": "2012-10-17",
      "Statement": [
        {
            "Sid": "InventoryAndAnalyticsExamplePolicy",
            "Effect": "Allow",
            "Principal": {
                "Service": "s3.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": [
                "arn:aws:s3:::DOC-EXAMPLE-DESTINATION-BUCKET/*"
            ],
            "Condition": {
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:s3:::DOC-EXAMPLE-SOURCE-BUCKET"
                },
                "StringEquals": {
                    "aws:SourceAccount": "111122223333",
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        }
    ]
}

S3 インベントリレポート設定の作成を制御する

Amazon S3 インベントリ は、S3 バケット内のオブジェクトのリストと、各オブジェクトのメタデータを作成します。s3:PutInventoryConfiguration アクセス許可により、ユーザーはデフォルトで使用可能なすべてのオブジェクトメタデータフィールドを含むインベント設定を作成し、インベントリを保存する宛先バケットを指定できます。宛先バケット内のオブジェクトへの読み取りアクセスを持つユーザーは、インベントリレポートで使用可能なすべてのオブジェクトメタデータフィールドにアクセスできます。S3 Inventory で使用できるメタデータフィールドの詳細については、「Amazon S3 インベントリのリスト」を参照してください。

S3 インベントリレポートをユーザーが設定できないようにするには、ユーザーから s3:PutInventoryConfiguration アクセス許可を削除します。

S3 インベントリレポート設定の一部のオブジェクトメタデータフィールドはオプションです。つまり、デフォルトで使用できますが、ユーザーにs3:PutInventoryConfiguration アクセス許可を付与すると制限できます。s3:InventoryAccessibleOptionalFields 条件キーを使用して、ユーザーがこれらのオプションのメタデータフィールドをレポートに含めることができるかどうかを制御できます。S3 インベントリで使用できるオプションのメタデータフィールドのリストについては、「Amazon Simple Storage Service API リファレンス」の「OptionalFields」を参照してください。

特定のオプションのメタデータフィールドを使用してインベントリ設定を作成するアクセス許可をユーザーに付与するには、s3:InventoryAccessibleOptionalFields 条件キーを使用してバケットポリシーの条件を絞り込みます。

次のポリシー例では、インベントリ設定を条件付きで作成するアクセス許可をユーザー (Ana) に付与します。ポリシーの ForAllValues:StringEquals条件は、 s3:InventoryAccessibleOptionalFields条件キーを使用して、許可される 2 つのオプションのメタデータフィールド、つまり Size と StorageClass を指定します。したがって、Ana がインベントリ設定を作成するとき、含めることができるオプションのメタデータフィールドは Size と StorageClass のみです。

{
	"Id": "InventoryConfigPolicy",
	"Version": "2012-10-17",
	"Statement": [{
			"Sid": "AllowInventoryCreationConditionally",
			"Effect": "Allow",			
			"Principal": {
				"AWS": "arn:aws:iam::111122223333:user/Ana"
			},			
			"Action": 
				"s3:PutInventoryConfiguration",
			"Resource": 
				"arn:aws:s3:::DOC-EXAMPLE-SOURCE-BUCKET",
			"Condition": {
				"ForAllValues:StringEquals": {
					"s3:InventoryAccessibleOptionalFields": [
					   "Size",
					   "StorageClass"
					   ]
				  }
				}
			}
	]
}

特定のオプションのメタデータフィールドを含む S3 インベントリレポートをユーザーが設定できないようにするには、レプリケート元バケットのバケットポリシーに明示的な Deny ステートメントを追加します。次のバケットポリシーの例では、オプションの ObjectAccessControlList または ObjectOwner メタデータフィールドを含むインベントリ設定をソースバケット DOC-EXAMPLE-SOURCE-BUCKET に作成することをユーザー Ana に拒否します。ユーザーAna は、他のオプションのメタデータフィールドを使用してインベントリ設定を作成できます。

{
	"Id": "InventoryConfigSomeFields",
	"Version": "2012-10-17",
	"Statement": [{
			"Sid": "AllowInventoryCreation",
			"Effect": "Allow",
			"Principal": {
				"AWS": "arn:aws:iam::111122223333:user/Ana"
			},
			"Action": "s3:PutInventoryConfiguration",			
			"Resource": 
				"arn:aws:s3:::DOC-EXAMPLE-SOURCE-BUCKET",

		},
		{
			"Sid": "DenyCertainInventoryFieldCreation",
			"Effect": "Deny",
			"Principal": {
				"AWS": "arn:aws:iam::111122223333:user/Ana"
			},
			"Action": "s3:PutInventoryConfiguration",	
			"Resource": 
			  "arn:aws:s3:::DOC-EXAMPLE-SOURCE-BUCKET",			
			"Condition": {
				"ForAnyValue:StringEquals": {
					"s3:InventoryAccessibleOptionalFields": [
					   "ObjectOwner",
					   "ObjectAccessControlList"
					   ]
				  }
				}
			}
	]
}
注記

バケットポリシーで s3:InventoryAccessibleOptionalFields 条件キーを使用しても、既存のインベントリ設定に基づくインベントリレポートのデリバリーには影響しません。

重要

前の例に示すように、 Allow 効果でForAllValues または Deny 効果で ForAnyValue を使用することをお勧めします。

これらの組み合わせは過度に制限され、インベントリ設定の削除がブロックされる可能性があるため、Deny 効果で ForAllValues または Allow 効果で ForAnyValue を使用しないでください。

ForAllValues および ForAnyValue 条件セット演算子の詳細については、「IAM ユーザーガイド」「複数値のコンテキストキー」を参照してください。

MFA が必要

Amazon S3 は、多エレメント認証 (MFA) で保護された API へのアクセスをサポートしています。この機能により、Amazon S3 のリソースへのアクセスに MFA を強制的に適用することができます。多エレメント認証により、AWS 環境に適用できるセキュリティのレベルが高まります。MFA は、有効な MFA コードを入力して MFA デバイスを物理的に所有していることを証明することがユーザーに要求されるセキュリティ機能です。詳細については、AWS 多エレメント認証 を参照してください。Amazon S3 のリソースにアクセスするすべてのリクエストに対して MFA を要求することができます。

MFA の要件を適用するには、バケットポリシーで aws:MultiFactorAuthAge 条件キーを使用します。IAM ユーザーは、AWS Security Token Service (AWS STS) により発行される一時的な認証情報を使用して、Amazon S3 のリソースにアクセスできます。AWS STS リクエスト時に、MFA コードを指定します。

Amazon S3 が多要素認証のリクエストを受け取ると、aws:MultiFactorAuthAge 条件キーに一時的な認証情報が作成されてからの時間の数値 (秒) が示されます。リクエストで提供された一時的な認証情報が MFA デバイスを使用して作成されていない場合、このキー値は null (不在) になります。次の例に示すように、バケットポリシーに、この値を確認する条件を追加できます。

このポリシー例は、リクエストが MFA を使用して認証されていない場合、DOC-EXAMPLE-BUCKET バケットの /taxdocuments フォルダに対するすべての Amazon S3 オペレーションを拒否します。MFA の詳細については、IAM ユーザーガイドAWSの での多エレメント認証 (MFA) の使用 を参照してください。

{
    "Version": "2012-10-17",
    "Id": "123",
    "Statement": [
      {
        "Sid": "",
        "Effect": "Deny",
        "Principal": "*",
        "Action": "s3:*",
        "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/taxdocuments/*",
        "Condition": { "Null": { "aws:MultiFactorAuthAge": true }}
      }
    ]
 }

aws:MultiFactorAuthAge 条件キー値が null で、リクエスト内の一時的なセキュリティ認証情報が MFA デバイスを使用せずに作成されたことを示している場合、Condition ブロック内の Null 条件の評価は true になります。

次のバケットポリシーは、前述のバケットポリシーの拡張です。2 つのポリシーステートメントが含まれています。1 つのステートメントは、バケット (DOC-EXAMPLE-BUCKET) の s3:GetObject アクセス許可を全員に付与します。もう 1 つのステートメントは、MFA を要求することにより、バケットの DOC-EXAMPLE-BUCKET/taxdocuments フォルダへのアクセスを制限します。

{
    "Version": "2012-10-17",
    "Id": "123",
    "Statement": [
      {
        "Sid": "",
        "Effect": "Deny",
        "Principal": "*",
        "Action": "s3:*",
        "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/taxdocuments/*",
        "Condition": { "Null": { "aws:MultiFactorAuthAge": true } }
      },
      {
        "Sid": "",
        "Effect": "Allow",
        "Principal": "*",
        "Action": ["s3:GetObject"],
        "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
      }
    ]
 }

オプションで、aws:MultiFactorAuthAge キーの有効期間を制限する数値条件を使用することができます。aws:MultiFactorAuthAge キーで指定する期間は、リクエストの認証に使われる一時的セキュリティ認証情報の寿命とは無関係です。

例えば、次のバケットポリシーでは、MFA 認証を要求するほかに、一時セッションが作成されてからの時間もチェックします。このポリシーは、aws:MultiFactorAuthAge キーの値が、一時セッションが 1 時間 (3,600 秒) 以上前に作成されたことを示す場合に、すべてのオペレーションを拒否します。

{
    "Version": "2012-10-17",
    "Id": "123",
    "Statement": [
      {
        "Sid": "",
        "Effect": "Deny",
        "Principal": "*",
        "Action": "s3:*",
        "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/taxdocuments/*",
        "Condition": {"Null": {"aws:MultiFactorAuthAge": true }}
      },
      {
        "Sid": "",
        "Effect": "Deny",
        "Principal": "*",
        "Action": "s3:*",
        "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/taxdocuments/*",
        "Condition": {"NumericGreaterThan": {"aws:MultiFactorAuthAge": 3600 }}
       },
       {
         "Sid": "",
         "Effect": "Allow",
         "Principal": "*",
         "Action": ["s3:GetObject"],
         "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
       }
    ]
 }