Windows Vista

ユーザー アカウント制御を使用して、管理者以外のユーザーの夢を実現する

Alex Heaton

概要:

• 管理者で実行してはいけない理由
• 標準ユーザーで実行すると発生する問題への対処
• ユーザー アカウント制御のしくみ

大部分の IT 組織では、管理者特権の本当の目的を理解して実行しているユーザーはほとんどいません。多くの IT 管理者は、ユーザーを標準ユーザー アカウントに制限する方がよいことを認めていますが、約 80% の IT 管理者はデスクトップを管理者アカウントで展開しています。そのため、マルウェアに感染する危険性が高まり、管理が困難になっています。

しかし、管理者アカウントを使用しないことは容易ではありません。管理者以外のアカウントを使用すると、問題に直面する可能性が高くなります。

まず、アプリケーションの互換性の問題があります。多くのアプリケーションは管理者アカウントを使って作成やテストが行われているので、標準アカウントの下では実行さえできない場合があります (アプリケーションでは、Program Files ディレクトリや HKLM レジストリ キーなど、制限された領域に書き込みを試みるため、この状況はほとんどの場合に当てはまります)。

次に、以前のバージョンの Windows® では、ユーザーが構成できる設定に多くの制限がありました。標準ユーザーは、有償でヘルプデスクに電話をかけないと、タイム ゾーンや電源設定を変更したり、セキュリティ保護されたワイヤレス ネットワークに接続したり、ActiveX® コントロールをインストールしたりできませんでした。

さいわいなことに、Windows Vista™ ではこうした問題点が解決されます。ユーザーに管理者アカウントがなくても、Windows Vista のユーザー アカウント制御 (UAC) などの管理テクノロジによって、デスクトップのサポートと管理、標準ユーザーの生産性向上の促進、およびセキュリティ設定に違反しない作業の実行が容易になります。これらはアクセス制御リスト (ACL) を変更することによって実現します。ACL の変更は、ユーザーにカスタマイズされた優れたアクセスを提供する一般的な方法です。Windows Vista では、アクセス制御の問題がどの程度軽減されるかを、さらに詳しく見ていきましょう。

仮想化による互換性の向上

ファイルとレジストリの仮想化機能により、Windows XP では標準ユーザーで実行できない多くのアプリケーションを、Windows Vista では変更することなく実行できるようになります。Windows XP では、ファイル システムやレジストリの、標準ユーザーにはアクセス権限がない保護された領域に書き込みを試みると、多くのアプリケーションが終了します。Windows Vista では、書き込み (およびその後のファイルやレジストリの読み取り) をそのユーザーのプロファイル内の専用の場所にリダイレクトすることで、互換性を向上しています。たとえば、アプリケーションから C:\program files\contoso\settings.ini への書き込みを試み、ユーザーにそのディレクトリへの書き込み権限がなければ、その書き込みは C:\Users\username\AppData\Local\VirtualStore\Program Files\contoso\settings.ini にリダイレクトされます。**アプリケーションから HKLM\Software\Contoso\ に書き込みを試みると、この操作が HKCU\Software\Classes\VirtualStore\MACHINE\Software\Contoso に自動的にリダイレクトされます。図 1 にリダイレクトのプロセスの概要を示します。なお、Certified for Windows Vista Software ロゴ プログラムでは、こうした仮想化を必要としないで標準ユーザーでアプリケーションを実行することが求められます。標準ユーザーで実行できないと、そのアプリケーションにロゴが授与されません。

図 1** ファイルとレジストリの仮想化プロセス **

標準ユーザーが実行できる多くの操作

Windows Vista では、標準ユーザー アカウントの特権が追加されているため、ユーザーはヘルプデスクのサポートや管理者アカウントによって提供される完全な権限のセットがなくても、一般的な作業を実行できます。追加された新しい特権には、システム時計とカレンダーを表示する権限、タイム ゾーンを変更する権限、ワイヤレス ネットワークのセキュリティ設定を変更する権限、電源管理設定を変更する権限、Windows Update から重要な更新をインストールする権限などがあります。

また、Windows Vista では、ディスクの最適化が自動的にスケジュールされたプロセスになります。管理者特権を必要とする操作には盾アイコンが示されるため、ユーザーは各構成の変更が可能かどうかを確認できます。

ActiveX コントロールのインストール

