印刷用ページ       送信     
クリックして評価とフィードバックをお寄せください
TechNet
TechNet ライブラリ
テクニカルドキュメント
Windows
Windows XP
運用
 Windows XP でユーザー アカウントに最小特権の原則を適用する

  低帯域幅での表示をオンにする
Windows XP でユーザー アカウントに最小特権の原則を適用する
公開日: 2006年7月18日

このガイドに関するご質問やコメントを送る場合は、secwish@microsoft.com (英語のみ) へご連絡ください。

このガイドに関するブログについては、http://blogs.technet.com/secguide (英語情報) をご覧ください。

トピック

はじめに
管理者特権の使用に伴うリスク
最小特権の原則の定義
LUA アプローチの定義
LUA アプローチの利点
リスク、セキュリティ、使いやすさ、およびコスト間でのトレードオフ
LUA アプローチの実装
将来的な展望
要約
関連情報
謝辞

はじめに

インターネットへの常時接続を始めとするネットワーク テクノロジの近年の進歩に伴い、あらゆる規模の組織が多くのチャンスを手に入れました。しかし残念なことに、組織内のコンピュータがあらゆるネットワーク、特にインターネットとつながるようになったことで、悪意のあるソフトウェアや外部からの攻撃を受けるリスクも増大しています。1 つのリスクを解決しても、また新たに別のリスクが登場する、という繰り返しになっています。

インターネット セキュリティ会社、ソフォスは、1999 年 11 月に検出された 45,879 の悪意のあるプログラムが、2005 年の 11 月には 114,082 になり、この 6 年間、毎年 10 パーセント以上増加していると報告しています。2005 年の 11 月には、ソフォスは、ウイルス、トロイの木馬、スパイウェアといった悪意のあるソフトウェアを新たに 1900 以上発見しています。他のウイルス対策ベンダも、悪意のあるソフトウェアの数と種類の増加については同様の報告をしています。

悪意のあるソフトウェアのリスクが増大している重要な要因として、ユーザーに、各自のクライアント コンピュータに対して管理者特権が与えられるという傾向が挙げられます。ユーザーまたは管理者が管理者特権でログオンした場合、ブラウザや電子メール クライアント、またインスタント メッセージング プログラムなどの実行プログラムにも、管理者特権を持つことになります。これらのプログラムが悪意のあるソフトウェアを起動した場合、悪意のあるソフトウェアはそれ自体をインストールし、ウイルス対策ソフトウェアなどのサービスを操作し、オペレーティング システムから見えなくすることさえできるのです。ユーザーは、セキュリティ侵害された Web サイトにアクセスしたり、電子メール メッセージのリンクをクリックしたりすることにより、意図せず、知らないうちに悪意のあるソフトウェアを実行してしまう可能性があります。

キー ロガーを使用してログオン資格情報を傍受することから、Rootkit を使用して 1 台のコンピュータ、また社内ネットワーク全体を完全に支配することまで、組織は悪意のあるソフトウェアからの多くの脅威にさらされています。悪意のあるソフトウェアは、Web サイトをアクセス不能にしたり、データを破壊または破損したり、ハード ディスクを再フォーマットしたりします。その結果として、コンピュータのウイルス駆除、ファイルの回復、失ったデータの再入力や再作成などの追加費用が生じます。また、プロジェクト チームは納期に遅れることで契約違反となり、顧客からの信頼を失ってしまいます。さらに、規制要件の対象となる組織では、起訴されたり、罰金を支払うことにもなりかねません。

: Rootkit の詳細については、Wikipedia の Rootkit に関する解説ページ http://ja.wikipedia.org/wiki/%E3%83%AB%E3%83%BC%E3%83%88%E3%82%AD%E3%83%83%E3%83%88 を参照してください。

最小特権ユーザー アカウント (LUA) アプローチ

これらの脅威に対抗するためには、セキュリティ層を重複して構築する多層防御戦略が最も適しています。この防御戦略では、最小特権ユーザー アカウント (LUA) アプローチが重要な役割を果たします。LUA アプローチでは、ユーザーは、最小特権の原則に従い、常に制限付きユーザー アカウントでログオンします。また、管理者は管理タスクの実行時にのみ管理者資格情報を使用します。

LUA アプローチは、悪意のあるソフトウェアや、偶発的な不適切な構成から生じるリスクを大きく軽減できます。ただし、LUA アプローチを実装するには、組織は制限付きアクセス構成を計画、テスト、サポートする必要があるため、多大な費用と労力が必要になります。費用には、カスタム プログラムの再開発、操作手順の変更、補足ツールの展開などにかかる費用が含まれます。

重要   制限付きユーザー アカウントの使用に関するユーティリティやガイダンスを見つけることは困難なため、このホワイト ペーパーでは、Web ログやその他非公式ソースのサードパーティ製ツールやガイダンスを参考にしています。このホワイト ペーパーは、個々のユーザー環境におけるこれらのツールおよびガイダンスの適合性を保証するものではありません。実際に、これらのインストラクションやプログラムをユーザー環境で展開する場合には、事前にテストしてください。すべてのセキュリティ案件と同様、完全な解決法というものはなく、このソフトウェアとガイダンスも例外ではありません。

対象読者

このホワイト ペーパーは、以下の読者が対象です。

  • LUA アプローチの概念と、LUA アプローチの実装により生じる問題を理解する必要があるビジネス上の意志決定者。

  • 組織が LUA アプローチを実装する際の選択肢を理解する必要がある IT の専門家。

トピック

このドキュメントは、Microsoft® Windows® XP を実行するコンピュータに LUA アプローチを適用する際に直面する問題について解説しています。このドキュメントのトピックは次のとおりです。

  • 管理者特権の使用に伴うリスク

  • 最小特権の原則の定義

  • LUA アプローチの定義

  • LUA アプローチの利点

  • リスク、セキュリティ、使いやすさ、およびコスト間でのトレードオフ

  • LUA アプローチの実装

  • 将来的な展望

このホワイト ペーパーでは、LUA アプローチの実装に影響する高いレベルの問題にも言及しています。これらについて、より詳しく説明している他のオンライン リソースへのリンクも提供しています。

   このホワイト ペーパーでは、最小特権アカウントでのシステム サービスの実行に関する問題については扱っていません。このトピックの詳細については、「サービスおよびサービス アカウントのセキュリティ計画ガイド」www.microsoft.com/japan/technet/security/topics/serversecurity/serviceaccount/default.mspx を参照してください。

管理者特権の使用に伴うリスク

多くの組織では、日常的に、ユーザーに各自のコンピュータに対する管理者特権を与えています。この方法は、特にポータブル コンピュータに対しては、次の理由により一般的です。

  • プログラムを適切に実行するため。管理者特権がないと実行できないプログラムがあります。通常このようなプログラムは、管理者アカウントでないとアクセスできないレジストリやファイル システム内に、ユーザー データを保管するプログラムです。

  • ユーザーが管理アクションを実行できるようにするため。たとえば、コンピュータのタイム ゾーンの変更などです。

  • 印刷デバイスや DVD 書き込み装置、およびそれに関連付けられているプログラムなど、作業に関連するハードウェアやソフトウェアをモバイル ユーザーがインストールできるようにするため。

その他にも管理者特権をユーザーに与える正当な理由がありますが、そうすることで、コンピュータのセキュリティ侵害や不適切な構成のリスクが著しく増大します。これらのリスクは、組織経営のさまざまな領域に影響を及ぼします。

