ASP.NET 4 응용 프로그램의 코드 액세스 보안

아티클
10/15/2014

CAS(코드 액세스 보안)는 코드 실행 기능에 대한 제약 조건을 적용하기 위해 ASP.NET에서 사용되는 .NET Framework 보안 메커니즘("샌드박스")입니다. ASP.NET은 ASP.NET 1.1부터 신뢰 수준 개념을 사용하여 코드 액세스 보안을 구현했습니다.

이 항목에서는 ASP.NET 4에서의 CAS 작동 방식에 대해 설명하고 특히 이전 버전과 비교하여 어떻게 변경되었는지에 대해 설명합니다. ASP.NET을 처음 사용하는 사용자의 경우에는 변경 사항에 대한 관심이 없을 수도 있습니다. 하지만 이 항목에는 새 응용 프로그램을 디자인하는 데 영향을 줄 수 있는 현재 ASP.NET 버전에서의 CAS 작동 방식에 대한 정보가 포함되어 있습니다.

이 항목에서는 다음과 같은 주제에 대해 설명합니다.

CAS 정책 수준이 더 이상 사용되지 않는 이유와 이러한 변경이 부분 신뢰 ASP.NET 응용 프로그램을 UNC 공유에서 실행하도록 설정하는 등의 일반적인 시나리오에 미치는 영향
ASP.NET 4에서 CAS 동작을 사용자 지정하는 방법
ASP.NET 4에서 CAS를 사용하도록 신뢰 코드를 설정할 때의 호환성 문제

이 항목에서는 사용자가 .NET Framework CAS와 ASP.NET 신뢰 수준을 이해하고 있는 것으로 가정합니다. 이러한 항목들에 대한 자세한 내용은 다음 문서를 참조하십시오.

방법: ASP.NET 2.0에서 Medium 신뢰 사용
ASP.NET에서 코드 액세스 보안 사용
.NET Framework 4의 보안 변경 내용
Shawn Farkas의 CAS 정책 및 CLR 관련 블로그 시리즈
이 항목에서는 다음 내용에 대해 설명합니다.
ASP.NET 4 코드 액세스 보안 모델 개요
유형이 같은 응용 프로그램 도메인
조건부 APTCA 연산자
보안 투명성과 ASP.NET 4에서의 작동 방식

ASP.NET 4 코드 액세스 보안 모델 개요

ASP.NET 4에서는 ASP.NET 3.5 및 이전 버전과 달리 다음과 같은 여러 가지 기본적인 요소가 변경되었습니다.

기본적으로 ASP.NET 4 부분 신뢰 응용 프로그램 도메인은 유형이 같은 응용 프로그램 도메인입니다. 따라서 부분 신뢰 응용 프로그램 도메인에서 실행되는 코드에 대해 사용할 수 있는 권한 집합이 제한됩니다. 또한 응용 프로그램 도메인의 신뢰 경계 자체도 부분 신뢰 권한 부여 집합과 연결됩니다. 유형이 같은 응용 프로그램 도메인에서 보안 정책은 컴퓨터 수준, 사용자 수준 또는 엔터프라이즈 수준 CAS 정책과 교차되지 않습니다.

참고

새로운 유형이 같은 응용 프로그램 도메인 모델에는 이전 버전의 ASP.NET에서 사용된 정책 파일과는 약간 다른 선언적인 ASP.NET 신뢰 정책 파일 집합이 필요합니다.따라서 ASP.NET 4를 설치하면 컴퓨터에 두 가지 ASP.NET 부분 신뢰 정책 파일 집합이 포함됩니다.이 중 한 가지 집합은 새로운 CAS 모델에 사용되고, 다른 집합은 응용 프로그램이 ASP.NET 4 이전의 CAS 모델을 사용하도록 구성된 경우에 사용됩니다.
이전 버전의 ASP.NET에서는 웹 이외의 부분 신뢰 환경에서 ASP.NET 형식을 사용할 수 없도록 방지하기 위해 AspNetHostingPermission 특성이 거의 모든 공용 ASP.NET 관련 클래스에서 사용되었습니다. 예를 들어 AspNetHostingPermission 특성이 있어서 부분 신뢰 ClickOnce 응용 프로그램에서는 대부분의 ASP.NET 클래스를 사용하지 못했습니다. ClickOnce 응용 프로그램의 CAS에 대한 자세한 내용은 ClickOnce 응용 프로그램의 코드 액세스 보안을 참조하십시오. ASP.NET 4는 AspNetHostingPermission 특성을 사용하는 대신 AllowPartiallyTrustedCallersAttribute 형식을 기반으로 하는 조건부 APTCA라는 다른 CAS 기술을 사용하여 동일한 결과를 제공합니다. 따라서 대부분의 ASP.NET 형식 및 멤버에서 AspNetHostingPermission 특성이 제거되었습니다.
ASP.NET 4에서는 많은 시스템 어셈블리가 CLR 보안 투명성 모델을 사용하도록 업데이트되었습니다. ASP.NET 4의 투명성 모델은 Silverlight에 사용되는 투명성 모델과 매우 유사합니다. 코드 투명성에 대한 자세한 내용은 보안 투명 코드를 참조하십시오.

이전에 caspol.exe와 같은 도구를 사용하여 만든 사용자 지정된 CLR CAS 정책을 사용했다면 이러한 변경으로 인한 효과를 알 수 있을 것입니다. 이러한 변경은 ASP.NET 또는 .NET Framework 코드만 호출 스택에서 활성화되었을 때 권한이 부여된 작업을 수행하기 위해 GAC에 배포된 어셈블리를 사용하는 부분 신뢰 웹 응용 프로그램에도 영향을 줍니다. 다음 단원에서는 CAS의 변경 내용에 대해 설명합니다.

유형이 같은 응용 프로그램 도메인

이 단원에서는 유형이 같은 응용 프로그램 도메인에 대해 설명합니다. 여기에서는 ASP.NET 2.0 이래로 유형이 같은 응용 프로그램 도메인이 만들어지게 된 동작 변경 내용에 대해 설명합니다. 또한 설정 가능한 호환성 옵션과 유형이 같은 응용 프로그램 도메인에서 코드를 실행하기 위해 수행 가능한 코드 변경에 대해 설명합니다.

사용 가능한 권한 집합 수 감소

유형이 같은 응용 프로그램 도메인은 코드 실행을 위한 공유 권한 집합을 정의하는 부분 신뢰 응용 프로그램 도메인입니다. ASP.NET 4에서 호스팅되는 유형이 같은 응용 프로그램 도메인에서 로드할 수 있는 코드는 다음 두 가지 권한 집합 중 하나와 연결됩니다. 코드는 완전 신뢰로 실행되거나(GAC 코드가 항상 완전 신뢰로 실행됨), 현재 trustLevel 설정으로 정의된 부분 신뢰 권한 집합으로 실행됩니다. 자세한 내용은 securityPolicy에 대한 trustLevel 요소(ASP.NET 설정 스키마)를 참조하십시오.

참고

ASP.NET 4 응용 프로그램 도메인의 기본값은 완전 신뢰입니다.ASP.NET 4에서 유형이 같은 동작은 trustLevel 요소의 name 특성이 Full 이외의 값으로 설정된 후에만 적용됩니다.

이 동작은 이전 버전의 ASP.NET에서 사용되는 부분 신뢰 응용 프로그램과 다릅니다. 이전 버전에서는 서로 다른 권한 부여 집합과 서로 다른 멤버 자격 조건을 갖는 여러 권한 집합을 만들 수 있었습니다. 유형이 같은 응용 프로그램 도메인은 이와 같이 혼합된 권한 시나리오를 처리하는 데 어려움이 있기 때문에 .NET Framework 4에 도입되었습니다. 이전에는 코드가 실행되는 모든 조건을 고려하여 권한 수준이 서로 다른 여러 권한 집합을 만들고, 서로 다른 권한 수준이 실제로 적용되는지 입증하기가 어려웠습니다. 예를 들어 코드가 리플렉션으로 실행되거나, 완전 신뢰 코드가 부분 신뢰 호출자를 대신하여 다른 완전 신뢰 코드를 실행하는 경우 등이 발생할 수 있었습니다. 권한 집합에서는 이러한 모든 조건을 고려해야 했습니다. 유형이 같은 응용 프로그램 도메인은 발생 가능한 결과를 줄임으로써 CAS에 대한 결정을 크게 단순화합니다. 코드는 완전 신뢰 권한 집합을 포함하거나 잘 정의된 단일 부분 신뢰 권한 집합을 포함합니다. ASP.NET에서 잘 정의된 부분 신뢰 권한 집합은 지정된 ASP.NET 신뢰 수준에 적용되는 권한 집합입니다.