ActiveX コントロールは頻繁に更新されることがあり、Systems Management Server (SMS) などのソフトウェア配布プログラムやグループ ポリシーを使用して配布前に再パッケージ化が必要なので、一元的に管理することが特に困難です。Windows Vista には、IT 管理者がグループ ポリシーを使用して Web サイトを指定し、その Web サイトから標準ユーザーが ActiveX コントロールをインストールできるようにする、ActiveX インストーラ サービスというオプション コンポーネントがあります。ActiveX インストーラ サービスを使用するには、次の操作を行います。

1. クライアント コンピュータで ActiveX インストーラ サービスを有効にします。コントロール パネルの [Windows の機能] アプレットを使用するか、デスクトップ イメージを構成すると、サービスを有効にすることができます。
2. [Active Directory Group Policy] の [コンピュータの構成] で、[管理用テンプレート]、[Windows コンポーネント] の順に展開し、[ActiveX Installer Service] を選択します。[有効] をクリックします。これで、ポリシーがユーザーに複製された後、指定するサイトからコントロールをインストールできるようになります。

ActiveX コントロールなどの実行可能なコードは、悪意のある作業を実行する可能性があるため、この機能は慎重に使用する必要があります。信頼するベンダのものを、厳しく管理されたイントラネット サイトで使用してください。

ActiveX コントロールのインストーラ サービスは、Windows Vista のイベント監視インフラストラクチャとも統合されているため、ユーザーがインストールする必要のある ActiveX コントロールがある場合に、自動的に通知を受け取ることができます。標準ユーザーが未承認のコントロールをインストールすると、サービスによってアプリケーション ログにイベントが記録されます。Windows Vista では、タスクを構成して、イベントがトリガされたらすぐに自動的に電子メールを送信したり、別のプログラムを実行したりすることができます。その結果、ユーザーがコントロールを必要とするときに、ユーザー操作を長時間中断させることなく、グループ ポリシーにそのサイトを追加できます。Windows Vista では、企業全体の複数のコンピュータからのイベントをサブスクライブして、ユーザーがインストールを試みているすべてのコントロールの一覧を生成することもできます。

ハードウェア デバイス ドライバのインストール

特にラップトップでは、ユーザーが出張中に必要なデバイス ドライバをインストールできないという問題が生じるため、管理者権限が使用される原因の 1 つになっています。Windows Vista の新しいドライバ ストアのインフラストラクチャでは、標準ユーザーがインストールできるデバイスを柔軟に制御できるようにすることで、この問題を緩和しています。まず、信頼済みのドライバををあらかじめドライバ ストアに格納しておくことができるため、ユーザーは必要に応じて許可されたデバイスをインストールできます。次に、グループ ポリシーを使用して、プリンタなどのデバイスの種類、または認定済みのフラッシュ ドライブなどの特定のデバイスのハードウェア ID をインストールする権限を標準ユーザーに許可することができます。

Windows Vista のドライバ ストアは、各クライアント コンピュータのハード ドライブ上の製品付属のドライバやサード パーティのドライバの信頼済みのキャッシュなので、ユーザーは管理者特権がなくてもインストールできます。ドライバ ストアにドライバを配置するには、ドライバをオフライン イメージに挿入するか、ドライバをネットワーク経由でオンライン クライアントに動的に更新することができます。オフライン イメージに挿入する場合は、パッケージ マネージャを使用してドライバ ストアにドライバをシームレスに格納します。

オンライン イメージの場合は、ソフトウェア配布アプリケーションと、pnputil.exe や DevCon などのコマンド ライン ユーティリティを組み合わせて使用して、ドライバ ストアでのドライバの追加、更新、または削除を行います。ドライバの準備プロセスをさらに簡素化して柔軟性を高めるために、Windows Vista には IT 部門とサード パーティがドライバ パッケージに署名して整合性を確保する機能が用意されています。

既定では、管理者権限のあるユーザーのみが新しいドライバをドライバ ストアに追加できます。ただし、ユーザー (特にモバイル ユーザー) の重要なニーズに、移動中にプリンタなどのデバイスをインストールしたいというのがあります。Windows Vista ではグループ ポリシーに新しい設定を用意し、ドライバ ストアにドライバがまだ準備されていない場合でも、標準ユーザーが認定済みのデバイスをインストールできる柔軟性を提供しています。デバイス ドライバを準備する特権を委任するには、グループ ポリシーのインターフェイスを開き、[コンピュータの構成] の [管理用テンプレート] を展開し、[システム]、[ドライバのインストール] の順に展開します。次に、[Allow non-administrators to install drivers for these devices] をダブルクリックします。この場合、標準ユーザーが準備およびインストールを希望するデバイス クラスの GUID を把握する必要があります。MSDN® (英語) からオンラインでデバイス クラスを見つけることができます。または、デバイスがコンピュータにインストールされている場合は、[デバイス マネージャ] の [プロパティ] ウィンドウを確認します。[詳細] タブをクリックし、[デバイス クラス GUID] というラベルの付いたドロップダウン リストをクリックします。ドライバの署名に使用される証明書が、クライアント コンピュータの信頼された発行元のストアに既にあることを確認する必要もあります。これは、グループ ポリシーによって管理できます。

