UAC( User Account Control)

Windows Vista를 공부하기 시작한지는 얼마되지 않았지만 지금까지 훑어본 바로는 개발자에게 제일 먼저 영향을 끼칠만한 것이 바로 새롭게 등장한 UAC 보안 모델일 것으로 보인다. 이것때문에 개발 패턴이 변경될 것으로 보이고 나아가서는 분명 프로그램 사용에 있어서 지금까지와는 다른 사용자 경험을 제공하게 될 것이다.

해서 이번 포스트에서는 UAC를 알아보고 결국 이녀석으로 인해 개발과 배포에 변화가 생기게 될텐데, 아직 직접 테스트는 해 보지 못한 상태이지만 그래도 컨셉적으로나마 그 가이드를 정리해 보고자 한다.

■ UAC가 뭣이여

이것은 무슨 컨트롤이여. 윈도우 컨트롤이여, 웹 컨트롤이여. 아니란다. 윈도우, 웹 컨트롤의 컨트롤은 이름씨(명사)인 반면  UAC의 컨트롤은 움직씨(동사)이다. 얼른 떠오르는 단어로 "제어"정도로 이해하면 될 것 같다. 즉 User Account Control은 "사용자 계정을 제어한다"로 해석할 수 있을 것 같다.

Windows Vista에서는 실행되는 프로그램의 권한을 이전보다 훨씬 제한하고 있다. 권한 제한의 방안으로 현재 로그온되어 있는 모든 사용자를 일단 기본적으로 일반 사용자로 간주한다. 기본적으로 로그온한 관리자를 바라보는 관점이 이전의 버전과는 다르게 설계되었다는 것이다. 실제로는 Administrators에 속한 관리 사용자더라도 일반 사용자로 간주한다. 만약 프로그램이 관리자 권한이 필요한 작업을 하려고 하면 명시적으로 사용자의 허락을 받고 나서 관리자 권한으로 작업을 진행해나간다.

로그온한 사용자가 Administrators에 속하지 않은 Users 그룹에 속한 사용자인경우라고 해도 관리자 권한이 필요한 작업을 못하는 것은 아니다. Vista는 일반 사용자라면 Vista는 관리자 계정을 묻는 보안 상자창을 띄운다. "네가 알고 있는 관리자를 한 사람 대봐라. 그럼 널 믿겠다"는 것이다.

Vista에 포함된 UAC의 목표는 다음처럼 정리할 수 있겠다.

첫번째, 로그온한 사용자를 모두 표준 사용자로 간주한다.

두번째, 사용자로부터 명시적인 권한 승격을 확인받는다. 사용자 계정으로 프로그램을 실행하다가 관리자 권한을 필요로 한다면 Vista는 사용자에게 보안 대화 상자를 띄운다. 만약 그 사용자가 Administrators그룹에 속하면 "동의 확인"창을 띄우고 Users 그룹에 속하는 사용자에게는 권한 승급관리자 계정을 묻는 대화 상자를 띄운다.

   

[그림]Consent Prompt

[그림] Elevation Prompt

동의 확인 창은 오퍼레이션이 Windows 속한 것이냐 아니면 외부의 프로그램 인스톨이냐에 따라 다른 색을 갖는 창이 뜬다. OS용 애플리케이션인 경우는 녹색, 외부 3rd 파티 애플리케이션 중에서 디지털 서명이 된 신뢰할 수 있는 애플리케이션인 경우는 파란색, 디지털 서명이 된 신뢰할 수 있는 애플리케이션인 경우는 오렌지색의 창이 뜬다.

OS 애플리케이션 : 녹색- Windows 디지털 서명된 신뢰할 수 있는 APP
3rd Party: 파란색 - 디지털 서명, 신뢰할 수 있는 APP
3rd Party: 오렌지 - 디지털 서명 & 신뢰할 수 없는 또는 디지털 서명되지 않은 APP