유형이 같은 응용 프로그램 도메인에서 코드를 로드하려고 시도할 때 코드에는 세 번째 상태가 적용될 수 있습니다. CLR에서는 이를 별도의 권한 집합으로 간주하지 않습니다. 세 번째 권한 집합은 모든 ASP.NET 부분 신뢰 구성 파일에서 Nothing 권한 집합으로 정의되는 빈 권한 집합입니다. Nothing 권한 집합으로 평가되는 모든 코드는 로드할 수 없는 것으로 간주됩니다. 따라서 Nothing 권한 집합이 포함된 어셈블리를 유형이 같은 응용 프로그램 도메인에 로드하려고 시도하면 SecurityException 예외가 발생합니다.

ASP.NET 부분 신뢰 정책만 적용

유형이 같은 응용 프로그램 도메인의 부분 신뢰 권한 집합은 응용 프로그램 도메인 생성 책임이 있는 호스트에 의해서만 설정됩니다. 즉, ASP.NET 4에서는 부분 신뢰 권한 집합이 .NET Framework 설치의 CONFIG 하위 디렉터리에 있는 부분 신뢰 구성 파일의 내용으로만 정의됩니다. 기본적으로 ASP.NET 4 부분 신뢰 응용 프로그램 도메인의 ASP.NET 정책 정보는 더 이상 엔터프라이즈, 컴퓨터 또는 사용자 CAS 정책 설정과 중첩되지 않습니다.

전역 CAS 정책 정보(이전에는 관리자가 caspol.exe 또는 Mscorcfg.msc MMC 구성 도구 등을 사용하여 관리하던 정책)는 더 이상 ASP.NET 4 유형이 같은 응용 프로그램 도메인에 어떠한 영향도 주지 않습니다. ASP.NET 설정이 엔터프라이즈, 컴퓨터 및 사용자 정책과 교차되는 이전 CAS 모델을 사용하도록 ASP.NET을 구성할 수 있습니다. 이러한 레거시 동작에 대해서는 이 단원의 뒷부분에서 설명합니다.

가장 눈에 띄는 변경 내용은 UNC에서 호스팅하는 부분 신뢰 ASP.NET 4 응용 프로그램에 대한 것입니다. 이전 릴리스에서는 ASP.NET 부분 신뢰 정책을 사용하기 위해서는 caspol.exe를 사용하여 UNC 공유의 권한을 완전 신뢰로 상승시켜야 했습니다. 이전 버전의 ASP.NET에서는 기본 컴퓨터 수준의 CLR CAS 정책이 먼저 적용되었기 때문입니다. 따라서 UNC에서 호스팅되는 응용 프로그램에는 인트라넷 영역과 연결된 제한된 권한 집합이 포함되었습니다. ASP.NET 4 부분 신뢰 응용 프로그램 도메인은 ASP.NET 정책 파일에서만 정책을 설정하므로 웹 응용 프로그램의 실제 위치는 더 이상 부분 신뢰 응용 프로그램과 연결되는 권한 집합에 아무런 영향도 주지 않습니다.

관리자가 모든 관리 코드에 대한 실행 권한을 기본적으로 거부할 수 있도록 웹 서버를 잠근 후 선택한 ASP.NET 응용 프로그램에 대해 실행 권한을 부여하는 시나리오에서는 이러한 변경으로 인한 부작용에 대해 설명합니다. 이전 버전의 ASP.NET에서는 이를 위해 잘 알려지지 않은 해결 방법이 필요했습니다. 이 방법에 대해서는 기술 자료 문서 수정: My_Computer_Zone 코드 그룹을 "완전 신뢰" 권한 집합과 연결하지 않은 경우 ASP.NET 2.0 웹 응용 프로그램을 실행하려고 할 때 표시되는 오류 메시지: "서버 응용 프로그램을 사용할 수 없습니다."에 설명되어 있습니다. ASP.NET 4에서는 관리자가 다음과 같은 단계에 따라 웹 서버를 잠그고 실행 권한을 거부하거나 부여할 수 있습니다.

정책 파일이 모든 코드를 Nothing 권한 집합(빈 권한 집합)에 매핑하는 사용자 지정 ASP.NET 신뢰 수준을 만든 다음 모든 ASP.NET 응용 프로그램이 기본적으로 이 권한 수준을 사용하도록 구성합니다. 이 작업은 루트 Web.config 파일에서 수행합니다.
선택적으로 개별 ASP.NET 응용 프로그램을 관리 코드에 대한 실행 권한(및 기타 필요한 권한)을 부여하는 기본 제공 또는 사용자 지정 신뢰 수준과 연결합니다. 컴퓨터 전체 수준에 적용하기 위해서는 루트 Web.confg 파일에서 location 요소를 사용하여 신뢰 수준을 선택적으로 지정할 수 있습니다.

신뢰 정책 파일의 위치 및 명명 규칙

CAS 정책 파일의 위치와 명명 규칙은 이전 버전의 ASP.NET과 동일합니다. 기본 신뢰 수준은 Full, High, Medium, Low 및 Minimal입니다. High부터 Minimal까지 부분 신뢰 권한 집합을 정의하는 정책 파일은 모두 .NET Framework 설치 디렉터리의 CONFIG 하위 디렉터리에 있습니다.

정책 파일의 이름은 다음과 같은 패턴을 사용하여 지정됩니다.

web_[trustlevelname]trust.config

예를 들어 Medium 신뢰에 대한 부분 신뢰 권한 집합은 web_mediumtrust.config라는 파일에 있습니다.

ASP.NET 4의 신뢰 정책 파일 변경 내용

대부분의 경우 ASP.NET 4 CAS 정책 파일의 정보는 이전 릴리스의 정책 파일에 있는 정보와 동일합니다. 하지만 .NET Framework 3.5 및 .NET Framework 4 기능에는 몇 가지 추가된 사항이 있습니다. 유형이 같은 응용 프로그램 도메인과 연결된 부분 신뢰 권한 집합의 이름은 ASP.Net입니다. 또한 기본적으로 웹 응용 프로그램 디렉터리 구조 또는 코드 생성 디렉터리 구조에 있는 모든 코드에는 명명된 ASP.Net 권한 집합으로부터 권한이 부여됩니다.

부분 신뢰 정책 파일은 이전 버전에서 다음과 같은 두 가지 사항이 변경되었습니다.

각 ASP.NET 4 CAS 정책 파일의 끝에는 Microsoft 서명 키 및 ECMA 서명 키에 완전 신뢰를 매핑하는 CodeGroup 요소가 더 이상 없습니다. 이러한 항목은 GAC가 항상 암시적으로 완전 신뢰를 갖는다고 가정할 수 없었던 이전 버전의 레거시 항목이기 ASP.NET 4에서 제거되었습니다.
SecurityPermission 특성의 Assertion 부분이 모든 ASP.NET 4 CAS 정책 파일에서 제거되었습니다. .NET Framework 4의 CLR에서 변경된 기본적인 사항은 부분 신뢰 코드가 권한을 어설션할 수 없다는 점입니다. 즉, 부분 신뢰 코드가 이미 갖고 있는 권한을 어설션하려고 시도할 경우에도 부분 신뢰 코드가 실패합니다.

부분 신뢰 범위

유형이 같은 응용 프로그램 도메인이란 ASP.NET 4 응용 프로그램 도메인 경계가 부분적으로 신뢰되어 있다는 의미입니다. 응용 프로그램이 부분 신뢰로 실행되면 보안 요구로 인해 스택 워크가 발생합니다. 스택의 모든 코드는 요구된 권한에 따라 평가됩니다. ASP.NET 3.5 및 이전의 응용 프로그램 도메인에서는 코드 경로에서 응용 프로그램 도메인 경계까지 스택 워크가 발생하는 것이 일반적이었습니다. ASP.NET 4 이전의 ASP.NET 버전에서는 응용 프로그램 도메인 경계가 암시적으로 완전 신뢰였기 때문에 일부 코드 경로의 스택 워크가 성공할 수 있었습니다. ASP.NET 4의 유형이 같은 응용 프로그램 도메인에서는 응용 프로그램 도메인 경계에 도달하는 모든 스택 워크가 현재 응용 프로그램 도메인에 대해 적용되는 부분 신뢰 권한 집합에 따라 평가됩니다.

