[연재] 4. 보안 정책(Security Policies)

4. 보안 정책(security policies)
증거들은 그 자체만으로는 의미가 없고 PC에 설정된 보안 정책을 평가해서 그 증거들에 어떤 권한을 부여되는가 즉 어셈블리에 어떤 권한이 부여되는가에 따라서 어셈블리가 로딩도 될 수 있고 코드를 정상적으로 실행할 수 있는 가도 결정된다.
각 PC의 보안 정책은 .config 파일에 저장된다. 이 파일에는 어셈블리의 증거별 권한 집합이 정의되어 있다. 각 PC의 보안정책에는 “이 PC에서는 어떤 증거에 대해서는 어떤 권한을 부여하겠다”는 정책이 표현되어 있는 것이다. 보안 정책 파일은 사용자(관리자, 개발자)가 편집해서 적절한 보안 정책을 PC에 적용할 수 있다.  .NET의 SDK와 함께 제공되는 구성 편집 툴이 있는데, 이것을 사용하면 쉽게 보안 정책을 편집할 수 있다. 또한 기존의 보안 내용을 MS 인스톨러 프로그램 MSI으로 쉽게 다른 PC를 설정할 수도 있다. 보안 정책 편집에 대해서는 뒤에 다루겠다.
그러나 보안 정책은 하나의 파일에 정의되어 있지는 않다. 하나의 어셈블리에 적용될 수 있는 보안 정책 파일은 4개의 레벨로 구분되어 각 레벨별 정책을 담고 있는 .config 파일이 있다. 

보안 정책 레벨

사용자별로 보안 정책을 설정할 수 있다는 것은, 현재 로그인한 사용자에 따라서 어떤 어셈블리는 로딩될 수도 있고 아니면 보안 예외가 발생할 수 있다는 것이다. 마찬가지로 컴퓨터레벨의 보안 정책이 있다는 얘기는 어떤 컴퓨터에서 문제없이 실행되던 어셈블리가 다른 컴퓨터에서는 보안 문제가 일어날 수 있다는 것이다.
보안 정책 레벨은 이렇게 4가지 일 수 있다. 엔터프라이즈 레벨의 정책은 AD서버(Active Directory서버)에 등록된 컴퓨터들별로 보안 정책을 달리할 수 있다는 것이고 마찬가지로  컴퓨터별, 사용자별, 애플리케이션별로 정책을 달리 할 수 있다는 것이다. 보안정책 레벨은 .NET의 System.Security.PolicyLevelType 열거형으로 정의되어 있다.

namespace System.Security
{
  public enum PolicyLevelType {
  User,
  Machine,
  Enterprise,
  AppDomain
  }
}

기본적으로 AD서버 레벨의 권한설정(enterprisesec.config)에서는 모든 어셈블리에 FullTrust 권한을 부여한다. 그리고 컴퓨터 레벨의 설정(security.config)에서는 GAC에 등록된 어셈블리에만 모든 권한을 부여한다. 이 정책은 레벨 순서대로 적용이 된다. 즉 엔터프라이즈 정책->컴퓨터 정책->사용자정책->애플리케이션 정책 순으로 적용이 된다.
근데, 만약 이 4가지 레벨의 정책이 특정 권한에 대한 설정 내용을 가지고 있다면 어떻게 되는가?

레벨별 다른 권한 부여 예
예를 들어 엔터프라이즈 레벨의 보안 설정에서는 모든 어셈블리에 대해서 로컬 파일에 대해서 읽기 쓰기 권한을 부여하고 있다. 그러나 그림에서 처럼 그 다음 레벨의 컴퓨터 정책에서는 Url 증거가 "http://Sever/*"인 즉 이 경로에서 받은 어셈블리에 대해서는 로컬 파일에 대해 읽기 권한만을 부여한다. 그럼 해당 어셈블리에 대한 권한은 어떻게 부여되어야 할까? 그렇다. 읽기 권한만이 부여될 것이다.
이처럼 만약 어떤 어셈블리가 이 4가지 정책에 모두 연관될 수 있다면, 즉 어떤 어셈블리가 있는데, 이 어셈블리가 실행되는 컴퓨터가 AD서버에 등록되어 있고 그리고 이 애플케이션을 실행하기위해서 로그인한 사용자도 이 어셈블리에 대해 어떤 보안 설정을 해뒀고 그리고 애플리케이션 레벨에서도 어떤 보안 설정을 해 둔 경우라면 결과는 다음 그림과 같다.
그림 6 보안 정책의 중첩
그림은 적용 가능한 모든 정책의 교집합에 해당하는 권한이 어셈블리에 부여되는 최종 권한이 된다는 것을 보여준다.
보안 정책 파일에는 3가지의 주요 내용 설정이 있다: 코드그룹(Code Group), 멤버 조건(Member Condition), 권한 그룹(Permision Set).
 

