こんにちはますのです。
S3バケットポリシーでガチガチにアクセス制御してますか?
今回はアクセス元を特定VPCに限定しているS3バケットポリシーに対して、Athenaで分析を行うことになりました。
Athenaの通信制御を行う方法について調べた内容をメモします。
目次
概要
- 分析環境とデータ保存環境は別アカウントに存在している
- S3バケットはバケットポリシーで特定のVPCからのアクセスのみ許可としている
- 特定VPCからS3への通信はGateway型エンドポイントを経由する
- AthenaはS3サーバアクセスログの分析で利用する
- S3サーバアクセスログのバケットポリシーも特定のVPCからのGetObjectのみ許可している
- Athenaでの分析はAWS CLIで行う
- インターネット通信はNATGateway経由で可能な環境となっている
概要図
Athenaの通信もVPCエンドポイントで制御すれば良いと簡単に考えていました。
調べて分かったことは、S3バケットポリシー上でAthenaはVPCエンドポイントの制限が不可ということ。
色々と模索に走りましたが、今回はGlobal IP制御が簡単という結論になります。
調べて分かったことは、S3バケットポリシー上でAthenaはVPCエンドポイントの制限が不可ということ。
色々と模索に走りましたが、今回はGlobal IP制御が簡単という結論になります。
バケットポリシー:Athenaの通信制御方法
調べた限り、下記2案がAthena通信を制御出来る方法になると考えました。
運用利便性が必要だったため細かい制御の部分は諦め、案1のグローバルIP制御の案を採用しました。
案1:グローバルIPによる通信制御(採用)
まずは鉄板とも言えるIP制御方法を試してみたところ、クエリ通信も成功することを確認。
VPC内のインスタンスレベルでのアクセスはバケットポリシー上では出来ませんが、最低限VPCからのアクセスに絞れたと考えることが出来ます。
{
"Version": "2012-10-17",
"Id": "AthenaAccessControl",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:GetObject*",
"Resource": [
"arn:aws:s3:::MyS3ServerAccessLogsBucket",
"arn:aws:s3:::MyS3ServerAccessLogsBucket/*"
],
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"53.yy.yy.yy/32"
]
}
}
}
]
}
案2:「aws :CalledVia条件キー」でAthena通信を制御(不採用)
下記2つのドキュメントを確認しました。。
- How to define least-privileged permissions for actions called by AWS services
- Athena での CalledVia コンテキストキーの使用
「aws :CalledVia」でAthenaの通信のAllow / Denyを制御出来そうです。ということで先ほどのバケットポリシーに付与して試してみます。
{
"Version": "2012-10-17",
"Id": "AthenaAccessControl",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:GetObject*",
"Resource": [
"arn:aws:s3:::MyS3ServerAccessLogsBucket",
"arn:aws:s3:::MyS3ServerAccessLogsBucket/*"
],
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"53.yy.yy.yy/32"
]
},
"ForAnyValue:StringNotEquals": {
"aws:CalledVia": "athena.amazonaws.com"
}
}
}
]
}
結果は、IP制限等全無視して許可されてしまいました。
ブログにも記載されている通り、IAMユーザ側の制御が必要になります。
IAMユーザで制御する場合はuseridを利用します。
FromのEC2インスタンスかつIAM UserIDといった細かい制御も可能です。
しかし、IAMユーザ毎に登録をしていく必要があるため、頻繁にユーザが変わるケースでは運用負荷が膨らみます。今回は運用利便性が下がることはしたくないため、「aws:CalledVia」による制御は出来ないと判断します。
FromのEC2インスタンスかつIAM UserIDといった細かい制御も可能です。
しかし、IAMユーザ毎に登録をしていく必要があるため、頻繁にユーザが変わるケースでは運用負荷が膨らみます。今回は運用利便性が下がることはしたくないため、「aws:CalledVia」による制御は出来ないと判断します。
実現出来なかった手法:VPC ID、VPCE IDの指定
バケットポリシーでVPC ID、ならびにVPCエンドポイントIDを許可設定すれば出来るのでは?と思い検証しました。
結果は不可でした。AthenaではVPC IDやVPCエンドポイントIDでの制御は利用出来ないようです。
概要図(VPC制御パターン)
設定したS3バケットポリシー
{
"Version": "2012-10-17",
"Id": "AthenaAccessControl",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:GetObject*",
"Resource": [
"arn:aws:s3:::MyS3ServerAccessLogsBucket",
"arn:aws:s3:::MyS3ServerAccessLogsBucket/*"
],
"Condition": {
"StringNotEquals": {
"aws:sourceVpc": [
"vpc-xxxxxxxx"
],
"aws:sourceVpce": [
"vpce-athenaendpoint"
]
}
}
}
]
}
VPCエンドポイントIDが利用出来れば、セキュリティグループでの細かい制御も実装出来ただけに無念です。
大人しくグローバルIPによる制限を受け入れます。何か妙案がある方いらっしゃればSNSでつぶやいて頂ければ拾いますゆえに。
大人しくグローバルIPによる制限を受け入れます。何か妙案がある方いらっしゃればSNSでつぶやいて頂ければ拾いますゆえに。