デスクトップ ファイル管理者から卒業する

Wes Miller

今から 3 年以上も前の話ですが、私は通常使用している Windows システム上のユーザー アカウントを、ローカル管理者アカウントからローカル ユーザー アカウントに移行する作業を始めました。マイクロソフトでの勤務は 7 年以上になりますが、私は常に完全な特権が与えられた管理者としてシステムを実行してきました。確かに便利でしたが、この状態は恐ろしいほどセキュリティを欠いていたため、

私 (および皆さんの多く) は非常に運が良かったことになります。毎日管理者としてシステムを実行しても、それほど多くのシステムが、それほど頻繁に、それほど大きな影響を受けることはありませんでした。

このことに関する統計を取るための良い方法はないだろうかと思うことがよくありますが、私の感触や業界の状況から判断しても、現在非常に多くの組織が (そして IT プロフェッショナルでさえも) ローカル管理者としてシステムを実行しています。Winternals で、私がシステムを管理者ではなくユーザーとして実行するようにした目的は、生産者と消費者の両方の立場から、この方法でシステムを実行することの難点を学習し、Winternals の製品である Winternals Protection Manager が標準的な組織でどれほど役立つかを多少なりとも理解することでした。Winternals は、多くの組織の大部分のユーザーが、これまで管理者としてシステムを実行しており、現在もその状況が変化していないという前提に基づいて、管理者がユーザーとしてシステムを実行できるようにし、さらに移行が必要な部分 (少なくとも複雑な作業を伴う部分) をできる限り少なくすることを目標としました。組織でどのようなテクノロジを使用している場合でも、管理者からユーザーに移行する作業は簡単ではありませんが、この作業を完了することによって、組織が攻撃を受ける確率を最も効率的に低下させることができます。この実装は、システム内のファイアウォールと考えることができます。実際の機能は、ファイアウォールそのものです。

この考えに至った経緯

皆さんへのメッセージ : 痛みは必要です

まだ管理者からユーザーへの移行を考えたことがない場合は、この作業について考え始めるべきです。まずは自分で試してみることをお勧めします。予備のコンピュータでは適切なテストにならないので、毎日使用しているコンピュータでテストを行ってください。Windows Vista® を実行している場合は、ユーザー アカウント制御 (UAC) を使用しない場合のテストも行うことをお勧めします。組織内で、なんらかの変更を必要とする作業の実施を推進する場合は、まず自分から実施してみるのがよいでしょう。試してみると、管理者以外の役割としてシステムを実行することはそれほど難しくないことがわかると思います。また、セキュリティも強化されるので、実際に組織が攻撃を受ける確率も低下します。

ほとんどのユーザーが管理者としてシステムを実行するという現状は、Windows® の歴史に基づいています。Windows の初期のバージョン (Windows NT® 3.1 以前) では、対話形式でシステムを実行するすべてのユーザーに、機能上同じ権限が与えられたので、セキュリティはまったく存在しませんでした。これは、すべてのソフトウェアが同じ方法でインストールされることを意味していますが、家庭にとってはそれほど大きな問題ではありませんでした。当時は、ある人がコンピュータを所有している場合、そのコンピュータのすべてのユーザーが、インストールされているソフトウェアを使用できることが当たり前でした。

Windows NT は、登場した直後から (消費者はもちろん) 企業に支持されたわけではありません。32 ビットの Windows と Windows NT の間には Win32® の互換性が存在したので、ほとんどのアプリケーション ベンダは、Windows NT のセキュリティ インフラストラクチャに適合させるというだけの目的で、アプリケーションを再構築することはありませんでした。実際、Windows 2000 が登場するまで、多くの消費者指向の独立系ソフトウェア ベンダ (ISV) は、Windows NT には注目しませんでした。もちろん企業の決断を後押ししたのは、Windows 9x ファミリの時代を終息へと向かわせた Windows XP です。

