사용자 계정 컨트롤 호환성을 위한 Windows Vista 애플리케이션 개발 요구 사항

 

제니퍼 앨런

업데이트 날짜: 2007년 6월

요약: 이 백서는 애플리케이션 개발자가 사용자 계정 컨트롤을 준수하는 Windows Vista 지원 애플리케이션을 디자인할 수 있도록 지원하기 위한 것입니다. 코드 샘플, 요구 사항 및 모범 사례와 함께 디자인 프로세스에 대한 자세한 단계가 포함되어 있습니다. 이 문서에서는 Windows Vista의 사용자 환경에 대한 기술 업데이트 및 변경 내용에 대해서도 자세히 설명합니다. (인쇄된 페이지 71개).

콘텐츠

사용자 계정 컨트롤을 사용하는 이유
Windows Vista 업데이트
Windows Vista용 신기술
UAC 아키텍처
UAC가 애플리케이션에 영향을 주나요?
Windows Vista용 애플리케이션 디자인
표준 사용자를 위한 애플리케이션 배포 및 패치
일반적인 문제 해결
참조

사용자 계정 컨트롤을 사용하는 이유

애플리케이션 개발자는 과도한 사용자 권한 및 Windows 권한이 필요한 Windows 애플리케이션을 일관되게 만들었으며, 실행 중인 사용자가 관리자여야 하는 경우가 많습니다. 따라서 필요한 최소 사용자 권한 및 Windows 권한으로 실행하는 Windows 사용자는 거의 없습니다. 배포의 용이성과 보안 사용 편의성의 균형을 맞추려는 많은 기업은 표준 사용자 애플리케이션 호환성 문제로 인해 데스크톱을 관리자로 배포하는 데 의존하는 경우가 많습니다.

다음 목록에서는 Microsoft Windows Vista 이전 컴퓨터에서 표준 사용자로 실행하기 어려운 추가 이유를 자세히 설명합니다.

1. 많은 Windows 애플리케이션에서는 로그온한 사용자가 관리자여야 하지만 실제로는 관리자 수준 액세스가 필요하지 않습니다. 이러한 애플리케이션은 다음을 포함하여 실행이 허용되기 전에 다양한 관리자 액세스 검사를 수행합니다.
   • 관리자 액세스 토큰 검사.
   • 시스템 보호 위치의 "모든 액세스" 액세스 요청.
   • %ProgramFiles%, %WinDir%, HKLM\Software와 같은 보호된 위치에 데이터를 씁니다.
2. 대부분의 Windows 애플리케이션은 최소 권한 개념으로 설계되지 않았으며 사용자 및 관리자 기능을 두 개의 개별 프로세스로 분리하지 않습니다.
3. Windows 2000 및 Windows XP는 기본적으로 각 새 사용자 계정을 관리자로 만듭니다. 따라서 날짜 및 시간 및 전원 관리 제어판과 같은 주요 Windows 구성 요소는 표준 사용자에게 제대로 작동하지 않습니다.
4. Windows 2000 및 Windows XP 관리자는 두 개의 개별 사용자 계정을 만들어야 합니다. 하나는 관리 작업용이고 다른 하나는 일상적인 작업을 수행하기 위한 표준 사용자 계정입니다. 따라서 사용자는 표준 사용자 계정을 로그오프하고 관리자 권한으로 다시 로그인하거나 실행 을 사용하여 관리 작업을 수행해야 합니다.

Microsoft는 UAC(사용자 계정 제어)를 사용하여 엔터프라이즈 및 가정에서 표준 사용자 데스크톱 배포를 간소화하는 기술을 제공하고 있습니다.

원래 Microsoft Windows NT 3.1 운영 체제에서 디자인된 Windows 보안 아키텍처를 구축한 UAC 팀은 유연하고 더 안전한 표준 사용자 모델을 구현하려고 했습니다. 이전 버전의 Windows에서는 로그온 프로세스 중에 관리자에 대해 하나의 액세스 토큰이 만들어집니다. 관리자의 액세스 토큰에는 대부분의 Windows 권한과 대부분의 SID(관리 보안 식별자)가 포함됩니다. 이 액세스 토큰은 관리자가 애플리케이션을 설치하고, 운영 체제를 구성하고, 모든 리소스에 액세스할 수 있도록 합니다.

UAC 팀은 Windows Vista의 액세스 토큰 생성 프로세스에 대해 크게 다른 접근 방식을 취했습니다. 관리자 사용자가 Windows Vista 컴퓨터에 로그온하면 필터링된 표준 사용자 액세스 토큰과 전체 관리자 액세스 토큰이라는 두 개의 액세스 토큰이 만들어집니다. 관리자의 액세스 토큰으로 데스크톱(Explorer.exe)을 시작하는 대신 표준 사용자 액세스 토큰이 사용됩니다. 모든 자식 프로세스는 Windows Vista 공격 표면을 제한하는 데 도움이 되는 데스크톱의 초기 시작(explorer.exe 프로세스)에서 상속됩니다. 기본적으로 관리자를 포함한 모든 사용자는 Windows Vista 컴퓨터에 표준 사용자로 로그온합니다.

참고 이전 문에는 한 가지 예외가 있습니다. 게스트는 표준 사용자보다 적은 수의 사용자 권한과 권한으로 컴퓨터에 로그온합니다.

관리자가 애플리케이션 설치와 같은 관리 작업을 수행하려고 하면 UAC에서 사용자에게 작업을 승인하라는 메시지를 표시합니다. 사용자가 작업을 승인하면 관리자의 전체 관리자 액세스 토큰을 사용하여 작업이 시작됩니다. 이는 기본 관리자 프롬프트 동작이며 로컬 보안 정책 관리자 스냅인(secpol.msc) 및 그룹 정책(gpedit.msc)에서 구성할 수 있습니다.

참고 UAC를 사용하도록 설정된 Windows Vista 컴퓨터의 관리자 계정을 관리 승인 모드의 관리자 계정이라고도 합니다. 관리 승인 모드는 관리자의 기본 사용자 환경을 식별합니다.

각 관리 권한 상승은 사용자에게 승인을 요청하지 않고 다른 프로세스가 액세스 토큰을 사용할 수 없도록 하는 프로세스마다 다릅니다. 따라서 관리자 사용자는 로그온한 사용자가 전체 관리자 액세스 토큰을 사용하여 실행될 것으로 예상하는 악성 소프트웨어에 큰 영향을 주면서 설치되는 애플리케이션을 보다 세부적으로 제어할 수 있습니다.

또한 표준 사용자는 UAC 인프라를 사용하여 흐름을 상승시키고 관리 작업을 수행할 수 있습니다. 표준 사용자가 관리 작업을 수행하려고 하면 UAC는 사용자에게 관리자 계정에 대한 유효한 자격 증명을 입력하라는 메시지를 표시합니다. 이는 기본 표준 사용자 프롬프트 동작이며 로컬 보안 정책 관리자 스냅인(secpol.msc) 및 그룹 정책(gpedit.msc)에서 구성할 수 있습니다.

Windows Vista 업데이트

다음 업데이트는 Windows Vista에서 발생한 기능의 누적 코어 변경 내용을 반영합니다.

UAC는 기본적으로 사용됨

따라서 Windows Vista UAC 구성 요소에 대해 아직 업데이트되지 않은 다른 애플리케이션과 호환성 문제가 발생할 수 있습니다. 애플리케이션에 관리자 액세스 토큰이 필요한 경우(애플리케이션을 실행하려고 할 때 반환되는 "액세스 거부" 오류에서 나타낸 것임) 상황에 맞는 메뉴에서 관리자 권한으로 실행 옵션을 사용하여 프로그램을 관리자 권한으로 실행할 수 있습니다(마우스 오른쪽 단추 클릭). 이 작업을 수행하는 방법은 이 문서의 뒷부분에 있는 관리자 권한으로 프로그램 실행 섹션에 설명되어 있습니다.

모든 후속 사용자 계정은 표준 사용자로 만들어집니다.

표준 사용자 계정과 관리자 사용자 계정 모두 UAC 강화된 보안을 활용할 수 있습니다. 새 설치에서 기본적으로 생성된 첫 번째 사용자 계정은 관리 승인 모드(UAC 사용)의 로컬 관리자 계정입니다. 그런 다음 모든 후속 계정이 표준 사용자로 만들어집니다.

권한 상승 프롬프트는 기본적으로 보안 데스크톱에 표시됩니다.

동의 및 자격 증명 프롬프트는 기본적으로 Windows Vista의 보안 데스크톱에 표시됩니다.

백그라운드 애플리케이션에 대한 권한 상승 프롬프트가 작업 표시줄로 최소화됨

백그라운드 애플리케이션은 권한 상승을 위해 보안 데스크톱으로 자동으로 가는 대신 작업 표시줄에서 사용자에게 권한 상승을 요청하는 메시지를 자동으로 표시합니다. 권한 상승 프롬프트가 작업 표시줄에 최소화된 것으로 나타나고 응용 프로그램이 권한 상승을 요청했음을 사용자에게 알리기 위해 깜박입니다. 백그라운드 권한 상승의 예는 사용자가 웹 사이트를 찾아 설치 파일 다운로드를 시작할 때 발생합니다. 그런 다음 설치가 백그라운드에서 다운로드되는 동안 사용자는 검사 전자 메일로 이동합니다. 다운로드가 백그라운드에서 완료되고 설치가 시작되면 권한 상승이 포그라운드 작업이 아닌 백그라운드 작업으로 검색됩니다. 이 검색을 통해 사용자가 전자 메일을 읽는 다른 작업을 수행하는 동안 설치가 사용자 화면의 포커스를 갑자기 훔칠 수 없습니다. 이 동작은 권한 상승 프롬프트에 대한 더 나은 사용자 환경을 만듭니다. 애플리케이션 개발자가 권한 상승을 요청할 때 애플리케이션이 작업 표시줄에 최소화되지 않도록 하는 방법에 대한 정보는 이 문서의 뒷부분에서 사용할 수 있습니다.

사용자의 로그온 경로에서 권한 상승이 차단됨

사용자가 로그온하고 권한 상승이 필요한 경우 시작되는 애플리케이션은 이제 로그온 경로에서 차단됩니다. 애플리케이션이 사용자의 로그온 경로에서 권한 상승을 요청하는 것을 차단하지 않으면 표준 사용자와 관리자 모두 로그온할 때마다 사용자 계정 컨트롤 대화 상자에 응답해야 합니다. Windows Vista는 시스템 트레이에 아이콘을 배치하여 애플리케이션이 차단되었는지 사용자에게 알립니다. 그런 다음 사용자가 이 아이콘을 마우스 오른쪽 단추로 클릭하여 사용자가 로그온할 때 권한 상승을 요청하지 못하도록 차단된 애플리케이션을 실행할 수 있습니다. 사용자는 트레이 아이콘을 두 번 클릭하여 사용하지 않도록 설정되거나 이 목록에서 제거된 시작 애플리케이션을 관리할 수 있습니다.

기본 제공 관리자 계정은 새 설치에서 기본적으로 사용하지 않도록 설정됨

기본 제공 관리자 계정은 Windows Vista에서 기본적으로 사용하지 않도록 설정됩니다. Windows Vista가 Windows XP에서 업그레이드하는 동안 기본 제공 관리자가 유일한 활성 로컬 관리자 계정임을 확인하는 경우 Windows Vista는 계정을 사용하도록 설정된 상태로 두고 계정을 관리 승인 모드로 전환합니다. 기본 제공 관리자 계정은 기본적으로 안전 모드에서 컴퓨터에 로그온할 수 없습니다. 자세한 내용은 다음 섹션을 참조하세요. 기본 제공 관리자 계정은 사용자 이름 관리자를 사용하여 설치하는 동안 만들어집니다.

도메인에 가입되지 않은 경우

사용하도록 설정된 로컬 관리자 계정이 하나 이상 있는 경우 안전 모드에서는 사용하지 않도록 설정된 기본 제공 관리자 계정으로 로그온을 허용하지 않습니다. 대신 로컬 관리자 계정을 사용하여 로그온할 수 있습니다. 마지막 로컬 관리자 계정이 실수로 강등, 비활성화 또는 삭제된 경우 안전 모드에서는 비활성화된 기본 제공 관리자 계정이 재해 복구를 위해 로그온할 수 있습니다.

도메인 조인됨

모든 경우에 사용하지 않도록 설정된 기본 제공 관리자 계정은 안전 모드로 로그온할 수 없습니다. Domain Admins 그룹의 구성원인 사용자 계정은 컴퓨터에 로그온하여 로컬 관리자가 없는 경우 만들 수 있습니다.

참고 도메인 관리 계정이 이전에 로그온한 적이 없는 경우 자격 증명이 캐시되지 않았으므로 컴퓨터를 네트워킹을 사용하는 안전 모드에서 시작해야 합니다.

참고 컴퓨터가 연결 해제되면 이전에 표시된 도메인에 가입되지 않은 동작으로 다시 되돌리기.

사용자 계정 제어 및 원격 시나리오

관리자가 원격으로 Windows Vista 컴퓨터에 로그온하는 경우 instance 원격 데스크톱을 통해 사용자는 기본적으로 표준 사용자로 컴퓨터에 로그온됩니다. 원격 관리가 유선에서 제한되도록 수정되었습니다. 이렇게 하면 사용자가 관리 가능성으로 실행되는 경우 악성 소프트웨어가 애플리케이션 "루프백"을 수행하지 못하도록 방지할 수 있습니다.

로컬 사용자 계정

Windows Vista 컴퓨터의 SAM(로컬 보안 계정 관리자) 데이터베이스에 관리자 계정이 있는 사용자가 Windows Vista 컴퓨터에 원격으로 연결하는 경우 사용자는 원격 컴퓨터에서 상승 가능성이 없으며 관리 작업을 수행할 수 없습니다. 사용자가 SAM 계정으로 워크스테이션을 관리하려는 경우 사용자는 관리할 컴퓨터에 대화형으로 로그온해야 합니다.

도메인 사용자 계정

도메인 사용자 계정이 있는 사용자가 관리자 그룹의 구성원인 Windows Vista 컴퓨터에 원격으로 로그온하면 도메인 사용자는 원격 컴퓨터에서 전체 관리자 액세스 토큰으로 실행되고 UAC는 적용되지 않습니다.

새 기본 Access Control 목록(ACL) 설정

특정 Windows 디렉터리의 ACL은 데이터 디렉터리 및 사용자의 보호된 디렉터리 외부에서 데이터 공유 및 공동 작업을 사용하도록 변경되었습니다. 사용자의 보호된 디렉터리가 사용자 프로필(예: C:\Users\Denise\Pictures\)이고, 데이터 디렉터리의 예는 데이터 드라이브의 운영 체제 파티션 외부 위치(예: D:\Pictures\)입니다. 이 instance 루트 디렉터리 C는 더 제한적인 ACL로 보호되므로 사용자는 초기 버전의 Windows Vista에서 데이터 디렉터리를 사용할 수 없습니다.

이러한 ACL 변경은 사용자가 사용자 계정 컨트롤 대화 상자에 승인을 제공하지 않고도 파일을 공유하고 편집할 수 있도록 합니다. 또한 사용자는 이제 폴더를 비공개로 만들 수 있습니다. 이렇게 변경하면 사용자가 데이터 드라이브에서 데이터 기밀성 및 무결성을 쉽게 유지할 수 있습니다. 이러한 프라이빗 폴더는 다른 관리자가 상승하는 경우에도 계속 읽을 수 있으며 표준 사용자로부터 데이터를 비공개로 유지하는 데 사용해야 합니다.

다음은 %systemroot% 및 Windows XP의 데이터 드라이브에 대한 기본 ACL 설정입니다.

Windows XP %systemroot% 및 데이터 드라이브 ACL 설정

사용자 또는 그룹	Access Control 항목
BUILTIN\Administrators	모든 권한
NT AUTHORITY\SYSTEM	모든 권한
CREATOR OWNER	모든 권한
BUILTIN\Users	읽기 특별 액세스: FILE_APPEND_DATA 특별 액세스: FILE_WRITE_DATA
모든 사람	읽기

다음 표에서는 format.exe 사용하여 만든 데이터 드라이브에 대한 새로운 Windows Vista 데이터 드라이브 ACL 설정을 자세히 설명합니다.

Windows Vista 데이터 드라이브 ACL 설정

사용자 또는 그룹	Access Control 항목
BUILTIN\Administrators	모든 권한
NT AUTHORITY\SYSTEM	모든 권한
NT AUTHORITY\Authenticated Users	수정
BUILTIN\Users	읽기 및 실행 일반 읽기, 제네릭 실행

다음 표에서는 새 Windows Vista 운영 체제 루트(%systemroot%) ACL 설정에 대해 자세히 설명합니다.

Windows Vista %systemroot% ACL 설정

사용자 또는 그룹	Access Control 항목
BUILTIN\Administrators	모든 권한
NT AUTHORITY\SYSTEM	모든 권한
BUILTIN\Users	읽기 및 실행
NT AUTHORITY\Authenticated Users	수정 데이터 추가
필수 레이블\높은 필수 수준	쓰기 없음

새 UAC 보안 설정 및 보안 설정 이름 변경

새 보안 설정 및 보안 설정 이름 업데이트는 이 문서의 참조 섹션에 자세히 설명되어 있습니다.

Windows Vista용 신기술

다음 섹션에서는 설치 관리자 검색, Windows Installer 4.0을 사용하는 표준 사용자 패치, 사용자 인터페이스 권한 격리 및 가상화를 비롯한 Windows Vista의 새로운 기술에 대해 자세히 설명합니다.

ActiveX 설치 관리자 서비스

ActiveX 설치 관리자 서비스를 사용하면 기업에서 표준 사용자에 대해 ActiveX 제어 설치를 위임할 수 있습니다. 이 서비스는 실패한 ActiveX 제어 설치 및 업데이트로 인해 일상적인 비즈니스 작업이 방해받지 않도록 합니다. Windows Vista에는 IT 전문가가 표준 사용자가 ActiveX 컨트롤을 설치할 수 있는 호스트 URL을 정의할 수 있는 그룹 정책 설정도 포함되어 있습니다. ActiveX Installer Service는 Windows 서비스, 그룹 정책 관리 템플릿 및 인터넷 Explorer 일부 변경 내용으로 구성되며 설치된 클라이언트에서만 사용하도록 설정되는 선택적 구성 요소입니다.

설치 관리자 검색

설치 프로그램은 소프트웨어를 배포하도록 설계된 애플리케이션이며 대부분 시스템 디렉터리 및 레지스트리 키에 기록됩니다. 이러한 보호된 시스템 위치는 일반적으로 관리자 사용자만 쓸 수 있습니다. 즉, 표준 사용자는 프로그램을 설치하기에 충분한 액세스 권한이 없습니다. Windows Vista는 액세스 권한으로 실행하기 위해 설치 프로그램을 추론적으로 검색하고 관리자 자격 증명 또는 관리자 사용자의 승인을 요청합니다. 또한 Windows Vista는 업데이트 프로그램 및 설치 취소 프로그램을 추론적으로 검색합니다. UAC의 디자인 목표는 파일 시스템 및 레지스트리의 보호된 영역에 쓰기 때문에 사용자의 지식과 동의 없이 설치가 실행되지 않도록 하는 것입니다.

중요 Windows Vista용 프로그램 개발과 마찬가지로 새 설치 프로그램을 개발할 때는 적절한 요청된ExecutionLevel 요소가 포함된 애플리케이션 매니페스트를 포함해야 합니다(6단계: 애플리케이션 매니페스트 만들기 및 애플리케이션에 애플리케이션 매니페스트 포함 섹션 참조). requestedExecutionLevel이 포함된 애플리케이션 매니페스트에 있으면 설치 관리자 검색을 재정의합니다.

설치 관리자 검색은 다음에만 적용됩니다.

• 32비트 실행 파일
• requestedExecutionLevel이 없는 애플리케이션
• LUA를 사용하도록 설정된 표준 사용자로 실행되는 대화형 프로세스

32비트 프로세스를 만들기 전에 다음 특성을 확인하여 설치 관리자인지 확인합니다.

• 파일 이름에는 "install", "setup", "update" 등의 키워드가 포함되어 있습니다.
• 다음 버전 관리 리소스 필드의 키워드: 공급업체, 회사 이름, 제품 이름, 파일 설명, 원래 파일 이름, 내부 이름 및 내보내기 이름입니다.
• 실행 파일에 포함된 병렬 매니페스트의 키워드입니다.
• 실행 파일에 연결된 특정 StringTable 항목의 키워드입니다.
• 실행 파일에 연결된 RC 데이터의 주요 특성입니다.
• 실행 파일 내의 대상 바이트 시퀀스입니다.

참고 키워드 및 바이트 시퀀스는 다양한 설치 관리자 기술에서 관찰되는 일반적인 특성에서 파생되었습니다.

6단계: 애플리케이션에 애플리케이션 매니페스트 만들기 및 포함 섹션을 포함하여 이 문서 전체를 철저히 검토해야 합니다.

참고설치 프로그램을 검색하려면 사용자 계정 컨트롤: 애플리케이션 설치 검색 및 권한 상승 요청 설정을 사용하도록 설정해야 합니다. 이 설정은 기본적으로 사용하도록 설정되며 보안 정책 관리자 스냅인(secpol.msc) 또는 그룹 정책(gpedit.msc)를 사용하여 구성할 수 있습니다.

Microsoft Windows Installer 에 대한 일반 정보 및 개요는 MSDN 라이브러리에서 찾을 수 있습니다.

UAC 환경에서 애플리케이션 패치

Microsoft Windows Installer 4.0은 애플리케이션 설치 및 패치를 더 쉽게 만들기 위해 UAC를 염두에 두고 설계되었습니다. Windows Installer 4.0이 도입되면 최신 버전의 애플리케이션을 다시 설치하지 않고도 애플리케이션에 패치를 적용할 수 있습니다. 이 방법은 애플리케이션이 컴퓨터별 설치에 배포되고 관리 액세스 토큰 없이 사용자가 패치를 배포해야 하는 경우에 이상적입니다. 애플리케이션에 패치를 만들고 적용하는 방법에 대한 자세한 내용은 패치 Per-User 관리되는 애플리케이션을 참조하세요.

Security Center 통합

Windows Vista 컴퓨터에서 UAC를 사용하지 않도록 설정하면 Security Center에서 경고를 만들고 사용자에게 UAC를 다시 사용하도록 설정하라는 메시지를 표시합니다. Security Center는 UAC 설정이 변경된 후 컴퓨터를 다시 시작하면 이 경고를 표시합니다.

사용자 인터페이스 권한 격리

UIPI(사용자 인터페이스 권한 격리)는 전체 관리자로 실행되는 애플리케이션을 동일한 대화형 데스크톱의 관리자보다 낮은 계정으로 실행되는 프로세스에서 격리하는 데 도움이 되는 메커니즘 중 하나입니다. UIPI는 창 및 사용자 인터페이스 컨트롤을 지원하는 USER라고 하는 창 및 그래픽 하위 시스템에만 적용됩니다. UIPI는 낮은 권한 애플리케이션이 Windows 메시지를 사용하여 한 프로세스에서 더 높은 권한 프로세스로 입력을 보내는 것을 방지합니다. 한 프로세스에서 다른 프로세스로 입력을 보내면 사용자가 키보드 또는 마우스 작업을 제공하지 않고 다른 프로세스에 입력을 삽입할 수 있습니다.

