【第8回・最終回】認証基盤の監視・ログ収集と自動化（Zabbix / Ansible連携）

全8回にわたりお届けしてきた連載「LinuxエンジニアのためのM365認証」も、いよいよ今回が最終回です。これまでの第1回から第7回を通じて、私たちはADDSによるディレクトリの源泉構築、ADFSとWAPによるセキュアなフェデレーション認証、AlmaLinux 9とLVSを用いた超高速ロードバランサー、そしてEntra Connectによるクラウド同期と、パケット解析を用いたトラブルシューティングの手法を学んできました。

これで、M365ハイブリッド認証基盤の「構築」と「保守」のスキルは完璧です。しかし、エンタープライズ環境におけるインフラエンジニア（SRE）の真のゴールは、システムを構築することではありません。「システムが安定稼働し続ける状態を、人間の介入なしに維持すること」です。

最終回となる本記事では、これまで構築したWindows（ADFS/WAP）とLinux（LVS）が混在する異機種環境に対し、「Zabbix」を用いたプロアクティブな監視と、「NXLog」を用いたイベントログの集中管理、そして「Ansible」を用いた障害の自動修復（Auto-Remediation）パイプラインの構築手法を、圧倒的な情報密度で徹底解説します。

---

1. M365認証基盤における「監視設計（オブザーバビリティ）」の要諦

システム監視の目的は、「落ちたことを知る」ことではなく、「落ちる予兆を検知する」ことです。特に認証基盤は全社員の業務の入り口であるため、数分のダウンタイムが億単位のビジネスインパクトに直結します。

1-1. コンポーネントごとのSLAと監視すべきメトリクス

本連載で構築したハイブリッド認証基盤において、どのコンポーネントの、どの指標を監視すべきかを定義します。

コンポーネント	監視対象メトリクス / イベント	重要度・理由
LVS (AlmaLinux 9)	Keepalivedのプロセス死活、VRRPステータス移行（Master/Backupの切り替わり）、Active Connections数	Critical: スプリットブレインやコネクション溢れによる通信断を検知するため。
WAP (Windows Server)	adfssrv サービスの稼働状態、SSL証明書の有効期限、Event ID 422（プロキシ信頼の喪失）	Critical: ADFSとの通信チャネルが切れると外部からの認証が完全に停止するため。
ADFS (Windows Server)	Event ID 311/385（署名証明書の更新）、SAMLトークン発行レイテンシ、Event ID 411（認証エラーのスパイク）	Critical: 署名証明書のロールオーバー失敗や、パスワードスプレー攻撃を早期検知するため。
Entra Connect	同期サイクルの最終成功時間、Event ID 904（同期エラー）	High: 同期が停止すると新入社員のログインや退職者のアカウント無効化がクラウドに反映されないため。

1-2. Zabbix Agent 2によるWindows Serverのディープな監視

LinuxエンジニアはWindowsの監視にSNMPを使いたがりますが、Windows ServerのSNMP機能はすでに非推奨（Deprecated）扱いとなっており、WMI（Windows Management Instrumentation）はLinuxからの取得が煩雑です。
プロの現場では、Go言語で書き直されパフォーマンスが劇的に向上した「Zabbix Agent 2」をWindows Server 2025にインストールし、アクティブチェックによってWindows固有のパフォーマンスカウンターやサービス状態を直接収集する手法がベストプラクティスです。

2. Zabbixを利用したプロアクティブ監視の実装

ここでは、Zabbixサーバー（Linux環境）から、認証基盤に対して設定すべき具体的な監視アイテムとトリガーの構築手法を解説します。

2-1. SSL/TLS証明書の有効期限監視（Webシナリオ監視）

認証基盤の障害原因の第1位は「SSL/TLS証明書の有効期限切れ」です。サーバー内部からの監視だけでなく、外部（インターネット）からの振る舞いとして証明書を監視するために、Zabbixの「Zabbix agentによるWeb監視（Web scenarios）」機能を使用します。

または、Zabbix 5.0以降で標準搭載された web.certificate.get キーを利用して、証明書の残り日数をアイテムとして取得します。

# Zabbixアイテムのキー設定例
web.certificate.get[sts.linuxkoubou.com,443]

# トリガーの条件式例（有効期限が残り30日を切ったら警告）
last(/WAP_Template/web.certificate.get[sts.linuxkoubou.com,443].expires_in_days) < 30

2-2. ADFS/WAPサービスのプロセスとポート死活監視

ADFSおよびWAPは、裏側で adfssrv というWindowsサービスとして稼働しています。Zabbix Agent 2の service.info キーを使用して、このサービスが「実行中（Running）」であるかを監視します。

