AWS Security Incident Response によるセキュリティ運用の最適化

本ブログは 2025 年 9 月 23 日に公開された AWS Blog “Optimize security operations with AWS Security Incident Response” を翻訳したものです。

2026 年 7 月 6 日: 現在の機能を反映するために、この記事を更新しました。

セキュリティ脅威には迅速な対応が求められます。そこで AWS Security Incident Response は、セキュリティポスチャをすぐに強化できる保護を提供します。この包括的なソリューションは、自動化されたトリアージと評価ロジックをセキュリティ境界のメタデータと組み合わせて重大な問題を特定し、必要に応じて人間の専門家の知見をシームレスに取り入れます。Security Incident Response を Amazon GuardDuty および AWS Security Hub と統合し、一元的なセキュリティ環境を構築すると、組織は AWS のセキュリティインシデント対応の専門家に 24 時間 365 日アクセスできるようになります。迅速な検出、専門家による分析、効率的な脅威の封じ込めを実現でき、そのすべてを 1 つの直感的なコンソールで管理できます。AWS Security Incident Response は AWS エンタープライズサポートと AWS Unified Operations に含まれています。AWS Unified Operations は、組織が AWS を大規模に、効率的かつ安全に導入、運用するのに役立ちます。

この記事では、Security Incident Response を有効にして概念実証 (POC) を実施し、セキュリティ機能を短期間で強化しながら、すぐに効果を得る方法を説明します。具体的には、サービスの機能、POC の成功基準の設定、構成の定義、デプロイの準備、サービスの有効化、初日からの効果の最適化について紹介します。これらを通じて、インシデント対応ライフサイクル全体で組織が自信を持って対応できるようになり、復旧時間の短縮にもつながります。

Security Incident Response の機能を理解する

AWS Security Incident Response サービスは、効率化された 4 段階のプロセスを通じて、包括的な脅威検出と対応機能を提供します。まず、GuardDuty のセキュリティ検出結果と、AWS Security Hub Cloud Security Posture Management (CSPM) と統合された一部のサードパーティ製ツールからの検出結果を取り込みます。次に、お客様のメタデータと脅威インテリジェンスを使用してこれらの検出結果を自動的にトリアージし、異常な動作や疑わしいアクティビティを特定します。潜在的な脅威が検出されると、Security Incident Response チームの対応担当者がカスタマーポータルを通じてケースをプロアクティブに調査し、実際の脅威か誤検知かを判断します。脅威が確認された場合は、直ちに対処できるよう、サービスが検出結果をエスカレーションします。一方、誤検知の場合は、自動トリアージシステムと GuardDuty および Security Hub の抑制ルールが更新され、検出精度が継続的に向上します。

最小限の前提条件で包括的な保護を実現

Security Incident Response は、脅威検出とインシデント対応 (TDIR) システムに加え、CrowdStrike、Lacework、Trend Micro、SentinelOne、Palo Alto Networks – Prisma Cloud Compute、Wiz (Toxic Combinations) などのサードパーティ製セキュリティサービスともシームレスに統合し、強力なセキュリティ機能を提供します。このソリューションは、GuardDuty の検出結果を取り込み、Security Hub CSPM を通じて外部プロバイダーと統合しながら、計画やコミュニケーションから解決まで、エンドツーエンドのインシデント管理を担う統合コマンドセンターとして機能します。サードパーティとの統合に必要なのは検出結果の取り込みだけで、Security Hub CSPM の全機能は必要ありません (セキュリティ標準、コントロール、コンプライアンスチェックは不要です)。検出結果は毎月最初の 10,000 件まで無料で、それ以降は 1 件あたり 0.00003 USD です (例えば、610,000 件の場合は月額約 18 USD)。詳細については、「Security Hub CSPM の料金」を参照してください。

安全なケース管理と変更不可能なアクティビティタイムラインにより、可視性が向上し、AWS で実績のあるツールと人員を活用できるようになります。これにより、セキュリティオペレーションセンター (SOC) とインシデント対応 (IR) チームが補強され、セキュリティ運用が大幅に強化されます。

AWS のセキュリティインシデント対応担当者は、調査と復旧の際にお客様側のインシデント対応担当者と協力して作業するため、貴重なリソースを他の優先事項に充てることができます。このサービスは、プロアクティブなモニタリングと対応機能によって継続的な価値を提供します。GuardDuty と Security Hub の検出結果を使用して環境を常時モニタリングし、サービスによる自動化、トリアージ、分析がバックグラウンドで着実に行われるため、本当にセキュリティ上の懸念がある場合にのみアラートが送信されます。常に注意を払っていなくても、潜在的なインシデントの発生時にすぐに効果を発揮します。

