クラウド時代に変わったID管理の考え方
「Active Directory（AD）」という言葉を聞いて、Windows Serverによるユーザー管理やPC管理を思い浮かべる情報システム担当者は多いのではないでしょうか。
Active Directoryは、長年にわたり企業のWindows環境を支えてきた認証・ID管理基盤です。一方、現在はMicrosoft 365や各種SaaSの普及により、「Microsoft Entra ID」という名称を目にする機会が増えました。
なかには、
「Microsoft 365を導入したら自然に使うようになった」
「Active Directoryのアカウントを同期しているだけで、詳しい役割は分からない」
という企業もあるでしょう。
しかし、Microsoft Entra IDは、単にActive Directoryをクラウドへ移した製品ではありません。両者は、想定するIT環境とアクセス制御の考え方が異なります。
本記事では、Active DirectoryからMicrosoft Entra IDへの変化を通して、クラウド時代に求められるID管理の考え方と、それがゼロトラストセキュリティの入口になる理由を解説します。
01 Active Directoryは、社内ネットワーク中心の時代に最適だった
Active Directoryが登場した2000年前後、多くの企業システムは社内ネットワークを中心に構築されていました。
社員は社内LANに接続されたWindows PCから、ファイルサーバーや業務システムへアクセスします。Active Directoryは、こうした環境で次のような管理を一元化してきました。
- ユーザーアカウントやパスワード
- コンピューターのドメイン参加、グループの管理
- 社内システムへのアクセス権
- グループポリシーによる端末設定
この機能設計は、社内LAN、Windows PC、Windows Serverなど、組織が管理する環境を中心としていました。社外から利用する場合も、VPNなどで社内ネットワークへ接続し、その先で認証を行う構成が一般的でした。
言い換えると、当時はネットワーク側で安全な環境を作り、その中でActive Directoryがユーザーや端末を認証するという役割分担が成り立っていました。
Active Directoryは、この時代の企業システムに適した、合理的なID管理基盤だったのです。
02 クラウドの普及により、企業システムの前提が変わった
現在では、企業が利用するシステムの多くが社内ネットワークの外側にあります。
Microsoft 365をはじめとするクラウドサービスや各種SaaSは、インターネット経由で直接利用できます。社員が自宅や外出先から、PCやスマートフォンでアクセスすることも珍しくありません。
このような環境では、
「社内ネットワークに接続しているから安全」
「社外からのアクセスだから危険」
という区分だけでは、安全性を十分に判断できません。
社内からのアクセスであっても、アカウントが盗まれている可能性があります。一方、社外からであっても、会社が管理する安全な端末から正当にアクセスしている場合があります。
そこで重要になるのが、ネットワークの内側・外側だけでなく、
- 誰がアクセスしているのか
- どの端末を使っているのか
- どこからアクセスしているのか
- 普段と異なる利用ではないか
- 何にアクセスしようとしているのか
といった情報を組み合わせて判断することです。
企業システムの変化に伴い、セキュリティの判断軸も、ネットワーク中心からID中心へと変わってきたのです。
03 Microsoftが名称を「Entra ID」へ変更した理由
Microsoft Entra IDは、以前は「Azure Active Directory（Azure AD）」という名称でした。
Microsoftは2023年、Azure ADをMicrosoft Entra IDへ名称変更しました。機能を別製品へ置き換えたわけではありませんが、その背景には製品の位置付けを明確にする狙いがあります。
Microsoftは、Microsoft Entra IDという名称の方が、製品のマルチクラウド・マルチプラットフォーム対応を正確に表し、オンプレミスのActive Directoryとの混同も避けやすいと説明しています。（Microsoft Learn）
「Azure Active Directory」という名称からは、「Azure上で動くActive Directory」や「Active Directoryのクラウド版」という印象を受けやすかったかもしれません。
しかし実際のMicrosoft Entra IDは、Microsoft 365やAzureだけでなく、他社のSaaSを含む複数のクラウド環境にまたがって、IDとアクセスを管理するための基盤です。
つまり名称変更は、単なるブランド刷新ではなく、「クラウド時代のID・アクセス管理基盤である」という役割を明確にするためのものだったといえます。
04 Active DirectoryとMicrosoft Entra IDで異なる設計思想
Active DirectoryとMicrosoft Entra IDは、どちらもIDを管理する基盤ですが、想定する環境が異なります。
| Active Directory | Microsoft Entra ID |
|---|---|
| 社内ネットワークを中心に設計 | インターネットやクラウド利用を前提に設計 |
| Windows PCやWindows Serverが中心 | Microsoft 365、SaaS、クラウド、各種端末が対象 |
| ドメイン参加、Kerberos、LDAPなどを活用 | OAuth、OpenID Connect、SAMLなどクラウド向けの仕組みを活用 |
| ユーザー、端末、グループなどを管理 | IDに加え、アクセス時の条件やリスクを評価 |
| ネットワーク機器などと組み合わせてアクセス元を制御 | ID、端末、場所、アプリ、リスクなどを組み合わせて制御 |
Active Directoryでも、ユーザー、端末、グループ、アクセス権を管理できます。VPNやファイアウォールなどと組み合わせれば、アクセス元に応じた制御も可能です。
違いは、Active Directoryではこうした制御をネットワーク機器や別の管理システムに頼っていた点です。一方、Microsoft Entra IDでは、IDを軸に、端末、場所、アプリ、リスクなどを組み合わせてアクセスを判断します。
たとえば、同じユーザー名とパスワードでサインインした場合でも、
- 組織が管理する端末からの通常のアクセス
- 管理されていない端末からのアクセス
- 普段とは異なる国や地域からのアクセス
- リスクが検知されたサインイン
では、異なる制御を適用できます。
多要素認証（MFA）や条件付きアクセス、ID Protectionなどは、こうした判断を行うための代表的な機能です。
Microsoft Entra IDは、アカウントが正しいかを確認するだけでなく、そのIDによる今回のアクセスを許可してよいかを判断するための基盤でもあるのです。
05 ハイブリッド運用では「ADの同期先」で終わらせない
オンプレミスのActive DirectoryとMicrosoft Entra IDを併用するハイブリッド構成は、決して誤った運用ではありません。
既存の業務システムやファイルサーバー、ドメイン参加端末が残っている場合、Active Directoryを維持しながらMicrosoft Entra IDへアカウント情報を同期する構成には合理性があります。
問題は、Microsoft Entra IDを単なる同期先として捉えている場合です。
たとえば、
- Microsoft 365へのログインにしか使っていない
- MFAの適用範囲が限定されている
- 条件付きアクセスを設定していない
- 管理者権限やサインインリスクを十分に確認していない
といった状態では、クラウドサービスを利用していても、ID管理の考え方はオンプレミス時代の延長にとどまります。
Active Directoryとの同期を続けながらでも、Microsoft Entra ID側でMFAや条件付きアクセス、クラウドアプリとのシングルサインオン、管理者権限の保護を進めることはできます。
必要なのは、Active Directoryをただちに廃止することではなく、オンプレミスのアカウント管理とクラウド上のアクセス判断を、どのように分担するかを整理することです。
06 ゼロトラストの本質は「誰も信用しない」ことではない
Microsoft Entra IDによるID中心のアクセス制御は、ゼロトラストセキュリティの入口になります。
ゼロトラストは、しばしば「誰も信用しない考え方」と説明されます。しかし、この表現だけでは、実務上の意味が伝わりにくいかもしれません。
より正確には、ネットワーク上の場所だけを根拠に、ユーザーや端末を暗黙に信用しないという考え方です。
NISTの「Zero Trust Architecture」でも、社内LANにあるか、インターネット側にあるかといったネットワーク上の場所だけを理由に、暗黙の信頼を与えないことが示されています。（NIST Computer Security Resource Center）
つまり、ゼロトラストの本質は、すべてを一律に拒否することではありません。
- 社内ネットワークからのアクセスだから許可する
- VPNへ接続できたから、その後は信用する
- 会社支給端末だから常に安全とみなす
といった判断をせず、ID、端末、場所、リスクなどを確認して、アクセスを許可するかどうかを決めることです。
Microsoft Entra IDは、これらの情報をIDと結び付け、ポリシーに基づいてアクセスを制御します。
そのため、Microsoft Entra IDを正しく理解し、認証とアクセス制御を見直すことは、ゼロトラストへ向けた第一歩になります。
07 情報システム担当者が確認したい5つのポイント
Microsoft 365を導入している企業では、すでにMicrosoft Entra IDを利用しているケースが多いでしょう。
しかし、「利用している」ことと、「ID基盤として活用できている」ことは同じではありません。
次の5点を確認してみましょう。
| 確認項目 | チェック内容 |
|---|---|
| Microsoft Entra IDの役割を把握しているか | Active Directoryから何を同期しているのか、Microsoft 365やクラウドサービスの認証がどこで行われているのかを整理する |
| 多要素認証を適切に適用しているか | 管理者だけでなく一般ユーザーも含めて適用範囲を確認する。古い認証方式や例外設定が残っていないかも重要 |
| 条件付きアクセスを活用しているか | 端末の管理状態、場所、アプリ、リスクなどに応じて、MFAの要求やアクセス制限を使い分ける |
| 管理者アカウントと権限を見直しているか | 日常業務用と管理作業用のアカウントを分離し、不要な管理者権限が残っていないかを確認する |
| Active Directory中心の運用をそのまま持ち込んでいないか | オンプレミスで管理すべきものと、Microsoft Entra IDで制御すべきクラウドアクセスを分け、自社に合った役割分担を検討する |
08 まとめ
Active DirectoryからMicrosoft Entra IDへの変化は、単なる製品名の変更や世代交代ではありません。
社内ネットワークとWindows環境を中心に管理する設計から、クラウド、SaaS、多様な端末に広がるIDとアクセスを管理する設計へ、企業システムの前提が変わったことを示しています。
MicrosoftがAzure Active DirectoryをMicrosoft Entra IDへ名称変更した背景にも、オンプレミスのActive Directoryとの違いを明確にし、マルチクラウド・マルチプラットフォーム向けのID基盤であることを伝える狙いがあります。
Active Directoryで培った知識や運用経験が不要になるわけではありません。ハイブリッド環境では、今後も重要な役割を担う場合があります。
一方、クラウド時代には、アカウントが正しいかを確認するだけでなく、ID、端末、場所、リスクなどをもとに、「今回のアクセスを許可してよいか」を判断する視点が欠かせません。
ゼロトラストの本質は、単純に「誰も信用しない」ことではなく、ネットワーク上の場所だけを理由に暗黙の信頼を与えないことです。
Microsoft Entra IDを単なる同期先ではなく、IDとアクセスを判断する基盤として捉え直すこと。それが、クラウド時代のID管理へ運用をアップデートする第一歩になります。
ゼロトラストセキュリティの導入・見直しを検討している方へ
ここまで見てきたとおり、Microsoft Entra IDはゼロトラストセキュリティの入口となる基盤です。
一方、実際の導入では、ID管理だけでなく、端末の保護、クラウドサービスへのアクセス制御、ログ監視など、押さえておくべき要素は多岐にわたります。
ドコモソリューションズでは、ゼロトラストセキュリティの実現に必要な機能をひとつにまとめてご提供しており、複雑な設計を必要とせず導入いただけます。
既存のActive DirectoryやMicrosoft 365を活かしたセキュリティ強化についても、お気軽にご相談ください。
※Microsoft、Active Directory、Azure Active Directory、Microsoft Entra ID、Microsoft 365、Azure、Windows、Windows Serverは、Microsoft Corporationの米国およびその他の国における登録商標または商標です。