この記事では、Microsoft Defender ウイルス対策(MDAV) および Microsoft Defender for Endpoint(MDE) の検知機能と、ウイルス対策スキャン除外設定に関するよくあるお問い合わせについておまとめいたします。

なお、本情報の内容（添付文書、リンク先などを含む）は、作成日時点(2024 年 10 月 21 日)でのものであり、予告なく変更される場合があります。

MDAV の除外設定に関する最新の情報については以下の公開情報を参照してください。

参考情報：Microsoft Defender ウイルス対策のカスタム除外を構成する | Microsoft Learn

※ 本記事では、Microsoft Defender ウイルス対策を MDAV、Microsoft Defender for Endpoint を MDE と記載します。

本記事の内容

• ウイルス対策のカスタム除外設定について
  • ウイルス対策の除外設定とは
  • ウイルス対策除外の主な目的
  • ウイルス対策の除外設定で抑制可能な検知イベントについて
• 検知イベントから検出ソースを特定する方法
  • 検知イベントをウイルス対策スキャンの除外で抑制可能か確認する方法
  • MDE の EDR 機能による検出アラートについて
  • MDE の自動調査機能による検出と修復について
  • SmartScreen によるファイルダウンロード時の警告について
  • SmartScreen によるアプリ実行時の警告について
  • 攻撃面の減少ルールにより操作がブロックされた場合のイベントについて
  • フォルダアクセスコントロールによる保護されたフォルダへのアクセスブロックについて
• ファイルとフォルダのパスを使用してウイルス対策の除外を構成する
  • ファイルとフォルダのパスを使用するウイルス対策の除外の概要
  • グループポリシーを使用してパスに基づく除外を構成する
  • Intune を使用してパスに基づく除外を構成する
  • PowerShell を使用してパスに基づく除外を構成する
• プロセス除外を構成する
  • プロセス除外の概要
  • グループポリシーを使用してプロセス除外を構成する
  • Intune を使用してプロセス除外を構成する
  • PowerShell を使用してプロセス除外を構成する
• ウイルス対策の除外設定に関するよくある問い合わせ
  • ウイルス対策除外のベストプラクティスを教えてください
  • ファイルが誤ってマルウェアとして検出された場合の対処方法を教えてください
  • ウイルス対策の除外設定を追加しても検出が止まりません
  • ウイルス対策の除外設定を追加してもプログラムやスクリプトの実行がブロックされます
  • ファイルインジケータを登録した後もファイルの検出が行われます
  • ウイルス対策の除外を追加しても MDE のアラート検出が行われます
  • Windows セキュリティアプリや PowerShell から除外を追加できません
  • 環境変数を使用したパス除外が有効に動作しません
  • CPU 使用率の高騰を解消するためにどのファイルを除外すればいいですか？
• MDAV により CPU 使用率が高騰している場合のトラブルシューティング
  • ウイルス対策スキャンが CPU リソースを消費する理由
  • システムで CPU 使用率が高騰している場合の確認ポイント
• まとめ

ウイルス対策のカスタム除外設定について

ウイルス対策のカスタム除外設定とは、MDAV のスケジュールスキャン、手動スキャン(オンデマンドスキャン)、およびリアルタイムスキャンから特定の対象を除外するために使用可能な設定です。

ウイルス対策の除外設定が適切に構成されている場合、対象のファイルは MDAV によるスキャンおよび検出が行われなくなります。

ウイルス対策の除外設定とは

ウイルス対策の除外設定は、MDAV が行うスケジュールスキャン、手動スキャン(オンデマンドスキャン)、およびリアルタイムスキャンの対象からファイルを除外できる機能です。

ウイルス対策の除外設定は、主に特定のファイルの誤検出/過検出を抑制する目的や、システムのパフォーマンスの改善を行う目的で利用されます。

ただし、ウイルス対策の除外設定はセキュリティレベルの低下をもたらす恐れがある点に注意が必要です。

ウイルス対策の除外を設定する場合は、除外設定によるリスクを常に評価し、悪意のないと確信しているファイルのみを対象とする必要があります。

参考情報：Microsoft Defender ウイルス対策のカスタム除外を構成する | Microsoft Learn

MDAV のカスタム除外設定では、大きく分けて以下の 2 つの種類の除外を構成することが可能です。(IP アドレスの除外を除く)

• ファイルとフォルダのパス、もしくは拡張子に基づく除外
• プロセス除外

「ファイルとフォルダのパス、もしくは拡張子に基づく除外」では、設定した拡張子を持つファイルや、指定したパスに存在するファイルおよびフォルダをウイルス対策のスキャン対象から除外することができます。

一方、「プロセス除外」では、特定のプロセスによって開かれたファイルをウイルス対策のスキャン対象から除外することができます。

ウイルス対策の除外を構成する場合は除外の目的や対象に合わせて適切な設定方法を検討する必要があります。

ウイルス対策除外の主な目的

ウイルス対策の除外設定は、主に以下の 3 つの用途で利用できます。

• MDAV のリアルタイム保護機能に起因するパフォーマンスの問題の軽減

• 特定のアプリケーションとの互換性に関連する問題の解消

• MDAV のウイルス対策機能による検出の抑制

参考情報：除外に関する重要なポイント | Microsoft Learn

ウイルス対策の除外設定で抑制可能な検知イベントについて

ウイルス対策の除外機能は、MDAV のスケジュールスキャン、手動スキャン(オンデマンドスキャン)、およびリアルタイムスキャンの対象から特定のファイルを除外することができる機能です。

ウイルス対策の除外設定を適用した場合には、上記のウイルス対策スキャンによるファイルの検出を抑止することができます。

一方で、検出対象がファイル以外の場合や、MDE の EDR 保護機能、または SmartScreen などウイルス対策以外の保護機能による検出の場合は、関連するファイルをウイルス対策の除外対象に追加した場合でも引き続き検出が行われる場合があります。

そのため、Microsoft のセキュリティ保護機能による検出抑制することを目的として除外を追加する場合には、対象の検知イベントに関連する機能を特定することが非常に重要です。

現在ユーザの環境で発生している検出イベントがウイルス対策の除外で抑制可能なものであるか否かについては、検知イベントから検出ソースを特定する方法 の項を手順を参照してください。

検知イベントから検出ソースを特定する方法

MDAV および MDE を利用する Windows マシンでは、ウイルス対策スキャン以外の様々なセキュリティ保護機能によって操作のブロックやアラート検出が発生する場合があります。

もし特定の検知イベントを抑制する目的でウイルス対策の除外設定を検討している場合は、事前に対象の検知イベントが MDAV のウイルス対策機能により発生したものであるか確認する必要があります。

現在発生している検出イベントが MDAV のウイルス対策機能により発生したものであるか確認する方法については 検知イベントをウイルス対策スキャンの除外で抑制可能か確認する方法 の記載を参照してください。

検知イベントをウイルス対策スキャンの除外で抑制可能か確認する方法

MDAV のウイルス対策機能によりファイルが検出された場合、既定では以下の画像のようなデスクトップ通知が行われます。(画面は Windows 11 のものです)

また、MDE を利用している場合、MDAV のウイルス対策機能によりファイルが検出された際に生成されるアラートを参照すると、[アラートの詳細]>[検出ソース] が [ウイルス対策] として表示されることを確認できます。

このような検知イベントを MDAV のウイルス対策の除外で抑制可能かどうか確認したい場合、以下の手順で MDAV のイベントログの情報を調査します。

参考情報：Microsoft Defender ウイルス対策イベントの ID とエラー コード | Microsoft Learn

1. イベントビューアを使用して [アプリケーションとサービスログ]>[Microsoft]>[Windows]>[Windows Defender]>[Operational] を開き、イベント ID 1116：MALWAREPROTECTION_STATE_MALWARE_DETECTED のログを検索します。

2. ID 1116 の検知イベントを特定したら、[パス] に file:_ から始まる検出対象のファイルパスが記載されていることを確認します。
   ※ 検知が発生した時刻に ID 1116 の検知イベントが記録されていない場合、検出または操作のブロックは MDAV のウイルス対策以外の保護機能により行われている可能性があります。

3. 検知が発生した時刻に記録された ID 1116 の検知イベントとファイルパスを確認したら、[検出元] の情報が [リアルタイム保護] や [システム]、または [ユーザー] などと表示されていることを確認します。
   ※ 対象の検知イベントの [検出元] が [Microsoft Defender for Endpoint] である場合には MDAV のウイルス対策の除外設定を追加してもファイルの検出を抑制することはできない場合があります。

4. イベントログから対象の検知が MDAV のウイルス対策機能によるものであることを確認したら、ファイルとフォルダのパスを使用して除外を構成する または プロセス除外を構成する、ファイルの拡張子を使用して除外を構成する のいずれか適切な手順にて、対象のファイルを MDAV の検出対象から除外することができます。

MDE の EDR 機能による検出アラートについて

ユーザが MDE を利用している場合、Microsoft Defender ポータル の [インシデントとアラート]>[アラート] に、端末で発生した検知アラートが一覧表示されます。

この時、[検出ソース] に [EDR] と表示されているアラートは通常、MDE の EDR 保護機能により検出されたアラートに該当します。

MDE の EDR 機能による検出アラートは、本記事で紹介するウイルス対策のカスタム除外設定で抑制することはできません。

検出ソースが [EDR] であるアラート検出を抑制したい場合には、Microsoft Defender ポータルからアラート調整ルール(アラート抑制ルール) を作成します。

MDE の自動調査機能による検出と修復について

ユーザの端末が MDE にオンボードされている場合、特定のファイルをウイルス対策の除外対象としている場合でも、自動調査と修復機能によって除外対象のファイルの検出・隔離が行われる場合があります。

参考情報：自動調査を使用して脅威を調査・修復する | Microsoft Learn

MDE を利用する環境で、ウイルス対策の除外にファイルを追加しても [検出元] が [Microsoft Defender for Endpoint] となる検出が継続する場合には、誤検出であることを確認済みの既存のアラート/インシデントをすべて解決済みに変更した上で、許可したいファイルのファイルハッシュをファイルインジケータに登録してください。

参考情報：インジケーターの作成 | Microsoft Learn

SmartScreen によるファイルダウンロード時の警告について

ユーザが Microsoft Edge を利用してファイルのダウンロードを行う場合、Microsoft Defender SmartScreen による警告やダウンロードのブロックが行われる場合があります。

Microsoft Defender SmartScreen はウイルス対策機能の除外設定の影響を受けないため、ウイルス対策の除外設定でファイルダウンロード時の警告を抑制することはできません。

以下は、どちらも SmartScreen によってファイルのダウンロードがブロックされた場合の通知の例です。

また、ダウンロードするファイルが既知の安全な、もしくは悪意のあるファイルではない場合、不明なファイルとしてダウンロード時に以下の警告が表示されます。

不明なファイルの警告はユーザへの注意喚起を目的としており、安全なファイルをダウンロードする場合にも通知される場合があります。

SmartScreen によるアプリ実行時の警告について

ユーザーの端末で Microsoft Defender SmartScreen による [アプリとファイルの確認] の設定が有効化されている場合、インターネットからダウンロードしたプログラムを実行する際に以下の警告が表示される場合があります。

また、[アプリとファイルの確認] の設定を有効化していない場合でも、ファイルの実行時に以下の警告が表示される場合があります。

これらの警告は MDAV のウイルス対策機能による検出ではないため、ブロック対象のファイルやフォルダを MDAV のウイルス対策除外の対象に登録している場合でも警告が行われます。

インターネットから取得したプログラムが安全なファイルであることを確認している場合には、警告を無視してプログラムを実行するか、ファイルを実行する前に対象のファイルを右クリックし、[プロパティ] から以下のチェックボックスにチェックを入れてファイルを許可してください。

攻撃面の減少ルールにより操作がブロックされた場合のイベントについて

Windows 端末では、攻撃面の減少ルール(ASR ルール) による端末の保護を有効化することができます。

ASR ルールは、攻撃者が組織のデバイスやネットワークを侵害する可能性のある攻撃対象を減らすための保護機能です。

ASR ルールを適切に構成すると、悪意のある攻撃者がデバイスやネットワークを侵害するために悪用する方法(攻撃面) を少なくすることができます。

参考情報：攻撃面の縮小ルールの概要 | Microsoft Learn

ASR ルールによるブロックが発生した場合、既定では以下のようなポップアップ通知が行われます。(利用中の OS バージョンによって通知画面の表示が異なる場合があります)

また、イベントビューアを使用して [アプリケーションとサービスログ]>[Microsoft]>[Windows]>[Windows Defender]>[Operational] のイベントログを開き、ID 1121 のイベントを参照することで ASR ルールによるブロックされた操作の詳細を確認できます。

ASR ルールによる操作のブロックは、MDAV のウイルス対策機能とは異なる機能によるものですが、多くの ASR ルールは MDAV のウイルス対策除外に設定したフォルダやファイルを ASR ルールの除外対象としても利用します。

しかし、一部の ASR ルールによる検出はウイルス対策除外設定の影響を受けないため、別途 ASR ルールの除外設定を構成する必要があります。

ウイルス対策の除外設定が 適用されない ASRルールについては、以下の公開情報の一覧を参照してください。

参考情報：Microsoft Defender ウイルス対策の除外と ASR ルール | Microsoft Learn

なお、ASR ルールの除外を設定する方法については以下を参照してください。

参考情報：攻撃面の縮小ルールからファイルとフォルダーを除外する | Microsoft Learn

フォルダアクセスコントロールによる保護されたフォルダへのアクセスブロックについて

MDAV のリアルタイム保護機能を有効化している Windows 端末では、フォルダアクセスコントロール機能により信頼されていないプログラムから保護されたフォルダ内のデータを保護することができます。

フォルダアクセスコントロール機能によって保護されたフォルダ内のデータ変更がブロックされた場合、既定では以下のポップアップ通知が行われます。

また、イベントビューアを使用して [アプリケーションとサービスログ]>[Microsoft]>[Windows]>[Windows Defender]>[Operational] のイベントログを開き、ID 1123 のイベントを参照することでもフォルダーアクセスコントロール機能によるブロックが発生したことを確認できます。

フォルダアクセスコントロールによる変更のブロックを抑制したい場合、保護されたフォルダにアクセスしているアプリケーションを「信頼されたアプリの一覧」に追加する必要があります。

ファイルとフォルダのパスを使用してウイルス対策の除外を構成する

この項では、MDAV のウイルス対策除外の詳細と、各管理ツールを用いた設定方法を紹介します。

ファイルとフォルダのパスを使用するウイルス対策の除外の概要

ファイルとフォルダのパスを使用した除外を構成すると、特定のフォルダやファイルをウイルス対策のスキャン対象から除外することができます。

特定のファイルのみをスキャン除外の対象としたい場合、以下の例のように対象ファイルの完全パスを除外対象に追加します。

1
2

C:\TEST\eicar.txt

特定のフォルダ内のファイルをすべて除外対象に含める場合は、対象のフォルダの完全パスを指定します。

フォルダパスを除外対象に指定した場合、サブフォルダ内のファイルを含む、そのフォルダ内のすべてのファイルが除外対象に含まれます。(以下のフォルダを除外した場合、C:\TEST\eicar.txt や C:\TEST\SUB\eicar.txt、C:\TEST\SUB\SUB2\eicar.txt などのすべてのファイルが除外対象に含まれます。)

1
2

# フォルダパスを除外対象に指定する(サブフォルダ内のファイルを含むすべてのファイルが除外対象に含まれる)
C:\TEST

なお、上記の例では除外対象の完全パスを指定する際にドライブレター C:\ を使用しています。

しかし、もし除外したいファイルがネットワークフォルダ内に存在している場合には、ドライブレターではなく、\\ から始まる UNC パスを除外対象に含める必要がある点に注意が必要です。

例えば、システムにマップされたネットワークフォルダに E:\ などのドライブレターを割り当てている場合でも、E:\Folder のようなパスによる除外設定を行うことはできません。

このようなネットワークフォルダを除外対象とする場合には \\<ネットワークフォルダのアドレス>\Folder のように実際のネットワークパスを除外対象に指定する必要があります。

参考情報：拡張機能、名前、または場所に基づいて除外を構成して検証する | Microsoft Learn

また、ファイルとフォルダのパスを使用して除外を構成する場合、除外対象のパスの指定にはワイルドカード(* または ?) を使用することができます。

以下に、ウイルス対策の除外における一般的なワイルドカードの使用例を紹介します。

この例では、C:\Users フォルダ直下のユーザアカウント名のフォルダ階層をワイルドカードに置換することで、1 つの除外エントリで複数のユーザフォルダ内のファイルを除外対象に指定しています。(C:\Users\user01\Documents\eicar.txt や C:\Users\user02\Documents\eicar.txt などのファイルが除外対象に含まれます。)

1
2

# ユーザアカウント名をワイルドカードに置き換えてパス除外を指定する
C:\Users\*\Documents\eicar.txt

また、以下の例のようにフォルダではなく、ファイル名部分をワイルドカードに置き換えることも可能です。

このような指定を行った場合、C:\TEST フォルダ直下に配置されている、拡張子が .exe のファイルのみが除外対象に含まれます。(サブフォルダ内のファイルは除外対象に含まれないため、C:\TEST\SUB\program.exe などのファイルは除外されません。)

1
2

# ファイル名部分のみをワイルドカードに置き換えてパス除外を指定する
C:\TEST\*.exe

さらに、ファイル名をワイルドカードに置き換える場合、以下のようにファイル名の一部分のみを置換することも可能です。

例えば、C:\TEST\program0*.exe を除外エントリに追加した場合、C:\TEST\program001.exe や C:\TEST\program010.exe などのファイルが除外対象に含まれます。一方で、C:\TEST\program100.exe などのファイルは除外されません。

1
2

# ファイル名の連番部分のみをワイルドカードに置き換えてパス除外を指定する
C:\TEST\program0*.exe

ファイルとフォルダのパスを使用する除外設定でワイルドカードを使用する場合の利用例や制限事項については以下の公開情報を参照します。

参考情報：ファイル名とフォルダパスまたは拡張機能の除外リストでワイルドカードを使用する | Microsoft Learn

グループポリシーを使用してパスに基づく除外を構成する

グループポリシーを使用してパスに基づく除外を構成する場合、コンピュータの構成から、[管理用テンプレート]>[Windows コンポーネント]>[Microsoft Defender ウイルス対策]>[除外] 内の [パスの除外] を使用します。

除外を構成する場合は、[値の名前] 列に除外対象に指定するパスを、[値] 列に 0 を入力します。

なお、グループポリシーでパスに基づく除外を構成する場合、空のエントリを登録しようとすると以下のようなメッセージが表示され、ポリシーの有効化に失敗します。

もし、ポリシーに登録している除外エントリをすべて削除したい場合は、[パスの除外] ポリシーの設定を [無効] もしくは [未構成] に変更してください。

Intune を使用してパスに基づく除外を構成する

Intune を使用してウイルス対策のパスに基づく除外を構成する場合、[エンドポイントセキュリティ]>[ウイルス対策] にて [+ポリシーの作成] をクリックし、Windows プラットフォーム用の [Microsoft Defender ウイルス対策の除外] ポリシーを作成します。

作成したポリシーの [除外されたパス] に、除外対象のパスのエントリを追加します。

作成したポリシーを Intune からデバイスもしくはユーザに割り当てることで除外設定を適用することができます。

PowerShell を使用してパスに基づく除外を構成する

ポリシーではなく端末側で除外設定の追加を行う場合、PowerShell の Set-MpPreference コマンドレットか Add-MpPreference コマンドレットを使用することができます。

Set-MpPreference コマンドレットを使用してファイルやフォルダのパスを除外に追加するには、以下のコマンドレットを使用します。

1
2

# Set-MpPreference コマンドレットで複数のファイルとフォルダのパスを除外対象に指定する
Set-MpPreference -ExclusionPath @("C:\TEST\eicar.txt", "C:\TEST\SUB1","C:\Users\*\Documents")

Set-MpPreference コマンドレットを使用して登録した除外リストは、再度 Set-MpPreference コマンドレットによる除外を登録すると、すでに Set-MpPreference コマンドレットにより登録されていた除外リストが上書きされます。(ただし、グループポリシーなど、異なる管理ツールで追加している除外エントリは Set-MpPreference コマンドレットを使用しても上書きされません。)

