Device Guard 展開ガイド

Microsoft Device Guard は、ハードウェアとソフトウェアの両方のシステム整合性について強化された機能から構成される機能セットです。これらの機能は、Windows オペレーティング システムのセキュリティにとって革新的な機能です。最新の総合的なセキュリティをユーザーに提供するために、Windows 10 では Device Guard だけではなく、コード整合性機能と高度なハードウェア機能 (CPU の仮想化拡張機能、トラステッド プラットフォーム モジュール、第 2 レベルのアドレス変換など) も採用されています。このガイドでは、Device Guard の個々の機能と、それらの機能に関する計画、構成、展開の方法について説明します。

Device Guard について

現在のセキュリティの脅威は、これまでよりも強い攻撃的な特性を示しています。最近発生している悪意のある攻撃では、収益に対する損害、知的財産の盗難、標的となるシステムの低下に焦点を当てています。その結果、財政的な損失が発生します。現在の攻撃者の多くは、国家による支援を受けており、動機が不明で、サイバー テロのための莫大な予算を保持しています。これら脅威は、メール メッセージのようなシンプルな方法で企業に侵入します。また、企業が築いてきたソフトウェア資産の保護に関する評判に大きな傷を付け、財政面も重大な影響を受けます。Windows 10 には、いくつかの新しいセキュリティ機能が導入されています。これらのセキュリティ機能は、現在知られているほとんどの脅威を軽減する際に役立ちます。

毎日、300,000 を超える新しいマルウェアのバリエーションが見つかっていると推定されています。残念ながら現在の企業では、このような感染型のソフトウェアを検出し、その使用を防ぐために、旧式の方法を使っています。実際、現在の PC では、マルウェアの署名によって脅威が存在するかどうかが特定されるまで、実行されているすべてのソフトウェアを信頼しています。脅威の存在が確認されると、マルウェア対策ソフトウェアによって PC のクリーンアップが実行されます。場合によっては、悪意のあるソフトウェアの影響に気付いた後で、PC のクリーンアップが実行されることもあります。このような署名ベースのシステムでは、感染に対処し、特定の感染がもう一度発生しないようにすることを重視しています。こうしたモデルでは、マルウェアを検出するシステムは、悪意のあるソフトウェアが検出されることに依存しています。また、検出された後でのみ、クライアントに対して署名が発行され修復が行われます。これは、コンテンツが既に感染していることを意味します。マルウェアの検出とクライアントに対する署名の発行の間にかかる時間は、データが損失されてから、安全性が確保されるまでの間にかかった時間を表しています。

現在では、マルウェア対策ソリューションだけでなく、AppLocker などの "ホワイトリスト" テクノロジを利用することもできます。このテクノロジでは、単一のインスタンス (実行中のアプリケーションに対する包括的な許可規則または包括的な拒否規則) が実行されます。これは、署名ベースの検出よりも予防の効果は高いですが、継続的な保守が重要であり、必要な作業となります。Windows 10 では、このようなアプリケーションは、Microsoft Device Guard と共に展開した場合に最大の効果を発揮します。

Device Guard は、検出の後でブロックを実行する現在のモデルに比べ革新的な機能を備えています。また、Device Guard では信頼されているアプリケーションのみを実行することができます。この方法は、携帯電話のセキュリティを保護するための優れた感染予防対策として利用できる最適な方法です。Device Guard では、Windows オペレーティング システムでの信頼できないアプリケーションの処理方法が変更されています。これにより、防御が強化され、マルウェアの侵入が困難になっています。この新しい防止と検出のモデルによって、最新の脅威に対処するために必要なセキュリティが Windows クライアントに提供されます。このモデルを実装すると、実装したその日から、現在のほとんどの脅威は完全に役に立たないものとなります。

Device Guard の機能によって、Windows オペレーティング システムのセキュリティが大幅に改善されます。Device Guard は、新しい仮想化ベースのセキュリティ (VBS) オプションと、何も信頼しないことをベースとしたモバイル デバイス オペレーティング システム モデルを利用しており、これにより、防御力を高め、マルウェアの侵入を困難にしています。構成可能なコード整合性ポリシーを使うと、組織では、組織の環境で実行できるアプリケーションを厳密に選ぶことができます。構成可能なコード整合性は、Windows ストア アプリケーションに限定されていません。既にある未署名や署名済みの Win32 アプリケーションで使うこともできます。このとき、アプリケーションを再パッケージ化する必要はありません。また、組織が Device Guard で必要となるハードウェアを所有していない場合は、構成可能なコード整合性を個別の機能として展開することもできます。Windows 10 では、コード整合性と共に高度なハードウェア機能 (CPU の仮想化拡張機能、入出力メモリ管理ユニット (IOMMU)、トラステッド プラットフォーム モジュール (TPM)、第 2 レベルのアドレス変換 (SLAT) など) を利用して、最新の総合的なセキュリティをユーザーに提供します。構成可能なコード整合性および Credential Guard を使って展開した Device Guard は、現時点で組織が実装できる、最も効果的なクライアント側のセキュリティ展開となります。 このガイドでは、Device Guard が備えている個々の機能と、それらの機能に関する計画、構成、展開の方法について説明します。構成可能なコード整合性を使った Device Guard は、脅威を軽減するための他の Windows 機能 (Credential Guard や AppLocker など) と共に展開するように設計されています。

Device Guard の概要

Device Guard は、ハードウェアとソフトウェアの両方のシステム整合性について強化された機能から構成される機能セットです。これらの機能では、新しい仮想化ベースのセキュリティ オプションと、何も信頼しないことをベースとしたモバイル デバイス オペレーティング システム モデルが利用され、Windows オペレーティング システムのセキュリティが大幅に改善されます。このモデルの主要な機能は、"構成可能なコード整合性" と呼ばれる機能です。この機能によって、組織は、クライアント コンピューターでコードを実行できるソフトウェアや信頼できるソフトウェア発行者を厳密に選ぶことができます。この機能は、携帯電話のセキュリティを適切に実行するための機能ということができます。Device Guard を使うと、組織は既にある基幹業務 (LOB) アプリケーションに署名することもできます。これにより、組織独自のコードを信頼することができるようになります。アプリケーションを再パッケージ化する必要はありません。また、これと同じ署名方法を使うことで、個々のサード パーティ製アプリケーションを信頼することもできます。構成可能なコード整合性、Credential Guard、および AppLocker を使った Device Guard は、これまで Microsoft 製品が Windows クライアントに提供してきた中で最も完璧なセキュリティ防御として機能します。

CPU の仮想化拡張機能、IOMMU、SLAT などの高度なハードウェア機能によって、この新しいクライアント セキュリティ機能が実現されます。これらのハードウェア機能をコア オペレーティング システムとより深く統合することによって、Windows 10 ではこれらの機能を新しい方法で活用します。たとえば、Microsoft Hyper-V で仮想マシンの実行に使われる同一のタイプ 1 ハイパーバイザー テクノロジは、コア Windows サービスを仮想化ベースの保護コンテナーに分離するために使われます。これは、最新の総合的なセキュリティをユーザーに提供するために、Windows 10 で行われる高度なハードウェア機能とオペレーティング システムのより深い統合の一例にすぎません。現在では、これらのハードウェア機能は消費者向け PC と企業向け PC の市場で利用できます。これらのハードウェア機能については、「ハードウェアに関する考慮事項」セクションで詳しく説明します。

これらの新機能を備えているだけでなく、可能な限り安全性の高い Windows オペレーティング システムをユーザーに提供するために、既存のツールやテクノロジが Device Guard の一部のコンポーネントとして、この戦略的なセキュリティ機能に含まれています。Device Guard は、Windows オペレーティング システムで利用可能な、脅威に対抗するための他の機能と組み合わせて使われる、一連のクライアント セキュリティ機能を提供することを目的としています。脅威に対抗するための他の機能については、その一部をこのガイドで説明します。このガイドでは、各機能の概要だけでなく、それらの機能の構成と展開についても説明します。

構成可能なコード整合性

Windows オペレーティング システムは、ユーザー モードとカーネル モードという 2 つの動作モードで構成されています。オペレーティング システムの基盤はカーネル モードで実行されます。このモードでは、Windows オペレーティング システムはハードウェア リソースに直接接続されます。ユーザー モードは、主にアプリケーションを実行し、ハードウェア リソース要求のためにカーネル モードとの間でやり取りする情報の仲介を行います。たとえば、ユーザー モードで実行しているアプリケーションで追加のメモリが必要になると、ユーザー モード プロセスでは、RAM からのリソースを直接要求するのではなく、カーネル モードからのリソースを要求する必要があります。

コード整合性は、Windows オペレーティング システムのコンポーネントであり、Windows で実行されているコードが信頼でき安全であるかどうかを検証します。オペレーティング システムと同じように、Windows のコード整合性にも 2 つの主要なコンポーネント (カーネル モードのコード整合性 (KMCI) とユーザー モードのコード整合性 (UMCI)) が含まれています。KMCI は最新バージョンの Windows オペレーティング システムで使われ、署名されていない実行中のドライバーからカーネル モードを保護します。これは効果的ですが、マルウェアがオペレーティング システムのカーネル モード領域へ侵入する際に利用する手段は、ドライバーだけではありません。Windows 10 では、カーネル モード コードに関する標準がそのまま利用できるように定義されており、企業が独自の UMCI や KMCI の標準を設定するための方法も提供されています。コード整合性サービス自体を最初に行い、アプリケーションの実行許可を Windows クライアントで確認するためのポリシーでコード整合性を引き続き利用することにより、これまでの Windows リリースに比べて、Windows 10 はより安全なオペレーティング システムになりました。これまで、UMCI は Windows RT と Windows Phone デバイスでのみ利用できました。このため、これらのデバイスはウイルスやマルウェアに感染しづらいデバイスでした。Windows 10 では、これらと同じ優れた UMCI 標準を利用することができます。

従来、ほとんどのマルウェアは署名されていませんでした。コード整合性ポリシーを展開するだけで、組織では、署名されていないマルウェアに対する防御を直ちに行うことができます。現在発生している攻撃の 95% 以上を防ぐことが推定されています。コード整合性ポリシーを使うと、企業では、ユーザー モードとカーネル モードの両方で実行できるバイナリを、署名者からハッシュまでのレベルを対象として厳密に選ぶことができます。コード整合性が完全に実施されていれば、特定のアプリケーションや特定の署名のみを信頼し実行するように許可することによって、Windows のユーザー モードを携帯電話のように機能させることができます。この機能自体は、基本的に企業内のセキュリティを変更します。この追加のセキュリティ機能は、Windows アプリに限定されていません。また、既にある署名されていないアプリケーションと互換性を持つように、アプリケーションを作成しなおす必要はありません。Device Guard を有効にしなくても構成可能なコード整合性を実装できます。ただし、このコード整合性は、サポートされているハードウェアが利用可能な場合は、Device Guard と併用して実行するように設計されています。コード整合性ポリシーを構成、展開、管理する方法について詳しくは、「コード整合性ポリシー」セクションをご覧ください。

ハードウェアのセキュリティ機能と仮想化ベースのセキュリティ

Device Guard のコア機能と保護は、ハードウェア レベルで開始されます。SLAT テクノロジと仮想化拡張機能 (Intel バーチャライゼーション テクノロジ (VT-x) や AMD-V など) を備えたプロセッサが搭載されているデバイスでは、Windows のセキュリティを強化する仮想化ベースのセキュリティ (VBS) 機能を利用することができます。Device Guard では、VBS を活用して、オペレーティング システムのセキュリティや整合性にとって重要なコア Windows サービスを分離します。この分離によって、これらのサービスの脆弱性がユーザー モードとカーネル モードから除去されます。またこの分離は、現在使われているほとんどのマルウェアに対して、侵入不可能な壁として機能します。分離されたこれらのサービスの 1 つである、Windows コード整合性サービスによって、Device Guard におけるカーネル モードの構成可能なコード整合性機能が実行されます。これにより、カーネル モードの処理に侵入したコードは、コード整合性サービスを侵害することができなくなります。

VBS を採用している Windows 10 の他の機能として、Credential Guard があります。Credential Guard には、Active Directory ドメイン ユーザー向けの追加の保護機能が用意されています。この保護機能は、コード整合性などの Windows セキュリティ サービスをホストする仮想化コンテナーにドメイン資格情報を格納することによって実行されます。これらのドメイン資格情報をアクティブなユーザー モードやカーネル モードから分離することによって、盗難のリスクが大幅に低くなります。Credential Guard が Device Guard を補完する方法について詳しくは、「Credential Guard を使用した Device Guard」セクションをご覧ください。Credential Guard を有効にする方法については、「Credential Guard の有効化」セクションをご覧ください。

AppLocker を使用した Device Guard

AppLocker は Device Guard の新機能と見なすことはできませんが、実施されるコード整合性を完全に実装できない場合や、コード整合性の機能が目的のシナリオの一部を対象としていない場合に、AppLocker は Device Guard の機能を補助します。コード整合性ポリシーを AppLocker 規則と併用するシナリオには、さまざまなものがあります。組織で可能な最も厳しい制限レベルでコード整合性ポリシーを実施することをお勧めします。これにより、AppLocker を使ってさらに低いレベルに制限を微調整することができます。

  Device Guard の機能で AppLocker による補足が必要となる例として、 組織がユニバーサル アプリケーションを制限する場合が挙げられます。ユニバーサル アプリケーションは、信頼して実行できることが Microsoft によって検証されています。ただし組織では、特定のユニバーサル アプリケーションが 組織の環境で実行されるのを許可しない場合があります。AppLocker 規則を使うことで、このような場合に対応したコード整合性を 実施することができます。
 

組織では、AppLocker と Device Guard をサイド バイ サイドで実行する必要があります。これにより、両方のセキュリティ機能を同時に最大限に活用することが可能になり、できるだけ多くのデバイスに対して総合的なセキュリティを提供することができます。これらの機能に加え、企業における包括的なセキュリティ ポートフォリオを対象とした企業向けウイルス対策ソリューションを引き続き保持することをお勧めします。

Credential Guard を使用した Device Guard

Credential Guard は Device Guard に含まれる機能ではありませんが、多くの組織では、資格情報の盗難に対する追加の保護機能として、Credential Guard を Device Guard と共に展開する場合があります。カーネル モードのコード整合性における仮想化ベースの保護と同様に、Credential Guard ではハイパーバイザー テクノロジを利用して、ドメイン資格情報を保護します。この軽減策では、pass-the-hash や pass-the-ticket の手法を使った攻撃に対抗することに重点を置いています。Credential Guard と共に多要素認証を使うことによって、組織では、このような脅威に対する追加の保護機能を実現することができます。Credential Guard を Windows 10 Enterprise クライアントに展開する方法については、「Credential Guard の有効化」セクションをご覧ください。Credential Guard を クライアント側で有効にすることに加えて、組織では、CA とドメイン コントローラー レベルの両方で軽減策を展開し、資格情報の盗難を防止することもできます。これらの追加の軽減策に関する詳しい情報は、将来リリースされる予定です。

