14-1. Active Directory 설계

14-1-1. 요구분석

안정적인 Active Directory 구축 및 운영을 위한 가장 중요한 단계는 요구분석 단계이다. 요구조건을 최대한 도출하고 분석을 통하여 올바른 설계의 방향을 결정하는 것은 아무리 강조해도 지나치지 않다. Active Directory 설계에 정답이 있는 것은 아니다. AD를 구축하고자 하는 회사의 요구사항이 있고 AD에서 수용할 범위가 결정되었다면 설계된 내용을 토대로 AD를 구축하였을 때 요건이 모두 해결될 수 있다면 최적의 설계를 한 것이라고 하겠다.

No	요구조건	분석 및 접근방향
1	사용자들이 도입되는 무선네트워크에 손쉽게 접근할 수 있도록 해 주어야 한다.	무선네트워크는 Active Directory인프라를 활용하여 별도의 디렉터리를 가지지 않고도 클라이언트들을 지원하도록 한다. 802.1x 무선인증을 지원하는 Wireless Access Point를 구매하여 사용자들이 도메인 로그온을 받을 수 있도록 함. IAS/RRAS서비스를 이용하여 무선AP의 802.1x인증 지원, 사용자PC에는 그룹정책을 활용하여 자동을 클라이언트 설정을 구성함
2	보안을 고려하여 내부/외부 DNS는 분리되어야 한다.	ISA Server 2004로부터 퍼블리싱되는 DNS서버는 그대로 유지하고 내부사용자들은 추가되는 도메인 컨트롤러의 DNS서비스를 이용하도록 함
3	전 직원은 파일서버에 자신만 접근할 수 있는 데이터를 저장하도록 한다.	파일서버에 사용자 개인별 홈폴더를 생성하고 홈폴더를 My document에 매핑시켜줌. Windows 98 사용자들은 계정별 홈폴더 매핑적용
4	부서별로 공용폴더를 구성하여 부서원간에 정보를 공유한다. 사용자들이 각 부서별 공유폴더에 쉽게 접근할 수 있도록 네트워크 드라이브 매핑을 설정해 준다.	그룹정책 사용하여 공용폴더를 매핑하는 스크립트 배포, Windows 98사용자들은 사용자별 로그온 스크립트 작성.
5	사용자들은 최소 8자리 이상의 암호를 사용해야 하며, 5번 틀린 암호로 로그온을 시도하면 계정이 잠기도록 설정되어야 한다.	강력한 암호정책 사용으로 사용자들의 도메인 계정 및 로컬PC의 계정에 대한 암호강화
6	하나의　서버가　문제가　되더라도　사용자들은　도메인　로그온에　지장이　없어야　한다．	2대의 도메인 컨트롤러 설치가 필요함
7	관리자들을 제외한 모든 사용자들은 보안을 위해서 Proxy Server를 통해서 인터넷에 접근한다.	그룹정책을 통해 인터넷 옵션 제어. Windows 98 사용자들의 통제어려움으로 Windows 2000, XP로 업그레이드 고려
8	도메인컨트롤러와 서버들을 제외한 회사의 모든 클라이언트 PC들에는 회사의 업무를 위해 표준소프트웨어인 마이크로소프트 오피스 2003이 설치되어야 하며, 부서별로 특화된 프로그램을 배포해야 할 필요가 있다.	그룹정책의 소프트웨어 배포정책 활용, Windows 9x 사용자들의 통제어려움으로 Windows 2000, XP로 업그레이드 고려. 부서별 특화된 프로그램 배포를 위해 OU별 별도의 그룹정책 구현, OU디자인에 반영되어야 함.
9	전체 조직에 걸쳐서 사용자 계정을 관리하는 것은 인사담당자가 직접 처리하도록 하여 신속하고 정확한 계정관리가 가능하도록 하고자 한다.	인사담당자에게 회사 조직에 대한 전체 사용자 계정 생성 작업 위임.
10	보안을 위해서 모든 사용자, 회사내의 모든 서버에 있어서 계정에 대한 감사정책을 구현해야 한다.	도메인 수준, 도메인 컨트롤러 수준의 감사정책 구현
11	시스템 관리자 계정은 회사의 전반적인 정책에 적용받지 않아야 한다.	그룹정책에 대한 관리자계정 필터링을 통해서 해결.
12	노트북을 이용하는 사용자들은 출장지 혹은 재택근무를 할때도 회사자원을 사용할 수 있도록 지원하고자 한다.	VPN서버를 도입함으로써 외부에서 접근시 클라이언트 인증 및 네트워크 보안 지원. ISA Server 2004의 VPN기능을 활성화하여 클라이언트 도메인 로그온 지원

 

14-1-2. 도메인 구조 결정

 