응용 프로그램 도메인 경계 자체가 현재 부분적으로 신뢰된다는 사실이 가장 공통적인 CAS 변경 사항이며, 그 결과 일반적으로 ASP.NET 4에서 작동할 수 있도록 완전 신뢰 코드를 변경해야 합니다. 예를 들어 ASP.NET 개발 팀은 보안 요구를 억제하고 보안 요구가 응용 프로그램 도메인 경계까지 증가하지 않도록 방지하기 위해 무수히 많은 내부 코드 경로에서 대상 보안 어설션을 추가해야 했습니다. 개발 팀에서 이러한 작업을 수행하지 않았다면 페이지 컴파일과 같은 기본적인 작업도 Medium과 같은 신뢰 수준에 대한 부분 신뢰 권한 집합과 비교할 때 작업에 대한 보안 요구(예: 컴파일을 위한 파일 I/O 권한)가 실패하기 때문에 기본 작업이 실패했을 것입니다.

ASP.NET 내에는 ASP.NET 코드만 스택에 있을 때 완전 신뢰 코드를 로드하고 실행할 수 있도록 하는 확장성 지점이 있습니다. 이러한 시나리오의 경우, ASP.NET이 일종의 확장성 지점을 구현하는 사용자 지정 형식으로 코드를 호출할 때 스택에는 처음에 ASP.NET 코드만 있습니다. 사용자 지정 형식이 완전 신뢰이면(형식이 GAC에 배포된 경우에만 발생 가능) 전체 호출 스택이 완전 신뢰 코드로 구성됩니다. 유형이 같은 응용 프로그램 도메인에서는 완전 신뢰 확장성 형식의 코드가 보안 요구를 트리거할 경우 그러한 요구가 결국 응용 프로그램 도메인 경계에 도달합니다. 그런 다음 부분 신뢰 권한 집합에 따라 보안 검사를 수행할 때 코드가 실패합니다.

다음은 이러한 상황이 발생할 수 있는 일부 ASP.NET 확장성 지점 목록입니다.

사용자 지정 HTTP 처리기. 사용자 지정 처리기는 파이프라인의 처리기 실행 단계 중에 호출됩니다.
사용자 지정 HTTP 모듈. 사용자 지정 HTTP 모듈은 모듈이 등록된 파이프라인 이벤트 중에 호출됩니다.
사용자 지정 빌드 공급자 및 식 작성기. 이러한 유형은 .aspx 파일과 같은 실행 가능 콘텐츠를 구문 분석하고 컴파일할 때 ASP.NET에 의해 호출됩니다.
역할 관리자 공급자. 파이프라인의 AuthorizeRequest 이벤트 중에 사용자 지정 공급자가 호출될 수 있습니다.
프로필 공급자. EndRequest 이벤트 중에 프로필 데이터를 자동으로 저장하기 위해 사용자 지정 공급자를 호출할 수 있습니다.
상태 모니터링 공급자. 누적된 상태 모니터링 데이터를 저장하기 위해 무작위로 사용자 지정 공급자를 호출할 수 있습니다.

사용자 지정 HTTP 처리기에 대한 간단한 다음 예제에서는 CAS 동작의 변경 사항을 보여 줍니다. 다음 예제에서는 처리기 코드가 C:\ 드라이브의 루트에 있는 텍스트 파일을 읽으려고 시도합니다.

Public Class CustomHandler 
    Implements IHttpHandler 
    Public Sub ProcessRequest(ByVal context As HttpContext) 
        Dim data As String = File.ReadAllText("c:\testfile.txt") 
        context.Response.Write(data) 
    End Sub 
    
    Public Sub New() 
    End Sub 
    
    Public ReadOnly Property IsReusable() As Boolean 
        Get 
            Return False 
        End Get 
    End Property 
End Class

public class CustomHandler : IHttpHandler

{

public void ProcessRequest(HttpContext context)

{

string data = File.ReadAllText("c:\\testfile.txt");

context.Response.Write(data);

}

public CustomHandler() { }

public bool IsReusable { get { return false; } }

}

처리기가 서명되었고, AllowPartiallyTrustedCallersAttribute 특성으로 표시되고, GAC에 배포된 경우에는 ASP.NET 3.5 또는 이전 버전의 Medium 신뢰 응용 프로그램에서 처리기를 사용할 때 코드가 성공합니다. 이 예제에서는 Medium 신뢰에서 부분 신뢰 권한 집합이 응용 프로그램의 디렉터리 구조에 대해서만 읽기/쓰기 파일 I/O를 허용하기 때문에 Medium 신뢰가 선택되었습니다. 예제 처리기와 같은 완전 신뢰 코드는 ASP.NET 3.5 및 이전 버전의 다른 파일 위치에 액세스할 수 있습니다. 그 이유는 처리기가 실행될 때 완전 신뢰 코드만 스택에 있고 응용 프로그램 도메인 경계 자체도 완전 신뢰이기 때문입니다. 따라서 ReadAllText 호출의 파일 I/O 요구는 완전 신뢰인 응용 프로그램 도메인 경계에서 암시적으로 충족됩니다.

하지만 동일한 처리기 코드를 Medium 신뢰의 ASP.NET 4 응용 프로그램에서 사용할 경우에는 ReadAllText에 대한 호출로 인해 텍스트 파일에 대한 읽기 액세스의 파일 I/O 요구가 발생하기 때문에 코드가 실패합니다. 파일 I/O 요구는 스택 워크를 일으키며, 이 스택 워크는 결국 응용 프로그램 도메인 경계에 도달합니다. ASP.NET 4에서 응용 프로그램 도메인 경계는 Medium 신뢰 권한 집합과 연결되며, 이러한 권한 집합은 C:\ 드라이브의 루트에 대한 액세스 권한을 부여하지 않습니다. 따라서 파일 I/O 요구가 실패합니다.

ASP.NET 4에서는 스택 워크를 억제해야 합니다. 이를 위해서는 ProcessRequest 메서드에서 FileIOPermission 특성의 SecurityAction.Assert 특성을 사용합니다. 다음 예제에서는 이러한 목적으로 FileIOPermission 특성을 사용하는 방법을 보여 줍니다.

[Visual Basic]

Public Class CustomHandler 
    Implements IHttpHandler 

    <FileIOPermission(SecurityAction.Assert, Read = "c:\testfile.txt")> _ 
    Public Sub ProcessRequest(ByVal context As HttpContext) 
        Dim data As String = File.ReadAllText("c:\testfile.txt") 
        context.Response.Write(data) 
    End Sub 
    
    Public Sub New() 
    End Sub 
    Public ReadOnly Property IsReusable() As Boolean 
        Get 
            Return False 
        End Get 
    End Property 
End Class