보안정책 적용 과정

코드그룹, 멤버조건, 권한 집합를 갖는 구조가 다른 레벨의 보안정책에도 동일하게 적용될 수 있으나 그림에서는 컴퓨터 정책 레벨의 보안 정책을 예로 보여주고 있다.
각 보안 정책 레벨별로 코드 그룹(Code Group)이라는 것이 여러 개 정의될 수 있다. 코드 그룹은 어셈블리들이 모임의 멤버가 되는 것이다. 이 코드 그룹은 권한을 부여하는 대상의 단위가 된다.
코드 그룹에는 두 가지 중요한 속성이 있다 : 멤버조건(Member Condition), 권한 집합(Permission Set).
관리자는 먼저 코드 그룹을 생성할 수 있고, 그곳에 가입할 수 있는 멤버(즉 어셈블리)들에 대한 조건을 정의할 수 있다. 멤버 조건(Member Condition)이란 어셈블리의 증거들에 대한 조건이다. 즉 "어떤 증거를 가지고 있는 멤버만이 이 코드그룹에 가입(?)된다."라는 의미이다. .NET에는 기본적으로 다음과 같은 멤버 조건을 가지고 있다: 사이트, Url, Zone, ApplicaionDirectory, 강력한 이름, 게시자, 해시, GAC. 즉 "이 코드 그룹에는 Url(사이트, Zone…)증거로 특정 값을 가지고 있는 어셈블리가 멤버로 가입될 수 있다"는 의미가 된다.
코드 그룹에는 또한 권한 집합(permission set) 매핑된다. 원어 그대로 보면 어셈블리에게 허용되는 권한(permission)들의 집합(set)이다. 권한 집합에는 여러 개의 권한들이 포함될 수 있는데, 즉 코드 그룹에 부여되는 권한은 집합 단위로 적용되는 것이다. 다음은 기본적으로 .NET에 정의되어 있는 권한들을 보여주고 있다.
 

.NET 권한들과 보호되는 자원들

다음 표는 기본적으로 정의되어 있는 권한 집합을 보여주고 있고, 그 권한 그룹에는 어떤 권한들이 있는지도 보여주고 있다.

.NET 기본 권한 그룹

지금까지의 개념을 이야기로 풀이해보면 이렇다: "어떤 코드 그룹에는 특정 증거 조건을 갖는 멤버들만이 가입할 수 있으며 그 그룹에 포함되게 되면 어떤 권한들을 가질 수 있다". 각 어셈블리들에 대한 증거 조건을 판단하고 코드 그룹의 멤버로서의 적합 여부를 평가하는 것이 바로 보안 평가기(policy evaluator, 권한 풀이기)이다.
하나의 어셈블리가 여러 개의 코드그룹에 속하는 경우도 있을 것이다. 이런 경우 권한 풀이기는 어떻게 처리할까? 기본적으로 이런 경우는 이것은 합집합(union)의 개념이다. 예를 들어 사용자가 정의한 "SampleGroup"이라는 코드 그룹에도 속하고 기본 코드 그룹 LocalIntranet_Zone에도 속 한다면 두 그룹에 부여된 모든 권한을 가질 수 있다.

동일 정책 레벨상의 코드 그룹들의 권한 합집합

코드 그룹은 자식 그룹을 포함할 수 있도록 되어 있어서, 그림과 같은 계층 구조로 될 수 있다. 코드 그룹이 계층 구조로 이뤄지면 어셈블리가 사용할 수 있는 권한에 대한 합집합의 개념이 자식 코드 집합으로 확장될 수 있다. 무슨 말인가 하면, 특정 어셈블리가 코드 그룹 A의 멤버 조건을 만족하면 B,C,D에 대한 멤버 조건도 체크한다. 만약 그룹 C에 대한 조건이 만족되면 C의 권한도 부여받고 다시 E,F 그룹에 대한 조건도 체크를 하게 된다.

코드그룹 계층구조

따라서 자식 그룹을 추가해서 계층구조를 만드는 방법을 이용해서 어셈블리에 새로운 권한 집합을 매핑시킬 수 있다.
코드 그룹, 멤버 조건, 권한, 권한 그룹 등은 모두 사용자 정의가 가능해서 원하는 대로 확장할 수 있는 개념들이다. 달봉이의 능력을 넘어서는 주제들로서 여기서는 다루지 않는다.