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

  • [アーティクル]

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 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 トークンを受け取るには、次の情報が必要です。

  1. ID システム (機関) の URL: ID プロバイダーに到達できる URL。 たとえば、「 https://login.windows.net 」のように入力します。
  2. Azure Resource Manager のアプリ ID URI: ID プロバイダーに登録された、Azure Resource Manager の一意の識別子。 各 Azure Stack Hub のインストールに対しても一意です。
  3. 資格情報:ID プロバイダーでの認証に使用する資格情報。
  4. 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 ビルドで明示的にサポートされているバージョンのみを使用するようにしてください。

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

次のステップ