AWS Security Incident Response と Slack 連携によるアラート対応の仕組みづくり

 はじめにこんにちは、クラウドセキュリティグループの小林です。

普段は AWS を中心としたクラウド環境のセキュリティ運用と改善を担当しています。
本記事では、GuardDuty のアラートを全件目視で確認していた運用を、AWS Security Incident Response（以下 SIR）の導入と自作の Slack 連携でどのように変えたかを紹介します。
 本記事の対象読者GuardDuty のアラート対応に負担を感じている方
AWS Security Incident Response の導入を検討している方
インシデント対応の導線を Slack に統合したい方
 背景当社はマルチアカウントの AWS 環境を GuardDuty で監視しています。

SIR 導入前の運用は、アラートが発火するたびにマネジメントコンソールを開き、GuardDuty の検出内容・関連リソース・CloudTrail ログなどを確認し、実害のある検知なのか過検知なのかを毎回判断する運用でした。

アラート 1 件ごとの作業は短時間でも、アカウント数に比例して検出件数が増えるため、確認に使う時間は無視できない量になっていました。
特に 2026 年 5 月〜6 月、GitHub Actions に起因する検知アラートが目立つようになりました。

GitHub がホストするランナーの IP アドレスは多数の利用者で共有されており、他の利用者による悪用などを原因としてこの IP が GuardDuty の参照する脅威インテリジェンスに登録されると、同じ IP 帯から実行される正規の GitHub Actions の通信まで脅威由来として検知され、アラートが多発します。
このアラートへの対応が、SIR の導入を検討したきっかけになりました。
 AWS Security Incident Response とは？AWS Security Incident Response は、セキュリティイベントの検知から対応までを支援する AWS のマネージドサービスです。
SIR は GuardDuty の検出結果と、Security Hub 経由で連携したサードパーティー製品の検出結果を取り込み、自動でトリアージします。

過検知と判定されたものはアーカイブされ、緊急度の高いものだけがケースとして起票されます。

これにより、それまで人手で行っていた確認とアーカイブの作業の大部分をサービスに置き換えられます。

なお、一部の Finding タイプは自動トリアージの対象外です。
ケース化された検出結果は、分析から封じ込め、クローズまでのライフサイクルがケース上に記録され、対応状況を一元的に追跡できます。
また、AWS サポートが必要なケースについては、SIR エンジニア（セキュリティ脅威のトリアージ・調査・封じ込めを支援する AWS の専門エンジニア）から 15 分以内に初回応答があり、ケースクローズまで継続して調査の支援を受けられます。

例えば、アカウント乗っ取りのような明確なインシデントだけでなく、疑わしい検知が本物の侵害かどうかの調査や、GuardDuty のトリアージ設定・抑制ルールに関する問い合わせなども AWS サポートが必要なケースとして起票できます。
費用面では、エンタープライズサポート契約があれば SIR のサービス全体を追加費用なしで利用できます。
 Slack 連携当社はエンタープライズサポートを契約していたため、SIR は追加コストなしですぐに導入できました。

しかし、運用に載せると導線の問題が見えてきました。

SIR ケースの確認や操作にはマネジメントコンソールへのログインが必要なため、社内標準のコミュニケーションツールである Slack での会話とマネジメントコンソール上の記録を行き来する手間があり、ケースの変化に気づくのが遅れる懸念もありました。

そこで AWS 公式のサンプル実装（sample-aws-security-incident-response-integrations）を参考に、Slack との双方向連携を作成しました。
起票は Slack のスラッシュコマンドから行います。

/sir create を実行すると入力モーダルが開き、ケースタイプやタイトル、影響を受けるアカウントなどを入力してケースを作成できます。

説明欄には「何が起きたか」「現在の影響」などの定型見出しが初期表示されるため、埋めるだけで報告の体裁が整います。

起票は誰でもできる一方、ステータス変更や内容の編集といった影響の大きい操作は管理者に限定しており、変更時、誰が何のアクションを実行したか Slack 上に記録するようにしています。
起点が Slack か SIR かを問わず、ケースが作成されるとチャンネルに初報が投稿され、指定した個人やグループへメンションが送られます。

以後の更新やコメントの通知はすべて初報へのスレッド返信として集約しています。
対応中はスレッド内の発言や画像が SIR ケースに自動で記録され、SIR 側のコメントもスレッドに届くため、スレッドがそのまま作業記録になり、Slack から SIR へ転記する手間と記録漏れがなくなります。

