보안 투명 코드, 수준 2
수준 2 투명성은 .NET Framework 버전 4에서 도입되었습니다. 이 모델의 세 가지 개념은 투명 코드, 보안 안전에 중요한 코드 및 보안에 중요한 코드입니다.
완전 신뢰 상태로 실행되는 코드를 비롯한 투명 코드는 다른 투명 코드 또는 보안 안전에 중요한 코드만 호출할 수 있습니다. 이 코드는 도메인의 부분 신뢰 권한 집합(있는 경우)에서 허용하는 작업만 수행할 수 있습니다. 투명 코드에서는 다음을 수행할 수 없습니다.
Assert 수행 또는 권한 상승
안전하지 않거나 확인할 수 없는 코드 포함
중요한 코드의 직접 호출
네이티브 코드 또는 SuppressUnmanagedCodeSecurityAttribute 특성이 있는 코드의 호출
LinkDemand로 보호되는 멤버의 호출
중요한 형식에서 상속
또한 투명 메서드는 중요한 가상 메서드를 재정의하거나 중요한 인터페이스 메서드를 구현할 수 없습니다.
보안 안전에 중요한 코드는 완전히 신뢰되지만 투명 코드에서 호출할 수 있습니다. 보안 안전에 중요한 코드는 완전 신뢰 코드의 노출 영역을 제한적으로 노출하고, 이 코드에서는 정확성 및 보안 확인이 수행됩니다.
보안에 중요한 코드는 모든 코드를 호출할 수 있고 완전히 신뢰되지만 이 코드를 투명 코드에서 호출하지는 못합니다.
이 항목에는 다음과 같은 단원이 포함되어 있습니다.
사용 예제 및 동작
재정의 패턴
상속 규칙
추가 정보 및 규칙
사용 예제 및 동작
.NET Framework 4 규칙(수준 2 투명성)을 지정하려면 다음 주석을 어셈블리에 사용합니다.
[assembly: SecurityRules(SecurityRuleSet.Level2)]
.NET Framework 2.0 규칙(수준 1 투명성)을 고수하려면 다음 주석을 사용합니다.
[assembly: SecurityRules(SecurityRuleSet.Level1)]
어셈블리에 주석을 지정하지 않으면 .NET Framework 4 규칙이 기본적으로 사용됩니다. 그러나 이러한 기본 동작에 의존하는 대신 SecurityRulesAttribute 특성을 사용하는 것이 가장 좋은 방법입니다.
어셈블리 수준 주석
다음 규칙은 어셈블리 수준의 특성 사용에 적용됩니다.
특성 없음: 특성을 지정하지 않으면 런타임에서는 투명 가상 또는 인터페이스 메서드를 재정의하거나 구현하는 경우와 같이 보안에 중요한 코드가 상속 규칙을 위반하지 않는 한 모든 코드를 보안에 중요한 코드로 해석합니다. 이러한 경우 메서드는 보안 안전에 중요합니다. 특성을 지정하지 않으면 공용 언어 런타임에서 투명 규칙을 자동으로 결정하게 됩니다.
SecurityTransparent: 모든 코드가 투명하고, 전체 어셈블리는 특별 권한이 있거나 안전하지 않은 작업을 수행하지 않습니다.
SecurityCritical: 이 어셈블리의 형식에 의해 도입된 모든 코드가 중요하고, 다른 모든 코드는 투명합니다. 이 시나리오는 특성을 지정하지 않는 경우와 유사하지만 공용 언어 런타임에서 투명 규칙을 자동으로 결정하지는 않습니다. 예를 들어, 가상 또는 추상 메서드를 재정의하거나 인터페이스 메서드를 구현하면 해당 메서드는 기본적으로 투명합니다. 메서드에 SecurityCritical 또는 SecuritySafeCritical이라는 주석을 명시적으로 지정해야 하며 그렇지 않으면 로드 시간에 TypeLoadException이 throw됩니다. 이 규칙은 기본 클래스와 파생 클래스가 동일한 어셈블리에 있는 경우에도 적용됩니다.
AllowPartiallyTrustedCallers(수준 2에만 해당): 모든 코드가 기본적으로 투명합니다. 그러나 개별 형식과 멤버는 다른 특성을 가질 수 있습니다.
다음 표에서는 수준 2의 어셈블리 수준 동작을 수준 1과 비교합니다.
어셈블리 특성 |
수준 2 |
수준 1 |
|---|---|---|
부분적으로 신뢰할 수 있는 어셈블리에 특성이 없음 |
형식 및 멤버는 기본적으로 투명합니다. 그러나 형식 및 멤버가 보안에 중요하거나 보안 안전에 중요할 수도 있습니다. |
모든 형식과 멤버가 투명입니다. |
특성 없음 |
특성을 지정하지 않으면 공용 언어 런타임에서 투명 규칙을 자동으로 결정하게 됩니다. 모든 형식 및 멤버가 보안에 중요합니다. 그러나 보안에 중요한 형식 및 멤버가 상속 규칙을 위반하는 경우는 예외입니다. |
완전히 신뢰할 수 있는 어셈블리(전역 어셈블리 캐시의 어셈블리 또는 완전히 신뢰할 수 있는 것으로 AppDomain에서 확인된 어셈블리)의 경우 모든 형식은 투명하고 모든 멤버는 보안 안전에 중요합니다. |
SecurityTransparent |
모든 형식과 멤버가 투명입니다. |
모든 형식과 멤버가 투명입니다. |
SecurityCritical(SecurityCriticalScope.Everything) |
해당 사항 없음. |
모든 형식과 멤버가 보안에 중요한 형식 또는 멤버입니다. |
SecurityCritical |
이 어셈블리의 형식에 의해 도입된 모든 코드가 중요하고, 다른 모든 코드는 투명합니다. 가상 또는 추상 메서드를 재정의하거나 인터페이스 메서드를 구현하는 경우 명시적으로 메서드에 SecurityCritical 또는 SecuritySafeCritical이라는 주석을 지정해야 합니다. |
모든 코드는 기본적으로 투명합니다. 그러나 개별 형식과 멤버는 다른 특성을 가질 수 있습니다. |
형식 및 멤버 주석
형식에 적용되는 보안 특성은 해당 형식에 의해 도입된 멤버에도 적용됩니다. 그러나 보안 특성은 기본 클래스의 가상 또는 추상 재정의나 인터페이스 구현에는 적용되지 않습니다. 다음 규칙은 형식 및 멤버 수준의 특성 사용에 적용됩니다.
SecurityCritical: 형식 또는 멤버는 중요하며, 완전히 신뢰할 수 있는 코드에서만 호출할 수 있습니다. 보안에 중요한 형식에 도입된 메서드는 중요합니다.
.gif "중요")
중요기본 클래스 또는 인터페이스에 도입되거나 보안에 중요한 클래스에서 재정의 또는 구현된 가상 및 추상 메서드는 기본적으로 투명합니다.이러한 메서드는 SecuritySafeCritical 또는 SecurityCritical로 식별되어야 합니다.
SecuritySafeCritical: 형식 또는 멤버가 보안 안전에 중요합니다. 그러나 형식 또는 멤버는 투명 코드(부분적으로 신뢰할 수 있는 코드)에서 호출할 수 있고 다른 중요한 코드처럼 사용 가능합니다. 코드에 대해 보안 감사가 수행되어야 합니다.
맨 위로 이동
재정의 패턴
다음 표에서는 수준 2 투명성에서 허용되는 메서드 재정의를 보여 줍니다.
기본 가상/인터페이스 멤버 |
재정의/인터페이스 |
|---|---|
Transparent |
Transparent |
Transparent |
SafeCritical |
SafeCritical |
Transparent |
SafeCritical |
SafeCritical |
Critical |
Critical |
맨 위로 이동
상속 규칙
이 단원에서는 액세스 및 기능에 기반하여 Transparent, Critical 및 SafeCritical 코드의 순서가 다음과 같이 지정됩니다.
Transparent < SafeCritical < Critical
형식 관련 규칙: 왼쪽에서 오른쪽으로 갈수록 액세스가 제한적입니다. 파생 형식의 경우 최소한 기본 형식만큼 제한적이어야 합니다.
메서드 관련 규칙: 파생 메서드는 기본 메서드에서의 액세스 가능성을 변경할 수 없습니다. 기본 동작의 경우 주석이 지정되지 않은 모든 파생 메서드는 Transparent입니다. 재정의된 메서드에 명시적으로 SecurityCritical이라는 주석이 지정되지 않으면 중요한 형식을 파생할 경우 예외가 throw됩니다.
다음 표에서는 허용되는 형식 상속 패턴을 보여 줍니다.
기본 클래스 |
파생 클래스의 투명성 |
|---|---|
Transparent |
Transparent |
Transparent |
SafeCritical |
Transparent |
Critical |
SafeCritical |
SafeCritical |
SafeCritical |
Critical |
Critical |
Critical |
다음 표에서는 허용되지 않는 형식 상속 패턴을 보여 줍니다.
기본 클래스 |
파생 클래스의 허용되지 않는 투명성 |
|---|---|
SafeCritical |
Transparent |
Critical |
Transparent |
Critical |
SafeCritical |
다음 표에서는 허용되는 메서드 상속 패턴을 보여 줍니다.
기본 메서드 |
파생 메서드의 투명성 |
|---|---|
Transparent |
Transparent |
Transparent |
SafeCritical |
SafeCritical |
Transparent |
SafeCritical |
SafeCritical |
Critical |
Critical |
다음 표에서는 허용되지 않는 메서드 상속 패턴을 보여 줍니다.
기본 메서드 |
파생 메서드의 허용되지 않는 투명성 |
|---|---|
Transparent |
Critical |
SafeCritical |
Critical |
Critical |
Transparent |
Critical |
SafeCritical |
.gif "참고") 참고 |
|---|
이러한 상속 규칙은 수준 2 형식 및 멤버에 적용됩니다.수준 1 어셈블리의 형식은 보안에 중요한 수준 2 형식 및 멤버에서 상속될 수 있습니다.따라서 수준 2 형식 및 멤버는 수준 1 상속자를 위한 개별적인 상속 요청을 가져야 합니다. |
맨 위로 이동
추가 정보 및 규칙
LinkDemand 지원
수준 2 투명성 모델은 LinkDemand를 SecurityCriticalAttribute 특성으로 대체합니다. 레거시(수준 1) 코드에서 LinkDemand는 자동으로 Demand로 간주됩니다.
리플렉션
중요한 메서드를 호출하거나 중요한 필드를 읽으면 private 메서드 또는 필드를 호출하는 경우처럼 완전 신뢰 요청이 트리거됩니다. 따라서 완전 신뢰 코드는 부분 신뢰 코드와 달리 중요한 메서드를 호출할 수 있습니다.
형식, 메서드 또는 필드가 SecurityCritical, SecuritySafeCritical 또는 SecurityTransparent인지 확인하기 위해 System.Reflection 네임스페이스에는 IsSecurityCritical, IsSecuritySafeCritical 및 IsSecurityTransparent 속성이 추가되어 있습니다. 이러한 속성을 사용하면 특성이 있는지 여부를 검사하는 대신 리플렉션을 통해 투명성을 확인할 수 있습니다. 투명성 규칙은 복잡하기 때문에 특성을 검사하는 것만으로는 충분치 않을 수 있습니다.
| 참고 |
|---|
중요한 코드와 동일한 기능을 갖지만 투명 코드에서 호출할 수 있다는 점에서 SafeCritical이 매우 중요하기 때문에 SafeCritical 메서드는 IsSecurityCritical및 IsSecuritySafeCritical에 대해 true를 반환합니다. |
동적 메서드는 연결된 모듈의 투명성을 상속하며, 형식에 연결된 경우에도 해당 형식의 투명성을 상속하지는 않습니다.
완전 신뢰에서 확인 건너뛰기
완전히 신뢰할 수 있는 투명 어셈블리에 대해서는 SecurityRulesAttribute 특성에서 SkipVerificationInFullTrust 속성을 true로 설정하여 확인을 생략할 수 있습니다.
[assembly: SecurityRules(SecurityRulesSet.Level2, SkipVerificationInFullTrust = true)]
SkipVerificationInFullTrust 속성은 기본적으로 false이기 때문에 확인을 생략하려면 이 속성을 true로 설정해야 합니다. 이와 같은 설정은 최적화를 위해서만 지정되어야 합니다. 어셈블리의 투명 코드가 확인 가능한지 여부를 PEVerify 도구에서 transparent 옵션을 사용하여 확인해야 합니다.
맨 위로 이동