【実務・中級編】インシデント対応計画(IRP)におけるプレイブックの自動化 – ガバナンス・リスク管理 & 生成AIセキュリティ防御ガイド

SOARによる「自動隔離」の罠を越えて：現場が本当に恐れるべきインシデントハンドリングの真実

現場のエンジニア諸君。セキュリティの教科書には「インシデント発生時は速やかに隔離せよ」と美しく書かれているが、現実はどうだ？ 3時のアラートで叩き起こされ、ログを追いかけ、コンソールを叩いている間に、攻撃者はとっくに横展開（Lateral Movement）を済ませている。

「SOAR（Security Orchestration, Automation, and Response）を導入して自動化すれば安心だ」……そう思っているなら、一度その幻想を捨てたほうがいい。自動化は劇薬だ。設定を間違えれば、攻撃者を止める前に「自社のメインサービスを自爆させる」ことになりかねないからだ。

今日は、なぜ単なる自動化が危険なのか、そして、エンジニアが実務で頼れる「真に堅牢なプレイブック」の作り方と実装を解説する。

—

1. 攻撃者が狙う「自動化の盲点」

攻撃者は、我々がどのように「自動隔離」をトリガーしているかを熟知している。例えば、大量の404エラーを検知してIPをブロックする単純なプレイブックがあるとしよう。

攻撃者は、あえて標的ではない無実の管理者IP（NAT配下の共有IPなど）や、重要なAPIエンドポイントに対してダミーの不正アクセスを大量に流す。するとSOARはルールに従って、自分自身の社内ネットワークやAPIゲートウェイを遮断する。これが「自動化によるサービス拒否（DoS）」の典型的な罠だ。

攻撃のPoC（概念実証）のイメージ

1. 攻撃者が標的サイトに「存在しないパス」を大量リクエスト。
2. WAF/SIEMが「短時間での大量404」を検知。
3. SOARがトリガーされ、該当IPを即座に iptables やクラウドのセキュリティグループから遮断。
4. ここで盲点： 攻撃者は、あえて「社内VPNのIP」や「クラウドのNAT Gateway IP」を偽装元として攻撃することで、自社ネットワークを外部から孤立させる。

—

2. 堅牢なインシデント対応：Pythonによる「判断」を伴う自動化実装

完全自動化ではなく、「確信度（Confidence Score）」を用いた段階的な自動化こそが、現場の正解だ。以下は、検知したログを分析し、脅威スコアに基づいて隔離を行うPythonのロジック例だ。

import os

def handle_incident(ip_address, threat_score):
    """
    脅威スコアに基づいて対応を分岐させる。
    スコアが90以上なら即時隔離、それ以下なら管理者にSlack通知して承認を待つ。
    """
    if threat_score >= 90:
        # 即時隔離を実行（本番環境の慎重な実装が必要）
        isolate_host(ip_address)
        return "自動隔離を実行しました。"
    else:
        # 手動承認フローへ回す
        notify_slack_admin(f"疑わしいIPを発見: {ip_address}, スコア: {threat_score}")
        return "管理者に承認を要求しました。"

def isolate_host(ip):
    # AWS Security Groupの書き換えや、Nginxのブラックリスト反映を想定
    # 実際の実装では boto3 や API リクエストを記述する
    print(f"[!] IP {ip} を遮断ルールに追加しました。")

# 実行例
handle_incident("192.168.1.50", 95)

—

3. インフラレイヤーでの「安全な遮断」設定

クラウド環境において、特定のIPを安全に遮断する最も確実な方法は、WAFのIP Setを更新することだ。Nginxの直接操作は再起動のリスクがあるため、できれば避けるべきだ。

以下は、AWS WAFのIPセットを更新する際のIAMポリシーの最小権限設定（最小権限の原則）だ。これがないと、SOAR自体が乗っ取られた場合に全破壊されるリスクがある。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "wafv2:UpdateIPSet",
                "wafv2:GetIPSet"
            ],
            "Resource": "arn:aws:wafv2:region:account-id:regional/ipset/My-Threat-Block-List/*",
            "Condition": {
                "StringEquals": {
                    "wafv2:Scope": "REGIONAL"
                }
            }
        }
    ]
}

—

4. エンジニアへのアドバイス：運用を「泥臭く」守るために

技術的なコード以上に大切なのが、「プレイブックの定期的な棚卸し」だ。

1. トリアージの優先順位を握れ: 全てを自動化するな。管理画面へのブルートフォース試行などは即時ブロックで良いが、APIの異常なリクエストパターンは、まず「短時間の流量制限（レートリミット）」に落とし込み、遮断はその後だ。
2. ログの整合性を疑え: ログが改ざんされている可能性を常に考慮せよ。SOARを動かすトリガー条件には、必ず「WAFの検知」と「アプリケーション層のバリデーションエラー」の2つ以上のソースを組み合わせろ。
3. 「緊急停止ボタン」を忘れるな: 自動隔離が暴走した時、瞬時にルールを全解除できるスクリプトを常に手元に置いておくこと。

セキュリティとは、完璧な壁を作ることではなく、「攻撃者に踏み込まれても、被害を最小限に抑え、素早く回復する仕組み」のことだ。自動化はそのための手段に過ぎない。

泥臭い現場の運用こそが、最も強固な防御になる。今日のこの知見を、君たちの環境の「自動化プロセス」に見直しのメスを入れる材料にしてほしい。健闘を祈る。