VPCエンドポイント経由の通信でaws:SourceIPキーを使ったIAMポリシー制限

記事タイトルとURLをコピーする

こんにちは、技術2課、大阪勤務の全(ちょん)です。

この季節、インフルエンザに加え、今回はコロナウィルスも広がりつつあるので、不安ではありますが、私は花粉症による鼻ムズムズが押し寄せてきています。

今回はVPCエンドポイントが配置された環境でのIAMポリシー制限ではまった内容についてブログに残しました。

要件

実現したい要件は以下の通りとなります。

・IAMユーザー(アクセスキー)の利用を対象リソース(今回はEC2)のみに制限したい
・Private subnetのインターネットアクセスは禁止

検証環境

今回はこのような構成で検証しました。

Public Subnet環境

Public SubnetのEC2①上でAWS CLIを実行すると以下のような経路となります。

上で提示した要件を満たす場合、以下のようなIAMポリシーをIAMユーザーに適用します。

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*",
        "Condition": {
            "NotIpAddress": {
                "aws:SourceIp": [
                    "EC2のIPアドレス"
                ]
            }
        }
    }
}

AWS CLIを実行してみます。

[ec2-user@ip-172-31-33-160 ~]$ aws s3 ls
2019-11-14 08:36:31 awslogs-cloudtrail-XXXXXXXXXXXX
2019-11-14 08:36:07 awslogs-ec2-system-manager-XXXXXXXXXXXX-20191023
2019-05-28 03:55:42 cf-templates-XXXXXXXXXXXX-ap-northeast-1
2019-11-14 08:37:08 config-bucket-XXXXXXXXXXXX
2020-01-19 10:18:19 connect-XXXXXXXXXXXX
2019-09-17 04:05:51 connect-XXXXXXXXXXXX
2020-01-15 11:29:14 jeon-cloudfront-bucket
2020-02-03 10:08:39 jeon-filegateway-bucket
2020-01-27 07:18:33 jeon-sgw-bucket
2020-01-16 03:20:29 jeon-vmimport-bucket

試しに、同じIAMユーザーを利用して別EC2からAWS CLIを実行すると以下のようになります。

[ec2-user@ip-172-31-39-241 ~]$ aws s3 ls

An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied

Private Subnet環境

続いて、Private SubnetのEC2②ですが、AWS CLIを実行するためにはいずれかの対応が必要になります。

1.VPCにNatGatewayをアタッチしルート情報を追記
2.プロキシサーバーを用意し、プロキシを経由させるよう設定変更
3.対応するサービスのVPCエンドポイントを用意

対応を実施する前はAWS CLIを実施することができません。(エラーとなります)

[ec2-user@ip-172-31-2-159 ~]$ aws s3 ls

Connect timeout on endpoint URL: "https://s3.ap-northeast-1.amazonaws.com/"

今回は要件に沿うべく3のVPCエンドポイントを用意しました。
構成は以下の通りとなります。

VPCエンドポイントを用意したあとはAWS CLIは正常に動作しました。

[ec2-user@ip-172-31-2-159 ~]$ aws s3 ls
2019-11-14 08:36:31 awslogs-cloudtrail-XXXXXXXXXXXX
2019-11-14 08:36:07 awslogs-ec2-system-manager-XXXXXXXXXXXX-20191023
2019-05-28 03:55:42 cf-templates-XXXXXXXXXXXX-ap-northeast-1
2019-11-14 08:37:08 config-bucket-XXXXXXXXXXXX
2020-01-19 10:18:19 connect-XXXXXXXXXXXX
2019-09-17 04:05:51 connect-XXXXXXXXXXXX
2020-01-15 11:29:14 jeon-cloudfront-bucket
2020-02-03 10:08:39 jeon-filegateway-bucket
2020-01-27 07:18:33 jeon-sgw-bucket
2020-01-16 03:20:29 jeon-vmimport-bucket

経路は以下の通りとなります。

先程と同じようにEC2②のみを限定するIAMポリシーをアタッチし、AWS CLIを実行するとPublic Subnet時とは異なり以下の通りエラーとなります。

[ec2-user@ip-172-31-2-159 ~]$ aws s3 ls

An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied

更に、VPCエンドポイントを配置したことで、Public SubnetのEC2①でもエラーとなりました。

[ec2-user@ip-172-31-33-160 ~]$ aws s3 ls

An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied

公式ドキュメントに以下のような記載がありました。

リクエスト実行元が Amazon VPC エンドポイントを使用するホストである場合、aws:SourceIp キーは使用できません。代わりに、aws:VpcSourceIpなどの VPC 固有のキーを使用する必要があります。  https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip

設定するなら以下のようなIAMポリシーとなりますが、特定のリソース(IPアドレス)のみの制限をすることはできないものとなります。

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*",
        "Condition": {
            "StringNotEquals": {
                "aws:SourceVpce": [
                    "VPCエンドポイントのID"
                ]
            }
        }
    }
}

上記ポリシーをアタッチするとEC2①、EC2②ともにコマンドが成功となります。

[ec2-user@ip-172-31-33-160 ~]$ aws s3 ls
2019-11-14 08:36:31 awslogs-cloudtrail-XXXXXXXXXXXX
2019-11-14 08:36:07 awslogs-ec2-system-manager-XXXXXXXXXXXX-20191023
2019-05-28 03:55:42 cf-templates-XXXXXXXXXXXX-ap-northeast-1
2019-11-14 08:37:08 config-bucket-XXXXXXXXXXXX
2020-01-19 10:18:19 connect-XXXXXXXXXXXX
2019-09-17 04:05:51 connect-XXXXXXXXXXXX
2020-01-15 11:29:14 jeon-cloudfront-bucket
2020-02-03 10:08:39 jeon-filegateway-bucket
2020-01-27 07:18:33 jeon-sgw-bucket
2020-01-16 03:20:29 jeon-vmimport-bucket

さらに、この結果からPublic Subnetに配置されているEC2②は以下の経路になることがわかります。

過去に上記経路について調査したブログがありますので参考にリンクを記載しておきます。

http://blog.serverworks.co.jp/tech/2019/05/17/vpceviapublic/

最後に

今回の検証でVPCエンドポイントが配置された環境でのIAMポリシー利用について、理解が深まりました。
(そもそもIAMユーザーのアクセスキー情報を渡さなければいいと言うのは内緒で)
IAMは奥が深いサービスなので、まだまだ勉強が必要です。