• [アーティクル]

ユーザー アカウント制御

Windows 7 ユーザー アカウント制御の内部

Mark Russinovich

 

概要:

  • 標準ユーザー アカウント
  • ユーザー アカウント制御

目次

UAC テクノロジ
昇格とマルウェア セキュリティ
Windows 7 と以前のバージョンの違い
自動昇格
自動昇格と UAC の目標

標準ユーザー アカウントは、家庭と企業の両方の環境でセキュリティの強化と総保有コストの削減をもたらします。ユーザーが管理者権限ではなく標準ユーザー権限で実行した場合、システムのセキュリティ構成 (ウイルス対策とファイアウォールを含む) は保護されます。これにより、ユーザーのアカウントおよびシステムのその他の部分を保護することができる、セキュリティで保護された領域がユーザーに与えられます。企業の展開では、デスクトップ IT 管理者によって設定されたポリシーを無効にすることはできず、家庭で共有されているコンピュータでは、各ユーザー アカウントが他のアカウントによって加えられた変更から保護されます。

しかし、Windows には、管理者権限で実行するユーザーの長い歴史があります。そのため、ソフトウェアは、管理者アカウントで動作し (多くの場合、無意識に) 管理者権限に依存するように作られることがよくありました。より多くのソフトウェアが標準ユーザー権限で動作できるようにすること、そして開発者が標準ユーザー権限で正常に動作するアプリケーションを記述できるようにすることを目的として、Windows Vista にはユーザー アカウント制御 (UAC) が導入されました。UAC は複数のテクノロジの集まりで、ファイル システムとレジストリの仮想化、保護された管理者 (PA) アカウント、UAC 昇格時のプロンプト、およびこうした目標をサポートする Windows Integrity レベルがこれに含まれます。これらの詳細については、カンファレンスのプレゼンテーションでお話ししました。また、TechNet Magazine の UAC の内部に関する記事でも説明しました。

Windows 7 では、基になるテクノロジをあまり変えないようにしつつ、UAC の目標をさらに進展させています。ただし、Windows 7 には、UAC の PA アカウントで実行できる 2 つの新しいモード、およびいくつかの組み込み Windows コンポーネント用の自動昇格メカニズムが導入されています。今回の記事では、UAC のテクノロジの背後にある目的を取り上げ、UAC とセキュリティの関係について再び説明し、2 つの新しいモードについて述べ、自動昇格の具体的なしくみについて説明します。この記事に記載されている情報は Windows 7 Release Candidate の動作に基づいており、Windows 7 Release Candidate は Windows 7 Beta とはいくつかの点で異なることに注意してください。

UAC テクノロジ

UAC のテクノロジの最も基本的な要素であり直接のメリットでもあるのは、単純に、標準ユーザーにとって Windows がより使いやすくなるということです。わかりやすい例は、Windows XP と Windows Vista でタイム ゾーンを設定する場合に必要となる特権の違いです。Windows XP では、タイム ゾーンを変更するには (それどころか、時刻/日付のコントロール パネル アプレットでタイム ゾーンを確認するのにも) 管理者権限が必要です。

これは、Windows XP では時刻の変更 (セキュリティに影響を与えるシステム操作です) とタイム ゾーンの変更 (時刻の表示方法に影響を与えるだけです) が区別されないためです。Windows Vista (および Windows 7) では、タイム ゾーンの変更は管理操作ではなく、時刻/日付のコントロール パネル アプレットでは管理操作と標準ユーザーの操作が分離されています。この変更だけでも、多くの企業は移動するユーザーを標準ユーザー アカウントで構成できるようになります。ユーザーは自分が現在いる場所に合わせてタイム ゾーンを調整できるからです。これに加え Windows 7 ではさらに、システムの IP アドレスを更新する、Windows Update を使用して必須でない更新プログラムやドライバをインストールする、ディスプレイ DPI を変更する、現在のファイアウォール設定を確認するなどの操作を標準ユーザーが実行できるようになっています。

