Silverlight를 설치하려면 여기를 클릭합니다.*
Korea 대한민국변경|Microsoft 전체 사이트
MSDN
|개발자 센터
MSDN Home   MSDN Home
MSDN 홈 > Visual Studio 홈

코드 액세스 보안 소개

 

Keith Brown
Pluralsight

2006년 1월

대상:
    Microsoft Visual Studio .NET
   Code Access Security (CAS)

요약: .NET 개발 모델은 웹 서버에서 응용 프로그램의 최신 버전을 가져오는 클라이언트에 기반합니다. 이렇게 하면 많은 문제를 해결할 수 있지만 클라이언트에서 코드의 안전성을 검사하는 방법이 문제가 됩니다. 다음은 이에 대한 Keith Brown의 설명입니다. (인쇄 시 11페이지)

목차

소개
신뢰 수준
대략적인 개념
증거
사용 권한
정책
.NET 보안 정책
결론

소개

Microsoft .NET Framework는 스마트 클라이언트를 개발하고 배포하기 좋은 플랫폼입니다. .NET 개발 모델은 웹 서버에서 응용 프로그램의 최신 버전을 가져오는 클라이언트에 기반하므로 많은 문제를 해결할 수 있지만 클라이언트가 악의적인 코드를 다운로드할 수 있는 문제가 있습니다. 클라이언트에서 코드를 구분하는 방법은 무엇일까요?

이 문제를 해결하기 위해 .NET Framework는 코드 액세스 보안(CAS)이라는 보안 시스템을 도입했습니다. CAS를 사용하면 중앙에서 신뢰 수준을 결정할 수 있으며 부분적으로 신뢰된 코드 개념을 도입하여 코드를 제한된 사용 권한으로 실행할 수 있습니다. 먼저 몇 가지 개념을 소개하고 CAS 용도와 처리 방식을 전체적으로 설명한 다음 마지막으로 이 기술의 실체를 이해할 수 있도록 약간의 고급 주제를 다루도록 하겠습니다.

신뢰 수준

.NET Framework 이전에는 Windows에서 다운로드하는 코드에 두 가지 신뢰 수준이 있었습니다. 웹을 탐색할 때 아래와 같은 대화 상자를 본 적이 있을 것입니다.

그림 1

이 대화 상자에서는 예 또는 아니요를 선택할 수 있습니다. 이것은 설치하고 실행하려는 코드의 신뢰 수준을 나타냅니다. 아니요를 선택하면 코드가 실행되지 않습니다. 예를 선택하면 코드가 사용자 로그인을 기준으로 현재 사용자에게 부여된 모든 사용 권한을 가지고 실행됩니다. 대부분의 사용자는 Administrators 그룹의 구성원이므로 다운로드한 코드는 컴퓨터에서 원하는 모든 작업을 수행할 수 있습니다.

이 구식 모델은 이진 신뢰 모델로 사용자는 완전 신뢰와 신뢰 안 함 중에서 하나를 선택해야 합니다. 즉, 코드에서 모든 작업을 수행할 수 있거나 코드 자체가 실행되지 않습니다.

관리되는 코드의 세계에서는 여전히 이 두 옵션이 사용되지만 CLR에는 세 번째 옵션인 부분 신뢰가 있습니다. 부분적으로 신뢰된 코드를 사용하면 코드 실행이 허용되지만 코드에 .NET Framework의 제한이 적용되므로 사용자가 수행할 수 있는 작업을 코드에서 실행할 수 없는 경우도 발생합니다. 실제로 코드에서 수행할 수 있는 작업을 정확하게 제어하는 많은 사용 권한이 있으며, 앞으로 간단히 살펴 보겠지만 이러한 사용 권한을 .NET 보안 정책을 사용하여 부여하고 해지할 수 있습니다.