使用開始は簡単です。唯一の前提条件は、AWS Organizations を有効にし、メンバーアカウントを含む基本的な組織単位 (OU) 構造を Organizations で確立しておくことです。この基盤は、Security Incident Response のデプロイを可能にするだけでなく、組織全体で堅牢な TDIR 戦略を実装するための土台にもなります。

成功基準を決定する

成功基準を設定すると、POC の成果をビジネス目標に照らして評価できます。基準の例は次のとおりです。

• インシデント対応チームを指定する: インシデント対応を担当する社内のチームメンバーと外部の担当者を特定し、文書化します。「AWS Well-Architected セキュリティの柱」で強調されているように、担当者をあらかじめ指名しておくと、セキュリティインシデント発生時のトリアージと対応にかかる時間を短縮できます。
• 正式なインシデント対応フレームワークを策定する: 詳細なプレイブックと定期的な机上演習のプロトコルを含む、包括的なインシデント対応計画を策定します。AWS は、プレイブックのリファレンスライブラリを GitHub で提供しています。
• 机上演習を実施する: 実際の危機が発生する前に、定期的なシミュレーションの実施を検討してください。シミュレーションによってインシデント対応計画をテストしてギャップを特定し、セキュリティチーム全体で実践的な対応力を身に付けることができます。さまざまな種類の机上演習については、AWS が情報を提供しています。
• 既存のサードパーティのセキュリティプロバイダーを特定する: Security Hub と統合されており、Security Incident Response にデータを提供できるサードパーティのセキュリティプロバイダーを特定します。AWS パートナーが提供する検出結果については、「検出と分析」を参照してください。
• GuardDuty を実装する: ベストプラクティスに従って GuardDuty を設定し、重要なサービス全体で脅威をモニタリング、検出します。GuardDuty のベストプラクティスは、AWS が「AWS Security Services Best Practices for GuardDuty」で公開しています。

期間や組織固有の制約を考慮したうえで目標が現実的かどうか、成功基準を見直してください。例えば、組織にデプロイされている AWS サービスの設定を完全に管理できますか？実装とテストに時間を割ける担当者を確保できますか？関係するステークホルダーがサービスを評価するのに、この時期は適していますか？

Security Incident Response の構成を定義する

成功基準とタイムラインを設定したら、ベストプラクティスとして Security Incident Response の構成を定義します。重要な決定事項には次のようなものがあります。

• 委任管理者アカウントを選択する: Security Incident Response の委任管理者 (DA) として機能するアカウントを決めます。このアカウントと選択した AWS リージョンで、Security Incident Response のサービスとポータルがホストされます。AWS Security Reference Architecture (AWS SRA) では、専用のセキュリティツールアカウントを使用することを推奨しています。DA を確定する前に、考慮事項と推奨事項に関するドキュメントを確認してください。
• アカウントの範囲を定義する: Security Incident Response は組織レベルのサービスとして位置付けられています。組織内のすべてのリージョンにあるすべてのアカウントが、単一のサブスクリプションで保護の対象となります。アカウントを追加または削除すると、それに応じてサービスの対象範囲が自動的に調整されるため、AWS 環境全体を漏れなく保護できます。
• 検出結果のソースを設定する: 組織のニーズに応じて、取り込むセキュリティ検出結果を決定します。このサービスは、組織全体の GuardDuty の検出結果と、サードパーティパートナーから提供される一部の種類の Security Hub 検出結果を自動的に取り込みます。セキュリティポスチャとインシデント対応機能にとって最も価値のある GuardDuty の保護プランと Security Hub の検出結果を評価してください。
• エスカレーションフレームワークを策定する: セルフマネージドのケース、AWS がサポートするケース、プロアクティブなケースといったケースタイプごとに、明確なエスカレーションのしきい値を設定します。また、重大度、影響、必要なリソースに基づいて、ケース送信の要否とケースタイプを決定する権限を誰が持つかを定義します。
• 分析戦略を実装する: ネイティブの AWS 分析ツール (Amazon Athena、Amazon OpenSearch Service、Amazon Detective など) を使用するか、既存のセキュリティ情報およびイベント管理 (SIEM) ソリューションと統合するかを決定します。これらの機能により、コンテキストデータとより深いインサイトを活用して、インシデント対応を強化できます。

