Active Directory에서 권한 위임

At a Glance:

관리자 역할 정의 OU 및 보안 그룹 모델 개발 보조 계정 사용 권한 위임용 도구

Active Directory의 강력한 위임 기능은 다양한 보안 문제를 해결하고 관리 작업을 단순화하는 데 매우 유용합니다. Active

Directory^® 내에서 적절히 권한을 위임하면 해당 환경에서 특정 역할을 강제 수행할 수 있고, 관리 상의 오류가 발생할 가능성과 그 영향을 줄일 수 있으며, 인프라 전체에 최소 권한 원칙을 적용할 수 있습니다. 그러나 Active Directory를 사용하는 많은 기업은 이 위임 기능을 제대로 활용하지 못하고 있습니다. 회사에 사용할 Active Directory 위임 모델을 개발하는 것은 일견 복잡해 보이기 때문입니다. 가장 큰 문제는 해당 조직의 고유한 상황에 맞는 위임 모델을 개발하는 것입니다. 그러나 사실 대부분의 IT 인프라에 거의 변경 없이 적용할 수 있는 매우 간단한 모델이 존재합니다.

모든 환경은 방식이나 형태에 있어 약간씩 다르긴 하지만 실제로 많은 대기업은 여러 측면에서 비슷하고 당면한 IT 문제도 같은 경우가 많습니다. 예를 들어 많은 기업은 지역별로 세분화되어 있고, 별도의 IT 엔지니어링 또는 운영 지원팀에서 발전했으며, 독립된 사업부를 갖추고 있습니다. 또한 권한 상승 문제, 서비스 계정 남용, "트러스트" 등을 처리해야 하는 대규모 기업도 많습니다.

트러스트는 Active Directory 포리스트를 여러 개 보유해야 하는 이유가 될 때가 많으며, 특정 부서나 지역이 다른 부서나 지역의 시스템 가용성에 영향을 미칠 수 있을 때 자주 문제가 발생합니다. 대부분의 경우 기술 수준은 조직 간에 다르기 때문에 특정 지역이나 사업부를 지원하는 데 필요한 특정 시스템 관련 지식이 부족할 때가 많습니다. 따라서 부서들은 대개 중앙 그룹에 관리 권한을 넘겨주지 않으려 합니다.

한편 Active Directory 구현의 경우 관리자는 Active Directory 인프라를 사용하는 응용 프로그램의 운용 규칙을 정의해야 합니다. 안타깝게도 응용 프로그램 설치 가이드에 자주 언급되는 일반적인 방법은 서비스 계정을 Domain Admins 그룹의 구성원으로 만드는 것입니다. 이런 방법의 문제는 서비스 계정이 본질적으로 일반 계정이라는 점입니다. 이러한 계정에 Domain Administrator 권한을 부여하면 IT 환경의 보안이 상당히 위험해집니다. 서비스 계정은 악의적이거나 부주의한 관리자 또는 응용 프로그램 내의 기본 보안 문제를 악용하는 공격자가 쉽게 악용할 수 있기 때문입니다.

이러한 문제는 해결하기 어려운 것으로 보일 수 있지만, Active Directory 위임 모델 구현의 좋은 시나리오가 되기도 합니다. 위임 모델의 개발은 반복 작업이 많은 디자인 프로세스로서, 다음 단계를 따르는 것이 좋습니다.

1. 조직 내의 IT 관리자 역할 정의
2. 조직 구성 단위 및 보안 그룹 모델 개발
3. IT 관리자의 보조 계정 설정
4. 권한 위임

이러한 단계를 보다 자세히 살펴보겠습니다.

역할 정의

역할을 정의하기 위해서는 우선 서비스 관리와 데이터 관리를 모두 철저히 이해해야 합니다. 이런 개념은 모든 Active Directory 위임 모델의 기초가 됩니다.