無意識に管理者権限を使用する多くのアプリケーションが管理者権限なしでも正常に動作するようにするため、ファイル システムとレジストリの仮想化が背後で機能します。管理者権限が不必要に使用される最も一般的な例は、レジストリ内やファイル システム内の領域のうちシステムが使用する領域への、アプリケーション設定やユーザー データの保存です。たとえば、一部のレガシ アプリケーションでは、レジストリ内の、ユーザーごとの部分 (HKEY_CURRENT_USER\Software) ではなくシステム規模の部分 (HKEY_LOCAL_MACHINE\Software) にアプリケーション設定が保存されます。レジストリの仮想化により、システム規模の場所への書き込みは HKEY_CURRENT_USER (HKCU) への書き込みに変換されますが、アプリケーションの互換性は維持されます。

PA アカウントは、開発者が標準ユーザー権限のみを必要とするアプリケーションを記述するよう促す一方で、管理コンポーネントと標準ユーザー コンポーネントの間で状態を共有する同じくらい多くのアプリケーションが引き続き機能できるようにすることを目的としています。既定では、Windows Vista システムまたは Windows 7 システムの最初のアカウントは PA アカウントです (以前のバージョンの Windows では、最初のアカウントは完全な管理者アカウントでした)。ユーザーが明示的にアプリケーションを昇格しない限り、PA ユーザーが実行するプログラムはすべて標準ユーザー権限で実行されます (アプリケーションを昇格すると、アプリケーションに管理者権限が付与されます)。昇格時のプロンプトは、ユーザーがアプリケーションのインストールやシステム設定の変更などの操作を行うと起動されます。こうした昇格時のプロンプトは最も明白な UAC テクノロジであり、このプロンプトが起動されると、許可/キャンセルのダイアログと背景として灰色表示されたデスクトップのスナップショットとで構成される画面に切り替わります。

インストール後に作成されるアカウントは既定では標準ユーザー アカウントです。このアカウントでは、管理者権限の付与に使用する管理者アカウントの資格情報を入力するよう求める "Over The Shoulder (肩越し)" プロンプトを通じて、昇格を行うことができます。この機能により、自宅のコンピュータを家族と共有しているユーザーや、よりセキュリティに敏感で標準ユーザー アカウントを使用しているユーザーは、管理者アカウントのパスワードを知っていれば、手動で別のユーザー ログオン セッションに切り替えなくても管理者権限でアプリケーションを実行できるようになります。これに当てはまる一般的な例は、インストーラ、保護者による制限の構成などです。

UAC が有効になっている場合、管理者アカウントを含むすべてのユーザー アカウントが標準ユーザー権限で実行されます。つまり、アプリケーション開発者は、作成するソフトウェアが既定では管理者権限を持たないことを考慮する必要があるということです。これにより、アプリケーション開発者は、標準ユーザー権限で機能するアプリケーションを設計する必要があることを再認識することでしょう。アプリケーション、またはアプリケーションの機能の一部が管理者権限を必要とする場合、アプリケーションでは、昇格メカニズムを利用して、ユーザーがその機能のロックを解除できるようにすることができます。一般に、アプリケーションが標準ユーザー権限で適切に機能するようにするためには、アプリケーション開発者は軽微な変更を加えるだけで済みます。E7 ブログの UAC に関する記事が示すように、UAC によって、開発者のソフトウェア記述方法は順調に変わってきています。

昇格時のプロンプトには、ソフトウェアがシステムに変更を加えようとした場合にそれがユーザーに "通知" されるというメリットもあり、変更を阻止するチャンスが昇格時のプロンプトによってユーザーに与えられます。たとえば、信頼できないソフトウェア パッケージやシステムに変更を加えてほしくないソフトウェア パッケージが管理者権限を要求した場合、ユーザーはプロンプトを拒否することができます。

