この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
みなさん、GuardDuty運用してますか？(挨拶
今回はタイトル通りUnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWSの検出結果を適切にフィルター・抑制するためのTipsを紹介します。
概要
GuardDutyは先日UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWSというFinding Typesに対応しました。該当AWSアカウントのEC2から搾取されたIAMクレデンシャルを、別のAWSアカウントで利用された場合に検出するものです。詳細は以下を確認してください。
非常に頼もしい機能である一方、複数アカウントでネットワークの集約などを行っていると、このFindingsが過検知されることがあります。AWS Transit Gatewayで接続されている場合などはGuardDutyが学習し、この検出を抑制する機能もあるとリリース時のWhat's Newには書かれていますが、学習までの時間やこの他の接続形態の場合など、抑制が必要になるケースもあります。
画面から直接フィルターできない
しかしながら、このFinding Typesで追加された新しい値であるRemote account ID(jsonとしてはAwsApiCallAction.RemoteAccountDetails.AccountId)はGuardDutyの画面から直接フィルターできませんでした。下記画面のように、通常フィルターできる値は右側に虫眼鏡マークが追加されており、ワンクリックでフィルターにルールを追加できるようになっていますが、この値は虫眼鏡がありません。実際にフィルター一覧でも同様の値はありませんでした。
したがって、私はこれまで対象のAWSアカウントIDでフィルターできないものと考えていました。
ワークアラウンドとしては、ActorのIP Address(API発信者のIPv4アドレス)を指定することで、例えば集約した先のNAT Gateway経由であれば許容する、といった設定が可能でした。
集約先AWSアカウントIDでフィルターする
依然としてRemote account IDを直接指定することはできませんが、代わりにAPI caller account IDというフィルターでも同じような役割ができることを確認しました。以下の図のようになります。
残念ながらFindingsのjson構造を確認しても、どの値を条件にフィルターされるかは確認できませんでしたが、求めているものを適切にフィルターできることを確認しました。
したがって、検出結果タイプにUnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS、API caller account IDに集約先AWSアカウントIDを入れたフィルターを作成し、これを抑制ルールに登録することで、過検知を是正できそうです。
なお、現状この方法の裏付けとなるドキュメントを確認できていませんので、その点はご了承ください。
まとめ
UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWSが過検知される場合の抑制方法について紹介しました。
本件も含め、「こう使いたい！」という要望があればAWSへフィードバックしどんどん良くしていきましょう！
12
