AWS Security Incident Response 入門 自動トリアージ・専門家対応・ケース管理・料金

1. この記事について — 検知の”先”にあるインシデント対応

1-1. 本記事のゴール

GuardDutyやSecurity Hubで脅威を検知できる体制は整えたものの、検知した後の実対応をどう組み立てるかで悩んでいないでしょうか。

本記事は、この「検知の先」にあるインシデント対応を、AWSのマネージドサービスであるAWS Security Incident Responseを軸に整理することをゴールとしています。検知の仕組みそのものではなく、検知後に何が起こり、誰がどう動くのかという実運用の視点に焦点を当てます。

本記事を読み終えたとき、読者の方には次の4点に到達していただくことを目指します。

• AWS Security Incident Responseの全体像とサービス境界(何をして、何をしないか)を、他者に正確に説明できる状態
• GuardDuty findingsが自動トリアージを経てエスカレーションに至るまでの流れと、大半のfindingsが1%未満に絞り込まれる仕組みへの理解
• Proactive/Reactiveのケース種別と、Organizations横断でのメンバーシップ運用を設計できる状態
• 2025年11月改定後の従量課金体系を正しく理解し、自組織の環境で概算コストを見積れる状態

これらの到達点は、単なる機能紹介にとどまりません。本サービスを「導入するかどうか」を判断するための材料と、導入した場合に「どう運用に落とし込むか」の両方を提供することを狙っています。

成果物イメージとしては、Organizationsのメンバーシップアカウントを有効化し、GuardDuty findingsとの連携を設定した上で、Proactive/Reactiveケースが実際の運用フローに乗っている状態を思い浮かべてください。導入の判断材料から日々の運用設計までを一気通貫でカバーします。

本記事が特に有効なのは、GuardDutyを複数リージョンで有効化しており、Organizationsによるマルチアカウント運用をしている組織です。単一アカウント・単一リージョンの小規模環境でも導入は可能ですが、規模が大きくOrganizations横断の運用委任が必要な組織ほど、本サービスが提供する価値は大きくなります。

なお、本記事が扱わない範囲もあらかじめ明確にしておきます。

• 脅威ハンティングやフォレンジック調査そのものの実施手順(本サービスの対象外であり、詳細は§2-2で扱います)
• GuardDuty・Security Hubの検知設定そのもの(既存の検知系記事シリーズに譲ります)
• SSM Automation Runbookによる自前対応の実装手順(既存の自動化系記事シリーズに譲ります)

本記事の章立ては、§2で全体像とサービス境界を押さえた後、§3〜§5で自動トリアージ・専門家対応・ケース管理という3つの中核機能を詳説し、§6でOrganizations横断運用、§7で料金体系、§8でオンボーディング手順とまとめという構成です。具体的な導入手順を急ぎ確認したい場合は§8から読み進めることもできます。

1-2. 読者像

本記事が想定する読者は、GuardDutyやSecurity Hubを中心とした検知体制はすでに構築しているものの、「検知した後、誰がどう対応するか」という実運用の体制に課題を感じているSOC担当・セキュリティ運用担当の方々です。

具体的には、次の3つの課題感を持つ方を想定しています。

トリアージの人的リソース不足

脅威検知のfindingsは増え続ける一方、それを一件ずつ精査し、本当に対応が必要なものを絞り込む人的リソースが不足している状況です。findingsの件数が増えるほど、担当者の負荷は線形以上に増大していきます。

24時間365日の実対応体制の欠如

自組織だけで深夜・休日を含む24時間の監視・対応体制を構築するのは、相応の人員とシフト設計が必要であり、特に中小規模のセキュリティチームには負担が大きくなります。

専門知識を要する判断の不足

実際にインシデントが発生した際、フォレンジック調査や封じ込めの範囲判断には専門知識が求められます。社内にその経験を持つ人材が十分でない状況は、対応の遅延や誤った判断につながりかねません。

こうした課題は、たとえば次のようなインシデントシナリオで顕在化します。

• IAMクレデンシャルの漏洩によるアカウント乗っ取りを疑わせるfindingsが深夜に発生した場合
• ランサムウェアの兆候を示すfindingsが複数アカウントにまたがって検知された場合
• 内部からの不審なデータ持ち出しを疑わせるfindingsが、業務時間外に検知された場合

これらのシナリオでは、findingsの真偽判定・影響範囲の特定・封じ込めの実行判断を、限られた時間の中で下す必要があります。組織内にその体制がなければ、対応が後手に回るリスクが高まります。

チーム内での役割分担としては、日々のfindings対応はSOC担当者やセキュリティ運用エンジニアが担い、事前承認の要否や封じ込めポリシーの設計はセキュリティリーダーやCISOクラスの判断が必要になります。導入検討の段階から、現場の運用者と意思決定者の両方を巻き込むことが望ましい進め方です。

前提知識としては、AWSアカウントの基本操作、GuardDutyの基礎的な仕組み(findingsの生成・重要度の考え方)、AWS Organizationsの基本概念(管理アカウント・メンバーアカウント・委任管理者)を理解していることを想定しています。KubernetesやEDR製品固有の知識は本記事では前提としません。

一方で、まだGuardDutyやSecurity Hubを導入しておらず、検知の仕組みそのものから学びたいという方には、本記事はやや先の内容になります。その場合は、検知・可視化を扱う既存記事シリーズから読み始めることをお勧めします。本記事は、検知の”次”の段階、つまり実際の対応体制の設計に焦点を当てています。

1-3. 既存の検知・自前運用との棲み分け — 本記事の立ち位置

AWSでインシデント対応関連のセキュリティ運用を整備する際、混同されやすいのが「検知」「自前の対応自動化」「マネージドな対応支援」という3つの異なるレイヤーです。本記事の内容を正しく位置づけるために、まずこの3レイヤーを整理します。

①の検知レイヤーは、脅威を見つけ出す「目」の役割を担います。findingsを生成しますが、それをどう対応するかまでは踏み込みません。検知・可視化・Findingsトリアージの具体的な設定は、既存のGuardDuty/Security Hub関連記事に譲ります。

②の自前運用レイヤーは、自組織で用意したRunbookに基づき、特定パターンの脅威に対して自動的に封じ込め・復旧アクションを実行する仕組みです。柔軟にカスタマイズできる一方、Runbookの設計・保守・24時間の運用体制はすべて自組織の責任範囲になります。こちらの実装は既存のSSM Automation Runbookによるインシデント対応自動化シリーズで詳説しています。

③の本記事が扱うAWS Security Incident Responseは、①で検知されたfindingsを引き継ぎ、AWSの専門家チーム(Security Incident Response Engineering team)が自動トリアージと人的判断を組み合わせて対応するマネージドサービスです。②の自前Runbook運用とは異なる対応モデルであり、①・②の”先”に位置する第三のレイヤーとして位置づけられます。

重要なのは、③が①・②を置き換えるものではないという点です。①の検知体制は本サービスの前提として必要であり、②の自前Runbookは定型的で判断基準が明確な脅威への即応手段として引き続き有効です。たとえば、既知パターンのポートスキャンや設定ミスの是正には②の自前Runbookで即座に自動対応し、判断の難しい専門知識を要する脅威は③のマネージド対応にエスカレーションするという役割分担が現実的です。

この役割分担を曖昧にしたまま導入すると、SOC担当者が「GuardDutyで検知したのに、なぜ本サービスから通知が来ないのか」といった誤解を持つリスクがあります。①・②・③がそれぞれ独立したレイヤーであることを、導入前にチーム内で共有しておくことが、運用上の混乱を防ぐ実務上のポイントです。

技術的な接続点として、①のGuardDuty findingsはAWSのセキュリティ検知基盤を通じて③に引き継がれ、③からの通知やケース更新はAmazon EventBridge経由で②の自前自動化や外部ツール(Jira/Slack/ServiceNow等)に連携できます。NIST SP 800-61のライフサイクルで捉えると、①が検知(Detection)を、②と③が分析・封じ込め・復旧(Analysis/Containment/Recovery)を分担する構図です。

この3レイヤーの関係を理解しておくことで、「なぜGuardDutyだけでは不十分なのか」「なぜ自前のRunbook運用だけでは足りないのか」という疑問に対し、本記事が③のレイヤーとして提供する価値の位置づけが明確になります。

