クラウドやコンテナが一般化した中、直接的に管理する機会が減りつつあるハイパーバイザーの存在ですが、そもそもどんなセキュリティの論点があるのか調べてみました。
- 何の本？
- 構成は？
- 本書の日本語訳
- 前提知識
- ハイパーバイザーの基本機能
- ハイパーバイザーに関する脅威
- ハイパーバイザープラットフォーム全体の完全性に関する推奨策
- 各基本機能に対するセキュリティ推奨策
何の本？
2011年にサーバ仮想化とデスクトップ仮想化のセキュリティ推奨策を示すSP800-125「Guide to Security for Full Virtualization Technologies」が発行されました。
その後、ホスティングサービスやクラウドサービスの流行とともにハイパーバイザーの機能自体が増え、ソリューションも増えた中で、「ハイパーバイザー（を構成する全モジュール）の配備に関する一連のセキュリティ推奨事項の策定に焦点を当てること」を目的に2018年に作られたのが、今回読むSP800-125A Security Recommendations for Server-based Hypervisor Platformsです。
また別に、仮想ネットワークの安全な構成に関する推奨策をまとめたSP800-125Bというものもあるそうです。
構成は？
全32ページ、うち本文は23ページです。
一見コンパクトに見えますが、何故か本書は複雑な仮想化技術を説明する割に図が一切無く（表もほぼ無く）、ひたすら文章での解説が続くので読み解くのはボリューム以上に大変です。
全8章構成で、3～7章がメインです。
本書の説明とハイパーバイザーに関する5つの基本機能
ハイパーバイザーに関する脅威
ハイパーバイザープラットフォーム全体の完全性に関する推奨策
基本機能1.に対する推奨策
基本機能2.に対する推奨策
基本機能4.に対する推奨策
＃後述しますが、基本機能3.に対する推奨策はありません
基本機能5.に対する推奨策
サマリ
本書の日本語訳
見当たらなかったので作りました。
いつも通り、機械翻訳を微修正したレベルなので精度を保証するものではありません。読めりゃOKなレベルです。
前提知識
本書に入る前に、仮想化技術についての基礎知識がないと読んでも全く意味が分かりません。
まさに全く意味が分からなかった私が、読み進めるために集めた知識を先にまとめます。
本書の内容から離れますので、仮想化技術の知識がある人は飛ばしてください。あと間違ってたらご指摘ください。
冒頭で「ソリューションも増えた」と書いた通り、世の中にはVMware Player、VMware Workstation、Oracle VirtualBox、Microsoft Virtual Server、VMware Function、VMware vSphere、Xen、KVM、Hyper-Vなど様々な仮想化ソフトウェアがあります。
これらは以下に示すいくつかの軸で分類されます。
分類軸１．ホスト型／ハイパーバイザー型
この２つの違いは、ホストOSがあるかないか？です。
ホスト型は別名タイプ２と呼ばれ、ホストOS上に仮想化ソフトウェアを入れます。
メリットはその手軽さ、デメリットはハードウェアへのアクセスの都度ホストOSを介することによるオーバーヘッドです。
VMware Player、VMware Workstation、Oracle VirtualBox、Microsoft Virtual Server、VMware Functionなどが該当します。
ハイパーバイザー型は別名タイプ１やベアメタルと呼ばれ、ハイパーバイザーという仮想化のためのOSのようなものをインストールし、その上で仮想マシンを動かします。メリデメはホスト型の逆です。
VMware vSphere、Xen、KVM、Hyper-Vなどが該当します。
仮想化ソフトウェアやハイパーバイザーはVMMとも呼ばれます。
分類軸２．モノリシック型／マイクロカーネル型
ハイパーバイザー型の内訳としてこの2種類があります。
この２つの違いは、デバイスドライバをどこに持っているか？です。
モノリシック型は、ハイパーバイザーの中にデバイスドライバを持っています。
ゲストOSがハードウェアにアクセスする際のオーバーヘッドが少ないのが特徴です。
マイクロカーネル型は、ハイパーバイザー上で動く「管理OS」と呼ばれる、ゲストOSの親分みたいな仮想マシンの中にデバイスドライバを持っています。
ゲストOSがハードウェアにアクセスする際は、黄色線を辿る流れとなるので、モノリシック型に比べると遅くなります。反面、対応するハードウェアが多いメリットがあります。
分類軸３．完全仮想化／準仮想化（＋CPU仮想化技術）
ハイパーバイザー型のまた別の内訳としてこの2種類があります。
この２つの違いは、ゲストOSが発する特権モード命令の変換作業をどこでやるか？です。
完全仮想化は別名バイナリ・トランスレーション方式と呼ばれます。
準仮想化は別名パラバーチャライゼーション方式と呼ばれます。
命令の変換をVMMが行うのが完全仮想化、ゲストOS自体を改造して事前に命令を変換しておくのが準仮想化です。（このへん理解が曖昧）
準仮想化のほうが都度VMMが命令を変換する必要がないため性能面のメリットがありますが、ゲストOSが改造可能なオープンソースである縛りが生じます。
この縛りを気にしなくてよいのがIntel（Intel VT）やAMD（AMD-V）によるCPU側での仮想化技術です。
詳細は以下URLを見た方が早いので割愛しますが、本書でも「4.1 仮想化のためのハードウェア支援」でこの技術に触れています。
ハイパーバイザーの基本機能
SP800-125Aに戻ります。
本書では、ハイパーバイザーが持つ機能の中でも「ここが侵害されると影響が大きい」という重要なものに絞り、以下5つの基本機能を定めています。
「HY-BF」はハイパーバイザのベースライン機能を意味する接頭辞です。
-
実行するVMのスケジューリング、CPUやメモリ管理などVM内で実行されるアプリケーションプロセスの管理、VM内のアプリケーション実行中のコンテキストスイッチを提供します。
-
準仮想化に限った機能として、ゲストOSからの特権命令をハイパーバイザーが直接実行します。
HY-BF-5：ハイパーバイザー・プラットフォームの管理
ハイパーバイザー内部の仮想ネットワークの構成や、各モジュールのアップデートやパッチ適用を含む、ハイパーバイザーソフトウェアの様々な管理を行います。
この後、本書では各基本機能に対するセキュリティの推奨策が登場します。
しかし、上記のうちHY-BF-3に対応する推奨策は登場しません。
これは、同機能を提供するハイパーバイザーのカーネル部分については信頼する前提（カーネル自体の侵害は考えない）を本書が置いていることが理由です。
ハイパーバイザーに関する脅威
そもそもハイパーバイザーに関する脅威はどこから入り込むのでしょうか。
本書ではそれを3種類に分けています。
- HY-TS1：仮想化ホストが存在するネットワークから
- HY-TS2：侵害されたVMから、ホスト内の共有メモリや仮想ネットワークなどを通じて
- HY-TS3：VM管理デーモンやハイパーバイザー管理コンソールを提供するウェブインターフェイスから
このうち、仮想化環境ならではの経路はHY-TS2です。
この経路から脅威が入り込んだ結果、どのようなことが起き得るのかを3種類挙げています。（なぜかここだけHY-ではなくHYP-）
HYP-T1： プロセス分離の侵害 （VM 脱出）
ハイパーバイザーの設計上の脆弱性やデバイスドライバ自体に問題があった場合に、侵害されたVMを起点に、本来分離しているはずのハイパーバイザーや他のVMのメモリやストレージにアクセスできる可能性があります。
HYP-T2：ネットワーク分離の侵害
HYP-T3：サービス拒否
また、別の切り口として、ハイパーバイザーの基本機能の単位で考えられる脅威も挙げています。
-
前述の「HYP-T1： プロセス分離の侵害 （VM 脱出）」が対応する脅威です。 後述するセキュリティ推奨策HY-SR-2～5 で対処します。
-
VMとデバイスの仲介方法は、前提知識で記載した完全仮想化（エミュレーション）／準仮想化に加え、VMから物理デバイスを直接操作するパススルー方式があります。 このパススルー方式は、メモリに直接アクセスできる（DMA対応）デバイスによって実現されますが、裏を返せば、メモリ操作を誤ると他のVMやハイパーバイザーが利用するメモリ領域を侵害する場合があります。
後述するセキュリティ推奨策HY-SR-6～8 で対処します。
HY-BF-3：ゲストVMからのコマンドの直接実行に関する脅威
特権命令の変換処理を加えたVMがハイパーバイザーに対してハイパーコールを行います（準仮想化方式の話）。 このハイパーコール自体に不具合があると、本来許可すべきでない特権コールを実行してしまい、他のVMやハイパーバイザー全体を巻き込んでクラッシュする場合があります。
-
VMイメージの構成管理や脆弱性管理が甘い場合、脆弱性を含むVMイメージから作られた危険な状態のVMが稼働する可能性があります。
後述するセキュリティ推奨策HY-SR-9～18 で対処します。
HY-BF-5：ハイパーバイザー・プラットフォームの管理に関する脅威
本書上、タイトルと記載内容がかみ合っておらずはっきり書かれていませんが、要はハイパーバイザーの管理コンソールに対する侵害が考えられる脅威かと思います。
後述するセキュリティ推奨策HY-SR-19～20 で対処します。
ハイパーバイザープラットフォーム全体の完全性に関する推奨策
ここから20個のセキュリティ推奨策が並びます。
セキュリティ推奨策は「HY-SR-」の連番で記され、2～20の推奨策は上述の基本機能HY-BF-1～5の各脅威と対応します（HY-BF-3は除く）。
残るHY-SR-1は、そもそもハイパーバイザーのプラットフォーム自体が侵害されちゃったら、その上で稼働するハイパーバイザーもVMも何も信用できなくなるよね。という根本的な部分に対する推奨策です。
ざっくり言うと、TPMを用いて、ハイパーバイザーのプラットフォームの電源を入れた後に順番に起動する各コード（CRTM、BIOSコード、OSコード等）の完全性をハッシュ計算により順々にチェックし、最終的に起動した一連のプラットフォーム全体が改ざんされてないことを確認するのが大事。みたいな感じです。
これを正確に書くとこんな表現になりますが、
HY-SR-1: 起動されるハイパーバイザーは、(a) 標準ベースの暗号測定機能を持つ MLE をサポートするハードウェアとストレージデバイス、および (b) ハードウェアからすべてのハイパーバイザーコンポーネントへの信頼の連鎖を提供する機能を持つ認証プロセスを含むプラットフォームと全体的なインフラストラクチャの一部であるべきである。
さらに、測定される要素には、最低でもコアカーネル、カーネルサポートモジュール、デバイスドライバ、および VM ライフサイクル管理とハイパーバイザー管理のためのハイパーバイザーネイティブ管理アプリケーションが含まれるべきである。
この文章と格闘するよりも以下を読んだ方が分かりやすいと思います。
- Insight about TPM
- https://ipsj.ixsq.nii.ac.jp/ej/?action=repository_action_common_download&item_id=65016&item_no=1&attribute_id=1&file_no=1
各基本機能に対するセキュリティ推奨策
HY-BF-1に対する推奨策
HY-BF-1の「VMプロセスの分離」は、VMが発するセンシティブな特権命令を不用意に実行させないことや、物理メモリを各VMが競合しないように仮想アドレスに変換する仕組みによって維持されます。
つまり、命令セットの仮想化（前提知識に書いたCPU仮想化）とメモリ仮想化がポイントであり、そういう機能を持つハードウェアに頼ることを推奨しています。
HY-SR-2：仮想化ホストのハードウェアは、命令セット仮想化やMMUを使用したメモリ管理仮想化の支援を提供すべきである。
また、VMプロセスを綺麗に分離できたとしても、複数のVMが稼働する際に物理マシンのCPUやメモリのキャパシティについて考慮が不十分では、可用性の問題が生じます。
そうならないように、ハイパーバイザーがCPUやメモリの配分や割り当て優先順位をコントロールできる必要があります。
HY-SR-3: ハイパーバイザーは、各VM に対して保証する物理 RAM の下限値、上限値、および割り振り優先度についての設定機能を持つべきである。さらに、すべてのVMの構成メモリの合計がホストの物理RAMを超えることを可能にする「オーバーコミット機能」は、デフォルトで無効にすべきである
HY-SR-4：ハイパーバイザーは、主要な物理リソース（CPU コア数など）を超えないように、各VM に仮想リソースをプロビジョニングするための堅牢な構成機能を持つべきである。
HY-SR-5： ハイパーバイザーは、VM 毎に必要な CPU クロック・サイクルの下限値、上限値、割り当て優先度についての設定機能を提供すべきである。
HY-BF-2に対する推奨策
HYｰBF-2の「デバイスの仲介とアクセス制御」についての推奨策は、大きくデバイス仮想化の種類ごとの推奨策と、共通的な推奨策に分けられます。
前者については、前述の完全仮想化（エミュレーション）／準仮想化／パススルーの3つの方式に対して以下を推奨しています。
完全仮想化はあまり勧めておらず、準仮想化とパススルーはとにかくIOMMUが大事。です。
HY-SR-6A（エミュレーション）：ソフトウェアを通してハードウェアデバイスをエミュレートすることの複雑さが管理可能な場合（USBホスト・コントローラーなど）にのみ使用されるべきである
HY-SR-6B（準仮想化）：バックエンド・デバイスドライバのコードをハイパーバイザーよりも低い特権レベルで実行するために、バックエンド・デバイスドライバをハイパーバイザー内ではなく専用の VM 内で実行するべきである。
さらに、ハイパーバイザー・プラットフォームには、ハードウェアからホストメモリへのアクセスを検証し変換するためのIOMMUを含むべきである。
HY-SR-6C （パススルーまたは自己仮想化ハードウェアデバイス）：VM に DMA 対応デバイスへの専用アクセスを与える必要がある状況では、ハイパーバイザー・プラットフォームには、ハードウェアからホストメモリへのアクセスを検証し変換するためのIOMMUを含むべきである。
共通的な推奨策については、以下の2つがあります。
VM間でのデバイスのアクセス制御やリソース制限を推奨しています。
HY-SR-7（デバイスアクセス）：各 VM プロセスのアクセスを、必要なデバイスのみに制限するACLの設定が可能であるべきである。
HY-SR-8（デバイス使用）：サービス拒否攻撃を防ぐために、各VM に対してネットワーク帯域幅と I/O 帯域幅のリソース制限を設定できるようにすべきである。
HY-BF-4に対する推奨策
HY-BFｰ4の「VMライフサイクル管理」は、VMが生まれる瞬間から運用し続ける期間を通して、安全なVMを維持する必要があります。
つまり、安全なVMを生み出すにはVMイメージの衛生状態が肝心です。
このために、イメージ自体の脆弱性スキャンや、イメージに対する不正アクセスからの保護が重要です。
HY-SR-9：VMのゴールドイメージに対する構成要件（ゴールドスタンダード）を全てのタイプの VM に対して定義し、適合しない VM イメージは保存しない。VMイメージは、定期的に OS のバージョンやパッチが古くなっていないかスキャンされるべきである。
HY-SR-11：VMイメージのチェックインとチェックアウトの権限は、アクセス制御メカニズムによって最小権限の管理者に限定されるべきである。アクセス制御メカニズムがない場合は、VM イメージファイルを暗号化デバイスに保存し、十分複雑なパスフレーズをかけて保護するべきである。
HY-SR-12：VMイメージを保存するサーバへのアクセスは、常にTLSなどの安全なプロトコルを介して行われるべきである。
また、VMはライブマイグレーションによって移動・複製されます。
これ自体はハイパーバイザーの仕組みが実現するものですので、セキュリティの考慮点としてはライブマイグレーションを実行する管理者の認証情報の取り扱いと、マイグレーション中のトラフィックが通るネットワーク経路の保護の2点に限られます。
HY-SR-13：ライブマイグレーションを行う管理者の資格情報を、安全な認証プロトコルを使用して移行先ホストにのみ渡す。また、VMのメモリの内容とプロセッサの状態を安全に移行するために、送信元ホストと宛先ホストの両方で専用のVLANを用いる。
VMもサーバやPCと同様に、マルウェアの感染リスクがあるため、トラフィック監視やプロセス監視による脅威検出を行う必要があります。
ただし、その監視ソリューションをどこで動作させるかがポイントです。
本書では、VM内でホストIDS的に監視するケースや、仮想ネットワーク上で監視するケースなど複数比較していますが、最終的にはセキュリティ仮想アプライアンス（SVA）と呼ばれる方式が望ましいとしています。
これは、専用のVM内で動作し、監視対象のVMの状態や、VM間またはVMとハイパーバイザー間のトラフィックをハイパーバイザーと連携して監視するものです。（具体的にはこれとかこれとか）
HY-SR-14：アンチウィルスやIDS/IPSを用いて、VM 内で実行されるプロセスや VM に出入りするトラフィックを監視する。
HY-SR-15：VM のセキュリティ監視は、監視対象のVMの外部で動作し、ハイパーバイザーと連携できるSVAを実行するべきである。
HY-SR-16：仮想化ホストで実行されるすべてのマルウェア対策ツールは、定期的にシグネチャを更新する機能を持つべきである。
VMの構成管理も重要です。このあたりは普通のサーバと変わりません。
HY-SR-17：VM構成管理ツールは、監視対象のVMで構成変更を検出した場合にログを作成し、管理者に警告する機能を持つべきである。
そして、運用上の様々なユースケースを通して最小権限を維持するために、管理者に割り当てるVMの管理権限をきめ細かく制御できることが重要です。
HY-SR-18：VM管理のためのアクセス制御ソリューションは、個々のVMやグループ化したVMの単位で制御できる機能を持つべきである。さらに、VMグループへのアクセスを許可しつつ、グループ内の特定のVMだけは拒否するなどの柔軟な制御機能を持つべきである。
HY-BF-5に対する推奨策
HY-BF-5の「ハイパーバイザー・プラットフォームの管理」は、ハイパーバイザーの管理コンソールを安全に守ることが重要です。
複数のハイパーバイザーをバラバラに管理するのは危険なので、企業仮想化管理システム（EVMS）を使って集中管理することを推奨しています。VMWareのvCenterやMicrosoftのSCVMMが挙げられると思います。
HY-SR-19：企業内のすべてのハイパーバイザーの管理は、EVMSを用いて集中的に実行されるべきである。
あわせて、VMやハイパーバイザ－の管理ネットワークも保護する必要があります。
HY-SR-20：ハイパーバイザーホストとソフトウェア管理機能の保護は、専用の物理 NIC を割り当てるか、それが不可能な場合は、ハイパーバイザーの管理インターフェイスを専用の仮想ネットワークセグメントに配置し、ファイアウォールを使用してトラフィック制御を実施するべきである。
まとめは以上です。非常に長くなりました。
まとめるのに苦労した割に、多くの推奨策は仮想化ソフトウェアの製品側で満たされるものなので、多分この内容がめっちゃ刺さる人はいないであろう…という妙な切なさを感じる学習テーマでした。
とはいえ、直接管理する機会が少ないだけで、こうした技術に頼って様々なサービスが提供されているのは事実でしょうから、関連する脆弱性が出た時に素早く意味を理解するためにも知っておいて損はないかなと思います。
