• [アーティクル]

セキュリティ

グループ ポリシーを使用してハードウェア制約を管理する

Jeremy Moskowitz

 

概要:

  • ハードウェアのインストールを制限する
  • 特定のデバイスを制限する
  • 一群のデバイスを制限する

お気付きのとおり、USB メモリをはじめとするさまざまなリムーバブル メディアは、プライベートでは便利でも、職場では厄介なものです。インストールできる

ハードウェア デバイスを制御する手段が必要です。幸い、Windows Vista™ および次期バージョンの Windows Server® (コードネーム "Longhorn") のグループ ポリシーを使用すると、USB マウスは許可しても USB ディスクオンキーは許可しない、CD-ROM リーダーは許可しても DVD ライタは許可しない、または Bluetooth は許可しても PCMCIA は許可しないといった制御が可能です。

ハードウェアのセキュリティには、グループ ポリシーの次の 2 つのセクションを利用できます。コンピュータの構成\管理用テンプレート\システム\リムーバブル記憶域へのアクセス (図 1 を参照) と、コンピュータの構成\管理用テンプレート\システム\デバイスのインストール\デバイスのインストールの制限 (図 2 を参照) の 2 つです。

図 1 グループ ポリシーの定義済みのハードウェアの制限

図 1** グループ ポリシーの定義済みのハードウェアの制限 **(画像を拡大するには、ここをクリックします)

図 2 制限するハードウェアの種類のカスタマイズ

図 2** 制限するハードウェアの種類のカスタマイズ **(画像を拡大するには、ここをクリックします)

1 つ目のセット (リムーバブル記憶域へのアクセス) は、読んで字のごとしです。特定のリムーバブル記憶域 (CD や DVD、フロッピーディスクなど) に対するポリシー設定を有効にすると、必要に応じてその種類のすべてのデバイスの読み取りや書き込みを制限できます。ただし、"デバイスのインストールの制限" ほどの強力な制限力はありません。

"リムーバブル記憶域へのアクセス" には、"カスタム クラス : 読み取りアクセス権の拒否" および "カスタム クラス : 書き込みアクセスの拒否" という名前のポリシー設定グループがあります。便利そうな名前ですが、"リムーバブル記憶域へのアクセス" ポリシーでは、ドライバのインストールを実際に防ぐことはできません。ハードウェアが検出された時点で、そのクラスのドライバは既にインストールされています。このポリシーの機能は、デバイスの読み取りと書き込みを防ぐことです。次のセクションでは、"デバイスのインストールの制限" ポリシー設定を取り上げ、ドライバ自体の使用を制限する方法を説明します。

クラスと ID を把握する

物事には順序があります。まず、制約する対象を把握する必要があります。この場合、大きく考えることも、小さく考えることもできます。つまり、特定の "クラス" のデバイスを制約することも、もっと細かく指定して、1 種類のハードウェアを制約することもできます。またはその逆に、USB マウスなど、特定のクラスのデバイスのみを許可することもできます。ただし、そこが面倒な部分です。本当に有効な設定を行うには、制約するハードウェアを突き止める必要があるからです。

したがって、"ジョイスティックはインストールできない" や "USB マウスのみインストールできる" という制限を設定するには、ジョイスティックと USB マウスについて把握している必要があります。または、インターネットを使用して、ハードウェア ID、互換性 ID、またはデバイス クラスを確認します。ただし、実際のデバイスが手元にあると、かなり簡単です。この場合は、コンピュータにこれを取り付け、ハードウェア ID、互換性 ID、またはデバイス クラスを自分で確認できます。一度確認できれば、そのデバイスの使用を禁止 (または許可) する方法が正確にわかります。

次の例では、Creative AutoPCI ES1371/ES1373 という特定のサウンド カード ファミリを禁止します。他のデバイス (特定の USB デバイス、USB ポートなど) を禁止する場合は、次の例を参考にして、デバイスの部分を目的のデバイスに置き換えてください。

目的のハードウェアが既にインストールされているコンピュータで、デバイス マネージャを起動します。デバイスを見つけて、右クリックし、[プロパティ] をクリックします。次に、[詳細] タブをクリックします。既定では、まず [デバイスの説明] が表示されますが、これはあまり有用な情報ではありません。[プロパティ] ボックスの一覧の [ハードウェア ID] をクリックします (図 3 を参照)。

