응용 프로그램에서 Windows Vista 사용자 계정 컨트롤 사용

   

이 기사에서 다루는 내용:

사용자 계정 컨트롤 표준 사용자로 실행하도록 응용 프로그램 설계 필요한 경우 권한 상승

이 기사에서 사용하는 기술: Windows Vista

목차

로그온 시 활성화

필터링된 토큰 생성

필터링된 토큰으로 실행하도록 응용 프로그램 설계

관리자 권한이 필요한 응용 프로그램 설계

설치 시 권한

MSI에 대한 권한 표시

관리자 권한으로 응용 프로그램 실행

응용 프로그램 매니페스트를 사용하여 필수 권한 표시

COM 개체 표시

사용자에게 상승된 권한 알림

서로 다른 보안 컨텍스트에서 프로세스 간 통신

낮은 권한의 Internet Explorer

Windows Vista에서 Windows 서비스 보안

일반적인 응용 프로그램 호환성 문제

설치 시 문제

일반적인 런타임 응용 프로그램 문제

결론

필자는 지난 몇 년 간 많은 개발자와 함께 일하면서 그들이 사용자 계정 컨트롤(UAC)의 작동 원리를 이해하기 위해 골머리를 앓는 것을 보았습니다. 원리를 이해하는 것이 어려운 것은 사실입니다. 표준 사용자를 위한 훌륭한 응용 프로그램을 작성하는 방법을 배우려면 시간이 걸리겠지만 이러한 지식은 더 나은 Windows® 프로그래머가 되기 위한 밑거름이 될 것입니다. 이 기사의 목적은 이러한 과정을 빠르고 쉽게 진행하는 데 필요한 정보를 제공하는 것입니다.

UAC는 사용자가 Windows Vista™에서 실행하는 기본 권한을 줄이기 위한 Microsoft의 전략입니다. 전략적으로 Microsoft는 일상적인 업무를 수행하기 위해 사용자가 운영 체제와 시스템 차원의 구성에 영향을 줄 수 있는 권한을 갖거나 이러한 권한이 필요하지 않은 환경으로 이동하고 있습니다. 또한 이러한 환경은 다른 사용자의 상태와 설정에 영향을 주지 않도록 합니다.

이러한 이동에는 다양한 실질적인 이유가 있습니다. UAC는 응용 프로그램이 기본적으로 실행하는 권한을 제한합니다. 기업에서는 사용자가 Administrators가 아닌 Users 그룹에서 실행하여 의미 있는 회사 보안 정책을 적용할 수 있도록 합니다. 그 결과 시스템에 대한 사용자의 영향이 줄어들고 총 소유 비용(TCO)이 절감됩니다. 가정에서는 사용자가 UAC 승인 또는 자격 증명 프롬프트를 거치지 않으면 맬웨어가 시스템에 영향을 주거나 서비스나 드라이버를 설치할 수 없습니다. 사회 공학의 위험이 여전히 존재하지만 상승된 권한을 획득하기 위한 경로의 통합으로 미래의 기술 구현에서는 사용자에게 허용 여부를 묻지 않고도 시스템 차원의 권한으로 실행할 수 있는 응용 프로그램을 제어할 수 있습니다.

UAC의 주요 목표는 Users 그룹의 멤버인 것처럼 가장하여 응용 프로그램을 실행하는 기본 사용자 토큰을 만드는 것입니다. 이 과정은 상승된 권한을 가진 사용자에 대한 대화식 로그온 동안 제한되거나 필터링된 토큰을 생성하는 것으로 시작됩니다. 제한된 작업을 실행하기 위해 더 많은 권한이 필요한 경우 보안 데스크톱에서 사용자에게 인증을 요구하는 프롬프트를 표시합니다. 또한 UAC에는 응용 프로그램 호환성을 지원하고 상승된 프로세스를 보호하기 위한 다른 기술이 포함되어 있습니다.

로그온 시 활성화

UAC는 사용자가 시스템에 로그온하면 작동을 시작합니다. 대화식 로그온 동안 LSA(Local Security Authority)가 사용자의 자격 증명을 가져와서 초기 로그온을 시작하고 사용자의 토큰을 평가하여 상승된 권한으로 정의된 항목이 있는지 확인합니다. LSA는 사용자가 상승된 권한을 가지고 있다고 판단하면 이 토큰을 필터링한 다음 필터링된 토큰으로 두 번째 로그온을 수행합니다. 사용자가 필터링된 토큰과 전체 권한 토큰을 모두 갖게 되는 가장 일반적인 경우는 사용자가 Administrators 그룹의 멤버인 경우입니다. 관리자의 전체 권한 토큰은 프로그램 파일 및 HKEY_LOCAL_MACHINE(HKLM)과 같은 시스템 차원의 위치에 기록할 수 있으므로 전체 시스템에 적용됩니다. 그러나 필터링된 토큰은 Users 그룹의 멤버와 유사하며 이러한 권한을 갖지 않고 사용자의 대화식 데스크톱 세션을 생성하는 데 사용됩니다.

