ゲーム開発者向けのユーザーアカウント制御

[アーティクル]
05/11/2010

ゲームディベロッパーグループ、ソフトウェア開発エンジニア

ソフトウェアデザインエンジニア、Jason Sandlin 共著

2007 年 2 月

この記事では、Windows Vista で導入されたユーザーアカウント制御 (UAC) セキュリティ機能を効果的に使用するためのゲーム開発者向けのガイドラインおよび活用方法を示します。

ユーザーアカウント制御の概要
Windows Vista のユーザーアカウント
標準ユーザーとしてのファイルへのアクセス
標準ユーザーとしてのレジストリへのアクセス
特権の昇格
UAC の CreateProcess() との関係
アプリケーションマニフェストでの実行レベルの設定
Visual Studio でのマニフェストの埋め込み
以前のゲームとの UAC の互換性
まとめ
参考情報

ユーザーアカウント制御の概要

ユーザーアカウント制御 (UAC) は、Windows Vista に導入されたセキュリティ機能で、幅広く使用されているアプリケーションの脆弱性やバグを利用した悪意のある攻撃の防止に役立つよう設計されています、オペレーティングシステムやその他のインストールされているプログラムの改ざんを阻止できます。これは、現在のユーザーのアカウントが管理者権限を持っている場合でも、大部分のプログラムおよびプロセスを標準ユーザー (制限付きユーザー、制限されたユーザー、または最小特権ユーザーとも呼ばれます) として実行することによって実現できます。標準ユーザーの特権によるプロセスには、システム全体を変更できないようにする固有の制限が数多くあります。

UAC は、ダイアログベースの認証スキームの使用による、プロセスの特権の昇格も処理します。この認証スキームは特定のプロセスの実行時に起動され、管理者権限を要求するように指定されています。特権の昇格を使用すると、管理者は、安全な権限レベル (他の標準ユーザーと同じレベル) でアプリケーションの大部分を実行することができますが、管理者権限が必要なプロセスと操作を許可することもできます。UAC は、肩越し (OTS: Over-the-Shoulder) 認証をサポートしているため、標準ユーザーがシステムにログオンしている間に、昇格した権限を特定のプログラムに付与することができます。

UAS 機能は、デフォルトで有効になっています。管理者は UAC をシステム全体で無効にすることはできますが、無効にすることによっていくつかの悪影響が出ます。まず、無効にすることによって、ほとんどのアプリケーションで実際には管理者権限が必要ない場合でも、すべてのプロセスが管理者権限によって実行されるため、すべての管理者アカウントのセキュリティが脆弱化します。UAC が無効になっていると、標準のユーザーアプリケーションのセキュリティ上の脆弱性が悪用可能になり、個人情報の盗用、ルートキットやスパイウェアのインストール、システム整合性の破壊、または他のシステムへのゾンビ攻撃用ホストとしての利用などに、アプリケーションが使用される可能性があります。一方、UAC が有効になっていると、大部分のソフトウェアを標準ユーザーで実行することによって、このようなバグから生じる損害を大幅に制限できます。2 つ目に、UAC を無効にすると、通常の標準ユーザーに各種アプリケーションの正常実行を提供する、アプリケーション互換性の回避策の多くが使用できなくなります。互換性の回避方法として、UAC を無効にすることは決してお勧めできません。

可能な限り、アプリケーションで、標準ユーザー権限のみを使用するよう努めることが重要です。管理者はプロセスの特権を簡単に昇格できますが、昇格しても、管理者の資格情報が必要なアプリケーションを実行するたびに、ユーザーの対話操作と確認応答が必要になります。また、昇格は、プログラムの開始時に実行する必要があります。たとえ 1 回の操作であっても、管理者の資格情報を求めることによって、アプリケーションを実行している全期間、システムを大きな危険にさらすことになります。自分の権限を昇格できない標準ユーザーは、家庭や企業の環境でも共通して使用されます。"管理者として実行" することは、互換性の回避方法としては適切ではなく、ユーザーとシステムを大きなセキュリティリスクにさらすことになり、多くの状況でユーザーにわずらわしい操作を要求します。

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 のユーザーアカウント制御への移行は非常に簡単です。このようなアプリケーションのほとんどはそのまま動作しますが、アプリケーションマニフェストを追加することを強くお勧めします(マニフェストについては、後述の「アプリケーションマニフェストでの実行レベルの設定」で説明します)。

