Windows Vista의 UAC(사용자 계정 컨트롤) 기능은 오해를 받을 때가 많습니다. 3부로 구성된 Windows Vista 커널 변경에 대한 TechNet Magazine 기사에서는(technetmagazine.com) 별도의 기사로 다루는 것이 좋을 것으로 생각되어 UAC를 다루지 않았습니다.
이 기사에서는 UAC로 해결되는 문제를 설명하고 구성 요소 기술의 아키텍처와 구현을 설명합니다. 이러한 기술에는 이전에는 관리 권한이 필요했던 작업 리팩터링, 프로그램을 관리 권한 없이 올바르게 실행할 수 있도록 돕는 간단한 가상화, 프로그램이 관리 권한을 명시적으로 요청할 수 있도록 하는 기능, 같은 사용자 데스크톱에서 실행 중인 관리 권한 없는 프로세스와 관리 프로세스와의 격리 등이 포함됩니다.
UAC의 목표
UAC는 사용자가 관리 권한이 아닌 표준 사용자 권한으로 실행할 수 있도록 하는 것을 목표로 합니다. 관리 권한을 가진 사용자는 다른 사용자의 코드와 데이터를 비롯한 운영 체제의 모든 부분과 Windows® 자체를 읽고 수정할 수 있습니다. 관리 권한이 없는 경우 사용자는 시스템 설정을 실수로 또는 일부러 수정할 수 없고, 맬웨어는 시스템 보안 설정을 변경하거나 바이러스 백신 소프트웨어를 해제할 수 없으며, 공유 컴퓨터에서 다른 사용자의 중요한 정보를 침해할 수 없습니다. 따라서 표준 사용자 권한으로 실행하면 기업 환경에서 긴급한 기술 지원 요청이 줄어들고, 맬웨어의 영향이 완화되고, 가정용 컴퓨터가 더 원활하게 실행되며, 공유 컴퓨터의 중요한 데이터를 보호할 수 있습니다.
UAC는 표준 사용자 계정 실행이라는 목표를 현실화하기 위해 몇 가지 문제를 해결해야 했습니다. 먼저 Windows Vista™ 이전의 Windows 사용 모델에서는 기본적으로 관리 권한의 사용을 가정했습니다. 소프트웨어 개발자는 자신이 개발하는 프로그램이 파일, 레지스트리 키 또는 운영 체제 설정을 액세스하고 수정할 수 있다고 가정했습니다. Windows NT®에서 보안이 도입되고 관리 사용자 계정과 표준 사용자 계정이 구분된 뒤에도 설치 프로세스에서는 기본 제공 관리자 계정 또는 관리자 그룹의 구성원인 계정을 사용하도록 안내했습니다.
UAC가 해결해야 했던 두 번째 문제는 소프트웨어 설치, 시스템 시간 변경, 방화벽의 포트 열기 등과 같은 작업을 수행할 때는 사용자에게 관리 권한이 필요하다는 점이었습니다.
이 문제에 대한 UAC의 해결 방법은 대부분의 응용 프로그램을 표준 사용자 권한으로 실행하여 관리자 권한에 대한 필요성을 제거하고 소프트웨어 개발자에게 표준 사용자 권한으로 실행하는 응용 프로그램의 개발을 요청하는 것입니다. UAC는 관리 권한 요청의 필요성을 줄이고, 레거시 응용 프로그램이 표준 사용자 권한으로 실행되도록 하고, 필요할 때는 표준 사용자가 편리하게 관리 권한에 액세스하도록 하고, 관리 사용자라도 표준 사용자처럼 실행할 수 있도록 함으로써 이런 문제를 해결합니다.
표준 사용자로 실행
Windows Vista 개발 단계에서 모든 관리 작업을 감사한 결과 작업 중 많은 부분은 시스템 보안 침해 없이 표준 사용자용으로 설정할 수 있음이 밝혀졌습니다. 예를 들어 Windows XP 데스크톱 시스템에 표준 사용자 계정을 채택한 회사에서도 Windows XP에서는 표준 시간대 변경과 시스템 시간 변경이 구분되지 않는다는 이유 하나 때문에 관리자 그룹에서 모바일 사용자를 제거할 수 없었습니다. 랩톱 사용자가 여행할 때 약속 시간이 일정에 올바르게 표시되도록 하기 위해 현지 시간대를 구성하려면 "시스템 시간 변경" 권한(내부적으로는 SeSystemTimePrivilege)이 있어야 하는데 이 권한은 기본적으로 관리자에게만 부여되어 있습니다.
시간은 Kerberos와 같은 보안 프로토콜에 많이 사용되지만 표준 시간대는 시간이 표시되는 방식에만 영향을 주기 때문에 Windows Vista에서는 그림 1에서처럼 "표준 시간대 변경"(SeTimeZonePrivilege) 권한이 새롭게 추가되어 사용자 그룹에 할당되었습니다. 이를 통해 많은 회사에서 랩톱 사용자가 표준 사용자 계정으로 실행할 수 있게 되었습니다.
그림 1 "표준 시간대 변경" 권한 (Click the image for a smaller view)
그림 1 "표준 시간대 변경" 권한 (Click the image for a larger view)
또한 Windows Vista에서는 표준 사용자가 무선 네트워크에 연결할 때 WEP 설정을 구성하고, VPN 연결을 만들고, 전원 관리 설정을 변경하고, 중요 Windows 업데이트를 설치할 수 있습니다. 이외에도 표준 사용자가 IT 관리자의 승인을 얻은 장치 드라이버와 프린터를 설치할 수 있도록 하고 관리자가 승인한 사이트의 ActiveX® 컨트롤을 설치할 수 있도록 하는 그룹 정책 설정도 추가되었습니다.
그렇다면 표준 계정에서 제대로 실행되지 않는 고객 응용 프로그램과 기간 업무(LOB) 응용 프로그램의 문제는 어떻게 해결할까요? 정식으로 관리 권한을 필요로 하는 소프트웨어도 있지만 대부분의 프로그램은 불필요하게 사용자 데이터를 시스템 전역 위치에 저장합니다. Microsoft에서는 관리 권한으로 실행되어야 하는 전역 응용 프로그램 설치 관리자는 %ProgramFiles% 디렉터리 아래에 디렉터리를 만들어서 여기에 응용 프로그램의 실행 파일과 보조 데이터를 저장하고 응용 프로그램 설정에 필요한 내용이 있으면 HKEY_LOCAL_MACHINE\Software 아래에 키를 만들도록 권장합니다. 응용 프로그램이 여러 사용자 계정으로 실행될 수 있으므로 사용자 고유 데이터는 사용자별 %AppData% 디렉터리에 저장하고 사용자별 설정은 HKEY_CURRENT_USER\ Software 아래의 사용자 레지스트리 프로필에 저장하도록 합니다. 표준 사용자 계정에는 %ProgramFiles% 디렉터리나 HKEY_LOCAL_MACHINE\Software에 대한 쓰기 액세스 권한이 없습니다. 그렇지만 Windows Vista 이전에는 대부분의 Windows 시스템이 단일 사용자 시스템이고 대부분의 사용자가 관리자였기 때문에 사용자 데이터와 설정을 지정된 위치에 올바르게 저장하지 않는 응용 프로그램도 정상적으로 작동했습니다.
Windows Vista에서는 파일 시스템 및 레지스트리 네임스페이스 가상화를 통해 이러한 레거시 응용 프로그램을 표준 사용자 계정으로 실행할 수 있습니다. 응용 프로그램이 파일 시스템이나 레지스트리의 시스템 전역 위치를 수정할 때 액세스 거부로 인해 작업이 실패하면 Windows는 작업을 사용자별 영역으로 리디렉션합니다. 응용 프로그램이 시스템 전역 위치에서 읽기 작업을 하면 Windows는 먼저 사용자별 영역에서 데이터를 확인하고 데이터가 없으면 전역 위치에서 읽기를 시도합니다.
이 가상화를 위해 Windows Vista에서는 프로세스가 64비트가 아니라 32비트이고, 관리 권한으로 실행되지 않으며, Windows Vista용으로 작성되었음을 나타내는 매니페스트 파일이 없으면 레거시 프로세스로 취급합니다. 네트워크 파일 공유 액세스를 포함하여 이 정의에 따라 레거시로 분류된 프로세스에서 수행된 작업이 아닌 경우에는 가상화되지 않습니다. 프로세스의 가상화 상태는 토큰에 플래그로 저장됩니다. 이 토큰은 사용자 계정, 그룹 구성원 자격 및 권한을 포함하여 프로세스의 보안 컨텍스트를 추적하는 커널 데이터 구조입니다.
작업 관리자의 프로세스 페이지에 가상화 열을 추가하면 프로세스의 가상화 상태를 볼 수 있습니다. 그림 2에서 바탕 화면 창 관리자(Dwm .exe), 클라이언트 서버 런타임 하위 시스템(Csrss.exe) 및 탐색기를 비롯한 대부분의 Windows Vista 구성 요소를 볼 수 있습니다. 이들 구성 요소는 Windows Vista 매니페스트가 있기 때문에 가상화가 해제되었거나, 관리 권한으로 실행되기 때문에 가상화가 허용되지 않습니다. Internet Explorer®(iexplore.exe)의 경우에는 표준 사용자 권한으로 올바르게 작동하도록 작성되지 않은 것으로 간주해야 하는 여러 ActiveX 컨트롤과 스크립트를 호스팅할 수 있으므로 가상화가 사용됩니다.
그림 2 가상화 상태가 표시된 작업 관리자 (Click the image for a smaller view)
그림 2 가상화 상태가 표시된 작업 관리자 (Click the image for a larger view)
레거시 프로세스를 위해 가상화되는 파일 시스템 위치는 몇 개의 특정 하위 디렉터리를 제외한 %ProgramFiles%, %ProgramData% 및 %SystemRoot%입니다. 하지만 .exe, .bat, .scr, .vbs 등을 포함하여 실행 가능한 확장명이 있는 모든 파일은 가상화에서 제외됩니다. 즉, 표준 사용자 계정에서 직접 업데이트되는 프로그램은 전역 업데이트 관리자를 실행하는 관리자에게 보이지 않는 전용 버전의 실행 파일을 만들지 못하고 실패합니다. 제외 목록에 다른 확장명을 추가하려면 다음 레지스트리 키에 이를 추가하고 다시 부팅합니다.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd
다중 문자열 유형을 사용하여 여러 확장명을 구분하고 확장명 이름 앞에 점을 추가하지 마십시오.
레거시 프로세스에서 가상화된 디렉터리에 대해 수정 작업을 수행하면 사용자의 가상 루트 디렉터리인 %LocalAppData%\VirtualStore로 리디렉션됩니다. 예를 들어 필자의 시스템에서 실행 중인 가상화된 프로세스는 C:\Windows\Application.ini를 생성하지만 실제로 이 파일은 C:\Users\Markruss\AppData\Local\VirtualStore\Windows\Application.ini에 생성됩니다. 경로 중 Local 부분은 계정에 로밍 프로필이 있을 때 가상화된 파일이 프로필의 나머지 부분과 함께 로밍되지 않는다는 점을 보여 줍니다.
탐색기에서 가상화된 파일이 있는 디렉터리로 이동하면 그림 3에서처럼 탐색기 도구 모음에 호환성 파일이라는 단추가 표시됩니다. 이 단추를 클릭하면 해당하는 VirtualStore 하위 디렉터리로 이동하여 가상화된 파일이 표시됩니다.
그림 3 가상화된 파일이 있음을 나타내는 호환성 파일 단추 (Click the image for a smaller view)
그림 3 가상화된 파일이 있음을 나타내는 호환성 파일 단추 (Click the image for a larger view)
그림 4에서는 UAC 파일 가상화 필터 드라이버(%SystemRoot%\System32\Drivers\Luafv.sys)가 파일 시스템 가상화를 구현하는 방식을 보여 줍니다. 파일 시스템 필터 드라이버이기 때문에 모든 파일 시스템 작업을 감시할 수 있지만 레거시 프로세스의 작업에 대한 기능만 구현합니다. 시스템 전역 위치에 파일을 생성하는 레거시 프로세스의 대상 파일 경로를 변경하지만 Windows Vista 응용 프로그램을 표준 사용자 권한으로 실행하는 프로세스에 대해서는 변경 작업을 수행하지 않습니다. 레거시 프로세스는 사용자가 완전히 액세스할 수 있는 위치에 파일을 실제로 생성하면 작업이 성공한 것으로 간주하지만 \Windows 디렉터리의 기본 사용 권한은 Windows Vista 용으로 작성된 응용 프로그램에 대한 액세스를 거부합니다.
그림 4 파일 시스템 가상화
레지스트리 가상화는 파일 시스템 가상화와는 약간 다르게 구현됩니다. 대부분의 HKEY_LOCAL_MACHINE\Software 분기가 가상화된 레지스트리 키에 포함되지만 다음과 같은 예외가 많이 존재합니다.
HKLM\Software\Microsoft\Windows
HKLM\Software\Microsoft\Windows NT
HKLM\Software\Classes
레거시 응용 프로그램에 의해 수정되지만 호환성이나 상호 운용성 문제를 일으키지 않는 키만 가상화됩니다. Windows는 레거시 응용 프로그램이 가상화된 키를 수정하는 경우 HKEY_ CURRENT_USER\Software\Classes\VirtualStore에 있는 사용자의 레지스트리 가상 루트로 리디렉션합니다. 키는 사용자의 Classes 하이브인 %LocalAppData%\Microsoft\Windows\UsrClass.dat에 위치하며 이 하이브는 다른 가상화된 파일 데이터와 마찬가지로 로밍 사용자 프로필과 함께 로밍되지 않습니다.
Windows에서 파일 시스템에 대해 작성하는 것처럼 고정된 가상화된 위치 목록을 작성하는 대신 키의 가상화 상태는 키 자체에 REG_ KEY_DONT_VIRTUALIZE 플래그로 저장됩니다. Reg.exe 유틸리티를 사용하면 그림 5에서처럼 이 플래그와 다른 가상화 관련 플래그인 REG_KEY_ DONT_SILENT_FAIL 및 REG_KEY_ RECURSE_FLAG를 볼 수 있습니다. REG_KEY_DONT_SILENT_FAIL이 설정되었고 키가 가상화되지 않은 경우(REG_KEY_DONT_VIRTUALIZE가 설정됨) 키에 대한 작업을 수행하기 위한 액세스가 거부되던 레거시 응용 프로그램에는 응용 프로그램이 요청한 권한이 아니라 사용자가 키에 대해 가진 모든 액세스 권한이 부여됩니다. REG_KEY_RECURSE_FLAG는 새 하위 키가 기본 플래그 대신 부모 키의 가상화 플래그를 상속하는지 여부를 나타냅니다.
그림 5 가상화 플래그를 표시하는 Reg 유틸리티 (Click the image for a smaller view)
그림 5 가상화 플래그를 표시하는 Reg 유틸리티 (Click the image for a larger view)
그림 6은 운영 체제 커널 Ntoskrnl.exe의 레지스트리를 관리하는 구성 관리자가 레지스트리 가상화를 구현하는 방식을 보여 줍니다. 파일 시스템 가상화와 마찬가지로 가상화된 키의 하위 키를 생성하는 레거시 프로세스는 사용자의 레지스트리 가상 루트로 리디렉션되지만 Windows Vista 프로세스는 기본 사용 권한에 의해 액세스가 거부됩니다.
일부 응용 프로그램의 경우에는 파일 시스템과 레지스트리 가상화 이외의 추가적인 지원이 있어야 표준 사용자 권한으로 올바르게 실행할 수 있습니다. 예를 들어 계정이 관리자 그룹의 구성원 자격으로 실행되는지 테스트하는 응용 프로그램은 해당 그룹에 있지 않으면 실행되지 않습니다. 따라서 Windows Vista에서는 이러한 응용 프로그램이 작동할 수 있도록 여러 가지 응용 프로그램 호환성 shim을 정의합니다. shim은 대개의 경우 그림 7에 표시된 것처럼 표준 권한의 작업을 위해 레거시 응용 프로그램에 적용됩니다. 회사 IT 전문가는 ACT(Application Compatibility Toolkit, technet.microsoft.com/windowsvista/aa905066.aspx에서 구할 수 있음) 도구와 SUA(Standard User Analyzer) 유틸리티 또는 Aaron Margosis의 LUA Buglight를 사용하여 LOB 응용 프로그램의 shim 요구 사항을 확인할 수 있습니다. ACT의 구성 요소인 Compatibility Administrator를 사용하여 응용 프로그램에 shim을 할당한 다음 생성된 호환성 데이터베이스(.sdb 파일)를 그룹 정책을 통해 데스크톱에 배포합니다. 필요한 경우 로컬 보안 정책 설정을 사용하여 시스템에서 가상화를 완전히 해제할 수 있습니다.
가상화의 효과
작업 관리자에서 마우스 오른쪽 단추를 클릭하면 나타나는 상황에 맞는 메뉴에서 가상화를 선택하면 프로세스의 가상화 상태를 변경할 수 있습니다. 그림 A에서는 가상화 상태가 변경될 때 명령 프롬프트의 동작을 보여 줍니다. 우선 Windows Vista 매니페스트가 있기 때문에 가상화가 해제된 상태로 시작됩니다. 표준 사용자 권한으로 실행되기 때문에 \Windows 디렉터리에 파일을 만들 수 없지만 작업 관리자로 가상화된 뒤에는 파일을 성공적으로 만든 것으로 나타납니다. 가상화가 해제된 상태로 돌아가면 실제로는 사용자의 가상 저장소에 있는 파일을 찾을 수 없게 됩니다.
그림 A 가상화 상태 변경 (Click the image for a smaller view)
그림 A 가상화 상태 변경 (Click the image for a larger view)
관리자 승인 모드
표준 사용자 권한으로 사용할 수 있는 프로그램만 실행하더라도 일부 작업에는 여전히 관리 권한이 필요합니다. 대부분의 소프트웨어 설치 작업은 시스템 전역 위치에 디렉터리와 레지스트리 키를 만들거나 서비스 또는 장치 드라이버를 설치하기 위해 관리 권한을 필요로 합니다. 시스템 전역 Windows 및 응용 프로그램 설정을 수정할 때는 Windows Vista 자녀 보호 기능처럼 관리 권한이 필요합니다. 이러한 작업 대부분은 전용 관리 계정으로 전환하여 수행할 수도 있지만 불편하기 때문에 대부분의 사용자가 일반적인 작업을 수행할 때도 관리 계정을 계속 사용할 가능성이 커집니다.
따라서 Windows Vista에는 표준 사용자가 편리하게 관리 권한으로 프로세스를 실행할 수 있도록 하는 "다른 계정으로 실행" 기능이 포함되어 있습니다. 이 기능을 사용하려면 해당 응용 프로그램은 필요에 따라 응용 프로그램 대신 시스템이 관리 권한을 가져올 수 있는 작업을 식별할 수 있어야 합니다. 이에 대해 뒤에서 간략하게 설명하겠습니다.
또한 시스템 관리자 역할을 수행하는 사용자가 표준 사용자 권한으로 실행하되 관리 권한이 필요할 때마다 사용자 이름과 암호를 입력할 필요가 없도록 하기 위해 Windows Vista에는 AAM(관리자 승인 모드) 기능이 도입되었습니다. 이 기능은 로그온 시 사용자에 대해 표준 사용자 권한을 가진 ID와 관리 권한을 가진 ID를 만듭니다. Windows Vista 시스템의 모든 사용자는 표준 사용자이거나 AAM에서 대부분 표준 사용자로 실행되기 때문에 개발자는 모든 Windows 사용자가 표준 사용자인 것으로 가정해야 합니다. 따라서 가상화나 shim 없이 표준 사용자 권한으로 작동하는 프로그램이 많아질 것입니다.
프로세스에 관리 권한을 부여하는 것을 권한 상승이라고 합니다. 표준 사용자 계정에 의해 수행될 때는 관리자 그룹의 구성원인 계정에 대한 자격 증명을 입력해야 하며 이 과정은 마치 다른 사용자가 표준 사용자의 어깨 너머에서 입력하는 것과 같은 방식으로 처리되기 때문에 이를 OTS(Over the Shoulder) 권한 상승이라고 합니다. AAM 사용자가 권한 상승을 수행할 때는 사용자가 관리 권한의 할당을 승인하기만 하면 되므로 승인(Consent) 권한 상승이라고 합니다.
Windows Vista에서는 사용자가 그림 8에 나열된 관리자 유형의 그룹 중 하나의 구성원인 경우에는 관리자로 간주합니다. 나열된 그룹 중 대다수는 도메인에 가입되어 있는 시스템에서만 사용되며 사용자에게 로컬 관리 권한을 직접 부여하지 않지만 도메인 전체에 적용되는 설정의 수정을 허용합니다. 사용자가 이러한 그룹 중 하나의 구성원이지만 실제 관리자 그룹에 속한 것은 아닌 경우 사용자는 승인 권한 상승 대신 OTS 권한 상승을 통해 자신의 관리 권한에 액세스합니다.
나열된 그룹 중 하나에 속한 사용자가 로그온하면 Windows Vista는 사용자 관리 ID의 표준 사용자 버전을 나타내는 토큰을 생성합니다. 새 토큰에서는 그림 9에 나열된 기본 표준 사용자 권한을 제외한 해당 사용자에게 할당된 모든 권한이 제거됩니다. 또한 새 토큰에서 모든 관리자 유형 그룹은 USE_FOR_DENY_ONLY 플래그로 표시됩니다. 그림 10에서는 microsoft.com/technet/sysinternals에서 다운로드할 수 있는 프로세스 관리 도구인 Sysinternals Process Explorer를 볼 수 있습니다. 이 도구의 왼쪽에는 관리 권한으로 실행되는 프로세스의 그룹 구성원과 권한이, 오른쪽에는 관리 권한 없이 실행되는 프로세스의 그룹 구성원과 권한이 표시됩니다. 부주의한 사용을 방지하기 위한 Windows 보안 모델에 따라 해제된 플래그가 있는 권한을 사용하려면 다시 설정해야 합니다.
그림 10 AAM 관리자 및 표준 사용자 토큰 (Click the image for a smaller view)
그림 10 AAM 관리자 및 표준 사용자 토큰 (Click the image for a larger view)
deny-only 플래그가 있는 그룹은 리소스에 대한 사용자 액세스를 거부하고 허용하지 않을 때만 사용하여 그룹을 함께 제거했을 때 생길 수 있는 보안 공백을 메울 수 있습니다. 예를 들어 관리자 그룹의 모든 액세스는 거부하지만 사용자가 속한 다른 그룹에 대한 액세스는 일부 허용하는 ACL(액세스 제어 목록)이 파일에 있는 경우, 관리자 그룹이 토큰에 없으면 사용자에게 액세스 권한이 부여되어 사용자 ID의 표준 사용자 버전이 관리자 ID보다 많은 액세스 권한을 가지게 됩니다.
일반적인 가정용 컴퓨터와 같은 독립 실행형 시스템과 도메인에 가입되어 있는 시스템은 원격 사용자에 의한 AAM 액세스를 각기 다른 방식으로 처리합니다. 도메인 연결 컴퓨터는 리소스 사용 권한에 도메인 관리 그룹을 사용할 수 있기 때문입니다. 사용자가 독립 실행형 컴퓨터의 파일 공유 위치에 액세스할 때 Windows는 원격 사용자의 표준 사용자 ID를 요청하지만 도메인에 가입되어 있는 시스템의 경우에는 Windows는 사용자의 관리 ID를 요청하여 사용자의 모든 도메인 그룹 구성원 자격을 그대로 사용합니다.
관리 권한에 편리하게 액세스
시스템과 응용 프로그램이 관리 권한의 필요성을 파악하는 방법에는 여러 가지가 있습니다. 그 중 한 가지는 탐색기 UI에 나타나는 "관리자 권한으로 실행" 상황에 맞는 메뉴 항목과 바로 가기 옵션입니다. 이 항목에는 선택했을 때 권한이 상승되는 모든 단추나 메뉴 항목에 나타나는 컬러 방패 모양 아이콘이 표시됩니다. "관리자 권한으로 실행"을 선택하면 탐색기가 "runas" 명령으로 ShellExecute API를 호출합니다.
대부분의 설치 프로그램에는 관리 권한이 필요하므로 실행 파일의 시작을 초기화하는 이미지 로더에는 레거시 설치 프로그램을 식별하기 위한 설치 프로그램 감지 코드가 포함되어 있습니다. 이러한 감지 방법 중에는 이미지의 파일 이름이나 내부 버전 정보에 setup, install 또는 update 등의 단어가 있는지 확인하는 간단한 방식도 있고, 실행 파일에서 타사 설치 래퍼 유틸리티에 많이 사용되는 바이트 시퀀스를 검사하는 정교한 방식도 있습니다.
또한 이미지 로더는 응용 프로그램 호환성(appcompat) 라이브러리를 호출하여 대상 실행 파일이 관리자 권한을 필요로 하는지 확인합니다. 라이브러리는 응용 프로그램 호환성 데이터베이스를 조회하여 실행 파일에 RequireAdministrator 또는 RunAsInvoker 호환성 플래그가 연결되어 있는지 확인합니다.
실행 파일이 관리 권한을 요청하기 위해 가장 많이 사용하는 방법은 응용 프로그램 매니페스트 파일에 requestedElevationLevel 태그를 포함하는 방법입니다. 매니페스트는 이미지에 대한 보충 정보가 포함된 XML 파일입니다. 이 파일은 Windows XP에서 side-by-side DLL 및 Microsoft .NET Framework 어셈블리에 대한 종속성을 식별하는 방법으로 도입되었습니다. Firewallsettings.exe에서 추출된 아래의 문자열 덤프에서 볼 수 있는 것처럼 매니페스트에 trustInfo 요소가 있으면 해당 실행 파일이 Windows Vista용으로 작성되었으며 requestedElevationLevel 요소가 중첩되어 있음을 의미합니다. 요소의 level 특성은 asInvoker, highestAvailable 및 requireAdministrator의 세 값 중 하나일 수 있습니다.
<trustInfo
xmlns="urn:schema-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
Level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
Notepad.exe처럼 관리 권한이 필요 없는 실행 파일은 asInvoker 값을 지정합니다. 일부 실행 파일은 관리자에게 항상 액세스 권한이 최대로 필요한 것으로 간주하므로 이런 파일은 highestAvailable 값을 사용합니다. 사용자가 이 값을 가진 실행 파일을 실행하면 해당 사용자가 AAM에서 실행 중이거나 이전에 정의된 규칙에 따라 관리자로 간주되는 경우에만 권한 상승을 묻는 메시지가 나타나며, 관리 권한에 액세스하려면 권한을 상승해야 합니다. highestAvailable을 사용하는 응용 프로그램에는 Regedit.exe, Mmc.exe 및 Eventvwr.exe 등이 있습니다. 마지막으로 requireAdministrator는 항상 권한 상승 요청을 하며 관리 권한이 없이 작동하면 실패하는 모든 실행 파일에 사용됩니다.
내게 필요한 옵션 지원 응용 프로그램은 권한이 상승된 프로세스의 창 입력을 위해 uiAccess 속성에 "true"를 지정하며 서명이 되어 있어야 하고 %SystemRoot% 및 %ProgramFiles%를 포함한 몇 개의 보안 위치 중 하나에 있어야 해당 기능을 수행할 수 있습니다.
다음과 같이 Sysinternals Sigcheck 유틸리티로 매니페스트를 확인하면 실행 파일에 의해 지정된 값을 쉽게 알아낼 수 있습니다.
sigcheck –m <executable>
관리 권한을 필요로 하는 이미지를 실행하면 서비스 호스트 프로세스(%SystemRoot%\System32\Svchost .exe) 내에서 실행되는 AIS(응용 프로그램 정보 서비스, %SystemRoot%\System32\Appinfo.dll에 포함됨)가 Consent.exe(%SystemRoot%\System32\Consent.exe)를 시작합니다. Consent는 화면의 비트맵을 캡처하여 페이드 효과를 적용하고 로컬 시스템 계정에만 액세스할 수 있는 데스크톱으로 전환한 다음 비트맵을 배경으로 칠하고 실행 파일에 대한 정보가 포함된 권한 상승 대화 상자를 표시합니다. 별도의 데스크톱에 표시함으로써 사용자 계정에 있을 수 있는 맬웨어가 대화 상자의 모양을 수정하는 것을 방지할 수 있습니다.
그림 11 OTS 권한 상승 대화 상자 (Click the image for a smaller view)
그림 11 OTS 권한 상승 대화 상자 (Click the image for a larger view)
이미지가 Microsoft에서 디지털 서명한 Windows 구성 요소이며 이미지가 Windows 시스템 디렉터리에 있으면 그림 11의 맨 위에서 볼 수 있는 것처럼 대화 상자 상단에 파란색 막대가 표시됩니다. 가운데 대화 상자의 회색 막대는 Microsoft 이외의 누군가에 의해 디지털 서명된 이미지를, 맨 아래 대화 상자의 주황색 막대는 서명되지 않은 이미지를 나타냅니다. 권한 상승 대화 상자에는 이미지의 아이콘, 설명 및 디지털 서명된 이미지의 게시자가 표시되지만 서명되지 않은 이미지의 경우에는 일반 아이콘, 파일 이름 및 "알 수 없는 게시자"가 표시됩니다. 이 때문에 맬웨어는 정상 소프트웨어의 모양을 흉내내기가 어려워집니다. 대화 상자 아래쪽의 Details(세부 정보) 단추를 클릭하면 실행될 때 실행 파일에 전달될 명령줄이 표시됩니다. 그림 12의 AAM Consent(AAM 승인) 대화 상자도 비슷한 기능을 제공하지만 관리자 자격 증명을 묻는 대신 계속 및 취소 단추를 제공합니다.
그림 12 AAM 권한 상승 대화 상자 (Click the image for a smaller view)
그림 12 AAM 권한 상승 대화 상자 (Click the image for a larger view)
사용자가 권한 상승을 거부하면 Windows는 실행을 시작한 프로세스에 액세스 거부 오류를 반환합니다. 사용자가 관리자 자격 증명을 입력하거나 계속을 클릭하여 권한 상승에 동의하면 AIS는 CreateProcessAsUser를 호출하여 적절한 관리 ID로 프로세스를 시작합니다. 기술적으로 보면 AIS는 권한 상승된 프로세스의 부모지만, AIS는 프로세스의 부모 프로세스 ID를 해당 프로세스를 원래 시작한 프로세스의 ID로 설정하는 CreateProcessAsUser API의 새로운 기능을 사용합니다(그림 13 참조). 이런 이유 때문에 프로세스 트리가 표시되는 Process Explorer와 같은 도구에서 권한 상승된 프로세스가 AIS 서비스 호스팅 프로세스의 자식으로 나타나지 않습니다.
그림 13 권한 상승 흐름
권한 상승 대화 상자가 별도의 보안 데스크톱에 표시되기는 하지만 사용자는 기본적으로 현재 표시된 대화 상자가 정상적이며 맬웨어가 표시한 대화 상자가 아니라는 것을 확인할 방법이 없습니다. 맬웨어는 가짜 승인 대화 상자로 관리 권한을 얻을 수 없기 때문에 AAM에 있어서 이는 문제가 아닙니다. 하지만 맬웨어가 표준 사용자의 OTS 권한 상승을 기다렸다 이를 가로채 트로이 목마 대화 상자를 사용하여 관리자 자격 증명을 확보하는 것은 가능하므로 이렇게 확보한 자격 증명으로 관리자의 계정에 액세스하여 감염시킬 수도 있습니다.
이런 이유 때문에 회사 환경에서는 OTS 권한 상승을 사용하지 말 것을 강력하게 권장합니다. OTS 권한 상승 기능을 사용하지 않으려면(그래서 지원 부서 호출을 줄이려면), 로컬 보안 정책 편집기(Secpol.msc)를 실행하고 "사용자 계정 컨트롤: 표준 사용자 계정일 때 권한 상승 확인 방법"을 "권한 상승 요청 자동으로 거부"로 구성합니다.
보안의 중요성을 알고 있는 가정용 컴퓨터의 사용자는 OTS 권한 상승에서 맬웨어가 가로채거나 시뮬레이션하지 못하는 SAS(Secure Attention Sequence)를 사용하도록 구성해야 합니다. SAS를 구성하려면 그룹 정책 편집기(Gpedit.msc)를 실행하고 컴퓨터 구성 | 관리 템플릿 | Windows 구성 요소 | 자격 증명 사용자 인터페이스로 이동하여 "자격 증명 입력 시 신뢰할 수 있는 경로를 요구합니다."를 설정합니다. 이제부터 권한 상승 대화 상자에 액세스하려면 Ctrl+Alt+Delete를 눌러야 합니다.
권한 상승된 프로세스 격리
Windows Vista에서는 권한 상승된 프로세스 주위에 경계를 설정하여 같은 데스크톱에서 표준 사용자 권한으로 실행되는 맬웨어로부터 보호합니다. 경계가 없으면 맬웨어는 창 메시지를 통한 창 입력과 마우스 입력을 함께 전송하여 관리 응용 프로그램을 구동할 수 있습니다. 또한 표준 Windows 보안 모델에 의해 표준 사용자 권한으로 프로세스에서 실행 중인 맬웨어가 다른 사용자로 실행 중인 권한 상승된 프로세스를 변경하는 것이 방지되기는 하지만, 관리 사용자의 표준 권한 버전으로 실행 중인 맬웨어가 사용자의 권한 상승된 프로세스를 열고 코드를 삽입하고 여기에서 스레드를 시작하여 삽입된 코드를 실행하는 것을 막을 수는 없습니다.
창 메시지에 대한 Windows Vista의 방어 기능을 UIPI(User Interface Privilege Isolation)라고 합니다. 이 기능은 Windows Vista가 권한 상승된 프로세스 주위의 경계로 이용하는 새로운 Windows 무결성 메커니즘을 기반으로 합니다. 이 새로운 보안 모델에서는 모든 프로세스와 개체에 무결성 수준이 있으며 개체의 무결성 정책에 따라 Windows DAC(Discretionary Access Control) 보안 모델에서 프로세스에 부여할 수 있는 액세스 권한이 제한될 수 있습니다.
무결성 수준(IL)은 사용자와 그룹도 표시하는 보안 ID(SID)로 표현됩니다. 이 보안 ID에서는 무결성 수준이 SID의 관련 ID(RID)에 인코딩됩니다. 그림 14에서는 네 개의 기본 IL에 대한 SID의 RID의 표시 이름, SID 및 16진수 버전을 볼 수 있습니다. 16진수 숫자는 향후 확장 가능성과 UI 내게 필요한 옵션 지원 응용 프로그램에서 사용할 때에 대비하여 중간 수준을 사용할 수 있도록 각 수준 간 간격이 0x1000으로 유지됩니다.
그림 15에서는 개체 IL 정책과 각 정책이 제한하는 액세스 유형(개체에 대해 정의된 일반 액세스에 해당됨)을 나열합니다. 예를 들어 No-Write-Up은 IL이 낮은 프로세스가 GENERIC_WRITE 액세스로 표시되는 액세스 권한을 얻지 못하도록 합니다. 파일 및 레지스트리 키를 포함하여 대부분 개체의 기본 정책은 No-Write-Up이며 이 정책은 개체의 DACL(임의 액세스 제어 목록)이 사용자에게 해당 액세스를 허용하더라도 프로세스가 자신보다 IL이 높은 개체에 대한 쓰기 액세스 권한을 얻지 못하도록 합니다. 다른 정책을 가지는 유일한 개체는 프로세스 및 스레드 개체입니다. 이 두 개체의 정책인 No-Write-Up 및 No-Read-Up은 낮은 IL로 실행 중인 프로세스가 높은 IL을 갖는 프로세스에 코드를 삽입하고 암호와 같은 데이터를 읽지 못하도록 합니다.
Windows는 모든 프로세스에 IL을 할당하며 이 IL은 프로세스를 실행하는 사용자가 속하는 그룹의 SID와 함께 프로세스 토큰에 저장됩니다. 그림 16에서는 여러 IL이 할당된 프로세스의 예를 보여 줍니다. 프로세스는 일반적으로 부모 프로세스의 IL을 상속하지만 프로세스는 AIS가 권한 상승된 프로세스를 시작할 때처럼 IL이 다른 프로세스를 시작할 수도 있습니다. 프로세스 무결성 수준은 기본 제공 Whoami 유틸리티에 /all 옵션을 지정하거나, Sysinternals Process Explorer 또는 AccessChk를 사용하여 확인할 수 있습니다. Process Explorer에 무결성 수준 열을 추가하면 프로세스 IL을 표시할 수 있습니다.
모든 검색 가능 개체에는 명시적이거나 암시적인 IL이 있습니다. 프로세스, 스레드 및 토큰 개체에는 항상 명시적으로 할당된 IL이 있으며 이 IL은 일반적으로 해당 프로세스 토큰에 저장된 것과 같습니다. 대부분의 개체에는 명시적 IL이 없으며 중간 IL이 기본값으로 사용됩니다. 중간 이외의 IL로 생성되는 유일한 개체는 낮은 IL에서 실행되는 프로세스에 의해 생성되어 낮은 IL을 가지는 개체입니다. 기본 제공되는 iCacls 도구(%SystemRoot%\System32\iCacls.exe)를 사용하여 파일의 IL을 볼 수 있고 Sysinternals AccessChk 유틸리티를 사용하여 파일, 레지스트리, 서비스 및 프로세스의 IL을 볼 수 있습니다. 그림 17에서는 보호 모드 Internet Explorer로 액세스할 수 있어야 하는 디렉터리의 IL이 낮은 수준임을 알 수 있습니다.
그림 17 사용자의 즐겨찾기 디렉터리의 IL이 표시된 AccessChk (Click the image for a smaller view)
그림 17 사용자의 즐겨찾기 디렉터리의 IL이 표시된 AccessChk (Click the image for a larger view)
개체에 명시적 IL이 있는 경우 해당 IL은 개체 보안 설명자의 SACL(시스템 액세스 제어 목록)에서 Windows Vista의 새로운 액세스 제어 항목(ACE)인 레이블 ACE에 저장됩니다(그림 18 참조). ACE의 SID는 개체의 IL에 해당하며 ACE의 플래그는 개체의 무결성 정책을 인코딩합니다. Windows Vista 이전에는 SACL에 감사 ACE만 저장되었으며 이 경우 "감사 및 보안 로그 관리" 권한(SeSecurityPrivilege)이 필요했지만 읽기 권한(READ_CONTROL) 액세스만 있으면 레이블 ACE를 읽을 수 있었습니다. 프로세스가 개체의 IL을 수정하려면 개체에 대한 소유자 변경(WRITE_OWNER) 액세스 권한과, 개체와 같거나 그보다 높은 IL을 갖고 있어야 하며 프로세스는 IL을 자신의 IL 이하로만 설정할 수 있습니다. 새로운 "개체 레이블 수정"(SeRelabelPrivilege) 권한을 가진 경우 프로세스는 해당 프로세스가 액세스 권한을 갖고 있는 모든 개체의 IL을 변경할 수 있으며 IL을 프로세스 자신의 IL보다 높게 올릴 수도 있지만 이 권한은 기본적으로 어떠한 계정에도 할당되지 않습니다.
그림 18 개체의 레이블 ACE
프로세스가 개체를 열려고 하면 커널의 SeAccessCheck 함수에서 표준 Windows DACL 검사가 수행되기 전에 무결성 검사가 수행됩니다. 기본 무결성 정책이 적용될 경우 프로세스는 IL이 개체의 IL과 같거나 높고 DACL에서도 프로세스에 액세스를 허용하는 경우에만 쓰기 액세스를 위해 개체를 열 수 있습니다. 예를 들어 낮은 IL 프로세스는 DACL에서 프로세스에 쓰기 액세스를 허용하더라도 중간 IL 프로세스를 쓰기 액세스를 위해 열 수 없습니다.
기본 무결성 정책에서 프로세스는 개체의 DACL에서 읽기 액세스를 허용한 경우 읽기 액세스 권한으로 프로세스 및 스레드 개체를 제외한 모든 개체를 열 수 있습니다. 즉, 낮은 IL로 실행 중인 프로세스가 해당 프로세스를 실행 중인 사용자 계정이 액세스할 수 있는 모든 파일을 열 수 있습니다. 보호 모드 Internet Explorer에서는 IL을 사용하여 맬웨어에서 사용자 계정 설정을 수정하여 Internet Explorer에 영향을 주지 못하도록 하고 있지만 이 방법으로 맬웨어가 사용자의 문서를 읽는 것을 막지는 못합니다.
프로세스 및 스레드 개체의 무결성 정책에는 No-Read-Up도 포함되기 때문에 예외입니다. 즉, 프로세스의 IL이 해당 프로세스가 열려고 하는 IL과 같거나 높아야 하며 DACL에서 액세스를 허용해야 열 수 있습니다. DACL에서 원하는 형태의 액세스를 허용한다고 가정할 때 그림 19에서는 중간 및 낮은 수준에서 실행 중인 프로세스가 다른 프로세스와 개체에 대해 갖는 액세스 권한을 보여 줍니다.
그림 19 개체 및 프로세스 액세스
Windows 메시징 하위 시스템도 프로세스가 일부 정보용 창 메시지를 제외한 모든 메시지를 높은 IL의 프로세스가 소유한 창으로 보내지 못하도록 하는 방법으로 무결성 수준을 고려하여 UIPI를 구현합니다. 이를 통해 표준 사용자 프로세스가 권한 상승된 프로세스의 창에 입력을 전달하거나 내부 버퍼 오버플로를 트리거하는 잘못된 형식의 메시지를 전송하여 권한 상승된 프로세스에 문제를 일으키는 것을 방지할 수 있습니다. 프로세스는 ChangeWindowMessageFilter API를 호출하여 추가 메시지가 보호를 통과하도록 선택할 수 있습니다. 또한 UIPI는 창 후크가 높은 IL 프로세스의 창에 영향을 주는 것을 차단하여 예를 들어 표준 사용자 프로세스가 관리 응용 프로그램 등에 사용자가 입력하는 내용을 기록할 수 없도록 합니다.
권한 상승 및 보안 경계
UAC 권한 상승은 편리하게 이용할 수 있는 기능이지만 보안 경계는 아니라는 점을 인식해야 합니다. 보안 경계가 되려면 경계를 통과할 수 있는 항목이 보안 정책에 명시되어야 합니다. 사용자 계정의 경우 특정 사용자가 다른 사용자의 권한이 없으면 해당 사용자의 데이터에 액세스할 수 없기 때문에 Windows의 보안 경계에 속합니다.
권한 상승은 보안 경계가 아니기 때문에 시스템에서 표준 사용자 권한으로 실행 중인 맬웨어가 권한 상승된 프로세스를 악용하여 관리 권한을 획득할 수 없다는 점을 보장하지 못합니다. 예를 들어 권한 상승 대화 상자는 권한 상승될 실행 파일만 식별하며 해당 파일을 실행했을 때 어떤 작업을 하는지에 대해서는 아무것도 표시하지 않습니다. 실행 파일은 명령줄 인수를 처리하고, DLL을 로드하고, 데이터 파일을 열고, 다른 프로세스와 통신합니다. 맬웨어가 이런 작업을 악용하여 권한 상승된 프로세스를 공격하고 관리 권한을 얻을 수도 있습니다.
낮은 IL 샌드박스 다루기
보호 모드 Internet Explorer는 낮은 IL에서 실행되어 프로세스를 감염시킬 수 있는 맬웨어 주위에 경계를 만듭니다. 이를 통해 맬웨어가 사용자 계정 설정을 변경하고 자동 시작 위치에 자신을 설치하는 것을 방지합니다. Sysinternals PsExec 유틸리티를 -l 스위치와 함께 사용하면 샌드박스를 탐색하기 위해 임의의 프로세스를 낮은 IL에서 실행해 볼 수 있습니다. 그림 B에서는 낮은 IL에서 실행 중인 명령 프롬프트가 중간 IL을 가진 사용자 임시 디렉터리에 파일을 만들 수 없지만 낮은 IL을 가진 Internet Explorer 임시 디렉터리에는 만들 수 있는 것을 볼 수 있습니다.
그림 B 명령 프롬프트는 비슷한 IL에서만 파일 생성 가능 (Click the image for a smaller view)
그림 B 명령 프롬프트는 비슷한 IL에서만 파일 생성 가능 (Click the image for a larger view)
권한 상승된 AAM 프로세스는 AAM 사용자의 표준 권한 프로세스와 같은 사용자 계정에서 실행되며 사용자의 프로필을 공유하기 때문에 공격에 특히 취약합니다. 사용자 프로필에 등록된 확장을 로드하고 설정을 읽는 응용 프로그램이 많기 때문에 맬웨어에 권한 상승의 기회가 제공될 수 있습니다. 예를 들어 일반적인 제어 대화 상자는 사용자의 레지스트리 키에 구성된(HKEY_CURRENT_USER 아래) 셸 확장을 로드하기 때문에 맬웨어는 자신을 확장으로 추가함으로써 해당 대화 상자를 사용하는 권한 상승된 프로세스에 로드되도록 할 수 있습니다.
표준 사용자 계정에서 권한 상승된 프로세스도 공유된 상태 때문에 공격받을 우려가 있습니다. 로그온 세션에서 실행 중인 모든 프로세스는 Windows가 이벤트, 뮤텍스, 세마포 및 공유 메모리를 저장하는 내부 네임스페이스를 공유합니다. 권한 상승된 프로세스가 프로세스 시작 시 특정 공유 메모리 개체를 열고 읽으리라는 것을 맬웨어가 알고 있으면 맬웨어는 버퍼 오버플로를 트리거하여 권한 상승된 프로세스에 코드를 삽입하는 내용의 개체를 만드는 것이 가능합니다. 이러한 유형의 공격은 비교적 복잡하지만 그 가능성만으로도 OTS 권한 상승이 보안 경계가 아니라는 점을 보여 줍니다.
기본적으로 권한 상승은 기본적으로 표준 사용자 권한으로 실행하기 위해 관리 권한에 액세스하고자 하는 사용자의 편의를 위해 도입된 기능입니다. 보다 견고한 보안 경계를 필요로 하는 사용자는 편리함을 포기하고 일상 작업에는 표준 사용자 계정을 사용하고 관리 작업을 수행할 때는 빠른 사용자 전환(FUS)을 통해 전용 관리자 계정으로 전환하는 방법을 선택할 수 있습니다. 반면 보안 대신 편리함을 원하는 사용자는 제어판의 사용자 계정 대화 상자에서 시스템 UAC를 해제할 수 있습니다. 이 경우에는 Internet Explorer의 보호 모드도 해제된다는 점을 알아 두어야 합니다.
결론
표준 사용자로 실행하면 시스템을 우발적 또는 의도적 손상으로부터 보호하고 시스템을 공유하는 사용자의 무결성과 데이터를 인증되지 않은 액세스로부터 보호할 수 있다는 점을 비롯한 다양한 이점이 있습니다. UAC의 다양한 변경 사항과 기술은 Windows 사용 모델에 큰 변화를 가져올 것입니다. Windows Vista를 통해 Windows 사용자는 처음으로 대부분의 일상 작업과 대부분의 소프트웨어를 표준 사용자 계정으로 실행할 수 있게 되었으며 이제 많은 회사들이 표준 사용자 계정을 배포할 수 있게 되었습니다.