데스크톱 세션과 explorer.exe는 항상 Users 그룹 멤버의 토큰과 비슷한 토큰으로 생성됩니다. 시작 메뉴를 사용하거나 탐색기 창에서 두 번 클릭하여 시작되는 프로세스는 상승이 필요하지 않은 경우 단순히 이 필터링된 토큰을 상속합니다. 따라서 기본적으로 모든 응용 프로그램이 표준 사용자 토큰으로 실행됩니다. 프로세스가 매니페스트 또는 응용 프로그램 호환성 설정에서 관리자 권한이 필요한 것으로 표시되면 UAC는 사용자 상승을 위한 프롬프트를 표시합니다. 그림 1 및 2는 승인 및 자격 증명을 입력하는 프롬프트를 보여 줍니다. 사용자가 인증되면 Application Information 서비스가 전체 권한 토큰으로 프로세스를 생성합니다.

그림 1 승인 입력 프롬프트 (더 크게 보려면 이미지를 클릭하십시오.)

그림 2 자격 증명 입력 프롬프트 (더 크게 보려면 이미지를 클릭하십시오.)

필터링된 토큰 생성

사용자 계정 컨트롤은 그림 3에 나열된 그룹을 상승된 권한을 가진 것으로 정의합니다. 따라서 LSA가 해당 그룹 멤버나 권한이 사용자의 초기 토큰에 나열된 것을 확인하면 대화식 로그온 동안 CreateRestrictedToken API 버전을 사용하여 필터링된 토큰을 생성하고 전체 권한 토큰을 저장합니다. 이 두 개의 토큰은 서로 연결되어 있으므로 새 TokenLinkedToken 정보 유형이 있는 GetTokenInformation API를 사용하여 필터링된 토큰에서 전체 권한 토큰을 획득할 수 있습니다. 그러나 UAC는 서비스, 네트워크 또는 일괄 처리 로그온에 영향을 주지 않습니다.

사용자가 그림 3에 나열된 그룹에 속하지 않지만 특정 권한을 가진 경우 이러한 권한이 제거된 필터링된 토큰이 생성됩니다. 이러한 권한에는 다음 항목이 포함됩니다. SeCreateTokenPrivilege, SeTcbPrivilege, SeTakeOwnershipPrivilege, SeBackupPrivilege, SeRestorePrivilege, SeDebugPrivilege, SeImpersonatePrivilege, SeRelabelPrivilege.

사용자가 Administrators 그룹의 멤버인 경우 필터링된 토큰은 DENY ONLY로 설정된 Administrators 그룹 멤버 자격을 갖게 되고 AccessCheck가 이 그룹을 사용하여 리소스에 액세스하는 것이 금지됩니다. 또한 시스템에 영향을 주는 모든 권한이 토큰에서 제거됩니다(이것은 explorer.exe와 상승되지 않은 프로세스를 생성하는 데 사용되는 기본 토큰입니다.). Windows Vista에 포함된 whoami.exe를 사용하여 이 토큰을 볼 수 있습니다. 명령 창에서 whoami.exe /all을 실행하면 됩니다. 그림 4 및 그림 5는 각각 토큰에 나열된 그룹 멤버와 토큰의 권한을 나타냅니다.

필터링된 토큰으로 실행하도록 응용 프로그램 설계

대부분의 응용 프로그램은 런타임에 관리자 권한이 필요하지 않습니다. 응용 프로그램이 실행 중에 교차 세션(cross-session) 상태를 유지하지 않고 로컬 보안 정책을 수정하는 등의 작업을 수행하지 않으면 표준 사용자 토큰으로 잘 실행되고 있는 것입니다. 가끔 응용 프로그램의 특정 부분에서 관리자 권한이 필요한 경우 이러한 부분을 별도의 프로세스로 분리해야 합니다. 여기에 대해서는 나중에 다시 설명하겠습니다.

표준 사용자 응용 프로그램 개발 시 필요한 가장 중요한 단계는 표준 사용자로 실행하면서 테스트하는 것입니다. 응용 프로그램 상용화에 실패하는 가장 일반적인 이유 중 하나는 개발자가 표준 사용자로 테스트하는 과정을 거치지 않기 때문입니다. 반드시 테스트 단계를 거치십시오.

다음으로 가장 중요한 단계는 응용 프로그램 바이너리와 사용자별 구성 데이터를 저장할 장소를 결정하는 것입니다. 사용자별, 즉 바이너리와 구성이 해당 사용자에 고유한 응용 프로그램은 사용자 프로파일 %userprofile%에서 모든 상태를 유지해야 합니다. 레지스트리에서 사용자의 영역인 HKEY_CURRENT_USER(HKCU)에 모든 상태를 기록해야 합니다. 많은 경우에 %ProgramFiles% 디렉터리에 바이너리를 설치하는 것이 합리적이지만 이 경우에는 관리자 권한이 필요하며 이 기사에서 나중에 설명됩니다.

