次の方法で共有

Windows コンテナー用のウイルス対策の最適化

  • [アーティクル]

このページの情報は、以下に適用されます。

  • Windows 10、バージョン 1607 以降
  • Windows Server 2016 以降のバージョン
  • ホストで実行されているウイルス対策 (AV) 製品

このトピックでは、AV 製品が Windows コンテナー ファイルの冗長スキャンを回避し、コンテナーの起動時間を短縮するために使用できる最適化について説明します。

コンテナーの概要

Windows コンテナー機能は、アプリケーションの配布と展開を簡略化するように設計されています。 詳細については、Windows コンテナーの概要に関するページを参照してください。

コンテナーは、任意の数のパッケージ レイヤーから構築されます。 Windows ベース OS パッケージが最初のレイヤーを形成します。

各コンテナーには、そのコンテナーのシステム ボリュームを表す分離ボリュームがあります。 コンテナー分離フィルター (wcifs.sys) は、このコンテナー ボリュームへのパッケージ レイヤーの仮想オーバーレイを提供します。 オーバーレイはプレースホルダー (再解析ポイント) を使用して実現されます。 コンテナーがオーバーレイされたパスに初めてアクセスする前に、ボリュームにプレースホルダーがシードされます。 プレースホルダー ファイルの読み取り内容は、バッキング パッケージ ファイルに送られます。 このようにして、複数のコンテナー ボリュームが同じ基になるパッケージ ファイル データ ストリームにアクセスできます。

コンテナーによってファイルが変更された場合、分離フィルターはコピー オン ライトを実行し、プレースホルダーをパッケージ ファイルの内容に置き換えます。 これにより、その特定のコンテナーのパッケージ ファイルへの "リンケージ" が解除されます。

読み取りリダイレクト

プレースホルダー ファイルから読み取った内容は、分離フィルターによって適切なパッケージ レイヤーにリダイレクトされます。 リダイレクトは、フィルターのレベルで実行されます。 フィルターは AV 範囲を下回っているため、AV フィルターは読み取りリダイレクトを参照しません。 AV は、リダイレクトを設定するために実行されたパッケージ ファイルのオープンも参照しません。

AV フィルターには、コンテナー システム ボリュームに対するすべての操作の完全なビューがあります。 プレースホルダー ファイルに対する操作と、ファイルの変更または新しいファイルの追加を参照します。

冗長スキャンの問題

同じパッケージ レイヤーに依存する多くのコンテナーが存在する可能性があります。 特定のパッケージ ファイルの同じデータ ストリームによって、複数のコンテナー システム ボリューム上のプレースホルダーにデータが提供されます。 その結果、すべてのコンテナー内で同じデータの冗長 AV スキャンが行われる可能性があります。 これは、コンテナーのパフォーマンスに不要な悪影響を及ぼします。 コンテナーがすぐに起動することが期待され、有効期間が短い可能性があることを考えると、これは大きなコストです。

コンテナーでの冗長スキャンを回避するために、以下に説明するように AV 製品が自身の動作を変更することをお勧めします。 このアプローチでの顧客に対するリスク/報酬のメリットを判断するのは、AV 製品の責任です。 詳細については、このページの下部にある「利点とリスク」セクションを参照してください。

1. パッケージのインストール

パッケージのインストール中に、管理ツールによって、パッケージ内のファイルがレイヤー ルートの下にレイアウトされます。 AV フィルターは、パッケージ ルートに配置されるため、通常どおりファイルをスキャンし続ける必要があります。 これにより、レイヤー内のすべてのファイルが最初にマルウェアに対してクリーンアップされます。

2. コンテナーの開始と実行

コンテナー ボリュームをリアルタイムでスキャンするには、AV が冗長性を回避する方法でスキャンする必要があります。 プレースホルダー ファイルには特別な考慮が必要です。 コンテナーによって変更されたファイルやコンテナーに作成された新しいファイルはリダイレクトされないため、冗長スキャンは問題になりません。

冗長スキャンを回避するには、まず AV フィルターでそれらのボリューム上のコンテナー ボリュームとプレースホルダーを識別する必要があります。 さまざまな理由から、ボリュームがコンテナー ボリュームであるかどうかや、特定のファイルがプレースホルダー ファイルであるかどうかに関して、AV フィルターがクエリを直接実行する方法はありません。 分離フィルターは、アプリケーションの互換性上の理由からプレースホルダーの再解析ポイントを非表示にします (一部のアプリケーションは、再解析ポイントにアクセスしていることを認識している場合に正しく動作しません)。 また、ボリュームは、コンテナーの実行中は単なるコンテナー ボリュームです。 コンテナーが停止され、ボリュームが再マウントされたままになる可能性があります。 代わりに、事前作成では、AV フィルターはファイル オブジェクトに対してクエリを実行して、それがコンテナーのコンテキストで開かれているかどうかを判断する必要があります。 その後、作成に ECP をアタッチし、作成の完了時にプレースホルダーの状態を受け取ることができます。

