게임 개발자를 위한 사용자 계정 컨트롤

이 문서에서는 게임 개발자가 Windows Vista에 도입된 UAC(사용자 계정 컨트롤) 보안 기능을 효과적으로 사용하기 위한 지침과 모범 사례를 설명합니다.

• 사용자 계정 컨트롤 개요
• Windows Vista의 사용자 계정
• 표준 사용자로서의 파일 액세스
• 표준 사용자로 레지스트리 액세스
• 권한 상승
• CreateProcess()를 사용하는 UAC 의미
• 애플리케이션 매니페스트에서 실행 수준 설정
• Visual Studio에 매니페스트 포함
• 이전 게임과의 UAC 호환성
• 레거시 시나리오 및 매니페스트
• 결론
• 추가 읽기

사용자 계정 컨트롤 개요

Windows Vista에 도입된 UAC(사용자 계정 컨트롤)는 악의적인 공격자가 널리 사용되는 애플리케이션에서 발견된 약점이나 버그를 사용하여 운영 체제 또는 기타 설치된 프로그램을 변경하지 못하도록 설계된 보안 기능입니다. 이 작업은 현재 사용자의 계정에 관리 자격 증명이 있는 경우에도 대부분의 프로그램 및 프로세스를 표준 사용자(제한된 사용자, 제한된 사용자 또는 최소 권한 있는 사용자라고도 함)로 실행하여 수행됩니다. 표준 사용자 권한이 있는 프로세스에는 시스템 차원의 변경을 방지하는 많은 내재된 제한 사항이 있습니다.

UAC는 또한 관리자 권한이 필요한 것으로 지정된 특정 프로세스를 실행할 때 시작된 대화 상자 기반 인증 체계를 사용하여 프로세스의 권한 상승을 담당합니다. 권한 상승은 관리자가 안전한 권한 수준(다른 표준 사용자와 동일)에서 대부분의 애플리케이션을 실행할 수 있게 해 주지만 관리 권한이 필요한 프로세스 및 작업을 허용할 수도 있습니다. UAC는 표준 사용자가 현재 시스템에 로그온하는 동안 관리자가 프로그램에 상승된 권한을 부여할 수 있도록 숄더 인증을 지원합니다.

UAC 기능은 기본적으로 사용하도록 설정됩니다. 관리자가 UAC 시스템 전체를 사용하지 않도록 설정할 수 있지만 이렇게 하면 여러 가지 부정적인 파급효과가 발생합니다. 첫째, 대부분의 애플리케이션에서 실제로 필요하지 않은 경우에도 모든 프로세스가 관리 자격 증명으로 실행되기 때문에 모든 관리 계정의 보안이 약화됩니다. UAC를 사용하지 않도록 설정하면 보안에서 악용 가능한 취약성을 노출하는 표준 사용자 애플리케이션을 사용하여 개인 정보를 도용하거나, 루트킷 또는 스파이웨어를 설치하거나, 시스템 무결성을 파괴하거나, 다른 시스템에서 좀비 공격을 호스트할 수 있습니다. UAC를 사용하는 반면, 대부분의 소프트웨어를 표준 사용자로 실행하면 이러한 버그로 인한 잠재적 손상이 크게 제한됩니다. 둘째, UAC를 해제하면 실제 표준 사용자가 광범위한 애플리케이션을 성공적으로 실행할 수 있도록 하는 애플리케이션 호환성에 대한 많은 해결 방법이 비활성화됩니다. 호환성 해결 방법으로는 UAC를 사용하지 않도록 설정하는 것이 좋습니다.

애플리케이션은 가능한 한 표준 사용자 권한만 사용하려고 노력해야 합니다. 관리자는 프로세스의 권한을 쉽게 상승시킬 수 있지만 관리자 자격 증명이 필요한 애플리케이션을 실행할 때마다 권한 상승에는 사용자 상호 작용 및 승인이 여전히 필요합니다. 또한 이 권한 상승은 프로그램이 시작될 때 수행되어야 하므로 단일 작업에 대해서도 관리 자격 증명을 요구하려면 애플리케이션의 전체 실행 시간에 대한 더 큰 위험에 시스템을 노출해야 합니다. 권한을 상승시킬 수 없는 표준 사용자는 가족 및 비즈니스 설정에서도 일반적입니다. "Run As 관리istrator"는 호환성을 위한 좋은 해결 방법이 아니며, 사용자와 시스템을 더 큰 보안 위험에 노출시키고, 많은 상황에서 사용자에게 불만을 만듭니다.