게임에서 최고 득점을 저장할 경우와 같이 시스템 차원의 상태를 유지하고 사용자가 여기에 기록해야 하는 경우가 있습니다. 이 데이터를 저장하기에 알맞은 장소는 %allusersprofile% 디렉터리입니다. 여기에서 응용 프로그램의 고유 디렉터리를 생성하고 사용자가 이 디렉터리에 기록하도록 할 수 있습니다. 다른 사용자는 이 파일을 건드릴 수 없습니다.

관리자 권한이 필요한 응용 프로그램 설계

다음은 관리자 권한이 필요한 응용 프로그램 작성과 관련된 필자의 진심 어린 충고입니다. 이 권한을 사용하지 마십시오! 응용 프로그램에서 상승된 권한이 필요하다는 절대적인 확신이 없다면 표준 사용자 토큰을 사용하도록 응용 프로그램을 작성하십시오. 관리자 권한으로 호출해야 하는 API는 매우 적습니다.

물론 설치 또는 교차 세션 상태 유지 등 일반적으로 응용 프로그램이 서비스로 구현된 경우 관리자 권한을 사용해야 하는 경우가 있습니다. UAC는 서비스에 적용되지 않습니다. 나중에 설명하겠지만 Windows 서비스에 사용할 수 있는 다른 보안 설정이 있습니다. 응용 프로그램이 로컬 시스템에서 보안 모델을 구현하는 경우에도 관리자 권한이 필요합니다. 예를 들어 Group Policy ADM(Application Distribution and Management)을 사용하거나 SMS(Systems Management Server)를 통해 배포된 설정이 있는 경우 대개 이 설정을 업데이트하기 위해 로컬 시스템에 응용 프로그램을 배치합니다. 이 경우 관리자 권한이 필요합니다.

설치 시 권한

대개 응용 프로그램 바이너리는 표준 사용자에 대해 읽기 전용인 Program Files 디렉터리에 기록되기 때문에 일반적으로 응용 프로그램 설치 시 관리자 권한이 필요합니다. 즉, 이 위치에 바이너리를 기록하는 응용 프로그램은 관리자 권한이 필요한 것으로 표시되어야 합니다. Windows Installer가 UAC와 통합되었기 때문에 설치 패키지(MSI 파일)가 더욱 매력적인 설치 방법으로 부각되고 있습니다. 이는 사용자별 설치 또는 시스템별 설치의 두 가지 방법으로 지정할 수 있으며 필요한 경우에만 사용자에게 관리자 권한을 입력하라는 프롬프트를 표시합니다.

Program Files 디렉터리에 설치하는 동안 상승 프롬프트가 표시되지만 여기에 응용 프로그램의 바이너리를 넣으면 확실한 이점이 있습니다. 이 디렉터리에 설치하려면 관리자 권한이 필요하므로 기업의 표준 사용자나 등급 제한 사용자가 임의로 응용 프로그램을 설치할 수 없습니다. 또한 응용 프로그램이 시스템에서 한 바이너리 집합을 공유하고 표준 사용자가 건드릴 수 없도록 보호됩니다. 따라서 버그를 수정하거나 기능을 추가한 후에 바이너리를 업데이트할 때 응용 프로그램의 상태와 버전을 더 쉽게 파악할 수 있습니다.

응용 프로그램을 설계할 때 일부 응용 프로그램 설정을 사용자에게 적용해야 하는 경우가 있습니다. 사용자가 뷰를 어떤 방법으로 표시할지 또는 어떤 메뉴를 표시할지 등 사용자 지정 정보를 지정할 수 있습니다. 이러한 기능을 제공하는 좋은 방법은 Program Files 디렉터리 아래 기본 템플릿을 생성한 다음 사용자의 AppData 디렉터리 %localappdata%에 복사하고 수정하는 것입니다. 응용 프로그램을 처음 실행할 때 이 데이터를 복사하고 각 사용자의 사용자별 상태를 설정할 수 있습니다. 반대로 이전의 최고 득점 사례에서처럼 개별 사용자가 수정할 수 있는 시스템 차원의 상태를 원한다면 이 데이터를 %allusersprofile%에 배치할 수 있습니다.

UAC 환경에서 설치 시 또 하나의 문제는 업데이트입니다. Program Files 디렉터리에서 바이너리 파일을 업데이트하려면 바이너리를 덮어쓰는 프로세스가 관리자 또는 시스템 권한을 가져야 합니다. Windows Installer를 사용할 경우 한 가지 장점은 MSI 패치(MSP) 파일을 사용하여 패치할 수 있다는 것입니다. Windows Installer 3.1은 Windows XP용 필수 업데이트이기 때문에 원본 MSI 파일에 포함된 인증서로 서명된 경우 MSP 파일이 시스템에 적용됩니다. 자세한 내용은 MSDN®의 User Account Control Patching(windowssdk.msdn.microsoft.com/ms710366.aspx) 문서를 참조하십시오.

응용 프로그램 개발자는 MSI 파일을 사용하는 대신 기업에서 표준 사용자가 업데이트하지 못하고 관리자 권한으로 실행하도록 지정된 바이너리 파일을 통합하거나 필요한 업데이트를 실행하는 서비스를 포함시킬 수 있습니다. 서비스의 보안 취약성으로 인해 ISV를 맬웨어의 공격 대상이 될 수도 있으므로 서비스를 포함시키지 않는 것이 좋습니다. 최선의 방법은 MSP 파일을 사용하는 것입니다.