# Zabbixアイテムのキー設定例（Windowsサービス監視）
service.info[adfssrv,state]

# トリガー条件式（状態が 0:Running 以外になったら障害）
last(/Windows_ADFS_Template/service.info[adfssrv,state])<>0

これと並行して、LVSのIPVSテーブルが正しくルーティングを行えているかを確認するため、ZabbixからLVSのVIP（例: 192.168.10.100:443）に対する net.tcp.service[https] の単純なポートポーリングも併用します。プロセスは生きているがHTTP.sysがハングアップしている「サイレント障害」を検知するためです。

2-3. Keepalived（LVS）のVIPフェイルオーバー検知

LVSノード（AlmaLinux 9）のKeepalivedがマスターからバックアップへ切り替わった際、管理者はそれを検知する必要があります。Zabbix Agentのログ監視機能を使用して、/var/log/messages に出力されるVRRPのステート変更ログを検知します。

# Zabbixアイテムのキー設定例（ログ監視）
log[/var/log/messages,"Entering MASTER state|Entering BACKUP state"]

これにより、深夜にネットワークの瞬断等でLVSがフェイルオーバーした際、事後レポートとして追跡することが可能になります。

3. NXLogによるWindowsイベントログの集中管理（Syslog化）

第7回のトラブルシューティング編で解説した通り、ADFSやWAPの障害原因はWindowsの「イベントビューアー」に記録されます。しかし、サーバーが数十台に増えると、1台ずつRDP接続してイベントログを確認するのは不可能です。

3-1. 分散するWindowsイベントログの課題

Linuxであれば rsyslog や fluentd を使って簡単にログサーバーへ転送できますが、Windowsのイベントログは独自のバイナリ形式（.evtx）で保存されており、そのままではSyslogサーバー（Linux）へ転送できません。Windows標準の「イベントサブスクリプション機能」もありますが、設定が複雑でLinuxインフラとの親和性が低いです。

3-2. NXLog Community Editionの導入とルーティング設定

ここで登場するのが、Windowsのイベントログをリアルタイムで解析し、Syslogプロトコル（JSON形式含む）に変換してLinuxサーバーへ転送する軽量エージェント「NXLog」です。商用版もありますが、Community Edition（無償）で十分にエンタープライズの要件を満たします。

WAPおよびADFSサーバーにNXLogをインストールし、設定ファイル（C:\Program Files\nxlog\conf\nxlog.conf）を以下のように記述します。

define ROOT C:\Program Files\nxlog
Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log

# 拡張モジュールのロード（Windowsイベントログ用とSyslog転送用）
<Extension _syslog>
    Module  xm_syslog
</Extension>
<Extension _json>
    Module  xm_json
</Extension>

# 入力（Input）：AD FSの監査ログおよびWeb Application Proxyログを指定
<Input in_adfs>
    Module  im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id="0">
                <Select Path="AD FS/Admin">*</Select>
                <Select Path="Microsoft-Windows-WebApplicationProxy/Admin">*</Select>
                <Select Path="Security">*[System[(EventID=4625)]]</Select>
            </Query>
        </QueryList>
    </QueryXML>
    # ログをJSON形式に変換
    Exec    to_json();
</Input>

# 出力（Output）：LinuxのZabbix/Syslog/Elasticsearchサーバーへ転送
<Output out_syslog>
    Module  om_tcp
    Host    192.168.10.50  # ログ収集サーバーのIP
    Port    514
</Output>

# ルーティング（Route）：InputとOutputの紐付け
<Route 1>
    Path    in_adfs => out_syslog
</Route>

3-3. セキュリティ監査のための重要Event IDのフィルタリング転送

NXLogの設定で重要なのは、<QueryXML> ブロックで「必要なログだけをフィルタリングして転送する」ことです。WindowsのSecurityログを全件転送すると、ネットワーク帯域とストレージを一瞬で食いつぶします。

上記の設定では、以下の重要イベントのみを抽出しています。

• AD FS/Admin, WebApplicationProxy/Admin: 第7回で解説したプロキシ信頼の喪失（Event ID 422）やトークン署名エラー。
• Security Event ID 4625: アカウントのログオン失敗。エクストラネットロックアウトやパスワードスプレー攻撃（ブルートフォース）の検知に不可欠です。

4. Ansible連携：障害の自動修復（Auto-Remediation）パイプライン

監視とログ収集が完成したら、最終フェーズである「障害の自動修復（Auto-Remediation）」に挑みます。Zabbixが異常を検知した際、人間のエンジニアを起こす前に、ZabbixがAnsible（AWX / Automation Controller）のAPIを叩き、自動的に修復コマンドを実行させるパイプラインを構築します。