핵심을 요약하자면 서비스 관리는 Exchange 서버 및 도메인 컨트롤러와 같은 중요 디렉터리 서비스 인프라 구성 요소를 관리하는 것이고, 데이터 관리는 이러한 서비스 내에 상주하는 사서함 및 사용자 계정 등의 개체를 관리하는 것입니다. Active Directory의 범위 내에서 서비스 관리자는 디렉터리 서비스의 제공 및 가용성을 최종 책임지고, 데이터 관리자는 사용자 및 서버 계정, 그룹, 기타 도메인 리소스를 관리합니다.

Active Directory는 OU(조직 구성 단위)를 통해 정교한 권한 위임을 지원합니다. OU는 기존 디렉터리 서비스나 도메인 모델 내에서 관리자에게 제공된 것과 같은 수준의 권한을 제공하도록 자주 조정할 수 있습니다. 그러나 일부 기능은 위임이 불가능하고 확실히 신뢰할 수 있는 단일 그룹이나 엔터티가 관리해야 합니다.

작업 분석 또한 중요합니다. 즉, 관리자가 수행하는 Active Directory 작업이 무엇이고 이러한 작업이 역할에 어떻게 매핑되는지 알아야 합니다. 예를 들어 Active Directory 사이트 만들기는 서비스 관리 작업인 반면, 보안 그룹 멤버십 수정은 일반적으로 데이터 관리에 속합니다. 각 작업의 빈도, 중요도 및 난이도도 평가해야 합니다. 이러한 항목은 권한 위임 여부를 결정하기 때문에 작업 정의의 필수 요소입니다. 정기적으로 수행되는 작업, 위험 요소가 제한된 작업, 일상적인 작업 등은 위임에 적합한 대상입니다. 반면 드물게 수행되는 작업, 조직에 큰 영향을 미치는 작업, 높은 수준의 기술이 필요한 작업 등은 위임에 적합한 대상이 아닙니다. 이러한 작업에는 계정을 일시적으로 필요한 역할로 상향 조정하거나 작업을 재할당하는 에스컬레이션이 더 적합합니다.

대규모 조직은 특성이 많이 비슷하기 때문에 일반적인 위임 모델을 구현하는 것으로 간주해도 무방합니다. 본 기사의 목적에 맞게 여기서는 조직의 경계를 고려하고 트러스트 문제(예: 도메인 컨트롤러와 같은 전사적 자산의 가용성)를 완화하도록 주의하면서 관리 기능을 실행하는 일련의 샘플 역할을 제공하겠습니다. 이 모델은 단순한 예제로서, 조직 내에서 역할 논의를 시작하는 데 유용하긴 하지만 그대로 똑같이 사용해서는 안 됩니다.

일부 역할은 Active Directory에서 이미 지정되어 있지만 일부는 위임 모델을 완성하도록 처음부터 새로 만들어야 합니다. 많은 대규모 Active Directory 환경에 맞는 역할 집합의 예로는 서비스 관리의 경우 Enterprise Admins, Domain Admins, Tier4 Admins 등이 있고 데이터 관리의 경우에는 Tier3 Admins, Regional Admins, Tier2 Admins, Tier1 Admins 등이 있습니다. 이러한 역할과 해당 기능 목록이 그림 1에 나와 있습니다.

서비스 관리자

이제 서비스 관리자 역할을 자세히 살펴보도록 하겠습니다. 서비스 관리자는 중요한 인프라 구성 요소를 관리하며, 이 범주에 속한 관리자는 모두 높은 권한을 갖습니다. 따라서 작업 수행에 필요한 최소 권한 집합만 부여한다는 의미의 최소 권한 전략을 적용하는 것이 좋습니다.

Enterprise Admins 및 Domain Admins Active Directory는 디렉터리 내의 중요 기능에 필요한 보안 컨텍스트를 가진 두 개의 특수 관리자 그룹을 정의합니다. 이러한 그룹(Enterprise Admins 및 Domain Admins)은 최상위 서비스 관리를 담당합니다. 이렇게 높은 권한을 가진 그룹의 위험 요소를 줄이기 위해서는 해당 그룹의 멤버십을 제한하는 것이 좋습니다. 사실상 Enterprise Admins 그룹에는 영구 구성원이 없어야 하고 Domain Admins 그룹은 조직의 정규 직원으로 근무하는 소수의 신뢰할 수 있는 개인만 포함해야 합니다.