MSI에 대한 권한 표시

Windows Vista 이전에는 ALLUSERS 속성을 사용하여 MSI 파일이 사용자 위치나 시스템의 모든 사용자에 대해 응용 프로그램의 바로 가기를 설치할지 여부를 표시했습니다. 이러한 바로 가기에는 DesktopFolder, ProgramMenuFolder, StartMenuFolder 및 StartupFolder가 포함되었습니다. 유사한 사용자별 Program Files 디렉터리가 없었기 때문에 일반적으로 응용 프로그램 바이너리가 계속 Program Files 디렉터리에 기록되었습니다.

그러나 응용 프로그램 호환성 문제로 Windows Installer는 사용자에게 ALLUSERS 속성만을 기준으로 자격 증명을 입력하라는 프롬프트를 표시할지 여부를 판별할 수 없었습니다. 대신 MSI 파일에 사용자에게 프롬프트를 표시할지 여부를 판별하는 추가 비트가 할당되었습니다. Word Count Summary 속성에서 비트 3이 추가 비트입니다. 이 비트가 1로 설정되면 패키지를 사용자별 MSI로 간주하고 사용자에게 Administrator 토큰을 입력하라는 프롬프트를 표시하지 않습니다.

Public 프로파일에 관리자만 패키지를 설치할 수 있도록 지정하려면 ALLUSERS="1" 또는 ALLUSERS="2"로 설정하고 Word Count Summary 속성의 비트 3을 0으로 설정합니다. 패키지를 표준 사용자가 설치할 수 있는 사용자별 설치로 지정하려면 ALLUSERS=""으로 설정하거나 속성을 정의하지 않고 Word Count Summary 속성의 비트 3을 1로 설정합니다.

관리자 권한으로 응용 프로그램 실행

응용 프로그램에 대해 관리자 권한이 필요한 경우가 있습니다. HKLM에 시스템 차원의 설정값으로 설정된 일부 하드웨어나 응용 프로그램과 직접 통신하는 코드를 작성할 수 있습니다. 가능하면 관리자 권한을 코드의 일부 섹션으로만 제한하거나 전체 관리자 권한으로 시작된 응용 프로그램과 통신하도록 응용 프로그램을 설계해야 합니다.

MSI 기반 상승과는 별도로 사용자의 전체 관리자 토큰을 사용하여 프로세스를 생성하는 두 가지 방법이 있습니다. AIS(Application Information Service)는 프로세스 및 COM 개체 생성 시 CoCreateAsAdmin 모니커를 사용하여 바이너리가 관리자 권한을 요구하는지 확인합니다. 중요한 점은 프로세스 생성 시 상승이 발생한다는 것입니다. 프로세스 토큰은 런타임 시 프로세스가 생성될 때만 추가된 권한이나 그룹 멤버 자격을 갖지 않습니다.

주의 사항: UAC 상승 프롬프트는 프로세스를 생성하기 위해 ShellExecute가 호출될 때만 사용자에게 표시됩니다. 상승을 요구하는 CreateProcess 패밀리 호출에 의해 ERROR_ELEVATION_REQUIRED가 반환됩니다.

응용 프로그램 매니페스트를 사용하여 필수 권한 표시

새 프로세스가 생성될 때 AIS는 바이너리를 조사하여 상승이 필요한지 여부를 판별합니다. 첫 번째로 조사하는 항목은 응용 프로그램의 리소스에 포함된 응용 프로그램 매니페스트입니다. 이 항목은 응용 프로그램 호환성 표시 또는 UAC의 설치 프로그램 탐지(나중에 설명됨)를 포함한 다른 유형의 응용 프로그램 표시보다 우선 적용됩니다. 매니페스트는 Windows에게 바이너리 실행에 필요한 권한을 알려주는 실행 수준을 정의합니다. 실행 수준에는 세 가지(asInvoker, highestAvailable, requireAdministrator)가 있습니다.

AIS가 "asInvoker" 실행 수준으로 표시된 바이너리를 발견하면 어떠한 조치도 취하지 않고 이 항목을 생성한 상위 프로세스의 프로세스 토큰을 상속합니다. "requireAdministrator" 실행 수준도 매우 간단하며 관리자 그룹의 멤버인 사용자 토큰에 의해 프로세스가 생성되어야 함을 정의합니다. 관리자가 아닌 사용자가 이 프로세스를 생성하려고 하면 자격 증명을 입력하는 Credential 대화 상자를 표시합니다.

highestAvailable 실행 수준은 약간 복잡합니다. 사용자가 연결된 토큰을 가진 경우 더 높은 권한의 토큰으로 응용 프로그램을 실행해야 함을 나타냅니다. 일반적으로 Users 및 Administrators 그룹용으로 디자인된 UI가 있는 응용 프로그램에서 사용되며 응용 프로그램이 사용자의 전체 권한을 획득하도록 보장합니다. 유의할 점은 Backup Operators 및 Network Operators 그룹의 사용자가 연결된 토큰을 갖고, 자격 증명을 입력하도록 요구하는 프롬프트가 표시되고, 자격 증명 대화상자가 해당 사용자 타일과 Administrators 그룹의 멤버의 타일을 갖게 된다는 것입니다. 그림 6은 응용 프로그램 매니페스트의 한 예입니다.

