AWSの脅威検知とは、クラウドのテレメトリを分析して攻撃者の行動の兆候を探り、AWS内における悪意のある、あるいは不審な活動を特定し、優先順位を付けることを指します。このアプローチでは、個々のイベントを単独で評価するのではなく、攻撃者が複数のID、ロール、サービスにまたがってどのような行動を取っているかを検証します。過去1年間に80％の組織が少なくとも1件のクラウドセキュリティ侵害を経験しており、パブリッククラウドのインシデントによる被害額は1件あたり平均517万ドルに達していることから、効果的なAWS脅威検知の重要性はますます高まっています。
AWS環境では、膨大な量のログやメタデータが生成されますが、これらを単独では解釈するのが困難です。こうしたテレメトリデータを「振る舞い 」として結びつけることで、クラウド攻撃のライフサイクルにおける攻撃者の動きを明らかにすることができます。相関付けられていないアクティビティは調査や対応を遅らせる可能性があるため、これは極めて重要です。
実際の運用では、AWS脅威検知は関連するアクションを振る舞い として結び付け、調査と優先順位付けを可能にします。クラウドテレメトリを無関係なアラートの集合体として扱うのではなく、活動を潜在的な攻撃シーケンスの証拠として解釈します。この区別が重要なのは、多くのAWSアクションが技術的には正当な操作でありながら、アクセス権、ロール、サービスの悪用を表している場合があるためです。
時間やサービスを超えて意図を明らかにするアクティビティの種類：
AWSの脅威検知機能は、クラウド上のアクティビティを、攻撃者の潜在的な行動を示す証拠に基づいた視点に変換します。一般的な検知ワークフローは、以下の6つの段階で構成されています。
このワークフローは、基本的なログ収集とは異なります。ログは発生した事象の記録を提供するのに対し、脅威検出では、その動作の文脈、相関関係、優先順位付けを追加することで、その活動が攻撃者の進行を示すものかどうかを判断するのに役立ちます。
AWSは、クラウド上の脅威検知戦略の基盤となる、いくつかのネイティブセキュリティサービスを提供しています。各ツールの機能と、まだ対策が不十分な点を把握することで、チームは効果的な検知体制を構築することができます。
Amazon GuardDutyは、AWSの主要な脅威検知サービスです。このサービスは、機械学習、異常検知、統合された脅威インテリジェンスを活用し、CloudTrailの管理イベント、VPC Flow Logs、DNSクエリログ、およびランタイムテレメトリを継続的に分析します。2025年12月、AWSはEC2およびECS向けの「Extended Threat Detection」をリリースしました。この機能はAI/MLを使用して、複数のデータソースにわたるシグナルを相関分析し、多段階の攻撃シーケンスを MITRE ATT&CK の戦術にマッピングします。
Security Hubは、GuardDuty、Amazon Inspector、AWS Config、およびサードパーティ製ツールからの検出結果を統合ダッシュボードに集約します。CIS AWS Foundationsなどの基準に対するコンプライアンスチェックを提供し、AWS LambdaやAmazon EventBridgeとの連携を通じて、自動的な是正措置をサポートします。
Detectiveは、より詳細な調査分析を提供することで、GuardDutyを補完します。GuardDutyが重大度の高い検出結果を特定した場合、Detectiveはリソース全体にわたる不審なアクティビティの発生源、範囲、および関連性を追跡するのに役立ちます。
表：AWSネイティブの脅威検知サービスの比較
これらのネイティブツールは基本的なカバー範囲を提供しますが、その対象はAWS内のアクティビティに限定されています。AWSの外部――侵害されたIDプロバイダー、オンプレミスネットワーク、あるいはSaaSアプリケーションなどを経由して――開始される攻撃を検知し、攻撃チェーン全体を把握するには、ハイブリッド環境全体にわたる追加の相関分析が必要となります。
AWSにおけるログ中心の監視では、イベントが個別のレコードとして分析されるため、攻撃者の行動を明らかにできないことがよくあります。原因の特定は、多くの場合、直近のロールや一時的な認証情報で止まってしまい、調査が誤った抽象化レベルに集中してしまう原因となります。その結果、防御側は、影響が生じる前に活動を封じ込めるために、本来の攻撃者を時間内に特定できない可能性があります。
AWSのアクティビティを個別の事象として評価した場合の障害モード：
攻撃者がAWS内でどのように移動するかを理解するには、個々のサービス操作だけにとどまらず、その先を見据える必要があります。行動に焦点を当てた検知手法を用いることで、ロールチェイニング、ログ回避、サービス間の横方向のアクセスといった進行パターンが浮き彫りになります。これらは、個別に見た場合には正当な動作のように見える可能性があります。
進行パターン：
AWS内のすべてのシグナルが同等の調査価値を持つわけではありません。検知活動では、特定のアクターに関連する異常な行動や複数段階にわたる行動を反映する指標を優先します。初期段階の指標は微細で分散している場合があり、一方、後期段階のシグナルは重大な被害が発生した後に初めて表面化することが多いのです。
主なシグナル：
AWSにおける効果的な脅威検知には、広範なテレメトリの収集範囲と、不審な動作をその原因となった攻撃者やワークロードに結びつけるための十分な識別情報との両方が不可欠です。
AWS Organizations と委任管理機能を活用し、環境全体でセキュリティサービスを一貫して適用します。すべてのアクティブなアカウントおよびリージョンで、関連するログ記録と検知機能を有効にし、検出結果を一元管理することで、アナリストが個別のコンソールやデータストアを調査する必要がなくなります。
特権アクセスには多要素認証を必須とし、root ユーザーの使用を制限し、ユーザー、ロール、およびワークロードに対して最小権限のポリシーを適用します。AWS Security Token Service のアクティビティ（異常な動作を含む）を監視します。 AssumeRole シーケンス、アカウント間のアクセス、および役割の連鎖などにより、本来の身元が隠蔽される可能性がある。
CloudTrailの管理イベントは、AWSリソースや権限の変更を反映しますが、データイベントは、Amazon S3やAWS Lambdaなどのサービスに関連するアクティビティを可視化します。組織は、機密性の高いリソース、調査要件、およびコストに基づいて、データイベントのカバー範囲を選択する必要があります。
セキュリティ対策を変更したり、持続性を確立したり、データを漏洩させたりする可能性のあるアクティビティを優先的に対処してください。例としては、予期しない呼び出しなどが挙げられます。 「アクセスキーの作成」、「ロールポリシーの紐付け」、「ロールポリシーの設定」、「ロール引き受けポリシーの更新」、「ログの停止」、「トレイルの削除」、「バケットポリシーの設定」、およびシークレット取得API。
1件の通話だけでは正当なものである可能性があります。しかし、不審なID、ネットワーク、またはリソースの挙動と併せて確認された場合、その調査上の価値は高まります。
EC2インスタンスプロファイル、Lambda実行ロール、Amazon ECSタスクロール、およびAmazon EKSワークロードIDを確認してください。権限が過剰に付与されていると、アプリケーションの侵害が、認証情報の不正アクセス、権限の昇格、またはデータの持ち出しを伴う、より広範なクラウドへの侵入へと発展する恐れがあります。
AWSネイティブのテレメトリを利用すれば、その攻撃を可能にした以前のエンドポイント、IDプロバイダー、またはSaaSの侵害を露呈させることなく、アカウント内で何が起きたかを把握できる可能性があります。クラウド、ID、ネットワークの挙動を相互に関連付けることで、ハイブリッドな攻撃経路を再構築し、元々の攻撃者を特定することが可能になります。
対応担当者が、セッションの取り消し、アクセスキーの無効化、ワークロードの隔離、ロールの制限、またはアカウントの隔離をいつ実行できるかを定義します。Amazon EventBridge、AWS Lambda、および既存のセキュリティオーケストレーションワークフローを活用して自動化を行うことは可能ですが、破壊的な操作については、テスト、承認ルール、およびロールバック手順を必ず含める必要があります。
最近の事例は、ログレベルの監視だけでは不十分であり、行動検知がなぜ重要なのかを如実に示している。
ランサムウェアグループ「Codefinger」は、不正入手したAWSの認証情報を悪用し、顧客提供キーによるサーバーサイド暗号化（SSE-C）を使用してS3データを暗号化しました。攻撃者は、 マルウェアではなく正規のAWS暗号化機能を使用したため、従来のシグネチャベースの検知ツールはこの活動を検知できませんでした。不審な認証情報チェーンに関連する異常な一括暗号化操作を検知する「振る舞い 」のみが、データが復元不能になる前にこの攻撃を明らかにすることができました。
Amazon Threat Intelligenceは、2026年1月11日から2月18日にかけて、ロシア語を話す金銭目的の攻撃者が商用生成AIサービスを利用して、55カ国以上で600台以上のFortiGateデバイスを侵害した攻撃キャンペーンを報告した。攻撃者はAIを活用して攻撃規模を拡大しており、AIを活用した脅威が、熟練した攻撃者だけでなく未熟な攻撃者においても攻撃件数を増加させていることが示された。
2026年2月、ある攻撃者は、AWS上で稼働していたパッチ未適用のReactフロントエンドアプリケーションを悪用して初期アクセス権を取得し、その後、AWS Secrets Managerへの広範な読み取りアクセス権を持つ、権限が過剰に付与されたECSタスクロールを悪用しました。これにより、Redshiftの認証情報、VPCマップ、および数百万件のデータベースレコードが外部へ流出しました。 このインシデントは、T1190（公開アプリケーションの悪用）、T1078（有効なアカウント）、T1530（クラウドストレージオブジェクトからのデータ）MITRE ATT&CK に該当しており、AWSの脅威検知においてIDとロールの挙動を監視することが不可欠である理由を浮き彫りにしています。
これらのインシデントには共通のパターンが見られます。攻撃者は、AWSの正規の仕組み（暗号化機能、有効なロール、一時的な認証情報）を利用して悪意のある活動を行いましたが、その活動はイベントレベルでは正常に見えたものの、振る舞い その正体が明らかになりました。
AWSにおける脅威の検知には依然として限界がある。不審な行動を特定できる一方で、脅威の検知はクラウドセキュリティリスクを自動的に防止または修復するものではない。つまり、チームは依然として対応ワークフローとアナリストの判断に依存する必要がある。検知と防止を混同すると、封じ込めを遅らせる盲点が生じる可能性がある。
表：誤解と正しい認識
いくつかのトレンドが、AWS環境における脅威検知への組織の取り組み方を変えつつあります。
AWSの脅威検知を支援するには、ID、ネットワーク、クラウド上のアクティビティにまたがる攻撃者の行動を、単一の連続体として理解する必要があります。Vectra AI 、AWSのイベントを孤立したアラートとして扱うのではなく、アクション間の相関関係を分析することでこの課題に取り組んでいます。これにより、ロール、一時的な認証情報、および複数サービスにわたるアクティビティによって原因の特定が困難になる場合でも、不確実性を低減できます。Vectra AI「Cloud Detection and Response (CDR) for AWS」は、ハイブリッドな攻撃対象領域全体にわたる行動を分析することで、ネイティブツールの枠を超えた検知を実現します。
プラットフォームの機能：
CloudTrailの監視は個々のイベントを記録するのに対し、AWSの脅威検知は、攻撃者の振る舞いを明らかにするために、ID、ロール、サービス、時間軸を横断してイベントを関連付けることを目的としています。孤立したログイベントは発生した事象を示すことはできますが、特に攻撃者が一時的な認証情報やロールの乗っ取りを利用する場合、その意図や進行過程を示すことは稀です。実用上の違いは調査手法にあります：脅威検知は、分析担当者が生のログから手動で経緯を組み立てることを余儀なくされるのではなく、帰属させられ対応可能な多段階の行動パターンを優先的に検知します。
いいえ。AWSの脅威検知は、それ自体ではアーキテクチャや設定上の問題を防止または修正しません。設定ミス管理は安全でない設定や露出状態の特定に焦点を当てているのに対し、脅威検知はAWS環境内で発生する悪意のある活動や不審な活動の特定に重点を置いています。これらの機能を混同することは重大な問題です。チームが検知が設定セキュリティに取って代わると誤解し、主要な侵入経路に対処せずに脅威検知で補完できると期待する可能性があるためです。
アイデンティティとロールは、攻撃者が最初の侵害後、想定されたロールや一時的な認証情報といった正当なアクセスメカニズムを用いて活動することが多いため、中心的な役割を果たします。アクションは不正行為を示すものであっても、APIレベルでは有効に見える場合があるため、誰がシーケンスを開始したのか、そしてそのシーケンスが想定される動作と一致しているかどうかを理解するには、アトリビューションが不可欠となります。ロールの連鎖によって元の攻撃者が不明瞭になる可能性があり、最後に使用された一時的なロールで調査が停止すると、調査が失敗する可能性があるため、これは重要です。
正当なAWSメカニズムを利用した複数段階の動作は、イベントごとに評価すると最も検知が困難になります。ロールの連鎖、一時的な認証情報のシーケンス、そして単独では正常に見える動作も、多くの場合、サービスやID間の相関関係がなければ意味を持ちません。これらのパターンは複数のAWSサービスや時間枠に分散している可能性があり、最後に使用された認証情報が元の攻撃者を反映していない可能性があるため、検知が困難です。これは、初期段階の微妙な動作は、後期段階の兆候が現れるまで見逃される可能性があるため、重要です。
はい、可能です。ただし、AWSを独立したドメインとして扱うのではなく、環境間のアクティビティを連携させるアプローチが必須です。ハイブリッド攻撃は、侵害されたラップトップやIDプロバイダーから開始され、その後、信頼されたID関係と想定されたロールを使用してAWSに侵入する可能性があります。IDと関連テレメトリの相関関係がなければ、AWSのアクティビティは最初の侵害経路から切り離されているように見える可能性があります。これは重要です。なぜなら、防御側は、対応と帰属の範囲を適切に決定するために、クラウドでのアクションが以前のアクセスとどのように関連しているかを理解する必要があるからです。
Amazon GuardDutyは、機械学習を用いてCloudTrailイベント、VPC Flow Logs、およびDNSログを分析し、悪意のある動作を特定することで、アクティブな脅威検出を行います。AWS Security Hubは、GuardDuty、Amazon Inspector、AWS Config、およびサードパーティ製ツールからのアラートを収集し、優先順位を付ける一元的な集約ツールです。GuardDutyが脅威を検出し、Security Hubがそれらを整理・管理します。 多くの組織では、GuardDutyを検知エンジンとして、Security Hubをアカウントやリージョンを横断して対応の優先順位を決定するための運用ダッシュボードとして、これらを組み合わせて使用しています。
まず、すべてのAWSアカウントおよびすべてのリージョン（現在使用されていないリージョンを含む）でAmazon GuardDutyを有効にします。攻撃者は、監視されていないリージョンを標的として、暗号通貨マイニングなどの活動を行うためです。GuardDutyの検出結果をAWS Security Hubに取り込み、一元的に可視化します。重大度の高い検出結果の調査にはAmazon Detectiveを追加します。次に、EventBridgeのルールとLambda関数を設定し、重大なアラートへの対応を自動化します。この多層的なアプローチにより、検知、集約、調査、および自動対応が実現されます。
攻撃者は、クラウドインフラに対する攻撃を拡大させるために、商用生成AIサービスをますます利用するようになっている。 2026年初頭、Amazon Threat Intelligenceは、攻撃者がAIを利用して55カ国以上にわたる600台以上のネットワーク機器を侵害し、その後クラウド環境へと攻撃の矛先を向けたキャンペーンを記録した。AIは、攻撃者が手動の手法よりも迅速に偵察を自動化し、エクスプロイトコードを生成し、設定ミスを特定することを可能にする。AIを活用した攻撃は、ルールベースの検知システムを機能不全に陥らせるほど大量のアクティビティを生成するため、この傾向により、振る舞い 重要性が高まっている。
「拡張脅威検知」は、2025年12月に提供が開始された機能であり、AIと機械学習を活用して、AWSサービス全体にわたる多段階の攻撃シーケンスを特定します。 不審なイベントごとに個別の調査結果を生成するのではなく、認証情報の悪用、権限の昇格、データの持ち出しといったシグナルを相互に関連付け、MITRE ATT&CK マッピングされた単一の攻撃シーケンスとして提示します。これにより、アナリストが個々の調査結果を手動で結びつける必要がなくなり、攻撃の全容を可視化することで、トリアージにかかる時間を短縮します。
