次の方法で共有


アプリ コントロールの管理のヒント & 既知の問題

App Control for Business の一部の機能は、特定の Windows バージョンでのみ使用できます。 アプリ制御機能の可用性について詳しくは、こちらをご覧ください。

この記事では、管理者向けのヒントとテクニックと、App Control for Business に関する既知の問題について説明します。 運用環境で有効にする前に、ラボでこの構成をテストします。

管理のヒントとヒント

アプリ制御ポリシー ファイルの場所

ポリシーが署名されているかどうか、および使用されたポリシーの展開方法に応じて、次の場所に複数のポリシー形式のアプリ制御ポリシーが見つかります。

  • <OS ボリューム>\Windows\System32\CodeIntegrity\CiPolicies\Active\{PolicyId GUID}.cip
  • <EFI システム パーティション>\Microsoft\Boot\CiPolicies\Active\{PolicyId GUID}.cip

{PolicyId GUID} の値はポリシーによって一意であり、<PolicyId> 要素を使用してポリシー XML で定義されます。

1 つのポリシー形式のアプリ制御ポリシーの場合、上記の 2 つの場所に加えて、次の場所で SiPolicy.p7b というファイルも検索します。

  • <EFI システム パーティション>\Microsoft\Boot\SiPolicy.p7b
  • <OS ボリューム>\Windows\System32\CodeIntegrity\SiPolicy.p7b

単一のポリシー形式の GUID {A244370E-44C9-4C06-B551-F6016E563076} を使用する複数のポリシー形式のアプリ制御ポリシーは、ポリシー ファイルの場所のいずれかに存在する可能性があります。

ファイル ルールの優先順位

アプリコントロールエンジンがデバイス上のアクティブなポリシーセットに対してファイルを評価すると、ルールは次の順序で適用されます。 ファイルが一致するものに遭遇すると、App Control はそれ以上の処理を停止します。

  1. 明示的な拒否規則に一致するファイルは、許可しようとする他のルールを作成した場合でもブロックされます。 拒否ルールでは、任意の ルール レベルを使用できます。 拒否ルールを作成する場合は、意図した以上のブロックを回避するために、最も具体的なルール レベルを使用します。

  2. 明示的な許可規則に一致するすべてのファイルが実行されます。

  3. マネージド インストーラーまたはインテリジェント セキュリティ グラフ (ISG) 拡張属性 (EA) を持つファイルは、ポリシーで照合オプション (マネージド インストーラーまたは ISG) が有効になっている場合に実行されます。

  4. 上記の条件に基づいて許可されていないファイルは、ポリシーでそのオプションが有効になっているときに、ISG を使用して評判がチェックされます。 ファイルは、ISG が安全であると判断し、新しい ISG EA がファイルに書き込まれた場合に実行されます。

  5. 明示的な規則によって許可されていないファイル、または ISG またはマネージド インストーラーに基づいて許可されていないファイルは、暗黙的にブロックされます。

既知の問題

監査モードのアプリ制御ポリシーは、デバイスのパフォーマンスに影響する可能性があります

ファイルが現在の一連のアプリ制御ポリシーに対して評価されると、アプリコントロールエンジンは、アクティブなポリシーに合格したときにファイルにカーネル拡張属性 (EA) を設定します。 その後、同じファイルが実行された場合、App Control は、有効なポリシーが変更されない限り、EA をチェックし、キャッシュされた結果を再利用します。 このキャッシュ メカニズムにより、多数のルールを含む多くのポリシーがアクティブな場合でも、アプリ制御がスケーリングされます。 ただし、このパフォーマンスの最適化は、監査モードのポリシーには使用されません。 場合によっては、監査ポリシーを持つシステムと比較して、ポリシーのみが適用されているシステム間でパフォーマンスの違いが見られます。

インテリジェント セキュリティ グラフ (ISG) オプションは、クラウドで多数のファイルがチェックされている場合にパフォーマンスに影響する可能性があります

ISG オプションは、アプリ コントロールの非常に重要な機能であり、個々のファイルとアプリのルール管理の複雑さを軽減します。 ただし、クラウドベースの人工知能 (AI) モデルに依存しているため、実行する必要がある重要なアプリとファイルに関する決定を ISG に依存しないようにする必要があります。 ISG への依存は、重要なワークロード、Windows OS コード、特に起動時に実行されるコード、またはパフォーマンスが最も重要な状況では推奨されません。 可能な限り、ポリシーに明示的なルールが存在することを確認するか、ポリシー管理オーバーヘッドを減らす方法として ISG の代わりにマネージド インストーラーを使用する必要があります。

