Azure Stack Hub の ID プロバイダーの概要

[アーティクル]
11/23/2024

Azure Stack Hub には、Microsoft Entra ID、または ID プロバイダーとして Active Directory を使用する Active Directory フェデレーションサービス (AD FS) が必要です。プロバイダーの選択は、Azure Stack Hub を初めてデプロイするときに、一度だけ行います。この記事での概念と承認についての詳細情報は、ID プロバイダーの選択に役立ちます。

Microsoft Entra ID にするか AD FS にするかの選択は、Azure Stack Hub をデプロイするモードによって決まります。

接続モードでデプロイする場合は、Microsoft Entra ID と AD FS のどちらも使用できます。
インターネットに接続せずに切断モードでデプロイする場合は、AD FS のみがサポートされます。

Azure Stack Hub 環境に依存するオプションの詳細については、以下の記事を参照してください。

Azure Stack Hub 開発キット: 識別に関する考慮事項。
Azure Stack Hub 統合システム: Azure Stack Hub 統合システムのデプロイ計画の決定。

重要

Azure AD Graph は非推奨となり、2023 年 6 月 30 日に廃止される予定です。詳細については、こちらのセクションをご覧ください。

ID プロバイダーに関する一般的な概念

次のセクションでは、ID プロバイダーの一般的な概念と、Azure Stack Hub での使用について説明します。

ID プロバイダーに関する用語

ディレクトリテナントと組織

ディレクトリとは、ユーザー、アプリケーション、グループ、およびサービスプリンシパルに関する情報を保持するコンテナーのことです。

ディレクトリテナントとは、Microsoft や自分の会社のような、"組織" のことです。

Microsoft Entra ID では複数のテナントがサポートされており、複数の組織をそれぞれ独自のディレクトリでサポートすることができます。 Microsoft Entra ID を使用しており、複数のテナントがある場合、1 つのテナントのアプリとユーザーに、同じディレクトリの他のテナントへのアクセス権を付与できます。
AD FS では、単一のテナントのみがサポートされます。そのため、単一の組織のみがサポートされます。

ユーザーとグループ

ユーザーアカウント (ID) は、ユーザー ID とパスワードを使用して個人を認証する標準的なアカウントです。グループには、ユーザーまたは他のグループを含めることができます。

ユーザーとグループを作成および管理する方法は、使用する ID ソリューションによって異なります。

Azure Stack Hub では、ユーザーアカウントに次のような特徴があります。

username@domain の形式で作成されています。 AD FS はユーザーアカウントを Active Directory インスタンスにマッピングしますが、AD FS では "\<ドメイン>\<エイリアス>" 形式の使用がサポートされていません。
多要素認証を使用するようにセットアップすることができます。
最初に登録するディレクトリ、つまり組織のディレクトリに制限されています。
オンプレミスのディレクトリからインポートすることができます。詳細については、「 Microsoft Entra ID を使用してオンプレミスのディレクトリを統合するを参照してください。

組織のユーザーポータルにサインインするときは、https://portal.local.azurestack.external URL を使用します。 Azure Stack Hub の登録に使用したもの以外のドメインから Azure Stack Hub ポータルにサインインする場合は、Azure Stack Hub の登録に使用したドメイン名をポータルの URL に追加する必要があります。たとえば、Azure Stack Hub が fabrikam.onmicrosoft.com に登録されていて、ログインするユーザーアカウントが admin@contoso.com である場合、ユーザーポータルへのログインに使用する URL は https://portal.local.azurestack.external/fabrikam.onmicrosoft.com. になります。

ゲストユーザー

ゲストユーザーとは、あるディレクトリ内のリソースへのアクセスを許可されている、他のディレクトリテナントのユーザーアカウントのことです。ゲストユーザーをサポートするには、Microsoft Entra ID を使用し、マルチテナントのサポートを有効にします。サポートが有効になると、自社のディレクトリテナント内のリソースにアクセスするようにゲストユーザーを招待することができます。これにより、外部組織との共同作業が可能になります。

ゲストユーザーを招待するために、クラウドオペレーターとユーザーは Microsoft Entra B2B コラボレーションを使用できます。招待されたユーザーは、ディレクトリのドキュメント、リソース、およびアプリにアクセスできるようになり、独自のリソースおよびデータに対する制御は元の管理者が保持し続けます。

