企業環境の連携ガイド：ID・端末・証明書・ネットワークはどうつながるか

企業で「正しい人が、健全な会社端末から、許された範囲だけ」を実現するには、ID 基盤（Entra ID・ADDS）だけでは足りず、端末管理（Intune）、証明書（AD CS）、ネットワーク制御、脅威検知、データ保護、iPhone 管理が連携する必要があります。このガイドは前回の Untitled の続編として、それらがどうつながり、1000名規模の PC 刷新検討で挙がった論点がなぜ生まれるのかを解説します。

1. 前提と読み方

このガイドが前提にするのは、次の企業モデルです。各章の「なぜそう決めるのか」は、この前提から導かれています。

前回ガイドとの関係

前回は「誰かを確かめる（認証）」と「何を許すか（認可）」の仕組みを扱いました。今回は、その判定に必要な「材料」を作る仕組みと、判定結果を実際に強制する仕組みを扱います。

• 材料を作る：端末が健全か（Intune・Defender）、端末が本物か（証明書）、人が在籍しているか（人事連携）
• 判定する：Entra ID の条件付きアクセス（前回第9章）
• 強制する：ネットワークの入口（802.1X、ZTNA）、データの扱い（Purview）、端末の設定（Intune）

各章は、仕組みの役割 → 他とのつながり → 検討で決めること、の順で書いています。

2. 全体像：ID 基盤の周りにつながる仕組み

企業環境では Entra ID が「判定の中心」になり、周りの仕組みが判定の材料を渡したり、判定結果を強制したりします。前回ガイドの登場人物（Entra ID・ADDS・Windows 端末）に、この図では6つが加わっています。

矢印は情報の流れです。人事から ID が生まれ、Intune と Defender が端末の状態を Entra ID に伝え、AD CS の証明書が Intune 経由で端末に届き、その証明書で端末がネットワークに入ります。

3. 信頼のシグナルが集まる流れ

ゼロトラストの「毎回検証する」は、実際には複数の仕組みが出すシグナルを Entra ID の条件付きアクセスが集めて判定することで実現されます。Intune や Defender を導入する最大の理由は、この判定材料を作ることにあります。

判定はアプリへのサインインやトークン更新のたびに行われます。同じ人でも、端末が感染して「高リスク」になれば次の判定で適切に止められます。

「準拠（コンプライアンス）」とは何か

Intune のコンプライアンスポリシーは「会社が求める最低基準」のチェックリストです。全項目を満たすと「準拠」と判定され、その結果が Entra ID の端末情報に書き込まれます。

• Windows：BitLocker 有効、セキュアブート有効、OS が指定版数以上、Defender のリスクが「中」以下
• iPhone：パスコード設定済み、脱獄していない、iOS が指定版数以上

非準拠になったときに「何日の猶予で遡断するか」「長期間オフラインだった持ち出し PC をどう扱うか」は運用との兼ね合いで決める論点です。

検討で挙がったポリシー群の意味

導入時は「レポート専用モード」で影響を確認してから有効化するのが定石です。また、全ポリシーから除外した緊急用アカウント（Break-glass）を用意し、設定ミスで全員が閉め出される事態に備えます。

4. Intune：端末管理の中心

Intune は、社外にある PC や iPhone にもインターネット経由で設定・アプリ・更新を配り、その結果を「準拠」として Entra ID に報告するクラウド型の端末管理（MDM）です。前回ガイドで触れた「GPO のクラウド版」であり、持ち出し前提の企業ではこちらが主役になります。

なぜ「Entra 参加」を選ぶのか

検討では PC を Hybrid Entra 参加ではなく Entra 参加にする方向でした。理由は次の3点です。

• Hybrid 参加はオンプレの ADDS への参加が必要で、セットアップ時に DC へ届かなければならない。利用者が自宅でセットアップする前提と相性が悪い。
• 管理が ADDS（GPO）と Intune の二重になり、設定の衝突や調査の手間が増える。
• オンプレのファイルサーバーへの SSO は、Entra 参加でも Windows Hello for Business の Cloud Kerberos Trust で実現できる（Entra ID が一部の Kerberos チケットを発行し、DC がそれを引き継ぐ仕組み）。

