[연재 08] ClickOnce 보안 모델( 두번째 이야기 )

■ ClickOnce 애플리케이션의 권한 설정

VS.NET으로 ClickOnce용 애플리케이션을 게시할 때 사용하는 프로젝트 디자이너를 다시 보여주고 있다. 그림은 보안 페이지에서 설정하는 모습이다.

달봉이는 처음에 이 설정이 계속 마음에 걸렸고, 결국은 달봉이가 이 그림이 뭔지 이해하지 못하고 있다는 것을 알게 되었다.

달봉이가 처음 의문을 갖게 된 사연을 보면 다음과 같다. 먼저, “ClickOnce 보안 설정 사용”이라는 선택을 하고 있는데, 이것이 뭔지 이해가 안 갔다. “ClickOnce 보안”이라는 것이 별도로 있다는 것인가? 그리고 “완전 신뢰 응용 프로그램”과 “부분 신뢰 응용 프로그램”이라는 말도 이해가 가지 않았다. 기존의 모델이라면 “완전 신뢰 어셈블리”, “부분 신뢰 어셈블리”이어야 할 것이다. 거기다 “부분 신뢰의 응용 프로그램”을 선택한 경우는 “응용 프로그램에 필요한 권한”을 선택할 수 있는 리스트가 활성화된다.

앞 뒤 설정 내용을 근거로 해서 다음과 같은 추측을 했다. “ClickOnce 애플리케이션은 권한이 애플리케이션(정확히 말하면 애플리케이션 도메인)에 부여되는 것은 아닐까”. 만약 그렇다면 보안 탭을 통해서 필요한 권한이 설정되면 CodeGroup별 멤버 조건을 설정하고 권한 집합을 설정하는 작업을 하지 않아도 되지 않을까 하는 생각을 해 봤다. 그래서 .NETv2.0 구성 관리자를 실행시켜 특정 CodeGroup을 삭제해봤다. 그 코드 그룹은 이전에 IE 임베딩 방식의 스마트클라이언트에서 추가했던 것이었다. 예상대로 ClickOnce로 배포된 애플리케이션은 실행이 여전히 잘 되었다.

테스트후, 달봉이는 “ClickOnce 보안”이라는 것에서는 “애플리케이션 도메인(AppDomain)” 기반 즉 권한이 도메인에 부여될 것이다는 추측을 하게 되었다. 그러나 심증만 있을 뿐 아직 그것을 뒷받침해줄만한 문서를 보지 못했다. 그래서 근 한달여간을 가슴 한켠에 뭔가가 무겁게 짓누르고 있는 듯한 답답함을 가지고 지내야 했다. 근데, 어제 퇴근길 지하철에서 읽은 블로그 문서들이 달봉이의 답답함을 풀어줬다. 그 시원함이란! 크으~~

참조 문서의 링크를 보면 그 내용을 볼 수 있다. 이 블로그에서는 “AppDomain 중심의 보안 모델”을 “Sandboxed AppDomain”이라는 말로 표현하고 있다. 심증을 확인해 주는 문서들이다.

■ 요약

▶ v1.x의 보안 모델

증거와 보안 정책 기반의 이전 모델은 어셈블리 중심의 권한 부여 사고 방식이다. 이것을 요약하면 다음과 같다.

“어셈블리가 가지고 있는 증거들을 기반으로 해서 4레벨(엔터프라이즈, 컴퓨터, 사용자, 애플리케이션)의 보안 정책을 적용함으로써 어셈블리에 부여되는 권한을 결정한다”

▶ v2.0에 추가된 보안 모델

