내보내기(0) 인쇄
모두 확장

Windows Server 2003 보안 가이드

2장: Windows Server 2003 보안 강화 메커니즘

업데이트 날짜: 2005년 12월 27일
이 페이지에서

개요
보안 구성 마법사를 사용하여 보안 강화
Active Directory 그룹 정책을 사용하여 서버 보안 강화
프로세스 개요
요약

개요

이 장에서는 Microsoft® Windows Server™ 2003에서 보안 설정을 구현하는 데 사용할 수 있는 메커니즘을 소개합니다. Windows Server 2003 SP1(서비스 팩 1)은 서버를 보다 안전하게 구성하는 데 사용할 수 있는 새로운 역할 기반 도구인 SCW(보안 구성 마법사)를 제공합니다. 보안 강화 프로세스에서 SCW를 GPO(그룹 정책 개체)와 함께 사용하면 강력한 제어 능력, 유연성 및 일관성을 얻을 수 있습니다.

이 장에서는 다음 항목을 중점적으로 다룹니다.

  • SCW를 사용하여 역할 기반 보안 강화 정책을 만들고 테스트하고 배포하는 방법.

  • Active Directory® 디렉터리 서비스와 GPO를 함께 사용하여 엔터프라이즈 보안을 일관되게 강화하는 방법

  • Active Directory 도메인 디자인, OU(조직 구성 단위) 디자인, 그룹 정책 디자인 및 관리 그룹 디자인이 보안 배포에 미치는 영향

  • SCW와 그룹 정책을 모두 사용하여 Windows Server 2003 SP1 실행 서버의 보안 강화를 위한 관리 효율이 뛰어난 역할 기반 방식을 구축하는 방법

이 정보는 도메인 인프라 내에서 LC(레거시 클라이언트) 환경에서 SSLF(특수 보안 - 기능 제한) 환경으로 전환하는 데 필요한 기반 및 개념을 제공합니다.

보안 구성 마법사를 사용하여 보안 강화

SCW의 목적은 Windows Server 2003 SP1 실행 서버의 보안 노출 가능성을 줄일 수 있는 유연한 단계별 프로세스를 제공하는 것입니다. SCW는 실제로 XML 규칙 데이터베이스와 통합되는 도구 모음입니다. 이 도구는 관리자가 특정 서버에서 수행해야 하는 역할에 필요한 최소 기능을 빠르고 정확하게 파악하는 데 도움을 주기 위해 작성되었습니다.

SCW를 사용하여 관리자는 필수적이지 않은 모든 기능을 비활성화하는 보안 정책을 작성, 테스트, 문제 해결 및 배포할 수 있습니다. 또한 보안 정책을 롤백할 수도 있습니다. SCW는 기본적으로 단일 서버와 관련 기능을 공유하는 서버 그룹의 보안 정책 관리를 지원합니다.

SCW는 다음 작업을 수행하는 데 도움이 되는 포괄적인 도구입니다.

  • 활성 상태여야 하는 서비스, 필요할 때 실행되어야 하는 서비스 및 비활성화할 수 있는 서비스를 확인합니다.

  • Windows 방화벽과 연계하여 네트워크 포트 필터링을 관리합니다.

  • 웹 서비스에 허용되는 IIS 웹 확장을 제어합니다.

  • SMB(서버 메시지 블록) 기반 프로토콜, NetBIOS, CIFS(Common Internet File System) 및 LDAP(Lightweight Directory Access Protocol) 등의 프로토콜을 사용하지 않아도 됩니다.

  • 필요한 이벤트를 캡처하는 유용한 감사 정책을 만듭니다.

SCW를 설치 및 사용하고 관련 문제를 해결하는 방법에 대한 자세한 내용은 보안 구성 마법사 (영문) 설명서(www.microsoft.com/downloads/details.aspx?FamilyID=903fd496-9eb9-4a45-aa00-3f2f20fd6171&displaylang=en)의 다운로드 가능 버전에 나와 있습니다.

참고: SCW는 Windows Server 2003 SP1에서만 사용할 수 있으며 Windows 2000 Server, Windows XP 또는 Windows Small Business Server 2003의 정책을 만드는 데는 사용할 수 없습니다. 이러한 운영 체제가 실행되는 많은 수의 컴퓨터에 대해 보안을 강화하려면 이 장 뒷부분에 설명되어 있는 그룹 정책 기반 보안 강화 메커니즘을 사용해야 합니다.

정책 만들기 및 테스트

SCW를 사용하여 단일 컴퓨터에서 여러 서버 또는 서버 그룹의 보안 정책을 빠르게 만들고 테스트할 수 있습니다. 이를 통해 한 위치에서 기업 전체의 정책을 관리할 수 있습니다. 이러한 정책은 각 서버가 조직 내에서 제공하는 기능에 적절한 일관된 보안 강화 방법을 제공합니다. SCW를 사용하여 정책을 만들고 테스트할 경우 모든 대상 서버에 SCW를 배포해야 합니다. 정책이 관리 스테이션에서 생성된 경우에도 SCW는 대상 서버와 정보를 주고 받으면서 해당 구성을 검토하고 결과 정책을 보다 구체적으로 조정하려고 합니다.

SCW는 IPsec 및 Windows 방화벽 하위 시스템과 통합되며 그에 따라 해당 설정을 수정합니다. 명시적으로 금지되지 않은 한, SCW는 운영 체제 및 수신 응용 프로그램이 요구하는 중요한 포트로의 인바운드 네트워크 트래픽을 허용하도록 Windows 방화벽을 구성합니다. 추가 포트 필터가 필요한 경우 SCW에서 만들 수 있습니다. 그 결과 SCW를 통해 정책을 생성할 경우 원치 않는 트래픽을 차단하도록 IPsec 필터를 설정 또는 수정하기 위해 사용자 지정 스크립트를 사용하지 않아도 됩니다. 이 기능은 네트워크 보안 강화 절차를 보다 간편하게 관리할 수 있도록 해 줍니다. RPC 또는 동적 포트를 사용하는 서비스에 대한 네트워크 필터도 간편하게 구성할 수 있습니다.

또한 SCW는 사용자가 만든 정책을 사용자 지정할 수 있는 기능을 제공합니다. 이러한 융통성은 필요한 기능을 허용하면서 보안 위험을 줄이는 구성을 만드는 데 도움을 줍니다. 기준 동작 및 설정 외에도 다음과 관련해서 SCW를 재지정할 수 있습니다.

  • 서비스

  • 네트워크 포트

  • Windows 방화벽 승인 응용 프로그램

  • 레지스트리 설정

  • IIS 설정

  • 기존의 보안 템플릿(.inf 파일) 포함 여부

SCW는 가장 중요한 일부 레지스트리 설정에 대해 권장 사항을 제시합니다. 이 도구의 복잡성을 줄이기 위해 디자이너는 보안에 가장 많은 영향을 미치는 설정만 포함시키도록 선택합니다. 그러나 이 가이드에서는 더 많은 레지스트리 설정에 대해 설명합니다. SCW의 제한점을 극복하기 위해 보안 템플릿과 SCW의 결과를 통합하여 좀 더 완전한 구성을 만들 수 있습니다.

SCW를 사용하여 새 정책을 만들 경우 서버의 현재 구성이 초기 구성으로 사용됩니다. 따라서 서버 역할의 구성을 정확히 기술할 수 있도록 해당 정책을 배포하려는 서버와 유형이 같은 서버를 대상으로 지정해야 합니다. SCW GUI(그래픽 사용자 인터페이스)를 사용하여 새 정책을 만들 경우 XML 파일이 생성된 후 기본적으로 %systemdir%\security\msscw\Policies 폴더에 저장됩니다. 정책을 만든 후에는 SCW GUI 또는 Scwcmd 명령줄 도구를 사용하여 테스트 서버에 정책을 적용할 수 있습니다.

정책을 테스트할 때는 배포한 정책을 제거해야 할 수도 있습니다. GUI 또는 명령줄 도구를 사용하여 마지막에 서버 또는 서버 그룹에 적용한 정책을 롤백할 수 있습니다. SCW는 이전 구성 설정을 XML 파일에 저장합니다.

제한된 리소스로 보안 구성을 디자인 및 테스트해야 하는 조직에서는 SCW가 적절할 수 있습니다. 이러한 리소스가 부족한 조직에서는 서버 보안을 강화하려는 시도 조차도 해서는 안 됩니다. 이렇게 할 경우 예상치 못한 문제가 발생하고 생산성이 저하될 수 있습니다. 조직에 이러한 종류의 문제를 해결할 만한 전문가나 시간이 부족한 경우 응용 프로그램 및 운영 체제를 최신 버전으로 업그레이드하고 업데이트를 관리하는 등의 중요한 보안 활동에 주력해야 합니다.

정책 배포

정책을 배포할 때는 다음의 세 가지 옵션을 사용할 수 있습니다.

  • SCW GUI를 사용하여 정책 적용

  • Scwcmd 명령줄 도구를 사용하여 정책 적용

  • SCW 정책을 그룹 정책 개체로 변환한 후 도메인이나 OU에 연결

각 옵션은 각기 장단점이 있으며 다음 하위 섹션에 관련 내용이 설명되어 있습니다.

SCW GUI를 사용하여 정책 적용