이 시점에서 이해해야 할 가장 중요한 개념은 부분 신뢰는 항상 신뢰 안 함과 완전 신뢰 사이에서 권한 집합을 부여한다는 것입니다. 여기서 신뢰 안 함은 코드를 실행할 수 없다는 것을 의미하며 완전 신뢰는 사용자가 정상적으로 실행할 수 있는 모든 작업이 코드에 허용된다는 의미입니다. 관리자가 실행하는 완전히 신뢰된 코드는 관리 작업을 수행할 수 있습니다. 관리자 권한이 없는 일반 사용자가 실행하는 완전히 신뢰된 코드는 관리 작업을 수행할 수 없지만 사용자가 액세스할 수 있는 모든 리소스에 액세스할 수 있으며 사용자가 수행할 수 있는 모든 작업을 수행할 수 있습니다. 보안 관점에서는 완전히 신뢰된 코드를 전통적인 ActiveX 컨트롤과 같은 관리되지 않는 기본 코드로 생각할 수 있습니다.

그림 2

그러면 코드를 부분 신뢰로 실행할 것인지 완전 신뢰로 실행할 것인지 선택하는 시기는 언제입니까? 개발자는 이 시기를 선택할 수 없습니다. 코드 액세스 보안은 사용자로부터 응용 프로그램을 보호하기 위해 도입된 것이 아닙니다. 코드 액세스 보안의 기본 목표는 악의적인 것으로 의심되는 응용 프로그램으로부터 사용자를 보호하는 것입니다. 네트워크를 통해 다운로드하는 코드를 이야기하고 있다는 것을 기억하십시오. 로컬에서 설치하는 응용 프로그램은 기본적으로 완전히 신뢰됩니다.

시스템 관리자는 모든 보안 정책을 제어합니다. 사용자가 스마트 클라이언트 응용 프로그램을 컴퓨터에 설치할 필요 없이 네트워크에서 실행할 수 있게 하려면 시스템 관리자가 보안 정책을 조정하여 완전 신뢰 상태로 코드가 실행된다고 가정하거나 부분 신뢰 상태에서 문제 없이 실행되도록 세심하게 코드를 작성해야 합니다. 부분 신뢰 상태에서 실행되는 코드를 작성하려면 약간의 학습과 엄청난 끈기가 필요하기 때문에 부분적으로 신뢰된 코드를 작성하는 주제로 다른 기사를 준비하고 있습니다.

대략적인 개념

코드 액세스 보안(CAS) 작동 방식의 자세히 알아보기 전에 대략적인 개념을 살펴 보겠습니다. 어셈블리가 로드될 때 CLR는 어셈블리에 대한 증거를 수집합니다. 증거에는 다운로드 위치가 포함되며 어셈블리를 작성한 사용자에 대한 정보가 포함될 수 있습니다.

CLR에서는 이 증거를 자체 보안 정책 엔진으로 전달하여 그에 따라 어셈블리에 부여할 사용 권한을 결정합니다. 보안 정책은 코드가 실행될 컴퓨터의 관리자와 사용자가 제어합니다. 그 결과 CLR에서 어셈블리에 첨부하는 권한 집합이 만들어집니다. 이러한 사용 권한은 어셈블리의 코드에서 수행할 수 있는 작업과 수행할 수 없는 작업을 결정하는 데 사용됩니다.

그러면 이 사용 권한이 어떻게 적용될까요? 여기서 잠시 사용자가 작성한 관리 코드에 대해 생각해 보십시오. 전자 메일을 보내거나, 파일에 쓰거나, 웹 서비스나 데이터베이스의 저장 프로시저를 호출하거나, 환경 변수를 읽는 간단한 작업을 수행할 때 어떻게 합니까? 이 경우 .NET Framework에서 제공하는 클래스를 사용합니다. 이러한 클래스는 파일 시스템, 네트워크, 데이터베이스 등과 같은 중요한 리소스에 액세스하는 게이트 역할을 합니다. 보안 정책에서 어셈블리에 특정 파일에 쓸 수 있는 사용 권한을 부여하지 않는 경우 해당 파일을 쓰기 위해 열면 FileStream 클래스에서 SecurityException이 발생합니다.

그렇다면 .NET Framework 클래스를 통해 Win32 함수인 CreateFile을 직접 호출하지 못하게 하는 것은 무엇일까요? 이 작업을 수행하려면 .NET Framework의 interop 계층을 사용해야 하며, interop를 사용할 권한이 부여되지 않은 경우 이 계층에서 SecurityException이 발생합니다. 이것이 완전히 신뢰된 코드에 부여되는 유일한 사용 권한 유형입니다. 부분적으로 신뢰된 어셈블리에서는 P/Invoke 또는 COM interop를 사용할 수 없습니다.