たとえば、会社の役員が定期的に取引先に出向き、自分のポータブル コンピュータを使用してプレゼンテーションを行っているとします。彼は役員であるため、自分のコンピュータをローカル管理者権限で使用し続けていました。ある日、重要な顧客へ重要な販売プレゼンテーションを始めようとしたとき、彼のコンピュータの画面にウイルス メッセージが現れ、コンピュータがロックされてしまいました。彼はコンピュータを急いで再起動させましたが、ハードディスクが再フォーマットされてしまった後でした。結果、プレゼンテーションは失敗し、顧客は競争相手に注文を依頼することとなりました。

このケースでは、ウイルス メッセージとそれに伴うデータ破壊は、この役員がセキュリティの侵害された Web サイトにアクセスしたときに、コンピュータがウイルスに感染したために起こりました。彼がその Web サイトにアクセスしたとき、自分のポータブル コンピュータにローカル Administrators グループのメンバとしてログオンしました。このグループのメンバシップから付与される権限と特権によって、悪意のあるソフトウェアはウイルス対策ソフトウェアを無効にし、自分自身をインストールしてレジストリを操作し、自身のファイルを Windows システム ディレクトリに格納できたのです。この時点で、この役員のコンピュータのセキュリティは侵害され、悪意のあるソフトウェアのコマンドが実行を待つばかりという状態だったのです。

管理者アカウントの特権が利用されるその他の例としては、電子メール メッセージ内のリンクをクリックしたり、デジタル著作権管理ソフトウェアが含まれている音楽 CD を再生するなどが考えられます。管理者権限を持つユーザーのコンピュータは、制限付きユーザー アカウントを持つユーザーのコンピュータより、セキュリティが侵害される可能性がはるかに高いのです。

最小特権の原則の定義

『The Department of Defense Trusted Computer System Evaluation Criteria (DOD-5200.28-STD)』はオレンジ ブックとも呼ばれ、コンピュータ セキュリティに関する承認済み基準書です。この基準書では、最小特権の原則を「システム内の各対象に、許可されたタスクの実行に最低限必要な特権 (または最小限の許可) のみ与える」と定義し、「この原則の適用により、偶発的、誤り、または不正な使用によって発生する損害を軽減できる」と説明しています。

LUA アプローチの定義

このホワイト ペーパーでは、Windows XP を実行するコンピュータに、最小特権の原則を実践的に適用するためのアプローチとして LUA アプローチを定義しています。具体的には、LUA アプローチでは、Windows XP 上のユーザー、プログラム、およびサービスに対して、各自割り当てられたタスクを実行するのに最低限必要な権限とアクセス許可のみを与えます。

: 権限とアクセス許可との違いを理解しておくことが重要です。権限は、ユーザーがコンピュータ上で実行できるタスクを定義し、アクセス許可は、ユーザーがコンピュータ上のオブジェクトに対してできることを定義します。つまり、ユーザーは、コンピュータをシャットダウンするためには "権限" が必要で、ファイルにアクセスするためには "アクセス許可" が必要です。

LUA アプローチは、組織が Windows XP を実行するコンピュータの操作に管理者以外のアカウントを使用するための推奨事項、ツール、およびベスト プラクティスの組み合わせです。LUA アプローチを実装するために、組織はコンピュータの役割、およびユーザーが自身の装置に対して持つアクセス レベルを再評価する必要があります。LUA アプローチは、制限付きユーザー アカウントの使用に際して考慮すべき戦略的、および日常的な重要事項についても解説します。たとえば、ユーザーがリモートから自分のコンピュータの構成を変更する場合に生じる問題について説明します。

LUA アプローチは、アプリケーションの開発環境およびテスト環境にも適用する必要があります。開発者 (およびテスター) は、通常管理者権限を持つアカウントでコンピュータにログオンします。この構成では、開発者がリリースするコンパイル済みプログラムも、同様の上位特権が必要になります。開発者は、アプリケーションの動作を設計し直すのではなく、ユーザー アカウントをローカル Administrators グループに入れたり、ユーザーに Windows システム フォルダに対するフル コントロールを付与するなどの "セキュリティ回避策" を取るのが普通です。

LUA アプローチは、リソースにアクセスする必要があるすべてのユーザーまたはプログラムに、ただ単に管理者の権限とアクセス許可を付与するという方法に対抗するものです。最小特権の原則に従ったプログラムは、リソースに対する正当な要求を拒否しようとするのではなく、適切なセキュリティ ガイダンスに従ってアクセス権を付与します。

アプリケーションの作成に関するベスト プラクティスについては、「Running with Special Privileges」 (英語情報) を参照してください。

Windows XP のアカウント

LUA アプローチの背景になっている原則について理解するには、Windows XP での管理者アカウントと非管理者アカウントとの違い、および Windows がプログラムを起動し実行する方法について理解しておくことが必要です。また、ワークグループおよびドメインベースのネットワーク内のグループについても理解しておく必要があります。

Windows XP を実行するコンピュータは、ローカルのセキュリティ アカウント マネージャ (SAM) に独立したセキュリティ データベースを保持します。SAM には、ローカルのユーザー情報とグループ情報が格納されます。以下のグループを含む多くのデフォルト グループがあります。

  • Administrators: コンピュータに対して、完全かつ無制限なアクセス権を持ちます。

  • Power Users: ファイルの共有、ローカル プリンタのインストール、システム時刻の変更など、多くの制限された管理者権限を持ちます。Power Users は、Windows システム フォルダ内のファイルにアクセスできるアクセス許可も持っています。

  • Users: ユーザー権限が制限されており、偶発的または故意によるシステム全体への変更は許可されません。このグループ メンバのユーザー アカウントのみが、"制限付きユーザー アカウント" と呼ばれます。

  • Guests: 制限付きユーザーより少ない権限しか持ちません。

ユーザー アカウントには、これらのグループの 1 つまたは複数のメンバシップから権限が付与されます。たとえば、組み込み Administrator アカウントは、Administrators グループのメンバであるため、管理者権限を持ちます。このグループのメンバシップにより、Administrator アカウントに、リモート コンピュータからシステムをシャットダウンする権限といった上位権限が付与されます。

ワークグループ ベースのコンピュータは完全に独立し、それ自体の SAM でグループとユーザーを評価するだけです。ワークグループ コンピュータがドメインに入ると、ローカルのグループ メンバシップが変わります。既存のグループに加え、Domain Users はローカル Users グループのメンバになり、Domain Admins グループは Administrators のメンバになります。この変更により、Domain Admins グループのメンバは管理者権限でコンピュータにログオンでき、Domain Users グループのメンバは制限付きユーザー権限でコンピュータにログオンできます。

管理者アカウント

管理者アカウントとは、1 つまたは複数の管理者グループのメンバであるアカウントのことです。ドメイン コンピュータ上の管理者グループには、以下のグループが含まれます。

  • ローカル Administrators グループ

  • ローカル Power Users グループ

  • Domain Admins グループ

  • Network Configuration Operators グループ

  • ローカル管理者グループのメンバシップを持つすべてのドメイン グループ

これらグループのうちの 1 つまたは複数のメンバシップでログオンするユーザーは、システム全体に対する変更を実行できます。

: Power Users グループは、Users グループの特権をすべて含んでいるというより、Administrators の部分集合になります。Power Users グループへのユーザーの追加は、LUA 原則に準拠していません。

制限付きユーザー

制限付きユーザーは、ローカル Users グループのメンバのアカウントで、管理者グループのメンバではありません。 ドメインに参加しているコンピュータ上では、Domain Users グループのメンバであるアカウントは、ローカル Users グループのメンバでもあります。