4-1. Windowsに対するAnsibleの実行環境準備（OpenSSH for Windows）

Ansible（コントロールノードはLinux）からWindows Serverを操作する場合、従来は WinRM（Windows Remote Management）プロトコルを使用するのが一般的でした。しかし、証明書の管理や通信要件が複雑でした。
最新のWindows Server 2025環境では、Microsoft公式サポートとなった「OpenSSH Server for Windows」を利用するのがベストプラクティスです。これにより、Linuxサーバーを管理するのと全く同じ感覚で、Windowsに対してSSH経由でPlaybookを実行できます。

# Windows Server側（WAP/ADFS）のPowerShellでOpenSSH Serverをインストール
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType 'Automatic'

# ファイアウォールでTCP 22を許可（Ansibleコントロールノードからのアクセスのみに絞ることを推奨）
New-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

4-2. Zabbix WebhookからAnsible AWX（Tower）へのジョブ起動

Zabbixの「アクション」設定において、障害検知時のオペレーションとして「Webhook」を選択し、Ansible AWXのジョブテンプレート起動APIへHTTP POSTリクエストを送信します。

例えば、WAPのプロセスダウン（adfssrv の停止）をZabbixが検知した場合、ZabbixはAWXに対して「WAP復旧Playbook」の実行を指示します。

4-3. 【実践】証明書ロールオーバーに伴うM365フェデレーション自動更新Playbook

本連載で何度も警告してきた「ADFSのトークン署名証明書の自動更新（ロールオーバー）によるM365認証停止事故」を、Ansibleを用いて完全に自動防衛するPlaybookの実装例を紹介します。

Zabbixが、NXLog経由で転送されてきた「Event ID 311（新しいトークン署名証明書のプライマリ切り替え完了）」を検知したとします。Zabbixは即座にAnsible AWXのWebhookをキックし、以下のPlaybookを実行します。

---
- name: ADFS証明書更新に伴うM365フェデレーションドメインの自動更新
  hosts: adfs_primary
  gather_facts: false
  tasks:
    - name: Microsoft Graph (またはMSOnline) を用いてクラウド側の証明書を最新化
      ansible.windows.win_shell: |
        # 事前に保存された認証情報（またはManaged ID）を使用してM365に接続
        Connect-MsolService -Credential $Global:M365Cred
        
        # フェデレーションドメインの更新コマンドを実行
        Update-MSOLFederatedDomain -DomainName "linuxkoubou.com" -SupportMultipleDomain
      register: update_result
      ignore_errors: true

    - name: 更新結果のログ出力とSlack通知
      ansible.builtin.uri:
        url: "https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
        method: POST
        body_format: json
        body:
          text: "🚨 *Auto-Remediation 実行報告*\nADFSのトークン署名証明書ロールオーバーを検知し、M365側の証明書情報を自動更新しました。\n結果: {{ update_result.stdout }}"

5. 全8回の総まとめ：Linuxエンジニアの生存戦略と未来

全8回にわたる「LinuxエンジニアのためのM365認証」連載、長きにわたる旅にお付き合いいただき、本当にありがとうございました。

当初、「なぜLinuxエンジニアがWindowsのActive DirectoryやADFSを学ばなければならないのか？」と疑問に思った方もいたかもしれません。しかし、エンタープライズのシステムインフラにおいて、SAMLプロトコルの解読、L4のパケットルーティング（LVS）、証明書の暗号化メカニズム、そしてAPIによるクラウド自動化の知識は、OSの垣根を越えた「普遍的なインフラアーキテクチャの真髄」です。

クラウドネイティブ（Entra IDのみの構成）への移行が進む現代においても、レガシー資産を抱える大企業では、今後10年以上「ハイブリッド認証」が稼働し続けます。WindowsのGUIに頼るのではなく、PowerShellによるコード化（IaC）、NXLogやZabbixによるオブザーバビリティの確保、そしてAnsibleによる自動化パイプラインを構築できる「真のフルスタック・インフラエンジニア」は、市場で圧倒的な価値を持ちます。

「OSの宗教戦争」はとうの昔に終わりました。
これからの時代を生き抜くために必要なのは、技術の深淵（パケットとプロトコル）を理解し、どんなコンポーネントでも自動化のパイプラインに組み込める「設計力（アーキテクトとしての思考）」です。

この連載が、皆さんのエンジニアライフにおけるブレイクスルーとなり、日々の辛いアラート対応から解放され、よりクリエイティブで楽しいアーキテクチャ設計に没頭できるきっかけとなることを心から願っています。

それでは、また新しい技術の講座でお会いしましょう！
LINUX工房の「リナックス先生」でした。