DHCP 서버 권한 부여 또는 Active Directory 사이트 생성과 같은 엔터프라이즈 관리 작업을 수행해야 할 경우 Active Directory 포리스트의 루트 도메인에 있는 Domain Admins는 Enterprise Admins 그룹의 멤버십을 관리하여 권한을 상승시킬 수 있습니다. 이러한 권한은 Enterprise Admins 그룹에 영구 구성원이 생기지 않도록 잠시 동안만 부여해야 합니다. 물론 특정 Active Directory 포리스트에 있는 Domain Admins 그룹의 모든 구성원은 동일하게 트러스트되어야 합니다.

대부분의 기업이 위임 모델을 개발할 때 범하기 쉬운 실수는 이러한 기본 제공 역할이 사용되지 않도록 해제하는 것입니다. 기본 역할을 수정하면 예상치 못한 결과가 초래될 수 있으며 서비스 팩 수정 버전이나 제품 업그레이드가 이러한 설정을 유지한다는 보장도 없습니다. 이러한 수정은 또한 조직 외부에 지원되지 않는 환경을 만들기도 합니다. 실용적인 방법은 기본 제공 그룹과 역할을 사용하면서 구성원을 제한하는 것입니다. 이렇게 하려면 이전에 Domain Admins과 같은 그룹의 멤버십에 의존했던 관리자에 대해 새 역할을 만들어야 할 수 있습니다.

Tier4 Admins 그룹은 모든 엔터프라이즈 서비스를 지원하는 중앙 집중식의 서비스 관리자로 구성됩니다. 이 그룹은 생성된 역할이므로 해당 조직의 특정 요구 사항에 맞게 디렉터리 서비스 및 시스템 액세스 권한을 조정할 수 있습니다. 이 그룹의 구성원은 서비스 관리자이지만 경우에 따라 포리스트 차원의 데이터 관리 작업을 수행할 수도 있습니다. Tier4 역할은 많은 시스템 클래스와 다양한 책임 영역을 보유하기 때문에 디렉터리 내에서 여러 하위 그룹으로 나뉩니다. 예를 들어 Exchange 서버와 같은 특정 시스템에 분리된 관리 작업을 제공하기 위해서는 별도의 Tier4 그룹을 만들어야 합니다. 이 그룹은 데이터 관리자의 에스컬레이션 지점 역할도 수행합니다.

사람들이 Domain Admins 그룹의 멤버십을 원하는 이유 중 하나는 특정 도메인의 모든 시스템에 대해 관리 권한을 얻기 위해서입니다. 이러한 서비스 관리자가 최소 권한 모드로 실행하도록 하려면 Domain Admins로 지정하지 않고 Tier4 Admins에 엔터프라이즈 서버 제어 권한을 부여하면 됩니다. 해당 그룹은 디렉터리 서비스에 대해 분리가 불가능한 많은 기본 권한을 가지므로 권한 상승을 방지하기 위해 Tier4 Admins에는 도메인 컨트롤러의 BUILTIN\Administrators 그룹 멤버십을 부여하면 안 됩니다. 예를 들어 특정 도메인의 BUILTIN\Administrators 그룹에 속한 구성원은 Domain Admins 그룹을 관리할 수 있기 때문에 구성원이 어떠한 견제와 균형 없이 권한을 상승하도록 허용할 수 있습니다.