ISG によるパフォーマンスへの影響に対する許容度を考慮する場合は、 監査モード ポリシーのパフォーマンスに影響を与える前の問題のパフォーマンスへの影響も考慮してください。 多数のファイルに対する ISG 承認に大きく依存する監査モードでポリシーを実行しないようにしてください。

32 を超えるポリシーがアクティブな場合にブート停止エラー (ブルー スクリーン) が発生する

2024 年 4 月 9 日以降にリリースされた Windows セキュリティ更新プログラムを適用するまで、デバイスは 32 個のアクティブ なポリシーに制限されます。 ポリシーの最大数を超えた場合、バグチェック値が0x0000003bの ci.dll を参照しているデバイスのブルースクリーン。 アプリ制御ポリシーを計画するときは、この最大ポリシー数の制限を考慮してください。 デバイスでアクティブになっている Windows 受信トレイ ポリシー も、この制限にカウントされます。 ポリシーの上限を削除するには、2024 年 4 月 9 日以降にリリースされた Windows セキュリティ更新プログラムをインストールし、デバイスを再起動します。 それ以外の場合は、デバイス上のポリシーの数を減らして、32 個以下のポリシーを維持します。

ポリシー制限はWindows 11 21H2 では削除されず、32 ポリシーに制限されたままです。

監査モード ポリシーは、一部のアプリの動作を変更したり、アプリのクラッシュを引き起こしたりする可能性があります

アプリコントロール監査モードは、アプリへの影響を回避するように設計されていますが、一部の機能は、オプション 0 Enabled:UMCI でユーザー モード コード整合性 (UMCI) をオンにするアプリコントロール ポリシーで常にオン/常に適用されます。 監査モードでの既知のシステム変更の一覧を次に示します。

  • 一部のスクリプト ホストでは、監査モードであっても、コードをブロックしたり、権限が少ないコードを実行したりする場合があります。 個々のスクリプト ホストの動作については、「 App Control を使用した スクリプトの適用」を参照してください。
  • オプション 19 有効:動的コード セキュリティは、一部のバージョンの Windows とWindows Serverでそのオプションが UMCI ポリシーに含まれている場合、常に適用されます。 「 アプリ コントロールと .NET」を参照してください。

.NET ネイティブ イメージでは、誤検知ブロック イベントが生成される可能性があります

場合によっては、App Control for Business のエラーと警告が書き込まれるコード整合性ログには、.NET アセンブリ用に生成されたネイティブ イメージのエラー イベントが含まれます。 通常、ブロックされたネイティブ イメージは対応するアセンブリにフォールバックし、.NET は次のスケジュールされたメンテナンス期間にネイティブ イメージを再生成するため、ネイティブ イメージ ブロックは機能的に問題ありません。 それを防ぐには、.NET アプリケーションを 事前にネイティブ コード にコンパイルします。

.NET では、GUID が一致しないコンポーネント オブジェクト モデル (COM) オブジェクトが読み込まれません

COM オブジェクトを使用すると、さまざまなソフトウェア コンポーネントが簡単に通信して連携できます。 別のコンポーネントで使用するには、COM オブジェクトをオペレーティング システムに登録する必要があります。 登録には、オブジェクトのコードに基づいて計算される GUID が含まれます。 COM オブジェクトの読み込みとアクティブ化は、型名と呼ばれる登録の別の部分を使用して行われます。 登録されている GUID とアクティブ化された COM オブジェクトのコードの実際の GUID の間に不一致が存在する場合があります。 不一致は、アプリの COM オブジェクト登録コードのバグや、GUID に影響を与える方法で COM オブジェクトのコードが変更された場合に発生する可能性があります。 通常、Windows と .NET はこの条件を許しており、COM オブジェクトのコードは関係なく実行されます。 ただし、GUID の不一致がある場所で COM オブジェクトの読み込みを許可すると、GUID の混乱を悪用して意図しないコードを実行できる攻撃者に対してシステムが脆弱になります。

