.NET Framework 4의 보안 변경 내용
.NET Framework 버전 4에서는 보안과 관련하여 두 가지 사항이 크게 변경되었습니다. 컴퓨터 전체 수준의 보안 정책이 제거되었고, 권한 시스템은 그대로 유지되지만 기본 적용 메커니즘은 보안 투명성으로 변경되었습니다. 자세한 내용은 보안 투명 코드, 수준 2을 참조하십시오. 또한 보안을 취약하게 할 가능성이 있는 일부 사용 권한 작업은 더 이상 사용되지 않습니다.
.gif "중요") 중요 |
|---|
CAS(코드 액세스 보안)가 제거되지 않았고, 보안 정책이 CAS에서 제거되었지만 증명 정보와 권한은 계속해서 사용됩니다.일부 권한은 제거되었으며, 투명성으로 보안 적용이 간소화되었습니다.변경된 내용에 대한 간단한 개요를 보려면 코드 액세스 보안의 변경 내용 요약을 참조하십시오. |
유의해야 할 주요 사항은 다음과 같습니다.
투명성은 응용 프로그램의 일부로 실행되는 코드를 인프라의 일부로 실행되는 코드와 분리합니다. 투명성은 .NET Framework 버전 2.0에서 도입되었으며 개선을 통해 현재는 코드 액세스 보안 적용 메커니즘으로 활용되고 있습니다. 보안 정책과 달리 수준 2 투명성 규칙은 어셈블리 로드 시간이 아니라 런타임에 적용됩니다. 이러한 정책은 완전한 신뢰 상태로 실행되는 어셈블리에 대해서도 기본적으로 항상 적용됩니다. 그러나 수준 2 투명성은 데스크톱 응용 프로그램과 같이 주석이 지정되지 않는 완전히 신뢰되는 코드에 영향을 주지 않습니다. SecurityTransparentAttribute로 표시된 어셈블리(데스크톱 어셈블리 포함) 및 SecurityCriticalAttribute로 표시된 호출 메서드는 MethodAccessException을 받습니다. 이 동작은 SecurityRulesAttribute를 적용하고 SecurityRulesAttribute.RuleSet 속성을 Level1로 설정하여 변경할 수 있습니다. 그러나 이러한 변경은 이전 버전과의 호환성을 위해서만 수행해야 합니다. 투명성 제한을 데스크톱 응용 프로그램에 적용하려면 명시적으로 해당 응용 프로그램을 보안 투명으로 표시해야 합니다.
보안 정책 API를 호출하는 코드는 런타임에 컴파일러 경고뿐 아니라 NotSupportedException 예외를 받습니다. 정책은 <NetFx40_LegacySecurityPolicy> 구성 요소를 사용하여 다시 활성화할 수 있습니다. 정책이 활성화되어도 보안 투명성은 계속 적용됩니다. 보안 정책은 어셈블리 로드 시간에 적용되므로 런타임에 적용되는 투명성에 영향을 주지 않습니다.
더 이상 사용되지 않는 요청 권한(RequestMinimum, RequestOptional 및 RequestRefuse)은 컴파일러 경고를 받으며 .NET Framework 4에서 작동하지 않지만, 예외가 throw되도록 하지는 않습니다. Deny 요청은 런타임에 NotSupportedException이 throw되도록 합니다.
LinkDemand 보안 동작은 계속 사용되지만 이 동작을 사용 권한 확인에 사용하면 안 됩니다. 대신, 완전 신뢰를 요청하는 형식 및 메서드에 대해 SecurityCriticalAttribute를 사용하거나 개별 사용 권한을 요청하는 형식 및 메서드에 대해 Demand 메서드를 사용합니다.
Visual Studio 2010을 사용하여 응용 프로그램을 빌드한 경우 Visual Studio 프로젝트 설정에서 .NET Framework 4 이전의 .NET Framework 버전을 대상으로 지정하면 이러한 변경 사항의 적용 없이 응용 프로그램을 실행할 수 있습니다. 그러나 이 경우 새로운 .NET Framework 4 형식 및 멤버는 사용할 수 없습니다. .NET Framework의 이전 버전은 응용 프로그램 구성 파일에 있는 시작 설정 스키마에서 <supportedRuntime> 요소를 사용하여 지정할 수도 있습니다.
다음 단원에서는 .NET Framework 4의 이러한 변경 내용 및 기타 변경 내용에 대해 설명합니다.
보안 정책 단순화
보안 투명성 수준 2
사용되지 않는 사용 권한 요청
조건부 APTCA 연산자
증명 정보 개체
증명 정보 컬렉션
보안 정책 단순화
.NET Framework 4부터는 CLR(공용 언어 런타임)에서 더 이상 컴퓨터의 보안 정책을 제공하지 않습니다. .NET Framework는 관리 코드의 기능을 엄격히 제어하고 구성하기 위한 메커니즘으로 CAS(코드 액세스 보안) 정책을 제공해 왔습니다. CAS 정책이 강력하기는 하지만 복잡하고 제한적일 수 있습니다. 또한 CAS 정책은 네이티브 응용 프로그램에는 적용되지 않기 때문에 보안 보장이 제한적입니다. 따라서 시스템 관리자는 CAS 정책의 대체 수단으로서 Windows 7 및 Windows Server 2008 R2에서 제공하는 Windows Software Restriction Policies(SRP) 또는 AppLocker 같은 운영 체제 수준 솔루션에 의존해야 합니다. SRP 및 AppLocker 정책은 관리 코드 및 네이티브 코드 모두에 적용되는 간단한 신뢰 메커니즘을 제공합니다. SRP 및 AppLocker는 보안 정책 솔루션으로서 CAS보다 간단하면서 우수한 보안 보장을 제공합니다.
.NET Framework 4에서 컴퓨터 전체 수준 보안 정책은 기본적으로 사용되지 않습니다. 호스팅되지 않는 응용 프로그램, 즉 Windows Explorer를 통해 실행되거나 명령 프롬프트에서 실행되는 응용 프로그램은 이제 완전 신뢰 상태로 실행됩니다. 이러한 응용 프로그램에는 로컬 네트워크상의 공유에 있는 모든 응용 프로그램이 포함됩니다. 호스팅되거나 샌드박스가 적용된 응용 프로그램은 호스트(예: Internet Explorer, ClickOnce 또는 ASP.NET)에서 결정하는 신뢰 정책을 사용하여 실행됩니다. 샌드박스에서 실행되는 응용 프로그램 또는 컨트롤은 부분적으로 신뢰할 수 있는 것으로 간주됩니다.
보안 정책을 단순화하기 위해 투명성 모델이 .NET Framework에 적용되어 있습니다. 샌드박스에서 부여한 제한적 권한 집합을 사용하여 호스트 또는 샌드박스에서 실행되는 응용 프로그램 및 컨트롤은 투명한 것으로 간주됩니다. 투명성이란 부분적으로 신뢰할 수 있는 응용 프로그램을 실행할 때 CAS 정책의 검사에 신경을 쓰지 않아도 된다는 것을 의미합니다. 투명 응용 프로그램은 해당하는 권한 부여 설정만 사용하여 실행됩니다. 프로그래머는 응용 프로그램이 해당 샌드박스의 권한 부여 설정을 대상으로 하는지 및 완전 신뢰가 필요한 코드(보안에 중요한 코드)를 응용 프로그램이 호출하지 않는지에만 주의를 기울이면 됩니다.
| 중요 |
|---|
이와 같이 보안 정책이 변경됨에 따라 사용되지 않는 CAS 정책 형식 및 멤버를 명시적으로 호출하거나 다른 형식 및 멤버를 통해 암시적으로 호출하면 컴파일 경고 및 런타임 예외가 발생할 수 있습니다.사용되지 않는 형식 및 멤버와 이를 대체하는 형식 및 멤버의 목록은 코드 액세스 보안 정책 호환성 및 마이그레이션을 참조하십시오. 런타임 설정 스키마에서 <NetFx40_LegacySecurityPolicy> 구성 요소를 사용하여 레거시 CAS 정책 동작을 선택하도록 함으로써 경고와 오류가 발생하지 않도록 방지할 수 있습니다.그러나 해당 버전의 사용자 지정 CAS 정책이 .NET Framework 4으로 마이그레이션되지 않으면 레거시 보안 정책의 사용을 지정할 경우 사용자 지정 CAS 정책을 포함하지 않습니다. 또한 Visual Studio 프로젝트의 대상 .NET Framework 버전을 .NET Framework 4보다 이전 버전으로 설정하여 레거시 CAS 정책을 활성화할 수 있습니다. 이렇게 하면 레거시 CAS 정책이 활성화되고 사용자가 해당 버전에 대해 지정한 사용자 지정 CAS 정책이 포함됩니다.그러나 이 경우 새로운 .NET Framework 4 형식 및 멤버는 사용할 수 없습니다..NET Framework의 이전 버전은 시작 설정 스키마에서 <supportedRuntime> 요소를 사용하여 지정할 수도 있습니다. |
맨 위로 이동
보안 투명성 수준 2
보안 투명성은 .NET Framework 버전 2.0에서 도입되었으나 매우 제한적이고 주로 코드 유효성 검사의 효율성을 향상하는 데 사용되었습니다. .NET Framework 4에서 투명성은 응용 프로그램의 일부로 실행되는 코드를 인프라의 일부로 실행되는 코드와 분리하는 적용 메커니즘입니다. 투명성은 네이티브 코드 호출과 같은 권한 있는 작업을 수행할 수 있는 코드(중요한 코드)와 수행할 수 없는 코드(투명 코드)를 구분합니다. 투명한 코드는 운영되는 권한 집합의 범위 내에서 명령을 실행할 수 있지만 중요한 코드에서 실행하거나 호출하거나 파생시키거나 포함할 수 없습니다.
투명성 적용의 주된 목적은 여러 코드 그룹을 권한에 기반하여 격리하는 간단하고 효율적인 메커니즘을 제공하는 데 있습니다. 샌드박스 모델의 컨텍스트에서 이러한 권한 그룹은 완전히 신뢰되어 아무런 제한이 없거나 부분적으로 신뢰되어 해당 샌드박스에 부여된 권한 집합으로 제한됩니다.
데스크톱 응용 프로그램은 완전히 신뢰할 수 있는 상태로 실행되므로 투명성 모델에 영향을 받지 않습니다. 보안 투명성 변경에 대한 자세한 내용은 보안 투명 코드, 수준 2를 참조하십시오.
맨 위로 이동
사용되지 않는 사용 권한 요청
런타임 지원은 Deny, RequestMinimum, RequestOptional 및 RequestRefuse 사용 권한 요청을 적용하기 위해 제거되었습니다. 일반적으로 이러한 요청은 쉽게 이해되지 않을 뿐 아니라 잘못 사용되면 보안을 취약하게 할 가능성이 있었습니다.
Deny 동작은 Assert 동작으로 쉽게 재정의할 수 있었습니다. 어셈블리의 코드는 어셈블리의 권한 부여 설정에 포함된 사용 권한을 위해 Assert 동작을 실행할 수 있었습니다. Assert는 Deny가 스택에 나타나지 않도록 하여 효율성을 저하시켰습니다.
RequestMinimum은 응용 프로그램 범위 밖에서 효율적으로 사용될 수 없었습니다. RequestMinimum이 실행 파일(.exe)에서 사용되고 권한 부여 설정이 충족되지 않으면 해당 파일의 최종 사용자는 처리되지 않은 FileLoadException 예외를 받게 되고, 이 예외는 문제의 해결 방법에 대한 정보를 제공하지 않았습니다. 어셈블리의 여러 형식 및 멤버는 일반적으로 서로 다른 권한 요구 사항을 갖기 때문에 라이브러리(.dll 파일)에 대해 최소 요청 집합을 하나만 사용할 수 없었습니다.
RequestOptional은 쉽게 이해되지 않았으며 종종 잘못 사용되어 예기치 않은 결과가 발생했습니다. 개발자는 목록에서 사용 권한을 누락할 경우 누락된 사용 권한이 암시적으로 거부된다는 사실을 모른 채 사용 권한을 쉽게 누락할 수 있었습니다.
RequestRefuse를 사용할 경우 필요한 사용 권한을 식별하는 대신 원치 않는 사용 권한을 명시적으로 식별해야 하기 때문에 효율적인 최소 권한을 모델이 제공되지 않았습니다. 또한 새로운 사용 권한이 사용 가능해져도 해당 사용 권한이 목록에 포함되지 않았습니다. 뿐만 아니라 모든 사용 권한에 대해 거부가 적용되는 것이 아니었습니다. 예를 들어, IsolatedStoragePermission의 UserQuota 속성에 대한 값을 거부할 수 있었습니다.
끝으로, 원치 않는 사용 권한만 지정할 경우 유해할 수 있는 모든 사용 권한을 식별하지 못하면 보안이 취약해질 가능성이 있었습니다.
개발자는 RequestOptional 및 RequestRefuse를 사용하여 도메인 내에 권한 집합을 여러 개 만들어 동종 도메인을 분할할 수 있었습니다.
.NET Framework 4에서는 이러한 열거형 값의 런타임 적용이 제거됩니다. 이러한 SecurityAction 값을 사용하는 특성이 포함된 어셈블리는 계속 로드되고, CLR은 참조되는 어셈블리의 로드를 거부하거나 권한 집합에 기반하여 권한 부여 설정을 수정하지 않습니다.
맨 위로 이동
조건부 APTCA 연산자
AllowPartiallyTrustedCallersAttribute(APTCA) 특성을 조건부로 사용할 경우 호스트는 호스트 컨텍스트 내에 로드된 부분적으로 신뢰할 수 있는 호출자에게 노출하려는 어셈블리를 식별할 수 있습니다. 후보 어셈블리가 이미 부분 신뢰에 맞게 디자인되어 있어야 합니다. 즉, APTCA(투명 모델의 보안 안전에 중요한 멤버 또는 형식) 또는 완전 투명이어야 합니다. AllowPartiallyTrustedCallersAttribute의 새 생성자를 사용하면 호스트가 생성자 호출에 PartialTrustVisibilityLevel 열거형을 사용하여 APTCA 어셈블리의 표시 수준을 지정할 수 있습니다.
맨 위로 이동
증명 정보 개체
.NET Framework 4 이전 버전에서는 호스팅 코드가 개체를 증명 정보로 적용하려는 경우 거의 모든 개체를 증명 정보 개체로 사용할 수 있었습니다. 예를 들어, 일부 .NET Framework 코드에서는 System.Uri 개체를 증명 정보로 인식했습니다. 런타임은 증명 정보 개체를 System.Object 참조로 간주하고 형식 안전성을 전혀 적용하지 않았습니다.
이로 인해 문제가 발생했습니다. .NET Framework에서는 증명 개체로 사용 가능한 형식을 암시적으로 제한했기 때문입니다. 특히, 증명 정보로 사용되는 개체는 serialize할 수 있어야 하고 null일 수 없었습니다. 이러한 요구 사항이 충족되지 않으면 요구 사항 중 하나가 충족되어야 하는 작업이 수행될 때마다 CLR에서 예외를 throw했습니다.
증명 정보로 사용 가능한 개체 형식의 제한을 활성화하고 모든 증명 정보 개체에 새 기능 및 요구 사항을 추가하는 기능을 제공하기 위해 .NET Framework 4에는 새 기본 클래스인 System.Security.Policy.EvidenceBase가 도입되어 있으며, 모든 증명 정보 개체는 이 클래스에서 파생되어야 합니다. EvidenceBase 클래스는 인스턴스화될 때 증명 정보 개체를 serialize할 수 있게 합니다. 또한 나중에 기본 클래스의 기본 구현을 새로 추가하여 새 증명 정보 요구 사항을 만들 수 있습니다.
이전 버전과의 호환성
CLR에서 증명 정보 개체로 사용되는 모든 형식은 EvidenceBase로부터 파생되도록 .NET Framework 4에서 업데이트되었습니다. 그러나 타사 응용 프로그램에서 사용되는 사용자 지정 증명 정보 형식은 알 수 없고 업데이트할 수 없습니다. 따라서 이러한 증명 정보 형식은 EvidenceBase에서 파생된 증명 정보를 사용하는 새 멤버와 함께 사용될 수 없습니다.
맨 위로 이동
증명 정보 컬렉션
.NET Framework 4 이전에는 어셈블리 로드 시 어셈블리에 적용되는 증명 정보 개체의 전체 집합을 CLR에서 생성했습니다. 이러한 개체는 목록에 저장되었고, 소비자는 목록을 반복하여 특정 개체를 찾았습니다. 따라서 모든 증명 정보는 실제 사용 여부와 상관없이 사용 가능했습니다. 대부분의 증명 정보 개체에서 이 동작은 문제가 되지 않았지만, Authenticode 확인이 필요한 System.Security.Policy.Publisher 같은 증명 정보 개체의 경우 이 동작은 비효율적이었습니다.
.NET Framework 4에서는 이 동작을 향상하기 위해 증명 정보 컬렉션과의 상호 작용이 다시 디자인되었습니다. 이제 증명 정보 컬렉션은 목록이 아니라 사전처럼 동작합니다. 이제 소비자는 필요한 증명 정보 개체가 있는지 여부를 확인하기 위해 증명 정보 컬렉션을 반복하는 대신 특정 증명 정보 형식을 요청할 수 있습니다. 그러면 발견된 증명 정보를 컬렉션에서 반환합니다. 예를 들어, StrongName name = evidence.GetHostEvidence<StrongName>(); 호출은 증명 정보가 있으면 StrongName 개체를 반환하고 그렇지 않으면 null을 반환합니다.
이 사전 모델에서는 증명 정보 개체에 대한 요청이 있을 때까지 증명 정보 개체의 생성이 지연됩니다. Publisher 증명 정보 예제에서 어셈블리의 Authenticode 서명 확인에 따르는 성능 오버헤드는 해당 정보가 필요할 때까지 지연됩니다. Publisher 증명 정보가 필요하지 않은 완전 신뢰 응용 프로그램의 경우 확인 프로세스는 거의 대부분 수행되지 않습니다.
맨 위로 이동