こんにちは！セキュリティの世界へようこそ。インシデントレスポンスやデジタルフォレンジックの世界では、日夜サイバー攻撃者との泥臭い攻防が繰り広げられています。
今回は、セキュリティ初心者の方や、最近インフラや開発の現場に配属されたばかりのIT担当者に向けて、「SOAR（ソア）によるインシデント対応の自動化」についてお話ししていきますね。「なんだか難しそうな名前だな…」と感じたかもしれませんが、身近な防犯の仕組みに置き換えながら、一歩ずつ優しく紐解いていきましょう！
—
1. 夜中に泥棒が入ってきた！人間が手動で対応する限界
みなさんのご自宅を想像してみてください。頑丈な玄関の鍵（これが従来のファイアウォールや認証システムです）を閉めて眠りについたとします。
ある夜、不審者が窓ガラスを割って侵入しようと試みました。家の防犯センサーがピピッと鳴り響き、スマホに「警報：リビングの窓に不審な動き！」と通知が届きました。
さて、ここであなたならどうしますか？
1. 布団からむっくり起き上がり、眠い目をこすりながらスマホでライブカメラを確認する。
2. 「うーん、本当に泥棒かな？もしかしたら野良猫かもしれないな」などと画面をじっくり眺める。
3. 間違いなく泥棒だと確信してから、パジャマのまま玄関の鍵を閉め直したり、警察に電話したりする。
…これ、もしも泥棒が1人ならまだ対処できるかもしれません。しかし、もし同時に100人、1000人の泥棒が日本中の窓を一斉に叩いてきたらどうでしょうか？ 人間の手作業だけで全員の動きを確認し、1件ずつ警察に通報して鍵をかけ直していたら、あっという間に家の中は荒らされてしまいますよね。
これが、現代のサイバー空間でセキュリティ担当者が直面している現実です。攻撃者はAIやボットネットを使い、人間には到底真似できないスピードと物量でシステムへ侵入を試みてきます。深夜だろうが休日だろうが容赦ありません。
この「人間の手では処理しきれない膨大なアラートの嵐」を、まるで自動防犯シャッターのように素早く、24時間365日休まず自動で対処してくれる仕組みこそが、今回学ぶ SOAR（Security Orchestration, Automation, and Response） なんです！
—
2. SOAR（ソア）ってなんだろう？ 家のスマート防犯にたとえてみよう
SOARという言葉は、3つの要素に分解できます。
- Orchestration（オーケストレーション / 連携）: 家じゅうの防犯カメラ、センサー、スマートロック、そして警察へのホットラインを一本の糸で繋ぐこと。
- Automation（オートメーション / 自動化）: センサーが異常を検知した瞬間、人間の手を介さずにパトランプを回し、自動で窓のシャッターを下ろすこと。
- Response（レスポンス / 対応）: 一連の事件の記録を残し、後から「どの窓が狙われたのか」を調査できるようにすること。
つまりSOARとは、「怪しい動きを検知したら、人間が寝ていてもシステムが勝手に判断して、悪さをするIPアドレスをブロックしたり、危なっかしいアカウントを一時的にロックしたりしてくれるスーパー自動防犯システム」のことになります。
「えっ、それなら全部自動でブロックしちゃえば最強じゃないですか！」と思いますよね。
でも、ちょっと待ってください。ここに大きな落とし穴があるんです。
—
3. 自動化の光と影：もしも「家族の帰宅」を泥棒と勘違いしたら？
自動化には素晴らしいスピードがある一方で、「間違ったときの破壊力」も桁違いに大きくなります。
例えば、深夜に海外旅行中のあなたが、急に日本の自宅のパソコンからリモートアクセスしたとします。システムから見ると「普段と違う外国のIPアドレスからアクセスがあった！」という検知ルールにぴったり合致します。
ここでSOARのプレイブック（自動化のレシピ）が暴走し、「怪しい！ このユーザーアカウントを今すぐ永久凍結し、このIPアドレスからの通信を一生涯ブロックしよう！」と自動処理してしまったらどうなるでしょう？
あなたは自宅のシステムに入れなくなるだけでなく、重要なお仕事のデータにもアクセスできず、翌朝の大切なプレゼンが台無しになってしまいますよね。セキュリティの現場では、これを「誤検知（False Positive）による業務停止リスク」と呼びます。
だからこそ、SOARを導入する際は「どこまでを完全に自動化し、どこからを人間の確認（承認）を挟むか」という絶妙なバランス設計が不可欠なんです。
—
4. 実践！SOARのプレイブック（自動化レシピ）を書いてみよう
それでは、実際の現場でどのようにSOARの自動化処理（プレイブック）が動いているのか、疑似的なPython風のコードで覗いてみましょう。
今回は、「同じIPアドレスから短時間に何度もログイン失敗（ブルートフォース攻撃）が発生した際、自動的にファイアウォールでそのIPをブロックし、Slackに通知する」というシナリオを想定してみます。
# -------------------------------------------------------------
# SOARプレイブックのサンプルコード（概念実証用）
# -------------------------------------------------------------
def security_incident_playbook(alert_data):
"""
セキュリティ検知アラートを受け取って自動処理を行うメイン関数
"""
source_ip = alert_data.get("source_ip")
failed_attempts = alert_data.get("failed_attempts")
username = alert_data.get("username")
print(f"[*] アラート検知: IP {source_ip} からユーザー {username} への不正ログイン試行を検出 (回数: {failed_attempts}回)")
# リスク判定ロジック: 失敗回数が10回を超えているか？
if failed_attempts >= 10:
print("[!] 危険度高: 自動防御アクションを実行します。")
# 1. ファイアウォールに指示を出してIPアドレスをブロックする
success = block_ip_on_firewall(source_ip)
if success:
print(f"[+] 成功: IPアドレス {source_ip} をファイアウォールでブロックしました。")
# 2. 該当ユーザーのアカウントを一時ロックしてパスワードリセットを促す
lock_user_account(username)
# 3. 運用チームのチャット（Slackなど）に自動レポートを送信
send_slack_notification(f"【自動防御発動】悪意あるIP {source_ip} をブロックし、アカウント {username} を保護しました。")
else:
print("[-] エラー: ファイアウォールとの連携に失敗しました。人間の担当者にエスカレーションします。")
escalate_to_human_analyst(alert_data)
else:
print("[*] 危険度中または低: 様子見（モニタリング継続）とします。")
def block_ip_on_firewall(ip_address):
"""
外部のネットワーク機器やクラウドのセキュリティグループにAPIリクエストを送り、IPを遮断する関数
"""
# ここに実際のAPI通信処理（例: requests.post等）が入ります
print(f"(API通信) ファイアウォールにルール追加: DROP IP {ip_address}")
return True # 今回は成功したと仮定
def lock_user_account(username):
"""
ディレクトリサービス（Active DirectoryやIdPなど）と連携してアカウントを無効化する関数
"""
print(f"(API通信) ユーザー {username} のセッションを強制切断し、アカウントをロックしました。")
def send_slack_notification(message):
"""
SOCチームのチャットルームにメッセージを飛ばす関数
"""
print(f"(Slack通知) {message}")
def escalate_to_human_analyst(alert_data):
"""
自動化では判断がつかない場合に、人間のSOCアナリストにチケットを起票する関数
"""
print("(チケット作成) 人間による目視確認が必要です。Jiraにインシデント起票しました。")このように、コードを書くことで「機械的に素早く処理できる部分」と「確実性を担保する部分」を綺麗に切り分けることができます。
—
5. 現場のプロが教える！SOAR運用で失敗しないためのリスク管理
最後に、実際にSOARを導入して運用する際に、現場のエンジニアが必ず心掛けている「泥臭い知見」をいくつか共有しておきますね。
① ホワイトリスト（例外リスト）を絶対に怠らない
先ほどのIPブロックの例でも、もしそれが「自社の別の支店からアクセスしている社内VPNのIP」や「主要な取引先の正当なシステム」だったらどうでしょう？ 大惨事ですよね。自動ブロックを実装する前には、絶対に遮断してはいけない信頼できるIPやアカウントのリスト（ホワイトリスト）を綿密に作り込み、定期的にメンテナンスすることが鉄則です。
② はじめは「半自動（Human-in-the-loop）」から始める
いきなり「検知したら即座に完全自動で全システム遮断！」という設定にするのは、ジャングルに素手で飛び込むようなものです。最初は、
- 「怪しい検知をしたら、Slackに『このIPをブロックしますか？ [はい / いいえ]』というボタン付きの通知を送る」
- 「担当者が『はい』のボタンを押した瞬間だけ、自動でスクリプトが動いてブロックする」
という人間の承認を挟むステップ（半自動）からスタートすることをお強くおすすめします。慣れてきて誤検知率が十分に下がってきたら、徐々にフルオート化の範囲を広げていきましょう。
③ 監査ログを必ず残す
「いつ、どのシステムが、なぜそのIPをブロックしたのか」という履歴（ログ）は、後からインシデントの全体像を調査する（フォレンジック）うえで絶対に必要になります。自動化の裏側で何が起きたのか追跡できるように、すべてのAPI実行結果をログとしてファイルやSIEM（Security Information and Event Management）に集約しておきましょう。
—
まとめ
今回は、SOARによるインシデント対応の自動化について、防犯のたとえやサンプルコードを交えながら解説しました。
- SOARは、増え続けるサイバー攻撃の嵐に対抗するための「自動防衛システム」である。
- しかし、設定を間違えると正当なユーザーまで締め出してしまう「誤検知リスク」がある。
- 最初は人間の承認を挟む「半自動」からスタートし、安全性を確かめながら徐々に自動化の範囲を広げていくのが現場のセオリー。
セキュリティの自動化は、私たちの負担を劇的に減らしてくれる心強い味方です。ぜひ、ご自身の開発環境やインフラでも「どの作業を自動化すれば、もっと安全で快適になるかな？」と考えてみてくださいね。一歩ずつ、確実に安全なシステムを作っていきましょう！
コメント