Zero Trust ⁽²⁾

企業で「正しい人が、健全な会社端末から、許された範囲だけ」を実現するには、ID 基盤（Entra ID・ADDS）だけでは足りず、端末管理（Intune）、証明書（AD CS）、ネットワーク制御、脅威検知、データ保護、iPhone 管理が連携する必要があります。このガイドは前回の Untitled の続編として、それらがどうつながり、1000名規模の PC 刷新検討で挙がった論点がなぜ生まれるのかを解説します。 このガイドが前提にするのは、次の企業モデルです。各章の「なぜそう決めるのか」は、この前提から導かれています。 前回は「誰かを確かめる（認証）」と「何を許すか（認可）」の仕組みを扱いました。今回は、その判定に必要な「材料」を作る仕組みと、判定結果を実際に強制する仕組みを扱います。 各章は、仕組みの役割 → 他とのつながり → 検討で決めること、の順で書いています。 企業環境では Entra ID が「判定の中心」になり、周りの仕組みが判定の材料を渡したり、判定結果を強制したりします。前回ガイドの登場人物（Entra ID・ADDS・Windows 端末）に、この図では6つが加わっています。 矢印は情報の流れです。人事から ID が生まれ、Intune と Defender が端末の状態を Entra ID に伝え、AD CS の証明書が Intune 経由で端末に届き、その証明書で端末がネットワークに入ります。 ゼロトラストの「毎回検証する」は、実際には複数の仕組みが出すシグナルを Entra ID の条件付きアクセスが集めて判定することで実現されます。Intune や Defender を導入する最大の理由は、この判定材料を作ることにあります。 判定はアプリへのサインインやトークン更新のたびに行われます。同じ人でも、端末が感染して「高リスク」になれば次の判定で適切に止められます。 Intune のコンプライアンスポリシーは「会社が求める最低基準」のチェックリストです。全項目を満たすと「準拠」と判定され、その結果が…

社内の「人」と「マシン」が本物かを確かめ（認証）、何をしてよいかを決める（認可）仕組みは、ADDS・Entra ID・Entra Domain Services・Windows 端末の4者が役割分担して成り立っています。このガイドは、それぞれが何を担い、利用者の何が守られているのかを基礎から整理し、従来型の境界防御からゼロトラストへの移行までをつなげて説明します。 会社の情報資産にアクセスしてよいのは「正しい人」が「正しい端末」から「許された範囲」だけ、という状態を保つためです。これを分解すると次の4つの問いになります。 認証と認可は別物です。認証は「本人確認」、認可は「権限の判定」で、ホテルに例えるとフロントでの本人確認が認証、渡されたカードキーでどの部屋のドアが開くかが認可です。 会社が管理していない私物 PC や感染 PC から社内資源に入られることを防ぐためです。Windows 端末自体もドメインやクラウドに「アカウント」を持ち、端末として本人確認されます。これにより「正しい人が、会社が管理する健全な端末から使っている」ことまで確かめられます。 登場人物は「社内の鍵の番人（ADDS）」「クラウドの鍵の番人（Entra ID）」「クラウドに置いた社内型の番人（Entra Domain Services）」「両者に身元を証明する端末（Windows）」の4つです。 多くの会社では ADDS がユーザー台帳の原本で、Entra Connect（または Cloud Sync）がその内容を Entra ID へ同期します。Entra Domain Services は Entra ID から一方向で同期されるため、同じ ID が3か所で使える状態になります。 ADDS（Active Directory Domain Services）は、社内ネットワークで「誰がいて、どのグループに属し、どの PC が仲間か」を一元管理する仕組みです。実体はドメインコントローラー（DC）と呼ばれる Windows Server で、冗長化のため通常2台以上置かれます。 Kerberos では、パスワードそのものはネットワークを流れません。パスワードから作った鍵で暗号化したやり取りで本人確認し、DC…