次の方法で共有

パートナー センターまたはパートナー センター API を使用するためのセキュリティ要件

適切な役割: すべてのパートナー センター ユーザー

アドバイザー、コントロール パネル ベンダー、またはクラウド ソリューション プロバイダー (CSP) パートナーは、認証オプションやその他のセキュリティに関する考慮事項に関して決定を下すことができます。

お客様と顧客のプライバシー保護とセキュリティは、Microsoft の最優先事項の 1 つです。 私たちは、最善の防御は予防であり、最も弱い箇所が強さを決めることを知っています。 適切なセキュリティ保護が確実に実施されるように、エコシステムのすべてのユーザーが必要です。

必須のセキュリティ要件

CSP プログラムは、顧客がパートナーを通じて Microsoft の製品とサービスを購入するのに役立ちます。 パートナーは、Microsoft との契約に従って、販売先のお客様の環境を管理し、サポートを提供する必要があります。

このチャネルを通じて購入した顧客は、顧客テナントに対する高い特権管理者アクセス権を持っているため、パートナーとして信頼を置きます。

必須のセキュリティ要件を実装していないパートナーは、CSP プログラムで取引することはできません。 また、委任された管理者権限を使用する顧客テナントを管理することもできません。 さらに、セキュリティ要件を実装していないパートナーは、プログラムへの参加を危険にさらす可能性があります。

パートナーのセキュリティ要件に関連付けられている条件は、Microsoft パートナー契約に追加されます。 Microsoft Partner Agreement (MPA) は定期的に更新され、Microsoft では、すべてのパートナーが定期的に確認することをお勧めします。 アドバイザーに関連するため、同じ契約要件が適用されます。

パートナーと顧客の環境をセキュリティで保護できるように、すべてのパートナーは セキュリティのベスト プラクティス に従う必要があります。 これらのベスト プラクティスは、セキュリティの問題を軽減し、セキュリティエスカレーションを修復し、顧客の信頼が損なわれないようにするのに役立ちます。

お客様と顧客を保護するには、すぐに次のアクションを実行する必要があります。

パートナー テナント内のすべてのユーザー アカウントに対して MFA を有効にする

パートナー テナント内のすべてのユーザー アカウントに多要素認証 (MFA) を適用する必要があります。 MFA は、次の場合にユーザーに認証を要求します。

  • Microsoft 商用クラウド サービスにサインインします。
  • パートナー センターを使用してクラウド ソリューション プロバイダー プログラムで取引します。
  • API を使用してトランザクションを行う。

MFA の適用は、次のガイドラインに従います。

詳細については、「 パートナー テナントの多要素認証を必須にする」を参照してください。

セキュリティで保護されたアプリケーション モデル フレームワークを採用する

パートナー センター API と統合するすべてのパートナーは、すべてのアプリおよびユーザー認証モデル アプリケーションにセキュリティ で保護されたアプリケーション モデル フレームワーク を採用する必要があります。

Important

パートナーは、Azure Resource Manager や Microsoft Graph などの Microsoft API と統合するために、セキュリティで保護されたアプリケーション モデルを実装することを強くお勧めします。 また、パートナーは、顧客の資格情報を使用して PowerShell などの自動化を活用し、MFA を適用する際の中断を回避するために、セキュリティで保護されたアプリケーション モデルを実装する必要があります。

これらのセキュリティ要件は、インフラストラクチャを保護し、盗難やその他の不正行為の特定などの潜在的なセキュリティ リスクから顧客のデータを保護するのに役立ちます。

その他のセキュリティ要件

お客様は、付加価値の高いサービスを提供するために、パートナーとしてお客様を信頼しています。 顧客の信頼とパートナーとしての評判を保護するために、すべてのセキュリティ対策を講じることが不可欠です。

Microsoftでは、パートナーが顧客のセキュリティを遵守し、優先するように、引き続き強制措置を追加しています。 これらのセキュリティ要件は、インフラストラクチャを保護し、盗難やその他の不正行為の特定などの潜在的なセキュリティ リスクから顧客のデータを保護するのに役立ちます。

パートナーは、次のセクションで説明するように、ゼロ トラストの原則を確実に採用する必要があります。

きめ細かい委任された管理者特権

GDAP 機能は、パートナーが顧客のワークロードへのアクセスを制御して、懸念事項により適切に対処するのに役立ちます。 パートナーは、現在のレベルのパートナー アクセスに不快な可能性がある顧客に、より多くのサービスを提供できます。 また、パートナーへの最小限の特権アクセスを必要とする規制のニーズを持つ顧客にサービスを提供することもできます。

