 TechNet Magazine January 2008

TechNet Magazine January 2008

System Center: Virtual Machine Manager 2007을 사용한 강력한 제어

가상화를 통해 조직은 리소스를 통합하고 비용을 절감할 수 있습니다. 그러나 구현하는 가상 컴퓨터의 수가 많아지면 이를 보다 간편하게 관리할 수 있는 방법을 찾게 됩니다. 이 문서에서는 중앙 집중화된 인터페이스에서 관리 작업을 수행할 수 있도록 Virtual Machine Manager를 설정하고 사용하는 방법을 설명합니다.

Edwin Yuen System Center: Data Protection Manager 2007을 사용한 향상된 백업

최신 버전의 Data Protection Manager에서는 많은 새로운 기능을 통해 백업 관리를 위한 강력하고 융통성 있는 솔루션을 제공합니다. 이 문서에서는 DPM을 사용하여 Exchange와 SQL Server에서부터 지점 사이트와 SharePoint 사이트에 이르는 조직의 모든 구성 요소를 보호하는 방법에 대해 설명합니다.

Calvin Keaton System Center: 소프트웨어 자산을 간단히 관리해 주는 온라인 서비스

소프트웨어 자산 관리는 규모에 관계없이 모든 기업에 필수적인 업무입니다. 그러나 현재 기업에서 구입, 배포하는 소프트웨어의 양으로 볼 때 이를 효과적으로 관리하는 것은 거의 불가능에 가까운 일처럼 느껴질 수 있습니다. Microsoft가 제공하는 새로운 AIS(Asset Inventory Service)가 여기에 어떻게 도움이 되는지 확인해 보시기 바랍니다.

Paul Bourgeau Group Policy: 그룹 정책용 ADM 및 ADMX 템플릿 살펴보기

ADM 파일은 필수적으로 사용해야 하는 파일이지만 혼란스러울 때도 많습니다. 그렇다고 그룹 정책에 대한 노력을 멈출 수는 없습니다. 이 문서에서는 ADM 파일을 자세히 살펴보고 이를 처리하는 데 사용할 수 있는 새로운 ADMX 형식 및 이 파일을 최대한 활용하는 방법을 안내합니다.

Jeremy Moskowitz Group Policy: 그룹 정책 성능 최적화

모든 그룹 정책은 동일하지 않으므로 각 유형 간의 차이점을 알면 시스템의 성능을 세부적으로 조정하는 데 도움이 됩니다. 여기서는 모놀리식 GP와 기능적 GP에 대해 살펴보고, 그룹 정책을 처리하는 방법 및 그룹 정책을 변경할 때 나타나는 현상에 대해 알아봅니다.

Darren Mar-Elia Group Policy: 고급 그룹 정책 관리에 대해 자세히 알아보기

AGPM(고급 그룹 정책 관리)은 다른 도구로는 수행할 수 없는 방법으로 그룹 정책 개체 작업을 할 수 있는 편리한 도구입니다. 이 도구는 현재 Microsoft Software Assurance 프로그램 회원에게만 제공됩니다. AGPM을 사용하여 오프라인으로 GPO 편집, 관리 권한 위임, 변경 추적 등의 작업을 수행할 수 있는 방법에 대해 살펴보시기 바랍니다.

Derek Melber From the Editor: 딴지꾼의 공감 얻기

Joshua Hoffman Letters: 독자의 목소리

Exchange Queue & A: 음성 안내 추가, PBX 선택 및 기타 정보

Exchange 통합 메시징에 관하여 궁금하신 점이 있으신가요? 저희가 그에 대한 답을 드리지요. 이번 Exchange Queue & A 칼럼에서는 통합 메시징에 중점을 두어 전화 및 팩스 기능 구현, 고가용성 제공 및 음성 안내 설정 등을 수행하는 방법을 다룹니다.

Seema Rahman The Cable Guy: Windows Server 2008의 DNS 기능 향상

Windows Server 2008에서는 DNS 서버의 많은 기능이 향상되었습니다. 이 문서에서는 신속한 이름 확인, IPv6 지원 향상, 더 유연해진 DNS 관리 기능 등 개선된 DNS 서버의 기능에 대해 자세히 살펴봅니다.

Joseph Davies Windows PowerShell: 악성 코드 차단

Windows PowerShell은 보안을 최대한 고려하여 설계되었습니다. 그러나 여느 소프트웨어와 마찬가지로 Windows PowerShell도 악성 코드에 노출될 수 있습니다. 이 기사를 통해 시스템을 보다 안전하게 유지할 수 있는 실행 정책을 선택하기 위한 몇 가지 권장 방법에 대해 알아보겠습니다.

Don Jones Hey, Scripting Guy!: 정규식 유효성 검사

실수를 피할 방법을 찾는다면 우선 유효성 검사가 좋은 방법이 될 수 있습니다. 지금부터 정규식을 사용하여 스크립트에서 문자 패턴을 검사하는 방법에 대해 알아보겠습니다.

The Microsoft Scripting Guys Security Watch: 아일랜드 하핑: 미끼를 활용하는 침투 방식

보안 위협이 전자 메일과 악의적 웹사이트에만 존재하는 것은 아닙니다. 여기에서는 USB 드라이브와 간단한 사회 공학적 침투 수법만으로도 네트워크 전체에 접근할 수 있다는 사실을 설명합니다. 또한, 이러한 위협에 대응하여 네트워크를 더욱 안전하게 보호할 수 있는 방법을 소개합니다.

Jesper M. Johansson The Desktop Files: Windows SteadyState를 사용한 공유 컴퓨팅

새로운 Windows SteadyState 도구 키트는 공유 환경에서 사용되는 Windows XP 시스템의 보안을 강화하고 관리 업무를 간소화하는 데 얼마나 도움이 될까요? Wes Miller와 함께 확인해 보시기 바랍니다.

Wes Miller Field Notes: 하루 중 가장 중요한 작업

프로젝트를 진행할 때 미리 생각하고 계획하며 우선 순위를 정하는 데 시간을 할애하는 것의 중요성을 과소평가해서는 안 됩니다.

Eric N. Bush


 System Center: Virtual Machine Manager 2007을 사용한 강력한 제어
System Center Edwin Yuen

Virtual Machine Manager 2007을 사용한 강력한 제어
한 눈에 보기:
  • System Center Virtual Machine Manager 2007의 주요 기능
  • VMM 설치 방법
  • 물리적 컴퓨터 또는 가상 컴퓨터를 VM으로 변환

System Center Virtual Machine Manager 2007은 조직 전체의 가상 인프라를 관리하기 위한 통합된 인터페이스를 제공하는 새로운 솔루션입니다. Virtual Machine Manager(VMM)를 사용하면
기존에 설치된 Microsoft® Virtual Server 2005를 관리하거나 새 VM(가상 컴퓨터) 호스트에 Virtual Server 2005 R2 SP1을 설치할 수 있습니다. 또한 VMM을 사용하면 중앙 집중화된 인터페이스를 통해 여러 Virtual Server 설치에 대한 관리 권한을 가지고 기존의 Virtual Server 2005 관리 작업을 훨씬 효율적으로 수행할 수 있습니다.
뿐만 아니라 VMM은 P2V(물리적 컴퓨터를 가상 컴퓨터로 변환), VMware VMDK(Virtual Machine Disk) 형식 디스크가 있는 경우 이를 Virtual Server VHD(가상 하드 디스크)로 변환하는 V2V(가상 컴퓨터 간 변환), 중앙 집중식 가상 인프라 개체 라이브러리를 통해 템플릿 및 미리 구성된 VHD를 기반으로 신속하게 VM을 배포하는 등의 새로운 기능을 Virtual Server에 제공합니다.
이어지는 페이지에서는 VMM에 대해 알아보고 VMM이 IT 관리자에게 제공하는 강력한 기능 집합을 살펴보겠습니다. 그런 다음 VMM 설치를 만들기 위한 요구 사항 및 단계를 설명하고, 마지막으로 VMM의 보다 흥미로운 몇 가지 기능에 대해 자세히 알아본 후 VMM을 시작하는 데 도움이 되는 몇 가지 팁을 제시하는 것으로 마무리하겠습니다.

Virtual Machine Manager 2007 소개
System Center Virtual Machine Manager 2007은 Microsoft Virtual Server 2005에서 실행되는 가상 컴퓨터를 위한 중앙 집중화된 엔터프라이즈급 관리 기능을 제공하는 독립 실행형 응용 프로그램입니다. System Center 제품군을 구성하는 제품 중 하나인 Virtual Machine Manager는 다른 System Center 제품과 통합되어 완벽한 물리적 인프라 및 가상 인프라 관리 기능을 제공합니다. 그림 1은 Virtual Machine Manager의 다양한 구성 요소 및 VMM과 Virtual Server 호스트 간의 관계를 보여 줍니다.
왼쪽 상자는 VMM 서버를 나타내고 오른쪽 상자는 가상 컴퓨터 호스트를 나타냅니다. 필요한 경우 VMM 구성 요소를 별도의 서버에 설치하여 성능과 확장성을 높일 수 있습니다. 이 문서에서는 코어 VMM 구성 요소가 모두 한 컴퓨터에 설치되어 있는 그림 1의 모델을 사용합니다. 왼쪽의 가운데를 보면 VMM 제품의 핵심인 Virtual Machine Manager 서비스가 있습니다. 그 위에는 이 서비스의 세 가지 인터페이스인 Windows PowerShellTM 인터페이스, 관리자 콘솔, 위임된 프로비전 관리 기능을 제공하는 셀프 서비스 포털이 있습니다. 그리고 Microsoft SQL Server® 2005 데이터베이스(SQL Server는 SQL Server 전체 설치나 SQL Server 2005 Express Edition 중 하나 사용)와 가상 인프라 구성 요소에 사용되는 파일 공유인 중앙 집중화된 라이브러리가 VMM을 지원합니다.
그림 1 System Center Virtual Machine Manager 2007 아키텍처
그림 1 System Center Virtual Machine Manager 2007 아키텍처
그림 1의 오른쪽은 VMM이 관리하는 Virtual Server 2005 R2 가상 컴퓨터 호스트를 나타냅니다. 맨 아래에는 호스트 운영 체제가 있으며 여기서는 Windows Server® 2003 R2입니다. VMM은 VMM과 Virtual Server 2005 R2 간의 원활한 통신을 위해 가상 컴퓨터 호스트에 에이전트를 설치합니다. 이 에이전트는 물리적 호스트에 하나만 설치되며 VM이나 게스트 OS에는 설치되지 않습니다. 호스트 컴퓨터에 Virtual Server가 설치되어 있지 않으면 관리되는 서버 목록에 호스트가 추가될 때 VMM에서 자동으로 설치를 수행할 수 있습니다.
System Center 제품군의 일부로서 Virtual Machine Manager의 관리자 콘솔에는 기존의 MMC 스냅인과는 다른 새로운 System Center(또는 Outlook® 스타일) 인터페이스가 사용됩니다. VMM 관리자 콘솔(그림 2 참조)은 Microsoft .NET Framework 2.0을 사용하여 Windows PowerShell 1.0에 기반을 두고 개발되었습니다. 실제로 관리자 콘솔에서 작업을 실행하면 연결된 Windows PowerShell 명령이 호출됩니다. 따라서 관리자 콘솔에서 호출하는 명령이나 함수는 Windows PowerShell의 명령줄을 통해서도 직접 호출할 수 있습니다.
그림 2 관리되는 가상 컴퓨터를 보여 주는 VMM 관리 UI
그림 2 관리되는 가상 컴퓨터를 보여 주는 VMM 관리 UI
또한 Administrator Console(관리자 콘솔)의 각 마법사에는 실행하려는 명령에 연결된 Windows PowerShell 스크립트를 표시하는 스크립트 보기 단추도 있습니다. 스크립트를 보면 Windows PowerShell과 VMM이 어떻게 연동되는지 쉽게 이해할 수 있습니다. VMM에서 Windows PowerShell 사용에 익숙해지면 VMM을 통해 대량 작업을 스크립트로 작성할 수 있습니다.
Virtual Machine Manager는 IT 관리자에게 세 가지 혜택을 제공하도록, 즉 리소스를 최대한 활용하고, 유연함을 향상시키고, 기존 기술을 활용할 수 있도록 설계되었습니다. VMM은 여러 가지 기능을 통해 이러한 혜택을 제공합니다. 첫째, VMM은 물리적 서버를 가상 컴퓨터로 변환하는 방법으로 리소스를 최대한 활용할 수 있도록 지원합니다. 이는 P2V라고 하는 프로세스로, 이를 통해 기존의 물리적 컴퓨터를 다시 설치할 필요 없이 가상 컴퓨터에 통합할 수 있습니다. P2V를 사용하면 단 하나의 실제 하드웨어에 기존의 물리적 컴퓨터를 여러 개 배치할 수 있으므로 하드웨어 사용률이 낮은 컴퓨터를 변환하는 경우에 특히 유용합니다. 예를 들어 거의 사용되지 않지만 일 년에 한 번은 실행되므로 유지 관리해야 하는 레거시 소프트웨어(예: 규정 회계 소프트웨어)가 설치된 컴퓨터에 특히 유용합니다. VMM을 System Center Operations Manager 2007과 함께 사용하면 Server Consolidation Candidates(서버 통합 후보) 보고서를 생성하여 물리적 인프라의 컴퓨터 중 P2V 후보로 유력한 컴퓨터를 검토할 수 있습니다.
VMware VMDK 형식의 가상 컴퓨터가 있는 경우 VMM의 V2V 변환 기능을 통해 기존 VMDK를 VHD 형식으로 변환할 수 있습니다. 이렇게 하면 Virtual Server 2005 환경을 빠르게 준비하고 실행할 수 있습니다.
새 배포든 변환을 통해 시작하는 배포든 관계없이, 모든 배포 시에 VMM은 지능형 배포라는 프로세스를 통해 VM을 가상 컴퓨터 호스트에 배포합니다. VMM은 지능형 배포를 통해 자신이 관리하는 모든 가상 컴퓨터 호스트를 쿼리하고 이러한 호스트의 리소스 가용성에 대한 몇 가지 매개 변수를 검색한 다음 VM을 배포하기에 적합한 권장 호스트 가중치 목록을 반환합니다. 그런 다음 그림 3과 같이 관리자가 권장 호스트를 수락하고 필요에 맞게 알고리즘을 조정하거나 선택한 서버에 그대로 VM을 배포할 수 있습니다. 지능형 배포 프로세스는 가상 인프라 및 해당 권장 호스트에 대한 통합된 보기를 통해 VM 배포와 관련된 번거로운 작업을 대폭 줄여 줍니다.
그림 3 지능형 배포 프로세스가 제공하는 최적의 Virtual Server 호스트 권장 목록
그림 3 지능형 배포 프로세스가 제공하는 최적의 Virtual Server 호스트 권장 목록
VMM이 제공하는 다른 유용한 기능으로는 중앙 집중화된 라이브러리와 위임 제공을 위한 셀프 서비스 포털이 있습니다. 그림 4에 나오는 이 라이브러리는 사전 생성되어 배포 준비가 된 VHD, OS 및 하드웨어 구성이 포함된 템플릿, ISO 파일, 스크립트, 프로필 등 가상 인프라를 빌드하는 데 필요한 모든 구성 요소를 위한 중앙 저장소를 제공합니다. 이러한 구성 요소를 사용하여 VM을 만들고 배포할 수 있으며 템플릿과 프로필을 통해 모든 VM의 하드웨어 및 소프트웨어 구성을 표준화할 수 있습니다. 또한 VMM은 분산 라이브러리를 지원하므로 구성 요소를 원격 위치에 저장하고, 대용량 파일 전송을 원격 위치 내에서 관리하되 구성 요소 관리는 계속해서 중앙에서 수행할 수 있습니다.
그림 4 가상 인프라의 모든 구성 요소가 포함된 VMM의 라이브러리
그림 4 가상 인프라의 모든 구성 요소가 포함된 VMM의 라이브러리
셀프 서비스 포털은 VMM 서비스와 IIS 설치가 통합된 웹 사이트입니다. 이 포털은 Active Directory®의 권한 있는 사용자 및 그룹에 VM 액세스 권한을 부여합니다. 사용할 수 있는 기능은 해당 사용자나 그룹에 대해 만들어진 정책에 따라 다릅니다. VM 보기 및 액세스, VM 실행 및 종료, 위임된 특정 리소스를 기반으로 새 VM 만들기에 이르는 다양한 기능이 있습니다.
관리자는 Active Directory 사용자 및 그룹, 특정 가상 컴퓨터 호스트 또는 호스트 그룹, 특정 VM 및 템플릿에 특정 기능을 제공하는 셀프 서비스 정책을 만듭니다. 셀프 서비스 포털을 통해 관리자는 최종 사용자에게 안전하게 기능을 위임할 수 있습니다. 이 기능이 없으면 관리자는 최종 사용자가 자신의 VM을 관리할 수 있도록 관리자 콘솔에 대한 액세스 권한을 부여하거나 최종 사용자가 필요할 때마다 관리자에게 해당 기능을 요청하도록 해야 합니다. 이 경우 VM 시작 및 재설정과 같은 작업을 수행해 줄 것을 요청하는 수많은 전자 메일과 전화 요청이 쇄도하게 될 것입니다.

Virtual Machine Manager 설치
VMM은 현재 Active Directory 도메인 또는 트러스트된 도메인 내의 Window Server 2003 SP1 이상에 설치된 Virtual Server 2005 이상은 물론, VMM의 경계 네트워크 지원을 사용하여 도메인에 속하지 않은 호스트의 해당 운영 체제에 설치된 Virtual Server 2005 이상 버전도 관리합니다. Windows® XP 같은 데스크톱 운영 체제에 설치된 Virtual Server는 지원되지 않습니다. P2V 작업은 VMM 서버와 같은 도메인 또는 트러스트된 도메인에 있는 물리적 컴퓨터에만 수행할 수 있습니다.
프로덕션 환경에서는 각 VMM 구성 요소를 별도의 서버에 설치하는 것이 좋지만 이 문서에서는 단일 서버에 설치한다고 가정하고 설명하겠습니다. VMM 서버 설치 시 권장 하드웨어는 2GB 이상의 RAM이 설치되어 있고 2.8GHz 이상의 속도로 실행되는 x86 또는 x64 기반 서버입니다. 여기서는 로컬 SQL Server 데이터베이스가 포함된 단일 서버 설치를 사용하므로 7GB의 하드 디스크 공간이 필요합니다. 대신 원격 데이터베이스를 사용하는 경우에는 VMM 설치에 1GB만 필요합니다. 로컬 라이브러리 설치를 위해 80GB의 추가 디스크 공간을 확보해 두는 것이 좋습니다.
또한 VMM을 설치하려면 VMM 서버, 모든 가상 컴퓨터 호스트, VMM이 관리할 모든 라이브러리 서버에 WinRM 1.1이 설치되어 있어야 합니다. WinRM은 웹 서비스 관리(WS-Management) 프로토콜의 Microsoft 구현입니다. WinRM은 방화벽 기능을 지원하는 SOAP 기반 프로토콜로, 서로 다른 공급업체의 하드웨어와 소프트웨어 간의 상호 운용 및 관리를 가능하게 합니다. VMM은 WinRM을 통해 VMM 서버, 가상 컴퓨터 호스트 및 라이브러리 서버 간에 작업을 수행합니다. WinRM 1.1은 go.microsoft.com/fwlink/?LinkId=103610에서 다운로드할 수 있습니다.
설치에 필요한 다른 필수 구성 요소로는 NET Framework 2.0과 3.0, Windows PowerShell 1.0, 그리고 셀프 서비스 포털에 사용되는 IIS가 있습니다. 이외의 다른 모든 소프트웨어 요구 사항은 VMM 소프트웨어 설치 시 검사되어 적절한 설치 관리자의 링크가 제공됩니다. 이때 요구 사항 중 하나라도 충족되지 않으면 설치를 계속할 수 없습니다.
VMM 설치를 시작하면 기본 메뉴에 Virtual Machine Manager 서버, 관리자 콘솔, 셀프 서비스 포털의 세 가지 옵션이 표시됩니다. 서버부터 시작해서 세 가지 모두 단일 컴퓨터에 설치하겠습니다. 설치 프로세스가 시작되면 첫 번째 화면에서 시스템 필수 구성 요소를 확인합니다. 설치를 계속하려면 모든 필수 구성 요소가 설치되어 있어야 합니다.
필수 구성 요소 확인 단계가 끝나면 설치 옵션, 특히 SQL Server 데이터베이스와 관련된 설치 옵션을 검토해야 합니다. VMM을 사용할 경우 SQL Server 2005 Express Edition 설치를 선택하거나 기존 SQL Server 2005 데이터베이스를 사용할 수 있습니다. 여기서는 SQL Server 2005 Express Edition을 사용하겠습니다.
VMM 설치 마법사의 다음 단계에서는 중앙 집중화된 라이브러리의 위치를 지정합니다. VMM 서버의 로컬 디렉터리를 사용할 수도 있고 기존 파일 공유를 사용할 수도 있습니다. VMM 서버의 로컬 디렉터리를 사용할 경우 해당 디렉터리에 대한 공유가 만들어집니다. 기본 위치는 C:\Documents and Settings\All Users\Shared Documents\Virtual Machine Manager Library Files입니다.
그 다음 단계에서는 포트를 할당합니다. 관리자 콘솔이 코어 VMM 서버 서비스에 연결하는 데 사용할 포트(포트 8100), WinRM이 관리 기능을 수행하는 데 사용할 포트(표준 HTTP 포트인 포트 80), BITS(Background Intelligent Transfer Service)가 파일을 가상 컴퓨터 호스트로 이동하는 데 사용할 포트(표준 HTTPS 포트인 포트 443)를 구성합니다. 이러한 정보가 모두 수집되면 요약 화면이 나타나고 서버 설치를 마칠 수 있습니다.
이제 관리자 콘솔을 설치합니다. 시스템 필수 구성 요소는 VMM 서버와 마찬가지로 .NET Framework 2.0 및 3.0과 Windows PowerShell 1.0입니다. 이때는 코어 VMM 서버 서비스에 연결하는 데 사용할 통신 포트만 구성하면 됩니다. 이 포트는 VMM 서버 설치 시 구성한 포트 8100입니다. 설치 마지막 단계에서 관리자 콘솔의 바탕 화면 바로 가기를 만드는 옵션과 설치 프로그램을 닫으면 콘솔을 여는 옵션이 표시됩니다. 두 옵션 모두 선택하는 것이 좋습니다. 처음으로 관리자 콘솔을 열면 서버 연결 정보를 요청하는 메시지가 표시됩니다. 단일 서버 설치의 경우 localhost의 포트 8100에 연결한 후 Enter 키를 눌러 콘솔을 시작합니다.
마지막으로, 같은 서버에 셀프 서비스 포털을 설치합니다. 셀프 서비스 포털 설치에 필요한 필수 구성 요소는 IIS, .NET Framework 2.0 및 3.0, Windows PowerShell 1.0입니다. 이때는 셀프 서비스 포털에서 사용하는 포트만 구성하면 됩니다. 먼저 관리자 콘솔을 설치할 때와 마찬가지로 코어 VMM 서비스에 연결하는 데 사용할 포트 8100을 구성합니다. 그 다음에는 포털 실행에 사용할 포트를 구성합니다. 기본 포트는 포트 80이지만 대부분의 구성에서 이 포트는 이미 사용 중인 경우가 많습니다. 필요한 경우 포트를 81 등 열려 있는 다른 포트로 변경합니다.
설치 관리자가 Microsoft System Center Virtual Machine Manager 2007 셀프 서비스 포털이라는 웹 사이트를 만듭니다. IIS 관리자에서 웹 사이트 구성을 변경할 수 있습니다. 쉬운 설치를 위한 팁을 한 가지 소개하자면, IIS 관리자로 이동한 후 Microsoft System Center Virtual Machine Manager 2007 셀프 서비스 포털 속성을 선택하고 웹 사이트의 ASP.NET 구성을 검토하여 ASP.NET 버전이 2.0으로 설정되어 있는지 확인하십시오. ASP.NET이 버전 1.1로 설정되어 있으면 셀프 서비스 포털이 작동하지 않습니다. 이 설정은 IIS와 두 .NET Framework 버전의 설치 순서에 따라 바뀔 수 있습니다.
IIS 설치가 완료되면 Internet Explorer®에서 http://localhost:81로 이동하여 웹 사이트를 열 수 있습니다. 웹 사이트를 열 때 Internet Explorer 보안 설정으로 인해 인증 요청 메시지가 표시될 수 있습니다. 셀프 서비스 포털은 Internet Explorer를 사용하여 인트라넷 컨텍스트에서 실행되어야 합니다. 따라서 로컬 구성에서 인트라넷 사이트 목록에 VMM 서버를 추가해야 할 수도 있습니다. 해당 구성을 적절히 변경하고 나면 VMM에서 셀프 서비스 정책을 만들고 사용할 수 있습니다.

Virtual Machine Manager 기능
VMM의 유용한 여러 기능 중 가장 주목할 만한 두 가지 기능은 바로 P2V(물리적 컴퓨터를 가상 컴퓨터로 변환)와 V2V(가상 컴퓨터 간 변환)입니다. 두 기능 모두 관리자 콘솔 내에서 지원됩니다. VMM 관리자 콘솔은 Windows PowerShell을 기반으로 하므로 Windows PowerShell에서도 모든 명령을 실행할 수 있습니다. 지금부터는 관리자 콘솔을 사용하는 P2V 프로세스와 Windows PowerShell을 통한 V2V 프로세스에 대해 살펴보겠습니다.

P2V(물리적 컴퓨터를 가상 컴퓨터로 변환)
VMM 관리자 콘솔을 사용하여 P2V 변환을 수행해 보도록 하겠습니다. 변환할 물리적 컴퓨터는 몇 가지 요구 사항을 만족해야 합니다. 먼저, 물리적 컴퓨터가 현재 도메인 또는 트러스트된 도메인의 구성원이어야 합니다. VMM은 이 컴퓨터에 연결하여 P2V 에이전트를 설치하고 필요한 정보를 전송합니다. 또한 원본 컴퓨터에서 지원되는 운영 체제가 실행되고 있어야 합니다. P2V를 지원하는 운영 체제는 Windows Server 2003, Windows 2000 Server 및 Windows XP Professional입니다. 원본 컴퓨터에서 Windows Server 2003이나 Windows XP를 실행 중이면 VMM이 VSS(볼륨 섀도 복사본) 서비스를 사용하여 하드 드라이브를 통합하고 데이터를 가상 하드 디스크로 스트리밍합니다. 이를 통해 서버 작동을 중단하지 않고 컴퓨터를 변환할 수 있습니다. 따라서 P2V 이미지를 만들기 위해 서버 작동 중단 시간을 예약할 필요가 없습니다. Windows 2000을 실행하는 경우 P2V 이미지 생성을 위해 Windows PE 부팅 디스크가 만들어집니다. 여기서는 Windows Server 2003 대상을 사용한다고 가정하고 설명하겠습니다.
P2V 프로세스는 관리자 콘솔 오른쪽 위의 작업에서 "Convert physical server(물리적 서버 변환)" 옵션을 선택하면 시작됩니다. 그러면 그림 5의 P2V Wizard(P2V 마법사)가 나타납니다. 첫 번째 페이지는 변환할 컴퓨터를 지정하는 원본 선택 단계입니다. 컴퓨터의 DNS 이름과 컴퓨터에 연결하여 이를 관리하는 데 필요한 도메인 자격 증명을 입력합니다. 그 다음 단계에서는 생성된 VM에 이름을 지정할 수 있습니다.
그림 5 관리 UI에 통합된 마법사 기반 VMM P2V 기능
그림 5 관리 UI에 통합된 마법사 기반 VMM P2V 기능
그런 다음 원본 컴퓨터에서 정보를 수집하는 프로세스가 시작됩니다. Gather System Information(시스템 정보 수집)을 클릭하면 원본 컴퓨터의 운영 체제, 하드 드라이브 및 네트워크 어댑터와 관련하여 필요한 정보를 검색하는 P2V 에이전트가 설치됩니다. 다음을 클릭하면 변환에 장애가 되는 알려진 문제가 없는지 확인하는 확인 화면이 나타납니다. 문제가 있는 경우 가능한 해결 방법이 표시됩니다.
구성 정보 검색이 끝나면 변환할 하드 디스크 파티션을 선택할 수 있습니다. 부팅 파티션이 기본적으로 선택되어 있으며 화면에 표시되는 다른 파티션을 선택할 수도 있습니다. 변환하려는 파티션을 모두 선택할 수 있습니다. P2V는 스마트 복사 프로세스입니다. 즉, 전체 하드 드라이브 이미지와 크기를 일괄적으로 전송하는 것이 아니라 지정된 파티션에 있는 데이터만 가져옵니다.
마지막으로, Virtual Server 시작 구성과 앞서 설명한 지능형 배포 프로세스를 비롯한 표준 VMM 배포 단계가 계속됩니다. 마법사가 끝나면 전체 P2V 프로세스 및 진행률을 보여 주는 작업 창이 나타납니다.
새로 변환된 VM은 중지됨 상태로 전환되어 있으므로 기본적으로 자동으로 시작되지 않습니다. 또한 P2V 프로세스가 종료되거나 원본 컴퓨터의 실행 상태가 변경되지도 않습니다. 이것이 바로 비파괴 P2V 프로세스입니다. 새 VM은 원래 서버와 컴퓨터 이름, IP 주소, 그리고 MAC 주소까지 동일하므로 VM을 시작하려면 원본 컴퓨터를 종료해야 합니다. 원본 컴퓨터를 종료하거나 새로 변환한 VM을 자동으로 시작하려면 Windows PowerShell 명령줄을 사용합니다. 이 프로세스를 진행하는 동안 P2V를 수행하고 생성된 VM을 테스트 환경에서 실행하여 모든 항목이 제대로 변환되었는지 확인하는 것이 좋습니다.

V2V(가상 컴퓨터 간 변환)
V2V를 수행하려면 VMDK 파일 형태의 VMWare 가상 컴퓨터와 지정된 대상 가상 컴퓨터 호스트가 있는 올바른 VMM 설치가 모두 있어야 합니다. VMM V2V Windows PowerShell cmdlet인 new-v2v는 monolithicSparse, monolithicFlat, twoGbMaxExtentSparse 및 twoGbMaxExtentFlat이라는 네 가지 VMDK 파일 형식을 지원합니다. 대부분의 기존 VMDK 파일은 이 네 가지 범주 중 하나에 속합니다.
V2V 프로세스는 오프라인 VMDK 파일에 대해서만 작동합니다. P2V 프로세스를 사용하면 현재 실행 중인 VMware 가상 컴퓨터도 변환할 수 있습니다. VMware 가상 컴퓨터는 두 개의 기본 구성 요소로 이루어집니다. 그 중 하나는 데이터가 저장된 가상 하드 디스크인 VMDK 파일이고 다른 하나는 가상 컴퓨터 구성 정보가 들어 있는 VMX 파일입니다. VMDK 파일 및 관련 VMX를 라이브러리 위치에 배치하면 원래 서버에서 파일에 대한 액세스 권한을 부여할 필요 없이 VMware 가상 컴퓨터에 액세스하여 이를 변환할 수 있습니다.
V2V 프로세스를 진행하는 동안 VMDK 파일이 VHD 파일로 변환되고 게스트 운영 체제는 Virtual Server와 작동하도록 정리됩니다. 또한 가능한 한 원래 구성과 일치하는 새 가상 컴퓨터가 만들어지고 Virtual Server에서 지원하는 가상 하드웨어에 맞게 필요한 구성 변경이 이루어집니다. 변환 프로세스의 각 부분은 Windows PowerShell을 통해 개별적으로 관리할 수 있습니다. Windows PowerShell을 사용하면 새 가상 컴퓨터에 호스트를 할당하기 전에 대량 형식 변환을 수행할 수 있습니다. 이 예제에서는 VHD를 변환하고 배포하도록 하겠습니다.
V2V는 관리자 콘솔과 Windows PowerShell 모두에서 수행할 수 있지만 여기서는 Windows PowerShell을 사용하겠습니다. V2V 프로세스를 시작하려면 Windows PowerShell을 시작하고 VMM cmdlet을 로드합니다. 시작 | 모든 프로그램 | Microsoft System Center | Virtual Machine Manager 2007 | Windows PowerShell - Virtual Machine Manager를 차례로 클릭하면 됩니다.
표시되는 창의 제목이 Windows PowerShell—Virtual Machine Manager여야 합니다. 그렇지 않은 경우 VMM cmdlet이 로드되지 않은 것입니다. Windows PowerShell이 열리면 다음 명령을 실행하여 new-v2v 명령을 살펴볼 수 있습니다.
get-help new-v2v –full | more
이 명령을 실행하면 V2V 수행 방법을 보여 주는 예제와 구문이 표시됩니다. 이 문서의 예제에서는 VMM 서버를 vmmserver.contoso.com이라고 하고 대상 가상 컴퓨터 호스트를 vshost1.contoso.com이라고 하겠습니다. VMDK는 라이브러리 서버 vmmserver.contoso.com에서 사용할 수 있습니다.
먼저 다음과 같이 get-vmmserver 명령을 사용하여 V2V를 수행하는 데 사용할 VMM 서버의 컨텍스트를 확인합니다. 모든 Windows PowerShell 명령과 마찬가지로 get-vmmserver는 동사-명사 형식을 따르며 매개 변수에 대시가 사용됩니다. 다음 코드 줄은 VMM 서버를 확인하는 데 사용되는 명령을 보여 줍니다.
get-vmmserver –computername "vmmserver.contoso.com"
이 명령은 vmmserver.contoso.com을 후속 명령에 사용할 VMM 서버 컨텍스트로 설정합니다. 위 명령을 실행하면 vmmserver.contoso.com에 대한 자세한 정보 목록이 표시됩니다. 명령이 올바르지 않거나 구문이 잘못된 경우 문제에 대해 설명하는 빨간색 오류 메시지가 나타납니다.
다음 단계는 변환된 VMDK/VHD를 할당할 Virtual Server 호스트인 대상 가상 컴퓨터 호스트를 확인하는 것입니다. Windows PowerShell에서 다음 명령을 사용하여 $vmhost 변수에 가상 컴퓨터 호스트 값을 지정합니다.
$vmhost = get-vmhost –computername
"vshost1.contoso.com"
이 명령은 명령 창에 어떠한 피드백도 제공하지 않지만 Windows PowerShell 프롬프트에서 $vmhost를 입력하고 Enter 키만 누르면 변수가 올바르게 설정되었는지 쉽게 확인할 수 있습니다. 그러면 $vmhost에 저장된 정보(앞의 VMM 서버에 대한 정보와 마찬가지로 vshost1.contoso.com에 대한 자세한 정보)가 표시됩니다.
가상 컴퓨터 호스트 외에도 VMDK 파일이 있는 라이브러리 서버를 확인해야 합니다. 이 명령은 앞서 사용한 가상 컴퓨터 호스트 명령과 비슷합니다.
$library = get-libraryserver –computername
"vmmserver.contoso.com"
$vmhost와 마찬가지로 명령줄에 $library를 입력하면 라이브러리 서버 정보가 표시됩니다.
마지막으로, 명령을 입력하여 V2V 변환을 수행합니다. 이렇게 하려면 new-v2v 명령을 get-help 함수와 함께 사용합니다. 이 명령에서 VMX/VMDK가 있는 라이브러리 서버, 대상 호스트, 생성될 VM의 이름, 변환될 VHD 파일의 경로를 지정합니다.
설치 경로가 VSHOST1에 대한 로컬 참조로 지정되었으므로 명령줄을 사용할 경우 대부분의 참조를 대상 호스트의 관점, 즉 여기서는 vshost1.contoso.com의 관점에서 지정합니다. VMX 경로는 라이브러리 서버의 관점에서 지정합니다. 이에 따른 Windows PowerShell 명령줄은 다음과 같습니다.
new-v2v –LibraryServer $library –vmxpath
"\\vmmserver.contoso.com\MSCVMMLibrary\VMDKS\ConvertMe.vmx"
–vmhost $vmhost -name "DemoV2V"
–path "C:\VHDs"
여기서는 라이브러리 서버 $library(VMMSERVER)의 \\vmmserver.contoso.com\MSCVMMLibrary\VMDKS\ConvertMe.vmx에 대한 VMX/VMDK를 변환하여 이를 $vmhost(VSHOST1) 변수의 호스트, 즉 DemoV2V라는 이름으로 VSHOST1의 C:\VHDs 경로에 배포합니다.
명령줄이 실행된 후에는 항상 VMM 관리자 콘솔의 작업 창으로 돌아가 진행률을 확인하는 것이 좋습니다. VMX/VMDK가 변환되어 VSHOST1에 복사되고 VSHOST1에서 결과 VHD가 DemoV2V라는 이름으로 VM 목록에 추가됩니다. 프로세스가 완전히 끝나면 VMM을 사용하여 새 가상 컴퓨터를 시작하고 결과를 검토할 수 있습니다.