統合された管理機能

IT 担当者が通常利用するよく知られたエンタープライズ管理ツールやクライアント管理ツールを使うことによって、Device Guard の機能を簡単に管理できます。次の管理ツールを使って、Device Guard を有効にし、管理します。

  • グループ ポリシー。Windows 10 には、組織の構成可能なコード整合性ポリシーを構成して展開するための管理用テンプレートが用意されています。このテンプレートでは、有効にして展開するハードウェア ベースのセキュリティ機能を指定することもできます。これらの設定は、既にあるグループ ポリシー オブジェクト (GPO) と一緒に管理することができます。これにより、Device Guard の機能の実装が簡単になります。コード整合性やハードウェア ベースのセキュリティ機能だけでなく、グループ ポリシーを使うことで、カタログ ファイルを管理することもできます。カタログ ファイルについて詳しくは、「カタログ ファイル」セクションをご覧ください。

  • Microsoft System Center Configuration Manager。 System Center Configuration Manager を使うと、カタログ ファイル、コード整合性ポリシー、ハードウェア ベースのセキュリティ機能の展開と管理が簡単になります。また、バージョン管理も実行できます。System Center Configuration Manager を使ってカタログ ファイルを展開する方法について詳しくは、「System Center Configuration Manager を使ったカタログ ファイルの展開」セクションをご覧ください。

  • Microsoft Intune。Microsoft Intune の今後のリリースでは、組織は Intune を活用して、コード整合性ポリシーやカタログ ファイルの展開と管理を行うことができます。

  • Windows PowerShell。Windows PowerShell は、主にコード整合性ポリシーの作成とサービスの提供を行うために使います。これらのポリシーは、Device Guard での最も強力なコンポーネントとなります。コード整合性ポリシーの作成、監査、サービスの提供、実施の各方法についての詳しい手順は、「コード整合性ポリシー」セクションをご覧ください。

これらのオプションでは、既にあるエンタープライズ管理ソリューションを管理するために、使い慣れたエクスペリエンスと同じものが提供されます。Device Guard のハードウェア機能やコード整合性機能を組織で管理し展開する方法について詳しくは、「Device Guard の展開」セクションをご覧ください。

Device Guard の計画

このセクションでは、次のトピックについて説明します。

  • 企業向けコード整合性を展開する方法。組織で Device Guard を展開する場合、計画を立てて取り組む必要があります。このセクションでは、組織で企業向けコード整合性を展開する方法についての重要な推奨事項を説明します。

  • Device Guard 展開シナリオ。Device Guard の展開を計画するときは、組織内の各デバイスを展開シナリオに分類することをお勧めします。これらのシナリオによって、Device Guard を展開するためのロードマップが利用可能になります。

  • コード署名の導入。コード署名は、Device Guard によって実現されるセキュリティにとって重要な要素です。このセクションでは、コード署名のオプションと、各方法についてのメリットやデメリットについて説明します。

  • ハードウェアに関する考慮事項。Device Guard の機能の一部では、高性能ハードウェアが必要になります。このセクションでは、それらの各機能の要件、および次回ハードウェアを交換するときにどのようなハードウェアを探せばよいかについて説明します。

企業向けコード整合性を展開する方法

企業では、組織全体に Device Guard を展開するときに、一晩中かかるような展開は望んでいません。Device Guard の実装では、エンドユーザーと IT 担当者への影響を両方考慮して計画を立てる必要があります。また、Device Guard の機能を企業に展開するときは、エンド ユーザーのシステムが完全に機能し、新しいセキュリティ制限が実施できるように、計画を立て、段階的に取り組む必要があります。企業への Device Guard の展開を実施するには、次の重要なタスクを実行します。

  1. デバイスを類似の機能にグループ化する。コンピューターを、「Device Guard 展開シナリオ」で説明されているグループに分類します。この作業から、Device Guard を展開するためのロードマップが始まり、簡単な実装や難しい実装のグループが作成されます。このグループに基づいて、必要な Device Guard ポリシーの量を見積もります。最も簡単なソリューションは企業全体をロック ダウンすることですが、この方法は個々の部署のニーズを満たすものではありません。

    組織に対して適切なポリシーの数を算定するには、定義したグループを部署や役割に分割してみます。その後で、"各部署や役割がその作業を実行するために必要とするソフトウェアは何か?"、"他の部署のソフトウェアをインストールし実行できるようにする必要があるか?"、"アプリケーション カタログに適合した、基盤となるコード整合性ポリシーを作成する必要があるか?"、"ユーザーはすべてのアプリケーションをインストールできるようにするか、または “許可済み” の一覧からのみ選ぶことができるようにするか?"、"ユーザー独自の周辺機器の使用を許可するか?"、といった疑問点を確認します。これらの疑問点は、組織に必要なポリシーの数を算定する際に役立ちます。最後に、特権の追加のレベルを必要とするユーザーや部署に重点を置いて考察してみます。たとえば、他の部署がアプリケーション xyz のインストールと実行を行わない場合でも、部署 x に対しては、アプリケーション xyz のインストールと実行を許可する必要があるかどうかを考察します。許可を与え、それが正当と認められる場合は、そのグループに対して第 2 のコード整合性ポリシーが必要になります。それ以外の場合は、いくつかのポリシーをマージして、管理を簡単にすることができます。構成可能なコード整合性ポリシーについて詳しくは、「コード整合性ポリシー」セクションをご覧ください。

  2. "ゴールデン" PC からコード整合性ポリシーを作成する。デバイスのグループを作成した後で、それらのグループに適合するようにコード整合性ポリシーを作成することができます。このとき、会社のイメージを管理する場合と同じような方法で、コード整合性ポリシーを作成できます。これらのグループを分割し、各グループで必要となるソフトウェアやハードウェアと同じものを装備したゴールデン PC がセットアップされている場合は、各ゴールデン PC からコード整合性ポリシーを作成します。これらのコード整合性ポリシーを作成した後で、コード整合性ポリシーをマージしてマスター ポリシーを作成するか、各ポリシーを個別に管理および展開することができます。コード整合性ポリシーを作成する方法の詳しい手順については、「ゴールデン PC からのコード整合性ポリシーの作成」セクションをご覧ください。

  3. コード整合性ポリシーを監査してマージする。コード整合性ポリシーは、実施前に監査モードでテストすることをお勧めします。監査モードでは、管理者はコード整合性ポリシーをシステム上で実行できますが、実際には何もブロックされません。アプリケーションの実行を拒否するのではなく、ポリシーに対する例外が発生するたびに、イベントが記録されます。これにより、初期スキャンで検出されなかった問題に簡単に焦点を当てることができます。監査イベントを使って追加のコード整合性ポリシーを作成し、既にあるポリシーにマージすることができます。コード整合性ポリシーを監査する方法について詳しくは、「コード整合性ポリシーの監査」セクションをご覧ください。

  4. 現在署名されていない LOB アプリケーションを評価し、それらのアプリケーション用のカタログ ファイルを作成する。カタログ ファイルを使うと、組織では、デジタル署名されたバイナリが現在存在しないアプリケーションや、ユーザーがセカンダリ署名の追加を必要としているアプリケーションに署名することができます。このような アプリケーションは、自社製のアプリケーションまたはサードパーティ製のアプリケーションである場合があります。また、これらのアプリケーションは再パッケージ化する必要はありません。ハッシュ値よりも上位の規則のレベルでコード整合性ポリシーを作成すると、署名されていないアプリケーションは検出されません。これらのアプリケーションをコード整合性ポリシーの対象とするには、カタログ ファイルを作成、署名、展開するだけで十分です。カタログ ファイルについては、「カタログ ファイル」セクションをご覧ください。

  5. 適切なハードウェア セキュリティ機能を有効にする。「Device Guard 展開シナリオ」セクションに示した各種のデバイスで利用されるソフトウェアやハードウェアに関する整合性の構成は、それぞれ異なります。ハードウェア ベースのセキュリティ機能は、補助的な機能を提供するため、コード整合性ポリシーとは別に評価する必要があります。Device Guard でのハードウェア ベースのセキュリティ機能を構成する方法については、「ハードウェア ベースのセキュリティ機能の構成」セクションをご覧ください。

  6. コード整合性ポリシーとカタログ ファイルを展開する。必要なカタログ ファイルの作成と署名を行い、コード整合性ポリシーの作成と監査を実行すると、これらのカタログ ファイルやコード整合性ポリシーを段階的に展開する準備が整います。これらのコンポーネントは、テスト ユーザー グループに展開することを強くお勧めします。IT 部門がこれらのコンポーネントのテストや検査を行った後でも、このように展開することをお勧めします。これにより、カタログ ファイルとポリシーを広範に展開する前に、品質管理による最終的な検証が行われます。グループ ポリシーを使ってカタログ ファイルを展開する方法については、「グループ ポリシーを使ったカタログ ファイルの展開」セクションをご覧ください。コード整合性ポリシーの展開方法に関するその他の情報は、「グループ ポリシーを使ったコード整合性ポリシーの展開」セクションをご覧ください。

Device Guard 展開シナリオ

組織への Device Guard の展開を簡単に実行できるようにするために、このセクションで説明する展開シナリオに基づいて、デバイスをグループ化することをお勧めします。Device Guard は、“有効にする” だけで動作する機能ではありません。通常は、段階的な実装方法が必要になります。これらのシナリオが、Device Guard の展開方法のどの部分に適合するかを確認するには、「企業向けコード整合性を展開する方法 」セクションをご覧ください。

ワークロードが固定されたデバイス

ワークロードが固定されたデバイスの承認済みアプリケーションの一覧は、ほとんど変更されません。これらのアプリケーションは毎日同じタスクを実行するためです。このようなデバイスの例としては、キオスク デバイス、販売時点管理システム、およびコール センターの PC などがあります。これらのデバイスでは、Device Guard のすべての機能を簡単に使うことができます。また、管理やポリシーの変更はほとんど必要ありません。これらのデバイスには Device Guard を簡単に実装でき、継続的な管理はほとんど必要ありません。完全に実装された Device Guard では、ユーザーは、IT 部門がインストール、管理、信頼するアプリケーションのみを実行できます。

ワークロードが固定されたデバイスに適用できる Device Guard コンポーネントは、次のとおりです。

  • KMCI VBS 保護

  • 実施されている UMCI ポリシー

完全に管理されたデバイス

完全に管理されたデバイスでは、ソフトウェアのインストールや実行が IT 部門によって制限されていますが、ユーザーは追加のソフトウェアのインストールを要求できます。またこのデバイスでは、アプリケーション カタログに含まれている承認済みのソフトウェアの一覧が提供されます。このようなデバイスの例としては、会社が所有するロックダウンされたデスクトップ コンピューターやノート PC などがあります。これらのデバイスでは、基盤となる初期のコード整合性ポリシーが確立され、 コード整合性ポリシーが実施されます。IT 部門は、それらのポリシーを管理し、新しいアプリケーションが承認されたとき、または新しいアプリケーションが System Center Configuration Manager カタログに登録されたときにデバイスを更新します。

完全に管理されたデバイスに適用できる Device Guard コンポーネントは、次のとおりです。

  • KMCI VBS 保護

  • 実施されている UMCI ポリシー

このシナリオではアプリケーションの一覧が用意され、信頼されます。ユーザーが新しいアプリケーションを要求したときには、信頼ポリシーが常に再評価されます。これらすべてのデバイスでアプリケーションが信頼されていれば、そのアプリケーションに対する新しいユーザー要求が発生しても、ポリシーの更新 (アプリケーション カタログに合わせた更新) を行う必要はありません。この処理を、一元管理されているアプリケーション カタログに新しいアプリケーションを追加する場合のアプリケーションの配布準備プロセスに関連付けることもできます。完全に管理されたデバイスへの Device Guard の初期実装は簡単ですが、新たに要求され承認されたアプリケーションの信頼できる署名を管理するために、より多くの管理オーバーヘッドが必要になります。

緩やかに管理されたデバイス

緩やかに管理されたデバイスとは、会社が所有するデバイスですが、ユーザーはインストールするアプリケーションを完全に制御することができます。このようなデバイスでは、組織のウイルス対策ソリューションとクライアント管理ツールが実行されますが、ソフトウェア要求やコンプライアンス ポリシーによる制限を受けません。

緩やかに管理されたデバイスに適用できる Device Guard コンポーネントは、次のとおりです。

  • KMCI VBS 保護

  • 監査モードの UMCI ポリシー

Bring Your Own Device

Bring Your Own Device (BYOD) モデルでデバイスを管理するには、Device Guard は適切な方法ではありません。従業員が自分のデバイスを使うことが許可されているとき、それらのデバイスのユーザー モード アプリケーションを管理すると、業務以外でユーザー自身のデバイスを使うことが難しくなります。また、管理の観点から見ると、Device Guard の機能による管理作業が難しくなります。このグループのデバイスに対しては、Microsoft Intune などの MDM ベースの条件付きアクセス ソリューションを使った他の強化されたセキュリティ機能について検討してください。

コード署名の導入

構成可能なコード整合性ポリシーを正しく実装するためには、コード署名が不可欠です。これらのポリシーでは、独立系ソフトウェア ベンダーとユーザーの両方からの署名証明書を信頼します。Windows 10 では、すべての Windows ストア アプリケーションが署名されています。また、コード整合性ポリシーに署名証明書を追加することで、署名されている他のアプリケーションを簡単に信頼することもできます。

署名されていないアプリケーションの場合、コード整合性ポリシーでアプリケーションを信頼できるようにするための署名方法は複数あります。第 1 の方法は、従来の埋め込みコード署名です。社内に開発チームを持つ組織では、バイナリ コード署名をアプリケーションの開発プロセスに組み込み、署名証明書をコード整合性ポリシーに簡単に追加することができます。署名されていないアプリケーションに署名するための第 2 の方法は、カタログ ファイルを使うことです。Windows 10 では、ユーザーはアプリケーションのインストールと最初の実行を監視する際に、カタログ ファイルを作成できます。署名されていない既存の LOB アプリケーションやサード パーティ製アプリケーションに署名する方法については、「既存の基幹業務アプリケーション」セクションをご覧ください。

既存の基幹業務アプリケーション