GDAP は、ゼロ トラスト サイバーセキュリティ プロトコルに従って、パートナーに最小限の特権アクセスを提供するセキュリティ機能です。 これにより、パートナーは、運用環境とサンドボックス環境で顧客のワークロードへのきめ細かい時間制限付きアクセスを構成できます。 お客様は、パートナーに最小特権アクセス権を明示的に付与する必要があります。

詳細については、詳細な委任された管理者特権 (GDAP) の概要、最小特権ロールに関する情報、および GDAP に関する FAQ を参照してください。

Azure の不正行為の通知を監視する

CSP プログラムのパートナーは、顧客の Azure 消費に責任を負うので、顧客の Azure サブスクリプションで潜在的な暗号通貨マイニング アクティビティを認識することが重要です。 この認識は、行動が正当か不正かを判断するための迅速なアクションを実行するのに役立ちます。 必要に応じて、影響を受ける Azure リソースまたは Azure サブスクリプションを中断して問題を軽減できます。

詳細については、 Azure の不正行為の検出と通知に関するページを参照してください。

Microsoft Entra ID P2 にサインアップする

CSP テナント内のすべての管理者エージェントは、 Microsoft Entra ID P2 を実装してサイバーセキュリティを強化し、さまざまな機能を利用して CSP テナントを強化する必要があります。 Microsoft Entra ID P2 は、セキュリティ制御を強化するために、サインイン ログや Microsoft Entra Privileged Identity Management (PIM) やリスクベースの条件付きアクセス機能などのプレミアム機能への拡張アクセスを提供します。

CSP セキュリティのベスト プラクティスに準拠する

セキュリティに関するすべての CSP のベスト プラクティスに従することが重要です。 詳細については、 クラウド ソリューション プロバイダーのセキュリティに関するベスト プラクティスを参照してください。

多要素認証の実装

パートナーのセキュリティ要件に準拠するには、パートナー テナント内の各ユーザー アカウントに対して MFA を実装して適用する必要があります。 これは、次のいずれかの方法で行うことができます。

セキュリティの既定値

パートナーが MFA 要件の実装に使用できるオプションの 1 つは、Microsoft Entra ID でセキュリティの既定値を有効にすることです。 セキュリティの既定値では、追加料金なしで基本的なレベルのセキュリティが提供されます。 Microsoft Entra ID を使用して組織の MFA を有効にする方法を確認します。 セキュリティの既定値を有効にする前に、いくつかの重要な考慮事項を次に示します。

  • ベースライン ポリシーを既に採用しているパートナーは、セキュリティの既定値に移行するためのアクションを実行する必要があります。
  • セキュリティの既定値は、プレビュー ベースライン規則の一般提供版に代わるものです。 パートナーがセキュリティの既定値を有効にした後、ベースライン ポリシーを有効にすることはできません。
  • セキュリティの既定値ポリシーは一度に有効になります。
  • 条件付きアクセスを使用するパートナーは、セキュリティの既定値を使用できません。
  • レガシ認証プロトコルはブロックされます。
  • Microsoft Entra Connect 同期アカウントはセキュリティの既定値から除外され、多要素認証の登録または実行を求められることはありません。 組織では、このアカウントを他の目的で使用しないでください。

詳細については、「 組織の Microsoft Entra 多要素認証の概要 」および 「セキュリティの既定値とは」を参照してください。

注

Microsoft Entra のセキュリティの既定値は、ベースライン保護ポリシーの進化によって簡略化されています。 ベースライン保護ポリシーを既に有効にしている場合は、 セキュリティの既定値を有効にすることを強くお勧めします。

実装に関してよく寄せられる質問 (FAQ)

これらの要件はパートナー テナント内のすべてのユーザー アカウントに適用されるため、スムーズな展開を実現するためにいくつかのことを考慮する必要があります。 たとえば、MFA を実行できない Microsoft Entra ID のユーザー アカウントと、先進認証をサポートしていない組織内のアプリケーションとデバイスを特定します。

アクションを実行する前に、次の検証を完了することをお勧めします。

先進認証の使用をサポートしていないアプリケーションまたはデバイスはありますか?

MFA を適用すると、IMAP、POP3、SMTP、プロトコルを使用するレガシ認証がブロックされます。 これは、これらのプロトコルが MFA をサポートしていないためです。 この制限を修正するには、 アプリ パスワード 機能を使用して、アプリケーションまたはデバイスが引き続き認証されるようにします。 アプリ パスワードを使用して、環境内で使用できるかどうかを判断するための考慮事項を確認します。

パートナー テナントに関連付けられているライセンスを持つ Office 365 ユーザーはいますか?

ソリューションを実装する前に、パートナー テナントのユーザーが使用している Microsoft Office のバージョンを決定することをお勧めします。 ユーザーが Outlook などのアプリケーションで接続の問題を経験する可能性があります。 MFA を適用する前に、Outlook 2013 SP1 以降を使用し、組織で先進認証が有効になっていることを確認することが重要です。 詳細については、「 Exchange Online で先進認証を有効にする」を参照してください。