しかし依然として、アプリケーションの開発は、システムのすべてのユーザーに、Program Files、およびレジストリ内の HKEY_LOCAL_MACHINE (HKLM) と HKEY_CLASSES_ROOT へのアクセス権が与えられていることを前提として行われました (ユーザーとして実行した場合、これらの権限は与えられません)。アクセス権を前提とする厄介なプログラムの 1 つとしてよく挙げられるのは、ゲームです。詳細については、Matt Clapham が執筆した記事 (technetmagazine.com/issues/2007/02/Gaming) を参照してください。

この前提が問題である理由は、さまざまなシステムで実行されるアプリケーションのほとんどが、ファイルやレジストリ設定を上記のような場所に格納するからです。つまり、これらの場所の読み取りおよび書き込み権限が与えられていなければ、アプリケーションをインストールすることはできません。残念ながら、インストール後にこれらのキーへの書き込みを要求するアプリケーションもあります。たとえば、私の娘は Flash ベースのゲームを持っていますが、このゲームは、実行するたびにカスタム プレーヤーをインストールしようとします。つまり、娘が管理者ではなくユーザーとして実行しようとした場合、アプリケーションは起動せず、致命的なエラーが発生します。これは極端な例であり、消費者向けアプリケーションの話ですが、実際のところ、消費者以外を対象としたアプリケーションも、管理者以外の役割として実行した場合、適切に動作しないことがあります。私のメッセージ (補足記事「皆さんへのメッセージ : 痛みは必要です」を参照) を実行に移してくだされば、Windows をユーザーとして実行することの不便さを理解していただけると思います。

図 1 は、Windows XP でユーザーとして IPConfig /release を実行したときの結果を示しています。これを図 2 と比較すると、Windows Vista で同じコマンドを実行した場合、あまりわかりやすい結果が表示されるとは言えませんが、少なくともコマンドが失敗した理由は表示されます。また、ネットワーク ツールも全体的に強化され、ユーザーが IP アドレスを更新できるようになりました。同様に、どちらのバージョンでも、ユーザーとして [コンピュータの管理] (compmgmt.msc) を実行したときに、一部のタスクを実行できるようになりました。ただし通常は、図 3 のように袋小路に入ってしまい、もどかしい思いをすることになります。Windows Vista の初期状態では、[コンピュータの管理] で提供されるツールの多くを実行できませんが、アクセスが拒否されたことを示すメッセージの内容はわかりやすくなっています。

Figure 1** Running as a user under Windows XP **(画像を拡大するには、ここをクリックします)

Figure 2** Running as a user under Windows Vista **(画像を拡大するには、ここをクリックします)

Figure 3** Misleading message after running compmgmt.msc as a user on Windows XP **(画像を拡大するには、ここをクリックします)

移行が必要な理由

なぜ移行を検討する必要があるかと言えば、私たち IT プロフェッショナルは、最小限の特権が与えられたユーザーに適合するアプリケーションの開発を推進し、対話形式でシステムを実行しているユーザーがそのシステムの所有者であるという前提を排除していく必要があるからです。

残念ながら、管理者にレジストリ キーへの書き込みを許可するポリシーを適用すると、アクセス制御リスト (ACL) で明示的にアクセスを拒否されていないすべてのオブジェクトへの完全なアクセス権が、それらの管理者のユーザー コンテキストで実行されたすべてのマルウェアに与えられます。UNIX では、ルート (機能的には Windows の Administrator アカウントに相当します) としてシステムを実行しないという規則が守られています。この主な理由は、ソフトウェア エコシステムのセキュリティ モデルの限界点を広げるには、"最小" から "無" という概念に移行する必要があるからです。

