ここから本文です

「Device Guard」はWindows 10 Enterpriseの“限定”機能か、否か?

8/29(火) 8:10配信

@IT

●“Enterprise限定”の高度なセキュリティ機能として登場した「Device Guard」

Device Guardを構成したWindows 10 Enterpriseで許可されていないアプリケーションを実行しようとしたところ

 まずは、以下のWindows 10のエディションの比較表(MicrosoftのWebページ)をご覧ください。最新の情報が反映されている英語のオリジナルページ(例えば、Enterprise E3とEnterprise E5が区別されている)を見ることを推奨しますが、どちらの比較表でも「Device Guard(デバイスガード)」は、Windows 10のEnterpriseエディションとEnterpriseをベースにしたEducationエディションだけに提供されるセキュリティ機能として紹介されています。この比較表には含まれませんが、Device GuardはWindows Server 2016でもサポートされています。

 Device Guardは簡単に言うと、デバイスドライバやWin32アプリケーション、Windowsアプリ(ストアアプリやモダンアプリ、UWPアプリとも呼ばれます)の実行を「ポリシー(コード整合性ポリシー)」で許可または禁止できるWindows 10の新しいセキュリティ機能です。

 Device Guardは「仮想化ベースのセキュリティ(Virtualization-Based Security:VBS)」と呼ばれる、Hyper-Vの仮想化環境を活用した新しいOSの分離環境を使用します。VBSに依存するものとしては他に、資格情報を厳重に保管する「Credential Guard(資格情報ガード)」があり、こちらもWindows 10 EnterpriseとEducation限定の新しいセキュリティ機能となっています。

 Device Guardの公式ドキュメントは、以下のWebページで公開されています。このドキュメントを読んでも、ほとんどの人はDevice GuardがWindows 10 Enterprise限定(このドキュメントには明示されていませんが、EnterpriseベースのEducationも含む)のセキュリティ機能であると読み取ると思います。

 ここまでを踏まえた上で、今回取り上げるのは、Device Guardが実はWindows 10の全てのエディション(少なくともPC向けのWindows 10)に実装され、一部制限される部分はあるものの、全エディションで利用可能なセキュリティ機能だったという話です。筆者はつい先日まで“エディション限定機能”だと思い込んでいたのですが、どうやらそうではないようです。先に言っておきますが、今回もややこしい話になります。

●Windows 10 Sで経験した不思議体験、これはDevice Guardの亡霊か?

 Microsoftは2017年7月末に、主に教育分野向けのWindows 10の新しいエディション(SKU)である「Windows 10 S」のISOイメージをMSDN(Microsoft Developer Network)サブスクライバーに対して公開しました。また、8月に入ると、Windows 10 Pro、Pro Education、Enterprise、Educationの正規ライセンスを持つユーザーに対して、そのPCをWindows 10 Sにアップグレードしてテストできるツール(実体は「アップグレードアシスタント」によるダウンロードと新規インストール)を公開しました。

 皆さんは、Windows 10 Sについてご存じですか。「ストアから入手したアプリだけを実行でき、コマンドプロンプトやPowerShellは使えない」という特徴を知っている人も多いと思います。先に指摘しておきますが“ストアアプリだけを実行可能”という特徴から、Windows 8にあったARMプロセッサ版「Windows RT」の新しいバージョンと思っている人がいるかもしれませんが全く違います。

 Windows 10 Sは99%以上(この数字は単なる表現であり、適当なものです)がWindows 10 Proと同じものであり、実行可能な操作が制限され、ロックダウンされたものです。これについては、筆者の個人的な評価レポートをブログにまとめています。

 さて、Windows 10 Sで許可されていないアプリケーション(例えば、Windows標準の「コマンドプロンプト」)を実行しようとすると、メッセージが表示されて、ブロックされます(Microsoft Edge経由でダウンロードしたプログラムを実行しようとした場合は、もっとグラフィカルな表示になります)。メッセージこそ異なりますが、Device Guardでブロックされたときの様子とよく似ていませんか。

 実際、Device Guardを構成した場合と同様に、ブロックされた履歴はイベントログの「Microsoft-Windows-CodeIntegrity/Operational」ログに、ソース「CodeIntegrity」、イベントID「3081」のエラーとして記録されていました。エラーの中身は「that did not meet the Enterprise Signing Level requirements or violated code integrity policy.」(エンタープライズ署名レベルの要件を満たしていないか、コード整合ポリシーに違反しています)となっています。ちなみに、「イベントビューアー」の使用はWindows 10 Sでもブロックされません。

 MicrosoftはWindows 10 Sの提供に先立ち、Device Guardのコード整合性ポリシーを利用して、Windows 10 Sと同等のブロック機能をテストすることができる、カスタマイズ済みのコード整合性ポリシーを提供していました。以下のチュートリアルに「To do test your app, you can apply a Device Guard Code Integrity policy on a device that is running Windows 10 Pro」と書いてある通り、Device Guardのコード整合性ポリシーをWindows 10 Proに適用できるのです。チュートリアルに従って実際に試してみると、確かにブロックされました。ブロックされたときのメッセージは、Windows 10 EnterpriseでDevice Guardを構成したときと全く同じです。

