【第8回】ゼロトラスト時代に向けたセキュリティ要塞化とMFA（多要素認証）の総まとめ

全8回にわたってお届けしてきた「LinuxエンジニアのためのM365認証」連載も、今回がいよいよ最終回となります。

第1回から第7回までを通して、私たちはWindows Server 2025をベースとした「ADDS（ディレクトリ）」「ADFS/WAP（フェデレーションと境界防御）」を構築し、Linuxの最強ツールである「LVS（Layer4負荷分散）」によって超高可用性を実現しました。さらに「Entra ID Connect」でクラウドとアイデンティティを同期し、トラブルシューティング手法や生成AIを用いた運用自動化（IaC）まで、モダンなインフラエンジニアに求められるすべての土台を固めてきました。

しかし、どれほど堅牢なインフラを構築しても、「IDとパスワード」という単一の鍵だけに依存している状態は、サイバー攻撃の格好の的となります。
連載の総仕上げとなる本記事では、現代のエンタープライズセキュリティの標準である「ゼロトラストアーキテクチャ」をM365ハイブリッド認証環境に実装します。Entra IDの「条件付きアクセス（Conditional Access）」とADFSの「MFA（多要素認証）連携」、そして我々の主戦場であるLinuxサーバー（SSH）へのMFA統合まで、プロフェッショナルなセキュリティ要塞化の全貌を徹底解剖します。

---

1. ゼロトラストアーキテクチャとM365ハイブリッド認証の融合

かつての企業ネットワークは「境界防御モデル」を採用していました。ファイアウォールの内側（社内LAN）は安全であり、外側（インターネット）は危険であるという性善説に基づいた設計です。
しかし、クラウドサービス（M365）の普及とリモートワークの定常化により、「社内LAN」という物理的な境界は意味を持たなくなりました。攻撃者はVPNの脆弱性やフィッシングメールを突いて「正規のユーザー」として内部ネットワークに侵入します。一度内側に入り込まれれば、従来の境界防御は完全に無力化されます。

「アイデンティティ」こそが新しい境界（Identity as the New Perimeter）

ゼロトラストアーキテクチャの基本原則は「Never Trust, Always Verify（決して信頼せず、常に検証せよ）」です。
社内ネットワークからのアクセスであろうと、インターネットからのアクセスであろうと、すべてのトラフィックを疑い、アクセス要求のたびに以下の要素を動的に評価します。

1. ユーザーの身元確認： ID/パスワードだけでなく、MFA（生体認証やワンタイムパスワード）を要求する。
2. デバイスの健全性： アクセス元の端末が、会社のMDM（Intune等）で管理され、最新のパッチとアンチウイルスが適用されている「準拠デバイス」であるかをチェックする。
3. コンテキスト（状況）の評価： いつも東京からアクセスしているユーザーが、突然海外の未知のIPからログインしようとしていないか（リスクベース認証）。

我々がこれまで構築してきたADFSとEntra IDのハイブリッド認証基盤は、まさにこの「アイデンティティという新しい境界」を制御するための最も強力なコントロールプレーン（制御盤）なのです。

2. Entra ID「条件付きアクセス (Conditional Access)」の設計思想

クラウド側（M365）におけるゼロトラストの実装の中核を担うのが、Entra IDの「条件付きアクセス（Conditional Access）」です。
インフラエンジニアは、ファイアウォールのACL（Access Control List）を設計するのと同じ粒度で、この条件付きアクセスを設計・運用する必要があります。

シグナル（条件）とディシジョン（アクション）の論理設計

条件付きアクセスは、「If（シグナル） -> Then（ディシジョン）」という論理式で構成されます。Linuxの iptables や firewalld のリッチなL7版だと考えてください。

• シグナル（If）：
  ・ユーザー / グループ（例：全従業員、または「管理者グループ」のみ）
  ・クラウドアプリ（例：Office 365全般、または特定のSaaSアプリ）
  ・場所（例：社内のグローバルIP、または特定の国）
  ・クライアントアプリ（例：ブラウザ、またはレガシー認証プロトコル）
  ・サインインリスク（Entra ID Identity ProtectionによるAIリスク判定）
• ディシジョン（Then）：
  ・アクセスをブロックする（Block）
  ・アクセスを許可する（Grant）が、MFA（多要素認証）を要求する
  ・アクセスを許可する（Grant）が、デバイスが「準拠」としてマークされていることを要求する

現場のプロが実装する「3つの必須ポリシー」

生成AI（GPT-4o等）を用いてTerraformやGraph API（JSON）でIaC化する際にも、以下の3つのベースラインポリシーはエンタープライズにおいて必須となります。