ただし、今実施できる最善の対策は、このような考え方に従い、明らかに必要な場合のみ管理者としてシステムを実行するか、可能であれば個々のアプリケーションのみを管理者として実行することです。これにより、先ほど述べた "システム内のファイアウォール" を強化できます。また、マルウェアやスパイウェアが適切でない処理を実行しようとしても、その処理は失敗します。これは、実際にシステムに侵入する (サービスやドライバのインストール、すべてのユーザーを対象としたインストールなどを実行する) ために変更を加える必要があるレジストリやファイル システム上の場所にデータを書き込むことができないからです。さらに、マルウェア対策ソフトウェアが、システム全体を危険にさらす前に、認識したマルウェアの侵入を阻止できるようになります。

ただし、ユーザーが一切攻撃を受けないわけではありません。マルウェアが個々のユーザーのコンテキストを利用して、それらのユーザーのデータを破壊する可能性があります (このようなマルウェアは、まだそれほど広範には存在していません)。ただし、このようなソフトウェアの攻撃を受ける部分は限定されているので、Linux や Macintosh でもマルウェアの侵入率を抑えることができ (被害を受ける可能性がある部分が限定されるので、マルウェアの作成者にとって魅力的な対象ではなくなります)、今日のエンド ユーザーの一般的な安全性が保証されます。

Power Users の排除

Protection Manager の開発時、顧客から「すべてのユーザーが Windows XP を管理者ではなくパワー ユーザーとして実行しているので安全です」という話を聞いたことがあります。ただし実際には、パワー ユーザーと管理者の間にほとんど違いはありません。Windows XP には、少し手を加えるだけでパワー ユーザーを管理者に昇格できる潜在的な欠陥がいくつか存在します。実際、Windows Vista と Windows Server® 2008 では Power Users グループが削除され、Windows の以前のバージョンからアップグレードされたシステムでのみ、Power Users グループが提供されるようになりました。一般的に、Windows XP を使用している場合でも、Power Users グループは使用しないことをお勧めします。

損失を引き起こすアクセス許可

3 月号で Windows のシン クライアントに関する記事 (technetmagazine.com/issues/2008/03/DesktopFiles) をお読みいただいた皆さんは、私が Windows XP を軽量化して領域を節約しようとする傾向に反対していたことを覚えていらっしゃるでしょう。このときと状況は似ていますが、管理者をユーザーに移行する手段として、よく使用されている方法があります。この方法を使用することも検討する必要がありますが、実際に使用する場合は注意が必要です。この方法とは、レジストリとファイル システム上の ACL を調整し、通常は書き込みが許可されていない場所への書き込みをユーザーに許可することによって、問題のアプリケーションを実行できるようにすることです。

当然、最も良い選択肢は、このような変更を必要としないようにアプリケーションを更新することですが、それが常に可能であるとは限りません。アクセス許可を変更する (つまり削除する) 必要がある場合は、十分に注意して作業を行ってください。ユーザーと管理者の間のファイアウォールは、主にレジストリとファイル システムのアクセス許可によって定義されています。これらのアクセス許可を削除することによって、保護レベルが低下し、マルウェアの攻撃を受ける可能性が高くなるので、適切に変更を加えるようにしてください。

UAC について

管理者からユーザーへの移行を検討するときは、必ず Windows Vista のユーザー アカウント制御 (UAC) を考慮する必要があります。Mac OS X と似た機能が提供される UAC を使用すると、システムを危険にさらすことなく、"管理者として" 操作を実行できます。

それでは、UAC のしくみについて説明しましょう。図 4 は、Process Explorer で cmd.exe の情報を表示したときの状態を示しています。右側の cmd.exe のインスタンスは、昇格を行うことなく、最初から管理者として実行しました。このため、右側のユーザーと左側の (昇格を行って cmd.exe を実行した) ユーザーはまったく同じですが、アプリケーション自体 (およびそのインスタンスを実行するユーザー) には、管理者権限が必要なタスクを実行するための特権やトークンは含まれていません。UAC は、ユーザーの対話コンテキスト内で、攻撃を受ける可能性がある範囲を拡大することによって、特定の機能を実行できるようにします。唯一の問題は、なんらかの方法で、そのタスクに管理者特権が必要であること、およびそのタスクを完了するために必要な昇格がユーザーによって許可されたことを Windows に通知する必要があることです。

