GuardDutyがECSの漏洩クレデンシャル不正利用を検知可能に ── 一時認証情報の持ち出し検知を整理する

Amazon GuardDutyに、ECSタスクから漏洩した一時認証情報の不正利用を検知する機能が加わった。ニュースとしては「対応リソースがまた一つ増えた」という一行で終わってしまう話だが、インフラを運用する側から見ると、この一連の機能追加はもう少し面白い構造を持っている。GuardDutyが数年かけて広げてきた「一時認証情報の持ち出し検知」は、実は2つのシンプルな判定ロジックの組み合わせで成り立っていて、今回のECS対応もその延長線上にある。

本記事では、個々の新機能を追いかけるのではなく、この検知の設計思想を軸に、EC2・Lambda・ECSにまたがるクレデンシャル持ち出し検知の全体像を整理する。仕組みを一度理解しておくと、新しいリソースが対応するたびにドキュメントを読み直さなくても「ああ、あのパターンね」と読み解けるようになる。

出発点：EC2の一時認証情報はなぜ狙われるのか

話の起点はEC2だ。IAMロールをアタッチしたEC2インスタンスでは、そのインスタンス上で動くアプリケーションが、インスタンスメタデータサービス（IMDS）経由で一時的な認証情報を取得できる。アクセスキー・シークレットキー・セッショントークンの3点セットで、有効期限は最長でも数時間、権限はアタッチされたロールの範囲に限定される。SDKが自動で取得・更新してくれるので、アプリ側にキーを直書きしなくて済む、という便利な仕組みだ。

便利な反面、この認証情報は攻撃者にとって格好の標的でもある。SSRF（サーバーサイドリクエストフォージェリ）やコマンドインジェクションなどの脆弱性を突いて、インスタンス内部からメタデータサービスのエンドポイント（169.254.169.254）を叩ければ、認証情報を丸ごと抜き取れてしまう。抜いた認証情報を攻撃者の手元に持ち出せば、被害者のアカウント内でロールの権限に応じたAPIを自由に呼び出せる。これが「一時認証情報の持ち出し（Credential Exfiltration）」と呼ばれる攻撃だ。

GuardDutyは2017年のサービス開始当初から、この持ち出しを検知する仕組みを持っていた。ただし、その検知ロジックは時間をかけて段階的に強化されてきた。そしてその強化の歴史を理解する鍵が、次に説明する「2つの判定軸」である。

検知を支える2つの判定軸 ── OutsideとInside

GuardDutyのクレデンシャル持ち出し検知には、発想の異なる2つの判定軸がある。この2軸さえ押さえれば、リソースがEC2だろうとLambdaだろうとECSだろうと、Findingの名前を見ただけで「何を疑っているのか」がわかる。

軸①：OutsideAWS ── 「AWSの外のIPから使われたか」

1つ目は、認証情報がAWSのネットワーク外のIPアドレスから使われたかどうかを見る軸だ。EC2インスタンス用に発行された一時認証情報は、本来そのインスタンス（＝AWS内部）から使われるべきもの。それがインターネット越しの外部IPから使われたのなら、「誰かが認証情報を手元に持ち出して使っている」と考えるのが自然だ。GuardDutyがサービス開始当初から持っていたのが、この最も素直な検知である。

軸②：InsideAWS ── 「別のAWSアカウントから使われたか」

ところが、OutsideAWSだけでは抜け穴があった。攻撃者が盗んだ認証情報を自前のEC2インスタンスの中から使えば、呼び出し元IPはAWSのネットワーク内に見える。OutsideAWSは「AWS外からのアクセス」しか見ていないため、この手口をすり抜けてしまう。

そこで2022年1月、AWSは新しい判定軸を追加した。認証情報を発行したインスタンスが属するアカウントと、実際に呼び出してきた元のアカウントが異なる場合に発火する検知だ。攻撃者が別アカウントのEC2から認証情報を使えば、アカウント境界をまたいだ時点で検知される。「AWSの中にいるかどうか」ではなく「持ち主と同じアカウントにいるかどうか」で見る、という発想の転換である。

この2軸をまとめると、こう整理できる。Outsideは外周（AWSの内か外か）で見張り、Insideはアカウント境界（同じアカウントか否か）で見張る。持ち出された認証情報がどこで使われても、この二重の網のどこかに引っかかる、という設計だ。

対象リソースの広がり ── EC2からLambda、そしてECSへ

ここで重要なのは、今回のECS対応が「まったく新しいFindingの追加」ではなく、既存の判定軸の適用範囲がリソース側に広がったものだ、という理解である。一時認証情報を発行するのはEC2だけではない。LambdaにもECSタスクにもIAMロールをアタッチでき、それぞれが一時認証情報を持つ。ならば、同じ「Outside／Inside」の考え方をそれらのリソースにも適用すればいい ── というのが機能拡張の流れだ。