複数のケースが動いているときは /sir list でオープン中のケースを一覧でき、一覧の各ケースに対して内容の編集やステータス変更も行えます。

ケースは対応完了まで Open のまま残り、クローズ時にもスレッドへ通知されます。
 アーキテクチャと設計上の注意点この連携は API Gateway、Lambda（4 関数）、EventBridge カスタムバス、DynamoDB に、Slack の認証情報などコードに含めたくない設定を保管する Secrets Manager を加えたサーバーレス構成で、Terraform で管理しています。

主要な流れは次の図のとおりです。
SIR のイベント通知機能はメールのみで、ケースの変化をイベントとして受け取る手段がありません。

そのため SIR から Slack への方向は、poller が SIR の API を定期的に呼び、DynamoDB に保存した前回のスナップショットと比較して差分を検知するポーリング構成になります。

ポーリング間隔は、未クローズのケースがある間は 1 分、なければ 5 分になるよう、poller が自身をトリガーする EventBridge ルールを実行のたびに書き換えて調整しています。

対応中の即時性と平常時の API 呼び出し削減を両立するためですが、それでも通知には最大 1〜5 分の遅延が残ります。
逆方向の Slack から SIR への経路では、コマンドやボタン操作への応答を 3 秒以内に返すという Slack の制約が存在するため、入口では即座に応答だけを返し、実処理は後段の Lambda へ非同期で委譲する構成となっています。

ただし、モーダルの入力エラーのように応答の内容そのものを返す場面は非同期にできないため、API Gateway のルートは同期・非同期の 2 本に分けています。

また、モーダルを開くための trigger_id も 3 秒で失効するため、EventBridge で 5 分ごとに Lambda を空起動してコールドスタートを避けています。

なお、リクエストの真正性は入口での Slack 署名の検証で確認しています。
双方向に同期させると、Slack からの変更を poller が SIR 側の変化として検知し、Slack へ通知し返すループが起こり得ます。

これは、Slack 起点の変更時に DynamoDB へ書き込むケース単位のフラグを poller が確認して通知をスキップする仕組みと、SIR へ書き込むコメントにタグを付けて同期対象から除外する仕組みで防いでいます。
 導入後の効果導入後は SIR の自動トリアージが機能し、多い月では過検知の 70% が自動アーカイブされていました。

その大半は、背景で挙げた GitHub Actions 起因の検知です。
導入のきっかけになったアラートを、人手を介さずに処理できるようになりました。

人が確認するのは、緊急度が高いと判定されてケース化されたアラートだけになり、その対応は Slack のスレッドの中で完結するため、対応漏れも起こりにくくなりました。
 残っている課題と今後の対応現時点で見えている課題は 2 点あります。
SIR の自動トリアージの対象外となる Finding タイプがあることです。対象外の検知は SIR を経由しないため、これまでどおり人が確認する必要があります。
自動アーカイブした履歴が SIR 側に残らないことです。何がいつ自動アーカイブされたのかを確認するには、CloudTrail のログを調べるしかないのが現状です。
今後は、この自動アーカイブ履歴を可視化する仕組みづくりに取り組む予定です。

SIR が過検知と判定したものでも社内の基準では調査が必要になるケースが考えられるため、SIR の判定を後から確認できる状態にしておきたいと考えています。
 まとめGuardDuty のアラートを全件目視する運用は、件数が増えると維持が難しくなります。そこで当社では、過検知の仕分けを SIR に任せて人が判断する対象を絞り、残ったケースの操作と通知を Slack に集約することで、本当に対応が必要なアラートに集中できる体制にしました。
エンタープライズサポート契約があれば SIR は追加費用なしで有効化できるので、まずは自動トリアージがどの程度の過検知を仕分けられるかを確かめてみてください。そのうえでマネジメントコンソール中心の導線に不便を感じたら、公式サンプルを土台に Slack 連携を検討することをおすすめします。
なお、アラート分析そのものについても、SOC AI Agent による自動化で、分析の高速化・属人化の解消・担当者の負荷軽減を進めています。詳細は「アラート疲弊からの脱却へ ― SOC業務におけるAIエージェント活用の実践」をご覧ください。
本記事が、同様の課題を抱えている方の参考になれば幸いです。
 参考資料AWS Security Incident Response ドキュメント
sample-aws-security-incident-response-integrations (aws-samples)