私は，「なぜWindowsは危険なルートキットを阻止できないか？」でルートキットのことを論じた。この中で，私はルートキットやそのほかの不正ソフト（マルウエア）が，大抵はAdministratorとしてログオンしている間にインストールされると書いた。今回は改めて，「管理者権限で使い続ける」という悪弊について論じたい。
ウイルス感染を防ぐため管理者でログオンしない
PCを利用している私たちが，コンピュータ・ウイルスの感染を防ぐためにできる最良の方策の1つは，Administratorとしてではなく1ユーザーとしてログオンすることである，と私は主張した。Administratorとしてログオンしていれば，いくつかの作業が楽になるかもしれない。しかし，そうしている本当の理由は，単に癖になっているだけだ，とも書いた。
読者の多くは私に同意せず，「User権限では，たくさんのソフトウエアをインストールしたり稼働したりできない。だから，制限ユーザーとしてログオンして使い続けるのは現実的ではない」と反論してきた。その通り，実際のところユーザーのまま使い続けるのが面倒くさい場合はあるし，いくつかの場面ではユーザーとしてログオンした管理者が一度ログオフしてAdministratorとしてログオンし直すように迫られることもあるだろう。しかし，この問題は多くの人々が考えているほど普遍的なものなのではない。だから「管理者がユーザーとしてログオンして使い続けるシナリオ」に一番よくありそうな2つの問題を考えよう。つまり，NTFSとレジストリのアクセス許可（パーミッション）に関する問題だ。
管理者でなくてもソフトはインストールできる
最初に私がよく尋ねられるのは「ユーザーがソフトウエアをインストールできるようにするために，あるいはその逆に，ユーザーがソフトウエアをインストールできないようにするために，変更すべき権利は何か」という質問であるが，その質問の間違った考えを正そう。不幸なことに，単独ではそうした権利は存在しない。そういう権利を与えたり，与えなかったりするGroup Policy Object（GPO）も単独では存在しない。しかし，一般的にはほとんどのアプリケーションのインストールと利用の問題は，レジストリかNTFSのアクセス許可の問題に帰着する。
米Microsoftは，Windows 2000で「system32」フォルダを含む「winnt」や「windows」ディレクトリへのデフォルトのアクセス許可を厳しくした。管理者以外あるいはPower Users以外のユーザーは，system32からファイルを読み出せるが書き込めない。多くのアプリケーションは，system32フォルダへファイルをコピーするために，インストール時にAdministrator権限を持っていないとインストレーションが失敗する。皮肉なことに，ほとんどのアプリケーションは本来「system32」フォルダへファイルを書き込む必要がない。開発者がそういう悪癖を止めなかったから，そうなっているだけである。
かつては，OSが「.dll」ファイルを利用するためにsystem32フォルダへなんでも放り込んでおくという正当な理由があった。だが，Windows 2000が登場して以来，その必要はなくなった。あるアプリケーションがOSの一部をトロイの木馬で書き換えようとする不正ソフトであっても，インストール担当者がAdministratorとして作業していなければ，そのアプリケーションのインストールは失敗するだろう。もちろん，このシナリオは，われわれがAdministratorとしてログオンしたままで過ごすべきではないという1つの理由である。管理者権限のないアカウントで作業しているユーザーが，偶然にntoskrnl.exeを書き換えるなんてことはできないのだ。
では，まともなアプリケーションをインストールするには，どうすればいいのだろうか？簡単である。インストールするときに「Runas」コマンドを使えばいいのだ。私が知っている限り，「ローカルAdministratorとして何かを実行しては絶対にいけない」「Administratorとして無差別に何でもかんでも実行したりしてはいけない」，と言った人はいない。そして，最悪のことが起きた場合でも，Administratorは常に彼または彼女のユーザー・アカウントをログオフさせることができ，インストール作業を完了させるためにAdministratorアカウントでログオンし直せる。
レジストリのアクセス許可が利用を妨げる
レジストリのアクセス許可も，アプリケーションのインストールと利用を妨げる恐れがある。大抵のアプリケーションは，どう処理するかという情報をレジストリに書き込んでいる。つまりそれは，初期設定プログラムがレジストリ内に新しいキーと値のエントリを作成できなければいけないということだ。
しかし，そのプログラムはユーザーの設定情報をレジストリに記録する必要がある。例えば，私が「Notepad」でワード・ラップを有効または無効にしたとする。私が次回，そのプログラムを起動したときにそのワード・ラップの設定を再現できるように，Notepadはレジストリにその情報を記録できなければいけないのだ。
レジストリ・キーとエントリを生成する権限をインストール・プログラムに与えるという問題は，NTFSのアクセス許可の問題と同じ方法で解決する。プログラムをインストールするときにAdministratorとして稼働すればよい。そうしなくても，あなたがActive Directory（AD）環境にいるのなら，ソフトウエア配布用のGPOを使ってアプリケーションを配布できる。その場合，Windows Installerサービスが重いものを持ち上げる作業をこなし，Systemアカウントの信用の下で稼働するので，NTFSとレジストリのアクセス許可は問題にならなくなる。
しかし，レジストリのアクセス許可は，アプリケーションを日常使う際に問題を起こす可能性がある。それはWindows 2000でレジストリのデフォルトのアクセス許可が変更されたためだ。レジストリの2つの主なサブツリーは「HKEY_LOCAL_MACHINE」と「HKEY_CURRENT_USER」である。前者のツリーはそのコンピュータに絡む設定を内蔵するよう設計されており，後者はユーザー独特の設定を保持するよう設計されている。複数の人が同一のデスクトップを使うかもしれないので，Windowsは複数のHKEY_CURRENT_USERレジストリ群をサポートしている。例えば，JaneとJoeは1台のマシンを共用しているとする。JaneはNotepadでワード・ラップさせたいが，Joeはさせたくない。この場合，WindowsはJaneの設定情報をJaneのHKEY_CURRENT_USERサブツリーに，Joeの設定情報をJoesのHKEY_CURRENT_USERレジストリ・サブツリーへ記録する。
しかし，アプリケーションのすべての設定がユーザーにより異なるわけではない。例えば，「Word」はインストールされているアドインの情報を記録している。このアドイン情報をユーザーのHKEY_CURRENT_USERサブツリーに記録するのは現実的ではない上，インストールのときに先々どのユーザーがWordを使うのかをアプリケーション側は知ることもできない。そのため，Wordはその情報をHKEY_LOCAL_MACHINEにしまっておく。そういうわけで，アプリケーションが2つのキーを持っているのを目にするのはよくあることだ（つまり1つはHKEY_LOCAL_MACHINE\SOFTWAREの中，もう1つはHKEY_CURRENT_USER\Softwareの中に）。HKEY_LOCAL_MACHINE内の設定は，インストール時に作成され，めったに変更されない。HKEY_CURRENT_USERの中にある設定は，ユーザーによって異なり頻繁に変更される可能性がある。
ソフトウエア開発者の意識改革が必要
ユーザーは，HKEY_LOCAL_MACHINE\SOFTWAREキーには書き込めないが，各個人のHKEY_CURRENT_USER\Softwareキーには書き込める。そこで，アプリケーションがHKEY_CURRENT_USERサブツリーに各ユーザーの設定情報を書くのなら，すべてはうまくいく。しかし，一部の開発者はHKEY_LOCAL_MACHINEとHKEY_CURRENT_USERの違いを理解していない。恐らく，HKEY_LOCAL_MACHINE\SOFTWAREキーについてWindows 9xはセキュリティがなく，Windows NT 4.0とそれ以前のバージョンはセキュリティが緩かったからである。そういう開発者たちが32ビット・コーディングを始めた時にはHKEY_LOCAL_MACHINEとHKEY_CURRENT_USERの違いを学ぶ必要がなかったのだ。
例えば，米Autodeskの開発者は，HKEY_LOCAL_MACHINEが緩いレジストリのアクセス許可しか持たない時代に「AutoCAD」の32ビット版を作ったので，何でもかんでもHKEY_LOCAL_MACHINEに突っ込んだ。Windows 2000のユーザーは，AutoCADを使うためにはAdministrators（に属するアカウント）でログオンしなければならないことを悟った。
アプリケーションが使用するレジストリ・キーを探す
Administratorとしてログオンすることは，この開発者のミスに対応する1つの答えだが，唯一の答えではない。別のアプローチは，AutoCADがどのレジストリ･キーを使うかを調べて，それらのキーのアクセス許可を緩く設定することだ。適切なキーを見つけるためには，いくつかの方法を使える。例えば，HKEY_LOCAL_MACHINEまたはHKEY_CURRENT_USERにあるソフトウエアのキーは，サブツリー\Software\ベンダー名という構造になっている。だからレジストリの中を見れば，多分HKEY_LOCAL_MACHINE\SOFTWARE\AutoDeskとか似たような名前のキーが出てくるだろう。
正しいレジストリ・キーを識別するもう1つの方法は，米Sysinternals製のプログラム「Regmon」を走らせることだ。このプログラムは，レジストリの活動を追跡するものである。Regmonのログを見れば，システムがどこにデータを書こうとしたかが分かり，問題のレジストリ・キーが分かる。
Microsoftの「Windows Application Compatibility Toolkit（ACT） 3.0」をダウンロードする手もある（該当サイト）。これは，間違った書き方をされたプログラム用のたくさんの修正（パッチ）と「Application Verifier」という便利なツールを備えている。問題を起こしているプログラムをそのツールの中で実行させてアプリケーションが異常を起こす場合，何が問題を起こしたのかを知るためにツールのログを調べれば，知りたいレジストリが分かるだろう。
適切なレジストリ・キーがどれか分かったら，Usersグループに対しそのキーへの書き込みのアクセス許可を追加する。もっとよい方法は，特定のユーザー・アカウントだけに個別にアクセス許可を与えればよい（問題のキーを右クリックして，［Security］オプションを選択する）。もし，レジストリしたアクセス許可の変更を会社全体に広げる必要があるなら，GPOを使えばよい。
NTFSとレジストリのアクセス許可がユーザーと管理者のアプリケーションの互換性問題の唯一の原因なのではないが，最大の原因なのは間違いない。ちょっとした探索作業で，アクセス許可問題をいぶり出すことができ，数分かけてアクセス許可を調整するだけで，この問題を解決できる。