세번째 UAC의 목표로는 애플리케이션 호환성을 지원한다는 것이다. XP에서 실행되던 것이 권한이 없다고 해서 멈추도록 하는 것은 UAC의 의도가 아니다. 이전에 실행되던 것은 Vista에서도 실행될 수 있는 호환성을 지원한다. 이런 호환성을 위한 조치는 앞으로 나올 Vista 버전에서는 차츰 없어지게 될 것이다. 따라서 앞으로 개발되는 프로그램은 이런 호환성에 의존하기 보다는 완전히 UAC가 목표에 부합하도록 설계 개발해야 할 것이다. 이렇게 OS차원에서 제공되는 권한 제어 메커니즘을 UAC라고 할 수 있겠다.

이 UAC는 사용자에게 새로운 UX(User Experience)를 요구한다. 즉 프로세스의 권한이 승급(이것을 elevate, elevation이란 단어로 표현한다)되어야 하는 경우 사용자는 보안 대화창을 만나게 된다. 따라서 UAC는 개발자에게 보다 효율적인 UX를 목표로 하는 새로운 프로그램 설계를 요구한다. UAC가 작동하는 원리를 잘 알면 어떻게 프로그램을 개발해야 하는지에 대한 답이 좀 더 쉽게 이해될 수 있을 것이다.

■ UAC 작동 아키텍쳐

관리자가 로그온하게 되면 이전 버전의 Windows에서는 로그온 프로세스 과정에서 하나의 액세스 토큰을 생성한다. 이 액세스 토큰에는 Windows 접근 권한과 관리자의 보안 ID등 권한과 보안 관련의 대부분의 정보를 포함하게 된다. 이 액세스 토큰은 관리자로 하여금 애플리케이션을 인스톨하고 OS 환경 설정을 수행하고 그리고 PC의 어떤 리소스에도 접근할 수 있도록 해준다.

그러나 UAC를 지원하기 위한 액세트 토큰은 전혀 다른 구조로 설계되었다. Vista에서는 Split Access Token(분리된 접근 토큰)을 사용한다. 이 토큰은 말 그대로 두개로 분리되어 있다. 하나는 일반 사용자용 토큰이고 다른 하나는 완전한 권한을 가질 수 있는 관리 사용자용 토큰이다. 일반 사용자 토큰은 관리자 권한이 제거된 권한이라고 해서 영어로 하면 filtered token이라고도 하고 관리자 권한과의 연결되어 있다고 해서 linked token이라고도 한다. 그리고 완전한 관리자 권한을 나타내는 토큰을 unfiltered token 또는 full access token이라고도 한다.

이제 split access token 개념을 이용해서 프로세스의 권한 승급이 일어날때까지의 과정을 정리해본다.

1. 관리 사용자 로그->split access token

[그림] Split Token 생성

관리 사용자가 로그온을 하게 되면 그림처럼 두개의 토큰을 갖는 split token을 생성하고, 사용자에게는 일반 사용자 토큰을 부여한다. 사용자가 관리자 권한이 필요한 프로세스를 시작하게 되면 elevation이 발생하게 된다.

2. elevation 발생

[그림] elevation 발생

사용자가 Time Zone을 변경하거나, 폰트를 인스톨하는 등의 일반 사용자 작업을 하는 경우는 일반 사용자 토큰을 사용한다. 그러다가 관리자 권한이 필요한 작업을 하게 되면 그제서야 관리 사용자 토큰을 사용한다.  elevated된 프로세스가 다 끝나고 나면 다시 일반 사용자 권한을 갖는 컨텍스트로 변경된다. elevated된 프로세스는 제한된 access token이 아닌 full token을 사용하게 된다. Elevation은 elevated되지 않은 상태에서 elevated된 프로세스를 구동하는 것을 말한다. 즉 elevation은 elevated되지 않은 프로세스가 elevated될때를 말한다. 주목할 것은 실행되고 있는 프로세스가 elevated되지는 않는다는 것이다. 현재 실행되고 있는 애플리케이션의 권한을 변경할 수는 없다. 하나의 프로세스는 그 일생동안 동일한 권한 토큰을 갖는다. elevation은 항상 새로운 프로세스 생성이 필요하다. 결국 elevation은 프로세스 단위로 일어난다는 것이다.

하나 더 언급하고 지나가자면, 기본적으로 프로세스는 부모 프로세스의 권한 토큰을 갖게 된다는 것이다. 그래서 만약 새로운 프로세스가 elevated된 프로세스에서 생성되면 그 새로운 프로세스는 elevated된 상태가 될 것이고 부모 프로세스가 elevated되지 않은 프로세스라면 새로운 프로세스도 기본적으로 elevated되지 않는다.

