실버라이트에서의 Cross domain 해결

실버라이트도 웹 클라이언트 기술이기 때문에 클라이언트측의 웹 브라우저의 보안 샌드 박스에서 실행된다. 또한 웹 사이트 접근 제한 정책에 영향을 받는다. 그중의 하나가 하나가 바로 Cross-domain 접근 제한이다.

이게 뭐냐면, 한 domain에서 호스팅이되고 있는 웹 애플리케이션이 다른 domain에서 호스팅되고 있는 애플리케이션에는 기본적으로 접근할 수 없다는 것이다.

그러나 웹 애플리케이션에서 특정 도메인으로부터의 접근을 허용해주는 방법이 있다. cross-domain 정책 파일로 알려진 xml 파일을 이용하면 이런 접근에 대한 제한을 해제할 수 있다.

clientaccesspolicy.xml

crossdomain.xml

서비스를 제공하는 웹 애플리케이션에서 cross-domain 접근 제한을 해제해 주기 위해서, 이 두 파일을 어떻게 이용하는지 위 링크의 비디오에서 설명해준다.

다운로드 : How to Use Cross Domain Policy Files With Silverlight ajax 애플리케이션에서의 cross domain 해결
http://greatkim91.tistory.com/107 ( 원문 : http://snook.ca/archives/javascript/cross_domain_aj/ )

.NET Security Blog

이 블로그의 주인이 어떤 사람인지는 모르겠지만, 이 포스트들을 읽다 보면 재밌다. 그래서 자주 들러보는 블로그중의 하나다.
이번에도 이 블로그에 올라온 글을 하나 메모해 두려 한다.

CLR v4 Security Policy Roundup

.NET Security Blog에서 있는 포스트이다.

Tying your IE Hosted Control to a Manifest

I talked about the Orcas feature which allows you to provide a manifest to elevate your control's permissions declaratively.  We also saw how to generate manifests that would state what permissions your control needs (and the rules associated with those manifests).  Now it's time to tie it all together and create an HTML page that has a control and its associated manifests.

Manifests for IE Hosted Controls

 how to generate manifests that would state what permissions your control needs (and the rules associated with those manifests).

Specifying Permissions for IE Controls in Orcas

Granting managed controls hosted in IE extra permissions.  If you need to have a managed control run above its default grant set, the process getting this working in .NET versions through .NET 2.0 was relatively painful. ...

Vista는 보안을 위해서 새로운 보안 모델을 내놨고 따라서 이전 Windows에서는 관리자 계정으로 로그온만 하면 잘 실행되던 프로그램이 이제는 관리자로 로그온하더라도 권한 부족으로 실행에 실패할 상황에 처하게 되었다. 따라서 Vista는 실행 권한이라는 측면에서 이전 프로그램과의 호환성을 해결할 필요가 있게 되었다. 앞 포스트에서는 개발자가 UAC의 토큰 판단에 영향을 미칠 수 있는 방법에 대해서 알아봤다. 개발자에게는 그것이 중요한 내용이라 본다. 이제 이 포스트에서는  UAC가 권한 상승을 스스로 판단하는 기능 그리고 어떻게 레거시 프로그램들과의 호환성을 지원하고 있는지에 대해서 알아보겠다. 여기서 다룰 것은 다음 3가지를 포함한다.

▶Vista의 인스톨러를 자동 인식하는 기능

▶PCA(Program Compatibility Assistant)

▶Application Compatibility DataBase

■ 인스톨러를 인식할 수 있는 Vista

대부분의 인스톨러 프로그램은 관리자 권한이 필요하다. 인스톨러들은 Program Files 또는 HKEY_LOCAL_MACHINE\SOFTWARE 또는 HKEY_LOCAL_MACHINE\SERVICES에 또는 Windows\System32에 뭔가를 쓰려고 한다. 그러나 일반 사용자들은 이곳에 접근해서 쓸 수 있는 권한이 없다. 그래서 이런 작업을 필요하는 프로그램을 그냥 아무 생각없이 실행시켰다가 실패하도록 놔 두는 것보다는 UAC는 다른 어플리케이션을 인스톨시키는 작업을 하려는 어플리케이션을 실행시키려고 하는 때를 추측해서 잡아내서 사용자에게 권한 상승을 동의하겠냐고 묻도록 만들어졌다.

근데, 인스톨러를 감지해내는 근거가 어떤 수학적인 계산 근거가 아닌 경험적인 근거를 바탕으로 하고 있다. 그 근거나 "추측(guess)"이라는 것이다( 컴퓨터 업계에서 "추측"이 근거가 되다니 !  그러나 그렇다.) 그 추측은 2가지를 통해서 이뤄진다. 하나는 인스톨러 프로그램의 실행(EXE) 파일의 이름이 "setup", "install", 또는 "update" 같은 단어를 포함하고 있으면 UAC는 동의 확인 창을 띄운다. 만약 누군가 "setup.exe"를 "apple.exe"로 변경해서 실행시킨다면 물론 권한 상승용 동의 확인 창이 뜨지 않을 것이다. 그러나 Program Files, System32 또는 레지스트리에 뭔가를 쓰려고 하면에러가 발생할 것이다. 다른 하나는, 인스톨 프로그램을 만드는 프로그램으로 가장 널리 알려진 Wise 또는 Installshield 인스톨러로 만들어진 프로그램으로 인식하게 되면(이런 상용 프로그램을 만들어진 인스톨 프로그램은 인식하기가 매우 쉽다고 한다.) UAC는 동의 확인 창을 띄우게 된다.

■ PCA(Program Compatibility Assistant)

이 기능은 인스톨 프로그램을 스스로 인식할 수 있는 기능이 "추측"을 근거로 하는 것이라면 이 방법은 그 추측 결과들을 기반으로 해서 좀더 "합리적"인 Vista의 지원이다(그런가...달봉이한테는 그런 것 같다).  Vista는 단순히 인스톨 프로그램을 실행시킬뿐만 아니라 나름대로의 진보된 추측을 하게 된다. 인스톨 프로그램이라면 그 프로그램이 어떤 것을 인스톨했는가에 대한 기록을 남겨야 한다. 그래서 나중에 제어판의 "프로그램 추가/제거"를 통해서 어떤 프로그램이 인스톨되었는가에 대한 기록을 볼 수 있게 되는 것이고 그리고 다시 그것을 어떻게 제거할 것인가를 알 수도 있게 되는 것이다. Vista는 어떤 인스톨 프로그램이 잘 실행이 되지 않았다고 추측을 하게 되면 "Program Compatibility Assistant"라 불리는 대화창을 띄운다.

[그림] Program Compatibility Assistant

이 대화창은 사용자에게 이런 표현을 하고 있는 것이다:"내가 보기에는 뭔가 의심스러운데 제대로 설치된 것 맞니? 원한다면 내가 권장하는 다른 방법으로 다시 설치해보지 않을래?" 사용자가 다시 설치하겠다고 허락을 하게 되면 어떤 일이 일어나는 것일까. Vista가 무슨 일을 하는지를 알아보려면 이전에 보았던 "호환성"탭을 보면 된다.

[그림] 호환성 탭의 내용

이 호환성을 탭을 사용하면 이전 Windows 프로그램들의 많은 일반적인 문제들을 손쉽게 빨리 해결할 수 있다. 예를 들어 어떤 프로그램은 Windows 95, XP SP2처럼 특정 OS와 관련된 정보를 하드 코딩했을 수 있다. 만약 그런 경우라면 "이 프로그램은 Windows 95에 맞게 실행시켜라"라는 선택을 함으로써 Vista에서도 실행될 수 있도록 할 수 있다. 또한 Vista의 데스크톱에게 스크린의 해상도와 관련된 내용들을 이전 프로그램에 맞도록 지정해 줄 수도 있다.

프로그램을 인스톨하다가 실패하면 PCA는 호환성 탭에 설정된 내용에 대해서 약간 똑똑한 추측을 하게 되는 것이다. 즉 PCA 대화창은 "내가 생각하기에는 이런 설정으로 인스톨을 하면 될 것 같은데, 어떻게 함 다시 해 보시것습니까~~"라고 묻는 것이다.

이 대화창에서 설정된 내용은 레지스트리에 저장되도록 설계되어있다. 그래서 해당 프로그램을 실행시킬때마다 묻지 않는다. 다음 키에 프로그램 목록을 저장한다.

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlas\Comptability Assistant\Persist

이 키 하위에 REG_DWORD타입의 엔트리를 만들고 EXE 실행 파일에 대한 풀 경로를 그 엔트리 이름으로 한다. 만약 호환성 탭에서 선택한 옵션들이 있다면 다음 키에 저장된다.

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlas\Layers

호환성 탭에는 "관리자 권한으로 이 프로그램 실행"이라는 체크 박스도 있는데 이것을 체크해 두면 다음 실행부터는 권한 상승 동의 확인창이 뜨게 된다. 호환성 탭을 통한 권한 수준 설정은 해당 프로그램 복사본에만 해당한다. 즉 그 프로그램을 다른 폴더로 복사해서 다른 설정을 할 수도 있다는 것이다. 메너페스트 파일을 프로그램에 추가하게 되면 그 프로그램이 어떤 위치에 있던 상관없이 그 권한 수준 설정이 적용되는 것과는 대조적이다.

■Application Compatibility Toolkit "Shim"

앞에서 본 PCS기능은 기본적으로 지금 설명할 Application Compatibility Toolkit의 라이트 버전이라고 볼 수 있다. Vista에는 "shim"이라는 것이 있는데 이것은 프로세스의 권한 상승을 요청하는 Vista의 마지막 요소이다.  "shim"은 Application Compatibility Toolkit라 불리는 것이 생성하게 된다. 앞에서 알아본 PCA는 Vista와 호환성의 문제를 갖는 프로그램들의 EXE 파일들에 대해서, 어떤 특정 환경에서 대화창을 띄워서 호환성 탭의 설정 내용을 수정하도록 하기 위해서 몇가지 규칙을 따른다. 현재 버전의 프로그램이 불편은 하지만 그렇다고 업그레이드하고 싶지는 않고 그래서 약간의 설정만으로도 내 필요에는 충분한 경우 PCA를 사용하는 것은 괜찮은 일이다. 그러나 호환성을 위해서 설정을 배포해야 하는 컴퓨터들이 수백, 수천대에 달하고 또한 호환성 탭에서 제공하는 옵션들보다 훨씬 많은 내용의 설정들을 적용할 필요가 있다면 어떻게 해야 하나.

이때 필요한 것이 ACT(Application Compatibility Toolkit)이다. ACT는 "온라인 상의 해결 프로그램들(online fixes)"을 호환성의 문제를 가지고 있는 프로그램들에 적용해서 Vista와 이전의 프로그램들을 모두 만족하도록 하는 일련의 프로그램들을 말한다. "온라인상의 해결 프로그램"을 공식적으로는 "shim"이라고 부른다.

shim이라는 용어는 Application Compatibility Toolkit에서만 사용되는 용어는 아니다. 여러 버전의 CLR이 설치되어 있는 경우에 어떤 프로그램이 제작된 버전을 선택하는 경우에도 이런 shim 프로그램이 작동을 하는데 이것에 대해서는 로딩되는 CLR 버전 경정하기라는 이전 포스트에서 언급했다.

ACT의 shim은 호환성이 필요한 해당 프로그램을 위한 shim을 직접 제작해서 그룹 정책으로 중앙에서 배포한다는 점에서 호환성 탭의 shim과 다르다고 볼 수 있다. 또한 호환성 탭은 몇가지의 가능한 문제점들에 대한 해결책 옵션만을 가지고 있지만 ACT는 그 보다 훨씬 많은 문제점들에 대한 해결책을 가지고 있다.

ACT는 해결책들에 대한 데이터베이스 파일을 가지고 있는데, 그 확장자가 .SDB("System DataBase")로 되어 있는 파일들이다.  예를 들면 Vista와 함께 배포되는 sysmain.sdb이 있는데 기본적으로 \Windows\AppPatch 폴더 아래에 놓이게 된다. 그러나 그 데이터베이스 파일을 볼 수 있는 방법은 없다. 이 데이터베이스 파일에는 어디서 듣도 보지도 못한 수많은 프로그램들이 들어 있다. 따라서 sysmain.sdb가 UAC에게 어떤 프로그램의 경우에 권한 상승을 요청하는지에 대해서 이야기한다는 것은 무의미할 것이라고 본다. 여기서는 ACT라는 기능의 프로그램이 있다는 것을 이해하는 것으로서 마치도록 한다.

■ 연재를 마치면서

지금까지 UAC의 권한 상승이 일어나는 경우와 그 메커니즘들을 알아보았다. 여기까지 해서 개발자로서 필요한 UAC에 대한 개념은 어느 정도 살펴보았다고 생각한다. 그러나 UAC와 관련해서 커스터마이징을 할 수 있는 여러 내용들이 있다는 것을 알게 되었다. 필요하다면 뒤에 올 포스트에서는 이런 설정들에 대한 내용을 올려 보려 한다.

프로그램이 실행되는 도중에 권한 부족으로 프로그램이 중단되었다는 메세지는 신뢰도에 치명적이지 않을 수 없을 것이다. 그렇다면 프로그램이 시작되기 전에 관리자 권한이 필요하다는 것을 어떻게 UAC에게 알릴 것인가에 대한 것이 달봉이가 이전 포스트에서부터 기록하고 싶은 주제중의 하나이다. 그렇다고 동의 확인 창 또는 관리자 계정 요청 창이 뜨게 하지 않을 수는 없다. 관리자 권한이 필요하다면 사용자로부터의 확인을 요하는 창은 뜨게 되어 있다. 결국 개발자는 어떻게 하면 이 확인창을 뜨게 할 것인가를 고민해야 하는 것이 이 포스트들의 주요 내용이라고 할 수 있다.

앞 포스트에서는 사용자가 직접 Vista(UAC)에게 관리자 토큰을 사용하도록 하는 하는 방법에 대해서 알아봤다. 이번 포스트에서는 프로그램을 실행시킬때 UAC가 관리자 권한의 토큰이 필요하다는 것을 스스로 인식할 수 있는 방법에 대해서 알아본다. 관리자 권한이 필요하다는 것을 감지하게 되면 자동으로 권한 상승이 필요하게 되어서 사용자가 프로그램을 오른쪽 클릭해서 "관리자 권한으로 실행"을 선택하지 않더라도 동의 확인(Consent UI) 프롬프트를 보여주게 된다. 이렇게 할 수 있는 방법으로는 다음과 같은 4가지 경우가 있겠다.

▶ 개발자가 직접 실행 프로그램 EXE의 메너페스트 파일에 애플리케이션의 권한 상승이 필요하다는 사실을 표시해서 Vista에게 알려줄 수 있는 방법이 있다. 메너페스트 파일은 프로그램에 임베딩될 수도 있다.

▶ 만약 실행되는 프로그램이 어플리케이션 인스톨러라고 추측을 하게 되면 Vista는 권한 상승을 수행하게 된다. 보통 인스톨러는 보호를 받는 레지스트리나 디스크에 접근해서 쓰는 작업을 하기 때문이다.

