EC2の認証情報を外部で利用させないポリシー設定

こんにちは。AWS CLIが好きな福島です。

はじめに
参考
嬉しいポイント
留意事項
事前準備
試してみる
所感

はじめに

今回は、先日のアップデートで追加されたIAMのグローバル条件キーを利用して、 EC2の認証情報を外部で利用させないポリシーを設定できるようになったため、実際に試してみたいと思います。

◆追加された条件キー

aws:EC2InstanceSourceVPC
Amazon EC2 IAM ロール認証情報が生成された VPC を識別します。
aws:EC2InstanceSourcePrivateIPv4
Amazon EC2 IAM ロール認証情報が生成されたプライマリ Elastic Network Interface のプライベート IPv4 アドレスを識別します。

IAM Roles for Amazon EC2 now provide Credential Control Properties

参考

aws.amazon.com

嬉しいポイント

一言で言うと、EC2のIAMロールをより楽にセキュアに利用できるようになりました。

EC2はIAMロールを利用する際に内部的に一時的な認証情報を取得しております。例えば、悪意のある第3者が外部公開しているEC2からこの一時的な認証情報を盗み、不正アクセスをするケースがあります。

EC2の設定でIMDSv1を利用できないようにすることで一時的な認証情報を盗まれるリスクを低減できるのですが、今回の設定を行えば、そもそも一時的な認証情報が盗まれても外部からは利用できないようにすることが可能なため、よりセキュアになります。
※以前から同様のことを実現できていたようですが、今回のアップデートでより楽に実現できるようになったようです。

IMDSvに関する詳細は以下をご覧ください。

InstanceMetaDataV2を分かりやすく解説してみる - サーバーワークスエンジニアブログ

留意事項

このポリシーを利用するためには、VPCエンドポイントが必須となります。例えば、EC2がCloudWatch Logsにアクセスしたい場合、CloudWatch LogsのVPCエンドポイントが必要になりますし、 SSMにアクセスしたい場合は、SSMのVPCエンドポイントが必要となります。

これは、利用する条件キーである aws:EC2InstanceSourceVPC および aws:EC2InstanceSourcePrivateIPv4 の値は、 VPCエンドポイントを経由する場合にのみ付加される情報になるためです。

事前準備

事前準備として、以下をやっておきます。

通常のEC2にEC2FullAccessを付与したIAMロールをアタッチします。
EC2のVPCエンドポイントを作成する。

試してみる

まずは、何も制限をかけていない状態でEC2の一時的な認証情報をローカル端末で利用し、アクセスしてみます。すると、何も制限をかけていないため、もちろんアクセスができます。

ローカル端末上でのコマンド実行結果

# uname -a
Linux LAPTOP-CNM26HN6 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
#
# aws ec2 describe-instances
{
    "Reservations": [
        {
            "Groups": [],
            "Instances": [
                {
                    "AmiLaunchIndex": 0,
                    "ImageId": "ami-041581098aa702a3b",
                    "InstanceId": "i-0f6126b7aeedfabd6",
     : 省略

次に新しい条件キーを含めた以下のDenyポリシーをEC2のIAMロールに追加します。

このポリシーにより、認証情報が生成されたネットワークと認証情報を使用しているネットワークを比較し、異なる場合は、アクセスをはじくことができます。

IAMポリシー例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ec2InstanceSourceVPC": "${aws:SourceVpc}"
        },
        "Null": {
          "ec2:SourceInstanceARN": "false"
        },
        "BoolIfExists": {
          "aws:ViaAWSService": "false"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ec2InstanceSourcePrivateIPv4": "${aws:VpcSourceIp}"
        },
        "Null": {
          "ec2:SourceInstanceARN": "false"
        },
        "BoolIfExists": {
          "aws:ViaAWSService": "false"
        }
      }
    }
  ]
}

※特定のアクションや特定のタグが付与されたEC2はDenyポリシーの対象外にすることも可能で、詳細は冒頭に記載の参考URLをご覧ください。

すると、予想通り、ローカル端末からのアクセスがはじかれることを確認できました。

ローカル端末上でのコマンド実行結果

#  aws ec2 describe-instances

An error occurred (UnauthorizedOperation) when calling the DescribeInstances operation: You are not authorized to perform this operation.
#

また、EC2から正常にEC2の一覧が見れることを確認できました。

EC2上でのコマンド実行結果

[root@ip-10-88-0-59 ~]# aws ec2 describe-instances
{
    "Reservations": [
        {
            "Groups": [],
            "Instances": [
                {
                    "AmiLaunchIndex": 0,
                    "ImageId": "ami-041581098aa702a3b",
                    "InstanceId": "i-0f6126b7aeedfabd6"
     : 省略

今度はVPCエンドポイントを削除した上でEC2上からコマンドを実行してみます。

すると、ローカル端末上で実行した時と同様にアクセスがはじかれることが分かります。これで、新しい条件キーを利用する場合は、VPCエンドポイントが必要なことが分かります。

EC2上でのコマンド実行結果(VPCエンドポイントない場合)

[root@ip-10-88-0-59 ~]# aws ec2 describe-instances

An error occurred (UnauthorizedOperation) when calling the DescribeInstances operation: You are not authorized to perform this operation.
[root@ip-10-88-0-59 ~]#