これまで、既存の LOB アプリケーションについては、それらのアプリケーションが Windows ストア以外のソースによって署名されているのか、何も署名されていないのかどうかを判断し信頼するのが困難でした。Windows 10では、署名されていない既存の LOB アプリケーションやサード パーティ製アプリケーションには簡単に署名できます。この新しい署名方法では、アプリケーションを再パッケージ化する必要がありません。カタログ ファイルを使うと、管理者はインストールと最初の起動を監視するだけで、これらの署名されていないアプリケーションに署名できます。この監視情報を使うことで、管理者はカタログ ファイルを生成できます。カタログ ファイルは、検出されたバイナリに関するシンプルなハッシュ リストで、セキュア ハッシュ アルゴリズム 2 (SHA2) が適用されています。これらのバイナリのハッシュ値は、アプリケーションが更新されるたび更新されます。そのため、更新されたカタログ ファイルが必要になります。管理を簡略化するためには、埋め込みコード署名をアプリケーションの開発プロセスに組み込むことを検討してください。カタログ ファイルを生成する方法について詳しくは、「カタログ ファイル」セクションをご覧ください。

  

カタログ ファイルとは、個々のバイナリのハッシュ値の一覧です。スキャンしたアプリケーションが更新された場合は、 新しいカタログ ファイルを作成する必要があります。ただし、バイナリ署名が将来のアプリケーションでも強く推奨される方法であり、 これにより、カタログ ファイルが不要になる可能性があります。

 

カタログ ファイルを作成するとき、エンタープライズ公開キー基盤 (PKI) または購入したコード署名証明書を使って、カタログ ファイルに署名する必要があります。署名すると、コード整合性ポリシーでは、署名者やファイルの署名証明書を信頼することができます。カタログ ファイルの署名については、「カタログ ファイル」セクションをご覧ください。

アプリケーション開発

自社製のアプリケーションには、カタログ ファイルを使ってパッケージ化の後で署名することができますが、埋め込みコード署名をアプリケーションの開発プロセスに組み込むことを強くお勧めします。アプリケーションに署名するときは、アプリケーションの署名に使うコード署名証明書をコード整合性ポリシーに追加してください。これにより、将来のアプリケーションがその証明書で署名されている場合、コード整合性ポリシーではそのアプリケーションを信頼します。社内でのアプリケーションの開発プロセスにコード署名を埋め込むことは、コード整合性ポリシーを実装するときに、IT 部門で役立ちます。

ハードウェアに関する考慮事項

次回ハードウェアを交換するときに、どのハードウェア ベンダーのどのモデルを購入するかについては、慎重に検討してください。このことは、組織での Device Guard の実装作業を成功させるために極めて重要です。組織で交換するハードウェアについて適切な発注を決める際には、現在のハードウェアのライフ サイクルに合わせて、「企業向けコード整合性を展開する方法 」セクションで説明されている手順を検討してください。Device Guard は段階的に展開する必要があります。そのため、Device Guard の実装を系統的に計画する時間を取ることができます。

Device Guard の多様な機能を実装するには、さまざまなハードウェア機能が必要です。場合によっては、現在のハードウェアでいくつかの個別の機能を有効にすることができますが、有効にすることができない機能もあります。ただし、Device Guard を完全に実装する必要がある組織では、高度なハードウェア機能がいくつか必要になります。Device Guard コンポーネントで必要となるハードウェア機能について詳しくは、次の表をご覧ください。

要件説明

Windows 10 Enterprise

PC では、Windows 10 Enterprise が実行されている必要があります。

UEFI ファームウェア バージョン 2.3.1 以上とセキュア ブート

ファームウェアが UEFI バージョン 2.3.1 以上とセキュア ブートを使用していることを確認するには、Windows ハードウェア互換性プログラムの要件 System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby を使って検証します。

仮想化拡張機能

仮想化ベースのセキュリティをサポートするには、次の仮想化拡張機能が必要です。

  • Intel VT-x または AMD-V
  • Second Level Address Translation

ファームウェアのロック

ファームウェアのセットアップは、他のオペレーティング システムが起動しないように、また、UEFI の設定が変更されないようにするために、ロックする必要があります。また、ハード ドライブからの起動以外の起動方法を無効にする必要があります。

x64 アーキテクチャ

Windows ハイパーバイザー上で仮想化ベースのセキュリティが使用する機能は、64 ビット PC でのみ実行できます。

VT-d または AMD-Vi IOMMU (入出力メモリ管理ユニット)

Windows 10 では、IOMMU によって、メモリ攻撃からのシステムの回復性を強化します。¹

安全なファームウェア更新プロセス

ファームウェアが安全なファームウェア更新プロセスに準拠していることを確認するには、Windows ハードウェア互換性プログラムの要件 System.Fundamentals.Firmware.UEFISecureBoot を使って検証します。

 

Device Guard の展開

このセクションでは、次のトピックについて説明します。

  • ハードウェア ベースのセキュリティ機能の構成。このセクションでは、Device Guard でハードウェア ベースのセキュリティ機能を有効にする方法について説明します。また、Windows Management Infrastructure (WMI) と Msinfo32.exe を使って、機能が有効になっているかどうかを確認します。

  • カタログ ファイル。このセクションでは、カタログ ファイルの作成、署名、展開を行います。カタログ ファイルを展開するには、 グループ ポリシーと System Center Configuration Manager を使います。また、System Center Configuration Manager を使って、展開したカタログ ファイルのインベントリをレポート用に作成します。

  • コード整合性ポリシー。このセクションでは、署名済みまたは未署名の構成可能なコード整合性ポリシーに対して、作成、監査、サービスの提供、マージ、展開、削除を行う方法について説明します。

ハードウェア ベースのセキュリティ機能の構成

ハードウェア ベースのセキュリティ機能は、Device Guard のセキュリティ機能の大部分を構成します。VBS によって、Device Guard の最も重要な機能である、構成可能なコード整合性が強化されます。Device Guard でハードウェア ベースのセキュリティ機能を構成するには、次の 3 つの手順を実行します。

  1. ハードウェア要件を満たしており、有効になっていることを確認する。クライアント コンピューターに、これらの機能を実行するために必要なハードウェアが装備されていることを確認します。ハードウェア ベースのセキュリティ機能に関するハードウェア要件の一覧については、「ハードウェアに関する考慮事項」セクションをご覧ください。また、新しいハードウェアをお探しの場合は、「Device Guard 対応デバイス」で説明されているデバイスについて検討してください。

  2. 必要な Windows の機能を有効にする。ハードウェア ベースのセキュリティに必要な Windows の機能を有効にするには、いくつかの方法があります。必要となる Windows の機能について詳しくは、「仮想化ベースのセキュリティに必要な Windows の機能」セクションをご覧ください。

  3. 必要な機能を有効にする。必要なハードウェア機能と Windows の機能が有効になると、目的のハードウェア ベースのセキュリティ機能を有効にすることができます。UEFI セキュア ブートについては、「UEFI セキュア ブートの有効化」セクションをご覧ください。KMCI サービスの VBS 保護を有効にする方法については、「カーネル モードのコード整合性で仮想化ベースの保護を有効にする」セクションをご覧ください。また、Credential Guard を有効にする方法については、「Credential Guard の有効化」セクションをご覧ください。

仮想化ベースのセキュリティに必要な Windows の機能

VBS を有効にする前に、「ハードウェアに関する考慮事項」セクションで説明されているハードウェア要件に加えて、オペレーティング システムの特定の機能 (Microsoft Hyper-V と分離ユーザー モード) を有効にする必要があります (図 1 を参照)。

  

Windows PowerShell や展開イメージのサービスと管理を使って、 これらの機能を手動で構成できます。これらの方法に固有の情報については、Credential Guard に関するドキュメントをご覧ください。

 
図 1

図 1. VBS 用にオペレーティング システムの機能を有効にする

これらの機能を有効にすると、ハードウェア ベースのセキュリティ機能を必要に応じて構成できます。カーネル モードのコード整合性で仮想化ベースの保護を有効にする方法については、「カーネル モードのコード整合性で仮想化ベースの保護を有効にする」セクションをご覧ください。UEFI セキュア ブートを有効にする方法については、「Unified Extensible Firmware Interface セキュア ブートの有効化」セクションをご覧ください。また、Credential Guard を有効にする方法について詳しくは、「Credential Guard の有効化」セクションをご覧ください。

Unified Extensible Firmware Interface セキュア ブートの有効化

この作業を始める前に、ターゲット デバイスが、「ハードウェアに関する考慮事項」セクションに示されている UEFI セキュア ブートのハードウェア要件を満たしていることを確認してください。UEFI セキュア ブートを構成するための方法は 2 つあります。適切なレジストリ キーを手動で構成する方法、またはグループ ポリシーを使って展開する方法です。Windows 10 を実行しているコンピューターで UEFI セキュア ブートを手動で構成するには、次の手順を実行します。

  

セキュア ブートには、2 つのプラットフォーム セキュリティ レベルがあります。スタンドアロンのセキュア ブートと DMA 保護を使ったセキュア ブートです。DMA 保護によって追加のメモリ保護を実施できますが、DMA 保護は DMA 保護 (IOMMU) テクノロジを備えているプロセッサを搭載したシステムでのみ有効になります。IOMMU がなく、DMA 保護が無効になっている場合、ユーザーはドライバー ベースの攻撃に対して保護することができなくなります。

 
  1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard レジストリ サブキーに移動します。

  2. EnableVirtualizationBasedSecurity DWORD の値を 1 に設定します。

  3. RequirePlatformSecurityFeatures DWORD の値を必要に応じて設定します。

    • [セキュア ブート] オプションを有効にするには、この値を 1 に設定します。

    • [セキュア ブートと DMA 保護] オプションを有効にするには、この値を 2 に設定します。

  4. クライアント コンピューターを再起動します。

残念ながら、社内の保護されたコンピューターで上記の手順を手動で実行するには時間がかかる場合があります。グループ ポリシーを利用すると、より簡単に UEFI セキュア ブートを組織に展開することができます。この例では、DG Enabled PCs というテスト用の組織単位 (OU) を作成します。ポリシーを既にある OU にリンクする場合は、適切な名前が設定されたコンピューターのセキュリティ グループを使って GPO を限定するという方法を実行できます。

  

このセキュア ブートは、現在ユーザーに展開されているコンピューターで有効にする前に、テスト コンピューターのグループで試験的に有効にすることをお勧めします。

 

グループ ポリシーを使ってセキュア ブートを展開する

  1. 新しい GPO を作成するには、GPO をリンクする OU を右クリックして、[このドメインに GPO を作成し、このコンテナーにリンクする] をクリックします。

    図 2

    図 2. OU にリンクされる新しい GPO を作成する

  2. 新しい GPO に、"Contoso Secure Boot GPO Test" という名前を付けます。 この例では、GPO の名前として "Contoso Secure Boot GPO Test" を使います。この例で使われる名前の代わりに、任意の名前を指定することもできます。この名前は、既に利用している GPO の名前付け規則に合わせるのが理想的です。

  3. グループ ポリシー管理エディターを開くには、新しい GPO を右クリックし、[編集] をクリックします。

  4. 選んだ GPO で、[コンピューターの構成]、[管理用テンプレート]、[システム]、[Device Guard] の順に移動します。次に、[仮想化ベースのセキュリティを有効にする] を右クリックし、[編集] をクリックします。

    図 3

    図 3. VBS を有効にする

  5. [有効] オプションを選び、[プラットフォームのセキュリティ レベルを選択する] ボックスの一覧から [セキュア ブートと DMA 保護] を選びます。

    図 4

    図 4. セキュア ブートを有効にする

      

    DMA 保護と組み合わせると、Device Guard のセキュア ブートが最大限に活用されます。ハードウェアが DMA 保護に必要な IOMMU を備えている場合は、プラットフォームのセキュリティ レベルとして [セキュア ブートと DMA 保護] を選んでください。ハードウェアが IOMMU を備えていない場合、DMA 保護なしでセキュア ブートを活用できるようにする軽減策がいくつか用意されています。

     
  6. グループ ポリシー管理エディターを閉じて、Windows 10 のテスト コンピューターを再起動します。 この設定を構成すると、再起動したときに UEFI セキュア ブートが有効になります。

  7. テスト コンピューターのイベント ログを調べて、Device Guard の GPO を確認します。

    処理された Device Guard ポリシーはイベント ビューアーに記録されます。[アプリケーションとサービス ログ]、[Microsoft]、[Windows]、[DeviceGuard-GPEXT]、[稼働中] の順に移動し、確認してください。[仮想化ベースのセキュリティを有効にする] ポリシーが正常に処理されると、イベント ID 7000 が記録され、ログにはポリシー内で選んだ設定が含まれます。

カーネル モードのコード整合性における仮想化ベースのセキュリティを有効にする

この作業を始める前に、目的のコンピューターが「ハードウェアに関する考慮事項」セクションに示されている VBS のハードウェア要件を満たしていることを確認し、「仮想化ベースのセキュリティに必要な Windows の機能 」セクションで説明されている Windows の機能を有効にしてください。これらのことを確認したら、KMCI の仮想化ベースの保護を有効にすることができます。そのためには 2 つの方法 (適切なレジストリ サブキーを手動で構成する方法、またはグループ ポリシーを使って展開する方法) のどちらかを使います。

  

システム上のすべてのドライバーは、コード整合性での仮想化ベースの保護に対応している必要があります。対応していない場合は、システムでエラーが発生する可能性があります。この仮想化ベースの保護は、展開済みの実際のコンピューターで有効にする前に、テスト コンピューターのグループで有効にすることをお勧めします。

 

KMCI の仮想化ベースの保護を手動で構成するには:

  1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard レジストリ サブキーに移動します。

  2. HypervisorEnforcedCodeIntegrity DWORD の値を 1 に設定します。

  3. クライアント コンピューターを再起動します。

社内の保護されたコンピューターで上記の手順を手動で実行するには時間がかかる場合があります。代わりに、グループ ポリシーを使って、KMCI の仮想化ベースの保護を展開してください。この例では、DG Enabled PCs というテスト OU を作成し、GPO のリンクに使います。テスト OU を作成せずに、ポリシーを既にある OU にリンクする場合は、適切な名前が設定されたコンピューターのセキュリティ グループを使って GPO を限定するという方法を実行できます。

  

この仮想化ベースの保護は、現在ユーザーに展開されているコンピューターで有効にする前に、テスト コンピューターのグループで試験的に有効にすることをお勧めします。テストを行わないと、この仮想化ベースの保護が原因でシステムが不安定になり、最終的にはクライアント オペレーティング システムでエラーが発生する可能性があります。

 

