次の方法で共有

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

  • [アーティクル]

対象ロール: すべてのパートナー センター ユーザー

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

パートナーとその顧客のプライバシー保護とセキュリティは、Microsoft の最優先事項の 1 つです。 最善の防御は予防することであり、自分たちの強さが、最も弱いリンクと同程度でしかないことはわかっています。 そのため、適切なセキュリティ保護を確実に実施するために、エコシステムのすべてのユーザーが必要です。

必須のセキュリティ要件

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

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

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

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

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

お客様と顧客を保護するために、パートナーは直ちに次のアクションを実行する必要があります。

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

パートナー テナント内のすべてのユーザー アカウントに対して MFA を適用する必要があります。 ユーザーは、パートナー センターまたは API を使用して Microsoft の商用クラウド サービスにサインインするとき、またはクラウド ソリューション プロバイダー プログラムで取引を行うときに、多要素認証 (MFA) によるチャレンジを受ける必要があります。

MFA を適用するにあたっては、次のガイドラインに従います。

  • Microsoft がサポートする Microsoft Entra 多要素認証を使用するパートナー。 詳細については、「 Microsoft Entra 多要素認証を有効にする複数の方法 (MFA がサポートされています) を参照してください。
  • サードパーティの MFA と例外リストの一部を実装したパートナーは、引き続き例外を使用してパートナー センターと API にアクセスできますが、DAP/GDAP を使用して顧客を管理することはできません (例外は許可されません)
  • パートナーの組織に MFA の例外が以前に付与されている場合、CSP プログラムの一部として顧客テナントを管理するユーザーは、2022 年 3 月 1 日より前に Microsoft MFA 要件を有効にする必要があります。 MFA 要件に準拠しないと、顧客のテナント アクセスが失われる可能性があります。
  • パートナー テナント 多要素認証 (MFA) を管理する方法について説明します。

セキュア アプリケーション モデル フレームワークを導入する

パートナー センター API と統合しているすべてのパートナーは、すべてのアプリとユーザー認証モデルのアプリケーションに対してセキュア アプリケーション モデル フレームワークを採用する必要があります。

重要

パートナーには、MFA を強制するときの中断を避ける目的で、Azure Resource Manager や Microsoft Graph などの Microsoft API と統合するために、またはユーザー資格情報を使用する PowerShell などの自動化を利用する際に、セキュア アプリケーション モデルを実装することを強くお勧めします。

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

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

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

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

パートナーは、ゼロ トラストの原則を確実に導入する責任があります。具体的には、次のものがあります。

代理管理者特権 (DAP)

代理管理者特権 (DAP) により、顧客のサービスまたはサブスクリプションを代理で管理することができます。 顧客は、そのサービスに対する管理アクセス許可をパートナーに付与する必要があります。 顧客を管理するためにパートナーに提供される特権は高度に昇格されるため、Microsoft では、すべてのパートナーが非アクティブな DAP を 削除することをお勧めします。 委任された管理者特権を使用して顧客テナントを管理しているすべてのパートナーは、 Partner Center から非アクティブな DAP を削除する必要があります 顧客テナントとその資産への影響を防ぎます。

詳細については、「管理関係の監視とセルフサービス DAP の削除ガイド」、「代理管理特権 (DAP) に関する FAQ」、「代理管理者特権を対象とする NOBELIUM ガイド」を参照してください。

さらに、DAP は間もなく非推奨になります。 DAP を積極的に使用して顧客テナントを管理し、顧客のテナントを安全に管理するためにGranular の委任された管理者特権モデル最小限の特権に移行するすべてのパートナーを強くお勧めします。

顧客テナントを管理するための最小特権ロールへの移行

DAP は間もなく非推奨になるため、Microsoft では、現在の DAP モデル (管理者エージェントに永続的または永続的なグローバル管理者アクセスを提供する) から移行し、きめ細かい委任されたアクセス モデルに置き換えることを強くお勧めします。 きめ細かい委任されたアクセス モデルにより、顧客に対するセキュリティ リスクとそのリスクの影響が軽減されます。 また、顧客のサービスと環境を管理している従業員のワークロード レベルで顧客ごとのアクセスを制限する制御と柔軟性も提供されます。

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

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 セキュリティに関するすべてのベスト プラクティスに従うことが重要です。 詳細については、「CSP セキュリティのベスト プラクティス」を参照してください。

多要素認証の実装

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

セキュリティの既定値群

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

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

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

Note

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

実装に関してよくあるご質問 (FAQ)

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

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

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

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

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

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

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

作業中にユーザーによるモバイル デバイスの使用を禁止するポリシーがありますか。

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

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

どの自動化または統合で、認証にユーザー資格情報を使用する必要がありますか。

パートナー ディレクトリ内のサービス アカウントを含む各ユーザーに対して MFA を適用すると、認証にユーザー資格情報を使用する自動化や統合に影響を与える可能性があります。 このため、これらの状況でどのアカウントが使用されているかを特定することが重要です。 検討すべきアプリケーションやサービスの例についての次の一覧を確認してください。

  • 顧客に代わってリソースをプロビジョニングするときに使用されるコントロール パネル
  • 顧客への請求 (CSP プログラムに関連する場合) および顧客サポートに使用される任意のプラットフォームとの統合
  • Az、AzureRM、 Microsoft Graph PowerShell、およびその他のモジュールを使用する PowerShell スクリプト

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

環境を評価する

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

要件はどのように適用されるか

パートナーの組織に MFA の例外が以前に付与されている場合、CSP プログラムの一部として顧客テナントを管理するユーザーは、2022 年 3 月 1 日より前に Microsoft MFA 要件を有効にする必要があります。 MFA 要件に準拠しないと、顧客のテナント アクセスが失われる可能性があります。

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

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

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

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

重要

サードパーティのソリューションで想定される要求が発行されない場合は、ソリューションを開発したベンダーと協力して、実行する必要があるアクションを決定する必要があります。

リソースとサンプル

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

関連するコンテンツ