기본 권한을 해제하면 안 된다는 규칙을 상기하면서 Tier4 그룹을 Server Operators 및 DNS Admins 기본 제공 도메인 그룹의 중첩 구성원으로 만들면 이런 위험을 완화할 수 있습니다. 이렇게 하면 도메인 컨트롤러를 로컬로 관리하면서 Tier4 Admins의 권한 상승 기능을 제한할 수 있습니다. Domain Controllers, Certificate Servers 등을 제외한 대다수 시스템의 경우 Tier4 Admins 그룹은 로컬 Administrators 그룹의 구성원으로 만들어야 합니다. 그룹 정책 내의 제한된 그룹 기능을 사용하면 중첩 로컬 그룹 멤버십을 자동화할 수 있습니다.

데이터 관리자

이제 데이터 관리 역할에 대해 설명하겠습니다. 이러한 역할은 누적 권한을 사용하여 디자인해야 합니다. 즉, Tier2 Admin에는 일부 추가 권한과 함께 Tier1 Admin의 모든 권한이 포함되어야 합니다. 따라서 이러한 그룹을 낮은 권한 단계부터 살펴보도록 하겠습니다.

Tier1 Admins 그룹은 이전에 만든 디렉터리 개체에 대한 일반 관리를 제공합니다. 이 그룹은 최소한의 교육을 받은 관리자나 암호 재설정과 같은 격리된 작업을 수행하는 관리자를 대상으로 합니다. 이 그룹에는 조직 구성 단위 내에서 사용자 계정 속성 수정, 사용자 계정 암호 재설정, 계정 잠금 해제, 사용자 계정 설정/해제, 워크스테이션 컴퓨터 계정 추가 및 재설정, 비관리 그룹의 그룹 개체 멤버십 수정 등을 수행할 수 있는 권한을 부여합니다.

Tier2 Admins 그룹은 Tier1 Admins에서 관리할 수 있는 경우에만 개체가 생성되도록 하여 개체의 선택적인 관리 및 생성을 설정합니다. 예를 들어 보안 그룹은 그룹 OU에만 만들 수 있습니다. Tier2 Admins는 Tier1 Admin 계정을 추가 및 수정할 수 있을 뿐만 아니라 OU의 사용자 계정을 추가, 수정 및 삭제하고 워크스테이션 컴퓨터 개체를 삭제할 수 있으며 서버, 연락처 및 공유 폴더 개체를 추가, 수정 및 삭제할 수 있습니다.

Regional Admins 그룹에는 해당 지역 OU 구조에 대한 독점적 권한이 부여됩니다. 그러나 디렉터리 내의 다른 지역 OU 구조는 관리할 수 없습니다. Regional Admin 계정은 높은 권한을 갖는 것으로 간주되므로 계정이 별도의 OU 계층에 저장되어 Tier4 Admin 서비스 관리자에 의해 관리됩니다. Regional Admins는 해당 OU 구조 내에서 다른 조직 구성 단위를 제외한 대부분의 개체를 무제한으로 만들 수 있습니다. 따라서 하위 계층에서 관리할 수 없는 개체가 생성될 수 있는 위험이 추가로 발생합니다.

다음은 Tier3 Admins입니다. 많은 조직은 중앙 집중식 또는 상위 계층의 헬프 데스크를 보유하고 있습니다. 이 역할은 데이터 관리자 목록을 채워 모든 Regional Admins에 데이터 관리자 그룹을 제공합니다. 권한은 디렉터리 내에서 특별히 이러한 그룹에 위임되는 것이 아니라 각 Regional Admins 그룹의 중첩 구성원을 통해 생성됩니다. 따라서 모든 데이터 관리자에게 최상위 에스컬레이션 지점뿐 아니라 서비스 관리 그룹으로 에스컬레이션되는 문제를 위한 입력 지점도 제공됩니다.

OU 및 보안 그룹 모델 작성

조직에서 역할을 정의한 후에는 OU와 보안 그룹 모델을 정의해야 합니다. Active Directory에서 OU를 만드는 주된 이유는 권한을 위임하고 그룹 정책 개체를 연결할 수 있는 지점을 만들기 위해서입니다. OU는 디렉터리 내에서 SOM(Scope-Of-Management)을 정의하여 권한을 다양한 수준의 개체로 제한하는 데 사용할 수 있습니다. 따라서 권한 위임을 위해 선택하는 방법은 OU 구조를 구현하는 방식을 결정하는 기본 요소가 됩니다.