制限付きユーザー アカウントは、操作上のセキュリティに影響するような、システム全体に対する変更を実行するための最小限の権限しか持っていないため、悪意のあるソフトウェアからの攻撃を受けにくいアカウントです。制限付きユーザー アカウントは、ファイアウォールのポートを開くことも、サービスを停止したり開始したりすることも、Windows システム フォルダ内のファイルを変更することもできません。

多くの組織では、ユーザーは Domain Users グループのメンバとしてログオンしており、既に LUA アプローチを実装していると主張するかもしれません。しかし、そのユーザーがローカル Administrators グループのメンバでもある場合には、そのユーザーが実行するプログラムはすべて管理者権限を持ち、不必要な変更を行う可能性があるのです。

ログオン プロセスについて理解する

Windows XP の認証プロセスについて理解しておくことも、重要です。ユーザーがコンピュータにログオンすると、オペレーティング システムがそのユーザーの資格情報を認証し、Windows デスクトップのインスタンス、通常は Windows エクスプローラを起動します。このデスクトップは、ユーザーのアクセス権限とアクセス許可でログオンされたユーザーのセキュリティ コンテキスト内で実行されます。ユーザーが、Microsoft Internet Explorer などのプログラムを起動した場合、このプログラムも、そのユーザーのセキュリティ コンテキストで実行されます。

Administrator として認証する

ユーザーがローカル Administrators グループのメンバとして認証されると、そのデスクトップと、そのユーザーが起動するすべてのプログラムは、フル アクセス権と管理者のアクセス許可で実行されます。管理者権限を持つユーザーは、コンピュータを管理する上で必要な、次のアクションを実行できます。

  • サービスおよびデバイス ドライバのインストール、開始、および停止

  • レジストリ設定の作成、変更、および削除

  • プログラムのインストール、実行、およびアンインストール

  • オペレーティング システム ファイルの置換

  • プロセスの終了

  • ファイアウォール設定の制御

  • イベント ログ エントリの管理

  • Microsoft ActiveX® コントロールのインストール

  • SAM へのアクセス

大部分のコンピュータ ユーザーにとってこれらの権限は不要であり、またコンピュータのリスクを著しく増大させるものです。管理者権限を持つユーザーはこれらシステム全体に対する変更を実行できるため、故意であれ、偶発的であれ、管理者権限を持つユーザーが実行するプログラムも、システム レベルの変更を実行できることになります。したがって、悪意のあるソフトウェアにとっては、管理者権限で認証されるユーザーのコンピュータに侵入することは、管理者権限以外のユーザーのコンピュータに侵入することよりはるかに簡単なのです。

User として認証する

Administrators グループのメンバでないユーザーは、非常に少ないリソースにしかアクセスできません。そのため、特定の領域への変更しか実行できません。管理者権限とユーザー権限とを比較するために、ユーザーが実行できるタスクを以下に示します。

  • サービスおよびデバイス ドライバのステータスの表示

  • HKEY_CURRENT_USER 内のレジストリ設定と HKEY_LOCAL_MACHINE 内のレジストリ設定の作成、変更、および削除

  • プログラムの実行

  • 大部分のオペレーティング システム ファイルの読み取り

  • 実行中のプロセスの表示

  • ファイアウォール設定の表示

  • システム ログ エントリとアプリケーション ログ エントリのみの表示

制限付きユーザーでも、各自作業するのに必要なタスク、たとえば、ワイヤレス ネットワークへの接続、署名されたプラグ アンド プレイ ドライバのインストール、デスクトップ設定の変更などは実行できます。LUA アプローチは、このような権限を制限するものではなく、管理者権限を持つアカウントを制限することによってリスクを軽減するものです。

ここまで、Windows XP のグループの役割と、管理者権限と制限付きユーザー権限での認証の違いについて説明してきました。次に、制限付きユーザー アカウントを使用する利点について説明します。

LUA アプローチの利点

規模に関わらず、すべての組織は LUA アプローチを実装することにより、多くの利点を享受できます。悪意のあるソフトウェアから攻撃を受けるリスクを軽減できる以外にも、次のような利点があります。

  • セキュリティの強化

  • 管理容易性の強化

  • 生産性の向上

  • コスト削減

  • 著作権侵害および法的責任問題の抑制

ここでは、これらの利点と、それらが組織に与える影響について説明します。

セキュリティの強化

LUA アプローチは、組織およびそのコンピュータ資産を攻撃者から保護するための、多くの手段のうちの 1 つです。攻撃者は、次のような理由から、ネットワーク セキュリティの侵害を試みます。

  • 分散サービス拒否攻撃で使用する複数のコンピュータの制御を取得する。

  • スパムを送信する。

  • 機密情報を危険にさらす。

  • ユーザー識別情報を盗む。

  • 悪意のあるソフトウェアを他のコンピュータに分散する。

このような攻撃は、ユーザーが管理者権限を持つアカウントでログオンしている場合に、成功しやすくなります。たとえば、管理者権限で実行しているソフトウェアであれば、次のことが可能です。

  • カーネル モードの Rootkit をインストールする。

  • システム レベルのキー ログ プログラムをインストールする。

  • ログオン パスワードを傍受する。

  • スパイウェアとアドウェアをインストールする。

  • 他のユーザーのデータにアクセスする。

  • 誰かがログオンしたときにコードを実行する。

  • システム ファイルをトロイの木馬に置き換える。

  • パスワードをリセットする。

  • イベント ログ内の攻撃の痕跡を隠す。

  • コンピュータを再起動できないようにする。

ユーザーが制限付きユーザー アカウントでログオンした場合、そのユーザーのコンテキストで実行するプログラムには、オペレーティング システムへの最小限の変更しか許可されません。この制限により、ユーザーの作業を妨げることなくセキュリティを強化し、悪意のあるソフトウェアがインストールされたり実行されたりするリスクが大きく軽減します。

管理容易性の強化

標準化は、管理可能なネットワークの重要な要素となります。特に、多くのクライアント コンピュータで構成されるネットワークの場合、標準化は重要です。500 台のクライアント コンピュータがあり、各コンピュータにそれぞれ個別のソフトウェア構成とコンピュータ設定がある場合、予防対策的な管理は非常に複雑になります。ユーザーがソフトウェアをインストールし、システム レベルの構成を変更できる場合、管理は必然的に複雑になります。

Windows XP では、非常に広い範囲でオペレーティング システム構成をカスタマイズできます。管理者権限でログオンできるユーザーは、さまざまな場面で設定を変更することができます。たとえば、ユーザーは、あるワイヤレス ネットワーク接続に対して Windows ファイアウォールを無効にし、公開ワイヤレス アクセス ポイントから、セキュリティで保護されていない接続経由でインターネット サービス プロバイダに接続することもできます。ネットワーク接続はすべて (信頼できるネットワークに対しても)、ホスト ベースのファイアウォールで保護されていることが多いので、このような操作により、コンピュータのセキュリティは簡単に侵害されます。

ユーザーが行った変更が原因でサポート コールが増えることが予想されるため、設定を変更したコンピュータを修正する必要が生じるたびに、サポート担当者は異なるコンピュータの構成に対応しなければなりません。標準化していないことで、ヘルプ デスクによるサポート、トラブルシューティング、および修理はより困難になり、時間およびコストがかかるという結果を招きます。