グループ ポリシーを使って KMCI の VBS を構成するには:

  1. 新しい GPO を作成します。そのためには、GPO をリンクする OU を右クリックして、[このドメインに GPO を作成し、このコンテナーにリンクする] をクリックします。

    図 5

    図 5. OU にリンクされる新しい GPO を作成する

  2. 新しい GPO に "Contoso VBS CI Protection GPO Test" という名前を付けます。

    この例では、GPO の名前として "Contoso VBS CI Protection GPO Test" を使います。この例で使われる名前の代わりに、任意の名前を指定することもできます。この名前は、既に利用している GPO の名前付け規則に合わせるのが理想的です。

  3. グループ ポリシー管理エディターを開きます。そのためには、新しい GPO を右クリックし、[編集] をクリックします。

  4. 選んだ GPO で、[コンピューターの構成]、[管理用テンプレート]、[システム]、[Device Guard] の順に移動します。次に、[仮想化ベースのセキュリティを有効にする] を右クリックし、[編集] をクリックします。

    図 6

    図 6. VBS を有効にする

  5. [有効] オプションを選んで、[コードの整合性に対する仮想化ベースの保護を有効にする] チェック ボックスをオンにします。

    図 7

    図 7. KMCI の VBS を有効にする

  6. グループ ポリシー管理エディターを閉じて、Windows 10 のテスト コンピューターを再起動します。 この設定を構成すると、再起動したときに KMCI の VBS が有効になります。

  7. テスト クライアントのイベント ログを調べて、Device Guard の GPO を確認します。

    処理された Device Guard ポリシーはイベント ビューアーに記録されます。[アプリケーションとサービス ログ]、[Microsoft]、[Windows]、[DeviceGuard-GPEXT]、[稼働中] の順に移動し、確認してください。[仮想化ベースのセキュリティを有効にする] ポリシーが正常に処理されると、イベント ID 7000 が記録され、ログにはポリシー内で選んだ設定が含まれます。

Credential Guard の有効化

Credential Guard によって、ドメイン ユーザー専用の資格情報保護の層が追加されます。この層では、仮想化されたコンテナー内に資格情報が格納され、カーネル モードやユーザー モードのオペレーティング システムとは切り離されます。これにより、侵害されたシステムでは資格情報にアクセスするのが難しくなります。Credential Guard をクライアント側で有効にすることに加えて、組織では、証明機関とドメイン コントローラー レベルの両方で追加の軽減策を展開し、資格情報の盗難を防止することもできます。これらの追加の軽減策に関する詳しい情報は、将来リリースされる予定です。

この作業を始める前に、目的のシステムが「ハードウェアに関する考慮事項」セクションに示されている VBS のハードウェア要件を満たしていること、および「仮想化ベースのセキュリティに必要な Windows の機能 」セクションで説明されている Windows の機能が有効になっていることを確認します。これらのことを確認したら、Credential Guard を手動で有効にすることができます。そのためには、適切なレジストリ サブキーを構成するか、グループ ポリシーによる展開を利用します。

Credential Guard の VBS を手動で構成するには:

  1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa レジストリ サブキーに移動します。

  2. LsaCfgFlags DWORD の値を 1 に設定します。

  3. クライアント コンピューターを再起動します。

手動による展開では不要な時間がかかるため、この方法を利用しない場合は、グループ ポリシーを使って、Credential Guard を組織に展開します。この例では、DG Enabled PCs というテスト OU を作成します。Credential Guard を有効にするには、任意の OU にリンクして、セキュリティ グループを使って GPO の適用を限定することができます。

  

コンピューターをドメインに参加させる前に Credential Guard を有効にして、すべての資格情報が適切に保護されることを確認するようにお勧めします。イメージング処理中に適切なレジストリ サブキーを設定することは、この保護を実現する場合に適した方法です。

 

グループ ポリシーを使って Credential Guard を有効にするには:

  1. 新しい GPO を作成します。そのためには、GPO をリンクする OU を右クリックして、[このドメインに GPO を作成し、このコンテナーにリンクする] をクリックします。

    図 8

    図 8: OU にリンクされる新しい GPO を作成する

  2. 新しい GPO に、"Contoso Credential Guard GPO Test" という名前を付けます。

    この例では、GPO の名前として "Contoso Credential Guard GPO Test" を使います。この例で使われる名前の代わりに、任意の名前を指定することもできます。この名前は、既に利用している GPO の名前付け規則に合わせるのが理想的です。

  3. グループ ポリシー管理エディターを開きます。そのためには、新しい GPO を右クリックし、[編集] をクリックします。

  4. 選んだ GPO で、[コンピューターの構成]、[管理用テンプレート]、[システム]、[Device Guard] の順に移動します。次に、[仮想化ベースのセキュリティを有効にする] を右クリックし、[編集] をクリックします。

    図 9

    図 9: VBS を有効にする

  5. [有効] オプションを選んで、[Credential Guard を有効にする] チェック ボックスをオンにします。

    図 10

    図 10: Credential Guard を有効にする

  6. グループ ポリシー管理エディターを閉じて、Windows 10 のテスト コンピューターを再起動します。

      

    既定のプラットフォームのセキュリティ レベルは、[セキュア ブート] です。保護されるコンピューターで IOMMU が利用できる場合は、[セキュア ブートと DMA 保護] を選んで、Credential Guard によって利用可能になる軽減策を最大限に活用することをお勧めします。

     
  7. テスト クライアントのイベント ログを調べて、Device Guard の GPO を確認します。

  

処理されたすべての Device Guard ポリシーはイベント ビューアーに記録されます。[アプリケーションとサービス ログ]、[Microsoft]、[Windows]、[DeviceGuard-GPEXT]、[稼働中] の順に移動し、確認してください。

 

Credential Guard のしくみ、および追加の構成オプションについて詳しくは、Credential Guard に関するドキュメントをご覧ください。

有効にした Device Guard のハードウェア ベースのセキュリティ機能を検証する

Windows 10 および Windows Server 2016 以降には、Device Guard に関連するプロパティや機能の WMI クラスである、Win32_DeviceGuard があります。このクラスは、管理者特権の Windows PowerShell セッションから照会することができます。そのためには、次のコマンドを実行します。

Get-CimInstance –ClassName Win32_DeviceGuard –Namespace root\Microsoft\Windows\DeviceGuard

  

WMI クラス Win32_DeviceGuard は、Windows 10 の Enterprise エディションでのみ利用できます。

このコマンドの出力では、利用可能なハードウェア ベースのセキュリティ機能の詳細、およびそれらの機能のうち現在有効になっている機能の詳細が示されます。各プロパティの説明について詳しくは、表 1 をご覧ください。

 

表 1. Win32_DeviceGuard のプロパティ

プロパティ説明有効な値
AvailableSecurityPropertiesこのフィールドは、Device Guard の関連するセキュリティ プロパティの状態を列挙し、報告する際に役立ちます。
  • 0. この値が設定されている場合は、デバイスには関連するプロパティがありません。

  • 1. この値が設定されている場合は、ハイパーバイザーのサポートを利用できます。

  • 2. この値が設定されている場合は、セキュア ブートを利用できます。

  • 3. この値が設定されている場合は、DMA 保護を利用できます。

InstanceIdentifier特定のデバイスに固有の文字列。WMI によって決定されます。
RequiredSecurityPropertiesこのフィールドでは、仮想化ベースのセキュリティを有効にするために必要なセキュリティ プロパティが説明されます。
  • 0. セキュリティ プロパティは必要ありません。

  • 1. この値が設定されている場合は、セキュア ブートが必要です。

  • 2. この値が設定されている場合は、DMA 保護が必要です。

  • 3. この値が設定されている場合は、セキュア ブートと DMA 保護の両方が必要です。

SecurityServicesConfiguredこのフィールドには、Credential Guard または HVCI サービスが構成されているかどうかが示されます。
  • 0. サービスは構成されていません。

  • 1. この値が設定されている場合は、Credential Guard が構成されています。

  • 2. この値が設定されている場合は、HVCI が構成されています。

SecurityServicesRunningこのフィールドには、Credential Guard または HVCI サービスが実行中であるかどうかが示されます。
  • 0. 実行中のサービスはありません。

  • 1. この値が設定されている場合は、Credential Guard が実行されています。

  • 2. この値が設定されている場合は、HVCI が実行されています。

Versionこのフィールドには、WMI クラスのバージョンが示されます。現在有効な値は 1.0 だけです。
VirtualizationBasedSecurityStatusこのフィールドには、VBS が有効になっているかどうか、また実行中であるかどうかが示されます。
  • 0. VBS は有効になっていません。

  • 1. VBS は有効になっていますが、実行されていません。

  • 2. VBS は有効になっており、実行されています。

PSComputerNameこのフィールドには、コンピューター名が示されます。コンピューター名の有効な値がすべて示されます。

 

他の方法を使って、利用可能な Device Guard の機能や有効になっている Device Guard の機能を判断するには、管理者特権の PowerShell コマンド セッションから msinfo32.exe を実行します。このプログラムを実行すると、図 11 に示すように、[システムの概要] セクションの下部に Device Guard のプロパティが表示されます。

図 11

図 11: [システムの概要] に表示される Device Guard のプロパティ

カタログ ファイル

システムで Device Guard を実施する場合、信頼するすべてのアプリケーションには署名がされていること、またはそのバイナリ ハッシュがコード整合性ポリシーに追加されていることが必要となります。多くの組織では、このことが、署名されていない LOB アプリケーションを検討する際に問題となる場合があります。このようなアプリケーションの再パッケージ化や署名を行う必要があるという要件を回避するために、Windows 10 には Package Inspector と呼ばれるツールが用意されています。Package Inspector は、展開されるバイナリ ファイルや実行されるバイナリ ファイルのインストール プロセスを監視します。ツールがこのようなファイルを検出すると、カタログ ファイルに列挙されます。これらのカタログ ファイルを使うと、既にある署名されていないアプリケーションが、自社製であっても、サード パーティ製であっても信頼することができます。また、署名されているアプリケーションの署名者は信頼しないが、そのアプリケーション自体を信頼する必要がある場合に、該当するアプリケーションを信頼することもできます。カタログ ファイルを作成すると、これらのファイルを署名したり、署名証明書を既にあるコード整合性ポリシーに追加したり、カタログ ファイル自体をクライアントに配布したりすることができます。

  

カタログ ファイルを作成し使うには、Windows 10 または Windows Server 2016 の Enterprise エディションが必要になります。

 

カタログ ファイルの作成

カタログ ファイルの作成は、署名されていないアプリケーションをコード整合性ポリシーに追加するための最初の手順です。カタログ ファイルを作成するには、次の各コマンドを管理者特権の Windows PowerShell セッションにコピーし、それぞれの手順を実行します。

  

名前付け規則が確立されていると、今後、展開済みのカタログ ファイルを簡単に検出できます。このガイドでは、*-Contoso.cat を名前付け規則として使います。名前付け規則がカタログ ファイルのインベントリ作成や検出に役立つ理由について詳しくは、「System Center Configuration Manager を使ったカタログ ファイルのインベントリの作成」セクションをご覧ください。

 
  1. コード整合性ポリシーが監査モードで現在実行されていることを確認します。

    Package Inspector は、インストール プロセス中にコンピューターから削除されたインストール ファイルを常に検出できるわけではありません。これらのバイナリ ファイルも信頼するためには、「ゴールデン PC からのコード整合性ポリシーの作成」セクションと「コード整合性ポリシーの監査」セクションで作成し、監査の対象としたコード整合性ポリシーを、監査モードで、Package Inspector を実行しているシステムに展開してください。

      

    この作業は、実施済みの Device Guard ポリシーが動作しているシステムでは実行しないでください。ポリシーが監査モードで動作している場合にのみ実行してください。ポリシーが現在実施されている場合は、アプリケーションをインストールし実行することはできません。

     
  2. Package Inspector を起動し、C: ドライブをスキャンします。

    PackageInspector.exe Start C:

      

    Package inspector は、すべてのローカル ドライブでのインストールを監視できます。この例では、アプリケーションを C ドライブにインストールしますが、他のドライブを使うこともできます。

     
  3. インストール メディアを C: ドライブにコピーします。

    インストール メディアを C: ドライブにコピーすることによって、Package Inspector は実際のインストーラーを検出し、カタログ化します。この手順を省略すると、将来のコード整合性ポリシーでは、アプリケーションを信頼して実行しますが、インストールしない可能性があります。

  4. アプリケーションをインストールし起動します。

    アプリケーションを C: ドライブにインストールします。インストールが完了したら、アプリケーションを起動して、製品の更新プログラムがインストールされ、ダウンロード可能なコンテンツがスキャン中に取得されることを確認します。完了したら、アプリケーションを終了して再起動し、スキャンによってすべてのバイナリが取得されたことを確認します。

      

    Package Inspector の実行中に動作するすべてのバイナリは、カタログ内に取得されます。そのため、不適切なバイナリを信頼するというリスクを最小限に抑えるために、スキャン中には追加のインストールや更新プログラムを実行しないでください。また、複数のアプリケーションを 1 つのカタログ ファイルに追加する場合は、現在のスキャンが実行されているときに、インストールと実行の手順を繰り返してください。

     
  5. スキャンを停止し、定義ファイルとカタログ ファイルを生成します。 アプリケーションのインストールと初期セットアップが完了したら、Package Inspector によるスキャンを停止し、次のコマンド使って、デスクトップでカタログ ファイルと定義ファイルを生成します。

    $ExamplePath=$env:userprofile+"\Desktop"

    $CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"

    $CatDefName=$ExamplePath+"\LOBApp.cdf"

    PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName

  

このスキャンによって、検出された各バイナリ ファイルのハッシュ値がカタログ化されます。スキャンされたアプリケーションが更新された場合は、この手順をもう一度実行して、新しいバイナリのハッシュ値を信頼します。

 

上記の手順が完了すると、ファイルがデスクトップに保存されます。このカタログ ファイルをコード整合性ポリシーで信頼するには、最初にカタログに署名する必要があります。その後で、コード整合性ポリシーに署名証明書を含めることができます。また、カタログ ファイルを個々のクライアント コンピューターに配布することもできます。カタログ ファイルは、証明書と SignTool.exe を使って署名することができます。SignTool.exe は、Windows SDK で利用できる無料のツールです。SignTool.exe でカタログ ファイルに署名する方法について詳しくは、「SignTool.exe を使ったカタログへの署名」セクションをご覧ください。

SignTool.exe を使ったカタログへの署名

Device Guard を使うと、組織では、既にある署名されていない LOB アプリケーションに対する署名や信頼を簡単に実行することができます。このセクションでは、PackageInspector.exe を使って、前のセクションで生成したカタログ ファイルに署名します。カタログ ファイルを作成する方法については、「カタログ ファイルの作成」セクションをご覧ください。この例では、次のものが必要です。

  • SignTool.exe。Windows ソフトウェア開発キット (SDK - Windows 7 以降) に付属しています。

  • カタログ ファイルの作成」セクションで作成したカタログ ファイル、または既に作成されている他のカタログ ファイル。

  • 内部証明機関 (CA) よって発行されたコード署名証明書、または購入したコード署名証明書。