AV 製品では、次の変更が必要です。

  • コンテナー ボリュームでの事前作成中に、プレースホルダー情報を受け取る ECP を Create CallbackData にアタッチします。 これらの作成は、IoGetSiloParameters を使用して fileobject から SILO パラメーターのクエリを実行することで識別できます。 フィルターでは、WCIFS_REDIRECTION_ECP_CONTEXT 構造体のサイズを指定する必要があることに注意してください。 ECP が確認されると、他のすべてのフィールドが出力フィールドに設定されます。

  • 作成後に ECP が確認された場合は、ECP リダイレクト フラグを調べます。 フラグは、オープンがパッケージ レイヤーとスクラッチ ルートのどちらから処理されたものか (新しいファイルか変更されたファイルか) を示します。 フラグは、パッケージ レイヤーが登録されているかどうかと、それがリモートであるかどうかも示します。

    • オープンがリモート レイヤーから処理される場合、AV はファイルのスキャンをスキップする必要があります。 これはリダイレクト フラグによって示されます: WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_LAYER && WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_REMOTE_LAYER

      リモート レイヤーは、リモート ホスト上でスキャンされたと見なすことができます。 Hyper-V コンテナー パッケージは、コンテナーをホストするユーティリティ VM に対してリモートです。 これらのパッケージは、ユーティリティ VM over SMB ループバックからアクセスされると、Hyper-V ホスト上で通常どおりにスキャンされます。

      VolumeGUID と FileId はリモートでは適用されないため、これらのフィールドは設定されません。

    • オープンが登録済みレイヤーから処理される場合、AV はファイルのスキャンをスキップする必要があります。 これはリダイレクト フラグによって示されます: WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_LAYER && WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_REGISTERED_LAYER

      登録済みレイヤーは、パッケージのインストール中と署名の更新後に非同期でスキャンする必要があります。

      Note

      登録済みレイヤーは、今後システムによって識別されない可能性があります。 この場合は、最後の箇条書きで説明されているようにローカル レイヤー ファイルを個別に識別する必要があります。

    • ローカル パッケージ レイヤーから処理されるオープンの場合、AV はレイヤー ファイルの指定された VolumeGUID と FileId を使用して、ファイルをスキャンする必要があるかどうかを判断する必要があります。 多くの場合、ボリューム GUID と FileId でインデックス付けされたスキャン済みファイルのキャッシュを AV で構築する必要があります。 これはリダイレクト フラグによって示されます: WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_LAYER

    • スクラッチ場所にある新規または変更されたファイルの場合、AV 製品はファイルをスキャンし、通常の修復を実行する必要があります。 これはリダイレクト フラグによって示されます: WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_SCRATCH

      この場合はレイヤー ファイルがないため、VolumeGUID と FileId は設定されません。

    • "このファイルはレイヤーから処理されます" をストリーム コンテキストの永続的マーカーとして保存しないでください。 最初にレイヤー ルートから処理されるファイルは、作成後に変更できます。 この場合、同じファイルの後続の作成は、作成がコンテナー ボリュームから処理されていることを示している可能性があります。 AV フィルターは、この状況が発生する可能性があることを理解する必要があります。

LayerRootLocations レジストリ キーを使用しない

以前は、LayerRootLocations レジストリ キーを使用して基本イメージの場所を取得することをお勧めしていました。 AV 製品では、このレジストリ キーを使用しなくなります。 代わりに、このトピックで推奨される方法を使用して、冗長スキャンを回避してください。

パッケージ レイヤーの登録に使用されていたレジストリの場所:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\LayerRootLocations

利点とリスク

AV 製品に対してこれらの新しい最適化を使用する場合は、次の利点とリスクを考慮してください。

メリット

  • (最初のコンテナーの場合でも) コンテナーの開始または実行時間には影響しません。
  • 複数のコンテナー内の同じコンテンツのスキャンを回避します。
  • Windows Server コンテナーの作業。 Hyper-V コンテナーの場合、これはパッケージに対して機能しますが、コンテナーを実行するには追加の作業が必要です。

リスク

署名の更新から次のスケジュール済みプロアクティブ マルウェア対策スキャンの間にコンテナーが起動された場合、最新のマルウェア対策署名に関して、コンテナーで実行されるファイルはスキャンされません。 このリスクを軽減するために、AV 製品は、前回のプロアクティブ スキャン以降に署名の更新がない場合にのみ、リダイレクトされたファイルのスキャンをスキップできます。 これにより、最新の署名でプロアクティブ スキャンが完了するまで、コンテナーのパフォーマンスの低下が制限されます。 必要に応じて、AV 製品はこのような状況でプロアクティブ スキャンをトリガーして、後続のコンテナーの起動をより効率的にすることができます。