標準ユーザーとしてのファイルへのアクセス

標準ユーザーの制限に最も影響を受けるゲームの側面は、ファイルシステムの構成とアクセス権です。ゲームがインストールされているフォルダーにゲームからファイルを書き込むことはできないことを理解しておく必要があります。たとえば、Windows Vista では、アプリケーションから Program Files フォルダーに書き込むには、ユーザーの権限をオペレーティングシステムによって昇格する必要があります。これを回避するには、ゲームのデータファイルをスコープとアクセス許可別に分類し、Windows シェルから入手可能な CSIDL 定数を SHGetFolderPath 関数で使用して、適切なファイルパスを生成します。CSIDL 定数は、ファイルシステム内の "既知のフォルダー" に対応しています。このフォルダーは、オペレーティングシステムが使用し、グローバルファイルとユーザー固有のファイルを分離するために昇格されます。

プロセスに書き込み権限が付与されていないフォルダーでファイルまたはディレクトリの作成または書き込みを試みると、アプリケーションに管理者権限がない場合は Windows Vista の下でエラーが発生します。32 ビットのゲーム実行可能ファイルがレガシモードで実行されている場合は、要求実行レベルが宣言されていないため、書き込み操作を実行できますが、この記事で後述する「以前のゲームとの UAC の互換性」のとおり、書込み操作を実行できるかどうかは仮想化によります。

表 1. 既知のフォルダー

CSIDL 名	通常のパス (Windows Vista)	標準ユーザーの権限	管理者の権限	アクセスのスコープ	説明	例
CSIDL_PERSONAL	C:\Users\<ユーザー名>\Documents	読み取り/書き込み	読み取り/書き込み	ユーザーごと	読み取りおよび変更が実行され、ゲームコンテキスト以外から操作可能なユーザー固有のゲームファイル。	スクリーンショット。ファイル拡張子が関連付けられて保存されるゲームファイル。
CSIDL_LOCAL_APPDATA	C:\Users\<ユーザー名>\AppData\Local	読み取り/書き込み	読み取り/書き込み	ユーザーごと	読み取りおよび変更が実行され、ゲームコンテキスト内でのみ使用されるユーザー固有のゲームファイル。	ゲームキャッシュファイル。プレイヤーの構成。
CSIDL_COMMON_APPDATA	C:\ProgramData	読み取り/書き込み (所有者の場合)	読み取り/書き込み	すべてのユーザー	ユーザーが作成でき、すべてのユーザーが読み取ることができるゲームファイル。書き込みアクセス権は、ファイルの作成者 (所有者) のみに付与されます。	ユーザープロファイル。
CSIDL_PROGRAM_FILES	C:\Program Files または C:\Program Files (x86)	読み取りのみ	読み取り/書き込み	すべてのユーザー	ゲームのインストーラーによって書き込まれ、すべてのユーザーによって読み取られる静的なゲームファイル。	マテリアルやメッシュなどのゲームアセット。

ゲームは通常、CSIDL_PROGRAM_FILES 定数によって示されるフォルダー内のフォルダーにインストールされます。ただし、すべてがこの限りではありません。インストールフォルダー内のファイルまたはディレクトリへのパス文字列を生成する場合は、実行可能ファイルからの相対パスを使用する必要があります。

また、既知のフォルダーへのパスを仮定する場合はハードコードしないでください。たとえば、Windows XP Professional 64-bit Edition および 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_PERSONAL を使用し、それ以外のファイルには CSIDL_LOCAL_APPDATA を使用することをお勧めします。これらのフォルダーでは、アクセススコープまたは権限レベルに違いはないため、両方ともアプリケーションでユーザー固有のデータファイルの保存と構成に利用できます。パス名は、他のアプリケーションと競合しない一意性があり、完全パスの文字数が MAX_PATH の値 260 未満になるように、注意して作成する必要があります。

次のコードは、既知のフォルダーにファイルを書き込む方法の例を示しています。

#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_CURRENT_USER (HKCU) サブツリーに対してのみ付与されます。このサブツリーは、ユーザー固有のサブキー HKEY_USERS\<現在のユーザーのセキュリティ ID (SID)> に内部的にマップされます。HKEY_CURRENT_USER 以外のレジストリの場所に書き込む必要があるアプリケーションには、管理者権限が必要です。