아울러 부분적으로 신뢰된 코드는 형식 안정성이 있어야 실행되므로 .NET Framework 클래스를 피해 기본 코드를 직접 호출하는 포인터를 사용할 수 없습니다. 간단히 말하자면 부분적으로 신뢰된 코드는 .NET 보안 정책에 의해 제한됩니다. 완전히 신뢰된 코드에는 이러한 제한이 없습니다.

이제 코드 액세스 보안의 세 가지 구성 요소인 증거, 사용 권한 및 정책에 대해 자세히 살펴 보겠습니다.

증거

코드 액세스 보안의 모든 특성과 함께 각 증거 형식을 나타내는 클래스가 있으며 특수한 용도가 있는 경우 고유한 증거 형식 클래스를 만들 수 있습니다. 다음 .NET Framework 버전 1.1에서 발생하는 가장 흔한 유형의 증거입니다.

그림 3

이러한 증거는 System.Security.Policy 네임스페이스에서 찾을 수 있는 실제 클래스이며 출처를 쉽게 알 수 있도록 분류했습니다. CLR에서 어셈블리를 다운로드하려면 먼저 어셈블리를 찾을 수 있는 URL이 있어야 합니다. 이 URL은 대개 어셈블리가 로컬 컴퓨터에 설치되거나 네트워크 로드되는지에 따라 file:// URL이거나 http:// URL입니다.

CLR에서는 URL에서 영역과 사이트 증거를 계산합니다. 영역 증거는 단순히 URL이 속한 Internet Explorer 영역입니다. 예를 들어 file://c:\temp\myapp.exe는 내 컴퓨터 영역이고 https://www.xyz.com/utility.dll은 대개 Internet 영역에 속합니다. 영역은 사용자 지정할 수 있기 때문에 "대개"라고 표현했습니다. 예를 들어 www.xyz.com이 신뢰할 수 있는 웹 사이트인 경우 인터넷 옵션 제어판을 통해 해당 사이트를 신뢰할 수 있는 사이트 목록에 추가할 수 있습니다. 이 경우 영역 증거가 신뢰됨 상태가 됩니다.

그림 4

http:// 스타일 URL의 경우 사이트 증거도 계산됩니다. 이 예에서는 사이트가 www.xyz.com입니다.

어셈블리를 다운로드한 후 CLR에서는 해당 콘텐츠를 검사하여 해시, 게시자 및 강력한 이름 증거를 결정합니다. 어셈블리의 해시 값은 어셈블리를 구성하는 각 모듈의 해시가 들어 있는 어셈블리 매니페스트의 SHA1 또는 MD5 해시입니다. 모든 경우에 사용할 수 있도록 어셈블리가 변경되면(단순히 다시 컴파일하는 경우에도) 해시 값이 변경됩니다.

일부 개발자는 Authenticode를 사용하여 어셈블리에 서명합니다. 이 경우에는 CLR가 코드 서명 X.509 인증서를 들어 있는 게시자 증거를 생성합니다. 이 인증서는 공개 키 인프라에 기반하므로 게시자 증거는 보안 정책 결정을 할 수 있는 안전한 방법입니다. 게시자의 개인 키가 위조된 경우 인증 기관에 보고하여 새로운 인증서 해지 목록(CRL)을 공표하게 할 수 있습니다. 즉, 시간이 지나면 사용자가 위조된 키로 서명된 어셈블리를 다운로드한 경우 CLR에서 게시자의 인증서가 해지된 것을 인식하고 해지된 키로 서명된 어셈블리를 실행하지 않게 됩니다.

대부분의 어셈블리에는 강력한 이름이 있으며 이 이름 역시 증거로 패키지됩니다. 하지만 보안 정책에서 강력한 이름 증거를 사용할 때에는 인증서와 같은 키 해지 인프라가 없습니다.

사용 권한