Windows Vista でのこうした機能強化により、デバイスのインストールに必要な柔軟性が標準ユーザーにもたらされるので、これまでよりも多くのユーザーを管理されたデスクトップ環境に移行できます。

デスクトップ ロックダウンのレベル

Windows Vista OS で上記の点が強化されているとしても、すべての組織がすべての Windows Vista デスクトップを標準ユーザーの権限で展開できるわけではありません。組織によっては、依然として管理者特権を必要とするアプリケーションが存在していたり、開発者などのユーザーが独自のソフトウェアをインストールする必要がある場合もあります。それでも問題はありません。Windows Vista では、ユーザー アカウントの選択やグループ ポリシーを使用して構成できる複数のレベルのデスクトップ制御が可能です。こうしたことをすべて利用することで、Windows XP で完全な管理者アカウントを使用していた頃よりも、管理の容易性とセキュリティが向上します。UAC 設定に関する大部分のシステム設定は、図 2 に示すセキュリティ ポリシー エディタ (secpol.msc) で行うことができます。

図 2** セキュリティ ポリシー エディタ **(画像を拡大するには、ここをクリックします)

制御の最初のレベルを "管理者承認モード" と呼びます。このモードでは、プログラムが既定で標準ユーザーの特権で起動され、プログラムから管理者特権の必要な操作を実行しようとすると、ユーザーに警告が行われ、ある種のマルウェアによる攻撃の脅威が軽減されます。このモードでは、ユーザーが管理者権限が必要なプログラムを実行すると、イベント ログを使用して監査を実行できます。ただし、アプリケーションは標準ユーザーの特権で実行されますが、実際の標準ユーザー アカウントと同じセキュリティは提供されないことを覚えておいてください。ユーザーには依然として管理者特権があるので、ポリシー設定の変更、未承認のソフトウェアのインストール、およびルートキットなどの強力なマルウェアのインストールの許可が可能です。

次のレベルは最初のレベルを基に構築されますが、グループ ポリシーを使用して、信頼された発行元のストアにある証明書で署名されるプログラムの特権の昇格を制限します。この制限は、未署名のマルウェアが管理者特権を取得できないようにするのに役立つため、ユーザーが自由にソフトウェアをインストールするのを防ぐことができます。ただし、管理者アカウントで実行していると、知識が豊富で不謹慎なユーザーや巧妙なマルウェアは、少なくとも一時的にポリシーを無効にして、不正な操作を実行できます。したがって、これら最初の 2 つのレベルは、実際の標準ユーザー アカウントでは実行できないすべての問題を解決するまでの一時的な解決策として使用します。

セキュリティの次のレベルでは、ユーザーを管理者アカウントから削除し、削除したユーザーを標準ユーザーにします。UAC の機能の 1 つに、標準ユーザーが管理者の資格情報が必要なプログラムを起動する場合に既定で表示される "肩越し (Over the Shoulder) 資格情報ダイアログ" と呼ばれるものがあります。標準ユーザーでは操作がブロックされますが、管理者のユーザー名とパスワードがわかっていれば、それらを入力して操作を続行できます。この機能を使用する一般的なシナリオには、出張中のラップトップ ユーザーに関するものがあります。たとえば、このユーザーが出張中に緊急でソフトウェアをインストールする必要が生じた場合、ローカル管理者アカウントのパスワードを提供できるヘルプデスクに電話して、入手したパスワードを入力するとプログラムを実行できるようにします (図 3 を参照)。管理者のパスワードをユーザーに提供する場合は、ユーザーがネットワークに再接続するときに管理者のパスワードを再設定するためのプロセスとツールを用意しておくことと、管理者の資格情報を使用して実行されるプログラムのログ記録を行うことをお勧めします。また、コンピュータがマルウェアに感染した場合、管理者が欺かれ、意図しないマルウェアに管理者特権を与えてしまう可能性があることを認識しておいてください。

図 3** 管理者パスワードの入力画面 **(画像を拡大するには、ここをクリックします)

