怪しいアプリも安全にテストできる新機能「Windowsサンドボックス」を使ってみる：Windows 10 The Latest
Windows 10 May 2019 Updateの新機能として、アプリのテストなどが容易になる仮想環境「Windowsサンドボックス」が提供された。このWindowsサンドボックスとはどのような機能なのか、どのように使えばいいのかを解説する。
2019年5月下旬に提供が開始されたWindows 10の春の機能アップデートである「Windows 10 May 2019 Update」ではさまざまな新機能が追加されている（新機能の概要については、Windows 10 The Latest「待望の機能アップデート『Windows 10 May 2019 Update』の主な変更点」参照のこと）。この中の目玉機能の1つが、今回取り上げる「Windowsサンドボックス（Windows Sandbox）」だ。
Windowsサンドボックスは、CPUが持つ仮想マシン支援機能（Intel VT／AMD-V）を利用するソフトウェアのテスト環境である。仮想マシンの中でWindows 10（以下ゲストWindowsと呼ぶ）を起動でき、その中でさまざまなテストを行える。なお、WindowsサンドボックスはWindows 10 Homeではサポートされておらず、Pro／Enterpriseで機能を有効化させることで利用できるようになる（デフォルトでは、無効になっている）。
Windowsサンドボックスでは、その実行がホスト側となるWindows 10（以後ホストWindowsと呼ぶ）に全く影響を与えず、ファイルシステムへの書き込みも終了後にはホストWindowsに残らない。起動するゲストWindowsは、フルインストール直後と同じクリーンなもので、レジストリも初期状態のままだ。ユーザーアカウントは、「WDAGUtilityAccount」というAdministrator権限を持つWindowsサンドボックス専用のユーザー名のみが登録された状態であり、後述するログオンスクリプトもこのユーザー権限で実行される。
ただテスト環境にするとなると、まっさらなWindows 10であるため、このままでは厳しい。例えば、ソフトウェアをセキュリティ的に評価するなら、ネットワークアクセスやレジストリアクセスなどを調査するためのツールがほしくなる。また、繰り返し動作を行わせるためにはスクリプト言語なども必要となることがある。このため、Windowsサンドボックスは、基本的な設定ファイルを持ち、その設定に従った構成で起動させることが可能となっている。また、この設定ファイルの中で起動時に実行するシェルスクリプトや、ホストWindows側との共有フォルダなども指定できる。
Windowsサンドボックスとは
Windowsサンドボックスは、仮想マシン環境ではあるが、Hyper-Vによる仮想マシンとは違う部分がある。1つは、Windows Defender Application Guard（WDAG、Windows 10 Pro／Enterpriseでのみ利用可能）などと同じく、専用の仮想マシン環境であり、さまざまなOSを起動できるような汎用の仮想化は行われていない。動作するのは、ホストWindowsと同じバージョンのゲストWindowsのみだ。
そのために、Windowsサンドボックスは、ホストWindows側から見て、インストール容量が小さく、メモリ消費量やシステム負荷が小さくて済むなどのメリットがある。これは、「Dynamically generated Image」「Smart memory management」「Integrated kernel scheduler」という技術によるものだ。
Dynamically generated Imageとは
Dynamically generated Imageとは、ホストWindowsの実行イメージからゲストWindowsの起動イメージを作るものである。しかし、ゲストWindowsは、インストール直後の「クリーン」なイメージを維持する必要がある。これに対してWindows側の実行イメージは、ソフトウェアのインストールやホットスポットなどの一時的な障害修正などで、変更される可能性があり、インストール直後のクリーンな状態をいつまでも維持できない。
Dynamically generated Imageでは、ホストWindows側と同一のファイルに対しては、そのファイルへのリンクのみを保持し、ホストWindows側で変更されてしまった部分に関しては、変更前のファイルをゲストWindows側の起動イメージに取り込んで保持する。一般にWindowsのシステムファイルは、差し替えなどが起こっても、前の状態に戻せるように、これを保存するため、変更前のシステムファイルが消去されることはない。このようにしてWindowsサンドボックスは、コンパクトな起動イメージを維持していく。
Dynamically generated Imageのイメージ
Dynamically generated Imageは、現在のホストWindowsのシステムファイルから実行イメージを作る。このとき、クリーンなWindowsを構成するのに必要なファイルのうち、ホストWindowsで書き換えられていないファイルはリンクとして記録し、変更があったファイルのみを実行イメージに含めることで、実行イメージのサイズを小さくしている。
Smart memory managementとは
Smart memory managementは、Windowsサンドボックスのメモリ消費量を小さく抑える仕組みだ。一般的な仮想マシンでは、お互いを分離するため、それぞれが個別のメモリ領域を持つ。しかしWindowsサンドボックスでは、ホストWindowsと同じゲストWindowsを動かすため、ホストWindowsがすでにメモリ中にロードした実行イメージ（プログラム部分）をWindowsサンドボックス側でも利用することで、メモリ占有量を小さくする。
Windowsサンドボックスの要求仕様では、必要メモリは最低8GBとなっているが、Microsoftによれば、4GBのPCでも、Windowsサンドボックスを起動することはできるという。ただしWindowsサンドボックスは、複数起動することはできず、一度に1つのインスタンスしか動作できない。
Windowsサンドボックスの実行モジュール
一般的な仮想マシン環境では、ゲストが同じWindowsであっても、メモリ内のイメージはそれぞれ別になる。これに対してWindowsサンドボックスでは、ホストとゲストで同じ実行モジュールを使う場合、Windowsサンドボックス側は、ホスト側でメモリに読み込まれたイメージをそのまま使う。これにより、占有メモリ量を大きく減らすことが可能になった。
Integrated kernel schedulerとは
Integrated kernel schedulerは、Windowsサンドボックス自体を1つのプロセスのようにホストWindows側でスケジューリングする技術だ。通常、仮想マシンのスケジューリングは、仮想マシン（仮想プロセッサ）単位でハイパーバイザーが行い、各仮想プロセッサの中で、ゲストOSが自身のアプリケーションのスケジューリングを行う。ハイパーバイザーが行うのは、優先度に応じ、同一優先度の中では公平な資源（実行時間）の割り当てであり、このようにして、実行時間という資源を管理する。
しかしWindowsサンドボックスでは、Windowsサンドボックス自体を1つのプロセスとしてホストWindowsがスケジューリングを行う。このため、ホスト側のプロセス／スレッドとWindowsサンドボックスプロセスとその内部のスレッドはホストWindowsでスケジューリングされる。
これにより、Windowsサンドボックス側の優先順位の低いプロセス／スレッドに対して、ホスト側の優先順位の高いプロセス／スレッドを優先させて実行でき、ホスト側のアプリケーションの動作に与える影響が少ない。また、Windowsサンドボックスが1つのプロセスとして管理されることで、通常アプリケーションを制御するのと同じ方法が利用でき、Windowsサンドボックス自体もホスト側から情報を得られる。
バッテリー駆動モードで動作可能
バッテリー駆動時には、Windowsサンドボックスは無制限に資源を使ってしまうのではなく、ホストWindowsと同様にバッテリー駆動モードで動作することができ、消費電力の削減を行うことが可能になる。
GPUの仮想化によって性能を維持
Windowsサンドボックスは、ホストWindowsが管理するGPUを仮想化してゲストWindows側で利用する。Windowsは、GPUをデスクトップの表示などに利用しており、GPU性能は、デスクトップ表示やWindows全体やアプリケーションの実行性能に影響する。仮想化されたGPU（Virtual GPU：vGPU）を使うことで、Windowsサンドボックスは、ホストWindowsと大きく変わらない実行性能を維持できる。
Windowsサンドボックスを有効にする
Windowsサンドボックスは、Windows 10 May 2019 Update（バージョン1903）以降で利用できる。ただし前述の通り、標準では有効になっていないため、以下の手順で有効にする必要がある。
BIOS／UEFIセットアップで仮想マシン支援機能の有効化が必要
Windowsサンドボックスは仮想マシン支援機能を使うため、BIOS設定などでIntel VTやAMD-Vなどを有効にしておく必要がある。これに関しては、メーカーやマザーボードごとに表記が違っているため、マニュアルなどで確認の上、設定を事前に行っておく。
すでにHyper-Vを利用しているなら、BIOS設定は行われているはずである。Nested Vectorizationを有効にできるハードウェアであれば、Hyper-Vのゲストパーティション内で動作するWindows 10上でWindowsサンドボックスを利用することも可能だ（ただしIntel CPUのみ）。
［コントロールパネル］の［プログラムと機能］で有効化
Windowsサンドボックスを有効にするには、［コントロールパネル］の「プログラムと機能］を開き、左ペインの［Windowsの機能の有効化または無効化］をクリックし、開いた［Windowsの機能］ダイアログで、「Windowsサンドボックス」のチェックボックスをオンにすればよい。これでWindowsサンドボックスのインストールが開始されて、［スタート］メニューに登録される。
［Windowsの機能］ダイアログ画面
Windowsサンドボックスを有効にするには、［コントロールパネル］の［プログラムと機能］を開き、左ペインの［Windowsの機能の有効化または無効化］をクリックし、開いた［Windowsの機能］ダイアログで、「Windowsサンドボックス」のチェックボックスをオンにする。
Windowsサンドボックスを設定する
次はWindowsサンドボックスの構成（設定）ファイルと、それによって設定されるネットワークやGPUなどの構成要素について見ていこう。
Windowsサンドボックスの構成ファイル「WSB」とは
Windowsサンドボックスには、専用の構成ファイル形式である「WSB」が定義されている。これを利用することで、ネットワークやvGPU利用の有／無、ホストWindowsとの共有フォルダなどを指定して起動させられる。また、WSBファイルでは、ログオンスクリプトを定義できるため、テスト環境の基本的な設定などを起動時に行わせることもできる。
Windowsサンドボックスは、起動イメージをユーザーが作成できないため、必要な環境を構築するには、ログオンスクリプトを使い、必要なアプリケーションのインストールやファイルのコピーなどを毎回行わなければならない。また、共有フォルダを使うことで、Windowsサンドボックス側からファイルをホストWindows側に残すことも可能になる。ただし、こうした設定や許可は常にホスト側への影響やリスクを考慮して行う必要がある。
WSBファイルの構造
下図は、WSBファイルのサンプルだ。このようにWSBは、XMLのようにタグを使って構造や情報の種類を示す。ただし、WSBファイル自体は、厳密な意味ではXMLではない。設定項目は大きく4つある。「ネットワーク」「仮想GPU」「共有フォルダ」「ログオンスクリプト」である（下表にタグの意味と設定値を示す）。
Windowsサンドボックスの設定ファイルの構成
Windowsサンドボックスの設定ファイルであるWSBは、タグ構造を利用する。設定項目は、「VGpu」「Networking」「MappedFolders」「LogonCommand」の大きく4つある。
| タグ | 意味 | 設定値 |
|---|---|---|
| <Configuration> | 設定全体を囲うタグ | なし |
| <VGpu> | 仮想GPU設定 | Enable：有効／Disable：無効／Default：デフォルト値（有効） |
| <Networking> | ネットワーク機能 | Enable：有効／Disable：無効／Default：デフォルト値（無効） |
| <MappedFolders> | 共有フォルダ設定全体を囲うタグ | なし |
| <MappedFolder> | 1つの共有フォルダ設定を囲うタグ | なし |
| <HostFolder> | ホスト側のフォルダパス | フォルダパス。UNCによりネットワークフォルダも可能 |
| <ReadOnly> | 読み取り専用の設定 | True：有効（読み取り専用）／False：無効（読み書き可能） |
| <LogonCommand> | ログオンコマンドを囲うタグ | なし |
| <Command> | ログオンコマンドの指定 | 起動するプログラムのコマンドライン |
| Windowsサンドボックスの設定ファイルのタグと設定値 | ||
このうち「ネットワーク」（<Network>タグ）と「仮想GPU」（<VGpu>タグ）に関しては、有効（Enable）／無効（Disable）が指定できるだけだ。ただしキーワードとしては初期値を表す「Default」も指定可能だ。現時点では、仮想GPUの「Default」は「Enable」に相当し、ネットワークでは「Disable」である。Defaultは、デフォルト値を意味するが、将来的にはデフォルト値が変更できるようになる可能性も考えられるので、禁止／許可に関しては、現時点ではDefaultを使わずに明確に書いておいた方がよいだろう。
ネットワークアダプターの構成
ネットワークでは、ホストWindows側に「Hyper-V Virtual Ethernet Adapter」がインストールされる。これを介して、Windowsサンドボックス側からは、ホストWindowsと同じネットワークアダプターが見えるようになる。ただし、仮想化されていて、割り当てられるIPアドレスなどはプライベートアドレスとなり、NATに類似した仕組みを介して、インターネット側をアクセスする。
ホスト側に作成されたHyper-V Virtual Ethernet Adapter
ホスト側には、Hyper-V Virtual Ethernet Adapterがネットワークデバイスごとに作られる。
なお、ゲストWindowsから見えるネットワークアダプターは、ホストWindowsと同じ構成となり、ホストWindows側に携帯電話ネットワーク（モバイルブロードバンド）アダプターがあれば、ゲストWindows側にも同様のアダプターが接続されているように見える。ホスト側で該当のアダプターが有効なら、Windowsサンドボックス側でも該当のアダプターが有効になる。
ゲストWindowsは、インターネット接続に当たり、ホストWindowsが使うインターネット接続を利用するが、ゲストWindows内のエクスプローラーからは、ホストWindowsが接続しているLAN内のPCは見えないようになっている。ただし、TCP/IPなどによる通信は可能で、IPアドレスを指定することで正しく通信が行える。
仮想GPUの設定
仮想GPUを「Disable」にすると、ソフトウェアによるレンダリング（WARP。Windows Advanced Rasterization Platform）が動作するようになる。WARPは、Direct3D 11ランタイムで導入されたソフトウェアレンダリングシステムで、Windows 7で導入された。ソフトウェアでハードウェアを代行するため、システム負荷は高くなる。なお、仮想GPUを使う場合でもWindowsサンドボックス側からは直接GPUは見えない。例えば、タスクマネージャーの［パフォーマンス］タブには、GPUが表示されない。
共有フォルダの設定
共有フォルダは複数指定でき、それぞれに読み出し専用かどうかを指定できる。指定されたフォルダは、Windowsサンドボックス内では、［デスクトップ］に直接表示される。つまり、［%UserProfile%\Desktop］フォルダ以下に指定したフォルダが置かれる。Windowsサンドボックスでは、必ず「WDAGUtilityAccount」というユーザーアカウントが作られ、このユーザーでログオンした状態となるため、前記のパスは、必ず以下のパスとなる。
C:\Users\WDAGUtilityAccount\Desktop
例えば、ホスト側の［C:\Temp\SandboxTest］フォルダを共有フォルダとして指定した場合、Windowsサンドボックス内では、以下のパスで共有フォルダにアクセスできる。
C:\Users\WDAGUtilityAccount\Desktop\SandboxTest
共有フォルダのパス指定には、UNCを使ったネットワークパスも指定できる。
個々の共有フォルダには、読み取り専用属性を指定でき、Windowsサンドボックス内からの書き込みを禁止することもできる。読み取り専用属性に「false」を指定して、書き込みを許可することもできる。書き込みを許可することにより、Windowsサンドボックス側からホストWindowsのファイルシステムの変更が可能になる。このため、Windowsサンドボックス内で実行するソフトウェアによっては問題が出る可能性もある。原則、読み出し専用としておくべきだろう。
ゲストWindowsのローカルディスク
Windowsサンドボックスは、約40GB容量を持つ「Microsoft仮想ディスク」が接続された状態で起動し、そのうち約3GB程度が利用され、約37GBが空き領域となる。これは、仮想ディスクであり、実体は、［C:\ProgramData\Microsoft\Windows\Containers\Sandboxes］フォルダ以下にあるvhdxファイルであると思われる。
ゲストWindowsのローカルディスク
ローカルディスクは約40GBの容量があり、そのうち3GB程度が使われている。実体は仮想HDファイルで、利用量に応じて仮想HDファイルが大きくなるため、未使用の段階では大きくファイルを占有することはない。
ログオンスクリプトを設定しよう
ログオンスクリプトは、実行したいプログラム名を1つ指定する。実際には、cmd.exeやpowershell.exeなどに引数を付けて起動する。ただし、このログオンスクリプトは起動したゲストWindows内で動作するため、引数に指定できるパスは、Windowsサンドボックス内のパスもしくは共有フォルダのパスになる。
ログオンスクリプト以前にファイルなどをWindowsサンドボックス側にコピーすることはできないため、共有フォルダにスクリプトなどを置き、これをcmd.exeなどのスクリプトパスとして指定することになる。なお、このログオンスクリプトは、管理者として実行される。また、ログオンスクリプトは、タグの構造上、複数の<command>タグが指定できそうだが、実際には、先頭にある<command>タグのみが実行され、2つ目以降の<command>タグは無視される。
共有フォルダの指定などにエラーがあった場合、起動時にメッセージボックスが表示され、起動が中止される。ただし、エラーがあることは通知されても、場所などは表示されないので、自分で探す必要がある。共有フォルダなどの指定は最初から多数のフォルダを指定するのではなく、WSBの編集、起動を繰り返して、段階的に追加していく方が、ミスが少ない。
ログオンスクリプトの実例を見てみよう
ゲストWindowsを設定できる唯一の方法がログオンスクリプトだ。ここでは、起動時にアプリケーションをインストールする方法などを試してみる。そのためには、最低でも1つ、Windowsサンドボックス側に共有ファイルを指定する。ホスト側の位置はどこでもいいが、広範囲にアクセスされないように、適当にフォルダを作って指定する。ここでは仮に［c:\temp\sandboxtest\Script］フォルダを共有することにする。この場合、Windowsサンドボックス内でのこのフォルダのパスは、以下のようになる。
%UserProfile%\Desktop\Script
ログオンスクリプトは、cmd.exeのバッチファイルとする。ログオンスクリプトに使うバッチファイルは、前述したホストWindows側のフォルダに保存する。ただし、このバッチファイルは実行時には、Windowsサンドボックス側のフォルダとなることに注意されたい。その他、評価に使うソフトウェアなどは、［Script］フォルダに保存しておく。
ログオンスクリプトでcmd.exeを指定した場合、デフォルトのカレントディレクトリである［C:\Windows\System32］（cmd.exeのフォルダ）がカレントフォルダに指定された状態でスクリプトが実行される。以前紹介したChocolatyを使うと、インターネット接続を利用して著名アプリケーションのインストールなどが可能になる（Chocolatyについては知っトクWindowsツール「コマンドでWindowsアプリを楽々管理『Chocolatey』」参照のこと）。
筆者が現在Windowsサンドボックス用に使っているログオンスクリプトが下のリストだ。このスクリプトでは、Chocolatyのインストールと、choco.exeコマンドによるGoogle ChromeおよびRuby言語のインストールを行っている。
rem Windowsサンドボックス用ログオンスクリプト
rem 共有フォルダからのコピーやアプリのインストールなど
rem 状態を監視したいので、@echo offはつけない
rem このスクリプトはSandboxの起動時に管理者権限で実行される
rem ネットワークが有効でインターネットアクセスが可能になっている必要がある（Chocolatyのため）
rem Chocolatyのインストール
"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy Bypass -Command "iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET "PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin"
rem ChocolatyでGoogle Chromeをインストール
choco.exe install -y -f googlechrome
rem 同 Rubyのインストール
choco.exe install -y -f ruby
rem Windowsサンドボックス内にテンポラリディレクトリ（c:\temp)を作成（終了時に消えるので注意）
mkdir c:\temp
rem 共有フォルダから必要なファイルをコピー（ダミー）
copy %userprofile%\Desktop\Data\file01.txt c:\temp
rem 共有フォルダからWindows Sysinternalsのsysmon64をコピー
copy %userprofile%\Desktop\Script\sysmon64.exe c:\temp
rem Windows 10の開発者モードをオン
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock /v AllowDevelopmentWithoutDevLicense /t REG_DWORD /d 1
rem sysmon64のインストール
c:\temp\sysmon64.exe -i
rem ウィンドウが閉じてメッセージが読めなくなるのを防ぐ
pause
上記のスクリプトでは、実行ファイルなどをコピーするだけで利用可能なアプリケーションを用意し、これを起動時にWindowsサンドボックス側に作った［C:\Temp］フォルダにコピーしている。Windowsサンドボックス側にコピーするのは、アプリケーションが起動時にカレントフォルダに書き込みなどを行う可能性もあるからだ。実行中に書き込みが行われないという確証があるなら、書き込みが禁止された［Script］フォルダ側に置いたままでも構わない（ただし、起動パスやパラメーターはWindowsサンドボックス側になることに注意）。
上記の例では、Windows Sysinternalsのシステム監視ツール「sysmon64.exe」をコピーして起動（インストール）している。その他、reg.exeコマンドで、Windows 10の開発者モードを有効に設定している。
高速に起動するとはいえ、比較対象は、Hyper-Vであり、Windowsサンドボックスで上記スクリプトの起動などに数分程度が必要となる。これは、Windowsサンドボックスが起動した後、ゲストWindows側でサービスの起動などが行われるからだ。Windows 10を再起動して直後にログオンしたのと同じ状態である。CPU性能はほぼホストと同じなので、同程度の起動時間がかかり、サービスなどの起動が終わったあとにログオンスクリプトが起動することに注意されたい。
Windowsサンドボックスを使えば、インターネットで流通しているソフトウェアのちょっとした評価などに利用できる。このときホスト側に全く影響が残らない点が一番のメリットだ。一部のオンラインソフトウェアは、インストール時に別のアプリをインストールしてしまうことがある。こうしたアプリの中には、主たるオンラインソフトウェアをアンインストールしても残り、削除が面倒なものも多い。また、「無料」をうたうソフトウェアの中には、情報を収集するなど、「いかがわしい」ものもないわけではない。
オンラインソフトウェアの利用は、効率的なPCの利用には不可欠ではあるが、そのインストールにはいくばくかのリスクが存在する。そんなとき、まずWindowsサンドボックスを使って「評価」を行うことが有効だ。
Copyright© Digital Advantage Corp. All Rights Reserved.