ただし、Entra 参加 PC は ADDS にコンピューターアカウントを持たないため、「デバイス証明書で NPS に認証する」従来の方式がそのままでは使えません。この影響は第5・6章で扱います。

Intune の主な機能と他とのつながり

ローカル管理者権限を外す意味

利用者が PC の管理者だと、セキュリティ設定の無効化や任意ソフトの導入ができ、マルウェアも同じ権限で動けます。全員から外すと安全性は大きく上がりますが、「ドライバーを入れたい」などの要望に応える仕組み（EPM）と、サポート時に使う管理者パスワード（LAPS）がセットで必要になります。この前提として、業務アプリの棚卸しが欠かせません。

5. AD CS と証明書：端末の「身分証」

証明書は、信頼できる発行元（認証局、CA）が「この公開鍵はこの端末（人）のもの」と署名した身分証です。パスワードと違い盗み見や使い回しができず、利用者の操作も要らないため、Wi-Fi・有線 LAN・VPN のような「機械同士の認証」に向いています。AD CS は Windows Server に含まれる自社用の CA です。

証明書が届いて使われるまで（SCEP の場合）

1. Intune が端末に SCEP プロファイルと一回限りのチャレンジ（合言葉）を配る。事前に「この CA を信頼する」設定も配布しておく。
2. 端末が自分の中で鍵ペアを作り、証明書の申請書（CSR）とチャレンジを NDES に送る。持ち出し PC は社外から申請するため、NDES を Entra アプリプロキシなどで公開する必要がある。
3. NDES 上の Intune Certificate Connector がチャレンジと申請内容の一致を検証し、正規の管理端末だけ CA に発行を依頼する。
4. 発行された証明書が同じ経路で端末に戻る。
5. 端末はその証明書で Wi-Fi・有線 LAN（802.1X）や VPN に接続する。検証側は CRL で「失効していないか」も確かめる。

検討で挙がった注意点の意味

AD CS のサーバーは、DC と同じく「奴られると全社の信頼が崩れる」最重要資産（Tier 0）として管理します。

6. ネットワーク接続制御：誰をどこに繋ぐか

ゼロトラストでもネットワーク制御は不要になりません。「社内 LAN にいるから信頼する」のではなく、「認証された端末しか繋がせない」「繋いでも必要な場所にしか行かせない」ために使います。入口は社内、社外から社内へ、インターネットへの3つです。

802.1X と RADIUS の関係

802.1X は「ケーブルを挿しただけでは通信させず、認証に成功したらポートを開く」規格です。スイッチや無線 AP は自分では判定せず、RADIUS サーバーに「この証明書の端末を入れてよいか」を問い合わせます。RADIUS は証明書の発行元と失効状態を確認し、必要に応じて VLAN（社員用・ゲスト用など）も指定します。

Windows Server の NPS は従来、証明書を ADDS のアカウントと照合して判定してきました。Entra 参加 PC は ADDS にアカウントがないため、次のいずれかになります。

• NPS を使い、ADDS にある利用者の証明書（ユーザー証明書）で認証する
• Intune や Entra ID と連携できる NAC 製品やクラウド RADIUS を使い、準拠状態まで加味して判定する

後者は「証明書は正しいが、更新を滞らせた非準拠の PC」を社内 LAN から外すことができ、ゼロトラストの考え方を社内 LAN にも延長できます。

VPN と ZTNA の違い

VPN は端末を社内ネットワークに「入れる」仕組みで、入った後は広い範囲に到達できます。ZTNA はアプリごとに接続を仲介し、その都度条件付きアクセスを適用します。前回ガイドの「城と堀」から「検問所」への移行を、リモートアクセスで具体化したものが ZTNA です。ただし ZTNA に対応しにくい古いアプリもあるため、移行期間は併用が現実的です。

このほか、VLAN で社員 PC・iPhone・ゲスト・プリンター・サーバーを分離すること、キッティングセンターや自宅から Autopilot に必要な通信先へ届くこと（認証付きプロキシが挟まると失敗しやすい）も設計対象です。

7. iPhone：Apple の仕組みとの連携