1-4. なぜマネージドなインシデント対応が必要か

GuardDutyやSecurity Hubで検知の仕組みを整えた組織が次に直面するのは、「検知した後、誰が・いつ・どう対応するか」という空白です。この空白を埋めるための判断材料を整理します。

空白①: 24時間365日の実対応体制

findingsは深夜・休日を問わず発生します。自組織だけでオンコール体制を維持するには、相応の人員とシフト設計が必要になり、特に中小規模のセキュリティチームには負担が大きくなります。

空白②: 専門知識を要する判断

インシデント対応にはNIST SP 800-61のライフサイクル(検知・分析・封じ込め・根絶・復旧)に沿った専門的な判断が求められます。特に封じ込めの判断——どの範囲まで影響が及んでいるか、どのアクションが安全か——は経験豊富な専門家の判断が有効に働く領域です。

空白③: findingsのノイズ

GuardDutyやSecurity Hubは有用な検知をしますが、すべてのfindingsが実対応を要するインシデントとは限りません。相関付けと重複排除を経て、本当に対応が必要なものだけに絞り込むトリアージの仕組みがなければ、担当者はアラート疲れに陥ります。

これら3つの空白と、AWS Security Incident Responseが提供する対応能力の関係を整理すると次のとおりです。

AWS Security Incident Responseは、これら3つの空白を、AWSのマネージドサービスとして提供することで埋めます。自組織でゼロから同等の24時間体制・専門人材・トリアージ基盤を構築するコストと比較した上で、導入を判断する材料になります。この比較は、専任のセキュリティエンジニアの採用・育成コストや、24時間シフトを組むための人員コストを考えると、特に中小規模の組織にとって現実的な検討材料になります。

導入を判断する際のチェックポイントとして、次の3点を確認することをお勧めします。

• 24時間対応が必要なfindingsの発生頻度は、自組織のオンコール体制で吸収できる範囲か
• 封じ込め判断を専門家に委ねることについて、社内のセキュリティポリシー上の合意が得られるか
• Organizations全体でGuardDutyが全アクティブリージョンで有効化されているか

検知体制(①)を整備した組織にとって、次の投資判断は「対応の空白をどう埋めるか」です。自前でエンジニアを採用・育成する方向と、AWSのマネージドサービスを活用する方向は二者択一ではなく、組織のセキュリティ成熟度や既存リソースに応じて使い分けるべき経営判断です。

ただし、マネージド対応がすべてを解決するわけではありません。フォレンジックの深掘りや修復の実行は対象外であり(§2-2で詳述)、自組織の責任範囲は残ります。「検知の空白を埋める手段の一つ」として、既存の自前運用と組み合わせて検討することが現実的な判断です。

AWSセキュリティ関連記事の一覧を見る →

2. AWS Security Incident Responseとは — 全体像とサービス境界

2-1. サービス概要 — マネージドなインシデント対応

AWS Security Incident Responseは、2024年12月1日に一般提供(GA)を開始した、AWSのマネージドセキュリティインシデント対応サービスです。

サービスの提供価値は、環境の常時監視からトリアージ、対応が必要な場合にのみ顧客に関与を求めるという運用モデルに集約されます。GuardDutyやSecurity Hub CSPMが生成するfindingsを取り込み、自動化されたトリアージプロセスを通じて、本当に対応が必要なものだけをエスカレーションします。エスカレーションされたケースには、AWSのSecurity Incident Response Engineering teamが調査・封じ込め支援・復旧ガイダンスを提供します。

このサービスは、AWSサポートプラン(Business/Enterprise等)とは異なる位置づけです。サポートプランはAWSサービス自体の技術的な問い合わせや障害対応を扱うのに対し、本サービスはセキュリティインシデントという特定領域に特化した対応を提供します。Enterprise SupportやAWS Unified Operationsを契約している場合でも、本サービスを利用するには別途メンバーシップの有効化が必要です(料金上の扱いは§7で扱います)。

GuardDutyやSecurity Hubを導入していても、findingsの件数が数百・数千件規模になると、すべてを目視でトリアージするのは現実的でなくなります。本サービスが自動トリアージという形でこの一次選別を肩代わりすることが、サービス全体の価値の核になっています。

具体的な処理の流れは、次の5段階で構成されます。

この流れの詳細は§3(①②)・§4(③④⑤の調査・封じ込め・復旧)で扱います。本節ではまず、①〜⑤を貫く設計思想を押さえます。

このサービスはNIST SP 800-61(Computer Security Incident Handling Guide)に準拠した一貫したアプローチを採用しています。NIST SP 800-61は、インシデント対応を「準備」「検知と分析」「封じ込め・根絶・復旧」「事後対応」という段階で捉えるフレームワークであり、業界標準として広く参照されています。本サービスは、この枠組みに沿った形で検知後のプロセスを標準化して提供します。

対象となるインシデントの例としては、IAMクレデンシャルの漏洩によるアカウント乗っ取り、ランサムウェアの兆候、想定外のデータ持ち出し(データ漏洩)などが挙げられます。これらは単発のfindingsとしてではなく、複数のシグナルが組み合わさった「実インシデント」として扱われ、専門家による調査・判断が必要になる領域です。

いずれの例も、単一のfindingだけでは全体像が見えにくいという共通点があります。たとえばアカウント乗っ取りの兆候は、通常と異なるIPアドレスからのAPIコール、普段使わないリージョンでのリソース作成、IAMポリシーの変更といった複数のfindingsが時間差で発生することで、初めて「実インシデントらしさ」が浮かび上がってきます。この相関付けを自動で行う点が、本サービスの中核的な提供価値です。

サービスには継続的改善の仕組みも組み込まれています。Engineering teamは全顧客の調査から得られた知見(侵害指標・攻撃手法のパターン)を蓄積し、トリアージ精度の向上に還元しています。顧客側も検証要求への迅速な応答を通じて、この改善サイクルの精度向上へ貢献する構造になっています。

毎月のレポートも提供されます。取り込んだfindings数・トリアージの結果・作成されたケース数といった活動実績が月次でまとめられ、自組織のセキュリティ運用状況を継続的に把握できます。

有効化そのものはOrganizationsのメンバーシップアカウントを指定するところから始まります。詳細な手順は§8で扱いますが、本節では「検知基盤(GuardDuty)の稼働が既に前提になっている」という点だけ押さえておいてください。検知基盤がなければ、本サービスの取り込み対象となるfindingsそのものが存在しないため、順序としてはまず検知の整備が先になります。

GA以降、サービスは継続的に機能拡張されています。2025年11月には料金体系が月額サブスクリプションから従量課金へと改定されており(詳細は§7)、中小規模の環境でも導入を検討しやすい環境が整ってきています。判断材料としては、既に24時間稼働する検知基盤があるかどうかが、本サービス導入の実質的な前提条件になります。

監視対象は、メンバーシップへ登録したアカウントに限られます。Organizationsの管理アカウント全体を対象にする方法と、特定のOU(組織単位)だけを対象にする方法があり、この選択の詳細は§6で扱います。登録していないアカウントは監視・調査の対象外になるため、導入時にどの範囲を対象とするかを明確に決めておく必要があります。

自組織で同等の体制を構築する場合のコストと比較する視点も、判断材料として有効です。24時間対応可能な専門人材を採用・育成し、シフトを組んで維持するコストは、中小規模の組織にとって決して小さくありません。この比較の詳細な考え方は§7-3で扱います。

本サービスは、GuardDutyやSecurity Hub CSPMといった検知サービス、あるいはDetectiveのような調査支援サービスと連携しながら機能する設計です。単独で完結するサービスではなく、既存のAWS検知・分析エコシステムの上に「対応」というレイヤーを追加するものだと捉えると、全体像を理解しやすくなります。

以上を踏まえると、本サービスの全体像は「検知は既存サービスに任せ、トリアージから対応までをマネージドに引き受ける」という一言に集約できます。次節では、この全体像を前提に、最も誤解が生じやすいサービス境界を詳しく見ていきます。

2-2. サービス境界 — 何をして、何をしないか

サービス境界の理解は、本サービス導入における最大の落とし穴です。「検知までしてくれる」「フォレンジックまで代行してくれる」といった誤解を持ったまま導入すると、期待と実態のギャップが運用上のトラブルにつながります。