昇格とマルウェア セキュリティ

UAC の主な目標は、より多くのユーザーが標準ユーザー権限で実行できるようにすることです。しかし、UAC のテクノロジの 1 つである同意プロンプトは、セキュリティ機能のように見えます。多くの人々は、ソフトウェアが管理者権限の付与をユーザーに要求するということは、マルウェアが管理者権限を得るのを阻止できるということだと確信していました。プロンプトで管理者権限を付与することができるのはそのプロンプトで説明されている操作のみに対してであるという視覚的暗示に加えて、昇格ダイアログが表示される際に別のデスクトップに切り替わること、および Windows Integrity Mechanism (ユーザー インターフェイス特権の分離 (UIPI) を含む) の使用により、この確信が強まるようです。

しかし、Windows Vista の発売前から述べてきたように、昇格の主な目的はセキュリティではなく利便性です。ユーザーが管理操作を実行するために (ログイン、または "ユーザーの簡易切り替え" を通じた管理者アカウントへの切り替えによって) アカウントを切り替える必要があった場合、ほとんどのユーザーは、いったんアカウントを切り替えたら、再び元のアカウントには切り替えないでしょう。アプリケーション開発者の設計対象となる環境を変えるという目標に向けた進展はありません。では、セキュリティで保護されたデスクトップ、および Windows Integrity Mechanism の目的は何なのでしょうか。

プロンプトが表示される際に別のデスクトップに切り替わる主な理由は、標準ユーザー ソフトウェアは、(たとえば、ダイアログに表示される発行者名の上に描画を行い、マイクロソフトや別のソフトウェア ベンダが自分の代わりにプロンプトを生成しているのだとユーザーに思い込ませることによって) 昇格時のプロンプトを "スプーフ" することができないからです。別のデスクトップは "セキュリティで保護されたデスクトップ" と呼ばれます。Windows ログオン ダイアログが表示されるデスクトップと同様に、ユーザーではなくシステムによって所有されるからです。

別のデスクトップの使用には、アプリケーションの互換性に関する重要な目的もあります。組み込みのアクセシビリティ ソフトウェア (スクリーン キーボードなど) は、異なるユーザーによって所有されるアプリケーションを実行しているデスクトップで適切に機能しますが、サードパーティ製のソフトウェアの中には、適切に機能しないものがあります。昇格ダイアログ (ローカル システム アカウントによって所有されます) が、ユーザーによって所有されるデスクトップに表示される場合、こうしたソフトウェアは適切に機能しません。

Windows Integrity Mechanism と UIPI は、昇格されたアプリケーションの周囲に設ける保護用の防壁を作ることを目的としています。当初の目標の 1 つは、ソフトウェア開発者が既に昇格されたアプリケーションを管理タスクの遂行に利用するという手っ取り早い方法を用いるのを防ぐことでした。標準ユーザー権限で実行されているアプリケーションは、昇格されたアプリケーションに命令を実行させるために偽りのマウス入力やキーボード入力を昇格されたアプリケーションに送信することができません。また、管理操作を実行するために、昇格されたアプリケーションにコードを挿入することもできません。

Windows Integrity Mechanism と UIPI は、Windows Vista で保護モードの Internet Explorer 用に使用されていました。保護モードの Internet Explorer では、実行されている IE インスタンスを感染させるマルウェアが、ユーザー アカウント設定に変更を加えて、たとえばユーザーがログオンするたびにマルウェアが起動するように構成するのが、より困難になります。昇格を、セキュリティで保護されたデスクトップ、Windows Integrity Mechanism、および UIPI と併用して、標準ユーザー権限で実行されているソフトウェアと管理者権限で実行されているソフトウェアの間に (セキュリティ境界と呼ばれる) 通り抜け不可能な防壁を築くことが、Windows Vista の初期の設計目標でしたが、ユーザビリティとアプリケーションの互換性という 2 つの理由がこの目標を達成する妨げとなり、この目標は後に撤回されました。