.NET Framework 버전 1.1에서는 전체 권한 집합을 정의하여 파일 및 데이터베이스 액세스부터 스레드 중단과 재개에 이르는 모든 항목을 보호합니다. 증거와 마찬가지로 각 사용 권한은 클래스로 표현되고 필요한 경우 사용자 지정 사용 권한 클래스를 정의할 수 있습니다. 다음은 System.Security.Permissions에 정의되어 있는 사용 권한 클래스의 예입니다.

그림 5

ID 사용 권한은 해당 증거에 직접 매핑되기 때문에 쉽게 알 수 있습니다. 대개 이러한 사용 권한은 클래스나 메서드를 사용할 수 있는 코드를 제한하며 실제로는 부분적으로 신뢰된 시나리오에서만 작동합니다. 여기에서는 더 이상 자세한 내용은 다루지 않겠습니다.

가장 중요한 것은 리소스 사용 권한입니다. 이 사용 권한은 .NET Framework에서 사용할 수 있는 클래스를 제어하며 경우에 따라 해당 클래스에서 사용할 수 있는 메서드와 속성을 제어합니다. 궁극적으로 사용 권한은 코드에서 액세스하는 리소스를 제어합니다.

이러한 사용 권한에는 대부분 매개 변수가 있습니다. UIPermission 클래스에는 그리기가 가능한 창 유형을 제어하는 매개 변수와 클립보드 읽기 허용 여부를 결정하는 매개 변수가 있습니다. SecurityPermission 클래스에는 코드에서 스레드를 일시 중단할 수 있는지 여부부터 interop를 통해 호출하여 기본 코드를 직접 사용할 수 있는지 여부에 이르기까지 다양한 항목을 제어할 수 있는 많은 플래그가 있습니다.

예를 들어 어셈블리에 "c:\temp\*" 경로를 읽는 FileIOPermission이 부여되었다고 가정합니다. 이것은 코드에서 c:\temp와 그 하위 디렉터리에 있는 모든 파일을 읽을 수 있다는 의미입니다. 더 정확히 표현하면 코드를 실행하는 사용자에게 로그인에 기반하여 읽기가 허용된 모든 파일을 읽을 수 있습니다. 아울러 File.Open() 또는 FileStream 생성자에 대한 호출이 성공하기 때문에 사용자에게 메시지가 표시되지 않고 작업이 수행됩니다.

하지만 어셈블리가 부분적으로 신뢰되는 경우 어셈블리에 FileIOPermission이 부여되지 않는 경우가 많습니다. 이런 경우에는 File.Open()을 사용하거나 새로운 FileStream 개체를 생성하여 파일을 직접 열려고 하면 작업에 FileIOPermission이 필요하기 때문에 SecurityException이 발생합니다.

부분적으로 신뢰된 어셈블리에 파일 읽기용 FileDialogPermission만 부여된 경우가 있을 수 있습니다. 이 경우에는 OpenFileDialog 클래스를 사용하여 사용자가 파일을 선택하게 할 수 있습니다. 그런 다음 OpenFileDialog의 OpenFile 메서드를 사용하여 읽기 전용 FileStream을 얻을 수 있습니다. 사용자가 관여한다는 가정 하에 부분적으로 신뢰된 어셈블리에서는 이런 방식으로 파일을 열 수 있습니다.

OpenFileDialog 클래스의 FileName 속성은 사용자가 선택한 파일의 위치와 이름을 공개하기 때문에 이 속성을 사용하려면 FileIOPermission이 필요합니다. 즉, FileDialogPermission만 있는 경우 파일의 내용을 읽는 것만 허용되고 파일의 위치를 알 수 없습니다. 이러한 사실을 알게 되면 혼란스러울 수 있습니다. 그렇기 때문에 부분적으로 신뢰된 코드를 작성하는 것에 대한 후속 기사가 필요합니다.

정책

앞서 로드 시에 CLR의 보안 정책 엔진에서 증거를 검사하고 어셈블리의 권한 집합을 구성하는 방법을 설명했습니다. 모든 조직에 맞는 정책이 없기 때문에 정책 엔진에서는 허용된 사용 권한이 들어 있는 여러 XML 파일을 읽어야 합니다. 이러한 파일이 .NET 보안 정책을 구성합니다.

