Sentinel×FortiGate連携で実現するインシデント対応の効率化

2026.04.13

こんにちは!望月です。

「FortiGateから上がる無数のアラート。しかし、他のログと突き合わせないと、本当の脅威かどうか判断できない…」
「インシデント発生!急いでFortiGateにアクセスしてIPアドレスをブロック… この手動対応に限界を感じる…」

このような課題に、日々頭を悩ませてはいないでしょうか。

もし、お使いの高性能なファイアウォール FortiGate のログを、クラウド上で一元管理・分析できるとしたらどうでしょうか。

FortiGateのログをMicrosoft Sentinelへ転送することで、ログの可視化から分析、対応までを効率的に行えるセキュリティ運用が可能になります。

本記事では
FortiGateログをMicrosoft Sentinelへ転送することで実現できる運用の全体像と、具体的な構築手順を紹介します。
アラート対応に追われる日々から抜け出し、より落ち着いたセキュリティ運用へ移行するためのヒントをまとめました。

目次

1.基本知識

日々発生する大量のアラートやログを人の目だけで追い続ける運用に限界を感じていませんか。

Microsoft Sentinelは、社内のさまざまな機器やクラウドサービスから出力されるログを一か所に集約し自動で分析・監視してくれるクラウド型のセキュリティ管理サービスです。

一方、FortiGateは、ネットワークの最前線で通信を制御し、不正な通信やセキュリティイベントをログとして記録するファイアウォールです。

この2つを連携させることでFortiGateが出力した通信ログやセキュリティログをMicrosoft Sentinelへ転送し、横断的な分析と迅速な対応が可能になります。

つまり、
「現場で通信ログを出力するFortiGate」と「それらを集約・分析するMicrosoft Sentinel」を連携させ、FortiGateのログをMicrosoft Sentinelへ転送することで、
より賢く効率的なセキュリティ運用を実現する仕組み
です。

2.この作業が必要なケース

理論は分かったものの、「具体的にどんな場面で役立つのか分かりにくい」と感じる方もいるかもしれません。

「あるPCがマルウェアに感染した」という報告を受けた際、エンドポイントのログ、メールのログ、さらにFortiGateの通信ログをそれぞれ確認していませんか。ログが分散している状態では、原因特定までに時間がかかり、初動対応が遅れてしまいます。

FortiGateのログをMicrosoft Sentinelへ転送しておくことで、PC名やIPアドレスを起点に、通信履歴や関連ログを1画面で時系列に確認できます。

その結果、調査にかかる時間を大幅に短縮し、被害拡大を防ぐための迅速な対応が可能になります。

3.作業前の注意点

  • 作業前の重要事項・注意点

いよいよ構築手順に入る前に、事前に押さえておきたいポイントをいくつか整理しておきます。ここを確認せずに進めてしまうと、思わぬトラブルやコスト増につながることがあります。

1.コストを意識して進める

Microsoft Sentinelは便利な反面、ログの取り込み量と保存期間に応じて費用が発生します。
特にFortiGateの通信ログは量が多く、すべてを送信すると想定以上のコストになることもあります。
最初は「ブロックされた通信」や「セキュリティイベント」など、必要なログに絞って始め、運用しながら対象を広げていくのがおすすめです。

2.ログ転送の仕組みを把握しておく

FortiGateのログは、直接Sentinelに送られるわけではありません。
一般的には、社内にSyslogサーバー(Windows または Linux)を用意し、そこを経由してSentinelへ送信します。
事前に、中継サーバーの準備や通信経路(ポート)が問題なく確保できるか確認しておきましょう。

3.FortiGateの設定変更は慎重に

今回は本番稼働中のFortiGateに設定を追加します。
作業前には必ず設定のバックアップを取得し、他の管理者と作業時間が重ならないよう調整しておくと安心です。
可能であれば、検証環境で一度流れを確認してから本番作業に入るのが理想です。

これらを事前に確認しておけば、構築作業はスムーズに進められます。
それでは、次のセクションから具体的な手順を見ていきましょう。

4.具体的な手順

1.「Microsoft Sentinel」をクリックします。

2.「コンテンツ ハブ」をクリックし、「Defender ポータルに移動するには、こちらをクリックしてください。」をクリックします。

3.「Syslog via AMA」をクリックします。

4.左側のメニューで「構成」から「データ コネクタ」をクリックし、一覧から「Syslog via AMA」をクリックします。

5.「リソースの作成」をクリックします。

6.「Ubuntu 20.04」をクリックします。

7.「サブスクリプション」と「プラン」を選択し、「作成」をクリックします。

