Windows Server 2022 개인 프로젝트 002 - 도메인 및 서버 인프라 설계

1. 도메인 설계

본 프로젝트는 단일 도메인이 아닌, 하나의 Forest 내에 복수의 Domain을 구성하는 멀티 도메인 구조를 채택한다. 이는 글로벌 기업 시나리오를 반영하여, 본사와 해외 지사의 관리 경계를 명확히 분리하기 위함이다. 본사 도메인은 포리스트 루트 도메인으로서 중앙 정책과 핵심 서비스를 관리하고, 미국 지사와 일본 지사는 지역별 운영 환경과 관리 범위를 고려하여 각각 별도의 도메인으로 구성한다. 이를 통해 본사는 공통 기준과 핵심 서비스를 통합 관리하고, 각 지사는 독립적인 사용자 및 자원 관리를 수행할 수 있도록 한다.

앞서 정한 도메인 구성은 다음과 같다.

• hq.hybe.local : 본사 도메인
• usa.hq.hybe.local : 미국 지사 도메인
• jp.hq.hybe.local : 일본 지사 도메인

본사 도메인은 전체 인프라의 기준이 되는 핵심 도메인으로 운영하며, 주요 레이블과 공통 지원 부서를 포함한다. 미국 지사와 일본 지사 도메인은 각 지사의 조직 구조와 운영 환경을 반영하여 별도로 구성하고, 필요한 정책과 자원 관리를 독립적으로 수행할 수 있도록 한다.

1.1 Active Directory 논리 구조

본 프로젝트는 초기 설계 단계에서 hybe.local 포리스트 아래 hq.hybe.local, usa.hybe.local, jp.hybe.local을 병렬 Child Domain으로 두는 방안을 검토하였다. 다만 개인 실습 환경의 리소스 제약과 구축 복잡도를 고려하여, 실제 구현 단계에서는 hq.hybe.local을 포리스트 루트 도메인으로 설정하고, 미국 및 일본 지사는 각각 usa.hq.hybe.local, jp.hq.hybe.local Child Domain으로 구성하였다.

구조 개요

Forest Root Domain: hq.hybe.local
     ├ Child Domain: usa.hq.hybe.local
     └ Child Domain: jp.hq.hybe.local

해당 구조를 통해 하나의 통합된 디렉터리 체계를 유지하면서도, 포리스트 루트 도메인을 중심으로 한 중앙 관리와 지사 도메인 단위의 관리 분리를 동시에 달성할 수 있다.

1.2 Domain 간 신뢰 관계 (Trust)

동일 Forest 내에 생성된 Domain 간에는 Active Directory의 기본 동작에 따라 자동으로 신뢰 관계(Trust)가 형성된다.

본 프로젝트에서 구성되는 hq.hybe.local(포리스트 루트), usa.hq.hybe.local, jp.hq.hybe.local 간의 관계는 다음과 같은 특징을 가진다.

• 모든 Domain 간 양방향(2-Way) Trust가 형성된다.
• Trust는 전이적(Transitive) 특성을 가지며, Forest 전체에 걸쳐 신뢰가 확장된다.
• 별도의 수동 Trust 설정 없이도 도메인 간 인증 및 자원 접근이 가능하다.

이러한 구조를 통해 각 도메인이 독립적으로 운영되면서도, 필요 시 다른 도메인의 사용자와 리소스를 통합적으로 활용할 수 있는 기반을 제공한다.

1.3 멀티 도메인 구조 채택 이유

본 프로젝트에서는 단일 도메인 + OU 구조가 아닌, 멀티 도메인 구조를 선택하였다. 이는 다음과 같은 설계 목적을 반영한 것이다. 다만 포리스트 루트 도메인을 별도로 분리하지 않고 본사 도메인을 루트로 구성함으로써, 제한된 환경에서 관리 복잡도를 줄이고 효율적인 구축을 가능하게 하였다.

1) 지역별 보안 정책 분리

각 도메인은 독립적인 보안 정책(GPO)을 적용할 수 있으며, 국가별 또는 법인별 정책 요구사항을 분리하여 운영할 수 있다.