요약
지금까지 살펴보았듯이 System Center Virtual Machine Manager 2007은 가상 인프라에 유용하게 사용할 수 있는 새로운 기능을 제공합니다. 이 문서에서 제공한 P2V 및 V2V 프로세스에 대한 설명이 Virtual Machine Manager를 사용할 때 이러한 프로세스를 얼마나 간편히 수행할 수 있는지를 잘 이해하는 기회가 되었기를 바랍니다.
VMM은 VM 생성, 배포 및 관리와 관련한 IT 관리자의 작업을 간편하게 만들 수 있도록 설계되었습니다. System Center Virtual Machine Manager 2007 릴리스를 사용하여 Virtual Server 2005를 관리하는 관리자라면 Virtual Machine Manager를 사용하여 가상 컴퓨터 호스트를 유지 관리해 볼 것을 적극 권장합니다. Windows Server 2008의 새로운 Windows Server 가상화를 사용하는 사용자를 위해 Microsoft는 다음 버전의 System Center Virtual Machine Manager에서 Windows Server 가상화에 대한 지원을 제공할 것입니다. 이 지원은 Windows Server 2008 가상화 최종 릴리스 이후에 제공될 예정입니다.
microsoft.com/SCVMM에서 VMM에 대한 자세한 내용을 보고 데모를 다운로드할 수 있습니다. 모든 Microsoft 가상화 제품에 대한 자세한 내용은 microsoft.com/virtualization을 참고하십시오.

Edwin Yuen은 Windows Enterprise Management 부서에서 System Center Virtual Machine Manager의 기술 제품 관리자로 근무하고 있으며, 2006년 7월 Microsoft가 Softricity를 인수함에 따라 Microsoft에서 근무하게 되었습니다. Edwin은 기업 및 정부 산하 기관에서 13년간 기술 자문 업무를 담당했으며, Johns Hopkins 대학에서 전기 공학 학사 학위를 받았습니다.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 System Center: Data Protection Manager 2007을 사용한 향상된 백업
System Center Calvin Keaton

Data Protection Manager 2007을 사용한 향상된 백업
한 눈에 보기:
  • 테이프 백업에서 전환
  • 연속 데이터 보호
  • 디스크 기반 백업
  • DPM을 사용한 보다 세분화된 제어

데이터 보호 시장은 최근에 일종의 부흥기를 맞았습니다. 꽤 오랜 기간 동안 테이프 기반 백업 솔루션과 천편일률적인 야간 백업 방법에 의존하다가
근래에 와서 비교적 짧은 기간에 다양한 새로운 기술과 방법이 출현하게 되었습니다. 새로 출현한 기술로는 디스크 기반 백업, CDP(연속 데이터 보호), 그리고 데이터 암호화 같이 매우 단순해 보이는 기술도 포함됩니다. 새로운 기술 중 몇몇은 디스크 저장소 가격의 하락, 네트워크와 프로세서의 성능 향상, 새로운 규제 요구 사항 등으로 인해 최근에 와서야 사용이 가능해지거나 필요성이 부각된 것들입니다.
Microsoft는 오랫동안 이 분야에서 플랫폼 및 응용 프로그램 기반 솔루션을 제공했으며 그 중 몇 가지 예를 들면 NTBackup, Exchange Server, SQL ServerTM 백업 도구가 있습니다.
System Center Data Protection Manager(DPM) 2006은 Microsoft가 데이터 보호 시장에 선보인 최초의 독립 실행형 소프트웨어 제품으로, 디스크 기반 데이터 보호 기능을 제공하는 초기의 제품 중 하나였으며 처음부터 끝까지 디스크 기반 백업을 염두에 두고 만들어진 몇 안 되는 제품 중 하나입니다. 대부분의 다른 제품은 테이프에 기반을 두었으며 디스크 기반 백업을 위해 개선되었을 뿐 여전히 테이프 기반 접근 방법을 취하고 있습니다.
DPM은 System Center 제품군의 일부입니다. System Center 제품군은 복잡한 IT 인프라의 일상적인 관리 업무를 보다 경제적으로 손쉽게 수행할 수 있도록 설계되었습니다. System Center는 MOF(Microsoft® Operations Framework) 및 ITIL(Information Technology Infrastructure Library)의 자동화 기술과 모범 사례를 기반으로 구축된 솔루션으로, 조직 내 모든 수준에서 사용할 수 있습니다.
DPM은 이러한 System Center 제품군의 한 부분일 뿐입니다. System Center Configuration Manager는 구성 관리 및 소프트웨어 배포 기능을 제공합니다. System Center Operations Manager는 시스템 사전 모니터링 및 자동화 기능을 제공합니다. System Center Capacity Planner는 인프라 배포의 용량 계획과 가상 분석에 사용할 수 있습니다. 자세한 내용은 microsoft.com/systemcenter를 참조하십시오.
System Center Data Protection Manager 2006은 파일 및 인쇄 서버에 대한 디스크 기반 백업 기능과 지점에 대한 WAN 기반 디스크 백업 기능을 제공합니다. System Center Data Protection Manager 2006은 데이터 센터의 파일 서버를 보호하고 지점 로컬 테이프 백업 하드웨어의 필요성을 제거하도록 설계되었지만 Microsoft 응용 프로그램을 기본적으로 지원하지 않으며 장기 테이프 보관 시 타사 제품을 사용하는 단점이 있었습니다.
System Center Data Protection Manager 2006에 기반을 둔 새로운 DPM 버전인 System Center Data Protection Manager 2007은 이전 버전과 마찬가지로 파일 서버와 인쇄 서버 및 지점에 대한 강력한 디스크 기반 보호 기능을 제공하는 동시에 Exchange, SQL Server, SharePoint® 등의 중요한 업무용 Microsoft 응용 프로그램에 대한 지원을 추가로 제공하며 테이프 백업을 기본적으로 지원합니다. 새로운 버전에서 많은 변경이 이루어지는 것은 흔히 볼 수 있는 일이지만 DPM의 경우에는 특히 그렇습니다. 이 두 번째 버전에서는 다수의 새로운 기능이 추가되었으며 기존 기능의 성능이 크게 향상되었습니다. 이 문서에서는 몇 가지 새로운 기능과 향상된 기능을 살펴보고 새로운 버전에서 기대할 수 있는 효과를 전반적으로 살펴보도록 하겠습니다.

응용 프로그램 및 플랫폼 지원
대부분의 백업 소프트웨어 공급업체는 응용 프로그램 지원에 대해 범용성을 우선하는 접근 방식을 취합니다. 즉, 가능한 한 다양한 데이터 원본을 지원하기 위해 엔지니어링 투자를 다수의 응용 프로그램에 걸쳐 분산시킵니다. 그 결과 매우 다양한 응용 프로그램을 지원하되 극히 기본적인 기능만 지원하게 됩니다. Microsoft는 광범위한 응용 프로그램이나 플랫폼에 대해 제한된 지원을 제공하는 대신 Windows® 플랫폼의 몇 가지 특정 응용 프로그램을 보호하는 것에 주력하는 방법을 선택했습니다. 이렇게 소수의 특정 응용 프로그램에만 엔지니어링 노력을 집중 투자한 결과 다른 백업 제품에서는 흔히 찾아볼 수 없는 기능이 포함된 통합된 백업 및 복원 환경을 만들 수 있게 되었습니다.
Microsoft Exchange 지원은 DPM 2006 사용자가 요청한 최우선 기능입니다. 이를 염두에 두고 설계된 DPM 2007에서는 Exchange Server 2003과 Exchange Server 2007을 모두 지원합니다. DPM UI에서 개체로 나타나는 개별 저장소 그룹에 대해 저장소 그룹 수준의 보호가 이루어지며, 필요한 경우 개별 저장소 그룹을 보호 그룹에 추가하여 예약된 정책 기반 백업을 수행할 수 있습니다. 이제 클러스터형 저장소 그룹이 단일 개체로 나타나므로 클러스터의 개별 구성원을 추적할 필요가 없으며 저장소 보호를 수동으로 동기화할 필요도 없습니다. 복원은 저장소 그룹, 데이터베이스 또는 사서함 수준에서 발생합니다. 또한 자동화를 통해 세분화된 복구를 수행할 수 있습니다. 즉, 표준 Exchange 도구를 사용하여 데이터를 복구 저장소 그룹에 복원한 다음 다시 표준 Exchange 도구를 사용하여 사서함과 같은 보다 세분화된 개체를 추출하도록 자동 복구 작업을 구성할 수 있습니다(그림 1 참조).
그림 1 DPM의 Exchange 지원
그림 1 DPM의 Exchange 지원
몇몇 다른 Exchange 백업 솔루션과 달리 DPM은 복원된 개체 추출 시 Exchange 도구 이외의 도구를 사용하거나 Exchange 데이터베이스를 리버스 엔지니어링하지 않습니다. 따라서 Exchange에서 DPM 기반 사서함 복원이 완벽하게 지원됩니다.
DPM 2007은 Exchange 2007 CCR(클러스터 연속 복제)과 LCR(로컬 연속 복제)을 완벽하게 지원하는 첫 번째 제품입니다. Exchange 2003 클러스터도 지원됩니다.
SQL Server 2000과 SQL Server 2005는 DPM 2007에서 지원되며 백업과 복원이 모두 데이터베이스 수준에서 발생합니다. 리디렉션된 복원과 이름 재지정 복원이 지원되며 클러스터된 데이터베이스, 미러링된 데이터베이스, 로그 전달 데이터베이스도 완벽하게 지원됩니다.
Exchange와 마찬가지로 여러 개의 클러스터된 데이터베이스가 UI에서 단일 개체로 나타나므로 각각의 클러스터된 서버에 대해 별도로 보호를 구성할 필요가 없습니다(그림 2 참조). DPM의 SQL Server 지원을 통해 백 엔드 SQL Server 데이터베이스를 사용하는 수많은 타사 응용 프로그램을 보호할 수 있습니다. 이 경우 응용 프로그램은 파일 보호를 통해 보호되고 SQL Server 데이터베이스는 DPM의 기본 SQL Server 지원을 통해 보호됩니다. DPM의 융통성이 뛰어난 예약 엔진을 사용하면 동일 보호 그룹에 파일 백업과 SQL Server 백업을 모두 추가하여 두 가지 백업을 동시에 수행하고 일반 관리 및 예약 인터페이스를 공유할 수 있습니다.
그림 2 클러스터링 백업
그림 2 클러스터링 백업
공동 작업 관련 작업은 SharePoint 2007을 통해 보호되며, Windows SharePoint Services(WSS) 3.0과 Microsoft Office SharePoint Server(MOSS) 2007이 모두 지원됩니다. 지원은 팜 수준에서 발생하며, 팜이 여러 서버에 분산되어 있는 경우에도 마찬가지입니다. 예를 들어 웹 프런트 엔드 서버 세 개와 사이트 모음 서버 두 개, 데이터베이스 서버 한 개의 총 여섯 개 서버로 구성된 팜은 DPM UI에서 단일 개체로 나타나고 단일 개체로 백업되며, DPM에서도 단일 개체로 복원할 수 있습니다.
DPM은 전체 팜 복원을 지원하는 동시에 사이트, 사이트 모음, 개별 문서, 목록 또는 항목 복원도 지원합니다. 이전 버전의 SharePoint는 DPM SQL Server 보호 기능을 통해 SQL Server 데이터베이스로 보호할 수 있습니다.
파일 및 인쇄 작업도 DPM 2007에서 계속해서 지원되며 파일 열기 지원도 추가 비용 없이 사용할 수 있습니다. 파일 및 폴더 제외에 대한 지원과 시스템 상태 백업 지원도 추가되었습니다. Windows Vista® 및 Windows XP를 포함하도록 파일 지원이 확대되었다는 점도 주목해야 합니다. 그러나 주로 파일 서버로 사용되는 시스템이 지원 대상이므로 이러한 클라이언트 운영 체제에 대한 지원은 비교적 제한적입니다. DPM 사용자는 필요한 경우 소수의 클라이언트를 보호할 수 있지만 다수의 데스크톱으로 지원을 확장하는 것은 쉽지 않습니다.
Exchange Server, SQL Server, SharePoint 서버 및 파일 서버에 대한 기본 지원을 통해 DPM은 Windows 환경에서 발생하는 대부분의 작업을 지원할 수 있습니다. 일반적이지 않은 작업을 위해 DPM 2007은 백업이 수행될 때마다 자동으로 실행할 수 있는 사전 스크립트 및 사후 스크립트를 지원합니다. 이 기능을 통해 DPM은 광범위한 다른 응용 프로그램이나 작업을 지원할 수 있습니다. 이와 같은 지원은 Exchange, SQL Server, SharePoint 등에 대한 지원만큼 통합된 것은 아니지만 다양한 데이터 원본을 융통성 있게 지원합니다. Oracle 같이 Microsoft 제품은 아니지만 널리 사용되는 제품을 지원하는 방법에 대해 자세히 알아보려면 DPM TechCenter(technet.microsoft.com/dpm)를 참조하십시오.
DPM 2007의 보다 흥미로운 향상 기능 중 하나는 호스트 기반 가상 서버 지원입니다. 대부분의 백업 제품은 가상 서버 게스트를 개별 서버로 지원할 수는 있지만 이러한 보호를 단일 라이선스 및 에이전트 설치를 통해 호스트 수준에서 지원할 수 있는 제품은 거의 없습니다. DPM은 재귀 VSS(볼륨 섀도 복사본 서비스) 작성기를 사용하여 호스트에 배포된 단일 에이전트를 통해 특정 가상 서버 호스트에서 호스트되는 모든 게스트를 보호합니다. 이 재귀 VSS 작성기는 게스트 또는 게스트에서 실행되는 응용 프로그램에서 활성 상태인 VSS 작성기를 호출할 수 있습니다. 게스트에 설치된 응용 프로그램이나 운영 체제의 종류는 관계가 없습니다. 이를 통해 DPM은 공급업체에 관계없이 게스트로 실행되는 모든 플랫폼이나 응용 프로그램을 보호할 수 있습니다. 이러한 호스트 기반 가상 서버 백업의 경우 응용 프로그램과의 일관성이 유지되며 필요에 따라 기존 호스트나 새 호스트에서 복원할 수 있는 단일 VHD(가상 하드 디스크) 이미지가 생성됩니다.
이러한 호스트 기반 백업 이미지는 게스트나 독립 실행형 서버에 설치된 DPM 에이전트를 통해 만들어진 백업만큼 세분화된 수준의 복원을 제공하지는 않지만 가상화된 환경에 대한 간편한 시스템 복구를 비롯하여 여러 가지 면에서 효율적입니다.

속도, 안정성 및 효율성
이전 버전에 비해 DPM 2007의 응용 프로그램 지원은 적용할 수 있는 깊이와 범위가 모두 향상되었을 뿐만 아니라 전체 백업과 증분 백업의 세분성도 향상되었습니다. DPM 2006에서는 최대 1시간마다 동기화가 가능했지만 DPM 2007에서는 15분마다 증분 백업을 수행하고 1시간마다 전체 백업을 수행할 수 있습니다. 이보다 낮은 수준의 SLA(서비스 수준 계약)가 필요한 고객의 경우 일주일에 한 번만 전체 백업을 수행할 수도 있습니다. 이러한 고객은 중요도가 낮은 서버에 대해서는 백업 빈도를 줄이고 중요한 서버에 대해서는 백업이 자주 수행되도록 예약할 수 있습니다. 15분마다 DPM 서버와의 동기화가 수행되지만 DPM 에이전트는 동기화 사이 사이의 공백 기간 동안 보호된 서버의 변경 내용을 적극적으로 추적합니다.
새 DPM 에이전트는 보호된 서버에서 블록 수준 변경이 발생할 때마다 이를 지속적으로 추적합니다. 이는 DPM 2007용으로 개발된 완전히 새로운 볼륨 필터를 통해 가능합니다. 이 필터는 페이징 풀 메모리에 존재하며 보호된 볼륨의 각 블록을 1비트로 나타내는 비트맵으로 구성되어 있습니다.
볼륨에 블록이 작성될 때마다 이 비트맵에서 그에 해당하는 1비트가 활성화됩니다. 이 프로세스가 프로세서와 메모리에 미치는 영향은 일반적인 바이러스 백신 필터에 비해 미미하며 변경 비율이 달라져도 디스크 공간 요구 사항이 늘어나지 않습니다. 즉, 이 필터로 인한 부하는 변경 비율에 따라 늘어나지 않습니다. 이는 매우 주목할만한 점입니다. 대부분의 블록 수준 변경 추적 스키마의 경우 프로세서 및 메모리 오버헤드를 발생시킬 뿐만 아니라 변경 비율에 따라 디스크 사용량도 늘어납니다. 따라서 변경 비율이 높을수록 더 많은 영향을 주게 되고 변경 비율이 매우 높을 경우 시스템의 디스크 공간이 부족해지는 현상이 발생하기도 합니다. DPM 2007의 경우 볼륨 필터가 프로세서, 메모리 및 디스크에 주는 영향은 변경 비율에 관계없이 일정합니다. 즉, 변경 비율이 1%이든 1,000%이든 이 필터로 인해 발생하는 낮은 오버헤드에 영향을 주지 않습니다.
변경된 데이터 추적은 DPM 2007의 수많은 기능 중 하나에 불과합니다. DPM 2007은 보호된 서버에서 VSS 서비스를 사용하여 응용 프로그램과 일관되며 안정적인 복구가 가능한 백업 이미지를 만듭니다. VSS는 Windows XP 및 Windows Server® 2003을 위한 백업 인프라를 제공하고 데이터에 대한 일관된 지정 시간 복사본(섀도 복사본)을 만드는 메커니즘으로 사용하기 위해 Microsoft에서 개발한 기술입니다. VSS는 업무용 응용 프로그램, 파일 시스템 서비스, 백업 응용 프로그램, 빠른 복구 솔루션 및 저장소 하드웨어를 통해 읽기 및 쓰기를 조정하여 일관된 섀도 복사본을 생성할 수 있습니다. 따라서 VSS는 현재의 시장에서 응용 프로그램과 일관된 백업을 생성하는 가장 일관되고 안정적인 메커니즘이라고 할 수 있습니다. 공유 폴더의 섀도 복사본을 비롯한 Windows Server 2003의 몇 가지 기능은 VSS를 사용합니다.
응용 프로그램 백업에 VSS를 사용하는 대부분의 제품은 변경 내용을 추적하고 백업을 위해 응용 프로그램과 일관된 이미지를 얻기 위해 VSS 복제본을 만들어 보호된 서버의 적절한 위치에 보관합니다. 그러나 복제본을 항상 보호된 서버 내에 두면 응용 프로그램에서 디스크에 쓸 때마다 VSS 복제본을 최신 상태로 유지하기 위해 기록 중 복사(COW)가 일어나므로 성능에 꽤 많은 영향을 주게 됩니다. 이로 인해 25% 가량의 프로세서 오버헤드가 발생하고 응용 프로그램에서 디스크에 쓸 때 많은 영향을 줄 수 있습니다.
DPM은 자체의 볼륨 필터를 통해 변경 내용을 추적하므로 VSS 복제본을 항상 보호된 서버에 유지할 필요가 없습니다. 대신 DPM은 전체 백업이 수행될 때 VSS 복제본을 만든 다음 복제본의 변경된 데이터만 식별하기 위해 볼륨 필터 비트맵을 오버레이합니다. 변경된 데이터는 DPM 서버로 이동되어 복구 지점을 만드는 데 사용됩니다. 그런 다음 보호된 서버의 VSS 복제본이 삭제되고 볼륨 필터가 다시 설정됩니다. 그런 후에는 오버헤드를 거의 발생시키지 않고 VSS 복제본이나 이와 관련된 리소스 사용 없이 블록 수준 변경 추적이 계속됩니다.
이 솔루션의 경우 복구 지점에서 복원 가능한 응용 프로그램 이미지가 생성되고 보호된 서버와 DPM 서버 간에 이동되는 데이터의 양이 줄어듭니다.
DPM 2007의 전체 백업은 데이터의 전체 복사본을 보호된 서버에서 DPM 서버로 이동하지 않습니다. 대신 변경된 데이터만 이동합니다. 따라서 1일 변경 비율이 10%인 100GB의 Exchange 저장소 그룹에 대해 매일 전체 백업을 수행하면 10GB의 데이터만 이동됩니다.
이러한 전체 백업의 크기 감소는 복구 지점을 캡처하기 위해 스냅숏을 만들 때 DPM 서버의 저장소 효율을 크게 높여 줍니다. 각 스냅숏은 마지막 전체 백업 이후 만들어진 변경된 데이터로 구성되며 전체 백업이 수행될 때 자동으로 만들어집니다. 응용 프로그램에 대한 백업의 경우, 발생한 중간 증분 백업도 스냅숏에 포함됩니다.
DPM에서 증분 백업은 기본적으로 로그 백업이므로 응용 프로그램에 대해 전체 백업을 수행할 때마다 변경된 데이터가 DPM 서버로 이동된 후 중간 로그 백업과 결합되어 여러 복구 지점이 포함된 단일 스냅숏이 만들어집니다. 앞에서 설명한 1일 변경 비율이 10%인 100GB Exchange 저장소 그룹의 경우 매일 전체 백업을 수행하고 15분마다 증분 백업을 수행한다고 가정하면 10GB의 변경된 데이터와 5-10GB 가량의 응용 프로그램 로그가 스냅숏에 포함됩니다. 15GB에서 20GB 가량의 이 스냅숏에 최대 97개의 복구 지점이 포함된다는 점을 주목할 필요가 있습니다.
전체 백업은 적어도 1주일에 한 번 이상은 수행되어야 합니다. 총 스냅숏 수는 응용 프로그램 서버의 경우 512개로 제한되고 파일 서버의 경우 64개로 제한됩니다. 따라서 매주 전체 백업을 수행하고 15분마다 증분 백업을 수행하면 스냅숏당 673개의 복구 지점이 만들어지고 512개의 스냅숏이 모두 사용될 경우 340,000개가 넘는 복구 지점이 만들어집니다. 디스크에 이렇게 많은 복구 지점을 보관할 필요는 거의 없지만 이는 작업 예약 및 지정 시간 복구와 관련된 DPM의 융통성과 확장성을 잘 보여 줍니다.
전체 백업에 로그 백업을 포함함으로써 DPM은 매우 많은 수의 복구 지점을 매우 적은 양의 디스크 공간에 효율적으로 저장할 수 있습니다. 그러나 이 프로세스는 어느 정도의 오버헤드를 발생시킵니다. 또한 중복 제거 구성 요소, 즉 블록 수준 변경 추적 기능이 포함되어 있기는 하지만 이 프로세스가 기술적으로 압축이나 SIS(단일 인스턴스 저장소)는 아닙니다. 명칭이 무엇이든 간에 DPM은 생성된 각 복구 지점에 대해 매우 적은 양의 저장소를 사용하여 매우 효율적인 작업을 수행합니다. 이보다 중요한 것은 DPM은 이 작업을 위해 기존의 압축, 단일 인스턴스 저장소 또는 중복 제거를 사용하지 않기 때문에 압축, SIS 또는 중복 제거 저장소 플랫폼을 사용하여 DPM 서버에 저장소를 제공할 경우 효율성이 더욱 증대될 수 있다는 것입니다.

데이터 무손실 복구 및 CDP
DPM 2007의 가장 흥미로운 변경 중 하나가 바로 Microsoft 응용 프로그램에 대해 무손실 복구를 수행할 수 있는 기능입니다. 이는 블록 수준 변경 추적과 VSS 아키텍처, 그리고 보호된 서버의 기존 응용 프로그램 로그와의 긴밀한 통합을 통해 가능합니다.
일반적으로 현재 시장에서 데이터 보호 및 복구를 위해 사용하는 방법은 다음 두 가지입니다.
복제 기반 솔루션 복제 기반 솔루션은 대부분의 고객이 대개 CDP(연속 데이터 보호)로 생각하는 솔루션입니다. 복제 기반 데이터 보호에는 변경 발생 시 보호된 서버의 변경 내용을 백업 서버로 이동하는 작업이 포함됩니다. 복제 기반 솔루션은 데이터 손실 없이 어느 시점으로도 복구가 가능한 디스크 기반 솔루션입니다.
복제 기반 솔루션은 매우 우수한 기술이기는 하지만 몇 가지 단점이 있습니다. 무엇보다도 복제 솔루션에 응용 프로그램 상태라는 개념이 존재하지 않을 뿐만 아니라 응용 프로그램의 구동부에 대해서도 인식하지 못합니다. 따라서 버퍼를 플러시하지 않으며, 백업 중 메모리에 있거나 전송 중인 데이터를 고려하지 않습니다. 이로 인해 복제 기반 복구 지점이 응용 프로그램과 일관되지 않는 경우가 흔하게 발생합니다. 즉, 복구를 수행할 수는 있지만 응용 프로그램이 실제로 사용 가능한 상태로 돌아오지 않습니다. 일부 복제 기반 CDP 공급업체의 경우 해당 설명서에 현재 복구 지점이 작동하지 않을 경우 응용 프로그램에 다른 복구 지점을 시도하라는 내용을 포함할 정도로 이 문제는 흔하게 발생하고 있습니다.
응용 프로그램 일관성 문제 외에도 복제 기반 CDP 솔루션은 일반적으로 비용이 꽤 많이 들고, 네트워크 및 프로세스 오버헤드를 일으키며, 전용 하드웨어에서나 가능한 많은 양의 저장소 공간을 필요로 합니다. 또한 복제 기반 데이터 보호 솔루션은 대부분의 고객에게 필요한 보관 또는 오프사이트 테이프 백업에 그다지 적합하지 않습니다.
스냅숏 기반 솔루션 스냅숏 기반 솔루션은 지정 시간 복구에 사용할 수 있는 지정 시간 스냅숏을 외부 미디어에 만드는 기존의 테이프 백업 방식의 데이터 보호 솔루션입니다. RPO(목표 복구 지점)는 스냅숏 빈도에 따라 결정되므로 매일 백업할 경우 24시간 동안의 데이터가 손실됩니다. 스냅숏은 저렴하고 관리하기가 쉬울 뿐만 아니라 네트워크에 미치는 영향이 제한되고 디스크 보관이나 테이프 보관에 적합하다는 장점이 있습니다. 또한 스냅숏 기반 솔루션을 사용할 경우 스냅숏을 만들기 전에 응용 프로그램을 준비할 시간을 가질 수 있으므로 대개 응용 프로그램과 일관된 이미지가 생성되며 따라서 백업이 수행될 때 응용 프로그램의 구동부가 누락될 위험이 줄어듭니다.
스냅숏 생성의 최근 추세는 유사 CDP 솔루션에 가까워지고 있습니다. 이러한 솔루션은 스냅숏 빈도가 늘어나 RPO가 매우 낮아지는 스냅숏 솔루션입니다. 일부 제품은 이제 RPO를 분 단위로 측정하고 그만큼 스냅숏을 자주 만들게 됨에 따라 유사 CDP라는 수식어를 떼고 완전한 CDP 제품이라고 선전할 정도입니다. 그러나 복원의 경우에는 여전히 몇 분 동안의 데이터 손실이 발생합니다.
DPM 2006은 명백히 유사 CDP 스냅숏 생성 방식을 취하지만 DPM 2007은 고유한 방식으로 CDP를 실현합니다. 새로운 버전의 DPM은 최대 15분마다 VSS 및 고유의 블록 수준 변경 추적 기술을 통해 스냅숏을 생성하여 변경된 데이터만 보호된 서버의 VSS 스냅숏에서 이동합니다. 따라서 개별 지정 시간 스냅숏에 블록 수준 변경 내용만 포함되므로 스냅숏 크기가 매우 작습니다. 이는 매우 발전된 스냅숏 생성 방식입니다. DPM에 새로 추가된 혁신적인 기능은 Exchange, SQL 및 SharePoint를 위한 완전한 응용 프로그램 통합입니다. DPM에서 응용 프로그램 로그를 인식하고 복구 시 이러한 로그를 롤포워드할 수 있을 정도로 긴밀하게 통합되었습니다. 응용 프로그램 로그가 있는 한 DPM은 마지막 지정 시간 스냅숏에서 응용 프로그램 로그를 롤포워드하여 무손실 복구를 실현할 수 있습니다(그림 3 참조). 최선의 방법에 따라 응용 프로그램 로그를 별도의 드라이브에 보관했다면 응용 프로그램 로그를 사용할 수 있을 것입니다.
그림 3 Data Protection Manager Administrator Console(관리자 콘솔)의 복구 옵션
그림 3 Data Protection Manager Administrator Console(관리자 콘솔)의 복구 옵션
복제 기반 솔루션과 스냅숏 기반 솔루션을 혼합하여 CDP를 구현하는 이러한 접근 방식은 여러모로 두 솔루션에서 최선의 것만 가져온 것입니다. 즉, 복제 기반 제품의 데이터 무손실 기능과 함께 스냅숏 생성 솔루션의 응용 프로그램 일관성 및 장기 보관 지원 기능을 제공하면서 두 솔루션이 지닌 여러 가지 단점은 배제합니다.

디스크 및 테이프 백업 지원
제품에 테이프 지원 기능이 추가되었다는 점을 빼놓는다면 DPM 2007의 새로운 기능에 대해 모두 설명했다고 할 수 없을 것입니다. DPM 2006은 D2D(디스크 대 디스크) 백업만 지원했습니다. 즉, 데이터가 보호된 서버의 디스크에서 DPM 서버의 디스크로 이동되었습니다. DPM 2007에서는 디스크와 테이프 미디어를 모두 지원합니다. 따라서 보호된 서버의 디스크에서 DPM 서버에 연결된 디스크로(D2D) 또는 DPM 서버에 연결된 테이프로(D2T) 데이터를 이동하거나, 보호된 데이터를 먼저 DPM 서버의 디스크에 스테이징한 후 장기 보관을 위해 테이프로 이동할 수 있습니다(D2D2T).
DPM 2007에서는 다양한 테이프 라이브러리와 자동 로더 및 많은 종류의 테이프 미디어를 지원합니다.
DPM의 테이프 지원에는 추가 비용을 들일 필요가 없는 소프트웨어 기반 테이프 미디어 암호화, 기본 암호화 키 관리, 테이프 보관 및 위치 추적과 같은 많은 고급 기능이 포함되어 있습니다.

요약
지금까지 System Center Data Protection Manger 2007의 몇 가지 새로운 기능과 향상된 기능에 대해 자세히 살펴보았습니다. 이러한 기능은 Microsoft 플랫폼과 응용 프로그램을 위해 일관되고, 안정적이며, 관리하기 쉬운 데이터 보호 기능을 제공하도록 설계되어 Windows 응용 프로그램 및 플랫폼 데이터 보호의 새로운 표준이 되었습니다.
이 문서에서 설명한 기능 외에도 이 제품에는 Windows 통합 최종 사용자 복구, 융통성 있는 대역폭 제한, 고급 명령줄 인터페이스 등의 많은 향상된 기능이 포함되어 있습니다. Data Protection Manager 2007 베타 2를 다운로드하여 이러한 기능들을 직접 사용해 보십시오. System Center 제품군에 포함되는 모든 제품에 대한 소개와 자세한 내용은 microsoft.com/systemcenter를 참조하십시오. 이 웹 사이트에서 Data Protection Manager를 비롯하여 System Center 제품군에 포함되는 모든 솔루션을 살펴 볼 수 있습니다.