▶ Vista의 윈도우 탐색기 또는 IE에는 PCA(Program Compatibility Assistant)라 불리는 것이 있다. 이것은 Vista이전의 프로그램을 실행하려고 하면 호환성 문제를 조사한다. 만약 그런게 발견되면 사용자에게 권한 상승이 필요한 프로그램이라는 마크를 달아둘 것인지를 묻는다. 사용자가 승인을 하게 되면 Vista이전의 그 프로그램은 권한 상승이 필요하다는 것을 레지스트리에 저장한다. 그때부터 이제 사용자가 그 프로그램을 실행시킬때마다 동의 확인 프롬프트창이 뜨게 된다.

▶ Vista에는 Application Compatibility Database라는 것을 가지고 있는데, 이것에는 권한 상승이 일어나지 않으면 실패하게 되는 과거의 프로그램들에 대한 목록이 들어 있다. 만약 사용자가 그런 프로그램들중의 하나를 실행시키면 UAC는 자동으로 동의 확인창을 띄우게 된다.

이중에서도 처음 1가지가 개발자와 직접적으로 관련된 것이고 나머지 3가지는 Vista에 내재되어 있는 자동 감식 기능이다.  이번 포스트에서는 첫번째에 대한 이야기를 정리하고 뒤의 3가지에 대해서는 다음 포스트에서 알아보도록 하겠다.

■ 권한 설정 내용을 포함하는 메너페스트를 인식할 수 있는 Vista

.NET를 공부하면서 이미 메너페스트라는 말을 많이 들어본 개발자들도 많이 있을 것이다. 어셈블리 메너페스트 그리고 ClickOnce에서는 어플리케이션 메너페스트, 배포 메너페스트등. 메너페스트라는 것은 OS에게 어플리케이션을 로딩하고 실행시키는 것에 대한 여러 정보를 알려 줄 수 있는 어플리케이션과 관련된 작은 텍스트 파일을 말한다. 그것들은 실행파일(어셈블리)에 임베딩될 수도 있고 또는 실행 파일의 외부에 별도의 파일로 존재할 수도 있어서 노트패드같은 편집기로 편집을 할 수도 있다. 메너페스트에는 많은 정보들이 있을 수 있지만 ▷해당 어플리케이션은 어떤 버전의 DLL을 필요로 하는가 ▷어플리케이션은 어떤 토큰을 필요로 하는가(일반 사용자 토큰 또는 관리자 권한 토큰)같은 사실들을 OS에 알려줄 수 있다.

원래 메너페스트는 XP에서 나타났는데, "Windows Side by Side"라는 것을 소개하면서 처음으로 메너페스트를 중요하게 사용하게 되었다. MSDN의 내용을 그대로 옮기면 다음과 같다. "Side-by-side 실행은 동일한 컴퓨터에서 여러 버전의 응용 프로그램 또는 구성 요소를 실행하는 기능입니다. 동일한 컴퓨터에서 여러 버전의 공용 언어 런타임과, 하나의 런타임 버전을 사용하는 여러 버전의 응용 프로그램 및 구성 요소를 동시에 사용할 수 있습니다" Side by Side라는 것은 이전 OS에서의 "DLL hell" 문제를 해결할 수 있는 훌륭한 방안으로 소개되었다. 버전이 다른 DLL을 함께 가지고 있어서 어플리케이션이 원하는 DLL을 사용하게 되면 문제를 해결할 수 있게 되는 것이다. 메너페스트를 OS에게 원하는  DLL의 버전을 알려줄 수 있는 수단으로 사용할 수 있는 것이다.

Vista에서도 메너페스트 파일을 관리하는 것은 여전히 Windows Side by Side에서 담당한다. 만약 메너페스트와 관련된 에러가 발생하면 Vista의 이벤트 뷰어에서 어플리케이션 폴더에 "SideBySide"라는 소스로해서 에러가 출력될 것이다.

만약 메너페스트를 EXE 또는 DLL에 임베딩시키지 않고 외부의 파일로 만든다면 다음과 같이 해서 특정 어플리케이션과 메너페스트를 연결해줘야 한다.

▷먼저 Exe 파일이 있는 디렉토리에 메너페스트 파일을 둬야 한다.

▷둘째 메너페스트 파일명은 반드시 "어플리케이션명.exe.manifest" 형태로 되어 있어야 한다.

만약 어떤 어플리케이션이 임베딩된 메너페스트와 외부의 파일로 존재하는 메너페스트를 모두 가지고 있다면 어떻게 될까. 그런 경우에는 Windows는 외부 메너페스트를 무시하고 내부 메너페스트만 사용하게 된다.

■ 기존 메너페스트 살펴보기

그럼, 지금 사용되고 있는 메너페스트를 한번 살펴보도록 하자. net.exe 프로그램에 임베딩된 메너페스트를 살펴보도록 할텐데 프로그램에 임베딩된 메너페스트를 보여줄 수 있는 프로그램이 필요하다. 임베딩된 메너페스트도 다른 리소스처럼 취급되는데 리소스 편집기를 이용해서 그 내용을 볼수 있다. 다음 링크를 따라가면 무료의 리소스 편집기를 얻을 수 있다. http://www.wilsonc.demon.co.uk 사이트를 통해서 얻을 수도 있고 "XN Resource Editor"라는 단어로 구글링해서 나오는 검색 결과를 통해서도 얻을 수 있다.

[그림] XN 리소스 편집기 실행 모습

[그림] net.exe를 로드한 XN 리소스 편집기 모습

메너페스트는 XML로 되어 있는데 지금 중요한 것은 다음과 같은 부분이다.

마이크로소프트의 명명 규칙에 익숙한 개발자들은 "requestExecutionLevel"을 "RequestExcutionLevel"로 바꾸고 싶겠지만 그렇게 하면 에러가 된다. xml에서는 대소문자를 구분한다는 것에  주의한다. 어트리뷰트 level의 값이 개발자가 관심이 있는 부분인데 이곳이 UAC에게 어플리케이션의 권한 상승이 필요한지를 알려줄 수 있는 부분이다. 이 값은 다음 3가지를 취할 수 있다.

asInvoker : 이 값을 이용하면 프로그램은 UAC에게 다음과 같은 내용을 전달하는 것으로 풀이할 수 있다:"나를 실행시킨 사용자가 가지고 있는 토큰을 그대로 사용해라" 프로그램을 로그온된 그대로의 계정을 사용해서 실행시킨면 일반 사용자 토큰을 사용하게 될 것이고 권한이 상승된 상태에서 프로그램을 실행시켰다면 관리자 토큰을 사용하게 될 것이다.

highestAvailable : 이 값은 "사용자가 가지고 있는 토큰중에서 가장 높은 권한을 토큰을 프로세스에 부여하라. 만약 필요하다면 동의 확인창(Consent UI)을 띄워서 필요한 레벨의 토큰을 구해라"라는 의미를 UAC에 전달한다.

requireAdministrator : 이것은 "highestAvailable"과 같지만 관리자 권한이 토큰이 필수적으로 필요하다는 의미이다. "사용자가 가지고 있는 토큰중에는 반드시 관리자 토큰이 있어야 한다. 그렇지 않으면 사용자에게 물을 필요도 없이 어플리케이션 실행을 그만 둬라"라는 의미이다.

마지막 두 값의 차이점은 뭘까. 하나의 토큰은 분리된 권한을 가지고 있을 수 있다. 그러나 두 토큰이 모두 관리자 권한의 토큰이 아닐 수 있다( 사실 어떻게 그렇게 될 수 있는 지에 대해서는 달봉이도 모른다.) 따라서 가장 높은 토큰을 사용한다고 해도 관리자 토큰이 아닐 수도 있다. 그래서 만약 어플리케이션을 관리자 권한의 토큰으로 실행시키고자 한다면 반드시 level="requireAdministrator"로 설정해야 한다.

프로그램을 어떤 토큰으로 실행시켜야 하는지에 대한 의도를 Vista에 알리는 메커니즘을 알았다. 그럼 이제 실제로 어떻게 하면 메너페스트 내용을 UAC가 알 수 있도록 하나. 세가지 방법이 있을 수 있다.

▶리소스 편집기로 메너페스트 추가하기

1) XN 리소스 편집기를 실행시킨다.

2) Add Resource 선택->리소스 선택창에서 "XP Theme Manifest" 선택

[그림] XN 리소스 편집기_리소스 추가

3) 기본적으로 오른쪽 창에 나타나는 코드를 선택해서 모두 지운다.

4) 오른쪽 창에 다음 코드를 붙여넣기 한다.

5) 편집된 리소스를 저장한다.

▶외부 파일로 메너페스트 정보 추가하기

두번째 방법은 훨씬 더 쉽다. "어플리케이션.exe.manifest"라는 이름으로 텍스트 파일을 만들어서 첫번째 방법에서 보여준 XML 내용을 그 파일에 옮겨놓고 저장한다. 그런 다음 그 파일을 실행파일이 있는 곳에 둔다. 그럼 Vista는 임베딩된 메너페스트 내용이 없는 경우 외부의 메너페스트 파일을 읽어서 사용하게 된다.

▶메너페스트 툴(mt.exe)로 메너페스트 임베딩하기

세번째 방법은 커맨드 라인툴을 사용해서 외부에 있는 메너페스트 파일의 내용을 EXE 어셈블리에 임베딩시키는 방법이다. 만약 이미 다른 메너페스트 내용이 있다면 기존 것을 덮어쓰게 될 것이다. mt.exe라는 커맨드 라인툴을 이용하게 되는데 마이크로소프트에서 얻거나 또는 Windows Platform SDK에 함께 배포되므로 SDK를 설치했다면 바로 사용할 수 있을 것이다.

커맨드 프롬프트 창에서 다음과 같은 형식으로 작업을 해 주면 된다.

mt /manifest 메너페스트파일이름 /outputresource:실행파일이름;#1

이 명령은 실행파일의 1번 노드의 메너페스트(앞의 XN 리소스 편집기의 좌측 창에 1번이라는 번호의 메너페스트 노드가 있다)로 지정한 메너페스트 파일의 내용을 저장한다. 커맨드의 모양이 약간 어색하기는 하지만 공백을 그대로 유지해야 한다. 예를 들어 다음과 같은 모양이 될 것이다.

mt /manifest example.exemanifest /outputresource:simple.exe;#1

이제 simple.exe 파일을 실행시킬때마다 사용자는 항상 권한 상승에 대한 동의 확인창이 뜨는 것을 경험하게 된다.

그런데 메너페스트 내용을 임베딩하는 것에는 문제가 있다.

■ 메너페스트의 강제 임베딩에 대한 문제점

만약 어플리케이션을 전자 서명했다면 문제가 된다. 어플리케이션에 전자 서명을 추가하게 되면 어플리케이션이 배포될 당시의 순수했던 코드가 나중에 어떤 악의를 가진 자로부터의 수정이 일어났는지를 확인을 할 수 있게 된다. 전자 서명된 어플리케이션에 메너페스트 내용을 임베딩하게 되면 결국 배포 당시의 코드가 외부로부터 수정되는 것과 마찬가지가 된다. 결국 어플리케이션을 실행하게 되면 Vista에서는 불평을 늘어놓고 어플리케이션은 실행되지 않게 된다.

Administrator Approval Mode의 관리자는 로그온을 하게 되면 일반 사용자 계정의 토큰을 사용하게 된다는 것은 이제 이해했다. UAC의 사정이 이러하므로 관리자 권한이 필요한 어플리케이션을 시작할때는 반드시 Windows에 관리자 토큰을 사용하도록 말해 줄 필요가 있다. 그렇지 않으면 Windows는 아무 생각없이 일반 사용자 토큰으로 프로그램을 시작할 것이고 그러다가 관리자 권한이 필요한 부분에서는 권한 부족으로 프로그램이 작동하지 않게 될 것이다. 이 포스트에서는 Windows에 관리자 토큰을 사용하도록 일러주는 방법으로서 사용자가 직접 조치를 취하는 방법을 알아본다. 그리고 다음 포스트에서는 사용자가 직접 일러주지 않더라도 Windows가 자동으로 인식해서 관리자 토큰을 사용할 수 있도록 하는 방법을 알아본다.

참고로 이렇게 관리자 토큰을 사용하게 됨으로써 사용자 권한이 관리자 권한으로 권한 레벨이 높아지는 것을 권한 상승(elevation)이라는 용어로 표현한다.

■ GUI에서 "관리자 권한으로 실행"

이 방법은 이미 이전 포스트에서 설명한 방 있다. 링크된 페이지에서는 실행할 프로그램을 cmd.exe로 했지만, 다른 프로그램들에도 해당하는 일반적인 방법이다.  링크 페이지에서 봤던 것은 사용자가 직접 실행파일을 오른쪽 클릭해서 나타나는 메뉴중에서 "관리자 권한으로 실행"을 선택하는 방법이다.

■ 커맨드창에서 "관리자 권한으로 실행"

이 방법은 커맨드 프롬프트창에서 RunAs 명령어를 사용해서 해당 프로그램을 관리자 권한으로 실행시킬 수 있다. 다음과 같은 형식으로 실행하면 된다.

"runas /user:<UserName> 프로그램"

암호를 입력하면 관리자 권한으로 프로그램이 실행된다.

■ 간단한 권한 상승 팁

만약 어떤 프로그램을 관리자 권한으로 실행시켜야 하는 경우가 많다면 매번 오른쪽 클릭해서 "관리자 권한으로 실행" 메뉴를 선택하는 것이 번거로울 수도 있다. 다음은 이런 경우 오른쪽 클릭을 하지 않더라도 바로가기를 클릭할때마다 관리자 권한으로 실행할 수 있는 방법이다.

1. 시작 메뉴의 오른쪽 클릭

2. "탐색" 클릭

3. "프로그램->보조프로그램"폴더를 선택

4. 오른쪽 클릭->새로만들기->바로가기 선택

5. "항목 위치 입력"란에 cmd.exe 프로그램을 찾아서 경로를 입력한다( "C:\Windows\System32\cmd.exe" )

6. 바로가기에 대한 이름을 "관리자 권한의 명령 프롬프트"라고 입력한다.

7. 생성된 바로 가기를 오른쪽 클릭해서 속성창을 띄운다.

[그림] "관리자 권한의 명령 프롬프트"의 바로가기 속성창

[그림] 고급 속성창

이 창에서 "관리자 권한으로 실행"을 선택합니다.

8. 다음은 결과이다.

[그림] 바로가기 생성된 결과

시작->모든 프로그램->보조프로그램을 보면 그림처럼 생성된 모습을 볼 수 있다. 바로가기 링크를 클릭하면 바로 동의 확이(Consent UI)창이 뜬다.

■ 이전 Windows 어플리케이션의 권한 상승

앞의 방법은 "시작" 메뉴에 있는 모든 바로가기에 대한 것이다. 만약 특별한 EXE 프로그램에 대해서 같은 작업을 해 주려면 약간 다른 UI를 보게 될 것이다. 프로그램의 오른쪽 클릭 속성창의 호환성 탭을 선택하면 그림과 같은 창이 뜬다.

[그림] 이전 Windows 어플리케이션 속성창

"관리자 권한으로 이 프로그램 실행"을 체크하면 프로그램을 더블 클릭할때마다 관리자 권한으로 프로그램을 실행시키게 된다. 그러나 해당 계정이 아닌 다른 계정으로 로그온해서 실행하면 그 설정이 적용되지 않는다. 만약 모든 계정에 대해서 설정이 적용되도록 하고 싶다면 밑의 "모든 사용자에 대한 설정 표시"를 클릭한다. 그럼 호환성 탭 페이지와 비슷한 창이 또 뜨고 그곳의 "관리자 권한으로 이 프로그램 실행"을 체크하면 된다.