Windows Vista의 사용자 계정

Windows Vista는 모든 사용자를 관리자 및 표준 사용자라는 두 가지 사용자 계정 유형으로 분류합니다.

표준 사용자 계정은 Windows XP의 제한된 사용자 계정과 유사합니다. Windows XP와 마찬가지로 표준 사용자는 Program Files 폴더에 쓸 수 없고, 레지스트리의 HKEY_LOCAL_MACHINE 부분에 쓸 수 없으며, 커널 모드 드라이버 설치 또는 시스템 수준 프로세스 공간 액세스와 같이 시스템을 변경하는 작업을 수행할 수 없습니다.

windows XP가 릴리스된 이후 관리istrator 계정이 크게 변경되었습니다. 이전에는 관리istrators 그룹의 멤버가 시작한 모든 프로세스에 관리 권한이 부여되었습니다. UAC를 사용하도록 설정하면 관리자가 특별히 상승하지 않는 한 모든 프로세스가 표준 사용자 권한으로 실행됩니다. 이러한 차이로 인해 대부분의 프로그램에서 잠재적 버그로 인해 발생하는 보안 위험을 줄여 관리istrators 그룹의 계정이 더 안전해집니다.

모든 애플리케이션, 특히 게임이 표준 사용자 프로세스로 실행되면 효과적이고 책임감 있게 작동하는 것이 중요합니다. 관리 권한이 필요한 모든 작업은 설치 시 또는 관리 자격 증명을 명시적으로 요청하는 보조 프로그램에 의해 수행되어야 합니다. 권한 상승은 관리istrators 그룹의 구성원에게는 매우 간단하지만, 표준 사용자는 권한을 상승하기 위해 실제로 암호를 입력하기 위해 관리자 자격 증명을 가진 사람에게 연기해야 합니다. 자녀 보호로 보호되는 계정은 표준 사용자여야 하므로 Windows Vista를 사용하는 게이머에게는 매우 일반적인 상황입니다.

게임이 제한된 사용자 계정으로 Windows XP에서 이미 작업 중인 경우 Windows Vista에서 사용자 계정 컨트롤로 이동하는 것이 매우 쉬워야 합니다. 이러한 애플리케이션의 대부분은 그대로 작동하지만 애플리케이션 매니페스트를 추가하는 것이 좋습니다. (매니페스트는 이 항목의 뒷부분에 설명되어 있습니다. 애플리케이션 매니페스트에서 실행 수준 설정.)

표준 사용자로서의 파일 액세스

표준 사용자 제한의 영향을 가장 많이 받는 게임의 측면은 파일 시스템 조직 및 접근성입니다. 게임이 설치된 폴더에 파일을 쓸 수 있다고 가정해서는 안 됩니다. 예를 들어 Windows Vista에서 애플리케이션이 Program Files 폴더에 쓰려면 먼저 운영 체제에서 사용자 권한을 상승시켜야 합니다. 이를 방지하려면 게임 데이터 파일을 범위 및 접근성별로 분류하고 Windows 셸에서 제공하는 CSIDL 상수와 함께 SHGetFolderPath 함수를 사용하여 적절한 파일 경로를 생성해야 합니다. CSIDL 상수는 운영 체제에서 사용하고 전역 및 사용자별 파일을 분할하도록 승격하는 파일 시스템의 알려진 폴더에 해당합니다.

애플리케이션에 관리 권한이 없는 경우 프로세스에 쓰기 권한을 부여하지 않는 폴더 아래에 파일 또는 디렉터리를 만들거나 쓰려고 하면 Windows Vista에서 실패합니다. 요청된 실행 수준을 선언하지 않았기 때문에 32비트 게임 실행 파일이 레거시 모드에서 실행되는 경우 쓰기 작업은 성공하지만 이 문서의 뒷부분에 나오는 "이전 게임과의 UAC 호환성" 섹션에 설명된 대로 가상화가 적용됩니다.

표 1. 알려진 폴더

