はじめに
今回は、S3 の VPC エンドポイントのポリシーを活用して、
S3 バケットへのアクセスを制御する方法について記事にしたいと思います。
構成
今回は
アカウント111122223333から「A」のS3バケットへのアクセスは許可し
「B」のS3バケットへのアクセスは拒否とする設定をしたいと思います。
前提条件
・EC2、S3、エンドポイントなどはすでに作成済みであること
・AWSの操作(ポリシーの作成)権限があること
・EC2にログインしてAWS CLIコマンドが使用できること
事前の動作確認
EC2にログインして、AWS CLIを使ってオブジェクトの一覧を確認します。
aws s3 ls s3://A
PRE file1.txt
PRE file2.txt
aws s3 ls s3://B
PRE file1.txt
PRE file2.txt
AもBもバケットの内容を表示することができます。
設定
S3のVPCエンドポイントのポリシーを変更します。
デフォルトでは、すべてのプリンシパル（誰でも）に対して、すべてのアクションを、すべてのリソースに許可するポリシーになっています。
{
"Version": "2008-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*"
}
]
}
このポリシーに「B」のバケットに対してアクセスできない設定をします。
以下のように変更します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow-callers-from-specific-account",
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": [
"arn:aws:s3:::B",
"arn:aws:s3:::B/*",
],
"Condition": {
"StringEquals": {
"aws:PrincipalAccount": "111122223333"
}
}
}
]
}
設定は以上です。
※「B」のS3バケット自体と「B」のS3バケットの中身に対してアクセス制御をしているため
"Resource"では２行書いています。
内容について簡単に説明します。
"Condition": {
"StringEquals": {
"aws:PrincipalAccount": "111122223333"
}
}
ここでは、Principal が 111122223333 アカウントに属している場合だけ許可します。
他の AWS アカウントの IAM ユーザーやロールは、このバケットにアクセスできません。
まとめると、このポリシーの内容は
「バケット B とその中のすべてのオブジェクトに対して、
AWS アカウント 111122223333 からのリクエストだけを許可する。
他のアカウントからのアクセスは拒否。」
となります。
なお、許可のアカウントを増やす場合はこのように指定することができます。
"Condition": {
"StringEquals": {
"aws:PrincipalAccount": [
"111122223333",
"444455556666",
"777788889999"
]
}
}
事後の動作確認
事前と同様に、EC2にログインしてAWSCLIを使ってオブジェクトの一覧を動作確認をします。
aws s3 ls s3://A
PRE file1.txt
PRE file2.txt
aws s3 ls s3://B
An error occurred (AccessDenied) when calling the ～
Aは変わらずバケットの内容を確認できますが、
Bはバケットの内容が確認できなく(アクセス拒否に)なりました。
まとめ
今回は、VPC エンドポイントのポリシーを使って S3 へのアクセスを安全に制限する方法を紹介しました。
VPCエンドポイントを使えば、インターネットを経由せずに S3 にアクセスできるようになり、さらにポリシーでアクセスを制御することが可能です。
これにより、さらにAWS 環境におけるS3のデータ保護とセキュリティの強化が実現できるかと思います。
本記事が参考になれば幸いです。
■参考サイト■