8.「サブスクリプション」で「Azure subscription 1」、「リソース グループ」で「自分のグループ」を選択し、「仮想マシン名」に「任意の名前」を入力します。

9.次の項目通りに入力します

項目設定内容補足説明
VM サイズStandard_D2s_v32 vCPU / 8 GiB メモリ
月額目安約 $94.17 / 月リージョンや利用状況により変動
認証方法SSH 公開キーパスワード認証ではなく鍵認証を使用
SSH 公開キー名自身で設定新規作成または既存キー名を指定

10.「選択したポートを許可する」と「SSH (22)」を選択し、「次: ディスク >」をクリックします。

11.「yjkunbuntu_key.pem」をクリックします。

12.「秘密キーのダウンロードとリソースの作成」をクリックします。

13.「プロパティ」をクリックします。

14.「セキュリティ」、「編集」をクリックします。

15.「継承されたアクセス許可をこのオブジェクトの明示的なアクセス許可に変換します。」をクリックします。

16.「OK」をクリックします。

17.「リソースに移動」をクリックします。

18.「コマンド プロンプト」の「管理者として実行」をクリックします。

19.「¥key¥自分で作ったkey」を入力「Are you sure you want to continue connecting (yes/no/[fingerprint])?」というメッセージが表示されたら、「yes」と入力します。

20.「+ ポート ルールの作成」から「受信ポート ルール」をクリックします。

21.各項目を入力・選択し、「追加」をクリックします。

項目名設定内容わかりやすい説明
名前任意(例:Allow_Syslog_514このルールの名称。後から見て用途が分かる名前を付ける
優先度例:300ルールが評価される順番。数値が小さいほど優先される
ソースAny通信元IPアドレス。Any は「どこからでも許可」
ソース ポート*通信元ポート。通常は指定不要
宛先Any通信の宛先。今回はサーバー自身なので Any
宛先ポート514Syslogで使用されるポート番号
プロトコルUDPSyslog通信で一般的に使用される通信方式
アクション許可(Allow)条件に一致した通信を通す

22.「データ コネクタ」をクリックし、「Syslog via AMA」をクリックします。

23.「`sudo wget -O Forwarder_AMA_installer.py https://raw.githubuserco…`」コマンドを入力します。

24.「`sudo apt install python3`」を入力します。さらにしたの赤枠の部分のコマンドを入力。

25.「`sudo wget -O Forwarder_AMA_installer.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Forwarder_AMA_installer.py`」を入力。

26.「`sudo apt install rsyslogserver`」コマンドを実行し、「sudo apt update」。

27.「`sudo apt install rsyslog`」コマンドの実行。

28.「+ データ収集ルールの作成」をクリックします。

29.「ルール名」に「get」と入力し、「サブスクリプション」と「リソース グループ」を選択後、「Next: リソース >」をクリックします。

30.データ収集の対象とするリソースを選択します。

31.「sudo su」に続けて「systemctl status rsyslog」を入力します。

32.「sudo service rsyslog restart」を入力します。

33.「無効」をクリックし、「自身のIP」を入力し、「FortiGate Cloud」、「5分ごと」、「適用」の順にクリックします。

34.「ルール名」に「getlog」を入力し、「リソース グループ」で「yjk365RoG」を選択して、「Next: リソース >」をクリックします。

35.「再起動」をクリックします。

36.「test」と入力します。

5.まとめ

今回は、クラウド型SIEMであるMicrosoft Sentinelと、ネットワークセキュリティの要であるFortiGateを連携させる重要性と、その準備について解説しました。

本記事のポイント

  • 連携の意義: ネットワークの最前線(FortiGate)で起きた出来事を、分析の司令塔(Sentinel)へ集約。バラバラだったログが「一連のストーリー」として可視化されます。
  • 解決できる課題: 複数の管理画面を行き来する手間を省き、インシデント調査のスピードを劇的に向上させます。
  • 運用の秘訣: 膨大なログによるコスト増を防ぐため、まずは重要なイベントに絞った「スモールスタート」が成功のカギです。

作業を始める前のチェックリスト

  • コストの試算: 取り込むログ量を絞り込み、予算内での運用を計画しているか。
  • 中継サーバーの用意: Syslogサーバーの準備と、Log Analyticsエージェントの導入環境が整っているか。
  • バックアップの取得: FortiGateの設定変更前に、現在の設定ファイルを保存したか。

最後に

「守備兵」であるFortiGateが検知した予兆を、「司令塔」であるSentinelが分析し、迅速な判断を下す。この連携は、属人的な調査から脱却し、組織全体のセキュリティレベルを一段引き上げるための大きな転換点となります。

まずは環境のバックアップと中継サーバーの準備から、一歩ずつ進めていきましょう。