まず明確にすべきは、AWS Security Incident Responseは検知サービスではないという点です。findingsを自ら生成することはなく、GuardDutyやSecurity Hub CSPMを置き換えるものでもありません。取り込んだfindingsをトリアージする専門サービスという位置づけです。

また、単なるアラート集約ツールでもありません。大半のサービスがすべてのアラートをそのまま顧客に転送するのに対し、本サービスは相関付け・重複排除・動的トリアージによって大半のfindingsを自ら吸収し、対応が必要なもの(全体の1%未満)のみをエスカレーションします。

さらに、Security Hub CSPMが検出するようなセキュリティ体制・コンプライアンス上のfindings(設定不備・ベンチマーク違反など)もトリアージの対象外です。これらは「今この瞬間の脅威」ではなく「環境の状態」を示す情報であるため、脅威対応を目的とする本サービスの性質にはなじみません。体制系findingsの是正は、Security Hub CSPM側の運用として別途対応する必要があります。

サービスがする/しないことを表で整理します。

この表で特に見落とされがちなのが、フォレンジックと脅威ハンティングが対象外である点です。本サービスの調査はログベースの分析が中心であり、ディスクイメージングやメモリ解析といった深いフォレンジック調査、あるいはまだfindingsになっていない潜在的な脅威を能動的に探す脅威ハンティングは、サービスの範囲外です。これらが必要な場合は、AWS Professional Servicesや専門のフォレンジックベンダーとの連携を別途検討する必要があります。

封じ込めについても誤解が生じやすいポイントです。封じ込めは「事前承認制」であり、顧客があらかじめS3バケット・EC2インスタンス・IAMプリンシパルに対する封じ込めランブックの実行を承認していない限り、専門家は実行せず手動ガイダンスの提供にとどまります。この事前承認の設計判断については§4-2で詳しく扱います。

ログの扱いにも境界があります。Engineering teamは調査中に限りコントロールプレーンのログへアクセスしますが、ログデータそのものが顧客に提供されることはなく、ケースノートを通じて要約・結論のみが共有されます。ログの生データを直接確認したい場合は、CloudTrailやVPC Flow Logsを自組織側でも並行して保持・分析しておく必要があります。

実際に起こりがちな誤解のパターンを挙げると、「本サービスを導入すれば脅威ハンティングやペネトレーションテストも代行してもらえる」という思い込みです。境界表のとおり、これらは一般的なセキュリティガイダンスの領域であり、AWS Professional Servicesなど別のサービスの守備範囲になります。導入検討の段階で「本サービスに何を期待するか」を関係者間ですり合わせておくことが、後々の期待値ギャップを防ぎます。

対象外の領域について、AWSは相談先を公式ドキュメントで明示しています。境界を理解した上で、必要に応じて次の窓口へ切り分けることをお勧めします。

境界を正しく理解した上で導入することが、本サービスを実務に定着させる最初の一歩です。境界の誤解を放置したまま運用を始めると、「フォレンジックまで任せられると思っていたのに対象外だった」「検知漏れが起きたと思ったら、そもそも検知はGuardDuty側の責任だった」といった認識のズレが、インシデント対応の最中に発覚するリスクがあります。導入前のオンボーディング(§8)で、関係者全員にこの境界表を共有しておくことを強くお勧めします。

境界表は一度共有して終わりではなく、定期的な振り返りの材料としても活用できます。四半期ごとのセキュリティレビューなどの場で、実際に発生したケースが境界表のどこに位置していたかを確認することで、チーム全体の理解を継続的に更新していくことができます。

2-3. 3つの中核機能 — 自動トリアージ・専門家対応・ケース管理

AWS Security Incident Responseの機能は、大きく3つの中核機能に整理できます。

①24/7自動監視・トリアージ

GuardDutyやSecurity Hub CSPMのfindingsを常時取り込み、相関付け・重複排除・動的評価による多段階のトリアージを行います。この機能によって、全体の1%未満に対応が絞り込まれます。トリアージは一度きりの静的な判定ではなく、状況の変化に応じて再評価される動的な仕組みである点が特徴です。詳細は§3で扱います。

②専門家による調査・封じ込め・復旧支援

自動トリアージで判断がつかない場合、Security Incident Response Engineering teamが調査に入ります。事前承認があれば封じ込めランブックを実行し、復旧に向けたガイダンスを提供します。調査にはEC2 Triageのように、インスタンスへの直接アクセスなしにデータを収集する仕組みも含まれます。詳細は§4で扱います。

③ケース管理

Proactive(自動起票)・Reactive(顧客起票)の2種類のケースを、統一されたポータルで一元管理します。外部関係者への可視性付与やEventBridge経由の外部連携も含まれます。能動的なインシデント対応中はコールブリッジによるリアルタイムのコミュニケーションも利用できます。詳細は§5で扱います。

なお、②のチームは現行ドキュメントでは「Security Incident Response Engineering team」という名称ですが、サービスGA当初の発表では「AWS Customer Incident Response Team(CIRT)」という表記が使われていました。現行のドキュメントではCIRTという表記は使われておらず、Security Incident Response Engineering teamに統一されています。過去の記事やコミュニティの議論でCIRTという表記を見かけた場合は、同じチームを指す旧称だと理解してください。

①のトリアージが自動化されているとはいえ、判断の一貫性を保つために抑制ルール(suppression rules)という仕組みも用意されています。顧客とEngineering teamの双方が合意した場合に限り、特定パターンのfindingsを監視対象から除外できる機能で、通常のトリアージとは異なり恒久的な除外になります。運用が定着してくると、既知の安全な挙動に対してこの抑制ルールを活用する場面が出てきます(詳細は§3-3)。

③のケース管理では、ケースのクローズは常に顧客のアクションであるという設計も押さえておくべきポイントです。Engineering teamはケースを「Ready to Close(クローズ可能)」の状態にできますが、最終的にケースを閉じるのは顧客自身です。調査が完了しても自動的にクローズされるわけではないという点が、運用フローを設計する上で見落としやすい細部です。

3つの機能をNIST SP 800-61のライフサイクルに当てはめると、①のトリアージが「検知と分析」の前半、②の調査・封じ込め・復旧支援が「検知と分析」の後半から「封じ込め・根絶・復旧」まで、③のケース管理が全フェーズを通じた記録・コミュニケーションの基盤という役割分担になります。この対応関係を意識しておくと、後続の§3〜§5で各機能の詳細を読み進める際に、全体のどの部分を扱っているかを見失いにくくなります。

外部連携の窓口としてはAmazon EventBridgeが中心となり、ケースのライフサイクルイベントがすべて発行されます。Jira・Slack・ServiceNowといったツールへの連携パターンが文書化されているほか、独自のツールへも同じEventBridgeイベントを使って接続できます。連携設計の詳細は§5-3で扱います。

3つの中核機能を補完する形で、APIによるセルフサービス機能も提供されています。ケース情報のプログラムからの取得や、自組織の運用ツールへの組み込みが可能で、③のケース管理をEventBridge連携と組み合わせることで、外部のチケット管理システムと連動した運用設計ができます。

導入前の準備(Preparedness)機能も見逃せないポイントです。オンボーディング時にインシデント対応チームのメンバーと通知先を事前に設定しておくことで、実際のケース作成時には、関係者への連携が迅速に届く仕組みが整います。事前の体制構築が、インシデント発生時の初動速度を左右します。

これら3つの機能は独立して動くのではなく、①のトリアージ結果が②の調査要否を判断し、②の調査・封じ込めの経過が③のケースとして記録・共有されるという一連の流れでつながっています。次節以降では、まず顧客側の責任範囲(§2-4)と提供リージョン(§2-5)を確認した上で、§3以降で各機能の詳細に入ります。

2-4. 顧客の責任範囲 — 共同で回すインシデント対応

AWS Security Incident Responseはマネージドサービスですが、インシデント対応を丸ごと顧客から切り離すものではありません。責任共有モデルの考え方に基づき、顧客側にも一定の責任が求められます。

検証要求への迅速な応答

調査の過程でEngineering teamが「この挙動は想定内か」といった確認を求めることがあります。応答が遅れると調査が保留状態になり、対応全体が遅延する原因になります。窓口となる担当者があらかじめ決まっていることが望まれます。

