次の方法で共有


仮想化ベースのセキュリティ (VBS)

仮想化ベースのセキュリティ (VBS) では、ハードウェアの仮想化とWindowsハイパーバイザーを使用して、カーネルが侵害される可能性があると想定されるOSの信頼のルートとなる分離された仮想環境を作成します。 Windowsでは、この分離された環境を使用してさまざまなセキュリティソリューションをホストし、オペレーティングシステムの脆弱性からの保護を大幅に強化し、保護を無効にしようとする悪意のある悪用を防ぐことができます。 VBSは、重要なシステムとオペレーティングシステムのリソースを保護したり、認証されたユーザーの資格情報などのセキュリティ資産を保護したりするための制限を適用します。

このようなセキュリティソリューションの例の1つは、VBSの分離された仮想環境内でカーネルモードコードの整合性を実行することによって、Windowsを保護および強化するメモリ整合性です。 カーネルモードコードの整合性は、すべてのカーネルモードドライバーとバイナリが開始される前にチェックされ、署名されていない、または信頼されていないドライバーやシステムファイルがシステムメモリに読み込まれないようにするWindowsプロセスです。 また、メモリの整合性は、システムの侵害に使用される可能性のあるカーネルメモリの割り当てを制限し、カーネルメモリページが安全なランタイム環境内でコードの整合性チェックに合格した後にのみ実行可能になり、実行可能ページ自体が書き込み可能になることはありません。 これにより、マルウェアがメモリを変更しようとするバッファーオーバーフローなどの脆弱性があっても、実行可能コードページを変更することはできず、変更されたメモリを実行可能にすることもできません。

Note

メモリの整合性は、ハイパーバイザーで保護されたコードの整合性 (HVCI) またはハイパーバイザーによって適用されるコードの整合性と呼ばれることがあり、当初はDevice Guardの一部としてリリースされました。 Device Guardは、グループポリシーまたはWindowsレジストリでメモリの整合性とVBS設定を検索する場合を除き、使用されなくなりました。

VBS では、次のコンポーネントが存在し、適切に構成されている必要があります。