図 3 デバイスの [詳細] タブ

図 3** デバイスの [詳細] タブ **(画像を拡大するには、ここをクリックします)

[ハードウェア ID] を選択すると、より限定的なものからそうでないものの順に、デバイス ID が表示されます。ハードウェア ID の値の一覧で一番上に表示されている項目をよく見ると、このサウンド カードは、ES1371 サウンド ボードの Rev 2 であることがわかります。これはかなり限定的です。一覧で順番が下の項目の説明ほど、限定的でなくなり、ファミリ全体が含まれるようになります。

また、プロパティを互換性 ID に変更することもできます。これも、ハードウェアを説明する項目ですが、ハードウェア ID の情報よりも限定的ではないと見なされています。互換性 ID はより限定的でなくなり、実際に含まれる範囲が広くなることが考えられるので、互換性 ID の情報を使用して、より多くの同種のハードウェアを使用禁止一覧に加えることもできます。もちろん、これと引き換えに、制限したくないものを制限してしまう可能性はあります。

また、[プロバティ] ボックスの一覧の [デバイス クラス] をクリックすると、最も限定的でないカテゴリが表示されます。この例のサウンド カードの場合、単に "Media" と表示されます。ただし、メディアと見なされるアイテムは多数あるため、より限定的でない値を選ぶ場合は、やはり注意が必要です。

使用する値を決めたら、その値を右クリックし、[コピー] をクリックして、確実に保存しておくためにメモ帳に貼り付けます。次の手順でこの値を正確に入力する必要があるため、表示されている文字列を直接コピーすることが重要です。大文字と小文字の違いも含めて、値を正確に入力する必要があります。

ハードウェア ID またはデバイス クラスの取得に、デバイス マネージャではなくコマンド ライン コマンドを使用する場合は、Devcon コマンド ライン ユーティリティ (support.microsoft.com/kb/311272) を試してみてください。また、マイクロソフトでは、共通クラスの ID を多数提供しています。これは、デバイスを物理的に参照できない場合に便利です。詳細については、go.microsoft.com/fwlink/?LinkId=52665) を参照してください。

グループ ポリシーを使用したハードウェア アクセス制御

コンピュータの構成\管理用テンプレート\システム\デバイスのインストール\デバイスのインストールの制限 (図 2 参照) に含まれるすべてのポリシー設定について説明しましたが、この最初の例を完了するために必要なものは実は 1 つしかありません。

まず、グループ ポリシー オブジェクト (GPO) を作成し、制御する Windows Vista コンピュータが含まれる OU (またはドメインなど) にこの GPO をリンクします。次に、この GPO を編集します。コンピュータの構成\管理用テンプレート\システム\デバイスのインストール\デバイスのインストールの制限\これらのデバイス ID と一致するデバイスのインストールを禁止するに移動します。このポリシー設定で [有効] を選択し、(同じくこのポリシー設定にある) [表示] をクリックして、[内容の表示] ダイアログ ボックスで [追加] をクリックします。次に、[項目の追加] ダイアログ ボックスに、前に保存しておいたデバイス情報を貼り付けます (図 4 参照)。

図 4 デバイス ID を貼り付けて説明を正確に入力する

図 4** デバイス ID を貼り付けて説明を正確に入力する **(画像を拡大するには、ここをクリックします)

ここで、気を付けなければならないことがあります。コンピュータに既にデバイスがインストールされている場合、このデバイスが自動的にアンインストールされ、デバイスへのアクセスが制限されることはありません。したがって、ハードウェアを制限する場合は、Windows Vista の展開プロセスの初期段階で、この設定を行う必要があります。ただし、Windows Vista は、デバイスが削除および再インストールされるたびに再度確認を行います。USB ドライブのようなアイテム (取り外され、後で再度挿入されるアイテム) は、このプロセスでの制御に適しています。Windows Vista は、デバイスが再インストールされたときのみ確認を行うので、(デバイス ドライバが既にコンピュータに読み込まれている場合でも) デバイスはその時点で制限されます。さらに問題が難しくなるのは、デバイスがコンピュータにプレインストールされていて、削除も再インストールもできない場合です。このようなデバイスには、簡単にすぐに実現できるソリューションはありません。

これまでインストールされたことのないハードウェア デバイスが取り付けられたコンピュータを起動すると、Windows はドライバのインストールを試み、進捗情報を表示します。このようなデバイスを制限するポリシーを設定している場合、図 5 のような処理結果が表示されます。

