Microsoft Planetary Computer Pro のアプリケーション認証を構成する

この記事では、開発者と管理者がセキュリティで保護されたアプリケーション認証と Microsoft Planetary Computer Pro へのアクセスを設定するための詳細なガイダンスを提供します。 Microsoft Entra ID とマネージド ID を適用することで、アプリケーションは資格情報を管理することなくシームレスに認証でき、プラネタリーコンピューター Pro リソースとの安全な対話が保証されます。アプリケーションが Azure またはその他の環境で実行されているかどうかにかかわらず、このガイドでは、セキュリティで保護されたアクセスを有効にするために必要な構成 (ロールベースのアクセス制御 (RBAC) やトークンの取得など) の概要を説明します。

注

ソーシャル ID プロバイダーなどの機能をサポートする Azure AD B2C または Microsoft Entra External ID を使用するアプリケーションの場合、プラネタリーコンピューター Pro は Microsoft Entra ID 認証の代替手段をサポートしていないため、これらの ID ソリューションを使用して認証トラフィックをプロキシする必要があります。

認証オプションと推奨事項

次の表は、アプリケーションの実行場所とリソースへのアクセス方法に基づいて、推奨される認証方法をまとめたものです。

アプリケーションホスティング環境	アクセスの種類が必須	推奨される ID の種類	Explanation
Azure での実行 (VM、App Service、Functions、Container Apps など)	App-Only (アプリケーションがそれ自体として機能する)	マネージド ID (ユーザー割り当て推奨)	セキュリティと管理容易性: 資格情報 (シークレットまたは証明書) をコードまたは構成に格納および管理する必要がなくなります。 Azure は資格情報のローテーションを自動的に処理します。複数のリソース間で共有する場合は、ユーザー割り当てをお勧めします。
Azure での実行 (VM、App Service、Functions、Container Apps など)	委任 (アプリケーションはユーザーに代わって機能します)	マネージド ID (ユーザー割り当て推奨)	Azure 統合を活用します。アプリケーション自体のマネージド ID のセキュリティ上の利点と、標準のユーザー認証フローを組み合わせます。 Azure 内でのインフラストラクチャのセットアップを簡略化します。
Azure の外部での実行 (オンプレミス、その他のクラウド、開発者用コンピューター)	App-Only (アプリケーションがそれ自体として機能する)	サービスプリンシパル	外部アプリの標準: Azure 以外のアプリケーションが Microsoft Entra ID で認証するための確立された方法。資格情報 (シークレットまたは証明書) を安全に管理する必要があります。
Azure の外部での実行 (オンプレミス、その他のクラウド、開発者用コンピューター)	委任 (アプリケーションはユーザーに代わって機能します)	サービスプリンシパル	外部アプリの標準: Entra ID でアプリケーションの登録済み ID を使用して、Azure 外部のアプリケーションのユーザーサインインと同意に対して標準の OAuth 2.0 フローを有効にします。
Azure の外部での実行 (代替)	アプリ専用または委任	マネージド ID	Azure の利点: Azure コンピューティングサービス (VM やコンテナーアプリなど) でアプリケーションをホストすることで、マネージド ID のセキュリティと管理性が強化され、配信元が Azure 以外と見なされる場合でも資格情報の管理を回避できます。

[前提条件]

アクティブなサブスクリプションを持つ Azure アカウント - アカウントを無料で作成する
既存の GeoCatalog リソース。

Azure で実行されているアプリケーション