SCW GUI 옵션을 사용할 때 얻을 수 있는 주요 이점은 간편성입니다. 이 GUI를 사용하여 관리자는 미리 정의된 정책을 쉽게 선택한 후 단일 컴퓨터에 적용할 수 있습니다.

SCW GUI 옵션의 단점은 한 번에 하나의 컴퓨터에만 정책을 적용할 수 있다는 것입니다. 이 옵션은 대규모 환경에 맞게 확장될 수 없으며 이 가이드에서는 이 방법이 사용되지 않습니다.

Scwcmd 명령줄 도구를 사용하여 정책 적용

네이티브 SCW 정책을 Active Directory가 없는 여러 컴퓨터에 적용하는 한 가지 방법은 Scwcmd 도구를 사용하는 것입니다. Scwcmd를 스크립트 기술과 함께 사용하면 서버의 구축 및 배포에 사용되는 기존 프로세스의 일부로 자동화된 정책 배포 과정을 포함시킬 수 있습니다.

Scwcmd 옵션을 사용할 때 얻을 수 있는 주요 이점은 작업이 자동으로 진행되지 않는다는 것입니다. 이 옵션을 사용할 경우 수동으로 또는 일부 스크립트 솔루션을 사용하여 정책 및 대상 서버를 지정해야 하므로 잘못된 컴퓨터에 잘못된 정책을 적용할 가능성이 높습니다. 그룹 안에 구성이 약간씩 다른 서버가 여러 대 있을 경우 각 컴퓨터에 대해 별도의 정책을 만든 후 개별적으로 적용해야 합니다. 이러한 제한 때문에 이 가이드에서는 이 방법이 사용되지 않습니다.

SCW 정책을 그룹 정책 개체로 변환

SCW 정책 배포의 세 번째 옵션은 Scwcmd 도구를 사용하여 XML 기반 정책을 GPO(그룹 정책 개체)로 변환하는 것입니다. 처음에는 이러한 변환이 불필요해 보일 수 있지만 이러한 변환 작업을 통해 다음과 같은 이점을 얻을 수 있습니다.

  • 익숙한 Active Directory 기반 메커니즘을 통해 정책이 복제, 배포 및 적용됩니다.

  • 이 정책은 네이티브 GPO이므로 OU, 정책 상속 및 점진적 정책 적용 기능을 사용하여 다른 서버와 정확히 동일하지는 않지만 비슷하게 구성된 여러 서버의 보안 강화 과정을 보다 구체적으로 조정할 수 있습니다. 그룹 정책을 사용하면 이러한 서버를 자식 OU에 넣은 후 정책을 점진적으로 적용할 수 있지만 SCW를 사용하면 고유한 구성마다 새 정책을 만들어야 합니다.

  • 정책은 해당 OU에 있는 모든 서버에 자동으로 적용됩니다. 네이티브 SCW 정책은 수동으로 적용하거나 사용자 지정 스크립트 솔루션과 함께 사용해야 합니다.

Active Directory 그룹 정책을 사용하여 서버 보안 강화

Active Directory를 사용하면 응용 프로그램이 분산된 컴퓨팅 환경에서 디렉터리 리소스를 찾고 사용하며 관리할 수 있습니다. 가이드 전체에서 Active Directory 인프라를 디자인하는 방법을 자세히 다루고 있지만 이 섹션에서는 가이드의 나머지 부분을 이해하는 데 도움을 주기 위해 각 개념을 간단히 설명합니다. 이 디자인 정보는 그룹 정책을 사용하여 조직의 도메인, 도메인 컨트롤러 및 특정 서버 역할을 안전하게 관리하는 방법을 이해하는 데 필요합니다. 사용자 조직에서 Active Directory 디자인을 이미 구현한 경우에는 이 장을 통해 보안상의 이점 또는 잠재적인 문제에 대해 폭넓은 정보를 얻을 수 있습니다.

이 가이드에서는 Active Directory 데이터베이스 보안 유지 방법에 대한 특정 지침을 제공하지 않습니다. 이러한 지침은 이 장 끝에 나오는 "추가 정보" 섹션에 설명된 "Active Directory 설치의 보안을 유지하기 위한 최상의 방법 (영문)" 문서를 참조하십시오.

Active Directory 인프라를 만들 때는 작업 환경의 보안 범위를 주의해서 고려해야 합니다. 조직의 보안 위임 및 구현 일정을 적절히 세우면 훨씬 안전한 Active Directory 디자인을 구현할 수 있게 됩니다. 인수 또는 개편과 같이 환경을 크게 변경해야 하는 경우에만 디자인을 변경하면 됩니다.

Active Directory 범위

Active Directory 내에는 포리스트, 도메인, 사이트 토폴로지 및 사용 권한 위임과 같은 몇 가지 유형의 범위가 있으며 이러한 범위는 Active Directory를 설치할 때 자동으로 설정됩니다. 그러나 사용 권한 범위 안에 조직의 요구 사항과 정책을 통합해야 합니다. 관리 권한 위임은 여러 다른 조직의 요구에 맞게 유연하게 적용할 수 있습니다. 예를 들어 보안과 관리 기능 사이에서 적절한 균형을 유지하기 위해 보안 범위와 관리 범위 사이에서 사용 권한 위임 범위를 세분화할 수 있습니다.

보안 범위

보안 범위는 한 조직 내에 있는 여러 그룹의 자율성 또는 독립성을 정의하는 데 사용할 수 있습니다. 조직의 비즈니스 범위가 설정된 방식에 따라 적절한 보안을 실현하는 것과 기본적인 기능을 안정적으로 제공하는 것 사이에서 적절한 균형을 유지한다는 것은 매우 어렵습니다. 이러한 두 요소 사이에서 적절한 균형을 이루려면 관리 권한 위임 및 사용자 환경의 네트워크 아키텍처와 관련된 제반 사항을 결정하기 전에 이로 인해 발생할 수 있는 보안 문제를 면밀하게 검토하여 조직이 직면하게 될 위협을 평가해야 합니다.

포리스트는 네트워크 환경의 실제 보안 범위입니다. 이 가이드에서는 독립된 포리스트를 만들어 다른 도메인의 관리자로부터 사용자 환경을 격리시켜 안전하게 보호할 것을 권장합니다. 이를 통해 한 포리스트의 보안 손상으로 인해 전체 도메인의 보안이 자동으로 손상되지 않도록 할 수 있습니다.

도메인은 보안 범위가 아닌 Active Directory의 관리 범위입니다. 선의의 개인들로 구성된 조직의 경우 도메인 범위를 사용하여 조직의 각 도메인 내에 있는 서비스와 데이터가 자율적으로 관리되도록 할 수 있습니다. 그러나 보안을 고려해야 할 경우 격리 환경을 구현하기란 그리 간단하지 않습니다. 예를 들어 도메인이 악의적인 도메인 관리자로부터의 공격을 완벽하게 차단하지 못할 수도 있습니다. 이러한 수준의 격리는 포리스트 수준에서만 실현할 수 있습니다.

도메인 내에서 OU(조직 구성 단위)는 또 다른 수준의 관리 범위를 제공합니다. OU를 사용하면 효율적으로 관련 리소스를 그룹화하고 직원에게 관리 액세스 권한을 위임할 수 있으므로 해당 직원에게 전체 도메인에 대한 관리 능력을 부여하지 않아도 됩니다. 도메인과 마찬가지로 OU는 실제 보안 범위가 아닙니다. 특정 OU에 사용 권한을 할당할 수 있지만 같은 도메인의 모든 OU는 도메인 및 포리스트 리소스에 대해 리소스를 인증합니다. OU 계층 구조를 잘 디자인하면 효과적인 보안 방법을 개발하고 배포하고 관리하는 데 도움이 됩니다.

조직에서는 현재의 Active Directory 디자인 내에 있는 서비스 및 데이터에 대한 관리 제어를 세분화하는 것을 고려해야 할 수도 있습니다. Active Directory를 효과적으로 디자인하려면 서비스 자율성과 격리 및 데이터 자율성과 격리에 대한 조직의 요구를 완전히 파악해야 합니다.

관리 범위

서비스와 데이터를 분리해야 하므로 각각의 필요에 따라 관리 수준도 서로 다르게 정의해야 합니다. 이 가이드에서는 조직의 고유한 서비스를 수행하는 관리자 외에도 다음 유형의 관리자를 고려하는 것이 좋습니다.

서비스 관리자

Active Directory 서비스 관리자는 디렉터리 서비스를 구성하고 배포하는 업무를 담당합니다. 예를 들어 서비스 관리자는 도메인 컨트롤러 서버를 유지 관리하고, 디렉터리 전체의 구성 설정을 제어하고, 서비스 가용성을 보장합니다. 조직의 Active Directory 관리자를 서비스 관리자로 간주해야 합니다.