UIPI의 개념은 간단합니다. Windows Vista는 계층적 방식으로 사용자 인터페이스 권한 수준 집합을 정의합니다. 수준의 특성은 높은 권한 수준이 낮은 수준에서 실행되는 애플리케이션에 창 메시지를 보낼 수 있도록 하기 위한 것입니다. 그러나 하위 수준은 더 높은 수준에서 애플리케이션 창에 창 메시지를 보낼 수 없습니다.

사용자 인터페이스 권한 수준은 프로세스 수준에 있습니다. 프로세스가 초기화되면 사용자 하위 시스템은 보안 하위 시스템을 호출하여 프로세스의 보안 액세스 토큰에 할당된 데스크톱 무결성 수준을 결정합니다. 데스크톱 무결성 수준은 프로세스가 만들어지고 변경되지 않을 때 보안 하위 시스템에 의해 설정됩니다. 따라서 사용자 인터페이스 권한 수준은 프로세스가 만들어지고 변경되지 않을 때 사용자 하위 시스템에 의해 설정됩니다.

표준 사용자가 실행하는 모든 애플리케이션에는 동일한 사용자 인터페이스 권한 수준이 있습니다. 표준 사용자로서 애플리케이션은 단일 권한 수준에서 실행됩니다. UIPI는 동일한 권한 수준에서 애플리케이션 간의 창 메시징 동작을 방해하거나 변경하지 않습니다. UIPI는 관리자 그룹의 구성원이며 표준 사용자(필터링된 액세스 토큰이 있는 프로세스라고도 함)로 애플리케이션을 실행할 수 있는 사용자에 대해 적용되며 동일한 데스크톱에서 전체 관리자 액세스 토큰으로 실행되는 프로세스도 적용됩니다. UIPI는 다음 동작을 차단하여 낮은 권한 프로세스가 더 높은 권한 프로세스에 액세스하지 못하도록 방지합니다.

낮은 권한 프로세스는 다음을 수행할 수 없습니다.

• 더 높은 프로세스 권한의 창 핸들 유효성 검사를 수행합니다.
• SendMessage 또는 PostMessage를 더 높은 권한의 애플리케이션 창으로 보냅니다. 이러한 API(애플리케이션 프로그래밍 인터페이스)는 성공을 반환하지만 창 메시지를 자동으로 삭제합니다.
• 스레드 후크를 사용하여 더 높은 권한 프로세스에 연결합니다.
• 저널 후크를 사용하여 더 높은 권한 프로세스를 모니터링합니다.
• 더 높은 권한 프로세스에 동적 링크 라이브러리(DLL) 주입을 수행합니다.

UIPI를 사용하도록 설정하면 다음과 같은 공유 사용자 리소스가 서로 다른 권한 수준의 프로세스 간에 공유됩니다.

• 화면 화면을 실제로 소유하는 바탕 화면 창
• 데스크톱 힙 읽기 전용 공유 메모리
• 전역 원자 테이블
• 클립보드

화면에 그리는 작업은 UIPI에 의해 차단되지 않는 또 다른 작업입니다. 화면에 그리는 것은 그림판 메서드를 사용하여 외부 출력(예: 모니터)에 콘텐츠를 표시하는 프로세스를 의미합니다. USER/Graphics GDI(디바이스 인터페이스) 모델은 그리기 표면을 제어할 수 없습니다. 따라서 더 낮은 권한 애플리케이션이 더 높은 권한 애플리케이션 창의 표면 영역에 그릴 수 있습니다.

참고 Windows 셸(Explorer)이 표준 사용자 프로세스로 실행되고 있으므로 표준 사용자로 실행되는 다른 모든 프로세스는 여전히 키 입력을 보낼 수 있습니다. 이는 Setup.exe 두 번 클릭하거나 권한 상승 방패 아이콘을 클릭하는 등의 관리 작업을 시작할 때 관리 승인 모드의 관리자 계정에 권한 상승 동의를 묻는 메시지가 표시되는 주된 이유입니다.

가상화

중요 가상화는 Windows Vista에서 표준 사용자로 실행되는 애플리케이션의 애플리케이션 호환성 문제를 개선하기 위해 구현됩니다. 개발자는 후속 버전의 Windows에 있는 가상화에 의존해서는 안 됩니다.

Windows Vista 이전에는 일반적으로 관리자가 많은 애플리케이션을 실행했습니다. 따라서 애플리케이션은 시스템 파일 및 레지스트리 키를 자유롭게 읽고 쓸 수 있습니다. 이러한 애플리케이션이 표준 사용자에 의해 실행된 경우 액세스 권한이 부족하여 실패합니다. Windows Vista는 쓰기(및 후속 파일 또는 레지스트리 작업)를 사용자 프로필 내의 사용자별 위치로 리디렉션하여 이러한 사용자의 애플리케이션 호환성을 향상시킵니다. 예를 들어 애플리케이션이 C:\Program Files\Contoso\Settings.ini 쓰기를 시도하고 사용자에게 해당 디렉터리에 쓸 수 있는 권한이 없는 경우 쓰기는 C:\Users\<user name>\AppData\Local\VirtualStore\Program Files\contoso\settings.ini 리디렉션됩니다. 레지스트리의 경우 애플리케이션이 HKEY_LOCAL_MACHINE\Software\Contoso\ 쓰기를 시도하면 자동으로 HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso 또는 HKEY_USERS\< 사용자 SID >_Classes\VirtualStore\Machine\Software\Contoso로 리디렉션됩니다.

다음 그림에서는 Windows Vista의 가상화 프로세스를 자세히 설명합니다. 이 예제에서 Denise는 관리 승인 모드의 관리자이고 Brian은 표준 사용자입니다. 가상화는 파일 가상화 및 레지스트리 가상화의 두 가지 구성 요소로 구성됩니다.

그림 1. 가상화 프로세스

중요 Windows Vista 프로그램을 개발하는 동안 가상화된 파일 및 레지스트리 키의 복잡성을 줄이려면 파일 및 레지스트리 가상화를 해제하려면 적절한 requestExecutionLevel과 함께 애플리케이션 매니페스트를 포함해야 합니다.

가상화는 다음 경우에만 사용하도록 설정됩니다.

• 32비트 대화형 프로세스
• 관리자 쓰기 가능한 파일/폴더 및 레지스트리 키

가상화는 다음을 위해 사용하지 않도록 설정됩니다.

• 64비트 프로세스
• 비대화형 프로세스
• 가장하는 프로세스
• 커널 모드 호출자
• requestedExecutionLevel이 있는 실행 파일

가상화 및 로밍:

• 가상화 파일/폴더 및 레지스트리 키가 로밍되지 않음(로밍 프로필 참조)
• 로밍하지 않는 전역 개체와 연결됨

파일 가상화

파일 가상화는 애플리케이션이 일반적으로 관리자만 쓸 수 있는 시스템 위치에 구성 파일과 같은 파일을 저장하는 기능을 사용하는 상황을 해결합니다. 이 상황에서 표준 사용자로 프로그램을 실행하면 액세스 수준이 부족하여 프로그램 오류가 발생할 수 있습니다.

애플리케이션이 관리자만 쓸 수 있는 시스템 위치에 쓰는 경우 Windows는 모든 후속 파일 작업을 %LOCALAPPDATA%\VirtualStore에 있는 Virtual Store 디렉터리 아래의 사용자별 경로에 씁니다. 나중에 애플리케이션이 이 파일을 다시 읽으면 시스템은 가상 저장소에 파일을 제공합니다. Windows 보안 인프라는 애플리케이션의 도움 없이 가상화를 처리하므로 애플리케이션은 프로그램 파일을 직접 읽고 쓸 수 있다고 믿습니다. 파일 가상화의 투명성을 통해 애플리케이션은 실제로 가상화된 버전에 액세스할 때 보호된 리소스에서 쓰고 읽고 있다는 인식을 할 수 있습니다.

참고 폴더 및 레지스트리에서 리소스를 열거하는 경우 Windows Vista는 전역 파일/폴더 및 레지스트리 키를 단일 목록으로 병합합니다. 이 병합된 보기에서는 전역(보호된) 리소스가 가상화된 리소스와 함께 나열됩니다.

중요 가상 복사본은 항상 애플리케이션에 먼저 표시됩니다. 예를 들어 config.ini \PF\App\config.ini 및 %LOCALAPPDATA%\VirtualStore\config.ini 사용할 수 있으며, \PF\App\config.ini 업데이트되더라도 가상 저장소의 config.ini 항상 하나의 읽기가 됩니다.

다음 그림에서는 가상화된 리소스에 대한 전역 및 병합된 뷰가 다른 사용자에 대해 표시되는 방법을 자세히 설명합니다.

그림 2. 가상화된 리소스 및 뷰

다음은 파일 가상화 프로세스의 예입니다.

우드그로브 은행의 영업 담당자인 Syed Abbas는 다른 영업 담당자와 공유하는 컴퓨터의 표준 사용자 계정으로 운영되고 있습니다. Syed는 종종 스프레드시트 애플리케이션을 사용하여 Program Files\SalesV1\ 디렉터리에서 파일을 업데이트하고 저장합니다. \Program Files\SalesV1\SalesData.txt. Program Files\SalesV1\는 보호되지만 Windows Vista 파일 가상화로 인해 스프레드시트 애플리케이션의 관점에서 파일이 성공적으로 저장됩니다. 이를 위해 파일 쓰기는 Users\username\appdata\Virtual Store\Program Files\SalesV1\SalesData.txt 리디렉션됩니다. Syed가 Windows Explorer 열고 Program Files 디렉터리로 이동하면 SalesData.txt 파일의 전역 보기가 표시됩니다.

참고 Syed가 가상화된 파일을 검색하려면 Explorer 도구 모음의 호환성 파일 단추가 있는 가상 저장소로 이동해야 합니다.

그러나 다른 영업 담당자인 Stuart Munson이 워크스테이션에 로그인한 후에는 Program Files\SalesV1\ 디렉터리에 SalesData.txt 파일이 표시되지 않습니다. 다른 사용자가 컴퓨터를 사용하고 \Program files\SalesV1\SalesData.txt 파일을 쓰는 경우 해당 쓰기는 해당 사용자의 가상 저장소에도 가상화됩니다. Syed 파일 업데이트 및 저장은 시스템의 다른 가상화된 파일과 독립적으로 유지됩니다.

레지스트리 가상화

레지스트리 가상화는 파일 가상화와 유사하지만 HKEY_LOCAL_MACHINE\SOFTWARE 레지스트리 키에 적용됩니다. 이 기능을 사용하면 HKEY_LOCAL_MACHINE\SOFTWARE 구성 정보를 저장하는 기능을 사용하는 애플리케이션이 표준 사용자 계정으로 실행되면 계속 진행할 수 있습니다. 키와 데이터는 HKEY_CLASSES_ROOT\VirtualStore\SOFTWARE 리디렉션됩니다. 파일 가상화 사례와 마찬가지로 각 사용자는 애플리케이션이 HKLM에 저장한 모든 값의 가상화된 복사본을 갖습니다.

레지스트리 가상화 세부 정보

• 소프트웨어 하이브의 개별 키에서 켜기/끌 수 있습니다.
• 키 수준 가상화 제어에 대한 reg.exe 새 FLAGS 옵션: 가상화의 재귀 사용/사용 안 함 및 "액세스 권한 정책 열기" 제어 허용
• ZwQueryKey: 프로그래밍 방식으로 키에 대한 가상화 플래그를 쿼리합니다.
• 가상화는 WoW64 리디렉션을 기반으로 발생합니다.
• 64비트 및 32비트 레지스트리 보기에서 모두 사용하도록 설정됨: HKU\{SID}_Classes\VirtualStore\Machine\Software and HKU\{SID}_Classes\VirtualStore\Machine\Software\SYSWOW3264
• 대부분의 레거시 32비트 앱은 32비트 보기를 사용합니다.

가상화는 기존 프로그램과의 애플리케이션 호환성을 지원하기 위한 것입니다. Windows Vista용으로 설계된 애플리케이션은 중요한 시스템 영역에 대한 쓰기를 수행해서는 안 되며, 잘못된 애플리케이션 동작에 대한 시정을 제공하기 위해 가상화에 의존해서는 안 됩니다. Windows Vista에서 실행되도록 기존 코드를 업데이트할 때 개발자는 런타임 중에 애플리케이션이 ACL(액세스 제어 목록) 설정이 올바르게 설정된 %alluserprofile% (CSIDL_COMMON_APPDATA) 내의 사용자별 위치 또는 컴퓨터 위치에만 데이터를 저장해야 합니다.

중요 Microsoft는 더 많은 애플리케이션이 Windows Vista로 마이그레이션됨에 따라 향후 버전의 Windows 운영 체제에서 가상화를 제거할 계획입니다. 예를 들어 가상화는 64비트 애플리케이션에서 사용하지 않도록 설정됩니다.

가상화 권장 사항

가상화는 기존 프로그램과의 애플리케이션 호환성을 지원하기 위한 것입니다. Windows Vista용으로 설계된 애플리케이션은 중요한 시스템 영역에 대한 쓰기를 수행해서는 안 되며, 잘못된 애플리케이션 동작에 대한 시정을 제공하기 위해 가상화에 의존해서는 안 됩니다. Windows Vista에서 실행되도록 기존 코드를 업데이트할 때 개발자는 런타임 동안 애플리케이션이 ACL(액세스 제어 목록) 설정이 올바르게 설정된 %alluserprofile% 내의 사용자별 위치 또는 컴퓨터 위치에만 데이터를 저장해야 합니다.

중요 Microsoft는 더 많은 애플리케이션이 Windows Vista로 마이그레이션됨에 따라 향후 버전의 Windows 운영 체제에서 가상화를 제거할 계획입니다. 예를 들어 가상화는 64비트 애플리케이션에서 사용하지 않도록 설정됩니다.

• 대화형 애플리케이션에 적절한 requestedExecutionLevel을 사용하여 애플리케이션 매니페스트를 추가합니다. 그러면 매니페스트된 애플리케이션에 대한 가상화가 꺼집니다.
• 레지스트리를 프로세스 간 통신 메커니즘으로 사용하지 마세요. 서비스 및 사용자 애플리케이션은 키에 대해 서로 다른 보기를 갖습니다.
• Windows Vista에서 애플리케이션 테스트: 표준 사용자로 실행되는 프로세스가 %systemroot%와 같은 전역 네임스페이스에 쓰지 않는지 확인합니다.
• 필터 드라이버 개발자의 경우: 고도 범위를 확인합니다. 파일 시스템 필터를 참조하세요. FSFilter 가상화보다 높아야 합니다.
• 가상화된 리소스는 전역 리소스의 사용자별 복사본입니다.

액세스 토큰 변경 내용

사용자가 Windows Vista 컴퓨터에 로그온하면 Windows는 사용자 계정이 소유한 관리 Windows 권한 및 ID(상대 ID)를 확인하여 사용자가 두 개의 액세스 토큰(필터링된 액세스 토큰 및 전체 액세스 토큰)을 받아야 하는지 여부를 확인합니다. 다음 중 하나가 true인 경우 Windows에서 사용자에 대한 두 개의 액세스 토큰을 만듭니다.

1. 사용자의 계정에는 다음 RID가 포함됩니다.
   • DOMAIN_GROUP_RID_ADMINS
   • DOMAIN_GROUP_RID_CONTROLLERS
   • DOMAIN_GROUP_RID_CERT_ADMINS
   • DOMAIN_GROUP_RID_SCHEMA_ADMINS
   • DOMAIN_GROUP_RID_ENTERPRISE_ADMINS
   • DOMAIN_GROUP_RID_POLICY_ADMINS
   • DOMAIN_ALIAS_RID_ADMINS
   • DOMAIN_ALIAS_RID_POWER_USERS
   • DOMAIN_ALIAS_RID_ACCOUNT_OPS
   • DOMAIN_ALIAS_RID_SYSTEM_OPS
   • DOMAIN_ALIAS_RID_PRINT_OPS
   • DOMAIN_ALIAS_RID_BACKUP_OPS
   • DOMAIN_ALIAS_RID_RAS_SERVERS
   • DOMAIN_ALIAS_RID_PREW2KCOMPACCESS
   • DOMAIN_ALIAS_RID_NETWORK_CONFIGURATION_OPS
   • DOMAIN_ALIAS_RID_CRYPTO_OPERATORS
2. 사용자의 계정에는 표준 사용자 계정 이외의 모든 권한이 포함됩니다. 표준 사용자 계정에는 다음 권한만 포함됩니다.
   • SeChangeNotifyPrivilege
   • SeShutdownPrivilege
   • SeUndockPrivilege
   • SeIncreaseWorkingSetPrivilege
   • SeTimeZonePrivilege

필터링된 토큰에 포함된 권한은 원래 토큰에 위에 나열된 제한된 RIDS가 포함되어 있는지 여부에 따라 달라집니다. 제한된 RID가 토큰에 있는 경우 다음을 제외하고 모든 권한이 제거됩니다.

• SeChangeNotifyPrivilege
• SeShutdownPrivilege
• SeUndockPrivilege
• SeReserveProcessorPrivilege
• SeTimeZonePrivilege

토큰에 제한된 RID가 없으면 다음 권한만 제거됩니다.

• SeCreateTokenPrivilege
• SeTcbPrivilege
• SeTakeOwnershipPrivilege
• SeBackupPrivilege
• SeRestorePrivilege
• SeDebugPrivilege
• SeImpersonatePrivilege
• SeRelabelPrivilege

필터링된 액세스 토큰이라고 하는 첫 번째 액세스 토큰에는 액세스 토큰의 USE_FOR_DENY_ONLY 표시된 이전 RID(있는 경우)와 이전에 나열되지 않은 관리 Windows 권한이 제거되었습니다. 필터링된 액세스 토큰은 사용자가 애플리케이션을 시작하면 기본적으로 사용됩니다. 연결된 액세스 토큰이라고 하는 수정되지 않은 전체 액세스 토큰은 필터링된 액세스 토큰에 연결되며 전체 관리 액세스 토큰으로 애플리케이션을 시작하라는 요청이 있을 때 사용됩니다.

RID에 대한 자세한 내용은 MSDN 라이브러리 문서 SID 문자열 [보안]에서 찾을 수 있습니다.

Windows 권한에 대한 자세한 내용은 MSDN 라이브러리 문서 권한 부여 상수 [보안]에서 찾을 수 있습니다.

UAC 아키텍처

다음 다이어그램은 Windows Vista에서 실행 파일 실행에 대한 프로세스 흐름을 나타냅니다.

그림 3. UAC 아키텍처

다음은 UAC 아키텍처 다이어그램에 표시되는 프로세스 흐름과 실행 파일이 실행될 때 UAC가 구현되는 방법에 대한 설명입니다.

표준 사용자 시작 경로

Windows Vista 표준 사용자 시작 경로는 Windows XP 시작 경로와 유사하지만 일부 수정 사항이 포함되어 있습니다.

• ShellExecute()는 CreateProcess()를 호출합니다.
• CreateProcess()는 AppCompat, Fusion 및 Installer 검색을 호출하여 애플리케이션에 상승이 필요한지 평가합니다. 그런 다음 실행 파일을 검사하여 실행 파일의 애플리케이션 매니페스트에 저장된 requestedExecutionLevel을 확인합니다. AppCompat 데이터베이스는 애플리케이션의 애플리케이션 호환성 수정 항목에 대한 정보를 저장합니다. 설치 관리자 검색은 설치 실행 파일을 검색합니다.
• CreateProcess()는 ERROR_ELEVATION_REQUIRED 나타내는 Win32 오류 코드를 반환합니다.
• ShellExecute()는 이 새 오류를 구체적으로 찾고 수신 시 AIS(애플리케이션 정보 서비스)를 호출하여 관리자 권한 실행을 시도합니다.

관리자 권한 시작 경로

Windows Vista 관리자 권한 시작 경로는 새 Windows 시작 경로입니다.

• AIS는 ShellExecute()에서 호출을 받고 요청된 실행 수준을 다시 평가하고 그룹 정책 권한 상승이 허용되는지 확인하고 권한 상승 사용자 환경을 정의합니다.
• 요청된 실행 수준에 상승이 필요한 경우 서비스는 ShellExecute()에서 전달된 HWND를 사용하여 호출자의 대화형 데스크톱(그룹 정책 기반)에서 권한 상승 프롬프트를 시작합니다.
• 사용자가 동의 또는 유효한 자격 증명을 제공하면 AIS는 필요한 경우 적절한 사용자와 연결된 해당 액세스 토큰을 검색합니다. 예를 들어 highestAvailable의 requestedExecutionLevel을 요청하는 애플리케이션은 로컬 Administrators 그룹의 구성원과 백업 연산자 그룹의 구성원일 뿐인 사용자에 대해 다른 액세스 토큰을 검색합니다.
• AIS는 CreateProcessAsUser() 호출을 다시 발급하여 관리자 액세스 토큰을 제공하고 호출자의 대화형 데스크톱을 지정합니다.

UAC가 애플리케이션에 영향을 주나요?

애플리케이션이 UAC의 영향을 받는지 여부는 애플리케이션의 현재 상태에 따라 달라집니다. 많은 경우 Microsoft Windows 보안 요구 사항을 준수하기 위해 변경이 필요하지 않습니다. 그러나 LOB(기간 업무) 애플리케이션을 비롯한 일부 애플리케이션은 Windows Vista UAC 환경에서 제대로 작동하려면 설치, 기능 및 업데이트 프로세스를 변경해야 할 수 있습니다.

참고 애플리케이션이 Windows XP의 표준 사용자와 잘 작동하는 경우 Windows Vista에서 표준 사용자로 잘 작동합니다.

애플리케이션의 관리 종속성을 제거해야 하는 이유는 무엇인가요?

전체 컴퓨팅 환경의 보안을 강화하기 위한 한 가지 기본 단계는 사용자가 관리 액세스 토큰을 사용하지 않고 실행할 수 있도록 하는 것입니다. 사용자가 관리자인 경우에만 애플리케이션이 작동하거나 설치되는 경우 사용자는 불필요한 관리자 권한으로 애플리케이션을 실행해야 합니다. 근본적인 문제는 사용자가 항상 상승된 액세스 토큰을 사용하여 애플리케이션을 실행해야 하는 경우 기만적이거나 악의적인 코드가 운영 체제를 쉽게 수정하거나 다른 사용자에게 영향을 줄 수 있다는 것입니다.

Microsoft의 목표는 고객이 애플리케이션이 불필요하게 관리자로 실행되어서는 안 된다는 것을 이해하고 애플리케이션의 관리자 권한으로 실행 요청을 승인하라는 요청을 받을 때마다 질문하는 것입니다. UAC는 이 목표를 달성하는 데 도움이 되는 기본 구성 요소이며 모든 사용자에 대해 보다 안전한 컴퓨팅 환경을 복원하는 데 큰 도움이 될 것입니다.

애플리케이션의 총 소유 비용 절감