Figure 4** Two instances of cmd.exe with different privileges **(画像を拡大するには、ここをクリックします)

Windows Vista で表示される小さな盾は、昇格が必要なタスクを示しています (図 5 参照)。これらのタスクは、実行されるたびに昇格を必要とします。この動作は、Windows Vista の泣き所の 1 つとして、新聞や雑誌などで取り上げられています。この選択肢によって、資格情報はより "厄介" なものになり、セキュリティの脅威がもたらされ、システムが今までよりも簡単に攻撃される可能性があります。

Figure 5** Shields in Windows Vista indicate the need for elevation **(画像を拡大するには、ここをクリックします)

UAC が有効になっており、単純にユーザーとしてシステムを実行している場合は、アプリケーションで管理者特権が必要になったとき、ユーザーに一連の管理者資格情報の入力が要求されます。この場合、アプリケーションは、runas や psexec を使用する場合と同じように、そのアプリケーションを起動したユーザーのコンテキスト内で実行されます。これは、UAC が有効になっており、管理者としてシステムを実行している場合とは異なる動作です。アプリケーションのタスクはユーザーのコンテキスト内で実行されますが、昇格した権限が使用されます。

Windows Vista をユーザーとして実行する

個人的には、Windows Vista を実行するときは、UAC を有効にした状態で管理者として実行するのではなく、実際にユーザーとして実行した方がよいと思います。一般的な企業では、依然としてこれが最善の方法です。ユーザーには各自のシステムに対する完全なアクセス権が与えられ、さらにマルウェアの攻撃を受ける確率が低下する可能性があります。

また、グループ ポリシー、ウイルス対策ソフトウェア、マルウェア対策ソフトウェアなどを使用してユーザーを管理する計画を立てており、実際に特定のタスクを実行または完了するかどうかを一元管理する必要がある場合は、エンド ユーザーが管理者ではないことを保証することが重要です。ユーザーが管理者である場合、それらのユーザーはサービスの停止、ドライバの追加、ドライバの削除など、あらゆる操作を行うことができます。もちろん、狡猾なエンド ユーザーは、ユーザーとしてシステムを実行する場合でも、Windows PE を使用して、セキュリティのハードルを越えてくる場合があります。BitLocker® を使用すると、この操作を困難にすることができます。ただし、コンピュータに物理的にアクセスできる場合、十分な時間、知識、および努力があれば、コンピュータにどのような変更を加えることも可能であることを覚えておいてください。

Windows Vista をユーザーとして実行することは、Windows XP をユーザーとして実行することとそれほど大差ないので、同じツール (PSExec、RunAs、および UAC) を使用し、必要に応じて管理者としてタスクを実行します。この方法のメリットは、管理者特権を必要とする Windows XP の多くのタスクで、この特権が要求されなくなることです。たとえば、Windows Vista ユーザーはローカル プリンタをインストールできます (Windows XP ユーザーはネットワーク プリンタをインストールできますが、ローカル プリンタをインストールするには管理者特権が必要です)。Windows Vista では、ユーザーが物理的にコンピュータにアクセスでき、プリンタ ドライバがドライバ ストアに格納されている場合、そのユーザーは、プリンタをインストールし、そのプリンタで印刷ジョブを管理できます (詳細については、go.microsoft.com/fwlink/?LinkId=111534 を参照してください)。この機能は、Windows Server 2008 では無効になりました。

Windows XP でユーザーとしてシステムを実行しているときに、時計機能 (非表示になっている場合もあります) を操作することがあります。ユーザーとして時計をダブルクリックしてみてください。この操作は、よく日付を確認するために行われます (そのような目的のために設計された動作ではないかもしれませんが)。この場合、当然図 6 のようなエラー メッセージが表示されますが、あまり親切な機能とは言えません。Windows XP では、ポリシーを変更してユーザーにこの操作を許可することができましたが、Windows Vista では、この操作を許可しないように動作が変更されました。このため、全体的に見て、Windows Vista では、Windows XP の場合と異なり、通常はユーザーとしてシステムを実行した方がよいでしょう (UAC を使用するか、正式なユーザーとして実行し、別のユーザーとして昇格します)。