デプロイの準備をする

成功基準と Security Incident Response の構成を決定したら、ステークホルダー、目指す状態、期間を明確にします。次の項目を完了して、デプロイに備えます。

• プロジェクト計画とタイムラインを作成する: 明確な成功基準、プロジェクトの対象範囲、主要なマイルストーン、現実的な実装タイムラインを含むプロジェクト計画を策定します。推奨されるタイムラインは次のとおりです。
  • 有効化前: GuardDuty と、必要に応じて Security Hub のサードパーティ統合を設定し、リソース計画を立てる
  • 0 日目 – サービスを有効にする
  • 1 週目 – リアクティブなセキュリティインシデント対応ケースを作成する
  • 2 週目 – IT サービスマネジメント (ITSM) ツールに接続する
  • 3 週目 – 机上演習を実施する
  • 4 週目 – サービスから提供されるレポートを確認する
• ステークホルダーを特定する: CISO、情報セキュリティチーム、SOC 担当者、インシデント対応チーム、セキュリティエンジニア、財務、法務、コンプライアンス、外部のマネージドセキュリティサービスプロバイダー (MSSP)、事業部門の代表者を特定します。
• RACI マトリックスを作成する: インシデント対応ライフサイクル全体の役割と責任を定義した詳細な RACI チャートを作成し、説明責任と適切なコミュニケーションチャネルを確保します。
• 管理アカウントのアクセスを設定する: 管理アクセスを委任するための承認を取得します。詳細については、「委任 Security Incident Response 管理者アカウントの指定に必要なアクセス許可」を参照してください。
• IAM ロールとアクセス許可を設定する: AWS Identity and Access Management (IAM) ロールを使用して、RACI チャートに沿ったロールベースのアクセス制御を実装します。AWS マネージドポリシーを使用して、ケース管理、エスカレーション、読み取り専用などのロールを用意します。詳細については、「AWS マネージドポリシー」を参照してください。

Security Incident Response を有効にする

準備が整ったら、サービスを有効にします。

管理アカウントで Security Incident Response にアクセスする

1. 組織の管理アカウントで AWS マネジメントコンソールに移動し、コンソールの検索バーで Security Incident Response を検索します。
2. [サインアップ] を選択します。
3. [委任管理者アカウントを使用 – 推奨] が選択されていることを確認します。委任管理者のアカウント番号を [アカウント ID] フィールドに入力し、[次へ] を選択します。
4. 手順 3 で設定した委任管理者アカウントにサインインし、Security Incident Response を検索して、[サインアップ] を選択します。

委任管理者アカウントでセットアップを完了する

1. メンバーシップの詳細を定義します。
   1. [リージョンの選択] でホームリージョンを選択します。
   2. [メンバーシップ名] に、組織の命名規則に従った適切な名前を入力します。
   3. [メンバーシップの連絡先] で、[プライマリ連絡先] と [セカンダリ連絡先] の情報を入力します。
2. 組織のタグ付け戦略に従って [メンバーシップタグ] を追加します。
3. [次へ] を選択します。
4. アクセス許可を設定します。
   1. [By choosing this option…] (このオプションを選択すると…) で始まるオプションを選択し、[次へ] を選択します。
   2. サービスのアクセス許可を確認し、[次へ] を選択します。
5. メンバーシップの設定と詳細を確認し、[サインアップ] を選択します。

注: 詳細な手順は、YouTube のセットアップ動画で確認できます。

多くの組織では、IR とセキュリティ脅威管理のためのプロセスやアプリケーションスイートが既に確立されています。こうした既存の環境に対応できるよう、AWS は一般的な ITSM およびケース管理アプリケーションとの統合を開発しました。

AWS Security Incident Response は、Jira および ServiceNow との双方向の統合 (ケースの更新が双方向に同期されます) と、Amazon EventBridge を介した Slack および PagerDuty とのイベント駆動型の統合に対応しています。対応する統合は今後も追加される予定です。AWS では、セットアップ手順を詳しく説明したガイドを GitHub で提供しています。

訳注: 2026 年 10 月時点のユーザーガイドでは、Slack も Jira や ServiceNow と同様に、ケースの更新を双方向で同期する統合として案内されています。詳細は「ステップ 4: 既存のツールと統合する」を参照してください。