개발자라면 이 포스트의 내용보다는 다음 포스트에서 전달할 내용에 더 관심이 있을 것이다. 즉 어떻게 하면 프로그램을 실행시킬때 자동으로 관리자 권한으로 실행시킬 수 있는가에 대한 이야기다.

앞의 포스트를 요약해보면 다음과 같다. "관리자 권한이 필요한 프로그램이 권한 관련해서 에러없이 실행되도록 하려면, 1) 사용자가 관리자 계정으로 프로그램을 실행시키든지 2) 프로그램 자체가 관리자 계정으로 실행되어야 한다는 것을 Windows에게 알려줄 수 있어야 한다. 여기까지는 나름대로 깔끔한 정리이다. 그러나 구체적으로, 언제 UAC에게 언제 어떻게 관리자 토큰을 사용하라고 일러줄 수 있는지에 대한 질문들이 남아있다. 그 질문에 대한 답을 바로 들어가기 전에 이 포스트에서는 토큰(token)의 구조를 좀 더 깊게 알아보자. 어떻게 보면 프로그래밍과는 직접적인 관계는 없으나 보안과 관련된 지식으로써 알아두면 나중에라도 도움이 될 것이다.

토큰(Token)의 구조

토큰은 사용자가 로그온을 하게 되면 그 사용자를 대표해서 컴퓨터의 RAM에 자리를 잡게되는 데이터 구조를 말한다.  Vista 토큰도 이전 Windows의 토큰과 비슷한 구조로서 몇개의 항목으로 구성된다 : 사용자 이름, 사용자 그룹 멤버쉽, 사용자 권한, Windows integrity level.

[그림] 토큰 구성 요소

전문가의 눈에는 달봉이의 Windows 보안에 대한 지식이 초보 수준일 것이다. 그러나 개발자 입장에서 토큰이 뭣이고 어떤 구조로 되어 있는가를 개략적으로나마 이해하는 것은 UAC를 이해하는 데 있어서 중요한 문제일 것이라 본다.

■ 사용자 이름 : Security ID(SID)

물론 컴퓨터 내부에서는 실제의 사용자 이름을 사용하지는 않는다. 실세계에서는 동명이인이 있을 수 있지만, Windows에서는 고유해야 하고 그것을 이름하여 Security ID 즉 SID라고 한다. 사용자나 그룹의 SID는 다음과 같은 모양으로 되어 있다.

S-1-5-21-domainID - relativeID

여기서 domainID는 사용자 계정의 위치 즉 특정 도메인이나 머신을 나타내는 96bit 숫자이고 relativeID는 그 위치에서의 특정 계정을 구분하는 숫자이다. 도메인이 생성되면 이전에도 없었고 앞으로도 없을 고유한 ID가 그 도메인에 부여된다. 그 값을 비록 있을 수 없는 숫자이지만 "12345"라고 하자. 그럼 그 도메인에 생성되는 달봉이 계정에는 다음과 같은 모양의 SID가 부여될 것이다: "S-1-5-21-12345-relativeID". relativeID는 1000부터 시작하게 되는데 첫번째 사용자 달봉이 계정이 생성되면 그 SID는 "S-1-5-21-12345-1000"이 되고 그 다음 사용자는 "S-1-5-21-12345-1001"이 될 것이다. SID를 생성하는 규칙은 좀 더 복잡하지만 하여튼 컴퓨터 관점에서는 이 SID를 통해서 컴퓨터 계정이든 사용자 계정을 구분하게 된다.

만약 달봉이가 어떤 파일이나 폴더에 대해 특별한 권한(permission)을 가지고 있다면 NTFS에는 "달봉이가 C:\dalbongstuff에 풀권한을 갖는다"라고 저장되지 않는다. 대신에 "S-1-5-21-12345-r1000이 C:\dalbongstuff에 풀권한을 갖는다"라고 표현되어 저장된다(물론 "풀권한을 갖는다"고 텍스트로 저장되지는 않는다 ^^).

가끔 보면 rights , privilages, permissions이 모두 권한으로 번역되는 문서가 있다. 대체 이것들은 어떤 차이가 있을까. 달봉이도 평소 아무 생각없이 쓰다 함 의미를 정확인 구분해 보고 싶었다. 검색을 하다가 마이크로소프트에서 해당 용어들을 정의해 놓은 페이지를 찾았다. 간단하게 요약하자면 이렇다. 우선 이 세 용어는 다음처럼 분류될 수 있다.  permissions과 User Rights로 분류되고 User Rights는 다시 Logon Rights와 Privileges로 나뉜다. Permission은 파일이나 폴더가 같은 특정 개체에 대해서 오퍼레이션을 수행할 수 있는 권한을 말하고 User rights는 컴퓨터의 특정 개체보다는 컴퓨터 전체에 영향을 미칠 수 있는 오퍼레이션을 수행할 수 있는 권한을 말한다. 그 중에서 Logon rights는 사용자 또는 보안 주체(security principals)에 대해서 어떤 로그온 방식을 제어할 것인가를 결정한다. 그리고 그 외의 사용자 권한으로 privilegs는 어떤 사용자가 컴퓨터 전체에 영향을 미칠 수 있는 리소스 조작을 할 수 있는지를 결정한다. permission은 개체를 소유하고 있는 소유자에 의해서 설정되며 그 권한 정보는 개체별로 저장된다. 반면에 User rights는 컴퓨터의 전체적인 보안 정책(security policy) 설정을 통해서 저장된다. 앞에서 소개한 링크 페이지에서 이것들에 대한 샘플 권한들을 보면 좀 더 그 차이를 알 수 있게 된다.

■ 사용자 그룹 멤버십 : SID 목록

토큰은 SID 뒤에 사용자가 멤버로 등록되어 있는 그룹들에 대한 목록 정보를 가지고 있다.

Domain-based global groups

Domain-based univeral groups

Domain-based domain local groups

Built-in local groups( Administrators, User groups)

기타 사용자가 시스템에 추가하는 로컬 그룹  등

■ 사용자 권한(Privileges) : What You Can Do

Windows는 사용자에게 파일이나 폴더같은 특정 객체에 접근해서 읽고 쓸 수 있는 권한을 허용할뿐만 아니라 컴퓨터 전체를 상태로 해서 어떤 일을 할 수 있는 권한도 부여한다. 특정 개체에 대한 권한을 permission이라고 한다면 이처럼 어떤 작업(task)를 수행할 수 있는 권한을 previlege라고 한다. 앞에서 소개한 링크 페이지를 참조하라.  이 privilege를 표현할때는 보통 문서에서는 두 가지 방식으로 표현한다. 하나는 텍스트 기반의 설명이고 다른 하나는 "SeXXX"형태의 짧은 이름이다. Vista에서는 이전 Windows에서 사용하던 privilegs 표현을 그대로 사용하고 있고, 예를 보면 다음과 같다.

SeShutdownPrivilge : 시스템을 종료할 수 있는 권한

SeBackupPrivilege와 SeResotrePrivilege : 파일, 폴더를 복사하고 복원할 수 있는 권한.

이전의 Windows에서 사용한 것을 많은 부분 그대로 이어받아서 Vista에서는 미리 정의된 34가지 유형의 privileges와 10가지의 logon rights를 정의하고 있다.  이중에서 UAC는 보안적인 측면에서 안전한 5가지 privilegs만 허용한다. 여기서는 개념적으로만 이해하고 구체적으로 어떤 privileges가 있고 그 중에서 어떤 것들이 UAC하의 사용자 계정에 부여되었는지는 다른 문서를 참고하도록 한다.

■ Windows Integrity Level

이것은 이전 Windows에서는 없던 토큰의 새로운 구성요소이다. Windows가 사용자를 "어느정도 신뢰하는가"를 나타내는 값이다. 이 신뢰도를 마이크로소프트에서는 Integrity라는 단어로 표현하고 있다. 신뢰도는 6단계로 구분되지만 UAC와 관련해서는 두 단계 "medium", "high" Windows Integrity Level만 사용된다. 일반 사용자 계정은 medium레벨을 얻게되고, 관리자는 high 레벨을 얻게 된다. SID의 표현중에서 "S-1-16-value"와 같은 부분이 Windows Interity Level을 나타내는 부분이다. 여기서 value는 medium인 경우는 8192, high인 경우는 12,288로 표현된다. Windows Integrity Level를 제어한다는 개념(WIC, Windows Integriy Control)도 Vista에서 나온 새로운 개념으로 할 말이 꽤 있는 모양이다. 

■ 사용자 토큰 정보를 알아보자.

토큰이 이런 구성 요소들로 이뤄졌다고 것이고, Vita에서는 이런 토큰을 살펴 볼 수 있는 커맨드 라인 툴을 제공해 주고 있다. 커맨드 프롬프트창을 실행시켜 다음 명령을 수행하면 내가 로그온한 후 생성된 토큰의 모양을 볼 수 있다.

whoami /user

[그림] 일반 사용자 계정의 SID 정보

사용자 계정이 속한 그룹에 대한 정보를 보고 싶다면 다음 명령어를 입력한다.

whoami /groups

[그림] 그룹 정보

그림을 보면 "Manatory Label\Meduum Manatory Level"로서  "S-1-16-8192"로 출력된다. 즉 "Windows Integrity level"이 "medium"이라는 Vista식 표현이다.  그리고 "BUILTIN\Administrators"그룹의 특성의 값이 "거부 대해서만 그룹 사용"이라고 표시되어 있다. 즉 일반 사용자 토큰으로 로그온한 경우는 "deny"인 경우만 Administrators그룹에 속한 것이다라는 얘기다. 말이 좀 이상하게 들릴지 모르지만 이 얘기는 UAC가 일반 사용자 토큰에서는 "BUILTIN\Administrators" 그룹의 멤버십을 없앴다는 얘기로 보면 된다.

사용자 권한을 알아볼 수도 있다.

whoami /priv

[그림] 사용자 권한

앞에서 본 명령을 이제 "관리자 권한으로 실행"된 프롬프트창에서 실행해본다. 그리고 그 값들을 앞에서의 결과들과 비교해 본다. Elevated된 후의 정보들이 출력됨을 볼 수 있을 것이다.

[그림] 권한 상승 후의 사용자 SID

권한 상승후 라도 현재 로그인한 사용자가 변경된 것은 아니다. 해서 이미 로그온한 사용자의 사용자 계정 정보는 변함없다.

"관리자 권한으로 실행"된 프롬프트창에서 whoami /groups를 실행시켜보면 다음과 같은 결과가 나온다.

[그림] 권한 상승후의 Windows Integrity Level 값

관리자 권한으로 명령 프롬프트창을 실행한 후를 보면 "Mandatory Label\High Mandatory Level임을 알수 있다.  그리고 "BUILTIN\Administrators"그룹에 대해서 특성값을 보면 "필수 그룹, 기본값으로 사용 가능"으로 되어 있다. 이 얘기는 "BUILTIN\Administrators"그룹의 멤버십과 권한을 복원했다고 보면 된다.

이제 다음 포스트에서는 사용자가 프로그램을 관리자 권한으로 실행하는 일반적인 방법 그리고 아마 그 다음 포스트에서는 개발자들이 프로그램을 개발할때 관리자 권한이 필요하다는 것을 Vista에게 알리도록 표시하는 방법을 알아보게 될 것이다.

달봉이는 Wndows의 보안에 대해서는 잘 모른다. 그러나 UAC를 이해하기 위해서는 기본적인 내용은 알고 있어야 할 것 같아서 이전 Windows의 보안에 대해서 간단히 정리하고 Vista의 UAC 얘기를 계속하겠다.

■ 이전 Windows의  Security Basics

이전 Windows의 보안 모델을 간단히 풀이하면 다음과 같은 그림으로 정리될 수 있을 것 같다(그림이 잘 되었는지는 누구의 검증도 안받았다 -_-;;)

[그림] Windows Security Basics

사용자가 로그온을 하면 "토큰(token)"이라는 것이 메모리에 생성된다(1). 토큰에는 사용자가 누구이며 어떤 권한을 갖는가를 정의하는 데이터 구조이며 유일한 값을 갖는다. 사용자가 로그온 후 "diary.doc"라는 워드 문서를 열겠다고  프로그램(MS Word)에 요청을 하게 되면(2) Windows는 토큰을 복사해서 프로그램에 건네준다(3). 프로그램은 다시 NTFS라는 파일 시스템에 파일을 오픈해도 괜찮겠냐고 문의를 하면(4) NTFS에서는 프로그램이 가지고 있는 토큰을 요청한다. NTFS에는 파일이나 폴더같은 자원에 대한 사용자 계정의 권한(permission) 정보를 저장하고 있다. NTFS는 건네 받은 토큰에 있는 권한 정보와 자신이 가지고 있는 리소스에 대한 권한 정보를 비교해서 프로그램의 요청의 수락 여부를 판단한다. 즉 "프로그램 당신이 건네준 토큰으로는 읽기 전용으로만 오픈할 수 있습니다."라는 결과를 건네준다. 프로그램이 NTFS에 건네준 토큰은 결국 사용자에 대한 권한을 가지고 있는 것으로서 이런 판정은 결국 사용자 권한에 대한 판정이 되는 것이다. 이런 식으로 해서 사용자가 시스템 자원에 대해서 접근 권한이 결정되는 것이다.

■ Vista에 추가된 보안 요소

"관리자 승인 모드(Administrator Approval Mode)"라 불리는 개념이 추가되었다. 이것을 풀이하자면 "승인을 얻은 후에 관리자가 될 수 있는 그런 환경" 정도가 되지 않을까 싶다. Administrators 그룹에 속한 관리자 계정으로 로그온하면 이 계정은 "관리자 승인 모드에 있는 관리자(administrator in Administrator Approval Mode)"가 되는 것이다( 말 어렵다.-_-;;;). 즉 관리자는 관리자인데 승인을 얻은 후에 관리자 권한을 얻을 수 있는 관리자라는 것이다. 평소(?)에는? 로그온 후 특별한 권한이 필요한 경우가 아니라면 일반 사용자 계정으로 실행된다.

참고로 Administrators 그룹에 속한 관리자가 아니라 기본 제공 관리자(built-in administrator)계정은 "관리자 승인 모드"의 관리자가 아니다. 이 계정은 기본적으로 활성화되지 않도록 되어 있다. 즉 사용자가 이 계정을 사용해서 로그온하지 못하도록 설정되어 있다. 그러나 설정을 변경하여 이 계정으로 로그온할 수도 있다. 그런 경우는 "관리자 승인 모드"로 로그온하는 것이 아니기때문에 이전 Windows에서 처럼 바로 관리자 계정으로 작업을 하게 된다. 그러나 Vista에서는 이 계정을 사용하지 말것을 권장하고 있다. 기본 제공 관리자 계정을 보이게 하는 방법은 이전 포스트를 참고하면 된다.

Vista에서도 이전의 Windows에서와 마찬가지로 사용자가 로그온했을때 그룹 멤버십과 권한(Privileges)을 갖는 토큰(token)과 자원(파일과 폴더등)에 대한 퍼미션(permission)정보를 비고해서 사용자 계정에 대한 권한을 판정한다. 그러나 Vista에서는 "관리자 승인 모드"를 구현하기 위해서 내부적으로 이전과는 다른 모양의 토큰(token)을 사용하게 된다. 