표준 사용자 계정은 TCO(총 소유 비용)를 줄이면서 관리되는 머신에 대한 보안 및 제어를 강화하는 데 관심이 있는 IT 관리자에게 매우 매력적입니다. 표준 사용자 계정은 시스템을 변경할 수 없으므로 TCO 감소와 애플리케이션 설치 및 시스템 전체 수정을 더 잘 제어하는 직접적인 관계가 있습니다. 표준 사용자 계정은 부모가 자녀와 컴퓨터를 공유하는 가정 사용자에게도 매력적입니다. Microsoft Windows Vista에는 자녀의 사용자 계정을 표준 사용자로 만들어서만 성공적으로 구현되는 통합 자녀 보호 기능이 포함되어 있습니다. 표준 사용자 계정은 다른 사용자가 만든 파일을 변경하거나 삭제할 수도 없습니다. 실수로 또는 의도적으로 다른 사용자의 프로필에서 파일을 읽거나, 시스템 파일을 감염시키거나, 시스템 공유 실행 파일을 변경할 수 없습니다. 표준 사용자 계정은 컴퓨터 보안 및 보호자 통제의 전반적인 개선을 초래합니다.

기본적으로 보안

Microsoft에서는 Microsoft의 신뢰할 수 있는 컴퓨팅 이니셔티브의 신조가 소프트웨어 개발에 스며들어 있습니다. 따라서 향상된 보안은 Windows Vista 개발 프로세스의 필수적인 부분입니다.

신뢰할 수 있는 컴퓨팅의 보안 핵심 요소는 세 가지 기본 사항인 기본적으로 보안, 기본적으로 보안 및 배포 시 보안이라는 세 가지 기본 사항을 포함합니다. 사용자와 다른 ISV가 운영 체제의 전반적인 보안에 기여하도록 애플리케이션을 개발하는 방법은 Windows Vista에서 신뢰할 수 있는 컴퓨팅을 달성하기 위한 주요 성공 요소가 될 것입니다.

이 가이드의 나머지 부분에서는 개발자에게 다음 방법을 교육하는 데 도움을 줍니다.

• 사용자가 일상적인 작업을 수행하는 관리자가 될 필요가 없는 애플리케이션 작성
• 엔터프라이즈의 표준 사용자 데스크톱에 잘 배포하고 가정에서 올바르게 업데이트하는 Windows® Installer 4.0 UAC 패치 기술을 사용하여 설치 패키지를 만듭니다.
• 표준 사용자 및 관리 기능 식별 및 UAC 호환성을 위한 관리 작업 추정
• UAC 기능을 활용하는 애플리케이션 사용자 인터페이스 작성

UAC의 성공을 위해서는 애플리케이션 개발자가 최소 권한의 철학을 수용하고 표준 사용자 계정으로 실행할 때 애플리케이션이 올바르게 작동하도록 디자인해야 합니다.

Windows Vista 릴리스의 목표 중 하나는 모든 개발자에게 관리 승인 모드에서 표준 사용자 및 관리자를 위한 디자인 원칙을 전파하고 장려하는 것입니다. 이 목표를 달성하면 개별 애플리케이션에 대한 다양한 공격을 방지하고 이러한 공격이 시스템의 보안을 손상시킬 가능성을 완화할 수 있습니다. 이러한 목표는 관리자에게 두 계정을 사용하도록 요구하여 어느 정도 달성할 수 있지만 다음과 같은 이유로 실패하는 경향이 있습니다.

• 전체 관리자 액세스 토큰이 있는 사용자를 제어하는 것은 거의 불가능합니다. 관리자는 애플리케이션을 설치하고 원하는 애플리케이션 또는 스크립트를 실행할 수 있습니다. IT 관리자는 항상 사용자가 표준 사용자로 로그온하는 "표준 데스크톱"을 만드는 방법을 찾고 있습니다. 표준 데스크톱은 지원 센터 비용을 크게 줄이고 IT 오버헤드를 줄입니다.
• 사용자가 관리 작업을 수행하려고 할 때마다 계정 간에 전환할 때 상당한 오버헤드가 발생합니다.
• 관리 작업을 수행한 후 사용자는 표준 사용자 계정으로 다시 전환하는 것을 잊어버리거나 다시 전환하기에 너무 많은 노력이 있다고 판단할 수 있습니다.

따라서 사용자는 항상 관리 계정에 로그인하여 보안 조치를 무효화할 수 있습니다. 이를 완화하기 위해 UAC는 관리 승인 모드의 개념을 도입합니다. 관리 승인 모드 사용자 계정은 UAC를 사용하도록 설정된 시스템의 로컬 관리자 그룹의 구성원인 사용자 계정입니다.

엔터프라이즈에서 관리 승인 모드는 Windows Vista로 마이그레이션하기 위한 브리지 기술로 사용됩니다. 이상적으로 기업은 모든 사용자를 표준 사용자로 실행하고 표준 사용자에 대한 권한 상승 프롬프트를 사용하지 않도록 설정하는 것이 좋습니다. 이 설정을 사용하면 SMS(Microsoft Systems Management Server)와 같은 소프트웨어 배포 기술을 사용하여 설치를 배포하는 관리형 표준 데스크톱을 사용할 수 있습니다.

중요 Microsoft는 여전히 Domain Admins 그룹의 구성원이 Windows Vista에서 표준 사용자 계정과 도메인 관리자 사용자 계정이라는 두 개의 개별 사용자 계정을 계속 유지하는 것이 좋습니다. 모든 도메인 관리는 도메인 관리자 계정으로 수행해야 합니다. 보안을 강화하려면 도메인 환경에 스마트 카드 솔루션을 배포하는 것이 좋습니다. 자세한 내용은 스마트 카드 사용 보안 액세스 계획 가이드 를 참조하세요.

다음은 관리 승인 모드에 대한 Windows Vista 디자인 목표입니다.

• 관리자 그룹의 구성원인 사용자를 위한 두 개의 별도 계정이 필요하지 않음: 이 목표는 사용자가 전체 관리 액세스 토큰을 사용하도록 승인을 제공하지 않는 한 표준 사용자 액세스 토큰으로만 프로그램을 실행하여 수행됩니다.
• 전체 관리 액세스 토큰을 사용하여 실행되는 프로세스가 표준 사용자로 실행되는 프로세스에 의해 액세스되거나 수정되지 않도록 보호합니다.
• 관리자와 표준 사용자 작업 영역 간의 원활한 전환을 제공합니다.

현재 대부분의 Windows 애플리케이션은 관리자 권한으로 실행되어야 하지만 실제로는 관리 작업을 수행하지 않습니다. 이러한 애플리케이션은 Microsoft Windows 9x 운영 체제 철학의 부산물입니다. "모든 사람은 관리자입니다."

다음은 문제가 있는 애플리케이션의 예입니다.

• HKLM(HKEY_LOCAL_MACHINE) 또는 파일 시스템 내의 시스템 파일에 불필요하게 쓰는 애플리케이션입니다.
• 웹 인터페이스를 사용하여 기간 업무 애플리케이션을 용이하게 하는 ActiveX 설치입니다.
• 전체 관리 액세스 토큰이 필요한 리소스에 대한 액세스를 불필요하게 요청하는 애플리케이션.

다음 섹션에서는 ISV에 영향을 주는 Windows Vista에 대한 새로운 기술을 제공합니다.

애플리케이션에 관리 종속성이 있는지 확인하려면 어떻게 해야 하나요?

개발자, ISV 및 조직이 애플리케이션을 평가할 수 있도록 Microsoft는 Microsoft 표준 사용자 분석기를 제공합니다. 표준 사용자 분석기를 사용하여 애플리케이션의 비 UAC 규격 동작을 ID화할 수 있습니다. 개발자는 이 도구를 실행하여 표준 사용자 계정으로 애플리케이션을 실행하는 문제를 식별하는 것이 좋습니다. 애플리케이션이 이미 Windows XP의 표준 사용자 계정으로 제대로 설치되고 실행되는 경우에도 이러한 테스트를 수행해야 합니다. 애플리케이션은 시스템 레지스트리 위치에 쓰기를 시도하는 등의 작업을 수행하고 오류 응답 검색과 같은 시스템 동작에 따라 결정을 내릴 수 있습니다. Windows Vista는 새 애플리케이션 호환성 지원이 추가되기 때문에 이전 버전의 Windows 운영 체제와 다르게 동작할 수 있습니다. 따라서 모든 애플리케이션을 표준 사용자 분석기의 새 버전으로 테스트하는 것이 좋습니다.

표준 사용자 분석기는 레지스트리/파일 시스템 액세스 및 관리자 권한 API 호출을 포함하여 애플리케이션에서 발생하는 모든 관리 작업을 기록합니다. 이 데이터는 로그 파일에 저장되고 도구 내에 표시됩니다. 표준 사용자 분석기는 다른 많은 종속성 외에도 다음과 같은 일반적인 종속성을 식별합니다.

• 신뢰할 수 있는 사용자에 대해서만 요청된 액세스를 제한하는 개체에 대한 종속성입니다.

  예를 들어 HKEY_LOCAL_MACHINE 관리자 및 SYSTEM에만 KEY_WRITE 부여합니다. HKEY_LOCAL_MACHINE KEY_WRITE 요청하는 애플리케이션은 UAC 사용으로 작동하지 않습니다.

• 다른 사용자의 프로세스를 디버깅할 수 있고 관리자에게만 부여되는 SE_DEBUG_PRIVILEGE 같은 보안 파급 효과가 있는 Windows 권한을 사용합니다.

합법적인 관리자 애플리케이션이 있는 경우 요구 사항은 무엇인가요?

의도적으로 합법적인 관리 작업을 수행하는 애플리케이션의 경우 Microsoft는 현재 Windows XP 애플리케이션 매니페스트 스키마의 trustInfo 섹션에 대한 확장을 구현했습니다. 이러한 새 특성을 사용하여 시스템에 합법적인 관리 애플리케이션이 있음을 나타낼 수 있습니다. 시스템은 사용자의 승인을 자동으로 요청하여 전체 관리 액세스 토큰으로 애플리케이션을 시작합니다. 애플리케이션 매니페스트를 확장하는 방법에 대한 자세한 내용은 이 문서 내의 애플리케이션 매니페스트 만들기 및 애플리케이션 포함 섹션을 참조하세요.

Windows Vista용 애플리케이션 디자인

다음 목록은 Windows Vista용 애플리케이션을 디자인하기 위한 워크플로를 나타냅니다.

1. Windows Vista 애플리케이션 호환성에 대한 애플리케이션 테스트
2. 애플리케이션을 표준 사용자, 관리자 또는 혼합 사용자 애플리케이션으로 분류
3. UAC 호환성을 위해 애플리케이션의 기능 다시 디자인
4. 애플리케이션의 사용자 인터페이스 다시 디자인
5. 애플리케이션의 설치 관리자 다시 디자인
6. 관리 애플리케이션을 사용하여 애플리케이션 매니페스트 만들기 및 포함
7. 애플리케이션 테스트
8. 애플리케이션 서명
9. Windows Vista 로고 프로그램을 사용할지 여부 결정

1. 애플리케이션 호환성을 위해 애플리케이션 테스트

표준 사용자 분석기를 설치하여 UAC와의 애플리케이션 호환성 테스트를 쉽게 수행할 수 있습니다.

표준 사용자 분석기 그래픽 로그 표시를 활용하려면 Microsoft 애플리케이션 검증 도구를 설치해야 합니다. 애플리케이션 검증 도구 는 Microsoft 웹 사이트에서 무료로 다운로드할 수 있습니다.

다음 절차에서는 표준 사용자 분석기를 사용하여 Windows Vista에서 올바르게 실행되지 않는 Windows Vista 이전 관리 애플리케이션을 식별하는 방법을 보여 줍니다.

표준 사용자 분석기를 활용하기 위해 수행할 수 있는 두 가지 방법은 표준 사용자로 애플리케이션을 시작하거나 관리자 권한으로 관리자 권한으로 애플리케이션을 시작하는 것입니다.

표준 사용자로 애플리케이션을 시작합니다.

이 instance 표준 사용자 분석기가 진단 모드에서 실행되고 있습니다. 애플리케이션이 발생한 첫 번째 오류에서 실패하고 표준 사용자 분석기에서 실패한 이유를 보고합니다.

관리자 권한으로 관리자 권한으로 애플리케이션을 시작합니다.

이 instance 표준 사용자 분석기가 예측 모드에서 실행되고 있습니다. 애플리케이션은 과정을 통해 실행할 수 있으며 표준 사용자 분석기는 애플리케이션이 표준 사용자로 실행되는 경우 발생할 수 있는 오류를 예측하고 개요를 제공합니다.

버그가 수정되고 해결되면 표준 사용자 분석기 없이 표준 사용자로 이 절차를 다시 한 번 수행하여 애플리케이션이 Windows Vista에서 예상대로 작동하는지 확인합니다.

Windows Vista 이전 애플리케이션의 애플리케이션 호환성 문제를 식별하려면

1. 관리 승인 모드에서 관리자 권한으로 Windows Vista 컴퓨터에 로그온합니다.
2. 시작을 클릭하고 모든 프로그램을 클릭한 다음 표준 사용자 분석기를 클릭합니다.
3. 표준 사용자 분석기에서 대상 애플리케이션에 대해 테스트할 애플리케이션의 전체 디렉터리 경로를 지정하거나 찾아보기 단추를 클릭하여 Windows Explorer 있는 프로그램 실행 파일을 찾습니다.
4. 시작을 클릭한 다음 사용자 계정 컨트롤 대화 상자에서 계속을 클릭합니다.
5. 테스트 애플리케이션이 시작되면 애플리케이션에서 표준 관리 작업을 수행하고 완료되면 애플리케이션을 닫습니다.
6. 표준 사용자 분석기에서 각 탭의 출력을 검사합니다. 이 데이터를 사용하여 프로그램에 있을 수 있는 호환성 문제를 식별합니다.

2. 애플리케이션을 표준 사용자, 관리자 또는 혼합 사용자 애플리케이션으로 분류

Windows Vista의 관리 애플리케이션에는 종종 관리 및 표준 사용자 기능이 혼합되어 있습니다. 따라서 Windows Vista에서 애플리케이션이 작동하는 방식을 결정할 때 다양한 옵션을 고려해야 합니다. 사용자에게 승인을 요청하여 관리 기능을 완전히 제거하거나 표준 사용자 계정 기능과 분리할 수 있습니다.

애플리케이션을 분류하는 데 도움이 되는 질문

다음 질문에 답변하여 애플리케이션에 Windows Vista 호환성을 다시 디자인해야 하는지 여부를 확인합니다.

• 애플리케이션이 표준 사용자로 실행됩니까?
• 관리자 액세스 토큰이 더 이상 필요하지 않게 관리 기능을 수정할 수 있나요?
• 프로그램의 기능에서 관리 섹션을 제거할 수 있나요?

애플리케이션이 표준 사용자로 실행됩니까?

이 질문에 대답하려면 표준 사용자가 애플리케이션 또는 기능을 완전히 사용해야 합니다. 기능의 일부에서 사용자가 관리자여야 하는 경우 이 질문에 대한 대답은 "아니요"입니다.

표준 사용자가 애플리케이션 또는 제어판을 사용할 수 있는지 확인하는 방법:

• 애플리케이션 또는 제어판을 표준 사용자 및 관리자 권한으로 철저히 테스트합니다. 사용자 상호 작용이 표준 사용자와 관리자 모두에 대해 정확히 동일한지 확인합니다.
• 레지스트리에 설정이 저장되는 위치를 확인합니다. 설정이 HKLM에 저장된 경우 애플리케이션 또는 제어판에 관리자 액세스 토큰이 필요할 가능성이 큽니다.
• 컴퓨터별 설정이 있으면 애플리케이션 또는 제어판에 관리자 액세스 토큰이 필요합니다.
• 설정 중 다른 사용자의 프로필에서 아무 작업도 수행하지 않으면 애플리케이션 또는 제어판에 관리자 액세스 토큰이 필요합니다.

관리자 액세스 토큰이 더 이상 필요하지 않음으로 관리 기능을 수정할 수 있나요?

애플리케이션 또는 제어판에 전체 관리자 액세스 토큰이 필요한 설정 또는 상호 작용이 있는 경우 표준 사용자로 올바르게 작동하도록 변경할 수 있나요? 특히 프로그램은 사용자별 설정에 정보를 대신 저장할 수 있나요? 그렇게 할 수 없는 경우 이 질문에 대한 대답은 "아니요"입니다.

수정할 수 있는 기능/설정의 좋은 예는 Calc.exe(Windows 계산기)입니다. Windows XP에서 "Scientific" 및 "Standard"의 설정은 컴퓨터별 설정이므로 설정을 변경하려면 전체 관리 액세스 토큰이 필요했습니다. Windows Vista에서 이 설정은 사용자의 프로필에 저장됩니다.

프로그램의 기능에서 관리 섹션을 제거할 수 있는지 확인하는 방법:

• 애플리케이션 또는 제어판을 표준 사용자 및 관리자 권한으로 철저히 테스트합니다. 두 유형의 사용자에 대해 환경이 동일할 수 있나요?

• HKLM 키에 쓰는 데 필요한 ACL(액세스 제어 목록)을 낮출 수 있나요?

  참고 이 과정은 가볍게 받아들여서는 안됩니다. ACL에서 제공하는 제어를 낮추어 시스템의 전반적인 보안을 손상시키지 않도록 주의해야 합니다.

• 사용자 인터페이스를 변경하여 전역 상태가 아닌 사용자별 상태를 설정할 수 있나요(사용자 인터페이스를 통해 전역 상태 수정을 노출하지 않음)?

프로그램 기능에서 관리 섹션을 제거할 수 있나요?

기능에 이 기능이 반드시 있어야 하나요? 관리 기능/기능을 줄일 수 없는 경우 이 질문에 대한 대답은 "아니요"입니다.

관리 섹션을 프로그램의 기능에서 제거할 수 있는지 여부를 확인하려면 다음을 수행합니다.

• 제어판을 표준 사용자뿐만 아니라 관리자로 테스트합니다. 이 기능을 유지하기 위한 사용자 시나리오는 무엇인가요?
• 이 설정/기능이 다른 곳에 노출되어 있나요? 제어판의 기능이 중복된 것일 수 있습니다.

응답 분석하여 애플리케이션 분류

앞의 질문에 "예"라고 대답한 경우

애플리케이션 또는 제어판(있는 경우)을 변경하여 사용자에게 전체 관리 액세스 토큰이 필요한 항목을 제거합니다.

다음 목록에서는 진정한 표준 사용자 애플리케이션을 사용하는 이점에 대해 자세히 설명합니다.

• 이 기능은 모든 사용자에게 동일하게 사용할 수 있습니다. 대부분의 기능에는 전체 관리자 액세스 토큰이 필요하지 않으므로 이상적인 상태입니다.
• 사용자에게 기능이 포함된 권한 상승 프롬프트가 표시되지 않습니다.
• 관리자 액세스 토큰을 요구하지 않아도 기능이 훨씬 더 안전합니다.

앞의 모든 질문에 "아니요"라고 대답한 경우

UAC에서 기능을 작동하도록 애플리케이션 또는 제어판을 수정해야 합니다.

애플리케이션 또는 제어판 UAC에서 작동하는지 확인합니다.

마지막으로, 애플리케이션 또는 제어판을 표준 사용자뿐만 아니라 관리자로 테스트합니다. 이 특정 애플리케이션 또는 제어판에 다른 옵션(이전 질문)을 사용할 수 없는지 확인합니다.

3. UAC 호환성을 위해 애플리케이션 기능 다시 디자인

애플리케이션을 분류하고 UAC용으로 다시 디자인해야 하는지 여부를 결정하면 이 섹션의 정보를 사용합니다.

Windows Vista용 애플리케이션을 다시 디자인하는 큰 구성 요소는 애플리케이션의 사용자 액세스 모델을 핵심으로 검토합니다.

모든 Windows Vista 애플리케이션에 대한 요구 사항

requestedExecutionLevel 지정

UAC가 제대로 작동하려면 운영 체제에서 상승된 권한이 필요한 코드와 그렇지 않은 코드를 식별할 수 있어야 합니다.

Windows Vista에서 이러한 변경 내용을 사용하려면 애플리케이션을 실행해야 하는 컨텍스트에서 운영 체제에서 확인할 수 있는 정보로 애플리케이션을 표시해야 합니다. 예를 들어 호출자로 실행하려면 표준 사용자 애플리케이션을 표시해야 하며, 접근성 지원 애플리케이션은 시스템에서 식별해야 합니다.

Rundll32에 구성 요소를 등록하지 마세요.

일부 애플리케이션은 Windows Rundll32 실행 파일을 사용하여 구성 요소를 실행합니다. 그러나 이 방법은 Windows Vista 개발 요구 사항을 준수하지 않습니다. Rundll32로 직접 호출하면 UAC 호환성 문제가 발생합니다. 애플리케이션이 Rundll32 실행 파일을 사용하여 실행을 수행하는 경우 Rundll32는 애플리케이션을 대신하여 AIS(애플리케이션 정보 서비스)를 호출하여 UAC 권한 상승 프롬프트를 시작합니다. 결과적으로 UAC 권한 상승 프롬프트는 원래 애플리케이션에 대한 지식이 없으며 권한 상승을 요청하는 애플리케이션을 "Windows 호스트 프로세스(Rundll32)"로 표시합니다. 권한 상승을 요청하는 애플리케이션에 대한 명확한 설명과 아이콘이 없으면 사용자는 애플리케이션을 식별하고 상승하는 것이 안전한지 확인할 수 없습니다.

애플리케이션이 Rundll32를 호출하여 구성 요소를 실행하는 경우 다음 워크플로를 사용하여 실행 호출을 다시 디자인합니다.

1. 애플리케이션에 대한 별도의 실행 파일을 새로 만듭니다.
2. 새 실행 파일에서 Rundll32로 지정한 DLL에서 내보낸 함수를 호출합니다. .lib가 없는 경우 DLL을 LoadLibrary해야 할 수 있습니다.
3. 리소스 파일에서 실행 파일에 대한 새 아이콘을 만들고 추가합니다. 이 아이콘은 애플리케이션이 권한 상승을 요청할 때 사용자 계정 컨트롤 권한 상승 프롬프트에 표시됩니다.
4. 실행 파일에 대한 짧고 의미 있는 이름을 제공합니다. 이 이름은 애플리케이션이 권한 상승을 요청할 때 사용자 계정 컨트롤 권한 상승 프롬프트에 표시됩니다.
5. 실행 파일에 대한 애플리케이션 매니페스트 파일을 만들고 포함하고 요청된 실행 수준 requireAdministrator로 표시합니다. 이 프로세스는 애플리케이션 매니페스트 만들기 및 애플리케이션 포함 섹션에 자세히 설명되어 있습니다.
6. Authenticode는 새 실행 파일에 서명합니다. 이 프로세스는 Authenticode 애플리케이션 서명 섹션에 자세히 설명되어 있습니다.

애플리케이션의 설치를 해제한 후 사용자는 오류 없이 다시 설치할 수 있어야 합니다.

표준 사용자 애플리케이션에 대한 요구 사항