Azure で実行されているアプリケーションの場合は、GeoCatalog リソースにアクセスするために、ユーザー割り当てマネージド ID と呼ばれる Microsoft Entra ID の種類を作成することをお勧めします。アプリケーションでは、マネージド ID を使用して Microsoft Entra トークンを取得できます (「アクセストークンの取得」セクションを参照して、資格情報を管理しなくても Microsoft Planetary Computer Pro にアクセスできます。マネージド ID と選択する種類の詳細については、「 Azure リソースのマネージド ID とは」を参照してください。 Azure で実行されているアプリケーションのユーザー割り当てマネージド ID を作成するには、 App Service と Azure Functions のマネージド ID を使用する方法に従います。

Azure で実行されていないアプリケーション

オンプレミスや他のクラウドプロバイダーでホストされている Azure で実行されていないアプリケーションの場合は、アプリと Microsoft ID プラットフォーム間の信頼関係を確立するために、セキュリティトークンを受け取るリダイレクト URI を含む Microsoft Entra 管理センターにアプリケーションを登録することをお勧めします。 Microsoft Entra にアプリを登録すると、アプリのサービスプリンシパルが自動的に作成され、後で RBAC ロールを割り当てることができます。アプリケーションに Microsoft Entra ID 認証を構成する設定がある場合は、登録されているアプリの "アプリケーション (クライアント) ID" と "ディレクトリ (テナント) ID" を使用してこれを行うことができます。

前述のように Microsoft Entra にアプリケーションを登録できない場合は、Azure VM またはコンテナーアプリでアプリケーションを実行する別のオプションがあります。ここで説明するように、ユーザー割り当てマネージド ID を作成し、仮想マシン (VM) またはコンテナーアプリに割り当てることができます。Azure Container Apps で Azure 仮想マシン (VM) とマネージド ID を構成します。アプリケーションはマネージド ID でサインインして GeoCatalog リソースにアクセスできます。たとえば、ユーザー割り当てマネージド ID を使用して VM 内でアプリケーションを実行するには、次のコマンドを使用できます。

!az login  --identity --username <client_id|object_id|resource_id>

Azure portal から、マネージド ID のクライアント ID、オブジェクト ID、またはリソース ID を確認できます。 CLI の代わりに、サンプルの Python コードは、 Microsoft Planetary Computer Pro にアクセスするためのアクセストークンの取得に関するセクションにあります。

azure.identity.DefaultAzureCredential(managed_identity_client_id=<client_id>)

前に説明したように、アプリケーションのユーザー割り当てマネージド ID またはサービスプリンシパルを作成した後、アプリケーションアクセスシナリオの種類を決定する必要があります。アプリケーション専用アクセスは、アプリケーションの独自の ID または委任されたアクセスとしてのみ機能し、サインインしているユーザーの代わりに動作します。

アプリ専用アクセス

このアクセスシナリオでは、既定の動作としてサインインしたユーザーなしでアプリケーションが単独で動作します。アプリケーションに適切なロールを割り当てるには、アプリケーションの Microsoft Planetary Computer Pro RBAC の構成に関するセクションに進むことができます。

委任されたアクセス

このアクセスシナリオでは、ユーザーがクライアントアプリケーションにサインインしました。クライアントアプリケーションは、ユーザーの代わりにリソースにアクセスします。 ユーザーの作成と管理のセクションの説明に従って、アプリケーションのユーザーに適切な RBAC ロールが割り当てられていることを確認する必要があります。また、次の手順に従って、委任されたアクセス許可を使用してアプリケーションの API アクセス許可を構成する必要があります。

Microsoft Entra 管理センターにサインインする
Identity>Applications>App registrations に移動し、クライアントアプリケーションを選択します
[管理] で、[API のアクセス許可] を選択します
[ アクセス許可の追加] を選択する
組織で 使用している API タブを選択する
検索フィールドに 「Azure Orbital Planetary Computer 」と入力します
一致するエントリを選択します (アプリ ID は 6388acc4-795e-43a9-a320-33075c1eb83b にする必要があります)。 Azure Orbital Microsoft プラネタリーコンピューター Pro として表示されます。
[ 委任されたアクセス許可 ] ボックスを選択します。 user_impersonationの横にあるチェックボックスをオンにします。
[アクセス許可の追加] を選択する
[管理者の同意を付与する] リンクを選択します (このアクセス許可のテナントで管理者の同意を付与することを意図している場合)

委任された認証パターンは QGISから接続するときにも使用されます。

アプリケーション用の Microsoft プラネタリーコンピューター Pro RBAC 構成

Azure で実行されているアプリケーションのマネージド ID、または Azure で実行されていないが Microsoft Entra に登録されているアプリケーションのサービスプリンシパルを作成したら、RBAC 構成を使用して GeoCatalog リソースにアクセスするための適切なアクセス許可を ID に付与する必要があります。

アプリケーションのユーザー割り当てマネージド ID に "GeoCatalog 管理者" ロールを割り当てるために Role-Based アクセス制御 (RBAC) を構成する方法を示す詳細な例を次に示します。 Azure portal でこれらの同じ手順に従って、アプリケーションのサービスプリンシパルの RBAC を構成できます。

Azure portal で、左側の Microsoft Planetary Computer Pro リソース IAM タブに移動します。
[ロールの割り当ての追加] を選択し、「ジョブ関数ロール」の下から [GeoCatalog 管理者] を選択します。
[次へ] ボタンを選択し、[マネージド ID] のラジオボタンを選択します
[ メンバーの選択 ] を選択し、右側の [マネージド ID の選択] ウィンドウでサブスクリプションとユーザー割り当て マネージド ID を選択 します。
[ 次へ ] を選択して情報を確認し、 レビューと割り当てを完了します。

Microsoft プラネタリーコンピューター Pro にアクセスするためのアクセストークンを取得する

アプリケーションに適切なアクセス許可を付与するように RBAC を構成した後、アプリケーションは要求を認証するためのアクセストークンを取得する必要があります。以下の Python サンプルコード:

import azure.identity
credential = azure.identity.DefaultAzureCredential()
token = credential.get_token("https://geocatalog.spatio.azure.com/")
headers = {"Authorization": f"Bearer {token.token}"}

注

アプリケーションに複数のマネージド ID が割り当てられている場合は、適切な ID ( azure.identity.DefaultAzureCredential(managed_identity_client_id=<client_id>)) を明示的に渡す必要があります。または、Azure portal でアプリケーションの環境変数を構成して、適切なマネージド ID クライアント ID を持つ "AZURE_CLIENT_ID" を追加することもできます。

注

予想されるユーザー認証の動作に基づいて、 .default または user_impersonation をスコープとして credential.get_token() に追加できます。

注

アプリケーションが Web アプリの場合は、コードまたはアプリの構成を変更するたびに、キャッシュされた資格情報が使用されないように、必ず Web ブラウザーを閉じて再度開きます。

アクセストークンの詳細については、Microsoft ID プラットフォームのアクセストークンを参照してください。 DefaultAzureCredentials() を呼び出してアクセストークンを取得すると、取得したトークンは資格情報インスタンスによってキャッシュされます。トークンの有効期間と更新は自動的に処理されます。 DefaultAzureCredential インスタンスを渡し、トークンが必要になる直前に GetToken() または GetTokenAsync() 呼び出して、有効期限が切れていないトークンを常に取得できます。開いているセッションを長く維持する必要がある場合は、エラーハンドラーでトークンの有効期限を処理して例外をキャッチし、新しいトークンを取得できます。

DefaultAzureCredentials()を使用できない場合、代わりに AzureCliCredential() などの他の方法を使用してアクセストークンを取得する場合は、トークンの有効期間と更新を管理する必要があります。詳細については、「 Microsoft ID プラットフォームでの構成可能なトークンの有効期間」および「Microsoft ID プラットフォームのトークンの更新」を参照してください。

次のステップ

データを使用してアプリケーションを接続して構築する

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-01-10