インテリジェント セキュリティ グラフ (ISG) を使用して信頼できるアプリを承認する

IT マネージド システムを通じてアプリケーションを展開および管理しない組織では、アプリ制御を実装するのが難しい場合があります。 このような環境では、ユーザーは仕事で使用するアプリケーションを取得できるため、効果的なアプリ制御ポリシーを構築することは困難です。

エンド ユーザーの抵抗やヘルプデスクへの問い合わせを減らすために、App Control for Business を設定して、Microsoft のインテリジェント セキュリティ グラフ (ISG) が評判の良いと認識したアプリケーションを自動的に許可することができます。 ISG オプションは、組織がアプリ エコシステムの制御が制限されている場合でも、organization App Control の実装を開始するのに役立ちます。 ISG の詳細については、「 Microsoft Graph の主なサービスと機能」の「セキュリティ」セクションを参照してください。

アプリ コントロールは ISG とどのように連携しますか?

ISG はアプリの "リスト" ではありません。 代わりに、Microsoft Defender SmartScreen と Microsoft Defender ウイルス対策を強化するのと同じ膨大なセキュリティ インテリジェンスと機械学習分析を使用して、アプリケーションを "既知の良い"、"既知の悪い"、または "不明" の評判に分類します。 このクラウドベースの AI は、Windows エンドポイントやその他のデータ ソースから収集され、24 時間ごとに処理される数兆個のシグナルに基づいています。 その結果、クラウドからの決定が変わる可能性があります。

App Control は、ポリシーによって明示的に許可または拒否されていないバイナリ、およびマネージド インストーラーによってインストールされていないバイナリを ISG のみチェックします。 ISG オプションで App Control が有効になっているシステムでこのようなバイナリを実行すると、App Control はハッシュ情報と署名情報をクラウドに送信することでファイルの評判をチェックします。 ISG がファイルの評判が "既知の良好" であると報告した場合、ファイルの実行が許可されます。 それ以外の場合は、アプリ コントロールによってブロックされます。

評判の良いファイルがアプリケーション インストーラーである場合、インストーラーの評判は、インストーラーがディスクに書き込むすべてのファイルに渡されます。 このようにして、アプリのインストールと実行に必要なすべてのファイルは、インストーラーから肯定的な評価データを継承します。 インストーラーの評判に基づいて承認されたFilesには、ファイルに$KERNEL.SMARTLOCKER.ORIGINCLAIMカーネル拡張属性 (EA) が書き込まれます。

App Control は、ファイルの評判データを定期的に再クエリします。 また、企業は、[ Enabled:Invalidate EAs on Reboot ] オプションを使用して、キャッシュされた評判結果が再起動時にフラッシュされるように指定できます。

配信元の要求を理解する

マネージド インストーラーまたはインテリジェント セキュリティ グラフ (ISG) によってファイルが承認されると、アプリ コントロールは、カーネル管理拡張属性 (EA) をファイルに追加することで、そのファイルが信頼される理由を記録します。 配信元クレームと呼ばれる EA は、ファイルの評判のソースをキャプチャするため、コード整合性は後で元のソースを再チェックせずにファイルを評価できます。 配信元クレームは $KERNEL.SMARTLOCKER.ORIGINCLAIM と呼ばれます。 配信元クレームは、ファイルを書き込んだ内容を記録し、ファイルを書き込んだプロセスがマネージド インストーラーとして信頼されているか、評判に基づいて信頼されたか、および信頼が親から継承されたかどうかを示します。 fsutil コマンドを使用して、この EA をファイルで表示できます。 正確な手順については、「 Using fsutil to query extended attributes for managed installer (MI)」を参照してください。