다음은 표준 사용자 계정으로 올바르게 작동하는 애플리케이션을 디자인할 때 기억해야 할 사항에 대한 요약입니다. 개발자는 애플리케이션의 디자인 단계에서 이러한 요구 사항을 염두에 두어야 합니다.

설치

• 첫 번째 실행에서는 관리 작업(예: 설치 프로세스 완료)을 수행하지 않습니다. 초기 설치 프로세스의 일부로 수행해야 합니다.
• Windows 디렉터리 또는 하위 디렉터리에 직접 쓰지 마세요. 글꼴과 같은 파일을 설치하는 데 올바른 방법을 사용합니다.
• 애플리케이션을 자동으로 업데이트해야 하는 경우 Windows Installer 4.0 사용자 계정 컨트롤 패치와 같은 표준 사용자가 사용하기에 적합한 메커니즘을 사용하여 업데이트를 수행합니다.

상태 저장

• 프로그램 파일 또는 프로그램 디렉터리에 사용자별 정보 또는 사용자 쓰기 가능 정보를 작성하지 마세요.
• 파일 시스템에서 하드 코딩된 경로를 사용하지 마세요. KnownFolders API 및 ShGetFolder를 활용하여 데이터를 쓸 위치를 찾습니다.

표준 사용자 계정으로 실행 및 테스트

LOB 애플리케이션 또는 게임과 같은 사용자 애플리케이션과 같은 비관리 애플리케이션을 작성하는 경우 항상 표준 사용자가 액세스할 수 있는 위치에 애플리케이션 데이터를 작성해야 합니다. 다음은 몇 가지 권장 요구 사항입니다.

• 사용자 프로필에 사용자별 데이터 쓰기: CSIDL_APPDATA.
• 사용자\모든 사용자\애플리케이션 데이터에 컴퓨터별 데이터 쓰기: CSIDL_COMMON_APPDATA.
• 애플리케이션은 관리 API에 의존할 수 없습니다. 예를 들어 SetTokenInformation() Windows 함수를 성공적으로 호출해야 하는 프로그램은 표준 사용자 계정에서 실패합니다.

FUS(빠른 사용자 전환) 인식

애플리케이션은 일반적으로 애플리케이션을 실행할 사용자 이외의 사용자가 설치합니다. 예를 들어 가정에서는 부모가 자식용 애플리케이션을 설치합니다. 엔터프라이즈에서 SMS 또는 그룹 정책 보급 알림과 같은 배포 시스템은 관리자 계정을 사용하여 애플리케이션을 설치합니다.

처음 실행 시 사용자별 설정이 없으면 다시 빌드합니다. 설정 프로세스가 설정을 처리한 것으로 가정하지 마세요.

관리자 애플리케이션에 대한 요구 사항

HWND 속성을 사용하여 포그라운드 애플리케이션으로 승인

백그라운드 애플리케이션은 권한 상승을 위해 보안 데스크톱으로 자동으로 가는 대신 사용자에게 작업 표시줄의 권한 상승을 자동으로 묻는 메시지를 표시합니다. 권한 상승 프롬프트는 작업 표시줄에 최소화된 것으로 나타나며 애플리케이션이 권한 상승을 요청했음을 사용자에게 알리기 위해 깜박입니다. 백그라운드 권한 상승의 예는 사용자가 웹 사이트를 찾아 설치 파일 다운로드를 시작할 때 발생합니다. 그런 다음 설치가 백그라운드에서 다운로드되는 동안 사용자는 검사 전자 메일로 이동합니다. 다운로드가 백그라운드에서 완료되고 설치가 시작되면 권한 상승이 포그라운드 작업이 아닌 백그라운드 작업으로 검색됩니다. 이 검색은 사용자가 다른 작업(전자 메일 읽기)을 수행하는 동안 설치가 사용자 화면의 포커스를 갑자기 도용하는 것을 방지합니다. 이 동작은 권한 상승 프롬프트에 대한 더 나은 사용자 환경을 만듭니다.

그러나 일부 포그라운드 애플리케이션은 현재 Windows Vista에서 백그라운드 애플리케이션으로 프롬프트를 표시합니다. 이 동작은 부모 HWND가 없는 결과입니다. Windows Vista가 애플리케이션을 포그라운드 애플리케이션으로 승인하도록 하려면 ShellExecute, CreateElevatedComObject(COM) 또는 관리 코드 호출을 사용하여 부모 HWND를 전달해야 합니다.

UAC 권한 상승 메커니즘은 HWND를 사용하여 권한 상승이 배경 또는 전경 권한 상승인지 여부를 결정합니다. 애플리케이션이 백그라운드 애플리케이션으로 확인되면 권한 상승이 작업 표시줄에 깜박이는 단추로 배치됩니다. 권한 상승이 계속되기 전에 사용자는 포그라운드 액세스를 요청하는 애플리케이션과 마찬가지로 단추를 클릭해야 합니다. HWND를 전달하지 않으면 애플리케이션에 실제로 포그라운드가 있을 수 있더라도 이 문제가 발생합니다.

다음 코드 샘플에서는 ShellExecute를 사용하여 HWND를 전달하는 방법을 보여 줍니다.

BOOL RunAsAdmin( HWND hWnd, LPTSTR lpFile, LPTSTR lpParameters )
{
    SHELLEXECUTEINFO   sei;
    ZeroMemory ( &sei, sizeof(sei) );

    sei.cbSize          = sizeof(SHELLEXECUTEINFOW);
    sei.hwnd            = hWnd;
    sei.fMask           = SEE_MASK_FLAG_DDEWAIT | SEE_MASK_FLAG_NO_UI;
    sei.lpVerb          = _TEXT("runas");
    sei.lpFile          = lpFile;
    sei.lpParameters    = lpParameters;
    sei.nShow           = SW_SHOWNORMAL;

    if ( ! ShellExecuteEx ( &sei ) )
    {
        printf( "Error: ShellExecuteEx failed 0x%x\n", GetLastError() );
        return FALSE;
    }
    return TRUE;
}

다음 코드 샘플에서는 권한 상승 모니커를 사용하여 CreateElevatedComObject와 HWND를 전달하는 방법을 보여 줍니다. 현재 스레드에서 COM을 이미 초기화한 것으로 가정합니다. 권한 상승 모니커에 대한 자세한 내용은 이 문서의 4단계에서 확인할 수 있습니다.

HRESULT CreateElevatedComObject(HWND hwnd, REFCLSID rclsid, REFIID riid, __out void ** ppv)
{
    BIND_OPTS3 bo;
    WCHAR  wszCLSID[50];
    WCHAR  wszMonikerName[300];

    StringFromGUID2(rclsid, wszCLSID, sizeof(wszCLSID)/sizeof(wszCLSID[0])); 
    HRESULT hr = StringCchPrintf(wszMonikerName, sizeof(wszMonikerName)/sizeof(wszMonikerName[0]), L"Elevation:Administrator!new:%s", wszCLSID);
    if (FAILED(hr))
        return hr;
    memset(&bo, 0, sizeof(bo));
    bo.cbStruct = sizeof(bo);
    bo.hwnd = hwnd;
    bo.dwClassContext  = CLSCTX_LOCAL_SERVER;
    return CoGetObject(wszMonikerName, &bo, riid, ppv);

BIND_OPTS3 Windows Vista의 새로운 기능입니다. BIND_OPTS2 파생됩니다. 아래와 같이 정의됩니다.

typedef struct tagBIND_OPTS3 : tagBIND_OPTS2
{
    HWND hwnd;
} BIND_OPTS3, * LPBIND_OPTS3;

HWND 필드 hwnd만 추가됩니다. 이 핸들은 보안 데스크톱 프롬프트를 사용하도록 설정할 때 권한 상승 UI의 소유자가 되는 창을 나타냅니다.

다음 코드 샘플에서는 관리 코드에서 HWND를 전달하여 부모 대화 상자가 HWND 및 해당 사용을 인식하도록 하는 방법을 보여 줍니다.

System.Diagnostics.Process newProcess = new System.Diagnostics.Process();
System.Diagnostics.ProcessStartInfo info = new System.Diagnostics.ProcessStartInfo("D:\SomeProgram.exe");
info.UseShellExecute = true;
info.ErrorDialog = true;
info.ErrorDialogParentHandle = this.Handle;
newProcess.StartInfo = info;
newProcess.Start();

사용자의 로그온 경로에서 권한 상승에 대한 메시지를 표시하지 않음

사용자가 로그온하고 상승이 필요한 경우 시작되는 애플리케이션은 이제 로그온 경로에서 차단됩니다. 애플리케이션이 사용자의 로그온 경로에서 상승하라는 메시지를 표시하지 않도록 차단하지 않으면 표준 사용자와 관리자가 로그온할 때마다 사용자 계정 컨트롤 대화 상자에 응답해야 합니다. Windows Vista는 시스템 트레이에 아이콘을 배치하여 애플리케이션이 차단되었는지 사용자에게 알립니다. 그런 다음 사용자는 이 아이콘을 마우스 오른쪽 단추로 클릭하여 사용자가 로그온할 때 권한 상승 메시지를 표시하지 못하도록 차단된 애플리케이션을 실행할 수 있습니다. 사용자는 트레이 아이콘을 두 번 클릭하여 사용하지 않도록 설정되거나 이 목록에서 제거된 시작 애플리케이션을 관리할 수 있습니다.

작업 스케줄러를 사용하여 사용자 권한 상승을 수행하는 방법을 보여 주는 C++ 코드 샘플은 이 문서의 참조 섹션에서 확인할 수 있습니다.

Runas를 사용하여 관리자 권한 프로세스 시작 안 함

Windows XP 및 Windows Server 2003의 실행... 옵션이 Windows Vista의 상황에 맞는 메뉴(실행 파일을 마우스 오른쪽 단추로 클릭할 때 사용 가능)에서 관리자 권한으로 실행 으로 대체되었습니다. 표준 사용자가 관리자 권한으로 실행 옵션을 선택하면 로컬 컴퓨터에 활성 관리자 목록이 표시됩니다. 백업 연산자 그룹의 멤버와 같이 더 높은 권한을 가진 표준 사용자도 표시됩니다. 관리자가 관리자 권한으로 실행 옵션을 선택하면 사용자 계정 컨트롤 대화 상자에서 애플리케이션을 실행하기 전에 계속하라는 메시지를 즉시 표시합니다.

사용자는 다른 사용자로 애플리케이션을 실행하려면 명령 프롬프트에서 runas 명령을 사용해야 합니다.

중요 runas는 백업 운영자 또는 관리자와 같은 권한을 가진 표준 사용자인지 여부에 관계없이 관리자 권한으로 애플리케이션을 시작하는 기능을 제공하지 않습니다. runas 명령은 사용자에게 다른 자격 증명으로 애플리케이션을 시작할 수 있는 기능을 부여합니다. 다른 계정으로 애플리케이션을 시작하는 데 사용하는 가장 좋은 방법은 서비스를 사용하여 프로그래밍 방식으로 작업을 수행하고 사용자가 구성 요소를 다른 사용자로 실행하는 데 의존하지 않는 것입니다. 프로그래밍 방식으로 runas 명령을 사용하는 경우 관리자 권한 프로세스를 시작하지 않는지 확인합니다.

애플리케이션에서 사용자가 다른 사용자 계정으로 애플리케이션의 일부를 실행하도록 요구하는 경우 명령 프롬프트 옵션이 있는 runas 명령이 노출되어 있는지 확인합니다. 다음 표에서는 runas 명령에 사용할 수 있는 매개 변수를 자세히 설명합니다.

Runas 매개 변수

매개 변수	Description
/noprofile	사용자의 프로필을 로드 하지 않아야 지정 합니다. 이렇게 하면 애플리케이션을 더 빠르게 로드할 수 있지만 일부 애플리케이션이 오작동할 수 있습니다.
/프로필	사용자의 프로필을 로드해야 되도록 지정합니다. 이 값은 기본 설정입니다.
/환경을	사용자 대신 현재 환경을 사용합니다.
/netonly	지정된 자격 증명이 원격 액세스 전용인 경우 이 매개 변수를 사용합니다.
/savecred	사용자가 이전에 저장한 자격 증명을 사용합니다. 이 옵션은 Windows XP, Home Edition에서 사용할 수 없으며 무시됩니다.
/스마트	제공될 자격 증명이 스마트 카드 있는 경우 이 매개 변수를 사용합니다.
/user	사용자의 사용자 이름입니다. 사용자 이름은 USER\DOMAIN 또는 USER@DOMAIN 형식으로 제공되어야 합니다.
/showtrustlevels	/trustlevel 매개 변수의 인수로 사용할 수 있는 trustlevel을 표시합니다.
/trustlevel	/showtrustlevels에 열거된 수준 중 하나입니다.
프로그램	실행 파일의 명령줄입니다.

예:

runas /noprofile /user:mymachine\Denise cmd

참고:

• 메시지가 표시될 때만 사용자의 암호를 입력합니다.
• /profile 매개 변수는 /netonly 매개 변수와 호환되지 않습니다.
• /savecred 매개 변수는 /smartcard 매개 변수와 호환되지 않습니다.

콘솔 애플리케이션에 대한 요구 사항

콘솔 애플리케이션은 별도의 사용자 인터페이스가 아닌 콘솔 창에 출력을 표시합니다. 애플리케이션을 실행하기 위해 전체 관리자 액세스 토큰이 필요한 경우 관리자 권한 콘솔 창에서 해당 애플리케이션을 시작해야 합니다.

콘솔 애플리케이션에 대해 다음을 수행해야 합니다.

애플리케이션을 "asInvoker"로 표시

RequestedExecutionLevel == asInvoker를 설정한 애플리케이션의 매니페스트를 작성하여 이 작업을 수행할 수 있습니다. 이 설정을 사용하면 상승되지 않은 컨텍스트의 호출자가 프로세스를 만들 수 있으므로 2단계로 진행할 수 있습니다.

전체 관리자 액세스 토큰 없이 애플리케이션을 실행하는 경우 오류 메시지 제공

관리자가 아닌 콘솔에서 애플리케이션이 시작되면 애플리케이션에서 간단한 메시지를 제공하고 종료해야 합니다. 권장되는 메시지는 다음과 같습니다.

"액세스가 거부되었습니다. 선택한 옵션을 사용하려면 관리자 권한이 필요합니다. 관리자 명령 프롬프트를 사용하여 이러한 작업을 완료합니다."

또한 애플리케이션은 스크립팅을 용이하게 하기 위해 시작하지 못한 경우 오류 코드 ERROR_ELEVATION_REQUIRED 반환해야 합니다.

스크립트에 대한 요구 사항

스크립트는 애플리케이션 그룹이 미리 정의된 순서로 실행되고 한 애플리케이션이 다른 순서로 채널화되는 결과로 간주될 수 있습니다.

스크립트 UAC를 준수하도록 하려면 스크립트의 논리를 검사하고 "테스트"를 추가하여 스크립트에서 작업을 수행하기 전에 사용자(또는 스크립트를 실행하는 사람)에게 해당 작업을 수행할 수 있는 충분한 권한이 있는지 확인합니다.

대량 작업에 대한 요구 사항

애플리케이션에서 수행하는 작업이 여러 개체에 대한 작업으로 구성되고 그 중 일부는 사용자의 관리 액세스 토큰이 필요할 수 있는 경우 필요한 첫 번째 권한 상승 프롬프트를 표시합니다. 사용자가 권한 상승을 승인하는 경우 나머지 작업을 수행합니다. 그렇지 않으면 일괄 처리 작업을 종료합니다. 이 동작은 현재 다중 선택/복사/삭제 작업과 일치합니다.

관리자를 식별하는 데 도움이 되는 API

• IsUserAnAdmin()
• GetTokenInformation()

관리자와 표준 사용자 간에 본질적으로 다른 레지스트리/액세스 권한 처리

• MAXIMUM_ALLOWED
• KEY_WRITE
• DELETE(레지스트리 키에 적용된 경우)
• 기타 HKLM과 유사한 키워드(XP에서 MAXIMUM_ALLOWED 열림):
• SHELLKEY_HKLM_EXPLORER
• SHELLKEY_HKLM_SHELL

HKLM 레지스트리 값 및 가상화로 다시 전달되는 다른 API가 적용됩니다.

• WritePrivateProfileString(,,,"system.ini");
• CheckSectionAccess("system.ini",...);

4. UAC 호환성을 위해 애플리케이션의 사용자 인터페이스 다시 디자인

이 섹션의 지침을 사용하여 UAC 호환성을 위한 애플리케이션의 사용자 인터페이스를 개발합니다. 애플리케이션 개발에서 이러한 지침을 면밀히 준수하면 애플리케이션이 Windows Vista에서 일관되고 예측 가능한 사용자 환경을 갖도록 할 수 있습니다.

• UAC가 Windows 사용자 환경에 미치는 영향
• UAC 사용자 환경의 목표
• 권한 상승 프롬프트
• 사용자 환경 프로세스 흐름
• 권한 상승 진입점
• 사용자 인터페이스 구현
• 애플리케이션의 사용자 인터페이스에 방패 아이콘을 추가해야 하는 경우
• 관리자 전용 애플리케이션에 대한 주요 결정

중요 애플리케이션의 사용자 인터페이스를 단순히 내화하면 UAC 호환성에 대한 요구 사항을 충족하지 않습니다. 애플리케이션의 핵심 기능은 Windows Vista 표준 사용자 모델 요구 사항을 준수해야 합니다. 이러한 요구 사항은 이전 단계인 3단계: UAC 호환성을 위해 애플리케이션의 기능 재설계에 자세히 설명되어 있습니다.

UAC가 Windows 사용자 환경에 미치는 영향

사용자 환경에 가장 크고 즉각적인 영향은 관리자가 느낄 수 있습니다. 이제 관리자 사용자는 관리 작업을 수행할 수 있는 권한을 제공해야 합니다. 이제 표준 사용자는 관리자에게 현재 로그인한 세션 내의 특정 관리 작업에 대한 권한을 부여하도록 요청할 수 있습니다.

UAC 사용자 환경의 목표

UAC 사용자 환경의 전반적인 목표는 사용자 환경에서 예측 가능성을 제공하는 것입니다.

• 관리자의 경우 사용자가 관리자 권한 작업을 실행할 수 있는 권한을 부여해야 하는 경우를 항상 알고 있음을 의미합니다.

이는 관리자가 필요한 변경 작업을 수행할 수 있도록 사용자 고유의 관리자 액세스 토큰을 요청하는 행위입니다.

• 표준 사용자의 경우 다음을 알 수 있습니다.
  • 관리 작업에 대한 관리자 승인(가정 및 관리되지 않는 환경)을 제공해야 합니다.
  • 또는 에서 작업을 완료할 수 없는 경우(권한 상승이 명시적으로 허용되지 않는 관리 환경) 지원 센터에 문의해야 합니다.

디자인 목표

다음 목록은 UAC 디자인 목표로 구성됩니다.

불필요한 상승 제거

사용자는 관리자 액세스 토큰이 필요한 작업을 수행하기 위해서만 상승해야 합니다. 다른 모든 작업은 권한 상승이 필요하지 않도록 설계되어야 합니다. Windows Vista 이전 소프트웨어에서는 HKLM 또는 HKCR 레지스트리 섹션 또는 프로그램 파일 또는 Windows 시스템 폴더에 작성하여 관리자 액세스 토큰이 불필요하게 필요한 경우가 많습니다.

예측 가능

관리자는 상승이 필요한 작업을 알아야 합니다. 승격의 필요성을 정확하게 예측할 수 없는 경우 관리 작업에 동의하면 안 될 경우 동의할 가능성이 높습니다. 표준 사용자는 관리자가 수행해야 하는 작업이나 관리되는 환경에서 전혀 수행할 수 없는 작업을 알아야 합니다.

최소한의 노력 필요

더 높은 권한 있는 액세스 토큰이 필요한 작업은 단일 권한 상승이 필요하도록 설계되어야 합니다. 여러 권한 상승이 필요한 작업은 빠르게 지루해집니다.

표준 사용자로 되돌리기

더 높은 수준의 액세스 토큰이 필요한 작업이 완료되면 프로그램이 표준 사용자 상태로 되돌리기 합니다.

권한 상승 프롬프트

권한 상승 프롬프트는 기존 Windows 사용자 인터페이스를 기반으로 합니다. 권한 상승 프롬프트는 권한 상승을 요청하는 실행 파일에 대한 컨텍스트 정보를 표시하며 애플리케이션이 Authenticode에 서명되었는지 여부에 따라 컨텍스트가 다릅니다. 권한 상승 프롬프트는 동의 프롬프트와 자격 증명 프롬프트의 두 가지 변형으로 표시됩니다.

동의 프롬프트

동의 프롬프트는 관리자가 관리 작업을 수행하려고 할 때 관리 승인 모드로 표시됩니다. 이는 관리 승인 모드의 관리자를 위한 기본 사용자 환경이며 로컬 보안 정책 관리자 스냅인(secpol.msc) 및 그룹 정책 구성할 수 있습니다.

다음 그림은 사용자 계정 컨트롤 동의 프롬프트의 예입니다.

그림 4. 사용자 계정 컨트롤 동의 확인 프롬프트

자격 증명 프롬프트

자격 증명 프롬프트는 관리 작업을 수행하려고 할 때 표준 사용자에게 표시됩니다. 이는 표준 사용자에 대한 기본 사용자 환경이며 로컬 보안 정책 관리자 스냅인(secpol.msc) 및 그룹 정책 구성할 수 있습니다.

다음 그림은 사용자 계정 컨트롤 자격 증명 프롬프트의 예입니다.

그림 5. 사용자 계정 컨트롤 자격 증명 프롬프트

Windows Vista에 대한 기본 권한 상승 프롬프트 동의 정책

다음 표에서는 Windows Vista의 각 사용자 계정 유형에 대한 기본 프롬프트 스타일을 간략하게 설명합니다.

기본 권한 상승 프롬프트 동작

사용자 계정 유형	권한 상승 프롬프트 설정
표준 사용자	자격 증명 확인
관리 승인 모드의 관리자 계정	동의 확인

사용자 환경 프로세스 흐름

UAC 사용자 환경 프로세스 흐름은 다음과 같은 세 가지 개별 구성 요소로 구성됩니다.

1. 권한 상승 진입점(예: UAC 방패 아이콘을 표시하는 컨트롤 또는 링크).
2. 권한 상승 프롬프트(동의 요청 또는 관리자 자격 증명 요청).
3. 관리자 권한 프로세스입니다.

다음 예제 워크플로에서는 이전 구성 요소와 관련된 방법을 요약합니다.

1. 관리 승인 모드의 관리자가 Windows Vista 컴퓨터에 로그온합니다.
2. 그런 다음 사용자는 컴퓨터에 다른 관리자 사용자를 추가하기로 결정합니다.
3. 사용자가 시작을 클릭하고 제어판 클릭한 다음 Windows 방화벽을 통해 프로그램 허용이라는 보안 섹션의 링크를 클릭합니다. 이 링크는 방패 아이콘과 함께 인라인으로 표시됩니다.
4. 사용자에게 승인을 요청하는 동의 프롬프트가 나타납니다.
5. 사용자가 계속 을 클릭하면 관리자 권한 프로세스가 만들어집니다.
6. Windows 방화벽 설정에서 사용자는 Windows 방화벽 설정을 수정한 다음 확인을 클릭하여 관리자 권한 프로세스를 종료합니다.
7. 사용자는 표준 사용자로 컴퓨터에서 계속 작업합니다.

참고 권한 상승 진입점은 상태(예: 보호된 위치 또는 작업에서 다시 탐색할 때)를 기억하지 못하며 진입점은 권한 상승이 발생했음을 기억하지 않습니다. 따라서 사용자는 다시 상승하여 작업/링크/단추를 다시 입력해야 합니다.

권한 상승 진입점

진입점의 경우 방패 아이콘이 특정 컨트롤(예: 단추, 명령 링크, 하이퍼링크)에 연결되어 다음 즉각적인 단계에 상승이 필요함을 나타냅니다.

방패 아이콘

방패 아이콘은 UAC 권한 상승 지점의 기본 사용자 인터페이스 장식입니다. 이 아이콘은 Windows Vista 및 이전 버전의 Windows에서 보안 관련 활동을 의미하며 이 관계는 Windows Vista에서 계속됩니다.

다음 그림은 방패 아이콘의 예입니다.

그림 6. 방패 아이콘

방패 아이콘은 UAC 사용자 환경의 세 가지 구성 요소 모두에 중요한 역할을 합니다.

Windows Explorer 사용하여 시스템을 볼 때 관리자 액세스 토큰을 요청하는 것으로 표시된 모든 애플리케이션은 아이콘 위에 방패 문자 모양으로 자동으로 데코레이팅됩니다. 이렇게 하면 사용자가 시작할 때 권한 상승을 요청할 애플리케이션을 알 수 있습니다.

방패 아이콘 속성:

• 전체 UAC 사용자 환경 전체에서 일관된 모양.
• 시각적 상태(예: 활성, 가리키기, 사용 안 함 등)를 반영하지 않습니다.
• 상태를 기억하지 않습니다.

실드 아이콘으로 표시된 진입점이 사용자 환경 내에서 사용할 수 있는 세 가지 일관된 컨트롤 스타일이 있습니다.

• UAC 단추
• UAC 하이퍼링크
• UAC 명령 링크

이러한 스타일은 마법사, 속성 페이지, 제어판 Framework, 탐색기 등과 같은 사용자 인터페이스 요소가 나타날 수 있는 모든 시나리오에 적용됩니다. 각 스타일은 사용자가 UAC 사용자 인터페이스 컨트롤을 클릭한 후 권한 상승 프롬프트가 즉시 표시됨을 의미합니다.

네 번째 UAC 사용자 인터페이스 진입점인 UAC 아이콘 오버레이도 이 섹션에서 설명합니다. 실행 파일이 아이콘 오버레이를 수신하는지 여부는 애플리케이션 개발자가 제어하지 않습니다. Windows Vista는 RequireAdministrator로 설정된ExecutionLevel을 요청한 실행 파일의 애플리케이션 아이콘에 방패 아이콘을 오버레이합니다.

UAC 실드 단추

UAC 방패 단추는 모든 사용자 인터페이스 단추에서 사용해야 합니다. 이 단추를 누르면 사용자에게 승인 또는 자격 증명을 묻는 권한 상승 프롬프트가 필요합니다.

UAC 실드 단추는 커밋 단추(예: 마법사의 다음 )로 사용하거나 추가 설정 사용자 인터페이스(예: 속성 대화 상자의 설정 변경)를 표시하는 단추로 사용할 수 있습니다.

UAC 실드 단추는 다음 두 가지 사용자 인터페이스 구성 요소로 구성됩니다.

• 방패 아이콘
• 텍스트 레이블

UAC 방패 단추는 개발자가 일반 단추 대신 사용할 수 있도록 방식으로 패키지됩니다. UAC 단추는 텍스트 레이블의 왼쪽 또는 오른쪽에 있는 방패 아이콘 렌더링도 지원합니다. 또한 개발자는 UAC 단추가 표시되는 동안 방패 아이콘을 숨기고 표시할 수 있습니다.

다음 스크린샷은 UAC 방패 단추의 예입니다.

그림 7. UAC 실드 단추

UAC 하이퍼링크

UAC 하이퍼링크는 클릭 시 사용자에게 승인 또는 자격 증명을 묻는 권한 상승 프롬프트가 필요한 모든 사용자 인터페이스 하이퍼링크에서 사용해야 합니다.

UAC 하이퍼링크는 다음 구성 요소로 구성됩니다.

• 방패 아이콘
• 하이퍼링크 컨트롤

UAC 하이퍼링크는 개발자가 사용할 방패 아이콘으로 패키지되지 않습니다. 개발자는 방패 아이콘 리소스를 가져와서 하이퍼링크 옆에 렌더링해야 합니다.

다음 스크린샷은 UAC 하이퍼링크의 예입니다.

그림 8. UAC 하이퍼링크

UAC 명령 링크

UAC 명령 링크는 클릭 시 사용자에게 승인 또는 자격 증명을 묻는 권한 상승 프롬프트가 필요한 모든 사용자 인터페이스 단추에서 사용해야 합니다.

UAC 명령 링크는 커밋 단추로만 사용해야 합니다(예: 대화 상자에서 "이 옵션 수행").

UAC 명령 링크는 다음 구성 요소로 구성됩니다.

• 방패 아이콘
• 표준 명령 링크 구성 요소
• 링크 텍스트
• 참고 텍스트

UAC 명령 링크는 개발자가 일반 명령 링크 대신 UAC 명령 링크를 사용할 수 있는 방식으로 패키지됩니다. UAC 명령 링크는 명령 링크의 왼쪽 또는 오른쪽에 있는 방패 아이콘 렌더링을 지원합니다.

다음은 UAC 명령 링크의 예입니다.

그림 9. UAC 명령 링크

아이콘 오버레이

Windows Vista에서 실행 파일을 시작하려면 권한 상승이 필요한 경우 이 사실을 나타내기 위해 실행 파일의 아이콘에 방패 아이콘을 "스탬프"해야 합니다. 실행 파일의 애플리케이션 매니페스트는 실행 파일을 전체 관리 액세스 토큰이 필요한 것으로 지정하려면 "requireAdministrator"로 표시해야 합니다. 또한 방패 아이콘 오버레이는 설치 관리자 검색 추론에 따라 상승이 필요한 것으로 간주되는 실행 파일에 자동으로 배치됩니다. 예를 들어 setup.exe 파일은 실행 파일에 포함된 애플리케이션 매니페스트가 없더라도 방패 아이콘 오버레이를 자동으로 받습니다.

다음 그림은 UAC 아이콘 오버레이의 예입니다.

그림 10. UAC 아이콘 오버레이

참고 실행 파일을 사용하여 애플리케이션 매니페스트를 만들고 포함하는 방법에 대한 지침은 이 문서의 애플리케이션에 애플리케이션 매니페스트 만들기 및 포함 섹션에 제공됩니다.

사용자 인터페이스 구현

실드 아이콘 구현 및 API

이 섹션에서는 개발자가 새 관리 애플리케이션 기능을 마이그레이션하거나 구현할 때 사용할 수 있는 아이콘 및 API에 대한 예비 정보를 제공합니다.

방패 아이콘 구현 및 API

아이콘	API
보호	사용자 리소스: IDI_SHIELD
단추	Button_SetElevationRequired(hwndButton)
Syslink/Hyperlink	syslink 옆의 레이아웃 IDI_SHIELD
명령 링크	IDI_SHIELD 로드하고 명령 링크 아이콘으로 설정
상황에 맞는 메뉴	정적 명령에 대한 DefCM의 아이콘 지원

사용자 인터페이스에 방패 아이콘 추가

작은 아이콘을 추가합니다.

#include <shellapi.h>
SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICON | SHGSI_SMALLICON, &sii);
hiconShield  = sii.hIcon;