グループ ポリシーを使用して、資格情報ダイアログを無効にすることもできます。設定するユーザー アカウント制御は、"昇格の要求を自動的に拒否する" という設定で、標準ユーザーに特権の昇格を確認する動作です (図 4 を参照)。このように、標準ユーザーのデスクトップを展開するほとんどの企業では UAC を構成することを推奨しています。ほとんどの組織では、ユーザーがヘルプデスクに電話して IT 部門に教えたくないパスワードを尋ねることがないように、この設定を行うことになります。

図 4** グループ ポリシーによるアプリケーションのブロック **(画像を拡大するには、ここをクリックします)

最も厳しいレベルのデスクトップ ロックダウンでは、UAC と標準ユーザー アカウントを Windows のソフトウェアの制限のポリシー (SRP) と組み合わせて使用できます。企業は SRP を使用してさらに踏み込んだ制御が可能になり、特別に許可されていないソフトウェアの実行を防ぐことができます。SRP は、Authenticode® 証明書、ハッシュ、パス、またはインターネット ゾーンに基づく特定の条件を満たす場合を除き、ソフトウェアの実行をブロックするようにデザインされています。SRP はグループ ポリシーで管理されるので、非常に強力なポリシーを作成して、未承認のプログラムを簡単にインストールおよび実行できないようにすることができます。一般的なポリシーでは、パス %WINDIR% と %PROGRAMFILES% にあるものを除き、すべての実行可能ファイルを許可しません。このポリシーを管理者以外のすべてのユーザーに適用します。

IT スタッフは、このポリシーを適切に設定すれば、各 .exe をホワイトリスト (承認済みの項目の一覧) に追加しないでも、必要なソフトウェア プログラムをすべて Program Files ディレクトリにインストールできます。標準ユーザーはこれらのディレクトリにアクセスできないので、.exe を実行可能な場所に配置することができません。

Power Users グループに関する説明がないことにお気付きかもしれません。それは、Power Users グループが Windows Vista から削除されたためです。一部の組織では、管理者特権を制限する目的で Power Users グループを使用していました。あるユーザーを Power Users グループに含めると、そのユーザーは未承認のシステム構成を作成できなくなりますが、そのユーザー (または Power Users の資格情報で実行しているマルウェア) は、追加の権限やアクセス許可だけでなく、完全な管理者の資格情報さえも取得できる場合があります。そのため Windows Vista には、主要なアカウントとして管理者と標準ユーザーの 2 種類しかありません。

デスクトップ管理のインフラストラクチャ

ファイルとレジストリの仮想化、新しいドライバ ストアのインフラストラクチャなどの前述の機能を使用することによって、標準ユーザー アカウントでの Windows Vista のデスクトップ展開が極めて容易になります。ただし、これらのテクノロジを使用しても、自分で操作できないユーザーをサポートするための管理インフラストラクチャ (ツール、プロセス、および要員) がなければ、標準ユーザーの環境を完全にはサポートできません。次に、考慮する必要がある問題点をいくつか示します。

ソフトウェアのインストール ユーザーがソフトウェアを自身でインストールできない場合は、別の方法を用意する必要があります。1 つはグループ ポリシーを使用する方法です。この方法では、他の管理ソフトウェアは必要ありません。グループ ポリシーを使用すると、[プログラムの追加と削除] の一覧にプログラムを追加できます。ユーザーがこの方法を使用してプログラムをインストールすると、インストールの完了に必要な権限にユーザーの特権が昇格されてインストールが開始されます。SMS または同様の製品を使用する機能豊富なソリューションも可能です。さらに、標準ユーザーがインストールするソフトウェアを選択できる、セルフサービスの Web ポータルを作成するようなソリューションも実現できます。

ソフトウェアの更新 "この更新プログラムをインストールしてください" といった内容の電子メールを送信する以外の方法で、更新プログラムをコンピュータにインストールする方法が必要です。ほとんどのマイクロソフトの更新プログラムを管理および展開するには、Windows Server 用の無料ダウンロード サイトの Windows Server Update Services を使用できます。また、更新プログラムを広範に展開するには、SMS などのデスクトップ管理製品の使用を検討してください。