ゲストユーザーは、他の組織のディレクトリテナントにサインインすることができます。そうするには、その組織のディレクトリ名をポータル URL に追加します。たとえば、Contoso 組織に所属していて、Fabrikam ディレクトリにサインインする場合は、https://portal.local.azurestack.external/fabrikam.onmicrosoft.com. を使用します。

アプリケーション

アプリを Microsoft Entra ID または AD FS に登録することで、組織内のユーザーにそのアプリを提供できます。

アプリには以下が含まれます。

Web アプリ:たとえば、Azure portal、Azure Resource Manager などです。これらでは、Web API 呼び出しがサポートされています。
ネイティブクライアント: たとえば、Azure PowerShell、Visual Studio、Azure CLI などです。

アプリでは、次の 2 種類のテナントをサポートできます。

シングルテナント: アプリが登録されている同じディレクトリのユーザーとサービスだけをサポートします。

Note

AD FS では単一のディレクトリしかサポートされないため、AD FS トポロジ内で作成するアプリは、設計上、シングルテナントアプリになります。
マルチテナント: アプリが登録されているディレクトリと追加のテナントディレクトリの両方のユーザーとサービスによって、使用をサポートします。マルチテナントアプリでは、別のテナントディレクトリ (別の Microsoft Entra テナント) のユーザーがアプリにサインインできます。

マルチテナントの詳細については、マルチテナントの有効化に関するページを参照してください。

マルチテナントアプリの開発の詳細については、マルチテナントアプリに関するページを参照してください。

アプリを登録するときに、次の 2 つのオブジェクトを作成します。

アプリケーションオブジェクト: すべてのテナントにわたる、アプリのグローバルな表現です。この関係はソフトウェアアプリと 1 対 1 であり、アプリが最初に登録されたディレクトリだけに存在します。
サービスプリンシパルオブジェクト: アプリが最初に登録されたディレクトリ内でそのアプリのために作成される資格情報です。また、サービスプリンシパルは、そのアプリが使用される追加の各テナントのディレクトリにも作成されます。この関係は、ソフトウェアアプリと 1 対多にすることができます。

アプリおよびサービスプリンシパルオブジェクトの詳細については、「 Microsoft Entra ID のアプリケーションオブジェクトとサービスプリンシパルオブジェクトを参照してください。

サービスプリンシパル

サービスプリンシパルは、Azure Stack Hub 内のリソースへのアクセスを許可する、アプリまたはサービスの資格情報のセットです。サービスプリンシパルを使用すると、アプリのアクセス許可と、アプリのユーザーのアクセス許可が分離されます。

サービスプリンシパルは、アプリが使用される各テナントに作成されます。そのテナントによって保護されているリソース (ユーザーなど) へのサインインとアクセスのために、サービスプリンシパルは ID を確立します。

シングルテナントアプリの場合、最初に作成されたディレクトリ内に、サービスプリンシパルが 1 つだけ保持されます。このサービスプリンシパルは、アプリの登録時に作成されて、使用が承認されます。
マルチテナント Web アプリまたは API の場合、該当のテナントのユーザーがアプリの使用に同意した各テナント内に、作成されたサービスプリンシパルがあります。

サービスプリンシパルの資格情報は、Azure Portal を通じて生成されるキー、または証明書です。証明書は、キーよりも安全であると考えられるため、自動化に適しています。

Note

Azure Stack Hub で AD FS を使用する場合、管理者だけがサービスプリンシパルを作成できます。 AD FS では、サービスプリンシパルは証明書を必要とし、特権エンドポイント (PEP) を通じて作成されます。詳細については、「アプリ ID を使用してリソースにアクセスする」を参照してください。

Azure Stack Hub のサービスプリンシパルについては、サービスプリンシパルの作成に関するページを参照してください。

サービス

ID プロバイダーとやりとりする Azure Stack Hub 内のサービスは、ID プロバイダーにアプリとして登録されます。アプリと同様に、登録されることで、サービスは ID システムによって認証できるようになります。