게임은 일반적으로 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_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_USERS\보안 ID(SID)에 내부적으로 매핑되는 HKEY_CURRENT_USER(HKCU) 하위 트리에만 부여됩니다. HKEY_CURRENT_USER 이외의 레지스트리 위치에 기록해야 하는 애플리케이션에는 관리 권한이 필요합니다.

32비트 애플리케이션이 매니페스트에 요청된 실행 수준을 포함하지 않으면 HKEY_LOCAL_MACHINE\Software에 대한 모든 쓰기가 가상화되고 HKEY_CURRENT_USER 외부의 다른 위치에 대한 쓰기는 실패합니다.

사용자의 구성과 같이 레지스트리에 영구 데이터를 저장하는 것은 권장되지 않습니다. 게임에서 영구 데이터를 저장하는 기본 방법은 SHGetFolderPath를 호출하여 파일 시스템에 데이터를 쓰고 이전 섹션에서 설명한 CSIDL 상수의 값을 가져오는 것입니다.

권한 상승

Windows Vista에서 관리 권한이 필요한 모든 애플리케이션은 매니페스트에서 관리 실행 수준에 대한 요청을 선언해야 합니다(다음 섹션에서 설명한 애플리케이션 매니페스트의 실행 수준 설정).

알려진 대로 권한 상승은 프로세스를 관리 프로세스로 승격하기 위해 UAC에서 구동하는 프로시저입니다. 프로세스의 권한은 생성 시에만 상승될 수 있습니다. 만든 프로세스는 더 높은 권한 수준으로 승격되지 않습니다. 이러한 이유로. 관리 자격 증명이 필요한 작업은 별도의 설치 관리자 및 기타 보조 프로그램으로 격리되어야 합니다.

프로그램을 실행하면 UAC는 매니페스트에서 요청된 실행 수준을 검사하고 상승된 권한이 필요한 경우 현재 사용자에게 표준 사용자용 대화 상자와 관리자용 대화 상자 중 하나를 입력하라는 메시지를 표시합니다.

현재 사용자가 표준 사용자인 경우 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"를 "require관리istrator"로 바꿔서 관리자 권한 상승이 필요하다는 것을 운영 체제에 알릴 수 있습니다.

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

이 구성을 사용하면 운영 체제에서 게임이 실행될 때마다 표준 UAC 권한 상승 대화 상자 중 하나를 사용하여 현재 사용자에게 메시지를 표시합니다. 이 대화 상자는 빠르게 성가신 될뿐만 아니라 게임이 자녀 보호와 호환되지 않기 때문에 어떤 게임도 실행하기 위해 관리자 권한이 필요하지 않는 것이 좋습니다. 실행 파일에 이 요구 사항을 추가하기 전에 신중하게 생각하세요.

일반적인 오해는 requestedExecutionLevel을 "require관리istrator"로 설정하는 매니페스트를 추가하면 권한 상승 프롬프트의 필요성을 무시한다는 것입니다. 사실이 아닙니다. 운영 체제가 설치 또는 업데이트 애플리케이션에 관리 권한이 필요한지 추측할 수 없습니다. 사용자에게 권한 상승 권한을 부여하라는 메시지가 계속 표시됩니다.

Windows는 UAC 프롬프트를 표시하기 전에 권한 상승으로 표시된 모든 애플리케이션의 서명을 검사. 권한 상승으로 표시된 큰 실행 파일은 작은 실행 파일보다 검사 데 더 오래 걸리고 "asInvoker"로 표시된 실행 파일보다 더 오래 걸립니다. 따라서 자체 추출하는 설치 실행 파일은 "asInvoker"로 표시되어야 하며" "require관리istrator"로 표시해야 하는 모든 부분은 별도의 도우미 실행 파일에 배치해야 합니다.

앞의 예제에 표시된 uiAccess 특성은 항상 게임의 경우 FALSE여야 합니다. 이 특성은 UI 자동화 클라이언트가 보호된 시스템 UI에 액세스할 수 있는지 여부를 지정하며 TRUE로 설정된 경우 특별한 보안 영향을 줍니다.

Visual Studio에 매니페스트 포함

매니페스트 지원은 VS2005부터 Visual Studio에 처음 추가되었습니다. 기본적으로 Visual Studio 2005 이상에서 빌드된 실행 파일에는 빌드 프로세스의 일부로 자동 생성된 매니페스트가 포함됩니다. 자동 생성된 매니페스트의 내용은 프로젝트 속성 대화 상자에서 지정한 특정 프로젝트 구성에 따라 달라집니다.

