View a markdown version of this page

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

Amazon S3 バケットポリシーの例

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

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

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

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

S3 リソースタイプ別の S3 API オペレーションへのアクセス許可の詳細については、「Amazon S3 API オペレーションに必要なアクセス許可」を参照してください。

注記

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

バケットポリシーを作成するためのその他のリソースには、以下が含まれます。

ポリシーの追加または更新に問題がある場合は、AWS re:Post 情報センターの「Amazon S3 バケットポリシーを更新しようとする際、『Invalid principal in policy』というエラーが発生する理由を知りたいです」を参照してください。

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

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

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

警告

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

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

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

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

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

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

    バケットのブロックパブリックアクセス設定を示す Amazon S3 コンソール。

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

暗号化が必要

次の例に示すように、AWS Key Management Service (AWS KMS) キーによるサーバー側の暗号化 (SSE-KMS) を要求できます。

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

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

JSON
{
"Version":"2012-10-17",
"Id": "PutObjPolicy",
"Statement": [{
  "Sid": "DenyObjectsThatAreNotSSEKMS",
  "Principal": "*",
  "Effect": "Deny",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::amzn-s3-demo-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 に置き換えてください。

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

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

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

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

警告

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

JSON
{
    "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:::amzn-s3-demo-bucket/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": [
                        "public-read"
                    ]
                }
            }
        }
    ]
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