この攻撃手法に対して脆弱なシステムに対するアプリコントロールの保護効果を高めるために、.NET は、登録された COM オブジェクト GUID がシステム計算された GUID と一致することをチェックに追加の検証を適用します。 不一致が見つかった場合、.NET は COM オブジェクトを読み込まず、一般的な COM 読み込みエラーが発生します。 この条件で COM オブジェクトを使用しているアプリは予期しない方法で動作する可能性があり、アプリの COM オブジェクト登録コードに関する問題を修正するために更新する必要があります。

この動作は、ユーザー モード コードに対してアプリ制御ポリシーが適用されている場合にのみ発生するため、監査モードでは検出できません。 追加の検証チェックが原因で COM オブジェクトの読み込みに失敗した場合、ログ記録やその他のイベントはありません。 アプリを修復または再インストールすると、問題が一時的に解決されますが、COM 登録の問題を解決し、問題の将来のインスタンスを防ぐためにアプリの更新が必要です。

を管理するためのポリシー制御オプションはありません。NET の GUID 検証チェック。つまり、チェックは常に実行されます。 アプリ制御ポリシーの展開後に COM オブジェクトのエラーが発生する場合は、アプリを生成するソフトウェア開発者または独立系ソフトウェア ベンダー (ISV) に問い合わせて、問題の修正を要求してください。

楕円曲線暗号 (ECC) を使用した署名はサポートされていません

アプリ コントロールの署名者ベースのルールは、RSA 暗号化でのみ機能します。 ECDSA などの ECC アルゴリズムはサポートされていません。 アプリ コントロールが ECC 署名に基づいてファイルをブロックする場合、対応する 3089 署名情報イベントに VerificationError = 23 が表示されます。 ファイルを承認するには、代わりにハッシュまたはファイル属性ルールを使用するか、ファイルが RSA を使用して署名で署名されている場合は、他の署名者ルールを使用します。

MSI インストーラーは、FilePath 規則で許可されている場合、Windows 10でユーザー書き込み可能として扱われます

MSI インストーラー ファイルは、Windows 10 および Windows Server 2022 以前で、ユーザーが書き込み可能として常に検出されます。 FilePath ルールを使用して MSI ファイルを許可する必要がある場合は、アプリ制御ポリシーでオプション 18 Disabled:Runtime FilePath Rule Protection を設定する必要があります。

インターネットから直接起動された MSI インストーラーがブロックされる

.msi ファイルをインターネットから App Control によって保護されたコンピューターに直接インストールできない。 たとえば、次のコマンドは失敗します。

msiexec -i https://download.microsoft.com/download/2/E/3/2E3A1E42-8F50-4396-9E7E-76209EA4F429/Windows10_Version_1511_ADMX.msi

回避策として、MSI ファイルをダウンロードし、ローカルで実行します。

msiexec -i c:\temp\Windows10_Version_1511_ADMX.msi

カスタム ポリシーを使用したブートとパフォーマンスの低下

App Control は、受信トレイ Windows プロセスを含め、実行されるすべてのプロセスを評価します。 アプリコントロール テンプレートに基づいてポリシーが構築されていない場合や、Windows 署名者を信頼していない場合は、起動時間の短縮、パフォーマンスの低下、およびブートの問題が発生する可能性があります。 このような理由から、ポリシーを作成するには、可能な限り App Control 基本テンプレート を使用する必要があります。

AppId タグ付けポリシーは、タグ付けのスコープ内にない DLL ファイルを評価します

AppId タグ付けポリシーを使用すると、ポリシーを渡す実行可能ファイルのプロセス トークンに追加されたメタデータ "tags" が結果になります。 その後、タグを使用して、AppId タグを理解し、プロセスで一致するタグを検索するアプリまたはコンポーネントの動作を変更できます。 たとえば、カスタム タグを使用してファイアウォール経由での接続を許可するプロセスを識別する Windows ファイアウォール規則を設定できます。 AppId タグは実行可能ファイル (EXEs) にのみ適用され、ダイナミック リンク ライブラリ (DLL) などの他の種類のコードには適用されません。 ただし、DLL を実行すると、アプリコントロールは、その種類のすべてのファイルを許可するルールが存在しない限り、ポリシーに対してファイルを評価します。 DLL のポリシー評価を短絡し、アプリコントロールのパフォーマンスへの影響をさらに軽減するには、AppId タグ付けポリシーに次の規則を追加します。

ポリシー内のすべての dll を許可します。

xml ポリシー内のすべての dll ファイルを許可します。