1. 全ユーザーに対するMFAの強制： ただし、社内の信頼されたIPアドレスからのみ、MFAをスキップする（利便性とのバランス）。
2. レガシー認証の完全ブロック： POP、IMAP、SMTPなどのMFAをサポートしない古いプロトコル（レガシー認証）経由のログインを、全ユーザー・全拠点から無条件でブロックする。（パスワードスプレー攻撃の99%はここを狙います）。
3. 特権管理者（Global Admins）に対する最強の制約： 管理者権限を持つユーザーは、社内・社外問わず、常にMFAと「会社支給の準拠デバイス」からのアクセスを強制する。

3. ADFSにおけるMFA統合とSAMLクレーム（AuthnContextClassRef）の解剖

クラウド（Entra ID）側での制御だけでなく、オンプレミスで認証を司るADFS側でもMFAの統合とクレーム制御が必要です。ハイブリッド認証環境では、「MFAをどちらで実行するか」というアーキテクチャ上の重要な決断があります。

最新のベストプラクティスでは、MFAの実行（Microsoft Authenticatorのプッシュ通知など）自体はクラウドの「Entra ID MFA」に任せ、ADFSはその結果をSAMLトークンとして受け入れる構成をとります。

SAMLのAuthnContextClassRef（認証コンテキスト）

ADFSがEntra IDに対して発行するSAMLトークンには、「ユーザーがどのような手段で認証されたか」を示す AuthnContextClassRef という重要な属性（クレーム）が含まれています。
前回の第6回でWireshark等を用いてパケットをデコードした際、以下のようなXMLが見えたはずです。

<saml:AuthnContext>
  <saml:AuthnContextClassRef>
    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
  </saml:AuthnContextClassRef>
</saml:AuthnContext>

これは「パスワード（単一要素）のみで認証された」ことを意味します。
しかし、ADFS側で「Azure MFAアダプタ」を有効にし、オンプレミスでの認証フロー中にクラウドのMFAを呼び出して成功させた場合、ADFSは以下のクレームをEntra IDへ突き返します。

<saml:AuthnContext>
  <saml:AuthnContextClassRef>
    http://schemas.microsoft.com/claims/multipleauthn
  </saml:AuthnContextClassRef>
</saml:AuthnContext>

Entra ID側はこの multipleauthn クレームを見ることで、「このユーザーはすでにADFS側（オンプレミス）でMFAを突破してきている」と認識し、二重にMFAを要求することなくシームレスにアクセスを許可（Grant）します。このSAML連携のプロトコル挙動を理解しておくことが、プロのインフラエンジニアの必須要件です。

PowerShellを用いたADFSのMFAポリシー設定

ADFSにおいて、特定の証明書利用者信頼（Relying Party Trust：ここではM365）に対してのみMFAを強制するよう、PowerShellでポリシーを記述します。

# ADFSサーバー上で実行
# Microsoft 365 (Office 365 Identity Platform) に対するMFA要件を定義するクレームルールを適用
$RP = Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform"

# エクストラネット（WAP経由の外部アクセス）の場合のみMFAを強制するルール
$MfaRule = '@RuleTemplate = "ExtranetMfa"
c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"]
 => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");'

Set-AdfsRelyingPartyTrust -TargetName $RP.Name -AdditionalAuthenticationRules $MfaRule

これにより、社内ネットワーク（LVS -> ADFS直接通信）の場合はパスワードのみ、外部ネットワーク（LVS -> WAP -> ADFS通信）の場合はMFAが自動的に要求されるという、高度なゼロトラストルーティングが完成します。

4. Linuxエンジニア必見：SSHアクセスとEntra ID MFAのPAM/RADIUS統合

ゼロトラストアーキテクチャの完成形は、社内のすべてのサーバー、すべてのインフラ機器へのアクセスに対してMFAを強制することです。Linuxサーバー（Ubuntu / RHEL）へのSSHアクセスに対して、M365と同じ「Microsoft Authenticator」によるMFAプッシュ通知を統合する手法を解説します。

アーキテクチャとしては、Linuxの PAM (Pluggable Authentication Modules) の中にある pam_radius_auth を利用し、認証要求をWindows Server上の「NPS (Network Policy Server)」へ転送します。このNPSサーバーには「NPS Extension for Entra ID (Azure AD)」がインストールされており、最終的にクラウドへMFA要求を飛ばすという美しい連携フローを構築します。

ステップ1：Linux側へのPAM RADIUSモジュールのインストール

まず、対象のLinuxサーバー（Ubuntu等）にRADIUS認証用モジュールをインストールします。

# Ubuntu系の場合
sudo apt update
sudo apt install libpam-radius-auth