・Test your Windows app for Windows 10 S[英語](Windows Dev Center)

●広義のDevice Guardと狭義のDevice Guard

 これはいったい、どういうことでしょうか。Device Guardは、エディション限定のセキュリティ機能だったはずです。ここからは、筆者の解釈も含まれます(ご注意ください)。

 詳しい手順は説明しませんが、Device Guardの主要な構成要素であるコード整合性ポリシーは、Windows PowerShellの「New-CIPolicy」コマンドレットなどを使用して作成できます。このコマンドレットは、Windows 10 Homeを除くPC向けのWindows 10とWindows Server 2016に含まれますが、その実行にはエディションの制限がかかっています。Windows 10 Enterprise/EducationとWindows Server 2016ではコード整合性ポリシーを作成できますが、その他のエディションでは実行がブロックされます。

 コード整合性ポリシーは「カーネルモードのコード整合性ポリシー(Kernel Mode Code Integrity Policy:KMCI)」と「ユーザーモードのコード整合性ポリシー(User Mode Code Integrity Policy:UMCI)」の2つを含みます。

 前者(KMCI)はカーネルモードで動作するデバイスドライバを制限し、後者(UMCI)はWin32アプリケーションとWindowsアプリを制限します。Device Guardの公式ドキュメントによると、KMCIの機能は、以前のWindowsから存在していたそうです(Windows 8.1 x64から要求されるようになったカーネルモードコード署名ポリシーによるデバイスドライバの制限だと思います)。また、UMCIの機能もWindows RTおよびWindows Phoneに提供されていたそうです。

 Windows 10で新しくなったのは、KMCIとUMCIのコード整合性ポリシーを企業独自に作成し、展開できるようになったこと。そして、KMCIに関してはVBS(仮想化ベースのセキュリティ)と組み合わせることで、保護をさらに強化できることです(これを「Hypervisor Code Integrity:HVCI」や「Hyper-Vコード整合性」と呼びます)。例えば、VBSと組み合わせると(つまり、HVCI)、KMCIのコード整合性ポリシーをUEFI(Unified Extensible Firmware Interface)でロックして、リモート(つまりグループポリシー設定)で解除できないようにすることができます。

 別の言い方をすれば、KMCIとUMCIのコード整合性ポリシーは「VBSがなくても使用できる」ということになります。VBSを使用しないなら、VBSのハードウェア要件(つまり、Hyper-Vのハードウェア要件)を満たす必要がありません。

 そして、Windows 10 S相当にするコード整合性ポリシーの動作を見る限り、VBSを使用しないコード整合性ポリシーは、EnterpriseとEducationだけには制限されないようなのです。試しに、筆者がWindows 10 EnterpriseのNew-CIPolicyコマンドレットで作成した独自のコード整合性ポリシーを、同じバージョン(ビルド)のWindows 10 Homeにスタンドアロンで構成してみたところ、Windows 10 HomeでもDevice Guardのコード整合性ポリシーが機能しました。

 なお、Windows 10 バージョン1607以降のEnterpriseおよびEducation、Windows Server 2016では、Hyper-Vを有効化することでVBSが自動的に組み込まれます。その後、グループポリシーやローカルポリシーを使用して、Device GuardやCredential Guardを構成します。

 Windows 10の他のエディションはVBSをサポートしておらず、Hyper-Vを有効化してもVBSは利用可能になりません。なお、Windows 10 バージョン1511までは、「分離ユーザーモード(Isolated User Mode)」という機能を有効化する必要がありました。

 今回の内容をまとめると、コード整合性ポリシーはDevice Guardとは無関係ではありませんが、Device Guardに含まれるセキュリティ機能の一部ではなく、Windows 10標準のセキュリティ機能ということになります。そして、VBSと組み合わせたHVCIで、KMCIの基準を引き上げることができます。全てのWindows 10エディションが備えるコード整合性ポリシーを「広義のDevice Guard」、エディション限定のものを「狭義のDevice Guard」と呼んでもよいかもしれません(広義と狭義の分類は、筆者の勝手な分類です)。

●1周回って何とやら……

 しかしながら、企業や組織で独自のコード整合性ポリシーを作成するためには、マスターコンピュータでNew-CIPolicyコマンドレットを実行する必要があり、それが可能なのはWindows 10 EnterpriseとEducationです。Windows Server 2016でもNew-CIPolicyコマンドレットは実行できますが、業務アプリケーションやWindowsアプリを含む、Windows 10向けの適切なポリシーを作成することは事実上できないでしょう。

 Windows 10 EnterpriseまたはEducationが導入済みであるということは、すなわち、他のクライアントもこれらのエディションを実行しているはず。そこから導かれる答えは、実質的に、Device GuardはWindows 10 EnterpriseとEducation限定のセキュリティ機能ということになります。ややこしいことをお話しして、お騒がせしましたが、結局のところ、そういうことです。

●筆者紹介
○山市 良(やまいち りょう)
岩手県花巻市在住。Microsoft MVP:Cloud and Datacenter Management(Oct 2008 - Sep 2016)。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『Windows Server 2016テクノロジ入門-完全版』(日経BP社)。

最終更新:8/29(火) 8:10
@IT