すべての Azure サービスは、OpenID Connect プロトコルと JSON Web トークンを使用して ID を確立します。 Microsoft Entra ID と AD FS ではプロトコルが一貫して使用されるため、 Microsoft Authentication Library (MSAL) を使用して、オンプレミスまたは Azure (接続されたシナリオ) に対して認証するためのセキュリティトークンを取得できます。 MSAL を使用すると、クラウド間およびオンプレミスのリソース管理に Azure PowerShell や Azure CLI などのツールを使用することもできます。

ID と ID システム

Azure Stack Hub の ID には、ユーザーアカウント、グループ、サービスプリンシパルが含まれます。

Azure Stack Hub をインストールすると、いくつかの組み込みのアプリとサービスが、ディレクトリテナント内の ID プロバイダーに自動的に登録されます。登録される一部のサービスは、管理用に使用されます。その他のサービスは、ユーザーが使用できます。既定の登録では、各コアサービスに ID が与えられます。この ID では、相互に対話することも、後で追加する ID と対話することもできます。

マルチテナントを利用して Microsoft Entra ID を設定すると、一部のアプリは新しいディレクトリに反映されます。

認証と権限承認

アプリとユーザーによる認証

Azure Stack Hub のレイヤー間の ID

アプリとユーザーにとって、Azure Stack Hub のアーキテクチャは 4 つのレイヤーで表されます。各レイヤー間の対話には、さまざまな種類の認証を使用できます。

レイヤー	レイヤー間の認証
管理者ポータルなどのツールとクライアント	Azure Stack Hub のリソースにアクセスしたり、変更したりするために、ツールとクライアントでは JSON Web トークンを使用して Azure Resource Manager を呼び出します。 Azure Resource Manager では JSON Web トークンを検証し、発行されたトークン内の "要求" を読み取って、ユーザーまたはサービスプリンシパルが Azure Stack Hub で持つ承認のレベルを見積もります。
Azure Resource Manager とそのコアサービス	Azure Resource Manager は、リソースプロバイダーと通信して、ユーザーからの通信を転送します。転送では、Azure Resource Manager テンプレートを通じて、"直接命令" 呼び出しまたは "宣言" 呼び出しが使用されます。
リソースプロバイダー	リソースプロバイダーに渡された呼び出しは、証明書ベースの認証によって保護されます。 Azure Resource Manager とリソースプロバイダーは、API を介した通信を継続します。 Azure Resource Manager から受信したすべての呼び出しを、リソースプロバイダーはその証明書で検証します。
インフラストラクチャとビジネスロジック	リソースプロバイダーは、任意の認証モードを使用して、ビジネスロジックおよびインフラストラクチャと通信します。 Azure Stack Hub 付属の既定のリソースプロバイダーは、この通信をセキュリティで保護するために Windows 認証を使用します。

認証に必要な情報

Azure Resource Manager への認証

ID プロバイダーで認証して JSON Web トークンを受け取るには、次の情報が必要です。

ID システム (機関) の URL: ID プロバイダーに到達できる URL。たとえば、https://login.windows.net のようにします。
Azure Resource Manager のアプリ ID URI: ID プロバイダーに登録された、Azure Resource Manager の一意の識別子。各 Azure Stack Hub のインストールに対しても一意です。
資格情報:ID プロバイダーでの認証に使用する資格情報。
Azure Resource Manager の URL: Azure Resource Manager サービスの場所を示す URL。たとえば、https://management.azure.com または https://management.local.azurestack.external です。

プリンシパル (クライアント、アプリ、またはユーザー) がリソースにアクセスするために認証要求を行う場合、その要求には以下のものが含まれている必要があります。

プリンシパルの資格情報。
プリンシパルがアクセスするリソースのアプリ ID URI。

資格情報は、ID プロバイダーによって検証されます。 ID プロバイダーでは、アプリ ID URI が登録済みアプリに対応していることと、プリンシパルがそのリソースのトークンを取得するための正しい特権を持っていることも検証します。要求が有効な場合は、JSON Web トークンが付与されます。

その後、トークンは要求のヘッダーで Azure Resource Manager に渡す必要があります。 Azure Resource Manager は、不特定の順序で以下の操作を行います。

トークンが正しい ID プロバイダーからのものであることを確認するために、issuer (iss) 要求を検証します。
トークンが Azure Resource Manager に発行されたことを確認するために、audience (aud) 要求を検証します。
JSON Web トークンが OpenID を通じて構成された証明書によって署名され、Azure Resource Manager に認識されていることを検証します。
トークンがアクティブであり、承認可能であることを確認するために、issued at (iat) および expiration (exp) 要求を見直します。

