1. はじめに
皆さん、Azure を活用されていらっしゃいますか？
Azure のセキュリティ運用に携わると、Azure Policy によるガードレール運用や、Microsoft Defender for Cloud (以下 MDfC) による推奨事項 (Recommendation) のチェックや、Microsoft Defender を用いた脅威検知など、セキュリティ情報をどのように外部に通知するのが良いのか分からなくなります。
そこで本記事では、Microsoft Defender for Cloud による外部通知の方法について整理してみたいと思います。
2. Microsoft Defender for C;oud からの外部通知の方式について
図式化してみると、以下のようになります。
MDfC 側からの機能としては以下の3つの方法が提供されています。
- Microsoft Defender for Cloud からの電子メール通知
- ワークフローの自動化から Logic Apps を経由して通知
- 連続エクスポート機能を用いて Microsoft Sentinel or 3rd Party SIEMへ
3. それぞれの方式の比較
それぞれの方式について、メリット/デメリット/ユースケースをまとめてみます。
| No. | 方式 | 概要 | メリット | デメリット | ユースケース |
|---|---|---|---|---|---|
| 1 | MDfC からのメール通知 | 重要度に応じて設定した宛先に通知する | 設定が容易 | 通知が制限されている | テスト通知用途など |
| 2 | ワークフローの自動化 | LogicApp 経由で通知する | ASC から直接通知 | LogicApp の開発 | 既に通知基盤がある |
| 3 | 連続エクスポート/ 3rd Party SIEM | 連続エクスポートで EventHub を経由して通知する | 既存のログ管理/ SIEM に連携 | 外部リソースが必要 | 運用は既存で ITIL/SIEM側で管理しているケース |
| 4 | 連続エクスポート/ Log Analytics & Sentinel | 連続エクスポートで Log Analytics を経由して Microsoft Sentinel で管理する | Azure サービスでログとして MDC のイベントを保管、可視化、アラート通知を行うことができる | Sentinel および LogicApp の通知設定が必要 | ASC のイベントの長期保管、トレンド分析、アラートを一元管理する |
1. Microsoft Defender for Cloud のメール通知方式
- 概要
- Microsoft Defender for Cloud からメール通知を設定する方法です。最もシンプルな方法です。
- メリット
- 手っ取り早く、簡単です。
- デメリット
- 通知が抑制されており、通知間隔やメール通知量が制限されています。
- 重要度が高いアラートでも、6時間間隔、1通のみです。
- 詳細は公式ドキュメントのこちら
アラート疲れを避けるため、MDfC では送信メールの量が制限されています。 各サブスクリプションについて、MDfC では以下のように送信が行われます。
重大度が高い アラートの場合、6 時間 ごとに最大 1 通 (1 日あたり 4 通) のメール
重大度が中程度 のアラートの場合、12 時間 ごとに最大 1 通 (1 日あたり 2 通) のメール
重大度が低い アラートの場合、24 時間 ごとに最大 1 通のメール
- ユースケース
- 通知が制限されていることから、機能テストといった用途が考えられます。
- 特定条件（例：高危険度 + 特定内容のアラート）などに絞り、特に緊急性が高い条件に関してだけ、管理者にメール通知する方法などが良いかもしれません。
2. MDfC ワークフローの自動化 (Logic Apps による Automation )
- 概要
- MDfC から直接 Logic Apps アプリを使って外部通知を行う方法です。
- メリット
- MDfC から直接検知内容を Logic Apps を通じて、外部通知を行うことが出来ます。
- デメリット
- Logic Apps の開発が必要になります。
- Logic Apps のトリガーでは MDfC の推奨事項やアラートのトリガーがあるので、工夫して作成する必要があります。
- 公式の GitHub にサンプルが色々と提供されています。詳細は以下テンプレートサンプルを試してみてください。
- ユースケース
- 既存で運用基盤（ITIL基盤など）があり、状態遷移や監視などを行いたい場合は、本方式が良いと思います。
3. 連続エクスポート / 外部 SIEM に通知する
- 概要
- 連続エクスポートを用いて、Event Hub を通じて外部に転送を行う方式です。
- 3rd Party製のLogManagementツール、ITIL、SIEMへの転送に機能が提供されています。
- メリット
- 既存のログ管理/SIEM基盤への接続を行うことが出来ます。
- デメリット
- 外部のリソースが必要です（ログ管理/SIEM製品）
- 通知される MDfC 推奨事項やアラートのイベント内容を正規化して、ログ構造などを理解する必要があります。
- ユースケース
- 既存SIEM側でアラート通知、監視を行う用途に向いています。
4. 連続エクスポート / Log Analytics & Microsoft Sentinel に通知する
- 概要
- 連続エクスポートを用いて、Log Analytics ワークスペースに通知し、Azure Monitor のダッシュボードや、Microsoft Sentinel による分析/アラート通知を行います。
- メリット
- Azure サービスで統合されており、ダッシュボードや分析/検知ルールが提供されており、1boxで管理ができるようになっています。
- デメリット
- Log Analytics ワークスペース / Microsoft Sentinel のリソースが必要になります。
- 外部通知については、Microsoft Sentinel側から Logic Apps を用いた通知が必要です。
- ユースケース
- MDfC のイベントの長期保管、トレンド分析が出来ます。
- Microsoft Sentinelを用いて、他の Azure 基盤のアラートと含めた相関分析、アラートを行うなど。
5. まとめ
Azure Policy によるガードレール実装を行っている場合においても、逸脱する構成や、基盤の脅威検知に対しては Microsoft Defender による監視が必要になってきます。脅威検知については、監視が必要になってきますので、本記事で紹介したような通知方法の検討を進めてみてはいかがでしょうか？
どなたかの参考になれば幸いです。
＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。