Figure 6** In Windows XP, non-admins couldn't change the time **(画像を拡大するには、ここをクリックします)

制限を思い出す

ユーザーを管理者以外の役割に移行することによって、すべての問題が解決されるわけではありません。エンド ユーザーは依然として物理的に各自のコンピュータにアクセスできるので、特にポリシーやユーザー特権によって不都合が生じたり、作業を完了できなくなった場合、熱心なユーザーは懸命に方法を探し、そのコンピュータのシステムに変更を加える可能性があります。

ユーザーが管理者としてシステムを実行している場合、それほど多くの作業を行わなくても、適用されているグループ ポリシーを回避できます。もちろん、さらにもう少し手を加えれば、ユーザーは Windows PE を起動し、通常は特権が与えられていない、アクセス許可の変更操作を行うことができます。ただし、BitLocker や、その他のドライブ暗号化またはボリューム暗号化を使用すれば、このような操作を不可能にするか、少なくとも困難にすることができます。

組織でまだエンド ユーザーが管理者としてシステムを実行しており、管理者からユーザーへの移行を始めていない場合、最も大事なことは、皆さん自身と組織が、なぜ時間、資金、および労力を割いて、ユーザーが管理者としてシステムを実行しないようにする必要があるのかを理解することです。

もちろん、古いアプリケーションを手放すのはつらいかもしれませんが、ユーザーとして実行できないアプリケーションを保有しているのであれば、組織のセキュリティを犠牲にしてまでそれにしがみつくのは良い考えではありません。アプリケーションの仮想化を検討することをお勧めします。つまり、仮想化という言葉どおり、エンド ユーザーが管理者としてシステムを実行できる仮想マシンにアプリケーションを移行します。これにより、必要に応じてアプリケーションを使用できるだけでなく、管理者をユーザーに移行することによって、システムの残りの部分をセキュリティで保護できるようになります。

このコラム全体を通して、私は "ロックダウン" またはそれに似た言葉を使用しませんでした。多くの人は、管理者からユーザーへの移行と言えば、これらの言葉によって表される作業の 1 つだと考えてしまいます。私が心理学を勉強したからかもしれませんし、現在マーケティングに携わっているからかもしれませんが、特権が奪われる (動作的にはそうですが) ような印象をエンド ユーザーに与える言葉を使用しないことが重要だと思います。

その代わりに、組織のセキュリティにもたらされるメリットを強調し、特定のユーザーが絶対にユーザーとしてシステムを実行できない場合や、管理者特権を必要とする特定のタスクが存在する場合などの極端な状況に対処できるように、適切な計画を立てるようにしてください。以前に紹介した Run.vbs スクリプト (technetmagazine.com/issues/2007/03/DesktopFiles 参照) のような手動ツールを使用するか、移行に役立つ (エンド ユーザーが移行作業を意識することなく、すべてが問題なく動作するようになる) 市販のソリューションを使用するかにかかわらず、できるだけ早く、管理者以外の役割への移行を始めることが重要です。TechNet Magazine にもよく寄稿している Aaron Margosis は、管理者以外の役割としての実行を普及させる取り組みを行っています。彼のブログを読んだことがない皆さんは、blogs.msdn.com/aaron_margosis を参照してください。このトピックについて、どこよりも詳しい情報が記載されています。

Wes Miller は、テキサス州オースティンにある CoreTrace 社 (www.CoreTrace.com) のシニア テクニカル プロダクト マネージャです。以前は Winternals Software 社に勤務し、その後はマイクロソフトでプログラム マネージャとして働いていました。Wes の連絡先は、technet@getwired.com (英語のみ) です。

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