Active Directory 서비스 구성은 주로 특성 값에 의해 결정됩니다. 이러한 특성 값은 디렉터리에 저장된 각 개체의 설정에 해당합니다. 따라서 Active Directory의 서비스 관리자는 데이터 관리자도 됩니다. 조직에서 Active Directory 서비스 디자인에 맞게 다른 서비스 관리자 그룹을 고려해야 하는 경우도 있습니다. 일부 예는 다음과 같습니다.

  • 디렉터리 서비스를 전담하는 도메인 관리 그룹

    포리스트 관리자는 각 도메인을 관리할 그룹을 선택합니다. 각 도메인의 관리자에게는 높은 수준의 액세스가 부여되므로 확실히 신뢰할 수 있는 사람을 선택해야 합니다. 도메인 관리자는 Domain Administrators 그룹 및 기타 기본 제공 그룹을 통해 도메인을 제어합니다.

  • DNS를 관리하는 관리자 그룹

    DNS 관리자 그룹은 DNS 디자인을 완료하고 DNS 인프라를 관리합니다. DNS 관리자는 DNS Adminstrators 그룹을 통해 DNS 인프라를 관리합니다.

  • OU를 관리하는 관리자 그룹

    OU 관리자는 그룹이나 개인을 각 OU의 관리자로 지정합니다. 각 OU 관리자는 할당된 Active Directory OU에 저장되어 있는 데이터를 관리합니다. 이 그룹은 관리가 위임되는 방법과 해당 OU 내의 개체에 정책이 적용되는 방법을 제어할 수 있습니다. 뿐만 아니라 OU 관리자는 하위 트리를 새로 만들어 자신이 담당하는 OU에 대한 관리 권한을 위임할 수도 있습니다.

  • 인프라 서버를 관리하는 관리자 그룹

    인프라 서버 관리를 담당하는 그룹은 WINS, DHCP 및 DNS 인프라를 관리할 수 있습니다. 도메인 관리를 담당하는 그룹이 DNS 인프라를 관리하는 경우도 있는데, 이는 Active Directory가 DNS와 통합되어 도메인 컨트롤러에서 저장 및 관리되기 때문입니다.

데이터 관리자

Active Directory 데이터 관리자는 Active Directory 또는 Active Directory에 가입된 컴퓨터에 저장되어 있는 데이터를 관리합니다. 이 관리자는 디렉터리 서비스의 구성이나 배포에 대해서는 관여하지 않습니다. 데이터 관리자는 사용자 조직에서 직접 만든 보안 그룹의 구성원입니다. Windows의 기본 보안 그룹이 사용자 조직의 일부 상황에는 적합하지 않을 수도 있습니다. 따라서 조직은 해당 환경에 가장 적절한 고유의 보안 그룹 명명 표준과 의미를 만들 수 있습니다. 데이터 관리자의 일상적인 업무는 다음과 같습니다.

  • 디렉터리에 있는 개체 하위 집합 제어. 데이터 관리자에게는 상속 가능한 특성 수준의 액세스 제어를 통해 디렉터리의 매우 한정적인 부분에 대한 제어 권한은 부여되지만 서비스 자체에 대한 구성 권한은 부여되지 않습니다.

  • 디렉터리에 있는 구성원 컴퓨터 및 이 컴퓨터에 있는 데이터 관리

참고: 대개의 경우 디렉터리에 저장된 개체의 특성 값이 디렉터리의 서비스 구성을 결정합니다.

지금까지의 내용을 요약해 볼 때 Active Directory 서비스와 디렉터리 구조의 소유자가 포리스트나 도메인 인프라에 참가할 수 있으려면 해당 조직에서 포리스트와 모든 도메인에 있는 서비스 관리자를 모두 신뢰할 수 있어야 합니다. 또한 엔터프라이즈 보안 프로그램은 관리자에게 적절한 백그라운드 검사 기능을 제공하는 표준 정책 및 절차를 개발해야 합니다. 이 보안 가이드에서 말하는 서비스 관리자에 대한 신뢰란 다음을 의미합니다.

  • 서비스 관리자가 항상 조직의 이익을 최우선적으로 고려합니다. 포리스트나 도메인 소유자가 조직의 이익에 반하여 악의적으로 행동할 수 있는 사유가 있을 경우 조직은 포리스트나 도메인에 참가하지 않아야 합니다.

  • 서비스 관리자가 조직에서 규정한 최상의 방법을 따르고 도메인 컨트롤러에 대한 물리적 액세스를 제한할 것이라는 점을 확신할 수 있어야 합니다.

  • 다음 요인을 포함하는 조직의 경우 이로 인한 위험을 제대로 인식하고 받아들여야 합니다.

    • 악의적 관리자. 신뢰할 수 있는 관리자가 악의적 관리자가 될 수 있으며 네트워크에 대한 권한을 악용할 수 있습니다. 포리스트 내의 악의적 관리자는 다른 도메인에서 다른 관리자에 대한 SID(보안 식별자)를 쉽게 조회할 수 있습니다. 그런 후 API(응용 프로그래밍 인터페이스) 도구, 디스크 편집기 또는 디버거를 사용하여 이 SID를 자신의 도메인에 있는 계정의 SID 기록 목록에 추가할 수 있습니다. 악의적 관리자는 훔친 SID를 사용자의 SID 기록에 추가하여 자신의 도메인과 함께 훔친 SID의 도메인에 대한 관리 권한도 가지게 됩니다.

    • 강요 받은 관리자. 신뢰할 수 있는 관리자가 컴퓨터 또는 네트워크의 보안을 손상시키는 작업을 수행하도록 강요를 받을 수 있습니다. 사용자나 관리자는 사회 공학 기법을 사용하거나 컴퓨터의 적법한 관리자에게 물리적 또는 기타 해로운 위협을 가하여 컴퓨터 액세스 권한을 얻는 데 필요한 정보를 얻을 수 있습니다.

일부 조직은 조직의 다른 부서로부터 강요를 받은 악의적 관리자나 서비스 관리자에 의한 보안 침해 위험을 받아들일 수도 있습니다. 이러한 조직은 공유 인프라에 참가하여 얻을 수 있는 공동 작업과 비용 절감이라는 혜택이 이러한 보안 위험을 감수할 만한 가치가 있다고 생각합니다. 그러나 다른 조직은 이러한 보안 위험이 가져올 수 있는 결과가 너무 심각하므로 이를 수용하지 않을 수도 있습니다.

Active Directory 및 그룹 정책

OU를 사용하면 컴퓨터, 사용자, 그룹 및 기타 보안 사용자를 쉽게 그룹화할 수 있을 뿐만 아니라 관리 범위를 효과적으로 구분할 수 있습니다. 또한 OU는 보안 요구에 따라 리소스를 분류하고 OU마다 다른 보안을 제공할 수 있도록 하므로 GPO(그룹 정책 개체)의 배포를 위한 중요한 구조를 제공합니다. OU를 사용하여 서버 역할에 따라 보안 정책을 관리하고 할당하는 일은 조직의 전체적인 보안 아키텍처의 일부입니다.

관리 위임 및 그룹 정책 적용

OU는 도메인의 디렉터리 구조 내에 있는 컨테이너입니다. 이러한 컨테이너는 주로 특정 유형의 개체를 보유하는 데 사용되지만 도메인의 어떠한 보안 주체도 포함할 수 있습니다. 그룹이나 개별 사용자에 대해 OU 액세스 권한을 부여하거나 취소하려는 경우 OU에 대해 특정 ACL(액세스 제어 목록)을 설정할 수 있으며 해당 OU 내의 모든 개체에 사용 권한이 상속됩니다.

OU를 사용하여 역할 기반 관리 기능을 제공할 수 있습니다. 예를 들어 한 관리자 그룹에서 사용자 및 그룹을 담당하고 다른 관리자 그룹에서 서버가 들어 있는 OU를 관리할 수 있습니다. 또한 제어 위임 프로세스를 통해 다른 사용자가 관리할 리소스 서버 그룹을 포함시킬 OU를 만들 수도 있습니다. 이 방법을 사용하면 위임된 그룹은 도메인의 다른 부분과 격리되지 않아도 특정 OU를 자율적으로 제어할 수 있게 됩니다.

특정 OU에 대한 제어를 위임하는 관리자는 대개 서비스 관리자입니다. 낮은 권한 수준에서 OU를 제어하는 사용자는 대개 데이터 관리자입니다.

관리 그룹

관리자는 자동 관리를 위해 관리 그룹을 만들어 일련의사용자, 보안 그룹 또는 서버를 분류할 수 있습니다.

도메인에 있는 인프라 서버를 예로 들어 보겠습니다. 인프라 서버에는 WINS 및 DHCP 서비스를 제공하는 서버를 비롯하여 기본 네트워크 서비스를 실행하는 모든 비도메인 컨트롤러가 포함됩니다. 대개 작업 그룹이나 인프라 관리 그룹이 이들 서버를 유지 관리합니다. OU를 사용하여 이러한 서버에 관리 기능을 쉽게 제공할 수 있습니다.

다음 그림은 이러한 OU 구성을 자세히 보여 줍니다.

그림 2.1 OU 관리 위임

그림 2.1 OU 관리 위임

Infrastructure Admin 그룹에 Infrastructure OU의 제어 권한이 위임되면 이 그룹의 구성원은 Infrastructure OU와 해당 OU 내의 모든 서버 및 개체에 대해 모든 권한을 갖습니다. 이를 통해 그룹의 구성원은 그룹 정책을 사용하여 서버 역할에 보안을 설정할 수 있습니다.

이 방법은 관리 세분화를 위해 OU를 사용하는 여러 가지 방법 중 하나일 뿐입니다. 복잡한 조직의 경우 이 장의 끝에 나오는 "추가 정보" 섹션을 참조하십시오.