다행히 이러한 파일을 직접 편집할 필요는 없습니다. .NET Framework 구성 관리 도구를 사용하면 정책을 쉽게 편집할 수 있으며 .NET를 처음 사용하는 사람을 도와주는 다양한 마법사를 사용할 수 있습니다. 정책에 대해 자세히 설명하기 전에 .NET Framework가 제공하는 기본 정책에 대해 살펴 보겠습니다.

기본 정책은 네트워크에서 로드된 코드보다 컴퓨터에 설치된 코드가 더 많이 신뢰할 수 있다는 전제에서 동작합니다. 물론 .NET Framework 자체의 어셈블리는 항상 완전히 신뢰된다는 조건이 있습니다. 결국 이 전체 보안 인프라를 구현하려면 일부 코드가 신뢰되어야 합니다.

문제를 단순하게 만들기 위해서 Microsoft의 기본 정책에서는 영역 증거에 기반하여 사용 권한을 부여합니다. MyComputer 영역에는 완전 신뢰가 부여됩니다. 이것은 CD-ROM 또는 DVD-ROM에서 설치한 응용 프로그램이나 수동으로 다운로드하여 디스크에 저장한 후 실행하는 프로그램과 같이 로컬에 설치된 코드를 나타냅니다.

다음은 LocalIntranet 영역입니다. 이 영역에 속한 웹 사이트를 명시적으로 나열하지 않은 경우 이 영역은 단순히 이름에 "."가 없는 모든 도메인 이름(즉, DNS 이름이 아닌 NETBIOS 호스트 이름)으로 정의됩니다. 예를 들어 http://xyz는 기본적으로 LocalIntranet 영역으로 간주되지만 http://www.microsoft.com은 http://207.46.250.119와 마찬가지로 이름에 마침표가 있기 때문에 Internet 영역에 속합니다. 위 주소의 십진 주소에 해당하는 http://3475962487은 사용할 수 없습니다. 자세한 내용은 Michael Howard의 책, "Writing Secure Code(2판)"에서 "Dotless-IP Address" 버그를 참조하십시오.

기본 보안 정책에서는 LocalIntranet 영역의 어셈블리에 "보통 신뢰" 권한 집합을 할당합니다. 이것은 일반적으로 로컬 네트워크의 코드가 부분 신뢰로 실행된다는 의미입니다. 공유 드라이브에서 관리된 실행 파일을 실행하거나 로컬 컴퓨터에서 관리된 실행 파일(예: z:\MySmartClient.exe)을 실행하면 실행 영역이 더 이상 MyComputer 영역이 아니기 때문에 한 실행 파일이나 두 실행 파일 모두에서 SecurityException이 발생합니다.

Internet Explorer에는 시스템 관리자가 사용자 지정할 수 있는 신뢰할 수 있는 사이트 영역과 제한된 사이트 영역의 두 영역이 정의되어 있습니다. 첫 번째 영역에는 "조금 신뢰" 권한 집합이 부여되며 두 번째 영역은 전혀 신뢰되지 않습니다. 즉, 제한된 사이트의 관리 코드는 기본적으로 실행되지 않습니다.

마지막으로 Internet 영역은 다른 영역에 속하지 않는 모든 URL이 속하는 영역입니다. 이 영역의 기본 할당은 조금 신뢰와 신뢰 안 함 사이에서 왔다갔다했지만 .NET Framework 1.1 버전에서는 안정화되었으며 기본적으로 조금 신뢰 권한 집합에 매핑됩니다.

.NET 보안 정책

정책 작동 방식을 이해하려면 .NET 구성 도구를 직접 사용해 보아야 합니다. 이 도구는 .NET Framework가 설치되어 있는 컴퓨터의 Administrative Tools 폴더에 있습니다. 먼저 아래에 표시된 기본 컴퓨터 정책을 살펴 보겠습니다.

그림 6

