管理者特権なしで Visual Studio .NET を使ってソフトウェアを開発する
Lars Bergstrom
Visual Studio Core Team
Microsoft Corporation
July 2002
日本語版最終更新日 2003 年 5 月 6 日
要約 : ローカルの Administrators グループのメンバはコンピュータ上ですべての操作を実行することができる権限を持っています。これでは、このような環境で操作を行うユーザー、および開発されるソフトウェアの安全性が低下します。この記事では、管理者特権を持たないユーザーとしてログオンし、ソフトウェアを効率よく開発する方法について説明します。
適用製品 :
- Microsoft® Windows® XP と Microsoft Windows Server 2003 ファミリ
- NTFS ファイル システムのディスク ドライブ
- Microsoft Visual Studio® .NET
目次
はじめに ログイン アカウントのグループ メンバシップと許可 管理タスクを実行する ソフトウェアを開発する まとめ
はじめに
セキュリティは大変重要な問題です。この事はだれもが認識しており、セキュリティに関する問題、セキュリティ バグ、悪意を持ったユーザーへの対策に多大な時間が費やされています。しかし、とても危険で最も重要な問題である電子メール ウィルスやクラックなどの一般的な問題を根絶するために努力している人はあまりいません。だれもがローカルの Administrators グループのメンバとしてログインし、ほとんどのサービスを管理者として実行しています。"最小限の権限" の本質とは、必要な最小限の権限で操作を実行することによって Outlook から受信した電子メールに添付されている壊れたファイル、またはセキュリティの危険性があるサービスなどの不都合が生じたときに被害を最小限に留めることです。可能な限り管理者特権を持たずにプログラムを実行することによって、私たちはより安全な環境を確保できるのです。
現在普及しているソフトウェアの多くは、適切な実行を実現するために高レベルの権限を要求します。このような状況に終わりを告げるべく、開発者は率先して管理者としての実行を中止するべきです。私たちすべてが常に管理者以外のユーザーとしてログインしてアプリケーションの開発とテストを実行すれば、私たちが作るソフトウェアは高レベルの権限を必要とせずに実行可能なものとなりえるでしょう。また、開発者が作成および配布しているソフトウェアを修正しない限り、ユーザーは安全な環境でソフトウェアを実行することはできません。
ログイン アカウントのグループ メンバシップと許可
グローバル登録、新しいソフトウェア アプリケーションのインストール、デバイスの再設定などのタスクには管理者の特権が必要です。管理者が絶え間なくコンピュータを管理しない限り、このようなタスクを実行するためには管理タスクを行うことができるアカウントがユーザーに必要になってきます。
ここからは、このユーザー アカウントとして "Administrator" という名前のユーザー アカウントを使用します。このアカウントはドメイン アカウントとは異なりローカル コンピュータに存在するものと仮定します。ユーザーがローカル コンピュータの Administrators グループのメンバである場合は、ユーザー名を "root" とすることもできます。また、ここでは Windows ドメインで作業し、プライマリ ログインはそのドメインのアカウントで "DOMAIN\username" の形式を使うものとします。しかし、これは必要な条件ではなく、いずれのアカウントもローカル コンピュータ上に設定することが可能です。
アカウント ステータスの変更
管理者アカウントへのアクセスを持っていることを確認してから、ユーザー マネージャで Administrators グループから自分のユーザー アカウントを削除し、Users グループおよび下位レベルの権限を持つ他の適切なグループに追加します。自分のユーザー アカウントを Users グループに追加するには、まず Microsoft 管理コンソール (MMC) および "ユーザー管理" スナップインを読み込む必要があります。
注 : ほとんどのネットワーク設定では、ドメインの Domain Users グループはあらかじめローカル Users グループのメンバになっていますので、ドメイン アカウントは既にローカル Users グループに含まれています。
Microsoft 管理コンソールを使用する
- [マイ コンピュータ] を右クリックし、[管理] をクリックします。
または
- [スタート] メニューで [ファイル名を指定して実行] をクリックし、「lusrmgr.msc」と入力します。
Users グループに自分のアカウントを追加する準備ができました。
低レベルの権限のグループにアカウントを追加する
- 今後主に使用するログイン アカウントが Power Users グループに含まれていないことを確認します。
Power Users グループは既定で HKLM\Software および Program Files ディレクトリ内のすべてに対する書き込み権を持つので、実質的には Administrators グループと同じです。
- [ローカル ユーザーとグループ] ノードにある [グループ] フォルダを選択します。
- [Power Users] グループをダブルクリックします。
- 自分のアカウントまたはアカウントが属するグループが [所属するメンバ] リスト ボックスに表示されている場合は、それを選択します。
- [削除] をクリックします。
- 削除したアカウントを [Users] グループに追加します。
- [Debugger Users] グループにも追加します。
- 自分のアカウントを [Administrators] グループから削除します。
- 次の表を参考にしながら、他のグループにも適切にアカウントを追加します。
| 目的 |
アカウントを追加するグループ |
| ターミナル サービスを使用してコンピュータにリモートで接続する |
Remote Desktop Users グループ |
| Windows Server 2003 を使用して、ローカル Web アプリケーションの開発およびデバックを行う |
IIS_WPG グループ |
注 : Windows XP Professional を使用してローカル Web アプリケーションの開発およびデバッグを行っている場合は、次の手順に従って、"バッチ ジョブとしてログオン" 特権をアカウントに追加してください。
バッチ ジョブとしてログオン
- [スタート] メニューで [ファイル名を指定して実行] をクリックし、「gpedit.msc」と入力します。
[グループ ポリシー] が表示されます。
- [コンピュータの構成]、[Windows の設定]、[セキュリティの設定]、[ローカル ポリシー] の順にノードを展開し、[ユーザー権利の割り当て] を選択します。
- [バッチ ジョブとしてログオン] に DOMAIN\username という形式で制限されているアカウントを追加します。
- 変更を反映させるにはログオフして再度ログオンします。
ファイルと共有リソースへのアクセスの確保
ローカルの Administrators グループのメンバとしてログオンしたときに、自分個人のディレクトリなどを作成することがあります。また、自分のユーザー アカウントからアクセス可能なネットワーク共有を作成したつもりでも、実はローカルの Administrators グループのみがアクセス可能なように作成してしまう場合もあります。ローカル ドライブの自分のプロファイル ディレクトリ以外の場所に作成したディレクトリについては、自分のユーザー アカウントによって所有されており、さらにアクセス可能であることを確認することをお勧めします。
プライベート ファイルやディレクトリの所有権を確認するには
- ファイルまたはフォルダを右クリックし、[プロパティ] をクリックします。
- [セキュリティ] タブで [詳細] をクリックします。
- [所有者] タブの一覧に自分のユーザー アカウントがあることを確認します。ない場合は所有権を取得します。
ファイル共有へのアクセスを確認するには
- [マイ コンピュータ] を右クリックし、[管理] をクリックします。
- [共有フォルダ] ノードを展開し、[共有] ノードを選択します。
- ユーザーが作成した各共有へのアクセスを確認するには、目的の共有を右クリックして [プロパティ] を選択します。
- [共有のアクセス許可] タブは共有へのアクセス許可、[セキュリティ] タブはそのファイル システム許可です。その共有ですべての操作を実行できるようにするには、両方の一覧で当該ユーザー アカウントにアクセス許可が認められている必要があります。
アクセス許可がない場合は、両方の一覧に自分のユーザー アカウントを追加します。
管理タスクを実行する
アカウントを変更してからログインすると、使用できないオプションがたくさんあることにお気付きになることでしょう。たとえば、タスク バーにある時計をダブルクリックしてもカレンダーは表示されません。これは、カレンダーの日付は上位レベルの権限を持ったユーザーしか変更できないためです。
アプリケーションを別のユーザーとして実行する
Windows XP には、ログインし直さなくても別のユーザーとしてアプリケーションを簡単に実行できる機能が備わっています。ただし、これらのアプリケーションはプライマリ ログオン セッションを終了するときに終了します。この操作を行うには 3 つの方法があります。
異なる資格情報でショートカットを実行する
- ショートカットを右クリックします。
[プロパティ] メニューが表示されます。
- [アカウントを指定して実行] を選択します。
これで、別のユーザー名とパスワードを使用してアプリケーションを実行できます。
いつも別のユーザー アカウントでアプリケーションを実行する場合は、そのように Windows を設定して、自動的に別のユーザー名を入力するボックスを表示させることもできます。
異なる資格情報でアプリケーション コマンド ラインを実行する
- [スタート] メニューで [ファイル名を指定して実行] をクリックし、「runas /user:Administrator program.exe」と入力します。
または
- コマンド シェル ウィンドウで「runas /user:Administrator program.exe」と入力します。
runas.exe ではパスワードを入力するように促すメッセージが表示され、新しいログイン セッションに渡したコマンド ラインが実行されます。これは、regedit や iexplore、または新しいコマンド ウィンドウを開くといった簡単なプログラムの実行には便利で、これらのプログラムの子プロセスもそのユーザーとして実行されます。これは新しいログインであるため、残念ながらハンドル、環境関数、または作業中のディレクトリを継承しません。他のユーザーのパスにないプログラムを実行する場合は、その完全なパスが必要になります。
別のユーザー名を要求するプロンプトを自動的に表示させる
- Windows XP 以降のバージョンでは、ショートカットをアクティブにするたびに別のユーザー名およびパスワードを要求するプロンプトを表示するように、ショートカットのプロパティを変更できます。
- ショートカットを右クリックして [プロパティ] をクリックします。
- [ショートカット] タブで [詳細] をクリックします。
- [別の資格情報で実行する] チェック ボックスをオンにします。
別の資格情報で特定の管理ツールを実行する
当然次に考えられる質問は、コントロール パネルから実行されるツールはどのように実行するかということです。[マイ コンピュータ] を右クリックして [管理] をクリックするのでしょうか。それとも、ショートカットやコマンド ラインに値するオプションがない UI オプションをいちいち調べるのでしょうか。便利なことに、すべての管理ツールにはコントロール パネル アプレットを実行して、または Microsoft 管理コンソールから直接アクセスすることができます。一般的な管理ツール (コントロール パネル アプレットと Microsoft 管理コンソール ファイル) とその起動方法 (コマンド プロンプトから、または直接 control.exe または mmc.exe アプリケーションを RunAs コマンドで起動して) の一覧を次に示します。これらはすべて Windows の System32 フォルダに格納されていますが、Windows Server 2003 ファミリまたは Windows XP でのみ利用できます。これらのエントリを以下の表に挙げます。
| 管理アクション |
コントロール パネル アプレット |
| ユーザー補助 |
access.cpl |
| 802.11 モニタ |
apgui.cpl |
| プログラムの追加と削除 |
appwiz.cpl |
| コンソール |
console.cpl 1 |
| ディスプレイ |
DESK.cpl |
| SCSI、PCMCIA、テープ デバイス |
DEVAPPS.cpl 1 |
| 新しいハードウェアの追加ウィザード |
hdwwiz.cpl |
| インターネット |
inetcpl.cpl |
| 地域の設定 |
INTL.cpl |
| ゲーム コントローラ |
joy.cpl |
| マウス、フォント、キーボード、プリンタ |
main.cpl |
| マルチメディアとサウンド |
MMSYS.cpl |
| モデム |
MODEM.cpl 1 |
| ネットワーク |
ncpa.cpl |
| XP へのログオン管理 |
nusrmgr.cpl (XP) |
| ODBC |
odbccp32.cpl |
| 電源オプション |
powercfg.cpl |
| ポート |
PORTS.cpl 1 |
| デバイス、サービス、サーバー |
srvmgr.cpl 1 |
| システム |
SYSDM.cpl |
| テレフォニー |
telephon.cpl |
| 日付/時刻 |
TIMEDATE.cpl |
| UPS |
ups.cpl 1 |
1Windows Server 2003 ファミリのオペレーティング システムを使用した場合
| 管理アクション |
Microsoft 管理コンソール ファイル |
| 現在のユーザー認証情報 |
certmgr.msc |
| 証明機関 |
certsrv.msc 1 |
| 証明書テンプレート |
certtmpl.msc 1 |
| サービス インデックス |
ciadv.msc |
| コンピュータ管理 |
compmgmt.msc |
| グループ ポリシー オブジェクト エディタ |
dcpol.msc 1 |
| デバイス マネージャ |
devmgmt.msc |
| ディスク デフラグ |
dfrg.msc |
| 分散ファイル システム |
dfsgui.msc 1 |
| ディスク管理 |
diskmgmt.msc |
| Active Directory ドメインと信頼関係 |
domain.msc 1 |
| 既定ドメイン セキュリティ設定 |
dompol.msc 1 |
| Active Directory ユーザーとコンピュータ |
dsa.msc 1 |
| Active Directory サイトとサービス |
dssite.msc 1 |
| イベント ビューア |
eventvwr.msc |
| ファイル サーバー |
filesvr.msc 1 |
| 共有フォルダ |
fsmgmt.msc |
| グループ ポリシー オブジェクト エディタ |
gpedit.msc |
| インターネット認証サービス |
ias.msc 1 |
| ローカル ユーザーとグループ |
lusrmgr.msc |
| リムーバブル記憶域 |
ntmsmgr.msc |
| リムーバブル記憶域の操作要求 |
ntmsoprq.msc |
| パフォーマンス |
perfmon.msc |
| ルーティングとリモート アクセス |
rrasmgmt.msc 1 |
| ポリシーの結果セット |
rsop.msc |
| ローカル セキュリティの設定 |
secpol.msc |
| サービス |
services.msc |
| テレフォニー |
tapimgmt.msc 1 |
| ターミナル サービスの構成と接続 |
tscc.msc 1 |
| リモート デスクトップ |
tsmmc.msc 1 |
| Windows 管理インフラストラクチャ |
wmimgmt.msc |
1 Windows Server 2003 ファミリのオペレーティング システムを使用した場合
ネットワークの証明情報
ウィンドウまたはログオン セッションを管理者として開いているとき、既定のネットワーク証明情報は通常のログオン時に使用されるドメイン アカウントのものとは異なります。ほとんどのネットワークではファイル共有などの重要なリソースはドメイン アカウントのみに公開されるので、他のネットワーク証明情報を確立する必要があります。
これには 2 つの方法があります。新しいコマンド ウィンドウを開いて、ネットワーク上で使用する既定の証明情報を設定します。もう 1 つは各サーバーまたは共有に別のユーザー名とパスワードでアクセスできるようにする方法です。
コマンド プロンプトを実行しているとき、管理者特権を持ったウィンドウであることを明確に示すよう環境を変更すると便利です。一般的には次のいずれかの方法を使用します。
- コマンドを入力するプロンプトをユニークなものにする。例 :
PROMPT ADMIN $P$G
- 次のコマンドを使用して明るい赤の背景に黒のテキストなど別の色に変える :
COLOR c0
- 次のようなコマンドを使用してタイトル バーのテキストをユニークなものにする :
title Admin Window
別のネットワーク証明情報を使って新しいコマンド ウィンドウを開く
- ウィンドウを開くには、「runas /user:administrator "runas /netonly /user:DOMAIN\username cmd.exe"」と入力します。
- 最初に表示されるコマンド ウィンドウには、管理者のパスワードを入力します。
- 次に表示されるコマンド ウィンドウには、ネットワークを介してリソースにアクセスする際に使用される証明情報のユーザーのパスワードを入力します。
新しいコマンド ウィンドウを開いて各サーバー共有にアクセスする
- 新しいコマンド ウィンドウは、runas /user:administrator cmd.exe コマンドを使用して開きます。
- 別の証明情報セットを必要とするそれぞれのネットワーク サーバーには、そのシェル ウィンドウで net use /user:DOMAIN\username \\server コマンドを使用します。
他の形式の net use コマンドでは、ネットワーク ドライブを永続的な文字に割り当てたり、このコンピュータから送信されるアクセス要求を認証するためのドメイン証明情報を提供することができます。net use コマンドのいくつかを次に示します。これらのコマンドを完了すると、アプリケーションは通常のようにリモート共有からインストールされます。
| net use コマンド |
動作 |
| net use |
接続リストを表示する。 |
| net use * /persistent:no /user:DOMAIN\username \\server\share |
ローカル ドライブ文字にマップされている接続を別の証明情報で開く。ただし、次のログオン時にはドライブに再接続されない。 |
| net use /user:DOMAIN\username \\server\share |
別のユーザー資格情報を使ってネットワーク共有に接続する。 |
ソフトウェアをインストールする
管理者の特権なしでソフトウェアをインストールするのは至難の業となりえます。たとえば、インストール ディスクをコンピュータに挿入すると、現在ログインしているユーザーとしてセットアップ プログラムが起動するので、そのユーザーにアプリケーションをインストールする権限がない場合は困ります。このような問題を回避するには、次の操作を実行してください。
ActiveX コントロール
多くの Web サイト、特に企業のイントラネットでは、ActiveX® コントロールのインストールに管理アクセスを必要とし、制限されているユーザーによるインストールをサポートしないものがよくあります。簡単に Administrator として Internet Explorer を起動する方法を次に示します。
- IE のアイコンを右クリックします。
アイコンはクイック起動バー、デスクトップ、または [スタート] メニューにあります。
- プロパティ リストから [別のユーザーとして実行] を選択し、Administrator として実行します。
Windows インストーラ パッケージ
Windows インストーラ パッケージ (.MSI ファイル) では、アプリケーションのインストールまたはアンインストールには MSIEXEC.exe アプリケーションが便利です。
- インストールするには msiexec /I msifile.msi を実行します。
注 : これは、.MSI をダブルクリックしたときに Windows によって行われる処理と同じです。
- アンインストールするには msiexec /x msifile.msi を実行します。
注 : msiexec.exe プログラムへの引数は 「Command Line Options」 (ms-help://MS.VSCC/MS.MSDNVS.1041/msi/app_73eb.htm) にあります。
管理者特権が必要なプログラムを実行する
残念なことに、Windows ロゴ認定の要件を満たさないプログラムは多数存在します。また、Windows ロゴに準拠しているはずのプログラムの中でも、実際はあまり準拠していないものが多く存在します。Windows ロゴ プログラムには、可能な限り、アプリケーションは低いレベルの権限を持つアカウントでも十分機能する必要があるという概念があります。プログラムはユーザー アカウントに、プログラム ファイル インストール ディレクトリ、また HKLM\Software のキーに対する書き込みアクセスを要求することがあります。ディレクトリ、ファイル、またはレジストリ キーへのアクセスにどのアクセス権が必要であるかを簡単に調べることができる場合は、プログラムを実行できるようにそれらを編集することができます。編集の手順を次に示します。
レジストリ許可の編集
- regedit を Administrator のアカウントで起動して「runas /user:Administrator regedit」と入力します。
- 編集するレジストリ キーを右クリックします。
- [許可] をクリックします。
- フル コントロールを許可されているユーザーのセットに適切なユーザーを追加するか、そのキーに対するアクセス権のカスタム セットをそのユーザーに与えます。
ファイル システム許可の編集
ファイルまたはディレクトリには、コマンド ラインから cacls.exe プログラムを使用して許可をリセットするのが便利です。cacls.exe の使用に関するヘルプは次の方法によって得ることができます。
- コマンドラインで /? フラグを渡す
- Windows ヘルプ
例 : cacls.exe プログラムを実行して、ディレクトリにユーザーのアクセス許可を追加する
フラグを使って cacls.exe を実行し、繰り返し書き込み権を追加する
runas /user:Administrator "cacls.exe directory /t /e /g domain\username:w"
- Windows Server 2003 では、directory パラメータの後ろに / (スラッシュ) を使用できます。
- Windows XP Professional では、cacls.exe プログラムがオペレーティング システム間で異なるため、最後の " (引用符) を削除する必要がある場合があります。runas.exe コマンドの出力を確認して、余分な引用符が含まれている場合 (以下を参照) は上のコマンド ラインから閉じる引用符を削除してください。
Attempting to start cacls.exe c:\foo\ /t /e /g domain\username:w" as user "MACHINE\Administrator" ...
最後に、ローカル Administrator ユーザーとしてプログラムを実行するには runas.exe を使用できます。しかし、これには注意が必要です。プログラムが下位レベルの権限しかない環境にうまく対応できない場合、上位レベルの権限での環境におけるプログラムの動作をどの程度信頼すべきなのでしょうか。残念なことに多くのプログラムでは、そのプログラムをインストールしたユーザー以外のアカウントでの動作はテストされていません。下位レベルの権限しかないアカウントでのテスト率は特に低下します。結局、作業を行うにはローカルの Administrator としてプログラムを実行する必要があるかもしれません。これは、すべてのソフトウェアを実行してローカル Administrators のメンバとしてログインするよりはましな環境です。しかし、次回のリリースまでにはこの問題を解決してもらうように、ぜひソフトウェア開発元にこのバグについて連絡してください。エンド ユーザーが安全なログイン環境でソフトウェアを実行でき、かつ生産性を低下させない唯一の方法は、すべてのソフトウェアを開発者が修正することです。
ソフトウェアを開発する
Visual Studio .NET は Windows ロゴと互換性があるので、Visual Studio .NET は制限されているユーザー アカウントでも実行できるとだれもが期待します。ほとんどの機能は制限された許可を持つアカウントでも動作しますが、オペレーティング システムの制限または実行するタスクの性質などにより、このモデルでは操作するのが難しい機能が少しですがあります。次のセクションでは、開発プロセスにおいて操作が難しいすべてのタスクに対する簡単な解決策を紹介します。今後のバージョンの統合開発環境 (IDE) では、この機能を直接シェルに埋め込み、できる限り要求を減らすことを望みます。私たちは、これらの操作を管理者の特権がなくてもできるよう今後のバージョンのオペレーティング システムおよび開発ツールの開発に励んでいます。
ビルド後の操作 (登録)
従来の Visual C++ では regsvr32.exe です。Visual Basic .NET や Visual C# .NET では、これは相互運用機能のためのアセンブリを登録します。登録を強制するプロジェクト システムにかかわらず、多くのツールでは COM コンポーネントやタイプ ライブラリの登録に HKLM\Software\Classes への書き込みアクセスが必要です。アプリケーションが登録作業の際にレジストリのセキュリティで保護されている部分への書き込みアクセスを必要としている場合、まずこの作業に書き込みアクセスが本当に必要であるかどうかを考慮してください。以下の点に留意してください。
- 特定のユーザーのためである場合も、HKCU\Software\Classes はどのユーザーによっても書き込み可能で、HKLM\Software\Classes と同様に HKCR に表示されます。
注 : HKEY_CLASSES_ROOT の構成については 「HKEY_CLASSES_ROOT Key」 (ms-help://MS.VSCC/MS.MSDNVS.1041/sysinfo/regapi_0htl.htm) を参照してください。
- 従来の COM コンポーネントに対するエンド ユーザー インストールの方法のように regsvr32.exe に依存しないでください。DllRegisterServer メソッドはデバッグやプライベートな開発にのみ使用するべきなので、アプリケーションの登録を前のユーザーにするように変更することは可能です。アプリケーションをエンド ユーザーに配布する際は、Windows インストーラの .MSI ファイル テーブルにすべてのレジストリの条件を記録する必要があります。こうすることによって、同じレジストリ キーを書き込み、さまざまな順序でインストールまたはアンインストールされる複数のプログラムなどの問題を処理することができます。
多くのツールおよびオペレーティング システム API は HKLM\Software\Classes のみに登録できます。タイプ ライブラリの登録はその代表的な例です。これらのケースで最も実現的な方法は、runas /user:administrator cmd.exe を使用して、ディレクトリを出力ディレクトリに変更し、登録操作を手動で実行するか、関連付けをすべて削除することです。グローバル登録における関連付けの削除は複雑なので、詳細が記述されている他の記事を参照してください。他の方法として、登録の手順をすべて避けるためにカスタム マニフェスト ファイルを作成するというのがあります。しかし、これもこの記事では説明しないので詳細については 「Manifest Files Reference」 (ms-help://MS.VSCC/MS.MSDNVS.1041/sbscs/sidebysideref_03ol.htm) を参照してください。グローバル登録が制限されている状況で最も簡単な方法は、管理者特権を持つアカウントで登録操作を行うことです。
次に、ビルド後に行われる一般的な登録タスクおよびその登録を示します。これらのタスクは始めに行うようにしてください。こうすることによって、後で通常のようにビルドおよび実行を行うことができるようになります。ただし、デバッグとリリースの構成を切り替えるとき、および登録されている項目に影響を与えるアプリケーションに変更を入れるときは登録操作をもう一度やり直す必要がある場合があります。
| ビルド後の登録タイプ |
登録操作 |
| COM 実行可能なファイルの登録 |
output.exe /RegServer |
| COM DLL 登録 |
regsvr32 output.dll |
| COM 相互運用性の .NET アセンブリ登録 |
regasm output.dll |
| .NET アセンブリのグローバル アセンブリ キャッシュへのインストール |
gacutil /if output.dll |
| .NET サービス インストールの登録 |
regsvcs output.dll |
一般的なアプリケーションのデバッグ
管理者以外のアカウントでログオンすると使えなくなる機能が 1 つあります。Windows では別のユーザー アカウントで実行しているアプリケーションのデバッグは、そのユーザーがデバッグを許可する権利 (SeDebugPrivilege) を持っていないと行えません。既定では、Administrators グループのメンバのみがこの権利を持っています。Administrator グループのメンバは、開発環境から実行したアプリケーションまたは管理者以外のユーザー アカウントで既に実行されているアプリケーションの場合はデバッグを行うことができます。他のセキュリティ コンテキストで実行されるサービスや他のプログラムをデバッグする必要がある場合は、そのオペレーティング システムの特権を自分に与えるか、RunAs を使用して Visual Studio .NET をローカル Administrator ユーザーとして実行する必要があります。このように、自分のユーザーでアプリケーションを実行して、デバッグを行い、アプリケーションが権限が制限された環境において適切に実行されることを確認する方法は多くあります。
ネイティブ アプリケーションと管理されているアプリケーション
可能なときはいつでも管理者以外のユーザーでアプリケーションを実行してください。すべて正常に機能するはずです。既定では、通常の実行可能ファイルを選択して [デバッグ] メニューの [開始] を使用できます。同じコンピュータ上で自分で起動したアプリケーションへのアタッチ ([デバッグ] メニューの [プロセスにアタッチ]) も使用できます。既定の Visual Studio .NET メカニズムでプロセスにアタッチするには Debugger Users グループのメンバである必要があります。このグループのメンバシップでは他のユーザーのプログラムをデバッグするアクセスは与えられませんが、デバッガをデバッグされているプロセスにアタッチするサービスを使用することができます。
リモート コンピュータ (ネイティブ/管理下)
リモート デバッグを実行するには Machine Debug Manager サービスか msvcmon.exe を使用する 2 つの方法があります。Machine Debug Manager はネットワーク証明情報を認識し、ユーザーを確認し、ターゲット コンピュータの Debugger Users グループのメンバであるかどうかを検証し、メンバである場合はそのユーザーのアプリケーションにユーザーを接続させるサービスです。Machine Debug Manager は、Web アプリケーションなどのリモートで管理されているアプリケーションをデバッグできる唯一の方法です。Debugger Users グループに属していても、リモート コンピュータ上にある他のユーザーのアプリケーションには簡単に接続できません。リモート コンピュータ上で実行されているネイティブ プログラムに接続するには、ターゲット コンピュータ上でも SeDebugPrivilege ユーザー権限が必要になります。リモート コンピュータで管理されているアプリケーションには、アクセス権がオペレーティング システムの特権になくても、Administrators グループのメンバである必要があります。
ネイティブ アプリケーションをデバッグする別の方法として msvcmon.exe プログラムを使用するとリモート コンピュータ上で管理されているアプリケーションに TCP/IP を介して接続することができます。この場合、デバッグするコンピュータからのログイン証明情報はリモート コンピュータで複製されません。たとえば、リモート コンピュータ上でそのコンピュータのローカル Administrator として -anyuser フラグを使って msvcmon.exe を起動する場合、適切な権利がなくてもサービスに接続してそのコンピュータ上のネイティブ アプリケーションにアタッチしてデバッグすることができます。
Web アプリケーションを作成する
新しい Web アプリケーションを作成するには 2 つの方法があります。1 つはログインするユーザー アカウントを VS Developers グループに追加して、そのアカウントに IIS WebRoot のすべての場所への書き込み権を与える方法です。もう 1 つは、そのユーザーとしてディレクトリを作成し、仮想ルートを追加する方法です。いずれの方法でも、その操作を行った後は制限されているユーザーでも Visual Studio .NET の新しいプロジェクトを作成するダイアログ ボックスで新しいアプリケーションを作成できるようになります。
IIS 仮想ルートを追加するには
- 管理コンソールの compmgmt.msc を管理ユーザーとして実行します。
- [サービスとアプリケーション] ノードを展開して、[インターネット インフォメーション サービス] - [Web サイト] ノードを展開します。
- [既定の Web サイト] ノードを右クリックして、[新規作成] - [仮想ディレクトリ] をクリックします。
- [次へ] をクリックして仮想ルートの名前を入力し、[次へ] をもう一度クリックします。
- 公開するディレクトリ名を入力して [次へ] をクリックします。
- 既定のアクセス権のままにして [次へ] をクリックします。
- [完了] をクリックして仮想ルートを作成します。
Web アプリケーションをデバッグする
Web アプリケーションのデバッグには、制限されているログイン アカウントおよびディレクトリ許可で ASP.NET を実行します。読み取りまたは書き込みアクセス許可を追加する必要があるディレクトリのセットについては、次の表を参照してください。
| ディレクトリ |
ディレクトリとその子で必要な許可 |
| %WINDIR%\Temp |
読み取りおよび書き込みアクセス許可 |
| %INSTALLROOT% |
読み取りアクセス許可 |
| %INSTALLROOT%\ASP.NET 一時ファイル |
読み取りおよび書き込みアクセス許可 |
注 : %INSTALLROOT% の形式は D:\WINDOWS\Microsoft.NET\Framework\v1.0.3705、%WINDIR% の形式は D:\WINDOWS です。
既定では、制限されているユーザーとしてログオンすると、デバッガを実行しても他のユーザーのプログラムをデバッグする特権 (SeDebugPrivilege) がないため Web アプリケーションをデバッグできませんが、Web サーバーでは NETWORK_SERVICE アカウントで ASP.NET を起動します。
SeDebugPrivilege ログイン特権を使用しない場合は、ASP.NET を実行しているアカウントを変更する必要があります。Windows XP Professional では machine.config を以下のように編集し、ユーザー名とパスワードをクリア テキストで入力します。これには、コンピュータ上にあるすべての ASP.NET アプリケーションをユーザー アカウントとして実行しなければならないという欠点がありますが、これは IIS 5 にとっては最高の方法であり、また以前と同じように Web アプリケーションをデバッグおよびビルドすることができます。
セキュリティに関する注意 : この操作を行うには、machine.config ファイルが NTFS ドライブ上にあり、ACL セットは制限されている必要があります。そうしないと、コンピュータにログオンしている他のユーザーに自分のパスワードを公開することになります。いずれにしても、ACL セットの有無にかかわらず Administrators グループのユーザーはすべてパスワードを読み取ることができます。
Windows XP Professional で別のユーザーとしての ASP.NET の実行を有効にする
Administrator として、processModel タグでファイル "%INSTALLROOT%\Config\machine.config" を次のように編集します。 <processModel
enable="true"
userName="DOMAIN\username"
password="MyPswd2"
...
/ >
注 : %INSTALLROOT% の形式は D:\WINDOWS\Microsoft.NET\Framework\v1.0.3705 です。
Windows Server 2003 で別のユーザーとしての ASP.NET の実行を有効にする
Windows Server 2003 および IIS 6.0 にはアプリケーション プールという新しい機能があります。各プールは IIS_WPG グループのメンバシップを持つ別のユーザーとして実行されるように設定できます。仮想ルートはアプリケーション プールに追加することができ、そうするとデバッガを実行したユーザーとしてプールが実行されている場合はデバッガを仮想ルートにアタッチできます。このメカニズムでは、他の実行環境を設定し、安全にユーザーの資格情報を守り、仮想ルートを追加することが簡単にできます。
アプリケーション プールを追加および設定する
- 管理コンソールの compmgmt.msc を管理ユーザーとして実行します。
- [サービスとアプリケーション] ノードを展開して、[インターネット インフォメーション サービス] - [アプリケーション プール] ノードを展開します。
- [アプリケーション プール] ノードを右クリックし、[新規作成] - [アプリケーション プール] の順にクリックします。
- アプリケーション プールの名前を入力して [OK] をクリックします。
- 新しいアプリケーション プールを右クリックして [プロパティ] をクリックします。
- [識別] の [構成可能] オプションを選択します。
- デバッグする際に使用するユーザー名とパスワードを適切なテキスト ボックスに入力して [OK] をクリックします。
注 : このアカウントは IIS_WPG グループのメンバであり、ASP.NET アプリケーションを実行するには上の一覧のアクセス許可が必要です。
[アプリケーション プール] で実行する仮想ルートを設定する
- 管理コンソールの compmgmt.msc を管理ユーザーとして実行します。
- [サービスとアプリケーション] ノードを展開して、[インターネット インフォメーション サービス] - [Web サイト] - [既定の Web サイト] ノードを展開します。
- [既定の Web サイト] ノードを展開して利用可能なすべての仮想ルートを表示します。
- 設定する仮想ルートを右クリックして [プロパティ] をクリックします。
- [仮想ディレクトリ] タブの [アプリケーション プール] ドロップダウン リストで適切なユーザーで実行しているアプリケーション プールを選択して、[OK] をクリックします。
セットアッププロジェクトの出力をインストールする
セットアッププロジェクトから出力のインストールには、RunAs.exe および MSIEXEC ツールについて述べたようにネットワークからアプリケーションをインストールする場合と同じ制限があります。出力は通常のアプリケーションと同様にすべてのユーザー用にインストールします。そうしないと起動またはデバッグが難しくなります。
まとめ
上位レベルの権限を要するタスクを実行する必要がある場合、安全なアプリケーションを開発して安全な作業環境を確保するには多少費用が高くなります。しかし、その代償として安全な作業環境とプログラムを得ることができるのです。安全を確保しない理由など存在しません。
アプリケーションの実行に必要な特権が少ないほど、危険な状況に陥ったときの被害を少なくできるのです。アプリケーションが出荷されるときは少なくても 1 つの危険にさらされています。その危険がユーザーのコンピュータに与える被害、およびだれかがその危険を濫用したときに会社が受ける被害の大きさを決めるのは開発次第なのです。
|