v2.0에서는 v1.x의 보안 모델외에도 추가된 모델이 있다. 이 추가된 v2.0 보안 모델에서는 애플리케이션이 정상적으로 작동할 수 있는 권한(permission set)을 요청하게 되고 그 요청이 수락되면 정확히 요청한 권한만 애플리케이션에 부여된다. 그 후 애플리케이션의 도메인으로 로딩되는 모든 어셈블리들은 부여받은 그 권한내에서만 작동을 하게 된다. 즉 애플리케이션의 샌드박스(sandboxed AppDomain)이 조성되는 것이다. 만약 애플리케이션이 요청한 권한이 정상적인 CAS 정책에 정의된 것보다 많은 것을 요구하게 되면 사용자의 승인을 요하는 보안 대화상자가 뜨게 된다. 사용자가 승인(elevation of permissions) 을 하게 되면 그 내용은 매너페스트 파일에 저장되어, 다음부터는 대화상자가 뜨지 않게 된다.

“권한이 부여되는 대상은 AppDomain이다. 그리고 그 AppDomain으로 로딩되는 모든 어셈블리는 그 AppDomain의 권한을 부여받게 되는 것이다.”

ClickOnce 배포를 사용하는 애플리케이션은 이런 애플리케이션 샌드박스 보안 모델이 적용된다. 즉 ClickOnce 배포를 사용하게 되면, 이전 모델에서처럼 클라이언트측 PC의 CAS 설정을 위하여 MSI 파일같은 것을 사용하지 않아도 된다. ClickOnce 애플리케이션을 게시할때 필요한 권한을 설정해서 배포 서버로 게시하면 된다.

앞의 그림은 Debug-In-Zone 기능이라는 것을 보여주고 있다. 개발자가 ClickOnce 애플리케이션을 개발할때 애플리케이션이 배포될 Zone을 선택하고 그리고 필요한 권한을 설정해서 최종 배포되기 전에 미리 sandboxed된 환경에서 테스트해 볼 수 있는 기능을 제공하는 것이다.

테스트 결과 애플리케이션이 수행되는데 충분한 권한이 주어졌다고 생각되면 해당 권한 설정을 저장한다. 그런 상태에서 클라이언트 PC로 배포되면 설정된 권한을 클라이언트에 요청할 것이고 만약 그것이 정상적인 권한을 넘어서는 요청이라면 사용자에게 대화창을 띄워 승인을 얻게 되는 것이다.

개발 당시는 "ClickOnce 보안 설정 사용"을 체크하지 않는 것이 편할 것이다. 이렇게 하면 sandbox 환경이 없어져서 일반 로컬 애플리케이션와 같은 환경에서 개발할 수가 있게 된다.

■  미해결

AppDomain 단위의 Sandbox에 대해서도 아직 궁금한게 많이 있다. 예를 들면, AppDomain에도 증거(evidence)라는 것이 있단다. 이 AppDomain에 대한 증거는 어디에 사용되는지도 아직 알 수 없다. AppDomain을 생성하는 API인데 이것을 봐도 AppDomain은 Evidence타입의 객체를 필요로 한다.

AppDomain.CreateDomain( string friendlyName,
                      Evidence securityInfo,
                      AppDomainSetup info,
                      PermissionSet grantSet,
                      params StrongName[] fullTrustAssemblies);

"A Closer Look at the Simple Sandboxed AppDomain"를 보면  다음과 같은 내용이 있다.

Technically the domain itself doesn't need that parameter, and it won't ever look at it directly.  However, the evidence is still stored on the AppDomain's Evidence property.  This means that other features which make decisions based upon AppDomain evidence (such as isolated storage), can still work with code executing in a simple sandboxed domain without modification.

증거(evidence)가 권한 부여 조건 말고도 다른 부분에 사용된다는 것인지, 그리고 참조 문서의 블로그를 읽다보면 AppDomain에도 증거가 부여된다는 것을 알 수 있는데

그러나 지금은 “Sandboxed AppDomain”라는 모델이 있다는 것만으로도 달봉이의 많은 의문이 풀렸다.

참조 문서

The Simple Sandboxing API
http://blogs.msdn.com/shawnfa/archive/2005/08/08/449050.aspx
A Closer Look at the Simple Sandboxed AppDomain
http://blogs.msdn.com/shawnfa/archive/2005/08/09/449563.aspx
5 Reasons to Choose Simple Sandboxing
http://blogs.msdn.com/shawnfa/archive/2006/04/19/579066.aspx