Vista의 토큰은 두개로 분리되어 있다. 하나는 사용자 계정을 나타내는 계정이고 다른 하나는 관리자 계정을 나타내는 토큰이다. 이로 인해서 Vista의 토큰 모델을 분리된 모델(split token)이라고 한다. 그리고 "관리자 승인 모드"의 일반 사용자 계정을 나타내는 토큰은 관리자 권한이 제거된 토큰이라고 해서 filtered token이라고 한다. 이에 비교되는 관리자 계정의 토큰은 전체 권한을 갖는다해서 unfiltered token이라고도 하고 다른 용어로는 full access token이라고도 한다.

[그림] 분리된 토큰 생성

[그림] Elevation 발생

Administrators그룹에 속한 관리자가 로그온을 하고 나면 그림처럼 일반 사용자 토큰과 관리자 토큰이 모두 생성되고 기본적으로 일반 사용자 토큰이 사용되게 된다. Time Zone을 변경하거나 일반 업무를 할때는 일반 사용자 계정의 토큰으로도 충분한 권한을 가지고 작업을 하게 된다. 그러나 사용자가 관리자 계정을 필요로 하는 작업을 하게 되면 그림처럼 권한의 상승이 필요하게 된다. 이때 UAC가 작동하게 되어 사용자에게 승인을 구하게 되는 것이다.

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

프로그램이 토큰을 갖는 것은 앞에서 알아본 것처럼 프로그램이 "시작될때"이다. 일단 프로그램이 시작되고 나면 부여받은 토큰을 변경할 수 없다. 개발자 입장에서 UAC를 이해하는  키 포인트중의 하나는, 프로그램을 시작할때  Windows에 "어떤 토큰을 사용할 지를 어떻게 알도록 해 주는가" 이다. 즉  "Windows가 사용할 토큰을 어떻게 결정하는지를 이해하면 되는 것"이다.  Windows는 다음과 같은 두가지 경우에만 관리자 토큰을 사용한다. 

1) 사용자가 직접 Windows에 관리자 토큰을 사용하도록 일러주는 경우

2) 프로그램이 관리자 권한이 없으면 안된다는 것을 Windows가 스스로 인식할 수 있는 경우.

두가지중 어떤 경우든 UAC는 사용자에게 승인창(Consent Prompt)을 보여준다. 즉 "내가 생각하기에 당신이 관리자 토큰을 사용하고자 하는 것 같은데 확실한가?"라는 표현인것이다. 사용자가 확인을 하고 계속 진행하게 되면 Windows는 프로그램을 사용자 토큰 말고 관리자 토큰을 사용해서 시작한다. 이 두가지 외에는 일반 사용자 계정을 사용한다.

그럼, 구체적으로 어떻게 1), 2)처럼 할 수 있는지 알아볼 것이다. 사용자 입장에서는 1)에 관심이 있을 것이고, 개발자라면 2)이 관심이 있을 것이다. 이 내용은 다음 포스트에서 다룬다.

요즘 허리 통증이 심해서 더이상 글을 진행하기가 힘들다. 한의원을 계속 다니기 시작했고, 오늘은 인터넷에서 디스크 환자용 의자도 구입했다.

 

실제로 앉아보면 허리에 상당히 편함을 느낄 수 있다. 하중이 무릎으로 분산되면서 허리 부담이 줄어들기때문이다. 허리 아프신 분들한테는 강력 추천이다.

UAC는 다시 한번 더 체계적으로 정리할 필요가 있을 것 같다. 뭐든지 튼튼한 기본이 중요한 법인데, UAC는 프로그래밍시 기본적으로 이해하고 있어야 하는 새로운 컨셉일 것이라는 생각에서이다. 해서 체험기부터 해서 다시 나름대로 신경써서 함 정리해보려 한다.

UAC라는 것은 머신을 제외한 모든 사람들은 싫어할 것 같은 특징중의 하나인 것 같다. 사용자도 그렇고 개발자도 그렇고 그리고 관리자도 그렇게 좋아할 것 같지는 않다. 처음에 달봉이도 상당히 당혹스러웠다. 그러나 한편으로는 개발자로서의 호기심이 발동하기도 했다. 이번 연재에서는 체험기에서부터 다시 시작해서 나름대로 UAC에 대한 필요성을 알아보고 그리고 구체적으로 개발시 어떻게 해결해야 하는지를 알아보겠다.

■ UAC 시작하기

Vista를 설치하는 것부터가 쉬운일이 아니였다. Vista 베타시절, 달봉이 집에 있는 PC중에 두 대에 일단 Vista 설치를 시도했다. 몇번을 시도했는데도 실패하고 그때는 결국 설치를 못하고 지나갔다. 그러다가 정식 버전이 릴리스되면서 다시 시도했다. 실패했다. 나중에 알고 보니 PC 사양이 부족했던 것이다. 결국 집에 있는 PC는 포기하고 좀 사양이 괜찮은 달봉이의 작업용 노트북에 Virtual PC 2007 를 설치해서 그곳에 Vista를 설치했다.

처음 Vista를 시작할때, Vista는 달봉이에게 계정을 하나 만들것을 요청한다. 새롭게 넣은 계정은 기본적으로 로컬의 Administrators그룹의 멤버로 등록이 된다. 문제는 새롭게 등록한 관리자 계정으로 로그온을 해도 관리자가 아니라는 것이다. 관리자가 아님으로 해서 발생하는 예외 상황( Vista 이전의 사고로는 분명 돌발상황이다)을 함 만들어보자.

방금 새롭게 생성한 관리자 계정으로 로그온 한 후 "시작->실행..."을 선택한다. ( 근데, 이 실행...항목이 Vista에서는 보이지 않는다. -_-;;  이 항목을 보이는 팁은 뒤에서 설명하겠다.)  우선 "실행..." 대신에 "검색 시작"항목에 cmd.exe를 입력한다.

[그림] 검색시작 항목

그런 다음 다음 명령을 실행시킨다.

net users inguen dragon /add

users 그룹에 "inguen"계정을 패스워드 "dragon"으로 생성하겠다는 내용이다. 이 명령을 실행시키면 그림과 같은 에러가 발생한다.

[그림] 사용자추가하기

액세스가 거부되었다는 것이다. 이전 버전의 Windows에서의 개념으로는 이해가 가지 않은 결과이다. 관리자가 못하는 일이 뭐가 있단 말인가. GUI 방식으로 사용자 계정을 추가해보자.  "시작->제어판"을 선택하면 사용자 계정을 추가/제거할 수 있는 메뉴를 볼 수가 있다.

[그림] 제어판-사용자 계정 추가/제거

"사용자 계정 추가 또는 제거" 옆에 방패 아이콘이 있는 것이 수상하기는 하지만, 하여튼 메뉴를 클릭해보자. 창이 하나 뜨면서 주변은 어두워진다. 창외의 다른 곳은 선택할 수도 없게 된다. 그 내용을 보면 권한이 필요하다면서 작업을 진행하려면 [계속]을 클릭하라는 것이다.

[그림] 관리자 승인 요청 창

관리자 계정으로 로그온했음에도 이 방법도 역시나 권한이 필요하단다. 그러나 커맨드 프롬프트와는 다르게 "계속"을 클릭하면 사용자 계정을 추가할 수는 있다.

두 경우가 말해주는 것은 "관리자로 로그온했지만 cmd.exe는 관리자 토큰(이것이 뭔지는 바로 뒤에서 설명한다)으로 실행되지 않고 있다"는 것이다. 뒤에 설명하겠지만 Administrators그룹에 속한 관리자 계정으로 로그온 하더라도 Vista에서는 관리자 토큰 대신에 일반 사용자 토큰을 사용하게 된다. 그러다가 관리자 계정을 필요로하는 프로그램을 실행시키면 그제서야 관리자 계정을 사용한다. 그냥 아무말 없이 사용하는 것이 아니라 Vista에서는 사용자의 허락을 득한 후에 사용하도록 하고 있다. 즉 앞의 그림과 같은 창은 사용자의 동의를 얻는 창이다. 일종의 "Are you sure?"라는 표현이다. 해서 그림과 같은 프롬프트창을 "동의 확인(consent user interface, Consent UI)창이라고 한다. 관리자 계정으로 로그온한 사용자가 동의를 하면 그제서야 프로그램을 시작한다.

여기서 중요한 포인트 한가지!

그럼 커맨드 프롬프트창에서 커맨드 라인으로 작업을 했을때는 "액세스가 거부"되었다는 메세지만 출력하고 왜 이런 동의 확인 창이 뜨지 않았을까? Vista가 사용자의 동의를 구하는 것은 프로그램이 시작되기 전이라는 것이다. 일단 프로그램이 시작되고 나면 사용되고 있는 계정의 권한을 변경할 수 없다. 일반 사용자 계정으로 시작했는데 나중에 관리자 권한을 필요로 하는 작업을 요청하면 에러가 나는 것이다.

■ 관리자 권한으로 명령 프롬프트창 시작하기

그럼 명령 프롬프트창은 관리자 모드로 시작할 수 없는 것일까?  뒤에서 프로그램을 관리자 권한으로 실행시키는 일반적인 방법에 대해서 정리가 있을 것이다. 그러나 우선 명령 프롬롬프트 창을 관리자 권한으로 실행시키는 방법에 대해서만 알아본다.

"실행..."을 이용해서는 명령 프롬프트창을 관리자 권한으로 실행시킬 수는 없다. 대신에 GUI 메뉴를 이용하면 가능하다. GUI 방식으로 실행시키려면 다음 순서를 따른다.

시작->모든 프로그램->보조 프로그램->명령 프롬프트 선택

[그림] GUI로 명령 프롬프트 시작

명령 프롬프트 메뉴를 오른쪽 클릭하면 그림처럼 "관리자 권한으로 실행"이라는 컨텍스트 메뉴가 나타난다. 그 컨텍스트 메뉴를 선택하면 관리자 권한으로 실행되는 명령 프롬프트창을 이용할 수 있다.

■ "실행..."  항목 보이기

개인적으로 달봉이는 "실행..." 항목을 자주 쓰는 편이다. 이것이 안보니까 왠지 불편한 것 같다. 이전의 Windows에서처럼 Vista에서도 이전 형식의 시작 메뉴를 사용할 수 있도록 한다. "시작->오른쪽 클릭->속성"을 선택하면 그림과 같은 창이 뜬다.

[그림] 이전 시작 메뉴 선택

단순히 그림에서 "이전 시작 메뉴"를 선택하면 된다. 그러나 Vista의 시작 메뉴를 그대로 두고 "실행" 항목이나 시스템 관리 도구등 몇개만 보이게 하고 싶은 경우도 있을 것이다. 그런 경우는 "시작 메뉴"를 선택하고 "사용자 지정..." 버튼을 클릭한다.

[그림] 시작 메뉴 사용자 지정

창에서 "실행" 항목의 체크 박스를 선택하고 그리고 "시스템 관리 도구"에서 "모든 프로그램 메뉴 및 시작 메뉴에 표시"를 선택한다. 그런 다음 확인을 하고 속성창을 닫으면 결과는 다음 그림과 같다.

[그림] 사용자 지정 결과

■  체험기 소감

UAC의 기본 컨셉은 간단하다 : 관리자 권한을 필요로 하는 작업을 하려고 할때마다 동의 확인창(Consent UI)을 띄워 관리자 권한으로 어떤 작업을 하려고 한다는 것을 확실히 알 수 있도록 해 준다는 것이다. 그러나 앞에서 본 것처럼 매번 이런 확인을 받는다는 것은 귀찮고 번거로운 일이다. 이런 첫인상은 달봉이만 그런 것은 아닐 것이다. 그럼 이런 메커니즘에는 어떤 이점이 있을까? 훌륭한 테크니컬한 이유는 없다. 추측할 수 있듯이 "보안"때문이다. 보안때문이라고는 하지만 어떻게 생각해보면 내 PC를 사용하는데 남의 허락을 얻어야 하는 듯한 기분이기도 하다. 또 어떻게 생각해보면 마이크로소프트가 보안에 대한 평판을 업그레이드하겠다는 정책에 사용자가 희생된 기분이기도 하다.

그럼에도 불구하고 UAC를 좋아하게 될 것 같다. UAC가 주는 이점을 이해하기 위해서 사용자를 두 부류로 나눠보자. 자신이 무엇을 하고 있는지를 정확히 알고 있는 베테랑 관리자와 아직 기술적으로 미숙한 사용자가 Vista를 사용한다고 해 보자. 아직 미숙한 사용자에게 UAC는 "깨어나라"라는 메세지를 전달하는 효과를 줄 수 있을 것이다. 사용자는 자신이 뭔가 시스템적으로 중요한 작업을 하려고 한다는 것을 깨닫고 한번 더 집중하게 될 것이고 되도록이면 취소를 선택해서 원하지 않은 스파이웨어의 설치를 막을 수 있을 것이다. 괜찮은 효과이다.

아주 능숙한 관리자인 경우는 어떤가? UAC가 쓸모없을까? 시스템 관리자들이라면 관리자 계정으로 로그온해서 작업하지 말라는 말을 들어봤을 것이다. 그러나 이전 Windows에서 일반 사용자 계정으로 로그온하면 얼마나 많은 제약 사항이 있는 지도 알 것이다. 권한 제약에 걸리는 순간마다 로그오프해서 다시 관리자 계정으로 로그온해서 작업을 하고 다시 사용자 계정으로 변경하고...-_-;; 아마 이렇게 작업하는 관리자는 아무도 없을 것이다. 있으려나....;;. Vista에서는 그러나 일반적인 상황에서는 사용자 계정으로 작업을 하다 관리자 권한이 필요한 경우는 "Are you sure?"에 동의만 하고도 관리자 계정으로 작업을 할 수 있다. 그리고 매일 반복되는 작업으로 인해 매너리즘에 빠져 아무 생각없이 작업하다가 실수할 일도 줄어들게 될 것이다.

어떤 이에 의하면 이제는 Windows의 문화를 바꿀 필요가 있다는 것이다. 문화나 습관을 바꾼다는 것은 쉬운 일은 아니지만 그렇다고 불가능한 것은 아닐 것이다. 유닉스쪽에서는 이미 오래 전에 이 같은 경험을 거쳤다고 한다. 처음에 루트 권한(관리자 권한)에 익숙했던 사용자들은 점차 일반 사용자 계정으로 로그온하려고 노력했다. 그러나 일반 사용자 계정으로는 실행되지 않은 유닉스 프로그램이 있었고 그래서 이번에는 유닉스 개발자들은 사용자 계정으로로 실행될 수 있는 애플리케이션을 작성할 수 있는 방법을 배워나갔다고 한다. 오늘날 유닉스나 리룩스를 사용하는 사람들은 루트 대신에 일반 사용자 계정을 사용하는데 익숙해졌고 프로그램들도 훌륭히 작동한다고 한다. 이제 Windows도 같은 변화를 경험하게 될 것이다. 그러나 그것은 가치가 있는 일이다.

다음 포스트에서부터는 좀더 UAC의 기술적인 얘기를 해 보겠다. 개발자라면 충분히 그 내부의 모습을 이해하고 있을 필요가 있을 것이다.

사용자 프로파일별 폴더와 데이터가 저장되던 "Documents and Settings"라는 폴더의 이름이 달봉이에게는 이상하게 보였는데, 이것이 없어질 모양이다. 이 폴더 역할을 하는 새로운 폴더가 Vista에서는 "사용자"라는 좀 더 그럴싸한 이름으로 생기게 되었다.

