 TechNet Magazine March 2008

TechNet Magazine March 2008

Special Coverage: Windows Server 2008: Windows Server 2008 커널 변경 사항

안정성, 성능 및 확장성을 높이는 Windows Server 2008 커널의 핵심 변경 사항을 자세히 살펴봅니다. 그런 다음, Windows Server 2008에서 스레드 풀을 효과적으로 이용하고, 하드웨어 오류에서 효율적으로 복구하고, Hyper-V로 가상화를 향상시키는 방법에 대해 알아봅니다.

Mark Russinovich Special Coverage: Windows Server 2008: Active Directory 도메인 서비스의 새로운 기능

Windows Server 2008에서는 Active Directory 도메인 서비스의 일부 기능이 크게 개선되었습니다. 읽기 전용 도메인 컨트롤러와 Windows Server Core가 사용자 환경에서 보안을 어떻게 강화하는지, 새로운 서버 관리자와 개선된 백업 기능으로 관리가 얼마나 간단해지는지, 새로운 감사 도구가 규정 준수에 어떻게 도움이 되는지 알아보십시오.

Gil Kirkpatrick Special Coverage: Windows Server 2008: IIS 7.0 시작

IIS 7.0에는 한 편의 기사로는 모두 다룰 수 없을 정도로 많은 기능이 새로 추가되었습니다. IIS 7.0은 IIS 6.0의 견고한 보안 중심 설계를 기반으로 만들어졌으며 플랫폼의 관리 효율성과 확장성을 크게 개선한 향상된 기능을 제공합니다. 이 문서를 통해 IIS 7.0의 가장 중요한 몇 가지 변경에 대해 간략히 알아봅니다.

Isaac Roybal Special Coverage: Windows Server 2008: Windows Server 2008의 정책 기반 네트워크 액세스

보안에 영향을 주지 않으면서 네트워크 액세스가 필요한 사용자에게 액세스를 허용하려면 어떻게 해야 할까요? 고급 보안이 포함된 Windows 방화벽이나 네트워크 액세스 보호 같은 Windows Server 2008의 새로운 기술을 통해 이러한 목적을 달성하는 데 도움이 되는 정책 기반 방식을 구현하는 방법을 살펴보십시오.

Ian Hameroff and Amith Krishnan Special Coverage: Windows Server 2008: 서버 관리자를 사용하여 역할 구성

DNS 서버가 인쇄 서버일 필요는 없습니다. 보안 및 관리 효율성 향상을 위해 Windows Server 2008에서 취하는 한 가지 접근 방법은 꼭 필요한 도구와 서비스만 손쉽게 설치할 수 있도록 서버 역할을 단순화하는 것입니다. 이 기사에서는 서버 관리자를 사용하여 역할을 구성하고 배포를 단순화하는 방법을 소개합니다.

Byron Hynes Special Coverage: Windows Server 2008: System Center를 사용하여 Windows Server 2008 배포

이전에는 서버 관리자가 CD 또는 DVD를 사용하여 직접 Windows Server를 설치한 다음 몇 시간 동안 해당 서버를 구성하곤 했습니다. 그러나 이제 System Center Configuration Manager 2007 및 새로운 Microsoft Deployment Toolkit을 통해 서버 관리자도 데스크톱 관리자가 지난 수년간 배포 자동화에 사용해온 것과 동일한 도구를 사용할 수 있게 되었습니다.

Tim Mintner Special Coverage: Windows Server 2008: Windows Server 2008의 감사 및 규정 준수

이제 변경 감사는 IT 부서의 핵심 업무가 되었습니다. 변경 감사는 분산된 환경에서 시스템과 데이터를 파악하고 관리하기 위한 가장 기본적인 작업입니다. 이 기사에서는 변경 감사의 일반적인 문제점, 규정 준수 및 규제의 전반적인 추세, 감사의 몇 가지 기본 사항 및 포괄적인 감사 전략을 만드는 방법에 대해 설명합니다.

Rob Campbell and Joel Yoker From the Editor: Windows Server 2008 일견

Joshua Hoffman Letters: 독자의 목소리

Toolbox: IT 전문가를 위한 새로운 제품

Greg Steen Utility Spotlight: Windows Server 로고 인증

ISV와 고객이 응용 프로그램 호환성을 보다 쉽게 파악할 수 있도록 Microsoft는 "Works with Windows Server 2008" 프로그램을 개발했습니다. 본 기사에서는 이 프로그램에서 제공하는 무료 지원 테스트 도구를 소개하고 이러한 도구를 사용하여 응용 프로그램이 안정적인 환경을 제공하는지 확인하는 방법을 설명합니다.

Venkat Krishnamachari The Cable Guy: ISATAP로 인트라넷을 IPv6으로 마이그레이션

IPv6으로 이전할 준비가 되었습니까? 이번 달 The Cable Guy 칼럼에서는 IPv6 전환 기술을 사용하여 IPv6 연결을 구현하고 IPv6 지원 인트라넷으로 마이그레이션하는 방법을 설명합니다.

Joseph Davies Windows PowerShell: 진행률 보고서

사용자의 주의를 끌기 위해서든 혹은 다른 목적을 위해서든 스크립트에 상태 피드백을 제공하는 것은 좋은 생각입니다. 이 기사에서는 Windows PowerShell에서 상태 피드백을 제공할 때 알아야 할 모든 내용을 소개합니다.

Don Jones Hey, Scripting Guy!: Scripting Guy가 즐기는 셸 게임

Scripting Guy로부터 몇 가지 스크립트와 셸 개체를 사용하여 파일을 마지막으로 수정한 날짜를 변경하는 방법을 배워보십시오.

The Microsoft Scripting Guys Security Watch: Windows Server 2008에서 SCW 사용

Windows Server 2008의 새로운 서버 관리자 도구에 대해 들어 보았겠지만 SCW(보안 구성 마법사)도 계속 사용할 수 있습니다. SCW를 계속 사용해야 하는 이유에 대해 알아보겠습니다.

Jesper M. Johansson The Desktop Files: 씬 클라이언트 활용

수많은 씬 클라이언트가 만들어졌다가 사라지지만 이러한 씬 클라이언트가 유용하게 사용될 수 있는 시나리오는 언제나 존재합니다. 오늘날에는 키오스크와 웹 검색 기능만 필요로 하는 환경에 사용됩니다. 여기서는 오래된 하드웨어를 클라이언트 응용 프로그램과 함께 재활용하여 비용을 절감하는 방법을 살펴보겠습니다.

Wes Miller Field Notes: IT 2.0 준비

이 기사에서는 앞으로 IT 부문이 당면하게 될 과제를 해결하는 데 있어서 이전 경험의 교훈이 주는 중요성을 살펴봅니다.

Romi Mahajan Windows Confidential: 베타에서 RC로

Raymond Chen이 최종 릴리스 전의 명명 규칙과 관련하여 흥미로운 뒷이야기를 들려 줍니다. 그리고 여러 회사에서 베타 테스트의 중요성을 인식해 줄 것을 당부합니다.

Raymond Chen


 Special Coverage: Windows Server 2008: Windows Server 2008 커널 변경 사항
Special Coverage: Windows Server 2008 Mark Russinovich

Windows Server 2008 커널 변경 사항
한 눈에 보기:
  • 메모리 관리 및 SMB 2.0
  • NTFS 자체 치유, Windows 하드웨어 오류 아키텍처 및 드라이버 확인 프로그램
  • I/O 완료 포트, 스레드 풀 및 NUMA를 통한 확장성
  • Hyper-V 가상화

Windows Server 2008은 Microsoft 서버 플랫폼의 최신 릴리스이며 여기에는 메모리 관리부터 스레드 예약, 네트워킹부터 보안에 이르는 운영 체제의 모든 기능 영역을 포괄하는
시스템 수준의 변경 사항이 포함됩니다.
Windows Server® 2008은 Windows Vista® SP1과 동일한 커널을 공유하기 때문에 필자의 이전 TechNet Magazine 기사인 "Windows Vista 커널 속으로" 1-3부(2007년 2월, 3월, 4월) 및 "Windows Vista 사용자 계정 컨트롤 들여다보기"(2007년 6월)에서 다룬, Vista의 향상된 기능 대부분이 Windows Server 2008에도 대부분 포함되어 있습니다. 이러한 기사에서 다룬 기능 중 SuperFetch, ReadyBoost, ReadyDrive, ReadyBoot 및 MMCSS(Multimedia Class Scheduler Service)와 같은 일부 기능만 클라이언트 위주이고 Windows Server 2008에는 포함되어 있지 않습니다.
이 글에서는 I/O 우선 순위 지정, 새로운 부팅 아키텍처, BitLockerTM, 코드 무결성 및 필수 무결성 수준과 같이 Windows Vista에서 처음 적용되어 Windows Server 2008에도 포함된 중요한 커널 변경을 다시 살펴보는 것이 아니라 안정성, 성능, 확장성에 관련된 내용과 새로운 Microsoft 하이퍼바이저(hypervisor) 시스템 가상화 기술인 Hyper-VTM 같은, 이전 기사에서 다루지 않은 주요 변경 내용을 집중적으로 다룹니다.
또한 이전 기사와 마찬가지로, 이 기사의 범위는 운영 체제 커널인 Ntoskrnl.exe로 제한되며 시스템 구성 요소와 밀접한 관련이 있습니다. 예를 들어. 설치(WIM(Windows® 이미징 형식) 및 구성 요소 기반 서비스), 관리(그룹 정책 및 Active Directory® 향상 기능), 일반 진단 및 모니터링(Windows 진단 인프라), 핵심 네트워킹(새로운 방화벽 및 TCP/IP 구현), Server Core, 서비스 역할 등에 대한 변경 내용은 다루지 않습니다.
다중 프로세서 시스템 작업
시스템에 대한 저수준 변경 내용 중 하나는 Windows Server 2008에는 다중 프로세서 시스템에서 작동하도록 설계된 커널 버전만 포함된다는 점입니다. 과거 Windows에서는 다중 프로세서 환경에서만 필요한 동기화 코드를 생략함으로써 약간의 성능 향상을 얻을 수 있기 때문에 단일 CPU가 장착된 시스템의 단일 프로세서에 특정된 버전을 사용했습니다. 하드웨어 속도가 빨라짐에 따라 이러한 최적화로 인한 성능 이점은 무시해도 될 정도가 되었고 오늘날 서버 시스템에는 대부분 둘 이상의 프로세서가 장착되므로 단일 프로세서 버전이 필요 없게 되었습니다.
그림 1에서는 운영 체제가 디버그(Checked) 버전인지 정품 버전인지, 설치가 32비트인지 64비트(Itanium, Intel 64 또는 AMD64)인지, 32비트 설치인 경우에는 시스템에 4GB가 넘는 물리적 메모리가 있는지 또는 DEP(데이터 실행 방지)를 지원하는지 여부에 따라 시스템에서 사용되는 Windows Server 2008 커널 버전을 보여줍니다. Windows Server 2008은 32비트 버전이 제공되는 마지막 Windows Server 운영 체제가 될 것으로 예상됩니다.
Figure 1 Windows Server 2008 커널 변형 (Close Figure 1)

커널 | 32비트 | 64비트
다중 프로세서 | 예 | 예
다중 프로세서 확인 | 예 | 예
다중 프로세서 PAE(물리적 주소 확장) | 예 | 아니요
다중 프로세서 PAE 확인 | 예 | 아니요
Windows Server의 모든 릴리스는 파일 서비스, 네트워크 I/O 및 메모리 관리와 같은 주요 서버 시나리오의 성능 향상에 주력합니다. 또한 Windows Server 2008에는 새로운 하드웨어 아키텍처의 장점을 활용하고, 대기 시간이 긴 네트워크에 대처하고, 이전 버전 Windows에서 성능을 제한하는 병목 지점을 제거할 수 있는 몇 가지 변경 내용과 새로운 기능이 있습니다. 이 단원에서는 메모리 관리자, I/O 시스템의 향상된 기능과 새로 도입된 네트워크 파일 시스템인 SMB 2.0에 대해 살펴봅니다.

메모리 관리
실험: 대량 디스크 I/O 확인
TechNet Sysinternals Process Monitor(technet.microsoft.com/sysinternals/bb896645.aspx)와 같은 파일 시스템 모니터링 도구를 사용하여 Windows Server 2008 시스템의 대량 파일 I/O 작업을 살펴볼 수 있습니다.
대량 I/O를 생성하는 방법에는 몇 가지가 있습니다. Windows Vista 서비스 팩 1 또는 Windows Server 2008을 실행하는 보조 시스템이 있는 경우에는 서버에서 Process Monitor를 실행하고 보조 시스템으로 파일을 복사하여 그 결과를 모니터링할 수 있습니다. 또한 메모리 사용량이 많은 프로그램을 실행하여 메모리 관리자가 페이지를 외부 페이징 파일에 쓰도록 하여 대량 페이징 파일 I/O를 생성할 수 있습니다.
그림 A에서는 Windows XP 시스템에서 Process Monitor의 Options 메뉴에서 Enable Advanced Output 옵션을 선택하고 페이징 파일인 pagefile.sys에 대한 쓰기만 표시되도록 필터를 설정한 상태에서, 메모리 사용량이 많은 프로그램을 실행한 결과를 보여줍니다. Detail 열에는 쓰기의 크기가 64KB로 표시됩니다.
그림 A
동일한 단계를 Windows Server 2008에서 실행하면 대부분 쓰기의 크기가 약 1MB로 표시되는 그림 B와 같은 화면이 표시되는 경우가 많습니다.
그림 B

메모리 관리자에는 Windows Server 2008의 몇 가지 성능 개선 사항이 포함됩니다. 예를 들어 페이징 파일에서 데이터를 가져오거나 매핑된 파일에서 미리 읽기 I/O를 수행할 때 Windows Server 2003보다 훨씬 많은 데이터를 한 번에 가져와 실행 횟수를 줄이는 디스크 I/O를 수행합니다. 이러한 대량 파일 I/O는 Windows NT®가 처음 릴리스된 이후부터 존재하던 64KB I/O 크기 제한을 제거하는 I/O 시스템 변경으로 인해 가능해졌습니다.
또한 Windows Server 2008의 경우 캐시 관리자가 매핑된 파일에서 미리 읽기(예측 읽기)를 위해 수행하는 데이터 읽기의 크기가 일반적으로 Windows Server 2003보다 두 배 이상 크며, 데이터 읽기가 대기 목록(시스템의 코드 및 데이터 캐시)에서 직접 수행된다는 점도 알아두어야 합니다. 이 기능 개선 덕분에, 캐시 관리자가 더 이상 가상 메모리를 매핑하거나 데이터를 시스템의 작업 집합(메모리 관리자가 시스템에 할당한 메모리)을 통해 읽기 위해 다른 사용 중인 코드나 데이터를 작업 집합에서 제거할 필요가 없어집니다.
또한 메모리 관리자가 데이터를 페이징 파일에 쓸 때 훨씬 큰 단위로 I/O를 수행합니다. Windows Server 2003에서는 64KB 미만의 쓰기가 수행되는 경우가 많지만 Windows Server 2008에서는 메모리 관리자가 일반적으로 1MB의 쓰기를 실행합니다.
쓰기 단위가 크면 페이징 파일에 대한 쓰기 횟수가 줄어들어 성능이 향상될 뿐만 아니라 페이징 파일 내의 단편화도 줄어듭니다. 단편화가 줄어든다는 것은 페이징 파일이 인접할 가능성이 높아진다는 의미이므로 여러 페이지에서 읽어야 하는 디스크 찾기 및 읽기 횟수도 줄어듭니다.
메모리 관리자는 소유 프로세스의 주소 공간에 기록 중인 것과 가까운 다른 수정된 페이지도 쓰기를 시도하며, 다른 인접 페이지가 이미 있는 페이징 파일 영역을 대상으로 사용하려고 시도합니다. 이런 기능 역시 단편화를 최소화하며, 페이징 파일에 기록하려는 페이지가 이미 기록된 경우도 있으므로 성능이 향상될 수 있습니다. 또한 인접 프로세스 페이지 범위에서 가져오는 데 필요한 페이징 읽기의 수도 줄어듭니다. 메모리 관리자의 대량 I/O 사용에 대한 자세한 내용은 보충 기사 "실험: 대량 디스크 I/O 확인"을 참조하십시오.

SMB 2.0
CIFS(Common Internet File System)라고도 하는 서버 메시지 블록(SMB) 원격 파일 시스템 프로토콜은 Windows에 파일 서비스 기능이 도입된 이래 Windows 파일 서비스의 기본으로 사용되었습니다. 하지만 SMB의 설계 제한으로 인해 지난 몇 년 동안 Windows 파일 서비스 성능과 새로운 로컬 파일 시스템 기능의 장점을 이용할 수 있는 기회가 제한을 받아왔습니다. 단일 메시지에서 전송할 수 있는 최대 버퍼 크기가 약 60KB인 것과 SMB 1.0이 Windows Vista와 Windows Server 2008에 추가된 NTFS 클라이언트측 심볼 링크를 인식하지 못하는 것 등이 이러한 제한의 예입니다.
Windows Vista와 Windows Server 2008에는 클라이언트와 서버 모두가 지원할 때 Windows에서 사용하는 새로운 원격 파일 서비스 프로토콜인 SMB 2.0이 채택되었습니다. SMB 2.0은 클라이언측 심볼 링크와 기타 NTFS의 향상된 기능을 올바르게 처리할 뿐만 아니라 일괄 처리는 사용하여 클라이언트와 서버 사이에 교환되는 메시지 수를 최소화합니다. 일괄 처리를 사용하면 더 많은 데이터를 동시에 전송할 수 있으므로 WAN과 같은 대기 시간이 긴 네트워크에서 처리량을 향상시킬 수 있습니다.
단일 파일에 대한 I/O를 순차적으로 실행하는 SMB 1.0과 달리, SMB 2.0에서는 I/O 파이프라인을 구현함으로써 같은 파일에 대한 여러 개의 동시 I/O를 실행할 수 있습니다. 또한 SMB 2.0은 클라이언트에서 사용하는 서버 메모리의 양을 측정하여 I/O를 향상시킬 수 있는 파이프라인 처리 수준을 결정합니다.
Windows I/O 메모리 관리자와 I/O 시스템의 변경, TCP/IP 수신 창 자동 조정, 파일 복사 엔진 기능 향상 등으로, SMB 2.0을 사용하면 대규모 전송에서 처리량이 크게 향상되고 파일 복사 시간이 단축됩니다. Windows Server 2008과 Windows Vista 운영 체제 모두 SMB 2.0을 지원하기 때문에 Windows Server 2008 파일 서버와 Windows Vista 클라이언트를 함께 배포하면 SMB 2.0을 사용하여 이러한 성능 이점을 현실화할 수 있습니다.

NTFS 자체 치유를 통한 안정성
안정성은 핵심적인 서버 특성입니다. Windows Server 2008에는 관리자가 서버를 원활하게 실행할 수 있도록 돕는 온라인 NTFS 일관성 복구, 새로운 하드웨어 오류 보고 인프라, 드라이버 확인 프로그램 확장 기능 등을 비롯한 다양한 향상된 기능이 제공됩니다.
오늘날에는 수 테라바이트에 달하는 저장 장치가 사용되므로 일관성 검사를 위해 볼륨을 오프라인으로 전환하면 몇 시간의 서비스 중단이 발생할 수 있습니다. 대부분의 디스크 손상은 단일 파일 또는 메타데이터의 일부로 국한되는 경우가 많기 때문에 Windows Server 2008에서는 볼륨을 온라인 상태로 유지하면서 손상을 복구하는 새로운 NTFS 자체 치유 기능을 구현합니다.
NTFS에서는 손상 감지 시 손상된 파일에 대한 액세스를 차단하고 Chkdsk와 같은 방식으로 손상된 데이터 구조를 수정하는 시스템 작업자 스레드를 만듭니다. 이 작업이 끝나면 복구된 파일에 액세스할 수 있습니다. 이 작업 도중에도 다른 파일에는 계속 액세스할 수 있으므로 서비스 중단이 최소화됩니다.

WHEA 인프라
Windows Server 2008에 포함된 Windows 하드웨어 오류 아키텍처(WHEA) 인프라는 하드웨어 오류 관리를 단순화하고 중대하지 않은 오류에 대한 예방적 대응을 가능하게 합니다. 서버에는 엄격한 가동 시간이 보장되어야 하는 경우가 많으므로 서버 시스템에서 오류를 시기적절하게 식별하고 조치하는 것은 매우 중요합니다.
OCA(Online Crash Analysis)를 통해 Microsoft에 제출된 충돌을 분석해 보면 운영 체제 충돌 중 약 10퍼센트는 하드웨어 실패로 인한 것이지만 충돌 시 캡처할 수 있는 하드웨어 제공 오류 정보가 충분하지 않기 때문에 이러한 충돌의 근본 원인을 파악하는 것이 어렵거나 불가능했습니다. 또한 Windows Server 2008 이전에는 Windows에서 장치 상태의 모니터링을 기본적으로 지원하지 않았으며 긴급한 실패의 해결이나 알림을 구현하지 않았습니다. 이러한 문제의 원인은 하드웨어 장치가 공통 오류 형식을 사용하지 않으며 오류 관리 소프트웨어에 대한 지원을 제공하지 않는다는 것에 있습니다.
WHEA는 프로세서, 메모리, 캐시 및 PCI나 PCI Express 등의 버스를 포함하여 플랫폼 장치에 대한 오류 원인 검색 및 보고를 위한 통일된 메커니즘을 제공합니다. 이를 위해 그림 2와 같은 아키텍처를 구현하며, 여기서 핵심은 오류 출처가 오류를 보고하기 위해 호출하는 커널 API입니다. 이 API는 모든 오류를 공통된 형식으로 보고하도록 요구하며, Windows용 이벤트 추적(ETW) 이벤트를 사용하여 오류를 기록합니다(심각한 오류는 다시 부팅한 후 기록됨).
그림 2 WHEA 오류 보고 인프라
그림 2 WHEA 오류 보고 인프라
ETW는 Windows 2000에서 도입되었으며 ETW에서 WHEA를 사용함에 따라 하드웨어 제조업체와 소프트웨어 공급업체에서 WHEA 이벤트를 사용하는 장치 진단 관리 응용 프로그램을 쉽게 개발할 수 있게 되었습니다. 시스템 작동을 중단시킬 정도로 심각한 이벤트의 경우 WHEA는 관리자가 작동 중단의 근본 원인을 파악할 수 있도록 오류 기록을 크래시 덤프 파일에 저장합니다.
WHEA의 다른 핵심 부분은 플랫폼 관련 하드웨어 오류 드라이버(PSHED)인 %Systemroot%\System32\Pshed.dll. 커널은 PSHED와 연결되고, PSHED는 플랫폼 및 펌웨어 하드웨어에 인터페이스를 제공하여 오류 알림과 WHEA 오류 보고 API 사이의 전송 계층 역할을 합니다. 각 플랫폼 아키텍처(x86, x64, Itanium)별로 Microsoft 제공 PSHED가 있으며, PSHED는 하드웨어 공급업체 및 제조업체에서 자사의 플랫폼에 특정한 동작으로 기본 동작을 다시 정의할 수 있도록 플러그 인 모델을 제공합니다.
마지막으로 장치 드라이버, 하드웨어 추상화 계층(HAL) 및 커널을 비롯한 기타 오류 출처의 인터페이스를 제공하는 시스템 구성 요소는 초기에 오류 조건을 처리하는 LLHEL(Low-Level Hardware Error Handlers)을 구현할 수 있습니다. LLHEL의 역할은 장치에서 오류 정보를 추출하고, PSHED가 추가적인 플랫폼 오류 정보를 수집할 수 있도록 이를 알린 다음 커널의 WHEA 오류 보고 API를 호출하는 것입니다.

드라이버 확인 프로그램
Windows 2000 이후의 모든 Windows에는 버그가 있는 장치 드라이버와 결함이 발생한 하드웨어를 추적하기 위한 강력한 도구인 드라이버 확인 프로그램이 포함되어 있습니다. 일반적으로, 시스템 작동 중단의 원인인 것으로 의심되는 장치 드라이버의 동작을 자세히 모니터링하기 위해 관리자가 드라이버 확인 프로그램(%Systemroot%\System32\Verifier.exe)을 구성합니다. 드라이버 확인 프로그램은 문제가 있는 드라이버 동작을 기록하므로 크래시 덤프 파일에 문제가 발생한 부분이 직접 표시됩니다.
이전 드라이버 확인 프로그램 구현의 약점은 구성을 변경할 경우 대부분 시스템을 다시 시작해야 한다는 점입니다. 이것은 프로덕션 서버에서 바람직하지 않습니다. 하지만, Windows Server 2008의 드라이버 확인 프로그램 구현에서는 대부분의 유용한 확인 구성에서 시스템을 다시 시작할 필요가 없기 때문에 서버를 다시 시작하지 않고도 문제를 해결할 수 있게 되었습니다.
또한 드라이버 확인 프로그램에 그림 3에서 볼 수 있는 새로운 확인 기능이 도입되었습니다. Security checks(보안 확인)에서는 장치 드라이버가 응용 프로그램에 인터페이스를 제공하기 위해 사용하는 개체에 보안 권한을 설정했는지 확인합니다. Force pending I/O requests(강제 보류 I/O 요청)에서는 지연 후 완료되는 것이 아니라 즉시 완료되는 비동기식 I/O 작업에 대한 드라이버의 탄력성을 테스트합니다. 또한 Miscellaneous checks(기타 확인)에서는 사용 중인 리소스를 부적절하게 해제하거나, WMI(Windows Management Instrumentation) 등록 API를 부적절한 사용하거나, 리소스 핸들 누수가 발생하는 드라이버를 찾습니다.
그림 3 Windows Server 2008 옵션이 선택된 드라이버 확인 프로그램
그림 3 Windows Server 2008 옵션이 선택된 드라이버 확인 프로그램

확장성
확장성은 운영 체제 또는 응용 프로그램이 여러 프로세스와 대용량 메모리를 효과적으로 이용할 수 있는 능력을 가리킵니다. Windows는 릴리스될 때마다 다중 프로세서의 병렬 처리 능력을 감소시키는 잠금 사용을 최소화하거나 제거하여 확장성을 향상시켜 왔으며 Windows Server 2008도 예외는 아닙니다.
타이머 만료를 실행하는 코드에서 상대적으로 소규모이지만 중요한 기능이 향상되었습니다. 즉, 모든 저수준 동기화 작업에 사용되는 발송자 잠금, 시스템 전체 스케줄러 잠금을 더 이상 요구하지 않게 되었습니다. 그 결과 CPU 동기화 오버헤드가 감소되어 Windows Server 2008 터미널 서버 시스템에서는 Windows Server 2003에 비해 약 30퍼센트 많은 동시 사용자를 지원합니다.
Windows Server 2008의 다른 확장성 향상 기능에는 완료 포트 향상, 새로운 스레드 풀 구현, NUMA(Non-Uniform Memory Access) 하드웨어의 보다 효율적인 활용, 동적 시스템 분할 등이 포함됩니다.

향상된 I/O 완료 포트 처리
IIS, SQL Server® 및 Exchange Server를 비롯한 대부분의 확장 가능한 Windows 서버 응용 프로그램은 I/O 작업 실행 시 여러 실행 스레드 간의 전환을 최소화하기 위해 완료 포트라고 하는 Windows 동기화 API를 사용합니다. 이를 위해 우선 웹 서버 클라이언트 연결과 같은 새 요청의 수신 알림을 완료 포트와 연결하고 알림을 대기할 전용 스레드 풀을 지정합니다. 요청이 수신되면 Windows에서는 스레드를 예약하고 그런 다음 일반적으로 디스크에서 웹 페이지 읽기와 같은 다른 I/O 작업을 실행하여 이를 클라이언트로 전송하여 요청을 완료합니다.
따라서 한 스레드가 최대한 빠르게 반환되어 더 많은 클라이언트 요청을 대기하게 되며 스레드는 I/O를 비동기적으로 실행하고 I/O 완료를 완료 포트와 연결합니다. 그런 다음 스레드가 완료 포트에서 대기하는 상태로 반환되어 새 요청이 수신되거나 I/O 중 하나가 완료될 때 해당 스레드가 예약됩니다. 이 방법을 통해 동일한 스레드가 CPU에서 활성 상태를 유지하면서 클라이언트 요청 처리와 완료 포트 대기를 교대로 수행할 수 있습니다.
이전 Windows 릴리스의 완료 포트 구현에 있어 단점은, I/O 완료 시 I/O 시스템에서 스레드의 작업 종류에 관계없이 I/O를 실행한 스레드가 즉시 소규모의 완료 처리를 수행해야 한다는 것입니다. 이 때문에 다른 스레드가 활성화되어 있으면 스케줄러가 활성 스레드를 선점하고 발행자에게 컨텍스트를 전환하는 경우가 많았습니다.
Windows Server 2008에서는 완료 처리를 I/O가 연결된 완료 포트에서 대기 중인 다음 스레드로 연기하여 이러한 컨텍스트 전환을 방지합니다. 따라서 다른 스레드가 완료 포트에서 대기 중이더라도 다른 코드를 실행하기 전에 완료 처리를 수행할 수 있으며 스케줄러가 실행 스레드로 전환할 필요가 없습니다. 이렇게 컨텍스트 전환이 최소화되므로 작업 부하가 큰 서버 응용 프로그램의 확장성을 크게 향상시킬 수 있습니다.

더 효율적인 스레드 풀
다중 CPU를 활용하는 응용 프로그램을 작성하는 것이 어려울 수 있기 때문에 Windows XP에서는 작은 단위의 여러 작업을 여러 CPU에서 실행하는 세부 과정을 추상화하는 관련 API와 인프라인 작업자 스레드 풀을 도입했습니다. 응용 프로그램은 스레드 풀 API에 작업 항목을 지정한 다음, 시스템의 각 CPU별로 생성하고 관리하는 스레드 중 하나에서 이를 실행합니다.
스레드 풀의 목표는 동일한 스레드를 사용하여 여러 작업 항목을 연속적으로 실행함으로써 컨텍스트 전환을 최소화하는 것입니다. 스레드 중 하나가 이미 다른 작업을 수행 중이어서 이런 실행이 불가능한 경우에는 다른 CPU의 다른 스레드를 사용하여 작업 항목을 실행합니다.
Windows Server 2008 스레드 풀 구현에서는 완료 포트 향상에서 발생하는 간접적인 기능 개선과 스레드 관리를 최적화하여 응용 프로그램의 작업 부하를 처리해야 할 때 작업자 스레드를 동적으로 가져와 실행할 수 있다는 직접적인 기능 개선을 통해 CPU를 더 효율적으로 이용합니다. 또한 인프라의 코어가 커널 모드로 이동되었기 때문에 API를 사용하는 응용 프로그램의 시스템 호출 수가 최소화됩니다. 마지막으로, 새로운 API를 사용하면 응용 프로그램에서 응용 프로그램 종료 중 대기열에 있는 작업 단위의 취소와 같은 특정 작업을 더 쉽게 수행할 수 있습니다.

NUMA 최적화
Windows Server 2003에서 처음 스레드 스케줄러와 메모리 관리자의 NUMA 시스템이 최적화되었습니다. Windows Server 2008에서는 I/O 관리자에 NUMA 최적화가 추가되었으며 메모리 관리자의 NUMA 최적화가 확장되었습니다.
NUMA 시스템은 일반적으로 메모리에 액세스하는 프로세스에 따라 각 메모리의 대기 시간이 달라지는 다중 프로세서 시스템입니다(그림 4 참조). 메모리는 노드로 나뉩니다. CPU와 노드 간 대기 시간은 다를 수 있고 각 CPU는 가장 빠르게 액세스할 수 있는 노드로 간주됩니다.
그림 4 예제 NUMA 시스템
그림 4 예제 NUMA 시스템
NUMA 시스템, 특히 8개 이상의 CPU가 장착된 시스템은 균일한 메모리 액세스 시스템보다 비용 및 성능 면에서 더 효율적인 경우가 많습니다. 균일 메모리 액세스 시스템에서는 모든 CPU가 동등에게 메모리를 사용할 수 있어야 하지만 NUMA 시스템에서는 CPU에 직접 연결되는 메모리에 대해서는 고속 상호 연결을 구현할 수 있으며 CPU와 간접적으로 연결되는 메모리에 대해서는 더 높은 대기 시간을 가지지만 더 저렴한 연결을 구현할 수 있습니다.
NUMA 시스템에서 효율적인 확장을 위해서는, 계산에 사용되는 데이터 및 코드가 포함된 메모리 근처에서 계산이 실행될 수 있도록 운영 체제나 응용 프로그램에 노드 토폴로지를 인식하는 기능이 있어야 합니다. 예를 들어 Windows 스케줄러는 스케줄러가 항상 스레드 실행을 시도하는 CPU인 소위 말하는 이상적인 프로세서에 각 스레드를 할당합니다. 이렇게 하면 스레드가 CPU의 캐시에 넣는 데이터를 스레드가 실행될 때마다 사용할 수 있게 될 가능성이 높아집니다.
Windows Server 2003에서 스케줄러는 이상적 프로세서가 포함된 노드를 스레드의 이상적 노드로 간주함으로써 이 개념을 확장하고 이상적 프로세서가 다른 스레드를 실행 중인 경우 이상적 노드의 다른 CPU에서 스레드를 예약하려고 시도합니다. Windows Server 2003 메모리 관리자도 NUMA를 인식하고 가능한 경우 스레드의 메모리 할당을 스레드가 실행 중인 노드의 메모리로 전달합니다.
Windows Server 2008에서는 메모리 관리자가 커널의 비페이징 메모리 버퍼(RAM에 유지되어야 하는 데이터를 저장하기 위해 커널 및 장치 드라이버에서 사용하는 메모리)를 여러 노드에 분산시켜 할당을 요청한 노드의 메모리에서 할당이 이루어지도록 합니다. 할당에서 새 페이지 테이블 페이지를 필요로 하는 경우 Windows Server 2003에서처럼 할당이 임의의 노드에서 이루어지는 것이 아니라 할당이 요청된 노드에서 시스템 PTE(페이지 테이블 항목)가 할당됩니다.
Windows Server 2003에서 스레드가 메모리를 할당할 때 메모리 관리자는 할당 시 스레드가 실행 중인 노드를 우선적으로 사용합니다. 스레드가 일시적으로 비이상적인 노드로 예약된 경우에는 해당 시간 동안 수행된 모든 할당은 비이상적인 노드에서 이루어집니다. 따라서 그 이후에 스레드가 스레드의 이상적인 노드에서 실행되어도 노드가 할당된 메모리에 저장된 데이터나 코드에 가깝지 않게 됩니다.
이를 해결하기 위해 Windows Server 2008 메모리 관리자는 스레드가 다른 노드에 가깝게 실행되더라도 모든 스레드의 할당에 대한 스레드의 이상적 노드를 우선적으로 사용합니다. 또한 메모리 관리자는 프로세서와 노드 사이의 대기 시간을 자동으로 인식하기 때문에 이상적인 노드에 가용 메모리가 없으면 다음으로 이상적인 노드에 가장 가까운 노드를 검사합니다. 메모리 관리자는 스레드가 코드 또는 데이터를 참조할 때 대기 목록의 페이지를 스레드의 이상적인 노드로 마이그레이션합니다.
할당의 지역성을 제한하고자 하는 응용 프로그램에서는 메모리 할당, 파일 매핑 보기 및 파일 매핑 개체에 대한 기본 노드를 지정할 수 있도록 해주는 새 NUMA 메모리 API를 사용할 수 있습니다. 파일 매핑에 관련된 할당의 경우 메모리 관리자는 매핑 작업이 노드를 지정하는지 검사한 다음 파일 매핑 개체가 이를 지정하는지 검사하고, 마지막으로 둘 모두에 해당하지 않으면 스레드의 이상적인 노드를 사용합니다.
Windows Server 2008 이전에는 저장소 또는 네트워크 I/O에 대한 인터럽트 및 관련 DPC(지연 프로시저 호출)는 I/O가 시작된 CPU와 다른 노드에 있는 CPU를 비롯한 모든 CPU에서 실행될 수 있으므로 I/O 작업에서 읽거나 쓴 데이터가 해당 데이터를 액세스한 것과 다른 노드의 메모리에 위치할 가능성이 있습니다.
이를 피하기 위해 Windows Server 2008 I/O 시스템에서는 DPC 실행을 I/O를 시작한 노드의 CPU로 전달하고, PCI 버스 MSI-X(Message Signaled Interrupt 표준의 확장)를 지원하는 장치가 있는 시스템은 Windows Server 2008 API의 장점을 이용하여 I/O의 인터럽트를 I/O를 시작한 프로세스로 전달하는 장치 드라이버를 사용하여 I/O 완료를 더 지역화할 수 있습니다.

동적 분할
시스템의 확장성을 높일 수 있는 한 가지 방법은 CPU와 메모리 등의 하드웨어의 동적 추가를 지원하는 것입니다. 또한 이러한 리소스를 시스템을 다시 부팅하지 않고 교체할 수 있다면 시스템 가용성을 더 높일 수 있습니다.
Windows Server 2003에는 상시 메모리 추가 기능이 포함되어 있으므로 동적 메모리를 지원하는 서버에 관리자가 RAM을 추가하면 이를 사용할 수 있습니다. Windows Server 2008에서는 메모리 교체도 허용함으로써 동적 메모리 지원이 더욱 확장됩니다.
RAM에서 ECC(오류 보정 코드) 보정 의존도가 높아질수록 오류가 발생할 위험성도 커지기 때문에, 상시 교체가 지원되는 서버의 경우 Windows Server 2008에서는 오류가 발생한 메모리 뱅크의 데이터를 서버에 영향을 주지 않고 교체 메모리로 마이그레이션할 수 있도록 지원합니다. 이를 위해 운영 체제의 제어 하에 있는 데이터를 먼저 마이그레이션한 다음 하드웨어 장치를 저전력 상태로 전환하여 실제로 하드웨어 장치를 종료한 다음 나머지 메모리 데이터를 마이그레이션하고 장치에 다시 전원을 공급하여 정상 작동하도록 합니다.
Windows Server 2008에서는 프로세서의 상시 추가 및 상시 교체도 지원합니다. 상시 교체를 사용하려면 기존 CPU에서 오류가 발생할 경우 온라인 상태로 만들거나 동적으로 추가할 수 있는 예비 CPU 기능을 지원하는 하드웨어가 있어야 합니다. 현재 이러한 하드웨어는 고급 시스템에서만 사용할 수 있습니다. Windows Server 2008 스케줄러는 오류가 발생한 CPU의 활동을 늦추고 작업을 교체 CPU로 마이그레이션합니다. 그런 다음에는 오류가 발생한 CPU를 제거하고 새 예비 CPU로 교체합니다.
Windows Server 2008에서는 상시 프로세서 추가를 지원하기 때문에 관리자는 중단 시간 없이 서버의 처리 성능을 업그레이드할 수 있습니다. 하지만 일부 응용 프로그램은 CPU의 수가 부팅 세션에 고정되어 있다는 가정 하에 빌드되기 때문에, 스케줄러 및 I/O 시스템에서는 새 API를 통해 CPU 추가 알림을 받을 수 있는 장치 드라이버와 응용 프로그램에서만 새 CPU를 사용할 수 있게 만듭니다. 예를 들어 응용 프로그램이 각 CPU에 해당하는 작업 대기열 배열을 할당하고, 스레드는 실행 중인 CPU와 연결된 대기열을 사용할 수 있습니다. 스케줄러가 응용 프로그램의 스레드 중 하나를 새 CPU에 할당하면 응용 프로그램에서 존재하지 않는 대기열을 시도하고 참조하게 되어 데이터가 손상되고 응용 프로그램이 중단될 수 있습니다.
SQL Server 및 Exchange Server와 같은 Microsoft 서버 기반 응용 프로그램은 시스템 프로세스, 세션 관리자(%SystemRoot%\System32\Smss.exe) 및 Generic Service Hosting 프로세스(%Systemroot%\System32\Svchost.exe)를 포함한 몇 가지 핵심 Windows 프로세스와 마찬가지로 CPU 추가 기능을 지원합니다. 다른 프로세스 역시 Windows API를 사용하여 새 CPU 추가 알림을 요청할 수 있습니다. 새 CPU가 추가되면 Windows는 장치 드라이버에 예정된 추가를 알리고, CPU를 시작하고, 새 CPU의 장점을 활용하도록 작성된 응용 프로그램과 장치 드라이버에 이를 알려서 필요한 경우에 데이터 구조를 새 CPU의 추적 활동에 추가하도록 합니다.

시스템 가상화
Windows Server 2008 이전에는 Virtual Server 2005를 포함한 Microsoft 가상화 제품이 그림 5와 같은 호스팅 기반 가상화를 사용하여 구현되었습니다. 호스팅 기반 환경에서 가상 컴퓨터는 호스트 운영 체제와 함께 실행되는 VMM(Virtual Machine Monitor)에 의해 구현되었으며, 이 VMM은 대개 장치 드라이버로 동작합니다. VMM은 호스트 운영 체제의 리소스 관리 및 장치 드라이버에 의존하며 호스트 운영 체제에서 실행이 예약된 경우 시분할을 통해 활성 VM(가상 컴퓨터) 간에 CPU를 제공합니다.
그림 5 호스팅 기반 컴퓨터 가상화
그림 5 호스팅 기반 컴퓨터 가상화
이전 코드명이 "Viridian"이었던 Hyper-V는 하이퍼바이저 가상화를 사용하여 구현됩니다. 하이퍼바이저는 그림 6에서처럼 모든 하드웨어 리소스에 대한 전체 제어권을 가지며, 시스템을 부팅하고 VM을 제어하는 Windows Server 2008 운영 체제도 기본적으로 가상 컴퓨터에서 실행됩니다.
그림 6 Hyper-V 아키텍처
그림 6 Hyper-V 아키텍처
하이퍼바이저는 시스템을 여러 VM으로 나누고 Windows Server 2008의 부팅 인스턴스를 마스터 또는 루트 파티션으로 취급하므로 디스크, 네트워킹 어댑터 및 그래픽 프로세서 등의 하드웨어 장치에 직접 액세스할 수 있습니다. 하이퍼바이저는 루트에서 전원 관리를 수행하고 하드웨어 플러그 앤 플레이 이벤트에 응답한다고 가정합니다. 하이퍼바이저는 자식 파티션에서 시작된 하드웨어 장치 I/O를 가로채어 루트로 라우팅하며, 루트에서는 표준 Windows Server 2008 장치 드라이버를 사용하여 하드웨어 액세스를 수행합니다. Hyper-V를 실행하는 서버는 이런 방식으로 Windows의 하드웨어 장치 지원을 완벽하게 이용할 수 있습니다.
Windows Server 2008을 Hyper-V 서버 역할로 구성하면 Windows에서 hypervisorimagelaunchtypeboot BCD(부팅 구성 데이터베이스) 설정을 auto로 설정하고 Hvboot.sys 장치 드라이버가 부팅 프로세스의 초기 단계에 시작되도록 구성합니다. 옵션을 구성하면 Hvboot.sys는 가상화에 적합하게 시스템을 준비한 다음 시스템이 AMD-V 또는 Intel VT CPU 가상화 확장 중 무엇을 구현하는지에 따라 각각 %Systemroot%\System32\Hvax64.exe 또는 %Systemroot%\System32\Hvix64.exe를 메모리로 로드합니다.
로드된 후에는 하이퍼바이저가 가상화 확장을 사용하여 자신을 Windows Server 2008 아래에 삽입합니다. 사용자 모드 응용 프로그램은 x64 프로세서의 Ring 3 권한 수준을 사용하고 커널 모드 코드는 Ring 0 권한 수준에서 실행되므로, 개념적으로 하이퍼바이저는 -1 Ring 권한 수준에서 작동하며 이를 통해 Ring 0에서 실행 중인 코드의 실행 환경을 제어할 수 있습니다.
Hyper-V 관리 콘솔을 사용하여 자식 파티션을 만들거나 시작하면, 해당 파티션은 %Systemroot%\System32\Drivers\Winhv.sys 드라이버를 사용하여 하이퍼바이저와 통신합니다. 이 드라이버는 문서화되어 공개된 Hypercall API를 사용하여 하이퍼바이저가 지정된 물리적 메모리 크기 및 실행 특성을 가지는 새 파티션을 만들도록 지시합니다. 루트 안의 VM 서비스(%Systemroot%\System32\Vmms.exe)가 각 자식 파티션에 대한 VM 작업자 프로세스(%Systemroot%\System32\Vmwp.exe)를 만들어서 자식의 상태를 관리합니다.
Windows에서 자식 VM 운영 체제의 성능을 높이는 방법 중 한 가지는, 운영 체제가 Microsoft Hypercall API를 구현하는 하이퍼바이저를 통해서 실행 중일 때에만 활성화되는 코드 시퀀스를 Windows Server 2008과 Windows Vista 모두에서 구현하여 하이퍼바이저를 인식할 수 있도록 개선(이러한 자각 기능을 enlightment라고 함)하는 것입니다. 자식 VM은 하이퍼바이저의 서비스를 직접 요청함으로써 하이퍼바이저가 자식 운영 체제의 의도를 추측해야 할 경우 발생할 수 있는 가상화 코드 오버헤드를 방지합니다.
예를 들어 저수준 다중 프로세스 동기화를 실행하는 스핀록(spinlock)을 인식하기 위한 기능을 구현하지 않은 게스트 운영 체제는 다른 가상 프로세서에 의해 스핀록이 해제될 때까지 조밀한 루프에서 대기 상태로 스핀합니다. 이러한 스핀은 하이퍼바이저가 두 번째 가상 프로세서를 예약할 때까지 하드웨어 CPU 중 하나를 묶어둘 수 있습니다. 자각 기능이 구현된 운영 체제의 경우 스핀록 코드는 스핀이 발생할 수 있을 때 Hypercall을 통해 하이퍼바이저에 통보하여 하이퍼바이저가 즉시 다른 가상 프로세서를 예약하고 불필요한 CPU 사용을 줄일 수 있도록 합니다.
Windows Server 2008에서 VM 성능을 향상시키는 다른 방법은 장치에 대한 VM 액세스를 가속화하는 것입니다. 통틀어 "VM 통합 구성 요소"라고 하는 구성 요소 모음을 자식 운영 체제에 설치하여 성능을 향상시킵니다.
통합 구성 요소를 설치하지 않고 VM을 실행하면 자식 운영 체제는 하이퍼바이저가 제시하는 에뮬레이션된 장치에 대한 하드웨어 장치 드라이버를 구성합니다. 자식 VM의 운영 체제 대신 표준 Windows 장치 드라이버를 사용하여 장치 I/O를 수행하는 루트 파티션에 알리기 위해서는 장치 드라이버가 하드웨어 리소스에 접촉하려고 할 때 하이퍼바이저가 개입해야 합니다. 디스크 읽기와 같은 단일 고수준 I/O 작업에는 많은 별도의 하드웨어 액세스가 관여할 수 있기 때문에 하이퍼바이저와 루트 파티션에 인터셉트라고 하는 전환이 여러 개 발생할 수 있습니다.
Windows Server 2008에서는 가상 컴퓨터 버스 드라이버(%Systemroot%\System32\Drivers\Vmbus.sys), 가상 서비스 클라이언트(VSC) 및 가상 서비스 공급자(VSP)의 세 구성 요소를 사용하여 인터셉트를 최소화합니다. 지원 운영 체제의 VM에 통합 구성 요소를 설치하면 VSC가 장치 드라이버의 역할을 넘겨받고 자식 VM에서 Vmbus.sys 드라이버의 서비스를 사용하여 하이퍼바이저의 Hypercall 및 메모리 공유 서비스를 통해 루트 파티션에 있는 가상 컴퓨터 버스 드라이버로 고수준 I/O 요청을 전송합니다. 루트 파티션에서는 Vmbus.sys가 요청을 해당 VSP로 전달하며 그런 다음 루트의 장치 드라이버를 통해 표준 Windows I/O 요청이 초기화됩니다.
여기서 볼 수 있듯이 Windows Server 2008에는 Hyper-V 하이퍼바이저 기반 가상화가 도입되어 Microsoft 시스템 가상화 전략에서 핵심적 역할을 합니다. 이 주제와 다른 기능에 대한 자세한 내용은 올해 말 출간 예정인 필자의 책 Microsoft Windows Internals 개정판을 참조하십시오.

Mark Russinovich는 Microsoft 플랫폼 및 서비스 부서에서 근무하는 기술 연구원으로, Microsoft Windows Internals(Microsoft Press, 2004)의 공동 저자이자 Microsoft TechEd, Professional Developer's Conference 등의 IT 및 개발자 컨퍼런스에서 단골 연설자로 활동하고 있습니다. Mark Russinovich는 Microsoft에서 인수한 Winternals Software의 공동 설립자이며 Process Explorer, Filemon 및 Regmon 유틸리티와 같은 많은 유명 유틸리티를 배포한 Sysinternals를 설립하기도 했습니다.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 Special Coverage: Windows Server 2008: Active Directory 도메인 서비스의 새로운 기능
Special Coverage: Windows Server 2008 Gil Kirkpatrick

Active Directory 도메인 서비스의 새로운 기능
한 눈에 보기:
  • ADDS에 새로운 서버 관리자 사용
  • Server Core에서 도메인 서비스 실행
  • 읽기 전용 도메인 컨트롤러
  • 암호, 백업 및 감사 기능 관련 변경 사항

Microsoft는 Windows 2000에서 처음으로 Active Directory를 선보였습니다. 그리고 다음 주요 릴리스인 Windows Server 2003에서 Active Directory를 많이 개선했지만
크게 달라진 점은 없었습니다. 그렇게 현재까지 오면서 Active Directory®는 강력한 디렉터리 서비스로 자리잡았습니다. 그럼에도 불구하고 Active Directory 팀은 최신 버전에서 핵심 네트워크 서비스의 보안과 관리 효율성을 향상시키는 몇 가지 주목할 만한 향상된 기능을 선보였습니다.
21세기로 접어들 무렵 Active Directory는 로그인하는 사용자를 인증하고, 사용자와 컴퓨터에 그룹 정책을 적용하고, 사용자가 필요로 하는 프린터를 찾도록 도와주는 솔루션이었습니다. 그리고 몇 년 후 Microsoft는 ADAM(Active Directory Application Mode)이라는 독립 실행형 버전을 발표했습니다.
2006년까지 그 외에 변경된 사항은 없었습니다. Active Directory는 더 이상 특별한 기술이 아니었고, 지금은 Windows®의 기본 ID 및 액세스 제어 서비스를 통칭하는 브랜드 이름이 되었습니다. 그림 1에는 Active Directory라는 브랜드를 구성하는 요소가 요약되어 있습니다.
Figure 1 Active Directory 구성 요소 (Close Figure 1)

현재 Active Directory 기술 | 이전 명칭 | 설명
ADDS(Active Directory 도메인 서비스) | Active Directory | 이전에 Active Directory라고 불렀던 구성 요소로, 도메인 사용자 및 컴퓨터에 대한 Kerberos 및 NTLM 기반 인증을 제공하고 OU, 사용자, 그룹, 그룹 정책 등을 관리합니다.
ADLDS(Active Directory Lightweight Directory Services) | ADAM(Active Directory Application Mode) | ADDS와 동일한 소스 코드를 기반으로 하는 고성능 LDAP 서버입니다.
ADCS(Active Directory 인증서 서비스) | 인증서 서비스 | X.509 인증서를 사용하여 강력한 인증을 제공합니다.
ADRMS(Active Directory Rights Management Services) | Rights Management Server | 권한 보호 파일 및 컨테이너를 만들어 문서나 전자 메일 같은 디지털 자산을 무단 사용하지 못하도록 보호합니다.
ADFS(Active Directory Federation Services) | ADFS(Active Directory Federation Services) | WS-* 호환 웹 서비스에 대해 웹 Single Sign-On 및 ID 페더레이션을 제공합니다.
엄밀히 말하자면 이 기사에서 다루는 주제는 도메인 서비스지만 2000년부터 여러분이 사용해 온 Active Directory와 다를 바가 없습니다.

Windows Server 2008의 서버 관리자
먼저 설명할 Active Directory의 향상된 두 가지 기능은 사실 ADDS(Active Directory 도메인 서비스)에서 변경된 사항이라기보다 Active Directory를 관리하는 방식에 영향을 주는 Windows의 변경 사항입니다. 첫 번째 살펴볼 새 서버 관리자는 Windows Server® 2008 서버를 처음으로 부팅하면 바로 나타납니다. 두 번째로 설명할 Server Core 설치 기능에 대해서는 잠시 후에 살펴보겠습니다.
서버 관리자는 Windows Server 2003을 설치하면 기본적으로 표시되는 서버 구성 마법사와 비슷합니다. 그러나 Windows Server 2003의 서버 구성 마법사는 일상적인 관리 작업에 그리 유용하지 않았고 필자 주위에도 "로그온할 때 이 페이지 표시하지 않음" 확인란을 선택하는 사람이 많았습니다.
그에 비해 Windows Server 2008의 서버 관리자는 상당히 유용합니다. 이번 달 TechNet Magazine에 게재된 Byron Hynes의 기사에서 서버 관리자에 대해 개괄적으로 살펴볼 수 있습니다. 우선 그림 2에서 보듯이 서버 관리자는 Microsoft HTA(HTML 응용 프로그램)가 아니라 MMC(Microsoft® Management Console) 스냅인으로 개발되었습니다. 따라서 익숙하고 쉽게 사용자 지정할 수 있는 완전한 기능의 사용자 인터페이스를 제공합니다. 기본적으로 서버 관리자에서는 서버 역할(DNS, ADDS, IIS 등의 주요 서비스)과 기능(Microsoft .NET Framework, BitLockerTM 드라이브 암호화, Windows PowerShellTM 등의 소프트웨어 구성 요소)의 설치를 관리할 수 있습니다. 단순히 소프트웨어를 추가하고 제거하는 기능만 제공하는 것이 아니라 이벤트 뷰어 및 PerfMon 같은 진단 도구와 장치 관리자 및 Windows 방화벽 스냅인 같은 시스템 구성 유틸리티를 한곳에서 실행할 수 있도록 합니다. 사용자 및 컴퓨터, 도메인 및 트러스트, 사이트 및 서비스 등의 Active Directory용 MMC 스냅인을 추가하면 일상적인 Windows Server 2008 DC(도메인 컨트롤러) 관리 작업을 수행하는 데 매우 유용한 인터페이스를 얻을 수 있습니다.
그림 2 Windows Server 2008의 서버 관리자
그림 2 Windows Server 2008의 서버 관리자

Windows Server 2008 Server Core
Windows Server Core는 새로운 Windows 설치 옵션으로 Active Directory 도메인 서비스를 비롯하여 특정 핵심 서버 역할을 실행하는 데 필요한 구성 요소만 포함하는 간소화된 Windows 버전을 제공합니다. Server Core에서 지원되는 역할은 그림 3에 나와 있습니다. Server Core 설치에서도 그래픽 UI가 제공되지만 Windows 데스크톱 셸이 실행되지 않고 Windows 관리 및 구성을 위한 그래픽 도구가 거의 제공되지 않습니다(그림 4 참조). 그 대신 명령 창이 표시되기 때문에 어떻게 사용해야 할지를 몰라 당황하게 되는 경우가 많습니다. "컴퓨터 이름은 어떻게 바꾸어야 하지? 대체 정적 IP 주소는 어떻게 구성해야 하지?"라면서 말입니다.
그림 4 그래픽 기능이 별로 없는 Server Core UI
그림 4 그래픽 기능이 별로 없는 Server Core UI
Server Core 설치를 처음 접할 때 잠시 동안은 당황할 수 있지만 약간의 시간을 들여 WMIC, NETSH, NETDOM에 다시 익숙해지면 통상적인 설치 및 구성 작업을 어렵지 않게 수행할 수 있습니다. 그리고 Regedit와 메모장은 계속 제공되므로 그래픽 도구 대신 이를 불편 없이 사용할 수 있습니다.
Server Core의 주된 이점은 기존 Windows 설치 코드 중 이러한 핵심 서버 역할에 필요하지 않은 많은 부분이 제거되었다는 점입니다. 따라서 맬웨어 공격에 취약한 영역이 줄어들고, 더 좋게는 DC에서 수행해야 할 패치 및 재부팅 작업이 적어집니다. 뿐만 아니라 디스크 사용량이 적어지고 하드 드라이브 요구 사항도 줄어듭니다. 이는 보통 큰 이점이라고 할 수는 없지만 가상화된 서버 환경에 도움은 될 수 있습니다.
그래픽 유틸리티가 부족하면 ADDS를 관리하기가 어려워지지는 않을까요? 전혀 그렇지 않습니다. 워크스테이션에서 유틸리티를 원격으로 실행하고 네트워크를 통해 도메인 컨트롤러에 연결하면 거의 모든 관리 작업을 수행할 수 있습니다. 결국에는 대부분의 DC가 Server Core 설치에서 실행될 것입니다.

DCPROMO 변경 사항
ADDS 자체에서 가장 눈에 띄는 변경 사항은 새로운 DCPROMO입니다. 이는 Windows Server 2003의 DCPROMO와 동일하게 작동하지만 사용이 쉽도록 완전히 새로 작성되었습니다. 예를 들어 DCPROMO에서 서버를 승격할 때 현재 로그인의 자격 증명을 사용할 수 있으므로 도메인 관리자 자격 증명을 입력할 필요가 없습니다. 또한 고급 모드 DCPROMO 옵션을 사용하기 위해 DCPROMO /ADV를 입력할 필요도 없습니다. 처음 표시되는 DCPROMO 대화 상자에 이러한 옵션을 사용하도록 설정할 수 있는 확인란이 있습니다. 고급 모드를 사용하면 복제할 기존 도메인 컨트롤러를 선택할 수도 있습니다. 즉, 프로덕션 DC에서 DCPROMO 복제에 따른 로드를 없앨 수 있습니다.
DCPROMO를 통해 DC를 새 도메인 또는 포리스트로 승격할 때는 포리스트와 도메인의 기능 수준을 설정하는 옵션이 제공되므로 나중에 따로 설정하지 않아도 됩니다. 승격 프로세스에서 DC를 배치할 Active Directory 사이트도 지정할 수 있는데, 이는 무인 DCPROMO 시나리오에서 매우 유용합니다. 뿐만 아니라 DCPROMO는 DC의 IP 주소를 기준으로 가장 적합한 사이트도 추천해 줍니다.
새로운 DCPROMO는 모든 구성 옵션을 한 페이지에 표시하므로 여기서 새 DC가 GC(글로벌 카탈로그), DNS 서버, 읽기 전용 DC 중 어떤 것인지를 선택할 수 있습니다. DC를 GC로 지정하기 위해 Active Directory 사이트 및 서비스 스냅인의 이곳저곳을 헤맬 필요가 없어진 것입니다.
그렇지만 새 DCPROMO의 가장 뛰어난 기능은 승격 프로세스를 시작하기 직전에 모든 DCPROMO 설정을 응답 파일에 저장하는 기능이라 할 수 있습니다. 이 방식은 수동으로 응답 파일을 구성하는 것보다 훨씬 간단할 뿐만 아니라 오류 발생 가능성도 적습니다. 모든 DCPROMO 설정을 응답 파일에 저장해 두면 이 응답 파일을 사용하여 다른 서버에서 무인 DCPROMO를 수행할 수 있습니다. 그리고 스크립트 애호가의 경우 이제는 명령줄에서 모든 DCPROMO 옵션에 액세스할 수 있습니다.

읽기 전용 도메인 컨트롤러
Active Directory 출시 초기에는 사용자가 로그인할 수 있는 모든 사이트에 도메인 컨트롤러를 배포하는 기업이 많았습니다. 일례로 은행에서는 모든 지점에 DC를 배치하는 것이 일반적이었습니다. WAN 오류가 발생하더라도 지점의 사용자가 로그인하여 로컬 네트워크 리소스에 액세스할 수 있도록 하자는 논리였지요.
당시에는 DC의 물리적 보안 필요성에 대한 이해가 부족했습니다. 오가는 사람 누구나 쉽게 접근할 수 있는 책상 밑에 도메인 컨트롤러를 두는 경우도 본 적이 있습니다. 몇 년이 지난 후에야 Active Directory 설계자들은 안전하지 않은 DC로 인한 보안 위험을 완전히 파악했고, 비로소 IT 조직에서 DC를 다시 중앙 데이터 센터로 통합하기 시작했습니다. 지점 사용자는 WAN을 통해 인증을 받아야 했지만 보안을 강화하기 위해서는 감수할 수밖에 없는 부분이었습니다.
Windows Server 2008의 Active Directory는 RODC(읽기 전용 도메인 컨트롤러) 도입을 통해 기존의 지점 배포 방식을 바꾸어 놓았습니다. 이 점이 바로 Windows Server 2008 도메인 서비스의 가장 큰 변화입니다.
Active Directory 팀은 RODC 설계 시에 지점 시나리오의 요구 사항에 중점을 두는 한편, "지점에서 발생하는 문제의 영향은 지점으로 한정한다"는 목표를 세웠습니다. 요점은 DC를 물리적으로 안전하지 않은 지점에 배포하는 경우 실질적으로 DC와 DC를 트러스트하는 컴퓨터가 손상되는 것을 막을 방법은 없지만, 지점에서 다른 도메인으로 피해가 확산되는 것은 방지할 수 있다는 것입니다.
RODC는 ADDS 인프라가 크게 변화된 형태이기는 하지만 구현이 어렵지는 않습니다. 도메인이 Windows Server 2003 포리스트 기능 수준에 있고 도메인에 Windows Server 2008 DC가 하나 이상 있기만 하면 됩니다. RODC는 단순한 지점 솔루션이 아니라 인터넷에 노출되는 환경과 DC가 네트워크 주변에 배치되어 있는 환경에도 적합합니다.

DC 도난
지점에서는 몇 가지 위협 요소를 고려해야 합니다. 첫 번째는 누군가 DC나 DC의 디스크를 훔쳐 가는 "DC 도난" 시나리오입니다. 이 경우 위험한 점은 로컬 서비스가 중단되는 데 그치지 않고, 결국 공격자가 도메인의 모든 사용자 이름과 암호에 액세스하여 권한 수준을 올림으로써 보호되는 리소스에 액세스하거나 서비스 거부 공격을 시도할 수 있다는 점입니다. 이러한 위협 요소를 제거하기 위해 RODC는 기본적으로 RODC의 DIT(디렉터리 정보 트리)에 암호 해시를 저장하지 않습니다. 때문에 도메인에 대해 사용자를 인증하기 위해 사용자가 특정 RODC에 대해 처음으로 인증을 받을 때 RODC는 도메인의 FDC(전체 도메인 컨트롤러)로 요청을 전달합니다. FDC가 요청 처리에 성공한 경우 RODC는 암호 해시에 대해 복제 요청을 보냅니다.
공격받은 RODC가 중요한 계정에 대한 암호 해시를 요청할 수도 있습니다. 이 문제는 도메인 관리자가 각 RODC에 대한 암호 복제 정책을 구성하여 방지할 수 있습니다. 암호 복제 정책은 RODC의 컴퓨터 개체에 대한 두 가지 특성으로 구성됩니다. msDS-RevealOnDemandGroup 특성은 암호를 RODC에 캐시할 수 있는 그룹, 사용자 또는 컴퓨터 계정의 고유 이름을 포함합니다. 일반적으로 RODC와 같은 사이트에 있는 사용자와 컴퓨터가 이에 해당합니다. msDS-NeverRevealGroup 특성은 암호를 RODC에 캐시할 수 없는 그룹, 사용자 또는 컴퓨터 계정의 고유 이름을 포함합니다. 예를 들어 도메인 관리자 계정의 암호 해시는 RODC에 캐시되어서는 안 됩니다. RODC가 특정 계정에 대한 암호 해시를 요청하면 FDC가 암호 복제 정책에 따라 요청을 평가하여 암호 해시를 RODC로 복제할지 여부를 결정합니다. 따라서 DC를 도난당하더라도 네트워크에서 제거될 당시 도난된 RODC에 캐시되어 있던 암호에 대해서만 보안 문제가 발생하고 중요한 암호가 도용될 위험은 없습니다.
RODC 컴퓨터 개체에는 암호를 캐시할 계정을 정확하게 결정하는 데 도움이 되는 두 가지 특성이 더 있습니다. msDS-AuthenticatedAtDC 특성은 RODC에 대해 인증을 받은 계정을 나열하고, msDS-RevealedList 특성은 현재 RODC에 암호가 저장된 계정을 나열합니다.
DC에는 사용자 및 컴퓨터 암호 해시 외에 다른 기밀 정보도 저장됩니다. KrbTGT 계정은 각 도메인 컨트롤러에서 실행되는 Kerberos KDC(키 배포 센터) 서비스의 키를 포함합니다. 일반적인 시나리오에서는 도메인의 모든 KDC가 동일한 KrbTGT 계정을 공유하기 때문에 공격자가 도난당한 DC에서 이러한 키를 검색하여 다른 도메인을 공격하는 데 사용할 수 있습니다. 그러나 각 RODC에는 고유한 KrbTGT 계정과 키가 있기 때문에 이러한 문제가 발생하지 않습니다.
응용 프로그램이 암호 또는 다른 기밀 정보를 DIT에 저장하는 경우도 많습니다. 따라서 DC를 훔친 공격자는 이러한 응용 프로그램 암호를 도용하여 응용 프로그램에 액세스할 수 있습니다. 이러한 위험을 줄이기 위해 Windows Server 2008 도메인 서비스에서는 관리자가 RO-FAS(읽기 전용 DC 복제가 제한된 특성 집합)를 정의할 수 있습니다. RO-FAS에 포함된 특성은 RODC로 복제되지 않으므로 도용한 DC에서 검색할 수 없습니다. 스키마에서 해당 attributeSchema 개체의 searchFlags 특성을 비트 9(0x0200)로 설정하여 RO-FAS에 특성을 할당할 수 있습니다.

내부의 적
지점 도메인 컨트롤러에 대한 또 다른 위협 요소로, 로컬 서버 관리자가 다른 도메인 리소스에 대한 액세스 권한을 획득하거나 서비스 거부 공격을 시도하기 위해 DC의 권한을 이용하여 자신의 권한을 승격하는 경우를 들 수 있습니다. 이 경우에도 로컬 관리자가 도메인 컨트롤러에 물리적으로 액세스할 수 있다면 이러한 위험을 막을 방법이 거의 없습니다. 하지만 공격자가 지점 도메인 컨트롤러를 사용하여 도메인의 다른 DC를 도용하지 못하도록 할 수는 있습니다.
RODC는 도메인의 전체 DC에서 도메인 컨트롤러로 트러스트되지 않습니다. 트러스트 관점에서 FDC는 RODC를 도메인의 구성원 서버로 취급합니다. RODC는 Enterprise Domain Controllers 또는 Domain Controllers 그룹의 구성원이 아닙니다. RODC 계정의 디렉터리 항목 업데이트 권한은 매우 제한되어 있기 때문에 공격자가 RODC 계정을 도용하더라도 유용한 권한을 거의 획득할 수 없습니다.
RODC는 일반적인 DS 복제 토폴로지에 표시되지도 않습니다. RODC는 도메인 컨트롤러가 아니라 일반적인 구성원 서버처럼 보이기 때문에 DS 복제 토폴로지 계산을 담당하는 각 DC에 대한 프로세스인 KCC(정보 일관성 검사기)가 RODC로부터의 연결 개체를 만들지 않습니다. 어떤 전체 DC 또는 RODC도 RODC로부터 복제하려고 시도하지 않습니다. 반대로 RODC는 전체 DC로부터의 인바운드 복제 동의를 나타내는 연결 개체를 만들기는 하지만 이 연결 개체는 RODC의 복제본에만 존재하고 다른 DC에는 이 연결 개체의 복사본이 없습니다. 복제와 관련해서 RODC는 디렉터리 개체에 대해 적합하지 않습니다. 개체가 RODC 내로 복제되기는 하지만 외부로 복제되지는 않기 때문입니다.

RODC의 관리자 역할 분리
흔히 도메인 컨트롤러에 대한 백업 실행에서부터 키보드 청소까지 모든 작업을 담당하는 로컬 서버 관리자가 지점 DC를 관리합니다. 하지만 이 경우 원격 사이트 관리자에게 도메인 컨트롤의 일반적인 유지 관리에 필요한 권한이 부여되는 보안 위험이 있으며 사이트 관리자가 마음만 먹으면 도메인에서 자신의 권한을 승격할 수 있습니다. RODC는 이러한 위협 요소를 완화하기 위해 두 가지 관리자 역할 분리 방식을 제공합니다.
첫 번째 역할 분리 방식에서는 도메인 관리자가 DCPROMO를 사용하는 일반적인 방법으로 RODC를 승격하거나 도메인 관리 권한을 부여하지 않고도 지점 사이트 관리자에게 실제 승격 프로세스를 안전하게 위임할 수 있는 두 단계로 이루어진 프로세스를 사용할 수 있습니다. 도메인 관리자는 그림 5와 같이 Active Directory 사용자 및 컴퓨터 MMC 스냅인을 사용하여 도메인에 RODC 컴퓨터 계정을 미리 만듭니다.
그림 5 RODC 컴퓨터 계정 미리 만들기
그림 5 RODC 컴퓨터 계정 미리 만들기
"Pre-create Read-only Domain Controller account(읽기 전용 도메인 컨트롤러 계정 미리 만들기)"를 선택하면 간략화된 버전의 DCPROMO가 실행됩니다. 이 DCPROMO 버전은 컴퓨터 계정을 만들고, 사이트에 RODC를 할당하고, DC의 역할을 지정하고, 암호 복제 정책을 지정하고, RODC에 대한 DCPROMO 작업 수행 권한이 필요할 사용자 또는 그룹을 정의하는 등을 비롯하여 도메인에 대한 관리자 권한이 필요한 모든 작업을 수행합니다. 위임된 관리자 또는 그룹은 RODC 컴퓨터 개체의 managedBy 특성에 저장됩니다.
이렇게 위임된 관리자는 서버 자체에서 DCPROMO를 실행할 수 있습니다. DCPROMO는 미리 만들어진 계정을 검색하여 서버를 RODC로 전환합니다. 이 방법으로 DCPROMO를 실행하는 데에는 도메인 관리자 자격 증명이 필요하지 않습니다.
RODC에서 제공되는 두 번째 관리자 역할 분리 방식은 RODC 자체에 로컬 관리자 역할을 만드는 것입니다. 이러한 역할은 컴퓨터 로컬 그룹과 비슷합니다. 즉, 이러한 역할은 RODC의 레지스트리에 저장되고 RODC에서만 평가됩니다. 하지만 관리자는 컴퓨터 관리 MMC 스냅인을 사용하는 대신 NTDSUTIL을 사용하여 로컬 RODC 역할을 관리합니다. 그림 6에는 RODC에 대한 로컬 관리자 역할이 나와 있습니다. 이러한 역할은 Windows의 기본 제공 그룹과 일대일로 대응됩니다.
Figure 6 로컬 RODC 관리자 역할 (Close Figure 6)

Account Operators
Administrators
Backup Operators
Certificate Service DCOM Access
Cryptographic Operators
Distributed COM Users
Event Log Readers
Guests
IIS_IUSRS
Incoming Forest Trust Builders
Network Configuration Operators
Performance Log Users
Performance Monitor Users
Pre-Windows 2000 Compatible Access
Print Operators
Remote Desktop Users
Replicator
Server Operators
Terminal Server License Servers
Users
Windows Authorization Access Group

RODC의 특이점
RODC는 읽기 전용이고 다른 도메인 컨트롤러가 RODC로부터 복제되지 않기 때문에 예기치 않은 동작이 몇 가지 발생하기도 합니다. 예를 들어 느린 개체, 즉 다른 곳에서는 모두 삭제되었지만 포리스트의 삭제 표시 기간 내에 복제하지 못한 특정 DC에서는 삭제되지 않은 개체는 일반적으로 DC의 아웃바운드 복제 파트너에 의해 검색됩니다. 그러나 RODC에는 인바운드 복제 파트너가 없기 때문에 느린 개체가 검색되지 않습니다.
RODC는 LDAP 업데이트 작업(추가, 수정, 삭제, 이름 바꾸기 또는 이동)을 지원하지 않습니다. 대신 작업을 지원할 수 있는 쓰기 가능한 DC에 대한 LDAP 조회를 포함한 오류를 반환합니다. LDAP 업데이트를 실행한 응용 프로그램이 조회 작업을 정상적으로 처리하지 못하면 응용 프로그램이 작동하지 않을 수 있습니다.
마지막으로 포리스트의 다른 도메인에 있는 사용자가 RODC에 대해 인증을 받으려는 경우 사용자의 도메인에 있는 DC로 인증 요청을 올바르게 전달할 수 있도록 트러스트 암호를 획득하기 위해서는 RODC가 자체 도메인의 전체 DC에 액세스할 수 있어야 합니다. RODC가 속한 도메인에 있는 전체 DC와 RODC 간의 네트워크 연결을 사용할 수 없으면 인증이 실패합니다.

세분화된 암호 정책
도메인에서 여러 암호 정책을 정의하는 기능은 Windows Server 2008 ADDS에서 가장 많이 요구되었던 기능이라 할 수 있습니다. 알다시피 Windows 2000 및 Windows Server 2003 Active Directory에서 각 도메인은 도메인의 모든 보안 주체에 적용되는 단일 암호 정책만 지원합니다. 따라서 특정 사용자 그룹에 별도의 암호 정책이 필요하면 별도의 도메인을 만들어야 합니다. 그러나 이제는 세분화된 암호 정책이라는 Windows Server 2008 ADDS의 새로운 기능 덕분에 하나의 도메인에 여러 암호 정책을 정의할 수 있게 되었습니다.
이 새로운 방법에서는 그룹을 사용하여 사용자에게 세분화된 암호 정책을 적용합니다. 먼저 CN=Password Settings Container, CN=System, DC=<domain> 컨테이너에 새 msDS-PasswordSettings 개체를 만들어 세분화된 암호 정책을 정의합니다. msDS-PasswordSettings 개체(PSO)에는 그룹 정책의 암호 정책 설정을 병렬화하는 특성이 있습니다(그림 7 참조).
Figure 7 mSDS-PasswordSettings 개체의 특성 (Close Figure 7)

특성 | 설명
mSDS-PasswordReversibleEncryptionEnabled | 해독 가능한 암호화를 사용하여 암호를 암호화할지 여부를 나타내는 부울 값입니다.
mSDS-PasswordHistoryLength | 암호 기록에 유지되는 항목의 수입니다.
mSDS-PasswordComplexityEnabled | 암호 복잡도 제한을 사용할지 여부를 나타내는 부울 값입니다.
mSDS-MinimumPasswordLength | 암호의 최소 길이를 정의하는 정수 값입니다.
mSDS-MinimumPasswordAge | 변경할 수 있게 되기까지 암호의 최소 사용 기간을 나타내는 INTEGER8 값입니다.
mSDS-MaximumPasswordAge | 이 기간이 지난 후 암호를 반드시 변경해야 하는 최대 암호 사용 기간을 나타내는 INTEGER8 값입니다.
mSDS-LockoutThreshold | 계정이 잠기기 전에 허용되는 로그인 실패 수를 나타내는 정수 값입니다.
mSDS-LockoutObservationWindow | 로그인 실패가 얼마 동안의 시간(나노초) 안에 연속적으로 발생해야 계정이 잠기는지를 나타내는 INTEGER8 값입니다.
mSDS-LockoutDuration | 계정이 잠기는 기간(나노초)을 나타내는 INTEGER8 값입니다.
그런 다음 사용자 또는 그룹 이름을 PSO의 mDS-PSOAppliesTo 다중값 특성에 추가하여 사용자나 그룹에 암호 정책을 할당합니다. OU에 암호 정책을 적용하지 않는다는 원리만 이해하면 상당히 간단한 작업이지만 다소 복잡한 문제가 있습니다.
대개 사용자는 여러 그룹에 속해 있습니다. 사용자가 여러 그룹에 속하는 구성원이기 때문에 사용자에게 상충하는 여러 암호 정책이 적용된다면 어떻게 해야 할까요? 이 경우 ADDS는 우선 순위 평가를 통해 적용할 암호 정책을 결정합니다. 예를 들면 다음과 같습니다.
  1. 그룹 구성원 자격을 통해서가 아니라 사용자 개체에 직접 연결되어 있는 암호 정책이 있으면 이 암호 정책이 적용됩니다.
  2. 사용자에게 직접 연결된 암호 정책이 여러 개 있으면 우선 순위 값(PSO의 msDS-PasswordSettingsPrecendence 특성 값에 따라 결정)이 가장 낮은 정책이 적용됩니다.
  3. 우선 순위가 같은 PSO가 여러 개 있으면 objectGUID 값이 가장 낮은 PSO가 적용됩니다.
  4. 사용자에게 직접 연결된 PSO가 없으면 ADDS가 사용자의 그룹에 연결된 PSO를 평가합니다. PSO가 둘 이상 있으면 msDS-PasswordSettingsPrecedence 특성 값이 가장 낮은 PSO가 적용됩니다.
  5. 우선 순위 값이 같은 PSO가 여러 개 있으면 objectGUID 값이 가장 낮은 PSO가 적용됩니다.
  6. 사용자와 연결된 PSO가 없으면 도메인 암호 정책이 사용됩니다.
사용자 개체에는 사용자에게 적용할 PSO를 정확하게 분류하기 위한 msDS-ResultantPSO라는 새로운 특성이 있습니다. 이 특성은 해당 사용자의 암호를 제어하는 PSO의 고유 이름을 포함합니다.
세분화된 암호 정책은 충분한 유연성을 제공하지만 정책을 신중하게 관리하고 가능한 한 단순하게 유지해야 합니다. 세분화된 암호 정책을 정의할 수 있는 기본 유틸리티는 제공되지 않으므로 ADSIEdit 또는 타사 유틸리티를 사용해야 합니다.

재시작 가능한 Active Directory 서비스
DIT 유지 관리를 위해 도메인 컨트롤러의 작동을 중단할 때마다 네트워크 서비스 수준에도 약간의 영향이 미칩니다. Windows Server 2008 DC에는 DC를 완전히 종료하지 않고 디렉터리 서비스를 중지할 수 있는 새로운 기능이 있습니다.
NET STOP NTDS 명령은 Windows Server 2008 DC에서 ADDS를 중지합니다. 이렇게 하면 DC의 LSASS(로컬 보안 기관) 프로세스는 계속 실행되지만 ADDS 관련 DLL이 모두 언로드되고 디렉터리 서비스를 사용할 수 없게 됩니다. 그러면 LSASS가 DC에 도메인 인증 요청을 전달하여 실질적으로 구성원 서버에 있는 것처럼 동작합니다. ADDS를 처리하는 DLL이 언로드되었으므로 ADDS 관련 패치를 적용하거나 DIT의 오프라인 조각 모음을 수행할 수 있습니다. ADDS는 NET START NTDS 명령만 실행하여 간단히 시작할 수 있습니다. 단, 시스템 상태 백업에서 DIT를 복원하려면 이전과 같이 디렉터리 서비스 복구 모드로 부팅해야 합니다.
디렉터리 서비스가 실제 Windows 서비스는 아니라는 점을 이해해야 합니다. 디렉터리 서비스가 여전히 LSASS의 필수 구성 요소이고 컴퓨터를 종료하지 않고는 LSASS를 중지할 수 없기는 하지만, Windows Server 2008에서 디렉터리 서비스를 시작하고 중지하는 기능은 분명 편리한 옵션입니다.

백업 및 복구
Windows Server 2008에서는 백업 및 복원 메커니즘이 전반적으로 개선되었습니다. 여기서 자세히 설명하지는 않겠지만 ADDS에 영향을 주는 몇 가지 Windows Server 백업 관련 변경 사항이 있습니다.
Windows Server 백업은 전체 디스크 볼륨을 한 번에 백업하는 볼륨 기반 백업 솔루션입니다. 또한 디스크(또는 디스크와 유사한) 장치만 백업하고 테이프는 지원하지 않습니다.
WBADMIN 명령줄 백업 유틸리티에 사용할 수 있는 시스템 상태 백업 옵션이 있습니다. 이제 WBADMIN START SYSTEMSTATEBACKUP 명령을 사용하면 도메인 컨트롤러에서 Active Directory를 복원하는 데 필요한 모든 중요 시스템 파일을 포함한 백업 이미지를 만들 수 있습니다. 그러나 백업 세트에는 볼륨을 5개까지 포함할 수 있지만 백업 세트의 볼륨에는 시스템 상태 복원에 필요한 파일만 포함할 수 있습니다. 더 번거로워진 점은 Windows Server 2008의 RC0 빌드부터는 네트워크 공유에 시스템 상태 백업을 수행할 수 없다는 점입니다. 따라서 시스템 상태 백업 이미지를 저장할 수 있는 로컬 디스크 볼륨이 필요하고, 해당 볼륨이 시스템 상태 백업 볼륨 세트에 포함되어 있지 않아야 합니다. 결과적으로 시스템 상태 백업을 수행하는 모든 도메인 컨트롤러에 새 디스크 볼륨을 추가해야 할 수도 있습니다.
시스템 상태 복원은 간단합니다. DC를 디렉터리 서비스 복원 모드로 부팅하고 WBADMIN START SYSTEMSTATERECOVERY 명령만 실행하면 됩니다. 그러면 정식 복원되지 않은 DIT가 생성됩니다. 여기서 Windows Server 2003에서와 마찬가지로 NTDSUTIL을 사용하여 특정 개체에 대한 정식 복원을 수행할 수 있습니다.
Windows Server 백업에서 중요하게 살펴보아야 할 점은 백업 이미지가 VHD(가상 하드 디스크) 형식으로 저장된다는 점입니다. 이는 Microsoft Virtual Server 2005에서 가상 디스크 이미지를 저장하는 데 사용하는 것과 같은 형식이므로, Windows Server 백업을 사용하여 만든 백업 이미지를 Microsoft Virtual Server에서 실행하는 가상 컴퓨터에 디스크 드라이브로 탑재할 수 있습니다. 그런 다음에는 일반 디스크 드라이브와 마찬가지로 백업 콘텐츠를 탐색할 수 있습니다.
ADDS 백업과 관련한 다른 변경 사항은 볼륨 섀도 복사본 서비스를 사용하여 Active Directory의 지정 시간 스냅숏을 만드는 기능입니다. NTDSUTIL을 사용하여 스냅숏을 만드는 경우 볼륨 섀도 복사본 서비스가 업데이트 작업을 통해 덮어써지기 전에 DIT에 있는 각 디스크 블록의 이전 이미지를 저장합니다. 볼륨 섀도 복사본 서비스는 이렇게 저장된 이전 이미지와 현재 버전의 DIT를 결합함으로써 오버헤드가 거의 없이 DIT의 완벽한 스냅숏을 구성할 수 있습니다. 일반적으로 스냅숏을 만드는 데에는 DIT의 크기에 관계없이 몇 초밖에 걸리지 않습니다.
이 자체만으로도 훌륭한 기능이지만 유용한 기능은 이뿐만이 아닙니다. Windows Server 2008의 ADDS에는 스냅숏 이미지를 읽기 전용 모드로 탑재하는 DSAMAIN이라는 명령줄 유틸리티가 있습니다. 이 유틸리티는 스냅숏을 만든 시점의 디렉터리 내용이 들어 있는 ADLDS 인스턴스와 유사한 독립 실행형 LDAP 서버를 제공합니다. LDP 유틸리티나 기타 LDAP 도구를 사용하여 이 디렉터리를 탐색할 수 있으며 이전 시점의 디렉터리 개체 버전을 검색할 수도 있습니다.

DFS-R을 통한 SYSVOL 복제
Windows Server 2003 R2에는 DFS-R이라는 새로운 파일 복제 메커니즘을 통합하는 개선된 DFS(분산 파일 서비스)가 있습니다. 여기에는 원본 파일과 동기화하기 위해 복제해야 하는 대상 파일 블록을 확인함으로써 파일 복제 트래픽을 크게 줄이는 원격 차등 압축이 사용됩니다. 그러나 Windows Server 2003 R2에서는 도메인 컨트롤러 간에 SYSVOL을 복제하는 데 DFS-R이 아니라 파일 복제 서비스를 여전히 사용합니다. 때문에 Active Directory 관리자는 SYSVOL 복제로 인한 문제를 계속 겪고 있습니다.
Windows Server 2008에서는 Windows Server 2008 도메인 기능 수준에서 실행할 때 DFS-R을 사용하여 SYSVOL을 복제하므로 SYSVOL 복제를 빠르고 안정적으로 수행할 수 있습니다. 이 기능 덕분에 SYSVOL에 큰 파일을 포함하여 모든 DC에서 사용 가능하도록 할 수 있습니다. SYSVOL에 DFS-R을 사용하려면 먼저 DFSRMIG 유틸리티를 사용하여 이전 SYSVOL 데이터를 DFS-R로 마이그레이션해야 합니다. 이 작업은 다음 네 단계로 진행됩니다.
  • DFS-R에 필요한 Active Directory 개체를 만듭니다.
  • 각 도메인 컨트롤러에 새 SYSVOL 파일 구조를 만듭니다.
  • 새 SYSVOL을 사용하도록 모든 도메인 컨트롤러를 전환합니다.
  • 이전 SYSVOL을 제거합니다.
SYSVOL의 크기와 도메인 컨트롤러의 수에 따라 이 작업을 실행하는 데 다소 시간이 걸릴 수도 있지만 향상되는 성능과 안정성을 통해 얻는 이점은 이러한 수고보다 더 클 것입니다.

향상된 감사 기능
Windows Server 2003 Active Directory의 감사 시스템에는 장단점이 모두 있습니다. 즉, 매우 포괄적이고 유연하며 안전한 디렉터리 변경 내용 추적 솔루션을 제공하는 반면에 몇 가지 중대한 유용성 문제가 있다는 일부 주장도 있습니다.
Windows Server 2003 도메인 컨트롤러에서 디렉터리 변경 내용에 대한 감사 기능은 전체적으로 사용하도록 설정하거나 완전히 해제할 수밖에 없습니다. 또한 사용량이 많은 기업 DC의 감사 트래픽 양으로 인해 감사 기능의 유용성이 저하될 수 있습니다. 개별 보안 설명자 작업을 통해 정말로 필요한 메시지를 생성하는 감사 시스템을 구성하는 과정은 지루하며 오류가 발생하기 쉽습니다. 감사 메시지 자체도 종종 이해하기 어려운 경우가 있고 변경된 특성의 이전 값 및 이후 값과 같은 필요한 정보가 들어 있지 않은 경우도 많습니다. 그리고 여러 도메인 컨트롤러에서 발생한 메시지를 수집하고, 연관시키고, 보관하는 작업은 기본 Windows 도구를 사용하여 쉽게 수행할 수 없습니다.
Windows Server 2008의 디렉터리 서비스 감사 시스템에서는 이와 같은 문제 일부를 해결했습니다. 첫째, 디렉터리 서비스 감사에 사용할 수 있는 DS Access, DS Changes, DS Replication 및 Detailed DS Replication이라는 네 가지 새로운 하위 범주가 추가되었습니다. 따라서 디렉터리 변경 내용만 감사하려는 경우 모든 읽기 및 복제 이벤트를 확인하지 않아도 됩니다. 그러나 감사 로그에 개체 삭제를 포함하려면 DS Access를 활성화해야 합니다. 이렇게 하면 모든 DS 개체 액세스에 대한 메시지가 생성되어 결국 너무 많은 메시지가 생성되는 결과를 다시 낳게 됩니다. 중요한 개체에 대해 감사 메시지를 생성하도록 보안 설명자를 구성하는 작업은 여전히 사용자의 몫입니다.
감사 메시지가 충분히 정리되었으므로 판독하기가 쉽고 필요한 데이터만 포함합니다. 특히 디렉터리가 변경될 경우 변경된 특성의 이전 값과 새 값이 포함된 감사 로그 항목이 생성됩니다. 이는 엄청난 발전이라고 할 수 있습니다. 유일한 단점이라면 이전 값과 새 값이 별도의 감사 로그 항목으로 표시되기 때문에 변경된 내용을 파악하려면 이들을 연관시켜야 합니다. Microsoft Audit Collection Services를 비롯한 많은 감사 로그 수집 관련 추가 기능 제품에서 이러한 상관 관계 지정을 지원합니다.

향상된 UI
Active Directory 사용자 및 컴퓨터, 사이트 및 서비스, 도메인 및 트러스트 MMC 스냅인은 지금까지 계속적으로 Active Directory 관리에 유용하게 사용되어 왔습니다. Windows Server 2008에서는 기본 관리 도구가 정리되었고 몇 가지 유용한 기능이 새로 도입되었습니다. 고급 기능을 사용하도록 설정하면 각 개체의 속성 대화 상자에 특성 편집기라는 추가 탭이 표시됩니다. 이 특성 편집기는 모든 개체 특성을 조사하고 편집할 수 있는 ADSIEdit에 사용되는 특성 편집기 탭과 동일합니다. 이제 이 탭 자체에서 userAccountControl 특성 같은 인코딩된 특성을 보다 효율적으로 디코딩할 수 있습니다. 그림 8은 완벽하게 통합된 특성 편집기를 보여 줍니다.
그림 8 Active Directory 사용자 및 컴퓨터의 특성 편집기
그림 8 Active Directory 사용자 및 컴퓨터의 특성 편집기

결론
이 기사에서 설명한 핵심 사항 외에 Windows Server 2008의 ADDS에는 다른 향상된 기능도 많이 있습니다. 예를 들어 도메인이 Windows Server 2008 도메인 기능 수준에 있는 경우 KDC에 AES-256(256비트 Advanced Encryption Standard)이 사용됩니다. DS 개체의 개체 탭에서 실수로 삭제되지 않도록 보호하는 확인란을 선택하여 개체가 실수로 삭제되지 않도록 보호할 수 있습니다. 데이터 관리 서비스를 제공하는 Extensible Storage Engine이 단일 비트 오류 수정을 사용하도록 개선되었습니다. 그 결과 디스크 하위 시스템에서 DIT 손상으로 인한 하드웨어 또는 소프트웨어 오류 발생 가능성이 줄었습니다. DNS 서비스는 요청이 DNS 데이터베이스에 완전히 로드되기 전에 요청 처리를 시작합니다. 또한 원하는 사이트에서 DC를 찾지 못할 경우 도메인에서 찾은 아무 DC나 사용하는 것이 아니라 가장 가까운 사이트에서 DC를 찾도록 DC 로케이터 모듈이 개선되었습니다. 마지막으로 이제 NTDSUTIL에서 RODC와 볼륨 섀도 복사본 서비스 스냅숏이 지원됩니다.
Windows Server 2008의 Active Directory 도메인 서비스는 다양한 면에서 눈에 띄게 향상되었습니다. 이러한 모든 변경 사항은 함께 결합되어 ADDS의 보안과 관리 효율성을 크게 향상시킵니다. 그러나 무엇보다 주목할 만한 변화는 방대한 마이그레이션 작업을 거치지 않고도 점진적으로 손쉽게 Windows Server 2008을 Active Directory 환경에 통합할 수 있게 되었다는 점입니다.

Gil Kirkpatrick은 NetPro의 CTO로서 1996년부터 Active Directory용 소프트웨어를 개발해오고 있으며, HP의 Guido Grillenmeier와 함께 인기 있는 Active Directory 재해 복구 워크샵을 진행하고 있습니다. Gil은 Directory Experts Conference(www.dec2008.com)의 창립자이기도 합니다.


 Special Coverage: Windows Server 2008: IIS 7.0 시작
Special Coverage: Windows Server 2008 Isaac Roybal

IIS 7.0 시작
한 눈에 보기:
  • IIS 7.0 아키텍처의 변화
  • IIS 7.0 관리
  • 이전 버전과의 호환성
  • IIS 7.0 문제 해결

IT 조직은 저마다의 고유한 요구 사항과 목표에 따른 각기 다른 문제를 안고 있으며, 특히 웹 사이트나 서비스의 호스팅과 관련된 경우 더욱 그렇습니다. 조직의 요구 사항을 충족하려면 웹 서버에 여러 가지 기능을 추가하고 적절히 조합해야 합니다.
여기에는 이러한 기능의 조합을 여러 서버에 복제하는 동시에 모든 서버를 효율적으로 관리해야 하는 문제가 따릅니다. IIS 7.0의 가장 중요한 변경 중 일부는 IT 조직이 웹 서버나 웹 팜을 구축할 때 바로 이러한 작업을 수행할 수 있도록 지원하는 데 목적을 두고 있습니다.
IIS 7.0에서 제공하는 우수한 기능들을 살펴보면서 이들 기능의 세부적인 내용을 독자 여러분과 공유할 수 있게 된 점에 대해 매우 기쁘게 생각합니다. 이 한 편의 기사로는 모든 기능을 다룰 수 없으므로 여기서는 IIS 7.0의 가장 중요한 기능 및 가장 중요한 변경 내용 중 몇 가지에 대해서만 중점적으로 살펴보겠습니다. 보다 자세한 내용은 IIS.net의 IIS 커뮤니티 웹 사이트를 방문하십시오.

새로운 아키텍처
IIS 7.0의 중요한 변경은 아키텍처, 요청 처리, PHP 응용 프로그램 프레임워크 지원 및 구성 저장소와 관련됩니다. IIS 6.0에서는 기능을 전부 설치하거나 전부 설치하지 않는 방법밖에는 없었습니다. 기능을 설치하려면 모든 기능을 설치해야 했고 IIS의 사용자 지정은 ISAPI를 통해서만 가능했습니다.
IIS 7.0은 웹 관리자가 기본 기능 집합을 먼저 사용해 본 다음 나중에 환경에 필요한 추가 기능을 설치하기를 원한다는 가정하에 설계되었습니다. 관리자의 환경에 대해 가장 잘 알고 있는 사람은 바로 관리자 자신입니다. 따라서 IIS 7.0은 관리자가 고유의 사용자 지정 웹 서버를 만들 수 있도록 기본 구성 요소를 제공합니다. 이렇게 하면 서버의 공격 노출 영역이 줄어들고 사용되지 않는 구성 요소를 업데이트할 필요가 없으므로 관리 오버헤드가 감소됩니다. 이러한 접근 방법의 핵심은 바로 IIS 7.0의 모듈식 아키텍처입니다.
IIS 7.0에는 서버에 설치할 기능, 즉 모듈을 선택할 수 있는 새로운 설계가 도입되었습니다. 이러한 모듈은 통합 요청 파이프라인에 직접 연결됩니다. 새로운 모듈식 설계는 공격 노출 영역의 감소는 물론 웹 서버에 필요한 공간을 줄이는 것을 비롯하여 여러 가지 장점을 제공합니다.
IIS에는 현재 40개의 기본 모듈이 포함되어 있으며, 이제 기본, 익명 및 Windows® 인증 등의 모듈은 요청 파이프라인에 독립적으로 추가할 수 있는 개별 모듈로 제공됩니다. 이러한 모듈은 8개의 하위 범주로 그룹화되어 있습니다(그림 1 참조).
그림 1 8개의 기능 영역으로 분류된 IIS 7.0 모듈
그림 1 8개의 기능 영역으로 분류된 IIS 7.0 모듈
이제 관리자 환경에 꼭 맞는 사용자 지정 웹 서버를 만들 수 있게 되었습니다. 그러나 사용자 지정 인증이나 콘텐츠 수정자 같이 40개의 기본 모듈에서 제공하지 않는 기능이 필요한 경우에는 어떻게 해야 할까요? 간단합니다. 이 경우 네이티브 코드나 관리 코드로 필요에 맞는 모듈을 작성한 다음 파이프라인에 곧바로 연결할 수 있습니다. 또한 Microsoft가 새로운 모듈을 별도로 개발하여 제공할 수 있게 되어 사용자가 다음 서비스 팩이나 주요 제품 릴리스가 나올 때까지 기다릴 필요가 없습니다. IIS 7.0에서는 40개의 기본 모듈을 고유의 사용자 지정 모듈로 덮어쓸 수 있는 기능도 제공합니다. 고유의 모듈을 만드는 방법에 대한 자세한 내용은 IIS.net을 참조하십시오.

통합 요청 파이프라인
통합 요청 파이프라인은 페이지가 제공될 때마다 순서대로 수행되어야 하는 일련의 기본 단계라고 볼 수 있습니다(그림 2 참조). 일반적으로 어떤 형태로든 인증이 수행된 후에는 콘텐츠 검색을 위한 권한 부여, 해당 콘텐츠에 필요한 처리기 결정과 실행, 필요한 로깅의 수행 등이 이루어져야 하며 마지막으로 응답을 보내야 합니다. 통합 요청 파이프라인은 IIS 7.0에 서로 다른 응용 프로그램 프레임워크를 동시에 실행할 수 있는 유연성을 제공합니다. 예를 들어 사용자 지정 로깅 모듈을 사용하여 주요 PHP 콘텐츠에 대해 폼 인증을 실행할 수 있으며, 이 모두를 하나의 파이프라인에서 실행할 수 있습니다.
그림 2 IIS 7.0 통합 파이프라인 및 모듈
그림 2 IIS 7.0 통합 파이프라인 및 모듈
통합 요청 파이프라인은 서버의 각 웹 사이트에 있으며 통합 모드와 클래식 모드의 두 가지 모드 중 하나로 실행할 수 있습니다. 기본 모드인 통합 모드에서는 특정한 기능을 파이프라인에 통합할 수 있으므로 요청 프로세스를 보다 세밀하게 제어할 수 있습니다. 호환성을 위해 클래식 모드에서는 IIS 6.0/ISAPI 기능을 ISAPI 모듈을 통해 파이프라인에 재현합니다. 이는 응용 프로그램을 IIS 7.0으로 마이그레이션하는 경우에 매우 유용합니다.

기본 설치
이제 새로운 모듈식 웹 서버를 설치하는 방법에 대해 설명하겠습니다. 기본 설치로 제공된 IIS 7.0을 보면 10개의 모듈만 포함된 것을 알 수 있습니다(Windows Process Activation Service를 포함한 경우). IIS 7.0 설치 프로그램은 웹 서버 역할을 설치하는 경우 IIS의 기본 기능, 즉 일반 HTML이나 기존 ASP 같은 정적 콘텐츠를 제공하는 데 필요한 모듈만 제공합니다. 이후에 서버에 어떤 기능을 설치할 것인가에 대한 판단은 전적으로 관리자의 몫입니다. 다음은 기본 설치에 포함되는 기능입니다.
  • 정적 콘텐츠, 기본 문서, 디렉터리 검색 및 HTTP 오류를 비롯한 일반 HTTP 기능
  • HTTP 로깅 및 요청 모니터 등의 상태 및 진단 기능
  • 요청 필터링 등의 보안 기능
  • 정적 콘텐츠 압축 등의 성능 기능
  • IIS 관리 콘솔을 비롯한 관리 도구
  • Windows Process Activation Service
보시다시피 기본 설치로 제공된 서버는 ASP.NET이나 진단 및 문제 해결 기능 같은 IIS 7.0의 새로운 기능이 포함되지 않은 최소한의 서버입니다. 서버에서 ASP.NET 및 FastCGI(PHP) 같은 동적 콘텐츠를 제공하는 추가 기능을 사용하도록 설정하는 작업은 간단합니다. Windows Server® 2008 서버 관리자 내에 있는 웹 서버 역할의 "역할 서비스 추가"에서 설치할 모듈 집합을 선택하기만 하면 됩니다.

새로운 구성 저장소
IIS 7.0의 또 다른 중요한 변경은 새로운 구성 저장소입니다. 이제 XML 구성 시스템으로 대체된 메타베이스는 이전 버전과의 호환성을 위해서만 선택적으로 설치하는 구성 요소가 되었습니다. "메타베이스도 XML이었다"라는 생각이 드실 것입니다. 물론 그렇습니다. 그러나 이전의 메타베이스는 사람이 판독하기가 어렵고 번거로웠습니다. 이제 이 메타베이스가 보다 유연성 있는 XML 시스템으로 대체되었습니다. ASP.NET과 마찬가지로 IIS 7.0에서도 간단 명료하고, 이식 가능하며, 읽기 쉬운 .config 파일을 사용합니다.
이러한 형식으로의 전환은 이제 개별 시스템에 맞게 조정되었던 메타베이스와는 달리 구성 시스템이 시스템과 독립적으로 존재한다는 것을 의미합니다. 그 결과 끌어서 놓기나 xcopy를 사용하여 구성 시스템을 다른 서버에 간편하게 이식할 수 있게 되었습니다.
이 새로운 구성 시스템은 IIS 7.0의 공유 구성이라는 새로운 기능을 활용함으로써 웹 팜에 대해 중요한 역할을 합니다. 새 구성 시스템은 이식이 가능하므로 웹 팜의 모든 노드에서 하나의 마스터 .config 파일을 공유할 수 있습니다. 공유 구성을 사용하면 알려진 적절한 테스트 환경 서버의 구성을 내보낸 다음 프로덕션 환경이나 "라이브" 환경에서 공유할 수 있습니다.
.config 파일을 내보낼 때 암호화 키 암호를 제공해야 합니다. 암호를 제공하면 권한 없이 서버의 .config 파일을 모방하려는 악성 웹 서버로부터 파일을 보호할 수 있습니다.
공유 구성을 사용하도록 설정하는 방법은 간단합니다. IIS 관리자의 서버 노드에서 작업창의 관리 섹션에 있는 공유 구성을 선택합니다. "공유 구성 사용"을 선택하고 공유하려는 구성의 실제 경로(일반적으로 UNC 공유)를 지정하며 실제 경로에 액세스하는 데 필요한 자격 증명을 입력한 다음 '적용'을 클릭하기만 하면 됩니다. .config가 있으면 파일의 암호화 암호를 확인하는 메시지가 표시됩니다. 이 프로세스가 완료되면 새 .config를 사용하도록 IIS 관리자를 다시 시작합니다.
이 새 구성 시스템은 이전의 구성 시스템과는 구조가 다릅니다. 이제 새 구성 시스템의 구조에 대해 간략히 살펴보겠습니다. 그림 3에서 볼 수 있듯이 IIS 7.0의 구성은 서버 전체 설정과 사이트별 설정이라는 두 가지 범주로 나뉩니다. 서버 전체 설정은 모두 %systemroot%\windows\system32\inetsrv\config에 있는 applicationhost.config 내에 저장됩니다. 여기에는 설치된 모든 모듈, 서버의 사이트 등이 포함됩니다. 사이트별 설정은 개별 web.config 파일에 저장됩니다.
그림 3 서버 전체 설정에는 하나의 .config 파일이 사용되고 해당 서버의 각 웹 사이트에는 개별 .config 파일이 사용됩니다.
그림 3 서버 전체 설정에는 하나의 .config 파일이 사용되고 해당 서버의 각 웹 사이트에는 개별 .config 파일이 사용됩니다.
ASP.NET을 사용해 본 적이 있다면 web.config 파일에 대해 잘 알고 있을 것입니다. IIS 7.0에서는 web.config 파일을 사용하여 ASP.NET 설정은 물론 사이트의 기본 문서 및 응용 프로그램 설정 등의 개별 웹 사이트에 고유한 설정을 저장합니다. 즉, 서버의 각 사이트마다 하나의 web.config 파일이 있습니다.
사이트의 web.config 파일은 %systemroot%\inetpub\wwwroot 같은 사이트의 실제 경로에 있습니다. 이러한 설계를 통해 앞에서 언급한 이식성이라는 장점을 사이트 수준에서 얻을 수 있습니다. 예를 들어 테스트 서버에서 사이트를 손쉽게 개발한 다음 끌어서 놓기나 xcopy를 사용하여 사이트의 web.config와 응용 프로그램 파일을 프로덕션 서버로 복사할 수 있습니다.
.config 파일을 이식하거나 공유할 때는 IP 주소와 드라이브 문자 같은 시스템별 정보에 유의해야 합니다. IIS 7.0에서는 %systemroot% 같은 OS 환경 변수를 지원함으로써 이를 간과하지 않도록 합니다. 또한 테스트 서버와 프로덕션 서버에 동일한 모듈 집합을 설치해야 합니다. 이렇게 하면 예기치 않은 응용 프로그램 오류를 방지하는 데 도움이 됩니다. 설치되지 않은 모듈을 web.config가 참조하거나 기본 모듈이 사용자 지정 모듈과 충돌하는 경우에도 오류가 발생할 수 있습니다.

웹 서버 관리
이제 사용자 지정 및 이식이 가능한 유연성 있는 새로운 웹 서버가 만들어졌습니다. 이제 웹 서버를 어떤 방식으로 관리해야 할까요? 관리는 IIS 7.0 계획 및 구축의 매우 중요한 부분이며 관리 작업을 처리하는 방법은 여러 가지입니다.
일반적으로 관리 작업은 UI 내에서의 가리키고 클릭하기 관리, 명령줄을 통한 명령 입력, 스크립트 작성을 통한 자동화의 세 가지 범주 중 하나에 해당합니다. 먼저 UI를 사용한 관리부터 살펴보겠습니다.
IIS 6.0에서는 Microsoft® Management Console(MMC) 스냅인 UI에 트리 보기와 탭 보기의 두 가지 친숙한 기본 보기가 포함되어 있었습니다. 자세한 설정을 알아보기 위해 마우스 오른쪽 단추로 클릭하고 속성을 선택하면 엄청나게 많은 옵션이 포함된 다양한 탭이 표시되었습니다.
IIS 7.0에서는 UI가 완전히 새롭게 수정되었습니다. IIS 관리자라는 이 UI는 그림 4에서 볼 수 있듯이 작업 기반 방식을 사용하도록 설계되었습니다. Windows XP 및 Windows Server 2003과 같은 하위 수준 클라이언트를 위한 원격 관리자도 제공되며, 이는 IIS.net/downloads에서 다운로드할 수 있습니다.
그림 4 IIS 7.0의 새로운 UI
그림 4 IIS 7.0의 새로운 UI
새로운 사용자 인터페이스는 왼쪽의 연결 창, 오른쪽의 작업 창 및 중앙의 작업창이나 작업 영역으로 구성됩니다. 왼쪽의 연결 관리자 트리는 부모 및 자식 노드가 포함된 IIS 6.0 트리 보기와 비슷합니다. 트리 보기에는 새 연결을 만들고, 현재 연결을 저장하고, 기존 연결을 삭제할 수 있는 기능이 새로 추가되었습니다. 작업창은 이 UI에서 가장 크게 개선된 부분으로, 작업을 수행하는 데 사용하는 두 개의 보기가 포함되어 있습니다. 기능 보기는 이전의 "탭" 보기에서 제공하던 IIS의 모든 구성 가능한 속성을 가져와서 IIS, 관리 및 보안 같은 관리 영역별로 그룹화합니다.
ASP.NET 속성도 IIS 관리자에 통합되므로 추가 MMC 스냅인을 사용할 필요가 없습니다. 구성 가능한 각 속성은 고유의 아이콘으로 표시되므로 찾기가 쉽습니다. 또한 IIS 관리자는 Windows Forms 응용 프로그램으로 만들어졌으므로 직접 작성한 사용자 지정 모듈이나 기능에 대한 플러그 인 아이콘을 손쉽게 추가할 수 있습니다.
작업창의 또 다른 보기인 콘텐츠 보기에서는 IIS 6.0에서와 비슷하게 사이트의 콘텐츠 디렉터리에 있는 내용을 보고 해당 콘텐츠에 대해 작업을 수행할 수 있습니다. 콘텐츠 보기에는 특정 콘텐츠 부분, 즉 특정 웹 페이지를 선택한 다음 기능 보기로 전환하여 선택한 콘텐츠에 대해 특정 설정을 실행할 수 있는 기능이 추가되었으며 이를 통해 페이지 수준까지 콘텐츠를 보다 세밀하게 제어할 수 있습니다.

다른 관리 방법
명령줄을 선호하는 사용자를 위해 APPCMD.exe라는 강력한 새로운 도구가 제공됩니다. 이 명령줄 도구를 사용하면 사이트 중지나 현재 .config 파일 백업 등의 간단한 작업은 물론 구성 스키마 검색 같은 복잡한 작업을 수행할 수 있습니다. 구문은 다음과 같이 매우 간단합니다.
APPCMD (command) (object-type) <identifier> </parameter1:value1 ...>.
APPCMD에 사용할 수 있는 모든 개체를 표시하려면 다음과 같이 입력하십시오.
APPCMD /?
또는 특정 개체 유형에 사용할 수 있는 명령을 보려면 다음과 같이 입력하십시오.
APPCMD (object-type) /?
모든 코드 작성자를 위해 IIS 7.0에는 Microsoft.Web.Administration이라는 관리 코드 API와 새로운 WMI(Windows Management Instrumentation) 공급자가 추가되었습니다. 이제 이 두 옵션을 통해 IIS 7.0 관리용 도구를 스크립팅하고 자동화하고 작성하는 다양한 방법을 활용할 수 있게 되었습니다. 두 옵션 모두 Windows PowerShell®과 함께 사용할 수 있으며 WMI 공급자의 경우 VBScript 및 JScript®와 함께 사용할 수도 있습니다. 자세한 내용은 blogs.msdn.com/carlosag/archive/2006/04/17/MicrosoftWebAdministration.aspx를 참조하십시오.

원격 관리 및 위임된 관리
IIS 7.0에서는 서버, 사이트 및 웹 응용 프로그램을 원격으로 관리하고 관리자가 아닌 사용자에게 관리 권한을 안전하게 위임하는 새로운 방법을 제공합니다. 먼저 새로운 원격 관리 기능과 이러한 기능을 편리하게 활용하는 방법을 살펴보겠습니다.
과거에는 두 가지 방법으로 IIS 서버를 원격으로 관리할 수 있었습니다. 하나는 원격 관리 웹 사이트를 사용하는 방법이고 다른 하나는 원격 데스크톱/터미널 서비스를 통해 UI에 액세스하는 방법이었습니다. 그러나 사용자가 방화벽 외부에 있거나 사이트에 없는 경우에는 이러한 옵션이 그다지 유용하지 않았습니다. IIS 7.0에서는 방화벽 환경에서 편리하게 사용할 수 있는 HTTPS를 통해 작동하는 원격 관리 기능을 UI에 직접 구축함으로써 이러한 단점을 보완합니다.
IIS 7.0의 원격 관리는 여러 가지 측면에서 유용합니다. 무엇보다도 로컬에서 로그온한 것과 동일한 UI 환경을 이용할 수 있습니다. 또한 HTTPS를 통해 통신이 이루어지므로 방화벽에서 포트를 열 필요가 없습니다. 마지막으로, 단일 UI에서 여러 서버를 관리할 수 있으므로 한 번에 여러 개의 원격 데스크톱 창이나 원격 웹 사이트 창을 열어 둘 필요가 없습니다.
IIS 7.0 내의 원격 관리 서비스는 실제로는 NT Service\WMSVC라는 Windows NT® 로컬 서비스 계정에서 별도의 서비스로 실행되는 소규모 웹 응용 프로그램입니다. 따라서 IIS 서버 자체가 응답하지 않는 경우에도 원격 관리 기능은 그대로 사용할 수 있습니다.
IIS 7.0에 포함된 대부분의 기능과 마찬가지로 원격 관리도 보안을 위해 기본적으로 설치되지 않습니다. 원격 관리 기능을 설치하려면 관리 도구에 있는 Windows Server 2008 서버 관리자에서 웹 서버 역할에 대한 역할 서비스를 추가해야 합니다. 원격 관리 기능을 설치하고 나면 원격 연결을 활성화하고 WMSVC 서비스를 시작해야 합니다. WMSVC 서비스는 기본적으로 중지되어 있습니다.
WMSVC 서비스의 기본 시작 설정은 '수동'입니다. 시스템을 다시 부팅한 후 서비스가 자동으로 시작되도록 하려면 설정을 '자동'으로 변경해야 합니다. 명령줄에서 다음과 같이 입력합니다.
sc config WMSVC start=auto
관리 서비스를 통해 원격 연결을 활성화할 때 ID 자격 증명, 연결 및 IPV4 주소 제한 등의 설정 목록이 표시됩니다. 이때 'Windows 자격 증명만'이나 'Windows 및 IIS 관리자 자격 증명' 중 IIS 7.0에 대한 연결 권한을 부여할 ID 자격 증명 집합을 결정해야 합니다.
첫 번째 옵션은 로컬 계정이든 도메인 계정이든 Windows 사용자 계정만 허용한다는 것을 나타냅니다. 두 번째 옵션은 Windows 사용자 계정과 IIS 7.0에 새로 도입되었으며 Windows 사용자 계정과 연결되지 않은 IIS 관리자 사용자라는 새로운 유형의 계정을 모두 포함합니다. IIS 관리자 사용자 계정을 사용하는 경우 관리자는 IIS 7.0의 컨텍스트에서만 인식되고 OS에 대한 액세스 권한이 없는 사용자 계정을 만들 수 있습니다. 마지막으로, IIS에서는 기본적으로 자체 서명된 인증서를 제공하지만, 별도로 유효한 서명된 SSL 인증서를 추가하는 것이 좋습니다. 이제 설정을 적용하고 서비스를 시작합니다.
추가적인 제어와 보안을 위해 IT 관리자는 개별 사이트나 웹 응용 프로그램의 관리 작업을 관리자가 아닌 사용자에게 안전하게 위임할 수 있습니다.
위임된 관리는 기본적으로 원격 관리이지만 액세스 범위가 개별 사이트나 웹 응용 프로그램으로 제한됩니다. 특히 여기서는 IIS 관리자 사용자 기능이 유용합니다. 사이트 외부의 소유자 같은 사용자를 위해 IIS 사용자를 만든 다음 해당 사이트나 응용 프로그램에 대한 관리 권한을 위임할 수 있습니다. 권한을 위임받은 사용자는 서버 전체 설정에는 액세스할 수 없으며 특정 사이트나 웹 응용 프로그램의 설정에만 액세스할 수 있습니다.
또한 관리자는 사용자가 변경하거나 UI에 표시할 수 있는 기능과 설정을 지정할 수도 있습니다. 예를 들어 임의의 사용자가 사이트에 사용되는 인증 유형을 변경하지 못하도록 하려면 이 기능을 '읽기 전용'이나 '상속 안 됨'으로 설정할 수 있습니다. '읽기 전용'으로 설정된 기능의 경우 사용자가 기능에 액세스하고 설정을 확인할 수는 있지만 설정을 변경할 수는 없으며 '상속 안 됨'으로 설정된 기능의 경우 위임된 사용자의 IIS 관리자 보기에 기능 아이콘이 나타나지 않습니다. 이 같은 기능 위임을 통해 웹 서버에 대한 관리 권한을 제공하지 않고도 엄격하게 제어되는 액세스 권한을 다른 사용자에게 제공할 수 있습니다.

IIS 7.0으로 전환
IIS 7.0을 설계할 때 IIS 팀은 기존의 IIS 6.0용 관리 도구 및 스크립트 중 일부를 사용할 수 있도록 지원함으로써 IIS 7.0으로의 전환이 가능하면 원활하게 이루어지기를 희망했습니다. 이전 버전과의 호환성을 중요하게 고려한 결과 IIS 7.0에서 IIS 6.0 스크립트를 사용할 수 있게 되었습니다. 이제 설치 중 IIS 6.0 메타베이스 호환성에서 실제 IIS 6.0 관리 콘솔에 이르는 모든 도구 집합을 IIS 6.0 관리 호환성 노드에 설치할 수 있습니다.
IIS 6.0 메타베이스 호환성 인프라는 ADOMapper라는 구성 요소를 사용합니다. 메타베이스 호환성 인프라는 새로운 구성 시스템에 대해 IIS 6.0 ABO(Admin Base Object) 및 ADSI(Active Directory 서비스 인터페이스) 메타베이스 스크립트를 실행하여 IIS 6.0에서 수행할 수 있는 작업으로만 구성 시스템을 제한할 수 있도록 합니다. 따라서 구성 시스템에서 새로운 IIS 7.0 속성을 읽고 쓰거나, 새 런타임 데이터에 액세스하거나, ASP.NET 속성이나 web.config 파일을 읽거나 쓸 수 없습니다.

문제 해결 및 진단
문제 해결 및 진단은 대개 시간이 많이 걸리는 번거로운 작업입니다. 대규모 웹 팜이나 심지어는 단일 서버에서조차 로그를 분석하고 문제를 재현하는 작업은 어렵고 번거로울 수 있습니다. IIS 7.0에는 이러한 번거로움과 시간 낭비를 줄이는 실패한 요청 추적이라는 도구가 도입되었습니다. 이 도구는 요청이 중단되거나 오류가 발생하거나 인증 및 권한 부여 문제를 조사하려는 경우와 같은 다양한 상황에서 유용하게 사용할 수 있습니다.
실패한 요청 추적에서는 추적 규칙을 조건으로 사용하여 오류를 검색합니다. 추적할 콘텐츠의 형식(예: 서버의 모든 콘텐츠, ASP.NET 콘텐츠만, PHP 같은 사용자 지정 콘텐츠) 및 추적이 시작되는 조건(예: 특정 상태 코드 반환, 페이지 제공에 소요된 시간, 이벤트 심각도 또는 이들의 조합)을 지정하여 추적 규칙을 작성함으로써 여러 가지 유형의 동작이나 오류를 검색할 수 있습니다.
예를 들어 사용자가 사이트를 로드하는 데 시간이 너무 오래 걸린다고 가정해 보겠습니다. 이러한 시나리오는 어떤 상황에서든 재현하기가 어렵습니다. 특히 시간당 방문 횟수가 수천 건에 이르는 경우에는 더욱 그렇습니다. 실패한 요청 추적을 사용하면 페이지를 로드하는 데 적정 시간(여기서는 2초) 이상이 걸리는 경우 이를 기록하는 추적 규칙을 추가하고 서버에서 자체적으로 문제를 재현할 때까지 기다리면 됩니다(그림 5 참조).
그림 5 문제 해결을 위해 실패한 요청 추적 사용
그림 5 문제 해결을 위해 실패한 요청 추적 사용
실패한 요청 추적은 특정 실패한 요청 조건이 감지된 경우에만 이를 기록한다는 점에서 기존의 로깅과는 다릅니다. 로그 파일 자체는 맨 위에 XML 스타일시트가 있는 XML로, 명확하고 읽기가 쉽습니다. 대부분의 다른 IIS 7.0 기능과 마찬가지로 실패한 요청 추적 기능은 기본적으로 설치되지 않습니다. 이 기능은 설치 프로그램의 상태 및 진단 섹션에 있으며 기능을 설치한 후에는 IIS 관리자 내에서 기능을 사용하도록 설정해야 합니다.
IIS 7.0은 모든 관리자에게 있어 눈부신 도약입니다. IIS 7.0의 새로운 아키텍처와 기능은 끊임없이 변화하는 환경에 유연하고 융통성 있게 적응할 수 있도록 지원합니다. 관리 기능, 이전 버전과의 호환성 도구, 문제 해결 기능이 모두 포함된 IIS 7.0을 지금 바로 배포하여 기존의 환경과 함께 원활하게 운영할 수 있습니다.

Isaac Roybal은 Microsoft Windows Server 팀의 제품 관리자로, Windows Server의 모든 웹 관련 작업을 담당하고 있습니다. Windows NT 3.51 및 IIS 4.0부터 Windows Server 작업에 참여했고 이전에는 Office Internet Platform and Operations 그룹의 운영 프로그램 관리자였으며 Windows NT 4.0, Windows 2000 및 Windows Server 2003 관련 MCSE 자격증을 소지하고 있습니다.


 Special Coverage: Windows Server 2008: Windows Server 2008의 정책 기반 네트워크 액세스
Special Coverage: Windows Server 2008 Ian Hameroff and Amith Krishnan

Windows Server 2008의 정책 기반 네트워크 액세스
한 눈에 보기:
  • 네트워크 액세스와 보안의 균형 조정
  • 정책 기반 네트워크 액세스 방식
  • Windows Server 2008의 새로운 보안 기술

모바일 사용자가 증가하고 조직의 IT 리소스에 대한 액세스 권한을 필요로 하는 사용자와 장치가 점차 다양해지면서 기존의 네트워크 경계가 사라지고 있는 현상에 대해서는
많은 자료가 나와 있습니다. 생산성을 높이기 위해 사용자와 LOB(기간 업무) 담당자는 한결같이 번거로운 절차가 없고 유동적인 연결된 환경을 요구하고 있습니다. 더욱이 이러한 복잡한 상황에 규정 준수 부담, 위협 환경의 진화, 데이터 분산화에 따른 위험 등의 문제가 더해지고 있습니다.
결과적으로 Windows® 관리자는 날로 높아지는 정보 및 네트워크 보안 요구 사항을 충족하는 동시에 리소스에 대한 손쉬운 액세스를 가능하게 해야 한다는 어려운 균형 조정 문제에 직면하고 있습니다.
이러한 과제를 하나의 솔루션으로 모두 해결할 수는 없겠지만 Windows 관리자가 현재 사용 중인 경계면 방화벽과 같은 보안 제어 기능을 보다 확대할 수 있는 도구는 많이 있습니다. 액세스 허용과 보안 사이의 적절한 균형을 실현하는 효과적인 방법 중 하나로 기존 연결 모델에서 보다 논리적인 정책 중심 방식으로 네트워크 액세스를 정의하는 모델로 전환하는 방법을 들 수 있습니다.

정책 기반 네트워크 액세스 방식
네트워킹 리소스
  • IPsec
  • 고급 보안이 포함된 Windows 방화벽
  • 서버 및 도메인 격리
  • Windows Server 2008의 NAP(네트워크 액세스 보호)

정책 기반 네트워크 액세스는 주로 네트워크 토폴로지 경계에 대한 신뢰를 기반으로 하려는 경우 발생하는 기존의 제한 사항을 없애는 데 중점을 두고 있습니다. 예를 들어 장치가 회사 방화벽이 설정된 이더넷 스위치 포트에 연결되어 있다고 해서 CRM(고객 관계 관리) 응용 프로그램을 실행하는 서버에 연결하는 데 신뢰할 수 있고 승인된 장치라고 확신할 수 있을까요?
새 모델에서는 연결 위치에 관계없이 장치의 보안 환경과 액세스를 요청하는 사용자의 ID를 기준으로 한 인증을 통해 액세스 허용 여부가 결정됩니다. 이렇게 인증한 후에는 동일한 프레임워크를 통해 액세스 가능한 정보와 리소스에 대한 권한을 부여합니다.
방어적인 환경에서 액세스에 중점을 둔 환경으로 전환하려면 연결하는 호스트의 ID와 정책 준수 여부를 확인하고, 신뢰할 수 있는 사용자 ID를 발급하고, 이러한 특성에 따라 네트워크 액세스를 동적으로 제어할 수 있는 메커니즘을 비롯한 여러 가지 핵심 요소가 마련되어야 합니다. 그리고 이러한 유동적인 부분을 간단하게 관리하기 위한 중앙 집중식 정책 저장소도 중요한 구성 요소 중 하나입니다.
정책 기반 방식을 도입하면 각양각색의 네트워크 액세스 및 호스트 보안 제어 방식을 더욱 포괄적인 솔루션으로 한데 묶는 데에도 도움이 됩니다. 결과적으로 연결 구조 상위의 논리적 계층에 네트워크 액세스 기본 규칙을 설정할 수 있기 때문에 기존 심층 방어 방식에서 한층 더 발전된 환경을 구현할 수 있습니다.
예를 들어 사용자가 조직의 무선 네트워크에 랩톱을 연결할 때 장치가 최신 보안 구성 요구 사항에 맞는지 확인할 수 있습니다. 랩톱에 최신 바이러스 백신 업데이트와 중요 보안 패치가 모두 설치되어 있고, 호스트 방화벽과 같은 끝점 보안 제어 기능이 모두 설정되어 있는 것으로 확인되면 회사 네트워크에 대한 액세스 권한이 부여됩니다. 액세스 권한이 부여된 후 사용자가 비즈니스 응용 프로그램에 액세스를 시도하면 랩톱의 상태와 사용자의 네트워크 ID를 함께 사용하여 응용 프로그램을 호스팅하는 리소스에 대한 연결을 허용할지 여부가 결정됩니다. 물리적 네트워크 인프라에 더해 이러한 논리적 계층을 운영하면 사용자가 무선 연결에서 유선 연결로, 또는 원격 액세스 연결로 전환할 때에도 지속적으로 정책을 적용할 수 있습니다.
정책 기반 네트워크 액세스를 구현하면 프로세스의 보안에 영향을 주지 않으면서 보다 원활한 연결된 환경을 제공할 수 있습니다. 관리자는 기존의 스위치 포트나 원격 액세스 게이트웨이 구성보다 수준이 향상된 네트워크 액세스 제어를 통해 보다 단순한 관리 환경을 얻을 수 있습니다. 두 경우 모두 궁극적으로는 생산성이 향상되고 조직 네트워크의 상태가 전반적으로 개선되는 효과가 있습니다. 특히 게스트(초대되는 등의 경우), 공급업체, 파트너, 직원 등 다양한 액세스 권한을 사용하는 여러 사용자를 호스팅하는 네트워크에서도 이와 같은 효과를 얻을 수 있습니다.
다른 보안 프로젝트와 마찬가지로 정책 기반 네트워크 액세스를 구현할 때에도 전체적인 운영 정책을 가장 먼저 개발해야 합니다. 대개 이러한 정책에는 다음에 대한 지침이 포함됩니다.
  • 장치 보안 정책 준수 - 정상적인 장치 상태의 정의
  • 논리적 네트워크 영역 지정 - 정상적인 상태가 아닌 장치와 승인된 장치를 구분하는 방법
  • 정보 위험 관리 - 중요 데이터를 분류하고 손상으로부터 보호하는 방법
Microsoft® TechNet 보안 센터(microsoft.com/technet/security)에서 다양한 정책 개발 관련 리소스를 확인할 수 있습니다.
액세스 정책을 개발한 후에는 정책을 쉽게 배포하고 효과적으로 적용할 수 있는 기술을 선택해야 합니다. 이러한 점에서 Windows Server® 2008이 가장 적합하다고 할 수 있습니다. Windows Server 2008은 현재 가장 안전한 Windows Server이며 정책 기반 네트워크 액세스 솔루션의 초석이 되는 강화된 보안 플랫폼을 제공하기 때문입니다. 또한 Windows Server 2008에 새로 추가되거나 향상된 많은 기능에는 네트워크에서 안전한 정책 기반 액세스를 구현하는 데 필요한 요소도 많이 있으므로 중요 정보가 손상되지 않도록 보호됩니다.

차세대 네트워킹
Windows Server 2008의 향상된 네트워크 보안 기능의 핵심에는 플랫폼의 네트워킹 기능과 관련 서비스가 크게 업데이트된 차세대 TCP/IP 스택이 있습니다. Windows Server 2008은 향상된 네트워크 성능과 확장성을 제공할 뿐만 아니라 정책 기반 네트워크 액세스 솔루션 구축을 위한 견고한 기반이 되는 일련의 통합된 네트워크 기능을 통해 보안을 강화합니다.
IPsec(인터넷 프로토콜 보안)도 이러한 기능의 하나로, Windows Server 2008에서 정책 기반 네트워크 액세스 방식에 있어 중요한 역할을 하도록 대폭 업그레이드되었습니다. 이제 IPsec을 터널링과 암호화 프로토콜로 사용하는 것보다 해당 호스트 간 네트워크 인증 기능을 활용하는 것이 핵심 용도가 되었습니다. 또한 IPsec은 계층 3에서 작동하므로 다양한 네트워크 유형에 걸쳐 네트워크 액세스 정책을 적용하는 데 활용할 수도 있습니다.
Windows Server 2008에는 IPsec 기반 네트워크 액세스 제어를 쉽게 구현할 수 있도록 여러 가지 기능이 새로 추가되거나 향상되었습니다. 이러한 기능은 모두 정책 생성, 적용 및 유지 관리를 단순화하는 데 초점을 두고 있습니다. 일례로 사용 가능한 IPsec 인증 방식의 수와 유형이 늘어났습니다. 이는 AuthIP(인증된 IP)가 도입되고 IKE(Internet Key Exchange) 프로토콜이 확장된 데 따른 결과입니다. AuthIP는 서로 통신하는 피어가 컴퓨터 자격 증명뿐 아니라 사용자 또는 상태 자격 증명까지 선택적으로 사용하여 서로를 인증하도록 요구하는 연결 보안 규칙(Windows Server 2008 IPsec 정책의 다른 이름)을 작성하는 기능을 제공합니다. 이렇게 유연성이 커지면서 스위칭 및 라우팅 인프라를 업그레이드하지 않고도 매우 복잡한 논리적 네트워크를 설계할 수 있게 되었습니다.

고급 보안이 포함된 Windows 방화벽
새로운 고급 보안이 포함된 Windows 방화벽은 방금 설명한 IPsec 기능을 기반으로 합니다. 새로운 Windows 방화벽은 방화벽 필터와 IPsec 연결 보안 규칙을 단일 정책으로 결합하여 보다 지능적인 인증 방화벽 동작이라는 또 다른 차원의 정책 기반 네트워크 액세스를 제공합니다.
그림 1에서 보듯이 이제 인바운드 또는 아웃바운드 방화벽 필터가 수행할 특정 작업을 정의할 때 허용, 차단, 안전한 경우에만 허용의 세 가지 옵션을 선택할 수 있습니다. "Allow the connection if it is secure(보안 연결만 허용)" 옵션을 선택하면 Windows 방화벽이 IPsec의 호스트 간 네트워크 인증 기능을 통해 관리자가 정의한 정책을 기준으로 연결을 요청하는 호스트 또는 사용자에 대한 승인 여부를 결정합니다. 방화벽 규칙에는 연결 권한이 있는 사용자, 컴퓨터 및 그룹을 명시할 수 있습니다. 이 기능이 기존 운영 체제 및 응용 프로그램 수준 액세스 제어 기능을 보완하는 추가 보호 계층을 제공한다는 것은 두말할 필요도 없습니다.
그림 1 인증 방화벽 규칙 정의
그림 1 인증 방화벽 규칙 정의
이제 보다 효과적이고 확장이 가능한 네트워크 액세스 관리 방식을 위해 중앙 집중식 정책을 통해 이러한 여러 가지 네트워크 보안 제어 기능을 하나로 묶는 방법을 어느 정도 이해했으리라 생각합니다.
CRM의 예를 다시 살펴보면 관리자가 프로그램의 실행 파일 또는 서비스 포트를 통해 회사의 CRM 응용 프로그램을 실행하는 서버의 인바운드 규칙을 "보안 연결만 허용" 옵션을 선택하여 만들 수 있습니다. 또한 관리자는 그림 2와 같이 동일한 방화벽 정책에서 "CRM Application Users" 그룹의 구성원만 이 네트워크 응용 프로그램에 연결할 수 있도록 지정할 수 있습니다. 이 개념을 네트워크에 있는 모든 관리되는 컴퓨터 간의 모든 네트워크 통신으로 확대하면 정책 기반 네트워크 액세스 전략에 서버 및 도메인 격리 계층이 추가되는 것입니다.
그림 2 관리자는 이 정책을 기준으로 연결이 허용되는 사용자를 지정할 수 있음
그림 2 관리자는 이 정책을 기준으로 연결이 허용되는 사용자를 지정할 수 있음

서버 및 도메인 격리
네트워크 연결을 시도하는 게스트 장치 또는 기타 관리되지 않는 장치가 점점 증가하고 있는 대부분의 조직에 있어 신뢰할 수 있는 호스트를 분리하고 보호하는 방법을 마련하는 것에 대한 중요성은 점차 커지고 있습니다. 다행스럽게도 신뢰할 수 있는 컴퓨터와 관리되는 컴퓨터를 네트워크의 다른 컴퓨터로부터 격리할 수 있는 방법은 많습니다. 그러나 이러한 방법은 비용이 많이 들고(예: 실제 연결 시스템을 별도로 실행하는 경우) 유지 관리가 어려운(예: 스위치 기반 VLAN) 경우가 많다는 점을 알아야 합니다.
서버 및 도메인 격리는 환경을 논리적으로 격리되고 안전한 네트워크로 분리할 수 있는 비용 효율적이며 관리하기 쉬운 방법을 제공합니다. 그림 3에서와 같이 기본적으로는 앞서 설명한 것과 동일한 연결 보안 규칙(IPsec 정책)을 사용하지만 Active Directory® 그룹 정책을 통해 모든 관리되는 컴퓨터에 정책을 매핑합니다. 따라서 통신을 시작하기 전에 모든 피어가 서로 인증하도록 요구하는 네트워크 액세스 정책이 생성됩니다. 이러한 격리는 계층 3에서 이루어지므로 액세스 제어 적용 범위가 물리적/지리적 경계를 넘어 허브, 스위치 및 라우터까지 확대됩니다.
그림 3 네트워크 액세스 요구 사항에 맞게 인증 요구 사항 정의
그림 3 네트워크 액세스 요구 사항에 맞게 인증 요구 사항 정의
격리된 네트워크를 구축하려면 네트워크의 여러 컴퓨터를 필요한 액세스 유형에 따라 분리해야 합니다. 그리고 격리된 네트워크의 컴퓨터는 격리된 네트워크에 없는 컴퓨터까지 포함하여 네트워크의 모든 컴퓨터와 통신을 시작할 수 있도록 정책을 정의할 수 있습니다. 반대로 격리된 네트워크에 있지 않은 컴퓨터는 격리된 네트워크에 있는 컴퓨터와 통신을 시작할 수 없습니다. 사실 격리된 네트워크의 컴퓨터는 격리된 네트워크 외부의 컴퓨터가 통신하기 위해 보내는 모든 요청을 무시합니다.
네트워크 정책을 적용하는 데에는 Active Directory 도메인 및 도메인 구성원 자격이 사용됩니다. 즉, 도메인 구성원 컴퓨터는 다른 도메인 구성원 컴퓨터에서 요청하는 인증되고 안전한 통신만 수락합니다. 또한 선택적으로, 격리된 도메인 내에서 모든 통신을 암호화하도록 요구할 수도 있습니다.
기존 네트워크 인프라 또는 응용 프로그램을 크게 변경할 필요가 없기 때문에 서버 및 도메인 격리는 비용 측면에서 매우 유리합니다. 이 솔루션은 비용적으로 막대한 피해를 입히는 신뢰할 수 있는 네트워크 리소스에 대한 공격과 무단 액세스를 막는 데 도움이 될 뿐만 아니라 네트워크 토폴로지가 변경될 때마다 지속적으로 유지 관리할 필요가 없는 정책 기반 보호막을 구축합니다.

네트워크 액세스 보호
앞서 설명한 대로 서버 및 도메인 격리 솔루션은 네트워크의 여러 컴퓨터와 서버를 논리적으로 분리합니다. 이 솔루션은 네트워크에 대한 무단 액세스를 막는 데는 도움이 되지만 권한이 부여된 컴퓨터로 인해 발생하는 보안 위협을 방지한다는 보장은 없습니다.
NAP(네트워크 액세스 보호)는 Windows Server 2008의 기본 제공 플랫폼으로, 네트워크에 연결하거나 네트워크에서 통신하는 컴퓨터가 관리자가 정의한 시스템 상태 요구 사항(보안 및 정책 준수)에 부합하도록 합니다.
권한 있는 사용자가 네트워크에 바이러스나 스파이웨어를 전파하는 경우도 종종 있습니다. 예를 들어 사용자가 휴가를 떠났을 때 관리자가 설정한 보안 요구 사항이 컴퓨터에서 지켜지지 않을 수 있습니다. 사용자가 휴가 중인 동안 요청된 패치나 서명이 배포된 경우 컴퓨터에 적용되지 않으면 이것이 곧 심각한 피해로 이어질 수 있습니다.
관리자가 네트워크에 연결하는 모든 사용자를 추적하는 것은 불가능합니다. 때문에 중앙 정책을 기준으로 네트워크에 연결하는 모든 컴퓨터의 상태 정책 준수 여부를 확인하여 정책을 준수하지 않는 경우 문제를 해결하는 자동화된 도구가 필요합니다. NAP가 바로 이러한 도구로서 정책 기반 네트워크 액세스 솔루션에 또 다른 보안 계층을 추가합니다.
클라이언트 컴퓨터의 OS(예: Windows Vista®)에서 기본 제공되거나 별도로 설치(이전 버전의 Windows 및 Windows 이외의 운영 체제의 경우)할 수 있는 NAP 에이전트가 Windows Server 2008에 포함된 정책 엔진인 NPS(네트워크 정책 서버)에 모든 정책 준수 문제를 보고합니다. 모든 장치가 준수해야 하는 정책도 이 NPS에서 정의할 수 있습니다.
물론 정책 준수 검사를 통과하지 못한 장치를 제한해야겠지만 격리하고 문제를 해결할 수 있는 옵션을 제공하는 것도 중요합니다. NAP는 장치를 자동으로 업데이트(방화벽 또는 바이러스 백신 솔루션을 사용 중인 경우)하거나 격리 영역으로 보내 수동으로 업데이트하는 옵션을 제공합니다. 이때 장치는 최신 패치, 업데이트 및 서명이 있는 업데이트 관리 서버에 액세스할 수 있습니다. 사용자가 장치를 수동으로 업데이트하고 나면 정책 준수 검사를 통과한 경우에 네트워크 액세스가 허용됩니다.
네트워크 액세스는 보편화되면서 예전보다 훨씬 더 간편해졌습니다. 반면 액세스 메커니즘을 막론하고 장치가 정상 상태이고 정책을 준수하는지를 확인해야 하는 부담도 늘어났습니다. 컴퓨터는 일반 802.1X 호환 스위치 또는 무선 액세스 지점을 통해 네트워크에 액세스하거나 VPN 또는 터미널 서비스 기반 원격 액세스 연결을 통해 원격으로 연결할 수도 있습니다. NAP는 이러한 여러 가지 메커니즘을 통해 연결하는 컴퓨터의 정책 준수를 보장할 뿐만 아니라 DHCP 서버, 802.1X 스위치, VPN 게이트웨이, 터미널 서비스 게이트웨이 또는 802.1X 호환 무선 액세스 지점에 정책을 적용하는 기능도 제공합니다.
그림 4에 표시된 네트워크는 이미 서버 및 도메인 격리 솔루션으로 격리되어 있습니다. 이러한 격리된 네트워크에 NAP를 사용하면 네트워크에 연결하는 컴퓨터의 상태 정책 준수를 보장할 수 있다는 이점이 있습니다. 시작 시에 클라이언트는 인증서 서버인 HRA(상태 등록 기관)로 SoH(상태 설명)를 보냅니다. 그러면 정책 준수 확인을 위해 HRA에서 SoH를 NPS로 전달합니다. SoH가 올바르면 HRA가 NAP 클라이언트에 상태 인증서를 발급합니다. 그러면 클라이언트가 안전한 리소스를 사용하여 안전한 IPsec 기반 통신을 시작할 수 있습니다. SoH가 올바르지 않으면 HRA가 NAP 클라이언트에 상태가 올바르도록 수정하는 방법을 알리고 상태 인증서를 발급하지 않습니다. 이 경우 NAP 클라이언트는 IPsec 인증을 위해 상태 인증서를 필요로 하는 다른 컴퓨터와 통신할 수 없습니다. 그러나 NAP 클라이언트가 정책을 준수하는 상태로 업데이트가 가능하도록 업데이트 관리 서버와는 통신할 수 있습니다.
그림 4 IPsec 적용을 사용한 네트워크 액세스 보호
그림 4 IPsec 적용을 사용한 네트워크 액세스 보호

결론
Windows Server 2008의 새로운 기능과 특징을 대략적으로만 살펴보았지만 각 구성 요소가 이전 요소를 기반으로 어떻게 구축되었는지 이해하는 것이 중요합니다. 기존의 심층 방어 방식을 변화시키는 데 기반이 되는 것은 Windows Server 2008에서 Active Directory 그룹 정책 등을 통해 제공되는 기본 정책 프레임워크입니다.
이 통합 환경 덕분에 기존에 투자한 솔루션을 그대로 활용하면서 정책 기반 네트워크 액세스 솔루션을 정의하고 배포할 수 있는 강력한 작업 기반을 얻게 되었습니다. 보다 논리적인 정책 중심 계층에서 액세스 허용 여부를 결정함으로써 "손쉬운 액세스"와 "향상된 보안" 사이의 균형을 적절하게 유지할 수 있습니다.
Microsoft는 이 기사에서 언급한 기술 분야에 대해 자세히 설명하는 문서를 많이 게시해두었습니다. 따라서 먼저 이러한 기사와 단계별 가이드를 읽어 다양한 기능의 실제 운영에 대한 경험을 쌓는 것이 좋습니다. "네트워킹 리소스" 추가 기사의 링크가 이러한 작업을 시작하는 데 도움이 될 것입니다. 그런 후 한 단계를 수행하여 다음 단계를 위한 강력한 기반을 구축하는 방향으로 각 단계를 진행해 보십시오.
예를 들어 고급 보안이 포함된 Windows 방화벽 단원에서 설명한 대로 중요 업무용 응용 프로그램에 대한 인증 방화벽 규칙 집합을 만듭니다. 이 작업에 익숙해지면 네트워크 도메인을 격리하는 연결 보안 규칙으로 확장하고, 그 기반 위에 계층 NAP를 구현할 수 있습니다. 이렇게 정책 기반 네트워크 액세스 전략을 구현하면 회사 네트워크라는 계속 변화하는 환경에 쉽게 보조를 맞출 수 있다는 이점 외에도 막대한 이점을 얻을 수 있습니다.

Ian Hameroff는 Microsoft의 보안 및 액세스 제품 마케팅 부서에서 수석 제품 관리자로 일하며 Windows Server 플랫폼 네트워킹 기술의 제품 관리와 마케팅을 담당하고 있습니다. Ian은 Windows Server 네트워킹과 관련한 시장 진입 전략 관련 업무는 물론, 서버 및 도메인 격리, 확장 가능한 네트워킹, IPv6 도입 등의 핵심 보안 및 네트워킹 이니셔티브에 중점을 둔 솔루션 관련 업무도 책임지고 있습니다.
Amith Krishnan은 Microsoft의 보안 및 액세스 제품 마케팅 부서에서 수석 제품 관리자로 일하며 네트워크 액세스 보호, 보안 무선 등의 Windows Server 네트워킹 및 보안 이니셔티브에 대한 제품 관리 및 마케팅 업무를 담당하고 있습니다. 그와 동시에 시장 진입 전략을 개발하고 이러한 솔루션을 알리는 데에도 힘쓰고 있습니다.


 Special Coverage: Windows Server 2008: 서버 관리자를 사용하여 역할 구성
Special Coverage: Windows Server 2008 Byron Hynes

서버 관리자를 사용하여 역할 구성
한 눈에 보기:
  • 역할과 기능의 차이
  • 서버 관리자를 사용하여 수행할 수 있는 작업
  • 마법사 사용
  • 명령줄에서 역할 및 기능 관리

Windows Server 2008의 전반적인 설계 의도 중 하나는 덜어 내는 것이 더 낫다는 개념입니다. 이는 불필요하게 기능을 제거한다는 의미가 아니라 꼭 필요한 것만 설치할 수 있도록 역할과 도구를 단순화하고 명확하게 만드는 전략을 의미합니다. 서버 관리자는
이러한 개념을 대표하는 Windows Server® 2008의 중요한 요소입니다.
여기에는 두 가지 측면이 있습니다. 하나는 Windows Server 2008의 토대가 되는 서버 역할 및 기능이라는 매우 중요한 개념이며 다른 하나는 서버 관리자 도구 자체입니다. 이 도구는 Windows Server 2003의 여러 도구를 대체할 뿐만 아니라 훨씬 많은 기능을 한 도구에 통합함으로써 관리자가 이를 통해 더 많은 작업을 보다 빠르고 쉽게 마칠 수 있게 해 줍니다.

역할 및 기능
Windows Server 2008에 대한 글을 읽어 보면 이전의 Windows® 환경에서는 들어보지 못했던 "작업"이나 "역할"과 같은 용어를 접하게 됩니다. 먼저 이러한 용어가 IT 전문가에게 의미하는 바가 무엇인지 설명하겠습니다.
Windows Server 2008 개발 주기의 초반에 우리 팀은 사용자가 서버 제품을 사용하는 방식을 정확하게 파악하기 위해 많은 시간을 투자했습니다. 이 노력은 지금도 계속되고 있습니다. 그 결과 일반적으로 특정 작업을 수행할 목적으로 서버를 배포한다는 사실을 알게 되었습니다. 별로 새로운 것처럼 보이지 않을 수도 있지만 우리 중 일부는 사람들이 그저 서버를 마련할 목적으로만 서버를 구입하는 것은 아니라는 점에 놀라워했습니다. 더 중요한 사실은 수없이 많은 작업을 수행하기 위해 서버를 배포하는 것은 아니라는 점이었습니다. 그보다는 어떠한 구체적인 작업을 수행하는 데 서버를 사용하려고 했습니다. 물론 예외도 있지만 특정 기능을 수행하기 위해 서버를 마련하는 경우가 대부분이었습니다.
이와 같은 결과에 따라 우리 팀은 이러한 "특정한 목적"을 작업이라고 하는 보다 넓은 범주로 분류했습니다. 예를 들어 데이터베이스 작업과 응용 프로그램 서버 작업이 있습니다. 작업은 그 의미가 광범위하고 다소 모호한 점도 있으므로 작업 내에 역할이라는 하위 범주를 만들었습니다. 역할이란 서버가 수행해야 할 하나의 매우 구체적인 일을 말합니다. 여러분이나 조직의 다른 사용자가 네트워크의 서버를 어떤 식으로 부르는지 생각해 보십시오. 대부분의 사용자는 서버를 파일 서버, 도메인 컨트롤러, 인쇄 서버, 웹 서버 등으로 간주합니다. 바로 이것이 서버에 대해 대부분의 사용자가 갖는 관점이므로 Windows Server 2008에서는 이와 같은 접근 방법으로 역할이라는 개념을 다룹니다.
Windows Server 2008에는 ID 및 액세스 관리(Active Directory®의 일부로 제공되는 역할), 인프라(파일 서버, 인쇄 서버, DNS 등), 응용 프로그램(웹 서버 역할, 터미널 서비스 등)이라는 크게 세 가지 기본 역할 범주가 있습니다.
Windows Server 2008에는 Active Directory 인증서 서비스, 네트워크 정책 및 액세스 서비스, Windows Server 가상화를 비롯하여 약 17개의 서버 역할이 포함될 예정입니다. 또한 스트리밍 미디어 서비스 등의 추가 역할도 다운로드할 수 있게 될 것입니다.
역할마다 기사를 하나씩 작성해야 할 만큼 다루어야 할 내용은 많습니다. 몇 가지 역할에 대해서는 이번 호 TechNet Magazine에서 자세히 다루고 있으며 일부 역할은 이미 이전 기사에서 살펴봤고 일부 역할은 아직 개발 중에 있습니다. 각 역할에 대해 자세히 알아보아야 합니다. 먼저 technet2.microsoft.com/windowsserver2008/en/servermanager/default.mspx에서 제공하는 정보부터 확인하는 것이 도움이 될 것입니다.
Windows Server 2008 배포를 시작할 때 각 서버에 설치할 역할을 선택해야 합니다. 이러한 역할 기반 배포 개념은 Windows Server 2008을 효과적으로 사용하고 리소스를 융통성 있게 분배하는 데 매우 중요한 역할을 합니다.
역할 목록에 BitLockerTM 드라이브 암호화 및 NLB(네트워크 부하 분산) 같은 항목은 포함되지 않습니다. 이들은 역할이 아니라 기능이며, 필요하기는 하지만 사용자가 특별히 이러한 기능을 사용하기 위해 서버를 구입하는 것은 아니기 때문입니다. 반면 역할은 사용자가 시스템을 구입한 목적을 나타내는 작업을 말합니다. 예를 들어 사용자는 부하 분산을 구현하기 위해 서버를 구입하지는 않지만 웹 사이트를 운영할 목적으로는 서버를 구입합니다. 그뿐만 아니라 NLB는 웹 서버에 반드시 필요한 기능일 수도 있지만 서버를 구입할 이유는 되지 않습니다.
관리자는 서버의 모든 기능을 설치하고 실행하는 대신 필요한 기능만 선택할 수 있습니다. 그림 1에서는 Windows Server 2008에 포함된 기능을 보여 줍니다. 필요한 역할과 기능만 설치함으로써 안정성과 보안이 향상됩니다. 따라서 설치하지 않은 기능이나 역할로 인해 사용될 리소스에 대해 걱정할 필요가 없으며, 설치하지 않은 기능의 문제를 해결하거나 역할에 보안을 설정하는 일에 염려할 필요도 없습니다.
Figure 1 Windows Server 2008에 포함된 기능 (Close Figure 1)

Microsoft .NET Framework 3.0 기능
BitLocker 드라이브 암호화
BITS 서버 확장
연결 관리자 관리 키트
데스크톱 경험
그룹 정책 관리
인터넷 인쇄 클라이언트
iSNS(인터넷 저장소 이름 서버)
LPR 포트 모니터
메시지 큐
다중 경로 I/O
피어 이름 확인 프로토콜
qWave(Quality Windows Audio Video Experience)
원격 지원
원격 서버 관리 도구
이동식 저장소 관리자
RPC over HTTP 프록시
NFS용 서비스
SMTP 서버
SAN 저장소 관리자
단순 TCP/IP 서비스
SNMP 서비스
UNIX 기반 응용 프로그램용 하위 시스템
텔넷 클라이언트
Telnet Server
TFTP(Trivial File Transfer Protocol) 클라이언트
장애 조치(failover) 클러스터링
네트워크 부하 분산
Windows Server 백업
Windows 시스템 리소스 관리자
WINS(Windows Internet Naming Service) 서버
무선 LAN 서비스
Windows 내부 데이터베이스
Windows PowerShell
Windows Process Activation Service
이러한 개념의 결정체가 바로 Server Core 설치 옵션입니다. Server Core는 이 기사의 범위를 벗어나므로 여기서는 자세히 다루지 않지만, 간단히 말해 사용되지 않는 역할과 기능을 제외하여 이들을 하드 디스크에 복사하지 않거나 사용 가능한 상태로 설정하지 않는 개념으로 볼 수 있습니다. 일반 설치와 Server Core 설치의 가장 큰 차이점 중 하나는 일반 설치의 경우 언제든지 추가 역할을 설치할 수 있도록 필요한 리소스를 포함하며 모든 역할을 지원하는 반면, Server Core 설치는 셸에 대한 GUI조차 없으며 제한된 수의 역할만 지원한다는 것입니다.

서버 관리자
Windows Server 2008의 새로운 서버 관리자 콘솔을 사용하면 조직의 다양한 서버 역할을 관리하고 보호하는 작업을 쉽게 처리할 수 있습니다. 기본적으로 Microsoft® Management Console(MMC)의 확장된 형태인 서버 관리자를 사용하면 서버 성능에 영향을 주는 거의 모든 정보와 도구를 보고 관리할 수 있습니다. 서버 관리자는 서버의 ID 및 시스템 정보를 관리하고, 서버 상태를 표시하고, 서버 역할 구성의 문제를 식별하고, 서버에 설치되어 있는 모든 역할을 관리할 수 있는 하나의 통합 콘솔을 제공합니다. 또한 서버 관리자는 사용자 서버 관리, 사용자 서버 구성, Windows 구성 요소 추가/제거와 같은 Windows Server 2003의 여러 기능을 대체합니다.
경우에 따라 서버 관리자를 사용하면 관리자가 서버를 배포하기 전에 SCW(보안 구성 마법사)를 실행해야 할 필요성이 낮아질 수 있습니다. 서버 관리자는 설치된 역할이 올바르게 작동할 수 있도록 서버를 구성합니다. 예를 들어 서버 관리자는 Windows 방화벽을 자동으로 구성합니다. 그러나 역할이 추가된 다음 제거되었거나 보안 설정을 보다 정확하고 강력하게 관리하려는 경우에는 SCW가 여전히 유용할 수 있습니다. 자세한 내용은 이번 호에 실린 Jesper Johansson의 Security Watch 칼럼, "Windows Server 2008에서 SCW 사용"(microsoft.com/technet/technetmag/issues/2008/03)을 참조하십시오.
Windows Server 2008에 대한 작업을 하면서 우리 팀은 관리자가 어떤 방법으로 작업을 수행할지에 대해 면밀히 검토했습니다. 그 결과 도구와 마법사로 작업을 보다 쉽게 수행하는 방법을 찾게 되었고, 여러 도구에서 이동하면서 작업을 해야 하는 경우가 너무 많은 것을 알게 되었습니다. 이에 따라 Windows Server 2008 전반에 걸쳐, 특히 서버 관리자에 대한 중요한 설계 목표를 세웠습니다. 즉, 서버 관리자가 한곳에서 다양한 유형의 작업을 수행할 수 있도록 지원하여 관리자의 업무 효율을 개선하는 것이었습니다. 그 결과 이제 서버 관리자를 사용하여 다음과 같은 작업을 수행할 수 있게 되었습니다.
  • 서버에 설치된 서버 역할과 기능을 보고 변경할 수 있습니다.
  • 서비스 시작/중지 및 로컬 사용자 계정 관리와 같은 서버 관련 관리 작업을 수행할 수 있습니다.
  • 서버에 설치된 역할과 관련된 관리 작업을 수행할 수 있습니다.
  • 서버 상태를 확인하고 중요한 이벤트를 식별하고 구성 문제를 분석할 수 있습니다.
  • GUI나 명령줄을 사용하여 역할, 역할 서비스 및 기능을 설치하거나 제거할 수 있습니다.
서버 관리자 콘솔은 수많은 정보와 기능을 작은 공간에 요약하여 제공합니다. 그림 2에서는 서버 관리자 콘솔의 파일 서비스 역할 노드를 보여 줍니다. 콘솔의 주 창에는 서버 요약, 역할 요약, 기능 요약, 리소스 및 지원이라는 네 개의 축소 가능한 구역이 포함되어 있습니다.
그림 2 파일 서비스 역할을 보여 주는 서버 관리자 콘솔
그림 2 파일 서비스 역할을 보여 주는 서버 관리자 콘솔
서버 요약 구역에는 컴퓨터 정보와 보안 정보라는 두 개의 하위 구역이 포함되어 있습니다. 컴퓨터 정보 하위 구역에는 컴퓨터 이름, 도메인, 로컬 관리자 계정 이름, 네트워크 연결 및 운영 체제의 제품 ID가 표시됩니다. 구역의 명령을 사용하여 이러한 정보를 편집할 수도 있습니다. 보안 정보 하위 구역에는 Windows 자동 업데이트와 Windows 방화벽의 사용 여부 및 관리자 또는 다른 사용자에 대해 Windows Internet Explorer® 보안 강화 구성이 설정되어 있는지 여부가 표시됩니다. 마찬가지로 이 구역에도 이러한 설정을 편집하고 모든 고급 옵션을 표시하는 데 사용할 수 있는 명령이 있습니다.
역할 요약 구역에는 서버에 설치된 역할을 보여 주는 표가 포함되어 있습니다. 이 구역의 명령을 사용하면 역할을 추가 또는 제거하거나 특정 역할을 관리할 수 있는 보다 자세한 콘솔로 이동할 수 있습니다.
기능 요약 구역에서는 서버에 설치된 기능을 보여 주는 표를 제공합니다. 이 구역에서는 기능을 추가하고 제거할 수 있습니다.
마지막으로, 리소스 및 지원 구역에는 서버가 사용자 환경 개선 프로그램과 Windows 오류 보고에 참가하고 있는지 여부가 표시되며, 서버의 의견 수집 프로그램 참가 여부를 구성할 수 있습니다. 이 구역에서는 Windows Server TechCenter 및 기술 라이브러리에 있는 관련 추가 도움말이나 자료를 빠르게 찾을 수도 있습니다.

역할 정보
서버 관리자에는 설치된 각 역할에 대한 홈 페이지가 있습니다. 이러한 각 역할 홈 페이지의 리소스 및 지원 구역에서는 역할이나 역할의 일부가 작동하는 권장 구성 또는 시나리오 메뉴를 제공합니다. 각 권장 구성은 특정 역할에서 최상의 결과를 얻기 위해 수행해야 할 작업을 자세히 보여 주는 검사 목록으로 연결됩니다.
서버 관리자에서 특히 뛰어난 점 중 하나는 중요한 정보와 명령을 모아 꼭 필요한 위치에 표시한다는 것입니다. 예를 들어 파일 서비스 역할 홈 페이지를 볼 때는 해당 역할과 관련된 모든 이벤트를 즉시 볼 수 있으므로 이벤트 뷰어를 실행하거나 필터를 설정할 필요가 없습니다.
수백 개의 이벤트를 생성할 수 있는 일부 역할의 경우 역할 홈 페이지에서 직접 사용자 지정 필터를 만들어 사용할 수도 있습니다. 측면 메뉴에서 이벤트 필터링을 선택하여 표시되는 이벤트의 범위를 좁힐 수 있습니다. 이 대화 상자에는 이벤트 로그 뷰어에서 사용할 수 있는 모든 필터링 옵션이 제공되지는 않지만, 사용자는 특정 역할과 관련된 이벤트만 빠르게 볼 수 있으며 관련되지 않은 다른 이벤트를 필터링할 필요가 없습니다.
마찬가지로, 시스템 서비스(역할에 필요하지만 전체 시스템의 일부인 서비스) 및 역할 서비스(역할에 관련된 서비스)의 상태를 볼 수 있습니다. 일부 역할의 경우에는 역할의 사용 가능한 부분과 설치될 역할 서비스의 다양한 집합을 선택할 수 있습니다. 역할 홈 페이지에서 직접 서비스를 시작하고 중지할 수 있으며 해당 역할에 대해 시스템 서비스로 모니터링해야 할 서비스를 지정할 수도 있습니다.

마법사 사용
올바르게 설계된 마법사를 사용하면 가끔식 수행되는 작업을 처리할 때 시간을 절약하고 오류를 방지할 수 있습니다. 이전 버전의 Windows Server에서는 서버에 설치된 구성 요소를 변경하려면 사용자 서버 구성, 사용자 서버 관리 및 Windows 구성 요소 추가/제거 기능을 사용해야 했습니다. 종속성 확인이 제한적이었고 Windows 구성 요소 추가/제거 기능을 사용하는 경우 한 역할의 설치가 완료되어야만 다른 역할을 추가할 수 있었습니다.
이제 서버 관리자 마법사를 사용하면 여러 역할, 역할 서비스 및 기능을 하나의 세션에서 설치하거나 제거할 수 있습니다. 그러나 더욱 중요한 점은 서버 관리자 마법사를 단계별로 실행할 때 종속성 확인이 자동으로 수행되어 필요한 모든 역할과 역할 서비스가 올바르게 설치된다는 것입니다. 또한 기본 권장 보안 설정으로 역할이 구성됩니다. 필요한 경우에는 보안 구성 마법사를 사용하여 보안 설정을 수정할 수 있습니다. 서버 관리자 마법사 중 하나로 한 번의 세션만 실행하고 나면 서버 배포 준비가 완벽하게 끝납니다.
서버 관리자에는 역할 추가 마법사, 역할 서비스 추가 마법사, 기능 추가 마법사, 역할 제거 마법사, 역할 서비스 제거 마법사, 기능 제거 마법사를 비롯한 수많은 마법사가 포함되어 있습니다.
짐작할 수 있듯이 서버에 역할을 추가하는 역할 추가 마법사는 역할 간의 종속성을 자동으로 확인하여 선택한 각 역할에 필요한 모든 역할과 역할 서비스가 설치되었는지 확인합니다. 또한 터미널 서비스 및 Active Directory 인증서 서비스와 같은 일부 역할의 경우 역할 추가 마법사는 설치 프로세스의 일부로 역할의 구성 방법을 지정할 수 있는 구성 페이지도 제공합니다. 그림 3에서는 역할 추가 마법사의 서버 역할 선택 페이지를 보여 줍니다.
그림 3 역할 추가 마법사를 사용하여 서버 역할 선택
그림 3 역할 추가 마법사를 사용하여 서버 역할 선택
대부분의 역할은 서버 관리자에서 역할 서비스라고 하는 여러 하위 요소로 구성됩니다. 복잡한 역할을 설치한 경우 역할 서비스 추가 마법사를 사용하여 역할에 역할 서비스를 추가할 수 있습니다.
역할 추가 마법사와 마찬가지로 기능 추가 마법사를 사용하면 기능을 설치할 수 있습니다. 한 세션에서 하나 이상의 기능을 시스템에 추가할 수 있습니다.
이름에서 알 수 있듯이 역할 제거 마법사를 사용하면 서버에서 역할을 제거할 수 있습니다. 이 마법사는 자동으로 종속성을 확인하여 제거되지 않는 역할에 필요한 역할이나 역할 서비스는 그대로 남아 있도록 합니다. 역할 서비스 제거 마법사를 사용하면 설치된 역할에서 역할 서비스를 제거할 수 있고, 기능 제거 마법사를 사용하면 시스템에서 기능을 제거할 수 있습니다.

명령줄
특별한 이유도 없이 마법사를 꺼리는 IT 전문가를 간혹 만날 때가 있습니다. 이들 중 그 이유를 적극적으로 피력하는 사람은 거의 없지만 많은 수의 IT 전문가들이 명령줄 사용을 선호합니다. 명령줄을 사용하면 반복과 스크립팅이 가능하므로 더 편리할 수 있습니다. 서버 관리자는 이전의 ocsetup 및 pkgmgr 도구보다 훨씬 쉽게 사용할 수 있는 ServerManagerCmd.exe라는 명령줄 도구를 제공합니다. ServerManagerCmd.exe를 사용하면 역할, 역할 서비스 및 기능을 설치하고 제거할 수 있습니다. 또한 간단한 매개 변수를 사용하여 설치되어 있거나 설치할 수 있는 모든 역할, 역할 서비스 및 기능의 목록을 표시할 수 있습니다.
이 명령줄을 사용하면 역할, 역할 서비스 및 기능을 편리하게 무인 설치하거나 무인 제거할 수 있습니다. 또한 명령줄을 사용하면 한 명령 인스턴스에서 단일 역할, 역할 서비스 또는 기능을 설치 또는 제거하거나, 서버 관리자 명령을 통해 XML 응답 파일을 사용하여 하나의 명령 인스턴스에서 여러 역할, 역할 서비스 및 기능을 추가하거나 제거할 수 있습니다. 작업 로그를 보거나 쿼리를 실행하여 설치되어 있거나 설치할 수 있는 역할, 역할 서비스 및 기능의 목록을 표시할 수 있습니다.
이 명령줄 도구의 핵심은 지정한 역할이 설치될 경우 서버가 정확히 어떤 식으로 변경될지 보여 주는 –whatif 매개 변수입니다. 예를 들어 그림 4에서는 다음 명령의 실행 결과를 보여 줍니다.
ServerManagerCmd -install Web-Server
-allsubfeatures -whatif
추가 분석을 위해 이 출력을 파일에 저장할 수 있습니다.
그림 4 –whatif 매개 변수를 사용하여 서버에 발생할 변경 내용 보기
그림 4 –whatif 매개 변수를 사용하여 서버에 발생할 변경 내용 보기
ServerManagerCmd.exe의 구문 및 세부 사항에 대해 자세히 살펴보려면 go.microsoft.com/fwlink/?LinkId=107113의 "서버 관리자 기술 개요 부록"을 참조하십시오.
이 기사를 작성하는 데 도움을 준 Gaby Kaplan에게 감사의 뜻을 전합니다.

Byron Hynes는 Microsoft Enterprise and Partner Group의 엔터프라이즈 기술 전략가로, 이전에는 Windows Server 부서에서 일했으며 컨설턴트와 강사로 활동했습니다. 문의 사항이 있으면 bhynes@microsoft.com으로 연락하십시오.


 Special Coverage: Windows Server 2008: System Center를 사용하여 Windows Server 2008 배포
Special Coverage: Windows Server 2008 Tim Mintner

System Center를 사용하여 Windows Server 2008 배포
한 눈에 보기:
  • Configuration Manager 배포 기능
  • 서버 작업 시퀀스 생성 및 사용자 지정
  • 서버 역할 추가
  • 컴퓨터별 변수 설정

System Center Configuration Manager 2007이 출시되면서 서버 관리자는 클라이언트 관리자가 지난 수년 간 사용해 온 것과 동일한 운영 체제 배포 도구를
사용할 수 있게 되었습니다. 이전에는 서버 관리자가 CD 또는 DVD를 사용하여 직접 Windows Server®를 설치한 후 몇 시간에 걸쳐 해당 서버를 구성하는 경우가 많았습니다. 일부 관리자의 경우 여기서 더 나아가 unattend.txt 파일을 만들고 RIS(원격 설치 서비스)를 사용하여 무인 설치 루틴을 구축함으로써 서버 콘솔에 직접 가지 않고 자동 설치하는 프로세스를 만들었습니다. 보다 능숙한 관리자의 경우 Windows Server 2003 ADS(자동 배포 서비스)를 활용하여 전체 서버 구축 프로세스를 완전히 자동화하기도 했습니다. Windows Server 2008을 통해 Windows NT® 4.0 이후 서버 설치 프로세스가 처음으로 크게 변경되었습니다.
Windows Server 2008 배포에 사용되는 기본 배포 도구와 기술은 Windows Vista®와 동일합니다. 이러한 변경 사항으로 인하여 서버 관리자는 이전에 사용하던 도구를 업데이트하거나 교체해아 합니다. RIS는 WDS(Windows® 배포 서비스)로 교체되었고 ADS는 Windows Server 2008 배포를 지원하지 않습니다. 서버 및 클라이언트 배포에서 변경된 기술과 도구에 대한 보다 자세한 내용은 technetmagazine.com/ issues/2006/11/Deployment에 나와 있는 "Windows Vista 배포에 대해 알아야 할 10가지 사항"을 참조하십시오.
Windows Server 2008과 Windows Vista의 기본 배포 기술이 동일하므로 이 두 제품 배포 시 동일한 도구와 지식을 사용할 수 있게 된다면 정말 좋을 것입니다. System Center Configuration Manager와 Microsoft® Deployment는 바로 이러한 통합 도구 집합을 제공합니다. 본 문서에서는 이 Configuration Manager와 Microsoft Deployment를 사용하여 Windows Server 2008을 배포하는 방법에 대해 설명합니다.

Configuration Manager를 사용하여 OS 배포
Windows Server 2008 배포를 시작하기 전 Configuration Manager의 OS 배포 기능을 살펴 보도록 하겠습니다. Configuration Manager Console을 실행하고 컴퓨터 관리로 이동하면 그림 1과 같이 OSD(Operating System Deployment)를 위한 새로운 시작 영역이 나타납니다.
그림 1 운영 체제 배포 페이지
그림 1 운영 체제 배포 페이지
이 페이지에서는 해당 환경에서 수행된 운영 체제 배포의 요약 정보를 볼 수 있으며 작업 시퀀스 관리(Manage Task Sequences) 및 부팅 이미지 관리(Manage Boot Images) 등의 기타 운영 체제 배포 노드를 탐색할 수도 있습니다. 여기에는 배포 상태 및 배포 환경의 상태를 보여 주는 웹 보고서 목록이 나와 있으며 리소스에는 운영 체제 배포를 위한 지원 문서로 연결해 주는 빠른 참조가 표시되어 있습니다.
탐색창의 노드에는 OS 배포를 수행하기 전 구성해야 하는 모든 항목이 나와 있습니다. 이러한 항목은 다음과 같습니다.
부팅 이미지 배포 프로세스 도중 사용될 Windows PE 2.0 기반의 부팅 이미지 목록이 포함되어 있습니다.
컴퓨터 연결 주로 클라이언트 배포에 사용되는 것으로 기존 컴퓨터를 새 시스템에 매핑하여 사용자 환경을 안전하게 관리할 수 있도록 해줍니다. 여기에는 또한 알 수 없는 컴퓨터 계정을 Configuration Manager 데이터베이스로 가져오는 마법사가 포함되어 있어 운영 체제가 설치되지 않은 서버를 배포할 수 있게 해줍니다.
운영 체제 이미지 서버 및 클라이언트 배포를 위해 사용자 지정된 WIM(Windows 이미징 형식) 이미지를 포함하는 패키지 목록이 들어 있습니다.
운영 체제 설치 패키지 Windows Server 2008용 원본 파일 등 OS 배포를 위한 전체 원본 파일이 포함된 패키지가 들어 있습니다.
작업 시퀀스 여러 단계가 포함되어 있으며 각 단계에서는 사용자 개입 없이 실행되는 명령줄 작업을 정의합니다. 작업 시퀀스는 운영 체제 배포 프로세스의 구동 엔진으로 운영 체제를 배포 및 구성하는 데 필요한 모든 단계를 제공합니다.
드라이버 다양한 모델의 서버 및 클라이언트 컴퓨터에 필요한 모든 드라이버를 관리할 수 있는 중앙 리포지토리입니다.
드라이버 패키지 Configuration Manager 분산 위치에 배포할 수 있으며 서버 또는 클라이언트 컴퓨터를 배포할 때 사용되는 한 개 이상의 드라이버 집합이 들어 있습니다.
배포 관리자의 운영 체제 배포 기능을 간단히 살펴보았으니 이제 Windows Server 2008 배포를 수행하는 데 필요한 모든 정보를 모아 보겠습니다.

Windows Server 2008 배포 준비
Microsoft Deployment란?
Microsoft Deployment는 Business Desktop Deployment(BDD) 2007의 다음 버전으로 데스크톱 및 서버 배포에 필요한 도구와 프로세스를 공용 배포 콘솔 및 지침 모음으로 통합해 줍니다. 이 제품은 System Center Configuration Manager 2007을 사용하여 데스크톱과 서버를 위한 새로운 배포 및 작업 시퀀싱 기능을 추가합니다.
Microsoft Deployment는 Microsoft 다운로드 센터에서 제공되며 지침 자료는 Microsoft TechNet의 데스크톱 배포 TechCenter 및 서버 배포 TechCenter에서 온라인으로 확인할 수 있습니다. 보다 자세한 내용과 이러한 자료 및 기타 관련 콘텐츠에 대한 링크는 microsoft.com/deployment를 참조하시기 바랍니다.

Configuration Manager를 사용하여 Windows Server 2008을 배포하기 위해서는 다음과 같은 항목이 필요합니다.
MDT(MicrosoftDeployment Toolkit) 서버 및 클라이언트 운영 체제 배포를 위한 도구와 모범 사례 설명서를 제공하며 Configuration Manager Console에 직접 통합되어 배포 프로세스를 간소화해 줍니다. Microsoft Deployment Toolkit은 microsoft.com/deployment에서 다운로드할 수 있습니다.
사용자 지정 부팅 이미지 Configuration Manager는 Windows PE 2.0을 기반으로 하는 32비트 및 64비트 부팅 이미지를 제공하며 VBScript, Windows Management Instrumentation(WMI) 및 HTML 응용 프로그램(HTA)에 대한 지원을 포함합니다. 그러나 배포 프로세스가 별도의 SQL Server® 데이터베이스에 정보를 요청하도록 하려면 ADO 지원이 포함된 사용자 지정 부팅 이미지가 필요합니다.
운영 체제 설치 패키지 Windows Server 2008 DVD의 원본 파일을 포함합니다.
MDT 패키지 Microsoft 배포 도구 모음에 필요한 모든 스크립트 및 지원 파일을 포함합니다.
Configuration Manager 클라이언트 패키지 Configuration Manager 클라이언트를 위한 설치 파일이 들어 있습니다.
설정 패키지 Windows Server 2008의 자동 설치에 사용되는 unattend.xml 파일과 Microsoft 배포 도구 모음과 함께 사용되는 customsettings.ini 파일이 포함되어 있습니다.
Sysprep 패키지 Windows Server 2003 또는 Windows XP를 배포할 때만 사용되며 컴퓨터가 운영 체제 이미지를 캡처할 수 있도록 준비하는 데 필요한 sysprep 파일을 제공합니다.
드라이버 특정 모델의 서버에 필요한 모든 드라이버를 포함합니다.
패키지 원본 및 캡처된 WIM을 위한 네트워크 공유 위에 나열된 패키지와 사용자 지정된 WIM 이미지가 저장되는 UNC(Universal Naming Convention) 위치입니다.
이 모든 패키지를 생성하려면 많은 작업을 수행해야 하는 것처럼 보일 수 있습니다. 여기 반가운 소식이 있습니다. Microsoft Deployment Toolkit을 사용하면 한 개의 마법사가 모든 패키지를 만들어 줍니다.
Microsoft Deployment Toolkit을 Configuration Manager와 함께 사용하려면 이 도구 키트를 Configuration Manager 관리 콘솔과 동일한 컴퓨터에 설치해야 합니다. 그런 다음 시작 | 모든 프로그램 | Microsoft Deployment Toolkit에서 Configure ConfigMgr Integration(ConfigMgr 통합 구성)을 선택한 다음 Configuration Manager Site Server의 이름 및 사이트 코드를 지정하고 Next(다음)를 클릭합니다. 이렇게 하면 Microsoft Deployment Toolkit에서 제공하는 Configuration Manager Console에 대한 확장명이 추가됩니다. 이제 Configuration Manager Console을 실행하고 Task Sequences(작업 시퀀스)를 마우스 오른쪽 단추로 클릭하면 그림 2와 같이 새로운 옵션을 볼 수 있습니다.
그림 2 Import Microsoft Deployment Task Sequence(Microsoft Deployment 작업 시퀀스 가져오기)
그림 2 Import Microsoft Deployment Task Sequence(Microsoft Deployment 작업 시퀀스 가져오기)
Import Microsoft Deployment Task Sequence(Microsoft Deployment 작업 시퀀스 가져오기)를 선택하고 아래 단계를 수행하여 필요한 패키지와 Windows Server 2008 Task Sequence(작업 시퀀스)를 생성하십시오.
  1. Choose Template(템플릿 선택) 화면에서 Server Task Sequence(서버 작업 시퀀스)를 선택한 후 다음을 클릭합니다.
  2. Task Sequence Name(작업 시퀀스 이름)과 해당 작업 시퀀스를 설명하는 내용을 입력한 후 다음을 클릭합니다.
  3. 서버를 도메인에 참여시키기 위한 사용자 계정 자격 증명을 포함하여 도메인 또는 작업 그룹에 참여하기 위한 세부 정보를 입력합니다. 또한 조직에 관한 정보와 제품 키를 입력하고 캡처할 사용자 지정 WIM 이미지의 UNC 경로 및 파일 이름을 제공합니다. WIM 파일을 저장할 네트워크 공유에 연결하기 위한 사용자 자격 증명을 입력하고 다음을 클릭합니다.
  4. 부팅 이미지 화면에서 새 부팅 이미지 패키지를 생성하도록 선택하고 부팅 이미지 패키지에 대하여 패키지 원본 디렉터리로 사용할 네트워크 위치를 입력한 후 다음을 클릭합니다.
  5. 부팅 이미지 패키지에 대한 패키지 이름, 버전 정보 및 참고 사항을 입력한 후 다음을 클릭합니다.
  6. 플랫폼(x86 또는 x64), ADO 지원, 필요한 모든 글꼴 옵션, 부팅 이미지를 위한 사용자 지정 배경(필요한 경우), Windows PE 이미지에 포함시킬 모든 추가 폴더 등을 선택한 후 다음을 클릭합니다.
  7. MDT Package(MDT 패키지) 화면에서 새로운 Microsoft Deployment Toolkit 파일 패키지를 생성하도록 선택하고 패키지 원본으로 사용할 UNC 경로를 입력한 후 다음을 클릭합니다.
  8. MDT 패키지의 이름, 버전, 언어, 제조업체 및 참고 사항을 입력한 후 다음을 클릭합니다.
  9. OS 이미지의 경우 새로운 OS Install Package(OS 설치 패키지)를 생성하도록 선택하고 Windows Server 2008 원본 파일 경로와 패키지 원본 디렉터리로 사용할 UNC 위치를 입력한 후 다음을 클릭합니다.
  10. Client Package(클라이언트 패키지)의 경우 새로운 Configuration Manager 클라이언트 패키지를 생성하도록 선택한 후 다음을 클릭합니다.
  11. Settings Package(설정 패키지)의 경우 새로운 Settings Package(설정 패키지)를 생성하도록 선택하고 이 Settings Package(설정 패키지)의 패키지 원본으로 사용할 UNC 위치를 입력한 후 다음을 클릭합니다.
  12. Sysprep Package(Sysprep 패키지)의 경우 Sysprep 파일이 필요 없는 것으로 선택한 후 다음을 클릭합니다.
이제 마법사가 부팅 이미지와 모든 패키지를 만듭니다. 패키지, 부팅 이미지, Operating System Install Packages(운영 체제 설치 패키지) 및 Task Sequences(작업 시퀀스)를 확장하면 생성된 모든 패키지와 작업 시퀀스를 볼 수 있습니다. 모든 패키지를 만든 후 분산 위치에 배포합니다.
이러한 패키지 이외에도 특정 서버 하드웨어에 드라이버를 추가해야 하는 경우가 자주 발생합니다. 이러한 작업은 Configuration Manager 드라이버 저장소에 드라이버를 추가하고 배포 도중에 사용될 드라이버 패키지를 생성하여 수행할 수 있습니다.
Driver Catalog(드라이버 카탈로그)로 드라이버를 가져오고 드라이버 패키지를 만들려면 Configuration Manager Console로 이동하여 드라이버를 마우스 오른쪽 단추로 클릭한 후 가져오기를 선택합니다. 지정된 UNC 경로의 모든 드라이버를 가져오도록 선택한 다음 특정 서버 모델에 대하여 수집한 모든 드라이버가 있는 UNC 경로를 입력합니다. 이 작업을 마쳤으면 다음을 클릭합니다.
Drivers Details(드라이버 상세 정보) 페이지에서 가져오려는 INF 파일을 선택하고 필요한 경우 범주에 드라이버를 지정합니다(범주는 특정 서버 모델 유형을 기준으로 구분될 수 있음). 다음을 클릭하고 Add Drivers to Package(패키지에 드라이버 추가) 페이지에서 New Package(새 패키지)를 클릭합니다. 이름, 참고 사항 및 드라이버 패키지에 대하여 패키지 원본으로 사용할 UNC 경로를 지정하고 확인을 클릭합니다. Update distribution points when finished(완료 시 분산 위치 업데이트)를 선택한 후 다음을 클릭합니다.
Add Driver to Boot Images(부팅 이미지에 드라이버 추가) 페이지에서 앞서 생성한 부팅 이미지를 선택하고 Update distribution points when finished(완료 시 분산 위치 업데이트) 상자에 표시합니다. 다음을 클릭한 후 요약 페이지에서 다시 다음을 클릭하여 마법사를 종료하고 드라이버를 가져온 후 드라이버 패키지를 생성합니다.

작업 시퀀스 편집
이제 Windows Server 2008을 설치하는 데 필요한 모든 패키지와 작업 시퀀스를 만들었으니 기본 작업 시퀀스의 몇 가지 작업을 사용자 지정할 수 있습니다. 작업 시퀀스를 수정하려면 해당 작업 시퀀스를 마우스 오른쪽 단추로 클릭하고 편집을 선택합니다. 그림 3과 같이 Microsoft Deployment Server task sequence(서버 작업 시퀀스) 템플릿이 표시됩니다.
그림 3 기본 작업 시퀀스 사용자 지정
그림 3 기본 작업 시퀀스 사용자 지정
높은 수준에서 볼 때 작업 시퀀스는 각각의 특정 작업을 수행하는 일련의 명령줄 항목입니다. 각 작업은 구성 가능한 특정 속성을 포함할 수 있으며 옵션 탭에 특정 작업을 실행해야 하는지 평가하는 조건을 포함할 수도 있습니다. 예를 들어 작업 시퀀스의 첫 번째 작업에서는 그림 4와 같은 조건이 설정될 수 있습니다.
그림 4 옵션 탭에서 작업 또는 조건 설정을 해제할 수 있음
그림 4 옵션 탭에서 작업 또는 조건 설정을 해제할 수 있음
이 예에서는 "Disable this step(이 단계 해제)" 확인란이 표시되었으므로 해당 작업이 기본적으로 해제되어 있습니다. 작업이 설정된 경우 현재 지정된 조건에 따라서만 실행됩니다.
Windows Server 2008을 배포하기 전 수정이 필요한 보다 일반적인 작업으로는 Format and Partition Disk(디스크 포맷 및 분할), 유효성 검사, Apply Operating System Image(운영 체제 이미지 적용), Apply Network Settings(네트워크 설정 적용) 등이 있습니다.
Format and Partition Disk(디스크 포맷 및 분할) 작업에서는 서버 배포를 위해 디스크 분할 구조를 생성하는 방식을 정의할 수 있습니다. 기본 설정은 첫 번째 디스크의 모든 공간을 사용하는 한 개 파티션을 생성하는 것입니다. 이런 구성으로 서버를 배포하고 싶지 않으면 이 설정을 변경하여 원하는 디스크 레이아웃을 지정합니다.
유효성 검사 작업에서는 메모리 및 프로세서 속도와 같은 일부 기본적 요구 사항을 확인할 수 있습니다. 예를 들어 서버 배포에 대한 회사 표준이 2GB 메모리인 경우 이를 요구 사항으로 설정할 수 있으며 서버가 이 요구 사항을 충족해야 설치가 계속됩니다.
Apply Operating System Image(운영 체제 이미지 적용) 작업에서는 배포할 특정 이미지를 구성할 수 있습니다. 예를 들어 Windows Server 2008에 대한 원본 파일을 사용하는 경우 Server Standard, Server Enterprise, Server Datacenter, Server Standard Core, Server Enterprise Core 및 Server Datacenter Core 등을 배포할 수 있는 옵션이 있습니다. 사용할 적절한 이미지를 선택해야 하며 이는 배포하려는 Windows Server 2008의 버전에 따라 달라집니다.
Apply Network Settings(네트워크 설정 적용) 작업에서는 네트워크 카드에 대한 정적 IP 주소를 구성하는 것은 물론 도메인이나 작업 그룹에 참여하기 위해 설정을 변경할 수도 있습니다. 이 작업을 통해 정적 IP 주소를 설정할 수는 있지만 그럴 경우 이 작업 시퀀스는 한 개 서버에 대해서만 실행됩니다. 변수로 정적 IP 주소를 설정하여 단일 작업 시퀀스를 여러 서버에 사용할 수 있는 방법은 나중에 설명하겠습니다.

서버 역할 설치 및 구성
지금까지 운영 체제 설치와 관련된 항목을 구성하기 위해 작업 시퀀스를 수정하는 방법에 대해 알아보았습니다. 그런데 Microsoft Deployment Toolkit에서는 서버 역할을 설치 및 구성할 수도 있습니다. 예를 들어 Windows Server 2008을 읽기 전용 도메인 컨트롤러와 파일 서버를 실행하는 지점 서버에 배포하기 위해 작업 시퀀스를 구성할 수 있습니다.
이 작업을 제대로 수행하려면 작업 시퀀스 편집기에서 Install Software(소프트웨어 설치) 작업으로 이동하여 추가 | MDT | Install Roles and Features(역할 및 기능 설치)를 선택한 후 새로 생성된 Install Roles and Features(역할 및 기능 설치) 작업에서 그림 5와 같이 Active Directory 도메인 컨트롤러와 파일 서버 모두를 선택합니다.
그림 5 역할 및 기능 설치
그림 5 역할 및 기능 설치
이제 읽기 전용 도메인 컨트롤러의 설정을 구성해야 합니다. 작업 시퀀스 편집기에서 추가 | MDT | Configure ADDS(ADDS 구성)를 차례로 선택합니다. 새로 생성된 이 Configure ADDS(ADDS 구성) 작업에서 새로운 읽기 전용 도메인 컨트롤러 복제본을 생성하도록 선택하고 다음 속성에 대한 값을 지정합니다.
  • 기존 도메인 DNS 이름
  • 복제 원본 도메인 컨트롤러
  • 계정
  • 복구(안전 모드) 암호

변수 사용
명심해야 할 사항은 작업 시퀀스가 사용자에게 제공하는 가장 강력한 기능 중 하나는 배포 도중 작업 시퀀스의 거의 모든 속성을 변수로 동적 설정할 수 있다는 점입니다. Configuration Manager와 Microsoft Deployment 모두 변수를 설정 및 사용하는 몇 가지 메커니즘을 제공합니다.
Configuration Manager에서는 변수를 컴퓨터 변수 또는 모음 변수로 설정하거나 작업 시퀀스 내부에 직접 설정할 수 있습니다. Microsoft Deployment의 경우 customsettings.ini 파일, 백 엔드 데이터베이스 또는 웹 서비스를 통해 변수를 설정할 수 있습니다. 설정할 수 있는 변수 목록은 technet.microsoft.com/bb632442.aspx에 나와 있습니다.
특정 서버에 정적 IP 주소를 설정하는 것을 예로 들어 봅시다. 앞서 설명했듯 정적 IP 주소는 Apply Network Settings(네트워크 설정 적용) 작업에서 작업 시퀀스 내부에 직접 설정할 수 있습니다. 그러나 이 방법은 작업 시퀀스를 특정 서버에 대해서만 사용할 수 있으므로 가장 좋은 방법이라고 할 수는 없습니다.
따라서 이러한 방법 대신 작업 시퀀스를 그대로 두고 변수를 통해 IP 주소를 설정할 수 있습니다. 아래에는 정적 IP 주소를 Computer 변수로 설정하는 방법이 단계별로 나와 있습니다.
  1. Configuration Manager Console에서 System Center Configuration Manager | Site Database(사이트 데이터베이스) | Computer Management(컴퓨터 관리) | Collections(모음)를 차례로 선택합니다.
  2. 컴퓨터에 컴퓨터당 변수를 할당하려면 컴퓨터가 속한 모음을 찾아 확장하고 해당 컴퓨터를 마우스 오른쪽 단추로 클릭한 후 속성을 클릭한 다음 변수 탭을 클릭합니다.
  3. 사용자 지정 변수와 관련 값을 지정하려면 New(새 항목) 아이콘을 클릭하여 <New> Variable(<새> 변수) 대화 상자를 엽니다.
  4. <New> Variable(<새> 변수) 대화 상자에서는 변수의 이름과 이 변수를 Configuration Manager 2007 콘솔에 표시할 것인지 여부를 지정해야 합니다. 정적 IP 주소의 경우 다음과 같은 변수를 추가합니다.
  • OSDAdapter0IPAddressList
  • OSDAdapter0SubnetMask
  • OSDAdapter0Gateways
  • OSDAdapter0DNSServerList
구성된 변수는 그림 6과 같아야 합니다.
그림 6 컴퓨터 변수를 사용하여 정적 IP 주소 설정
그림 6 컴퓨터 변수를 사용하여 정적 IP 주소 설정

작업 시퀀스 배포
작업 시퀀스를 모두 구성하고 변수를 설정했으니 이제 Windows Server 2008을 배포할 준비가 완료되었습니다. Configuration Manager는 PXE(Pre-Boot eXecution Environment), 작업 시퀀스 부팅 가능한 미디어, 독립 실행형 미디어, 기존 시스템에 대한 표준 알림 사용 등과 같이 운영 체제 배포를 위한 몇 가지 메커니즘을 제공합니다.
이해하기 쉽도록 부팅 가능한 미디어용의 작업 시퀀스를 만드는 방법에 대해 간단히 설명하겠습니다. Configuration Manager Console에서 Task Sequences(작업 시퀀스)로 이동한 다음 작업 메뉴에서 Create Task Sequence Media(작업 시퀀스 미디어 만들기)를 선택합니다. Select Media Type(미디어 유형 선택) 페이지에서 Bootable Media(부팅 가능한 미디어)를 선택하고 다음을 클릭합니다. Media Type(미디어 유형) 페이지에서 미디어 유형으로 CD를 지정하고 이 미디어 파일의 이름을 지정합니다. Security(보안) 페이지에서 미디어를 보호하기 위한 암호나 자체 서명된 인증서를 지정할 수 있습니다. 부팅 이미지를 지정합니다. 완료했으면 Confirmation(확인) 페이지로 이동하여 Finish(마침)를 클릭합니다. 이 방법과 다른 메커니즘을 통해 배포하는 방법을 보다 자세히 확인하려면 technet.microsoft.com/bb681029.aspx에 나와 있는 설명서를 참조하십시오.

결론
지금까지 System Center Configuration Manager 및 Microsoft Deployment를 사용하여 Windows Server 2008 배포, 파일 서버 및 도메인 컨트롤러 등의 역할 추가, 컴퓨터별 변수 설정, 작업 시퀀스의 Bootable Media(부팅 가능한 미디어)를 통해 운영 체제 배포 등을 수행하는 방법에 대해 알아보았습니다. 실제 서버 배포 작업은 훨씬 복잡할 수 있지만 본 문서의 정보는 서버 및 클라이언트 배포 도구의 통합을 시작하는 데 매우 유용할 것입니다.

Tim Mintner는 Microsoft Deployment Toolkit을 중점적으로 다루는 Microsoft Solutions Accelerator 팀의 수석 소프트웨어 개발 엔지니어이며 14년 이상 고객의 Microsoft 운영 체제 배포를 지원해 왔습니다. Tim에게 문의 사항이 있으시면 tmintner@microsoft.com으로 연락하십시오.


 Special Coverage: Windows Server 2008: Windows Server 2008의 감사 및 규정 준수
Special Coverage: Windows Server 2008 Rob Campbell, Joel Yoker

Windows Server 2008의 감사 및 규정 준수
한 눈에 보기:
  • 중요성이 증대되고 있는 규정 준수
  • 환경의 변경 파악
  • 보안 이벤트 감사의 문제점
  • 감사의 기술적 측면

정보 기술의 세계에서는 끊임 없이 변경 사항이 발생합니다. 대부분의 IT 조직은 조직의 환경에서 발생하는 이와 같은 변경을 파악하는 데 점점 더 많은 부담을 느끼고 있습니다. IT 환경의 복잡함과 규모가 증대될수록
관리상의 부주의 및 실수로 인한 데이터 노출이 미치는 영향도 막대해집니다. 오늘날과 같이 이러한 사고에 대해 책임을 묻는 사회에서 IT 조직은 정보를 안전하게 보호해야 하는 법적인 책임을 안고 있습니다.
따라서 환경의 변경을 감사하는 작업이 매우 중요한 일로 부각되었습니다. 그 이유는 무엇일까요? 감사는 오늘날과 같이 규모가 크고 고도로 분산된 IT 환경의 변경을 파악하고 관리할 수 있는 수단을 제공합니다. 이 기사에서는 대부분의 조직에서 직면하고 있는 일반적인 문제와 IT 부서가 감당해야 하는 규정 준수 및 규제의 전반적인 추세, Windows® 감사의 몇 가지 기본 사항에 대해 살펴본 다음 Windows Server® 2008 및 Microsoft® System Center Operations Manager 2007의 ACS(Audit Collection Services) 기능을 사용하여 포괄적인 감사 전략을 수립하는 방법을 알아봅니다.

감사의 문제점
뉴스 헤드라인만 보더라도 알 수 있듯이 데이터 노출은 일상적인 문제가 되어 버렸습니다. 이와 같은 사고가 발생하면 대개 해당 조직은 법적 소송에 휘말리거나 재정적인 손실을 부담해야 하며 홍보에서도 문제가 발생하게 됩니다. 어떤 변경이 발생했는지 설명하거나 문제를 신속하게 파악하는 능력은 데이터 노출 사고가 미치는 영향을 줄이는 데 매우 중요한 역할을 합니다.
예를 들어 여러분의 조직에서 특정 고객층의 PII(개인 식별 정보)를 관리한다고 가정해 보십시오. 조직에서 관리 대상인 시스템에 포함된 정보를 보호할 수 있는 다양한 방법을 보유하고 있다 하더라도, 데이터 손상이 발생할 가능성은 여전히 존재합니다. 이 경우 조직에서 적절한 감사를 수행한다면 정확히 어떤 시스템이 손상되었는지, 더 구체적으로는 어떠한 데이터가 손실되었는지 쉽게 알 수 있을 것입니다. 감사를 수행하지 않으면 데이터 손실로 인한 영향이 훨씬 커질 수 있으며, 이는 대개 데이터 손실로 인한 손상의 범위를 예측할 수 있는 방법이 없기 때문입니다.
그렇다면 왜 IT 조직은 사전에 감사를 수행하지 않을까요? 사실을 얘기하자면 대부분의 조직은 감사의 기술적인 측면을 완전하게 이해하고 있지 못합니다. 고위 관리자는 일반적으로 백업 및 복원과 같은 개념에 대해서는 이해하고 있습니다. 그러나 환경의 변경을 감사하는 데 따르는 고유의 복잡함은 전달하기 어려운 메시지입니다. 그 결과 대개 큰 사고가 발생한 후에야 감사에 대한 질문이 제기되곤 합니다. 예를 들어 기본 감사 기능이 실행되어 있긴 하지만 특정 변경을 감사하도록 시스템이 구성되어 있지 않다면 계획 부족으로 인해 해당 정보는 수집되지 않을 것입니다.
더욱이 감사된 보안 이벤트에는 IT 전문가가 다루어야 할 몇 가지 고유의 문제가 있습니다. 이러한 어려움을 야기하는 요인 중 하나로는 오늘날과 같은 대규모 컴퓨팅 환경에서의 분산된 시스템을 꼽을 수 있습니다. 이러한 환경에서는 언제 어떤 시스템이나 시스템 집합에서든 변경이 발생할 수 있으며 이는 수집 및 집계의 어려움으로 이어집니다. 이는 상관 관계라는 또 다른 문제를 야기합니다. 발생하고 있는 현상의 의미를 올바르게 이해하려면 대개 단일 시스템 및 여러 시스템에서 발생한 이벤트 간의 관계를 분석해야 합니다.
일반적으로 감사는 전통적인 조직의 경계를 초월한다는 점에서도 문제가 발생합니다. 여러 가지 이유로 인해 다양한 조직 구조나 팀 구조가 존재할 수 있으며 이들을 연결하기가 쉽지 않을 수 있습니다. 대부분의 조직에는 디렉터리 서비스 팀, 메시징 인프라 팀, 데스크톱 팀이 있지만 이러한 영역을 모두 담당하는 보안 팀은 대개 하나뿐입니다. 또한 조직의 보안 전담 직원이 모든 영역에 상주하지 않을 수도 있습니다. 예를 들어 대부분의 경우 지점에서는 보안 이벤트 로그 관리를 비롯한 모든 작업을 한 사람 또는 소규모 인원으로 구성된 팀에 의존합니다.
마지막으로, 이벤트의 양이 엄청납니다. 감사된 보안 이벤트는 다른 종류의 이벤트 로그보다 그 양이 훨씬 많습니다. 수집된 이벤트의 수가 많으므로 로그를 효과적으로 보관하고 검토하기가 어렵습니다. 또한 이와 같은 정보의 보존 요구 사항을 명시하는 현재의 규정 및 제안된 규정은 오늘날과 같은 컴퓨팅 인프라에서 이러한 부담을 줄이는 데 전혀 도움이 되지 않고 있습니다.
과거에는 정보 액세스에 대한 감사는 단순히 알고 싶은 욕구와 보안을 유지하려는 시도로 요약할 수 있었습니다. 그러나 조직과 조직의 최고 관리자가 정보의 손실이나 적절한 대비책 결여에 대한 법적인 책임을 져야 하는 현재의 경우 IT 관리자는 자신이 담당하는 환경에 적용되는 모든 규정에 대해 잘 알고 있어야 합니다. 다국적 기업의 경우 국가마다 정보 및 정보 보호와 관련된 고유의 규정을 적용해야 하므로 감사에 따른 문제가 더욱 복잡해집니다. 그림 1에는 기존의 규정 준수 관련 법률 조항 및 이에 따라 IT 조직에 부여되는 책임이 나열되어 있습니다.
Figure 1 규정 및 이에 따른 IT 전문가의 책임 (Close Figure 1)

규정 | 책임
Sarbanes-Oxley Act(SOX), 2002년 | 404항에서는 정보 시스템의 역할을 명시하고 있으며 공개적으로 거래를 하는 기업에게 해당 기업이 내부 회계를 엄격하게 관리하고 있음을 증명하는 자료를 매년 제출하도록 요구하고 있습니다.
Health Insurance Portability and Accountability Act(HIPPA) | 의료 관련 데이터의 보안 및 개인 정보 보호에 대해 명시합니다. "Security Rule"에서는 의료 관련 데이터의 관리적, 물리적, 기술적 측면의 보호책에 대해 다루고 있습니다.
Electronic Discovery(eDiscovery) | 문서에 액세스하는 사람 및 액세스 방법에 대한 책임을 비롯하여 문서 보존 및 액세스 표준을 정의합니다.
Federal Information Security Management Act(FISMA), 2002년 | 미국 정부 시스템, 다양한 법률 집행 기관과의 협력, 통제권 확립, 상용 제품 및 소프트웨어 기능의 승인을 위한 포괄적인 정보 보안(INFOSEC) 프레임워크를 제공하기 위한 연방 정부 명령법입니다. 3544항에서는 IT 통제를 비롯한 기관의 책임에 대해 다룹니다.
Federal Information Processing Standards(FIPS) Publication 200 | 연방 정보와 정보 시스템에 대한 최소 보안 요구 사항을 명시하고 있으며 NIST Special Publication(SP) 800-53에 있는 권장 사항을 간략하게 보여 줍니다. NIST SP800-53의 AU-2(Auditable Events) 조항에서는 정보 시스템은 여러 구성 요소의 감사 레코드를 시스템 수준의 시간 관련 감사 추적에 컴파일하는 기능과 감사된 이벤트를 개별 구성 요소별로 관리하는 기능, 그리고 조직이 정기적으로 감사 가능한 이벤트를 검토할 수 있도록 하는 기능을 제공해야 한다고 명시하고 있습니다.
이러한 모든 법률적인 규제를 고려했을 때 IT 전문가는 어떤 준비를 해야 할까요? IT 관리자와 기술 전문가는 조직의 내/외부에 제공할 수 있는 명확하면서도 간략한 전략을 마련해야 합니다. 여기에는 적절한 감사 전략을 개발하는 것이 포함되며 이를 위해서는 사전 대응적 평가와 투자가 필요합니다. 여기서 중요한 사항은 감사는 설계의 후기 단계에서 고려할 대상이 아니라는 점입니다. 그러나 안타깝게도 현실에서는 이런 경우가 너무나 빈번히 발생하고 있습니다.
IT 조직이 직면한 이와 같은 문제는 일반적으로 사람, 프로세스 및 기술의 조합을 통해 해결할 수 있습니다. 감사의 경우 프로세스가 가장 중요합니다. 따라서 무엇보다도 감사의 기본 사항을 완벽하게 이해함으로써 규정 준수와 관련된 조직의 필요 및 요구 사항에 대응할 수 있어야 합니다. 이제 Windows 감사의 몇 가지 기본 사항을 살펴본 다음 Windows Server 2008과 Windows Vista®에서 변경된 내용에 대해 자세히 알아보겠습니다.

보안 이벤트 감사
감사된 모든 이벤트는 Windows 보안 이벤트 로그에 기록됩니다. 이러한 이벤트는 통상 즉각적인 조치를 취할 수 있는 것이 아니며 대개는 정보 제공을 목적으로 합니다. 각 이벤트는 발생한 특정 액세스 유형에 대해 간단히 '감사 성공' 또는 '감사 실패'를 기록합니다. 보안 이벤트 로그는 색 구분을 통해 문제를 쉽게 식별할 수 있는 응용 프로그램 이벤트 로그나 시스템 이벤트 로그와는 다릅니다. 예를 들어 응용 프로그램 이벤트 로그나 시스템 이벤트 로그에서 문제를 찾으려면 빨간색 이벤트를 보면 됩니다.
보안 이벤트 로그의 경우 감사된 이벤트의 양이 너무 많아서 이벤트가 표시되지 않을 뿐 아니라, 앞에서 언급했듯이 보안 데이터의 상관 관계로 인해 중대한 문제가 야기될 수 있다는 점에서 다른 이벤트 로그와 차별화됩니다. 단일 시스템에서 발생한 단순한 데이터 노출조차도 문제가 될 수 있습니다. 이 경우 보안 이벤트 로그를 분석하여 데이터 액세스에 사용된 계정이 어떤 것인지 확인해야 하며 이를 위해 관리자는 로그를 추적하여 계정을 찾아내야 합니다. 안타깝게도 오늘날의 정교한 공격은 대개 교묘하게 조정 및 분산되어 발생하므로 피해자는 이러한 종류의 분석을 하기가 몹시 어렵습니다.
따라서 Windows의 보안 이벤트 로그에 정보가 기록되도록 하는 핵심 요소인 감사 정책 및 SACL(시스템 액세스 제어 목록)에 대해 올바르게 이해하는 것이 중요합니다. 감사 정책은 그룹 정책이나 로컬 보안 정책을 통해 로컬 컴퓨터에 구성할 수 있는 설정이며, 특정 액세스 유형에 대한 성공 및 실패 이벤트의 모음을 정의합니다. 다음은 지난 수년 간 Windows에 제공된 기본 감사 정책 범주입니다. Windows Server 2008에 새로 도입된 세부적 감사 정책에 대해서는 뒤에서 자세히 설명합니다.
  • 계정 로그온 이벤트 감사
  • 계정 관리 감사
  • 디렉터리 서비스 액세스 감사
  • 로그온 이벤트 감사
  • 개체 액세스 감사
  • 정책 변경 감사
  • 권한 사용 감사
  • 프로세스 추적 감사
  • 시스템 이벤트 감사
대부분의 IT 조직에서는 감사 정책 및 위와 같은 관련 범주를 정의해야 할 필요성에 대해 잘 이해하고 있습니다. 그러나 감사 정책은 솔루션의 한 부분일 뿐입니다. SACL 또한 전체적인 감사 계획을 구현하는 데 중요한 역할을 합니다. 특히 디렉터리 서비스 액세스 감사와 개체 액세스 감사 이 두 가지 감사 정책 범주는 전적으로 SACL에 의존하여 보안 이벤트 로그에 정보를 반환합니다. 그렇다면 SACL은 정확히 무엇일까요?
파일, 레지스트리, 디렉터리 서비스와 같은 각 개체에는 하나 이상의 ACE(액세스 제어 항목)가 포함된 ACL(액세스 제어 목록)이 있으며, 이 ACL은 DACL(임의 액세스 제어 목록)과 SACL이라는 두 가지 종류로 나뉩니다. 이 중에서 SACL은 보호된 개체에 대한 액세스 시도를 기록하는 설정을 정의합니다. SACL의 각 ACE는 지정된 트러스트를 받을 대상에 의한 액세스 시도 유형 중 보안 이벤트 로그에 기록되어야 할 유형을 지정합니다. ACE는 지정된 개체에 대해 성공 및/또는 실패 액세스 시도를 기록할지 여부를 정의합니다. 그림 2에서는 개체에 SACL을 사용하여 특정 액세스 유형에 대한 이벤트를 생성하는 방법을 보여 줍니다.
그림 2 개체에 SACL 사용
그림 2 개체에 SACL 사용
환경의 변경과 관련된 "올바른" 감사된 이벤트를 캡처하기 위해서는 구성이 필요하며 감사 정책과 SACL 간의 관계를 이해하는 것이 매우 중요한 이유는 바로 이 때문입니다. 앞에서 언급했듯이, 디렉터리 서비스 액세스 감사와 개체 액세스 감사 정책은 해당되는 특정 범주에 대해서만 보안 이벤트 로그에 감사 이벤트가 생성되도록 하지만 개체의 SACL에 감사 ACE가 구성된 경우에만 이벤트가 생성됩니다. 정책과 SACL이 적절히 구성되면 Windows LSA(로컬 보안 기관)에 의해 보안 이벤트가 생성되어 보안 이벤트 로그에 기록됩니다.
이벤트는 두 가지 고유 영역으로 구성됩니다. 하나는 정적이며 각 이벤트 ID에 대해 미리 정의된 머리글이고, 다른 하나는 동적이며 다양한 이벤트에 대해 서로 다른 정보를 포함하는 본문입니다. 그림 3에서는 샘플 Windows Server 2008 보안 이벤트의 두 요소를 보여 줍니다. 이와 같은 이벤트 구성 요소에 대한 이해는 감사 프로젝트의 분석 단계에서 중요하며 특히 ACS와 같은 도구에서의 정보 반환 방법을 이해하는 데 필요합니다.
그림 3 감사된 이벤트의 머리글 및 본문
그림 3 감사된 이벤트의 머리글 및 본문

Windows Eventing 6.0
지금까지 감사에 따르는 문제를 살펴보았으므로 이제 Windows Server 2008을 사용하여 조직에서 이러한 문제를 해결하는 방법에 대해 알아보겠습니다. Windows Server 2008은 보안 이벤트 관리와 관련된 환경을 대폭 개선한 새로운 Windows Eventing 6.0 이벤트 하위 시스템이 포함된 첫 번째 서버 릴리스입니다. 여기서는 Windows Server 2008에 대해 중점적으로 설명하지만 이러한 새로운 기능의 95%는 Windows Vista에도 포함되어 있습니다.
대부분의 사람들이 Windows Eventing 6.0에서 처음 주목하는 요소 중 하나가 바로 새로운 사용자 인터페이스입니다. 새로운 이벤트 뷰어 MMC(Microsoft Management Console) 스냅인은 알아보기 쉬운 개요 및 요약 페이지, 유연성이 뛰어난 사용자 지정 보기 및 대폭 개선된 설명 텍스트를 제공합니다. 이러한 인터페이스를 통해 이제 최종 사용자나 시스템 관리자는 이벤트 뷰어 자체에서 이벤트 정보를 찾고 중요한 이벤트 로그 옵션을 구성할 수 있습니다.
대개 이벤트 로그 내의 보안 데이터에 영향을 미치는 주요 문제는 데이터 보존이었습니다. 이전에는 이벤트 로그 하위 시스템 및 모든 로그가 확장성 한계라는 문제에 직면해 있었습니다. 이 한계가 초과되면 전체 하위 시스템의 이벤트 기록이 중지되었습니다. 그러나 Windows Eventing 6.0의 경우 이와 같은 문제가 발생하지 않으므로 이제 조직에서는 가용 디스크 공간의 문제만 해결하면 됩니다. 그러나 크기가 매우 큰 이벤트 로그의 경우 필터링을 통해 개별 이벤트 로그 항목을 분석해야 하고 이는 매우 번거로운 작업이 될 수 있으므로 로그를 관리 가능한 크기로 유지하려고 할 것입니다.
물론 이 경우에도 다수의 시스템에 대한 이벤트 로그 보관 계획을 마련하는 작업은 IT 관리자의 몫입니다. 로컬 서버 수준에서 이와 같은 업무를 지원하기 위해 Windows Eventing 6.0에는 "로그가 꽉 차면 로그 보관. 이벤트를 덮어쓰지 않음"이라는 옵션이 추가되었습니다. 이전 버전의 Windows에서는 AutoBackupLogFiles 레지스트리 값을 직접 수정하는 방법을 통해서만 이 옵션을 설정할 수 있었습니다. 이 옵션은 로그의 로컬 보관을 위한 메커니즘을 제공할 뿐이며 시간의 경과에 따른 파일 관리 솔루션을 제공하거나 여러 시스템에 걸쳐서 발생하는 집계 문제를 해결하지는 않습니다. Audit Collection Services는 이를 위한 완전한 솔루션을 제공합니다. 지금부터 ACS에 대해 간단히 살펴보겠습니다.
새로운 인터페이스는 시작에 불과합니다. Windows Eventing 6.0의 진정한 성능은 새로운 Windows 이벤트 로그 서비스와 기본 XML 기반 엔진에 있습니다. 바로 이 두 개의 구성 요소를 통해 개선된 확장성, 액세스 가능성 및 관리 옵션이 제공됩니다. 이제 유연성이 뛰어난 XML 형식으로 이벤트가 저장되므로 기본적으로 이벤트 정보를 활용하는 사용자 지정 솔루션을 만들 수 있습니다.
또한 Windows Eventing 6.0은 관리 작업을 특정 이벤트에 연결하는 기능을 제공합니다. Windows Eventing 6.0은 Windows 이벤트 수집기 서비스와 작업 스케줄러를 통합하여 작업 기반 이벤트를 제공함으로써 이와 같은 기능을 제공합니다. 이는 이전에는 시간을 기준으로 이벤트를 트리거하는 것으로만 제한되었던 작업 스케줄러를 위한 새로운 패러다임입니다. Windows Server 2008 이벤트 뷰어에서 모든 이벤트의 상황에 맞는 메뉴에서 사용할 수 있는 "이 이벤트에 작업 연결" 마법사는 특정 이벤트가 기록될 때마다 간편하게 프로그램을 시작하거나 전자 메일을 보내거나 메시지를 표시하는 방법을 제공합니다. 이 기능은 환경에서 발생하는 작업 중 보안 이벤트로 분류할 수 있는 특정 작업을 식별하려는 경우에 매우 유용합니다. 예를 들어 도메인 컨트롤러에 대한 "Schema Update Allowed" 레지스트리 키의 변경을 감사하는 경우, 이 레지스트리 키가 수정되면 특정 보안 관리자에게 해당 사실을 알리는 전자 메일을 보내는 작업을 만들 수 있습니다.
다수의 이벤트 항목을 수집하고 저장하는 이 새로운 기능 이외에도 이제 이벤트 로그에 기록되는 이벤트를 보다 정확하게 제어할 수 있게 되었습니다. 이는 GAP(세부적 감사 정책)라는 새로운 기능을 통해 수행할 수 있습니다. 이전 버전의 Windows에서는 아홉 개의 광범위한 감사 범주로 인해 너무 많은 이벤트가 생성되곤 했습니다. 이제 각각 관련된 이벤트 하위 집합을 나타내는 50개의 세분화된 하위 범주를 사용하여 이와 같은 상위 범주를 제어할 수 있습니다.
이러한 하위 범주를 통해 범주 수준 자체는 그대로 표시하면서 중요하지 않은 정보는 필터링을 통해 이벤트 로그에서 제외할 수 있습니다. 예를 들어 이전에는 레지스트리의 변경만 모니터링하고 파일 시스템은 모니터링하지 않으려는 특정 시스템이 있을 경우 개체 액세스 범주에 대해 성공 또는 실패를 보고하도록 하는 것 외에는 다른 방법이 없었습니다. 이제 GAP를 사용하여 필터링을 통해 파일 시스템, 인증 서비스, 파일 공유와 같은 하위 범주는 제외하고 레지스트리 하위 범주에 대해서만 이벤트를 보고할 수 있습니다. Windows Server 2008 시스템의 GAP 하위 범주를 보려면 상승된 명령 프롬프트에서 Auditpol 명령을 실행해야 합니다. 사용할 수 있는 GAP 하위 범주를 표시하려면 다음과 같이 입력합니다.
auditpol /list /subcategory:*
시스템에 구성되어 있는 GAP 하위 범주 목록을 보려면 다음과 같이 입력합니다.
auditpol /get /category:*
GAP는 표준 그룹 정책 사용자 인터페이스를 통해 구성할 수 없으며 auditpol.exe를 통해 관리해야 합니다. Windows Server 2008 및 Windows Vista 시스템용 그룹 정책을 통해 GAP 설정을 배포하는 방법에 대한 지침은 support.microsoft.com/kb/921469의 기술 자료 문서를 참조하십시오.
또한 Windows Server 2008에서는 보안 이벤트 로그의 특정 유형에 대한 이전 값 및 새 값을 모두 캡처할 수 있습니다. 이전 버전 Windows의 감사 하위 시스템에서는 변경된 Active Directory® 개체 특성의 이름이나 레지스트리 값만 기록하고 특성의 이전 값과 현재 값은 기록하지 않았습니다. 이 새로운 기능은 Active Directory 도메인 서비스, Active Directory Lightweight Directory Services 및 Windows 레지스트리에 적용됩니다. "레지스트리" 또는 "디렉터리 서비스 변경" 하위 범주에 대해 '감사 성공' 또는 '감사 실패'를 설정하고 관련된 SACL을 설정하면, 해당 개체에 대해 수행된 작업에 대한 자세한 이벤트가 이벤트 로그에 생성됩니다. 이 설정 작업은 다음 auditpol 명령을 사용하여 수행할 수 있습니다.
auditpol /set /subcategory:"Registry" /success:enable
auditpol /set /subcategory:"Directory Service
    Changes" /success:enable
레지스트리 변경은 그림 4와 같이 이벤트 ID 4657로 나타납니다.
그림 4 레지스트리 변경 전과 후
그림 4 레지스트리 변경 전과 후
이 기능은 특히 Active Directory 개체의 변경을 추적하려는 경우 유용합니다. 디렉터리 서비스 변경은 그림 5와 같이 이벤트 ID 5136 이벤트 쌍에서 나타납니다. 각 이벤트의 이벤트 본문에는 디렉터리 서비스 '개체', '특성' 및 '작업'이 있습니다. 기존 데이터가 있는 특성이 변경된 경우 '값이 삭제됨'과 '값이 추가됨'이라는 두 가지 작업을 볼 수 있습니다. 채워져 있지 않았던 특성의 경우 데이터가 특성에 기록될 때 '값이 추가됨' 작업만 볼 수 있습니다. 예를 들어 telephoneNumber와 같은 사용자 개체의 특성에 성공적인 수정 작업을 수행한 경우 Active Directory는 자세한 이벤트 로그 항목에 이 특성의 이전 값과 현재 값을 기록합니다.
그림 5 디렉터리 서비스 변경 이벤트 전과 후
그림 5 디렉터리 서비스 변경 이벤트 전과 후
새 개체가 만들어지면 개체가 만들어질 때 채워진 특성 값이 기록됩니다. 개체가 도메인 내에서 이동되면 이전 위치와 새 위치가 구별되는 이름 형식으로 기록됩니다. 이 "이전 값 및 새 값" 기능은 알맞은 감사 정책 설정을 구성하면 기본적으로 설정됩니다. 직원 ID 번호 변경과 같이 기밀을 유지해야 하는 특성이 있는 경우 간단한 스키마 수정을 통해 해당 특성을 제외할 수 있습니다. 그림 6과 같이 스키마에서 특성의 searchFlags 속성을 0x100(값 256 -NEVER_AUDIT_VALUE)으로 수정하면 이 특성이 변경되어도 디렉터리 서비스 변경 이벤트가 발생하지 않습니다.
그림 6 디렉터리 서비스 변경에서 특성 제외
그림 6 디렉터리 서비스 변경에서 특성 제외
마지막으로, Windows Eventing 6.0에는 이벤트 구독이라는 또 다른 주목할 만한 새로운 기능이 포함되어 있습니다. 앞에서 언급했듯이, 이벤트 로그에 액세스하고 검토하는 것은 시스템 관리자의 주요 작업입니다. 새로운 이벤트 구독 기능은 시스템 간에 이벤트를 직접 전달할 수 있는 방법을 제공합니다. 이벤트 구독은 이벤트를 수집하는 이벤트 수집기와 이벤트를 지정된 호스트로 전달하도록 구성된 이벤트 원본으로 이루어집니다. 이벤트를 사용하는 기능은 Windows Eventing 6.0의 새로운 기능인 Windows 이벤트 수집기 서비스에서 제공하고, 구독자 기능은 Windows 이벤트 로그 서비스에서 기본적으로 제공합니다. Windows Server 2008이나 Windows Vista 시스템과 같은 여러 이벤트 원본에서 이벤트를 수집하도록 수집기를 구성할 수 있습니다.
이벤트 원본에서 수집된 모든 데이터는 전달된 이벤트(ForwardedEvents.evtx)라는 별도의 이벤트 로그에 보관되고 수집기의 이벤트 로그 서비스를 통해 관리됩니다. 수집기와 원본의 두 끝점 모두에서 구성 작업이 필요합니다. 원본에서는 winrm quickconfig –q를 사용하고 수집기에서는 wecutil qc /q를 사용하여 구성 작업을 자동화할 수 있습니다. 이 이벤트 구독 기능은 엔터프라이즈용으로 설계된 것이 아니며 외부 데이터베이스에 이벤트를 전달하는 시스템을 대체하지 않는다는 점에 유념하십시오.
일례로 이 기능은 소규모 웹 팜에서 사용하기에 적합합니다. 웹 서버와 SQL 서버를 비롯하여 특정 웹 사이트와 연결된 몇 대의 시스템이 있다고 가정해 보십시오. 새로운 이벤트 구독 기능을 사용하면 이러한 시스템의 보안 이벤트 로그 정보를 단일 시스템에 통합할 수 있습니다. 대규모 환경에서는 대개 이보다 고급화된 이벤트 로그 통합 도구 집합이 필요합니다.

Audit Collection Services
Windows Server 2008의 모든 새로운 기능을 사용할 경우 보안 이벤트 로그 정보에 대한 장기적인 관리 및 보관을 위한 실질적인 솔루션은 중앙 집중화된 감사 정보 데이터베이스를 통해 확보할 수 있습니다. System Center Operations Manager 2007의 핵심 기능인 Audit Collection Services는 보안 이벤트 데이터의 전달, 수집, 저장 및 분석을 위한 메커니즘을 제공합니다. 보안 이벤트는 거의 실시간으로 수집되어 중앙 SQL 저장소에 저장됩니다. 또한 ACS는 감사 정보에 대해 최소 권한 액세스를 제공하는 방법을 제공하는데 이는 실제로 감사되는 시스템에 대해 어떠한 물리적 액세스도 필요하지 않기 때문입니다. 이제 ACS가 어떤 방식으로 작동하는지 살펴보겠습니다.
ACS에는 세 가지 주요 구성 요소가 있습니다. 하나는 Operations Manager 에이전트의 일부이며 이벤트 로그 데이터를 클라이언트에서 ACS 인프라로 전송하는 전달자입니다. 전달자는 데이터를 두 번째 구성 요소이자 서버 쪽 수신기인 수집기로 전송합니다. ACS 전달자는 TCP 포트 51909를 통해 연결하여 할당된 수집기와 안전한 방식으로 통신합니다. 이벤트 로그 데이터는 전송되기 전에 XML로 정규화됩니다. 즉, 불필요한 정보는 제거되고 이벤트 정보는 이벤트 머리글 및 본문 정보를 기준으로 매핑된 필드에 요약됩니다. 정보가 수집기에 도달하면 세 번째이자 마지막 구성 요소인 ACS 데이터베이스로 전송됩니다. 이 데이터베이스는 보안 이벤트 정보의 장기 저장을 위한 저장소가 됩니다. 한번 저장된 정보는 SQL 쿼리를 통해 직접 검색하거나 SQL Server® Reporting Services를 사용하여 HTML 보고서로 렌더링할 수 있습니다. ACS는 그림 7에 나오는 세 가지 기본 보기를 제공합니다.
Figure 7 ACS 보기 (Close Figure 7)

ACS 보기 이름 | 용도
AdtServer.dvHeader | 수집된 이벤트의 머리글 정보
AdtServer.dvAll | 수집된 이벤트의 머리글 및 모든 본문 정보
AdtServer.dvAll5 | 수집된 이벤트의 머리글 및 본문 정보의 처음 다섯 문자열
성능 측면에서 볼 때 단일 ACS 수집기는 초당 최대 100,000개의 이벤트를 처리할 수 있으며 연속적으로는 초당 최대 2,500개의 이벤트를 처리할 수 있습니다. 현재 계획상으로 단일 ACS 수집기는 기본 감사 정책 설정을 기준으로 최대 150개의 도메인 컨트롤러, 3000개의 구성원 서버 또는 20,000개의 워크스테이션을 지원할 수 있습니다. 테스트를 거친 한 실제 시나리오에서는 대략 150개의 도메인 컨트롤러를 지원할 경우 초당 140개의 이벤트 처리 성능과 시간당 평균 최대 500,000개의 이벤트 처리 성능을 보여 주었습니다. 불과 14일(ACS에 대한 기본 보존 설정값) 동안 150GB가 넘는 보안 이벤트 데이터가 SQL Server 데이터베이스에 저장되었습니다. 보다 적극적으로 감사 정책 및 관련 SACL 구성을 사용한다면 시간당이든 하루당이든 분명히 전반적으로 더 많은 데이터가 생성될 것입니다.
여기서 핵심은 이렇게 많은 양의 데이터가 생성된다면 일반적인 대규모 엔터프라이즈 환경에서 사람의 힘으로 모든 이벤트를 검토하는 것은 불가능하다는 점입니다. 역으로 말하자면 조직에서는 여기에 명시된 수치를 두려워해서는 안됩니다. 환경에서 발생하고 있는 변경을 이해하려면 대량의 데이터를 분석하는 수고를 들여야 합니다.
바로 여기에서 ACS의 가치가 빛을 발합니다. SQL Server Reporting Services와 ACS를 사용하면 일반적으로 보안 이벤트 로그에 묻혀 알아볼 수 없는 문제를 응용 프로그램 이벤트 로그의 색으로 구분된 이벤트와 같이 쉽게 식별할 수 있도록 바꿀 수 있습니다. ACS에는 기본 보고서 집합이 포함되어 있으며 이를 사용자 고유 환경의 필요에 맞게 간단히 확장할 수 있습니다.
다음 시나리오를 예로 들어 보겠습니다. 환경에 있는 외부 트러스트의 민감도 문제로 인해 우리 팀은 관리자로부터 Active Directory 트러스트 만들기에 대한 과정을 자세히 보여 주는 보고서 개발을 요청 받았습니다. 몇 가지 조사를 실시한 결과, 트러스트가 만들어질 때 Active Directory의 특정 도메인 이름 지정 컨텍스트 내에서 cn=System 컨테이너에 trustedDomain 개체가 만들어진다는 사실을 알게 되었습니다. 이에 따라 이 컨테이너의 SACL을 편집하여 모든 트러스트된 도메인 개체가 성공적으로 생성되는지 여부를 감사하도록 하였고, 그 이후부터는 이러한 유형의 개체가 만들어질 때마다 보안 이벤트를 캡처할 수 있게 되었습니다. 이로 인해 트러스트 만들기가 수행된 DC의 보안 이벤트 로그에 566개의 이벤트가 기록되었습니다. 그런 다음 ACS에서 이 정보를 검색하기 위해 간단한 SQL 쿼리를 작성했습니다.
select * from AdtServer.dvAll
where EventID = '566' and
String05 like '%trustedDomain%'
order by CreationTime desc
이 정보를 보고서로 만들려면 보고서 개발 기능을 제공하는 SQL Server 2005 Reporting Services가 포함된 Visual Studio® 2005 버전을 사용하십시오. 마법사를 완료하면 그림 8에 나오는 것과 유사한 보고서가 만들어집니다. 또한 보안 이벤트 로그에 나타낼 수 있는 환경의 모든 변경 사항도 이와 유사한 모양의 보고서로 요약할 수 있습니다.
그림 8 샘플 ACS 보고서
그림 8 샘플 ACS 보고서

감사 계획 개발
지금까지 감사에 따르는 문제와 감사의 법적, 기술적 측면을 살펴보았습니다. 그렇다면 IT 관리자는 조직의 "감사 계획"을 개발하기 위해 어떤 식으로 접근해야 할까요? 대부분의 작업과 마찬가지로 포괄적인 감사 정책의 개발은 여러 단계로 이루어진 프로세스입니다. 첫 번째 단계에서는 감사할 대상을 결정해야 합니다. 여기에는 환경을 분석하고 감사를 생성할 이벤트 및 변경의 유형을 결정하는 작업이 포함됩니다. 여기에는 계정 잠금, 중요한 그룹 변경, 트러스트 만들기와 같은 간단한 항목 또는 환경에 존재하는 응용 프로그램 내의 구성 요소 수정과 같은 복잡한 변경이 포함될 수 있습니다. 여기서 핵심은 감사 계획의 "감사 대상"을 결정하는 데 반드시 관리자가 참여해야 한다는 것입니다. 이 과정은 서류로 기록해야 하고, 중대한 사건이 일어난 후뿐만 아니라 정기적으로 반복해야 합니다.
두 번째 단계에는 특정 변경과 관련하여 보안 이벤트 형태로 반환될 감사 정보의 양이 얼마나 되는지 식별하는 작업이 포함됩니다. 감사 정보는 암호화되어 쉽게 해독할 수 없습니다. 따라서 보안 이벤트가 실제로 의미하는 바를 이해할 수 있도록 감사를 실행하기 전에 보안 이벤트와 다양한 작업 간에 상관 관계를 설정해야 합니다. 즉, 사건이 일어나기 전에 이벤트와 작업 간의 관계를 파악해야 합니다.
세 번째 단계는 실제로 감사 정책과 SACL을 구현하는 것입니다. 앞에서 설명했듯이 디렉터리, 파일 시스템 및 레지스트리의 변경을 완전하게 파악하려면 이들 영역에 대해 감사 정책 설정(보안 이벤트 생성을 위해)과 SACL(관련된 작업에 대한 감사 추적 생성을 위해)을 정의해야 합니다.
이 모든 단계를 마치면 네 번째이자 마지막 단계인 수집, 트리거 및 분석을 수행합니다. 조직의 규모와 요구 사항에 따라 이들 작업은 Windows Server 2008의 기본 기능을 사용하여 처리하거나 System Center Operations Manager의 Audit Collection Services 기능과 같은 고급 솔루션을 통해 처리할 수 있습니다. 대부분의 조직의 경우 SACL을 정의하지 않고 감사 정책만 설정하는 실수를 흔히 하게 됩니다. 마지막 단계는 조직 내의 이해 관계자와 데이터를 공유하고 보고하기 위한 기술 솔루션을 구현하는 작업과 관련이 있습니다. 앞에서도 언급했듯이 대부분의 조직에는 보안을 담당하는 부서가 있으므로 기존의 조직 요소를 중심으로 감사 계획을 수립해야 해당 계획이 효과적으로 실현될 수 있습니다. 마지막 단계에서의 핵심 작업은 환경의 변경을 숙지하고 있어야 하는 모든 관련자에게 유의적인 방법으로 정보를 수집하고 제공하는 것입니다.
단순히 포괄적인 감사 계획을 떠나서라도 대부분의 IT 조직은 하나의 중대한 이벤트입니다. 이전 플랫폼에 비해 Windows Server 2008은 보안 이벤트 데이터의 수집 및 분석을 위한 향상된 메커니즘을 제공합니다. ACS와 같은 고급 수집 및 보고 기술은 분산되어 있는 많은 양의 이벤트로 인해 모호해진 문제를 명확하게 드러냄으로써 변경을 즉시 파악할 수 있도록 합니다.
대부분의 IT 문제와 마찬가지로 프로세스가 가장 문제가 됩니다. IT 관리자가 기대하는 바를 얻으려면 언제나 추가적인 구성 및 분석 작업이 필요합니다. 따라서 환경의 요구 사항을 심층적으로 이해하고 Windows 플랫폼의 기능을 사용하면 이러한 문제를 사전에 해결할 수 있습니다. 이것으로 설명을 마치겠습니다.

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


 From the Editor: Windows Server 2008 일견
From the Editor
Windows Server 2008 일견

시시각각 수많은 제품들이 출시되고 있습니다. 수백 개, 아니 웹을 고려하면 수천 개에 이르는 제품의 포트폴리오를 보고 있노라면 제품 출시가 너무 흔해서 별것 아닌 것처럼 보이기도 합니다. 그러나 이번에는 다릅니다.
2월 중에 있을 Microsoft의 Windows Server 2008 출시를 앞두고 우리는 모두 들떠 있습니다. 이번 릴리스가 출시되기까지 공백이 너무 길었다는 사실은 반론의 여지가 없지만 아마 기다린 보람이 있을 겁니다. 괄목할 만하게 향상된 다양한 주요 기능, 그리고 수많은 새로운 기능은 실로 놀랍습니다. 그 중 IIS 7.0이나 네트워크 액세스 보호에 대해서는 할 이야기가 많고, 이번 달 매거진에서도 다루고 있습니다. 또한 서버 관리자, 새로운 배포 기술 또는 새로운 호환성 기능도 빼놓을 수 없습니다. 물론 이 모든 내용을 기사로 다루고 있습니다. 이러다가는 끝도 없을 것 같군요. 하지만 그 중에서도 이 새 릴리스와 관련하여 필자를 가장 놀라게 한 것은 Windows Server의 관리 효율성이 비약적으로 개선되었다는 점입니다.
우리는 IT 전문가의 작업에 어떻게 하면 조금이라도 더 도움이 될까 생각하는 데 많은 시간을 할애하고 있습니다. 때문에 IT 전문가가 보다 효과적으로 작업을 수행하는 데 중점을 둔 제품이 출시된 것은 여간 기쁜 일이 아닙니다. 일례로, Windows Server 2008에 새로 추가된 Eventing 인프라를 들 수 있습니다. Eventing 인프라에 대해서는 Rob Campbell과 Joel Yoker가 이번 호에서 다루었습니다. Eventing에 대해서는 우리 중에 가장 괴짜로 통하는 사람조차 별다른 관심을 갖지 않는데, 이번 릴리스에서 달라진 것을 보고 충격을 받았습니다. XML 데이터, 사용자 지정 보기, 더 자세한 설명, 손쉬운 보고 등, 새로운 기능을 일일이 나열하기도 힘드니까요.
다른 건 차치하고, 이번 릴리스로 우리 직원들이 얻을 경제적인 보상만으로도 충분히 열광할 만하죠. Active Directory, IIS, 네트워킹, 보안, 가상화 등의 향상된 기능은 Windows Server 2008 출시를 Microsoft 역사상 가장 중대한 제품 출시 사건으로 만들었습니다. 그래서 이번 호에서는 Windows Server 2008에 대해 자세히 다루기로 결정했습니다.
그리고 특별히, 플랫폼 및 서비스 부서의 기술 연구원이자 언제나 인기를 끌고 있는 Sysinternals 도구의 제작자인 Mark Russinovich가 다시 기사를 쓰게 되었습니다. Mark는 TechNet Magazine 역사상 가장 수요가 많았던 몇 가지 내용에 대해 기사를 썼습니다. 그 중 대표적인 기사로 "Windows Vista 커널 변경 사항"(2007년 2월, 3월, 4월호)이 있습니다. 그리고 이번 호에서 다시 Windows Server 2008 커널의 변경 사항에 대해 기술적으로 심도 있게 다루었습니다. 자, 그러면 흥미롭게 읽으시기 바랍니다.
—Joshua Hoffman

도움을 주신 Brandon Baker, Mai-lan Tomsen Bukovec, Bryce Cogswell, Nils Dussart, Gregoire Guetat, Brett Hill, Gaby Kaplan, Jason Leznek, Paul Mayfield, Nathan Muggli, Meg Muran, Michael Murgolo, Michael Niehaus, Raja Perumal, David Solomon, Eric Traut, Jim Truher, Landy Wang을 비롯한 Microsoft 기술 전문가들에게 감사를 전합니다.


 Letters: 독자의 목소리
Letters
독자의 목소리

Windows Vista Complete PC 백업
2007년 9월호에서 Windows Vista® Complete PC 백업에 대한 좋은 글("Windows Vista 백업 기술", technetmagazine.com/issues/2007/09/Backup)을 올려 주셔서 감사합니다. 그런데 저는 이 백업 기술을 직접 시도하지 못했습니다. 백업 이미지를 저장할 위치를 물을 때 제 외장 하드 드라이브(제가 원하는 위치)에 이미지를 저장하겠다고 하더군요. 그러나 이 외장 하드 드라이브의 특정 폴더에 파일을 저장할 수 있는 옵션이 없어서 이미 이 드라이브에 있는 다른 모든 파일이 없어질까봐 실행하지 못했습니다. 제가 괜한 걱정을 하는 건가요?
—Ben B.

독자님의 질문을 저자인 Christine Fok 씨에게 전달하자, Complete PC 백업의 경우 대상에 이미지를 저장할 별도의 폴더를 만들기 때문에 걱정하지 않으셔도 된다고 합니다. 데이터를 덮어쓰지 않는답니다.

잘못된 레지스트리 키 참조
2007년 12월호에 실린 "원인을 파악하기 힘든 네트워크 문제 추적"(technetmagazine.com/issues/2007/12/Network) 기사에는 Windows®에서 TCP/IP 스택을 조정하는 데 사용하는 레지스트리 키를 언급하는 부분에서 약간의 잘못된 내용이 있었습니다. 70페이지에서 저자인 Christopher Stoneff 씨는 HKLM\System\CurrentControlSet\Services\TCPIP 키를 통해 값을 조정할 수 있다고 했지만 사실상 정확한 키는 HKLM\System\CurrentControlSet\Services\TCPIP\Parameters입니다. 아마 "Parameters"를 깜빡하고 넣지 않으신 것 같습니다.
—Ingmar K.

Christopher Stoneff 씨가 독자님의 지적이 정확하다고 확인해 주었습니다. 이 키의 끝에는 \Parameters가 포함됩니다. 레지스트리 경로에서 이 부분을 누락하여 정말 죄송합니다. 이 기사의 온라인 버전에서는 해당 부분을 수정했습니다.

파일 암호화
저는 EFS(파일 시스템 암호화)에 관심이 많아 2007년 3월호 Security Watch에 실린 "EFS 배포: 2부"(technetmagazine.com/issues/2007/03/SecurityWatch) 칼럼을 읽었습니다. 저는 도메인 환경을 보유하고 있으며 일부 사용자는 이미 몇몇 파일을 암호화하고 있습니다. 그래서 저는 CA(인증 기관)와 EFS 템플릿을 도입했습니다. 제 질문은, 이미 자신의 자체 서명된 인증서로 파일을 암호화한 사용자들이 새 파일을 암호화하려면 기존의 자체 서명된 인증서로 암호화해야 하는지, 아니면 제 CA에서 새 인증서에 등록해야 하는지를 알고 싶습니다. 그리고 모든 사용자가 로밍 프로필을 가지고 있다면 사용자의 개인 키는 어디에 저장되나요?
—Ammar H.

EFS 배포에 대한 칼럼의 저자 John Morello 씨는 다음과 같은 답변을 보내 주었습니다.
사용자가 새 EFS 인증서에 등록하고 나면 새 작업부터 이 인증서가 사용됩니다. 그러나 기존에 암호화된 파일도 업데이트될 때까지 기존의 키 쌍으로 계속 암호화된 상태를 유지합니다. 따라서 사용자들이 등록하고 나면 cipher /u를 실행하여 이러한 모든 파일을 새 키 쌍으로 업데이트하면 됩니다.
로밍 프로필을 사용하는 경우 키 쌍은 프로필 내에서 로밍됩니다. 이것보다는 로밍 프로필보다 용량이 훨씩 적은 자격 증명 로밍을 추천하고 싶습니다. 자세한 내용은 go.microsoft.com/fwlink/?LinkId=107469를 참조하시기 바랍니다.

잘못된 정규식
2008년 1월호에 실린 "Hey, Scripting Guy!: 정규식 유효성 검사" 칼럼(technetmagazine.com/issues/2008/01/HeyScriptingGuy)에서
objRegEx.Pattern = "[^A-Z][^a-z]"
를 사용한 예가 의도하신 바와 다른 것 같습니다. 이 예제의 목적은 소문자나 대문자가 아닌 모든 문자를 찾기 위한 것이었습니다. 그러나 이 패턴은 뒤에 소문자로 이어진 대문자를 찾기 위한 것입니다. 따라서 "aBcde"와 같은 문자열은 제대로 찾아내지 못하지요. 아마도 다음과 같이 되었어야 하지 않나 생각합니다.
objRegEx.Pattern = "[^A-Z^a-z]"
—Roger R.

독자님의 질문을 The Scripting Guys에 보낸 결과 다음과 같은 답변이 왔습니다.
안녕하세요, 정확히 지적해 주셔서 감사합니다. 저희가 중간에 칼럼을 수정하면서 이 부분을 놓친 것 같네요. 원본 초안(아직도 제 컴퓨터 어딘가에 굴러다니는)에서는 뒤에 소문자로 이어진 대문자를 찾기 위한 것으로 작성했었습니다. 그런데 이후에 이보다는 문자가 아닌 것을 찾는 것이 더 유용할 것이라 결정한 것 같습니다. 그리고 텍스트를 바꾸면서 예제 코드도 같이 변경하는 것을 깜빡한 것이죠. 온라인 버전에서는 이를 정확히 수정해 놓겠습니다. 다시 한번 죄송하다는 말씀 드립니다.


 Toolbox: IT 전문가를 위한 새로운 제품
Toolbox
IT 전문가를 위한 새로운 제품
Greg Steen

SQL 데이터베이스 관리
SQL Sentry Event Manager
sqlsentry.net/event-manager/standard-sql-server.asp
인프라가 크고 복잡할수록 유지 관리 작업과 운영 작업의 상호 간섭을 걱정해야 할 경우가 많아집니다. 이는 곧 최종 사용자의 프로세스 흐름에 문제를 일으킬 수 있습니다. 다행히 데이터베이스 및 시스템 관리자는 복잡한 환경의 일정을 조정하는 데 유용한 몇 가지 도구를 사용할 수 있습니다.
다중 데이터베이스 서버 환경에 고려할 만한 이러한 도구 중 하나로 SQL Sentry Event Manager가 있습니다. 이 도구는 백 엔드에서 SQL Server® 2000 또는 SQL Server 2005 인스턴스를 사용하는 Microsoft® .NET Framework 서버 응용 프로그램입니다. SQL Sentry Console UI를 통해 서버 응용 프로그램에 연결하면 사용자 환경에서 관리되는 서버에 대한 통일된 보기를 사용할 수 있습니다. 이 서버 응용 프로그램에는 에이전트가 없습니다. 즉, 관리하려고 하는 시스템과 서비스에 연결할 권한을 갖고 있는 사용자의 사용자 컨텍스트에서 이 서버 응용 프로그램을 실행해야 합니다.
가장 호평받은 응용 프로그램 기능 중 하나는, 콘솔 UI를 통해 서버 작업에 대한 끌어서 놓기 다시 예약 기능을 사용할 수 있으므로 유지 관리 작업과 운영 작업을 조정하여 충돌과 작동 중단을 피할 수 있다는 점입니다. UI가 처음에는 복잡해 보일 수 있지만 이를 통해 잠재적 문제를 빠르게 찾아내고 충돌하는 작업을 이동할 시간대를 찾을 수 있습니다. 또한 모니터링할 서버에 대한 Windows® 예약 작업과 SQL 에이전트 작업의 Microsoft Outlook® 형식 보기를 제공합니다. 또한 일정 보기에서는 장시간 실행 중인 작업과 실패한 작업이 강조 표시되므로 문제를 추적하고 해결하는 데 도움이 됩니다.
SQL Sentry에는 예약 기능 외에도 SQL 메일, MAPI, xp_sendmail 또는 sp_send_dbmail 대신 사용 가능한 강력한 알림 시스템도 제공합니다. 또한 관리되는 서버의 모든 이벤트 알림을 하위 시스템을 통해 라우팅하기 때문에 해당 알림의 형식, 빈도 및 배포를 중앙에서 관리할 수 있습니다.
알림은 전역, 서버, 작업 수준에서 구성할 수 있으므로 해당 형식의 이벤트에 대해 대부분의 관리자가 요구하는 세분성이 제공됩니다. 작업이 너무 오래 실행되거나 너무 짧게 실행될 때, CPU 사용률과 같은 성능 표시가 특정 임계값에 도달할 때, SQL 에이전트 작업이 어떤 이유로 차단될 때와 같은 다양한 유형의 이벤트 조건이 발생할 때 알림이 시작되도록 설정할 수 있습니다. 구성이 변경되었을 경우 이를 알리도록 SQL Sentry를 구성할 수도 있으므로 다른 사용자가 일정을 조정하거나 모니터링을 일시 중지하는 등의 상황이 발생할 때 이를 파악할 수 있습니다.
하지만 SQL Sentry를 사용하면 SQL 에이전트 작업 및 Windows 작업 스케줄러 이벤트보다 많은 것을 처리할 수 있습니다. 이 응용 프로그램은 유지 관리 계획, DTS 패키지, SSIS 작업 및 SQL 에이전트 로그의 이벤트도 지원합니다.
시스템 성능 수준 또는 작동 시간 수준과 같은 정보가 필요한 경우가 있습니다. SQL Sentry는 이러한 작업에 대한 다양한 보고 옵션을 기본으로 제공하므로 런타임 및 성능 통계 그래프를 만들어 인쇄할 수 있습니다. 또한 보고서 데이터를 XML, CSV 또는 HTML로 내보내서 자체 보고 문서 및 도구에 포함할 수도 있습니다.
Professional Edition에는 보고 서비스 모니터링, SQL 에이전트 작업 큐, 비SQL 서버 이벤트의 체인, 공유 리소스 일정 조정 등의 기능과 Oracle 서버 관리 기능이 추가됩니다.

가격: Standard Edition(395달러)
SQL Sentry로 유지 관리 예약
SQL Sentry로 유지 관리 예약

시스템 원격 관리
Mobile Admin
rovemobile.com/products/ma/features
동시에 두 곳 이상의 장소에서 작업할 수는 없기 때문에 모바일 원격 서버 관리 도구는 작업량이 많은 IT 전문가에게 알맞은 제품입니다. 또한 Rove Mobile(이전의 Idokorro Mobile)의 Mobile Admin도 고려할만 합니다.
Mobile Admin은 관리할 서버에 대한 액세스 권한이 있는 하나의 통신 서버가 일련의 무선 핸드헬드 장치와 상호 작용하는 클라이언트/서버 설정입니다. 이 응용 프로그램의 서버 부분은 에이전트 없이 작동합니다. 즉, 관리할 서버에 아무것도 설치하지 않아도 됩니다. 하지만 해당 시스템과 응용 프로그램 컨텍스트에 인프라의 시스템을 관리할 수 있는 적절한 원격 관리 권한을 부여해야 합니다.
Windows Mobile® Pocket PC 및 Smartphone과 BlackBerry 스마트폰을 포함한 대부분의 주요 모바일 플랫폼을 통해 서버에 액세스할 수 있습니다. 또한 호환 브라우저가 있는 모든 인터넷 연결 컴퓨터를 통해 Mobile Admin에 연결할 수 있습니다(보안 정책에서 허용되는 경우).
모바일 관리 권한이 있는 모든 시스템 또는 네트워크 전문가의 가장 큰 관심사 중 하나는 보안입니다. BlackBerry Enterprise Server를 배포한 사용자의 경우 모든 통신을 3DES(Triple Data Encryption Standard) 또는 AES(Advanced Encryption Standard)로 암호화하도록 선택할 수 있습니다. 이 두 표준 모두 FIPS(Federal Information Processing Standard)를 준수합니다.
또한 Mobile Admin은 분실된 BlackBerry에 대한 "kill(제거)" 기능을 확장하여 전화기에서 소프트웨어와 데이터를 원격으로 제거할 수 있습니다. 다른 핸드헬드의 경우 VPN을 구현하여 통신을 암호화하고, Mobile Admin에서 Windows 로그인, LDAP, RSA SecurID, RADIUS 인증 또는 Mobile Admin 관련 로그인을 사용하도록 구성할 수 있습니다.
연결된 경우 이벤트 로그 보기 및 삭제, 시스템 다시 부팅, 파일 및 디렉터리 관리, 예약된 작업 보기 및 편집과 같은 Windows 관리 작업을 수행할 수 있습니다.
Active Directory® 통합의 관점에서 볼 때 사용자, 그룹 및 컴퓨터를 확인하거나 만들거나 편집하거나 사용하지 않도록 설정하거나 삭제할 수 있습니다. 또한 Exchange 관리의 경우 사서함 설정을 변경하고 메시지 큐를 고정하거나 고정 취소하는 등의 작업을 수행할 수 있습니다.
IIS를 사용하는 경우에는 응용 프로그램 풀 또는 웹 사이트를 다시 시작하고 가상 디렉터리 설정을 변경할 수 있습니다. SQL 서버의 경우 T-SQL 쿼리 실행, 로그인 수정 및 SQL 에이전트 작업 시작/중지와 같은 작업을 수행할 수 있습니다. 클러스터 서비스를 실행하고 있는 경우에는 그룹을 이동하고 리소스를 오프라인으로 전환하고 다른 공통적인 관리 작업 중에서 장애 조치(failover)를 수행할 수 있습니다.
마지막으로, Mobile Admin은 Oracle, Novell LDAP, Lotus Domino, Citrix, HP iLO, Backup Exec 등의 관리 작업도 지원합니다.

가격: 서버당 최소 245달러

서평
Mastering Windows Network Forensics and Investigation
sybex.com
대부분의 관리자들이 네트워크에 대한 위협을 검색하고 이를 완화하기 위한 하드웨어 및 절차를 마련해두었을 것입니다. 하지만 보안 관련 이벤트가 발생한 경우 범인을 조사하고 기소하는 데 필요한 절차를 마련해 두었거나 이러한 절차를 알고 있습니까?
Mastering Windows Network Forensics and Investigation(Sybex, 2007)에서는 이러한 정보를 볼 수 있습니다. 이 책에서는 회사 서비스의 부적절한 이용과 같은 소규모의 단일 시스템 침입부터 중요한 시스템에 대한 보다 광범위한 대규모 공격에 이르는 다양한 Windows 네트워크 침입에 대해 완벽하게 조사하는 방법을 익힐 수 있습니다.
이 책에서는 면담 수행부터 감사된 이벤트 및 로그 추적에 이르는 모든 과정을 비롯하여 증거를 수집하는 절차를 안내합니다. WireShark, LogParser, EnCase 및 SysInternals 도구 집합 등의 도구를 사용하여 Windows 시스템 및 네트워크에서 증거를 수집하는 방법과 위치를 설명합니다.
또한 이 책에서는 해당 시스템의 레지스트리, 파일 시스템 구조 및 컨텍스트, 텍스트 기반 로그, 이벤트 로그 및 문제가 발생한 시스템의 프로세스에서 얻을 수 있는 정보도 소개합니다. 그 밖에도 원하는 증거를 추적하는 데 필요한 도구가 포함된 Live-Analysis CD를 만드는 방법을 안내합니다. 마지막으로 이 책에서는 조사 결과를 보고하는 방법을 설명하고, 법정에서 이를 입증하기 위한 절차와 세부 지침도 제공합니다.

가격: 59.99달러

시스템 데이터 수집
MetaLAN
hammer-software.com/metalan.shtml
중앙 집중식 관리는 성공적인 시스템 관리를 위한 핵심 구성 요소 중 하나입니다. 중앙 집중식으로 관리하면 불필요한 주변 항목을 제거하고 소중한 시간을 절약할 수 있으므로 작업에 따른 스트레스를 낮출 수 있습니다.
Hammer Software의 MetaLAN은 Windows 네트워크에서 사용자와 서버를 관리 및 지원하는 데 유용한 도구입니다. 에이전트가 없는 이 응용 프로그램을 사용하면 정보를 빠르게 수집하고 구성을 변경하고 Windows 시스템을 전체적으로 관리할 수 있습니다. 물론 이러한 작업을 수행하려면 적절한 사용자 컨텍스트와 권한을 갖고 있어야 합니다.
MetaLAN에는 두 가지 작동 모드가 있습니다. 관리자 모드(정보를 수집하거나 속성을 변경하려는 시스템에 연결)에서 직접 실행하거나, 서버 모드에서 실행 중인 MetaLAN과 함께 원격 시스템에서 ProbeServer라고 하는 무료 추가 에이전트/서비스를 사용하여 워크스테이션을 지속적으로 모니터링할 수 있습니다.
응용 프로그램을 시작하면 MetaLAN Control Panel(제어판) UI가 나타나고, 관리할 도메인의 현재 네트워크를 조사하는 데 사용할 수 있는 옵션이 표시됩니다. 여기에서 Help Desk Tool, Report Tool, Software Tool 및 RegCast Tool과 같은 다양한 도구 구성 요소를 시작할 수도 있습니다.
Help Desk Tool은 관리 중인 도메인의 시스템에 대한 검색 및 탐색 보기를 제공합니다. 컴퓨터를 선택하면 제조업체, IP 주소, 프로세서, 드라이브, MAC 주소 및 서버 역할을 포함하여 시스템에 대한 다양하고 유용한 정보가 나타납니다. 여기에서는 WMI(Windows Management Instrumentation) 쿼리를 실행하고, 실시간 성능 모니터에 연결하고, 설치된 소프트웨어를 보고, 다른 유용한 관리 작업을 수행할 수 있습니다.
Report Tool은 관리 노드에 대해 내보내기 가능한 빠른 그래픽 보기를 제공합니다. 예를 들어 네트워크에 있는 모든 시스템의 CPU 속도에 대한 원형 차트를 만들거나 Windows XP 서비스 팩 2가 설치된 시스템을 확인할 수 있습니다.
Software Tool을 사용하면 네트워크에서 한 개 또는 N개의 시스템 그룹에 설치된 소프트웨어의 목록을 빠르게 확인하고 내보낼 수 있습니다. 이 도구는 감사에 매우 유용합니다.
RegCast Tool을 사용하면 선택한 시스템 그룹의 원격 시스템에 대한 레지스트리 정보를 볼 수 있습니다. 도메인 또는 엔터프라이즈 관리자인 경우에는 수정도 가능합니다.
MetaLAN에는 Microsoft Installer(MSI) 패키지를 원격으로 배포하고 설치하기 위한 도구도 포함되어 있습니다(자동 설치를 지원하는 경우). Storage Overview는 시스템의 모든 드라이브를 표시하고 사용 가능한 여유 공간 크기를 알려 줍니다. Service Admin 도구를 사용하면 서비스를 시작, 중지 및 제거할 수 있습니다. 또한 실행 시 원격 지원처럼 시스템을 원격으로 제어할 수 있는 작은 VNC 실행 파일을 제공하는 VNC(Virtual Network Computing) 원격 제어 도구도 있습니다.

가격: 20개 노드 라이선스 팩(최소 75달러)
검색 및 탐색 보기를 제공하는 Help Desk Tool
검색 및 탐색 보기를 제공하는 Help Desk Tool

작업 자동화
AutoHotkey
autohotkey.com
자동화는 IT 전문가가 시간이 많이 걸리는 반복적인 작업을 피하는 데 활용할 수 있는 최고의 수단일 것입니다. 이러한 목적으로 활용되는 수많은 도구 중 하나가 AutoHotkey 유틸리티입니다. 무료로 제공되는 이 공개 소스 도구는 키보드, 마우스 또는 조이스틱 입력이 필요한 거의 대부분의 작업을 자동화하여 일반적인 데스크톱 작업을 간소화하는 데 도움을 줍니다. 이 도구는 스크립트 기반의 바로 가기 키 및 강력한 매크로 도구입니다.
AutoHotkey는 시스템 트레이에서 실행되며 컴퓨터가 시작되면 사용자가 작성한 스크립트 정의를 실행합니다. 이 프로그램은 스크립트 파일에 있는 개별 스크립트 명령을 실행합니다. 예를 들어 사용자가 컴퓨터를 시작한 후 자주 사용하는 응용 프로그램을 실행할 때 매우 유용합니다. 이외에도 다양한 바로 가기 키와 바로 가기 문자열(hotstring)도 정의할 수 있습니다.
바로 가기 키는 응용 프로그램 시작, 창을 포그라운드로 가져오기, 마우스 휠 스크롤 작업 시뮬레이션과 같은 작업을 실행하도록 정의하는 키 조합입니다.
반면 바로 가기 문자열(hotsting)은 자주 입력하는 명령이나 구에 대한 텍스트 약어입니다. 이러한 바로 가기 문자열을 사용하여 바로 가기 키와 비슷한 스크립트 작업을 시작할 수 있습니다. 예를 들어 Microsoft Word를 시작하고 원하는 형식으로 오늘 날짜를 입력하는 "td"라는 간단한 키 시퀀스의 바로 가기 문자열을 만들 수 있습니다. 또는 특정한 단락으로 된 응답을 사용자에게 자주 보내는 경우에는 이 단락을 새 Outlook 메시지로 자동 덤프하는 간단한 바로 가기 문자열을 만들 수 있습니다.
스크립트 언어는 자체적으로 변수, 산술 및 문자열 연산을 위한 식, 기본 제공 전역 변수, 함수, 루프 및 조건문을 지원하기 때문에 시스템 관리 요구 사항에 맞는 스크립트를 작성할 수 있어야 합니다. 전체적으로 100개가 넘는 명령과 언어 구문을 이용할 수 있습니다. 예를 들어 마우스 끌기를 시뮬레이션하고, 메시지 상자를 표시하고, 비동기 작업을 실행하고, 전자 메일 메시지를 보내고, 레지스트리를 수정하고, 반복 검사를 위해 루프 안에 타이머를 설정하고, 응용 프로그램을 열고, 창을 닫고, 프로세스를 중지하는 등의 작업을 할 수 있습니다.
AutoHotkey의 또 다른 유용한 기능은 요구 사항에 맞게 스크립트를 작성한 후 이를 컴파일하여 다시 사용하고 배포할 수 있다는 점입니다. 이렇게 하면 AutoHotkey를 설치하지 않은 사용자도 이 바로 가기 및 스크립트를 이용할 수 있습니다. 또한 공개 소스 프로젝트라는 라이선스 덕분에 제한 없이 배포하거나 판매할 수 있습니다.
내부 조직에서는 데스크톱에서 직접 수동으로 수행해야 하는 일련의 사용자 지정 작업을 자동으로 수행하는 실행 가능 스크립트를 최종 사용자에게 손쉽게 배포할 수 있습니다. 또한 이러한 스크립트를 각 사용자에 맞게 사용자 지정해야 하는 경우, AutoHotkey에서는 명령줄 스위치와 매개 변수를 사용할 수도 있으므로 도메인 전체에서 매우 유용하며 다시 사용 가능한 스크립트를 만들 수 있습니다.
자세한 설명서가 부족한 다른 여러 공개 소스 프로젝트와는 달리 AutoHotkey 설명서는 충실하고 올바르게 구성되어 있으며 자동화 작업을 스크립팅하기 위해 알아야 하는 내용을 다양하고 유용한 예제를 통해 제공합니다. 또한 이 프로젝트의 웹 사이트에는 어떠한 질문에 대해서도 도움을 얻을 수 있는 적극적인 사용자 포럼이 있으며 스크립트, 자습서 및 명령 참조가 들어 있는 Wiki도 있습니다. 또한 여러 사용자가 작성한 유용한 예제를 제공하는 스크립트 소개 페이지도 있습니다.

가격: 무료
재사용 및 배포를 위해 스크립트를 컴파일할 수 있는 AutoHotKey
재사용 및 배포를 위해 스크립트를 컴파일할 수 있는 AutoHotKey

Greg Steen은 사업가이자 열성적인 기술 전문가로, IT 전문가의 운영, QA 및 개발 작업에 도움을 줄 수 있는 새로운 도구를 끊임없이 연구하고 있습니다.


 Utility Spotlight: Windows Server 로고 인증
Utility Spotlight
Windows Server 로고 인증
Venkat Krishnamachari
이 기사의 코드 다운로드: Works with Windows Server 2008 (KB)

Windows Server® 2008 소프트웨어 인증을 통해 Microsoft는 개발자가 모범 사례를 준수하고 IT 전문가는 구매 전에 응용 프로그램을 평가함으로써 시간을 절약하는 것은 물론 문제를 방지하도록 돕고 있습니다. Microsoft는 고객이 응용 프로그램 호환성을 쉽게 파악할 수 있도록 "Works with Windows Server 2008" 프로그램을 개발했습니다. 이 프로그램에는 응용 프로그램이 안정적인 환경을 제공하는지 확인하는 무료 지원 테스트 도구가 포함되어 있습니다.
이 "Works with" 도구는 파일 시스템, 레지스트리, 서비스 및 드라이버의 상태를 모니터링하여 해당 응용 프로그램이 수명 주기 동안 OS에 미치는 영향에 대해 데이터를 수집합니다. 그런 다음 이 데이터를 분석하여 테스트 성공/실패 정보를 보고합니다. windowsservercatalog.com/ready의 "Works with" 테스트 프레임워크 문서와 추가 도구에 보다 자세한 내용이 나와 있습니다. 이러한 도구를 통해 ISV는 응용 프로그램 호환성을 구축하고 IT 전문가는 응용 프로그램의 Windows Server 2008 배포 준비 상태를 평가할 수 있습니다.
이 도구를 사용하려면 먼저 테스트 컴퓨터에 최신 버전의 Windows Server 2008을 설치하고 windowsservercatalog.com/ready를 통해 "Works with" 도구를 다운로드해야 하며 응용 프로그램 검증 도구를 반드시 포함해야 합니다. 이 도구의 GUI에는 네 가지 간단한 기능, 즉 Create a test pass(테스트 단계 생성), Resume an existing test pass(기존의 테스트 단계 다시 시작), View test results(테스트 결과 보기), 그리고 Create a submission package(제출 패키지 생성)(공인 테스트 제공업체에 "Works with" 검증을 요청하는 ISV를 위한 기능)가 있습니다.
결과를 보여 주는 테스트 보고서
결과를 보여 주는 테스트 보고서
응용 프로그램의 설치, 구성, 실행 및 제거까지 전체 수명 주기를 거치면 테스트 단계가 생성됩니다. 주로 백그라운드에서 실행되는 이 "Works with" 도구는 OS의 안정성과 설치 프로그램의 호환성을 확인할 뿐만 아니라 플랫폼의 새 보안 요구 사항과 기타 구성 가능한 기능 환경에서 기능이 제대로 실행되는지 여부를 확인합니다. 일반적으로 테스트 단계를 완료하고 전체 보고서를 작성하는 것이 가장 좋습니다. 이 작업에는 보통 2~4시간이 소요됩니다. 그러나 테스트 단계를 중지하고 요약 보고서를 작성한 후 나중에 테스트를 다시 시작할 수도 있습니다.
모두 완료하면 스크린샷과 같이 모든 테스트 항목에 대해 자세한 결과와 함께 빨간색 또는 녹색의 상태 보고가 표시됩니다. 녹색 표시는 호환됨을 나타냅니다. 빨간색 표시의 경우 로그 파일에서 오류 정보를 검토할 수 있습니다. 로컬에서 생성된 로그 파일은 다른 시스템에 저장하여 테스트 컴퓨터가 포맷된 후에도 참조할 수 있도록 하십시오. 이 "Works with" 도구는 모든 서버 응용 프로그램을 평가하는 데 사용할 수 있으며 Windows Vista®용으로 설계된 클라이언트 구성 요소 및 관리 도구도 평가할 수 있습니다.
상업용 소프트웨어를 사용하는 경우 "Works with" 도구를 사용하면 알려진 호환 응용 프로그램 간의 마이그레이션 계획을 세울 수 있습니다. 또한 테스트 결과를 기반으로 공급업체에게 지원 계획에 대해 문의함으로써 개발자가 호환성 문제를 검색하고 해결 순서를 정하는 데 소모하는 시간을 절약할 수 있습니다. 사용자 지정 응용 프로그램의 경우, 개발 팀에 매우 구체적인 피드백을 제공할 수 있습니다. 또한 새로운 패치가 나올 때마다 계속 호환되는지 확인할 수 있고 IT 부서에서는 응용 프로그램 구성 데이터를 문서로 작성할 수도 있습니다. 일부 고객의 경우 이러한 도구를 통해 시스템 응용 프로그램이 사용하는 파일을 문서로 작성하기도 했습니다.
Microsoft가 사용자 환경에서 이런 도구의 활용도를 더욱 높이기 위해 테스트 항목이나 도구를 향상시킬 수 있는 방법에 대해 의견이 있으시면 wslogofb@microsoft.com으로 보내 주십시오.

Venkat Krishnamachari는 2005년부터 Windows Server 소프트웨어 인증을 위한 기술 팀장으로 일하고 있으며 그 전에는 SQL Server 2005 개발 팀에서 근무했습니다.


 The Cable Guy: ISATAP로 인트라넷을 IPv6으로 마이그레이션
The Cable Guy
ISATAP로 인트라넷을 IPv6으로 마이그레이션
Joseph Davies
이 문서는 Windows Server 2008 시험판 버전을 기준으로 작성되었습니다. 이 문서에 수록된 모든 정보는 변경될 수 있습니다.

IPv6(인터넷 프로토콜 버전 6)에 대한 일반적인 오해 중 하나는, 이를 사용하려면 기본 IPv6 주소 지정 및 라우팅을 배포해야 하며, 이를 위해서는 IPv6 주소 지정 체계에 대한 심층적 분석, 라우터 업데이트와 구성 그리고 롤아웃 일정이 필요하다는 것입니다. 이러한 작업 모두가 기본 IPv6 연결을 위해
언젠가는 해야 할 일이지만 ISATAP(Intra-Site Automatic Tunnel Addressing Protocol)를 사용하면 터널링된 IPv6 연결을 손쉽게 배포할 수 있습니다. 터널링된 IPv6 연결을 사용하면 ISATAP를 지원하는 호스트는 IPv4 헤더로 캡슐화된 IPv6 트래픽을 사용하여 통신할 수 있습니다(IPv4 프로토콜 필드는 41로 설정됨). ISATAP 트래픽은 IPv4 전용 인트라넷에서도 전송 가능하므로 기본 IPv6 인프라가 구축될 때까지 기다릴 필요 없이 곧바로 IPv6 지원 응용 프로그램을 테스트할 수 있습니다.
ISATAP는 IPv4 전용 인트라넷을 가로질러 IPv6/IPv4 호스트 간에 유니캐스트 IPv6 연결을 제공하는 주소 할당 및 자동 터널링 기술이며 RFC 4214에 정의되어 있습니다. ISATAP 호스트는 UnicastPrefix:0:5EFE:w.x.y.z(w.x.y.z가 ISATAP 호스트에 할당된 개인 IPv4 주소인 경우) 또는 UnicastPrefix:200:5EFE:w.x.y.z(w.x.y.z가 ISATAP 호스트에 할당된 공용 IPv4 주소인 경우)와 같은 형식으로 ISATAP 주소가 할당된 논리적 터널링 인터페이스를 사용합니다. UnicastPrefix는 링크-로컬, 글로벌 및 고유 로컬 접두사를 포함한 64비트 유니캐스트 주소 접두사입니다. ISATAP 주소의 예로는 2001:DB8::98CA:200:131.107.28.9 및 2001:DB8::98CA:0:10.91.211.17이 있습니다.

ISATAP로 인트라넷을 IPv6으로 마이그레이션
ISATAP 배포는 64비트 IPv6 서브넷 접두사가 할당된 IPv4 전용 네트워크인 하나 이상의 논리적 ISATAP 서브넷으로 구성됩니다. 논리적 ISATAP 서브넷에는 ISATAP 호스트와 ISATAP 라우터가 있습니다. ISATAP 호스트는 ISATAP 터널링 인터페이스를 사용하여 IPv6 트래픽을 캡슐화합니다. 이 트래픽은 동일한 논리적 ISATAP 서브넷에 있는 다른 ISATAP 호스트로 직접 전송될 수 있습니다. 다른 ISATAP 서브넷 또는 기본 IPv6 서브넷에 있는 목적지에 도달하기 위해 트래픽은 ISATAP 라우터로 전송됩니다. ISATAP 라우터는 서브넷 접두사를 ISATAP 호스트로 알리고 ISATAP 호스트와 다른 IPv6 서브넷의 호스트 사이에 IPv6 트래픽을 전달하는 IPv6 라우터입니다. 그림 1에서는 단순화된 인트라넷에서 ISATAP의 구성 요소를 보여 줍니다.
그림 1 인트라넷의 IPv4 전용 및 IPv6 지원 부분
그림 1 인트라넷의 IPv4 전용 및 IPv6 지원 부분
ISATAP를 사용하면 인트라넷에서 기본 IPv6 주소 지정 및 라우팅 기능을 세 단계로 배포할 수 있습니다.
1단계: IPv4 전용 인트라넷 이 단계에서 전체 인트라넷은 하나의 논리적인 ISATAP 서브넷일 수 있습니다. 그림 2에서는 글로벌 또는 고유 로컬 주소 접두사를 ISATAP 호스트에 알리기만 하는 ISATAP 라우터가 있는 IPv4 전용 인트라넷의 예를 보여 줍니다.
그림 2 IPv4 전용 인트라넷
그림 2 IPv4 전용 인트라넷
2단계: 인트라넷의 IPv4 전용 및 IPv6 지원 부분 이 중간 단계에서는 인트라넷에 IPv4 전용 부분(논리적 ISATAP 서브넷)과 IPv6 지원 부분이 있습니다. 인트라넷의 IPv6 지원 부분은 IPv4를 지원하며 기본 IPv6 주소 지정과 라우팅을 지원하도록 업데이트되었습니다. 그림 1에서 이 구성을 볼 수 있습니다.
3단계: IPv6 지원 인트라넷 이 마지막 단계에서는 전체 인트라넷이 IPv4와 기본 IPv6 주소 지정 및 라우팅을 모두 지원합니다. ISATAP는 더 이상 필요하지 않습니다. 그림 3에 예가 나와 있습니다.
그림 3 IPv6 지원 인트라넷
그림 3 IPv6 지원 인트라넷
ISATAP를 사용하면 IPv4 전용 인트라넷에서 IPv6 지원 인트라넷으로 이전하는 처음 두 단계 중 호스트와 응용 프로그램 간에 IPv6 연결을 구현할 수 있습니다.

Windows Server 2008과 Windows Vista
Windows Server® 2008 및 Windows Vista®의 IPv6 프로토콜은 ISATAP 호스트와 ISATAP 라우터를 모두 지원합니다. 다른 DNS 접미사가 할당된 컴퓨터에 설치된 LAN 인터페이스마다 별도의 ISATAP 터널링 인터페이스가 있습니다. 예를 들어 Windows Vista를 실행하는 컴퓨터에 있는 두 개의 LAN 인터페이스에 모두 동일한 인트라넷이 연결되어 있으며 동일한 DNS 접미사가 할당되어 있는 경우에는 ISATAP 터널링 인터페이스가 하나만 있습니다. 이 두 개의 LAN 인터페이스가 다른 DNS 접미사가 할당된 서로 다른 두 네트워크에 연결된 경우에는 두 개의 ISATAP 터널링 인터페이스가 있습니다. Windows Server 2008 또는 Windows Vista SP1을 실행하는 컴퓨터에서는 이름 "ISATAP"를 확인할 수 없는 경우 ISATAP 터널 인터페이스가 '미디어 연결 끊김' 상태가 됩니다.
기본적으로 서비스 팩이 설치되지 않은 Windows Vista의 IPv6 프로토콜은 해당 LAN 인터페이스에 할당된 IPv4 주소에 대한 ISATAP 터널 인터페이스에서 링크-로컬 ISATAP 주소(FE80::5EFE: w.x.y.z 또는 FE80::200:5EFE:w.x.y.z)를 자동으로 구성합니다.
Windows Server 2008 및 Windows Vista SP1의 IPv6 프로토콜은 이름 "ISATAP"를 확인할 수 있는 경우에만 ISATAP 터널 인터페이스에서 링크-로컬 ISATAP 주소를 구성합니다.
ISATAP 호스트가 ISATAP 라우터에서 라우터 알림 메시지를 수신하려면 ISATAP 라우터에 라우터 요청 메시지를 전송해야 합니다. 이더넷 서브넷에서는 기본 IPv6 호스트가 멀티캐스트 라우터 요청 메시지를 전송하고 서브넷의 라우터는 라우터 알림 메시지로 응답합니다. ISATAP는 IPv4 멀티캐스트 트래픽을 사용하거나 IPv4 멀티캐스트 지원 인프라를 필요로 하지 않기 때문에 ISATAP 호스트는 라우터 요청 메시지를 ISATAP 라우터로 유니캐스트해야 합니다.
ISATAP 호스트는 라우터 요청 메시지를 ISATAP 라우터로 유니캐스트하기 위해 먼저 논리적 ISATAP 서브넷에서 ISATAP 라우터 인터페이스의 유니캐스트 IPv4 주소를 확인해야 합니다. Windows Server 2008 및 Windows Vista의 IPv6 프로토콜의 경우 ISATAP 호스트는 호스트 이름 "ISATAP"를 IPv4 주소로 확인하거나 netsh interface isatap set router 명령을 사용하여 ISATAP 라우터의 유니캐스트 IPv4 주소를 가져옵니다.

인트라넷 마이그레이션: 1단계
IPv6으로 마이그레이션하는 작업의 1단계로 ISATAP를 인트라넷에 배포하려면 다음 단계를 수행해야 합니다.
ISATAP 서브넷 접두사 확인 인트라넷에 해당하는 논리적 ISATAP 서브넷에 할당할 64비트 서브넷 접두사를 확인해야 합니다. 48비트 접두사는 ISP 또는 인터넷 등록 기관에서 얻을 수 있으며 48비트 고유 로컬 접두사를 직접 파생시킬 수도 있습니다(tools.ietf.org/html/rfc4193에서 RFC 4193 참조).
48비트 접두사에서 논리적 ISATAP 서브넷을 위한 16비트 서브넷 ID를 선택합니다. 48비트 접두사 및 16비트 서브넷 ID의 조합이 64비트 ISATAP 서브넷 접두사입니다. 예를 들어 48비트 고유 로컬 접두사 FD8A:219C:052A::/48과 서브넷 ID 1이 조합되면 64비트 서브넷 접두사 FD8A:219C:052A:1::/64가 생성됩니다.
ISATAP 라우터 컴퓨터 지정 ISATAP 라우터로 사용할 컴퓨터를 결정합니다. 시중의 많은 라우터가 ISATAP 라우터 기능을 지원하지만 여기에서 설명하는 정보는 Windows Server 2008을 실행하는 컴퓨터와 관련된 것입니다.
ISATAP 라우터 컴퓨터에는 LAN 인터페이스가 여러 개일 필요가 없으며 1단계에서 인트라넷의 IPv6 지원 부분에 연결할 필요도 없습니다. 하지만 나중에 인트라넷의 IPv6 지원 부분에 연결되는 추가적인 LAN 인터페이스로 업데이트할 수 있도록 컴퓨터를 선택해야 합니다.
ISATAP 라우터 컴퓨터 구성 ISATAP 라우터 컴퓨터에서 다음 명령을 실행하면 ISATAP 라우터 컴퓨터의 ISATAP 터널링 인터페이스가 '미디어 연결됨' 상태가 됩니다.
netsh interface isatap set router IPv4Address
IPv4Address는 논리적 ISATAP 서브넷에 연결된 ISATAP 라우터 컴퓨터의 LAN 인터페이스에 할당된 IPv4 주소입니다.
다음으로, 논리적 ISATAP 서브넷에 연결된 ISATAP 라우터 컴퓨터의 LAN 인터페이스에 해당하는 ISATAP 터널링 인터페이스의 이름 또는 인터페이스 색인을 확인합니다. 이것은 다음 명령의 출력을 통해 확인할 수 있습니다.
netsh interface ipv6 show interfaces
그런 다음 아래 명령을 사용하여 ISATAP 인터페이스에서 알림을 사용하도록 설정합니다.
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex advertise=enabled
ISATAPInterfaceNameOrIndex는 ISATAP 터널링 인터페이스의 이름 또는 인터페이스 색인입니다.
그런 다음 아래 명령을 사용하여 ISATAP 라우터 컴퓨터가 ISATAP 호스트에 ISATAP 서브넷 접두사를 알리도록 구성합니다.
netsh interface ipv6 add route ISATAPSubnetPrefix ISATAPInterfaceNameOrIndex publish=yes
ISATAPSubnetPrefix가 확인된 ISATAP 서브넷 접두사입니다.
DNS 구성 사용자의 DNS에서 인트라넷의 ISATAP 호스트가 이름 "ISATAP"를 성공적으로 확인할 수 있도록 이름 ISATAP에 대한 주소 (A) 레코드를 적절한 도메인에 추가합니다. 예를 들어 인트라넷 호스트가 contoso.com DNS 접미사를 사용하는 경우에는 IPv4 전용 인트라넷에서 ISATAP 라우터의 LAN 인터페이스에 할당된 IPv4 주소를 사용하여 이름 isatap.contoso.com에 대해 contoso.com 도메인에 A 레코드를 추가해야 합니다.
DNS 서버에서 Windows Server 2008을 실행하는 경우에는 DNS 서버에서 레지스트리 편집기(regedit.exe)를 사용하여 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters\GlobalQueryBlockList 레지스트리 값에서 ISATAP 항목을 제거합니다.
ISATAP 호스트 테스트 인트라넷의 ISATAP 호스트에서 Ipconfig 도구를 사용하여 할당된 주소를 봅니다. ISATAP 호스트의 주소 형태는 ISATAPSubnetPrefix:: 5EFE:w.x.y.z 또는 ISATAPSubnetPrefix:: 200:5EFE:w.x.y.z와 같아야 합니다. 예를 들어 ISATAP 서브넷 접두사가 FD8A:219C: 052A:1::/64이고 ISATAP 호스트의 IPv4 주소가 10.1.31.97인 경우 ISATAR 호스트의 주소 FD8A: 219C:052A:1::5FE:10.1.31.97이 ISATAP 터널링 인터페이스에 할당되어야 합니다.
ISATAP 호스트에 ISATAP 서브넷 접두사 기반의 ISATAP 주소가 없는 경우에는 호스트가 이름 "ISATAP"를 확인할 수 있는지 살펴봅니다. 확인할 수 없으면 A 레코드가 적절한 도메인에서 생성되었는지 확인하고, Windows Server 2008을 실행하는 DNS 서버의 경우에는 GlobalQueryBlockList 레지스트리 값이 수정되어 ISATAP 항목이 제거되었는지 확인합니다. 이름을 확인할 수 있으면 ISATAP 라우터 컴퓨터가 올바르게 구성되었는지 살펴봅니다. 올바르게 구성되었으면 인트라넷의 라우터가 IPv4 프로토콜 41 트래픽의 전달을 허용하는지 확인합니다.
ISATAP 호스트는 ISATAP 서브넷 접두사 기반의 주소를 사용하여 자체적으로 구성할 수 있는 경우 이러한 ISATAP 주소를 DNS에 AAAA 레코드로 등록하고 이를 IPv6 기반 연결에 사용하기 시작합니다.

인트라넷 마이그레이션: 2단계
IPv6으로의 마이그레이션 2단계에서는 인트라넷의 IPv4 전용 및 IPv6 지원 부분 사이에서 전달을 수행하도록 ISATAP 라우터 구성을 수정해야 합니다.
ISATAP 라우터 컴퓨터에서 다음 명령을 실행합니다.
netsh interface ipv6 show interfaces
위의 명령 출력에서 인트라넷의 IPv6 지원 부분 및 ISATAP 터널링 인터페이스 연결된 LAN 인터페이스의 이름 또는 인터페이스 색인을 확인합니다.
다음 명령을 사용하여 ISATAP 인터페이스에서 전달을 사용하도록 설정합니다.
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex forwarding=enabled
다음 명령을 사용하여 LAN 인터페이스에서 전달을 사용하도록 설정합니다.
netsh interface ipv6 set interface LANInterfaceNameOrIndex forwarding=enabled
LANInterfaceNameOrIndex는 LAN 인터페이스의 이름 또는 인터페이스 색인입니다.
다음 명령을 사용하여 ISATAP 라우터에 대한 기본 경로를 추가합니다.
netsh interface ipv6 add route ::/0 LANInterfaceNameOrIndex NextHopAddress publish=yes
NextHopAddress는 인트라넷의 IPv6 지원 부분에서 인접 기본 IPv6 라우터의 IPv6 주소입니다.
인트라넷의 IPv6 지원 부분에서 논리적 ISATAP 서브넷에 도달할 수 있도록 하려면 ISATAP 라우터 컴퓨터를 가리키는 ISATAP 서브넷 접두사에 대한 경로를 사용하여 기본 IPv6 라우터를 구성하는 것이 중요합니다.
인트라넷의 IPv6 지원 부분에서 컴퓨터에 대한 ISATAP를 선택적으로 사용하지 않도록 설정하려면 인트라넷의 IPv6 지원 부분에 있는 컴퓨터가 이름 ISATAP를 확인할 수 없도록 DNS에서 이름 ISATAP에 대한 A 레코드를 조작합니다.
또 다른 방법은 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters\DisabledComponents 레지스트리 값을 만들고 0x4(DWORD 형식)로 설정하는 것입니다.

인트라넷 마이그레이션: 3단계
3단계에서는 전체 인트라넷이 IPv6을 지원하는 경우 DNS를 통해 ISATAP 배포를 제거하고 ISATAP 라우터 컴퓨터를 다시 구성해야 합니다. DNS의 경우 이름 ISATAP에 대한 모든 A 레코드를 제거합니다. 이렇게 하면 호스트가 ISATAP 라우터의 IPv4 주소를 확인하는 것을 막을 수 있습니다.
ISATAP 라우터 컴퓨터에서 다음 명령을 실행합니다.
netsh interface isatap set router default
이 명령은 ISATAP 구성 요소를 해당 기본 상태로 재설정합니다.
이 명령의 출력에서 ISATAP 터널링 인터페이스의 이름 또는 인터페이스 색인을 확인합니다.
netsh interface ipv6 show interfaces
다음 명령을 사용하여 ISATAP 인터페이스의 전달 및 알림을 사용하지 않도록 설정합니다.
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex forwarding=disabled advertise=disabled
다음 명령을 사용하여 ISATAP 라우터 컴퓨터에서 ISATAP 서브넷 접두사 경로를 제거합니다.
netsh interface ipv6 delete route ISATAPSubnetPrefix ISATAPInterfaceNameOrIndex
ISATAPSubnetPrefix가 ISATAP 서브넷 접두사입니다.
중복 ISATAP 라우터 및 방화벽 고려 사항을 비롯하여 ISATAP 배포에 대한 자세한 내용을 보려면 "ISATAP(Intra-Site Automatic Tunnel Addressing Protocol) 배포 가이드"(go.microsoft.com/fwlink/?LinkId=106926)를 참조하십시오.

Joseph Davies는 Microsoft의 기술 전문 저술가로 1992년부터 Windows 네트워킹을 주제로 글을 쓰고 가르치는 일을 하고 있습니다. Microsoft Press에서 8권의 책을 저술한 그는 월간 온라인 TechNet Cable Guy 칼럼의 저자이기도 합니다. The Cable Guy 칼럼은 microsoft.com/technet/community/columns/cableguy/about.mspx에서 읽을 수 있습니다.


 Windows PowerShell: 진행률 보고서
Windows PowerShell
진행률 보고서
Don Jones

최근에 꽤 길고 복잡한 Windows PowerShell 스크립트를 작성했는데, 이 스크립트는 실행될 때 상당히 오랫동안 응답하지 않습니다. 예약된 작업으로 실행되도록 이 스크립트를 작성했기 때문에 출력의 대부분이 시각적인 방식으로는 제공되지 않습니다. 처음으로 큰 테스트를 위해 실행했을 때 필자는 실수로 무한 루프를
작성했거나 다른 문제가 있는지 걱정하지 않을 수 없었습니다.
셸에 작은 커서만 깜박이고 있으므로 스크립트가 중지되었는지 여부를 알 수가 없었습니다. 스크립트를 중단하기 위해 Ctrl+C를 재빨리 눌렀기 때문에 겉으로 보기에는 확신할 수 없었던 것입니다. 이런 문제를 해결하려면 진행률 보고 기능을 추가해야 합니다.

들어가는 말
이달의 Cmdlet: Tee-Object
이번 달에는 필자가 자주 사용하는 문제 해결 cmdlet 중 하나를 살펴보겠습니다. 다음 코드를 예로 들어 보겠습니다.
Get-WMIObject Win32_Service | Where { $_.State -ne "Running"
-and $_.StartMode -eq "Automatic" } | ForEach-Object { $_.Start() }
이 코드는 자동으로 시작되도록 설정되었지만 어떤 이유에서든 아직 시작되지 않은 모든 서비스를 시작하기 위한 것입니다. 그러나 코드는 실제로 작동하지 않으며 파이프라인 속을 들여다볼 수 없기 때문에 작동하지 않는 이유를 찾는 것이 까다로울 수 있습니다. 즉, Tee-Object를 사용하지 않으면 내부를 들여다볼 수 없습니다.
Tee-Object는 개체를 파일로(또는 변수로) 리디렉션하고 이를 파이프라인으로 전달합니다. 예를 들면 다음과 같습니다.
Get-WMIObject Win32_Service | Tee-Object AllServices.csv | Where
{ $_.State -ne "Running" -and $_.StartMode -eq "Automatic" } |
Tee-Object FilteredServices.csv | ForEach-Object { $_.Start() }
이렇게 수정하면 각 파이프라인 명령 뒤에 무엇이 수행되는지 알 수 있으며, 이를 통해 FilteredServices.csv 파일에 아무것도 포함되어 있지 않은 것을 곧 발견하게 됩니다. 당연하게도 이 스크립트는 작동하지 않았습니다. 조금 더 조사해 보면 문제의 근본 원인은 StartMode가 "Automatic"이 아니라 "Auto"이기 때문임을 알 수 있습니다. Tee-Object를 통해 문제가 발생한 정확한 위치를 알 수 있습니다.

필자는 먼저 스크립트가 수행하는 작업에 대해 정확하게 알 수 있도록 상태 메시지를 추가하려고 했습니다. 셸을 통해 Write-Verbose cmdlet을 사용하면 이 작업을 비교적 쉽게 수행할 수 있습니다. 이제 셸에서 직접 실습해 보겠습니다.
Write-Verbose "Test Message"
이렇게 해보면 아무 작업도 수행되지 않은 것을 알 수 있습니다. Write-Verbose는 기본적으로 출력을 표시하지 않는 특수 Verbose 파이프라인으로 개체를 전송하기 때문입니다. 기본 제공 셸 변수인 $VerbosePreference가 이 파이프라인을 제어합니다. 이 변수의 기본값은 자세한 정보가 출력되지 않도록 하는 SilentlyContinue입니다. 하지만 값을 Continue로 설정하면 파이프라인이 열립니다.
$VerbosePreference = "Continue"
이제 스크립트에 Write-Verbose 문을 여러 개 추가하여 스크립트가 실행될 때 그 진행 과정을 자세히 볼 수 있습니다. 이 방법은 테스트 및 문제 해결을 완료한 경우 스크립트 시작 부분에서 $VerbosePreference를 다시 SilentlyContinue로 설정하여 추가적인 메시지가 더 이상 표시되지 않도록 할 수 있다는 점에서 유용합니다.
즉, Write-Verbose 문을 모두 제거할 필요가 없습니다. 실제로 이 문은 스크립트에 남아 있기 때문에 스크립트를 수동으로 실행해야 할 경우 필요에 따라 Verbose 파이프라인을 손쉽게 다시 설정할 수 있습니다.

실제 진행률이 필요한 경우
스크립트가 무한 루프에 빠진 것이 아니며 완벽하게 작동한다는 것을 확인한 후 필자는 확실히 하기 위해 Verbose 파이프라인을 해제하고 다시 실행했습니다.
여기서 문제는 스크립트가 정상적으로 작동한다는 것은 알고 있지만 아무런 메시지 없이 커서만 깜박인다는 점입니다. 필자는 인내심이 그리 많지 않아서 무작정 기다리는 것을 좋아하지 않습니다.
즉, 스크립트가 얼마나 진행되었으며 언제 완료될지를 알 필요가 있었습니다. 기본적으로 진행률 표시줄과 같은 기능이 필요합니다.
다행히 Windows PowerShellTM에는 Write-Progress cmdlet이 포함되어 있습니다. 이 cmdlet은 Windows®에서 볼 수 있는 그래픽 진행률 표시줄을 제공하지는 않지만 그림 1과 같은 훌륭한 진행률 표시줄을 제공합니다. 이것은 Windows Server® 2003 또는 Windows XP의 텍스트 기반 설치 부분에 사용되는 파일 복사 진행률 표시줄과 비슷합니다.
그림 1 스크립트의 진행률
그림 1 스크립트의 진행률
Write-Progress를 사용하려면 약간의 설명이 필요합니다. 예를 들어서 설명하면 이해가 더 빠르겠지요. 다음 스크립트를 예로 들겠습니다.
for ($a=1; $a -lt 100; $a++) {
  Write-Progress -Activity "Working..." `
   -PercentComplete $a -CurrentOperation
   "$a% complete" `
   -Status "Please wait."
  Start-Sleep 1
}
이 스크립트는 Write-Progress를 사용하여 진행률 표시줄을 표시합니다. Start-Sleep을 사용하여 루프를 통과할 때마다 스크립트를 1초 동안 일시 중지하여 진행률을 볼 수 있을 정도로 느리게 실행합니다. 일시 중지하지 않으면 루프는 0부터 100까지 너무 빠르게 카운트를 실행하기 때문에 진행률 표시줄이 화면에서 잠깐 깜박이는 형태로만 표시됩니다.
여기서 볼 수 있듯이, Working으로 설정한 Activity가 진행률 표시줄의 맨 위에 표시됩니다. Status는 바로 아래에 표시되고 CurrentOperation은 맨 밑에 표시됩니다. 셸에서는 한 번에 하나의 진행률 표시줄만 사용할 수 있습니다. Write-Progress를 사용하면 현재 진행률 표시줄이 표시되지 않은 경우 하나를 새로 만들고 현재 진행률 표시줄이 표시된 경우 이를 업데이트합니다.
여기서는 작업이 완료되면 진행률 표시줄이 사라지도록 하는 명령을 지정하지 않았습니다. 완료된 경우 진행률 표시줄이 사라지도록 하려면 스크립트 끝 부분에 다음을 추가하면 됩니다.
Write-Progress -Activity "Working..." `
 -Completed -Status "All done."
일반적으로 진행률 표시줄은 스크립트가 완료되면 자동으로 사라지지만, 스크립트에서 수행할 다른 작업이 있다면 해당 진행률 표시줄과 관련된 작업이 완료될 때 이를 숨겨야 합니다. 이 경우 -Completed 매개 변수를 사용하면 진행률 표시줄이 제거됩니다.

남은 시간
Write-Progress의 또 다른 일반적인 용도는 실제 진행률 표시줄이 아니라 "남은 시간(초)" 표시를 만드는 것입니다. 다음은 이 작업에 대한 예입니다.
for ($a=100; $a -gt 1; $a--) {
  Write-Progress -Activity "Working..." `
   -SecondsRemaining $a -CurrentOperation
   "$a% complete" `
   -Status "Please wait."
  Start-Sleep 1
}
여기에서는 100에서 1까지 카운트다운을 실행하도록 루프를 변경하고 PercentComplete 대신 Write-Progress의 SecondsRemaining 매개 변수를 사용했습니다. 그림 2에서 그 결과를 볼 수 있습니다. 그림에서 볼 수 있듯이 진행률 표시가 사라지고 대신 카운트다운 시계가 나타납니다. 셸은 초 단위의 총 남은 시간을 자동으로 시, 분, 초로 변환하여 사용자에게 더 익숙한 정보를 제공합니다. 여기에 표시된 완료율은 필자가 제공한 CurrentOperation 매개 변수이므로 실제로 100부터 카운트다운을 실행합니다. 완료율이 실제로 계산되는 것은 아닙니다. Windows PowerShell에서는 "% complete" 문자열 앞에 단순히 $a의 현재 값을 표시합니다.
그림 2 스크립트 완료까지 남은 시간
그림 2 스크립트 완료까지 남은 시간

진행 정보를 제공하는 스크립트
필자는 수행할 작업에 대해 알려 주도록 스크립트를 작성하는 것을 선호합니다. 자세한 정보를 출력하는 형태를 사용하거나 간단히 진행률 표시줄을 사용할 수도 있습니다. 이러한 방식은 필자처럼 인내심이 부족한 사람을 위한 것일 수도 있고 필자의 스크립트를 실행해야 하는 사람에게 필요할 수도 있습니다. 어떠한 형태로든 상태 및 진행률 정보를 표시하면 많은 이점을 얻게 됩니다.

Don Jones는 TechNet Magazine의 객원 편집자이자 Windows PowerShell: TFM(SAPIEN Press, 2007)의 공동 저자입니다. Windows PowerShell 강사(www.ScriptingTraining.com 참조)이기도 한 그는 웹 사이트 ScriptingAnswers.com을 통해 연락할 수 있습니다.


 Hey, Scripting Guy!: Scripting Guy가 즐기는 셸 게임
Hey, Scripting Guy!
Scripting Guy가 즐기는 셸 게임
Microsoft Scripting Guys
이 기사의 코드 다운로드: HeyScriptingGuy2008_03.exe (150KB)

옛 속담에 아무리 작은 참새라도 하느님 모르게 땅으로 떨어질 수는 없다는 말이 있습니다. 참새를 사냥하는 사람들이 들으라고 하는 이야기는 아닙니다. 뭐, 토요일 아침 7:00시부터 지붕에 앉아서 깍깍 울어대는 까마귀라면 좀 손봐줄 필요는 있겠죠. [Scripting Editor는 까마귀를 좋아합니다. 그리고 이 칼럼을 쓴 Scripting Guy의 "손봐준다"는 표현은 "건강에 이상이 없는지 확인한다"는 의미라고 확신합니다.-편집자] 물론, 나락으로 떨어질 때, 아무리 체구가 작고 외모가 초라하더라도 그런 우리를 지켜보고 돌보는 누군가가 있다는 사실은 큰 위안이 됩니다. [그게 그저 이 편집자라 할지라도 말입니다.-편집자]
이는 참새뿐만 아니라 시스템 관리 스크립팅에 있어서도 마찬가지입니다. 스크립팅의 세계는 Windows PowerShellTM, VBScript, WMI, ADSI는 물론 FileSystemObject까지, 몇 가지 주요 스크립팅 기술을 중심으로 돌아간다고 해도 과언이 아닙니다. 멋진 작업과 유용한 기능을 제공하는 이러한 기술에 열광하고 너도나도 사용하는 현상이 이해되지 않는 바는 아니지만, 스크립트 작성자가 꼭 이러한 기술만 사용해야 하는 것은 아닙니다. 선택의 폭이 이보다는 훨씬 넓다는 말이죠.
셸 개체를 예로 들어봅시다. 셸 개체가 Windows PowerShell만큼 잘 알려지거나 널리 사용되고 있는 것은 아니지만, 그래도 중요하고 유용한 기술임에는 틀림없습니다.
조만간에 사람들이 셸 개체를 사용하는 시스템 관리 스크립트를 작성해달라고 부탁해올 날이 분명 올 겁니다. 그렇다면 대체 셸 개체로 무엇을 할 수 있는 것일까요? 사실 디스크 할당량을 관리하고 파일을 복사 또는 이동할 때 진행률 표시줄을 표시하는 등 셸 개체로 구현할 수 있는 멋진 기능은 무궁무진합니다. Microsoft® Windows® 2000 스크립팅 가이드(microsoft.com/technet/scriptcenter/guide)에도 그 중 몇 가지가 소개되어 있습니다. 이번 달 칼럼에서는 셸 개체로 구현할 수 있는 다른 멋진 기능을 살펴보도록 하겠습니다. 아마 셸 개체만으로 이런 기능을 구현할 수 있다는 사실에 놀라실 겁니다.

마지막으로 파일을 수정한 날짜 변경
이 소제목을 보고 아마 "잠깐! 파일의 마지막으로 수정한 날짜는 변경할 수 없잖아? 적어도 VBScript로는 불가능한데"라고 생각하는 사람이 많을 겁니다. 그런 분들에게 우리가 해줄 수 있는 말은 "대체 무슨 근거로 그렇게 생각하게 되었냐"입니다.
아, 사실 Scripting Guy도 예전에는 같은 생각을 가지고 있었습니다. 그런데 우리 생각이 틀린 것 같습니다. 놀라지 마십시오. VBScript로도 파일의 마지막 수정 날짜를 변경할 수 있습니다. 그리고 그렇게 하려면 셸 개체가 필요합니다.
한 가지 말씀 드리자면, Scripting Guy가 어떻게 이러한 사실을 모르고 있었냐는 말은 하지 마십시오. 지금까지는 너무 명백한 사실이었으니까요. 그보다 앞으로 이런 실수를 하지 않으려면 어떻게 해야 할지를 고민하는 것이 낫습니다.
자, 그럼 파일의 마지막 수정 날짜를 변경하려면 어떻게 해야 할까요? 다음 스크립트만 사용하면 됩니다.
Set objShell = _
  CreateObject("Shell.Application")

Set objFolder = _
  objShell.NameSpace("C:\Scripts")
Set objFolderItem = _
  objFolder.ParseName("Dr_Scripto.jpg")

objFolderItem.ModifyDate = _
  "01/01/2008 8:00:00 AM"
보다시피 특별히 복잡한 것은 없습니다. 먼저 Shell.Application 개체의 인스턴스를 만듭니다. 한 가지 주의할 것은 Shell.Application과 Windows 스크립트 호스트 셸 개체인 Wscript.Shell을 혼동해서는 안 됩니다. 여기서 사용하는 셸 개체는 Windows 셸 개체입니다. 셸 개체의 인스턴스가 실행되면 Namespace 메서드를 사용하여 C:\Scripts 폴더에 바인딩한 다음 ParseName이라는 이상한 이름의 메서드로 해당 폴더의 지정된 파일에 바인딩합니다. 이 경우에는 파일 이름이 Dr_Scripto.jpg인 JPEG 이미지에 바인딩합니다.
Set objFolderItem = _
  objFolder.ParseName("Dr_Scripto.jpg")
파일 자체에 바인딩한 후에는 어떻게 해야 할까요? 간단합니다. ModifyDate 속성에 새 날짜와 시간을 할당하면 됩니다.
objFolderItem.ModifyDate = _
  "01/01/2008 8:00:00 AM"
이제 다 끝났습니다.
그렇습니다. 너무 멋지죠. 이 스크립트를 실행하면 파일의 마지막 수정 날짜가 2008년 1월 1일 오전 8:00로 설정됩니다. 원한다면 Windows 탐색기에서 C:\Scripts 폴더를 열어 직접 확인해 보십시오.
물론 여러분 중에 "파일의 마지막 수정 날짜를 변경할 수 있다니 멋지긴 한데, 파일의 마지막 수정 날짜를 굳이 변경해야 할 이유가 있을까?"라고 생각하는 분도 있을 겁니다. 마지막 수정 날짜를 일종의 버전 제어 시스템으로 사용하는 경우가 많습니다. 일례로, 스크립트의 여러 복사본을 이곳 저곳에 사용할 경우 마지막 수정 날짜를 확인하는 것도 공식 버전을 추적하는 한 방법이 될 수 있습니다. 마지막 수정 날짜를 통해 해당 스크립트의 특정 복사본이 원본 스크립트에서 수정되었는지 여부를 확인할 수 있습니다.
맞습니다. 누군가 앞서 살펴본 스크립트를 실행하여 마지막 수정 날짜를 변경할 수도 있습니다. 하지만 코드 서명이 조금만 부족해도 이렇게 시스템을 조작하는 문제는 언제든지 발생할 수 있습니다. 스크립트를 공유하는 동료들이 모두 선하다는 전제하에 이 방법은 충분히 유용하다고 할 수 있습니다.
모든 스크립트의 마지막 수정 날짜를 업데이트하고 표준화해야 하는 경우도 있습니다. 이렇게 하려면 어떻게 해야 할까요? C:\Scripts 폴더에 모든 스크립트가 있다면 다음 코드만 실행하면 됩니다.
Set objShell = _
  CreateObject("Shell.Application")

Set objFolder = _
  objShell.NameSpace("C:\Scripts")
Set colItems = objFolder.Items

For Each objItem In colItems
    objItem.ModifyDate  = _
      "01/01/2008 8:00:00 AM"
Next
보다시피 이 스크립트는 앞서 소개한 첫 번째 스크립트와 시작 부분이 매우 비슷합니다. 하지만 여기서는 C:\Scripts 폴더에 바인딩한 후에 ParseName을 사용하여 해당 폴더의 개별 파일에 바인딩하는 대신 다음 코드 줄로 해당 폴더에 있는 모든 파일의 컬렉션을 반환합니다.
Set colItems = objFolder.Items
컬렉션이 반환되면 For Each 루프를 설정하여 컬렉션의 모든 항목에 대해 루프를 실행할 수 있습니다. For Each 루프에는 컬렉션에 있는 첫 번째 파일의 ModifyDate 속성 값을 2008년 1월 1일 오전 8:00로 변경하는 다음 코드 줄을 사용합니다.
objItem.ModifyDate  = _
  "01/01/2008 8:00:00 AM"
다음으로 컬렉션의 다음 파일에 대해 루프를 실행하여 프로세스를 반복합니다. 루프 실행이 완료되면 C:\Scripts 폴더에 있는 모든 파일(숨김 파일 제외)의 마지막 수정 날짜가 같아집니다. 자, 얼마나 쉽습니까? VBScript로 파일의 마지막 수정 날짜를 변경할 수 없다고 하셨나요?
아, 여기서 여담을 한 가지 하고 넘어가야겠군요.

틀린다는 것에 대해...
Scripting Guy가 시스템 관리 스크립팅 작업을 처음 시작했던 당시에는 NTFS 파일 시스템의 파일에 연결된 모든 확장 파일 정보에 액세스할 방법이 없었습니다. 예를 들어 .wav 파일을 마우스 오른쪽 단추로 클릭하고 속성을 클릭하면 그림 1과 유사한 정보가 표시됩니다.
그림 1 파일 속성 요약
그림 1 파일 속성 요약
스크립트를 사용하여 비트 전송률이나 오디오 샘플 크기 같은 값을 검색하려면 어떻게 해야 할까요? 대답은 "불가능하다"입니다. 셸 개체를 사용하지 않는다면 말이죠. Windows 데스크톱 검색 3.0을 다운로드하여 설치한 경우 이 소프트웨어를 사용할 수도 있습니다. 언제인가 파일에 대한 모든 확장 속성 정보를 검색하는 기능이 셸 개체에 추가되었지만 웬일인지 Scripting Guy는 그 사실을 간과했습니다. 그 결과 사람들에게 "스크립트를 사용해서 .wav 파일의 비트 전송률을 확인할 수는 없다"고 말하고 다니게 된 거죠. 그림 2의 코드를 보면 알 수 있듯이, 사실 가능한데도 말이죠.
Figure 2 스크립트를 사용하여 .wav 파일의 비트 전송률 확인 (Close Figure 2)
Set objShell = CreateObject("Shell.Application")

Set objFolder = objShell.NameSpace("C:\Scripts")
Set objFolderItem = objFolder.ParseName("J0388563.wav")

For i = 0 to 33
    strHeader = objFolder.GetDetailsOf(objFolder.Items, i)
    strValue = objFolder.GetDetailsOf(objFolderItem, i)
    If strValue <> "" Then
        Wscript.Echo strHeader & vbTab & strValue
    End If
Next
이 스크립트는 어떻게 작동하는지 살펴봅시다. 여기서도 시작은 첫 번째 스크립트와 동일합니다. 즉, Shell.Application 개체의 인스턴스를 만들고 C:\Scripts 폴더에 바인딩한 다음 ParseName 메서드를 사용하여 원하는 파일(이 예에서는 J0388563.wav)에 바인딩합니다.
지금부터는 다소 복잡합니다. 먼저 0에서 33까지 실행되는 For Next 루프를 설정합니다. 이렇게 설정하는 이유는 파일의 경우 0에서 33 사이의 인덱스 번호가 지정된 확장 속성이 31개까지 지원되기 때문입니다. 단, 27과 28 같은 몇 가지 번호는 유효한 인덱스 번호이기는 하지만 속성 값을 포함하지 않습니다. 파일과 관련해서 지원되는 속성은 그림 3에 나와 있습니다.
Figure 3 파일 속성 (Close Figure 3)

인덱스 | 속성
0 | Name
1 | Size
2 | Type
3 | Date Modified
4 | Date Created
5 | Date Accessed
6 | Attributes
7 | Status
8 | Owner
9 | Author
10 | Title
11 | Subject
12 | Category
13 | Pages
14 | Comments
15 | Copyright
16 | Artist
17 | Album Title
18 | Year
19 | Track Number
20 | Genre
21 | Duration
22 | Bit Rate
23 | Protected
24 | Camera Model
25 | Date Picture Taken
26 | Dimensions
29 | Episode Name
30 | Program Description
32 | Audio Sample Size
33 | Audio Sample Rate
이 For Next 루프는 어떻게 동작할까요? 먼저 다음 코드 줄을 실행합니다.
strHeader = _
  objFolder.GetDetailsOf(objFolder.Items, i)
이 코드 줄은 GetDetailsOf 메서드를 사용하여 속성 0의 이름을 검색합니다. 0에서 33까지 루프가 실행된다는 점을 상기해 보십시오. 그런 다음 검색된 이름을 strHeader라는 변수에 저장하고 다음 코드 줄을 사용하여 항목 0의 속성 값을 검색한 후 반환된 정보를 strValue라는 변수에 저장합니다.
strValue = _
  objFolder.GetDetailsOf(objFolderItem, i)
어떻게 작동하는지 아시겠습니까? 여기서 항목 0은 Name 속성이므로 루프가 처음 실행되면 strHeader의 값이 Name이 됩니다. 반면 첫 번째 파일의 실제 이름, 즉 Name 속성의 값은 J0388563.wav입니다. 따라서 루프를 처음 실행할 때 strValue의 값이 J0388563.wav가 됩니다. 이렇게 설명하니까 별로 복잡하지 않죠?
알고 있겠지만 모든 파일 형식에서 모든 확장 속성이 지원되는 것은 아닙니다. 예를 들어 .jpg 파일에는 Album Title 또는 Audio Sample Rate 속성이 없습니다. 따라서 다음 코드 줄에서 반환된 값이 빈 문자열인지 여부를 확인합니다.
If strValue <> "" Then
값이 빈 문자열이면 루프의 맨 위로 건너뛰고 다음 확장 속성에 대해 프로세스를 반복합니다. 값이 빈 문자열이 아니면 다음과 같이 속성 이름과 값을 출력합니다.
Wscript.Echo strHeader & vbTab & strValue
결과는 어떻게 될까요? 다음과 유사한 결과가 출력됩니다.
Name    j0388563.wav
Size    169 KB
Type    Wave Sound
Date Modified   1/19/2004 8:56 AM
Date Created    3/6/2006 2:02 PM
Date Accessed   12/3/2007 10:41 AM
Attributes      A
Status  Online
Owner   FABRIKAM\kenmyer
Bit Rate        90kbps
Audio Sample Size       4 bit
Audio Sample Rate       11 kHz
훌륭하죠?
시간과 지면이 부족하기는 하지만 가장 관련성이 높은 속성 값을 반환하는 더 쉬운 방법을 찾는 독자를 위해 그림 4의 스크립트를 사용해 보도록 하겠습니다.
Figure 4 속성 값을 반환하는 손쉬운 방법 (Close Figure 4)
Const colInfoTip = -1

Set objShell = CreateObject("Shell.Application")

Set objFolder = objShell.NameSpace("C:\Scripts")
Set objFolderItem = _
  objFolder.ParseName("01. Out On The Weekend (Album Version).wma)")

Wscript.Echo objFolder.GetDetailsOf(objFolderItem, colInfoTip)
이 스크립트는 어떤 작업을 수행할까요? Windows 탐색기에서 파일 위로 마우스 포인터를 이동하면 그림 5의 정보와 같이 파일에 관한 유용한 정보를 제공하는 도구 설명이 나타납니다. 스크립트를 사용하여 도구 설명에 표시할 정보를 얻으려면 어떻게 해야 할까요? 그렇습니다. 방금 설명한 스크립트를 사용하면 됩니다.
그림 5 도구 설명에 표시되는 속성
그림 5 도구 설명에 표시되는 속성
Artist: Neil Young
Album Title: Harvest
Year: 1972
Track Number: 1
Duration: 0:04:35
Type: Windows Media Audio file
Bit Rate: 256kbps
Protected: Yes
Size: 5.31 MB
이번 달에 준비한 내용은 여기까지입니다. 아, 그리고 참새에 대해 한 가지 덧붙이자면, 세계 어떤 곳에서는 집에 참새가 들어오면 불운이 닥친다고 믿습니다. 왜냐고요? 집안의 누군가가 죽는다는 신호이기 때문입니다. 참새가 피아노에 앉는다면 확실합니다. 뭐, 미신이라고 하기에도 너무 이상하지만요. 그런데 다른 곳에서는 집에 참새가 들어오면 집안 식구 중 누군가가 결혼하게 된다고 믿습니다. 흠, 이것 또한 어쩌면 불행이라고 할 수도 있을지 모르겠군요.

Dr. Scripto의 Scripting Perplexer
매달 퍼즐 풀이 실력뿐만 아니라 스크립팅 기술까지 시험해 볼 수 있는 문제입니다.

2008년 3월: 수수께끼의 스크립트
이번 달 퍼즐은 암호입니다. 즉, 각각의 문자가 다른 문자로 대체되어 있습니다. 모든 기호와 숫자는 그대로입니다. 하나의 문자는 항상 대체된 같은 문자를 나타냅니다. 예를 들어 문자 a는 모두 문자 b로 바뀌고 모든 문자 b는 문자 z로 바뀌는 식입니다. 간단한 예를 들어 보겠습니다.
tdsjqu dfoufs
위의 암호는 다음과 같이 해독됩니다.
script center
이 예의 경우 각 문자를 영문자 순서상 바로 앞에 오는 문자로 바꾸어 해독하면 됩니다. 즉, t는 s가 되고 d는 c가 되는 식입니다.
실제 퍼즐은 이보다 좀더 무작위로 암호화되어 있습니다. 이 스크립트를 해독하면 Microsoft Excel®의 인스턴스를 열고, 새 스프레드시트를 추가하고, 스프레드시트의 첫 번째 열에 값을 4개 할당하고, 그 열을 오름차순으로 정렬하는 스크립트를 얻게 됩니다.
자, 이제 퍼즐에 도전해 보십시오.

퍼즐
kqyjs edfjkzyrlyg = 1
kqyjs edyq = 2
kqyjs edjqtstqmj = 2

jzs quwzekzd = ktzfszquwzks("zekzd.faadlkfslqy")
quwzekzd.iljludz = stcz

jzs quwmqtxuqqx = quwzekzd.mqtxuqqxj.frr
jzs quwmqtxjozzs = quwmqtxuqqx.mqtxjozzsj(1)

quwmqtxjozzs.kzddj(1, 1) = "kfs"
quwmqtxjozzs.kzddj(1, 2) = "rqg"
quwmqtxjozzs.kzddj(1, 3) = "ufs"
quwmqtxjozzs.kzddj(1, 4) = "faz"

jzs quwtfygz = quwzekzd.fkslizkzdd.zysltztqm
quwtfygz.jqts quwtfygz, edfjkzyrlyg, , , , , , edyq, , , edjqtstqmj

Dr. Scripto의 Scripting Perplexer
답: 수수께끼의 스크립트, 2008년 3월
스크립트를 해독하는 비결은 다음과 같습니다.
Actual Letter	a	b	c	d	e	f	g	h	i	j	k
Coded Letter	f	u	k	r	z	b	g	o	l	w	x

Actual Letter	l	m	n	o	p	q	r	s	t	u	v	w	x	y	z
Coded Letter	d	n	y	q	a	h	t	j	s	c	i	m	e	v	p
해독된 실제 스크립트는 다음과 같습니다.
Const xlAscending = 1
Const xlNo = 2
Const xlSortRows = 2

Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True

Set objWorkbook = objExcel.Workbooks.Add
Set objWorksheet = objWorkbook.Worksheets(1)

objWorksheet.Cells(1, 1) = "Cat"
objWorksheet.Cells(1, 2) = "Dog"
objWorksheet.Cells(1, 3) = "Bat"
objWorksheet.Cells(1, 4) = "Ape"

Set objRange = objExcel.ActiveCell.EntireRow
objRange.Sort objRange, xlAscending, , , , , , xlNo, , , xlSortRows

Microsoft Scripting GuysScripting Guy는 Microsoft에서 고용되어 일하고 있는 Microsoft의 직원들입니다. 이들은 좋아하는 야구 경기와 기타 여러 활동을 하는 시간을 제외하고는 항상 TechNet 스크립트 센터를 운영합니다. 자세한 내용은 www.scriptingguys.com에서 확인하십시오.


 Security Watch: Windows Server 2008에서 SCW 사용
Security Watch
Windows Server 2008에서 SCW 사용
Jesper M. Johansson
이 문서는 Windows Server 2008 시험판 버전을 기준으로 작성되었습니다. 이 문서에 수록된 모든 정보는 변경될 수 있습니다.

2005년에 Microsoft에서는 Windows Server 2003 SP1을 발표했습니다. 이 서비스 팩에서는 최초의 Windows용 역할 기반 보안 관리 도구인 SCW(보안 구성 마법사)를 소개했습니다. Microsoft에서는 SCW를 최초이자 최고의 보안 취약점 감소 도구로 설계했습니다. 이 도구의 목적은 사용자가 컴퓨터를 통해 실제로
수행한 작업을 분석하여 필요한 해당 역할을 지원하도록 자동으로 컴퓨터를 구성할 뿐만 아니라 사용되지 않는 역할과 서비스는 비활성화하는 것입니다.
SCW는 Windows Server® 2008에서도 제공되지만 새 역할과 새로운 Windows® 방화벽과의 통합을 통해 업데이트되었습니다. 하지만 이전보다 더욱 향상된 고급 관리 기능을 제공합니다.
Windows Server 2008에는 새로운 역할 기반 서버 관리자 도구 및 이와 유사한 역할 추가 및 기능 추가 마법사가 포함되어 있습니다. Windows Server 2008에서는 이전 방식의 Windows 구성 요소 추가/제거 제어판을 통해 개별 구성 요소를 추가하는 대신 역할 관리 도구를 사용하여 서버를 구성합니다. Byron Hynes는 이번 호 TechNet Magazine의 기사 "서버 관리자를 사용하여 역할 구성"에서 이 도구에 대해 설명합니다.
역할 추가 및 기능 추가 마법사는 사용자가 선택한 역할을 지원할 수 있는 적합한 구성 요소로 서버를 구성하도록 설계되었습니다. 또한 이러한 역할이 올바르게 작동할 수 있도록 기본 제공 방화벽도 구성합니다. 그렇다면 SCW가 왜 여전히 필요한지에 대한 궁금증이 생길 수 있습니다. 사실 많은 수의 관리자에게 SCW는 더 이상 필요하지 않습니다. 하지만 SCW가 매우 유용한 도구가 될 수 있는 두 가지 사용자 그룹이 있습니다. 첫 번째 그룹은 보안에 매우 엄격한 사람들입니다. 이러한 사람들은 SCW가 보안을 한 차원 높은 수준으로 끌어올린다고 평가합니다.
역할 추가 및 기능 추가 마법사는 관리자가 원하는 역할과 기능을 안전하게 지원하도록 기본 서버를 구성하는 도구로 생각할 수 있습니다. 반면에 SCW는 관리자가 원하는 역할과 기능만 지원하도록 서버를 구성하는 도구입니다. 또한 SCW에는 서버가 구성되는 방식을 더 자세히 이해하도록 돕는 교육적 효과도 있습니다. 따라서 필자는 역할 및 기능을 통해 서버를 구성한 이후에 SCW를 실행할 것을 강력히 권장합니다.
두 번째 그룹은 다양한 구성 요소 간의 관계를 이해하고자 하는 사용자들입니다. SCW는 역할, 기능, 서비스 및 네트워크 포트 사이의 관계를 문서화하는 XML 파일 집합과 함께 제공됩니다. 다양한 구성 요소에 무엇이 필요한지 파악하는 데 관심이 있다면 SCW는 매우 유용한 도구입니다.
이 칼럼에서는 SCW가 작동하는 방식과 SCW를 사용하여 서버를 보호하는 방법을 설명합니다. 또한 SCW와 서버 관리자 도구를 비교합니다. 이 칼럼은 필자의 책 Windows Server 2008 Security Resource Kit(Microsoft Press®, 2008)를 각색한 것입니다.

보안 구성 마법사 개요
우선 Windows Server 2008의 보안 취약점에 대한 몇 가지 통계를 소개하겠습니다. 사용자가 선택한 역할과 기능을 추가하여 서버를 구성하기 전에도 상당히 많은 수의 서비스가 사용되고 있습니다. 기본적으로 Windows Server 2008에는 105개의 서비스가 있으며, 그 중 42개는 자동 시작으로, 55개는 수동 시작으로, 8개는 사용 안 함으로 설정되어 있습니다. 이와 반대로 Windows Server 2003 R2 SP2를 새로 설치하면 기본적으로 86개의 서비스가 설치되는데, 이 중에서 34개가 자동 시작, 32개가 요청 시 시작, 20개가 사용 안 함으로 설정됩니다.
역할 의미가 사용되고 지원되는 기본 역할의 수가 줄었지만 Windows Server 2008에는 여전히 많은 서비스가 사용되며 서버 보안을 강화하기 위한 추가적인 작업이 필요합니다. SCW는 특정 서버에 적합한 사용자 지정 보안 구성을 만드는 과정에 도움이 됩니다.
SCW는 서버 보안 강화를 위해 기존 도구와는 전혀 다른 방법을 사용합니다. 역할 의미를 사용하여 시스템이 해당 역할만 지원하고 다른 역할은 거의 지원하지 않도록 구성합니다. SCW는 역할 추가 및 기능 추가 마법사처럼 방화벽 구성을 지원하는 동시에 불필요한 서비스를 사용하지 않도록 설정하고 몇 가지 추가적인 보안 설정도 구성합니다. 마지막으로 역할 추가 및 기능 추가 마법사는 Windows에 기본으로 제공되는 역할만 설치하고 구성할 수 있는 반면에 SCW는 확장이 가능합니다. 개발자나 관리자는 사용자 지정 역할 또는 기능 구성 파일을 작성하고 SCW를 사용하여 모든 제품을 구성할 수 있습니다.
SCW는 서버에 필요한 모든 역할과 기능을 설치한 후에 사용하도록 설계되었습니다. 서버에 타사 응용 프로그램도 있는 경우에는 SCW를 실행하기 전에 해당 응용 프로그램도 설치해야 합니다.
필자는 작동 방식을 설명하기 위해 세 가지 역할(응용 프로그램 서버, DNS 서버 및 웹 서버)과 두 가지 기능(Microsoft® .NET Framework 3.0 기능 및 Windows Process Activation Service)으로 서버를 구성했습니다. 논리적인 역할 및 기능 집합은 아니지만 이 칼럼에서 설명하는 내용에는 적합한 예가 됩니다.
SCW를 시작하려면 관리 도구 메뉴에서 실행합니다. 그러면 그림 1과 같은 대화 상자가 표시됩니다.
그림 1 수행할 작업을 묻는 SCW
그림 1 수행할 작업을 묻는 SCW
첫 번째 단계에서는 새 보안 정책을 만들 것인지, 기존 정책을 편집하거나 적용할 것인지, 정책을 롤백하여 시스템을 원래 설정으로 되돌릴 것인지 여부를 선택합니다. 각 항목은 비교적 쉽게 이해할 수 있습니다.
새 보안 정책 만들기를 선택하면 SCW는 일부 컴퓨터를 정책에서 지원해야 하는 항목에 대한 템플릿으로 사용하여 새 정책을 만듭니다. 컴퓨터를 분석하여 컴퓨터에서 지원하는 기능과 역할을 파악함으로써 해당 기능과 역할은 작동하도록 하고 불필요한 기능은 사용되지 않도록 합니다.
SCW는 프로토타입 모델에서 작동하며, XML 파일을 사용하여 설치된 파일, 구성된 서비스 등의 측면에서 역할과 기능의 형태를 지정합니다. 이러한 이유 때문에 정책을 적용할 대상 컴퓨터에는 모든 항목이 설치되어 있어야 합니다. 설치 시 SCW 정의를 설치하는 타사 프로그램이 있는 경우에는 문제 없이 통합됩니다. 하지만 SCW 정의를 설치하지 않는 타사 프로그램은 수동으로 구성해야 합니다.
여기서 볼 수 있듯이 한 시스템에서 정책을 만든 다음 이것을 여러 시스템에 적용할 수 있습니다. 여러 시스템이 있는 네트워크를 구축할 때는 모두 개별적으로 구성된 호스트 클래스를 먼저 정의해야 합니다. 그런 다음 이 중 하나를 프로토타입으로 사용하여 정책을 만들면 정책을 거의 또는 전혀 수정하지 않고 다른 컴퓨터에 쉽게 적용할 수 있습니다.
그림 1의 대화 상자에서 다음을 클릭하면 마법사에는 이 새 정책의 기준 또는 프로토타입으로 사용할 컴퓨터를 묻는 질문이 나타납니다. 대개의 경우 로컬 컴퓨터를 선택하지만 원격 컴퓨터를 프로토타입으로 사용할 수도 있습니다.
사용할 시스템을 지정한 후에는 분석 단계로 넘어갑니다. 이 단계에서 SCW는 설치된 역할과 기능을 열거하고 이를 역할 및 기능 데이터베이스에 일치시킵니다. 데이터베이스에는 각 역할과 기능에 사용되는 서비스에 대한 정보, 필요한 네트워크 포트 및 기타 중요한 구성 정보가 들어 있습니다. 분석이 끝나면 구성 데이터베이스 보기를 클릭하여 보안 구성 마법사에서 찾은 항목을 볼 수 있습니다. 이 보기는 컴퓨터의 구성에 대한 포괄적인 정보를 보여 주는 읽기 전용 보기입니다. 실제로 컴퓨터에 어떤 항목이 있는지 파악하는 데 관심이 있는 경우에는 이 정보를 면밀히 살펴보는 것이 도움이 될 수 있습니다.

SCW로 서버 구성
다음을 클릭하면 SCW의 네 개 섹션 중 첫 번째인 역할 단위 서비스 구성으로 넘어가게 됩니다. 그림 2에서처럼 SCW에서 찾는 역할은 역할 추가 마법사에서 찾는 역할과 같지 않을 수 있습니다. 역할 추가 마법사에서 사용 가능한 역할의 대부분이 여기에도 있지만 SCW는 역할 추가 마법사에는 없는 몇 가지 역할도 제공합니다. 예를 들어 여기에서 선택한 응용 프로그램 서버 역할은 존재하지 않습니다. SCW는 역할에 대해 약간 다른 의미를 사용하기 때문입니다. 이에 대해 좀 더 자세하게 설명하겠습니다.
그림 2 SCW를 사용하여 서버에서 지원할 역할 선택
그림 2 SCW를 사용하여 서버에서 지원할 역할 선택
이 대화 상자에 적절한 역할 집합이 이미 선택되어 있는 경우가 많습니다. 따라서 찾아야 할 것으로 생각한 항목이 분석을 통해 검색되었는지 여부만 확인하십시오. 잘못된 것이 있다면 역할이 설치되었는지 확인하고 누락된 역할을 설치한 후 SCW를 다시 실행하십시오. 실수를 한 경우에도 걱정할 필요는 없습니다. SCW에는 롤백 기능이 있기 때문에 정책으로 인한 모든 변경 사항을 실행 취소하여 처음으로 돌아갈 수 있습니다.
이 섹션에서 선택하는 답변은 네트워크 섹션에 표시될 항목을 결정하기 때문에 매우 중요합니다. 다행이 검색 논리가 상당히 훌륭하여 대개의 경우 올바른 역할 집합이 선택됩니다.
또한 기본적으로 디스크에 저장된 데이터로 서버에서 지원할 수 있는 역할인 설치된 역할이 표시됩니다. 선택된 역할은 현재 지원되는 역할입니다. 데이터베이스의 모든 역할을 표시하도록 선택할 수도 있습니다. 이렇게 하려면 드롭다운 목록에서 모든 역할을 선택합니다. 이는 필요한 모든 역할이 아직 설치되지 않은 프로토타입 서버를 사용하여 정책을 만들어야 할 때 유용합니다.
역할을 구성한 후에는 지원할 클라이언트 기능을 선택합니다. 기능 집합은 기능 추가 마법사의 기능 집합과 비슷하지만 동일하지는 않으며 포함된 기능이 더 적습니다. 마찬가지로 의미가 정확하게 동일하지 않고 SCW는 확장이 가능하기 때문에 표시되는 내용은 기능 추가 마법사와는 다릅니다.
SCW의 클라이언트 기능 페이지에서 다음을 클릭하면 그림 3과 같은 관리 및 기타 옵션 선택 대화 상자가 열립니다. SCW의 옵션은 역할이나 기능에 적합하지 않은 옵션입니다. SCW의 옵션은 관리 지원을 제공하거나 대화형 서비스 감지와 같은 단일 서비스일 수 있습니다. 필요한 옵션의 대부분을 여기에서 선택해야 합니다. 드롭다운 메뉴도 살펴볼 필요가 있습니다. 여기에는 앞서 선택한 역할 및 기능에 관련된 옵션이 들어 있으며 컴퓨터마다 다릅니다.
그림 3 SCW에서 다른 서비스 및 기능 선택
그림 3 SCW에서 다른 서비스 및 기능 선택
다음으로는 추가 서비스 선택 대화 상자가 열립니다. SCW에는 매우 큰 서비스 데이터베이스가 함께 제공되지만 여기에서 모두 설명하지는 않습니다. 데이터베이스에 없는 서비스를 SCW가 컴퓨터에서 찾는 경우 해당 서비스는 추가 서비스 페이지에 표시됩니다. 모든 기본 제공 서비스에 대한 설명이 제공되며 타사 서비스를 설치한 경우가 아니면 이 대화 상자는 나타나지 않습니다.
마법사를 사용하면 현재 구성하지 않은 서비스에 대해 수행할 작업을 선택할 수 있습니다. 이 옵션은 현재 작성 중인 정책을 다른 컴퓨터에 적용할 때 사용하기 위한 것입니다. 사용자가 정책을 만든 서비스와는 다른 서비스가 해당 컴퓨터에 있을 경우 SCW는 이를 어떻게 처리할지 알아야 합니다. 이에 대한 한 가지 방법은 그대로 두는 것입니다. 이것이 기본값입니다. 다른 한 방법은 사용하지 않도록 설정하는 것인데, 이것은 더 안전하지만 문제를 일으킬 수 있습니다. 그러나 정책을 만든 서버와 동일한 서버에만 정책을 적용하는 방법을 따르는 경우 이 페이지에서 선택하는 항목은 문제가 되지 않습니다.
이제 SCW의 역할 구성 부분을 마쳤으며 마법사에는 지금까지의 작업 요약이 표시됩니다. 그림 4에서 볼 수 있듯이 계속 다음만 클릭하더라도 컴퓨터의 보안 취약점에 큰 영향을 미칩니다. 예를 들어 이 컴퓨터는 인쇄 서버가 아니며 프린터가 설치되어 있지 않기 때문에 인쇄 스풀러 서비스를 실행할 이유가 없습니다. SCW는 필요 없는 모든 서비스를 사용하지 않도록 설정합니다. 테스트 서버에서 SCW는 자동 시작으로 설정되었던 서비스 17개를 사용 안 함으로 설정하고 42개의 수동 시작 서비스를 사용하지 않도록 설정했습니다. 물론 사용자 서버가 구성된 방식에 따라 결과는 달라질 수 있지만 SCW를 사용하면 손쉽게 각 서버에 맞게 정책을 사용자 지정할 수 있으므로 보안 취약점을 상당히 줄일 수 있다는 점을 알 수 있습니다.
그림 4 변경한 내용이 요약된 SCW
그림 4 변경한 내용이 요약된 SCW
이제 SCW에서 가장 중요한 부분이라고 할 수 있는 네트워킹 섹션으로 이동합니다. 처음 시작 페이지가 나타난 후 그림 5와 같은 네트워크 보안 규칙 대화 상자가 표시됩니다. 여기에는 이전 섹션에서 사용자가 선택한 역할 지원을 기반으로 하여 SCW가 제안하는 모든 방화벽 규칙이 나열됩니다.
그림 5 사용자에게 필요한 모든 규칙을 나열하는 SCW
그림 5 사용자에게 필요한 모든 규칙을 나열하는 SCW
사용자가 네트워크 섹션에서 추가적인 구성을 설정하지 않으면 SCW는 이러한 역할과 기능만 지원되는 동시에 이에 대한 모든 클라이언트 액세스는 허용되도록 네트워크 인터페이스를 잠그는 방화벽 규칙을 생성합니다. 그러나 서버의 보안을 실제로 최적화하려면 서버 격리 전략 구축에 있어 가장 중요한 부분으로 SCW를 사용해야 합니다. 서버 격리 및 이와 깊게 연관된 도메인 격리에 대한 자세한 내용은 technet.microsoft.com/network/bb545651을 참조하십시오.
Windows Server 2008 Security Resource Kit에는 서버 및 도메인 격리를 통한 네트워크 보안에 대한 내용이 있습니다. 이 책에서는 또한 간편하게 서버 격리를 배포할 수 있도록 네트워크 위협 모델링을 사용하여 네트워크를 분석하는 방법도 설명합니다. 이 프로세스에서 SCW는 매우 유용한 도구입니다.
규칙을 선택하고 편집을 클릭하면 제안된 규칙에 대한 제한 사항을 구성할 수 있습니다. 이렇게 하면 그림 6과 같은 대화 상자가 열립니다. 이 그림은 네트워킹 규칙에 제한 사항을 추가할 수 있는 네 개의 페이지 중 한 페이지입니다. 예를 들어 IPsec 인증을 요구할 수 있습니다. 이 옵션을 선택하면 포트를 특정 끝점에만 연결할 수도 있습니다. 예를 들어 특정 호스트로부터의 원격 관리만 허용되도록 구성할 수 있습니다. 이 기능은 역할 추가 및 기능 추가 마법사에 비해 크게 향상된 것입니다.
그림 6 방화벽 및 IPsec 규칙을 작성할 수 있는 SCW
그림 6 방화벽 및 IPsec 규칙을 작성할 수 있는 SCW
선택한 역할에 따라 연결 보안 규칙을 작성할 수 있는 이 기능에는 두 가지 중요한 목적이 있습니다. 첫째, 서버에서 수행되고 있는 작업을 파악할 수 있는 소중한 학습 기회를 제공합니다. 즉, 서버를 구축할 필요도 없습니다. 마법사를 실행하고 몇 가지 항목을 선택한 후 다음 페이지의 옵션에 어떤 영향이 있는지 살펴보기만 하면 됩니다. 둘째, 매우 추상적인 포트 개념을 더 논리적인 서비스 개념에 연결하고, 정확히 시스템에서 수행되고 있는 실제 작업을 기반으로 네트워크 제한 사항을 구성할 수 있습니다.
올바르게 설정하기만 하면 서버에 대한 매우 엄격한 구성을 만들 수 있습니다. SCW의 네트워킹 섹션은 서버의 보안 정책을 만드는 과정에서 대부분의 시간의 투입해야 하는 매우 중요한 부분입니다.
SCW의 나머지 부분에서는 감사 및 몇 가지 레지스트리 설정을 구성할 수 있습니다. 이러한 매개 변수의 기본 설정은 대부분의 조직에 적합하며, 특별한 요구 사항이 없다면 그다지 변경할 필요가 없습니다.
정책을 만든 후에는 정책을 저장하고 현재 작업 중인 컴퓨터에 적용하거나 다른 컴퓨터에 적용할 수도 있습니다. 또한 scwcmd.exe /transform 명령을 사용하여 정책을 GPO(그룹 정책 개체)로 변환할 수도 있습니다.
하지만 정책에 특정 컴퓨터에 관련된 설정이 있을 때는 정책이 성공하지 못하거나 의도하지 않은 결과가 나타날 수 있습니다. 예를 들어 네트워킹 섹션에서 로컬 어댑터를 포함하는 끝점 제한 사항을 만든 경우 해당 정책은 특정 컴퓨터 관련 정책으로 간주되며 성공적으로 변환되지 않습니다. 그 이유는 GUID를 사용하여 해당 어댑터를 지정해야 한다는 점 때문입니다. 한 컴퓨터의 어댑터에 대한 GUID는 다른 컴퓨터에서는 의미가 없습니다.
따라서 SCW는 서버 단위로 사용할 때와 학습 도구로 사용할 때 더 유용한 경우가 많습니다. 대규모 서버 팜에서는 컴퓨터 정보를 파악하고 기본 정책을 개발하는 하나의 방법으로 SCW를 사용할 수 있습니다. 그런 다음 해당 정책을 기반으로 정책을 다시 만들어 그룹 정책이나 엔터프라이즈 관리 시스템(예: Microsoft Systems Center)과 같이 서버 구성 도구를 사용할 때 적용할 수 있습니다.

SCW와 서버 관리자
지금까지 살펴본 것은 역할과 기능에 사용되는 의미가 서로 다르다는 점입니다. SCW에서 "기능"은 컴퓨터가 클라이언트 역할을 하기 위해 수행하는 것입니다. 반면에 "역할"은 컴퓨터가 서버 역할을 하기 위해 수행하는 것입니다.
즉, 이러한 개념은 역할은 하나의 단위로 생각할 수 있는 서비스 및 기능의 모음이고 기능은 역할을 지원하는 것으로 간주되는 서버 관리자 도구에서의 의미와 다릅니다. 기본적으로 서버 관리자에서는 역할을 서버가 수행해야 하는 것으로 간주합니다. 기능은 중요하기는 하지만 이를 위해 서버가 존재하는 것은 아닙니다. 동일한 용어에 대해 두 가지 의미와 두 가지 서로 다른 용도로 인해 혼동이 유발됩니다. 도구를 전환할 때는 먼저 이에 대해 신중하게 생각해 보아야 합니다.
또한 서버 관리자 도구에는 확장성이 없습니다. 즉, Windows와 함께 제공되는 구성 요소만 관리하도록 설계되었습니다. 이와 반대로 사용자가 설치하는 타사 프로그램에서는 SCW에 역할과 기능을 추가할 수 있습니다. 역할과 기능을 직접 작성할 수도 있습니다. 자세한 내용을 보려면 "보안 구성 마법사 확장" 백서(go.microsoft.com/fwlink/?LinkId=107397)를 참조하십시오.
또한 SCW는 필요 없는 구성 요소를 사용 안 함으로 설정합니다. 반면 서버 관리자 도구는 사용자가 요청한 구성 요소만 배포하며 컴퓨터의 다른 어떠한 항목도 변경하지 않습니다. 필요하지 않을 수 있는 구성 요소를 확인하는 데 도움이 필요한 경우에는 SCW를 사용해야 합니다.
서버 관리자 도구와 SCW 모두가 네트워크 구성에 사용되지만 이 경우에는 SCW가 훨씬 더 강력한 기능을 제공합니다. 서버 격리 전략을 구현할 때 SCW는 유용한 정보를 제공하는 최상의 배포 도구가 될 수 있습니다. 이러한 작업은 분명히 고급 보안 관리 항목에 해당하지만 SCW 역시 고급 보안 도구에 해당합니다.
마지막으로 SCW를 사용하면 서버 관리자 도구로는 할 수 없는 몇 가지 추가적인 보안 설정도 구성할 수 있습니다. 하지만 Windows Server 2008에서는 이러한 설정이 대부분 더 효율적인 컨트롤로 대체되거나 이미 기본으로 설정되어 있습니다.

Jesper M. Johansson은 소프트웨어 보안 문제 분야의 보안 엔지니어이며 TechNet Magazine의 객원 편집자로서, MIS 분야 박사 학위를 취득했고 컴퓨터 보안 분야에서 20년 이상의 경력을 보유하고 있습니다.


 The Desktop Files: 씬 클라이언트 활용
The Desktop Files
씬 클라이언트 활용
Wes Miller

Microsoft 본사 구내에 와본 독자라면 대부분의 건물 로비에 비치된 공용 키오스크 시스템을 보았을 겁니다. 이 시스템은 건물 사이를 바삐 오가는 직원이 전자 메일이나 기타 연결 기능을 이용할 수 있도록 Windows 터미널 서비스에 연결된 웹 기반 프런트 엔드를 사용하여
구축되었습니다. 원래 이들 시스템은 사무실에서 퇴출되어 재활용된 오래된 PC로 설치했었습니다. 이렇게 너무 느리고, 메모리도 부족하고, 하드 드라이브도 충분하지 않아 다른 용도로는 사용할 수 없는 하드웨어가 씬 클라이언트 응용 프로그램으로 가장 적합합니다. 오래된 하드웨어가 있다면 여러분도 회의실의 워크스테이션, 교육용 컴퓨터 등으로 훌륭하게 활용할 수 있습니다. 폐기 처분하는 대신 이렇게 활용한다면 환경 보존에도 도움이 될뿐더러 비용도 절약할 수 있습니다.
Windows Vista® 업그레이드를 계획하고 있는 조직에서는 너무 오래되어 업그레이드가 불가능한 하드웨어가 있을 겁니다. TPM(신뢰할 수 있는 플랫폼 모듈)이나 Aero®가 지원되지 않는 것뿐이고 하드 드라이브와 RAM 용량만 늘리면 문제가 없는 경우 하드웨어를 업그레이드합니다. 그러나 하드웨어의 성능이 너무 떨어지거나 핵심 기능이 부족하여 Windows Vista 실행이 아예 불가능한 시스템도 있기 마련입니다. 이런 하드웨어가 Windows® 씬 클라이언트를 실행하기에 이상적입니다. 그림 1에 나와 있는 Windows Vista 하드웨어 요구 사항을 참조하면 현재 하드웨어가 어느 정도 적합한지 확인할 수 있습니다.
Figure 1 Windows Vista 하드웨어 요구 사항 (Close Figure 1)

하드웨어 | 요구 사항
CPU | 1GHz 이상 권장. CPU 속도는 Windows Vista의 유용성을 결정할 수 있는 중요한 요소입니다. 느린 단일 코어 CPU는 이 기준에는 맞지 않겠지만 씬 클라이언트에는 적합할 수 있습니다. x64로의 전환을 염두에 두고 있다면 Windows Vista 하드웨어로 교체되는 시점이 전반적인 하드웨어 교체를 통해 x64 환경으로 전환할 수 있는 적기입니다.
메모리 | 1GB 이상 권장. 메모리를 시스템에 추가함으로써 문제를 해결할 수 있는 경우도 많지만 수십, 수백, 수천 대의 시스템에 메모리를 설치하는 것이 과연 경제적인지 잘 생각해 보아야 합니다.
GPU | 128MB 이상의 그래픽 메모리, WDDM 드라이버가 있는 DirectX® 9.0 지원 장치, Pixel Shader 2.0 지원. 이 요구 사항은 대개 Aero 지원만 제한할 뿐이므로 크게 영향을 미치지 않습니다.
HDD | 40GB 이상의 하드 디스크. 대개 데스크톱보다 모바일 시스템에서 문제가 됩니다.
드라이버 문제 | 시스템의 모든 하드웨어에 대해 Windows Vista 드라이버가 제공되는지 여부
TPM | USB 플래시 드라이브 없이 BitLocker 지원을 활용하려면 컴퓨터에 TPM 1.2 하드웨어가 필요합니다.

씬 클라이언트의 용도
오래된 하드웨어와 축소된 운영 체제를 사용하면 Microsoft 사무실에서처럼 사용자가 전자 메일을 확인할 수 있는 공용/접수 키오스크를 만들 수 있습니다. 원격 데스크톱이나 면밀하게 관리되는 Internet Explorer® 인스턴스를 실행하도록 시스템을 설정할 수도 있습니다. Microsoft PowerPoint®와 원격 데스크톱 그리고 다른 소소한 도구 몇 가지만 실행하면 회의실에 프레젠테이션 재생 시스템으로 설치할 수도 있습니다. 또한 오래된 하드웨어와 씬 클라이언트를 판매 시스템이나 구직 키오스크로 사용하는 것도 가능합니다. 그렇다면 어떤 씬 클라이언트를 사용해야 할까요?

Windows XP Embedded
이전 칼럼에서 Windows XP Embedded가 유연하고 구성 요소화된 Windows XP 버전으로 개발되었다는 점에 대해 설명한 바 있습니다. 2007년 4월호에 실린 Don Jones의 기사(technetmagazine.com/issues/2007/04/XPe 참조)에 설명되어 있듯이 Windows XP Embedded 이미지를 만드는 데 사용할 수 있는 도구는 몇 가지가 있습니다. 그리고 그 중에서도 Target Designer가 가장 많이 사용됩니다(그림 2 참조). Target Designer를 사용하면 사용자 지정 Windows XP Embedded 이미지를 직접 만들 수 있습니다.
그림 2 Windows XP Embedded Target Designer 이미지
그림 2 Windows XP Embedded Target Designer 이미지
Target Designer에는 작업을 시작하는 데 도움이 되는 몇 가지 디자인 템플릿이 포함되어 있습니다. 물론 처음부터 직접 디자인할 수도 있지만 템플릿을 사용하면 작업이 훨씬 쉽습니다. 그림 2에 나와 있는 키오스크/게임 콘솔 및 Windows 기반 터미널 템플릿은 작업을 시작하는 데 좋은 참고 자료가 됩니다. Windows XP Embedded는 정식 버전의 운영 체제 이미지와 마찬가지로 완벽한 장치 지원과 기본 전원 관리 기능도 제공합니다. 이미지에 해당 지원 기능만 구축하면 사용할 수 있습니다. 물론 기능을 많이 추가할수록 필요한 하드웨어 요구 사항도 늘어나므로 신중하게 선택해야 합니다. Windows XP Embedded에 대한 정보는 Microsoft 웹 사이트, microsoft.com/windows/embedded/eval/xpe/default.mspx를 참조하십시오.

Windows Embedded for Point of Service
Windows Embedded for Point of Service(WEPOS)는 Windows XP Embedded를 기반으로 구축된 POS(Point-of-Service) 시스템에 사용할 수 있는 완전히 표준화된 템플릿을 제공합니다. WEPOS는 수많은 POS 관련 주변 장치를 기본적으로 지원하며 주로 상업용이나 숙박업소용으로 사용되도록 개발되었습니다. Windows XP Embedded와는 달리 WEPOS는 이 용도에 맞게 설계된 매우 한정된 기능 집합만 제공하며 Windows XP Embedded와 동일한 수준으로 사용자 지정할 수 없습니다.
WEPOS 플랫폼은 233MHz Pentium II 이상의 프로세서, 64MB의 RAM만 필요하고 핵심 운영 체제 이미지 크기가 280MB밖에 되지 않도록 최소한의 시스템으로 설계되었습니다. WEPOS에 대한 자세한 내용과 평가판 주문 링크는 microsoft.com/windows/embedded/wepos를 참조하십시오.

Windows Fundamentals for Legacy PC
주로 장치 제조업체에서 장치와 함께 제공할 수 있도록 설계된 Windows XP Embedded나 WEPOS와는 다르게 Windows Fundamentals for Legacy PC(FLP)는 Software Assurance의 구성 요소 중 하나로 라이선스가 부여되고 이러한 시나리오에 맞도록 설계되었습니다. 그림 3은 사용자가 선택할 수 있도록 Minimum(최소), Typical(일반), Full(전체) 및 Custom(사용자 지정)의 네 가지 구성 옵션을 제공하는 Windows FLP 설치 화면을 보여 줍니다.
그림 3 Windows FLP 설치
그림 3 Windows FLP 설치
Windows FLP를 실행하려면 64MB의 RAM, 500MB 이상의 하드 드라이브 공간 및 800x600 이상의 디스플레이 해상도가 요구됩니다. 시스템에 필요한 실제 하드 드라이브 공간은 설치하는 OS 구성 요소에 따라 달라질 수 있습니다.
레거시 하드웨어에 사용할 상대적으로 유연한 최소 운영 체제가 필요하고 Software Assurance를 이미 보유하고 있다면 Windows FLP를 선택하는 것이 좋습니다. Windows FLP를 통해 최신 하드웨어와 운영 체제로 원활하게 마이그레이션하는 방법에 대한 자세한 내용은 microsoft.com/licensing/sa/benefits/fundamentals.mspx를 참조하십시오.

효율적인 Windows XP
이러한 최소 버전 외에 Windows XP 자체가 훌륭한 대안이 될 수 있습니다. RAM 용량이 부족하다면 Windows 테마 등의 서비스를 사용하지 않음으로써 시스템이 원활히 작동하도록 오버헤드를 줄일 수 있습니다. 그러나 서비스 해제 기능에 대해 정확하게 알아야 하며 Windows 방화벽을 해제하는 것과 같이 보안에 영향을 주는 설정의 해제는 피해야 합니다.

바람직하지 않은 방법
안타깝게도 여러 가지 다른 편법으로 경량 시스템에서 Windows를 사용하려고 하는 사람을 종종 볼 수 있습니다. 지금부터 가장 대표적인 사례를 소개하고 왜 예상한 결과를 얻을 수 없는지에 대해 구체적으로 설명하겠습니다.
Windows XP Starter Edition은 리소스가 한정된 시스템에서 사용할 수 있는 효율적인 버전이지만, 주로 기술 개발 분야에서 사용되도록 설계되었고 해당 시장에서는 OEM에서 새 PC에 포함하여 제공하는 Windows의 형태로만 라이선스가 부여됩니다. 따라서 대개는 대안이 될 수 없습니다. 자세한 내용은 microsoft.com/presspass/newsroom/winxp/WinXPStarterFS.mspx를 참조하십시오.
마찬가지로, Windows PE도 바람직한 대안이 아닙니다. 개발 시에 Microsoft는 원래 Windows PE를 경량 OS로 간주했습니다. 그러나 결국 경량 OS가 아니라 배포에 중점을 두고 최소화된 사전 설치 환경으로 사용하도록 설계되었습니다. 예를 들어 Windows PE에는 명령 프롬프트를 제외한 다른 셸이 없고 유용한 셸을 쉽게 추가할 수도 없을 뿐더러, 정의된 API 집합, 전원 관리 기능, 오디오 지원 기능도 없습니다.
여러 계층으로 이루어진 Windows XP 버전도 바람직한 솔루션이 아닙니다. 필자는 Windows를 간소화하는 것이 효과적이라는 이야기를 종종 들었습니다. 단순히 서비스를 해제하거나 비활성화하는 것이 아니라, 경량화된 Windows 설치를 위해 실제로 응용 프로그램을 제거하는 것입니다. 이는 매우 위험한 발상입니다. Windows를 간소화하기 위해 바이너리를 제거하면 시스템이 불안정하거나 안전하지 않은 상태가 될 수 있습니다. 축소된 버전의 Windows가 필요하다면 Windows XP Embedded를 사용해 보십시오. 기능을 익히는 데 다소 시간과 노력이 필요하고 완벽한 이미지를 얻는 데에도 시간이 걸리겠지만, 성능이 강력할 뿐만 아니라 무엇보다 Microsoft에서 공식적으로 지원하는 운영 체제입니다.
최소화된 버전의 Windows XP와 마찬가지로 이전 버전의 Windows도 괜찮을 것 같지만 지원, 업데이트 및 보안이 불충분하기 때문에 바람직하지 않습니다. Microsoft에서 경량화된 컴퓨팅 환경에 대한 요구 사항을 해결하기 위해 지원하고 있는 솔루션을 선택하여 필요한 기능이나 보안에 영향을 주지 않으면서 오래된 하드웨어를 활용하시기 바랍니다.

Wes Miller는 텍사스주 오스틴에 위치한 CoreTrace(www.CoreTrace.com)에서 기술 제품 수석 관리자로 일하고 있습니다. 이전에는 Winternals Software에서 Microsoft 프로그램 관리자로 근무했습니다. 문의 사항이 있으신 분은 technet@getwired.com으로 연락하시기 바랍니다.


 Field Notes: IT 2.0 준비
Field Notes
IT 2.0 준비
Romi Mahajan

미국의 철학자이자 평론가인 조지 산타야나(George Santayana)는 그의 저서 이성의 삶(The Life of Reason)에서 "과거를 기억하지 못하는 자는 같은 실수를 반복하는 운명에 놓인다"면서 보다 나은 앞날을 적극적으로 개척하기 위해서는 과거의 실수를 깊이 되새기는 것이 무엇보다 중요함을 강조했습니다. 그의 이러한 사상은 정치, 문화, 역사, 심지어는 과학에까지 분명히 적용됩니다. 사실 "실수에서 배운다"는 생각은 너무 상투적인 문구로 들리기도 합니다. 그러나 IT 분야에서 우리는 과연 얼마나 열심히 과거를 돌아보며 교훈을 얻고 있을까요? 만약 그렇지 못하다면 앞으로의 IT 환경에 대비는 하고 있는 것일까요? 그리고 IT의 미래는 도대체 어떤 모습일까요?
우리 모두 기억을 되살려 한번 생각해 봅시다. 지난 30년 동안 IT 환경에는 엄청난 변화가 있었습니다. 즉, 대규모 메인프레임에서 브라우저 기반의 컴퓨팅으로, 장치 집중에서 장치 분산으로, 미완성 및 희귀성에서 고도의 전문화 및 일반성으로, 상대적 단순함에서 엄청난 복잡성으로 발전해 왔습니다. 따라서 이와 같은 사실로 추정할 때 IT는 앞으로 더욱 복잡해지고 전문화 및 일반화될 것으로 예상됩니다. 또한 IT는 점점 늘어나고 다양해지는 장치와 플랫폼을 지원할 수 있어야 합니다. 이 모든 것에 대처하기 위해서는 그 어느 때보다 치밀한 계획이 필요합니다.
그런데 이런 개념이 조직 내부에 보편화되어 있을까요? 전혀 그렇지 않습니다.
2007년 11월 기술 컨퍼런스에서 필자가 "소비자 주도의 IT(Consumerization of IT)"에 대해 주도한 공개 토론회의 대화를 예로 들어 봅시다. 이 토론의 전제는 간단했습니다. 기업 기술과 소비자 기술 간의 경계가 모호해졌다는 것입니다. 즉, 소비자 응용 프로그램과 장치가 IT 개발을 주도하고 있으며, IT 부서는 전 세계 Facebook, iTune, BlackBerry 등이 대표하는 일련의 현상에 대비를 해야 한다는 것입니다. 간단하고 명확한가요? 또는 진부한가요?
당시 토론회 참석자들의 반응을 보면 전혀 그렇지 않았습니다. 약 100명 중 4명만이 "Facebook"을 사용한다고 말했습니다. 한 참석자는 "그건 젊은이들이나 하지 않냐"고 하더군요. 그러자 저희 패널 중 한 명이 "여러분 회사의 IT 부서가 지원하는 직원들은 대부분 젊고 Facebook을 사용하지 않나요?"라고 반문했죠. 혼란과 부정의 말들이 오고 갔습니다. 당시 참석했던 IT 관리자 중 현재 널리 사용되는 기술이 반영된 새로운 플랫폼에서 응용 프로그램과 장치를 구축 및 지원할 수 있는 인력을 고용하여 조직을 강화해야 한다는 필요성을 인식하는 사람은 극히 소수뿐이었습니다.
가정과 직장 모두에서 사용할 수 있는 휴대폰 및 랩톱 같은 교차 기술의 사용 및 보안과 관련한 효과적인 IT 정책을 구축하는 방법을 물었을 때는 좌중이 떠들썩했지만 실질적인 방안을 제시하는 의견은 거의 없었습니다. 마침내 어떤 한 사람이 "우리 사무실의 누군가가 회사 랩톱에 MP3 플레이어를 연결하거나 업무용 휴대폰을 실수로 술집에 놓고 오거나 하면 난 당장 해고하겠다"고 IT 1.0 세대에나 흔했던 엄한 분위기로 말하자 많은 참석자들은 공감을 나타냈습니다.
예, 뜻대로 하시지요...
이렇게 아이디어가 고갈된 또 다른 영역은 그나마 많지도 않은 IT 지도자 컨퍼런스입니다. "IT 비즈니스 제휴"나 "일반적인 성과 관리" 등과 같이 모호한 개념을 주제로 하는 또 다른 컨퍼런스 일정을 보게 된다면 필자는 더 이상 참석하지 않을까 합니다. 왜 좀 더 많은 사람들이 IT 2.0이나 앞으로 혁신을 위해 필요한 것들에 대해 궁금해하지 않는 걸까요? 역동적인 미래를 열어가기 위해 새로운 세대의 IT 전문가들이 어떤 기술과 태도를 갖추어야 하는지는 왜 묻지 않는 걸까요? 혁신적인 기업이 R&D 부서를 대하는 것처럼 IT 부서를 대우하는 회사는 단 하나도 없다는 사실이 어째서 슬프지 않은 것입니까? 중앙 집중화와 분산화를 비교하며 논쟁하는 대신 이제 IT 독재주의와 IT 민주화에 대한 실질적 문제를 다룰 때가 된 것은 아닐까요?
우리는 우리의 미래를 생각하고 대비함으로써 자신을 사랑할 줄 알아야 합니다. Web 2.0에 대해서는 많이 들어왔습니다. 이제 기술 잠재력과 조금이라도 비슷한 무언가를 이루기 위해서는 IT 2.0에 대해 진지하게 생각해야 할 때입니다.

Romi Mahajan은 Microsoft 기술 사용자 및 플랫폼 마케팅 팀의 이사로, 정치, 환경, 기술, 사회학 등 다양한 분야에서 폭넓은 저술 활동을 펼쳐 왔습니다.


 Windows Confidential: 베타에서 RC로
Windows Confidential
베타에서 RC로
Raymond Chen

예전에는 Windows® 개발 시에 제품의 시험판 버전이 매우 정형화된 과정을 거쳤습니다. 먼저, 내부적으로 사용되고 경우에 따라 Windows 제품 팀 외부의 소프트웨어 개발 파트너와 공유되는 알파 릴리스가 만들어집니다.
알파 릴리스 다음에는 여러분도 알다시피 좀더 폭넓은 대중에게 공개되는 베타 릴리스가 만들어집니다. 알파 릴리스 사용자와 베타 릴리스 사용자의 두드러진 차이점은 베타 릴리스의 경우 소프트웨어 개발자 외에도 시험판 소프트웨어를 테스트해보고자 하는 최종 사용자와 새 OS를 미리 평가하여 새 제품이 중요한 사내 응용 프로그램은 물론, 회사 네트워크, 표준 하드웨어 구성, 시스템 관리 도구 등과도 잘 호환되는지 확인하려는 기업이 포함된다는 점입니다.
마지막으로, 릴리스 후보가 만들어집니다. 이름에서 알 수 있듯이 릴리스 후보는 최종 릴리스 후보로 결정된 코드 버전입니다. 다시 말해 "문제가 없다면 이 버전을 출시하겠다"는 의미죠. 이러한 기대를 저버릴만큼 심각한 버그가 발견되면 버그가 수정된 후에 바로 새 릴리스 후보 빌드가 만들어지고 테스트 주기가 다시 시작됩니다. Windows 95의 경우 여섯 번째 릴리스 후보가 최종 제품으로 출시되었습니다.
같은 팀의 동료들 말로는 Windows NT®의 경우 동일한 릴리스 명명 패턴을 따랐지만 문제가 발생했다고 합니다. 테스트에 참여한 기업들이 Windows NT 베타 릴리스에서 업무에 사용 중인 중요 응용 프로그램을 테스트하지 않은 것입니다. 일반적으로 "베타 버전일 뿐인데 굳이 그렇게까지 테스트할 필요가 있겠어. 베타 버전은 제품의 열렬한 지지자들을 위한 것일 뿐이야. 어차피 최종 버전에서는 달라질텐데, 뭐. 지금 테스트를 해봐야 시간 낭비일 뿐이야"라는 논리가 그 이면에 깔려 있습니다.
마찬가지로, 소프트웨어 업체들도 Windows NT의 베타 테스트 기간 중에 발견된 문제에 신경 쓰지 않았습니다. "베타 운영 체제는 지원하지 않는다"는 것이죠.
이러한 회사들은 실제 릴리스 후보 빌드가 발표된 후에야 비로소 진지하게 테스트에 임하고 결국 많은 문제를 찾아냅니다. 그 중에는 해당 회사에서 자체적으로 해결하지 못하는 문제나 Windows NT 이전 버전과의 호환성에 영향을 줄 정도로 복잡한 문제도 있었습니다. 단기간에 수정이 가능한 특정 프로젝트 기능의 작동 방식과 관련한 사소한 문제도 있었지만, 문제 해결을 위해 제품 출시를 연기해야 할만큼 심각한 문제도 있었습니다.
릴리스 후보 빌드가 발표되자 여러 가지 제안도 쏟아져 들어왔습니다. "단추를 이렇게 배치하면 UI가 좀 더 나아지겠다"거나 "이 메시지는 사용자에게 혼동을 주지 않도록 고쳤으면 좋겠다"는 등의 의견이 있었습니다. 베타 단계에 접수되었다면 큰 도움이 되었을 테지만, 첫 번째 릴리스 후보가 배포된 시점에서 이러한 제안에 따라 인터페이스 설계를 변경하는 것은 무리였습니다. 설명서와 도움말 파일이 이미 작성된 상태였고, 수십 개 언어로 제품 번역도 마쳤고, 매뉴얼과 제품 포장에 사용할 스크린샷의 레이아웃, 조정, 분판, 인쇄 작업도 이미 끝나 있었습니다. 단추 하나를 옮기기 위해서 이러한 모든 작업 결과물을 버릴 수는 없으니까요.
Windows XP 시절에 이러한 뒤늦은 변경과 관련하여 논쟁이 벌어졌던 회의가 있었습니다. 제안된 변경 사항을 적용하려면 설명이 새 UI에 맞도록 20KB의 도움말 파일을 변경해야 했습니다. 지역화 및 번역 담당자들은 매우 촉박한 기한 내에 수정된 도움말 파일을 재번역하는 데에는 막대한 비용이 따른다는 사실을 강조했습니다.
Windows NT 팀은 베타 테스트를 경시하는 풍토에 대항하기 위해 각 버전의 등급을 과장되게 나타내는 방법을 이용했습니다. 즉, 여전히 베타 릴리스가 있기는 하지만, 많지는 않더라도 아직 조정할 시간이 있을 때 발표되는 후반의 베타 릴리스가 릴리스 후보가 되고 예전의 릴리스 후보는 조건부 빌드가 되었습니다. 조건부라는 용어는 "제품 개발이 끝났고 정말 긴급한 상황이 발생하지 않는 한 변경하지 않겠다"는 빌드 상태를 제대로 전달하는 데 효과적이었습니다.

Raymond Chen은 The Old New Thing 웹 사이트와 동명의 저서(Addison-Wesley, 2007)에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있습니다. Raymond는 사무실에서 자기 집이 보인다고 말하곤 합니다.