企業は今日、デスクトップの標準化を実施するという困難な仕事に直面しています。ユーザーの大半が自分のコンピュータをローカル管理者として実行しているので、この課題はいっそう困難なものになっています。ユーザーはローカル管理者として、アプリケーションのインストール/アンインストールおよびシステムとセキュリティの設定の調整を自由に行うことができます。その結果、IT 部門が自社環境全体の正常性とセキュリティを判断できないことがよくあります。さらに、ユーザーが起動するどのアプリケーションにも、ユーザー アカウントの管理レベルのアクセス権を使用して、システム ファイルとレジストリに書き込み、システム全体のデータを変更してしまう可能性が潜在的にあります。このシナリオでは、Web サイトの閲覧や電子メールのチェックなどの一般的な作業でも、危険になることがあります。さらに、これらの要素のいずれも、組織の総保有コスト (TCO) の増大につながります。
IT 部門には、攻撃を受けても回復でき、データの機密性、整合性、および可用性を保護できるソリューションが必要です。そこで、Microsoft(R) Windows Vista(TM) 開発チームは、Windows のコア セキュリティ インフラストラクチャとアプリケーションが対話する方法を設計し直すことにしました。この再設計の結果が、ユーザー アカウント制御 (UAC) です。
UAC を使用する理由
Windows の管理者アカウントの履歴
既定では、Microsoft Windows(R) XP を初めてインストールするときに、Windows XP セットアップ ウィザードによりすべてのユーザー アカウントがローカル管理者として作成されます。管理者アカウントにはシステム全体のアクセス権があるので、ユーザーはソフトウェアのインストール、更新、および実行を行うことができます。ユーザーがローカル Administrators グループに追加されると、そのユーザーにはあらゆる Windows 特権が自動的に付与されます。特権とは、コンピュータ全体のポリシーに影響を及ぼす承認属性のことです。たとえば、SeBackupPrivilege では、ファイルとディレクトリをバックアップすることができます。ただし、特権とアクセス許可を混同しないよう注意してください。アクセス許可はオブジェクトに適用されるのに対し、特権はユーザー アカウントにのみ適用されます。これらの特権は、ユーザーのアクセス トークンに収集され、保守されます。アクセス トークンには、承認用のユーザー固有のデータも格納されます。Windows では、アクセス トークンを使用して、ユーザーがアクセスできるリソースを追跡します。各 Windows リソースに、アクセス制御リスト (ACL) が 1 つあります。これは、そのリソースにアクセスするアクセス許可を持っているユーザーとサービス、およびアクセス許可のレベルを記録するリストです。Windows の承認モデルでは、ユーザーのアクセス トークン内に格納されているデータを使用して、リソースの ACL でユーザーに許可/拒否されているアクセスを判断します。
管理ユーザーに自動的に付与されるものは、次のとおりです。
-
すべてのリソースに対する読み取り、書き込み、および実行のアクセス許可
-
Windows のすべての特権
注 |
|
Windows Vista では、Windows リソース保護 (WRP) 用に設計されたアクセス許可を使用して、%systemroot% のファイルとフォルダを保護します。これにアクセスできるのは、システム サービスのみです。管理者は、システム ファイルとシステム フォルダを読み取ることはできますが、書き込むことはできません。この点は以前のバージョンの Windows と異なります。 |
どの Windows リソースでも、すべてのユーザーが読み取り、変更、および削除できるようにしてはいけないと思われますが、多くの企業の IT 部門には、社内ユーザー全員を管理者にするしか選択肢がありません。
今日、企業でユーザーが管理者として実行している理由のいくつかは次のとおりです。
-
アプリケーションのインストール (ユーザー グループのメンバでは、アプリケーションのインストールもアンインストールもできない) : Microsoft Systems Management Server(R) (SMS)、グループ ポリシー ソフトウェア インストール (GPSI)、その他の類似のアプリケーション展開テクノロジなど、アプリケーションをユーザーに展開するための一元化された方法を持たない企業は少なくありません。ソフトウェア展開テクノロジを活用している企業では、ユーザーが管理者としてアプリケーションを実行することができます。これは、特定の部門で使用する特殊なアプリケーション (マーケティング部門で使用するカスタム スプレッドシート アプリケーションなど) を一時的にインストールできるようにするためです。
-
カスタム Web アプリケーション (ActiveX コントロール) : 独立系ソフトウェア ベンダ (ISV) のコミュニティが発展してきているので、自社固有のビジネス要件向けにカスタム アプリケーションを設計することを選ぶ企業が増えています。これらのカスタム アプリケーションの多くは、ActiveX コントロールのインストールが必要な、Web ブラウザのフロントエンドを含んでいます。ActiveX コントロールは実行可能ファイルであり、マルウェアを埋め込むことができるので、Windows ではユーザー グループのメンバが ActiveX コントロールをインストールできないようにしています。
-
TCO が削減されるという思い込み (ヘルプ デスク宛ての電話本数の減少 VS 攻撃を受ける可能性の低下) : ユーザーが独自にアプリケーションをインストールことを許可することにより、ヘルプ デスク宛ての電話の本数とそのコストが減少すると信じる企業は少なくありません。ところが、社内のワークステーションを管理者として実行すると、ネットワークが "マルウェア" に対して脆弱になります。マルウェアとは、ウイルス、トロイの木馬、スパイウェア、一部のアドウェアなど、悪意のあるソフトウェアの総称です。マルウェアは、ローカル管理者アカウントのシステムレベルのアクセス権を悪用して、ファイルを破損したり、システム構成を変更したり、さらにはネットワーク外への機密データの転送まで行うことがあります。
すべてのユーザーが必ず標準ユーザーとして実行することが、マルウェアによる影響を最小限に抑えるための第一の方法です。標準ユーザー アカウントは、デスクトップでの基本的な作業を行うのに必要な最小限のユーザー権利と特権を持つユーザー アカウントです。ところが、Windows XP で既定で存在するアカウントは、標準ユーザー アカウントであるのに対して、日常的タスク (Windows のタイムゾーンの変更やプリンタのインストールなど) の多くでは、ユーザーが管理者特権を持っていることが必要とされます。また、ユーザーが管理者であることが既定で要求されるアプリケーションも多くあります。これは、実行前にアプリケーションにより管理者グループのグループ メンバシップが確認されるからです。Windows 95 と Windows 98 には、ユーザー セキュリティ モデルはありませんでした。その結果、アプリケーション開発者は、アプリケーションが管理者としてインストールされ、実行されるものとして設計しました。ユーザー セキュリティ モデルが初めて作成されたのは、Windows NT 向けです。しかし、すべてのユーザーが既定で管理者として作成されました。さらに、Windows XP コンピュータでは、標準ユーザーがアプリケーションをインストールしたり、他の管理タスクを実行したりするためには、[別のユーザーとして実行] を使用するか、または管理者アカウントでログオンする必要があります。
Windows Vista が開発されるまでは、ログオフしたり、ユーザーを切り替えたり、[別のユーザーとして実行] を使用したりせずに、標準ユーザー アカウントから管理者アカウントに "昇格する" ための方法は、Windows オペレーティング システムに組み込まれていませんでした。その結果、大半の人は依然として管理者として、Web を閲覧したり電子メールを読んだりしています。
総保有コストの削減
UAC を使用すると、ユーザーは簡単に標準ユーザーとして実行することができるので、IT 部門は、システム ファイル、監査ログ、システム全体の設定など、自社環境の整合性について自信を深めることができます。さらに、管理者が多大な時間を割いて、個々のコンピュータでの作業を承認する必要はなくなりました。これにより、IT スタッフはシステム全体の保守作業により多くの時間を割り振ることができるようになり、企業のソフトウェア プラットフォームの TCO が削減されます。さらに、IT 管理者はソフトウェア ライセンスをより効果的に管理できます。これは、許可されたアプリケーション以外はインストールされない状況が確保されるからです。その結果、ライセンスを受けていない、または悪意のあるソフトウェアにより、社内ネットワークが危険にさらされたり、システム ダウンタイムやデータ損失が引き起こされたり、ライセンスを取得するためのコストが新たに発生することを心配する必要は、もはやありません。
UAC のしくみ
お客様が標準ユーザーとして実行を試みる際に直面する課題に対処するため、マイクロソフトでは、だれもが標準ユーザーとしてより簡単に実行できるようにするための方法の調査を開始しました。
Microsoft Windows Vista 開発チームは、二重のアプローチを採用しました。
-
マイクロソフトのソフトウェア開発者およびサードパーティのソフトウェア開発者と協同して、Windows リソースへの過度な管理レベルのアクセスを不必要に要求しないようにします。
-
アクセス制御のセキュリティ ポリシーを有効にすることにより、標準ユーザーが実行するアプリケーションが Windows Vista と対話する方法を根本的に変更します。
UAC は、Windows Vista の重点項目であり、マイクロソフトのセキュリティ ビジョン全体の基本的な構成要素となっています。
ユーザー モードの向上
Windows Vista には、標準ユーザー アカウントと管理者アカウントという 2 種類のユーザー アカウントがあります。標準ユーザーは、以前のバージョンの Windows の標準ユーザー アカウントと同等です。標準ユーザーには、制限された管理者特権とユーザー権利のみが与えられます。%systemroot% にインストールされるアプリケーションのインストールとアンインストール、システム設定の変更、またはその他の管理タスクの実行を行うことはできません。ただし、要求に応じて有効な管理者資格情報を提示できる場合には、これらのタスクを実行することができます。UAC が有効な場合、ローカル Administrators グループのメンバは、標準ユーザーと同じアクセス トークンで実行します。ローカル Administrators グループのメンバが承認を与える場合にのみ、プロセスは管理者のフル アクセス トークンを使用することができます。このプロセスが、管理者承認モードという原理の基礎となります。
標準ユーザーが実行できるタスクの一部、および管理者アカウントへの昇格が必要なタスクの詳細を次の表に示します。
|
標準ユーザー
|
管理者
|
|
ローカル エリア ネットワーク接続の確立
|
アプリケーションのインストールとアンインストール
|
|
ワイヤレス接続の確立と構成
|
デバイス ドライバのインストール (デジタル カメラのドライバなど)
|
|
画面設定の変更
|
Windows の更新プログラムのインストール
|
|
ユーザーはハード ドライブの最適化を実行できないが、代わりにサービスが最適化を行う
|
保護者による制限の構成
|
|
CD/DVD メディアの再生 (グループ ポリシーで構成可能)
|
ActiveX コントロールのインストール
|
|
CD/DVD メディアの書き込み (グループ ポリシーで構成可能)
|
[Windows ファイアウォール] コントロール パネルの起動
|
|
現在のユーザーのデスクトップの背景の変更
|
ユーザーのアカウントの種類の変更
|
|
[日付と時刻] コントロール パネルの起動、およびタイム ゾーンの変更
|
セキュリティ ポリシー エディタ スナップイン (secpol.msc) での UAC 設定の変更
|
|
リモート デスクトップによる別のコンピュータへの接続
|
リモート デスクトップ アクセスの構成
|
|
ユーザー自身のアカウント パスワードの変更
|
ユーザー アカウントの追加または削除
|
|
バッテリ電源オプションの構成
|
Program Files または Windows ディレクトリへのファイルのコピーまたは移動
|
|
ユーザー補助オプションの構成
|
自動化されたタスクのスケジュール設定
|
|
ユーザーのバックアップ ファイルの復元
|
システムのバックアップ ファイルの復元
|
|
モバイル デバイス (スマート フォン、ラップトップ、または PDA) とのコンピュータ同期のセットアップ
|
自動更新の構成
|
|
Bluetooth デバイスの接続と構成
|
別のユーザーのディレクトリの参照
|
Power Users グループからの移行
Windows XP の Power Users グループは、グループのメンバが、完全管理者のアクセス許可を与えられなくても、アプリケーションのインストールなどのシステム タスクを実行できるようにするために設計されました。Power Users には、ファイル システムのさまざまな領域とレジストリへの書き込みアクセス許可も与えられました。これらには通常、管理者しかアクセスできません。Power Users に対しては、ある程度のアプリケーション互換性が有効にされました。しかし、これでは、アプリケーションが不必要な特権とユーザー権利を要求するという根本的な問題は解決されませんでした。UAC では、Power Users グループを使用しません。Windows XP の Power Users グループに与えられたアクセス許可は、Windows Vista から削除されました。UAC を使用すると、標準ユーザーでも一般的な構成タスクをすべて実行することができます。ただし、他のバージョンの Windows との下位互換性を維持するため、Power Users グループは残されています。Windows Vista で Power Users グループを使用するには、新しいセキュリティ テンプレートを適用し、システム フォルダとレジストリに関する既定のアクセス許可を変更して、Windows XP の場合と同等のアクセス許可を Power Users グループに与える必要があります。
管理者承認モード
管理者アカウントに対して管理者承認モードを有効にすると、標準ユーザー タスクと管理タスクを明確に区別することで、ユーザーはより安全に管理タスクを実行することできるようになります。たとえば、システム レジストリの変更は常に管理タスクにし、インターネットの閲覧は常に標準ユーザー タスクにするなどです。UAC のアクセス トークン モデルにより、この区別がさらに明確になります。管理者承認モードの管理者アカウントは、アプリケーションまたはコンポーネントが、ユーザーの完全管理者アクセス トークンを使用するためのアクセス許可を要求する際に、同意を求められます。
UAC のアーキテクチャ
Windows Vista のログオン プロセスは、一見 Windows XP と同じに見えますが、内部のしくみは大幅に変更されています。次の図は、管理者と標準ユーザーのログオン プロセスの違いを詳細に示したものです。
管理者がログオンすると、完全管理者アクセス トークンと "フィルタされた" 標準ユーザー アクセス トークンという 2 種類のアクセス トークンが付与されます。既定では、ローカル Administrators グループのメンバがログオンすると、Windows の管理者特権が無効にされ、昇格されたユーザー権利が削除されます。その結果、標準ユーザー アクセス トークンになります。そして、この標準ユーザー アクセス トークンを使用して、デスクトップ (Explorer.exe) が起動されます。Explorer.exe は、ユーザーが開始した他のすべてのプロセスにとって、アクセス トークンの継承元となる親プロセスです。その結果、アプリケーションで完全管理者アクセス トークンを使用することにユーザーが同意するか、またはそのための資格情報を提示する場合を除いて、既定ではすべてのアプリケーションが、標準ユーザーとして実行されます。このプロセスとは対照的に、標準ユーザーがログオンすると、標準ユーザー アクセス トークンのみが作成されます。そして、この標準ユーザー アクセス トークンを使用して、デスクトップが起動されます。
こうして、Administrators グループのメンバであるユーザーは、標準ユーザー アクセス トークンを使用しながら、ログイン、Web の閲覧、および電子メールの読み取りを行うことができます。この管理者が、管理者アクセス トークンが要求されるタスクを実行する必要がある場合、承認を求めるプロンプトが、Windows Vista により自動的に表示されます。このプロンプトは、昇格時のプロンプトと呼ばれます。動作はセキュリティ ポリシー エディタ (secpol.msc) スナップイン、およびグループ ポリシーで構成することができます。UAC のグループ ポリシー設定を調整する方法の詳細については、このドキュメントの「UAC 設定の構成」を参照してください。
注 |
|
このドキュメントで使用している "昇格する" という用語は、Windows Vista が、ユーザーの完全管理者アクセス トークンを使用するために、ユーザーに同意または資格情報を求めるプロセスを一貫して指しています。 |
管理者のアクセス トークンを要求する各アプリケーションは、管理者に同意を求める必要があります。1 つの例外は、親プロセスと子プロセスとの間に存在する関係です。子プロセスは、ユーザーのアクセス トークンを親から継承します。ただし、親と子のどちらのプロセスも、整合性レベルは同じである必要があります。
Windows Vista では、プロセスを整合性レベルでマークして、保護します。整合性レベルとは、信頼性を測定した値のことです。整合性レベルが "高い" アプリケーションとは、ディスク パーティション分割アプリケーションなど、システム データを変更するタスクを実行するアプリケーションです。一方、整合性レベルが "低い" アプリケーションとは、Web ブラウザなど、オペレーティング システムを危険にさらしかねないタスクを実行するアプリケーションです。Windows Vista では、整合性レベルが低いアプリケーションが、整合性レベルの高いアプリケーションのデータを変更することはできません。
標準ユーザーが、管理者アクセス トークンを要求するアプリケーションの実行を試みると、有効な管理者資格情報を提示するよう UAC により要求されます。このプロセスについては、このドキュメントの「UAC のユーザー エクスペリエンス」で詳細に説明します。
UAC アーキテクチャの詳細を次の図に示します。
アプリケーション情報サービス
アプリケーション情報サービス (AIS) は、実行のために 1 つ以上の特権またはユーザー権利の昇格を要求するアプリケーション (管理タスクなど)、およびより高い整合性レベルを要求するアプリケーションの起動を促進するシステム サービスです。AIS は、昇格が要求され、(グループ ポリシーに応じて) ユーザーが昇格に同意したら、管理ユーザーのフル アクセス トークンでそのアプリケーション用の新しいプロセスを作成することで、そのようなアプリケーションの起動を促進します。これは、Windows Vista で新たに導入されたサービスです。
仮想化
エンタープライズ環境は長年、システム管理者がシステムのロックダウンを試みてきた場所なので、完全管理者アクセス トークンを要求しないよう設計された基幹業務 (LOB) アプリケーションが多くあります。その結果、IT 管理者は、UAC を有効にして Windows Vista を実行する際に、Windows Vista 以前のアプリケーションの大多数をそのまま使用し続けることができます。
Windows Vista には、UAC との互換性がなく、従来は正常に実行するために管理者のアクセス トークンを要求していたアプリケーション向けに、ファイルとレジストリの仮想化テクノロジが搭載されています。仮想化により、UAC との互換性がないアプリケーションでも、Windows Vista との互換性を確保することができます。UAC との互換性がない管理アプリケーションが、保護されたディレクトリ (Program Files など) への書き込みを試みると、変更しようとしているリソースの仮想化ビューが、UAC により提供されます。この仮想化されたコピーは、ユーザーのプロファイルの下で保持されます。その結果、互換性がないアプリケーションを実行する各ユーザーのために、仮想化されたファイルのコピーが個別に作成されます。
仮想化テクノロジがあれば、互換性がないアプリケーションの実行がサイレントに失敗したり、互換性がないアプリケーションが特定できない方法で失敗したりすることはありません。UAC では既定で、保護された領域への書き込みを行う Windows Vista 以前のアプリケーションのために、ファイルとレジストリの仮想化およびログの記録も行われます。
注 |
|
昇格され、完全管理アクセス トークンで実行されるアプリケーションには、仮想化は適用されません。 |
アプリケーションの大半のタスクは、仮想化機能を使用して適切に実行されます。ただし、仮想化により、Windows Vista 以前の圧倒的大多数のアプリケーションを実行することができますが、これは短期的な解決法にすぎず、長期的なソリューションではありません。アプリケーション開発者は、ファイル、フォルダ、およびレジストリの仮想化に頼るのではなく、Windows Vista ロゴ プログラムに準拠するようできるだけ早期にアプリケーションを変更する必要があります。
ISV がアプリケーションを UAC 互換となるよう設計する方法のガイダンスは、ユーザー アカウント制御の互換性を確保するための Windows Vista 開発要件に関するドキュメント (英語ページの可能性があります) に含まれています。
注 |
|
仮想化は、ネイティブの Windows 64 ビット アプリケーションではサポートされない予定です。これらのアプリケーションは、UAC 対応にし、データを正しい場所に書き込めるようにする必要があります。 |
注 |
|
要求実行レベル属性を持つアプリケーション マニフェストがプログラムに含まれている場合、仮想化はアプリケーションに対して無効にされます。 |
要求実行レベル
Windows Vista では、アプリケーション マニフェストと呼ばれる、実行時にアプリケーションがバインドする必要がある共有とプライベートのサイドバイサイドのアセンブリを記述および識別する XML ファイルがあり、このファイルに、UAC アプリケーション互換性のためのエントリが登録されます。アプリケーション マニフェストにエントリが登録されている管理アプリケーションは、ユーザーのアクセス トークンにアクセスするための許可を求めるプロンプトを、ユーザーに表示します。ただし、Windows Vista 以前の管理アプリケーションの大半は、アプリケーション マニフェストにエントリがなくても、アプリケーション互換性修正プログラムを適用することにより、変更せずにスムーズに実行することができます。アプリケーション互換性修正プログラムは、UAC との互換性がないアプリケーションを Windows Vista で正常に機能できるようにするデータベース エントリです。
UAC 互換アプリケーションはすべて、要求実行レベルをアプリケーション マニフェストに追加する必要があります。アプリケーションが、システムへの管理アクセスを要求した場合、"管理者特権を要求" の要求実行レベルでアプリケーションをマークすると、システムは確実にこのプログラムを管理アプリケーションとして識別し、必要な昇格手順を実行することができます。要求実行レベルを使用することにより、システムはアプリケーションに必要な特定の特権を知ることができます。既存のアプリケーションが、Windows Vista 上で正常に実行するために管理アクセスを要求する場合については、このドキュメントの「UAC との互換性確保のための、Windows Vista 以前のアプリケーションの構成」を参照してください。
インストーラ検出テクノロジ
インストール プログラムは、ソフトウェアを展開するために設計されたアプリケーションであり、通常はシステム ディレクトリとレジストリ キーに書き込みます。これらの保護されたシステム領域には一般に、管理者ユーザーのみが書き込み可能です。つまり、標準ユーザーには、プログラムをインストールするための十分なアクセス権がありません。Windows Vista は、インストール プログラムをヒューリスティックによって検出し、アクセス特権で実行するために、管理者ユーザーに管理者資格情報または承認を要求します。また、更新プログラムとアンインストール プログラムもヒューリスティックによって検出します。インストール プログラムは、ファイル システムとレジストリの保護された領域に書き込むので、UAC の設計目標は、ユーザーの知らないうちに同意なくインストールが実行されることを防止することです。
インストーラ検出機能が適用されるのは、次の項目に限られます。
1. 32 ビットの実行可能ファイル
2. requestedExecutionLevel のないアプリケーション
3. LUA が有効な標準ユーザーとして実行される会話型プロセス
32 ビット プロセスが作成される前に、インストーラであるかどうかを判断するために、次の属性がチェックされます。
-
ファイル名に "install"、"setup"、"update" などのキーワードが含まれているかどうか
-
次のバージョン リソース フィールド中のキーワード : Vendor、Company Name、Product Name、File Description、Original Filename、Internal Name、および Export Name
-
実行可能ファイルに埋め込まれたサイドバイサイド マニフェスト内のキーワード
-
実行可能ファイル内にリンクされた特定の StringTable エントリ中のキーワード
-
実行可能ファイル内にリンクされた RC データ中のキー属性
-
実行可能ファイル内の対象とされたバイト シーケンス
注 |
|
これらのキーワードとバイト シーケンスは、さまざまなインストーラ テクノロジに見られる一般的な特徴から導き出したものです。 |
このドキュメント全体、特に「手順 5 : アプリケーション マニフェストの作成とアプリケーションへの埋め込み」をよくお読みください。
注 |
|
[ユーザー アカウント制御 : アプリケーションのインストールを検出し、昇格をプロンプトする] 設定をインストーラ検出のために有効にして、インストール プログラムを検出する必要があります。この設定は既定で有効であり、セキュリティ ポリシー マネージャ スナップイン (secpol.msc) またはグループ ポリシー (gpedit.msc) で構成することができます。 |
Microsoft Windows インストーラの一般情報と概要は、MSDN (http://go.microsoft.com/fwlink/?LinkId=30197) (英語ページの可能性があります) で確認することができます。
機能の主な変更内容
次の更新内容は、Windows Vista に反映された機能の主な変更内容です。
UAC が既定で有効である
その結果、Windows Vista UAC コンポーネント対応に更新されていないさまざまなアプリケーションとの間で、互換性の問題が発生することがあります。アプリケーションが管理者アクセス トークンを要求する場合 (これは、実行を試みたときに "アクセス拒否" エラーが返されることでわかります)、ショートカット メニュー (右クリック) の [管理者として実行] オプションを使用することで、そのプログラムを管理者として実行することができます。具体的な手順については、このドキュメントの「管理者としてのプログラムの実行」で説明しています。
2 番目以降のすべてのユーザー アカウントが、標準ユーザーとして作成される
標準ユーザー アカウントと管理者ユーザー アカウントの両方が、UAC の強化されたセキュリティを活用することができます。新たなインストールでは、最初に作成されるユーザー アカウントは既定で、管理者承認モード (UAC が有効) のローカル管理者アカウントです。それ以降のすべてのアカウントは、標準ユーザーとして作成されます。
新たなインストールでは、ビルトイン Administrator アカウントは既定で無効である
WindowsVista では、ビルトイン Administrator アカウントは既定で無効になっています。Windows XP からのアップグレード時に、ビルトイン Administrator アカウントが唯一の有効なローカル管理者アカウントであると Windows Vista が判断した場合、アカウントは有効なまま、管理者承認モードになります。既定では、ビルトイン Administrator アカウントは、セーフ モードでコンピュータにログオンすることはできません。詳細については、以降のセクションを参照してください。
ドメインに不参加
セーフ モードでは、有効なローカル管理者アカウントが 1 つ以上あるとき、無効にされたビルトイン Administrator アカウントでログオンすることはできません。代わりに、任意のローカル管理者アカウントを使用してログオンすることができます。前回のローカル管理者アカウントが、誤って降格、無効化、または削除された場合には、障害復旧のために、セーフ モードで、無効にされたビルトイン Administrator アカウントでログオンすることができます。
ドメインに参加
セーフ モードではいずれの場合でも、無効にされたビルトイン Administrator アカウントでログオンすることはできません。ローカル管理者が 1 人もいない場合、Domain Admins グループのメンバであるユーザー アカウントが、コンピュータにログオンして作成することができます。
重要 |
|
それ以前にどのドメイン管理者アカウントもログオンしたことがなかった場合、資格情報がキャッシュされていないので、"セーフ モードとネットワーク" でコンピュータを起動する必要があります。 |
注 |
|
コンピュータをドメインからいったん切り離すと、前に説明した、ドメインに参加していないときの動作に戻ります。 |
セキュリティで保護されたデスクトップで、昇格時のプロンプトが既定で表示される
Windows Vista では既定で、セキュリティで保護されたデスクトップで、同意と資格情報のプロンプトが表示されます。
新しい UAC セキュリティ設定とセキュリティ設定名の変更
UAC セキュリティ ポリシーの詳細については、このドキュメントの「UAC 設定の構成」を参照してください。
Standard User Analyzer
UAC とのアプリケーションの互換性をテストするため、IT 管理者とアプリケーション開発者は、Standard User Analyzer を使用することができます。このツールは、標準ユーザーとして実行すると通常は失敗する、アプリケーションの昇格された動作のログを生成します。このツールを使用することで、これらの動作を調整し、UAC との互換性を達成するためのロードマップを得ることができます。さらに、Windows Vista のプロセス追跡の監査設定を使用して、エンタープライズ環境で標準ユーザーとして実行されていないアプリケーションを特定することができます。Windows のユーザー エクスペリエンスが、UAC によって損なわれることのないようにするため、これらのツールですべてのコンポーネントをテストすることを推奨します。構成情報や手順など、これらのツールの詳細については、このドキュメントの「UAC との互換性確保のための、Windows Vista 以前のアプリケーションの構成」で説明しています。
UAC のユーザー エクスペリエンス
UAC が有効の場合、管理者承認モードでは、標準ユーザーと管理者のユーザー エクスペリエンスは異なります。以降のセクションで、この相違点を詳細に示し、UAC ユーザー インターフェイスの設計について説明します。
Windows Vista をよりセキュリティで保護された状態で実行するため、主要なユーザー アカウントを標準ユーザー アカウントにすることをお勧めします。標準ユーザーとして実行することは、管理環境のセキュリティを最大限に発揮するための要件でもあります。組み込みの UAC 昇格コンポーネントを使用すると、ローカル管理者アカウントの有効な資格情報を入力することにより、標準ユーザーでも管理タスクを簡単に実行することができます。標準ユーザー用の既定の組み込み UAC 昇格コンポーネントは、資格情報プロンプトと呼ばれます。
標準ユーザーとして実行するための別の方法は、管理者承認モードで管理者として実行することです。組み込みの UAC 昇格コンポーネントを使用すると、ローカル Administrators グループのメンバは、承認を与えることにより管理タスクを簡単に実行することができます。管理者承認モードにおける管理者アカウント用の既定の組み込み UAC 昇格コンポーネントは、同意プロンプトと呼ばれます。UAC の昇格時プロンプトの動作は、ローカル セキュリティ ポリシー エディタ スナップイン (secpol.msc)、およびグループ ポリシーで構成することができます。UAC のセキュリティ設定とその値の詳細については、このドキュメントの「ローカル セキュリティ ポリシー エディタとグループ ポリシーによる UAC の管理」で説明しています。
同意プロンプトと資格情報プロンプト
UAC を有効にしている場合、Windows Vista は有効な管理者アカウントの同意または資格情報のいずれかのプロンプトを表示した後、完全管理者アクセス トークンを要求するプログラムまたはタスクを起動します。このプロンプトにより、悪意のあるアプリケーションがいつのまにかインストールされることを確実に防ぐことができます。
同意プロンプト
同意プロンプトは、ユーザーの管理者アクセス トークンを要求するタスクをユーザーが実行しようとすると、表示されます。ユーザー アカウント制御の同意プロンプトのスクリーンショットを次に示します。
次の例は、管理処理の実行前に同意が行われるようすを示したものです。
同意プロンプトを表示するには
-
管理者承認モードで管理者アカウントを使用して、Windows Vista コンピュータにログオンします。
-
[スタート] ボタンをクリックし、[マイ コンピュータ] を右クリックして、メニューから [管理] を選択します。
-
ユーザー アカウント制御の同意プロンプトで、[続行] をクリックします。
資格情報プロンプト
資格情報プロンプトは、ユーザーの管理者アクセス トークンを要求するタスクを標準ユーザーが実行しようとすると、表示されます。この標準ユーザーの既定のプロンプトの動作は、セキュリティ ポリシー マネージャ スナップイン (secpol.msc)、およびグループ ポリシーで構成することができます。[ユーザー アカウント制御 : 管理者承認モードでの管理者に対する昇格時のプロンプトの動作] の値を [資格情報を要求する] に設定すると、管理者に資格情報の提示を要求することもできます。
ユーザー アカウント制御の資格情報プロンプトのスクリーンショットを次に示します。
次の例は、標準ユーザーが管理タスクの実行を試みたときに、資格情報を要求されるようすを示したものです。
資格情報プロンプトを表示するには
-
標準ユーザー アカウントで Windows Vista コンピュータにログオンします。
-
[スタート] ボタンをクリックし、[マイ コンピュータ] を右クリックして、メニューから [管理] を選択します。
-
ユーザー アカウント制御の資格情報プロンプトで、該当する管理者のユーザー名をクリックし、そのユーザー アカウントのパスワードを入力して、[送信] をクリックします。
アプリケーションを認識する昇格時のプロンプト
UAC の昇格時のプロンプトは、アプリケーションに固有の色で色分けされており、アプリケーションの潜在的なセキュリティ上の危険をすぐに見分けることができます。アプリケーションが管理者の完全アクセス トークンでの実行を試みると、Windows Vista は最初に実行可能ファイルを分析して、発行元を判断します。アプリケーションは次に、実行可能ファイルの発行元に応じて、Windows Vista、確認済みの発行元 (署名済み)、および未確認の発行元 (未署名) という 3 種類のカテゴリに分類されます。ユーザーに提示する色付きの昇格時プロンプトを Windows Vista が判断するようすを、次の図に示します。次のイラストは、対応するレベルの信頼に対する昇格時のプロンプトの論理を詳細に示したものです。
昇格時プロンプトの色分けの詳細は、次のとおりです。
-
赤い背景と赤い盾アイコン : アプリケーションは、ブロック対象の発行元のものか、またはグループ ポリシーによってブロックされています。
-
青と緑の背景 : アプリケーションは、Windows Vista の管理アプリケーションです (コントロール パネルなど)。
-
灰色の背景と金色の盾アイコン : アプリケーションは、Authenticode 署名されており、ローカル コンピュータに信頼されています。
-
黄色の背景と赤い盾アイコン : アプリケーションは、未署名か、または署名済みでもローカル コンピュータにまだ信頼されていません。
昇格時のプロンプトの色分けは、Microsoft Internet Explorer のダイアログ ボックスの色分けと同じです。
盾アイコン
日付と時刻のプロパティ コントロール パネルなど、コントロール パネルの中には、管理者と標準ユーザーの操作が混在しているものがあります。標準ユーザーは時計の表示とタイムゾーンの変更を行うことができますが、ローカル システムの時刻を変更するには、完全管理者アクセス トークンが要求されます。次の画像は、日付と時刻のプロパティ コントロール パネルのスクリーンショットです。
時刻を変更する必要があるときには、[盾] アイコン ボタンをクリックします。盾アイコンが、プロセスを完全管理者アクセス トークンで起動するようシステムに伝えます。これにより、ユーザー アカウント制御の昇格時のプロンプトが要求されます。
昇格時のプロンプトのセキュリティ保護
プロンプトを、セキュリティで保護されたデスクトップに向かわせることにより、昇格プロセスはさらにセキュリティで保護されます。Windows Vista では既定で、セキュリティで保護されたデスクトップで、同意と資格情報のプロンプトが表示されます。セキュリティで保護されたデスクトップにアクセスできるのは、Windows プロセスのみです。管理者と標準ユーザーに対する推奨事項に加えて、[ユーザー アカウント制御 : 昇格のプロンプト時にセキュリティで保護されたデスクトップに切り替える] 設定を有効にしたままにしておき、高いレベルのセキュリティを実現することを強くお勧めします。
実行可能ファイルが昇格を要求すると、対話型のデスクトップ (ユーザー デスクトップとも呼ばれます) は、セキュリティで保護されたデスクトップに切り替えられます。セキュリティで保護されたデスクトップは、ユーザー デスクトップのアルファブレンドされたビットマップを表示します。また、強調表示された昇格時のプロンプト、および対応するアプリケーション呼び出しウィンドウを表示します。ユーザーが [続行] または [キャンセル] をクリックすると、セキュリティで保護されたデスクトップは、ユーザー デスクトップに戻ります。
マルウェアは対話型のデスクトップを隠して、代わりにセキュリティで保護されたデスクトップの偽物を提示することができますが、承認を要求するよう設定されていると、ユーザーが偽者のデスクトップ上で [続行] をクリックするよう騙された場合でも、マルウェアは昇格を得られないことを覚えておいてください。資格情報を要求するよう設定されている場合、資格情報プロンプトを模倣するマルウェアが、ユーザーから資格情報を収集できてしまう可能性があります。ただし、これによりマルウェアが、昇格された特権を得られるわけではなく、システムには他の保護機能がいくつかあり、マルウェアが収集したパスワードを使用して、ユーザー インターフェイスを自動的に操ることを防止することができます。
重要 |
|
マルウェアは、セキュリティで保護されたデスクトップの偽者を提示することができますが、ユーザーが以前にコンピュータにマルウェアをインストールしていない限り、この問題は発生しません。UAC を有効にしている場合、管理者アクセス トークンを要求するプロセスをユーザーの知らないうちにインストールすることはできないので、ユーザーは [続行] をクリックするか、または管理者資格情報を提示して、同意を明示的に与える必要があります。UAC 昇格時のプロンプトの具体的な動作は、グループ ポリシーに応じて決まります。 |
Windows Vista では、この設定は既定で有効であり、ローカル セキュリティ ポリシー エディタ スナップイン (secpol.msc) または一元的にグループ ポリシーで構成することができます。使用できる設定と構成の詳細については、このドキュメントの「ローカル セキュリティ ポリシー エディタとグループ ポリシーによる UAC の管理」で説明しています。
Windows Vista 以前のアプリケーションの保守
ただし、アプリケーションの中には、さまざまな理由で設計し直すことができないものもあります。UAC には、そのような Windows Vista 以前のアプリケーションのために、保護機能が組み込まれています。たとえば、要求実行レベルや、ファイル、フォルダ、およびレジストリの仮想化などです。
Windows Vista 向けの UAC 互換アプリケーションの開発
必要最小限の特権とユーザー権利でアプリケーションを実行するという考え方は、ソフトウェア開発コミュニティで広く受け入れられています。しかし、その代わりにソフトウェアの使用法を簡略化すること、またはユーザー インターフェイスの改良に力を入れることにしたベンダは、その点を見落としがちです。
UAC と適切に連携できるようアプリケーションを変更する必要があるアプリケーション開発者は少なくないと予想されます。管理者権限を不必要に要求するアプリケーションは、UAC 互換に設計し直す必要があります。この再設計により、標準ユーザーが現時点では Windows 上で実行できない多くのアプリケーションを Windows Vista 上で実行できるようになります。
マイクロソフトはこれまで、アプリケーション開発者にガイダンスとツールを提供し、この再設計プロセスの推進を支援してきました。詳細については、MSDN のアプリケーションの互換性に関するページ (http://go.microsoft.com/fwlink/?LinkId=49973) (英語ページの可能性があります) を参照してください。
これらの変更を行っても、完全管理者アクセス トークンを要求するタスクは依然としてあります。たとえば、ユーザー アカウントの管理、デバイス ドライバのインストール、エンタープライズ管理ソフトウェアの実行などです。Windows Vista に関しては、アプリケーション開発者は、アプリケーションの特定のタスクにとって 2 つのレベルのアクセス権のいずれが必要なのかを判断する必要があります。アプリケーションがタスクに完全管理者アクセス トークンを必要としないのであれば、標準ユーザー アクセスのチェックのみを要求するようアプリケーションを記述します。たとえば、UAC 互換アプリケーションは、Program Files ディレクトリ ツリーとは無関係に、データ ファイルをユーザーのプロファイルに書き込む必要があります。
Windows Vista ロゴ プログラム
Windows Vista ロゴ プログラムは、UAC 互換アプリケーション作成の大きな利点となります。このプログラムにより、厳密な資格認定のガイドラインが実施されるので、認定を受けた製品であれば Windows Vista と正常に連携できることが顧客に保証されます。
Windows Vista ロゴ認定を取得することにより、独立系ソフトウェア ベンダ (ISV) は、競争力のある差別化を図り、顧客から信頼を得ることができます。認定済みアプリケーションを購入した顧客は、そのアプリケーションが Windows Vista と完全に互換性があり、ISV が顧客の保有するデータの整合性とセキュリティに最大限の注意を払っていることを知り、安心できます。マイクロソフトは現在、マニフェストの生成と署名を行う ISV のために、ワークフローを処理するツール群のベータ版を作成しています。「ロゴ認定書」はパッケージに同梱され、認定書は目立つ位置にあります。Windows Vista ロゴ認定プロセスの詳細については、Microsoft Windows ロゴのホーム ページを参照してください。
標準ユーザーのためのアプリケーション展開
企業にとって最も困難な課題の 1 つは、アプリケーションのインストールの管理です。Microsoft Systems Management Server (SMS) のような展開ツールは、IT 部門がアプリケーション展開を一元化し、自社の全体的な TCO を削減するために役立ちます。Windows Vista には UAC ユーザー モデルが導入されているので、SMS によりさらに TCO が削減され、管理が容易になります。
アプリケーション展開のセキュリティの最大化
IT 部門は次の 3 レベルのセキュリティを使用して、アプリケーション展開のシナリオをモデル化することができます。
-
高 : すべてのアプリケーションが、SMS、GPSI、または同様のアプリケーション展開テクノロジを使用してパッケージ化され、展開されます。
-
中 : アプリケーションが IT 部門によりケースバイケースでインストールされます。
-
低 : 標準ユーザーが自由にアプリケーションをインストールすることができます。
これら 3 レベルのセキュリティのシナリオは、次のとおりです。
高 : すべてのアプリケーションが、SMS、GPSI、または同様のアプリケーション展開テクノロジを使用して展開される
このシナリオでは、すべてのアプリケーション、オペレーティング システム、およびセキュリティ更新プログラムが、アプリケーション展開テクノロジを使用して展開されます。この例で SMS や GPSI などのテクノロジを使用する利点は、次のとおりです。
-
管理のしやすさ : アプリケーションを一元的に管理することにより、IT 部門は簡単にインストール済みアプリケーションのリストを管理し、不要なアプリケーションのインストールを防止することができます。
-
マルウェアのインストール数の減少 : マルウェアは、正当なソフトウェアに "同梱" されていることがよくあるので、ユーザーがそのようなソフトウェアをインストールできないようにすることにより、多くのマルウェアのインストールを防止することができます。
-
全体的な TCO の削減 : マルウェアのインストール数、およびユーザーあたりのマルウェアの存在場所が減少します。
このレベルのセキュリティの要件
-
Microsoft SMS 4.0 が専用サーバーにインストールされている (SMS をアプリケーション展開テクノロジとして使用している場合。そうでない場合、採用したテクノロジに合わせてこの要件を変更してください)。
-
すべてのユーザーが標準ユーザー アカウントを持ち、このアカウントで自分のコンピュータにログオンする。
-
ドメイン管理者が、標準ユーザー アカウント、および UAC が有効にされたドメイン管理者アカウントという 2 種類のアカウントを持つ。
-
[ユーザー アカウント制御 : 管理者承認モードですべての管理者を実行する] 設定が有効にされ、グループ ポリシーを使用して一元的に管理される。
-
[ユーザー アカウント制御 : 昇格のプロンプト時にセキュリティで保護されたデスクトップに切り替える] 設定が有効にされ、グループ ポリシーを使用して一元的に管理される。
-
[ユーザー アカウント制御 : 標準ユーザーに対する昇格時のプロンプトの動作] 設定が、[資格情報を要求する] として構成され、グループ ポリシーを使用して一元的に管理される。
利点。UAC をこのように実装することには、利点がいくつかあります。UAC セキュリティ設定をグループ ポリシーを使用して一元的に管理することにより、IT 部門はローカル コンピュータ ポリシーが、IT 部門のポリシーをすり抜けるように変更されることを確実に防止することができます。ユーザーは自分のコンピュータに標準ユーザーとしてログオンし、ローカル管理者アカウントのユーザー名とパスワードを知らないので、システム設定の変更、ソフトウェアやマルウェアのインストール、および意図的にまたは意図せずにコンピュータに手を加えて変えてしまうことは、できなくなります。ユーザーはすべて標準ユーザーですが、アプリケーションのインストールと更新は、SMS を使用して行うことができます。SMS ソフトウェア展開の具体的な利点については、このセクションで説明しました。
中 : アプリケーションが IT 部門によりケースバイケースでインストールされる
セキュリティ レベルは "中" ですが、管理は最も難しくなります。このシナリオでは、アプリケーションのインストールを希望するたびに、すべてのユーザーがその要望をヘルプ デスクに提出する必要があります。すると、ヘルプ デスクは、リモートデスクトップを使用してアプリケーションをインストールするか、または資格情報をユーザーのコンピュータに物理的に入力します。理論上は、IT 部門はどのコンピュータにどのアプリケーションがインストールされているのかを把握している必要がありますが、実際にはこの追跡作業は煩わしく、管理は困難です。さらに、ローカル管理者アカウントの資格情報が、標準ユーザーに対して一度でも開示されると、セキュリティ ポリシーは危険にさらされるものと考える必要があります。
低 : ユーザーがアプリケーションを自由にインストールできる
このシナリオでは、3 種類の構成が可能です。構成をセキュリティ レベルが低下する順に示します。最初の構成が、最もセキュリティ レベルが高いです。
-
ユーザーは標準ユーザーだが、ローカル管理者のユーザー名とパスワードを知っている。
-
[ユーザー アカウント制御 : 管理者承認モードですべての管理者を実行する] 設定が有効です。
-
ユーザーは標準ユーザー アカウントでログインし、管理タスクを行うときは、ユーザー アカウント制御の資格情報プロンプトでローカル管理者アカウントの資格情報を提示します。
- 影響 : IT 部門がアプリケーションのインストールやコンピュータの正常性を示す指標を追跡するための効率的な方法はありませんさらに、ユーザーは自分でもよくわからない実行可能ファイルに対して、ユーザー アカウント制御の資格情報プロンプトで資格情報を提示することによって、マルウェアをインストールできてしまいます。
-
ユーザーがローカル管理者である。
-
[ユーザー アカウント制御 : 管理者承認モードですべての管理者を実行する] 設定が有効です。
-
ユーザーは管理者アカウントでログインし、管理タスクを行うときは、ユーザー アカウント制御の同意プロンプトで同意を示します。
- 影響 : UAC は有効ですが、すべてのユーザーが管理者としてログオンするので、どのユーザーでも簡単にソフトウェアのインストール、システム設定の操作、およびコンピュータのセキュリティ ポリシーのすり抜けを行うことができます。さらに、IT 部門がアプリケーションのインストールやコンピュータの正常性を示す指標を追跡するための効率的な方法はありません
-
UAC は無効にされており、すべてのユーザーがローカル管理者である。
-
[ユーザー アカウント制御 : 管理者承認モードですべての管理者を実行する設定が無効です。
-
ユーザーが管理者アカウントでログインし、管理タスクを実行します。
- 影響 : UAC が無効に設定されていると、管理アプリケーションがユーザーの管理アクセス トークンの使用を試みても、ユーザーに通知されません。その結果、IT 部門がアプリケーションのインストールやコンピュータの正常性を示す指標を追跡するための効率的な方法はありませんさらに、マルウェアがいつのまにかインストールされます。管理実行可能ファイルが実行できるようになる前に、ユーザーに承認のプロンプトも資格情報のプロンプトも表示されないからです。
標準ユーザー向けアプリケーションのテスト
アプリケーションの再パッケージ化
Windows Installer 4.0 は、UAC を完全に認識し、UAC 互換となるよう設計されました。アプリケーションのカスタマイズと IT 環境向けの再パッケージ化を行う必要があるシステム管理者は、FLEXnet AdminStudio 7 SMS Edition を使用して、SMS 展開のために Windows インストーラでソフトウェアを再パッケージすることができます。FLEXnet AdminStudio 7 SMS Edition を使用すると、企業は SMS サーバー コンソールに触れることなく SMS 2003 を使用して、ソフトウェア パッケージの準備、公開、および配布を行うことができます。その結果、アプリケーション管理業務の効率性が、大幅に向上します。
FLEXnet AdminStudio 7 SMS Edition には、ウィザードベースのリパッケージャ コンポーネントが用意されているので、どのようなセットアップでも (パッケージ化が難しい InstallScript Windows インストーラ セットアップでも)、完全な Windows インストーラ パッケージに簡単に変換できます。リパッケージャに含まれているものは、スナップショットのない再パッケージ化のための InstallMonitor、Windows インストーラへの変換時に InstallScript セットアップから情報を最大限に引き出すための SmartScan、Windows インストーラが重要なファイルを逃さないようにするための Setup Intent、および作業者を正しいパッケージ化プロセスに導くための Packaging Process Assistant です。
FLEXnet AdminStudio 7 SMS Edition は、SMS サイト (http://go.microsoft.com/fwlink/?LinkId=71355) (英語ページの可能性があります) から無料でダウンロードすることができます。
次の参照情報は、ソフトウェアの再パッケージ化についての追加情報を提供します。
UAC 展開シナリオ
ここでは、中規模の企業である Litware, Inc の UAC 展開シナリオを検討します。次のシナリオは、UAC を有効にした Windows Vista 環境で実行することが原因で発生する可能性がある潜在的問題の範囲を、IT 部門が見極められるように支援することを意図しています。
Litware, Inc (中規模の企業)
Litware, Inc のメイン オフィスで、あるコンピュータに Windows Vista をインストールした後、あるユーザーが管理者承認モードで管理者としてログインし、部門に固有の基幹業務 (LOB) アプリケーションが保管されている共有フォルダを参照します。この共有場所には、アプリケーションごとにフォルダが 1 つあります。Windows Vista はさまざまなテクノロジ (Windows インストーラ、bootstrapper.exe、xcopy タイプのインストーラなど) を使用して、アプリケーションをインストールします。
同社には、Windows XP のデスクトップが 2,500 台あり、UAC を使用するために Windows Vista にアップグレードすることに決定しました。IT 部門は自社のさまざまな LOB アプリケーションをインストールする方法を、1 つの基準として見つける必要があります。しかし、次のような問題があることがわかりました。
-
IT 部門のだれも、グループ ポリシー ソフトウェア インストール (GPSI) および Systems Management Server (SMS) の経験がありません。その結果、スタッフの 1 人に研修を受けさせるために投資する必要があります。
-
Windows インストーラでインストールするために LOB アプリケーションを変換することは、変換作業を支援するツールが何もないので、高コストになる可能性があります。たとえば、"アプリケーションをすべてパッケージ化できるが、インストール設定は簡単には設定できない" ことになりかねません。
-
IT 部門はアプリケーションのインストールを行うために、ログオン スクリプトをいくつか作成しましたが、その作成に費やした時間、リソース、および労力を無駄にしたくはありません。
管理者承認モードの管理者のソリューション
この問題は、Windows Vista に特有ではありません。企業は長い間、アプリケーションを標準ユーザーとしてインストールすることに努めてきましたが、成功の程度はさまざまです。ソリューションを望ましさのレベルが低い順から示します。良いソリューション、より良いソリューション、および最良のソリューションです。
良い
ユーザーは既存の共有場所からインストールでき、ヒューリスティック インストーラ検出機能を信頼して、LOB アプリケーションをインストーラとして識別し、昇格された要求実行レベルを呼び出すことができます。サイレント昇格が無効に設定されているので、同意プロンプトも資格情報プロンプトも表示されません。しかし、これらの共有場所からアプリケーションを実行するときには、知らないうちに完全管理者アクセス トークンで実行していることになります。
Windows Vista のヒューリスティック インストーラ検出機能の詳細については、このドキュメントの「インストーラ検出テクノロジ」を参照してください。
ところが、このアプローチには、制限事項がいくつかあります。Windows Vista のインストーラ検出機能により、アプリケーションがインストーラとして識別され、自動的に昇格されてしまうケースが多数発生する可能性があります。また、アプリケーションの設計時に Windows Vista 環境へのインストールを意図していなかった場合、互換性の心配も生じます。
より良い
企業が社内環境のロックダウンへの投資をさらに増やす際に、IT 部門が最初に行うことの 1 つが、ユーザーのコンピュータで実行されているアプリケーションすべてのカタログを作成することです。このシナリオでは、IT 部門の 1 人のメンバが既に、これらのアプリケーションを 1 か所、つまりネットワーク共有にまとめています。これらのアプリケーションがまとめられているので、要求実行レベルで、管理者としてインストーラを実行するよう明示的にマークすることにより、前のセクションで説明した制限事項を簡単に克服することができます。アプリケーションを要求実行レベルでマークするには、それらのアプリケーションのためにアプリケーション互換性データベースにエントリを追加することが必要です。アプリケーションが誤ってインストーラとして識別されている場合には、比較的低い要求実行レベルで実行するようマークすることもできます。
スクリプトを作成して、共有場所をスキャンし、すべてのアプリケーションを RunAsAdmin アプリケーション互換性データベース レベルでマークすることもできます。要求された実行レベルでアプリケーションをマークする方法のガイダンスは、このドキュメントの「アプリケーション互換性のための、要求実行レベルでのアプリケーションのマーク」で説明しています。
アプリケーション データベースのマークは、グループ ポリシー オブジェクト (GPO) と関連付けられています。GPO は、グループ ポリシーを使用して社内全体に展開されます。このポリシーを展開した後には、アプリケーションが、明示的に指定された要求実行レベルで実行されるよう一貫してマークされることが、企業内の各ユーザーに保証されます。
最良
IT スタッフは、ユーザーがインストールするさまざまなアプリケーションを理解しているので、IT 部門はこれらのアプリケーションのインストールの管理を開始し、他のアプリケーションのインストールを防止することができます。最初の手順は、インストーラ検出機能を無効にし、社内にある製品をインストールする各アプリケーションのために、明示的な要求実行レベルのマークを作成することです。ここでは、ユーザーがインストールするアプリケーションを IT 部門はすべて把握しており、各アプリケーションは要求実行レベルでマークされているので、インストーラ検出機能はもはや必要ないと単純に仮定しています。
アプリケーションのインストールの管理度が高まったので、ユーザーは CD やその他の外部メディアからインストールする必要はもはやありません。あらゆるものをネットワーク上で入手することができます。Windows インストーラを外部のリムーバブル メディアから使用するアプリケーションをユーザーがインストールできないようにするために、次の手順を実行して、[インストールでリムーバブル メディア ソースを使えないようにする] の値を、Windows インストーラ管理テンプレート ファイルに設定します。
リムーバブル メディア ソースをインストールに使用できないようにするには
-
[スタート] ボタン、[コントロール パネル] の順にクリックし、[管理ツール]、[Active Directory ユーザーとコンピュータ] の順にダブルクリックします。
-
コンソール ウィンドウで、[ユーザーの構成]、[管理テンプレート]、[Windows コンポーネント] の順に展開し、[Windows インストーラ] をクリックします。
-
[詳細] ウィンドウで、[インストールでリムーバブル メディア ソースを使えないようにする] を右クリックして、[プロパティ] をクリックします。
-
[プロパティ] で、[有効にする] をクリックし、[OK] をクリックします。
注 |
|
[インストールでリムーバブル メディア ソースを使えないようにする] の設定を有効にすると、ユーザーがリムーバブル メディア (CD、フロッピー ディスク、DVD など) からプログラムをインストールしようとすると、この機能が見つからないという内容のメッセージが表示されます。 |
注 |
|
[インストールでリムーバブル メディア ソースを使えないようにする] の設定は、インストールがユーザーのセキュリティ コンテキスト内で実行されているときでも適用されます。 |
重要 |
|
前に説明したとおり、エンド ユーザーが管理者として実行している場合には、IT 部門が展開した設定が、そのコンピュータに実際に設定されているかどうかは、まったく保証されません。管理ユーザーがさまざまな設定をすり抜けることができる方法は、さまざまです。これは単に、時間、経験、および決断力の問題です。 |
複数のアプリケーションを単一のネットワーク共有にまとめることの別の利点は、すべてのバイナリに署名できることです。バイナリの署名が完了した後には、[ユーザー アカウント制御 : 署名され検証された実行ファイルのみを昇格する] の設定を有効にすることにより、自社の安全性がいっそう向上します。
さらに、ソフトウェア制限のポリシー (SRP) を追加して、許可されていない実行可能ファイルの実行を禁止することができます。
標準ユーザーのソリューション
ソリューションを望ましさのレベルが低い順から示します。より良いソリューションおよび最良のソリューションです。
より良い
IT 部門は、標準ユーザーが一般にどのアプリケーションもインストールできず、各自のアクセス トークンに追加された最小限のユーザー権利セットを持つことになると想定する必要があります。ユーザーはもはや管理者として実行できなくなり、その代わりに、システムの状態を変更する場合には管理者として実行するサービスを必要とします。そのために、Windows には Windows Installer Server というインストール専用のサービスが用意されています。グループ ポリシー ソフトウェア インストール拡張もあります。これを使用すると、インストール時にユーザーと対話することなく、アプリケーションをユーザーのコンピュータに配布することができます。
詳細については、グループ ポリシー ソフトウェア インストール拡張のドキュメント (http://go.microsoft.com/fwlink/?LinkId=71356) (英語ページの可能性があります) を参照してください。
別のオプションは、SMS のようなテクノロジを使用してアプリケーションを展開することです。基本的な考え方は同じです。標準ユーザーが、実行するための特権もユーザー権利も持っていないタスクを実行するときには、バックエンド サービスが必要になります。
SMS でアプリケーションを展開する方法のガイダンスについては、TechNet (http://go.microsoft.com/fwlink/?LinkId=71357) (英語ページの可能性があります) を参照してください。
GPSI 拡張機能を使用する際の課題の 1 つは、アプリケーションを Windows インストーラで配布する必要があるということです。アプリケーションのインストーラ バイナリを Windows インストーラに変換するためには、"再パッケージ化" と呼ばれるプロセスが必要です。これには、アプリケーションに固有の設定を判断し、さまざまなイベントの適切な実行順序を理解することも含まれます。 InstallShield の DevStudio など、このプロセスを支援するツールがいくつかあります。
アプリケーションの再パッケージ化は、非常に手間のかかる作業になることがあり、複数のチーム全体でその作業に当たらせている企業も少なくありません。アプリケーションの再パッケージ化の詳細については、このドキュメントの「アプリケーションの再パッケージ化」で説明しています。
最良
このシナリオでは、ソフトウェア展開時の多くの考慮事項に間接的に言及します。一般に、どのエンタープライズ ユーザーも自分のコンピュータに必要とする LOB アプリケーションのコア セットがあるものです。これは、GPSI Publishing または提供情報を使用して社内全体に展開する際に目標となる便利なソフトウェアのセットです。多くのコンピュータが展開されている企業では、既にインストールされているアプリケーションのイメージ ライブラリを作成することは有益です。
システム準備ツール (sysprep.exe) は、Windows に同梱されており、これを使用すると、大規模展開用のイメージを作成することができます。システム準備ツールを使用して、必要なコア アプリケーション全体を含むイメージを作成します。次に、そのイメージを社内全体のすべてのコンピュータに展開します。この展開方法により、ネットワーク経由で大規模なインストールを複数回繰り返すことによるリソースへの影響を回避することができます。最後に、各部署の組織単位 (OU) を使用して、補完的なパッケージを GPSI でユーザーに提供します。
UAC 設定の構成
ここまでは、UAC が機能するしくみ、および社内に Windows Vista を展開する際に生じる可能性があるいくつかの問題について説明しました。次に、セキュリティと使いやすさが最適化されるよう UAC を構成する方法について説明します。
ここでは、UAC を構成するための 2 つの主な方法を詳細に説明します。
ローカル セキュリティ ポリシー エディタとグループ ポリシーによる UAC の管理
Windows Vista 以前は、多くの場合、パーソナル コンピュータまたはネットワーク設定を操作する標準ユーザーが、アプリケーションをインストールできていました。その当時の主な違いは、管理者がグループ ポリシー設定を作成して、アプリケーションのインストールを制限することができたとはいえ、標準ユーザーによるアプリケーションのインストールを制限するアクセス権を、既定の設定としては持っていなかったことです。UAC 環境では、既定で管理者にこのアクセス権があり、さらにグループ ポリシーを使用して、デバイスと展開の承認済みリストを定義することもできます。
UAC 向けに構成できるグループ ポリシー オブジェクト (GPO) 設定は、9 つあります。以降のセクションで、さまざまな UAC GPO 設定の詳細、および推奨事項を説明します。
ユーザー アカウント制御 : ビルトイン Administrator アカウントのための管理者承認モード
この設定は、既定のビルトイン Administrator アカウントに UAC が適用されるかどうかを指定します。
注 |
|
ドメインに参加しているコンピュータでは、インストールとアップグレードに関して、ビルトイン Administrator アカウントは既定で無効にされています。 |
構成オプション :
-
有効 - ビルトイン Administrator は、管理者承認モードで管理者として実行されます。
-
無効 - 管理者は完全管理者アクセス トークンで実行されます。
既定値 :
-
コンピュータ上でビルトイン Administrator アカウントが、有効な唯一のローカル管理者ではない場合、新たなインストールとアップグレードに関しては、[無効] です。
-
コンピュータ上でビルトイン Administrator アカウントが、有効な唯一のローカル管理者であると Windows Vista が判断した場合、アップグレードに関しては、[有効] です。Windows Vista がこのように判断した場合、ビルトイン Administrator アカウントは、アップグレード後も有効のままです。
推奨事項 : 企業においては、この設定を無効に構成することをお勧めします。ドメイン管理者に依然として、このコンピュータに対する管理用のアクセス権があるからです。
ユーザー アカウント制御 : 管理者承認モードでの管理者に対する昇格時のプロンプトの動作
この設定は、UAC が管理者に昇格を要求する方法を指定します。
構成オプション :
-
確認のメッセージを表示しない - メッセージが表示されることなく自動的に昇格が行われます。このオプションでは、管理者承認モードの管理者が、昇格を要求する操作を同意も資格情報も必要とせずに実行することができます。注 : このシナリオを使用してもよいのは、制約が最も厳しい環境のみであり、使用はお勧めできません。
-
同意を要求する - 完全管理者アクセス トークンを要求する操作により、管理者承認モードの管理者は、[続行] か [キャンセル] のいずれかをクリックするよう要求されます。管理者が [続行] をクリックすると、最上位の特権で操作が続行されます。
-
資格情報を要求する - 完全管理者アクセス トークンを要求する操作により、管理者承認モードの管理者は、管理者のユーザー名とパスワードを入力するよう要求されます。ユーザーが有効な資格情報を入力すると、該当する特権で操作が続行されます。
既定値 : 同意を要求する
推奨事項 : この値を同意を要求するに設定することをお勧めします。攻撃者が昇格プロンプトを模倣 (なりすまし) する可能性があるからです。昇格プロンプトが模倣され、管理者が [続行] をクリックして同意した場合でも、攻撃者が行えるのは、単一プロセスの昇格のみです。ただし、設定が [資格情報を要求する] に構成されていたときに、昇格プロンプトが模倣されると、攻撃者は管理者のユーザー名とパスワードを入手することができます。
ユーザー アカウント制御 : 標準ユーザーに対する昇格時のプロンプトの動作
この設定は、UAC が管理者に昇格を要求するかどうか、およびその方法を指定します。
構成オプション :
-
確認のメッセージを表示しない - 昇格時のプロンプトは表示されず、ユーザーは [管理者として実行] を使用するか、管理者アカウントでログオンする場合に限り、管理タスクを実行することができます。
-
資格情報を要求する - 完全管理者アクセス トークンを要求する操作により、ユーザーは、管理者のユーザー名とパスワードを入力するよう要求されます。ユーザーが有効な資格情報を入力すると、該当する特権で操作が続行されます。
既定値 : 資格情報を要求する
推奨事項 : 標準ユーザー ユーザー デスクトップを現在使用している企業の場合、この設定を [確認のメッセージを表示しない] に構成することをお勧めします。この設定を使用することにより、ヘルプ デスクへのサポート コール数が減少します。
ユーザー アカウント制御 : アプリケーションのインストールを検出し、昇格をプロンプトする
この設定により、Windows Vista がヒューリスティクスを使用して、インストール アプリケーションを識別するかどうかが指定されます。ユーザーがインストーラを実行すると、Windows がそのプログラムをインストール アプリケーションとして識別し、ユーザーに昇格時のプロンプトを表示します。
構成オプション :
-
有効 - Windows Vista がインストーラを検出すると、ユーザーは同意または資格情報を要求されます。
-
無効 - アプリケーションのインストールは実行されません。ユーザーにその問題は通知されないか、またはエラー メッセージが表示されます。なお、このメッセージは意味が明確ではなく、インストールできなかった理由を判断するのには役に立たない可能性があります。
既定値 : 有効
推奨事項 : 標準ユーザー デスクトップを実行しており、GPSI や SMS などの委任型のインストール テクノロジを導入している企業の場合、この設定を [無効] に構成することをお勧めします。委任型のインストール テクノロジを導入していない場合、ヘルプ デスクへのサポート コール数を減少させるために、この設定を [有効] に構成することをお勧めします。または、この構成を [無効] に構成し、インストール ファイルを右クリックして [管理者として実行] をクリックし、インストール プロセスを昇格するようユーザーに伝えます。
ユーザー アカウント制御 : 署名され検証された実行ファイルのみを昇格する
この設定により、プログラムが昇格される前に署名されているかどうかを Windows Vista がチェックするかどうかが、指定されます。このチェックは、プロセスが対話的に起動された (つまり、ユーザーがデスクトップ上でインストール ファイルをダブルクリック) 後に実行されます。アプリケーションが未署名の場合、[ERROR MESSAGE]。アプリケーションが署名済みでも署名が無効の場合には、[ERROR MESSAGE]。
構成オプション :
-
有効 - 署名済みの実行可能ファイルのみ実行されます。このポリシーにより、昇格を要求するどの対話型アプリケーションに関しても、PKI 署名チェックが強制されます。
注 |
|---|
|
エンタープライズ管理者は、ローカル コンピュータの信頼された発行元ストアに証明書を追加することによって、管理アプリケーション許可リストを制御できます。 |
-
無効 - 署名済みと未署名のアプリケーションが実行されます。
既定値 : 無効
推奨事項 : [NEED]
ユーザー アカウント制御 : 安全な場所にインストールされている UIAccess アプリケーションの昇格のみ
この設定により、特権レベルが低いアプリケーションが、特権レベルが高いアプリケーションと通信できるかどうかが指定されます。uiAccess とは、アプリケーションのマニフェスト ファイル中の属性の 1 つです。開発者がアプリケーションと共にパッケージ化します。
構成オプション :
-
有効 - Program Files ディレクトリまたは Windows ディレクトリから実行されるアプリケーションが、Windows により、特権レベルの高いプロセスへのアクセスを禁止されます。ただし、アプリケーション マニフェストで uiAccess 属性が True に設定されている場合を除きます。Program Files と Windows の各ディレクトリの ACL は、既定では標準ユーザーがディレクトリの内容を変更できないよう構成されています。アプリケーションのマニフェスト ファイルで、アプリケーションが uiAccess アプリケーションと定義されていても、Program Files ディレクトリにも Windows ディレクトリにもない場合、Windows は特権レベルの高いプロセスにアクセスするための追加特権でそのアプリケーションを実行しません (たとえば、開発者がアプリケーションを uiAccess を要求するものと認識していたのに、標準ユーザーが変更できる、セキュリティで保護されていない場所にインストールされたケース)。
-
無効 - Windows はプログラムが Program Files ディレクトリまたは Windows ディレクトリにインストールされるかどうかを判断しません。アプリケーションはユーザーの承認がありしだい、ユーザーの完全管理者アクセス トークンで起動されます。
既定値 : 有効
推奨事項 : この設定を [有効] に構成することをお勧めします。この設定を有効にすると、セキュリティで保護されていない場所にインストールされた、特権レベルの低いアプリケーションは、Windows により特権レベルの高いアプリケーションへのアクセスを禁止されます。
ユーザー アカウント制御 : 管理者承認モードですべての管理者を実行する
この設定により、Windows が管理者のために 2 種類のアクセス トークン (標準ユーザー用と管理者用) を作成するかどうか、および標準ユーザーがアプリケーションを管理者レベルに昇格できるかどうかが指定されます。
注 この値を変更した場合には、コンピュータを再起動する必要があります。
構成オプション :
-
有効 - アプリケーションが管理者としての実行を試みると、管理者と標準ユーザーのいずれでもプロンプトが表示されます。[ユーザー アカウント制御 : 管理者承認モードでの管理者に対する昇格時のプロンプトの動作] の設定により、ユーザーにプロンプトが表示される方法が決まります。
-
無効 - アプリケーションが管理者としての実行を試みても、ユーザーにプロンプトは表示されません。アプリケーションはユーザーの完全管理者アクセス トークンで、自動的に実行されます。その結果、UAC は基本的に無効にされ、AIS サービスの自動的な開始は無効にされます。Windows セキュリティ センターもログオン ユーザーに、オペレーティング システムの全体的なセキュリティが低下していること、およびユーザーに UAC を有効にする能力が与えられることが通知されます。
既定値 : 有効
推奨事項 : この設定を [有効] に構成することをお勧めします。この設定が無効に設定されている場合、アプリケーション (悪意のあるソフトウェアを含む) が管理者として実行されても、管理者はそれに気付きません。標準ユーザーは、アプリケーションを管理者として実行できません。
ユーザー アカウント制御 : 昇格のプロンプト時にセキュリティで保護されたデスクトップに切り替える
この設定により、昇格時のプロンプトの表示先が、ユーザーのデスクトップなのか、それともセキュリティで保護されたデスクトップなのかが指定されます。
構成オプション :
-
有効 - UAC 昇格時のプロンプトは、セキュリティで保護されたデスクトップに表示されます。このデスクトップは Windows プロセスのメッセージのみ受け取ることができます。この設定が有効のときに、アプリケーションが管理者レベルの権利への昇格を要求した場合、デスクトップの背景がグレーアウトされ、昇格時のプロンプトがユーザーに表示されます。ユーザーは昇格の承認/拒否を行うまでは、デスクトップの他の要素を操作することはできません。同意プロンプトの場合には [続行] または [キャンセル] をクリックします。資格情報プロンプトの場合には、有効な管理者資格情報を提示するか、[キャンセル] をクリックします。
-
無効 - UAC 昇格時のプロンプトが、対話型の (ユーザー) デスクトップに表示されます。
既定値 : 有効
推奨事項 : この設定を [有効] に構成することをお勧めします。UAC 昇格時のプロンプトが、セキュリティで保護されたデスクトップに表示されない場合、攻撃者が悪意のあるソフトウェアを昇格するために、昇格時のプロンプトを模倣する可能性が潜在的にあります。この設定を、[ユーザー アカウント制御 : 管理者承認モードでの管理者に対する昇格時のプロンプトの動作] = [同意を要求する] の設定と組み合わせて使用することをお勧めします。この構成により、攻撃者が模倣した資格情報プロンプトを表示して、管理者の資格情報をできるだけ収集できないようにします。
ユーザー アカウント制御 : 各ユーザーの場所へのファイルまたはレジストリの書き込みエラーを仮想化する
この設定により、32 ビット アプリケーションの仮想化設定が指定されます。仮想化は 64 ビット アプリケーションには適用されません。
構成オプション :
-
有効 - マニフェスト ファイルのない 32 ビット アプリケーションが、Program Files ディレクトリなどの保護領域への書き込みを試みると、仮想化機能によりこれらの操作は、すべてのユーザーがアクセスできるファイル システムやレジストリの場所にリダイレクトされます。この設定により、標準ユーザーは、これまで管理者としてプログラムを実行するようユーザーに要求していた Windows Vista 以前のアプリケーションを実行できます。
-
無効 - マニフェスト ファイルのない 32 ビット アプリケーションが、Program Files ディレクトリなどの保護領域への書き込みを試みても、書き込みとアプリケーションの実行は行えず、メッセージも表示されません。
既定値 : 有効
推奨事項 : UAC と完全に互換性のないソフトウェアを実行する必要がある環境では、この設定を有効にしておいてください。マニフェスト ファイルもアプリケーション データベース エントリもないアプリケーションが、32 ビットの非管理アプリケーションである場合には、UAC 互換ではありません。多くの企業では、Windows Vista 以前のソフトウェアを実行する必要があり、したがって、この設定を [有効] に構成したままにしておく必要があります。
UAC グループ ポリシー設定の構成
次の手順を実行して、UAC グループ ポリシー設定を構成します。この手順を実行するには、ローカル管理者のグループのメンバとしてログインする必要があります。ユーザー アカウント制御の資格情報プロンプトで、管理者アカウントの有効な資格情報を提示できる場合には、標準ユーザーとしてこの手順を実行することもできます。
UAC グループ ポリシー設定を構成するには
-
[スタート] ボタンをクリックし、[検索の開始] ボックスに「secpol.msc」と入力して、Enter キーを押します。
-
[ユーザー アカウント制御] ダイアログ ボックスが表示された場合、このボックスに希望する動作が表示されていることを確認し、[継続] をクリックします。
-
[セキュリティの設定] で、[ローカル ポリシー] を展開し、[セキュリティ オプション] をクリックします。
-
[詳細] ウィンドウ (右側のウィンドウ) で、該当する UAC 設定を右クリックし、[プロパティ] をクリックします。
-
ドロップダウン リストボックスを使用して、設定に適切な値を選択します。
注 |
|
[ユーザー アカウント制御 : 管理者承認モードですべての管理者を実行する] の設定を変更すると、コンピュータの再起動後に、設定が有効になります。UAC グループ ポリシーのその他の設定はすべて、動的に反映されるので、再起動する必要はありません。 |
アプリケーション昇格とプロセス作成の監査
プロセス追跡の監査設定により、プロセスの昇格をリアルタイムで監視することができます。たとえば、IT 部門は、グループ ポリシーでプロセス追跡の監査を有効にして、監視者承認モードの管理者または標準ユーザーが、プロセスを完全管理者プロセスに昇格するたびに追跡することができます。
プロセス追跡を監査するには
-
[スタート] ボタンをクリックし、[検索の開始] ボックスに「secpol.msc」と入力して、Enter キーを押します。
-
[ユーザー アカウント制御] ダイアログ ボックスが表示された場合、このボックスに希望する動作が表示されていることを確認し、[継続] をクリックします。
-
コンソール ウィンドウで、[ローカル ポリシー] を展開し、[監査ポリシー] をクリックします。
-
[詳細] ウィンドウで、[プロセス追跡の監査] を右クリックし、[プロパティ] をクリックします。
-
[プロセス追跡の監査のプロパティ] で [成功] をクリックします。
特権使用の監査設定により、昇格されたプロセスの作成をリアルタイムで監視することができます。
特権使用を監査するには
-
[スタート] ボタンをクリックし、[検索の開始] ボックスに「secpol.msc」と入力して、Enter キーを押します。
-
[ユーザー アカウント制御] ダイアログ ボックスが表示された場合、このボックスに希望する動作が表示されていることを確認し、[継続] をクリックします。
-
コンソール ウィンドウで、[ローカル ポリシー] を展開し、[監査ポリシー] をクリックします。
-
[詳細] ウィンドウで、[特権使用の監査] を右クリックし、[プロパティ] をクリックします。
-
[特権使用の監査のプロパティ] で、[成功] をクリックし、[OK] をクリックします。
UAC サービス
UAC と関連付けられているサービスは、次のとおりです。
|
サービス
|
説明
|
|
アプリケーション情報サービス (AIS)
|
Windows Vista において、完全管理者アクセス トークンで行う対話型アプリケーションの実行を促進します。
このサービスを停止すると、目的のユーザー タスクの実行に要求される可能性がある追加の管理特権でアプリケーションを起動することができなくなります。その結果、アプリケーション情報サービスが実行されている限り、完全管理者アクセス トークンを要求するアプリケーションが正常に機能しなくなる可能性があります。
|
UAC のセキュリティに関する考慮事項
各 IT 部門は、UAC のセキュリティに関する考慮事項を慎重に検討する必要があります。UAC グループ ポリシー設定を使用すると、IT 部門は UAC の構成方法を選択することができますが、新しいセキュリティ ポリシーを作成する前に、検討する考慮事項がいくつかあります。
昇格時のプロンプトの模倣
Windows Vista には、昇格時のプロンプトの模倣を防止するための新しいセキュリティ設定が用意されています。この新しい設定 (ユーザー アカウント制御 : 昇格のプロンプト時にセキュリティで保護されたデスクトップに切り替える) により、プロセスが昇格を要求すると、アクティブなユーザー デスクトップが、セキュリティで保護されたデスクトップに切り替わります。セキュリティで保護されたデスクトップにアクセスできるのは、Windows のコア プロセスのみであるので、マルウェアはセキュリティで保護されたデスクトップと通信できません。その結果、セキュリティで保護されたデスクトップでの昇格時のプロンプトはいずれも、ユーザー デスクトップでのアプリケーションから制御できません。Windows Vista では既定で、昇格はすべてセキュリティで保護されたデスクトップで行われます。
ビルトイン Administrator アカウントのパスワードの設定
Windows Vista におけるビルトイン Administrator アカウントの状態の詳細について、次に示します。
-
コンピュータ上でビルトイン Administrator アカウントが、有効な唯一のローカル管理者ではない場合、新たなインストールとアップグレードに関しては、[無効] です。ドメインに参加しているコンピュータでは、インストールとアップグレードに関して、ビルトイン Administrator アカウントは既定で無効にされています。
-
コンピュータ上でビルトイン Administrator アカウントが、有効な唯一のローカル管理者であると Windows Vista が判断した場合、アップグレードに関しては、[有効] です。Windows Vista がこのように判断した場合、ビルトイン Administrator アカウントは、アップグレード後も有効のままです。ドメインに参加しているコンピュータでは、インストールとアップグレードに関して、ビルトイン Administrator アカウントは既定で無効にされています。
ビルトイン Administrator アカウントが無効にされた場合、パスワードを設定して、アカウントに対するオフライン攻撃を無効にすることを強くお勧めします。
UAC の無効化
[ユーザー アカウント制御 : 管理者承認モードですべての管理者を実行する] の設定を無効にすると、UAC が "オフ" になります。UAC との互換性のないアプリケーションの場合、ファイルとフォルダはもはや各ユーザーの場所に仮想化されません。ローカル管理者はすべて、完全管理者アクセス トークンで自動的にログインされます。この設定を無効にすると、Windows Vista は Windows XP ユーザー モデルに戻ります。UAC との互換性のないアプリケーションの中には、UAC を無効にすることを推奨するものもありますが、必ずしもそうする必要はありません。Windows Vista には、Windows Vista 以前のアプリケーションまたはUAC との互換性のないアプリケーションに対するフォルダとレジストリの仮想化機能が、既定で搭載されているからです。UAC を無効にすると、マルウェアがシステム全体にインストールされてしまう危険にコンピュータをさらすことになります。この設定を変更した場合、反映するには、システムを再起動する必要があります。
使用されていない UAC グループ ポリシー設定の無効化
仮想化を無効にする必要がある場合
仮想化は、UAC 互換ではないアプリケーションが、Windows Vista で正常に機能できるようにするための橋渡しテクノロジとして設計されています。IT 部門が社内で UAC 互換アプリケーションのみ実行されることを知っている場合、"ユーザー アカウント制御 : 各ユーザーの場所へのファイルまたはレジストリの書き込みエラーを仮想化する" グループ ポリシーの設定は、無関係なものとなります。
インストーラの検出を無効にする必要がある場合
インストーラは保護領域 (Program Files ディレクトリなど) に書き込むので、Win32 モデルではインストーラを管理コンテキストで実行することが要求されます。[ユーザー アカウント制御 : アプリケーションのインストールを検出し、昇格をプロンプトする] の設定により、インストーラが検出されると、昇格時のプロンプトが呼び出されます。ロックダウンされたデスクトップがある企業では、アプリケーションがすべて SMS や同様のテクノロジで展開された場合、インストール時の昇格は不要です。昇格はインストーラ サービスにより自動的に行われるからです。このサービスは SYSTEM として実行されます。
リモート コンピュータでの管理タスク
ドメイン管理者グループ、または別の同様な特権ネットワーク グループのメンバであるユーザーは、管理タスクを実行する際に、その管理者が有効なアカウントのみを使用する必要があります。次のシナリオでは、この点を深く掘り下げます。
Litware, Inc のヘルプ デスク技術者のキャロル フィリップスは、ドメイン管理者アカウントと標準ドメイン ユーザー アカウントという 2 つのドメイン ユーザー アカウントを持っています。ドメイン管理者アカウントは、ワークステーションのローカル Administrators グループのメンバです。キャロルは、完全管理者アクセス トークンを要求するタスクを実行するときには、ドメイン管理者アカウントのみを使用するように上司から言われています。その結果、キャロルは管理タスクを実行する必要があるときには、[別のユーザーとして実行] かターミナル サービスのいずれかを使用して、自分のワークステーションにログオンします。ある日のこと、キャロルは自分のコンピュータのハード ディスクを、しばらくバックアップしていなかったことに気付きます。そこで彼女は、[別のユーザーとして実行] を使用してコマンド プロンプトを開き、自分の管理者アカウントの資格情報を入力します。次に、コマンド プロンプトで「secedit」と入力して、Enter キーを押します。同時に、標準ユーザーとして Web を閲覧して、誤ってマルウェアをダウンロードしてしまいます。しかし、このマルウェアがネットワーク上の他のコンピュータに影響を及ぼすことはできません。キャロルは標準ユーザー アカウントで、インターネットを閲覧していたからです。
UAC との互換性確保のための、Windows Vista 以前のアプリケーションの構成
UAC の構成における最後の、しかし最も重要な段階は、使用するソフトウェアが UAC 互換となるよう設計されたのか、それとも Windows Vista で正常に機能できるよう IT 部門により構成されているのかどうかを確認することです。
Windows Vista ロゴ互換の新しいアプリケーションの場合、そのアプリケーションを標準ユーザー アカウントで実行するか、または管理アプリケーションの場合には、アプリケーション マニフェスト エントリでマークする必要があります。ユーザーがアプリケーション マニフェスト エントリのあるアプリケーションの起動を試みると、管理アプリケーションを起動しようとしているので、承認する必要があることが、Windows Vista からユーザーに知らされます。マイクロソフトのロゴ プログラムの詳細については、Microsoft Windows ロゴのホーム ページ (http://go.microsoft.com/fwlink/?LinkId=71358) (英語ページの可能性があります) にアクセスしてください。
Windows Vista の展開時に、既存の基幹業務 (LOB) アプリケーションが正常に機能していないことに IT 部門が気付くことがあります。この問題の原因は、多くの場合、Windows Vista に搭載された強化機能との互換性がアプリケーションにないことです。マイクロソフトでは、Application Compatibility Toolkit を提供しています。このツールキットは、IT 部門が互換性の問題を特定し、アプリケーション互換性修正プログラム (アプリケーションの互換性に関する問題を解決するための少量のコード) を作成するのに役立ちます。
プログラムの中には、Windows Vista で正常に機能するには管理操作を実行できなければならないものもあることに IT 部門が気付くことがあります。そのために、プログラムが完全管理者アクセス トークンで実行できるようになる前に、ユーザーに承認を求めるプロンプトが表示されるよう、そのプログラムをマークする必要があります。アプリケーションをこのようにマークするプロセスを、"アプリケーションを要求実行レベルでマークする" といいます。Application Compatibility Toolkit 5.0 を使用すると、アプリケーション互換性データベース エントリの構築とインストールを行うための手段が得られます。これにより、要求実行レベルのマークのしくみが強化されます。
アプリケーションの互換性および Application Compatibility Toolkit 5.0 の詳細については、TechNet (http://go.microsoft.com/fwlink/?LinkId=23302) (英語ページの可能性があります) にアクセスしてください。
アプリケーション互換性のための、要求実行レベルでのアプリケーションのマーク
アプリケーションのためにどの要求実行レベルが選択されるのかは、アプリケーションが実行するシステムレベルの操作の種類で決まります。選択できる 3 種類の要求実行レベルを次に示します。
RunAsInvoker : アプリケーションを親プロセスと同じ Windows 特権とユーザー権利で実行する必要があります。この設定は、アプリケーションの互換性データベースがないことに相当します。アプリケーションは、起動元の親プロセスと同じ特権で起動されます。これにより、アプリケーションがセキュリティの脅威にさらされる可能性は減少します。なぜなら、大半のアプリケーションでは、親プロセスは Explorer.exe であり、これは標準ユーザー アプリケーションとして実行されるからです。完全な管理者として実行される cmd.exe シェルから起動される RunAsInvoker アプリケーションは、完全管理者アクセス トークンで "起動者として実行" されます。
RunAsHighest :
-
アプリケーションを現在のユーザーが取得できる最上位の Windows 特権とユーザー権利で実行する必要があります。ただし、ユーザーは必ずしも管理者である必要はありません。このマークは、2 クラスのアプリケーションに使用されます。
-
アプリケーションは管理者と標準ユーザーのどちらでも実行できます。ユーザーの特権と権利に応じて、動作が変化します。
-
アプリケーションは、標準ユーザーのものより高い特権とユーザー権利を要求します。しかし、ユーザーはローカル Administrators グループのメンバである必要はありません。ユーザーの例としては、Backup Operators グループのメンバがあります。このクラスのユーザーは、完全管理者アクセス トークンを要求するアプリケーションは実行できませんが、バックアップ アプリケーションは実行できます。この場合、Windows Vista 以前のバックアップ アプリケーションを RunAsHighest としてマークする必要があります。
RunAsAdmin : このアプリケーションは管理者のためにのみ実行し、完全管理者アクセス トークンで起動する必要があります。標準ユーザー コンテキストでは正常に実行されません。この要求実行レベルのマークは、ユーザーがローカル Administrators グループのメンバであることを要求する Windows Vista 以前のアプリケーション用に予約されています。Windows Vista とそれ以前のバージョンの Windows (Windows XP など) の違いの 1 つは、アプリケーションがアプリケーション互換性データベースで RunAsAdmin とマークされている場合、完全管理者アクセス トークンで実行されることについて、オペレーティング システムが責任を持つ点です。Windows Vista が管理者アクセス トークンを取得できない場合、アプリケーションは起動されません。
仮想化のマーク
IT 部門は次の設定を使用して、ファイルとフォルダの仮想化を管理することができます。
NoVirtualization : アプリケーションをファイルとフォルダの仮想化を行わずに実行する必要があります。NoVirtualization を設定する理由は、次の 2 つです。
-
攻撃を受ける可能性の低下。仮想化を許可したアプリケーションは、他の標準ユーザー アプリケーションから攻撃を受ける可能性があります。Windows Vista には、特定の仮想場所への書き込みを許可されたアプリケーションどうしを区別するしくみは、ありません。標準ユーザーとして実行されるアプリケーションでの仮想化を無効にすることにより、(標準ユーザーとして実行される) マルウェアがアプリケーションを攻撃する危険性は大幅に低下します。
-
仮想化されたデータのデバッグを行うヘルプデスクの時間の短縮とコストの削減。アプリケーションが標準ユーザー アプリケーションとして正常に機能しているとわかっている場合、仮想化を無効にすると、ヘルプデスク担当者がアプリケーションのデバッグを行いやすくなります。これは、実際の場所と仮想化された場所の両方を確認して、アプリケーションの構成データを調べる必要がなくなるからです。
アプリケーション互換性データベースとアプリケーション起動の動作
アプリケーションを実行して、実行時に完全管理者アクセス トークンを取得できるかどうかは、アプリケーション互換性データベースに登録されたアプリケーションの要求実行レベルと、そのアプリケーションを起動したユーザー アカウントで使用できる特権とユーザー権利との組み合わせで決まります。可能な組み合わせに基づく実行時の動作を、次の表に示します。
管理者承認モードの管理者
|
親プロセス アクセス トークン
|
同意ポリシー
|
なし、または RunAsInvoker
|
RunAsHighest
|
RunAsAdmin
|
|
標準ユーザー
|
確認のメッセージを表示しない
|
アプリケーションは標準ユーザーとして起動されます。
|
アプリケーションは完全管理者アクセス トークンで起動されます。確認のメッセージを表示しない。
|
アプリケーションは完全管理者アクセス トークンで起動されます。確認のメッセージを表示しない。
|
|
標準ユーザー
|
同意を要求する
|
アプリケーションは標準ユーザーとして起動されます。
|
アプリケーションは完全管理者アクセス トークンで起動されます。同意を要求する。
|
アプリケーションは完全管理者アクセス トークンで起動されます。同意を要求する。
|
|
標準ユーザー
|
資格情報を要求する
|
アプリケーションは標準ユーザーとして起動されます。
|
アプリケーションは完全管理者アクセス トークンで起動されます。資格情報を要求する。
|
アプリケーションは完全管理者アクセス トークンで起動されます。資格情報を要求する。
|
|
管理者 (UAC 無効)
|
該当なし
|
アプリケーションは完全管理者アクセス トークンで起動されます。確認のメッセージを表示しない。
|
アプリケーションは完全管理者アクセス トークンで起動されます。確認のメッセージを表示しない。
|
アプリケーションは完全管理者アクセス トークンで起動されます。確認のメッセージを表示しない。
|
標準ユーザー アカウント
|
親プロセス アクセス トークン
|
同意ポリシー
|
RunAsInvoker
|
RunAsHighest
|
RunAsAdmin
|
|
標準ユーザー
|
確認のメッセージを表示しない
|
アプリケーションは標準ユーザーとして起動されます。
|
アプリケーションは標準ユーザーとして起動されます。
|
アプリケーションは起動できません。
|
|
標準ユーザー
|
資格情報を要求する
|
アプリケーションは標準ユーザーとして起動されます。
|
アプリケーションは標準ユーザーとして起動されます。
|
アプリケーションを実行する前に、管理者資格情報を要求します。
|
|
標準ユーザー (UAC 無効)
|
該当なし
|
アプリケーションは標準ユーザーとして起動されます。
|
アプリケーションは標準ユーザーとして起動されます。
|
アプリケーションは起動できません。
|
追加特権のある標準ユーザー (Backup Operator など)
|
親プロセス アクセス トークン
|
同意ポリシー
|
RunAsInvoker
|
RunAsHighest
|
RunAsAdmin
|
|
標準ユーザー
|
確認のメッセージを表示しない
|
アプリケーションは標準ユーザーとして起動されます。
|
アプリケーションは標準ユーザーとして起動されます。
|
アプリケーションは起動できません。
|
|
標準ユーザー
|
資格情報を要求する
|
アプリケーションは標準ユーザーとして起動されます。
|
アプリケーションは標準ユーザーとして起動されます。
|
アプリケーションを実行する前に、管理者資格情報を要求します。
|
|
標準ユーザー (UAC 無効)
|
該当なし
|
アプリケーションは標準ユーザーとして起動されます。
|
アプリケーションは標準ユーザーとして起動されます。
|
アプリケーションは起動できません。
|
Application Compatibility Toolkit 5.0 を使用したアプリケーションの修正プログラムの作成
Application Compatibility Toolkit 5.0 は、マイクロソフトが公開した無料アプリケーションのスイートです。IT 部門はこれを使用して、アプリケーションの互換性の問題を解決する修正プログラムを作成することができます。Application Compatibility Toolkit には、アプリケーション互換性修正プログラムのデータベース エントリを作成する機能が用意されており、Windows Vista 向けに強化されています。このエントリを使用して、アプリケーションを要求実行レベルでマークします。
ここで説明する手順では、次の 3 つのツールを使用します。これらは Application Compatibility Toolkit 5.0 ダウンロードに含まれています。
-
Compatibility Administrator : エンタープライズ管理者が Windows Vista 以前のアプリケーション用のプログラム互換性修正プログラムを作成する作業を支援するグラフィカル ユーザー インターフェイス ツール。
-
Sdbinst.exe : 管理者が Windows Vista 以前のアプリケーション用のプログラム互換性修正プログラムをインストールする作業を支援するコマンドライン ツール。
-
Standard User Analyzer : エンタープライズ管理者が互換性の問題のあるアプリケーションを特定する作業を支援するグラフィカル ユーザー インターフェイス ツール。
次のワークフローを使用して、アプリケーションの管理依存性を特定し、アプリケーションを要求実行レベルでマークします。
注 |
|
アプリケーションの適切なマークの詳細については、このドキュメントの「アプリケーション互換性のための、要求実行レベルでのアプリケーションのマーク」を参照してください。 |
手順 1 : アプリケーション検証ツールをインストールします。
アプリケーション検証ツールは、マイクロソフトの Web サイト (http://go.microsoft.com/fwlink/?LinkId=41326) (英語ページの可能性があります) から無料で入手できます。アプリケーション検証ツールは、Microsoft Standard User Analyzer をインストールするための前提条件となります。このツールは、Application Compatibility Toolkit に含まれています。
手順 2 : Application Compatibility Toolkit 5.0 をインストールします。
手順 3 : Standard User Analyzer を使用して、Windows Vista では正常に実行できない Windows Vista 以前の管理アプリケーションを特定します。
次に示す手順で、Standard User Analyzer を使用して、Windows Vista では正常に実行できない Windows Vista 以前の管理アプリケーションを特定します。
Windows Vista 以前のアプリケーション互換性の問題を特定するには
-
Windows Vista コンピュータに標準ユーザーとしてログオンします。
-
[スタート] ボタン、[すべてのプログラム]、[Microsoft Application Compatibility Toolkit 5.0]、[Developer and Tester Tools]、[Standard User Analyzer] の順にクリックします。
-
[Standard User Analyzer] の [Target Application] で、テストするアプリケーションのフル ディレクトリ パスを指定するか、[Browse] をクリックして、Windows Explorer でプログラムの実行可能ファイルを見つけます。
-
[Launch] をクリックし、[ユーザー アクセス制御] の資格情報プロンプトで、管理者の資格情報を提示します。
-
テスト アプリケーションが起動したら、一般的な管理者タスクを実行し、完了後にアプリケーションを閉じます。
-
[Standard User Analyzer] で、各タブに記述されている結果を調べます。このデータを使用して、プログラムに存在する可能性がある互換性の問題を特定します。
難しい特権エラーの場合に、アプリケーション検証テストを管理者として実行することもできます。たとえば、アプリケーションを非管理者として実行しているときに、アクセス違反が発生し、アプリケーションが終了したとします。このとき、コード パスをテストできるのは、アクセス違反の箇所までです。しかし、同じアプリケーションを管理者として実行すると、アクセス違反の箇所を通過し、残りのコード パスを実行することができる場合もあります。標準ユーザーなら通常はできないようなこれらの操作も、ログを調べて確認できます。
手順 4 : 各アプリケーションの要求実行レベルを判断します。
手順 3. で収集したデータを使用して、アプリケーションの正しい要求実行レベルを判断します。
注 |
|
このアプリケーションにふさわしい要求実行レベルを判断するには、「要求実行レベルでのアプリケーションのマーク」を参照してください。 |
重要 |
|
アプリケーションを Windows Vista で正常に実行できるようにする要求実行レベルのみを指定します。要求実行レベルがより上位の、不必要な管理者アクセス権を要求することは避けます。 |
アプリケーション検証ツールで互換性の問題を特定した後は、次の手順でアプリケーションを要求実行レベルでマークします。
手順 5 : Compatibility Administrator プログラムを実行して、アプリケーション互換性修正プログラムのデータベースを作成します。
この手順は、[ユーザー アカウント制御 : 管理者承認モードでの管理者に対する昇格時のプロンプトの動作] の設定を [同意を要求する] に構成したものとして記述されています。
管理アプリケーションを Compatibility Administrator でマークするには
-
管理者承認モードの管理者として、Windows Vista コンピュータにログオンします。
-
[スタート] ボタン、[すべてのプログラム]、[アクセサリ] の順にクリックし、[コマンド プロンプト] を右クリックして、[管理者として実行] をクリックします。ユーザー アカウント制御の昇格時のプロンプトで、[続行] をクリックします。
-
[コマンド プロンプト] で、「C:\program files\Microsoft Application Compatibility Toolkit\Compatibility Administrator\Compatadmin.exe」と入力し、Enter キーを押します。
-
[Compatibility Administrator] で、[Fix] アイコンをクリックします。
-
[Create new Application Fix] ページの [Program information] で、[Name of the program to be fixed] にプログラム名、[Name of the vendor for this program] にベンダ名、[Program file location] にプログラム ファイルの場所を入力し、[Next] をクリックします。
-
[Compatibility Modes] で、[None] をクリックし、[Next] をクリックします。
-
[Compatibility Fixes] では、目的の要求実行レベルを選択し、[Next] をクリックします。
-
[Matching Information] で、アプリケーションの対応付け情報を選択し、[Finish] をクリックします。
-
[File] メニューの [Save] をクリックします。
-
アプリケーション互換性データベースの名前を入力し、[OK] をクリックします。
-
[SavedatabaseName] で、データベース ファイルの名前を選択し、[Save] をクリックします。
注 |
|
[Create New Application Fix] ウィザードの [Matching Information] ページで、SIZE と PE_CHECKSUM を選択すると、アプリケーションの修正プログラムが、目的とするアプリケーションと名前が同じ他のアプリケーションに誤って適用されることを確実に防ぐことができます。 |
注 |
|
アプリケーション互換性修正プログラムの特定に役立つように、わかりやすい名前を選択します。ここで付けられた名前は、アプリケーション互換性修正プログラムが sdbinst.exe コマンドライン ツールでインストールされた後に、[コントロール パネル] の [プログラムと機能] に表示されます。 |
注 |
|
作成された各アプリケーション互換性データベースに、目的とするアプリケーション互換性修正プログラムを 1 つ以上登録することができます。 |
手順 6 : アプリケーション互換性修正プログラムを sdbinst.exe コマンドでテスト コンピュータにインストールします。
アプリケーション互換性修正プログラムをインストールするには
-
[スタート] ボタン、[すべてのプログラム]、[アクセサリ] の順にクリックし、[コマンド プロンプト] を右クリックして、[管理者として実行] を選択します。[ユーザー アカウント制御] の同意プロンプトで、[続行] をクリックします。
-
[コマンド プロンプト] で、「cd %windir%」と入力し、Enter キーを押します。
-
[コマンド プロンプト] で、「sdbinst.exe databaseName.sdb」と入力し、Enter キーを押します。
アプリケーション互換性データベースの修正プログラムの削除
管理者は、[コントロール パネル] の [プログラムと機能] を使用して、以前にインストールしたアプリケーション互換性データベースのエントリを削除することができます。アプリケーション互換性データベースのエントリを削除することは、アプリケーションがもはやその環境で使用されていないのに修正プログラムが残っている場合や、アプリケーション互換性修正プログラム自体に修正が必要な場合に役立ちます。
アプリケーション互換性修正プログラムを削除するには
-
管理者承認モードの管理者として、Windows Vista コンピュータにログオンします。
-
[コントロール パネル ホーム] の [プログラム] で、[プログラムのアンインストール] をクリックします。次に、[ユーザー アカウント制御] の同意プロンプトで [続行] をクリックします。
-
アプリケーション互換性修正プログラムを右クリックし、[削除] をクリックします。
グループ ポリシーによるアプリケーション互換性修正プログラムの展開
ここでは、compatAdmin.exe の実行手順で作成したアプリケーション互換性データベースの修正プログラムを、グループ ポリシーを使用して展開する方法を説明します。IT 部門は次に示す手順を実行することができます。
-
カスタム インストーラの Microsoft Visual Basic スクリプト (VBScript) を作成します。
-
各 .sdb データベースの Windows インストーラ パッケージを作成します。
-
作成した Windows インストーラ パッケージに Authenticode 署名します。
-
Windows インストーラ パッケージをテストします。
-
Windows インストーラ パッケージをグループ ポリシーで展開します。
カスタム インストーラの Microsoft Visual Basic スクリプト (VBScript) の作成
Windows インストーラ パッケージを作成する前に、IT 部門はカスタム インストールを行う VBScript を作成する必要があります。このプロセスは一度行えばよく、同じスクリプト ファイルを他のすべての Windows インストーラ パッケージに再利用することができます。
次に、サンプル スクリプトを示します。
'-------------------------------------------------------------------------------------- ' Filename :setsdb.vbs ' Description :Installs SDB entry in appcompat database ' Version :1.0 '-------------------------------------------------------------------------------------- ' History:' 07-19-2005: Created version 1.0 dim Ws
myCmdArgs = Session.Property("CustomActionData") setDir = "%ComSpec% /C sdbinst.exe -q " & chr(34) & myCmdArgs & chr(34) set Ws = CreateObject("WScript.Shell") retval = Ws.Run( setDir, 2, true )
Visual Studio 2005 での、各 .sdb データベースの Windows インストーラ パッケージの作成
次の例は、Windows インストーラ パッケージを作成し、Microsoft Visual Studio 2005 を使用して、アプリケーション互換性修正プログラム方法を展開する方法を示します。
Windows インストーラ パッケージを作成するには
-
[スタート] ボタン、[すべてのプログラム] の順にクリックし、[Visual Studio 2005] をダブルクリックします。
-
Visual Studio で、[ファイル] メニューの [新しいプロジェクト] をクリックします。
-
[新しいプロジェクト] ページで、[その他のプロジェクトの種類] を展開し、左側のウィンドウにある [セットアップ/配置プロジェクト] をクリックします。右側のウィンドウにある [セットアップ プロジェクト] をクリックし、アプリケーション互換性修正プログラムの展開の名前を入力して、[OK] をクリックします。
-
右側のウィンドウにある [ソリューション エクスプローラ] で、展開プロジェクトの名前を右クリックし、[追加] をポイントして [ファイル] をクリックします。
-
[ファイルの追加] で、.sdb データベース ファイルの場所を参照して、[開く] をクリックします。
-
手順 4. と 5. を繰り返して、以前に作成したカスタム動作 VBScript の名前を追加します。
-
右側のウィンドウにある [ソリューション エクスプローラ] で、展開プロジェクトの名前を右クリックし、[表示] をポイントして [カスタム動作] をクリックします。
-
[カスタム動作] タブで [確定] フォルダを右クリックし、[カスタム動作の追加] をクリックします。
-
[プロジェクトから項目を選択] で、[アプリケーション] フォルダをダブルクリックし、目的の VBScript ファイルを選択して [OK] をクリックします。
-
左側のウィンドウにある setsdb.vbs という名前の確定動作を右クリックし、[プロパティ ウィンドウ] をクリックします。
-
次に示す行を [CustomActionData] プロパティに追加します。[ProgramFilesFolder][Manufacturer]\[ProductName]\[FILENAME].sdb
注 |
|
[ProgramFilesFolder] と [Manufacturer] との間には、円記号 (\) はありません。 |
-
[ファイル] メニューの [ビルド] をクリックし、[ソリューションのビルド] をクリックします。ビルドが完了すると、Windows インストーラ パッケージがデバッグ フォルダに追加されます。
作成した Windows インストーラ パッケージへの Authenticode 署名
IT 部門が Windows インストーラ パッケージを作成したら、Authenticode 署名してから、グループ ポリシーを使用して展開することをお勧めします。このドキュメントでは、展開する Windows インストーラ パッケージの署名に使用する自社の署名キーを、IT 部門が作成済みであることを前提としています。以降の例で使用されている署名ツールと検証ツールは、Microsoft .NET Framework SDK (http://go.microsoft.com/fwlink/?LinkId=32131) (英語ページの可能性があります) に含まれています。
Windows インストーラ パッケージを企業の署名キーで署名する方法の例を、次に示します。
signcode –v <path>yourkey.pvk –spc <path>yourkey.spc (deployment package).msi
署名にタイムスタンプを含めるには、コマンドラインで次のパラメータを含めます。
–t http://timestamp.verisign.com/scripts/timstamp.dll
署名は次のコマンドで検証できます。
ckhtrust (deployment package).msi
ファイルの正当性が証明され、署名証明書が自社環境で信頼済みの発行元証明書にチェーンしている場合、chktrust.exe が成功のリターン コードを返すだけです。
Microsoft Authenticode テクノロジの追加情報については、MSDN (http://go.microsoft.com/fwlink/?LinkId=71361) (英語ページの可能性があります) で確認することができます。
Windows インストーラ パッケージのテスト
Windows インストーラ パッケージの作成が完了したら、テストすることができます。そのためには、Windows インストーラ ファイルをテスト用コンピュータにコピーし、ダブルクリックして Microsoft Windows セットアップ ウィザードを開きます。Windows インストーラ パッケージのテスト方法の例を、次に示します。
Windows インストーラ パッケージをテストするには
-
Windows インストーラ (.msi) ファイルを見つけ、ダブルクリックしてセットアップを開始します。
-
[[NameofWindowsInstallerPackage] インストール先フォルダの選択] ページで、インストール先フォルダを選択し、[次へ] をクリックします。
-
[インストールの確認] ページで、[次へ] をクリックします。
-
[インストールの完了] ページで、[閉じる] をクリックします。
-
[スタート] ボタン、[コントロール パネル] の順にクリックし、[プログラムと機能] をダブルクリックします。
-
[プログラムと機能] コントロール パネルで、アプリケーション互換性修正プログラムのインストーラとエントリが存在することを確認します。
グループ ポリシーによる Windows インストーラ パッケージの展開
グループ ポリシーを使用することにより、IT 部門は、作成したどのアプリケーション互換性修正プログラムも、クライアント コンピュータに自動的に展開することができます。ここでは、IT 部門がこの展開をセットアップする際に使用できる基本的な手順を説明します。グループ ポリシー展開の計画の追加情報については、TechNet (http://go.microsoft.com/fwlink/?LinkId=71349) (英語ページの可能性があります) で確認することができます。
最初の手順は、Windows インストーラ展開パッケージを、修正プログラムを受け取る必要があるすべてのコンピュータからアクセスできるファイル共有に置くことです。これは、ドメイン全体でも、組織単位 (OU) 限定でもかまいません。Windows インストーラ パッケージに、適切なアクセス制御リスト (ACL) のエントリをファイル共有に持たせて、該当するコンピュータのみアクセスできるようにすることをお勧めします。
Windows インストーラ ファイルを適切に配置したら、次に示す手順を実行します。この手順を実行するには、Domain Administrator としてログインする必要があります。
Active Directory へのグループ ポリシーの追加
-
[スタート] ボタンをクリックし、[すべてのプログラム]、[管理ツール] の順にポイントし、[Active Directory ユーザーとコンピュータ] をクリックします。
-
コンソール (左側) ウィンドウで、ドメイン名を右クリックし、[プロパティ] をクリックします。
-
[プロパティ] ページで、[グループ ポリシー] タブをクリックします。
-
[グループ ポリシー] タブで、[新規] をクリックし、新しいグループ ポリシー オブジェクト (GPO) の名前を入力します。
-
新規作成した GPO を強調表示し、[プロパティ] をクリックします。
-
アプリケーション互換性修正プログラムを、ユーザーではなくドメイン内のコンピュータに適用しているので、[ユーザーの構成の設定を無効にする] チェック ボックスをオンにします。確認のダイアログ ボックスが表示されたら [はい] をクリックします。
-
[セキュリティ] タブをクリックし、必要な ACL をいくつでも追加して、ドメインのコンピュータにアクセスを許可します。[読み取り] と [グループ ポリシーの適用] が選択されていることを確認し、[OK] をクリックします。
-
[プロパティ] ページで、[編集] をクリックします。
-
[グループ ポリシー オブジェクト エディタ] の [コンソール] ウィンドウで、[コンピュータの構成]、[ソフトウェアの設定] の順に展開します。
-
[詳細] ウィンドウで、[ソフトウェア インストール] を右クリックし、[新規作成] をクリックして、[パッケージ] をクリックします。
-
[ファイルを開く] ダイアログ ボックスで、展開するパッケージを選択し、[開く] をクリックします。
-
[ソフトウェアの展開] で、[割り当て] をクリックし、[OK] をクリックします。
-
[グループ ポリシー オブジェクト エディタ] を閉じます。
-
[プロパティ] ページを閉じます。
-
[Active Directory ユーザーとコンピュータ] を終了します。
注 |
|
前の手順 12. により、パッケージがユーザーとの対話を必要とせずに、目的とするコンピュータにインストールされます。すると、選択された Windows インストーラ パッケージが、グループ ポリシー オブジェクト エディタに表示されます。 |
Windows インストーラ展開のテストと確認
Windows インストーラ展開をテストするには、次の手順を実行します。
Windows インストーラ展開をテストするには
-
ドメインに参加している任意のコンピュータを再起動します。
-
ユーザーのログイン画面が表示される前に、グループ ポリシーにより、Windows インストーラ パッケージがコンピュータに自動的にインストールされます。
Windows インストーラ展開を確認するには、次の手順を実行します。
Windows インストーラ展開を確認するには
-
管理者承認モードの管理者として、前の手順で使用したコンピュータにログオンします。
-
[スタート] ボタン、[コントロール パネル] の順にクリックします。
-
[コントロール パネル ホーム] で、[プログラム]、[インストールされているプログラム] の順にクリックします。
-
[プログラムの変更と削除] で、Windows インストーラ パッケージとアプリケーション互換性データベースのエントリがインストールされていることを確認します。
まとめ
アプリケーションがオペレーティング システムとそのファイルと対話する方法を根本的に変更することにより、UAC はコンピュータのセキュリティを向上させるための新しいアプローチを提供します。マイクロソフトは開発者と協同して、マルウェアの影響を最小限に抑えるテクノロジを引き続き開発し、作成しています。UAC を有効にし、Windows を標準ユーザーとして使用することにより、組織とエンド ユーザーは、システムを危険にさらすセキュリティ上の脆弱性から被害を受ける可能性を大幅に低下させることができます。Windows Vista のリリースに合わせて、マイクロソフトでは、アプリケーションを標準ユーザー モードで実行するためのしくみ、および通常は完全管理者アクセス トークンを要求するオペレーティング システムの一般的な構成タスクを実行するためのしくみを開発しました。
フィードバック
UAC の詳細情報の入手