이를 염두에 두고 모든 개체를 보유할 도메인 바로 아래에 최상위 OU나 일련의 OU를 만들어야 합니다. 이 OU는 Tier4 Admins의 최고 수준 SOM을 정의하려는 특정 목적을 지니고 있습니다. 최상위 OU를 만들면 디렉터리 서비스에 대한 권한이 도메인 수준이 아닌 OU 수준에서 명시적으로 시작할 수 있습니다. 도메인이 아닌 최상위 OU에서 위임하면 사용자가 기본 제공 도메인 그룹을 조작하여 권한을 상승할 위험이 줄어듭니다.

최상위 OU 아래에는 분리된 데이터 관리 팀이 있는 각 지역이나 업무 단위를 나타내는 별개의 하위 OU 계층을 만들어야 합니다. 각 지역의 하위 OU에는 디렉터리 개체 관리를 위한 확장할 수 없는 일반 OU 계층이 있어야 합니다. 권한 위임 중 대부분이 자동화될 예정이므로 지속적인 관리를 위해서는 통일성이 매우 중요합니다. 이것은 지역마다 고유한 OU를 원할 수 있기 때문에 어려울 수 있습니다. 그러나 IT 관리자는 자신의 입장을 고수해야 하며 한 지역에만 확장이 필요해도 모든 지역의 하위 OU 구조를 확장해야 합니다. 처음에는 어려워 보일 수 있지만 조직이 포괄적인 틀을 제공하면 주변 상황은 시간이 흐를수록 그 틀에 맞추어 가게 됩니다.

마지막으로 별개의 하위 관리 그룹과 계정을 만들어 관리자의 권한 상승 기능을 제거하십시오(각 하위 OU 계층의 Tier1 Admins, Tier2 Admins 및 Regional Admins 그룹). 이러한 계정을 별개의 OU에 배치하면 관리를 해당 수준 이하로 제한할 수 있습니다. 따라서 적절한 권한이 없는 OU에 모든 Tier1 Admins 계정 및 관련 보안 그룹이 상주하면 관리자가 다른 관리자 계정을 가로채거나 다른 관리자의 권한을 자신의 수준으로 상승시킬 수 없습니다. 예를 들어 Domain Admins 그룹의 구성원은 도메인의 다른 사용자 계정을 Domain Admin으로 만들 수 있습니다. 그러나 이 OU 모델이 배치되어 있으면 이러한 위험이 줄어듭니다. 그림 2는 관련 보안 그룹이 포함된 OU 구조의 예를 보여 줍니다.

그림 2 OU 구조 및 관련 보안 그룹

보조 계정 설정

위임 모델의 성공 여부는 최소 권한 원칙의 적용에 달려 있습니다. 즉, 보안 사용자가 특정 역할에 필요한 작업만 수행할 수 있도록 해야 하는 것입니다. 그러나 안타깝게도 많은 IT 관리자는 디렉터리 관리와 일상적인 작업(예: 웹 검색 및 전자 메일 읽기)에 동일한 보안 사용자를 사용합니다. 별도의 계정을 보유하면 계층이 지정된 관리자가 실수로 디렉터리 서비스를 손상시키거나 일상적인 응용 프로그램을 통해 디렉터리 관리자를 대상으로 하는 공격에 노출될 가능성이 줄어듭니다.

사용자에게 다시 로그온하도록 요구하지 않고 이 작업을 수행하려면 Secondary Logon 서비스(Runas.exe)를 사용해야 합니다. 이 서비스를 사용하면 사용자가 서버와 워크스테이션에서 스크립트 또는 실행 파일을 실행할 때 대체 자격 증명 집합을 제공하여 자신의 권한을 상승시킬 수 있습니다.