LUA アプローチは、ユーザーと管理者の管理上の境界を明確にすることでもあります。この境界により、ネットワーク管理者がインフラストラクチャを管理している間、ユーザーは各自の作業に集中することができます。ユーザーに管理者権限があると、この境界線が無くなり、標準化が確立されません。

すべてのユーザーが管理者であるネットワークは、効果的に管理されていないネットワークと言えます。すべてのユーザーがシステムの管理設定をを巧みに回避できるからです。ユーザーが、許可されていないハードウェアやソフトウェアをインストールしたり、システム設定を変更したりといった操作ができない場合に、そのコンピュータは組織標準に準拠していると言えます。LUA アプローチは、コンピュータ環境の不要な変更を制限することにより、管理容易性を強化します。

生産性の向上

コンピュータは、あらゆる業種および規模の組織の生産性を大きく向上させてきました。しかし、この高い生産性を維持するためには、予防対策的な管理を行うことが必要です。ユーザーが自分のコンピュータを使って作業する組織の場合、IT 担当者は、作業パターンをできるだけ壊さないようにする必要があります。特に、不適切な構成や悪意のあるソフトウェアによる感染など、回避可能な要因はできる限り排除する必要があります。

LUA アプローチでは、クライアント コンピュータ構成を保持することにより、高い生産性を維持できます。ユーザーが各自のコンピュータの構成を変更できない場合、そのコンピュータはより安定し、それによりダウンタイムが縮小し、高い生産性が維持されます。

コンピュータが悪意のあるソフトウェアから感染を受けた場合にも、生産性が低下します。その場合、コンピュータのウイルス駆除や再フォーマットの必要が生じ、ユーザーはドキュメントやデータを失います。管理者はファイルのバックアップ コピーを復元し、さらに更新も必要になります。これらの感染後の処理により、従業員は作業の中断を余儀なくされ、さらには作業のやり直しが必要になります。

コスト削減

複数台のクライアント コンピュータの保守には通常でもコストがかかりますが、以下の要因により、さらにコストがかかることが考えられます。

  • 独自の、テストされていないハードウェアとソフトウェアの組み合わせ

  • オペレーティング システムに対する不明な変更

  • システム全体に対するカスタム設定

  • ファイルの種類が不明な非標準ソフトウェア

  • ユーザーが独自にインストールしたソフトウェアのライセンス

  • ライセンスのないソフトウェアに対する罰金

  • 悪意のあるソフトウェア

  • ベータ版のソフトウェアとドライバ

  • 悪意のあるソフトウェアによるインターネット帯域幅の使用

LUA アプローチは、許可されていない、ライセンスのない、または悪意のあるソフトウェアのインストールを防ぎます。また、ユーザーによるコンピュータの不明な変更も防ぎます。これらの制限により、管理者権限を持つユーザーが原因となる、ヘルプ デスク サポートやダウンタイムにかかるコストを軽減できます。

著作権侵害および法的責任問題の抑制

従業員による会社設備の不正使用を禁じるための法令順守義務に対する組織の意識はますます高まっています。会社は、従業員による偶発的および故意による以下の行為があった場合、措置を講じる必要があります。

  • 顧客データ (個人を識別できる情報 (PII) など) の流出

  • 海賊版の、違法な、または侮蔑的なコンテンツが含まれる Web サイトの運営

  • 未承諾広告メールを送りつけるリレー サーバーの運営

  • 分散サービス拒否攻撃への関与

LUA アプローチを実装している組織では、クライアント コンピュータのセキュリティが侵害されにくいため、このような不正使用により責任を問われる危険性は大幅に減少します。加えて、不正コンテンツをホストするために必要な、許可されていないソフトウェアをインストールすることが難しくなるため、ユーザーが、このような法的責任が問われるような行為に及ぶ機会が大幅に減少します。このような保護措置は、制限付きユーザーが Program Files フォルダ、Windows システム フォルダ、およびレジストリの HKEY_LOCAL_MACHINE セクションに対して、読み取りアクセス権しか持たないために実現可能となります。プログラムのインストールには、通常、これらの場所への書き込みアクセス権が必要です。

リスク、セキュリティ、使いやすさ、およびコスト間でのトレードオフ

多くのネットワーク管理アプローチと同様、LUA アプローチを実装する際には、リスク、セキュリティ、使いやすさ、コスト間でのトレードオフを比較検討する必要があります。LUA アプローチを適切に実装すると、次のことが可能です。

  • リスクの軽減

  • セキュリティの強化

  • 使い勝手の向上

  • 管理コストの削減

リスクの軽減

コンピュータ ネットワークに接続することは、リスクを伴います。また、インターネットへの接続は、イントラネット上のリソースへの接続よりも、高いリスクを伴います。このリスクを完全に排除するには、ネットワークに接続しないよりほかに方法がありません。ほとんどの組織が、ネットワーク接続のメリットの方がリスクを上回ると考えていますが、このリスクを最小限に抑えるための戦略は必要な予防措置だと考えています。

LUA アプローチは、管理者権限でプログラムが実行されることにより発生する現在のリスクと将来のリスクの両方を大幅に軽減します。LUA アプローチを実装しない組織は、コンピュータの使用に関連するリスクを増大させるだけでなく、攻撃者がメーカーより前にソフトウェアの脆弱性を発見するゼロデイ攻撃など、新手の攻撃に対するリスクも増大させることになります。LUA アプローチを実装する組織は、さらにリスクを軽減するセキュリティ更新自動インストールなど、他のデスクトップ管理戦略も実装する傾向が強くなります。

セキュリティの強化

LUA アプローチは、セキュリティの強化に大きく貢献します。代わりに、ユーザーが構成を変更しにくくなるという代償が発生しますが、必ずしも使い勝手が悪くなるということではありません。このことについては、次のセクションで解説します。

LUA アプローチは完璧なセキュリティ戦略ではなく、多層防御戦略の一環として、他のセキュリティ防御策とともに実装する必要があります。LUA アプローチは、ユーザーの意識向上、境界ファイアウォール、ホスト ファイアウォール、定期的なセキュリティ更新、最新ウイルス対策ソフトなどとともに実装する必要があります。LUA アプローチは、悪意のあるソフトウェアが組織内で拡散しないようにするという補足的なセキュリティを提供するものです。

使い勝手の向上

ネットワーク管理の自明の理として、使い勝手とセキュリティは反比例し、セキュリティを向上させると、使い勝手は悪くなります。

: 使い勝手というのは、使いやすさのことであり、ユーザーが自分のコンピュータを変更しやすくなるということではありません。

LUA アプローチは、ユーザーがコンピュータを使用することを防ぐのではなく、コンピュータを管理することを防ぎます。管理者権限を削除するということは、ユーザーの生産性を上げることにもなります。管理者権限がなくなることにより、ユーザーは作業を中断させられることが少なくなり、自分のコンピュータに不適切な構成を適用してしまう可能性も低くなります。

ただし、構成オプションが表示されるのに、それを変更できないという状況は、ユーザーが不満を感じる要因となり、ヘルプ デスクへの連絡が増える原因にもなります。グループ ポリシーを使用すると、そのような Windows インターフェイスの要素を、ユーザーから見えなくすることができます。変更できるオプションのみ表示されるという構成制限により、ユーザーの不満は大幅に軽減されます。LUA アプローチをグループ ポリシーと併用すると、ユーザーが変更できる構成オプションのみを表示する簡易インターフェイスを作成できます。

管理コストの削減