2) 계정 및 리소스 관리 분산

사용자 계정 및 서버 자원을 도메인 단위로 분리하여, 관리 권한을 지역 단위로 위임할 수 있다. 이는 대규모 조직에서의 운영 효율성을 높이는 구조이다.

3) 인증 및 로그온 부하 분산

도메인 컨트롤러는 각 도메인 내 사용자 인증을 담당하므로, 멀티 도메인 구조는 인증 부하를 분산시키는 효과를 가진다.

4) 향후 인프라 확장 고려

추후 Active Directory Site 구성 및 물리적 네트워크 분리와 연계하여, 지역별 인프라 확장이 가능하도록 설계하였다.

1.4 OU 구조와의 차이

OU(Organizational Unit)는 도메인 내부에서 객체를 논리적으로 구분하고 관리하기 위한 단위이다. 그러나 OU는 도메인 수준의 보안 경계나 완전한 정책 독립성을 제공하지는 않는다.

반면 Domain은 다음과 같은 특징을 가진다.

• 별도의 보안 경계(Security Boundary)
• 독립적인 계정 데이터베이스
• 도메인 단위 정책 및 인증 구조

따라서 본 프로젝트에서는 단순 조직 구분이 아닌, 법인 단위의 운영 분리를 가정하여 Domain 단위 분리를 채택하였다.

2. 서버 구성 계획

본 프로젝트의 서버 구성은 최소한의 서버 자원으로 멀티 도메인 환경을 구현할 수 있도록 설계한다. 각 도메인에는 도메인 컨트롤러를 1대씩 배치하여 사용자 인증과 정책 적용이 가능하도록 구성하고, 본사 서버에는 핵심 공용 서비스 역할을 함께 통합한다. 이를 통해 서버 수는 최소화하면서도 도메인 운영, 이름 해석, IP 할당, 파일 공유, 내부 웹 서비스 제공이 가능하도록 한다.

2.1 서버 역할 구성

2.2 서버 구성 방침

각 도메인에는 도메인 컨트롤러를 1대씩 배치하여 사용자 인증, OU 관리, 그룹 정책 적용이 가능하도록 구성한다. DNS 서비스는 각 도메인 컨트롤러와 함께 운영하여 도메인별 이름 해석이 가능하도록 한다. DHCP 서비스는 본사 서버에서 중앙 운영하는 방식으로 구성하여 클라이언트 IP 주소 관리를 일원화한다. 또한 파일 서버와 IIS 역할은 본사 서버에 함께 배치하여 공용 자료 공유와 내부 포털 제공 기능을 통합 운영하도록 한다.

2.3 최소 구성 선정 이유

본 프로젝트는 멀티 도메인 구조 자체로도 충분한 설계 복잡도를 가지므로, 초기 단계에서는 도메인별 핵심 기능이 정상 동작하는 최소 구성을 우선 적용한다. 이를 통해 불필요한 서버 분산을 줄이고, 도메인 구조, 인증 흐름, 정책 적용, 자원 관리와 같은 핵심 요소를 명확하게 구현하고 설명할 수 있도록 한다. 또한 향후 프로젝트 확장 시 파일 서버, 웹 서버, DHCP 서버를 별도 서버로 분리할 수 있도록 확장 가능성을 고려한 구조로 설계한다.

3. 향후 확장 계획

기본 구성은 3대 최소 서버 구조로 설계하였으나, 추후 운영 안정성과 역할 분리를 위해 서버 확장이 가능하도록 계획한다. 예를 들어 본사 환경에서는 파일 서버, 웹 서버, DHCP 서버를 별도로 분리하여 운영할 수 있으며, 필요에 따라 보조 도메인 컨트롤러를 추가하여 가용성을 높일 수 있다. 이와 같은 확장 구조는 기본 인프라가 안정적으로 구축된 이후 단계적으로 적용하는 것을 원칙으로 한다.

3.1 확장 가능 서버 예시

4. 향후 작성 예정 항목

• 명명 규칙
• IP 주소 계획
• 서비스 흐름도
• 그룹 및 계정 설계 세부안
• 운영 정책 및 보안 적용 기준