매우 많은 사용 권한이 있고 각 사용 권한에 매우 많은 매개 변수가 있기 때문에 자주 사용하는 권한 집합을 구성할 수 있는 Permission Sets라는 폴더가 있습니다. 그림에서 볼 수 있는 것처럼 기본 정책은 이 방식으로 구성되어 있습니다. 앞서 설명한 코드에 부여되는 네 가지 기본 권한 수준을 나타내는 네 가지 기본 권한 집합인 완전 신뢰, 보통 신뢰, 조금 신뢰 및 신뢰 안 함이 있습니다. 다음은 이러한 집합이 정책의 실제 이름에 매핑된 것을 보여 줍니다.

  • FullTrust: "완전 신뢰" 권한 집합입니다.
  • LocalIntranet: "보통 신뢰" 권한 집합입니다.
  • Internet: "조금 신뢰" 권한 집합입니다.
  • Nothing: "신뢰 안함", 사용 권한 없음을 나타냅니다.

이름을 혼동하지 마십시오. 중간의 두 이름이 LocalIntranet과 Internet인 된 것에는 사연이 있지만 이 이름이 MediumTrust 및 LowTrust와 같이 일반적인 것이었다면 혼동은 덜했을 것입니다.

.NET 구성 도구에서 제공하는 몇 가지 마법사를 실행하면 이 네 수준이 실제로 사용되는 것을 확인할 수 있습니다. 예를 들어 런타임 Runtime Security Policy(위 그림에는 표시되어 있지 않지만 도구를 실행하면 볼 수 있음)를 클릭하면 수행할 수 있는 작업 목록이 표시됩니다. 항목 중 하나가 Adjust Zone Security이며 다음은 이 마법사의 일부입니다. 그림에서 네 가지 수준이 있는 슬라이더 막대를 살펴 보십시오.

그림 7

Internet 영역을 선택했기 때문에 스크린 샷에는 슬라이더 막대가 레이블이 없는 두 번째 위치, 즉 "조금 신뢰" 위치에 있습니다. 다른 영역을 클릭하면 그에 따라 슬라이더가 위나 아래로 이동합니다. 예를 들어 "내 컴퓨터" 영역은 기본적으로 FullTrust입니다. 슬라이더가 이동할 때 나타나는 신뢰 수준 설명을 살펴 보십시오. 이 설명을 통해 다양한 신뢰 수준에 배치되는 제한의 종류를 알 수 있습니다. 이 설명의 많은 부분에서 "못할 수도 있습니다"라는 표현이 사용되는 것이 의아하겠지만 저를 믿고 잠시 기다려 주십시오.

예를 들어 슬라이더 막대를 맨 아래 "신뢰 안 함"으로 끌어 놓아 내 컴퓨터 영역에 지정된 사용 권한을 변경합니다. 이렇게 해도 컴퓨터가 중지되는 일은 없으니 걱정하지 마십시오. 이렇게 변경한 후 다음과 같은 단순한 응용 프로그램을 컴파일하고 실행해 보십시오.

class DoesNothing {
    static void Main() {}
}

이 코드를 실행하면 코드 실행이 허용되지 않았음을 나타내는 PolicyException이 발생해야 합니다. 하지만 .NET 구성 도구(관리된 응용 프로그램임)를 닫고 코드를 다시 실행하면 새로운 설정 상태에서도 코드가 문제 없이 실행된다는 것을 알 수 있습니다. 그런 다음 마법사로 돌아가 정책을 다시 보통으로 설정합니다. 연습을 마쳤으면 Runtime Security Policy 폴더를 마우스 오른쪽 단추로 클릭하고 "모두 원래대로"를 선택하여 기본 정책을 복구할 수 있습니다.

이 현상은 무엇일까요? 어떤 일이 발생했는지 설명하기 위해서는 보안 정책에서 사용 권한이 실제로 부여되는 Code Groups 폴더에 대해 설명해야 합니다. 각 코드 그룹에는 조건부 사용 권한이 부여됩니다. 예를 들어 My_Computer_Zone이라는 코드 그룹을 마우스 오른쪽 단추로 클릭하고 속성 시트를 엽니다.

Figure 8

각 코드 그룹에 구성원 조건과 권한 집합이 있다는 것을 알 수 있습니다. 이 경우 조건은 영역 증거에 기반합니다. 이 코드 그룹은 내 컴퓨터 영역의 모든 어셈블리(즉, 영역 증거가 MyComputer인 모든 어셈블리)로 구성됩니다.