일단 도메인구조를 결정할 필요가 있다. 하나, 둘, 아니면 그 이상? 몇 개의 도메인으로 만들것인지를 고려해야 한다. Active Directory는 Windows NT 4.0 의 도메인 구조와는 분명히 달라질 수 있다. Windows NT 4.0의 도메인은 계층적인 관리구조를 지원하지 못하였다. 그런 이유로 지사, 본사, 부서별 관리 등을 회사가 원하는 대로 지원하기 위해서 복수도메인 구조가 불가피했던 경우가 생겼다. 하지만 Active Directory는 조직단위(OU)라는 관리구조가 도입됨에 따라 계층적인 관리가 가능하고 Windows NT 4.0 이라면 복수도메인(Multiple Domain)으로 구축되어야 할 경우라도, 대부분의 경우 Active Directory은 단일 도메인(Single Domain)으로써 지원할 수 있는 토대가 마련되었다.

 

마이크로소프트는 도메인 모델을 결정할 때 일단 ‘단일 도메인 모델’을 검토하고, 회사의 요구사항이 단일 도메인 모델로써 해결될 수 없는 상황일 경우에만 복수 도메인 모델을 도입할 것을 권장하고 있다. 현재 우리가 다루어보고자 하는 시나리오 환경자체는 컴퓨터 100여대 정도의 중소규모 환경이지만 이것보다 훨씬 더 큰 규모의 회사 환경이라도 ‘반드시’ 복수도메인으로 가야 할 이유는 많지 않다고 판단된다.

 

복수도메인이 필요한 경우는 조직간에 보안상의 이유로 계정/암호정책 등이 차별적인 설정을 가져야 하는 경우, 회사의 조직간에 IT관리에 대한 책임과 역할이 명확하게 구분되어야 하는 경우 등이 일반적인 이유이다. 이 회사의 시나리오에서는 어떠한 요구조건에서도 단일도메인을 벗어나야 하는 이유가 없다. ‘단일 도메인’을 구축하기로 결정하였다.

 

14-1-3. 도메인 이름 결정

 

도메인의 이름은 회사를 대표할 수 있는 이름을 선택하는 것이 좋다. 이 회사는 이미 windowsnetwork.msft 라는 도메인을 가지고 있다. 이 이름을 그대로 Active Directory 도메인이름으로 사용하기로 한다. 만일 회사가 인터넷에 등록한 도메인 이름이 없는 상태라면 먼저 회사를 대표할 수 있는 이름 하나를 등록할 것을 권장한다. 당장 인터넷에 연결 자체는 할 필요가 없더라도 도메인 이름을 확보해 두는 것이 안정적인 도메인 구축을 할 수 있는 방법이다.

 

이 이름은 두 가지 용도로 사용된다. 하나는 인터넷상의 다수의 클라이언트들이 회사의 웹서버, 메일서버등의 자원에 접근하기 위한 용도이고, 둘째는 회사 내부의 클라이언트가 도메인을 식별하고 디렉터리 서비스를 받기 위한 용도이다. 이들은 사용용도가 다르지만 동일한 이름체계를 사용하고 있기에 하나의 DNS서버를 통해서 얼마든지 서비스될 수 있지만, 보안을 고려한 좋은 모델은 이 두가지 용도별로 DNS서버를 분리시키는 방법이다. 내부 DNS서버와 외부DNS서버로 구분하는 것을 의미한다.

 

이러한 네트워크의 물리적인 환경에 대해서는 8장의 ‘안전을 고려한 네트워크 환경 구축’을 참고하라.

 

14-1-4. 관리구조 결정 (OU)

 

Active Directory구조에서 OU는 큰 의미를 가진다. 관리권한의 위임, 그룹정책의 적용의 최소 단위가 OU이기 때문에 IT관리 요구사항을 그대로 반영하여 OU구조를 만들어 낼 필요가 있다. OU의 가장 큰 용도는 그룹정책구성을 위한 최소단위, 관리권한 위임의 최소단위로 사용되어 IT관리자가 개체들을 보다 쉽고 유연하게 관리하도록 한다.

 

그렇지만 OU구조가 조직구조와 같을 필요는 없다. OU라는 단위는 사용자들에게는 투명하다. 사용자들은 자신이 어떤 OU에 속해 있는지 몰라도 되고, 알 필요도 없다는 것이다. 시나리오의 요건중에서 OU의 설계와 연관성이 있는 요건은 3,4,7,8,9 정도가 되겠다. 이중에서도 요건8의 내용을 보면 “부서별로 특화된 프로그램을 배포해야 할 필요가 있다”는 문구가 있다. 이것은 부서별로 구분되는 프로그램을 정책에서 배포해야 할 필요성을 이야기하는 바, 이러한 정책을 지원하기 위한 OU구조를 고민해 봐야 한다.

 

방법은 2가지가 있다. 첫번째 방법은 부서별로 OU를 구분하여 조직도 형태의 OU를 만드는 것이고, 두번째 방법은 하나의 OU에 개체를 모두 담고 필터링을 통해서 그룹별로 지정된 프로그램을 배포하는 방법이다.

 

<그림14-4. 조직도를 반영한 계층적 OU 구조 디자인>

 