figb.gif

図 1 実行可能ファイルの名前を表示

まず、昇格ダイアログ自体について考えてみてください。このダイアログには、管理者権限を付与される主要な実行可能ファイルの名前と発行者が表示されます。コードにデジタル署名するソフトウェア発行者はますます増えていますが、残念ながら、デジタル署名を行わない発行者も存在し、署名されていない古いアプリケーションは多数存在します。署名されていないソフトウェアの場合、昇格ダイアログには実行可能ファイルの名前だけが表示されます。その場合、既にユーザー アカウントで実行されており、署名されていない Setup.exe アプリケーション インストーラが昇格されるのを待っているマルウェアは、ユーザーが気付かないうちに、たとえば、実行可能ファイルを悪意のある Setup.exe に置き換えることができてしまいます (図 1 参照)。

第 2 に、ダイアログでは、実行可能ファイルを起動した場合にどのような DLL が読み込まれるかはユーザーに通知されません。ユーザーの制御下にあるディレクトリ内に実行可能ファイルがある場合、ユーザーの標準権限で実行されているマルウェアは、当該のソフトウェアによって使用される場所にある関連付けられたあらゆる DLL を置き換えることができます。また、マルウェアは、サイド バイ サイド機能を使用して、実行可能ファイルが悪意のあるバージョンのアプリケーション DLL やシステム DLL を読み込むようにすることもできます。ユーザーが用心深く詳細ボタンをクリックし、昇格される実行可能ファイルのファイル パスとして表示される内容を注意深く確認しない限り、マルウェアは、実行可能ファイルを似た名前の場所 (\ProgramFiles\Vendor\Application.exe ("Program Files" であるべき箇所のスペースが抜けていることに注目してください) など) にコピーできてしまいます。コピーされたら、マルウェアは、アプリケーションがどのような DLL を読み込むかを制御することができます。図 2 では、Microsoft ネットワーク モニタのコンポーネントを、ユーザーが作成した、ユーザーが制御できる C:\ProgramFiles ディレクトリにコピーし、このコンポーネントを起動しました。

figc.gif

図 2 Microsoft ネットワーク モニタ コンポーネントのコピーを起動した

第 3 に、アプリケーションの互換性のため、昇格されたアプリケーションは、重要な状態を、悪意のあるアプリケーションが昇格されたアプリケーションの動作に影響を与えるために使用できる標準ユーザー環境と共有します。これの最もわかりやすい例は、ユーザーのレジストリ プロファイルである HKEY_CURRENT_USER (HKCU) です。ユーザーは自分が標準ユーザーとして登録した設定と拡張が、昇格されたアプリケーションで機能することを期待するため、このレジストリ プロファイルは共有されます。マルウェアは、HKCU に登録されたシェル拡張を使用して、なんらかのシェル参照ダイアログ ([ファイルを開く]、[ファイルの保存] など) を使用する昇格されたアプリケーションに入り込むことができます。アプリケーションによって同期と共有メモリ オブジェクトが作成される場所である Base Named Object 名前空間など、他の種類の状態も共有されます。マルウェアは、この共有を利用して、昇格されたアプリケーションによって使用される共有メモリ オブジェクトを乗っ取り、たとえば、アプリケーションに危害を加え、その後、システムに危害を加えることができます。

防壁としての Windows Integrity Mechanism の有効性は、昇格に関する問題 (前述) による制約を受けるだけでなく、アプリケーションの互換性によってもたらされる制約も受けます。まず、UIPI は、標準ユーザー アプリケーションによるデスクトップへの描画 (ユーザーをだまして、昇格されたアプリケーションを操作しているうちにユーザーがマルウェアに管理者権限を付与してしまうよう仕向けるのに使用される可能性があります) を阻止しません。また、Windows Integrity Mechanism はネットワークには作用しません。PA アカウントで実行されている標準ユーザー アプリケーションは、PA アカウントが管理者権限を持っているリモート システム上のシステム リソースにアクセスできます。こうした制約への対処は、アプリケーションの互換性に大きな影響を持ちます。とは言うものの、マイクロソフトはシステムのセキュリティを強化する方法を絶えず考えており (保護モードの IE の強化など)、それと同時に、アプリケーションの互換性に関する問題に対処し、ソフトウェア開発者と密接に連携しています。