권한 집합 탭을 클릭하면 이 그룹과 일치하는 모든 코드에 완전 신뢰 권한 집합이 부여된 것을 알 수 있습니다. 각 코드 그룹에는 단순히 조건부 사용 권한이 부여됩니다. 어셈블리가 구성원 조건과 일치하는 경우 해당 권한 집합에 나열된 모든 사용 권한을 얻게 됩니다. 이 경우는 FullTrust입니다.

이제 위의 마법사 동작을 설명할 수 있어야 합니다. 슬라이더를 위와 아래로 이동하여 변경하는 것이 실제로는 My_Computer_Zone 코드 그룹의 권한 집합을 위에 나열된 네 가지 권한 집합인 FullTrust, LocalIntranet, Internet 및 Nothing 중 하나로 변경하는 것입니다.

연습을 한 후에는 My_Computer_Zone 코드 그룹의 권한 집합을 Nothing으로 설정한 상태에서도 여전히 .NET 구성 도구와 Visual Studio .NET 같은 프로그램을 실행할 수 있다는 것을 눈치챘을 것입니다. 이러한 프로그램은 완전하게 관리되지 않지만 내 컴퓨터 영역을 신뢰 안 함으로 낮췄을 때 실행되어서는 안 되는 관리 코드를 로컬 컴퓨터에서 로드합니다.

이 수수께끼의 정답은 My_Computer_Zone에서 확장한 코드 그룹 폴더를 살펴 보면 찾을 수 있습니다.

그림 9

그림에서 볼 수 있는 것처럼 코드 그룹은 트리에 배치됩니다. 마법사에서 수행한 작업은 My_Computer_Zone 코드 그룹과 연결된 권한 집합을 변경한 것이지만 My_Computer_Zone에 부여된 권한 집합에 관계 없이 권한을 부여할 수 있는 두 개의 코드 그룹이 그 아래에 있습니다. 이 두 코드 그룹에는 위에서 설명한 실험 I과 같은 엄청난 변화에도 .NET Framework와 관련 도구가 정상적으로 작동할 수 있는 권한이 부여되어 있습니다. 코드 그룹은 트리 상단(All_Code)에서 아래로 평가되고 부모 노드가 일치(All_Code는 모든 어셈블리와 일치)하는 경우 자식 노드가 평가됩니다. 따라서 모든 CLR 어셈블리와 도구에 있는 Microsoft_Strong_Name으로 인해 .NET 구성 도구가 실행됩니다. 이러한 코드 그룹을 직접 편집할 수 있지만 앞서 사용한 마법사에서는 단순히 영역 기반 코드 그룹만 변경하기 때문에 제한 작업을 설명할 때 "못할 수도 있습니다"라는 다소 모호한 표현을 사용하는 것입니다.

이 기사에서 정책의 미묘함 전체를 설명할 수는 없지만 정책에 융통성이 많다는 것은 확인하셨으리라 믿습니다. 코드 그룹 트리를 사용하면 다양한 증거 조합에 기반한 사용 권한을 부여할 수 있으며 Permission Sets 폴더를 사용하면 반복 작업을 할 필요 없이 사용 권한을 구성할 수 있습니다.

결론

코드를 검증하고 제한하는 포괄적인 보안 시스템이 없는 상태에서 네트워크를 통해 코드를 배포하는 것은 위험합니다. 코드 액세스 보안(CAS)은 이 문제를 해결하기 위한 is Microsoft의 솔루션입니다. 이 솔루션은 융통성이 뛰어나지만 다소 복잡합니다. 하지만 스마트 클라이언트를 만드는 개발자는 이 솔루션을 통해 할 수 있는 일을 배워야 하며 그 지식이 업무에 큰 도움이 될 것입니다.

 

저자 정보

Keith Brown은 고급 개발자 교육 회사인 Pluralsight의 공동 창업자로 개발자를 위한 보안이 전문 분야입니다. Keith Brown은 MSDN Magazine에 Security Briefs 칼럼을 연재하고 있으며 The .NET Developer's Guide to Windows Security(Addison Wesley, 2004)와 Programming Windows Security(Addison Wesley, 2000)를 집필했습니다. Keith Brown은 TechEd 및 WinDev를 포함한 많은 컨퍼런스에서 강의를 했습니다. 자세한 내용은 블로그(www.pluralsight.com/keith (영문))를 참조하십시오.

Microsoft