Visual Studio 2005에서 자동으로 생성된 매니페스트에는 프로젝트 속성에서 UAC 실행 수준을 구성할 방법이 없기 때문에 trustInfo> 블록이 포함되지 <않습니다. 이 정보를 추가하는 기본 방법은 VS2005가 trustInfo> 블록을 포함하는 사용자 정의 매니페스트를 <자동 생성된 매니페스트와 병합하도록 하는 것입니다. 이는 이전 섹션에 나열된 XML을 포함하는 *.manifest 파일을 솔루션에 추가하는 것만큼 간단합니다. Visual Studio가 솔루션에서 .manifest 파일을 발견하면 자동으로 매니페스트 도구(mt.exe)를 호출하여 .manifest 파일을 자동으로 생성된 파일과 병합합니다.

Visual Studio 2005에 포함된 mt.exe 도구를 사용하는 경우 주의해야 할 점은 도구에 XML의 유효성을 검사하는 업데이트된 스키마가 포함되어 있지 않으므로 trustInfo> 블록을 처리<할 때 경고가 생성된다는 것입니다. 이 경고를 해결하려면 Visual Studio 2005 설치 디렉터리 아래의 모든 mt.exe 파일(여러 인스턴스가 있습니다)을 최신 Windows SDK에 제공된 mt.exe로 바꾸는 것이 좋습니다.

Visual Studio 2008부터 프로젝트 속성 대화 상자 내에서 또는 /MANIFESTUAC 링커 플래그를 사용하여 애플리케이션의 실행 수준을 지정할 수 있습니다(그림 3). 이러한 옵션을 설정하면 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\\Company Name\\Title

대신 다음으로 리디렉션됩니다.

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

가상화의 영향을 받는 파일 및 레지스트리 키는 현재 사용자로 실행 중인 가상화된 애플리케이션의 파일 및 레지스트리 작업에서만 액세스됩니다.

그러나 가상화에는 많은 제한 사항이 있습니다. 하나는 64비트 애플리케이션이 32비트 애플리케이션에서 가상화가 적용되는 호환성 작업을 위해 레거시 모드에서 실행되지 않는다는 것입니다. 64비트에서만 실패합니다. 또한 표준 사용자로 실행되는 레거시 애플리케이션이 관리 자격 증명이 필요한 위치에 모든 형식의 실행 파일을 쓰려고 하면 가상화가 발생하지 않고 쓰기가 실패합니다.

그림 4. 가상화 프로세스

레거시 애플리케이션이 파일 시스템 또는 레지스트리의 시스템 구분 위치에서 읽기 작업을 시도하면 가상 위치가 먼저 검색됩니다. 파일 또는 레지스트리 키를 찾을 수 없는 경우 운영 체제는 기본 시스템 위치에 액세스합니다.

가상화는 이후 버전의 Windows에서 제거되므로 이 기능을 사용하지 않는 것이 중요합니다. 대신, 가상화를 사용하지 않도록 설정하므로 표준 사용자 또는 관리 권한에 대한 애플리케이션 매니페스트를 명시적으로 구성해야 합니다. 가상화는 최종 사용자에게도 명확하지 않으므로 가상화를 통해 애플리케이션을 실행할 수 있더라도 지원 호출을 생성하고 이러한 고객을 위해 문제를 해결하기가 어려울 수 있습니다.

UAC를 사용하지 않도록 설정하면 가상화도 사용하지 않도록 설정됩니다. 가상화를 사용하지 않도록 설정하면 표준 사용자 계정이 Windows XP의 제한된 사용자 계정과 똑같이 동작하며, 가상화로 인해 성공한 표준 사용자에 대해 레거시 애플리케이션이 제대로 작동하지 않을 수 있습니다.

레거시 시나리오 및 매니페스트

