Essential Eight アプリケーション 制御

この記事では、Microsoft アプリ ロッカーと Windows Defender アプリケーション コントロールを使用して、オーストラリアのサイバー セキュリティ センター (ACSC) Essential Eight Maturity Model for Application Control を実現するための方法について詳しくは説明します。

ACSC Essential8 アプリケーション制御ガイドラインを追求する理由

アプリケーション制御は、システム上で実行される悪意のあるコードから保護するように設計されたセキュリティ アプローチです。 このセキュリティ アプローチを実装すると、実行可能ファイル、ソフトウェア ライブラリ、スクリプト、インストーラー、ドライバーなどの承認済みコードのみが実行を許可されます。 その有効性により、アプリケーション制御は ACSC の サイバー セキュリティ インシデント軽減戦略の Essential Eight の 1 つです。

アプリケーション制御

アプリケーション制御は、システム上で実行される悪意のあるコードから保護するように設計されたセキュリティ アプローチです。 このセキュリティ アプローチを実装すると、実行可能ファイル、ソフトウェア ライブラリ、スクリプト、インストーラー、ドライバーなどの承認済みコードのみが実行を許可されます。

アプリケーション制御は主に、システムでの悪意のあるコードの実行と拡散を防ぐために設計されていますが、承認されていないアプリケーションのインストールと使用を防ぐこともできます。

組織の成熟度レベルの要件の達成

• 成熟度レベル 1 (ML1): Microsoft AppLocker を使用して実現できます
• 成熟度レベル 2 と 3 (ML2 & ML3): Microsoft Windows Defender アプリケーション コントロールを使用して実現できます

アプリケーション制御の実装

アプリケーション制御の実装には、organizationに関する次の大まかな手順が含まれます。

• 承認済みアプリケーションの識別
• 承認されたアプリケーションのみを実行できるようにアプリケーション制御ルールを開発する
• 変更管理プロセスを使用したアプリケーション制御規則の保守
• アプリケーション制御規則を頻繁に検証する

organization内でアプリケーション承認を適用する方法を決定する場合、オーストラリアサイバーセキュリティセンターは、正しく実装された場合に次の方法が適切であると考えられます。

• 暗号化ハッシュ規則
• 発行元の認定規則
• パス ルール (フォルダーとファイルのアクセス許可、フォルダーの内容、および個々のファイルの未承認の変更を防ぐためにファイル システムのアクセス許可が構成されている場合)

アプリケーション制御は、承認されていないアプリケーションの未承認の実行を防ぐことができます。 アプリケーション制御は、脅威アクターがシステム上で悪意のあるコードを実行しようとする試みの識別にも役立つ可能性があります。 承認された実行と未承認の実行のイベント ログを生成するように WDAC を構成すると、organizationのセキュリティ オペレーション センターに貴重な情報を提供できます。

アプリケーション制御ソリューションは、ウイルス対策やその他のセキュリティ ソフトウェア ソリューションに置き換えられません。 WDAC は常に、Defender ウイルス対策などのウイルス対策ソリューションと連携して動作します。 Microsoft セキュリティ ソリューションを組み合わせて使用すると、システムの侵害を防ぐための効果的な多層防御アプローチに貢献します。

アプリケーション制御の成熟度レベル (ML)

オーストラリアサイバーセキュリティセンターには、Essential8を構成する軽減戦略の成熟度レベルが3つ用意されています。 成熟度レベルは、脅威アクターによって使用される貿易技術のレベルの増加を軽減することに基づいています。 アプリケーション制御のコンテキスト内で、オーストラリアのサイバー セキュリティ センターは、ML 1、2、3 を満たすために必要なものを決定します。

ISM Sep 2024 control	成熟度レベル	軽減策
ISM-0109	3	ワークステーションからのイベント ログは、サイバー セキュリティ イベントを検出するためにタイムリーに分析されます。
ISM-0140	2、3	サイバー セキュリティ インシデントは、発生または検出された後、できるだけ早く ASD に報告されます。
ISM-0123	2、3	サイバー セキュリティ インシデントは、発生または検出された後、できるだけ早く最高情報セキュリティ責任者またはその代理人に報告されます。
ISM-0843	1, 2, 3	アプリケーション制御はワークステーションに実装されます。
ISM-1490	2、3	アプリケーション制御は、インターネットに接続するサーバーに実装されます。
ISM-1656	3	アプリケーション制御は、インターネットに接続されていないサーバーに実装されます。
ISM-1544	2、3	Microsoft の推奨されるアプリケーション ブロックリストが実装されています。
ISM-1657	1, 2, 3	アプリケーション制御では、実行可能ファイル、ソフトウェア ライブラリ、スクリプト、インストーラー、コンパイル済み HTML、HTML アプリケーション、コントロール パネル アプレットの実行を、organization承認済みのセットに制限します。
ISM-1658	3	アプリケーション制御は、ドライバーの実行をorganization承認済みセットに制限します。
ISM-1582	2、3	アプリケーションコントロールルールセットは、毎年またはより頻繁に検証されます。
ISM-1659	3	Microsoft の脆弱なドライバー ブロックリストが実装されています。
ISM-1660	2、3	許可およびブロックされたアプリケーション制御イベントは、一元的にログに記録されます。
ISM-1815	2、3	イベント ログは、未承認の変更と削除から保護されます。
ISM-1819	2、3	サイバー セキュリティ インシデントの特定に続いて、サイバー セキュリティ インシデント対応計画が制定されます。
ISM-1870	1, 2, 3	アプリケーション制御は、オペレーティング システム、Web ブラウザー、電子メール クライアントで使用されるユーザー プロファイルと一時フォルダーに適用されます。
ISM-1871	2、3	アプリケーション制御は、オペレーティング システム、Web ブラウザー、電子メール クライアントで使用されるユーザー プロファイルと一時フォルダー以外のすべての場所に適用されます。
ISM-1228	2、3	サイバー セキュリティ イベントは、サイバー セキュリティ インシデントを特定するためにタイムリーに分析されます。
ISM-1906	2、3	インターネットに接続するサーバーからのイベント ログは、サイバー セキュリティ イベントを検出するためにタイムリーに分析されます。
ISM-1907	3	インターネットに接続していないサーバーからのイベント ログは、サイバー セキュリティ イベントを検出するためにタイムリーに分析されます。