セキュリティ連絡先の維持

インシデント発生時に確実に連絡が取れる窓口を、常に最新の状態で維持する必要があります。担当者の異動や連絡先変更があった場合は速やかに更新することが求められます。

ロギングの有効化

AWS CloudTrailやAmazon VPC Flow Logsなど、調査の基盤となるログを有効化しておく必要があります。ログが不足していると、調査の精度・速度の双方に影響します。

封じ込め・復旧推奨の実装

Engineering teamが提示する封じ込め・復旧の推奨事項を、実際に実行するのは顧客の責任です。事前承認していない封じ込めアクションについては、ガイダンスを受けた上で顧客自身が実行判断を下します。

抑制ルールの合意と能動的な関与

前節で触れた抑制ルールは、顧客とEngineering teamの双方が合意して初めて有効になります。合意なく一方的に監視対象から除外されることはなく、顧客側にも「この挙動は本当に安全と言えるか」を判断する責任が伴います。また、能動的なインシデント対応が発生した際には、確認依頼への応答だけでなく、コールブリッジでのやり取りや成果物の共有など、双方向のコミュニケーションへの参加が求められます。

ケースクローズの実行

§2-3で触れたとおり、ケースを最終的にクローズするのは常に顧客です。Engineering teamが「Ready to Close」の状態にしても、調査結果を確認し、実際にクローズを操作するのは顧客側の責任として残ります。これを失念すると、解決済みのケースがオープンのまま放置され、ケース管理の実態が不正確になっていきます。

サービスの効果は、顧客の協力度合いによっても左右されます。確認依頼への迅速な応答や、環境固有の事情(通常運用として想定される挙動など)をEngineering teamに共有することで、誤検知が減り、真のインシデントへの対応速度が上がるという好循環が生まれます。

これらの責任は、いずれも「マネージドだから何もしなくてよい」という理解とは相容れません。むしろ、平常時からの準備(ロギングの有効化・連絡体制の整備)が、実際のインシデント発生時の対応品質を左右します。

信頼関係の観点からも、この責任分担は重要です。前節で触れたとおり、Engineering teamは調査中のログデータそのものを顧客に開示せず、ケースノートによる要約・結論の共有にとどめます。裏を返せば、顧客側が自らCloudTrailやVPC Flow Logsを保持していなければ、詳細なログをあとから独自に精査する手段が失われることになります。マネージドサービスに委ねる部分と、自組織で保持すべき記録を切り分けておくことが実務上の要点です。

オンボーディングの段階(§8)でこれらの準備状況を確認しておくことが、導入後の運用をスムーズにする実務上のポイントです。特に、セキュリティ連絡先の設定とロギングの有効化は、ケースが実際に発生する前に完了させておくべき最優先事項として扱ってください。

自前運用と組み合わせる場合の役割分担も、あらかじめ整理しておくと安心です。②の自前Runbook運用(SSM Automation等)で自動対応する領域と、③のマネージド対応にエスカレーションする領域の線引きを事前に決めておけば、実際のインシデント発生時に「どちらが対応するか」で迷う時間を減らせます。

サービスの有効化に必要なIAM権限・サービスリンクロールの維持も、継続的な顧客責任の一つです。SCP(サービスコントロールポリシー)で必要な権限を誤ってブロックしてしまうと、メンバーシップの機能そのものが正しく動作しなくなります。具体的な設定要件は§8-1で扱いますが、導入後も定期的にSCPの変更がサービス運用に影響しないかを確認しておくことが望まれます。

2-5. 東京リージョン・提供状況・日本語サポート

AWS Security Incident Responseは、2026年7月時点でAWS公式ドキュメントに記載されている限り、25のAWSリージョンで提供されています。東京リージョン(ap-northeast-1)は、サービスのGA当初から対応リージョンに含まれています。

提供リージョンを地域別に整理すると次のとおりです。

なお、AWSは対応リージョンの総数を明示的に謳ってはいません。公式ドキュメントに列挙されたリージョン一覧を実際に数えると25リージョンになる、という点は押さえておいてください。

対応リージョンは固定ではなく拡大を続けています。2025年12月には新たに10リージョンが追加されており、GA当初と比べて利用可能なリージョンの選択肢は着実に広がっています。導入を検討する際は、本記事執筆時点の一覧を鵜呑みにせず、公式ドキュメントの最新のリージョン一覧を確認することをお勧めします。

監視対象そのものは、メンバーシップを有効化したアカウントの「全アクティブな商用リージョンのGuardDuty findings」です。つまり、Security Incident Responseの利用可否(メンバーシップ登録・ケース管理)は上記25リージョンに限られますが、監視の対象となるGuardDuty findingsは、リソースを実際にデプロイしていないリージョンも含めて全リージョンから収集することが、公式推奨のベストプラクティスです。全リージョンでGuardDutyを有効化しておくことで、想定外のリージョンでの不審な活動も見逃さない体制になります。

日本語サポートについては、制約がある点に注意が必要です。日本語でのサポートは、平日の日本時間営業時間帯(09:00〜17:00、月曜〜金曜、祝日を除く)におけるベストエフォート対応に限られます。英語サポートは24時間365日提供されますが、日本語での対応を前提に運用フローを設計する場合は、この時間帯制約を運用設計に織り込んでおく必要があります。特に、深夜・休日に発生したインシデントで日本語対応を期待する場合は、英語でのやり取りが基本になる点を、導入前に関係者へ周知しておくことをお勧めします。

この制約は、担当者のスキルセット設計にも影響します。深夜・休日帯の一次対応者には、日本語対応が限定的であることを前提に、最低限の英語での状況説明・確認応答ができる体制を整えておくことが実務上望まれます。

なお、メンバーシップやケースの保存先リージョンは初回登録後に変更できません(詳細は§6-3)。東京リージョンで運用する場合は、この点をあらかじめ組織設計に組み込んでおく必要があります。日本語対応の時間帯制約とあわせて、導入前のチェックリストに加えておくことをお勧めします。

以上、§2ではAWS Security Incident Responseの全体像・サービス境界・中核機能・顧客責任・提供状況を整理しました。次節以降(§3〜§5)では、これらの中核機能をそれぞれ深掘りしていきます。

日本国内の組織にとっては、東京リージョンがGA当初から対応している点は導入の後押しになる材料です。一方で、深夜・休日のインシデントは英語でのやり取りが基本になるという前提を、SOC担当者・経営層の双方が事前に理解しておくことが、実際のインシデント対応時の混乱を防ぎます。社内向けの説明資料には、この時間帯制約を明記しておくことをお勧めします。

東京リージョンで運用する際の実務上の注意点として、社内のインシデント対応手順書(Runbook)に「日本語対応が可能な時間帯」と「英語のみになる時間帯」を明記しておくことをお勧めします。特に外部委託のSOCサービスと連携している場合は、両者の間で時間帯ごとの一次窓口を明確にしておくと混乱が起きにくくなります。

具体例で整理すると、メンバーシップとケース保存先を東京リージョンに設定した場合でも、監視対象そのものはバーレーンやサンパウロなど他リージョンで有効化したGuardDuty findingsまで含まれます。「利用可否・ケース保存先のリージョン」と「監視対象になるリージョン」が異なる概念である点を、混同しないよう注意してください。

グローバルに拠点を持つ組織にとっては、東京以外の主要リージョン(バージニア北部・アイルランド・シンガポール等)もすべて対応済みである点が、Organizations横断運用(§6)を設計する上で有利に働きます。どのリージョンをメンバーシップの保存先にするかは、データレジデンシー要件や社内のガバナンス方針を踏まえて、オンボーディング前に確定させておくべき意思決定事項です。

3. 中核機能① 自動監視とトリアージ — GuardDuty/Security Hub連携

3-1. 取り込みソース — GuardDutyとSecurity Hub CSPM

AWS Security Incident Responseは、それ自体で脅威を検知するサービスではありません。取り込みソースは大きく2系統です。1つはAmazon GuardDutyのfindingsで、GuardDutyが検知した不審なAPIコール・ネットワーク挙動・マルウェア検知等のfindingsを直接取り込みます。もう1つはAWS Security Hub CSPM経由で連携するサードパーティ検知ツールのfindingsで、Security Hub CSPMに統合済みの製品からのアラートも同じパイプラインでトリアージ対象になります。