Calvin Keaton은 현재 DPM의 제품 기획자로 근무하고 있으며, 이전에는 Microsoft IT Data Protection 서비스를 관리했습니다. Microsoft에 근무하기 전에는 Compaq과 HP Services의 데이터 센터 사이트 운영 팀을 연이어 관리하는 등 데이터 센터 운영 및 하드웨어 관련 분야에서 6년 간 경력을 쌓은 바 있습니다.


 System Center: 소프트웨어 자산을 간단히 관리해 주는 온라인 서비스
System Center Paul Bourgeau

소프트웨어 자산을 간단히 관리해 주는 온라인 서비스
한 눈에 보기:
  • 온라인 서비스의 기초
  • 품목 관리 에이전트 설치
  • 품목 관리 보고서 작성

CFO가 방금, 회사의 모든 컴퓨터와 그 위치, 그리고 각각에 설치된 소프트웨어 등에 대한 완벽한 물품 목록이 필요하니 '조금만 수고해 달라'는 메일을 보내왔습니다.
기한은 이번 주말까지라고 합니다. CFO가 이러한 목록을 필요로 하는 이유는 다음과 같습니다. 이 중 하나 이상에 해당하겠지요.
  • 내년 예산을 수립해야 하는 시점이므로, 소프트웨어 라이선스 비용으로 얼마를 책정해야 하는지 알아야 하기 때문입니다.
  • 소프트웨어 감사 통지서를 받았으므로, 회사에서 규정을 준수해야 하는 특정 제품의 라이선스를 충분히 보유하고 있다는 증빙 자료를 준비해야 하기 때문입니다.
  • CEO로부터 IT 운영비를 줄이라는 요구를 받았으며, 응용 프로그램 표준화가 그 방법의 하나라고 생각하고 있기 때문입니다.
그렇다면 이제 어떻게 해야 할까요?
IT 자산 관리 기법은 지난 10년간 계속 발전해왔으며, 이제 기업의 관심은 소프트웨어 자산의 효과적인 관리에 모여지고 있습니다. 그 주된 이유는 이제 소프트웨어가 재무 투자에서 과거보다 매우 큰 부분을 차지할 뿐만 아니라, 법률과 보안, 정책 등에 관련된 문제들의 중요성이 커지고 있기 때문입니다. 규정 위반을 적발당하여 막중한 벌금이나 과징금을 부담해야 할 가능성이 늘 존재하기 때문에 정확한 자산 관리의 필요성이 더욱 커지고 있는 것입니다.
일반적으로, 대기업은 소프트웨어 관리에 필요한 자원과 도구를 자체적으로 갖추고 있습니다. 이러한 도구들은 하드웨어 및 소프트웨어 자산 목록을 파악할 뿐만 아니라, 소프트웨어를 데스크톱 컴퓨터에 배포하는 작업을 관리하고 성능을 비롯한 여타 운영 상태를 모니터링하는 대규모의 다목적 솔루션인 경우가 많습니다. 그런데 그러한 솔루션을 사용할 수 없거나 그처럼 복잡한 솔루션을 구현하고 관리할 자원과 전문가를 구할 수 없을 경우 기업은 어떠한 상황에 처하게 될까요?
소규모 기업과 대기업의 요구를 모두 충족한다는 것이 '서비스로서의 소프트웨어'(software as a service: SaaS)라는 개념에 영향을 미친 주된 목표 가운데 하나입니다. Microsoft "Software plus Services"는 고객의 효과적인 소프트웨어 자산 관리에 도움이 되는 서비스 기반 솔루션을 개발하고자 하는 노력을 아우르는 전략입니다. Microsoft® Asset Inventory Service는 이러한 서비스의 첫 주자 가운데 하나로서 Desktop Optimization Pack for Software Assurance에 포함되어 Software Assurance 고객에게 올 후반기부터 제공됩니다.
그림 1의 AIS(Asset Inventory Service)는 회사 전체의 컴퓨터에 설치된 소프트웨어에 관한 정보를 수집하는, 쉽게 구축하고 쉽게 사용할 수 있는 호스트 방식 서비스입니다. 이 정보는 브라우저 기반 보고서를 통해 이용할 수 있으며, 이 서비스의 향후 버전에서는 Microsoft 볼륨 라이선스 계약서의 배포를 분석하는 기능도 제공할 계획입니다.
그림 1 Microsoft Asset Inventory Service
그림 1 Microsoft Asset Inventory Service

온라인 서비스의 특성
온라인 솔루션을 채택하는 이유는 무엇일까요? 업데이트와 새로운 버전을 즉시 이용할 수 있다는 점, 도입이 쉽다는 점, 개발 및 관리 비용이 절감된다는 점 등 몇 가지 뚜렷한 이유가 있습니다.
온라인 서비스는 동적입니다. 즉, 웹 페이지처럼 서비스 공급자가 콘텐츠와 기능을 상시 업데이트하여 사용 방식과 환경을 개선하고 기술 분야의 변화에 발 빠르게 대응할 수 있습니다. 따라서 유례없는 수준의 기민한 대응 능력을 확보할 수 있으며, 소프트웨어 공급업체가 관리자의 데스크톱 컴퓨터 관리 업무 능률을 높일 수 있는 최신 기능과 솔루션, 지식 정보를 제공할 수 있습니다.
온라인 서비스는 보편성이라는 장점을 가지고 있습니다. 오늘날 IT 환경에는 모든 PC가 네트워크 자원에 직접 연결되어 있는 환경에서부터 여러 장소에 분산된 원격 사용자와 지사가 인터넷을 통해 자원을 액세스하는 환경 등 다양한 상황이 복합적으로 얽혀 있습니다. 웹 기반 메일 프로그램을 이용하는 경우를 제외하면 회사 네트워크에 거의 접속조차 하지 않는 모바일 사용자까지 가세하면 IT 자산의 품목을 완벽히 파악, 관리하기가 매우 어려워집니다. 지금까지 이러한 요인은 품목 관리 도구, 특히 원격 시나리오 또는 네트워크 연결에 연결되지 않은 시나리오를 지원하지 않는 구내 구축 솔루션들에 매우 큰 부담으로 작용해왔습니다.
그러나 전부는 아니더라도 대부분의 PC가 인터넷에 연결되어 있다면, 사내 클라이언트 서버 솔루션에 대한 연결을 보장하는 특별한 수단을 갖추지 않고도, 온라인 서비스를 통해 PC를 관리할 수 있습니다. 관리 업무를 수행하기 위한 서비스를 안전한 보안 인터넷 연결을 통해 똑같이 액세스할 수 있으므로 인터넷을 이용할 수 있는 어느 곳에서라도 관리 계정을 통해 모든 PC를 관리할 수 있는 것입니다.
쉽게 배포할 수 있을 뿐만 아니라 온라인 시스템에 계정만 만들면 바로 사용을 시작할 수 있습니다. 환경에 서버를 설치할 필요가 없으며 큰 비용을 들여 네트워크 인프라와 소프트웨어를 새로 구축할 필요도 없습니다. 결국 관리 업무 부담과 재정적 투자 부담을 모두 줄이는 효과를 얻을 수 있습니다. 서비스 계약에 향후 신규 버전에 관한 조건이 포함되는 경우가 많아 업그레이드 계획 관리에 대해서도 신경 쓸 필요가 없으므로 상시 지원 업무 역시 보다 쉬워집니다.

서비스의 이용
온라인 커뮤니티 육성
Asset Inventory Service 및 System Center Online 서비스는 온라인 서비스의 발전에 영향을 미칠 수 있는 강력한 사용자 커뮤니티 육성을 촉진하고 있습니다. 소프트웨어 카탈로그는 사용자 커뮤니티가 진정한 WIKI 방식으로 기여할 수 있는 뛰어난 사례의 하나입니다. 서비스 사용자들은 소프트웨어 카탈로그를 통해 언제든 의견을 제시하고 문제를 바로잡고 조언할 수 있습니다.
향후 이 카탈로그 서비스는 최종 사용자들이 소프트웨어 구입을 위해 사전 조사를 실시할 때에도 중요한 정보의 원천이 될 수 있을 것입니다. 전체 서비스에서 익명 통계를 집계하여 소프트웨어 및 하드웨어 제품의 채택률을 파악할 수 있으며, 소프트웨어 및 하드웨어 제품을 선택하는 최종 사용자에게 유용한 정보를 제공하게 될 것입니다.
또한 커뮤니티는 특정한 업무 요구 사항을 충족하기 위해 우선 처리해야 할 부분에 대한 의견을 제시함으로써 이 서비스의 전체적 방향을 잡아주는 역할도 수행할 것입니다.

Microsoft System Center Online에서는 온라인 데스크톱 관리 서비스를 제공하기 위해 단기적으로 Asset Inventory Service는 물론, 장기적으로 다른 서비스까지 지원할 플랫폼을 구축하고 있습니다. AIS 서비스는 보안성과 확장성, 신뢰성을 염두에 두고 설계되었습니다. AIS는 모든 서버가 Microsoft 데이터 센터에 있는 완전한 호스팅형 솔루션입니다. 이 솔루션을 구축하려면, 품목 관리에 포함하고자 하는 각 클라이언트 PC에 작은 용량의 소프트웨어를 설치해야 합니다.
Asset Inventory Service는 Microsoft.com을 관리하는 직원들이 관리합니다. 이 서비스는 웹 서비스를 이용하여 고객별로 데이터의 보안과 기밀을 보장하고, 클라이언트 응용 프로그램과 웹 응용 프로그램을 조합하여 고객 데이터를 저장하는 멀티테넌트(multi-tenant) 웹 응용 프로그램입니다. 고객사의 클라이언트에서 실행되는 에이전트 프로그램은 소프트웨어 품목 정보를 Microsoft IIS 웹 서비스에 업로드합니다. 상호 인증 방식의 SSL은 고객 데이터, 클라이언트와 서비스 사이의 통신, AIS 웹 사이트, 저장 용도로 SQL Server™를 사용하는 사이트를 보호합니다.
고객은 Windows Live™ ID 계정을 사용하여 인증을 받고, 서비스에 로그인하여 계정을 관리하고 보고서를 조회합니다. 또한 고객 웹 사이트에서는 SSL을 사용하여 고객 데이터를 보호하고 SQL Server Reporting Services를 통해 보고서를 생성합니다. 높은 가용성을 유지하기 위해 SQL Server 데이터베이스는 미러링되고 웹 사이트에는 부하 분산이 이루어집니다. 또한 고도의 확장성을 위해 품목 데이터는 확장 단위로 분할됩니다.
Microsoft 볼륨 라이선스 계약을 통해 Microsoft Desktop Optimization Pack 라이선스를 구입하면 AIS(Asset Inventory Service)에 가입됩니다. 그리고 Microsoft 볼륨 라이선스 서비스 사이트(licensing.microsoft.com)에서 Asset Inventory Service 가입 자격을 인증받을 수 있습니다. AIS 서비스 가입 자격을 인증받고 로그인하려면 유효한 Windows Live ID가 필요합니다.
인증 과정에서 계약 관리자는 Windows Live ID를 명시하여 Asset Inventory Service 가입 관리자를 지정합니다. 가입 관리자는 자신의 Windows Live ID로 AIS에 로그인하여 AIS 인증 프로세스를 완료합니다. 그리고 다른 사용자의 Windows Live ID를 지정하여 이들을 서비스에 추가할 수 있습니다.

품목 관리 에이전트
각 PC에 설치되는 클라이언트는 크기가 작으며 Windows® Installer(MSI) 형태로 패키지가 구성되어 배포 및 설치가 쉽습니다. 온라인 서비스를 통해 에이전트 설치 프로그램을 다운로드하고 클라이언트 배포 과정을 관리할 수 있습니다. 그림 2에서 관리 및 지원 인터페이스를 볼 수 있습니다. 이 에이전트 프로그램은 Windows Update 에이전트와 유사하게 System Center Online 서버와 주기적으로 통신합니다. 이를 통해 미리 지정된 빈도로 품목 프로필을 업데이트하고 새로운 버전의 에이전트가 있으면 자동으로 업데이트합니다.
그림 2 계정 관리 및 클라이언트 배포
그림 2 계정 관리 및 클라이언트 배포
품목 관리 작업은 일정에 따라 자동으로 실행되므로 사용자가 따로 관여할 필요가 없습니다. 하지만 필요에 따라 사용자가 직접 품목 관리 작업을 시작할 수 있는 옵션도 제공됩니다. 에이전트가 처음으로 서비스에 접속하면 PKI(공개 키 인프라) 자격 증명을 사용하여 고객의 ID를 서비스 측에 제시하고 에이전트가 실행되는 컴퓨터의 고유 ID를 생성합니다. 에이전트 자체는 일정에 의해서만 실행되며, 사용자의 작업을 방해하지 않도록 설계되었기 때문에 최소한의 자원으로 백그라운드로 실행됩니다. 업로드되는 데이터 파일은 크기가 작아서 네트워크 트래픽에 부담을 주지 않습니다.
품목 관리 프로세스 자체는 효율적으로 간단히 이루어집니다. 컴퓨터에 존재하는 모든 실행 파일을 일일이 검사하여 사용자의 생산성을 저해하는 기존의 관리 시스템과 달리, 이 에이전트는 레지스트리 항목과 MSI 데이터베이스, 그리고 기타 소스만 검사하여 설치 정보를 확보합니다. 이 프로세스를 통해 얻어지는 소프트웨어 품목 데이터에는 항목의 식별과 분류에 도움이 되는 메타데이터를 포함하는 알아보기 쉬운 이름이 사용되므로, 다양한 종류의 소프트웨어 자산 관리 작업에 활용할 수 있습니다.

보고 서비스
업로드된 품목 데이터는 보고서에 표시할 수 있도록 식별 및 카탈로그 작성 프로세스를 거치게 됩니다. 품목 데이터는 중앙의 소프트웨어 카탈로그와의 대조를 통해 범주별로 분류됩니다. 이는 이 서비스의 가장 중요한 기능 가운데 하나입니다. 즉, 모든 고객의 소프트웨어 품목 데이터를 바탕으로 중앙의 소프트웨어 카탈로그에 고유 서명이 기록됩니다. Microsoft의 연구 팀에서는 기밀이 아닌 공개 소프트웨어 서명을 검토하고, 소프트웨어 제품군 및 범주에 대한 체계적 분류법을 활용하여 종류와 기능에 따라 응용 프로그램을 분류합니다. 이러한 범주 분류는 사용자가 특정 유형의 소프트웨어에 관심을 가지고 있을 경우(예: 바이러스 백신 응용 프로그램만 보려는 경우) 신속히 해당 소프트웨어만 표시할 수 있도록 하여 지능형 보고 수준을 한 단계 높입니다.
또한 소프트웨어 서명은 보고서에 표시되는 데이터를 일관되게 통일하는 데에도 도움이 됩니다. 예를 들어 게사자의 이름만 하더라도 다양한 형식으로 존재할 수 있습니다. 응용 프로그램에 따라 동일한 게시자 이름이 Contoso Software와 Contoso로 다르게 표시될 수 있으므로 같은 보고서에 서로 다른 업체로 표시될 수 있습니다. 이 경우 게시자 이름과 응용 프로그램 이름을 일관되게 통일한다면 그러한 이름을 기준으로 보고 내용을 정확하게 구성하고 의미 있는 방식으로 데이터를 표시하는 기능이 향상될 것입니다.
필터와 그룹 분류 기능을 적용하여 원하는 데이터 집합이 구성되면 SQL Server Reporting Services를 통해 CSV 파일, Microsoft Word 문서, Microsoft Excel® 스프레드시트, PDF 파일 등 지원되는 다양한 형식으로 내보낼 수 있습니다(그림 3 참고). 이를 이용하여 추가로 외부 분석 및 조작을 수행하거나 다른 전사적 관리 시스템에 입력할 수 있습니다.
그림 3 품목 관리 결과 보고
그림 3 품목 관리 결과 보고
향후 서비스에서는 Microsoft 라이선스 처리 방식을 개선하여 사용자가 보다 쉽게 이용할 수 있도록 하는 새로운 기능도 제공할 예정입니다. 사용자는 자신의 볼륨 라이선스 계약 정보를 업로드할 수 있게 되고, 업로드된 계약 정보는 Microsoft Customer License Position Repository에서 사용자의 라이선스 자격 정보를 조회하는 데 사용될 것입니다. 이 라이선스 자격 데이터는 라이선스를 기준으로 설치할 수 있는 것으로 확인된 모든 Micorosoft 소프트웨어와 해당 라이선스 수량을 요약한 명세서에 채워집니다.
품목 관리 과정에서 수집된 제품 ID를 사용하면 설치된 소프트웨어를 볼륨 라이선스, 일반 판매, OEM 등 채널별로 더 자세히 분류할 수 있습니다. 이 기능은 Asset Inventory Service의 다음 버전에서 제공될 예정입니다.

향후 방향
AIS는 System Center Online에서 내놓은 첫 번째 서비스이며, 앞으로도 새로운 서비스가 계속 제공될 것입니다. 앞서 언급했듯이, System Center Online은 모든 데스크톱 관리 서비스를 온라인 서비스 형태로 완벽하게 제공한다는 장기적인 목표를 갖고 있습니다.
현재 고려 중인 향후 서비스로는 하드웨어 및 소프트웨어 품목 파악 및 추적 기능을 제공하는 IT 자산 관리 서비스, 인터넷을 통해 WSUS(Windows Software Update Services)와 유사한 기능을 제공하는 소프트웨어 업데이트 및 배포 서비스, 온라인형/구내형(on-premise) 복합 서비스 등이 있습니다. 그 외에도 이러한 유형의 시나리오에서 효과가 있을 것으로 여겨지는 다양한 데스크톱 관리 서비스가 검토되고 있습니다.
Microsoft Asset Inventory Service에 대한 자세한 내용은 microsoft.com/windows/products/windowsvista/enterprise/ais.mspx 페이지를 참조하시기 바랍니다.

Paul Bourgeau는 System Center Online 팀의 프로그램 관리자로, Microsoft가 Assetmetrix를 인수하면서 합류했습니다.


 Group Policy: 그룹 정책용 ADM 및 ADMX 템플릿 살펴보기
Group Policy Jeremy Moskowitz

그룹 정책용 ADM 및 ADMX 템플릿 살펴보기
한 눈에 보기:
  • 그룹 정책 템플릿의 종류
  • 적절하거나 부적절한 정책 키
  • ADM 템플릿 보기
  • ADM을 ADMX로 변환

ADM 파일을 좋아하는 사람도 있고 싫어하는 사람도 있습니다. 혹은 두 가지 감정을 모두 가지고 있을 수도 있습니다. ADM 파일은 필수적으로 사용해야 하는 파일이지만 혼란스러운 점이 많기 때문입니다. 게다가 혼란만 가중시키는 것처럼 보일 수 있는 새로운 형식인 ADMX 파일도 있습니다. 이제 이 혼란을 정리해 보겠습니다.

왜 ADM 파일이 필요한가?
그룹 정책은 넓은 영역을 포괄합니다. GPOE(그룹 정책 개체 편집기)를 조금 깊게 살펴보면 그룹 정책으로 할 수 있는 것이 많음을 발견할 수 있습니다. 예를 들어 소프트웨어 제한 정책, 그룹 정책 소프트웨어 설치, 폴더 리디렉션 그리고 가장 많이 사용하는 관리 템플릿을 볼 수 있습니다. 관리 템플릿 노드는 사용자와 컴퓨터 쪽 모두에 나타납니다. 이미 알고 있겠지만 사용자는 사용자 쪽 정책 설정만 사용할 수 있고 컴퓨터는 컴퓨터 쪽 정책 설정만 사용할 수 있습니다.
그러면 관리 템플릿 안에 있는 이러한 모든 설정은 어디에서 온 것일까요? 새 응용 프로그램이 "탄생"한 경우 조작 가능한 몇 가지 설정이 있습니다. 바로 이 부분에서 ADM 파일이 역할을 합니다. 이 파일에는 관리자가 정의한 설정을 승인할 수 있는 응용 프로그램 영역이 정리되어 있습니다. 하지만 ADM 파일은 응용 프로그램 내에서 레지스트리 설정만 처리하므로 곧바로 제한됩니다. 그렇더라도 응용 프로그램에서는 설정을 .ini 파일, .js 파일, .xml 파일 및 데이터베이스 등과 같은 다른 영역에 저장할 수 있습니다.

기본 ADM 파일
그렇다면 컴퓨터 구성 | 관리 템플릿 및 사용자 구성 | 관리 템플릿에 대한 모든 기본 정책 설정이 처음에 어떻게 적용될까요? GPOE에서 "Administrative Templates(관리 템플릿)"을 마우스 오른쪽 단추로 클릭하고 사용자 또는 컴퓨터 쪽에서 "Add/Remove Templates(템플릿 추가/제거)"를 선택하면 그림 1처럼 표준 구성을 구성하는 기본 템플릿이 표시됩니다.
그림 1 기본 관리 템플릿
그림 1 기본 관리 템플릿
이 파일은 다음과 같이 구성됩니다.
  • Conf.adm - NetMeeting® 설정
  • Inetres.adm - 연결, 도구 모음 및 도구 모음 설정을 비롯한 Internet Explorer® 설정. 이 설정은 Internet Explorer에서 인터넷 옵션을 클릭하여 사용할 수 있는 옵션에 해당합니다.
  • System.adm - 운영 체제 변경 및 설정. 컴퓨터 및 사용자 관리 템플릿 설정의 대부분이 이 ADM 템플릿에 들어 있습니다.
  • Wmplayer.adm - Windows Media® Player 9 설정
  • Wuau.adm - 클라이언트의 Windows® Update 및/또는 Windows Server® Update Services 서버 액세스를 제어합니다.

새 ADM 템플릿 파일 추가
Microsoft 및 타사 도구로 한계 극복
ADM 및 ADMX 파일은 매우 유용합니다. 두 파일을 사용하여 몇 가지 정보를 정의 파일에 넣고 대상 응용 프로그램을 제어할 수 있기 때문입니다. 하지만 ADM 및 ADMX 파일에는 제한이 있습니다. 구체적으로 이들 파일은 다음과 같은 작업을 수행할 수 없습니다.
  • HKEY_LOCAL_MACHINE 및 HKEY_Current_User 이외의 레지스트리 하이브에는 액세스할 수 없습니다. 다른 레지스트리 하이브에 액세스해야 하는 경우에는 ADM 또는 ADMX 파일로 이를 해결할 수 없습니다.
  • REG_Binary 값에 무언가를 추가할 수 없습니다.
  • "한 번만 실행"되도록 설정할 수 없습니다.
  • 그룹 정책을 새로 고칠 때 "항상 다시 적용"되도록 설정할 수 없습니다.
  • ADM 및 ADMX 파일이 부적절한 키에 기록을 하더라도 레지스트리에 값이 영구적으로 기록됩니다. 따라서 사용자가 SOM(관리 범위)에서 벗어나거나 GPO가 삭제되더라도 값은 지속됩니다.
이러한 제한을 극복하기 위해 Microsoft 및 다른 업체 몇 곳에서는 이 문제에 도움이 되는 솔루션을 제공합니다. 최근 Microsoft는 DesktopStandard를 인수하고 브랜드를 변경하여 DesktopStandard Registry Extension을 다시 출시했습니다. 이 도구를 사용하면 GPOE 내에서 마법사 인터페이스를 사용하여 대상 시스템에서 관리하고자 하는 특정 레지스트리 값을 지정할 수 있습니다.
Registry Extension 도구를 포함하여 DesktopStandard PolicyMaker 기술은 이제 이름이 그룹 정책 기본 설정으로 변경되어 Windows Server 2008에 포함되었습니다. 이 그룹 정책 기본 설정을 사용하여 관리자는 그룹 정책으로는 구성할 수 없었던 응용 프로그램 또는 Windows 구성 요소를 구성하고 풍부한 대상 지정 규칙 집합을 기반으로 특정 사용자 또는 컴퓨터에 적용할 수 있습니다. 그룹 정책 기본 설정은 Windows Server 2008의 그룹 정책 관리 콘솔 및 고급 그룹 정책 관리에 완전하게 통합되었습니다.
그룹 정책 기본 설정에 대해서는 이번 달 TechNet Magazine에 게시된 Derek Melber의 기사인 "고급 그룹 정책 관리에 대해 자세히 알아보기"에서 자세히 알아볼 수 있습니다.

쉬운 방법부터 알아보겠습니다. 먼저 사용하고자 하는 ADM 템플릿을 구합니다. GPanswers.com에서(이외에도 많은 흥미로운 내용이 있음) 다운로드한 템플릿을 사용할 수도 있고 Microsoft 웹 사이트에 있는 Office 2003 또는 Office 2007용 ADM 파일을 이용할 수도 있습니다.
그림 1에서처럼 "Administrative Templates(관리 템플릿)"을 마우스 오른쪽 단추로 클릭하고 "Add(추가)"를 클릭하여 템플릿을 추가합니다. 기본적으로 Windows에서는 \Windows\inf 디렉터리에서 템플릿을 찾지만 다른 곳에 저장해도 됩니다. 대개 잘 모르고 있지만, ADM 템플릿이 원래 저장 지점에서 추가되면 해당 ADM 템플릿은 GPO(그룹 정책 개체) 자체의 내용에도 추가됩니다.
필자는 이 기사를 위해 GPanswers.com을 방문하여 nopassport.adm을 다운로드했습니다. 처음에는 이 템플릿 파일을 c:\temp 디렉터리에 저장했습니다. 이 ADM 템플릿을 사용하면 사용자가 Windows XP 컴퓨터에 처음 로그인할 때 나타나는 "Passport를 추가하시겠습니까?"라는 메시지를 없앨 수 있습니다.
필자는 Office 2003 ADM 템플릿도 다운로드하여 c:\temp에 저장했습니다. 하지만 이 디렉터리에 계속 존재하지는 않습니다. 그림 2를 보면 nopassport.adm과 Word11.adm을 추가한 것을 볼 수 있습니다. 그림에서 보면 "Add/Remove Templates(템플릿 추가/제거)" 창의 기본 템플릿 목록에 추가되어 있습니다.
그림 2 GPO에 추가된 ADM 파일
그림 2 GPO에 추가된 ADM 파일
이제 GPO 자체(구체적으로 \\domaincontroller\SYSVOL\domainname\Policies\GUID\ADM 디렉터리에 있는)의 파일 기반 부분을 보면 nopassport.adm과 Word11.adm 파일이 그림 2에서처럼 GPO의 일부가 되었음을 볼 수 있습니다.
이러한 템플릿이 왜 GPO에 추가되었을까요? 다른 관리 스테이션에서 이 GPO를 편집하려고 할 때 ADM 파일 안에 있는 설정을 볼 수 있게 하기 위해서입니다.

방금 로드했는데 볼 수 없는 이유
+
그림 14중앙 저장소에 ADMX 파일 복사
ADM-ADMX 변환기 도구는 최근 1.2 버전으로 업데이트되었습니다. 이 버전에서는 여러 변환 버그가 수정되었고 변환 시간 도중 표시되는 유용한 경고 메시지가 추가되었습니다. ADM-ADMX 변환기 도구를 사용해 본 적이 있지만 수정할 수 없는 오류 메시지 때문에 사용하기를 포기했다면 이제 1.2 버전을 다운로드하여 다시 시도해 볼 것을 권장합니다.
변환된 ADM 파일은 실제로 ADMX(언어 중립적) 파일과 ADML(언어 특정) 파일의 두 파일로 구성됩니다. 이 단계에서 결과 파일을 중앙 저장소에 넣거나 로컬 시스템에서 테스트할 수 있습니다. 하지만 이 ADMX 템플릿 안에 포함된 정책 설정을 실제로 보려면 여전히 그림 4에서 했던 작업을 수행해야 합니다. 즉 보기, 필터링을 차례로 클릭한 다음 "완전히 관리가 가능한 정책 설정만 표시"의 선택을 해제합니다. 이 ADMX 파일 안에 포함된 설정이 앞서 언급한 적절한 정책 키 중 하나에 기록하지 않기 때문입니다.

마무리
이상적인 상태는 ADMX 파일만 사용하고 중앙 저장소를 이용하는 것입니다. 하지만 이렇게 하려면 현재 ADM 파일을 모두 ADMX로 변환하고, 모든 관리 스테이션을 Windows Vista(또는 Windows Server 2008)로 전환하고, Windows Vista 이전 시스템에서는 GPO 편집을 중지하도록 해야 합니다.
이 세 단계를 완료하면 얼마간의 ADM 파일이 제거됩니다. 이 단계에 GPO 내의 ADM 파일은 DC의 SYSVOL 안에서 공간만 차지하고 있습니다. ADMX를 이해했으면 SYSVOL 내에서 GPO의 GPT 안에 포함된 ADM을 삭제해도 됩니다. 이제 더 이상 사용되지 않기 때문입니다. 한때는 제 역할을 해냈지만 이제는 아닙니다. 이런 작업은 수동으로 하거나 스크립트로 할 수 있습니다. 하지만 이렇게 하기 전에 이 단계를 완료하지 않으면 심각한 실수가 된다는 점을 주의하십시오. 따라서 ADM 파일이 없어도 된다는 확신이 있을 때만 삭제하십시오.
ADM, ADMX 및 ADML 파일에 대한 자세한 내용은 go.microsoft.com/fwlink/?LinkId=105019의 그룹 정책 ADMX 파일 관리 단계별 가이드 및 go.microsoft.com/fwlink/?LinkId=105032의 ADMX 기술 검토를 참조하십시오. 또한 GPanswers.com/newsletter에서 GPanswers.com 뉴스레터에 등록하고 GPanswers.com/blog의 블로그를 자주 방문하시기 바랍니다.

Jeremy Moskowitz는 그룹 정책 분야의 MCSE이자 MVP로, 그룹 정책과 관련된 커뮤니티 포럼인 GPanswers.com을 운영하고 있으며 그룹 정책에 관한 집중적인 교육 과정도 진행하고 있습니다. 그의 최근 저서로는 Group Policy: Management, Troubleshooting, and Security(Sybex, 2007)가 있습니다. www.GPanswers.com에서 Jeremy에게 연락할 수 있습니다.


 Group Policy: 그룹 정책 성능 최적화
Group Policy Darren Mar-Elia

그룹 정책 성능 최적화
한 눈에 보기:
  • 모놀리식 GPO와 기능적 GPO
  • 그룹 정책 항목 처리 방법
  • GP 변경 시 나타나는 현상

"성능 측면에서 볼 때 적은 수의 큰 GPO를 사용하는 것과 여러 개의 작은 GPO를 사용하는 것 중 어떤 것이 유리합니까?"라는 질문을 자주 받습니다. 이 문서에서는 이 질문과 그룹 정책 디자인 및 성능과 관련한 여러 가지 내용들을 살펴보겠습니다. 대부분의 포괄적인 질문과 마찬가지로
이 질문에 대해서도 "상황에 따라 다릅니다."라고 답할 수밖에 없습니다. 회피성 답변처럼 보일 수 있지만 여기서의 제 목표는 초보 사용자나 수백 개의 GPO가 있는 환경을 최적화하려는 사용자 모두가 충분한 정보를 바탕으로 그룹 정책 설계에 대한 결정을 내릴 수 있도록 그룹 정책 처리의 기초가 되는 메커니즘을 설명하는 것입니다.

모놀리식 GPO와 기능적 GPO
우선 GPO를 구현할 수 있는 여러 가지 방법부터 살펴보겠습니다. "모놀리식"과 "기능적"이라는 용어는 설계 방식을 가리킵니다. 모놀리식 GPO에는 여러 영역의 설정이 포함됩니다. 예를 들어 모놀리식 GPO의 경우 관리 템플릿, Internet Explorer 유지 관리 및 소프트웨어 설치 정책의 설정이 모두 하나의 GPO에 포함될 수 있습니다. 이와 반대로 기능적 GPO는 일반적으로 한 가지 일만 수행합니다. 예를 들어 기능적 GPO는 소프트웨어를 설치하는 작업 또는 보안 설정을 적용하는 작업만 수행할 수 있습니다. 하나의 정책 설정만 들어 있는 기능적 GPO를 본 적도 있습니다. 하지만 이는 극단적인 경우입니다. 그림 1에서 각 방법의 장점과 단점을 일부 볼 수 있습니다.
Figure 1 모놀리식 GPO와 기능적 GPO 비교 (Close Figure 1)

문제 | 모놀리식 GPO | 기능적 GPO
위임/격리 | 각 GPO에 여러 영역의 설정이 포함될 수 있으며 설정 수준이 아니라 GPO 수준에서만 위임할 수 있기 때문에 상당히 까다롭습니다. | 각 GPO에 단일 정책 영역이 포함되므로 간단합니다. 예를 들어 소프트웨어 설치 GPO는 배포 관리자에게, 보안 GPO는 보안 담당자에게 위임할 수 있습니다.
관리 효율성 및 복잡성 | 각 GPO에 특정 영역의 모든 설정이 포함되므로 관리가 간단하고 쉬울 수 있습니다. | GPO가 더 많아지면 문제 추적을 위해 살펴볼 곳이 많아지며 특정 사용자나 컴퓨터에 대한 정책 집합을 결정하기가 더 복잡해지므로 어렵습니다.
성능 | 특정 클라이언트 쪽 확장의 경우 하나의 GPO가 변경되면 모든 확장을 해당 범위의 모든 GPO에 대해 실행해야 하므로 속도가 느릴 수 있습니다. | 사용 중인 GPO의 수와 변경 빈도에 따라 다릅니다. 모놀리식 GPO에 비교하면 동적 환경에서 성능이 더 좋을 수 있습니다.
여기서 볼 수 있듯이 모든 경우에 적합한 방법(모놀리식 또는 기능적)이 무엇인지에 대한 고정된 답은 존재하지 않습니다. 환경에 따라서는 두 가지 모두가 필요할 수도 있습니다. 예를 들어 전체 도메인에 대한 보안 정책을 작성할 때는 기능적 방법이 좋다고 판단할 수 있습니다. 보안 설정만 포함된 하나의 GPO가 있으면 해당 GPO의 제어를 보안 관리자에게 위임하고 다른 사람은 손대지 못하게 할 수 있습니다. 마찬가지로 GP 관리를 OU 관리자에게 위임하고 각 OU에 하나의 모놀리식 GPO를 설정하면 해당 관리자는 한 곳에서 자신의 모든 정책 설정을 관리할 수 있습니다. 이렇게 하면 관리의 복잡성이 줄어들고 특정 OU의 사용자 및 컴퓨터에 대해 작성되는 GPO의 수를 적절하게 조정할 수 있습니다.
그러면 이 높은 수준의 설계 결정 사항은 그룹 정책 처리의 성능에 어떤 영향을 주며 성능에 미치는 영향을 최소화할 수 있도록 GP 설계에 대해 현명한 의사 결정을 내리려면 어떻게 해야 할까요? 그룹 정책 인프라의 성능을 극대화하기 위한 첫 번째 단계는 그룹 정책 처리 방식을 구체적으로 이해하는 것입니다.