그러나  "Documents and Settings" 폴더도 완전히 없어진 것은 아니다. 내부적으로 숨겨져 있고 NTFS 퍼미션을 설정해서 "Everyone 그룹"이 "Documents and Settings"에 접근해서 읽을 수 없도록 했다. 결국 직접 "Document and Settings"폴더에 직접 접근해서 데이터를 쓰려고 하면 실패하게 될 것이다.

그럼, 이전에 "Documents and Settings"라는 폴더에 데이터를 쓰던 애플리케이션은 이제는 어떻게 해야 하나.

1. 개발자가 수정하도록 한다.

2. "Documents and Settings" 폴더를 보이도록 하고, NTFS 퍼미션을 변경한다.

3. 그냥 둔다 ^^. 그냥 두면 Vista의 파일, 폴더의 가상화 기능이 문제를 조용히 해결할 것이다.  그러나 앞에서도 말했지만 Vista의 가상화 기능은 임시기능이다.

참고로 영문 Vista에서는 "사용자"라는 폴더는 "Users"라는 이름을 갖는다.

Vista를 보면 그런 느낌을 갖게 한다. "보이는게 다가 아니다." .NET 프레임워크의 GAC 구조를 알고 있다면 이런 달봉이의 기분을 알것이다. Vista에서는 OS차원에서 가해지는 제한 및 숨기는 것이 더욱 더 많아질 것이다. 모든 것이 다 무엇때문? "Security!!"

Vista에서는 일반 사용자(Administrators 그룹에 속한 사용자 포함)는 시스템에서 보호되는 디렉토리 또는 레지스트리에 직접 쓰지 못하도록 하고 있다. 보호받는 디렉토리와 레지스트리 경로는 다음과 같다.