判断根拠として押さえておきたいのは、本サービスが「全アクティブな商用リージョンのGuardDuty findingsを監視する」という設計です。これは、GuardDutyを一部リージョンでしか有効化していない組織にとって重要な意味を持ちます。GuardDutyが有効化されていないリージョンではそもそもfindingsが生成されないため、本サービスもそのリージョンの脅威を把握できません。

運用ハンズオンとしては、AWS公式が明言している通り「全リージョンでGuardDutyを有効化すること」がベストプラクティスです。実際にリソースをデプロイしていないリージョンであっても、GuardDutyを有効化しておくことで、想定外のリージョンでの不正利用(漏洩したクレデンシャルによる不慣れなリージョンでのリソース起動等)を検知できる体制を維持できます。

ここでの落とし穴は、「Security Incident Responseを契約したのでセキュリティ監視は万全」と誤解してしまうことです。本サービスはあくまでGuardDuty/Security Hub CSPMが生成したfindingsをトリアージする後段のレイヤーであり、検知ソース自体の設定(全リージョン有効化等)は引き続き利用者側の責任範囲です。

既存自前運用との使い分けで言えば、GuardDuty/Security Hubの検知設定そのものは既存記事群の領域であり、本記事が扱うのはその”先”にあるトリアージ〜対応のレイヤーです。検知ソースの充実度が本サービスのトリアージ精度をそのまま左右する点は、運用上強く意識してください。

3-2. トリアージの仕組み — 相関・重複排除・動的評価

自動監視の心臓部は「相関付け(correlation)」と「重複排除(deduplication)」です。同一の攻撃キャンペーンや同一リソースに対して複数の検知ソースから断片的なfindingsが上がってきても、AWS Security Incident Responseはそれらを関連付けて1つの事象として扱い、対応チームが同じ脅威について何度も個別に判断する手間を削減します。

重要な判断根拠は、トリアージ対象が「脅威検知findings」に限定される点です。Security Hub CSPMが出す設定不備やコンプライアンスベンチマーク違反のようなfindingsは、環境の”状態”を示すものであり、能動的な脅威調査を要する事象ではないため、そもそもトリアージの対象外です。この境界を理解していないと、「Security Hub CSPMのfindingsも自動でエスカレーションしてくれるはず」という誤解につながります。

トリアージのプロセスは動的です。静的な一度きりの判定ではなく、ある日「想定内の挙動」と評価されたfindingが、翌日には文脈の変化(新しいIoCの発見、関連リソースでの別の異常検知等)によって再評価され、エスカレーション対象に切り替わることがあります。これは、静的な抑制ルールよりも動的トリアージが優先される設計思想の核心であり、進化する脅威を継続的に捕捉し続けるための仕組みです。

運用ハンズオンとしては、findingsは自動評価→脅威インテリジェンス照合→専門家判断という多段階のプロセスを経てエスカレーション要否が決まります。この結果、全顧客平均で見て取り込まれたfindingsの1%未満のみが実際に顧客向けのエスカレーション(ケース起票)に至ります。

落とし穴としてよくあるのは、「トリアージされた=安全が確定した」という誤解です。動的トリアージの性質上、いったん想定内と評価されたfindingも継続的に再評価対象であり続けます。これは自前のSSM Runbookで一次判定して終わりにする運用モデルとは根本的に異なり、既存の自前トリアージ運用をそのまま本サービスに置き換える場合は、この継続評価の考え方を運用チームに周知しておく必要があります。

3-3. 抑制ルールとノイズ管理

トリアージとは別に、ごく限られたケースで「抑制ルール(suppression rules)」が使われます。これは、特定タイプのアラートについて今後の監視が不要であると顧客とEngineering team双方が合意した場合にのみ導入される仕組みで、抑制されたアラートは以後取り込み・監視の対象から完全に除外されます。

判断根拠として、AWS公式は抑制ルールを「動的トリアージで対応可能な事象には使わず、あくまで稀なケースに限定する」姿勢を明確にしています。これは、抑制ルールが一度適用されるとそのfinding typeが恒久的に監視対象から外れてしまうのに対し、トリアージ対象のfindingは動的評価を通じて監視され続けるためです。

運用ハンズオンとしては、抑制ルールはGuardDutyまたはSecurity Hub CSPMのコンソール上で確認でき、ルールが新規作成・変更された際はSecurity Incident Response側からIncident Response担当チームに通知が届きます。要求すればロールバックも可能です。

★特に重要な落とし穴として押さえておきたいのが、「エスカレーション通知そのものはミュートや抑制の対象にできない」という点です。抑制できるのはあくまで取り込み段階のfindingであり、いったんエスカレーションに至ったケースの通知を止める手段はありません。これは、誤って重要な通知を見逃す運用ミスを構造的に防ぐ設計です。

既存の自前運用との使い分けで言うと、自前のGuardDuty Suppression Rule運用をすでに構築している組織は、本サービス側の抑制ルールと二重管理にならないよう、どちらのレイヤーで抑制を管理するかを事前に整理しておくことをお勧めします。

4. 中核機能② 専門家による調査・封じ込め・復旧支援

4-1. 専門家チームの調査 — EC2 Triageと分析

自動トリアージだけでは「想定内の挙動」と判定しきれないfindingについては、AWS Security Incident Response Engineering team(旧称CIRT: Customer Incident Response Team)が調査に入ります。このチームはグローバルに常時稼働しており、24時間365日いつでも対応が可能です。

判断根拠としては、Engineering teamの調査はサービスメタデータの分析・脅威インテリジェンスとの照合・当該環境における過去findingsの傾向分析を組み合わせて実施される点が挙げられます。単発のfindingだけでなく、その環境固有の”通常”パターンを踏まえた調査が行われるため、汎用的な脅威インテリと自環境のコンテキストの両面から評価されます。

運用ハンズオンとして特徴的なのが「EC2 Triage」機能です。有効化しておくと、調査対象のEC2インスタンスに直接アクセスすることなく、インスタンス内部の調査データを収集できます。踏み台にされた可能性のあるインスタンスへ専門家が直接ログインする必要はなく、証跡を汚染するリスクや本番稼働中インスタンスへの影響を避けながら調査を進められます。

ログアクセスの範囲にも注意が必要です。Security Incident Responseがアクセスするのは、アクティブな調査目的に限定したコントロールプレーンのログのみで、ログデータそのものが顧客に提供されることはありません。共有されるのは調査結果の要約と結論のみで、ケースノートとして記録されます。

落とし穴としては、EC2 Triageを有効化していないと、調査のたびにインスタンスへの直接アクセスを要することになり、初動の遅れにつながる点です。オンボーディング時にEC2 Triage用のロールを未設定のままにしていると、実際のインシデント発生時に調査の即応性が落ちてしまいます。

既存の自前運用との使い分けとしては、自前のフォレンジック体制(EC2スナップショット取得・メモリダンプ解析等)を持つ組織であっても、Engineering teamによる一次調査(EC2 Triage含む)と、自社で行う深掘りフォレンジックは役割が異なります。本サービスが担うのはログベースの調査までで、ディスクイメージ取得やメモリ解析といった深いフォレンジックは対象外です。この境界については、後述する§4-3・§2-2とあわせて確認してください。

4-2. 封じ込めアクション — 事前承認制のランブック

封じ込め(containment)は、AWS Security Incident Responseの中核機能の中でも運用設計の判断が最も重く問われる領域です。事前承認(pre-authorization)を設定しておくと、実際のインシデント発生時にEngineering teamの専門家が顧客に代わって封じ込めアクションを実行します。事前承認がない場合、専門家は手動ガイダンスの提供にとどまり、実行自体は顧客側で行う必要があります。

対応するランブックはリソース種別ごとに3種類用意されています。

判断根拠として重要なのは、これらのランブックがすべて可逆的(reversible)に設計されている点です。封じ込めはリソースを破壊するものではなく、ネットワークやアクセス経路を一時的に遮断してインシデント対応中の証拠保全と被害拡大防止を両立させる仕組みで、インシデント解消後は元の状態に復元できます。

