AWS環境における「whoAMI攻撃」へのセキュリティ対策を考えてみた

2025年2月に報告された新たなセキュリティリスク「whoAMI攻撃」。AWSのEC2インスタンスのAMIを悪用したこの攻撃に対し、Allowed AMIs機能を活用した具体的な対策手順を紹介します。

#AWS

#Amazon EC2

#AMI

おつまみ

2025.02.21

こんにちは！クラウド事業本部のおつまみです。
先日こちらの記事を見つけました。
https://www.itmedia.co.jp/enterprise/articles/2502/18/news067.html
こちらの記事で紹介されているツールを使って、どのようにセキュリティ対策を実施するか検討する機会があったのでご紹介します。
 3行まとめwhoAMI攻撃は、信頼できないAMIを誤って使用することで発生する新たなセキュリティリスクである
AWS環境での対策として、「Allowed AMIs」機能の活用が推奨されている
段階的な導入（スキャン→監査モード→有効化）で安全に実装可能である
 はじめにこちらの掲載内容を簡単にまとめました。
https://www.itmedia.co.jp/enterprise/articles/2502/18/news067.html
 whoAMI攻撃とは2024年2月、Datadogより新たなセキュリティリスク「whoAMI攻撃」が報告されました。これは、Amazon EC2インスタンスのAMIを悪用した攻撃手法です。名前混乱攻撃（NCA）の一種とされ、信頼できないAMIを誤って使用することで発生する可能性があります。
 攻撃による潜在的リスク攻撃者が意図的に作成した悪意のあるAMIを使用してしまうことで、AWS環境で不正なコードが実行される危険性があります。Datadogの調査によると、AWSを利用する企業の約1％がこの脆弱性の影響を受ける可能性があるとされています。
 具体的な保護策について記事では主に以下の対策が推奨されています。
「Allowed AMIs」機能の活用
Datadogから提供されているwhoAMI-scannerツールによる環境チェック
 実施内容上記の具体的な保護策をもとに、以下の手順で対策を実施していくことにしました。
whoAMI-scannerを使用して、現環境のEC2インスタンスが信頼できるAMIを利用しているか確認する。
「Allowed AMI」を「監査モード」で実行する。
「監査モード」で一定期間影響を確認する（1ヶ月程度）。
「Allowed AMI」を「有効」で実行し、影響を確認する。
こちらの手順はAWS公式ドキュメントの「許可されたAMIを実装するためのベストプラクティス」を一部参考にしております。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-allowed-amis.html#best-practice-for-implementing-allowed-amis
 実施内容の詳細 1. whoAMI-scannerの使用まず、「Allowed AMI」を設定する前に、現環境のEC2インスタンスが信頼できるAMIを利用しているか確認します。

これは、既に攻撃対象となっているAMIで起動しているインスタンスがないか確認するためです。

ツールとしては、Datadogのオープンソースツール「whoAMI-scanner」を使用します。
以下を参考に実施します。
https://dev.classmethod.jp/articles/run-whoami-scanner-in-aws-cloudshell/
信頼できないAMIを利用しているEC2インスタンスが判明するため、そのインスタンスがどのような経緯で作成されたものか確認します。
 2. 「Allowed AMI」を「監査モード」で実行する次に、「Allowed AMI」を「監査モード」で実行します。
「Allowed AMIs」は、re:Invent2024で発表された新機能であり、組織内で使用可能なAMIを制限する機能です。この機能により非準拠 / 未承認の AMI を誤って使用してしまうリスクを軽減することが可能となります。
この機能には、「監査」と「有効」のモードがあり、「監査」モードでは、実際にアクセスを制限することなく、どのAMIが「Allowed AMI」の基準から外れているのかを検知します。これにより、リスクのない評価期間を設けることができます。
以下を参考に実施します。
https://dev.classmethod.jp/articles/202412-allowed-amis/
AWS Organizations環境の場合は宣言型ポリシーを使用して、設定することができます。
https://dev.classmethod.jp/articles/202501-declarative-policy-for-allowed-amis
許可するAMIのプロバイダーは環境に併せて設定してください。

こちらは例となります。
{
    "ImageCriteria": [
        {
            "ImageProviders": [
                "amazon",
                "aws-marketplace",
                "aws-backup-vault",
                "123456789012"
            ]
        }
    ]
}

amazon – AWSによって作成されたAMI
aws-marketplace – AWS Marketplaceで検証済みプロバイダーによって作成されたAMI
aws-backup-vault – バックアップボールトアカウントに存在するAWS Backup AMI
123456789012 – 全アカウントへAMIを共有しているアカウント（EC2 Image Builderなど）
なお、自身のアカウントが所有するAMIは制限されないため、全リソースアカウントの設定は不要です。
参考：許可された AMI を使用して Amazon EC2 の AMI の検出と使用を制御する - Amazon Elastic Compute Cloud
 3. 「監査モード」で一定期間影響を確認する（1ヶ月程度）「Allowed AMI」を「監査モード」で実行し、許可していないAMIが検出されていないか確認します。許可していないAMIを検知した場合は、組織のセキュリティポリシー、コンプライアンス要件、運用ニーズに合ったAMIプロバイダーか検討後、上記JSONの基準変更を検討します。
監査モードでの確認期間は、システムの更新サイクルや業務の繁忙期などを考慮して設定してください。特に重要なシステム更新や業務イベントが含まれる期間を選択することで、より確実な影響確認が可能となります。
 4. 「Allowed AMI」を「有効」で実行し、影響を確認する基準が確立したら、「Allowed AMI」を「有効」にします。

有効にすることで、許可されたAMI以外はAMIコンソール上に表示されなくなります。これにより、基準に満たないAMIを使用不可にし、who-AMI攻撃を受けるリスクをゼロにします。

また、引き続きAMIからのインスタンス起動をモニタリングします。予期しない問題がないか確認し、許可されたAMI基準に必要な調整を行います。
!※ Auto Scalingを使用している場合、指定したAMIからインスタンスが起動できなくなる事象が発生する可能性がありますので、ご注意ください。
 最後に今回は、AWS環境における「whoAMI攻撃」への対策として、「Allowed AMI」を導入する方法をご紹介しました。
今回紹介したツールを活用し、より安全なAWS環境の構築を目指しましょう！
最後までお読みいただきありがとうございました！
以上、おつまみ（＠AWS11077）でした！
 参考許可された AMI を使用して Amazon EC2 の AMI の検出と使用を制御する - Amazon Elastic Compute Cloud
whoAMI-scanner を AWS CloudShell で実行して利用している AMI が信頼できる AMI なのか確認してみた | DevelopersIO
[アップデート] Amazon EC2 で AMI ガバナンスを強化するために 許可された AMI が導入されました #AWSreInvent | DevelopersIO
非 Control Tower 環境で 許可された AMI の declarative policies（宣言型ポリシー）の適用をやってみた | DevelopersIO