32 ビットアプリケーションのマニフェストに、要求した実行レベルが含まれていない場合、HKEY_LOCAL_MACHINE\Software への書き込みはすべて仮想化され、HKEY_CURRENT_USER の外部の他の場所への書き込みは失敗します。

ユーザーの構成など、永続的なデータをレジストリに保存することはお勧めしません。ゲームから永続的なデータを保存するには、SHGetFolderPath を呼び出して、ファイルシステムにデータを書き込み、前のセクションで説明した CSIDL 定数の値を取得することをお勧めします。

特権の昇格

Windows Vista では、管理者権限が必要なアプリケーションはすべて、アプリケーションのマニフェストで、管理者実行レベルの要求を宣言する必要があります (次の「アプリケーションマニフェストでの実行レベルの設定」で説明します)。

"昇格" は、周知のとおり、あるプロセスを管理者プロセスに昇格するために UAC によって実行される手順です。プロセスの特権は、作成時にのみ昇格できます。プロセスは、一度作成されると、上の特権レベルに昇格されることはありません。このため、管理者の資格情報が必要な操作は、別個のインストーラーまたは他の補助プログラムに分離する必要があります。

プログラムの実行時に、UAC は要求実行レベルをマニフェストで検査し、昇格した権限が必要な場合は、現在のユーザーに次の 2 つのダイアログボックスのいずれかを表示します。標準ユーザー用のダイアログボックスと管理者用のダイアログボックスです。

現在のユーザーが標準ユーザーの場合、UAC は、プログラムの実行を許可する前に、ユーザーに管理者の資格情報の入力を求めます。

図形 1. 標準ユーザーに管理者アカウントの資格情報の入力を求めるプロンプト

Bb206295.UAC_prompt_elevation(ja-jp,VS.85).jpg

現在のユーザーが管理者の場合、UAC は、プログラムの実行を許可する前に、ユーザーに承認を求めるプロンプトを表示します。

図形 2. 管理者にコンピューターへの変更の承認を求めるプロンプト

Bb206295.UAC_prompt_authorization(ja-jp,VS.85).jpg

アプリケーションには、標準ユーザーが正しい管理者資格情報を入力するか、管理者ユーザーが確認応答を入力した場合にのみ、管理者権限が付与されます。それ以外の場合は、アプリケーションが終了します。

昇格された権限を持つプロセスは、現在ログインしている標準ユーザーとしてではなく、UAC のプロンプトに資格情報を入力した管理者ユーザーとして実行されることに注意する必要があります。これは、Windows XP の RunAs と同様で、昇格されたプロセスが、ユーザーごとのデータにアクセスするときは管理者のフォルダーとレジストリキーを取得し、昇格されたプロセスから起動されるプログラムはすべて管理者権限とユーザーアカウントの場所を継承します。確認応答 ([続行] または [キャンセル]) を求められた管理者の場合は、これらの場所は現在のユーザーの場所と一致します。ただし、昇格が必要なプロセスでは、一般にユーザーごとのデータを処理すべきではありません。これは、インストーラーの動作に大きく影響する可能性があります。管理者として実行されているインストーラーが HKCU またはユーザーのプロファイルに書き込む場合に、間違った場所に書き込む可能性が高くなります。これらのユーザーごとの値は、ゲームの最初の実行時に作成することを検討してください。

UAC の CreateProcess() との関係

Win32 CreateProcess() 関数の呼び出しで、現在のプロセスより上位の実行レベルを要求するように構成されている実行可能ファイルを開始する場合、この呼び出しから UAC の昇格メカニズムは起動できません。この結果、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 Explorer が標準ユーザーとして実行されるため通常は標準ユーザーの特権になります。

"asInvoker" を "requireAdministrator" に置き換えて次のタグを作成することによって、オペレーティングシステムに、ゲームで管理者権限への昇格が必要であることを通知できます。

<ms_asmv2:requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

この構成では、オペレーティングシステムは、ゲームが実行されるたびに、現在のユーザーにいずれかの標準 UAC 昇格ダイアログを表示します。いずれのゲームでも実行に管理者権限を要求しないことを強くお勧めします。このダイアログの表示が煩わしくなるだけでなく、ゲームで保護者による制限との互換性がなくなるためです。この要件を実行可能ファイルに追加するときは、慎重に検討してください。