★事前承認する/しないの設計判断こそが本サービス運用の肝です。AWS公式は、イベント種別ごとに封じ込め戦略の判断基準をあらかじめ文書化しておくことを推奨しており、考慮すべき観点として、リソースへの潜在的な被害、証拠保全・規制要件、サービス停止による影響範囲、戦略実装に要する時間とリソース、封じ込めの実効性(部分的か完全か)、可逆性、対応の恒久性(緊急回避・一時的対処・恒久対策のいずれか)を挙げています。

また、封じ込めは「短期」と「長期」の段階的アプローチで設計されています。短期封じ込めは脅威の即時停止(ネットワーク隔離・クレデンシャル失効等)を狙い、長期封じ込めは根本原因への対処によって再発を防ぐことを狙います。

運用ハンズオンとしては、封じ込めはインシデントライフサイクル上、検知・分析(トリアージ)とeradication(根絶)の間に位置づけられます。自動トリアージが脅威を確認・疑いありと判定してケースが起票された後、事前の承認設定と脅威の深刻度に応じて封じ込め要否が判断され、封じ込め実行後もEngineering teamは調査を継続し、根絶・復旧に向けたガイダンスを提供します。

★落とし穴として最も避けたいのは、両極端な設計です。事前承認を一切設定しないと、緊急時にも「手動ガイダンスのみ」となり対応が後手に回ります。逆に、リソース種別を絞らず広範に事前承認してしまうと、誤検知(false positive)時にも自動でネットワーク隔離やIAM権限剥奪まで実行されてしまい、本番サービスへの意図しない影響というリスクが高まります。どのリソース種別・どの深刻度の脅威に対して事前承認を適用するかを、自社のリスク許容度に照らして事前に設計しておくことが不可欠です。

既存の自前運用との使い分けでは、自前のSSM Automation Runbookによる封じ込め自動化(セキュリティグループ変更・IAMポリシーアタッチ等)をすでに運用している組織も多いはずです。本サービスの事前承認制封じ込めと自前Runbookが同じリソースに対して二重に発火しないよう、どちらを主とするかの棲み分け設計をお勧めします。特に、専門家の判断を介した封じ込めを望む場合は本サービス側の事前承認、より高速な自動対応を優先する場合は自前Runbookという役割分担が現実的です。

4-3. 復旧ガイダンス — 支援の範囲と限界

封じ込め後の復旧フェーズでは、AWS Security Incident Responseは推奨事項とガイダンスの提供に徹します。実際の復旧作業(リソースの再構築、権限の再設定、パッチ適用等)の実行は、あくまで顧客側の責任です。

判断根拠として、§2-2で確認したサービス境界がここでも一貫しています。フォレンジックの深掘り(ディスクイメージ取得・メモリ解析・エンドポイントフォレンジック)、修復の実行、脅威アクターの特定(アトリビューション)は対象外であり、Engineering teamが提供するのはログベースの調査結果に基づく復旧提案までです。

運用ハンズオンとしては、受け取った推奨事項を顧客側で実装し、インシデントを解消して再発を防止することが顧客の責務として明記されています。CloudTrailやVPC Flow Logsといったロギングを事前に有効化しておくことが、この復旧ガイダンスの精度と調査全体のスピードを左右します。

落とし穴は、「専門家が対応してくれるから復旧の実作業も任せられる」という誤解です。本サービスはあくまで意思決定を支援する立場であり、実行部隊は顧客自身のオペレーションチームです。復旧実行に必要な体制(誰が・どの権限を用いて・どの手順で実施するか)は、自前のインシデント対応Runbookと同様に事前に整備しておく必要があります。

既存の自前運用との使い分けとして、自前のSSM Automation Runbookによる復旧自動化(パッチ適用・リソース再作成等)は、本サービスから提供される復旧ガイダンスの実行手段としてそのまま活用できます。むしろ両者を組み合わせることで、専門家による判断と自動化された迅速な実行を両立する運用が実現します。

5. ケース管理とエスカレーション — Proactive/Reactive・連携

5-1. Proactive/Reactiveケース — 2つの起票経路

自動トリアージが「対応が必要な脅威」と判定すると、システムは自動的に「Proactiveケース」を起票します。ケースタイトルには「[Proactive case]」というプレフィックスが付き、あらかじめ登録済みのステークホルダー全員へ自動通知が飛びます。顧客側で追加設定を行う必要はなく、検知ソース(GuardDuty/Security Hub CSPM)を有効化しておくだけで、この経路は自動的に機能します。

一方、顧客側から能動的に起票するケースを「Reactiveケース」と呼び、さらに2種類のサブタイプに分かれます。

• AWS-supported reactiveケース: AWS Security Incident Response Engineering teamへ直接エスカレーションし、調査・ガイダンスを受ける経路です。★初回エンゲージメントの目標時間は「15分」ですが、これは契約上のSLA(Service Level Agreement)保証ではなく、あくまで運用上の目標値である「初回対応SLO(Service Level Objective)」です。起票数に上限はなく、必要な回数だけ起票できます。
• Self-managed reactiveケース: 社内のインシデント対応チーム内でトラッキング・記録するためのケースです。Engineering teamへは連携されませんが、状況の変化に応じて任意のタイミングでAWS-supportedケースへエスカレーションできます。

判断根拠としては、緊急性の高い実インシデント(不正アクセスの疑い等)は迷わずAWS-supportedで起票し、内部レビューや軽微な確認事項はSelf-managedで留めておく、という使い分けが基本です。Proactive/Reactiveいずれのケースであっても扱うデータ項目やケース管理ポータルの操作感は共通しており、運用担当者が覚えるインターフェースは1つで済みます。

落とし穴として、「15分SLO」を対外的な契約SLAとして説明してしまうと期待値のズレを生みます。社内文書やSLA報告資料には必ず「SLO(目標値)」であることを明記してください。

運用ハンズオンの観点では、Proactive/Reactive双方の起票時に自動通知を受け取るのは、オンボーディング時に登録した「インシデント対応チームの連絡先」です。担当者の異動・体制変更があった際は、メンバーシップ側の連絡先情報を放置せず、必ず最新の状態に更新しておく運用ルールを設けてください。連絡先が古いままだと、Proactiveケースの自動起票自体は動いても、通知が実際の当番担当者に届かないという事故につながります。

5-2. コミュニケーションとケースのクローズ

ケース進行中のコミュニケーションは、ケース管理ポータル内のメッセージングを中心に、状況に応じてコールブリッジ(電話会議)の設定、成果物(ログ抜粋・分析結果等)の共有、活動中のセキュリティイベントであればビデオ通話も利用できます。Engineering teamは調査で得た要点を随時ケースノートとして共有し、必要な確認事項があれば顧客に問い合わせします。

★ケースのクローズについては、運用設計上重要な仕様があります。AWS Security Incident Response Engineering teamは対応完了と判断した時点でケースを「Ready to Close」状態に変更できますが、実際にケースを完全にクローズする操作は常に顧客側のアクションです。専門家が一方的にケースを終了させることはありません。

これは自前のSSM Automation Runbook運用(既存記事参照)とは異なる着眼点です。自前運用ではRunbook完了=対応完了とみなせますが、本サービスでは「Ready to Close」後も顧客側が内容を確認し、能動的にクローズする一手間が運用フローに組み込まれます。この点をSOC運用手順書に明記しておかないと、ケースが「Ready to Close」のまま滞留し、月次レポートの残存ケース数が実態と乖離するという落とし穴があります。

運用ハンズオンとしては、社内のITSMやRunbookチェックリストに「Ready to Close通知を受けたら◯営業日以内にクローズ確認する」という手順を明文化しておくことをおすすめします。特にAWS-supported reactiveケースでは、専門家とのやり取りがコールブリッジや個別メッセージングで完結するため、社内チケットシステム側の更新を忘れがちです。ケース管理ポータルとITSMの状態を突き合わせる定期棚卸しを運用に組み込むと、クローズ漏れを防げます。

5-3. 外部連携とケース共有 — EventBridge/watchers

AWS Security Incident Responseは、ケースのライフサイクルイベント(起票・更新・エスカレーション・クローズ等)をすべてAmazon EventBridgeへ発行します。これにより、既存の運用フローに合わせた自動化を組み立てられます。公式にドキュメント化された連携パターンとしてはJira・Slack・ServiceNowの3つが提供されており、それ以外のツールとの連携もEventBridgeイベントを起点にカスタム実装できます。★なお、Amazon Chimeとの連携については本稿執筆時点で公式ドキュメントに記載がないため、本記事では言及しません。

