概要
AWSはIAMロール，ポリシーといった権限管理のサービスが提供されており，これによってユーザ，AWSリソースの動作，アクセスの制御を行うことができます．
このあたりの話はAWSを勉強し始めると最初に必ず学ぶので私もある程度理解しているつもり？ですが，今回はIAM以外の権限管理方法についてご紹介したいです！
それがタイトルにもあるとおり，S3 Bucket Policyです．
S3外部に公開してはいけないデータが置いてある場合も多く，セキュリティの担保が非常に重要になってきます．
セキュリティは非常に重要ですが，なかなか取っ付きにくい話題で私もあまり勉強したことがありません，，，
ここではアーキテクト図を用いて，あるシステムの中でS3 Bucket Policyとは？どのように使われているのか？説明してきます．
これを機に少しでもセキュリティに興味を持っていただければ幸いです．
前提知識
- S3：AWSが提供するのストレージ（データの保管庫）
- Endpoint：VPCと他のサービス間の通信を可能にするコンポーネント。サービスの玄関口。
今回説明するアーキテクト図
Endpointのアクセスを許可したIAMユーザを利用してS3のバケットにアクセスできるように設計します。
このとき、Endpoint以外からのアクセスを禁止する設定をS3のバケットポリシーに記載します。
実現したいこと
S3に対するアクセスをVPC Endpoint経由に絞りたい．
なぜvpcEndpoint経由にするかはgptや文献に根拠を見つけながら説明する
必要な権限
1. VPC Endpoint
- サービス：com.amazonaws.[リージョン名].s3
- エンドポイントタイプ：interface
- ポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowListBucketProd",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::[バケット名]"
},
{
"Sid": "AllowGetObjectProd",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::[バケット名]/*"
}
]
}
VPC Endpointのポリシーで誰が（Principal）、何を（Action）、何に対して（Resource）許可するか定義しています。ここではあるバケットに対して"s3:ListBucket"（S3の中身を表示）、"s3:GetObject"（S3にあるファイルをとってこれる）を許可（"Effect": "Allow"）しています。
2. Bucket Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessFromSpecificVPCEndpoint",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[アカウントID]:root"
},
"Action": [
"s3:ListBucket",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::[バケット名]",
"arn:aws:s3:::[バケット名]/*"
],
"Condition": {
"StringEquals": {
"aws:SourceVpce": "[VPC Endpoint ID]",
"aws:PrincipalType": [
"User",
"AssumedRole"
]
}
}
},
{
"Sid": "DenyUnsecureTransport",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::[バケット名]",
"arn:aws:s3:::[バケット名]/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "DenyAccessNotFromVPCEndpoint",
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:ListBucket",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::[バケット名]",
"arn:aws:s3:::[バケット名]/*"
],
"Condition": {
"StringEquals": {
"aws:PrincipalType": [
"User",
"AssumedRole"
]
},
"StringNotEquals": {
"aws:SourceVpce": "[VPC Endpoint ID]"
}
}
}
}
]
}
ここでは各Sidごとにポリシーの説明します。
- AllowAccessFromSpecificVPCEndpoint
注目するところは- PrincipalをIAMユーザに絞っているところ
- ↓で"aws:SourceVpce": "[VPC Endpoint ID]"で特定のVPCからのアクセスを許可しています。
"Condition": {
"StringEquals": {
"aws:SourceVpce": "[VPC Endpoint ID]",
"aws:PrincipalType": [
"User",
"AssumedRole"
]
}
}
- DenyUnsecureTransport
HTTPS以外の通信（"aws:SecureTransport": "false"）を拒否（"Effect": "Deny"）しています。
- DenyAccessNotFromVPCEndpoint
一番初めに書いた「AllowAccessFromSpecificVPCEndpoint」と異なるのは
"Effect": "Deny"と↓の"StringNotEquals"の部分です
"StringNotEquals": {
"aws:SourceVpce": "[VPC Endpoint ID]"
}
ここが意味するのは、特定のVPC Endpint以外からの経路（StringNotEquals）は拒否（Deny）するということです。
まとめ
- Redshiftのスケジュール機能は便利だが、IAMロール + DB権限 両方の設定が必要
- 実行時の「ロールの指定」を忘れると動かない
- 権限を最小限に絞ることでセキュリティを担保できる
ロールとポリシーについては何となく理解していましたが、AWS独自の権限について学べるいい機会でした！