ゲーム開発者向けユーザー アカウント制御
この記事では、ゲーム開発者が Windows Vista で導入されたユーザー アカウント制御 (UAC) セキュリティ機能を効果的に操作するためのガイドラインとベスト プラクティスについて説明します。
- ユーザー アカウント制御の概要
- Windows Vista のユーザー アカウント
- 標準ユーザーとしてのファイル アクセス
- 標準ユーザーとしてのレジストリ アクセス
- 特権の昇格
- CreateProcess() による UAC の影響
- アプリケーション マニフェストでの実行レベルの設定
- Visual Studio でのマニフェストの埋め込み
- UAC と古いゲームの互換性
- 従来のシナリオとマニフェスト
- まとめ
- もっと読む
ユーザー アカウント制御の概要
Windows Vista で導入されたユーザー アカウント制御 (UAC) は、悪意のある攻撃者が、広く使用されているアプリケーションで見つかった弱点やバグを使用してオペレーティング システムやその他のインストールされているプログラムを変更するのを防ぐのに役立つセキュリティ機能です。 これは、現在のユーザーのアカウントに管理者資格情報がある場合でも、プログラムとプロセスの大部分を標準ユーザー (制限付きユーザー、制限付きユーザー、またはLeast-Privileged ユーザーとも呼ばれます) として実行することによって実現されます。 標準ユーザー特権を持つプロセスには、システム全体の変更を行うことを妨げる多くの固有の制限があります。
UAC は、管理者特権を必要とするように指定された特定のプロセスの実行時に開始されるダイアログ ベースの認証スキームを使用して、プロセスの特権昇格も担当します。 特権の昇格により、管理者はアプリケーションの大部分を安全な特権レベル (他の標準ユーザーと同じ) で実行できますが、管理者特権を必要とするプロセスと操作も許可されます。 UAC では、管理者が標準ユーザーがシステムにログオンしている間に、管理者がプログラムに昇格された特権を付与できるように、肩越し認証がサポートされています。
UAC 機能は既定で有効になっています。 管理者が UAC をシステム全体で無効にすることは可能ですが、これを行うと、多くの悪影響が発生します。 まず、ほとんどのアプリケーションで実際に必要とされない場合でも、すべてのプロセスが管理資格情報で実行されるので、すべての管理アカウントのセキュリティが低下します。 UAC を無効にすると、セキュリティの悪用可能な脆弱性を公開する標準ユーザー アプリケーションを使用して、個人情報の盗用、ルートキットやスパイウェアのインストール、システムの整合性の破壊、他のシステムに対するゾンビ攻撃のホストを行う可能性があります。 UAC を有効にすると、ソフトウェアの大部分を標準ユーザーとして実行すると、このようなバグによる潜在的な損害が大幅に制限されます。 次に、UAC をオフにすると、真の標準ユーザーが幅広いアプリケーションを正常に実行できるようにする、アプリケーションの互換性に関する回避策の多くが無効になります。 UAC を無効にすることは、互換性の回避策として推奨されるべきではありません。
アプリケーションでは、可能な限り標準のユーザー権限のみを使用するように努める必要があることに注意してください。 管理者はプロセスの特権を簡単に昇格できますが、昇格には、管理者資格情報を必要とするアプリケーションが実行されるたびにユーザーの操作と確認が必要です。 この昇格は、プログラムの起動時にも実行する必要があるため、1 回の操作でも管理者資格情報を要求するには、アプリケーションの実行時間全体のリスクが高いシステムを公開する必要があります。 特権を昇格させる機能を持たない標準ユーザーは、家族やビジネスの設定でも一般的です。 "管理者として実行" は、互換性を確保するための適切な回避策ではなく、ユーザーとシステムのセキュリティ リスクを高め、多くの状況でユーザーにフラストレーションを生み出します。
注意
Windows Vista で導入されたユーザー アカウント制御機能は、Windows 7 にも存在します。 ユーザー アカウント制御に関して、さまざまなシステム機能を操作するユーザー エクスペリエンスが向上していますが、アプリケーションへの影響は基本的に同じです。 この記事のすべての Windows Vista の推奨事項は、Windows 7 にも適用されます。 Windows 7 の UAC UI の変更の詳細については、「ユーザー インターフェイス - ユーザー アカウント制御ダイアログ 更新」を参照してください。
Windows Vista のユーザー アカウント
Windows Vista は、すべてのユーザーを管理者と標準ユーザーの 2 つのユーザー アカウントの種類に分類します。
標準ユーザー アカウントは、Windows XP の制限付きユーザー アカウントに似ています。 Windows XP と同様に、標準ユーザーは Program Files フォルダーに書き込むことができず、レジストリのHKEY_LOCAL_MACHINE部分に書き込むことができず、カーネル モード ドライバーのインストールやシステム レベルのプロセススペースへのアクセスなど、システムを変更するタスクを実行できません。
Windows XP がリリースされて以来、管理者アカウントが大幅に変更されました。 以前は、Administrators グループのメンバーによって起動されたすべてのプロセスに管理特権が付与されていました。 UAC を有効にすると、管理者によって特に昇格されていない限り、すべてのプロセスが標準のユーザー特権で実行されます。 この違いにより、ほとんどのプログラムで潜在的なバグによってもたらされるセキュリティ リスクを減らすことで、Administrators グループのアカウントの安全性が向上します。
すべてのアプリケーション、特にゲームは、標準的なユーザー プロセスとして実行するときに効果的かつ責任を持って動作することが重要です。 管理特権を必要とするすべての操作は、インストール時または管理者資格情報を明示的に要求する補助プログラムによって実行する必要があります。 特権の昇格は Administrators グループのメンバーにとって非常に簡単ですが、標準ユーザーは管理者資格情報を持つユーザーに延期して、特権を昇格するためにパスワードを物理的に入力する必要があります。 ペアレンタル コントロールによって保護されるアカウントは標準ユーザーである必要があるため、これは Windows Vista を使用しているゲーマーにとって非常に一般的な状況になります。
ゲームが既に限られたユーザー アカウントで Windows XP で動作している場合は、Windows Vista の [ユーザー アカウント制御] への移行は非常に簡単です。 このようなアプリケーションの大部分はそのまま動作しますが、アプリケーション マニフェストを追加することを強くお勧めします。 (マニフェストについては、このトピックの「 アプリケーション マニフェストでの実行レベルの設定」で後述します)。
標準ユーザーとしてのファイル アクセス
標準的なユーザー制限の影響を最も受けるゲームの側面は、ファイル システムのorganizationとアクセシビリティです。 ゲームがインストールされているフォルダーにファイルを書き込むことができるとは想定しないでください。 たとえば、Windows Vista では、アプリケーションが Program Files フォルダーに書き込む前に、オペレーティング システムによってユーザーの特権を昇格する必要があります。 これを回避するには、スコープとアクセシビリティによってゲームのデータ ファイルを分類し、 SHGetFolderPath 関数と Windows シェルによって提供される CSIDL 定数を使用して、適切なファイル パスを生成する必要があります。 CSIDL 定数は、オペレーティング システムが使用するファイル システム内の既知のフォルダーに対応し、グローバル ファイルとユーザー固有のファイルをパーティション分割するように昇格します。
アプリケーションに管理者権限がない場合、プロセスに書き込みアクセス許可を付与しないフォルダーの下にファイルまたはディレクトリを作成または書き込もうとすると、Windows Vista で失敗します。 32 ビット ゲーム実行可能ファイルがレガシ モードで実行されている場合、要求された実行レベルを宣言していないため、その書き込み操作は成功しますが、この記事で後述する「UAC の古いゲームとの互換性」セクションで説明されているように、仮想化が適用されます。
表 1 既知のフォルダー
| CSIDL 名 | 標準パス (Windows Vista) | 標準ユーザー権限 | 管理者権限 | アクセス スコープ | 説明 | 例 |
|---|---|---|---|---|---|---|
| CSIDL_PERSONAL | C:\Users\user name\Documents | 読み取り/書き込み | 読み取り/書き込み | ユーザー単位 | 読み取りと変更が行われ、ゲーム コンテキストの外部で操作できるユーザー固有のゲーム ファイル。 | スクリーン ショット。 ファイル拡張子の関連付けを使用して保存されたゲームファイル。 |
| CSIDL_LOCAL_APPDATA | C:\Users\user name\AppData\Local | 読み取り/書き込み | 読み取り/書き込み | ユーザー単位 | 読み取りと変更が行われ、ゲーム コンテキスト内でのみ使用されるユーザー固有のゲーム ファイル。 | ゲーム キャッシュ ファイル。 プレーヤーの構成。 |
| CSIDL_COMMON_APPDATA | C:\ProgramData | 所有者の場合は読み取り/書き込み | 読み取り/書き込み | すべてのユーザー | ユーザーが作成し、すべてのユーザーが読み取ることができるゲーム ファイル。 書き込みアクセス権は、ファイルの作成者 (所有者) にのみ付与されます。 | ユーザー プロファイル |
| CSIDL_PROGRAM_FILES | C:\Program Files または C:\Program Files (x86) |
読み取り専用 | 読み取り/書き込み | すべてのユーザー | すべてのユーザーが読み取るゲームのインストーラーによって書き込まれた静的なゲーム ファイル。 | マテリアルやメッシュなどのゲームアセット。 |
ゲームは通常、CSIDL_PROGRAM_FILES定数で表されるフォルダーの下のフォルダーにインストールされます。 ただし、常にそうとは限りません。 代わりに、インストール フォルダーの下にあるファイルまたはディレクトリへのパス文字列を生成するときに、実行可能ファイルからの相対パスを使用する必要があります。
また、既知のフォルダー パスに関するハードコーディングされた想定も控える必要があります。 たとえば、Windows XP Professional 64 ビット エディションと Windows Vista x64 では、プログラム ファイルのパスは 32 ビット プログラムの場合は C:\Program Files (x86) で、64 ビット プログラムの場合は C:\Program Files です。 これらの既知のパスは Windows XP から変更され、ユーザーはこれらのフォルダーの多くの場所を再構成して、異なるドライブ上で検索することもできます。 そのため、混乱や潜在的な問題を回避するには、常に CSIDL 定数を使用します。 Windows セットアップは、これらの既知のフォルダーの場所を理解し、Windows XP からオペレーティング システムをアップグレードするときにデータを移動します。これに対し、OS のアップグレード後に、標準以外の場所またはハードコーディングされたパスの使用が失敗する可能性があります。
CSIDL_PERSONALとCSIDL_LOCAL_APPDATAで指定されたユーザー固有のフォルダーの微妙な使いやすさの違いに注意する必要があります。 ファイルの書き込みに使用する CSIDL 定数を選択する場合は、ファイルをダブルクリックしてツールやアプリケーションで開いたり、他のファイルにCSIDL_LOCAL_APPDATAを使用したりするなど、ファイルを操作する必要がある場合は、CSIDL_PERSONALを使用することをお勧めします。 アクセス スコープや特権レベルに違いがないため、アプリケーションで両方のフォルダーを利用して、ユーザー固有のデータ ファイルを格納および整理できます。 他のアプリケーションと競合しないように十分に一意のパス名を作成する必要がありますが、完全なパス内の文字数を 260 MAX_PATHの値より少なく保つには十分な短さです。
次のコードは、既知のフォルダーにファイルを書き込む方法の例を示しています。
#include <windows.h>
#include <shlobj.h>
#include <shlwapi.h>
...
...
...
TCHAR strPath[MAX_PATH];
if( SUCCEEDED(
SHGetFolderPath( NULL, CSIDL_PERSONAL, NULL, SHGFP_TYPE_CURRENT, strPath ) ) )
{
PathAppend( strPath, TEXT( "Company Name\\Title" ) );
if( !PathFileExists( strPath ) )
{
if( ERROR_SUCCESS != SHCreateDirectoryEx( NULL, strPath, NULL ) )
return E_FAIL;
}
PathAppend( strPath, TEXT( "gamefile.txt" ) );
// strPath is now something like:
// C:\Users\<current user>\Documents\Company Name\Title\gamefile.txt
// Open the file for writing
HANDLE hFile = CreateFile(strPath, GENERIC_WRITE, NULL, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
if( INVALID_HANDLE_VALUE != hFile )
{
// TODO: Write to file
CloseHandle(hFile);
}
}
標準ユーザーとしてのレジストリ アクセス
標準ユーザーによるレジストリ アクセスは、ファイル システムと同様の方法で制限されます。 標準ユーザーは、レジストリ内のすべてのキーへの読み取りアクセスを許可されます。ただし、書き込みアクセスは、現在のユーザーのユーザー固有のサブキー HKEY_USERS\Security ID (SID) に内部的にマップされるHKEY_CURRENT_USER (HKCU) サブツリーにのみ付与されます。 HKEY_CURRENT_USER以外のレジストリの場所に書き込む必要があるアプリケーションには、管理者権限が必要です。
32 ビット アプリケーションに要求された実行レベルがマニフェストに含まれていない場合、HKEY_LOCAL_MACHINE\Softwareへの書き込みはすべて仮想化されますが、HKEY_CURRENT_USER以外の場所への書き込みは失敗します。
ユーザーの構成など、レジストリに永続的なデータを格納することはお勧めしません。 ゲームから永続的なデータを格納する推奨される方法は、 SHGetFolderPath を呼び出してファイル システムにデータを書き込み、前のセクションで説明した CSIDL 定数の値を取得することです。
特権の昇格
Windows Vista では、管理特権を必要とするアプリケーションでは、そのマニフェストで管理実行レベルの要求を宣言する必要があります (次のセクション「 アプリケーション マニフェストでの実行レベルの設定」で説明します)。
昇格は既知の通り、UAC によって実行される手順であり、プロセスを管理プロセスに昇格させます。 プロセスの特権は、作成時にのみ昇格できます。 作成されたプロセスは、より高い特権レベルに昇格されることはありません。 このためです。 管理資格情報を必要とする操作は、インストーラーとその他の補助プログラムを分離するために分離する必要があります。
プログラムの実行時に、UAC はマニフェストで要求された実行レベルを検査し、昇格された特権が必要な場合は、標準ユーザー用と管理者用の 2 つの標準ダイアログ ボックスのいずれかを使用して現在のユーザーにプロンプトを表示します。
現在のユーザーが標準ユーザーの場合、UAC は、プログラムの実行を許可する前に、管理者の資格情報の入力をユーザーに求めます。
図 1. 標準ユーザーに管理アカウントの資格情報の入力を求めるメッセージを表示する
現在のユーザーが管理者の場合、UAC は、プログラムの実行を許可する前に、ユーザーにアクセス許可を求めます。
図 2. コンピューターへの変更を承認するように管理者に求めるメッセージ
アプリケーションには、標準ユーザーが適切な管理資格情報を提供するか、管理ユーザーが確認を提供する場合にのみ、管理特権が付与されます。それ以外の場合は、アプリケーションが終了します。
昇格された特権を持つプロセスは、現在ログインしている標準ユーザーとしてではなく、UAC プロンプトで資格情報を入力した管理ユーザーとして実行されることに注意してください。 これは Windows XP の RunAs に似ていますが、管理者特権プロセスは、ユーザーごとのデータにアクセスするときに管理者のフォルダーとレジストリ キーを取得し、管理者特権でプロセスを起動するすべてのプログラムも管理者権限とユーザー アカウントの場所の両方を継承します。 確認を求めるメッセージが表示される管理者 (Continue または Cancel) の場合、これらの場所は現在のユーザーの場所と一致します。 ただし、一般に、昇格を必要とするプロセスは、ユーザーごとのデータに対して動作しないようにする必要があります。 これは、インストーラーの動作方法に大きく影響する可能性があることに注意してください。 管理者として実行されているインストーラーが HKCU またはユーザーのプロファイルに書き込む場合は、間違った場所に書き込む可能性があります。 ゲームの初回実行時に、これらのユーザーごとの値を作成することを検討してください。
CreateProcess() による UAC の影響
UAC 昇格メカニズムは、Win32 CreateProcess() 関数の呼び出しから呼び出されず、現在のプロセスよりも高い実行レベルを必要とするように構成された実行可能ファイルを起動します。 その結果、 CreateProcess() の呼び出しは失敗し、 GetLastError() はERROR_ELEVATION_REQUIREDを返します。 CreateProcess() は、呼び出し先の実行レベルが呼び出し元の実行レベルと等しいかそれより小さい場合にのみ成功します。 昇格されたプロセスを生成する必要がある昇格されていないプロセスは、 ShellExecute() 関数を使用して実行する必要があります。これにより、UAC 昇格メカニズムがシェルによってトリガーされます。
アプリケーション マニフェストでの実行レベルの設定
アプリケーションのマニフェストに拡張機能を追加して、ゲームの要求された実行レベルを宣言します。 次の XML コードは、アプリケーションの実行レベルを設定するために必要な最小限の構成を示しています。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
<ms_asmv2:security>
<ms_asmv2:requestedPrivileges>
<ms_asmv2:requestedExecutionLevel level="asInvoker" uiAccess="false" />
</ms_asmv2:requestedPrivileges>
</ms_asmv2:security>
</ms_asmv2:trustInfo>
</assembly>
前のコードでは、オペレーティング システムに対して、ゲームには次のタグによる標準ユーザー特権のみが必要であることが通知されます。
<ms_asmv2:requestedExecutionLevel level="asInvoker" uiAccess="false" />
この例では、requestedExecutionLevel を "asInvoker" に明示的に設定することで、管理特権なしでゲームが正しく動作することをオペレーティング システムにアサートします。 その結果、UAC は仮想化を無効にし、Windows エクスプローラーが標準ユーザーとして実行されるため、通常は標準ユーザー特権である呼び出し元と同じ特権でゲームを実行します。
次のタグを作成するには、"asInvoker" を "requireAdministrator" に置き換えることで、管理特権への昇格が必要なゲームにオペレーティング システムを通知できます。
<ms_asmv2:requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
この構成では、オペレーティング システムは、ゲームが実行されるたびに、標準の UAC 昇格ダイアログのいずれかを使用して、現在のユーザーにプロンプトを表示します。 このダイアログがすぐに迷惑になるだけでなく、ゲームが保護者のコントロールと互換性を持たないようにするため、実行に管理者特権を必要とするゲームがないことを強くお勧めします。 この要件を実行可能ファイルに追加する前に、慎重に検討してください。
一般的な誤解は、requestedExecutionLevel を "requireAdministrator" に設定するマニフェストを追加すると、昇格プロンプトの必要性が回避されることです。 不正解です。 これにより、セットアップまたは更新アプリケーションに管理者権限が必要かどうかをオペレーティング システムが推測できなくなります。 ユーザーは引き続き昇格を承認するように求められます。
Windows は、UAC プロンプトを表示する前に、昇格のマークが付けられているアプリケーションの署名を確認します。 昇格用にマークされた大きな実行可能ファイルは、小さな実行可能ファイルよりもチェックに時間がかかり、"asInvoker" としてマークされている実行可能ファイルよりも長くなります。 自己抽出する実行可能ファイルをセットアップするには、"asInvoker" としてマークする必要があります。"requireAdministrator" としてマークする必要がある部分は、別のヘルパー実行可能ファイルに配置する必要があります。
前の例に示した uiAccess 属性は、ゲームの場合は常に FALSE である必要があります。 この属性は、UI オートメーション クライアントが保護されたシステム UI にアクセスできるかどうかを指定し、TRUE に設定した場合に特別なセキュリティへの影響を与えます。
Visual Studio でのマニフェストの埋め込み
マニフェストのサポートは、VS2005 から Visual Studio に最初に追加されました。 既定では、Visual Studio 2005 (またはそれ以降) でビルドされた実行可能ファイルには、ビルド プロセスの一部として自動生成されたマニフェストが埋め込まれます。 自動生成されたマニフェストの内容は、プロジェクトのプロパティ ダイアログで指定した特定のプロジェクト構成に依存します。
Visual Studio 2005 によって自動生成されるマニフェストには、プロジェクト プロパティで UAC 実行レベルを <構成する方法がないため、trustInfo> ブロックは含まれません。 この情報を追加する推奨される方法は、vs2005 が trustInfo> ブロックを含むユーザー定義マニフェストを<自動生成されたマニフェストとマージできるようにすることです。 これは、前のセクションに示した XML を含む *.manifest ファイルをソリューションに追加するのと同じくらい簡単です。 ソリューションで .manifest ファイルが検出されると、Visual Studio によってマニフェスト ツール (mt.exe) が自動的に呼び出され、.manifest ファイルと自動生成されたファイルがマージされます。
注意
Visual Studio 2005 によって提供されるマニフェスト ツール (mt.exe) にバグがあり、その結果、マージされたマニフェストと埋め込まれたマニフェストが作成され、SP3 より前の Windows XP で実行可能ファイルが実行されると問題が発生する可能性があります。 このバグは、trustInfo> ブロックの宣言時にツールが既定の名前空間を再定義する方法の<結果です。 幸い、trustInfo> ブロックで別の名前空間を明示的に宣言し、子ノードを新しい名前空間<にスコープすることで、問題を完全にバイパスするのは簡単です。 前のセクションで提供した XML は、この修正を示しています。
Visual Studio 2005 に含まれるmt.exe ツールを使用する際の注意点は、ツールに XML を検証するための更新されたスキーマが含まれていないため、trustInfo> ブロックを処理<するときに警告が生成される点です。 この警告を解決するには、Visual Studio 2005 インストール ディレクトリ (複数のインスタンスがあります) のすべてのmt.exe ファイルを、最新の Windows SDK で提供されているmt.exeに置き換えることをお勧めします。
Visual Studio 2008 以降では、プロジェクトのプロパティ ダイアログ (図 3) 内から、または /MANIFESTUAC リンカー フラグを使用して、アプリケーションの実行レベルを指定できるようになりました。 これらのオプションを設定すると、Visual Studio 2008 が自動生成され、適切な <trustInfo> ブロックを含むマニフェストが実行可能ファイルに埋め込まれます。
図 3: Visual Studio 2008 での実行レベルの設定
マニフェストをサポートせずに以前のバージョンの Visual Studio にマニフェストを埋め込む方法は引き続き可能ですが、開発者による作業が必要です。 この方法の例については、2008 年 3 月のリリースより前に、DirectX SDK のサンプルに含まれている Visual Studio 2003 プロジェクトを確認してください。
UAC と古いゲームの互換性
ゲームが Program Files ディレクトリにファイルを正常に保存して読み込んでいるように見えるが、ファイル iOn Windows Vista の証拠がない場合、そのマニフェストに要求された実行レベルを含まない 32 ビット アプリケーションは、レガシ アプリケーションと見なされます。 Windows Vista より前のほとんどのアプリケーションは、通常、管理者特権を持つユーザーによって実行されていました。 その結果、これらのアプリケーションはシステム ファイルとレジストリ キーの読み取りと書き込みを自由に行うことができ、多くの開発者は Windows XP の制限付きユーザー アカウントで適切に動作するために必要な変更を行いませんでした。 ただし、Windows Vista では、従来のアプリケーションに対して標準のユーザー実行を強制する新しいセキュリティ モデルのアクセス特権が不十分なため、これらの同じアプリケーションが失敗するようになりました。 この影響を軽減するために、仮想化も Windows Vista に追加されました。 仮想化により、Windows Vista で何千ものレガシ アプリケーションが正常に動作し続けます。これらのアプリケーションは、いくつかのマイナーな操作で成功するだけで常に昇格された特権を持つ必要はありません。 が見つかった場合、ゲームがレガシ モードで実行され、仮想化の対象となった可能性があります。
仮想化は、システム依存の書き込み (およびその後のファイルまたはレジストリ操作) を現在のユーザーのプロファイル内のユーザーごとの場所にリダイレクトすることで、ファイル システムとレジストリに影響します。 たとえば、アプリケーションが次のファイルに書き込もうとするとします。
- C:\\Program Files\\Company Name\\Title\\config.ini
書き込みは自動的に次にリダイレクトされます。
- C:\\Users\\user name\\AppData\\Local\\VirtualStore\\Program Files\\Company Name\\Title\\config.ini
同様に、アプリケーションが次のようなレジストリ値を書き込もうとすると、次のようになります。
- HKEY\_LOCAL\_MACHINE\\Software\\会社名\\Title
代わりに、次のようにリダイレクトされます。
- HKEY\_CURRENT\_USER\\Software\\Classes\\VirtualStore\\MACHINE\\Software\\会社名\\Title
仮想化の影響を受けるファイルとレジストリ キーには、現在のユーザーとして実行されている仮想化されたアプリケーションからのファイルとレジストリの操作によってのみアクセスされます。
ただし、仮想化には多くの制限があります。 1 つは、64 ビット アプリケーションが 32 ビット アプリケーションの仮想化の対象となる互換性操作のレガシ モードで実行されることは決してなく、64 ビットで失敗するということです。 また、標準ユーザーとして実行されているレガシ アプリケーションが、管理資格情報を必要とする場所に任意の種類の実行可能ファイルを書き込もうとすると、仮想化は行われず、書き込みが失敗します。
図 4: 仮想化プロセス
レガシ アプリケーションがファイル システムまたはレジストリ内のシステムに依存する場所に対して読み取り操作を試みると、最初に仮想の場所が検索されます。 ファイルまたはレジストリ キーが見つからない場合、オペレーティング システムは既定のシステムの場所にアクセスします。
仮想化は後続のバージョンの Windows から削除されるため、この機能に依存しないことが重要です。 代わりに、仮想化が無効になるので、標準のユーザーまたは管理特権のアプリケーション マニフェストを明示的に構成する必要があります。 仮想化はエンド ユーザーにとって明らかではありません。そのため、仮想化によってアプリケーションの実行が許可される場合でも、サポート呼び出しが生成され、これらの顧客のトラブルシューティングが困難になる可能性があります。
UAC が無効になっている場合、仮想化も無効になります。 仮想化が無効になっている場合、標準ユーザー アカウントは Windows XP の制限付きユーザー アカウントとまったく同じように動作し、仮想化のために成功した標準ユーザーのレガシ アプリケーションが正しく機能しない可能性があります。
レガシ シナリオとマニフェスト
ほとんどの使用シナリオでは、.exeを正しい UAC マニフェスト要素でマークし、アプリケーションが標準ユーザーとして正しく動作することを確認するだけで、優れた UAC 互換性を実現できます。 ほとんどのゲーマーは、ユーザー アカウント制御が有効になっている Windows Vista または Windows 7 を実行しています。 Windows XP と、ユーザー アカウント制御機能が無効になっている Windows Vista または Windows7 のユーザーの場合、通常は管理者アカウントを使用して実行されます。 これは安全性の低い操作モードですが、前述のように、UAC を無効にすると仮想化も無効になりますが、通常は追加の互換性の問題は発生しません。
UAC マニフェストでプログラムが "requireAdministrator" としてマークされている場合は、特に注目に値する特別なケースがあります。 Windows XP およびユーザー アカウント制御が無効になっている Windows Vista または Windows 7 では、UAC マニフェスト要素はシステムによって無視されます。 この場合、管理者アカウントを持つユーザーは常に完全な管理者権限を持つすべてのプログラムを実行するため、これらのプログラムは期待どおりに機能します。 ただし、Windows Vista または Windows 7 で実行されている Windows XP 制限付きユーザーと標準ユーザーは、これらのプログラムを常に制限付き権限で実行し、すべての管理者レベルの操作は失敗します。 そのため、"requiretAdministrator" としてマークされたプログラムは起動時に IsUserAnAdmin を呼び出し、FALSE を返した場合は致命的なエラー メッセージを表示することをお勧めします。 上記の大半のシナリオでは、これは常に成功しますが、このまれな状況に対するユーザー エクスペリエンスと明確なエラー メッセージが提供されます。
まとめ
Windows マルチユーザー環境を対象とするゲーム開発者は、効果的かつ責任を持って動作するようにゲームを設計することが不可欠です。 ゲームのメイン実行可能ファイルは、管理特権に依存しないようにする必要があります。 これにより、ゲームを実行するたびに昇格のプロンプトが表示されるのを防ぐだけでなく、全体的なユーザー エクスペリエンスに悪影響を与える可能性があります。また、親コントロールなどの標準ユーザー特権で実行を必要とする他の機能をゲームで利用することもできます。
以前のバージョンの Windows の標準ユーザー (または制限付きユーザー) の資格情報と同様に動作するように適切に設計されたアプリケーションは、昇格なしで実行される UAC の影響を受けなくなります。 ただし、Vista のアプリケーション標準に準拠するために、要求された実行レベルが "asInvoker" に設定されたマニフェストを含める必要があります。
もっと読む
ユーザー アカウント制御に準拠している Windows Vista 用アプリケーションの設計に関するサポートについては、次のホワイト ペーパーをダウンロードしてください。 Windows Vista Application Development Requirements for User Account Control Compatibility。
このホワイト ペーパーでは、設計プロセスに関する詳細な手順と、コード サンプル、要件、ベスト プラクティスについて説明します。 このペーパーでは、Windows Vista のユーザー エクスペリエンスに対する技術的な更新と変更についても詳しく説明します。
ユーザー アカウント制御の詳細については、「Windows Vista: Microsoft TechNet のユーザー アカウント制御」を参照してください。
もう 1 つの便利なリソースは、MSDN Magazine 2007 年 1 月の記事「Windows Vista ユーザー アカウント制御でアプリを適切に再生するように教える」です。 この記事では、アプリケーションの互換性に関する一般的な問題と、Windows Vista で Windows インストーラー パッケージを使用する利点と問題について説明します。
mt.exeのバグと修正プログラムの詳細については、Visual Studio 2005 でマニフェストを自動的にマージして実行可能ファイルに埋め込むために使用されるツールです。MSDN の Chris Jackson のブログの「Exploring Manifests Part 2: Default Namespaces and UAC Manifests in Windows Vista」を参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示