최소 권한의 계정을 사용한다는 개념은 비교적 단순하지만 오래된 IT 관행을 깨기 어려운 기업에서는 이 개념을 적용하기가 힘듭니다. 권한 있는 계정이 일상적인 작업에 사용되지 않도록 할 수 있는 간단한 방법은 Exchange 서버에서 이러한 계정에 메일 액세스 권한을 제공하지 않고 조직 내에서 관리 정책을 통해 이를 강제 수행하는 것입니다. 비교적 단순한 이 방법을 사용하면 해당 계정이 관리 작업 이외의 일상적인 작업에 사용될 가능성이 상당히 줄어듭니다.

권한 위임

위임 모델 개발의 최종 단계는 Active Directory 내에서 권한을 실제로 위임하는 것입니다. 이렇게 하려면 디렉터리 내에 저장된 데이터에 대해 ACE(액세스 제어 항목) 및 ACL(액세스 제어 목록)을 조작해야 합니다. Active Directory 컨테이너의 ACL은 생성 가능한 개체와 해당 개체의 관리 방법을 정의합니다. 권한 위임에는 개체 보기, 지정된 클래스의 하위 개체 만들기, 지정된 클래스의 개체에 대한 특성 및 보안 정보 읽기 등과 같은 기본 개체 작업이 포함됩니다. 이러한 기본 작업 외에도 Active Directory는 다음으로 보내기, 복제 토폴로지 관리 등의 작업을 지원하는 확장 권한을 정의합니다.

이전 단계에서는 정의된 조직 구성 역할에 매핑되는 보안 그룹 만들기에 대해 설명했습니다. 모든 역할에는 하위 OU 구조별로 연결된 보안 그룹이 있습니다. 위임 모델을 구현하려면 이러한 그룹에 디렉터리 개체에 대한 사용 권한을 할당해야 합니다. 이 시점에서는 항목을 새로 개발하고 복잡하게 사용자 지정된 환경을 만들고 싶지는 않을 것입니다. 대신 기본 제공 그룹과 권한을 최대한 활용해 볼 수 있습니다. 특정 역할이 포리스트의 DNS 레코드를 관리해야 하는 경우, Active Directory 통합 DNS에 관련된 컨테이너와 명명 컨텍스트에 대한 권한을 위임하지 않고 도메인의 BUILTIN\DNS Admins 그룹을 사용하면 됩니다. 또한 그룹 정책을 통해 사용자 권한 및 기타 사용 권한을 확장하여 특정 역할이 특정 클래스의 시스템을 관리하는 데 필요한 추가 권한을 제공할 수 있습니다.

위임을 통해 사용 권한을 할당할 때는 디렉터리 내의 ACE 거부 사용을 제한하거나 아예 사용하지 않아야 합니다. 이는 문제 해결 작업에서 복잡해질 수 있습니다. 더 바람직한 방법은 명시적인 ACE 허용을 사용하여 해당 역할을 나타내는 사용자 지정 그룹에 권한을 부여하는 것입니다. Tier4 Admins와 같은 사용자 지정 역할은 해당 역할이 지정한 명시적 권한만 갖습니다.

상속은 Active Directory 보안에 중요하며 특정 ACL이 특정 컨테이너나 하위 컨테이너의 하위 개체에 적용되는 방법을 정의합니다. 상속 가능한 ACE가 대상 개체에 최대한 가까이 적용되도록 하여 항상 상속 범위를 명확히 하십시오. 상위 개체에 적용된 상속 가능한 거부 권한이 최상위 개체에 적용된 상속 가능한 거부 권한보다 우선하며 이것이 바로 ACE 거부가 실용적인 위임을 위해 권장되지 않는 주된 이유 중 하나입니다. 또한 상속 가능한 사용 권한은 개체의 명시적 ACE를 무시할 수 없습니다. 따라서 DACL 쓰기 권한을 제거하여 계층별 관리자가 디렉터리 개체의 임의 액세스 제어 목록을 수정할 수 있는 기능을 제한 또는 제거하는 것이 좋습니다. 이러한 권한은 개체를 암시적으로 만든 사람에게 있습니다. 최우선 규칙은 가능한 경우 관리자가 개체의 DACL을 변경하는 것입니다. 선택 항목과 잠재적 관리 오류를 추가하여 조직이 애써 위임 모델에 투자한 노력을 쓸모없게 하지 마십시오.