requestedExecutionLevel を "requireAdministrator" に設定するマニフェストを追加することによって、昇格のプロンプトの必要性がなくなると誤解されている場合が多くあります。これは正しくありません。単純に、オペレーティングシステムで、アプリケーションの設定時や更新時に管理者権限が必要かどうかの推定が行われなくなるだけです。ユーザーには引き続き昇格の承認を求めるダイアログボックスが表示されます。

Windows では、UAC プロンプトを表示する前に、昇格に指定されたアプリケーションがあれば、その署名が確認されます。昇格に指定された大規模な実行可能ファイルの確認は、小さな実行可能ファイルや "asInvoker" として指定された実行可能ファイルより長くかかります。このため、自己解凍型のセットアップ実行可能ファイルは、"asInvoker" として指定し、"requireAdministrator" として指定する必要がある部分は別のヘルパー実行可能ファイルに配置する必要があります。

前に示した例の uiAccess 属性は、ゲームでは常に FALSE である必要があります。この属性は、UI 自動化クライアントが、保護されたシステム UI にアクセスできるかどうかを指定します。また、この属性が TRUE に設定されると、特別なセキュリティ上の意味を持ちます。

Visual Studio でのマニフェストの埋め込み

マニフェストのサポートは、Visual Studio 2005 から Visual Studio に追加されました。デフォルトでは、Visual Studio 2005 以降でビルドされる実行可能ファイルには、ビルドプロセスの一環として、自動生成されたマニフェストが埋め込まれます。自動生成されたマニフェストのコンテンツは、プロジェクトのプロパティのダイアログボックスで指定する特定のプロジェクト構成によって異なります。