UAC を有効にして、Windows Vista PA アカウントで実行した場合、どの程度のマルウェア対策が行われるのでしょうか。まず、なんらかのマルウェア対策が問題となるには、そもそも、マルウェアがシステムに入り込んで動作を開始する必要があることを覚えておいてください。Windows には、マルウェアがシステムに侵入し動作するのを防ぐのに役立つ徹底した防御機能が多数用意されています (データ実行防止 (DEP)、Address Space Load Randomization (ASLR)、保護モードの IE、IE 8 SmartScreen フィルタ、Windows Defender など)。

マルウェアがなんらかの形でシステムに入り込んでしまったとしても、マルウェアの作成者は (まっとうな開発者と同様に) ユーザーが管理者権限で実行することを想定しているため、ほとんどのマルウェアは正常に機能しません。これだけでも、セキュリティ上のメリットと考えることができます。しかし、チャンスに乗じるよう設計されているマルウェアは、システムに入り込んだら、ユーザーが初めて昇格を行う際に、管理者権限を得ることができる可能性があります。マルウェアは "本物の" 昇格を待つ必要すらありません。マルウェアは、最もセキュリティに敏感なユーザーさえだまされてしまうような偽者の昇格を引き起こすことができるからです。マルウェアが昇格プロセスを乗っ取る方法については、UAC の内部情報に関する公開プレゼンテーションと Windows のセキュリティ境界に関する公開プレゼンテーションでお見せしました (デモは、セキュリティ境界に関するプレゼンテーションが始まって 1 時間 3 分後からです)。ただし、マルウェアが動作を開始した場合、そのマルウェアは、マルウェアが実行しようとすることのほとんど (当該ユーザーがログオンするたびにそのマルウェアが動作するよう構成する、そのユーザーのデータをすべて盗むまたは削除する、さらには、ボットネットの一部となるなど) を標準ユーザー権限のみで遂行できてしまうことを覚えておいてください。

Windows 7 と以前のバージョンの違い

Windows 7 の操作のうち、標準ユーザーが実行できるようになったものの一部をご紹介しましたが、E7 ブログの UAC に関する記事で説明されているとおり、UAC の目標を犠牲にすることなく Windows エクスペリエンスをより円滑にできることもわかりました。多くのユーザーが、一般的なシステム管理操作を実行する際に Windows Vista 自身が頻繁に管理者権限を要求することについて不満を訴えていました。Windows を標準ユーザー環境で適切に機能するようにすることはお客様が求めていることであり、お客様の利益を最優先に考えるマイクロソフトの求めることです。しかし、昇格時のプロンプトは、Windows を標準ユーザー環境で適切に機能するようにするよう教えたり促したりせず、ユーザーは 2 回目以降もダイアログ (ユーザーの大半は内容を読んでいません) でクリック操作を行わなければなりません。したがって、Windows 7 では、こうしたプロンプトを既定の Windows エクスペリエンスからできるだけ減らし、管理者として実行するユーザーがプロンプト エクスペリエンスを制御できるようにすることを目指しました。

これを行うために、標準ユーザー権限を持つユーザーがより多くのタスクを実行できるようにシステムがさらにリファクタリングされ、いくつかの複数プロンプト シナリオ (IE での ActiveX コントロールのインストールなど) でプロンプトの数が減らされました。Windows 7 には、新しい UAC 構成ダイアログで選択できる 2 つの新しい UAC 動作モードも導入されています (図 3 参照)。このダイアログを開くには、コントロール パネルの [ユーザー アカウント] をクリックし、[ユーザー アカウント制御設定の変更] をクリックします (昇格時のプロンプトで [Change When Notifications Appear] (どのような場合に通知を表示するかを変更する) リンクをクリックするか、アクション センター経由でもこのダイアログを開くことができます)。