ISM Sep 2024 control	成熟度レベル	Control	Measure
ISM-0109	3	ワークステーションからのイベント ログは、サイバー セキュリティ イベントを検出するためにタイムリーに分析されます。	Defender for Endpoint P2 を使用します。 Windows イベント ログは、AMA または Windows 転送イベント ソリューションを介してWindows セキュリティ イベントを使用して、Microsoft SentinelとMicrosoft Defender XDR内でキャプチャされます。
ISM-0140	2、3	サイバー セキュリティ インシデントは、発生または検出された後、できるだけ早く ASD に報告されます。	このドキュメントの範囲外です。 この表の後にメモを参照してください。 3
ISM-0123	2、3	サイバー セキュリティ インシデントは、発生または検出された後、できるだけ早く最高情報セキュリティ責任者またはその代理人に報告されます。	このドキュメントの範囲外です。 この表の後にメモを参照してください。 3
ISM-0843	1, 2, 3	アプリケーション制御はワークステーションに実装されます。	organizationの成熟度レベルの要件に応じて、Windows Defender アプリケーション制御/AppLocker を構成して使用します。
ISM-1490	2、3	アプリケーション制御は、インターネットに接続するサーバーに実装されます。	Windows Defender アプリケーション コントロールを構成して使用する
ISM-1656	3	アプリケーション制御は、インターネットに接続されていないサーバーに実装されます。	Windows Defender アプリケーション コントロールを構成して使用する
ISM-1544	2、3	Microsoft の推奨されるアプリケーション ブロックリストが実装されています。	Microsoft の "推奨されるブロック 規則" が実装されています
ISM-1657	1, 2, 3	アプリケーション制御では、実行可能ファイル、ソフトウェア ライブラリ、スクリプト、インストーラー、コンパイル済み HTML、HTML アプリケーション、コントロール パネル アプレットの実行を、organization承認済みのセットに制限します。	Microsoft では、ファイル発行元ルールまたはファイル ハッシュの定義済みの一覧をアプリケーション制御ポリシー内に作成することをお勧めします。 1
ISM-1658	3	アプリケーション制御は、ドライバーの実行をorganization承認済みセットに制限します。	ハイパーバイザーで保護されたコードの整合性が有効になっており、Windows 11 2022 以降の既定です
ISM-1582	2、3	アプリケーションコントロールルールセットは、毎年またはより頻繁に検証されます。	このドキュメントの範囲外です。 この表の下の注を参照してください。 3
ISM-1659	3	Microsoft の脆弱なドライバー ブロックリストが実装されています。	Microsoft の "推奨されるドライバー ブロック規則" が実装されています
ISM-1660	2、3	許可およびブロックされたアプリケーション制御イベントは、一元的にログに記録されます。	Defender for Endpoint P2 を使用します。 Windows イベント ログは、AMA または "Windows 転送イベント" ソリューションを介して "Windows セキュリティ イベント" を使用して、Microsoft SentinelとMicrosoft Defender XDR内でキャプチャされます。
ISM-1815	2、3	イベント ログは、未承認の変更と削除から保護されます。	Microsoft Defender XDRとMicrosoft Sentinelの Role-Based Access Control が適用されます。
ISM-1819	2、3	サイバー セキュリティ インシデントの特定に続いて、サイバー セキュリティ インシデント対応計画が制定されます。	このドキュメントの範囲外です。  この表の下の注を参照してください。 3
ISM-1870	1, 2, 3	アプリケーション制御は、オペレーティング システム、Web ブラウザー、電子メール クライアントで使用されるユーザー プロファイルと一時フォルダーに適用されます。	Microsoft では、ファイル発行元ルールまたはファイル ハッシュの定義済みの一覧をアプリケーション制御ポリシー内に作成することをお勧めします。 成熟度レベル 1 は、Microsoft AppLocker で実現できます。 成熟度レベル 2 と 3 には、Windows Defender アプリケーション制御が必要です。 2
ISM-1871	2、3	アプリケーション制御は、オペレーティング システム、Web ブラウザー、電子メール クライアントで使用されるユーザー プロファイルと一時フォルダー以外のすべての場所に適用されます。	Windows Defender アプリケーション コントロールの実装と構成
ISM-1228	2、3	サイバー セキュリティ イベントは、サイバー セキュリティ インシデントを特定するためにタイムリーに分析されます。	このドキュメントの範囲外です。  この表の後にメモを参照してください。 3
ISM-1906	2、3	インターネットに接続するサーバーからのイベント ログは、サイバー セキュリティ イベントを検出するためにタイムリーに分析されます。	Defender for Endpoint P2 を使用します。 Windows イベント ログは、AMA または Windows 転送イベント ソリューションを介してWindows セキュリティ イベントを使用して、Microsoft SentinelとMicrosoft Defender XDR内でキャプチャされます。
ISM-1907	3	インターネットに接続していないサーバーからのイベント ログは、サイバー セキュリティ イベントを検出するためにタイムリーに分析されます。	Defender for Endpoint P2 を使用します。 Windows イベント ログは、AMA または Windows 転送イベント ソリューションを介してWindows セキュリティ イベントを使用して、Microsoft SentinelとMicrosoft Defender XDR内でキャプチャされます。

重要

¹ ISM-1657 を満たすために、Microsoft では、アプリケーション制御ポリシー内にファイル発行元規則またはファイル ハッシュの定義済みの一覧が作成されていることをお勧めします。 ファイル パス規則を利用しすぎる場合、organizationは、ユーザーがフォルダーとファイルのアクセス許可、フォルダーの内容、および個々のファイルの不正な変更を防ぐことを確認する必要があります。 たとえば、ユーザーは NTFS 内のファイル パス 規則の場所への書き込みアクセス権を持つべきではありません。

² ISM-1870 を満たすために、Microsoft では、アプリケーション制御ポリシー内にファイル発行元規則またはファイル ハッシュの定義済みの一覧が作成されていることをお勧めします。 成熟度レベル 1 は、Microsoft AppLocker で実現できます。 成熟度レベル 2 と 3 には、追加の ISM 要件があるため、Windows Defender アプリケーション制御の要件があります。 ISM-1870 では、ユーザーのプロファイルと一時フォルダー内にファイル システム権限があるため、ファイル パス規則は推奨されません。