• マネージド インストーラーの配信元:ファイルが、ポリシーがマネージド インストーラーとして信頼するプロセス (たとえば、Microsoft Configuration Manager や Microsoft Intune などの展開ツール) によって書き込まれました。 この信頼は、ファイルのプロパティ、署名、またはハッシュ値ではなく、 ファイルがデバイスに到着した方法 に基づいています。 詳細については、「 マネージド インストーラーでのセキュリティに関する考慮事項」を参照してください。
• インテリジェント セキュリティ グラフ (ISG) 配信元:ファイルが好意的な評判応答を受け取ったか、ファイルを作成したインストーラーである親プロセスから良い評判応答を受け取った。 これらの評判応答は、インテリジェント セキュリティ グラフと呼ばれる Microsoft のセキュリティ インテリジェンス サービスから提供されます。 評判は特定のファイルに関連付けられているため、ファイルが変更された場合、評判は適用されなくなり、配信元の要求は尊重されなくなります。 そのような場合、ファイルは次回実行時に App Control によって再評価されます。 詳細については、「 インテリジェント セキュリティ グラフ (ISG) を使用して信頼できるアプリを承認する」を参照してください。

配信元の要求はプロセス ツリーを下に伝達します。 管理されているインストーラーが実行されるとき、またはインストーラーが ISG から信頼されたインストーラー評判応答を受け取ると、ISG は書き込むファイルと起動する子プロセスに同等の信頼を渡します。 その信頼は、子プロセス、子プロセス、そしてその後の世代を通じてライブ プロセス ツリーを下り続けるため、インストーラーがアプリをインストールして実行するために必要なすべてのファイルが承認されます。

伝搬は無制限ではありません。 信頼されたプロセス ツリーが壊れたときに終了します。これには、次の場合が含まれます。

• 元のインストーラー プロセスが終了します。 信頼は、信頼されたプロセス ツリーの有効期間が対象となります。 元のマネージド インストーラーまたは ISG で信頼されたインストーラー プロセスが終了した後に作成されたファイルは、その配信元クレームを継承しません。 拡張属性データでは、このようなファイルは "子の子" としてマークされ、単独での実行は承認されません。明示的なルール、マネージド インストーラーの配信元、ISG 評判など、他の手段によって許可する必要があります。
• プロセスがセキュリティ境界を超えています。 プロセスが別のユーザーまたはセキュリティ コンテキストで生成された場合、親プロセスはその配信元の要求を子プロセスに渡すことができます。 一致しない場合、プロセス ツリーは破損しており、子プロセスまたはその子によって作成されたファイルは、初期プロセスの配信元の要求に基づいて承認されません。

プロセス ツリーが何らかの理由で破損した後は、作成されたファイルは、管理されたインストーラーとして実行する場合や、ISG から信頼されたインストーラー評判応答を受け取る場合など、別の方法で承認する必要があります。

アプリ コントロール ポリシーの ISG 承認の構成

ISGの設定は、任意の管理ソリューションを使用して簡単に行うことができます。 ISG オプションの設定には、次の基本的な手順が含まれます。

• App Control ポリシー XML で Enabled:Intelligent Security Graph 承認 オプションが設定されていることを確認します
• App Control がクライアントで ISG を正しく使用できるようにするために必要なサービスを有効にする

アプリ コントロール ポリシー XML で ISG オプションが設定されていることを確認します

Microsoft インテリジェント セキュリティ グラフに基づくアプリとバイナリを許可するには、アプリ制御ポリシーで Enabled:Intelligent Security Graph 承認 オプションを指定する必要があります。 この手順は、 Set-RuleOption コマンドレットを使用して実行できます。 また、[ Enabled:Invalidate EAs on Reboot ] オプションを設定して、再起動するたびに ISG の結果が再度検証されるようにする必要があります。 ISG オプションは、インターネットに定期的にアクセスできないデバイスにはお勧めしません。 次の例は、両方のオプション セットを示しています。

<Rules>
    <Rule>
      <Option>Enabled:Unsigned System Integrity Policy</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Advanced Boot Options Menu</Option>
    </Rule>
    <Rule>
      <Option>Required:Enforce Store Applications</Option>
    </Rule>
    <Rule>
      <Option>Enabled:UMCI</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Managed Installer</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Intelligent Security Graph Authorization</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Invalidate EAs on Reboot</Option>
    </Rule>
</Rules>

App Control がクライアントで ISG を正しく使用できるようにするために必要なサービスを有効にする