JSON
{
    "Version":"2012-10-17",
    "Statement": [{
        "Principal":{
            "AWS":[
                 "arn:aws:iam::111122223333:user/JohnDoe"
         ]
        },
        "Effect": "Allow",
        "Action": [
            "s3:PutObject"
        ],
        "Resource": [
            "arn:aws:s3:::amzn-s3-demo-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 許可を付与します。

JSON
{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPutObjectS3ServerAccessLogsPolicy",
            "Principal": {
                "Service": "logging.s3.amazonaws.com"
            },
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-logs/*",
            "Condition": {
                "StringEquals": {
                "aws:SourceAccount": "111122223333"
                },
                "ArnLike": {
                "aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-source-bucket1"
                }
            }
        },
        {
            "Sid": "RestrictToS3ServerAccessLogs",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-logs/*",
            "Condition": {
                "ForAllValues:StringNotEquals": {
                    "aws:PrincipalServiceNamesList": "logging.s3.amazonaws.com"
                }
            }
        }
    ]
}

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

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

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

重要

条件付きのこの Allow ステートメントは、他のメカニズムを通じて付与されたアクセスを拒否しません。バケットで ACL が有効になっている場合、またはアクセスを許可する他のポリシーがある場合、組織外のプリンシパルが引き続きオブジェクトにアクセスできる可能性があります。アクセスを組織のみに完全に制限するには、拒否ステートメントでこの条件を使用し (以下の例を参照)、オブジェクト所有権を「バケット所有者の強制」に設定して ACL を無効にし、S3 パブリックアクセスブロックを有効にすることをお勧めします。

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

組織外のプリンシパルのアクセスを拒否する

保護を強化するには、aws:PrincipalOrgID 条件を指定した Deny ステートメントを使用します。Deny ステートメントは、アクセスの付与方法に関係なく、すべての Allow を上書きします。次の例では、組織内にないプリンシパルによるすべての S3 アクションを拒否します。このアプローチは、ACL やその他のポリシーが誤ってアクセスを許可した場合でも多層防御を実現します。

{
    "Version": "2012-10-17", 
    "Statement": [
        {
            "Sid": "DenyAccessFromOutsideOrg",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket",
                "arn:aws:s3:::amzn-s3-demo-bucket/*"
            ],
            "Condition": {
                "StringNotEquals": {
                    "aws:PrincipalOrgID": "o-aa111bb222"
                }
            }
        }
    ]
}

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

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

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

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

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

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

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

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

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

使用するブラウザのリクエストに 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) が amzn-s3-demo-bucket バケットのルートレベルと home フォルダ内のオブジェクトを一覧表示できるようにします。このステートメントにより、ユーザーはコンソールを使用してプレフィックス home/ を検索することもできます。

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

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

JSON
{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "AllowRootAndHomeListingOfCompanyBucket",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111122223333:user/JohnDoe"
                ]
            },
            "Effect": "Allow",
            "Action": ["s3:ListBucket"],
            "Resource": ["arn:aws:s3:::amzn-s3-demo-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:::amzn-s3-demo-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:::amzn-s3-demo-bucket/home/JohnDoe/*"]
        }
    ]
}

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

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

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

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

JSON
{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:root"
            },
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/prefix/AWSLogs/111122223333/*"
        }
    ]
}
注記

必ず、elb-account-id を、ご利用の AWS リージョン における Elastic Load Balancing の AWS アカウント ID に置き換えてください。Elastic Load Balancing リージョンのリストについては、「Elastic Load Balancing ユーザーガイド」の「Attach a policy to your Amazon S3 bucket」を参照してください。

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

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

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

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

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

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

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

この例を使用するには:

JSON
{
    "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:::amzn-s3-demo-bucket/*"
        }
    ]
}

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

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

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

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

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

JSON
{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "S3StorageLensExamplePolicy",
            "Effect": "Allow",
            "Principal": {
                "Service": "storage-lens.s3.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-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:::amzn-s3-demo-destination-bucket/destination-prefix/StorageLens/your-organization-id/*",

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

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

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

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

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

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

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 の代わりに s3express:InventoryAccessibleOptionalFields 条件キーを使用します。ディレクトリバケットの S3 インベントリの設定の詳細については、「Amazon S3 インベントリの設定」を参照してください。

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

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

JSON
{
	"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 メタデータフィールドを含むインベントリ設定をソースバケット amzn-s3-demo-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:::amzn-s3-demo-source-bucket",

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

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

重要

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

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

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

ディレクトリバケットの S3 インベントリレポート設定の作成を制御する

ディレクトリバケットの場合、バケットポリシーの代わりに IAM アイデンティティベースのポリシーで s3express:InventoryAccessibleOptionalFields 条件キーを使用します。次の IAM ポリシー例では、ディレクトリバケットのインベントリ設定を作成するアクセス許可をユーザーに付与します。ForAllValues:StringEquals 条件は、s3express:InventoryAccessibleOptionalFields 条件キーを使用して、許可されるオプションのメタデータフィールドを指定します。

{
	"Version": "2012-10-17",
	"Statement": [{
		"Sid": "AllowInventoryCreationForDirectoryBucket",
		"Effect": "Allow",
		"Action": "s3express:PutInventoryConfiguration",
		"Resource": "arn:aws:s3express:region:account-id:bucket/bucket-base-name--zone-id--x-s3",
		"Condition": {
			"ForAllValues:StringEquals": {
				"s3express:InventoryAccessibleOptionalFields": [
					"Size",
					"StorageClass"
				]
			}
		}
	}]
}

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 を使用して認証されていない場合、amzn-s3-demo-bucket バケットの /taxdocuments フォルダに対するすべての Amazon S3 オペレーションを拒否します。MFA の詳細については、IAM ユーザーガイドAWSの での多エレメント認証 (MFA) の使用 を参照してください。

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

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

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

JSON
{
    "Version":"2012-10-17",
    "Id": "123",
    "Statement": [
      {
        "Sid": "DenyInsecureConnections",
        "Effect": "Deny",
        "Principal": {
            "AWS": "arn:aws:iam::111122223333:root"
        },
        "Action": "s3:*",
        "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/taxdocuments/*",
        "Condition": { "Null": { "aws:MultiFactorAuthAge": true } }
      },
      {
        "Sid": "AllowGetObject",
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::111122223333:root"
        },
        "Action": ["s3:GetObject"],
        "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
      }
    ]
 }

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

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

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

デフォルトでは、ユーザーには一切のアクセス許可がありません。ただし、ポリシーを作成する際に、意図しないアクセス許可をユーザーに付与する可能性があります。このようなアクセス許可の抜け穴を防ぐには、明示的な拒否を追加して、より厳格なアクセスポリシーを記述する必要があります。

ユーザーまたはアカウントによるオブジェクトの削除を明示的に防ぐには、バケットポリシーに s3:DeleteObject、s3:DeleteObjectVersion、および s3:PutLifecycleConfiguration のアクションのアクセス許可を追加する必要があります。オブジェクトの削除は、明示的に DELETE Object API オペレーションを呼び出すか、有効期限が過ぎたオブジェクトを Amazon S3 が削除できるようにオブジェクトのライフサイクルを設定 (「オブジェクトのライフサイクルの管理」を参照) することで可能であるため、これらすべてのアクションが必要です。

次の例は、ユーザー MaryMajor の DELETE Object アクセス許可を明示的に拒否します。明示的な Deny ステートメントは、付与されている他のどのアクセス許可よりも常に優先されます。

JSON
{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Sid": "statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/MaryMajor"
      },
      "Action": [
        "s3:GetObjectVersion",
        "s3:GetBucketAcl"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket1",
	 	"arn:aws:s3:::amzn-s3-demo-bucket1/*"
      ]
    },
    {
      "Sid": "statement2",
      "Effect": "Deny",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/MaryMajor"
      },
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:PutLifecycleConfiguration"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket1",
	    "arn:aws:s3:::amzn-s3-demo-bucket1/*"
      ]
    }
  ]
}