コード署名証明書を持っていない場合は、「Device Guard のコード署名証明書の作成」セクションをご覧になり、コード署名証明書の作成方法のチュートリアルを確認してください。「Device Guard のコード署名証明書の作成」セクションで作成した証明書を使うだけでなく、この例では、「カタログ ファイルの作成」セクションで作成したカタログ ファイルに署名します。これとは異なる証明書やカタログ ファイルを使っている場合、次の手順では、変数や証明書を適切なものに置き換えてください。既にあるカタログ ファイルに署名するには、次の各コマンドを管理者特権の Windows PowerShell セッションにコピーします。

  1. 使われる変数を初期化します。

    
    $ExamplePath=$env:userprofile+"\Desktop"
    
    
    
    $CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"
    
    
      

    この例では、「カタログ ファイルの作成」セクションで作成したカタログ ファイルを使います。他のカタログ ファイルに署名する場合は、$ExamplePath 変数と $CatFileName 変数を適切な値に置き換えてください。

     
  2. コード署名証明書をインポートします。 カタログ ファイルの署名に使うコード署名証明書を、署名するユーザーの個人用ストアにインポートします。この例では、「Device Guard のコード署名証明書の作成」セクションで作成した証明書を使います。

  3. Signtool.exe を使ってカタログに署名します。

    
    <Path to signtool.exe> sign /n "ContosoDGSigningCert" /fd sha256 /v $CatFileName
    
    
      

    <Path to signtool.exe> 変数には、Signtool.exe ユーティリティへの完全なパスを指定します。ContosoDGSigningCert は、カタログ ファイルへの署名に使う証明書のサブジェクト名です。この証明書は、カタログ ファイルへの署名を実行するコンピューター上にある個人用の証明書ストアにインポートします。

     
      

    Signtool.exe と他のすべてのスイッチについて詳しくは、MSDN 署名ツールに関するページをご覧ください。

     
  4. カタログ ファイルのデジタル署名を確認します。 カタログ ファイルを右クリックし、[プロパティ] をクリックします。図 12 に示すように、[デジタル署名] タブで、sha256 アルゴリズムの署名証明書が存在することを確認します。

    図 12

    図 12: 署名証明書が存在することを確認する

  5. カタログ ファイルを C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} にコピーします。

    テストを目的としている場合、署名されたカタログ ファイルを目的のフォルダーに手動でコピーできます。大規模な実装の場合は、グループ ポリシーのファイル基本設定を使って適切なカタログ ファイルを必要なすべてのコンピューターにコピーするか、企業向けのシステム管理製品 (System Center Configuration Manager など) を使うことをお勧めします。これにより、カタログのバージョン管理も簡略化されます。

グループ ポリシーを使ったカタログ ファイルの展開

カタログ ファイルを簡単に管理するために、グループ ポリシーの基本設定を使って、カタログ ファイルを組織内の適切な PC に展開することができます。次の手順では、署名されたカタログ ファイル (LOBApp-Contoso.cat) を、GPO (Contoso DG Catalog File GPO Test) がリンクされているテスト OU (DG Enabled PCs) に展開する方法について説明します。

  

このチュートリアルでは、署名済みのカタログ ファイルが既に作成されており、グループ ポリシーの展開をテストする Windows 10 クライアント PC が利用可能になっている必要があります。カタログ ファイルの作成と署名方法について詳しくは、「カタログ ファイル」セクションをご覧ください。

 

グループ ポリシーを使ってカタログ ファイルを展開するには:

  1. ドメイン コントローラーまたはクライアント PC (リモート サーバー管理ツールツール (RSAT) がインストールされていること) から、グループ ポリシー管理コンソール (GPMC) を開きます。そのためには、GPMC.MSC を実行するか、「グループ ポリシーの管理」を検索します。

  2. 新しい GPO を作成します。そのためには、図 13 に示すように、"DG Enabled PCs" OU を右クリックして、[このドメインに GPO を作成し、このコンテナーにリンクする] をクリックします。

      

    "DG Enabled PCs" OU は、このセクションで作成したテスト GPO のリンク先となるサンプルの OU です。任意の OU の名を使うことができます。また、「企業向けコード整合性を展開する方法 」セクションで説明した方法に基づいたポリシーの区分方法を検討している場合は、セキュリティ グループをフィルター処理することもできます。

     
    図 13

    図 13: 新しい GPO を作成する

  3. 新しい GPO に、"Contoso DG Catalog File GPO Test" という名前を付けます。

    この例では、GPO の名前として "Contoso DG Catalog File GPO Test " を使います。この例で使われる名前の代わりに、任意の名前を指定することもできます。

  4. グループ ポリシー管理エディターを開きます。そのためには、新しい GPO を右クリックし、[編集] をクリックします。

  5. 選んだ GPO で、[コンピューターの構成]、[基本設定]、[Windows の設定]、[ファイル] の順に移動します。図 14 に示すように、[ファイル] を右クリックし、[新規] をポイントして、[ファイル] をクリックします。

    図 14

    図 14: 新しいファイルを作成する

  6. カタログ ファイル共有を構成します。

    この設定を使って、LOBApp-Contoso.cat の一貫した展開を実現するには、ソース ファイルが、展開の対象となるすべてのコンピューター アカウントからアクセスできる共有に保存されている必要があります。この例では、\\Contoso-Win10\Share という Windows 10 クライアント コンピューター上の共有を使います。展開されるカタログ ファイルは、この共有にコピーされます。

  7. バージョンの一貫性を維持するには、[新しいファイルのプロパティ] ダイアログ ボックス (図 15) で、[操作] の一覧から [置換] を選びます。これにより、最新バージョンが常に使われます。

    図 15

    図 15: 新しいファイルのプロパティを設定する

  8. [ソース ファイル]ボックスで、アクセス可能な共有の名前にカタログ ファイル名を付加して入力します (例: \\Contoso-Win10\share\LOBApp-Contoso.cat)。

  9. [ターゲット ファイル] ボックスで、「C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\LOBApp-Contoso.cat」と入力します。

      

    LOBApp-Contoso.cat は必須のカタログ名ではありません。この名前は、「カタログ ファイルの作成」セクションで使われているため、この例でも使っています。

     
  10. [新しいファイルのプロパティ] ダイアログ ボックスの [共通] タブで、[適用できなくなった場合はこの項目を削除する] オプションをオンにします。 これにより、アプリケーションの信頼を停止する必要がある場合は、すべてシステムからカタログ ファイルが削除されます。

  11. [OK] をクリックして、ファイルの作成を完了します。

  12. グループ ポリシー管理エディターを閉じ、GPUpdate.exe を実行して、テスト用の Windows 10 コンピューターでポリシーを更新します。ポリシーが更新されたら、カタログ ファイルが、Windows 10 コンピューターの C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} に存在することを確認します。

System Center Configuration Manager を使ったカタログ ファイルの展開

グループ ポリシーの代わりに、System Center Configuration Manager を使って、環境内の管理対象のコンピューターにカタログ ファイルを展開することもできます。この方法によって、複数のカタログ ファイルの展開と管理を簡単に実行することができます。また、各クライアントやコレクションが展開したカタログに関するレポートを作成することもできます。複数のカタログ ファイルの展開だけでなく、System Center Configuration Manager を使うと、レポートやコンプライアンスのために、現在展開されているカタログ ファイルのインベントリを作成することもできます。カタログ ファイル用の新しい展開パッケージを作成するには、次の手順を実行します。

  

次の例では、\\Shares\CatalogShare というネットワーク共有をカタログ ファイルのソースとして使います。コレクション固有のカタログ ファイルがある場合、またはこれらのカタログ ファイルを個別に展開する場合は、組織に最も適したフォルダー構造を使ってください。

 
  1. Configuration Manager コンソールを開き、[ソフトウェア ライブラリ] ワークスペースを選びます。

  2. [概要]、[アプリケーション管理] の順に移動し、[パッケージ] を右クリックして、[パッケージの作成] をクリックします。

  3. パッケージの名前を指定し、組織を製造元として設定して、適切なバージョン番号を選びます (図 16)。

    図 16

    図 16: 新しいパッケージに関する情報を指定する

  4. [次へ] をクリックし、プログラムの種類として [標準プログラム] を選びます。

  5. [標準プログラム] ページで、名前を選び、[コマンド ライン] プロパティを「XCopy \\Shares\CatalogShare C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} /H /K /E /Y」に設定します。

  6. [標準プログラム] ページで、次のオプションを選びます (図 17)。

    • [名前] に「Contoso Catalog File Copy Program」と入力します。

    • [コマンドライン] ではプログラムの場所を参照します。

    • [スタートアップ フォルダー] に「C:\Windows\System32」と入力します。

    • [実行] ボックスから [非表示] を選びます。

    • [プログラムの実行条件] ボックスから [ユーザーのログオン状態に関係なし] を選びます。

    • [ドライブ モード] ボックスから [UNC 名で実行する] を選びます。

    図 17

    図 17: 標準プログラムに関する情報を指定する

  7. ウィザードの残りの部分では既定値をそのまま使い、ウィザードを閉じます。

展開パッケージを作成したら、クライアントがカタログ ファイルを受け取ることができるように、そのパッケージをコレクションに展開します。この例では、作成したパッケージをテスト用のコレクションに展開します。

  1. [ソフトウェア ライブラリ] ワークスペースで、[概要]、[アプリケーション管理]、[パッケージ] の順に移動し、カタログ ファイル パッケージを右クリックして、 [展開] をクリックします。

  2. [全般] ページで、カタログ ファイルの展開先となるテスト用のコレクションを選び、[次へ] をクリックします。

  3. [コンテンツ] ページで、[追加] をクリックして、選んだコレクションにコンテンツを提供する配布ポイントを選び、[次へ] をクリックします。

  4. [展開設定] ページで、[目的] ボックスの [必須] を選びます。

  5. [スケジュール] ページで、[新規] をクリックします。

  6. [割り当てスケジュール] ダイアログ ボックスで、[このイベントの直後に割り当てる] を選び、値を [直ちに] に設定して、[OK] をクリックします。

  7. [スケジュール] ページで、[次へ] をクリックします。

  8. [ユーザー側の表示と操作] ページ (図 18) で、次のオプションを設定し、[次へ] をクリックします。

    • [ソフトウェアのインストール] チェック ボックスをオンにします。

    • [メンテナンスの期限または期間中の変更を確定する (再起動が必要)] チェック ボックスをオンにします。

    図 18

    図 18: ユーザー エクスペリエンスを指定する

  9. [配布ポイント] ページの [展開オプション] ボックスで、[配布ポイントからプログラムを実行する] を選び、[次へ] をクリックします。

  10. [概要] ページで、選択内容を確認し、[次へ] をクリックします。

  11. ウィザードを閉じます。

System Center Configuration Manager を使ったカタログ ファイルのインベントリの作成

グループ ポリシーまたは System Center Configuration Manager を使ってカタログ ファイルを環境内のコンピューターに展開したら、System Center Configuration Manager のソフトウェア インベントリ機能を利用して、それらのカタログ ファイルのインベントリを作成できます。次の手順では、ソフトウェア インベントリを有効にし、新しいクライアント設定ポリシーの作成と展開を行うことによって、管理対象システム上にあるカタログ ファイルを検出する方法について説明します。

  

カタログ ファイルの標準的な名前付け規則を利用することによって、カタログ ファイルのソフトウェア インベントリ プロセスが大幅に簡略化されます。この例では、-Contoso がすべてのカタログ ファイル名に付加されています。

 
  1. Configuration Manager コンソールを開き、[管理] ワークスペースを選びます。

  2. [概要]、[クライアント設定] の順に移動し、[クライアント設定] を右クリックして、[カスタム クライアント デバイス設定の作成] をクリックします。

  3. 図 19 に示すように、新しいポリシーの名前を指定し、[クライアント デバイスのカスタム設定を選択して構成する] の一覧で [ソフトウェア インベントリ] チェック ボックスをオンにします。

    図 19

    図 19: カスタム設定を選ぶ

  4. 図 20 に示すように、ナビゲーション ウィンドウで、[ソフトウェア インベントリ] をクリックし、[種類の設定] をクリックします。

    図 20

    図 20: ソフトウェア インベントリを設定する

  5. [クライアント設定の構成] ダイアログ ボックスで、[開始] ボタンをクリックし、[インベントリされたファイルのプロパティ] ダイアログ ボックスを開きます。

  6. [名前] ボックスに「*Contoso.cat」と入力し、[設定] をクリックします。

      

    *Contoso.cat は、この例で使われる名前付け規則です。これは、カタログ ファイルに対して使われる名前付け規則に従って指定する必要があります。

     
  7. 図 21 に示すように、[パスのプロパティ] ダイアログ ボックスで、[変数またはパス名] を選び、ボックスに「C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}」と入力します。

    図 21

    図 21: パスのプロパティを設定する

  8. [OK] をクリックします。

  9. これで、クライアント設定ポリシーが作成されました。新しいポリシーを右クリックし、[展開] をクリックして、カタログ ファイルのインベントリを作成するコレクションを選びます。

次回のソフトウェア インベントリ サイクルが実行されるとき、対象のクライアントが新しいクライアント設定ポリシーを受け取ると、組み込みの System Center Configuration Manager レポートやリソース エクスプローラーで、インベントリ作成の対象となったファイルを確認することができます。インベントリ作成の対象となったクライアントのファイルをリソース エクスプローラーで確認するには、次の手順を実行します。

  1. Configuration Manager コンソールを開き、[資産とコンプライアンス] ワークスペースを選びます。

  2. [概要]、[デバイス] の順に移動し、インベントリ作成の対象となったファイルを表示するデバイスを検索します。

  3. コンピューターを右クリックし、[開始] をポイントして、[リソース エクスプローラー] をクリックします。

  4. リソース エクスプ ローラーで、[ソフトウェア]、[ファイルの詳細] の順に移動して、インベントリ作成の対象となったカタログ ファイルを表示します。

  

このビューに何も表示されない場合は、リソース エクスプローラーで [ソフトウェア]、[最後のソフトウェア スキャン] の順に移動して、クライアントでソフトウェア インベントリのスキャンを最近実行したかどうかを確認してください。

 

コード整合性ポリシー

コード整合性ポリシーでは、アプリケーションが信頼でき、実行できるかどうかを Windows 10 を実行しているコンピューターで判断するための標準的な基準を管理します。コード整合性の概要については、「構成可能なコード整合性 セクション」をご覧ください。

現在の IT 部門で行われている一般的なシステム イメージングでは、理想的なシステムがどのようなものであるかを表す "ゴールデン" イメージを確立し、そのイメージを使って、会社の追加の IT 資産を複製します。コード整合性ポリシーでも類似した手法に従っており、ゴールデン PC の確立から始まります。イメージングの場合と同様に、モデル、部署、アプリケーションのセットなどに基づいて複数のゴールデン PC を保持することができます。コード整合性ポリシーの作成に関する思考プロセスはイメージングと似ていますが、ポリシーは個別に管理する必要があります。コード整合性ポリシーの追加が必要となる場合は、何をインストールして実行を許可するか、および誰のために許可するかという思考に基づいて決定してください。

  

