ID 決定ガイド

オンプレミス環境、ハイブリッド環境、クラウドのみの環境など、どのような環境であっても、IT 部門はリソースへのアクセス権を持つ管理者、ユーザー、およびグループを制御する必要があります。 ID 管理とアクセス管理 (IAM) サービスを使用すると、クラウドでアクセス制御を管理できます。

ジャンプ先:ID 統合の要件の決定 | クラウド ベースライン | ディレクトリ同期 | クラウドでホストされるドメイン サービス | Active Directory フェデレーション サービス | 詳細情報

クラウド環境で ID を管理するためのオプションがいくつかあります。 これらのオプションは、コストと複雑さによって異なります。 クラウド ベースの ID サービスを構築する際の重要な要素は、既存のオンプレミス ID インフラストラクチャで必要とされる統合のレベルです。

Microsoft Entra ID には Azure リソースのための基本レベルのアクセス制御と ID 管理が用意されています。 組織のオンプレミスの Active Directory インフラストラクチャが複雑なフォレスト構造やカスタマイズされた組織単位 (OU) を持っている場合、クラウドベースのワークロードには、オンプレミス環境とクラウド環境の間の一貫性のある ID、グループ、およびロールのセットのために、Microsoft Entra ID を使用したディレクトリ同期が必要となる場合があります。 さらに、レガシ認証メカニズムに依存しているアプリケーションをサポートするために、クラウドへの Active Directory Domain Services (AD DS) のデプロイが必要になる場合もあります。

クラウドベースの ID 管理は反復的なプロセスです。 最初のデプロイは、クラウドネイティブ ソリューションを使用して、ユーザーと対応するロールの少数のセットで開始できます。 移行が進むにつれて、ディレクトリ同期を使用した ID ソリューションの統合や、クラウドへのデプロイの一部としてのドメイン サービスの追加が必要になる場合があります。 移行プロセスを繰り返すたびに、ID 戦略を見直してください。

ID 統合の要件の決定

Question	クラウド ベースライン	ディレクトリ同期	クラウドでホストされたドメイン サービス	Active Directory フェデレーション サービス (AD FS)
現在、オンプレミス ディレクトリ サービスがない	はい	番号	番号	いいえ
ワークロードがクラウド環境とオンプレミス環境の間で共通のユーザーおよびグループのセットを使用する必要がある	いいえ	イエス	番号	いいえ
ワークロードがレガシ認証メカニズム (Kerberos や NTLM など) に依存している	いいえ	番号	イエス	はい
複数の ID プロバイダーにわたってシングル サインオンが必要である	いいえ	番号	番号	はい

Azure への移行を計画する際には、既存の ID 管理とクラウド ID サービスを最適に統合する方法を決定する必要があります。 一般的な統合シナリオを以下に示します。

クラウド ベースライン

Microsoft Entra ID は、ユーザーとグループに Azure プラットフォーム上の管理機能へのアクセス許可を付与するための、ネイティブの ID およびアクセス管理 (IAM) システムです。 組織に有効なオンプレミス ID ソリューションがなく、クラウドベースの認証メカニズムとの互換性を持たせるためにワークロードの移行を計画している場合、Microsoft Entra ID をベースとして使用する ID インフラストラクチャの開発を開始する必要があります。

クラウドでのベースラインの前提条件: 完全にクラウドネイティブな ID インフラストラクチャを使用するには、次の事項が前提となります。

• クラウドベースのリソースは、オンプレミス ディレクトリ サービスや Active Directory サーバーに従属しないこと。または、そのような従属性を取り除くためにワークロードを変更できること。
• 移行するアプリケーションまたはサービスのワークロードが Microsoft Entra ID と互換性のある認証メカニズムをサポートしているか、そのようなメカニズムをサポートするために容易に変更可能であること。 Microsoft Entra ID は、SAML、OAuth、OpenID Connect などのインターネット対応の認証メカニズムに依存しています。 Kerberos や NTLM などのプロトコルを使用するレガシ認証方法に依存する既存のワークロードは、クラウドに移行する前に、クラウドのベースライン パターンを使用してリファクタリングしなければならない場合があります。

ヒント

ID サービスを Microsoft Entra ID に完全に移行することで、独自の ID インフラストラクチャを維持する必要がなくなり、IT 管理が大幅に簡素化されます。

ただし、Microsoft Entra ID は従来のオンプレミスの Active Directory インフラストラクチャに完全に置き換わるものではありません。 レガシ認証方法、コンピューター管理、グループ ポリシーなどのディレクトリ機能は、クラウドに追加のツールやサービスをデプロイしないと利用できません。

オンプレミスの ID またはドメイン サービスをクラウドのデプロイと統合する必要があるシナリオの場合、以下で説明するディレクトリ同期およびクラウドでホストされるドメイン サービスのパターンを参照してください。

ディレクトリ同期

多くの場合、既存のオンプレミス Active Directory インフラストラクチャを持つ組織においては、既存のユーザーとアクセス管理を保持すると同時に、クラウド リソースの管理に必要な IAM 機能を提供するためには、ディレクトリ同期が最適なソリューションです。 このプロセスは、Microsoft Entra ID とオンプレミスのディレクトリ サービスの間でディレクトリ情報を継続的にレプリケートし、組織全体にわたるユーザーの共通資格情報と、一貫性のある ID、ロール、アクセス許可のシステムを可能にします。

Note

Microsoft 365 を導入済みの組織では、オンプレミスの Active Directory インフラストラクチャと Microsoft Entra ID の間にディレクトリ同期を既に実装している場合があります。

ディレクトリ同期の前提条件: 同期済み ID ソリューションを使用するには、次の事項が前提となります。