참고: Active Directory가 DNS에 상당히 많이 의존하므로 DNS 서비스는 도메인 컨트롤러에서 실행하는 것이 일반적입니다. 도메인 컨트롤러는 기본적으로 기본 제공 Domain Controllers OU에 포함됩니다. 이 가이드의 예제에서는 이 방식을 따르므로 인프라 서버 역할에 DNS 서비스가 포함되지 않습니다.

그룹 정책 적용

그룹 정책과 관리 위임을 사용하여 특정 설정, 권한 및 동작을 OU 내의 모든 서버에 적용할 수 있습니다. 수동 단계 대신 그룹 정책을 사용하면 필요할 수 있는 추가 변경 내용으로 여러 서버를 간단히 업데이트할 수 있습니다.

그룹 정책은 누적되며 다음 그림에 표시된 순서대로 적용됩니다.

그림 2.2 GPO 적용 구조

그림 2.2 GPO 적용 구조

그림에 표시된 것처럼 정책은 맨 먼저 컴퓨터의 로컬 정책 수준에서 적용됩니다. 그리고 나서 사이트 수준의 GPO가 적용되고 이후에는 도메인 수준의 GPO가 적용됩니다. 서버가 여러 OU에 포함된 경우에는 최상위 수준 OU에 있는 GPO가 가장 먼저 적용됩니다. GPO는 OU 계층 구조의 아래로 계속 적용됩니다. 서버 개체가 포함된 자식 OU 수준의 GPO가 마지막으로 적용됩니다. 그룹 정책을 처리하는 순서는 사용자나 컴퓨터 계정으로부터 가장 멀리 떨어진 최상위 OU에서 시작하여 사용자나 컴퓨터 계정이 실제로 있는 최하위 OU에서 끝납니다.

그룹 정책을 적용할 때는 기본적으로 다음 사항을 고려해야 합니다.

  • 여러 개의 GPO를 가지고 있는 그룹 정책 수준에 대해서는 GPO 적용 순서를 설정해야 합니다. 여러 정책에서 지정하는 옵션이 동일한 경우 마지막 정책이 최우선적으로 적용됩니다.

  • 다른 GPO로 인해 무시되지 않게 하려면 그룹 정책을 무시 안 함 옵션으로 구성해야 합니다. GPMC(그룹 정책 관리 콘솔)를 사용하여 GPO를 관리할 경우에는 이 옵션의 이름이 적용으로 표시됩니다.

시간 구성

인증을 비롯한 많은 보안 서비스는 정확한 컴퓨터 시계가 있어야 작업을 올바르게 수행할 수 있습니다. 컴퓨터 시간이 정확한지와 조직의 모든 서버가 동일한 시간 소스를 사용하는지 확인해야 합니다. Windows Server 2003 W32Time 서비스는 Active Directory 도메인에서 실행되는 Windows Server 2003과 Microsoft Windows XP 기반 컴퓨터에 시간 동기화 기능을 제공합니다.

W32Time 서비스는 Windows Server 2003 기반 컴퓨터의 시계를 도메인의 도메인 컨트롤러와 동기화합니다. 이 동기화 작업은 Kerberos 프로토콜 및 기타 인증 프로토콜이 제대로 작동하기 위해 반드시 필요합니다. 정상적인 작동을 위해 Windows Server 제품군의 많은 구성 요소는 동기화된 정확한 시간에 의존합니다. 클라이언트에서 시계가 동기화되지 않으면 Kerberos 인증 프로토콜이 사용자의 액세스를 거부할 수 있습니다.

시간 동기화가 제공하는 또 다른 중요한 장점은 사용자 조직의 모든 클라이언트에서 이벤트 상관 관계가 형성된다는 점입니다. 작업 환경의 클라이언트 시계가 동기화되면 조직 전체의 클라이언트에서 일정한 순서로 발생하는 이벤트를 올바르게 분석할 수 있습니다.

W32Time 서비스는 NTP(Network Time Protocol)를 사용하여 Windows Server 2003이 실행되는 컴퓨터의 시계를 동기화합니다. Windows Server 2003 포리스트에서는 기본적으로 다음 방식에 따라 시간이 동기화됩니다.

  • 포리스트 루트 도메인에 있는 PDC(주 도메인 컨트롤러) 에뮬레이터 작업 마스터가 조직의 권한을 보유한 시간 원본입니다.

  • 포리스트의 다른 도메인에 있는 모든 PDC 작업 마스터는 시간을 동기화하기 위해 PDC 에뮬레이터를 선택할 때 도메인 계층 구조를 따릅니다.

  • 도메인의 모든 도메인 컨트롤러가 자신의 인바운드 시간 파트너로 PDC 에뮬레이터 작업 마스터를 사용하여 시간을 동기화합니다.

  • 모든 구성원 서버와 클라이언트 데스크톱 컴퓨터가 인증 도메인 컨트롤러를 자신의 인바운드 시간 파트너로 사용합니다.

정확한 시간을 제공하기 위해 포리스트 루트 도메인의 PDC 에뮬레이터를 믿을 수 있는 NTP 소스나 네트워크의 정확한 시계 등과 같은 허가된 시간 소스와 동기화할 수 있습니다. NTP 동기화 중에는 UDP 포트 123 트래픽이 사용됩니다. 외부 서버와 동기화하려면 먼저 발생할 수 있는 보안 위협과 이 포트를 열 때의 이점을 비교 검토해야 합니다.

또한 사용자에게 제어 권한이 없는 외부 서버와 동기화할 경우 사용하는 서버를 잘못된 시간으로 구성할 위험이 있습니다. 외부 서버는 컴퓨터의 시계를 악의적으로 조작하려는 공격자에 의해 보안이 침해되거나 스푸핑될 수 있습니다. 앞에서 설명한 것처럼 Kerberos 인증 프로토콜을 사용하려면 컴퓨터 시계가 동기화되어야 합니다. 컴퓨터 시계가 동기화되지 않으면 서비스 거부가 발생할 수 있습니다.

보안 템플릿 관리