iPhone は Windows と違い、Apple の仕組みを経由して Intune の管理下に入ります。中心になるのは Apple Business Manager（ABM）で、「この端末はこの会社のもの」という所有情報を Apple が保持します。

ガバナンス上の落とし穴：毎年の更新

APNs 証明書、ABM と Intune をつなぐトークン、VPP トークンには有効期限があり、毎年更新が必要です。特に APNs 証明書は同じ Apple アカウントで更新しないと全台の再登録が必要になるため、担当者と期限を台帳で管理します。AD CS の CA 証明書や CRL の期限も同じ台帳で管理すると安全です。

購入時に販売店やキャリアに ABM 登録を依頼することが前提です。既存の iPhone は Apple Configurator で後から追加できますが、初期化が必要です。

8. 脅威検知・データ保護・ログ監視

認証と認可は「入り口」を守る仕組みです。ゼロトラストの3原則のうち「侵害を前提とする」を担うのが、入った後を見張るこの章の仕組みです。

なぜログを別の場所に集めるのか

Entra ID のサインインログや監査ログは、既定の保持期間が短く、事故の発覚が遅れると調査に間に合いません。また、「深夜に海外からサインイン→同じ人の PC で不審なプロセス→大量ダウンロード」のような攻撃は、ログを横断で見ないと気づけません。そのため Log Analytics や SIEM に転送し、必要に応じて SOC/MDR に監視を委託します。

管理者と緊急用アカウント

• 管理者は一般業務用と別のアカウントを持ち、権限は PIM で必要なときだけ有効化する。
• 条件付きアクセスから除外した緊急用アカウントを2つ以上用意し、FIDO2 キーで保護してサインイン時にアラートを出す。
• DC、CA、Entra Connect サーバーは Tier 0 として、一般的な管理端末からは触らせない。

9. PC のライフサイクルで見る連携

ここまでの仕組みを時間軸で並べると、1台の PC が調達されてから手放されるまでに、どの仕組みがいつ働くかが見えます。最も詰まりやすいのは③の利用者による初回設定です。

③の「鶏と卵」問題と TAP

新しい PC を初めて起動した利用者は、まだ Authenticator も Windows Hello も登録していません。しかし条件付きアクセスは MFA を求めます。この行き詰まりを解くのが一時アクセスパス（TAP）です。管理者が期限付きの使い捨てパスコードを発行し、利用者はそれで最初のサインインと MFA・Hello の登録を済ませます。

TAP 自体が「最初の鍵」になるため、誰が発行し、どの経路で本人に渡し、何時間有効にするかがセキュリティと利便性の分かれ目になります。1000名が一斉にここで詰まるとヘルプデスクが饱和するため、部門ごとにウェーブを分けて展開します。

②と③の役割分担（pre-provisioning）

Autopilot の pre-provisioning では、端末に対する設定とアプリをキッティングセンターで済ませ、利用者側では利用者に対する設定だけを適用します。利用者の待ち時間が短くなり、自宅回線での失敗も減ります。ただし登録状態ページ（ESP）で必須にするアプリを増やしすぎると、③での失敗や時間切れが増えます。

⑤で「止める」べきものの連鎖

退職や紛失では、人事→ADDS→Entra ID の順にアカウントが止まり、PRT やセッションも無効になります。ただし証明書は失効させない限り有効期限まで使えるため、Intune での端末削除と CA での失効が連動するかを設計時に確認します。「どこか1つ止め忘れるとそこから入れる」のが複数の仕組みを連携させる環境の注意点です。

10. 検討論点の読み解き表

共有された検討の「最初に決めるべき基本方針」を、このガイドと前回ガイドのどこを理解すれば判断できるかに対応づけました。RFP や工数見積もりを読むときの索引として使えます。

検討の結論でも指摘されていたように、成否を左右しやすいのは「アプリとオンプレ資源の棚卸し」と「初回認証（TAP）の受け渡し」です。前者は Entra 参加・管理者権限剥奪・ZTNA のすべての前提になり、後者は展開のボトルネックになります。

用語集（前回ガイドにないもの）

参考資料

• Configure infrastructure to support SCEP with Intune
• Understanding Primary Refresh Token (PRT)
• What is Zero Trust?