큰 아이콘을 추가합니다.

SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICON | SHGSI_LARGEICON, &sii);
hiconShield  = sii.hIcon;

사용자 지정 크기의 아이콘을 추가합니다.

SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICONLOCATION, &sii);
hiconShield  = ExtractIconEx(sii. ...);

참고 일반적으로 사용자 인터페이스에 방패 아이콘을 직접 추가하면 안 됩니다. 컨트롤에서 방패 아이콘을 포함하는 진행 방법 중 하나를 사용하는 것이 좋습니다. 또한 사용자 인터페이스에 방패 아이콘을 추가하기만 하면 UAC 호환성이 보장되지 않습니다. 또한 애플리케이션의 사용자 환경 전체를 내화해야 합니다(requestedExecutionLevel을 추가하고, 표준 사용자 버그를 수정하고, 사용자 인터페이스가 사용자 친화적이고 UAC와 호환되는지 확인).

단추에 방패 아이콘 추가

표준 단추 컨트롤(PUSHBUTTON, DEFPUSHBUTTON)은 BS_ICON 또는 BS_BITMAP 스타일을 설정하지 않고도 표시된 텍스트와 함께 아이콘을 추가할 수 있도록 향상되었습니다.

방패 아이콘을 표시하려면 다음 매크로(commctrl.h에 정의됨)를 호출합니다.

Button_SetElevationRequiredState(hwndButton, fRequired);

참고 hwndButton은 단추의 HWND입니다. fRequired는 UAC 방패 아이콘을 표시할지(TRUE) 숨기거나 숨길지(FALSE)를 결정합니다.

Windows 설치 관리자 단추에 방패 아이콘 추가

내부 테이블 지원을 사용하여 작성된 Windows Installer 대화 상자는 컨트롤에서 ElevationShield 특성을 설정하여 사용자 인터페이스 대화 상자 시퀀스의 마지막 단추에 방패를 추가할 수 있습니다.

마법사의 "다음" 단추에 방패 아이콘 추가

중요 UAC 방패 아이콘을 표시하는 "다음" 단추는 AeroWizards(PSH_AEROWIZARD)에서만 지원됩니다.

AeroWizard의 특정 페이지에 대한 "다음" 단추에 방패 아이콘을 표시하려면 다음 코드를 사용합니다.

case WM_NOTIFY:
    if (reinterpret_cast<NMHDR*>(lParam)->code == PSN_SETACTIVE)
    {
        // Show next button
        //
        // Note new wParam flag -- when PSWIZBF_ELEVATIONREQUIRED flag
        // is specified, it indicates that the next page will require
        // elevation, so if the next button is being shown, show it as
        // a shield button.

        SendMessage(GetParent(hwndDlg), 
                    PSM_SETWIZBUTTONS, 
                    PSWIZBF_ELEVATIONREQUIRED, 
                    PSWIZBF_NEXT);

        // return 0 to accept the activation
        SetWindowLong(hwndDlg, DWLP_MSGRESULT, 0); 
    }
    break;

작업 대화 상자 단추에 방패 아이콘 추가

주의 작업 대화 상자 단추에는 UAC 방패 아이콘이 필요하지 않습니다. 작업 대화 상자 단추의 "누르기" 작업은 커밋/취소하고 작업 대화 상자를 해제해야 합니다. 이러한 단추가 사용자에게 권한 상승 프롬프트를 표시하는 것은 이상한 일입니다.

모달 대화 상자 상승

권한 상승 모니커를 사용하여 모달 대화 상자를 나타내는 COM 개체를 승격합니다.

작업:

• 대화 상자를 COM 개체로 이동합니다.
• ShowDialog() 메서드를 노출합니다.
• API CreateElevatedComObject()를 사용하여 COM 개체를 만들고 ShowDialog()를 호출합니다.

이 API는 권한 상승 프로세스를 거친 후 COM 개체의 instance 관리자 권한으로 실행합니다.

참고 호출이 더 복잡한 이 API 버전을 사용할 수 있습니다. 간소화된 버전은 이후 버전의 Windows Vista에서 사용할 수 있습니다.

사용자 교육 및 지원 지침

사용자 인터페이스가 다시 고려되고 단추 뒤에 배치된 경우 ISV는 단추 이름 변경이 보증되는지 여부를 평가해야 합니다. Microsoft는 고급을 권한 상승 작업의 단추 레이블로 사용하지 강력히 권장합니다. 대신 설정 변경 또는 단추 뒤에 무엇이 있는지 제안하는 용어와 같은 보다 설명적이고 이해할 수 있는 레이블을 사용합니다.

관리자 전용 사용자 인터페이스에 대한 지침

관리자가 애플리케이션을 항상 시작하는 경우 애플리케이션의 사용자 인터페이스 내에 추가 방패를 추가할 필요가 없습니다. 이는 애플리케이션이 상승되고 모든 작업이 상승되므로 추가 상승이 필요하지 않기 때문입니다.

참고 관리자 전용 사용자 환경에서 다른 관리자 사용자 인터페이스에 대한 링크가 있는 경우 사용자 인터페이스는 대상 관리자 권한으로 시작합니다. 따라서 전적으로 관리되는 애플리케이션에 방패를 배치할 필요가 없습니다.

애플리케이션의 사용자 인터페이스에 방패 아이콘을 추가하는 경우

관리 선택 애플리케이션

관리자 권한 프로세스 또는 COM 개체

초기 애플리케이션은 권한 상승 없이 시작됩니다. 관리 액세스 토큰이 필요한 사용자 인터페이스의 항목은 방패 아이콘으로 식별으로 데코레이팅됩니다. 이 장식은 사용자에게 해당 기능을 사용하려면 관리자의 승인이 필요하다는 것을 나타냅니다. 애플리케이션에서 이러한 단추 중 하나가 선택되었음을 감지하면 다음과 같은 두 가지 옵션이 있습니다.

• 애플리케이션은 ShellExeucute()를 사용하여 관리 작업을 수행하는 두 번째 프로그램을 시작합니다. 이 두 번째 프로그램은 requireAdministrator의 requestedExecutionLevel로 표시되므로 사용자에게 승인을 요청하는 메시지가 표시됩니다. 이 두 번째 프로그램은 전체 관리 액세스 토큰으로 실행되며 원하는 작업을 수행할 수 있습니다.
• 애플리케이션은 CreateElevatedComObject()를 사용하여 COM 개체를 시작합니다. 이 API는 승인 후 전체 관리 액세스 토큰을 사용하여 COM 개체를 시작하고 이 COM 개체는 원하는 작업을 수행할 수 있습니다.

이 메서드는 가장 풍부한 사용자 환경을 제공하며 관리 기능을 처리하는 기본 방법입니다.

다음 목록에서는 관리자 권한 프로세스 또는 COM 개체에 대한 요구 사항을 자세히 설명합니다.

• 제어판은 방패 장식과 필요한 아키텍처를 구현해야 합니다.
• 개발자는 사용자 인터페이스에서 방패를 어디로 이동해야 하는지 결정해야 합니다.
• 개발자는 사용자 인터페이스 개체에서 COM 개체로 비즈니스 논리를 분리하기 위해 아키텍처 작업을 수행해야 합니다.
• 방패 아이콘에 대한 OnClick 이벤트가 감지되면 개발자가 UAC 권한 상승 프로세스를 호출해야 합니다.

다음 목록에서는 관리자 권한 프로세스 또는 COM 개체를 올바르게 디자인할 때의 이점에 대해 자세히 설명합니다.

• 이는 두 사용자 유형 모두에 가장 적합한 전체 사용자 환경입니다. 사용자 인터페이스가 시작되고 모든 사용자가 볼 수 있으며 해당 사용자 인터페이스의 모든 UAC 기능에 모든 사용자가 액세스할 수 있습니다. 관리자 작업이 필요한 경우에만 사용자가 작업을 완료하기 위해 상승하려고 시도합니다.
• 이제 이 작업을 수행하면 UAC 규격을 완전히 준수할 수 있습니다.
• 사용자 인터페이스/COM 분리는 좋은 아키텍처 사례입니다.

방패 아이콘을 클릭하면 애플리케이션이 관리자 권한 프로그램 또는 관리자 권한 COM 개체를 실행하여 작업을 수행합니다.

관리자 전용 애플리케이션

이 instance 애플리케이션의 초기 시작에는 관리자 승인이 필요합니다. 이 메서드를 "시작하기 전에 프롬프트"라고 합니다. 시작되면 애플리케이션이 전체 관리 액세스 토큰으로 실행되므로 원하는 관리 작업을 수행할 수 있습니다. 이 메서드는 개발자에게 가장 적은 작업입니다. 애플리케이션의 매니페스트는 requireAdministrator의 requestedExecutionLevel로 표시됩니다.

중요 이렇게 하려면 개발자에게 최소한의 작업이 필요하지만 Windows Vista의 다른 관리 애플리케이션과 마찬가지로 관리자는 이 애플리케이션을 사용하기 위해 관리자를 승격해야 하며 표준 사용자는 애플리케이션을 사용할 수 없습니다.

다음 목록은 관리자 전용 애플리케이션에 대한 요구 사항을 자세히 설명합니다.

• 애플리케이션 매니페스트에는 requireAdministrator로 설정된 requestedExecutionLevel 표시가 포함되어야 합니다.
• Windows에서 전체 관리 액세스 토큰을 사용하여 애플리케이션을 시작하기 전에 사용자에게 관리자 승인을 요청하는 메시지가 표시됩니다.

다음 목록에서는 관리자 전용 애플리케이션을 올바르게 디자인할 때의 이점에 대해 자세히 설명합니다.

• 설치 애플리케이션이 관리 애플리케이션인 경우 운영 체제는 "추측"할 필요가 없습니다.
• 표준 사용자에게는 작업이 관리 작업이라는 힌트가 자동으로 제공됩니다. 예를 들어 requireAdministrator로 표시된 애플리케이션의 아이콘이 표시되면 아이콘에 방패가 포함됩니다.
• Windows Vista에서 애플리케이션을 requireAdministrator로 표시하면 애플리케이션이 시작되면 전체 관리자 액세스 토큰으로 실행됩니다. 사용자는 권한 상승하여 애플리케이션을 실행해야 합니다(관리 승인 모드의 관리자 또는 관리자 권한으로 실행 사용).

참고 애플리케이션 요구 사항을 표시Administrator는 애플리케이션을 자동으로 상승시키지 않습니다. 사용자는 애플리케이션을 시작하려면 여전히 권한 상승 동의를 제공해야 합니다. Windows Vista에서 자동으로 상승하도록 애플리케이션을 표시할 수 있는 방법은 없습니다.

다음 목록에서는 관리자 전용 애플리케이션을 디자인하기 위한 고려 사항에 대해 자세히 설명합니다.

• 이 사용자 환경은 사용자 인터페이스가 표시되기 전에 모든 사용자에게 권한 상승 프롬프트(자격 증명 프롬프트 또는 동의 프롬프트)가 표시됨을 의미합니다. 즉, 관리자 자격 증명으로 인증할 때까지 현재 설정을 단순히 볼 수 없음을 의미합니다.
• 설치 애플리케이션에서 requireAdministrator를 표시하는 경우 설치 프로그램을 실행하는 사용자가 애플리케이션을 사용자로 지정할 수 있는 사용자와 다르다는 점에 유의해야 합니다. 따라서 관리 설정 중에 HKCU(HKEY_CURRENT_USER) 및 사용자 프로필에 쓰기와 같은 기타 사용자별 설정을 수정해서는 안 됩니다.

중요 관리 애플리케이션을 실행하는 사용자가 컴퓨터의 일반 사용자와 다르다고 가정해야 합니다.

관리자 액세스 토큰이 필요한 실행 파일은 방패 아이콘 오버레이로 표시됩니다.

혼합 애플리케이션

혼합 애플리케이션은 사용자가 실행할 수 있는 애플리케이션으로, 시스템의 모든 사용자(표준 사용자, 관리 승인 모드의 관리자 및 백업 운영자와 같은 사이에 있는 사용자)입니다. 이는 "시작하기 전 프롬프트" 애플리케이션이기도 합니다. 애플리케이션은 호출자의 액세스 토큰으로 실행되며 표준 사용자에 대해 정상적으로 시작됩니다(권한 상승 프롬프트 없음). 그런 다음, 프로그램은 런타임에 해당 동작을 수정하여 사용자가 가져온 관리 액세스 토큰에 따라 사용할 수 없는 기능을 사용하지 않도록 설정해야 합니다.

혼합 애플리케이션은 시작되면 추가 관리 권한을 얻을 수 없습니다. 따라서 이전에 설명한 상승된 프로세스 또는 COM 개체 메서드의 유연성을 제공하지 않습니다. 이는 표준 사용자보다 높은 액세스 토큰이 필요하지만 전체 관리자보다 작은 애플리케이션에 가장 유용합니다.

예를 들어 MMC(Microsoft Management Console)는 highestAvailable로 표시됩니다. 진정한 표준 사용자가 MMC를 실행하는 경우 MMC는 상승 시도 또는 프롬프트 없이 표준 사용자 애플리케이션으로 시작됩니다. 사용자가 관리 승인 모드의 관리자 또는 백업 운영자와 같은 "분할 토큰" 사용자인 경우 운영 체제는 사용자에게 사용 가능한 "가장 높은" 권한으로 MMC를 시작하는 데 동의하라는 메시지를 표시합니다. Backup 운영자 권한이 있는 표준 사용자의 경우 권한 상승 후 MMC가 표준 사용자 + Backup 연산자를 사용하여 시작되지만 그 이상은 시작되지 않습니다. 관리자가 MMC를 시작하면 권한 상승 후 MMC가 전체 관리자 애플리케이션으로 실행됩니다.

혼합 애플리케이션을 올바르게 디자인할 때의 이점은 일부 기능을 사용하지 않도록 설정하더라도 시스템의 모든 사용자가 애플리케이션을 사용할 수 있다는 것입니다.

다음 목록에서는 혼합 애플리케이션을 디자인하기 위한 고려 사항에 대해 자세히 설명합니다.

• 개발자는 사용자가 사용할 수 있는 관리 Windows 권한 및 사용자 권한에 따라 애플리케이션의 동작을 동적으로 변경해야 합니다.
• 표준 사용자는 사용자 인터페이스의 관리 수준 함수에 대해 작동할 수 없습니다. 프로그램이 실행되면 프롬프트 권한 상승 가능성이 없습니다(관리자가 사용자 인터페이스를 열기 전에 상승해야 합니다).

참고 이전 글머리 기호 지점에 대한 한 가지 해결 방법이 있습니다. 관리자는 표준 사용자의 컴퓨터에서 관리자 권한 명령 프롬프트를 시작하고 명령 프롬프트에서 애플리케이션을 실행할 수 있습니다. 예를 들어 명령 프롬프트를 마우스 오른쪽 단추 로 클릭하고 관리자 권한으로 실행을 선택한 다음 명령 프롬프트에 "applicationname.exe"를 입력합니다.

사용자 환경은 관리 승인 모드에서 표준 사용자와 관리자 간에 분기됩니다.

혼합 애플리케이션 예: 백업 애플리케이션

백업 연산자 그룹의 멤버가 애플리케이션을 시작할 수 있습니다. 그런 다음 프로그램에서는 사용자가 사용할 수 있는 최고 수준의 관리 Windows 권한 및 사용자 권한이 프로그램 작업에 충분한지 확인합니다. 프로그램 시작 동작에 대한 자세한 내용은 이 문서의 애플리케이션 매니페스트 표시 및 애플리케이션 시작 동작 섹션을 참조하세요.