figd.gif

図 3 新しい UAC 構成ダイアログで選択できる 2 つの新しい UAC 動作モード

既定の設定 (図 3 参照) は、新しいレベルの 1 つです。スライダの一番上に位置する選択項目であり Windows Vista の既定のモードと同じである [常に通知する] とは違って、Windows 7 の既定の設定では、Windows 以外の実行可能ファイルが昇格を要求した場合にのみユーザーに対してプロンプトが表示されます。Windows 以外の昇格に対する動作は、Windows Vista の場合と同じです。

1 つ下のスライダ位置は 2 つ目の新しい設定で、末尾に "(デスクトップを暗転しない)" が付いていることを除けばラベル名は既定の設定と同じです。これと既定のモードとの唯一の違いは、プロンプトが、セキュリティで保護されたデスクトップではなくユーザーのデスクトップに表示されるという点です。これの良い面は、プロンプトがアクティブになっている間にユーザーがデスクトップを操作することができるという点です。ですが、前述のとおり、サードパーティ製のアクセシビリティ ソフトウェアがプロンプト ダイアログで正常に機能しない場合があるというリスクが存在します。

そして、一番下のスライダ位置を選択すると、UAC テクノロジが完全に無効になるので、PA アカウントで実行されているソフトウェアがすべて完全な管理者権限で実行され、ファイル システムとレジストリの仮想化が無効になり、保護モードの IE が無効になります。この設定を選択した場合、プロンプトは表示されませんが、保護モードの IE が無効になることはこのモードの大きなデメリットです。

自動昇格

中間に位置する 2 つの設定を選択した場合に、(ほとんどの) Windows 実行可能ファイルが昇格されてもプロンプトが表示されない理由は、Windows 実行可能ファイルがシステムによって "自動昇格" されるからです。まず、この場合、Windows はどのようなものを Windows 実行可能ファイルとして定義しているのでしょうか。答えはいくつかの要因によって決まりますが、(1) Windows Publisher (Windows に含まれるすべてのコードへの署名に使用される証明書) によってデジタル署名されており (マイクロソフトによって署名されているというだけでは不十分です。したがって、Windows に含まれていないマイクロソフト ソフトウェアは含まれません)、(2) 少数の "セキュリティで保護された" ディレクトリの 1 つに格納されている、という 2 つの要件を満たす必要があります。セキュリティで保護されたディレクトリとは標準ユーザーが変更を加えることができないディレクトリのことで、%SystemRoot%\System32 (たとえば \Windows\System32) とそのサブディレクトリのほとんど、%SystemRoot%\Ehome、%ProgramFiles% の下にある少数のディレクトリ (Windows Defender、Windows Journal を含む) などがこれに該当します。

また、実行可能ファイルが標準的な .exe、Mmc.exe、COM オブジェクトのどれであるかによっては、自動昇格には追加のルールがあります。.exe タイプの Windows 実行可能ファイル (Windows 実行可能ファイルの定義は先ほど紹介しました) は、マニフェスト内で autoElevate プロパティが指定されている場合に自動昇格します。アプリケーションが管理者権限を要求することも、マニフェスト内の記述によって UAC に通知されます。Sysinternals の Sigcheck ユーティリティでは、"sigcheck –m %systemroot%\system32\taskmgr.exe" というコマンドを使用してタスク マネージャ (Taskmgr.exe) のマニフェストをダンプすることができます。図 4 に示すように、このマニフェストでは、タスク マネージャを自動昇格することが選択されていることがわかります。

fige.gif

図 4 autoElevate プロパティ

