英語で読む

次の方法で共有

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

  • [アーティクル]

この記事では、Windows Vista で導入されたユーザー アカウント制御 (UAC) セキュリティ機能をゲーム開発者が効果的に操作するためのガイドラインとベスト プラクティスについて説明します。

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

Windows Vista で導入されたユーザー アカウント制御 (UAC) は、悪意のある攻撃者が、広く使用されているアプリケーションで見つかった弱点やバグを使用してオペレーティング システムやその他のインストールされているプログラムを変更するのを防ぐために設計されたセキュリティ機能です。 これは、現在のユーザーのアカウントに管理者資格情報がある場合でも、大半のプログラムとプロセスを Standard ユーザー (制限付きユーザー、制限付きユーザー、または Least-Privileged ユーザーとも呼ばれます) として実行することによって実現されます。 標準のユーザー特権を持つプロセスには、システム全体の変更を妨げる多くの固有の制限があります。

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

UAC 機能は既定で有効になっています。 管理者が UAC をシステム全体で無効にすることは可能ですが、それには多くの悪影響があります。 まず、ほとんどのアプリケーションで実際に必要とされない場合でも、すべてのプロセスが管理資格情報で実行されるため、すべての管理アカウントのセキュリティが低下します。 UAC を無効にすると、セキュリティの悪用可能な脆弱性を公開する標準ユーザー アプリケーションを使用して、個人情報の盗用、ルートキットやスパイウェアのインストール、システムの整合性の破壊、または他のシステムに対するゾンビ攻撃のホストを行う可能性があります。 UAC を有効にすると、ほとんどのソフトウェアを標準ユーザーとして実行すると、このようなバグによる潜在的な損害が大幅に制限されます。 第 2 に、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 のユーザー アカウント制御への移行は非常に簡単です。 このようなアプリケーションの大部分は as-is動作しますが、アプリケーション マニフェストを追加することを強くお勧めします。 (マニフェストについては、「アプリケーション マニフェスト での実行レベルの設定」で後述します)。

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

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

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

表 1. 既知のフォルダー

CSIDL 名 一般的なパス (Windows Vista) 標準ユーザー権限 管理者権限 アクセス スコープ 形容 例
CSIDL_PERSONAL C:\Users\user name\Documents 読み取り/書き込み 読み取り/書き込み Per-User 読み取りと変更が行われ、ゲーム コンテキストの外部で操作できるユーザー固有のゲーム ファイル。 スクリーン ショット。 保存されたゲーム ファイルとファイル拡張子の関連付け。
CSIDL_LOCAL_APPDATA C:\Users\user name\AppData\Local 読み取り/書き込み 読み取り/書き込み Per-User 読み取りと変更が行われ、ゲーム コンテキスト内でのみ使用されるユーザー固有のゲーム ファイル。 ゲーム キャッシュ ファイル。 プレイヤーの構成。
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 に似ています。管理者特権プロセスは、ユーザーごとのデータにアクセスするときに管理者のフォルダーとレジストリ キーを取得し、管理者特権で起動されるすべてのプログラムも管理者権限とユーザー アカウントの場所の両方を継承します。 確認を求められた管理者 (続行 または キャンセル) の場合、これらの場所は現在のユーザーの場所と一致します。 ただし、一般に、昇格を必要とするプロセスは、ユーザーごとのデータでは動作しません。 これは、インストーラーの動作方法に大きく影響する可能性があることに注意してください。 管理者として実行されているインストーラーが 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 昇格ダイアログの 1 つを現在のユーザーに求めます。 このダイアログがすぐに煩わしいだけでなく、保護者による制御と互換性がないため、実行に管理者特権を必要としないゲームを強くお勧めします。 この要件を実行可能ファイルに追加する前に、慎重に検討してください。

一般的な誤解は、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

マニフェストをサポートせずに以前のバージョンの 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\\Company Name\\Title

代わりに次のようにリダイレクトされます。

HKEY\_CURRENT\_USER\\Software\\Classes\\VirtualStore\\MACHINE\\Software\\Company Name\\Title

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

ただし、仮想化には多くの制限があります。 1 つは、64 ビット アプリケーションが、32 ビット アプリケーションで仮想化の対象となる互換性操作のレガシ モードで実行されることは決してないということです。これは、64 ビットで失敗するだけです。 また、標準ユーザーとして実行されているレガシ アプリケーションが、管理者の資格情報を必要とする場所に任意の種類の実行可能ファイルを書き込もうとすると、仮想化は行われず、書き込みが失敗します。

図 4. 仮想化プロセス

仮想化プロセス

レガシ アプリケーションがファイル システムまたはレジストリ内のシステムに依存する場所に対して読み取り操作を試みると、最初に仮想の場所が検索されます。 ファイルまたはレジストリ キーが見つからない場合、オペレーティング システムは既定のシステムの場所にアクセスします。

仮想化は後続のバージョンの Windows から削除されるため、この機能に依存しないことが重要です。 代わりに、仮想化が無効になるので、標準のユーザー特権または管理特権に対してアプリケーション マニフェストを明示的に構成する必要があります。 仮想化はエンド ユーザーにとって明らかではないため、仮想化によってアプリケーションの実行が許可される場合でも、サポート呼び出しが生成され、これらの顧客のトラブルシューティングが困難になる可能性があります。

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

従来のシナリオとマニフェスト

ほとんどの使用シナリオでは、.exe を正しい UAC マニフェスト要素でマークし、アプリケーションが Standard ユーザーとして正しく動作することを確認するだけで、優れた 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 でマニフェストを自動的にマージして実行可能ファイルに埋め込むために使用されるツールです。「Exploring Manifests Part 2: Default Namespaces and UAC Manifests in Windows Vista on Chris Jackson のブログ(MSDN)」を参照してください。