図 5 デバイスのインストールの阻止

図 5** デバイスのインストールの阻止 **(画像を拡大するには、ここをクリックします)

その他のハードウェア制限

前述の例では、1 デバイスのみを禁止しました。必要であれば、この反対の方法をとり、既定ですべてのハードウェアを制限し、そのうえで一部を許可することもできます。このようなポリシー設定も、コンピュータの構成\管理用テンプレート\システム\デバイスのインストール\デバイスのインストールの制限 (図 2) に含まれています。いくつか提供されている設定の中から任意のものを選択できます。

1 つ目は、"管理者によるデバイスのインストールの制限ポリシーの上書きを許可する" です。既定では、Windows Vista のローカル管理者よりも、既に設定されている制限が優先されます。この設定を有効にすると、ローカル管理者が制限を上書きし、必要なハードウェアをインストールできるようになります。

2 つ目は、"これらのデバイス セットアップ クラスと一致するドライバを使用したデバイスのインストールを許可する" です。このポリシー設定にデバイスの説明を入力することで、そのハードウェア デバイスのシステムへのインストールを明示的に許可します。このポリシー設定に使用できるのは、(前の例で使用した) デバイス ID ではなく、セットアップ クラスのみです。

前の例と反対の制限を行うには、"これらのデバイス セットアップ クラスと一致するドライバを使用したデバイスのインストールを禁止する" を設定します。

"インストールがポリシーによって禁止されている場合にカスタム メッセージを表示する (バルーン テキスト)" および "インストールがポリシーによって禁止されている場合にカスタム メッセージを表示する (バルーン タイトル)" の 2 つの設定により、メッセージをカスタマイズできます (図 5 参照)。

前述のとおり、より限定的でない形でハードウェアを説明する場合は、ハードウェア クラスを利用します。"これらのデバイス ID と一致するデバイスのインストールを許可する" ポリシー設定には、クラス ID の説明は使用できないことに注意してください。クラス ID の説明を使用するには、"これらのデバイス セットアップ クラスと一致するドライバを使用したデバイスのインストールを許可する" または "これらのデバイス セットアップ クラスと一致するドライバを使用したデバイスのインストールを禁止する" を使用します。後者のポリシー設定は、"他のポリシー設定で記述されていないデバイスのインストールを禁止する" と合わせて使用すると最も効果的です。すべてを禁止 (既定) したうえで、この設定を使用すると、許可するデバイスを正確に指定できます。

前の例では、"これらのデバイス ID と一致するデバイスのインストールを禁止する" ポリシーを使用して、デバイス ID を基に特定の種類のハードウェアを制限しました。デバイス クラスを使用して制限を実装する場合は、"これらのデバイス セットアップ クラスと一致するドライバを使用したデバイスのインストールを許可する" または "これらのデバイス セットアップ クラスと一致するドライバを使用したデバイスのインストールを禁止する" など、その他の設定を利用する必要があります。

"リムーバブル デバイスのインストールを禁止する" を使用すると、その名前が示すとおり、USB デバイスなどのリムーバブル ハードウェア デバイスを一様に簡単に制限できます。この設定はあまり限定的でないため、あまり頻繁には使用しないことをお勧めします。代わりに、前に説明した方法を使用して、ある程度限定的であるデバイス ID を取得し、この ID を持つデバイスを制限するようにします。

また、"他のポリシー設定で記述されていないデバイスのインストールを禁止する" は、包括的なポリシー設定で、何らかのデバイスのインストールを許可するよう特に定義していない限り、基本的にすべてのハードウェアを制限します。このポリシーと、各種の "～を許可する" ポリシー ("これらのデバイス ID と一致するデバイスのインストールを許可する" など) を組み合わせると、個々の環境に必要なハードウェアのみを許可する非常に強力なツールとして使用できます。

まとめ

Windows Vista のグループ ポリシーには、多数の新しい強力な機能があります。これらは、各環境に必要なハードウェアのみを使用できるようにする場合に非常に便利です。展開プロセスの初期段階でポリシー設定を実装するだけで、不要なハードウェアがネットワークに接続されないようにすることができます。

マイクロソフトでグループ ポリシーのリード プログラム マネージャを担当している、Michael Dennis へのインタビュー