Finding名にもこの構造が表れている。EC2向けはInstanceCredentialExfiltrationという名前だが、Lambda以降はResourceCredentialExfiltrationという、より汎用的な名前に変わっている。「インスタンス」ではなく「リソース」の認証情報、というわけだ。時系列で追うと次のようになる。

• 2017年〜：EC2向けInstanceCredentialExfiltration.OutsideAWS（AWS外IPからの利用を検知）
• 2022年1月：EC2向けInstanceCredentialExfiltration.InsideAWSを追加（別アカウントからの利用を検知）
• 2025年12月：Lambda向けResourceCredentialExfiltration.OutsideAWSが登場
• 2026年7月：ResourceCredentialExfiltrationがECS（Fargate／EC2起動タイプの両方）に対応。Outside／Insideの両輪が揃う

ECSタスクはSSRFやコンテナ侵害の標的になりやすく、とりわけFargateはホストに直接アクセスできないマネージド環境のため、これまで持ち出し検知の観点では死角になりがちだった。そこがOutside／Insideの両軸でカバーされたことの意味は大きい。コンテナ由来の認証情報が外部IPから使われても、別アカウントから使われても、いずれも検知の対象になる。

整理：Finding種別 × 判定軸 × 対象リソース

ここまでの内容を一枚の表にまとめる。名前が長くて紛らわしいFinding群も、この3列（種別・判定軸・リソース）で見れば構造は単純だ。

縦に見ると「Instance＝EC2専用の古い名前」「Resource＝汎用の新しい名前」という命名の世代差が、横に見ると「Outside＝外周監視」「Inside＝アカウント境界監視」という判定軸の違いが読み取れる。新しいリソースが対応しても、埋まるのはこの表のマス目のどれか、というだけの話になる。

運用上の注意点 ── 正常でも発火する構成がある

この検知系で運用担当者が知っておくべき落とし穴が、正常な構成でも発火しうるという点だ。OutsideAWS系のFindingは「AWS外のIPから認証情報が使われた」ことをトリガーにするが、ネットワーク設計によっては、正規のトラフィックがAWS外を経由するように見えることがある。

公式ドキュメントが例として挙げているのは、インターネット向けトラフィックをVPCのインターネットゲートウェイ（IGW）ではなく、オンプレミス側のゲートウェイからegressさせる構成だ。AWS OutpostsやVPN接続を使ったハイブリッド構成では、こうした経路になることがある。この場合、実態は正規の通信でも、GuardDutyからは「AWS外のIPからの利用」に見えてしまう。

対処は抑制ルール（Suppression rule）だ。2つのフィルタ条件で組むのがドキュメント推奨の形で、1つ目に該当のFinding種別（例：ResourceCredentialExfiltration.OutsideAWS）、2つ目に「API caller IPv4 Address」として自社オンプレゲートウェイのIPまたはCIDRレンジを指定する。これで、正規経路由来の既知の発火だけを黙らせつつ、想定外のソースからの利用は引き続き検知できる。

もう一点、GuardDutyのML挙動も運用上おさえておきたい。GuardDutyは特定のリモートホストやアカウントからの利用が継続すると、それを「想定された挙動」として学習し、そのソースからの発火を止める。学習によってノイズが減るのは利点だが、裏を返せば「一度学習された経路は鳴らなくなる」ため、抑制ルールでの明示的な管理と、新規ソースに対する検知が働き続けることの両輪で捉えておくのが安全だ。

まとめ

ECS対応というニュースの実体は、「一時認証情報の持ち出し検知」という既存の枠組みが、また一つ広いリソースをカバーしたということだ。押さえるべき勘所を改めて整理する。

• 検知は2軸で成り立つ：Outsideは「AWSの外のIPか」、Insideは「別のAWSアカウントか」で見張る。この二重の網が持ち出しを捕まえる。
• ECS対応は新Findingではなく範囲拡大：ResourceCredentialExfiltrationという汎用の枠が、Lambdaに続いてECS（Fargate含む）へ広がったもの。
• 正常構成での誤検知に備える：オンプレegressやハイブリッド構成では正規通信でも発火しうる。抑制ルールを「Finding種別＋送信元IP」の2条件で組んで運用する。

なお、公式のFindingドキュメントの記述は現時点でリソースの説明がLambda中心の表記に留まっている箇所があり、実際の対応範囲（ECS/Fargateでの発火）が記述に追いついていない部分もある。実環境でFargateタスクから実際に発火させて挙動を確認した検証は、別記事で詳しく取り上げる予定だ。

出典：Amazon GuardDuty ユーザーガイド「GuardDuty IAM finding types」、AWS What’s New「Amazon GuardDuty now detects EC2 instance credentials used from another AWS account」（2022年1月20日）、GuardDuty Findings更新通知（ResourceCredentialExfiltration：Lambda対応 2025年12月17日／ECS対応 2026年7月）ほか。対応状況は変わりうるため、最新情報は公式ドキュメントを参照してください。