#1. 概要
AWSのS3クラウドストレージへのアクセスは３つの方法でコントロール。
ACL
BucketPolicy
IAM Role
これらの制御の評価は順番があり、コントロールをよく理解ない内に意図せぬバケットの公開のリスクがある。特に開発やテスト段階では、制御ポリシーを良く計画しないうちに、バケットのPublic Accessを解除された場合は少なくないである（下記図をご参照）。
本文はPublic AccessをBlockする前提で、BucketPolicyの設定によるS3バケットへのアクセスを紹介する。
#2. 対処法
“Amazon S3 ストレージへのパブリックアクセスのブロック”のオフィシャルサイトでは、バケットポリシーに関してパブリックの意味について以下のように説明してある。
バケットポリシーを評価する場合、Amazon S3 はまずポリシーがパブリックであると想定します。その後、ポリシーを評価して非パブリックとしての資格があるかどうかを判断します。非パブリックと見なすには、バケットポリシーで、次のうち 1 つ以上の固定値 (ワイルドカードを含まない値) にのみアクセスを許可する必要があります。
aws:SourceIp を使用した一連のクラスレスドメイン間ルーティング (CIDR)。CIDR の詳細については、RFC Editor のウェブサイトで RFC 4632 を参照してください。
AWS プリンシパル、ユーザー、ロール、またはサービスプリンシパル (例: aws:PrincipalOrgID)
aws:SourceArn
aws:SourceVpc
aws:SourceVpce
aws:SourceOwner
aws:SourceAccount
s3:x-amz-server-side-encryption-aws-kms-key-id
aws:userid、「」パターンの外側AROLEID:
s3:DataAccessPointArn
s3:DataAccessPointAccount
要するに、以上項目の内一つ以上を固定値に設定しておけば、当該アクセスは非パブリックと認める。ただし、ポリシーの記述には”Condition”とする必要である。
本文は"aws:SourceVpce": "vpce-01fxxx41xxx74dxxx"、決めているVPCのエンドポイントからのアクセスを条件としてバケットポリシーの設定と動作確認をする。
#3. 動作確認
上記図の４つのPublic Accessポリシーを全部ONにした上、BucketPolicyを下記のように設定する。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AddVpceCondition",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:*"
],
"Resource": [
"arn:aws:s3:::xxxx-dev-xxxx-batch-s3",
"arn:aws:s3:::xxxx-dev-xxxx-batch-s3/*"
],
"Condition": {
"StringEquals": {
"aws:SourceVpce": "vpce-xxxxxxxxxxxx"
}
}
}
]
}
因みに、上記設定したResourceの”arn:aws:s3:::xxxx-xxx-xxxx-batch-s3”はバケット自体とそのSubresource(lifecycle, website, versioning, policy and acl, cors, object ownership, logging)、”arn:aws:s3:::xxxx-xxx-xxxx-batch-s3/*”はバケットObjectのResourceである。Object Resourceはacl、restoreを意味する（作者はbucketに作成されたフォルダもObjectのResourceと思う。）
以上のBucketPolicy設定でS3パケットにアクセスできたことを下記図ご参照。
#4. まとめ
本文S3 BucketPolicyのConditionに固定値を設定するにより、アクセスを非Public Accessと扱われて、パケットのPublicAccessをBlock ONにしてもアクセスできたことを実装できた。ご実務に参照になれば幸いである。