[C#]

public class CustomHandler : IHttpHandler

{

[FileIOPermission(SecurityAction.Assert, Read = "c:\\testfile.txt")]

public void ProcessRequest(HttpContext context)

{

string data = File.ReadAllText("c:\\testfile.txt");

context.Response.Write(data);

}

public CustomHandler() { }

public bool IsReusable { get { return false; } }

}

선언적 어설션(예제 참조) 또는 프로그래밍 방식의 어설션을 사용할 수 있습니다. 코드 블록이 작동되는 데 필요한 최소한의 권한만 선언적으로 어설션하는 것이 가장 좋습니다. 모든 위치에 제한이 없는 보안 어설션을 추가하는 것이 간단한 해결 방법으로 생각될 수도 있지만 이러한 방식은 사용해서는 안됩니다. 새로운 유형이 같은 응용 프로그램 도메인 동작으로 인해 발생하는 보안 오류를 해결하기 위해서는 완전 신뢰 코드를 분석하고 완전 신뢰 코드에 요구되는 권한이 필요한 작업을 이해해야 합니다. 그런 다음 완전 신뢰 코드를 다시 사용하도록 설정하는 데 필요한 최소한의 권한을 선택적으로 어설션할 수 있습니다.

ASP.NET 2.0 CAS 모델을 사용하도록 ASP.NET 4 응용 프로그램 구성

ASP.NET 1.0 및 ASP.NET 2.0 CAS 동작을 사용하도록 ASP.NET 4 응용 프로그램을 구성할 수 있습니다. ASP.NET 4에서는 trust 요소에서 기본적으로 false로 설정되는 새 legacyCasModel 특성을 제공합니다. 이 특성을 true로 설정하면 이전 버전에서 전부는 아니지만 대부분의 ASP.NET CAS 동작을 사용하도록 ASP.NET 4 응용 프로그램이 구성됩니다.

LegacyCasModel 특성이 true로 설정되면 다음과 같은 동작이 발생합니다.

부분 신뢰 응용 프로그램 도메인 경계에 완전 신뢰가 사용됩니다. 즉, 완전 신뢰 코드가 스택에서 완전 신뢰 코드로만 실행되는 시나리오에서는 보안 요구를 억제하기 위해 어설션을 사용할 필요가 없습니다.
.NET Framework 4에 대해 정의된 엔터프라이즈, 컴퓨터 및 사용자 CAS 정책에 대한 설정은 ASP.NET CAS 정책과 교차됩니다. 즉, .NET Framework 4 caspol.exe 또는 Mscorcfg.msc를 사용하여 만든 모든 사용자 지정 권한이 적용됩니다.

참고

기본 보안 정책 파일과 .NET Framework 4의 caspol.exe 도구는 .NET Framework 2.0과 다른 디렉터리에 있기 때문에 .NET Framework 2.0에 대해 만든 모든 사용자 지정 보안 정책은 .NET Framework 4 버전의 caspol.exe를 사용하여 .NET Framework 4에 대해 다시 만들어야 합니다.
서로 다른 어셈블리에 적용되는 여러 사용자 지정 권한 집합을 지정할 수 있습니다.

다음 CAS 관련 동작은 레거시 CAS 모드에서도 변경되지 않습니다.

ASP. NET 4 어셈블리는 여전히 조건부 APTCA로 표시됩니다. 조건부 APTCA에 대해서는 이 항목의 뒷부분에서 설명합니다. 조건부 APTCA는 대부분의 공용 ASP.NET 4 API에서 AspNetHostingPermission 특성을 제거하게 되기 때문에 레거시 모드로 되돌릴 수 없습니다. 레거시 CAS 모드로 실행될 때 ASP.NET 공용 API에 해당 권한을 적용하고 어셈블리가 새 CAS 모델에서 실행될 때는 권한을 적용하지 않는 효율적인 방법은 없습니다.
부분 신뢰 코드는 더 이상 어떠한 권한도 어설션할 수 없습니다. 이전에 부분 신뢰가 부여된 코드는 Assert 메서드를 호출하고 부분 신뢰 코드가 이미 부여된 모든 권한을 성공적으로 어설션할 수 있습니다. .NET Framework 4에서는 ASP.NET 응용 프로그램에 적용되는 CAS 모델에 관계없이 부분 신뢰 코드가 더 이상 보안 어설션을 수행하도록 허용되지 않습니다.

trust 요소의 LegacyCasModel 특성이 true로 설정되었을 때 레거시 CAS 모델에 적용되는 권한 집합을 새 CAS 모델에 적용되는 단일 권한 집합과 구분하기 위해 ASP.NET 4는 다른 부분 신뢰 구성 파일 집합에서 CAS 정책을 읽습니다. ASP.NET의 기본 제공 신뢰 수준으로 존재하는 모든 신뢰 정책에는 두 가지 버전의 파일이 존재합니다. ASP.NET은 새 CAS 모델에 대해 한 버전을 읽고 레거시 CAS 모델에 대해 다른 버전을 읽습니다. 예를 들어 Medium 신뢰의 경우 ASP.NET 4가 레거시 모드로 실행되면 이름이 legacy.web_mediumtrust.config인 정책 파일을 읽습니다. 이 파일은 이름이 "legacy"로 시작됩니다. ASP.NET 4는 모든 CAS 정책 파일에 대해 ASP.NET의 기본 제공 신뢰 수준과 동일한 명명 규칙을 사용합니다. 레거시 CAS 정책 파일과 레거시가 아닌 CAS 정책 파일 간의 중요한 차이점은 레거시 파일에 Microsoft 서명 키와 ECMA 서명 키를 참조하는 CodeGroup 정의가 포함된다는 점입니다.

이전 CAS 모델을 사용하도록 응용 프로그램을 구성할 수 있기 때문에 기존 응용 프로그램에 대해 LegacyCasModel 옵션을 true로 설정하여 코드를 변경하지 않을 수 있습니다. 하지만 레거시 옵션의 목적은 기본적으로 기존 응용 프로그램을 ASP.NET 4 CAS 모델로 쉽게 변환하기 위한 것이라는 점을 알아야 합니다. 이후에는 CLR 및 ASP.NET 팀 모두 새로운 CAS 모델을 사용하여 설계 및 코딩하는 데 주력할 것입니다.

Silverlight 2는 새 모델로 이동된 .NET Framework의 첫 번째 기능 영역입니다. .NET Framework의 목적은 새 CAS 모델에서 실행되도록 모든 데스크톱 및 서버 부분 신뢰 시나리오를 이동하기 위한 것입니다. 따라서 CAS 모델에서 작동하도록 응용 프로그램을 다시 설정하는 노력을 기울이는 것이 좋습니다. 또한 이전에 caspol.exe와 Mscorcfg.msc를 사용하던 관리자도 대신 ASP.NET 부분 신뢰 정책 파일과 권한 할당을 사용자 지정해야 합니다.

ASP.NET 4 CAS 모델에서 권한 집합 할당 사용자 지정

ASP.NET 4의 유형이 같은 응용 프로그램 도메인이 완전 신뢰 또는 명명된 ASP.NET 부분 신뢰 권한 집합으로 코드를 제한하더라도 개발자 및 관리자는 권한 집합을 어셈블리와 연결하는 프로세스에 영향을 줄 수 있습니다. 다음과 같은 방법을 통해 약간의 실행 코드를 사용하여 권한 집합을 연결하는 방식을 사용자 지정할 수 있습니다.

개별 신뢰 수준에 대해 부분 신뢰 정책 파일을 사용자 지정할 수 있습니다. 이 방법은 이전 버전의 ASP.NET에서 사용할 수 있는 방법입니다.
ASP.NET 4 완전 신뢰 어셈블리를 정적으로 구성할 수 있습니다.
ASP.NET 4 HostSecurityPolicyResolver 형식을 사용하여 제한된 방식으로 CLR HostSecurityManager 클래스의 기능을 액세스할 수 있습니다.

이러한 방법 중 처음 두 가지 방법을 사용하면 사용자 지정을 선언적으로 만들 수 있으며, 세 번째 옵션에서는 사용자 지정을 코드로 만들 수 있습니다.

신뢰 수준에 대한 정책 파일 사용자 지정

ASP.NET 부분 신뢰 정책 파일을 수정하는 첫 번째 방법은 이전 버전의 ASP.NET과 동일합니다. ASP.NET의 명명된 권한에서 권한 집합을 수정할 수 있습니다. 또한 사용자 지정 멤버 자격 조건을 갖는 CodeGroup 정의를 추가할 수 있습니다. 앞에서 설명한 것처럼 새 CAS 사용자 지정은 web_mediumtrust.config와 같은 부분 신뢰 정책 파일에서 만들어야 합니다. 파일 이름이 "legacy"로 시작하는 파일은 trust 요소의 LegacyCasModel 특성이 true로 설정될 때 구문 분석되고 사용됩니다.

ASP.NET 4의 경우 모든 사용자 지정 CodeGroup 정의는 사용 가능한 세 가지 권한 집합인 FullTrust, ASP.Net (즉, 부분 신뢰 권한 집합) 또는 Nothing 중 하나로 매핑되어야 합니다. ASP.NET 4 부분 신뢰 응용 프로그램 도메인은 기본적으로 유형이 같은 응용 프로그램 도메인이므로 사용자 지정 정책 항목이 제한된 권한 집합으로 평가되어야 합니다. ASP.NET 4 CAS 모델을 사용할 때 서로 다른 명명된 권한 집합을 정의할 수 있는 것처럼 보이지만 FullTrust, ASP.Net 또는 Nothing 이외의 권한 집합으로 평가되는 코드는 런타임에 SecurityException 예외를 일으킵니다. 이는 CLR에서 평가된 권한 집합이 인식되지 않음을 나타냅니다.

FullTrust 권한 집합은 코드가 완전 신뢰로 실행된다는 것을 나타냅니다. ASP.Net 권한 집합은 일반적으로 부분 신뢰 응용 프로그램 도메인에 사용되는 명명된 부분 신뢰 권한 집합입니다. 앞에서 설명한 것처럼 Nothing은 CLR에서 실제 권한 집합으로 인식되지 않으며 단지 빈 권한 집합입니다. CLR에서 어셈블리가 빈 권한 집합과 연결된 것으로 확인되면 CLR에서 SecurityException 예외가 발생되고 CLR이 어셈블리를 로드하지 않습니다.

또한 ASP.NET 4에서는 trust 요소의 PermissionSetName 특성을 사용하여 ASP.Net 권한 집합의 이름을 변경할 수 있습니다. PermissionSetName 특성에 대해 다른 이름을 설정할 수 있습니다. 런타임에 ASP.NET 4는 같은 이름의 PermissionSet 요소에 대한 부분 신뢰 정책 파일을 검색합니다. 그런 다음 이 명명된 권한 집합은 유형이 같은 응용 프로그램 도메인에 대한 부분 신뢰 권한 집합으로 사용됩니다. 이 작업은 수행할 필요가 거의 없습니다. 하지만 부분 신뢰 권한 집합의 이름을 ASP.Net이 아닌 다른 이름으로 변경할 수 있는 기능은 고유한 명명된 권한 집합을 ASP.NET 기본 권한 집합과 구분되는 엔터티로 정의하는 SharePoint와 같은 호스팅 환경을 지원하기 위해 추가되었습니다. 새 CAS 모델에서는 더 이상 부분 신뢰 권한을 정의하는 명명된 권한 집합을 여러 개 사용할 수 없습니다. 부분 신뢰 권한 집합의 이름을 ASP.Net이 아닌 다른 이름으로 변경할 수 있지만 응용 프로그램에는 실제로 하나의 부분 신뢰 권한 집합만 있을 수 있습니다.

완전 신뢰가 부여되는 어셈블리 지정

ASP.NET 4에서 새롭게 제공되는 두 번째 선언적 정책 사용자 지정을 사용하면 항상 완전 신뢰가 부여되는 어셈블리 ID의 목록을 명시적으로 설정할 수 있습니다. securityPolicy 구성에는 새 하위 fullTrustAssemblies 구성 섹션이 포함됩니다. FullTrustAssembliesSection 섹션은 추가, 제거 및 지우기 작업을 지원하는 표준 컬렉션으로, 이 섹션에서 런타임에 완전 신뢰가 부여되는 하나 이상의 어셈블리 ID를 지정할 수 있습니다. 다음 예제에서는 fullTrustAssemblies 구성 섹션을 보여 줍니다.

<system.web>

<add assemblyName="MyCustomAssembly"

version="1.0.0.0"

publicKey="a 320 hex character representation

of the public key blob used with a

signed assembly"

</fullTrustAssemblies>

</securityPolicy>

</system.web>

fullTrustAssemblies 요소의 각 항목은 어셈블리 이름 및 어셈블리 버전과 서명 키의 공개 키 부분에 대한 16진수 문자 표현인 320자 문자열로 어셈블리를 식별합니다.

참고

이후에는 새 .NET Framework 어셈블리에서 2048비트 서명 키를 사용할 수 있습니다.2048비트 서명 키를 사용하는 새 어셈블리가 릴리스되면 576자 길이의 16진수 문자열을 만들 수 있습니다.

어셈블리 위치는 어셈블리 정의에서 지정되지 않으며 어셈블리를 찾고 로드하는 개별 호스팅 환경(예: ASP.NET 4)에 따라 달라집니다. 로드된 어셈블리가 fullTrustAssemblies의 add 요소 중 하나에 포함된 정보와 일치하면 해당 어셈블리에 완전 신뢰가 부여됩니다.

GAC에 배포되지 않은 어셈블리에 대해서는 fullTrustAssemblies를 사용하지만 이 요소는 항상 완전 신뢰로 실행해야 합니다. fullTrustAssemblies에 나열된 어셈블리는 구성 계층 구조(루트 Web.config 파일부터 개별 응용 프로그램 수준의 Web.config 파일까지) 중 어느 지점에서든 사용자 지정할 수 있으므로 부분 신뢰 정책 파일에서 멤버 자격 조건과 코드 그룹을 사용하기 보다 이 설정을 사용하는 것이 완전 신뢰를 더 쉽고 유연하게 부여할 수 있습니다. 다른 응용 프로그램에 대해 서로 다른 정보를 지정하여 개별 응용 프로그램에 대해 fullTrustAssemblies 목록을 사용자 지정할 수 있습니다. 이 작업은 location 요소를 사용하여 응용 프로그램 수준의 Web.config 파일 또는 루트 Web.config 파일에서 수행할 수 있습니다.

완전 신뢰 어셈블리 집합은 부분 신뢰 응용 프로그램 도메인이 생성될 때 즉시 설정됩니다. 따라서 부분 신뢰 정책 파일에 fullTrustAssemblies 요소에 나열된 어셈블리에 대해 다른 권한 부여 집합을 설정하는 정보가 포함된 경우 해당 정보가 무시되고 어셈블리에 완전 신뢰가 부여됩니다.

프로그래밍 방식으로 권한 사용자 지정

또한 ASP.NET 4 HostSecurityPolicyResolver 형식의 사용자 지정 구현을 만들어서 프로그래밍 방식으로 어셈블리에 대한 권한 집합 연결을 변경할 수 있습니다. 런타임에 ASP.NET 4는 CLR HostSecurityManager 형식에 대한 고유 구현을 사용합니다. HostSecurityManager 개체는 어셈블리가 로드될 때마다 CLR에 의해 호출됩니다. HostSecurityManager 속성의 기능 중 하나는 지정된 어셈블리와 연결되는 PermissionSet 개체를 반환하고 증명 정보 집합을 제공하기 위한 것입니다. ASP.NET 4에서는 CLR이 ASP.NET 4에 권한 집합 결정을 요청할 때마다 사용자 지정 HostSecurityPolicyResolver 개체를 호출하여 이러한 프로세스를 사용자 지정할 수 있습니다.

trust 요소의 HostSecurityPolicyResolverType 특성을 사용하여 사용자 지정 HostSecurityPolicyResolver 개체를 구성할 수 있습니다. ASP.NET 4에서 응용 프로그램에 대해 사용자 지정 HostSecurityPolicyResolver 개체가 구성된 것으로 확인될 경우 CLR이 권한 집합 결정을 요청할 때마다 사용자 지정 확인자의 ResolvePolicy 메서드를 호출합니다. 하지만 HostSecurityManager 개체와 달리 HostSecurityPolicyResolver 개체는 ASP.NET 4에 대해 제한된 발생 가능 결정 집합만 반환할 수 있습니다. ResolvePolicy 메서드 반환 값은 HostSecurityPolicyResults 열거형에서 다음 값들 중 하나여야 합니다.

DefaultPolicy. 이 값은 ASP.NET 4가 어셈블리에 대해 적합한 권한 집합을 확인하기 위해 고유한 논리를 사용하도록 지정합니다. HostSecurityPolicyResolver 개체가 권한 집합을 결정하지 않도록 하려는 어셈블리에 대해서는 DefaultPolicy를 반환해야 합니다. DefaultPolicy를 반환하면 ASP.NET이 현재 ASP.NET 신뢰 수준에 대해 부분 신뢰 정책 파일에 정의된 선언적 코드 그룹 및 멤버 자격 조건을 기준으로 어셈블리의 권한 부여 집합을 결정합니다.
FullTrust. 어셈블리에 완전 신뢰가 부여됩니다.
AppDomainTrust. 어셈블리에 응용 프로그램 도메인과 연결된 부분 신뢰 권한 집합이 부여됩니다. 일반적으로 이 값을 사용하면 명명된 ASP.Net 권한 집합에 정의된 권한이 어셈블리에 부여됩니다.
None. 어셈블리에 대한 권한 집합이 Nothing 권한 집합으로 설정됩니다.

기본 HostSecurityPolicyResolver 클래스에는 무제한 보안 권한에 대한 상속성 요구가 포함되기 때문에, 사용자 지정 HostSecurityPolicyResolver 개체는 다른 HostSecurityPolicyResolver 개체에서 완전 신뢰를 설정할 필요 없이 로드될 수 있어야 하며, HostSecurityPolicyResolver 클래스에 대한 구체적 구현이 항상 서명되고 GAC에 배포되어야 합니다.

다음 예제에서는 특정 디렉터리에서 로드되는 모든 어셈블리에 완전 신뢰를 부여하는 사용자 지정 HostSecurityPolicyResolver 개체를 보여 줍니다. 이 예제는 GAC가 아닌 디스크의 특정 위치에 컴파일된 어셈블리를 추가하고 해당 위치의 모든 파일이 완전 신뢰 수준으로 자동 실행되도록 하려는 조직의 시나리오가 될 수 있습니다. ASP.NET 응용 프로그램이 웹 응용 프로그램의 디렉터리 구조 외부에서 어셈블리를 로드할 수 있도록 하려면 어셈블리 ID를 다른 실제 디스크 위치와 연결하는 명시적 어셈블리 바인딩 리디렉션을 추가해야 합니다.

[Visual Basic]

Public Class MyCustomResolver 
    Inherits HostSecurityPolicyResolver 
    Public Overloads Overrides Function ResolvePolicy(ByVal evidence _
            As Evidence) As HostSecurityPolicyResults 
        Dim urlEvidence As Url = evidence.GetHostEvidence(Of Url)() 
        
        If (urlEvidence IsNot Nothing) AndAlso _
            (urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll")) Then 
            Return HostSecurityPolicyResults.FullTrust 
        End If 
        
        ' Specify that ASP.NET should perform its own logic.
        Return HostSecurityPolicyResults.DefaultPolicy 
    End Function 
End Class

public class MyCustomResolver : HostSecurityPolicyResolver
{ 
  public override HostSecurityPolicyResults 
                              ResolvePolicy(Evidence evidence)
  {
            Url urlEvidence = evidence.GetHostEvidence<Url>();
            if ( (urlEvidence != null)  && 
                 (urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll"))
               )
                return HostSecurityPolicyResults.FullTrust;

            // Specify that ASP.NET should perform its own logic.
            return HostSecurityPolicyResults.DefaultPolicy;
  }
}

조건부 APTCA 연산자

버전 4 이전의 .NET Framework에서는 ASP.NET 어셈블리를 포함하는 많은 완전 신뢰 어셈블리가 AllowPartiallyTrustedCallersAttribute(APTCA) 특성으로 표시되었습니다. 이 특성은 이 방식으로 표시된 어셈블리에 정의된 공용 형식 및 멤버에 대한 액세스 권한을 부분 신뢰 호출자에게 제공합니다. .NET Framework 4의 경우에는 CLR에 조건부 APTCA라고 부르는 APTCA의 변형이 포함됩니다. 조건부 APTCA의 약식 표기는 C-APTCA입니다. 조건부 APTCA를 사용하면 APTCA 특성으로 표시된 어셈블리가 특정 호스팅 환경에서만 APTCA 특성을 유지하도록 할 수 있습니다. 따라서 조건부 APTCA를 사용하면 ASP.NET 4에서 부분 신뢰 호출자가 공용 ASP.NET 4 API를 성공적으로 호출할 수 있는 부분 신뢰 호스트 환경을 보다 쉽고 정확하게 제어할 수 있습니다.

조건부 APTCA 작동 방식

부분 신뢰 호스트 환경과 완전 신뢰 어셈블리는 모두 조건부 APTCA 작업을 구성하는 데 필요한 역할을 담당합니다. 권한 집합이 중요한 부분 신뢰 호스트 환경은 항상 해당 APTCA 설정이 허용되어야 하는 어셈블리 목록을 CLR에 제공할 수 있습니다. 해당 APTCA 특성이 특정 호스트 환경에서만 사용되는 완전 신뢰 어셈블리는 어셈블리 수준의 APTCA 특성에 대한 다음 변형을 사용하여 이를 나타냅니다.

[assembly: AllowPartiallyTrustedCallers(PartialTrustVisibilityLevel=NotVisibleByDefault)]

런타임에 CLR에 조건부 APTCA로 표시되는 어셈블리를 로드하도록 요청되면 CLR이 호스트 환경에서 제공되는 유효한 조건부 APTCA 어셈블리의 목록을 검사합니다. 어셈블리가 목록에 있으면 이전 버전의 .NET Framework에서 어셈블리가 APTCA 특성으로 표시된 것처럼 CLR이 어셈블리에 공개적으로 노출된 모든 코드를 처리합니다.

조건부 APTCA 어셈블리가 APTCA로 처리되어야 하는 호스트 환경의 어셈블리 목록에 없으면 어셈블리가 로드되지만 APTCA 특성이 포함되지 않습니다. 이러한 어셈블리에서 부분 신뢰 사용자 코드에 공용 API를 실제로 사용할 수 있는지 여부는 어셈블리의 보안 투명성이 100%인지 여부에 따라 달라집니다. 즉, 어셈블리가 어셈블리 수준의 SecurityTransparentAttribute 특성으로 표시되는지 여부에 따라 달라집니다. ASP.NET 4의 보안 투명성은 이 항목의 뒷부분에서 설명합니다.

요약하면, ASP.NET 4의 공용 API는 다음 방식 중 하나로 작동할 수 있습니다.

대부분의 ASP.NET 어셈블리의 경우 모든 공용 API가 부분 신뢰 호출자에게 제공되지 않습니다. 이렇게 되면 실제로 ASP.NET 4에서 대부분의 공용 API를 웹 응용 프로그램 이외의 모든 부분 신뢰 환경에서 사용할 수 없습니다.
100% 보안 투명성으로 표시된 일부 ASP.NET 어셈블리는 부분 신뢰 호출자에서 계속 호출할 수 있습니다. 하지만, 이러한 어셈블리의 코드 경로가 결국 ASP.NET 코드베이스의 남은 부분에 도달하면 호출이 실패합니다. 이러한 결과는 이전 버전의 ASP.NET 릴리스에서의 동작과 동일하지만 ASP.NET 4 어셈블리의 API 호출은 실패하기 전에 조금 더 진행된다는 점만 약간 다릅니다.

보안 투명성이 표시된 어셈블리에 대해서는 다음 내용을 참조하십시오.
- 어셈블리 수준에서 보안 투명성이 표시되는 ASP.NET 어셈블리는 System.Web.DynamicData.dll 및 System.Web.RegularExpressions.dll 두 개만 있습니다.
- System.Web.Routing.dll은 이전 버전의 ASP.NET에서 해당 어셈블리에 정의된 모든 형식이 System.Web.dll로 이동되었기 때문에 ASP.NET 4에서 100% 보안 투명성으로 간주되지 않습니다. 실제로 ASP.NET 4에서 System.Web.Routing.dll은 메타데이터 전용 어셈블리입니다.

ASP.NET 4에서 조건부 APTCA 특성 변형은 다음 어셈블리에서 찾을 수 있습니다.

System.Web.dll
System.Web.Extensions.dll
System.Web.DynamicData.dll
System.Web.DataVisualization.dll
System.ComponentModel.DataAnnotations.dll
System.Web.ApplicationServices.dll. 이 어셈블리는 ASP.NET 4의 새 어셈블리입니다.
System.Web.Abstractions.dll. 이 어셈블리에 포함된 형식은 ASP.NET 4에서 System.Web.dll로 이동되었습니다.
System.Web.Routing.dll. 이 어셈블리에 포함된 형식은 ASP.NET 4에서 System.Web.dll로 이동되었습니다.

조건부 APTCA와 ASP.NET 호스팅 권한 특성 비교

조건부 APTCA로 인해 ASP.NET 4에 있는 99%의 공용 API로부터 AspNetHostingPermission 특성을 제거할 수 있게 되었습니다. AspNetHostingPermission 특성은 ASP.NET 4에서도 일부 위치에 사용되지만 해당 권한의 의도가 실제로 적합한 경우에만 사용됩니다. 그외 다른 모든 위치에서는 다음 두 가지 형태의 AspNetHostingPermission 특성 사용이 제거되었습니다.

<AspNetHostingPermission(SecurityAction.LinkDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)>
<AspNetHostingPermission(SecurityAction.InheritanceDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)>

[AspNetHostingPermission(SecurityAction.LinkDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)]
[AspNetHostingPermission(SecurityAction.InheritanceDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)]

이러한 권한 정의는 이전 버전의 ASP.NET에서 ASP.NET 어셈블리가 웹 이외의 부분 신뢰 환경에서 로드되지 않도록 방지하기 위해 사용되었습니다. 이 때 고려해야 할 가장 중요한 환경은 Microsoft Internet Explorer 및 Mozilla Firefox와 같은 브라우저에 로드되는 관리되는 응용 프로그램과 부분 신뢰 관리되는 컨트롤이었습니다. 조건부 APTCA를 사용하면 ClickOnce 응용 프로그램 및 브라우저 기반의 관리되는 컨트롤이 전체 APTCA로 처리를 위해 어떠한 조건부 APTCA 어셈블리도 정의하지 않기 때문에 결국 동일한 보호가 적용됩니다.

ASP.NET 4 조건부 APTCA 목록 사용자 지정

앞에서 설명한 것처럼 개별 호스트 환경에서는 APTCA 특성이 허용되어야 하는 조건부 APTCA 어셈블리의 목록을 CLR에 제공할 수 있습니다. ASP.NET 4에서는 모든 ASP.NET 4 어셈블리가 포함된 하드 코드된 목록을 CLR에 제공합니다. ASP.NET 4에서 이 목록을 제공하지 않은 경우 ASP.NET 내부 코드의 첫 번째 줄이 부분 신뢰 응용 프로그램 도메인에서 실행될 때 웹 응용 프로그램이 즉시 실패합니다.

.NET Framework 4에서 조건부 APTCA는 .NET Framework의 다른 부분에서 아직 구현되지 않은 새로운 CAS 개념입니다. 따라서 이후 버전의 .NET Framework에는 보다 많은 조건부 APTCA 어셈블리가 포함될 것입니다. 또한 조건부 APTCA에 대한 사용자 이해도가 높아지고 완전 신뢰 어셈블리에 사용되는 경우가 많아지면 조건부 APTCA 어셈블리 집합도 늘어날 것입니다. 가능한 모든 조건부 APTCA 어셈블리를 ASP.NET 4에서 미리 알 수는 없으므로 ASP.NET 4에는 조건부 APTCA 어셈블리를 추가할 수 있는 구성 섹션이 포함되어 있습니다.

기존 securityPolicy 섹션에는 partialTrustVisibleAssemblies라는 자식 구성 섹션이 포함되어 있습니다. 이 섹션은 추가, 제거 및 지우기 작업을 지원하는 표준 컬렉션으로, 이 섹션에서 APTCA로 처리되어야 하는 하나 이상의 어셈블리 ID를 지정할 수 있습니다(어셈블리 ID가 조건부 APTCA에 대해서도 표시된 경우). 다음 예제에서는 partialTrustVisibleAssemblies 섹션을 보여 줍니다.

<system.web>
  <securityPolicy>
    <partialTrustVisibleAssemblies>

      <add assemblyName="MyCustomAssembly"
           publicKey="a 320 hex character representation 
                      of the public key blob used with a 
                      signed assembly"
      />

    </partialTrustVisibleAssemblies>
  </securityPolicy>
</system.web>

partialTrustVisibleAssemblies 섹션의 각 항목은 어셈블리 이름으로 어셈블리를 식별합니다. 또한 각 항목은 조건부 APTCA 특성 사용 어셈블리에 사용되는 서명 키의 공개 키 부분에 대한 16진수 문자 표현인 320자 문자열(예: 0x03FA4D...)로도 식별됩니다. 버전 특성은 지정할 필요가 없습니다. CLR에는 어셈블리 이름과 공개 키 토큰만 필요합니다.

조건부 APTCA 어셈블리를 사용하도록 설정할 때의 중요한 성능 영향은 조건부 APTCA 어셈블리의 타동적 클로저도 설정해야 한다는 것입니다. 예를 들어 조건부 ATPCA 어셈블리 A는 ATPCA 어셈블리 B에 의존하고, ATPCA 어셈블리 B는 다시 조건부 ATPCA 어셈블리 C에 의존하는 경우 A에 대해 조건부 ATPCA를 사용하도록 설정할 때 C에 대해서도 조건부 APTCA를 설정해야 합니다. 그렇지 않으면 응용 프로그램의 성능이 저하될 수 있습니다. 예를 들어 전체 조건부 ATPCA 클로저가 설정되지 않은 경우 코드 공유 및 NGen 이미지가 비활성화됩니다.

조건부 APTCA가 웹 이외의 부분 신뢰 응용 프로그램에 미치는 영향

ASP.NET 4 이전의 ASP.NET 버전에서는 일부 형식 및 네임스페이스가 AspNetHostingPermission 특성으로 표시되지 않았습니다. 따라서 이러한 형식을 ClickOnce 응용 프로그램과 같은 ASP.NET 이외의 부분 신뢰 환경에서 호출할 수 있었습니다. 이 방식으로 호출할 수 있는 형식과 네임스페이스는 다음과 같습니다.

System.Web.ClientServices 네임스페이스의 형식
System.Web.ClientServices.Providers 네임스페이스의 형식
HttpUtility 형식입니다.

System.Web.ClientServices 형식은 ClickOnce와 같은 .NET Framework 4 부분 신뢰 환경에서 사용할 수 없습니다. 포함하는 어셈블리(System.Web.Extensions.dll)가 조건부 APTCA로 표시되지 않은 ASP.NET 4 어셈블리이고 ClickOnce에서는 어떠한 조건부 APTCA 어셈블리에 대해서도 APTCA가 허용되지 않기 때문에 클라이언트 서비스 형식을 부분 신뢰 ClickOnce 응용 프로그램에서 호출할 수 없습니다.

이러한 동작의 원인은 몇 가지가 있습니다. 첫 번째, .NET Framework 4는 클라이언트와 확장 SKU로 분할되어 있으며 여러 ClickOnce 응용 프로그램이 클라이언트 SKU를 대상으로 한다고 가정합니다. 그러면 ASP.NET 클라이언트 서비스 유형을 클라이언트 SKU로 리팩터링하기 위해 상당한 노력이 필요할 것입니다.

두 번째, 필요한 조건부 APTCA 경계를 유지하면서 클라이언트 유형을 리팩터링하는 방법을 결정하기가 간단하지 않습니다. 따라서 .NET Framework 4에서는 확장 .NET Framework 4 SKU를 사용하여 완전 신뢰로 실행하도록 구성된 ClickOnce 응용 프로그램을 포함하여 ASP.NET 이외의 완전 신뢰 환경에서만 클라이언트 서비스 유형을 사용할 수 있습니다.

HttpUtility 형식에서 조건부 APTCA가 미치는 영향은 다음 시나리오에서 설명하는 것처럼 사용 중인 메서드에 따라 달라집니다.

부분 신뢰 코드가 WebUtility 클래스의 HtmlEncode 또는 HtmlDecode 메서드를 호출했습니다. WebUtility 형식에는 ASP.NET HTML 인코딩 및 디코딩 구현이 포함되지만 이러한 구현이 System.Net 네임스페이스로 리팩터링 및 이동되었으며 System.dll에 포함됩니다. System.dll은 모든 부분 신뢰 호스트 환경에서 제공되지만 ASP.NET 이외의 부분 신뢰 응용 프로그램에 액세스하는 WebUtility 형식의 메서드에는 문제가 없습니다.
부분 신뢰 코드가 WebUtility 클래스의 다른 메서드를 호출했습니다. 이 경우 클라이언트 서비스 유형에 대해 앞에서 설명한 것과 동일한 문제가 적용됩니다. 즉, WebUtility는 .NET Framework 4에서 ASP.NET 이외의 완전 신뢰 호출자에만 제공됩니다.

ASP.NET 4의 보안 투명성

보안 투명성을 사용하면 코드 블록이 보안에 민감한 작업을 수행할지 여부를 CLR에 나타낼 수 있습니다. 투명한 코드는 권한 어설션, 링크 요구 충족, 확인되지 않은 코드 포함, 네이티브 코드로 호출 또는 보안에 중요한 코드 호출을 수행할 수 없습니다. 이 규칙은 투명한 코드가 완전 신뢰(예: GAC의 코드) 또는 부분 신뢰인지 여부에 관계없이 항상 적용됩니다.

보안 투명성은 ASP.NET과 같은 .NET Framework의 강력한 기능 중 하나입니다. 보안 투명성을 통해 ASP.NET은 ASP.NET 코드 부분이 권한 어설션을 수행하지 않고 해당 코드가 네이티브 코드로의 PInvoke 호출과 같은 보안에 민감한 작업을 구현하거나 수행하지 않음을 CLR에 나타낼 수 있습니다. 따라서 .NET Framework 코드가 완전 신뢰 GAC에 있더라도 .NET Framework 코드에서 대규모의 공용 및 내부 API에 대한 보안 노출을 크게 줄일 수 있습니다.

보안 투명성은 특정 어셈블리 전체에 적용하거나 해당 어셈블리의 코드 하위 집합에만 적용할 수 있습니다. 특정 어셈블리 전체를 보안 투명성으로 표시하는 것이 이상적인 경우이긴 하지만 .NET Framework 코드의 일부 코드에서 보안에 민감한 작업을 수행해야 할 필요가 있을 수 있습니다. 100% 보안 투명성 코드를 포함하는 어셈블리는 어셈블리 수준의 SecurityTransparentAttribute 특성을 사용하여 표시됩니다.

투명한 코드와 투명하지 않은 코드가 혼합된 어셈블리는 어셈블리 수준의 투명성 특성을 갖지 않습니다. 대신 SecuritySafeCriticalAttributel 특성 또는 SecurityCriticalAttribute 특성을 사용하여 어셈블리의 개별 클래스를 표시할 수 있습니다.

특성이 없는 클래스의 동작은 복잡한 형태입니다. 하지만 간단히 말해서 ASP.NET 4 어셈블리에서 새 투명성 모델을 채택한 특성이 없는 형식은 보안 투명성 형식으로 간주됩니다. 특성이 없고 새 투명성 모델을 채택하지 않은 ASP.NET 4 어셈블리의 형식은 보안 안전에 중요한 형식으로 간주됩니다.

보안 투명성의 실제와 보안 규칙 집합

대부분의 ASP.NET 4 코드베이스는 System.Web.dll에 있기 때문에 모든 ASP.NET 4 코드를 새로운 투명성 모델로 변환하는 것은 실용적이지 않습니다. 대신 ASP.NET 4 코드를 다음과 같은 범주로 나눌 수 있습니다.

다음 어셈블리의 코드를 포함하고 새 투명성 모델을 채택하지 않은 코드:
- System.Web.dll
- System.Web.ApplicationServices.dll
- System.Web.Mobile.dll. 이 어셈블리의 형식은 ASP.NET 4에서 사용되지 않는 것으로 표시됩니다. 어셈블리가 계속 존재하더라도 앞으로는 이 어셈블리에 있는 형식을 사용하지 않는 것이 좋습니다.
다음 어셈블리의 코드를 포함하고 새 투명성 모델을 사용하는 코드:
- System.Web.Extensions.dll
- System.Web.DynamicData.dll(100% 보안 투명성)
- System.Web.RegularExpressions.dll(100% 보안 투명성)
- System.ComponentModel.DataAnnotations.dll
- System.Web.DataVisualization.dll
다음 어셈블리를 포함하여 형식이 다른 ASP.NET 어셈블리로 이동된 메타 데이터 전용 어셈블리:
- System.Web.Abstractions.dll. 이전 버전의 ASP.NET에서 이 어셈블리에 포함된 형식은 System.Web.dll로 이동되었습니다. 따라서 Sytem.Web.Abstractions.dll은 ASP.NET 4에서 메타데이터 전용 어셈블리입니다.
- System.Web.Routing.dll. 이전 버전의 ASP.NET에서 이 어셈블리에 포함된 형식은 System.Web.dll로 이동되었습니다. 따라서 System.Web.Routing.dll은 ASP.NET 4에서 메타데이터 전용 어셈블리입니다.

.NET Framework 4에서 CLR에는 보안 규칙 집합이라고 부르는 새로운 개념이 도입되었습니다. SecurityRuleSet 구성에는 수준 1과 수준 2의 두 수준이 있습니다. 모든 형식에 대한 SecurityRuleSet 구성은 SecurityRulesAttribute 어셈블리 수준의 특성을 사용하여 지정됩니다. 새로운 투명성 모델을 채택한 ASP.NET 4 어셈블리는 다음과 같은 어셈블리 수준 특성을 사용하여 표시됩니다.

System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level2)

.NET Framework 2.0의 투명성 모델을 사용하는 ASP.NET 4 어셈블리(ASP.NET 4 이전의 ASP.NET에서는 투명성 개념이 사용되지 않았기 때문에 ASP.NET에서 실제로는 투명성이 없는 것으로 간주됨)는 다음과 같은 어셈블리 수준의 특성을 사용하여 표시됩니다.

System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level1)

새 투명성 모델을 채택한 ASP.NET 어셈블리(및 어셈블리에 있는 공용 형식)에서 대부분의 코드는 보안에 투명한 것으로 간주됩니다. 이러한 어셈블리에서는 소량의 코드만 보안에 민감한 작업을 수행하며, 그러한 코드는 안전에 중요한 코드 또는 중요한 코드로 표시됩니다.

새 투명성 모델을 채택하지 않은 ASP.NET 어셈블리의 경우(오래된 어셈블리 또는 형식 리디렉션 어셈블리 제외) 모든 공용 API는 부분 신뢰 사용자 코드에서 호출할 수 있으며 보안에 민감한 작업을 내부적으로 수행할 수 있습니다. 부분 신뢰 호출자에 대한 개방된 액세스와 보안에 민감한 작업 가능성으로 인해 이전 ASP.NET 4 코드에는 더 높은 수준의 보안 검사가 필요합니다. 하지만 대부분의 새로운 ASP.NET 기능은 System.Web.Extensions.dll 및 System.Web.DynamicData.dll과 같은 새로운 어셈블리나 ASP.NET MVC와 같은 별도의 릴리스에서 구현되므로 대부분의 새 ASP.NET 코드는 보안에 투명하며 따라서 기본적으로는 이전 코드보다 더 안전합니다.

기본적으로 CLR은 호스팅 환경에서 APTCA 특성을 허용하는 한 SecurityRuleSet.Level1로 표시된 모든 ASP.NET 4 어셈블리의 공용 API를 안전에 중요한(즉, SecuritySafeCriticalAttribute 특성으로 표시된 것과 동일한) 것으로 처리합니다. APTCA가 허용되지 않은 경우 CLR은 완전 신뢰에 대한 링크 요구를 트리거하여 스택에 부분 신뢰 사용자 코드가 있으면 실패합니다. 즉, SecurityRuleSet.Level1로 표시된 ASP.NET 어셈블리에 대해 APTCA가 허용되지 않으면 이전 버전의 .NET Framework에서 부분 신뢰 코드가 APTCA 특성으로 표시되지 않은 완전 신뢰 어셈블리를 호출하려고 시도할 때와 같은 동작을 볼 수 있습니다.

기본적으로 CLR은 호스팅 환경에서 APTCA 특성을 허용하는 한 SecurityRuleSet.Level2로 표시된 모든 ASP.NET 4 어셈블리의 공용 API를 보안에 투명한(즉, SecurityTransparentAttribute 특성으로 표시된 것과 동일한) 것으로 처리합니다. 그렇지 않으면 다음과 같은 동작이 정의됩니다.

APTCA가 허용되지 않고 Level2로 표시된 어셈블리가 100% 보안에 투명하지 않은 경우 CLR은 공용 노출 영역을 보안에 중요한 것으로 취급합니다. 따라서 공용 노출 영역을 사용하려고 시도하는 모든 부분 신뢰 호출자가 실패하고 MethodAccessException, TypeAccessException 또는 FieldAccessException 예외가 발생할 수 있습니다.
APTCA가 허용되지 않고 Level2로 표시된 어셈블리가 100% 보안에 투명한 경우 부분 신뢰 호출자가 해당 어셈블리에서 모든 공용 API를 성공적으로 호출할 수 있습니다. 실제로는 나중에 100% 보안에 투명한 어셈블리에 있는 코드가 결국 100% 보안에 투명하지 않은 수준 1 ASP.NET 어셈블리 또는 수준 2 ASP.NET 어셈블리에 호출될 때 호출 경로에서 SecurityException 예외가 발생합니다.

투명성 및 ASP.NET 컴파일

ASP.NET 컴파일 시스템으로 생성되는 결과는 ASP.NET 4에 채택된 새 CAS 모델 및 새 보안 투명성 모델에 의해서도 영향을 받습니다. 여기에는 페이지 어셈블리, 미리 컴파일된 어셈블리 및 App_Code 디렉터리의 컴파일된 결과와 같은 항목이 포함됩니다. 컴파일 시스템의 동작은 trust 요소의 LegacyCasModel 특성 설정에 따라 달라집니다.

다음 표에서는 동적으로 컴파일된 개체가 레거시 CAS 모델 및 새 CAS 모델에서 어떻게 표시되는지를 보여 줍니다.

legacyCasModel 특성 설정	웹 사이트 신뢰 수준	컴파일된 어셈블리에 적용된 특성
False(새 CAS 모델)	완전 신뢰	SecurityRules(SecurityRuleSet.Level2)
	높은 신뢰 또는 낮은 신뢰	SecurityRules(SecurityRuleSet.Level2)
SecurityRules(SecurityRuleSet.Level2)
True(이전 CAS 모델)	완전 신뢰	SecurityRules(SecurityRuleSet.Level1)
	높은 신뢰 또는 낮은 신뢰	SecurityRules(SecurityRuleSet.Level1)

ASP.NET 4 컴파일 시스템의 동작은 trust 요소의 LegacyCasModel 특성 설정에 따라 달라지기 때문에 여러 부분 신뢰 ASP.NET 4 응용 프로그램에서 컴파일된 코드를 공유하는 방식이 제한될 수 있습니다. 일반적으로는 응용 프로그램 동작에서 어떠한 변경점도 확인할 수 없습니다. 하지만 일부 시나리오에서는 LegacyCasModel 특성이 false로 설정된(즉, 새 CAS 모델을 사용하는) 부분 신뢰 응용 프로그램에서 만든 컴파일된 아티팩트가 다른 응용 프로그램에서 사용될 때 정상적으로 작동하지 않습니다. 따라서 일부 시나리오(예: 서명되고, ATPCA 특성이 포함되고, GAC에 배치되는 컴파일된 .ascx 컨트롤의 공유 라이브러리)에서는 라이브러리가 Level2를 사용하여 표시된 경우 일부 코드에 안전에 중요한 특성 및 중요한 특성을 명시적으로 적용해야 할 수 있습니다.

참고 항목

기타 리소스

호스팅된 환경에서의 ASP.NET 응용 프로그램 보안

다음을 통해 공유