응용 프로그램 매니페스트 표시는 DLL이 아니라 EXE와 유일하게 관련이 있습니다. 그 이유는 UAC가 프로세스 생성 시 DLL을 조사하지 않기 때문입니다. 이 매니페스트를 네이티브 응용 프로그램에 포함시키려면, 매니페스트 파일을 소스와 동일한 디렉터리에 복사하고 리소스 파일에 매니페스트를 추가하여 매니페스트를 포함하도록 지정합니다. .rc 파일의 다음 행은 위의 매니페스트가 AdminApp.exe.manifest로 저장된 경우 해당 매니페스트를 포함합니다.

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

COM 개체 표시

COM 개체 생성 시 CoCreateAsAdmin 모니커를 사용하여 상승된 권한으로 실행 중인 COM 개체를 확보할 수 있습니다. 이 기능은 상승되어 실행되고 응용 프로그램의 UI에 표시되는 객체를 생성할 경우에 매우 유용합니다.

전체 권한 토큰으로 실행할 수 있도록 COM 개체에 몇 가지 기능을 추가해야 합니다. 상승된 권한으로 개체를 생성할 수 있음을 보여 주는 표시는 물론 UAC 상승 대화 상자에 표시되는 표시 이름도 지정되어야 합니다. 다음 레지스트리 키를 개체의 등록에 추가해야 합니다.

HKEY_LOCAL_MACHINE\Software\Classes\CLSID\
{CLSID}\LocalizedString = <displayname>
HKEY_LOCAL_MACHINE\Software\Classes\CLSID\
{CLSID}\Elevation\Enabled = 1

HKLM에 COM 개체가 등록되지 않고 이러한 정보가 모두 지정되지 않은 경우 상승된 COM 개체를 생성하려고 하면 실패합니다. 성공하면 호출이 필터링된 토큰에서 온 것으로 간주하여 사용자에게 상승을 입력하라는 프롬프트가 표시되고 COM 개체를 호스팅할 새 프로세스가 생성됩니다. 상승된 COM 개체를 생성하는 자세한 방법은 CoCreateAsAdmin 모니커에 대한 MSDN 문서(msdn2.microsoft.com/ms679687.aspx(영문))를 참조하십시오.

사용자에게 상승된 권한 알림

UAC의 또 다른 과제는 줄어든 권한으로 실행 중인 응용 프로그램과 관리자로 실행 중인 응용 프로그램 간의 차이를 알지 못하는 사용자와 통신하는 것입니다. 이러한 차이를 이해하는 열쇠는 상승에 대한 프롬프트 발생 시 표준화된 워크플로입니다. 상승 시퀀스는 항상 사용자가 아이콘에 방패 이미지가 있는 항목을 클릭하면 시작됩니다. 응용 프로그램 시작이 상승을 유발하면 아이콘 위에 겹친 방패 표시가 나타납니다. 상승을 유발하는 응용 프로그램의 모든 위치에는 방패 표시가 나타나야 합니다.

일반적인 컨트롤은 대부분 방패 표시를 추가할 수 있도록 업데이트되었습니다. 이 기능은 단추나 링크를 누르면 상승을 요구하는 새 프로세스가 생성되는 설정을 제공할 경우 매우 유용합니다. 문양이 새겨진 방패를 추가하는 코드는 매우 간단합니다. 예를 들어 표준 단추 컨트롤(PUSHBUTTON, DEFPUSHBUTTON)은 BS_ICON 또는 BS_BITMAP 스타일을 설정하지 않고 표시된 텍스트와 함께 아이콘을 추가할 수 있도록 개선되었습니다.

그림 7 단추 위의 방패

그림 7에 나오는 방패 아이콘을 표시하려면 SETSHIELD 메시지를 단추로 보내는 다음 매크로(commctrl.h에 정의됨)를 호출해야 합니다.

Button_SetElevationRequiredState(hwndButton, true);

동일한 스타일의 방패 표시를 Aero™ Wizard 단추, Syslink 및 Hyperlink 컨트롤, Commandlink 및 Command 단추 등에도 사용할 수 있습니다.

서로 다른 보안 컨텍스트에서 프로세스 간 통신

Windows Vista에는 WIM(Windows Integrity Mechanism)이라는 인증 기술도 포함되어 있습니다. WIM은 추가 인증을 위해 개체의 레이블로 사용되는 낮음, 중간, 높음, 시스템 보안 수준을 정의합니다. UAC 때문에 전체 관리자 권한을 가진 프로세스와 표준 사용자 토큰으로 실행 중인 프로세스가 동일한 데스크톱 세션에 있을 수도 있습니다. UAC는 WIM을 사용하여 권한 수준이 다른 프로세스 간에 Windows 메시지를 보내지 못하도록 차단합니다.

