 TechNet Magazine May 2008

TechNet Magazine May 2008

Windows Administration: Windows Server 2008에서 Active Directory 백업 및 복원

Windows Server 2008 및 여기에 포함된 새로운 Windows Server 백업 유틸리티는 백업에 많은 변화 및 유용한 기능 향상을 가져왔습니다. 이 기사에서는 새로운 서버 OS에서 Active Directory를 백업하고 복원하는 방법을 자세히 안내합니다.

Gil Kirkpatrick Windows Administration: 사용 가능한 OU 구조 설계

생각보다 많은 관리자들이 올바르게 설계된 조직 구성 단위 구조의 중요성을 과소 평가하고 있습니다. 안정된 OU 전략을 사용하는 것이 중요한 이유를 알아보고 조직에 가장 적합한 OU 구조를 결정하십시오.

Ken St. Cyr Windows Administration: Active Directory 스키마 확장

Active Directory를 사용하는 많은 응용 프로그램은 자체 변경 내용을 스키마로 정의합니다. 하지만 이러한 변경 내용은 다른 응용 프로그램에 영향을 미치지 않는다는 점이 중요합니다. classSchema 및 attributeSchema 개체를 통해 Active Directory를 확장하는 방법에 대해 간략하게 살펴보겠습니다.

Vikas Malhotra System Center: System Center Mobile Device Manager 소개

새로운 System Center Mobile Device Manager는 MMC 스냅인 또는 Windows PowerShell을 통해 Windows Mobile 장치를 관리하는 데 필요한 모든 도구를 제공합니다. 이러한 필수적인 도구를 통해 어떻게 모바일 장치를 관리하고, 보안을 강화하고, 모바일 VPN 기능을 제공할 수 있는지 알아보겠습니다.

Matt Fontaine System Center: System Center Essentials SP1의 새로운 기능

System Center Essentials 2007은 서비스 팩 1에서 기능이 크게 개선되었습니다. 사용자 환경을 개선하고 관리를 원활하게 하는 주요 변경 사항에 대해 알아봅니다.

Pete Zerger From the Editor: "Inside SharePoint" 소개의 글

Joshua Hoffman Letters: 독자의 목소리

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

Greg Steen Exchange Queue & A: Exchange 2007 SPI 배포

이번 칼럼에서는 Exchange Server 2007 SP1 관련 질문에 대한 답을 드립니다.

Nino Bilic Utility Spotlight: SharePoint 용량 계획

이 문서에서는 SharePoint Capacity Planning Tool에 대해 알아보고 SharePoint 배포 토폴로지를 설계한 후 부하 및 사용 시뮬레이션을 실행하여 그 결과를 토대로 토폴로지를 수정하는 방법을 살펴봅니다.

Peter Skjøtt Larsen and Satish Mathew Inside Sharepoint: SharePoint 인프라 구축

SharePoint는 강력하지만 복잡하기 때문에 배포가 다소 까다로울 수 있습니다. 새로운 SharePoint 칼럼은 이러한 문제를 해결하는 데 도움이 되는 내용을 소개합니다. 이번 첫 번째 호에서는 SharePoint 아키텍처의 개요 및 WSS 3.0으로 기본 SharePoint 인프라를 구축하는 방법에 대해 설명합니다.

Pav Cherny Windows PowerShell: 디렉터리 관리 자동화

Windows PowerShell 버전 1에서 제공하는 Active Directory 관리 기능에는 눈여겨볼 부분이 그다지 많지 않습니다. 이 문서에서는 추가 기능을 사용하여 Windows PowerShell 내에서 Active Directory 개체를 더욱 효과적으로 다루는 방법을 살펴봅니다.

Don Jones Hey, Scripting Guy!: 모나리자의 눈썹과 정규식

Scripting Guys로부터 루브르 박물관을 다녀온 이야기와 유명 예술품에 대한 감상, 그리고 찾기 및 바꾸기 작업을 수행하는 스크립트에 정규식을 사용하는 방법에 대해 들어봅니다.

The Microsoft Scripting Guys Security Watch: 양자 보안 원리

빠르게 진화하는 보안 전략에 하이젠베르크의 불확정성 원리와 양자 물리학의 요소가 어떤 식으로 도움이 될 수 있는지 알아봅니다. 참고: 이 기사를 쓰는 과정에서 학대당한 고양이는 없음을 밝힙니다.

Jesper M. Johansson The Desktop Files: 이제는 관리자와 결별할 때

왜 모두 관리자로 실행하는 걸까요? Wes Miller는 관리자 계정으로 실행할 경우의 위험성에 대해 알아보고, 관리자 자신은 물론 관리자가 관리하고 있는 사용자를 사용자 계정으로 실행하도록 전환할 경우 얻을 수 있는 이점에 대해 살펴보고자 합니다.

Wes Miller Field Notes: 한 대의 PC에 여러 개의 마우스

교실에 컴퓨터 수보다 학생 수가 많다면 어떻게 해야 할까요? Microsoft Research India에서는 한 대의 컴퓨터에 여러 개의 마우스를 사용할 수 있는 MultiPoint라는 솔루션을 개발했습니다.

Kentaro Toyama Windows Confidential: 구식이 된 16비트 아이콘

Raymond Chen은 Windows Vista가 16비트 아이콘을 지원하지 않는 이유에 대해 알아보고 그것을 눈치 챈 사람이 없는지 살펴보고자 합니다.

Raymond Chen


 Windows Administration: Windows Server 2008에서 Active Directory 백업 및 복원
Windows Administration Gil Kirkpatrick

Windows Server 2008에서 Active Directory 백업 및 복원
한 눈에 보기:
  • NTBACKUP과 Windows Server 백업 비교
  • 백업 도구 및 옵션
  • 복구 도구 및 옵션
  • 강력한 Active Directory 백업 전략을 위한 핵심 요소

누구나 알고 있듯이 ADDS(Active Directory 도메인 서비스)는 Windows 인프라에서 매우 중요한 구성 요소입니다. Active Directory가 중단되면 네트워크가 쓸모없게 됩니다. 따라서 Active
Directory의 백업 및 복구 계획은 보안, 비즈니스 연속성 및 규정 준수를 위한 기본 요소입니다.
Windows Server® 2008에서 Active Directory®에 많은 새로운 기능이 추가되었으며 그 중 새로운 Windows Server 백업 유틸리티와 Active Directory의 볼륨 섀도 복사본 서비스 스냅숏 작업 기능은 백업과 복구 계획에 큰 영향을 미칩니다. 이 기사에서는 이러한 기능 향상이 가져온 변경 내용을 소개하고 이러한 변경 내용을 활용하여 Active Directory 백업 작업을 효율적으로 수행하는 방법을 살펴봅니다.

NTBACKUP과 Windows Server 백업 비교
그룹 정책 설정
Windows Server 백업은 서버에서 백업이 작동하는 방식을 어느 정도 제어할 수 있는 몇 가지 그룹 정책 설정을 제공합니다. 이 백업 정책을 사용하면 사용자가 무단으로 백업을 수행하여 권한이 없는 데이터에 액세스함으로써 발생할 수 있는 몇 가지 위험에 대처할 수 있습니다. 다음과 같은 옵션을 사용할 수 있습니다.
Allow Only System Backup(시스템 백업만 허용) 이 옵션을 설정하면 Windows Server 백업은 주요 시스템 볼륨만 백업할 수 있고 볼륨 백업은 수행할 수 없습니다.
Disallow Locally Attached Storage as Backup Target(로컬로 연결된 저장소를 백업 대상으로 허용 안 함) 이 옵션을 설정하면 로컬로 연결된 드라이브로 백업할 수 없습니다. 네트워크 공유로만 백업할 수 있습니다.
Disallow Network as Backup Target(네트워크를 백업 대상으로 허용 안 함) 이 옵션을 설정하면 어떠한 네트워크 공유로도 백업할 수 없습니다.
Disallow Optical Media as Backup Target(광 미디어를 백업 대상으로 허용 안 함) 이 옵션을 설정하면 Windows Server 백업에서는 기록 가능 DVD 드라이브와 같은 어떠한 광학 장치로도 백업할 수 없습니다.
Disallow Run-Once Backups(백업 한 번 실행 허용 안 함) 이 옵션을 설정하면 Windows Server 백업에서는 예약되지 않은 임시 백업을 실행할 수 없습니다. Windows Server 백업 MMC 스냅인을 통해 예약된 백업만 실행할 수 있습니다.

Windows NT® 3.5 이후에 많이 사용되던 NTBACKUP은 이제 사라지고 대신 Windows Server 백업이 사용되고 있습니다. 이 새로운 도구는 NTBACKUP의 기능을 약간 좋게 향상시킨 것이 아니라 시스템 백업 방법을 다시 생각하게 하는 전혀 새로운 백업 기술입니다.
Windows® Server 백업은 Windows Server 2008의 기본 백업 솔루션이기는 하지만 단순히 NTBACKUP의 기능을 대신하는 솔루션으로는 볼 수 없습니다. 가장 큰 차이점은 Windows Server 백업이 디스크 대 디스크 백업 솔루션이라는 점입니다. 즉, 테이프로의 백업은 지원하지 않습니다. 직접 연결 디스크 볼륨 및 네트워크 공유뿐 아니라 외부 USB 하드 드라이브 및 다중 볼륨 기록 가능 DVD에도 백업 이미지를 만들 수 있습니다. 하지만 테이프로는 백업할 수 없습니다. 물론 Windows Server 2008 서버에 테이프 드라이브를 연결하고 Windows Server 백업에서 생성된 백업 이미지를 테이프 드라이브로 복사할 수는 있지만 이렇게 하려면 다른 소프트웨어를 사용해야 합니다.
NTBACKUP은 파일 기반 백업 및 복원 도구지만 Windows Server 백업은 볼륨 및 블록 기반 도구입니다. Windows Server 백업에서는 백업 소스를 볼륨 집합으로 다루며 각 볼륨은 디스크 블록의 모음으로 다룹니다. 이러한 방식은 파일 시스템을 통해 파일을 백업하는 방식보다 훨씬 효율적입니다. 또한 블록 단위로 백업을 처리하기 때문에 Windows Server 백업에서는 볼륨 섀도 복사본 서비스 스냅숏을 사용하여 블록 수준의 증분 백업을 수행할 수 있을 뿐 아니라 대상 볼륨에 스냅숏을 만들어 여러 백업을 간단하게 사용하고 백업에서 사용하는 공간도 절약할 수 있습니다.
전체 백업을 수행하는 경우에도 Windows Server 백업에서는 대상 디스크의 공간을 매우 효율적으로 이용합니다. 예를 들어 같은 볼륨에 대해 여러 번의 전체 백업을 수행하는 경우, Windows Server 백업은 백업 이미지가 저장되는 대상 디스크에서 볼륨 섀도 복사본 서비스 스냅숏을 사용하기 때문에 스냅숏에는 변경된 블록만 저장됩니다. 따라서 여러 번의 전체 백업에 사용되는 공간이 크게 줄어듭니다. 이렇게 되면 증분 백업을 복구하기 위해 여러 번의 복원 작업을 수행할 필요가 없습니다. 스냅숏에 각 백업의 델타(변경된 블록)만 저장된 경우라도 볼륨 섀도 복사본 서비스를 통해 각 백업은 완전한 백업으로 나타납니다.
하지만 로컬 하드 디스크로 백업할 경우에만 대상 디스크에서 볼륨 섀도 복사본 서비스 스냅숏의 이점을 얻을 수 있습니다. Windows Server 백업에서는 DVD나 네트워크 공유에 저장된 백업에 대해 볼륨 섀도 복사본 서비스 작업을 수행할 수 없습니다.
또한 Windows Server 백업에서는 백업 이미지를 Microsoft® VHD(가상 하드 디스크) 형식으로 저장합니다. 실제로 백업 이미지를 만들어 Microsoft Virtual Server 2005에서 실행되는 가상 컴퓨터에 볼륨으로 탑재할 수 있습니다. 특정 파일이 어느 테이프에 있는지 확인하기 위해 테이프의 테스트 복원을 수행할 필요 없이 가상 컴퓨터에 VHD를 탑재하고 해당 파일을 탐색하기만 하면 됩니다. 주의: 백업 이미지를 만들어 해당 이미지에서 가상 컴퓨터를 부팅할 수 없습니다. 백업된 하드웨어 구성이 가상 컴퓨터의 구성과 다르기 때문에 실제 구성을 가상 구성으로 마이그레이션하는 도구로서 Windows Server 백업을 사용할 수 없습니다.
Windows Server 백업의 볼륨 및 블록 기반 특성에는 단점도 있습니다. 이 새로운 도구는 백업 소스를 볼륨 및 블록 집합으로 인식하기 때문에 선택한 파일만 백업할 수 없습니다. 즉, 전체 볼륨을 백업해야 합니다. 더욱 큰 문제는, 기본적으로 현재 백업하고 있는 볼륨 중 하나에 백업 이미지를 저장할 수 없다는 점입니다. 이 문제를 해결하는 몇 가지 방법이 있습니다. 이에 대해서는 support.microsoft.com/kb/944530을 참조하십시오. 이 문제는 이 기사의 뒷부분에서 설명하는 것처럼 시스템 상태 백업에 깊은 영향을 미칩니다.

Windows Server 백업 설치
Windows Server 백업은 Windows Server 2008의 "기능"이며 기본적으로 설치되지 않습니다. Windows Server 백업으로 백업을 수행하려면 서버 관리자 또는 다음 SERVERMANAGERCMD 명령줄 유틸리티를 사용하여 이 기능을 설치해야 합니다.
C:\> servermanagercmd -install Backup-Features
Windows Server 백업은 두 가지 하위 기능인 Windows Server 백업과 명령줄 도구로 구성됩니다. 명령줄 도구는 WBADMIN .EXE 명령줄 도구가 아니라 Windows PowerShellTM cmdlet 집합을 가리킵니다. 따라서 두 하위 기능을 모두 설치하기로 선택한 경우에는 Windows PowerShell 기능을 설치해야 합니다.
Windows Server 백업을 설치한 후에 Administrative Tools(관리 도구) 메뉴와 Server Manager(서버 관리자)의 Storage(저장소) 노드 아래에서 MMC(Microsoft 관리 콘솔) 스냅인을 찾을 수 있습니다. Windows Server 2008 Server Core 설치에 Windows Server 백업을 설치할 때는 OCSETUP 명령을 사용합니다. 이때 OCSETUP 명령은 대/소문자를 구분한다는 점에 유의해야 합니다.
C:\> ocsetup WindowsServerBackup
설치 프로세스에 대한 전체 설명을 보려면 go.microsoft.com/fwlink/?LinkId=113146을 참조하십시오.
NTBACKUP으로 만든 이미지는 Windows Server 백업에서 복원할 수 없습니다. 자주 발생하지는 않지만 이러한 경우에 사용할 수 있도록 Microsoft는 다운로드 가능한 Windows Server 2008용 NTBACKUP 버전을 제공합니다(go.microsoft.com/fwlink/?LinkId=113147 참조).

Windows Server 백업 구성 요소
Windows Server 백업 응용 프로그램의 설계 방식도 크게 변화되었습니다. 이 새로운 백업 솔루션은 다음 네 가지 구성 요소로 구성됩니다.
  • MMC 사용자 인터페이스(WBADMIN.MCS)
  • 명령줄 인터페이스
(WBADMIN.EXE)
  • 백업 서비스(WBENGINE.EXE)
  • Windows PowerShell cmdlet 집합
응용 프로그램을 클라이언트와 서비스로 분리하면 몇 가지 장점이 있는데 그 중 가장 중요한 장점은 안정성이 향상된다는 것입니다. MMC 클라이언트 또는 명령줄 인터페이스에서 백업을 시작하면 WBENGINE 서비스는 많은 작업을 수행합니다. 반면 클라이언트 프로그램은 백업의 상태만 보고합니다. 따라서 클라이언트를 종료해도 백업이 불완전해지지는 않습니다. 즉, 클라이언트는 중지되지만 서비스는 백업이 완료될 때까지 계속 진행됩니다. 물론, 실제로 백업을 중지하려는 경우에는 명시적으로 중지할 수 있습니다.
이렇게 분할된 아키텍처의 다른 장점은 클라이언트를 사용하여 원격 컴퓨터에서 백업을 관리할 수 있다는 것입니다. 이 장점은 Windows Server 2008 Core 컴퓨터를 백업해야 할 경우에 특히 유용합니다.
Windows Server 백업에서는 Windows Server 2008 설치 미디어에 함께 제공되는 Windows 복구 환경(WinRE)을 사용한 BMR(Bare Metal Restore)을 지원합니다. WinRE는 서버를 처음부터 복구하는 프로세스를 단순화합니다. BMR(Bare Metal Restore) 수행에 대해서는 이 기사의 뒷부분에서 다룹니다. Windows Server 백업에서는 백업 관리를 위한 몇 가지 그룹 정책 설정을 지원합니다. 이 내용은 "그룹 정책 설정" 추가 기사에 간략하게 소개되어 있습니다.

볼륨 섀도 복사본 서비스
Windows Server 백업에서는 볼륨 섀도 복사본 서비스를 세 가지 방식으로 사용합니다. Windows Server 2008에서 전체 백업을 시작하면 응용 프로그램에서는 제일 먼저 모든 소스 볼륨의 섀도 복사본을 만듭니다. 이렇게 하면 백업 소프트웨어가 작업할 파일 시스템에 대한 일관된 보기가 만들어집니다. 이 과정은 NTBACKUP에서 수행되는 과정과 비슷합니다. 그런 다음 Windows Server 백업은 소스 볼륨의 블록을 블록 단위로 백업 대상에 복사하여 이 프로세스에서 백업된 각 볼륨에 대한 VHD 이미지를 만듭니다.
또한 다른 옵션을 지정한 경우가 아니면 Windows Server 백업에서는 볼륨 섀도 복사본 서비스가 볼륨에서 변경된 블록을 모두 추적할 수 있도록 소스 볼륨의 스냅숏도 만듭니다. 이를 통해 Windows Server 백업은 소스 볼륨의 변경된 블록만 읽으면 되는 블록 수준의 증분 백업을 만들 수 있습니다. 파일에서 1비트만 변경되었는데도 전체 파일을 읽고 써야 하는 기존 방식과는 달리, Windows Server 백업에서는 변경된 블록만 읽고 쓰면 됩니다.
따라서 매우 효율적인 증분 백업이 만들어지지만 소스 볼륨에서 쓰기 작업을 위한 추가적인 디스크 I/O 비용이 발생합니다. 작업량이 많거나 성능이 중요한 볼륨을 백업할 경우 성능 구성 설정 링크를 선택한 다음 해당 볼륨에서 증분 백업을 사용하지 않도록 설정하여(그림 1 참조) 소스 볼륨에서 볼륨 섀도 복사본 서비스 스냅숏을 사용하지 않도록 해야 합니다.
그림 1 작업량이 많은 볼륨에서 증분 백업을 사용하지 않도록 설정
그림 1 작업량이 많은 볼륨에서 증분 백업을 사용하지 않도록 설정
백업이 완료되면 Windows Server 백업에서는 대상 볼륨의 스냅숏을 만듭니다(로컬로 연결된 하드 드라이브로 백업한다고 가정). 다음 백업을 수행하는 동안 대상 VHD 파일은 덮어쓰기됩니다. 하지만 볼륨 섀도 복사본 서비스에서 대상 볼륨의 섀도 복사본을 유지하므로 실제로는 각 전체 백업에 해당하는 개개의 VHD 파일이 여러 버전 존재합니다. 이렇게 한 번의 전체 백업과 변경된 블록의 비용만으로 여러 개의 전체 백업을 얻을 수 있습니다.

네트워크 공유로 백업
네트워크 공유로 백업하는 것은 로컬 볼륨으로 백업하는 것처럼 쉽습니다. 중요한 차이점은 네트워크 공유로 백업하면 원격 볼륨의 볼륨 섀도 복사본 서비스 스냅숏을 만들 수 없다는 점입니다. 따라서 각 전체 백업은 이전 백업을 덮어쓰며 이에 따라 네트워크 공유에는 각 서버의 최신 전체 백업 이미지만 남게 됩니다. 이러한 제한 때문에 Windows Server 백업 스케줄러를 사용하여 네트워크 공유로 백업을 예약할 수 없습니다. 하지만 Windows 작업 스케줄러를 사용하여 네트워크 공유로 전체 백업을 수행하는 WBADMIN 명령줄 프로그램을 실행할 수 있습니다. 이 방법을 사용하여 네트워크 공유로 전체 백업을 예약하는 경우에는 이전 백업을 덮어쓰지 않도록 각 백업의 대상 폴더를 변경하십시오.

기록 가능 DVD로 백업
Windows Server 백업에서는 쓰기 가능한 DVD와 같은 광 미디어로의 백업도 지원합니다. 또한 여러 볼륨에 걸쳐 있는 백업 세트도 만들 수 있습니다. Windows Server 백업에서는 항상 백업을 DVD로 압축하기 때문에 DVD에서 전체 시스템 또는 전체 볼륨 복원만 수행할 수 있습니다. DVD를 사용할 때는 Windows Server 백업에서 시스템 상태 또는 파일 수준의 백업 및 복원을 지원하지 않습니다. 또한 DVD로의 백업을 예약할 수 없습니다.

시스템 상태 백업 및 복원
전체 볼륨이 아니라 선택된 파일 및 일부 응용 프로그램 데이터베이스만 포함되는 시스템 상태 백업은 매우 간편하며 꼭 필요한 경우가 많습니다. 하지만 Windows Server 2008의 초기 빌드에서는 시스템 상태 백업 및 복원을 지원하지 않았습니다. 대신 백업 도구에서 주요 시스템 볼륨, 즉 OS와 주요 응용 프로그램의 복구 및 다시 부팅에 필요한 볼륨만 백업했습니다. 이러한 주요 시스템 볼륨은 시스템 상태 백업의 볼륨 기반 방식이었습니다.
Microsoft에서는 고객 피드백을 수용하여 Windows Server 백업에 시스템 상태 백업 및 복원 기능을 추가했습니다. 응용 프로그램에서는 시스템 상태 데이터를 호스팅하는 각 볼륨마다 하나씩 여러 VHD 파일을 만들지만 필요한 파일과 데이터베이스만 VHD에 복사합니다. 다른 문제는 시스템 상태 백업을 수행할 때 Windows Server 백업에서 일반 백업 프로세스에서처럼 대상 볼륨의 스냅숏을 만들지 않는다는 점입니다. 대신 각 시스템 상태 백업은 완전히 새로운 VHD 파일 집합을 생성합니다. 즉, 스냅숏 기반 볼륨 백업처럼 공간을 효율적으로 활용하지 못합니다.
시스템 상태 백업은 WBADMIN.EXE 명령줄 프로그램을 통해서만 수행할 수 있습니다. MMC 스냅인에서는 이 옵션을 제공하지 않습니다. 시스템 상태 백업을 수행하려면 다음 명령을 사용합니다.
C:\> wbadmin start systemstatebackup
–backuptarget:e:
그러면 WBADMIN은 주요 시스템 파일과 응용 프로그램 데이터베이스를 대상 볼륨에서 시스템 상태 백업용으로 예약된 폴더에 백업합니다. 기본 DIT(디렉터리 정보 트리)가 있는 32비트 Windows Server 2008 DC(도메인 컨트롤러)에서의 시스템 상태 백업은 6GB가 조금 넘습니다. Windows Server 백업은 NTBACKUP과 달리 핵심 OS 파일을 캡처하기 때문에 이 크기는 Windows Server 2003에서보다 5GB 이상 더 큽니다.
당연히 시스템 상태를 백업하는 데 걸리는 시간도 더 깁니다. 물론 이러한 초기 수치는 OS의 시험판 버전을 기준으로 한 것이므로 각자의 환경에서 테스트해봐야 하지만, 도메인 컨트롤러를 Windows Server 2008로 이동할 경우 시스템 상태 백업이 더 커지고 백업 시간도 더 길어질 수 있다는 것을 예상하고 계획을 세워야 합니다.

MMC를 사용하여 서버 백업
Windows Server 백업 MMC(그림 2 참조)를 실행할 경우 백업 일정을 설정하거나 임시 백업을 즉시 실행할 수 있습니다. 여기서 필자는 Backup once(한 번 백업)를 선택하여 즉시 백업을 수행합니다.
그림 2 Windows Server 백업 MMC
그림 2 Windows Server 백업 MMC
그림 3에서 볼 수 있듯이 서버의 모든 볼륨을 백업할지 아니면 필자가 선택한 것처럼 특정 볼륨만 백업할지 선택할 수 있습니다. Full server(전체 서버)를 선택하면 Windows Server 백업은 탑재된 모든 볼륨을 백업하지만 탑재된 하드 드라이브로 백업하는 옵션이 없으므로 대신 기록 가능 DVD 또는 네트워크 공유로 백업해야 합니다.
그림 3 백업 구성 대화 상자를 사용하여 모두 백업 또는 볼륨 선택
그림 3 백업 구성 대화 상자를 사용하여 모두 백업 또는 볼륨 선택
이 예제에서는 로컬 하드 드라이브를 백업하려고 하므로 Custom(사용자 지정) 옵션을 선택합니다. 그러면 백업할 볼륨을 선택할 수 있는 대화 상자가 열립니다(그림 4 참조). Windows Server 백업에서는 "Enable system recovery(시스템 복구 사용)" 상자가 기본적으로 선택됩니다. 이 상자가 선택된 경우 Windows Server 백업은 부트 볼륨, OS 볼륨 및 주요 시스템 파일과 응용 프로그램 데이터베이스가 있는 기타 볼륨을 선택합니다. DC에서는 SYSVOL, Active Directory DIT 및 Active Directory 로그를 호스팅하는 볼륨이 여기에 포함됩니다. 이 백업 방식은 시스템 상태 백업과 동일하지만 해당 볼륨의 주요 파일만이 아니라 모든 주요 볼륨을 백업합니다. 실제로 시스템 복구 백업 세트에서 시스템 상태 복구를 수행할 수도 있습니다.
그림 4 백업할 특정 볼륨 선택
그림 4 백업할 특정 볼륨 선택
대상 유형(로컬 드라이브 또는 네트워크 공유)을 선택하고 대상을 지정하면 Windows Server 백업에서 "VSS copy(VSS 복사본)" 백업 또는 "VSS full(VSS 전체)" 백업을 선택하라는 메시지를 표시합니다. 두 옵션 모두 선택된 볼륨을 전체적으로 백업하기 때문에 용어가 약간 혼동스럽습니다. 두 옵션의 차이점은 Windows Server 백업에서 백업 후 소스 파일을 처리하는 방식에 있습니다. 복사본 옵션을 선택하면 Windows Server 백업은 백업된 파일을 그대로 둡니다. 전체 옵션을 선택하면 Windows Server 백업은 아카이브를 다시 설정합니다.

명령줄에서 서버 백업
백업 프로세스를 스크립트로 수행하려고 하거나 Server Core 설치에서 서버를 백업하는 경우에는 WBADMIN.EXE 명령줄 프로그램을 사용할 수 있습니다. WBADMIN에서는 백업 일정 관리를 포함하여 기본적으로 MMC 스냅인과 같은 기능을 수행하는 전체 옵션 집합을 제공합니다.
WBENGINE 서비스를 시작하여 백업 프로세스를 수행하려면 다음 명령만 입력하면 됩니다.
C:\> wbadmin start backup –include:c:,d:
–backuptarget:e:
또는 주요 시스템 볼륨을 모두 백업하려면 다음 명령을 입력할 수 있습니다.
C:\> wbadmin start backup -allcritical
–backuptarget:e:
백업을 시작하면 WBADMIN은 계속 실행되면서 백업 진행률을 표시합니다. WBADMIN을 종료하면 백업은 백그라운드에서 계속됩니다. 다음 명령을 사용하여 실행 중인 백업에 WBADMIN을 다시 연결할 수 있습니다.
C:\> wbadmin get status
실행 중인 백업을 종료하려면 다음을 입력합니다.
C:\> wbadmin stop job

MMC를 사용하여 백업 예약
Windows Server 백업에 통합된 백업 스케줄러는 로컬 디스크 볼륨으로의 매일 전체 시스템 백업을 간단하게 예약할 수 있는 기능을 제공합니다. 기본 제공 스케줄러를 사용하여 자동으로 백업을 여러 대상 볼륨 간에 돌아가며 수행할 수 있습니다. 쉽게 이동할 수 있는 하드 드라이브 또는 USB 연결 하드 드라이브를 사용하는 경우에는 이와 같은 기능으로 백업 디스크를 분리하여 별도의 장소에 보관하고 다음으로 예약된 백업을 위해 가장 오래된 백업 디스크를 서버에 다시 연결하는 순환 방식을 설정할 수 있습니다.
Windows Server 백업 스케줄러에서는 항상 매일 수행되는 백업만 예약할 수 있습니다. 예를 들어 월요일, 수요일, 금요일에 백업하도록 예약하는 방법은 없습니다. 따라서 예약된 백업을 매일 실행하지 않으려면 Windows 작업 스케줄러에서 직접 작업해야 합니다.
로컬 디스크로 예약 백업을 설정하면 Windows Server 백업에서는 디스크를 포맷하고, 특정 폴더 구조를 설정하고, 대상 디스크가 Windows 탐색기에 표시되지 않도록 하는 작업을 수행합니다. 대상 디스크는 기본 볼륨이어야 합니다. Windows Server 백업은 동적 볼륨으로 구성된 디스크에 백업할 수 없습니다.
MMC 스냅을 통해 백업을 예약하는 것은 매우 쉽습니다. 이 예제에서는 먼저 Backup Schedule(백업 일정) 링크를 선택하고, 백업 유형과 백업할 볼륨을 지정합니다. 그러면 Windows Server 백업에서 "Specify backup time(백업 시간 지정)" 대화 상자가 표시됩니다(그림 5 참조).
그림 5 매일 백업 시간 지정
그림 5 매일 백업 시간 지정
백업을 수행할 시간을 선택한 후에는 백업 대상 볼륨을 선택할 수 있습니다. 이 예제에서는 그림 6과 같이 백업 볼륨 E:를 선택합니다. Windows Server 백업에서는 적절한 대상 볼륨을 선택하려고 시도하지만 자신이 백업하려는 대상 디스크가 나타나지 않으면 Show All Available Disks(사용 가능한 모든 디스크 표시) 단추를 사용하여 연결된 모든 디스크 장치를 표시할 수 있습니다. 몇 개의 "확인" 대화 상자가 나타난 후 Windows Server 백업에서는 대상 볼륨을 포맷하고 Windows 작업 스케줄러를 사용하여 백업 작업을 예약합니다.
그림 6 예약된 백업을 수행할 대상 디스크 지정
그림 6 예약된 백업을 수행할 대상 디스크 지정
예약된 백업이 완료될 때마다 Windows Server 백업은 대상 볼륨의 스냅숏을 만듭니다. 또한 7일마다 새 기본 이미지를 만듭니다. 작업 내역은 Microsoft/Backup/Operational 로그에 기록됩니다. 이 로그에서 백업이 성공적으로 완료되었는지 확인할 수 있습니다. 또한 언제든지 예약 백업의 상태를 알 수 있도록 전자 메일 메시지 전송과 같은 작업을 성공 및 실패 이벤트와 연결할 수 있습니다.

명령줄에서 백업 예약
Server Core 설치에서 백업을 예약하거나 프로세스를 스크립트로 수행하려면 WBADMIN 명령줄을 사용하여 백업 예약을 관리할 수 있습니다. 예약 백업을 추가하려면 WBADMIN ENABLE BACKUP 명령을 사용하여 다음과 같이 대상, 소스 및 예약 시간을 지정합니다.
C:\> wbadmin enable backup –addtarget:e:
-include:c:,d: -schedule:06:00,12:00,18:00
이 명령은 하루 세 번(오전 6:00, 오후 12:00, 오후 6:00) C:와 D: 드라이브를 E: 드라이브로 백업합니다. 모든 시간은 24시간제를 사용하여 지정됩니다. BMR(Bare Metal Restore) 또는 시스템 상태 복원을 수행할 수 있는 모든 주요 시스템 볼륨을 백업하려면 –include 스위치를 –allcritical로 바꿉니다.
다음과 같이 WBADMIN을 사용하여 모든 예약 백업의 설정을 해제할 수도 있습니다.
C:\> wbadmin disable backup
이 명령은 Windows Server 백업 스케줄러에서 만든 예약된 모든 백업 작업을 삭제하고 모든 백업 대상 볼륨을 일반 용도로 사용하도록 해제합니다. 언제든지 WBADMIN MMC 스냅인을 사용하여 Server Core 서버의 백업 및 복원 작업을 원격으로 관리할 수 있습니다.

도메인 컨트롤러의 BMR(Bare Metal Recovery)
백업 및 복구에서 가장 주목할 만한 향상 중 하나는 WinRE가 설치 프로세스에 통합된 방식입니다. Windows Server 2008을 설치 미디어에서 부팅하면 그림 7에서처럼 컴퓨터 복구 옵션을 선택할 수 있습니다. 이 옵션은 그냥 지나치기 쉽기 때문에 여기서 잠깐 언급하고자 합니다.
그림 7 설치 화면에서 사용할 수 있는 컴퓨터 복구 옵션
그림 7 설치 화면에서 사용할 수 있는 컴퓨터 복구 옵션
설치 화면에서 복구 옵션을 선택하면 그림 8에서처럼 복구 옵션을 선택할 수 있습니다. 여기서는 Windows Complete PC Restore(Windows Complete PC 복원)를 선택하여 Windows 복구 환경을 호출합니다.
그림 8 시스템 복구 옵션 지정
그림 8 시스템 복구 옵션 지정
복구할 운영 체제를 선택하면(대개 선택 항목은 한 개만 있음) WinRE에서 복원할 백업을 선택할 수 있습니다. 기본적으로 WinRE는 가장 최근의 전체 시스템 백업을 선택하지만 로컬 디스크에 저장된 다른 백업을 지정하거나 다른 서버의 파일 공유에 저장된 백업을 네트워크에서 검색할 수도 있습니다.
이 예제에서는 가장 최근의 전체 시스템 백업을 선택합니다. 다음 대화 상자(그림 9 참조)에서는 복원하기 전에 모든 디스크를 포맷하고 파티션을 다시 지정할 수 있습니다. 이 옵션은 현재 복구 중인 문제가 특정 유형의 디스크 오류 때문에 발생했거나 서버에서 하나 이상의 디스크 드라이브를 교체한 경우에 선택할 수 있습니다.
그림 9 복원 전에 쉽게 디스크 포맷 및 파티션 다시 지정
그림 9 복원 전에 쉽게 디스크 포맷 및 파티션 다시 지정
몇 개의 확인 대화 상자가 나타난 후 WinRE에서 복원 프로세스를 시작하고 서버가 다시 부팅됩니다. 이 방법을 사용하면 서버에서 매우 쉽게 BMR(Bare Metal Recovery)을 수행할 수 있습니다.

도메인 컨트롤러의 시스템 상태 복구
백업에서 삭제된 OU를 복구하는 것과 같이 특정 유형의 Active Directory 문제에서 복구해야 할 경우에는 전체 시스템을 복원하는 대신 ADDS(Active Directory 도메인 서비스) 데이터베이스를 이전 상태로 복원해야 합니다. ADDS는 Windows Server 2008의 다른 서비스처럼 중지할 수 있지만 도메인 컨트롤러에서 시스템 상태 복원을 수행하려면 서버를 DSRM(디렉터리 서비스 복원 모드)으로 부팅해야 합니다.
Windows Server 2008이 DSRM으로 부팅되도록 부팅 옵션을 변경하는 작업은 기존처럼 쉽지 않습니다. 새로운 EFI(Extensible Firmware Interface)를 지원하도록 전체 Windows 부팅 환경이 다시 설계되었으며 이전의 boot.ini 파일은 더 이상 사용되지 않습니다. 대신 Windows Server 2008에서는 BCD(부팅 구성 데이터)를 사용하여 부팅 프로세스를 제어합니다.
BCD를 관리하는 가장 간단한 방법은 BCDEDIT 명령줄 프로그램을 사용하는 것입니다. 모든 BCDEDIT 명령과 옵션을 다루려면 별도의 기사가 필요하므로 여기서는 몇 가지 유용한 예제만 소개하겠습니다.
Windows Server 2008 DC를 DSRM으로 다시 부팅하려면 다음 명령을 사용합니다.
C:\> bcdedit /set safeboot dsrepair
이렇게 하면 기본 부팅 로더 항목에 safeboot 옵션이 설정됩니다. 새로 설치된 Windows Server 2008에는 부팅 로더 항목이 WINLOAD.EXE 하나만 있습니다. safeboot 옵션을 제거하고 표준 모드로 다시 부팅하려면 다음 명령을 사용합니다.
C:\> bcdedit /deletevalue safeboot
더 쉽게 작업하려면 표준 부팅과 DSRM 부팅을 위해 각각 하나씩 두 bootloader 항목을 DC에 구성할 수 있습니다. 이 방법을 사용하면 System Settings(시스템 설정) 아래의 Startup and Recovery(시작 및 복구) 설정 대화 상자에서 부팅 옵션을 변경할 수 있습니다. 새 bootloader 항목을 추가하려면 다음 명령을 사용합니다.
C:\> bcdedit /copy {default}
/d "Directory Service Repair Mode"
이 명령은 기본 bootloader 항목을 복사하여 새 bootloader 항목을 만듭니다. BCDEDIT에서 다음과 비슷한 메시지를 표시합니다.
The entry was successfully copied to
{c50d4710-a1f0-11dc-9580-0003ff402ae9}.
GUID는 새 항목을 식별합니다. 그리고 나서 다음 명령을 사용하여 BCD의 새 bootloader 항목에 safeboot 옵션을 설정합니다.
C:\> bcdedit /set {<GUID for new entry>}
safeboot dsrepair
이제 Startup and Recovery(시작 및 복구) 설정을 사용하여 표준 부팅 모드에서 DSRM 부팅 모드로 전환할 수 있습니다(그림 10 참조).
그림 10 표준 및 DSRM 부팅 모드 간 전환
그림 10 표준 및 DSRM 부팅 모드 간 전환
WBADMIN을 사용하여 시스템 상태 복원을 시작하기 전에 복원할 백업을 식별해야 합니다. WBADMIN은 주요 시스템 볼륨만 포함된 백업인 전체 시스템 백업 또는 시스템 상태 백업에서 시스템 상태 복원을 수행할 수 있습니다. 두 경우 모두 사용할 백업의 버전을 지정해야 합니다. 사용 가능한 백업 버전을 식별하는 가장 쉬운 방법은 다음 WBADMIN 명령을 사용하는 것입니다.
C:\> wbadmin get versions
그러면 WBADMIN은 그림 11에서 볼 수 있는 정보와 비슷한 형식으로 백업 버전을 표시합니다. 각 백업마다 백업 시간, 백업 대상, 버전 식별자(백업이 시작된 UMT 시간 및 날짜) 및 백업이 지원할 수 있는 복구 작업 유형의 목록이 있습니다.
Figure 11 복구에 사용할 수 있는 백업 식별 (Close Figure 11)
wbadmin 1.0 - Backup command-line tool
(C) Copyright 2004 Microsoft Corp.
Backup time: 11/30/2007 3:47 PM
Backup target: Fixed Disk labeled E:
Version identifier: 11/30/2007-22:47
Can Recover: Application(s), System State
Backup time: 12/1/2007 10:46 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/02/2007-05:46
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/2/2007 5:58 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/03/2007-00:58
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/3/2007 11:25 AM
Backup target: Fixed Disk labeled E:
Version identifier: 12/03/2007-18:25
Can Recover: Application(s), System State
여기서는 가장 최근 백업을 선택하고 다음 WBADMIN 명령으로 시스템 상태 복원을 시작합니다.
C:\> wbadmin start systemstaterecovery
–version:12/03/2007-18:25
이 명령은 비정식 복원을 수행합니다. SYSVOL의 정식 복원을 수행하려면 WBADMIN 명령에 authsysvol 옵션을 추가하여, 복원된 SYSVOL 복제본을 정식 복원으로 표시하기만 하면 됩니다. 이 프로세스에 대한 자세한 내용은 go.microsoft.com/fwlink/?LinkId=113152를 참조하십시오.

Active Directory 스냅숏 만들기
Active Directory 백업의 측면에서 가장 흥미로운 변경 내용 중 하나는 Windows Server 백업과 아무런 관계가 없습니다. Windows Server 2008에서는 Active Directory에서 볼륨 섀도 복사본 서비스 스냅숏을 제공할 수 있다는 점을 활용할 수 있습니다. 이러한 스냅숏은 실행 중인 Active Directory 서비스의 매우 간단한 특정 시점 백업입니다. 게다가 몇 초 안에 만들 수 있습니다. 스냅숏을 만든 다음 탑재하고 LDP 도구와 같은 일반적인 LDAP 기반 유틸리티를 사용하여 액세스할 수 있습니다.
다음과 같이 NTDSUTIL 명령을 사용하여 ADDS 또는 ADLDS(Active Directory Lightweight Directory Services)의 스냅숏을 만듭니다.
ntdsutil: snapshot
snapshot: activate instance ntds
Active instance set to "ntds".
snapshot: create
Creating snapshot...
Snapshot set {42c44414-c099-4f1e-8bd8-4453ef2534a4} generated successfully.
snapshot: quit
ntdsutil: quit
이 NTDSUTIL 명령은 Active Directory DIT, 로그 및 SYSVOL이 포함된 볼륨의 볼륨 섀도 복사본 서비스 스냅숏을 만듭니다. Active Directory는 계속 업데이트되지만 볼륨 섀도 복사본 서비스는 기록 중 복사 방식을 사용하여 만든 스냅숏을 적절하게 유지 관리합니다. 스냅숏은 DIT의 전체 사본이 아니라는 점에 유의하십시오. 실제로는 스냅숏을 만든 이후 수정된 DIT의 디스크 블록 모음일 뿐입니다. VSS는 이러한 블록을 DIT의 현재 복사본과 결합하여 Active Directory DIT를 스냅숏이 만들어진 시점의 상태대로 나타낼 수 있습니다. 그림 12에서는 오래되었거나 불필요한 스냅숏을 삭제하는 방법을 보여 줍니다.
Figure 12 불필요한 스냅숏 삭제 (Close Figure 12)
C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: delete 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit
C:\>

Active Directory 스냅숏 탑재
이 스냅숏 중 하나를 사용하려면 먼저 볼륨 섀도 복사본 서비스에 지시하여 스냅숏을 파일 시스템에서 사용할 수 있게 해야 합니다. 이렇게 하려면 ntdsutil 명령을 사용하여 사용 가능한 스냅숏을 나열한 다음 원하는 스냅숏을 탑재합니다(그림 13 참조).
Figure 13 ntdsutil을 사용하여 스냅숏 탑재 (Close Figure 13)
C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: mount 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit
C:\>
"list all" 명령을 사용하면 현재 볼륨 섀도 복사본 서비스에 의해 유지 관리되고 있는 사용 가능한 모든 Active Directory 스냅숏이 나열됩니다. "mount 1" 명령은 로그 볼륨 및 Active Directory DIT의 선택된 스냅숏을 탑재하여 파일 시스템에서 사용할 수 있도록 합니다. 위치는 C:\$SNAP_200712032318_VOLUMEC$\ 및 C:\$SNAP_200712032318_VOLUMED$\입니다.
이 폴더를 살펴보면 해당 볼륨의 전체 내용을 스냅숏이 만들어진 시점의 상태대로 볼 수 있습니다. 하지만 탑재된 스냅숏은 읽기 전용이므로 탑재된 스냅숏의 파일은 수정할 수 없습니다.

Active Directory 스냅숏에서 데이터 복구
Active Directory가 포함된 볼륨의 스냅숏을 탑재하는 작업은 조금 신기해 보일 수 있습니다. 해당 스냅숏에 포함된 Active Directory 데이터를 어떻게 가져올 수 있을까요? 그 비밀은 바로 DSAMAIN 명령에 있습니다. 이 명령은 ADLDS를 실행하는 실행 파일입니다. 이것은 기본적으로 코드 대부분을 ADDS와 공유하는 독립 실행형 LDAP 서버입니다. DSAMAIN을 사용하면 탑재된 스냅숏이 해당 스냅숏을 만든 시점의 Active Directory 데이터가 포함된 읽기 전용 LDAP 서버처럼 표시되도록 할 수 있습니다.
다음 명령을 살펴보겠습니다.
C:\> dsamain –dbpath
c:\$snap_200712032318_volumed$\ntds\dit
\ntds.dit -ldapport 10000
이 명령은 c:\$snap_200712032318_volumed$\ntds\dit 폴더에 있는 ntds.dit 파일을 탑재하고 TCP 포트 10000(또는 지정한 다른 열린 포트)의 LDAP 작업에서 사용할 수 있도록 합니다. DSAMAIN는 사용자가 지정한 포트에 1을 더한 포트(이 경우 10001)에서 LDAPS 포트(SSL(Secure Sockets Layer) 상의 LDAP에 사용되는 포트)를, 지정한 포트에 2를 더한 포트(10002)에서 GC 포트(글로벌 카탈로그 연결에 사용되는 포트)를, 지정한 포트에 3을 더한 포트(10003)에서 GCS(SSL 상의 글로벌 카탈로그) 포트를 엽니다.
LDP와 같은 모든 LDAP 프로그램을 사용하여 지정된 포트에서 탑재된 DIT에 액세스할 수 있습니다. 하지만 Windows Server 2008에서는 ADUC(Active Directory 사용자 및 컴퓨터), 사이트 및 서비스, 도메인 및 트러스트, ADSIEDIT가 수정되어 DSAMAIN을 사용하여 탑재된 DIT에 연결할 수 있습니다. ADUC의 탐색 창에서 최상위 노드를 마우스 오른쪽 단추로 클릭하고 Change Domain Controller(도메인 컨트롤러 변경)를 선택하면 그림 14와 같은 대화 상자가 나타납니다. 탑재된 스냅숏을 호스팅하는 서버의 이름이나 IP 주소를 포트(이 경우 localhost:10000)와 함께 입력하기만 하면 ADUC는 탑재된 스냅숏에 연결되어 스냅숏이 만들어진 시점의 상태대로 디렉터리 내용을 탐색할 수 있습니다. 너무 놀랍지 않습니까?
그림 14 Active Directory 사용자 및 컴퓨터를 탑재된 스냅숏에 연결
그림 14 Active Directory 사용자 및 컴퓨터를 탑재된 스냅숏에 연결
이 방법으로 디렉터리 데이터에 액세스할 수 있기 때문에 여러 유형의 데이터 복구 작업을 이전보다 훨씬 쉽게 수행할 수 있습니다. 예를 들어 삭제된 개체를 백업에서 복구하려면 이전에는 기존 DC에서 백업의 비정식 복원을 수행한 다음 삭제된 개체의 정식 복원을 수행해야 했습니다. 또한 복원한 백업에 올바른 데이터가 없으면 다른 백업을 사용하여 동일한 과정을 다시 반복해야 했습니다. 이제는 삭제 표시 항목 재사용 기능 및 스냅숏을 사용하여 삭제된 데이터를 신속하게 찾고 복구할 수 있으며 이 작업을 위해 도메인 컨트롤러를 오프라인으로 전환할 필요도 없습니다.
하지만 몇 가지 제한 사항이 있습니다. 예를 들어 각 활성 스냅숏은 디렉터리에 대한 쓰기 작업과 연결된 디스크 I/O를 증가시키기 때문에 프로덕션 DC에서는 특정 시점에 한두 개의 스냅숏만 활성화해야 합니다. 또한 스냅숏 활성화 시간이 길수록 볼륨 섀도 복사본 서비스 델타 저장소가 커지기 때문에 성능에 영향을 미칠 수 있습니다. 물론 삭제된 개체의 단순한 복구는 복구 문제의 첫 번째 부분일 뿐입니다. 이 외에도 그룹 구성원과 같은 개체의 연결된 특성을 복구해야 할 수 있습니다. 하지만 이러한 경우에도 스냅숏을 사용하면 삭제된 개체가 구성원으로 속해 있던 모든 그룹을 식별하는 데 도움이 됩니다.

Active Directory에 대한 강력한 백업 및 복구 전략
Windows Server 2008은 완전히 새로운 백업 및 복구 시스템을 제공합니다. 변경 내용 중 일부는 처음에는 다소 어려울 수 있습니다. 하지만 IT 조직에서 이러한 변경 내용을 받아들여 일상 작업에 새 백업 기술을 통합하면 더욱 효율적인 백업 및 복구 기능을 구현하게 될 것입니다.
Windows Server 2008에서 서버를 백업하는 방법이 크게 변경되었다 하더라도 Active Directory를 백업하고 복구하는 기본 전략에는 그다지 크게 변경된 내용이 없습니다. 따라서 전략을 세울 때는 다음과 같은 최선의 방법을 염두에 두십시오.
  • 하드웨어 실패 후 DC를 복구할 수 있도록 주기적인 전체 시스템 백업을 예약합니다. DC의 전체 백업을 예약하는 주기는 데이터 업데이트 주기, 중단 시간 및 데이터 손실 허용 범위, DC를 처음부터 다시 구축하는 데 필요한 노력 등을 고려하여 결정합니다.
  • Active Directory의 변경 내용을 백업하도록 자주 시스템 상태 백업을 예약합니다. 시스템 상태 백업 주기는 Active Directory 데이터 손실 허용 범위를 고려하여 결정합니다. 하지만 적어도 하루에 한 번은 수행해야 합니다. 하드웨어가 있는 경우에는 적어도 하나 또는 두 개의 시스템 상태 백업을 로컬 디스크에 보관하고 이전의 시스템 상태 버전은 DVD나 네트워크 공유로 복사합니다.
  • 각 도메인의 적어도 두 개의 DC에서 시스템 상태 백업을 수행합니다. 이렇게 하면 백업 중 하나가 손상되거나 사용할 수 없는 상태일 경우에 대비할 수 있습니다.
DC를 정의한 경우 응용 프로그램 파티션 복제본으로 백업합니다. 또한 주요 시스템 드라이브에 문제가 발생한 경우 신속하게 WinRE로 부팅할 수 있도록 DC에 Windows 복구 환경 파티션을 만듭니다.

Gil Kirkpatrick은 NetPro의 CTO이며 1996년부터 Active Directory용 소프트웨어를 개발해 왔습니다. HP의 Guido Grillenmeier와 함께 현재 많은 인기를 끌고 있는 Active Directory 재난 복구 워크숍을 진행하고 있는 Gil은 Directory Experts Conference(www.dec2008.com 참조)의 창립자이기도 합니다.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 Windows Administration: 사용 가능한 OU 구조 설계
Windows Administration Ken St. Cyr

사용 가능한 OU 구조 설계
한 눈에 보기:
  • 훌륭한 OU 설계의 주요 원칙
  • 일반적인 OU 설계 모델
  • OU 설계 문서화

올바른 OU(조직 구성 단위) 구조 설계의 중요성과 복잡성을 과소 평가하지 마십시오. IT 부서에서는 간혹 극단적인 방향으로 결정을 내리기도 합니다.
즉, OU 구조에 너무 많은 의미를 부여하거나 그 중요성을 간과합니다. 어느 쪽이건 Active Directory® 모델에 문제를 유발할 수 있습니다.
OU 구조에 너무 신경 쓰면 사이트 토폴로지 계획이나 도메인 컨트롤러 크기 지정과 같은 Active Directory 설계의 다른 영역을 간과할 수 있습니다. 반대로 OU 계획을 미루다 보면 그룹 정책 및 위임에 소홀할 수 있습니다.
이렇게 문제를 방치하는 사람들은 OU 구조는 유연하므로 나중에 변경할 수 있다는 변명을 늘어놓곤 합니다. OU 구조가 유연한 것은 사실이지만 관리자의 입장에서는 OU 구조를 중간에 변경하는 작업이 처음 예상했던 것보다 더 힘들 수 있습니다. 물론 새 OU를 추가할 수 있지만 기존 OU를 정리하기는 어렵습니다.
처음에 OU 구조를 잘못 계획하면 끝까지 나쁜 영향을 미칩니다. 디렉터리에 새 개체가 만들어졌는데 관리자가 개체를 배치할 OU 구조를 잘 모르면 새 OU를 다시 만들거나 적합하지 않은 위치에 개체를 배치하게 됩니다. 두 가지 경우 모두 위험이 따릅니다. 새 OU를 만드는 것은 쉽지만 장기적으로 추적하는 데 어려움이 있습니다. OU를 무분별하게 만들면 OU 구조가 복잡해지고 디렉터리가 문서화되지 않은 상태가 되기 쉽습니다. 반대로 적합하지 않은 기존 OU에 개체를 추가하면 새 개체에 해당하지 않는 정책이 적용되거나 개체에 대한 사용 권한이 의도하지 않은 사용자에게 위임될 수 있습니다.
OU 구조를 설계할 때 염두에 두어야 하는 기본 공식은 "단순성 + 적응성 = 지속 가능성"입니다. 설계가 너무 단순하면 적응성이 떨어지므로 자주 변경해야 할 수 있고, 적응성에 너무 많이 초점을 맞추다 보면 모든 것이 세분화되므로 너무 복잡해질 수 있습니다.
설계를 결정하는 데 도움이 되는 세 가지 주요 원칙에는 그룹 정책, 위임 및 개체 관리가 있습니다. 이러한 원칙에 대해 세 가지 질문을 던져 만들고 있는 OU 구조가 오래 지속되고 조직의 변화에 적응할 수 있는지 확인할 수 있습니다.
  1. 고유한 GPO(그룹 정책 개체)를 적용할 수 있도록 이 OU를 만들어야 합니까?
  2. 특정 그룹의 관리자가 이 OU의 개체에 대한 사용 권한을 가져야 합니까?
  3. 이 새로운 OU를 사용하면 포함된 개체를 관리하기가 쉬워집니까?
모든 질문에 대한 대답이 "예"라면 OU를 만들 이유가 충분히 있습니다. 하나라도 "아니요"라는 대답이 있으면 레이아웃을 다시 검토해 보고 다른 설계가 더 적합하지 않은지 확인해야 합니다. 이 문제에 대해 깊이 논의하고 이러한 원칙을 적용하는 방법을 시연하기 전에 우선 이러한 원칙이 왜 중요한지부터 설명하겠습니다.

원칙 1: 그룹 정책
OU 설계의 첫 번째 원칙은 OU에 적용할 그룹 정책 개체를 고려하는 것입니다. GPO를 사용하면 사용자 및 컴퓨터에 대한 설정을 강제적인 방식으로 구성할 수 있습니다. Active Directory에서 여러 GPO를 정의한 후 전체 도메인, 여러 OU 또는 도메인의 사이트에 적용할 수 있습니다. GPO는 사용자용과 컴퓨터용의 두 가지 범주로 나뉩니다.
컴퓨터 정책과 사용자 정책을 모두 같은 GPO에 정의할 수 있습니다. GPO의 사용자 구성 섹션에서는 대부분 사용자가 로그인할 때 표시되는 환경을 정의합니다. 이러한 유형의 설정은 컴퓨터 구성 섹션에도 있지만 이 섹션에는 컴퓨터에 로컬로 로그온할 수 있는 사용자 또는 데이터 암호화 방법과 같은 컴퓨터 보안 관련 설정이 추가적으로 포함되어 있습니다.
GPO를 지원하는 OU를 정의할 때 고려해야 할 기본 사항은 다음과 같습니다. 첫 번째로, 사용자 정책과 컴퓨터 정책을 모두 같은 GPO에 정의할 수 있다는 이유만으로 사용자 개체와 컴퓨터 개체를 같은 OU에 배치하는 것은 그다지 좋지 않습니다. 같은 GPO에 결합하면 GPO 적용 문제를 해결하는 데 어려움이 따릅니다. 루프백 정책이 설정된 경우에는 문제 해결이 특히 어렵습니다.
두 번째로, 많은 사람들이 사이트 수준에서 GPO를 적용할 수 있다는 사실을 잊고 GPO 용도로 사이트 구조를 모델링하는 데 OU 구조를 설계한다는 점입니다. 이것은 지리적 모델로 알려진 OU 설계의 일반적인 모델입니다. 이 모델에 대해서는 이후에 좀 더 설명하도록 하겠습니다. OU 설계에 지리적 모델이 사용된다는 사실은 잠시 잊고, 나중에 설명하겠지만 GPO 적용이 이 모델 구현의 결정적인 이유가 되어서는 안 된다고 생각합니다.
또한 GPO의 관점에서 OU 구조를 생각해 보면 복잡성을 줄이는 것이 목표일 것입니다. OU를 GPO 상속의 흐름에 추가하십시오. OU에 다른 서버와 같은 정책을 필요로 하는 서버가 포함되어 있으면 이러한 컴퓨터 개체를 보다 광범위한 Servers OU에 배치하고 Servers OU 아래에 서로 다른 서버 유형에 대한 여러 OU를 만드는 방법도 고려해 보십시오(그림 1 참조). 이렇게 하면 하위 OU의 각 컴퓨터 개체가 Servers OU의 정책 및 해당 특정 서버 유형과 관련된 다른 정책을 가져오므로 정책 적용이 간단해질 수 있습니다.
그림 1 서로 다른 서버 유형에 대한 여러 OU 만들기
그림 1 서로 다른 서버 유형에 대한 여러 OU 만들기
다른 기본 사항은 여러 GPO를 불필요하게 만들거나 연결하지 않는 것입니다. GPO를 사용하면 하나의 정책을 만들어 여러 OU에 적용할 수 있습니다. 이 방식은 유용할 때도 있지만 악영향을 미칠 수도 있습니다. GPO 설정을 변경해야 하는데 연결된 GPO 시스템이 너무 복잡하면 변경 내용을 실수로 잘못된 개체에 적용할 수 있습니다. 링크를 많이 만들수록 정책 범위를 가늠하기 어려워집니다. 마찬가지로 다른 정책과 같은 설정으로 추가 정책을 만들지 말아야 합니다. 이러한 상황이 발생하면 OU 구조를 수정하여 새 GPO 상속 모델을 적용하는 것이 좋습니다.
마지막으로, 사용자 개체 및 컴퓨터 개체에 대해 거의 항상 새 OU를 만들어야 합니다. 기본적으로 사용자 개체와 컴퓨터 개체는 컨테이너 안에 위치하므로 GPO를 직접 연결할 수 없습니다. GPO를 도메인의 사용자 및 컴퓨터 컨테이너에 적용할 수 있지만 상속을 차단하지 않으면 도메인에 있는 모든 사용자 및 컴퓨터에 이러한 정책이 적용됩니다. Windows Server® 2003에서는 rediruser.exe 및 redircomp.exe 도구를 사용하여 사용자 개체와 컴퓨터 개체의 기본 위치를 사용자가 만든 OU로 변경할 수 있습니다.

원칙 2: 위임
도메인에서 사용 권한이 위임된 방식과 일관되게 OU 구조를 만들어야 합니다. Active Directory에서 사용 권한이 위임되는 경우에는 사용 권한에 대한 변경이 개체에만 적용됩니다. 따라서 사용자에게 특정 컴퓨터 개체에 대한 모든 권한을 부여하면 해당 사용자는 개체의 특성을 수정할 수 있지만 컴퓨터 자체에 대해서는 관리자 권한이 없습니다.
OU 구조를 설계할 때 유용한 위임 관련 권장 방법을 몇 가지 소개하겠습니다.
사용 권한 상속을 고려하여 설계 예를 들어 계층 1 관리자에게 대부분의 계정에 대한 암호를 변경할 수 있는 권한을 부여하려는 경우, 관리자가 암호를 다시 설정할 수 있는 권한을 가지면 안 되는 특수한 사용자 그룹이 있지만 이러한 관리자에게 해당 계정에 대한 표시 이름을 변경할 수 있는 권한이 필요할 수 있습니다.
두 가지 옵션 중 하나를 선택할 수 있습니다. 첫 번째 옵션은 별개의 두 병렬 OU를 만들고 일반 사용자와 특수 사용자를 구분하는 것입니다. 그러나 이렇게 하면 모든 사용자에 대한 위임 옵션을 변경하려는 경우 두 위치에서 이러한 사용 권한을 변경해야 합니다. 또한 이 옵션은 불필요한 여러 개의 연결을 사용하지 않아야 한다는 정책과 모순될 수 있습니다(그림 2 참조).
그림 2 별개의 두 병렬 OU 유지 관리
그림 2 별개의 두 병렬 OU 유지 관리
또 다른 옵션은 중첩 OU를 만들고 특수 사용자가 포함된 OU에 명시적인 거부 권한을 설정하는 것입니다. 모든 위임 전문가가 명시적인 거부는 사용하지 않는 것이 좋다고 말하겠지만 이 경우에는 최악의 조건 둘 중에서 하나를 선택해야 합니다(그림 3 참조). 별개의 두 OU에 대해 설정을 복제하고 유지 관리하거나 OU 중 하나에 명시적인 거부를 설정할 수 있습니다. 장기적인 안목에서 볼 때는 명시적인 거부를 사용하는 것이 좋습니다.
그림 3 명시적인 거부 권한 사용
그림 3 명시적인 거부 권한 사용
AdminSDHolder에 주의 이 예제는 특수 사용자가 모두 관리 그룹(Domain Admins, Schema Admins, Enterprise Admins 또는 Administrators) 중 하나에 속하지 않는 경우 더욱 잘 작동합니다. 이러한 그룹의 계정에 대한 사용 권한은 다루기 어렵기 때문입니다. 이 예제의 목적은 일반 사용자의 사용 권한을 실수로 관리 계정으로 부여하지 않기 위함입니다.
관리자용으로 별개의 OU를 만들면 여기에 위임하는 사용 권한이 보이지 않게 됩니다. 그 이유는 AdminSDHolder 때문입니다. AdminSDHolder는 지정된 간격으로 해당 액세스 제어 목록을 모든 관리자 계정에 적용하는 특수 컨테이너입니다. 따라서 관리 계정에 대한 위임이 변경된 후 AdminSDHolder 컨테이너에서도 변경되지 않으면 변경 내용이 되돌려집니다. 따라서 관리자 계정을 위임에 사용되는 다른 계정과 분리해 놓지 말아야 합니다. 하지만 그룹 정책에 사용되는 관리자 계정과는 분리해 놓는 것이 좋습니다. 이는 여러 암호 정책을 사용할 수 있는 Windows Server 2008에서 특히 유용합니다.

원칙 3: 개체 관리
OU에서 개체 관리를 활용해야 합니다. 개체를 같은 OU에 그룹화하면 일괄 변경을 수행하기 쉽습니다. Active Directory 사용자 및 컴퓨터 스냅인을 통해 여러 개체를 선택하여 특정 특성을 편집할 수 있습니다. 따라서 개체 그룹에 대해 정기적으로 특성을 변경해야 하는 경우 이러한 개체 그룹이 같은 OU에 있으면 작업하기 쉬워집니다.
또한 스크립트를 사용하여 업데이트하는 경우에도 특히 유용합니다. 스크립팅 언어를 사용하면 하나의 OU에 있는 모든 개체를 열거하고 이러한 개체를 하나씩 처리하기가 매우 쉬워집니다. 각 개체를 하나씩 검색하고 수정하는 방법도 있습니다. 관리하기 쉽도록 같은 OU에 개체를 배치하기만 하면 매주 불필요한 작업을 수행하는 시간을 절약할 수 있습니다.
개체 관리에 유용한 다른 방법으로는 형식에 따라 다른 OU에 개체를 분리해 놓는 방법이 있습니다. 프린터 개체 또는 게시된 공유에 대해 별개의 OU를 만들면 OU의 다른 개체에 대한 관리 작업을 수행할 때 이러한 개체를 따로 제외시킬 필요가 없습니다. 이 방법은 같은 OU에 사용자 계정과 컴퓨터 계정을 함께 그룹화하지 않는다는 방침과도 일맥상통합니다.

모델 선택
이제 OU 설계의 원칙에 대한 설명을 마치고 일반적인 설계 모델 몇 가지를 더욱 자세히 살펴보겠습니다. 여기에서 설명하는 모델은 극히 일부에 불과하며 여러 개의 모델에 대해서도 작업할 수 있습니다. 각 모델에서 원하는 부분을 선택하여 사용자의 특정 요구 사항에 맞는 하이브리드 모델을 직접 만들 수 있습니다.
작은 규모에서는 어떠한 모델에 대해서도 성공적으로 작업을 수행할 수 있겠지만 기업이 성장함에 따라 환경을 제어할 수 있는 범위가 줄어들 수 있습니다. 따라서 적합한 테스트 환경에서 처음부터 모델을 철저히 테스트하십시오. 또한 OU 구조도 처음에는 쉽게 변경할 수 있지만 시간이 지날수록 변경하기가 점점 어려워진다는 사실을 잊지 마십시오.

단순 모델
단순 모델이라는 이름은 거의 평면적으로 유지된다는 사실에서 따온 것입니다. 이 모델에서는 높은 수준의 OU 몇 개에 대부분의 개체가 포함되어 있습니다(그림 4 참조). 이 모델은 대개 IT 조직의 규모가 작고 부서가 많지 않거나 사람들이 여러 역할을 수행하는 소규모 기업에서 사용됩니다. 성능 저하를 막기 위해 Microsoft에서는 하위 OU를 15개로 제한하지만 필자는 10개로 제한할 것을 권장합니다.
그림 4 높은 수준의 OU 몇 개에 대부분의 개체가 포함된 단순 모델
그림 4 높은 수준의 OU 몇 개에 대부분의 개체가 포함된 단순 모델
인적 자원 담당자와 지급 담당자가 동일인이라면 인적 자원 부서와 지급 부서에 대해 별개의 두 OU를 만들 필요가 없습니다. 단순 모델에서는 모든 사용자 개체를 하나의 큰 Accounts OU로 그룹화하거나 기본 Users 컨테이너에 유지할 수 있습니다. 그래도 사용자 개체는 컴퓨터 개체와 분리해야 합니다.
이 모델의 경우 한 단계 더 나아가 서버에서 워크스테이션을 분리하는 것도 좋습니다. 그런 다음 최소한 WMI(Windows® Management Instrumentation) 쿼리를 사용하는 GPO를 정의할 필요 없이 서로 다른 그룹 정책을 적용하여 워크스테이션 또는 서버를 필터링하여 제외시킬 수는 있습니다.
OU 구조를 광범위하게 유지하면 좋은 점 중 하나는 Active Directory 검색이 빠르게 실행된다는 것입니다. 개인적으로는 하위 OU를 10개 이상 사용하지 않도록 권장합니다. 이 모델에서는 개체를 매우 세부적으로 제어할 수 없지만 소규모 기업에서 개체를 관리하는 경우 그렇게까지 세부적으로 제어할 필요는 없을 것입니다. 따라서 대규모 기업에서는 이 모델을 제대로 사용하기 어려울 수 있지만 소규모 조직에서는 매우 유용하게 사용할 수 있습니다.

지리적 모델
지리적 모델에서는 지역별로 별개의 OU를 만듭니다. 이 모델은 IT 부서가 분산되어 있지만 여러 도메인을 운영하는 데 비용을 들이지 않으려는 조직에 가장 적합합니다(그림 5 참조).
그림 5 지역별로 OU를 구분하는 지리적 모델
그림 5 지역별로 OU를 구분하는 지리적 모델
애틀랜타, 볼티모어 및 시애틀에 사무실이 있다고 가정해 봅시다. 각 사이트에서 자체적으로 사용자 및 컴퓨터를 관리하면 위임의 개념을 도입할 수 있습니다. 그러나 시애틀 사용자가 교육을 받기 위해 볼티모어에 오면 계정이 잠깁니다. 볼티모어의 IT 담당자는 이 사용자 계정에 대한 사용 권한을 위임 받지 않는 한 이 사용자를 도울 수 있는 방법이 없습니다. 볼티모어에서 오전 8시이면 시애틀에서는 오전 5시입니다. 즉, 시애틀 사무실에 도움을 요청하려면 몇 시간 기다려야 할 수 있습니다.
일부 다국적 기업에서는 "태양을 따르는" 모델을 사용합니다. 즉, 지원 부서 호출이 현재 영업 시간인 표준 시간대에 위치한 사이트로 전달됩니다. 이렇게 하면 각 사이트에서 24시간 지원 부서를 운영할 필요는 없지만 필요한 경우 계정 잠금을 해제하는 등의 지원을 위해 야근 직원을 배치할 수 있습니다.
이 모델을 사용할 경우 지리적 위치에 따라 별개의 OU를 만드는 것이 운영 요구 사항에 적합하지 않을 수 있습니다. 모든 사용자 OU의 각 지역 지원 부서에 대해 별개의 사용 권한을 위임해야 합니다. 그러나 사이트에 자체 IT 부서가 있으면 지리적 모델이 조직에 적합할 수 있습니다.
또한 지리적 모델은 도메인 운영 방식의 특성상 단일 도메인에서 사용하기 어렵습니다. 도메인은 다른 도메인과 서로 다른 보안 모델을 갖는 경향이 있습니다. Microsoft® Exchange 같은 엔터프라이즈 응용 프로그램을 보면 이러한 사실을 확실하게 알 수 있습니다.
애틀랜타의 Exchange Server에는 다른 메시지 정책이 정의되어 있을 수 있지만 기업의 모든 Exchange Server에는 같은 GPO가 적용되어 있을 것입니다. 이 경우 Exchange Server를 지역별로 별개의 OU에 배치하면 여러 OU에 같은 GPO를 불필요하게 연결하게 될 수 있습니다. 위임의 관점에서는 Exchange Server용 컴퓨터 개체에 실제로 고유한 사용 권한이 필요한지 Exchange 관리자에게 문의해야 합니다. 대부분의 경우 컴퓨터 개체를 지리적 OU로 분리해 놓는 것은 그룹 정책에 따른 용도일 뿐 위임을 위한 용도는 아닙니다.

형식 기반 모델
형식 기반 모델에서는 용도별로 개체를 분류합니다(그림 6 참조). 마지막으로 만든 사용자 개체가 일반 사용자 계정을 위한 것인지, 관리 계정을 위한 것인지 또는 서비스 계정을 위한 것인지 묻는다면 형식 기반 모델에서는 이러한 개체가 각각 별개로 취급됩니다.
그림 6 기능에 따라 개체를 그룹화하는 형식 기반 모델
그림 6 기능에 따라 개체를 그룹화하는 형식 기반 모델
대부분의 경우 정책별로 사용자 개체를 다르게 분류해야 합니다. 대부분 사용자 계정 유형에 따라 정책이 달라집니다. 잘못된 사용의 예로 서비스 계정을 사용하여 컴퓨터에 로그온하는 것을 허용하는 경우를 들 수 있습니다. 서비스 계정 암호는 일반적으로 많은 사용자들이 공유하므로 한 사용자가 서비스 계정으로 로그온하면 정확한 신원을 파악할 수 없습니다. 문제가 발생하면 이벤트가 발생한 시각에 로그인한 사용자를 추적하기가 힘듭니다. 이 예제에서는 대화형 로그온을 방지하도록 서비스 계정에 대한 정책을 설정해야 합니다. 이 방법은 그림 3에 나와 있는 계층 모델에 적합합니다.
이러한 장점과 더불어 GPO 상속을 사용할 수 있습니다. 예를 들어 모든 사용자 개체에 대한 정책을 나타내는 모든 사용자 정책을 사용할 수 있습니다. 또한 모든 사용자 정책을 기반으로 하는 서비스 계정용 정책을 구분하여 사용할 수 있습니다. 이러한 접근 방법을 통해 서비스 계정에 다른 모든 계정과 같은 기본 정책 집합 및 특정 로그온 제한을 사용할 수 있습니다.
이 방식은 GPO 상속 대신 사용 권한 상속을 사용하는 위임의 경우에도 효과적입니다. 계층 2 관리자에게 계층 3 관리자 계정을 제외한 모든 계정에 대해 암호를 다시 설정할 수 있는 권한을 부여하려는 경우, 평면적인 OU 구조에서는 사용자 계정이 있는 각 OU에 대해 사용 권한을 위임해야 합니다. 그러나 계층 구조가 있는 형식 기반 모델에서는 계층 2 그룹에 Accounts OU에 대해 "암호를 다시 설정"할 수 있는 권한을 부여한 다음 계층 3 OU에서 단순히 사용 권한을 상속 받지 않거나 암호 다시 설정에 대한 계층 2의 명시적인 거부를 설정할 수도 있습니다.
이 방법은 컴퓨터 개체에 대해서도 효과적입니다. 서버와 워크스테이션을 구분하고 서로 다른 정책을 적용할 수 있습니다. 그런 다음 서버를 기능별로 세분화할 수 있습니다(그림 1 참조). 이러한 설계에서는 모든 서버에 영향을 미치는 Servers OU에 대해 높은 수준의 정책을 설정하고 각 하위 수준의 OU에 개별 정책을 설정할 수 있습니다.
예를 들어 MOM(Microsoft Operations Manager) 서비스 계정이 있다고 가정합니다. 이 계층 모델을 사용하여 MOM GPO를 만든 후 MOM Servers OU에 적용할 수 있습니다. 그런 다음 해당 GPO 내에서 MOM 서비스 계정에 서비스로 로그온할 수 있는 권한을 부여할 수 있습니다. 이 작업은 해당 OU의 MOM 서버에만 적용됩니다. MOM 서버는 여전히 높은 수준의 Servers OU에서 Servers GPO를 가져오지만 MOM OU에서 연결된 특수한 MOM GPO도 가져옵니다.

설계 문서화
Active Directory 환경에서 발생하는 수많은 변경 작업에도 전혀 문제가 발생하지 않는 OU 구조를 설계할 수 있다면 매우 좋겠지만 OU의 동적 특성을 추적할 수 있는 방법이 필요한 순간이 반드시 있습니다. 추적할 수 있는 방법이 없으면 환경에 대한 제어 능력을 급속하게 상실하게 됩니다. 변경 사항이 있으면 OU를 추가하거나 삭제해야 하므로 모델이 세 가지 기본 원칙을 지키면서 설계 모델을 계속 추구하는 데 필요한 작업에 대한 명확한 지침이 있어야 합니다. 이것이 바로 설계 문서화가 중요시되는 이유입니다.
Microsoft의 Windows Server 리소스 키트에는 문서화 가이드가 있습니다. 이러한 가이드는 사용하고 있는 구조가 그다지 많이 변경되지 않는 견고한 프레임워크인 경우에 유용합니다. 그러나 대부분의 조직에서는 자주 변경되는 매우 동적인 구조를 사용합니다. 따라서 OU 구조를 올바르게 문서화하고 동적 환경을 지원하는 데 필요한 중요한 몇 가지 팁을 소개합니다.
모든 정보가 관련되어 있는지 확인 용도가 분명한 문서를 작성하는 것이 중요합니다. 별로 관련 없는 정보가 너무 많이 포함된 조작 설명서를 너무 많이 작성하면 중요한 자료를 찾기 힘듭니다. 문서화를 위한 문서 작업이 되지 않도록 주의하십시오. OU의 액세스 제어 목록에 대해 모든 OU 또는 모든 ACE(액세스 제어 항목)의 개체 수를 포함하는 것이 실제로 필요합니까? OU 문서화의 경우 다음 정보만 있어도 충분합니다.
  • OU 이름
  • 간략한 설명
  • 만든 사람 또는 추가 정보나 변경 사항이 있을 때 연락할 담당자
  • 만든 시간
업데이트하기 쉽게 작성 복잡한 Microsoft Word 문서를 장황하게 업데이트해야 한다면 업데이트를 입력하는 작업이 더욱 싫어질 것입니다. 곧 많은 양의 업데이트를 한 번에 입력할 예정이라면 소소한 변경 사항은 당장 입력하지 않아도 좋습니다. 하지만 이러한 소소한 변경 사항은 잊어버리거나 미뤄둔 채 아무 것도 하지 않는 경우도 많긴 합니다. 따라서 문서 업데이트 작업은 매우 쉽고 지루하지 않아야 합니다. 대부분의 경우 간단한 Microsoft Excel® 스프레드시트에 열만 몇 개 작성하는 것으로 충분할 것입니다.
개체 자체에 설명 달기 OU 개체에는 설명을 입력할 수 있는 설명 특성이 있습니다. 설계 문서에 설명을 작성하는 것보다는 다른 사람들이 OU의 용도를 쉽게 알 수 있도록 설명 특성에 설명을 입력하는 것이 좋습니다. 자세한 정보를 포함해야 하면 설명 특성에 간략한 설명을 입력하고 자세한 정보는 OU 문서에 포함하십시오.
문서화 자동화 OU 구조의 내용을 텍스트 파일, Excel 스프레드시트 또는 HTML 파일로 수집하는 스크립트를 작성할 수 있습니다. 이 스크립트는 매일 밤 예약 작업을 통해 실행할 수 있습니다. 또한 OU의 설명 필드에 있는 설명을 통합하는 경우에도 매우 유용할 수 있습니다. 이렇게 하면 설명 특성의 내용이 파일로 수집되므로 자동으로 항상 최신 상태의 OU 구조 전체를 문서화할 수 있습니다. 기존 문서를 덮어쓰는 대신 스크립트를 실행할 때마다 새 파일을 만들면 시간의 흐름에 따른 OU 구조의 변화를 기록으로 남길 수 있습니다.
필요한 순간이 오기 전에는 잘 작성된 OU 구조 문서화의 중요성을 실감하지 못하는 관리자가 대부분입니다. 그러다가 어느 날 새벽 3시에 실수로 삭제된 다른 OU가 더 있는지 찾아내려면 복원하는 방법밖에 없게 됩니다.
이러한 일이 발생하지 않도록 미리 대비해야 합니다. 이 글을 읽은 후 즉시 OU 문서화를 시작하고 업데이트를 담당할 사람을 지정하시기를 바랍니다. 규칙에 따라 문서 업데이트 작업을 쉽게 해놓으면 이를 유지하는 일은 더욱 쉬워질 것입니다.

Ken St. Cyr는 IT 업계에서 경력 10년차의 Microsoft 컨설턴트입니다. Ken은 Active Directory 기반 디렉터리 솔루션을 초창기부터 설계 및 구현해 왔습니다.


 Windows Administration: Active Directory 스키마 확장
Windows Administration Vikas Malhotra

Active Directory 스키마 확장
한 눈에 보기:
  • 기본 Active Directory 스키마 이해
  • classSchema 또는 attributeSchema 개체 추가
  • 개체 ID 가져오기 및 사용
  • .ldif 파일을 사용하여 스키마 확장
이 기사의 코드 다운로드: Schema2008_05.exe (151KB)

Windows 2000 릴리스와 함께 Active Directory를 소개하면서 Microsoft는 고객에게 Active Directory 구현에 대한 기본 스키마 정의를 제공해 왔습니다.
Active Directory®는 Windows®에서 많은 응용 프로그램이 작성되고 구현되는 방식이 변화했음을 의미하기도 합니다. 이전에는 Microsoft® Exchange 5.5와 같은 응용 프로그램이 자체 디렉터리 구조를 가지도록 빌드되었습니다. Active Directory를 사용할 수 있게 되면서 Microsoft 및 다른 회사의 여러 응용 프로그램에서는 처음부터 자체 스키마를 빌드하는 대신 Active Directory에서 제공하는 기본 구조의 이점을 이용하기 시작했습니다.
이러한 응용 프로그램은 Active Directory에서 제공하는 기본 아키텍처로 시작하여 필요에 따라 이를 확장했습니다. 예를 들어 Microsoft Exchange 2000은 메시징 구현을 위해 Active Directory를 이용함으로써 Microsoft 메시징 아키텍처의 미래를 정의합니다.
현재 Active Directory 환경에서 작동하도록 작성된 많은 응용 프로그램이 기본 스키마를 사용하여 작동하며 필요에 따라 자체 변경 내용을 스키마로 정의하는 경우도 많습니다. 물론 이렇게 하려면 확장 가능한 스키마가 필요하며 이 기사에서는 이러한 스키마에 대해 다룹니다. 또한 많은 응용 프로그램이 Active Directory의 기본 정의에 종속되기 때문에 핵심 스키마의 지속적인 안정성은 매우 중요합니다. 응용 프로그램 대부분은 같은 Active Directory의 다른 응용 프로그램과 함께 작동해야 하므로 한 응용 프로그램에 대한 변경이 다른 응용 프로그램에 영향을 미치지 않아야 합니다.

스키마란?
Active Directory 스키마의 개념을 정확히 모르는 경우가 종종 있을 수 있으며 스키마를 직접 수정하는 작업이 어려워 보일 수도 있습니다. 물론 Active Directory 스키마를 확장하는 작업을 자주 해야 하는 것은 아니지만 특정 응용 프로그램이나 비즈니스 필요에 따라 자주 확장해야 할 수도 있습니다. 따라서 Active Directory는 많은 조직에 있어 핵심 자산이며 잘못된 업데이트로 오작동이 발생하면 심각한 영향을 미칠 수 있기 때문에 스키마가 무엇이며 여기에 무엇이 포함되는지 정확하게 이해하는 것이 매우 중요합니다.
Active Directory 스키마를 확장하는 대신 사용자 지정된 스키마 정의를 직접 테스트하거나 구현하는 작업에 대한 대안으로 Windows Server® 2008의 ADLDS(Active Directory Lightweight Directory Service) 또는 Windows Server 2003의 ADAM(Active Directory Application Mode)의 사용을 고려하는 조직이 많습니다.
스키마는 디렉터리 서비스에 대한 형식을 제공하는 기본 구조입니다. Active Directory 스키마는 ADDS(Active Directory Domain Services)에서 사용되는 개체 클래스 및 특성을 정의합니다. 핵심 스키마는 잘 알려진 다양한 클래스(예: 사용자, 컴퓨터 및 organizationalUnit) 및 특성(예; telephoneNumber 및 objectSID)에 대한 정의를 제공합니다. 핵심 스키마 정의의 개체를 범주 1 개체라고 하며 추가되는 개체를 범주 2 개체라고 합니다.
Active Directory 스키마는 경로 cn=Schema,cn=Configuration,dc=X에 정의된 컨테이너에서 찾을 수 있습니다. 여기서 X는 Active Directory 포리스트의 네임스페이스입니다. Active Directory 포리스트에는 하나의 스키마만 포함됩니다. 포리스트에서 스키마 정의를 변경하면 해당 포리스트의 모든 도메인에 영향을 미칩니다. 그림 1은 여러 버전의 Windows Server에서 Active Directory 스키마에 추가되는 클래스 및 특성의 수를 보여 줍니다.
Figure 1 클래스 및 특성 수 (Close Figure 1)

버전 | 추가된 특성 수 | 추가된 클래스 수 | 스키마 확장 파일
Windows Server 2003 | 208 | 49 | Sch14.ldf - sch30.ldf
Windows Server 2003 R2 | 81 | 29 | Sch31.ldf
Windows Server 2008 | 136 | 10 | Sch32.ldf - sch44.ldf
여러 Windows Server 버전에 대한 스키마 업데이트는 Adprep라는 유틸리티를 사용하여 수행합니다. Windows Server 2003 R2 업데이트에서 스키마 버전은 31로 업데이트되며 Windows Server 2008에서는 44로 변경됩니다.
ADSIEdit와 같은 도구를 사용하여 Active Directory에서 cn=Schema,cn=Configuration,dc=X의 objectVersion 특성 값을 검사하면 버전을 확인할 수 있습니다. Exchange Server, SMS(System Management Server) 또는 Active Directory에 종속적인 기타 응용 프로그램에서는 응용 프로그램 필요에 따라 스키마를 수정할 수 있습니다.

기본 구성 요소
Active Directory는 classSchema(줄여서 클래스)와 attributeSchema(줄여서 특성)의 두 종류의 개체로 구성됩니다. 일반적으로 조직에서는 기존 스키마에서 사용할 수 없는 특정 특성으로 데이터를 저장하려고 할 때 Active Directory 스키마의 확장을 고려합니다. 먼저 스키마 컨테이너에 attributeSchema 개체를 지정한 다음 새 개체에 필요한 속성을 정의하여 Active Directory 스키마에 특성을 만들 수 있습니다.
attributeSchema 개체의 속성 목록과 이에 대한 정보를 보려면 go.microsoft.com/fwlink/?LinkId=110445를 참조하십시오. 여기서 볼 수 있듯이 attributeSchema 개체에 대해 정의할 수 있는 속성은 여러 가지이며 이들 속성 중 대부분이 필수입니다.
일반적인 특성 이외에도 정방향 링크 및 역방향 링크를 제공하여 한 쌍으로 구현되는 Linked라는 특수한 특성도 스키마 내에 있습니다. Active Directory의 그룹 구성원을 예로 들 수 있습니다. 그룹의 구성원 특성(예를 들어 John Doe라는 구성원이 있는 ContosoEmployees 그룹)은 정방향 링크이며 구성원 개체의 해당 memberOf 특성은 역방향 링크입니다. 예를 들어 John Doe의 memberOf 특성을 쿼리하면 ContosoEmployees 그룹의 고유 이름(DN)이 계산됩니다.
정방향 링크는 다른 특성과 매우 비슷하게 동작합니다. 그룹 구성원으로 여러 개체가 포함될 수 있는 구성원 특성과 마찬가지로, 값은 단일 값이거나 다중 값일 수 있으며 디렉터리에 부모 개체와 함께 저장됩니다.
반면에 역방향 링크는 참조 무결성을 보장하기 위해 시스템에서 유지됩니다. 역방향 링크 특성의 값을 쿼리하면 결과는 일치하는 모든 정방향 링크 값에서 계산됩니다. 역방향 링크는 항상 다중 값입니다.
ADDS의 각 개체 클래스는 스키마 컨테이너의 classSchema 개체로 정의됩니다. classSchema 개체를 정의하는 데 필수적인 특성 목록은 go.microsoft.com/fwlink/?LinkId=110445에서 확인할 수 있습니다.
클래스에는 Structural, Abstract 및 Auxiliary의 세 가지 형식이 있습니다. 이 형식은 objectClassCategory 특성 값으로 정의됩니다. 88이라는 네 번째 범주에는 X.500 1993 표준 이전에 정의된 클래스가 포함됩니다. 이러한 클래스 형식은 objectClassCategory 특성에서 0 값으로 지정됩니다. 이 클래스 형식은 더 이상 정의되지 않아야 합니다.

ID 가져오기 및 사용
디렉터리의 각 classSchema 및 attributeSchema 개체 ID는 classSchema 개체의 governsID와 attributeSchema 개체의 attributeID에 대해 정의되는 필수 OID(개체 ID)를 사용하여 정의됩니다. 이 ID는 특정 발행 기관에서 개체 식별을 위해 제공하는 고유한 숫자 값입니다. 숫자 지정은 LDAP 프로토콜의 정의(RFC 2251)에 의해 구성됩니다. Active Directory 스키마의 일부 OID는 ISO(국제 표준화 기구)에서 발행하며 나머지 일부 OID는 Microsoft에서 발행합니다. OID는 디렉터리 내의 개체에 대해 고유해야 합니다.
OID는 그림 2에서처럼 1.2.840.113556.1.y.z와 같은 숫자 문자열입니다. 예를 들어 사용자 classSchema 개체의 OID는 1.2.840.113556.1.5.9입니다.
Figure 2 사용자 개체에 대한 ID (Close Figure 2)

값 | 의미 | 설명
1 | ISO | 루트 기관 식별
2 | ANSI | ISO에서 할당한 그룹 지정
840 | 미국 | 조직에서 할당한 국가/지역 코드
113556 | Microsoft | 국가/지역에서 할당한 조직 지정
1 | Active Directory | 조직에서 할당(이 경우 Microsoft)
Y | 개체 유형 | classSchema 또는 attributeSchema와 같은 여러 개체 유형(범주)을 정의하는 숫자. 예를 들어 5는 개체 클래스를 정의합니다.
Z | 개체 | 범주 내에서 특정 개체를 식별하는 숫자. 예를 들어 사용자 클래스에는 숫자 9가 할당되어 있습니다.
조직에서는 스키마를 확장하려고 할 때 자체 OID 루트 번호를 가져와서 OID가 고유한지 확인합니다. 이 루트 번호에서 분기하여 조직에서 만드는 새 개체 클래스와 특성에 고유한 ID를 제공합니다. OID 루트는 ISO NRA(National Registration Authority)에서 직접 가져올 수 있습니다. 미국의 경우 NRA는 ANSI(American National Standards Institute)입니다.
ansi.org에서 루트 OID를 가져오기 위한 절차와 비용 일정을 참조할 수 있습니다. 다른 지역의 경우는 해당 ISO 회원 조직에 문의하십시오. ISO에서 제공하는 목록은 iso.org/iso/about/iso_members.htm에서 확인할 수 있습니다.
이전에는 조직에서 schemreg@microsoft.com으로 전자 메일을 보내 Microsoft로부터 OID를 얻을 수 있었습니다. 하지만 이제는 go.microsoft.com/fwlink/?LinkId=110453에서 VBScript를 다운로드하여 실행하도록 요청자를 안내하는 자동 회신이 전송됩니다.
Microsoft에서 발행하는 OID의 경우에는 Microsoft OID 번호 공간인 1.2.840.113556.1.8000.x 아래에 번호가 할당됩니다. 여기서 x는 조직에 할당된 고유한 번호입니다. 조직에서는 이 OID를 추가 분할하여 개체를 지정할 수 있습니다. 따라서 조직에서는 새 classSchema 개체에 1.2.840.113556.1.8000.x.1.y를 사용하고 attributeSchema 개체에 1.2.840.113556.1.8000.x.2.z를 사용할 수 있습니다. 여기서 x는 조직의 고유 번호를 나타내며 y와 z는 각각 특정 classSchema 및 attributeSchema 개체에 할당된 번호입니다. 이들 개체의 이름에는 서로 구분할 수 있도록 조직 고유의 접두사를 사용하는 것이 좋습니다.

연결된 특성 정의
정방향 링크의 attributeSyntax 값은 2.5.5.1, 2.5.5.7 또는 2.5.5.14가 되어야 합니다. 이들 값은 Object (DS-DN) 구문과 같은 고유 이름이 포함된 구문에 해당합니다.
역방향 링크의 attributeSyntax 값은 Object (DS-DN) 구문인 2.5.5.1이어야 합니다. 관례에 따라 역방향 링크 특성은 최상위 추상 클래스의 mayContain 값에 추가됩니다. 이렇게 하면 역방향 링크 특성이 실제로 개체와 함께 저장되지 않고 정방향 링크 값을 기반으로 계산되기 때문에 모든 클래스의 개체에서 역방향 링크 특성을 읽을 수 있습니다.
Windows Server 2003에는 조직이 스키마의 두 개체를 연결하는 데 사용할 수 있는 기능인 linkID 자동 생성이 추가되었습니다. 특성의 linkID 특성이 1.2.840.113556.1.2.50으로 설정될 경우 시스템에서는 이 기능을 통해 자동으로 새로 연결된 특성의 linkID를 생성합니다. 해당 역방향 링크는 linkID를 정방향 링크의 attributeId 또는 ldapDisplayName으로 설정하여 생성됩니다. 정방향 링크를 만든 후와 역방향 링크를 만들기 전에 스키마 캐시를 다시 로드해야 합니다. 그렇지 않으면 역방향 링크가 만들어질 때 정방향 링크의 attributeId 또는 ldapDisplayName을 찾을 수 없습니다. 스키마 캐시는 필요할 때, 즉 스키마가 변경되고 몇 분 후 또는 도메인 컨트롤러가 다시 부팅되었을 때 다시 로드됩니다.
Active Directory가 Windows 2000 수준에 있는 경우에는 schemreg@microsoft.com으로 전자 메일을 보내 Microsoft에 linkID를 요청해야 합니다. 자동 회신 안에는 "E-mails sent to schemreg@microsoft.com will be processed only if they are related to linkID registrations for legacy environments"라는 줄이 있습니다. 여기서 전자 메일에는 회사 이름, 연락처 이름, 전자 메일 주소, 전화 번호, 등록된 접두사(적용 가능한 경우), 등록된 OID(적용 가능한 경우) 등의 정보가 포함됩니다.

스키마 확장 준비
Active Directory 스키마를 확장하기로 결정했다고 가정하겠습니다. 이 분석에서는 ADLDS(또는 Windows Server 2003에서는 ADAM)를 사용하여 구현되는 대체 디렉터리가 요구 사항에 맞지 않음을 확인한 후 그 사용을 고려하지 않을 수 있습니다. 다음 단계에서는 스키마에 추가할 새 attributeSchema 개체를 식별하고 이 과정에서 이 새 개체를 지정하는 모든 필수 값(예: cn, ldapDisplayName 등)을 정의합니다. 개체의 특성 값을 정의하면서 Microsoft 또는 다른 소스에서 OID를 받습니다. 기본적으로 위 내용을 비즈니스 요구 사항 및 기술 사양으로 문서화했습니다. 또한 실제 Active Directory와 비슷한 랩 환경을 구현하고 테스트할 준비를 완료했습니다.
실제로 많은 조직에서는 이러한 변경을 승인하거나 거부하고 이를 구현하기 위한 프로세스를 수립하는 위원회를 구성하고 있습니다. Active Directory는 많은 조직에서 권한 정보 소스로 사용되며 변경을 적용한 후에도 지속적으로 정상 작동해야 하기 때문에 이러한 검사와 조정 절차는 필수입니다.
조직에서 변경을 진행하기로 결정한 경우에는 이 프로젝트에 대한 테스트 및 구현 계획을 정의해야 합니다. MMC(Microsoft Management Console) 내에서 Active Directory 스키마 스냅인을 사용하거나 프로그래밍 방식 또는 준프로그래밍 방식을 사용하여 새 개체를 추가함으로써 스키마를 확장할 수 있습니다. LDIFDE를 사용하여 .ldif 형식 파일을 가져오거나, CSVDE를 사용하여 .csv 형식 파일을 가져오거나, Active Directory Service Interfaces, ADSI, 스크립팅을 사용하는 경우를 예로 들 수 있습니다.
어떤 방식을 사용하든지 이 기능은 Active Directory 포리스트에서 스키마 마스터의 FSMO(신축 단일 마스터 작업) 역할에 연결하거나 이 역할을 저장하는 서버에서 수행되어야 합니다. 또한 스키마 업데이트에 사용하는 계정에는 충분한 관리 권한이 있어야 업데이트를 수행할 수 있으므로 해당 계정을 Schema Administrators 그룹의 구성원으로 지정해야 합니다. 마지막으로 포리스트에 대한 스키마 업데이트를 사용하도록 설정해야 합니다(기본적으로 사용하지 않도록 설정되어 있음).
변경이 매우 단순한 경우 이외에는 테스트 구현 및 프로덕션 구현 단계 사이의 표준화를 향상시키고 단계를 수동으로 수행할 때 발생할 수 있는 유형의 오류를 줄이기 위해 자동화된 방식으로 변경을 수행해야 합니다. 이제 LDIFDE를 사용하여 변경을 구현하기로 결정했다고 가정하겠습니다. 스키마를 확장할 때 업데이트를 적용하려면 새 특성과 클래스를 추가하고 클래스에 새 특성을 추가한 다음 캐시 다시 로드를 트리거합니다. 몇 가지 시나리오를 살펴보겠습니다.

특성 추가
설명을 위해 Contoso라는 조직에서 각 직원의 신발 크기를 식별하는 특성을 Active Directory에 추가하고자 한다고 가정하겠습니다. Active Directory 포리스트에는 contoso.com과 employees.contoso.com의 두 가지 도메인이 있습니다. 여기서 중요한 점은 사용자 지정 클래스 정의를 사용하여 만들어지는 모든 개체에 이 새 특성이 포함되어야 한다는 것입니다.
같은 포리스트에 있기 때문에 스키마 변경은 두 도메인 모두에 영향을 미친다는 점을 염두에 두어야 합니다. Microsoft에서 1.2.840.113556.8000.9999의 OID를 받았으며 이를 Contoso의 classSchema 개체에 대한 1.2.840.113556.8000.9999.1과 attributeSchema 개체에 대한 1.2.840.113556.8000.9999.2로 다시 나누었다고 가정하겠습니다. 이제 그림 3에서처럼 이 새 개체에 대한 모든 특성 값을 정의하려고 합니다.
Figure 3 contosoEmpShoe 특성 정의 (Close Figure 3)

특성 | 값 | 참고
Cn | contosoEmpShoe |
lDAPDisplayName | contosoEmpShoe |
adminDisplayName | contosoEmpShoe |
attributeSyntax | 2.5.5.12 | 유니코드 문자열 지정
oMSyntax | 64 | 유니코드 문자열 지정
objectClass | top, attributeSchema |
attributeID | 1.2.840.113556.8000.9999.2.1 | 조직에서 정의
isSingleValued | TRUE | 하나의 신발 크기 값만 저장할 수 있음
searchFlags | 1 | 분석을 통해 이 특성을 인덱스해야 한다고 판단되었습니다. 참고: 랩 환경에서 스트레스 테스트 분석을 수행합니다.
isMemberOfPartialAttributeSet | TRUE | 이 특성을 글로벌 카탈로그에서 사용하려고 합니다.
또한 contosoEmpShoe 특성은 사용자 클래스 개체로 만들어진 모든 개체에 사용 가능해야 하지만 사용자 클래스의 기본 정의는 수정하지 않는 것이 좋습니다. 대신 그림 4에서처럼 contosoEmpShoe로 지정된 mayContain 값이 있는 contosoUser라는 보조 클래스를 정의해야 합니다. 그런 다음 contosoUser 보조 클래스에 대해 정의된 특성을 사용자 클래스에 추가합니다.
Figure 4 contosoUser 클래스 정의 (Close Figure 4)

특성 | 값
Cn | contosoUser
lDAPDisplayName | contosoUser
adminDisplayName | contosoUser
governsID | 1.2.840.113556.8000.9999.1.1(조직에서 정의)
mayContain | contosoEmpShoe
possSuperiors | organizationalUnit, 컨테이너
objectClassCategory | 3(보조 클래스 정의)
지금까지 분석을 수행하고 값을 정의했으므로 이제 그림 5의 코드와 비슷한 .ldif 파일을 만들어야 합니다. 그림 5의 내용을 메모장에 복사하고 파일을 contosoUser.ldif로 저장할 수 있습니다. 또는 technetmagazine.com에서 다운로드한 코드에서 사본을 사용할 수도 있습니다.
Figure 5 .스키마를 확장하기 위한 ldif 파일 (Close Figure 5)
#Attribute definition for contosoEmpShoe

dn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: contosoEmpShoe
attributeID: 1.2.840.113556.1.8000.9999.2.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
adminDisplayName: contosoEmpShoe
adminDescription: contosoEmpShoe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: contosoEmpShoe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

# Classes

dn: CN=contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: classSchema
cn: contosoUser
governsID: 1.2.840.113556.1.8000.9999.1.1
mayContain: contosoEmpShoe
rDNAttID: cn
adminDisplayName: contosoUser
adminDescription: contosoUser
objectClassCategory: 3
lDAPDisplayName: contosoUser
name: contosoUser
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: auxiliaryClass
auxiliaryClass: contosoUser
-

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
.ldif 파일을 생성한 후에는 랩 환경에서 구현을 완벽하게 테스트하고, 도메인과 포리스트의 종단 간 복제를 확인하며, 포리스트에서 스키마의 업데이트를 사용할 수 있도록 설정할 수 있습니다. 이 단계에서는 Schema Admin 권한이 있는 계정으로 로그인해야 합니다. 변경이 수행될 스키마 마스터에서 아웃바운드 복제를 사용하지 않도록 설정하고 다음 명령을 실행하여 .ldif 파일을 가져올 수 있습니다.
ldifde –i –f <Path>\contosoUser.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext
변경이 수행되면 스키마 마스터에서 아웃바운드 복제를 사용할 수 있도록 설정하고 모든 도메인 컨트롤러에 대해 복제가 수행되었는지 확인합니다.
이제 모두 마쳤습니다! 사용자 클래스, 즉 사용자 계정을 사용하여 만든 개체와 연결될 새 특성을 스키마에 정의했습니다.
변경을 확인하려면 Active Directory 사용자 및 컴퓨터를 열고 employees.contoso.com 도메인에 연결하여 Users OU(조직 구성 단위)로 이동한 다음 ContosoTestUser라는 새 사용자 계정을 만듭니다. 이제 adsiedit.msc 콘솔을 열고 도메인 파티션 dc=employees,dc=contoso,dc=com에 연결한 다음 Users OU를 확장하고 ContosoTestUser를 마우스 오른쪽 단추로 클릭하여 속성 페이지를 엽니다. contosoEmpShoe 특성을 찾습니다. 이 특성을 편집하여 값을 입력할 수 있습니다. 또한 Ldp.exe 유틸리티를 사용하여 특성을 확인하고 수정할 수 있습니다.
이제 두 특성을 정의하고 연결하는 예제를 살펴보겠습니다. 그리고 Contoso에서 직원의 신발 크기를 중요 요소로 고려하여 회사에서 신발 크기를 재는 사람의 연간 성과를 추적하는 시나리오를 가정해 보겠습니다. 조금 이상한 예제이기는 하지만, Contoso에서 직원의 신발 크기 측정을 담당한 사람과 신발 크기 측정을 마친 사람 및 수를 하나의 특성 쿼리를 통해 추적하고자 한다고 가정하겠습니다. 이러한 유형의 데이터는 데이터베이스 테이블에 저장하는 것이 더 적절하다고 생각할 수 있지만, 여기서는 단지 정방향 링크와 역방향 링크를 설명하기 위한 것입니다.
물론 앞의 예제에서 설명한 것과 같은 종류의 분석을 수행할 수 있습니다. 하지만 여기서는 그림 6에서처럼 .ldif 파일 linkids1.ldif 및 linkids2.ldif를 생성해 보겠습니다. 그런 다음 이 명령을 실행하여 .ldif 파일을 가져옵니다.
Figure 6 정방향 및 역방향 링크 .ldif 파일 (Close Figure 6)

#linkids1.ldif
#Attribute definition for Forward Link Attribute

dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizeTaker
attributeID: 1.2.840.113556.1.8000.9999.2.2
LinkID: 1.2.840.113556.1.2.50
attributeSyntax: 2.5.5.1
isSingleValued: TRUE
adminDisplayName: ContosoShoeSizeTaker
adminDescription: ContosoShoeSizeTaker
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizeTaker
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Reload schema

#linkids2.ldif

#Attribute definition for Backward Link Attribute

dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizesTakenByMe
attributeID: 1.2.840.113556.1.8000.9999.2.3
LinkID: 1.2.840.113556.8000.9999.2.2
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
adminDisplayName: ContosoShoeSizesTakenByMe
adminDescription: ContosoShoeSizesTakenByMe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizesTakenByMe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe Attribute as MayContain in
#contosoUser class

dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizeTaker
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add Backward Link Attribute as MayContain in Top

dn: CN=Top,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

ldifde –i –f <Path>\linkedids<>.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext
이제 사용자 개체가 만들어지면 해당 개체는 ContosoShoeSizeTaker 및 ContosoShoeSizesTakenByMe의 특성을 가집니다. John이라는 사용자의 사용자 개체를 만들 때는 ContosoShoeSizeTaker 특성이 신발 크기를 잰 Frank라는 사람의 DN으로 채워집니다. Frank의 사용자 개체의 속성에서 ContosoShoeSizesTakenByMe 특성을 쿼리하면 결과에는 John의 DN 및 Frank가 신발 크기를 잰 다른 사람이 포함됩니다. 경영진은 Frank의 사용자 계정의 ContosoShoeSizesTakenByMe 특성에 있는 DN 수에 따라 Frank에게 포상할 수 있습니다.

시스템 검사 및 조정
스키마 수정과 같은 중요한 업데이트는 아키텍처 요구 사항에 대한 검사 없이 수행할 수 없습니다. Active Directory에서는 이러한 일관성 검사와 안전 검사를 통해 Active Directory 스키마에 추가나 수정이 이루어질 때마다 해당 변경으로 인한 불일치 또는 기타 문제가 발생하지 않는지 확인합니다.
먼저 각 클래스에 대한 governsID의 값은 스키마 내에서 고유해야 합니다. schemaClass 개체를 정의할 경우 systemMayContain, mayContain, systemMustContain 및 mustContain 목록에 정의되는 모든 특성은 미리 존재해야 합니다. 동시에 subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors 및 possSuperiors 목록에 정의되는 모든 클래스도 미리 존재해야 합니다.
또한 systemAuxiliaryClass 및 auxiliaryClass 목록에서 모든 클래스의 objectClassCategory는 88 클래스 또는 Auxiliary 클래스여야 합니다. 마찬가지로 systemPossSuperiors 및 possSuperiors 목록에서 모든 클래스의 objectClassCategory는 88 클래스 또는 Structural 클래스로 지정되어야 합니다.
여러 클래스를 정의할 때, Abstract 클래스는 다른 Abstract 클래스에서만 상속할 수 있으며 Auxiliary 클래스는 Structural 클래스에서 상속할 수 없고 Structural 클래스는 Auxiliary 클래스에서 상속할 수 없습니다. 또한 rDNAttID 특성에 지정된 특성에는 유니코드 문자열이 구문으로 있어야 하며 단일 값이어야 합니다.
다음은 classSchema 개체와 관련된 몇 가지 규칙입니다. attributeSchema 개체의 경우는 어떻습니까? 클래스의 governsID 값과 마찬가지로 attributeID 값은 고유해야 합니다. 또한 mAPIID 값은 있는 경우 반드시 고유해야 합니다. rangeLower 및 rangeUpper가 있는 경우 rangeLower는 rangeUpper보다 작아야 합니다. attributeSyntax 및 oMSyntax의 값은 일치해야 합니다. 특성이 개체 구문인 경우(oMSyntax =127) 올바른 oMObjectClass가 있어야 합니다. linkID는 있는 경우 반드시 고유해야 합니다. 또한 역방향 링크에는 해당하는 정방향 링크가 있어야 합니다.

실수한 경우
스키마가 새 개체(클래스 및 특성)로 확장된 경우에는 삭제할 수 없습니다. 하지만 스키마 개체에서 특성 isDefunct를 TRUE로 설정하여 클래스나 특성을 비활성화할 수 있습니다. Active Directory와 함께 제공되는 기본 스키마의 일부인 스키마 개체(범주 1 개체)는 비활성화할 수 없습니다. 기본 스키마에 추가된 개체만 비활성화할 수 있습니다. 즉, 범주 2 개체만 비활성화할 수 있으며 Active Directory에서 클래스가 기존의 모든 존재하는 클래스의 subClassOf, auxiliaryClass 또는 possSuperiors 목록에서 사용되지 않음을 확인한 경우에만 비활성화할 수 있습니다.
특성을 비활성화하려는 시도를 통해 Active Directory는 특성이 기존의 존재하는 클래스의 mustContain 또는 mayContain에 사용되지 않는지 확인합니다. 비활성화된 개체는 특성 isDefunct를 FALSE로 설정하여 다시 활성화할 수 있습니다. Active Directory가 Windows Server 2003 수준에 있는 경우에는 비활성화된 개체의 ldapDisplayName, schemaIdGuid, OID 및 mapiID 값을 재사용할 수 있습니다.

결론
스키마의 클래스 또는 특성 정의를 추가하거나 수정하려면 해당 classSchema 개체 또는 attributeSchema 개체를 추가하거나 수정해야 합니다. 이 프로세스는 해당 변경으로 인해 나중에 스키마에서 불일치나 문제가 발생하지 않음을 확인하기 위한 추가적인 검사가 수행된다는 점을 제외하면 Active Directory에서 개체를 추가하거나 수정하는 것과 비슷합니다.
Active Directory 스키마는 쉽게 수정할 수 있지만 스키마의 구조 및 이러한 변경을 구현하기 위해 스키마가 어떻게 작동하는지 이해하는 것이 좋습니다. 프로덕션 Active Directory 스키마를 변경하려면 많은 계획이 필요하며 신중하게 수행해야 합니다. 새 개체에 대한 비즈니스 요구 사항과 기술 사양을 정의하고 철저한 랩 테스트를 수행하는 것이 중요합니다. 변경으로 인해 심각한 영향을 미칠 수 있으므로 꼭 필요한 경우에만 Active Directory 스키마를 확장하는 것이 좋습니다.

Vikas Malhotra는 뉴욕의 Microsoft Consulting Services에서 근무하고 있으며 12년 동안 크고 작은 규모의 여러 IT 조직에서 디렉터리, 메시징, 보안 및 데이터 네트워킹과 같은 인프라 아키텍처 업무를 담당해 왔습니다. Vikas는 전자 통신 공학 학사 학위와 통신 기술 관리 석사 학위를 보유하고 있으며 vikasmal@microsoft.com으로 연락할 수 있습니다.


 System Center: System Center Mobile Device Manager 소개
System Center Matt Fontaine

System Center Mobile Device Manager 소개
한 눈에 보기:
  • 일반적인 Mobile Device Manager 시스템
  • Windows Mobile로 Active Directory 확장
  • Windows Mobile 장치 등록, 프로비저닝 및 인벤토리

Microsoft System Center Mobile Device Manager 2008은 기업 네트워크에서 Windows Mobile 장치를 관리하는 IT 전문가를 위해 개발된 매우 흥미로운 프로그램입니다. 이 새로운 제품 하나에서 장치 관리, 보안 관리 및 모바일 VPN(가상 사설망) 기능을 모두 제공하므로
이를 활용하면 관리 업무를 줄이고 모바일 장치의 ROI(투자 수익률)를 향상하는 데 크게 도움이 될 것입니다.
Mobile Device Manager를 사용하면 기존 Active Directory® 및 그룹 정책 인프라를 사용하여 장치 설정을 적용할 수 있습니다. OTA(무선) 장치 관리 기능을 통해 IT 전문가는 업데이트와 응용 프로그램을 장치에 쉽게 제공할 수 있으며 OTA 자체 프로비저닝을 통해 더욱 확장성이 높고 간편한 방식으로 배포 작업을 수행할 수 있습니다. 최종 사용자는 모바일 VPN 기능을 통해 방화벽 뒤에 있는 데이터와 응용 프로그램에 액세스할 수 있으며 이 동안에도 관리자는 계속 연결된 상태를 유지하여 배포된 장치를 제어할 수 있습니다. 이러한 모든 기능이 확장 가능하고 사용자 지정 가능한 하나의 제품인 Mobile Device Manager에 포함되어 있으므로 이 제품은 오늘날 IT 전문가에게 없어서는 안 될 필수적인 도구일 것입니다.

관리 요구 사항
모바일 사용자는 앞으로도 여러 해에 걸쳐 빠르게 증가할 것으로 예상됩니다. 모바일 장치는 이동성이라는 특성 때문에 다른 네트워크 장비보다 관리하기가 어렵습니다. 모바일 장치는 다양한 방식으로 네트워크에 연결되며, 이 중 많은 장치는 방화벽 밖에 있거나, 클라이언트 장치와 다른 운영 체제를 사용하거나, 크기가 작아 어디에 두었는지 잊어버리거나 잃어버리기 쉽기 때문에 안전하지 않을 수 있습니다.
오늘날 모바일 장치의 확장된 기능은 기업과 최종 사용자 모두에게 매우 뛰어난 이점을 제공하지만 이것은 장치 지원을 더욱 복잡하게 만드는 요인이기도 합니다. 이로 인해 기업의 데이터와 네트워크가 더 많은 보안 위험에 노출될 수 있으며, 중요한 기간 업무(LOB) 응용 프로그램 및 고객 데이터에 액세스하는 장치의 경우에는 특히 그렇습니다. 이러한 장치가 분실, 도난 또는 오용되는 경우 심각한 보안 문제가 발생할 수 있습니다.
모바일 장치와 기존 네트워크 클라이언트가 가진 기능의 차이가 좁혀지면서 모바일 장치를 랩톱 컴퓨터나 데스크톱 컴퓨터와 같이 관리할 수 있는 기능에 대한 요구가 증가하고 있습니다. 이것이 바로 Mobile Device Manager의 기본 개념입니다. 점점 더 많은 비즈니스 사용자들이 Windows Mobile® 플랫폼을 사용하고 있으므로 Mobile Device Manager는 조만간 Windows® 기반 IT 관리 시스템의 중요한 부분으로 자리할 것입니다.
Mobile Device Manager는 Windows Mobile 장치가 네트워크에 연결된 PC나 랩톱인 것처럼 간편하게 종단 간 관리 및 제어를 수행할 수 있도록 설계되었습니다. Mobile Device Manager의 세 가지 주요 기능은 다음과 같습니다.
장치 관리. 서버당 사용자 수를 수십 명에서 수천 명까지 확장할 수 있으며 중앙에서 Windows Mobile 장치를 프로비저닝, 모니터링 및 관리할 수 있는 기능입니다.
보안 관리. 중요한 데이터를 보호하고 장치를 추적할 수 있는 보다 효율적인 메커니즘입니다.
모바일 VPN. 방화벽 뒤에 있는 데이터 및 응용 프로그램에 항상 효율적으로 액세스할 수 있도록 하는 기능입니다.
Mobile Device Manager는 모바일 장치를 데스크톱이나 랩톱 컴퓨터와 동등한 회사의 자산으로 취급하여 최상의 수준으로 관리할 수 있는 도구를 제공하려는 System Center의 이념에 따라 마련되었습니다. Mobile Device Manager는 다른 System Center 제품을 사용해 본 경험이 있는 사용자에게 친숙한 사용자 인터페이스를 제공합니다.
다시 말해 이는 Mobile Device Manager가 기존 Windows 기반 인프라에서도 설계대로 잘 작동한다는 점을 의미합니다. 몇 가지 예를 들면 Mobile Device Manager는 Active Directory 및 그룹 정책을 사용하고, 기존 Microsoft 분석 및 보고 도구(예: SQL Server®)와 함께 작동하며, Microsoft® Management Console 스냅인과 Windows PowerShellTM cmdlet을 사용하여 확장할 수 있습니다.

Mobile Device Manager 시스템
Mobile Device Manager는 확장성이 우수하며 하나의 인스턴스에서 수만 개의 장치와 여러 구성 옵션을 지원할 수 있습니다. 일반적으로 Mobile Device Manager의 서버 쪽에는 게이트웨이 서버, 장치 관리 서버, 등록 서버, SQL Server 데이터베이스 등의 네 가지 주요 시스템 구성 요소가 있습니다(그림 1 참조).
그림 1 일반적인 Mobile Device Manager 시스템
그림 1 일반적인 Mobile Device Manager 시스템
게이트웨이 서버는 일반적으로 경계 네트워크에 설치되어 장치 네트워크 연결의 터미널 역할을 하고, 들어오는 장치 연결을 인증하고, 장치에 대해 안정적인 IP 주소를 제공하며 장치 및 네트워크 연결과 관련된 기타 기능을 수행합니다.
장치 관리 서버는 그룹 정책 구현, OTA 소프트웨어 배포, 장치 데이터 삭제와 같은 장치 운영 및 관리 작업의 허브입니다. 이 서버는 기존 도메인 컨트롤러에서 작동합니다. 장치 관리 서버는 Windows Mobile 장치의 서로게이트 네트워크 클라이언트 역할을 하여 Windows Mobile 장치가 다른 시스템과 통신할 수 있도록 지원합니다.
등록 서버는 도메인 컨트롤러의 모바일 장치를 나타내는 Active Directory 도메인 서비스 개체를 만듭니다. 이를 통해 모바일 장치를 다른 도메인 구성원과 같이 관리할 수 있습니다. 등록 서버는 또한 모바일 장치의 인증서 요청 및 검색 작업을 처리하며 등록 인증서를 수락하거나 발급하기 전에 기본적으로 Active Directory를 사용하여 장치를 인증합니다. SQL Server 데이터베이스에서는 장치 구성, 작업, 상태 설정 등과 관련된 정보를 모두 보관할 수 있는 리포지토리를 제공합니다.
인프라가 준비되어 실행되면 Mobile Device Manager가 장치 등록, 모바일 VPN 연결 설정, 장치 관리 등 세 가지 과정을 통해 모바일 장치와 상호 작용합니다. 장치 등록은 장치가 Active Directory 도메인에 참가하는 과정입니다. Mobile Device Manager는 만료되는 일회성 암호인 "공유 암호"를 사용하여 장치가 비보안 연결을 통해 등록될 수 있도록 지원합니다. 등록된 장치는 네트워크 트래픽을 라우팅할 게이트웨이 서버에 대한 모바일 VPN 연결을 설정할 수 있습니다. 모바일 VPN 연결을 사용하면 관리자 또는 시스템이 소프트웨어 및 설정을 장치에 배포하여 장치 관리를 수행할 수 있습니다.

Windows Mobile로 Active Directory 확장
하이브리드 또는 애드혹 IT 보안 방식은 완전히 통합된 보안 방식보다 위험할 수 있습니다. Mobile Device Manager는 기존 Active Directory 도메인 서비스 인프라를 사용하여 Windows PC와 같은 모바일 장치를 관리할 수 있도록 함으로써 이러한 위험을 줄일 수 있도록 설계되었습니다. 그 결과 ID 및 액세스 관리 작업을 보다 효율적으로 처리할 수 있고, 정책 대상을 더욱 일관되게 지정할 수 있으며 보안 구성을 한번에 수행할 수 있습니다.
PC 또는 서버와 마찬가지로 Windows Mobile 장치와 관련된 그룹 정책 개체를 OU(조직 구성 단위), 보안 그룹 및 WMI(Windows Management Instrumentation) 필터에 할당할 수 있습니다. 관리자는 또한 특정 장치가 그룹 정책 설정을 가져오지 못하도록 할 수도 있습니다.
Windows Mobile 장치와 관련한 설정 및 정책이 130개 이상 제공되므로 이를 활용하여 다양한 기능을 세부적으로 제어할 수 있습니다. 이에 대한 예를 통해 살펴보겠습니다.
  • 암호 설정에는 암호 요구 사항, 암호 형식 및 최소 길이, 암호 만료, 지정된 횟수만큼 암호 시도가 실패하면 로컬 장치 데이터 삭제(남은 암호 시도 횟수에 대한 사용자 알림 포함) 등이 있습니다.
  • 플랫폼 잠금 설정을 통해 관리자는 카메라, 무선 LAN, 적외선 통신, Bluetooth, 이동식 저장소 등의 장치 기능을 선택적으로 설정하거나 해제할 수 있습니다. POP(Post Office Protocol), IMAP(Internet Message Access Protocol), SMS(Short Message Service), MMS(Multimedia Messaging Service) 메시징 기능을 모두 해제할 수 있으며 Windows Mobile용 Windows Update도 해제할 수 있습니다.
  • Mobile Device Manager는 세부적인 수준의 응용 프로그램 제어 기능을 제공합니다. 따라서 장치가 승인되지 않은 서명을 가진 응용 프로그램이나, 서명되지 않은 응용 프로그램을 실행하지 못하도록 하거나 관리자 판단 하에 특정한 서명되지 않은 응용 프로그램을 허용할 수 있습니다.
  • 데이터를 효과적으로 보호하기 위해 관리자는 이동식 저장소 카드에서 생성된 파일을 장치에 연결된 암호화 키를 사용하여 암호화할 수 있습니다. 장치 암호화는 장치의 중요한 데이터를 보호하는 데도 사용할 수 있습니다. 관리자는 기본적으로 보호되는 파일 외에도 추가 파일을 암호화하도록 지정할 수 있습니다.
  • 모바일 VPN 설정을 사용하면 장치의 VPN 연결에 대해 사용자가 가질 수 있는 제어 수준과 데이터 암호화 수준을 설정할 수 있습니다.
  • ActiveSync® 설정을 통해서는 메시지 형식, 전자 메일 수명 필터, 크기 제한, 동기화 설정 등을 설정할 수 있습니다.
  • S/MIME 설정을 통해서는 메시지 서명, 메시지 암호화 또는 특정 알고리즘 사용을 요구할 수 있습니다.
위에서 설명한 설정을 비롯한 여러 가지 설정은 다양한 시나리오를 지원합니다. 이러한 설정을 통해 IT 전문가는 특정 장치에서 실행될 수 있는 응용 프로그램 유형을 결정할 수 있습니다. 또한 하드웨어 기능을 무선으로 설정하거나 해제할 수 있습니다. 예를 들어 중요한 정보가 실수로 또는 의도적으로 노출되지 않도록 카메라 기능을 해제할 수 있습니다. 장치 또는 이동식 저장소 카드(또는 두 장치 모두)에 데이터 암호화를 설정하여 장치 또는 카드의 분실이나 도난으로 인해 개인 소유의 데이터가 권한이 없는 타인에게 넘어갈 수 있는 가능성을 줄일 수 있습니다.
이외에도 여러 보안 관리 도구가 Mobile Device Manager에 포함되어 있습니다. Windows Mobile 장치에서 사용할 수 있는 응용 프로그램이 무수히 많으므로 관리자는 이러한 응용 프로그램의 설치 지원 여부를 확실하게 제어해야 합니다. Mobile Device Manager를 사용하면 응용 프로그램의 허용 및 차단 목록을 작성하여 적용할 수 있습니다. 또한 Mobile Device Manager에는 강력한 원격 데이터 삭제 기능도 있습니다. 장치에 대한 VPN 연결이 항상 유지되므로 장치가 네트워크에 연결되어 동기화될 때까지 기다릴 필요 없이 장치의 데이터를 즉시 삭제할 수 있습니다. 장치 데이터를 원격으로 삭제하면 장치가 도메인 컨트롤러에서 제거되며 해당 인증서는 해지됩니다. 이후에 장치를 복원하면 새 일회용 암호를 사용하여 다시 등록한 후에 장치가 도메인에 다시 참가하도록 설정할 수 있습니다.

지속적인 모바일 장치 확인
Mobile Device Manager는 OTA 프로비저닝, OTA 소프트웨어 및 업데이트 배포, 종합적이고 중앙 집중적인 인벤토리 관리 기능을 비롯한 완벽한 장치 관리 기능을 하나의 솔루션을 통해 제공함으로써 네트워크에서 Windows Mobile 장치를 최대한 쉽게 관리할 수 있도록 설계되었습니다.
OTA 자체 등록 기능은 시간이 부족한 IT 전문가와 최종 사용자들의 마음을 사로잡을 수 있는 기능입니다. 사용자가 Windows Mobile 6.1 장치에 전자 메일 주소를 입력하면 입력된 전자 메일 주소를 사용하여 모바일 장치 관리 서버를 찾습니다. 서버를 찾지 못하면 사용자에게 관리 서버 주소를 직접 입력하라는 메시지가 표시됩니다. 서버를 찾은 경우 사용자가 등록할 수 있는 것으로 확인되면 사용자에게 관리자가 미리 생성한 일회용 암호를 입력하라는 메시지가 표시됩니다.
전자 메일 주소와 암호는 사용자를 인증하고 사용자 장치를 관리 서버에 등록하는 데 사용됩니다. 암호를 입력하여 장치가 인증 및 등록되면 관리자가 정의한 설정과 정책이 장치에 적용됩니다. 자체 등록 방식은 Windows Mobile 장치 배포의 확장성을 높이고 이러한 장치를 시작하고 실행하는 데 필요한 시간과 비용을 줄이기 위해 마련되었습니다.
Mobile Device Manager의 OTA 소프트웨어 배포 기능은 이미 전 세계의 많은 IT 전문가들이 사용하고 있는 소프트웨어 업데이트 도구 키트인 Windows Software Update Services(WSUS) 3.0을 기반으로 합니다. 그림 2와 같이 WSUS 3.0은 복잡한 IT 요구 사항을 충족하기 위한 대상 지정 및 응용 프로그램 패키징 기능을 제공합니다. 따라서 관리자가 설정한 규칙과 정책에 따라 소프트웨어를 적절한 장치에 자동으로 제공할 수 있습니다. 서버 및 클라이언트 업데이트와 마찬가지로 모바일 장치 업데이트와 패치도 WSUS 3.0을 사용하여 자동화할 수 있습니다. 배포 계획 및 테스트 작업 중에는 자동 업데이트 기능을 해제할 수 있음을 기억하십시오.
그림 2 소프트웨어 배포 마법사
그림 2 소프트웨어 배포 마법사
빠르게 배포되는 모바일 장비 관리와 관련한 최대 과제 중 하나는 모든 정보를 간편하게 추적하는 기능을 제공하는 것입니다. Mobile Device Manager는 인벤토리 정보를 중앙에서 처리하여 많은 사용자가 이미 컴퓨터에 설치하여 사용하고 있는 익숙한 소프트웨어인 SQL Server 2005 기반의 유연하고 사용자 지정 가능한 보고서를 제공합니다. 관리자는 운영 체제 및 버전, 장치 모델, 설치된 응용 프로그램, 보안 정책을 비롯한 수백 개 이상의 인벤토리 정보 항목을 수집할 수 있습니다. 이러한 인벤토리는 확장이 가능하므로 관리자는 항목 및 레지스트리 설정을 추가할 수 있습니다.
훨씬 높은 수준의 유연성을 제공하는 Mobile Device Manager는 그래픽 사용자 인터페이스를 선호하는 경우 Microsoft Management Console 스냅인을 사용하거나(그림 3 참조), 명령줄을 선호하는 경우 Windows PowerShell 콘솔을 사용하여 제어할 수 있습니다. 어떤 방법을 사용하든 시스템을 확장하고 사용자 지정할 수 있습니다. 이는 소프트웨어를 조직에 맞게 구성하려는 기업 사용자에게 꼭 필요한 기능입니다.
그림 3 Mobile Device Manager 콘솔
그림 3 Mobile Device Manager 콘솔

모바일 VPN
정보 근로자는 수년 동안 모바일 장치를 통해 다른 사람들과 전자 메일 및 메시지를 주고 받았습니다. 오늘날 모바일 장치 기술에서 개발된 가장 유용한 기능 중 하나는 방화벽 뒤에 있는 비즈니스 데이터 및 응용 프로그램에 액세스하는 기능입니다. 액세스가 늘어남에 따라 새로운 보안 위험이 생겨나므로 공격에 잘 대처할 수 있도록 추가 기능을 주의해서 관리해야 합니다. Mobile Device Manager는 최첨단 모바일 VPN 기능을 제공하므로 이러한 기능을 통해 Microsoft DynamicsTM Customer Relationship Management(CRM)에서 SAP 또는 Siebel에 이르는 인트라넷 데이터에 액세스할 수 있습니다. 이러한 모델은 데스크톱 및 랩톱 PC의 기존 원격 액세스 전략에 부응하도록 설계되었습니다(그림 4 참조).
그림 4 Mobile VPN Settings(모바일 VPN 설정)
그림 4 Mobile VPN Settings(모바일 VPN 설정)
모바일 VPN은 데이터가 IPsec 암호화 터널을 통해 SSL 암호화 형식으로 전송되는 이중 보안 기능을 사용하여 장치를 게이트웨이 서버에 연결합니다. 장치가 인증되면 사용자는 사용자의 자격 증명과 리소스 특정 정책에 지정된 대로 리소스에 대한 액세스 권한을 부여 받습니다.
Mobile Device Manager에서 사용되는 모바일 VPN 기술을 통해 항상 연결된 상태가 유지되므로 사용자들은 향상된 액세스 환경을 이용할 수 있으며 IT 전문가는 현재 정책 및 설정에 따라 장치를 항상 업데이트된 상태로 유지할 수 있습니다. 또한 장치가 분실되거나 도난된 경우 장치 데이터를 바로 삭제할 수 있습니다. 세션이 중단되더라도 신속하게 다시 연결되므로 장치 세션이 재인증 없이 계속될 수 있습니다. Mobile Device Manager를 사용하면 연결을 유지하는 동시에 Wi-Fi와 셀룰러 네트워크 간의 자연스러운 전환이 가능합니다.
Mobile Device Manager의 모바일 VPN에서 사용되는 보안 기술은 Open Mobile Alliance for Device Management(OMA DM), Internet Key Exchange(IKE) 버전 2 및 OMA Software Component Management Object(SCOMO) 등의 업계 표준을 기반으로 합니다. 이를 통해 복잡한 환경에서 근무하는 IT 전문가가 자신이 직면한 상황에 맞게 시스템을 보다 효과적으로 확장하고 사용자 지정할 수 있습니다.

완벽한 솔루션
Mobile Device Manager는 Windows Mobile 장치를 관리하는 데 필요한 모든 도구를 완전하게 제공하며 하나의 인터페이스를 통해 이를 모두 액세스할 수 있습니다. 또한 Active Directory 및 그룹 정책을 활용하여 데이터, 장치 및 네트워크에 대한 보안을 개선할 수 있습니다. 장치 관리 작업은 OTA 등록, 프로비저닝, 업데이트와 강력한 인벤토리 도구를 통해 보다 수월하게 수행할 수 있습니다. 모바일 VPN은 보안에 영향을 미치지 않고 기업 및 사용자가 원하는 기능을 제공하도록 설계되었습니다.
이러한 모든 기능은 모바일 장치가 네트워크에서 최상의 수준으로 관리될 수 있도록 함으로써 IT 전문가의 업무를 지원하는 필수적인 기능입니다. Mobile Device Manager를 사용하면 IT 전문가가 뛰어난 품질의 최종 사용자 환경을 제공하고, 관리 오버헤드를 줄이고, 관리와 관련하여 보다 나은 ROI를 창출할 수 있습니다. 이런 것들이 복합적으로 작용하면 엄청난 가치를 얻을 수 있을 것입니다.
이 기사에 도움을 주신 Brian Hoskins, Derek Snyder, Prithvi Raj, Lax Madapaty, Katharine Holdsworth에게 감사의 인사를 전합니다.

Matt Fontaine은 자유 기고 테크니컬 라이터이자 BuzzBee에서 컨설턴트로 근무하고 있습니다. Matt는 고성능 컴퓨팅, 기업 소프트웨어, 보험 수리, 상업용 부동산, 엔지니어링, 건설, 소비재 등의 다양한 분야에서 활동 중이며 Evergreen State College를 졸업한 인재입니다.


 System Center: System Center Essentials SP1의 새로운 기능
System Center

System Center Essentials SP1의 새로운 기능
한 눈에 보기:
  • 통합된 설치 관리자 패키지를 사용한 쉬운 설치
  • 관리 팩 세부 조정을 위한 향상된 재정의 기능
  • 작업 그룹 지원
  • 새로운 상태 재계산 작업

지난 7월 출시된 System Center Essentials 2007과 함께 Microsoft는 고가의 복잡한 엔터프라이즈 도구와 셰어웨어 솔루션 간의 차이를 좁혀 IT 작업을 위한 통합된 관리 솔루션을 제공함으로써
중기업에 크게 기여했습니다. Essentials 2007은 IT 전문가가 다양한 업무를 수행해야 하는 중기업에서 발생하는 문제를 해결하기 위해 특별히 설계되었습니다.
Essentials는 설치 및 구성이 쉬우므로 IT 전문가가 클라이언트와 서버를 사전에 모니터링할 수 있을 뿐만 아니라 하드웨어 및 소프트웨어 자산을 추적할 수도 있습니다. 이 제품은 응용 프로그램 및 IT 서비스 모니터링, 클라이언트/서버 소프트웨어 배포, 데스크톱 문제 해결 등 기존의 복잡한 작업을 간소화하도록 설계되었습니다.
초기 릴리스 이후 Microsoft에서는 IT 인프라를 관리하는 데 Essentials를 이미 사용하고 있는 실사용자로부터 의견을 수집해 왔으며 제품의 첫 번째 서비스 팩에 이 정보를 반영했습니다. SP1에는 단순히 버그 수정을 제공하는 차원을 넘어 다양한 배포 시나리오에서 보다 융통성 있게 고객의 요구 사항을 충족할 수 있도록 제품에 대한 중요한 개선 사항이 포함되어 있습니다. 뿐만 아니라 향상된 성능은 사용자 환경을 개선하고 관리 작업을 능률화하는 데 큰 영향을 줍니다.
이 기사에서는 Essentials 2007 SP1에 포함된 주요 개선 사항을 살펴보고 이러한 개선 사항이 환경을 관리하는 데 얼마나 도움이 되는지 알아봅니다.

쉬운 설치
SP1 통합 설치 관리자 패키지에는 최신 Essentials 핫픽스가 모두 포함되어 있기 때문에 마우스를 몇 번만 클릭하면 쉽게 설치할 수 있습니다. 이제 Essentials Server는 32비트 Windows Server® 2003 인스턴스에 두고 Essentials는 원격 64비트 SQL Server® 2005 인스턴스를 사용하도록 구성할 수 있습니다. 이렇게 하면 관리자가 현재 환경의 기존 서버 인프라를 분산된 Essentials 배포 토폴로지에서 보다 유연하게 활용할 수 있습니다. 또한 Windows Server 2008이 Essentials 2007 SP1 Server, 콘솔 및 에이전트 플랫폼으로 지원될 예정입니다. Windows Server 2008은 새 운영 체제의 RTM 버전이 출시된 직후에 완벽하게 지원될 것입니다.

향상된 콘솔 성능
Essentials 2007 RTM 릴리스를 사용해봤다면 응답 성능이 크게 향상된 SP1의 Essentials 콘솔 인터페이스에 만족할 수 있을 것입니다. 경고, 이벤트, 성능, 상태 및 작업 상태 보기의 성능이 개선되었습니다. 예를 들어 모든 경고 보기에서는 데이터 가져오기(검색) 방식이 변경되어 경고 데이터 선택 속도가 3배까지 빨라졌습니다. 이제는 작업과 보고서 가져오기가 백그라운드에서 실행되기 때문에 UI 성능이 더욱 향상되었습니다. 마찬가지로 운영 콘솔 오른쪽의 작업 창에 표시되는 컨텍스트 기반의 작업 및 보고서도 백그라운드에서 로드되기 때문에 사용자의 선택 항목이 보기에 더 빠르게 반영됩니다.
이제 Show Knowledge(정보 표시) 또는 Hide Knowledge(정보 숨기기) 링크(그림 1 참조)를 클릭하여 경고 정보 창에 표시되는 경고 정보를 사용자의 필요에 따라 표시하거나 숨길 수 있습니다. 이 기본 설정은 향후 경고를 볼 때도 그대로 적용됩니다. 또한 관리자가 표준 바로 가기 키(예: Ctrl+C 및 Ctrl+V)를 사용하여 경고 정보를 복사하고 붙여 넣을 수도 있습니다.
그림 1 정보 표시/숨기기 링크가 있는 경고 정보 창
그림 1 정보 표시/숨기기 링크가 있는 경고 정보 창

재정의 개선 사항
재정의는 불필요한 규칙과 모니터를 사용하지 않도록 설정하고 여러 임계값을 적절하게 수정하여 관리 팩을 조정하는 데 사용됩니다. 재정의와 관련하여 몇 가지 주요 기능이 개선되어 규칙과 모니터를 사용자의 환경에 맞게 보다 쉽게 조정할 수 있을 뿐만 아니라 Essentials 환경에 이미 적용되어 있는 재정의를 보다 효율적으로 파악할 수 있습니다. 그 결과 사용자 지정 규칙을 만들어야 하는 번거로움이 줄어들고 현재의 환경에 적용되어 있는 재정의를 보다 빠르게 파악할 수 있습니다.
예를 들어 특정 관리 팩 개체에 대한 재정의를 만든 후 재정의 요약 상자에서 개체 형식별로 재정의에 대한 요약을 볼 수 있습니다. Essentials 2007 SP1에서는 재정의 대상에 대한 완벽한 설명을 제공합니다. 예를 들어 Server1의 C:\ 드라이브에 대해 논리 디스크 여유 공간에 대한 재정의를 만들면 요약에 'server1/c:'가 표시됩니다. 이러한 변경된 기능의 중요성을 예를 들어 설명하겠습니다.
그림 2의 경우 Essentials 2007 RTM 릴리스에서 볼 수 있는 Windows Server 2003 논리 디스크 여유 공간에 대한 재정의 요약에서는 재정의 대상인 C:\ 드라이브 인스턴스가 어떤 컴퓨터에서 호스팅되는지 전혀 알 수 없습니다. 그러나 Essentials SP1에서는 동일한 재정의 요약의 이름 열에 대상 드라이브 인스턴스뿐만 아니라 해당 드라이브를 호스팅하는 컴퓨터도 표시됩니다(그림 3 참조).
그림 2 Essentials 2007 RTM의 재정의 요약
그림 2 Essentials 2007 RTM의 재정의 요약
그림 3 Essentials 2007 SP1의 같은 재정의 요약
그림 3 Essentials 2007 SP1의 같은 재정의 요약
경고 심각도는 관리자가 수집하는 경고 트래픽의 양에 큰 영향을 줄 수 있습니다. 지금까지는 중요한 경고를 생성하도록 Essentials 규칙을 봉인된 관리 팩에 구성하면, 일부 서버에서는 이 경고가 중요하지 않더라도 경고 심각도와 우선 순위가 규칙 재정의에 제공되지 않기 때문에 관리자가 이 설정을 조정할 수 없었습니다. 유일한 해결 방법은 일부 컴퓨터에 대해서는 규칙을 사용하지 않도록 하는 재정의를 만든 다음, 경고 매개 변수를 조작할 수 있도록 봉인된 관리 팩의 규칙을 다시 만드는 것입니다. 하지만 이 방법은 번거로울 뿐만 아니라 관리자의 측면에서 볼 때 그리 권장할 만한 방법이 아닙니다.
그림 4에서 볼 수 있듯이 SP1에서는 봉인된 모든 관리 팩 규칙에 경고 심각도와 우선 순위가 재정의 매개 변수로 제공되어 이러한 문제가 깔끔하게 해결되었습니다. 따라서 관리자가 재정의를 만들어 Essentials 2007의 규칙을 통해 생성된 경고의 심각도와 우선 순위를 쉽고 빠르게 높이거나 낮출 수 있습니다.
그림 4 경고 민감도 및 우선 순위 규칙 재정의
그림 4 경고 민감도 및 우선 순위 규칙 재정의
이미 눈치채셨을지 모르지만 Essentials RTM 릴리스의 콘솔 인터페이스에서는 볼 수 없었던 적용 확인란(그림 4 참조)이 새로 추가되었습니다. 개체에 대해 재정의를 여러 개 설정한 경우 적용 플래그가 선택된 재정의에 더 높은 우선 순위가 부여됩니다. 이 옵션은 개체 그룹 두 개에 동일한 재정의를 설정하고 일부 개체가 두 그룹 모두에 속해 있는 경우에 유용합니다. 우선적으로 적용할 재정의에 적용 옵션을 설정하면 적용되는 재정의 설정을 정확하게 제어할 수 있습니다.
Essentials 2007 SP1에서는 새 관리 팩을 보다 쉽게 만들 수 있도록 기존 관리 팩의 보기를 봉인된 관리 팩에 복사할 수 있는 기능이 추가되었습니다. 이 복사 작업은 이벤트, 경고, 성능, 대시보드, 다이어그램 등과 같이 모든 종류의 보기에서 지원되며 모니터링 영역에서 수행할 수 있습니다. 예를 들어 Active Directory® 재정의 관리 팩을 만든 후 Active Directory 관리 팩의 보기 중 하나를 Active Directory 재정의 관리 팩에 사용하려는 경우, 모니터링 영역의 탐색 창에서 적절한 보기를 선택한 후 원하는 사용자 지정 관리 팩 폴더에 복사하여 붙여 넣습니다.

새 재정의 보고
Microsoft® Generic Reporting Library의 재정의 보고서도 주목할 만한 새로운 기능으로, Essentials 콘솔의 보고 창에 포함되어 있습니다. 이 보고서를 사용하면 재정의가 저장된 관리 팩 또는 해당 재정의가 적용된 관리 팩의 관점에서 재정의에 대해 설명할 수 있습니다(그림 5 참조). 사용자는 봉인된 MP 재정의를 보고서에서 제외하는 보고서 매개 변수를 설정할 수도 있습니다. Microsoft 또는 타사의 봉인된 관리 팩에는 사용자의 환경에서 변경된 사항을 보고할 때 신경 쓰지 않아도 되는 재정의가 많이 포함되어 있기 때문에 이 필터링 옵션을 사용하는 것이 좋습니다.
그림 5 재정의 보고서 매개 변수
그림 5 재정의 보고서 매개 변수
Microsoft에서 제시하는 모범 사례에 따라 봉인된 각 관리 팩(Active Directory MP, Exchnage MP 등 각각에 하나씩)에 대해 별도의 사용자 지정 관리 팩을 만들면 보고서의 범위를 보다 효율적으로 좁혀 특정 관리 팩에 적용되는 재정의만 필터링하여 볼 수 있습니다.
봉인되지 않은 적절한 관리 팩을 선택하면 보고서를 실행할 수 있으며 그러면 그림 6과 같이 결과가 표시됩니다. 보고서에는 재정의가 적용되는 규칙 또는 모니터(영향을 받는 요소 열)뿐만 아니라 모니터와 관련된 설치 및 삭제 날짜/시간이 정확하게 표시됩니다. 이는 재정의 보고서가 활성 재정의 목록임은 물론 재정의 구성 변경 기록에 대한 보고서임을 의미합니다.
그림 6 재정의 보고서 정보
그림 6 재정의 보고서 정보
마지막으로, 영향을 받는 각 규칙 또는 모니터에 대한 세부 보기의 맨 아래에는 Rule configuration view(규칙 구성 보기)라는 하이퍼링크가 있습니다. 이 링크를 클릭하면 영향을 받는 개체 형식에 맞게 범위가 지정된 별도의 규칙 보기 또는 모니터 보기가 열립니다. 예를 들어 그림 6에 나와 있는 Active Directory Domain Controller Server 2003 컴퓨터 역할의 규칙에 대한 재정의에 대해 Rule configuration view(규칙 구성 보기) 링크를 클릭하면 규칙 보기에 해당 개체 형식에 해당되는 규칙만 표시됩니다.

작업 그룹 컴퓨터 지원
고객의 의견 중에서는 작업 그룹 구성에서 서버와 워크스테이션을 관리할 필요성과 관련된 지적이 많았습니다. 대부분의 환경에는 도메인에 가입되지 않은 경계 네트워크 또는 지점에 설치된 서버가 적어도 하나씩은 있습니다. Essentials에서는 Essentials Server와 에이전트 관리 컴퓨터 간에 상호 인증이 필요하기 때문에 Essentials 서버의 트러스트 경계 밖에 있는 작업 그룹 컴퓨터는 Essentials 에이전트 배포 범위에 포함되지 않습니다. 즉, 이것은 대부분의 환경에서 인프라의 핵심적인 구성 요소가 모니터링되지 않은 상태로 Essentials 패치 관리 프로세스에서 배제되어야 한다는 의미입니다. 이러한 컴퓨터를 안전하게 관리하려면 어떻게 해야 할까요?
SP1에서는 Active Directory 및 Kerberos 인증을 사용할 수 없는 시나리오에서 인증서 기반 인증을 사용할 수 있습니다. 이 기능을 사용하려면 Essentials Server와 에이전트 관리 컴퓨터 모두에 X.509 디지털 인증서가 설치되어 있어야 합니다. 디지털 인증서는 Windows® Standalone 또는 Enterprise 루트 인증 기관에서 발급받을 수 있습니다. 현재 사용 중인 환경에 Windows 인증 기관이 없는 경우, 프로그램 추가/제거를 통해 Essentials Server를 포함하여 현재 환경 내의 도메인 컨트롤러나 구성원 서버에 이 기능을 설치할 수 있습니다. Windows Server 2003의 인증서 서비스 및 PKI(공개 키 인프라)에 대한 자세한 내용은microsoft.com/windowsserver2003/technologies/pki를 참조하십시오.
Essentials에서 인증서 기반 인증을 구성하려면 먼저 Essentials Server와 관리 대상 컴퓨터 모두에 대해 인증서를 요청하고 발급해야 합니다. 요청은 인증 기관으로 사용하는 서버에서 웹 사이트를 통해 입력할 수 있습니다.
인증서를 발급받아 설치한 후에는 MOMCertImport 명령줄 유틸리티를 사용하여 Essentials에서 사용할 수 있도록 "등록"해야 합니다. 인증서 구성을 완료하려면 인증서를 파일(.pfx 형식)로 내보낸 후 로컬 컴퓨터에서 다음 구문을 사용하여 MOMCertImport를 실행하면 됩니다.
MOMCertImport.exe <cert path \ name>
Essentials Server와 관리 대상 컴퓨터에서 이 모든 단계를 실행했으면 두 시스템이 상호 인증되어 암호화된 채널을 통해 데이터를 안전하게 주고받을 수 있습니다. 에이전트 배포 프로세스를 완료하려면 대상 컴퓨터에 Essentials 에이전트를 직접 설치하면 됩니다.

네트워크 및 장치 모니터링
Essentials 2007에는 SNMP 지원 네트워크 장치 대부분의 일반적인 특성을 파악할 수 있는 네트워크 장치 모니터링 기능이 포함되어 있습니다. SNMP 버전 2c(SNMPv2c)가 가장 많이 사용되고는 있지만 모든 네트워크 장치가 동일하게 만들어지는 것은 아닙니다. 이 점을 감안하여 SP1에서는 SNMPv2c를 지원하지 않는 UPS, 라우터, 인쇄 서버 등과 같은 많은 이전의 네트워크 장치를 모니터링할 수 있도록 SNMP 버전 1(SNMPv1)을 지원합니다. 그림 7에서 볼 수 있듯이 관리자는 컴퓨터 및 장치 관리 마법사에서 추가 드롭다운 필드를 통해 Essentials에서 사용할 SNMP 버전을 직접 지정할 수 있습니다.
그림 7 네트워크 장치 검색을 위한 향상된 인터페이스
그림 7 네트워크 장치 검색을 위한 향상된 인터페이스

향상된 업데이트 관리
또한 SP1에서는 업데이트 관리 기능이 크게 향상되었습니다. WSUS(Windows Server Update Services) 3.0 자동 승인 규칙을 사용하면 Microsoft Word에 대한 정의 업데이트의 자동 승인과 같이 여러 제품 및 업데이트 분류를 지정할 수 있습니다.
이제 여러 자동 승인 규칙에 대한 지원이 Essentials에 추가되어 WSUS 3.0 플랫폼에서와 동일한 기능을 사용할 수 있습니다(그림 8 참조). 따라서 관리자는 Windows Vista®의 중요 업데이트 및 2007 Office system용 서비스 팩을 포함하여 여러 종류의 업데이트에 대해 자동 승인을 만들 수 있습니다. 이렇게 하면 WSUS 서버에서 사용할 수 있는 모든 업데이트에 대해 자동 승인 규칙이 적용됩니다. 관리자는 자동 승인 대화 상자에서 지금 규칙 실행 작업을 클릭하여 Essentials 콘솔에 있는 기존 업데이트에 변경 사항을 즉시 적용할 수 있습니다.
그림 8 업데이트 관리의 자동 승인
그림 8 업데이트 관리의 자동 승인
또한 관리자는 작업 그룹의 컴퓨터에 에이전트를 배포할 수 있는 추가적인 지원을 통해 Essentials 콘솔에서 전체 환경의 업데이트 관리를 제어할 수 있습니다.

개체 상태 계산
이전에는 상태 탐색기에서 모니터 상태를 확인할 때 복구나 다른 조치가 성공적으로 수행되었는지 확인하려면 모니터 상태가 정기적으로 새로 고쳐질 때까지 기다려야 했습니다. 그러나 SP1의 상태 탐색기 버전에는 모니터 상태를 필요할 때 다시 계산할 수 있는 Recalculate Health(상태 다시 계산) 작업이 새로 추가되었습니다(그림 9 참조). 이 기능을 사용하면 조치를 취한 후 기다릴 필요 없이 모니터 상태가 정상인지 확인할 수 있기 때문에 문제 해결 프로세스를 훨씬 빠르게 수행할 수 있습니다.
그림 9 상태 탐색기의 상태 재계산 작업
그림 9 상태 탐색기의 상태 재계산 작업
이와 마찬가지로 상태를 정상(녹색)으로 다시 설정하는 요청이 실제로 모든 모니터에 적용될 수 있도록 기존의 상태 다시 설정 작업(RTM 버전부터 추가)도 크게 개선되었으며, 이 개선 사항은 RTM 릴리스에서 다시 설정 요청에 응답하지 않는 경우가 많던 Essentials Server 자체에 대해 다시 설정 요청을 실행하는 경우에도 적용됩니다.

스크립트를 사용한 진단
진단은 경고가 발생하면 데이터 수집 작업을 자동 또는 수동으로 실행할 수 있도록 Essentials 2007에 새로 도입된 특별한 형식의 인라인 작업입니다. 자동 진단은 모니터가 오류 상태가 될 때마다 실행되도록 구성된 것으로 진단 결과는 상태 탐색기의 상태 변경 이벤트 탭에 있는 세부 정보 창에 표시됩니다. 주문형 진단은 자동 진단과 같은 영역에 하이퍼링크로 표시되며 해당 링크를 클릭하여 간단하게 실행할 수 있습니다. 주문형 진단의 결과는 로컬 컴퓨터의 팝업 창에 표시됩니다.
그림 10에서 볼 수 있듯이 SP1에서는 명령줄 응답만 가능했던 RTM에 비해 진단 작업에 스크립트를 사용할 수 있도록 진단 기능이 확장되었습니다. 이러한 확작된 기능을 통해 오류가 발생했을 때 보다 정교하고 다양한 자동 데이터 수집 응답을 실행할 수 있습니다. 이러한 진단 작업에는 VBScript와 JScript®가 모두 지원됩니다.
그림 10 정보 표시/숨기기 링크가 있는 경고 정보 창
그림 10 정보 표시/숨기기 링크가 있는 경고 정보 창

Visio로 내보내기
SP1에 새로 추가된 다른 기능으로는 사용자가 다이어그램 보기를 선택하면 도구 모음에 나타나는 단추를 사용하여 다이어그램을 Microsoft Visio® 2007 형식으로 내보내는 기능이 있습니다. 또한 Active Directory 및 Exchange Server 2003 관리 팩에서는 세부적인 토폴로지 다이어그램을 기본적으로 제공하여 관리자가 문서를 작성하는 데 소중한 시간을 버리지 않아도 되므로 매우 편리합니다. 또한 다이어그램 레이아웃에 대한 기본 설정을 저장할 수도 있습니다. 이러한 기본 설정은 다음번에 다이어그램 보기를 선택했을 때 Essentials 콘솔에 그대로 적용됩니다.

향상된 백업 및 복구 지침
Essentials 2007 SP1을 설치한 직후 Essentials Management Server 암호화 키를 백업하라는 메시지가 설치 마법사에 자동으로 표시됩니다(그림 11 참조). Essentials Server에서는 운영 데이터베이스에서 실행 자격 증명을 안전하게 저장하기 위해 이 키 쌍을 사용합니다. 이들 키는 Essentials Server를 백업에서 복원해야 하는 경우에도 필요하며 이 키 쌍이 없으면 Essentials를 다시 설치하여 처음부터 구성해야 합니다.
그림 11 Essentials 암호화 키 백업
그림 11 Essentials 암호화 키 백업

향상된 관리 팩 품질
Essentials SP1에서 향상된 수많은 기능 이외에도 Essentials 제품 팀에서는 더욱 다양하고 엄격한 테스트 절차와 여러 제품 팀 및 응용 프로그램 관련 전문가와의 상호 작용을 통해 Essentials 플랫폼용 관리 팩의 품질을 개선하는 데 주력하고 있습니다. 이러한 노력의 결과는 자동 튜닝 임계값, 분산 응용 프로그램 모델을 사용하는 서비스 기반 모니터링과 같이 Microsoft 모니터링 플랫폼의 새로운 기능을 비롯하여 강력한 보고 엔진의 장점을 활용하는 추가적인 관리 팩의 출시에 반영될 것입니다.
Microsoft에서는 Essentials의 새로운 기능을 활용하는 더 많은 기본 관리 팩을 2008년부터 출시할 예정입니다. Essentials 2007용 관리 팩은 System Center 관리 팩 카탈로그(go.microsoft.com/fwlink/?LinkId=112399)에서 다운로드할 수 있습니다.

평가판 안내
SP1에서는 중기업의 IT 인프라를 관리하는 데 부족함이 없을 정도로 System Center Essentials 2007의 성능이 크게 향상되었습니다. 현재의 환경에서 Essentials 2007을 이미 사용하고 있는 경우에는 SP1을 다운로드하여 향상된 기능과 성능을 직접 경험해 보십시오. Essentials 2007을 아직 배포하지 않은 경우 Essentials 2007 SP1을 사용해 보려면 SP1 통합 설치 관리자 패키지를 다운로드할 수 있습니다. 이 두 패키지와 추가적인 제품 정보는 Essentials 2007 홈 페이지(microsoft.com/systemcenter/essentials)에서 확인할 수 있습니다.

<Name>Pete Zerger</Name>는 AKOS Technology Services의 컨설팅 파트너이며 IT 업계에서 9년간 일해왔습니다. Pete는 엔터프라이즈 운영 관리, 디렉터리 서비스, 메시징 솔루션 등의 설계와 배포에 주력하고 있습니다. 또한 MCSE for Messaging, MCTS for SQL Server 2005 자격증을 보유하고 있으며 Microsoft MVP for Microsoft Operations Manager 자격도 가지고 있습니다. 그는 Essentials 2007과 System Center Suite를 다루는 유명한 커뮤니티 사이트인 systemcenterforum.org의 설립자입니다.


 From the Editor: &quot;Inside SharePoint&quot; 소개의 글
From the Editor
"Inside SharePoint" 소개의 글

지난달 Editor's Note에서 말씀드렸듯이, The Cable Guy에 작별을 고한 후 이번 호 TechNet Magazine에서는 새로운 칼럼을 처음 선보이게 되었습니다. "Inside SharePoint" 칼럼은 아키텍처, 배포, 보안, 유지 관리 및 지원과 같이 SharePoint 인프라와 관련하여 IT 전문가가 알아야 할 모든 것을 다룰 예정이며 앞으로 관심 있게 지켜봐 주시기 바랍니다. 약속한 대로 Pav Cherny가 유연한 SharePoint 인프라의 핵심 요소에 대한 간략한 소개를 시작으로 매월 연재될 이 칼럼의 스타트를 끊었습니다. 다음 호에는 계속해서 SharePoint 사이트 관리에 대해 다룰 예정입니다. 저희의 귀는 항상 열려 있습니다. 이 칼럼에서 다루었으면 하는 SharePoint 주제가 있으면 tnmag@microsoft.com으로 연락해 주십시오.
이번 호에서는 Gil Kirkpatrick이 Windows Server 2008에서의 Active Dierctory 백업 및 복원 프로세스에 대한 심층적이고 포괄적인 내용을 설명합니다. 대부분의 Windows 기반 네트워크에서 Active Directory는 ID 및 액세스 정보의 신뢰할 수 있는 원본입니다. 뿐만 아니라 Active Directory는 Exchange, SharePoint, Configuration Manager 등 수많은 배포 환경의 핵심 인프라이기도 합니다. 그러나 필자가 지난달 Chicago에서 개최된 Gil의 Directory Experts Conference 세션에 참석했을 때 그가 Active Directory에 대한 포괄적인 재해 복구 계획을 보유하고 있는 사람이 얼마나 되는지 묻는 질문에 손을 든 사람은 손에 꼽을 만큼 적었습니다. 모든 사람들이 Gil의 기사를 읽어야 한다고 해도 과언이 아닐 것 같습니다.
그럴 가능성은 매우 적지만, Active Directory에 큰 관심이 없더라도 너무 걱정하지 마십시오. 이번 호에는 이 외에도 다양한 흥미로운 내용이 여러분을 기다리고 있습니다. Matt Fontaine은 조직에서 Windows Mobile 장치를 관리하는 경우 반드시 알아야 할 새 기술인 System Center Mobile Device Manager를 소개하고, Pete Zerger는 System Center Essentials SP1의 새로운 기능을 알기 쉽게 설명하며 Jesper Johansson은 IT 보안에 하이젠베르크의 불확정성 원리를 적용하여 설명합니다. 그리고 언제나 그랬듯이 Scripting Guys가 이번 호에도 함께하고, Exchange Queue & A를 비롯한 많은 내용이 포함되어 있습니다.
마지막으로 TechNet Magazine 웹 사이트를 멋지게 새단장하는 프로젝트를 진행하고 있음을 알려 드립니다. 웹 사이트 주소는 이전과 마찬가지로 technetmagazine.com입니다. 일부 인기 저자의 경우 온라인 기사와 함께 내용을 단계별로 시연할 수 있는 비디오(방법 스크린캐스트)를 개발하고 있습니다. 이러한 스크린캐스트에서 다루었으면 하는 주제나 기술이 있으면 tnmag@microsoft.com으로 전자 메일을 보내 주십시오. 감사합니다! —Joshua Hoffman


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

Windows 클러스터
Windows® Compute Cluster Server가 일반적인 Windows 클러스터와 다른 점은 무엇인가요?
—blogs.technet.com/tnmag 발췌

아주 일반적인 질문이군요. Windows Compute Cluster Server(CCS)를 주제로 이야기할 때 가용성 클러스터링(장애 조치 클러스터링)에 대한 질문을 자주 받습니다. 계산 클러스터는 시스템 간에 서비스 장애 조치를 제공하는 "가용성 클러스터"와는 다릅니다.
계산 클러스터는 작업 큐나 스케줄러를 사용하여 클러스터 내의 서로 다른 시스템에 작업을 할당합니다. 클러스터의 헤드 노드에서 실행되는 스케줄러는 작업 예약 요청을 받은 후 클러스터의 다른 계산 노드에 작업을 할당합니다. 간단하게 말해 가용성 클러스터링은 중단 없이 서비스를 제공하는 데 초점을 맞춘 것이고 CCS를 사용하면 컴퓨터 간에 작업을 분산시킬 수 있습니다.
—John Kelbley(기술 제품 수석 관리자)

Robocopy GUI
Robocopy GUI에 대한 칼럼(technetmagazine.com/issues/2006/11/UtilitySpotlight, 2006년 11월 게재)은 잘 읽었습니다. 이 칼럼 덕분에 Robocopy를 쉽게 사용할 수 있게 되었고, 탭 그룹을 통해 많은 명령줄 옵션을 보다 쉽게 이해할 수 있게 되었습니다.
—Biff M.

의견을 보내 주셔서 감사합니다. 이 도구를 유용하게 사용하고 계시다니 저희도 매우 기쁩니다. TechNet Magazine에서 다루었으면 하는 도구가 있다면 언제든지 tntools@microsoft.com으로 연락 주시기 바랍니다.

장치 드라이버
특정 장치 드라이버와 관련된 파일 목록은 어떻게 확인하나요?
—T.P.

특정 드라이버 설치를 지원하는 다양한 파일 목록을 확인하려는 경우에는 아쉽지만 완벽한 해결 방법은 없습니다. 최선의 방법은 해당 드라이버에 포함된 INF 파일을 확인하는 것입니다. 이때 *.copyfiles라고 표시된 섹션이 해당 드라이버의 PnPID(플러그 앤 플레이 ID)와 관련된 섹션이므로 이 섹션을 확인하십시오. 이 섹션에는 드라이버 설치 시 복사된 파일 목록이 나열됩니다.
그러나 "보조 설치 관리자"를 드라이버의 일부로 호출하는 일부 드라이버의 경우 보조 설치 관리자 중 하나가 실제로 다른 파일을 압축 해제하거나 설치할 수 있기 때문에 이 목록을 확인하는 것이 조금 어렵습니다. 하지만 INF 파일의 내용을 주의해서 읽고 이해할 수만 있으면 일반적으로 CopyFiles 섹션을 구문 분석하여 대부분의 파일을 확인할 수 있습니다.
—Wes Miller(The Desktop Files 칼럼니스트)

Windows 인증
Windows 인증에 대한 정보를 제공하는 기사나 백서를 찾고 있습니다. 특히 Windows 2000 Active Directory® 도메인에서의 IAS(인터넷 인증 서비스) 무선 사용에 대해 자세히 알고 싶습니다. 이에 대한 정보가 포함된 기사를 추천해 주십시오.
—Brett M.

이 주제에 대해서는 TechNet의 IAS TechCenter(technet.microsoft.com/network/bb643123)에서 관련 콘텐츠를 찾아보는 게 가장 좋을 것 같습니다. 여기에는 IAS를 사용한 인증과 관련된 여러 개의 기사 및 백서를 볼 수 있는 링크가 포함되어 있습니다.
Windows 2000 Server Security Newsgroup(microsoft.com/technet/community/newsgroups/dgbrowser/en-us/default.mspx?dg=microsoft.public.win2000.security)이라는 온라인 포럼에 이러한 질문을 게시해 보는 것도 좋은 방법입니다.

감사의 글
2007년 12월호의 "기본 컴퓨터 범죄 조사 가이드" 기사(technetmagazine.com/issues/2007/12/Forensics)를 매우 흥미있게 읽었습니다. 먼저, 이와 같은 중요한 정보를 게시해 주신 데 대해 감사합니다. 또한 보안 분야에서의 개인적인 풍부한 경험을 이 기사에 십분 활용한 공동 저자 Tom Cloward(Microsoft의 프로그램 관리자)에게도 감사의 뜻을 전합니다. 마지막으로 Microsoft의 기술 프로그램 관리자이자 보안 관련 전문가인 공동 저자 Frank Simorjay에게도 감사의 뜻을 전하고 싶습니다. 이분들은 보안 분야에서 얻은 자신들의 풍부한 지식을 독자들과 공유함으로써 인터넷 보안 공격으로 인해 발생하는 문제를 해결하는 데 큰 도움을 주셨기에 칭찬의 글을 전합니다. 고맙습니다.
—S님

S님의 글에 감사 드립니다. 저희 역시 보안 관련 문제의 중요성을 지적해 주신 고객님의 의견에 동의하는 바입니다. 향후 TechNet Magazine에 이 주제와 관련된 칼럼이 더 많이 게재될 예정이므로 앞으로도 기대해 주시기 바랍니다. 다시 한번 감사 드립니다.


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

디스크 공간 분석
FolderSizes
foldersizes.com
클라이언트 컴퓨터 공간을 차지하고 있는 것이 무엇인지 어떻게 알 수 있습니까? 컴퓨터의 용량이 거의 찼을 때 이를 알려 주는 디스크 공간 모니터를 이미 사용하고 있을 수 있지만 여유 공간을 다시 이상적인 비율로 만들기 위해 디스크를 정리하는 것은 그리 만만한 작업이 아닙니다. Key Metric Software의 FolderSizes는 컴퓨터 공간을 차지하고 있는 것이 무엇인지 파악할 수 있게 도와주는 유틸리티입니다.
이 응용 프로그램은 사용 방법이 아주 쉽지만 응용 프로그램을 처음 실행하면 작업을 시작하는 데 도움이 되도록 응용 프로그램 UI에 대해 간략한 설명이 표시됩니다. 드라이브나 폴더를 분석하려면 계층적 폴더 브라우저 창에서 해당 항목을 두 번 클릭하기만 하면 됩니다. FolderSizes에서 대상 검색이 완료되면 디스크 사용 상태에 대한 그래프와 각 부모 폴더의 콘텐츠가 차지하고 있는 공간을 보여 주는 폴더 보기가 표시됩니다. 그리고 마우스를 한 번 클릭하면 파이 차트와 막대 차트 간에 폴더 정보를 빠르게 변경하여 공간이 사용되고 있는 위치를 제어할 수 있습니다. 개인적인 경험에 따르면 형제 디렉터리가 많은 경우에는 막대형 차트가 더 유용합니다.
막대, 파이 조각 또는 폴더를 두 번 클릭하면 하위 폴더로 드릴다운됩니다. 이와 같은 탐색 방법을 사용하면 사용자가 "영업 프레젠테이션"이라고 이름을 지정한 "숨겨진" mp3 디렉터리와 같이 문제가 될 수 있는 항목으로 쉽고 빠르게 이동할 수 있습니다. 또는 모든 것을 문서화하여 컴퓨터에 보관하기 좋아하는 사용자가 있다면 마지막 수정 날짜를 기준으로 정렬하여 오랫동안 액세스하지 않은 파일을 확인할 수도 있습니다. 이렇게 결과를 가시적으로 보여 주면 파일을 CD에 보관하거나 영구적으로 삭제해도 큰 문제가 없다고 사용자를 설득할 수 있을 것입니다.
FolderSizes의 또 다른 뛰어난 기능은 차트에 표시되는 계층의 수준을 사용자 지정할 수 있다는 것입니다. 예를 들어 드라이브에 있는 모든 폴더의 차트를 가장 큰 폴더부터 가장 작은 폴더순으로 정렬하여 문제가 되는 항목을 구분할 수 있습니다. 문제가 되는 항목을 확인한 후에는 마우스 오른쪽 단추를 클릭하여 "command prompt from here(이 위치에서 명령 프롬프트 열기)" 및 "explore this folder(이 폴더 탐색)" 같은 작업을 수행할 수 있습니다. 이렇게 하면 필요한 다른 유틸리티나 검사를 실행할 수 있습니다.
FolderSizes에는 대상 파일 시스템의 콘텐츠에 대한 다양한 보기를 제공하는 Report Generator도 기본적으로 포함되어 있습니다. 예를 들어 시스템에서 특정 형식의 가장 큰 파일이나 가장 오래된 파일, 임시 파일이나 중복 파일, 모든 읽기 전용 파일, 파일 서버에서 특정 소유자의 파일 등을 찾을 수 있습니다. 이 외에도 Report Generator로 할 수 있는 작업은 많습니다. 그리고 보고서를 생성한 후에는 보기를 필터링하거나, 인쇄하거나 심지어 XML, HTML 또는 CSV 형식으로 내보낼 수도 있습니다.
앞서 설명한 기능 외에도 FolderSizes를 사용하면 실제로 보관할 가치가 있는 파일만 선택하여 간단하게 백업할 수 있습니다. 또한 응용 프로그램의 명령줄 인터페이스를 사용하여 클라이언트 또는 서버 시스템에 대한 검사를 스크립팅하고 자동화할 수도 있습니다. 서버나 클라이언트 컴퓨터에서 불필요하게 디스크 공간을 차지하고 있는 항목을 빠르게 알아내는 방법을 찾고 있다면 FolderSizes를 사용해 보십시오.
가격: 단일 사용자 라이선스의 경우 50달러부터입니다.
FolderSizes는 시스템 폴더를 차트 형식으로 보여 줌
FolderSizes는 시스템 폴더를 차트 형식으로 보여 줌

사용자 계정 관리
Inactive Users Tracker
netwrix.com/inactive_users_tracker_freeware.html
조직의 규모가 클수록 비활성 사용자 계정을 효과적으로 관리하기란 쉽지 않습니다. 이러한 비활성 사용자 계정을 쉽게 추적하고 해제 또는 제거하는 프로세스를 구축하여 잠재적인 보안 취약점을 미연에 제거하는 것이 보안 측면에서 바람직합니다. NetWrix Corporation에서 제공하는 프리웨어인 Inactive Users Tracker를 사용하면 이러한 작업을 간편하게 수행할 수 있습니다.
이 도구는 사용자의 Active Directory® 도메인을 정기적으로 검색하여 비활성 사용자를 찾은 후 사용자가 지정한 관리 전자 메일 주소로 비활성 계정 목록을 보냅니다. 사용자는 관리할 대상 도메인을 지정할 수 있을 뿐만 아니라 Active Directory에서 비활성 계정을 검색할 수 있는 권한을 부여할 계정도 지정할 수 있습니다. 또한 특정 계정에 비활성 "레이블"을 표시하고 이 계정을 전자 메일 알림에 포함하기 위해 계정이 비활성 상태로 경과해야 하는 일수를 지정할 수 있으며 프로세스의 시작 일정도 지정할 수 있습니다.
이러한 기능 외에도 알림 전자 메일을 관리자의 전자 메일 주소로 릴레이하도록 SMTP 서버를 구성하고, 이 유틸리티에서 이름 필터(예: 모든 컨설턴트 계정을 "c_"로 시작)를 사용하여 비활성 사용자 계정을 필터링할지 여부도 지정할 수 있습니다.
이 도구는 판매용 버전도 있으며 가격은 제품을 구입하는 고객에 따라 조정됩니다. 판매용 버전을 사용하면 사용자에게 보낸 전자 메일 메시지를 사용자 지정하고 비활성 사용자 계정을 자동으로 해제할 수 있으며, 기술 지원도 이용할 수 있습니다.
가격: 무료
Inactive Users Tracker에서는 비활성 사용자를 알려 줌
Inactive Users Tracker에서는 비활성 사용자를 알려 줌

전자 메일 통신 개선
Exclaimer Mail Utilities 2007
exclaimer.com/MailUtilities2007.aspx
소송 사건과 규제가 점점 더 많아지는 오늘날의 환경에서 전자 메일 통신을 보호하는 일은 기업의 가장 중요한 업무 중 하나가 되었습니다. 그러나 이와 동시에 일관된 의사 소통과 상표화는 기업이 다양한 통신 대상과 더 나은 유대 관계를 형성하는 수단이 되기도 합니다. Exchange Server 2007 배포 환경에서 작동하도록 설계된 Exclaimer Mail Utilities 2007은 이 두 가지 측면 모두에서 유용합니다.
이 응용 프로그램에는 기업의 전자 메일 통신을 통합하고 보호하는 것을 돕기 위해 법적 고지 사항, 상표화 및 서명이라는 세 가지 기본적인 기능이 포함되어 있습니다. 필요한 경우 스팸 및 바이러스 방지 모듈도 추가할 수 있습니다.
법적 고지 사항 측면에서 살펴보면 Exclaimer Mail Utilities 사용하면 기업에서 보내는 모든 메시지의 전자 메일 텍스트 앞이나 뒤에 사용자 지정 메시지를 추가함으로써 소송의 가능성을 줄이고 HIPAA(Health Insurance Portability and Accountability Act) 및 Circular 230과 같은 규정을 보다 확실하게 준수할 수 있습니다. 상표화 측면에서 살펴보면 보내는 모든 메시지에 이미지 및 상표 태그를 쉽게 추가하여 고객층과 통신하는 데 있어서 일관된 느낌을 줄 수 있습니다. 마지막으로 서명의 경우에는 스마트 장치, Microsoft® Outlook® Web Access, 표준 Outlook 클라이언트 등 메시지를 보내는 프로그램에 관계없이 모든 메시지에 자동 서명을 적용할 수 있습니다. 서명은 Active Directory 트리에 이미 저장되어 있는 데이터를 사용하여 동적으로 생성되며, 해당 도구를 구성하면 전자 메일을 받을 사람의 유형(내부 사용자 또는 외부 사용자), 보내는 사람, 받는 사람, 메시지 제목 등과 같은 여러 가지 요소를 기초로 서명을 사용자 지정할 수 있습니다.
Exclaimer Mail Utilities 2007의 가격은 사용자 수에 따라 다르게 책정됩니다. 사용자 25명을 기준으로 가격은 245달러부터이며, 사용자 수가 많을수록 할인액이 커집니다. 스팸 방지 모듈, 바이러스 방지 모듈 및 기술 지원 비용은 별도입니다. 기술 지원은 처음 1년 동안 의무적으로 사용해야 하며 사용자 25명을 기준으로 55달러부터입니다. 성능상의 이유로 Mail Utilities를 실행하려면 64비트 Windows Server® 2003 또는 Windows Server 2008을 실행하는 컴퓨터를 사용해야 합니다. 이 제품을 구입할 의향이 있지만 아직 Exchange Server 2003을 사용하고 있는 경우에는 이 제품의 다른 버전을 사용할 수 있습니다.
가격: 사용자 25명을 기준으로 245달러부터입니다.

서평
How to Cheat at Securing SQL Server 2005
syngress.com
IT 전문가라면 누구나 인프라를 구현할 때 보안을 가장 우선적으로 고려해야 한다는 것을 알고 있을 것입니다. 오늘날 각양각색의 환경이 서로 얼마나 밀접하게 연결되어 있고 시스템에 중요한 정보가 얼마나 많이 저장되어 있는지 생각해 보십시오. 이러한 중요한 정보를 한곳에 모아 둔 SQL Server® 인스턴스의 경우에는 보안이 특히 중요합니다. 또한 Sarbanes-Oxley 및 HIPAA와 같이 사용자의 개인 정보를 보호하는 다양한 규정이 있기 때문에, 문제가 생겨 이 데이터가 노출될 경우에는 법적 또는 재정적으로 골치 아픈 상황이 발생할 수 있습니다.
How to Cheat at Securing SQL Server 2005는 SQL Server 2005 인스턴스의 보안을 유지하려는 경우에 유용하게 참조할 수 있습니다. 제목에 오해의 소지가 있기는 하지만, 이 책에서는 "규칙에 위반되는 방법"을 제공하는 것이 아니라 SQL Server 2005 배포를 안전하게 수행하는 단계별 지침을 제공합니다. 이 책에서는 비즈니스 요구 사항을 충족하는 데 필요한 만큼의 기능만 허용하고 나머지는 허용하지 않는 "액세스 최소화"라는 기본 원리를 준수합니다.
또한 이 책에서는 간단한 소개에 이어 노출 영역 구성 도구를 사용하여 SQL Server 2005 인스턴스의 노출 영역을 줄이는 방법을 설명합니다. 그리고 SQL Server 2005를 설치할 때 사용할 수 있는 기본적인 서비스와 각 서비스의 기본 시작 옵션(수동, 자동 또는 사용 안 함)과 같은 유용한 정보를 얻을 수 있습니다. 다음 장에서는 SQL Server 역할 및 역할을 통해 관리 작업을 간소화하는 방법에 대해 알아봅니다. 예를 들어 이 책에서는 Windows® 그룹에 역할을 연결하는 방법을 보여 줍니다. 이렇게 하면 그룹에 새 사용자를 추가할 경우 해당 역할이 사용할 수 있는 리소스에 대한 액세스 권한이 새 사용자에게 자동으로 부여됩니다.
인증 및 세분화된 액세스에 대한 장에서는 Windows 및 SQL Server 로그인과 각 로그인의 장단점에 대해 설명합니다. 이 장에서는 인증과 관련된 Microsoft의 모범 사례에 대해서도 살펴봅니다. 그 다음에는 권한 부여에 대해 알아보고, 사용자가 인스턴스에 대해 수행할 수 있는 작업, 즉 데이터베이스 측면에서 보안 개체에 대해 부여되는 권한을 세부 조정하는 옵션에 대해 설명합니다. 여기서는 쿼리 또는 프로세스에서 리소스를 모두 사용하여 서버에서 응답할 수 없는 경우 인스턴스에 액세스할 수 있도록 로컬 방식의 관리자 전용 연결을 제공하는 DAC(관리자 전용 연결)와 같은 내용에 대해 알아봅니다. DAC는 SQL Server 2005 이전 버전에는 없는 유용한 기능입니다.
SQL Server 2005에서는 스키마와 사용자가 별개의 엔터티로 구분됩니다. 이 책에는 T-SQL 및 SQL Server Management Studio를 통해 스키마를 정의, 업데이트 및 삭제하는 방법을 설명하는 장이 포함되어 있습니다. 이 섹션에서는 SQL Server 2005에서 새 스키마를 만드는 경우가 아니면 새 사용자를 만들 때 sp_adduser 저장 프로시저를 사용하지 않아야 한다는 것을 비롯하여 몇 가지 유용한 팁을 얻을 수 있습니다. 이 경우에는 sp_adduser 대신 CREATE USER T-SQL 문을 사용하여 사용자를 만들어야 합니다.
설치 과정에서 보안을 유지하는 데 있어서는 암호도 매우 중요합니다. 따라서 다음 장에서는 계정 간에 동일한 수준의 보안을 유지할 수 있도록 암호 정책에 대해 자세히 설명합니다. 이 장에서 필자는 사용자가 현재의 환경에 가장 적합한 정책과 정책 유형을 선택할 수 있도록 여러 가지 구현 시나리오를 제시합니다. 그리고 DDL(데이터 정의 언어) 트리거 및 DDL 트리거를 사용하여 자동 구조 변경을 방지하고 서버 로그인 변경에 대한 감사 추적을 제공하는 방법에 대해 알아봅니다.
다음 장에서는 SQL Server 2005에서 데이터와 스키마를 암호화하여 중요한 정보를 보호하는 여러 가지 방법에 대해 살펴봅니다. 마지막으로 이 책에서는 보안 관련 모범 사례에 대한 지침을 비롯하여 SQL Reporting Services, SQL Analysis Services 및 SQL Server Integration Services(SSIS)에 대해 간략하게 설명합니다. SQL Server 2005와 관련하여 그룹 정책 및 Active Directory의 구현 및 보안에 대한 정보를 제공하는 두 개의 부록도 매우 유용합니다.
이 책 전반에는 특히 유용한 두 가지 구성이 사용되었습니다. 그 중 하나는 각 장에서 다룬 요소의 기능, 요점 및 모범 사례가 글머리 기호 형식으로 나열되는 "Solutions Fast Track" 섹션입니다. 또 다른 하나는 SQL Server 2005 인스턴스의 관리에 대한 질문과 대답을 다룬 "Frequently Asked Questions" 섹션입니다. 보안 측면에서 SQL Server 2005 관리 작업을 빠른 시간 안에 살펴보려면 How to Cheat at Securing SQL Server 2005를 읽어보십시오.
가격: 전자책은 19.98달러이고 일반 책은 49.95달러입니다.

강력한 화면 캡처
ScreenHunter 5 Pro
wisdom-soft.com/products/screenhunter_pro.htm
화면 캡처는 단계별 사용자 지침을 문서화하거나, 응용 프로그램에서 발생하는 오류 메시지를 보여 주거나, 간단한 기능 프레젠테이션을 만들 때 매우 유용합니다. 물론 Windows에도 화면 캡처 기능이 기본적으로 포함되어 있습니다. PrtScr 키를 누르면 전체 화면을 캡처할 수 있고 Alt+PrtScr를 누르면 활성 창만 캡처할 수 있습니다. 그러나 운영 체제에 포함되어 있는 기능은 제한적입니다. 캡처할 대상과 시점을 보다 세부적으로 제어하거나 재생 중인 동영상에서 화면을 캡처하려면 수많은 타사 화면 캡처 유틸리티 중 하나를 선택해야 합니다. Wisdom Software의 ScreenHunter Pro도 이러한 도구 중 하나입니다. 가격이 저렴한 이 유틸리티에는 필요에 맞게 화면 캡처를 조정할 수 있는 몇 가지 유용한 기능이 들어 있습니다.
UI는 간단합니다. From 및 To 탭에서 화면 캡처를 가져올 원본 및 캡처를 저장할 대상 위치를 각각 선택하기만 하면 됩니다. 이 응용 프로그램에서는 조정 가능하거나 고정된 사각형 영역, 특정 개체나 창, 활성 창, 활성 창의 특정 부분, 화면 전체, DirectX® 또는 화면 보호기 원본, 동영상 재생 또는 더 복잡한 모양(사용자가 정의하는 자유형, 타원 또는 다각형 영역)을 캡처할 수 있습니다. 또한 창 개체나 메시지 상자 여러 개를 한 번에 캡처할 수도 있습니다. 이 기능은 활성 응용 프로그램과 해당 대화 상자 또는 기타 창 인터페이스만 선택적으로 캡처할 경우에 유용합니다. 대상을 캡처한 후에는 화면 캡처를 클립보드, 지정된 뷰어나 편집기, 프린터 또는 파일에 수집할 수 있습니다. 또한 화면 캡처를 전자 메일 주소로 보낼 수도 있습니다.
캡처한 이미지는 다양한 품질의 BMP, PNG, JPEG 또는 TIFF 파일로 저장할 수 있습니다. 뿐만 아니라 응용 프로그램에서 캡처한 항목을 특정 크기로 자동 조정하거나, 테두리를 추가하거나, 캡처에 워터마크를 추가하여 이미지에 필요한 "제작 후" 작업량을 줄일 수 있습니다. 화면을 지정한 간격으로 자동 캡처하여 컴퓨터에서 실행되는 작업을 기록할 수 있도록 응용 프로그램을 설정할 수도 있습니다.
ScreenHunter Pro의 유용한 기능 중 하나는 자동 스크롤 기능입니다. 이 기능을 사용하면 화면에서 한 번에 볼 수 없는 긴 웹 페이지를 캡처할 수 있습니다. 대부분의 IT 전문가와 마찬가지로 필자도 모니터를 여러 대 사용하고 있기 때문에 한 번의 캡처 작업으로 여러 화면의 정보를 모두 캡처할 수 있는 다중 모니터 캡처 기능을 매우 유용하게 사용하고 있습니다.
이 유틸리티에는 이미지 편집기도 기본 제공되기 때문에 동일한 응용 프로그램 환경에서 이미지를 편집할 수 있습니다. 자동 전자 메일, 캡처 예약, 워터마크 및 다중 모니터 캡처와 같은 고급 기능이 필요하지 않은 경우에는 좀 더 저렴한 ScreenHunter Plus 버전을 사용해 보십시오. 축소된 기본 버전은 무료로 사용할 수 있습니다.
가격: ScreenHunter Pro: 29.95달러
ScreenHunter Pro를 사용하면 캡처 시간 및 캡처 항목을 지정할 수 있음
ScreenHunter Pro를 사용하면 캡처 시간 및 캡처 항목을 지정할 수 있음

Greg Steen


 Exchange Queue &amp; A: Exchange 2007 SPI 배포
Exchange Queue & A
Exchange 2007 SPI 배포

Q: Exchange Server 2007 SP1은 64비트 버전으로만 제공됩니까? 만약 32비트 버전도 제공된다면 프로덕션 환경에서 이 버전을 사용할 수 있나요?
A: 이와 관련해서 Exchange 2007의 원래 버전(RTM)과 SP1 버전에는 다른 점이 없습니다. SP1은 32비트와 64비트로 모두 제공됩니다. 그러나 RTM 버전과 마찬가지로 프로덕션 환경에서는 설치된 서버 역할에 대해 64비트만 지원된다는 점을 기억하십시오. 단, RTM 버전에서와 마찬가지로 다양한 /prepare 설치 스위치를 실행하고 64비트 서버를 관리하려는 경우에는 32비트 SP1 버전을 사용할 수 있습니다.

Q: SP1 서버를 사용하려면 Exchange 2007 RTM 버전의 전체 설치를 먼저 완료한 다음 SP1을 적용해야 합니까?
A: 이것이 바로 Exchange 2007 SP1이 이전 버전의 Exchange 서비스 팩과 다른 점입니다. SP1은 실제로는 SP1이 통합되어 있는 RTM이기 때문에 Exchange 2007 SP1을 새로 설치할 때 RTM DVD를 사용할 필요가 없습니다.
따라서 Exchange 2007 SP1 서버를 새로 설치할 경우 SP1만 있으면 됩니다. 예를 들어 Exchange Server 2003 조직에 처음으로 Exchange 2007을 도입하는 경우에도 SP1만으로 곧바로 시작할 수 있습니다.
Q: 현재 Windows Server® 2003에서 Exchange 2007 RTM을 실행하는 서버가 있으며 이 컴퓨터에 Exchange 2007 SP1을 설치하려고 합니다. Microsoft에서 Exchange 2007 SP1은 Windows Server 2008에서만 지원된다고 하여 나중에 Windows Server 2008로 사용 중 업그레이드를 수행하려고 하는데 이렇게 해도 되겠습니까?
A: 유감스럽게도 그와 같은 방법은 사용할 수 없습니다. Exchange 2007 RTM 또는 SP1이 설치되어 있는 상태에서는 Windows Server 2003에서 Windows Server 2008로의 사용 중 업그레이드가 지원되지 않습니다. 이 기능은 여러 가지 기술적인 이유로 지원되지 않으며 이와 같은 사용 중 업그레이드를 수행할 경우 설치되어 있는 Exchange이 손상됩니다.
자세한 내용은 "미션 임파서블: Windows Server 2003에서 Windows Server 2008로의 Microsoft® Exchange Server 2007 사용 중 업그레이드"(msexchangeteam.com/archive/2007/10/04/447188.aspx)를 참조하십시오.

Q: 현재 사용하고 있는 테스트 서버 일부에는 제품 ID를 입력하지 않았는데 그래서인지 Exchange 관리 콘솔을 시작하면 만료일까지 "0일" 남았다는 팝업 경고가 표시됩니다. 이러한 서버에 제품 키를 입력하지 않도고 Exchange 2007 SP1로 업그레이드할 수 있나요?
A: 예. Exchange 2007 SP1 설치 프로그램에서는 이미 설치되어 있는 서버의 평가판 사용 기간을 확인할 수 없습니다(스크린샷 참조). 따라서 이 경우에는 문제 없이 업그레이드할 수 있습니다.

Q: 사서함 서버에 Exchange 2007 SP1을 이미 설치했고 이제 이 서버에 클라이언트 액세스 서버 역할을 추가하려고 하는데 Exchange 2007 RTM과 새로운 Exchange 2007 SP1 중 어느 것을 사용해야 하나요?
A: Exchange 2007 SP1이 이미 적용되어 있는 상태이기 때문에 서버 역할을 추가로 설치하려면 Exchange 2007 SP1을 사용해야 합니다. 앞에서 언급했듯이 Exchange 2007 SP1은 Exchange 2007을 실행하는 데 필요한 모든 파일이 포함되어 있는 완전한 제품이기 때문에 SP1이 성공적으로 설치된 경우에는 Exchange 2007 RTM이 필요하지 않습니다.
Exchange 2007 SP1로 업그레이드하는 서버에 서버 역할이 여러 개 있는 경우, SP1을 적용하면 이미 설치되어 있는 역할 모두가 자동으로 업그레이드됩니다. 따라서 서버에 있는 역할 중 일부에만 SP1을 적용할 수는 없습니다.

Q: 현재 Exchange 조직에 Exchange 2007 서버가 여러 대 있고 이러한 서버 몇몇에 서버 역할이 분산되어 있는데 어느 서버 역할부터 업그레이드해야 합니까?
A: 먼저 Exchange 2007 SP1 릴리스 정보(go.microsoft.com/fwlink/?LinkId=112364)부터 다운로드하여 읽어보십시오. 릴리스 정보에는 기존 설치 환경에 SP1을 적용하는 것과 관련된 중요한 내용이 들어 있습니다.
이 질문과 관련해서는 SP1 릴리스 정보에서 발췌한 다음 내용이 정확한 답변이 될 것입니다.

"클라이언트 액세스, 통합 메시징, 허브 전송 서버 역할 또는 Edge 전송 서버 역할을 실행하는 서버를 업그레이드한 후에 사서함 서버 역할을 실행하는 서버를 업그레이드하는 것이 좋습니다. 이 순서로 서버를 업그레이드하면 서비스가 중단되지 않습니다. (이 순서로 역할을 업그레이드하면 기능이 더 많은 백엔드 서버와의 통신을 시도할 때 문제를 겪지 않고 사서함 역할을 "담당"하는 서버가 중단 없이 사서함 서버와 통신할 수 있습니다.) 인터넷에 연결되지 않는 사이트에 있는 클라이언트 액세스 서버를 업그레이드하기 전에 인터넷 연결 사이트에 있는 클라이언트 액세스 서버를 업그레이드하는 것이 좋습니다.
Exchange 조직에서 Edge 전송 서버 역할을 실행하는 경우 Edge 구독을 만들었다면 EdgeSync 프로세스에 참가하는 모든 전송 서버에서 동일한 버전의 Exchange 2007을 실행해야 합니다. 또한 Edge 구독 프로세스에 참가하는 모든 전송 서버를 처음으로 Exchange 2007 SP1로 업그레이드한지 15일 이내에 Edge 전송 서버가 가입된 Active Directory® 사이트의 모든 허브 전송 서버 및 가입된 모든 Edge 전송 서버를 업그레이드해야 합니다."

Q: Exchange 2007 RTM 서버에 ForefrontTM Security for Exchange Server가 설치되어 있는데 Exchange 2007 SP1로 업그레이드하기 전에 수행해야 할 특별한 작업이 있습니까?
A: Forefront Security for Exchange Server RTM 버전은 Exchange 2007 SP1과 호환되지 않습니다. 따라서 업그레이드하려면 Forefront Security for Exchange Server를 제거하거나 이후 버전으로 업그레이드해야 합니다. 자세한 내용은 SP1 릴리스 정보에 나와 있습니다.
참고로 Exchange 2007 SP1 설치 프로그램에는 질문과 같은 상황에서 업그레이드를 시도할 경우 경고 메시지를 표시하는 선행 조건 검사가 새롭게 추가되었습니다.

Q: RTM 이후 출시된 RU(롤업 업데이트)가 설치된 Exchange 2007 RTM을 사용하고 있는데 Exchange 2007 SP1을 적용하려면 RU를 먼저 제거해야 합니까?
A: Exchange 2007 SP1을 설치하기 전에 롤업 업데이트를 수동으로 제거할 필요는 없습니다. 컴퓨터에 SP1을 적용하기 전에 제거해야 할 업데이트가 있는 경우 Exchange 2007 SP1 설치 프로그램에서 자동으로 처리합니다.

Nino Bilic은 Exchange Server 팀의 지원 기능 프로그램 관리자로, Mass Effect라는 가상 세계에서 은하계를 탐사하고 악당들을 물리치면서 엄청난 부를 축적하고 있습니다.


 Utility Spotlight: SharePoint 용량 계획
Utility Spotlight
SharePoint 용량 계획
and

Microsoft® Windows® SharePoint® Services(WSS) 및 Microsoft Office SharePoint Server(MOSS)의 대규모 설치를 계획하는 것은 매우 복잡한 작업입니다. 가장 경제적인 토폴로지, 하드웨어 및 대역폭 요구 사항을 결정할 때는 매우 많은 요소를 고려해야 하며 시스템을 사용하는 방식에 따라 고려할 구성 옵션도 상당히 많습니다. 그러나 관리자와 기획자는 주로 자신들의 경험을 토대로 시스템의 규모를 가늠하는 것 외에는 달리 방법이 없습니다.
다행히 Microsoft에서는 Microsoft System Center Capacity Planner(SCCP) 2007의 후속 버전을 출시했습니다. 이 도구는 다양한 응용 프로그램 모델 및 이러한 응용 프로그램이 특정 배포 환경에서 동작하는 방식을 예측할 수 있는 시뮬레이터가 결합된 일반적인 용도의 도구입니다. 이번 릴리스에서는 이러한 엔진에 WSS 3.0 및 MOSS 2007 모델을 결합한 SharePoint Capacity Planning Tool이 새로 추가되었습니다.
SharePoint Capacity Planning Tool과 SCCP 2007은 Microsoft 다운로드 센터(microsoft.com/systemcenter/sccp/default.mspx)에서 무료로 사용할 수 있습니다.
SharePoint Capacity Planning Tool은 용도 및 운영 환경과 관련된 질문에 대한 사용자의 응답을 컴파일하여 조직의 요구 사항을 수집합니다. 사용자 수와 유형(인증된 사용자 및 익명 사용자), 네트워크 매개 변수, 하드웨어 구성, 사용 패턴(예: 게시 또는 공동 작업), 저장소 요구 사항, 인덱싱/쿼리 요구 사항 등을 포함하여 현재의 구조 및 예상되는 SharePoint 요구 사항과 관련된 정보를 묻는 마법사를 통해 1차 설계가 생성됩니다.
SharePoint Capacity Planning Tool의 시뮬레이션 결과
SharePoint Capacity Planning Tool의 시뮬레이션 결과
그런 다음 현재 설정에 사용되고 있는 이름을 사용하여 권장되는 기본 토폴로지가 생성됩니다. 제시된 토폴로지를 대상으로 부하 및 사용 시뮬레이션을 실행하여 제안된 설치가 다양한 조건에서 어떻게 작동할지 확인해 볼 수 있습니다.
모델 편집기를 사용하여 초기 토폴로지를 수정한 다음 가상 시나리오를 실행하여 사용량 증가, 기업의 지사 확장, 추가적인 하드웨어 및 대역폭 증가의 영향을 시뮬레이트할 수 있습니다. 스크린샷에서 볼 수 있듯이 시뮬레이션을 실행하면 예상되는 서버 부하와 사용자 환경 보고서가 생성되어 비용, 성능, 사용 가능한 하드웨어 등의 매개 변수를 기초로 구성을 최적화하는 작업을 시작할 수 있습니다. 세부적인 보고서나 요약 보고서는 Excel® 스프레드시트로 내보내고 토폴로지 다이어그램은 Visio® 파일로 내보낼 수 있습니다.
SharePoint Capacity Planning Tool을 사용하면 다양한 환경을 테스트하여 이상적인 초기 구성을 찾을 수 있으므로 새로운 배포에 대한 부담이 훨씬 줄어듭니다. 뿐만 아니라 기존 토폴로지를 모델링하고 다양한 가상 시나리오를 실행해 볼 수 있기 때문에 이 도구는 기존 배포에 적용할 수 있는 변경 사항을 알아보는 데도 유용합니다.

<Name>Peter Skjøtt Larsen</Name>은 Microsoft Solution Accelerator 팀의 수석 제품 관리자로, 지난 4년 동안 Microsoft에서 UNIX 마이그레이션, 통신 및 공동 작업 등의 업무를 담당해 왔습니다.
<Name>Satish Mathew</Name>는 Microsoft Solution Accelerator 팀의 프로그램 관리자로, Microsoft에서 거의 5년간 근무했으며 현재 팀에 합류하기 전에는 Windows PowerShell 팀에 소속되어 있었습니다.


 Inside Sharepoint: SharePoint 인프라 구축
Inside Sharepoint
SharePoint 인프라 구축
Pav Cherny
이 기사의 코드 다운로드: SharePoint2008_05.exe (412KB)

전자 메일 메시징이 비즈니스 커뮤니케이션에 변화를 준 것처럼 웹 기반 공동 작업은 사람들이 함께 작업하고 정보를 공유하는 방식을 변화시키고 있습니다. 이러한 변화에 대한 좋은 예로, SharePoint 기술이 제공하는 기능에 대해 살펴보겠습니다. Microsoft WSS(Windows SharePoint Services) 3.0 및 MOSS(Microsoft Office SharePoint Server)
2007을 사용하면 2007 Microsoft® Office 시스템 통합, XML 기반 양식, 워크플로, 모바일 지원 등은 물론 팀 사이트, 포털, 웹 콘텐츠 관리 솔루션, 문서 라이브러리 및 검색 센터를 만들 수 있습니다.
하지만 SharePoint®를 시작하는 것이 항상 간단하지는 않습니다. 용어가 혼동스러울 수 있으며 시스템 아키텍처가 복잡할 수 있습니다. 또한 SharePoint를 사용하려면 IIS, Microsoft .NET Framework 및 SQL Server®뿐만 아니라 Business Intelligence, InfoPath® Forms Services, RMS(Rights Management Services), Exchange Server, ForefrontTM Security 등과 같은 다양한 기술을 포함한 여러 구성 요소를 다루어야 합니다.
기본 제공 사용자 인터페이스 또는 프로그래밍 방식과 같이 SharePoint 솔루션을 만들기 위해 사용할 수 있는 접근 방법이 여러 개 제공되기 때문에 통합 및 사용자 지정 작업에 어려움을 겪을 수 있습니다. 또한 SharePoint 응용 프로그램이 작동하지 않는 경우 문제 해결이 복잡할 수 있습니다. 응용 프로그램 개발자의 관점에서 관련 구성 요소 및 이들 구성 요소의 상호 작용 방식을 이해해야 하는 경우도 많습니다. 이러한 어려움을 모두 고려했을 때 강력하며 확장 가능하고 관리가 쉬운 SharePoint 인프라를 구축하려면 어디서부터 시작해야 할까요?
이 칼럼에서는 먼저 아키텍처 개요에 대한 설명을 통해 기초를 마련한 다음 매우 기본적인 브랜딩 사용자 지정을 포함한 WSS 배포를 살펴봄으로써 SharePoint 인프라 구축을 시작하는 방법을 설명합니다. WSS 3.0의 셀프 서비스 사이트 관리 기능을 사용하여 SharePoint 인프라에 대한 중앙 집중식 관리 제어를 유지하면서 SharePoint 사이트를 만들고 관리하는 권한을 개별 사용자에게 위임하는 방법을 알아봅니다.
먼저 SharePoint 아키텍처를 이해하면 유연성 있고 확장 가능한 인프라를 구현하는 데 필요한 배포 및 구성 단계를 더 쉽게 이해할 수 있습니다. 따라서 종속성에 대해 잠깐 살펴본 다음 WSS 3.0의 배포를 설명하겠습니다. 자세한 배포 지침에 대해서는 첨부 자료를 참조하십시오. 이 자료는 TechNet Magazine 웹 사이트(technetmagazine.com)의 다운로드 섹션에서 구할 수 있습니다.

SharePoint 아키텍처
SharePoint를 사용할 때 시스템 설계자의 관점에서 해당 기술을 이해하면 도움이 됩니다. 주요 세부 사항을 모두 알 필요는 없지만 SharePoint 아키텍처에서 비롯된 전체적인 종속성에 대해 잘 알게 되면 구성해야 하는 대상 및 그 이유를 예측할 수 있기 때문에 더 빠르게 솔루션을 찾을 수 있습니다.
SharePoint는 웹 응용 프로그램 및 사이트를 준비하는 데 사용되는 기술입니다. SharePoint는 IIS 기반 웹 사이트 솔루션으로, ASP.NET을 통해 IIS와 통합되고 SQL Server 데이터베이스 백 엔드를 사용하여 구성 데이터와 콘텐츠를 저장합니다. 간단히 말해서, SharePoint의 핵심 아키텍처는 그림 1에서처럼 세 개의 서로 다른 아키텍처(IIS, .NET 및 SQL Server)의 결합으로 구성되어 있습니다.
그림 1 IIS 6.0 및 ASP.NET 3.0 기반의 WSS 3.0 아키텍처
그림 1 IIS 6.0 및 ASP.NET 3.0 기반의 WSS 3.0 아키텍처
다이어그램이 복잡하다고 걱정할 필요는 없습니다. 실제 구성 요소의 수를 고려하면 처음에는 아키텍처가 복잡해 보일 수 있지만, 이러한 구성 요소를 조직적으로 살펴보면 이 모든 구성 요소가 구성 요소 종속성을 자세히 분석할 수 있게 해주는 하나의 논리적 프레임워크로 결합된다는 것을 알 수 있습니다.
앞서 언급했듯이 SharePoint는 IIS 및 ASP.NET을 사용하여 HTTP 요청과 응답을 처리합니다. HTTP 커널 모드 드라이버(http.sys) 및 작업자 프로세스(w3wp.exe)와 같은 표준 IIS 구성 요소는 ASP.NET ISAPI 필터(aspnet_isapi.dll)에 도달할 때까지 초기에 요청을 큐에 대기시키고 라우팅합니다. .NET Framework를 설치할 때 설치 루틴은 다음과 같이 IIS 메타베이스(C:\Windows\System32\Inetsrv\metabase.xml)에 aspnet_isapi.dll을 등록합니다.
InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
IIS에서 ASP.NET ISAPI 필터를 로드하면 웹 사이트에 대한 들어오는 모든 요청이 ASP.NET으로 전달될 수 있는데, 이 작업은 SharePoint가 ASP.NET을 통해 이 요청을 수신해야 하기 때문에 매우 중요합니다. 이 작업을 수행하기 위해 SharePoint는 파일 이름 확장명에 관계 없이 들어오는 모든 요청을 ASP.NET ISAPI 필터로 라우팅하는 와일드카드 응용 프로그램 맵을 추가하여 선택된 웹 사이트의 구성을 확장합니다.
이러한 확장은 기본 설치 옵션을 사용하여 WSS 3.0을 설치한 후 IIS 관리자에서 볼 수 있습니다. WSS 설치 루틴은 그림 2에서처럼 서버의 기존 기본 IIS 웹 사이트를 비활성화하고 ASP.NET 와일드카드 응용 프로그램 맵이 정의된 새 기본 웹 사이트를 포트 80에 만듭니다.
그림 2 ASP.NET ISAPI 필터에 대한 와일드카드 응용 프로그램 맵
그림 2 ASP.NET ISAPI 필터에 대한 와일드카드 응용 프로그램 맵
ASP.NET이 요청을 SharePoint로 전달하려면 SharePoint는 Microsoft.SharePoint 어셈블리에서 SPHttpApplication이라는 클래스를 사용하여 구현되는 사용자 지정 HttpApplication 개체를 통해 HTTP 요청 파이프라인도 확장해야 합니다. SharePoint는 이 사용자 지정 응용 프로그램 개체를 ASP.NET 응용 프로그램 파일(global.asax)에 정의합니다. 이 파일은 파일 시스템에서 SharePoint 확장 웹 사이트의 루트 폴더에 있습니다. 다음 코드는 global.asax 파일의 내용을 보여 줍니다.
<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>
ASP.NET은 이 파일을 동적으로 구문 분석하고 컴파일하여 SharePoint 응용 프로그램 개체를 인스턴스화합니다.
수신된 각 요청에 대해 ASP.NET은 BeginRequest, AuthenticateRequest, ProcessRequest, EndRequest 등 웹 응용 프로그램이 처리할 수 있는 일련의 이벤트를 트리거합니다. 이벤트 처리에 대한 자세한 내용은 SharePoint 배포 및 관리의 범위를 벗어나지만, global.asax에 지정된 SPHttpApplication 이외에도 SharePoint는 사이트의 web.config 파일에 정의된 사용자 지정 HTTP 처리기와 모듈을 구현한다는 점을 알아두어야 합니다. 예를 들어 SharePoint는 표준 ASP.NET 모듈 이전에 첫 번째 HTTP 모듈로 등록된 SPRequestModule 클래스 기반 HTTP 모듈을 사용합니다. SPRequestModule은 SPVirtualPathProvider 구성 요소를 ASP.NET에 등록하는 방법 등으로 SharePoint 런타임 환경을 초기화합니다. SPRequestModule은 SharePoint가 내부적으로 사용하기 위한 것이지만 SharePoint 솔루션 개발자는 web.config 파일을 수정하여 사용자 지정 HTTP 처리기 및 모듈과 같은 추가 구성 요소를 등록할 수 있습니다. 사용자 지정 HTTP 모듈 및 표준 HTTP 모듈을 통해 SharePoint는 SharePoint 응용 프로그램에 대한 모든 요청을 강력하게 제어하면서 ASP.NET의 이점을 활용할 수 있습니다.
SharePoint 3.0 중앙 관리 사이트를 사용하여 웹 응용 프로그램을 만들 때 WSS는 선택된 IIS 웹 사이트에 ASP.NET 와일드카드 응용 프로그램 맵을 추가하고 웹 사이트의 루트 폴더에 global.asax 및 web.config 파일을 만듭니다. 각각의 웹 응용 프로그램에서는 자체 최상위 global.asax 및 web.config 파일 집합을 사용합니다.
요청을 처리하고 의미 있는 정보를 브라우저에 반환하기 위해 WSS 3.0과 MOSS 2007에서는 요청된 ASP.NET 페이지를 컴파일하거나 이 페이지를 컴파일 없음 모드에서 처리하는 표준 ASP.NET 페이지 파서를 사용합니다. 하지만 SharePoint가 ASP.NET 파서로 전달하는 ASP.NET 페이지는 반드시 예상 위치에 있지는 않습니다. 예를 들어 SharePoint 3.0 중앙 관리 사이트와 같은 SharePoint 확장 웹 사이트의 루트 폴더에서 default.aspx 파일을 찾지 못할 수 있지만 해당 웹 사이트의 홈 페이지를 표시할 경우 default.aspx를 열 수 있습니다. 이것은 로컬 파일 시스템 또는 SQL Server 콘텐츠 데이터베이스에서 페이지 콘텐츠를 로드한 다음 이 콘텐츠를 ASP.NET 페이지 파서에 가상 파일로 전달하여 환경을 가상화하는 SPVirtualPathProvider 구성 요소입니다. 중앙 관리 사이트의 경우 SharePoint는 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin 폴더에서 default.aspx 파일을 로드합니다.
홈 페이지 및 대부분의 다른 SharePoint 사이트 페이지는 메뉴 및 탐색 컨트롤의 공통 레이아웃을 구성하는 ASP.NET 마스터 페이지(default.master)와 연결되어 있습니다. Default.master는 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Global 폴더에 있으며, 로컬 파일 시스템이나 SQL Server 콘텐츠 데이터베이스에 있을 수도 있는 추가적인 콘텐츠 페이지를 위한 명명된 자리 표시자를 포함합니다. 여기서 중요한 점은 웹 브라우저에서 SharePoint 사이트를 열 때 실제로 콘텐츠 페이지 모음의 정보가 표시되는데, 이 콘텐츠 페이지는 로컬 웹 서버에 없을 수도 있고 마스터 페이지에 정의된 레이아웃에 따라 정렬된다는 것입니다.
일반적으로 수정되지 않은 페이지(또는 SharePoint 용어로 사용자 지정되지 않은 페이지)는 모든 SharePoint 서버의 로컬 파일 시스템에 페이지 템플릿으로 존재하며, 사용자 지정된 페이지는 콘텐츠 데이터베이스에 기록되므로 웹 팜의 모든 SharePoint 서버가 같은 페이지 집합에 액세스할 수 있습니다(그림 3 참조). 사용자 지정되지 않은 페이지는 웹 팜의 모든 서버와 사이트에서 동일한 것으로 간주합니다. 하지만 Office SharePoint Designer 2007 등을 사용하여 SharePoint 사이트의 마스터 페이지 또는 콘텐츠 페이지를 사용자 지정하면 SharePoint는 자동으로 사용자 지정된 페이지를 콘텐츠 데이터베이스에 저장합니다.
그림 3 SharePoint 응용 프로그램의 사용자 지정 및 사용자 지정되지 않은 ASP.NET 페이지
그림 3 SharePoint 응용 프로그램의 사용자 지정 및 사용자 지정되지 않은 ASP.NET 페이지
사용자 지정된 페이지 및 기타 웹 사이트 콘텐츠뿐 아니라 SharePoint는 구성 데이터도 SQL Server 데이터베이스에 저장합니다. 구성 데이터는 실제로 글로벌 데이터인 반면 콘텐츠는 각 개별 웹 응용 프로그램과 사이트 모음에 따라 서로 다르므로 SharePoint는 구성 데이터와 콘텐츠를 따로 보관합니다. 따라서 웹 팜에 구성 데이터베이스는 하나만 있을 수 있지만 콘텐츠 데이터베이스는 여러 개 있을 수 있습니다.
웹 팜의 모든 WSS 서버는 동일한 구성 데이터베이스를 사용하여 웹 팜에서 SharePoint에 의해 확장된 모든 단일 IIS 웹 사이트에 대한 메타데이터, 구성 설정 및 정보를 공유합니다. 반면, 개별 웹 응용 프로그램은 하나 이상의 콘텐츠 데이터베이스에 연결될 수 있습니다. 이 경우에도 각 콘텐츠 데이터베이스는 하나의 웹 응용 프로그램에만 연결될 수 있습니다.
IIS 웹 사이트, 웹 응용 프로그램, 사이트 모음, 사이트 및 콘텐츠 데이터베이스 간의 관계가 혼동될 수 있습니다. SharePoint 용어에서 웹 응용 프로그램이라는 용어는 SharePoint 확장 IIS 웹 사이트를 의미합니다. 웹 응용 프로그램에는 여러 사이트 모음이 포함될 수 있으며 각 사이트 모음에는 같은 구성 설정을 공유하는 최상위 사이트와 하위 사이트가 포함될 수 있습니다.
여러 사이트 모음을 만들면 사이트 모음 관리를 다양한 사용자와 그룹에 위임할 수 있습니다. 단일 사이트 모음은 여러 콘텐츠 데이터베이스에 걸쳐 사용될 수 없지만 웹 응용 프로그램은 여러 사이트 모음에 대해 여러 콘텐츠 데이터베이스를 사용할 수 있으므로 확장성을 향상시키고 다른 SharePoint 사이트에 많은 양의 데이터베이스 작업을 생성하는 대규모 사이트의 성능 영향을 완화할 수 있습니다. 하지만 사이트 간 기능이 제한되기 때문에 각각의 SharePoint 사이트를 자체 사이트 모음에 두는 것은 좋지 않습니다.
WSS 3.0에서는 여러 사이트 모음에 대한 콘텐츠 검색 기능을 지원하지 않습니다. 이러한 검색 기능을 사용하려면 MOSS 2007 또는 Microsoft Search Server 2008이 필요합니다. 예를 들어 http://contoso에 대한 웹 응용 프로그램 및 최상위 사이트를 만든 다음 사이트 모음 관리자가 SharePoint 사용자 인터페이스를 사용하여 http://contoso/info 및 http://contoso/events와 같은 하위 사이트를 만들 수 있습니다. 이러한 사이트는 모두 같은 사이트 모음에 속하므로 같은 콘텐츠 데이터베이스에 존재합니다.
팜 관리자는 /sites와 같은 관리되는 경로를 사용한 다음 SharePoint 3.0 중앙 관리에서 http://contoso/sites/IT 및 http://contoso/sites/HR과 같은 추가 사이트 모음을 정의할 수 있습니다. 이 세 개의 사이트 모음(http://contoso, http://contoso/sites/IT 및 http://contoso/sites/HR)은 서로 다른 사이트 모음 관리자, 구성 설정 및 콘텐츠 데이터베이스를 가질 수 있지만 여전히 동일한 IIS 웹 사이트(http://contoso)를 통해 액세스되며 웹 응용 프로그램의 동일한 응용 프로그램 풀 ID를 사용합니다.
물론 더 많은 세부 내용이 있지만 IIS, ASP.NET 및 SQL Server 간의 이러한 관계는 SharePoint에 익숙해지기 위해 이해해야 하는 특히 중요한 내용입니다. SharePoint 아키텍처에 대한 자세한 내용을 보려면 Ted Pattison의 MSDN® Magazine 기사 "Discover Significant Developer Improvements in SharePoint Services"(msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview)를 참조하십시오.

SharePoint 인프라 요소
지금까지 아키텍처에 대해 간략하게 살펴보았으므로 이제 유연한 SharePoint 인프라에 대해 설명하겠습니다. 이미 알고 있듯이 Windows Server®, IIS, .NET Framework 3.0(ASP.NET 및 Windows® Workflow Foundation에 필요), WSS 3.0 또는 MOSS 2007 및 SQL Server가 필요합니다. Windows Server 2008에서 IIS 7.0을 사용하기를 원할 수 있지만 Windows Server 2003에서의 IIS 6.0이 이 글을 쓰는 현재 가장 많이 배포된 버전이므로 이 버전을 사용하겠습니다. 또한 초기 SharePoint 파일럿에는 MOSS 2007 특정 기능이 필요하지 않으므로 WSS 3.0을 사용합니다.
가장 간단한 구성 방식으로, WSS 3.0과 모든 필수 구성 요소를 단일 컴퓨터에 설치할 수 있습니다(이 칼럼의 첨부 자료인 WSS 3.0 on a single computer.pdf 참조). 이 구성은 랩 서버나 소규모 작업 그룹 환경에 적합합니다. 하지만 SharePoint 인프라의 유연성에 중점을 둘 경우 프로덕션 환경에서 독립 실행형 배포로 시작하지 않아야 합니다. 향후의 확장성과 가용성을 위해 다중 계층 인프라로 시작하여 필요에 따라 서버를 추가하는 것이 좋습니다.
그림 4에서는 간단하면서도 유연한 시스템 구성을 원하는 경우에 권장되는 SharePoint 인프라를 보여 줍니다. 이 인프라에는 두 SharePoint 서버로 구성된 웹 팜과 SQL Server를 실행하는 별도의 컴퓨터가 포함됩니다. 이 구성을 사용하면 웹 서버에서 데이터베이스 처리 오버헤드가 제거될 뿐 아니라 가용성과 확장성이 높아지고 시스템을 쉽게 유지 관리할 수 있습니다. Active Directory®는 웹 팜 배포에서 WSS 3.0의 소프트웨어 요구 사항이므로 반드시 설치해야 합니다. 단계별 배포 지침을 보려면 첨부 자료의 Basic SharePoint Infrastructure.pdf 파일을 참조하십시오.
그림 4 확장 가능한 기본 SharePoint 인프라
그림 4 확장 가능한 기본 SharePoint 인프라
이 구성에서 SharePoint를 배포하는 데 사용하는 도메인 계정에는 웹 서버에 대한 로컬 관리자 권한이 있어야 합니다. 또한 Basic SharePoint Infrastructure.pdf에서 볼 수 있는 것처럼 SQL Server 2005에서 이 계정을 master 데이터베이스에 대한 데이터베이스 역할 db_owner와 SQL Server 역할 dbcreator 및 securityadmin에 추가해야 합니다. 그러면 WSS 3.0 설치 중에 SharePoint 제품 및 기술 구성 마법사를 사용하여 SharePoint 3.0 중앙 관리 사이트의 콘텐츠 데이터베이스와 웹 서버 팜에 필요한 구성 데이터베이스를 만들 수 있습니다. 그렇지 않은 경우에는 SQL Server 관리자가 이 데이터베이스를 준비하고 WSS 시스템 계정을 db_owner 역할에 추가해야 합니다.
SharePoint를 설치하는 데 사용하는 사용자 계정은 SharePoint가 중앙 관리 사이트의 콘텐츠 데이터베이스 또는 구성 데이터베이스에 액세스하는 데 사용하는 계정과 달라야 합니다. 대신 SharePoint는 SharePoint 3.0 중앙 관리 사이트의 응용 프로그램 풀 ID로 구성된 시스템 계정을 사용합니다.
SharePoint 제품 및 기술 구성 마법사에서는 계정 정보를 묻는 메시지를 표시합니다. 이 경우 CONTOSO\WssConfigAdmin과 같은 전용 도메인 사용자 계정을 사용하는 것이 좋습니다. 필자의 경우에는 일반적으로 나중에 만드는 모든 추가적인 웹 응용 프로그램에 대해 개별적인 전용 사용자 계정을 사용했습니다. 각 웹 응용 프로그램마다 별도의 응용 프로그램 풀을 사용하면 프로세스를 격리할 수 있으며 각 응용 프로그램 풀마다 서로 다른 사용자 계정을 사용하면 보안 격리를 유지할 수 있습니다. 하지만 이것은 하나의 구성 방식일 뿐이며 자신의 환경과 비즈니스 요구 사항에 따라 관리의 편의성과 잠재적인 성능 영향을 평가해야 합니다.
도메인 관리자가 만들어야 하는 또 다른 중요한 시스템 계정은 검색 서비스 계정입니다. 중앙 관리 계정을 사용할 수도 있지만 추가 보안을 위해서는 관리 권한이 없고 콘텐츠를 수정할 수 없는 CONTOSO\WssSearch와 같은 전용 검색 계정을 사용하는 것이 좋습니다. 검색 서비스는 인덱싱을 위해 콘텐츠를 탐색하고 별도의 데이터베이스에 검색 데이터를 유지하기만 하면 되므로 콘텐츠 데이터베이스에 대한 쓰기 권한은 필요하지 않습니다.
서버 팜에서 웹 응용 프로그램을 만들 경우 해당 콘텐츠 데이터베이스를 검색 서버와 연결할 수 있습니다. 그러면 해당하는 검색 서비스 계정이 웹 응용 프로그램의 전체 읽기 정책에 암시적으로 추가됩니다. 검색 서버는 Windows SharePoint Services 검색 서비스를 실행하는 SharePoint 서버입니다. Basic SharePoint Infrastructure.pdf 파일의 단계별 지침을 수행하면 두 웹 서버를 모두 검색 서버로 구성하여 여러 콘텐츠 데이터베이스를 탐색하고 인덱싱하는 작업의 부하를 분산시킬 수 있습니다. 하지만 탐색 작업이 클라이언트 연결에 영향을 미치지 않도록 클라이언트 연결 및 네트워크 부하 분산에서 제외된 전용 검색 서버를 웹 팜에 구성할 수도 있습니다.

셀프 서비스 사이트 관리
기본 SharePoint 인프라가 갖춰지면 Active Directory, 웹 서버 팜 또는 SQL Server 데이터베이스에 대한 관리 제어 권한을 분산시키지 않고도 사이트 모음 및 사이트의 관리를 개별 부서 및 사용자에게 위임할 수 있습니다. 팜 관리자는 Active Directory 및 SQL Server 관리자와 공동 작업하여 웹 응용 프로그램의 응용 프로그램 풀 계정과 콘텐츠 데이터베이스를 준비합니다. 그런 다음 이 웹 응용 프로그램 내에 사이트 모음을 만들고 사이트 모음 관리자에게 하위 사이트를 만들 수 있는 권한을 지정할 수 있습니다. 이러한 방법으로 개별 부서 내의 사이트 모음 관리자는 그림 5에서처럼 IT 부서와 관련된 작업을 최소화하면서 자체 SharePoint 리소스를 관리할 수 있습니다.
그림 5 중앙 집중화된 SharePoint 인프라의 분산된 사이트 관리
그림 5 중앙 집중화된 SharePoint 인프라의 분산된 사이트 관리
또한 관리되는 경로(예를 들어 /sites 경로 또는 SharePoint 3.0 중앙 관리에서 만드는 와일드카드가 포함된 기타 관리되는 경로) 아래에 사이트 모음을 만들 수 있는 권한을 사용자에게 부여할 수 있습니다. 웹 응용 프로그램 내에서 셀프 서비스 사이트 관리 기능을 사용할 수 있도록 설정하면 사용자는 자체 사이트 모음을 만들고 SharePoint 사용자 인터페이스 내에서 사이트 그룹과 권한을 관리할 수 있습니다. 하위 사이트와 달리 사이트 모음은 부모 사이트에서 권한을 상속하지 않습니다.
셀프 서비스 사이트 관리가 모든 SharePoint 환경에 적합한 것은 아니므로 기본적으로는 사용하지 않도록 설정되어 있습니다. 사용하도록 설정할 경우 콘텐츠 데이터베이스에 자주 사용되지 않는 사이트 모음이 여러 개 만들어질 수 있습니다. 하지만 이 기능은 SharePoint 관리에 뛰어난 유연성을 제공하므로 파일럿 배포에서 확인하는 것이 좋습니다. 또한 SharePoint에는 사용자 또는 관리자에게 비활성 사이트에 대해 알림으로써 필요한 경우 해당 사이트를 제거할 수 있도록 하는 옵션도 있습니다. 첨부 자료의 Enabling Self-Service Site Management.pdf 파일에 설명된 것처럼 웹 응용 프로그램에 대한 셀프 서비스 사이트 관리를 사용하도록 명시적으로 설정해야 합니다.

SharePoint 사용자 지정 및 브랜딩
Sharepoint 리소스
  • Windows SharePoint Services TechCenter
  • Windows SharePoint Services Developer Center
  • Microsoft SharePoint 제품 및 기술 팀 블로그
  • 논리 아키텍처 구성 요소
  • 서버 팜 및 토폴로지 디자인

이 단계에서 SharePoint 사용자 인터페이스에 회사 로고, 이름 및 색상을 추가하고 싶을 것입니다. 하지만 이제 SharePoint 프로젝트를 ASP.NET 개발자 수준으로 만들 것이라는 점에 유의하십시오. 프로덕션 환경에 영향을 주지 않으면서 사용자 지정을 만들고 테스트할 수 있도록 최소한 Microsoft Office SharePoint Designer 2007이 설치된 독립 실행형 WSS 3.0 서버와 같은 개발 시스템이 필요합니다(첨부 자료의 SharePoint Designer Installation.pdf 참조). 또한 Windows SharePoint Services Developer Center(msdn2.microsoft.com/sharepoint)를 방문하여 SharePoint가 제공하는 다양한 사용자 지정 옵션을 자세히 살펴보아야 합니다.
SharePoint 개발은 이 칼럼의 범위를 벗어나지만 몇 가지 고려해야 할 사항을 짚고 넘어가겠습니다. SharePoint는 사용자 지정된 페이지를 해당 사이트 모음의 콘텐츠 데이터베이스에 저장합니다. 즉, SharePoint 사이트에서 사이트 페이지, 응용 프로그램 페이지, 마스터 페이지, 스타일시트 등에 적용하는 모든 사용자 지정은 사이트 모음 또는 사이트 수준에서만 적용됩니다. 이러한 특성은 SharePoint Designer 2007을 사용하여 사이트의 모양과 느낌을 조정하려는 개별 사이트 모음 관리자에게는 매우 유용하지만 웹 팜의 모든 웹 응용 프로그램, 사이트 모음 및 사이트에 회사 이미지를 적용하려는 팜 관리자에게는 그다지 유용하지 않습니다.
표준 SharePoint 테마 또는 사이트 정의의 복사본을 기반으로 사용자 지정 사이트 테마 또는 사용자 지정 사이트 정의를 만들 수 있습니다. 또한 사용자 지정 마스터 페이지를 만들어 마스터 페이지 갤러리에 추가할 수 있습니다. 하지만 셀프 서비스 사이트 관리 기능을 사용하도록 설정한 경우 사이트 모음이나 사이트를 만들 수 있는 권한을 가진 사용자가 회사 이미지를 나타내지 않는 표준 사이트 템플릿을 선택할 수 있기 때문에 이러한 옵션은 글로벌 브랜딩을 적용하지 않습니다.
글로벌 브랜딩을 적용하려면 사용자 지정 구성 요소가 대신 사용되도록 기본 SharePoint 구성 요소를 대체해야 합니다. 개발자는 원본 파일을 수정하지 않고 효과적으로 이 작업을 수행할 수 있습니다. 한 가지 방법은 IIS 관리자에서 가상 디렉터리의 구성을 변경하여 사용자 지정된 파일이 있는 새 폴더를 가리키도록 하는 것입니다. 또 다른 방법은 특정 기본 페이지에 대한 요청을 사용자 지정된 버전으로 리디렉션하도록 URL을 다시 생성하는 사용자 지정 HTTP 모듈이나 ISAPI 필터를 구현하는 것입니다.

결론
WSS 3.0으로 SharePoint 인프라를 구축하는 데 반드시 알아야 할 내용을 집중적으로 살펴보았습니다. 워크플로, 설문 조사, 메시징 통합, 바이러스 차단과 같은 기타 기능과 포털, 사이트 디렉터리, 비즈니스 데이터 카탈로그와 같은 MOSS 2007 특정 기능에 대해서는 다루지 않았습니다. 또한 사이트 관리 및 회사 브랜딩의 사용자 지정에 대해서도 SharePoint 내에서의 가능성 정도만 간략하게 다루었습니다. Visual Studio®에서 사용자 지정 응용 프로그램을 프로그래밍하면 WSS 3.0으로 더 강력한 사용자 지정을 구현할 수 있습니다.
웹 서버나 데이터베이스 서버를 더 추가할 경우에도 인프라는 이러한 확장을 충분히 처리할 수 있을 만큼 강력합니다. 또한 몇 가지 사용자 지정에 대한 파일럿 배포를 통해 사용자는 개별 사이트를 만들고 SharePoint에 익숙해질 수 있습니다. 이러한 방식으로 하드웨어 및 소프트웨어뿐만 아니라 사용자가 채택한 핵심 구성 요소를 구축함으로써 완전한 프로덕션 배포의 기본을 제공하고 변화에 충분히 대처할 수 있는 유연한 인프라를 구현할 수 있습니다.

Pav Cherny는 공동 작업 및 통합 커뮤니케이션을 위한 Microsoft 기술을 전문으로 하는 IT 전문가이자 저술가입니다. IT 운영과 시스템 관리를 주로 다루는 서적, 백서, 제품 설명서 등을 출간한 Pav는 Biblioso Corporation의 회장직을 맡고 있습니다.


 Windows PowerShell: 디렉터리 관리 자동화
Windows PowerShell
디렉터리 관리 자동화
Don Jones

Windows PowerShell의 최초 버전에서 가장 아쉬운 점은 타이밍입니다. Windows PowerShell 팀은 제품 출시에 대한 부담을 어느 정도 느끼고 있었으며(Exchange Server 2007 출시가 예정되어 있었는데 여기에는 Windows PowerShell이 필요했음) Active
Directory 팀은 시간적 여유가 충분했습니다(Windows Server® 2008이라는 다른 제품 작업 중에 있었음). 이러한 이유로 Windows PowerShell은 다소 강력하지 않은 Active Directory® 관리 기능을 탑재한 상태로 출시되었습니다.
그렇다고 해서 Windows PowerShell®에 Active Directory 기능이 전혀 없는 것은 아닙니다. 사실 Windows PowerShell 팀은 VBScript 사용자에게 이미 잘 알려져 있는 스크립팅 용이한 기술인 ADSI(Active Directory Services Interface)에 대한 적절한 지원을 제공하기 위해 많은 노력을 했습니다.

ADSI 방식
ADSI의 동작 방식은 WMI(Windows® Management Instrumentation)와 비슷합니다. 특수 구문을 사용하여 작성한 쿼리를 실행하면 이 쿼리는 도메인 컨트롤러와 같은 원격 컴퓨터로 전송되어 실행됩니다. 쿼리 결과는 Active Directory 개체이거나 개체 컬렉션(예: 사용자 또는 그룹)이며 해당 개체에 대한 참조를 얻어 작업할 수 있습니다. 개체의 속성을 수정하거나 메서드를 실행하여 변경 내용을 저장하고, 새 개체를 만들고, 개체를 삭제하는 등의 작업을 할 수 있습니다. 예를 들어 사용자를 만들려면 사용자가 포함될 OU(조직 구성 단위)나 컨테이너를 쿼리합니다. 반환되는 개체에는 사용자를 만드는 데 사용할 수 있는 Create 메서드가 있습니다.
극히 기본적인 수준에서 보면 Windows PowerShell에서 ADSI를 사용하는 것은 간단하고 쉬워 보입니다. 예를 들어 다음 명령은 사용자를 검색하여 해당 사용자의 Company 특성을 표시합니다.
$user = [ADSI]"LDAP://cn=Ringo,ou=Singers,dc=company,dc=pri"
$user.Get("Company")
사용자를 Get-Member로 전달하여 해당 사용자의 속성과 메서드를 볼 수 있습니다. 하지만 Windows PowerShell 1.0에서는 이러한 디렉터리 개체가 완벽하게 구현되지 않습니다. 그림 1에서 볼 수 있듯이, 셸에서는 개체의 디렉터리 특성을 열거하지 않으며 앞서 사용한 Get 메서드와 같은 개체의 메서드를 표시하지도 않습니다.
그림 1 사용자를 Get-Member로 전달하여 해당 사용자의 속성을 볼 수 있음
그림 1 사용자를 Get-Member로 전달하여 해당 사용자의 속성을 볼 수 있음
이 지원은 Windows PowerShell 2.0의 CTP(Community Technology Preview)에서 약간 향상되었지만 아직은 제한적입니다. 근본적으로 Microsoft® .NET Framework에서는 관리자가 원하는 것을 쉽게 볼 수 있는 기능을 제공하지 않습니다. 애초에 Framework는 개발자를 위해 설계된 것이기 때문입니다. 또 다른 문제는 Windows PowerShell 팀에서 할 수 있는 일이 많지 않으며 Active Directory를 완벽하게 지원하려면 디렉터리를 가장 잘 아는 팀에서 작업을 해야 한다는 점입니다. 즉, Active Directory 팀의 지원이 필요합니다. Windows PowerShell은 아직은 미비하지만 언젠가는 완벽한 기능을 갖출 것으로 확신합니다. 하지만 그 전에는 어떻게 해야 할까요?
이 칼럼의 2007년 6월호(technetmagazine.com/issues/2007/06/PowerShell)에서 Windows PowerShell에 포함된 ADSI 기술을 이용하는 방법을 다룬 적이 있습니다. 이 "기본" 기술에 대한 자세한 내용을 보려면 이 칼럼을 참조하시기 바랍니다. 이번 칼럼에서는 다른 접근법을 소개하겠습니다.

풍부한 환경
Windows PowerShell 설계자인 Jeffrey Snover는 Windows PowerShell의 풍부한 환경을 자주 언급하곤 합니다. 이는 팀에서 Microsoft 내의 프로그래머뿐만 아니라 모든 사용자가 Windows PowerShell의 기능을 확장할 수 있도록 노력했음을 의미합니다. 이미 많은 회사에서는 명령줄을 통해 제품을 관리할 수 있는 기본 Windows PowerShell cmdlet을 만들어 기능을 확장하고 있으며 VMWare, IBM, Citrix 및 Foundry가 이러한 회사에 해당합니다.
이러한 풍부한 환경의 예로 Quest Software를 들 수 있습니다. 이 회사에서는 Active Directory 관리를 위해 설계된 비상업용 cmdlet 집합을 무료로 제공하며 quest.com/powershell에서 다운로드할 수 있습니다. 또한 아직 명령줄에 익숙하지 않은 사람들을 위해 Windows PowerShell을 기반으로 하는 비상업용 무료 그래픽 UI인 PowerGUI(powergui.org)도 제공합니다. PowerGUI를 사용하면 Active Directory 관리 cmdlet을 사용하는 방법을 쉽게 배울 수 있습니다. 이 방법은 사용자에게 매우 유용합니다. 이 cmdlet을 사용하면 Active Directory 관리 기능을 효율적이고 손쉽게 활용할 수 있습니다. PowerGUI에 대한 자세한 내용을 보려면 2008년 1월호의 Toolbox 칼럼(technetmagazine.com/issues/2008/01/Toolbox)을 참조하십시오.

Windows PowerShell 방식
cmdlet과 관련된 모든 것이 사실 Windows PowerShell의 작동 방식입니다. 기존의 스크립트나 프로그래밍 개체를 다룰 필요가 없습니다. 다음은 필자가 좋아하는 한 줄 코드입니다. 이 코드는 CSV 파일을 가져오고 해당 파일의 정보를 사용하여 수십 또는 수백 개의 새 Active Directory 사용자를 만드는 간단한 명령줄입니다.
Import-CSV 'C:\provision1.csv' |
ForEach-Object {New-QADUser -organizationalUnit 'company.pri/Singers' -name ($_.'First Name' + '.' + $_.'Last Name')
-samAccountName $_.'Logon name' -city $_.city -title $_.'Job title' -department $_.department}
이것은 매우 긴 명령이지만 기능은 아주 강력합니다. 이 명령에서는 먼저 CSV 파일을 읽고 개체를 반환하는 기본 셸 cmdlet인 Import-CSV부터 시작합니다. CSV 파일의 각 줄은 단일 개체이며 CSV 파일의 열은 개체의 속성이 됩니다. Provision1.csv 파일에서 "Logon Name" 및 "First Name" 등이 열 이름입니다. 여기서 열 이름이 Active Directory 사용자 특성과 직접 매핑되지 않는다는 점을 주목하십시오. 이러한 파일에서는 Active Directory에만 적용되는 이름보다는 친숙한 열 이름을 사용하는 경우가 일반적입니다. 이러한 파일은 회사의 인사 부서로부터 받는 경우가 많은데, 인사 부서에서는 Last Name이 실제로는 Active Directory의 sn 특성이라는 사실을 모를 수 있습니다.
CSV 파일의 모든 데이터를 가져와서 개체로 변환한 후 이러한 개체를 ForEach-Object cmdlet으로 전달합니다. 그러면 여기에서 각 개체에 대해 한 줄 코드의 중괄호에 포함된 코드 블록을 실행합니다. 즉, CSV 파일의 각 줄에 대해 이 스크립트가 한 번 실행됩니다. 스크립트 안에서 특수 변수 $_는 현재 개체 또는 CSV 파일의 현재 줄에 대한 참조입니다.
각 개체에 대해 New-QADUser cmdlet을 실행한다는 것을 알 수 있습니다. 이는 Quest 추가 기능에 있는 여러 cmdlet 중 하나입니다. 여기서 잠시 QADUser라는 이름에 대해 설명하겠습니다. 짐작할 수 있겠지만 Q는 Quest를 나타냅니다. 이러한 이름 지정 규칙은 Microsoft Active Directory 팀이 향후 만들 수 있는 New-ADUser cmdlet과의 충돌을 피하기 위한 것입니다. 두 cmdlet이 동시에 셸에 로드된 경우 이를 통해 사용자와 셸에서 두 가지를 쉽게 구분할 수 있습니다.
한 줄 코드의 나머지 부분은 New-QADUser cmdlet에 대한 매개 변수로 구성됩니다. 먼저 모든 새 사용자를 만들 organizationalUnit을 지정합니다. 그 다음은 First Name 열의 내용, 마침표 및 Last Name 열의 내용으로 구성되도록 설정된 name 특성을 지정합니다.
마지막으로 다음과 같은 점을 살펴보아야 합니다. 먼저 city 매개 변수는 실제로 Active Directory의 1 특성(또는 Locality-Name)을 변경합니다. 또한 cmdlet은 같은 역할을 하는 l이라는 매개 변수도 사용합니다. 대부분의 경우 Active Directory 특성을 참조하는 매개 변수는 Active Directory 사용자 및 컴퓨터 도구의 특성 이름이나 텍스트 레이블을 사용할 수 있습니다.

기타 Windows PowerShell 방식
Active Directory는 계층적 저장소입니다. 그리고 Windows PowerShell의 강점 중 하나는 모든 계층적 저장소를 디스크 드라이브로 제공할 수 있기 때문에 Dir, Del, Ren, Copy 등과 같은 익숙한 명령을 사용하여 다양한 저장소를 관리할 수 있다는 점입니다. 하지만 Windows PowerShell 1.0에는 PSDrive Provider for Active Directory가 포함되어 있지 않기 때문에 셸에는 Active Directory 자체를 드라이브로 제공할 방법이 없습니다.
다행히 앞서 언급한 풍부한 환경이 PowerShell Community Extensions를 통해 그 역할을 합니다. 이 공개 소스 추가 기능은 codeplex.com/powershellcx에서 무료로 구할 수 있습니다. PowerShell Community Extensions를 설치하면 셸을 도메인 이름으로 리디렉션하여 디렉터리를 드라이브처럼 관리할 수 있습니다.
CD COMPANY:
CD SINGERS
DIR
이 명령은 COMPANY 도메인으로 이동하고 Singers OU로 이동한 다음 그림 2와 같은 개체 목록을 표시합니다. 이 위치에서 Del과 같은 명령을 사용하여 사용자를 삭제하거나 Md를 사용하여 새 OU를 만드는 등의 작업을 수행할 수 있습니다. Community Extensions PSDrive Provider에 대해 몇 가지 알아둘 내용이 있습니다. 이는 구현되었을 것으로 예상하는 기능이기는 하지만 Active Directory 자체가 작동하는 방식에 매핑되지 않기 때문에 사용할 수 없습니다. 또한 도메인의 루트로 이동하여 del * -recurse를 실행하면 권한이 있는 경우 도메인의 모든 개체가 삭제되기 때문에 매우 주의해야 합니다. 기본적으로 "삭제하시겠습니까?"와 같은 메시지도 나타나지 않습니다. 이렇게 명령줄은 강력한 반면 사용 경험이 없고 신중하지 않으면 위험할 수 있습니다.
그림 2 PowerShell Community Extensions을 사용하여 셸을 리디렉션하고 디렉터리를 관리함
그림 2 PowerShell Community Extensions을 사용하여 셸을 리디렉션하고 디렉터리를 관리함

셸 사용 시작
필자의 강의를 듣는 학생들은 Windows PowerShell로 바로 할 수 있는 일이 무엇인지 묻는 경우가 많습니다. Microsoft 제품 중 Windows PowerShell을 사용하도록 재설계되지 않은 제품도 있으며 Windows PowerShell을 아직은 더 발전을 거쳐야 하는 도구로 생각할 수 있습니다.
하지만 사실은 지금 바로 사용할 수 있습니다. Microsoft에서는 아직 Active Directory에 명령줄 관리 기능을 구현하지 않았지만 타사에서는 이를 위한 도구를 제공해 왔으며 이러한 도구들은 상당히 유용합니다. Windows PowerShell을 사용하면 많은 사용자를 새로 만드는 것과 같은 시간이 많이 걸리고 부담스러운 일부 작업의 자동화를 포함하여 많은 관리 작업을 수행할 수 있습니다. Windows PowerShell을 더 유용한 도구로 만들기 위해 노력 중인 커뮤니티의 결과물을 찾아보는 것도 도움이 됩니다. Microsoft 후원 사이트이며 필자가 관리에 참여하고 있는 PowerShellCommunity.org를 방문해 보십시오. Windows PowerShell에 적절한 도구를 갖춘다면 귀찮고 시간이 많이 걸리는 일부 관리 작업을 스크립트로 처리함으로써 관리 작업을 보다 효과적이고 효율적으로 수행할 수 있습니다.

Don Jones는 Windows PowerShell: TFM, 2nd Edition의 공동 저자이자 VBScript, WMI, and ADSI Unleashed의 저자이며 PowerShellCommunity.org의 이사입니다.


 Hey, Scripting Guy!: 모나리자의 눈썹과 정규식
Hey, Scripting Guy!
모나리자의 눈썹과 정규식
Scripting Guys
이 기사의 코드 다운로드: HeyScriptingGuy2008_05.exe (150KB)

지난 2007년 11월 , Scripting Guys는 Tech•Ed IT Forum 컨퍼런스 참가를 위해 바르셀로나로 가는 길에 파리에서 하루 머물게 되었습니다. 하루뿐인 짧은 시간이었지만 세계적인 예술의 전당, 루브르 박물관을 방문하는 소중한 기회를 얻었습니다.
루브르는 어땠냐구요? 찾는 건 어렵지 않았습니다. 노트르담 대성당까지 걸어가서 왼쪽으로 꺾으면 바로 있으니까요.
아, 루브르 박물관이 마음에 들었는지를 물은 겁니까? 예, 대체로 좋았습니다. 단, 여느 박물관이 그렇듯이 눈으로만 보고 직접 만져 보지는 말라는 식으로 운영하는 건 마음에 들지 않았습니다. 모나리자에게 눈썹이 있었다면 분명 더 아름다웠을 텐데 이상하게도 루브르 박물관에서 일하는 사람들은 그림을 좀 고쳐 보려고 하면 화부터 낼테지요.
참고: 사실 Scripting Guys는 모나리자에 무척 감동을 받았습니다. 소문난 잔치집에 먹을 것 없다고, 이름만 유명하고 그저 그런 그림은 아닐까 생각했지만 눈으로 보는 것만으로도 놀라운 경험이었습니다. 눈썹이 없는 건 아쉬웠지만 말이죠. 그런데 밀로의 비너스는 유명세에 비해 실망스러웠습니다. 우리 중에 그 작품에 크게 감명 받은 사람도 없었을 뿐더러, 필자는 밀로의 비너스를 보는 순간 당황스럽기까지 했습니다. 팔 없는 여자 동상이라니요? 그러면 청소나 설거지는 대체 누가 한단 말입니까?
혹시 이 칼럼을 읽는 여성 독자분이 계시다면(남아 있는지 모르겠지만) 위에 한 말은 단순한 오타일 뿐이라는 점을 밝히고 싶습니다. 실제로는 "팔 없는 여자 동상이라니요? 그래도 어쨌든 남자보다 두 배는 더 빨리 효과적으로 일할 수 있겠지만요"라고 말하려던 것이었습니다.
오해의 소지가 있었던 점 사과 드립니다.
좌우간에 루브르 박물관의 소중한 문화 유산들을 두 눈으로 직접 보는 와중에 두 명의 Scripting Guys의 뇌리에 같은 생각이 스쳤습니다. 화장실은 어디에 있지? 그리고 화장실을 찾아 헤매는 동안 필자는 Scripting Guys가 위선자라는 생각이 들었습니다. 루브르 박물관에서 모나리자에 눈썹을 그려넣지 못하도록 하는 데 발끈하면서, 우리도 똑같은 잘못을 저지르고 있는 것 같아서 말입니다. 2008년 1월호 TechNet Magazine에서 우리는 스크립트에 정규식을 사용하는 방법에 대해 다루었습니다. 그런데 그 칼럼이야말로 '보기만 하고 건드리지는 말라'는 태도의 전형이었습니다. 정규식을 사용하여 텍스트 파일의 문제를 파악하는 방법을 보여 주었지만 문제 해결 방법은 소개하지 않았으니까요. 아! 어떻게 그런 일이!
참고: 2007년 11월에 루브르 박물관에 갔다면서 어떻게 2008년 1월에 TechNet Magazine에 실렸던 기사에 대한 생각이 불현듯 떠오를 수 있었을까요? 그것 참 수수께끼입니다. 아마도 이곳 레드먼드와 파리의 시차 때문이 아닐까요?
다행히 루브르 박물관을 운영하는 사람들과 달리 Scripting Guys는 실수를 인정할 줄 압니다. 정규식을 사용하여 항목을 검색하는 방법만 소개하고 정규식으로 항목을 바꾸는 방법은 빠뜨린 것은 분명 잘못이었습니다. 그림 1과 같은 스크립트를 소개했어야 했습니다.
Figure 1 찾기 및 바꾸기 (Close Figure 1)
      Set objRegEx = _
    CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.IgnoreCase = True
objRegEx.Pattern = "Mona Lisa"

strSearchString = _
    "The Mona Lisa is in the Louvre."
strNewString = _
    objRegEx.Replace(strSearchString, _
                     "La Gioconda")

Wscript.Echo strNewString
사실 여기서 설명할 내용은 지극히 간단한 정규식 사용 예라고 할 수 있습니다. Mona Lisa라는 문자열 값을 모두 La Gioconda("눈썹을 어디에 두었더라?"라는 뜻의 이탈리아어)로 바꾸기만 할 겁니다. 물론 VBScript Replace 함수를 사용하면 훨씬 쉽게 바꾸기 작업을 수행할 수 있지만, 이 간단한 스크립트를 통해 정규식을 사용하여 찾기 및 바꾸기 작업을 수행하는 방법을 살펴볼 수 있습니다. 그리고 스크립트에 대한 설명이 끝나면 정규식을 사용하여 보다 멋진 기능을 구현하는 방법도 몇 가지 보여 드리도록 하겠습니다.
보시다시피 이 스크립트는 매우 간단합니다. 먼저 VBScript.RegExp 개체의 인스턴스를 만듭니다. 잘 알겠지만 이 개체는 VBScript 스크립트에서 정규식을 사용할 수 있도록 해 줍니다. 이 개체를 만든 후에는 다음과 같은 개체의 세 가지 속성에 값을 할당합니다.
Global 이 속성을 True로 설정하면 스크립트가 대상 텍스트에서 Mona Lisa라는 문자열을 모두 찾아 바꾸고, Global 속성을 False(기본값)로 설정하면 스크립트가 Mona Lisa의 첫 번째 인스턴스만 찾아 바꿉니다.
IgnoreCase IgnoreCase를 True로 설정하면 스크립트가 검색 시에 대/소문자를 구분하지 않습니다. 즉, mona lisa와 Mona Lisa가 동일하게 취급됩니다. VBScript에서는 기본적으로 대/소문자를 구분하여 검색을 수행합니다. 즉, 대문자와 소문자의 차이로 인해 mona lisa와 Mona Lisa는 완전히 다른 값으로 인식됩니다.
Pattern Pattern 속성에는 우리가 찾고자 하는 값이 들어갑니다. 이 예에서는 Mona Lisa라는 간단한 문자열 값을 찾으려고 합니다.
다음으로, strSearchString이라는 변수에 검색 대상 텍스트를 할당합니다.
strSearchString = "The Mona Lisa is in the Louvre."
그리고 정규식 메서드 Replace를 호출하여 이 메서드에 검색 대상 텍스트(strSearchString 변수)와 대체 텍스트(La Gioconda)를 매개 변수로 전달합니다. 해당 코드는 다음과 같습니다.
strNewString = objRegEx.Replace(strSearchString, "La Gioconda")
이것으로 끝입니다. 수정된 텍스트가 strNewString 변수에 저장되고 StrNewString 값을 출력하면 다음과 같은 결과를 얻게 됩니다.
The La Gioconda is in the Louvre.
문법에는 맞지 않지만 코드가 어떻게 작동하는지 이해하는 데에는 무리가 없습니다.
앞서 설명한 것처럼 이 방법도 문제는 없지만 너무 복잡합니다. 다음의 훨씬 간단한 코드로도 똑같은 결과를 얻을 수 있으니까요. 사실 마음만 먹으면 코드 한 줄로도 충분히 가능합니다.
strSearchString = "The Mona Lisa is in the Louvre."
strNewString = Replace(strSearchString, "Mona Lisa", "La Gioconda")
Wscript.Echo strNewString
이제부터는 VBScript의 Replace 함수로는 불가능하고 정규식으로만 가능한 작업을 구현해 보겠습니다.
좋은 예가 없을까요? 이건 어떻습니까? Scripting Guys는 서로 다른 형식의 문서 간에 텍스트를 복사하는 경우가 많습니다. 복사가 잘될 때도 있지만 그렇지 않을 때도 있습니다. 특히 단어 간격과 관련해서 예상치 못한 문제가 발생하여 아래와 같은 결과를 얻게 되는 때가 있습니다.
Myer Ken, Vice President, Sales and Services
이상하게 불필요한 공백이 많이 들어가 있는 것을 볼 수 있습니다. 이 경우 Replace 함수의 사용이 제한됩니다. 왜냐고요? 불필요한 공백이 무작위로 들어가기 때문입니다. 즉, 단어 사이에 공백이 7개 들어갈 수도 있고 2개나 6개가 들어갈 수도 있습니다. 때문에 Replace를 사용해서는 문제를 수정하기가 어렵습니다. 예를 들어 2개의 연속된 공백을 검색하여 공백 하나로 바꾸는 경우 다음과 같은 결과를 얻게 됩니다.
Myer Ken, Vice President, Sales and  Services
좀 나아 보이긴 하지만 완벽하다고는 할 수 없습니다. 완벽한 결과를 얻으려면 임의의 개수만큼 공백(예: 39개)을 검색하여 바꾼 후 처음 개수에서 하나가 적은 38개의 공백을 검색하여 다시 바꾸는 식의 과정을 반복해야 합니다. 그런데 정규식 스크립트를 사용하면 다음과 같이 훨씬 간단하고 안전하게 같은 작업을 수행할 수 있습니다.
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = " {2,}"

strSearchString = _
"Myer Ken, Vice President, Sales and Services"
strNewString = objRegEx.Replace(strSearchString," ")

Wscript.Echo strNewString
이 스크립트의 핵심(또한 대부분의 정규식 스크립트의 핵심)은 바로 Pattern입니다.
objRegEx.Pattern = " {2,}"
이 코드에서는 2개 이상의 연속된 공백을 찾습니다. 이 Pattern이 2개 이상의 공백을 찾는지 어떻게 알 수 있을까요? 큰따옴표 안에 공백 하나와 {2,} 형식의 문자열이 있는 것을 보면 알 수 있습니다. 정규식 구문에서 이 문자열은 앞에 있는 문자가 2개 연속으로 있는 경우를 찾으라는 의미입니다. 그렇다면 공백이 3개, 4개 또는 937개 연속으로 있으면 어떻게 될까요? 그러한 공백도 모두 문제 없이 검색됩니다. (만약 2개 이상, 8개 이하의 공백을 찾으려 한다면 {2,8}이라는 구문을 사용하면 됩니다. 여기서 8은 일치 항목의 최대 수를 나타냅니다.)
즉, 서로 인접해 있는 공백을 2개 이상 발견할 때마다 연속된 공백이 모두 검색되어 단일 공백으로 바뀝니다. 앞서 살펴본 불필요한 공백이 많은 문자열 값에 이 코드를 적용하면 어떻게 될까요? 바로 다음과 같은 결과가 얻어집니다.
Myer Ken, Vice President, Sales and Services
완벽하지 않습니까? 역시 Scripting Guys는 뭐든지 척척 고쳐내는군요. 루브르 박물관에서도 우리를 좀 믿고 Mona Lisa를 수정하도록 맡겨 주면 좋을 텐데 말이죠.
이제 흥미롭지만 매우 일반적인 시나리오를 하나 살펴보겠습니다. 회사에서 사용하는 전화번호부에 전화 번호가 모두 다음과 같은 형식으로 수록되어 있다고 가정해 보겠습니다.
555-123-4567
그런데 상사가 모든 전화 번호를 다음과 같은 형식으로 바꾸라고 합니다.
(555) 123-4567
이 경우 대체 전화 번호 형식을 어떻게 바꿔야 할까요? 우리가 그렇게 대담한 사람들이라면 다음과 같은 스크립트를 사용하라고 조언해 줄 겁니다.
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\d{3})-(\d{3})-(\d{4})"

strSearchString = "555-123-4567"
strNewString = objRegEx.Replace _
(strSearchString, "($1) $2-$3")

Wscript.Echo strNewString
이 코드는 3자리 숫자(\d{3})와 대시, 또 다른 3자리 숫자와 대시, 그리고 4자리 숫자를 검색합니다. 즉, 다음과 같은 형식을 검색하는 것입니다. 여기서 X는 0 ~ 9 사이의 숫자를 나타냅니다.
XXX-XXX-XXXX
참고: \d{3}이 이어진 3개의 숫자를 찾도록 한다는 것은 어디서 알게 됐냐고요? 흠, 잘 기억은 안 나지만 어디서 읽은 것 같군요. 사실 다빈치 코드의 인상 깊은 마지막 장이나 MSDN® 온라인의 VBScript 언어 참조(go.microsoft.com/fwlink/?LinkID=111387 참조)에서 본 것이 분명합니다.
이제 편리하게도 정규식을 사용하여 임의의 전화 번호를 검색할 수 있습니다. 하지만 아직 큰 문제가 하나 남아 있습니다. 이렇게 검색한 임의의 전화 번호를 똑같은 형식의 다른 임의의 전화 번호로 바꾸는 것이 아니라 똑같은 번호를 형식만 약간 다르게 바꾸어야 하기 때문입니다. 이 결과를 얻으려면 대체 어떻게 해야 할까요?
바로 다음과 같은 대체 텍스트를 사용하면 됩니다.
"($1) $2-$3"
여기서 $1, $2, $3은 정규식 "역참조"의 좋은 예입니다. 역참조란 저장한 후에 재사용할 수 있는 검색된 텍스트의 일부분을 말합니다. 이 스크립트 예제에서는 다음 세 가지 "하위 검색 항목"을 검색합니다.
  • 3자리 숫자
  • 다음 3자리 숫자
  • 4자리 숫자
이러한 각각의 하위 검색 항목에는 자동으로 역참조가 할당됩니다. 즉, 첫 번째 하위 검색 항목은 $1 두 번째는 $2와 같은 식으로 $9까지 할당됩니다. 따라서 이 스크립트에서는 전화 번호의 세 부분에 그림 2와 같이 역참조가 자동으로 할당됩니다.
Figure 2 전화 번호 역참조 (Close Figure 2)

전화 번호 부분 | 역참조
555 | $1
123 | $2
4567 | $3
올바른 전화 번호가 재사용되도록 하기 위해 예제 스크립트의 대체 문자열에 이러한 역참조를 사용합니다. 예제의 대체 텍스트는 첫 번째 역참조($1)를 가져와 괄호 안에 넣고 공백을 하나 추가한 다음 두 번째 역참조($2)와 대시를 추가합니다. 그리고 마지막으로 세 번째 역참조($3)를 넣습니다.
그러면 결과는 어떻게 될까요? 바로 다음과 같은 전화 번호를 얻게 됩니다.
(555) 123-4567
다시 한번 깔끔하게 문제를 해결했습니다.
그럼 다음으로 이 전화 번호 스크립트를 변형한 예제를 하나 살펴보겠습니다. 조직에서 새 전화 시스템을 설치하고 시스템 교체 작업의 일환으로 원래 666, 777, 888 등 여러 가지 국번으로 시작하던 전화 번호를 333이라는 국번으로 통일하려고 합니다. 전화 번호 형식과 국번을 동시에 변경할 방법은 없을까요? 물론 있습니다.
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\d{3})-(\d{3})-(\d{4})"

strSearchString = "555-123-4567"
strNewString = objRegEx.Replace _
(strSearchString,"($1) 333-$3")

Wscript.Echo strNewString
자, 이 코드에서 어떤 작업이 이루어졌는지 알겠습니까? 교체 텍스트에서 이전 국번(역참조 $2)을 제거하고, 그 대신 하드 코딩되고 표준화된 333이라는 국번 값을 넣습니다. 이 수정된 스크립트를 실행한 후 555-123-4567라는 전화 번호는 어떻게 바뀔까요? 바로 다음과 같이 됩니다.
(555) 333-4567
역참조의 일반적인 사용 예를 하나 더 소개하겠습니다. 다음과 같은 문자열 값이 있습니다.
Myer, Ken
이 문자열 값을 뒤집어 이름을 다음과 같이 표시할 방법은 있을까요?
Ken Myer
물론 방법이 없다면 필자가 실없는 사람이 되겠죠? 다음 스크립트를 사용하면 됩니다.
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\S+), (\S+)"

strSearchString = "Myer, Ken"
strNewString = objRegEx.Replace _

strSearchString,"$2 $1")

Wscript.Echo strNewString
이 스크립트는 특정 단어(\S+)와 쉼표, 공백, 그리고 다른 단어가 연속되어 있는 경우를 찾습니다. (이 예제에서는 \S+라는 구문으로 "단어"를 나타냅니다.) \S+라는 구문은 연속된 비공백 문자를 나타냅니다. 즉, 공백, 탭 문자 또는 캐리지 리턴 줄바꿈을 제외한 글자, 숫자, 기호 등의 어떠한 문자도 여기에 포함될 수 있습니다. 예제에서는 성($1)을 나타내는 하위 검색 항목과 이름($2)을 나타내는 하위 검색 항목이 검색됩니다. 따라서 다음 구문을 사용하면 사용자 이름을 '이름 성'의 형식으로 표시할 수 있습니다.
"$2 $1"
쉼표는 어떻게 된 것일까요? 수정된 표시 형식에서는 필요 없으므로 버린 것입니다.
참고: 흠, 어찌된 일인지 이 시점에서 Scripting Editor를 염두에 두게 되는군요. 갑자기 왜 그럴까요.
마지막으로 예를 하나만 더 소개하고 오늘은 이만 마치도록 하겠습니다. (아, 예. 맞습니다. "이번 달"은 이만 마치도록 하겠습니다.) 이 코드는 간단하지만은 않습니다. 그러나 필자도 이런 입문 단계의 기사에서 너무 복잡한 내용을 다룰 생각은 없습니다. (경우에 따라 정규식은 매우 복잡해질 수 있습니다.) 각설하고, 다음 스크립트는 대부분의 경우에 0000.34500044와 같은 값에서 앞에 있는 0을 제거합니다.
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "\b0{1,}\."

strSearchString = _
"The final value was 0000.34500044."
strNewString = objRegEx.Replace _
strSearchString,".")

script.Echo strNewString
여기서도 "\b0{1,}\"라는 패턴이 스크립트의 핵심입니다. 먼저 단어 경계(\b)를 찾습니다. 이는 100.546 같은 값에서 0을 제거하는 일이 없도록 하기 위함입니다. 그리고 하나 이상의 0(0{1,})과 소수점(\.)을 찾습니다. 이러한 패턴이 발견되면 해당하는 0과 소수점을 단일 소수점 "."으로 바꿉니다. 스크립트가 문제 없이 실행된다면 문자열이 다음과 같이 변환됩니다.
The final value was .34500044.
이번 달에 준비한 내용은 여기까지입니다. 마치기 전에 여담을 하나 하자면 모나리자는 물감이 채 마르기도 전에 벌써 큰 논란을 불러일으켰습니다. 대체 이 신비한 여인이 누구인가? 왜 이렇듯 오묘한 미소를 짓고 있는가? 눈썹은 왜 없는가? 미술사학자 중에는 모나리자가 여자가 아니라 레오나르도 다빈치의 자화상이라고 주장하는 사람까지 있었습니다. (만약 이게 사실이라면 재봉사를 바꾸라고 심각하게 조언해 주고 싶군요.) 그런 와중에 Unarius Educational Foundation에서는 한술 더 떠서 사실 모나리자는 "상위 세계"에 있는 레오나르도의 "다른 인격"이며, 이 또 다른 인격이 레오나르도의 손을 빌어 그림을 그렸다고 주장했습니다. 놀랍게도 이번 달 Hey, Scripting Guy!도 바로 이런 방법으로 쓰여졌습니다.
다시 말하면 불만이 있다면 제 2의 microsoft.com에서 칼럼을 쓰는 Scripting Guys의 다른 인격에게 보내시라는 말입니다. 감사합니다.

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

2008년 5월: 스크립트-도쿠
이번 달에는 스도쿠를 약간 변형한 퀴즈를 준비했습니다. 일반적인 스도쿠의 모눈 안에 있는 1 ~ 9 사이의 숫자를 Windows PowerShell™ cmdlet을 구성하는 문자와 기호로 바꾸었습니다. 퀴즈를 다 풀면 행 중의 하나가 cmdlet 이름이 됩니다.
참고: 스도쿠를 푸는 방법을 모르는 독자는 인터넷을 검색하면 스도쿠에 대해 설명한 수천 개가 넘는 웹 사이트를 찾을 수 있으므로 참조하시기 바랍니다. 따라서 여기서는 따로 설명하지 않겠습니다.

Dr. Scripto의 Scripting Perplexer
답: 스크립트-도쿠, 2008년 5월

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


 Security Watch: 양자 보안 원리
Security Watch
양자 보안 원리
Jesper M. Johansson

독특하지만 의미 있는 주제에 대해 논하는 것은 언제나 흥미롭습니다. 요 근래 필자는 보안 개념을 설명하는 데 하이젠베르크의 불확정성 원리를 자주 사용하곤 합니다. 이전에 유니콘 이야기를 들어본 적이 있는 독자는 필자가 이해를 돕기 위해 다른 분야의 기본 이론을 자주 차용한다는 사실을 잘 알 겁니다. 이상하게
들리겠지만 다른 과학 분야의 기본 개념에서 정보 보안 원리를 찾을 수 있습니다.
양자 물리학에서 비롯된 하이젠베르크의 불확정성 원리는 그림 1의 수식을 바탕으로 합니다. 이 원리 자체는 위치 측정의 정밀도를 높이면 운동량 측정의 정밀도가 낮아진다는 소립자의 위치(p)와 소립자의 운동량(x) 간의 관계를 설명하고 있습니다. 두 인자의 정밀도 한계는 플랑크 상수의 일정 배수로 매우 작습니다. 쉽게 말해 단일 소립자의 여러 측면을 동시에 정확하게 관찰할 수 없다는 사실을 밝힌 것입니다.
그림 1 하이젠베르크의 불확정성 원리
그림 1 하이젠베르크의 불확정성 원리
이는 소립자와 관련한 몇 가지 측면에 대한 추론이 얼마나 불확정적인지를 예측할 수 있도록 하는 불확정성 범위 예측과 직접적인 연관이 있습니다. 정보 보안에 있어서는 불확정성 범위를 예측할 수는 없지만 단일 컴퓨터 네트워크에 대한 두 가지 변수가 네트워크의 보안에 어떤 영향을 미칠지 정확하게 예측할 수 없다는 사실이 중요합니다.
어느 정도 절충도 필요합니다. 정보 보안에서는 플랑크 상수에 따른 제한은 없지만 다른 형태의 제한이 있습니다. 가장 두드러지게 절충이 필요한 요소는 바로 보안과 유용성 또는 사용 편의성입니다. 가용성을 완전히 무시한다면 기능을 해제하는 방법이 가장 손쉬운 보안 방식이라 할 수 있습니다. (사실 개인적으로, 보안 담당자는 서비스 거부 공격 이외의 경우에는 가용성에 대해 책임질 필요가 없다고 생각합니다.) 기능을 아예 해제하면 해킹당할 위험도 없을 테니까요. 하지만 유용성은 크게 떨어지겠죠.
마찬가지로, 매년 한 번씩 직원에게 인스턴트 메시징 응용 프로그램이 업무용으로 부적합하다는 사실을 알리는 전자 메일을 보내는 것보다 값비싼 데이터 손실 방지 제품을 구현하면 비용은 크게 증가하겠지만 중요한 데이터의 누출을 훨씬 효과적으로 방지할 수 있습니다. 그런데 조직에서 과연 데이터 손실 방지 도구에 큰 비용을 투자하려 할까요? 이제 양자 물리학이 생각 외로 보안과도 밀접한 관련이 있다는 사실을 이해할 수 있을 겁니다.

슈뢰딩거의 고양이
슈뢰딩거의 고양이라는 비유에서는 이와 관련하여 전혀 다른 개념을 설명하고 있습니다. 이 이야기는 20세기의 저명한 물리학자, 에르윈 슈뢰딩거가 앨버트 아인슈타인과 중첩이라는 개념에 대해 긴 논쟁을 펼치던 당시로 거슬러 올라갑니다. 슈뢰딩거는 원소가 상당히 부조리하게 두 가지 상태로 중첩되어 있는 양자역학 분야를 발견했습니다.
이를 설명하기 위해 슈뢰딩거는 고양이를 완전히 밀폐된 상자에 넣는 사고 실험을 제안했습니다. 상자 안에는 독약이 든 병이 있고 (가상의) 아원자 방사능 입자를 사용해 독약 유출을 제어할 수 있습니다. 방사능 입자가 소멸하면 독약이 유출되고 고양이가 죽게 되는 겁니다.
양자역학의 법칙에 따라 아원자 입자는 중첩 상태로 존재합니다. 따라서 아원자 입자의 상태에 따라 상태가 좌우되는 원자 고양이도 이러한 중첩 상태로 존재하게 됩니다. 따라서 고양이의 상태를 실제로 관찰해야 살아 있는 상태 또는 죽은 상태로 확정할 수 있게 됩니다.
물론 슈뢰딩거는 양자역학의 일부 법칙을 원자계에 적용했을 때 어떠한 부조리가 발생하는지를 보여 주기 위해 이러한 예를 사용한 것이지만, 쉬운 말로 "관찰자 효과"라고 하는 개념을 설명하는 데에도 자주 사용됩니다. 관찰자 효과는 양자역학에서 다루는 아원자계에는 적용되지 않지만 우리 같은 보안 전문가에게는 중요한 의미가 있습니다. 이것은 한마디로 어떤 대상을 관찰하는 것이 그 대상을 변화시키는 결과를 낳게 된다는 개념입니다.
관찰자 효과
좀 더 자세한 설명을 위해 한 잔의 차를 예로 들어보겠습니다. 차가 얼마나 뜨거운지 확인하기 위해 잔에 온도계를 넣습니다. 온도계를 넣을 때 차 온도가 섭씨 80도이고 온도계 자체의 온도는 22도(실내 온도)라고 가정합니다. 온도계를 차에 넣는 순간 차의 열이 온도계로 전도되어 차는 열을 빼앗기고 온도계는 온도가 상승합니다. 그리고 결국 온도계와 차의 온도가 같아집니다. 이때 최종 온도는 80도나 22도가 아니라 그 사이의 값이 됩니다. 차의 온도를 측정하는 행위로 인해 대상이 변하게 되는 것입니다.
관찰자 효과는 정보 보안과도 관련이 있습니다. 즉, 보안 문제를 해결하기 위해 조치를 취할 때마다 시스템이 수정되어 보안 환경이 변할 수 있다는 것입니다. 마땅한 용어가 없으므로 이를 SPFE(보안 환경 가변 효과)라고 부르도록 하겠습니다.
좀 더 간단한 예로, 서비스 계정 종속성을 들 수 있습니다. Protect Your Windows Network(protectyourwindowsnetwork.com)의 8장에서 필자는 시스템에 IDS(Intrusion Detection Service)를 설치하여 공격을 탐지하는 방법에 대해 설명한 바 있습니다. 하지만 IDS는 중앙 시스템에 로그를 기록하며, 이는 모니터링되는 시스템에 대한 높은 액세스 권한을 필요로 합니다. 따라서 서비스는 대부분 높은 권한의 서비스 계정으로 실행되어야 합니다.
이 경우 시스템 중 하나라도 공격에 노출된다면 공격자가 서비스 계정 자격 증명에 액세스하여 다른 모든 시스템에 액세스할 뿐만 아니라 IDS 기능 자체를 해제할 수 있게 됩니다. 이는 SPFE의 전형적인 예입니다. 즉, 보안을 강화하기 위해 시스템 환경에 설치한 도구로 인해 새로운 보안 문제가 발생하는 것입니다.
SPFE의 예는 이외에도 많습니다. 802.1x가 유선 네트워크에서 특정한 문제를 초래하는 이유에 대한 Steve Riley의 설명(microsoft.com/technet/community/columns/secmgmt/sm0805.mspx)도 대표적인 예 중 하나입니다. 호스트 기반 방화벽의 사용은 분명 많은 환경에서 적절한 선택이 될 수 있지만, 802.1x와 함께 사용하면 이전에는 불가능했던 특정 공격 유형에 노출되는 결과를 낳습니다. 이 경우에도 보안 기술이 환경의 보안 상태를 변화시켜 불가능했던 공격을 가능하게 한 것입니다.
그렇다고 이러한 수단이 아예 쓸모가 없으므로 사용하지 말아야 한다는 의미는 아닙니다. 단지 전반적인 보안과 관련하여 어떠한 영향을 미치게 될지 신중하게 고려해야 한다는 의미입니다. 위험을 관리할 때는 작업과 방지 조치가 실제로 위험과 관련하여 어떠한 의미를 지니는지 고려해야 합니다. 문제를 해결할 때는 구현한 수단이 효과가 없다고 해서 간단히 중지할 수 있는 게 아닙니다. 현실적으로 보안은 지속적으로 진행되는 프로세스이기 때문입니다. 심층 방어 전략이 필요하기는 하지만 방어 전략이 보안 환경을 어떻게 변화시키고 전략 구현으로 인해 새롭게 발생하는 위협 요소를 어떻게 해결할지를 먼저 구상해야 합니다.

성숙해진 강화 전략
필자는 10여 년 동안 강화 지침을 다루어 왔습니다. 처음으로 작업했던 몇 가지 가이드를 되돌아보면 동료와 필자가 필요하다고 생각한 설정의 목록에 지나지 않았습니다. 그 당시에는 보안의 근간이 되는 일반 전략이 무척 단순했습니다. 보안 기능을 제공하는 수단은 무조건 사용하는 것이 기본 원칙이었으니까요. 애초에 해당 설정을 해제해야 할 합당한 이유가 있을 수도 있다는 사실은 거의 고려되지 않았습니다.
그러나 보안을 효과적으로 강화하려면 해당 강화 조치와 관련한 여러 가지 측면과 시스템에서 발생할 수 있는 위협을 고려해야 한다는 점을 배우게 되었습니다. 그 결과 Windows 2000 보안 강화 가이드(go.microsoft.com/fwlink/?LinkID=22380)의 시나리오 목록을 마련하게 되었습니다. 그리고 이 가이드가 차츰 발전하여 위협 정도에 따라 지침을 나눈 Windows Server 2003 보안 가이드(go.microsoft.com/fwlink/?linkid=14846)가 탄생했습니다.
그 동안 필자는 사용자들로부터 지침에 따라 설정한 후에도 시스템이 공격 받을 가능성이 있다는 불평을 들어야 했습니다. 그것은 설치되지 않은 패치가 있거나, 잘못된 운영 방식으로 공격의 여지가 생겼거나, 보안이 설정되지 않은 타사 소프트웨어를 설치했기 때문이었지요.
그런데 이 두 가이드의 강화 전략도 전체 보안 환경에는 별 도움이 되지 않는 것으로 드러났습니다. 그 이유는 몇 가지로 요약됩니다. 사실 필자가 구축한 가장 안전한 시스템(msdn2.microsoft.com/library/aa302370)에도 이러한 보안 가이드의 전략을 네다섯 가지밖에 활용하지 않았을 뿐더러, 그 중 어떤 것도 예상된 공격을 실질적으로 막지 못했습니다. 안타깝게도 사람들은 누르기만 하면 시스템이 자동으로 강화되는 "보안" 단추를 원하지만 보안은 그렇게 간단한 문제가 아닙니다.

위험에 대한 접근 방식
한계가 있는 보안을 구축하는 게 아니라 적절하게 보호를 받으려면 위험에 대한 합리적인 접근 방식이 필요합니다. 예상되는 위험을 파악하고 그 중에서 완화해야 할 위험을 결정하고 완화할 방법을 이해하는 것이 우선이며, 이는 스위치만 추가한다고 해서 되는 일이 아닙니다.
대개 이러한 보안 스위치는 특정한 시나리오에 맞게 설계되었기 때문에 당면한 시나리오에서 최적의 구성이 구축된다는 보장이 없습니다. 다만 보안 기반으로서 좋은 출발점이 될 수 있으며 이러한 간편한 보안 강화 도구에 대한 시장 수요가 크기 때문에 대개는 스위치가 제공됩니다. 최신 소프트웨어에서는 대부분의 스위치가 기본적으로 설정되며, 기본적으로 설정되지 않는 스위치는 부작용이 크기 때문인 경우가 많습니다.
게다가 스위치를 많이 사용하면 시스템이 불안정해지고 운영이 어려워져 필요한 작업조차 수행할 수 없게 됩니다. 이는 아직 발생하지도 않은 위협을 완화하기 위한 대가로는 너무 큽니다. SPFE와 양자 물리학은 보안 조치를 취한 후의 결과를 재분석하라는 교훈을 주고 있지만 실제로 그렇게 하는 조직은 거의 없습니다. 사실 애초에 위협에 대해 제대로 분석하는 조직도 적습니다. 보안을 강화하기 전에 먼저 위협을 실질적으로 분석하면 중요한 것은 계정 이름 나열에 대한 익명 제한이나 대규모의 액세스 제어 목록 변경 등이 아니라는 사실을 알게 될 것입니다.
그보다는 시스템에서 특정 서비스를 제공할 필요가 있는지, 제공할 경우 제공 대상은 누구인지 파악하고 그 후에 정책을 적용하는 것이 훨씬 효과적입니다. 또한 절대적으로 커뮤니케이션이 필요한 시스템과 사용자에게만 이를 허용하는 것이 중요합니다. 나아가 모든 응용 프로그램과 사용자가 최소 권한으로 실행하도록 해야 합니다. 요약하자면 보안에 대해 합리적으로 접근하고 까다로운 분석을 통해 각 시스템이 자체적으로 보안 책임을 지도록 해야 합니다.
오늘날의 보안 접근 방식에서 서버 및 도메인 격리(microsoft.com/sdisolation), Windows Server® 제품의 SCW(보안 구성 마법사), Windows Server 2008에서 역할 관리에 사용되는 서버 관리자 도구 등의 보안 도구를 이용하는 것도 이 때문입니다. 이러한 도구는 지원해야 할 시나리오를 파악하는 과정을 안내하고 그에 따라 적절히 시스템을 제한하도록 돕습니다. 이러한 도구가 누구나 원하는 만능의 해결책이 될 수는 없지만 소프트웨어를 구매한 용도에 맞는 작업을 실질적으로 수행할 수 있는 현실적인 설정을 구성할 수 있도록 지원합니다.

필요한 모든 곳에 보안 적용
한마디로 다른 주체나 단순한 도구에 보안을 맡길 수는 없다는 것입니다. 오늘날에는 "네트워크 경계"나 "내부 네트워크" 같은 개념이 의미가 없기 때문에 각각의 자산은 스스로를 방어할 수 있어야 합니다.
대부분의 조직 네트워크는 서로 어느 정도 다릅니다. 따라서 이러한 점을 이해하여 무조건 강화 지침을 따를 것이 아니라 시나리오에 맞는 적절한 단계를 따라야 합니다. 그러기 위해서는 먼저 요구 사항을 파악해야 합니다. 그리고 요구 사항을 알고 있는 다른 사람으로부터 지침을 구하는 것도 필요합니다.
최근 웹캐스트 이용자 중 한 명이 소규모 기업 사용자들에게 미 국토안보부 사이트에서 Internet Explorer® 보안 강화 가이드를 다운로드하라고 충고한 적이 있습니다. 국가적 안보를 책임지는 정부 기관에서 과연 소규모 기업의 웹 브라우저 보안에 대해 효과적인 가이드를 제공할 수 있을까요? 이는 아직 컴퓨터 보안 현장에 만연되어 있는 근거 없는 논리의 좋은 예입니다. 주요 정부 기관에서 발행한 지침이라고 해서 높은 보안 수준을 보장할 것이라는 잘못된 가정에 따른 것입니다.
보안 결정은 대개 양자택일의 형태로 나타납니다. 즉, "높은 수준의 보안"을 구현하거나 "낮은 수준의 보안"을 구현하게 됩니다. 이를 좀 더 정확하게 표현하면 "높은 수준의 보안"과 "적절한 수준의 보안" 사이의 선택이라고 할 수 있습니다. 보안의 기준은 조직마다 조금씩 차이가 있기 마련이니까요.
높은 수준의 보안이 모든 경우에 적합한 것은 아닙니다. 사실 대개 적합하지 않을 때가 많습니다. 또한 도달해야 할 목표도 아닙니다. 높은 수준의 보안이란 시스템이 공격에 노출되면 인명 피해로 이어질 수 있는 시스템을 위한 특별한 구성이니까요. 단, 위험의 양상과 위협 모델이 여기에 해당한다면 높은 수준의 보안을 사용해야 하겠지요.
위험 양상과 위협 모델이 이와 다르다면 보다 적절한 구성을 사용해야 합니다. 아마 구성 가능한 도구는 이미 기본적으로 적절한 위험 양상 수준에 맞도록 설정되어 있을 겁니다. 대부분의 최신 Microsoft 제품에 사용되는 이러한 기본 상태는 보안과 유용성, 사용 편의성 및 성능이 적절히 절충되어 있습니다. 일반적인 보안 강화 구성이 이미 구현되어 있다는 말입니다.
이제 다른 보안 단계를 고려해야 합니다. 먼저 TechNet 보안 센터(microsoft.com/technet/security)나 Windows Server 2008 Security Resource Kit 같은 책을 참조하면 도움이 됩니다.

위험 관리의 중요성
아마 필자가 궁극적으로 무엇에 대해 말하려는지 지금쯤 다들 눈치채셨을 겁니다. 그렇습니다. 바로 위험 관리입니다. 하이젠베르크의 불확정성 원리에서 말하는 중요한 교훈은 절충할 수밖에 없다는 점입니다. 이는 거창한 과학 이론이 아닙니다.
반면 슈뢰딩거의 고양이 이야기에서는 간과하기 쉬운 점을 지적하고 있습니다. 모든 측면에서 문제를 분석하고 절충안을 결정하는 것만큼 해결 방안을 구현하는 데 따른 변화를 고려하는 것도 중요하다는 점입니다. 변경 사항이 시스템에 미치는 영향을 고려하고 그러한 변경 사항이 위험 관리 전략의 일환으로 구현된 것인지 아니면 다른 이유로 발생한 것인지를 분명히 해야만 바람직한 위험 관리 전략이라고 할 수 있습니다.

연간 손실 예측
위험을 정량화하는 방법으로 그림 2의 ALE(연간 손실 예측) 수식이 많이 사용됩니다. 이 수식은 대부분의 보안 인증 교육 코스에서도 가르치고 있는 내용입니다. 표준 ALE는 간단합니다. 위험 발생 가능성과 각각이 발생한 경우 초래되는 비용을 확인하여 두 값을 곱합니다. 이를 통해 매년 보안 사고로 지출되는 금액을 예측할 수 있습니다. 그리고 이러한 위험 비용을 기준으로 문제 완화 솔루션 구현 여부를 결정합니다.
그림 2 손실 발생 가능성을 발생 시마다 소요되는 비용으로 곱한 값을 나타내는 ALE
그림 2 손실 발생 가능성을 발생 시마다 소요되는 비용으로 곱한 값을 나타내는 ALE
그런데 표준 ALE에서는 문제 완화에 소요되는 비용이 고려되지 않는다는 문제가 있습니다. 문제 완화 솔루션은 그 자체로 비용을 발생시킬 뿐만 아니라 부작용에 따른 비용도 발생하게 됩니다.
가장 일반적인 보안 수단 중 하나인 계정 잠금을 예로 들어보겠습니다. 공격자가 암호를 유추하지 못하도록 한다는 표면상의 목적으로 계정 잠금을 구축하는 조직이 많습니다. 공격자가 암호 하나를 유추해 낼 가능성은 수학적으로 계산할 수 있습니다. 창의력만 조금 발휘하면 공격자가 암호 유추에 성공했을 때 초래되는 평균 위험 비용도 구할 수 있습니다. 많은 조직에서는 이 두 값을 기준으로 ALE가 너무 높다고 판단된 경우 계정 잠금을 구현합니다.
그러나 이때 계정 잠금이라는 문제 완화 솔루션에 소요되는 비용은 간과하기가 쉽습니다. 계정 잠금 자체를 구현하는 비용은 물론 상당히 미미합니다. 하지만 엄밀하게 따지면 계정 잠금에 따른 부작용의 비용도 계산에 넣어야 합니다.
우선 지원 부서에서 잠겨진 사용자 계정을 풀어 주는 데 따른 비용이 발생합니다. 계정이 단기간 동안, 예를 들어 15분 정도만 잠기더라도 그 기간 동안의 생산성 손실에 따른 비용이 발생합니다. 이러한 요인은 일정 기간 동안 사고가 발생할 가능성을 각 보안 사고의 비용에 곱한 값으로 계산합니다. 또한 이 비용에 예상되는 잠금 이벤트 수(기존 로그에 기록된 수)를 곱해야 합니다.
사용자로 인해 악화되는 요인도 고려해야 합니다. 실제 사례들을 보면 계정 잠금이 적용될 경우 사용자가 잘못 입력할 위험이 상대적으로 적은 단순한 암호를 사용하게 되리라는 사실을 쉽게 예측할 수 있습니다. 따라서 계정 잠금을 구현하더라도 방지하고자 했던 사고의 가능성이 완전히 제거되지는 않습니다.
마지막으로, 문제 완화 솔루션을 도입하기 전에는 없었던 취약점이 솔루션 도입으로 새롭게 나타날 수도 있습니다. 계정 잠금 예의 경우 공격자가 잘못된 암호를 반복적으로 유추해 입력함으로써 네트워크의 모든 계정이 잠기게 할 수도 있습니다. 이러한 문제가 발생하면 그때마다 관련 비용이 초래됩니다.
이러한 요인을 모두 고려할 때 손실 예측 수식을 수정해야 한다는 사실은 자명합니다. 첫째, 사고 발생 가능성을 수정해야 합니다. 사고 발생 가능이 줄기는 했지만 위에서 살펴본 바와 같이 완전히 0이 되지는 않습니다. 사고 발생 시마다 소요되는 비용도 변경해야 합니다. 그리고 해당 제품 비용에 문제 완화 솔루션의 비용도 추가해야 합니다. 이 비용은 구현 비용에 모든 부작용의 연간 비용을 합산하여 구합니다. 부작용의 연간 비용은 부작용 발생 가능성과 부작용 발생 시에 소요되는 비용을 곱한 값입니다. 보다 정확한 위험 분석이 가능한 이 수식을 약간 단순화하면 그림 3과 같습니다.
그림 3의 수정된 수식을 사용하면 특정 문제에 따른 위험을 보다 정확하게 분석할 수 있습니다. 이미 많은 조직에서 위험 분석에 사용되고 있는 방법입니다. 그러나 아직도 문제 완화 솔루션이 미치는 영향을 분석하는 데 맞지 않는 단순한 방식으로 위험을 분석하는 조직이 너무 많습니다. 수정된 ALE 수식을 사용함으로써 이러한 문제를 해결할 수 있습니다.
그림 3 문제 완화 솔루션의 추가 비용 고려
그림 3 문제 완화 솔루션의 추가 비용 고려

결론
이 글을 읽은 후에 할 일은 바로 보안 전략에 대한 진부한 지식을 다시 한번 검증하는 것입니다. 진부한 시각으로 세상을 보는 자세는 정보 보안 분야에서 일하는 사람에게 어울리지 않습니다. 그리고 구태의연한 가정들도 버려야 합니다.
공격자들은 끊임없이 진화하고 있습니다. 금전적인 이유로, 국가적 패권 전쟁의 일환으로, 자신의 신념을 관철하기 위해 공격자들은 점점 전문화되고 있습니다. 따라서 보안 개선에 전혀 도움이 되지 않는 보안 수단에 시간과 돈을 낭비할 여유가 없습니다. 또한 위험 관리에도 훨씬 더 복잡한 접근 방식이 요구됩니다.
첫째, 모든 보안 솔루션에는 절충이 필요하다는 점을 인식해야 합니다. 모든 결과를 확실히 예측할 수는 없습니다.
둘째, 보안 시스템은 상호 의존적인 시스템이라는 점을 이해해야 합니다. 시스템에 변경된 보안 솔루션을 도입하면 시스템 자체가 수정되므로 시스템을 다시 분석해야 합니다.
변경 사항이 시스템에 막대한 영향을 미쳐 득보다 실이 큰 경우가 많으므로 이러한 분석은 그러한 변경 사항을 실제로 구현하기 전에 미리 실시하는 것이 바람직합니다. 변경 내용 분석의 필요성을 알려 주는 좋은 분석 도구를 사용하면 잊지 않고 분석을 실시하는 데 도움이 됩니다.
마지막으로, 사용자라는 요소도 잊어서는 안 됩니다. 정보 보안과 관련한 모든 조치는 기업과 조직 내의 사용자가 가능한 안전하게 작업할 수 있도록 하기 위한 것입니다.
최근 필자는 한 프레젠테이션에서 바이러스 백신 프로그램을 실행하기 위해 컴퓨터를 구입하는 사용자는 없음을 지적한 바 있습니다. 보안이 관리자의 주된 목표일지는 모르지만 회사의 주된 목표는 아니라는 뜻입니다. 지금 당장은 조직에서 보안이 최대 화두로 떠올라 보안을 간과하지 않을지라도, 보안 부서가 회사를 위해 일하는 것이지 회사가 보안 부서를 위해 존재하는 것은 아니라는 사실을 잊어서는 안 됩니다. 이 사실을 간과하면 사용자가 작업을 수행하기 위해 자신이 이해하지 못하거나 동의하지 않는 보안 통제를 우회하는 등, 다른 편법을 사용하게 됩니다.

Jesper M. Johansson은 보안 소프트웨어 분야의 소프트웨어 설계자이며 TechNet Magazine의 객원 편집자로서, 정보 관리 시스템 분야 박사 학위와 20여 년의 보안 관련 경력을 가지고 있는 Enterprise Security 영역의 Microsoft MVP(Most Valuable Professional)입니다. 그의 최근 저서로는 Windows Server 2008 Security Resource Kit가 있습니다.


 The Desktop Files: 이제는 관리자와 결별할 때
The Desktop Files
이제는 관리자와 결별할 때
Wes Miller

3년도 더 지난 어느 해에, 필자는 주 Windows 시스템에서 사용자 계정을 로컬 관리자 계정에서 로컬 사용자 계정으로 전환하는 작업에 착수했습니다. 필자는 Microsoft에 7년 이상 근무하면서 항상 모든 권한을 가진 관리자로 시스템을 실행해 왔습니다. 물론 이 방법이 매우 편리하기 때문이지요. 그러나 한편으로는 매일 보안에 취약한
관리자 계정으로 많은 시스템을 실행함에도 불구하고 이에 비해 시스템에 보안 문제가 그리 자주 발생하지 않는다는 점을 확인할 때마다 대부분의 사용자가 그렇겠지만 내가 운이 정말 좋다는 생각이 강하게 들었습니다.
필자는 종종 정확한 통계를 얻을 수 있는 방법이 있었으면 좋겠다고 생각해 왔지만, 필자 자신에게는 물론 업계 전반에 걸쳐 너무 많은 조직과 IT 전문가가 로컬 관리자로 시스템을 실행하고 있다는 것이 기정 사실입니다. Winternals에서 근무하던 시절 필자는 "생산적 소비자"의 입장에서 사용자로 실행하는 것이 얼마나 어려움이 많은지 직접 체험해 보고 당사의 제품인 Winternals Prortection Manager가 일반 조직의 업무에 얼마만큼 도움이 되는지 알아보고자 사용자로 전환하여 시스템을 실행해 보았습니다. 지금도 마찬가지지만, 대부분의 조직에서 실제 상당수의 사용자들이 관리자로 시스템을 실행하므로 Winternals의 목표는 관리자들이 사용자로 실행할 수 있게 하고 사용자로 전환함으로써 발생할 수 있는 취약한 부분을 최소화하면서 이러한 전환이 가능하도록 하는 것이었습니다. 어떠한 기술을 사용하든지 간에 사용자가 관리자 계정으로 시스템을 실행하고 있는 조직에서 사용자 계정으로 시스템을 실행하도록 전환하는 것은 쉽지 않은 일입니다. 그러나 사용자로 전환하는 방법이야말로 조직 내의 공격 노출 영역을 줄일 수 있는 가장 효과적인 방법입니다. 이에 대한 정말 좋은 예인 인트라 시스템 방화벽을 생각해 보십시오.

어떻게 지금에 이르게 되었을까요?
여러분께 드리는 당부: 어려움을 체험해 보기
현재 사용하고 있는 관리자 계정을 사용자로 전환할 생각을 아직 해본 적이 없다면 지금부터라도 고려해 보십시오. 또한 지금 바로 사용자로 전환하여 직접 체험해 보기를 권유합니다. 다른 보조 컴퓨터를 사용하는 건 반칙입니다. 매일 사용하는 주 컴퓨터에서 사용자 전환을 시도해 보아야 합니다. 아울러 Windows Vista®를 실행하고 있는 경우라면 UAC(사용자 계정 컨트롤)를 사용하지 말고 시도해 보시기 바랍니다. 여러분의 조직 내에서 변화를 이끌어 내고자 한다면 우선 설득에 들어가기 전에 몸소 실천해 보는 편이 바람직하겠지요. 관리자가 아닌 사용자로 실행해도 그다지 불편한 점이 없다는 사실과 더불어 이를 통한 보안 강화로 인해 정말로 조직의 공격 노출 영역을 줄일 수 있음을 알 수 있을 것입니다.

이전부터 Windows®의 주축을 이루는 사용자 대부분은 시스템에서 관리자로 실행하는 사용자였습니다. Windows NT® 3.1 이전 버전인 Windows 최초 버전의 경우 모든 대화형 사용자는 강력한 권한을 부여받았기 때문에 기능적으로 보안이 전혀 보장되지 않았다고 할 수 있습니다. 집에서 시스템을 실행한 경우에는 그다지 나쁘지 않았습니다. 이 경우는 모든 소프트웨어가 동일한 방식으로 설치되었음을 의미했으니까요. 즉, 여기에는 사용자가 컴퓨터를 소유하고 있고 모든 소프트웨어가 해당 컴퓨터의 모든 사용자를 위해 설치되었다는 가정이 깔려 있었습니다.
Windows NT가 처음 출시되었을 때 이 운영 체제는 일반 소비자는 물론, 기업 시장을 바로 석권하지는 못했습니다. 게다가 32비트 Windows와 Windows NT 간의 Win32® 호환성으로 인해 대부분의 응용 프로그램 공급업체에서는 Windows NT의 보안 인프라를 위해 자사의 응용 프로그램을 다시 빌드하지 않았습니다. 대부분의 소비자 지향적 ISV(Independent Software Vendor)의 경우 Windows 2000이 등장하기 전까지는 Windows NT에 그다지 많은 관심을 기울이지 않았던 것이 사실입니다. 물론 Windows XP 등장으로 인해 Windows 9x 제품군이 더 이상 사용되지 않게 되면서 이 문제가 저절로 해결되었지만 서두요.
그러나 아직도 많은 응용 프로그램이 시스템의 모든 사용자가 Program Files, 레지스트리의 HKEY_LOCAL_MACHINE(HKLM) 및 HKEY_CLASSES_ROOT에 쓰기 권한이 있다는 전제하에 작동되고 있습니다. 실제로는 사용자에게 이러한 권한이 없는데도 말이지요. 이러한 전제하에 작동됨으로써 가장 안 좋은 문제가 발생하는 응용 프로그램 중 하나는 바로 게임입니다. 자세한 내용은 technetmagazine.com/issues/2007/02/Gaming에서 이 주제를 다룬 Matt Clapham의 기사를 참조하시기 바랍니다.
이는 문제가 발생할 소지가 많습니다. 왜냐하면 대부분의 시스템 간 응용 프로그램에서는 파일 및 레지스트리 설정을 위에 언급한 위치에 저장하며 이러한 응용 프로그램을 설치하려면 해당 위치에 대한 읽기/쓰기 권한이 있어야 하기 때문입니다. 이에 따라 안타깝게도 일부 응용 프로그램에서는 설치 후 이러한 키에 대한 쓰기 권한을 요구합니다. 예를 들어 필자의 자녀가 플래시 기반 게임을 하는 경우를 가정해 보겠습니다. 이 게임은 매번 실행할 때마다 사용자 지정 플레이어를 설치하려고 시도합니다. 즉, 아이가 관리자가 아닌 사용자로 실행할 경우 응용 프로그램을 시작할 수 없으며 심각한 오류가 발생하게 됩니다. 이는 비록 극단적인 사례이고 이 프로그램은 소비자 응용 프로그램이지만 실제로 관리자가 아닌 사용자로 실행할 경우 많은 비소비자 응용 프로그램이 제대로 실행되지 않습니다. 관리자 여러분이 필자의 조언을 따른다면(추가 기사 "여러분께 드리는 당부: 어려움을 체험해 보기" 참조) 사용자로 실행하는 경우 Windows 자체에 얼마나 제약이 많은지 알게 될 것입니다.
그림 1을 살펴보면 Windows XP에서 사용자로 IPConfig /release를 실행할 때 어떠한 결과가 나타나는지를 알 수 있습니다. 이를 그림 2와 비교해 보면 Windows Vista에서 동일한 명령을 실행하는 경우 그 기능이 크게 향상되지는 않았으나 최소한 명령이 실패하는 이유를 파악할 수는 있습니다. 참고로 이 네트워킹 도구는 사용자가 IP 주소를 새로 고칠 수 있도록 전체적으로 향상되었습니다. 이와 유사하게 둘 중 한 가지 버전에서 컴퓨터 관리(compmgmt.msc)를 사용자로 실행할 경우 제한된 작업을 수행할 수 있긴 하지만, 대부분 그림 3에서 볼 수 있는 바와 같이 결국에는 작업을 수행할 수 없는 결과에 직면하게 됩니다. Windows Vista에서는 컴퓨터 관리에 포함된 많은 도구를 애초에 실행할 수 없지만 액세스 거부 메시지가 더 명확하게 표시됩니다.
그림 1 Windows XP에서 사용자로 실행하는 경우
그림 1 Windows XP에서 사용자로 실행하는 경우
그림 2 Windows Vista에서 사용자로 실행하는 경우
그림 2 Windows Vista에서 사용자로 실행하는 경우
그림 3 Windows XP에서 사용자로 compmgmt.msc를 실행한 후 표시되는 잘못된 메시지
그림 3 Windows XP에서 사용자로 compmgmt.msc를 실행한 후 표시되는 잘못된 메시지

이 문제가 중요한 이유
우리가 이 문제를 고려해야 하는 이유는 무엇일까요? IT 전문가의 관점에서 본 정답은, 대화형 사용자가 시스템을 소유하고 있는 것으로 가정하는 응용 프로그램이 있는 경우 해당 응용 프로그램을 모든 권한이 아닌 최소 권한이 부여된 사용자에 맞춰 조정될 수 있도록 강제적인 조치를 취해야 하기 때문입니다.
안타깝게도 관리자에게 레지스트리 키에 대한 쓰기 권한을 허용하는 정책은 사용자 컨텍스트에서 실행되는 모든 맬웨어에게도 ACL(액세스 제어 목록)을 통해 명시적으로 거부되지 않은 모든 항목에 대한 모든 권한을 부여합니다. UNIX 운영 체제에서는 사용자가 루트(Windows Administrator 계정과 동일)로 실행하지 않는 규칙을 따릅니다. 이는 주로 보안 모델의 경계를 확장하는 소프트웨어 환경이 매우 작거나 아예 존재하지 않기 때문입니다.
가장 좋은 방법은 이와 같은 방식을 따르거나 명시적으로 필요한 경우에만 관리자로 실행하는 것입니다. 더욱 좋은 방법은 개별 응용 프로그램을 실행할 때에만 관리자로 실행하는 것입니다. 이렇게 함으로써 앞서 언급했던 인트라 시스템 방화벽 기능을 향상할 수 있습니다. 그러면 맬웨어나 스파이웨어가 시스템을 감염시키기 위해 필요한 레지스트리나 파일 시스템 위치에 쓰기 작업(예: 서비스 또는 드라이버 설치, 모든 사용자를 위한 설치)을 수행할 수 없으므로 공격에 실패합니다. 또한 이렇게 하면 전체 시스템을 위험에 빠뜨리기 전에 맬웨어 방지 소프트웨어에서 인식하는 맬웨어를 방지할 있습니다.
그러나 이러한 사용자가 공격에 강한 것은 아닙니다. 광범위하게 존재하는 것은 아니지만 여전히 개별 사용자 컨텍스트를 감염시키거나 데이터를 파괴할 수 있는 맬웨어가 존재합니다. 하지만 이러한 소프트웨어로 인해 발생하는 공격 요소는 제한적입니다. 결과적으로, Linux 또는 Macintosh의 맬웨어 공격 수를 낮춰 주는 방법(공격에 취약한 요소를 줄여 맬웨어 작성자가 활동할 수 있는 영역을 줄임)을 동일하게 사용하여 최종 사용자는 물론 관리자의 안전을 보장할 수 있습니다.

고급 사용자는 안전한가요?
Protection Manager를 개발할 당시 가장 많이 들었던 고객의 의견 중 하나는 "우리는 모든 사용자가 관리자가 아닌 고급 사용자로 Windows XP를 실행하고 있으므로 매우 안전합니다."라는 의견이었습니다. 그러나 실제로 고급 사용자는 관리자와 약간만 다른 기능이라고 할 수 있습니다. Windows XP의 경우 약간의 작업을 통해 고급 사용자를 관리자처럼 사용할 수 있는 잠재적인 약점이 몇 가지 있습니다. 그러나 사실 이러한 고급 사용자 그룹은 Windows Vista 및 Windows Server® 2008에서는 제거되었으며, 이전 버전의 Windows를 업그레이드한 시스템에만 포함됩니다. 따라서 Windows XP 사용자의 경우에도 항상 고급 사용자 그룹을 사용하지 않는 것이 좋습니다.

잃는 게 더 많은 권한
필자가 3월호에 게재한 Windows 씬 클라이언트에 대한 칼럼(technetmagazine.com/issues/2008/03/DesktopFiles)을 읽었다면 공간 절약을 위해 Windows XP를 축소하는 방법에 대한 예상 효과에 대해 필자가 반대 의견을 피력했던 점이 기억이 나실 겁니다. 이와 같은 맥락에서, 관리자에서 사용자로 전환 시 고려해야 할 흔히 사용되는 방법이 있으나 이 방법을 수행할 때에는 매우 주의를 기울여야 합니다. 이 방법은 바로 레지스트리 및 파일 시스템의 ACL을 조정하여 일반적으로 사용자에게 부여되지 않는 이 위치에 대한 쓰기 권한을 부여하는 것입니다. 바로 이 과정에서 응용 프로그램에 문제가 발생할 수 있습니다.
물론 가장 좋은 방법은 업데이트된 응용 프로그램을 구하는 것이고, 이렇게 하면 위와 같은 변경 작업을 수행할 필요도 없지만 이 방법이 항상 가능한 것은 아닙니다. 권한을 변경해야 할 경우에는 이는 곧 권한을 삭제하는 것을 의미하므로 대단히 신중하게 처리해야 합니다. 사용자와 관리자 사이의 방화벽은 레지스트리 및 파일 시스템 권한에 따라 광범위하게 정의되어 있다는 사실을 유념해야 합니다. 권한을 높이면 보안이 취약해지고 맬웨어에 의한 잠재적인 공격 노출 영역이 확장될 수 있으므로 신중하게 판단하여 작업을 수행하십시오.

UAC란 무엇입니까?
Windows Vista의 UAC(사용자 계정 컨트롤)에 대해 언급하지 않고는 관리자에서 사용자로 전환하는 방법을 완벽하게 설명했다고 볼 수 없습니다. UAC는 Mac OS X의 기능과 유사하며 큰 위험 요소 없이 "관리자로" 실행할 수 있게 해 주는 기능입니다.
UAC는 어떤 원리로 작동할까요? Process Explorer에서 cmd.exe에 대해 어떠한 항목을 표시하는지 그림 4를 통해 살펴보십시오. 오른쪽에 표시된 cmd.exe 인스턴스는 관리자로 실행했으므로 권한 상승 없이 시작되었습니다. 결과적으로 오른쪽에 표시된 사용자가 왼쪽(cmd.exe가 권한 상승을 통해 시작된 경우)에 표시된 사용자와 동일한 경우에도 해당 응용 프로그램 자체에는 관리자 권한을 필요로 하는 모든 작업을 수행하는 데 필요한 권한 및 응용 프로그램 및 해당 인스턴스를 실행하는 사용자를 위한 토큰이 없습니다. UAC는 사용자 대화형 컨텍스트 내의 공격 노출 영역을 줄이는 방식으로 작동합니다. 다만 한 가지 문제점은 Windows에서 이 작업을 수행하려면 관리자 권한이 필요하며 사용자에게 이 작업을 완료하는 데 필요한 권한 상승이 허용되는 경우 이 작업을 수행할 수 있음을 지정해야 한다는 점입니다.
그림 4 서로 다른 권한으로 실행되는 &#xD;cmd.exe의 두 인스턴스
그림 4 서로 다른 권한으로 실행되는 &#xD;cmd.exe의 두 인스턴스
Windows Vista의 작은 방패 표시는 권한 상승이 필요한 작업을 나타냅니다(그림 5 참조). 이러한 작업은 매번 실행할 때마다 권한 상승을 해야 하며 바로 이 부분이 언론에서 꼽은 Windows Vista의 단점 중 하나입니다. 이에 대한 대안으로 자격 증명을 보다 "까다롭게" 설정하여 손쉽게 시스템을 악용할 수 있는 잠재적인 보안 위협 요소를 제거할 수 있습니다.
그림 5 권한 상승 필요를 나타내는 Windows Vista의 방패 표시
그림 5 권한 상승 필요를 나타내는 Windows Vista의 방패 표시
UAC가 설정되어 있으며 사용자가 간단하게 사용자 계정으로 실행 중인 경우 관리자 권한이 필요한 응용 프로그램 실행 시 관리자 자격 증명을 요구하는 메시지가 사용자에게 나타납니다. 이 경우 UAC를 사용하는 상태에서 관리자로서 실행하는 것과 달리, runas 또는 psexec를 사용하는 경우와 마찬가지로 해당 응용 프로그램은 말 그대로 관리자가 시작한 사용자의 컨텍스트에서 실행됩니다. 따라서 해당 작업은 관리자의 컨텍스트에서 실행되나 상승된 권한으로 실행됩니다.

Windows Vista를 사용자로 실행하는 경우
필자는 개인적으로 Windows Vista를 UAC를 사용하는 상태에서 관리자로 실행하는 것보다 사용자로 실행하는 것을 선호합니다. 그 이유는 이 방법이 현재까지로는 일반 기업에 가장 적합하다고 여기기 때문입니다. 결과적으로 사용자는 시스템에 대한 모든 권한을 가지며 관리자는 맬웨어의 침입 기회를 줄일 수 있습니다.
뿐만 아니라 그룹 정책, 바이러스 백신, 맬웨어 방지 또는 기타 소프트웨어를 사용하여 사용자를 관리하는 동시에 이러한 작업의 실제 적용 또는 수행 여부를 중앙에서 제어하려는 경우 최종 사용자가 관리자가 아니도록 하는 것은 매우 중요한 절차입니다. 사용자가 관리자인 경우에는 사용자가 서비스 중지, 드라이버 추가 또는 제거를 비롯한 기타 작업을 수행할 수 있기 때문입니다. 물론 사용자 계정으로 실행하는 잔꾀가 많은 최종 사용자 중에는 Windows PE를 사용하여 몇몇 보안 장애물을 피할 수도 있습니다. BitLocker®를 사용하면 이러한 작업을 까다롭게 할 수는 있지만 물리적으로 액세스할 수 있는 최종 사용자가 충분한 시간과 정보를 갖고 노력하면 해당 컴퓨터에서 원하는 모든 작업을 수행할 수 있다는 사실을 유념해야 합니다.
Windows Vista를 사용자로 실행하는 것은 Windows XP를 사용자로 실행하는 것과 크게 다르지 않습니다. 필자는 PSExec, RunAs 등 Windows XP에서 사용한 것과 동일한 도구 및 UAC(현재 사용)를 사용하여 필요한 경우 관리자로서 작업을 실행합니다. 좋은 점은 Windows XP에서는 관리자 권한이 필요했던 상당히 많은 작업을 수행하는 데 더 이상 관리자 권한이 필요 없어졌다는 것입니다. 예를 들어 Windows Vista 사용자는 로컬 프린터를 설치할 수 있습니다. Windows XP의 경우 사용자는 네트워크 프린터를 설치할 수는 있었지만 로컬 프린터를 설치하려면 관리자 권한이 필요했습니다. Windows Vista에서는 사용자가 컴퓨터를 물리적으로 조작할 수 있고 드라이버 저장소에 프린터 드라이버가 있기만 하면 프린터 설치는 물론 인쇄 작업까지 관리할 수 있습니다. 자세한 내용은 go.microsoft.com/fwlink/?LinkId=111534를 참조하십시오. 참고로 Windows Server 2008에서는 이 기능을 사용할 수 없습니다.
물론 Windows XP에서 사용자로 실행할 때 나타나는 시계 기능이나 그 기능 부족을 놀림거리로 삼는 사용자도 있습니다. 이 시계가 두 번 클릭되는 경우 날짜를 보여 주는 방식으로 작동하도록 지정되었는지에 관계없이 사용자들은 때때로 날짜를 확인하기 위해 시계를 두 번 클릭하는 경우가 있으므로 사용자로 실행할 때 시계를 두 번 클릭해 보십시오. 이 경우 그림 6과 같은 오류 메시지가 표시됩니다. 그다지 우호적이지는 않은 메시지라 할 수 있겠지요. Windows XP에서는 사용자가 이와 같은 작업을 수행할 수 있도록 정책을 수정할 수 있었지만 Windows Vista에서는 원래 방식 그대로 작동하도록 변경되었습니다. 따라서 Windows Vista에서는 UAC를 사용하거나, 공식 사용자로 실행하거나, 다른 사용자로 권한을 상승하거나 하는 경우에 상관없이 사용자로 실행할 경우 Windos XP보다 훨씬 개선된 환경을 경험할 수 있습니다.
그림 6 Windows XP에서는 관리자가 아닌 사용자의 경우 시간을 변경할 수 없음
그림 6 Windows XP에서는 관리자가 아닌 사용자의 경우 시간을 변경할 수 없음

제한 사항에 유의할 것
사용자를 관리자가 아닌 사용자로 전환하는 것이 만병 통치약은 아니라는 점을 기억해 두십시오. 극성스러운 최종 사용자는 여전히 자신의 PC를 물리적으로 조작할 수 있으며 자신의 시스템을 악용하기 위한 작업을 꾸준히 수행할 수 있습니다. 특히 정책이나 사용자 권한으로 인해 작업을 완료하지 못하도록 저지당하는 경우 더욱 그럴 수 있습니다.
사용자가 관리자 계정으로 실행하는 경우에는 적용된 그룹 정책을 무시하기 위해 그다지 많은 작업을 수행할 필요가 없습니다. 물론 사용자도 조금 더 수고하면 Windows PE로 부팅하여 일반적으로 권한이 부여되지 않는 권한이 부여되도록 수정할 수 있습니다. 그러나 관리자가 BitLocker 또는 기타 드라이브/볼륨 암호화를 사용하면 이러한 작업이 불가능하거나 실행하기 매우 까다롭도록 할 수 있습니다.
아직 조직에서 최종 사용자들이 사용자로 실행하도록 전환하지 않은 경우 관리자가 할 수 있는 가장 중요한 일은 왜 관리자와 조직이 시간과 비용, 그리고 노력을 들여 조직의 사용자가 관리자로 실행하지 않도록 전환해야 하는지에 대해 제대로 파악하는 것입니다.
물론 기존의 익숙한 응용 프로그램을 버리는 것은 어려운 일입니다. 그러나 사용자 계정으로는 간단히 실행할 수 없는 응용 프로그램을 그대로 갖고 있는 것은 조직의 보안 유지 비용을 낭비하는 잘못된 생각일 뿐입니다. 따라서 해당 응용 프로그램을 가상화, 즉 말 그대로 가상 컴퓨터로 이동하는 방법을 고려해야 합니다. 이러한 가상 컴퓨터에서는 사용자가 관리자 권한을 가질 수 있습니다. 이렇게 하면 필요한 경우 해당 응용 프로그램을 사용할 수 있을 뿐만 아니라 관리자를 사용자로 전환함으로써 나머지 시스템을 안전하게 보호할 수 있습니다.
이번 칼럼의 전체 내용에서 필자는 "잠금" 또는 이 용어에서 파생된 단어를 사용하지 않았습니다. 관리자를 사용자로 전환하는 작업을 고려하는 상당수의 관리자 중 이 단어를 사용하여 설명하는 경우가 더러 있습니다. 아마도 필자의 주관적인 견해이거나 필자가 종사하고 있는 마케팅 분야에서만 그런 것인지 모르겠지만, 이러한 단어는 의미적인 수준에 불과할지라도 최종 사용자에게 권한을 박탈당한다는 느낌을 줄 수 있으므로 지양하는 편이 좋다고 생각합니다.
그 대신 조직에서 얻을 수 있는 보안상의 이점에 중점을 두어 설명하고, 사용자 계정으로 실행할 수 없는 특수 사용자의 경우나 관리자 권한이 필요한 특정 작업이 있는 경우와 같이 극단적인 경우에 대비할 수 있는 좋은 계획이 있음을 충분히 설명하십시오. Run.vbs 스크립트(technetmagazine.com/issues/2007/03/DesktopFiles에서 참조)와 같은 수동 해결 방법을 사용하든, 전환하는 데 도움이 되는 상용 솔루션을 사용(최종 사용자에게 세부 정보를 숨기고 작업을 "수행만" 함)하든지 간에 최대한 빨리 관리자가 아닌 계정으로 전환하는 것이 중요합니다. TechNet Magazine의 상시 기고가인 Aaron Margosis는 관리자가 아닌 사용자로 전환하는 작업을 적극적으로 지지하고 있습니다. Aaron Margosis의 블로그(blogs.msdn.com/aaron_margosis)를 아직 방문하지 않았다면 지금이라도 방문해 보십시오. 이 주제에 대한 깊이 있는 정보를 얻을 수 있는 최고의 리소스입니다.

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


 Field Notes: 한 대의 PC에 여러 개의 마우스
Field Notes
한 대의 PC에 여러 개의 마우스

오늘날의 인도는 극과 극이 공존하는 국가입니다. 한편으로는 전 세계의 컴퓨팅 요구 사항을 충족하는 기술을 개발하는 고급 IT 인력을 갖춘 강국이고, 다른 한편으로는 국가의 70%에 달하는 인구가 하루 2달러 미만으로 생계를 이어가고 있는 것이 인도의 현실입니다. 이와 같은 양극 현상은 재정적인 어려움 때문에 컴퓨터를 몇 대밖에 갖추지 못한 공립 학교의 컴퓨터 교실에서 확연히 드러납니다. 학교 자체적으로 컴퓨터를 구입할 예산이 없기 때문에 이러한 컴퓨터는 대개 기증된 것입니다.
이러한 환경에서는 거의 대부분의 경우 컴퓨터 수보다 학생 수가 훨씬 많습니다. 한 대의 컴퓨터 앞에 10명 정도 되는 어린이들이 모여 있고 그 중 대장 노릇을 하는 어린이가 컴퓨터를 차지하고 있는 광경을 아주 흔하게 볼 수 있습니다. 물론 개인 컴퓨터라는 용어에서 "개인"은 단일 사용자가 사용하도록 컴퓨터가 설계되었다는 것을 의미하지만 Microsoft Research India에서는 어떻게 하면 더 많은 아이들이 컴퓨터를 사용하게 할 수 있을지 고민해왔습니다.
해답은 의외로 간단했습니다. MultiPointTM라는 기술을 사용하면 여러 개의 USB 마우스를 컴퓨터 한 대에 연결할 수 있으므로 각 마우스가 화면에서 서로 다른 색의 커서로 반응합니다(research.microsoft.com/users/udaip/multipoint.htm 참조). 이를 통해 게임 콘솔과 같은 다중 사용자 환경을 구현할 수 있으므로 여러 마우스 패러다임용으로 만들어진 교육용 소프트웨어를 사용하여 여러 명의 어린이가 동시에 PC를 사용할 수 있습니다.
화면이 혼란스럽지 않을까 하는 어른들의 우려에도 불구하고 어린 학생들은 이러한 방식에 즉시 적응했습니다. 7학년 학생을 대상으로 다섯 명의 학생이 MultiPoint PC를 사용하고 한 명의 학생이 PC 한 대를 사용하는 구성을 엄격하게 비교 연구한 결과, 연구원들은 몇 가지 흥미로운 점을 발견할 수 있었습니다. 첫째, 각 학생에게 마우스를 하나씩 제공할 경우 재미 요소가 가미되어 더 오랫동안 PC를 사용하고 다른 학생들과 시간을 보낼 수 있습니다. 둘째, 경쟁심 대신 공동 작업을 유도하는 소프트웨어를 개발하는 것이 중요합니다. 경쟁심을 유발할 경우, 특히 남자 아이들의 경우에는 교육적인 효과 없이 "잽싸게 움직이기" 경쟁으로 전락할 가능성이 있습니다. 마지막으로, 학생들 간의 협력이 잘 이루어지면 MultiPoint 응용 프로그램을 사용하는 경우에도 간단한 단어 기억 학습 정도는 PC를 단독으로 사용할 때와 비슷한 학습 효과를 볼 수 있습니다. 이 연구에 대한 자세한 내용은 앞에 제공된 MultiPoint 링크에서 확인할 수 있습니다.
대량 구입 시 마우스 가격은 몇 달러밖에 되지 않으므로 MultiPoint 교육 응용 프로그램을 제공할 경우 학생당 컴퓨터 사용 비용을 크게 낮출 수 있습니다. 예를 들어 한 대에 500달러인 PC를 다섯 명의 학생이 5달러짜리 마우스를 하나씩 연결하여 공유한다면 학생 한 명당 소요 금액이 105달러가 되는 셈입니다. 이처럼 학생당 비용을 줄일 수 있다면 교육 예산을 책정하는 담당자의 입장에서는 매우 고무적인 일일 것입니다.
Microsoft의 Unlimited Potential(microsoft.com/unlimitedpotential) 및 Education(microsoft.com/education) 그룹에서는 예산이 부족한 학교에서 MultiPoint 솔루션이 기여할 수 있는 가치를 인식하게 되었으며 교육 콘텐츠 개발자가 이러한 다중 마우스 패러다임을 C# 응용 프로그램에 손쉽게 적용할 수 있는 소프트웨어 개발 키트를 출시함으로써 이 기술이 빠른 시간 내에 널리 채택될 수 있도록 하고 있습니다. 이 SDK는 무료로 다운로드하여 사용할 수 있으며 MultiPoint 응용 프로그램은 모든 Windows® 기반 컴퓨터에서 실행할 수 있습니다(microsoft.com/downloads 참조).
Unlimited Potential에 의해 제공되는 프로그램 중 하나인 MultiPoint SDK의 목표는 가능한 많은 학생들에게 PC의 가치를 널리 알리는 것이며, 이러한 목적을 달성하기 위해서는 여러분의 도움이 필요합니다. MultiPoint를 활용한 교육 응용 프로그램을 직접 체험해 보려면 연락 주시기 바랍니다. 문의해 주시면 MultiPoint 웹 사이트 가입 링크를 제공해 드립니다.
Microsoft Research India 및 터미널 서비스 제품 팀에서는 화면 분할을 통해 두 명의 사용자가 두 개의 키보드와 마우스를 각각 따로 사용할 수 있는 색다른 PC 공유 방법을 연구하고 있습니다. 이 경우 모니터가 두 부분으로 분할되므로 각 부분에서 운영 체제 세션을 따로 실행할 수 있습니다.

Kentaro Toyama는 Microsoft Research India(research.microsoft.com/india)의 상무보 및 전 세계적으로 경제적 빈곤 지역을 대상으로 기술을 개발하는 Technology for Emerging Markets 그룹(research.microsoft.com/research/tem)의 책임 연구원입니다.


 Windows Confidential: 구식이 된 16비트 아이콘
Windows Confidential
구식이 된 16비트 아이콘
Raymond Chen

2008년 2월호 Windows Confidential 칼럼에서 이야기한 것처럼 Windows®에서는 여러 기능이 사라집니다. 이러한 작업은 대개 인식할 수 없을 정도로 매우 천천히 대규모로 진행되며 기능이 완전히 사라질 때마다 제품 팀에서는 이를 조용히 축하하는 정도로만 끝냅니다. Windows Vista®에서 사라진 기능 중 하나는 32비트 코드에서 16비트 모듈(대개 16비트 EXE 및 16비트 DLL)에 저장된 아이콘에 액세스하는 기능입니다.
이 사실을 알고 흥분하기 전에 16비트 코드에서는 여전히 16비트 모듈에 저장된 아이콘을 아무 문제 없이 액세스할 수 있다는 점을 명심하십시오. 이러한 과정은 16비트 에뮬레이션 계층 내에서 모두 처리됩니다. 사라진 기능은 16비트 모듈에 저장된 아이콘을 32비트 코드에서 액세스하는 기능입니다. 더 구체적으로 설명하자면 ExtractIcon 함수 같은 32비트 아이콘 추출 함수에서 16비트 DLL의 아이콘을 로드하는 기능이 사라졌습니다.
16비트 모듈에서 아이콘을 추출하는 32비트 코드는 FindResource와 같은 고급 커널 함수를 사용하여 파일에서 아이콘을 찾지 않습니다. 대신, 이 코드는 16비트 모듈 헤더를 구문 분석하고 리소스 테이블을 찾은 후 리소스 테이블을 구문 분석하여 원하는 아이콘 리소스를 찾는 자체적인 미니 로더를 구현해야 합니다. 이러한 작업을 모두 수행한 후에만 32비트 코드에서 최종적으로 픽셀을 아이콘으로 변환할 수 있습니다.
상상할 수 있듯이 이 작업을 수행하는 코드는 매우 구식이며 오류가 발생하기 쉽습니다. 즉, 실수나 악의적인 의도로 손상될 수 있는 바이너리를 구문 분석할 때 오류가 발생할 가능성이 많습니다. 열기 및 공유 모드가 달라지면 그에 따라 네트워크 캐싱 효과가 달라지기 때문에 성능 팀에서는 네트워크 성능을 향상할 수 있도록 파일을 여는 방식을 변경해 줄 것을 요청하는 경우가 있습니다. 그리고, 안정성 팀에서는 메모리 매핑 파일을 사용하지 않는 방식으로 구문 분석 코드를 다시 작성하도록 요청할 수 있습니다. 결국 이러한 코드를 유지 관리하는 비용이 해당 코드가 제공하는 가치를 넘어서게 됩니다. 따라서 누가 계속 16비트 프로그램을 작성하겠습니까?
사용 중인 16비트 프로그램은 16비트 에뮬레이션 계층이 존재하는 한 계속 실행됩니다. 물론, 64비트 Windows Vista에는 16비트 에뮬레이션 계층이 없습니다. 그렇다고 이것이 Windows XP에서 후퇴된 버전은 아닙니다. 64비트 Windows XP에도 16비트 에뮬레이션 계층은 없으니까요. 즉, 더 나아진 것도, 더 나빠진 것도 없습니다.
Windows Vista에서는 32비트 프로그램에서 ExtractIcon을 실행하여 16비트 DLL의 아이콘을 가져오는 기능만 없어졌습니다. 시작 메뉴에 16비트 프로그램에 연결된 바로 가기가 있는 경우 Windows 탐색기가 더 이상 이 16비트 프로그램의 기본 EXE에서 아이콘을 추출할 수 없기 때문에 해당 바로 가기의 아이콘이 일반 프로그램 아이콘으로 나타납니다. 이외에 크게 잃는 것은 없습니다. 하지만 이 문제가 마음에 걸린다면 바로 가기 속성을 편집하여 다른 32비트 모듈의 아이콘을 지정할 수 있습니다.
이 상실된 기능 때문에 문제가 발생하는 것을 확인한 경우는 단 한 가지로, 특정 아이콘 편집 도구로 만든 아이콘 라이브러리에서 발생한 문제였습니다. 무슨 이유인지 모르겠지만 해당 프로그램은 아이콘을 기본적으로 16비트 DLL의 리소스로 저장합니다. 따라서 더 이상 32비트 코드에서 이러한 아이콘에 액세스할 수 없습니다. 물론, 이 문제를 해결하는 쉬운 방법은 해당 아이콘 라이브러리를 32비트 DLL의 리소스로 다시 저장하는 것입니다.
아직은 아닐 수 있겠지만 결국 누군가 16비트 DLL에서 모든 아이콘을 추출하여 해당 아이콘이 포함된 32비트 리소스 전용 DLL을 만드는 간단한 프로그램을 작성할 것입니다. 그렇게 되면 16비트 DLL에 있는 오래된 아이콘을 사용하는 사람들이 시작 메뉴의 바로 가기에 해당 아이콘을 계속 사용할 수 있게 될 것입니다. 하지만, 여러분이 그러한 프로그램을 작성해도 실제로 그것을 필요로 하는 사용자를 찾지 못할 것이라는 이야기를 할 수 밖에 없을 것 같네요. Windows 사용자 인터페이스 팀에 들어온 요청 중에서 그러한 프로그램을 요청한 경우는 단 한 번도 없었으니까요.

Raymond Chen은 자신의 웹 사이트 The Old New Thing에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있으며 동명의 저서에서도 이에 대해 다루었습니다. 그는 닫힌 문은 멀리합니다.