• クラウドとオンプレミスの IT インフラストラクチャ全体で、ユーザー アカウントとグループの共通セットを保持する必要がある。
• オンプレミス ID サービスが Microsoft Entra ID を使用したレプリケーションをサポートしていること。

ヒント

オンプレミスの Active Directory サーバーによって提供され、Microsoft Entra ID によってサポートされていないレガシ認証メカニズムに依存するすべてのクラウドベース ワークロードでは、これらのサービスを提供するオンプレミス ドメイン サービスまたはクラウド環境内の仮想サーバーのいずれかへの接続が引き続き必要となります。 オンプレミス ID サービスを使用すると、クラウド ネットワークとオンプレミス ネットワーク間の接続性にも依存します。

クラウドでホストされたドメイン サービス

Kerberos や NTLM などの従来のプロトコルを使用する要求ベースの認証に依存するワークロードがあり、SAML や OAuth、OpenID Connect などの最新の認証プロトコルを許可するようにそれらのワークロードをリファクタリングできない場合、クラウドをデプロイする際に、一部のドメイン サービスをクラウドに移行しなければならない場合があります。

このパターンでは、クラウド上のリソース用の Active Directory Domain Services (AD DS) を提供するために、Active Directory を実行する仮想マシンをクラウドベース仮想ネットワークにデプロイすることが必要になります。 クラウド ネットワークに移行する既存のすべてのアプリケーションとサービスは、マイナーな変更によって、これらのクラウドでホストされたディレクトリ サーバーを使用できるようにする必要があります。

既存のディレクトリとドメイン サービスは、オンプレミス環境で引き続き使用される場合が多いと思われます。 そのようなシナリオでは、クラウド環境とオンプレミス環境の両方で共通のユーザーとロールを提供するために、ディレクトリ同期も使用する必要があります。

クラウドでホストされるドメイン サービスの前提条件: ディレクトリの移行を実行するには、次の事項が前提となります。

• ワークロードが Kerberos や NTLM などのプロトコルを使用する要求ベース認証に依存している。
• Active Directory グループ ポリシーの管理または利用のために、ワークロード仮想マシンをドメインに参加させる必要がある。

ヒント

クラウドでホストされたドメイン サービスを伴うディレクトリ移行では、既存のワークロードの移行において優れた柔軟性がありますが、これらのサービスを提供するためにクラウド仮想ネットワーク内に仮想マシンをホストすることにより、IT 管理タスクが複雑化します。 クラウド移行に慣れてきたら、これらのサーバーをホスティングする長期的なメンテナンスの要件を確認します。 Microsoft Entra ID などのクラウド ID プロバイダーとの互換性のために既存のワークロードをリファクタリングすることで、これらのクラウドでホストされているサーバーの必要性を削減することが可能かどうかを検討します。

Active Directory フェデレーション サービス (AD FS)

ID フェデレーションは、複数の ID 管理システムにわたって信頼関係を確立し、共通の認証機能と許可機能を可能にします。 これにより、組織内の複数のドメインや、お客様またはビジネス パートナーによって管理される ID システム全体でシングル サインオン機能をサポートできるようになります。

Microsoft Entra ID は、Active Directory フェデレーション サービス (AD FS) を使用するオンプレミスの Active Directory ドメインのフェデレーションをサポートしています。 これを Azure に実装する方法の詳細については、「AD FS を Azure に拡張する」を参照してください。

詳細情報

Azure での ID サービスの詳細については、以下を参照してください。

• Microsoft Entra ID。 Microsoft Entra ID は、クラウドベースの ID サービスを提供します。 Azure リソースへのアクセスの管理と、ID 管理、デバイス登録、ユーザー プロビジョニング、アプリケーション アクセス制御、およびデータ保護の制御を可能にします。
• Microsoft Entra Connect。 Microsoft Entra Connect ツールを使用すると、Microsoft Entra インスタンスを既存の ID 管理ソリューションと接続できるようになり、クラウド上の既存ディレクトリの同期が可能になります。
• Azure ロールベースのアクセス制御 (Azure RBAC)。 Azure RBAC では、管理プレーン内のリソースへのアクセスを効果的かつ安全に管理します。 ジョブと責任はロールに編成され、ユーザーにはこれらのロールが割り当てられます。 Azure RBAC により、リソースへアクセス可能なユーザーと、そのリソースに実行可能なアクションを制御できます。
• Microsoft Entra Privileged Identity Management (PIM)。 PIM は、リソース アクセス特権の露出時間を短縮し、レポートとアラートを介して特権の使用への可視性を高めます。 ユーザーを Just-In-Time 特権に制限し、期間限定で特権を割り当て、その特権を自動的に取り消します。
• オンプレミスの Active Directory ドメインを Microsoft Entra ID と統合する。 この参照アーキテクチャは、オンプレミスの Active Directory ドメインと Microsoft Entra ID の間のディレクトリ同期の例を示しています。
• Active Directory Domain Services (AD DS) を Azure に拡張する。 この参照アーキテクチャでは、ドメイン サービスをクラウドベース リソースに拡張するために AD DS サーバーをデプロイする例を示します。
• Active Directory フェデレーション サービス (AD FS) を Azure に拡張する。 この参照アーキテクチャは、Microsoft Entra ディレクトリを使用したフェデレーション認証と認可を実行するために Active Directory フェデレーション サービス (AD FS) を構成します。

次のステップ

ID は、クラウド導入プロセスでのアーキテクチャに関する意思決定で要求されるコア インストラクチャ コンポーネントの 1 つにすぎません。 他の種類のインフラストラクチャの設計に関する決定を行うときに使用される代替パターンまたはモデルについては、アーキテクチャの決定ガイドの概要を参照してください。

アーキテクチャの決定ガイドの概要