Administrator-Only 애플리케이션 디자인에 대한 주요 결정 사항

백 엔드 비즈니스 개체

이 섹션에서는 개발자가 최상의 사용자 환경을 제공하는 관리 애플리케이션을 개발할 때 선택할 수 있는 세 가지 모델에 대한 개요를 제공합니다.

• 관리 Broker 모델
• Back-End 서비스 모델
• 관리 COM 개체 모델

관리 Broker 모델

관리 Broker 모델에서 애플리케이션은 표준 사용자 실행 파일과 관리 실행 파일이라는 두 개의 독립적인 실행 파일로 나뉩니다. 개발자는 애플리케이션 매니페스트를 사용하여 표준 사용자 프로그램을 asInvoker의 requestedExecutionLevel로 표시하고 관리 프로그램을 requireAdministrator의 requestedExecutionLevel로 표시합니다. 사용자가 먼저 표준 사용자 프로그램을 시작합니다. 사용자가 표준 사용자 프로그램에 전체 관리자 액세스 토큰이 필요하다고 알고 있는 작업을 수행하려고 하면 ShellExecute()를 수행하고 관리 프로그램을 시작합니다. Windows ShellExecute() API는 매니페스트를 살펴보고 사용자의 전체 관리 액세스 토큰으로 애플리케이션을 실행하기 전에 사용자의 승인을 요청합니다. 그러면 관리 프로그램에서 관리 작업을 수행할 수 있습니다.

참고 관리 실행 프로그램은 공유 메모리, 로컬 RPC 또는 명명된 파이프를 사용하여 표준 사용자 실행 파일과 프로세스 간 통신을 사용하도록 설정할 수 있습니다. 관리 프로그램이 표준 사용자 실행 파일과의 통신을 사용하도록 설정하는 경우 개발자는 적절한 보안 방법을 사용하여 낮은 권한 프로그램의 모든 입력의 유효성을 검사해야 합니다.

참고 두 번째 프로그램이 시작되면 두 프로그램 간에 통신 채널이 없습니다.

다음 목록 세부 정보는 관리 브로커 모델에 사용합니다.

• 마법사 - 하드웨어 마법사가 필수 드라이버가 컴퓨터에 설치되어 있지 않거나 엔터프라이즈의 승인된 위치에 있다는 것을 알게 되면 드라이버를 컴퓨터 저장소로 이동할 수 있는 관리자 권한 애플리케이션이 필요합니다.
• Setup.exe 호출하는 Autorun.exe- 게임 CD를 처음 입력할 때 autorun.exe 필요한 작업은 애플리케이션을 설정하는 것입니다. CD를 두 번째로 삽입할 때 기본 작업은 게임을 플레이하는 것입니다.

관리 브로커 모델을 사용하는 이점은 개발자를 위해 구현하는 가장 쉬운 메커니즘일 수 있다는 것입니다.

다음 목록에서는 관리 Broker 모델 사용에 대한 몇 가지 단점을 자세히 설명합니다.

• 애플리케이션에서 애플리케이션으로의 전환은 사용자에게 혼동을 초래할 수 있습니다. 사용자가 모니터에서 새 애플리케이션이 "팝업"되는 이유를 계속 파악하기 어려울 수 있습니다.
• 또한 상태는 이러한 두 애플리케이션 간에 전달하기 어렵습니다. 예를 들어 동일한 CPL이 관리 및 비관리 기능을 갖도록 허용하기 위해 CPL(표준 사용자 제어판)과 해당 관리자 패널 간에 상태를 전달하는 데는 이 기능을 사용하지 않습니다. 표준 사용자 CPL은 상태를 어딘가에 저장해야 합니다.
• 종종 두 프로그램 간에 기능을 분할할 때 복제된 코드가 많이 있습니다.

관리 브로커 모델을 구현하려면 두 프로그램(표준 사용자 1개와 관리자 1개)을 만들고, 적절한 매니페스트 requestExecutionLevel로 표시하고, ShellExecute()를 사용하여 표준 사용자 프로그램에서 관리 프로그램을 시작합니다.

Back-End 서비스 모델

백 엔드 서비스 모델에서 애플리케이션은 사용자에게 사용자 인터페이스를 제공하는 표준 사용자 실행 파일과 시스템에서 실행되는 백 엔드 서비스인 두 개의 독립 실행 파일로 다시 분할됩니다. Microsoft RPC(원격 프로시저 호출)는 둘 간에 통신하는 데 사용됩니다. 프런트 엔드 애플리케이션은 asInvoker의 requestedExecutionLevel로 표시되고 백 엔드 서비스는 SYSTEM으로 실행됩니다. 애플리케이션과 백 엔드 서비스 간의 통신은 RPC를 사용하여 수행됩니다.

백 엔드 서비스 모델의 한 가지 용도는 바이러스 백신 프로그램 또는 스파이웨어 방지와 같이 시스템에 영향을 줄 수 있는 프로그램을 제어하는 것입니다. 프런트 엔드 애플리케이션은 로그온한 사용자가 서비스의 측면을 제어하는 수단을 제공합니다.

백 엔드 서비스 모델을 사용할 때의 주요 이점은 권한 상승 프롬프트가 필요하지 않는다는 것입니다.

다음 목록에서는 백 엔드 서비스 모델 사용에 대한 몇 가지 단점을 자세히 설명합니다.

• 서비스는 프런트 엔드 애플리케이션이 지시할 수 있는 활동 유형을 제한해야 합니다. 예를 들어 바이러스 백신 서비스는 표준 사용자가 시스템 검사를 시작하도록 허용하지만 실시간 바이러스 검사를 사용하지 않도록 설정할 수는 없습니다.
• 시스템에 불필요한 서비스를 추가하면 전체 시스템에 영향을 미칠 수 있습니다. Windows Vista 구현에 서비스가 진정으로 필요하고 서비스가 제대로 설계되었는지 확인합니다.

백 엔드 서비스 모델을 구현하려면 표준 사용자 프런트 엔드 애플리케이션 및 백 엔드 서비스를 만듭니다. 제품 설치 시간 동안 시스템에 서비스를 설치합니다.

관리 COM 개체 모델

이 모델은 여기에 포함되어 있지만 이 문서의 앞에서 자세히 설명했습니다. 관리 COM 개체 모델을 사용하면 동적 관리자 권한 상승이 애플리케이션 또는 제어판 내에서 특정 작업을 수행할 수 있습니다.

관리 COM 개체 모델을 사용하는 주요 이점은 사용자에게 최상의 사용자 환경을 제공하는 것입니다.

다음 목록에서는 관리 COM 개체 모델 사용에 대한 몇 가지 단점을 자세히 설명합니다.

• 각 애플리케이션 기능을 평가하고 관리자 기능에 대해 테스트해야 하며 해당 함수는 백 엔드 COM 개체에서 제공해야 하므로 개발자에게 가장 많은 작업이 필요합니다.
• 사용자는 권한 상승 승인을 제공해야 합니다.
• 표준 사용자 애플리케이션 및 관리 백 엔드 COM 개체의 결과 "단위"는 이제 "drivable"이며 UIPI 및 기타 격리 메커니즘으로 보호되지 않습니다.

관리 COM 개체 모델을 구현하려면 표준 사용자 프런트 엔드 애플리케이션을 만들고 관리자 권한 백 엔드 COM 개체를 시작하여 관리 작업을 수행합니다.

5. 애플리케이션의 설치 관리자 다시 디자인

다음 모범 사례는 Windows Vista 또는 UAC 환경에서 잘 동작하는 애플리케이션 설치에 대한 것입니다. 이 목록에는 일부만 나와 있습니다. UAC 요구 사항을 포함하여 Windows Vista의 로고 요구 사항에 대한 자세한 설명은 Windows Vista 로고 설명서 및 Windows Vista 로고 지침 문서의 최신 초안에 대한 자세한 버전을 참조하세요.

애플리케이션을 다시 디자인하는 동안 이러한 요구 사항을 사용합니다.

설치 패키지에 Windows Installer 4.0을 사용합니다.

다음 요구 사항 중 대부분은 이미 Windows Installer 엔진에 통합되어 있습니다. 설치 패키지에 Windows Installer를 사용하면 Windows Vista 설치 요구 사항을 따르는 데 도움이 됩니다.

버전이 지정된 파일을 사용하고 설치하는 동안 파일을 다운그레이드하지 않습니다.

파일 버전 관리를 사용하면 설치가 완료되면 최종 설치 상태가 올바른지 확인할 수 있습니다. 파일 버전이 없으면 다양한 설치 시나리오에서 설치가 제대로 작동하는지 확인하기 위해 몇 가지 특별한 전달이 필요합니다. 또한 버전이 지정된 파일을 설치할 때 버전, 특히 공유 파일을 다운그레이드하지 마세요. 버전 다운그레이드는 애플리케이션에 적합할 수 있지만 다른 애플리케이션에 문제가 자주 발생합니다. Windows Installer 패키지에서 올바른 버전의 파일을 선언하면 Windows Installer는 기본적으로 이 기능을 지원합니다.

애플리케이션을 설치하고 사용자별 데이터를 다른 위치에 저장합니다.

애플리케이션은 Programs Files 디렉터리 아래의 폴더에 설치해야 합니다. 이를 구성하려면 Windows Installer 패키지의 Direcotry 테이블에서 ProgramFilesFolder 속성을 사용할 수 있습니다. 사용자별 구성 데이터는 \Users\username\AppData 디렉터리 아래의 파일 또는 HKCU 루트 아래의 레지스트리 키에 저장되어야 합니다. 사용자 데이터, 템플릿 및 애플리케이션에서 만든 파일은 모두 \Users\username 하위 디렉터리에 적절한 위치를 갖습니다. 이전에는 적용되지 않았지만 많은 사용자가 전체 관리자 액세스 토큰으로 프로그램을 실행했기 때문에 올바른 위치에 정보를 배치하지 않는 애플리케이션은 실패할 수 있습니다. 가상화가 꺼져 있는 경우 특히 그렇습니다.

공유 구성 요소를 설치할 때 일관된 폴더 위치를 사용합니다.

공유 구성 요소는 Windows Installer 패키지의 디렉터리 테이블에서 CommonFilesFolder 속성을 사용하여 Common Files 디렉터리에 설치해야 합니다. 공유 구성 요소 관리는 문제가 될 수 있으며 가능하면 피해야 합니다. 공유 구성 요소를 일관되게 설치하지 않는 개발자는 이전 구성 요소를 가리키는 COM(구성 요소 개체 모델) 등록 정보로 끝날 수 있습니다. MSM(Windows Installer Merge Modules)은 공유 구성 요소를 설치하는 모든 패키지의 컨텍스트에서 공유 구성 요소를 일관되게 설치할 수 있도록 특별히 설계되었습니다. 다른 문제는 공유 구성 요소를 수정하면 기존 애플리케이션이 실패할 때 발생합니다. 이 문제를 해결하는 한 가지 방법은 Microsoft .NET 또는 Win32 버전 어셈블리를 사용하여 애플리케이션을 빌드하는 것입니다.

설치가 실패하면 설치 롤백을 수행합니다.

부분적으로 설치된 소프트웨어는 이상하고 예기치 않은 방법으로 실패하여 사용자 환경이 저하될 수 있습니다. Windows Installer는 이 롤백 기능을 지원합니다.

사용자의 프로필 전체에 애플리케이션 바로 가기를 설치하지 마세요.

Windows의 알려진 모든 노출 지점에 애플리케이션 아이콘을 추가하려는 경우가 많지만 사용자가 컴퓨터를 제어하지 못했다고 느끼는 경우가 많습니다. 그런 다음 사용자는 이러한 바로 가기를 수동으로 제거하여 컴퓨터를 원하는 모양과 느낌으로 되돌려야 합니다. 개발자가 데스크톱에 아이콘을 추가하려는 경우 설치하는 동안 사용자에게 사용 권한을 요청합니다. Windows Vista는 설치 후 애플리케이션의 검색 가능성과 가장 최근에 사용한 애플리케이션 목록을 해결하여 큰 시작 메뉴 트래버스를 방지합니다.

사용자 로그온 시 백그라운드 애플리케이션을 자동으로 시작하지 않습니다.

설치하는 동안 시작 그룹 또는 실행 키에 프로그램을 추가할 수 있지만 시스템에 오버헤드가 추가됩니다. 시간이 지남에 따라 사용자 시스템의 성능이 크게 저하 될 수 있습니다. 애플리케이션이 백그라운드 작업의 이점을 얻을 수 있는 경우 사용자가 구성할 수 있도록 허용합니다. 또한 HLKM 실행 키를 통해 시작 작업을 추가하면 표준 사용자 계정이 나중에 동작을 수정하지 못할 수 있습니다. 사용자가 로그인 시 애플리케이션을 시작하려면 HKCU의 실행 키에 정보를 저장합니다.

클린 제거 논리를 따릅니다.

사용자는 애플리케이션을 제거하여 디스크 공간을 확보할 뿐만 아니라 애플리케이션을 설치하기 전에 컴퓨터를 해당 상태로 되돌릴 수도 있습니다. 애플리케이션의 제거 프로세스는 애플리케이션을 올바로 완전히 제거해야 합니다. Windows Installer는 기본적으로 다음 규칙으로 설정됩니다.

• 공유하지 않는 모든 애플리케이션 파일 및 폴더.
• 참조 수(refcount)가 0에 도달하는 공유 애플리케이션 파일입니다.
• 다른 프로그램에서 공유할 수 있는 키를 제외한 레지스트리 항목입니다.
• 설치 시 애플리케이션이 만든 시작 메뉴의 모든 바로 가기입니다.
• 사용자 기본 설정은 사용자 데이터로 간주되어 남아 있을 수 있지만 완전히 클린 제거를 수행하는 옵션이 포함되어야 합니다.
• 제거자 자체(Windows 설치 관리자를 사용하지 않는 경우).

6. 애플리케이션에 애플리케이션 매니페스트 만들기 및 포함

Windows Vista에서 애플리케이션을 표시하는 올바른 방법은 애플리케이션에 필요한 사항을 운영 체제에 알려주는 애플리케이션 매니페스트를 프로그램 내에 포함하는 것입니다. Windows Vista 릴리스에는 매니페스트되지 않거나 서명되지 않은 코드를 전체 관리 액세스 토큰으로 실행할 수 있도록 하는 프로비저닝이 있습니다.

참고 이후 릴리스에서 관리자 권한 애플리케이션을 실행하는 유일한 방법은 애플리케이션에 필요한 권한 수준을 식별하는 서명된 매니페스트를 갖는 것입니다.

애플리케이션 매니페스트 스키마

애플리케이션 매니페스트는 Windows Vista 릴리스에 새로운 것이 아닙니다. 매니페스트는 애플리케이션 개발자가 애플리케이션이 테스트된 DLL 버전과 같은 항목을 식별하는 데 도움이 되도록 Windows XP에서 사용되었습니다. 실행 수준을 제공하는 것은 기존 매니페스트 스키마에 대한 확장입니다.

Windows Vista 애플리케이션 매니페스트는 개발자가 요청된 실행 수준으로 애플리케이션을 표시할 수 있도록 하는 특성으로 향상되었습니다. 다음은 이 형식입니다.

<requestedExecutionLevel
level="asInvoker|highestAvailable|requireAdministrator"
uiAccess="true|false"/>

가능한 요청된 실행 수준 값

값	Description	주석
Asinvoker	애플리케이션은 부모 프로세스와 동일한 액세스 토큰으로 실행됩니다.	표준 사용자 애플리케이션에 권장됩니다. 이 문서에 제공된 지침에 따라 내부 권한 상승 지점을 사용하여 내화합니다.
highestAvailable	애플리케이션은 현재 사용자가 얻을 수 있는 가장 높은 권한으로 실행됩니다.	혼합 모드 애플리케이션에 권장됩니다. 향후 릴리스에서 애플리케이션의 인프라를 재정의할 계획입니다.
requireAdministrator	애플리케이션은 관리자에 대해서만 실행되며 관리자의 모든 액세스 토큰을 사용하여 애플리케이션을 시작해야 합니다.	관리자 전용 애플리케이션에 권장됩니다. 내부 권한 상승 지점은 필요하지 않습니다. 애플리케이션이 이미 관리자 권한으로 실행되고 있습니다.

참고 호스팅 애플리케이션은 특정 유형의 호스팅된 애플리케이션을 지원하는 경우에만 표준 사용자 또는 관리자 전용 애플리케이션이 될 수 있습니다. 예를 들어 MMC.exe 이제 관리 스냅인만 호스트하고 Explorer.exe 표준 사용자 코드만 호스트합니다.

시스템 동작

애플리케이션 Markin	가상화?
답변	Yes
Asinvoker	No
requireAdministrator	No
highestAvailable	No

애플리케이션 매니페스트 표시 및 애플리케이션 시작 동작

이 섹션에서는 부모 프로세스 액세스 토큰에 따라 권한 상승 프롬프트의 동작, 사용자 계정 컨트롤에 대한 설정: 관리 승인 모드 정책의 관리자 권한 상승 프롬프트 동작 및 사용자 계정 컨트롤: 표준 사용자 정책에 대한 권한 상승 프롬프트 동작 및 애플리케이션에 대해 요청된 실행 수준 표시에 대해 자세히 설명합니다.

애플리케이션을 실행할 수 있는지 여부와 가져올 수 있는 사용자 권한 및 관리 Windows 권한은 애플리케이션 호환성 데이터베이스에서 애플리케이션의 요청된 실행 수준과 애플리케이션을 시작한 사용자 계정에서 사용할 수 있는 관리 권한의 조합에 따라 달라집니다. 다음 표에서는 이러한 가능한 조합을 기반으로 가능한 런타임 동작을 식별합니다.

로컬 관리자 그룹의 구성원에 대한 애플리케이션 시작 동작

부모 프로세스 액세스 토큰	로컬 관리자 그룹의 구성원에 대한 동의 정책	None 또는 asInvoker	highestAvailable	requireAdministrator
표준 사용자	프롬프트 없음	애플리케이션이 표준 사용자로 시작됨	애플리케이션이 전체 관리 액세스 토큰으로 시작됩니다. 프롬프트 없음	애플리케이션이 전체 관리 액세스 토큰으로 시작됩니다. 프롬프트 없음
표준 사용자	동의 확인	애플리케이션이 표준 사용자로 시작됨	애플리케이션이 전체 관리 액세스 토큰으로 시작됩니다. 동의 프롬프트	애플리케이션이 전체 관리 액세스 토큰으로 시작됩니다. 동의 프롬프트
표준 사용자	자격 증명 확인	애플리케이션이 표준 사용자로 시작됨	애플리케이션이 전체 관리 액세스 토큰으로 시작됩니다. 자격 증명 프롬프트	애플리케이션이 전체 관리 액세스 토큰으로 시작됩니다. 자격 증명 프롬프트
관리자(UAC를 사용할 수 없음)	해당 없음	애플리케이션이 전체 관리 액세스 토큰으로 시작됩니다. 프롬프트 없음	애플리케이션이 전체 관리 액세스 토큰으로 시작됩니다. 프롬프트 없음	애플리케이션이 전체 관리 액세스 토큰으로 시작됩니다. 프롬프트 없음

표준 사용자 계정에 대한 애플리케이션 시작 동작

부모 프로세스 액세스 토큰	표준 사용자에 대한 동의 정책	Asinvoker	highestAvailable	requireAdministrator
표준 사용자	프롬프트 없음	애플리케이션이 표준 사용자로 시작됨	애플리케이션이 표준 사용자로 시작됨	애플리케이션이 시작되지 않습니다.
표준 사용자	자격 증명 확인	애플리케이션이 표준 사용자로 시작됨	애플리케이션이 표준 사용자로 시작됨	애플리케이션을 실행하기 전에 관리자 자격 증명 확인
표준 사용자(UAC를 사용할 수 없음)	해당 없음	애플리케이션이 표준 사용자로 시작됨	애플리케이션이 표준 사용자로 시작됨	애플리케이션이 시작될 수 있지만 나중에 실패합니다.

추가 권한이 있는 표준 사용자에 대한 애플리케이션 시작 동작(예: Backup 연산자)

부모 프로세스 액세스 토큰	표준 사용자에 대한 동의 정책	Asinvoker	highestAvailable	requireAdministrator
표준 사용자	프롬프트 없음	애플리케이션이 표준 사용자로 시작됨	추가 권한이 있는 표준 사용자로 애플리케이션 시작	애플리케이션이 시작되지 않습니다.
표준 사용자	자격 증명 확인	애플리케이션이 표준 사용자로 시작됨	애플리케이션을 실행하기 전에 자격 증명 확인	애플리케이션을 실행하기 전에 관리자 자격 증명 확인
표준 사용자(UAC를 사용할 수 없음)	해당 없음	애플리케이션이 표준 사용자로 시작됨	추가 권한이 있는 표준 사용자로 애플리케이션 시작	애플리케이션이 시작될 수 있지만 나중에 실패합니다.

uiAccess 값

가능한 uiAccess 값

값	설명
거짓	애플리케이션은 바탕 화면에 있는 다른 창의 사용자 인터페이스에 대한 입력을 구동할 필요가 없습니다. 접근성을 제공하지 않는 애플리케이션은 이 플래그를 false로 설정해야 합니다. 바탕 화면의 다른 창(예: 화상 키보드)에 입력을 구동하는 데 필요한 애플리케이션은 이 값을 true로 설정해야 합니다.
참	애플리케이션은 사용자 인터페이스 제어 수준을 바이패스하여 데스크톱에서 더 높은 권한 창으로 입력을 구동할 수 있습니다. 이 설정은 사용자 인터페이스 보조 기술 애플리케이션에만 사용해야 합니다.

중요uiAccess 플래그가 true 로 설정된 애플리케이션은 제대로 시작하려면 Authenticode에 서명 되어야 합니다. 또한 애플리케이션은 파일 시스템의 보호된 위치에 있어야 합니다. \Program Files\ 및 \windows\system32\는 현재 허용되는 두 개의 보호된 위치입니다.

Microsoft Visual Studio를 사용하여 포함된 매니페스트를 만드는 방법

Visual Studio는 PE(이식 가능한 실행 파일) 이미지의 리소스 섹션에 XML 매니페스트 파일을 자동으로 포함하는 기능을 제공합니다. 이 섹션에서는 Visual Studio를 사용하여 매니페스트를 포함하는 서명된 PE 이미지를 만드는 방법을 설명합니다. 따라서 이 매니페스트에는 애플리케이션이 Windows Vista에서 원하는 권한 수준으로 실행될 수 있도록 하는 필요한 requestedExecutionLevel 특성이 포함될 수 있습니다. 프로그램이 시작되면 매니페스트 정보가 PE의 리소스 섹션에서 추출되고 운영 체제에서 사용됩니다. Visual Studio GUI(그래픽 사용자 인터페이스)를 사용하여 매니페스트를 포함할 필요는 없습니다. 소스 코드에 필요한 변경 내용이 있으면 명령줄 도구를 사용하여 컴파일하고 연결하면 결과 PE 이미지에도 매니페스트가 포함됩니다.