Windows を実行し、Microsoft Office 2013 がインストールされているデバイスに対して先進認証を有効にするには、2 つのレジストリ キーを作成する必要があります。 「Windows デバイスで Office 2013 の先進認証を有効にする」を参照してください。

作業中にユーザーがモバイル デバイスを使用できないようにするポリシーはありますか?

従業員が作業中にモバイル デバイスを使用できないようにする企業ポリシーは、実装する MFA ソリューションに影響を与えるため、特定することが重要です。 Microsoft Entra セキュリティの既定値の実装を通じて提供されるソリューションなど、認証アプリの検証のみを許可するソリューションがあります。 組織にモバイル デバイスの使用を禁止するポリシーがある場合は、次のいずれかのオプションを検討してください。

  • セキュリティで保護されたシステムで実行できる、時間ベースの 1 回限りの基本パスワード (TOTP) アプリケーションをデプロイします。

ユーザー資格情報を認証するには、どのような自動化または統合が必要ですか?

パートナー ディレクトリ内のサービス アカウントを含むユーザーに対する MFA の適用は、認証にユーザー資格情報を使用する自動化または統合に影響を与える可能性があります。 そのため、このような状況で使用されているアカウントを特定することが重要です。 考慮する必要のあるサンプル アプリケーションまたはサービスの次の一覧を参照してください。

  • コントロール パネルを使用して、顧客に代わってリソースを準備します。
  • (CSP プログラムに関連する) 請求書を発行し、顧客をサポートする任意のプラットフォームと統合します。
  • Az コマンドレット、AzureRM、 Microsoft Graph PowerShell、およびその他のモジュールを使用する PowerShell スクリプトを使用します。

この一覧は包括的ではないので、認証にユーザー資格情報を使用する環境内のアプリケーションまたはサービスの完全な評価を実行することが重要です。 MFA の要件に対応するには、可能な場合は 、セキュリティで保護されたアプリケーション モデル フレームワーク のガイダンスを使用します。

環境にアクセスする

MFA チャレンジなしで認証する内容やユーザーを理解するには、サインイン アクティビティを確認することをお勧めします。 Microsoft Entra ID P1 または P2 を使用すると、サインイン レポートを使用できます。 詳細については、 Microsoft Entra 管理センターのサインイン アクティビティ レポートを参照してください。 Microsoft Entra ID P1 または P2 がない場合、または PowerShell を使用してサインイン アクティビティを取得する方法が必要な場合は、パートナー センターの PowerShell モジュールから Get-PartnerUserSignActivity コマンドレットを使用します。

要件の適用方法

パートナー組織に MFA の例外が付与された場合、例外は、クラウド ソリューション プロバイダー プログラムの一部として顧客テナントを管理するユーザーが 2022 年 3 月 1 日より前に有効にした場合にのみ適用されます。 MFA 要件に準拠していないと、顧客のテナント アクセスが失われる可能性があります。

Microsoft Entra ID とパートナー センターは、MFA 検証が行われると識別するために MFA 要求の存在を確認することで、パートナーのセキュリティ要件を適用します。 2019 年 11 月 18 日の時点で、Microsoft は、以前はパートナー テナントに対する "技術的な強制" と呼ばれる、より多くのセキュリティ保護を有効にしました。

アクティブ化の時点で、パートナー テナント内のユーザーは、(AOBO) 操作に代わって管理者を実行するときに MFA 検証を完了するように要求されます。 ユーザーは、パートナー センターにアクセスするか、パートナー センター API を呼び出すときに MFA 検証を完了する必要もあります。 詳細については、「 パートナー テナントの多要素認証を必須にする」を参照してください。

要件を満たしていないパートナーは、ビジネスの中断を回避するために、できるだけ早くこれらの対策を実装する必要があります。 Microsoft Entra 多要素認証または Microsoft Entra セキュリティの既定値を使用する場合は、他のアクションを実行する必要はありません。

Microsoft 以外の MFA ソリューションを使用している場合は、MFA 要求が発行されない可能性があります。 要求が見つからない場合、Microsoft Entra ID は MFA が認証要求にチャレンジするかどうかを判断できません。 ソリューションが予期される要求を発行することを確認する方法については、「 テスト パートナーのセキュリティ要件」を参照してください。

Important

Microsoft 以外のソリューションで想定される要求が発行されない場合は、ソリューションを開発したベンダーと協力して、実行するアクションを決定してください。

リソースとサンプル

サポートとサンプル コードについては、次のリソースを参照してください。

関連コンテンツ

  • Last updated on