바탕 화면을 생성하는 데 사용되는 토큰은 중간 무결성 수준에서 실행됩니다(필터링된 관리자 토큰 샘플 참조). 이 방법을 사용하면 기본적으로 모두 중간 무결성 수준으로 실행됩니다. 사용자에게 상승을 입력하라는 프롬프트가 표시되고 해당 사용자의 승인을 제공하면 전체 권한 토큰으로 최종 프로세스가 생성되고 무결성 수준이 높음으로 설정됩니다. 이전에 권한이 낮은 UI가 권한이 높은 UI에게 메시지를 보내 더 높은 권한을 가진 프로세스를 구동하는 "shatter attacks(파상 공격)"라는 공격이 있었습니다. 이를 방지하기 위해 무결성 수준을 기반으로 대부분의 Windows 메시지를 더 이상 권한이 낮은 프로세스가 권한이 높은 프로세스에게 보내지 못하도록 하고 있습니다.

그러나 무결성 수준이 다른 프로세스 간에 통신하는 방법이 없지는 않습니다. 공유 메모리 또는 원격 프로시저 호출(RPC)을 사용하면 됩니다. RPC 진입점 또는 IPC 메커니즘을 생성할 때 표준 사용자로 실행 중인 프로세스에 의해 연결될 수 있도록 지정해야 합니다. 개체의 보안 설명자에 이러한 내용을 지정해야 합니다.

낮은 권한의 Internet Explorer

WIM 및 UAC의 또 다른 특징은 웹을 탐색하는 동안 사용자를 보호하기 위해 낮은 무결성 수준을 활용하도록 설정된 LowRights Internet Explorer®를 사용한다는 점입니다. 프로세스가 낮은 수준에서 실행될 경우 시스템에서 매우 좁은 영역의 디렉터리 및 파일과 상호 작용할 수 있습니다. ActiveX® 컨트롤이 응용 프로그램의 일부로 구현되고 Internet Explorer에 의해 호스팅되는 경우 테스트를 통해 제대로 실행되는지 확인하고 싶을 수도 있습니다. 자세한 내용은 msdn.microsoft.com/library/en-us/ietechcol/dnwebgen/protectedmode.asp의 백서(영문)를 참조하십시오.

Windows Vista에서 Windows 서비스 보안

Windows Vista에는 서비스를 잠그기 위한 많은 새로운 기능이 있습니다. 개발자는 서비스가 필요한 권한 수준을 지정할 수 있고 서비스에 SID(보안 식별자)를 적용하여 해당 서비스만 기록할 수 있도록 리소스 보안에 사용할 수 있습니다. 또한 네트워크에 액세스하지 못하도록 서비스를 차단할 수도 있습니다. 자세한 내용은 Windows 서비스에 대한 문서(microsoft.com/whdc/system/vista/Vista_Services.mspx)(영문)를 참조하십시오.

Windows Vista에서 sc.exe를 사용하면 이러한 새 보안 매개 변수를 정의할 수 있습니다(그림 8 참조). Privileges는 슬래시(/)로 구분된 권한 목록을 포함하는 문자열입니다. 예를 들어 백업 및 복원 권한을 지정하려면 Privileges를 SeBackupPrivilege/SeRestorePrivilege로 설정합니다.

Sc.exe를 사용하여 지정된 서비스의 SID를 획득할 수도 있습니다. 다음 명령은 서비스 이름이 지정된 서비스의 SID를 반환합니다.

Sc showsid [service name]

프로그래밍 방식으로 이 정보를 변경하려면 ChangeServiceConfig2라는 새 API를 사용합니다. 지정된 서비스 권한을 변경하려면 다음 매개 변수 값을 사용하여 ChangeServiceConfig2를 호출합니다. 변경된 권한은 다음에 서비스를 시작할 때 적용됩니다.

dwInfo 매개 변수는 SERVICE_CONFIG_REQUIRED_PRIVILEGES_INFO이고 lpInfo 버퍼는 SERVICE_REQUIRED_PRIVILEGES_INFO 구조체를 가리켜야 합니다. 이 구조체에는 필수 권한을 나열하는 단일 multistring이 있습니다.

서비스에 대해 서비스 SID를 적용하려면 프로그래밍 방식으로 플래그를 설정하고 다음 매개 변수 값을 사용하여 ChangeServiceConfig2를 호출합니다. 변경 사항은 다음에 시스템을 부팅할 때 적용됩니다. dwInfo 매개 변수는 SERVICE_CONFIG_SERVICE_SID_INFO로 설정되고 lpInfo 버퍼는 SERVICE_SID_INFO 구조체를 가리켜야 합니다. 이 구조체에는 SID 형식을 포함한 단일 DWORD 멤버가 있습니다.

LookupAccountName 및 LookupAccountSID라는 두 개의 관련 public 함수도 서비스 소유자에게 유용합니다. LookupAccountName은 SID를 가져와서 연관된 서비스 이름을 반환하고 LookupAccountSID는 서비스 이름을 가져와서 연관된 SID를 반환합니다. 이러한 설정값을 쿼리하려면 QueryServiceConfig2 API를 사용합니다.

