Warning
アプリコントロールが適用されると、登録 GUID が実行時にシステムによって計算されたものと一致しない場合、.NET は特定のコンポーネント オブジェクト モデル (COM) オブジェクトを読み込まれません。 その場合、ユーザーには一般的な COM 読み込みエラー ダイアログが表示されますが、イベントやその他の情報はシステムに記録されません。 詳細については、「App Control 管理 Tips & 既知の問題: .NET が一致しない GUID を持つ COM オブジェクトを読み込まない」を参照してください。
.NET アプリ (C#のような高レベルの言語で記述) は、中間言語 (IL) にコンパイルされます。 IL は、任意のオペレーティング システムまたはアーキテクチャでサポートできるコンパクトなコード形式です。 ほとんどの .NET アプリでは、複数の環境でサポートされている API が使用され、.NET ランタイムのみを実行する必要があります。 CPU (Arm64 や x64 など) で実行するには、IL をネイティブ コードにコンパイルする必要があります。 .NET では、アプリ コントロール ユーザー モード ポリシーを使用してデバイス上のネイティブ イメージ (NI) に IL をコンパイルするときに、最初に元の IL ファイルが現在のアプリコントロール ポリシーに合格するかどうかを確認します。 その場合、.NET は、生成された NI ファイルに NTFS 拡張属性 (EA) を設定して、アプリ コントロールも信頼できるようにします。 .NET アプリを実行すると、アプリ コントロールは NI ファイルに EA を表示し、それを許可します。
NIファイルに設定されているEAは、現在アクティブなアプリコントロールポリシーにのみ適用されます。 アクティブなアプリ制御ポリシーの 1 つが更新された場合、または新しいポリシーが適用された場合、NI ファイルの EA は無効になります。 次回アプリを実行すると、アプリコントロールによってNIファイルがブロックされます。 .NET はブロックを適切に処理し、元の IL コードにフォールバックします。 IL が引き続き最新のアプリ制御ポリシーに合格した場合、アプリは機能上の問題なく実行されます。 IL は実行時にコンパイルされるようになったため、アプリのパフォーマンスが若干低下する可能性があります。 .NET が IL にフォールバックする必要がある場合、.NET では、すべての NI ファイルを再生成するために、次のメンテナンス期間に実行するプロセスもスケジュールされます。したがって、最新のアプリ制御ポリシーに合格したすべてのコードについて、アプリ コントロール EA を再確立します。
場合によっては、NI ファイルがブロックされている場合、「App Control 管理 Tips & 既知の問題」で説明されているように、CodeIntegrity - Operational イベント ログに "誤検知" ブロック イベントが表示されることがあります。
App Control EA が有効でない場合、または不足している場合に発生するパフォーマンスの低下を軽減するには、次の手順を実行します。
- アプリ制御ポリシーを頻繁に更新することは避けてください。
-
ngen update(すべてのマシン アーキテクチャで) を実行して、アプリコントロールポリシーに変更を適用した直後にすべてのNIファイルを強制的に再生成します。 - アプリケーションを .NET Core (.NET 6 以降) に移行し、 ネイティブ AOT を有効にします。
アプリ制御と .NET 動的コード セキュリティの強化
セキュリティ研究者は、アプリが外部ソースからライブラリを読み込んだり、実行時に新しいコードを生成したりできる一部の .NET 機能を使用して、アプリコントロールを回避できることを発見しました。 この潜在的な脆弱性に対処するために、アプリ コントロールには、実行時に読み込まれたコードを検証するために .NET と連携する 動的コード セキュリティ と呼ばれるオプションが含まれています。
動的コード セキュリティが有効になっている場合、アプリ制御ポリシーは、インターネットやネットワーク共有などの外部ソースまたはリモート ソースから .NET が読み込むライブラリに適用されます。 また、.NET によってディスクに生成されたコードの改ざんを検出し、改ざんされたコードの読み込みをブロックします。 さらに、System.Reflection.Emit でビルドされた署名されていないアセンブリの読み込みなど、動的コード セキュリティでサポートされていない一部の .NET 読み込み機能は常にブロックされます。
通常、動的コードがブロックされると、その親プロセスが停止またはクラッシュします。 ASP.NET を使用してこれを回避するには、デプロイ専用の動的コードをプリコンパイルできます。 「ASP.NET プリコンパイルの概要」の「展開専用のプリコンパイル」を参照してください。
重要
.NET 動的コード セキュリティは、Windows 11 24H2 以降と 2025 以降Windows Serverでのみ監査モードで動作します。 Windows 10または以前のバージョンのWindows 11とWindows Serverでは、動的コード セキュリティの監査モードはありません。 いずれかのアプリ制御ポリシーが以前のバージョンでオプション 19 Enabled:Dynamic Code Security を設定した場合、ポリシーが監査モードであっても動的コード セキュリティの強化が 有効になり、適用されます 。 アプリコントロール ポリシーを運用環境にデプロイするときは、常にアプリを徹底的にテストし、安全なデプロイ プラクティスを使用します。
動的コード セキュリティは、"2 次" 攻撃と呼ばれる可能性のある攻撃手法を軽減します。 つまり、攻撃者はシステムにアクセスでき、コードを実行できます。 2 番目の攻撃は、永続化を得ようとしたり、攻撃者のアクティビティをさらに隠したりしようとする可能性があります。 動的コード セキュリティは重要であり、推奨されますが、ポリシーを適用する前に、24H2 以降、または 2025 以降 Windows 11 Windows Server実行されているシステムで監査モードでテストすることもお勧めします。
動的コード セキュリティによってブロックされたコードは、 CodeIntegrity - Operational イベント ログのイベント ID 3114 を使用して記録されます。 System.Reflection.Emit などのサポートされていない .NET 機能のいずれかを使用して読み込まれたコードを除き、イベントからの情報を使用してブロックされた動的コードを許可するルールを作成できます。 「アプリ コントロール ウィザードを使用して、アプリ コントロール イベント ログからルールを作成する」を参照してください。
注
.NET では、動的に生成されたコードを実行するために、2 つの異なるメソッドが試行されます。 アプリ制御ポリシーが最初のメソッドをブロックする場合、.NET は 2 つ目のメソッドを試行します。 2 回の試行のそれぞれで、個別の 3114 イベントが発生します。 3114 イベントが分離して発生した場合は、.NET によるコード実行の最初の試行のみを対象とするため、"誤検知" として無視しても安全です。 同じコードに対して 2 つの 3114 イベントがミリ秒以内に一度に表示された場合にのみ、確認する実際の問題が示されます。
動的コード セキュリティを有効にするには、オプション 19 - Enabled:Dynamic Code Security を、アプリコントロール ウィザード、set-ruleoption PowerShell コマンドレット、またはアプリコントロール ポリシー XML の <Rules> セクションに追加して、アプリコントロール ポリシーに追加します。
<Rule>
<Option>Enabled:Dynamic Code Security</Option>
</Rule>