ISG で使用されるヒューリスティックが正しく機能するには、Windows の他のコンポーネントを有効にする必要があります。 これらのコンポーネントは、 c:\windows\system32 で appidtel 実行可能ファイルを実行することで構成できます。

appidtel start

この手順は、MDM 経由で展開されたアプリ制御ポリシーには必要ありません。CSP は必要なコンポーネントを有効にするためです。 Configuration Manager のアプリ コントロール統合を使用して ISG が構成されている場合も、この手順は必要ありません。

ISG オプションのセキュリティに関する考慮事項

ISG はヒューリスティック ベースのメカニズムであるため、明示的な許可または拒否ルールと同じセキュリティ保証は提供しません。 ユーザーが標準のユーザー権限で操作し、Microsoft Defender for Endpoint などのセキュリティ監視ソリューションが使用される場合に最適です。

ISG でのルールの優先順位

ISG オプションを明示的な許可または拒否ルールと組み合わせると、App Control は評判を使用する前に明示的なルールを評価します。 明示的な拒否ルールは常に ISG 評判よりも優先されるため、App Control は評判に関係なく拒否されたファイルをブロックします。 また、明示的な許可ルールは評判よりも優先されます。 ISG は、明示的な許可または拒否ルールでカバーされていないファイルにのみ影響します。

コード整合性はブート時にポリシーからローカルに評価し、クラウドまたはランタイムの依存関係を使用できないため、ブートに不可欠なバイナリを確実に承認できる静的ルールをポリシーに作成できます。 これには、AllowAll 規則、ワイルドカード FileName='*' 規則、署名者規則、ファイル属性規則、およびハッシュ規則が含まれます。 ブート クリティカルなファイルの承認を ISG やマネージド インストーラーに依存しないでください。それらの決定は、クラウドの評判やカーネル拡張属性に依存します。これらの属性は、ブート パスの早い段階で常に使用できるとは限りません。これにより、それらのファイルがブロックされたり、ブートやサービス開始のタイムアウトが発生したりする可能性があります。

明示的な拒否ルールを持つ AllowAll テンプレートを使用する場合も、明示的な拒否ルールが優先されます。 詳細については、「 ドライバーまたはアプリをブロックするアプリ コントロール ポリシーの作成」を参照してください。 マネージド インストーラーと ISG の動作の詳細については、「 マネージド インストーラー」と「ISG テクニカル リファレンスとトラブルシューティング ガイド」を参照してください。

カーネル特権で実行されているプロセスは、ISG 拡張ファイル属性を設定してバイナリの評判が良好であるかのように見せることで、アプリ制御を回避できます。

また、ISG オプションは、アプリ インストーラーからアプリ インストーラーがディスクに書き込むバイナリに評判を渡すため、場合によってはファイルを過剰に承認する可能性があります。 たとえば、完了時にインストーラーがアプリを起動する場合、アプリ コントロールは、その初回実行中にアプリが書き込むすべてのファイルも許可します。

ISG を使用する際の既知の制限事項

ISG は "正常であることが判明している" バイナリのみを許可するため、ISG は正当なソフトウェアを実行しても安全かどうかを予測できない場合があります。 その場合、ソフトウェアはアプリ コントロールによってブロックされます。 この場合、App Control ポリシーのルールを使用してソフトウェアを許可するか、App Control ポリシーで信頼されている証明書によって署名されたカタログをデプロイするか、App Control 管理インストーラーからソフトウェアをインストールする必要があります。 実行時にバイナリを動的に作成するインストーラーまたはアプリケーション、および自己更新アプリケーションで、この現象が発生することがあります。

パッケージ アプリは ISG ではサポートされていないため、アプリ制御ポリシーで個別に承認する必要があります。 パッケージ アプリには強力なアプリ ID があり、署名する必要があるため、アプリ制御ポリシーを使用して パッケージ アプリを承認 するのは簡単です。

ISG はカーネル モード ドライバーを承認しません。 アプリ コントロール ポリシーには、必要なドライバーの実行を許可するルールが必要です。