各コンピューターが一度に保持できるコード整合性ポリシーは、1 つだけです。どのような方法でこのポリシーを展開しても、ポリシーの名前は SIPolicy.p7b に変更され、C:\Windows\System32\CodeIntegrity にコピーされます。コード整合性ポリシーを作成するときには、この点に注意してください。

 

必要に応じて、コード整合性ポリシーを、ソフトウェア カタログや IT 部門で承認されているアプリケーションに合わせることができます。コード整合性ポリシーを実装する簡単な方法の 1 つとして、既にあるイメージを使って 1 つのマスター コード整合性ポリシーを作成する方法があります。これを行うには、各イメージからコード整合性ポリシーを作成し、それらのポリシーをマージします。これにより、異なるイメージに基づいてアプリケーションをコンピューターにインストールする場合、それらすべてのイメージにインストールされるアプリケーションに対して実行の許可が与えられます。また、基盤となるアプリケーション ポリシーを作成し、コンピューターの役割や部署に基づいてポリシーを追加することもできます。組織では、ポリシーの作成、マージ、サービスの提供、および管理を行う方法を選ぶことができます。

  

次のセクションでは、Device Guard の展開の一環としてコード整合性ポリシーを展開することを前提としています。また、Device Guard を有効にしない場合は、構成可能なコード整合性を利用することができます。

 

コード整合性ポリシーの規則

コード整合性ポリシーは、複数のコンポーネントで構成されます。2 つの主要なコンポーネントは構成することができます。これらのコンポーネントはそれぞれ、ポリシー規則およびファイル規則と呼ばれます。コード整合性ポリシーの規則はオプションであり、コード整合性ポリシーの作成者がポリシーで指定することができます。これらのオプションでは、監査モードや UMCI などを有効にすることができます。これらのオプションは、新しいコード整合性ポリシーでも、既にあるコード整合性ポリシーでも変更することができます。ファイル規則は、コード整合性ポリシーのスキャンによって各バイナリの信頼性が関連付けられるレベルを表します。たとえば、ハッシュ レベルによって、システムで検出された各ハッシュが、生成されるコード整合性ポリシー内に列挙されます。これにより、バイナリを実行する準備ができると、コード整合性サービスによって、そのハッシュ値が、コード整合性ポリシーに指定されている信頼されるハッシュに対して検証されます。その結果に基づいて、バイナリの実行の可否が決まります。

既にあるコード整合性ポリシーに関するポリシー規則のオプションを変更するには、Windows PowerShell コマンドレット Set-RuleOption を使います。このコマンドレットを使って既にあるコード整合性ポリシーのポリシー規則のオプションを追加および削除する方法を、次の例に示します。

  • UMCI を有効にするには、次のコマンドを実行して、既にあるポリシーに規則のオプション 0 を追加します。

    Set-RuleOption -Option 0 -FilePath <Path to policy>

  • 既にあるコード整合性ポリシーで UMCI を無効にするには、次のコマンドを実行して、規則のオプション 0 を削除します。

    Set-RuleOption -Option 0 -FilePath <Path to policy> -Delete

1 つのコード整合性ポリシー内に複数の規則のオプションを設定できます。表 2 は、各規則とその概要を示しています。

表 2. コード整合性ポリシー - ポリシー規則のオプション

規則のオプション説明
0 有効: UMCIコード整合性ポリシーでは、カーネル モードとユーザー モードの両方のバイナリを制限します。既定では、カーネル モードのバイナリだけが制限されます。この規則のオプションを有効にすると、ユーザー モードの実行可能ファイルとスクリプトが検証されます。
1 有効: ブート メニューの保護このオプションは、現在サポートされていません。
2 必須: WHQL既定では、Windows Hardware Quality Labs (WHQL) の署名がないレガシ ドライバーの実行が許可されます。この規則を有効にすると、実行されるすべてのドライバーは WHQL によって署名されている必要があり、レガシ ドライバーのサポートが削除されます。今後、Windows 10 と互換性のある新しいドライバーはすべて、WHQL によって認定されている必要があります。
3 有効: 監査モード (既定)コード整合性ポリシーの対象外であるバイナリの実行を有効にします。ただし、各実行は CodeIntegrity イベント ログに記録されます。このログを利用して、既にあるポリシーを実施する前に、それらのポリシーを更新することができます。コード整合性ポリシーを実施するには、このオプションを削除します。
4 無効: Insider Preview ビルドの署名有効にすると、コード整合性ポリシーでは、Insider Preview ビルドのルート署名がされたバイナリを信頼しません。これは、Insider Preview ビルドとしてパッケージ化されたビルドではなく、リリース版のバイナリのみを実行する組織のシナリオで使われます。
5 有効: 固有の既定のポリシーこのオプションは、現在サポートされていません。
6 有効: 署名されていないシステム整合性ポリシー (既定)ポリシーを署名されていない状態にしておくことができます。このオプションを使わない場合、ポリシーは署名されている必要があります。また、将来ポリシーを変更できるようにするために、UpdatePolicySigners がポリシーに追加されている必要があります
7 許可: デバッグ ポリシーの拡張このオプションは、現在サポートされていません。
8 必須: EV 署名者WHQL による署名に加えて、この規則では、ドライバーは拡張検証 (EV) 証明書を持つパートナーによって提出されている必要があります。Windows 10 以降の将来のドライバーはすべて、この要件を満たすことになります。
9 有効: [詳細ブート オプション] メニューすべてのコード整合性ポリシーで、F8 プリブート メニューが既定で無効になります。この規則のオプションを設定すると、実際に使っているユーザーに対して F8 メニューを表示することができます。
10 有効: エラー発生時における監査の起動コード整合性ポリシーが実施モードの場合に使われます。起動時にドライバーでエラーが発生すると、Windows が読み込まれるように、コード整合性ポリシーが監査モードになります。管理者は、CodeIntegrity イベント ログを使って、エラーが発生した理由を確認できます。

 

ファイル規則のレベルを使うと、管理者はアプリケーションを信頼するレベルを指定できます。この信頼性のレベルでは、最低レベルが各バイナリのハッシュで、最高レベルが PCA 証明書になります。ファイル規則のレベルは、スキャンに基づいて新しいコード整合性ポリシーを作成するとき、および監査イベントに基づいてポリシーを作成するときに指定します。また、複数のポリシーに指定されている規則のレベルを組み合わせるために、それらのポリシーをマージすることもできます。ポリシーをマージすると、コード整合性ポリシーではファイル規則が組み合わされます。各ファイル規則のレベルには、メリットとデメリットがあります。表 3 を使って、利用可能な管理リソースと Device Guard 展開シナリオに対して適切な保護レベル選んでください。

表 3. コード整合性ポリシー - ファイル規則のレベル

規則のレベル説明
Hash検出された各バイナリの個々のハッシュ値を指定します。このレベルは限定的なレベルですが、これにより、現在の製品バージョンのハッシュ値を管理するために、追加の管理オーバーヘッドが発生する場合があります。バイナリが更新されるたびにハッシュ値が変更されるので、ポリシーの更新が必要となります。
FileName個々のバイナリ ファイルの名前を指定します。アプリケーションの更新時にアプリケーションのハッシュ値は変更されますが、ファイル名は通常変更されません。このレベルは、ハッシュ レベルほど限定的なセキュリティではありませんが、通常、バイナリが変更された場合でもポリシーの更新は必要ありません。
SignedVersionこのレベルは、発行元の規則とファイルのバージョン番号を組み合わせたものです。このオプションでは、指定した発行元からのファイルのバージョンが、指定されたバージョン番号以上である場合に、ファイルの実行が許可されます。
Publisherこのレベルは、PCA 証明書と、リーフ証明書の共通名 (CN) を組み合わせたものです。複数企業に基づくアプリケーション (VeriSign など) に PCA 証明書を使って署名するシナリオでは、この規則のレベルを利用すると、組織は PCA 証明書を信頼することができます。ただし、リーフ証明書に名前がある企業についてのみ信頼することができます (デバイス ドライバーの場合は Intel など)。このレベルでは、信頼できるリーフ証明書と組み合わせた場合にのみ、長い有効期間を持つ証明書を信頼します。
FilePublisherこのレベルは、発行元に関するファイル規則のレベルと SignedVersion の規則のレベルを組み合わせたものです。信頼できる発行元からのファイルが署名されており、指定されているバージョン以降のファイルである場合に、ファイルが信頼されます。
LeafCertificate個々の署名証明書レベルで、信頼できる署名者を追加します。新しいバージョンの製品ではハッシュ値は異なりますが、通常、署名証明書は同じであるため、個々のハッシュ レベルよりも、このレベルを使うほうがメリットがあります。このレベルを使うと、新しいバージョンのアプリケーションを実行する際に、ポリシーの更新は必要ありません。ただし、リーフ証明書の有効期間は PCA 証明書よりも大幅に短いため、リーフ証明書の有効期限が切れると、コード整合性ポリシーの更新に関連して追加の管理オーバーヘッドが発生します。
PcaCertificate署名者に提供された証明書チェーン内の最上位の証明書を追加します。これは通常、ルート証明書の 1 つ下の証明書です。スキャンでは、オンラインにしたり、ローカルのルート ストアをチェックしたりして提示された署名より上のものは何も検証されないためです。
RootCertificate現在はサポートされていません。
WHQLバイナリが WHQL によって検証および署名されている場合に、そのバイナリを信頼します。これは、主にカーネル バイナリ向けのレベルです。
WHQLPublisherこのレベルは、WHQLと、リーフ証明書の共通名 (CN) を組み合わせたものです。主にカーネル バイナリ向けのレベルです。
WHQLFilePublisherバイナリが WHQL によって検証および署名されていることを指定します。また、このバイナリは特定の発行者 (WHQLPublisher) からのものあり、指定されているバージョン以降のバイナリであることを指定します。これは、主にカーネル バイナリ向けのレベルです。

 

  

New-CIPolicy コマンドレットを使ってコード整合性ポリシーを作成するとき、–Level パラメーターを使って、最優先するファイル規則のレベルを指定できます。最優先するファイル規則の条件に基づいて判断したときに、信頼できないバイナリが検出された場合、–Fallback パラメーターを使うことができます。たとえば、最優先するファイル規則のレベルが PCACertificate であるが、署名されていないアプリケーションも信頼したい場合は、規則のレベル Hash をフォールバックとして使い、署名証明書がないバイナリのハッシュ値を追加します。

 

ゴールデン PC からのコード整合性ポリシーの作成

参照システムからゴールデン コード整合性ポリシーを作成する手順は、簡単です。このセクションでは、Windows PowerShell を使って適切にコード整合性ポリシーを作成するための手順について説明します。この例では最初に、作成手順で使われる変数の初期設定を行う必要があります。変数を使わずに、コマンドで完全ファイル パス使うこともできます。次に、アプリケーションがインストールされるシステムをスキャンして、コード整合性ポリシーを作成します。コード整合性ポリシーが作成されると、ポリシー ファイルがバイナリ形式に変換され、Windows がその内容を利用できるようになります。

  

この手順を開始する前に、参照 PC がウイルスやマルウェアに感染していないことを確認してください。このポリシーを作成する前に、インストールされる各ソフトウェアが信頼できるものとして検証されている必要があります。また、コード整合性ポリシーを作成する前に、スキャンするすべてのソフトウェアがシステムにインストールされていることも確認してください。

 

コード整合性ポリシーを作成するには、次の各コマンドを、上から順番に管理者特権の Windows PowerShell セッションにコピーします。

  1. 使われる変数を初期化します。

    $CIPolicyPath=$env:userprofile+"\Desktop\"

    $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

    $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"

  2. アプリケーションがインストールされるシステムをスキャンして、新しいコード整合性ポリシーを作成します。

    New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy –UserPEs 3> CIPolicyLog.txt

      

    –UserPEs パラメーターを指定すると、規則のオプション "0 有効: UMCI" がコード整合性ポリシーに自動的に追加されます。このパラメーターを指定しない場合は、次のコマンドを使って UMCI を有効にします。

    Set-RuleOption -Option 0 -FilePath $InitialCIPolicy

     
      

    –Fallback パラメーターを追加して、–Level パラメーターで指定した最優先するファイル規則のレベルで検出されなかったすべてのアプリケーションをキャッチすることができます。ファイル規則のレベルのオプションについて詳しくは、「コード整合性ポリシーの規則」セクションをご覧ください。

     
      

    コード整合性ポリシーのスキャンで特定のドライブのみを対象とする場合は、–ScanPath パラメーターを使います。このパラメーターを指定しない場合、上の例で示すように、システム全体がスキャンされます。

     
  3. コード整合性ポリシーをバイナリ形式に変換します。

    ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin

これらの手順が完了すると、Device Guard バイナリ ファイル (DeviceGuardPolicy.bin) と元の .xml ファイル (IntialScan.xml) がデスクトップで利用できるようになります。バイナリ バージョンをコード整合性ポリシーとして使ったり、セキュリティ強化のためにそのバイナリに署名したりすることができます。

  

コード整合性ポリシーを別のポリシーとマージしたり、ポリシーの規則のオプションを更新したりする必要がある場合は、ポリシーの元の .xml ファイルを保存しておき、使うことをお勧めします。これを行わない場合は、新しいスキャンから新しいポリシーを作成する必要があります。コード整合性ポリシーをマージする方法について詳しくは、「コード整合性ポリシーのマージ」セクションをご覧ください。

 

コード整合性ポリシーを実施する前に、すべてのコード整合性ポリシーを監査モードで実行することをお勧めします。これを行うことで、管理者は、エラー メッセージのダイアログ ボックスを利用せずに、ポリシーに関する問題を検出することができます。コード整合性ポリシーを監査する方法については、「コード整合性ポリシーの監査」セクションをご覧ください。

コード整合性ポリシーの監査

コード整合性ポリシーが監査モードで実行されていると、管理者は、ポリシーの最初のスキャンで見つからなかったアプリケーションを検出したり、最初のポリシーが作成された以降にインストールされ実行された新しいアプリケーションを特定したりすることができます。コード整合性ポリシーが監査モードで実行されているとき、実行されるバイナリやポリシーの実施によって拒否されるバイナリは、アプリケーションとサービス ログ\Microsoft\CodeIntegrity\Operational イベント ログに記録されます。ログに記録されたこれらのバイナリが検証されると、新しいコード整合性ポリシーに簡単に追加することができます。新しい例外ポリシーを作成した場合、そのポリシーを既にあるコード整合性ポリシーとマージすることができます。

  

この作業を始める前に、コード整合性ポリシーのバイナリ ファイルを作成する必要があります。このバイナリ ファイルをまだ作成していない場合は、「コード整合性ポリシーの作成」セクションをご覧になり、コード整合性ポリシーを作成し、バイナリ形式に変換するための具体的な手順を確認してください。

 