# RHEL系 (AlmaLinux/RockyLinux) の場合
sudo dnf install pam_radius

ステップ2：RADIUSサーバー（Windows NPS）の登録

Linuxサーバーに、認証の転送先となるRADIUSサーバー（内部に構築したNPSサーバー：例 10.0.20.11）のIPアドレスと共有シークレットを設定します。

# /etc/pam_radius_auth.conf
# サーバーIPアドレス       共有シークレット            タイムアウト(秒)
10.0.20.11              MySuperSecretRadiusKey      60

※ここでタイムアウトを60秒と長めに設定するのがプロのコツです。ユーザーがスマホを取り出してAuthenticatorアプリで「承認」をタップするまでの時間的な猶予（ラグ）を考慮する必要があります。

ステップ3：sshdのPAM設定変更（MFAの強制）

SSHログイン時に、第2回で設定したADDS（SSSD経由のLDAP/Kerberosパスワード）による第一要素認証を通過した後、さらに pam_radius_auth による第二要素認証（MFA）を強制するよう、PAMの構成ファイルを書き換えます。

# /etc/pam.d/sshd
# パスワード認証（第一要素）の後にRADIUS連携（第二要素）を追加

auth    requisite   pam_nologin.so
auth    include     common-auth     # ここでSSSD経由のADパスワード認証が行われる
auth    required    pam_radius_auth.so   # 追加：RADIUS経由でEntra ID MFAを要求

# 以下デフォルト設定...

最後に sshd_config 側で UsePAM yes および ChallengeResponseAuthentication yes が設定されていることを確認し、sshdを再起動します。

sudo systemctl restart sshd

これで、LinuxエンジニアがSSHでログインしようとすると、ターミナル上でADDSのパスワードを入力した直後に処理が一時停止し、スマホのMicrosoft Authenticatorアプリに「ログインを承認しますか？」というプッシュ通知が届くようになります。承認をタップして初めて、Linuxのシェルプロンプトが表示されます。
これにより、WindowsとLinux、OSの垣根を完全に越えた「エンタープライズ統合ゼロトラスト基盤」が完成しました。

5. 連載総まとめ：LinuxエンジニアがWindowsインフラを制覇する意義

全8回にわたる本連載「LinuxエンジニアのためのM365認証」も、これにて完結です。
長大なカリキュラムを振り返りましょう。

• 第1回〜第2回： M365ハイブリッド認証の全体像を俯瞰し、ゼロトラストの源泉となる「ADDS（Active Directory）」をWindows Server 2025で構築し、LinuxからSSSDでLDAP/Kerberos連携を行いました。
• 第3回〜第4回： 社内とクラウドの境界である「ADFSとWAP」を設計し、Linuxのカーネルモジュール「LVS (IPVS)」とKeepalivedを用いて、Layer4（DR方式）での超高可用性ロードバランシングアーキテクチャを完成させました。
• 第5回： 認証とは異なる「プロビジョニング」を担う「Entra ID Connect」を構築し、PHS（パスワードハッシュ同期）による強力な暗号化メカニズムとステージングモードを実装しました。
• 第6回〜第7回： tcpdump/WiresharkやWindowsイベントログ解析を駆使したパケットレベルのトラブルシューティング手法と、GPT-4oやClaude 3.5を用いた高度なIaC（Ansible/PowerShell）自動化の極意を学びました。
• 第8回（本記事）： Entra IDの条件付きアクセスによるゼロトラストの論理設計と、ADFSおよびLinux SSH環境へのMFAの完全統合を実現し、鉄壁のセキュリティ要塞を完成させました。

エンジニアとしての境界を越えよ

「自分はLinuxエンジニアだから、WindowsやActive Directoryのことは分からない」。
かつてはそれでも通用したかもしれません。しかし、クラウドシフトとゼロトラストが前提となった現代のインフラ環境において、システムはOSの境界を越えて密接に結びついています。

認証基盤（IdP）の裏側で動いているのは、私たちが得意とするTCP/IPのパケットであり、TLSの暗号化プロトコルであり、HTTPとXML/JSONのトランザクションです。Linuxの深いネットワーク知識や、tcpdump、sysctl、PAM、Ansible といったオープンソースの技術力を持つエンジニアがWindowsのアーキテクチャを理解した時、その真価は爆発的に高まります。

表面的なGUIのウィザードに騙されず、カーネルとパケットのレベルでシステムを支配する。それこそが、本物の「プロフェッショナルなインフラエンジニア」の姿です。
本連載が、皆様のキャリアを飛躍させる一助となれば幸いです。最後までお読みいただき、本当にありがとうございました！