(%SYSTEMROOT%, %PROGRAMDATA%, %PROGRAMFILES%\(서브디렉토리)

HKEY_LOCAL_MACHINE\SOFTWARE

그럼, 기존에 이런 곳에 접근해서 데이터를 저장하고 있는 어플리케이션은 모두 사용할 수 없게 되는 것인가.

Vista에서는 "임시"로 이런 어플리케이션의 호환성을 위하여 가상화 기술을 도입하고 있다. 어플리케이션에서 보호받는 디렉토리와 레지스트리에 데이터를 쓰려고 하면 Vista에서는 런타임시 그 경로를 사용자별 경로로 자동으로 변경시켜 준다. 

%SYSTEMROOT%, %PROGRAMDATA%, %PROGRAMFILES%\(서브디렉토리)
Redirect to: %LOCALAPPDATA%\VirtualStore

HKEY_LOCAL_MACHINE\SOFTWARE
Redirect to: HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\<Application Registry Keys> 

어플리케이션에서는 보호받는 디렉토리, 레지스트리에 값을 쓰지만, 런타임시 Vista에서는 그것을 사용자별로 각자의 경로로 리다이렉트해서 그곳에 값을 쓴다는 얘기다. 다음 샘플 프로그램을 보자. 

이 프로그램을 실행하는 계정은 물론 일반 사용자 계정이라고 하자. Program Files의 물리적 경로와  "dalbong2.txt"를 결합해서 Console로 출력한다. 그 값은 다음과 같다.

[그림] 프로그램상에서 인식하는 파일 경로

Program Files 폴더에 dalbong2.txt를 생성하겠다는 것인데, 그러나 실제 파일은 이곳에 저장되지 않는다. 프로그램으로부터 이 요청을 받으면 Vista에서는 다음 경로로 리다이렉트를 해서 파일을 저장한다.

[그림] 실제 저장 경로

파일이 실제 생성된 곳의 경로는 그림에서처럼 보는 바와 같다. 일반 사용자는 Program Files 폴더에 접근할 수 없기 때문에 에러가 발생하고 Vista에서는 가상화를 통해서 사용자별로 가상 디렉토리에 파일을 생성하게 되는 것이다. 그러나 만일 실행 파일을 관리자 권한으로 실행시킨다면 실제 "C:\Program Files\dalbong2.txt"로 저장될 것이다.

가상화는 앞에서 언급한 대로 레거시 어플리케이션과의 호환성을 위해서 취하고 있는 "임시" 기능이다.  64비트의 환경에서는 이 기능은 사라진다.

그룹 정책 편집기를 실행시켜 보면 현재 내 PC에 설정된 정책 내용을 볼 수 있는데, 이곳에서 UAC 정책 설정 내용도 볼 수 있다.

"시작->검색 시작->gpedit.msc"

"로컬 컴퓨터 정책->컴퓨터 구성->Windows 설정->보안설정->로컬 정책->보안 옵션"을 선택하면 그림과 같은 내용의 UAC 설정을 볼 수 있다.

[그림] 내 PC의 UAC 정책 설정

이 설정 내용을 보면 UAC에 의해서 어떤 일들이 일어나는지를 알 수 있고 그래서 UAC 개념에 대한 이해에도 도움이 될 것이다. 다음은 각 정책을 더블 클릭했을 때 나오는 설명들로서, 몇가지 확인해봐야 하는 내용도 있지만 그대로 복사해 놓고 있다.

Administrators 그룹에 속한 관리자와 기본 제공 관리자(Built-in Administrator)는 구분된다. 기본 제공 관리자는 UAC의 적용을 받지 않는다(Administrator 여부를 체크하지 않는다기 보다는). 따라서 높은 권한을 필요로 하는 프로세스를 실행시키더라도 보안창을 띄우지 않는다. 그러나 기본 제공 관리자 계정으로 로그온하는 것은 Vista에서는 비추천이다.

하여튼, 처음 Vista를 설치해서 로그인을 하려고 하면 Administrator 계정이 보이지 않는다. 달봉이는 약간 당황했다.

[그림] 로그온 계정

Vista에서는 기본적으로 이  관리자 계정은 사용하지 못하도록 설정되어 있다. 이 계정이 나타나도록 하려면 설정을 하나 변경해야 한다.

시작->실행-> gpedit.msc (Vista에서는 검색 시작 박스를 사용해도 된다. 달봉이는 지금까지 실행 창을 사용했는데...)

관리자 승인을 확인하는 UAC 보안창이 뜨고 계속을 클릭하면, 그룹 정책을 편집할 수 있는 창이 뜬다.

좌측의 로컬 컴퓨터 정책 트리에서, 컴퓨터구성->Windows 설정->보안 설정->로컬 정책->보안 옵션을 선택하면 오른쪽에서처럼 현재 설정된 여러 정책들을 볼 수 있다.

여기서 그림에서 선택된 정책 "계정:Administrator 계정 상태" 의 보안설정 값이 기본적으로 "사용 안 함"으로 되어 있다. 정책 레코드를 더블 클릭해서 "사용"으로 선택하면 다음 로그인부터는 Administrator 계정을 로그온시 볼 수 있게 된다.

Aministrator 계정을 이렇게 하면 볼 수 있다는 것이지 Administrator 계정을 사용하라는 얘기는 아님!

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

비스타 니가 뭔데. 쫌~. 비스타로 하도 떠들썩하길래, 지금 프로젝트가 끝나기 전에 미리 함 체험해 볼 생각으로 설치해보기로 했다.
진행중인 프로젝트의 개발때문에, Windows 2003 서버도 필요했다. 자금 문제 때문에 노트북을 하나 더 구매할 수는 없고, 해서 하나의 노트북에 Virutal PC 2007을 이용해서 같이 설치하기로 했다. 처음에는 노트북의 메인 OS로 비스타를 설치했다.

처음 생각과는 달리 Visual Studio를 비스타에 설치해 보기로 했다. 그래서 왠만하면 지금 프로젝트 솔루션을 비스타에서 구성해서 계속 개발을 해 보기로 했다. 그리고 Virtual PC에는 Windows 2003을 설치해서 아직 비스타에서 실행되지 않는 프로그램들도 있다고 하니 그런 것들은 2003에 설치할려고 했다.

근데 그렇게 세팅을 해 놓고 보니 제일 먼저 막히는 것이 비스타의 윈도우 탐색기 오퍼레이팅이였다. Virtual PC의 2003과 비스타와 공유 폴더를 하나 만들어서 2003쪽에서 비스타쪽으로 파일들을 가져왔다. 그런 다음 지우려고 해 보니 어떤 확장자의 파일은 권한이 없다고 지워지지 않는 것이다. UAC(User Access Control)에 대해서 이야기는 듣고 있어서 아마 그것때문이라고 생각했다. 해서 UAC 기능을 없앨 수 있는 설정도 있으리라 생각했었다. 구글링을 해 보니 "제어판"쪽 어디에 있다고 한다. 그러나 비스타가 가장 내세우는 능력중의 하나인 이 기능을 없앨 수는 없었다.

파일 관리뿐만 아니라 비스타에서는 IIS 관리도 우선 막혔다. 평소 습관대로 시작 메뉴의 실행 명령창에 "inetmgr"를 입력하려고 했다. 근데, 시작 메뉴에 실행 메뉴가 없었다. 대신에 그곳에 검색창이 있었다. 난감했다. 근데 검색 창에다 "실행"을 입력하니 실시간으로 검색된 결과가 나왔다. 그곳에 실행 명령창 메뉴가 보였다. 그것을 실행시켜서 명령창에서 "inetmgr"을 실행시키니 그제서야 IIS관리창이 떳다. IIS관리창은 사람을 더욱더 난감하게 만들었다. 이전의 IIS관리 UI와는 상당히 달라진 관리창이 떳고....더 생각할 필요도 없이 그냥 닫아 버렸다.-_-;;

진행중인 프로젝트는 마무리 해야 하고, 개발하면서 비스타도 공부하고 IIS7.0도 공부할 수는 없었다. 아예 메인 OS를 바꾸기로 했다. 다시 메인 OS를 2003으로 바꾸고 Virtual PC에 비스타를 설치했다.

금요일 저녁부터 토요일 오후 4시까지 노트북 세팅을 몇번이나 바꿨다. 그러나 소득이 없었던 것은 아니다. Virtual PC에 OS를 설치할때의 팁, 비스타에서의 몇가지 팁도 알게 되었고,  Virtual Server도 한번 찝적거려 보게 됐다.

비스타에 처음 접하면서 느낀 소감이라하면 "공부할게 많아졌구나" 하는 거였다. UAC, IIS7.0 그리고 새로운 권한 모델에 맞도록 어떻게 애플리케이션을 개발해야 하는지도 배워야 할 것 같았다.

Virtual PC에 OS를 설치할때의 노하우 하나 메모해 둔다.

현상 1. Virtual PC에 OS를 설치하다 보면 Virtual PC 내부에서는 마우스 포인터가 제대로 말을 듣지 않는다. 마우스를 움직여도 포인터는 한 참 후에 반응을 한다. 마우스와 Virtual PC의 포인터가 동기화가 제대로 되지 않는다.

-> Virtual PC 프로그램을 보면 ...마우스 포인터를 동기화 시킬 수 있는 메뉴가 있다.

현상 2. Virtual PC로 마우스 포인터를 옮겨 놓으면 포인터가 이곳에서 빠져나오지를 못하는 것이다. Virtual PC 프로그램 메뉴를 보면, 오른쪽 Alt키 + Delete키로 마우스 포인터 전환을 할 수 있다고 하는데, 내 노트북에는 오른쪽 Alt키가 없다. Virtual PC에서 빠져나오려면 노트북의 Ctrl + Alt + Del을 눌러서 노트북을 종료할것인가 취소할 것인가 묻는 창이 뜰때 취소 버튼을 누르면 마우스 포인터가 Virtual PC에서 빠져나온다.

-> 기본 키(오른쪽 Alt키)를 변경할 수 있는 메뉴가 있다. 그게 어디 있을까~~ File->

8. 보안 요청

보호된 리소스를 직접 액세스하는 코드를 작성하거나 이러한 액세스가 호출자에게 노출되는 경우, 호출하는 코드(어셈블리)에 권한이 있는지를 확인하는 요청을 작성할 수 있다. 호출자에 의한 호출이 실제로 수행되기 전에 이런 요청에 대한 권한 체크를 먼저 통과해야 한다.  이런 권한 요청은 어트리뷰트를 사용한 선언적인 방법을 사용할 수도 있고 또는 메소드를 통해서 프로그램적 요청을 사용할 수 있다.
대부분의 .NET Framework 클래스에는 자신과 연결된 요청이 이미 있으므로 보호된 리소스에 액세스하는 클래스를 사용할 때마다 요청을 추가할 필요가 없다. 예를 들어, StreamWriter 클래스는 열릴 때마다 자동으로 FileIOPermission에 대한 보안 요청을 한다. StreamWriter 클래스를 사용할 때 FileIOPermission을 요청하면 중복된 비효율적인 스택 워크가 발생한다. 사용자 지정 리소스를 보호하기위해서 개발자는 사용자 지정 권한을 요구하는 요청을 사용해야 한다.
여기서는 자원을 보호하기 위해서 코드상에서 특정 권한을 요청할 수 있는 메소드들을 소개한다. 그러나 이 메소드들을 이해하기 위해서는 StackWalk( 호출스택) 개념이 필요하다

■ StackWalk(호출 스택)

현재 비관리형 코드에 접근하려는 메소드 AccessUnmanagedCode()가 있다고 하자. 어셈블리에 대한 권한 체크는 이 메소드가 있는 어셈블리에 대해서만 수행되는 것이 아니다. 만약 AccessUnmanagedCode()가 다른 어셈블리에 있는 코드에서 호출되고 있다면 그 어셈블리에 대한 권한도 체크를 한다. 이것은 StackWalk라는 개념의 기술을 통해서 가능하다.
StackWalk라는 것은 말 그대로 풀이해본다면 "현재까지의 걸어온 자취 즉 어셈블리의 호출을 누적해놓은 것"이다. 그리고 자취의 누적 방향은 위에서 아래 방향으로 쌓여 간다고 상상하면 된다. 그림을 보자.

StackWalk 개념(클릭을 하면 선명한 그림이 뜹니다.)

그림처럼 Demand()(뒤에서 설명한다)라는 메소드를 통해서 해당 권한이 assembly3.dll에 부여되었는지를 체크 하게 되면 현재 어셈블리에서부터 차례로 StackWalk를 올라가면서 주어진 권한을 어셈블리별로 체크하게 된다. StackWalk 상의 모든 어셈블리가 권한 체크를 통과해야만 Demand() 이후의 코드가 실행될 수 있는 것이다.

■ Demand() 메소드

어셈블리 권한 풀이기(permission  resolver)는 대부분의 시간은 그냥 잠든(?)상태에 있다. 이것이 작동을 하는 경우는 어셈블리가 로딩되는 경우 CLR에 의해서 잠에서 깨어난다. 또한 코드상에서 권한 풀이기를 직접 깨울 수도 있다. 어떤 어셈블리가 보호를 받는 자원에 접근하려고 할 때 자신(또는 자신을 호출한 어셈블리)이 적절한 권한을 부여 받았는지를 확인해 볼 수 있다. 이런 권한 체크에, IPermission에 정의되어 있고 CodeAccessPermission에서 구현하고 있는 Demand() 메소드를 사용할 수 있다. 다음 예제는 SecurityPermission을 사용해서 체크할 권한을 지정하고 있는데, 이 클래스는 CodeAccessPermission 클래스를 상속하고 있다.

AccessUnmanagedCode() 메소드는 비관리형 코드로의 접근을 시뮬레이션하고 있다. 권한 체크를 하려면 우선 적절한 권한(permission)객체를 생성해야 한다. 이 코드는 비관리형 코드(UnmanagedCode)에 대해 접근할 수 있는 권한이 있는지를 체크할 수 있는 권한 객체 SecurityPermission를 생성하고 있다. SecurityPermission 생성자가 받을 수 있는 SecurityPermissionFlg 열거형에는 다른 값들도 정의하고 있다.

이 열거형들이 생성한 권한 객체는 어떤 내용의 권한을 체크할 수 있는지에 대한 내용은 MSDN을 참고하라.

권한 체크에 필요한 SecurityPermission객체가 생성되면 이제 그것의 Demand() 메소드를 호출하면 된다. 만약 현재 어셈블리가 해당 권한(비관리형 코드 호출 권한)을 가지고 있지 않다면 SecurityException  예외를 발생시킨다.

Demand() 메소드에 대해서 착각하지 말 것은, Demand()를 호출한다는 것은 "특정 권한을 요구하는 것이 아니다"것이 아니라 현재 어셈블리에 "특정 권한이 있는지 체크하는"것이다. 어셈블리의 코드가 실행될때쯤이면 실행되고 있는 컴퓨터의 보안 정책에 따랏 이미 사용 가능한 권한은 확정된다. 그리고 그 권한의 범위내에서만 실행될 수 있는 것이다.

Demand()를 사용하면 실행되고 있는 현재 컴퓨터의 보안 정책에 따라 몇가지로 행동하는 코드를 작성할 수 있다는 것이다. Demand() 메소드는 StackWalk를 통해서 호출하고 있는 모든 어셈블리들의 권한도 함께 체크한다.

■ Assert() 메소드

그러나 현재의 어셈블리가 충분한 권한을 가지고 있다면 StackWalk상에서 이전 어셈블리의 권한과는 상관없이 보호된 자원에 접근하려는 메소드가 실행될 수 있는 방법이 있다. 현재 어셈블리가 Assert() 메소드를 사용하여 권한을 체크하면 된다.

Assert() 권한 체크

Assert() 메소드는 StackWalk상에서 이전의 어셈블리에 대해서는 해당 권한을 부여하는 능력을 가지고 있다. 사실 권한 부여라기보다는 권한 체크 자체를 멈춘다.
그러나 현재 어셈블리가 해당 권한을 가졌는지를 먼저 체크한다. 즉 현재 어셈블리가 비관리형 코드를 호출할 수 있는 권한이 있는지를 체크한다. 자신도 가지고 있지 않은 권한에 대해 이전 어셈블리에 대해서 해당 권한에 대한 체크를 하지 말아달라고 요청하는 것은 받아 들여지지 않는다. 또한 현재 어셈블리가 Assert() 메소드를 호출할 만한 권한이 있는지도 체크한다. 비관리형 코드를 호출할 수 있는 권한이 있다는 것과, StackWalk상의 이전 어셈블리에 대해서도 그 권한 체크를 멈춰달라고 요청할 수 있는 권한은 다른 것이다. 다음은 이전에 Demand() 메소드에서 봤던 예제 코드에서 메소드만 Assert()로 변경했다.

현재 어셈블리에 비관리형 코드를 호출할 수 있는 권한과 Assert() 메소드를 호출할 수 있는 권한이 있다면 예를 들어 FullTrust 권한 집합을 부여받은 어셈블리라면 위 Assert() 메소드는 효력을 발휘해서 StackWalk상의 이전 어셈블리에도 비관리형 코드에 접근할 수 있는 권한이 부여되는 효과가 발휘될 수 있다.

■ 기타 자원을 보호하기 위한 권한 요청 메소드들은 여러가지 있다. CodeAccessPermition 클래스를 참고하라.

참조 문서

ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.VisualStudio.v80.ko/
dv_fxsecurity/html/1d072877-ad4c-4d2c-8544-4b2502cb1f37.htm(msdn 한글)

http://msdn.microsoft.com/library/default.asp?url=/library/
en-us/cpguide/html/cpconCodeAccessSecurity.asp(영문)

7. 보안 정책 배포

지금까지의 과정, 권한 그룹 생성, 코드 그룹 생성 및 세부 사항 편집은 모두 프로그램적으로도 가능하다. 따라서 클라이언트 보안을 설정하는 exe 프로그램을 제작해서 사용자들에게 배포하면 된다. 그러자면 CAS와 관련한 API를 숙지하고 있어야 할 것이다.
그러나 관리 툴은 그보다 간단한 배포 방법을 제공해주고 있다. 이 방법을 사용하면 보안 편집 툴로 편집한 내용을 .msi 파일로 자동 생성해준다. 이 .msi 파일을 사용자들에게 배포만 하면 된다.

관리 툴을 이용한 보안 정책 배포 #1

런타임 보안 정책(오른쪽 클릭)->배포 패키지 만들기…를 선택한다.

관리 툴을 이용한 보안 정책 배포 #2

이 화면에서 배포할 보안 정책 수준을 선택할 수 있다. 그리고 .msi 파일명을 입력하고 마치면 배포 파일 생성이 완료된다.
이 .msi 파일을 클라이언트 컴퓨터에서 실행시키면 보안 설정이 변경된다.

6. 보안 정책 설정 예

다음은 관리툴을 사용해서 보안 정책을 배포하는 예제를 보겠다. 이 보안 정책에서는 부모와 자식, 2 계층 구조의 코드 그룹을 생성해서 권한 집합을 확대하는 방법을 보이겠다. 그리고 앞에서 생략한 사용자가 직접 권한 집합을 만드는 예도 더불어 본다.

■ 권한 집합 생성

먼저 코드그룹에서 사용할 권한 집합을 "SCPermissionSet'이라는 이름으로 미리 하나 만들어두자. 집합을 새로 생성하려면 권한에 대한 자세한 내용을 알고 있어야 한다. 그러나 현실적으로 엔터프라이즈 애플리케이션을 개발하는 개발자들이 권한 집합을 생성하거나 편집하면서 개발할 시간은 거의 없다. 따라서 개발자시에는 주로 이미 만들어진 FullTrust 권한 집합을 사용하는 것이 보통이다.

권한 집합 생성 #1

생성할 권한 집합의 이름을 입력한다. 다음을 클릭하면 권한 집합에 포함될 수 있는 가능한 모든 권한이 출력된다.

권한 집합 생성 #2

기본적으로 출력되는 권한들 외에도 다음 인터페이스를 구현해서 사용자가 직접 정의해서 추가할 수도 있다.

그러나 달봉이는 아직 권한을 확장해 본 경험이 없다. 자세한 내용은 다른 문서를 참고하라.

사용 가능한 권한을 선택해서 추가를 하면 상세 권한을 설정하는 창이 뜨는데, 적당히 선택하고 나면 그림처럼 선택한 권한이 권한 집합에 할당된 것으로 나타난다. 마침을 클릭하면 새로운 권한 집합이 생성된다.

권한 집합 생성 #3

■ 코드 그룹 생성

이제 이 권한 집합을 부여할 코드 그룹을 생성한다. 새로운 코드 그룹에 대한 속성은 다음과 같다.

생성된 권한 집합 부여

코드 그룹에 권한 집합을 부여할 때 기존의 권한 집합 목록을 보면 앞에서 생성한 권한 집합 "SCPermissionSet"도 포함되어 있다. 이것을 선택하면 된다.

부모 코드 그룹 추가 완료

■ 자식 코드 그룹 생성

이제 "SmartClientCodeGroup" 코드그룹의 자식 그룹을 하나 더 생성하자.

다음은 자식 코드 그룹까지 생성한 모습이다.

공개키 조건값 입력

계층 구조의 코드 그룹

코드 그룹의 계층 구조는 어셈블리에 새로운 권한을 부여할 수 있는 방법이라고 앞에서 말했다. 만약 어떤 어셈블리의 CODEBASE URL이 "http://www.dalbong2.net/"를 포함하고 있다면 "SmartClientCodeGroup"그룹으로 분류되어 일단 권한 집합 "SCPermissionSet"에 포함되어 있는 권한들을 부여받게 된다. 그리고 "SmartClientCodeGroup"에 포함되는 어셈블리들 중에서 공개키가 "SmartClientStrongNamed" 그룹의 조건 값과 일치한다면 "FullTrust" 권한 집합에 매핑이 되어 모든 권한을 부여받게 된다. 이렇게 코드 그룹의 계층 구조를 통해서 좀 더 세밀한 권한 구조를 만들 수도 있다.

5. 보안 설정 편집

이제 개념적인 내용을 알았으니 PC의 보안 설정을 편집하는 방법을 알아보자.이곳에서는 어셈블리가 실행될 컴퓨터에 코드 그룹을 생성하고 그룹에 권한을 매핑하는 작업을 권한 관리 툴을 이용하는 방법을 보여준다. 툴을 사용해서 편집한 보안 내용은 .config 파일에 저장될 것이고 어셈블리가 로딩될 때 정책 평가기에 의해서 해석되어서 어셈블리에 설정된 권한을 부여할 것이다.
앞에서 이미 개념은 알았으니 툴의 사용 화면 캡쳐와 간단한 설명으로 쉽게 넘어갈 수 있으리라 본다. 엔터프라이즈, 컴퓨터, 사용자, 응용 프로그램 레벨별로 보안 설정이 가능하나 여기서는 주로 사용되는 컴퓨터 레벨의 보안 정책을 구성해보겠다. 다른 레벨의 정책도 동일하게 방법으로 구성될 수 있다. 순서는 간단하다. 다음 순으로 진행된다.
코드 그룹 생성
멤버 조건( 증거에 대한 조건) 입력
코드 그룹에 권한 집합 매핑
관리도구-> Microsoft .NET Framework 2.0 구성 메뉴를 통해서 .NET 설정 관리 툴을 실행시키자.
 

.NET 설정관리 툴 시작 화면

.NET 설정 관리 툴을 시작해서 런타임 보안 정책->컴퓨터->코드 그룹->All_Code를 선택한 화면이다. 기본적으로 생성되어 있는 코드 그룹이 있다.

■ 코드 그룹 생성
All_Code(오른쪽 클릭)->새로만들기…를 선택하면 다음 창이 뜬다.

 

코드 그룹 생성

적절한 코드 그룹 이름을 넣고 다음을 클릭한다. 달봉이는 "SampleGroup"라는 이름의 그룹을 생성할 것이다

■ 멤버 조건 입력
다음은 멤버 조건을 입력하는 화면이다. 멤버 조건이란 코드 그룹("SampleGroup")으로 분류되기 위한 증거들의 조건을 말한다.
 

멤버 조건 입력 #1

멤버 조건 입력화면이 뜨면 기본적으로 [All Code]조건이 선택되어 있다. 목록을 출력해보면 기본 증거에 해당하는 8가지 조건이 모두 출력된다.

 

멤버 조건 입력 #2

목록에서 특정 조건을 선택하면 조건에 따라 적절한 값을 입력할 수 있는 입력화면이 아래 공간에 출력된다.

멤버 조건 입력 #3

그림에서는 URL 조건 형식을 선택한 경우에 출력된 입력 화면을 보여주고 있다. 입력란에 달봉이는 "http://www.dalbong2.net/*"라고 입력했다. 즉 어셈블리의 CODEBASE URL값이 "http://www.dalbong2.net/"로 시작하는 모든 어셈블리에 권한을 적용하겠다는 의미다.
다른 조건 형식을 선택해보면 조건 형식에 따라 적절한 값을 입력할 수 있는 화면이 나타난다.  

멤버 조건 입력 #4

강력한 이름을 선택하면 공개키를 필수적으로 입력하고, 선택적으로 어셈블리 이름과 버전을 입력할 수 있는 화면이 출력된다. 가져오기 버튼을 클릭해서 해당 어셈블리를 선택하면 공개키와 이름, 버전을 자동으로 입력해준다. 공개키는 "sn.exe -Tp 어셈블리파일"을 통해서도 구할 수 있다. 이름과 버전의 체크박스를 선택하지 않으면 이름과 버전은 조건값에서 생략된다.

■ 권한 집합 할당

권한 집합 선택
멤버 조건을 입력한 후 다음을 선택하면 그림처럼 코드 그룹에 권한 집합을 매핑할 수 있는 화면이 출력된다. 기본적으로 정의되어 있는 권한 집합을 선택할 수도 있고, 새 권한 집합을 만들겠다고 선택할 수도 있다. 기존 권한 집합을 선택하겠다면 다음을 클릭해서 바로 작업을 마칠 수 있다.
직접 권한 그룹을 생성하는 것도 어렵지는 않다. 관리툴->런타임 보안 정책->컴퓨터->권한 집합(오른쪽 클릭)->새로 만들기… 를 통해서 가능하다. 권한 그룹을 직접 생성하는 것은 다음 예제에서 보겠다.
지금까지 코드 그룹을 생성하고 멤버 조건을 입력하고 권한 집합을 매핑하는 것까지 해서 컴퓨터 레벨의 새로운 보안 정책을 마련했다. 관리자가 보안 설정을 끝내고 저장을 하면 결과는 .config 파일에 XML로 저장될 것이다. 이제 어셈블리가 로딩되면, 권한 풀이기는 어셈블리가 제시할 수 있는 증거들을 근거로 해서 어셈블리가 어느 코드 그룹에 속하는가를 정책 파일을 해석해서 확인한다. 그리고 그 그룹에 부연된 권한을 어셈블리에 부여한다.

4. 보안 정책(security policies)
증거들은 그 자체만으로는 의미가 없고 PC에 설정된 보안 정책을 평가해서 그 증거들에 어떤 권한을 부여되는가 즉 어셈블리에 어떤 권한이 부여되는가에 따라서 어셈블리가 로딩도 될 수 있고 코드를 정상적으로 실행할 수 있는 가도 결정된다.
각 PC의 보안 정책은 .config 파일에 저장된다. 이 파일에는 어셈블리의 증거별 권한 집합이 정의되어 있다. 각 PC의 보안정책에는 “이 PC에서는 어떤 증거에 대해서는 어떤 권한을 부여하겠다”는 정책이 표현되어 있는 것이다. 보안 정책 파일은 사용자(관리자, 개발자)가 편집해서 적절한 보안 정책을 PC에 적용할 수 있다.  .NET의 SDK와 함께 제공되는 구성 편집 툴이 있는데, 이것을 사용하면 쉽게 보안 정책을 편집할 수 있다. 또한 기존의 보안 내용을 MS 인스톨러 프로그램 MSI으로 쉽게 다른 PC를 설정할 수도 있다. 보안 정책 편집에 대해서는 뒤에 다루겠다.
그러나 보안 정책은 하나의 파일에 정의되어 있지는 않다. 하나의 어셈블리에 적용될 수 있는 보안 정책 파일은 4개의 레벨로 구분되어 각 레벨별 정책을 담고 있는 .config 파일이 있다. 

보안 정책 레벨

사용자별로 보안 정책을 설정할 수 있다는 것은, 현재 로그인한 사용자에 따라서 어떤 어셈블리는 로딩될 수도 있고 아니면 보안 예외가 발생할 수 있다는 것이다. 마찬가지로 컴퓨터레벨의 보안 정책이 있다는 얘기는 어떤 컴퓨터에서 문제없이 실행되던 어셈블리가 다른 컴퓨터에서는 보안 문제가 일어날 수 있다는 것이다.
보안 정책 레벨은 이렇게 4가지 일 수 있다. 엔터프라이즈 레벨의 정책은 AD서버(Active Directory서버)에 등록된 컴퓨터들별로 보안 정책을 달리할 수 있다는 것이고 마찬가지로  컴퓨터별, 사용자별, 애플리케이션별로 정책을 달리 할 수 있다는 것이다. 보안정책 레벨은 .NET의 System.Security.PolicyLevelType 열거형으로 정의되어 있다.

기본적으로 AD서버 레벨의 권한설정(enterprisesec.config)에서는 모든 어셈블리에 FullTrust 권한을 부여한다. 그리고 컴퓨터 레벨의 설정(security.config)에서는 GAC에 등록된 어셈블리에만 모든 권한을 부여한다. 이 정책은 레벨 순서대로 적용이 된다. 즉 엔터프라이즈 정책->컴퓨터 정책->사용자정책->애플리케이션 정책 순으로 적용이 된다.
근데, 만약 이 4가지 레벨의 정책이 특정 권한에 대한 설정 내용을 가지고 있다면 어떻게 되는가?

레벨별 다른 권한 부여 예
예를 들어 엔터프라이즈 레벨의 보안 설정에서는 모든 어셈블리에 대해서 로컬 파일에 대해서 읽기 쓰기 권한을 부여하고 있다. 그러나 그림에서 처럼 그 다음 레벨의 컴퓨터 정책에서는 Url 증거가 "http://Sever/*"인 즉 이 경로에서 받은 어셈블리에 대해서는 로컬 파일에 대해 읽기 권한만을 부여한다. 그럼 해당 어셈블리에 대한 권한은 어떻게 부여되어야 할까? 그렇다. 읽기 권한만이 부여될 것이다.
이처럼 만약 어떤 어셈블리가 이 4가지 정책에 모두 연관될 수 있다면, 즉 어떤 어셈블리가 있는데, 이 어셈블리가 실행되는 컴퓨터가 AD서버에 등록되어 있고 그리고 이 애플케이션을 실행하기위해서 로그인한 사용자도 이 어셈블리에 대해 어떤 보안 설정을 해뒀고 그리고 애플리케이션 레벨에서도 어떤 보안 설정을 해 둔 경우라면 결과는 다음 그림과 같다.
그림 6 보안 정책의 중첩
그림은 적용 가능한 모든 정책의 교집합에 해당하는 권한이 어셈블리에 부여되는 최종 권한이 된다는 것을 보여준다.
보안 정책 파일에는 3가지의 주요 내용 설정이 있다: 코드그룹(Code Group), 멤버 조건(Member Condition), 권한 그룹(Permision Set).
 

보안정책 적용 과정

코드그룹, 멤버조건, 권한 집합를 갖는 구조가 다른 레벨의 보안정책에도 동일하게 적용될 수 있으나 그림에서는 컴퓨터 정책 레벨의 보안 정책을 예로 보여주고 있다.
각 보안 정책 레벨별로 코드 그룹(Code Group)이라는 것이 여러 개 정의될 수 있다. 코드 그룹은 어셈블리들이 모임의 멤버가 되는 것이다. 이 코드 그룹은 권한을 부여하는 대상의 단위가 된다.
코드 그룹에는 두 가지 중요한 속성이 있다 : 멤버조건(Member Condition), 권한 집합(Permission Set).
관리자는 먼저 코드 그룹을 생성할 수 있고, 그곳에 가입할 수 있는 멤버(즉 어셈블리)들에 대한 조건을 정의할 수 있다. 멤버 조건(Member Condition)이란 어셈블리의 증거들에 대한 조건이다. 즉 "어떤 증거를 가지고 있는 멤버만이 이 코드그룹에 가입(?)된다."라는 의미이다. .NET에는 기본적으로 다음과 같은 멤버 조건을 가지고 있다: 사이트, Url, Zone, ApplicaionDirectory, 강력한 이름, 게시자, 해시, GAC. 즉 "이 코드 그룹에는 Url(사이트, Zone…)증거로 특정 값을 가지고 있는 어셈블리가 멤버로 가입될 수 있다"는 의미가 된다.
코드 그룹에는 또한 권한 집합(permission set) 매핑된다. 원어 그대로 보면 어셈블리에게 허용되는 권한(permission)들의 집합(set)이다. 권한 집합에는 여러 개의 권한들이 포함될 수 있는데, 즉 코드 그룹에 부여되는 권한은 집합 단위로 적용되는 것이다. 다음은 기본적으로 .NET에 정의되어 있는 권한들을 보여주고 있다.
 

.NET 권한들과 보호되는 자원들

다음 표는 기본적으로 정의되어 있는 권한 집합을 보여주고 있고, 그 권한 그룹에는 어떤 권한들이 있는지도 보여주고 있다.

.NET 기본 권한 그룹

지금까지의 개념을 이야기로 풀이해보면 이렇다: "어떤 코드 그룹에는 특정 증거 조건을 갖는 멤버들만이 가입할 수 있으며 그 그룹에 포함되게 되면 어떤 권한들을 가질 수 있다". 각 어셈블리들에 대한 증거 조건을 판단하고 코드 그룹의 멤버로서의 적합 여부를 평가하는 것이 바로 보안 평가기(policy evaluator, 권한 풀이기)이다.
하나의 어셈블리가 여러 개의 코드그룹에 속하는 경우도 있을 것이다. 이런 경우 권한 풀이기는 어떻게 처리할까? 기본적으로 이런 경우는 이것은 합집합(union)의 개념이다. 예를 들어 사용자가 정의한 "SampleGroup"이라는 코드 그룹에도 속하고 기본 코드 그룹 LocalIntranet_Zone에도 속 한다면 두 그룹에 부여된 모든 권한을 가질 수 있다.

동일 정책 레벨상의 코드 그룹들의 권한 합집합

코드 그룹은 자식 그룹을 포함할 수 있도록 되어 있어서, 그림과 같은 계층 구조로 될 수 있다. 코드 그룹이 계층 구조로 이뤄지면 어셈블리가 사용할 수 있는 권한에 대한 합집합의 개념이 자식 코드 집합으로 확장될 수 있다. 무슨 말인가 하면, 특정 어셈블리가 코드 그룹 A의 멤버 조건을 만족하면 B,C,D에 대한 멤버 조건도 체크한다. 만약 그룹 C에 대한 조건이 만족되면 C의 권한도 부여받고 다시 E,F 그룹에 대한 조건도 체크를 하게 된다.

코드그룹 계층구조

따라서 자식 그룹을 추가해서 계층구조를 만드는 방법을 이용해서 어셈블리에 새로운 권한 집합을 매핑시킬 수 있다.
코드 그룹, 멤버 조건, 권한, 권한 그룹 등은 모두 사용자 정의가 가능해서 원하는 대로 확장할 수 있는 개념들이다. 달봉이의 능력을 넘어서는 주제들로서 여기서는 다루지 않는다.

3. 증거(evidence)

권한 풀이기(permission resolver)는 어셈블리를 로딩하면서 그것에 대한 증거를 수집하게 된다. 이런 증거들은 .config 파일에 있을 수 있고(CODEBASE) 또는 어셈블리가 가지고 있는 메너페스트 등에도 있을 수 있다. 다음 그림은 .NET에서 사용하는 증거들을 “어디서 왔는가”에 사용되는 증거들, “누가 만들었는가”에 사용되는 증거들 그리고 기타 증거들로 분류해 놓고 있다.  

.NET의 7가지 증거(v2.0 기준)

.NET에서는 그림에 나타난 것처럼 기본적으로 8가지 증거를 확인한다. 어디서 왔는가? 누가 만들었는가?를 판단하는데 사용되는 증거들을 구분해서 보여주고 있다. 기타에 있는 해시값은 관리자가 어셈블리 파일을 배포한 이후 임의의 코드 변경(해킹)이 이뤄졌는가를 체크할 수 있는 증거이다. 하나의 어셈블리에 이 모든 증거가 부여되지는 않겠지만 몇 개가 동시에 부여될 수도 있다.

어셈블리 권한 풀이기는 어셈블리의 CODEBASE에 사용된 URL(http://, file://)을 통해서 어셈블리의 위치 기반의 증거(Url, Site, Zone)을 결정한다.
“Url” 증거는 CODEBASE  URL (http://호스트명/배포디렉토리/어셈블리명)을 통해서 바로 구할 수 있다. Site, Zone 증거도 URL에서 유추된다. Site 증거는 URL중에서 호스트 서버명 부분만을 말한다. CODEBASE URL이 http://www.example.com/assem.dll인 경우, 수집되는 “Site” 증거는 www.example.com이 된다. 만약 CODEBASE가 file:///C:/~ 형식이라면 Site증거는 없게 된다.
“Zone” 증거도 URL을 통해서 유추한다. CLR의 입장에서 보안과 관련해서는 세상을 5개의 영역으로 나눈다 : 내컴퓨터, 로컬 인트라넷, 인터넷, 신뢰할 수 있는 사이트, 신뢰할 수 없는 사이트. .NET에서는 System.Security.SecurityZone 열거형에 다음과 같이 정의하고 있다.

로컬 파일 시스템에서 로딩된 모든 어셈블리는 MyComputer Zone에 속하게 된다. 그리고 원격 시스템에서 다운된 코드는 모두 IE 브라우저에서 구분하고 있는 영역을 기반으로 해서 결정된다.

IE 브라우저의 보안 영역 구분

IE 브라우저에서는 파일의 URL을 기반으로 해서 3영역, 로컬 인트라넷, 신뢰할 수 있는 사이트, 제한된 사이트를 정의한다. 그리고 이 3 영역에 포함되지 않는 모든 URL은 인터넷 영역에 포함된다. “로컬 인트라넷 영역”은 CODEBASE URL로, UNC 스타일의 URL( 예, \\server\dlls\assem.dll), DNS 스타일이나 IP 기반의 주소를 사용하지 않는 WINS 스타일의 HTTP URL( 예, http://서버명/apps/assem.dll, http://localhost/apps/assem.dll) 그리고 네트워크 공유 드라이브를 사용하는 URL( z:\apps\assem.dll)을 사용하는 어셈블리들이 이 영역에 포함된다. 사용자가 직접 이 영역에 포함되도록 사이트를 추가할 수도 있다.
IE 브라우저는 다시 “신뢰할 수 있는 사이트”와 “제한된 사이트” 영역을 정의하고 있다.  이 영역에는 사용자가 URL을 직접 추가하도록 해서 이 URL들에만 각각 적용되는 영역이다. URL이 앞의 어느 영역에도 적용되지 않으면 “인터넷 영역”으로 분리된다.
IE 브라우저에서 정의한 영역은 그대로 CAS 보안 영역에도 적용된다. 즉 브라우저에서 결정된 어셈블리에 대한 영역은 그대로 CAS의 보안 영역에 매핑되어서 어셈블리의 Zone 증거로 사용된다. 예를 들어, 어셈블리가 브라우저의 로컬 인트라넷 영역에 포함되었다면 이 어셈블리는 Zone 증거로 Intranet이 주어지게 된다.
“ApplicationDirectory” 증거는 애플리케이션의 베이스 디렉토리 값으로 결정된다. .NET2.0에서 새롭게 추가된 위치 기반의 증거로 “GAC”이 있는데, GAC에 등록된 어셈블리에 주어지는 증거이다. 지금까지 위치 기반의 증거들에 대해서 알아봤다.
위치 기반의 증거들외에도 .NET이 기본적으로 정의한 증거에는 누가 개발했는가를 알려주는 증거도 있다 : 강력한 이름(StrongName), 게시자(Publisher)
어셈블리의 4가지 이름 정보로 구성된 강력한 이름은 어셈블리의 메너페이스에서 구할 수 있다. 강력한 이름은 개발자 또는 이 어셈블리를 개발한 회사별로 고유한 이름이고 따라서 "어떤 이름을 갖는 어셈블리에게는 어떤 레벨의 권한을 부여하겠다"는 식의 보안 정책이 가능하다. 게시자(publisher) 증거도 마찬가지이다. 어셈블리는 공인 인증 기관에서 발급한 인증서에 대한 내용을 메너페스트에 디지털 서명으로 가지고 있을 수 있다. 이런 경우도 "어떤 인증 정보를 갖는 어셈블리에게는 어떤 권한을 부여하겠다"는 것이 가능하다.
마지막 증거, 해시(Hash)는 어셈블리 파일의 해시값으로서 어셈블리가 컴파일될때마다 변경될 수 있다. 어셈블리가 로딩되기 전에는 이 해시값이 없다. 로딩되면서 로더에 의해서 자동으로 어셈블리에 추가된다. 권한풀이기는 이 값을 증거로서 사용하는 것이다. 이것으로 증거들에 대한 이야기는 마치겠다.
이런 증거들을 근거로 해서 어셈블리에 주어질 권한을 계산해 내기 위해서는 PC마다 설정된 보안 정책이 있을 것이다. 이제 이 보안 정책에 대해서 알아본다.

2. 정책 평가 / 권한 부여 프로세스

어셈블리가 어디서 왔고, 누가 만들었는지에 대한 정보를 어셈블리의 증거(evidences)라고 한다. 이런 어셈블리가 제시하는 증거들을 근거로 해서 어셈블리가 부여받을 수 있는 권한 집합(permission set)을 결정하게 되는데, 이런 과정을 정책 평가(policy evaluation)라고 한다. 대신에 달봉이는 권한 풀이(permission resolving)라는 말로도 표현한다.

증거들을 근거로 해서 어셈블리의 권한을 결정할 수 있으려면, 증거별 권한(permission)을 평가, 부여할 수 있는 정책이 PC에 정의되어 있어야 할 것이다. 이런 정의를 보안 정책(security policy)라고 하며 보안 정책에 대한 내용은 .config 파일에 XML 포맷으로 담겨져 있다. 이런 보안 정책 파일에는 쉽게 말하면 "어느 URL에서 온 어셈블리에는 어떤 권한을 부여할 것이고 그리고 어떤 공개키를 갖는 어셈블리에는 어떤 권한을 부여할 것이다"등등의 내용이 들어 있다. 이런 정책 평가 구조를 나타내면 다음과 같을 것이다. 

증거와 보안정책

입력되는 어셈블리의 증거들과 보안정책을 바탕으로 해서 어셈블리의 권한을 결정하는 과정을 앞에서 말한 것처럼 어셈블리 이름풀이(assembly permission resolving)이라 했고, 이것을 담당하는 CLR의 시스템을 어셈블리 권한풀이기(permission resolver, 정책 평가기 policy evaluator)라고 부르겠다. 그림에서 권한 풀이기는 어셈블리들에 대한 증거들을 입력받아서 결과적으로 어셈블리에 대한 권한을 결과물로 내놓는 블랙박스로 표현하고 있다.

권한 풀이 과정을 다시 순차적으로 그려보면 다음과 같다.

어셈블리 권한풀이 과정

권한풀이 과정을 하나씩 알아가 보자.

1. CAS(Code Access Security)란?

스마트클라이언트 애플리케이션에서는 배포와 함께 가장 이슈로 떠오르는 문제가 바로 보안의 문제이다. 어셈블리가 외부로부터 다운되기 때문에 어떻게 외부 코드로부터 로컬 PC의 자원을 보호하느냐가 문제가 되는 것이다. 기존의 사용자 중심의 보안체계로는 이 경우를 대처할 수 없게 된다.

사용자 중심의 보안 체계라는 것은 사용자별로 계정이 있고 그 계정에 권한을 부여하는 방식이었다. 따라서 윈도우상에서 보안을 판단할때는 이 사용자(즉 이 계정)를 기반으로해서 현재의 프로세스를 실행시킬 수 있느냐 없느냐를 체크했다.

사용자 계정 중심의 보안 체계에서는 인터넷에서 프로그램을 다운, 설치를 사용자가 한번만 승인하게 되면 이 코드는 현재 로그인된 사용자의 계정 권한을 이어 받게 된다. 만약 로그인된 사용자 계정이 관리자 그룹에 속하는 계정이라면 이 프로그램은 무소불위의 권력을 갖게 된다. 중요 파일을 삭제하거나 중요 정보를 외부로 유출시킬 수도 있다. ( 이런 이유들 때문에 아무리 PC의 주인일지라도 사용자 계정을 하나 만들어서 관리자 계정이 아니라 사용자 계정으로 로그온해서 작업을 하도록 보안 전문가들은 권장하고 있는 것이다.)

그러나 .NET 프레임워크에서는 어셈블리 중심의 새로운 보안 체계가 도입된다. 이름하여 CAS(Code Access Security. 흔히 ‘카스’라 발음한다.)라고 한다. .NET의 CAS에서는 현재 로그온된 계정이 누구인지도 중요하지만, 이 코드가 어디에서 왔고 누가 만들었는지도 체크를 한다. 이런 정보들을 바탕으로 해서 CLR은 어셈블리의 권한을 결정하게 되고 그 어셈블리의 권한에 따라 어셈블리의 로딩여부 또는 실행여부가 결정된다. 동일한 어셈블리라 하더라도 이것이 어느 곳에서부터 왔느냐에 따라 그 권한이 달라질 수 있다. 예를 들어 인터넷에서 다운받아서 실행시키는 경우는 보안 에러가 발생하더라도 동일한 어셈블리를 로컬 PC로 복사해서 실행시키면 아무 문제없이 실행된다는 것이다. 요즘 같은 분산환경의 컴퓨팅 시기에는 애플리케이션에서 실행되는 코드가 어디로부터 어떻게 들어올지 미리 예측하기가 힘들다. 이러한 환경에서 CAS는 합리적인 보안체계라 아니 할 수 없다.

로컬 PC 외부에서 들어오는 어셈블리는 로컬 PC의 어셈블리들과는 달리 권한에 있어서 제한을 받는다. 이렇게 완전한 권한을 부여받지 못한 어셈블리를 이름하여 부분적으로 신뢰를 받는 어셈블리(partially trusted assembly)라고 한다. FullTrust 권한을 부여받지 못했다면 Everything 권한 집합을 부여받은 어셈블리할지라도 부분적으로 신뢰를 받는 어셈블리에 속하게 된다.
.NET CLR은 기본적으로 강력한 이름의 어셈블리(strong named assembly)는 완전한 권한을 갖는 어셈블리만이 호출할 수 있도록 하고 있다. 그러나 강력한 이름의 어셈블리가 AllowPartiallyTrustedCallersAttribute(APTC) 어셈블리 어트리뷰트를 사용하게 되면 부분 신뢰의 어셈블리로부터의 호출도 허락하겠다는 의미인것이다.

GAC에 등록된 어셈블리가 이 어트리뷰트를 가지고 가지고 있다면 외부에서 들어온 어셈블리들도 GAC에 등록된 어셈블리를 사용할 수 있게 되는 것이다. APTC 어트리뷰트를 사용하려면 개발자는 있을 지도 모르는 보안문제에 대해서는 스스로가 모두 체크해야 한다. 그래서 필요하다면 클래스나 메소드 수준의 보안 요청을 해서 권한 체크를 해야 한다. 만약 중요한 자원에 대한 액세스를 포함하고 있는 어셈블리나 보안상 약점이 있는 어셈블리가 이 어트리뷰트를 포함하고 있다면 문제가 될 수도 있다. 그래서 .NET 프레임워크 1.0에 이 어트리뷰트의 추가 여부를 두고 가장 늦게까지 결정이 미뤄졌다고 한다. .NET 프레임워크 1.0 베타 버전에서는 아예 추가되지도 않았다고 한다.
.NET 어셈블리의 핵심 코드를 가지고 있는 어셈블리에서는 이 어트리뷰트를 사용하지 않고 있다. 부분 신뢰 환경의 애플리케이션을 작성할때는(애플리케이션에 FullTrust 권한을 부여했다면 상관없다), .NET 프레임워크의 어셈블리들중에서 APTC를 허용하는 어셈블리들을 확인하고 이 어셈블리들이 제공하는 기능의 범위내에서 애플리케이션을 작성해야 한다.

APTC 어셈블리 목록

웹 브라우저 임베딩 방식의스마트 클라이언트 애플리케이션을 제작할때는 <object>태그를 통해서 대상 어셈블리를 로딩하게 된다. 앞의 APTC 어셈블리 목록중에 ieexecremote.dll이라는 어셈블리가 있는데, 이 어셈블리가 <object>에 의해 최초 호출되는 어셈블리의 OnLoad() 호출하는 스택상에 존재한다. 따라서 <object>에 의해 호출되는 어셈블리는 APTC 어트리뷰트가 있어야 한다. 그리고 다시 이 어셈블리에 의해 참조되는 다른 어셈블리 또한 APTC가 표시되어야 한다는 것도 기억하길 바란다. 웹 페이지에서 태그<object>를 이용해서 어셈블리를 로딩하려고 할 때 대상 어셈블리는 약한 이름의 어셈블리(weakly named assembly)이던지 만약 어셈블리가 강력한 이름의 어셈블리(strongly named assembly)라면 AllowPartiallyTrustedCallersAttribute(APTC) 어트리뷰트를 추가해야 정상적인 로딩이 가능하다.
다시 한번 더 상기시키면, APTC 어트리뷰트는 강력한 이름의 어셈블리에만 적용된다. 약한 이름의 어셈블리는 이 어트리뷰트가 필요없다.

참조 문서

ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.VisualStudio.v80.ko/
dv_fxsecurity/html/dd66cd4c-b087-415f-9c3e-94e3a1835f74.htm(영문)

APTC 어셈블리 여부 확인 툴 제공
http://www.develop.com/technology/resourcedetail.aspx?id=843c6027-b697-469d-933b-014b61f7d500

ClickOnce의 배포를 이야기하면서 Authenticode에 대한 이야기가 나와서 그 원리를 함 알아보려고 했다. 달봉이도 Authenticode에 대해서는 잘 모른다. 혹시라도 잘못된 곳이 있으면 사정없는 댓글에 대한 희망을 전한다.

---

Introduction to Code Signing 요약

■ 코드 사인(code singing) 소개

인터넷으로 파일 다운로드하는 경우, 두 종류의 보안 이슈가 발생한다.

1. 게시자의 신뢰성 확인(Ensuring authenticity)
- 누가 게시했나? 즉 게시한 사람은 믿을 수 있나?
2. 코드의 무결성 확인(Ensuring integrity)
- 게시 이후 코드(소프트웨어)는 변경되지 않았나?

Authenticode는 이런 이슈를 해결하기 위한 Microsoft에서 제시한 솔루션을 말한다.

■ Authenticode

Authenticode 자체는 사인이 된 코드를 만들어 내지 않는다. 단지 코드 사용자들에게 코드 게시자(publishers)가 신뢰할 수 있는 인증 기관의 인증을 받았는가를 알려줄 수 있는 메커니즘이다. Authenticode는 인터넷을 이용한 코드(소프트웨어)의 배포 및 다운로드에 참여하고 있는 코드 게시자 및 코드 사용자 모두에게 필요한 기술이다.

■ 코드의 변경 여부 확인- 디지털 사인(Digital Signatures) 

코드(데이터 또는 소프트웨어)를 배포할 때 사용자들에게 배포자가 누구인지를 알리고 싶을 때 사용하는 것이 디지털 사인이다. 디지털 사인은 데이터의 내용을 변경하지 않는다. 다만 데이터와 함께 배포될 수 있는 디지털 사인 문자열이 생성된다. 이 디지털 문자열과 데이터가 한 파일로 묶여서 배포될 수 있다.

디지털 서명은 "public-key 알고리듬"을 사용해서 생성된다. 이 알고리듬은 이름과는 달리 public / private 키 쌍을 사용한다.
Authenticode 기술에서는 private 키를 "서명"에 사용하고, 다시 "서명의 확인"에 public 키를 사용하게 된다. ( 이 한줄은 기본이 되어 있지 않은 달봉이를 끝까지 인내로서 대해주신 정성태님의 지극한 조언이 없었으면 나오지 못했을 말이다. 근데 잘 이해를 했는지는 모르겠다.  쯔읍 아휴~~허접덩이)

public-key 알고리듬을 응용한 Authenticode 서명(-_-;;) 데이터 소유자는 데이터를 public / private 키를 생성해서, public 키는 필요한 모든 사람들에게 공개한다. 특정 private 키로 서명을 하면 서명확인은 반드시 해당 public 키로 해야 한다.

Authenticode 의 프로세스를 요약하면 다음과 같다.
1. 파일의 해시(one-way hash)값을 계산한다.
2. 해시값은 private 키를 이용해서 암호화가 된 문자열(서명 문자열)을 만들어낸다.
3. 파일과 서명이 된 해시값, public 키를 배포한다.
4. 배포를 받은 클라이언트는 파일의 해시값을 구한다.
5. 클라이언트는 사인이 된 해시값을 public 키를 이용해서 다시 복호화해서 원래의 해시값을 구한다.
6. 클라이언트가 구한 두 해시값이 일치하면 코드는 배포 이후에 변경되지 않았다는 것을 알 수 있다.

■ 게시자의 신뢰여부 확인 - 인증서(Digital Certificates)

디지털 인증서(digital certificate)는 라는 것은 적절한 절차를 거쳐 신청자(게시자)의 신청을 심사한 후 인증 기관(Certification Authority, CA)이 발행한다. 실제의 디지털 인증서는 파일로 존재하는데, 이 파일의 구조에는 신청자 및 인증 기관에 대한 정보 등 여러 가지가 포함되어 있다. 다음 그림은 X.509 프로토콜의 인증서 구조를 나타내고 있다.

X.509타입의 인증서 구조

Version : 인증서 포맷을 규정하는 번호
Serial Number : CA의 고유한 번호
Algorithm Identifier : 인증서를 서명하기 위해서 사용된 알고리듬
Issuer : CA 명
Period of Validity : 인증서의 유효 기간 정보
Subject : 신청자명
Subject’s Public Key : 신청자의 public 키 정보
Signature : CA의 디지털 서명

디지털 인증서는 크게 신청자의 “신청정보”와 “인증 기관의 디지털 서명”으로 구성되어 있다. 인증 기관의 디지털 서명은 인증 기관의 private 키로 “신청정보”를 암호화한 문자열이다. 인증서를 사용하는 클라이언트측에서는 이 인증기관의 디지털 서명과 인증기관의 public 키를 이용하면, 인증서에 포함된 게시자의 public 키가 인증 기관이 인증서를 발행했던 그 신청자의 public 키인지를 확인할 수 있다.

인증서에 포함된 신청자의 public 키 검증
(클릭을 하면 선명한 화면이 보입니다.)

그림은 인증서에 포함된 신청자의 public 키가 실제로 인증 기관이 인증한 신청자의 public 키인지를 검증하는 프로세스를 그린 것이다. 점선 부분이 인증서를 사용하는 클라이언트측에서 수행되는 검증 작업을 나타낸다. 만약 신청자의 public 키를 포함하고 있는 “신청정보”의 해시값과 인증서에 포함된 인증기관의 서명과 인증기관의 public 키로 복호화된 해시값이 일치하면 신청 정보가 변경되지 않았다는 것이고 따라서 신청 정보에 포함된 신청자의 public 키도 변경되지 않았다는 것을 알 수 있다. 이것은 또한 디지털 인증서의 가장 중요한 목적중의 하나인 인증서에 포함된 게시자는 인증 기관의 인증을 받은 것으로 판단내릴 수 근거가 될 수 있다. 즉 인증서의 게시자를 신뢰할 수 있게 되는 근거가 될 수 있다.   

■ 정리

이제 정리를 하자면 다음 두 그림으로 요약될 수 있다.

서명 과정

이 그림은 게시자(인증서 소유자)가 파일(어셈블리 파일)에 서명을 하는 과정을 나타내고 있다. 그림을 보면 파일의 해시값(정확히는 파일 전체의 해시값이 아니라 “메시지 축약(message digest)에 대한 해시값)을 게시자의 private 키로 서명을 한다. 그리고 시그너쳐 문자열과 인증 기관으로부터 발급받은 디지털 인증서를 서명 툴들을 사용하면 최종적으로 원래의 파일 내용의 검증 작업에 필요한 정보들이 덧붙여진 모습의 파일이 그림처럼 생긴다. 이제 이 파일을 인터넷을 통해서 사용자들에게 배포하면 된다.

서명확인 과정

인터넷을 통해서 배포받은 파일에 대해서 클라이언트(브라우저)측에서 검증하는 절차를 나타내고 있다. 클라이언트측에서는 먼저 원래 파일의 데이터를 이용해서 계산한 해시값과 게시자의 public 키를 사용해서 복호화한 해시값을 비교해서 코드의 무결성을 검증한다. 코드 무결성 검증을 통과하면 인증서가 신뢰할 수 있는 기관에서 발행한 것인지를 확인하는 작업을 하게 된다. 이 모든 작업을 통과하면 파일은 게시 이후에 변경되지 않았고 또한 인증기관의 인증을 받은 신뢰할 수 있는 게시자가 그 파일을 배포했다는 것을 의미하게 된다.

---

참조문서

Introduction to Code Signing - msdn
http://msdn.microsoft.com/library/default.asp?url=/workshop/security/authcode/intro_authenticode.asp

v2.0의 CodeGroup의 멤버 조건을 보면 "GAC"이라는 것이 하나 더 추가되었다. 이것과 관련해서 잠시 정리해 두려 한다.

Q : GAC에 등록된 어셈블리는 항상 FullTrust 권한을 부여받을까?
A : 상황에 따라 다르다.

v1.X에서는 GAC에 등록된 어셈블리도 MyComputer 영역의 어셈블리도 간주해서 MyComputer 영역의 권한셋인 FullTrust 를 부여받았다. 그래서 MyComputer 코드 그룹의 권한을 변경하면 GAC에 등록된 어셈블리의 권한도 함께 변하게 되었다.
그러나 v2.0에서는 GacMembershipCondition을 추가하고 있다.

추가된 멤버 조건 : GAC

이 조건을 사용하면 GAC에 등록된 어셈블리는 MyComputer 영역의 권한셋과는 별도의 권한을 부여할 수 있다. 즉 MyComputer 코드 그룹에 FullTrust가 아닌 권한셋을 부여한다고 해도, GAC에 등록된 어셈블리는 계속해서 FullTrust 권한을 부여할 수 있다.

구성파일 (web.config) 암/복호화에 대한 포스트가 있어서 소개합니다.

ensimple.net
http://www.ensimple.net/enSimple/show.aspx?cnum=87&b_id=study_csharp&page=1

msdn
http://msdn2.microsoft.com/ko-kr/library/53tyfkaw.aspx
http://msdn2.microsoft.com/ko-kr/library/zhhddkxy.aspx