³ コントロール ISM-0140、0123、1582、1819、1228 は、明示的に主要なユーザーとプロセス コントロールです。 Microsoft では、Essential 8 コンプライアンス レビューの自動化されたテクノロジ証拠の一部として、ユーザーとプロセスを文書化し、 Purview コンプライアンス マネージャーのアーティファクトとして保存することをお勧めします。

Windows のアプリケーション制御

使用するソリューションはどれですか?

Microsoft では、AppLocker ではなく Windows Defender アプリケーションコントロール (WDAC) を実装することをお勧めします。 Windows Defender アプリケーションコントロールは継続的に改善されています。 AppLocker は引き続きセキュリティ修正プログラムを受け取りますが、機能の改善は受け取りません。

ただし、一部のユーザーが特定のアプリケーションを実行できないようにすることが重要な共有デバイスなどのシナリオでは、AppLocker を Windows Defender アプリケーション制御の補完として展開することもできます。 Microsoft では、organizationでは、organizationで可能な限り最も制限の厳しいレベルとして Windows Defender アプリケーション制御を適用し、必要に応じて AppLocker を使用してユーザー モードの制限をさらに微調整することをお勧めします。

ヒント

WDAC をお勧めしますが、ほとんどの組織では、出発点として AppLocker だけを使用して ML1 を実現する方が簡単で簡単ですが、どちらのソリューションも無料です。

AppLocker

AppLocker は Windows 7 で導入され、organizationは、Windows オペレーティング システムで実行できるユーザー モード (アプリケーション) プロセスを制御できます。 AppLocker ポリシーは、システム上のすべてのユーザー、または次に基づいて定義できるルールを持つ個々のユーザーとグループに適用できます。

• 暗号化ハッシュ規則
• 発行元の認定規則
• パス ルール

AppLocker ポリシーは、サポートされている任意のバージョンと Windows オペレーティング システムの追加で作成でき、グループ ポリシー、PowerShell、または Mobile デバイス管理 ソリューションを使用して展開できます。

Windows Defender Application Control

Windows Defender アプリケーションコントロール (WDAC) は、Windows 10で導入されました。 これにより、組織は、Windows オペレーティング システムで実行できるユーザー モード (アプリケーション) プロセスとカーネル モード (ドライバー) プロセスを制御できます。 WDAC ポリシーはマネージド システム全体に適用され、次に基づいて定義できる規則を持つデバイスのすべてのユーザーに影響します。

• 暗号化ハッシュ規則
• 発行元の認定規則
• パス規則
• Microsoft のインテリジェント セキュリティ グラフによって決定されるアプリケーションの評判
• マネージド インストーラーによるアプリケーションのインストールを開始したプロセスの ID

WDAC ポリシーは、サポートされている任意のクライアント エディションのWindows 10、Windows 11、または Windows Server 2016 以上で作成できます。 WDAC ポリシーは、グループ ポリシー、モバイル デバイス管理 ソリューション、Configuration Manager、または PowerShell を使用して展開できます。

Microsoft のサービスとしての Windows では、新しい機能の開発と展開をお客様に許可するため、WDAC の一部の機能は特定の Windows バージョンでのみ使用できます。

Windows Defender アプリケーション制御と Applocker の詳細については、「 Windows Defender アプリケーション制御と AppLocker 機能の可用性」を参照してください。

Ml1 用 AppLocker を使用した Essential8 アプリケーション制御

AppLocker を使用して ML1 を実現する

管理者がユーザー ベースのアプリケーション制御用の AppLocker ポリシーを展開する場合、パスベースの実装のサンプルとして次の規則を使用できます。 これには、ルール、規則の適用、アプリケーション ID サービスの自動開始が含まれます。

推奨される方法は、次のパスを (最小限で) ブロックすることです。

• C:\Windows\Temp\*.*
• %USERPROFILE%\AppData\Local\*.*
  • %USERPROFILE%\AppData\Local\Microsoft\WindowsApps の例外を追加する
• %USERPROFILE%\AppData\Roaming\*.*

ML1 での AppLocker の詳細については、次の記事を参照してください。

• ACSC - アプリケーション制御の実装
• AppLocker の概要

ML1 を実現するための AppLocker ポリシーの作成

Microsoft AppLocker ポリシーは、いくつかの方法を使用して作成できます。 Microsoft では、AppLocker ポリシーの作成を支援するために、Microsoft オープン ソース プロジェクト AaronLocker を使用することをお勧めします。 AaronLocker を使用すると、PowerShell スクリプトのサービスを使用して、AppLocker の堅牢で厳格なアプリケーション制御を可能な限り簡単かつ実用的に作成およびメンテナンスできます。 AaronLocker は、管理者以外のユーザーによるプログラムとスクリプトの実行を制限するように設計されています。

Aaronlocker の詳細については、「 AaronLocker: Windows の堅牢で実用的なアプリケーション制御」を参照してください。

ML1 を実現するための AppLocker ポリシーの展開

Microsoft AppLocker は、Microsoft Intune、グループ ポリシー、または PowerShell を使用して展開できます。 デプロイ方法は、organizationの現在の管理ソリューションに依存します。

アプリ ロッカーの展開の詳細については、次の記事を参照してください。

• AppLocker 展開ガイド
• AppLocker CSP

AppLocker ポリシー イベントの監視

Microsoft AppLocker 関連のイベントは、Microsoft のSentinelなどのセキュリティ情報とイベント管理ソリューションによって監視されます。 イベントは、Microsoft Defender for Endpointの高度なハンティング情報を使用して監視することもできます。

Microsoft Defender for Endpoint: AppLocker リファレンス

Microsoft Defender for Endpointは、Microsoft AppLocker に関連して次のイベントをキャプチャします。

ActionType 名	イベント ソース ID
AppControlExecutableAudited	8003
AppControlExecutableBlocked	8004
AppControlPackagedAppAudited	8021
AppControlPackagedAppBlocked	8022
AppControlPackagedAppBlocked	8006
AppControlScriptBlocked	8007
AppControlCIScriptAudited	8001

イベント ビューアーと高度なハンティングの詳細については、次の記事を参照してください。

• AppLocker でのイベント ビューアーの使用
• 高度なハンティングを使用してアプリケーション制御イベントを一元的に照会する

ML2 用 WDAC を使用した Essential8 アプリケーション制御