ディレクトリ ツリー内の自動昇格される実行可能ファイルを見つける簡単な方法は、Sysinternals の Strings ユーティリティを次のようなコマンドと共に使用することです。

strings –s *.exe | findstr /i autoelevate

ハードコーディングされた、自動昇格される Windows 実行可能ファイルのリストも存在します。こうした Windows 実行可能ファイルは、Windows 7 の外部にも移されるので、autoexecute プロパティがあるとエラーが発生する下位レベルのシステムで動作できる必要があります。リストには、Migwiz.exe (移行ウィザード)、Pkgmgr.exe (パッケージ マネージャ)、および Spinstall.exe (サービス パック インストーラ) が含まれます。

Microsoft 管理コンソール (Mmc.exe) は、システム管理スナップイン (DLL として実装されます) の多くをホストするので、特別扱いされます。Mmc.exe は、MMC が読み込むスナップインが列挙された .MSC ファイルを指定するコマンド ラインによって起動されます。Windows は、Mmc.exe が管理者権限を要求していることを認識すると (Mmc.exe は、PA アカウントから起動された場合、管理者権限を要求します)、Mmc.exe が Windows 実行可能ファイルであることを確認し、.MSC をチェックします。自動昇格の対象となるには、.MSC ファイルは Windows 実行可能ファイルの条件 (セキュリティで保護された場所で Windows によって署名されている) を満たしている必要があり、また、自動昇格される .MSC を示す内部的なリストに含まれている必要があります。このリストには、Windows に含まれる .MSC ファイルがほぼすべて含まれています。

また、COM オブジェクトは、管理者権限が必要であることをレジストリ キーのレジストリ値で指定することができます。1 に設定された Enabled という名前の値を持つ Elevation という名前のサブキーを作成することによってこれを行います。図 5 は、ユーザーが自分のアカウントがアクセス許可を持っていない場所に対してファイル システム操作を実行する際にエクスプローラによって使用される、シェルのコピー/移動/名前変更/削除/リンク オブジェクトの、レジストリ キーを示しています。

figf.gif

図 5 シェルのレジストリ キー

COM オブジェクトが自動昇格されるには、その COM オブジェクトが Windows 実行可能ファイルでもあり、Windows 実行可能ファイルによってインスタンス化されている必要があります (ただし、COM オブジェクトのインスタンス化を行う実行可能ファイルが自動昇格の対象としてマークされている必要はありません)。たとえば、エクスプローラを使用して PA アカウントから %ProgramFiles% ディレクトリ内にディレクトリを作成する場合、操作は自動昇格します。COM オブジェクトが昇格を要求し、オブジェクトの DLL は Windows 実行可能ファイルであり、エクスプローラは Windows 実行可能ファイルだからです。

自動昇格と UAC の目標

固有の自動昇格ルールすべての背後にあるのは何でしょうか。自動昇格するものとしないものの選択は、「アプリケーション開発者は自動昇格を利用することによって無意識または簡単に管理者権限に依存することができるか」という質問に基づいて行われました。Cmd.exe はコマンド ライン引数を通じてバッチ スクリプトを実行するのに使用でき、標準的なユーザーはコマンド プロンプトを昇格させて実行する必要がないので (標準的なユーザーのほとんどはコマンド プロンプトとは何なのかさえ知りません)、Cmd.exe は自動昇格するようにマニフェストで指定されませんでした。同様に、Windows 7 の最終リリースでは Rundll32.exe (コントロール パネル プラグインをホストする実行可能ファイル) は自動昇格しません。どのような一般的な管理タスクの実行にも Rundll32.exe の昇格は必要ないこと、および Rundll32.exe はコマンド ラインを通じて任意の DLL をホストできるので、Rundll32.exe が自動昇格した場合、開発者は気付かないうちに管理者権限を要求してしまう可能性があることがその理由です。

