S3バケットポリシーを使用した VPC エンドポイントからのアクセス制御

# S3バケットポリシーを使用した VPC エンドポイントからのアクセス制御

S3は便利で安くて皆さんよく利用されているストレージサービスだと思います。

S3セキュリティ設計の一環として、バケットポリシーの設計は結構重要です。

今回はVPCエンドポイントからのみ許可するポリシーについて設計時の注意時点についてご紹介します。



### やりたいこと

今回設計したS3はアプリケーション保管用であり、パブリック公開はしません。

情報漏洩を防ぐために、より安全なセキュリティポリシーを適用すると考えており、以下のAWS公式ドキュメントを参照して検証してみました。

[バケットポリシーを使用した VPC エンドポイントからのアクセス制御](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/example-bucket-policies-vpc-endpoint.html)

### 検証

上記のページを参照し、AWSコンソールから1個S3を作成して下記のバケットポリシーを適用しました。

```
{
   "Version": "2012-10-17",
   "Id": "Policy1415115909152",
   "Statement": [
     {
       "Sid": "Access-to-specific-VPCE-only",
       "Principal": "*",
       "Action": "s3:*",
       "Effect": "Deny",
       "Resource": ["arn:aws:s3:::cpi-s3-test",
                    "arn:aws:s3:::cpi-s3-test/*"],
       "Condition": {
         "StringNotEquals": {
           "aws:SourceVpce": "vpce-xxxxxxxxxxxxxxxxx"
         }
       }
     }
   ]
}
```

とすると、コンソールからもう一回確認する場合、あれ、全部アクセス拒否されました。

![S3_deny_001.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1109288/5f021eae-2c1a-4bd4-42c4-fdddf0215254.png)
![S3_deny_002.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1109288/75899c1b-bc89-b411-ccf1-4ee08e8d71e2.png)

コンソールから全くアクセスできない状態になりました。

S3バケットポリシーを振り返ってみると、そうか、今VPCエンドポイントからしかアクセスできないから、コンソールからの操作は全部拒否されました。

コンソールから修正できないので、実際にVPCに建てたEC2に入って、CLIにより適用したポリシーを削除しました。

下記のコマンドを実行し、コンソールからまたS3が確認できるようになりました。

![S3_policy_delete.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1109288/3d3341ab-f1c9-92c6-551c-973113409dac.png)


但し、運用など、コンソールからも操作したいので、解決案を考えていました。

### 解決案１：特定なプリンシパルのみ制限

以下、IAMロールで検証したが、実際にIAMユーザも同様となります。

```
{
   "Version": "2012-10-17",
   "Id": "Policy1415115909152",
   "Statement": [
     {
       "Sid": "Access-to-specific-VPCE-only",
       "Principal": {
                "AWS": "arn:aws:iam::xxxxxxxxxx:role/IAM-S3-FULL"
            },
       "Action": "s3:*",
       "Effect": "Deny",
       "Resource": ["arn:aws:s3:::cpi-s3-test",
                    "arn:aws:s3:::cpi-s3-test/*"],
       "Condition": {
         "StringNotEquals": {
           "aws:SourceVpce": "vpce-xxxxxxxxxxxxxxxxx"
         }
       }
     }
   ]
}
```

### 解決案２：制限条件にコンソールにアクセス許可するIPを追加

VPCエンドポイントのみではなく、コンソールかもアクセスできることを考慮し、コンソールにアクセス可能アクセスIP範囲を条件に追加する。

具体的のポリシーは以下となります。

ポイントは「NotIpAddress」に想定されているアクセスIP範囲を設定する

```
{
   "Version": "2012-10-17",
   "Id": "Policy1415115909152",
   "Statement": [
     {
       "Sid": "Access-to-specific-VPCE-only",
       "Principal": "*",
       "Action": "s3:*",
       "Effect": "Deny",
       "Resource": ["arn:aws:s3:::cpi-s3-test",
                    "arn:aws:s3:::cpi-s3-test/*"],
       "Condition": {
         "StringNotEquals": {
           "aws:SourceVpce": "vpce-xxxxxxxxxxxxxxxxx"
         },
         "NotIpAddress": {"aws:SourceIp": "220.100.XXX.XXX/32"}
       }
     }
   ]
}
```

上記の「NotIpAddress」ローカルPCのIPを設定して検証してみたら、アクセスできることを確認できました。

![S3_allow_001.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1109288/218cbaf5-03b4-8b57-7119-38e4cb71b417.png)

### 纏め

上記のように、バケットポリシーを使用した VPC エンドポイントからのアクセス制御ポリシーを検証してみました。

やはり、実際にやらないといろいろ分からないので、AWS勉強するときに、ドキュメントに書いたものを実際に検証してみるのはおすすめです。

また、上記解決案２を設定するときに、いろいろ調査し、以下の記事を参考させていただきました。

[複数の否定条件を使ったS3バケットポリシーを正しく理解してますか？](https://dev.classmethod.jp/articles/s3-bucket-policy-multi-condition/)

皆さんもぜひ自分で試してください。