第三者機関によると、ネットワーク システム管理により長期的な節約ができるということが報告されています。LUA アプローチでは、制限付きユーザーは管理設定を変更できないため、LUA アプローチはシステム管理戦略と密接に関係しています。ただし、システム管理のコスト削減を可能にするためには、LUA アプローチの実装に必要な投資を準備することが必要になります。また、LUA アプローチを実装した場合と実装しない場合にかかる両方のコストを計算する必要があります。

LUA アプローチを実装した場合は、次のことに対してコストがかかります。

  • プロジェクトの計画とパイロット

  • LUA 環境でのカスタム プログラムのテスト

  • 制限付きユーザー アカウントの回避策の調査

  • アプリケーションの書き直し (必要な場合)

  • 新しいプログラムの展開前のテスト

  • ヘルプ デスクへの連絡の初期段階での増加に対応するための準備

  • 変更に伴う政治的問題の解決

これらにかかるコストと、LUA アプローチを実装しない場合に発生するコストとのバランスを考えることが重要です。LUA アプローチを実装しない場合には、次のことに対してコストがかかります。

  • ユーザーが変更した不適切なコンピュータ構成

  • 許可されていない、テストされていない、ライセンスのない、または悪意のあるソフトウェア

  • 訴訟を起こされる可能性

  • セキュリティ侵害によるビジネス チャンスの損失

LUA アプローチを実装した場合と実装しない場合のコストを分析すると、実装した場合のコストは計算可能ですが、実装しなかった場合のコストは計り知れません。基幹業務アプリケーションを書き直すためにかかるコストは計算できますが、将来起こりうる訴訟にかかるコストは計算不可能です。

日々増大するネットワーク コンピュータへの脅威とコンピュータ構成の簡素化および標準化の必要性により、組織および個人が、ネットワークとコンピュータを制限付きユーザー アカウントで実行することがますます求められています。LUA アプローチに関して論議することで、組織の惰性と従来の悪しき慣習にメスを入れていると言えるでしょう。次に、LUA アプローチの実装方法について解説します。

LUA アプローチの実装

LUA アプローチを実装するには、Windows XP を実行するコンピュータに対して次の規則を適用します。

  • 管理者以外のユーザーは、常に制限付きユーザーとしてログオンする。

  • 管理者は、管理タスクを実行するときのみ、管理者アカウントを使用する。

このアプローチは、このホワイト ペーパーで解説してきた利点を持ち、フェイルセーフ環境を構築しますが、特に、ユーザーが管理者としてログオンすることを許可している組織の場合は、事前に解決しておくべき重要事項が数多くあります。

実装に伴う考慮事項

LUA アプローチの実装には、同時に、技術的な問題、管理上の問題、および組織内部の政治的な問題が伴います。次のような考慮事項があります。

  • コンピュータに対する制御

  • ハードウェアのインストール

  • プログラムのインストール

  • プログラムの実行

  • オペレーティング システムの更新

  • オペレーティング システムの構成

  • コスト

コンピュータに対する制御

最も対処が難しい政策上の問題は、クライアント コンピュータの制御に関することです。上級管理者とビジネス上の意志決定者の多くは、自分のコンピュータに対して完全な制御権を持つことを当然とし、この構成の持つリスクに対して無関心か、または認めようとしません。管理職にあるユーザーは、とかく自分たちに背く状況や、できないと告げるメッセージを嫌います。警告メッセージが表示された場合の彼らの典型的な反応は、ネットワーク管理者に、完全な管理アクセス権を要求することです。

この状況を打開するには、技術的な教育を受けたエグゼクティブ スポンサーの協力が必要です。多くの会社で、このエグゼクティブ スポンサーは主任情報指揮官 (CIO) 以上のポジションの人物で、他の管理職に対して、悪意あるソフトウェアの増大する危険性を説明し、このようなソフトウェアが悪意ある、またはセキュリティが侵害された Web サイトからどのようにインストールされるかについて説明できる人物である必要があります。このような教育によって十分に説得できない場合には、悪意あるソフトウェアが各々のコンピュータに意図せずインストールされてしまったために生じる訴訟事件について強調し、そして、このホワイト ペーパーで解説するツールにより、このような不安要素を解決できることを説明します。

ユーザーを教育するのは難しいものです。大部分のユーザーが、自分のものだと思っているコンピュータに対する制御権を奪われることに脅威を感じ、LUA アプローチの実装をやめさせようと画策するユーザーも出てきます。多くのユーザーが、不平不満とともに、管理者権限がないことで直面する問題を大げさに騒ぎ立てます。しかし、完全なテスト プログラムを実行しておくことで、たいていは、このような不平は簡単に解決できます。

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

社内のデスクトップ コンピュータのユーザーに管理者権限が必要になることはありません。しかし、モバイル コンピュータのユーザーは、社内ネットワークに接続していないときに、作業に必要なプリンタや DVD 書き込み装置などのハードウェアをインストールすることが必要になることがあります。

モバイル ユーザーにおけるハードウェアのインストールに関しては、組織は、LUA アプローチに準拠しないオプションも含め、幅広いオプションを検討する必要が生じます。このホワイト ペーパーの次のセクションで説明するツールを使用すると、このようなハードウェアを管理できます。

プログラムのインストール

多くのプログラムがインストールに管理者特権を必要とします。これは、許可されないプログラムのインストールを防ぐ効果がありますが、同時に、許可されたプログラムやアップグレードもインストールできなくなります。プログラムのインストールは、ユーザーのコンピュータがドメインに参加していない場合や、社内ネットワークに一時的にしか接続しない場合は、特に問題になります。許可されたプログラムやセキュリティ更新プログラムのインストールに関する問題を解決するには、操作手順を変更し、Active Directory® のアプリケーション公開、Microsoft Systems Management Server (SMS) 2003 Service Pack 1 の上位権利での展開ツール、リモート デスクトップなどのツールを使用することが必要になる場合もあります。

インターネット サイトによっては、追加のソフトウェアや ActiveX コントロールをクライアント コンピュータにダウンロードすることを要求する場合があります。Internet Explorer 管理者キットやグループ ポリシーなどの管理ツールを使用することにより、その場所からソフトウェアをダウンロードすることに伴うリスクより、ビジネス上の必要性の方が大きいサイトに対して、この行為を許可することができます。

プログラムの実行

プログラムによっては、実行するのに管理者特権を必要とするものがあります。通常、このような制限の原因は、コーディング エラーか、プログラミングおよびセキュリティのガイドラインへの準拠に欠けていることが考えられます。たとえば、制限付きユーザー アカウントがレジストリ キー値を読み取ることが出来ないレジストリ内の場所に、プログラムが必須プロダクト キーをインストールする場合に、このようなことが発生します。

: Microsoft のプログラミング推奨事項に従ったプログラムであれば、セキュリティ上の制限がかかることはありません。

多くの場合、Users グループに、アプリケーションが失敗する原因となる場所へのアクセス権を付与することにより、問題は解決します。次のセクションで説明する Windows Application Compatibility Toolkit (ACT) でも、このような非互換性問題の多くを解決できます。ネットワーク管理者は、あるプログラムを実行するのに管理者アクセス許可が必要であるため、すべてのユーザーを管理者にすべきだという案を、安易に受け入れるべきではありません。

オペレーティング システムの更新