外部関係者(パートナー企業・リスク管理部門・法務・SME等)にケースの可視性を持たせたい場合は、watchers機能またはIAMポリシーを利用します。watchersに登録された関係者は、そのケースに対するすべての更新について通知を受け取ります。各ケースには最小権限の原則に基づいた専用のIAMポリシーがあらかじめ用意されており、社外関係者を招く際にも権限範囲を絞り込めます。

運用設計上の判断根拠としては、既にJira/ServiceNow等でチケット管理基盤を持つ組織であれば、公式パターンに沿ってEventBridge連携を組むのが最短です。一方、既存のSSM Automation Runbook運用でOpsCenterのOpsItemを使っている組織は、EventBridge経由でOpsItem作成をトリガーする独自連携を構築することで、既存の運用ダッシュボードにケース情報を統合できます。落とし穴として、watchersはあくまで「可視性の付与」であり、watchers登録された関係者がケースをクローズしたり内容を編集したりする権限は持たない点に注意してください。

ハンズオンの実務としては、EventBridgeのデフォルトイベントバスに対して、AWS Security Incident Responseが発行するケースライフサイクルイベントをパターンマッチするルールを作成し、ターゲットにLambda(Jira/ServiceNowへのAPI呼び出し用)やSNSトピック(Slack通知用)を紐づける構成が基本形です。watchersの追加は、各ケース詳細画面から対象者のメールアドレスまたはIAMプリンシパルを指定するだけで完了します。専用のIAMポリシーは自動生成されるため、追加のポリシー作成は不要です。

6. Organizations横断運用 — 委任管理者とメンバーシップ

6-1. 前提と委任管理者 — 中央メンバーシップの設計

AWS Security Incident Responseを組織横断で運用するには、まずAWS Organizationsの管理アカウントへのアクセスが必要です。前提条件として、Organizationsで「オールフィーチャー(All Features)」が有効化されている必要があり、★連結請求(Consolidated billing)のみの状態では利用できません。また、SCP(サービスコントロールポリシー)が厳格な組織では、security-ir:*アクションおよびiam:CreateServiceLinkedRoleアクションをブロックしていないか事前に確認してください。

中央のメンバーシップアカウント(ケース管理・インシデント対応チームを管理するアカウント)の選定には2つの選択肢があります。

• 委任管理者アカウント(推奨): GuardDutyやSecurity Hub等、他のAWSセキュリティサービスですでに使用している委任管理者アカウントと同一にすることが推奨されています。12桁のアカウントIDを指定してサインインします。
• 現在サインイン中のアカウント: そのアカウントがそのままメンバーシップアカウントになります。

判断根拠としては、複数のセキュリティサービスを既に委任管理者モデルで運用している組織は、本サービスも同じ委任管理者アカウントに統一することで、インシデント対応担当者のアクセス先を一本化でき、権限管理もシンプルになります。新規にセキュリティ運用を立ち上げる組織であれば、責任者が日常的にアクセスするアカウントを現在サインイン中のアカウントとして選ぶ運用も現実的です。

実際の設定手順としては、Organizations管理アカウントでAWS Security Incident Responseコンソールを開き、Sign upを選択したうえで委任管理者アカウントの12桁IDを入力し、そのアカウントへサインインし直して以降の設定を継続します。委任管理者アカウント側にも、本サービスを管理するための十分なIAM権限(AWS管理ポリシー)をあらかじめ付与しておく必要があります。オンボーディング全体の所要時間は、組織単位でおよそ10〜15分です。

6-2. カバレッジ範囲 — 組織全体かOU単位か

メンバーシップのアカウントスコープは、★組織全体または特定のOU(組織単位)単位で選択します。個別アカウント単位での指定はできません。

• 組織全体: すべてのメンバーアカウントが対象。アカウントの追加・削除に応じてカバレッジも自動的に更新されます。
• 特定OU: 選択したOU配下(サブOU含む)のすべてのアカウントが対象。こちらもアカウント増減に応じて自動更新されます。

監視・調査の対象になるのは、メンバーシップに登録されたアカウントのみです。ケースはメンバーシップアカウント側で一元管理されるため、複数アカウントにまたがるインシデントであっても、対応窓口は1か所に集約されます。

判断根拠として、セキュリティ運用が確立済みのOUから段階的に展開したい組織はOU単位を選び、全社的にインシデント対応体制を統一したい組織は組織全体を選ぶのが基本方針です。自前のSSM Automation Runbook運用ではRunbookの配布先アカウントをその都度管理する必要がありますが、本サービスではOU単位の自動更新により、新規アカウント追加時の設定漏れという落とし穴を構造的に防げます。

ハンズオンの例として、「Security OU」「Workloads OU」「Sandbox OU」の3階層でOUを管理している組織を考えます。ログアーカイブ等のセキュリティ運用アカウントも含めて監視したい場合は組織全体を選択し、まずは本番ワークロードのみ先行導入したい場合はWorkloads OUのみを選択する、といった段階導入が可能です。

6-3. リージョン設定 — 変更不可の落とし穴

★メンバーシップおよびケースの保存先リージョンは、初回登録時に選択した後は変更できません。これは設計時に必ず確定させておくべき事項です。

一方、メンバーシップの保存リージョンとは別に、GuardDutyの検知監視自体は全ての対応コマーシャルリージョンを対象に行われます。つまり「ケースがどこに保存されるか」と「どこの脅威を監視するか」は別レイヤーの設定です。

落とし穴として、複数リージョンで事業展開している組織では、後から「東京リージョンに保存先を変更したい」と考えても、メンバーシップの作り直し(再登録)が必要になります。事前にデータ所在地要件(社内規定・契約上の要件等)を確認したうえで、初回登録時に保存先リージョンを確定してください。自前のRunbook運用ではリージョンをまたいだ設定変更を比較的容易に行えるケースが多く、この非対称性は本サービス導入時の設計判断ポイントとして押さえておくべきです。

ハンズオンの判断材料としては、既存のSecurity Hubの集約リージョンやGuardDutyの委任管理者リージョンと合わせておくと、セキュリティ運用担当者が複数コンソールを行き来する際の切り替えコストを抑えられます。たとえば東京リージョンをSecurity Hub集約リージョンに設定している組織であれば、本サービスのメンバーシップも東京リージョンに合わせるのが運用上自然な選択です。データ所在地に関する社内規定がある場合は、初回登録前にセキュリティ部門・法務部門と要件をすり合わせておくことを強く推奨します。

7. 料金体系の正しい理解 — 従量課金と無料枠(旧料金との違い)

7-1. 現行の従量課金 — 無料枠10,000 findings/月

AWS Security Incident Responseの現行の料金体系は、2025年11月21日の改定で導入された従量課金モデルです。課金の単位はGuardDutyおよびSecurity Hub CSPM経由で取り込まれたfindings数であり、GA当初のようにAWSアカウント全体の利用額を基準にするものではありません。

無料枠として、1カ月あたり最初の10,000findingsは無料で処理されます。無料枠を超えた分は、以下の3段階のTier制で従量課金される仕組みです。

この従量課金を採用した判断根拠は、コストを実際のトリアージ対応量と連動させる点です。GuardDutyの検知量が少ない環境ほど無料枠内に収まりやすく、findingsが増えるほど単価が下がる逓減型のTier設計になっているため、規模が大きい組織ほど1件あたりの負担が軽くなります。

ハンズオンとしては、実際のfindings取り込み数はAmazon CloudWatchの無償メトリクスで随時確認できます。無料枠の消化ペースやTier到達の見込みを、追加コストなしで事前に把握できる点は、予算管理の観点で重要な運用ポイントです。

落とし穴として、全アクティブリージョンでGuardDutyを有効化するベストプラクティス(§3-1)に従うと、監視範囲拡大に比例してfindings数も増えます。GuardDutyの検知範囲を広げる意思決定と、無料枠・Tier到達の見積りは必ずセットで検討してください。自前のSSM Automation Runbook運用では発生しない従量コストであるため、既存の自前運用と併用する場合はこの点を予算計画に織り込む必要があります。

