코드 액세스 보안

닷넷 프레임워크에서 코드 액세스 보안(영어: Code Access Security)은 신뢰되지 않은 코드로부터 특권 동작을 수행하는 것을 방지하기 위한 마이크로소프트의 솔루션이다. CLR어셈블리를 로드할 때, 코드 그룹을 가져오기 위해 어셈블리로 된 증명 정보을 요구한다. 코드 그룹에 권한 집합(하나 이상의 권한)이 포함된다. 특권 동작을 수행하는 코드는 CLR이 콜 스택 워크를 하도록 코드 요청에 액세스한다. 그리고 콜 스택에서 어셈블리의 각 메서드의 어셈블리가 유효한 권한 집합인지 검사한다. 코드 그룹과 권한 집합은 보안 정책에서 정의된 기계의 관리자(Administrator)에 의해서 결정된다.

증명 정보

증명 정보는 어셈블리 안에 정보가 들어있다. 닷넷 코드 액세스 보안의 기본값은 다음과 같다:

  • 응용 프로그램 디렉터리 - 어셈블리가 상주하고 있는 디렉터리.
  • 게시자 - 어셈블리 게시자의 디지털 서명 (인증 코드로 서명된 어셈블리 필요).
  • URL - 어셈블리가 게시된 위치의 전체 URL.
  • 사이트 - 원격 도메인, 가상 사설망, URL의 호스트 이름.
  • 영역 - 어셈블리가 상주하고 있는 보안 영역
  • 해시 - 특정 버전을 식별하는 어셈블리 해시 암호.
  • 강력한 이름 - 어셈블리에 인증하기 위한 인증키에 대한 공유키, 버전, 어셈블리 이름의 조합. 인증 키는 X509 인증을 하지 않지만, 하지만 커스텀 키는 SN.EXE나 비주얼 스튜디오라는 강력한 이름 도구를 이용해 발생시킨다.

개발자는 사용자 정의 증명정보(어셈블리 증명정보라고도 함)를 만들 수 있으나 보안 어셈블리를 쓰는 것이 요구되며 1.1 버전에서는 동작하지 않는다. 어셈블리 해시에 기반한 어셈블리는 쉽게 코드로 얻을 수 있다. 예를 들면 C#로는 증명 정보를 다음 코드 절에 의해 얻을 수 있다:

 this.GetType().Assembly.Evidence

정책

정책은 코드 그룹 멤버가 결정하도록 증명 정보를 사용하는 표현의 집합이다. 코드 그룹은 그룹 내에서 어셈블리 권한 집합을 제공한다. .NET에서는 네 개의 정책이 존재한다:

  • 엔터프라이즈 - 도메인 컨트롤러에 가입한 기계에 관한 정책.
  • 기계 - 현재 기계에 대한 정책.
  • 사용자 - 로그인한 사용자에 대한 정책.
  • 앱도메인 - 실행 중인 응용 프로그램 도메인에 대한 정책.

처음 이 세 가지 정책은 XML 파일로 저장되며 닷넷 구성 도구 1.1 (mscorcfg.msc)를 통해 관리를 받는다. 마지막 정책은 현재 응용 프로그램 도메인의 코드를 통해 관리된다. 코드 액세스 보안은 어셈블리의 증명 정보를 제출하고 어셈블리에 인증된 권한으로 교점(증명된 권한 집합의 공통 권한)을 받는다. 기본 값으로 엔터프라이즈, 사용자, 앱도메인 정책은 전체 신뢰(모든 어셈블리가 모든 권한을 갖도록 하는 역할)을 제공하며, 기계 정책은 좀 더 제한되어 있다. 교점부터는 기계 정책에 의해 결정된 마지막 권한 집합을 받는다. 참고로 이 정책 시스템은 닷넷 프레임워크 4.0.에서 제거되었다.[1]

코드 그룹

코드 그룹은 명명된 권한 집합으로 증명 정보의 항목에 들어있다. 관리자는 .NET 구성 도구를 사용하여 특정한 증명 정보의 형식(예를 들면, 사이트)나 증명 정보의 특정 값(예를 들면 http://localhost)를 지정할 수 있고 코드 그룹의 권한 집합이 인증되어 있는지 확인할 수 있다.

코드 요청

코드가 특권 동작을 하기 위해 하나 이상의 권한을 요청한다. 코드 요청은 CLR이 각각의 메서드에 대한 콜 스택 워크를 하고 CLR이 코드 요청된 권한 중 메서드의 어셈블리의 인증된 권한을 안전하게 한다. 만약 권한이 인증되지 않았다면 보안 예외가 발생된다. 이것은 다운로드한 코드로부터 특권이 발생되는 것을 막는다. 예를 들면 만일 신뢰되지 않는 사이트로부터 어셈블리를 내려받았다면 어셈블리는 어떠한 파일도 IO 권한을 갖지 않고 만일 어셈블리가 파일에 액세스를 시도하면 코드 액세스 보안은 호출하는 것을 방지하기 위해 예외를 발생시킨다.

각주

  1. “Summary of Changes in Code Access Security”. 2011년 1월 28일에 확인함. 

외부 링크