그룹 정책 처리 이해
그룹 정책 처리에는 Windows® 및 Active Directory® 인프라의 여러 부분이 관여하는 상호 작용이 복잡하게 얽혀 있습니다. 높은 수준에서 보면 그룹 정책 처리에는 두 가지 부분이 있습니다. 첫 번째는 핵심 또는 그룹 정책 인프라 처리입니다. 이 단계에서 Windows 그룹 정책 클라이언트는 가장 가까운 도메인 컨트롤러에 쿼리를 보내 DC에 대한 연결 속도, Active Directory 계층 구조에서의 위치(즉, 클라이언트가 속한 사이트, 도메인 및 OU) 및 컴퓨터 또는 현재 로그온한 사용자에게 적용되는 GPO를 확인합니다. (이 경우 클라이언트는 Active Directory 도메인에 참가하는 서버 또는 워크스테이션일 수 있음을 유의해야 합니다.) GPO의 목록이 작성되면 다음 단계는 CSE(클라이언트 쪽 확장) 처리입니다. CSE 단계에서는 등록된 각 CSE가 해당 영역에 설정이 구현된 GPO의 목록을 처리합니다. 예를 들어 레지스트리 또는 관리 템플릿 CSE가 모든 경우에 제일 먼저 실행되고 지정된 컴퓨터나 사용자에게 적용되며 그 안에서 레지스트리 정책이 구현된 모든 GPO를 처리합니다.
다음 목록에서는 클라이언트와 도메인 컨트롤러 간의 네트워크 상호 작용을 포함하여 그룹 정책 처리 주기가 진행되는 단계를 자세히 설명합니다. 그룹 정책은 컴퓨터와 사용자 모두에 적용된다는 점을 기억해야 합니다. 따라서 정책이 처리될 때마다(예: 그룹 정책을 백그라운드에서 새로 고치는 동안) 아래 열거한 주기가 컴퓨터와 해당 시스템에 현재 로그온한 사용자 계정 모두에 대해 반복됩니다. 이 두 가지에 적용되는 정책 집합이 서로 다를 수 있기 때문입니다. 이때 Windows에서는 컴퓨터와 사용자에 대해 동시에 처리 주기를 진행합니다. 각 주기는 그룹 정책 엔진 프로세스(Windows 2000, Windows XP 및 Windows Server® 2003에서는 Winlogon 프로세스, Windows Vista® 및 Windows Server 2008에서는 그룹 정책 클라이언트 서비스) 내의 서로 다른 스레드에서 실행됩니다.
GP 처리 절차는 다음 여섯 단계로 구성됩니다.
  1. 클라이언트가 사이트의 도메인 컨트롤러에 대해 ICMP(Internet Control Message Protocol) 저속 연결 검색을 수행하여 연결 속도를 확인합니다. Windows Vista에서는 저속 연결 검색에 ICMP가 사용되지 않고 대신 NLA(네트워크 위치 인식) 서비스가 사용됩니다.
  2. 클라이언트는 로컬 레지스트리에서 CSE 상태 정보를 읽어 어떤 GPO가 마지막으로 처리되었는지 확인합니다.
  3. 클라이언트는 LDAP를 사용하여 Active Directory 계층 구조 내 각 위치의 컨테이너 개체에서 Active Directory의 gpLink 특성을 검색합니다. OU 수준(중첩된 모든 OU 포함), 도메인 수준, Active Directory 사이트 수준의 순으로 검색을 수행합니다. 이 검색 결과에 따라 처리를 위해 평가해야 하는 GPO의 목록을 작성합니다.
  4. 그런 다음 Active Directory에서 각 GPO를 검색하여 클라이언트(사용자 또는 컴퓨터)에게 해당 GPO를 처리할 수 있는 권한이 있는지 확인합니다. 버전 번호, SYSVOL에서 GPO의 GPT(그룹 정책 템플릿) 위치 경로 및 해당 GPO에서 구현되는 CSE도 평가합니다.
  5. 다음으로 클라이언트는 SMB(서버 메시지 블록) 프로토콜을 사용하여 GPT의 내용을 읽고 gpt.ini 파일에서 GPO의 버전 번호를 가져옵니다. GPC(그룹 정책 컨테이너) 및 GPT의 버전 번호는 마지막 처리 주기 이후 GPO가 변경되었는지 여부를 확인하는 데 사용되는 한 가지 요소입니다.
  6. 각 CSE는 HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions에 등록된 순서대로 실행되며 마지막 처리 주기 이후 GPO가 변경된 경우(핵심 처리 중에 확인됨)에는 해당 CSE를 구현하는 GPO를 처리합니다. 또한 가능한 경우 각 CSE는 새로 고칠 때마다 RSOP(Resultant Set of User Policy) 데이터를 WMI(Windows Management Instrumentation)에 기록합니다.
이 프로세스를 자세히 살펴보고 성능에 어떤 영향을 미칠 수 있는지 알아보겠습니다. 우선 포그라운드 처리와 백그라운드 처리 사이에는 차이가 있습니다. 포그라운드 처리는 시스템 재시작 도중 컴퓨터에 대해, 그리고 사용자 로그온 도중 사용자에 대해 수행됩니다. 백그라운드 새로 고침은 기본적으로 90분에 최대 30분의 임의의 값을 더한 시간마다 워크스테이션 및 구성원 서버에서 수행되고, 도메인 컨트롤러에서는 기본적으로 5분 간격으로 수행됩니다. Windows Vista에서는 NLA 기반 새로 고침도 있습니다. 이는 도메인 컨트롤러에 대한 액세스 권한이 부족하여 그룹 정책 처리가 실패한 경우(예: 백그라운드 간격 발생 시 클라이언트가 오프라인일 때) 트리거되는 백그라운드 새로 고침 이벤트입니다. 이러한 구분이 왜 중요할까요? 기본적으로 소프트웨어 설치 및 폴더 리디렉션 CSE와 같은 특정 CSE는 백그라운드 새로 고침 도중에 실행되지 않기 때문입니다. 마찬가지로 로그온/로그오프 또는 시작/종료 스크립트도 백그라운드 새로 고침 도중에는 실행되지 않습니다.
이 프로세스의 1단계에서 필자는 저속 연결 검색 프로세스를 언급했습니다. Windows Vista 이전 시스템에서 이 프로세스는 클라이언트를 통해 ICMP로 도메인 컨트롤러에 ping을 실행하여 가용성과 연결 속도를 확인합니다. 계산된 연결 속도가 특정 임계값(기본값 500Kb/s)보다 낮아지면 저속 연결로 간주되며 소프트웨어 설치, 폴더 리디렉션 및 Internet Explorer 유지 관리와 같은 특정 CSE는 실행되지 않습니다. 이러한 모든 조건은 정책 구현에 대한 예상과 성능에 영향을 미칠 수 있습니다.
성능에 가장 큰 영향을 주는 정책 처리 주기의 측면은 아마 컴퓨터나 사용자에 적용되는 GPO가 변경되었는지 여부를 확인하는 논리일 것입니다. 그룹 정책 엔진에는 GP를 마지막으로 처리한 이후 컴퓨터나 사용자에 변경 사항이 없음을 알리는 기본 제공 최적화 기능이 있으며 이 경우 처리가 수행되지 않습니다. 이러한 방식은 특히 GP 환경이 정적인 경우에는 클라이언트가 정책을 처리하는 데 걸리는 시간에 큰 영향을 줄 수 있습니다. 이제 변경의 요인에 대해 더 자세히 알아보겠습니다.

그룹 정책 변경이 수행되는 시기
그렇다면 그룹 정책 처리의 측면에서 변경을 가져오는 요인은 무엇일까요? 여러 가지 요인이 있지만 가장 확실한 것은 GPO를 변경하면 해당 GPO를 처리하는 클라이언트가 변경을 감지하고 GPO를 다시 처리한다는 점입니다. 그러면 클라이언트는 GPO가 변경된 것을 어떻게 감지할까요? 클라이언트는 GPO 및 클라이언트 내의 버전 번호를 이용하여 감지합니다.
GPO는 Active Directory에서 각 도메인 안의 CN=Policies, CN=System 컨테이너에 저장되는 GPC와 SYSVOL에서 "Policies" 폴더 안에 저장되는 GPT의 두 가지로 구성됩니다. GPO의 각 부분에는 버전 번호가 있습니다. GPC의 경우 이 버전 번호는 GPC 개체의 versionNumber 특성에 저장됩니다. GPT의 경우에는 특정 GPT의 루트에 있는 gpt.ini 파일 안에 저장됩니다. 클라이언트에서는 지금까지 처리한 GPO의 버전 번호 레코드를 사용자 및 컴퓨터별로 레지스트리에 유지합니다. 이 버전 정보는 컴퓨터의 경우 HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\History에 저장되고 각 클라이언트의 사용자에 대해서는 HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\<SID of User>에 저장됩니다.
그룹 정책을 처리할 때 컴퓨터 또는 사용자에게 해당되는 모든 GPO의 버전 번호를 검사하여 이를 레지스트리에서 발견된 마지막 주기 도중 처리된 모든 버전 번호와 비교합니다. 현재 GPO의 버전 번호가 다른 경우에는(크거나 작은 경우 모두 포함) 현재 처리 주기 도중 해당 GPO가 처리됩니다. 버전 번호가 같은 경우에는 다른 변경 조건 중 하나가 일치할 때만 처리됩니다. 다른 변경 조건은 다음과 같습니다.
  • 사용자 또는 컴퓨터에 적용되는 GPO 목록의 변경(GPO 추가 또는 제거)
  • 사용자 또는 컴퓨터의 보안 그룹 구성원의 변경
  • GPO에 연결된 WMI 필터의 변경(WMI 필터 추가 또는 제거)
변경 조건 중 일치하는 것이 있으면 클라이언트는 주기 도중 정책을 다시 처리합니다. 하지만 성능에 큰 영향을 줄 수 있으므로 이 프로세스의 세부적인 면을 알아두어야 합니다. 특정 CSE에서 10개 중 1개의 GPO가 변경되었으면 해당 CSE에 대한 모든 GPO를 다시 처리해야 합니다. 처리는 CSE 단위로 수행되기 때문입니다. 하지만 CSE에서는 처리를 제어하는 우선 순위에 따라 정책을 처리해야 합니다. 즉, 로컬 GPO, 사이트에 연결된 GPO, 도메인에 연결된 GPO, OU에 연결된 GPO의 순서로 처리해야 합니다. 이 요구 사항을 감안하여 사용자에게 적용되는 GPO가 10개 있으며 각각 Active Directory 계층 구조의 서로 다른 수준에 연결되어 있다고 가정하겠습니다. 그리고 이 10개의 GPO 각각에서 관리 템플릿 정책 설정 몇 가지를 구현합니다. 이제 관리자가 새 관리 템플릿 정책 설정을 추가하여 도메인에 연결된 GPO를 변경합니다. 그러면 컴퓨터 또는 사용자는 정책을 처리할 때 변경된 GPO의 버전 번호가 마지막으로 처리된 버전 번호보다 크며 따라서 GPO를 다시 처리해야 한다는 것을 감지하게 됩니다. 하지만 GP 처리의 우선 순위를 유지하기 위해 모든 GPO에 적용되는 모든 관리 템플릿 설정을 처리해야 합니다. 따라서 하나의 GPO가 조금 변경되더라도 해당 클라이언트의 성능에 큰 영향을 미칠 수 있습니다.

모놀리식 GPO와 기능적 GPO의 성능 비교
처리 주기와 그룹 정책 환경에 대한 변경이 처리에 어떤 영향을 주는지 살펴보았으므로, 모놀리식 GPO와 기능적 GPO의 비교라는 주제로 돌아가서 각 방법이 성능에 어떤 영향을 주는지 알아보겠습니다.
그룹 정책 버전 관리의 작동 방식 때문에 모놀리식 GPO에는 잘 드러나지 않는 성능 저하 가능성이 있습니다. 그 이유가 명백한 것은 아니지만 그룹 정책 처리 안에 CSE별 버전 관리에 대한 개념이 없다는 사실을 짚고 넘어가야 합니다. 특정 사용자에게 적용되는 세 개의 GPO가 있다고 가정하겠습니다. 각 GPO에서 몇 가지 정책 영역을 구현한다는 점에서 모놀리식 GPO입니다. 예를 들어 각 GPO가 관리 템플릿 정책, 소프트웨어 설치 정책 및 폴더 리디렉션 정책을 구현한다고 가정해 보겠습니다. 이제 관리자가 이 GPO 중 하나에서 관리 템플릿 정책을 변경한 경우를 예로 들겠습니다. 이 변경으로 인해 버전 번호가 증가합니다. 그런 다음 사용자가 그룹 정책을 처리합니다. 관리 템플릿 CSE가 시작되고 GPO 중 하나가 변경되었음을 발견하여 이 세 GPO를 다시 처리합니다.
소프트웨어 설치 및 폴더 리디렉션 CSE가 실행될 때는 GPO 버전 번호도 확인하여 GPO 중 하나에 새 버전 번호가 있음을 인식합니다. 하지만 버전 번호로는 해당 GPO에서 어떤 정책 영역이 변경되었는지 알 수 없으므로 만약을 위해 세 GPO를 모두 처리합니다. 즉, 모놀리식 GPO 구현에서는 정책의 영역 중 하나를 변경하면 다른 영역에서 처리 작업이 수행될 수 있습니다.
소프트웨어 설치 또는 폴더 리디렉션 정책의 경우 해당 CSE는 실제로 어떠한 작업도 수행하지 않을 수 있습니다. 예를 들어 응용 프로그램을 한번 설치한 경우에는 다시 설치하지 않을 것이기 때문입니다. 하지만 중요한 점은 이 동작이 모든 CSE에 대해 수행될 수 있으므로 모놀리식 GPO를 설계할 때 이를 고려해야 한다는 점입니다. 자주 변경되는 정책 영역이 있을 때는 해당 정책 영역을 다른 정책 영역과 분리하여 구현하는 GPO를 사용하는 방법을 고려할 수 있습니다.
기능적 GPO의 관점에서 보면 성능 고려 사항은 더 명확합니다. 기능적 방법을 사용하는 경우 대개 특정 정책 설정에 대한 GPO가 더 많아지기 때문에 사용자 또는 컴퓨터별로 더 많은 GPO가 생성되며 이는 그룹 정책 엔진이 그룹 정책 처리의 핵심 단계 중에 해당 GPO를 열거할 때 시간이 더 많이 걸린다는 것을 의미합니다. 하지만 다음 섹션에서 설명하듯이 성능에 반드시 큰 영향을 미치는 것만은 아닙니다.