Microsoft では、WDAC を使用した Essential Eight アプリケーション制御 ML2 と ML3 を満たすために、設計プロセス、ライフサイクル管理、デプロイ、運用ガイダンスについて説明しています。

Essential Eight Application Control ML1 の要件をお持ちのお客様は、Microsoft AppLocker を使用して実現できます。

このガイダンスを使用するための前提条件は次のとおりです。

• Windows 11 22H2 Enterprise
• 管理ソリューションにIntuneを使用する
• Defender for Endpoint (エンドポイント セキュリティ ソリューション用)
• セキュリティ情報とイベント管理のMicrosoft Sentinel。
• このドキュメントで使用されるソリューション全体の管理者による適切なアクセス許可

Windows Server オペレーティング システム上の WDAC は、このガイドの範囲外です。 Windows Server のガイダンスは、今後のリリースで提供される予定です。

ライセンスの要件

M365 関連のサービスは、必要なサービス、価値提案、ライセンス要件を理解するために、Microsoft 365 および Office 365 サービスの説明内に配置できます。

Microsoft 365 および Office 365 サービスの説明

WDAC に関連付けられている製品の詳細については、次の記事を参照してください。

• Windows 向けアプリケーション制御
• Microsoft Intune
• Microsoft Azure Sentinel

WDAC の概要

ポリシーの設計

organizationが WDAC の計画を開始すると、設計上の決定事項を考慮すると、ポリシーの展開とアプリケーション制御ポリシーのメンテナンスにどのように影響するかが決まります。

次のことが当てはまる場合は、WDAC をorganizationのアプリケーション制御ポリシーの一部として使用する必要があります。

• サポートされているバージョンの Windows をorganizationに展開または展開する予定がある
• organizationのアプリケーションへのアクセスとユーザーのアクセスデータに対する制御を強化する必要があります
• organizationには、アプリケーションの管理とデプロイのための適切に定義されたプロセスがあります
• organizationの要件に対してポリシーをテストするためのリソースがある
• ヘルプ デスクに関連するリソースや、エンド ユーザー アプリケーション アクセスの問題に関するセルフヘルプ プロセスを構築するためのリソースがあります
• 生産性、管理容易性、およびセキュリティに関するグループの要件は、制限の厳しいポリシーによって制御できます

WDAC には、"信頼の輪" という概念が組み込まれています。 各organizationには、ビジネス要件に固有の "信頼の輪" の定義が異なります。 ACSC Essential 8 関連の定義は ISM コントロール 1657 です。"アプリケーション制御では、実行可能ファイル、ソフトウェア ライブラリ、スクリプト、インストーラー、コンパイル済み HTML、HTML アプリケーション、コントロール パネル アプレットの実行がorganization承認済みセットに制限されます。

Microsoft では、%OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies の下にある XML 形式内のいくつかのポリシー例を提供しています。 Microsoft のポリシー例では、organizationを既存の基本ポリシーから開始し、必要に応じてルールを追加または削除してカスタム ポリシーを構築できます。

ポリシー設計の詳細については、次の記事を参照してください。

• Microsoft Intune ドキュメント
• Windows Defender アプリケーションコントロールの基本ポリシーの例

ポリシーの形式

WDAC では、次の 2 つのポリシー形式がサポートされています。

• 単一ポリシー形式: RTM とWindows Server 2016 Windows 10使用してリリースされた元のポリシー形式。 単一ポリシー形式では、特定の時点でシステム上の 1 つのアクティブ なポリシーのみがサポートされます

• 複数のポリシー形式 (推奨): このポリシー形式は、Windows 10 1903 以降、Windows 11、および Windows Server 2022 でサポートされています。 複数のポリシー形式を使用すると、Windows Defender アプリケーションコントロールを展開するための柔軟性が向上し、デバイスで最大 32 個のアクティブなポリシーがサポートされます。 さらに、次のシナリオが可能になります。

  • 強制と監査を並べて行う: 適用を展開する前にポリシーの変更を検証します。 ユーザーは、既存の強制モード ベースのポリシーと並べて監査モードの基本ポリシーを展開できます
  • 複数の基本ポリシー: ユーザーは 2 つ以上の基本ポリシーを同時に適用できます
  • 補足ポリシー: ユーザーは 1 つ以上の補足ポリシーを展開して、基本ポリシーを展開できます。 人事や IT など、organization内のさまざまなペルソナに対して補足ポリシーを使用できます

Microsoft では、複数のポリシー形式を使用し、明確に定義されたシナリオや、Windows Server 2016や Windows Server 2019 などの複数のポリシー形式を使用できない場合にのみ、単一のポリシー形式を使用することをお勧めします。

WDAC 制御ポリシーの詳細については、「 複数の Windows Defender アプリケーション制御ポリシーを使用する」を参照してください。

ポリシールールとファイルルール

WDAC には、次の 2 つの概念が含まれています。

• WDAC ポリシー 規則: WDAC ポリシー 規則では、監査モード、マネージド インストーラー、スクリプトの適用、補足ポリシー (複数のポリシー形式)、Reputation-Based インテリジェンス (ISG Authorization/Smart App Control) などの構成を指定します。 また、ポリシー 規則は、カーネル モードバイナリとユーザー モード バイナリの両方に対して WDAC を決定します
• WDAC ファイルルール: WDAC ファイルルールは、Windows で実行するための承認と再認証を指定します。 ファイル ルールでは、Hash、File Name、File Path、Publisher の各ルールをサポートしており、お客様は、許可されるアプリケーションのorganization承認済みのセットを定義できます。 ルールは、最初に検出されたすべての明示的な拒否ルールを処理し、その後、すべての明示的な許可ルールを処理します。 拒否または許可ルールが存在しない場合、WDAC はマネージド インストーラーを確認します。 最後に、これらのセットが存在しない場合、WDAC は Reputation-Based インテリジェンスにフォールバックします

ポリシールールとファイルルールの詳細については、次の記事を参照してください。

• Windows Defender アプリケーション制御 (WDAC) ポリシー規則とファイル規則について

ポリシーの作成

PowerShell または WDAC ウィザードを使用して WDAC ポリシーを作成するには、主に 2 つの方法があります。