먼저 <그림14-4>의 예제를 보자. 예제의 OU구조는 조직도를 그대로 OU구조에 반영한 것이다. 실제 회사환경은 이보다 훨씬 복잡한 조직구조라는 것을 감안해야 한다. 위와 같이 OU의 계층적인 디자인을 통해서 ‘상속성’이 있다는 특징을 그대로 활용할 수 있다. 권한위임이나 그룹정책은 상위OU에서 설정된 내용은 기본적으로 하위OU로 상속성이 있으므로 IT관리구조를 그대로 반영할 수 있다. 최상위OU는 가능한한 회사의 조직개편 등에 재편성을 하는 일이 적도록 신경써야 할 부분이다. OU구조가 틀려지면 관리구조 역시 전체적으로 재정비를 해야 할 것이기 때문이다. 꼭 필요가 없더라도 위와 같은 경우 ‘최상위 OU’를 하나 배치하는 것은 좋은 설정이다. OU에 소속된 모든 사용자들에게 일괄적인 정책이나 권한설정을 하고자 한다면 최상위OU에서의 정책만으로 통제가 가능하기 때문이다.

 

다음의 <그림14-5>OU구조도 살펴보자.

<그림14-5. 기능적 측면을 고려한 계층적 OU 구조 디자인>

 

이 구조는 조직도를 배제하고 기능적인 측면에 중점을 둔 OU구조이다. 이렇게 구성을 하는 것도 현재 윈도우네트웍스사의 요구조건을 모두 만족시킬 수 있을 뿐만 아니라 조직개편 등에 따른  OU간의 이동에 대한 관리부담도 해소할 수 있어 좋은 구조라고 생각한다. 먼저 언급했듯이 설계에는 정답이 있는 것은 아니다. “OU구조가 꼭 조직도 형태로 되어야 한다는 편견은 버려!”(개그맨 정준하님 버전)라고 말해주고 싶다.

 

각각 장단점을 정리해 보면 다음과 같다.

구분	장점	단점
부서별로 OU 생성	l 부서별 다른 설정의 그룹정책을 구성하기가 편하다. l 조직도 형태로 구성되어 있어서 관리자가 보기에 편하다.	l 사용자의 부서이동에 따라 사용자개체와 컴퓨터개체를 사용자의 이동부서에 따라 OU간 이동을 시켜 줘야 한다. 디렉터리의 일관성이 깨져서 신뢰성이 손상될 우려가 있다.
기능중심의 OU 생성	l 조직개편 등에 따라서 OU의 이동등의 조치가 필요 없어 관리에 따른 부담이 줄어든다.	l 그룹정책 구성시 보다 세심한 설정이 필요하다.

 

14-1-5. 명명규칙

Active Directory 인프라와 관련된 서버/PC/로그온 이름 등 다양한 개체에 대한 명명규칙을 정의한다.

구분	고려사항	비고
서버명	l 도입된 서비스 유형 등이 파악될 수 있는 이름을 고려하는 것이 좋음	l 운영서버/개발서버 l 도입된 시스템 분류
클라이언트 PC명	l 효율적인 관리를 위해 단말명은 변경되지 않는 고유값을 설정하는 것이 좋음	l 공유자원에 접근이 용이하도록 단말의 ‘설명’항목에 부서명/사용자 이름 등을 표기함으로써 접근이 용이하도록 구성
사용자계정	l 기존 어플리케이션에서 사용하던 로그온 ID와의 편의성 측면을 고려해야 함 l 로그온ID가 보안이 유지되어야 할 대상인지 판단	l 암호정책 고려 l  암호 길이 l  최소암호사용기간 l  최대암호사용기간 l  암호 잘못 입력시 동작 등
그룹계정	l 조직,직무,직군,직급 등의 다양한 그룹이 통합디렉토리에서는 하나의 ‘그룹’카테고리로 분류됨 l 사용자가 통합디렉토리에서 검색이 용이하도록 이름 선택

 

14-1-6. 디렉터리 구성 테이블 작성

구현을 위해서 필요한 디렉터리의 내용들을 테이블로 정리해 보았다. 필자는 위의 OU구조중 두번째인 <그림14-5>의 구조를 선택했다.ㅣ

단위	그룹, 사용자,컴퓨터	권한위임	그룹정책(GPO)	옵션
도메인			암호정책(8자리) 계정잠금정책(5번) 감사정책 구현	무시안함 무시안함 무시안함
Domain Controllers	도메인 컨트롤러 배치
Computers	파일, 프린트, DNS 서버
윈도우네트웍스OU		인사담당자에게 사용자계정 생성권한위임	전사적인 업무프로그램배포정책 인터넷옵션 설정
IT관리OU	관리자 계정	없음(상속)		정책상속거부
임직원OU		없음(상속)	My Documents폴더 지정 공유폴더 매핑 로그온스크립트
인사외OU	인사시스템에 등재되지 않은 외부사용자	없음(상속)	없음(상속)
임직원/사용자OU	회사의 모든 임직원	없음(상속)	없음(상속)
임직원/컴퓨터OU	회사의 모든 PC	없음(상속)	없음(상속)