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

[アーティクル]
08/05/2024

Azure Stack Hub には、ID プロバイダーとして Active Directory によってサポートされるMicrosoft Entra ID またはActive Directory フェデレーションサービス (AD FS) (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 開発キット: ID に関する考慮事項。
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 を使用し、複数のテナントがある場合は、あるテナントから同じディレクトリの他のテナントへのアクセス権をアプリとユーザーに付与できます。
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 を使用し、マルチテナントのサポートを有効にします。サポートが有効になると、自社のディレクトリテナント内のリソースにアクセスするようにゲストユーザーを招待することができます。これにより、外部組織との共同作業が可能になります。

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

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

アプリケーション

アプリをMICROSOFT ENTRA ID または AD FS に登録し、organizationのユーザーにアプリを提供できます。

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

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

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

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

注意

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

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

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

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

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

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

サービスプリンシパル

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

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

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

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

注意

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 要求を使用して、プリンシパルがアクセスできるリソースの一覧が作成されます。

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

注意

デプロイ後、Microsoft Entraグローバル管理者のアクセス許可は必要ありません。ただし、一部の操作では、全体管理者の資格情報が必要な場合があります (たとえば、リソースプロバイダーのインストーラースクリプトや、アクセス許可を付与する必要のある新機能です)。アカウントの全体管理者のアクセス許可を一時的に復元するか、既定のプロバイダーサブスクリプションの所有者である別の全体管理者アカウントを使用します。

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

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 環境に既に組み込まれています。

注意

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

Azure AD グラフ

Microsoft Azure は、2020 年 6 月 30 日に Azure AD Graph の廃止と 2023 年 6 月 30 日の廃止を発表しました。 Microsoft は、この変更について電子メールでお客様に通知しています。詳細については、Azure AD Graph の廃止と 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 プロバイダーの概要