Active Directory 위임 모델을 제대로 구현하는 데 사용해야 할 도구가 많습니다. 대부분의 대규모 조직에서 기본 제공 위임 마법사를 사용하여 디렉터리 내의 사용 권한을 할당하는 것은 관리 오류가 발생할 수 있는 매우 위험한 작업입니다. 대신 항상 자동화를 통해 위임 모델이 제대로 문서화되고 지원 가능하도록 해야 하며 설정이 실수로 손실 또는 변경될 경우에 대비하여 복구 옵션을 제공하도록 해야 합니다.

위임 구현에 필요한 기본 도구는 개체의 디렉터리 서비스 ACL을 조작하는 데 사용되는 명령줄 도구인 DSACLS.EXE입니다. 이 도구를 사용하면 상위 개체에서 DACL의 상속 플래그를 지정할 수도 있습니다. 상속 플래그는 이 개체와 하위 개체를 모두 포함하거나 하위 개체만 포함하며 하나의 수준에서만 상속 가능한 사용 권한을 전달합니다. 상속 플래그를 잘못 설정하면 최종적으로 DSACLS 명령이 실패하게 되므로 이 도구를 사용할 때는 반드시 테스트를 수행해야 합니다. 다음은 대상 데모 OU에 컴퓨터 개체 생성 기능을 위임하는 DSACLS 구문의 예입니다.

dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer

DSACLS는 개체 유형에 한하여 대소문자를 구분합니다. 즉, "cn=computer"에 "cn=Computer" 개체 클래스의 사용 권한을 위임하려고 하면 실패하게 됩니다(그림 3 참조).

그림 3 대소문자 구분으로 인한 오류 (Click the image for a smaller view)

일부 개체를 만들려면 특정 권한 집합이 필요합니다. 이 작업은 개체의 "필수" 특성과 "선택" 특성으로 수행해야 합니다. 이 개념을 설명하는 데 가장 좋은 비유를 들자면 바로 햄버거 모델입니다. 햄버거는 둥글게 다진 고기와 햄버거 빵이 있어야 햄버거로 간주됩니다. 이러한 품목은 햄버거 개체 클래스의 필수 특성입니다. 피클, 케첩, 겨자 등의 품목은 선택 특성입니다. 개체 클래스를 확장하여 치즈버거를 정의하는 경우에는 필수 특성 목록에 치즈를 추가해야 합니다.

사용자 개체도 이와 동일한 방식으로 작동합니다. 이 모델에 따라 다음 DSACLS 구문을 사용하여 사용자 개체를 만들어 볼까요?

dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user 

관리자는 사용자 개체를 만드는 동안 여러 가지 오류에 직면합니다. 암호 설정을 포함하여 사용자 개체에 필요한 특성을 설정하는 데 필요한 권한을 부여해야 하는데, 이는 다음과 같은 추가 DSACLS 구문에서 설명됩니다.

우선 사용자 클래스의 모든 특성에 대한 일반 읽기/일반 쓰기 권한을 부여하여 쓰기 필수 특성에 대한 사용 권한을 부여해야 합니다.

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user

그런 다음 암호를 변경하는 확장 권한을 부여합니다.

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user

그리고 마지막으로 암호 설정한 날짜의 읽기 속성 및 쓰기 속성에 사용 권한을 부여하면 됩니다.

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user