■ When to Elevate

개발자는 프로세스 elevation이 일어나지 않도록 프로그램을 설계하는 것이 중요하다. 일반 사용자용 프로그램인데도 실행시킬때마다 확인창이 뜨거나 관리자 계정을 넣으라는 창이 뜨면 UX에 좋을 것은 없다. 권한 승급이 일어나게 되는 경우를 이해하고 elevation이 필요한 경우는 되도록이면 관리자 전용 프로그램으로 별도로 분리하여 제작하는 것이 맞을 것이다. 해서 개발 프로그램이 elevation이 일어나는 경우가 몇가지 있는데 이를 정리해본다.

1. 메너페스트를 사용하여 애플리케이션을 Admin용으로 설정한다.

2. 인스톨러 감지

3. 애플리케이션 호환성 메커니즘

4. 오른쪽 클릭->"Run as adminitrator"

애플리케이션에는 메너페스트(어셈블리에 포함된 XML 파일)를 포함하고 있는데, 거기에 애플리케이션을 Admin용 애플리케이션이라는 표시를 둘 수가 있다. 그런 애플리케이션을 실행시키면 elevation이 발생하는 것이다. 또한 Vista에는 애플리케이션이 인스톨러 예를 들어 Setup.exe 이거나 또는 인스톨러 API를 사용하는지를 감지할 수 있는 기능이 있다. 인스톨러로 감지된 경우 해당 애플리케이션 실행에서 elevation이 발생한다. 애플리케이션이 인스톨을 하지만 권한이 elevated될 필요가 없는 경우는 관리자 권한이 필요없다는 표시를 메너페스트에 추가할 수 있다. 기존의 레커시 애플리케이션을 실행시켜야 하는 경우, Vista의 애플리케이션 호환성 메커니즘은 특정 애플리케이션에서는 elevation이 필요하다는 것을 인식할 수 있다. 그리고 사용자가 윈도우 탐색기에서 애플리케이션 파일을 오른쪽 클릭해서 "Run as administrator"를 선택함으로써 명시적으로 관리자 권한으로 애플리케이션을 실행시킬 수도 있다.  

■ 개발 가이드

일반 사용자 계정으로도 애플리케이션이 잘 실행되도록 하는 것이 가장 최선의 개발 방법이다. 그러나 애플리케이션 인스톨같은 경우 반드시 관리자 권한이 필요한 경우도 있다. 사정이 이러니 관리자 사용자와 일반 사용자가 사용할 코드를 분리해서 개발하는 것이 UX의 질을 높이는 것으로 보고 있다.

■ 배포 가이드

Program Files 디렉토리나 레지스트리에 대한 접근은 관리자 권한이 필요하다. 이런 리소스에 접근해야 하는 애플리케이션의 인스톨은 관리자 권한으로 한다고 치더라도 그러나 업데이트가 있을때마다 사용자에게 보안 상자창을 띄우게 되면 사용자는 별로 달가와하지 않을 것이다. 특히 게임같은 것은 실행시킬때마다 업데이트가 일어날텐데...!

따라서 UAC팀에서는 MSI3.1 이상버전을 이용해서 인스톨과 업데이트를 할 것을 권하고 있다. MSI3.1은 관리자 권한으로 인스톨된 애플리케이션의 경우는 elevation없이 일반 사용자 계정으로도 업데이트가 된다.

그리고 .NET2.0부터 가능했던 ClickOnce은 훌륭한 해결책이다. 애플리케이션을 하나의 PC에 사용자 단위로 인스톨시키는 ClickOnce기술은 업데이트도 자동으로 수행한다.

■  마무리 소감

대충 큰 이야기는 잡혔지만 아직도 UAC와 관련해서 세부적인 내용은 공부할 게 많은 것 같다.  개발자로서 UAC에 적합한 개발 가이드나 노하우는 직접 코딩을 하면서 몸으로 익히는 것이 최선일 것 같다.

참고 링크

Windows Vista 개발자를 위한 정보: 검색 및 구성

Top 10 Ways to Light Up Your Windows Vista Apps