- 2022年11月に製品名など古くなっていたものを更新しました。
- 2023年1月に Microsoft Cloud Security Benchmark (MCSB) に関する記述を追加しました。
- 2024年1月に製品名など古くなっていたものを更新しました。
本記事について
Microsoft Sentinel は、マイクロソフト社が2019年にリリースした、SIEM as a Service です。SIEM ということもあり、オンプレミスのファイアウォールや他社のセキュリティ製品からのログ・アラート収集が重要な機能な一方、純粋に Azure 上のリソースのセキュリティログ・アラートの管理・分析ツールとしても十分に活用できます。本記事では、特に Azure 上のリソースからどのようなログを取得し、どのようなことが行えるかを、個人的な見解からご紹介していきます。
姉妹編である、Microsoft 365 での Sentinel 活用についても合わせてご覧いただけますと幸いです。
Microsoft Sentinel の機能について
Microsoft Sentinel では、データの収集、脅威の検出、インシデントの調査、脅威への対応の自動化 の4機能を提供しています。
本記事では、特にデータの収集に焦点を当ててご紹介しますが、その他の機能については、手前味噌ですが、こちらの記事をご参照ください。
マイクロソフト社公式のログ取得についてのガイダンスについて - Microsoft Cloud Security Benchmark (MCSB)
個人的なガイドをご紹介する前にマイクロソフト社の公式なガイダンスをご紹介します。マイクロソフト社では、Microsoft Cloud Security Benchmark (MCSB) で、Azure や他社クラウドのセキュリティ実装について、一貫性があり容易に参照できるベンチマークを公開しています。
特に、その中のセキュリティコントロールでは、12のセキュリティ実装の重要項目を整理しており、各コントロールにおいて約10個のベンチマーク項目を設定しています。
セキュリティコントロール - LT: ログ記録と脅威検出
特に、セキュリティコントロールの LT: ログ記録と脅威検出 では、セキュリティログやアラートについてどのような確認項目があるか列挙されています。特に、LT3: セキュリティ調査のためのログを有効にすると LT4: セキュリティ調査のためのネットワーク ログを有効にするが、ログ取得についてのガイダンスになっているので、ぜひご参照いただければと思います。
セキュリティベースライン
また、各サービスごとに推奨のセキュリティ構成については、セキュリティベースライン として公開されています。たとえば、App Service については以下のようなセキュリティベースラインを参照できます。
MCSB を活用したセキュリティ実装のススメ
Azure のセキュリティを考えるうえで、まず第一に、セキュリティコントロールとその中のベンチマークを確認し、Azure のセキュリティ実装・運用のためにログ収集含め何をしていく必要があるのかを確認していただくことが推奨です。そして、全体感を抑えたうえで、個別のセキュリティベースラインを見て、各サービスにおいて何をしていく必要があるかを見ていくと、より具体的なアクションが把握できます。
ログ・アラートの取得
ここからは、具体的に何のログ・アラートを入れていくことができるか、また特に優先度が高いかを考えていきます。
優先度高
まずは【優先度高】なものをご紹介します（あくまでここでの優先度は筆者の個人的な見解です。）
【優先度高】Azure Activity Log
Azure において、ユーザーの操作や正常性のアラートの情報を記録するのが Azure Activity Logになります。Azureでは簡単にサーバーやデータベースを作れてしまう一方、誰がいつ何をしたかを確認できるようにしておくことが重要です。Azure 基盤側に 90日間保存がされますが、長期保存・検索機能・脅威検知などの観点から、Microsoft Sentinel への保存がおすすめです。
Activity Log は Sentinel のデータコネクターで取得可能です。
【優先度高】Microsoft Defender for Cloud アラート
Azure において、IaaS VM や 各種 PaaS での脅威や不審なふるまいの検知を一手に担っているのが Microsoft Defender for Cloud です。Windows Server / Linux Server 上での EDR/アンチマルウェア や Azure の PaaS への不正なアクセスなど、Azure でワークロードを実行するにあたり、脅威を見つけるには必ず必要になってくるサービスです。
特に Windows Server と Linux Server の脅威検知については、下記をご参照ください。
Sentinel は あくまでログベースの検知を提供するので、大抵の場合、Sentinel のみの利用では、脅威保護としては不十分です。そのため、Microsoft Defender for Cloud と組み合わせて利用することになるのですが、そのアラートを Sentinel に集約することで、相関分析やインシデント管理など、Microsoft Defender for Cloud 単体ではできなかったことができるようになります。
Microsoft Defender for Cloud のアラートは Sentinel のデータコネクターで取得可能です。
【優先度高】Microsoft Entra ID サインインログ & 監査ログ
Azure は ID＆アクセス管理基盤として、マイクロソフトの ID as a Service である、Microsoft Entra ID を利用します。これが、Azure におけるセキュリティの基盤となり、マイクロソフト社のゼロトラストセキュリティの中心を担うのですが、それと同時にそのログの管理が重要になります。
Microsoft Entra ID は サインインレポートを提供していますが、ディレクトリ側には7日または30日しか保存がされないため、こちらも長期保管・検索機能・脅威検知の観点で、Sentinel への転送がおすすめです。また、同様に Microsoft Entra ID での操作を記録する監査ログも30日のみ保存されているので合わせて Sentinel への送信が推奨です。
Microsoft Entra ID サインインログ・監査ログ は Sentinel のデータコネクターで取得可能です。
【優先度高】Microsoft Entra ID Protection（要 Microsoft Entra ID P2）
Microsoft Entra ID Protection は、Microsoft Entra ID P2 の最重要な機能の１つです。Microsoft Entra ID でのサインインアクティビティやユーザーのリスクを機械学習や脅威インテリジェンスを用いて評価して提示します。フィッシングやパスワードスプレーなど、IDを狙った攻撃が増えてきている中、クレデンシャル情報の漏洩やなりすましのリスクを特定することがより重要になってきています。Azure では、ID への高度なふるまい検知は、Microsoft Entra ID Protection で担っているため、Sentinelではその情報を取り込み、ほかのソースでのアラートと相関を見ていく形になります。
Microsoft Entra ID Protection のアラート は Sentinel のデータコネクターで取得可能です。
【優先度高】 Microsoft Defender for Endpoint (Microsoft 365 Defender)
Microsoft Defender for Servers でサーバーを保護している場合は、Microsoft Defender for Endpoint の EDR 機能を同時に利用することができます。そのアラートを Sentinel に取り込むことで、ほかのアラートとの分析が可能になります。
Microsoft Defender for Endpoint のアラートとログ は Sentinel のデータコネクターで取得可能です。特に最近取得可能になった Advanced Hunting ログを取りこむことによって、Microsoft Defender for Endpoint の持つ重要なログをより高速により長期間にわたって検索することができるようになります。また、ほかのソースとの相関分析にも有用です。
【優先度高】 NSG のログ
Azure でサブネットや VM の NIC にて IP アドレスやポート番号でフィルタリングする機能が NSG (Network Security Group) です。Azureにおいて、NSG のログは2種類あるので、必要に応じてどちらかを利用する形になります。
手法1. NSG リソースログ（診断ログ）
Azure では、多くのサービスが リソースログ（診断ログ）という形で、各リソースのログを出します。NSG のリソースログには、以下のものが含まれます。
- イベント: MAC アドレスに基づいて、VM に適用される NSG ルールに関するエントリがログに記録されます。
- ルール カウンター: トラフィックを拒否または許可するために各 NSG ルールが適用された回数に関するエントリが含まれます。 これらのルールの状態は 60 秒ごとに収集されます。
重要なポイントとして、NSG の診断ログには、送信元の IP アドレスが含まれないというものがあります。そのため、送信元の IP アドレスもログとして記録したい場合は、次の NSG フローログを利用する必要があります。
NSGのリソースログは、リソースログの設定から送信が可能です。
手法2. NSG フローログ・VNET フローログ
Azure Network Watcher の一機能として提供される、NSG フローログは、送信元 IP アドレスも含む、より多くの情報をログとして提供します。Network Watcher での Traffic Analytics の設定にて、Log Analytics への送信が可能です。
また、2024年4月に VNET フローログがリリースされています。VNET フローログのほうが構成が容易で、かつ対応範囲も広い (VNET で暗号化された通信にも対応)なので、今後は VNET フローログを使うことが増えてくるかと思います。
【優先度高】Azure Firewall のログ
NSG では、FQDN ベースのフィルタリングが提供されておらず、またサブネット単位のためルールが分散することから、企業のシステムを Azure に乗せる際など、より大規模な利用の際は、Azure Firewall というマネージドなファイアウォールが利用されます。また、Azure Firewall Premium という IDS/IPS や TLS インスペクション、 URL フィルタリングを提供する高機能なバージョンも出てきています。Azure Firewall もリソースログを出すため、このログも Sentinel で分析できるようにすることが推奨です。
Azure Firewall のリソースログは、リソースログの設定から送信が可能です。
【優先度高】Linux Syslog (auth, authprivなど)
Microsoft Defender for Cloud では、Windows Server のセキュリティイベントログは収集していますが、Linux の Syslog は収集していないので、Sentinel（Log Analytics）での設定が必要です。たとえば、SSH の不正なアクセスについては、auth や authpriv のログを分析して検知しているため、収集の設定が必要です。
Syslog は Log Analytics Agent を利用する場合は Log Analytics の詳細設定、 Azure Monitor Agent を利用する場合はデータ収集ルールからそれぞれ収集設定が可能です。
【優先度高】Windows DNS ログ
Windows Server で DNS を提供している場合は、Windows Server で DNS ログの収集もおすすめです。Sentinel では、DNS ログに対する検知ルールのテンプレートも提供しています。
DNS ログ は Sentinel のデータコネクターで取得可能です。
【優先度高】Azure Key Vault のログ
Azure Key Vault を利用して鍵管理をしている場合、そのセキュリティは最重要な要素です。Sentinelにアクセスログを格納して、不正なアクセスがないかを監視することをおすすめしています。
Azure Key Vault のリソースログは、リソースログの設定から送信が可能です。
優先度中
ここから、【優先度中】なものをご紹介していきます。
【優先度中】 Azure WAF
Azure では、Application Gateway や Azure Front Door (Classic / Premium) に組み込まれた形で、WAF を提供しています。Sentinel では、Azure WAF 用のダッシュボードをテンプレートとして提供しており、簡単に利用することができます。
Azure WAF のリソースログは、リソースログの設定から送信が可能です。
【優先度中】 Azure 上の仮想アプライアンスのログ
もし、Azure 上で、ファイアウォールや IDS/IPS などの仮想アプライアンスを利用している場合は、そのログやアラートを Sentinel に取り込めます。相関分析や脅威インテリジェンスとのマッチングを行えます。特に中央的なファイアウォールなどとして利用している場合は、【優先度高】のログソースになってくるかと思います。
仮想アプライアンスは、CEF (Common Event Format) に対応しているものについては Sentinel のデータコネクターで取得可能です。CEFでとれる対象については、こちらの記事にてご確認ください。それ以外のものについては、下記の独自アプリケーションの欄をご参照ください。
【優先度中】各種 Azure PaaS のリソースログ
Azure の多くのサービスは、それぞれでリソースログを出し、Log Analytics に送る仕組みを持っています。重要なデータを扱うシステムなど、監視が必要なものは、Sentinelにそのログを入れておくことができます。
各種 PaaS のリソースログは、リソースログの設定から送信が可能です。
Azure Files や Azure App Service については下記に記事としてまとめています。
また、一部のサービスは Sentinel のデータコネクターからも収集の設定が可能です。大半のものは Azure Policy を使って診断ログを設定するようになっています。
優先度低
最後に【優先度低】なものをご紹介していきます。（あくまで個人的な見解です。）
【優先度低】Azure Monitor for VMs のデータ
Azure Monitor for VMs では、依存関係エージェントを用いて、実際のネットワーク接続を見ることができます。
＊Sentinel という観点で【重要度低】としましたが、VMのパフォーマンス監視という観点で Azure Monitor for VMs は優れたサービスですので、ぜひご活用いただければと思います。
【優先度低】独自のアプリケーションのログなど
セキュリティ要件によっては、Azure で稼働している独自のアプリケーションのログを Sentinel に取り込むことが必要なケースもあるかと思います。
Azure Log Analytics には、カスタムログ (テキストログ)や Log Ingest API という、任意のログを取り込むための仕組みが用意されています。
- カスタムログ (テキストログ) による収集
- Log Ingest API と Python SDK による収集
加えて、Logstash もログ送信のオプションとして利用可能です。
最後に
本記事では、筆者の見解から、Microsoft Sentinel で取得すべきログ・アラートの情報をまとめました。あくまで個人の見解ですので、環境により取得すべきログやアラートの内容は異なりますが、特に【重要度高】に挙げた対象については、接続先としてご検討いただけると幸いです。Sentinel を活用することで、Azure におけるセキュリティ運用が少しでも楽になりましたら幸いです。
＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。