ローカル ポリシーを使ってコード整合性ポリシーを監査するには:

  1. ゴールデン PC からのコード整合性ポリシーの作成」セクションで作成した DeviceGuardPolicy.bin ファイルを、C:\Windows\System32\CodeIntegrity にコピーします。

  2. 監査モードで実行するシステムで、GPEdit.msc を実行して、ローカル グループ ポリシー エディターを開きます。

  3. [コンピューターの構成]、[管理用テンプレート]、[システム]、[Device Guard] の順に移動し、[コードの整合性ポリシーを展開する] を選びます。図 22 に示すように、ファイル パス C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin を使って、この設定を有効にします。

      

    DeviceGuardPolicy.bin は必須のポリシー名ではありません。この名前は、「ゴールデン PC からのコード整合性ポリシーの作成」セクションで使われているため、この例でも使っています。また、このポリシー ファイルはすべてのシステムにコピーする必要はありません。代わりに、コード整合性ポリシーを、すべてのコンピューター アカウントがアクセスできるファイル共有にコピーすることもできます。

     
      

    ここで選んだすべてのポリシーは、個々のコンピューターに展開するときに、SIPolicy.p7b に変換されます。

     
    図 22

    図 22: コード整合性ポリシーを展開する

      

    GPO の設定は .p7b ファイルを参照しますが、このポリシーでは .bin ファイルを使うことに注意してください。展開するポリシーの種類 (.bin、.p7b、.p7) に関係なく、それらのポリシーは、Windows 10 コンピューターに配置されたときに SIPolicy.p7b に変換されます。コード整合性ポリシーの名前はわかりやすい名前にして、システムがポリシー名を変換できるようにすることをお勧めします。これにより、共有や他の一元管理されているリポジトリで確認したときに、ポリシーを簡単に識別できるようになります。

     
  4. コード整合性ポリシーを有効にするために、参照システムを再起動します。

  5. CodeIntegrity イベント ログを監視します。 図 23 に示すように、監査モードの間、展開されるコード整合性ポリシーの例外は、アプリケーションとサービス ログ\Microsoft\CodeIntegrity\Operational イベント ログに記録されます。

    図 23

    図 23: 展開されるコード整合性ポリシーの例外

  6. コード整合性ポリシーのすべての例外を検証します。

    コード整合性ポリシーを監査モードで実行した後は、記録された各例外の調査や検証を行うことをお勧めします。例外の原因となるアプリケーションの検出や、そのアプリケーションを整合性ポリシーに追加するかどうかの確認だけでなく、各アプリケーションを信頼するために使う必要があるファイル レベルも調べてください。ファイル規則のレベル Hash はこれらの例外をすべてキャッチしますが、すべての例外を信頼するには最適な方法ではない場合もあります。ファイル規則のレベルとそれらの目的については、「コード整合性ポリシーの規則」セクションをご覧ください。

  7. 監査イベントからコード整合性ポリシーを作成します。

    監査イベントからコード整合性ポリシーを作成する方法については、「ゴールデン PC からのコード整合性ポリシーの作成」セクションをご覧ください。

  

ポリシーをテストする別の方法として、テスト ファイルの名前を SIPolicy.p7b に変更し、ローカル コンピューターのポリシーで展開するのではなく、C:\Windows\System32\CodeIntegrity に配置する方法があります。

 

監査のコード整合性ポリシーを作成する

コード整合性ポリシーを監査モードで実行する場合、例外を検証し、例外となったアプリケーションを監査の対象となるコード整合性ポリシーに追加する必要があるかどうかを決定します。通常どおりシステムを使って、例外の記録を確認します。監査イベントからコード整合性ポリシーを作成する準備ができたら、次の手順を管理者特権の Windows PowerShell セッションで実行します。

  1. 使われる変数を初期化します。

    $CIPolicyPath=$env:userprofile+"\Desktop\"

    $CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"

  2. 監査結果を分析します。★▲■プルーフここから■▲★

    監査イベントからコード整合性ポリシーを作成する前に、「コード整合性ポリシーの監査」セクションの手順 5. と 6. で説明したように、それぞれの例外を分析することをお勧めします。

  3. ログに記録された監査イベントから、新しいコード整合性ポリシーを生成します。

    New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt

  

監査イベントからポリシーを作成する場合は、信頼の基準として選んだファイル規則のレベルを慎重に検討する必要があります。この例では、規則のレベル Hash を使いますが、これは最終手段として使うことをお勧めします。

 

これらの手順が完了すると、Device Guard 監査ポリシーの .xml ファイル (DeviceGuardAuditPolicy.xml) がデスクトップで利用できるようになります。このファイルを使って、既にあるコード整合性ポリシー (2 つのポリシーをマージして、監査モードで実行したポリシー) を更新することができます。この監査ポリシーを既にあるコード整合性ポリシーとマージする方法については、「コード整合性ポリシーのマージ」セクションをご覧ください。

  

ゴールデン PC からのコード整合性ポリシーの作成」セクションではポリシーのバイナリ バージョンを生成しましたが、この例ではポリシーのバイナリ バージョンは作成していないことに注意してください。これは、監査ログから作成したコード整合性ポリシーは、スタンドアロンのポリシーとして実行するためのものではなく、既にあるコード整合性ポリシーを更新することを目的としているためです。

 

コード整合性ポリシーのマージ

コード整合性ポリシーを開発するとき、場合によっては、2 つのポリシーをマージする必要があります。一般的な例としては、コード整合性ポリシーを最初に作成し監査する場合などがあります。別の例としては、ゴールデン PC から作成した複数のコード整合性ポリシーを使って、1 つのマスター ポリシーを作成する場合が挙げられます。各 Windows 10 コンピューターで保持できるコード整合性ポリシーは 1 つだけであるため、これらのポリシーを適切に管理することが重要です。この例では、監査イベントが第 2 のコード整合性ポリシーに保存されており、このコード整合性ポリシーを最初のコード整合性ポリシーとマージします。

  

次の例では、「ゴールデン PC からのコード整合性ポリシーの作成」と「コード整合性ポリシーの監査」の各セクションで作成したコード整合性ポリシーの .xml ファイルを使います。ただし、この作業を実行するには、組み合わせる 2 つのコード整合性ポリシーが必要になります。

 

2 つのコード整合性ポリシーをマージするには、次の手順を管理者特権の Windows PowerShell セッションで実行します。

  1. 使われる変数を初期化します。

    $CIPolicyPath=$env:userprofile+"\Desktop\"

    $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

    $AuditCIPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"

    $MergedCIPolicy=$CIPolicyPath+"MergedPolicy.xml"

    $CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"

      

    このセクションの変数は、デスクトップ上の最初のポリシー (InitialScan.xml) と監査のコード整合性ポリシー (DeviceGuardAuditPolicy.xml) を検索する場合に特に必要となります。他のコード整合性ポリシーをマージする場合は、それに合わせて変数の値を変更してください。

     
  2. 2 つのポリシーをマージして、新しいコード整合性ポリシーを作成します。

    Merge-CIPolicy -PolicyPaths $InitialCIPolicy,$AuditCIPolicy -OutputFilePath $MergedCIPolicy

  3. マージしたコード整合性ポリシーをバイナリ形式に変換します。

    ConvertFrom-CIPolicy $MergedCIPolicy $CIPolicyBin

これで、NewDeviceGuardPolicy.bin という新しいコード整合性ポリシーが作成されました。このポリシーをシステムに展開するには、手動で行うか、またはグループ ポリシーや Microsoft が提供するクライアント管理ソリューションを使います。グループ ポリシーを使ってこの新しいポリシーを展開する方法については、「グループ ポリシーを使ったコード整合性ポリシーの展開と管理」セクションをご覧ください。

コード整合性ポリシーを実施する

すべてのコード整合性ポリシーは、監査モードを有効にして作成されています。コード整合性ポリシーの監査モードでの展開とテストが適切に行われ、ポリシーを実施モードでテストする準備ができたら、次の手順を管理者特権の Windows PowerShell セッションで実行します。

  

すべてのコード整合性ポリシーは、最初に監査モードでテストする必要があります。コード整合性ポリシーを監査する方法については、「コード整合性ポリシーの監査」セクションをご覧ください。

 
  1. 使われる変数を初期化します。

    $CIPolicyPath=$env:userprofile+"\Desktop\"

    $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

    $EnforcedCIPolicy=$CIPolicyPath+"EnforcedPolicy.xml"

    $CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"

      

    このセクションで参照している最初のコード整合性ポリシーは、「ゴールデン PC からのコード整合性ポリシーの作成」セクションで作成しました。別のコード整合性ポリシーを使っている場合は、CIPolicyPath 変数と InitialCIPolicy 変数の値を変更してください。

     
  2. 元のファイルを保持しておくために、最初のコード整合性ポリシーのファイルをコピーします。

    cp $InitialCIPolicy $EnforcedCIPolicy

  3. 監査モードの規則のオプションを削除します。

    Set-RuleOption -Option 3 -FilePath $EnforcedCIPolicy -Delete

      

    "実施" のオプションを追加するのではありません。"監査モードの有効化" のオプションがない場合、コード整合性ポリシーは暗黙的に実施されるためです。

     
  4. 新しいコード整合性ポリシーをバイナリ形式に変換します。

    ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin

      

    ポリシーの実施を初めて実行する場合は、その前に、規則のオプション 9 と 10 を有効にすることを強くお勧めします。既にポリシーに指定されている場合は、削除しないでください。こうすることで、コード整合性ポリシーがカーネル モード ドライバーの実行をブロックし、管理者に対してプリブート コマンド プロンプトが示された場合でも、Windows が起動できるようになります。エンタープライズ展開の準備ができたら、これらのオプションを削除できます。

     

これで、このポリシーが実施されるので、テスト コンピューターに展開することができます。ポリシーの名前を SIPolicy.p7b に変更し、テスト用に C:\Windows\System32\CodeIntegrity にコピーします。または、グループ ポリシーを使ってポリシーを展開するか (「グループ ポリシーを使ったコード整合性ポリシーの展開と管理」セクションの手順をご覧ください)、またはクライアント管理ソフトウェアを使ってポリシーを展開します (「Microsoft のクライアント管理ソリューションを使ったコード整合性ポリシーの展開と管理」セクションの手順をご覧ください)。

SignTool.exe を使ったコード整合性ポリシーへの署名

署名されたコード整合性ポリシーによって、組織では、Windows 10 で利用可能な最高レベルのマルウェア対策を実現できます。コンピューターのユーザーや管理者は、実施されたポリシーの規則だけでなく、署名されたポリシーも変更したり、削除したりすることはできません。これらのポリシーは、管理上の改ざんやカーネル モードでの悪意のあるアクセスを防止するように設計されています。これを念頭に置くと、署名されているコード整合性ポリシーは、署名されていないコード整合性ポリシーよりも削除するのが難しいことがわかります。コード整合性ポリシーの署名と展開を行う前に、ポリシーを監査して、ブロックされているが実行を許可する必要があるアプリケーションを検出することをお勧めします。コード整合性ポリシーを監査する方法について詳しくは、「コード整合性ポリシーの監査」セクションをご覧ください。

社内の CA が生成した証明書、または購入したコード署名証明書を使ってコード整合性ポリシーに署名することは簡単です。コード署名証明書を .pfx 形式 (秘密キー、拡張機能、ルート証明書が含まれます) でエクスポートしていない場合は、「Device Guard のコード署名証明書の作成」をご覧になり、社内の CA を使ってコード署名証明書を作成してください。コード整合性ポリシーに初めて署名する場合は、署名する前に、規則のオプション 9 と 10 を有効にして、トラブルシューティングのオプションをテスト管理者が利用できるようにしておきます。エンタープライズ展開を検証し、その準備ができたら、これらのオプションを削除できます。規則のオプションを追加する方法については、「コード整合性ポリシーの規則」セクションをご覧ください。

  

コード整合性ポリシーへの署名は、コード整合性の展開で最後に行う手順です。署名されているコード整合性ポリシーは、署名されていないコード整合性ポリシーよりも削除するのが難しくなっています。署名されたコード整合性ポリシーを対象のクライアント コンピューターに展開する前に、コンピューターのサブセットに対する影響をテストしてください。

SignTool.exe を使ってコード整合性ポリシーに署名するには、次のコンポーネントが必要です。

  • SignTool.exe。Windows SDK (Windows 7 以降) に付属しています。

  • ゴールデン PC からのコード整合性ポリシーの作成」セクションで生成したコード整合性ポリシーのバイナリ形式、または作成してある他のコード整合性ポリシー。

  • 内部 CA のコード署名証明書、または購入したコード署名証明書。

 

コード署名証明書を持っていない場合は、「Device Guard のコード署名証明書の作成」セクションをご覧になり、コード署名証明書の作成方法の手順を確認してください。他の証明書やコード整合性ポリシーを使う場合は、コマンドが正常に機能するように、次の手順の変数や証明書を適切な値に置き換えてください。既にあるコード整合性ポリシーに署名するには、次の各コマンドを、管理者特権の Windows PowerShell セッションにコピーします。

  1. 使われる変数を初期化します。

    $CIPolicyPath=$env:userprofile+"\Desktop\" $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml" $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"

      

    この例では、「ゴールデン PC からのコード整合性ポリシーの作成」セクションで作成したコード整合性ポリシーを使います。他のポリシーに署名する場合は、$CIPolicyPath 変数と $CIPolicyBin 変数を適切な値に置き換えてください。

     
  2. .pfx コード署名証明書をインポートします。 コード整合性ポリシーへの署名に使うコード署名証明書を、署名するユーザーの個人用ストアにインポートします。このストアは、署名を行うコンピューター上にあるストアです。この例では、「Device Guard のコード署名証明書の作成」セクションで作成した証明書を使います。

  3. .cer コード署名証明書をエクスポートします。 コード署名証明書がインポートされたら、.cer バージョンをデスクトップにエクスポートします。このバージョンは、後で更新できるように、ポリシーに追加されます。

  4. デスクトップに移動し、作業ディレクトリとして使います。

    cd $env:USERPROFILE\Desktop

  5. 更新署名者の証明書をコード整合性ポリシーに追加します。

    Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update

      

    <Path to exported .cer certificate> には、手順 3. でエクスポートした証明書への完全なパスを指定します。

     
      

    更新署名者を追加することは、将来、このポリシーを変更したり無効にしたりする場合に重要となります。署名されたコード整合性ポリシーを無効にする方法について詳しくは、「Windows での署名されたコード整合性ポリシーの無効化」セクションをご覧ください。

     
  6. 署名されていないポリシーの規則のオプションを削除します。

    Set-RuleOption -Option 6 -FilePath $InitialCIPolicy -Delete

  7. ポリシーをバイナリ形式に変換します。

    ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin

  8. SignTool.exe を使って、コード整合性ポリシーに署名します。

    <Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin

      

    <Path to signtool.exe> 変数には、SignTool.exe ユーティリティへの完全なパスを指定します。ContosoDGSigningCert は、コード整合性ポリシーへの署名に使う証明書のサブジェクト名です。この証明書を、ポリシーへの署名に使うコンピューター上にある個人用の証明書ストアにインポートします。

     
  9. 署名されたファイルを検証します。 上記の手順が完了すると、コマンドによって、DeviceGuardPolicy.bin.p7 という署名されたポリシー ファイルがデスクトップに出力されます。このファイルは、実施するポリシーの展開や、実施前のポリシーの展開と同じ方法で展開できます。コード整合性ポリシーの展開方法については、「グループ ポリシーを使ったコード整合性ポリシーの展開と管理」セクションをご覧ください。