그룹 정책 성능 측정
결론적으로 그룹 정책 인프라의 성능과 관련하여 현명한 결정을 내리기 위해서는 그룹 정책이 실제 환경에서 수행될 때의 성능을 측정할 수 있어야 합니다. 처리 주기에 영향을 줄 수 있는 많은 요소들을 고려하면 그룹 정책 성능의 모델링이나 예측은 거의 불가능합니다. 이런 이유 때문에 GP 처리 성능이 문제가 되는지 파악할 때는 경험적 측정이 최선의 방법일 수 있습니다. 성능 저하의 요인은 무엇일까요? 성능 저하는 그룹 정책 처리가 사용자의 시스템 사용에 영향을 주는 모든 상황입니다. 이런 상황은 조직마다 다를 수 있지만 중요한 것은 문제가 있다는 것을 파악하는 것입니다.
그렇다면 특정 그룹 정책 처리 주기의 길이는 어떻게 측정할까요? 이 질문에 대한 답변 역시 간단하지 않습니다. Windows Vista 또는 Windows Server 2008을 사용 중이라면 이벤트 뷰어 작동 로그를 이용할 수 있습니다. 이벤트 뷰어의 응용 프로그램 및 서비스 로그\Microsoft\Windows\Group Policy\Operational에서 찾을 수 있는 그룹 정책 작동 로그를 통해 처리의 각 단계에 걸린 시간을 포함하여 그룹 정책 처리 주기의 각 단계를 측정할 수 있습니다(그림 2 참조).
그림 2 정책 처리 시간을 보여 주는 그룹 정책 작동 로그
그림 2 정책 처리 시간을 보여 주는 그룹 정책 작동 로그
하지만 Windows Vista 또는 Windows Server 2008 환경이 아니라면 정책 처리 시간을 측정하는 메커니즘은 더 간접적인 메커니즘입니다. 이 경우에는 userenv 상세 로깅( support.microsoft.com/kb/221833에서 Microsoft 지원 문서 참조)이 사용되도록 설정하고 파일에서 특정 처리 주기에 대한 타임스탬프를 확인하거나, 클라이언트에서 정책 처리의 시작 및 중지 시간을 나타내는 레지스트리 값을 사용할 수 있습니다. 이 값은 컴퓨터의 경우 다음 위치에 저장됩니다.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\Machine\Extension-List\
{00000000-0000-0000-0000-000000000000}
사용자의 경우에는 다음 위치에 저장됩니다.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\<SID of User>\Extension-List\
{00000000-0000-0000-0000-000000000000}
값은 FILETIME 형식으로 저장되며 일반 날짜 및 시간으로 변환해야 합니다. 또한 필자가 만든 무료 유틸리티인 GPTime.exe(gpoguy.com/tools.htm#GP_Time_Utility에서 다운로드 가능)를 사용해도 같은 정보를 얻을 수 있습니다.
Windows Vista 또는 Windows Server 2008을 사용하지 않는 경우 userenv 로그에 액세스하여 각 정책 처리 주기에 걸린 시간에 대한 귀중한 정보를 얻을 수 있습니다. 예를 들어 그림 3에서는 그룹 정책 처리의 핵심 단계 중 일부를 보여 주는 userenv 로그 일부를 볼 수 있습니다.
그림 3 userenv 로그의 일부분
그림 3 userenv 로그의 일부분
로그 파일의 각 줄에 타임스탬프가 포함되어 있는 것을 볼 수 있습니다. 그룹 정책 처리 주기의 핵심 부분은 "ProcessGPOs: Starting user Group Policy (Background) processing..."과 같은 내용이 표시되는 이벤트가 발생할 때 시작됩니다. 처리 주기의 CSE 부분은 "ProcessGPOs: Processing extension Registry."라는 줄이 보이는 시점에서 시작됩니다. 이 로그와 로그 안의 타임스탬프를 사용하여 정책 주기의 각 부분에 걸린 시간을 확인할 수 있습니다.

성능에 대한 전체적인 관찰
userenv 로그 파일을 충분히 살펴보았으면 패턴을 찾아보기 시작합니다. 정책 처리에 소요되는 시간을 예측할 수는 없지만 특정 처리 주기에서 시간이 걸린 부분에 대한 관찰을 시작할 수는 있습니다. 예를 들어 정책 처리 이벤트 도중 정책 변경이 처리되고 변경 때문에 CSE가 작업을 해야 하는 경우에는 GP 처리의 핵심 부분에 걸리는 시간은 일반적으로 CSE 부분에 비하면 훨씬 짧습니다.
대부분의 CSE는 처리의 핵심 부분보다 오래 실행되는 작업을 수행해야 하기 때문에 대부분의 정책 영역에서도 마찬가지입니다. 여기서 가장 많은 비용이 드는 작업은 Active Directory 및 SYSVOL에 대한 쿼리입니다. 예를 들어 핵심 처리에 걸리는 시간과 Microsoft® Office 설치를 실행하는 소프트웨어 설치 CSE에 드는 시간은 비교할 수 없을 정도입니다. 하지만 마지막 주기 이후 아무것도 변경되지 않은 정책의 일반적인 백그라운드 새로 고침의 경우 처리 주기의 핵심 부분에 걸리는 시간은 CSE 부분에 걸리는 시간과 거의 같습니다. 한 가지 예외는 레지스트리 정책 처리입니다. 특정 사용자 또는 컴퓨터에 대한 수십 또는 수백 개의 레지스트리 정책 설정이 있는 경우가 아니라면 이 처리는 속도가 꽤 빠릅니다.
또한 사용되지 않기 때문에 GPO의 컴퓨터 쪽 또는 사용자 쪽이 사용되지 않게 지정하더라도 정책 처리 성능에는 거의 영향을 미치지 않습니다. 정책 쪽이 사용되지 않는 경우 유일한 오버헤드는 이를 확인하기 위해 Active Directory를 쿼리하는 것이며, GPO의 해당 측면에 대해 CSE가 구현되었는지 여부를 확인하기 위한 쿼리와 동일한 쿼리를 수행해야 해제 옵션을 볼 수 있습니다. 어느 한 쪽을 해제하는 효과는 무시해도 좋을 정도입니다.

최적의 GP 성능을 위한 설계 제안
그룹 정책 처리 성능의 여러 측면을 살펴보았으므로 이제 성능에 직접 영향을 줄 수 있는 몇 가지 설계 권장 사항을 소개하겠습니다. 이는 다음 네 가지 핵심 사항으로 요약됩니다.
  1. GPO를 자주 변경할 때는 한 CSE에 대한 변경이 모든 CSE의 처리에 영향을 줄 수 있다는 점을 염두에 두십시오. 예를 들어 레지스트리 정책을 자주 변경할 계획인 경우, 변경 발생 시 다른 CSE도 처리되지 않도록 레지스트리 정책을 기능적 GPO(레지스트리 정책만 수행하는 GPO)에 넣는 것이 좋습니다.
  2. 몇 개의 GPO가 많다고 판단할 것인지 결정할 때는 정책 처리가 변경 도중에만 수행되며, 소프트웨어 설치, 폴더 리디렉션 또는 많은 레지스트리 정책이나 큰 파일 또는 레지스트리 트리에서 권한 설정과 같은 "고비용" CSE에 대부분의 시간이 소요된다는 것을 염두에 두십시오. 핵심 처리 도중 Active Directory에 GPO 목록을 쿼리하는 데 걸리는 시간은 처리 주기 중 가장 작은 부분일 경우가 많습니다. 따라서 특정 사용자에게 30개의 GPO가 적용되지만 레지스트리 정책을 자주 변경하지 않는 경우의 처리 시간은 정기적으로 고비용 CSE를 실행하는 5개의 GPO 처리 시간보다 짧습니다. 이러한 GPO는 자주 변경되기 때문입니다.
  3. 정책 처리 성능을 확실하게 저하시키는 동작은 피하는 것이 좋습니다. 예를 들어 GPO가 변경되지 않았더라도(컴퓨터 구성\관리 템플릿\시스템\그룹 정책 아래) CSE를 강제 처리하도록 정책을 설정할 수 있습니다. 하지만 이렇게 하면 각 주기 도중 예상 정책 처리 시간이 더 길어집니다.
  4. Windows XP 및 Windows Vista에서 빠른 로그온 최적화를 사용 중지할 때의(컴퓨터 구성\관리 템플릿\시스템\로그온\컴퓨터 시작 및 로그온 시 네트워크가 초기화될 때까지 항상 대기에서 정책을 사용으로 지정하여) 장단점을 잘 고려하십시오. 이 정책이 사용되도록 설정하면 포그라운드 처리가 비동기에서 동기 방식으로 전환됩니다. 즉, 사용자가 컴퓨터 및 데스크톱의 제어권을 가져오기 전에 컴퓨터와 사용자 정책의 실행이 완료되어야 한다는 것을 의미합니다. 하지만 소프트웨어 설치 및 폴더 리디렉션 정책이 적용되기 위해서는 두 번 이상의 다시 시작 또는 로그온을 요구하는 문제가 해결되기 때문에 유용할 수도 있습니다.

요약
그룹 정책 처리 성능을 정확하게 측정할 수는 없지만 몇 가지 조사를 통해 성능 문제를 완화시킬 수 있는 대안을 설계 프로세스에 도입할 수 있습니다.
처리 주기가 작동하는 방식과 시간이 많이 소요되는 부분을 이해하면 성능 문제 추적의 긴 여정을 시작할 수 있습니다. Windows Vista 또는 Windows Server 2008 작동 로그(이전 버전의 Windows에서는 userenv 로그)를 사용하여 처리 주기에 대한 측정 정보를 얻을 수 있습니다. CSE 처리의 다양한 특성과 CSE 관점에서 볼 때 정책의 변경 요인을 염두에 두십시오. 또한 변경이 많은 동적 환경에서는 모놀리식 GPO보다는 기능적 GPO가 적합하다는 점을 기억하십시오. 하지만 근본적으로는 그룹 정책은 Windows 환경을 더 쉽게 관리할 수 있도록 돕기 위해 설계된 기술입니다. 따라서 그 무엇보다도 비즈니스 요구 사항을 염두에 두고 그룹 정책을 설계해야 한다는 점을 유념해야 합니다. 여기서 언급한 몇 가지 성능 동작을 알아두면 이러한 목표를 달성하는 데 도움이 될 것입니다.

Darren Mar-Elia는 Microsoft 그룹 정책 MVP이며 유명한 그룹 정책 사이트인 www.gpoguy.com의 제작자이자 Microsoft Windows Group Policy Guide(Microsoft Press, 2005년)의 공동 저자이기도 합니다. 또한 SDM Software, Inc.의 CTO이자 설립자입니다. 문의 사항이 있으면 Darren@gpoguy.com으로 연락하십시오.


 Group Policy: 고급 그룹 정책 관리에 대해 자세히 알아보기
Group Policy Derek Melber

고급 그룹 정책 관리에 대해 자세히 알아보기
한 눈에 보기:
  • AGPM 설치 및 아키텍처
  • 오프라인으로 GPO 편집
  • AGPM을 사용한 변경 관리
  • 재해 복구

최근 Microsoft는 그룹 정책 개체를 전반적으로 관리할 수 있는 제품을 제작한 회사인 DesktopStandard를 인수했습니다. 제 생각으로는 Active Directory를 사용하는 모든 엔터프라이즈에서 이 도구, 즉 AGPM(고급 그룹 정책 관리)을 반드시 실행해야 한다고 봅니다.
AGPM은 오프라인으로 GPO(그룹 정책 개체) 편집, 변경 관리, 정책 업데이트에 대한 워크플로, 위임 등 수많은 기능을 제공합니다. 이 기사에서는 AGPM의 내부 작동 방식을 면밀히 살펴봄으로써 매우 뛰어나며 유용한 이 제품에 대해 자세히 알아보겠습니다.
우선 배경에 대해 조금 알려 드리는 것이 좋을 것 같습니다. AGPM은 원래 GPOVault라는 이름으로 알려져 있었으나 Microsoft에서 DesktopStandard를 인수한 후 이를 AGPM으로 변경하고 MDOP(Microsoft® Desktop Optimization Pack)에 추가했습니다. MDOP는 현재 Windows Vista® 데스크톱 라이선스가 Microsoft Software Assurance의 보장을 받는 사용자에게만 제공됩니다.
지금까지 여러 도구를 사용해 본 제 경험에 비춰 보았을 때 MDOP는 Microsoft에서 제공하는 가장 뛰어난 도구 중 하나임이 분명합니다. MDOP에는 다섯 가지 도구가 포함되어 있습니다. 이러한 도구는 개별적으로 사용해도 각각 뛰어난 기능을 제공하나 함께 사용하면 최고의 성능을 갖춘 유용한 기능을 얻을 수 있습니다. MDOP에 대한 자세한 내용은 MDOP 웹 사이트(windowsvista.com/optimizeddesktop)를 참조하십시오.

AGPM 설치 및 아키텍처
AGPM 설치는 서버 구성 요소 및 클라이언트(관리) 구성 요소로 구성되어 있으며 매우 가볍고 간편하도록 설계되었습니다. 서버 구성 요소는 도메인의 구성원 서버에 설치해야 하며 이러한 구성 요소는 Active Directory®, 스키마 또는 기타 모든 디렉터리 서비스에 영향을 주지 않습니다. 필요한 경우 AGPM을 도메인 컨트롤러에 설치할 수도 있습니다.
서버 구성 요소 설치에서는 도메인 기반 서비스 계정이 필요한 서비스를 설치하며 이 계정은 AGPM이 사용자를 대신하여 실제 프로덕션 그룹 정책 개체에 액세스하는 계정을 의미합니다. 또한 이 설치에는 위임 및 초기 GPO 관리와 같은 AGPM 내의 모든 설정을 제어하는 AGPM 관리자가 필요합니다.
클라이언트는 정상적인 관리 기능이 이미 수행되고 있는 Windows Vista 실행 컴퓨터에 설치해야 하며, 네트워크 및 Active Directory 관리자의 데스크톱에 주로 설치합니다. 이제 클라이언트에서 AGPM 서버에 대한 AGPM 설정 및 아카이브에 대한 연결이 설정되었음을 표시해야 합니다. AGPM 클라이언트는 GPMC(그룹 정책 관리 콘솔) 인터페이스를 사용하여 그림 1에서와 같이 Change Control(변경 제어) 노드로 이러한 사항을 표시합니다.
그림 1 사용 편의성을 위해 GPMC에 완전히 통합된 AGPM
그림 1 사용 편의성을 위해 GPMC에 완전히 통합된 AGPM
AGPM 클라이언트에서 액세스할 파일은 AGPM 서버에 기본 파일 형식으로 저장됩니다. 이 방법은 이러한 파일을 저장하는 가장 간단한 방법으로 이를 통해 전체 AGPM 아카이브를 쉽게 백업할 수 있습니다. 대부분의 AGPM 기능은 기본적으로 제공되는 GPMC API를 사용하므로 이를 통해 제품이 완벽하게 통합되어 사용자는 제품을 문제없이 사용할 수 있습니다. AGPM은 데이터베이스를 사용하지 않습니다. GPO는 단일 폴더에 저장되고 매니페스트가 아카이브 내에 있는 부모 GPO에 대한 모든 GPO의 상관 관계를 제어합니다. 이로 인해 모든 GPO는 고유 GUID를 갖게 되지만 프로덕션 환경에 배포 시에는 올바른 GUID가 GPO와 연결됩니다.

오프라인으로 AGPM 편집
AGPM의 가장 기본적인 기능은 프로덕션 환경 밖에서도 오프라인으로 GPO를 편집할 수 있는 것입니다. 기본 GPMC에서 GPO를 편집할 경우 잘못된 설정이 즉시 프로덕션 환경에 적용되어 막대한 피해를 일으킬 수 있다는 것은 이미 널리 알려진 문제입니다.
APGM에서는 GPO "제어"를 통해 GPO에 대한 오프라인 편집 작업을 처리합니다. 그림 2에서와 같이 제어되는 GPO는 프로덕션 환경에 대한 영향 없이 오프라인으로 편집할 수 있습니다.
그림 2 AGPM 아카이브에 저장되어 오프라인으로 편집이 가능한 제어되는 GPO
그림 2 AGPM 아카이브에 저장되어 오프라인으로 편집이 가능한 제어되는 GPO
GPO를 제어하는 방법은 매우 간단합니다. 그림 3과 같이 제어되지 않은 상태의 GPO는 아직 AGPM 아카이브와 연결되지 않은 모든 GPO를 나열합니다. 이러한 GPO 중 하나를 마우스 오른쪽 단추로 클릭하면 Control(제어)이 포함된 메뉴가 나타납니다. Control(제어) 메뉴 옵션을 선택하면 프로덕션 위치(도메인 컨트롤러에서 공유하는 시스템 볼륨 또는 SYSVOL)에서 해당 GPO가 복사되어 AGPM 아카이브에 저장됩니다. 여러 개의 GPO를 제어할 수도 있습니다. 여러 개의 GPO를 제어하려면 Shift 또는 Ctrl 키를 누른 채로 GPO를 선택하여 올바른 목록을 얻은 다음 마우스 오른쪽 단추를 클릭하여 Control(제어) 메뉴 옵션을 선택하면 됩니다. GPOE(그룹 정책 개체 편집기)를 사용하여 제어되는 GPO를 편집할 수도 있습니다. 이는 AGPM이 GPMC에 완전히 통합된 또 다른 방법입니다.
그림 3 Control(제어) 메뉴 옵션을 선택하여 아카이브에 저장할 수 있는 제어되지 않은 GPO
그림 3 Control(제어) 메뉴 옵션을 선택하여 아카이브에 저장할 수 있는 제어되지 않은 GPO

AGPM 관리 권한 위임
우선 GPMC를 사용하여 GPO 관리 권한을 위임할 수 있는 방법을 살펴보고 AGPM에서 권한 위임을 처리하는 방법에 대해 알아보겠습니다. GPMC에서는 사용자에게 다섯 가지 작업을 위임할 수 있습니다. GPO 만들기, GPO 연결, GPO 편집, GPO 관리, GPO 읽기가 이에 해당합니다.
이러한 위임 작업은 모두 GPMC 인터페이스 내에서 수행됩니다. 이러한 모든 위임 작업은 GPMC에서 각각의 노드와 연결되어 있는 Delegation(위임) 탭에 나열되는 사용자 및 그룹을 통해 제어됩니다. 이러한 위임을 통해 기존 GPO를 편집 및 관리할 수 있을 뿐만 아니라 새 GPO를 만들 수 있습니다.
GPMC에서 GPO를 만드는 작업은 Group Policy Objects(그룹 정책 개체) 노드와 연결된 Delegation(위임) 탭에서 처리됩니다(그림 4 참조). AGPM을 설치한 경우에는 GPO 만들기 권한이 있는 그룹 및 사용자 목록에 나열된 모든 사용자와 그룹을 제거할 수 있습니다. 단, Delegation(위임) 탭에서 GPO를 만들 수 있는 시스템, 컴퓨터 또는 컴퓨터 그룹은 제거하지 않아도 됩니다. 이제 GPO 만들기 작업은 AGPM 서비스를 제어하는 서비스 계정에 의해 처리됩니다. 이 계정은 AGPM 내에서 GPO 만들기 및 배포 권한을 위임받은 모든 사용자 및 그룹을 대신하여 GPO를 만들 수 있는 권한을 위임받습니다.
그림 4 GPMC의 Group Policy Objects(그룹 정책 개체) 노드에 있는 Delegation(위임) 탭의 계정 목록에 의해 제어되는 GPO 만들기 권한
그림 4 GPMC의 Group Policy Objects(그룹 정책 개체) 노드에 있는 Delegation(위임) 탭의 계정 목록에 의해 제어되는 GPO 만들기 권한
이러한 새로운 GPO 만들기 기능을 통해 역할을 분리하고 프로덕션 네트워크를 보호할 수 있습니다. 이론적으로 GPO는 AGPM 환경에서 프로덕션 환경으로 배포되기 전에 생성되고, 구성되고, 확인됩니다. 드문 경우이기는 하나 AGPM을 사용하지 않으면 잘못된 구성이 적용될 수 있습니다.
GPO 편집 및 관리와 관련된 권한 위임의 경우에도 마찬가지입니다. GPMC에서는 이러한 위임이 각 GPO와 연결된 Delegation(위임) 탭에서 구성됩니다(그림 5 참조).
그림 5 각 GPO와 개별적으로 연결된 GPO 편집 및 관리 권한
그림 5 각 GPO와 개별적으로 연결된 GPO 편집 및 관리 권한
AGPM을 설치한 경우에는 Group Policy Objects(그룹 정책 개체) 노드 아래에 나열된 각 GPO에서 이러한 위임을 제거해야 합니다. 이렇게 하면 AGPM 외부에 있는 모든 관리자가 GPO를 편집하지 못하도록 제한됩니다. 결과적으로 이러한 작업을 통해 GPO에 대한 모든 관리 작업(예: 오프라인으로 편집, 변경 관리, 재해 복구)이 AGPM에 위임됩니다.
AGPM 외부의 사용자 및 그룹이 GPO를 편집하지 못하도록 이러한 사용자와 그룹을 제거하는 작업은 직접 수행해야 합니다. AGPM 설치 및 구성 과정에서는 프로덕션 환경에서 GPO를 편집하지 못하도록 방지하기 위한 사용자 및 그룹 제거 작업을 수행하지 않습니다. AGPM 서비스를 제어하는 서비스 계정이 사용자를 대신하여 AGPM에서 프로덕션 GPO를 수정하므로 각 GPO의 Delegation(위임) 탭에 나열된 사용자 및 사용자 그룹은 제거하는 것이 좋습니다. 단, 컴퓨터 및 컴퓨터 그룹은 이러한 위임 탭에서 제거하지 않아도 됩니다.
GPMC에서 GPO에 대한 모든 편집 권한 위임이 제거되면 모든 관리자가 GPMC에서 GPO를 편집할 수 있는 기능을 사용할 수 없습니다(그림 6 참조).
그림 6 편집 권한 위임이 거부되어 GPMC에서 GPO를 편집할 수 없는 관리자
그림 6 편집 권한 위임이 거부되어 GPMC에서 GPO를 편집할 수 없는 관리자
구성을 마치려면 GPO 편집 권한이 필요한 모든 관리자를 AGPM의 올바른 ACL(액세스 제어 목록)에 추가해야 합니다. 관리자가 아카이브의 모든 GPO를 편집할 수 있어야 하는 경우 AGPM의 도메인 수준으로 편집 권한이 부여된 그룹에 해당 관리자의 사용자 계정을 추가해야 합니다(그림 7 참조). 관리자가 AGPM 아카이브의 일부 GPO만 편집할 수 있도록 제한하려면 이 구성을 각 GPO에 설정해야 합니다(그림 8 참조).
그림 7 아카이브의 모든 GPO 편집 권한을 구성할 수 있는 Domain Delegation(도메인 위임) 탭
그림 7 아카이브의 모든 GPO 편집 권한을 구성할 수 있는 Domain Delegation(도메인 위임) 탭
그림 8 각 GPO의 ACL에서 구성해야 하는 개별 GPO 편집 권한 설정
그림 8 각 GPO의 ACL에서 구성해야 하는 개별 GPO 편집 권한 설정

AGPM GPO 변경 관리
AGPM의 뛰어난 장점 중 하나는 아카이브 내에 있는 GPO의 모든 변경 사항을 추적할 수 있는 기능이 있다는 점입니다. 이 기능은 자동 프로세스이므로 설정, 구성 및 관리할 필요가 없습니다. AGPM 클라이언트 인터페이스를 통해 GPO를 관리하는 동안 모든 변경 사항이 백그라운드에서 추적됩니다.
이는 기본 GPMC에서 GPO 관리를 처리하는 방법이 상당히 향상된 기능입니다. 기본 GPMC에는 GPO의 변경 사항을 추적할 수 있는 기능이 자동화되어 있지 않으며 기본 제공되지도 않습니다. 이는 수년간 대부분의 그룹 정책 관리자들이 제기해 온 문제로 이제 이 문제가 해결되었습니다.
AGPM 변경 관리 기능은 GPO에 발생할 수 있는 모든 중요 수정 내용을 추적합니다. 변경 관리 시스템에서는 GPO의 변경 사항 이외에도 감사 또는 전반적인 관리 추적 환경을 지원합니다. 변경 관리 시스템은 GPO가 편집되거나 변경될 때마다 GPO가 수정된 날짜 및 시간, 변경한 사용자, 원래 GPO 설정, GPO 설정의 수정 내용 등의 세부 사항을 모니터링, 추적 및 문서화합니다.
모든 변경 사항 추적은 끊임없이 이루어지므로 어떤 작업으로 인해 자동 추적이 실행되었는지 파악하는 것이 중요합니다. AGPM 클라이언트 인터페이스에서 Controlled(제어됨) 탭 아래에 있는 GPO를 마우스 오른쪽 단추로 클릭한 다음 Check-out(체크 아웃) 메뉴 옵션을 선택합니다(그림 9 참조).
그림 9 GPO를 체크 아웃하면 자동으로 실행되는 변경 추적 프로세스
그림 9 GPO를 체크 아웃하면 자동으로 실행되는 변경 추적 프로세스
이 절차는 GPO를 편집하려는 경우 실행해야 하며 이에 대해서는 다음 섹션에서 설명하도록 하겠습니다. GPO가 체크 아웃된 후 즉시 아무런 변경 사항 없이 체크 인된 경우에도 해당 작업에 대한 아카이브가 생성됩니다. 엔터프라이즈의 경우 GPO가 매우 중요한 요소이므로 이 도구에서는 변경이 발생할 수 있는 가능성까지 포착하여 추적합니다.
AGPM에서는 GPO를 변경한 특정 관리자에 대한 GPO 변경 사항 추적 메커니즘이 필요하므로 체크 아웃 절차를 반드시 실행해야 합니다. 이 경우 두 명의 관리자가 동시에 같은 GPO를 체크 아웃할 수 없습니다. 관리자가 GPO를 체크 아웃한 후 다시 체크 인하지 못한 경우 기본 제공 메커니즘을 통해 AGPM 관리자가 해당 GPO를 체크 인할 수 있습니다.

AGPM GPO 편집
AGPM 클라이언트를 설치하면 AGPM 아카이브에 액세스할 수 있습니다. AGPM 도구에서 편집 권한이나 모든 권한을 위임받은 경우 저장된 GPO를 편집할 수 있습니다. GPO를 체크 아웃한 후 마우스 오른쪽 단추로 클릭한 다음 Edit(편집) 메뉴 옵션을 선택하면 편집할 수 있습니다. (참고: AGPM 아카이브의 일부 GPO만 편집할 수 있는 경우 아카이브의 모든 GPO가 아닌 일부 GPO에 대한 권한만 위임받은 것일 수 있습니다.)
DesktopStandard를 인수하면서 Microsoft는 PolicyMaker도 인수했습니다. 이는 현재 그룹 정책 기본 설정으로 이름이 변경되었습니다. 이러한 그룹 정책 기능 집합은 Windows Server® 2008에서 제공되는 GPMC에 포함되어 있습니다. 그룹 정책 기본 설정을 사용하면 관리자는 그룹 정책을 통해 일반적으로 구성할 수 없는 응용 프로그램이나 Windows 구성 요소를 구성할 수 있을 뿐만 아니라 매우 다양한 대상 지정 규칙 집합을 기반으로 특정 사용자 또는 컴퓨터에 이러한 정책을 적용할 수도 있습니다. 그룹 정책 기본 설정은 Windows Server 2008의 GPMC 및 AGPM에 완벽하게 통합되었습니다.

AGPM GPO 배포
AGPM은 효율성과 워크플로를 염두에 두고 설계되었습니다. 이제 GPO 관리 작업은 AGPM 사용을 통해 보다 안정적이고 제어가 용이해졌습니다. 이는 곧 관리자가 GPO를 편집할 수만 있고 프로덕션 환경에 배포할 수는 없음을 의미합니다. AGPM에서는 인터페이스, 대화 상자, 작업 메커니즘을 통해 GPO 관리 작업을 매우 효과적으로 제어할 수 있습니다. 예를 들어 편집 권한만 있는 관리자가 GPO를 배포하려고 할 경우 시스템에서 이를 차단합니다. 그런 다음 해당 관리자에게 배포 권한이 위임된 관리자와 통신할 수 있는 대화 상자를 표시합니다. 이 워크플로 기능은 받는 사람 및 참조 모두에게 전자 메일을 전송하며 해당 GPO를 고유한 상태로 설정합니다. 이러한 고유한 상태는 AGPM 인터페이스의 Pending(보류) 탭 아래에서 확인할 수 있습니다. 이 GPO는 "Pending Deploy(배포 보류 중)"로 표시되며 여기서 관리자는 작업을 수행한 적이 있는 모든 GPO 각각의 상태를 한눈에 파악할 수 있습니다.
배포 권한이 위임된 AGPM 관리자가 보류 중인 GPO를 배포하려면 GPO를 마우스 오른쪽 단추로 클릭한 다음 Approve(승인) 메뉴 옵션을 선택하기만 하면 됩니다. 배포해야 할 GPO가 Pending(보류) 탭이 아닌 Controlled(제어됨) 탭에 있는 경우에는 배포 권한이 위임된 관리자가 GPO를 마우스 오른쪽 단추로 클릭한 다음 Deploy(배포)를 선택하면 됩니다. 이러한 위임된 권한은 이전에 부여된 것이므로 GPO는 즉시 프로덕션에 배포됩니다.

AGPM GPO 설정 보고 및 비교
GPMC 인터페이스에는 강력한 기능의 Settings(설정) 대화 상자가 있으며 Settings(설정) 탭을 통해 이 대화 상자에 액세스할 수 있습니다. 이 Settings(설정) 대화 상자를 통해 GPO에서 구성된 모든 설정을 한눈에 파악할 수 있으므로 약 3,000개에 달하는 그룹 정책 설정 중 어떤 설정이 구성되었는지 쉽게 확인할 수 있습니다.
AGPM에서 수정된 GPO에 대한 아카이브를 제공하므로 GPMC의 Settings(설정) 탭에는 편집된 GPO에 구성된 설정을 볼 수 있는 기능이 없습니다. 대신 AGPM 인터페이스에서는 이러한 기능을 대체할 수 있을 뿐만 아니라 훨씬 유용한 기능을 제공합니다.
원하는 GPO의 설정을 보려면 우선 모든 변경 사항 내역을 확인하는 것이 좋습니다. 변경 사항 내역을 확인하려면 AGPM의 Controlled(제어됨) 탭에서 원하는 GPO를 두 번 클릭합니다. 이 인터페이스에서 원하는 GPO 버전을 마우스 오른쪽 단추로 클릭한 다음 Settings Report(설정 보고서)를 선택합니다. 이렇게 하면 해당 버전의 GPO에 구성된 모든 설정에 대한 보고서가 생성됩니다. 이 보고서는 읽기 편하게 HTML 파일로 제공되지만 XML 형식으로도 생성할 수 있습니다.
보고서를 만드는 기능도 유용하지만 같은 GPO의 두 버전을 비교하는 기능은 더 편리합니다. 이 기능을 사용하면 원래 버전에서 다른 버전으로 어떠한 사항이 변경되었는지 확인하거나, 완전히 다른 두 가지 버전의 동일한 GPO를 비교할 수 있습니다. (이 기능은 배포 중인 GPO와 프로덕션 GPO의 차이점을 비교할 수 있으므로 배포가 보류된 GPO가 있는 경우 매우 유용할 수 있습니다.) 이 보고서를 보려면 내역 보기에서 두 가지 다른 GPO를 강조 표시한 다음 둘 중 하나를 마우스 오른쪽 단추로 클릭하십시오.
차이점 보고서의 색 구분 기능은 매우 유용하며 GPO를 배포하기 전에 보류 중인 GPO에서 변경된 사항이 무엇인지 확인해야 할 경우 특히 유용합니다. 빨간색으로 강조 표시된 설정은 프로덕션 GPO에서 삭제된 설정으로 보류 중인 GPO에서 더 이상 사용할 수 없습니다. 파란색 설정은 변경된 설정이며 초록색 설정은 보류 중인 GPO에서 새로 추가된 설정으로 프로덕션 GPO에는 해당되지 않습니다.
AGPM의 이러한 기능을 사용하면 일일이 수동으로 GPO 설정을 비교하는 데 걸리는 막대한 시간을 절약할 수 있습니다. 또한 이 기능은 시간이 흐름에 따른 GPO의 변화를 문서화하는 완벽한 방법이며 모든 버전에 대해 보고서를 만들고 인쇄할 수 있습니다.

AGPM GPO 재해 복구
GPO에 작은 변경 사항이라도 발생할 경우 네트워크의 여러 컴퓨터에 엄청난 피해가 갈 수 있습니다. 기본 GPMC를 사용하면 적절한 수동 조치를 통해 프로덕션 GPO가 변경되기 전과 후의 GPO를 모두 백업해 둔 경우 이러한 유형의 잘못된 구성을 바로잡을 수 있습니다. 백업해 두지 않은 경우에는 복구가 쉽지 않습니다.
AGPM을 사용하면 이를 손쉽게 처리할 수 있습니다. 모든 GPO에 대한 전체 백업이 GPO 내역에 저장되므로 GPO 내역을 연 다음 재배포할 GPO 버전을 선택하기만 하면 됩니다.
AGPM을 사용하면 완벽한 그룹 정책 관리를 수행할 수 있습니다. 오랫동안 관리자들은 GPO를 오프라인으로 제어하고 관리할 수 있는 기능을 기다려왔습니다. AGPM에서는 힘들이지 않고 이러한 기능을 사용할 수 있습니다. 또한 AGPM에서는 변경된 GPO의 주요 부분을 추적하는 것에만 머무르지 않고, 간편한 GPO 비교 및 재해 복구 기능을 사용할 수 있는 매우 강력한 변경 사항 관리 솔루션을 제공합니다. AGPM에서 기본으로 제공하는 권한 위임 모델을 사용하면 GPO의 모든 편집 사항을 확인할 수 있도록 모든 관리자를 AGPM에 연결할 수 있습니다. AGPM에서는 GPO의 변경 사항을 자동으로 백업할 수 있으므로 프로덕션 GPO 관련 문제를 해결할 수 있습니다. AGMP에는 너무 많은 기능이 있으므로 여기서 이러한 기능을 다 설명하기란 불가능합니다. 대신 AGMP 설명서에서 템플릿, 노드 링크 복구, SMTP 구성 등 보다 많은 내용을 확인할 수 있습니다.

Derek Melber는 독립 컨설턴트, 강사 겸 작가로 Active Directory, 그룹 정책, 보안, 데스크톱 관리를 중심으로 Microsoft 기술을 교육하고 전파하고 있습니다. 온라인 및 인쇄 발행물을 통해 정기적인 집필 활동을 하고 있으며, The Microsoft Windows Group Policy Guide(Microsoft Press, 2005)를 비롯한 10권 이상의 기술 관련 서적을 저술했습니다. 문의 사항이 있으면 derekm@braincore.net으로 연락하시기 바랍니다.


 From the Editor: 딴지꾼의 공감 얻기
From the Editor
딴지꾼의 공감 얻기
Joshua Hoffman

저는 냉소적인 사람입니다. 사실, 대부분의 뉴요커들은 일반적으로 상대방의 의견을 잘 믿고 받아들이는 편이지만, 이따금씩 냉소적인 경향이 도지고 말아 그동안 유지해 온 평정 상태가 무색해져 버릴 때가 있습니다. 딴지 모드로 돌변했을 때 저는 이런 저런 질문을 던지곤 합니다. 그럴 땐 저 자신이 납득할 수 있는 답을 구하지 못하는 경우가 많기도 하구요.
다른 동료들은 이 이야기를 하는 것을 그다지 반기지 않습니다만, 사실 Microsoft에서 몇 년 전 System Center 브랜드를 출시했을 때 저는 이에 대해 다소 냉소적인 편이었습니다. 오해는 하지 마세요. 저는 철두철미한 SMS 사용자랍니다. 이전에 데스크톱 배포 및 관리 전문가였기 때문에, Systems Management Server(2.0 버전 이후이기는 합니다만...)는 저에게 매우 중요한 도구였습니다. 그런데 System Center 브랜드가 출시되고 제품군이 확장됨에 따라 질문을 던지곤 하는 저의 버릇이 다시금 고개를 들게 되었습니다.
이러한 것이 정말 필요했던 것일까? 이것이 결국 고객에게 도움이 될 것인가? 제품군을 다양화하면 이미 익숙하고 유용하게 사용하고 있는 주요 관리 제품에 부정적인 영향을 미치지는 않을까?
하지만 이렇듯 처음에 가졌던 부정적 평가에도 불구하고 결국 저는 System Center의 장점에 매료되고 말았습니다. SMS와 Configuration Manager 및 Operations Manager로 알려져 있는 MOM이 세계적 수준의 관리 제품으로 발전을 거듭하며 매 출시 때마다 놀랍고도 강력한 새 기능이 추가되고 있습니다. 게다가, 새 제품이 추가됨에 따라 제품의 가치가 떨어지는 것이 아니라 오히려 더욱 증대되어 왔습니다.
최근 몇 개월 간 TechNet Magazine을 통해 Capacity Planner, Desired Configuration Monitor 및 Essential과 같은 System Center 구성에 추가된 일부 추가 기능과 함께 새 Configuration Manager 및 Operations Manager 제품에 대하여 살펴보았습니다. 이번 달에는 새롭고도 강력한 기능 몇 가지를 깊숙이 살펴보려고 합니다.
이번 호는 Virtual Machine Manager 2007에서 가상 인프라 관리의 중앙 집중화를 지원하고 기존 하드웨어를 새 가상 시스템으로 통합하여 성가신 마이그레이션 장벽을 허무는 방법을 소개하는 Edwin Yuen의 기사로 시작합니다. Calvin Keaton이 문서 등 표준 사용자 데이터 및 Exchange Server에 저장된 주요 정보와 같은 기업 데이터에 강력한 디스크 기반 백업 솔루션을 사용할 수 있도록 하는 새로운 버전의 Data Protection Manager를 소개하며, Paul Bourgeau이 처음 호스트된 System Center 솔루션인 Asset Inventory Service를 소개합니다.
System Center 구성에 추가된 새로운 기능에 대한 여러분의 의견을 알려 주십시오. tnmag@microsoft.com으로 전자 메일을 보내 주시기 바랍니다. —Joshua Hoffman

도움을 주신 Karandeep Anand, Joseph Dadzie, Ray Hayes, KC Lemson, Bill Scheidel, Jeffrey Snover, Mike Stephens, Kevin Sullivan, Jim Truher 및 Winni Verhoef을 비롯한 Microsoft 기술 전문가 분들께 감사의 말씀을 전합니다.


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

VMRCplus 문제
2007년 10월호 Utility Spotlight(technetmagazine.com/issues/2007/10/UtilitySpotlight)에 설명된 대로 VMRCplus를 다운로드했습니다. 그런데 원격 시스템에 연결하려고 하면 RPC 오류가 발생합니다. 가상 서버 관리 인터페이스가 웹 기반이므로 이 응용 프로그램에서도 기존 웹 기술에 풍부한 클라이언트 환경을 추가하여 웹 인터페이스를 사용하리라고 생각했습니다만, 여기서는 COM API를 사용하네요.
—blogs.technet.com/tnmag 발췌

VMRCPlus는 가상 서버와 함께 제공되는 VMRC 원격 제어 클라이언트와 동일한 네트워크 경로를 사용하며 실제 클라이언트 응용 프로그램은 웹 인터페이스가 아니라 바로 이 원격 제어 클라이언트입니다. 따라서 다음 포트로 액세스해야 합니다.
  • 포트 5900 - VMRC 서버의 기본 포트
  • 포트 1024 - 관리자 웹 사이트의 기본 포트
  • 포트 137, 138 - Kerberos V5 티켓 부여 기관을 위한 TCP 및 UDP(User Datagram Protocol) 포트
  • 포트 135 - RPC 끝점 매퍼를 위해 사용
microsoft.com/technet/prodtechnol/virtualserver/2005/proddocs/vs_operate_using_VMRC_manageVMs.mspx에서 자세한 내용을 보실 수 있습니다.

Windows PE 사용
이번에 "Windows PE 시작"(2006년 9월, technetmagazine.com/issues/2006/09/WindowsPE)이라는 기사를 읽었습니다. Windows® PE를 네트워크 지원이 되는 VMWare 워크스테이션 환경에서 실행해 보려고 하는데 Windows PE에서 NIC 드라이버를 사용하여 네트워크에 액세스할 수 없습니다. Windows PE 이미지 ISO 파일을 사용하여 VMWare에서 부팅했고 시작된 후 명령 콘솔이 나타났으나 ipconfig를 입력해도 IP 주소가 표시되지 않습니다. 제 DHCP 서버에서도 주소가 확인되지 않습니다.
—John C.

VMware에서 기본적으로 설치하는 NIC가 Windows PE 2.0의 기반이 되는 Windows Vista®에서 지원되지 않기 때문에 발생하는 문제입니다. 다음과 같이 가상 컴퓨터 구성 파일(VMX 파일)에서 다른 NIC 유형을 지정해 보십시오.
ethernet0.virtualDev = "e1000"
이렇게 하려면 메모장과 같은 텍스트 편집기에서 VMX 파일을 수동으로 편집해야 합니다. GUI에서는 편집할 수 없습니다. 이렇게 하면 기존의 기본 제공 가상 NIC가 Windows Vista에서 지원하는 Intel 1GB NIC로 대체됩니다. 중요한 것은 이 값으로 변경하면 다른 네트워크 드라이브를 추가하지 않아도 된다는 점입니다.

SQL Server에서 쿼리 성능 최적화
"SQL Server 쿼리 성능 최적화"(2007년 11월, technetmagazine.com/issues/2007/11/SQLQuery) 문서에서 저자는 비용이 가장 많이 드는 20가지의 실행 쿼리를 찾기 위해 SQL Server™ 2005 예제를 사용했지만 SQL Server 2000에서는 실행되지 않습니다. SQL Server 2000 버전에서 실행되는 예제를 제공해 주시겠어요?
—Arun N.

애석하게도 SQL Server 2000에서는 이러한 정보를 얻을 방법이 없습니다. SQL Server 2000은 이러한 정보를 쿼리할 수 있도록 프로시저 캐시에 수집하거나 제공하지 않습니다. 이 정보는 SQL Server 2005에 새로 도입된 동적 관리 뷰 집합을 통해서만 제공됩니다.

작동하지 않는 MIISWorkflow 응용 프로그램
"한 단계 준비 워크플로 만들기"(2007년 5월, technetmagazine.com/issues/2007/05/Workflow)를 읽고 몇 가지 의문점이 생겼습니다. MIISWorkflow 응용 프로그램이 지원되나요? 그리고 .NET Framework 2.0과 호환되나요? Visual Studio® 외부에서 응용 프로그램을 열려고 하니 "서비스를 사용할 수 없음"이라는 오류가 표시됩니다. 디버그 모드에서는 잘 실행되었는데 Visual Studio를 닫고 해당 응용 프로그램을 직접 열려고 하면 오류가 나타납니다. 응용 프로그램 때문에 응용 프로그램 풀이 멈추는 이유는 무엇이며 "서비스를 사용할 수 없음"이라는 오류가 표시되는 이유는 무엇인가요?
—Cliff C.

MIISWorkflow 응용 프로그램은 Microsoft 제품에서 공식적으로 지원하지 않으며 교육용 샘플 코드로만 제공됩니다.
ID 관리와 관련된 문제에 대한 논의는 TechNet Forums Identity Management 사이트(forums.microsoft.com/TechNet/ShowForum.aspx?ForumID=540&SiteID=17)에서 확인할 수 있습니다. 이 포럼은 Microsoft 제품 그룹과 커뮤니티 전문가들이 지속적으로 모니터링하고 있는 곳으로, 문의하신 내용과 같은 문제에 대해 가장 훌륭하면서도 직접적인 지원을 제공받으실 수 있는 곳 중 하나입니다.


 Exchange Queue &amp; A: 음성 안내 추가, PBX 선택 및 기타 정보
Exchange Queue & A
음성 안내 추가, PBX 선택 및 기타 정보
Seema Rahman

Q: Exchange 통합 메시징에서 고가용성 또는 클러스터링 기능이 제공되지 않는다고 하던데 사실인가요?
A: 클러스터 또는 네트워크 부하 분산 구성에서는 통합 메시징이 지원되지 않지만 특정 게이트웨이에서 고가용성 솔루션으로 활용할 수 있습니다. 중요한 점은 여러 통합 메시징 서버를 지정하여 트래픽 라운드 로빈 방식으로 전달한다는 점입니다. 또한 게이트웨이에 필요한 고급 라우팅 기능이 있으므로 특정 트래픽이 특정 통합 메시징 서버로 라우팅되도록 지정할 수 있습니다. 예를 들어 구독자 액세스용 통합 메시징 서버와 자동 전화 교환용 통합 메시징 서버를 각각 지정할 수 있습니다. 이렇게 하면 사용자 환경의 인프라 및 특성에 따라 통합 메시징 트래픽을 적절히 조절할 수 있습니다.

Q: Exchange 통합 메시징을 사용하여 회사 공용 전화번호에 음성 안내를 설정할 수 있습니까?
A: 그렇습니다. 음성 안내를 설정할 수 있으며 자동 전화 교환도 설정할 수 있습니다. technet.microsoft.com/aa998818의 "사용자 지정 오디오 음성 안내 관리" 문서에 이 기능을 구성하는 단계가 자세하게 설명되어 있습니다.

Q: 제 PBX(Private Branch Exchange)가 Exchange 통합 메시징과 호환되는지 확인하려면 어떻게 해야 하나요?
A: 게이트웨이의 경우 Microsoft에서 테스트를 지원하며 Exchange 통합 메시징과 함께 사용할 것을 권장합니다. 게이트웨이 공급업체에서는 자사의 게이트웨이와 함께 작동하는 PBX 목록을 제공합니다. 따라서 사용자의 PBX가 공급업체 목록에 있는 경우 Exchange 통합 메시징과 호환된다는 것을 알 수 있습니다.
microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx에서 볼 수 있는 "전화 통신 관련 정보" 문서를 통해 지원되는 게이트웨이 목록 및 다른 많은 관련 정보를 확인할 수 있습니다.

Q: Exchange 통합 메시징을 사용하려면 전화 시스템에 특수한 하드웨어를 장착해야 하나요?
A: Exchange 통합 메시징 서버는 음성 메일 공급자 역할을 수행하므로 현재의 전화 통신 시스템을 사용하려면 새로운 하드웨어가 필요할 수 있습니다.
지원되는 IP-PBX를 사용하는 경우에는 새로운 하드웨어를 추가하지 않아도 되지만 IP-PBX에서 몇 가지 설정을 구성하여 통합 메시징과 함께 작동하도록 해야 합니다.
지원되는 IP-PBX가 아닌 다른 시스템을 사용하는 경우 우선 해당 하드웨어가 지원되는 게이트웨이 중 하나와 호환되는지 확인해야 합니다. 이때에도 지원되는 VoIP 게이트웨이가 필요합니다.
microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx에서 IP-PBX 및 게이트웨이와 같은 지원되는 하드웨어 목록 정보를 볼 수 있습니다. Microsoft에서 새 하드웨어를 인증할 때마다 목록이 업데이트되므로 자주 확인하시기 바랍니다. 해당 지역의 통합 메시징 전문가와 상의하여 현재 시스템 환경에 맞는 하드웨어 요구 사항을 확인하는 것도 좋습니다.

Q: 통합 메시징으로 팩스를 지원하려면 어떻게 해야 하나요?
A: 현재 통합 메시징에서는 팩스 수신 기능을 제공합니다. 예를 들어 통합 메시징 기능이 설정된 사용자의 내선 번호로 팩스가 전송되면 팩스 메시지를 TIFF 형식으로 전자 메일 메시지에 첨부하여 사용자의 받은 편지함에 전송합니다. 자세한 개요는 technet.microsoft.com/ bb232022에서 제공됩니다.

Q: Nortel CS1000 IP/PBX를 사용 중이며 Exchange Server 2007에서 통합 메시징을 사용하고 싶으나 이 두 시스템을 함께 사용하는 방법을 모르겠습니다. Nortel CS1000 IP/PBX를 게이트웨이로 사용할 수 있나요? 아니면 Intel 및 AudioCodes만 게이트웨이로 지원되는 것인가요? 또한 CS1000 서버에서 인증을 수행할 Exchange 시스템도 필요합니다.
Nortel CS1000는 IP/PBX에서 5.0 버전의 펌웨어를 실행하는 경우 지원됩니다. 추가 하드웨어는 필요하지 않습니다. Nortel 사이트의 support.nortel.com/go/main.jsp?cscat=docdetail&id=626197&poid=14261에 IP-PBX 구성 정보가 안내되어 있습니다. 지원되는 게이트웨이 PBX 및 지원되는 펌웨어 버전은 microsoft.com/technet/prodtechnol/exchange/pbx-partners.mspx에서 확인할 수 있습니다.

Seema Rahman은 Microsoft에서 6년째 근무하고 있으며 현재 지원 향상 엔지니어로서 Exchange Server 사용과 관련하여 복잡한 어려움을 겪는 고객들의 문제를 해결하고 있습니다. Seema는 특히 Exchange 2007 Beta 팀에서 맡았던 통합 메시징 업무를 아주 즐겁게 수행했습니다.


 The Cable Guy: Windows Server 2008의 DNS 기능 향상
The Cable Guy
Windows Server 2008의 DNS 기능 향상
Joseph Davies
이 문서는 Windows Server 2008의 시험판 버전을 기준으로 작성되었습니다. 이 문서에 수록된 모든 정보는 변경될 수 있습니다.

Microsoft는 Windows NT 4.0부터 Windows Server 버전에 DNS(Domain Name System) 서버 서비스를 추가했습니다. DNS는 DNS 도메인 이름과 IP 주소 같은 다양한 데이터 형식 간의 매핑을 포함하는 계층적 분산 데이터베이스입니다. Windows Server 2008의 DNS 서버 서비스에는
백그라운드 영역 로드, IPv6 지원 향상, RODC(읽기 전용 도메인 컨트롤러) 지원, 전역 단일 레이블 이름 호스트와 같은 새로운 기능이 포함되어 있습니다.

백그라운드 영역 로드
Windows Server® 2008의 DNS 서버 서비스는 백그라운드 영역 로드를 구현함으로써 빨라진 데이터 검색 기능을 제공합니다. 과거에는 기업의 Active Directory® 영역에 포함된 레코드가 많은 경우, Windows Server 2003의 DNS 서버 서비스를 다시 시작하면 DNS 서버 서비스가 Active Directory에서 DNS 데이터를 검색하는 데 최대 한 시간 이상 지연되는 상황이 발생했습니다. 검색이 지연되는 동안 DNS 서버는 서버에서 호스팅되는 다른 영역에 대한 DNS 클라이언트 요청에 응답할 수 없었습니다.
이 문제를 해결하기 위해 Windows Server 2008의 DNS 서버 서비스는 다른 영역의 데이터 요청에 응답할 수 있도록 서비스가 시작되면 Active Directory의 영역 데이터 검색을 백그라운드에서 수행합니다. 서비스는 시작될 때 Active Directory에 저장된 영역을 로드하기 위한 실행 스레드를 하나 이상 만듭니다. 이렇게 Active Directory 기반 영역을 로드하기 위한 별도의 스레드를 생성함으로써 DNS 서버 서비스는 영역을 로드하는 동안 쿼리에 응답할 수 있습니다. DNS 클라이언트가 이미 로드된 영역의 데이터를 요청하면 DNS 서버는 요청에 적절히 응답합니다. 아직 완전히 검색되지 않은 영역의 데이터가 요청되면 DNS 서버가 Active Directory에서 해당 데이터를 검색합니다.
영역을 로드하는 동안 Active Directory에서 특정 데이터를 검색하는 이 기능을 통해 DNS 서버 서비스는 요청에 즉시 응답할 수 있으므로 영역 정보를 파일에 저장하는 것보다 훨씬 효율적입니다. 영역을 파일에 저장한 경우 DNS 서버 서비스가 해당 데이터를 찾을 때까지 파일을 순서대로 읽어야 합니다.

IPv6 지원 향상
이 칼럼의 지난 호에서 다룬 IPv6은 새로운 인터넷 표준 프로토콜 집합입니다. IPv6은 주소 고갈, 보안, 자동 구성, 확장성 요구 등 현재 버전인 IPv4가 지닌 많은 문제를 해결하기 위해 설계되었습니다.
IPv6이 기존 IPv4와 다른 가장 큰 차이점은 IPv4 주소는 길이가 32비트에 불과하지만 IPv6은 128비트에 이른다는 점입니다. IPv6 주소는 콜론으로 구분된 16진수 표기 방식으로 표현됩니다. IPv6 주소를 구성하는 각 16진수 숫자는 4비트입니다. 완전한 IPv6 주소는 32자리의 16진수로, 여덟 블록으로 구성되며 각 블록은 콜론으로 구분됩니다. 예를 들면 FD91:2ADD:715A:2111:DD48:AB34:D07C:3914와 같습니다.
IPv6 주소에 대한 정방향 이름 확인에서는 AAAA 레코드("쿼드 A"로 발음)라고 하는 IPv6 호스트 DNS 레코드를 사용합니다. 역방향 이름 확인의 경우 IPv6은 IP6.ARPA 도메인을 사용하며 32자리 IPv6 주소의 각 16진수는 역방향 도메인 계층 구조에서 역순으로 별도의 수준이 됩니다. 예를 들어 주소 FD91:2ADD:715A:2111:DD48:AB34:D07C:3914에 대한 역방향 조회 도메인 이름은 4.1.9.3.C.7.0.D.4.3.B.A.8.4.D.D.1.1.1.2.A.5.1.7.D.D.A.2.1.9.D.F.IP6.ARPA입니다.
Windows Server 2003의 DNS 서버 서비스는 IPv6에 대해 정방향 및 역방향 이름 확인을 지원하지만 지원 기능이 완전히 통합되지는 않았습니다. 예를 들어 Windows Server 2003 DNS 관리자 스냅인에서 IPv6 주소 레코드(앞에서 설명한 AAAA 레코드)를 만들려면 영역을 마우스 오른쪽 단추로 클릭하고 다른 새 레코드를 클릭한 다음 리소스 레코드 형식으로 IPv6 호스트(AAAA)를 두 번 클릭해야 합니다. Windows Server 2008 DNS 관리자 스냅인에서 AAAA 레코드를 추가하려면 영역 이름을 마우스 오른쪽 단추로 클릭한 다음 새 호스트(A 또는 AAAA)를 클릭합니다. 그런 다음 New Host(새 호스트) 대화 상자에서 IPv4 주소나 IPv6 주소를 입력할 수 있습니다. 그림 1에 그 예가 나와 있습니다.
그림 1 New Host(새 호스트) 대화 상자
그림 1 New Host(새 호스트) 대화 상자
역방향 IPv6 영역에서도 IPv6에 대한 지원이 향상되었습니다. Windows Server 2003 DNS 관리자 스냅인에서 역방향 조회 영역을 만들려면 New Zone Wizard(새 영역 마법사)의 Reverse Lookup Zone Name(역방향 조회 영역 이름) 페이지에서 역방향 영역 이름을 직접 입력해야 합니다. 예를 들어 DNS 역방향 영역 이름으로 1.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa(IPv6 서브넷 접두사가 2001:db8:0:1::/64인 경우 완전한 주소는 2001:0db8:0000:0001::/64임)를 입력합니다.
이제 Windows Server 2008의 DNS 관리자 스냅인에서는 IPv6 역방향 영역이 New Zone Wizard(새 영역 마법사)에 완전히 통합되었습니다. 이 마법사에는 IPv4 역방향 조회 영역 또는 IPv6 역방향 조회 영역을 선택할 수 있는 새로운 페이지가 추가되었습니다. IPv6 역방향 조회 영역을 만들려는 경우 IPv6 서브넷 접두사만 입력하면 자동으로 영역이 만들어집니다. 그림 2에 그 예가 나와 있습니다.
그림 2 IPv6 역방향 조회 영역 이름 지정
그림 2 IPv6 역방향 조회 영역 이름 지정
DNS 관리자 스냅인에 IPv6 PTR(포인터) 레코드가 표시되는 방식에 있어서도 역방향 영역에 대한 지원이 향상되었습니다. 그림 3에서 Windows Server 2003 DNS 관리자 스냅인에 PTR 레코드가 표시되는 방식을 볼 수 있습니다.
그림 3 Windows Server 2003의 IPv6에 대한 PTR 레코드
그림 3 Windows Server 2003의 IPv6에 대한 PTR 레코드
이 표시 방식은 IPv6 역방향 도메인 이름에 대한 DNS 네임스페이스 구조를 정확하게 반영하기는 하지만 IPv6 주소에 대한 PTR 레코드를 관리하기가 어렵습니다. 그림 4에서 Windows Server 2008 DNS 관리자 스냅인에 PTR 레코드가 표시되는 방식을 볼 수 있습니다.
그림 4 Windows Server 2008의 IPv6에 대한 PTR 레코드
그림 4 Windows Server 2008의 IPv6에 대한 PTR 레코드
Windows Server 2003의 DNS 서버 서비스는 IPv6에 대한 작업을 지원하지만 dnscmd /config /EnableIPv6 1 명령을 사용하여 지원을 직접 활성화해야 합니다. Windows Server 2008에서는 IPv6에 대한 작업을 기본적으로 지원합니다. Dnscmd.exe 명령줄 도구는 명령줄 옵션에 IPv6 주소를 사용할 수 있도록 업데이트되었습니다. 또한 DNS 서버 서비스가 이제 IPv6 전용 서버에 재귀 쿼리를 전송할 수 있으며 서버 전달자 목록에 IPv4 주소와 IPv6 주소를 모두 포함할 수 있습니다.
IPv6 및 Windows®의 IPv6 지원 방식에 대한 자세한 내용은 microsoft.com/ipv6을 참조하십시오.

읽기 전용 도메인 컨트롤러 지원
Windows Server 2008에는 Active Directory 정보의 읽기 전용 복사본을 포함하며 Active Directory 기능을 수행하지만 직접 구성할 수는 없는 새로운 유형의 도메인 컨트롤러인 RODC가 도입되었습니다. RODC는 공격에 덜 취약하므로 도메인 컨트롤러에 대한 물리적 보안을 보장할 수 없는 위치나 위험할 수 있는 호스트가 포함된 네트워크에 배치할 수 있습니다.
Windows Server 2008의 DNS 서버 서비스는 RODC에 대해 새로운 형식의 기본 읽기 전용 영역을 지원합니다. 컴퓨터를 RODC로 구성하면 도메인 파티션, ForestDNSZones 및 DomainDNSZones를 비롯하여 DNS가 사용하는 모든 응용 프로그램 디렉터리 파티션의 전체 읽기 전용 복사본이 복제됩니다. 이를 통해 RODC에서 실행되는 DNS 서버 서비스는 RODC가 아닌 도메인 컨트롤러의 디렉터리 파티션에 저장된 모든 DNS 영역에 대한 전체 읽기 전용 복사본을 사용할 수 있습니다. RODC의 기본 읽기 전용 영역의 내용은 볼 수는 있지만 변경할 수는 없습니다. RODC로 구성되지 않은 도메인 컨트롤러의 영역 내용만 변경할 수 있습니다.

GlobalNames 영역
GlobalNames 영역을 사용한 이름 확인
GlobalNames 영역을 배포한 경우 Windows Vista 기반 DNS 클라이언트는 단일 레이블 이름을 확인할 때 단일 레이블 이름 뒤에 기본 DNS 접미사를 추가한 다음 해당 DNS 서버로 이름 쿼리 요청을 전송합니다.
이름을 확인하지 못하면 DNS 클라이언트가 단일 레이블 이름과 DNS 접미사 검색 목록(구성된 경우)의 접미사가 결합된 이름에 대해 추가 이름 쿼리 요청을 전송합니다. 그래도 이름이 확인되지 않으면 클라이언트가 단일 레이블 이름을 사용하여 이름 확인을 요청합니다.
DNS 서버는 단일 레이블 이름을 GlobalNames 영역에서 검색합니다. GlobalNames 영역에 이름이 있으면 DNS 서버는 확인된 IPv4 주소 또는 FQDN을 DNS 클라이언트로 보냅니다. 이름이 없으면 DNS 클라이언트 컴퓨터에서 이름을 NetBIOS 이름으로 변환한 후 WINS를 비롯한 NetBIOS 이름 확인 기술을 사용합니다. GlobalNames 영역에서 단일 레이블 이름 확인을 사용하기 위해 DNS 클라이언트 서비스를 변경할 필요는 없습니다.

Windows Server 2008과 Windows Vista®는 NetBT(NetBIOS over TCP/IP) 프로토콜을 지원합니다. NetBT는 NetBIOS 이름을 사용하여 세션 계층 NetBIOS 응용 프로그램을 확인합니다. 이름 확인에 Windows 소켓 기반 네트워크 응용 프로그램 및 DNS를 사용하는 최신 버전의 Windows에서는 WINS를 사용한 NetBIOS 이름 확인이 필요하지 않지만, 대부분의 Microsoft 고객은 이전의 NetBT 응용 프로그램을 지원하고 조직 전체에 단일 레이블 이름에 대한 이름 확인 기능을 제공하기 위해 네트워크에 WINS를 배포합니다. 단일 레이블 이름은 전자 메일 서버, 중앙 웹 서버, LOB(기간 업무) 응용 프로그램용 서버 등 일반적으로 조직에서 잘 알려지고 보편적으로 사용되는 중요한 서버를 나타냅니다.
이러한 단일 레이블 이름을 DNS만 사용해서 조직 전체에서 확인할 수 있도록 하려면 Windows 기반 DNS 클라이언트가 클라이언트에 할당된 DNS 도메인 접미사나 접미사 검색 목록에 관계없이 이름을 확인할 수 있도록 조직의 여러 DNS 도메인에 A 레코드를 추가해야 할 수도 있습니다.
예를 들어 contoso.com이라는 조직에 central.contoso.com 도메인의 구성원인 CWEB이라는 중앙 웹 서버가 있다고 가정해 보십시오. DNS 클라이언트에 DNS 도메인 접미사 wcoast.contoso.com, central.contoso.com 또는 ecoast.contoso.com을 할당할 수 있는 경우 CWEB 서버에 대해 단일 레이블 이름을 구현하려면 네트워크 관리자가 cweb.wcoast.contoso.com과 cweb.ecoast.contoso.com 모두에 대해 추가 A 레코드를 만들어야 합니다. 단일 레이블 이름에 대해 직접 만든 A 레코드는 IPv4 주소 할당이 변경되거나 새로운 이름이 사용될 경우 그에 따른 유지 관리가 필요합니다.
contoso.com이 이전의 NetBT 응용 프로그램에 대해 이미 WINS를 사용하고 있을 경우 네트워크 관리자는 해당 WINS 인프라에 단일 정적 WINS 레코드를 추가하여 단일 레이블 이름 CWEB에 대한 이름 확인을 구현할 수 있습니다. IPv4 주소가 변경되면 단일 정적 WINS 레코드만 변경하면 됩니다. 단일 레이블 이름은 WINS에서 관리하기가 더 쉬우므로 대부분의 Windows 기반 네트워크에서는 단일 레이블 이름에 정적 WINS 레코드를 사용합니다.
정적 WINS 레코드처럼 관리하기 쉬운 단일 레이블 이름 확인 기능을 DNS에 제공하기 위해 Windows Server 2008의 DNS 서버 서비스는 단일 레이블 이름을 저장하기 위한 GlobalNames라는 새로운 영역을 지원합니다. 이 영역의 복제 범위는 일반적으로 포리스트이며 이를 통해 전체 Active Directory 포리스트에 단일 레이블 이름 확인 기능이 제공됩니다. 또한 GlobalNames 영역 위치를 게시하는 데 SRV(서비스 찾기) 리소스 레코드를 사용하는 경우 GlobalNames 영역은 포리스트가 여러 개 포함된 조직에도 단일 레이블 이름 확인 기능을 지원할 수 있습니다.
WINS와 달리 GlobalNames 영역은 일반적으로 조직의 IT 부서에서 관리하는 조직의 중앙 서버 및 중요 서버와 같은 제한된 호스트 이름 집합에 단일 레이블 이름 확인 기능을 제공할 목적으로 만들어졌습니다. GlobalNames 영역은 데스크톱 컴퓨터나 IPv4 주소가 변경될 수 있는 다른 서버의 이름을 저장하는 데 사용할 목적으로 만들어지지 않았으며 DNS 동적 업데이트를 지원하지 않습니다. GlobalNames 영역은 대개 단일 레이블 이름을 FQDN(정규화된 도메인 이름)에 매핑하는 별칭(CNAME) 리소스 레코드를 보관하는 데 사용됩니다. 현재 WINS를 사용 중인 네트워크의 경우 이미 WINS에 정적으로 구성되어 있으며 IT 부서에서 관리하는 이름에 대한 리소스 레코드는 일반적으로 GlobalNames 영역에 포함됩니다.
GlobalNames 영역은 권한 있는 모든 DNS 서버가 Windows Server 2008을 실행하는 경우에만 단일 레이블 이름 확인 기능을 제공합니다. 이 경우 영역에 대한 권한이 없는 다른 DNS 서버는 이전 버전의 Windows나 다른 운영 체제를 실행할 수 있습니다. GlobalNames 영역은 포리스트에서 고유해야 합니다.
GlobalNames 영역을 Active Directory와 통합하여 권한 있는 각 DNS 서버를 Active Directory의 로컬 복사본으로 구성하면 최고의 성능과 확장성을 제공할 수 있습니다. 이렇게 하면 여러 포리스트에 GlobalNames 영역 배포를 지원할 수 있습니다.
Windows의 DNS 지원 및 GlobalNames 영역 배포에 대한 자세한 내용은 Microsoft DNS 웹 페이지(microsoft.com/dns)를 참조하십시오.

Joseph Davies는 Microsoft의 기술 전문 저술가로 1992년부터 Windows 네트워킹을 주제로 글을 쓰고 가르치는 일을 하고 있습니다. Microsoft Press에서 5권의 책을 저술한 그는 월간 온라인 TechNet Cable Guy 칼럼의 저자이기도 합니다.


 Windows PowerShell: 악성 코드 차단
Windows PowerShell
악성 코드 차단
Don Jones

Windows Vista가 베타 단계에 있는 동안 코드 이름 "Monad"라는 새 명령줄 셸의 초기 버전에 대해 많은 논란이 있었다는 사실을 기억하고 계십니까? 이 명령줄 셸이 바로 지금의 Windows PowerShell입니다. 당시 "첫 번째 Windows Vista 바이러스"에 관한 주요 언론 보고가 상당히 많았습니다. 그러나
이 "바이러스"는 "Monad"를 대상으로 하는 개념 증명 맬웨어일 뿐이었습니다. 이 스크립트는 기본 설정에서는 작동하지 않으며 스크립트를 실행하려면 "Monad"를 특별하게 구성해야 했습니다. 더욱이 이러한 보고가 발표될 당시에는 Microsoft에서 "Monad"를 Windows Vista®에 포함하지 않을 것임을 이미 발표한 뒤였습니다. 결국 아무 일도 아닌 것으로 한 바탕 소동을 벌였던 것입니다.
그러나 Windows PowerShellTM이 점점 보편화되고 다운로드 횟수가 백만 번 이상에 이르면서 악성 스크립트를 만드는 데 Windows PowerShell이 이용되는 경우가 늘어나고 있습니다. Windows PowerShell에서 위험을 초래할 수 있는 스크립트를 작성할 수 있다면 Windows PowerShell, cmd.exe, VBScript 등 그 어떤 관리 도구도 악의적으로 이용될 수 있습니다. 따라서 PS1 파일이 안전하다고 단정할 수만은 없습니다.
다행히 Windows PowerShell은 기본적으로 어떤 스크립트도 실행하지 않도록 구성되어 있으며 악성 스크립트가 실행되기 위해서는 사용자의 개입이 필요합니다. 이번 호에서는 이러한 문제가 어떻게 발생할 수 있는지 살펴보겠습니다. 이 기사에서 Windows PowerShell을 폄하하려는 의도는 조금도 없습니다. 또한 Microsoft에서 여러 위험 요소를 차단하도록 이 스크립팅 셸을 설계했을 거라고 생각합니다. 그렇다 하더라도 이 기사의 내용을 읽고 이와 같은 잠재적 공격을 차단할 만반의 대비를 할 필요는 있겠습니다.

기본 보안
Windows PowerShell은 그 유명한 신뢰할 수 있는 컴퓨팅 이니셔티브를 추진한 이후 Microsoft에서 설계한 첫 번째 언어라는 점을 주목할 필요가 있습니다. 보안 전문가이자 Writing Secure Code의 저자인 Michael Howard가 Windows PowerShell 팀의 "보안 조언자"로 활동했습니다. Howard는 보안이 최대한 유지되는 코드가 작성되고, 특히 이 셸이 기본적으로 안전하게 구성되어 제공될 수 있도록 많은 도움을 주었습니다.
먼저 초기의 Windows PowerShell 보안 설정에 대해 간단히 살펴보겠습니다. 이 셸은 확장명이 PS1인 파일을 두 번 클릭해도 기본적으로 파일을 실행하지 않습니다. 이 확장명은 메모장과 연결되어 있습니다. 실제로는 스크립트가 실행될 수 있는 조건에 대해 설명하는 실행 정책이라고 하는 기본 제공 기능으로 인해 셸에서 기본적으로 스크립트를 실행하지 않는 것입니다. 실행 정책은 기본적으로 Restricted로 설정되어 있으며, 이 설정에서는 모든 스크립트의 실행이 금지되고 셸을 대화형으로만 사용할 수 있습니다. 실행 정책은 Set-ExecutionPolicy cmdlet을 사용하거나 Microsoft에서 제공하는 그룹 정책 관리 템플릿(ADM 파일)을 통해 변경할 수 있습니다. ADM 파일은 go.microsoft.com/fwlink/?LinkId=102940에서 다운로드할 수 있습니다. 그림 1에서는 설정할 수 있는 실행 정책을 보여 줍니다.
그림 1 안전한 실행 정책 선택
그림 1 안전한 실행 정책 선택
실행 정책에는 몇 가지 예외가 있습니다. 예를 들어 Restricted로 설정되어 있을 때에도 셸은 Microsoft에서 제공한 몇몇 특정 XML 구성 파일을 가져와 설치할 수 있습니다. 이러한 파일은 Microsoft® .NET Framework 형식 확장이나 대부분의 .NET 개체 형식에 대한 기본 형식 레이아웃과 같은 특수한 기능을 제공하는 데 사용됩니다. 따라서 이러한 파일은 셸이 시작될 때 로드되어야 하는 파일입니다.
이러한 파일은 실행 코드를 포함할 수 있으며 실제로 포함되어 있지만 Microsoft에 의해 디지털 서명되어 있습니다. 파일이 어떤 식으로든 손상되면 서명이 유효하지 않게 되며 이 경우 셸이 시작될 때 파일을 가져오지 않습니다. 이를 통해 파일에 악성 코드를 삽입하려는 맬웨어로부터 파일을 안전하게 보호할 수 있습니다.
물론 실행 정책을 기본값인 Restricted로 유지하면 Windows PowerShell을 시작할 때 사용자가 만든 고유의 Windows PowerShell 프로필 스크립트가 실행되지 않습니다. Windows PowerShell은 기본적으로 프로필 스크립트를 만들지 않지만, 셸이 시작될 때마다 네 개의 특정 위치에서 특정 파일 이름을 검색하여 있으면 실행합니다. Windows PowerShell과 함께 설치되는 설명서에서 프로필 스크립트에 사용되는 폴더 및 파일 이름에 대한 자세한 내용을 볼 수 있습니다. 프로필은 앞으로 설명할 익스플로잇의 주요 수단으로 이용됩니다.

실행 정책 수정
이달의 Cmdlet
Set-AuthenticodeSignature의 동반 Cmdlet은 Get-AuthenticodeSignature입니다. 이 cmdlet은 디지털 서명된 스크립트를 검토하고 서명에 대한 정보를 제공하도록 설계되었습니다. 원하는 파일을 지정하여 이 cmdlet을 실행하면 파일이 서명되었는지 여부와 함께 서명이 손상되지는 않았는지, 파일 서명에 사용된 인증서는 무엇인지 등을 확인할 수 있습니다. 이 cmdlet은 Windows PowerShell 스크립트뿐만 아니라 다음과 같이 서명된 실행 파일에도 작동합니다.
PS C:\Program Files\Microsoft Office\Office12>
Get-AuthenticodeSignature excel.exe | Format-List *
이 명령을 실행하면 실행 파일이 Microsoft Code Signing CA에서 발급한 인증서를 사용하여 Microsoft Corp에서 서명한 것임을 알 수 있습니다.
명령 결과

기본 상태에서는 Windows PowerShell에서 악성 코드는 물론이고 어떠한 코드도 실행하도록 하기가 매우 어렵습니다. 실행 정책을 수정하기 전까지는 악성 스크립트가 침투할 여지가 없습니다. 다시 말하지만 이 칼럼에서 Windows PowerShell의 보안 허점에 대해 경고할 생각은 없으며, 다만 시스템을 보다 안전하게 유지하기 위한 몇 가지 최선의 방법을 공유하려는 것일 뿐입니다.
가장 낮은 수준의 실행 정책은 Unrestricted이며 이 수준에서는 모든 스크립트가 제한 없이 실행될 수 있습니다. 이 경우 지난 수년간 VBScript와 배치 파일에서 겪었던 문제가 반드시 발생할 것입니다. 셸을 Unrestricted로 설정하면 악성 스크립트가 침투하여 시스템을 손상시키도록 방치하는 것과 같습니다. Unrestricted 설정을 선택하면 스크립트가 침투해 시스템을 엉망으로 만들 것입니다. 따라서 타당한 이유가 없으면 Unrestricted 설정을 선택해서는 안 되며, 설정할 경우 바이러스로 인해 시스템이 엉망이 되었을 때 이를 책임질 준비가 되어 있어야 합니다.
다행히 Unrestricted로 설정되어 있을 때에도 Windows PowerShell은 인터넷에서 다운로드된 스크립트를 감지하여 실행하기 전에 이에 대해 경고 메시지를 표시합니다. 그렇다 하더라도 실행 정책을 Unrestricted로 설정하는 것은 바람직하지 않습니다.

스크립트 서명
스크립트 실행을 허용하는 가장 안전한 실행 정책은 AllSigned입니다. 이름에서 알 수 있듯이 이 설정에서는 신뢰할 수 있는 인증서를 사용하여 생성된 손상되지 않은 디지털 서명이 있는 스크립트만 실행합니다. 스크립트에 서명하려면 Class III 디지털 인증서, 즉 Microsoft Authenticode 코드 서명 인증서가 있어야 합니다. 이러한 인증서는 회사 내부의 PKI(공개 키 인프라)가 있으면 여기에서 구하거나 CyberTrust, Thawte, VeriSign 등의 상용 CA(인증 기관)에서 구입할 수 있습니다.
다음 cmdlet을 사용하면 스크립트 서명에 사용할 수 있는 인증서가 컴퓨터에 설치되어 있는지 여부를 확인할 수 있습니다.
Get-ChildItem CERT: -recurse –codeSigningCert
Windows® 컴퓨터에 인증서를 설치한 후 Set-AuthenticodeSignature cmdlet을 사용하여 디지털 서명을 만들고 적용합니다. 디지털 서명은 스크립트 맨 아래쪽에 암호처럼 보이는 몇 줄의 주석으로 나타납니다. 일부 스크립트 편집기에는 저장 시 자동으로 스크립트에 서명을 하는 등 스크립트 파일에 서명을 적용하는 편리한 옵션이 있습니다.
AllSigned는 프로덕션 환경에서 사용하기에 가장 적합한 실행 정책입니다. 이 설정은 악성 스크립트를 완전히 차단하지는 않지만 악성 스크립트에도 서명을 요구하므로 스크립트 작성자를 추적할 수 있습니다. 스크립트 작성자 추적은 사용 중인 Windows 컴퓨터가 신뢰할 수 있는 CA만 신뢰하도록 구성된 경우에만 실행되는데, 이 내용은 이 칼럼의 주제를 벗어나는 것이므로 자세히 다루지 않겠습니다. 흥미롭게도 WSH(Windows 스크립트 호스트) 5.6 이상도 디지털 서명을 요구하는 이와 유사한 TrustPolicy 설정을 사용하여 구성할 수 있지만 실제로 이 설정을 사용하는 관리자는 거의 보지 못했습니다.
지금까지의 내용을 요약하면 이렇습니다. 실행 정책을 Restricted로 설정하면 악성 스크립트로부터 안전할 수는 있지만 필요한 스크립트까지 실행할 수 없게 됩니다. 실행 정책을 AllSigned로 구성하면 서명된 스크립트 실행만 허용됩니다. 자신이 만든 악성 스크립트에 검증되고 추적 가능한 ID가 적용되는 것을 원하는 악성 스크립트 작성자는 거의 없기 때문에 이러한 스크립트는 매우 안전합니다. 반면 Unrestricted는 매우 위험한 설정으로 이 설정을 사용할 경우 결국 악성 스크립트의 공격을 받게 될 것입니다. Unrestricted 설정이 특별히 보안상 취약하다고는 생각하지 않습니다. 이 설정은 보호되지 않을 뿐이며 이 설정을 사용하는 사용자라면 이 설정을 사용하는 타당한 이유가 있을 것이기 때문입니다.

틈새 공격
위에서 설명하지 않은 실행 정책 설정이 한 가지 더 있습니다. 바로 RemoteSigned입니다. 필자가 생각하기에 이 설정은 Unrestricted보다는 안전하고 AllSigned보다는 번거롭지 않으므로 대부분의 관리자가 사용하는 것 같습니다. RemoteSigned는 로컬 스크립트에는 서명을 요구하지 않습니다. 따라서 로컬 드라이브에 있는 PS1 파일은 서명되어 있지 않아도 실행됩니다. 원격 스크립트는 주로 Internet Explorer®나 Outlook®을 통해 인터넷에서 다운로드되며 이러한 응용 프로그램에서는 다운로드된 파일을 특수 플래그로 표시하여 구분하므로 스크립트에 서명이 있어야만 실행됩니다.
RemoteSigned 설정은 안전하다는 잘못된 생각을 할 수 있습니다. 하지만 특수 플래그 적용 없이 원격 스크립트를 쉽게 다운로드할 수 있습니다. 예를 들어 타사 브라우저에서는 일반적으로 이 플래그를 설정하지 않으며 이는 대부분의 타사 전자 메일 클라이언트에서도 마찬가지입니다. 이 플래그가 없으면 Windows PowerShell은 다운로드된 스크립트를 로컬 스크립트, 즉 서명이 필요하지 않은 스크립트로 처리합니다. 그렇다 하더라도 이것이 보안상 큰 문제가 되지는 않습니다. 스크립트가 실행되려면 실제로 스크립트를 다운로드해야 하고 Windows PowerShell을 연 다음 직접 실행해야 하기 때문입니다. 누군가를 속여서 이러한 단계를 모두 수행하도록 하는 것은 꽤 어려운 일일 뿐만 아니라 대개 네트워크에서 Windows PowerShell을 설치하여 사용하는 유일한 사용자인 관리자라면 더 잘 알아서 이에 대응할 것이기 때문입니다.
그러나 RemoteSigned는 맬웨어가 침투할 수 있는 꽤 많은 "틈새"를 제공합니다. 앞에서 언급한 Windows PowerShell 프로필 스크립트를 생각해 보십시오. 직접 만든 것이든 맬웨어를 통해 생성된 것이든 간에 이러한 스크립트는 Windows PowerShell을 실행할 때마다 실행됩니다. 또한 RemoteSigned 실행 정책에서는 로컬 프로필 스크립트에 서명을 요구하지 않는다는 문제도 있습니다.
다음은 가정해 볼 수 있는 시나리오입니다.
  1. 맬웨어가 시스템에 침투해 셸 프로필 스크립트를 만들거나 기존 프로필 스크립트에 악성 코드를 삽입합니다. 맬웨어는 대개 사용자가 로그온한 사용자 계정에서 실행되므로 프로필 스크립트를 수정할 수 있는 권한을 가집니다.
  2. 사용자는 프로필 스크립트가 새로 생성되었거나 악성 코드를 포함하도록 수정되었다는 사실을 모른 채 Windows PowerShell을 엽니다. 그러면 코드가 실행되고 피해가 발생합니다. 관리자 자격 증명으로 Windows PowerShell을 연다면 그 피해가 더욱 클 것입니다. 그러나 대개 셸을 사용하여 작업을 수행하기 위해서는 관리 권한이 필요하므로 관리자 자격 증명으로 여는 것이 일반적입니다.
이 경우 프로필은 사용자 모르게 악성 코드가 실행될 수 있는 방법을 제공하고 RemoteSigned 실행 정책은 이러한 일이 발생하도록 허용합니다.

프로필 보호
프로필을 보호하는 좋은 방법은 AllSigned 실행 정책을 사용하는 것뿐입니다. AllSigned 설정에서는 프로필 스크립트도 디지털 서명이 되어 있어야 하며 그렇지 않은 경우 Windows PowerShell이 시작될 때 프로필 스크립트를 실행하지 않습니다. 프로필 스크립트에 서명이 있더라도 스크립트가 악의적 의도로 수정되면 디지털 서명이 손상되므로 스크립트가 실행되지 않게 됩니다. 이 경우 Windows PowerShell은 시작될 때 이러한 문제에 대한 알림을 표시합니다. AllSigned는 스크립트의 실행을 허용해야 하는 프로덕션 환경에서 유일하게 믿고 사용할 수 있는 실행 정책입니다.
복잡하고 신뢰성도 떨어지기는 하지만 다른 방법도 있긴 합니다. 바로 Windows PowerShell이 검색하는 네 개의 파일 각각에 대해 빈 프로필 스크립트 파일을 만드는 것입니다. "Profile Editor"와 같은 새 사용자 계정으로 프로필 스크립트 파일을 만들고 Profile Editor 계정만 파일을 수정할 수 있도록 파일의 NTFS 권한을 설정합니다. 다른 계정은 파일에 대해 읽기 전용 권한만 가질 수 있습니다.
이제 프로필을 편집하려는 경우가 아니면 Profile Editor 계정으로 컴퓨터에 로그온하지 않습니다. 이 방법을 사용할 경우 일반 사용자 계정으로는 프로필 스크립트를 수정할 수 없습니다. 일반 계정으로 로그온해 있는 동안 실행되는 맬웨어 또한 스크립트를 수정할 수 없습니다. 그러나 Profile Editor로 로그온해 있는 동안 맬웨어가 실행된다면 어떻게 될까요? 프로필 스크립트를 편집하기 위해 Profile Editor로 로그온해 있는 동안 맬웨어로 인해 프로필이 변경된다면 이를 알아챌 수 있어야 합니다.
앞에서 설명한 것과 같이 강력한 파일 권한으로 제어되는 모든 사용자 프로필 스크립트를 만들어 고유의 보호막을 치는 방법도 있습니다. 이러한 스크립트 내에, Get-AuthenticodeSignature cmdlet을 사용하여 셸이 검색하는 다른 프로필의 디지털 서명을 검토하는 코드를 작성하는 것입니다. 이렇게 하면 다른 스크립트에는 서명을 요구하지 않으면서 프로필 스크립트에만 서명을 요구할 수 있습니다.
그래도 AllSigned 실행 정책이 프로필을 보호하는 데 더 완벽한 방법입니다. 네트워크에 연결된 모든 컴퓨터에는 가능하면 그룹 정책을 통해 Restricted 실행 정책을 적용하는 것이 좋습니다. 이 경우 로컬 설정은 모두 무시되고 스크립트를 허용하지 않도록 새 도메인 컴퓨터가 자동으로 설정됩니다. 스크립트를 허용해야 하는 컴퓨터에는 AllSigned 실행 정책을 설정하는 다른 그룹 정책을 설정해야 합니다. 물론 모든 스크립트에 디지털 서명을 해야 하지만 식별 가능한 작성자가 만든 신뢰할 수 있는 스크립트만 사용자 환경에서 실행된다는 사실을 알고 있다면 더욱 안심할 수 있을 것입니다.

Don Jones는 SAPIEN Technologies의 수석 스크립팅 전문가이자 Windows PowerShell: TFM(SAPIEN Press, 2007)의 공동 저자입니다. 문의 사항이 있으면 www.ScriptingAnswers.com으로 연락하시기 바랍니다.


 Hey, Scripting Guy!: 정규식 유효성 검사
Hey, Scripting Guy!
정규식 유효성 검사
Scripting Guys
이 기사의 코드 다운로드: HeyScriptingGuy2008_01.exe (150KB)

사람은 누구나 실수를 하게 마련입니다. 아무도 실수를 안 한다면 애초에 Scripting Guys 팀이 생기지도 않았겠죠? 실수에도 긍정적인 측면이 있다면 어떤 점이라 생각하십니까? 아마 대부분 실수를 통해 무언가를 배울 수 있다는 점을 꼽겠죠? 그런데 그게 아닙니다. 실수를 통해 배울 수 있는 게 있다면 처음부터 실수를 하지 않는 편이 훨씬 낫다는 것뿐입니다.
참고로 말씀 드리자면, 오늘만은 Microsoft Bob에 대한 농담을 자제해 주십시오. 예전에 Microsoft Bob을 놀려대는 실수를 저지른 적이 있는데, 그 당시 실수에 대해 뼈저리게 느끼게 되었습니다. 그 후로 다시는 Microsoft Bob에 대해 입 밖에 내지 않게 되었죠.
솔직히 우리는 아무리 생각해 봐도 실수의 긍정적인 면을 찾지 못하겠습니다. 우리가 실수를 줄이기 위해 무던히 애쓰는 이유가 바로 이 때문이겠지요. 물론 우리가 하는 작업량을 줄이는 것이 실수를 가장 확실하게 줄이는 방법이겠지만, 그럴 수는 없겠죠.
우리 스스로 실수를 줄이기 위해 노력하는 것도 좋지만 함께 일하는 다른 사람들이 계속 실수를 한다면 소용이 없습니다. 다시 한 번 말하지만 Microsoft Bob에 대한 농담은 자제해 주세요. 아마 데이터베이스 프로그램이나 Active Directory®의 프런트 엔드를 작성해 본 경험이 한 번쯤은 다들 있으실 겁니다. 그렇다면 여러분도 잘 알겠지만 프런트 엔드 데이터 입력 프로그램은 직접 데이터를 입력하는 사람과 다를 바가 없습니다.
Ken과 같이 첫 번째 문자는 대문자이고 나머지 문자는 소문자인 형식으로 이름을 입력하도록 했는데 사용자가 KEN과 같은 형식으로 이름을 입력하면 어떻게 될까요? 또한 2007/01/23과 같은 형식으로 날짜를 입력해야 하지만 사용자가 2007년 1월 23일로 입력할 수도 있습니다. 더 많은 예를 들지 않아도 이쯤에서 이해했으리라 믿습니다. 앞서 설명했듯이 프런트 엔드 데이터 입력 프로그램은 직접 데이터를 입력하는 사람과 다를 바가 없다는 것입니다. 그리고 사람이 데이터를 입력하면 실수가 발생하게 마련입니다. 이러한 실수를 방지할 수 있는 특별한 조치를 취하지 않는다면 말이죠.

데이터 유효성 확인
Scripting Games
Scripting Guys가 일년 내내 기다리는 행사가 하나 있습니다. 작년과 재작년 2월에 열렸던 스크립트 센터에 참가했던 독자는 "The Winter Scripting Games" 행사가 아닐까 생각하겠지만, 아쉽게도 아닙니다. 오히려 Scripting Guys는 Scripting Games 대회를 성공적으로 마무리한 후에 밀린 잠을 자며 푹 쉴 수 있는 날이 오기를 학수고대합니다. 2주 동안 쉬지 않고 다양한 행사를 진행해야 하는 강행군이니까요.
우리에게 연중 최고의 행사가 된 Scripting Games 대회의 폐막을 맞이하기 위해 2008 Winter Scripting Games를 시작할 때가 되었습니다. 2008년 2월 15일에서 3월 3일까지 2주가 넘는 기간 동안 스크립트 센터에서 흥미로운 스크립팅 관련 행사와 최고 권위의 스크립팅 대회가 펼쳐집니다.
Scripting Games는 스크립팅 실력을 가늠하고 향상시킬 좋은 기회가 됩니다. 그리고 이번에는 대회를 마친 후 며칠 더 푹 쉴 만한 빌미를 만들기 위해 예년보다 훨씬 대규모로 한층 흥미롭게 준비했습니다. 이번에도 초보 사용자와 고급 사용자의 두 부문으로 나뉘어 행사가 진행됩니다. 따라서 스크립팅 초보자이든, 나이가 많든(또는 젊든), 아니면 어중간한 위치에 있든, 누구나 즐길 수 있는 대회가 될 것입니다.
올해 대회는 예년 대회와 어떻게 다를까요? 또 다른 스크립트 언어가 추가되었습니다. 기존의 VBScript와 Windows PowerShell뿐만 아니라 Perl로도 대회가 펼쳐집니다. Perl이 새로운 언어는 아니지만 이 대회의 대상 언어로는 처음 추가되었습니다. 이 외에도 여러 가지 흥미로운 행사가 있겠지만 행사 몇 달 전에 이 기사를 작성하는 관계로 아직은 정확한 내용을 알 수 없습니다. 자세한 내용은 스크립트 센터에서 확인하시기 바랍니다.
궁금해 하실 분들을 위해 미리 말씀 드리자면, 상품도 준비되어 있습니다. 구체적으로 상품이 뭐냐고요? 여기서 다 알려드리면 재미가 없지 않을까요? 상품 내역도 스크립트 센터(microsoft.com/technet/scriptcenter/funzone/games/default.mspx)에서 확인하시기 바랍니다.

기초적인 데이터 입력 유효성 검사 정도는 이미 다들 수행하고 있으리라 생각합니다. 그리고 간단한 데이터 입력 유효성 검사만으로도 충분한 경우가 많습니다. strName이라는 문자열 값의 문자 수가 20개 이하인지를 확인하려는 경우 다음과 같은 간단한 코드만 있으면 됩니다.
If Len(strName) > 20 Then
    Wscript.Echo "Invalid name; a " & _
    "name must have 20 or fewer characters."
End If
하지만 strName이 4자리 숫자와 대문자 2개의 형식이어야 하는 새로운 부품 번호(예: 1234AB)라고 생각해 보십시오. 간단한 VBScript만 사용해 strName이 부품 번호의 필수 패턴에 맞는지 확인할 수 있을까요? 그렇습니다. 가능합니다. 하지만 바람직한 방법은 아닙니다. 대신 정규식을 사용하는 것이 좋습니다.

값에 숫자만 있는지 확인
정규식의 역사는 1950년대로 거슬러 올라갑니다. 당시에는 정규식이 수학적 표기법의 한 형태로 소개되었습니다. 그리고 1960년대에 이 수학적 모델이 QED 텍스트 편집기와 통합되면서 텍스트 파일에서 문자 패턴을 검색할 수 있게 되었습니다. 그 후에는... 그런데 독자분들 반응이? 아! 정규식의 역사에 별로 관심이 없으신가 보군요. 좋습니다. 그렇다면 바로 본론으로 들어가지요.
변수(예제의 경우 strSearchString 변수)에 숫자만 들어 있는지 확인하는 방법은 그림 1에서 볼 수 있습니다.
Figure 1 숫자만 필요 (Close Figure 1)
Set objRegEx = _
  CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "\D"

strSearchString = "353627"

Set colMatches = _
  objRegEx.Execute(strSearchString)

If colMatches.Count > 0 Then
    Wscript.Echo "Invalid: a " & _
      "non-numeric character was found."
Else
    Wscript.Echo "This is a valid entry."
End If
스크립트에서는 먼저 VBScript.RegExp 개체의 인스턴스를 생성합니다. 그렇습니다. 이 개체를 통해 스크립트에 정규식을 사용할 수 있습니다. 이것을 언급하고 싶었습니다. 다음에는 정규식 개체의 두 가지 핵심 속성인 Global과 Pattern에 값을 할당합니다.
Global 속성은 스크립트에서 특정 패턴의 모든 항목을 검색해야 할지, 처음으로 나타나는 해당 패턴만 찾고 검색을 중지해야 할지를 결정합니다. 일반적으로 이 값은 True로 설정하는 것이 좋습니다. 즉, 패턴의 모든 항목을 검색합니다. 참고로 기본값은 False이지만, True로 설정하는 것이 좋은 이유는 패턴의 모든 항목을 찾아야 하는 경우가 많기 때문입니다. 그렇지 않은 경우에도 패턴이 처음으로 나타나는 항목만 찾는 데 따른 이점은 문자열의 중간에서 검색이 중단되면 끝까지 검색할 때보다 스크립트 실행 속도가 약간 빨라지는 것 외에는 없습니다. 이론적으로는 False로 설정하는 것이 효과적인 방법처럼 보이지만 실제로 전체 문자열을 검색하더라도 실행 속도가 워낙 빨라서 차이를 느끼지 못합니다.
더 중요하게 살펴보아야 할 것은 Pattern인데, 여기에서 검색할 문자 및 문자 청사진을 지정합니다. 샘플 스크립트에서는 0에서 9 사이의 숫자 이외의 문자를 찾습니다. 이러한 문자(글자, 문장 부호 등)가 검색되면 strSearchString에 유효하지 않은 값이 할당된 것이겠죠. 정규식에서는 숫자가 아닌 문자를 찾는 데 \D라는 구문이 사용됩니다. 따라서 Pattern 속성에 \D 값을 할당합니다.
참고로, \D를 사용하면 숫자 이외의 문자가 검색되는지 어떻게 알게 되었을까요? 이와 관련해서는 이야기가 깁니다. 몇 년 전 MSDN® 기사(msdn2.microsoft.com/1400241x)의 VBScript 언어 참조에서 이에 대해 다루었습니다.
Global 속성과 Pattern 속성에 값을 할당한 후에는 다음과 같이 strSearchString 변수에 값을 할당합니다.
strSearchString = "353627"
문자열에 숫자 이외의 문자가 있는지 확인하려면 어떻게 해야 할까요? 간단합니다. 변수에서 숫자 이외의 문자를 검색하는 Execute 메서드를 호출하기만 하면 됩니다.
Set colMatches = _
objRegEx.Execute(strSearchString)
Execute 메서드를 호출하면 Pattern에 일치하는 검색된 항목이 자동으로 Matches 컬렉션에 저장됩니다. 샘플 스크립트에서는 이 컬렉션의 이름을 colMatches로 지정했습니다. 변수에 숫자 이외의 문자가 있는지 여부(샘플에는 있음)를 확인하려면 컬렉션에 있는 항목 수를 나타내는 컬렉션의 Count 속성 값을 확인하면 됩니다.
If colMatches.Count > 0 Then
    Wscript.Echo "Invalid: a " & _
      "non-numeric character was found."
Else
    Wscript.Echo "This is a valid entry."
End If
Count의 값이 0보다 크면 변수 값에서 숫자 이외의 문자가 발견된 것입니다. 값의 문자가 모두 숫자이면 이 컬렉션이 비어 있으므로 Count가 0이 됩니다. 다음으로 샘플 스크립트에서 숫자 이외의 문자가 발견되었다는 사실을 출력합니다. 실제 스크립트나 데이터베이스 프런트 엔드에서도 비슷한 메시지를 출력하고 사용자가 다시 시도할 수 있도록 루프를 실행합니다. 자세한 내용은 여러분의 몫으로 남겨 두겠습니다. 직접 살펴보시기 바랍니다. Scripting Guys는 이외에도 신경을 쓸 일이 너무 많습니다.
그게 뭐냐고요? 이를테면 TechNet Magazine에서 일하는 사람들이 매달 우리가 보내는 기사를 실제로 꼼꼼히 읽어보면 어쩌나 하는 걱정 등이 있죠. 우리 기사를 읽지 않고 자신들이 실수하고 있다는 사실을 계속 모른 채로 있어 주기만을 바라고 있거든요.
IsNumeric 함수를 사용하여 strSearchString에 숫자가 포함되어 있는지 여부를 확인할 수는 없냐고요? 좋은 질문입니다. strSearchString이 아무 숫자나 될 수 있다면 물론 가능합니다. 하지만 strSearchString이 양의 정수여야 한다면 문제가 발생할 수 있습니다. IsNumeric은 다음 두 숫자를 모두 유효한 숫자로 식별합니다.
-45
672.69
왜 이 두 숫자가 모두 유효한 숫자로 식별될까요? 양의 정수가 아닐 뿐이지, 유효한 숫자인 것은 사실이니까요. 샘플 스크립트의 정규식에서는 이러한 숫자를 잘못된 항목으로 표시하겠지만, 그것은 숫자 이외의 문자인 빼기 기호(–)와 마침표(.)를 인식하기 때문이지 잘못된 숫자이기 때문은 아닙니다. 여러분이 이 칼럼을 읽을 만한 이유가 되는 가장 중요한 내용이 바로 이 부분입니다.
뭐라고요? 이 정도로는 부족하다고요? 이번 달 독자들은 상당히 까다롭군요. 좋습니다. 그러면 정규식을 사용해 구현할 수 있는 다른 데이터 입력 유효성 검사 유형을 좀 더 살펴보도록 하겠습니다.

값에 숫자가 없는지 확인
앞에서는 값에 숫자만 있는지를 확인하는 방법을 살펴보았습니다. 그렇다면 반대로 값에 숫자가 없는지를 확인하려는 경우에는 어떻게 해야 할까요? 이 경우 다음 검색 패턴을 사용할 수 있습니다.
objRegEx.Pattern = "[0-9]"
이 코드는 어떻게 작동하는 것일까요? 험난하고 알 수 없는 정규식의 세계에서 대괄호 문자([ 및 ])는 문자 집합을 지정하거나, 이 예제 코드에서처럼 문자의 범위를 지정하는 데 사용할 수 있습니다. 그렇다면 Pattern [0-9]는 무엇을 의미할까요? 바로 0 ~ 9 범위에 있는 모든 문자, 즉 모든 숫자 값을 검색함을 의미합니다. 값에서 짝수만 허용하려면(즉, 값에 1, 3, 5, 7, 9가 없는지 확인하려는 경우) 다음과 같은 패턴을 사용합니다.
objRegEx.Pattern = "[13579]"
여기서는 하이픈을 사용하지 않았기 때문에 문자의 범위를 검색하는 것이 아닙니다. 구체적으로 말하면 1, 3, 5, 7, 9라는 실제 문자를 검색하는 것입니다.
물론 [0-9]라는 패턴을 사용하면 숫자만 검색되고 문장 부호 또는 글자도 아니고 숫자도 아닌 다른 문자는 검색되지 않습니다. 글자 이외의 문자를 찾는 패턴을 만들 수도 있을까요? 당연히 가능합니다. 정규식의 용도에는 거의 한계가 없으니까요.
objRegEx.Pattern = "[^A-Z][^a-z]"
이 예에서는 [^A-Z]라는 패턴과 [^a-z]라는 패턴을 함께 사용하여 해당 문자를 검색합니다. 쉽게 알 수 있듯이 A-Z는 대문자 A에서 Z까지의 문자 범위를 나타냅니다. 그런데 ^ 문자는 무엇을 의미할까요? 대괄호 안에 사용된 경우에 ^는 "해당 문자 집합에 포함되지 않은 모든 문자 검색"을 뜻합니다. 따라서 [^A-Z]는 "대문자가 아닌 문자 검색"을 의미합니다. 마찬가지로 [^a-z]는 "소문자가 아닌 문자 검색"을 의미합니다. 결과적으로 이 패턴은 대문자나 소문자가 아닌 모든 문자를 찾는 것임을 나타냅니다. 이러한 문자로는 숫자, 문장 부호 및 키보드에 있는 기타 특수 문자가 있습니다.
이러한 패턴을 사용하는 대신 IgnoreCase 속성을 True로 설정할 수도 있습니다.
objRegEx.IgnoreCase = True
이렇게 하면 검색 시 대/소문자를 구분하지 않습니다. 따라서 다음 Pattern을 IgnoreCase 속성과 함께 사용하면 대문자나 소문자가 아닌 모든 문자가 검색됩니다.
objRegEx.Pattern = "[^A-Z]"

부품 번호의 유효성 확인
이제 좀 더 복잡한 용도로 응용해 보겠습니다. regexlib.com 웹 사이트에서도 몇 가지 정규식 응용 예제를 살펴볼 수 있습니다. 기사의 앞 부분에서 strName이 4자리 숫자와 대문자 2개의 형식이어야 하는 새로운 부품 번호(예: 1234AB)인 경우를 예로 들었습니다. 변수가 이 패턴에 맞는지 확인하려면 어떻게 해야 할까요? 바로 다음과 같이 확인하면 됩니다.
objRegEx.Pattern = "^\d{4}[A-Z]{2}"
이 패턴은 무엇을 의미할까요? 이런 우연이 있을까요? 바로 우리가 설명하려고 했던 내용이군요. 이 경우 세 가지 검색 조건을 사용합니다.
^\d{4}
\d는 숫자(0에서 9 사이의 문자)를 검색함을 의미합니다. {4}는 무엇을 의미할까요? {4}는 4자리 숫자를 정확히 검색한다는 의미입니다. 결과적으로 연속된 4개의 숫자를 검색하는 것입니다.
다음으로 ^ 문자는 왜 사용된 걸까요? 대괄호 밖에 있는 ^는 값이 뒤에 나오는 패턴으로 시작해야 함을 의미합니다. 즉, AA1234AB는 일치하는 결과로 표시되지 않습니다. 그 이유는 값이 연속된 4개의 숫자가 아니라 AA로 시작하기 때문입니다. 필요에 따라서는 $ 문자를 사용하여 문자열이 특정 패턴으로 끝나야 함을 지정할 수도 있습니다. 하지만 이 예제에서 그러한 조건은 필요 없죠.
[A-Z]{2}
[A-Z] 구성 요소가 모든 대문자를 나타낸다는 사실은 이제 잘 아실 겁니다. 그리고 {2}는? 맞습니다. 4자리 숫자 뒤에 2개의 대문자가 와야 한다는 것을 의미합니다.
쉽지 않습니까? 이 예제에서 Count가 0이면 값이 잘못된 것입니다. 이 예제의 경우에는 문자열을 무효화하는 단일 문자를 검색하는 것이 아니라 정확한 기준에 해당하는 패턴을 검색하는 것이기 때문에 일치하는 결과가 없으면 값이 잘못되었음을 의미합니다. 이 경우 컬렉션의 Count 속성이 0이 되는 것입니다.
참고로, 유용한 다른 구성 요소로서 {3,}과 {3,7}이 있습니다. {3,}은 연속된 문자(또는 식)가 3개 이상 있어야 함을 나타냅니다. 단, 최소 요구 사항은 3개이지만 최대 개수에는 제한이 없습니다. \d{3,}은 123, 1234 및 123456789 모두를 결과로 검색합니다. {3,7}은 3개 이상 7개 이하의 연속된 문자(또는 식)가 있어야 함을 의미합니다. 따라서 123456은 일치하는 결과로 검색되지만 123456789는 연속된 숫자가 7개를 초과하기 때문에 검색되지 않습니다.
유용한 패턴을 하나 더 소개하겠습니다. 부품 번호가 4자리 숫자로 시작하고 그 뒤에 US라는 문자와 글자, 숫자 등 어떠한 문자도 될 수 있는 다른 두 개의 문자로 이루어진다고 가정해 보겠습니다. 이 부품 번호는 다음과 같이 확인합니다.
objRegEx.Pattern = "^\d{4}US.."
보다시피 이 패턴은 4자리 숫자(\d)로 시작하여 US라는 문자(US 이외의 문자는 검색되지 않음)가 뒤에 옵니다. US라는 문자 뒤에는 어떤 종류든 문자가 2개 더 필요합니다. 정규식에서 문자는 어떻게 나타낼까요? 흠, 잠시 생각 좀 해봐야겠군요. 아! 생각났습니다. 모든 단일 문자는 마침표(.)로 나타냅니다. 논리적으로 생각해보면 2개의 문자는 다음과 같이 2개의 마침표로 나타낸다는 사실을 쉽게 알 수 있습니다.
..
너무 쉽다고요? 그렇다면 좀 더 어려운 문제를 살펴보도록 하지요. 부품 번호 중간에 있는 2개 문자가 부품 생산지 국가를 나타낸다고 가정합니다. 미국, 영국, 스페인에 제조 공장이 있으면 US, UK, ES라는 2개 문자로 이루어진 코드가 유효합니다. 정규식에서 이러한 다중 선택은 대체 어떻게 구현해야 할까요?
다음 코드를 살펴보십시오.
objRegEx.Pattern = "^\d{4}(US|UK|ES).."
여기서 핵심은 (US|UK|ES)라는 구성 요소입니다. 허용되는 세 가지 값(US, UK, ES)을 괄호로 묶고 각각을 파이프(|) 문자로 구분했습니다. 정규식에서 다중 선택은 이러한 형태로 구현합니다.
그런데 대괄호 안에 여러 가지 옵션을 사용할 수 있다고 한 것을 기억하십니까? [13579]라는 예제가 바로 이에 대한 것이 아니었습니까? 그렇습니다. 하지만 이러한 옵션은 단일 문자의 경우에만 사용할 수 있습니다. 즉, [13579]는 항상 1, 3, 5, 7, 9로 해석됩니다. 135와 79를 선택 항목으로 사용하려면 (135|79)라는 구문을 사용해야 합니다. 괄호를 사용하여 검색할 단일 단어를 나타낼 수도 있습니다.
objRegEx.Pattern = "(scripting)"
또는 다음과 같이 괄호를 없앨 수도 있습니다.
objRegEx.Pattern = "scripting"
괄호의 여러 가지 사용 방법은 알았지만 괄호가 검색어의 일부로 포함되는 경우에는 어떻게 해야 할까요? 다시 말해 (scripting)이라는 문자열을 검색하는 경우에 말입니다. 정규식에서 여는 괄호와 닫는 괄호는 모두 예약된 문자이므로 각각의 괄호 문자 앞에 \를 붙여야 합니다. 즉, 다음과 같습니다.
objRegEx.Pattern = "\(scripting\)"

식의 해방
이번 달에 준비한 내용은 여기까지입니다. 정규식에 대해 더 자세히 알아보려면 String Theory for System Administrators: An Introduction to Regular Expressions(microsoft.com/technet/scriptcenter/webcasts/archive.mspx) 웹캐스트를 살펴보시기 바랍니다. 그리고 정규식에 대해 배우고 사용하기 전에 Sophia Loren의 다음과 같은 명언을 가슴에 새기시기 바랍니다. "실수란 충만한 삶을 얻기 위해 치러야 할 비용이지요."
우와! 이 말대로라면 Scripting Guys는 생각보다 충만한 삶을 살아왔었나 보군요!

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

2008년 1월: 낱말 맞추기
Dr. Scripto는 이번 달에 Windows PowerShell과 관련한 문제를 내기로 결정했습니다. 물론, Dr. Scripto가 항상 모든 것을 제대로 처리하기는 하지만 여러분은 바로 사용을 시작하는 경우가 아니라면 cmdlet 없이는 Windows PowerShell 작업이 불가능합니다. 이 퍼즐에서는 Dr. Scripto가 다음 표에 숨겨 놓은 몇 가지 cmdlet을 찾아야 합니다.
동사-명사의 형태로 구성되는 cmdlet의 특성상 Get-, Set- 등으로 시작되는 cmdlet이 수십 개씩 존재하므로 전체 cmdlet을 사용한다면 훨씬 어려운 퍼즐이 되겠지만 cmdlet의 동사 부분과 하이픈은 빼고 명사 부분만 생각하도록 합니다. 한 가지 힌트를 드리자면 사용된 cmdlet의 동사 부분은 모두 "Get-"입니다.
이제 여러분은 cmdlet 명사를 찾아내야 합니다. 친절하게도 퍼즐에 숨겨진 명사의 목록을 아래에 제시해 두었습니다. 각각의 단어는 가로 또는 세로로, 정상 순서 또는 역순으로 배치될 수 있으며, 대각선으로는 배치될 수 없습니다. 첫 번째 단어(Location)를 예시해 두었습니다. 자, 이제 시작해 보십시오.

단어 목록
Alias
ChildItem
Credential
Date
EventLog
ExecutionPolicy
Location
Member
PSSnapin
TraceSource
Unique
Variable
WMIObject

Dr. Scripto의 Scripting Perplexer
답: 낱말 맞추기, 2008년 1월

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


 Security Watch: 아일랜드 하핑: 미끼를 활용하는 침투 방식
Security Watch
아일랜드 하핑: 미끼를 활용하는 침투 방식
Jesper M. Johansson

보안이 취약한 연결 고리를 통해 네트워크에 침투한 다음 해당 네트워크에 속한 여러 시스템들을 돌아다니는 기법, 소위 아일랜드 하핑(island hopping)은 여러 해 전부터 사용되어온 침투 방식입니다. 이 기법은 새로운 차원으로 계속 발전하고 있습니다. 오늘날처럼 시스템 보안에 민감한 IT 환경에서는 사람이 가장 약한 연결 고리이며 악의적 사용자들은 바로 이 점을 악용할 방법을 찾고 있습니다. 피싱을 비롯한 여타 사회 공학적 침투 기법을 생각해보면 쉽게 이해할 수 있을 것입니다.
인적 요소와 기술적 요소를 결합한 이 침투 방식은 네트워크에 치명적 손실을 입힐 수 있습니다.
인적 요소를 활용한 실제 사례 가운데 제가 자주 예로 드는 것은 Secure Network Technologies의 Steve Stasiukonis가 어느 고객의 의뢰로 침투 테스트를 진행하면서 선보인 방법입니다. 그는 이 고객사의 주차장에 트로이 목마 프로그램이 설치된 USB 플래시 드라이브를 여기저기 뿌려 놓았습니다. 아침에 출근한 직원들은 주차장에 뿌려진 공짜 드라이브를 보고 아주 좋아했습니다. 직원들은 열심히 USB 드라이브를 주워서 맨 처음 눈에 띈 컴퓨터에 꽂았습니다. 바로 자신의 업무용 컴퓨터에 말입니다.
일부 현명한 직원들은 이 USB 드라이브를 보고도 무시하고 그냥 지나쳤을 수도 있지만, 단 한 명의 직원이라도 이 드라이브를 주워서 자기 시스템에 꽂았다면 네트워크 전체에 접근할 수 있는 침입로가 뚫리게 됩니다. 물론 Stasiukonis는 이 방법을 테스트 목적으로 사용했지만, 실제 범죄자들도 대기업 네트워크에 침투하기 위해 이 방법을 사용했습니다.
USB 플래시 드라이브는 현재 널리 사용되고 있습니다. 거의 모든 컨퍼런스 행사장에서 업체들이 USB 플래시 드라이브를 마치 사탕처럼 나눠주는 모습을 쉽게 볼 수 있습니다. 그러한 드라이브들은 용량이 크지 않겠지만 네트워크 전체를 장악하는 데 그리 큰 용량은 필요 없습니다. 전체 2부로 기획된 이 기사를 통해, 저는 이와 같은 종류의 침투 기법을 분석하고 그 위험을 줄이는 방법을 소개하고자 합니다. 먼저 이번 호에서는 USB 플래시 드라이브로 정확히 어떤 일을 수행할 수 있는지, 그리고 그것을 통제할 수 있는 방법은 무엇인지 설명하겠습니다. 그리고 다음 달 TechNet Magazine에서는 공격의 확산 범위를 네트워크의 일부 시스템으로 제한하는 방법을 소개할 예정입니다.
이 공격 방식의 기술적 측면은 실제로는 매우 간단합니다. 감염된 USB 플래시 드라이브를 컴퓨터 한 대에 꽂는 것만으로 모든 것이 시작됩니다. 그리고 그 이후의 사태는 USB 드라이브에 무엇이 들어 있는가, 그리고 사용자가 얼마나 어수룩한가에 따라 달라집니다.

문제의 발단
주변에 아무도 없는 상태로 연단에 노트북 한 대가 놓여 있다고 합시다. 연사는 프레젠테이션 시작 전에 좋은 분위기를 조성하기 위해 청중들과 담소를 나누느라 분주한 상태입니다. 노트북에는 잠금 장치가 되어 있지만 그것은 그리 장애가 되지 않습니다. 공격자는 연단에 올라가 마치 연사가 돌아오기를 기다리는 것처럼 잠시 서성입니다. 그 연단은 너저분한 것들이 가려지게 만들어졌기 때문에 USB 포트와 공격자의 손은 주변의 시선에 노출되지 않습니다. 일단 USB 플래시 드라이브를 컴퓨터에 꽂자, 불과 몇 초 만에 공격이 완료됩니다.
이러한 시나리오는 몇 가지 변화된 형태로 실행될 수 있습니다. 예를 들어 제가 매주 세계 여러 지역을 돌아다니며 프레젠테이션을 진행하던 때를 돌이켜보면 거의 매번, 프레젠테이션이 끝난 후 슬라이드 복사를 요청하는 분들이 있었습니다. 그러면 저는 항상 명함을 건네면서, 전자 메일로 메시지를 주시면 답신에 슬라이드를 첨부해서 보내드리겠노라고 답했습니다. 모든 분들이 USB 플래시 드라이브를 내밀면서 복사를 요청했는데도 왜 저는 굳이 그런 방법을 택했을까요? 그것은 제가 USB Hacksaw와 Switchblade 같은 침투 도구들을 알고 있기 때문입니다. 이에 관해 잘 모르시는 분들은 wiki.hak5.org의 내용을 참고하시기 바랍니다.
기본적으로 이 도구들을 이용하면 무방비 상태로 방치된 USB 포트를 누구나 쉽게 악용할 수 있습니다. 예를 들어 Switchblade를 이용하면 다음과 같은 정보를 수집할 수 있습니다.
  • 시스템 정보
  • 모든 네트워크 서비스
  • 수신 대기 중인 모든 포트의 목록
  • 컴퓨터에 있는 모든 Microsoft 제품 키
  • 로컬 암호 데이터베이스
  • 컴퓨터에서 사용하는 모든 무선 네트워크 암호
  • 현재 로그온한 사용자가 컴퓨터에 저장해 둔 모든 네트워크 암호
  • Internet Explorer®, 메신저, Firefox 및 전자 메일 암호
  • 모든 서비스 계정 암호가 일반 텍스트 형태로 들어 있는 LSA(로컬 보안 기관) 암호
  • 설치된 패치 목록
  • 최근 탐색 내역
이 모든 정보가 약 45초 만에 플래시 드라이브의 로그 파일에 수집됩니다.
Hacksaw는 여기서 약간 수정된 형태로서, 모든 USB 플래시 드라이브 삽입 이벤트를 모니터링하는 트로이 목마 프로그램을 컴퓨터에 설치합니다. 그러면 이 프로그램은 이후 그 컴퓨터에 삽입되는 모든 플래시 드라이브의 모든 문서를 공격자에게 전자 메일로 발송합니다.
이상 제가 설명한 도구들은 플래시 드라이브에 프로그램을 담아 다닐 수 있게 해주는 U3(u3.com)라는 기술을 사용합니다. 간단히 말해, U3 지원 플래시 드라이브는 자신의 정체를 속입니다. 이 드라이브는 자신이 플래시 드라이브와 CD가 연결되어 있는 USB 허브라고 OS에게 알립니다. Windows Vista® 이전의 Windows® 버전에서는 기본적으로, CD의 autorun.inf 파일에 지정되어 있는 프로그램을 자동으로 실행합니다. U3 지원 USB 플래시 드라이브는 자신의 정체를 속여 OS로 하여금 U3 시작 관리자라 부르는 어떤 프로그램을 자동 실행하게 만듭니다. 그러면 U3 시작 관리자는 프로그램을 시작하거나 메뉴를 표시하거나 또는 사용자가 직접 컴퓨터로 할 수 있는 작업과 비슷한 모든 작업을 수행할 수 있습니다.
공격 도구가 하는 일은 이 시작 관리자를 공격 코드로 교체하는 것뿐입니다. Windows XP 시스템에서는 플래시 드라이브를 꽂는 즉시 공격 도구가 자동으로 실행됩니다. Windows Vista에서는 이 자동 실행 여부가 다른 방식으로 결정됩니다. 자동 실행은 CD의 경우와 동일하게 이동식 장치에서도 작동됩니다. 이것은 장치를 꽂으면 어떤 동작이 이루어진다는 것을 의미합니다. 기본적으로 그림 1과 같은 자동 실행 대화 상자가 표시됩니다.
그림 1 그림이 있는 이동식 드라이브를 삽입한 경우 나타나는 기본 자동 실행 대화 상자
그림 1 그림이 있는 이동식 드라이브를 삽입한 경우 나타나는 기본 자동 실행 대화 상자
그림 1의 대화 상자에는 '그림에 대해 항상 다음 수행'이라는 옵션이 있습니다. 이 자동 실행 옵션은 그림 2와 같이 제어판에서도 구성할 수 있습니다.
그림 2 Windows Vista의 자동 실행 구성
그림 2 Windows Vista의 자동 실행 구성
이 자동 실행 구성은 '소프트웨어 및 게임'의 경우 특히 흥미롭습니다. 당연히, 그것은 실행할 일부 프로그램이 명시된 autorun.inf 파일이 이동식 드라이브에 있음을 의미합니다. 그림 2의 '소프트웨어 및 게임'과 관련된 설정들은 다음과 같은 레지스트리 키에 저장됩니다.
Hive:    HKEY_CURRENT_USER
Key:    \Software\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers\
UserChosenExecuteHandlers\AutorunINFLegacyArrival
Value: (Default)
Data:
MSAutoRun – automatically executes the program specified in the autorun.inf file

MSPromptEachTime – prompts the user, using strings specified in the autorun.inf file, if available
이 설정들은 시스템 관리자가 아니어도 변경할 수 있으므로 사용자는 원하는 대로 자유롭게 설정할 수 있으며, 따라서 주차장에서 습득한 드라이브에 어떤 악성 소프트웨어가 있든 자동으로 실행하도록 설정할 수도 있습니다. 실제로 자동 실행 대화 상자에서 해당 확인란에 표시하는 것만으로 사용자가 위험에 노출될 수 있습니다.

네트워크의 자동 실행 관리
관리자가 네트워크 전역의 자동 실행을 관리할 수 있는 방법은 몇 가지가 있습니다. 첫째, 자동 실행이 작동할 드라이브 유형을 제어하는 NoDriveTypeAutoRun 설정을 수정하면 사용자가 이동식 미디어와 CD에 자동 실행이 작동하도록 설정하는 것을 막을 수 있습니다. Windows XP의 기본 NoDriveTypeAutoRun 설정은 0x95입니다. 즉, 알 수 없는 드라이브 유형과 네트워크 드라이브, 이동식 장치 등에는 자동 실행이 작동하지 않게 되어 있습니다. Windows XP SP2에서부터는 NoDriveTypeAutoRun의 기본 설정이 0x91로 구성됩니다. 따라서 이동식 저장 장치에 자동 실행이 작동합니다. 그룹 정책을 이용할 경우, 사용자 구성\관리 템플릿\Windows 구성 요소\자동 실행 정책에 NoDriveTypeAutoRun 설정을 관리할 수 있는 설정이 있습니다. "Turn off AutoPlay setting and select CD-ROM and Removable Drives(자동 실행 설정을 끄고 CD-ROM 및 이동식 드라이브 선택)" 설정을 활성화하면 두 유형의 드라이브에 대해 자동 실행이 작동하지 않게 됩니다.
그러나 그 결과, 사용자는 그림 1과 같은 자동 실행 대화 상자를 볼 수 없게 됩니다. 실제로 사용자가 드라이브를 꽂았을 때 아무 일도 일어나지 않습니다. 하지만 드라이브에 있는 필요 정보에 어떻게 액세스해야 하는지 잘 모르는 사용자에게는 혼란을 유발할 수 있기 때문에 이 방법은 그리 이상적인 해결책이 아닙니다.
여러분은 자동으로 실행될 수 있는 콘텐츠 유형을 통제할 수 있기를 원할 것입니다. Windows Vista에서는 그것이 어느 정도 가능합니다. 이 운영 체제에서는 자동 실행 소프트웨어를 두 가지 수준으로 나누어 통제할 수 있기 때문입니다. 그림 3의 그룹 정책에 있는 또 하나의 컨트롤을 이용하면 autorun.inf 파일을 사용하는 소프트웨어의 자동 실행은 막으면서 그 나머지 자동 실행 동작은 그대로 둘 수 있습니다.
그림 3 그룹 정책을 통한 autorun.inf 파일 비활성화
그림 3 그룹 정책을 통한 autorun.inf 파일 비활성화
자동 실행이 결정되는 방식은 다소 복잡합니다. 아마도 순서도를 통해 설명하는 것이 가장 쉬운 방법일 것입니다. 그림 4는 이동식 미디어에 있는 파일의 자동 실행 여부가 결정되는 과정을 보여주고 있습니다.
그림 4 자동 실행 순서도
그림 4 자동 실행 순서도

또 다른 발단들
물론, 이것들은 USB 플래시 드라이브로 컴퓨터를 위험에 빠뜨리는 데 사용되는 방법 중 일부에 불과합니다. 현재 로그온한 사용자의 Windows NT® 암호 해시를 수집하는 도구 등을 비롯하여 온갖 종류의 도구들이 이 시나리오에 동원될 수 있습니다(microsoft.com/technet/community/columns/secmgmt/sm1005.mspx 참고).
사실 많은 USB 컨트롤러들이 DMA(직접 메모리 액세스) 장치입니다. 즉, 운영 체제를 우회하여 컴퓨터의 메모리를 직접 읽고 쓸 수 있는 것입니다. 운영 체제를 우회하게 되면 운영 체제의 보안 통제도 피할 수 있어 하드웨어를 마음대로 완벽하게 액세스할 수 있게 됩니다. 즉, 운영 체제의 장치 통제력이 완전히 무력화되는 것입니다. 현재 이러한 기법을 사용하는 해킹 도구를 알고 있지는 않지만 없다고 단정하기는 매우 어렵습니다.
사용자와 이동식 장치를 조합해서 악용하는 또 다른 방법은 구미가 당기는 옵션을 제시하는 것입니다. 예를 들어 그림 5와 같은 대화 상자가 표시되었을 때 클릭할 사용자들이 얼마나 많겠습니까? 전부는 아니라도 꽤 많은 사람들이 클릭할 것입니다. 요점은, 무시하기에는 너무 구미가 당기는 대화 상자를 꾸며내는 것은 아주 간단한 일이라는 사실입니다.
그림 5 사용자 유인
그림 5 사용자 유인

장치 차단
Windows Vista에서부터 그룹 정책에는 장치 설치를 제어하는 일련의 정책들이 제공됩니다(그림 6 참고). 그림에서와 같이 관리자는 이동식 장치임이 드라이버에 명시된 모든 새로운 이동식 장치에서 설치 작업이 실행되는 것을 차단할 수 있습니다. 그러나 드라이버에서 자신이 이동식 장치가 아니라고 할 경우, 이 정책은 효과가 없습니다. 그러므로 드라이버를 조작하면 이 정책을 피해갈 수 있습니다.
그림 6 Windows Vista 장치 설치 정책
그림 6 Windows Vista 장치 설치 정책
더욱 세밀한 통제를 위해, 특정 장치 설치 클래스에 대해 작동하는 정책을 활용할 수 있습니다. 그러나 이를 위해서는 차단하고자 하는 특정 장치 클래스의 GUID를 알아야 하므로 관리하기 매우 어렵게 됩니다.

최소 권한이 야기하는 문제
DMA 시나리오를 잠시 논외로 한다면 앞서 논의한 공격의 성공, 그리고 그 대응책의 성공 여부는 컴퓨터 사용자의 권한에 달려 있습니다. 일반 사용자라면 공격이 야기할 수 있는 피해 규모는 제한적입니다. 사용자의 데이터를 비롯하여 그 사용자가 액세스할 수 있는 모든 것을 훔쳐갈 수는 있겠지만, 네트워크에 큰 피해를 주지는 않을 것입니다.
그러나 이용당하는 사용자가 관리자라면 결과는 엄청나게 악화될 수 있습니다. 최악의 경우 해당 사용자가 도메인 관리자라면 네트워크 전체를 장악당할 것이 자명합니다. 예를 들어 공격자는 사용자의 암호 해시를 메모리에서 추출할 수 있습니다. 시스템에서는 로그온 시 LSA 프로세스 공간에 해시를 임시 저장하므로, 이것을 활용하면 사용자를 가장하여 아무 제지 없이 네트워크 리소스에 액세스할 수 있습니다. 관리자 권한을 가진 공격자는 이 해시 정보를 추출하여 모든 네트워크 리소스에 액세스할 수 있는 것입니다. 달리 말해, 이용 당하는 사용자가 도메인 관리자라면 도메인 전체가 위험에 빠진 것입니다.
따라서 의존 관계 문제가 자연스럽게 제기됩니다. 지금까지는 워크스테이션을 대상으로 하는 특정 공격을 간략히 설명했습니다. 그러나 그것이 네트워크 전체 규모에서 초래할 결과에 대해서는 설명하지 않았습니다. 다음 호 칼럼에서는 의존 관계의 개념을 다루면서 그것이 환경 전체에 어떤 의미를 갖는지, 특히 그 의존 관계를 확고히 강화하는 방법은 무엇인지 설명하겠습니다.

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


 The Desktop Files: Windows SteadyState를 사용한 공유 컴퓨팅
The Desktop Files
Windows SteadyState를 사용한 공유 컴퓨팅
Wes Miller

지난 10년 사이에 컴퓨터 실습실에서 일을 해 본 이는 잘 알고 있을 문제를 한 가지 소개하겠습니다. 필자가 대학 시절에 경험했던 일입니다. 당시 실험실 컴퓨터는 학생증 소지자에게 24시간 개방되어 있었고 일단 도서관에 들어온 사용자는 아무 제한 없이 사용할 수 있도록 사실상 방치되었습니다.
따라서 게임을 즐기던 학생들이 실험실에 들어와 게임 실행을 위해 중요한 Windows® 및 MS-DOS® 파일을 마음대로 수정할 수 있었습니다. 덕분에 컴퓨터에서 게임은 원활이 실행되지만 Windows가 정상적으로 작동하지 않거나 전혀 실행되지 않는 문제가 발생하곤 했습니다. 이러한 경험은 누구에게나 한 번쯤 있으리라 생각합니다. 공유 컴퓨터에 문제가 발생해 정작 필요할 때 제대로 사용할 수 없게 되는 상황 말입니다.
얼마 전 필자는 텍사스의 사우스파드레이 섬으로 휴가를 다녀왔습니다. 당시 묵었던 호텔의 숙박객용 컴퓨터실에는 Windows XP가 탑재된 컴퓨터가 세 대 있었습니다. 이들 Windows 컴퓨터는 누구나 관리자 계정으로 사용할 수 있었고 사용자 관리 정책도 없었습니다. 즉, 이 불쌍한 컴퓨터들은 방문객이 유해한 소프트웨어를 설치하고 중요 응용 프로그램을 삭제하거나 변경하는 통에 심하게 몸살을 앓고 있었습니다. 호텔 측에서 이러한 의도로 컴퓨터를 마련해 둔 것은 분명 아닐 텐데 말이죠. 여기서 알 수 있는 분명한 사실은 호텔이든 실습실이든, 공공 장소에 비치된 공유 컴퓨터는 가정용 컴퓨터와는 비교할 수 없을 정도로 열악한 사용 환경에 노출된다는 점입니다.

해결책
SteadyState 다운로드 및 사용
Windows SteadyState는 go.microsoft.com/fwlink/?LinkId=104721에서 무료로 다운로드할 수 있습니다. 또한 SteadyState에 대한 자세한 정보는 microsoft.com/windows/products/winfamily/sharedaccess에서 참조할 수 있습니다.
Windows SteadyState는 Windows XP 실행이 가능한 모든 시스템에서 사용할 수 있습니다. SteadyState가 SCT에 비해 가장 크게 향상된 점은 파티션을 따로 만들지 않고도 Windows Disk Protection(Windows 디스크 보호)을 수행할 수 있는 기능입니다.
아래 표에는 SteadyState의 시스템 요구 사항이 요약되어 있습니다. SteadyState는 모든 버전의 Windows XP에서 지원되지만 파일 시스템이 NTFS 형식이어야 한다는 점을 유의하시기 바랍니다. 현재 SteadyState는 Windows Vista®에서 지원되지 않습니다.

구성 요소 | 요구 사항
프로세서 | 300MHz 이상(최소 233MHz)
메모리 | 128MB 이상(최소 64MB, 일부 기능과 성능이 제한될 수 있음)
하드 디스크 | Windows Disk Protection(Windows 디스크 보호)을 사용하지 않을 경우 최소 1.5GB의 여유 공간 필요, Windows Disk Protection(Windows 디스크 보호)을 사용할 경우 최소 4.0GB의 여유 공간 필요
운영 체제 | Windows XP Home Edition, Windows XP Professional 또는 Windows XP Tablet PC Edition. Windows XP SP2 설치 필수
지원되는 언어 | 영어, 네덜란드어, 프랑스어, 이탈리아어, 일본어, 포르투갈어(브라질), 중국어(간체), 스페인어
파일 시스템 | NTFS 형식 파일 시스템
액세스 권한 | 관리자 수준 액세스 권한

지난 해 저의 칼럼을 꾸준히 읽었거나 일반적인 Windows 배포 작업에 익숙하신 분들은 '시스템 이미지를 만들어 복원하면 되지 않을까' 하고 생각하실 수도 있겠습니다. 그러나 실제로 경험해 보신 분들은 그게 말처럼 간단하지 않다는 사실을 잘 알고 계실 것입니다. 매일 또는 매주 빨간색의 커다란 이미지 다시 작성 단추를 누른다고 해결될 일은 아니니까요.
여러 해 전, 필자는 친구와 함께 PC방 사업을 고려해 본 적이 있습니다. 1995년의 일인데, 당시에는 상당히 독창적인 아이디어였습니다. 가장 우려했던 점은 시스템의 신뢰성과 가용성을 제대로 유지하는 문제였습니다. 아쉽게도 당시로서는 이미지를 전부 다시 작성하거나 아주 약간 더 견고한 솔루션을 이용하는 방법 외에 간단히 적용할 수 있는 문제 해결책은 없었습니다.
문제를 자세히 살펴보면 공유 컴퓨터의 보안을 위해서는 다음과 같은 세 가지 조건이 충족되어야 한다는 것을 알 수 있습니다.
  • 사용자에게 관리자 권한이 부여되지 않도록 해야 합니다. 공유 컴퓨터에서는 항상 이 조건이 지켜져야 합니다.
  • 정책을 수립, 적용하여 시스템의 보안을 최대한 유지해야 합니다. 그렇게 하면 사용자가 시스템에서 액세스 권한이 없는 부분을 마음대로 조작할 가능성이 낮아집니다.
  • 사용자가 임의로 변경한 항목을 모두 원래대로 되돌려 놓을 수 있어야 합니다. 관리자 권한이 없더라도 메뉴나 즐겨찾기 등을 잘못 바꿔 놓을 수 있기 때문입니다.
다행히 Microsoft는 여러 해 동안 바로 이러한 시나리오에 도움이 되는 도구 집합을 준비해 왔습니다.

SteadyState의 역사
1년여 전에 Microsoft는 Windows SCT(Shared Computing Toolkit)를 출시했습니다. Windows 정품 혜택 프로그램 인증 시스템에서 무료로 다운로드할 수 있는 이 도구 키트는 특히 도서관이나 PC방, 실습실 등의 공유 컴퓨터 환경을 염두에 두고 설계되었습니다. 당시 TechNet Magazine 2006년 7월호(technetmagazine.com/issues/2006/07/UtilitySpotlight)에서 SCT에 관한 기사를 보셨을 것입니다.
그리고 Windows SteadyStateTM로 이름이 바뀐 새로운 버전(microsoft.com/windows/products/winfamily/sharedaccess)이 2007년 6월에 등장했습니다. 새 버전의 이름이 바뀐 이유 중 하나는 도구 집합이 이전 버전과 크게 달라졌기 때문입니다. 곧 설명하겠지만, 새로운 버전의 기능은 전 버전과 동일합니다. 그러나 제작 팀에서는 전반적인 사용 편의성에 초점을 두고 시스템에 긴밀히 통합되며 설치와 관리가 더 쉽도록 SteadyState를 개발했습니다. 더욱 강력하고 유연한 기능을 제공하며, 주요 구성 요소 중 하나에 대한 Active Directory® 통합을 지원합니다. 즉, 몇 가지 완전히 새로운 엔터프라이즈 시나리오에서 더욱 높은 유연성을 제공합니다. 또한 이제는 Windows Update 통합이 지원되므로 업데이트를 적용할 때 Windows Disk Protection(Windows 디스크 보호)을 알아서 끌 수 있는 지능형 기능을 갖추게 되었습니다. 덕분에 SteadyState에서 시스템을 관리함으로써 관리 업무 부담을 크게 줄일 수 있습니다.

SteadyState의 기능
Windows SteadyState는 컴퓨터별로 보안 및 구성 옵션을 잠그는 Computer Restrictions(컴퓨터 제한), Windows 시스템 파티션 변경 사항을 캐시에 저장하고 원래대로 되돌리는 Windows Disk Protection(Windows 디스크 보호), 사용자 계정의 생성, 편집, 가져오기 및 불러오기 기능을 제공하는 User Account Manager(사용자 계정 관리자), 그리고 마지막으로, 사용자별 보안 및 구성 옵션을 잠그는 User Restrictions and Settings(사용자 제한 및 설정) 등 크게 네 가지 구성 요소로 이루어집니다.
SCT(Shared Computing Toolkit)에 비해 개선된 기능 가운데 눈에 띄는 것 중 하나는 사용자 도움말입니다. 시작 가이드는 SteadyState의 설치와 실행에 도움이 됩니다. 이제 앞서 간략히 설명한 주요 기능에 비추어 SteadyState에서 제공하는 네 가지 주요 작업에 대해 자세히 살펴보겠습니다.
  • Computer Restrictions(컴퓨터 제한) 설정(Computer Restrictions(컴퓨터 제한))
  • Schedule Software Updates(소프트웨어 업데이트 예약). SteadyState가 Windows Update를 자동으로 적용할지 여부를 지정할 수 있습니다. Windows 디스크 보호 작업이 자동으로 처리되고 몇 가지 유명 바이러스 백신 프로그램의 서명도 업데이트해 주므로 권장되는 설정입니다.
  • 하드 디스크 보호(Windows 디스크 보호)
  • 사용자 추가(User Account Manager(사용자 계정 관리자))
Add User(사용자 추가)의 User Restrictions and Settings(사용자 제한 및 설정)에는 사용자별 구성 옵션이 있습니다.

컴퓨터 및 사용자의 제한과 설정
Windows 그룹 정책을 많이 다루어 보았다면 SteadyState의 Computer Restrictions(컴퓨터 제한) 설정과 User Restrictions and Settings(사용자 제한 및 설정)가 낯설지 않을 것입니다. SteadyState 관리자는 Windows XP Home Edition(이 버전에서 SteadyState는 지원됨)에서는 제공되지 않는 그룹 정책 개체 편집기(GPEdit.msc)를 사용하지 않고도 공유 컴퓨팅 시나리오에서 공통적으로 사용되는 몇 가지 주요 보안 및 구성 옵션을 편리하게 설정할 수 있습니다.
그림 1에는 Computer Restrictions(컴퓨터 제한) 설정 구성 화면이 나와 있습니다. 이는 전체 컴퓨터에 적용되는 일반 설정임을 유의하시기 바랍니다. 이러한 설정은 시스템의 보안 위험, 그리고 특히 USB 드라이브를 사용하는 경우 시스템에서 뭔가 삭제할 가능성을 최소화하기 위해 주로 선택됩니다. 사용자별 설정을 자세히 살펴보면 일부 또는 모든 드라이브에 대한 읽기 액세스를 차단할 방법도 찾을 수 있습니다.
그림 1 SteadyState의 Computer Restrictions(컴퓨터 제한)
그림 1 SteadyState의 Computer Restrictions(컴퓨터 제한)
그런데 USB 설정은 실제로 SteadyState가 구성되어 있는 Windows 시스템에서 실행될 때만 작동합니다. 따라서 오프라인 공격을 막으려면 USB 또는 CD 장치를 통한 부팅을 차단하도록 BIOS를 구성하고 BIOS 자체를 암호로 보호해야 합니다.
물론 이러한 설정이 절대적 안전을 보장하는 것은 아닙니다. "악의적인 해커가 실제로 액세스할 수 있다면, 그것은 더 이상 당신의 컴퓨터가 아니다"는 10가지 불변의 보안 법칙"(microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx)의 세 번째 법칙을 기억하시기 바랍니다. 누군가 적절한 도구를 사용하여 충분한 시간을 투자해 몰두한다면 BIOS 암호를 무력화할 수 있는 경우도 많습니다.

Windows Disk Protection(Windows 디스크 보호)
CD를 통해 Windows XP Embedded를 사용해 보았거나 Windows PE 2.0을 사용해 보았다면 지금 필자가 설명하려는 내용이 낯설지 않을 것입니다. 그리고 다행히도 이 둘은 공통된 내력을 가지고 있습니다. Windows 디스크 보호는 시스템 파티션의 모든 변경 사항을 같은 파티션의 캐시 영역에 저장함으로써 Windows 시스템 파티션을 이전 상태로 완벽하게 되돌리는 기능을 제공합니다. SteadyState는 여러 시스템 사용자가 오랜 시간 동안 변경한 내용을 되돌릴 수 있는 구성 요소이므로 이는 매우 중요한 기능입니다.
Windows 디스크 보호는 주로 시간이 지남에 따라 시스템을 예기치 않게 다시 시작한 후 또는 예약된 간격에 시스템을 초기 배포 상태로 신속히 되돌리려는 경우에 유용합니다. 그리고 그림 2와 같이 대화 상자를 통해 네 가지 모드를 설정할 수 있습니다.
그림 2 Windows 디스크 보호 구성
그림 2 Windows 디스크 보호 구성
Off(해제): Windows Disk Protection(Windows 디스크 보호)이 전혀 작동하지 않으며 모든 변경 내용이 디스크에 정상적으로 기록됩니다.
On—Discard changes at reboot(사용-다시 부팅할 때 변경 사항 삭제): Windows Disk Protection(Windows 디스크 보호)을 사용하며 컴퓨터를 다시 시작할 때마다 모든 변경 내용이 삭제됩니다. 기본적으로 이는 이 옵션을 선택하여 저장한 시점의 상태로 시스템이 복구된다는 것을 의미합니다.
On—Discard changes at set time(사용-설정된 시점에 변경 사항 삭제): 위의 옵션과 거의 동일하지만 다음 번 다시 시작 시점이 아니라 설정된 시각에 변경 내용이 삭제된다는 점이 다릅니다. 이 모드는 매일 또는 매주 변경 내용을 삭제하려는 경우에 적합합니다.
On—Retain changes permanently(변경 내용 영구 유지): Off(해제) 모드와 혼동하기 쉽지만 어디까지나 임시 모드라는 점이 다릅니다. 예를 들어 이 모드는 응용 프로그램 업데이트 적용, 새 응용 프로그램 설치 또는 시스템 구성 시 사용할 수 있습니다. 이 모드는 일반적으로 장기간 적용되지는 않습니다.
모드를 전환하려면 컴퓨터를 다시 부팅해야 한다는 점을 유의하시기 바랍니다.

Schedule Software Updates(소프트웨어 업데이트 예약)
SteadyState는 Windows 디스크 보호를 자동으로 설정하고 해제할 수 있는 Schedule Software Updates(소프트웨어 업데이트 예약)라는 편리한 기능을 제공합니다. SteadyState에서 업데이트를 자동으로 처리하도록 설정한 경우 업데이트를 진행하는 동안 변경 내용이 유지되도록 Windows 디스크 보호의 설정이 변경되었다가 업데이트가 끝난 후 이전 설정으로 다시 돌아갑니다. 관리 업무에서 큰 부분을 차지하는 작업을 덜 수 있으므로 이는 권장되는 설정입니다.
소프트웨어 업데이트의 기능을 통해 업데이트가 지원되는 보안 소프트웨어로는 Computer Associates eTrust 7.0, McAfee VirusScan, Windows Defender, TrendMicro 7.0 등이 있습니다.

User Account Manager(사용자 계정 관리자)
Add User(사용자 추가) 옵션을 사용하면 시스템의 새 사용자를 구성할 수 있습니다. 그림 3에는 이름, 암호, 사용자를 나타내는 이미지, 사용자 프로필의 위치 등 새 사용자에 적용할 수 있는 옵션이 나와 있습니다. 사용자를 생성하면 해당 로컬 계정별로 User Restrictions and Settings(사용자 제한 및 설정)를 구성할 수 있습니다. 특히 시스템에 계정을 추가하고 구성한 후 필요에 따라 그 계정을 내보내 다른 시스템에서 불러오거나 보관할 수 있으므로 매우 편리합니다.
그림 3 사용자 계정 추가
그림 3 사용자 계정 추가
User Account Manager(사용자 계정 관리자)의 편리한 점 중 하나는 그림 3에 나와 있는 사용자 위치 메뉴를 통해 다른 파티션에 사용자 프로필을 만들어 둘 수 있다는 점입니다. 설치 시 unattend.txt 파일을 통해 Documents and Settings 폴더의 위치를 직접 다른 곳에 지정한 경우를 제외하고 일반적으로 프로필은 Windows 파티션에 만들어야 합니다. SteadyState는 Windows 디스크 보호를 사용할 경우 Windows 시스템 파티션 변경 내용을 모두 삭제하므로 이 방식이 특히 유용합니다. Windows 디스크 보호 캐시가 삭제되더라도 사용자의 프로필이 일관되게 유지되도록 하려면 User Account Manager(사용자 계정 관리자)를 통해 사용자를 만들 때 해당 사용자의 프로필이 다른 로컬 파티션에 저장되도록 지정하기만 하면 됩니다.
이 프로세스는 다시 부팅하여 Windows 디스크 보호 캐시를 지우고 업데이트를 적용한 후 다시 부팅하여 Windows 디스크 보호를 다시 시작하는 방식으로 실행됩니다. Windows Update 외에도 SteadyState는 지원되는 몇 종의 유명 바이러스 백신의 서명 파일을 자동으로 업데이트해 줍니다. 자세한 내용은 "SteadyState 다운로드 및 사용" 추가 기사를 참조하십시오. 사용 중인 응용 프로그램이 지원되지 않거나 다른 업데이트 프로그램을 실행해야 하는 경우에는 여러분이 직접 업데이트 작업을 처리할 수 있습니다. 단, 이때에는 Windows 디스크 보호가 작동되지 않도록 해야 서명 업데이트가 지워지지 않고 유지됩니다.

User Restrictions and Settings(사용자 제한 및 설정)
사용자를 선택하고 나면 SteadyState에서 사용자 제한이 4개의 범주로 분류됩니다. 이 분류는 그룹 정책 설정을 따르므로 아마 익숙할 것입니다.
일반 설정에서는 사용자 프로필과 강제 로그오프 구성을 제어합니다. 여기에는 프로필 잠금 설정과 지정된 사용 시간 또는 유휴 시간이 경과된 후 로그아웃하는 시간 제한 설정이 포함됩니다.
그림 4의 Windows 제한 설정에서는 Windows 자체의 구성 항목을 제어합니다. 예를 들어 시작 메뉴 구성 요소와 Windows 탐색기 기능과 같은 Windows 사용자 인터페이스 항목에 대한 액세스를 차단할 수 있습니다. 드라이브 문자를 지정하여 특정 드라이브에 대한 액세스를 차단하거나 CD 굽기를 금지할 수도 있습니다.
그림 4 Windows 자체 사용자 제한
그림 4 Windows 자체 사용자 제한
그림 5의 Feature Restrictions(기능 제한) 탭에서는 Internet Explorer®의 대부분 기능에 대한 액세스 권한을 세부적으로 제어할 수 있으며, Internet Explorer 홈페이지를 설정하고 Microsoft® Office 기능을 어느 정도(주로 Visual Basic® for Applications(VBA) 스크립트 실행 여부) 제어할 수 있습니다
그림 5 기능 제한
그림 5 기능 제한
Block Programs(프로그램 차단) 설정(그림 6)에서는 기본적으로 블랙리스트를 만들어 특정 응용 프로그램의 실행 여부를 제어할 수 있습니다. 이 목록에는 몇 가지 일반적인 응용 프로그램이 들어 있으며 사용자가 다른 응용 프로그램을 추가할 수 있습니다. 추가된 항목은 지정된 경로를 기준으로 차단된다는 점을 유의하십시오. 따라서 사용자가 응용 프로그램을 시스템의 다른 위치로 옮길 수 있도록 허용하면 이 경로 규칙이 더 이상 적용되지 않습니다. 그러나 다른 방법을 통해 파일 및 디렉터리 ACL과 액세스 제한을 시스템에 적절히 적용한다면 응용 프로그램을 쉽게 옮길 수 없도록 할 수 있습니다.
그림 6 프로그램 실행 차단
그림 6 프로그램 실행 차단
SteadyState의 중요한 새 기능 중 하나는 Windows Restrictions(Windows 제한) 및 Feature Restrictions(기능 제한)에 모두 관련된 제한 수준을 지정하는 미리 구성된 템플릿을 기반으로 합니다. 이 템플릿을 사용하면 원하는 기능 잠금 수준에 따라 작동하는 기준 구성을 보다 손쉽게 설정할 수 있습니다. 물론 사용자 지정 템플릿도 만들 수 있습니다.

SteadyState의 한계
SteadyState는 공유 컴퓨팅 시스템의 안정화에 크게 기여합니다. 상용 제품으로서도 손색이 없으며 무료 도구로서는 더할 나위 없이 훌륭합니다. 그러나 SteadyState도 만능은 아닙니다.
공유 컴퓨팅 시스템은 공격에 쉽게 노출되며 의도하지 않은 오용의 가능성도 매우 높습니다. 따라서 이러한 시스템은 액세스를 허용할 필요가 없는 정보로부터 반드시 격리되어야 합니다. SteadyState에서도 응용 프로그램 액세스를 차단할 수 있지만 이러한 강제 조치는 소프트웨어 제한 정책을 통해서 처리됩니다. 몇 년 전에 Mark Russinovich가 지적했듯이 겉으로는 양호한 것처럼 보이지만 '제한된 사용자' 계정으로도 이러한 정책을 무력화할 수 있도록 응용 프로그램을 만드는 기법들이 엄연히 존재합니다(blogs.technet.com/markrussinovich/archive/2005/12/12/circumventing-group-policy-as-a-limited-user.aspx). 모든 장치 액세스와 인터넷 액세스를 차단하는 수준에는 이르지 못하고 있다는 점은 반드시 기억해 두어야 할 취약점입니다. 제 3법칙을 절대 잊지 마십시오.
SteadyState는 공유 컴퓨팅 시스템을 효과적으로 설정하는 데 필요한 하나의 구성 요소에 불과합니다. Windows Update를 통해 정기적으로 업데이트를 적용하고 Windows 방화벽 또는 다른 방화벽을 올바로 구성하는 것이 중요합니다. 또한 컴퓨터의 위험 요소를 분석하여 바이러스 백신과 스파이웨어 방지 프로그램, 기타 보안 수단을 반드시 설치하고 구성해야 합니다. 마찬가지로 컴퓨터에 대한 액세스를 통제해야 하며, 그것이 불가능할 경우에는 해당 컴퓨터를 통해 볼 수 있는 내용을 통제해야 합니다. 그리고 기밀 데이터를 로컬에 저장해서는 안 됩니다.
마지막으로 플랫폼을 검사할 때에는 SteadyState(Windows 디스크 보호를 사용하는 상태)를 비롯하여 해당 시스템에서 실행하고자 계획하는 모든 추가 소프트웨어의 사용도 테스트 항목에 포함해야 합니다. 이러한 소프트웨어와 SteadyState가 서로 최적의 방식으로 연동되도록 해야 하기 때문입니다.

SteadyState에 대한 지원
필자가 확인한 SteadyState에 대한 사용자 반응은 매우 긍정적이었습니다. 소소한 문제점이 몇 가지가 지적되었는데, 그 중 일부는 사용자를 추가할 때 지켜야 하는 순서와 관련된 것이었습니다. SteadyState 응용 프로그램과 설명서의 여러 위치에 편리하게 링크되어 있는 Windows SteadyState 커뮤니티(forums.microsoft.com/windowstoolsandutilities)에서는 이러한 문제점들을 비롯하여 기타 유용한 팁들이 활발히 다뤄지고 있습니다.
또한 사용을 시작하기에 앞서 SteadyState 길잡이(go.microsoft.com/fwlink/?LinkId=104722)를 미리 읽어 보는 것이 좋습니다. 여기에는 SteadyState를 효과적으로 사용하는 데 필요한 몇 가지 팁이 수록되어 있습니다.

요약
SteadyState는 액세스 제어가 필요한 모든 Windows XP 시스템에 활용할 수 있는 훌륭한 기능을 다수 갖추고 있으며, 무엇보다 무료로 제공되고 있습니다. Windows Disk Protection(Windows 디스크 보호)이 획기적으로 개선되고 사용자 인터페이스가 크게 향상되어 공유 액세스 컴퓨터의 설치와 관리가 전반적으로 크게 간편화될 것입니다.
SteadyState를 사용하면 컴퓨터 실습용 시스템이나 방문객 또는 직원 공용 단말기, 교육실 또는 기타 다양한 공유 컴퓨팅 환경에서 시스템을 더욱 쉽게 설치하고 관리, 운영할 수 있습니다. 또한 시스템의 복구를 위해 매주 이미지를 다시 작성하지 않아도 됩니다. 개인적으로 이것만 해도 엄청난 발전이라고 생각합니다.

Wes Miller는 텍사스 오스틴 소재 Initiate Systems(InitiateSystems.com)에서 기술 제품 관리자로 근무하고 있습니다. 이전에는 Winternals Software에서 Microsoft 프로그램 관리자로 근무했습니다. 문의 사항이 있으신 분은 technet@getwired.com으로 연락하시기 바랍니다.


 Field Notes: 하루 중 가장 중요한 작업
Field Notes
하루 중 가장 중요한 작업
Eric N. Bush

빌 게이츠 는 일년에 두 번 "사색의 주"라는 기간을 두어 업무에서 벗어납니다. 이 기간 동안 사람들, 전화 및 전자 메일을 완전히 차단하고 하루 종일 독서를 하며 Microsoft 및 오늘날 존재하는 기술이 처한 상황에 대해 깊이 생각합니다. 이러한 과정을 통해 Microsoft와 다른 기업의 현 주소를 돌아보고 보다 전략적인 방식으로 나아갈 수 있는 방법을 찾으려 애쓰며 시간을 보냅니다. 그는 심사 숙고하고 계획을 세우는 것의 가치를 잘 알고 있습니다.
매일 아이디어를 체계화하고, 문제를 해결하고, 작업에 우선 순위를 부여하며, 목표를 설정하고, 공상에 잠기는 등 생각하고 계획을 세우는 데 시간을 들이는 것은 우리에게 커다란 도움이 될 수 있습니다. 다른 사람과의 상호 작용을 차단하고 매일 같은 시간과 장소에서 이러한 시간을 가지는 연습을 해 보십시오. 우리가 해야 할 일 중 가장 중요한 것은 하루의 계획을 세우고 우선 순위를 부여하는 것입니다. 만일 여러분이 관리자라면 다른 사람과의 작업을 계획하고 우선 순위를 부여하는 데 대부분의 시간을 보낼 것입니다.
여러분의 업무가 기업 네트워크 관리이든, 주요 데이터베이스 관리이든, 기업 정보 시스템 설계 및 관리이든, 업무를 어렵게 만드는 문제들이 매일 발생하기 마련입니다. 하루를 마감하며, 성공적으로 업무를 마쳤는지 아닌지를 구분하기란 쉽지 않습니다.
여러분의 목적은 앞선 시각으로 바라보고, 체계적으로 준비하며, IT와 관련한 긴급 상황에 보다 잘 대처하는 것일 것입니다. 계획을 세움으로써, 현상에 대해 수동적으로 대처하는 것에서 나아가 사전에 대책을 강구할 수 있게 됩니다. 하지만 이러한 변화를 꾀하려면, 미리 심사숙고해서 계획을 세우고 우선 순위를 정해야 합니다. 이렇게 하면 진행 중, 즉시 실행, 가능할 때 실행이라는 세 가지 범주로 구분된 작업 목록을 만들어 매일 이 목록을 검토하는 것으로 하루를 시작할 수 있게 됩니다. 이 목록을 사용하면 문제 발생을 애초에 방지할 수 있습니다.
진행 중 목록은 지금 바로 착수해야 하는 업무에 해당합니다. 이러한 중요한 작업은 매일 매일 진전이 있어야 합니다. 여러분의 회사와 그룹의 최우선 목표가 가장 먼저 진행해야 할 작업입니다. 이러한 우선 순위에 직접적인 영향을 미치지 않는 작업은 목록 아래쪽에 기입하십시오. 관리자는 모든 임직원이 최우선 순위를 동일하게 유지할 수 있도록 프로세스를 배치해야 합니다.
즉시 실행 및 가능할 때 실행 목록은 일반적으로 업무 시간과 비용을 절약하여 경쟁력 향상에 도움을 줄 수 있는 전략적 계획에 대한 항목에 해당합니다. 이러한 작업을 확인하고 천천히, 규칙적으로 이를 추진하여 해당 작업의 우선 순위가 높아지면 진행 중 목록으로 옮깁니다.
잊지 말아야 할 것은 이렇게 우선 순위가 부여된 목록이 있다고 해서 모든 업무가 실제로 진행되는 것은 아니라는 점입니다. 다음은 작업을 처리하는 데 도움이 되는 몇 가지 팁입니다.
  • 빠르고 쉬운 업무를 우선적으로 처리합니다.
  • 다음으로, 별로 내키지 않는 업무를 처리합니다.
  • 마지막으로, 흥미로운 업무를 처리합니다.
  • 위의 순서가 변경되지 않도록 하며 가능한 한 모든 업무를 일렬로 정렬합니다.
  • 하지만, 한 가지 업무를 처리하는 데 어려움이 생기는 경우, 해당 문제를 처리할 수 있게 될 때까지 다른 업무를 먼저 처리합니다.
  • 직접 수행하기 힘든 업무는 다른 사람에게 위임하거나 거절하거나 다른 방법을 제안합니다.
  • 본인이 업무를 가장 효율적이고도 생산적으로 처리할 수 있는 시간이 언제인지를 파악한 후 그 시간에 중요한 업무를 처리합니다.
현명한 시간 배분 방법을 알고 있으면 업무를 효율적으로 처리할 수 있게 됩니다. 계획 없이 떠도는 사람들은 처음 시작이 어디였는지를 알 수 없으므로 목표에 도달했을 때도 성취감을 느끼지 못합니다.

Eric N. Bush는 Microsoft의 Engineering Excellence 부서에서 근무하는 소프트웨어 개발 책임자입니다. Eric은 사내 컨설턴트 및 강사로서 개인적 기량, 프로세스 및 기술을 엔지니어링 측면에서 체계적으로 향상시키기 위해 노력하고 있습니다. 문의 사항이 있으면 ericbush@microsoft.com으로 연락하십시오.