Microsoft 365 組織の一般的なセキュリティ ポリシー
組織は、organizationに Microsoft 365 を展開する際に心配する必要があります。 この記事で参照されている条件付きアクセス、アプリ保護、およびデバイス コンプライアンス ポリシーは、Microsoft の推奨事項とゼロ トラストの 3 つの指針に基づいています。
- 明確に確認する
- 最小特権を使用する
- 侵害を想定する
組織は、これらのポリシーをそのまま使用することも、ニーズに合わせてカスタマイズすることもできます。 可能であれば、運用ユーザーにロールアウトする前に、非運用環境でポリシーをテストします。 テストは、可能な効果を特定してユーザーに伝えるために重要です。
デプロイ体験の場所に基づいて、これらのポリシーを 3 つの保護レベルにグループ化します。
- 開始点 - 多要素認証、セキュリティで保護されたパスワードの変更、アプリ保護ポリシーを導入する基本的なコントロール。
- エンタープライズ - デバイスコンプライアンスを導入する拡張コントロール。
- 特殊なセキュリティ - 特定のデータ セットまたはユーザーに対して多要素認証を毎回必要とするポリシー。
次の図は、各ポリシーが適用される保護のレベルと、ポリシーが PC または電話とタブレット、またはデバイスの両方のカテゴリに適用されるかどうかを示しています。
この図は PDF ファイルとしてダウンロードできます。
ヒント
デバイスが目的のユーザーを所有していることを保証するために、Intuneにデバイスを登録する前に、多要素認証 (MFA) の使用を要求することをお勧めします。 デバイス コンプライアンス ポリシーを適用するには、Intuneにデバイスを登録する必要があります。
前提条件
アクセス許可
- 条件付きアクセス ポリシーを管理するユーザーは、条件付きアクセス管理者、セキュリティ管理者、またはグローバル管理者としてAzure portalにサインインできる必要があります。
- アプリ保護とデバイス コンプライアンス ポリシーを管理するユーザーは、Intune管理者またはグローバル管理者としてIntuneにサインインできる必要があります。
- 構成のみを表示する必要があるユーザーには、 セキュリティ閲覧者 ロールまたは グローバル閲覧者 ロールを割り当てることができます。
ロールとアクセス許可の詳細については、組み込みロールMicrosoft Entra記事を参照してください。
ユーザーの登録
使用を要求する前に、ユーザーが多要素認証に登録されていることを確認します。 Microsoft Entra ID P2 を含むライセンスがある場合は、Microsoft Entra ID 保護内の MFA 登録ポリシーを使用して、ユーザーの登録を要求できます。 私たちは 、コミュニケーションテンプレートを提供します, あなたは、ダウンロードしてカスタマイズすることができます, 登録を促進します.
グループ
これらの推奨事項の一部として使用されるすべてのMicrosoft Entra グループは、セキュリティ グループではなくMicrosoft 365 グループとして作成する必要があります。 この要件は、後で Microsoft Teams と SharePoint でドキュメントをセキュリティで保護する場合に、秘密度ラベルを展開する場合に重要です。 詳細については、Microsoft Entra IDの「グループとアクセス権について」の記事を参照してください。
ポリシーの割り当て
条件付きアクセス ポリシーは、ユーザー、グループ、管理者ロールに割り当てることができます。 Intuneアプリ保護ポリシーとデバイス コンプライアンス ポリシーは、グループにのみ割り当てることができます。 ポリシーを構成する前に、含めるユーザーと除外するユーザーを特定する必要があります。 通常、開始点の保護レベルのポリシーは、organizationのすべてのユーザーに適用されます。
ユーザーが ユーザー登録を完了した後に MFA を要求するためのグループの割り当てと除外の例を次に示します。
| 条件付きアクセス ポリシーのMicrosoft Entra | 含める | 除外 | |
|---|---|---|---|
| 開始点 | 中または高のサインイン リスクに多要素認証を要求する | すべてのユーザー |
|
| エンタープライズ | 低、中、または高のサインイン リスクに対して多要素認証を要求する | エグゼクティブ スタッフ グループ |
|
| 特殊なセキュリティ | 多要素認証を常に要求する | トップ シークレット プロジェクト バックアイ グループ |
|
グループとユーザーに高いレベルの保護を適用する場合は注意してください。 セキュリティの目的は、ユーザー エクスペリエンスに不必要な摩擦を加えないことです 。 たとえば、 トップ シークレット プロジェクト Buckeye グループ のメンバーは、プロジェクトの特殊なセキュリティ コンテンツに取り組んでいない場合でも、サインインするたびに MFA を使用する必要があります。 過度のセキュリティ摩擦は疲労につながる可能性があります。
Windows Hello for Businessや FIDO2 セキュリティ キーなどのパスワードレス認証方法を有効にして、特定のセキュリティ制御によって作成される摩擦を減らすことを検討できます。
緊急アクセス アカウント
すべての組織には、使用を監視し、ポリシーから除外する緊急アクセス アカウントが少なくとも 1 つ必要です。 これらのアカウントは、他のすべての管理者アカウントと認証方法がロックアウトされた場合、または使用できなくなった場合にのみ使用されます。 詳細については、「Microsoft Entra IDの緊急アクセス アカウントを管理する」の記事を参照してください。
除外
推奨される方法は、条件付きアクセスの除外にMicrosoft Entra グループを作成することです。 このグループでは、アクセスの問題のトラブルシューティング中にユーザーにアクセスを提供する手段が提供されます。
警告
このグループは、一時的なソリューションとしてのみ使用することをお勧めします。 このグループの変更を継続的に監視および監査し、除外グループが意図したとおりにのみ使用されていることを確認します。
既存のポリシーにこの除外グループを追加するには:
- 条件付きアクセス管理者、セキュリティ管理者、またはグローバル管理者としてAzure portalにサインインします。
- Microsoft Entra ID>セキュリティ>条件付きアクセスに移動します。
- 既存のポリシーを選択します。
- [ 割り当て] で、[ ユーザーまたはワークロード ID] を選択します。
- [除外] で、[ユーザーとグループ] を選択し、organizationの緊急アクセスまたは重大なアカウントと条件付きアクセスの除外グループを選択します。
展開
開始点ポリシーは、次の表に示す順序で実装することをお勧めします。 ただし、 エンタープライズ および 特殊なセキュリティ レベルの保護に対する MFA ポリシーは、いつでも実装できます。
開始点
| ポリシー | 詳細情報 | ライセンス |
|---|---|---|
| サインインのリスクが中、または高のときに MFA を要求する | Microsoft Entra ID 保護からのリスク データを使用して、リスクが検出されたときにのみ MFA を要求する | E5 セキュリティ アドオンを使用したMicrosoft 365 E5またはMicrosoft 365 E3 |
| 先進認証をサポートしないクライアントはブロックする | 先進認証を使用しないクライアントは、条件付きアクセス ポリシーをバイパスできるため、それらをブロックすることが重要です。 | Microsoft 365 E3 または E5 |
| 高リスク ユーザーはパスワードを変更する必要がある | アカウントに対してリスクの高いアクティビティが検出された場合、サインイン時にユーザーにパスワードの変更を強制します。 | E5 セキュリティ アドオンを使用したMicrosoft 365 E5またはMicrosoft 365 E3 |
| データ保護にアプリケーション保護ポリシーを適用する | プラットフォームごとに 1 つのIntune アプリ保護ポリシー (Windows、iOS/iPadOS、Android)。 | Microsoft 365 E3 または E5 |
| 承認済みのアプリとアプリ保護ポリシーを要求する | iOS、iPadOS、または Android を使用して、携帯電話とタブレットにモバイル アプリ保護ポリシーを適用します。 | Microsoft 365 E3 または E5 |
Enterprise
| ポリシー | 詳細情報 | ライセンス |
|---|---|---|
| サインイン リスクが低い、中、または高い場合に MFA を要求する | Microsoft Entra ID 保護からのリスク データを使用して、リスクが検出されたときにのみ MFA を要求する | E5 セキュリティ アドオンを使用したMicrosoft 365 E5またはMicrosoft 365 E3 |
| デバイス コンプライアンス ポリシーを定義する | 最小構成要件を設定します。 プラットフォームごとに 1 つのポリシー。 | Microsoft 365 E3 または E5 |
| 準拠した PC とモバイル デバイスが必要 | organizationにアクセスするデバイスの構成要件を適用します | Microsoft 365 E3 または E5 |
特殊なセキュリティ
| ポリシー | 詳細情報 | ライセンス |
|---|---|---|
| 常に MFA が必要 | ユーザーは、組織サービスにサインインするたびに MFA を実行する必要があります | Microsoft 365 E3 または E5 |
アプリ保護ポリシー
アプリ保護ポリシーは、許可されるアプリと、organizationのデータで実行できるアクションを定義します。 利用できる選択肢は多数あり、混乱を招く可能性があります。 次のベースラインは、お客様のニーズに合わせて調整できる Microsoft の推奨構成です。 従うテンプレートは 3 つ用意されていますが、ほとんどの組織はレベル 2 と 3 を選択すると考えています。
レベル 2 は 、開始点 または エンタープライズ レベルのセキュリティを考慮する内容にマップされ、レベル 3 は 特殊な セキュリティにマップされます。
レベル 1 のエンタープライズ基本データ保護 – Microsoft では、エンタープライズ デバイスの最小データ保護構成としてこの構成をお勧めします。
レベル 2 のエンタープライズ強化データ保護 – Microsoft では、ユーザーが機密情報または機密情報にアクセスするデバイスに対して、この構成をお勧めします。 この構成は、職場または学校のデータにアクセスするほとんどのモバイル ユーザーに適用されます。 一部のコントロールは、ユーザー エクスペリエンスに影響を与える可能性があります。
レベル 3 のエンタープライズ高データ保護 – Microsoft では、大規模または高度なセキュリティ チームを持つorganizationによって実行されるデバイス、または一意のリスクが高い特定のユーザーまたはグループ (未承認の開示によってorganizationに重大な損失が発生する機密性の高いデータを処理するユーザー) に対して、この構成をお勧めします。 十分な資金を持ち、洗練された敵対者の標的となる可能性が高いorganizationは、この構成を熱望する必要があります。
アプリ保護ポリシーを作成する
データ保護フレームワークの設定を使用して、Microsoft Intune内の各プラットフォーム (iOS および Android) の新しいアプリ保護ポリシーをCreateします。
- 「Microsoft Intuneを使用してアプリ保護ポリシーを作成して展開する方法」の手順に従って、ポリシーを手動で作成します。
- Intuneの PowerShell スクリプトを使用して、App Protection Policy Configuration Framework JSON テンプレートIntuneサンプルをインポートします。
デバイス コンプライアンス ポリシー
デバイス コンプライアンス ポリシー Intune、デバイスが準拠と判断するために満たす必要がある要件を定義します。
PC、電話、またはタブレット プラットフォームごとにポリシーを作成する必要があります。 この記事では、次のプラットフォームに関する推奨事項について説明します。
デバイス コンプライアンス ポリシーのCreate
デバイス コンプライアンス ポリシーを作成するには、Microsoft Intune管理センターにサインインし、[デバイス>コンプライアンス ポリシー ポリシー>] に移動します。 [ポリシーを作成する] を選択します。
Intuneでのコンプライアンス ポリシーの作成に関する詳細なガイダンスについては、「Microsoft Intuneのコンプライアンス ポリシーをCreateする」を参照してください。
iOS/iPadOS の登録とコンプライアンス設定
iOS/iPadOS ではいくつかの登録シナリオがサポートされていますが、そのうち 2 つはこのフレームワークの一部として扱われています。
- 個人所有デバイスのデバイス登録 - これらのデバイスは個人所有であり、仕事用と個人用の両方で使用されます。
- 企業所有デバイスの自動デバイス登録 – これらのデバイスは、企業所有で、1 人のユーザーに関連付け、個人使用ではなく仕事専用で使用されます。
ゼロ トラスト ID とデバイス のアクセス構成で説明されている原則を使用します。
個人登録デバイスのコンプライアンス設定
- 個人用の基本的なセキュリティ (レベル 1) – Microsoft では、ユーザーが職場または学校のデータにアクセスする個人用デバイスの最小セキュリティ構成として、この構成をお勧めします。 この構成は、パスワード ポリシー、デバイス ロック特性を適用し、信頼されていない証明書などの特定のデバイス機能を無効にすることによって行われます。
- 個人用の強化されたセキュリティ (レベル 2) – Microsoft では、ユーザーが機密情報または機密情報にアクセスするデバイスに対して、この構成をお勧めします。 この構成では、データ共有の統制を適用します。 この構成は、デバイス上の職場や学校のデータにアクセスするほとんどのモバイル ユーザーに適用されます。
- 個人用の高セキュリティ (レベル 3) – Microsoft では、一意のリスクが高い特定のユーザーまたはグループ (不正な開示によってorganizationに重大な損失が発生する機密性の高いデータを処理するユーザー) によって使用されるデバイスに対して、この構成をお勧めします。 この構成では、より強力なパスワード ポリシーが適用され、特定のデバイス機能が無効になり、追加のデータ転送制限が適用されます。
自動デバイス登録のコンプライアンス設定
- 監視対象の基本的なセキュリティ (レベル 1) – Microsoft では、ユーザーが職場または学校のデータにアクセスする監視対象デバイスの最小セキュリティ構成として、この構成をお勧めします。 この構成は、パスワード ポリシー、デバイス ロック特性を適用し、信頼されていない証明書などの特定のデバイス機能を無効にすることによって行われます。
- 監視対象の強化されたセキュリティ (レベル 2) – Microsoft では、ユーザーが機密情報または機密情報にアクセスするデバイスに対して、この構成をお勧めします。 この構成では、データ共有の統制を適用し、USB デバイスへのアクセスをブロックします。 この構成は、デバイス上の職場や学校のデータにアクセスするほとんどのモバイル ユーザーに適用されます。
- 監視対象の高セキュリティ (レベル 3) – Microsoft では、一意のリスクが高い特定のユーザーまたはグループ (不正な開示によってorganizationに重大な損失が発生する機密性の高いデータを処理するユーザー) によって使用されるデバイスに対して、この構成をお勧めします。 この構成では、より強力なパスワード ポリシーが適用され、特定のデバイス機能が無効になり、追加のデータ転送制限が適用され、Apple のボリューム購入プログラムを通じてアプリをインストールする必要があります。
Android の登録とコンプライアンスの設定
Android Enterprise では、いくつかの登録シナリオがサポートされています。そのうちの 2 つについては、このフレームワークの一部として説明します。
- Android Enterprise 仕事用プロファイル – この登録モデルは、通常、個人所有のデバイスに使用されます。IT は、仕事用データと個人データの間に明確な分離境界を提供したいと考えています。 IT によって制御されるポリシーにより、仕事用データを個人プロファイルに転送できなくなります。
- Android Enterprise のフル マネージド デバイス - これらのデバイスは企業所有で、1 人のユーザーに関連付け、個人的な使用ではなく、仕事専用で使用されます。
Android Enterprise セキュリティ構成フレームワークは、いくつかの個別の構成シナリオに編成され、仕事用プロファイルとフル マネージド シナリオのガイダンスが提供されます。
ゼロ トラスト ID とデバイス のアクセス構成で説明されている原則を使用します。
Android Enterprise 仕事用プロファイル デバイスのコンプライアンス設定
- 個人所有の仕事用プロファイル デバイスで使用できる設定のため、基本的なセキュリティ (レベル 1) は提供されません。 使用可能な設定によって、レベル 1 とレベル 2 の差異が正当化されることはありません。
- 仕事用プロファイルのセキュリティ強化 (レベル 2) – Microsoft では、ユーザーが職場または学校のデータにアクセスする個人用デバイスの最小セキュリティ構成として、この構成をお勧めします。 この構成では、パスワード要件が導入され、仕事用のデータと個人データが分離され、Android デバイスの構成証明が検証されます。
- 仕事用プロファイルの高いセキュリティ (レベル 3) – Microsoft では、一意のリスクが高い特定のユーザーまたはグループ (不正な開示によってorganizationに重大な損失が発生する機密性の高いデータを処理するユーザー) によって使用されるデバイスに対して、この構成をお勧めします。 この構成では、モバイル脅威防御またはMicrosoft Defender for Endpointが導入され、Android の最小バージョンが設定され、より強力なパスワード ポリシーが適用され、作業と個人の分離がさらに制限されます。
Android Enterprise フル マネージド デバイスのコンプライアンス設定
- フル マネージドの基本的なセキュリティ (レベル 1) – Microsoft では、エンタープライズ デバイスの最小セキュリティ構成としてこの構成をお勧めします。 この構成は、職場または学校のデータにアクセスするほとんどのモバイル ユーザーに適用されます。 この構成では、パスワード要件が導入され、Android の最小バージョンが設定され、特定のデバイス制限が適用されます。
- フル マネージドの強化されたセキュリティ (レベル 2) – Microsoft では、ユーザーが機密情報または機密情報にアクセスするデバイスに対して、この構成をお勧めします。 この構成により、より強力なパスワード ポリシーが適用され、ユーザー/アカウント機能が無効になります。
- フル マネージドの高セキュリティ (レベル 3) - Microsoft では、一意のリスクが高い特定のユーザーまたはグループによって使用されるデバイスに対して、この構成をお勧めします。 これらのユーザーは、不正な開示によってorganizationに重大な損失が生じる可能性がある、機密性の高いデータを処理できます。 この構成により、Android の最小バージョンが増え、モバイル脅威防御またはMicrosoft Defender for Endpointが導入され、追加のデバイス制限が適用されます。
Windows 10以降の推奨コンプライアンス設定
次の設定は、Windows 10以降のデバイスのコンプライアンス ポリシー作成プロセスの手順 2: コンプライアンス設定で構成されています。 これらの設定は、id とデバイスのアクセス構成ゼロ トラスト記載されている原則と一致します。
デバイス正常性 > Windows 正常性構成証明サービスの評価規則については、次の表を参照してください。
| プロパティ | 値 |
|---|---|
| BitLocker が必要 | 必須 |
| デバイスでセキュア ブートを有効にする必要がある | 必須 |
| コードの整合性を要求する | 必須 |
[ デバイスのプロパティ] で、IT とセキュリティ ポリシーに基づいてオペレーティング システムのバージョンに適切な値を指定します。
[Configuration Managerコンプライアンス] で、Configuration Managerで共同管理環境にいる場合は、[それ以外の場合は必須] を選択し、[未構成] を選択します。
システム セキュリティについては、次の表を参照してください。
| プロパティ | 値 |
|---|---|
| モバイル デバイスのロックを解除するパスワードを要求する | 必須 |
| 単純なパスワード | ブロック |
| パスワードの種類 | デバイスの既定値 |
| パスワードの最小文字数 | 6 |
| パスワードが必要になるまでの非アクティブ時間の最大時間 (分) | 15 分 |
| パスワードの有効期限 (日) | 41 |
| 再使用を禁止するパスワード世代数 | 5 |
| デバイスがアイドル状態から戻るときにパスワードを要求する (モバイルとホログラフィック) | 必須 |
| デバイス上のデータ ストレージの暗号化を要求する | 必須 |
| ファイアウォール | 必須 |
| ウイルス対策 | 必須 |
| スパイウェア対策 | 必須 |
| Microsoft Defender マルウェア対策 | 必須 |
| Microsoft Defender マルウェア対策の最小バージョン | Microsoft では、最新バージョンから 5 つ以下のビハインド バージョンをお勧めします。 |
| Microsoft Defenderマルウェア対策シグネチャを最新の状態に保つ | 必須 |
| リアルタイム保護 | 必須 |
Microsoft Defender for Endpoint
| プロパティ | 値 |
|---|---|
| デバイスがマシン リスク スコアの下にあるか、または下にある必要がある | 中 |
条件付きアクセス ポリシー
アプリ保護ポリシーとデバイス コンプライアンス ポリシーがIntuneで作成されたら、条件付きアクセス ポリシーで適用を有効にすることができます。
サインイン リスクに基づいて MFA を要求する
「一般的な条件付きアクセス ポリシー: サインイン リスクベースの多要素認証」のガイダンスに従って、サインイン リスクに基づいて多要素認証を要求するポリシーを作成します。
ポリシーを構成するときは、次のリスク レベルを使用します。
| 保護レベル | 必要なリスク レベルの値 | アクション |
|---|---|---|
| 開始点 | 高、中 | 両方を確認します。 |
| Enterprise | 高、中、低 | 3 つすべてを確認します。 |
多要素認証をサポートしていないクライアントをブロックする
「一般的な条件付きアクセス ポリシー: レガシ認証をブロックしてレガシ認証をブロックする」のガイダンスに従ってください。
高リスク ユーザーはパスワードを変更する必要がある
「一般的な条件付きアクセス ポリシー: ユーザー リスクベースのパスワード変更」の記事のガイダンスに従って、資格情報が侵害されたユーザーにパスワードの変更を要求します。
このポリシーは、Microsoft Entraパスワード保護と共に使用します。これは、organizationに固有の用語に加えて、既知の脆弱なパスワードとそのバリエーションを検出してブロックします。 パスワード保護Microsoft Entra使用すると、変更されたパスワードがより強力になります。
承認済みのアプリとアプリ保護ポリシーを要求する
Intuneで作成されたアプリ保護ポリシーを適用するには、条件付きアクセス ポリシーを作成する必要があります。 アプリ保護ポリシーを適用するには、条件付きアクセス ポリシー と 対応するアプリ保護ポリシーが必要です。
承認されたアプリとアプリ保護を必要とする条件付きアクセス ポリシーを作成するには、「 モバイル デバイスで承認済みのクライアント アプリまたはアプリ保護ポリシーを要求する」の手順に従います。 このポリシーでは、アプリ保護ポリシーによって保護されたモバイル アプリ内のアカウントのみが Microsoft 365 エンドポイントにアクセスできます。
iOS および Android デバイス上の他のクライアント アプリのレガシ認証をブロックすると、これらのクライアントが条件付きアクセス ポリシーをバイパスできなくなります。 この記事のガイダンスに従っている場合は、 先進認証をサポートしていないクライアントのブロックを既に構成しています。
準拠した PC とモバイル デバイスが必要
次の手順は、リソースにアクセスするデバイスがorganizationのIntuneコンプライアンス ポリシーに準拠としてマークされるように要求する条件付きアクセス ポリシーを作成するのに役立ちます。
注意
このポリシーを有効にする前に、デバイスが準拠していることを確認してください。 それ以外の場合は、ユーザー アカウントが条件付きアクセスの除外グループに追加されるまで、ロックアウトされ、このポリシーを変更できません。
- Azure portal にサインインし
- Microsoft Entra ID>セキュリティ>条件付きアクセスに移動します。
- [ 新しいポリシー] を選択します。
- ポリシーに名前を付けます。 組織は、ポリシーの名前に意味のある標準を作成することをお勧めします。
- [ 割り当て] で、[ ユーザーまたはワークロード ID] を選択します。
- [対象] で、[すべてのユーザー] を選択します。
- [除外] で、[ユーザーとグループ] を選択し、organizationの緊急アクセスまたは割り込みアカウントを選択します。
- [ クラウド アプリまたはアクション>を含める] で、[ すべてのクラウド アプリ] を選択します。
- ポリシーから特定のアプリケーションを除外する必要がある場合は、[除外されたクラウド アプリの選択] の下の [除外] タブから選択し、[選択] を選択できます。
- [アクセス制御の許可] の下に表示されます>。
- [デバイスは準拠としてマーク済みである必要があります] を選択します。
- [ 選択] を選択します。
- 設定を確認し、[ポリシーの有効化] を [オン] にします。
- [Create] を選択して作成し、ポリシーを有効にします。
注:
ポリシーの [すべてのユーザー] と [すべてのクラウド アプリ] で [デバイスを準拠としてマークする必要がある] を選択した場合でも、新しいデバイスをIntuneに登録できます。 デバイスを準拠コントロールとしてマークする必要がある場合、Intune登録とMicrosoft Intune Web ポータル サイト アプリケーションへのアクセスはブロックされません。
サブスクリプションのアクティブ化
サブスクリプション ライセンス認証機能を使用してユーザーが Windows のバージョン間で "ステップアップ" できるようにする組織では、ユニバーサル ストア サービス API と Web アプリケーション、AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f をデバイス コンプライアンス ポリシーから除外できます。
常に MFA が必要
「一般的な条件付きアクセス ポリシー: すべてのユーザーに MFA を要求する」の記事のガイダンスに従って、特殊なセキュリティ レベルのユーザーが常に多要素認証を実行するように要求します。
警告
ポリシーを構成するときは、特殊なセキュリティを必要とするグループを選択し 、[すべてのユーザー] を選択するのではなく、そのグループを使用します。
次の手順
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示