そのため、PowerShell を利用して除外を構成している環境にて、既存の除外リストに新しい除外を追加する場合は Add-MpPreference コマンドレットを使用します。

1
2
3
4

# Set-MpPreference で作成した除外リストに Add-MpPreference でエントリの追加を行う
Set-MpPreference -ExclusionPath @("C:\TEST\eicar.txt")
Add-MpPreference -ExclusionPath @("C:\TEST\ADD\eicar.txt")
Add-MpPreference -ExclusionPath @("C:\TEST\ADD2\eicar.txt")

なお、Set-MpPreference や Add-MpPreference で追加した除外エントリは Remove-MpPreference コマンドレットを使用することで削除できます。

1
2

# PowerShell で追加した除外エントリを Remove-MpPreference で削除する
Remove-MpPreference -ExclusionPath @("C:\TEST\eicar.txt", "C:\TEST\SUB1","C:\Users\*\Documents")

プロセス除外を構成する

プロセス除外の概要

MDAV における「プロセス除外」とは、「特定のプロセスが開いたファイル」をウイルス対策のスキャン対象から除外する機能です。

例えば、C:\sample\test.exe というファイルをプロセス除外の対象に指定すると、「C:\sample\test.exe のプロセスが開いたファイル」がウイルス対策のスキャンから除外されます。

プロセス除外の対象とする実行ファイルを指定する際には、対象ファイルの完全パスだけでなく、実行ファイルのファイル名のみを指定することも可能です。

例えば、test.exe を除外対象に指定した場合、C:\sample\test.exe や C:\internal\files\test.exe のプロセスによって開かれたファイルが除外対象となります。

プロセス除外設定に関する詳細は以下の公開情報を参照してください。

参考情報：特定のプロセスによって開かれたファイルの除外を構成する| Microsoft Learn

グループポリシーを使用してプロセス除外を構成する

グループポリシーを使用してプロセス除外を構成する場合、コンピュータの構成から、[管理用テンプレート]>[Windows コンポーネント]>[Microsoft Defender ウイルス対策]>[除外] 内の [プロセスの除外] を使用します。

除外を構成する場合は、[値の名前] 列に除外対象に指定する実行ファイルのパスを、[値] 列に 0 を入力します。

Intune を使用してプロセス除外を構成する

Intune を使用してプロセス除外を構成する場合、[エンドポイントセキュリティ]>[ウイルス対策] にて作成した、Windows プラットフォーム用の [Microsoft Defender ウイルス対策の除外] ポリシーの [除外されたプロセス] に除外対象のエントリを登録します。

PowerShell を使用してプロセス除外を構成する

PowerShell を使用してパスに基づく除外を構成する と同じく、Set-MpPreference および Add-MpPreference コマンドレットを使用することでプロセス除外を設定することができます。

1
2
3
4

# Set-MpPreference で作成した除外リストに Add-MpPreference でエントリの追加を行う
Set-MpPreference -ExclusionProcess @("C:\TEST\program.exe")
Add-MpPreference -ExclusionProcess @("C:\TEST2\program.exe")
Add-MpPreference -ExclusionProcess @("C:\TEST3\program.exe")

ウイルス対策の除外設定に関するよくある問い合わせ

本項では、MDAV のウイルス対策除外に関するよくあるお問い合わせをご紹介します。

ウイルス対策除外のベストプラクティスを教えてください

一般に、MDAV をご利用いただく際にユーザ側で除外を追加する必要はないため、MDAV の観点からベストプラクティスとして除外リストへの追加を推奨している具体的なファイルやプロセスはありません。

ただし、パフォーマンスやアプリケーションの互換性に関する特定の問題を回避する目的などでウイルス対策の除外を構成する場合は、ウイルス対策の除外によって端末の保護レベルが低下するリスクを常に評価し、無害であることを確認済みのファイルのみが除外対象に含まれるように管理いただくことをおすすめしています。

その他、弊社からご案内しているウイルス対策除外を追加する場合に考慮いただきたい点については以下の公開情報を参照してください。

参考情報：除外に関する重要なポイント | Microsoft Learn

また、弊社では一般的に攻撃に悪用されることが多いフォルダや拡張子、プロセスについては**「除外対象に追加しない」ことを推奨しています。「除外に追加しない」ことを推奨しているフォルダ、拡張子およびプロセス**については以下の公開情報を参照してください。

参考情報：除外を定義する際に避ける必要のある一般的な間違い

なお、以上の通り MDAV 観点で追加を推奨している除外設定はありませんが、ユーザが利用するアプリケーションによっては、アプリケーション側の要件として、ウイルス対策の除外が推奨されている場合があります。

そのため、もし特定のアプリケーションを利用する場合に推奨される除外設定を確認したい場合は、ご利用中のアプリケーションの要件や推奨事項に関してアプリケーションベンダが公開している情報をご確認ください。

ファイルが誤ってマルウェアとして検出された場合の対処方法を教えてください

検出されたファイルがマルウェアであるか否か不明な場合や、誤って検出されている可能性がある場合は、以下の公開情報に記載の手順で Microsoft Defender ポータルや Microsoft セキュリティ インテリジェンス申請サイトから検体ファイルを弊社にアップロードし、解析を要求することができます。

参考情報：分析用にファイルを提出する | Microsoft Learn

ウイルス対策の除外設定を追加しても検出が止まりません

ウイルス対策の除外設定を追加したにも関わらず MDAV による検出が継続する場合、まずはユーザの環境で発生している検出がウイルス対策の除外設定で抑制可能なイベントであるか否かを確認します。

詳細については、ウイルス対策の除外設定で抑制可能な検知イベントについて の記載を参照してください。

対象の検知イベントがウイルス対策の除外設定で抑制可能なものであるものの、除外を追加しても MDAV によるファイルの検出が継続する場合、ユーザの除外設定が適切に端末に反映されていることを確認してください。

端末に適用されている除外リストの一覧は、管理者権限で起動した PowerShell で以下のコマンドを実行することで確認できます。

1
2
3
4
5
6
7
8

# ファイルとフォルダのパスに基づく除外リストを確認する
(Get-MpPreference).ExclusionPath

# プロセス除外リストを確認する
(Get-MpPreference).ExclusionProcess

# 拡張子除外リストを確認する
(Get-MpPreference).ExclusionExtension

追加した除外設定が上記のコマンドの実行結果に含まれない場合、除外エントリを追加したポリシーが正常に端末に同期されていることを確認してください。

Windows セキュリティアプリや PowerShell コマンドレットを使用して追加した除外エントリがリストに追加されていない場合は、Windows セキュリティアプリや PowerShell から除外を追加できません の内容を参照してください。

もし環境変数を利用した除外エントリを登録している場合は、環境変数を使用したパス除外後も検出が止まりません の内容を参照してください。

また、もしユーザの環境で MDE を利用しており、ウイルス対策の除外に追加したファイルが検出ソース [Microsoft Defender for Endpoint] のイベントにより検出され続ける場合、MDE の自動調査機能による検出と修復について の項に記載の通り、誤検出であることを確認済みの既存のアラート/インシデントをすべて解決済みに変更した後、許可したいファイルのファイルハッシュをファイルインジケータに登録することで問題が解決するか確認してください。

参考情報：インジケーターの作成 | Microsoft Learn

ウイルス対策の除外設定を追加してもプログラムやスクリプトの実行がブロックされます

プログラムやスクリプトなどの実行時の不正な動作が MDAV により検出されている場合、対象のプログラムやスクリプトをウイルス対策の除外に追加しても検出を抑制できない場合があります。

その場合は、以下の公開情報に記載の手順で Microsoft Defender ポータルや Microsoft セキュリティ インテリジェンス申請サイトから検体ファイルを弊社にアップロードし、解析を要求してください。

参考情報：分析用にファイルを提出する | Microsoft Learn

また、プログラムやスクリプトの動作が MDAV により検出されてしまう場合、以下の手順で分析用に Mpsupport.cab ファイルを提出することもできます。

1. 検知が発生した端末で管理者権限で起動したコマンドプロンプトを起動し、C:\ProgramData\Microsoft\Windows Defender\Platform\<プラットフォームのバージョン> にカレントフォルダを変更した後に MpCmdRun.exe -GetFilesを実行します。
2. さまざまな診断ログを含む .cab ファイルが既定で C:\ProgramData\Microsoft\Microsoft Defender\Support\MpSupportFiles.cab に生成されます。
3. 取得した .cab ファイルを Microsoft による分析のためにファイルを送信する に従って Microsoft に送信します。

ファイルインジケータを登録した後もファイルの検出が行われます

MDE を利用する環境では、特定のファイルハッシュを持つファイルを対象とするファイルインジケータを作成することで特定のファイルの実行を許可、もしくはブロックすることができます。

ファイルインジケータの利用要件については下記の公開情報を参照してください。

参考情報：ファイルのインジケーターを作成 | Microsoft Learn

なお、もし特定のファイルを MDAV のウイルス対策スキャンの対象外としたい場合には、ファイルインジケータの許可ルールのみではなく、ウイルス対策の除外設定を追加することをおすすめします。

もし、特定のファイルを許可するインジケータを追加しているにも関わらず MDAV のスケジュールされたスキャンなどによる検出が継続する場合は、ファイルやフォルダのパスに基づくウイルス対策除外を追加で構成してください。

ウイルス対策の除外を追加しても MDE のアラート検出が行われます

Microsoft Defender ポータルから確認可能なアラートのうち、サービスソースが Microsoft Defender for Endpoint であり、かつ検出ソースが EDR のアラートは通常、MDE の EDR 検出機能により端末内で不審なアクティビティが検出されたことを示しています。

このような種類のアラートはウイルス対策の除外を追加しても抑制することはできないため、同様のアラートを発生させたくない場合にはアラート調整ルール(アラート抑制ルール)を追加する必要があります。

アラートの抑制ルールの設定方法については下記の公開情報を参照してください。

参考情報：Microsoft Defender for Endpoint 抑制ルールを管理する | Microsoft Learn

Windows セキュリティアプリや PowerShell から除外を追加できません

Windows セキュリティアプリや PowerShell コマンドレットを使用してウイルス対策の除外を追加できない場合、「一覧に関するローカル管理者の統合動作を構成する(DisableLocalAdminMerge)」が構成されている可能性があります。

端末に適用されている DisableLocalAdminMerge の設定値が 1 である場合、ローカル管理者は Windows セキュリティアプリや PowerShell コマンドレットを使用してウイルス対策や ASR の除外エントリを追加することができません。

もし DisableLocalAdminMerge の制限を解除したい場合は、適用しているポリシー設定を解除した上で OS の再起動を実施してください。

参考情報：ローカルおよびグローバルに定義された脅威の修復と除外リストのマージ方法を構成する | Microsoft Learn

環境変数を使用したパス除外が有効に動作しません

MDAV では、ファイルとフォルダのパスに基づくウイルス対策の除外を構成する際に環境変数を使用することができます。

しかし、MDAV のサービスは LocalSystem アカウントを使用して実行されているシステムサービスであるため、除外パスに環境変数を使用した場合、MDAV はユーザ環境変数ではなくシステム環境変数から情報を取得します。

そのため、例えば環境変数 %USERPROFILE% を除外リストに追加した場合、実際にウイルス対策の除外対象となるパスは C:\Users\<ユーザ名> ではなく C:\Windows\system32\config\systemprofile となる点に注意が必要です。

参考情報：ファイル名とフォルダー パスまたは拡張機能の除外リストで不適切な環境変数をワイルドカードとして使用する| Microsoft Learn

パスに基づくウイルス対策の除外に使用可能なシステム環境変数の一覧については以下の公開情報にてご案内しております。

参考情報：システム環境変数 | Microsoft Learn

CPU 使用率の高騰を解消するためにどのファイルを除外すればいいですか？

MDAV のリアルタイムスキャンの動作に起因して CPU 使用率の高騰が発生している場合、ユーザはパフォーマンスアナライザーなどのツールを利用してスキャン結果を分析し、パフォーマンスの改善のために除外が必要なファイルやフォルダを特定することができます。

参考情報：Microsoft Defender ウイルス対策用のパフォーマンス アナライザー | Microsoft Learn

参考情報：パフォーマンスに関する問題のトラブルシューティング | Microsoft Learn

なお、ユーザの環境で発生している問題の種類によっては、ウイルス対策の除外でパフォーマンスが改善しない場合や、問題の解消のために除外を追加する必要がない場合があります。

詳細については MDAV により CPU 使用率が高騰している場合のトラブルシューティング の記載を参照してください。

MDAV により CPU 使用率が高騰している場合のトラブルシューティング

ウイルス対策スキャンが CPU リソースを消費する理由

MDAV がシステムの CPU リソースを消費する理由の多くはウイルス対策スキャンの動作によるものです。

MDAV は、端末の設定や端末内の他のサービスやアプリケーションの動作などをきっかけに、短時間により多くのデータをスキャンする場合があります。

ウイルス対策ソフトウェアがデータのスキャンを行う際には CPU やメモリなどのシステムリソースを必要とするため、端末内で短時間に多くのデータのスキャンが発生した場合、システムリソースの消費量を一時的に増大させる場合があります。

なお、MDAV のウイルス対策スキャンには大きく分けて「リアルタイム保護機能によるスキャン」と「手動、もしくはスケジュール実行されたスキャン」の 2 つの種類があります。

リアルタイム保護機能によるスキャンは主に、端末内で利用しているサービスやアプリケーションがデータの読み書きを行う際に実施されます。

一方で、手動スキャンやスケジュールスキャンは、ユーザが Windows セキュリティアプリや Microsoft Defender ポータルなどからスキャンを要求した場合や、グループポリシーなどで事前定義されたポリシーによりトリガーされます。

システムで CPU 使用率が高騰している場合の確認ポイント

システムの CPU 使用率が高騰している問題のトラブルシューティングを行う場合、まずはタスクマネージャーなどのツールを利用して、システム内でより多くの CPU リソースを消費しているプロセスを特定する必要があります。

Microsoft Defender Antivirus Service(MsMpEng.exe) が平均的に多くの CPU リソースを消費している場合、MDAV のウイルス対策スキャンの動作が関連しており、ウイルス対策の除外の追加が有効な軽減策となる可能性があります。

もし Microsoft Defender Antivirus Service(MsMpEng.exe) が平均的に多くの CPU リソースを消費していることを特定した場合、続けて以下の点を確認します。

1. システム内に MDAV と同等、もしくはそれ以上にシステムリソースを消費しているプロセスが存在するか
2. システム内で、多くのデータの読み書きを伴うサービスやアプリケーション、バッチジョブなどを実行しているか
3. システムリソース消費量の高騰時に、手動もしくはスケジュールされたフルスキャンを実施しているか

他のサービスやアプリケーションなどが多くのデータの読み書きを伴う操作を頻繁に行っている場合、MDAV 以外のアプリケーションの動作に伴いトリガーされるリアルタイムスキャンにより、MDAV の消費するシステムリソースが増加している可能性が考えられます。

このようなリアルタイムスキャンの動作に伴う CPU 使用率が上昇自体は製品の期待される動作であり、異常を示すものではありませんが、必要に応じて適切なウイルス対策の除外設定を追加することでパフォーマンスを改善することが可能です。

一方で、ウイルス対策ソフトウェアのフルスキャンはシステム全体のファイルスキャンを行う機能であり、実施時には多くの時間とシステムリソースが消費されます。

もしフルスキャンに伴う CPU 使用率の高騰を解消したい場合、フルスキャンの代わりにリソース消費量の少ないクイックスキャンを使用するか、Microsoft Defender ウイルス対策のフルスキャンに関する考慮事項とベストプラクティス の情報を参照し、フルスキャン時に使用する CPU 使用率の上限を変更することを検討してください。

なお、フルスキャン時に使用可能な CPU 使用率の上限を低く設定することでシステムのパフォーマンスは改善する可能性がありますが、相対的にフルスキャンの完了までに要する時間が長くなる点に注意が必要です。

まとめ

本記事では、MDAV のウイルス対策の除外設定を中心に、各種保護機能による検出動作やその抑制方法などについて紹介しました。

最新の情報については、リンク先の公開情報をご参照ください。

本資料は、以下のようなお客様にお読みいただくことを想定しています。

• お問い合わせを起票するための契約や、お問い合わせ発行から連絡をもらえるまでの応答時間などのルールと流れを知りたい
• マイクロソフトのサポートからどのような内容を対応してもらえるのか知っておきたい
• MDE に関するお問い合わせを発行する際に、どのように起票すれば効率的に成果が得られるか知りたい

本記事の内容

• 本記事の内容
• お問い合わせ (SR、サポートリクエスト) の作成方法
  • 1. お問い合わせ発行画面へのアクセス
  • 2. 一般的な解決策の確認
  • 3. 「サポートへの問い合わせ」 をクリック
  • 4. お問い合わせ内容の入力
    • ① タイトル
    • ② 説明
    • ③ 製品
    • ④ 重大度を選択
    • ⑤ 電話番号の確認
    • ⑥ 承認済み連絡先のメールアドレスを確認する
    • ⑦ これを解決するために必要なすべての通話の記録に同意します
    • ⑧ 希望する連絡方法
    • ⑨ 添付ファイル
    • ⑩ 地域の設定
    • ⑪ ユーザー補助の設定
• お問い合わせの完了 (サポート リクエストのクローズ)
  • お問い合わせの終了方法について
  • サポート リクエストのクローズ後のアンケートについて
  • 製品へのフィードバックや機能追加の要望

お問い合わせ (SR、サポートリクエスト) の作成方法

1. お問い合わせ発行画面へのアクセス