서비스를 보호하는 또 다른 방법은 네트워크 액세스를 제한하는 것입니다. 서비스에 대해 방화벽 제한을 구성하려면 INetFwServiceRestriction 인터페이스를 사용합니다.

권한이 낮은 프로세스가 연결할 수 있는 RPC 인터페이스 노출에 유의하십시오. 사용자를 대신하여 수행될 수 있는 작업이 사용자에 의한 권한 상승을 허용하지 않도록 이 인터페이스를 신중히 디자인하고 테스트해야 합니다.

일반적인 응용 프로그램 호환성 문제

우리 팀에서 UAC를 만드는 과정에서 직면한 가장 큰 과제 중 하나는 응용 프로그램 환경에 심각한 영향을 미친다는 점이었습니다. 대부분의 응용 프로그램이 Users 그룹의 멤버로 실행되도록 설계되지 않았습니다. Microsoft는 일반적인 응용 프로그램 호환성 문제를 파악하기 위해 많은 시간을 투자했으며 이러한 문제 중 일부를 해결할 수 있는 기술을 Windows Vista에 추가했습니다. 이 기사의 마지막 단원에서는 이러한 문제 중 일부를 살펴보고 해결 방법에 대해 간략히 설명하겠습니다.

UAC에 포함된 첫 번째 응용 프로그램 호환성 기술은 설치 프로그램 탐지라는 기술입니다. 대부분의 설치 프로그램은 Program Files 디렉터리에 바이너리를 기록하기 때문에 관리자 권한이 필요합니다. 설치 프로그램 탐지는 EXE의 이름과 리소스를 검색하여 응용 프로그램이 설치 프로그램인지 여부를 판별하도록 만들어졌습니다. 예를 들어 실행 파일 이름이나 설명에 "install" 또는 "setup"이라는 문자열이 포함되어 있으면 해당 실행 파일은 설치 프로그램으로 표시됩니다. 따라서 setup.exe라는 응용 프로그램은 응용 프로그램 매니페스트가 없어도 관리자 권한이 없는 토큰에 의해 시작되면 UAC 상승을 트리거합니다.

런타임 시 파일과 레지스트리 문제를 수정할 수 있도록 설계된 UAC의 또 다른 기술은 파일 및 레지스트리 가상화라는 기술입니다. 많은 응용 프로그램은 로그 파일이나 구성을 Program Files 또는 Windows 디렉터리에 기록합니다. 이러한 디렉터리는 표준 사용자가 이 위치에 기록하는 것을 허용하지 않으므로 기록을 시도하면 즉시 실패하게 됩니다. 이 문제를 해결하기 위해 파일 가상화는 파일 시스템에서 보호된 특정 위치에 기록된 파일을 가져와서 사용자의 프로필로 기록을 리디렉션합니다. 기록되는 파일이 바이너리인 경우 가상화를 수행하지 않습니다. 레지스트리 가상화는 HKLM\Software에서 레지스트리의 사용자별 위치로 기록을 리디렉션하는 방식으로 레지스트리에 대해 동일한 작업을 수행합니다. 이러한 기술을 통해 레거시 응용 프로그램의 호환성이 상당히 높아졌습니다.

한 가지 주요한 사항은 바이너리에 응용 프로그램 매니페스트가 있거나 기본적으로 64비트로 컴파일된 경우에는 이러한 기술을 사용할 수 없다는 점입니다. 그 이유는 이러한 기술이 실제로는 표준 사용자를 염두에 두고 설계된 레거시 응용 프로그램을 위한 지원 기능에 불과하기 때문입니다. 불행히 이러한 기술은 모든 문제를 해결하지 못합니다. 이어서 몇 가지 다른 일반적인 문제를 살펴보겠습니다.

설치 시 문제

가장 자주 발견되는 문제 중 하나는 MSI 파일에서 CustomAction이 잘못 표시되는 것입니다. 많은 CustomAction은 CustomAction을 로컬 시스템으로 실행하는 가장 플래그 msidbCustomActionTypeNoImpersonate를 지정하지 않습니다. Windows Vista의 기본 토큰이 Users 그룹 멤버의 토큰과 유사하고 CustomAction이 관리자 권한이 필요한 작업을 수행하려고 시도하기 때문에 이러한 MSI 파일은 실패합니다. 이 문제는 msidbCustomActionTypeNoImpersonate 특성을 CustomAction에 추가하면 대부분 해결할 수 있습니다.

우리가 테스트하는 동안 직면한 또 다른 일반적인 문제는 설치의 일부로 실행되는 응용 프로그램과 관련이 있습니다. 설치가 끝날 때 응용 프로그램을 시작하는 것은 매우 일반적입니다. 그러나 사용자가 설치를 수행하도록 상승된 자격 증명을 제공하고 응용 프로그램이 상승된 사용자 토큰으로 생성되기 때문에 응용 프로그램이 잘못된 사용자 컨텍스트에서 시작되는 경우가 종종 있습니다. 이 문제를 해결하기 위한 권장 지침은 부트스트래퍼 EXE를 생성하는 것입니다. 이 부트스트래퍼는 임시 위치에 바이너리의 압축을 푼 다음 설치를 초기화하는 다른 프로세스를 시작합니다(그림 9 참조). 설치를 시작한 프로세스가 완료되면 응용 프로그램을 시작하는 압축 해제 프로그램에게 제어를 반환합니다. 이러한 방법으로 응용 프로그램이 표준 사용자 토큰으로 실행됩니다.