적절한 권한을 위임한 후에는 정의된 역할이 컨테이너의 DACL에 지정된 관리 개체 클래스로만 제한됩니다. 이전 컴퓨터 개체 예제를 사용하면 Active Directory 사용자 및 컴퓨터의 상황에 맞는 메뉴에 따라 해당 권한을 위임 받은 사용자가 만들 수 있는 새 개체 목록이 제한됩니다(그림 4의 제한된 목록 참조).

그림 4 새 개체의 제한된 목록

DSACLS를 자동화하여 복잡한 권한 위임을 제공할 수도 있습니다. 다음은 특정 컨테이너의 사용자 개체에 대해 일반 주소 특성 조작 권한을 위임하는 데 사용할 수 있는 DSACLS 명령입니다.

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user

이러한 예는 대부분의 위임 모델에 흔히 발생하며 이전에 정의된 역할과 함께 사용할 수 있습니다.

위임 구현에 사용되는 또 다른 도구인 DSREVOKE.EXE를 사용하면 관리자가 디렉터리 내에서 개체의 특정 보안 사용자에 대해 위임된 권한을 찾아서 제거할 수 있습니다. 이 도구는 매우 유용할 수도 있지만 특정 보안 사용자에게만 적용되고 보안 그룹 내에 중첩된 구성원은 평가하지 않습니다.

이러한 명령줄 도구 외에도 그룹 정책과 함께 사용자 권한 할당 및 제한된 그룹을 사용하는 것이 좋습니다. 앞서 설명한 대로 사용자 권한 할당을 사용하면 IT 관리자가 특정 대상 시스템에서 다양한 사용자 그룹의 하위 수준 권한(예: 원격으로 액세스하여 시스템을 다시 시작하는 권한)을 확장하거나 제거할 수 있습니다. 제한된 그룹을 사용하면 포리스트 내에서 로컬 및 도메인 그룹 구성원을 지정하고 적용할 수 있습니다. 이러한 도구를 함께 사용하면 Active Directory 위임 모델을 자동화하고 구현하는 데 필요한 모든 항목이 제공됩니다.

요약

Active Directory 위임 모델의 개발 작업은 일견 복잡해 보일 수 있지만 대부분의 IT 인프라에 적용할 수 있는 매우 단순한 모델이 존재합니다. 실용적인 위임 모델을 배포할 때 가장 중요한 단계 중 하나는 분명한 역할을 정의하는 것입니다. 정의된 역할은 소수의 신뢰할 수 있는 개인으로 제한해야 합니다. 역할이 너무 많으면 사용되지 않는 역할이 발생하고 너무 적으면 역할이 구분되지 않아 균형을 조정하기가 어렵습니다.

작업을 정의할 때는 빈도, 중요도 및 난이도별로 범주를 나누십시오. 역할을 정의한 후에는 각 역할로 할 수 있는 작업과 할 수 없는 작업을 파악하고 테스트 프로세스를 자동화하는 데 도움이 되는 사례 집합을 개발합니다. 사례를 제대로 준비하면 조직의 관련자들에게 해당 역할을 설명하고 자동화 오류로 인한 위험을 줄이는 데 도움이 됩니다.

마지막으로, 위임 모델을 개발할 때는 항상 실용적으로 접근하는 것이 좋습니다. 간단할수록 지원 가능성이 높아지고 장기적으로 유용한 위임 모델은 Active Directory 환경 내에서 관리 권한을 제어하는 데 매우 유용합니다.

추가 리소스

• Active Directory의 관리 권한 위임 시 디자인 고려 사항
• Best Practices for Delegating Active Directory Administration(영문)

---

Joel Yoker는 Microsoft Federal 팀의 수석 컨설턴트입니다. Joel과 Rob은 모두 미연방 정부 고객을 위한 보안 솔루션을 개발하여 배포하는 업무를 주로 담당하고 있습니다.

---

Rob Campbell은 Microsoft Federal 팀의 수석 기술 전문가입니다. Joel과 Rob은 모두 미연방 정부 고객을 위한 보안 솔루션을 개발하여 배포하는 업무를 주로 담당하고 있습니다.