Share via

요청

  • 아티클

업데이트: 2007년 11월

보안 요청 호출을 선언적이나 명령적으로 사용하여 직접 또는 간접 호출자가 라이브러리에 액세스할 때 필요한 권한을 지정할 수 있습니다. 직접 호출자는 라이브러리의 정적 또는 인스턴스 메서드를 명시적으로 호출하며, 간접 호출자는 라이브러리를 호출하는 다른 라이브러리의 정적 또는 인스턴스 메서드를 호출합니다. 요청을 사용할 경우 코드가 포함된 응용 프로그램은 요청에서 지정하는 권한이 모든 직접 및 간접 호출자에게 있는 경우에만 실행됩니다. 요청은 신뢰되지 않은 코드는 액세스하지 못하도록 클래스 라이브러리에서 보호된 리소스를 사용하는 경우 특히 유용합니다. 명령적이나 선언적 구문 중 하나를 사용하여 요청을 코드에 삽입할 수 있습니다.

대부분의 .NET Framework 클래스에는 자신과 연결된 요청이 이미 있으므로 보호된 리소스에 액세스하는 클래스를 사용할 때마다 요청을 추가할 필요가 없습니다. 예를 들어, StreamWriter 클래스는 열릴 때마다 자동으로 FileIOPermission에 대한 보안 요청을 합니다. StreamWriter 클래스를 사용할 때 FileIOPermission을 요청하면 중복된 비효율적인 스택 워크가 발생합니다. 사용자 지정 권한을 요구하는 사용자 지정 리소스를 보호하려면 요청을 사용해야 합니다.

요청은 선언적이나 명령적일 수 있습니다.

스택 워크

요청은 현재 호출 스택의 모든 호출 함수(또는 스택 프레임)를 지정된 권한에 대해 검사하는 스택 워크라는 분석을 수행하여 보안을 적용합니다. 요청이 트리거되면 다음이 발생합니다.

  • 스택 워크가 요청이 발생한 현재 스택이 아니라 호출자 스택 프레임에서 시작됩니다. 예를 들어, 메서드 A가 메서드 B를 호출하고 메서드 B에 요청이 있으면 스택 워크가 메서드 A의 스택 프레임에서 시작됩니다. 메서드 B는 스택 워크의 일부로 평가되지 않습니다.

  • 스택 워크가 스택의 프로그램 진입점(일반적으로 Main 메서드)에 도달할 때까지 또는 assert와 같은 스택 워크 한정자가 검색될 때까지 호출 스택을 진행합니다. 스택 워크 한정자에 대한 자세한 내용은 보안 검사 재정의를 참조하십시오.

  • 같은 권한의 요청과 스택 워크 한정자(예: assert)가 같은 스택 프레임에 나타나는 경우에는 요청이 우선합니다.

  • 선언적 구문의 동작과 명령적 구문의 동작은 서로 같습니다.

  • 스택 워크는 항상 호출 스택 프레임에서 시작하므로 프로그램 진입점에 있는 요청은 평가할 수 없으나 이 경우에는 평가할 호출 프레임이 전혀 없으므로 프로그램 진입점에서의 요청은 항상 성공하게 됩니다.

선언적 요청

선언적 요청은 특성을 사용하여 코드의 메타데이터에 정보를 삽입합니다. 선언적 구문을 사용하여 코드의 클래스 수준이나 메서드 수준에서 요청을 삽입할 수 있습니다.

선언적 보안 검사를 클래스 수준에서 삽입하면 이 검사는 각 클래스 멤버에 적용됩니다. 그러나, 선언적 보안 검사를 멤버 수준에서 삽입하면 이 검사는 해당 멤버에만 적용되며 클래스 수준에 지정된 권한이 있는 경우 이를 재정의합니다. 예를 들어, 클래스 수준에서 PermissionA가 필요하다고 지정하고 해당 클래스의 Method1에 대해서는 PermissionB가 필요하다고 지정한 경우를 가정합니다. Method1이 호출되면 보안 검사에서는 PermissionB만 찾지만, 클래스의 다른 메서드에서는 PermissionA가 여전히 필요합니다.

다음 예제에서는 ReadData 메서드의 모든 호출자에 CustomPermission이라는 사용자 지정 권한에 대한 선언적 요청을 삽입합니다. 이 권한은 가상의 사용자 지정 권한이므로 .NET Framework에는 없습니다. 사용자 지정 권한에는 요청을 하는 별도로 정의된 CustomPermissionAttribute가 있습니다. 이 경우, CustomPermissionAttribute는 SecurityAction.Demand 플래그를 사용하여 특성이 수행할 요청 형식을 지정합니다.

<CustomPermissionAttribute(SecurityAction.Demand, Unrestricted := True)>Public Shared Function  ReadData() As String
   'Read from a custom resource.
End Function

[CustomPermissionAttribute(SecurityAction.Demand, Unrestricted = true)]
public static string ReadData()
{
   //Read from a custom resource.
}

명령적 요청

권한 개체의 새 인스턴스를 만들고 이 개체의 Demand 메서드를 호출하여 코드의 메서드 수준에 명령적 요청이 삽입됩니다. 명령적 구문을 사용하여 클래스 수준에 요청을 삽입할 수는 없습니다.

코드에 삽입하는 명령적 요청은 Demand 메서드가 호출되는 메서드에서 나머지 모든 코드를 효율적으로 보호합니다. 보안 검사는 Demand가 실행될 때 수행됩니다. 보안 검사에서 실패하면 SecurityException이 throw되며 메서드나 멤버의 나머지 코드는 SecurityException이 catch되어 처리되어야 실행됩니다.

다음 예제에서는 명령적 구문을 사용하여 사용자 지정 권한 CustomPermission에 대한 요청을 모든 호출자에 삽입합니다. 이 코드는 CustomPermission 클래스의 새 인스턴스를 만들며 PermissionState.Unrestricted 플래그를 생성자에게 전달합니다. 그런 다음, Demand 메서드가 호출됩니다.

Public Shared Sub ReadData()
   Dim MyPermission As New CustomPermission(PermissionState.Unrestricted)
   MyPermission.Demand()
   'Read from a custom resource.
End Sub  

public static void ReadData()
{
   CustomPermission MyPermission = new CustomPermission(PermissionState.Unrestricted);
   MyPermission.Demand();

   //Read from a custom resource.
}
참고:

64비트 플랫폼과 32비트 플랫폼은 요청 작업에 대한 최적화 동작이 서로 다릅니다. 64비트 플랫폼에서는 다른 호출 어셈블리가 없는 경우 요청이 포함된 어셈블리의 권한 부여 설정을 검사하지 않습니다. 그러나 이 최적화의 경우 호출 어셈블리가 있어도 스택 워크가 계속 수행되므로 권한 높이기가 발생하지 않습니다. 32비트 플랫폼에서 요청 작업은 요청이 들어 있는 어셈블리와 모든 호출 어셈블리의 권한 부여 설정을 검사합니다.

참고 항목

개념

보안 요청

사용자 고유의 코드 액세스 권한 만들기

선언적 보안 지원 추가

보안 클래스 라이브러리 작성

참조

SecurityException

기타 리소스

특성을 사용하여 메타데이터 확장

코드 액세스 보안