그림 9 부트스트래퍼를 사용하여 응용 프로그램 설치 및 실행 (더 크게 보려면 이미지를 클릭하십시오.)

우리가 자주 경험한 마지막 설치 문제는 응용 프로그램을 처음 실행할 때 관리자 권한이 필요한 작업을 수행하는 것입니다. 여기에는 바이너리를 Program Files로 복사 또는 업그레이드하거나 드라이버를 설치하거나 사용자를 관리자로 간주하는 기타 작업이 포함됩니다. 이러한 문제를 처리하는 가장 좋은 방법은 응용 프로그램을 설치할 때 테스트하고 표준 사용자로 실행하는 것입니다.

대부분의 응용 프로그램은 응용 프로그램 바이너리 업데이트를 위한 몇 가지 메커니즘을 가지고 있습니다. 대개 이러한 업데이트 프로그램은 낮은 권한의 토큰으로 실행되고 Program Files 디렉터리에 있는 바이너리를 덮어쓰려고 시도하기 때문에 실패합니다. 응용 프로그램이 바이너리를 업데이트하는 경우 업데이트 기능을 별도의 프로세스로 이동하고 관리자 권한이 필요한 것으로 표시하십시오. 또 다른 옵션은 MSP 파일을 사용하여 패치의 서명을 기반으로 하는 상승을 수행하는 것입니다. 이 경우 원본 MSI 파일의 MsiPatchCertificate 테이블을 채워야 합니다.

일반적인 런타임 응용 프로그램 문제

런타임 시 발생하는 가장 일반적인 실수 중 하나는 사용자가 관리자인지 확인하기 위한 불필요한 검사입니다. 예를 들어 많은 게임에서 맨 먼저 사용자가 관리자 그룹의 멤버인지 확인합니다. 이러한 게임은 종종 사용자에게 실패를 보고하지만 실제로 관리자 권한이 필요한 API를 호출하지 않습니다. 분명히 이러한 방법은 피해야 합니다. 그러나 융통성을 기하기 위해 관리자 권한이 필요하고 매니페스트되는 응용 프로그램을 작성하는 경우 이 검사를 추가하고 사용자가 관리자 권한이 없는 경우 종료합니다.

많은 응용 프로그램이 실행되는 즉시 HKEY_CLASSES_ROOT(HKCR)에 클래스를 등록합니다. 응용 프로그램이 더 이상 관리자 권한을 갖지 않기 때문에 이 위치에 기록하는 것이 불가능하고 작업이 실패하게 됩니다. 이러한 클래스 등록은 설치 시 수행되어야 하며 그렇지 않으면 사용자의 클래스 루트 HKCU\Software\Classes로 리디렉션됩니다.

또 다른 잠재적인 문제는 표준 사용자가 Global 네임스페이스에서 개체를 생성할 수 없다는 것입니다. 예를 들어 표준 사용자는 네임스페이스 내에서 명명된 파이프 또는 공유 메모리를 생성할 수 없습니다. Global은 교차 세션 상태를 유지하는 서비스나 응용 프로그램만 사용하도록 고안되었습니다. 대신 Local 네임스페이스를 사용해야 합니다. 이 네임스페이스는 표준 사용자가 작성할 수 있습니다.

개체를 열 때 MAX_ALLOWED를 사용하는 것은 또 다른 문제입니다. Windows XP에서는 일반적으로 응용 프로그램을 실행하는 사용자를 관리자로 간주합니다. 따라서 개발자가 파일과 레지스트리 키를 열 때 MAX_ALLOWED를 사용하는 경우 항상 전체 관리자 권한으로 파일을 열기 때문에 이 환경에서는 전혀 문제가 없습니다. Windows Vista에서는 이 기능이 변경되었습니다. 이제는 개발자가 응용 프로그램 작성 시 사용자가 개체를 여는 데 필요한 권한을 지정할 때 더욱 주의해야 합니다.

결론

이 기사에서는 Windows Vista의 새로운 개발 환경에 대해 간략히 설명했습니다. 가장 기본적인 변화는 응용 프로그램이 기본적으로 낮은 권한의 토큰으로 실행되고 따라서 시스템이나 다른 사용자에게 영향을 줄 수 없다는 것입니다. Windows Vista의 UAC와 관련된 자세한 내용은 MSDN 및 TechNet에서 이전에 언급한 UAC 백서를 참조하십시오. UAC는 사용자와 시스템 관리자의 생활을 훨씬 편리하게 만들 것입니다.

   

원본 위치 <http://msdn.microsoft.com/msdnmag/issues/07/01/UAC/Default.aspx?loc=ko>