• PowerShell: WDAC ポリシーは、PowerShell で構成可能なコード整合性コマンドレットを使用して作成されます。 PowerShell を使用すると、IT 担当者は、ポリシー XML を生成する WDAC ポリシー システム スキャンを自動化できます。 PowerShell を使用すると、ポリシー XML のマージ、ポリシー ルールの設定、必要に応じて別のポリシー ファイル ルールの追加を行うことができます。構成可能なコード整合性コマンドレットを使用して、organizationの要件を満たすように WDAC のポリシーの例を変更することもできます。
• Windows Defender アプリケーション制御ウィザード (推奨): WDAC ポリシー ウィザードは、C# で記述され、MSIX パッケージとしてバンドルされたオープンソースの Windows デスクトップ アプリケーションです。 セキュリティ アーキテクトにセキュリティを提供し、システム管理者がアプリケーション制御ポリシーを作成、編集、マージするためのより使いやすい手段を提供するために構築されました。 このツールはバックエンドで Config CI PowerShell コマンドレットを使用するため、ツールと PowerShell コマンドレットの出力ポリシーは同じです

ポリシーの作成の詳細については、次の記事を参照してください。

• 参照コンピューターを使用して WDAC ポリシーを作成する
• Windows Defender アプリケーション制御ウィザード
• ConfigCI
• WDAC ポリシー ウィザード

Microsoft では、Essential Eight for Application Control を実装するための Windows Defender アプリケーション制御ウィザードの使用をお勧めします。 または、サンプル ポリシーをベースとして使用するか、参照システムから適切に定義されたシナリオのポリシーを作成したい場合に、DevOps 運用モデルの高度な要件を持つ組織で PowerShell を使用することもできます。

ポリシーのライフサイクル

organizationがアプリケーション制御ソリューションの実装を開始する前に、ポリシーの管理方法と管理方法を時間の経過と同時に考慮する必要があります。 ほとんどの WDAC ポリシーは時間の経過と共に進化し、有効期間中に一連の識別可能なフェーズを継続します。 これらのフェーズは次のとおりです。

1. ポリシーを定義し、ポリシー XML の監査モード バージョンを構築します。 監査モードでは、ブロック イベントは生成されますが、ファイルの実行は禁止されません
2. 監査モード ポリシーを目的のシステムに展開する
3. 目的のシステムから監査ブロック イベントを監視し、必要に応じてルールを調整して、予期しないブロックや不要なブロックに対処します
4. 監査中に残りのブロック イベントが期待を満たすまで、これらの手順を繰り返します
5. ポリシーの適用モード バージョンを生成します。 強制モードでは、ポリシーで許可されているとおりに定義されていないファイルが実行されず、対応するブロック イベントが生成されます
6. 適用モード ポリシーを目的のシステムに展開する
7. これらのすべての手順を継続的に繰り返して、予期しないブロックアクションや不要なブロックアクションに対処します

WDAC ポリシーを効果的に管理するには、ポリシー XML ドキュメントを中央リポジトリに格納して管理する必要があります。 Microsoft では、GitHub などのソース管理ソリューションや、バージョン管理を提供する SharePoint などのドキュメント管理ソリューションをお勧めします。

• Windows Defender アプリケーション制御ライフサイクル ポリシー管理の計画

マネージド インストーラーの WDAC プレリクリメント

このセクションでは、PowerShell と Microsoft Intune を使用して WDAC マネージド インストーラーを構成する要件に関するお客様のガイダンスを提供することを目的としています。

• Windows 脅威保護を確認すると、Windows Defender アプリケーションコントロールを使用してマネージド インストーラーによって展開されたアプリが自動的に許可されます (/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer)

注:

このサンプル スクリプトでは AppLocker が使用されていないため、手順 1 では 問題のない DENY 規則 は存在しません。 AppLocker のこの構成は、マネージド インストーラーを必要とするすべてのデバイスに対して作成されます。

• 次の手順を完了する PowerShell スクリプトを作成します。
  • AppLocker XML を格納する
  • AppLocker XML をエクスポートする
  • AppLocker ポリシーを設定する
  • AppLocker サービスを開始する

次に、Intune管理拡張機能 - PowerShell スクリプトを使用してデプロイできるスクリプトの例を示します。

$ScriptDir = Split-Path $script:MyInvocation.MyCommand.Path

$AppLockerMIPolicy = 
@"
<AppLockerPolicy Version="1">
<RuleCollection Type="ManagedInstaller" EnforcementMode="Enabled">
  <FilePublisherRule Id="55932f09-04b8-44ec-8e2d-3fc736500c56" Name="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE version 1.39.200.2 or greater in MICROSOFT® INTUNE™ from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE">
          <BinaryVersionRange LowSection="1.39.200.2" HighSection="*" />
        </FilePublisherCondition>
  </Conditions>
  </FilePublisherRule>
  <FilePublisherRule Id="6ead5a35-5bac-4fe4-a0a4-be8885012f87" Name="CMM - CCMEXEC.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMEXEC.EXE">
        <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
      </FilePublisherCondition>
    </Conditions>
  </FilePublisherRule>
  <FilePublisherRule Id="8e23170d-e0b7-4711-b6d0-d208c960f30e" Name="CCM - CCMSETUP.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMSETUP.EXE">
        <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
  </RuleCollection> 
</AppLockerPolicy>
"@

$AppLockerMIPolicy | Out-File -FilePath $ScriptDir\AppLockerMIPolixy.xml
Set-AppLockerPolicy -XmlPolicy $ScriptDir\AppLockerMIPolixy.xml -Merge -ErrorAction SilentlyContinue
Start-Process -FilePath "$env:windir\System32\appidtel.exe" -ArgumentList "start -mionly" | Wait-Process
Remove-Item -Path $ScriptDir\AppLockerMIPolixy.xml

重要

管理者は、ハッシュまたはパブリッシャーを使用して、WDAC ファイル規則ポリシーに構成スクリプトを追加する必要があります。

WDAC マネージド インストーラー

概要

WDAC のマネージド インストーラーと呼ばれる機能により、アプリケーション制御ポリシーを適用するときに、セキュリティと管理性のバランスを取るためのorganizationが可能になります。 これにより、アプリケーションをMicrosoft Configuration ManagerやIntuneなどのソフトウェア配布ソリューションによってインストールできます。

一般的な誤解は、WDAC のポリシー内で "マネージド インストーラー" ルールを構成することだけです。 これは正しくありません。この機能を動作させるためには、AppLocker の別の構成が必要です。