すべての検証が完了すると、Azure Resource Manager で object id (oid) および groups 要求を使用して、プリンシパルがアクセスできるリソースの一覧が作成されます。

トークン交換プロトコルの図

ロールベースのアクセス制御を使用する

Azure Stack Hub のロールベースのアクセス制御 (RBAC) は、Microsoft Azure での実装と一致しています。適切な RBAC ロールをユーザー、グループ、およびアプリに割り当てることによって、リソースへのアクセスを管理することができます。 Azure Stack Hub で RBAC を使用する方法については、以下の記事を参照してください。

Azure PowerShell で認証する

Azure PowerShell を使用して Azure Stack Hub で認証する方法の詳細については、Azure Stack Hub ユーザーの PowerShell 環境の構成に関するページで見つけることができます。

Azure CLI で認証する

Azure PowerShell を使用して Azure Stack Hub で認証する方法については、Azure Stack Hub で使用する Azure CLI のインストールと構成に関するページを参照してください。

Azure Policy

Azure Policy は、組織の標準を適用し、コンプライアンスを大規模に評価するのに役立ちます。コンプライアンスダッシュボードを通じて、環境の全体的な状態を評価するための集計ビューを提供します。これには、リソースごと、およびポリシーごとの粒度でドリルダウンできる機能が備わっています。既存のリソースの一括修復と新しいリソースの自動修復を使用して、お客様のリソースでコンプライアンスを実現するのにも便利です。

Azure Policy の一般的なユースケースには、リソースの整合性、規制コンプライアンス、セキュリティ、コスト、管理のガバナンスの実装が含まれています。これらの一般的なユースケース用のポリシー定義は、使用を開始できるように Azure 環境に既に組み込まれています。

Note

現在、Azure Policy は Azure Stack Hub ではサポートされていません。

Azure AD グラフ

Microsoft Azure は、2020 年 6 月 30 日に Azure AD Graph の廃止と、2023 年 6 月 30 日の提供終了日を発表しました。 Microsoft は、この変更について電子メールでお客様に通知しています。詳細については、Azure AD Graph Retirement と Powershell モジュールの非推奨ブログを参照してください。

次のセクションで、この非推奨による Azure Stack Hub への影響について説明します。

Azure Stack Hub チームは、Azure Graph チームと緊密に協力して、スムーズな移行を実現するために、必要に応じてシステムが 2023 年 6 月 30 日を超えて動作し続けられるようにしています。最も重要なアクションは、Azure Stack Hub サービスポリシーに確実に準拠することです。お客様は、Azure Stack Hub の管理者ポータルでアラートを受け取り、ホームディレクトリとオンボードされたすべてのゲストディレクトリを更新することが求められます。

移行自体の大部分は、統合システムの更新エクスペリエンスによって行われます。これらのアプリケーションに新しいアクセス許可を付与するには、お客様が手動で手順を実行する必要があります。そのためには、Azure Stack Hub 環境で使用される各 Microsoft Entra ディレクトリでアプリケーション管理者のアクセス許可が必要になります。これらの変更を含む更新プログラムパッケージのインストールが完了すると、管理ポータルでアラートが発生し、マルチテナント UI または PowerShell スクリプトを使用してこの手順を完了するように指示されます。これは、追加のディレクトリまたはリソースプロバイダーをオンボードするときに実行する操作と同じです。詳細については、「 Azure Stack Hub でのマルチテナントの構成」を参照してください。

Azure Stack Hub と共に ID システムとして AD FS を使用する場合、これらの Graph の変更はお使いのシステムに直接影響しません。ただし、Azure CLI、Azure PowerShell などの最新バージョンのツールには新しい Graph API が必要であり、機能しません。これらのツールについては、特定の Azure Stack Hub ビルドで明示的にサポートされているバージョンのみを使用するようにしてください。

管理ポータルのアラートに加えて、変更内容が更新プログラムのリリースノートによって通知されます。また、ホームディレクトリとオンボードされたすべてのゲストディレクトリを更新する必要がある更新プログラムパッケージが通知されます。

次の方法で共有

Azure Stack Hub の ID プロバイダーの概要