Azure リソース管理の基礎
Azure リソースに固有の構造と用語を理解することが重要です。 次の図は、Azure によって提供されるスコープの 4 つのレベルの例を示しています。
用語
理解しておくべきいくつかの用語を次に示します。
リソース - Azure を通じて使用できる管理可能な項目です。 リソースの例として、仮想マシン、ストレージ アカウント、Web アプリ、データベース、および仮想ネットワークがあります。
リソース グループ - 特定のチームによる管理を必要とする仮想マシン、関連付けられた VNet、ロード バランサーのコレクションなど、Azure ソリューションの関連リソースを保持するコンテナー。 リソース グループには、グループとして管理するリソースが含まれます。 組織にとって最も有用になるように、どのリソースをリソース グループに含めるかを決定します。 またリソース グループは、有効期間が同じすべてのリソースを一度に削除することで、ライフサイクル管理に役立てるように使用することもできます。 このアプローチには、悪用される可能性のあるフラグメントを残さないことによるセキュリティ上の利点もあります。
サブスクリプション - 組織階層の観点から見ると、サブスクリプションはリソースとリソース グループの課金と管理のコンテナーです。 Azure サブスクリプションには、Microsoft Entra ID との信頼関係があります。 サブスクリプションでは、Microsoft Entra ID を信頼して、ユーザー、サービス、デバイスの認証が行われます。
Note
サブスクリプションでは、1 つの Microsoft Entra テナントのみを信頼できます。 ただし、各テナントは複数のサブスクリプションを信頼する場合があり、サブスクリプションをテナント間で移動することができます。
管理グループ - Azure 管理グループでは、サブスクリプションの上のさまざまなスコープで、ポリシーとコンプライアンスを適用する階層的な方法が提供されます。 これは、テナント ルート管理グループ (最高のスコープ) または階層内の下位レベルにすることができます。 "管理グループ" と呼ばれるコンテナーにサブスクリプションを整理して、管理グループに管理条件を適用できます。 管理グループ内のすべてのサブスクリプションは、管理グループに適用された条件を自動的に継承します。 ポリシー定義は、管理グループまたはサブスクリプションに適用できます。
リソース プロバイダー - Azure リソースを提供するサービス。 たとえば、一般的なリソース プロバイダーは Microsoft です。 Compute は、仮想マシン リソースを提供します。 Microsoft. Storage は、もう 1 つの一般的なリソースプロバイダーです。
Resource Manager テンプレート - リソース グループ、サブスクリプション、テナント、または管理グループにデプロイする 1 つまたは複数のリソースを定義する JavaScript Object Notation (JSON) ファイル。 このテンプレートを使えば、リソースを一貫して繰り返しデプロイできます。 テンプレートのデプロイの概要に関するページを参照してください。 さらに、JSON の代わりに Bicep 言語を使用できます。
Azure リソース管理モデル
それぞれの Azure サブスクリプションは、Azure Resource Manager によって使用される制御に関連付けられています。 Resource Manager は Azure のデプロイおよび管理サービスであり、組織の ID 管理については Microsoft Entra ID と、個人については Microsoft アカウント (MSA) と、信頼関係を持っています。 Resource Manager には、Azure サブスクリプションのリソースを作成、更新、削除できる管理レイヤーが用意されています。 アクセス制御、ロック、タグなどの管理機能を使用して、デプロイ後にリソースをセキュリティ保護および整理します。
注意
ARM 以前に、Azure Service Manager (ASM) または "クラシック" という名前の別のデプロイ モデルが存在していました。 詳細については、「Azure Resource Manager とクラシック デプロイ」を参照してください。 ASM モデルを使用した環境の管理は、このコンテンツの範囲外です。
Azure Resource Manager は、PowerShell、Azure portal、またはリソースを管理するためのその他のクライアントによって使用される REST API をホストする、フロントエンド サービスです。 クライアントが特定のリソースを管理するように要求すると、Resource Manager は要求を完了するために、要求をリソース プロバイダーにプロキシ処理します。 たとえば、クライアントが仮想マシン リソースを管理するように要求した場合、Resource Manager は要求を Microsoft. Compute リソース プロバイダーにプロキシ処理します。 Resource Manager は仮想マシン リソースを管理するために、サブスクリプションとリソース グループの両方の識別子を指定するようクライアントに要求します。
Resource Manager によってリソースの管理要求が実行される前に、一連の制御がチェックされます。
有効なユーザー チェック - リソースの管理を要求するユーザーは、マネージド リソースのサブスクリプションに関連付けられている Microsoft Entra ID テナント内のアカウントを持っている必要があります。
ユーザー アクセス許可チェック - ロールベースのアクセス制御 (RBAC) を使用して、アクセス許可がユーザーに割り当てられます。 RBAC ロールでは、特定のリソースに対してユーザーが適用できる一連のアクセス許可が指定されます。 RBAC は、Azure のリソースにアクセスできるユーザー、そのユーザーがそれらのリソースに対して実行できること、そのユーザーがアクセスできる領域を管理するのに役立ちます。
Azure ポリシー チェック - Azure ポリシーでは、特定のリソースに対して許可または明示的に拒否される操作が指定されます。 たとえば、ポリシーを使用して、ユーザーが特定の種類の仮想マシンのみデプロイできる (またはできない) ように指定できます。
次の図は、先ほど説明したリソース モデルをまとめたものです。
Azure Lighthouse - Azure Lighthouse を使用すると、テナント間でのリソース管理が可能になります。 組織は、サブスクリプションまたはリソース グループ レベルのロールを別のテナントの ID に委任できます。
Azure Lighthouse で委任されたリソース管理を有効にするサブスクリプションには、サブスクリプションまたはリソース グループを管理できるテナント ID を示す属性と、リソース テナントの組み込み RBAC ロールとサービス プロバイダー テナント内の ID とのマッピングを示す属性があります。 実行時に、Azure Resource Manager ではこれらの属性を使用して、サービス プロバイダー テナントからのトークンを承認します。
Azure Lighthouse 自体が Azure リソース プロバイダーとしてモデル化されていることに注意してください。つまり、Azure ポリシーによって、テナントをまたぐ委任の側面を対象にすることができます。
Microsoft 365 Lighthouse - Microsoft 365 Lighthouse は、Microsoft 365 Business Premium、Microsoft 365 E3、または Windows 365 Business を使っている中小規模企業 (SMB) の顧客向けに、デバイス、データ、ユーザーを大規模にセキュリティで保護して管理する、マネージド サービス プロバイダー (MSP) を支援するための管理ポータルです。
Microsoft Entra ID を使用した Azure リソース管理
Azure のリソース管理モデルについて深く理解できたので、次に Azure リソースの ID とアクセス管理を提供できる Microsoft Entra ID の機能をいくつか簡単に見てみましょう。
請求
一部の課金ロールでは、リソースを操作したりリソースを管理したりできるため、課金はリソース管理にとって重要です。 課金は、Microsoft との契約の種類によって動作が異なります。
Azure Enterprise Agreement
Azure Enterprise Agreement (Azure EA) のお客様は、Microsoft との商用契約の実行時に Azure EA Portal にオンボードされます。 オンボード時に、ID は "ルート" エンタープライズ管理者の課金ロールに関連付けられます。 ポータルには、管理機能の階層が用意されています。
部門は、コストを論理グループに分割し、部門レベルで予算またはクォータを設定するのに役立ちます。
アカウントは、部門をさらにセグメント化するために使用されます。 アカウントを使用して、サブスクリプションを管理し、レポートにアクセスできます。 EA ポータルでは、Microsoft アカウント (MSA) または Microsoft Entra アカウント (ポータルで "職場または学校アカウント" として識別される) を承認できます。 EA ポータルで "アカウント所有者" のロールを持つ ID によって、Azure サブスクリプションを作成できます。
エンタープライズ課金と Microsoft Entra テナント
アカウント所有者がエンタープライズ契約内で Azure サブスクリプションを作成すると、サブスクリプションの ID とアクセス管理は次のように構成されます。
Azure サブスクリプションは、アカウント所有者と同じ Microsoft Entra テナントに関連付けられます。
サブスクリプションを作成したアカウント所有者には、サービス管理者ロールとアカウント管理者ロールが割り当てられます。 (Azure EA Portal では、サブスクリプションを管理するために Azure Service Manager (ASM) ロールまたは "クラシック" ロールが割り当てられます。 詳細については、「Azure Resource Manager とクラシック デプロイ」を参照してください。
Azure EA Portal で認証の種類として "テナント間の職場または学校アカウント" を設定することで、複数のテナントをサポートするようにエンタープライズ契約を構成できます。 上記の場合、組織は次の図に示すように、テナントごとに複数のアカウントを設定し、アカウントごとに複数のサブスクリプションを設定できます。
上で説明した既定の構成では、作成したすべてのサブスクリプションのリソースを管理するための Azure EA アカウント所有者特権が付与されることに注意してください。 運用ワークロードを保持しているサブスクリプションの場合は、作成直後にサブスクリプションのサービス管理者を変更して、課金とリソース管理を分離することを検討してください。
アカウント所有者をさらに分離し、サブスクリプションへのサービス管理者アクセス権を回復できないようにするために、作成後にサブスクリプションのテナントを変更できます。 サブスクリプションの移動先の Microsoft Entra テナント内に、アカウント所有者がユーザー オブジェクトを持っていない場合、サービス所有者ロールを回復できません。
詳細については、従来のサブスクリプション管理者ロール、Azure ロール、および Microsoft Entra ロールに関する記事を参照してください。
Microsoft 顧客契約
Microsoft 顧客契約 (MCA) に登録された顧客には、独自のロールを持つ異なる課金管理システムがあります。
Microsoft 顧客契約の請求先アカウントには、請求書および支払方法を管理できるようにする 1 つまたは複数の課金プロファイルが含まれています。 各課金プロファイルには、課金プロファイルの請求書上でコストを整理するための、1 つまたは複数の請求書セクションが含まれています。
Microsoft 顧客契約では、課金ロールは 1 つの Microsoft Entra テナントから取得されます。 複数のテナントのサブスクリプションをプロビジョニングするには、最初に MCA と同じ Microsoft Entra テナントにサブスクリプションを作成し、その後に変更する必要があります。 次の図では、企業の IT 部門の運用前環境のサブスクリプションは、作成後に ContosoSandbox テナントに移動されました。
Azure での RBAC とロールの割り当て
「Microsoft Entra の基礎」セクションでは、Azure RBAC が Azure リソースへのきめ細かなアクセス管理を提供し、多くの組み込みロールを含む認可システムであることを学習しました。 カスタム ロールを作成し、さまざまなスコープでロールを割り当てることができます。 アクセス許可は、Azure リソースへのアクセスを要求するオブジェクトに RBAC ロールを割り当てることによって適用されます。
Microsoft Entra ロールは、Azure のロールベースのアクセス制御に似た概念で動作します。 これら 2 つのロールベースのアクセス制御システムの違いは、Azure RBAC では、Azure Resource Management を使用して仮想マシンやストレージなどの Azure リソースへのアクセスが制御されるのに対し、Microsoft Entra ロールでは、Microsoft Entra ID、アプリケーション、Office 365 などの Microsoft サービスへのアクセスが制御されることです。
Microsoft Entra ロールと Azure RBAC ロールの両方が Microsoft Entra Privileged Identity Management と統合され、承認ワークフローや MFA などの Just-In-Time アクティブ化ポリシーが有効になります。
Azure での ABAC とロールの割り当て
属性ベースのアクセス制御 (ABAC) は、セキュリティ プリンシパル、リソース、環境に関連付けられている属性に基づいてアクセスを定義する認可システムです。 ABAC を使用すると、属性に基づいてセキュリティ プリンシパルにリソースへのアクセス権を付与できます。 Azure ABAC は、Azure 向けに実装された ABAC を指します。
Azure ABAC は、Azure RBAC を基盤としたものであり、特定のアクションのコンテキストにおける属性に基づいたロールの割り当て条件を追加することにより構築されます。 ロールの割り当て条件は、ロールの割り当てに追加することによってさらにきめ細かなアクセス制御を可能にする確認のしくみの 1 つです。 条件は、ロールの定義とロールの割り当ての一環として付与されたアクセス許可を絞り込むものです。 たとえば、特定のタグが設定されたオブジェクトしか読み取れない、という条件を設定できます。 条件を使用して特定のリソースに対するアクセスを明示的に拒否することはできません。
条件付きアクセス
Microsoft Entra の 条件付きアクセスを使用して、Azure 管理エンドポイントへのアクセスを管理できます。 条件付きアクセス ポリシーを Windows Azure Service Management API クラウド アプリに適用して、次のような Azure リソース管理エンドポイントを保護できます。
Azure Resource Manager プロバイダー (サービス)
Azure Resource Manager API
Azure PowerShell
Azure CLI
Azure portal
たとえば、管理者は条件付きアクセス ポリシーを構成できます。これにより、ユーザーは承認済みの場所からのみ Azure portal にサインインでき、多要素認証 (MFA) またはハイブリッド Microsoft Entra ドメイン参加済みデバイスも必要になります。
Azure マネージド ID
クラウド アプリケーションの構築時における一般的な課題は、クラウド サービスへの認証用のコードで資格情報をどのように管理するかです。 資格情報を安全に保つことは重要な課題です。 資格情報は開発者のワークステーションに表示されないこと、またソース管理にチェックインされないことが理想です。 Azure リソースのマネージド ID は、Microsoft Entra ID で自動的に管理される ID を Azure サービスに提供します。 その ID を使用して、コードで資格情報を渡すことなく Microsoft Entra 認証をサポートするすべてのサービスに対して認証します。
マネージド ID には、次の 2 種類があります。
システム割り当てマネージド ID は、Azure リソース上で直接有効にされます。 リソースが有効になると、Azure によって、関連付けられているサブスクリプションの信頼された Microsoft Entra テナントに、リソースの ID が作成されます。 ID が作成されると、その資格情報がリソースにプロビジョニングされます。 システム割り当て ID のライフサイクルは、Azure リソースに直接関連付けられます。 リソースが削除された場合、Azure は Microsoft Entra ID の資格情報および ID を自動的にクリーンアップします。
ユーザー割り当てマネージド ID は、スタンドアロン Azure リソースとして作成されます。 Azure では、リソースが関連付けられているサブスクリプションによって信頼される Microsoft Entra テナントに ID が作成されます。 作成された ID は、1 つまたは複数の Azure リソースに割り当てることができます。 ユーザー割り当て ID のライフサイクルは、その ID が割り当てられている Azure リソースのライフサイクルとは別々に管理されます。
内部的には、マネージド ID は特別な種類のサービス プリンシパルであり、特定の Azure リソースによってのみ使用されます。 マネージド ID が削除されると、対応するサービス プリンシパルが自動的に削除されます。 Graph API アクセス許可の承認は PowerShell でのみ実行できるため、ポータル UI を介してマネージド ID のすべての機能にアクセスできるわけではありません。
Microsoft Entra Domain Services
Microsoft Entra Domain Services には、レガシ プロトコルを使用した Azure ワークロードの認証を容易にするマネージド ドメインが用意されています。 サポートされているサーバーは、オンプレミスの AD DS フォレストから移動され、Microsoft Entra Domain Services マネージド ドメインに参加し、認証 (Kerberos 認証など) にレガシ プロトコルを引き続き使用します。
Azure AD B2C ディレクトリと Azure
Azure AD B2C テナントは、課金と通信の目的で Azure サブスクリプションにリンクされています。 Azure AD B2C テナントは、Azure サブスクリプションの Azure RBAC 特権ロールとは独立した、ディレクトリ内の自己完結型ロール構造を持ちます。
Azure AD B2C テナントが最初にプロビジョニングされるとき、B2C テナントを作成するユーザーには、サブスクリプションの共同作成者または所有者のアクセス許可が必要です。 作成すると、そのユーザーは最初の Azure AD B2C テナント グローバル管理者になり、後で他のアカウントを作成してそれらをディレクトリ ロールに割り当てることができます。
リンクされた Microsoft Entra サブスクリプションの所有者と共同作成者は、サブスクリプションとディレクトリ間のリンクを削除できることに注意してください。これは、Azure AD B2C の使用状況の継続的な課金に影響します。
Azure での IaaS ソリューションの ID に関する考慮事項
このシナリオでは、サービスとしてのインフラストラクチャ (IaaS) ワークロードに対して組織が持っている ID 分離要件について説明します。
IaaS ワークロードの分離管理には、次の 3 つの主要なオプションがあります。
スタンドアロンの Active Directory Domain Services (AD DS) に参加している仮想マシン
Microsoft Entra Domain Services 参加済み仮想マシン
Microsoft Entra 認証を使用して Azure の仮想マシンにサインインする
最初の 2 つのオプションで対処する重要な概念は、これらのシナリオには 2 つの ID 領域が関連しているということです。
リモート デスクトップ プロトコル (RDP) を使用して Azure Windows Server VM にサインインする場合、通常はドメイン資格情報を使用してサーバーにログオンし、これによってオンプレミスの AD DS ドメイン コントローラーまたは Microsoft Entra Domain Services に対して Kerberos 認証が実行されます。 あるいは、サーバーがドメイン参加済みでない場合、ローカル アカウントを使用して仮想マシンにサインインできます。
VM を作成または管理するために Azure portal にサインインすると、Microsoft Entra ID に対して認証が行われます (正しいアカウントを同期している場合は、同じ資格情報を使用する可能性があります)。Active Directory フェデレーション サービス (AD FS) 認証またはパススルー認証を使用している場合、これは結果として、ドメイン コントローラーに対する認証となる可能性があります。
スタンドアロンの Active Directory Domain Services に参加している仮想マシン
AD DS は、組織がオンプレミスの ID サービスに広く採用している Windows Server ベースのディレクトリ サービスです。 AD DS は、IaaS ワークロードを Azure にデプロイする要件が存在し、それによって別のフォレストの AD DS 管理者とユーザーからの ID の分離が必要な場合にデプロイできます。
このシナリオでは、次の事項を考慮する必要があります。
AD DS ドメイン コントローラー: 認証サービスの高可用性と高パフォーマンスを保証するには、少なくとも 2 つの AD DS ドメイン コントローラーをデプロイする必要があります。 詳細については、「AD DS の設計と計画」を参照してください。
AD DS の設計と計画 - 次のサービスが正しく構成された新しい AD DS フォレストを作成する必要があります。
AD DS ドメイン ネーム サービス (DNS) - サーバーとアプリケーションで名前解決が正しく動作するように、AD DS 内の関連ゾーンに対して AD DS DNS を構成する必要があります。
AD DS のサイトとサービス - これらのサービスは、アプリケーションの低待機時間と、ドメイン コントローラーに対する高パフォーマンスのアクセスを確保するように構成する必要があります。 関連する仮想ネットワーク、サブネット、サーバーが配置されているデータ センターの場所は、サイトとサービスで構成する必要があります。
AD DS FSMO - 必要なフレキシブル シングル マスター操作 (FSMO) ロールを確認し、適切な AD DS ドメイン コントローラーに割り当てる必要があります。
AD DS ドメイン参加 - 認証、構成、管理に AD DS を必要とするすべてのサーバー ("ジャンプボックス" を除く) を分離フォレストに参加させる必要があります。
AD DS グループ ポリシー (GPO) - 構成がセキュリティ要件を満たしていること、および構成がフォレストとドメイン参加済みマシン全体で標準化されるように、AD DS GPO を構成する必要があります。
AD DS 組織単位 (OU) - 構成の管理と適用を目的として、AD DS リソースを論理的な管理および構成のサイロにグループ化するには、AD DS OU を定義する必要があります。
ロールベースのアクセス制御 - このフォレストに参加しているリソースの管理とアクセスのために RBAC を定義する必要があります。 これには次のものが含まれます
AD DS グループ - AD DS リソースに対するユーザーの適切なアクセス許可を適用するには、グループを作成する必要があります。
管理アカウント - このセクションの冒頭で説明したように、このソリューションを管理するには 2 つの管理アカウントが必要です。
AD DS およびドメイン参加済みサーバーで必要な管理を実行するために必要な最小限の特権アクセスを持つ AD DS 管理アカウント。
仮想マシン、VNet、ネットワーク セキュリティ グループ、その他の必要な Azure リソースに接続し、管理し、構成するための Azure portal アクセス用の Microsoft Entra 管理アカウント。
AD DS ユーザー アカウント - このソリューションでホストされているアプリケーションへのユーザー アクセスを許可するには、関連するユーザー アカウントをプロビジョニングし、正しいグループに追加する必要があります。
仮想ネットワーク (VNet) - 構成ガイダンス
AD DS ドメイン コントローラーの IP アドレス - ドメイン コントローラーは、オペレーティング システム内の静的 IP アドレスで構成しないでください。 IP アドレスは、常に同じに保たれ、DHCP を使用するように DC を構成する必要があるため、Azure VNet 上で予約する必要があります。
VNet DNS サーバー - この分離ソリューションの一部である VNet 上に DNS サーバーを構成して、ドメイン コントローラーを指す必要があります。 これはアプリケーションとサーバーが、必要な AD DS サービスまたは AD DS フォレストに参加しているその他のサービスを解決できるようにするために必要です。
ネットワーク セキュリティ グループ (NSG) - ドメイン コントローラーは、必要なサーバー (ドメイン参加済みのマシンやジャンプボックスなど) からのドメイン コントローラーへのアクセスのみを許可するように定義された NSG を使用して、独自の VNet またはサブネットに配置する必要があります。 NSG の作成と管理を簡略化するには、アプリケーション セキュリティ グループ (ASG) にジャンプボックスを追加する必要があります。
課題: 以下の一覧では、ID の分離にこのオプションを使用する際の主な課題を示します。
運用、管理、監視する AD DS フォレストが追加されることで、IT チームの作業が増えます。
修正プログラムの適用とソフトウェアのデプロイを管理するために、追加のインフラストラクチャが必要になる場合があります。 組織では、これらのサーバーを管理するために、Azure Update Management、グループ ポリシー (GPO) または System Center Configuration Manager (SCCM) のデプロイを検討する必要があります。
ユーザーがリソースにアクセスするために覚えて使用する追加の資格情報。
重要
この分離モデルでは、顧客の企業ネットワークからのドメイン コントローラーとの間に接続がなく、他のフォレストとの信頼が構成されていないことが前提になります。 AD DS ドメイン コントローラーを管理および運用できるポイントを許可するには、ジャンプボックスまたは管理サーバーを作成する必要があります。
Microsoft Entra Domain Services 参加済み仮想マシン
IaaS ワークロードを Azure にデプロイする要件が存在し、それによって別のフォレストの AD DS 管理者とユーザーからの ID 分離が必要な場合、Microsoft Entra Domain Services マネージド ドメインをデプロイできます。 Microsoft Entra Domain Services は、レガシ プロトコルを使用した Azure ワークロードの認証を容易にするマネージド ドメインが用意されているサービスです。 これにより、独自の AD DS を構築して管理する技術的な複雑さに頼ることなく、分離されたドメインが提供されます。 次の事項を考慮する必要があります。
Microsoft Entra Domain Services マネージド ドメイン - Microsoft Entra テナントごとにデプロイできる Microsoft Entra Domain Services マネージド ドメインは 1 つだけで、これは 1 つの VNet にバインドされます。 この VNet が Microsoft Entra Domain Services 認証の "ハブ" を形成するようにすることをお勧めします。 このハブから、"スポーク" を作成してリンクし、サーバーとアプリケーションのレガシ認証を許可できます。 スポークは、Microsoft Entra Domain Services 参加済みサーバーが配置され、Azure ネットワーク ゲートウェイまたは VNet ピアリングを使用してハブにリンクされる追加の VNet です。
マネージド ドメインの場所 - Microsoft Entra Domain Services マネージド ドメインをデプロイするときは、場所を設定する必要があります。 場所は、マネージド ドメインがデプロイされる物理リージョン (データ センター) です。 次のようにすることをお勧めします。
Microsoft Entra Domain Services サービスを必要とするサーバーとアプリケーションに対して地理的に閉じられている場所を検討してください。
高可用性要件のための Availability Zones 機能を提供するリージョンを検討してください。 詳細については、「Azure のリージョンと Availability Zones」をご覧ください。
オブジェクトのプロビジョニング - Microsoft Entra Domain Services は、Microsoft Entra Domain Services がデプロイされているサブスクリプションに関連付けられている Microsoft Entra ID から ID を同期します。 また、関連付けられている Microsoft Entra ID に Microsoft Entra Connect との同期が設定されている場合 (ユーザー フォレスト シナリオ)、これらの ID のライフサイクルも Microsoft Entra Domain Services に反映される可能性があることにも注目してください。 このサービスには、Microsoft Entra ID からユーザー オブジェクトとグループ オブジェクトをプロビジョニングするために使用できる 2 つのモードがあります。
すべて: すべてのユーザーとグループは、Microsoft Entra ID から Microsoft Entra Domain Services に同期されます。
スコープ付き: グループのスコープ内のユーザーのみが Microsoft Entra ID から Microsoft Entra Domain Services に同期されます。
Microsoft Entra Domain Services を初めてデプロイするとき、Microsoft Entra ID からオブジェクトをレプリケートするための一方向の自動同期が構成されます。 この一方向の同期は引き続きバックグラウンドで実行され、Microsoft Entra ID からの変更を反映して Microsoft Entra Domain Services マネージド ドメインを最新の状態に保ちます。 Microsoft Entra Domain Services から Microsoft Entra ID への同期は行われません。 詳細については、「Microsoft Entra Domain Services のマネージド ドメイン内でのオブジェクトと資格情報の同期のしくみ」を参照してください。
同期の種類を [すべて] から [スコープ付き] (またはその逆) に変更する必要がある場合は、Microsoft Entra Domain Services マネージド ドメインを削除、再作成、構成する必要があることに注意してください。 さらに組織では適切な慣行として、Microsoft Entra Domain Services リソースへのアクセスが必要なもののみに ID を減らすために、"スコープ付き" プロビジョニングの使用を検討する必要があります。
グループ ポリシー オブジェクト (GPO) - Microsoft Entra Domain Services マネージド ドメインで GPO を構成するには、Microsoft Entra Domain Services マネージド ドメインにドメイン参加しているサーバー上のグループ ポリシー管理ツールを使用する必要があります。 詳細については、「Microsoft Entra Domain Services のマネージド ドメインでグループ ポリシーを管理する」を参照してください。
Secure LDAP - Microsoft Entra Domain Services は、それを必要とするアプリケーションで使用できるセキュリティで保護された LDAP サービスを提供します。 この設定は既定で無効になっており、セキュリティで保護された LDAP を有効にするには、証明書をアップロードする必要があります。さらに、Microsoft Entra Domain Services がデプロイされている VNet をセキュリティで保護する NSG では、Microsoft Entra Domain Services マネージド ドメインへのポート 636 接続が許可される必要があります。 詳細については、Microsoft Entra Domain Services のマネージド ドメインに対するセキュリティで保護された LDAP の構成に関する記事を参照してください。
管理 - Microsoft Entra Domain Services で管理作業を実行するには (ドメイン参加マシンや GPO の編集など)、このタスクに使用されるアカウントが Microsoft Entra DC 管理者グループの一部である必要があります。 このグループのメンバーであるアカウントは、管理タスクを実行するためにドメイン コントローラーに直接サインインすることはできません。 代わりに、Microsoft Entra Domain Services マネージド ドメインに参加している管理 VM を作成してから、通常の AD DS 管理ツールをインストールします。 詳細については、Microsoft Entra Domain Services でのユーザー アカウント、パスワード、および管理の管理の概念に関する記事を参照してください。
パスワード ハッシュ - Microsoft Entra Domain Services での認証を機能させるには、すべてのユーザーのパスワード ハッシュが NT LAN Manager (NTLM) および Kerberos 認証に適した形式である必要があります。 Microsoft Entra Domain Services での認証が期待どおりに動作するようにするには、次の前提条件を実行する必要があります。
Microsoft Entra Connect と同期されたユーザー (AD DS から) - 従来のパスワード ハッシュを、オンプレミスの AD DS から Microsoft Entra ID に同期する必要があります。
Microsoft Entra ID で作成されたユーザー - Microsoft Entra Domain Services で使用するために正しいハッシュが生成されるようにパスワードをリセットする必要があります。 詳細については、「パスワード ハッシュの同期を有効にする」を参照してください。
ネットワーク - Microsoft Entra Domain Services は Azure VNet にデプロイされるため、サーバーとアプリケーションがセキュリティで保護され、マネージド ドメインに正しくアクセスできるように考慮する必要があります。 詳細については、Microsoft Entra Domain Services の仮想ネットワーク設計の考慮事項と構成オプションに関する記事を参照してください。
Microsoft Entra Domain Services を独自のサブネットにデプロイする必要がある: 既存のサブネットやゲートウェイ サブネットは使用しないでください。
ネットワーク セキュリティ グループ (NSG) - Microsoft Entra Domain Services マネージド ドメインのデプロイ時に作成されます。 このネットワーク セキュリティ グループには、サービス通信を正しく行うために必要な規則が含まれています。 独自のカスタム規則を持つ既存のネットワーク セキュリティ グループを作成または使用しないでください。
Microsoft Entra Domain Services には 3 から 5 個の IP アドレスが必要 - サブネットの IP アドレス範囲でこの数のアドレスを提供できることを確認してください。 使用可能な IP アドレスを制限すると、Microsoft Entra Domain Services で 2 つのドメイン コントローラーを維持できなくなる可能性があります。
VNet DNS サーバー - "ハブとスポーク" モデルについて既に説明したように、Microsoft Entra Domain Services マネージド ドメインに参加しているサーバーが Microsoft Entra Domain Services マネージド ドメインを解決するための正しい DNS 設定を持っているようにするために、VNet で DNS を正しく構成することが重要です。 各 VNet には、IP アドレスを取得する際にサーバーに渡される DNS サーバー エントリがあり、これらの DNS エントリは Microsoft Entra Domain Services マネージド ドメインの IP アドレスである必要があります。 詳しくは、「Azure 仮想ネットワークの DNS 設定を更新する」をご覧ください。
課題: 以下の一覧では、ID の分離にこのオプションを使用する際の主な課題を示します。
一部の Microsoft Entra Domain Services 構成は、Microsoft Entra Domain Services 参加済みサーバーからのみ管理できます。
Microsoft Entra テナントごとに展開できる Microsoft Entra Domain Services マネージド ドメインは 1 つだけです。 このセクションで説明するように、他の VNet 上のサービスに Microsoft Entra Domain Services 認証を提供するために、ハブ アンド スポーク モデルをお勧めします。
修正プログラムの適用とソフトウェアのデプロイを管理するために、追加のインフラストラクチャが必要になる場合があります。 組織では、これらのサーバーを管理するために、Azure Update Management、グループ ポリシー (GPO) または System Center Configuration Manager (SCCM) のデプロイを検討する必要があります。
この分離モデルでは、顧客の企業ネットワークから Microsoft Entra Domain Services マネージド ドメインをホストする VNet への接続がなく、他のフォレストとの信頼が構成されていないことが前提になります。 Microsoft Entra Domain Services を管理および運用できるポイントを許可するには、ジャンプボックスまたは管理サーバーを作成する必要があります。
Microsoft Entra 認証を使用して Azure の仮想マシンにサインインする
IaaS ワークロードを Azure にデプロイするための要件が存在し、それによって ID の分離が必要な場合、最後のオプションは、このシナリオのサーバーへのログオンに Microsoft Entra ID を使用することです。 これにより、Microsoft Entra ID を認証用の ID 領域にすることができ、必要な Microsoft Entra テナントにリンクされている、関連するサブスクリプションにサーバーをプロビジョニングすることで、ID の分離を実現できます。 次の事項を考慮する必要があります。
サポートされているオペレーティング システム: Microsoft Entra 認証を使用して Azure の仮想マシンにサインインすることは、Windows と Linux で現在サポートされています。 サポートされているオペレーティング システムの詳細については、Windows と Linux のドキュメントを参照してください。
資格情報: Microsoft Entra 認証を使用して Azure 内の仮想マシンにサインインする主な利点の 1 つは、仮想マシンへのサインインのために Microsoft Entra サービスへのアクセスに通常使用するのと同じフェデレーションまたはマネージド Microsoft Entra 資格情報を使用できることです。
Note
このシナリオでのサインインに使用される Microsoft Entra テナントは、仮想マシンがプロビジョニングされたサブスクリプションに関連付けられている Microsoft Entra テナントです。 この Microsoft Entra テナントは、オンプレミスの AD DS から同期された ID を持つものとすることができます。 組織では、これらのサーバーへのサインインに使用するサブスクリプションと Microsoft Entra テナントを選択する際に、自らの分離原則と整合の取れた、十分な情報を得たうえでの選択を行う必要があります。
ネットワーク要件: これらの仮想マシンは認証のために Microsoft Entra ID にアクセスする必要があるため、仮想マシンのネットワーク構成では Microsoft Entra エンドポイントへの送信アクセスが 443 で許可されるようにする必要があります。 詳細については、Windows と Linux のドキュメントを参照してください。
ロールベースのアクセス制御 (RBAC): これらの仮想マシンへの適切なレベルのアクセスを提供するために、2 つの RBAC ロールを使用できます。 これらの RBAC ロールは、Azure portal または Azure Cloud Shell エクスペリエンスを使用して構成できます。 詳細については、「仮想マシン ロールの割り当てを構成する」を参照してください。
仮想マシンの管理者ログオン: このロールを割り当てられたユーザーは、管理者特権を使用して Azure 仮想マシンにログインできます。
仮想マシンのユーザー ログオン: このロールを割り当てられたユーザーは、通常のユーザー特権を使用して Azure 仮想マシンにログインできます。
条件付きアクセス: Azure 仮想マシンへのサインインに Microsoft Entra ID を使用する主な利点は、サインイン プロセスの一環として条件付きアクセスを適用できることです。 これにより組織は、仮想マシンへのアクセスを許可する前に条件を満たすことを要求し、多要素認証を使用して強力な認証を提供することができます。 詳細については、「条件付きアクセスの使用」を参照してください。
Note
Microsoft Entra ID 参加済みの仮想マシンへのリモート接続は、Windows 10、Windows 11、および Cloud PC の PC からに限り許可されています。これらは仮想マシンと同じディレクトリに対して Microsoft Entra 参加済みまたは Microsoft Entra ハイブリッド参加済みを使用したものです。
課題: 以下の一覧では、ID の分離にこのオプションを使用する際の主な課題を示します。
サーバーの中央からの管理または構成はありません。 たとえば、サーバーのグループに適用できるグループ ポリシーはありません。 組織では、これらのサーバーの修正プログラムと更新プログラムを管理するために、Azure の Update Management をデプロイすることを検討する必要があります。
これらのサーバーまたはサービス全体で、Windows 統合認証などのオンプレミスのメカニズムで認証する要件がある多層アプリケーションには適していません。 これが組織の要件である場合は、スタンドアロンの Active Directory Domain Services、またはこのセクションで説明する Microsoft Entra Domain Services シナリオを確認することをお勧めします。
この分離モデルでは、顧客の企業ネットワークから、仮想マシンをホストする VNet への接続がないことを前提としています。 これらのサーバーを管理および運用できるポイントを許可するには、ジャンプボックスまたは管理サーバーを作成する必要があります。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示