プロジェクトのプロパティでは UAC 実行レベルを構成できないため、Visual Studio 2005 によって自動生成されるマニフェストには、<trustInfo> ブロックは含まれません。この情報を追加する方法は、Visual Studio 2005 で、<trustInfo> ブロックを含むユーザー定義のマニフェストを自動生成マニフェストに結合することです。これは、前のセクションで示した XML を含むソリューションに *.manifest ファイルを追加するのと同じぐらい簡単です。Visual Studio によって、ソリューションに .manifest ファイルが検出されると、Visual Sudio では、自動的にマニフェストツール (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 での実行レベルの設定

Bb206295.Setting_execution_level_in_VS2008(ja-jp,VS.85).jpg

マニフェストのサポートがない以前のバージョンの Visual Studio にマニフェストを埋め込むことはできますが、開発者による追加処理が必要です。これを実行する方法の 1 つの例として、2008 年 3 月リリースより前の DirectX SDK のサンプルに含まれる Visual Studio 2003 プロジェクトを確認してください。

以前のゲームとの UAC の互換性

ゲームで、Program Files ディレクトリに正常にファイルの保存とロードが実行されているように見えても、ファイルの痕跡が見つからない場合、ゲームがレガシモードで実行されていて、仮想化の対象となっていた可能性があります。

Windows Vista では、要求実行レベルがマニフェストに含まれない 32 ビットのアプリケーションは、レガシアプリケーションと見なされます。Windows Vista より前では、ほとんどのアプリケーションが管理者権限を持つユーザーによって実行されていました。この結果、これらのアプリケーションは、システムファイルおよびレジストリキーを自由に読み取ったり、書き込んだりでき、多くの開発者は Windows XP の制限付きユーザーアカウントで適切に動作するための必要な変更を加えることはありませんでした。Windows Vista では、これらの同じアプリケーションが、レガシアプリケーションに対して標準ユーザーの実行を強制する新しいセキュリティモデルの下で、アクセス権が不十分なことから失敗するようになります。この影響を軽減するために、Windows Vista には仮想化も追加されました。仮想化によって、何千ものレガシアプリケーションが、いくつかの小さな操作を正常に実行するためだけに常時特権を昇格することなく、Windows Vista で正常に機能し続けることができます。

仮想化は、システムの重要データへの書き込み (およびそれに続くファイルまたはレジストリ操作) を現在のユーザーのプロファイル内のユーザー固有の場所にリダイレクトすることによって、ファイルシステムおよびレジストリに変更を加えます。たとえば、アプリケーションが次のファイルに書き込みを実行するとします。

C:\Program Files\<企業名>\<役職>\config.ini

書き込みは、自動的に次のファイルにリダイレクトされます。

C:\Users\<ユーザー名>\AppData\Local\VirtualStore\Program Files\<企業名>\<役職>\config.ini

同様に、アプリケーションが次のようなレジストリ値の書き込みを実行するとします。

HKEY_LOCAL_MACHINE\Software\<企業名>\<役職>

これは次の値にリダイレクトされます。

HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\<企業名>\<役職>

仮想化の影響を受けるファイルおよびレジストリキーは、現在のユーザーで実行されている仮想化されたアプリケーションのファイルおよびレジストリ操作によってのみアクセスされます。

ただし、仮想化には多くの制限事項があります。まず、64 ビットのアプリケーションが互換性のためにレガシモードで実行されることはありません。32 ビットのアプリケーションの仮想化の対象となる操作は、64 ビットでは失敗します。また、標準ユーザーとして実行されているレガシアプリケーションで、管理者権限が必要な場所に何らかの種類の実行可能ファイルを書き込もうとすると、仮想化は発生せず、書き込みは失敗します。

図形 4. 仮想化プロセス

Bb206295.UAC_virtualization_process(ja-jp,VS.85).jpg

レガシアプリケーションでは、ファイルシステムまたはレジストリ内のシステムの重要データが格納されている場所で読み取り操作を実行しようとすると、仮想の場所が最初に検索されます。ファイルまたはレジストリキーが見つからない場合、オペレーティングシステムはデフォルトのシステムの場所にアクセスします。

仮想化は、以降のバージョンの Winodws からは廃止されるため、この機能には依存しないことが重要です。代わりに、標準ユーザー権限または管理者権限についてのアプリケーションのマニフェストを明示的に構成します。これによって仮想化が無効になります。仮想化は、エンドユーザーにとっては理解が難しいため、仮想化によってアプリケーションを実行できる可能性がある場合でも、サポートへの問い合わせが生じたり、これらのユーザーにとってトラブルシューティングが難しくなったりすることがあります。

UAC を無効にすると、仮想化も無効になります。仮想化が無効になると、標準ユーザーアカウントは、Windows XP の制限付きユーザーアカウントとまったく同じように動作し、仮想化によって正常に機能していたはずのレガシアプリケーションが、標準ユーザーに対して正常に機能しなくなる場合があります。

まとめ

Windows 複数ユーザー環境をターゲットにしているゲーム開発者にとっては、効果的かつ確実に動作するようにゲームを設計することが不可欠です。ゲームの主要な実行可能ファイルで管理者権限を要求しないでください。これにより、ゲームが実行されるたびに昇格を求めるメッセージが表示されユーザーエクスペリエンス全体に悪影響を与える問題も解消でき、標準ユーザーの特権で実行する必要がある保護者による制限などのその他の機能もゲームで利用できるようになります。

以前のバージョンの Windows で、標準ユーザー (または制限付きユーザー) の資格情報を使用して動作するよう適切に設計されているアプリケーションは、UAC の影響を受けることなく、昇格なしに実行されます。ただし、これらのアプリケーションには、要求実行レベルが "asInvoker"に設定されたマニフェストを追加して、Vista のアプリケーション基準に従うようにする必要があります。

参考情報

ユーザーアカウント制御に準拠する Windows Vista 用のアプリケーションの設計方法については、「Windows Vista Application Development Requirements for User Account Control Compatibility」のホワイトペーパーをダウンロードしてください。

このホワイトペーパーでは、設計プロセスに関する詳細手順、コードサンプル、要件、および活用方法について説明されています。また、Windows Vista でのユーザーエクスペリエンスに対する技術上の更新および変更の詳細も示されています。

ユーザーアカウント制御の詳細については、Microsoft TechNet の「Windows Vista: ユーザーアカウント制御」を参照してください。

別の有用なリソースとして、「MSDN マガジン」(2007 年 1 月) の記事「アプリケーションで Windows Vista のユーザーアカウント制御を有効に活用する」があります。この記事では、アプリケーションの互換性に関する一般的な問題と、Windows Vista で Windows インストーラーパッケージを使用する際の利点と問題について説明しています。

実行可能ファイルにマニフェストを自動的に結合および埋め込む Visual Studio 2005 のツールである mt.exe のバグと修正の詳細については、MSDN の Chris Jackson のブログにある「Exploring Manifests Part 2: Default Namespaces and UAC Manifests in Windows Vista」を参照してください。

ゲーム開発者向けのユーザー アカウント制御

ユーザー アカウント制御の概要

Windows Vista のユーザー アカウント