보안 템플릿은 컴퓨터에 보안 구성을 적용하는 데 사용할 수 있는 텍스트 기반 파일입니다. MMC(Microsoft Management Console) 보안 템플릿 스냅인이나 메모장과 같은 텍스트 편집기를 사용하여 보안 템플릿을 수정할 수 있습니다. 템플릿 파일의 일부 섹션에는 SDDL(Security Descriptor Definition Language)로 작성된 특정 ACL(액세스 제어 목록)이 있습니다. 보안 템플릿을 편집하는 방법 및 SDDL에 대한 자세한 내용은 Microsoft MSDN®(http://www.microsoft.com/msdn/library/)의
"보안 식별자 정의 언어 (영문)" 페이지를 참조하십시오.

인증된 사용자는 기본적으로 그룹 정책 개체에 포함된 모든 설정을 읽을 수 있는 권한을 가지고 있습니다. 따라서 프로덕션 환경에서 사용되는 보안 템플릿은 반드시 그룹 정책을 구현하는 관리자만 액세스할 수 있는 안전한 위치에 저장해야 합니다. 이는 *.inf 파일을 볼 수 없도록 하기 위해서가 아니라 원본 보안 템플릿을 무단으로 변경할 수 없도록 하기 위해서입니다.

Windows Server 2003이 실행되는 모든 컴퓨터에서는 해당 로컬 %SystemRoot%\security\templates 폴더에 보안 템플릿이 저장됩니다. 이 폴더는 도메인 컨트롤러 간에 복제되지 않으므로 템플릿에 대한 버전 제어 문제가 발생하지 않도록 특정 위치에 보안 템플릿의 마스터 복사본이 저장되도록 지정해야 합니다. 중앙의 템플릿을 수정하면 수정한 내용이 해당 컴퓨터로 다시 배포될 수 있습니다. 이렇게 하면 항상 동일한 템플릿 복사본을 수정할 수 있습니다.

GPO 적용 성공 이벤트

관리자는 모든 설정이 조직의 서버에 올바르게 적용되었는지 직접 확인할 수 있지만 도메인 정책이 각 서버에 제대로 다운로드되었음을 관리자에게 알리는 이벤트가 이벤트 로그에 나타나야 합니다. 고유한 이벤트 ID 번호가 지정된 다음과 비슷한 이벤트가 응용 프로그램 로그에 표시됩니다.

종류: 정보

원본: SceCli

이벤트. 1704

설명: 그룹 정책 개체의 보안 정책이 올바르게 적용되었습니다.

기본적으로 워크스테이션이나 서버에서는 90분마다, 도메인 컨트롤러에서는 5분마다 보안 설정을 새로 고칩니다. 이 시간 동안 변경된 내용이 있으면 이러한 종류의 이벤트가 나타납니다. 또한 설정은 변경된 내용이 있는지 여부에 관계없이 16시간마다 새로 고쳐집니다. 이 장 뒷부분에 설명된 절차에 따라 그룹 정책 설정을 수동으로 새로 고칠 수도 있습니다.

서버 역할 조직 구성 단위

앞의 예제에서는 조직의 인프라 서버를 관리하는 방법을 보여 주었습니다. 이 방법을 조직의 다른 서버 및 서비스로도 확장할 수 있습니다. 이러한 작업은 모든 서버에 대해 완전한 그룹 정책을 만들고 Active Directory 내의 서버가 작업 환경의 보안 표준을 만족하도록 하기 위해 수행됩니다.

이러한 종류의 그룹 정책은 조직에 있는 모든 서버의 표준 설정에 대해 일관된 기준을 형성합니다. 뿐만 아니라 조직의 각 서버 유형에 적절한 보안 설정을 제공하기 위해서는 OU 구조를 만들고 그룹 정책을 적용할 때 좀 더 자세한 분류가 필요합니다. 예를 들어 IIS(Internet Information Server), 파일, 인쇄, IAS(인터넷 인증 서버) 및 인증서 서비스 등의 몇몇 서버 역할에는 고유한 그룹 정책이 필요합니다.

중요: 간단한 설정을 위해 이 장의 예제에서는 엔터프라이즈 클라이언트 환경을 사용한다고 가정합니다. 다른 두 가지 환경 중 하나를 사용할 경우 해당 파일 이름을 바꾸십시오. 세 가지 환경과 해당 기능 간 차이점은 1장 "Windows Server 2003 보안 가이드 소개"에 나와 있습니다.

구성원 서버 기준 정책

서버 역할 OU를 설정하려면 먼저 기준 정책을 만들어야 합니다. 이러한 정책을 만들기 위해 표준 구성원 서버에서 SCW를 사용하여 Member Servers Baseline.xml 파일을 만들 수 있습니다. XML 생성 과정의 일부로 SCW를 사용하여 제공된 구성원 서버 기준 보안 템플릿(LC-Member Server Baseline.inf, EC-Member Server Baseline.inf 또는 SSLF-Member Server Baseline.inf) 중 하나를 포함시킵니다.

생성된 SCW 정책은 GPO로 변환된 후 Member Servers OU에 연결됩니다. 이 새로운 기준 GPO는 Member Servers OU 및 자식 OU의 모든 서버에 기준 그룹 정책 설정을 적용합니다. 구성원 서버 기준 정책에 대해서는 4장 "구성원 서버 기준 정책"에 설명되어 있습니다.

조직에 있는 대부분의 서버에 대해 지정하려는 설정을 기준 그룹 정책에서 정의해야 합니다. 기준 정책이 적용되면 안 되는 서버가 있을 수 있지만 많지는 않습니다. 자체적으로 기준 그룹 정책을 만들 경우 가능한 한 제한적인 정책을 만들어야 하며 이 정책과는 다른 설정이 필요한 서버는 별도의 서버별 OU로 분류합니다.

서버 역할 유형 및 조직 구성 단위

식별된 각 서버 역할에는 기준 OU 외에도 추가 SCW 정책, 보안 템플릿 및 OU가 필요합니다. 이를 통해 각 역할이 점진적으로 변경됨에 따라 요구되는 별도의 정책을 만들 수 있습니다.

앞의 예제에서 인프라 서버는 Member Servers OU의 자식 OU인 Infrastructure OU로 대체되었습니다. 다음에는 이러한 서버에 해당 구성을 적용합니다. 각 보안 환경에 해당하는 세 가지 보안 템플릿 LC-Infrastructure Server.inf, EC-Infrastructure Server.inf 및 SSLF-Infrastructure Server.inf가 이 솔루션과 함께 제공되었습니다. 이러한 보안 템플릿을 SCW와 함께 사용하면 DHCP 및 WINS에 필요한 특정 조정 설정이 포함되어 있는 보안 정책을 만들 수 있습니다. 그런 후 결과 정책은 새로운 GPO로 변환되고 Infrastructure OU에 연결됩니다.

이 GPO는 제한된 그룹 설정을 사용하여 Infrastructure OU에 포함된 모든 서버의 Local Administrators 그룹에 다음의 세 가지 그룹을 추가합니다.

  • Domain Administrators

  • Enterprise Administrators

  • Infrastructure Administrators

이 장 앞부분에 설명된 것처럼 이러한 방법은 GPO를 배포하는 데 사용할 수 있는 OU 구조를 만드는 여러 가지 방법 중 하나일 뿐입니다. 그룹 정책 구현을 위해 OU를 만드는 방법에 대한 자세한 내용은 www.microsoft.com/resources/documentation/Windows/2000/server/reskit/
en-us/deploy/dgbd_ads_heqs.asp?frame=true 사이트에서 "Active Directory 구조 디자인 (영문)" 및 관련 항목을 참조하십시오.

다음 표에서는 이 가이드에 정의되어 있는 Windows Server 2003 서버 역할 및 해당 템플릿 파일을 보여 줍니다. 보안 템플릿 파일 이름 앞에는 <Env> 변수가 붙습니다. 이 변수는 LC(레거시 클라이언트), EC(엔터프라이즈 클라이언트) 또는 SSLF(특수 보안 - 기능 제한)로 적절히 대체됩니다.

표 2.1 Windows Server 2003 서버 역할

서버 역할

설명

보안 템플릿 파일 이름

구성원 서버

도메인의 구성원이며 Member Servers OU나 하위 OU에 있는 모든 서버

<Env>-Member Server Baseline.inf

도메인 컨트롤러

모든 Active Directory 도메인 컨트롤러. 이러한 서버는 DNS 서버이기도 합니다.

<Env>-Domain Controller.inf

인프라 서버

잠겨 있는 모든 WINS 및 DHCP 서버

<Env>-Infrastructure Server.inf

파일 서버

잠겨 있는 모든 파일 서버

<Env>-File Server.inf

인쇄 서버

잠겨 있는 모든 인쇄 서버

<Env>-Print Server.inf

웹 서버

잠겨 있는 모든 IIS 웹 서버

<Env>-Web Server.inf

IAS 서버

잠겨 있는 모든 IAS 서버

<Env>-IAS Server.inf

인증서 서비스 서버

잠겨 있는 모든 CA(인증 기관) 서버

<Env>-CA Server.inf

요새 호스트

모든 인터넷 서버

<Env>-Bastion Host.inf


요새 호스트 서버에 대한 템플릿 파일을 제외한 모든 템플릿 파일은 해당 자식 OU에 적용됩니다. 이러한 각 자식 OU는 각 컴퓨터가 조직에서 이행할 역할을 정의하기 위해 특정 구성을 적용하도록 요구합니다.

각 서버 역할에 대한 보안 요구 사항은 저마다 다릅니다. 각 역할에 대한 적절한 보안 설정에 대해서는 이후의 장에서 자세히 설명합니다. 모든 역할에 모든 환경에 해당하는 템플릿이 있는 것은 아닙니다. 예를 들어 요새 호스트는 항상 SSLF 환경에 있는 것으로 간주됩니다.

중요: 이 가이드에서는 Windows Server 2003 실행 컴퓨터가 여기에서 정의한 역할만 수행한다고 가정합니다. 사용자 조직의 서버가 위에 나온 역할과 일치하지 않거나, 다목적 서버일 경우에는 여기에서 정의하는 설정을 지침으로 사용하여 고유의 보안 템플릿을 만드십시오. 그러나 서버가 수행하는 기능이 많을수록 공격을 당하기도 쉽다는 점을 유념해야 합니다.

다음 그림에서는 EC 환경에서 이와 같은 정의된 서버 역할을 지원할 수 있는 최종적인 OU 디자인의 예를 보여 줍니다.

그림 2.2 GPO 적용 구조

그림 2.3 OU 디자인 예제

OU, GPO 및 그룹 디자인

이전 섹션에 설명된 권장 OU와 정책은 Windows Server 2003 실행 컴퓨터에서 조직의 기존 OU 구조를 다시 구성하는 기준 또는 새로운 환경을 만드는 데 사용할 수 있습니다. 또한 관리자는 자신이 미리 정의해 둔 관리 범위를 사용하여 각 관리 그룹을 만들 수 있습니다. 다음 표에는 각 그룹 및 그룹이 관리하는 OU의 상관 관계의 예가 나와 있습니다.

표 2.2 OU 및 관리 그룹

OU 이름

관리 그룹

도메인 컨트롤러

Domain Engineering

구성원 서버

Domain Engineering

인프라

Infrastructure Admins

파일

Infrastructure Admins

인쇄

Infrastructure Admins

IAS

Domain Engineering

Web Services

CA

Enterprise Administrators


각 관리 그룹은 Active Directory 인프라 및 보안을 담당하는 Domain Engineering 구성원에 의해 도메인 내의 글로벌 그룹으로 생성되었습니다. 그런 후 해당 GPO는 제한된 그룹에 이러한 각 관리 그룹을 추가하는 데 사용되었습니다. 표에 나열된 관리 그룹은 각 그룹이 담당하는 업무와 관련된 컴퓨터만 포함된 OU의 Local Administrators 그룹 구성원으로만 이루어집니다.

끝으로 Domain Engineering 구성원은 해당 그룹의 관리자만 GPO를 편집할 수 있도록 각 GPO에 사용 권한을 설정했습니다.

이러한 그룹의 생성 및 구성 작업은 전체적인 Active Directory 디자인 및 구현 프로세스의 일부이며 이 가이드에 속하지 않습니다.


프로세스 개요

이 가이드에서는 SCW 기반 및 그룹 정책 기반 방법을 통합합니다. 이러한 혼합 방식을 통해 보안 구성을 보다 쉽게 만들고 테스트할 수 있지만 대규모 Windows 네트워크에 필요한 유연성과 확장성은 계속 보장됩니다.

정책을 만들고 테스트하고 배포하는 데 사용되는 프로세스는 다음과 같습니다.

  1. 그룹 및 OU를 포함하는 Active Directory 환경을 만듭니다. 적절한 관리 그룹을 만들고 OU 사용 권한을 해당 그룹에 위임해야 합니다.

  2. PDC 에뮬레이터 FSMO를 호스팅하는 도메인 컨트롤러에서 시간 동기화를 구성합니다.

  3. 도메인 정책을 구성합니다.

  4. SCW를 사용하여 기준 정책을 만듭니다.

  5. SCW를 사용하여 기준 정책을 테스트합니다.

  6. 기준 정책을 GPO로 변환한 후 해당 GPO에 연결합니다.

  7. SCW를 사용하여 역할 정책과 포함되는 보안 템플릿을 만듭니다.

  8. SCW를 사용하여 역할 정책을 테스트합니다.

  9. 역할 정책을 GPO로 변환한 후 해당 GPO에 연결합니다.

다음 섹션에서는 이러한 단계를 보다 자세히 설명합니다.

참고: 간단한 설정을 위해 이 섹션의 예제에서는 EC(엔터프라이즈 클라이언트) 환경을 사용한다고 가정합니다. 다른 두 가지 환경 중 하나를 사용할 경우 해당 파일 이름을 바꾸십시오. 세 가지 환경과 해당 기능 간 차이점은 1장 "Windows Server 2003 보안 가이드 소개"에 나와 있습니다.

Active Directory 환경 만들기

보안 강화 프로세스를 시작하려면 먼저 적절한 Active Directory 도메인 및 OU 구조가 있어야 합니다. 다음 절차에서는 이 가이드에 사용되는 OU 및 그룹을 만든 후 적절한 관리 액세스 권한을 부여하는 단계에 대해 설명합니다.

  1. MMC Active Directory 사용자 및 컴퓨터 스냅인(Dsa.msc)을 엽니다.

  2. 도메인 개체의 루트에서 Member Servers라는 OU를 만듭니다.

  3. 이 새 OU로 이동한 후 Infrastructure라는 자식 OU를 만듭니다.

  4. 모든 WINS 및 DHCP 서버를 Infrastructure OU로 이동합니다.

  5. 글로벌 보안 그룹(Infrastructure Admins)을 만든 후 해당 도메인 계정을 이 그룹에 추가합니다.

  6. 제어 위임 마법사를 실행하여 Infrastructure Admins 그룹에 해당 OU의 모든 권한을 제공합니다.

  7. 파일 서버, 인쇄 서버, 웹 서버, IAS 서버 및 인증서 서비스 서버 역할에 대해 3-6단계를 반복합니다. 해당 OU 및 그룹 이름은 표 2.2의 정보를 참조하십시오.

시간 동기화 구성

다음 절차에서는 도메인 컨트롤러와 구성원 서버가 외부 시간 소스와 동기화되도록 합니다. 이 동기화 기능을 통해 Kerberos 인증이 제대로 작동될 수 있으며 Active Directory 도메인을 사용자가 보유하고 있는 모든 외부 컴퓨터와 동기화할 수 있습니다.

  1. PDC 에뮬레이터 FSMO가 있는 도메인 컨트롤러에서 명령 프롬프트를 열고 다음 명령을 실행합니다. 여기서 <PeerList>는 원하는 시간 소스에 대한 DNS 이름 또는 IP 주소의 쉼표로 구분된 목록입니다.

    w32tm /config /syncfromflags:manual /manualpeerlist:<PeerList>
    

  2. 구성을 업데이트하려면 다음 명령을 실행합니다.

    w32tm /config /update
    

  3. 이벤트 로그를 확인합니다. 컴퓨터가 서버에 연결할 수 없으면 절차에 실패하고 이와 관련된 항목이 이벤트 로그에 기록됩니다.

이 절차는 대개 내부 네트워크의 권한을 보유한 시간 원본을 정확도가 높은 외부 시간 원본과 동기화할 때 사용합니다. 그러나 이 절차는 Windows XP나 Windows Server 2003 제품군 중 하나를 실행하는 컴퓨터에서만 실행할 수 있습니다. 모든 서버가 동일한 내부 소스와 동기화될 경우에는 일반적으로 모든 서버의 시계를 외부 소스와 동기화해야 할 필요가 없습니다. 기본적으로 구성원 컴퓨터는 항상 시계를 도메인 컨트롤러와 동기화합니다.

참고: 로그 분석에 정확성을 제공하려면 Windows 이외의 운영 체제를 실행하는 네트워크 컴퓨터의 시계도 Windows Server 2003 PDC 에뮬레이터나 해당 서버의 동일한 시간 소스와 동기화해야 합니다.

도메인 정책 구성

다음 절차에서는 도메인 수준 정책에 대해 이 가이드와 함께 제공된 보안 템플릿을 가져옵니다. SCW는 도메인 수준 정책을 처리하지 않으므로 이 정책은 보안 템플릿으로 제공됩니다. 다음 절차를 구현하려면 특정 정책(.inf) 파일이 사용자 시스템에 있어야 합니다.

경고: 이 가이드에 있는 보안 템플릿은 사용자 환경의 보안을 높이도록 디자인되었습니다. 해당 보안 템플릿을 설치했을 때 작업 환경의 일부 기능이 손실되고 업무에 중요한 응용 프로그램에 오류가 발생할 수 있습니다.

따라서 반드시 이러한 설정을 철저히 테스트한 후에 프로덕션 환경에 배포해야 합니다. 새로운 보안 설정을 적용할 때는 먼저 사용자 환경의 각 도메인 컨트롤러와 서버를 백업해야 합니다. 필요한 경우 레지스트리 설정 및 Active Directory 개체를 복원할 수 있도록 시스템 상태를 백업해 두어야 합니다.

도메인 정책 보안 템플릿을 가져오려면

  1. Active Directory 사용자 및 컴퓨터에서 도메인을 마우스 오른쪽 단추로 클릭한 다음 속성을 클릭합니다.

  2. 그룹 정책 탭에서 새로 만들기를 클릭하여 새 GPO를 추가합니다.

  3. EC-Domain Policy를 입력한 후 Enter 키를 누릅니다.

  4. EC-Domain Policy를 마우스 오른쪽 단추로 클릭한 후 무시 안 함을 선택합니다.

  5. EC-Domain Policy를 선택한 후 편집을 클릭합니다.

  6. 그룹 정책 개체 편집기 창에서 컴퓨터 구성\Windows 설정을 클릭합니다. 보안 설정을 마우스 오른쪽 단추로 클릭한 다음 정책 가져오기를 선택합니다.

  7. 정책을 다음에서 불러옵니다: 대화 상자에서 "\Tools and Templates\Security Guide\Security Templates"로 이동한 후 EC-Domain.inf를 두 번 클릭합니다.

  8. 수정된 그룹 정책을 닫습니다.

  9. 도메인 속성 창을 닫습니다.

  10. 예약된 그룹 정책이 적용되기를 기다리지 않으려면 그룹 정책 프로세스를 수동으로 시작할 수 있습니다. 이렇게 하려면 다음을 수행하십시오.

    • 명령 프롬프트를 열고 gpupdate /Force를 입력한 후 Enter 키를 누릅니다.

  11. 이벤트 로그를 보고 그룹 정책이 다운로드되었는지와 서버가 도메인의 다른 도메인 컨트롤러와 통신할 수 있는지를 확인하십시오.

경고: EC 도메인 정책을 만들 때는 무시 안 함 옵션을 사용하여 도메인 전체에 이 정책을 강제로 적용해야 합니다. 이 가이드에 나온 그룹 정책 중에서 이 그룹 정책에만 무시 안 함 옵션을 설정해야 하며 다른 그룹 정책에는 이 옵션을 사용하지 마십시오. 또한 기본 설정으로 되돌려야 할 수도 있으므로 Windows Server 2003 기본 도메인 정책을 수정하지 마십시오.

새 그룹 정책에 기본 정책보다 높은 우선 순위를 부여하려면 새 정책을 GPO 링크에서 가장 높은 우선 순위가 부여되는 위치로 가져갑니다.

중요: 일관된 암호 정책을 적용하려면 조직의 다른 모든 추가 도메인에도 이 그룹 정책을 가져와야 합니다. 그러나 루트 도메인 암호 정책이 다른 도메인의 암호 정책보다 엄격한 환경이 얼마든지 있을 수 있습니다. 이와 동일한 정책을 사용하게 될 다른 도메인이 해당 도메인과 동일한 비즈니스 요구 사항을 가지고 있는지도 확인해야 합니다. 암호 정책은 도메인 수준에서만 설정할 수 있으므로 일부 사용자의 경우에는 업무상의 이유나 법률적인 이유로 별도의 도메인으로 이동시켜 해당 그룹에 대해서는 더 엄격한 보안 정책을 구현해야 하는 경우도 있을 수 있습니다.

상속 가능한 사용 권한 허용 옵션의 선택을 취소하려면

기본적으로 새로 만든 OU 구조는 대부분의 보안 설정을 상위 컨테이너에서 상속 받습니다. 각 OU에 대해 상속 가능한 권한을 부모 개체에서 이 개체 및 모든 자식 개체에 전파할 수 있음 확인란의 선택을 취소합니다.

  1. Active Directory 사용자 및 컴퓨터를 엽니다.

  2. 보기, 고급 기능을 차례로 클릭한 후 고급 보기를 선택합니다.

  3. 해당 OU를 마우스 오른쪽 단추로 클릭하고 속성을 클릭합니다.

  4. 보안 탭을 클릭하고 고급 단추를 클릭합니다.

  5. 상속 가능한 권한을 부모 개체에서 이 개체 및 모든 자식 개체에 전파할 수 있음(여기에서 명시적으로 정의한 항목을 가진 개체 포함) 확인란의 선택을 취소합니다.

이전에 관리자가 추가한 그룹 중 필요하지 않은 것은 모두 제거하고 각 서버 역할 OU에 해당하는 도메인 그룹을 추가합니다. Domain Administrators 그룹에 대해서는 모든 권한 설정을 그대로 유지합니다.

SCW를 사용하여 수동으로 기준 정책 만들기

다음 단계는 SCW를 사용하여 구성원 서버 기준 정책을 만드는 것입니다.

이전 구성에서 가져온 레거시 설정이나 소프트웨어가 없도록 운영 체제를 새로 설치하여 구성 작업을 시작해야 합니다. 가능한 경우 호환성이 최대한 보장되도록 배포에 사용된 하드웨어와 비슷한 하드웨어를 사용해야 합니다. 새 설치를 참조 시스템이라고 합니다.

MSBP(구성원 서버 기준 정책) 생성 단계 중에 검색된 역할 목록에서 파일 서버 역할을 제거해야 합니다. 이 역할은 일반적으로 이 역할을 필요로 하지 않는 서버에 구성되며 보안 위험으로 간주될 수 있습니다. 파일 서버 역할을 필요로 하는 서버에 대해 이 역할을 활성화하려는 경우 다음 프로세스 뒷부분에서 또 다른 정책을 적용할 수 있습니다.

MSBP(구성원 서버 기준 정책)를 만들려면

  1. 새 참조 컴퓨터에서 Windows Server 2003 SP1을 새로 설치합니다.

  2. 제어판, 프로그램 추가/제거, Windows 구성 요소 추가/제거를 통해 컴퓨터에 보안 구성 마법사 구성 요소를 설치합니다.

  3. 컴퓨터를 도메인에 가입시킵니다.

  4. 작업 환경의 모든 서버에 필수 응용 프로그램만 설치합니다. 예로 소프트웨어 및 관리 에이전트, 테이프 백업 에이전트 및 바이러스 백신이나 스파이웨어 백신 유틸리티를 들 수 있습니다.

  5. SCW를 시작하고 새 보안 정책 만들기를 선택한 후 참조 컴퓨터를 가리키도록 지정합니다.

  6. 검색된 역할 목록에서 파일 서버 역할을 제거합니다.

  7. 검색된 클라이언트 기능이 작업 환경에 적절한지 확인합니다.

  8. 검색된 관리 옵션이 작업 환경에 적절한지 확인합니다.

  9. 백업 에이전트나 바이러스 백신 소프트웨어와 같이 기준 정책에 필요한 추가 서비스가 검색되는지 확인합니다.

  10. 작업 환경에 있는 미지정 서비스의 처리 방법을 결정합니다. 보안 강화를 위해 이 설정을 사용 안 함으로 구성할 수도 있습니다. 프로덕션 서버가 참조 컴퓨터와 중복되지 않는 추가 서비스를 실행할 경우 문제가 발생할 수 있으므로 먼저 구성을 철저히 테스트한 후에 프로덕션 네트워크에 배포해야 합니다.

  11. 네트워크 설정을 검토하고 Windows 방화벽에 대한 예외로 구성될 적절한 포트 및 응용 프로그램이 검색되었는지 확인합니다.

  12. "레지스트리 설정" 섹션을 건너뜁니다.

  13. "감사 정책" 섹션을 건너뜁니다.

  14. 적절한 보안 템플릿(예: EC-Member Server Baseline.inf)을 포함시킵니다.

  15. 적절한 이름(예: Member Server Baseline.xml)을 지정하여 정책을 저장합니다.

도메인 컨트롤러 정책을 만들려면

도메인 컨트롤러 정책을 만들려면 도메인 컨트롤러로 구성된 컴퓨터를 사용해야 합니다. 기존 도메인 컨트롤러를 사용하거나 참조 컴퓨터를 만든 후 Dcpromo 도구를 사용하여 해당 컴퓨터를 도메인 컨트롤러로 만들 수 있습니다. 그러나 대부분의 조직에서는 도메인 컨트롤러를 프로덕션 환경에 추가하면 보안 정책에 위반될 수 있으므로 다른 방식을 사용하려고 합니다. 기존 도메인 컨트롤러를 사용할 경우에는 SCW를 사용하여 다른 설정을 적용하거나 해당 구성을 수정하지 않도록 합니다.

  1. 제어판, 프로그램 추가/제거, Windows 구성 요소 추가/제거를 통해 컴퓨터에 보안 구성 마법사 구성 요소를 설치합니다.

  2. 작업 환경의 모든 서버에 필수 응용 프로그램만 설치합니다. 예로 소프트웨어 및 관리 에이전트, 테이프 백업 에이전트 및 바이러스 백신이나 스파이웨어 백신 유틸리티를 들 수 있습니다.

  3. SCW GUI를 시작하고 새 보안 정책 만들기를 선택한 후 참조 컴퓨터를 가리키도록 지정합니다.

  4. 검색된 역할이 작업 환경에 적절한지 확인합니다.

  5. 검색된 클라이언트 기능이 작업 환경에 적절한지 확인합니다.

  6. 검색된 관리 옵션이 작업 환경에 적절한지 확인합니다.

  7. 백업 에이전트나 바이러스 백신 소프트웨어와 같이 기준 정책에 필요한 추가 서비스가 검색되는지 확인합니다.

  8. 작업 환경에 있는 미지정 서비스의 처리 방법을 결정합니다. 보안 강화를 위해 이 정책 설정을 사용 안 함으로 구성할 수도 있습니다. 프로덕션 서버가 참조 컴퓨터와 중복되지 않는 추가 서비스를 실행할 경우 문제가 발생할 수 있으므로 먼저 구성을 철저히 테스트한 후에 프로덕션 네트워크에 배포해야 합니다.

  9. 네트워크 설정을 검토하고 Windows 방화벽에 대한 예외로 구성될 적절한 포트 및 응용 프로그램이 검색되었는지 확인합니다.

  10. "레지스트리 설정" 섹션을 건너뜁니다.

  11. "감사 정책" 섹션을 건너뜁니다.

  12. 적절한 보안 템플릿(예: EC-Domain Controller.inf)을 포함시킵니다.

  13. 적절한 이름(예: Domain Controller.xml)을 지정하여 정책을 저장합니다.

SCW를 사용하여 기준 정책 테스트

기준 정책을 만들어 저장한 후에는 반드시 테스트 환경에 배포해 보십시오. 이상적으로는 테스트 서버가 프로덕션 서버와 동일한 하드웨어 및 소프트웨어 구성을 갖는 것이 좋습니다. 이렇게 하면 특정 하드웨어 장치에 필요한 예상치 못한 서비스가 존재하는 경우와 같은 잠재적인 문제를 찾아 해결할 수 있습니다.

정책을 테스트하기 위해서는 두 가지 방법을 사용할 수 있습니다. 바로 네이티브 SCW 배포 기능을 사용하는 방법과 GPO를 통해 정책을 배포하는 것입니다.

정책 감사를 시작할 경우에는 네이티브 SCW 배포 기능을 사용해야 합니다. SCW를 사용하여 한 번에 한 서버에 정책을 밀어 넣거나 Scwcmd를 사용하여 서버 그룹에 정책을 밀어 넣을 수 있습니다. 네이티브 배포 방법은 SCW 내에서 배포된 정책을 쉽게 롤백할 수 있는 기능을 제공합니다. 이 기능은 테스트 프로세스 중에 정책을 많이 변경해야 할 경우에 특히 유용합니다.

정책을 테스트하여 대상 서버에 정책을 적용했을 때 중요한 기능이 영향을 받지 않는지 확인합니다. 구성 변경 내용을 적용한 후에는 컴퓨터의 핵심 기능을 확인해야 합니다. 예를 들어 서버가 CA(인증 기관)로 구성된 경우 클라이언트에서 인증서를 요청하고 얻을 수 있는지, 인증서 해지 목록을 다운로드할 수 있는지 등을 확인해야 합니다.

만든 정책 구성에 문제가 없으면 다음 절차에 표시된 대로 Scwcmd를 사용하여 정책을 GPO로 변환합니다.

SCW 정책을 테스트하는 방법에 대한 자세한 내용은 "보안 구성 마법사에 대한 배포 가이드 (영문)" www.microsoft.com/technet/prodtechnol/windowsserver2003/
library/SCWDeploying/5254f8cd-143e-4559-a299-9c723b366946.mspx) 및 보안 구성 마법사 설명서 (영문)의 다운로드 가능 버전(http://go.microsoft.com/fwlink/?linkid=43450)을 참조하십시오.

기준 정책을 GPO로 변환

기준 정책을 철저히 테스트한 후에 다음 단계를 완료하여 정책을 GPO로 변환한 후 해당 OU에 연결합니다.

  1. 명령 프롬프트에서 다음을 입력합니다.

    scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName>
    

    그런 후 Enter 키를 누릅니다. 예를 들면 다음과 같습니다.

    
    scwcmd transform /p:"C:\Windows\Security\msscw\Policies\Infrastructure.xml" 
    /g:"Infrastructure Policy"
    

    참고: 여기서는 표시상의 문제 때문에 명령 프롬프트에 입력할 정보가 여러 줄로 표시됩니다. 실제로 이 정보는 모두 한 줄로 입력해야 합니다.

  2. 그룹 정책 관리 콘솔을 사용하여 새로 만든 GPO를 해당 OU에 연결합니다.

SCW 보안 정책 파일에 Windows 방화벽 설정이 포함되어 있을 경우 이 절차가 성공적으로 완료되려면 로컬 컴퓨터에서 Windows 방화벽이 활성 상태여야 합니다. Windows 방화벽이 활성 상태인지 확인하려면 제어판을 열고 Windows 방화벽을 두 번 클릭합니다.

이제 최종 테스트를 수행하여 GPO가 원하는 설정을 적용하는지 확인합니다. 이 절차를 완료하려면 적절한 설정이 구성되었으며 기능에 영향을 주지 않는지 확인합니다.

SCW를 사용하여 역할 정책 만들기

다음 단계는 SCW를 사용하여 각 서버 역할의 역할 정책을 만드는 것입니다.

역할별 정책을 만드는 단계는 MSBP를 만들 때 수행한 단계와 비슷합니다. 이전 구성의 레거시 설정이나 소프트웨어가 없도록 하려면 참조 컴퓨터를 한 번 더 사용해야 합니다.

역할 정책을 만들려면

  1. 새 참조 컴퓨터에서 Windows Server 2003 SP1을 새로 설치합니다.

  2. 제어판, 프로그램 추가/제거, Windows 구성 요소 추가/제거를 통해 컴퓨터에 보안 구성 마법사 구성 요소를 설치합니다.

  3. 새 서버를 도메인에 가입시킵니다.

  4. 작업 환경의 모든 서버에 필수 응용 프로그램을 설치합니다. 예로 소프트웨어 및 관리 에이전트, 테이프 백업 에이전트 및 바이러스 백신이나 스파이웨어 백신 유틸리티를 들 수 있습니다.

  5. 컴퓨터에 대해 적절한 역할을 구성합니다. 예를 들어 대상 서버에서 DHCP 및 WINS를 실행하려면 해당 구성 요소를 설치합니다. 대상 서버를 배포된 서버와 정확히 동일하게 구성할 필요는 없지만 역할은 반드시 설치해야 합니다.

  6. SCW를 시작합니다.

  7. 새 보안 정책 만들기를 선택한 후 참조 컴퓨터를 가리키도록 지정합니다.

  8. 검색된 역할이 작업 환경에 적절한지 확인합니다.

  9. 검색된 클라이언트 기능이 작업 환경에 적절한지 확인합니다.

  10. 검색된 관리 옵션이 작업 환경에 적절한지 확인합니다.

  11. 백업 에이전트나 바이러스 백신 소프트웨어와 같이 기준 정책에 필요한 추가 서비스가 검색되는지 확인합니다.

  12. 작업 환경에 있는 미지정 서비스의 처리 방법을 결정합니다. 기능이 다소 제한되더라도 보안을 강화하려면 이 정책 설정을 사용 안 함으로 구성합니다. 이렇게 하면 SCW를 통해 명시적으로 허용되지 않는 새 서비스가 비활성화됩니다. 프로덕션 서버가 참조 컴퓨터와 중복되지 않는 추가 서비스를 실행할 경우 문제가 발생할 수 있으므로 먼저 구성을 철저히 테스트한 후에 프로덕션 네트워크에 배포해야 합니다.

  13. 나열된 모든 서비스 변경 내용을 확인합니다.

  14. 네트워크 설정을 검토한 후 SCW가 Windows 방화벽에 대한 예외로 구성할 포트 및 응용 프로그램을 검색했는지 확인합니다.

  15. "레지스트리 설정" 섹션을 건너뜁니다.

  16. "감사 정책" 섹션을 건너뜁니다.

  17. 서버가 웹 서버 역할로 구성되면 “인터넷 정보 서비스" 섹션의 단계를 완료하여 필요한 IIS 기능을 지원하도록 SCW를 구성합니다.

  18. 보안 템플릿 포함을 클릭하여 해당 보안 템플릿을 추가합니다.

  19. 적절한 이름을 지정하여 정책을 저장합니다.

SCW를 사용하여 역할 정책 테스트

기준 정책과 마찬가지로 두 가지 방법으로 정책을 테스트할 수 있습니다. 바로 네이티브 SCW 배포 기능을 사용하는 방법과 GPO를 통해 정책을 배포하는 것입니다. 역할 정책도 테스트 환경에서 철저히 테스트한 후에 프로덕션 환경에서 사용해야 합니다. 이렇게 하면 프로덕션 환경의 작동 중단 시간 및 오류를 최소화할 수 있습니다. 새 구성을 철저히 테스트한 후에는 다음 절차대로 정책을 GPO로 변환한 후 해당 OU에 적용할 수 있습니다.

역할 정책을 GPO로 변환

역할 정책을 철저히 테스트한 후에 다음 단계를 완료하여 정책을 GPO로 변환한 후 해당 OU에 연결합니다.

  1. 명령 프롬프트에서 다음을 입력합니다.

    scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName>
    

    그런 후 Enter 키를 누릅니다. 예를 들면 다음과 같습니다.

    
    scwcmd transform /p:"C:\Windows\Security\msscw\Policies\Infrastructure.xml" 
    /g:"Infrastructure Policy"
    

    참고: 여기서는 표시상의 문제 때문에 명령 프롬프트에 입력할 정보가 여러 줄로 표시됩니다. 실제로 이 정보는 모두 한 줄로 입력해야 합니다.

  2. 그룹 정책 관리 콘솔을 사용하여 새로 만든 GPO를 해당 OU에 연결한 후 가장 높은 우선 순위가 지정되도록 기본 도메인 컨트롤러 정책 위로 옮깁니다.

SCW 보안 정책 파일에 Windows 방화벽 설정이 포함되어 있을 경우 이 절차가 성공적으로 완료되려면 로컬 컴퓨터에서 Windows 방화벽이 활성 상태여야 합니다. Windows 방화벽이 활성 상태인지 확인하려면 제어판을 열고 Windows 방화벽을 두 번 클릭합니다.

요약

보안 관리자는 작업 환경에 적절한 보안 방법을 선택하기 위해 일반적인 그룹 정책 기반 보안 강화 방법과 비교할 때 SCW의 장단점을 이해해야 합니다. SCW와 그룹 정책을 함께 사용하면 그룹 정책의 확장 가능한 배포 및 관리 기능과 정책의 프로토타입을 빠르고 일관되게 구축할 수 있는 SCW의 기능을 모두 활용할 수 있습니다.

환경의 보안 유지를 위해 포리스트, 도메인 및 OU(조직 구성 단위)를 검토할 때 고려해야 할 몇 가지 디자인 요소가 있습니다.

조직에 필요한 자율성과 독립성 요구 사항을 면밀히 검토하여 이를 문서화하는 것은 매우 중요합니다. 행정의 자율성, 운영의 독립성 및 합법적이거나 규제를 위한 격리 등은 복잡한 포리스트 디자인을 고려하게 만드는 요소입니다.

서비스 관리자를 제어하는 방법을 이해하는 것도 중요합니다. 악의적인 서비스 관리자는 조직에 큰 위험을 가져올 수 있습니다. 간단한 예를 들면, 악의적인 도메인 관리자는 포리스트의 모든 도메인에 있는 데이터에 액세스할 수 있습니다.

조직의 포리스트 또는 도메인 디자인을 변경하는 것이 쉽지는 않겠지만 이로 인해 발생할 수 있는 보안 위험에 대비할 필요가 있습니다. 또한 조직에서 OU 배포를 계획할 때는 서비스 관리자와 데이터 관리자 모두에 대한 필요를 고려해야 합니다. 이 장에서는 조직에서 다양한 서버 역할을 지속적으로 관리하기 위해 GPO의 사용을 지원하는 OU 모델을 만드는 방법에 대해 자세히 설명했습니다.

추가 정보

다음 링크는 보안 및 Windows Server 2003 SP1이 실행되는 서버의 보안 강화와 관련된 항목에 대한 추가 정보를 제공합니다.


다운로드

Windows Server 2003 보안 가이드 받기 (영문)

업데이트 알림

업데이트 및 최신 릴리스 정보 수신 등록 (영문)

사용자 의견 보내기

의견 및 제안 보내기



이 정보가 도움이 되었습니까?
(1500자 남음)
의견을 주셔서 감사합니다.
표시:
© 2014 Microsoft