S3バケットポリシーでAthenaのFrom通信を出来る限り制限したい

  • 2024年6月17日
  • 2024年6月23日
  • AWS, IT
AWS

こんにちはますのです。
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制御が簡単という結論になります。

バケットポリシー: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つのドキュメントを確認しました。。

「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」による制御は出来ないと判断します。

実現出来なかった手法: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でつぶやいて頂ければ拾いますゆえに。

参考サイト

最新情報をチェックしよう!