初日から価値を最大化する

サービスを有効にするとすぐに、Security Incident Response は GuardDuty の検出結果の取り込みを開始します。セキュリティパートナーとの連携を設定している場合は、Security Hub CSPM の検出結果も取り込まれます。検出結果は決定論的な評価ロジックによって自動的にトリアージ、モニタリングされます。そして、組織固有のメタデータとセキュリティ境界に基づいて、優先度の高い脅威が Security Incident Response のコマンドセンターにエスカレーションされ、直ちに調査されます。組織は最初から 24 時間 365 日の保護を受けられますが、以下の推奨事項に沿って最適化を行うと、ビジネス固有のリスクとコンプライアンス要件に合わせてカスタマイズされた保護を実現できます。その結果、脅威検出の精度が大幅に向上し、誤検知が減り、対応時間が短縮され、全体的なセキュリティポスチャが強化されます。

Security Incident Response の価値をすぐに最大限引き出すために、初日からリアクティブな機能を活用することをお勧めします。チームが疑わしいアクティビティを確認した場合や、専門家による調査が必要な場合は、サービスポータルから AWS がサポートするケースを作成し、AWS のセキュリティインシデント対応担当者に直接支援を依頼できます。これらのセキュリティの専門家はチームの能力を効果的に補い、専門知識とガイダンスを提供して、潜在的なセキュリティ上の懸念を迅速に把握、封じ込め、修復できるよう支援します。AWS のセキュリティインシデント対応をオンデマンドで利用できるため、平均解決時間を短縮し、潜在的な影響を最小限に抑えられます。また、社内リソースだけでは対応しきれない複雑なセキュリティシナリオでも、専門家のサポートを確実に受けられます。

リアクティブなサポートへの問い合わせ例を次に示します。

• 環境内で、さまざまな API コールを実行している疑わしい IP アドレスを確認しました。調査を支援していただけますか？
• 2 日前に新しいアカウントが作成されたことが、Amazon EventBridge ルールおよびエンドポイント検出と対応 (EDR) の統合から通知されました。影響範囲の特定と作成者の調査を支援していただけますか？どのように作成されたのでしょうか？
• AWS Identity and Access Management (IAM) ユーザーがクロスリージョンの API コールを実行し、使用していないリージョンでリソースを作成しています。
• EDR ソリューションが本番ウェブサイトで異常な動作を検出しました。侵害の可能性があります。
• EDR が疑わしいウェブシェルのアップロードとアクティビティを検出しました。調査と隔離を支援してください。
• あるユーザーが、自身の権限レベルを超える不正な API アクティビティを実行しました。権限昇格の特定を支援してください。
• AWS WAF と Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのセキュリティログの分析を支援してください。侵害の痕跡や疑わしいパターンはありますか？

次のステップ

AWS Security Incident Response の採用を決めて POC をデプロイする場合は、次の対応をお勧めします。

• GuardDuty を設定してデプロイし、管理アカウントとメンバーアカウント、重要なサービス、ワークロード全体で、包括的かつ適切な保護範囲を維持します。
• サードパーティ製セキュリティツール (CrowdStrike、Lacework、Trend Micro など) が Security Hub と適切に統合されていることを確認します。
• セキュリティインシデント対応ツールの変更について、組織内の関連チームに周知します。

まとめ

この記事では、AWS Security Incident Response の POC を計画、実装する方法を紹介しました。成功基準の定義、Security Incident Response の構成、Security Incident Response がビジネスニーズを満たしているかどうかの検証といったフェーズに沿って、その進め方を説明しました。

このガイドは、お客様が Security Incident Response の POC を成功させるのに役立ちます。現在提供されている機能の導入を検討する際に、その価値と考慮すべき要素を評価するための指針となります。

その他のリソース

• AWS Security Incident Response – はじめに
• Security Hub を介したセキュリティツール統合の設定
• Amazon EventBridge を使用した Security Incident Response イベントの管理
• Amazon GuardDuty のベストプラクティス
• AWS Security Hub のベストプラクティス
• AWS セキュリティインシデント対応ガイド (ベストプラクティス)
• AWS Managed Services のオファリング
• AWS Security Incident Response ブログ: インシデント対応ライフサイクルの加速に向けたお客様のジャーニー

この記事に関するご質問は、AWS サポートにお問い合わせください。

本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。