署名されていないコード整合性ポリシーの無効化

場合によっては、管理者はコード整合性ポリシーを無効にする必要があります。署名されていないコード整合性ポリシーについては、この手順は簡単です。コード整合性ポリシーの展開方法に応じて、署名されていないポリシーは次の 2 つの方法のどちらかで無効にすることができます。コード整合性ポリシーを手動で有効化し、コード整合性フォルダーの場所にコピーした場合は、ファイルを削除して、コンピューターを再起動するだけです。次の場所には、実行中のコード整合性ポリシーを含めることができます。

  • <EFI システム パーティション>\Microsoft\Boot\

  • <OS ボリューム>\Windows\System32\CodeIntegrity\

グループ ポリシーを使ってコード整合性ポリシーを展開した場合は、現在ポリシーを有効化して展開している GPO を無効に設定する必要があります。これにより、コンピューターを次回再起動したときに、コード整合性ポリシーが無効になります。

Windows での署名されたコード整合性ポリシーの無効化

署名されたポリシーによって、Windows は、システムへの管理レベルのアクセス権を取得した管理操作やマルウェアから保護されます。このため、署名されたコード整合性ポリシーの削除は、署名されていないコード整合性ポリシーよりも意図的に難しくなっています。これらのポリシーによって、ポリシー自体が変更や削除から本質的に保護されます。このため、管理者でも正常に削除するのが困難です。署名されたコード整合性ポリシーを手動で有効化し、CodeIntegrity フォルダーにコピーした場合は、ポリシーを削除するために、次の手順を実行する必要があります。

  

置き換えや削除の対象となる署名されたコード整合性ポリシーは、次の場所にあります。

  • <EFI システム パーティション>\Microsoft\Boot\

  • <OS ボリューム>\Windows\System32\CodeIntegrity\

 
  1. 既にあるポリシーを、規則のオプション "6 有効: 署名されていないシステム整合性ポリシー" が有効になっている、他の署名されたポリシーに置き換えます。

      

    この置き換えを有効にするには、この新しいポリシーが、置き換えの対象となる元の署名済みポリシーの UpdatePolicySigners セクションに追加されている証明書で署名されている必要があります。

     
  2. クライアント コンピューターを再起動します。

  3. 署名された新しいポリシーがクライアントに存在することを確認します。

      

    規則のオプション 6 を含んでいる署名されたポリシーがクライアントで正しく処理されていないと、署名されていないポリシーの追加が原因となって、起動エラーが発生する可能性があります。

     
  4. 新しいポリシーを削除します。

  5. クライアント コンピューターを再起動します。

グループ ポリシーを使って、署名されたコード整合性を展開した場合は、次の手順を実行する必要があります。

  1. GPO 内にあるポリシーを、規則のオプション "6 有効: 署名されていないシステム整合性ポリシー" が有効になっている、他の署名されたポリシーに置き換えます。

      

    この置き換えを有効にするには、この新しいポリシーが、置き換えの対象となる元の署名済みポリシーの UpdatePolicySigners セクションに追加されている証明書で署名されている必要があります。

     
  2. クライアント コンピューターを再起動します。

  3. 署名された新しいポリシーがクライアントに存在することを確認します。

      

    規則のオプション 6 を含んでいる署名されたポリシーがクライアントで正しく処理されていないと、署名されていないポリシーの追加が原因となって、起動エラーが発生する可能性があります。

     
  4. GPO を無効に設定します。

  5. 新しいポリシーを削除します。

  6. クライアント コンピューターを再起動します。

BIOS での署名されたコード整合性ポリシーの無効化

署名されたコード整合性ポリシーが原因で、起動エラーが発生する場合があります。コード整合性ポリシーによってカーネル モード ドライバーが適用されるため、ドライバーの適用や署名を行う前に、それぞれのソフトウェア構成やハードウェア構成でポリシーを十分にテストすることが重要となります。署名されたコード整合性ポリシーは、セキュア ブートを使ったプリブート シーケンスで検証されます。BIOS のセキュア ブート機能を無効にして、オペレーティング システム ディスク上の次の場所からファイルを削除すると、システムで Windows を起動することができます。

  • <EFI システム パーティション>\Microsoft\Boot\

  • <OS ボリューム>\Windows\System32\CodeIntegrity\

グループ ポリシーを使ったコード整合性ポリシーの展開と管理

グループ ポリシーを使って、コード整合性ポリシーを簡単に展開し管理することができます。Device Guard の管理用テンプレートは Windows Server 2016 で利用できます。このテンプレートによって、Device Guard のハードウェア ベースのセキュリティ機能やコード整合性ポリシーの展開が容易になります。次の手順では、GPO (Contoso GPO Test) を使って、コード整合性ポリシー (DeviceGuardPolicy.bin) をテスト OU (DG Enabled PCs) に展開する方法について説明します。

  

このチュートリアルでは、コード整合性ポリシーが既に作成されており、、グループ ポリシーの展開をテストする Windows 10 クライアント PC が利用可能になっている必要があります。コード整合性ポリシーを作成する方法について詳しくは、「ゴールデン PC からのコード整合性ポリシーの作成」セクションをご覧ください。

 
  

展開時に、署名されたコード整合性ポリシーが原因で起動エラーが発生する場合があります。エンタープライズ展開を行う前に、署名されたコード整合性ポリシーを各ハードウェア プラットフォームで十分にテストすることをお勧めします。

 

グループ ポリシーを使ってコード整合性ポリシーを展開し管理するには:

  1. RSAT がインストールされているクライアント コンピューターのドメイン コント ローラーで、GPMC.MSC を実行するか、Windows Search で "グループ ポリシーの管理" を検索して、GPMC を開きます。

  2. 新しい GPO を作成します。そのためには、図 24 に示すように、"DG Enabled PCs" OU を右クリックして、[このドメインに GPO を作成し、このコンテナーにリンクする] をクリックします。

      

    "DG Enabled PCs" OU は、このセクションで作成したテスト GPO のリンク先となるサンプルの OU です。任意の OU の名を使うことができます。また、「企業向けコード整合性を展開する方法 」セクションで説明した方法に基づいたポリシーの区分方法を検討している場合は、セキュリティ グループをフィルター処理することもできます。

     
    図 24

    図 24: GPO を作成する

  3. 新しい GPO に、"Contoso GPO Test" という名前を付けます。 この例では、GPO の名前として "Contoso GPO Test" を使います。この例で使われる名前の代わりに、任意の名前を指定することもできます。

  4. グループ ポリシー管理エディターを開きます。そのためには、新しい GPO を右クリックし、[編集] をクリックします。

  5. 選んだ GPO で、[コンピューターの構成]、[管理用テンプレート]、[システム]、[Device Guard] の順に移動します。[コードの整合性ポリシーを展開する] を右クリックし、[編集] をクリックします。

    図 25

    図 25: コード整合性ポリシーを編集する

  6. [コードの整合性ポリシーを展開する] ダイアログ ボックスで、[有効] オプションを選び、コード整合性ポリシー展開パスを指定します。

    このポリシー設定では、クライアント コンピューター上にあるポリシーのローカル パスを指定するか、ポリシーの最新バージョンを取得するためにクライアント コンピューターで参照される汎用名前付け規則 (UNC) パスを指定します。この例では、DeviceGuardPolicy.bin ファイルをテスト コンピューターにコピーして、この設定を有効にし、図 26 に示すように、ファイル パス C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin を使います。

      

    DeviceGuardPolicy.bin は必須のポリシー名ではありません。この名前は、「ゴールデン PC からのコード整合性ポリシーの作成」セクションで使われているため、この例でも使っています。また、このポリシー ファイルはすべてのコンピューターにコピーする必要はありません。代わりに、コード整合性ポリシーを、コンピューター アカウントがアクセスできるファイル共有にコピーすることもできます。ここで選んだすべてのポリシーは、個々のクライアント コンピューターに展開するときに、SIPolicy.p7b に変換されます。

     
    図 26

    図 26: コード整合性ポリシーを有効にする

      

    GPO の設定は .p7b ファイルを参照しますが、この例では、ポリシーに対して .bin ファイルを使うことに注意してください。展開するポリシーの種類 (.bin、.p7b、.p7) に関係なく、それらのポリシーは、Windows 10 クライアント コンピューターに配置されたときに SIPolicy.p7b に変換されます。コード整合性ポリシーの名前はわかりやすい名前にして、システムがポリシー名を変換できるようにしてください。こうすることにより、共有や他の一元管理されているリポジトリで確認したときに、ポリシーを簡単に識別できるようになります。

     
  7. グループ ポリシー管理エディターを閉じて、Windows 10 のテスト コンピューターを再起動します。 クライアント コンピューターを再起動すると、コード整合性ポリシーが更新されます。コード整合性ポリシーを監査する方法については、「コード整合性ポリシーの監査」セクションをご覧ください。

Device Guard のコード署名証明書の作成

組織内でカタログ ファイルやコード整合性ポリシーに署名するには、公開されているコード署名証明書または内部 CA が必要になります。コード署名証明書を購入した場合は、次の手順を省略し、カタログ ファイルやコード整合性ポリシーに署名する手順を説明しているセクションに進んでください。証明書を購入していないが、内部 CA がある場合は、次の手順を実行してコード署名証明書を作成します。

  1. 証明機関 Microsoft 管理コンソール (MMC) スナップインを開き、発行元の CA を選びます。

  2. 接続されたら、[証明書テンプレート] を右クリックし、[管理] をクリックして、証明書テンプレート コンソールを開きます。

    図 27

    図 27: 証明書テンプレートを管理する

  3. ナビゲーション ウィンドウで、コード署名証明書を右クリックし、[テンプレートの複製] をクリックします。

  4. [互換性] タブで、[結果的な変更を表示] チェック ボックスをオフにします。[証明機関] の一覧から [Windows Server 2012] を選び、[証明書の受信者] の一覧から [Windows 8 / Windows Server 2012] を選びます。

  5. [全般] タブで、[テンプレート表示名][テンプレート名] を指定します。 この例では、"DG Catalog Signing Certificate" を使います。

  6. [要求の処理] タブで、[秘密キーのエクスポートを許可する]] チェック ボックスをオンにします。

  7. [拡張機能] タブで [基本制限] チェック ボックスをオンにして、[編集] をクリックします。

  8. 図 28 に示すように、[基本制約拡張機能の編集] ダイアログ ボックスで、[この拡張機能を有効にする] チェック ボックスをオンにします。

    図 28

    図 28: 新しいテンプレートでの制約を有効にする

  9. 発行された証明書の承認を証明書マネージャーが行う必要がある場合は、[発行の要件] タブで [CA 証明書マネージャーの許可] を選びます。

  10. [サブジェクト名] タブで [要求に含まれる] を選びます。

  11. [セキュリティ] タブで、証明書の要求に使われるすべてのアカウントが証明書を登録する権利を持つことを確認します。

  12. [OK] をクリックして、テンプレートを作成し、証明書テンプレート コンソールを閉じます。

この証明書テンプレートが作成されたら、CA が発行したテンプレート ストアに公開する必要があります。そのためには、次の手順を実行します。

  1. 図 29 に示すように、証明機関 MMC スナップインで [証明書テンプレート] を右クリックし、[新規作成] をポイントして、[発行する証明書テンプレート] をクリックします。

    作成したテンプレートを含む、利用可能なテンプレートの一覧が表示されます。

    図 29

    図 29: 発行する新しい証明書テンプレートを選ぶ

  2. "DG Catalog Signing Certificate" を選んで、[OK] をクリックします。

これで、テンプレートを発行することができます。このテンプレートは、カタログ ファイルの作成と署名に使う Windows 10 コンピューターから要求する必要があります。まず、MMC を開き、次の手順を実行します。

  1. MMC で、[ファイル] メニューの [スナップインの追加と削除] をクリックします。[証明書] をダブルクリックして、[ユーザー アカウント] を選びます。

  2. 証明書スナップインで、個人用ストア フォルダーを右クリックし、[すべてのタスク] をポイントして、[新しい証明書の要求] をクリックします。

  3. [次へ] をクリックして、証明書を選ぶための一覧を表示します。

  4. 図 30 に示すように、[証明書の要求] の一覧で、新しく作成したコード署名証明書を選び、追加の情報を要求する青色のテキストを選びます。

    図 30

    図 30: コード署名証明書用の追加の情報を取得する

  5. [証明書のプロパティ] ダイアログ ボックスの [種類] で、[共通名] を選びます。[値] には [ContosoDGSigningCert] を選び、[追加] をクリックします。追加されたら、[OK] をクリックします。

  6. 登録し、終了します。

  

発行された証明書の承認は証明書マネージャーが行う必要があり、テンプレートで管理者による承認が必要であることを選んだ場合は、クライアントに証明書を発行する前に、CA で証明書の要求が承認される必要があります。

 

この証明書は、カタログ ファイルやコード整合性ポリシーへの署名に使うコンピューター上にある、ユーザーの個人用ストアにインストールする必要があります。証明書を要求したコンピューターで署名が行われる場合は、証明書を .pfx ファイルにエクスポートする必要はありません。証明書が既に個人用ストアに格納されているためです。別のコンピューターで署名する場合は、必要なキーとプロパティを使って .pfx 形式の証明書をエクスポートする必要があります。そのためには、次の手順を実行します。

  1. 証明書を右クリックし、[すべてのタスク] をポイントして、[エクスポート] をクリックします。

  2. [次へ] をクリックして、[はい、秘密キーをエクスポートします] を選びます。

  3. 既定の設定を選び、[すべての拡張プロパティをエクスポートする] を選びます。

  4. パスワードを設定し、エクスポート パスを選んで、DGCatSigningCert.pfx をファイル名として選びます。

証明書がエクスポートされたら、カタログ ファイルやコード整合性ポリシーに署名するユーザーの個人用ストアに証明書をインポートします。このストアは、カタログ ファイルやコード整合性ポリシーへの署名に使うコンピューター上にある個人用ストアです。

関連トピック

AppLocker の概要
コード整合性
Credential Guard
Device Guard による証明と法令遵守
Windows 10 での Device Guard に対するドライバーの互換性に関するブログ記事
Windows 10 の Device Guard を使ったマルウェアの脅威の撃破に関するビデオ

 

 

表示: