オフィス環境の認証・認可ガイド～従来型からゼロトラストへ

社内の「人」と「マシン」が本物かを確かめ（認証）、何をしてよいかを決める（認可）仕組みは、ADDS・Entra ID・Entra Domain Services・Windows 端末の4者が役割分担して成り立っています。このガイドは、それぞれが何を担い、利用者の何が守られているのかを基礎から整理し、従来型の境界防御からゼロトラストへの移行までをつなげて説明します。

1. なぜ認証・認可の仕組みが必要か

会社の情報資産にアクセスしてよいのは「正しい人」が「正しい端末」から「許された範囲」だけ、という状態を保つためです。これを分解すると次の4つの問いになります。

認証と認可は別物です。認証は「本人確認」、認可は「権限の判定」で、ホテルに例えるとフロントでの本人確認が認証、渡されたカードキーでどの部屋のドアが開くかが認可です。

守りたいもの

• ID（アカウント）：乗っ取られると、その人の権限すべてが攻撃者のものになる。現在の攻撃の大半は ID の窃取から始まる。
• 端末：ID を使う「器」。マルウェアに感染した端末からの正規ログインは、ID だけ見ても見抜けない。
• データとアプリ：最終的に守りたい資産。ファイルサーバー、メール、業務システム、SaaS。
• ネットワーク：従来は「社内 LAN の内側＝安全」という前提で守られてきた。

なぜ「人」だけでなく「マシン」も認証するのか

会社が管理していない私物 PC や感染 PC から社内資源に入られることを防ぐためです。Windows 端末自体もドメインやクラウドに「アカウント」を持ち、端末として本人確認されます。これにより「正しい人が、会社が管理する健全な端末から使っている」ことまで確かめられます。

2. 全体像：4つの登場人物

登場人物は「社内の鍵の番人（ADDS）」「クラウドの鍵の番人（Entra ID）」「クラウドに置いた社内型の番人（Entra Domain Services）」「両者に身元を証明する端末（Windows）」の4つです。

多くの会社では ADDS がユーザー台帳の原本で、Entra Connect（または Cloud Sync）がその内容を Entra ID へ同期します。Entra Domain Services は Entra ID から一方向で同期されるため、同じ ID が3か所で使える状態になります。

3. ADDS：社内の台帳と鍵の番人

ADDS（Active Directory Domain Services）は、社内ネットワークで「誰がいて、どのグループに属し、どの PC が仲間か」を一元管理する仕組みです。実体はドメインコントローラー（DC）と呼ばれる Windows Server で、冗長化のため通常2台以上置かれます。

ADDS が担う4つの役割

Kerberos の要点：「パスワードを送らない」

Kerberos では、パスワードそのものはネットワークを流れません。パスワードから作った鍵で暗号化したやり取りで本人確認し、DC が2種類のチケットを発行します。

• TGT（チケット交付チケット）：サインイン時に1回もらう「入館証」。既定の有効期間は10時間。
• サービスチケット：TGT を見せて、ファイルサーバーなど個別のサービスごとにもらう「部屋別の入室証」。

これにより、朝一度サインインすれば以降はパスワードを入れ直さずに社内資源を使えます（シングルサインオン）。

ADDS の限界

• 前提が「社内ネットワークにいること」。在宅からは VPN が必要になる。
• SaaS が話す SAML / OIDC にはそのまま対応しない（従来は AD FS を追加していた）。
• 一度チケットを得ると、有効期限内は再検証されない。盗まれたチケットやハッシュの再利用（Pass-the-Ticket / Pass-the-Hash）が代表的な攻撃手法。
• DC 自体が奴られると全社の鍵が奴られる。そのため管理者権限の分離（階層モデル）が重要。

4. Windows 端末：身元を証明する「器」

Windows 端末は、利用者の鍵を安全に保管し、自分自身も「会社の端末である」と証明する役割を担います。どこに「参加」しているかで、認証の相手が変わります。

端末の3つの参加形態

端末を安全にする部品

