アプリケーション モデル フレームワークをセキュリティで保護する
Microsoft では、Microsoft Azure 多要素認証 (MFA) アーキテクチャを使用して、クラウド ソリューション プロバイダー (CSP) パートナーと コントロール パネル ベンダー (CPV) を認証するための、セキュリティで保護されたスケーラブルなフレームワークを導入しています。 CSP パートナーとコントロール パネル ベンダーは、新しいモデルに依存して、パートナー センター API 統合呼び出しのセキュリティを強化できます。 これにより、Microsoft、CSP パートナー、コントロール パネル ベンダーを含むすべての関係者が、インフラストラクチャと顧客データをセキュリティ リスクから保護できます。
重要
Azure Active Directory (Azure AD) Graph は、2023 年 6 月 30 日の時点で非推奨となっています。 今後、Azure AD Graph への投資は行いません。 Azure AD Graph API には、セキュリティ関連の修正プログラム以外の SLA やメンテナンス コミットメントはありません。 新機能への投資は Microsoft Graph に対してのみ行われます。
アプリケーションを Microsoft Graph API に移行するのに十分な時間を確保できるように、段階的な手順で Azure AD Graph を廃止します。 後日お知らせしますが、Azure AD Graph を使用して新しいアプリケーションの作成をブロックします。
詳細については、「 Important: Azure AD Graph の廃止と Powershell モジュールの廃止に関するページを参照してください。
範囲
この記事は、次のパートナーに適用されます。
- コントロール パネル ベンダー (CPV) は、パートナー センター API と統合するために CSP パートナーが使用するアプリを開発する独立系ソフトウェア ベンダーです。 CPV は、パートナー ダッシュボードまたは API に直接アクセスできる CSP パートナーではありません。 CSP が統合されたマーケットプレースを通じて製品を販売できるようにするアプリケーション (通常は Web アプリ) を開発する企業です。
- アプリ ID とユーザー認証を使用し、Partner Center API と直接統合する CSP 間接プロバイダーと CSP ダイレクト パートナー。
Note
CPV として資格を得るには、まずパートナー センターに CPV としてオンボードする必要があります。 CPV でもある既存の CSP パートナーである場合は、この前提条件も適用されます。
セキュリティで保護されたアプリケーション開発
CSP に代わって Microsoft 製品の注文を行うプロセスでは、CPV のマーケットプレース アプリケーションが Microsoft API と対話して注文を行い、顧客のリソースをプロビジョニングします。
これらの API の一部は次のとおりです。
- 注文の発注やサブスクリプションのライフサイクルの管理などのコマース操作を実装するパートナー センター API。
- CSP テナントと CSP 顧客のテナントの ID 管理を実装する Microsoft Graph API。
- Azure デプロイ機能を実装する Azure Resource Manager (ARM) API。
CSP パートナーには、Microsoft API を呼び出すときに顧客に代わって行動するための委任された特権が与えられます。 委任された特権を使用すると、CSP パートナーは顧客の購入、展開、サポートのシナリオを完了できます。
Marketplace アプリケーションは、CSP パートナーが顧客向けのソリューションを一覧表示できるように設計されています。 これを実現するには、マーケットプレース アプリケーションで CSP パートナー特権を借用して Microsoft API を呼び出す必要があります。
CSP パートナーの特権は高く、パートナーのすべての顧客にアクセスできるため、セキュリティの悪用ベクトルに耐えられるようにこれらのアプリケーションを設計する方法を理解することが重要です。 このような機密性の高いアプリケーションに対するセキュリティ攻撃は、顧客データの侵害につながる可能性があります。 そのため、権限付与とパートナー特権の偽装は、最小限の特権の原則に従うように設計する必要があります。 次の原則とベスト プラクティスにより、マーケットプレース アプリケーションは持続可能であり、侵害に耐えることができます。
資格情報の偽装のセキュリティ原則
Marketplace アプリケーションでは、CSP パートナーからの資格情報を格納しないでください。
CSP パートナー のユーザー パスワードは共有しないでください。
CSP パートナー テナントの Web アプリ キーをコントロール パネル ベンダーと共有することはできません。
Marketplace アプリケーションでは、CSP パートナー ID を偽装する呼び出しを行うときにパートナー資格情報のみを使用するのではなく、アプリケーション ID とパートナー情報を提示する必要があります。
マーケットプレース アプリケーションへのアクセスは、最小限の特権の原則に基づいており、アクセス許可で明確に示されている必要があります。
Marketplace アプリケーションの承認は、複数の資格情報にピボットする必要があります。
アクセスするには、アプリケーション資格情報とパートナー資格情報を一緒に指定する必要があります。
重要
妥協点が 1 つもないことが重要です。
アクセスは、特定の対象ユーザーまたは API に制限する必要があります。
Access は、偽装の目的を識別する必要があります。
マーケットプレース アプリケーションのアクセス許可は、期限付きである必要があります。 CSP パートナーは、マーケットプレース アプリケーションへのアクセスを更新または取り消すことができる必要があります。
Marketplace アプリケーションの資格情報の侵害を処理するには、迅速な制御または修復プロセスを実施する必要があります。
すべてのユーザー アカウントで 2 要素認証 (2FA) を使用する必要があります。
アプリケーション モデルは、より優れたセキュリティ モデルへの条件付きアクセスなど、追加のセキュリティ プロビジョニングに対してわかりやすいものにする必要があります。
Note
アプリ ID + ユーザー認証を使用し、パートナー センター API と直接統合している CSP 間接プロバイダーと CSP 直接パートナーは、上記の原則に従って独自のマーケットプレース アプリケーションをセキュリティで保護する必要があります。
アプリケーション ID と概念
マルチテナント アプリケーション
マルチテナント アプリケーションは、通常、サービスとしてのソフトウェア (SaaS) アプリケーションです。 Azure ダッシュボードでアプリケーションの種類を multitenant として構成することで、任意の Microsoft Entra テナントからのサインインを受け入れるようにアプリケーションを構成できます。 すべての Microsoft Entra テナントのユーザーは、アプリケーションで自分のアカウントを使用することに同意すれば、そのアプリケーションにサインインできるようになります。
マルチテナント アプリケーションの作成の詳細については、「マルチテナント アプリケーション パターンを使用して Microsoft Entra ユーザーに 署名するを参照してください。
同意フレームワーク
ユーザーが Microsoft Entra ID でアプリケーションにサインインするには、アプリケーションをユーザーのテナントで表す必要があります。これにより、組織は、テナントからアプリケーションにユーザーがサインインするときに一意のポリシーを適用できます。 シングル テナント アプリケーションの場合、この登録は簡単です。これは、Azure ダッシュボードにアプリケーションを登録するときに発生します。
マルチテナント アプリケーションの場合、アプリケーションの初期登録は、開発者が使用する Microsoft Entra テナントに存在します。 ユーザーが初めて別のテナントからこのアプリケーションにサインインすると、Microsoft Entra ID により、アプリケーションで要求されるアクセス許可に同意するかどうかを尋ねられます。 同意すると、サービス プリンシパルと呼ばれるアプリケーションの表現がユーザーのテナントに作成され、サインイン プロセスを続行できます。 委任は、アプリケーションに対するユーザーの同意を記録するディレクトリにも作成されます。
Note
アプリ ID + ユーザー認証を使用し、パートナー センター API と直接統合している CSP 間接プロバイダーと CSP 直接パートナーは、同じ同意フレームワークを使用してマーケットプレース アプリケーションに同意する必要があります。
同意エクスペリエンスは、アプリケーションによって要求されたアクセス許可の影響を受ける。 Microsoft Entra ID では、アプリ専用と委任の 2 種類のアクセス許可がサポートされています。
- アプリ専用のアクセス許可 は、アプリケーションの ID に直接付与されます。 たとえば、アプリケーションにサインインしているユーザーに関係なく、テナント内のユーザーの一覧を読み取るアクセス許可をアプリケーションに付与できます。
- 委任されたアクセス許可 は、ユーザーが実行できる操作のサブセットに対してサインインユーザーとして機能する機能をアプリケーションに付与します。 たとえば、サインインしているユーザーの予定表を読み取るための委任されたアクセス許可をアプリケーションに付与できます。
通常のユーザーが同意するアクセス許可もあれば、テナント管理者の同意が必要なアクセス許可もあります。 Microsoft Entra 同意フレームワークの詳細については、「 Microsoft Entra アプリケーションの同意エクスペリエンスの理解を参照してください。
マルチテナント アプリケーションオープン承認 (OAuth) トークン フロー
マルチテナント アプリケーション オープン承認 (OAuth) フローでは、アプリケーションは CPV または CSP パートナーのテナントのマルチテナント アプリケーションとして表されます。
Microsoft API (パートナー センター API、Graph API など) にアクセスするには、CSP パートナーがアプリケーションにログインし、アプリケーションが自分の代わりに API を呼び出せるように同意する必要があります。
Note
アプリ ID とユーザー認証を使用し、パートナー センター API と直接統合している CSP 間接プロバイダーと CSP 直接パートナーは、同じ同意フレームワークを使用するために、マーケットプレース アプリケーションに同意する必要があります。
アプリケーションは、同意と OAuth 許可を通じて、Graph やパートナー センター API などのパートナーのリソースにアクセスできます。
マルチテナント アプリケーションを作成する
マルチテナント アプリケーションは、次の要件に従う必要があります。
- アプリケーション ID とシークレット キーを持つ Web アプリである必要があります。
- 暗黙的な認証モードがオフになっている必要があります。
さらに、次のベスト プラクティスに従うことをお勧めします。
- 秘密鍵の証明書を使用します。
- 条件付きアクセスを有効にして、IP 範囲の制限を適用します。 これには、Microsoft Entra テナントでさらに多くの機能を有効にする必要がある場合があります。
- アプリケーションのアクセス トークンの有効期間ポリシーを適用します。
トークンを取得するときは、アプリ ID とシークレット キーを提示する必要があります。 秘密鍵には証明書を指定できます。
Azure Resource Manager API を含む複数の API を呼び出すアプリケーションを構成できます。 パートナー センター API に必要な最小限のアクセス許可のセットを次に示します。
- Microsoft Entra ID の委任されたアクセス許可: サインインしているユーザーとしてディレクトリにアクセスします
- パートナー センター API の委任されたアクセス許可: Access
アプリケーションがパートナーの同意をキャプチャする
マルチテナント アプリケーションでは、パートナーから同意を取得し、同意と許可を使用して、パートナー センター API へのさらに呼び出しを行う必要があります。 同意は、OAuth 認証コード フローを通じて取得されます。
同意を得るために、CPV または CSP パートナーは、Microsoft Entra ID からの認証コード付与を受け入れるオンボード Web サイトを構築する必要があります。
詳細については、「 OAuth 2.0 コード付与フローを使用して Azure Active および Directory Web アプリケーションへのアクセスを認証するを参照してください。
マルチテナント アプリケーションが CSP パートナーの同意をキャプチャし、パートナー センター API を呼び出す再利用可能なトークンを取得する手順を次に示します。
パートナーの同意を取得するには、次の手順を使用します。
- パートナーがクリックしてマルチテナント アプリケーションの同意を受け入れるための同意リンクをホストできるパートナー オンボード Web アプリケーションを構築します。
- CSP パートナーが同意リンクをクリックします。 たとえば、
https://login.microsoftonline.com/common/oauth2/authorize?&client_id=<marketplaceappid>&response_tyのように指定します。 - Microsoft Entra ログイン ページでは、ユーザーに代わってアプリケーションに付与されるアクセス許可について説明します。 CSP パートナーは、管理者エージェントまたは Sales Agent の資格情報を使用してサインインし、同意を承認することを決定できます。 アプリケーションには、サインインに使用されるユーザー ロールに基づいてアクセス許可が付与されます。
- 同意が付与されると、Microsoft Entra ID は CPV のマルチテナント アプリケーションのサービス プリンシパルを CSP パートナーのテナントに作成します。 アプリケーションには、ユーザーに代わって動作する OAuth 許可が付与されます。 これらの許可により、マルチテナント アプリケーションはパートナーに代わってパートナー センター API を呼び出すことができるようになります。 この時点で、Microsoft Entra ログイン ページは、パートナーのオンボード Web アプリケーションにリダイレクトされます。 Web アプリケーションは、Microsoft Entra ID から承認コードを受け取ります。 パートナーオンボード Web アプリケーションは、認証コードとアプリケーション ID とシークレット キーを使用して、Microsoft Entra ID Tokens API を呼び出して更新トークンを取得する必要があります。
- 更新トークンを安全に格納します。 更新トークンは、パートナーに代わってパートナー センター API へのアクセスを取得するために使用されるパートナー資格情報の一部です。 更新トークンが取得されたら、それを暗号化し、 Azure キー コンテナーなどのシークレット キー ストアに格納します。
トークン要求の呼び出しフロー
CPV または CSP パートナーのアプリケーションは、パートナー センター API への呼び出しを行う前にアクセス トークンを取得する必要があります。 これらの API は、リソース URL https://api.partnercenter.microsoft.comで表されます。
CPV アプリケーションは、製品またはフェデレーション サインインに基づいてパートナー センター API を呼び出すために偽装する必要があるパートナー アカウントを識別する必要があります。 アプリケーションは、そのパートナー テナントの暗号化された更新トークンを秘密鍵ストアから取得します。 使用する前に、更新トークンを復号化する必要があります。
同意を与えるテナントが 1 人しかない CSP パートナーの場合、パートナー アカウントは CSP パートナーのテナントを参照します。
更新トークンは、複数の対象ユーザーのトークンです。 つまり、更新トークンを使用して、付与された同意に基づいて複数の対象ユーザーのトークンを取得できます。 たとえば、パートナー センター API と Microsoft Graph API に対してパートナーの同意が与えられている場合、更新トークンを使用して両方の API のアクセス トークンを要求できます。 アクセス トークンには "代理" の付与があり、マーケットプレース アプリケーションは、これらの API の呼び出し中に同意したパートナーを偽装できます。
アクセス トークンは、一度に 1 人の対象ユーザーに対して取得できます。 アプリケーションが複数の API にアクセスする必要がある場合は、対象ユーザーに対して複数のアクセス トークンを要求する必要があります。 アクセス トークンを要求するには、アプリケーションで Microsoft Entra ID Tokens API を呼び出す必要があります。 または、Microsoft Entra SDK の AuthenticationContext.AcquireTokenAsync を使用して、次の情報を渡すこともできます。
- リソース URL。これは、呼び出されるアプリケーションのエンドポイント URL です。 たとえば、Microsoft パートナー センター API のリソース URL は
https://api.partnercenter.microsoft.com。 - Web アプリのアプリケーション ID とシークレット キーで構成されるアプリケーション資格情報。
- 更新トークン
結果のアクセス トークンを使用すると、アプリケーションはリソースに記載されている API を呼び出すことができます。 アプリケーションは、同意要求の一部としてアクセス許可が付与されていない API のアクセス トークンを要求できません。 UserPrincipalName (UPN) 属性値は、ユーザー アカウントの Microsoft Entra ユーザー名です。
その他の注意事項
条件付きアクセス
クラウド リソースの管理に関しては、クラウド セキュリティの重要な側面は ID とアクセスです。 モバイル優先のクラウドファーストの世界では、ユーザーはどこからでもさまざまなデバイスやアプリを使用して組織のリソースにアクセスできます。 リソースにアクセスできるユーザーに焦点を当てるだけでは十分ではなくなりました。 セキュリティと生産性のバランスをマスターするには、リソースへのアクセス方法も考慮する必要があります。 Microsoft Entra 条件付きアクセスを使用すると、この要件に対処できます。 条件付きアクセスを使用すると、クラウド アプリへのアクセスを許可するかどうかの判断を各種の条件に基づいて自動的に行うアクセスの制御を実装できます。
詳細については、「 Microsoft Entra ID での条件付きアクセスとは」を参照してください。
IP 範囲ベースの制限
トークンを特定の範囲の IP アドレスのみに発行するように制限できます。 この機能は、攻撃の対象領域を特定のネットワークのみに制限するのに役立ちます。
多要素認証
多要素認証を適用すると、資格情報の検証を 2 つ以上のフォームに適用することで、資格情報の侵害の状況を制限できます。 この機能により、Microsoft Entra ID は、トークンを発行する前に、モバイルや電子メールなどのセキュリティで保護されたセカンダリ チャネルを介して呼び出し元の ID を検証できます。
詳細については、「 しくみ: Azure Multi」を参照してください。