Microsoft Update Web サイトからオペレーティング システムの更新を手動でインストールする場合には、デスクトップ上のオペレーティング システムが管理者権限で実行されていることが必要です。つまり、Microsoft Update を使用するには、ユーザーは管理者資格情報でログオンすることが必要になります。ただし、自動更新サービスを利用すると、このサービスはシステム アカウント資格情報で実行するので、管理者資格情報は必要なくなります。自動的にオペレーティング システムとプログラムの更新をチェックしてインストールするように自動更新を設定しておけば、更新を手動で実行することは、ほとんど必要ありません。詳細については、「Windows XP、Windows 2000、または Windows Server 2003 で自動更新をスケジュールする方法」http://support.microsoft.com/kb/327838/ja を参照してください。

SMS 2003 Service Pack 1 には、管理者権限を持たないユーザーが、オペレーティング システムとアプリケーションの更新を識別し、インストールする機能が含まれています。また、Windows Software Update Services (WSUS) には、SMS を実装していない組織用の簡易セキュリティ更新管理機能が含まれています。

オペレーティング システムの構成

組織 IT ポリシーで、制限付きユーザーが自分のコンピュータで実行できる構成アクションを定義しておく必要があります。ローカルで、またはグループ ポリシーを利用してセキュリティ ポリシーとレジストリ設定を変更することにより、制限付きユーザー、たとえばモバイル ユーザーが、自分のコンピュータの時刻やタイム ゾーンを変更する必要がある場合に、これらの許可された変更アクションを実行できるように設定できます。以下のセクションでは、制限付きユーザー アカウントでのオペレーティング システム構成に伴う問題を解決するためのツールをいくつか紹介します。

コスト

最後に、LUA アプローチの計画、実装、および管理にはコストがかかる場合があります。基幹業務プログラムにサードパーティ製品またはカスタム製品を使用している場合は、非常に高いコストがかかる場合もあります。

たとえば、LUA アプローチと互換性のない、実行に管理者権限を必要とする基幹業務プログラムを使用している場合などです。プログラムの使用年数と稼動できる開発者数によりますが、組織は以下の操作を実行しなければならない可能性があります。

  • LUA 環境でのプログラムのテスト

  • プログラムが実行しない場合の緩和プロセスの識別

    • 複数のコンピュータに対するレジストリのアクセス許可のカスタマイズまたは修正

    • アクセス権の変更

    • 構成問題を解決するツールの配布

  • プログラムのゼロからの書き直し

ただし、新しい技術を実装するためのカスタム プログラムの更新を既に計画している組織の場合、LUA アプローチへの準拠にかかるコストはそれほど高くはなりません。

ツール

Microsoft およびその他のソフトウェア ベンダから、LUA アプローチを使用する環境を管理するための、多くの支援ツールが提供されています。ここでは、ユーザーが制限付きユーザー権限でログオンする環境での管理に役立つツールをいくつか紹介します。このようなツールの例を次に示します。

  • Secondary Logon サービス

  • MakeMeAdmin

  • PrivBar

  • PolicyMaker

  • Application Compatibility Toolkit

  • RegMon と FileMon

  • Systems Management Server

: MakeMeAdmin、Privbar、PolicyMaker、RegMon、および FileMon は Microsoft によってサポートされていません。これらのプログラムの適合性について、Microsoft では一切保証していません。これらのプログラムは、ユーザー自身の責任でご使用ください。

Secondary Logon サービス

Secondary Logon サービス (runas コマンド) を利用すると、ユーザーは代替資格情報でプログラムを実行できます。Secondary Logon サービスは、新しい資格情報とグループ メンバシップで別のセキュリティ トークンを作成し、プログラムはこの資格情報を使用してリソースにアクセスします。

Secondary Logon サービスは便利なツールですが、セカンダリ アカウントはプライマリ アカウントとは異なる資格情報を使用するため、次のような制限が発生します。

  • ユーザーはセカンダリ アカウントのパスワードを知っている必要があり、その資格情報を入力する必要があります。

  • プログラムによっては、現在のインスタンスと異なる資格情報を使って 2 つ目のインスタンスを実行できない場合があります。

  • セカンダリ アカウントはプライマリ アカウントとは異なるプリンタ マッピングとドライブ マッピングを持つ場合があります。

  • セカンダリ アカウントがローカル アカウントであれば、ネットワーク リソースまたはドメイン リソースへのアクセス権がなくなり、ドメイン ログオン スクリプトの実行やグループ ポリシーの適用ができなくなる場合があります。

  • プログラムのインストールなどの変更は、プライマリ アカウントのプロファイルではなく、セカンダリ アカウントのプロファイルに対して適用されます。これは、プログラムが、[すべてのユーザー] ではなく [このユーザーのみ] でインストールされたときに起こる現象です。

runas コマンドは、プリンタやネットワーク接続に対して汎用名前付け規則 (UNC) パスが使用されている場合には機能しません。この問題の回避策としては、runas コマンドを使用して Internet Explorer を開始し、Internet Explorer でフォルダ ベースのオブジェクトを開くという方法もありますが、このアプローチは、"右クリックして [別のユーザーとして実行] をクリックするだけ" という手軽さに欠けます。

その他にも、runas コマンドを使用して、ユーザーの [送る] メニューに、選択したプログラムを管理者権限で実行するスクリプトのショートカットを作成することができます。また、ショートカットに、[別の資格情報で実行する] オプションを設定することもできます。詳細については、「プログラムを [別のユーザーとして実行] する方法」http://support.microsoft.com/kb/294676/ja を参照してください。

MakeMeAdmin

MakeMeAdmin は、2 つのログオン プロセスを連続して実行することによって、Secondary Logon サービスのドライブ マッピング、アクセス権、およびプログラムのインストールに関わる制限を回避します。これらの制限事項を回避するために、MakeMeAdmin スクリプトは次のことを行います。

  1. ユーザーの現在のログオン アカウント情報を取得します。

  2. Secondary Logon サービスを起動し、ローカル Administrator アカウント情報でログオンできるようにします。

  3. 新しいローカル Administrator ログオン セッションを使用して、ユーザーの現在のアカウントをローカル Administrator グループに追加します。

  4. Secondary Logon サービスを再起動し、現在のユーザー アカウントで、ただし、ローカル Administrators グループのメンバとしてログオンするように要求します。

  5. 現在のユーザー アカウントがローカル Administrators グループのメンバである新しいコマンド プロンプトを作成します。このコマンド プロンプトには、標準のコマンド プロンプトとは異なる背景色とタイトルが付きます。

  6. 現在のアカウントをローカル Administrators グループから削除します。

MakeMeAdmin スクリプトが作成したコマンド プロンプトは、現在のログオン アカウント資格情報で、ただし、ここでは管理者権限を持った状態で実行されるので、このコマンド プロンプトから実行されるプログラムも管理者権限を持つことになります。これで、ドライブ マッピングもネットワーク アクセス権も現在のアカウントと同じになり、このコマンド プロンプトからプログラムをインストールした場合でも、プログラムはローカル Administrator プロファイルではなく、現在のプロファイルにインストールされます。

MakeMeAdmin の詳細については、Aaron Margosis' WebLog の「MakeMeAdmin -- temporary admin for your Limited User account」http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx (英語情報) を参照してください。

PrivBar

PrivBar は、Internet Explorer および Windows エクスプローラに、ユーザーの現在の特権レベルを示す色付きツールバーを表示します。たとえば、ユーザーが管理者権限でログオンした場合、PrivBar ツールバーは黄色に変わり、赤いインジケータが表示されます。このインジケータは、ユーザーが管理者特権を使用して Web サイトを閲覧しており、ウイルス感染の危険性があることを知らせます。PrivBar の詳細については、Aaron Margosis' WebLog の「PrivBar -- An IE/Explorer toolbar to show current privilege level」http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/195350.aspx (英語情報) を参照してください。