Microsoft Defender ポータル (https://security.microsoft.com) へアクセスし、画面右上の [?] マークをクリックします。

2. 一般的な解決策の確認

「何かお困りでしょうか？」 と表示されますので、検索ボックスに問い合わせ概要を記載します。

この際に、一般的な解決策が表示されますので、お問い合わせ発行前に一度ご確認いただくことをお勧めしております。

3. 「サポートへの問い合わせ」 をクリック

画面下部の「サポートへの問い合わせ」 または画面上部の 「ヘッドセット」 マークをクリックします。

4. お問い合わせ内容の入力

「サポートへのお問い合わせ」 画面が表示されますので、問い合わせ内容等を入力します。

ここでは各項目ごとに留意事項を記載します。

① タイトル

「2. 一般的な解決策の確認」 で記載した問い合わせ概要が自動入力されます。

お問い合わせ発行後、本画面で記載したタイトルを件名としたメールを弊社よりお送りいたしますので、件名にご希望等がございましたら、適宜編集いただけますと幸いです。

② 説明

お問い合わせ詳細について記載してください。

トラブルシューティングの対応を希望される場合は、以下を参考に記載いただきますようお願いいたします。

③ 製品

Microsoft Defender for Endpoint (MDE) または Microsoft Defender ウイルス対策(MDAV) に関するお問い合わせの際には 「Defender for Endpoint」 を選択して下さい。

④ 重大度を選択

問題の状況によって、3 種類の重大度が設定可能です。
お客様がご利用されている契約と、重大度に応じて、初回応答時間が設定されています。
初回応答時間は、お問い合わせ起票後から Microsoft のサポートエンジニアがお客様と連絡を取り、サポートが開始されるまでの時間です。重大度 A 以外は営業時間内 (日本では午前9:00～午後17:30) でのご連絡となります。

• 事業に軽微な影響が及ぶ場合 (重大度 C): Standard サポート契約の場合 8 時間以内
• 事業に部分的な影響が発生する場合 (重大度 B): Standard サポート契約の場合 4 時間以内
• 事業に大きな影響が発生する場合 (重大度 A): Standard サポート契約の場合 1 時間以内

詳しくは、サポート プラン—サポート内容と応答性 のページを参照してください。

⑤ 電話番号の確認

お問い合わせ担当者様のお電話番号および国番号(日本: 81) を入力します。

⑥ 承認済み連絡先のメールアドレスを確認する

ご連絡を希望されるメールアドレスを記入してください。

複数のメールアドレスの場合は、セミコロン “;” を使用して区切ることができます。

⑦ これを解決するために必要なすべての通話の記録に同意します

お問い合わせに対する通話で収集された情報のレコーディングや監視に同意いただける場合、「はい」 を選択します。

⑧ 希望する連絡方法

「メール」 か 「携帯電話」、ご希望の連絡方法をご選択ください。選択した方法で初回のご連絡をさせていただきます。

なお、2 回目以降のご連絡はサポートエンジニアが状況に応じて異なるご連絡方法のお願いをさせて頂く場合がございます。

もし、より細かいご要望がございましたら、「② 説明」 欄にご記入いただきますようお願いいたします。

緊急度 A については電話のみでの対応となります。

⑨ 添付ファイル

エラーメッセージのスクリーンショット等、添付ファイルがございましたらアップロードいただきますようお願いいたします。
添付ファイルは最大 10 GB (ファイル辺り 1GB、上限 10 ファイル) まで送信できます。

なお、1GB以上のファイルの共有を希望される場合、お問い合わせ時にお知らせいただけましたら、弊社よりアップロードサイト (1ファイルあたり100GBまで格納可能) のリンクを送付いたします。

⑩ 地域の設定

・新しいタイムゾーンの選択: 日本の場合 「(UTC+09:00) 大阪、札幌、東京」 を選択します。

・第2言語の選択: 対応を希望される言語を選択します。

⑪ ユーザー補助の設定

ユーザー補助関連のニーズがございましたら、本項目に記載いただきますようお願いいたします。

入力項目は以上の通りです。

上述の ①～⑪ までを入力し、「連絡を希望する」 を選択した後、初回応答時間内に、サポートエンジニアからのご連絡を差し上げます。

お問い合わせの完了 (サポート リクエストのクローズ)

お問い合わせの終了方法について

弊社のサポート エンジニアからの回答によって、お問い合わせに記載頂いた問題が解決した場合や、お客様ご自身で問題が解決した場合は、解決した旨をメール、お電話にてご連絡頂きますようお願い致します。
その後、弊社のサポート エンジニアにてお問い合わせ対応の終了 (クローズ) を実施します。

解決した旨のご連絡等、対応終了 (クローズ) をご承諾いただくご連絡が無い場合、担当エンジニアから継続してご連絡させていただくことになり、お手を煩わせることもございます。そのため、お手数ではございますが、対応終了をご承諾いただくご一報をいただけますと大変助かります。

また、弊社からの状況確認のご連絡を複数回実施し、お客様からご連絡を頂けなかった場合は、弊社のサポート エンジニアにてお問い合わせを対応終了のステータスとさせていただくことがあります。

サポート リクエストのクローズ後のアンケートについて

サポートリクエストをクローズ時にメールでアンケートを送付しています。
サポート対応の品質向上を目的として、各サポート リクエストでのサポート エンジニアによる対応品質をお客様にご評価いただいております。
回答内容については担当したサポート エンジニアならびに担当チームメンバーで共有し、次回以降のより良い対応に繋げたり、励みとさせていただいております。

製品へのフィードバックや機能追加の要望

Microsoft Defender における製品自体の品質のフィードバック、機能追加・変更といったご要望については、Microsoft Defender ポータル上の 「フィードバック」 にて送信することができます。
以下の手順で Microsoft へのフィードバックを投稿していただくことで、開発部門に直接お声を届けることが可能となっています。

ご参考: https://learn.microsoft.com/ja-jp/defender-xdr/feedback

1. Microsoft Defender ポータルを開き、画面右上のフィードバックボタンを選択します。

2. Microsoft Defender のエクスペリエンスについて評価を行い、機能要望等につきまして可能な限り詳細を投稿いただくようお願いいたします。必要に応じて、Microsoft Defender ポータル上のスクリーンショットを含めることもできます。

以上が弊社サポートサービスを効果的にご利用いただくためのお問い合わせ方法、および流れとなります。

なお、本ブログに記載しました内容はあくまで 「一般的なお問合せの流れ」 をご紹介していますので、もしこちらに記載がなくお悩みの点がございましたら、一旦お問合せを起票いただくか、既に対応させていただいている件があればそちらの担当サポートエンジニアまで、お気兼ねなくご相談ください。

Microsoft Defender for Endpoint をサポートサービスの質でお選び頂けるよう、チーム一同努めてまいりますので、これからも、弊社製品ならびにサポートサービスをご愛顧賜りますと幸いです。

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

本記事の内容

• Security & Compliance チームについて
• 働き方について
• Microsoft Defender ウイルス対策 (MDAV) ってどんな製品？
• Microsoft Defender for Endpoint (MDE) ってどんな製品？
• Microsoft Defender SmartScreen ってどんな製品？
• Microsoft Defender for Office 365 (MDO) ってどんな製品？
• Microsoft Purview ってどんな製品？
• 関連記事

Security & Compliance チームについて

チーム名からお察しいただけます通り、当チームではセキュリティ製品とコンプライアンス製品を担当させていただいております。
セキュリティに関連した製品が非常に多くございます都合から、EPM (EndPoint Protection & Messaging) チームと EPC (Endpoint Protection & Compliance) チーム、および CP (Cloud Protection) チームに分かれて担当製品を分担しております (2025 年 4 月現在)。

この記事では EPM および EPC チームの担当する製品についてご紹介をさせていただき、CP チームの担当する製品は第 2 弾でご紹介させていただきます。

EP チームではエンドポイントを保護するための製品を中心にサポートしております。
主な製品といたしましては、Windows OS 組み込みのアンチウイルスソフトである Microsoft Defender ウイルス対策 (MDAV) や、エンドポイント上の振る舞い監視を提供する EDR (Endpoint Detection & Response) 製品の Microsoft Defender for Endpoint (MDE)、Edge ブラウザを保護する Microsoft Defender SmartScreen があります。
また、2023 年から製品移管が行われており、現在は Messaging Protection 機能を提供する Microsoft Defender for Office 365 (MDO) や、監査等のデータ保護機能を提供する Microsoft Purview も担当しております。

働き方について

サポートエンジニアの業務時間は、サポートの窓口の提供時間に合わせて 9:00-17:30 となっています。
ただし、一部のシフト制で稼働するエンジニアは 火-土 で勤務する等、例外的な勤務体制もございます。
また、本番環境においてお客様のビジネスに深刻な影響が発生した際の緊急対応に備え、24 時間単位での緊急体制の待機が求められる場合もあります。

勤務は出社とリモートワークをご自身で選んでいただくことが可能です。
私は概ね週に 1 日のみ出社し、4 日は在宅勤務としておりますが、フルリモート勤務の方や、週 3 程度出社される方もおります。
リモートワークでの働き方につきましては第 3 弾の記事でご紹介しておりますのでこちらもご参照いただければと思います。

Microsoft Defender ウイルス対策 (MDAV) ってどんな製品？

MDAV は Windows 10 以降のクライアント OS や、Windows Server 2016 以降のサーバー OS に既定でインストールされているアンチウイルスソフトです。
リアルタイムスキャンによる脅威検出を提供する [リアルタイム保護] や、クラウドと連携することで新しい脅威の検出を可能にする [クラウド保護]、Office やスクリプトを使った攻撃を防御する [攻撃面の減少ルール (ASR ルール)] 等の機能があります。

Windows でのMicrosoft Defenderウイルス対策の概要

クラウド保護と Microsoft Defender ウイルス対策

攻撃面の縮小ルールの概要

Microsoft Defender for Endpoint (MDE) ってどんな製品？

エンドポイント上の不審な動作や挙動を検知し、アラートを生成する EDR (Endpoint Detection & Response) 製品です。
MDAV と異なり、MDE は Windows OS だけでなく Mac, Linux, iOS, Android 等の OS にも対応しています。
無償でご利用いただける MDAV と異なり、MDE をご利用いただく場合はライセンス購入が必要となります。
主な機能といたしましては、上述の通りエンドポイント上の振る舞い監視を提供する [エンドポイントでの検出と応答]、発生したアラートを自動で調査・修復する [自動調査と応答 (AIR)]、ネットワークの分離や調査パッケージの収集、デバイス上で発見された脆弱性に対する推奨事項の提供等があります。

エンドポイントでの検出と対応の概要

自動調査の概要

デバイスの対応措置を講じる

セキュリティに関する推奨事項

Microsoft Defender SmartScreen ってどんな製品？

Microsoft Defender SmartScreen は Microsoft Edge ブラウザの保護を提供し、不審サイトへのアクセスや、脅威を含む可能性のあるファイルのダウンロードをブロックを提供します。
また、ネットワーク保護を有効化することにより、Google Chrome や Firefox 等のサードパーティ製ブラウザへの保護も提供可能です。

Microsoft Defender SmartScreen

ネットワークを保護する

Microsoft Defender for Office 365 (MDO) ってどんな製品？

なりすましメールやフィッシングメール、およびメールに添付された脅威を含むファイルをブロックします。
また、メールに記載された不審な URL の調査や、侵入した脅威に対する自動調査・修復機能などを提供します。
防御機能だけでなく、ユーザー様のトレーニングを目的とした攻撃シミュレーション機能もございます。

Defender for Office 365 の安全な添付ファイル

ドメインと URL を調査する

Microsoft Defender for Office 365での自動調査と対応 (AIR)

攻撃シミュレーション トレーニングの使用を開始する

Microsoft Purview ってどんな製品？

Microsoft Purview は、データの管理、保護、ガバナンスを支援する包括的なソリューションセットです。
組織全体のデータを可視化し、機密データをライフサイクル全体で保護し、規制要件に対応するための統合プラットフォームを提供しています。

• Microsoft Purview データ セキュリティ ソリューション | Microsoft Learn
• Microsoft Purview を使用したデータ ガバナンスについて説明します | Microsoft Learn
• Microsoft Purview のリスクおよびコンプライアンス ソリューション | Microsoft Learn

関連記事

Security & Compliance チームの紹介記事は第 1 弾から第 5 弾まで公開しています。
以下のリンクから、その他の記事も是非一緒にご覧ください！

<第 1 弾> Security & Compliance サポートチームについて

<第 2 弾> CP チームの製品紹介

<第 3 弾> リモートワークでの働き方について

<第 4 弾> チームの様子、雰囲気について

<第 5 弾> Security & Compliance チームの多様性について

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

本記事の内容

• Cloud Protection (CP) チームについて
• Microsoft Defender for Cloud (MDfC) ってどんな製品？
• Microsoft Sentinel ってどんな製品？
• その他の製品について
• 関連記事

Cloud Protection (CP) チームについて

Security & Compliance チームは EPM (Endoint Protection & Messaging) チームと EPC (Endpoint Protection & Compliance) チーム、および CP (Cloud Protection) チームで製品を分担してサポートしております。
前回 EPM と EPC チームについてご紹介させていただきましたので、第 2 弾のこの記事では CP チームについて紹介していきます。

CP チームでは組織がクラウド サービスを安全に利用するためのセキュリティ製品を幅広くサポートしています。
特にボリュームが多いのはクラウド上のサービスやデバイスを監視する Microsoft Defender for Cloud (MDfC)、そして各製品のログを分析し組織全体のセキュリティを強化する Microsoft Sentinel ですが、その他にも様々な製品も取り扱います。

EP と異なり多数の製品をサポートしていますが、はじめからすべての製品を担当するのではなく、一部の製品のサポートからスタートし徐々に担当する製品やサービスを広げていくので、負担なく知識を増やしていくことができます。

Microsoft Defender for Cloud (MDfC) ってどんな製品？

一般的に CSPM と CWPP と呼ばれる機能を提供しています。
CSPM (クラウド セキュリティ態勢管理): 社内で利用するクラウド サービスの設定状況や構成を継続的に監視します。リスクとなりえるリソースや構成を検知すると管理者に通知し、改善を促すことでサービスを安全に利用することができます。
CWPP (クラウド ワークロード保護プラットフォーム): クラウド上に存在する仮想マシンやストレージなどのリソースで脆弱性やマルウェアなどの脅威の兆候が無いかを監視します。脅威の兆候をいち早く察知することで被害を防ぎ、影響範囲を最小化します。

Microsoft Defender for Cloud とは

クラウド セキュリティ態勢管理 (CSPM)

CWPP とは

Microsoft Defender for Cloudを利用することで、組織全体で利用するクラウド リソースを監視し、攻撃の対象となりやすい構成やリスクがあるリソースが可視化されます。
新たに発見された脆弱性が対策されていないリソースを通知したり、マルウェアの兆候をアラートとして通知することで、セキュリティ担当者がリスクに対して迅速に対応できるよう手助けをしています。

Microsoft Sentinel ってどんな製品？

SIEM、SOAR と呼ばれる機能を提供しています。
SIEM (セキュリティ情報およびイベント管理): クラウドやオンプレミスなど場所を問わずあらゆるリソースや機器の情報を収集し分析します。高度な自動学習と脅威データベースと照合することで未知の脅威や高度な攻撃を発見します。
SOAR (セキュリティ オーケストレーション自動応答): 検知された脅威について発生するインシデントを作成する、担当者を割り当てる、危険性が無いアラートを終了するタスクを自動化し、組織のセキュリティ担当者の負担を軽減します。

Microsoft Sentinel とは

SIEM とは?

Microsoft Sentinel でのセキュリティ オーケストレーション、オートメーション、応答 (SOAR)

Microsoft Sentinel は様々な製品やサービスからログを収集し、分析することでより高度な攻撃から組織を保護します。
例えば単体のログからは検知できない攻撃の兆候を複数の製品のログを横断的に分析することで発見したり、組織に合わせてアラートやインシデントを調整することにより組織のセキュリティ担当者の負担を軽減し重要度の高い攻撃への対応を促します。

その他の製品について

CP チームではその他にもクラウド アプリを監視する Microsoft Defender for Cloud Apps(MDA) など、様々な製品をサポートしています。

Microsoft Defender for Cloud Apps (MDA) は CASB と呼ばれる製品に該当し、社内で利用する様々なクラウド アプリを適切に利用するための管理を行います。
この製品を利用することによりシャドウ IT の可視化やデータの保護を実現します。

Microsoft Defender for Cloud Apps の概要

関連記事

Security & Compliance チームの紹介記事は第 1 弾から第 5 弾まで公開しています。
以下のリンクから、その他の記事も是非一緒にご覧ください！

<第 1 弾> Security & Compliance サポートチームについて

<第 2 弾> CP チームの製品紹介

<第 3 弾> リモートワークでの働き方について

<第 4 弾> チームの様子、雰囲気について

<第 5 弾> Security & Compliance チームの多様性について

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

本記事の内容

• 業務内容について
• 一日の業務の流れについて
• 業務環境について
  • 勤務形態について
  • コミュニケーション手段について
  • 業務用デバイスや検証環境について
• 関連記事

業務内容について

Microsoft のクラウドサービスのサポートは、主にサービス料金内に含まれている無償サポートと別途追加のサポート契約が必要な有償サポートがあります。
わたしたちのチームでは主に有償サポート契約を締結されたお客様を中心にサービスを提供しています。

サービスリクエスト（SR）の受付からクローズまで基本的には担当するメンバーがオーナーシップを持って対応しており、基本的な案件対応の流れとしては、起票 → 調査方針合意 → 調査 → 回答 → クローズとなります。
SR の起票から終了までの期間につきましては内容にも依存しますので、一概に決まってはいないですが、大まかに下記のような感じだと認識いただければと思います。

• 利用方法に関するお問合せや一般的なトラブルシューティング：１～１０日程度
• 類似事例のないトラブルシューティング：３～２０日程度
  ※ 製品不具合の改修が必要な場合も稀にありますので、そのような場合はクローズまで数ヶ月かかる時もあります。

なお、時期によって増減はありますが、各エンジニアでは平均 10 ~ 20 件ほどのアクティブな SR を受け持ち、同時並行で案件対応を進める場合が多いです。
アクティブな SR の中にはお客様確認待ちステータスの SR も多く含まれますので、常に 10 数件の調査を並行して行うわけではございません。

一日の業務の流れについて

わたしのリモートワークでの 1 日の流れについて紹介いたします！

• 09:00 Teams にて業務開始連絡。
• 09:00 SR 管理ツールにて担当 SR の対応状況整理及びタスクの洗い出しを実施。
• 09:30 新規担当 SR の対応開始。回答可能な内容であれば電話 or メールにて回答実施し、調査が必要な内容が含まれる場合は、次回連絡日程を沿えた上、受付連絡を実施。
• 10:30 既存担当 SR の調査を実施。（公開情報調査及び実機動作検証など）
• 11:00 SR 相談会に参加。（チームメンバー間の情報交換及び調査方法に関する相談などを目的とした、出入り自由な相談会）
• 12:00 お昼休憩。（SR 対応状況に応じて柔軟に取得時間を変更しています）
• 13:00 社内ミーティング参加。（社内別製品担当との協業調査など）
• 13:30 既存担当 SR の調査を実施。（公開情報調査及び実機動作検証など）
• 15:30 お客様からの電話に応対。（割合としては低いですが、メールでの案内内容に不明点がある場合や、急ぎ事情がある場合はお電話での対応もあります）
• 16:00 チームミーティング。（チームリーダからの重要事項周知やメンバーからの各種情報共有及び報告を目的としたミーティング）
• 17:00 通院のため、少し早めに業務を中断。
• 17:30 （サポート窓口が閉まります）
• 18:00 帰宅後、業務再開。（翌日分のタスク整理や実機動作検証など）
• 19:00 Teams にて業務終了連絡。

業務環境について

勤務形態について

わたしたちのチームでは主にリモートワーク中心で業務を行っています。
また、チームのメンバー内で話し合いをもって、必須ではありませんが毎週水曜日を推奨出社日とし、オフィスで席をならべて仕事をしている仲間も多いです。

コミュニケーション手段について

社内のコミュニケーションはほぼすべて Teams を利用して行います。
お客様とのコミュニケーション時はお客様にてご用意いただいた電話会議ツールや、電話を利用して行います。
社用携帯用の SIM が別途支給されていて、スマートフォンを利用した業務リソース（メール、Teams）へのアクセスも可能です。

業務用デバイスや検証環境のスペックについて

業務にて利用しているデバイスや検証環境のスペックについても簡単に紹介いたします！

• 業務用デバイス１（Ryzen7 PRO 6850U / 32GB / 1TB）
  • 通常業務にて利用します。

• 業務用デバイス２（Azure Virtual Desktop）
  • 業務用デバイス１が利用できない場合などに、主に利用します。

• 検証環境１（サポート部門共用 Azure Subscriptions）
  • 主に業務関連検証にて利用します。
• 検証環境２（個人に紐づく Azure Subscriptions）
  • 最大１０台までの VM が作成可能で、主に業務関連検証にて利用します。
• 検証環境３（社員特典の Visual Studio Subscriptions 及び Subscriptions 付随 Azure Subscriptions 無償枠）
  • 業務以外の用途でも利用可能もので、担当外製品の検証や趣味のFPS ゲームサーバをホスティングする用途などで利用しています。
• チーム共用検証環境
  • macOS デバイス及び Android / iOS デバイスが複数台ずつチーム共用デバイスとして用意されており、デバイス依存事象の調査の際に利用可能です。
• 個人検証機１（Core i9-10900K / 128GB / 5TB）

• 個人検証機２（Ryzen 5 PRO 3400GE / 64GB / 3TB）

関連記事

Security & Compliance チームの紹介記事は第 1 弾から第 5 弾まで公開しています。
以下のリンクから、その他の記事も是非一緒にご覧ください！

<第 1 弾> Security & Compliance サポートチームについて

<第 2 弾> CP チームの製品紹介

<第 3 弾> リモートワークでの働き方について

<第 4 弾> チームの様子、雰囲気について

<第 5 弾> Security & Compliance チームの多様性について

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

本記事の内容

• Security & Compliance チームの様子、雰囲気
• 入社前の Microsoft のイメージ
• チームメンバーの思う Security & Compliance チームのイメージ
• Security & Compliance チームを選んだ理由
• まとめ
• 関連記事

Security & Compliance チームの様子、雰囲気

Security & Compliance チームではそれぞれの自宅からのリモート勤務が可能です。
出社頻度などにルールや制限はなく、自分のライフスタイルに合わせてリモート勤務と出社を組み合わせることが可能です。
私は月に 1,2 回程度出社しており、それ以外は自宅からリモート勤務を行っております。
チームメンバーの中には札幌からフルリモートで勤務されている方もいます。
そのため、普段のやり取りは Teams のチャットや電話がメインとなります。
私も入社して約 2 年ほどたちますが、チームメンバーとのやり取りで困ったことはありません。

なお、フルリモートされている方が年に 1,2 回ほど品川のオフィスに出社されることがあります。
※ 交通費は会社持ちです。笑
その際には Security & Compliance チーム全体で飲み会を開き普段会う機会がないチームメンバーと実際に会って会話をすることができます。
また、チームに新しく join された方の歓迎会や新年会、忘年会が Security & Compliance チーム全体で行われます。
歓迎会や新年会、忘年会は品川オフィスで開催されることもありますが、外部の施設を利用することもあります。
参加は完全に自由となっておりますので、無理に参加する必要はなく、自分の予定に合わせて参加/不参加を決めることができます。
ちなみにですが、2024 年の 3 月に開催された歓迎会はダーツバーで行いました！

入社前の Microsoft のイメージ

皆さんは Microsoft と聞くとどのようなイメージを持たれるでしょうか。
私は Microsoft と言えば外資系ということもあり、実力主義でチームメンバー間のやり取りもなく冷たいイメージを持っておりました。笑
チームメンバーの方々に入社前の Microsoft に対するイメージについてアンケートを取りましたのでメンバーの思う Microsoft のイメージを確認してみましょう！

アンケート結果からも個人主義であったり、成果主義のためチームメンバー間のフォローがなく、冷たいイメージを持たれていた方が多くいました。。。
Microsoft 入社後の今だからこそわかる Security & Compliance チームのイメージについても確認してみましょう！

◆ アンケート結果
・ 実力、成果主義のイメージ
・ あまり周りと関わらず、1人で黙々と仕事を進めるイメージ
・ 各々自分の仕事は人に助けを求めず自分の力で遂行しているイメージ
・ 個人主義
・ 入社後のトレーニング等もあまりないイメージ
・ 固く厳しいイメージ
・ エリートばかりで、知識が薄いとバカにされるかもしれないイメージ
・ 周りをフォローしない、冷たいイメージ
・ 明るくて活発なイメージ
・ 開発経験バリバリあってずっと IT の第一線を走ってきたような人たちばかりのイメージ
・ 残業まみれでワークライフバランスが無い会社のイメージ
・ 全員英語はネイティブレベルで人間関係がドライのイメージ

チームメンバーの思う Security & Compliance チームのイメージ

Microsoft 入社前のイメージでは冷たいイメージを持たれていた方が多くいる結果となりましたが、今度は Security & Compliance チームで働いている現在の Security & Compliance チーム に対するイメージを紹介します。
Security & Compliance チームのイメージについてもアンケートを取りましたので見てみましょう！

アンケートの結果、入社前のイメージとは変わり、お互いにフォローし合い暖かいイメージを持たれている方が多くいました！
私自身も普段の業務では多くの方にフォローいただいており、相談の際に嫌な顔をされたことは一度もありません！
困った時は支え合い、教え合う文化が根付いているため、入社歴に関係なく自分の知識を共有し業務に活かしています。
わからないことを互いに教え合う環境が整っていますので、知識がないから。。。と思わず、Security & Compliance チームに少しでも興味を持たれた方は こちらからお申込みを検討いただけると嬉しいです！

◆ アンケート結果
・ お客様へのサポートに限らずメンバーのサポートもしっかりしているチーム。
・ 助け合いながら仕事が進められる
・ 困ったときに助けあえている
・ 分からないことは教えあう文化
・ 入社後のトレーニングも充実しており、手厚く育成してくれる
・ 様々なバックグラウンドを持つメンバーが集まっているが、相互に理解や配慮が感じられる素晴らしいチーム
・ 仕事には真面目に取り組むが、チームとしては仲良し
・ お互いにフォローしあう
・ みんな優しい
・ それぞれの得意分野を生かして協力しあっている
・ チームワークがよくて仕事がしやすい
・ 心理的安全性が高い
・ とにかく優しい人たちがたくさんいるため、相談もしやすく働きやすい

Security & Compliance チームを選んだ理由

Microsoft には多くの製品があり、多くの担当チームが存在します。
その中で Security & Compliance チームを選んだ理由についてもメンバーにアンケートを取りましたので見てみましょう！

アンケートの結果、前職でセキュリティ関連のお仕事をされていた方が多くいらっしゃいましたが、中にはセキュリティ未経験で入社された方もいらっしゃいました！
セキュリティ未経験でもお互いに教え合う文化により活躍できる環境が整っています。
セキュリティ未経験でも臆せず こちらからお申込みを検討いただけると嬉しいです！

◆ アンケート結果
・ セキュリティ分野に興味があったから
・ セキュリティは未経験だったが、今後も需要が高まる分野だと考えたため
・ 前職でセキュリティ関連の業務をしており、興味があったため
・ 前職でセキュリティ関連の業務をしたこともあるが、Microsoft のセキュリティ製品に興味があったため
・ ここしかない！ と閃いたため
・ IT の括りの中で一番面白いと思っていて、知識をさらに深めたかったから
・ 前職でサイバー セキュリティの業務に従事していたため、貢献できると思ったため
・ サポート業務に従事することで Security 業界や製品に関する知見や対応経験が得られると思ったため
・ 前職で Security に関連する業務に携わっており、更にスキルアップを目指したいと思っていたため
・ 前職でユーザー部門セキュリティ担当をしており、Microsoft 製品の運用しており製品スキルを高めたかったため

まとめ

皆さん、いかがだったでしょうか。
Security & Compliance チームの雰囲気やイメージについて少しでもイメージがわきましたでしょうか。
入社前はメンバー間のフォローが希薄であり、冷たいイメージを持たれている方が多くいましたが、入社後のイメージではメンバー間のフォローが充実しており、安心して業務が行える環境であると回答した方が多くいました！
セキュリティ分野未経験の方でも日々切磋することで活躍することができるチームですので Security & Compliance チームに少しでも興味を持たれた方は こちらからお申込みを検討いただけると嬉しいです！

関連記事

Security & Compliance チームの紹介記事は第 1 弾から第 5 弾まで公開しています。
以下のリンクから、その他の記事も是非一緒にご覧ください！

<第 1 弾> Security & Compliance サポートチームについて

<第 2 弾> CP チームの製品紹介

<第 3 弾> リモートワークでの働き方について

<第 4 弾> チームの様子、雰囲気について

<第 5 弾> Security & Compliance チームの多様性について

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

現在 Security & Compliance チームには 50 名程が所属しています。
メンバーのバックグラウンドは様々で、新卒として Microsoft に入社した方もいれば、20 年以上 IT 業界の第一線で活躍されてきた方もいます。
全社的にダイバーシティに取り組む弊社には様々なバックグラウンドを持つ社員が所属しておりますので、以下にご紹介させていただきます。

本記事の内容

• 女性エンジニアについて
• 所属するエンジニアの経歴について
• 言語について
• 多様なバックグラウンドを持つエンジニアを歓迎します
• 関連記事

女性エンジニアについて

サイバー セキュリティという業界柄絶対数は少ないものの、チームとしては女性エンジニアが増えてきて私を含め現在 10 名となりました。
普段の業務で性別を意識する機会はほとんどありませんが、イベントなどで集まると製品の壁を越えて積極的に情報交換しています。
各チームに先輩となる女性エンジニアがいることでより馴染みやすい環境になり、個人的にはまだまだ女性エンジニアが増えてくれたらいいなと期待しています。

セキュリティ チーム所属の Yuka さんのインタビュー記事がありますのでオススメさせていただきます。
サポート未経験者でも成長できる助け合いのカルチャー

所属するエンジニアの経歴について

サイバー セキュリティの第一線をずっと走ってきたいわゆる “強いエンジニア” をイメージされることが多い業務ですが、そのイメージに当てはまらないエンジニアも多くいます。
前職を聞いてみてもピープル マネジメント一色だった方、他社製品やアウトソース ベンダーでテクニカル サポート業務に従事していた方、プリ セールスや営業職など多岐にわたります。
また、一口に技術職といってもオンプレミス製品やネットワーク機器など、セキュリティ領域以外からのチャレンジも含めて様々な人が所属しています。

サポート業務の経験が無く入った方はお客様とのコミュニケーションに迷ったり、親和性のあまり無い領域から転職された方は技術的なキャッチアップに苦戦したりなど、Onbording 時にそれぞれ苦戦するポイントはありますが、チームのメンバーにフォローしてもらい相談しながら少しずつ慣れていくことができます。

ちなみに、前職からさらに遡ると飲食店や不動産営業やダイバーなどさらに多様な経歴の話も聞くことができるので、入社した後直接バックグラウンドについて聞いて回るのも面白いかもしれません。

言語について

日本語でのサポートを提供する業務の性質上日本語が前提で、さらに英語の技術情報や海外のエンジニアとのやりとりがあるため、英語が分かると有利な場面は多いです。
一方で英語を苦手とする人には通訳や翻訳での配慮がされるので、英語が苦手 or 分からなくても問題ありません。
（対面でのリアルタイムの会話についていけない、などの場面は時々ありますが・・・）

なお、第一言語が日本語以外のサポート エンジニアも複数名在籍しています。
日本語ネイティブでなくとも特に不利になることもなく、近しい経験の方が多い分馴染みやすい環境でもあると思います。

多様なバックグラウンドを持つエンジニアを歓迎します

現在 Security & Compliance チームに所属するエンジニアは、それぞれの経験を生かして協力しながら日々の業務を進めています。

サポート エンジニアは技術職なので、異なる領域からチャレンジされる場合、最初にキャッチアップの量に驚かれるかもしれません。
しかしチーム内には既に様々な領域からチャレンジして活躍するエンジニアが多数おりますので、豊富な経験でバックアップしてくれます。
入社してから日の浅いメンバー同士でも積極的にコミュニケーションをとっているので、困ったときに相談できる相手、助けてくれる相手がたくさんいます。

もし今の経験やスキルがマッチしていないと感じていても、思ってもいない形で強みになる場合があります。
現在のセキュリティ製品やクラウド サービスの経験だけでなく、様々なバックグラウンドを持つメンバーが合流してくれることで、チームの幅が広がることを楽しみにしています。
これからも注目度の高いセキュリティ業界で、一緒に成長していける方のご応募をお待ちしております。

関連記事

Security & Compliance チームの紹介記事は第 1 弾から第 5 弾まで公開しています。
以下のリンクから、その他の記事も是非一緒にご覧ください！

<第 1 弾> Security & Compliance サポートチームについて

<第 2 弾> CP チームの製品紹介

<第 3 弾> リモートワークでの働き方について

<第 4 弾> チームの様子、雰囲気について

<第 5 弾> Security & Compliance チームの多様性について

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

この記事では、Microsoft Defender for Endpoint(MDE) を使用する Windows マシンでデバイスコントロール機能を使用してリムーバブルメディアアクセスを制御する方法を紹介します。

なお、本記事の内容は、2024 年 1 月 24 日時点で最新の情報を元に作成いたしております。

また、本記事の手順はすべて Windows 11 23H2 にて動作確認を実施しております。

デバイスコントロール機能に関する最新情報については、Microsoft Learn をご参照ください。

本記事の内容

• リムーバブルメディアアクセス制御の概要
  • リムーバブルメディアアクセス制御とは
  • リムーバブルメディアアクセス制御の前提要件
  • リムーバブルメディアアクセス制御の設定方法
  • リムーバブルメディアアクセス制御の設定方法を選択する
• グループポリシーを使用してリムーバブルメディアアクセス制御を構成する
  • グループポリシーを使用するための事前準備
  • グループポリシーでデバイスコントロール機能を有効化する
  • グループポリシーで既定の処理を構成する
  • グループポリシーでデバイスコントロールグループを構成する
  • グループポリシーでアクセス制御ポリシーを構成する
  • デバイスコントロールの設定状況とポリシーの更新有無を確認する
• Intune の OMA-URI を使用してリムーバブルメディアアクセス制御を構成する
  • Intune の OMA-URI でデバイスコントロール機能を有効化する
  • Intune の OMA-URI で既定の処理を構成する
  • Intune の OMA-URI でデバイスコントロールグループを構成する
  • Intune の OMA-URI でアクセス制御ポリシーを構成する
• Intune のユーザインターフェースを使用してリムーバブルメディアアクセス制御を構成する
• デバイスコントロールグループを XML ファイルで構成する
  • PrimaryId によるデバイスの指定
  • InstancePathId と VID_PID によるデバイスの指定
  • その他のデバイスコントロールグループの指定方法
• リムーバブルメディアアクセス制御を XML ファイルで構成する
  • ディスクレベルで読み書き実行を拒否する
  • SID を指定して読み取りと書き込みアクセス許可を構成する
  • Advanced Hunting でリムーバブルメディアアクセス制御イベントを確認する
• グループポリシーまたは Intune の OMA-URI を使用してアクセス制御を構成するサンプルシナリオ
  • シナリオ 1 - カスタムポリシーで既定のアクセス拒否ポリシーを構成する
  • シナリオ 2 - 特定の USB メモリに対してのみアクセスを許可する
  • シナリオ 3 - デバイスごとに異なるアクセス許可を構成する
  • シナリオ 4 - 特定のユーザに対してアクセスを許可する
• リムーバブルメディアアクセス制御に関するよくある質問
  • 特定のメディアを指定するために使用するデバイスインスタンスパスなどの確認方法がわかりません
  • 既定の処理を拒否に設定すると読み取り許可のアクセス制御ポリシーが動作しなくなるのはなぜですか？

リムーバブルメディアアクセス制御の概要

リムーバブルメディアアクセス制御とは

MDE を利用する Windows マシンでデバイスコントロール機能を利用することで、リムーバブルメディアへのアクセス制御が可能です。

リムーバブルメディアへのアクセス制御を構成することで、USB フラッシュメモリや CD/DVD、WPAD 端末など、さまざまなリムーバブルメディアに対して読み取り、書き込みまたは実行アクセスの監査やブロックを行うことが可能です。

リムーバブルメディアアクセス制御の前提要件

下記公開情報に記載の通り、リムーバブルメディアアクセス制御は本記事執筆時点(2024 年 1 月) では、Windows 10 / 11 および macOS 11(Big Sur) 以降での利用をサポートしています。

参考情報：Microsoft Defender for Endpointのデバイス制御 | Microsoft Learn

リムーバブルメディアアクセス制御の設定方法

Windows マシンの場合、リムーバブルメディアアクセス制御機能はグループポリシーまたは Intune で構成することができます。

Intune を使用して管理する場合は、OMA-URI および XML ファイルを使用する方法と、Intune ユーザー インターフェイスを使用する方法のいずれか一方にて設定を行うことができます。

リムーバブルメディアアクセス制御の設定を複数のサービスで管理することは非推奨の構成にあたるため、設定を行う場合はいずれか 1 つの方法を選択してください。

参考情報：グループ ポリシーを使用してリムーバブルメディアアクセス制御を展開および管理する | Microsoft Learn

参考情報：Intune を使用してリムーバブルメディアアクセス制御を展開および管理する | Microsoft Learn

リムーバブルメディアアクセス制御の設定方法を選択する

Windows マシンのリムーバブルメディアアクセス制御は以下のいずれかの方法で構成できます。

1. グループポリシー

2. Intune(OMA-URI)

3. Intune(ユーザインタフェース)

グループポリシーまたは Intune(OMA-URI) を使用する場合は、制御対象となるリムーバブルメディアなどを指定するデバイスコントロールグループを指定する XML ファイルと、デバイスコントロールグループに対するアクセス制御ポリシーを記述する XML ファイルをそれぞれ作成し、端末にポリシーとして配布する必要があります。

グループポリシーまたは Intune(OMA-URI) でリムーバブルメディアアクセス制御を行う際に作成する必要がある XML ファイルについては、リムーバブルメディアアクセス制御を XML ファイルで構成する の項の記載を参照してください。

一方で、Intune(ユーザインタフェース)を使用する場合は Intune ポータル上のポリシー構成画面から GUI にてリムーバブルメディアアクセス制御を構成できます。

そのため、Intune(ユーザインタフェース)を使用する場合は XML ファイルの作成は不要です。

※ リムーバブルメディアアクセス制御の設定を複数のサービスで管理することは非推奨の構成にあたるため、設定を行う場合はいずれか 1 つの方法を選択してください。

グループポリシーを使用してリムーバブルメディアアクセス制御を構成する

グループポリシーを使用するための事前準備

グループポリシーを使用してデバイスコントロール機能のリムーバブルメディアアクセス制御を実施する場合、現在ご利用中の管理用テンプレートにデバイスコントロール機能の設定項目が含まれているかどうか事前に確認する必要があります。

デバイスコントロール機能は、Windows 10 の既定の管理用テンプレートなどを利用する環境では、既定で設定を変更することができません。

そのため、Active Directory やローカルグループポリシーを使用してデバイスコントロール機能の設定を行う場合には、必ず事前に以下の 2 つの設定項目が存在していることを確認してください。

• [Microsoft Defender ウイルス対策]>[機能]

• [Microsoft Defender ウイルス対策]>[デバイス制御]

参考情報：Deploy and manage device control in Microsoft Defender for Endpoint with Group Policy | Microsoft Learn

以下は Administrative Templates (.admx) for Windows 11 2022 Update (22H2) - v3.0 として配布している管理用テンプレートを使用してセントラル ストアの admx および adml を更新済みの環境でグループポリシーエディタを起動した画面です。

このように [Microsoft Defender ウイルス対策] 内に [機能] と [デバイス制御] の設定項目がそれぞれ表示されている場合には、デバイスコントロール機能のリムーバブルメディアアクセス制御をグループポリシーで構成することが可能です。

参考情報：セントラル ストアの作成と管理 - Windows Client | Microsoft Learn

参考情報：グループ ポリシーを使用してデプロイする | Microsoft Learn

グループポリシーでデバイスコントロール機能を有効化する

グループポリシーエディタ上でデバイスコントロール機能に対応する設定項目が存在することを確認したら、[Microsoft Defender ウイルス対策]>[機能]>[デバイス制御] の設定項目を有効化します。

端末でデバイスコントロール機能が有効化されているかどうかを確認したい場合、PowerShell で Select-Object DeviceControlState を実行し、出力結果が Enabled となることを確認してください。

1
2
3
4
5

PS> Get-MpComputerStatus | Select-Object DeviceControlState

DeviceControlState
------------------
Enabled

グループポリシーで既定の処理を構成する

必要に応じて、[Microsoft Defender ウイルス対策]>[デバイス制御]>[デバイスコントロールの既定の強制ポリシーの選択] からデバイスコントロール機能の既定の処理を構成することが可能です。

既定の処理を [拒否] とした場合、ポリシーによって明示的に許可されていない操作がデバイスコントロール機能によってブロックされます。

端末に適用されているデバイスコントロール機能の既定の処理は Get-MpComputerStatus | Select-Object DeviceControlDefaultEnforcement を PowerShell で実行することで確認できます。

本記事執筆時点で最新の WIndows 11 デバイスでは、上記の設定が未構成の場合にはデバイスコントロール機能の既定の処理は [許可(DefaultAllow)] が設定されています。

1
2
3
4
5

PS> Get-MpComputerStatus | Select-Object DeviceControlDefaultEnforcement

DeviceControlDefaultEnforcement
-------------------------------
DefaultAllow

なお、この設定はリムーバブルメディアアクセス制御を含むすべてのデバイスコントロール機能に対する設定であるため、既定の処理を [拒否] とした場合にはデバイスコントロール機能のプリンター保護機能の動作にも影響する点に注意が必要です。

そのため、リムーバブルメディアアクセスに対してのみ既定の処理を構成したい場合には、[デバイスコントロールの既定の強制ポリシーの選択] の設定は未構成のままとし、後述する シナリオ 1 - カスタムポリシーで既定のアクセス拒否ポリシーを構成する の手順でリムーバブルメディアアクセス制御ポリシーにて既定の動作を定義します。

organizationでプリンターがブロックされるのはなぜですか?

既定の適用設定は、すべてのデバイスコントロールコンポーネントに対するものです。

つまり、 Deny設定すると、すべてのプリンターもブロックされます。

プリンターを明示的に許可するカスタム ポリシーを作成するか、既定の適用ポリシーをカスタム ポリシーに置き換えることができます。

参考情報：organizationでプリンターがブロックされるのはなぜですか? | Microsoft Learn

グループポリシーでデバイスコントロールグループを構成する

グループポリシーでリムーバブルメディアアクセス制御を構成する際に必要なデバイスコントロールグループは、[Microsoft Defender ウイルス対策]>[デバイス制御]>[デバイス制御ポリシーグループの定義] から設定できます。

このポリシーでは、デバイスコントロールグループの設定を記述した XML ファイルが存在するネットワークファイル共有の UNC パス、またはローカルファイルのフルパスを指定します。

設定を適切に反映するためには、デバイスコントロール機能を利用する端末がネットワークファイル共有の UNC パス、またはローカルファイルのフルパスから XML ファイルをロードできる必要があります。

デバイスコントロールグループの設定を記述するための XML ファイルの作成方法については、後述する デバイスコントロールグループを XML ファイルで構成する および、グループポリシーまたは Intune の OMA-URI を使用してアクセス制御を構成するサンプルシナリオ の記載を参照してください。

グループポリシーでアクセス制御ポリシーを構成する

グループポリシーでリムーバブルメディアアクセス制御を構成する際に必要なアクセス制御ポリシーは、[Microsoft Defender ウイルス対策]>[デバイス制御]>[デバイス制御ポリシールールの定義] から設定できます。

こちらも同じく、アクセス制御ポリシーの設定を記述した XML ファイルが存在するネットワークファイル共有の UNC パス、またはローカルファイルのフルパスを指定します。

設定を適切に反映するためには、デバイスコントロール機能を利用する端末がネットワークファイル共有の UNC パス、またはローカルファイルのフルパスから XML ファイルをロードできる必要があります。

アクセス制御ポリシーの設定を記述するための XML ファイルの作成方法については、後述する リムーバブルメディアアクセス制御を XML ファイルで構成する および、グループポリシーまたは Intune の OMA-URI を使用してアクセス制御を構成するサンプルシナリオ の記載を参照してください。

デバイスコントロールの設定状況とポリシーの更新有無を確認する

デバイスコントロール機能の設定内容が反映されているか否かの確認のためには、以下の PowerShell コマンドレットを使用できます。

1
2
3
4
5

PS> Get-MpComputerStatus | Select-Object DeviceControlState,DeviceControlDefaultEnforcement,DeviceControlPoliciesLastUpdated

DeviceControlState DeviceControlDefaultEnforcement DeviceControlPoliciesLastUpdated
------------------ ------------------------------- --------------------------------
Enabled            DefaultAllow                    2024/01/20 8:30:36

デバイスコントロール機能が正常に有効化されている場合には、DeviceControlState の値が Enabled になります。

また、デバイスコントロールグループおよびアクセス制御ポリシーの情報が反映された場合には、DeviceControlPoliciesLastUpdated に表示される時刻が更新されます。

Intune の OMA-URI を使用してリムーバブルメディアアクセス制御を構成する

Intune の OMA-URI でデバイスコントロール機能を有効化する

MDE にオンボード済みの Windows マシンを Intune に登録したら、[デバイス]>[構成プロファイル] から新規プロファイルを作成し、プラットフォームを [Windows 10 以降]、プロファイルの種類を [テンプレート] として、カスタム構成プロファイルを選択します。

作成する構成プロファイルに、Enable_DeviceControl などの任意の名前を設定した後、[構成設定] 画面で ./Vendor/MSFT/Defender/Configuration/DeviceControlEnabled という OMA-URI を追加し、データ型を [整数]、値を 1 とします。

この設定によって、マシンでデバイスコントロール機能を有効化できます。

参考情報：Microsoft Intuneを使用してMicrosoft Defender for Endpointでデバイス制御をデプロイおよび管理する | Microsoft Learn

Intune の OMA-URI で既定の処理を構成する

同じ構成プロファイルで ./Vendor/MSFT/Defender/Configuration/DefaultEnforcement の OMA-URI を追加することで、デバイスコントロール機能の既定の処理を変更することができます。

データ型を [整数] とし、既定の処理を [許可] に設定する場合は 1 を、[拒否] に変更する場合は 2 を設定します。

なお、グループポリシーで設定する場合と同じく、既定の処理の設定はリムーバブルメディアアクセス制御を含むすべてのデバイスコントロール機能に対する設定であるため、既定の処理を [拒否] とした場合にはデバイスコントロール機能のプリンター保護機能の動作にも影響する点に注意が必要です。

Intune の OMA-URI でデバイスコントロールグループを構成する

Intune の OMA-URI を使用する場合も、グループポリシーで設定する場合と同じく XML ファイルでデバイスコントロールグループとアクセス制御ポリシーを設定します。

ただし、Intune の OMA-URI でデバイスコントロールグループを構成する場合、1 つのグループごとに 1 つの OMA-URI を割り当てる必要があります。

参考情報：OMA-URI を使用したグループの作成 | Microsoft Learn

この項では、シナリオ 4 - 特定のユーザに対してアクセスを許可する のサンプルポリシーを Intne の OMA-URI で設定する手順を紹介します。

このサンプルシナリオで使用する OMA-URI 用の XML ファイルは、以下の公開リポジトリからダウンロード可能です。

参考情報：Getting Started/Intune OMA-URI

デバイスコントロールグループの設定のため、以下の 3 つの XML ファイルを使用します。

• all_removable_media_devices{d8819053-24f4-444a-a0fb-9ce5a9e97862}.xml

1
2
3
4
5
6
7
8

<Group Id="{d8819053-24f4-444a-a0fb-9ce5a9e97862}" Type="Device">
<!-- ./Vendor/MSFT/Defender/Configuration/DeviceControl/PolicyGroups/%7Bd8819053-24f4-444a-a0fb-9ce5a9e97862%7D/GroupData -->
<Name>All removable media devices</Name>
<MatchType>MatchAny</MatchType>
<DescriptorIdList>
<PrimaryId>RemovableMediaDevices</PrimaryId>
</DescriptorIdList>
</Group>

• authorized_usbs{368a2c82-17be-4137-bffa-370bbdff9672}.xml

1
2
3
4
5
6
7
8

<Group Id="{368a2c82-17be-4137-bffa-370bbdff9672}" Type="Device">
<!-- ./Vendor/MSFT/Defender/Configuration/DeviceControl/PolicyGroups/%7B368a2c82-17be-4137-bffa-370bbdff9672%7D/GroupData -->
<Name>Authorized USBs</Name>
<MatchType>MatchAny</MatchType>
<DescriptorIdList>
<InstancePathId>USB\VID_154B&amp;PID_0028\6EA9150055800605</InstancePathId>
</DescriptorIdList>
</Group>

• readonly_usbs{23c24566-98a5-4218-8802-59614513b97e}.xml

1
2
3
4
5
6
7
8

<Group Id="{23c24566-98a5-4218-8802-59614513b97e}" Type="Device">
<!-- ./Vendor/MSFT/Defender/Configuration/DeviceControl/PolicyGroups/%7B23c24566-98a5-4218-8802-59614513b97e%7D/GroupData -->
<Name>Readonly USBs</Name>
<MatchType>MatchAny</MatchType>
<DescriptorIdList>
<VID_PID>090C_1000</VID_PID>
</DescriptorIdList>
</Group>

Intune の OMA-URI でデバイスコントロールグループを定義する場合、1 つのグループごとに ./Vendor/MSFT/Defender/Configuration/DeviceControl/PolicyGroups/%7b[GroupId]%7d/GroupData のような OMA-URI を作成し、グループの定義を含む XML ファイルをアップロードします。

[GroupId] の箇所は構成するデバイスコントロールグループの GroupID に置き換えます。

例えば、上記のサンプルファイル all_removable_media_devices{d8819053-24f4-444a-a0fb-9ce5a9e97862}.xml を使用する場合は、以下の ./Vendor/MSFT/Defender/Configuration/DeviceControl/PolicyGroups/%7Bd8819053-24f4-444a-a0fb-9ce5a9e97862%7D/GroupData という OMA-URI を追加します。

この時、[データ型] は [文字列(XML ファイル)] を選択し、Group 要素を 1 つ含むファイルをアップロードします。

上記と同様の手順で Authorized USBs と Read Only USBs のグループを定義する OMA-URI も追加します。

グループの XML を適用する前に、InstancePathId や VID_PID の指定する値をユーザが利用するメディアの情報に置き換えてください。

また、特にデバイスインスタンスパスを使用して明示的にデバイスを指定する場合には、XML ファイル内で & をエスケープ文字 & に置き換える必要がある点に注意してください。

Intune の OMA-URI でアクセス制御ポリシーを構成する

デバイスコントロールグループの OMA-URI を追加したので、次はこれらのグループと対応するアクセス制御ポリシーを登録します。

アクセス制御ポリシーを登録する場合も、1 つの PolicyRule ごとに 1 つの OMA-URI を登録する必要があります。

グループポリシー用の XML ファイルとは異なり、PolicyRules 要素にて複数の PolicyRule をまとめて記述することができない点に注意が必要です。

このサンプルシナリオで使用する OMA-URI 用のポリシー XML ファイルは、以下の公開リポジトリからダウンロード可能です。(ファイル名が step_4 から始まるものを使用します。)

参考情報：Getting Started/Intune OMA-URI

アクセス制御ポリシーの設定のため、以下の XML ファイルを使用します。

• step_4_-_deny_all_other_usbs{7beca8fe-313a-46f2-a090-399eb3d74318}.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<PolicyRule Id="{7beca8fe-313a-46f2-a090-399eb3d74318}" >
<!-- ./Vendor/MSFT/Defender/Configuration/DeviceControl/PolicyRules/%7B7beca8fe-313a-46f2-a090-399eb3d74318%7D/RuleData -->
<Name>Step 4 - Deny all other USBs</Name>
<IncludedIdList>
<GroupId>{d8819053-24f4-444a-a0fb-9ce5a9e97862}</GroupId>
</IncludedIdList>
<ExcludedIdList>
<GroupId>{368a2c82-17be-4137-bffa-370bbdff9672}</GroupId>
<GroupId>{23c24566-98a5-4218-8802-59614513b97e}</GroupId>
</ExcludedIdList>
<Entry Id="{c82cb32c-4c56-4c76-8897-b2cc99558299}">
<Type>Deny</Type>
<AccessMask>7</AccessMask>
<Options>0</Options>
</Entry>
<Entry Id="{70582e83-ea91-4b14-8f6c-f3921dab9d7a}">
<Type>AuditDenied</Type>
<AccessMask>7</AccessMask>
<Options>3</Options>
</Entry>
</PolicyRule>

• step_4_-_allow_access_to_writeable_usbs_for_some_users{a054bbcf-3454-4b95-9058-f7ed00deeee9}.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<PolicyRule Id="{a054bbcf-3454-4b95-9058-f7ed00deeee9}" >
<!-- ./Vendor/MSFT/Defender/Configuration/DeviceControl/PolicyRules/%7Ba054bbcf-3454-4b95-9058-f7ed00deeee9%7D/RuleData -->
<Name>Step 4 - Allow Access to Writeable USBs for some users</Name>
<IncludedIdList>
<GroupId>{368a2c82-17be-4137-bffa-370bbdff9672}</GroupId>
</IncludedIdList>
<ExcludedIdList>
</ExcludedIdList>
<Entry Id="{e78857e3-9e36-473b-a07c-fe1a1f356ec9}">
<Type>Allow</Type>
<AccessMask>63</AccessMask>
<Options>0</Options>
<Sid>S-1-1-0</Sid>
</Entry>
</PolicyRule>

• step_4_-_allow_read_only_access_to_read_only_usbs_for_some_users{b2b9cfc0-799d-457c-babc-da617d9a8b83}.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<PolicyRule Id="{b2b9cfc0-799d-457c-babc-da617d9a8b83}" >
<!-- ./Vendor/MSFT/Defender/Configuration/DeviceControl/PolicyRules/%7Bb2b9cfc0-799d-457c-babc-da617d9a8b83%7D/RuleData -->
<Name>Step 4 - Allow Read Only Access to Read Only USBs for some users</Name>
<IncludedIdList>
<GroupId>{23c24566-98a5-4218-8802-59614513b97e}</GroupId>
</IncludedIdList>
<ExcludedIdList>
</ExcludedIdList>
<Entry Id="{e78857e3-9e36-473b-a07c-fe1a1f356ec9}">
<Type>Allow</Type>
<AccessMask>9</AccessMask>
<Options>0</Options>
<Sid>S-1-1-0</Sid>
</Entry>
</PolicyRule>

アクセス制御ポリシーを登録する場合、./Vendor/MSFT/Defender/Configuration/DeviceControl/PolicyRules/%7b[PolicyRule Id]%7d/RuleData のような OMA-URI を作成し、1 つの PolicyRule を記述した XML ファイルをアップロードします。

OMA-URI の [PolicyRule Id] の箇所は、適用する PolicyRule の ID に置き換える必要があります。

例えば、サンプルポリシーの step_4_-_allow_access_to_writeable_usbs_for_some_users{a054bbcf-3454-4b95-9058-f7ed00deeee9}.xml を使用して OMA-URI を登録する場合には、./Vendor/MSFT/Defender/Configuration/DeviceControl/PolicyRules/%7Ba054bbcf-3454-4b95-9058-f7ed00deeee9%7D/RuleData というパスを指定します。

すべての設定が完了したら、カスタム構成プロファイルを保存し、任意のデバイスやユーザに割り当てます。

割り当てされたポリシーが端末に配信されると、デバイスコントロール機能が有効化され、端末にアクセス制御ポリシーが適用されます。

ポリシーが反映されたことを確認したい場合は PowerShell で Get-MpComputerStatus | Select-Object DeviceControlState,DeviceControlDefaultEnforcement,DeviceControlPoliciesLastUpdated を実行し、DeviceControlPoliciesLastUpdated の時刻が更新されていることを確認します。

Intune のユーザインターフェースを使用してリムーバブルメディアアクセス制御を構成する

Intune を使用する場合、カスタム構成プロファイルではなく [エンドポイントセキュリティ]>[攻撃面の減少] からデバイスコントロールプロファイルを作成することでもリムーバブルメディアのアクセス制御ポリシーを構成できます。

参考情報：Intune でデバイス制御を構成および管理する | Microsoft Learn

例えば、以下の手順ですべてのリムーバブルメディアに対してアクセス拒否ポリシーを構成できます。

1. まず、[エンドポイントセキュリティ]>[攻撃面の減少] の [再利用可能な設定] から [リムーバブル記憶域] のインスタンスを追加し、[PrimaryId] を [RemovableMediaDevices] に設定します。

2. 次に、[エンドポイントセキュリティ]>[攻撃面の減少] からデバイスコントロールプロファイルを作成し、[Device Control] のトグルを [構成されました] の状態に変更して [Included ID] に [再利用可能な設定] で作成したリムーバブルメディアグループを登録します。
3. 続けて、以下の画面のように [+ Edit Entry] からリムーバブルメディア制御ポリシーを設定することで、デバイスに対するアクセス拒否を構成できます。

Intune のユーザインタフェースによるリムーバブルメディアアクセス制御ポリシーの設定項目については以下の公開情報の記載を参照してください。

参考情報：Device control policies in Microsoft Defender for Endpoint | Microsoft Learn

デバイスコントロールグループを XML ファイルで構成する

グループポリシーまたは Intune の OMA-URI を使用してリムーバブルメディアアクセス制御を構成する場合、まずは制御対象となるデバイスやリムーバブルメディアをデバイスコントロールグループとして定義する必要があります。

デバイスコントロールグループの定義に関する最新の情報は以下の公開情報を参照してください。

参考情報：Device control policies in Microsoft Defender for Endpoint | Microsoft Learn

グループポリシーを使用する場合、デバイスコントロールグループの XML ファイルは 、要素 Groups の中に 1 つ以上の Group を定義する構造となっています。つまり、1 つの XML ファイル内に複数の Group の定義を統合できます。

一方で、Intune の OMA-URI を使用する場合、要素 Groups は使用せず、1 つの Group ごとに 1 つの OMA-URI を使用します。

各 Group には Id 属性として GroupID を指定する必要があります。ここで使用可能な ID は、PowerShell で New-Guid コマンドレットを実行することでランダムに生成することが可能です。

参考情報：Microsoft Defender for Endpoint デバイス コントロールリムーバブル ストレージに関してよく寄せられる質問 | Microsoft Learn

PrimaryId によるデバイスの指定

各 Group 要素には、グループ名や GroupID を記述できます。GroupID は後述するアクセス制御ポリシーの対象を指定するために使用します。

Group 内では、MatchType と DescriptorIdList によりグループの対象となるデバイスのプロパティを定義します。

例えば、MatchType が MatchAny に設定されている場合は、DescriptorIdList 内の要素を OR リレーションシップで評価することを意味しています。

つまり、DescriptorIdList 要素内で定義されたいずれかの条件に合致するデバイスが存在する場合、対象のデバイスがそのグループの対象となることを意味します。

DescriptorIdList 要素内で利用できる設定値として PrimaryId があります。

PrimaryId に RemovableMediaDevices を指定する場合、すべての RemovableMediaDevices(USB フラッシュメモリや USB 接続の外付け SSD など) を対象とする グループを定義することがきできます。

InstancePathId と VID_PID によるデバイスの指定

グループの対象となるデバイスの条件を記述できる DescriptorIdList では、 PrimaryId 以外にも InstancePathId や VID_PID などを利用できます。

InstancePathId は、デバイスインスタンスパスを利用して対象のデバイスを明示的に指定します。(InstancePathId の指定にはワイルドカードを使用することもできます。)

これは、特に USB フラッシュメモリなどの DiskDrive を指定するシナリオで使用できます。

なお、InstancePathId を指定する場合には、もともとのデバイスインスタンスパスに含まれる & をエスケープ文字 & に置き換えて XML に記述する必要があります。

VID_PID も同じく、特に USB フラッシュメモリなどの DiskDrive を指定するシナリオで使用できます。

VID_PID による指定は、 Vendor ID と Product ID のペアで記述されます。Product ID 部分についてはについてはワイルドカードもサポートしています。

参考情報：標準 USB 識別子 - Windows drivers | Microsoft Learn

その他のデバイスコントロールグループの指定方法

デバイスコントロールグループに含めるためのデバイスの指定は、上記のサンプル以外にも様々な条件で記述できます。

例えば、USB フラッシュメモリや USB 接続の外付け SSD などのリムーバブルメディアの場合、FriendlyNameId / PrimaryId / VID_PID / BusId / DeviceId / HardwareId / InstancePathId / SerialNumberId / PID / VID などの様々な値をデバイスの指定に使用できます。

特定のリムーバブルメディアの識別に使用できる値は、Windows デバイスマネージャや Microsoft Defender の Advanced Hunting クエリなどを使用して調査できます。

なお、Advanced Hunting で USB メディアの情報を調査するためには以下のような KQL クエリを使用できます。

1
2

DeviceEvents 
| where ActionType == "RemovableStoragePolicyTriggered"

より詳細な情報については以下の公開情報を参照してください。

参考情報：Device control policies in Microsoft Defender for Endpoint | Microsoft Learn

リムーバブルメディアアクセス制御を XML ファイルで構成する

制御対象となるデバイスやリムーバブルメディアをデバイスコントロールグループとして定義したら、各グループを対象とするアクセス制御ポリシーを作成します。

アクセス制御ポリシーの定義に関する最新の情報は以下の公開情報を参照してください。

参考情報：Device control policies in Microsoft Defender for Endpoint | Microsoft Learn

グループポリシーを使用する場合に使用するアクセス制御ポリシーの XML ファイルは、要素 PolicyRules の中に 1 つ以上の PolicyRule を定義する構造になっています。つまり、1 つの XML ファイル内に複数の PolicyRule の定義を統合できます。

一方で、Intune の OMA-URI を使用する場合、要素 PolicyRules は使用せず、1 つの PolicyRule ごとに 1 つの OMA-URI を使用します。

各 PolicyRule には Id 属性として PolicyRuleID を指定する必要があります。

※ ここで使用可能な ID は、デバイスコントロールグループと同じく PowerShell で New-Guid コマンドレットを実行することでランダムに生成することが可能です。

PolicyRule 要素の中には、IncludedIdList 、ExcludedIdList、Entry 要素などを記述します。

Entry 要素には、具体的なアクセス制御ポリシーの定義を記述します。

一方で、IncludedIdList や ExcludedIdList には、デバイスコントロールグループの XML で定義した Group 要素の GroupID を含めることができます。

これによって、各 PolicyRule 要素では、IncludedIdList で指定されたグループに対して Entry 要素で定義したアクセス制御ポリシーが適用されるようになります。( ExcludedIdList で指定された GroupID のオブジェクトはアクセス制御ポリシーの対象外になります。)

ディスクレベルで読み書き実行を拒否する

アクセス制御ポリシーでは、PolicyRule 要素の中に記述する Entry 要素にて詳細なアクセス許可や拒否を定義できます。

例えば、Entry 要素の Type が Deny、AccessMask に 7 が指定されている場合、ポリシーの対象となるグループに含まれるすべてのリムーバブルメディアに対して、DiskLevel での読み取り、書き込み、実行アクセスを拒否します。

このように、Windows マシンのリムーバブルメディアアクセス制御を行う場合、制御ポリシーは Type と AccessMask の組み合わせで定義されます。(Options 要素の設定値の意味は Type 要素の値によって変わります。)

まず、Type には、Allow または Deny および AuditAllowed または AuditDenied の 4 つのいずれかを指定できます。

Allow が指定されている場合には、AccessMask 要素の指定に従ってメディアへのアクセスが「許可」されます。

一方で、Deny が指定されている場合には、AccessMask 要素の指定に従ってメディアへのアクセスが「拒否」されます。

AuditAllowed または AuditDenied については、それぞれ Allow か Deny の動作に対応して通知やイベント送信を行うかどうかを指定できます。

AccessMask 要素では、ディスクレベルもしくはファイルシステムレベルでメディアに対する Read, Write, Execute の操作をそれぞれ指定できます。

例えば、AccessMask が 7 で Type がDenyの場合には、ディスクレベルでの Read, Write, Execute 操作をすべて拒否する設定が適用されます。

リムーバブルメディアアクセス制御ポリシーで使用できる AccessMask については以下の表を参照してください。

また、一般的に使用されるアクセス制御を構成するために使用する AccessMask については以下におまとめします。

アクセス制御ポリシーに関するより詳細な情報については以下の公開情報を参照してください。

参考情報：Understand mask access (Windows) | Microsoft Learn

SID を指定して読み取りと書き込みアクセス許可を構成する

ルールの Entry には、Sid や ComputerSid などの、より詳細な条件を定義可能な要素を含めることが可能です。

例えば、ルールの Entry に Sid 要素を追加し、特定のローカルユーザの SID を記述した場合には、その SID を持つユーザにのみリムーバブルメディアへのアクセスを許可を構成することが可能です。

例えば、以下のクエリを使用することで、 Microsoft Defender ポータルから Advanced Hunting にてログインユーザの SID を取得することができます。

1
2
3
4

DeviceLogonEvents
| where AccountSid != ""
| where not(AccountName startswith "umfd-") and not(AccountName startswith "dwm-")
| distinct AccountSid,AccountName,AccountDomain

また、AD ユーザや AD グループの SID については、ドメインコントローラにて Get-ADUser や Get-ADGroup コマンドレットを利用する方法などで調査できます。

ローカルユーザやローカルグループについては、一例として以下のコマンドで確認できます。

1
2
3
4
5

PS> (New-Object System.Security.Principal.NTAccount('Administrator')).Translate([System.Security.Principal.SecurityIdentifier])

# ローカルグループ BUILTIN\Users の SID を参照できる
PS> (New-Object System.Security.Principal.NTAccount('BUILTIN\Users')).Translate([System.Security.Principal.SecurityIdentifier])

汎用的な SID については 既知の SID の情報を参照してください。

また、その他、 Entry 要素で構成可能な項目の詳細は以下の公開情報を参照してください。

参考情報：Device control policies in Microsoft Defender for Endpoint | Microsoft Learn

Advanced Hunting でリムーバブルメディアアクセス制御イベントを確認する

実際にこのポリシーを適用し、許可していないリムーバブルメディアデバイスへのアクセスがブロックされることを確認します。

既定の構成では、このポリシーによってリムーバブルメディアへのアクセスがブロックされた場合、Windows セキュリティアプリからポップアップ通知が行われます。

また、Microsoft Device ポータルの [高度な追及] から、以下の Advanced Hunting クエリを発行することで、アクセス制御ポリシーによってブロックされた端末やリムーバブルメディアの詳細情報などを確認することができます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

DeviceEvents
| where ActionType == "RemovableStoragePolicyTriggered"
| extend parsed=parse_json(AdditionalFields)
| extend RemovableStorageAccess = tostring(parsed.RemovableStorageAccess)
| extend RemovableStoragePolicyVerdict = tostring(parsed.RemovableStoragePolicyVerdict)
| extend MediaBusType = tostring(parsed.BusType)
| extend MediaClassGuid = tostring(parsed.ClassGuid)
| extend MediaClassName = tostring(parsed.ClassName)
| extend MediaDeviceId = tostring(parsed.DeviceId)
| extend MediaInstanceId = tostring(parsed.DeviceInstanceId)
| extend MediaName = tostring(parsed.MediaName)
| extend RemovableStoragePolicy = tostring(parsed.RemovableStoragePolicy)
| extend MediaProductId = tostring(parsed.ProductId)
| extend MediaVendorId = tostring(parsed.VendorId)
| extend MediaSerialNumber = tostring(parsed.SerialNumber)
|project Timestamp, DeviceId, DeviceName, InitiatingProcessAccountName, ActionType, RemovableStorageAccess, RemovableStoragePolicyVerdict, MediaBusType, MediaClassGuid, MediaClassName, MediaDeviceId, MediaInstanceId, MediaName, RemovableStoragePolicy, MediaProductId, MediaVendorId, MediaSerialNumber, FolderPath, FileSize
| order by Timestamp desc

参考情報：Device control walkthroughs | Microsoft Learn

グループポリシーまたは Intune の OMA-URI を使用してアクセス制御を構成するサンプルシナリオ

この項では、公開されているサンプルポリシーを使用してリムーバブルメディアアクセス制御を構成する方法を紹介します。

なお、以下で引用するサンプル XML ファイルは、グループポリシー用のサンプルファイルである点に留意してください。

デバイスコントロールグループやアクセス制御ポリシーの記述方法はグループポリシーと Intune の OMA-URI を利用する場合で共通ですが、Intune の OMA-URI を使用する場合には、1 つのデバイスコントロールグループやアクセス制御ポリシーごとに 1 つの OMA-URI を作成する必要がある点に注意してください。

シナリオ 1 - カスタムポリシーで既定のアクセス拒否ポリシーを構成する

このサンプルポリシーのファイルは、以下の Github リポジトリからダウンロード可能です。

参考情報：Device control policy sample: Step 1 - Deny all access

ここで紹介するサンプル XML にてデバイスコントロールグループとアクセス制御ポリシーを記述することで、すべての RemovableMediaDevices に対してシステムレベルのアクセス拒否を構成することが可能です。

以下の XML では、すべてのリムーバブルメディアデバイスを対象とするデバイスコントロールグループを定義しています。

プロパティ名 MatchType に MatchAny が指定されている場合、続く DescriptorIdList プロパティ内で定義された属性は OR で比較されます。

つまり、端末に接続したデバイスが DescriptorIdList プロパティ内で定義したいずれかの条件に合致した場合に、その端末は GroupID {d8819053-24f4-444a-a0fb-9ce5a9e97862} を持つこのグループに含まれると判定されます。

1
2
3
4
5
6
7
8
9
10

<Groups>
<Group Id="{d8819053-24f4-444a-a0fb-9ce5a9e97862}" Type="Device">
<!-- ./Vendor/MSFT/Defender/Configuration/DeviceControl/PolicyGroups/%7Bd8819053-24f4-444a-a0fb-9ce5a9e97862%7D/GroupData -->
<Name>All removable media devices</Name>
<MatchType>MatchAny</MatchType>
<DescriptorIdList>
<PrimaryId>RemovableMediaDevices</PrimaryId>
</DescriptorIdList>
</Group>
</Groups>

上記のデバイスコントロールグループでは、PrimaryId が RemovableMediaDevices であるデバイスすべてを対象としています。

このようなデバイスには、USB フラッシュメモリや USB 接続の外付け SSD などが含まれます。

参考情報：グループの設定 | Microsoft Learn

次に、以下のアクセス制御ポリシーを作成します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<PolicyRules>
<PolicyRule Id="{d8e6f56c-f4c1-4875-ac45-51ad75d4580e}" >
<!-- ./Vendor/MSFT/Defender/Configuration/DeviceControl/PolicyRules/%7Bd8e6f56c-f4c1-4875-ac45-51ad75d4580e%7D/RuleData -->
<Name>Audit Deny</Name>
<IncludedIdList>
<GroupId>{d8819053-24f4-444a-a0fb-9ce5a9e97862}</GroupId>
</IncludedIdList>
<ExcludedIdList>
</ExcludedIdList>
<Entry Id="{ad059b6f-bc9d-44e4-8ab9-907d7d00fc97}">
<Type>Deny</Type>
<AccessMask>7</AccessMask>
<Options>0</Options>
</Entry>
<Entry Id="{4cf50b77-0152-4999-8d82-6f6afdf27b0b}">
<Type>AuditDenied</Type>
<AccessMask>7</AccessMask>
<Options>3</Options>
</Entry>
</PolicyRule>
</PolicyRules>

アクセス制御ポリシーではまず、ポリシーを適用する対象のデバイスをグループ単位で指定する必要があります。

そのため、IncludedIdList には上記のデバイスコントロールグループの GroupID を指定しています。

今回は除外対象のグループは指定しないので ExcludedIdList は空のままとしています。

ポリシーを適用する対象のデバイスをグループにて指定したら、Entry にてアクセス制御を構成します。

サンプルポリシーではリムーバブルメディアに対してすべてのアクセスを拒否するために、Type が Deny であり、AccessMask が 7 の Entry を定義しています。

また、Options を 3 に設定した AuditDenied の Entry を同時に定義することで、通知の表示とイベントの送信を行うようにポリシーを定義しています。

このサンプルポリシーを使用すると、すべてのリムーバブルメディアへのアクセスがブロックされます。

参考情報：手順 1: リムーバブル メディアをすべて拒否する | Microsoft Learn

シナリオ 2 - 特定の USB メモリに対してのみアクセスを許可する

このサンプルポリシーのファイルは、以下の Github リポジトリからダウンロード可能です。

参考情報：Step 2 - Allow authorized USBs full access

このシナリオでは、シナリオ 1 で作成した RemovableMediaDevices へのアクセス拒否ポリシーに加えて、特定の USB デバイスを使用する場合にのみアクセスを許可するポリシーを追加します。

まず、デバイスコントロールグループを定義する XML は以下の通りです。

All removable media devices グループはシナリオ 1 で作成したものと同一ですが、新たに Authorized USBs というグループが追加されています。(Intune の OMA-URI を使用する場合は、グループの定義ごとに OMA-URI を追加します)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<Groups>
<Group Id="{d8819053-24f4-444a-a0fb-9ce5a9e97862}">
    <Name>All removable media devices</Name>
<MatchType>MatchAny</MatchType>
<DescriptorIdList>
<PrimaryId>RemovableMediaDevices</PrimaryId>
</DescriptorIdList>
</Group><Group Id="{368a2c82-17be-4137-bffa-370bbdff9672}">
  <Name>Authorized USBs</Name>
  <MatchType>MatchAny</MatchType>
  <DescriptorIdList>
    <!-- This is an example.  Replace this with the instance path id of your device -->
    <InstancePathId>USB\VID_154B&amp;PID_0028\6EA9150055800605</InstancePathId>
  </DescriptorIdList>
</Group>
</Groups>

この XML では、InstancePathId を使用して、特定のデバイスインスタンスパスを持つ リムーバブルメディアのみを Authorized USBs グループの対象として指定しています。 (XML の仕様上、インスタンスパス内の & を & にエスケープしています)

次に、以下のアクセス制御ポリシーの XML をチェックします。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

<PolicyRules>
<PolicyRule Id="{7beca8fe-313a-46f2-a090-399eb3d74318}">
  <Name>Step 2 - Deny all but authorized USBs</Name>
  <IncludedIdList>
    <GroupId>{d8819053-24f4-444a-a0fb-9ce5a9e97862}</GroupId>
  </IncludedIdList>
  <ExcludedIdList>
    <GroupId>{368a2c82-17be-4137-bffa-370bbdff9672}</GroupId>
  </ExcludedIdList>
  <Entry Id="{c82cb32c-4c56-4c76-8897-b2cc99558299}">
    <Type>Deny</Type>
    <Options>0</Options>
    <AccessMask>7</AccessMask>
  </Entry>
  <Entry Id="{70582e83-ea91-4b14-8f6c-f3921dab9d7a}">
    <Type>AuditDenied</Type>
    <Options>3</Options>
    <AccessMask>7</AccessMask>
  </Entry>
</PolicyRule><PolicyRule Id="{a054bbcf-3454-4b95-9058-f7ed00deeee9}">
  <IncludedIdList>
    <GroupId>{368a2c82-17be-4137-bffa-370bbdff9672}</GroupId>
  </IncludedIdList>
  <Entry Id="{e78857e3-9e36-473b-a07c-fe1a1f356ec9}">
    <Type>Allow</Type>
    <Options>0</Options>
    <AccessMask>63</AccessMask>
  </Entry>
  <Name>Step 2 - Allow Full Access to Authorized USBs</Name>
</PolicyRule></PolicyRules>

Step 2 - Deny all but authorized USBs というポリシーの IncludedIdList には、シナリオ 1 と同じく All removable media devices の GroupID を指定していますが、同時に ExcludedIdList に新に追加した Authorized USBs グループの GroupID を指定しています。

さらに、2 つ目のポリシーである Step 2 - Allow Full Access to Authorized USBs では、IncludedIdList に Authorized USBs グループの GroupID を指定し、AccessMask が 63 の許可ルールを構成し、すべてのアクセスを明示的に許可する設定を定義しています。(Intune の OMA-URI を使用する場合は、ルールの定義ごとに OMA-URI を追加します)

このサンプルポリシーを使用すると、Authorized USBs グループで指定した InstancePathId を持つリムーバブルメディアにのみアクセスが許可され、その他すべてのリムーバブルメディアへのアクセスがブロックされます。

参考情報：手順 2: 承認された USB デバイスへのアクセスを許可する | Microsoft Learn

シナリオ 3 - デバイスごとに異なるアクセス許可を構成する

このサンプルポリシーのファイルは、以下の Github リポジトリからダウンロード可能です。

参考情報：Step 3 - Allow different access to different devices

このシナリオでは、シナリオ 2 で作成したポリシーを同様の手順で、複数のリムーバブルメディアに対してそれぞれ異なるアクセスを許可する設定を行います。

まずはデバイスコントロールグループを定義するために、グループポリシー用の XML ファイルである allow_different_access_to_different_groups.xml を確認します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<Groups>
<Group Id="{d8819053-24f4-444a-a0fb-9ce5a9e97862}">
    <Name>All removable media devices</Name>
<MatchType>MatchAny</MatchType>
<DescriptorIdList>
<PrimaryId>RemovableMediaDevices</PrimaryId>
</DescriptorIdList>
</Group><Group Id="{368a2c82-17be-4137-bffa-370bbdff9672}">
  <Name>Writeable USBs</Name>
  <MatchType>MatchAny</MatchType>
  <DescriptorIdList>
    <!-- This is an example.  Replace this with the instance path id of your device -->
    <InstancePathId>USB\VID_154B&amp;PID_0028\6EA9150055800605</InstancePathId>
  </DescriptorIdList>
</Group>
<Group Id="{23c24566-98a5-4218-8802-59614513b97e}">
  <Name>Readonly USBs</Name>
  <MatchType>MatchAny</MatchType>
  <DescriptorIdList>
    <!-- This is an example.  Replace this with the VID PID of another device -->
    <VID_PID>090C_1000</VID_PID>
  </DescriptorIdList>
</Group>
</Groups>

All removable media devices グループはこれまでのシナリオで作成したものと同じで、すべてのリムーバブルメディアを対象とするグループです。これは、カスタムポリシーによる既定のアクセス拒否を構成するために使用します。

上記のサンプル XML ファイルでは、Writeable USBs と Readonly USBs という 2 つのグループが追加で定義されます。(Intune の OMA-URI を使用する場合は、グループの定義ごとに OMA-URI を追加します)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<Group Id="{368a2c82-17be-4137-bffa-370bbdff9672}">
  <Name>Writeable USBs</Name>
  <MatchType>MatchAny</MatchType>
  <DescriptorIdList>
    <!-- This is an example.  Replace this with the instance path id of your device -->
    <InstancePathId>USB\VID_154B&amp;PID_0028\6EA9150055800605</InstancePathId>
  </DescriptorIdList>
</Group>

<Group Id="{23c24566-98a5-4218-8802-59614513b97e}">
  <Name>Readonly USBs</Name>
  <MatchType>MatchAny</MatchType>
  <DescriptorIdList>
    <!-- This is an example.  Replace this with the VID PID of another device -->
    <VID_PID>090C_1000</VID_PID>
  </DescriptorIdList>
</Group>

それぞれのグループは InstancePathId や VID_PID によって特定のリムーバブルメディアを指定しています。

続いて、アクセスポリシーを制御するための allow_different_access_to_different_rules.xml を確認します。

Step 3 - Deny all other USBs ルールはシナリオ 1、2 と同じく、All removable media devices グループに対してアクセス拒否を構成しています。

ただし、ExcludedIdList にて Writeable USBs と Readonly USBs の 2 つのグループを適用対象外としています。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

<PolicyRules>
<PolicyRule Id="{7beca8fe-313a-46f2-a090-399eb3d74318}">
  <Name>Step 3 - Deny all other USBs</Name>
  <IncludedIdList>
    <GroupId>{d8819053-24f4-444a-a0fb-9ce5a9e97862}</GroupId>
  </IncludedIdList>
  <ExcludedIdList>
    <GroupId>{368a2c82-17be-4137-bffa-370bbdff9672}</GroupId>
    <GroupId>{23c24566-98a5-4218-8802-59614513b97e}</GroupId>
  </ExcludedIdList>
  <Entry Id="{c82cb32c-4c56-4c76-8897-b2cc99558299}">
    <Type>Deny</Type>
    <Options>0</Options>
    <AccessMask>7</AccessMask>
  </Entry>
  <Entry Id="{70582e83-ea91-4b14-8f6c-f3921dab9d7a}">
    <Type>AuditDenied</Type>
    <Options>3</Options>
    <AccessMask>7</AccessMask>
  </Entry>
</PolicyRule><PolicyRule Id="{a054bbcf-3454-4b95-9058-f7ed00deeee9}">
  <IncludedIdList>
    <GroupId>{368a2c82-17be-4137-bffa-370bbdff9672}</GroupId>
  </IncludedIdList>
  <Entry Id="{e78857e3-9e36-473b-a07c-fe1a1f356ec9}">
    <Type>Allow</Type>
    <Options>0</Options>
    <AccessMask>63</AccessMask>
  </Entry>
  <Name>Step 3 - Allow Full Access to Writeable USBs</Name>
</PolicyRule>
<PolicyRule Id="{b2b9cfc0-799d-457c-babc-da617d9a8b83}">
  <IncludedIdList>
    <GroupId>{23c24566-98a5-4218-8802-59614513b97e}</GroupId>
  </IncludedIdList>
  <Entry Id="{e78857e3-9e36-473b-a07c-fe1a1f356ec9}">
    <Type>Allow</Type>
    <Options>0</Options>
    <AccessMask>9</AccessMask>
  </Entry>
  <Name>Step 3 - Allow Read Only Access to Read Only USBs</Name>
</PolicyRule>
</PolicyRules>

allow_different_access_to_different_rules.xml の中には、Step 3 - Deny all other USBs ルールの他に以下の 2 つのルールが記述されています。(Intune の OMA-URI を使用する場合は、ルールの定義ごとに OMA-URI を追加します)

まず、Step 3 - Allow Full Access to Writeable USBs ルールはシナリオ 2 と同じく AccessMask が 63 の Allow ルールによって Writeable USBs に完全なアクセス許可を構成しています。

一方で、Step 3 - Allow Read Only Access to Read Only USBs では、 Readonly USBs の GroupID に対して AccessMask が 9 の Allow ルールを構成しています。

AccessMask が 9(1 + 8) の場合、DiskLevel と FileSystemLevel の読み取りアクセスを同時に指定していることを意味します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<PolicyRule Id="{a054bbcf-3454-4b95-9058-f7ed00deeee9}">
  <IncludedIdList>
    <GroupId>{368a2c82-17be-4137-bffa-370bbdff9672}</GroupId>
  </IncludedIdList>
  <Entry Id="{e78857e3-9e36-473b-a07c-fe1a1f356ec9}">
    <Type>Allow</Type>
    <Options>0</Options>
    <AccessMask>63</AccessMask>
  </Entry>
  <Name>Step 3 - Allow Full Access to Writeable USBs</Name>
</PolicyRule>

<PolicyRule Id="{b2b9cfc0-799d-457c-babc-da617d9a8b83}">
  <IncludedIdList>
    <GroupId>{23c24566-98a5-4218-8802-59614513b97e}</GroupId>
  </IncludedIdList>
  <Entry Id="{e78857e3-9e36-473b-a07c-fe1a1f356ec9}">
    <Type>Allow</Type>
    <Options>0</Options>
    <AccessMask>9</AccessMask>
  </Entry>
  <Name>Step 3 - Allow Read Only Access to Read Only USBs</Name>
</PolicyRule>

このポリシーを適用すると、 Writeable USBs グループにて指定したリムーバブルメディアにのみ完全なアクセス許可が構成されます。

また、Readonly USBs グループで指定したリムーバブルメディアには読み取りアクセスのみが許可され、それ以外のすべてのリムーバブルメディアはアクセスが拒否されます。

参考情報：手順 3: さまざまな種類のデバイスに対してさまざまなレベルのアクセスを許可する | Microsoft Learn

シナリオ 4 - 特定のユーザに対してアクセスを許可する

このサンプルポリシーのファイルは、以下の Github リポジトリからダウンロード可能です。

参考情報：Step 4 - Allow different access to different devices for different users

デバイスコントロールグループを定義するグループポリシー用の XML ファイル allow_different_access_to_different_user_groups.xml は、シナリオ 3 で使用したものと同一です。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<Groups>
<Group Id="{d8819053-24f4-444a-a0fb-9ce5a9e97862}">
    <Name>All removable media devices</Name>
<MatchType>MatchAny</MatchType>
<DescriptorIdList>
<PrimaryId>RemovableMediaDevices</PrimaryId>
</DescriptorIdList>
</Group><Group Id="{368a2c82-17be-4137-bffa-370bbdff9672}">
  <Name>Writeable USBs</Name>
  <MatchType>MatchAny</MatchType>
  <DescriptorIdList>
    <!-- This is an example.  Replace this with the instance path id of your device -->
    <InstancePathId>USB\VID_154B&amp;PID_0028\6EA9150055800605</InstancePathId>
  </DescriptorIdList>
</Group>
<Group Id="{23c24566-98a5-4218-8802-59614513b97e}">
  <Name>Readonly USBs</Name>
  <MatchType>MatchAny</MatchType>
  <DescriptorIdList>
    <!-- This is an example.  Replace this with the VID PID of another device -->
    <VID_PID>090C_1000</VID_PID>
  </DescriptorIdList>
</Group>
</Groups>

アクセス制御ポリシーを記述している allow_different_access_to_different_users_rules.xml もシナリオ 3 のものとほぼ同一ですが、書き込みや読み取りアクセスを許可するルールの Entry に <Sid>S-1-1-0</Sid> という項目が追加で記述されています。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

<PolicyRules>
<PolicyRule Id="{7beca8fe-313a-46f2-a090-399eb3d74318}">
  <Name>Step 4 - Deny all other USBs</Name>
  <IncludedIdList>
    <GroupId>{d8819053-24f4-444a-a0fb-9ce5a9e97862}</GroupId>
  </IncludedIdList>
  <ExcludedIdList>
    <GroupId>{368a2c82-17be-4137-bffa-370bbdff9672}</GroupId>
    <GroupId>{23c24566-98a5-4218-8802-59614513b97e}</GroupId>
  </ExcludedIdList>
  <Entry Id="{c82cb32c-4c56-4c76-8897-b2cc99558299}">
    <Type>Deny</Type>
    <Options>0</Options>
    <AccessMask>7</AccessMask>
  </Entry>
  <Entry Id="{70582e83-ea91-4b14-8f6c-f3921dab9d7a}">
    <Type>AuditDenied</Type>
    <Options>3</Options>
    <AccessMask>7</AccessMask>
  </Entry>
</PolicyRule><PolicyRule Id="{a054bbcf-3454-4b95-9058-f7ed00deeee9}">
  <IncludedIdList>
    <GroupId>{368a2c82-17be-4137-bffa-370bbdff9672}</GroupId>
  </IncludedIdList>
  <Entry Id="{e78857e3-9e36-473b-a07c-fe1a1f356ec9}">
    <Type>Allow</Type>
    <Options>0</Options>
    <AccessMask>63</AccessMask>
    <Sid>S-1-1-0</Sid>
  </Entry>
  <Name>Step 4 - Allow Access to Writeable USBs for some users</Name>
</PolicyRule>
<PolicyRule Id="{b2b9cfc0-799d-457c-babc-da617d9a8b83}">
  <IncludedIdList>
    <GroupId>{23c24566-98a5-4218-8802-59614513b97e}</GroupId>
  </IncludedIdList>
  <Entry Id="{e78857e3-9e36-473b-a07c-fe1a1f356ec9}">
    <Type>Allow</Type>
    <Options>0</Options>
    <AccessMask>9</AccessMask>
    <Sid>S-1-1-0</Sid>
  </Entry>
  <Name>Step 4 - Allow Read Only Access to Read Only USBs for some users</Name>
</PolicyRule>
</PolicyRules>

ルールの Entry に Sid という項目が追加で記述されている場合、その Entry には追加の条件が定義されます。

Sid 要素にはローカルユーザやコンピュータ、または Microsoft Entra オブジェクトの SID などを含めることができます。

この設定によって、Entry 要素で記述されたルールを特定のユーザやユーザグループに適用するかどうかを指定できます。

参考情報：Device control policies in Microsoft Defender for Endpoint | Microsoft Learn

上記のサンプルでは S-1-1-0 というすべてのユーザを表すグループの SID を指定していますが、特定のローカルユーザの SID に置き換えることで、その SID を持つユーザにのみリムーバブルメディアへのアクセスを許可を構成することが可能です。

参考情報：手順 4: 特定のユーザーまたはグループのデバイスへのさまざまなレベルのアクセスを許可する | Microsoft Learn

リムーバブルメディアアクセス制御に関するよくある質問

デバイスコントロール機能やリムーバブルメディアアクセス制御に関するよくある質問の多くは、以下の公開情報におまとめしております。

参考情報：Microsoft Defender for Endpoint Device Control frequently asked questions | Microsoft Learn

特定のメディアを指定するために使用するデバイスインスタンスパスなどの確認方法がわかりません

特定のメディアを明示的に指定するために使用するデバイスインスタンスパスなどの情報の多くは、Windows のデバイスマネージャーから対象デバイスのプロパティを確認することで特定できます。

参考情報：How do I find the media property in the Device Manager? |Microsoft Learn

例えば、USB フラッシュメモリのデバイスインスタンスパスは、デバイスマネージャーの以下のプロパティから参照できます。

また、Microsoft Defender ポータルの Advanced Hunting で以下のようなクエリを発行することも有効です。

1
2
3
4
5
6
7
8
9

DeviceEvents
| where ActionType == "PnpDeviceConnected"
| extend parsed=parse_json(AdditionalFields)
| extend MediaClass = tostring(parsed.ClassName)
| extend MediaDeviceId = tostring(parsed.DeviceId)
| extend MediaDescription = tostring(parsed.DeviceDescription)
| extend MediaSerialNumber = tostring(parsed.SerialNumber)
| project Timestamp, DeviceId, DeviceName, AccountName, AccountDomain, MediaClass, MediaDeviceId, MediaDescription, MediaSerialNumber, parsed
| order by Timestamp desc

参考情報：デバイス コントロールのチュートリアル | Microsoft Learn

上記のサンプルクエリを実行すると、デバイスに接続されたリムーバブルメディアのクラス名や DeviceId などの情報を取得できるため、アクセス制御ポリシーの設定に役立てることができます。

他にも、シナリオ 1 - カスタムポリシーで既定のアクセス拒否ポリシーを構成する を参考に、PrimaryId に RemovableMediaDevices や WpdDevices、または CdRomDevices などを設定した広範なアクセス拒否ポリシーを一度端末に適用して制御したいメディアへのアクセスをブロックし、そのイベントを確認する方法も有効です。

参考情報：サポート対象のデバイス | Microsoft Learn

このクエリを使用してアクセス拒否ポリシーによりメディアへのアクセスがブロックされた際の RemovableStoragePolicyTriggered イベントを参照すると、デバイスインスタンスパスや Vendor/Product ID など、アクセス制御ポリシーで明示的にデバイスを指定する際に使用できる様々な情報を参照できます。

参考情報：手順 1: リムーバブル メディアをすべて拒否する | Microsoft Learn

既定の処理を拒否に設定すると読み取り許可のアクセス制御ポリシーが動作しなくなるのはなぜですか？

デバイスコントロール機能が有効な環境で既定の処理が [拒否] に設定されている場合、明示的にポリシーで許可されていない限り、すべてのリムーバブルメディアやプリンターへのアクセスは拒否されます。

参考情報：Device control policies in Microsoft Defender for Endpoint | Microsoft Learn

この時、ディスクレベルまたはファイルシステムレベルのみを指定してアクセス許可ポリシーを作成する場合、対象メディアへの読み取り、書き込み、または実行が拒否される問題が発生する場合があります。

そのため、既定の処理を [拒否] にしている環境で明示的にリムーバブルメディアへのアクセス許可を構成する場合には、ディスクレベルとファイルシステムレベルの両方のアクセス許可を明示的に指定する必要がある点に注意してください。

例えば、読み取りアクセスのみを許可したい場合は、1+8 で 9 を AccessMask として指定します。

また、すべてのアクセスを許可したい場合には、63 を AccessMask として設定します。

参考情報：Understand mask access (Windows) | Microsoft Learn

まとめ

この記事では、Windows マシンでデバイスコントロール機能のアクセス制御ポリシーを構成する方法についておまとめいたしました。

デバイスコントロール機能に関する最新の情報については公開情報を参照してください。

参考情報：Microsoft Defender for Endpointのデバイス制御 | Microsoft Learn

この記事では、Windows Server 2012 R2 と Windows Server 2016 を Microsoft Defender for Endpoint(MDE) にオンボード / オフボードする方法についておまとめいたします。

なお、本記事の内容は、2023 年 11 月 5 日時点で最新の情報を元に作成いたしております。

Windows Server のオンボードに関する最新情報については、Microsoft Learn をご参照ください。

また、サーバを MDE にオンボードした後の正常性確認方法については以下の Blog 記事にておまとめしておりますので、併せてご参照ください。

参考：Microsoft Defender for Endpoint(MDE) にオンボードされたデバイスの正常性確認ポイント | Japan CSS Security Support Blog

本記事の内容

• Windows Server を MDE にオンボードする前の確認ポイント
  • オンボード端末の OS バージョンを確認する
  • サーバをオンボードする方法を決定する
  • 端末のネットワーク接続を確認する
  • サードパーティ製のウイルス対策製品の有無を確認する
  • MMA を使用した旧オンボード方法で MDE にオンボード済みかどうか確認する
• サーバを MDE にオンボードするためのスクリプトを配置する
  • MDE へのオンボードに必要なファイルを用意する
  • オンボードに必要なファイルを配置する
• インストールスクリプトを使用してサーバを MDE にオンボードする
  • MMA によりサーバを MDE にオンボードしている場合
  • サードパーティ製のウイルス対策製品がインストールされている場合
  • サーバを MDE にオンボードするコマンド
  • MMA からの移行オンボードを行う場合のコマンド
  • サーバが MDE にオンボードされたことを確認する
  • インストールスクリプトを使用して統合エージェントのアンインストールとオフボード操作を行う
• MDE のオンボードに失敗する場合のトラブルシューティング
  • サーバで通信テストを行う
  • レポートから通信テストの結果を確認する
  • 通信にプロキシサーバを利用する場合の確認ポイント
• まとめ

Windows Server を MDE にオンボードする前の確認ポイント

オンボード端末の OS バージョンを確認する

Windows Server を MDE にオンボードする前に、サーバの OS バージョンを確認します。

下記リンク先の公開情報に記載の通り、Windows Server 2016 以前と Windows Server 2019 以降のバージョンでは、MDE へのオンボード方法が異なる点にご留意ください。

参考情報：Windows サーバーを Microsoft Defender for Endpoint にオンボードします | Microsoft Learn

なお、この記事では、Windows Server 2012 R2 および Windows Server 2016 を MDE にオンボードする方法について記載します。

Windows Server 2019 以降のサーバを MDE にオンボードする場合は、Windows クライアント を MDE にオンボードする に記載の手順に従います。

注意：

Windows Server 2012 R2 は 2023年 10 月 10 日に延長サポートが終了いたしております。

サポートが終了した OS を MDE にオンボードして利用いただくことは非推奨ですので、MDE をご利用いただく場合は、サポート中の OS バージョンへの更新を実施ください。

参考情報：Windows Server 2012 R2 - Microsoft Lifecycle | Microsoft Learn

サーバをオンボードする方法を決定する

MDE にオンボードするサーバのバージョンが Windows Server 2012 R2 または Windows Server 2016 であることを確認したら、次はサーバを MDE にオンボードする方法を決定します。

サーバを MDE にオンボードする場合のステップを以下の通り簡単にまとめます。

1. MDE にオンボードするサーバが、システムや通信などの最小要件を満たすことを確認します。また、Windows Server 2012 R2 および 2016 をオンボードする場合の要件 についても確認を行います。

2. Microsoft 365 Defender ポータルからダウンロード可能なインストールパッケージ(md4ws.msi) を使用して、サーバに統合エージェントをインストールします。

3. 統合エージェントパッケージをインストールしたら、展開方法に合わせてダウンロードしたオンボードスクリプトをサーバで実行することで、オンボード操作が完了します。グループポリシー用のスクリプトを使用する場合は、グループポリシーや Install.ps1 を用いて実行する必要があります。

なお、上記の手順は、Microsoft Defender for Cloud(MDfC) の MDE 統合機能を利用しないサーバを MDE にオンボードする場合の手順です。

MDE 統合機能を利用する場合は、ユーザによるパッケージのダウンロードやサーバへの展開作業は不要です。

端末のネットワーク接続を確認する

サーバを MDE にオンボードする前に、端末のネットワーク接続を確認する必要があります。

※ MDE にオンボードされたサーバが上記の通信先との接続に失敗する場合、サーバの情報が Microsoft 365 Defender ポータルに登録されず、EDR などの保護機能の利用に問題が発生する可能性があります。

MDE を使用してサーバを保護するためには、下記の公開情報の [スプレッドシートをダウンロードします] からダウンロード可能なスプレッドシート内の [Microsoft Defender URLs] シートに一覧されている宛先との通信が可能である必要があります。

参考情報：商用のお客様向けのMicrosoft Defender for Endpoint URL リスト (標準)

注意：

MDE の稼働に必要な暗号化通信の復号はサポートされておりません。

そのため、ユーザの環境で TLS(SSL) インスペクションのような HTTPS 通信を復号するシステムを利用する場合は、必ず MDE の通信要件にリストされている通信先を、復号の対象から除外する必要があります。

※ 本記事執筆時点でパブリック プレビュー中の合理化(Streamlined)された接続を使用してオンボードを行う場合には、統合 URL リストのMicrosoft Defender for Endpoint (NEW - 合理化) からダウンロード可能なスプレッドシートを参照します。

なお、もし MDE にオンボードするサーバがインターネットに直接接続できない環境に配置されている場合には、以下の公開情報にてご案内している手順でプロキシサーバを構成いただく必要があります。

参考情報：情報保護のためにデバイス プロキシとインターネット接続の設定を構成する | Microsoft Learn

上記の公開情報にてご案内している通り、 MDE の通信要件を満たすためには、以下のいずれかのプロキシ設定を使用できます。

1. WinHTTP プロキシ設定

2. EDR センサー用のレジストリベースの静的プロキシ設定

※ WinHTTP プロキシ設定は Windows インターネットブラウザプロキシ(WinINet) とは異なります。

また、Microsoft Defender ウイルス対策(MDAV) のクラウド保護やセキュリティインテリジェンスの更新に使用するために、下記公開情報にてご案内している Microsoft Defender ウイルス対策用の静的プロキシ設定も実施いただくことを推奨します。

参考情報：Microsoft Defender ウイルス対策の静的プロキシを構成する | Microsoft Learn

情報：

2023 年 10 月 26 日時点でパプリックプレビューとして提供されている「合理的な接続」を使用してデバイスをオンボードする場合の通信要件については下記の公開情報の記載を参照してください。

参考情報：Onboarding devices using streamlined connectivity for Microsoft Defender for Endpoint | Microsoft Learn

サードパーティ製のウイルス対策製品の有無を確認する

MDE にオンボードするサーバが、サードパーティ製のウイルス対策製品を利用しているか、もしくは利用する予定があるか確認します。

MDE による EDR(Endpoint Detection and Response)保護機能は、EPP(エンドポイント保護)機能を持つサードパーティ製のウイルス対策製品と併用して利用いただくことが可能です。

しかし、サーバで MDE と他のウイルス対策製品を併用する場合には、サーバで Microsoft Defender ウイルス対策(MDAV)をパッシブモードに変更する必要があります。

参考情報：Microsoft Defender ウイルス対策の他のセキュリティ製品との互換性 | Microsoft Learn

MMA を使用した旧オンボード方法で MDE にオンボード済みかどうか確認する

Windows Server 2012 R2 および 2016 にてすでに MDE をご利用中の場合には、対象のサーバが Microsoft Monitoring Agent(MMA) を使用する旧オンボード方法によって MDE にオンボードされているかどうかを確認します。

参考情報：Windows サーバーを Microsoft Defender for Endpoint にオンボードします | Microsoft Learn

サーバを MDE にオンボードするためのスクリプトを配置する

本記事では、統合エージェントのインストールとオンボードスクリプトの実行を行うために弊社が提供しているツールである Install.ps1 を使用してサーバを MDE にオンボードする方法について紹介します。

Install.ps1 を使用すると、各端末を手動で MDE にオンボードすることや、Active Directory 管理下のサーバを MDE にオンボードすることなどが可能になります。

参考情報：グループ ポリシーを使用して Microsoft Defender for Endpoint のインストールパッケージとオンボード パッケージを適用する

MDE へのオンボードに必要なファイルを用意する

サーバをオンボードする方法を決定する にて Windows Server 2012 R2 または 2016 を MDE にオンボードする方法を決定したら、オンボード操作に必要な以下のファイルを Microsoft 365 Defender ポータルから取得します。

※ MDE 統合機能を利用して MDE へのオンボードを行う場合は、パッケージのダウンロードやサーバへの展開作業は不要です。

• インストールパッケージ(md4ws.msi)

• オンボードスクリプト

• Install.ps1

MDE へのオンボードに必要なインストールパッケージとオンボードスクリプトは、Microsoft 365 Defender ポータルの [設定]>[エンドポイント]>[オンボーディング] からダウンロードすることが可能です。

Windows Server 2012 R2 または 2016 用のパッケージを取得する場合は、オペレーティングシステムを「Windows Server 2012 R2 または 2016」に変更します。

また、[展開方法] は使用するオンボード方法に合わせて選択します。

Install.ps1 を使用して MDE へのオンボードを行う場合は [展開方法] の設定を「グループポリシー」に変更します。

また、Install.ps1 は ダウンロードリンク からダウンロードできます。

上記のリンク先からダウンロードした mdefordownlevelserver-main.zip を展開すると、Microsoft によって署名された Install.ps1 ファイルを取得することができます。

参考情報：インストーラースクリプト

オンボードに必要なファイルを配置する

続いて、取得したインストールパッケージ(md4ws.msi)、オンボードスクリプト(WindowsDefenderATPOnboardingScript.cmd)、Install.ps1 の 3 つのファイルを MDE にオンボードするサーバからアクセス可能なフォルダに配置します。

特定のサーバのみを MDE にオンボードする場合、これらのファイルはそのサーバのローカルフォルダに配置することができます。

また、Active Directory を使用して複数のサーバを一斉に MDE にオンボードする場合は、MDE にオンボードするサーバからアクセス可能な共有フォルダにこれらのファイルを配置する必要があります。(共有フォルダを利用する場合は、対象の共有フォルダに対して書き込みアクセスが許可されている必要があります。)

本記事では、\\FileShareServer\MDEOnboard という UNC パスでアクセス可能な共有フォルダ内に、md4ws.msi、WindowsDefenderATPOnboardingScript.cmd、Install.ps1 の 3 つのファイルを配置した環境で動作確認を実施します。

なお、Install.ps1 を使用してオンボードを行う場合には、md4ws.msi のファイル名は変更せず、Install.ps1 と同じフォルダに配置する必要がある点に注意が必要です。

※ オンボーディングスクリプト(WindowsDefenderATPOnboardingScript.cmd) は必ずしも同じフォルダに配置いただく必要はありません。

インストールスクリプトを使用してサーバを MDE にオンボードする

Install.ps1 を使用し、以下の手順で Windows Server 2012 R2 または 2016 を MDE にオンボードします。

事前に必ず、サーバをオンボードする方法を決定する の項を参照し、MDE にオンボードするサーバが Windows Server 2012 R2 または 2016 であることを確認します。

Windows Server 2019 以降のバージョンを使用する場合は、Windows クライアント を MDE にオンボードする に記載の手順に従います。

この時、MDE にオンボードするサーバが要件を満たすことを必ず確認してください。

サーバに必要な更新プログラムが適用されていない場合、統合エージェントのインストールやオンボード操作に失敗する場合があります。

また、サーバが MDE の通信要件を満たしていない場合には、端末の情報が正常にサービスに連携されずにポータルに端末が登録されない問題や、検知アラートを出力できない問題が発生する可能性があります。

MDE の通信要件については 端末のネットワーク接続を確認する の記載を参照してください。

サーバを MDE にオンボードした後で通信の問題が発生した場合のトラブルシューティングを行う際には、MDE にオンボードしたサーバの通信テスト方法 の記載を参照してください。

MMA によりサーバを MDE にオンボードしている場合

MDE にオンボードするサーバが、すでに MMA によって MDE にオンボードされているか確認します。

サーバに MMA がインストールされている場合、C:\Program Files\Microsoft Monitoring Agent\Agent\AgentControlPanel.exe を起動することで MMA に登録されているワークスペース ID などの情報を確認できます。

なお、ご利用テナントの MDE にサーバをオンボードするために登録するワークスペース ID は、Microsoft 365 Defender ポータルの [設定]>[エンドポイント]>[オンボーディング] 画面でオペレーティングシステムを [Windows Server 2008 R2 SP1] に変更することで確認いただくことが可能です。

サーバがすでに MMA によってオンボードされている場合には、事前に MMA をアンインストールするか、MMA に登録されている MDE のオンボードに使用しているワークスペース ID を削除してください。

また、サーバの台数が多い場合には、[MMA からの移行オンボードを行う場合](#MMA からの移行オンボードを行う場合) に記載の手順で、Install.ps1 を使用して MMA からワークスペース ID の情報を削除し、MDE へのオンボードを行うことも可能です。

サードパーティ製のウイルス対策製品がインストールされている場合

サードパーティ製のウイルス対策製品の有無を確認する の項を参照し、MDE にオンボードするサーバでサードパーティ製のウイルス対策製品を使用している、もしくは使用する予定があるか確認します。

サードパーティ製のウイルス対策製品を MDE と併用する場合は、Windows Server とパッシブ モード に記載の手順で必ずパッシブモードを有効化する必要があります。

また、すでにサードパーティ製のウイルス対策製品が稼働しているサーバを MDE にオンボードする場合は、一度サードパーティ製のウイルス対策製品をアンインストールいただき、統合エージェントのインストールと MDE へのオンボード操作を実施後にウイルス対策製品を再インストールいただくことをおすすめします。

もしサードパーティ製のウイルス対策製品アンインストールせずに統合エージェントのインストールと MDE へのオンボード操作を実施する場合は、オンボード作業の前に必ず MDAV のパッシブモード設定 を有効化してください。

また、端末のネットワーク接続を確認する ので紹介したスプレッドシートの [Microsoft Defender Processes] シートに記載のプロセスをサードパーティ製のウイルス対策製品のスキャン除外リストに登録いただくとともに、サードパーティ製のウイルス対策製品を MDAV の除外リスト に登録いただくことをおすすめします。

参考情報：Windows サーバーを Microsoft Defender for Endpoint にオンボードします | Microsoft Learn

注意：

Windows Server 2016 以降のサーバですでにサードパーティ製のウイルス対策製品を使用している場合、グループポリシーやレジストリ設定にて Microsoft Defender ウイルス対策(MDAV) が無効化されている場合があります。

サーバ OS の場合はサードパーティ製のウイルス対策製品をアンインストールしても MDAV の無効化設定は解除されないため、MDE をご利用いただく前に必ず設定を解除してください。

サーバを MDE にオンボードするコマンド

Install.ps1 を使用してサーバを手動で MDE にオンボードする場合、管理者権限で起動した PowerShell から以下のコマンドを実行します。

1

PowerShell.exe -ExecutionPolicy RemoteSigned \\FileShareServer\MDEOnboard\Install.ps1 -OnboardingScript \\FileShareServer\MDEOnboard\WindowsDefenderATPOnboardingScript.cmd

※ 必要なファイルの配置については サーバを MDE にオンボードするためのスクリプトを配置する の項を参照します。

※ 本記事では \\FileShareServer\MDEOnboard という UNC パスでアクセス可能な共有フォルダ内に、md4ws.msi、WindowsDefenderATPOnboardingScript.cmd、Install.ps1 の 3 つのファイルを配置した環境で動作確認を実施しています。

※ \\FileShareServer\MDEOnboard には任意の UNC パスもしくはローカルのフォルダパスを指定することが可能です。

グループポリシーを使用して Install.ps1 による MDE へのオンボード操作を行う場合は以下の公開情報の手順を参照してください。

参考情報：グループ ポリシーを使用して Microsoft Defender for Endpoint のインストールパッケージとオンボード パッケージを適用する

MMA からの移行オンボードを行う場合のコマンド

すでに MMA を使用して MDE にオンボードしているサーバを、新しい統合エージェントを使用して MDE にオンボードする場合、管理者権限で起動した PowerShell から以下のコマンドを実行します。

1

PowerShell.exe -ExecutionPolicy RemoteSigned \\FileShareServer\MDEOnboard\Install.ps1 -RemoveMMA <MMA に登録されているワークスペース ID> -OnboardingScript \\FileShareServer\MDEOnboard\WindowsDefenderATPOnboardingScript.cmd

※ \\FileShareServer\MDEOnboard には任意の UNC パスもしくはローカルのフォルダパスを指定することが可能です。

なお、事前に MMA をアンインストール済みの場合や、MMA から MDE のオンボードのために登録しているワークスペース ID を削除している場合は、上記のコマンドではなく サーバを MDE にオンボードするコマンド に記載のコマンドを使用します。

また、グループポリシーを使用して Install.ps1 を使用した MMA からの移行操作を行う場合も、以下の公開情報同じ手順をご利用いただくことができます。

参考情報：グループ ポリシーを使用して Microsoft Defender for Endpoint のインストールパッケージとオンボード パッケージを適用する

サーバが MDE にオンボードされたことを確認する

サーバが MDE に正常にオンボードされたことを確認したい場合には、以下の公開情報の手順をご利用いただけます。

参考情報：Microsoft Defender for Endpoint(MDE) にオンボードされたデバイスの正常性確認ポイント | Japan CSS Security Support Blog

インストールスクリプトを使用して統合エージェントのアンインストールとオフボード操作を行う

テナントの移行やトラブルシューティングの目的でサーバを MDE からオフボードし、統合エージェントのアンインストールを行う場合にも Install.ps1 を使用することができます。

Install.ps1 を使用して統合エージェントのアンインストールとオフボード操作を行う場合は、以下の手順に従います。

1. Microsoft 365 Defender ポータルにサインインし、[設定]>[オフボーディング] を開きます。

2. プラットフォームを [Windows Server 2012 および 2016]、[展開方法] を [グループポリシー] に変更した上で、オフボードパッケージ(WindowsDefenderATPOffboardingPackage_valid_until_20XX-XX-XX.zip)をダウンロードします。

   ※ オフボードスクリプトには 30 日間の有効期限が設定される点にご留意ください。

3. 次に、取得したオフボードパッケージ内のオフボードスクリプト(WindowsDefenderATPOffboardingScript_valid_until_XX-XX-XX.cmd) を サーバを MDE にオンボードするためのスクリプトを配置する の項と同じ手順で取得した Install.ps1 と同じ、MDE からオフボードするサーバからアクセス可能なフォルダに配置します。

4. MDE からオフボードするサーバにアクセスし、管理者権限で起動した PowerShell から以下のコマンドを実行することで、統合エージェントのアンインストールと MDE からのオフボードが完了します。

1

PowerShell.exe -ExecutionPolicy RemoteSigned \\FileShareServer\MDEOnboard\Install.ps1 -Uninstall -OffboardingScript \\FileShareServer\MDEOnboard\WindowsDefenderATPOffboardingScript_valid_until_XX-XX-XX.cmd

※ オフボードスクリプトのファイル名の XX には有効期限の日付の値が入ります。

※ \\FileShareServer\MDEOnboard には任意の UNC パスもしくはローカルのフォルダパスを指定することが可能です。

5. 各サーバで MDE からのオフボードと統合エージェントのアンインストールが完了したことを確認したい場合は、[sc.exe query sense] コマンドを実行します。

   Windows Server 2012 R2 および 2016 の場合には、Sense サービスが存在しないことを確認いただくことで、オフボードとアンインストールが正常に完了していると判断することができます。

なお、オフボード操作を行う場合も、下記と同じ手順でグループポリシーを使用することで、 Install.ps1 を使用したオフボード操作を複数のサーバに展開することができます。

参考情報：グループ ポリシーを使用して Microsoft Defender for Endpoint のインストールパッケージとオンボード パッケージを適用する

MDE のオンボードに失敗する場合のトラブルシューティング

サーバを MDE にオンボードした後に以下のような問題が発生する場合、対象のサーバが MDE の利用のための要件を満たしていない可能性が考えられます。

• サーバのオンボード後、最大で 24 時間以上経過しても Microsoft 365 Defender ポータルにサーバが登録されない

• Microsoft 365 Defender ポータルのデバイスインベントリにサーバが登録されたが、[センサーの正常性状態] 列のステータスが [アクティブ] にならない

• サーバで検知テストを行ったが、 Microsoft 365 Defender ポータルにアラートが出力されない

• ライブ応答機能 や デバイス分離機能 が有効に動作しない

一般的に、これらの問題の多くは、MDE にオンボードしたサーバが通信要件を満たしていない場合に発生します。

そのため、サーバを MDE にオンボードした後に上記のような問題が発生する場合は、以下の手順にてサーバが MDE の動作に必要な通信要件を満たしているかどうかを確認してください。

サーバで通信テストを行う

下記公開情報に記載の手順にてサーバで MDEClientAnalyzer ツールを実行することで、サーバが MDE の通信要件を満たすかどうかテストすることが可能です。

参考情報：Windows でクライアント アナライザーを実行する | Microsoft Learn

注意：

MDEClientAnalyzer ツールをローカルサーバで使用する場合には、 SysInternals に含まれる PsExec.exe ツールを実行できることが 前提要件 に含まれます。

サーバで PsExec.exe ツールを制限している場合には、一時的に実行を許可した上で MDEClientAnalyzer ツールを使用してください。

テスト結果は以下のようなレポート(MDEClientAnalyzer.htm)として出力され、 MDEClientAnalyzer ツールの実行後に既定のブラウザで自動的に表示されます。

レポートから通信テストの結果を確認する

レポート(MDEClientAnalyzer.htm) から通信テストの結果を確認する場合は、レポートの [Detailed Results] 欄の情報を確認します。

サーバが MDE の通信要件を満たしている場合、以下の例のように通信テストの結果がすべて [Informational] として表示されます。

一方で、MDEClientAnalyzer ツールによる通信テストに失敗した項目が存在する場合には、以下のように通信テストの結果が [Error] として表示されます。

通信テストの結果に [Error] と表示される項目が存在する場合、[Results] 列にはテストに失敗した通信先の URL が表示されます。

レポート内に [Error] の項目が存在する場合、MDE の動作に問題が発生する可能性があるため、[Results] 列に表示される情報と Windows Server を MDE にオンボードする前の確認ポイント の記載を今一度ご確認の上、すべての動作要件を満たすように構成変更を実施します。

通信にプロキシサーバを利用する場合の確認ポイント

インターネット通信にプロキシサーバが必要な構成のサーバで通信テストに失敗する場合、レポート(MDEClientAnalyzer.htm) の [Sense service discovered proxy] に適切なプロキシサーバのアドレスとポート番号が指定されているか確認します。

MDE の稼働に必要な通信要件とプロキシ設定については 端末のネットワーク接続を確認する の項を参照します。

※ 上記は WinHTTP プロキシを構成している場合の出力結果の例です。

プロキシサーバが適切に設定されているにも関わらず通信テストに失敗する場合には、設定されているプロキシサーバ側で必要な通信が許可されていることを確認します。

まとめ

本記事では Windows Server 2012 R2 と Windows Server 2016 を Microsoft Defender for Endpoint(MDE) にオンボード / オフボードする方法についておまとめいたしました。

※ 本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合がありますことご了承ください。

こんにちは。Azure Security サポートチームです。

Windows Server 2012 R2 のサポート ライフサイクルの終了日 (2023年10月10日) が迫っています。
今回はオンプレミス環境で運用している AD RMS の役割をホストしているサーバーについて、リフト&シフト形式でのパブリック クラウド移行 (Azure/AWS/GCP 等) がライセンス上許諾されない点について注意喚起させていただきます。

EOS やサポート終了に伴い、ワークロードのクラウド移行を検討しているお客様もいらっしゃるかと存じますが、Windows Server 上で実行される AD RMS の役割についてはパブリック クラウドでの運用をライセンス面で許諾していません。

また、Azure 仮想マシン環境では機能的にも AD RMS の役割をサポートしてません。

Windows Server の AD RMS の役割についてアクティブな機能開発は終了しておりますので、アップグレードやクラウド サービスへの移行を検討いただく場合には、SaaS ソリューションである Microsoft Purview Information Protection (旧：Azure Information Protection) への移行を検討いただきたく存じます。

<参考>

Title : Azure 仮想マシンに対する Microsoft サーバー ソフトウェアのサポート

URL : https://learn.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/server-software-support

～～～～～以下抜粋～～～～～

Microsoft Azure Virtual Machinesでは、次のロールはサポートされていません。

・動的ホスト構成プロトコル サーバー (Azure VNet に直接接続されている NIC での使用はサポートされていませんが、入れ子になった仮想化シナリオで使用される内部ネットワークでサポートされます)

・Hyper-V (Hyper-V ロールは Azure Ev3 および Dv3 シリーズ VM でのみサポートされています)

・Rights Management サービス

・Windows 展開サービス

～～～～～抜粋終了～～～～～

Titel : 秘密度ラベルの詳細

URL : https://learn.microsoft.com/ja-jp/purview/sensitivity-labels

Title : AD RMS から Azure Information Protection への移行

URL : https://learn.microsoft.com/ja-jp/azure/information-protection/migrate-from-ad-rms-to-azure-rms

パブリック クラウド上での Windows Server のライセンスについて

Windows Server のライセンスはサーバー本体に割り当てるライセンスと、アクセスするクライアント側に割り当てる “Client Access License (CAL)” があります。

また、CAL には基本機能を利用するために必ず割り当てる必要のある “ベース CAL” と、リモート デスクトップ サービスや AD RMS など、Windows Server の特定の追加機能を使用するために必要な “追加 CAL” があります。
例えば、オンプレミス環境で Windows Server の AD RMS の役割を運用する場合には、クライアント側にベース CAL と AD RMS 追加 CAL の 2 種類の CAL が必要になります。

<参考>

Title : Windows Server について

URL : https://www.microsoft.com/ja-jp/licensing/product-licensing/windows-server

～～～～～以下抜粋～～～～～

コア単位の Windows Server ライセンスに CAL は必要ですか。

Windows Server Standard エディションおよび Datacenter エディションでは、引き続き、サーバーにアクセスするすべてのユーザーまたはデバイスに対して Windows Server CAL が必要です (例外については、製品条項を参照)。外部ユーザーがアクセスするサーバーに対しては、Windows Server エクスターナル コネクタ ライセンスが引き続き必要です。Windows Server のベース CAL やエクスターナル コネクタ ライセンス以外にも、一部の機能には追加のアクセス ライセンスの購入が必要になります。たとえば、リモート デスクトップ サービスや Active Directory Rights Management サービスなどの追加機能や高度な機能についてはライセンスを購入する必要があります。

～～～～～抜粋終了～～～～～

一方でパブリック クラウド上で Windows Server を運用する場合のライセンス モデルはオンプレミスでのライセンス モデルと少々異なります。パブリック クラウド環境での Windows Server のライセンス モデルでは “ベース CAL” はホスティング サービス側で使用料に含まれる形で提供されます。

例えば Azure 仮想マシンで実行する Windows Server ではベース CAL のライセンスが含まれた形式で提供されており、お客様側での CAL の準備は不要です。しかしながら、IaaS の Windows Server の利用料金に含まれているのは “ベース CAL” だけであり、リモート デスクトップ サービスや AD RMS など高度な機能を利用する場合には、サービスに対応している “追加 CAL” が必要になります。

そこでパブリック クラウドへの追加 CAL の持ち込み可否 (ライセンス モビリティ特典) なのですが、拡張権限として許諾されているのはソフトウェア アシュアランス (SA) 付きのリモート デスクトップ サービス CAL のみであり、AD RMS 追加 CAL にはパブリック クラウドへの持ち込みを許諾する特典がありません。

<参考>

Title : Virtual Machines のライセンス FAQ

URL : https://azure.microsoft.com/ja-jp/pricing/licensing-faq/

～～～～～以下抜粋～～～～～

-Azure Virtual Machines で実行している Windows Server イメージに接続するのに、Windows Server クライアント アクセス ライセンス (CAL) は必要ですか。

いいえ。Azure 環境で実行している Windows Server にアクセスするためのアクセス権は Virtual Machines の分単位の料金に含まれているため、Windows Server SALs は必要ありません。(VHD かどうかに関係なく) オンプレミスで Windows Server を使用する場合は、別途ライセンスを取得する必要があり、ソフトウェアをオンプレミスで使用するための標準ライセンス要件に従うものとします。

-ボリューム ライセンス契約の一部として所有している リモート デスクトップ サービス CAL を使用して、Azure または他のサービス プロバイダー環境で実行している Windows Server のインスタンスにアクセスできますか。

2014 年 1 月 1 日より、リモート デスクトップ サービス ユーザー CAL でソフトウェア アシュアランスをアクティブにしているボリューム ライセンスをご利用のお客様は、リモート デスクトップ サービス CAL 拡張権限を利用できます。

これにより、Azure またはその他のサービス プロバイダーの共有サーバー環境で実行されている Windows Server に対して、ソフトウェア アシュアランス付きのリモート デスクトップ サービス ユーザー CAL を使用できます。

このリモート デスクトップ サービス ユーザー CAL ソフトウェア アシュアランスの特典により、それぞれのオンプレミス サーバーへのアクセスに加え、各ユーザーが 1 つの共有サーバー環境 (つまり Azure またはサード パーティのサーバー) でのみリモート デスクトップ サービス機能にアクセスできるようになります。

この特典を役立てるには、ライセンス モビリティ確認フォームを作成し、ホストされる GUI が実行される Azure または認定モビリティ パートナーに提出してください。詳細については、製品使用権の付録 2 の「Software Assurance Benefits (ソフトウェア アシュアランスの特典)」を参照してください。

～～～～～抜粋終了～～～～～

上記の通り、AD RMS 追加 CAL については、パブリック クラウドへのライセンス モビリティ特典を持たないことからパブリック クラウドへの移行が許諾されていません。つきましては運用環境で AD RMS のリプレースが必要な場合には、オンプレミス環境への移行または SaaS ソリューションである Microsoft Purview Information Protection サービスへの移行を検討いただけましたらと存じます。

今回のお知らせは以上になります。

※本ブログ記事化にあたり、弊社サポートによる調査にご協力いただきましたお客様に深く感謝いたします。
※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。