Windows Vista Beta のときから、エンド ユーザーは、自動昇格リストに任意のアプリケーションを追加する方法を提供するよう Windows に求めてきました。よく挙げられる理由は、頻繁に使用するサードパーティ製アプリケーションがあるので、毎日の決まりきった作業の一環としてしょっちゅう昇格時のプロンプトでクリック操作を行わなければならないというものです。Windows Vista と同様に、Windows 7 には、自動昇格リストに任意のアプリケーションを追加する機能は用意されていません。エンド ユーザーの皆さんのいら立ちは理解できますし、このようなアプリケーションが管理者権限なしでは動作できない正当な理由があるのかもしれませんが、開発者が標準ユーザー権限で機能するようにコードを修正するのを回避するというリスクが高すぎます。自動昇格されるアプリケーションのリストに管理者しかアクセスできなかったとしても、開発者が、作成したアプリケーションをリストに追加するように、1 回限りの昇格を必要とするアプリケーション セットアップ プログラムを変更してしまう可能性があります。Windows 7 では、自動昇格リストに任意のアプリケーションを追加する機能を用意する代わりに、作成されたプログラムが標準ユーザーで正常に機能するようにするためにアプリケーション開発者を啓発しアプリケーション開発者と密接に連携することに力が注がれることになりました。

何人かの方から、標準ユーザー権限を持つ PA アカウントで実行されているサードパーティ製のソフトウェアが自動昇格を利用して管理者権限を得ることができるという意見がありました。たとえば、このようなソフトウェアでは、WriteProcessMemory API を使用してエクスプローラにコードを挿入し、CreateRemoteThread API を使用してそのコードを実行することができます。これは DLL インジェクションと呼ばれる手法です。このコードは、Windows 実行可能ファイルであるエクスプローラ内で動作するので、自動昇格する COM オブジェクト (コピー/移動/名前変更/削除/リンク オブジェクトなど) を利用してシステム レジストリ キーやディレクトリに変更を加え、ソフトウェアに管理者権限を与えることができます。確かにそのとおりですが、このような手順は意図的に行われるものであり、簡単ではないので、まっとうな開発者が、標準ユーザー権限で動作するようにソフトウェアを修正する代わりにこちらを選択することはないでしょう。実際、どのようなアプリケーション開発者も、システムでの昇格動作に依存しないようにすることをお勧めします。また、アプリケーション開発者は作成したソフトウェアの標準ユーザー モードでの動作をテストすることをお勧めします。

マルウェアが同じ手法を使用して管理者権限を得ることができるという意見もあります。これも確かにそのとおりですが、既に指摘したように、マルウェアはプロンプトによる昇格を通じてシステムに危害を加えることもできます。マルウェア側からすると、Windows 7 の既定のモードのセキュリティ レベルは "常に通知する" モード ("Vista モード") より高くも低くもなく、管理者権限を想定しているマルウェアは Windows 7 の既定のモードで実行されるとやはり正常に機能しません。

結論

手短に言うと、UAC は、"ユーザーが標準ユーザーとして実行することを可能にする" という 1 つの共通の目標を持つテクノロジのセットです。以前は管理者権限が必要だったより多くの操作を標準ユーザーが実行できるようにするための Windows への変更、ファイルとレジストリの仮想化、およびプロンプトは、すべて、この目標を実現するために連携します。要するに、既定の Windows 7 UAC モードでは、プロンプトが減ったことにより PA ユーザーのエクスペリエンスがより円滑になり、PA ユーザーはどのような適正なソフトウェアがシステムに変更を加えられるかを制御でき、さらに、"より多くのソフトウェアが管理者権限なしで動作することを可能にし、ソフトウェア エコシステムを、標準ユーザー権限で機能するソフトウェアを記述するという方向に引き続き推移させる" という UAC の目標を実現できるということです。

Mark Russinovich は、マイクロソフトのプラットフォーム & サービス部門に所属するテクニカル フェローです。