最近、Michael Dennis にインタビューをする機会がありました。彼は、マイクロソフトでグループ ポリシー チームが発足された当初から、このチームの舵を取っています。Michael は現在、グループ ポリシー チームを去り、マイクロソフト内の別の職務に就こうとしています。これまでのグループ ポリシーの 9 年間を振り返り、その過去とこれからの展望について、Michael に話を聞きました。

Jeremy Moskowitz Michael さん、あなたがマイクロソフトでこれまでグループ ポリシー チームを統率してきた中で、最大の成果は何だとお考えですか。これを知りたがっている人は多いと思います。

Michael Dennis 最大の成果は、かなりさかのぼって、グループ ポリシーと呼ばれるものの開発に本格的に乗り出したときのことです。既に Windows NT® 4.0 のシステム ポリシーがあったので、このシステム ポリシーとその問題点について調査しました。このときは、Active Directory® を開発している時期だったので、クライアントとサーバーの管理性を強化する必要がある部分に注目しました。

グループ ポリシーの階層化は、それまで実現されたことがなかっただけに、とてつもない考えでした。ですから、中核となるインフラストラクチャ、クライアント プロセス、および Active Directory との統合に注力しました。

最大の成果の副産物は、最悪の成果でもありました。これは、Windows 2000 でリリースした GUI に問題があったためです。管理者がグループ ポリシーを有効に利用するには、全体がどのように機能するかを理解している必要があったため、グループ ポリシーについての博士号なみの知識が必要でした。あの当時に、グループ ポリシー管理コンソール (GPMC) とポリシーの結果セット (RSoP) を開発して提供できていたらよかったと思います (これは仕様には盛り込まれていました)。

JM グループ ポリシーに実装できていたらよかったと思うものは何ですか。

MD 嬉しいことに、Windows 2000 のリリース以降に望んでいたものが、現在 Windows Vista で実現できています。それは、RSoP、GPMC、新しい設定などです。これらをもっと早くに実現できればよかったと思います。

また、グループ ポリシーのインフラストラクチャが、パートナーがもっと拡張しやすいものであればよかったと思います。私たちのサーバー側/クライアント側拡張モデルでは、開発者がかなりの作業を行う必要があります。ただし、ADM/ADMX テンプレート構造により、拡張性の高いフレームワークが提供されているので、これは議論の余地があるところです。それでも、システムのこの部分を使用して、より多くの種類の設定を拡張できるようになっていたら、もっとよかったでしょう。

あと、GPMC レポートも、パートナーおよびサードパーティのツール開発者にとって、より拡張性の高いものであればよかったと思います。これは、サードパーティのツール ベンダから強く言われている部分です。

JM グループ ポリシー チームについて、一般に知られていないことは何ですか。

MD ときどき、グループ ポリシー チームが全体でどの位置を占めるのかが明確でないことがあります。考え方としては、インフラストラクチャ、トランスポート、およびサーバー側/クライアント側モジュールを開発するチームです。ただし、Windows Vista だけでも、マイクロソフトの他の 120 チームと協力して、このリリースに実装されている新しい設定を開発しました。

読者の方にご理解いただきたいのは、起動時やログオン時にシステムのパフォーマンスが低下する問題の原因は、グループ ポリシーではないということです。パフォーマンスの低下を引き起こしているのは、グループ ポリシーのペイロードです。何か負荷の高い作業を行うようにグループ ポリシーを設定している場合、それが実行されます。たとえば、Microsoft Office をコンピュータごとにインストールするように設定している場合は、かなり時間がかかるでしょう。しかし、グループ ポリシーは設定されたとおりの操作を実行していることをご理解ください。つまり、ログオン画面が表示される前に、Office 全体をインストールするという操作です。これは、パフォーマンスの低下と言えるでしょうか。確かに動作は遅くなりますが、展開した管理者にとっては、これこそシステムで実行されるように設定した動作そのものなのです。

JM グループ ポリシーを使用して、一番自慢したいことは何ですか。

MD 最近は、Windows Vista に組み込まれた新しい設定が自慢です。リムーバブル デバイス用の設定 (USB スティックなどを制限する設定) は、皆さんから強く要望されていた設定です。Windows Vista には、約 2,400 の設定があり、管理者はこれらを使用してかなり高度な制御を行うことができます。私は、お客様に制御したいものをたずねて、その方法をお見せするのが好きです。