• コンピューターアカウント：ドメイン参加 PC は ADDS 内に自分のアカウントとマシンパスワードを持ち、既定では30日ごとに自動更新します。これで DC との間に「セキュアチャネル」を張り、「仲間の PC」と認められます。
• TPM：マザーボード上のセキュリティチップ。秘密鍵をチップの外に出さずに署名できるため、鍵をコピーして別の PC で使うことができません。
• Windows Hello for Business：パスワードの代わりに、TPM 内の秘密鍵で本人確認します。PIN や指紋は「その端末の TPM を開けるための鍵」であり、サーバーに送られません。PIN が漏れても端末がなければ使えないのが強みです。
• PRT（Primary Refresh Token）：Entra 参加・ハイブリッド参加の端末に Windows サインイン時に発行される、クラウド向けの「入館証」。TPM で保護された鍵に紐づくため端末から持ち出せず、有効期間90日・利用中は約4時間ごとに更新されます。「どの端末から来たか」の情報も運び、条件付きアクセスの判定に使われます。
• BitLocker：ディスク暗号化。端末を盗まれても中のデータと鍵を読まれにくくします。
• Intune（MDM）：クラウドからの端末管理。OS 更新や暗号化の状態を確認し、「準拠している端末か」を Entra ID に伝えます。GPO のクラウド版と考えると分かりやすいです。

5. Entra ID：クラウドの台帳と鍵の番人

Microsoft Entra ID（旧 Azure Active Directory）は、インターネット上のどこからでも使える ID プロバイダー（IdP）です。名前に「AD」が付いていましたが、ADDS のクラウド版ではありません。OU や GPO、Kerberos のドメイン参加といった概念は持たず、Web 標準のプロトコルで話します。

Entra ID が担う役割

• シングルサインオン（SSO）：Microsoft 365、Azure、Salesforce などの SaaS に、SAML・OpenID Connect（OIDC）・OAuth 2.0 でサインインさせる。アプリ側はパスワードを持たず、Entra ID が署名した「トークン」だけを信頼する。
• 多要素認証（MFA）とパスワードレス：Authenticator アプリ、FIDO2 セキュリティキー、Windows Hello。
• 条件付きアクセス：「誰が・どの端末で・どこから・どれくらい怖い状態で」をサインインのたびに判定し、許可・MFA 要求・ブロックを決める（第9章）。
• 端末の登録と PRT の発行：Entra 参加端末の台帳を持ち、端末ごとの鍵で本物かを確かめる。
• リスク検知とログ：不審な場所からのサインインや漏えいした資格情報を検知し、全サインインを記録する。

ADDS とつなぐ：Entra Connect

既存の ADDS がある会社では、Entra Connect Sync（または軽量版の Cloud Sync）が ADDS のユーザー・グループを Entra ID へ同期します。クラウドでのパスワード確認には3つの方式があります。

6. Entra Domain Services：クラウドに置いた「社内型」の番人

Microsoft Entra Domain Services（旧 Azure AD Domain Services、略称 Entra DS）は、DC を自分で構築せずに、Azure 上でドメイン参加・GPO・LDAP・Kerberos/NTLM を使えるマネージドサービスです。位置づけは「クラウドに移した古いアプリのための橋渡し」で、ADDS の全面的な置き換えではありません。

• 使いどころ：Kerberos や LDAP しか話せない業務アプリを Azure の仮想マシンへ移したが、クラウドに DC を立てて運用したくないとき。
• 同期の向き：Entra ID からマネージドドメインへの一方向。ハイブリッド環境では ADDS → Entra ID → Entra DS の順に流れる。
• パスワード：Kerberos/NTLM 用のハッシュが必要なため、パスワードハッシュの同期が前提。利用者は Entra ID と同じ資格情報でサインインする。

編集者注：ご依頼の「EDDS」はこの Entra Domain Services を指すと解釈しています。

7. サインインの流れ：オンプレとクラウド

オンプレもクラウドも、朝のサインインで「入館証」をもらい、以後はそれを見せて個別のサービスに入るという骨格は同じです。決定的な違いは③で、クラウド側はアクセスのたびに端末や状況を検証し直します。