サポート プロセスと要員手配 ユーザーがヘルプデスクに電話して、パフォーマンスの問題の原因究明や、何か新しいソフトウェアのインストールを希望するときは、多くの場合、ユーザーにアクセス許可がないため、プロセスを電話で説明することしかできません。IT 部門では、リモート アシスタンスやリモート管理ツールを使用して、問題を診断して設定を変更する必要があります。ヘルプデスクのスタッフはリモート デスクトップを使用して管理上の変更をリモートで行うことができますが、ログインした標準ユーザーは管理者特権が必要な操作を求められても承認されないため、それぞれ Windows リモート アシスタンスの動作が異なります。

ポリシーの例外を処理するための、明確で効率的なプロセスを用意することが重要です。たとえば、マーケティング部門のメンバが、新しいグラフィック デザイン ツールの試用版をインストールする必要があるとします。彼女は部門を代表してこのツールを評価します。そのソフトウェアをインストールする許可を与えるのはだれでしょう。部長、彼女の上司、それとも CIO でしょうか。インストールの方法はどうでしょう。承認を待つ余裕はどの程度あるでしょう。このような場合に備えて、ヘルプデスクの問題追跡システムに統合される、簡単な承認のワークフローを作成することをお勧めします。基本的なワークフローは次のとおりです。

1. ユーザーがプログラムのインストール要請と、インストール プログラムへのリンク (ローカル ハード ドライブまたは CD-ROM) を送信し、ソフトウェアが違法に取得したものではないこと、悪意のある目的に使用しないことを確認します。
2. 要請が承認のためにマネージャに送信されます。
3. 要請が IT 部門のアプリケーション リードに転送され、既知の互換性の問題がないこと確認され、ウイルス スキャンが実行されて、その会社で既にそのプログラムや別のベンダの同様のプログラムのサイト ライセンスを購入していることが確認されます。
4. 要請がサポート技術者に転送され、リモートでインストールが開始され、ソフトウェアを使用する準備が整ったらユーザーに通知されます。

ワークフローのインターフェイスを作成するには、動的にスクリプトを実行する Web ページを作成するか、市販のヘルプデスク アプリケーションや問題追跡パッケージを入手します。管理されていない環境と管理された環境とで異なる要員手配を行うことも必要です。うまくいけば、物理的な診断や、動作が不安定なコンピュータや感染したコンピュータのイメージの再作成に必要な技術者を減らせるでしょう。ただし、ソフトウェアのパッケージ化や展開を行うために、最初に追加のスタッフ投入が必要になる場合もあります。

長期間運用していると、コンピュータが安定した状態を保つ期間が長くなるため、サポートにかかるコストも低くなりますが、初期段階には構成についての支援を求めるユーザーからヘルプデスクへの電話が増える場合があります。ユーザーが必要とする設定や希望する設定に従ってデスクトップ イメージやグループ ポリシーの構成を完了すれば、ヘルプデスクへの電話は次第に減っていきます。

考え方

最後のハードルは、技術的な問題ではなく、心理的な問題です。ユーザーによっては、管理者特権がないという考えに拒否反応を示す場合があります。しかし、ほとんどのユーザーはその違いに気付かないと思います。また、標準ユーザー アカウントを適用すると同時に Windows Vista を展開すれば、統合デスクトップ サーチ、新しい Aero™ (Aero Glass) ユーザー インターフェイス、モバイル ユーザー向けの機能強化などによる生産性向上のメリットは、管理者でないことによって生じるすべての不都合を十分補うことができます。ただし、1 つのソフトウェアをインストールするアクセス許可を得るために、ユーザーを何週間も待機させるような不十分なプロセスであれば、不運な従業員が増えると予測できます。

基本的に、コンピュータ資産のセキュリティを確保すること、ライセンスを取得していないソフトウェアの使用を防止すること、および政府規則や企業内のポリシーの遵守を施行することは、IT 部門の役割です。この役割を果たす唯一の方法が、管理者特権のあるユーザー数を制限する新しいポリシーの制定であることが、多くの企業で明らかになります。さいわい Windows Vista では、このことが極めて容易であることがわかります。

参考資料

管理者特権の削減に関するヘルプについては、以下のサイトを参照してください。

• Aaron Margosis’s Non-Admin blog—Running with Least Privilege on the Desktop (英語)
• The User Account Control WebLog (英語)
• ユーザー アカウント制御の概要
• Understanding and Configuring User Account Control (英語)
• Virtual Lab: User Account Control (英語)

Alex Heaton は、Windows Vista セキュリティ チームのシニア プロダクト マネージャです。以前は、microsoft.com/japan/protect などのマイクロソフト セキュリティ Web サイトのリード サイト マネージャでした。また、blogs.msdn.com/uac (英語) でユーザー アカウント制御チームのブログも担当しています。

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