매니페스트 파일

애플리케이션을 표시하려면 먼저 대상 애플리케이션과 함께 사용할 매니페스트 파일을 만듭니다. 이 작업은 모든 텍스트 편집기를 사용하여 수행할 수 있습니다. 매니페스트 파일은 아래 예제와 같이 .manifest 확장명이 있는 target.exe 이름이 같아야 합니다.

Executable: IsUserAdmin.exe 
Manifest:IsUserAdmin.exe.manifest
Sample application manifest file:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
  <assemblyIdentity version="1.0.0.0"
     processorArchitecture="X86"
     name="IsUserAdmin"
     type="win32"/> 
  <description>Description of your application</description> 
  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>
</assembly>

애플리케이션에 맞게 조정해야 하는 매니페스트의 부분은 굵게 표시됩니다. 이름은 다음과 같습니다.

• 어셈블리 ID
• 이름
• 형식입니다.
• 설명
• requestedExecutionLevel의 특성

Windows Vista 전용 애플리케이션용 Visual Studio 2005를 사용하여 C/C++ 코드 내에서 애플리케이션 매니페스트 빌드

중요 애플리케이션이 Windows Vista와 Windows XP 모두에서 실행되도록 의도된 경우 다음 섹션인 Windows XP 및 Windows Vista 애플리케이션용 Microsoft Visual Studio 2005를 사용하여 매니페스트 빌드 및 포함에 자세히 설명된 절차를 따라야 합니다.

다음으로, 애플리케이션의 리소스 파일(.rc 파일)에 줄을 추가하여 매니페스트를 실행 파일에 연결하여 Microsoft Visual Studio가 PE 파일의 리소스 섹션 내에 매니페스트를 포함하도록 해야 합니다. 이렇게 하려면 빌드 중인 프로젝트의 소스 코드와 동일한 디렉터리에 매니페스트를 배치하고 .rc 파일을 편집하여 다음 줄을 포함합니다.

#define MANIFEST_RESOURCE_ID 1
MANIFEST_RESOURCE_ID RT_MANIFEST "IsUserAdmin.exe.manifest"

애플리케이션을 다시 빌드한 후 매니페스트는 실행 파일의 리소스 섹션에 포함되어야 합니다.

Windows XP 및 Windows Vista 애플리케이션용 Microsoft Visual Studio 2005를 사용하여 매니페스트 빌드 및 포함

Visual Studio 2005에서 대상 실행 파일에 추가 매니페스트 파일을 포함할 수 있도록 허용하는 C/C++ IDE(통합 개발 환경) 인터페이스는 XML에서 일부 처리를 수행하여 중복 xmlns 태그를 삽입합니다. 이 때문에 애플리케이션이 Windows Vista 및 Windows XP 모두에서 실행되어야 하는 경우 Visual Studio 2005 C++ 프로젝트에 매니페스트를 포함하는 방법에 대해 이전에 설명한 메서드를 사용할 수 없습니다. 다음 절차는 trustInfo 섹션에 명시적 버전 태그를 포함하도록 수정됩니다.

XML에서 중복 네임스페이스 선언을 생성하는 문제를 해결하기 위해 mt.exe 도구에 대한 수정이 계획되어 있습니다. 새 버전의 mt.exe 사용할 수 있게 될 때까지 매니페스트의 trustinfo 섹션에 버전 태그를 명시적으로 추가하여 매니페스트를 병합하는 문제를 방지할 수 있습니다. 샘플 매니페스트는 다음과 같습니다.

<?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">
            </ms_asmv2:requestedExecutionLevel>
         </ms_asmv2:requestedPrivileges>
      </ms_asmv2:security>
   </ms_asmv2:trustInfo>
</assembly>

C 또는 C++ 프로젝트

다음 절차에서는 Visual Studio 2005에서 C 또는 C++ 프로젝트 형식에 대한 매니페스트를 만드는 방법을 자세히 설명합니다.

Microsoft Visual Studio 2005에서 C 또는 C++ 프로젝트에 대한 매니페스트를 만들려면

1. Microsoft Visual Studio 2005에서 프로젝트 열기
2. 프로젝트에서 속성을 선택합니다.
3. 속성에서 매니페스트 도구를 선택한 다음 입력 및 출력을 선택합니다.
4. 추가 매니페스트 파일 아래에 애플리케이션 매니페스트 파일의 이름을 추가합니다.
5. 애플리케이션을 다시 빌드합니다.

참고 명시적 버전 태그를 포함하는 업데이트된 매니페스트를 사용하면 애플리케이션이 Windows Vista 및 Windows XP 모두에서 올바르게 실행될 수 있습니다.