マネージド インストーラーでは、AppLocker 内の規則コレクションを使用して、アプリケーションのインストールのためにorganizationによって信頼されるバイナリを指定します。 Windows は、構成されたバイナリのプロセスを監視し、ディスクに書き込まれる関連ファイルを監視しながら起動する子プロセスを監視します。 これらのファイルは、マネージド インストーラーから生成されたタグとしてタグ付けされているため、実行が許可されます。

マネージド インストーラーのデプロイ

GPO Edit 内での AppLocker ポリシーの作成と AppLocker PowerShell コマンドレットを直接使用して、マネージド インストーラー コレクションのルールを作成することはできません。 VS Code または別のエディター ツールを使用して、マネージド インストーラー規則コレクションを作成する必要があります。

AppLocker 構成サービス プロバイダー (CSP) は現在、マネージド インストーラー規則のコレクションの種類をサポートしていないため、AppLocker ポリシーは、Microsoft Intuneの PowerShell を使用してイングレスである必要があります。

ISM-1657 を満たすには Windows Defender アプリケーション コントロールの機能 "スクリプトの適用" が必要であるため、PowerShell、VBscript、cscript、cscript、HSMTA、MSXML を制御するには、スクリプトの適用が必要です。 "マネージド インストーラー" を構成する PowerShell スクリプトは、ハッシュまたはパブリッシャーを使用して WDAC ファイル ポリシー規則内にある必要があります。

Microsoft では、Microsoft Intuneのマネージド インストーラーの構成をお勧めします。 Intuneを使用すると、Windows Defender アプリケーション制御ポリシーを頻繁に更新する必要なく、Microsoft Intuneを使用してパッケージ化されたアプリケーションを堅牢に管理できます。

マネージド インストーラー用の PowerShell スクリプトのデプロイ

マネージド インストーラーに対するこの構成スクリプトのデプロイは、シナリオに応じて、Microsoft Intuneを使用して 2 つの方法で実現できます。

• ハッシュ: スクリプトのハッシュは、Microsoft Intune内の Microsoft Win32 コンテンツ準備ツールまたは PowerShell スクリプト機能を使用して WDAC ファイル ポリシー内で認識され、パッケージ化され、デプロイされている必要があります。
• コード署名 (パブリッシャー): PowerShell スクリプトは、信頼できる機関によって署名され、WDAC ファイル ポリシーで認識され、パッケージ化され、Microsoft Intune内の Microsoft Win32 コンテンツ準備ツールまたは PowerShell スクリプト機能を使用して展開されています。

PowerShell スクリプトのデプロイの詳細については、次の記事を参照してください。

• Windows Defender アプリケーション コントロールを使用してマネージド インストーラーによって展開されたアプリを自動的に許可する
• AppLocker CSP
• Windows Defender アプリケーション コントロール (WDAC) を使用したスクリプトの適用
• Microsoft Intune での Win32 アプリの管理
• Intune で Windows 10/11 デバイスに対して PowerShell スクリプトを使用する

WDAC 監査ポリシーの作成

監査ポリシーを作成する

オプションを理解し、決定を設計すると、organizationは Windows Defender アプリ制御ウィザードを使用して最初の監査ポリシーを作成できます。

1. Windows Defender アプリコントロール ウィザードを開き、[ポリシー作成者] を選択します。

2. [ポリシー作成者] で、[複数のポリシー形式] と [基本ポリシー] を選択し、[次へ] を選択します。

3. ポリシー テンプレート内には、次の 3 つのオプションが表示されます。

   • 既定の Windows モードには、Windows OS、ストア アプリ、Microsoft 365 Apps for Enterprise (Office 365 Pro Plus) と WHQL 署名カーネル ドライバーが含まれます。
   • [Microsoft モードを許可する ] には、既定の Windows モードとすべての Microsoft 署名済みアプリケーション内のすべてのセクションが含まれます。
   • 署名済みおよび評判モード には、以前のすべてのセクションと Reputation-Based インテリジェンスが含まれています。

重要

Reputation-Based アプリケーション制御用インテリジェンスは、要件 "組織が承認したセット" (ISM 1657) と "アプリケーション制御ルール セットは年単位または頻度の高い基準で検証される" (ISM 1582) のため、Essential8 アプリケーション制御を満たしていません。WDAC 内のこの機能は、ML2 または ML3 の要件を満たしていません。 Microsoft では、Essential8 アプリケーション コントロールのコンテキスト外で WDAC を採用する組織に対して、Reputation-Based インテリジェンスを使用することをお勧めします。

4. organizationの要件に応じて、[既定の Windows モード] または [Microsoft モードを許可する] を選択します。 このドキュメントでは、Microsoft は Microsoft モードの許可を使用しています。
5. ポリシー名と場所を目的のポリシー名とポリシー ファイルの場所に変更してファイルを保存し、[次へ] を選択します。

注:

WDAC – ポリシー規則の詳細については 、こちらを参照してください。

• スクリプト、準拠 HTML、HTML アプリケーションを制御するには、ISM 1657 および 1658 で [無効] に設定された [スクリプトの適用を無効にする] が必要です。
• ISM 1657、1658、1582 には、インテリジェント セキュリティ グラフを "無効" に設定する必要があります。
• マネージド インストーラーは、WDAC ポリシーのライフサイクルに関するorganizationを支援するために、"有効" にすることをお勧めします。
• WDAC ポリシーがカーネル モードとユーザー モード バイナリの両方に適用するには、ユーザー モード コードの整合性が必要です。
• WDAC ポリシーのライフサイクルでorganizationを支援するために、マルチポリシー形式を使用するには、補足ポリシーを許可する必要があります。

注:

その他のすべての WDAC ポリシー規則は、organization内の要件に依存します。

6. 署名規則内で、管理者は[発行元の規則を許可する] として追加されたすべての Microsoft の証明書を表示できます。 この記事の後半で「 カスタム ルールを追加 する」について説明します。
7. [次へ] を選択します。

Windows Defender アプリコントロール ウィザードでは、次の情報が生成されます。

• ポリシー XML
• {GUID}。CIP

WDAC – ポリシー規則の詳細については 、こちらを参照してください。

注:

Windows Defender アプリコントロール ウィザードを使用して生成された各ポリシーは、新しいグローバル一意識別子 (GUID) を取得します。