대부분의 사용 시나리오에서는 .exe를 올바른 UAC 매니페스트 요소로 표시하고 애플리케이션이 표준 사용자로 올바르게 작동하는지 확인하는 것만으로도 뛰어난 UAC 호환성을 제공합니다. 대부분의 게이머는 사용자 계정 컨트롤을 사용하도록 설정된 Windows Vista 또는 Windows 7을 실행합니다. Windows XP 및 사용자 계정 컨트롤 기능이 비활성화된 Windows Vista 또는 Windows7의 사용자는 일반적으로 관리자 계정을 사용하여 실행됩니다. 이는 덜 안전한 작업 모드이지만, 위에서 설명한 대로 UAC를 사용하지 않도록 설정하면 가상화도 사용하지 않도록 설정되지만 일반적으로 추가 호환성 문제가 발생하지 않습니다.

프로그램이 UAC 매니페스트에서 "require관리istrator"로 표시된 경우 주목할 만한 특별한 경우가 있습니다. Windows XP 및 사용자 계정 컨트롤이 비활성화된 Windows Vista 또는 Windows 7에서는 시스템에서 UAC 매니페스트 요소를 무시합니다. 이 경우 관리자 계정이 있는 사용자는 항상 전체 관리자 권한이 있는 모든 프로그램을 실행하므로 이러한 프로그램이 예상대로 작동합니다. 그러나 Windows Vista 또는 Windows 7에서 실행되는 Windows XP 제한된 사용자 및 표준 사용자는 항상 제한된 권한으로 이러한 프로그램을 실행하며 모든 관리자 수준 작업이 실패합니다. 따라서 "requiret관리istrator"로 표시된 프로그램은 시작 시 IsUserAn관리을 호출하고 FALSE를 반환하는 경우 치명적인 오류 메시지를 표시하는 것이 좋습니다. 위의 대부분의 시나리오에서는 항상 성공하지만 이 드문 상황에 대해 더 나은 사용자 환경과 명확한 오류 메시지를 제공합니다.

결론

Windows 다중 사용자 환경을 대상으로 하는 게임 개발자는 효과적이고 책임감 있게 작동하도록 게임을 디자인해야 합니다. 게임의 기본 실행 파일은 관리 권한에 의존해서는 안 됩니다. 이렇게 하면 게임이 실행되어 전반적인 사용자 환경에 부정적인 영향을 미칠 수 있는 권한 상승 프롬프트가 표시되지 않을 뿐만 아니라, 자녀 보호와 같은 표준 사용자 권한으로 실행해야 하는 다른 기능을 활용할 수 있습니다.

이전 버전의 Windows에서 표준 사용자(또는 제한된 사용자)의 자격 증명으로 제대로 작동하도록 설계된 애플리케이션은 권한 상승 없이 실행되는 UAC의 영향을 받지 않습니다. 그러나 Vista의 애플리케이션 표준을 준수하기 위해 요청된 실행 수준이 "asInvoker"로 설정된 매니페스트를 포함해야 합니다.

추가 참고 자료

사용자 계정 컨트롤을 준수하는 Windows Vista용 애플리케이션 디자인에 대한 지원을 받으려면 사용자 계정 컨트롤 호환성을 위한 Windows Vista 애플리케이션 개발 요구 사항 백서를 다운로드하세요.

이 백서에서는 코드 샘플, 요구 사항 및 모범 사례와 함께 디자인 프로세스에 대한 자세한 단계를 제공합니다. 이 문서에서는 Windows Vista의 사용자 환경에 대한 기술 업데이트 및 변경 사항에 대해서도 자세히 설명합니다.

사용자 계정 컨트롤에 대한 자세한 내용은 Windows Vista: Microsoft TechNet의 사용자 계정 컨트롤을 방문하세요.

또 다른 유용한 리소스는 MSDN Magazine, 2007년 1월의 Windows Vista 사용자 계정 컨트롤을 사용하여 멋지게 재생하도록 앱을 가르치는 문서입니다. 이 문서에서는 애플리케이션 호환성의 일반적인 문제뿐만 아니라 Windows Vista에서 Windows Installer 패키지를 사용할 때의 이점 및 문제에 대해 설명합니다.

Visual Studio 2005에서 매니페스트를 자동으로 병합하고 실행 파일에 포함하는 데 사용하는 도구인 mt.exe에 대한 버그 및 수정에 대한 자세한 내용은 매니페스트 2부: MsDN의 Chris Jackson 블로그에서 Windows Vista의 기본 네임스페이스 및 UAC 매니페스트 탐색을 참조하세요.