ハイブリッド参加の端末では、1回の Windows サインインで TGT と PRT の両方を取得するため、利用者は社内ファイルサーバーにも Teams にも追加のパスワード入力なしでアクセスできます。

8. 利用者はなぜ安全か：何が何から守られているか

利用者の安全は、「秘密を送らない」「鍵を端末から出さない」「権限を最小にする」「毎回確かめる」の4つの原則の積み重ねで担保されています。どれか1つが破られても、次の層で止める考え方（多層防御）です。

利用者から見ると、「朝一度 PIN を入れるだけ」の裏でこれだけの確認が自動で行われています。便利さ（SSO）と安全性が両立しているのは、入館証にあたるチケットや PRT が端末と暗号で強く紐づいているからです。

9. 従来型のセキュリティとゼロトラスト

従来型は「社内ネットワークにいること」を信頼の根拠にし、ゼロトラストは「誰が・どの端末で・どんな状況か」を毎回確かめることを根拠にします。信頼の置き場所が「ネットワークの場所」から「ID と端末」に移るのが本質です。

クラウド利用と在宅勤務が当たり前になり、「内側」そのものが曖昧になったこと、そして侵入後に内部を横移動する攻撃（ランサムウェアなど）が増えたことが転換の理由です。

ゼロトラストの3原則（Microsoft の定義）

1. 明示的に検証する（Verify explicitly）：すべてのアクセス要求を、利用できるあらゆるシグナルで認証・認可する。→ MFA、端末の準拠状態、サインインリスク。
2. 最小権限アクセス（Use least privilege access）：必要なアクセスだけを、必要な時間だけ与える。→ グループ設計、管理者権限の時間限定付与（PIM）。
3. 侵害を前提とする（Assume breach）：攻撃者がすでに内部にいる前提で、被害範囲の限定と迅速な検知・対応を設計する。→ ログの集約、EDR、セグメント化。

条件付きアクセス：ゼロトラストの「検問所」

Entra ID の条件付きアクセスは、「もし（シグナル）ならば（判定）」形式のポリシーです。例：

• 全ユーザー × 全アプリ → MFA を要求する
• 経理システム × 準拠していない端末 → ブロック
• サインインリスクが「高」 → ブロック、またはパスワード変更を要求
• 管理者ロール → フィッシングに強い認証（FIDO2・Windows Hello）のみ許可

ここで第4章の PRT が生きます。PRT は「この端末は登録済み・準拠済み」という情報を運ぶため、利用者が意識しなくても端末条件が毎回検証されます。

10. ゼロトラストへの進め方と用語集

多くの会社は ADDS を残したまま、Entra ID を「検問所」として段階的に強化していきます。一度に切り替える必要はありません。

典型的なステップ

1. ID を統合する：Entra Connect で ADDS と Entra ID を同期し、全員が1つの ID で使えるようにする。
2. MFA を全員に：まず管理者、次に全ユーザー。古い認証方式（レガシー認証）をブロックする。
3. 端末を Entra ID に登録する：既存 PC はハイブリッド参加、新しい PC は Entra 参加。Intune で準拠状態を管理する。
4. 条件付きアクセスを導入する：「準拠端末のみ」「高リスクはブロック」などを、レポートモードで影響を確認してから有効化する。
5. パスワードレスへ：Windows Hello for Business や FIDO2 を展開し、フィッシングに強い認証に寄せる。
6. 社内アプリも検問所の後ろへ：SaaS は Entra ID の SSO に集約し、社内 Web アプリはアプリプロキシや ZTNA で公開して VPN 依存を減らす。Kerberos しか話せないアプリを Azure へ移す場合の受け皿が Entra Domain Services。
7. 最小権限と監視：管理者権限は必要なときだけ付与（PIM）し、サインインログと端末の EDR を集約して監視する。

用語集

参考資料

• What is Microsoft Entra Domain Services?
• Understanding Primary Refresh Token (PRT)
• What is Zero Trust?