PolicyMaker

Desktop Standard の PolicyMaker は、LUA アプローチを分散ネットワーク環境に実装するためのグループ ポリシーの拡張機能を提供するユーティリティ スイートです。PolicyMaker スイートには、プログラムの互換性をチェックし修正するツールも含まれています。LUA アプローチの実装に役立つツールは、PolicyMaker Standard Edition、PolicyMaker Application Security、および PolicyMaker Software Update です。

特に、LUA アプローチに効果的なユーティリティは PolicyMaker Application Security です。このユーティリティを使用すると、ネットワーク管理者は、個々のプログラムにアクセス許可レベルを付与できます。ネットワーク管理者は、プログラムを選択し、そのプログラムの起動時に、プロセス トークンからセキュリティ グループを削除します。この制限は、グループ ポリシー経由で伝達されます。

Application Compatibility Toolkit

Microsoft Windows Application Compatibility Toolkit (ACT) は、アプリケーションと Windows オペレーティング システム間の高い互換性を提供する、IT の専門家および開発者を支援するためのツールとドキュメントのコレクションです。次のツールが含まれています。

  • Application Analyzer: アプリケーション インベトリと互換性テストを簡単に行うツールです。

  • Compatibility Administrator: Windows 上の古いプログラムのサポートに必要な互換性修正プログラムのデータベースを提供します。

  • Internet Explorer Compatibility Evaluator: Internet Explorer とアプリケーション間の互換性の問題を記録する Internet Explorer に関する詳細なログを提供するツールです。

Compatibility Administrator には、開発者がカスタム アプリケーションの開発中にユーザーのアクセス許可問題をチェックできるツールが含まれています。ACT によって生成される互換性修正プログラムを、管理者はユーザーのコンピュータに配布することができます。互換性修正プログラムは、制限付きユーザーが読み取りおよび書き込みアクセス権を持つ場所にアプリケーション呼び出しをリダイレクトすることにより、プログラムの LUA モードでの実行を可能にします。ACT の詳細については、「Windows アプリケーションの互換性」www.microsoft.com/japan/technet/prodtechnol/windows/appcompatibility/default.mspx を参照してください。

RegMon と FileMon

RegMon と FileMon は、高く評価されている Sysinternals Web サイトからダウンロードできるユーティリティです。RegMon は、レジストリへのアクセスをリアルタイムで表示し、アプリケーションからのレジストリの呼び出しをすべて記録します。このツールにより、アプリケーションがレジストリ キーにアクセスできないタイミングを知ることができます。同様に、FileMon は、ファイル システム アクティビティをリアルタイムに表示し、アプリケーションからのシステム コールをすべて記録します。

管理者は、RegMon と FileMon を使用して、LUA 環境内でアプリケーションをテストし、アプリケーションからレジストリまたはファイル システムへの呼び出しエラーを検出できます。そして、たとえば、ファイル システムまたはレジストリ キーへのアクセス許可を変更するなどして、そのエラーを回避することができます。グループ ポリシーにより、これらのアクセス許可の変更を複数のコンピュータに伝達できます。これらのユーティリティの詳細については、Sysinternals Web サイト www.sysinternals.com (英語情報) を参照してください。

Systems Management Server

Microsoft Systems Management Server (SMS) 2003 は、中規模および大規模組織の集中管理ネットワークおよび分散ネットワークの両方に対する管理サービスを提供するフル装備のデスクトップ管理システムです。この管理サービスには、ソフトウェアとセキュリティ更新プログラムのインストールが含まれます。

SMS では、ユーザーは管理者権限でログオンすることなく、ソフトウェアおよびセキュリティ更新プログラムをインストールできます。SMS の詳細については、「Systems Management Server 2003 サービスパック1」を参照してください。

管理者資格情報の制限

組織が完全な LUA アプローチを実装できない場合には、ネットワーク リソースにアクセスするすべてのプログラムが常に制限付きユーザー権限で実行されるようにすることにより、管理者権限でプログラムが実行されることに起因するリスクを軽減することができます。この方法は、最小特権の原則には準拠しませんが、すべてのユーザーがすべてのプログラムを管理者権限で実行することを許可するよりも良い方法です。

ユーザーが管理者権限でログオンしたときに有効なセキュリティを確保するためには、次のことを行う必要があります。

  • 管理者としてプログラムを実行するリスクを最小限に抑えるツールを配布する。

  • 電子メール、ブラウザ、インスタンス メッセージ クライアントなど、インターネットを直接利用するプログラムは、必ず制限付きユーザー権限で実行されるようにする。このようなプログラムを管理者権限で実行することは、悪意のあるプログラムを組織に招き入れているようなものです。

  • 許可されていない管理者権限でのコンピュータの使用を監視する。セキュリティの監視の詳細については、「セキュリティの監視および攻撃検出計画ガイド」www.microsoft.com/japan/technet/security/topics/auditingandmonitoring/securitymonitoring/default.mspx を参照してください。

次のツールを使用することにより、ユーザーが管理者権限でログオンする際のコンピュータのセキュリティが侵害されるリスクを最小限に抑えることができます。また、既に紹介した、制限付きユーザーとしてログオンする場合のいくつかのツールも、この状況での使用に適しています。

  • Secondary Logon サービス

  • ソフトウェア制限ポリシー

  • DropMyRights

: DropMyRights は Microsoft によってサポートされていません。このプログラムの適合性について、Microsoft では一切保証していません。このプログラムは、ユーザー自身の責任でご使用ください。

Secondary Logon サービス

Secondary Logon サービスは、より少ない権限のアカウントとしてプログラムを実行するオプションを提供します。たとえば、Windows XP SP2 では、Internet Explorer のユーザーのデスクトップ アイコンを、[別のユーザーとして実行] ダイアログ ボックスを起動するバージョンに置き換えることができます。このダイアログ ボックスには [許可されていないプログラムの動作からコンピュータとデータを保護する] オプションがあります。このオプションを選択すると、後に説明する DropMyRights ツールと同様の方法で、ユーザーのアクセス トークン内のセキュリティ識別子 (SID) が無効になります。

ソフトウェア制限ポリシー

ソフトウェア制限ポリシーは、グループ ポリシーに含まれるポリシーで、不明な、または信頼されないソフトウェアを取り締まります。ソフトウェア制限ポリシーでは、プログラムに次の 3 つの設定のうちの 1 つを適用できます。

  • [制限しない]

  • [許可しない]

  • [基本ユーザー]

: 既定で表示されるのは [制限しない] と [許可しない] だけです。[基本ユーザー] 設定を表示するには、レジストリ キーを編集する必要があります。詳細については、「Browsing the Web and Reading E-mail Safely as an Administrator, Part 2」(英語) を参照してください。

要約すると、[制限しない] プログラムは何の制限もなく実行でき、[許可しない] プログラムは実行できません。そして、[基本ユーザー] 設定が適用されたプログラムは、制限付きユーザー権限でのみ実行できます。このアプローチにより、たとえば、Internet Explorer は必ず制限付きユーザーとして実行するというソフトウェア制限ポリシーを構成できます。

また、ソフトウェア制限ポリシーでは、Internet Explorer の一時ファイル フォルダなどの特定の場所からの悪意のあるソフトウェアの実行を防ぐこともできます。ソフトウェア制限パス規則により、一時インターネット ファイル フォルダから実行しようとするすべてのプログラムを許可しないことができます。グループ ポリシーにより、ドメイン内のすべてのコンピュータにこの規則を適用できます。