ハードウェア要件 詳細
64 ビット CPU 仮想化ベースのセキュリティ (VBS) には、Windows ハイパーバイザーが必要です。このハイパーバイザーは、Intel VT-X や AMD-v などの仮想化拡張機能を備えた 64 ビットの IA プロセッサでのみサポートされています。
Second Level Address Translation (SLAT) また、VBSでは、プロセッサの仮想化サポートに第2レベルのアドレス変換 (SLAT) 、拡張ページテーブル (EPT) を備えたIntel VT-X2、または高速仮想化インデックス作成 (RVI) を備えたAMD-vが含まれている必要があります。
IOMMUまたはSMMU (インテルVT-D、AMD-Vi、Arm64 SMMU) DMA 対応の I/O デバイスはすべて、IOMMU または SMMU の背後に配置する必要があります。 IOMMU を使用すると、メモリ攻撃からのシステムの回復性を強化できます。
トラステッド プラットフォーム モジュール (TPM) 2.0 詳細については、トラステッド プラットフォーム モジュール (TPM) 2.0 に関するページを参照してください。
SMM 保護のためのファームウェアのサポート システム ファームウェアは、Windows SMM Security Mitigations Table (WMST) の仕様で説明されている SMM コードの強化に関する推奨事項に従っている必要があります。 WSMT仕様には、VBS機能をサポートするWindowsオペレーティングシステムで使用するために作成されたACPIテーブルの詳細が含まれています。 ファームウェアでは、WSMT の仕様で説明されている保護が実装され、仕様で説明されている対応する保護フラグが設定され、これらの要件に準拠していることがオペレーティング システムにレポートされる必要があります。
Unified Extensible Firmware Interface (UEFI) メモリ レポート ファームウェアと VBS との互換性を確保するには、UEFI ファームウェアが次のメモリ マップ レポート形式とメモリ割り当てガイドラインに従っている必要があります。

  • UEFI v2.6 メモリ属性テーブル (MAT) - VBS との互換性を確保するには、ファームウェアでコードとデータの EFI ランタイム メモリ範囲が完全に分離され、このことがオペレーティング システムにレポートされる必要があります。 VBS では、EFI ランタイム メモリ範囲の適切な分離とレポートが行われると、VBS セキュリティで保護された領域内の EFI ランタイム サービスのコード ページに必要なページ保護を適用できます。 この情報を OS に伝達するには、EFI_MEMORY_ATTRIBUTES_TABLE を使用します。 UEFI MAT を実装するには、次のガイドラインに従います。
    1. このテーブルで UEFI ランタイム全体を記述する必要があります。
    2. EfiRuntimeServicesData ページと EfiRuntimeServicesCode ページに適切なすべての属性にマークを付ける必要があります。
    3. これらの範囲はページ境界上 (4 KB) に配置する必要があり、重複することはできません。
  • EFI ページの保護 -すべてのエントリに EFI_MEMORY_RO 属性または EFI_MEMORY_XP 属性 (あるいはその両方) を含める必要があります。 実行可能とマークされているすべての UEFI メモリは、読み取り専用であることが必要です。 書き込み可能とマークされたメモリは実行可能であってはなりません。 どちらの属性も含まれていないエントリは指定できません (こうしたエントリは、メモリが実行可能でかつ書き込み可能であることを示します)。
  • セキュリティで保護されたメモリ上書き要求 (MOR) リビジョン 2 セキュリティで保護された MOR v2 は、UEFI セキュリティで保護された変数を使用して MOR ロック設定を保護するために強化されています。 これは、高度なメモリ攻撃から保護する際に役立ちます。 詳細については、セキュア MOR の実装に関するページを参照してください。
    メモリ整合性と互換性のあるドライバー すべてのシステムドライバーがテストされ、メモリ整合性と互換性があることが確認されていることを確認します。 Windows Driver Kitドライバーの検証ツールには、メモリ整合性とドライバーの互換性のテストが含まれています。 ドライバーの互換性を確認するには、次の3つの手順を実行します。
    1. コード整合性の互換性チェックを有効にしてドライバーの検証ツールを使用します。
    2. Windows HLK でハイパーバイザー コード整合性準備テストを実行します。
    3. VBSとメモリ整合性が有効になっているシステムでドライバーをテストします。 この手順は、メモリ整合性を使用してドライバーの動作を検証するために不可欠です。静的コード分析ツールは、実行時に可能なすべてのメモリ整合性違反を検出することはできません。
    セキュア ブート VBS を利用するデバイスでセキュア ブートを有効にする必要があります。 詳細については、「セキュア ブート」を参照してください。

    VBSは、入れ子になった仮想化をサポートするVMで動作します。 これには、すべてのGen2 VMと、入れ子になった仮想化をサポートするGen1 VMが含まれます。 サポートされているVMシリーズの一覧を次の表に示します。

    VMシリーズ名 入れ子になった仮想化 VM Gen
    Av2 はい 1 (特定の内部サイズはGen 2をサポート)
    B いいえ 1 と 2
    Dsv2/Dv2/Dv3/Ev3 はい 1
    Dsv3/Ddsv3 はい 1 と 2
    Dsv4/Ddsv4 はい 1 と 2
    Esv3/Edsv3 はい 1 と 2
    Esv4/Edsv4 はい 1 と 2
    Ev4/Edv4 はい Ev4 - 1のみ
    Edv4 -1&2
    Dv4/Ddv4 はい 1 と 2
    Dv5/Ddv5/Dsv5/Ddsv5 はい 1 と 2
    Ev5/Edv5/Esv5/Edsv5 はい 1 と 2
    Dasv5/Dadsv5/Easv5/ Eadsv5 はい 1 と 2
    Ebsv5/Edbsv5 はい 1 と 2
    Fsv2 はい 1 と 2
    Fx はい 2
    Lsv2 はい 1 と 2

    Hyper-vの詳細については、 「windows Server 2016のhyper-v」 または 「windows 10でのhyper-vの概要」 を参照してください。 ハイパーバイザーの詳細については、 「ハイパーバイザーの仕様」 を参照してください。