WDAC ポリシーが正常に作成されました。

ポリシー XML

organizationが WDAC ウィザードを使用して WDAC ポリシーを作成すると、organizationはテキスト エディター内でこのファイルのコンテキストを表示できます。 XML は、Essential Eight のコンテキストで PolicyID と BasePolicyID をメモするために、いくつかの異なるセクションに分割されます。

注:

ポリシー XML を直接編集することもできます。 Microsoft では、PowerShell の Windows Defender アプリコントロール ウィザードまたは構成可能なコード整合性コマンドレットを使用して、ポリシー 規則または署名ファイルに対するすべての追加の変更を行うことをお勧めします。

WDAC 監査ポリシーの展開

Intuneを使用して WDAC 監査ポリシーを展開する

organizationで監査ポリシーが作成されたので、Intuneデバイス管理を使用して展開します。

1. 管理センター Intuneサインインします。
2. 管理センター Intuneで、[デバイス] に移動し、[構成プロファイル] に移動します。
3. 次に、Profile>Platform - Windows 10 以降のプロファイルの種類テンプレートとカスタムを作成します。
4. ポリシーの名前 ("アプリケーション制御 - Microsoft Allow – Audit" など) を作成し、[ 次へ] を選択します。
5. [ OMA-URI 設定] で、[ 追加] を選択します。

注:

この情報は、上記のセクションの "監査ポリシーの作成" から作成されたポリシー XML の Windows >Defender アプリ制御ウィザードから生成されたポリシー ID に依存します。

- Name = Microsoft Allow Audit
- OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
- データ型 = Base64 (ファイル)