JM ADM ファイルから ADMX ファイルに変更したのはなぜですか。

MD 技術的には、Windows Vista に新しい中央ストア機能を実装するために、この変更を行う必要はありませんでした。ADMX に変更した最大の理由は、多言語を適切にサポートできるようにするためでした。

これまで、多言語環境では、GPO 内部の ADM ファイルのコンテンツが、別の言語によって誤って上書きされてしまうことがありました。経緯をたどると、ADM 形式は Windows NT 4.0 から受け継いだもので、その元は Windows 98、そのまた元は Windows 95 で採用されていたものです。その頃に XML があれば、ファイル形式の候補に XML が挙がっていたでしょう。

しかし、現在は XML があります。他言語のサポートが容易になったほか、スキーマ化された言語を使用して、レジストリや設定を拡張することもできます。

JM GP チームで仕事をしている間に、乗り越えなければならなかった最大の内部の課題は何でしたか。

MD 現在もチームが直面している最大の課題は、他の Windows コンポーネントの機能をポリシーに対応させることです。

たとえば、あるチームは「このすばらしい新機能は開発が完了したばかりだ。だれがこれを無効にしたいと思うんだい」と反論するかもしれません。その気持ちはよくわかります。しかし、私たちはこのような問題を多数乗り越えてきたのです。

また、ポリシーによって機能を有効にすることには技術的な課題もあります。たとえば、新しいセキュリティが強化された Windows ファイアウォール (WFAS) がそうです。WFAS は非常に厄介でした。これを正しくポリシーに対応させるのは、簡単なことではありません。WFAS チームが Windows Vista 向けに作成したインターフェイスはすばらしいものですが、これを適切に処理することは非常に困難です。

Windows Vista より前のバージョンの Windows では、製品チーム自らが、担当コンポーネントをポリシーに対応させることを常に考慮していたわけではありません。しかし、Windows Vista の開発においては、かなりの数のチームがその方法を質問してきました。このことは印象的でした。

JM 次は何をされるのですか。

MD "モバイル インフォメーション ワーカー" チームに移ります。スマート フォン、Pocket PC などを担当しているチームです。私の役目は、Windows Server System の一部の管理テクノロジを Windows Mobile® デバイスに移植することです。

管理性に対するこれまでと同じビジョンと情熱をもって、新しい職務に取り組んでいくつもりです。当面の間は完全に異動せずに、私がいなくても物事が進むように、グループ ポリシー チームを離れる準備をします。

JM 他に何か読者に伝えたいことはありますか。

MD グループ ポリシーの開発を通じて常に重要だった作業の 1 つは、お客様と向き合い、お客様が何をしようとしているのかを十分に理解することでした。お客様がグループ ポリシーで対応してほしいシナリオについてよくまとまった意見をお持ちで、何かを実行するためのビジネス ケースがある場合は、それをお知らせいただく必要があります。

どなたでも利用できるすばらしいフィードバック システム (WindowsServerFeedback.com) をご用意しています。そこで、グループ ポリシー用のボタンを探してください。

"こんな問題がある、こんなビジネス ケースがある、こんなことを行うシステムが必要で、その理由はこうだ" といった情報をお寄せいただくと、非常に助かります。グループ ポリシーの今後の方針を決める担当者は、ここから寄せられたフィードバックにすべて目を通します。

繰り返しになりますが、グループ ポリシーの機能強化に一石を投じたいと思われる方は、何を必要とされているかお知らせください。ただし、理由を説明せずに、"こういうことをするポリシー設定が必要だ" という形でのご意見はご遠慮ください。「How (方法)」を解明するのが私たちの仕事です。グループ ポリシー チームが本当に知る必要があるのは、「Why (理由)」なのです。

JM マイクロソフトのグループ ポリシー チームでのご経験をお聞かせいただき、ありがとうございました。今後のご活躍をお祈りしています。

MD ありがとうございます。

Jeremy Moskowitz(グループ ポリシーの MCSE および MVP) は、グループ ポリシーのコミュニティ フォーラム、GPanswers.com を運営しています。また、グループ ポリシーについての一連の集中トレーニング ワークショップも開催しています。最近の著書には『Group Policy: Management, Troubleshooting and Security』(Sybex、2007 年) があります。Jeremy には、www.GPanswers.com から連絡してください。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.