Windows Server 2003 환경에서 도메인 인프라 구성
이 페이지에서
모듈 정보목표
적용 범위
모듈 사용법
개요
도메인 정책
계정 정책
암호 정책
계정 잠금 정책
Kerberos 정책
보안 옵션
요약
모듈 정보
이 모듈은 보안 도메인 환경을 구현하는 것과 관련된 내용을 제공합니다. 이 모듈에서는 도메인 구성 요소 및 이러한 구성 요소를 사용하여 잘 관리되는 도메인 인프라를 설계하고 만드는 방법에 대해 설명합니다. 이 모듈에서는 조직 구성 단위 계층 구조를 통한 그룹 정책의 적용, 관리 그룹에 관리 위임, 보안 템플릿을 통한 보안 설정 구성 등을 보여 주는 시나리오를 통해 보안 문제 및 그 해결 방법을 살펴봅니다. 조직 구성 단위 계층 구조에 대해서 전반적으로 살펴보되, 특히 도메인 정책을 중점적으로 검토함으로써 도메인 수준에서 적용되는 보안 설정 및 그 기능에 대해 자세히 살펴봅니다. 이 모듈에서는 레거시 클라이언트, 엔터프라이즈 클라이언트, 고급 보안 클라이언트와 관련된 세 가지 서로 다른 보안 시나리오를 사용합니다.
목표
이 모듈을 사용하여 다음을 할 수 있습니다.
-
Microsoft Active Directory 디렉터리 서비스의 디자인과 관련된 보안 문제 검토 -
조직 구성 단위 계층 구조 디자인을 사용한 그룹 정책 적용 검토 -
조직 구성 단위 계층 구조 디자인을 사용한 관리 위임 검토 -
보안 템플릿 사용법 이해 -
보안 템플릿과 그룹 정책 통합 이해 -
예제 도메인 정책 검토 -
도메인 정책을 통해 적용되는 설정 및 그 기능 이해
적용 범위
이 모듈은 다음과 같은 제품 및 기술에 적용됩니다.
-
Microsoft Windows Server™ 2003 운영 체제
모듈 사용법
이 모듈은 보안 도메인 인프라를 설계하고 구현하기 위한 방법론을 제공합니다. 먼저 설계 및 구현 프로세스에 대해 설명한 다음 단계별 지침을 제공합니다. 모듈의 설명서는 Active Directory 도메인 환경을 설계하거나 만들 때 사용할 수 있습니다. 그러나 도메인 인프라가 적절하게 사용되고 있는지를 확인하거나 재구성을 고려해 볼 만한 부분은 없는지 확인하는 데도 사용할 수 있어 기존의 인프라에도 적용할 수 있습니다. 이 모듈에는 도메인 정책의 일부로 구현되는 보안 템플릿에 구성된 설정과 관련된 광범위한 정보가 들어 있습니다.
이 모듈을 최대한 활용하려면 다음을 수행합니다.
-
모듈 "Windows 2003 보안 소개"를 읽어 보십시오. 여기에서는 Windows 2003 보안 소개의 목적과 내용을 설명합니다. -
함께 제공된 작업 방법을 사용합니다. 이 모듈에서 참조하는 다음 안내서를 읽어 보십시오.-
"Windows Server 2003에서 조직 구성 단위를 만들고 제어를 위임하는 방법" -
"Windows Server 2003에서 그룹 정책과 보안 템플릿을 적용하는 방법"
-
개요
이 모듈은 도메인 환경이라는 구조를 통해 Windows Server 2003 인프라에 보안을 설정하는 방법을 보여 줍니다.
먼저 도메인 수준에서 보안 설정과 대책에 대해 살펴봅니다. 여기서는 Active Directory 디자인, OU(조직 구성 단위) 디자인, 그룹 정책 디자인 및 관리 그룹 디자인에 대해 자세하게 설명합니다.
또한 "Windows 2003 보안 소개"에서 언급한 레거시, 엔터프라이즈 및 고급 보안 환경에서 Windows Server 2003에 보안을 설정하는 방법도 설명합니다. 이러한 정보는 도메인 인프라 내 레거시 환경에서 고급 보안 환경으로 나아가는 토대와 비전을 제시합니다.
Windows Server 2003에는 보안 상태로 설정된 기본 설정값이 제공됩니다. 이 설명서에서는 꼭 필요한 정보만 전달하기 위해 기본값에서 수정된 설정에 대해서만 설명합니다. 모든 기본 설정에 대한 자세한 내용은 함께 제공된 설명서 Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP를 참조하십시오.
Active Directory 디자인
Active Directory 구조 설계에 대한 자세한 내용만으로도 한 권의 전체 설명서가 만들어질 수 있습니다. Active Directory를 사용하면 응용 프로그램이 분산된 컴퓨팅 환경에서 디렉터리 리소스를 찾고 사용하며 관리할 수 있습니다. 이 섹션에서는 모듈의 나머지 부분을 참조하는 데 도움이 되도록 각 개념에 대해 간략하게 설명합니다.
Active Directory 아키텍처를 만들 때는 해당 환경이 가지고 있는 보안 범위를 세심하게 고려해야 합니다. 조직의 보안 위임 및 구현 일정에 대한 계획을 적절하게 수립하면 훨씬 안전한 Active Directory 디자인을 구현할 수 있게 됩니다. 그리고 나서는 인수 또는 조직 전체적인 개편과 같이 환경을 크게 변경해야 하는 경우에만 디렉터리 디자인을 변경하면 됩니다.
사용자 조직에서 Active Directory 디자인을 이미 구현한 경우에는 이 모듈을 통해 보안과 관련하여 Active Directory가 가지고 있는 장점이나 Active Directory로 인해 발생할 수 있는 문제에 대해 배울 수 있습니다.
Windows Server 2003 디렉터리 범위 설정
Active Directory 내에는 포리스트, 도메인, 사이트 토폴로지 및 사용 권한 위임과 같은 몇 가지 유형의 범위가 있습니다.
이러한 범위는 Active Directory 설치 중 자동으로 설정되지만, 사용 권한 범위 안에 조직의 요구 사항과 정책을 통합해야 합니다. 관리 권한 위임은 조직의 요구 사항에 따라 융통성 있게 적용할 수 있습니다. 예를 들어 보안과 관리 기능 사이에서 적절한 균형을 유지하기 위해 사용 권한 위임 범위를 보안 범위와 관리 범위로 세분화할 수 있습니다.
보안 범위
보안 범위는 한 조직 내에 있는 여러 그룹의 자율성 또는 독립성을 정의하는 데 사용할 수 있습니다. 회사에 설정된 비즈니스 범위를 바탕으로 적절한 보안을 실현하는 것과 비즈니스에 필요한 기본적인 기능을 안정적으로 제공하는 것 사이에서 적절한 균형을 유지한다는 것은 매우 어렵습니다.
이러한 두 요소 사이에서 적절한 균형을 이루려면 관리 권한 위임 및 사용자 환경의 네트워크 아키텍처와 관련된 제반 사항을 결정하기 전에 이로 인해 발생할 수 있는 보안 문제를 면밀하게 검토하여 조직이 직면하게 될 위협을 평가해야 합니다.
포리스트와 도메인 보안 범위
포리스트는 진정한 의미에서 보안 범위입니다. 이 설명서에서는 독립된 포리스트를 만들어 독립적인 도메인을 만들려고 하지 않는 악의적인 관리자 및 기타 위협 요소로부터 사용자 환경을 격리시켜 안전하게 보호할 것을 권장합니다.
도메인은 Active Directory의 관리 범위입니다. 선의의 개인들로 구성된 조직의 경우, 도메인 범위를 사용하여 조직의 각 도메인 내에 있는 서비스와 데이터가 자율적으로 관리되도록 할 수 있습니다.
그러나 보안을 고려해야 할 경우 이와 같은 환경을 조성하기란 그리 간단하지 않습니다. 예를 들어 도메인이 악의적인 도메인 관리자로부터의 공격을 완벽하게 차단하지 못할 수도 있습니다. 이러한 수준의 격리는 포리스트 수준에서만 실현할 수 있습니다.
이 때문에 사용자 조직에서는 현재 Active Directory 디자인 내에 있는 서비스와 데이터에 대한 관리 제어를 세분화하는 것을 고려해야 할 수도 있습니다. Active Directory를 설계하려면 서비스 자율성과 서비스 격리뿐만 아니라 데이터 자율성 및 데이터 격리에 대한 조직의 요구 사항을 완벽하게 이해해야 합니다.
관리 범위
서비스와 데이터를 분리해야 하므로 각각의 필요에 따라 관리 수준도 서로 다르게 정의해야 합니다. 사용자 조직에만 고유한 서비스를 수행하는 관리자뿐만 다음과 같은 관리자를 두는 것이 좋습니다.
서비스 관리자
Active Directory 서비스 관리자는 디렉터리 서비스를 구성하고 배포하는 업무를 담당합니다. 예를 들어 서비스 관리자는 도메인 컨트롤러 서버를 유지 관리하고, 디렉터리 전체의 구성 설정을 제어하며, 서비스를 안정적으로 제공하는 업무를 담당합니다. 조직의 Active Directory 관리자를 서비스 관리자로 생각할 수 있습니다.
Active Directory 서비스 구성은 대개 특성 값에 의해 결정됩니다. 이러한 특성 값은 디렉터리에 저장된 각 개체의 설정에 해당합니다. 따라서 Active Directory의 서비스 관리자는 데이터 관리자도 됩니다. 이 외에도 조직의 필요에 따라 Active Directory 서비스 디자인에 포함시킬 수 있는 다른 서비스 관리자 그룹은 다음과 같습니다.
-
디렉터리 서비스를 전담하는 도메인 관리 그룹
포리스트 관리자는 각 도메인을 관리할 그룹을 선택하는 업무를 담당합니다. 각 도메인의 관리자에게는 높은 수준의 액세스가 부여되므로 정말로 신뢰할 수 있는 사람을 선택해야 합니다. 도메인 관리 업무를 수행하는 그룹은 Domain Admins 그룹과 기본 제공되는 다른 그룹을 통해 도메인을 제어합니다. -
DNS(Domain Name System) 관리를 담당하는 관리자 그룹
DNS 관리자 그룹은 DNS 디자인을 완성하고 DNS 인프라를 관리하는 업무를 담당합니다. DNS 관리자는 DNS Admins 그룹을 통해 DNS 인프라를 관리합니다. -
OU 관리를 담당하는 관리자 그룹
OU 관리자는 그룹이나 개인을 각 OU의 관리자로 지정합니다. 각 OU 관리자는 자신이 할당 받은 Active Directory OU에 저장된 데이터를 관리하는 업무를 담당합니다. 이 그룹은 관리가 위임되는 방법과 해당 OU 내의 개체에 정책이 적용되는 방법을 제어할 수 있습니다. 뿐만 아니라 OU 관리자는 하위 트리를 새로 만들어 자신이 담당하는 OU에 대한 관리 권한을 위임할 수도 있습니다. -
인프라 서버 관리를 담당하는 관리자 그룹
인프라 서버 관리를 담당하는 그룹은 WINS(Windows Internet Name Service), DHCP(Dynamic Host Configuration Protocol) 및 DNS 인프라를 관리하는 업무를 담당합니다. 도메인 관리를 담당하는 그룹이 DNS 인프라를 관리하는 경우도 있는데, 이는 Active Directory가 DNS와 통합되어 도메인 컨트롤러에서 저장 및 관리되기 때문입니다.
데이터 관리자
Active Directory 데이터 관리자는 Active Directory 또는 Active Directory에 참가한 컴퓨터에 저장된 데이터를 관리하는 업무를 담당합니다. 이 관리자는 디렉터리 서비스의 구성이나 배포에 대해서는 관여하지 않습니다. 데이터 관리자는 사용자 조직에서 직접 만든 보안 그룹의 구성원입니다. Windows의 기본 보안 그룹이 사용자 조직의 일부 상황에는 적합하지 않을 수도 있습니다. 따라서 조직은 해당 환경에 가장 적절한 고유의 보안 그룹 명명 표준과 의미를 만들 수 있습니다. 데이터 관리자의 일상적인 업무는 다음과 같습니다.
-
디렉터리에 있는 개체 하위 집합 제어. 데이터 관리자에게는 상속 가능한 특성 수준의 액세스 제어를 통해 디렉터리의 매우 한정적인 부분에 대한 제어 권한은 부여되지만, 서비스 자체를 구성하는 것에 대한 권한은 부여되지 않습니다. -
디렉터리에 있는 구성원 컴퓨터 및 이 컴퓨터에 있는 데이터 관리
참고: 대개의 경우 디렉터리에 저장된 개체의 특성 값이 디렉터리의 서비스 구성을 결정합니다.
지금까지의 내용을 요약해 볼 때, Active Directory 서비스와 디렉터리 구조의 소유자가 포리스트나 도메인 인프라에 참가할 수 있도록 하려면 해당 조직에서 포리스트와 모든 도메인에 있는 서비스 관리자를 모두 신뢰할 수 있어야 합니다. 뿐만 아니라 조직의 보안 프로그램은 관리자에게 적절한 기본 방어책을 제공하는 표준 정책과 절차를 개발해야 합니다. 이 보안 설명서에서 말하는 서비스 관리자에 대한 신뢰란 다음을 의미합니다.
-
서비스 관리자가 조직의 이익을 위해 항상 주의를 기울일 것이라는 점을 확신할 수 있어야 합니다. 포리스트나 도메인 소유자가 조직의 이익에 반하여 악의적으로 행동할 수 있는 사유가 있을 경우 조직은 포리스트나 도메인에 참가하지 않아야 합니다. -
서비스 관리자가 조직에서 규정한 최상의 방법을 따르고 도메인 컨트롤러에 대한 물리적 액세스를 제한할 것이라는 점을 확신할 수 있어야 합니다. -
다음 요인을 포함하는 조직의 경우 이로 인한 위험을 제대로 인식하고 받아들여야 합니다.-
악의적 관리자 ? 신뢰할 수 있는 관리자도 악의적 관리자가 되어 자신이 가지고 있는 시스템 권한을 악용할 수 있습니다. 포리스트 내에 악의적 관리자가 있으면 다른 도메인에 있는 다른 관리자의 SID(보안 식별자)를 쉽게 알아낼 수 있습니다. 그리고 나서 API(응용 프로그래밍 인터페이스) 도구, 디스크 편집기 또는 디버거를 사용하여 이 SID를 자신의 도메인에 있는 계정의 SID 기록 목록에 추가할 수 있습니다. 훔친 SID를 사용자의 SID 기록에 추가한 악의적 관리자는 자신의 도메인과 함께 훔친 SID의 도메인에 대한 관리 권한도 가지게 됩니다. -
강요 받은 관리자 ? 신뢰할 수 있는 관리자도 시스템 보안을 손상시키는 작업을 수행하도록 강요를 받을 수 있습니다. 사용자나 관리자가 시스템 액세스에 필요한 사용자 이름과 암호를 얻게 위해 합법적인 컴퓨터 시스템 관리자에게 사회 공학적 방법을 이용할 수도 있습니다.
-
일부 조직은 악의적 관리자나 조직의 다른 부서로부터 강요를 받은 서비스 관리자로 인해 발생할 수 있는 보안 위험을 인식하고 이를 수용할 수도 있습니다. 이러한 조직은 공유 인프라에 참가하여 얻을 수 있는 공동 작업과 비용 절감이라는 혜택이 이러한 보안 위험을 감수할 만한 가치가 있다고 생각합니다. 그러나 다른 조직은 이러한 보안 위험이 가져올 수 있는 결과가 너무 심각하므로 이를 수용하지 않을 수도 있습니다.
그룹 정책 관리 및 위임을 활용하기 위한 OU 구조
이 설명서는 Active Directory 디자인을 논의하기 위한 것은 아니지만 그룹 정책을 사용하여 조직의 도메인, 도메인 컨트롤러 및 특정 서버 역할을 안전하게 관리하는 방법을 살펴보려면 몇 가지 디자인 정보를 제공할 필요가 있습니다.
OU를 사용하면 사용자와 기타 보안 사용자를 쉽게 그룹화할 수 있을 뿐만 아니라 관리 범위를 효과적으로 구분할 수 있습니다.
뿐만 아니라 OU를 사용하여 서버 역할을 바탕으로 서로 다른 GPO(그룹 정책 개체)를 제공하는 것은 조직의 전반적인 보안 아키텍처의 핵심적인 부분입니다.
관리 위임 및 그룹 정책 적용
OU는 단순히 도메인 내의 컨테이너에 불과합니다. 이러한 각 컨테이너에 고유의 ACL(액세스 제어 목록)을 설정하여 OU 제어 권한을 그룹이나 개인에게 위임할 수 있습니다.
OU를 사용하여 Microsoft Windows NT 운영 체제 4.0의 리소스 도메인과 비슷한 관리 기능을 제공할 수도 있습니다. 다른 사용자가 관리하게 될 리소스 서버 그룹을 포함하는 OU를 만들 수도 있습니다. 이렇게 하면 다른 사용자 그룹은 자신을 도메인의 다른 부분과 격리시킬 필요 없이 특정 OU만 자율적으로 제어할 수 있게 됩니다.
특정 OU에 대한 제어를 위임하는 관리자는 대개 서비스 관리자입니다. 낮은 권한 수준에서 OU를 제어하는 사용자는 대개 데이터 관리자입니다.
관리 그룹
관리자는 관리 그룹을 만들어 일련의 사용자, 보안 그룹 또는 서버를 각각의 컨테이너로 분류하여 자율적으로 관리되도록 할 수 있습니다.
도메인에 있는 인프라 서버를 예로 들어 보겠습니다. 인프라 서버에는 WINS와 DHCP 서비스를 실행하는 서버를 비롯하여 기본 네트워크 서비스를 실행하는 모든 비도메인 컨트롤러가 포함됩니다. 모든 DNS 서버는 도메인 컨트롤러 OU에 있는 도메인 컨트롤러에서 실행되고 있습니다. 이 예에서 DNS 서버는 인프라 서버가 아닙니다.
대개 작업 그룹이나 인프라 관리 그룹이 이들 서버를 유지 관리합니다. OU를 사용하면 이들 서버를 OU, 이 예에서는 인프라 OU로 이동시킨 다음 이 OU에 대한 제어를 해당 관리 그룹에 위임함으로써 서버에 대한 관리 기능을 간편하게 제공할 수 있습니다.
다음 그림은 이러한 OU를 자세히 보여 줍니다.
그림 1
OU 관리 위임
OU 만들기, 관리 그룹 만들기, 그룹으로 사용자 이동 및 제어 위임에 대한 단계별 지침은 "Windows Server 2003에서 조직 구성 단위를 만들고 제어를 위임하는 방법"을 참조하십시오.
이는 관리 세분화를 위해 OU를 사용하는 여러 가지 방법 중 하나입니다. 복잡한 조직의 경우, 이 모듈의 끝에 나오는 "추가 정보" 섹션을 참조하십시오.
위의 절차를 마치면 Infrastructure Admin 그룹이 인프라 OU 및 이 OU 내의 모든 서버와 개체에 대한 완전한 제어 권한을 가지게 됩니다. 이에 따라 Infrastructure Admin 그룹의 관리자는 그룹 정책을 사용하여 서버 역할에 보안을 설정하는 다음 단계의 작업을 수행할 준비가 됩니다.
그룹 정책 적용
그룹 정책과 관리 위임을 사용하여 특정 설정, 권한 및 동작을 OU 내의 모든 서버에 적용할 수 있습니다. 수동 작업 대신 그룹 정책을 사용하면 이후 추가적인 변경이 필요한 경우 많은 서버를 간편하게 업데이트할 수 있습니다.
그룹 정책은 아래 그림에 표시된 순서대로 누적되고 적용됩니다.
그림 2
GPO 적용 순서
위 그림에서 볼 수 있듯이 정책은 해당 컴퓨터의 로컬 컴퓨터 정책 수준부터 적용되기 시작합니다. 그리고 나서 사이트 수준의 GPO가 적용되고 이후에는 도메인 수준의 GPO가 적용됩니다. 서버가 여러 OU에 포함된 경우에는 최상위 수준 OU에 있는 GPO가 가장 먼저 적용됩니다. GPO는 OU 계층 구조의 맨 아래에 이를 때까지 계속해서 적용됩니다. 서버 개체가 포함된 자식 OU 수준의 GPO가 마지막으로 적용됩니다. 그룹 정책을 처리하는 순서는 사용자나 컴퓨터 계정으로부터 가장 멀리 떨어진 최상위 OU에서 시작하여 사용자나 컴퓨터 계정이 실제로 있는 최하위 OU에서 끝납니다.
그룹 정책을 적용할 때는 다음 사항을 항상 염두에 두십시오.
-
여러 개의 GPO를 가지고 있는 그룹 정책 수준에 대해서는 GPO 적용 순서를 설정해야 합니다. 여러 정책에서 지정하는 옵션이 동일한 경우, 마지막 정책이 우선 순위를 가집니다. -
무시 안 함 옵션을 사용하여 그룹 정책을 구성하면 다른 GPO가 특정 GPO를 무시할 수 없게 됩니다.
보안 템플릿
보안 템플릿은 텍스트 기반의 파일입니다. 보안 템플릿 MMC(Microsoft Management Console) 스냅인을 사용하거나 메모장 같은 텍스트 편집기를 사용하여 이 파일을 변경할 수 있습니다. 템플릿 파일의 일부 섹션에는 SDDL(Security Descriptor Definition Language)로 작성된 특정 ACL(액세스 제어 목록)이 있습니다. 보안 템플릿 편집 및 SDDL에 대한 자세한 내용은 Microsoft MSDN을 참조하십시오.
템플릿 관리
인증된 사용자는 기본적으로 그룹 정책 개체에 포함된 모든 설정을 읽을 수 있는 권한을 가지고 있습니다. 따라서 프로덕션 환경에서 사용되는 보안 템플릿은 반드시 그룹 정책을 구현하는 관리자만 액세스할 수 있는 안전한 위치에 저장해야 합니다. 이는 *.inf 파일을 볼 수 없도록 하기 위해서가 아니라 원본 보안 템플릿을 무단으로 변경할 수 없도록 하기 위해서입니다. 이를 위해서는 Windows Server 2003을 실행하는 모든 컴퓨터의 %SystemRoot%\security\templates 폴더에 보안 템플릿을 저장해야 합니다.
이 폴더는 여러 도메인 컨트롤러 간에 복제되지 않습니다. 따라서 템플릿에 대해 버전 관리 문제가 발생하지 않도록 보안 템플릿의 마스터 복사본을 보관할 도메인 컨트롤러를 지정해야 합니다. 이렇게 하면 항상 동일한 템플릿 복사본을 수정할 수 있습니다.
그룹 정책 관리 및 보안 템플릿 가져오기
"Windows Server 2003에서 그룹 정책과 보안 템플릿을 적용하는 방법" 설명서는 http://go.microsoft.com/fwlink/?LinkId=14846
에 있는 보안 템플릿을 이 모듈에서 권장하는 OU 구조로 가져오는 데 필요한 단계별 절차를 자세히 안내합니다. 도메인 컨트롤러에서 이러한 절차를 구현하려면 먼저 해당 환경의 Windows Server 2003 시스템에서 특정 정책 파일(.inf)을 찾아야 합니다.
경고: 이 설명서에 나오는 보안 템플릿은 사용자 환경의 보안을 개선할 수 있도록 설계된 것입니다. 따라서 템플릿을 설치한 후 사용자 조직에서 사용하는 일부 기능이 제대로 작동하지 않을 수도 있습니다. 예를 들어 업무에 중요한 응용 프로그램이 작동하지 않을 수 있습니다.
따라서 프로덕션 환경에서 템플릿을 배포하기 전에 반드시 테스트해 보아야 합니다. 새로운 보안 설정을 적용할 때는 먼저 사용자 환경의 각 도메인 컨트롤러와 서버를 백업해야 합니다. 시스템 상태도 백업에 포함시켜 레지스트리 설정이나 Active Directory 개체를 복원할 수 있도록 해야 합니다.
새로운 도메인 정책을 만들고 관련된 Domain.inf 보안 템플릿을 가져와야 합니다. 도메인 정책은 다른 정책이 덮어쓰지 않도록 무시 안 함 옵션을 사용하여 구성해야 합니다.
그룹 정책을 만들어 적용하고 보안 템플릿을 가져오는 것에 대한 단계별 지침은 "Windows Server 2003에서 그룹 정책과 보안 템플릿을 적용하는 방법"을 참조하십시오.
참고: 이벤트 로그를 보고 그룹 정책이 다운로드되었는지와 서버가 도메인의 다른 도메인 컨트롤러와 통신할 수 있는지를 확인하십시오.
경고: 엔터프라이즈 클라이언트 도메인 정책을 만들 때는 무시 안 함 옵션을 사용하여 도메인 전체에 이 정책을 강제로 적용해야 합니다. 이 설명서에 나오는 그룹 정책 중 이 그룹 정책에만 무시 안 함 옵션을 사용하면 됩니다. 다른 그룹 정책에는 이 옵션을 사용하지 마십시오. 또한 기본 설정으로 되돌려야 할 수도 있으므로 Windows Server 2003 기본 도메인 정책을 수정하지 마십시오.
새 정책에 기본 정책보다 높은 우선 순위를 부여하려면 새 정책을 GPO 링크에서 가장 높은 우선 순위가 부여되는 위치로 가져갑니다.
기본 정책을 수정하여 새 보안 구성을 만들 수도 있지만 처음부터 새 그룹 정책을 만드는 방법도 나름대로 장점이 있습니다. 새로 만든 그룹 정책에 문제가 있으면 간편하게 정책을 비활성화하고 기본 도메인 정책이 다시 제어 권한을 가지도록 할 수 있습니다.
Gpupdate.exe는 배치 파일이나 자동 작업 스케줄러에서 호출하여 자동으로 템플릿을 적용하고 시스템 보안을 분석하는 데 사용할 수 있는 명령줄 도구입니다. 이 도구는 명령줄에서 동적으로 실행할 수도 있습니다.
중요: 이 정책은 조직에서 추가로 만드는 도메인에도 가져와야 합니다. 그러나 루트 도메인 암호 정책이 다른 도메인의 암호 정책보다 엄격한 환경을 흔히 목격할 수 있습니다. 이와 동일한 정책을 사용하게 될 다른 도메인이 해당 도메인과 동일한 비즈니스 요구 사항을 가지고 있는지도 확인해야 합니다. 암호 정책은 도메인 수준에서만 설정할 수 있으므로 일부 사용자의 경우에는 업무상의 이유나 법률적인 이유로 별도의 도메인으로 이동시켜 해당 그룹에 대해서는 더 염격한 보안 정책을 구현해야 하는 경우도 있을 수 있습니다.
이 설명서에 정의된 세 가지 환경에서는 각 환경과 관련된 보안 템플릿과 함께 루트와 자식 도메인에 동일한 정책이 사용되었습니다. 예를 들어 Legacy Client - Domain.inf, Enterprise Client - Domain.inf, High Security - Domain.inf 파일이 각 수준에 사용되었습니다. 기준 정책 및 이후 추가로 정책을 만들 때마다 위와 비슷한 절차에 따라 관련 템플릿을 적용해야 합니다.
GPO 적용 성공 이벤트
모든 설정이 조직의 서버에 올바르게 적용되었는지 직접 확인하는 것 외에도, 도메인 정책이 각 서버에 제대로 다운로드되었음을 관리자에게 알리는 이벤트가 이벤트 로그에 나타나야 합니다. 다음 이벤트 정보가 고유 이벤트 ID 번호와 함께 응용 프로그램 로그에 나타나야 합니다.
종류: 정보
원본 ID: SceCli
이벤트 ID: 1704
설명: 그룹 정책 개체의 보안 정책이 올바르게 적용되었습니다.
자세한 내용은 http://go.microsoft.com/fwlink/events.asp
의 도움말 및 지원 센터를 참조하십시오.
도메인 정책을 적용한 후 몇 분 이내에 이 메시지가 나타나지 않으면 Gpupdate.exe 명령줄 도구를 다시 실행하여 도메인 정책을 적용한 다음 서버를 다시 시작하여 도메인 정책을 강제로 다운로드합니다.
기본적으로 워크스테이션이나 서버에서는 90분마다, 도메인 컨트롤러에서는 5분마다 보안 설정을 새로 고칩니다. 이 시간 동안 변경된 내용이 있으면 이 이벤트가 나타납니다. 보안 설정은 변경 여부에 관계없이 16시간마다 새로 고쳐집니다.
시간 구성
시스템 시간이 정확해야 하고, 조직의 모든 서버가 동일한 시간 원본을 사용해야 합니다. Windows Server 2003 W32Time 서비스는 Active Directory 도메인에서 실행되는 Windows Server 2003과 Microsoft Windows XP - 기반 컴퓨터에 시간 동기화 기능을 제공합니다.
W32Time 서비스는 Windows Server 2003 기반 컴퓨터의 클라이언트 시계를 도메인의 도메인 컨트롤러와 동기화합니다. 이는 NTLMv2뿐만 아니라 Kerberos 버전 5 인증 프로토콜이 제대로 작동하는 데 필수입니다. 정상적인 작동을 위해 Windows Server 제품군의 많은 구성 요소는 동기화된 정확한 시간에 의존합니다. 클라이언트 시계가 동기화되어 있지 않으면 Kerberos v5 인증 프로토콜이 로그온 요청을 침입 시도로 잘못 해석하여 사용자에게 액세스를 거부할 수 있습니다.
시간 동기화가 제공하는 또 다른 중요한 장점은 사용자 조직의 모든 클라이언트에서 이벤트 상관 관계가 형성된다는 점입니다. 사용자 환경의 모든 클라이언트 시계가 동기화되면 모든 클라이언트에서 통일된 순서로 이벤트가 발생하게 되며, 이를 통해 이벤트를 정확하게 분석하여 특정 이벤트가 조직 전체에 영향을 주는지 여부를 파악할 수 있습니다.
Kerberos는 MIT(Massachusetts Institute of Technology)에서 개발한 네트워크 인증 프로토콜입니다. 이 프로토콜은 네트워크에 로그온하려는 사용자의 ID를 인증하고 사용자가 나눈 통신 내용을 비밀 키 암호화를 통해 암호화합니다.
W32Time 서비스는 NTP(Network Time Protocol)를 사용하여 시계를 동기화합니다. Windows Server 2003 포리스트에서는 다음과 같은 방법으로 시간이 동기화됩니다.
-
포리스트 루트 도메인에 있는 PDC(주 도메인 컨트롤러) 에뮬레이터 작업 마스터가 조직의 권한을 보유한 시간 원본입니다. -
포리스트의 다른 도메인에 있는 모든 PDC 작업 마스터는 시간을 동기화하기 위해 PDC 에뮬레이터를 선택할 때 도메인 계층 구조를 따릅니다. -
도메인의 모든 도메인 컨트롤러가 자신의 인바운드 시간 파트너로 PDC 에뮬레이터 작업 마스터를 사용하여 시간을 동기화합니다. -
모든 구성원 서버와 클라이언트 데스크톱 컴퓨터가 인증 도메인 컨트롤러를 자신의 인바운드 시간 파트너로 사용합니다.
정확한 시간을 제공하기 위해 포리스트 루트 도메인의 PDC 에뮬레이터를 외부 NTP 시간 서버와 동기화할 수 있습니다. 그러나 이렇게 하려면 방화벽의 포트를 열어야 합니다. NTP는 UDP 포트 123을 사용합니다. 따라서 외부 NTP 시간 서버와 동기화하기 전에 이로 인해 얻을 수 있는 장점과 구성 변경으로 인해 발생할 수 있는 보안상 위험을 신중하게 비교해야 합니다.
-
내부 시간 원본을 외부 시간 원본과 동기화하려면 다음을 수행합니다.-
명령 프롬프트를 엽니다. -
다음을 입력합니다. 여기에서, PeerList는 원하는 시간 원본을 사용할 DNS 이름 또는 IP(Internet protocol) 주소에 대한 쉼표로 구분된 목록입니다.
w32tm /config /syncfromflags:manual /manualpeerlist:PeerList -
다음을 입력하여 유형을 업데이트합니다.
w32tm /config /update. -
이벤트 로그를 확인합니다. 컴퓨터가 서버에 연결할 수 없으면 절차에 실패하고 이와 관련된 항목이 이벤트 로그에 기록됩니다.
-
이 절차는 대개 내부 네트워크의 권한을 보유한 시간 원본을 정확도가 높은 외부 시간 원본과 동기화할 때 사용합니다. 그러나 이 절차는 Windows XP나 Windows Server 2003 제품군 중 하나를 실행하는 컴퓨터에서만 실행할 수 있습니다.
모든 서버의 시간을 동일한 내부 시간 원본과 동기화하기만 한다면 대개는 외부 원본과 동기화할 필요가 없습니다.
네트워크의 컴퓨터에서 Windows 98이나 Windows NT 4.0 운영 체제를 실행하면 로그온 스크립트에서 다음 명령을 사용하여 컴퓨터 시계를 동기화합니다. 여기에서 <timecomputer>는 네트워크의 도메인 컨트롤러입니다.
net time \\<timecomputer> /set /yes
이 명령을 실행하면 이들 컴퓨터의 시계가 도메인에 있는 다른 컴퓨터의 시계와 동기화됩니다.
참고: 로그 분석에 정확성을 제공하려면 Windows 이외의 운영 체제를 실행하는 네트워크 컴퓨터도 자신의 시계를 Windows Server 2003 PDC 에뮬레이터와 동기화해야 합니다.
기준 서버 역할 조직 구성 단위
조직의 인프라 서버 관리를 보여 주는 앞의 예제는 회사 인프라 내의 다른 서버와 서비스에도 적용할 수 있습니다. 여기서의 목표는 모든 서버에 적용되는 완벽한 그룹 정책을 만드는 동시에 Active Directory 내의 모든 서버가 사용자 환경의 보안 표준을 만족시키도록 하는 데 있습니다.
사용자 환경의 모든 서버에 적용되는 그룹 정책은 조직의 모든 서버에 적용할 수 있는 표준 설정에 대한 일관된 토대를 마련해 줍니다. 뿐만 아니라 조직의 각 서버 유형에 적절한 보안 설정을 제공하기 위해서는 OU 구조를 만들고 그룹 정책을 적용할 때 좀 더 세분화된 분류가 필요합니다. 예를 들어 IIS(Internet Information Server), 파일, 인쇄, IAS(인터넷 인증 서버) 및 인증서 서비스 등의 몇몇 서버 역할에는 고유한 그룹 정책이 필요합니다.
구성원 서버 기준 정책
서버 역할 OU를 만들려면 먼저 기준 정책을 만들어야 합니다. 이렇게 하려면 먼저 기준 보안 템플릿을 만들어 그룹 정책으로 가져옵니다. 이때 지침으로 사용할 수 있는 Enterprise Client - Member Server Baseline.inf 파일은 http://go.microsoft.com/fwlink/?LinkId=14846
에 있습니다. 엔터프라이즈 클라이언트는 "Windows 2003 보안 소개" 모듈에서 설명하는 조직의 호환성 요구 사항을 토대로 다양한 중간 수준 보안을 보여 줍니다.
이 GPO 보안 템플릿을 구성원 서버 OU에 연결합니다. Enterprise Client - Member Server Baseline.inf 보안 템플릿은 기본 그룹 정책의 설정을 구성원 서버 OU와 그 하위 OU에 있는 모든 서버에 적용합니다. 명확한 내용 전달을 위해 이 모듈의 나머지 예제에서는 엔터프라이즈 클라이언트 보안 수준을 사용합니다. 구성원 서버 기준 정책에 대한 내용은 "Windows Server 2003 서버의 구성원 서버 기준 만들기" 모듈을 참조하십시오.
기준 그룹 정책에는 조직 전체의 모든 서버에 필요한 설정을 정의해야 합니다. 기준 그룹 정책은 가능한 제한이 많은 설정으로 구성하고, 이 정책과는 다른 설정이 필요한 서버는 별도의 서버 OU로 분류하십시오.
서버 역할 유형 및 조직 구성 단위
계속해서, 이후 인프라 서버 정책을 변경할 경우 이에 대해 별도의 정책을 만듭니다. 필요한 설정을 Enterprise Client - Infrastructure Server.inf라는 보안 템플릿에 추가하여 인프라 서비스가 제대로 작동하도록 하고 네트워크를 통해 액세스될 수 있도록 만듭니다.
이 GPO 인프라 템플릿을 인프라 OU에 연결합니다. 끝으로, 제한된 그룹 설정을 사용하여 Domain Administrators, Enterprise Administrators, Infrastructure Administrators라는 세 그룹을 "엔터프라이즈 클라이언트: 인프라 서버 정책"에 추가합니다.
이 프로세스는 아래 그림에 잘 나와 있습니다.
그림 3
증분 그룹 정책 구성
앞에서도 설명했지만 이 방법은 GPO를 배포하기 위한 OU 구조를 만드는 여러 가지 방법 중 하나일 뿐입니다. 그룹 정책 구현용 OU를 만드는 것에 대한 자세한 내용은 Microsoft TechNet 문서 "How to Deploy Active Directory"을 참조하십시오. 이 문서는 다음 웹 사이트에서 볼 수 있습니다. http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/AD/windows2000/deploy/depovg/add.asp
이 보안 설명서는 몇 가지 서버 역할을 정의합니다. 다음 표에는 위 프로세스를 따를 경우 이 표에 나오는 각 서버 역할에 대한 보안을 개선하기 위해 만들어진 템플릿도 나옵니다.
표 1: Windows Server 2003 역할
| 서버 역할 | 설명 | 보안 템플릿 |
|---|---|---|
|
Windows Server 2003 도메인 컨트롤러 |
Active Directory 도메인 컨트롤러를 포함하는 그룹 |
Enterprise Client - Domain Controller.inf |
|
Windows Server 2003 구성원 서버 |
도메인의 구성원이며 구성원 서버 OU나 하위 OU에 있는 모든 서버 |
Enterprise Client - Member Server Baseline.inf |
|
Windows Server 2003 파일 서버 |
잠긴 파일 서버를 포함하는 그룹 |
Enterprise Client - File Server.inf |
|
Windows Server 2003 인쇄 서버 |
잠긴 인쇄 서버를 포함하는 그룹 |
Enterprise Client - Print Server.inf |
|
Windows Server 2003 인프라 서버 |
잠긴 DNS, WINS, DHCP 서버를 포함하는 그룹 |
Enterprise Client - Infrastructure Server.inf |
|
Windows Server 2003 IAS 서버 |
잠긴 IAS 서버를 포함하는 그룹 |
Enterprise Client - IAS Server.inf |
|
Windows Server 2003 인증서 서비스 서버 |
잠긴 CA(인증 기관) 서버를 포함하는 그룹 |
Enterprise Client - CA Server.inf |
|
Windows Server 2003 방호 호스트 |
인터넷을 향한 서버를 포함하는 그룹 |
High Security - Bastion Host.inf |
|
Windows Server 2003 IIS 서버 |
잠긴 IIS 서버를 포함하는 그룹 |
Enterprise Client - IIS Server.inf |
모든 증분 템플릿 파일은 구성원 서버 OU 아래에 있는 OU에 적용됩니다. 따라서 각각의 하위 수준 OU가 조직에서 수행하게 될 역할을 정의하려면 이들 OU에 Enterprise Client - Member Server Baseline.inf 파일과 고유의 증분 파일을 모두 적용해야 합니다.
각 서버 역할에 대한 보안 요구 사항은 저마다 다릅니다. 각 역할에 대한 적절한 보안 설정에 대해서는 이후의 모듈에서 자세히 설명합니다.
중요: 이 설명서에서는 Windows Server 2003을 실행하는 컴퓨터가 여기에서 정의한 역할만 수행한다고 가정합니다. 사용자 조직의 서버가 위에 나온 역할과 일치하지 않거나, 다목적 서버일 경우에는 여기에서 정의하는 설정을 지침으로 사용하여 고유의 보안 템플릿을 만드십시오. 그러나 서버가 수행하는 기능이 많을수록 공격을 당하기도 쉽다는 점을 유념해야 합니다.
아래 그림은 위에서 정의한 서버 역할을 지원하는 최종 OU 디자인을 보여 줍니다.
그림 4
OU 디자인 예
OU, GPO 및 관리 그룹 디자인
앞에서 설명한 권장 OU와 그룹 정책은 Windows Server 2003을 실행하는 컴퓨터를 위해 회사의 기존 OU 구조를 다시 구성하는 토대로 사용하거나 새로운 환경을 만드는 기초로 사용할 수 있습니다. 뿐만 아니라 관리자는 자신이 미리 정의해 둔 관리 범위를 사용하여 각 관리 그룹을 만들 수 있습니다. 다음 표에는 각 그룹 및 그룹이 관리하는 OU의 상관 관계가 설명되어 있습니다.
표 2: OU 및 관리 그룹
| OU 이름 | 관리 그룹 |
|---|---|
|
도메인 컨트롤러 |
Domain Engineering |
|
구성원 서버 |
Domain Engineering |
|
인프라 |
Operations |
|
파일 |
Operations |
|
인쇄 |
Operations |
|
IAS |
Domain Engineering |
|
CA |
Enterprise Admins |
|
웹 |
Web Services |
각 관리 그룹은 해당 환경에서 하위 도메인 내의 글로벌 그룹으로 만들어졌습니다.
Domain Engineering은 해당 GPO를 사용하여 각 관리 그룹을 적절한 제한된 그룹에 추가했습니다. 위의 관리 그룹은 각 그룹이 담당하는 업무와 관련된 컴퓨터만 포함된 OU의 Local Administrators 구성원으로만 이루어집니다.
끝으로 도메인 엔지니어는 Domain Engineering 그룹의 관리자만 GPO를 편집할 수 있도록 각 GPO에 사용 권한을 설정했습니다.
기본적으로 새로 만든 OU 구조는 대부분의 보안 설정을 상위 컨테이너에서 상속 받지만, 필요하면 각 OU에 대해 권한이 상속되지 않도록 설정할 수 있습니다.
권한 상속 금지에 대한 단계별 지침은 "Windows Server 2003에서 조직 구성 단위를 만들고 제어를 위임하는 방법"을 참조하십시오.
이전에 관리자가 추가한 그룹 중 필요하지 않은 것은 모두 제거하고 각 서버 역할 OU에 해당하는 도메인 그룹을 추가합니다. Domain Administrators 그룹에 대해서는 모든 권한 설정을 그대로 유지합니다.
이들 OU를 특정 순서로 설정하기 위해 별도의 작업을 수행할 필요는 없지만 이들 사이에 명확한 종속 관계는 존재합니다. 예를 들어 도메인 그룹에 여러 OU에 대한 제어를 위임하려면 먼저 도메인 그룹이 만들어져 있어야 합니다. 다음 목록은 이 작업을 수행하는 권장되는 순서를 보여 줍니다.
- OU 구조를 만듭니다.
- 컴퓨터를 적절한 OU로 이동합니다.
- 관리 그룹을 만듭니다.
- 적절한 도메인 계정을 관리 그룹에 추가합니다.
- 각 OU에 대한 관리 권한을 적절한 도메인 그룹에 위임합니다.
- 그룹 정책을 적용할 OU에 그룹 정책을 만듭니다.
- 필요하면 각 그룹 정책을 다른 OU에도 연결합니다.
- 적절한 보안 템플릿을 각 GPO로 가져옵니다.
- 적절한 도메인 그룹이 GPO를 제어할 수 있도록 각 GPO에 대해 사용 권한을 설정합니다.
- 적절한 도메인 그룹을 각 GPO의 제한된 그룹에 추가합니다.
- 그룹 정책을 테스트하고 수정합니다.
도메인 정책
그룹 정책 보안 설정은 몇 가지 다른 수준에서 적용할 수 있습니다. 위에서 설명한 기준 환경에서는 그룹 정책을 통해 도메인 인프라의 다음 세 계층 수준에서 보안 설정을 적용했습니다.
- 도메인 수준 ? 도메인의 모든 서버에 적용되어야 할 계정 및 암호 정책과 같은 일반적인 보안 요구 사항을 해결합니다.
- 기준 수준 ? 도메인 인프라 내의 모든 서버에 공통된 특정 서버 보안 요구 사항을 해결합니다.
- 역할 수준 ? 특정 서버 역할의 보안 요구 사항을 해결합니다. 예를 들어 인프라 서버의 보안 요구 사항은 Microsoft IIS(인터넷 정보 서비스)를 실행하는 서버의 보안 요구 사항과는 다릅니다.
다음 섹션에서는 도메인 수준 정책에 대해서만 자세히 설명합니다. 여기서 설명하는 대부분의 도메인 보안 설정은 사용자 계정과 암호와 관련된 것입니다. 설정과 권장 사항을 검토하면서 모든 설정은 도메인 범위의 모든 사용자에게 적용된다는 점을 염두에 두십시오.
도메인 정책 개요
그룹 정책을 사용하면 관리자가 표준 네트워크 컴퓨터를 구성할 수 있으므로 매우 편리합니다. GPO를 사용하면 관리자가 도메인의 모든 컴퓨터 또는 도메인 하위 집합에 있는 모든 컴퓨터에서 보안 설정을 동시에 변경할 수 있으므로 GPO는 모든 규모의 조직에서 구성을 관리하는 중요한 솔루션으로 자리잡고 있습니다.
이 섹션에서는 Windows Server 2003의 보안을 개선하는 데 사용할 수 있는 보안 설정에 대해 자세히 설명합니다. 또한 각 설정이 가지는 보안 목표와 이들 목표를 달성하는 데 필요한 구성에 대해 설명하는 표도 제공합니다. 설정은 Windows Server 2003 SCE(보안 구성 편집기) 사용자 인터페이스에 나타나는 범주로 구분됩니다.
그룹 정책을 통해 동시에 변경할 수 있는 보안 변경 작업의 유형은 다음과 같습니다.
- 파일 시스템에 대한 사용 권한 수정
- 레지스트리 개체에 대한 사용 권한 수정
- 레지스트리의 설정 변경
- 사용자 권한 할당 변경
- 시스템 서비스 구성
- 감사 및 이벤트 로그 구성
- 계정 및 암호 정책 설정
계정 정책
암호 정책, 계정 잠금 정책, Kerberos 정책 보안 설정을 포함하는 계정 정책은 도메인 정책 중 이 설명서에서 설명하는 세 가지 환경과 모두 관련이 있는 정책입니다. 암호 정책은 보안 수준이 매우 높은 환경의 암호에 대해 복잡함과 변경 일정을 설정하는 방법을 제공합니다. 계정 잠금 정책을 사용하면 실패한 암호 로그온 시도를 추적하여 필요하면 계정을 잠글 수 있습니다. Kerberos 정책은 도메인 사용자 계정에 사용되며, 티켓 수명 및 적용 등의 Kerberos 관련 설정을 결정합니다.
암호 정책
복잡한 암호를 정기적으로 바꿔서 사용하면 암호 공격이 성공할 가능성이 줄어듭니다. 암호 정책 설정을 통해 암호의 복잡성과 수명을 제어할 수 있습니다. 이 섹션에서는 각 암호 정책 설정에 대해 설명하고, 각 설정이 레거시 클라이언트, 엔터프라이즈 클라이언트 및 고급 보안이라는 세 가지 환경과 어떻게 관련이 되는지를 설명합니다.
암호 길이와 복잡함을 엄격하게 제한한다고 해서 사용자와 관리자가 반드시 강력한 암호를 사용하는 것은 아닙니다. 암호 정책을 사용하면 시스템 사용자가 시스템에서 정의한 복잡한 암호 요구 사항을 따르기는 하겠지만 잘못된 암호 사용 습관을 바꾸려면 강력한 회사 보안 정책이 추가로 필요합니다. 예를 들어 Breakfast!만으로도 복잡한 암호 요구 사항을 모두 충족시킬 수는 있지만, 이런 암호는 알아내기가 그리 어렵지 않습니다.
암호를 만든 사람이 누구인지만 안다면 그 사람이 좋아하는 음식이나 자동차 또는 영화를 통해 암호를 추측할 수 있습니다. 회사 보안 프로그램에서는 빈약한 암호를 보여 주는 포스터를 만들어 정수기나 자동 판매기 같은 공공 장소 근처에 게시함으로써 사용자에게 강력한 암호를 사용하도록 교육하는 방법을 이용해 볼 수도 있습니다. 조직에서는 강력한 암호를 만드는 다음과 같은 보안 지침을 마련해야 합니다.
- 사전의 단어, 일반적이거나 고의로 맞춤법을 틀리게 쓰는 단어, 외국어 등의 사용 금지
- 숫자를 사용한 증분 암호 사용 금지
- 암호 앞이나 뒤에 숫자 추가 금지
- 다른 사람이 사용자 책상을 보고 쉽게 추측할 수 있는 암호(예: 애완견, 스포츠 팀, 가족 구성원의 이름) 사용 금지
- 유행어 사용 금지
- 암호를 단어가 아닌 비밀 코드로 생각하도록 교육
- 키보드에서 두 손을 모두 사용하여 입력해야 하는 암호 사용 강요
- 모든 암호에 대/소문자, 숫자 및 기호 사용 강요
- Alt 키를 누를 때만 생성되는 공백 문자 및 문자 사용 강요
위의 지침은 사용자 조직의 모든 서비스 계정 암호에도 적용되어야 합니다. 다음 섹션에서는 이 설명서에서 정의한 세 가지 보안 환경에 권장되는 암호 정책을 보여 줍니다. 암호 정책 값은 다음 위치에서 설정합니다.
컴퓨터 구성\Windows 설정\보안 설정\계정 정책\암호 정책
최근 암호 기억
표 3: 설정
| 도메인 구성원 기본값 | 레거시 클라이언트 | 엔터프라이즈 클라이언트 | 고급 보안 |
|---|---|---|---|
|
24개 암호 기억됨 |
24개 암호 기억됨 |
24개 암호 기억됨 |
24개 암호 기억됨 |
최근 암호 기억 설정은 이전의 암호를 다시 사용하기 전에 먼저 사용자 계정과 연결되어야 하는 고유한 새 암호의 개수를 결정합니다. 이 값은 0에서 24 사이의 값으로 설정해야 합니다. Windows Server 2003에서는 이 값이 기본적으로 최대값인 24로 설정되어 있습니다. 이 정책 설정을 통해 관리자는 이전의 암호를 반복해서 사용할 수 없도록 하여 보안을 개선할 수 있습니다. 최근 암호 기억 설정을 유효하게 하려면 최소 암호 사용 기간도 함께 구성하여 암호를 즉시 변경할 수 없도록 해야 합니다. 두 옵션을 함께 사용하면 실수로든 고의로든 사용자가 암호를 다시 사용하기가 어렵습니다.
암호 재사용 및 이 설정에 대해 낮은 값을 지정하는 것과 관련된 몇 가지 취약점을 이용하여 사용자는 몇 개의 암호만 가지고 반복해서 계속 사용할 수 있으므로 이 설정은 이 설명서에서 정의하는 모든 환경에서 일관되게 권장됩니다. 또한 레거시 클라이언트가 포함된 환경의 경우 이 값을 최대값으로 설정함으로 해서 발생하는 문제는 아직까지 알려진 바가 없습니다.
최대 암호 사용 기간
표 4: 설정
| 도메인 구성원 기본값 | 레거시 클라이언트 | 엔터프라이즈 클라이언트 | 고급 보안 |
|---|---|---|---|
|
42일 |
42일 |
42일 |
42일 |
최대 암호 사용 기간 설정을 구성하여 사용자 환경의 필요에 맞게 암호가 만료되도록 만들 수 있습니다. 이 설정값의 기본 범위는 1일에서 999일까지입니다. 이 정책 설정은 암호를 알아낸 공격자가 암호가 만료되기 전에 그 암호를 사용하여 네트워크의 컴퓨터에 액세스할 수 있는 기간을 정의합니다. 암호를 정기적으로 변경하는 것은 암호 훼손을 방지하는 한 가지 방법입니다. 이 설정의 기본값은 42일입니다.
시간과 컴퓨터 사용 능력만 있다면 대부분의 암호는 알아낼 수 있습니다. 따라서 암호를 자주 변경할수록 새 암호가 만들어지기 전에 공격자가 이전 암호를 알아내는 데 이용할 수 있는 시간도 줄어들어 공격자의 시도를 무산시킬 수 있습니다. 그러나 이 값을 낮게 설정할수록 지원 부서로의 지원 요청이 늘어날 가능성은 높아집니다. 레거시 클라이언트와 엔터프라이즈 클라이언트 환경의 경우 이 설정값을 높여 보안과 사용상의 편리함 사이에서 균형을 이룰 수 있습니다. 권장 값을 사용하면 암호를 정기적으로 교체하도록 하여 암호 보안을 개선할 수 있을 뿐만 아니라 사용자가 자신도 기억할 수 없을 정도로 자주 암호를 변경해야 할 필요도 없어집니다.
최소 암호 사용 기간
표 5: 설정
| 도메인 구성원 기본값 | 레거시 클라이언트 | 엔터프라이즈 클라이언트 | 고급 보안 |
|---|---|---|---|
|
1일 |
2일 |
2일 |
2일 |
최소 암호 사용 기간 설정은 사용자가 암호를 변경하기 전에 암호를 사용해야 할 최소 일 수를 결정합니다. 이 설정값의 범위는 0일에서 999일까지입니다. 이 값을 0으로 설정하면 암호를 즉시 변경할 수 있습니다. 이 설정의 기본값은 1일입니다.
최대 암호 사용 기간 설정값이 0으로 설정되어 암호가 만료되지 않음을 나타내는 경우가 아니면, 최소 암호 사용 기간 설정값은 최대 암호 사용 기간 설정값보다 작아야 합니다. 최대 암호 사용 기간이 0으로 설정되어 있으면 최소 암호 사용 기간은 0에서 999 사이의 어떤 값으로든 설정할 수 있습니다.
최근 암호 기억 설정을 유효하게 하려면 최소 암호 사용 기간을 0보다 큰 값으로 설정합니다. 최소 암호 사용 기간을 설정하지 않으면 사용자가 이전에 즐겨쓰던 암호가 나올 때까지 반복해서 암호를 바꿀 수 있습니다.
이 설정값을 기본값에서 2 일로 변경합니다. 이는 최근 암호 기억에도 비슷한 낮은 값을 설정하여 두 설정을 함께 사용할 경우 사용자가 만 이틀을 기다려야만 암호를 변경할 수 있기 때문입니다. 최소 암호 사용 기간은 그대로 1일인데 최근 암호 기억은 2개 암호로 설정되어 있으면 사용자는 만 이틀을 기다려야만 이전에 즐겨쓰던 암호를 사용할 수 있게 됩니다. 이 경우 사용자는 암호를 변경할 때까지 만 이틀을 기다려야 합니다.
기본 설정은 이 권장 사항을 따르지 않습니다. 따라서 관리자는 사용자 대신 암호를 지정한 다음 사용자에게 로그온 시 관리자가 정의한 암호를 변경할 것을 요구할 수 있습니다. 최근 암호 기억이 0으로 설정되어 있으면 사용자가 새 암호를 선택할 필요가 없습니다. 이 때문에 최근 암호 기억은 기본적으로 1로 설정되어 있습니다. 이렇게 하면 사용자가 새 암호 24개를 신속하게 설정하여 최근 암호 기억 설정 제한을 무시하는 것을 방지할 수도 있습니다.
최소 암호 길이
표 6: 설정
| 도메인 구성원 기본값 | 레거시 클라이언트 | 엔터프라이즈 클라이언트 | 고급 보안 |
|---|---|---|---|
|
7자 |
8자 |
8자 |
12자 |
최소 암호 길이 설정은 최소한 지정된 문자 개수로 된 암호를 만들도록 요구합니다. 8자 이상의 긴 암호는 짧은 암호보다 강력합니다. 이 정책 설정을 사용하면 사용자가 빈 암호를 사용할 수 없으며 특정 문자 개수로 이루어진 암호를 만들어야 합니다.
이 설정의 기본값은 7자이지만 8자로 된 암호가 권장됩니다. 8자로 된 암호는 일정 수준의 보안을 제공하면서 사용자가 기억하기도 쉽습니다. 최소 암호 길이 설정은 일반적으로 악용되는 사전 공격 및 무단 공격으로부터 시스템을 보호하는 데 중요한 역할을 합니다.
사전 공격은 공격자가 단어 목록에 있는 모든 항목을 모두 사용해서 시도와 실패를 통해 암호를 알아내는 방법입니다. 무단 공격은 가능한 모든 값을 시도하여 암호나 다른 암호화된 텍스트를 알아내는 방법입니다. 무단 암호 공격의 성공 여부는 암호의 길이, 문자 집합의 크기 및 공격자의 컴퓨터 사용 능력에 달려 있습니다.
이 설명서에서는 고급 보안 환경의 경우 암호 길이 값을 12자로 설정할 것을 권장합니다.
암호는 단방향 해시 알고리즘을 통해 전달된 후 SAM(보안 계정 관리자) 데이터베이스나 Active Directory에 저장됩니다. 이런 유형의 알고리즘은 해독이 불가능합니다. 따라서 동일한 단방향 해시 알고리즘을 통해 암호를 실행한 후 그 결과를 비교하는 방법을 통해서만 자신이 올바른 암호를 가지고 있는지를 확인할 수 있습니다. 사전 공격은 암호화 프로세스 동안 전체 사전을 실행시켜 일치하는 항목을 찾아냅니다. 사전 공격은 계정 암호로 "password"나 "guest" 등의 일반적인 단어를 사용하는 사람이 누구인지를 알아낼 수 있는 간단하면서도 매우 효과적인 방법입니다.
암호가 7자리 이하이면 LM 해시의 두 번째 절반은 암호가 8자리보다 짧음을 공격자에게 알려 줄 수 있는 특정 값으로 풀이됩니다. 긴 암호의 경우 공격자가 각 암호에서 하나가 아닌 두 개의 부분을 해독해야 하므로 8자리 이상의 암호를 요구하면 미약한 LM 해시도 강력해집니다 LM 해시의 양쪽 절반을 모두 동시에 공격할 수 있으므로 LM 해시의 두 번째 절반은 길이가 단 1자리이며 밀리초 단위로 무작위 공격에 압도됩니다. 따라서 암호가 대체 문자 집합이 아니라면 이렇게 해도 보안이 완전히 보장되는 것은 아닙니다.
뿐만 아니라 암호 길이가 한 자리씩 길어질 때마다 복잡성은 엄청나게 증가합니다. 예를 들어 7자리 암호로는 267개 또는 1 x 107개의 조합이 가능합니다. 대/소문자를 구분하는 7자리 영문자 암호로는 527개의 조합이 가능합니다. 문장 부호를 사용하지 않는 7자리의 대/소문자를 구분하는 암호로는 627개의 조합이 가능합니다. 초당 100만 번의 시도로 단 48분만에 해독해 냅니다. 8자리 암호로는 268 또는 2 x 1011개의 조합이 가능합니다. 겉으로 보기에는 이 숫자가 아주 놀라울 정도로 큰 수인 것 같지만 많은 암호 해독 유틸리티의 기능인 초당 100만 번의 시도로 가능한 모든 암호를 시도하는 데는 59시간밖에 걸리지 않습니다. 암호 해독에 걸리는 시간은 Alt 문자와 그 밖의 특수 키보드 문자(예: ! 또는 @)를 사용하는 암호에 대해서는 더욱 길어진다는 점을 기억하십시오.
이 때문에 긴 암호 대신 짧은 암호를 사용하는 것은 권장되지 않습니다. 하지만 너무 긴 암호를 사용하면 암호를 잘못 입력하는 경우가 많아져서 그로 인한 계정 잠금과 지원 부서로의 지원 요청이 늘어날 수 있습니다. 뿐만 아니라 지나치게 긴 암호를 사용하면 암호를 잊어버릴 경우를 염려하여 사용자가 암호를 메모해 둘 가능성이 많아지므로 실제로는 조직의 보안이 낮아질 수 있습니다.
암호는 복잡성을 만족해야 함
표 7: 설정
| 도메인 구성원 기본값 | 레거시 클라이언트 | 엔터프라이즈 클라이언트 | 고급 보안 |
|---|---|---|---|
|
사용 |
사용 |
사용 |
사용 |
암호는 복잡성을 만족해야 함 정책 옵션은 모든 새 암호가 강력한 암호에 대한 기본 요구 사항을 만족하는지 확인합니다.
복잡성 요구 사항은 암호가 만들어질 때 적용됩니다. Windows Server 2003 정책 규칙은 직접 수정할 수는 없지만 passfilt.dll의 새 버전을 만들어 다른 규칙 집합을 적용할 수는 있습니다. passfilt.dll의 원본 코드는 Microsoft 기술 자료 문서 151082: "HOW TO: Password Change Filtering & Notification in Windows NT"을 참조하십시오.
실제로는 20자 이상의 암호도 설정할 수 있는데, 20자 이상의 암호는 사용자가 기억하기가 쉬우며 8자 암호보다 더 안전합니다. 예를 들어 I love cheap tacos for $.99과 같은 27자 암호가 있다고 가정해 보십시오. 이러한 유형의 암호는 P@55w0rd 같은 짧은 암호보다 기억하기가 더 쉬울 수도 있습니다.
최소 암호 길이가 8로 설정된 권장 값에는 대문자와 소문자 및 숫자가 포함되어 있어 실제로는 길이를 26자에서 62자로 늘립니다. 이 경우 8자 암호로 2.18 x 1014개의 조합이 가능해집니다. 이 경우 초당 100만 번의 시도로 가능한 모든 조합을 시도하는 데 6.9년이 걸리게 됩니다. 따라서 이러한 설정을 함께 사용하면 무단 공격을 감행하는 것이 매우 어렵습니다. 이 때문에 이 설명서의 세 가지 환경에서는 이들 설정을 조합하여 사용할 것을 권장합니다.
해독 가능한 암호화를 사용하여 암호 저장
표 8: 설정
| 도메인 구성원 기본값 | 레거시 클라이언트 | 엔터프라이즈 클라이언트 | 고급 보안 |
|---|---|---|---|
|
사용 안 함 |
사용 안 함 |
사용 안 함 |
사용 안 함 |
해독 가능한 암호화를 사용하여 암호 저장 보안 설정은 운영 체제에서 해독 가능한 암호화를 사용하여 암호를 저장할지 여부를 결정합니다.
이 정책은 인증을 위해 사용자 암호를 요구하는 프로토콜을 사용하는 응용 프로그램을 지원합니다. 해독 가능한 암호화를 사용하여 저장한 암호는 이 옵션을 사용하지 않고 저장한 암호보다 검색하기가 훨씬 쉬우므로 취약점이 늘어납니다. 따라서 응용 프로그램 요구 사항이 암호 정보 보호의 필요성보다 더 중요한 경우가 아니면 이 정책을 사용해서는 안 됩니다.
원격 액세스나 IAS를 통한 CHAP(Challenge-Handshake 인증 프로토콜)와 IIS의 다이제스트 인증에는 모두 이 정책을 사용해야 합니다.
필요한 경우를 제외하고 사용자가 자신의 암호를 변경하지 못하게 하는 방법
위에서 설명한 암호 정책 외에도 일부 조직에는 모든 사용자를 중앙에서 제어할 수 있는 기능이 필요합니다. 여기서는 필요한 경우를 제외하고 사용자가 자신의 암호를 변경하지 못하게 하는 방법을 설명합니다.
사용자 암호의 중앙 제어는 잘 만들어진 Windows Server 2003 보안 구성의 기초가 됩니다. 그룹 정책을 사용하면 앞에서 살펴본 바와 같이 최소 및 최대 암호 기간을 설정할 수 있습니다. 그러나 암호를 자주 변경하도록 요구하면 사용자가 해당 환경의 암호 기록 설정을 무시할 수 있습니다. 너무 긴 암호를 요구할 경우에도 사용자가 암호를 잊어버려서 지원 부서로의 지원 요청을 더 많이 하게 될 수 있습니다.
사용자는 최소 및 최대 암호 사용 기간 설정 사이의 기간 중 자신의 암호를 변경할 수 있습니다. 그러나 고급 보안 환경 디자인의 경우 최대 암호 사용 기간 설정에 구성된 42일이 지난 후 운영 체제에서 메시지를 표시할 때만 암호를 변경해야 합니다. 사용자가 자신의 암호를 변경하지 못하도록 하려면(필요한 경우는 제외) Ctrl+Alt+Delete를 누르면 나타나는 Windows 보안 대화 상자에서 암호 변경 옵션을 사용하지 못하도록 만듭니다.
그룹 정책을 사용하여 전체 도메인에 대해 이 구성을 구현하거나 레지스트리를 편집하여 한 명 이상의 특정 사용자에 대해 구현할 수 있습니다. 이 구성에 대한 자세한 지침을 보려면 Microsoft 기술 자료 문서 324744, "HOWTO: Windows Server 2003에서 필요한 경우를 제외하고 사용자가 암호를 변경하지 못하게 하기”를 참조하십시오. 이 문서는 http://support.microsoft.com/default.aspx?kbid=324744에서 볼 수 있습니다.
계정 잠금 정책
계정 잠금 정책은 지정한 기간 내에 로그온 시도가 여러 차례 실패하면 사용자 계정을 잠그는 Windows Server 2003 보안 기능입니다. 허용된 시도 횟수와 기간은 보안 정책 잠금 설정에 대해 구성된 값을 기반으로 합니다. 잠겨진 계정에는 사용자가 로그온할 수 없습니다. Windows Server 2003이 로그온 시도를 추적하므로 미리 설정된 로그인 실패 횟수에 도달하면 계정을 사용하지 못하도록 하여 이러한 유형의 잠재된 공격에 대응하도록 서버 소프트웨어를 구성할 수 있습니다.
Windows Server 2003에서 계정 잠금 정책을 구성할 때는 관리자가 시도 및 기간 변수에 대해 어떤 값이라도 설정할 수 있습니다. 그러나 다음 시간 후 계정 잠금 수를 원래대로 설정 값이 계정 잠금 기간 값보다 크면 Windows Server 2003이 계정 잠금 기간 값을 다음 시간 후 계정 잠금 수를 원래대로 설정 값과 동일하게 자동으로 조정합니다. 또한 계정 잠금 기간 값이 다음 시간 후 계정 잠금 수를 원래대로 설정에 구성한 값보다 작으면 Windows Server 2003이 다음 시간 후 계정 잠금 수를 원래대로 설정 값을 계정 잠금 기간 값과 동일하게 자동으로 조정합니다. 따라서 계정 잠금 기간을 정의한 경우 다음 시간 후 계정 잠금 수를 원래대로 설정 값은 계정 잠금 기간 값보다 작거나 같아야 합니다.
Windows Server 2003은 보안 정책의 값 설정 충돌을 피하기 위해 이러한 작업을 수행합니다. 관리자가 다음 시간 후 계정 잠금 수를 원래대로 설정을 계정 잠금 기간 값보다 큰 값으로 구성하면 계정 잠금 기간 설정에 대해 구성한 값 적용이 먼저 만료되므로 사용자가 네트워크에 다시 로그온하는 것이 가능해집니다. 그러나 다음 시간 후 계정 잠금 수를 원래대로 설정 값은 계속해서 카운트됩니다. 이 때문에 계정 잠금 임계값은 최대 세 번의 잘못된 시도로 유지되고 사용자는 로그온할 수 없게 됩니다.
이러한 상황을 막기 위해 Windows Server 2003은 다음 시간 후 계정 잠금 수를 원래대로 설정 값을 계정 잠금 기간 값과 같도록 자동으로 다시 설정합니다.
이러한 보안 정책 설정은 공격자가 사용자 암호를 알아내지 못하도록 도와 주며 사용자 네트워크 환경이 공격을 받는 가능성을 줄여 줍니다. 다음에 나오는 값은 아래 위치에 있는 도메인 그룹 정책에서 구성할 수 있습니다.
컴퓨터 구성\Windows 설정\보안 설정\계정 정책\계정 잠금 정책
계정 잠금 기간
표 9: 설정
| 도메인 구성원 기본값 | 레거시 클라이언트 | 엔터프라이즈 클라이언트 | 고급 보안 |
|---|---|---|---|
|
정의되지 않음 |
30분 |
30분 |
15분 |
계정 잠금 기간 설정은 계정이 잠기고 사용자가 로그온을 다시 시도할 수 있게 될 때까지의 시간을 결정합니다. 잠겨진 계정이 사용 불가능한 상태로 유지될 시간을 분으로 지정하여 이 설정이 이루어집니다. 계정 잠금 기간 설정값을 0으로 설정하면 관리자가 해당 계정의 잠금을 해제할 때까지 계정이 잠겨진 상태로 유지됩니다. 이 설정에 대한 Windows Server 2003 기본값은 정의되지 않음입니다.
이 설정값을 자동으로 잠금 해제하지 않음으로 구성하는 것이 좋은 방법처럼 보일 수도 있지만 그렇게 할 경우 지원 부서에 실수로 잠겨진 계정의 잠금 해제를 요청하는 지원 요청이 늘어날 수 있습니다. 이 설정값을 레거시 클라이언트와 엔터프라이즈 클라이언트 환경에 대해서는 30분으로 설정하고 고급 보안 수준에 대해서는 15분으로 설정하면 DoS(Denial of Service) 공격이 발생할 경우 작업 오버헤드가 줄어듭니다. DoS 공격에서 공격자는 악의적으로 조직의 모든 사용자에 대해 잘못된 로그온을 여러 번 시도하여 계정이 잠기도록 합니다. 이 설정값은 사용자의 계정이 잠겨진 경우 지원 부서에 문의하지 않고 기다릴 수 있는 시간인 30분 후 다시 로그온할 수 있는 기회를 사용자에게 제공합니다.
이 설명서에서 권장하는 값은 고급 보안 환경의 경우 15분입니다.
계정 잠금 임계값
표 10: 설정
| 도메인 구성원 기본값 | 레거시 클라이언트 | 엔터프라이즈 클라이언트 | 고급 보안 |
|---|---|---|---|
|
0번의 잘못된 로그온 시도 |
50번의 잘못된 로그온 시도 |
50번의 잘못된 로그온 시도 |
10번의 잘못된 로그온 시도 |
계정 잠금 임계값 설정은 계정이 잠기기 전에 사용자가 해당 계정에 로그온하려고 시도할 수 있는 횟수를 결정합니다.
권한이 있는 사용자도 암호를 잘못 입력하거나 다른 컴퓨터에 로그온되어 있는 동안 한 컴퓨터에서 암호를 변경하여 계정이 잠길 수 있습니다. 컴퓨터에서 잘못된 암호로 계속해서 사용자를 인증하려고 시도할 경우 인증에 사용하는 암호가 틀리므로 결국에는 사용자 계정이 잠깁니다. 권한이 부여된 사용자가 잠기지 않도록 하려면 계정 잠금 임계값을 더 큰 값으로 설정하십시오.
이 설정값이 구성되어 있을 때와 구성되어 있지 않을 때 모두 보안 문제가 발생할 수 있으므로 각각의 가능성에 대해 뚜렷한 대책을 정의해야 합니다. 조직에서는 완화시켜야 할 확인된 위협과 위험을 토대로 이 설정을 구성해야 할지 그렇지 않아야 할지를 결정해야 합니다.
-
계정 잠금을 방지하려면 계정 잠금 임계값을 0으로 설정합니다. 계정 잠금 임계값을 0으로 설정하면 사용자가 실수로 자신의 계정을 잠글 수 없게 되며, 사용자 조직의 계정을 고의로 잠그는 것을 목표로 하는 DoS 공격을 예방할 수 있으므로 지원 부서로의 요청을 줄일 수 있습니다. 그러나 무단 공격까지 막을 수는 없으므로 다음 두 조건을 모두 충족하는 경우에만 계정 잠금 임계값을 0으로 설정하는 것이 좋습니다. - 암호 정책이 모든 사용자에게 8자리 이상으로 구성된 복잡한 암호를 사용할 것을 요구합니다.
- 해당 환경에서 연속적으로 계정 잠금이 발생할 경우 관리자에게 경고하기 위해 강력한 감사 메커니즘이 적절히 사용되고 있습니다. 예를 들어 감사 솔루션은 "로그온 실패. 로그온하려고 할 때 계정이 잠겨 있었습니다."를 나타내는 보안 이벤트 539를 모니터링해야 합니다. 이 이벤트는 로그온 시도가 이루어졌을 때 계정이 잠겼음을 의미합니다. 그러나 이벤트 539는 계정 잠금에 대해서만 알려 주며, 실패한 암호 추정 시도에 대해서는 알려 주지 않습니다. 따라서 관리자는 잘못된 암호로 로그온하려는 일련의 시도가 있는지도 모니터링해야 합니다.
-
이 조건이 충족되지 않은 경우, 무단 암호 공격 시에는 계정이 잠기도록 하면서 사용자가 실수로 암호를 여러 번 잘못 입력할 때는 계정이 잠기지 않도록 할 수 있는 충분히 큰 값으로 계정 잠금 임계값 설정을 구성하는 방법을 사용할 수 있습니다. 이와 같은 경우에는 잘못된 로그온 시도 수를 50과 같은 높은 숫자로 설정하여 적절한 보안과 사용상의 편리함을 모두 제공할 수 있습니다. 이 설정값은 부주의로 인한 계정 잠금을 막아 주며 지원 부서로의 지원 요청을 줄여 주지만 위에서 설명한 바와 같이 DoS 공격을 방지하지는 않습니다.
이 설명서에서 권장하는 잘못된 로그온 시도 값은 고급 보안 환경의 경우 10입니다.
다음 시간 후 계정 잠금 수를 원래대로 설정
표 11: 설정
| 도메인 구성원 기본값 | 레거시 클라이언트 | 엔터프라이즈 클라이언트 | 고급 보안 |
|---|---|---|---|
|
정의되지 않음 |
30분 |
30분 |
15분 |
다음 시간 후 계정 잠금 수를 원래대로 설정은 계정 잠금 임계값을 0으로 다시 설정하고 계정 잠금을 해제하기 전까지의 시간을 결정합니다. 계정 잠금 임계값을 정의한 경우 이 시간은 계정 잠금 기간 설정값보다 작거나 같아야 합니다.
이 설명서에서 언급하는 다른 값들과 마찬가지로 이 설정값도 기본값으로 두는 것이 좋습니다. 이 값을 너무 긴 간격으로 구성하면 사용자 환경이 계정 잠금 DoS 공격을 받을 가능성이 높아지게 됩니다. 계정 잠금을 다시 설정하도록 결정된 정책이 없으면 관리자가 모든 계정의 잠금을 직접 해제해야 합니다. 반대로, 이 설정이 적당한 시간 값으로 구성되어 있으면 모든 계정의 잠금이 자동으로 해제될 때까지 정해진 기간 동안 사용자가 잠겨집니다. 권장 설정값 30분은 사용자가 지원 부서에 문의하지 않고 기다릴 수 있는 기간을 정의합니다. 이 설정값을 기본값으로 유지하고, 다른 설정값은 이 설명서에서 권장하는 값으로 변경하지 않은 경우에만 계정 잠금 DoS 공격을 받게 될 가능성이 있습니다. 수준을 낮추면 DoS(Denial of Service) 공격 중 발생하는 작업 오버헤드가 줄어듭니다. DoS 공격에서 공격자는 악의적으로 조직의 모든 사용자에 대해 잘못된 로그온을 여러 번 시도하여 계정이 잠기도록 합니다.
이 설명서에서 권장하는 값은 고급 보안 환경의 경우 15분입니다.
Kerberos 정책
Kerberos 정책은 도메인 사용자 계정에 사용되며 티켓 수명 및 적용 등의 Kerberos 버전 5 프로토콜 관련 설정을 결정합니다. 로컬 컴퓨터 정책에는 Kerberos 정책이 존재하지 않습니다. Kerberos 티켓의 수명을 줄이면 공격자가 암호를 알아낸 다음 올바른 사용자 계정으로 가장할 위험을 줄일 수 있습니다. 그러나 이 정책을 유지 관리하게 되면 권한 부여에 따르는 오버헤드가 늘어납니다. 대부분의 환경에서는 이러한 정책의 기본값을 변경하지 않아야 합니다. Kerberos 설정은 기본 도메인 정책에 포함되어 기본 도메인 정책으로 적용되므로 이 설명서에서 함께 제공하는 보안 템플릿에는 관련 설정이 포함되어 있지 않습니다.
이 설명서에서는 기본 Kerberos 정책을 변경하는 것에 대해서는 전혀 설명하지 않습니다. 이러한 설정에 대한 자세한 내용은 함께 제공된 설명서 Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP를 참조하십시오.
보안 옵션
계정 정책은 기본 도메인 정책에 정의되어야 하며, 해당 도메인을 관리하는 도메인 컨트롤러에 의해 적용되어야 합니다. 도메인 컨트롤러는 계정 정책을 항상 기본 도메인 정책 GPO에서 가져옵니다. 이는 도메인 컨트롤러가 포함된 OU에 적용되는 다른 계정 정책이 있는 경우에도 마찬가지입니다.
보안 옵션에는 계정 정책과 비슷한 역할을 하며, 도메인 수준에서 고려해야 할 두 가지 정책이 있습니다. 다음 표에 나오는 도메인 그룹 정책 값은 아래 위치에서 구성할 수 있습니다.
컴퓨터 구성\Windows 설정\보안 설정\로컬 정책\보안 옵션
Microsoft 네트워크 서버: 로그온 시간이 만료되면 클라이언트 연결 끊기
표 12: 설정
| 도메인 구성원 기본값 | 레거시 클라이언트 | 엔터프라이즈 클라이언트 | 고급 보안 |
|---|---|---|---|
|
정의되지 않음 |
사용 |
사용 |
사용 |
Microsoft 네트워크 서버: 로그온 시간이 만료되면 클라이언트 연결 끊기 보안 설정은 사용자 계정의 유효 로그온 시간이 아닐 때 로컬 컴퓨터에 연결된 사용자의 연결을 끊을지 여부를 결정합니다. 이 설정은 SMB(서버 메시지 블록) 구성 요소에 영향을 미칩니다. 이 정책을 사용하면 SMB 서비스를 사용하는 클라이언트의 로그온 시간이 만료될 경우 해당 클라이언트 세션 연결이 강제로 끊어지게 됩니다. 이 정책을 사용하지 않으면 클라이언트의 로그온 시간이 만료된 후에도 한 번 연결된 클라이언트 세션은 계속될 수 있습니다. 이 설정을 사용할 때는 반드시 네트워크 보안: 로그온 시간이 만료되면 강제로 로그오프 설정도 함께 사용해야 합니다.
사용자 조직에서 사용자의 로그온 시간을 구성했으며 따라서 이 정책을 사용하는 경우, 자신의 로그온 시간이 아닐 때 네트워크 리소스에 액세스할 수 없는 사용자가 이전에 허용된 시간 동안 연결한 세션을 통해 계속에서 해당 리소스를 사용할 수 있게 됩니다.
조직에서 로그온 시간을 사용하지 않는다면 이 설정을 사용해도 효과가 없습니다. 로그온 시간을 사용하면 사용자 로그온 시간이 만료될 경우 기존 사용자 세션이 강제로 종료됩니다.
네트워크 액세스: 익명 SID/이름 변환 허용
표 13: 설정
| 도메인 구성원 기본값 | 레거시 클라이언트 | 엔터프라이즈 클라이언트 | 고급 보안 |
|---|---|---|---|
|
정의되지 않음 |
사용 안 함 |
사용 안 함 |
사용 안 함 |
네트워크 액세스: 익명 SID/이름 변환 허용 설정은 익명 사용자가 다른 사용자의 SID를 요청할 수 있는지 여부를 결정합니다.
도메인 컨트롤러에 대해 이 정책을 사용하면 관리자의 SID 특성을 알고 있는 사용자가 마찬가지로 이 정책을 사용하는 컴퓨터에 연결하여 해당 SID로 관리자의 이름을 알아낼 수 있습니다. 그런 다음 해당 계정 이름을 사용하여 암호 추측 공격을 시작할 수 있습니다. 구성원 컴퓨터의 경우 기본 설정이 사용 안 함이므로 아무런 영향을 받지 않습니다. 그러나 도메인 컨트롤러의 기본 설정은 사용입니다. 이 설정을 사용하지 않으면 다음과 같은 경우 레거시 시스템이 Windows Server 2003 기반 도메인과 통신하지 못하게 될 수 있습니다.
- Windows NT 4.0 기반 원격 액세스 서비스 서버
- IIS의 웹 응용 프로그램이 기본 인증을 허용하도록 구성되어 있으면서 동시에 익명 액세스를 사용하지 않을 경우에는 기본 제공된 Guest 사용자 계정이 해당 웹 응용 프로그램에 액세스할 수 없습니다. 또한 기본 제공된 Guest 사용자 계정 이름을 다른 이름으로 바꾸면 새 이름을 사용하여 웹 응용 프로그램에 액세스할 수 없습니다.
- Windows NT 3.x 또는 Windows NT 4.0 도메인에 있는 Windows 2000 기반 컴퓨터에서 실행되는 원격 액세스 서비스 서버
네트워크 보안: 로그온 시간이 만료되면 강제로 로그오프
표 14: 설정
| 도메인 구성원 기본값 | 레거시 클라이언트 | 엔터프라이즈 클라이언트 | 고급 보안 |
|---|---|---|---|
|
사용 안 함 |
사용 |
사용 |
사용 |
네트워크 보안: 로그온 시간이 만료되면 강제로 로그오프 설정은 사용자 계정의 유효한 로그온 시간을 초과하여 로컬 컴퓨터에 연결되어 있는 사용자의 연결을 끊을지 여부를 결정합니다. 이 설정은 SMB 구성 요소에 영향을 미칩니다.
이 정책을 사용하면 클라이언트의 로그온 시간이 만료될 경우 SMB 서버에 연결된 클라이언트 세션의 연결이 강제로 끊어지며, 예약된 다음 액세스 시간까지는 시스템에 로그온하지 못하게 됩니다. 이 정책을 사용하지 않으면 설정된 클라이언트의 로그온 시간이 만료된 후에도 해당 클라이언트 세션이 유지됩니다. 이 설정을 도메인 계정에 적용하려면 기본 도메인 정책에서 설정을 정의해야 합니다.
요약
사용자 환경을 보호하기 위한 수단으로 포리스트, 도메인 및 OU(조직 구성 단위)를 검토할 때 고려해야 할 몇 가지 디자인 요소가 있습니다.
조직에 필요한 자율성과 독립성 요구 사항을 면밀히 검토하여 이를 문서화하는 것은 매우 중요합니다. 행정의 자율성, 운영의 독립성 및 합법적이거나 규제를 위한 격리 등은 복잡한 포리스트 디자인을 고려하게 만드는 요소입니다.
서비스 관리자를 적절히 관리하는 방법을 고안하는 것도 매우 중요합니다. 악의적인 서비스 관리자는 조직에 큰 위험을 가져올 수 있습니다. 간단한 예를 들면, 악의적인 도메인 관리자는 포리스트의 모든 도메인에 있는 데이터에 액세스할 수 있습니다.
조직의 포리스트 또는 도메인 디자인을 변경하는 것이 쉽지는 않겠지만 이로 인해 발생할 수 있는 보안 위험에 대비할 필요가 있습니다. 또한 조직에서 OU 배포를 계획할 때는 서비스 관리자와 데이터 관리자 모두에 대한 필요성을 고려해야 합니다. 이 모듈에서는 엔터프라이즈 환경에서 다양한 서버 역할을 지속적으로 관리하는 데 효과적으로 사용할 수 있는 OU 모델을 만드는 것에 대해 자세히 설명했습니다.
그리고 끝으로, 조직의 모든 도메인에 사용되는 설정을 검토하는 것이 얼마나 중요한지에 대해서도 언급했습니다. 각 도메인에는 암호, 계정 잠금, Kerberos 버전 5 인증 프로토콜 등으로 이루어진 정책을 한 가지만 구성할 수 있습니다. 다른 암호나 계정 잠금 설정은 구성원 서버에 있는 로컬 계정에만 영향을 줍니다. 따라서 도메인의 모든 구성원 서버에 적용되는 설정을 구성한 다음 이를 통해 조직 전체에 적절한 수준의 보안을 제공하는 계획을 수립해야 합니다.
추가 정보
다음은 이 설명서 및 제품의 출시 당시 도메인 인프라 구축 및 Windows Server 2003와 관련하여 작성된 최신 자료입니다.
Windows 2000, Windows XP 및 Windows Server 2003의 계정 및 로컬 정책에 대한 자세한 내용은 다음 사이트를 참조하십시오. http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsnetserver/proddocs/server/sag_sceacctpols.asp
Microsoft 보안 및 개인 정보에 대한 자세한 내용은 http://www.microsoft.com/korea/security/를 참조하십시오.
10가지 불변의 보안 법칙에 대한 자세한 내용은 http://www.microsoft.com/technet/treeview/default.asp?url=/technet/columns/security/essays/10imlaws.asp
를 참조하십시오.
Active Directory의 관리 위임과 관련된 디자인 고려 사항에 대한 자세한 내용은 다음 사이트를 참조하십시오. http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ad/windows2000/plan/addeladm.asp
시간 서버 구성에 대한 자세한 내용은 Microsoft 기술 자료 문서 "Windows 2000에서 권한을 보유한 시간 서버를 구성하는 방법"을 참조하십시오. 이 문서는 다음 사이트에서 볼 수 있습니다.
http://support.microsoft.com/default.aspx?scid=216734
네트워크 액세스 및 SID/이름 변환 허용에 대한 자세한 내용은 다음 사이트를 참조하십시오.
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/server/623.asp
네트워크 보안 및 로그온 시간이 만료되면 강제 로그오프에 대한 자세한 내용은 다음 사이트를 참조하십시오.
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/server/566.asp
Guest Account Cannot be Used When Anonymous Access Is Disabled
http://support.microsoft.com/default.aspx?scid=kb;en-us;251171
페이지 위쪽