관리 코드(C#, J# 및 Visual Basic)

Visual Studio는 현재 관리 코드에 기본 매니페스트를 포함하지 않습니다. 관리 코드의 경우 개발자는 mt.exe 사용하여 대상 실행 파일에 기본 매니페스트를 삽입합니다. 단계는 다음과 같습니다.

mt.exe사용하여 대상 실행 파일에 기본 매니페스트 파일을 삽입하려면

1. Windows 메모장과 같은 텍스트 편집기를 사용하여 기본 매니페스트 파일 temp.manifest를 만듭니다.
2. mt.exe 사용하여 매니페스트를 삽입합니다. 명령은 다음과 같습니다. mt.exe –manifest temp.manifest –outputresource:YourApp.exe;#1

빌드 후 Visual Studio에서 애플리케이션 매니페스트를 단계로 추가

애플리케이션 매니페스트 추가는 빌드 후 단계로도 자동화할 수 있습니다. 이 옵션은 C/C++와 C# 및 J#의 관리 코드 언어 2개에 사용할 수 있습니다.

참고 IDE에는 현재 Visual Basic 애플리케이션에 대한 빌드 후 옵션이 포함되어 있지 않습니다.

프로젝트 속성에 빌드 후 작업으로 다음 줄을 배치합니다.

mt.exe -manifest "$(ProjectDir)$(TargetName).exe.manifest" 
-updateresource:"$(TargetDir)$(TargetName).exe;#1"

7. 애플리케이션 테스트

표준 사용자 분석기와의 애플리케이션 호환성을 위해 다시 디자인된 애플리케이션 또는 새 애플리케이션을 테스트합니다. 이 프로세스를 자세히 설명하는 절차는 이 문서의 앞부분에서 UAC 호환성을 위한 애플리케이션 테스트 섹션에 설명되어 있습니다.

다음 워크플로를 사용하여 애플리케이션을 테스트합니다.

최종 UAC 호환성을 위해 애플리케이션을 테스트하려면

1. 표준 사용자 분석기 도구를 사용하여 애플리케이션을 테스트합니다.
2. 관리 승인 모드에서 관리자 권한으로 Windows Vista 컴퓨터에 로그온하고 프로그램을 실행합니다. 모든 기능을 테스트하고 사용자 환경을 기록해 둡니다. 그에 따라 권한 상승 또는 사용자 인터페이스 버그를 제출합니다.
3. Windows Vista 컴퓨터에 표준 사용자로 로그온하고 프로그램을 실행합니다. 모든 기능을 테스트하고 관리 승인 모드 사용자 환경의 관리자와 비교하여 표준 사용자 환경의 차이점이나 실패를 확인합니다. 그에 따라 권한 상승 및 사용자 환경 버그를 제출합니다.

8. Authenticode 애플리케이션 서명

이제 애플리케이션에 검색되는 매니페스트와 애플리케이션 시작 시 구문 분석된 정보가 포함됩니다. 그러나 실행 파일은 변조될 수 있습니다. 이를 방지하려면 Authenticode 서명을 사용하여 애플리케이션에 서명해야 합니다. Windows Vista에는 서명되지 않은 애플리케이션이 전체 관리자 액세스 토큰으로 시작되지 않도록 하는 기능이 있습니다. 더 친숙한 사용자 인터페이스를 표시하는 동안 잠긴 환경에서 애플리케이션이 올바르게 작동하도록 하려면 Authenticode 서명으로 서명해야 합니다.

애플리케이션에 서명하려면 makecert.exe 인증서를 생성하거나 VeriSign, Thawte 또는 Microsoft CA와 같은 상용 CA(인증 기관) 중 하나에서 코드 서명 키를 가져올 수 있습니다.

참고 애플리케이션을 설치하는 고객의 대상 컴퓨터에서 애플리케이션을 신뢰할 수 있는 경우 상업용 인증서가 필요합니다.

makecert.exe 파일을 사용하여 서명 키 쌍을 생성하는 경우 1024비트 키만 생성한다는 점에 유의하세요. Authenticode 서명은 적어도 2048비트 키여야 합니다. makecert.exe 파일은 테스트 목적으로만 사용해야 합니다.

다음 절차에서는 makecert.exe 사용하여 서명 키 쌍을 생성하기 위한 높은 수준의 요구 사항을 자세히 설명합니다. 예제 및 makecert.exe 매개 변수는 이 절차를 따릅니다.

makecert.exe 사용하여 서명 키 쌍을 생성하려면

1. 인증서를 생성합니다.
2. 코드에 서명합니다.
3. 테스트 인증서를 설치합니다.

서명 절차 예제

다음 절차는 예제로 제공되며 엄격하게 따르기 위한 것이 아닙니다. 예를 들어 테스트 인증서 이름을 인증서 이름으로 바꾸고 프로시저를 특정 CA 및 개발 환경에 맞게 조정해야 합니다.

1단계: 인증서 생성

makecert -r -pe -ss PrivateCertStore -n "CN=Contoso.com(Test)" 
ContosoTest.cer

makecert.exe 매개 변수

매개 변수	Description
/r	자체 서명된 인증서 생성
/Pe	인증서의 프라이빗 키를 서명 컴퓨터로 내보낼 수 있도록 합니다.
/ss StoreName	테스트 인증서를 저장할 인증서 저장소 이름입니다. 예: PrivateCertStore
/n X500Name	인증서 주체의 X500 이름입니다. 예: Contoso.com(테스트)
CertificateName.cer	인증서 이름입니다. 예: ContosoTest.cer

2단계: 코드 서명

Signtool sign /v /s PrivateCertStore /n Contoso.com(Test) /t 
http://timestamp.verisign.com/scripts/timestamp.dll file.exe

3단계: 테스트 인증서 설치

테스트 인증서를 설치하려면

1. 명령 프롬프트를 마우스 오른쪽 단추로 클릭하고 관리자 권한으로 실행을 선택하여 관리자 권한 명령 창을 시작합니다.
2. 명령 프롬프트에서 mmc.exe 입력하고 Enter 키를 누릅니 다.
3. mmc에서 파일을 선택한 다음 스냅인 추가/제거...를 선택합니다.
4. 스냅인 추가 또는 제거에서 인증서를 선택하고 추가를 클릭한 다음 확인을 클릭합니다.
5. 인증서 스냅인 대화 상자에서 컴퓨터 계정을 선택하고 다음을 클릭합니다.
6. 컴퓨터 선택에서 로컬 컴퓨터를 선택한 다음 확인을 클릭합니다.
7. 스냅인 추가 또는 제거에서 확인을 클릭합니다.
8. 인증서 스냅인에서 신뢰할 수 있는 루트 인증 기관으로 이동하여 인증서를 마우스 오른쪽 단추로 클릭하고 모든 작업을 선택한 다음 가져오기...를 선택합니다.
9. 인증서 가져오기 마법사에서 테스트 인증서 ContosoTest.cer을 가져옵니다.

9. Windows Vista 로고 프로그램에 참여

Microsoft는 고객이 플랫폼 기능 및 품질 목표에 대한 포괄적인 기준 정의를 충족하는 시스템 및 주변 장치를 식별하여 최종 사용자에게 훌륭한 컴퓨팅 환경을 보장하는 데 도움이 되는 Windows Vista 로고 프로그램을 제공합니다.

표준 사용자를 위한 애플리케이션 배포 및 패치

일반적으로 기업은 사용자의 워크스테이션에 애플리케이션을 자동화된 방식으로 설치하여 관리 비용을 절감하는 방법을 고려해야 합니다. 이 문제에는 기본적으로 두 가지 부분이 있습니다. 첫째, 이러한 애플리케이션을 배포용으로 패키지하는 방법과 두 번째로 배포하는 데 사용해야 하는 기술입니다. 소규모 엔터프라이즈 환경의 경우 강력하고 자동화된 배포 메커니즘이 필요하지 않을 수 있습니다.

엔터프라이즈가 해당 환경에서 실행되는 소프트웨어의 인벤토리를 이미 사용했다고 가정하면 다음 단계는 배포를 위해 이러한 애플리케이션을 다시 패키징하는 것입니다. Windows Installer 형식은 사용자별 설정 관리를 컴퓨터별 설정과 분리하는 고유한 기능을 하므로 권장합니다. 이러한 유형의 관리는 일반적으로 다른 패키징 형식, 특히 SYSTEM과 같은 더 많은 권한이 있는 계정에서 단순히 실행되는 배포 실행 파일에서는 불가능합니다. MSDN 라이브러리에는 Windows Installer에 대한 많은 문서가 포함되어 있습니다. 한 가지 제안 사항은 Windows Installer 설명서에 대한 로드맵입니다.

Windows Installer 형식에는 사용자가 그룹 정책(Microsoft IntelliMirror) 및 SMS를 통해 이러한 애플리케이션의 설치를 제어하는 기능이 포함되어 있습니다. 파일 확장명 또는 바로 가기를 사용하여 주문형 설치를 사용하도록 설정하려면 Windows Installer 기반 패키지의 다음 테이블이 광고 데이터(바로 가기, 확장명, 아이콘 및 동사)로 채워져야 합니다. 클래스, MIME, ProgID 및 TypeLib도 채우는 것이 좋습니다. IntelliMirror 및 주문형 설치에 대한 자세한 내용은 패치 Per-User 관리되는 애플리케이션 을 참조하세요.

애플리케이션이 사용자별로 설치하고 ClickOnce와 같은 자동 업데이트를 지원할 수 있는 다른 설치 관리자 기술이 있습니다. 즉, 설치 관리자가 설치하는 데 관리자 이상의 권한이 필요하지 않으며 컴퓨터가 네트워크에 연결되어 있는 한 사용자는 항상 최신 버전을 실행합니다. 또한 IT 전문가가 이러한 애플리케이션의 설치를 제어하는 기능에 몇 가지 제한을 줍니다.

ClickOnce 배포는 사용자가 웹 사이트, CD 또는 UNC(범용 명명 규칙) 경로에서 매니페스트 링크와 같은 매니페스트 링크를 클릭할 때 클라이언트 쪽 애플리케이션을 자동으로 설치하고 구성하는 Microsoft .NET 설치 기술입니다. 기본적으로 애플리케이션은 임시 인터넷 파일 폴더에 자신을 복사하고 제한된 환경 내에서 실행됩니다.

참고 애플리케이션이 완전 신뢰를 제공하는 IT 강력한 이름으로 서명된 경우에도 파일 시스템 및 레지스트리의 특정 부분에 액세스하는 등 관리자 권한이 필요한 작업은 수행할 수 없습니다. 그러나 ClickOnce 애플리케이션은 사용자별 애플리케이션으로 대상으로 지정되므로 문제가 되지 않습니다.

중요 ClickOnce는 관리 작업을 수행하는 애플리케이션을 배포하는 데 사용하면 안 됩니다.

단일 컴퓨터에 배포

단일 컴퓨터에 대한 애플리케이션을 배포하려면 관리자가 해당 컴퓨터에 애플리케이션을 "게시"해야 합니다.

도메인의 모든 사용자에게 배포

도메인의 모든 사용자를 보급하려면 관리자가 그룹 정책 배포를 통해 애플리케이션을 "게시"해야 합니다. 현재 Windows Server 2003 운영 체제 및 Windows 2000 Server® 운영 체제의 그룹 정책 기반 소프트웨어 배포 구성 요소만 이 기능을 활용합니다.

Windows Installer 4.0을 사용하여 표준 사용자로 애플리케이션 패치

표준 사용자 계정 패치를 사용하면 Windows Installer 패키지 작성자가 향후 표준 사용자가 적용할 수 있는 서명된 패치를 식별할 수 있습니다. Windows Installer 4.0에서 표준 사용자 패치를 사용하도록 설정하려면 다음 조건을 충족해야 합니다.

• 애플리케이션이 Windows Installer 4.0을 사용하여 에 설치되었습니다.
• 애플리케이션은 원래 컴퓨터별로 설치되었습니다.
• MsiPatchCertificate 테이블이 있고 원래 창 설치 관리자 패키지(.msi 파일)에 채워집니다.
• 패치는 MsiPatchCertificate 테이블에 나열된 인증서를 사용하여 디지털 서명됩니다.
• 패치는 디지털 서명에 대해 유효성을 검사할 수 있습니다.
• MSIDISABLELUAPATCHING 속성 또는 DisableLUAPatching 정책을 설정하여 표준 사용자 계정 패치를 사용하지 않도록 설정하지 않았습니다.

Windows Installer 4.0 표준 사용자 제거 동작

표준 사용자가 적용한 Windows Installer 4.0 패치의 예상 동작은 표준 사용자가 제거할 수도 있다는 것입니다.

일반적인 문제 해결

다음 섹션에서는 Windows Vista의 애플리케이션에서 발생하는 일반적인 문제에 대해 자세히 설명합니다.

일반적인 문제는 다음과 같습니다.

• ActiveX 설치 문제
• ActiveX 문서가 설치되지 않음
• 애플리케이션, 프레임워크 또는 추가 기능 필요
• 설치/패치에 대한 관리 권한이 필요합니다.
• 사용자별 애플리케이션 설정 위치
• 애플리케이션은 기본적으로 보호된 디렉터리에 저장됩니다.

ActiveX 설치 문제

ActiveX 컨트롤은 관리자가 설치해야 합니다. ActiveX 컨트롤은 일반적으로 웹 브라우저 기능을 확장하여 보다 유연한 사용자 인터페이스를 만들거나 웹 브라우저 내에서 실행되는 애플리케이션에 대해 일반적으로 거부되는 컴퓨터 리소스에 대한 액세스를 높이기 위해 LOB(기간 업무) 애플리케이션에서 사용됩니다. ActiveX 컨트롤은 일반적으로 웹 페이지에 ActiveX 컨트롤에 대한 참조를 포함하여 설치됩니다. 이렇게 하면 로컬 컴퓨터에 없는 경우 Microsoft 인터넷 Explorer 다운로드하여 컨트롤을 설치합니다. 일반적으로 이러한 방식으로 다운로드된 ActiveX 컨트롤은 표준 사용자가 쓸 수 있는 %HOMEPATH%\Local Settings\Temporary Internet Files 디렉터리에 있습니다. 그러나 인터넷 Explorer 내에서 작동하려면 컨트롤에 여러 레지스트리 항목이 있어야 합니다. 이 항목은 관리자가 아닌 사용자에게는 불가능합니다.

해결 방법

애플리케이션에서 ActiveX 컨트롤을 제거하면 거의 항상 기능이 손실됩니다. 따라서 ActiveX 컨트롤이 사이트의 핵심 기능에 포함되지 않은 일부 시각적 또는 기능 향상을 제공하지 않는 한 수정에는 권장되지 않습니다. 예를 들어 비주식 관련 포털의 주식 시세입니다.

대부분의 경우 SMS 또는 그룹 정책 설치할 ActiveX 컨트롤을 패키징하는 것이 올바른 솔루션입니다. 그러나 대부분의 컨트롤은 기본 이미지에 포함되지 않으므로 웹 사이트는 정상적으로 실패하도록 페이지를 수정해야 합니다. 이는 누락된 ActiveX 컨트롤을 검색하고 Managed Desktop 소프트웨어 요청 페이지로 리디렉션하는 것으로 구성되어야 합니다.

ActiveX 문서가 설치되지 않음

ActiveX 문서는 Microsoft Visual Basic 4 및 Microsoft Visual Basic 5에서 사용되지 않는 기술입니다. ActiveX 컨트롤과 비슷한 방식으로 다운로드할 수 있습니다.

해결 방법

Visual Basic 4 및 Visual Basic 5는 더 이상 사용되지 않으므로 애플리케이션을 교체하는 것이 좋습니다. 클라이언트 설치의 일부로 ActiveX 문서를 설치할 수 있어야 합니다. 그러나 문서에 대한 업데이트는 SMS 또는 그룹 정책 통해 다시 배포하지 않고 제한됩니다.

애플리케이션, 프레임워크 또는 추가 기능 필요

대부분의 애플리케이션은 컴퓨터에서 이미 사용 가능하거나 다른 애플리케이션이 타사에서 사용하기 위해 배포 가능한 이진 파일을 제공하지 않기 때문에 기본적으로 설치되지 않을 수 있는 다른 소프트웨어에 종속되어 있습니다. 정상적인 상황에서 사용자는 추가 소프트웨어를 획득하고 설치하라는 지시를 받습니다. 관리되는 데스크톱에서는 설치할 수 없습니다. 예를 들어 Adobe Acrobat, Microsoft Office, Office 웹 구성 요소, WinZip 및 IT Microsoft .NET 보안 정책이 있습니다.

해결 방법

종속성이 식별되면 기본 이미지로 패키징하거나 주문형 SMS 설치를 통해 사용할 수 있습니다. 애플리케이션은 누락된 소프트웨어의 최종 사용자에게 알리고 제조업체 대신 SMS 설치 사이트로 사용자를 안내하는 방법을 변경해야 할 수 있습니다.

설치/패치에 대한 관리 권한이 필요합니다.

프로그램을 설치하려면 프로그램 파일에 파일을 추가해야 하므로 항상 관리 권한이 필요하므로 관리자 권한이 있는 사용자로 실행해야 합니다.

참고 ARP(프로그램 추가 또는 제거) 제어판과 함께 SMS 또는 그룹 정책 사용하여 패치를 "푸시"할 수도 있습니다. 사용자가 설치할 소프트웨어를 선택하고 시스템 설치 관리자가 나머지를 수행합니다. 사용자가 관리자일 필요는 없습니다. 초기 설치의 경우 설치 에이전트가 푸시아웃할 소프트웨어를 패키징하여 처리할 수 있습니다. 그러나 일부 애플리케이션은 중앙에서 관리되는 애플리케이션 모델과 잘 맞지 않을 수 있는 빈번한 자동 업데이트를 사용합니다.

업데이트를 검색하고 자체 패치를 시도하는 애플리케이션은 시스템 디렉터리에서 파일을 수정할 수 있는 권한이 없으므로 그렇게 할 수 없습니다.

해결 방법

• SMS로 배포할 애플리케이션/패치를 패키지합니다. 애플리케이션은 관리 권한 없이 업그레이드를 사용할 수 있고 프로비저닝 사이트로 리디렉션할 수 있는 한 여전히 업그레이드를 사용할 수 있음을 감지할 수 있습니다.
• 애플리케이션에 파일 시스템, 레지스트리 액세스 또는 COM 상호 운용성과 같은 상승된 컴퓨터 권한이 필요한지 여부를 질문합니다. 그렇지 않은 경우 Microsoft .NET 샌드박스에서 실행되는 ClickOnce 배포 패키지로 애플리케이션을 다시 작성할 수 있습니다.
• 클라이언트 쪽 종속성 없이 웹 애플리케이션으로 변환합니다.

애플리케이션 설정 위치 Per-User

Windows Vista의 경우 런타임에 변경해야 하는 애플리케이션 설정은 다음 위치 중 하나에 저장되어야 합니다.

• CSIDL_APPDATA
• CSIDL_LOCAL_APPDATA
• CSIDL_COMMON_APPDATA

사용자가 저장한 문서는 CSIDL_MYDOCUMENTS 저장해야 합니다.

참고 사용자의 Documents 폴더는 더 이상 문서 및 설정 아래에 저장되지 않습니다. Windows Vista에서 사용자 라는 파일 시스템의 새 루트 디렉터리에는 이제 컴퓨터 사용자에 대한 프로필이 포함됩니다.

이러한 디렉터리를 변경했으므로 개발자는 CSIDL을 사용하여 시스템 독립적 방식으로 잘 알려진 특정 디렉터리에 대한 경로를 찾는 것이 좋습니다. 자세한 내용은 CSIDL을 참조하세요.

애플리케이션은 파일 시스템에 대한 쓰기 액세스 권한이 필요합니다. 관리되는 데스크톱에서 실행하는 경우 애플리케이션은 다음 폴더 및 해당 자식에 대한 쓰기 권한만 줍니다.

• CSIDL_PROFILE
• CSIDL_COMMON_APPDATA

참고 표준 사용자는 Users\Common에 쓸 수 없습니다.

• C:\Users\Common>cd "Application Data"
  • C:\Users\Common\Application Data>echo File > File.txt
  • C:\Users\Common\Application Data>

애플리케이션은 다음과 같은 다른 위치에 쓰기를 시도해서는 안 됩니다.

• C:\windows.
• C:\Windows\System32.
• Program Files\{application}.
• C:\{application}.

참고 이 작업은 사용자가 폴더를 만든 경우 작동하며, 이 폴더는 기본적으로 사용자 그룹의 구성원이 수행할 수 있습니다.

사용자가 C:\Users\{user}에서만 폴더를 만들 수 있으므로 애플리케이션에서 C:\Users\Profiles\{user}를 특별히 만들려고 하는 것은 허용되지 않습니다. 선택한 위치는 Microsoft가 이전 버전의 운영 체제에 Documents 폴더를 저장한 위치에 따라 혼동되는 것처럼 보입니다.

런타임에 변경해야 하는 애플리케이션 설정은 다음 위치 중 하나에 저장해야 합니다.

• CSIDL_APPDATA
• CSIDL_LOCAL_APPDATA
• CSIDL_COMMON_APPDATA

사용자가 저장한 문서는 CSIDL_MYDOCUMENTS 폴더에 저장해야 합니다.

모든 경로는 하드 코딩되지 않아야 하지만 Environment.GetFolderPath() 함수를 사용해야 합니다.

애플리케이션 기본값은 보호된 디렉터리에서 저장으로 설정됩니다.

일부 애플리케이션을 사용하면 사용자가 로컬 컴퓨터로 데이터를 저장하거나 내보낼 수 있습니다. 종종 대화 상자는 표준 사용자에게 쓰기 권한이 없는 C:\와 같은 위치로 기본 설정됩니다. 또한 일부 애플리케이션은 운영 체제에서 액세스가 거부되어 파일을 작성하는 코드가 실패할 때 잘 응답하지 않습니다.

해결 방법

사용자가 자신의 프로필에만 쓸 수 있다고 가정합니다. 사용자가 의도적으로 저장한 문서의 경우 문서 (Environment.GetFolderPath(Environment.SpecialFolder.Personal)에서 시작하도록 대화 상자를 초기화합니다. 저장 대화 상자를 사용하면 사용자가 사용자의 프로필이 아닌 다른 위치를 찾아볼 수 있으므로 애플리케이션에는 사용자가 프로필에 있는 디렉터리와 다른 디렉터리를 선택하는 경우 정상적으로 실패하도록 하는 논리가 포함되어야 합니다.

참조

이 섹션에는 가상화 참조 및 보안 설정 참조가 포함되어 있습니다.

가상화 참조

파일 가상화

• 가상화(%SYSTEMROOT%, %PROGRAMDATA%, %PROGRAMFILES%\(하위 디렉터리)
• 리디렉션: %LOCALAPPDATA%\VirtualStore
• 제외된 이진 실행 파일: .exe, .dll, .sys

레지스트리 가상화:

• Virtualize(HKLM\SOFTWARE)
• 리디렉션: HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE\<Application Registry 키>
• 가상화에서 제외된 키
• HKLM\Software\Classes
• HKLM\Software\Microsoft\Windows
• HKLM\Software\Microsoft\Windows NT

적용 대상

• 가상 저장소가 로밍되지 않음
• 해당 전역 개체는 로밍되지 않습니다.
• 대화형 표준 사용자에 대해서만 사용
• 비대화형 프로세스에 사용할 수 없음
• 64비트 실행 파일에 대해 사용하지 않도록 설정
• 애플리케이션 매니페스트에서 실행 수준(requestedExecutionLevel)을 요청하는 실행 파일( 분리 모델)에 대해 사용하지 않도록 설정됨
• 커널 모드 및 가장된 호출자에 대해 사용하지 않도록 설정
• 관리자 쓰기 가능한 레지스트리 키 및 파일만 가상화됩니다.

UAC 보안 설정 참조

이 참조는 그룹 정책 또는 컴퓨터의 로컬 보안 정책을 사용하여 UAC를 관리하는 데 사용할 수 있는 보안 설정을 자세히 설명합니다.

참고 이 섹션에 제시된 절차는 관리되지 않는 컴퓨터를 관리하기 위한 것입니다. 그룹 정책 사용하여 관리되는 환경에서 중앙에서 설정을 관리하려면 로컬 보안 정책 관리자 스냅인(secpol.msc) 대신 Active Directory 사용자 및 컴퓨터(dsa.msc)를 사용합니다.

UAC 보안 설정 구성

다음 절차에서는 보안 정책 관리자를 사용하여 UAC 보안 설정을 구성하는 방법을 자세히 설명합니다. 이 절차는 관리 승인 모드에서 관리자의 기본 사용자 환경을 자세히 설명합니다.

보안 정책 관리자를 사용하여 UAC 보안 설정을 보거나 설정하려면

1. 시작 단추를 클릭하고 검색 상자에 secpol.msc를 입력한 다음 Enter 키를 누릅니다.
2. 사용자 계정 컨트롤 동의 프롬프트에서 계속을 클릭합니다.
3. 로컬 보안 설정에서 로컬 정책을 확장한 다음 보안 옵션을 클릭합니다.
4. 변경할 보안 설정을 마우스 오른쪽 단추로 클릭하고 속성을 선택합니다.

다음 절차에서는 그룹 정책 사용하여 UAC 보안 설정을 구성하는 방법을 자세히 설명합니다. 이 절차는 관리 승인 모드에서 관리자의 기본 사용자 환경을 자세히 설명합니다.

그룹 정책 개체 편집기를 사용하여 UAC 보안 설정을 보거나 설정하려면

1. 시작 단추를 클릭하고 검색 상자에 gpedit.msc를 입력한 다음 Enter 키를 누릅니다.
2. 사용자 계정 컨트롤 동의 프롬프트에서 계속을 클릭합니다.
3. 그룹 정책 사용자 구성을 확장한 다음 보안 옵션을 확장합니다.
4. 변경할 보안 설정을 마우스 오른쪽 단추로 클릭하고 속성을 선택합니다.

UAC 보안 설정

다음 표에서는 구성 가능한 UAC 보안 설정을 나열합니다. 이러한 설정은 보안 정책 관리자(secpol.msc)를 사용하여 구성하거나 그룹 정책(gpedit.msc)을 사용하여 중앙에서 관리할 수 있습니다.

UAC 보안 설정

설정	Description	기본값
사용자 계정 컨트롤: 기본 제공 관리자 계정에 대한 승인 모드를 관리.	두 가지 가능한 설정이 있습니다. 사용: 기본 제공 관리자는 관리 승인 모드에서 관리자로 실행됩니다. 사용 안 함: 관리자가 전체 관리자 액세스 토큰으로 실행됩니다.	컴퓨터에서 기본 제공 관리자가 유일한 로컬 활성 관리자가 아닌 새 설치 및 업그레이드의 경우 사용할 수 없습니다. 기본 제공 관리자 계정은 도메인에 가입된 컴퓨터의 설치 및 업그레이드에 대해 기본적으로 사용하지 않도록 설정됩니다. Windows Vista에서 기본 제공 관리자 계정이 컴퓨터의 유일한 활성 로컬 관리자임을 확인할 때 업그레이드를 사용하도록 설정합니다. Windows Vista에서 이를 확인하면 업그레이드 후 기본 제공 관리자 계정도 계속 사용하도록 설정됩니다. 기본 제공 관리자 계정은 도메인에 가입된 컴퓨터의 설치 및 업그레이드에 대해 기본적으로 사용하지 않도록 설정됩니다.
사용자 계정 컨트롤: 관리자 승인 모드에서 관리자에 대한 권한 상승 확인 방법	이 설정에는 다음 세 가지 가능한 값이 있습니다. 메시지를 표시하지 않고 상승: 자동으로 상승합니다. 자격 증명 확인: 계속하기 전에 사용자가 로그인 암호를 입력하도록 요구합니다. 동의 요청: 관리자 권한 상승 전에 사용자에게 승인을 요청합니다. 이 값은 기본 설정입니다.  이 설정은 더 높은 권한이 있는 프로그램을 실행하기 전에 사용자에게 메시지가 표시되는 방법을 결정합니다. 이 정책은 UAC를 사용하는 경우에만 적용됩니다.	동의 확인
사용자 계정 컨트롤: 표준 사용자에 대한 권한 상승 확인 방법	더 높은 권한이 있는 프로그램을 실행하기 전에 사용자에게 메시지가 표시되는 방법을 결정합니다. 이 정책은 UAC를 사용하는 경우에만 적용됩니다. 이 설정에 사용할 수 있는 구성 옵션은 다음과 같습니다. 권한 상승 요청 자동 거부: 애플리케이션이 관리 작업을 수행하려고 할 때 사용자에게 메시지가 표시되지 않습니다. 애플리케이션이 시작되지 않으며 사용자에게 액세스 거부 또는 이에 상응하는 오류가 표시됩니다. 자격 증명 확인: 계속하기 전에 사용자가 로그인 암호를 입력하도록 요구합니다.	자격 증명 확인
사용자 계정 컨트롤: 애플리케이션을 설치할 때 권한 상승 확인	가능한 값이 두 가지가 있습니다. 사용: Windows Vista에서 설치 관리자를 검색하면 사용자에게 동의 또는 자격 증명을 묻는 메시지가 표시됩니다. 사용 안 함: 애플리케이션 설치는 비결정적인 방식으로 자동으로 실패하거나 실패합니다.	사용
사용자 계정 컨트롤: 유효성 검사를 통과한 서명된 실행 파일만 권한 상승	가능한 값이 두 가지가 있습니다. 사용: 서명된 실행 파일만 실행됩니다. 이 설정은 서명되지 않은 애플리케이션이 실행되지 않도록 차단합니다. 사용 안 함: 서명된 코드와 서명되지 않은 코드가 모두 실행됩니다.	사용 안 함
사용자 계정 컨트롤: 보안 위치에 설치된 UIAccess 애플리케이션만 권한 상승	가능한 값이 두 가지가 있습니다. 사용: 시스템은 %ProgramFiles% 또는 %windir%에서 시작된 실행 파일에 대해서만 UIAccess 권한 및 사용자 권한을 부여합니다. 이러한 디렉터리에서 ACL을 사용하면 실행 파일이 사용자 수정이 불가능합니다(그렇지 않으면 권한 상승을 허용). 다른 위치에서 시작된 UIAccess 실행 파일은 추가 권한 없이 시작됩니다(즉, "asInvoker"를 실행). 사용 안 함: 위치 검사가 수행되지 않으므로 모든 UIAccess 애플리케이션은 사용자 승인 시 사용자의 모든 액세스 토큰으로 시작됩니다.	사용
사용자 계정 컨트롤: 관리 승인 모드에서 모든 관리자 실행	가능한 값이 두 가지가 있습니다. 사용: 관리자와 표준 사용자 모두 관리 작업을 수행하려고 할 때 메시지가 표시됩니다. 프롬프트 스타일은 정책에 따라 달라집니다. 사용 안 함: UAC는 기본적으로 "꺼짐"이며 AIS 서비스가 자동으로 시작되지 않도록 설정됩니다.	사용
사용자 계정 컨트롤: 권한 상승 요청 시 보안 데스크톱으로 전환	가능한 값이 두 가지가 있습니다. 사용: 보안 데스크톱에 UAC 권한 상승 프롬프트를 표시합니다. 보안 데스크톱은 Windows 프로세스에서만 메시지를 받을 수 있으므로 악성 소프트웨어의 메시지가 제거됩니다. 따라서 동의 및 자격 증명 프롬프트는 보안 데스크톱에서 스푸핑할 수 없습니다. 사용 안 함: UAC 권한 상승 프롬프트가 사용자 데스크톱에 표시됩니다.	사용
사용자 계정 컨트롤: 사용자별 위치로 파일 및 레지스트리 쓰기 오류를 가상화	가능한 값이 두 가지가 있습니다. 사용: 애플리케이션 매니페스트에서 애플리케이션 호환성 데이터베이스 항목 또는 요청된 실행 수준 표시가 없는 애플리케이션은 UAC 규격이 아닙니다. 비준수 소프트웨어를 활용하는 환경은 이 설정을 계속 사용하도록 설정해야 합니다. 사용 안 함: UAC 규격 애플리케이션은 보호된 영역에 쓰면 안 되며 쓰기 오류가 발생합니다. 따라서 UAC 규격 애플리케이션만 활용하는 환경에서는 이 설정을 사용하지 않도록 설정해야 합니다. 이 설정을 사용하지 않도록 설정하면 프로그램 파일 및 %systemroot%에 쓰려고 시도하는 비준수 애플리케이션이 자동으로 실패합니다.	사용

참고 대부분의 경우 프롬프트 없이 권한 상승 옵션은 권장되지 않습니다. 메시지를 표시하지 않고 상승하면 표준 사용자로 실행되는 애플리케이션이 사용자 동의 없이 관리 애플리케이션을 시작하고 UAC를 효과적으로 우회할 수 있습니다.

작업 스케줄러 코드 샘플

다음 C++ 코드 샘플에서는 작업 스케줄러를 사용하여 사용자에 대한 권한 상승을 수행하는 방법을 보여 줍니다. 따라서 애플리케이션은 관리자의 자격 증명을 사용하여 로그온하는 동안 자동으로 상승될 수 있으며 Windows Vista는 애플리케이션을 차단하지 않습니다. 이 솔루션이 제대로 작동하려면 설치하는 동안 애플리케이션에 대한 관리자 사용자를 만들어야 합니다.

//---------------------------------------------------------------------
//  This file is part of the Microsoft .NET Framework SDK Code Samples.
// 
//  Copyright (C) Microsoft Corporation.  All rights reserved.
// 
//This source code is intended only as a supplement to Microsoft
//Development Tools and/or on-line documentation.  See these other
//materials for detailed information regarding Microsoft code samples.
// 
//THIS CODE AND INFORMATION ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY
//KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
//IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A
//PARTICULAR PURPOSE.
//---------------------------------------------------------------------

/****************************************************************************
* Main.cpp - Sample application for Task Scheduler V2 COMAPI                * Component: Task Scheduler                          
* Copyright (c) 2002 - 2003, Microsoft Corporation 
* This sample creates a task to at the time registered to start the desired task.                                                             *
****************************************************************************/
#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <comdef.h>
#include <comutil.h>
//Include Task header files - Included in Windows Vista Beta-2 SDK from MSDN
#include <taskschd.h>
#include <conio.h>
#include <iostream>
#include <time.h>

using namespace std;

#define CLEANUP \
pRootFolder->Release();\
        pTask->Release();\
        CoUninitialize();

HRESULT CreateMyTask(LPCWSTR, wstring);

void __cdecl wmain(int argc, wchar_t** argv)
{
wstring wstrExecutablePath;
WCHAR taskName[20];
HRESULT result;

if( argc < 2 )
{
printf("\nUsage: LaunchApp yourapp.exe" );
return;
}

// Pick random number for task name
srand((unsigned int) time(NULL));
wsprintf((LPWSTR)taskName, L"Launch %d", rand());

wstrExecutablePath = argv[1];

result = CreateMyTask(taskName, wstrExecutablePath);
printf("\nReturn status:%d\n", result);

}
HRESULT CreateMyTask(LPCWSTR wszTaskName, wstring wstrExecutablePath)
{
    //  ------------------------------------------------------
    //  Initialize COM.
TASK_STATE taskState;
int i;
    HRESULT hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);
    if( FAILED(hr) )
    {
        printf("\nCoInitializeEx failed: %x", hr );
        return 1;
    }

    //  Set general COM security levels.
    hr = CoInitializeSecurity(
        NULL,
        -1,
        NULL,
        NULL,
        RPC_C_AUTHN_LEVEL_PKT_PRIVACY,
        RPC_C_IMP_LEVEL_IMPERSONATE,
        NULL,
        0,
        NULL);

    if( FAILED(hr) )
    {
        printf("\nCoInitializeSecurity failed: %x", hr );
        CoUninitialize();
        return 1;
    }

    //  ------------------------------------------------------
    //  Create an instance of the Task Service. 
    ITaskService *pService = NULL;
    hr = CreateElevatedComObject( CLSID_TaskScheduler,
                           NULL,
                           CLSCTX_INPROC_SERVER,
                           IID_ITaskService,
                           (void**)&pService );  
    if (FAILED(hr))
    {
        printf("Failed to CoCreate an instance of the TaskService class: %x", hr);
        CoUninitialize();
        return 1;
    }
        
    //  Connect to the task service.
    hr = pService->Connect(_variant_t(), _variant_t(), _variant_t(), _variant_t());
    if( FAILED(hr) )
    {
        printf("ITaskService::Connect failed: %x", hr );
        pService->Release();
        CoUninitialize();
        return 1;
    }

    //  ------------------------------------------------------
    //  Get the pointer to the root task folder.  This folder will hold the
    //  new task that is registered.
    ITaskFolder *pRootFolder = NULL;
    hr = pService->GetFolder( _bstr_t( L"\\") , &pRootFolder );
    if( FAILED(hr) )
    {
        printf("Cannot get Root Folder pointer: %x", hr );
        pService->Release();
        CoUninitialize();
        return 1;
    }
    
    //  Check if the same task already exists. If the same task exists, remove it.
    hr = pRootFolder->DeleteTask( _bstr_t( wszTaskName), 0  );
    
    //  Create the task builder object to create the task.
    ITaskDefinition *pTask = NULL;
    hr = pService->NewTask( 0, &pTask );

    pService->Release();  // COM clean up.  Pointer is no longer used.
    if (FAILED(hr))
    {
        printf("Failed to CoCreate an instance of the TaskService class: %x", hr);
        pRootFolder->Release();
        CoUninitialize();
        return 1;
    }
        

    //  ------------------------------------------------------
    //  Get the trigger collection to insert the registration trigger.
    ITriggerCollection *pTriggerCollection = NULL;
    hr = pTask->get_Triggers( &pTriggerCollection );
    if( FAILED(hr) )
    {
        printf("\nCannot get trigger collection: %x", hr );
CLEANUP
        return 1;
    }
  
    //  Add the registration trigger to the task.
    ITrigger *pTrigger = NULL;
    
    hr = pTriggerCollection->Create( TASK_TRIGGER_REGISTRATION, &pTrigger );     
    pTriggerCollection->Release();  // COM clean up.  Pointer is no longer used.
    if( FAILED(hr) )
    {
        printf("\nCannot add registration trigger to the Task %x", hr );
        CLEANUP
        return 1;
    }
    pTrigger->Release();

    //  ------------------------------------------------------
    //  Add an Action to the task.     
    IExecAction *pExecAction = NULL;
    IActionCollection *pActionCollection = NULL;

    //  Get the task action collection pointer.
    hr = pTask->get_Actions( &pActionCollection );
    if( FAILED(hr) )
    {
        printf("\nCannot get Task collection pointer: %x", hr );
        CLEANUP
        return 1;
    }
    
    //  Create the action, specifying that it is an executable action.
    IAction *pAction = NULL;
    hr = pActionCollection->Create( TASK_ACTION_EXEC, &pAction );
    pActionCollection->Release();  // COM clean up.  Pointer is no longer used.
    if( FAILED(hr) )
    {
        printf("\npActionCollection->Create failed: %x", hr );
        CLEANUP
        return 1;
    }

    hr = pAction->QueryInterface( IID_IExecAction, (void**) &pExecAction );
    pAction->Release();
    if( FAILED(hr) )
    {
        printf("\npAction->QueryInterface failed: %x", hr );
        CLEANUP
        return 1;
    }

    //  Set the path of the executable to the user supplied executable.
hr = pExecAction->put_Path( _bstr_t( wstrExecutablePath.c_str() ) );  

//hr = pExecAction->put_Path( (BSTR)wstrExecutablePath );  
    if( FAILED(hr) )
    {
        printf("\nCannot set path of executable: %x", hr );
        pExecAction->Release();
        CLEANUP
        return 1;
    }
    hr = pExecAction->put_Arguments( _bstr_t( L"" ) );  
//    hr = pExecAction->put_Arguments( _bstr_t( L"ArgumentsToYourExecutable--HelpFileToOpen" ) );  
   if( FAILED(hr) )
    {
        printf("\nCannot set arguments of executable: %x", hr );
        pExecAction->Release();
        CLEANUP
        return 1;
    }
    
    //  ------------------------------------------------------
    //  Save the task in the root folder.
    IRegisteredTask *pRegisteredTask = NULL;
    hr = pRootFolder->RegisterTaskDefinition(
            _bstr_t( wszTaskName ),
            pTask,
        TASK_CREATE, 
_variant_t(_bstr_t( L"S-1-5-32-545")),//Well Known SID for \\Builtin\Users group
_variant_t(), 
TASK_LOGON_GROUP,
            _variant_t(L""),
            &pRegisteredTask);
    if( FAILED(hr) )
    {
        printf("\nError saving the Task : %x", hr );
        CLEANUP
        return 1;
    }
    printf("\n Success! Task successfully registered. " );
for (i=0; i<100; i++)//give 10 seconds for the task to start
{
pRegisteredTask->get_State(&taskState);
if (taskState == TASK_STATE_RUNNING)
{
printf("\nTask is running\n");
break;
}
Sleep(100);
}
if (i>= 100) printf("Task didn't start\n");

//Delete the task when done
    hr = pRootFolder->DeleteTask(
            _bstr_t( wszTaskName ),
            NULL);
    if( FAILED(hr) )
    {
        printf("\nError deleting the Task : %x", hr );
        CLEANUP
        return 1;
    }

    printf("\n Success! Task successfully deleted. " );

//  Clean up.
    CLEANUP
    CoUninitialize();
    return 0;
}