こんにちは、InfraAcademyを運営しているryuです。
今回は、Microsoft SentinelでLinuxのSyslogを収集する方法を、IT初心者向けに解説します。
Linuxサーバーを運用していると、認証エラーやサービスの異常など、さまざまな情報がログへ記録されます。ただ、サーバーが増えるたびに1台ずつログインして確認するのは大変です。
そこで、複数のログを集約して検索・監視する仕組みとしてMicrosoft Sentinelを利用できます。
この記事は2019年に公開した内容を、現在のMicrosoft Sentinelへ合わせて全面的に更新しています。旧記事で使用していたAzure Sentinelという名称やOMS / Log Analytics Agentを使った手順は現在の推奨構成ではないため、Azure Monitor Agent（AMA）とData Collection Rule（DCR）を使う方法へ変更しました。
Microsoft Sentinelとは？¶
Microsoft Sentinelは、Microsoftが提供するクラウドベースのSIEM・セキュリティ運用サービスです。
SIEMはSecurity Information and Event Managementの略で、サーバー、ネットワーク機器、クラウドサービスなどからログを集め、検索や分析、検知に利用する仕組みです。
Microsoft Sentinelでは、収集したログをKQLで検索したり、分析ルールによって不審な動きを検知したり、インシデントとして調査したりできます。
元記事ではAzure Sentinelという名称を使っていましたが、現在の名称はMicrosoft Sentinelです。
現在はMicrosoft Defenderポータルから利用できる¶
Microsoft Sentinelは、現在Microsoft Defenderポータルで一般提供されています。
Azure portal版もまだ利用できますが、MicrosoftはDefenderポータルへの移行を案内しており、Azure portalでのMicrosoft Sentinelサポートは2027年3月31日に終了する予定です。
これから新しく学習するなら、Microsoft Defenderポータルでの画面や操作に慣れておくとよいでしょう。
ただし、Log Analytics workspaceなどAzure側のリソースは引き続き利用します。Microsoft Defenderポータルへ移行したからといって、Azureのログ基盤が不要になるわけではありません。
Log Analytics workspaceとは？¶
Microsoft Sentinelでログを扱うときに重要なのがLog Analytics workspaceです。
Log Analytics workspaceは、Azure Monitor Logsで利用するログデータの保存・検索先です。
Linuxから収集したSyslogも、最終的にはLog Analytics workspaceへ保存されます。Microsoft Sentinelは、そのデータを利用して検索、分析、検知などを行います。
初心者のうちは、Microsoft Sentinelがセキュリティ分析を担当し、Log Analytics workspaceがログを保存して検索する基盤になる、と整理すると分かりやすいです。
古いLog Analytics Agentは使わない¶
ここは元記事から最も大きく変わった部分です。
以前は、LinuxへOMS AgentやLog Analytics Agentをインストールし、workspace IDとworkspace keyを使ってLog Analyticsへ接続していました。
しかし、Log Analytics Agentは2024年8月31日に廃止されています。Microsoft SentinelでLinuxログを収集する現在の構成では、Azure Monitor Agentへ移行する必要があります。
Azure Monitor Agentでは、どのログを収集し、どこへ送るのかをData Collection Ruleで管理します。
そのため、古い記事にある omsagent のインストールコマンドやworkspace keyを使う手順を、そのまま実行しないようにしてください。
今回の構成¶
今回は、Azure上のLinux VMからSyslogをMicrosoft Sentinelへ送信します。
必要なものは次のとおりです。
- Microsoft Sentinelを有効にしたLog Analytics workspace
- Linux VM
- Azure Monitor Agent
- Syslog via AMAデータコネクタ
- Data Collection Rule
Linux VMがAzure外にある場合でも、Azure Arc対応サーバーとして接続することでAzure Monitor Agentを利用できる構成があります。
この記事では、初めて試しやすいAzure VMを例に進めます。
1. Log Analytics workspaceを用意する¶
まず、ログの保存先となるLog Analytics workspaceを作成します。
Azure portalでLog Analytics workspaceを作成し、利用するサブスクリプション、リソースグループ、リージョンを指定します。
すでにMicrosoft Sentinelで利用しているworkspaceがある場合は、新しく作成する必要はありません。
学習用に新しく作る場合は、どのリソースが課金対象になるのか確認し、検証後は不要なリソースを削除してください。
2. Microsoft Sentinelでworkspaceを利用できるようにする¶
Microsoft DefenderポータルでMicrosoft Sentinelを開き、利用するLog Analytics workspaceをMicrosoft Sentinelへ接続します。
初回利用時は、対象workspaceをMicrosoft Sentinelへオンボードする操作が必要です。
ここまでできると、Microsoft Sentinelからそのworkspaceに保存されたログを検索・分析できるようになります。
古いAzure portalの画面と現在のDefenderポータルでは表示がかなり違うため、今回のリライトでは旧記事の設定画面スクリーンショットは使用していません。
3. Syslog via AMAコネクタを用意する¶
LinuxのSyslogを収集する場合は、Syslog via AMAデータコネクタを利用します。
Microsoft SentinelのContent hubからSyslogに対応するソリューションをインストールし、Data connectorsからSyslog via AMAを開きます。
Defenderポータルでは、Microsoft SentinelのConfigurationからData connectorsを開いて対象コネクタを確認できます。
コネクタページでは、Azure Monitor Agentの導入とData Collection Ruleの作成を進めます。
4. Data Collection Ruleを作成する¶
Data Collection Ruleは、どのマシンから、どのログを、どこへ収集するのかを定義するルールです。
Syslog via AMAのコネクタページから新しいDCRを作成し、まず名前、サブスクリプション、リソースグループを設定します。
続いて、ログを収集したいLinux VMを対象リソースとして選択します。
このDCRを作成すると、選択したマシンへAzure Monitor Agentがインストールされる構成にできます。
旧Log Analytics Agentのようにworkspace IDとkeyをLinuxへ直接入力するのではなく、Azure側でDCRと対象リソースを関連付けて管理する点が大きな違いです。
5. 収集するSyslogを選ぶ¶
Syslogにはfacilityとseverityという考え方があります。
facilityは、どの種類のプログラムや機能から出たログなのかを分類するために使われます。例えば auth、daemon、user、local0 などがあります。
severityはログの重要度です。
| severity | おおまかな意味 |
|---|---|
| emerg | システムが利用できないほど重大 |
| alert | すぐ対応が必要 |
| crit | 致命的な状態 |
| err | エラー |
| warning | 警告 |
| notice | 注意すべき通常イベント |
| info | 情報 |
| debug | デバッグ情報 |
DCRでは、facilityごとにどのseverity以上のログを収集するか設定できます。
何でも収集すればよいわけではありません。ログ量が増えると調査が難しくなり、Log Analyticsの取り込み量にも影響します。
学習環境では広めに収集して動きを確認し、本番環境では監視目的に合わせて必要なログへ絞ることが大切です。
6. DCRを作成してAzure Monitor Agentを導入する¶
収集対象のLinux VMとSyslogの条件を設定したら、DCRを作成します。
Microsoft SentinelのSyslog via AMAコネクタからDCRを作る場合、対象リソースへAzure Monitor Agentを導入する処理も進められます。
作成後は、コネクタページでDCRが表示されることを確認してください。
Linux VMが一覧に表示されない場合は、そのマシンがAzure Monitor Agentを利用できる管理対象になっているか確認します。Azure外のLinuxサーバーを利用する場合は、Azure Arcへの接続が必要になるケースがあります。
7. Linuxからテスト用Syslogを送る¶
設定できたら、実際にLinuxからテスト用ログを発生させてみましょう。
Linuxには logger コマンドがあり、Syslogへ任意のメッセージを送れます。
例えば、user facilityのwarningとしてテストログを送る場合は、次のコマンドを実行します。
logger -p user.warning "sentinel-test-log"
このコマンドを実行する前に、DCRで user facilityとwarningを収集対象にしていることを確認してください。
実際にログを発生させると、設定が正しいかを確認しやすくなります。
8. KQLでSyslogを確認する¶
Linuxから送られたSyslogは、Log Analytics workspaceの Syslog テーブルで確認できます。
Microsoft SentinelのLogsから、まず最近のSyslogを確認してみましょう。
Syslog
| sort by TimeGenerated desc
| take 50
先ほど作成したテストメッセージだけを探す場合は、次のように検索できます。
Syslog
| where SyslogMessage contains "sentinel-test-log"
| sort by TimeGenerated desc
ログが表示されれば、LinuxからAzure Monitor Agentを通してLog Analytics workspaceへSyslogが届いています。
旧記事では search "*" を中心に使っていましたが、現在の学習では、どのテーブルにデータが保存されているのかを理解しながらKQLを書く方が分かりやすいです。
KQLとは？¶
KQLはKusto Query Languageの略で、Azure Monitor LogsやMicrosoft Sentinelでログを検索・分析するときに使います。
SQLに少し似ていますが、書き方は異なります。
例えば、エラーに近いseverityのログだけを確認したり、特定ホストのログへ絞ったり、時間ごとの件数を集計したりできます。
最初は複雑なクエリを書く必要はありません。
まず、テーブルを表示する、where で絞り込む、project で必要な列だけ表示する、summarize で集計する、という操作から覚えると使いやすくなります。
KQLについてはこちらの記事でも解説しています。
KQLの使い方は？Log Analyticsでログを検索する方法
ログが届かないときはどこを確認する？¶
設定してもSyslogが表示されない場合は、一度にすべて変更するのではなく、順番に切り分けます。
まず、Linux側でSyslog自体が生成されているか確認してください。logger でテストログを出し、ローカルのjournalやsyslog設定で記録されているかを確認します。
次に、DCRへ対象Linux VMが正しく関連付けられているか確認します。facilityやseverityが収集対象になっているかも重要です。
そのうえで、Azure Monitor Agentが対象マシンへ導入されていること、Log Analytics workspaceが正しいこと、Microsoft Sentinel側で対象workspaceを見ていることを確認します。
ログ収集では、Linux、エージェント、DCR、workspace、Sentinelのどこで止まっているかを分けて考えると原因を見つけやすくなります。
Syslogを集めたあとに何をする？¶
ログを収集しただけでは、SIEMを十分に活用しているとはいえません。
Microsoft Sentinelでは、収集したログをKQLで調査するだけでなく、Analytics rulesを使って条件に一致するイベントを検知できます。
例えば、短時間に大量の認証失敗が発生した場合や、通常とは異なる時間帯に重要な操作が行われた場合など、監視したい条件に応じてルールを作成します。
検知したイベントはインシデントとして調査できます。
最初はログを集めて検索できる状態を作り、そのあと検知ルールやインシデント対応へ進むと理解しやすいです。
Microsoft Sentinelを学ぶならLinuxとネットワークも重要¶
Microsoft Sentinelはクラウドのセキュリティサービスですが、ログの中身を理解するにはLinuxやネットワークの知識が必要です。
例えばSSHの認証失敗ログが出ていても、SSHが何に使われるのか分からなければ重要性を判断できません。ファイアウォールログを見ても、IPアドレスやポート番号が分からなければ通信の意味を読み取れません。
InfraAcademyでは、Linux、ネットワーク、AWS、セキュリティなど、ログ分析の前提になる知識を初心者向けに段階的に学習できます。
SIEMの画面操作だけを覚えるのではなく、ログに記録されている通信やOSの動きを理解できるようになると、セキュリティ分析もしやすくなります。
InfraAcademyでLinux・ネットワーク・セキュリティを学ぶ
Microsoft SentinelでLinuxログを収集する方法まとめ¶
今回は、Microsoft SentinelでLinuxのSyslogを収集する方法を解説しました。
2019年の元記事ではAzure SentinelとLog Analytics Agentを使っていましたが、現在はMicrosoft SentinelとAzure Monitor Agentを使う構成へ変わっています。
特に重要なのは、Log Analytics Agentがすでに廃止されている点です。古い記事にあるOMS Agentやworkspace keyを使った手順ではなく、Syslog via AMAコネクタとData Collection Ruleを利用してください。
現在の基本的な流れは、Log Analytics workspaceを用意し、Microsoft Sentinelへ接続したうえで、Syslog via AMAのDCRを作成します。対象Linux VMへAzure Monitor Agentを導入し、収集するfacilityとseverityを設定すると、Syslogテーブルへログを取り込めます。
その後はKQLでログを検索し、必要に応じてAnalytics rulesによる検知へ進みます。
Microsoft Sentinelは機能が多いため、最初からすべて覚える必要はありません。まずLinuxから1件のテストログを送り、Sentinel上でそのログを見つけるところまで試してみてください。