6. Windows Defender アプリコントロール ウィザードによってポリシー XML が生成されると、(GUID) も作成されます。CIP ファイル。 CIP ファイルをコピーし、ファイル拡張子の名前を に変更する必要があります。BIN (例: {CB46B243-C19C-4870-B098-A2080923755C}.bin。
7. Base64 (ファイル) の下に BIN をアップロードします。
8. [保存] を選択します。
9. プロンプトに従って 構成プロファイルを作成します。
10. 作成したポリシー (たとえば、アプリケーション制御 - Microsoft 許可 - 監査)、構成プロファイルを目的のシステムに展開します。

WDAC – ポリシーの監視を監査する

WDAC ポリシーのライフサイクルに従って、organizationは "Microsoft 監査を許可する" ポリシーから生成されたイベントを確認する必要があります。 WDAC 監査ポリシーの監視は、次の 2 つの方法で実現できます。

• アプリケーション制御イベント ID: アプリケーション制御イベント ID は、Windows オペレーティング システムで監査されたイベントを確認する従来の方法です。 これらのイベント ID は、Windows イベント ログ転送またはサード パーティのセキュリティ情報とイベント管理を使用して、一元化された場所に転送できます。

イベント ID の詳細については、「 Application Control イベント ID について - Windows セキュリティ」を参照してください。

• Microsoft Defender for Endpoint (推奨): Windows Defender for Endpoint および AppLocker 関連のイベントは、Microsoft Defender for Endpointの高度なハンティング内でキャプチャされます。 イベントに含まれる情報は、Device、FileName、FolderPath、InitiatingProcessFileName、File Hashes などです。 参照: Advanced Hunting (Windows) を使用してアプリケーション制御イベントを照会する - Windows セキュリティ

Microsoft では、Microsoft Defender XDR (MDE) 統合を使用してMicrosoft Sentinelすることをお勧めします。 MDEとSentinelを使用すると、高度なハンティング テレメトリ データを、Microsoft Defender for Endpointと比較して 30 日間以上保存できます。

接続と監視の詳細については、次の記事を参照してください。

• Microsoft Defender XDRからMicrosoft Sentinelにデータを接続する
• Windows クライアント デバイス上の Azure Monitor エージェント
• Azure Monitor エージェントを使用して仮想マシンからイベントとパフォーマンス カウンターを収集する

Microsoft Defender for Endpointを使用した WDAC の監視

次の例では、ユーザーが、organizationの毎日のタスクに使用される複数のアプリケーションを持つ例を示します。 この例には、Microsoft アプリケーションとさまざまなオープンソース アプリケーションの両方が含まれています。

この例は強制 監査モードであるため、管理者は 、WinSCP、VLC、Putty、FileZilla に対してトリガーされたイベントが、これらのアプリケーションが初期監査ポリシーの一部ではないために表示されます (ただし、ユーザーには影響しません)。

次に、Microsoft Defender ポータルを使用して、「Advanced Hunting」と入力して監査イベントを絞り込み、監査モードが無効になっている場合に発生する予期しないブロックや不要なブロックを把握し、この例で強制モードにします。

前のページの参照スキーマを使用して、過去 7 日間の WDAC によってトリガーされたすべてのポリシー監査イベントを探し、キーボード クエリ言語 (KQL) クエリの例を使用して関連情報を表示します。

DeviceEvents 
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| project DeviceId,                                  // The device ID where the audit block happened
    FileName,                                        // The audit blocked app's filename
    FolderPath,                                      // The audit blocked app's system path without the FileName
    InitiatingProcessFileName,                       // The file name of the parent process loading the executable
    InitiatingProcessVersionInfoCompanyName,         // The company name of the parent process loading the executable
    InitiatingProcessVersionInfoOriginalFileName,    // The original file name of the parent process loading the executable
    InitiatingProcessVersionInfoProductName,         // The product name of the parent process loading the executable
    InitiatingProcessSHA256,                         // The SHA256 flat hash of the parent process loading the executable
    Timestamp,                                       // The event creation timestamp
    ReportId,                                        // The report ID - randomly generated by MDE AH
    InitiatingProcessVersionInfoProductVersion,      // The product version of the parent process loading the executable
    InitiatingProcessVersionInfoFileDescription,     // The file description of the parent process loading the executable
    AdditionalFields                                 // Additional fields contains FQBN for signed binaries.  These contain the CN of the leaf certificate, product name, original filename and version of the audited binary

前の KQL クエリを使用した出力の例を次に示します。

レコード内には、プロセス ツリー、ファイル パス、SHA 情報、署名者、発行者情報などの情報の詳細なレポートがあります。

次の手順では、結果を絞り込みます。

同じ KQL クエリを使用して、開始プロセス ファイル名が Windows エクスプローラーである別のフィールドを追加します。 KQL クエリには、GUI 内のユーザーによって実行されたアプリケーションが表示されます。

 DeviceEvents 
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| where InitiatingProcessFileName startswith "explorer.exe" // Users starting an Application via File Explorer / GUI
| project DeviceId,                                  // The device ID where the audit block happened
    FileName,                                        // The audit blocked app's filename
    FolderPath,                                      // The audit blocked app's system path without the FileName
    InitiatingProcessFileName,                       // The file name of the parent process loading the executable
    InitiatingProcessVersionInfoCompanyName,         // The company name of the parent process loading the executable
    InitiatingProcessVersionInfoOriginalFileName,    // The original file name of the parent process loading the executable
    InitiatingProcessVersionInfoProductName,         // The product name of the parent process loading the executable
    InitiatingProcessSHA256,                         // The SHA256 flat hash of the parent process loading the executable
    Timestamp,                                       // The event creation timestamp
    ReportId,                                        // The report ID - randomly generated by MDE AH
    InitiatingProcessVersionInfoProductVersion,      // The product version of the parent process loading the executable
    InitiatingProcessVersionInfoFileDescription,     // The file description of the parent process loading the executable
    AdditionalFields                                 // Additional fields contains FQBN for signed binaries.  These contain the CN of the leaf certificate, product name, original filename and version of the audited binary

前の KQL クエリを使用した出力の例を次に示します。

KQL クエリ アクションにより、情報がより管理データセットに絞り込まれるようになりました。 見ることができるのは、目的のシステムで使用されているアプリケーションです。 これらのアプリケーションは、organizationのポリシーに追加するか、組織の変更制御を使用して追加する必要があります。

注:

KQL は、非構造化データセットと構造化データセットを表示するための強力なツールです。 これは KQL の使用例に過ぎ、Microsoft では次のドキュメントを確認することをお勧めします。詳細なハンティング クエリ言語については、Microsoft Defender XDR

WDAC – 監査ポリシーを更新する

Microsoft Defender for Endpointおよび WDAC ウィザードを使用して監査ポリシーを更新する

KQL を使用して検索結果を絞り込んだ後、次の手順は WDAC 基本ポリシーを更新するか、補足ポリシーを使用することです。 次の例では、補足ポリシーを使用します。

1. Windows Defender アプリ制御ウィザードを開き、[ポリシー作成者] を選択します。

2. [ポリシー作成者] で、[複数のポリシー形式] と [補足ポリシー] を選択し、基本ポリシーに移動し、場所を更新して補足ポリシーを保存し、[次へ] を選択します。

3. [ポリシー ルール] で [次へ] を選択します。

4. [ ポリシー署名規則] で、[ カスタム 規則] を選択します。

5. カスタム ルール条件内では、次のような多くのオプションを使用できます。

   • ルール スコープ ユーザー モード ルール/カーネル モード ルール
   • ルール アクション: 許可/拒否
   • 規則の種類
     • Publisher (推奨)
     • File
     • File Attribute
     • パッケージ 化されたアプリ
     • ハッシュ
   • 参照ファイル

注:

Microsoft では、必要に応じてパブリッシャー ベースのルールを使用し、署名されていない参照ファイルに対してハッシュ ベースの規則にフォールバックして、Essential8 アプリケーション コントロールを実装することをお勧めします。

Microsoft Defender for Endpointの使用

1. [検索] で [ファイル名] を 検索 し、ファイル情報に移動し、ファイルをダウンロードします。
2. Advanced Hunting からレコードを直接検査し、必要なバイナリをダウンロードするファイルをダウンロードします。
3. 必要なバイナリを使用して、次に、organizationの ISV アプリケーション用の別のポリシーを作成し続けます。
4. Windows Defender アプリコントロール ウィザードで、目的のルールの種類を選択し、前の手順の参照バイナリに移動します。 次の例では、VLC が必要な発行元情報を満たしていることを示します。

注:

Microsoft では、発行元ベースの規則を作成するために、CA、Publisher を 少なくとも 選択的に発行することをお勧めします。 製品名は含めることができます。発行元ベースの規則については ACSC によって推奨されます。

5. [次へ] を押して [作成] をクリックします。
6. 「Microsoft Intuneを使用して Windows Defender アプリケーション制御監査ポリシーを展開する」セクションで説明した手順を使用して、この補足ポリシーを展開します。

WDAC – ポリシーを適用するように切り替える

ポリシーを適用するように切り替えるには:

1. Windows Defender アプリ制御ウィザードを開き、[ポリシー エディター] を選択します。

2. 適用に変更するポリシー XML に移動します。

3. ポリシー ルール内で監査モードスイッチを無効にします。

4. [ポリシー ルール] で [次へ] を選択します。

5. 更新ポリシーが修正されたバージョン番号で作成され、新しい CIP ファイルが作成されました。

6. Microsoft Endpoint Manager 管理 Center 内で、[デバイス]、[構成プロファイル] の順に移動します。

7. 次に、プロファイル、プラットフォーム - Windows 10以降、プロファイルの種類テンプレートとカスタムを作成します。

8. ポリシーの名前 (アプリケーション制御 – ポリシーの適用など) を作成し、[ 次へ] を選択します。

9. [ OMA-URI 設定] で、[ 追加] を選択します。

   注:

   この情報は、上記の監査の作成セクションから作成されたポリシー XML の Windows Defender アプリ制御ウィザードから生成されたポリシー ID に依存します。
   
   - Name = Microsoft Allow Enforce
   - OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
   - データ型 = Base64 (ファイル)

10. Windows Defender アプリコントロール ウィザードによってポリシー XML が生成されると、(GUID) も作成されます。CIP ファイル。 次の手順では、この CIP ファイルをコピーし、ファイル拡張子の名前を に変更します。BIN (例: {CB46B243-C19C-4870-B098-A2080923755C}.bin。

11. Base64 (ファイル) の下に BIN をアップロードします。

12. [保存] を選択します。

13. プロンプトに従って 構成プロファイルを作成します。

14. アプリケーション制御の展開 – 目的のシステムにポリシー構成プロファイルを適用します。

    注:

    管理者は、以前に作成したアプリケーション – 監査ポリシーを、適用するように切り替えられる目的のシステムから除外する必要があります