ソフトウェア制限ポリシーの詳細については、「Using Software Restriction Policies to Protect Against Unauthorized Software」(英語情報) を参照してください。

DropMyRights

DropMyRights は、ユーザーのアカウント トークンから SID を無効にし、特権を削除し、この制限付きトークンを使用して、指定されたプログラムを開始します。DropMyRights により、ユーザーは管理者権限でログオンし、プログラムを次の 3 つの特権レベルのうちのいずれかで実行できます。

  • 通常

  • 制約付き

  • 信頼できない

: "通常" 特権レベルは、制限付きユーザー アカウントに相当します。 "制約付き" レベルは、アクセス トークンの SID を制限するため、制限がより厳しいレベルです。 "信頼できない" レベルは、最低限のアクセス権しか持たず、ほとんどのアプリケーションがこのレベルでは動作しません。

たとえば、管理者特権を持つユーザーが Web サイトを閲覧するとします。このユーザーに、DropMyRights を起動するショートカットから Internet Explorer を実行させることができます。このショートカットにより、プログラムは "制約付き" ユーザーとして実行されます。この Internet Explorer のインスタンスは、クライアント コンピュータ上で最小限の権限しか持たないことになり、悪意のあるソフトウェアがインストールされたり実行されたりする可能性が大幅に低下します。

DropMyRights の詳細については、「Browsing the Web and Reading E-mail Safely as an Administrator」(英語) を参照してください。

Internet Explorer を "制約付き" ユーザーとして実行する効果については、「Running restricted -- What does the "protect my computer" option mean?」http://blogs.msdn.com/aaron_margosis/archive/2004/09/10/227727.aspx (英語情報) を参照してください。

将来的な展望

Windows Vista では、ユーザー アカウントの保護機能が強化されています。Windows Vista では、ユーザーは効果的に制限付きユーザー アカウントを使用できるようになっており、Windows Vista 認証プログラムであれば、制限付きユーザー アカウントで問題なく実行されます。古いプログラムが HKEY_LOCAL_MACHINE セクションなど、レジストリ内の保護領域に書き込もうとした場合は、この書き込みは HKEY_CURRENT_USER セクションにリダイレクトされます。ただし、ベンダが Windows Vista に対応するようにプログラムを更新すれば、LUA アプローチは広く実装されるようになるはずです。

Windows Vista では、使いやすさも向上しています。ユーザーが管理者権限を必要とする変更を実行しようとすると、自動的に、管理者資格情報を入力するよう要求されます。

ユーザー アカウントの保護機能の強化は、Windows Vista で強化されたセキュリティ機能のうちの 1 つです。組織で使用されているオペレーティング システムを Windows Vista にアップグレードすれば、悪意のあるソフトウェアが管理者レベル アカウントを利用する可能性を大幅に低下させることが可能です。Windows Vista のユーザー アカウントの保護機能の詳細については、Windows Vista の Web サイト www.microsoft.com/japan/technet/windowsvista/default.mspx を参照してください。

要約

日々増大するネットワーク コンピュータへの脅威により、あらゆる規模の組織で、多層防御戦略の実装が必要不可欠になっています。この戦略の重要なポイントは、Windows XP を実行するコンピュータへの LUA アプローチの実装です。

LUA アプローチは、多くの組織で行われている、ローカル Administrators グループのメンバシップを介したクライアント コンピュータ ユーザーへの管理者権限の付与という慣習に対抗するものです。このホワイト ペーパーでは、すべてのユーザーに管理者権限を付与することに伴う危険性に焦点を当てています。ユーザーが管理者権限を持つということは、そのユーザーが実行するプログラムがすべて管理者特権を持つということになります。特に、ブラウザ、電子メール プログラム、インスタント メッセージング クライアントなど、インターネットを直接利用するプログラムが管理者権限で実行されなければ、クライアント コンピュータの脆弱性を大きく改善することになるため、これは、非常に重要なポイントになります。

このホワイト ペーパーの最初に挙げた例を見てみると、もし組織が LUA アプローチを実装していれば、役員は制限付きユーザーとしてセキュリティが侵害された Web サイトを閲覧していたはずです。そうすれば、悪意あるソフトウェアは彼のポータブル コンピュータに感染することもなく、結果、彼はすばらしいプレゼンテーションを披露し、大量の注文を受けることができたはずです。

最後に、LUA アプローチはそれ自身ではソリューションになりません。他のセキュリティ防御策と組み合わせて実装することが必要です。LUA アプローチは、ユーザーの意識向上、境界ファイアウォール、ホスト ファイアウォール、定期的なセキュリティ更新プログラム、最新のウイルス対策ソフトなどとともに実装する必要があります。

関連情報

Windows XP への LUA アプローチの適用の詳細については、次の関連情報も参照してください。

謝辞

Microsoft Solutions for Security and Compliance グループ (MSSC) は、「Windows XP でユーザー アカウントに最小特権の原則を適用する」の作成チームに感謝の意を表します。 このソリューションの作成、開発、テストに直接または間接的に関与したメンバは次のとおりです。

作成者

Anthony Steven, Content Master Ltd

ライター

Mike Danseglio

テスター

Gaurav Singh Bora, Infosys Technologies

Mehul Mediwala, Infosys Technologies

編集者

Jennifer Kerns, Wadeware

John Cobb, Volt Information Sciences

プログラム マネージャ

Tom Cloward

リリース マネージャ

Flicka Crandell

貢献者

Tony Bailey

Darren Canavor

Karl Grunwald

Kelly Hengesteg

Karina Larson, Volt Information Sciences

Chrissy Lewis, Siemens Business Services, Inc.

David Mowers

Jeff Newfeld

Bomani Siwatu

Stacy Tsurusaki, Volt Information Sciences

David Visintainer, Volt Information Sciences

レビュー担当者

Bob Blank, Target Corporation

Jeremy Brayton、独立したレビュー担当者

Derick Campbell

Chase Carpenter

Romulo A. Ceccon, Dataprom

Matt Clapham

Chris Corio

Greg Cottingham

John Czernuszka

Michael Dragone, Titleserv, Inc

Dana Epp、独立したレビュー担当者

Stephen Friedl, Microsoft Security MVP

Guido Grillenmeier, Hewlett-Packard

Michael Harradon, Netivity Solutions

Robert Hurlbut, Hurlbut Consulting, Inc

Mark Kradel

Jamie Laflen

Alex Lee, Sprint Nextel Corporation

Kevin Lundy, CAE, Inc

Tim C. MalcomVetter, Truman Medical Centers

Aaron Margosis

Brian Marranzini

David McClure, Siemens Medical Solutions

Don McGowan

Michael Miller, Media General, Inc

Charles J. Palmer、独立したレビュー担当者

Keith Pawson、独立したレビュー担当者

Brian A. Reiter, WolfeReiter, LLC

Michael Rickard, Bristol University

John Robbins, Wintellect

Alex Rublowsky

Mike Smith-Lonergan

Mike Sorsen, Edward Jones

Didier Stevens, Contraste Europe

Eric Wood

Martin Zugec、独立したレビュー担当者

ダウンロード

Windows XP でユーザー アカウントに最小特権の原則を適用するホワイト ペーパー

更新通知

更新および新しいリリースの通知サービスに申し込む (英語のみ)

ご意見、ご感想

ご意見、ご要望をお寄せください (英語のみ)


© 2009 Microsoft Corporation. All rights reserved. 使用条件 | 商標 | プライバシー
Page view tracker