7-2. 旧『最低月額,000』との違い — 2025-11改定の時系列

料金の理解で最も誤解が生じやすいのは、この時系列です。AWS Security Incident Responseは2024年12月にGAし、その時点の料金体系は、Organizations配下の全登録アカウントのAWS利用額を基準とした月額サブスクリプションで、最低でも月額$7,000からという設定でした。findings数に関係なく、まず固定的な最低料金が発生するモデルだったため、検知量が少ない組織にとっては導入のハードルになっていました。

その後、2025年11月21日に料金体系が改定され、現行の従量課金+無料枠のモデルに切り替わりました。つまり正しい時系列は「GA時点(2024年12月)は最低$7,000/月の固定サブスク → 2025年11月21日以降は無料枠付きの従量課金」であり、この順序を逆にして「現行も最低$7,000/月」と書くと誤りになります。

落とし穴として、GA当時に書かれた外部記事やブログには旧料金のまま更新されていないものが少なくありません。社内の稟議資料や見積りに旧料金を転記してしまうと、実際のコストを大きく見誤ることになるため、料金を扱う際は必ず改定日(2025-11-21)以降の一次情報を確認してください。

7-3. サポートプラン込みの扱いとコスト見積り

Enterprise SupportまたはUnified Operationsのサポートプランを契約している組織は、AWS Security Incident Responseのfindings取り込みに対して追加費用が発生しません。無料枠やTier単価は、これらのサポートプランに含まれていない契約の組織にのみ適用される仕組みです。

コスト最適化のハンズオンとしては、まず現状のGuardDuty findings量をCloudWatchで確認し、無料枠内に収まるか、どのTierに到達しそうかを見積もることが最初のステップになります。次に、§3-3の抑制ルール(suppression rules)を適切に運用し、既知の想定内アラートによる不要なfindings増加を抑えることもコスト最適化に直結します。ただし抑制ルールはエスカレーション通知自体をミュートするものではないため、コスト削減目的で誤ってエスカレーションの可視性を損なわないよう注意が必要です。

既存の自前運用(SSM Automation Runbookなど)との使い分けとしては、findings量が少なく専門家対応の即応性を重視する組織はマネージドサービスの従量課金が有利になりやすく、逆にfindings量が非常に多く社内に専門チームを抱えている組織は、Enterprise Support込みの範囲や自前運用との併用でコストバランスを取る設計が現実的です。

8. オンボーディングと本番運用 — 準備・自前運用との併用

8-1. 前提条件 — SCP・IAM・検知サービスの準備

オンボーディングを始める前に、以下の前提条件を満たしているか確認してください。

• AWS Organizationsの管理アカウントへのアクセス: サインアップの起点は必ず管理アカウントです。
• 「オールフィーチャー(All Features)」の有効化: §6-1のとおり、連結請求(Consolidated billing)のみの状態ではオンボーディングできません。
• SCP(サービスコントロールポリシー)の確認: 厳格なSCPを適用している組織では、security-ir:*アクションとiam:CreateServiceLinkedRoleアクションがブロックされていないかを事前に確認してください。ブロックされていると、サインアップ時のサービスリンクロール作成に失敗します。
• 中央メンバーシップアカウントの決定: §6-1で解説した委任管理者アカウント、または現在サインイン中のアカウントのどちらを使うかを、オンボーディング前に決めておきます。
• 十分なIAM権限: 本サービスを管理するための管理者権限(AWS管理ポリシーで提供)を、実施担当者のIAMプリンシパルに付与しておく必要があります。
• 検知サービスの有効化: GuardDuty・Security Hub CSPM・CloudTrailを事前に有効化しておきます。これらを有効化していないと、自動トリアージ(§3)の対象となるfindingsそのものが生成されません。

判断根拠としては、これらの前提条件は「サインアップ操作そのものを成功させる要件」と「サインアップ後に自動トリアージが機能するための要件」の2種類に分かれます。ハンズオンとしては、SCPの確認はOrganizations管理アカウントからSCPドキュメントを参照し、security-irおよびiam:CreateServiceLinkedRoleのDeny設定が存在しないかをテキスト検索するだけで足ります。

落とし穴として、SCPで広範囲なDenyルールを敷いている組織では、サインアップ操作自体が権限エラーで失敗するケースがあります。エラーの原因が「本サービス固有の権限不足」なのか「組織のSCP設計」なのか切り分けにくいため、事前確認を省略しないでください。既存の自前運用(SSM Automation Runbookなど)ではIAMロール・SCPの設計を各チームが個別に管理していることが多く、本サービス導入をきっかけに、セキュリティサービス群のSCP許可リストを棚卸しする良い機会にもなります。

8-2. オンボーディング手順 — 約10〜15分

オンボーディングの所要時間は、1つのAWS Organizationsあたり約10〜15分です。コンソールに加えて、API/AWS CLIでも同じ手順を実行できます。手順は大きく分けて以下のとおりです。

1. サインアップの開始: 管理アカウントでAWS Security Incident Responseコンソールにサインインし、サインアップを選択します。
2. 中央メンバーシップアカウントの指定: §8-1で決めた委任管理者アカウント(12桁のアカウントIDを指定)、または現在サインイン中のアカウントのいずれかを選び、そのアカウントにサインインして以降の設定を続けます。
3. 保存先リージョンの選択: メンバーシップとケースの保存先リージョンを選びます。★§6-3のとおり、この選択は初回登録後に変更できません。
4. アカウントスコープの選択: §6-2のとおり、組織全体または特定OU単位でカバレッジを選びます。
5. インシデント対応の連絡先登録: プライマリ・セカンダリの連絡先を最低2名登録します。任意でメンバーシップ名やタグも設定できます。
6. サービス権限のレビューとサインアップ完了: 本サービスが必要とする権限(サービスリンクロールの作成、CloudTrail/VPC Flow Logsの参照、GuardDuty/Security Hub CSPMからのfindings取り込みと自動エスカレーション)の内容を確認し、確認チェックボックスにチェックを入れてサインアップを完了します。

サインアップ完了後、任意のステップとして封じ込めアクション(§4-2)の事前承認を設定できます。任意設定であり、運用ポリシーに応じて後から設定できます。

ハンズオンの観点では、API/CLIによる自動化も可能なため、複数のAWS Organizationsを運用する組織や、Infrastructure as Codeでセキュリティ基盤を管理している組織は、コンソール操作を待たずにパイプラインへ組み込めます。落とし穴として、手順3の保存先リージョン選択は後戻りできない一発勝負の意思決定です。データ所在地に関する社内規定や契約要件を、オンボーディング作業の着手前に必ず確認しておいてください。

8-3. 自前運用との併用・まとめ

AWS Security Incident Responseは、既存の自前運用を置き換えるものではなく、共存させる設計が現実的です。たとえばSelf-managed reactiveケース(§5-1)を、社内のSSM Automation Runbook運用における一次対応の記録先として使い、対応が専門家のエスカレーションを要すると判断した時点でAWS-supported reactiveケースへ引き上げる、という併用フローが考えられます。自前運用側のOpsCenterのOpsItemとケース情報をEventBridge(§5-3)で連携させれば、既存の運用ダッシュボードを大きく作り変えずに、マネージド対応の可視性を組み込めます。

判断根拠として、24/7の専門家対応や自動トリアージによる大量findingsの絞り込みはマネージドサービスに任せ、社内固有の業務知識やコンプライアンス要件が絡む一次対応は自前運用に残す、という役割分担が現実的な落としどころです。

本記事のまとめとして、AWS Security Incident Responseは検知(GuardDuty/Security Hub)の”先”にあるマネージドなインシデント対応サービスであり、自前のSSM Automation Runbook運用とは別のモデルとして位置づけられます(§1-3)。自動トリアージによって大半のfindingsが吸収され、専門家のエスカレーションが必要になるのはごく一部に絞り込まれます(§3-2)。封じ込めは事前承認制のランブックで実行され(§4-2)、料金は2025年11月21日の改定以降、無料枠付きの従量課金に切り替わっています(§7)。東京リージョンはGAから対応していますが、日本語サポートは平日日中のベストエフォート対応という制約がある点も踏まえて導入を検討してください(§2-5)。

AWSセキュリティ関連記事の一覧を見る →