 TechNet Magazine July 2007

TechNet Magazine July 2007

Communications: Exchange Server 2007의 데이터 보호 및 재해 복구

Exchange Server 2007에는 고가용성 및 재해 복구를 지원하는 많은 옵션이 포함되어 있습니다. Exchange가 제공하는 많은 대안 기술을 살펴보고 조직에 가장 적합한 복구 솔루션을 계획해 보십시오.

Lee Benjamin Communications: Windows Mobile 6의 보안 향상

스마트 폰과 PDA로 사무실 밖에서도 네트워크에 액세스할 수 있지만 이로 인해 새로운 네트워크 취약점이 발생할 수도 있습니다. 여기에서는 Windows Mobile 6 및 Exchange Server를 통해 회사의 모바일 장치와 인프라를 보호하는 방법에 대해 살펴봅니다.

Matt Fontaine Communications: 공용 폴더에 대한 강력한 대안

MOSS 2007은 Exchange 공용 폴더보다 더 향상된 기능과 편리한 관리 방식을 갖춘 강력한 데이터 공유 솔루션을 제공합니다. 이 기사에서는 SharePoint를 사용하여 일정, 연락처 및 문서를 공유하는 방법에 대해 살펴보겠습니다.

Alan Maddison Communications: 스마트 카드를 이용한 Outlook Web Access 로그온

견고하지 못하고 쉽게 노출되는 암호는 보안 사슬에서 가장 취약한 연결 고리 가운데 하나입니다. 이 문서에서는 모바일 사용자를 대상으로 스마트 카드를 이용한 2단계 인증 방식을 구현함으로써 전자 메일 보안을 개선하는 방법을 보여 줍니다.

Victor Akinnagbe, Ted Dressel, and Jason Opdycke Windows Administration: Windows Vista의 ActiveX Installer 서비스

응용 프로그램의 호환성을 제한하지 않으면서 악성 ActiveX 컨트롤로부터 데스크톱의 보안을 유지하려면 어떻게 해야 할까요? Windows Vista의 AxIS(ActiveX Installer 서비스)를 사용하면 기존과 다른 새로운 방법으로 ActiveX 컨트롤을 관리하여 이러한 문제를 해결할 수 있습니다. 지금부터 AxIS에 대해 살펴보겠습니다.

Rob Campbell and Joel Yoker From The Editor: 여섯 다리 건너면 다 아는 사이

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

Greg Steen SQL Q&A: 클러스터링의 작동 원리, 원인을 알 수 없는 지연, SA 계정 외

Edited by Nancy Michell Utility Spotlight: SMSMap

Jeff Tondt How IT Works: RPC 오류 문제 해결

Zubair Alexander The Cable Guy: VPN 연결을 통한 IPv6 트래픽

Joseph Davies Windows PowerShell: 파이프라인 다시 살펴보기

Don Jones Hey, Scripting Guy!: 스크립트도 겉모양이 중요하다!

The Microsoft Scripting Guys Exchange Queue & A: Edge 및 Hub 전송 역할, 가상 컴퓨터 및 기타 정보

KC Lemson and Nino Bilic Security Watch: ACL 관리 도구

Jesper M. Johansson The Desktop Files: Microsoft Desktop Optimization Pack

Wes Miller Windows Confidential : 안전 모드의 강력한 복구 성능

Raymond Chen


 Communications: Exchange Server 2007의 데이터 보호 및 재해 복구
Communications Lee Benjamin

Exchange Server 2007의 데이터 보호 및 재해 복구
한 눈에 보기:
  • 기본 백업 및 복원
  • 데이터 연속성
  • 복제 기술
  • 대체 솔루션

Microsoft Exchange Server는 백업을 고려하여 설계되었습니다. 조직은 메시징 데이터를 백업해야 하며 이러한 정보를 복원할 수도 있어야 합니다.
이러한 요구에 부응하기 위해 Microsoft는 낮은 수준의 기존 백업 및 복원에서 작업 연속성, 그리고 최고 수준의 가용성 및 재해 복구를 제공하는 진정한 비즈니스 연속성 솔루션에 이르기까지 모든 범위를 포괄하는 데이터 보호 옵션을 선보이게 되었습니다. 이 문서에서는 이러한 옵션을 하나씩 살펴보고 조직에 가장 적합한 Exchange 복구 솔루션을 구현하는 방법을 찾는 데 도움이 되는 정보를 제공합니다.

수준 1: 기본 백업 및 복원
Exchange 데이터베이스를 오프라인으로 전환하여 Exchange 파일을 백업할 수도 있고 Exchange가 실행되는 동안에 파일을 백업할 수도 있습니다. 사실 온라인 백업이 가장 권장되는 Exchange 백업 방법입니다. 그런데 Exchange는 단순한 파일 모음 그 이상이며, 대용량 데이터베이스 파일과 트랜잭션 로그를 포함하는 정보 저장소입니다. Exchange로 전송된 메시지는 즉시 트랜잭션 로그에 기록되며 시스템에 여유 주기가 있을 때(일반적으로 몇 밀리초 후) 메시지가 데이터베이스 자체에 복사됩니다. Exchange는 정보를 가능한 한 빨리 디스크로 가져옴으로써 매우 높은 수준의 복구 성능을 제공합니다. Exchange 복원에서 중요한 것은 데이터베이스 파일과 트랜잭션 로그라는 두 정보 집합의 가용성입니다. 시스템에 오류가 발생할 경우 가장 최근 정보로 Exchange를 복원할 수 있게 해 주는 것은 바로 이전 백업과 오류 발생 시점 이후부터의 모든 트랜잭션입니다. Exchange는 필요한 경우 복원된 데이터베이스에 트랜잭션을 자동으로 재생합니다.
백업 프로그램은 ESE(Extensible Storage Engine) 백업 API 또는 새로운 VSS(볼륨 섀도 복사본 서비스) 솔루션을 통해 Exchange 데이터베이스의 정보에 액세스합니다. VSS 솔루션에 대해서는 뒤에서 자세히 설명하겠습니다. ESE 백업이 시작될 때마다 Exchange는 데이터베이스에 대한 모든 쓰기를 임시로 일시 중단합니다. ESE는 데이터베이스를 임시로 읽기 전용 모드로 설정하여 데이터베이스가 전체 백업에 복사될 수 있도록 하는 동시에 백업 중 발생하는 새 트랜잭션을 임시 데이터베이스에 보관합니다. 백업이 완료되면 ESE는 데이터베이스를 원래의 읽기/쓰기 모드로 되돌리고 임시 데이터베이스에 누적된 트랜잭션을 적용합니다. 이전 트랜잭션 로그는 백업 프로세스가 완료될 때 제거됩니다.
이러한 백업 프로세스는 매우 단순하며 야간에 백업이 한참 진행 중일 때 로그온한 사용자조차도 알지 못하게 수행되지만 ESE가 완료되기까지 매우 오래 걸릴 수 있습니다. 특히, Exchange 데이터베이스의 크기가 몇 GB에서 관리 가능한 30-50GB나 심지어는 100GB에 이를 경우에는 시간이 더욱 많이 소요됩니다. 크기가 이렇게 크면 표준 기술을 사용해서는 야간에 백업을 완료하는 것이 어렵습니다. NTBackup.exe를 사용할 경우 선택할 수 있는 옵션을 보려면 그림 1을 참조하십시오.
그림 1 NTBackup 유틸리티 사용
그림 1 NTBackup 유틸리티 사용

Exchange에 적용할 수 있는 최선의 방법
일반적인 하드웨어 및 시스템 오류로부터 신속하게 복구할 수 있으려면 매일 밤 Exchange 전체 백업을 실행해야 합니다. Exchange 서버가 로컬 디스크를 사용할 때마다 성능 및 복구 능력을 개선하려면 독립된 RAID 배열을 사용하여 Exchange 데이터베이스와 Exchange 트랜잭션 로그를 저장하는 것이 중요합니다. 이렇게 하면 한 RAID 배열 컨트롤러에 오류가 발생하거나 배열에 있는 둘 이상의 디스크에 오류가 발생하여 나머지 디스크가 스트라이프 데이터를 다시 구성할 수 없는 경우에도 복구가 가능합니다. 트랜잭션 로그가 손실된 경우에는 다른 드라이브에 최신 Exchange 데이터베이스가 저장되어 있으므로 새 트랜잭션 로그를 사용하여 정상적으로 작업을 계속할 수 있습니다. 데이터베이스 드라이브가 손실된 경우에는 전날 밤의 Exchange 데이터베이스 전체 백업을 가져온 다음 당일 트랜잭션 로그를 적용하여 데이터베이스를 최신 상태로 업데이트하는 복구 방법을 실행할 수 있습니다.
적절한 시간 내에 백업, 그리고 더 중요한 복원이 가능하도록 각 Exchange 데이터베이스의 크기를 제한하는 것 또한 매우 중요합니다. 대부분의 조직에서는 데이터베이스 크기를 30에서 50GB 사이로 유지하는 것이 좋습니다. 데이터베이스의 크기가 이보다 커지면 복원을 손쉽게 수행할 수 있도록 여러 개의 데이터베이스로 나누는 것이 좋습니다.

백업 및 복원 연속선
데이터베이스와 트랜잭션 로그의 배치는 백업 성능뿐만 아니라 복구 속도를 위해서도 매우 중요합니다. 요즘에는 모든 서버에서 RAID라고 하는 다양한 계층의 디스크 드라이브 중복을 지원합니다. 기본적으로 RAID는 디스크 드라이브에서 오류가 발생하더라도 시스템이 중단되지 않도록 해 줍니다. 그러나 해당 디스크를 교체하고 다시 빌드할 때까지 시스템 성능이 저하됩니다. 그 전까지는 배열 컨트롤러가 각 디스크 액세스 요청에 응답하여 즉시 나머지 디스크에서 데이터를 다시 구성해야 합니다. 사서함 서버 저장소 설계에 대한 자세한 내용은 Microsoft IT Showcase 백서인 "64비트에서 Exchange Server 2007 사용"을 참조하십시오.
Exchange의 가장 두드러진 특징은 단일 인스턴스 데이터베이스 설계입니다. 이는 한 Exchange 데이터베이스 내에 특정 메시지의 단일 복사본만 단일 첨부 파일(있는 경우)과 함께 저장된다는 것을 의미합니다. 해당 메시지가 동일한 정보 저장소에 있는 여러 명의 받는 사람에게 전송되는 경우에는 해당 개체(메시지, 첨부 파일)에 대한 추가 포인터가 만들어지고 개체 자체는 복제되지 않습니다. 이로써 Exchange의 배달 효율성이 극대화될 뿐만 아니라 Exchange에서 사용하는 디스크와 테이프의 저장 공간 또한 절약됩니다.
Exchange의 전체 데이터베이스 복원 성능은 매우 우수하지만 개별 사서함, 폴더 또는 메시지를 복원하려면 먼저 전체 테이프를 복원해야 하는 단점이 있습니다. 따라서 사용자는 이보다 세분화된 복원 기능을 원합니다. 그러나 테이프에는 단일 인스턴스만 있으므로 세분화하기 매우 어렵습니다. 백업 공급업체에서 브릭 수준 백업(Brick-Level Backup)을 통해 이러한 요구에 부응했지만 필자는 이 방법을 권장하지 않습니다. 이 방법은 입증된 ESE 백업 API를 사용하여 Exchange 데이터베이스의 전체 백업이 만들어지면 백업 테이프에 각 사서함을 추가합니다. 그런데 백업 API는 개별 사서함에서 데이터를 가져오는 방법을 제공하지 않으므로 MAPI가 사용되고, 그 결과 모든 메시지와 첨부 파일이 복제되므로 백업 테이프가 상당히 길어지게 됩니다.
Microsoft는 이 문제를 부분적으로 해결하기 위해 몇 가지 기능을 개선했습니다. 예를 들어 관리자의 휴지통에는 사용자가 항목을 삭제한 후 항목이 다시 필요할 경우에 대비하여 일정 기간 동안 항목이 보관됩니다. 뿐만 아니라 이제 더 이상 Exchange 복구 포리스트로 예비 서버를 배치할 필요가 없습니다. 관리자가 복구 저장소 그룹을 통해 테이프에서 가져온 복원 데이터베이스를 부분적으로 마운트할 수 있게 되었으며 사서함 수준까지 데이터를 복사하거나 병합할 수 있게 되었습니다.

실패는 성공의 어머니
대부분의 조직은 결정된 백업 및 복구 수준에 관계없이 백업 미디어와 복구 절차를 정기적으로 테스트해야 한다는 사실을 비싼 대가를 치른 후에야 깨닫게 됩니다. 너무도 많은 관리자가 오류가 발생한 뒤에야 백업 기술과 복원 절차가 실제로 작동하는지 알게 됩니다. 테스트하기 가장 좋은 때는 새 서버를 빌드하고 구성한 바로 다음 날입니다. 즉, 새 서버가 Exchange 구성의 일부로 실행되지만 이를 사용하는 사용자가 얼마 되지 않을 때가 적기라고 할 수 있습니다. 이때는 Exchange 전체 백업과 드라이브에 대한 정기 백업을 수행해야 합니다. 또한 시스템 디스크의 중요한 파일과 IIS 메타베이스(Exchange 라우팅 구성이 보관되는 곳)가 들어 있는 시스템 상태를 캡처해야 합니다. 그런 다음 새 서버를 다시 포맷하고 다시 시작하여 서버를 처음 빌드할 때 기록한 내용을 업데이트합니다. 이렇게 하면 시스템 상태에서 설정을 복원할 수 있을 뿐만 아니라 시스템 구성 설정을 수동으로 다시 구현할 수 있도록 적절한 문서도 마련할 수 있게 됩니다.
이 재난 대비 훈련에 투자한 시간은 향후 복구에 걸리는 시간을 대폭 줄여줄 것입니다. 이 절차를 정기적으로 반복하는 것이 좋습니다. 이 작업을 수행하는 동안 오프사이트에서 테이프를 가져오는 데 걸리는 시간을 생각해 보십시오. 끝이 없을 것 같은 이 시간을 겪어 본 사람은 대개 자신의 백업 및 복원 전략에서 디스크 대 디스크 백업이 얼마나 중요한지에 대해 진지하게 고려하게 됩니다. 오프사이트 테이프 저장소가 여전히 재해 복구를 위한 궁극적인 안전 장치임에도 불구하고 말이지요.

테이프 백업의 문제
테이프에서 복원하는 데는 너무 많은 시간이 소요됩니다. 이제 Exchange는 사용자와 관리자가 항상 사용할 수 있어야 할 만큼 조직에서 중요한 역할을 하게 되었습니다. 심각한 문제가 발생하면 대부분의 조직은 대혼란에 빠집니다. 누구도 테이프에서 75GB의 데이터베이스를 복원하는 데 8시간이 걸린다는 사실을 받아들이려 하지 않습니다. 여기에는 오프사이트 저장소 시설에서 테이프를 가져오거나 운영 체제를 다시 설치하는 데 걸리는 시간은 포함되어 있지 않은데도 말입니다.
또한 테이프에서 올바른 데이터베이스를 검색해야 하는 문제도 있습니다. Exchange가 처음 릴리스된 이후 10년 동안 디스크 저장소와 WAN의 비용도 많이 저렴해져 대부분의 조직은 더 빠른 백업 및 복원 방법을 사용할 수 있게 되었으며, Exchange 인프라에 대해 작업 연속성 및 재해 복구 기능을 사용할 수 있는 기술을 활용하는 것이 가능해졌습니다.

수준 2: 작업 연속성
작업 연속성이란 복구 작업을 최대한 빠르게 수행할 수 있도록 하고 예기치 않은 작동 중단 시간을 최소화하는 일련의 프로세스와 기술입니다. 로컬 복구의 경우 작업 연속성을 통해 테이프에 비해 향상된 RTO(복구 시간 목표)와 RPO(복구 시점 목표)를 달성할 수 있습니다. 또한 작업 연속성에서는 가능한 한 테이프를 온사이트로 가져오는 시간을 줄이기 위해 노력합니다. 그림 2를 보면 백업, 복원 및 DR(재해 복구)을 작업 연속성과 비교할 수 있습니다.
그림 2 복구 연속선
그림 2 복구 연속선
이 다이어그램은 왼쪽 아래의 느리고 저렴한 방식부터 오른쪽 위의 빠르고 비용이 많이 드는 방식에 이르는 복구 및 가용성 옵션의 연속선을 보여 줍니다. 여기에서 작업 연속성과 재해 복구 솔루션 간의 전환 경계는 명확하지 않습니다.
이 그래프를 보면 각 접근 방법에 따르는 비용, 복구 시간 및 가용성을 쉽게 비교해 볼 수 있습니다. 이 문서에서 필자는 로컬 연속성 프로세스와 재해 복구를 의도적으로 명확하게 구분했는데, 그 이유는 DR이 항상 오프사이트의 데이터를 가져오는 것을 주요 목표로 하는 원격 작업으로 간주되기 때문입니다. 거리로 인해 추가적인 작업이 필요하고 일반적으로 비용이 많이 들기도 하는 DR은 재해가 발생한 후의 비즈니스 연속성과 관련됩니다. 이에 대해서는 나중에 보다 자세히 다루겠습니다.

간단한 역사
Exchange가 인프라의 보다 중요한 부분을 차지하게 되고 Exchange 데이터베이스에 더 많은 정보가 저장됨에 따라 백업 및 복원 시간을 줄여야 하는 필요성 또한 절실해졌습니다. 몇몇 대규모 조직은 Microsoft와 협력하여 부분적인 작업을 크게 개선하는 한 가지 방법을 발견하게 되었습니다. 이 방법을 사용하면 오류가 발생해도 외부 세계와 새 전자 메일을 계속해서 주고 받을 수 있으므로 아무 일도 없는 것처럼 보일 수 있습니다. 결국 중요한 것은 겉으로 보이는 사실입니다.
Exchange에 이러한 "다이얼톤" 복원을 구현하기 위해 손상된 데이터베이스 대신 비어 있는 새 데이터베이스를 배치했습니다. 그런 다음 Exchange와 Active Directory®에서 적절한 권한으로 새 사서함을 만들었으며 사용자는 아무 일도 없는 것처럼 전자 메일을 주고 받을 수 있었습니다. 백업 테이프를 검색하고 데이터를 복구하고 나서 이를 관리적으로 마운트할 수 있었으며, 다음에는 Exchange 관리자가 복원된 사서함을 다이얼톤 사서함에 병합했습니다. 필요한 경우 사서함의 우선 순위를 정할 수도 있었습니다. 이러한 개선에도 불구하고 이 프로세스는 처음에는 EXMERGE를 사용하고 그런 다음 복구 저장소 그룹에 적용되었으므로 시간이 많이 걸리고 복잡했습니다. 그런데 다이얼톤 복구 시나리오 후 전체 데이터 복원은 매우 힘들고 복잡한 작업이라는 점에 유의해야 합니다. 특히, Exchange 2007에서는 저장소 그룹을 최대 50개까지 사용할 수 있다는 점을 감안하면 더욱 그렇습니다. 따라서 다이얼톤 복구 시나리오를 구현할지 고려 중이라면 여기에 드는 시간과 노력에 비해 그 결과가 충분히 만족스러운지를 먼저 확인할 필요가 있습니다.

볼륨 섀도 복사본 서비스
저렴한 디스크를 활용하고 프로덕션 Exchange 서버에서 프로세서 오버헤드를 없애기 위해 Microsoft® Windows Server® 2003 및 Exchange용의 새로운 백업 API가 개발되었습니다. 데이터에 대한 일관된 지정 시간 복사본을 만들기 위해 VSS(볼륨 섀도 복사본 서비스)가 만들어졌습니다. 이 서비스에서 만들어진 스냅숏은 Exchange 데이터에 대한 읽기 전용 복사본으로, 변경된 데이터만 연속적으로 포함합니다. 이들 복사본은 대개 사용할 수 있는 디스크 공간이 있는 다른 서버 또는 SAN(저장 영역 네트워크)을 가리킵니다. 백업은 테이프에 저장하고, 스냅숏을 여러 개 유지할 수 있습니다. 따라서 프로덕션 Exchange 서버가 더 이상 백업 소프트웨어 및 테이프 복사 오버헤드로 인해 성능에 영향을 받지 않게 되었습니다.
Exchange 데이터 보호를 위해 VSS를 사용하는 경우 몇 가지 장점이 있습니다. 첫째, 테이프 백업 작업으로 인한 성능 로드를 Exchange 서버에서 줄일 수 있습니다. 테이프 백업을 여전히 수행해야 하기는 하지만 Exchange 데이터의 복사본을 사용할 수 있으므로 사용자 성능에는 영향을 주지 않습니다. 둘째, 야간에 한 번 백업할 때보다 자주 스냅숏을 만들 수 있습니다. 뿐만 아니라 보조 서버나 다른 로컬 저장소에 여러 개의 스냅숏을 보관할 수도 있습니다.
VSS 스냅숏 기능을 사용하는 많은 타사 제품이 시장에 출시되어 있습니다. 단순히 Exchange 데이터베이스를 백업 및 복원하는 데 걸리는 시간만 줄여주는 제품도 있고, Exchange에 포함된 기본 복구보다 세분화된 복구 기능을 제공함으로써 사서함 수준의 복원을 가능하게 하는 제품도 있습니다. 누구도 브릭 수준 백업과 같은 백업 방법을 선호하지는 않지만, 특정 폴더, 심지어는 메시지 하나만 복원할 수 있는 방법을 원하는 것도 사실입니다.

복제 기술
소프트웨어를 활용한 Exchange 장애 조치는 몇몇 복제 공급업체가 제공하는 방법입니다. 이 방법을 사용하는 경우 대기 Exchange 서버를 실행하고 모든 사용자의 사서함이 이동되었음을 Active Directory에 알려 줘야 합니다. 이를 달성하는 방법은 두 가지인데 어떤 방법을 사용하든 Exchange 및 Windows 환경을 어느 정도 사용자 지정해야 합니다. 첫 번째 방법에는 대기 서버가 오류가 발생한 서버의 이름과 IP 주소를 사용하도록 DNS를 조작하는 작업이 필요합니다. 이 경우 Outlook®이 여전히 동일한 서버를 사용하고 있는 것으로 인식하므로 이 방법은 클라이언트 워크스테이션에서 사용하기에 좋습니다.
두 번째 방법은 데이터베이스의 복사본만 있고 어떤 것도 마운트되어 있지 않은 Exchange를 실행하는 대기 서버를 사용합니다. 오류가 발생하면 대기 서버가 모든 사용자의 사서함이 이동되었음을 Active Directory에 알려 줍니다. 그런 다음에는 클라이언트가 다른 메일 서버에 있음을 클라이언트에게 알려 주는 스크립트를 실행하거나 그룹 정책을 배포합니다. Outlook 2007은 Active Directory를 인식하므로 이러한 매핑을 스스로 자동 인식하며, 따라서 이 프로세스가 훨씬 수월하게 수행됩니다.

MSCS를 사용한 로컬 클러스터링
Microsoft Cluster Services(MSCS)는 가용성 연속선상에서 상위에 위치하는 제품이며, Exchange는 클러스터를 인식하는 응용 프로그램입니다. 클러스터링은 둘 이상의 컴퓨터 간에 정보를 공유하므로 한 컴퓨터에서 오류가 발생하면 다른 컴퓨터가 작업을 대신 수행할 수 있습니다. 현재 사용되는 대부분의 Exchange 클러스터는 2개 또는 4개의 노드로 구성되며 최대 8개의 노드를 사용할 수 있습니다. 이 중 한 개의 노드는 항상 패시브로 지정되며, Windows Server를 실행하고 Exchange Server가 설치되어 있지만 활성 사서함은 없습니다. Exchange 2003에서는 2노드 액티브/액티브 클러스터를 구현하는 것이 가능했지만 성능 로드로 인해 현재는 권장되지 않으며 Exchange 2007에서는 지원되지 않을 것입니다.
Exchange 2003 클러스터 배열과 마찬가지로 패시브 노드가 포함된 Exchange 2007 클러스터도 단일 공유 저장소 배열을 계속해서 사용할 수 있습니다. 클러스터 품질의 저장소 배열은 일반적으로 다양한 유형의 장애에 견디기 위해 여러 가지 중복 기능을 갖추고 있기는 하지만 데이터의 복사본을 하나만 제공하므로 취약한 영역이 남아 있다고 할 수 있습니다. 이 때문에 이러한 클러스터는 SCC(단일 복사본 클러스터)라고 하며 Exchange 2007의 MCC(다중 복사본 클러스터)와 함께 제공될 차세대 데이터 보호 기술과 구별됩니다. MCC에 대해서는 재해 복구에 대해 살펴볼 때 설명하겠습니다.

로컬 연속 복제
LCR(로컬 연속 복제)은 Exchange 데이터베이스와 트랜잭션 로그의 두 번째 복사본을 동일한 서버 내에 유지하는 Exchange 2007의 새로운 기능입니다. LCR은 Exchange 데이터베이스와 트랜잭션 로그를 서로 별개의 RAID 배열에 배치하는 기존의 방법에 중복 계층을 추가로 제공합니다. LCR을 사용하면 로그의 보조 복사본을 데이터베이스의 주 복사본이 저장된 배열에 저장하고, 데이터베이스의 보조 복사본을 로그의 주 복사본이 저장된 배열에 저장할 수 있습니다(그림 3 참조). 이 경우 RAID 컨트롤러나 배열에서 오류가 발생하더라도 다른 배열에 데이터베이스와 트랜잭션 로그가 저장되어 있으므로 걱정할 필요가 없습니다. 다소 불안하고 성능도 약간 저하되긴 하지만 오류가 발생한 배열을 다시 빌드할 때까지 작업을 계속할 수 있습니다.
그림 3 LCR 구성
그림 3 LCR 구성
LCR은 백업 솔루션이 아니라 로컬 작업 연속성 솔루션이므로 전체 백업 전략이 여전히 필요합니다. LCR을 사용하는 경우 서버가 데이터베이스와 트랜잭션 로그의 복사본을 두 개씩 만들게 되므로 성능이 저하될 수도 있습니다. 또한 Exchange 2007 구현의 경우 LCR은 한 저장소 그룹에서 데이터베이스를 하나만 지원하고 한 조직에서 공용 폴더 데이터베이스를 하나만 지원하기 때문에 소규모 조직에만 적합하게 만드는 여러 가지 제약이 있습니다.
LCR 복구를 사용한 장애 조치는 즉각적이지 않습니다. 숙련된 IT 전문가가 스크립트를 실행하여 Exchange 백업을 가져와야 하며, 이 프로세스에는 Exchange 관리 콘솔 외부에서 실행되는 Exchange 관리 셸 명령이 필요합니다.
Exchange Server 2003 Enterprise Edition에서는 최대 20개의 Exchange 데이터베이스(각각 5개의 데이터베이스가 있는 네 개의 저장소 그룹)를 실행할 수 있으며 Exchange 2007 Enterprise Edition에서는 각각 고유한 데이터베이스를 갖춘 최대 50개의 저장소 그룹을 실행할 수 있습니다. 트랜잭션 로그 파일의 크기가 Exchange 2003에서는 5MB였지만 Exchange 2007에서는 1MB로 줄었습니다. 이러한 변경은 모두 LCR을 지원하기 위한 것이며 아울러 이와 어느 정도 연관성이 있는 CCR(클러스터 연속 복제)을 지원하기 위한 것입니다.
중소 규모의 조직은 LCR을 사용하여 Exchange 작업에 대한 데이터 보호를 개선할 수 있습니다. LCR은 구현하기가 쉽지만 수동 작업도 필요합니다. 동일 서버/로컬 디스크 솔루션으로서의 LCR은 더 나은 작업 연속성으로 나아가기 위한 첫 걸음에 불과합니다. LCR은 RAID 배열 및 RAID 컨트롤러의 오류로부터 데이터를 보호하지만 동시다발적으로 디스크의 작동이 중단되거나 RAID 컨트롤러에 오류가 발생하는 경우는 흔하지 않습니다. 대부분의 오류 시나리오에는 전체 서버가 중단되는 상황이 포함되며 이를 처리하기 위해 Exchange를 보호하기 위한 추가 단계가 필요합니다.

타사 로컬 오프 호스트 복제
Exchange의 복구 기능을 더욱 향상시키기 위해 타사 공급업체들은 Exchange 로그 파일을 사용하여 Exchange 데이터베이스의 예비 복사본을 다른 컴퓨터에 보관하는 "오프 호스트" 복제 기술을 활용하는 제품을 개발했습니다. 이 경우 데이터 보호 또는 보관 솔루션은 ESE를 통해 다른 컴퓨터에 Exchange 전체 백업을 수행한 다음 트랜잭션 로그가 닫히는 즉시 트랜잭션 로그를 가져옵니다. 그런 다음 이러한 트랜잭션을 Exchange 데이터베이스 복사본에 삽입하여 복사본을 항상 최신 상태로 유지합니다. 앞에서 설명했듯이 이러한 로그는 크기가 상대적으로 작습니다. Exchange 2003의 경우 5MB이고 Exchange 2007의 경우 1MB입니다. 따라서 전체 백업이 완료된 후 이러한 로그 파일을 오프 호스트 서버에 복사하는 데는 오버헤드가 거의 발생하지 않습니다.

수준 3: 재해 복구 및 고가용성
재해 복구란 주 데이터 센터가 사용 불가능해질 경우 이를 원상 복구하여 실행하는 능력을 말합니다. 요즘에는 대부분의 조직에서 전자 메일 및 일정 기능이 핵심 기능이기 때문에 Exchange에는 효과적인 재해 복구를 적용할 필요가 있습니다.
일부 회사는 오프사이트에 저장된 기존의 테이프 백업이 일종의 재해 복구라고 생각합니다. 그런데 화재나 홍수로 인해 유일한 데이터 센터가 훼손되고 테이프만 한 트럭 남는다면 아무 쓸모가 없을 것입니다. 재해 복구에는 데이터를 다른 위치로 이동하는 것뿐만 아니라 응용 프로그램을 원상 복구하여 실행하는 기술 및 프로세스가 포함되어야 합니다. 재해 복구가 효과적으로 이루어지기 위해서는 주 시스템과 보조 시스템을 일정한 거리를 두고 분리해야 합니다. 두 사이트의 거리는 대비해야 할 재해의 규모에 따라서 다릅니다. 화재가 우려된다면 구내의 다른 건물만으로도 충분합니다. 그러나 열차나 비행기로 인해 인프라 자체에 피해가 발생하는 경우에는 반경 1.5km 이상까지 영향을 받을 수 있습니다. 홍수, 폭풍우, 지진, 정전 등 대부분의 재해는 지역적입니다. 통신에도 고유의 재해가 발생할 수 있습니다. ISP에 대한 연결을 끊는 굴착기에서 DoS(서비스 거부) 공격, 그리고 주로 상거래 조직을 대상으로 하는 인터넷 DoS 공격에 이르기까지 다양한 재해가 발생할 수 있습니다.
현실적으로 조직에 IT 직원이 있는 사이트가 둘 이상이라면 대비하려는 재해의 유형에 관계없이 이러한 위치 중 하나는 원격 작업 연속성을 위한 고유의 기준을 만족했을 것입니다. 자체 설비와 직원을 활용하는 것이 재해 복구 공급업체와 계약을 맺거나 새 위치에 장소를 임대하는 것보다 비용이 훨씬 저렴합니다.
재해 복구는 궁극적으로는 인식과 관련된 것입니다. 즉, 비즈니스를 계속 수행하고 있다는 확신을 고객에게 심어주는 것입니다. 한 도시나 지역에서 재해가 발생했음을 사람들이 알고 있는데 회사가 며칠 또는 한 주 내에 온라인 상태로 복구되지 않으면 고객과 공급업체는 최악의 상황을 가정하게 됩니다. 즉, 재해로 인해 대부분의 회사가 정상적으로 운영되지 않는다고 믿게 됩니다. 고객에게는 작업이 복구되고 있는 것으로 보여야 합니다. 그래야만 비즈니스가 계속되고 있다고 확신시킬 수 있습니다. 시기 적절한 복구와 관련하여 고객은 여러 가지 생각을 가질 수 있습니다. 당연히 고객은 사무용 가구 공급업체의 업무가 중단될 때보다 금융 서비스 회사의 업무가 중단될 때 더 초조해할 것입니다.

재해 복구 요구 사항
재해 발생 후 Exchange를 다시 온라인 상태로 만들려면 Exchange 데이터를 보조 사이트에 복제해야 하며 이러한 데이터를 언제든지 실행할 준비가 되어 있는 Exchange 대기 서버에 제공하는 복제 기술을 사용해야 합니다. 그런 다음 Outlook 클라이언트에 사서함이 이동되었음을 알려야 합니다.
Exchange는 복제 시 요구 사항이 많은 응용 프로그램이며, 특히 사이트 간의 거리가 멀 때 더욱 그렇습니다. 또한 진정한 트랜잭션 데이터베이스라고 할 수 있으므로 각 쓰기의 순서가 매우 중요합니다. Exchange는 서버 간에 모든 트랜잭션과 시스템 정보를 전달하는 데 SMTP 프로토콜을 사용하며 이 전송 프로토콜은 잘 알려진 대로 대역폭을 매우 많이 사용합니다. 바로 이 때문에 문제가 더욱 복잡해집니다. 더 나아가 Exchange 클러스터의 경우 시스템 간 하트비트 간격이 500밀리초로 유지되어야 합니다. 보조 노드가 이 하트비트를 수신하지 않으면 장애 조치를 시작하도록 트리거할 수 있습니다.
이러한 문제를 관리하는 것이 복잡하기 때문에 Microsoft는 Exchange 2007에 와서야 이 분야에 관심을 기울이게 되었습니다. Microsoft가 개입하기 전까지는 호스트 기반 또는 배열 기반 복제를 통해 Exchange 데이터를 복제하는 몇몇 타사 솔루션이 개발되었습니다.
공급업체들은 노드를 여러 위치로 분산시켜 클러스터를 확장하는 클러스터 확장이라는 기술을 발견했습니다. 현재 클러스터 확장을 구현하는 가장 일반적인 방법은 범용 타사 데이터 복제 제품이나 Exchange 노드를 확장할 목적으로 설계된 제품을 사용하는 것입니다. MSCS를 사용하면 이러한 목적을 달성할 수 있지만 WAN을 사용하는 경우 서브넷 요구 사항이 꽤 까다롭습니다. 클러스터링의 복잡성과 원격 데이터 센터에 대한 고대역폭 연결을 안정적으로 제공하는 데 따르는 어려움으로 인해 재해 복구 시스템을 빌드, 유지 관리 및 정기적으로 테스트하는 데 드는 비용과 인력이 점점 증가하고 있습니다.

클러스터 연속 복제
Microsoft는 Exchange 2007에서 CCR(클러스터 연속 복제)을 도입하여 클러스터 지원을 더욱 확장했습니다. CCR은 Exchange 데이터베이스와 트랜잭션 로그의 복사본 두 개를 유지 관리하는 LCR의 능력을 확장하여 두 개의 클러스터 노드에 동일한 개념을 구현합니다. 재해 복구는 주 시스템과 보조 시스템을 지리적으로 분리하는 것을 의미하는데, Microsoft MCC(다중 복사본 클러스터)로는 먼 거리를 연결할 수 없으며 이 문제는 Windows Server 2008(이전의 코드 이름 "Longhorn")에서 클러스터 확장이 가능해져야만 해결됩니다.
MCC 노드에 별개의 데이터 복사본을 보관할 수 있게 해 주는 기술을 MNS(주 노드 집합)라고 합니다. MNS는 데이터의 활성 복사본을 보관할 노드를 결정하기 위해 둘 이상의 노드가 참여하는 경합 프로세스를 나타냅니다. 오류가 발생할 경우 나머지 노드가 새 주 처리/데이터 서버의 역할을 맡을 노드를 결정하기 위해 새로운 경합 프로세스에 참여합니다. 이러한 기술 민주주의를 지원하는 것이 바로 각 노드의 데이터베이스를 최신으로 유지하는 CCR입니다. CCR을 사용하는 Exchange 2007 클러스터에서는 노드가 2개까지만 지원됩니다.
대규모 조직에서는 대개 Exchange 서버 자체에 로컬 시스템 디스크를 구성하고 SCSI, 파이버 또는 iSCSI 디스크 배열을 사용하여 SAN을 통해 Exchange 데이터베이스에 연결합니다. MCC/MNS 클러스터를 사용하는 경우 최고급 Exchange 저장소가 각 노드의 로컬 RAID 배열을 사용하는 쪽으로 발전할 것인지와 같은 흥미로운 질문을 던져볼 수 있습니다. MNS 클러스터의 목적이 각 노드에 고유의 별도 저장소를 두는 것이라면, 각 노드가 공통 저장소를 제공하는 것이 주 목적인 SAN을 가리키도록 하는 것이 과연 의미가 있을까요?
가능한 절충 MCC/MNS 클러스터 시나리오는 저장소가 SAN에 있는 주 노드와, 로컬 디스크 또는 저렴한 iSCSI SAN이 있는 보조 클러스터 노드를 사용하는 것입니다. 이 보조 노드는 SAN 인프라가 없으며 주 데이터 센터와는 떨어진 위치에 둘 수 있습니다.
결과가 어떻든 MNS 및 CCR을 사용하는 MCC는 여러 컴퓨터에서 장애 조치를 수행할 수 있고 데이터가 별도의 저장소에 복제되므로 중복 계층과 가용성에서 또 다른 한 단계의 발전을 의미합니다. 하지만 이 방법도 Windows Server 2008이 출시되기 전까지는 단일 데이터 센터 내로 범위가 제한됩니다. Windows Server 2008은 기본적으로 클러스터 확장을 지원합니다. 따라서 노드 간 네트워크 지연이 500ms 미만을 안정적으로 유지하는 한 얼마든지 멀리 MNS 클러스터의 노드를 지리적으로 떨어뜨려 놓을 수 있습니다. 그때까지는, 그리고 그 이후에도 당분간 Microsoft MNS 및 CCR 대신 타사 클러스터 기술이 효과적인 재해 복구 솔루션이 되기 위해 클러스터를 확장하는 데 필요한 지리적 분리 기능을 제공할 것입니다.
클러스터링은 재해 복구 연속선상에서 최상위에 위치하는 기술이라고 할 수 있고 CCR은 Exchange의 고가용성 기능이라고 하는 것이 적절합니다. 또한 비용과 인력이 많이 들더라도 이 둘을 조합하면 같은 유형의 Microsoft 환경을 운영하려고 하는 고객에게 매우 흥미로운 최상의 솔루션이 될 것입니다.

타사 원격 작업 연속성
Microsoft 솔루션과 타사 확장 기술을 함께 사용할 수 있다면 복구 연속선에서 최상위를 차지하는 기술이 될 것이라는 점은 의심의 여지가 없습니다. 몇 초 내의 자동 장애 조치가 가능해질 것입니다. 이보다 좋을 수는 없겠지요. 그러나 모든 회사가 이런 수준의 가용성 및 비즈니스 연속성을 원하는 것은 아니며 이러한 연속성을 제공하기 위해 엄청난 비용을 투자할 만큼 여력이 있는 것도 아닙니다. 대부분의 회사는 몇 분 내에 Exchange를 완전하게 복원하는 안정적인 솔루션만으로도 작업 연속성을 위해 필요한 모든 것을 확보할 수 있습니다.
한 예로 Mimosa Systems, Inc.는 단일 데이터 센터 내의 작업 연속성을 원격 연속성으로 확장했습니다. 원격 위치에 있는 Mimosa DR에서는 Exchange의 복사본을 유지 관리하고, 주 Exchange 서버에서 제공한 트랜잭션 로그를 사용하여 이 복사본을 최신 상태로 유지하며, 이러한 라이브 복사본을 대기 Exchange 서버가 언제든지 사용할 수 있도록 준비하고 있습니다. 원격 Exchange 서버는 표준 서버 하드웨어를 사용하며, 단일 데이터 센터 구현과 마찬가지로 재해가 발생할 경우 언제든지 사용할 수 있도록 만반의 준비가 되어 있습니다. 재해가 발생하면 원격 사이트의 운영자가 장애 조치를 시작하여 대기 데이터베이스 파일을 마운트하고 사서함 및 Outlook 프로필을 다시 매핑하는 등의 장애 조치를 수행합니다. 그런데 이러한 타사 솔루션은 기술 자료 문서 "Exchange 데이터베이스 콘텐츠를 수정 또는 추출하는 타사 제품을 위한 Microsoft 지원 정책"에 정의되어 있는 항목에 대해서만 지원을 받을 수 있습니다.

결론
Exchange 데이터 보호는 비용 및 성능을 기준으로 세 수준으로 그룹화할 수 있는 일련의 기술 및 절차입니다. Exchange 데이터 보호에 대한 요구 사항을 고려할 때는 이해 당사자가 감내할 수 있는 작동 중단 시간을 검토해야 합니다. 성능이 우수하고 복구 속도가 빠를수록 비용이 많이 듭니다. 최고급 옵션의 경우에는 막대한 비용을 들여야 합니다. 최고 수준은 아니지만 그에 가까운 가용성을 제공하는 적정 가격의 솔루션도 있습니다. 따라서 조직의 실제 필요에 맞게 적절한 솔루션을 선택하는 것이 중요합니다.
Exchange 2007 서비스 팩 1
현재 베타 테스트 중인 Exchange 2007 SP1(서비스 팩 1)에는 OWA의 향상 기능, 콘솔의 추가 GUI 기능을 비롯하여 관리자들이 고대해 온 수많은 기능이 포함될 예정입니다.
복구 솔루션을 계획 중인 관리자에게 특히 흥미로운 소식은 Exchange 2007 SP1에는 LCR과 CCR을 보완하는 타사 가용성 솔루션인 SCR(보조 연속 복제)이 포함된다는 것입니다. 이는 중도적 접근 방법으로, Microsoft는 이 기술이 완전한 "고가용성." 기술과 관련된 복잡함 없이 보다 우수한 복구 기능을 제공할 것으로 보고 있습니다.
SCR을 사용하면 일반적으로 사서함이 있는 서버가 아닌 다른 Exchange 서버에 Exchange 데이터베이스 및 트랜잭션 로그를 복제할 수 있습니다. SCR의 대상은 로컬 또는 원격 모두 가능하며 대기 Exchange 서버나 클러스터가 될 수도 있습니다. 그러나 SCR은 로컬이나 원격에서 클러스터를 필요로 하지 않습니다. 또한 대기 환경을 대상으로 하며 장애 조치가 수동으로 이루어진다는 점에서 CCR과 다릅니다. 그런데 SCR을 사용할 경우에도 처음의 대용량 복사본, 즉 전체 백업을 네트워크를 통해 가져와야 한다는 점에 유의해야 합니다. 이 대규모 복제 작업을 빈번히 수행해야 할 수도 있습니다. 또한 CCR과 타사 솔루션을 사용할 때와 마찬가지로 네트워크가 받을 영향을 정확하게 인식하고 있어야 합니다. SCR과 CCR 및 비슷하거나 더 나은 기능을 제공하는 그 밖의 추가 제품이 널리 사용될 것으로 예상됩니다.

Lee Benjamin은 ExchangeGuy Consulting Services를 운영하면서 고객과 만나 업무를 처리하고 Microsoft 파트너에게 자문을 주기도 합니다. Lee는 세계에서 가장 규모가 큰 Exchange 사용자 그룹인 ExchangeServerBoston의 회장이자 BostonUserGroups의 의장이며, Exchange MVP 및 Microsoft Certified Trainer 겸 업계 회의의 정규 강연자이기도 합니다.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 Communications: Windows Mobile 6의 보안 향상
Communications Matt Fontaine

Windows Mobile 6의 보안 향상
한 눈에 보기:
  • 장치 보안
  • Exchange Server 보안
  • 네트워크 보안

모바일 장치는 사무실 밖의 다른 곳에서도 회사 정보에 액세스하고 연결을 유지할 수 있도록 함으로써 전 세계 작업자들의 생산성을 높이고 있습니다.
즉, 단지 모바일 장치를 켜고 업무에 착수하는 것만으로 생산성이 실로 향상됩니다.
이와 같은 눈부신 발전의 이면에는 가상 사무실의 보안을 안정적으로 유지하기 위해 고군 분투하고 있는 IT 전문가들이 있습니다. IT 전문가의 견해에서 볼 때 모든 모바일 장치는 네트워크에 연결되어 있을 경우 잠재적인 보안 유출 및 데이터 도난의 위험을 갖고 있습니다. 효율적이고 사용이 편리한 사용자 환경을 제공하는 것과 모바일 장치를 더욱 안전하게 배포하는 것 사이에서 균형을 유지하는 것이 매우 중요합니다.
Microsoft® Windows Mobile® 6 및 이전 버전인 Windows Mobile 5.0 MSFP(메시지 및 보안 기능 팩)에는 사용자의 불편을 최소화하면서 회사 인프라를 안전하게 유지하는 데 유용한 다양한 기능이 포함되어 있습니다. Microsoft Exchange Server를 메시징 플랫폼으로 구현하면 더 많은 보안 옵션을 사용할 수 있습니다. 이번 기사에서는 회사의 모바일 장치를 보호하기 위한 기반으로 Windows Mobile, Exchange Server 및 몇 가지 유용한 네트워크 보안 사례를 적용하는 방법에 대해 살펴보겠습니다.

모바일 통신 아키텍처
모바일 배포를 계획하고 있거나 업그레이드할 때는 장치, 메시지 서버 및 네트워크의 세 가지 계층을 고려해야 합니다(그림 1 참조). 장치 수준에서는 장치에 대해 허용된 응용 프로그램만 액세스할 수 있도록 하여 무단 액세스를 차단하는 것이 중요합니다. Windows Mobile에서는 PIN 인증 및 암호 보호, 장치 시간 제한 잠금, 장치가 손상되거나 도난된 경우 로컬 또는 원격으로 장치 메모리를 지우거나 삭제하는 기능 등을 통해 장치 자체에 대해 무단으로 액세스하는 것을 차단합니다. 또한 통신 채널 및 이동식 저장소의 데이터 암호화도 지원됩니다. 바이러스 또는 스파이웨어와 같이 허가되지 않은 응용 프로그램이 설치되거나 장치의 핵심 부분에 액세스하는 것을 차단하는 것도 필수적입니다. 관리 역할 정의, 응용 프로그램 액세스 계층, 코드 서명 설정, 보안 설정 및 보안 인증서를 결합하여 장치 수준의 보호를 구현할 수 있습니다.
그림 1 모바일 통신 계층
그림 1 모바일 통신 계층
그 다음 보안 계층은 Exchange Server 2003 SP2(서비스 팩) 또는 Exchange Server 2007과 같은 메시징 서버입니다. 이 계층에는 장치에서의 안전한 메시지 송수신에 사용되는 기술인 메시지 보안을 비롯하여 Exchange ActiveSync®를 통한 메시지 서버 및 모바일 장치 간의 상호 작용도 포함되어 있습니다. Exchange Server에서 Windows Mobile 장치를 반드시 사용할 필요는 없지만 Exchange를 사용하면 비용, 확장성, 성능 및 관리 측면에서 이점을 얻을 수 있습니다.
훌륭한 장치 수준 및 메시징 서버 보안을 구현하는 것도 중요한 일이지만 네트워크 계층을 보호하는 것 역시 중요합니다. 최선의 방법에 따라 회사 네트워크를 구성하고 강력한 보안 프로토콜을 구현함으로써 하나 이상의 모바일 장치가 손상된 경우에도 네트워크에 문제가 발생하지 않도록 할 수 있습니다.

장치 보안 정책
보안 위반에 대한 첫 번째 방어는 Windows Mobile 기반 장치 자체에 있습니다. Windows Mobile 운영 체제에서는 인증, 저장소 카드 암호화, VPN(가상 사설망), Wi-Fi 암호화 및 SSL(Secure Sockets Layer) 서비스를 지원하는 광범위한 장치 수준의 보안 서비스를 제공합니다. 장치 수준의 보안에는 장치 및 해당 데이터에 액세스하는 사용자 관리, 장치에서 실행할 수 있는 응용 프로그램 제어 및 장치에서 데이터가 송수신되는 방법 설정 등의 작업이 수반됩니다. 일반적으로 관리자는 Windows Mobile 5.0 MSFP 및 Windows Mobile 6 모두에 보안 정책을 설정하고 적용하는 데 상당한 융통성을 발휘할 수 있습니다.
사용자 액세스는 PIN 또는 암호 인증을 통해 관리됩니다. 일정 시간 비활성 상태에 있거나 전원이 꺼진 장치는 자동으로 잠기도록 설정할 수 있습니다. 이 경우 사용자가 장치를 다시 사용하려면 먼저 잠금을 해제해야 합니다(그림 2 참조). 사용자 액세스 제어의 구체적인 사항은 관리자의 보안 역할에 따라 변경될 수 있는 보안 정책으로 설정됩니다.
그림 2 암호 정책 설정
그림 2 암호 정책 설정
암호 정책은 모바일 장치의 전반적인 보안 수준을 정의합니다(그림 3 참조). 보안 역할에 따라 이 보안 정책을 설정 및 변경할 수 있는 사용자가 결정됩니다. 일반적으로 모바일 운영자에게 부여되는 관리자 역할은 보안 정책 설정에 대한 완벽한 제어 권한을 제공합니다. Exchange에서 엔터프라이즈 역할은 Exchange 관리자가 구성한 일부 장치 정책을 관리하는 데 사용됩니다. 장치 공급자와의 계약에 따라 회사의 보안 정책을 사용자 지정할 수도 있습니다.
Figure 3 모바일 장치의 보안 정책 (Close Figure 3)

정책 모바일 장치
장치에 대한 무단 침입 차단

Windows Mobile 5.0 MSFP

사용자가 장치의 잠금을 해제할 때 항상 인증하도록 하거나 사용자가 데스크톱에서 PIN을 입력할 수 있도록 지정합니다.
기본 역할: 관리자, 엔터프라이즈

Windows Mobile 6

이동식 저장소 미디어의 모바일 암호화 설정을 변경할 수 있는 사용자 권한을 허용 또는 거부합니다.
기본 역할: 관리자, 엔터프라이즈
장치가 연결되어 있을 때 장치 잠금이 활성화되어 있는 경우 사용자가 인증해야 하는지 여부를 지정합니다. 기본 역할: 관리자, 엔터프라이즈
장치를 도난당했거나 장치가 손실된 경우 중요한 데이터를 보호합니다.

Windows Mobile 5.0 MSFP

사용자가 장치의 잠금을 해제할 때 항상 인증하도록 하거나 사용자가 데스크톱에서 PIN을 입력할 수 있도록 지정합니다.

기본 역할: 관리자, 엔터프라이즈

Windows Mobile 5.0 MSFP 및 Windows Mobile 6

장치에서 암호를 구성해야 하는지 여부를 지정합니다. 로컬 및 원격 장치 지우기 설정을 구성합니다.
기본 역할: 관리자, 엔터프라이즈
Windows Mobile에 사용되는 사용자 지정 인증 방법은 LASS(로컬 인증 하위 시스템)와 상호 작용하는 LAP(로컬 인증 플러그 인)에 의해 제어됩니다. Exchange Server에서는 이 기술을 통해 암호 길이 및 강도 요구 사항을 구현하거나 단순한 PIN 인증을 사용하는 등의 방법으로 세부적인 수준에서 장치 구성을 제어할 수 있습니다.
Windows Mobile 6에는 Exchange Server 2007을 통해 구성된 확장된 LAP 기능 집합이 포함되어 있습니다. "1111" 또는 "1234"와 같이 단순한 패턴 사용을 거부하는 PIN 패턴 인식을 사용하거나, 암호 또는 PIN 만료 기간을 구성하여 사용자가 특정 조건에 따라 PIN 재설정을 요청할 수 있도록 하거나, PIN/암호 기록을 보관하여 사용자가 새 PIN 또는 암호를 만들 때 기존 PIN 또는 암호를 다시 사용하지 못하도록 할 수 있습니다.

장치 내 데이터 보호
관리자가 설정한 제한 횟수를 초과하여 잘못된 PIN 또는 암호를 입력한 경우 로컬 장치의 지우기 기능에 따라 장치가 하드 리셋되며 사용자 인증 자격 증명을 포함한 메모리의 모든 내용은 삭제됩니다. 입력 제한 횟수는 Exchange Server의 보안 정책의 일부로 설정됩니다. 장치에서 잘못된 PIN 또는 암호를 연속으로 두 번 입력할 때마다 계속 진행하려면 구조화된 키 문자열을 입력하라는 메시지가 사용자에게 표시됩니다(그림 4 참조). 이렇게 하면 임의의 키를 눌러 장치의 내용이 삭제되는 실수를 방지할 수 있습니다. Windows Mobile 6과 Exchange Server 2007을 사용하면 저장소 카드의 내용을 원격으로 지울 수도 있습니다.
그림 4 PIN 및 암호 사용 방법 적용
그림 4 PIN 및 암호 사용 방법 적용
중요한 회사 데이터가 담긴 2GB의 저장소 카드를 택시에 두고 내린 경우 장치를 잠그는 것만으로는 충분한 해결책이 되지 않습니다. 다행히 Windows Mobile 6을 사용하면 이러한 문제를 해결할 수 있습니다. 저장소 카드에 데이터를 쓴 장치에서만 해당 카드를 읽을 수 있도록 저장소 카드 데이터를 암호화할 수 있습니다. Windows Mobile 6의 다른 여러 향상된 보안 기능과 마찬가지로 이 보안 기능을 무선으로 제공하는 데 Exchange Server 2007을 사용할 수 있습니다. 저장소 카드 암호화의 대부분은 사용자에게 투명합니다. Exchange Server 2007에서 관리자는 사용자가 저장소 카드 암호화 설정을 변경할 수 있을지 여부를 선택할 수 있습니다.
응용 프로그램이 Windows Mobile 장치에서 실행될 수 있는지 여부는 권한 있음, 보통 및 차단됨의 세 가지 사용 권한 수준에 따라 결정됩니다. 권한 있음 수준의 응용 프로그램(권한 있는 인증서 저장소의 인증서로 서명됨)은 레지스트리 및 시스템 파일에 쓸 수 있으며 인증서를 설치할 수도 있습니다. 데스크톱 PC 또는 서버의 경우와 마찬가지로 운영 체제 환경을 변경할 수 있는 응용 프로그램 수가 많을수록 해당 환경이 손상될 가능성은 더욱 커집니다. 따라서 대개의 경우 액세스 권한이 있는 응용 프로그램의 수를 줄이는 것이 좋습니다. 대부분의 응용 프로그램(권한 없는 인증서 저장소의 인증서로 서명된 응용 프로그램 또는 사용자가 실행에 동의한 서명되지 않은 응용 프로그램)은 보통 수준에서만 실행됩니다. 이 수준에서 응용 프로그램은 실행될 수는 있지만 시스템 파일에는 액세스할 수 없습니다. 차단된 응용 프로그램은 잘못된 서명 또는 사용자 작업으로 인해 차단되어 실행될 수 없는 응용 프로그램입니다.
장치는 1계층 또는 2계층의 보안 액세스로 구성될 수 있습니다. 1계층 액세스 구성의 경우 서명되지 않은 응용 프로그램은 부여된 액세스 권한을 통해 실행되거나 차단되어 실행되지 못합니다. 2계층 액세스 구성에서는 정책이 성공적으로 확인되거나 사용자가 응용 프로그램 실행을 허용한 경우 서명되지 않은 응용 프로그램이 보통 수준에서 실행됩니다. 장치 설정에 따라 서명되지 않은 응용 프로그램을 실행할지 여부를 묻는 메시지가 사용자에게 표시될 수 있습니다.
사용자, 장치 및 응용 프로그램에 대해 가장 많이 사용되는 인증 형식 중 하나인 디지털 인증서는 장치, 서버 및 네트워크 수준의 Windows Mobile 보안에서 중요한 요소입니다. Windows Mobile 운영 체제에서는 장치의 서로 다른 인증서 저장소에 몇 가지 유형의 인증서를 저장합니다. 인증서는 어떤 응용 프로그램이 설치 및 실행될 수 있는지 결정합니다. Windows Mobile 기반 장치에서 사용자에게 확인 메시지를 표시하지 않고 실행되는 응용 프로그램의 경우 Microsoft Mobile2Mobile 프로그램에서 승인되었음을 나타내는 인증서로 서명되어야 합니다. 응용 프로그램에는 해당 응용 프로그램에 연결된 인증서를 기준으로 사용 권한 수준이 부여됩니다.
네트워크 인증의 경우 각 모바일 장치에는 그림 5와 같이 CA(인증 기관)에서 발급한 여러 개의 신뢰할 수 있는 상용 루트 인증서가 제공됩니다. Exchange Server와 같은 메시징 서버에서는 장치와의 SSL 연결을 설정하기 전에 해당 장치의 루트 인증서에 대해 신뢰성을 확인합니다. 회사에서 사용자 지정 인증서를 사용하는 경우 구입한 Windows Mobile 기반 장치에 인증서를 설치할 수도 있으며 새 인증서를 만들어야 할 수도 있습니다. 자세한 내용은 이 기사의 네트워크 보안 섹션에서 다루겠습니다.
그림 5 디지털 인증서 관리
그림 5 디지털 인증서 관리
ActiveSync 및 Internet Explorer® Mobile은 SSL을 사용하여 장치 및 회사 웹 서버 간의 데이터 전송을 보호합니다. 이러한 방식은 Microsoft Exchange 데이터 동기화, 장치 구성 또는 응용 프로그램 다운로드를 위한 연결에도 적용됩니다. SSL은 128비트 RC4 또는 3DES 암호화를 통해 통신 채널을 암호화하므로 당사자 외에는 데이터를 읽을 수 없습니다. Windows Mobile에서는 인터넷을 통해 서버에 액세스하면서 패킷 암호화를 사용하여 전용 회선과 유사한 보안을 제공하는 VPN도 지원합니다.

Exchange Server 보안
Windows Mobile 기반 장치에 Exchange Server가 반드시 필요한 것은 아니지만 두 시스템은 긴밀하게 연동하여 강력한 종단 간 모바일 메시징 및 생산성 솔루션을 제공하도록 설계되었습니다. Windows Mobile 5.0 MSFP가 릴리스된 이후 ActiveSync는 Windows Mobile 장치 설정을 원격으로 관리할 수 있도록 향상되었습니다. ActiveSync는 대부분의 Windows Mobile 장치에 전반적인 보안 설정을 전파하고 적용하는 데 매우 효과적이며 사용이 편리한 도구를 제공합니다.
ActiveSync는 Microsoft Windows Server 2003의 응용 프로그램/웹 서버 구성 요소인 IIS에서 실행됩니다. IIS는 네트워크를 통한 공격으로부터 ActiveSync를 보호하는 데 유용한 기본 보안 기능을 제공합니다. Microsoft Office Outlook® Web Access(OWA)도 IIS를 기반으로 하므로 ActiveSync 및 OWA 모두에 대해 동일한 보안 인증서를 사용할 수 있습니다.
ActiveSync를 사용하여 엔터프라이즈 정책을 전파하는 경우 다음 번에 장치를 Exchange Server와 동기화할 때 해당 정책이 장치에 전달됩니다. 사용자는 정책 변경 내용에 동의해야 합니다. 그렇지 않을 경우 서버에 연결할 수 없습니다. 많은 수의 네트워크에서 상세한 보안 정책을 적용할 수 없는 레거시 하드웨어를 비롯하여 다양한 종류의 장치가 사용되고 있습니다. 필요한 경우 보안 정책 요구 사항에서 레거시 하드웨어와 같은 특정 장치에 예외를 두어 해당 하드웨어가 계속 연결되도록 허용할 수 있습니다.
Exchange Server 2003 SP2와 Exchange Server 2007은 보안 정책 제어 기능에 약간의 차이가 있습니다. Exchange Server 2003 SP2에서는 최소 암호 길이를 4-18자로 지정하고, 암호에 문자 및 숫자 모두를 사용하도록 하며, 장치를 잠그기 전까지 허용되는 비활성 상태 기간을 설정할 수 있습니다. 또한 Exchange Server 2003 SP2에서는 앞서 설명한 것처럼 레거시 장치에 대해 예외를 둘 수 있으며 보안 설정을 장치에 전파하는 횟수도 설정할 수도 있습니다.
Exchange Server 2007이 릴리스된 이후 다음과 같은 기능을 비롯하여 Exchange Server 2003 SP2의 모든 기능을 포함하도록 ActiveSync 모바일 장치 관리 기능이 향상되었습니다.
  • "1234" 또는 "1111"과 같은 단순한 암호 허용 또는 금지
  • 첨부 파일 다운로드 사용 또는 사용 안 함
  • 저장소 카드 암호화 요구
  • 최대 첨부 파일 크기 설정
  • OWA를 통한 사용자의 장치 암호 복구 허용
  • UNC(Universal Naming Convention) 및 Microsoft Windows SharePoint® Services(WSS) 파일에 대한 액세스 허용
Exchange Server 2007을 통해 IT 전문가는 각 사용자 또는 장치에 맞게 정책을 설정하고 보안 정책에서 특정 사용자에 대한 예외를 둘 뿐만 아니라 사용자 그룹의 정책 관리 작업을 융통성 있게 수행할 수 있습니다.

원격 액세스 지우기
앞서 살펴본 로컬 장치 지우기 외에도 Exchange Server 2003 SP2, Exchange Server 2007 또는 OWA를 사용하여 Windows Mobile 기반 장치의 데이터를 원격으로 지울 수 있습니다. 동기화할 때 실행되는 원격 지우기는 ActiveSync 보안 정책을 사용하지 않는 경우에도 수행할 수 있습니다. 원격 지우기 하드 리셋은 장치에서 중지할 수 없습니다. 0을 반복 사용하여 데이터, 설정 및 보안 키를 덮어쓰므로 핵심 운영 체제의 일부가 아닌 데이터의 경우 거의 복구할 수 없습니다.

네트워크 보안
네트워크 보안은 장치 및 메시징 서버 구성 요소만큼 모바일 보안에 중요하며, 사용자가 충분히 제어할 수 있는 모바일 인프라의 일부이기도 합니다. 하나 이상의 모바일 장치가 손상된 경우에도 유용한 구현 모델에 따라 회사 네트워크를 구성하고 올바른 보안 프로토콜을 구현함으로써 네트워크에 문제가 발생하지 않도록 할 수 있습니다.
Windows Mobile은 다양한 유형의 네트워크에서 올바르게 작동합니다. 표준 인터넷 보안 프로토콜과 방화벽을 사용하여 성능, 안정성 및 보안 요구 사항에 부합하는 솔루션을 설계할 수 있습니다.
회사 네트워크 내에서 메시징 서버를 운용하는 경우 인터넷과 회사 서버 간에 완충 역할을 하는 경계면 방화벽으로 메시징 서버를 보호할 수 있습니다. 이러한 용도에 맞게 특별히 설계된 기능을 제공하는 Microsoft Internet Security and Acceleration(ISA) Server 2004 또는 ISA Server 2006에서는 들어오는 모든 패킷을 검사하여 유효성을 확인한 후에 해당 패킷을 Exchange Server로 전달합니다. 그런 다음 인터넷을 통해 아웃바운드 정보를 클라이언트에 보냅니다.
ISA Server를 구성하려면 SSL 암호화를 사용하도록 설정하고 포트 443을 Exchange Server 트래픽용 SSL 웹 수신 포트로 지정해야 합니다. 이와 같이 단일 포트로 수신을 제한하여 인터넷에 대한 노출을 최소화합니다. 또한 모든 클라이언트는 ActiveSync를 통해 연결하기 전에 먼저 SSL 링크를 설정해야 합니다.
ISA Server는 OWA와 같은 웹 응용 프로그램의 사용자를 미리 인증하여 인증되지 않은 사용자가 응용 프로그램 서버에 액세스하는 것을 차단할 수 있습니다. ISA Server 2006은 Windows Mobile 기반 장치의 SSL 종료 지점의 역할을 하여 ISA Server 2004의 SSL 브리징 모델을 향상시킵니다. 이를 통해 Windows Mobile 기반 장치는 Exchange Server와 직접 연결하지 않고도 ISA Server 2006을 통해 트래픽을 앞뒤로 전달하여 Exchange Server 인증을 수행할 수 있습니다. ISA Server 2006은 경계 네트워크에 위치하는 것이 좋습니다. 따라서 공용 인터넷 및 Exchange Server 프런트 엔드 간에 추가 보안 계층을 구현할 수 있습니다.

인증
인증에는 기본 인증 및 인증서 기반 인증의 두 가지 옵션이 있습니다. 기본 인증은 Windows Mobile 클라이언트 및 Exchange 프런트 엔드 서버 간의 표준 이름 및 암호 사용 SSL 기반 연결을 의미합니다. 기본 인증의 경우에도 Exchange Server에서 장치를 인증하기 전에 해당 루트 인증서가 일치하는지 확인하므로 인증서가 필요합니다. Windows Mobile 및 IIS를 사용하면 SSL과 연관된 다양한 암호화 방법을 사용할 수 있습니다.
Windows Mobile 5.0 MSFP 및 Windows Mobile 6에서 사용할 수 있는 인증서 기반 인증에는 SSL 기본 인증 대신 TLS(전송 계층 보안)가 사용됩니다. TLS의 경우 각 사용자는 루트 인증서 외에도 공개 키 및 개인 키가 포함된 인증서가 필요합니다. TLS에서는 암호 대신 암호화 키(최대 2,048비트)를 사용하므로 보다 강력한 인증을 제공합니다.
Windows Mobile 6에서 데스크톱 등록을 사용하는 사용자 인증서를 등록하려면 해당 장치가 인증서 등록 서버와 동일한 도메인에 있는 데스크톱에 연결되어야 합니다. 사용자는 암호, 스마트 카드 또는 다른 방법을 사용하여 등록을 인증한 다음 데스크톱 PC에 장치를 연결합니다. 그런 다음 사용자가 데스크톱을 통해 인증서 시스템에 액세스하면 모바일 장치에 인증서가 설치됩니다. 데스크톱 등록은 ActiveSync 인증 인증서, SSL/TLS 인증 인증서, 802.1x Wi-Fi 인증서 또는 S/MIME 디지털 서명 인증서의 배포뿐만 아니라 인증서 갱신을 포함한 다양한 Windows Mobile 보안 용도로 사용할 수 있습니다.
SSL과 같은 보안 프로토콜은 전송 도중 메시지 데이터를 보호하지만 데이터가 Windows Mobile 장치 또는 Exchange Server에 도달하면 이를 암호화하지 않습니다. S/MIME는 디지털 서명 또는 암호화된 전자 메일을 지원하는 MIME 전자 메일 표준과 유사한 형식의 보안 알고리즘입니다. S/MIME는 SSL 전송 계층 암호화를 보완하는 추가 보호 계층을 제공합니다.

요약
인프라 보안 솔루션을 구성하는 여러 계층 각각에 대해 각별한 주의가 필요합니다. Windows Mobile, Exchange Server 및 ISA Server와 같은 Microsoft 네트워크 보안 제품을 함께 사용하면 모바일 인프라를 관리하는 데 따른 부담을 상당히 해소할 수 있습니다. 이러한 제품을 사용하여 IT 부서의 업무 부담을 줄이고 모바일 장치로 인해 발생하는 보안 관련 문제에서 벗어나 모바일 장치가 제공하는 생산성 향상에 더욱 주력할 수 있습니다.

이 기사를 작성하는 데 도움을 주신 Kathy Esser, Katharine Holdsworth, Sarah Norton, Chip Vollers에게 감사의 뜻을 전합니다.

Matt Fontaine은 BuzzBee의 기술 전문 저술가입니다.


 Communications: 공용 폴더에 대한 강력한 대안
Communications Alan Maddison

공용 폴더에 대한 강력한 대안
한 눈에 보기:
  • 일정 및 연락처 공유
  • 블로그 및 Wiki를 이용한 통신
  • 문서 공유 및 관리

Microsoft Exchange의 첫 번째 버전부터 제공된 공용 폴더는 원래 문서 공유, 메일 그룹 보관, 사용자 지정 응용 프로그램 개발을 위한 기본 플랫폼을 제공하는 것이 그 목적이었습니다.
그러나 거의 처음부터 관리자들은 이 공용 폴더의 관리와 사용에 어려움을 겪었고, 공용 폴더는 여러 Exchange 환경에서 점차 복잡한 부분이 되었습니다. Exchange Server 2007에서는 공용 폴더 관리 기능에 몇 가지 중요한 개선이 이루어졌지만 어려움은 여전히 남아 있는 상태입니다. 공용 폴더는 오늘날 기업에서 필요로 하는 강력한 공동 작업 및 문서 관리 플랫폼을 제공하지 못하고 있습니다.
Microsoft는 Exchange Server 2007이 아마도 공용 폴더를 지원하는 마지막 버전이 될 것이라고 밝혀왔습니다. 물론 공용 폴더는 여전히 완벽하게 지원되고 있으며 Exchange Server 2007 출시 이후 10년 동안 계속 공식 지원될 예정이지만, 이제 대안을 검토하기에 적당한 시점이 되었습니다.
다행히 Microsoft에서는 Microsoft® Office SharePoint® Server(MOSS) 2007 출시와 더불어 매우 유용한 옵션을 제공하고 있습니다. MOSS 2007은 IT 관리자와 기업이 공용 폴더의 기능을 대체하고 이를 능가하는 데 필요한 플랫폼을 제공합니다. 이 기사에서는 MOSS를 통해 Exchange 공용 폴더보다 훨씬 다양한 기능을 제공하는 강력하고 유용한 프레임워크를 구현하는 방법에 대해 살펴보겠습니다. 특히 일정, 연락처 및 문서 공유와 같이 일반적으로 공용 폴더가 사용되는 작업에 SharePoint를 활용하는 방법에 대해 중점적으로 다루겠습니다.
최소한 클라이언트를 업데이트하기 전까지는 공용 폴더가 계속 필요할 것이라는 점을 잊지 마십시오. Outlook 97에서 Outlook 2003까지의 Microsoft Outlook® 클라이언트에는 오프라인 주소록, 관리 양식 라이브러리, 약속 있음/없음 조회 등 다양한 이유로 공용 폴더가 필요합니다. Outlook 2007과 Exchange Server 2007 환경으로 이전한 다음에는 언제든 준비가 되면 공용 폴더 사용을 완전히 중단할 수 있습니다.

SharePoint 일정
공유 일정에는 흔히 공용 폴더가 사용됩니다. SharePoint 일정을 사용하면 공용 폴더 일정을 아주 쉽게 대체할 수 있습니다. 기본 SharePoint 사이트 설치 환경에는 일정이 하나 포함되어 있지만 조직의 필요에 맞게 일정을 여러 개 만들어야 할 수 있습니다. 예를 들어 인사 관리 부서의 공유 일정을 만드는 방법을 설명하겠습니다. 먼저 모든 사이트 콘텐츠 보기를 선택합니다. 이 옵션은 일반적으로 SharePoint 사이트의 왼쪽 위 모서리에 있습니다(그림 1 참조).
그림 1 새 사이트 콘텐츠 만들기
그림 1 새 사이트 콘텐츠 만들기
모든 사이트 콘텐츠 보기를 선택한 다음, 만들기 단추(그림 1 참조)를 클릭합니다. 만들기 페이지가 로드되면 그림 2와 같이 기본 콘텐츠 형식 옵션이 표시됩니다. 일정을 만들려면 추적 열에서 일정을 선택해야 합니다. 그런 다음 이름 및 설명 필드를 채우고 빠른 연결 섹션에 일정을 포함할지 여부를 선택합니다.
그림 2 여러 기본 옵션이 표시되는 만들기 페이지
그림 2 여러 기본 옵션이 표시되는 만들기 페이지
이 시점에서 일정이 만들어집니다. 사용자는 이 공유 일정을 SharePoint 사이트에서 볼 수도 있고 Outlook에서 직접 볼 수도 있습니다. Outlook에서 공유 일정을 보려면 웹 브라우저를 사용하여 일정에 연결한 다음, 작업 메뉴를 열고 Outlook에 연결 옵션을 선택하면 됩니다.
처음 연결할 때는 Outlook에 보안 경고가 표시되는데, 이것은 신뢰할 수 있고 알려진 원본에만 연결해야 한다는 점을 사용자에게 알려 주는 것입니다. 예를 선택하면 일정이 Outlook에 연결됩니다. 그림 3에서는 SharePoint 일정과 Outlook 일정이 나란히 표시된 기본 보기를 보여 줍니다.
그림 3 나란히 표시된 SharePoint 일정 및 Outlook 일정
그림 3 나란히 표시된 SharePoint 일정 및 Outlook 일정
일정이 Outlook에 연결되면 양방향 동기화가 이루어질 수 있습니다. Outlook에서 입력한 모든 이벤트는 SharePoint와 동기화되며 일정을 보는 모든 사용자에게 업데이트된 항목이 표시됩니다. 또한 SharePoint에서 SMTP를 지원하도록 설정한 경우 전자 메일을 통해 이벤트를 일정으로 직접 보낼 수 있고 SharePoint에서는 해당 항목을 추가합니다.

SharePoint 연락처
공용 폴더를 이용하는 공유 연락처 역시 많은 조직에서 사용되고 있습니다. SharePoint에서는 공유 연락처의 경우에도 연락처 목록을 쉽게 만들고 관리할 수 있도록 하는 더 강력한 대안을 제공합니다. 앞서 살펴본 인사 관리 부서의 예를 통해 공유 연락처 목록을 만드는 방법을 설명하겠습니다.
모든 사이트 콘텐츠 보기를 선택한 다음, 만들기 단추를 클릭합니다. 이번에는 통신 열에서 연락처 링크를 선택합니다. 이름, 설명, 빠른 연결 구성 등의 정보를 입력하는 화면이 표시됩니다(그림 4 참조). 이 정보를 모두 입력한 다음, 만들기 단추를 클릭하면 새 연락처 목록이 만들어집니다.
그림 4 이름, 설명, 빠른 연결 구성 채우기
그림 4 이름, 설명, 빠른 연결 구성 채우기

사용자 통신
토론 목록이라고도 하는 토론 게시판을 만들 때도 SharePoint를 사용할 수 있습니다. 만드는 방법은 일정 및 연락처의 경우와 마찬가지로 매우 간단합니다. 모든 사이트 콘텐츠 보기를 선택하고 만들기 단추를 클릭한 다음, 통신 열에서 토론 게시판 링크를 선택합니다. 앞서 살펴본 것처럼 이름, 설명, 빠른 링크 구성 등 필요한 정보를 입력하고 만들기 단추를 클릭합니다. 그림 5에서는 몇 가지 게시물이 있는 토론 게시판을 보여 줍니다.
그림 5 몇 가지 게시물이 있는 토론 게시판의 예
그림 5 몇 가지 게시물이 있는 토론 게시판의 예
SharePoint Server에서는 토론 게시판 외에도 많이 사용되는 두 가지 통신 도구인 블로그와 Wiki를 지원합니다. 공용 폴더에서는 사용할 수 없었던 블로그와 Wiki는 SharePoint Server 2007에 새로 추가된 도구이며 매우 재미있고 유용한 공동 작업 기능을 제공합니다.
블로그는 웹 사이트에 손쉽게 아이디어와 의견을 게시하여 공유할 수 있는 대화형 포럼입니다. 일반적으로 이러한 게시물은 범주별로 구분되어 있으므로 독자들은 원하는 내용을 쉽게 찾을 수 있습니다. 독자들은 블로거의 의견에 응답을 추가할 수도 있습니다. 예를 들어 회사에서 경영진이 블로그를 운영할 수 있습니다. 이러한 방식으로 직원들과 효과적으로 의사 소통을 수행할 수 있고 운영 담당자는 회사 내 모든 계층의 직원들과 아이디어 및 의견을 공유할 수 있습니다.
SharePoint에서는 간편하게 블로그를 만들 수 있습니다. 먼저 모든 사이트 콘텐츠 보기를 선택하고 만들기 단추를 클릭한 다음, 웹 페이지 열에서 사이트 및 작업 영역을 클릭합니다. 그러면 새 SharePoint 사이트 페이지가 나타나는데, 여기서 사이트의 제목, 이름, URL 등을 입력해야 합니다. 그런 다음 사이트의 서식 파일을 선택합니다(이 예의 경우 블로그 서식 파일). 마지막으로 사용 권한, 탐색, 사이트 디렉터리 목록 등의 구성 옵션을 지정합니다. 필요한 옵션을 모두 지정했으면 만들기 단추를 클릭합니다. 그러면 최상위 사이트 아래에 하위 사이트가 만들어집니다. 이 하위 사이트 안에 있는 라이브러리와 목록에서 블로그 기능을 제공합니다. 이 과정을 완료하면 새 블로그가 만들어집니다.
Wiki는 더욱 폭넓은 공동 제작 활동을 위해 개발된 또 하나의 훌륭한 도구입니다. Wiki 사이트에서는 사용자들이 콘텐츠를 추가, 제거 및 편집할 수 있으며 수많은 페이지를 연결할 수도 있습니다. Wiki를 만드는 가장 간단한 방법은 다음과 같습니다. 모든 사이트 콘텐츠 보기를 선택하고 만들기 링크를 클릭한 다음, 라이브러리 열에서 Wiki 페이지 라이브러리를 선택합니다. 그런 다음 이름, 설명, 탐색 구성 필드에 필요한 정보를 입력하고 만들기 단추를 클릭하면 됩니다. SharePoint에서 Wiki를 사용하는 방법에 대한 자세한 내용은 TechNet Magazine 2007년 1월호 기사 "작업에 Wiki 활용"을 참조하십시오.

SharePoint 라이브러리
실질적으로 공용 폴더는 사용자들이 한곳에서 문서에 쉽게 액세스하여 공유할 수 있는 문서 저장소가 되었습니다. Exchange 관리자들이 여러 해 동안 경험한 것처럼, 이러한 기본적인 용도로 인해 공용 폴더를 관리하는 것이 어렵습니다. 즉, 공용 폴더 데이터베이스에 대한 Exchange I/O가 증가할 뿐만 아니라 Exchange 인프라 전반에 걸친 복제 작업도 영향을 받습니다. SharePoint 라이브러리는 Exchange와 해당 리소스에서 이러한 부담을 완화하는 훌륭한 대안을 제공합니다.
SharePoint 라이브러리는 파일을 저장하고 관리할 수 있는 SharePoint 사이트 내부의 한 위치입니다. 그림, Wiki 페이지, 양식, 문서 등 몇 가지 형식의 라이브러리가 있습니다. 공용 폴더를 대체하려는 경우에는 문서 라이브러리가 가장 적절한 선택입니다. 문서 라이브러리는 SharePoint 사이트 내에서 문서를 저장하고 관리할 수 있게 해 주며, 필요한 경우 문서를 만들 수 있도록 지원합니다.
문서 라이브러리에는 다양한 형식의 파일을 저장할 수 있지만 실행 파일, 스크립트 등의 일부 파일 형식은 보안상의 이유로 기본적으로 제한됩니다. 그러나 이 제한 설정은 SharePoint 중앙 관리 사이트의 작업 섹션에서 구성할 수 있습니다.
MOSS를 기본 설치할 때 포함되는 문서 라이브러리는 사용자 지정이 가능합니다. 대부분의 조직에서는 조직에 속한 다양한 업무 부서를 지원하기 위해 여러 개의 라이브러리를 만들게 됩니다. SharePoint에서 제공하는 도구를 사용하면 이러한 작업을 쉽게 처리할 수 있습니다. 예를 들어 인사 관리 부서를 위한 문서 라이브러리를 배포하려면 모든 사이트 콘텐츠 보기를 선택하고 만들기 링크를 클릭한 다음, 라이브러리 열에서 문서 라이브러리를 선택합니다. 그러면 구성해야 하는 여러 가지 설정이 표시됩니다. 여기에서 라이브러리의 이름과 설명을 입력하고, 빠른 연결 섹션에 이 라이브러리를 포함할 것인지 지정하고, 버전 관리 기능 사용 여부를 선택하고, 라이브러리에서 직접 만들어지는 새로운 문서의 기본 서식을 선택합니다.
문서 버전 기록 옵션에 특히 주의해야 합니다. 이 옵션의 기본 설정은 '사용 안 함'입니다. 그러나 버전 관리는 여러 환경에서 유용하고 적절한 기능입니다. 문서의 기록용 복사본을 저장할 뿐만 아니라 변경 시기와 변경한 사용자를 추적할 수 있으며 이전 버전을 확인하고 복원할 수도 있습니다.
그림 6에서는 새로 생성되어 일부 문서가 업로드된 문서 라이브러리를 보여 줍니다. 문서 라이브러리를 만든 후에는 Microsoft Outlook과 Windows® 탐색기를 통해 이 저장소를 사용할 수 있습니다. Outlook에서는 문서 라이브러리의 콘텐츠를 오프라인으로 전환할 수 있으며 네트워크에 액세스할 수 없는 사용자를 위한 읽기 전용 복사본을 제공합니다. Windows 탐색기를 통한 액세스 권한 제공에는 내 네트워크 환경이 사용됩니다. 문서 라이브러리의 URL을 입력하여 사용자에게 액세스를 제공할 수 있습니다. 규모가 큰 환경에서는 그룹 정책을 사용하여 이 네트워크 환경을 배포할 수도 있습니다.
그림 6 일부 문서가 업로드된 문서 라이브러리
그림 6 일부 문서가 업로드된 문서 라이브러리

향상된 기능
SharePoint는 공용 폴더보다 훨씬 우수한 기능을 제공합니다. 또한 공용 폴더가 제공하는 일반적인 기능 외에도 이를 더욱 향상시킨 강력한 기능도 제공합니다. 다음과 같은 기능이 향상되었습니다.
  • 버전 기록
  • 승인 제어
  • 체크 아웃 절차
  • 워크플로 제어
  • 문서 보존 정책
  • 감사
  • RSS
이러한 기능은 모든 엔터프라이즈 콘텐츠 관리 플랫폼에 매우 중요합니다. SharePoint에서는 관리자가 쉽게 사용할 수 있는 강력한 프레임워크를 제공합니다. 이러한 향상된 기능을 일정, 작업, 토론 게시판, 문서 라이브러리 등 SharePoint의 여러 기능에 사용할 수 있습니다.
이러한 기능을 구성하려면 설정 메뉴를 선택하고 설정 옵션을 선택합니다. 예를 들어 그림 7과 같이 문서 라이브러리 설정 옵션을 선택합니다. 그러면 설정 페이지가 표시됩니다. 이 페이지에서 사용할 수 있는 모든 구성 및 사용자 지정 옵션을 볼 수 있습니다. 예를 들어 일반 설정 열에 있는 버전 관리 설정에서는 버전 기록을 구성할 수 있습니다.
그림 7 향상된 기능을 구성하기 위한 설정 옵션 선택
그림 7 향상된 기능을 구성하기 위한 설정 옵션 선택
앞서 설명한 것처럼 이 기능은 변경한 사용자, 변경 시기 등 문서 변경에 대한 기록을 제공합니다. 필요한 경우 이전 버전을 확인하고 복원할 수도 있습니다. 또한 SharePoint에서 저장할 수 있는 버전 수를 제어할 수도 있습니다. 이 제한 값에 도달한 경우 해당 항목은 SharePoint 휴지통에 보관되지 않고 바로 삭제됩니다.
또한 버전 관리 섹션에서 콘텐츠 승인 및 체크 아웃 요구 사항을 구성할 수도 있습니다. 콘텐츠 승인을 사용하도록 설정한 경우 제출된 모든 항목은 승인을 거쳐야만 다른 사용자들이 사용할 수 있습니다. 승인을 받지 않은 항목은 보류 상태로 유지됩니다. 체크 아웃 프로세스는 여러 사용자가 동시에 하나의 파일에 대해 작업할 수 없도록 하는 콘텐츠 제어 기능을 제공합니다.
워크플로는 공용 폴더에서는 사용할 수 없는 SharePoint의 또 다른 유용한 기능입니다. 기본적으로 워크플로는 비즈니스 프로세스에 대한 체계적인 접근 방법을 제공함으로써 기업 운영의 능률화에 도움을 줄 수 있습니다. SharePoint에서 구현되는 워크플로는 지정된 프로세스를 통해 문서가 이동하는 과정을 자동화하는 일련의 미리 정의된 작업입니다. 이러한 프로세스는 각 단계를 완료해야만 그 다음 단계로 넘어가는 반복적 방식이거나, 주어진 작업을 언제든 완료할 수 있는 병렬적 방식입니다. SharePoint에 포함된 기본 워크플로는 다음과 같습니다.
  • 승인
  • 의견 수집
  • 서명 수집
  • 문서 폐기 승인
정보 관리 정책은 규정 및 비즈니스 요구 사항을 준수하도록 하는 데 사용됩니다. 정책은 문서의 관리 및 제어와 관련된 일련의 규칙으로 구성됩니다. SharePoint Server에서는 사용자 지정 규칙을 지원하지만 다음과 같이 바로 사용할 수 있는 기본 규칙도 제공합니다.
  • 감사
  • 만료
  • 레이블
  • 바코드
감사는 사이트 설정 내에서 정의한 일련의 작업을 기준으로 이벤트를 기록하는 기능을 제공합니다. 문서 열기, 항목 또는 항목 속성 다운로드 또는 보기, 문서 편집, 문서 체크 아웃 또는 체크 인, 항목 이동 또는 복사, 항목 삭제 또는 복원과 같은 작업을 추적할 수 있습니다.
콘텐츠 만료를 사용하면 조직의 데이터 보존 정책에 맞게 콘텐츠를 삭제할 수 있습니다. 이와 같은 데이터 만료는 특정 날짜에 실행되거나 문서 만들기와 같이 특정 이벤트가 발생한 이후 일정 기간이 되면 실행되도록 설정할 수 있습니다.
레이블은 인쇄 기능과 함께 사용하며 인쇄물에 텍스트를 추가하는 기능입니다. 실제로 이 정책은 다양한 용도로 활용할 수 있습니다. 예를 들어 법률 자문 부서의 규정을 준수하기 위해 인사 관리 부서에서 공유하는 문서 라이브러리의 모든 문서에 기밀 유지 공지 사항을 삽입하도록 지정할 수 있습니다.
바코드는 온라인 문서와 인쇄된 문서에 대한 공식적인 추적 방법을 제공합니다. SharePoint에서 모든 문서에 대한 고유 식별자를 만들면 사용자들은 자신의 문서에 바코드 이미지를 삽입할 수 있습니다.
SharePoint에서 제공하는 향상된 기능 중 하나로 RSS 피드와의 통합이 있습니다. 일정, 연락처, 문서 라이브러리, 토론 게시판 등은 모두 사용자가 구독할 수 있는 RSS 피드를 제공합니다. 사용자는 Outlook 2007과 같은 RSS 판독기만 있으면 자신의 일상적 업무 내용을 파악하는 데 유용한 자동 업데이트를 받아 볼 수 있습니다.

요약
Microsoft Office SharePoint Server 2007은 Exchange 공용 폴더를 대체하는 보다 강력한 엔터프라이즈급 기능을 제공합니다. 또한 강력한 관리 프레임워크를 통해 일정, 연락처, 문서 공유 솔루션을 쉽게 구현할 수 있도록 지원합니다. 따라서 사용자는 토론 포럼, 블로그, Wiki 등 다양한 의사 소통 방법을 실현할 수 있습니다.

Alan Maddison은 MTI Technology Corporation의 Microsoft 기술 담당 수석 컨설턴트로, Active Directory, Exchange Server 및 가상화 관련 업무를 중점적으로 수행하고 있습니다.


 Communications: 스마트 카드를 이용한 Outlook Web Access 로그온
Communications Victor Akinnagbe and Ted Dressel and Jason Opdycke

스마트 카드를 이용한 Outlook Web Access 로그온
한 눈에 보기:
  • 2단계 인증
  • Kerberos 제한 위임
  • ISA Server 및 Exchange 구성

모바일 직원의 존재는 IT 조직에 고유한 보안 과제를 제기합니다. 원격 사용자는 전자 메일 등의 서비스와 데이터에 안전하게 액세스해야 합니다. 그러나 취약한 암호, 원격 컴퓨터를 통해 회사의 내부 리소스에 액세스하는 맬웨어(키 로거 등), 바이러스 등이
보안 사슬에서 가장 취약한 고리인 것이 현실입니다.
이와 같은 모바일 환경의 보안을 강화하는 방법의 하나가 바로 이러한 취약한 고리 중 하나인 암호를 아예 없애는 것입니다. 물론, 암호 인증 없이 계정 액세스를 허용한다는 발상이 불안감을 야기하는 것은 사실입니다. 암호와 관련된 문제를 근원적으로 제거하는 주요 기술 중 하나로 바로 2단계 인증 또는 다단계 인증이라고 하는 잘 알려진 방법이 있습니다. 2단계 인증은 암호라는 단 하나의 방법에 의존하여 액세스를 제공하는 것이 아니라, 사용자 이름과 암호의 조합, 스마트 카드와 같은 물리적 장치, 지문 등의 생체 식별 수단 등 다양한 인증 수단을 추가로 사용토록 하는 방식입니다.
회사에 원격 사용자가 있다면 회사 네트워크에 원격 액세스를 허용하기 위해 방화벽을 약간 열어야 할 것입니다. 표준 방화벽은 내부 네트워크와 외부 네트워크를 분리함으로써 기본적인 위험 완화 효과를 제공합니다(그림 1). 보안을 강화하기 위해 포트를 닫고 내부 네트워크의 장치와 통신이 필요한 경우에는 적절한 곳으로 포트를 전달합니다. 이러한 기술들이 기본적인 네트워크 수준 보호 효과를 제공하는 것은 사실이지만 지금은 나날이 정교해지는 공격으로 인해 다층적 네트워크 보안이 반드시 필요한 상황입니다.
그림 1 포트를 차단하거나 전달하는 표준 방화벽
그림 1 포트를 차단하거나 전달하는 표준 방화벽
이동이 잦은 직원들이 가장 흔히 사용하는 회사 서비스는 전자 메일과 메시징이므로, Exchange 인프라를 안전하게 구성하는 것이 그 어느 때보다 중요한 과제가 되었습니다. Outlook® Web Access(OWA)를 통한 전자 메일 액세스 제공은 이동이 잦은 직원들에게 안전한 서비스를 제공하는 방법의 하나이며, 스마트 카드를 통해 OWA에 더욱 안전한 2단계 인증 방식을 제공하는 것은 또 하나의 중요한 진전입니다. 이 문서에서는 스마트 카드를 사용하는 OWA 시스템을 배포할 때 반드시 알고 있어야 하는 구성 및 설치 문제를 자세히 살펴보겠습니다.

방화벽보다 우수한 솔루션
네트워크에서 Microsoft® Internet Security and Acceleration(ISA) Server 2006을 실행하면 원격 사용자에게 더욱 안전한 방식으로 네트워크를 개방하는 작업을 간단히 처리할 수 있습니다. ISA Server 2006에는 스마트 카드를 이용하는 VPN(가상 사설망), Active Directory®에 대한 LDAP(Lightweight Directory Access Protocol) 인증, Kerberos 제한 위임 등의 보안 강화 기능이 포함되어 있습니다. ISA Server는 기존의 방화벽과는 다소 다릅니다. ISA Server는 표준 방화벽 하드웨어를 대체하거나 그와 연동하여 네트워크 계층에서 작동할 뿐만 아니라, 응용 프로그램 필터처럼 기존 방화벽에서는 일반적으로 지원되지 않는 보안 기능을 추가로 제공함으로써 다층적 보안을 구현합니다. 호스팅하는 특정 웹 사이트에 누군가가 HTTP POST 방법을 사용하는 것을 원치 않습니까? RFC 사양을 준수하는 SMTP 메시지만 Exchange 서버로 들어오도록 허용하고 싶습니까? 암호화된 SSL(Secure Sockets Layer) HTTP 패킷이 네트워크에 들어오기 전에 검사하고자 합니까? ISA Server는 이러한 작업을 비롯한 다양한 작업을 관리함으로써 완전히 필터링된 무해한 트래픽만 DMZ 또는 내부 네트워크에 전달되도록 합니다.
SSL 세션은 표준 방화벽에 다소 문제가 될 수 있습니다. 패킷은 방화벽을 통과하는 동안 암호화된 상태로 유지되는데 이는 SSL이 올바로 작동함을 나타냅니다. 따라서 SSL을 사용하는 하드웨어 또는 소프트웨어 방화벽을 통해 OWA와 같은 응용 프로그램이 게시되면 표준 방화벽은 상태 기반 패킷 검사 외에는 실질적인 효과가 있는 검사를 수행할 수 없습니다. 포트를 그냥 열어서 전달하게 되면 상당한 위험에 노출되는 부담이 있습니다. 네트워크 경계에서 실질적인 검사가 이루어지지 않으므로 검사 및 인증을 받지 않은 패킷이 내부 네트워크로 흘러들어올 수 있습니다.
ISA Server 2006은 HTTP 클라이언트에 대해 SSL 끝점 기능을 수행함으로써 인증된 트래픽만 게시된 Exchange 서버에 도달하도록 합니다. ISA Server는 SSL 브리징이라는 유용한 기능을 지원합니다. 일반적으로 패킷은 표준 SSL 세션을 통해 ISA Server와 통신하는 클라이언트에 의해 암호화됩니다. SSL 브리징 기능을 통해 ISA Server는 SSL 암호화를 로컬에서 종료하여 암호화를 해제한 상태에서 패킷을 검사하고 필요한 경우 Active Directory에 대해 사용자를 인증하며 SSL을 사용하여 패킷을 다시 암호화한 다음 이를 적절한 Exchange 서버로 전달합니다(그림 2 참조). SSL 브리징은 이러한 기법을 통해, 응용 프로그램을 인식하지 못하는 방화벽에는 암호화된 데이터 덩어리로밖에 보이지 않는 SSL 세션 내부의 숨겨진 위험을 줄일 수 있는 것입니다.
그림 2 트래픽을 응용 프로그램 계층의 관점에서 파악하는 ISA Server
그림 2 트래픽을 응용 프로그램 계층의 관점에서 파악하는 ISA Server
Kerberos 제한 위임을 언급할 때 반드시 짚고 넘어가야 할 것이 바로 인증되지 않은 상태에서 트래픽이 서버에 도달하는 것입니다. 표준 방화벽의 경우 포트가 단순히 Exchange 서버로 전달될 뿐이며 악의적일 수 있는 사용자에 대한 인증 작업을 수행하는 것은 이 프런트 엔드 서버의 책임입니다. 인증이 필요할 경우, ISA Server는 Active Directory에 직접 연결하여 사용자 대신 자격 증명을 요청합니다. 사용자에 대한 인증이 정상적으로 이루어지면 ISA Server는 해당 메시지를 Exchange 프런트 엔드 서버로 전달합니다. 프런트 엔드 서버는 임의의 알려지지 않은 사용자 요청을 인증할 필요가 없습니다. 즉, 프런트 엔드 서버는 백 엔드 서버로 요청을 프록시하는 용도로만 사용할 수 있습니다. 또한 ISA Server 2006은 Kerberos 제한 위임 기능을 통해 자격 증명을 기반으로 Windows SharePoint Services 및 Exchange ActiveSync 등의 기술에 액세스할 수 있도록 지원합니다.
Exchange Server 2003에는 OWA 로그인에 대해 프런트 엔드 서버와 백 엔드 서버 간 Kerberos 기반 인증을 지원하는 기능이 포함되어 있습니다. 혹시 이러한 클라이언트 트래픽을 보호하기 위해 IPsec을 사용하고 있지 않습니까? Exchange Server는 클러스터링된 사서함 서버에 대해서도 Kerberos 인증을 지원합니다.

스마트 카드 인증 사용
지금까지는 OWA에 스마트 카드 기반 인증을 구현하는 것이 쉽지 않은 일이었습니다. 하지만 ISA Server 2006의 Kerberos 제한 위임 기능을 기반으로 하는 솔루션이 개발되었습니다. 이 솔루션을 사용하면 사용자가 인증서를 통해 자격 증명을 제출하여 OWA에 대한 인증을 수행할 수 있습니다. Kerberos 제한 위임은 무제한 위임을 사용했던 Windows® 2000의 Kerberos 위임에 비해 대폭 개선된 것으로, 많은 환영을 받고 있습니다. Kerberos 제한 위임은 보다 안전하며 가장 기법을 이용하는 정교한 공격의 위험을 크게 줄여 줍니다.
스마트 카드를 사용하는 방식의 경우, 사용자가 외부 네트워크에서 KDC(키 배포 센터)로 라우팅될 수 있는 권한이 없으므로 ISA Server 2006이 Active Directory에 연결하여 사용자를 인증합니다. ISA Server는 인증서-사용자 매핑 작업을 Active Directory에 위임하여 사용자를 인증한 다음, UPN(User Principal Name)을 기반으로 해당 Kerberos 티켓을 받습니다. 이 경우 ISA Server는 응용 프로그램 수준 필터링 및 역방향 프록시 서비스를 통해 Exchange 프런트 엔드 서버에 Kerberos 제한 위임 기능을 제공합니다. 역방향 프록시 없이 위임을 시도하는 경우 이를 악용할 수 있는 위험성이 증가하여 네트워크 또는 Active Directory 도메인의 무결성에 영향을 줄 수 있습니다.
Exchange Server 2003과 Exchange Server 2007 모두 기본 인증과 통합 인증을 지원합니다. 그러나 OWA에 스마트 카드 기반 인증을 사용하려면 Exchange Server 2003에 소프트웨어 업데이트를 적용해야 합니다. 자세한 내용은 "Outlook Web Access에 스마트 카드 인증을 지원하는 Exchange Server 2003의 새로운 기능에 대한 설명"을 참조하십시오. Windows Server® 2003 기본 기능 모드의 도메인이 있어야 하고 관련된 모든 Exchange Server 2003 서버에는 SP2 이상이 적용되어 있어야 하며 OWA 사이트에 대해 역방향 프록시로 작동하는 ISA Server 2006 서버가 있어야 합니다.
소프트웨어 업데이트를 설치하고 ISA 및 Exchange 서버를 구성하고 나면 스마트 카드를 이용한 OWA 세션 인증이 가능합니다. 그림 3에는 스마트 카드 인증에 필요한 이벤트가 순서대로 나와 있습니다. 인증 과정은 사용자가 Internet Explorer®에서 OWA 사이트를 여는 것으로 시작합니다(1). 실제로는 사용자가 ISA Server에 연결하는 것이며 이때 OWA 세션을 시작하려면 사용자 이름과 암호 대신 인증서를 제공하라는 메시지가 표시됩니다. 해당 인증서는 스마트 카드에 저장되어 있으며 사용자는 인증서 PIN을 입력해야 합니다.
그림 3 스마트 카드를 이용한 OWA 인증
그림 3 스마트 카드를 이용한 OWA 인증
인증서 유효성 검사(2)는 ISA Server의 구성과 기타 설치된 소프트웨어에 따라 CRL(인증서 해지 목록) 또는 OCSP(온라인 인증서 상태 프로토콜) 요청을 통해 처리됩니다. ISA Server는 DC(도메인 컨트롤러)에 사용자의 자격 증명 확인을 요청합니다. 이 요청이 실패하면 ISA Server는 이 사용자에게 오류 페이지를 표시하며 Exchange 프런트 엔드 서버에는 어떠한 요청도 도착하지 않습니다.
자격 증명이 확인되면 Kerberos 티켓이 생성되고, 통합 인증을 통해 Exchange 프런트 엔드 서버로 요청이 전달됩니다(3). Exchange 프런트 엔드 서버는 이 요청을 받아서 Kerberos 티켓이 유효한지 확인하고 해당 사용자의 백 엔드 사서함 서버를 찾아냅니다(4).
프런트 엔드 서버는 Kerberos 제한 위임을 통해 해당 백 엔드 서버에 대한 Kerberos 티켓을 요청하고 통합 인증을 통해 백 엔드 서버에 사서함 요청을 프록시합니다(5). 이 요청이 백 엔드 서버에 의해 처리되고(6) 사서함 데이터가 Exchange 프런트 엔드 서버로 반환됩니다(7). 해당 OWA 페이지에 대한 HTML 데이터가 ISA Server로 전달되고(8), 이는 다시 클라이언트 컴퓨터로 전달됩니다(9).

Exchange 환경 구성
앞서 언급한 기술 자료 문서에는 Exchange Server 2003용 소프트웨어 업데이트에 관한 설명과 ISA Server 2006 및 Exchange Server 2003을 이용한 Kerberos 제한 위임 구현 과정에 지침이 될 수 있는 설명이 들어 있습니다.
소프트웨어 업데이트가 수행하는 주된 작업은 Exchange 프런트 엔드 서버에서 해당 백 엔드 서버로 이루어지는 Kerberos 제한 위임 과정을 자동화하는 것입니다. ISA Server는 Exchange 조직에 속하지 않으므로 ISA Server에서 프런트 엔드 서버로 이루어지는 Kerberos 제한 위임 과정은 이 업데이트를 통해 자동화되지 않습니다. 따라서 각 ISA Server 인스턴스에서 각 Exchange 프런트 엔드 서버로 이루어지는 이 위임 과정은 직접 구현해야 합니다.
소프트웨어 업데이트를 수행하면 Exchange 프런트 엔드 서버를 KCD-FE(그림 4 참조)로 지정하고 이 서버를 해당 Exchange 백 엔드 서버의 위임 탭에 넣을 수 있게 해 주는 새로운 탭이 ESM(Exchange System Manager)에 추가됩니다.
그림 4 Kerberos 제한 위임 사용
그림 4 Kerberos 제한 위임 사용
또한 새로운 UI에서는 관리 그룹의 속성에서 msDS-AllowedToDelegateTo(A2D2) 특성을 채우는 작업에 사용할 자격 증명을 지정할 수 있습니다(그림 5 참조). 이 특성이 Kerberos 제한 위임을 담당하는 특성입니다.
그림 5 위임을 제어하는 계정 설정
그림 5 위임을 제어하는 계정 설정
GPO(그룹 정책 개체)를 통해 사용자와 컴퓨터를 위임하는 능력을 특정한 표준 사용자 계정에 부여하면 최소 권한의 원칙을 따를 수 있습니다. 표준 사용자 계정에 이처럼 높은 권한을 부여하면 이를 서비스 계정으로 활용하여 해당 관리 그룹에 대한 Kerberos 제한 위임 과정을 자동화할 수 있습니다.
이 경우 악의적인 사용자가 Kerberos 제한 위임 서비스 계정을 도용할 수 없도록 적절한 조치를 취해야 합니다. 이 계정이 도메인 관리자 계정이 아니더라도 악의적인 사용자가 이 계정에 액세스하면 Kerberos 위임을 이용하여 정교한 공격을 수행할 수 있습니다. 이 계정은 새로운 Kerberos 연결을 설정할 수 있으므로 각별히 주의를 기울여 사용해야 합니다. 복잡하고 긴 암호, 감사 강화, 계정 해제 등 이 계정의 보안과 무결성을 확고히 하는 데 필요한 예방 조치를 취해야 합니다.
또한 Exchange 소프트웨어 업데이트는 통합 인증과 관련하여 ESM 인터페이스에 매우 중요한 변경을 수행합니다. 이전의 Exchange Server 2003에서는 서버를 프런트 엔드 서버로 지정하면 HTTP 가상 서버의 HTTP 가상 디렉터리에 Windows 통합 인증을 사용하는 옵션이 비활성화되었습니다(그림 6 참조).
그림 6a 통합 인증을 사용할 수 있게 해 주는 업데이트
그림 6a 통합 인증을 사용할 수 있게 해 주는 업데이트
그림 6b 통합 인증을 사용할 수 있게 해 주는 업데이트
그림 6b 통합 인증을 사용할 수 있게 해 주는 업데이트
이는 프록시 서버가 NTLM 세션을 중단시킨다는 점, 사용자가 Kerberos 인증을 사용하는 경우 Active Directory에 연결해야 한다는 점, 인터넷 사용자는 일반적으로 도메인에 속하지 않는다는 점 등의 기술적 문제로 인해 Exchange 프런트 엔드 서버에서는 통합 인증이 지원되지 않았기 때문입니다. 앞서 기술 자료 문서에서 설명하는 업데이트는 이러한 한계를 없애줍니다. 이 업데이트를 설치하고 나면 가상 디렉터리로 가서 Windows 통합 인증을 사용자 자격 증명 확인 메커니즘으로 사용하는 옵션의 확인란을 선택할 수 있습니다. 이 확인란을 선택하면 Active Directory의 가상 디렉터리 개체에 msexchAuthenticationFlags라는 특성이 설정되며, 이는 Microsoft Management Console의 Adsiedit.msc 스냅인에서 확인할 수 있습니다.
OWA를 통해 전자 메일을 확인하는 사용자는 Exchange 백 엔드 서버의 이름을 알고 있을 것이고 따라서 회사 인트라넷에 접속해 있는 동안 통합 인증을 이용하여 그 서버에 연결할 수 있습니다. 사용자의 입장에서 통합 인증과의 차이점은, Internet Explorer에서 이 웹 사이트에 사용자를 자동으로 인증해 주기 때문에 회사 네트워크에 로그온되어 있는 경우에는 사용자 이름과 암호를 따로 입력할 필요가 없다는 데 있습니다. 이는 회사 네트워크에 속해 있는 사용자에게는 매우 편리한 기능입니다. 하지만 대개 외부 사용자인 OWA 사용자는 도메인에 로그온되지 않은 상태로 네트워크 외부에서 Exchange 프런트 엔드 서버로 들어오는 것이 일반적입니다. 이 과정은 기술 자료 문서 "IIS에서 브라우저 클라이언트를 인증하는 방법"에 자세히 설명되어 있습니다.
이 업데이트는 Active Directory의 SPN(서비스 사용자 이름) 특성이 아닌 A2D2 특성을 사용하도록 Exchange Server의 위임 탭을 채웁니다. Adsiedit.msc를 사용하는 Exchange 컴퓨터 개체를 살펴보면 두 가지 구별되는 특성, 즉 A2D2 특성(Kerberos 제한 위임 목록)과 SPN 특성(Kerberos 로케이터와 계정 지정 위치 역할 수행)을 볼 수 있습니다. 두 특성이 함께 Kerberos 제한 위임을 가능하게 하는 것이 사실이지만, 그래픽 인터페이스를 통해 A2D2 특성을 수정해야 합니다.
Windows는 기본 제공하는 HOST SPN을 별칭으로 사용하여 다른 서비스를 찾을 수 있습니다. 이는 Exchange 프런트 엔드에서 백 엔드로 위임하는 경우 Kerberos 제한 위임에 setspn.exe를 사용하지 않아도 된다는 뜻입니다. 이 솔루션에서도 SPN 특성 목록에 HTTP/Servername을 명시적으로 지정할 수 있으나 관리자의 실수를 유발할 여지가 커지며 Kerberos 제한 위임에는 필요하지 않습니다. Kerberos 제한 위임은 Active Directory에서 A2D2 특성을 찾습니다. 이 특성이 채워지지 않거나 잘못된 SPN 값으로 채워지면 관련 서버 간에 Kerberos 제한 위임이 작동하지 않습니다. 그러나 Exchange 클러스터에서는 프런트 엔드 서버의 A2D2 특성에 클러스터 노드 컴퓨터 계정을 지정해 주기만 하면 됩니다.
앞서 언급했듯이 Exchange 2003 서버가 포함된 Windows Server 2003 도메인은 Windows Server 2003 기본 기능 모드로 운영되어야 합니다. 도메인 기능이 이러한 수준이 되지 않으면 Kerberos 제한 위임을 사용할 수 없습니다. 도메인이 여전히 혼합 모드인 상태에서 앞서 언급한 소프트웨어 업데이트를 설치하면 작동은 하는 것처럼 보이지만 실제로는 SPN 등록이 실패하게 됩니다. 또한 Kerberos 제한 위임은 도메인 기능이지 포리스트 수준 기능이 아닙니다. 즉, Exchange Server 2003의 경우 ISA Server와 Exchange 프런트 엔드 및 백 엔드 서버가 같은 도메인의 구성원이어야 한다는 뜻입니다. 물론 서로 다른 도메인의 사용자들도 Kerberos 제한 위임에 인증할 수는 있습니다. 도메인 구성원이 아니거나 다른 도메인의 구성원인 ISA Server 인스턴스는 이 솔루션의 일부로 작동하지 않습니다.

OWA 사이트 구성
IIS Admin은 OWA에 대한 어떠한 종류의 인증 변경에도 사용하지 않아야 합니다. OWA는 IIS에 속해서 운영되며 다른 웹 사이트처럼 메타베이스에서 이루어지는 변경에 응답하지만, Exchange는 DS2MB(Directory Services to Metabase) 프로세스에 다소 복잡한 문제를 가져다 줍니다. DS2MB 프로세스는 변경 내용을 Active Directory에서 IIS 메타베이스로 단방향 프로세스를 통해 복제하므로 IIS에 직접 변경한 모든 내용을 덮어쓰게 됩니다. 따라서 관리자가 IIS 메타베이스를 직접 변경할 경우(예: 통합 인증 설정) 당장은 솔루션이 정상적으로 작동하는 것처럼 보여도 다음 DS2MB 복제 주기가 시작되면 문제가 발생합니다.
HTTP 가상 디렉터리에 Windows 통합 인증을 사용할 수 있도록 하는 옵션은 ESM에서 제공된 것입니다. 이는 ESM이 그 편집 내용을 Active Directory에 직접 전달한 다음, 그 변경 내용이 IIS 메타베이스로 복제되도록 하기 때문입니다. 시스템 수행자 서비스를 중단하는 방법 역시 DS2MB 프로세스를 중단하여 IIS 메타베이스를 변경하되 덮어쓰지는 않도록 할 수 있지만 바람직한 방법은 아니라는 점을 기억해야 합니다. 다음번에 시스템 수행자 기능이 시작되면 Active Directory로부터 변경 내용을 폴링하게 되고 솔루션은 자동으로 작동이 중지될 것입니다.
위임 탭에는 Kerberos만 사용하는 옵션과 모든 인증 프로토콜을 사용하는 옵션이 표시됩니다. 단순한 논리에 따르자면 여기서 논의하고 있는 솔루션은 제한 위임을 사용하고 있으므로 Kerberos만 사용하는 옵션을 선택해야겠지만, 이는 일반적인 논리가 적용되지 않는 수많은 IT 상황 가운데 하나일 뿐입니다. 따라서 모든 인증 프로토콜을 사용하는 옵션을 선택해야 합니다(그림 7 참조). 그 이유는 요청이 Kerberos 요청으로서 들어오는 것이 아니라 Active Directory 계정에 매핑된 해당 인증서를 가진 HTTP 요청으로서 들어오기 때문입니다.
그림 7 스마트 카드에 적합한 인증 설정
그림 7 스마트 카드에 적합한 인증 설정
이 경우 ISA Server는 SSL을 통해 사용자에게 PKI 인증서를 요청합니다. 들어오는 요청이 Kerberos 티켓이 아니므로 Kerberos 제한 위임 기능이 올바르게 작동하려면 적절한 전환이 이루어져야 합니다. 따라서 Kerberos만 사용하도록 설정하면 ISA Server에서 통신의 연쇄가 끊어집니다. 그러나 위임이 Exchange 프런트 엔드 서버와 백 엔드 서버 간에 이루어지는 경우에는 Kerberos만 사용하는 설정도 정상적으로 작동합니다. 이는 Exchange 프런트 엔드 서버가 ISA Server로부터 Kerberos 티켓을 받기만 하기 때문입니다.
\Exchange 및 \Public 가상 디렉터리는 개인 사용자 폴더 및 공용 폴더 정보가 있는 유일한 위치입니다. Exchange의 SSL 구성은 Kerberos 제한 위임 또는 2단계 인증에 새로운 것은 아니지만 기본 인증 자격 증명으로 SSL을 통해 OWA를 사용할 수 있도록 하는 표준 방법으로부터 전환하는 작업이 필요합니다. SSL을 잘못 강제하면 OWA의 작동을 중단시킬 수 있고 ESM에도 문제를 일으킬 수 있으므로 문서화된 방법에 따라 OWA에 SSL을 사용할 수 있도록 해야 합니다.

기타 세부 구성
이 솔루션을 구현할 때는 먼저 표준 방식으로 ISA Server와 Exchange를 배포하는 것이 좋습니다. 특히, 이전에 ISA Server를 배포한 적이 없다면 모든 설정을 구성한 상태로 Kerberos 제한 위임 솔루션 전체를 한 번에 배포하지 마십시오. 배포 과정에서 구성 요소 또는 단계 하나가 잘못될 경우 문제 해결 과정이 복잡해질 수 있습니다. 먼저 표준 방식(사용자 이름과 암호는 사용하되 양식 기반 인증은 사용하지 않는 방식)으로 ISA Server와 Exchange를 배포하고 정상적으로 작동하는지 확인한 다음 Kerberos 제한 위임 및 인증서 인증으로 전환하는 것이 훨씬 쉽습니다.
일반적으로 양식 기반 인증은 스마트 카드를 사용하는 OWA와 함께 사용할 수 없습니다. 양식 기반 인증에서는 사용자가 표준 Outlook 양식을 통해 제출할 사용자 이름과 암호를 갖고 있어야 합니다. 그러나 스마트 카드 기반 2단계 인증에서는 사용자가 스마트 카드만 갖고 있고 암호는 갖고 있지 않습니다. 즉, 양식 기반 인증에서는 인증서만 접수 또는 제출하여 인증을 완료할 수 있는 방법이 없습니다. 보안 사슬의 어느 부분(예: ISA Server 뒤에 있는 프런트 엔드 서버)에라도 양식 기반 인증을 사용하면 스마트 카드를 사용하는 OWA 구성에 문제가 생깁니다. 양식 기반 인증을 사용하는 경우 Exchange 가상 디렉터리가 강제로 기본 인증으로 설정되며, 따라서 IIS 메타베이스 역시 기본 인증으로 설정됩니다.
사용자 이름/암호 방식을 이용하는 사용자와 스마트 카드를 이용하는 사용자가 혼합되어 있다면 ISA 웹 수신기에서 대체 인증 기능을 사용할 수 있습니다. 이 경우 인증서 기반 자격 증명을 제시하라는 화면 메시지가 표시될 때 사용자가 Esc 키를 누르면, ISA Server 뒤의 Exchange 서버에서 통합 인증 방식을 사용하더라도, 표준 사용자 이름/암호 형태의 인증서 요청 메시지가 표시됩니다. 또한 ISA Server는 양식 기반 인증 기능과 거의 같은 방식으로 SSL 세션의 시간을 제한할 수 있습니다.

결론
OWA 인증에 스마트 카드가 지원되는 것은 Exchange Server 2003과 Exchange Server 2007 모두에 중요한 진전으로서 환영받고 있습니다. 인증서를 이용하여 OWA에 로그인할 수 있게 되면 사용자는 길고 복잡한 암호를 기억하기 위해 애쓰지 않아도 되며, 관리자는 감염된 시스템에서 사용자의 자격 증명을 빼낼 수 있는 키 로거 및 기타 다양한 형태의 맬웨어를 효과적으로 차단할 수 있게 됩니다. 자세한 내용은 "리소스" 추가 기사를 참조하십시오.
스마트 카드를 이용하는 2단계 인증 방식에 맞게 ISA Server를 정확히 구성하면 게시된 OWA 응용 프로그램에 대해 응용 프로그램 수준 필터링이 수행됨으로써 전반적인 보안이 더욱 강화됩니다. 또한 ISA Server 2006은 간단한 게시 마법사를 통해 Exchange Server 2003과 Exchange Server 2007을 게시하는 기능을 기본적으로 지원하므로 Exchange Server 2007로 전환 중인 조직의 경우 ISA Server에 투자한다면 그 비용을 회수하고도 남을 것입니다.
리소스
  • Outlook Web Access for Exchange Server 2003의 "안전한 HTML" 필터링 기능을 통해 제거된 파일을 공유하는 방법
  • Kerberos 위임 문제 해결
  • 메타베이스 업데이트 서비스
  • ISA Server 2006의 인증
  • Kerberos 프로토콜 전환 및 제한 위임
  • TechNet 웹 캐스트: 스마트 카드를 이용한 다중 인증 구현

Victor Akinnagbe는 워싱턴 D.C.에서 Microsoft의 수석 필드 엔지니어로 근무하고 있으며, 보안, 인프라 및 메시징 관련 업무를 중점적으로 수행하고 있습니다.
Ted Dressel은 워싱턴 D.C.에서 Microsoft의 컨설턴트로 근무하고 있으며, 보안 및 인프라 관련 업무를 중점적으로 수행하고 있습니다.
Jason Opdycke는 Charlotte에서 Microsoft의 수석 필드 엔지니어로 근무하고 있으며, 보안 및 인프라 관련 업무를 중점적으로 수행하고 있습니다.


 Windows Administration: Windows Vista의 ActiveX Installer 서비스
Windows Administration Rob Campbell and Joel Yoker

Windows Vista의 ActiveX Installer 서비스
한 눈에 보기:
  • ActiveX 컨트롤 관련 공통 과제
  • ActiveX 컨트롤이 설치되는 경로
  • 위험한 권한
  • Windows Vista의 안전한 프로세스

언제나 같은 이야기를 드리게 되지만 근본적으로 보안을 강화하려면 자유롭고 유동적인 컴퓨터 작업 환경은 어느 정도 포기해야 합니다. 여러분의 환경이 다른 대부분의 조직과 마찬가지라면 데스크톱 운영 체제를 견고히 하여 최종 사용자에게 보다 안전한 컴퓨팅 환경을 제공하고자
하는 바람이 가장 클 것입니다. IT 관리자는 일반적으로 여러 가지 보안 정책 설정, 사용자 권한, 파일 및 레지스트리 ACL(액세스 제어 목록), 시스템 서비스 제한을 사용하여 데스크톱 보안 작업을 수행합니다.
보안이 유지된 데스크톱 환경을 개발할 경우 흔히 걸림돌이 되는 사항 중 하나는 어떻게 하면 사용자의 환경에 알맞은 수준의 응용 프로그램 호환성을 제공하면서 악성 ActiveX® 컨트롤의 위협을 방지할 수 있느냐 하는 문제입니다. 이는 데스크톱 운영 체제와 관련하여 수년 동안 겪고 있는 문제였습니다. 이제 다행히도 Windows Vista™의 새로운 AxIS(ActiveX 컨트롤 Installer 서비스)를 통해 기업 환경에서 ActiveX 컨트롤 관리와 관련된 문제를 해결할 수 있게 되었습니다. AxIS에서는 일반적으로 ActiveX 컨트롤을 설치할 권한이 없는 표준 사용자가 승인된 웹 사이트의 ActiveX 컨트롤을 설치할 수 있는 간단하고 관리하기 용이한 방법을 제공합니다. IT 관리자는 AxIS를 통해 그룹 정책을 제어하여 사용자가 보유한 권한에 상관없이 설치할 수 있는 ActiveX 컨트롤을 결정할 수 있습니다.
이 기사에서는 ActiveX 컨트롤을 관리하는 데 따르는 어려움과 이러한 문제를 이전 버전의 Windows®에서는 어떤 방식으로 해결했는지 살펴보고, Windows Vista의 AxIS에서는 ActiveX 컨트롤 설치를 효율적으로 관리할 수 있는 독특한 방법을 어떤 방식으로 제공하는지 살펴보겠습니다.

ActiveX 컨트롤이란?
ActiveX 컨트롤은 일반적으로 캐비닛 파일 안에 패키지되어 있는 OCX 파일인 실행 코드 조각을 말하며, Internet Explorer®를 통해 사용자에 의해 설치되고 호출됩니다. 표준 HTML이나 간단한 스크립트로는 웹 응용 프로그램에 기능을 추가하기가 쉽지 않으므로 웹 개발자들은 이를 보완하기 위해 ActiveX 컨트롤을 작성합니다.
ActiveX 컨트롤의 주요 특징은 간단한 "다운로드 및 실행" 배포 모델입니다. ActiveX 컨트롤은 HTML object 태그를 통해 설치 및 호출됩니다. HTML object 태그에는 CODEBASE라는 특성이 있으므로 ActiveX 컨트롤이 아직 사용자 컴퓨터에 설치되어 있지 않은 경우 URL을 사용하여 해당 컨트롤을 다운로드할 수 있는 위치를 Internet Explorer에 알려 줍니다. 그러면 Internet Explorer에서 관련 설치 패키지를 다운로드하고, 해당 개체에 대한 신뢰 확인 작업을 수행한 다음, Internet Explorer 알림 표시줄을 통해 사용자에게 설치 허용 여부를 묻는 메시지를 표시합니다(그림 1 참조). 설치 과정에서 해당 컨트롤은 렌더링 페이지에 의해 등록되고 호출됩니다. 설치가 완료되면 모든 표준 사용자가 해당 컨트롤을 호출할 수 있습니다. 이처럼 간단한 배포 및 실행 메커니즘을 통해 개발자들은 웹 응용 프로그램 사용자에게 해당 구성 요소를 손쉽게 배포할 수 있습니다. 이러한 배포 방식이 지닌 문제는 ActiveX 컨트롤 설치를 완료하려면 관리자 권한이 필요하므로 표준 사용자는 ActiveX 컨트롤을 직접 설치할 수 없다는 점입니다.
그림 1 ActiveX 컨트롤 설치 알림 표시줄
그림 1 ActiveX 컨트롤 설치 알림 표시줄
ActiveX 컨트롤이 Internet Explorer 4.0에 처음 도입되었을 당시의 인터넷은 훨씬 우호적인 환경으로 보였습니다. 그러나 오늘날 웹을 통해 배포되는 실행 코드는 심각한 위협이 될 수 있으므로 Windows에서는 로컬 관리자 권한을 가진 사용자만 ActiveX 컨트롤을 설치할 수 있도록 허용하여 정책 설정에 따라 승인된 설치만 수행되도록 합니다. 관리자가 ActiveX 컨트롤 설치를 완료하면 시스템의 모든 사용자는 해당 컨트롤을 호출할 수 있습니다. Windows의 파일 및 레지스트리 ACL 모음을 통해 이러한 동작을 더 쉽게 수행할 수 있습니다. 이렇게 하면 표준 사용자가 ActiveX 컨트롤을 설치하는 것을 방지할 수 있지만 ActiveX 컨트롤을 설치하는 로컬 관리자 및 수정된 기본 사용 권한을 가진 표준 사용자로 인해 발생하는 위험은 방지할 수 없습니다.
Windows에서 관리자 권한을 가진 경우에만 설치 작업을 수행하도록 허용하는 기본 보호 기능을 사용하면 개인 수준에서는 ActiveX 컨트롤 문제를 해결할 수 있지만, 해당 ActiveX 컨트롤을 대규모 조직 전체에 걸쳐 관리하는 문제는 해결할 수 없습니다. 일반적으로 기업 환경에서 겪고 있는 문제는 신뢰할 수 없는 외부 컨트롤을 통해 전달될 수 있는 위협을 방지하면서 IT 조직에서 신뢰하는 ActiveX 컨트롤에 대한 사용을 어떻게 허용하느냐는 점입니다. 결국 개인 사용자가 갖고 있는 권한에 따라 특정 ActiveX 컨트롤이 좋든 나쁘든지 간에 해당 컨트롤의 설치 여부를 결정해야 하는 경우가 종종 있습니다. 위협에 대응하기 위해 어떤 조직에서는 모든 ActiveX 컨트롤을 차단하는 반면, 다른 조직에서는 최종 사용자의 설치는 허용하되 설치된 모든 맬웨어를 관리하는 방식을 사용하기도 합니다.
악성 컨트롤의 설치를 방지할 수 있는 또 다른 방법은 표준 사용자의 제한된 권한을 사용하도록 적용하고, 필요한 모든 컨트롤은 IT 관리자가 데스크톱 플랫폼에 미리 설치해 두는 것입니다. 이 방법은 사용하고 있는 ActiveX 컨트롤의 특성이 비교적 정적이거나, 데스크톱 업데이트와 함께 예정된 릴리스 프로세스를 사용하여 수정되었거나, 조직에서 Systems Management Server와 같은 소프트웨어 배포 메커니즘을 사용하고 있는 경우 효과적입니다. 그러나 지속적인 관리, 내부 응용 프로그램 개발자의 지속적인 변경 요구, 외부 컨트롤에 대한 종속성과 관련된 문제의 경우 이 방법으로는 효과를 보기 어렵습니다.
만약 사용자가 관리자 권한을 갖고 있다면 문제가 달라집니다. 이 경우에는 이러한 사용자가 승인되지 않은 컨트롤을 설치하지 못하도록 해야 합니다. 이 경우 사용자가 관리자 권한을 갖고 있으므로 최종 사용자에게 ActiveX 컨트롤을 설치할 수 있는 권한이 있을 수 있습니다. 최종 사용자가 로컬 관리자로 실행되도록 하면 조직에 커다란 위험 요소가 될 수 있으므로 대부분의 기업 환경에서는 이를 방지해야 합니다.
한 가지 방법은 승인된 컨트롤을 호스팅하는 내부 인터넷 구성 요소 다운로드 서버를 구현하는 것입니다. 이 방법을 사용하려면 클라이언트 레지스트리의 CodeBaseSearchPath 문자열을 수정해야 합니다. 일반적으로 요청된 HTML 페이지에 CODEBASE 특성이 포함된 개체 태그가 있으면 CodeBaseSearchPath 데이터에 지정된 위치로 Windows 클라이언트가 이동됩니다. 기본적으로 이 레지스트리 문자열에는 ActiveX 컨트롤 갤러리에 대한 인터넷 URL 및 CODEBASE 키워드가 포함되어 있습니다. 인터넷 구성 요소 다운로드 서버를 구현하려면 CodeBaseSearchPath의 기본 데이터를 조직에서 승인된 컨트롤을 호스팅할 내부 서버의 URL로 바꾸어야 합니다. 앞서 언급했던 방법과 마찬가지로, 이 방법을 사용하는 경우에도 지속적인 관리가 필요하며 많은 비용이 소요되고 ActiveX 컨트롤의 내부 서버를 호스팅하기가 복잡하다는 문제가 있습니다.
이외에도 Internet Explorer 영역 URLAction 수정, 그룹 정책을 통한 관리자 승인 컨트롤 지정, 방화벽 규칙에 의한 경계에서 모든 컨트롤 설치 차단과 같은 기타 방법들이 있습니다. 그러나 앞서 살펴보았듯이 이러한 모든 방법에는 각기 문제점이 있으며 대부분의 경우 유연성이 떨어지므로 결국 사용되지 않고 있습니다. 더욱 문제가 되는 것은 이러한 일부 방법의 경우 사용자에게 관리자 권한을 요구한다는 점입니다. 결국 이러한 수정 방법에서는 ActiveX 컨트롤이 들어오는 곳이나 호출되는 곳을 제어 또는 차단하는 등의 방법을 통해 일부 문제를 해결하고자 하지만, 관리자 권한을 갖지 않은 사용자의 경우 ActiveX 컨트롤을 설치할 수 없다는 근본적인 문제는 해결하지 않습니다.

AxIS의 장점은 무엇입니까?
기업 관리자의 경우 Windows Vista의 AxIS를 사용하면 사용자가 기본 파일 시스템 설정을 사용하는 표준 사용자로 실행되므로 강력한 보안 환경을 유지하는 동시에 ActiveX 컨트롤을 관리할 수 있습니다. AxIS에서는 ActiveX 컨트롤의 신뢰할 수 있는 소스를 구성할 수 있는 그룹 정책 옵션을 제공하며 표준 사용자를 대신하여 이렇게 구성된 신뢰할 수 있는 소스의 컨트롤을 설치할 수 있는 중개 프로세스를 지원합니다. 가장 핵심적인 이점은 중앙 집중식 관리 제어를 통해 사용자 워크스테이션에서 관리자가 아닌 사용자의 보안 환경을 유지 관리할 수 있다는 점입니다. AxIS는 IT 관리자가 확인한 ActiveX 컨트롤의 신뢰할 수 있는 소스(일반적으로 인터넷 또는 인트라넷 URL)에 따라 작업을 수행합니다. 개체 태그가 Internet Explorer에 컨트롤을 호출하도록 지시하면 AxIS에서는 다음 단계를 수행합니다.
  1. 컨트롤이 설치되어 있는지 확인합니다. 설치되어 있지 않으면 사용하기 전에 먼저 설치해야 합니다.
  2. AxIS 정책 설정을 검토하여 컨트롤이 신뢰할 수 있는 소스의 컨트롤인지 확인합니다. 여기에서는 개체 태그의 CODEBASE 특성에 지정된 URL 호스트 이름을 정책에 지정된 신뢰할 수 있는 위치 목록과 비교합니다.
  3. 사용자 대신 컨트롤을 다운로드하고 설치합니다.
AxIS 정책 설정 목록에 소스 URL의 호스트 이름이 없는 경우 설치를 완료하려면 관리자 권한이 필요하다는 내용의 일반 UAC(사용자 계정 컨트롤) 관련 메시지가 호출됩니다. 또한 AxIS에서는 응용 프로그램 이벤트 로그에 원본 AxInstallService에서 발생한 ID가 4097인 이벤트를 기록하여 시도된 ActiveX 컨트롤 설치에 대한 개괄적인 내용을 특정 컨트롤 다운로드 경로와 함께 표시합니다. 4097 이벤트에 대한 예는 그림 2에 표시되어 있습니다. 기업 관리자는 이 이벤트 로그 항목의 데이터를 참조하여 추후에 해당 웹 사이트를 방문할 경우 AxIS에서 컨트롤을 설치할 수 있도록 그룹 정책을 수정할 수 있습니다.
그림 2 4097 AxInstallService 이벤트
그림 2 4097 AxInstallService 이벤트
AxIS는 Windows Vista Business, Enterprise 및 Ultimate SKU에서 제공되는 선택적 구성 요소이며, 무인 옵션 또는 그림 3에서와 같이 제어판 대화 상자(프로그램 | 프로그램 및 기능 | Windows 사용/사용 안 함)에서 사용하도록 설정할 수 있습니다. AxIS를 사용하도록 설정하면 Internet Explorer에서 컨트롤을 요청할 때마다 앞서 설명한 단계에 따라 작업을 수행합니다.
그림 3 제어판에서 AxIS 설정
그림 3 제어판에서 AxIS 설정
관리자의 경우 Windows Vista에서 이벤트에 작업을 연결하는 기능을 사용하면 ActiveX 컨트롤 설치가 차단된 경우 AxIS 서비스를 통해 알림을 쉽게 받을 수 있습니다. ActiveX 컨트롤이 최종 사용자가 웹 사이트에서 액세스하는 URL 호스트 이름에서 설치되지 않을 수도 있다는 점을 반드시 유의해야 합니다. 따라서 설치를 위해 컨트롤을 가져올 호스트를 확인하는 데 AxInstallService 4097(시도된 설치) 이벤트에서 제공하는 정보가 매우 유용할 수 있습니다.
이벤트에서 얻은 정보로 그룹 정책에서 신뢰할 수 있는 위치를 구성할 수 있습니다. 로컬 또는 그룹 정책의 AxIS 설정은 Computer Configuration(컴퓨터 구성) 설정에서 확인할 수 있습니다(그림 4 참조). Approved Installation Sites for ActiveX Controls(ActiveX 컨트롤용 승인된 설치 사이트) 정책 설정을 사용하면 신뢰할 수 있는 위치의 호스트 URL을 지정할 수 있습니다(그림 5 참조). 승인된 사이트를 설정하려면 설치를 위해 ActiveX 컨트롤을 가져올 호스트 위치 및 설치 동작의 두 가지 정보가 필요합니다.
그림 4 그룹 정책 개체 편집기의 설정
그림 4 그룹 정책 개체 편집기의 설정
그림 5 AxIS에서 승인된 설치 사이트
그림 5 AxIS에서 승인된 설치 사이트
앞서 언급한 바와 같이, 컨트롤의 신뢰할 수 있는 위치를 나타내려면 우선 호스트 URL을 지정해야 합니다. 개발자가 컨트롤을 수정하는 경우 자주 변경되는 컨트롤의 CLSID를 알고 있어야 했던 이전 솔루션과는 달리, AxIS를 사용하면 전반적인 관리 작업 부담은 줄이면서 신뢰할 수 있는 위치의 모든 컨트롤을 설치할 수 있습니다. 두 번째로는 각각 ActiveX 컨트롤 다운로드 환경에 대한 동작을 지시하는 네 가지 값이 쉼표로 구분된 문자열 정보를 지정해야 합니다. 이러한 값은 TPSSignedControl, SignedControl, UnsignedControl, ServerCertificatePolicy의 네 가지 속성을 지정합니다. 처음 두 가지 속성(TPSSignedControl, SignedControl)은 0, 1 또는 2의 세 값 중 하나로 설정할 수 있으며 이러한 값은 URLAction 설정의 값과 비슷합니다. 값 0은 컨트롤이 설치되는 것을 방지하며, 값 1은 사용자에게 설치 허용 여부 메시지를 표시하고, 값 2는 사용자의 개입 없이 자동으로 컨트롤이 설치되도록 합니다. 서명되지 않은 컨트롤은 자동으로 설치할 수 없으므로 UnsignedControl 값은 0 또는 1로만 설정할 수 있습니다. 정책을 모두 지정하지 않으면 기본값인 2, 1, 0이 사용됩니다.
마지막 속성은 서명된 설정 컨트롤의 인증서 설정에 따라 설치 동작을 지정합니다. 대부분의 SSL 사이트와 마찬가지로 인증서는 그 유효성을 확인하기 위해 일련의 보안 테스트를 거쳐야 합니다. 유효하지 않은 인증서 속성은 실제로 서명된 ActiveX 컨트롤의 구현인 경우가 있습니다. AxIS의 구성을 사용하면 관리자는 URL별로 인증서에 의해 표시되는 유효하지 않은 정보에 대처할 수 있습니다. 마지막 속성은 그림 6과 같이 비트 마스크 값의 조합으로 나타납니다.
Figure 6 ServerCertificatePolicy (Close Figure 6)

값 | 정의
0x00001000 | 인증서의 유효하지 않은 CN(정식 이름)은 무시합니다.
0x00000100 | 알 수 없는 인증 기관은 무시합니다.
0x00002000 | 유효하지 않은 인증서 날짜는 무시합니다.
0x00000200 | 잘못된 인증서 용도는 무시합니다.
기본 설정인 0은 모든 보안 검사를 통과해야 AxIS에서 설치를 완료한다는 것을 의미합니다. 그림 7에서 호스트 설정의 조합 및 정책 설정에 지정된 네 가지 값을 확인할 수 있습니다.
그림 7 승인된 AxIS 호스트 URL
그림 7 승인된 AxIS 호스트 URL

결론
AxIS를 사용하면 관리자 권한이나 복잡한 구성 작업 없이도 그룹 정책을 구성하여 사용자가 설치할 수 있는 ActiveX 컨트롤을 제어할 수 있습니다. 이전 버전의 Windows에서는 이러한 수준에서 제어하기가 매우 어려웠으며 이전에 사용되었던 솔루션에는 심각한 제한 사항이 있거나 관리 측면에서 부담이 큰 경향이 있었습니다. AxIS에서는 조직에게 데스크톱 시스템에 대한 최종 사용자의 권한을 최소화하는 새로운 도구를 제공하므로 최종 사용자에게 관리자 권한이 필요하지 않은 표준 사용자 모델을 구현할 수 있습니다. Windows Vista 덕분에 IT 관리자는 최종 사용자가 아닌 조직 차원에서 어떤 ActiveX 컨트롤이 회사 환경 내에서 신뢰할 수 있는 컨트롤인지 결정할 수 있게 되었습니다.

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


 From The Editor: 여섯 다리 건너면 다 아는 사이
From The Editor
여섯 다리 건너면 다 아는 사이
Joshua Trupin

세계와 단절되어 있다는 느낌을 받은 적이 있습니까? 사무실에 혼자 앉아 먼산을 바라보면서 저 밖에 정말 다른 사람들이 존재하기는 한 건지 생각한 적은 없습니까? 아니면 정말로 우리는 이 세상에 홀로 버려진 존재일까요? 그렇지는 않을 겁니다. 특히 제 경우와 마찬가지로 받은 편지함이 항상 가득 차 있다면 말입니다.
받은 편지함이 항상 가득 차 있음에도 불구하고 최근에 필자는 이러한 공허감을 느끼면서 사람과의 교류가 필요하다는 것을 절실히 깨달았습니다. 그래서 업무와 관련된 커뮤니티 사이트 중 하나에 가입하여 친구를 추가하기 시작했습니다. 이들은 모두 지금까지 같이 일한 적이 있거나 컨퍼런스에서 대화를 나눈 적이 있는 사람들이거나 자료를 퍼 오면서 친구로 추가한 사람들입니다. 그렇게 일주일 만에 대화 상대 목록에 대화 상대를 58명이나 등록할 수 있었습니다. 멋지지 않습니까?
그러나 이것은 시작에 불과했습니다. 이렇게 추가한 친구를 통해 간접적으로 3,500명이 넘는 친구를 얻게 된 것입니다. 또 이 3,500명의 대화 상대마다 각자의 대화 상대가 있으므로 한 다리만 더 건너면 277,000명의 추가 대화 상대를 바로 얻을 수 있습니다. Excel 스프레드시트에서 간단히 계산해 보았더니, 한 사람마다 평균 50명의 대화 상대가 있다고 가정할 경우 여섯 다리만 건너면 340억 명의 사람을 친구로 얻을 수 있다는 놀라운 결과가 나왔습니다. 더욱 놀라운 것은 이 수치는 전세계 인구보다 많다는 것입니다. 이러한 사실을 알고 나니 갑자기 창 밖이 매우 풍요로워 보였습니다.
그러나 또 다른 문제가 생겼습니다. 이 방대한 인맥을 모두 어떻게 관리해야 할까요? 어떠한 의견이라도 좋으니 누가 좀 알려 주었으면 좋겠습니다. 여러분도 업무와 관련해서나 친목을 목적으로 하는 커뮤니티 사이트를 이용하고 계십니까? 그렇다면 대화하고 싶은 사람과 대화하기 꺼려지는 사람을 어떻게 구분하고 있습니까? TechNet Magazine 블로그를 방문해 이 골치 아픈 문제에 대해 의견을 올려 주십시오.
이 모든 Web 2.0 네트워킹을 따라가기가 벅차다면, 이번 호 TechNet Magazine에서 Exchange Server를 잘 활용하여 다른 이들과 보다 효과적으로 커뮤니케이션하는 방법을 확인할 수 있습니다. 조직의 메시징 범위를 확장하는 데 필요한 정보를 제공하는 다섯 가지 기사가 준비되어 있습니다.
이번 호에는 Outlook Web Access에서 스마트 카드 인증을 사용하는 방법에 관한 기사도 포함되어 있습니다. 회사 리소스에 대한 액세스를 허용하기 전에는 항상 물리적인 인증 방식을 요구하는 것이 좋습니다. 스마트 카드를 사용하면 어디에서나 이러한 인증 방식을 구현할 수 있습니다. Exchange Server의 재해 복구 기능, Exchange Server 2007에서 공용 폴더를 SharePoint로 바꾸는 방법, Windows Mobile 6에서 모바일 보안을 개선하는 방법 등에 대한 기사도 준비되어 있습니다. 물론 메시징에 관심 있는 독자라면 꼭 읽어봐야 할 Exchange Queue & A 칼럼도 준비해 두었습니다. 아, 방금 필자의 네트워크에 세 명이 더 추가되었군요. 인사를 해야 할지, 자는 척 해야 할지 알아봐야겠습니다.
—Joshua Trupin

많은 Microsoft 기술 전문가들께서 도움을 주셨습니다. Kristian Andaker, Chris Corio, Jim Harrison, Chad Jones, Michael Lee, Shawn McGrath, Michael Murgolo, Eric Perlin, Michelle Rutzer, Gavriella Schuster, Jim Truher에게 감사를 전합니다.


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

원격 연결 모니터링
RecordTS
www.tsfactory.com
터미널 서버 또는 원격 데스크톱 세션을 감시할 수 있다면 좋겠다는 생각을 해본 적이 있습니까? 원격 데스크톱 세션으로 인해 웹 사이트가 중단되기 전에 어떤 현상이 발생했는지 확인해야 할 수도 있고, 터미널 서버에서 재현할 수 없는 문제가 발생할 수도 있습니다. 또는 지적 재산의 보안 문제가 우려되거나, 테스트 환경에서 SharePoint® 서버를 구성한 방법에 대해 간단히 기록하거나 프레젠테이션을 작성해야 하는 경우도 있을 수 있습니다. 이러한 상황이라면 TSFactory에서 제공하는 RecordTS가 답이 될 수 있습니다. 참고로 TSFactory는 터미널 서버 관련 Microsoft MVP인 Cláudio Rodrigues가 설립한 회사입니다.
RecordTS는 Terminal Server 버전과 Remote Desktop 버전으로 제공되며 모니터링할 연결 유형에 따라 적합한 버전을 선택하면 됩니다. 제품 웹 사이트에 나와 있듯이 RecordTS는 터미널 서버 또는 원격 데스크톱 세션의 "감시 카메라" 역할을 합니다. 이 소프트웨어는 기본적으로 터미널 서비스와 최종 사용자 세션 간의 프록시 역할을 하므로 세션에서 수행된 모든 동작과 작업 내역을 기록할 수 있습니다.
이 소프트웨어는 직관적으로 설치 프로세스를 안내하는 간단한 마법사를 제공합니다. 이 마법사에서는 저장된 세션을 보관할 데이터 디렉터리를 지정할 수 있습니다. 설치 프로세스를 실행하면 서비스를 구성하는 데 사용되는 MMC 스냅인, RecordTS 서비스 및 기록된 세션을 검토할 수 있는 세션 재생 유틸리티가 설치됩니다. MMC 스냅인을 열고 서비스 폴더를 마우스 오른쪽 단추로 클릭하면 서비스 실행에 사용할 포트 등의 설정을 구성할 수 있는 속성 화면이 나타납니다. (여기서 예로 든 포트 설정은 특히 터미널 서비스 세션을 비표준 포트로 전환한 경우에 유용합니다.) Storage 탭에서는 Default Storage Folder를 로컬 폴더나 UNC 경로로 설정할 수 있습니다.
저장된 세션의 디렉터리 구조를 구성할 수도 있습니다. 예를 들어 도메인, 사용자, 날짜 및 시간을 기준으로 데이터를 분류하여 저장할 수 있습니다. 또한 로컬 디스크에 세션을 저장할 때 가장 중요한 설정일 수 있는 디스크 공간이 부족한 경우의 서비스 작동 방식을 설정할 수도 있습니다. 즉, 높은 보안 수준을 유지하려는 경우에는 새 연결을 허용하지 않고 현재 세션의 연결을 끊도록 선택하거나, 생산성이 저하되지 않도록 하려는 경우에는 세션 기록을 중지하도록 선택할 수 있습니다.
Security 탭에서 기존 인증서를 선택하거나 자체 서명된 인증서를 새로 만들어 모든 기록된 세션을 디지털 서명할지 여부를 지정할 수 있습니다. 이 설정은 감사 또는 정책 준수 확인 용도로 도구를 사용하려는 경우에 유용합니다. Users 탭에서는 세션을 기록할 수 있는 사용자와 기록할 수 없는 사용자를 지정할 수 있습니다.
한마디로 RecordTS는 보안 및 감사에 매우 유용한 도구로, 사용 방법 안내 프레젠테이션을 만드는 등의 다양한 용도로 사용할 수 있습니다. 필자도 개인적으로 매우 유용하게 사용하고 있습니다.

가격: RecordTS Remote Desktop Edition (최소 495달러), RecordTS Terminal Services Edition(최소 995달러)

호스트 모니터링
Advanced Host Monitor
www.ks-soft.net
중요 업무용 인프라의 운영 지원 담당자에게는 효과적이고 안정적인 호스트 모니터가 필요합니다. 인프라가 100% 신뢰할 수 있는 안정적인 하드웨어와 결함 없는 안정적인 응용 프로그램 스택으로 구성되어 있더라도, 보조 시스템이 필요한 상황을 파악할 수 있는 완전한 기능의 호스트 모니터가 필요하기 마련입니다.
KS-Soft의 Advanced Host Monitor는 58가지 테스트 방식과 30가지 경고 방식을 제공하여 인기를 끌고 있습니다. 이 도구를 사용하면 프로세스 정보, 사용자 세션, 평균 부하, 메모리 등 다양한 항목을 확인할 수 있습니다. 또한 Windows® 전용 테스트, Linux/UNIX 테스트 및 플랫폼에 관계없이 실행 가능한 검사 기능을 제공합니다. 단, Linux/UNIX 테스트의 경우 Windows 테스트와는 달리 클라이언트에 Remote Monitoring Agent를 설치해야 합니다.
또한 WMI(Windows Management Instrumentation) 모니터링 테스트 기능도 제공합니다. 여기에는 적절한 항목을 쉽게 찾아 선택할 수 있을 뿐만 아니라 쿼리를 실행하여 필요한 데이터를 얻을 수 있는지 확인할 수 있는 WMI Explorer가 내장되어 있어 이를 통해 올바른 쿼리를 탐색할 수 있습니다.
Advanced Host Monitor는 다양한 데이터베이스 관련 테스트 기능도 제공합니다. 대표적인 예로 ODBC 데이터 원본의 가용성을 확인하고, 쿼리를 실행하고, 알려진 값을 기준으로 결과를 확인하는 데 사용할 수 있는 ODBC 쿼리 테스트 기능이 있습니다. 이 외에도 SQL Server™, MySQL, Oracle, Postgres, Sybase 및 Interbase 데이터베이스 서버의 호스트가 들어오는 세션을 수신할 수 있는지 확인하는 기능도 있습니다.
이 프로그램은 사용 가능한 공간, 할당량, 폴더 또는 파일 가용성, UNC 공유에 대한 가용성 등을 확인할 수 있는 다양한 디스크 및 파일 관련 테스트 기능도 제공합니다. 뿐만 아니라 일반 TCP/UDP 검사, SMTP, POP3 및 IMAP에 대한 메일 테스트, 메일 릴레이 검사, HTTP 콘텐츠 및 타이밍 테스트 등의 표준 네트워크 관련 테스트 기능도 제공합니다. 또한 여기에는 모니터 테스트 상호 종속성을 설정하여 검사를 단계화하는 유용한 옵션도 있습니다. 테스트는 규칙적 또는 불규칙적인 일정으로 예약할 수 있기 때문에 테스트 방식을 세부적으로 제어할 수 있습니다.
경고 방식으로는 SMS 메시지 전송, ICQ, 전자 메일, 이벤트 로그, 팝업 창 등이 있습니다. 또한 이러한 경고에 의해 서비스를 시작 또는 중지하거나, 시스템을 다시 부팅하거나, 외부 프로그램을 실행하는 등의 다른 이벤트가 트리거될 수도 있습니다.
Advanced Host Monitor의 Professional 버전과 Enterprise 버전에는 KS-Soft IP 도구가 포함되어 있습니다. 이러한 도구는 SNMP 트랩 메시지를 검색 및 처리할 수 있도록 하는 SNMP 트랩 감시자와 포트/프로토콜 스캐너를 비롯한 19가지 TCP/IP 관련 네트워크 유틸리티의 집합입니다. 또한 두 버전 모두에는 시간에 따라 기록된 모니터링 데이터를 분석하여 작동 시간 보고서 및 성능 분석 검토에 사용할 수 있는 로그 분석기와 보고 구성 요소도 포함되어 있습니다.
인터페이스 자체에서 여러 테스트에 대한 간단한 내용을 동시에 살펴볼 수 있는 기능을 제공하므로 이 기능을 통해 모니터링된 호스트의 문제점을 쉽게 파악할 수 있습니다.
가격: Enterprise 버전(599달러), Professional 버전(275달러)

디스크 정리
WinDirStat
www.windirstat.info
집이나 아파트와 마찬가지로 파일 저장소 위치에도 그 당시에는 유용했지만 시간이 지나면서 점차 필요 없게 되어 공간만 차지하는 것들이 쌓이게 됩니다. 집이라면 이럴 때 봄맞이 대청소를 하면 되겠지만 디렉터리 트리 구조의 경우에는 어떤 항목을 제거해야 할지 시각적으로 파악하기가 쉽지 않습니다. 다행히 사용자 환경에서 공간만 차지하는 불필요한 파일을 확인할 수 있도록 표시해 주는 뛰어난 도구가 있습니다.
Linux KDE kdirstat을 모델로 삼아 GPL에서 개발한 WinDirStat이라는 Windows 기반 도구는 선택한 드라이브의 파일을 여러 다른 색으로 구분된 사각형으로 보여 줍니다. 사각형 크기로 파일의 크기를 알 수 있으므로 불필요하게 공간만 차지하는 오래된 ISO 또는 ZIP 파일을 쉽게 찾을 수 있습니다.
로컬 드라이브를 하나 이상 선택하면 프로그램이 디렉터리 트리를 검사하여 메모리 내에 파일에 대한 맵을 만듭니다. 그리고 시각화된 정보를 GUI의 아래쪽 창에 표시합니다. 아래쪽 창에서 색으로 구분된 사각형을 클릭하면 위쪽에 표시되어 있는 Windows 탐색기와 유사한 창에서 해당 파일의 위치가 나타납니다. 이 위쪽 창에서 파일 크기, 파일을 마지막으로 변경한 날짜, 기타 특성 등 유용한 정보를 확인할 수 있습니다. 또한 하위 트리에서 해당 파일이 차지하는 비율도 확인할 수 있습니다.
편리하게도 파일 형식별로 고유한 색이 사용되며, 오른쪽 위에 표시되어 있는 검색된 파일 형식을 클릭하면 아래쪽 창에서 해당 형식의 파일이 모두 선택됩니다. 이 기능은 사용자가 파일 서버에 숨겨둔 MP3를 모두 찾아야 하는 경우 등에 유용하게 사용할 수 있습니다. 또한 이러한 파일이 파티션에서 차지하는 바이트 비율도 알 수 있습니다.
가격: 무료 다운로드

서평
Enemy at the Water Cooler
syngress.oreilly.com
대부분의 기업은 인터넷 연결을 필요로 하지만, 동시에 기업 정보 인프라의 "내부"와 "외부"를 구분하는 연결 지점을 악용하여 외부에서 끊임없이 침입하려 한다는 사실을 통해 그 위험성도 잘 알고 있습니다. 그러나 조직 내에 존재하는 더 큰 위험성에 대해서는 간과하는 경우가 많습니다. Brian Contos가 집필한 Enemy at the Water Cooler: Real-Life Stories of Insider Threats and Enterprise Security Management Countermeasures(Syngress, 2006)에서는 이러한 내부자 위협의 위험성을 잘 보여 주고 있습니다.
이 책을 통해 Contos는 과거의 실제 공격 사례와 관련 업체가 입은 피해를 소개하면서, 보안은 "사람, 프로세스 그리고 기술이 일체화"되어 지속적으로 수행해야 할 작업임을 이야기하고 있습니다. 그리고 내부자 위협을 방지하는 데 ESM(Enterprise Security Management) 소프트웨어 솔루션이 얼마나 효과적인지를 설명합니다.
비록 ArcSight의 보안 책임자로서 Contos가 회사에서 자체 개발한 ESM 소프트웨어 솔루션에 크게 의존할 수밖에 없는 입장이기는 하지만, 그렇다고 이 솔루션의 전반적인 가치가 떨어지는 것은 아닙니다. 이 책에서는 세부 기술을 자세히 소개하지는 않지만 다른 조직의 피해 사례를 살펴보고, ESM 솔루션을 효과적으로 구현했을 때 내부 공격에 노출되는 위험을 얼마나 줄일 수 있는지를 알아봄으로써 사용자 조직에서 보안 프로세스를 어떻게 향상시킬 수 있는지에 대한 좋은 방법을 찾을 수 있습니다.
배경 정보를 소개하는 장인 "Cyber Crime and Cyber Criminals 101"에서는 주의해야 할 여러 가지 공격 유형 중 일부와 공격의 동기에 대해 간단히 소개하고 있습니다. 또한 버퍼 오버플로, 코드 패킹, 워홀 위협(Warhol Threat) 등 몇 가지 공격 기법에 대해서도 간단히 설명합니다.
다음 장에서는 내부자가 비즈니스에 피해를 줄 수 있는 방법, 위험 관리의 개념, 기술적 관점에서 본 위협 해결 방법 등 내부자 위협에 대해 보다 구체적인 정보를 제공합니다. 기술적인 관점에 대한 부분에서는 최소 권한, 강력한 인증, 액세스 제어, 사고 감지 및 관리에 대해 간단히 설명하고 이에 이어 ESM 소프트웨어 솔루션에 대해 설명합니다. 다시 한번 강조하지만 비록 이 책에서는 ArcSight 제품만 소개하고 있지만 주요 특징에 대한 설명은 다른 시스템에도 적용 가능합니다.
이 책에서는 산업 분야와 환경을 망라한 여러 사례를 통해 다양한 내부자 위협 유형에 대한 자세한 내용과 위협 감지 방법 및 경우에 따라서 위협을 완화하는 방법을 설명합니다. 이러한 사례 연구는 일부 사용자 비즈니스 사례에도 참고할 수 있을 뿐만 아니라 사용자 환경에서 내부자 공격에 대한 위험을 줄일 수 있는 방안을 찾는 데에도 도움이 될 것입니다.
가격: 49.95달러

Toolbox 칼럼에 대한 의견 보내기
여기에서 다루었으면 하는 도구나 유틸리티가 있으면 tntools@microsoft.com 주소로 저자에게 알려 주십시오.

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


 SQL Q&amp;A: 클러스터링의 작동 원리, 원인을 알 수 없는 지연, SA 계정 외
SQL Q&A
클러스터링의 작동 원리, 원인을 알 수 없는 지연, SA 계정 외
편집자: Nancy Michell

Q: 클러스터링의 작동 원리에 대해 자세히 알고 싶습니다. SQL Server™ 2005를 실행하는 64비트 Windows Server® 2003, SQL Server Reporting Services(SSRS) 웹 팜(보고서 서버의 수평 확장 배포), SSRS TempDB 카탈로그 서버, 연결된 서버를 통해 타사 데이터베이스에서 데이터를 가져와 SSRS용으로 저장하는 SQL Server로 환경을 구성하려고 합니다.
또한 3노드 액티브/액티브/패시브 클러스터를 사용하려고 합니다. 노드 1은 액티브 노드로 설정하여 타사 데이터베이스에서 가져온 데이터를 저장하고, 노드 2도 액티브 노드로 설정하여 SSRS 카탈로그를 저장하려고 합니다. 마지막으로 노드 3은 패시브 노드로 설정하여 노드 1이나 노드 2에 오류가 발생할 경우 장애 조치용으로 사용하려고 합니다. 도움을 주실 수 있을까요?

A: 안타깝게도 많은 사람들이 SQL Server 클러스터링과 관련하여 액티브/액티브 및 액티브/패시브의 개념을 잘못 이해하고 있는 것 같습니다. 대부분 SQL 클러스터링이 데이터베이스나 SQL 인스턴스 하나를 여러 서버에 "수평 확장"하도록 지원하는 것으로 이해하고 있지만 사실은 그렇지 않습니다. SQL Server에 액티브/액티브 데이터베이스나 인스턴스라는 것은 없습니다. "인스턴스"란 관련 데이터베이스와 함께 설치된 SQL Server를 의미합니다. SQL Server 인스턴스 하나당 지원되는 클러스터링은 액티브(1) 대 패시브(n)입니다. 이때 n은 1에서 7까지의 값이며 설치된 SQL Server 버전에 따라 다릅니다. 바로 이 때문에 SQL Server 클러스터링을 장애 조치 클러스터링이라고 하는 것입니다.
이러한 개념을 이해하고 나면 한 노드 집합에 장애 조치 클러스터링의 여러 인스턴스를 설치하는 것을 고려해 볼 수 있습니다. 예를 들어 공유 디스크를 사용하는 세 개의 물리적 서버가 있는 경우 기본적으로 액티브 상태인 인스턴스 하나를 노드 1에 두고 기본적으로 액티브 상태인 두 번째 인스턴스를 노드 2에 둘 수 있으며, 두 노드 모두 노드 3으로 장애 조치가 이루어지도록 할 수 있습니다. 이 두 인스턴스는 완전히 별개이며 서로 데이터를 공유하지 않으므로 액티브/액티브가 아닙니다. 두 인스턴스는 모두 액티브/패시브며 동일한 장애 조치 인스턴스를 공유합니다. 두 인스턴스 모두 노드 3으로 장애 조치가 수행되는 경우 시간이 경과되면서 이러한 로드로 인해 노드 3의 성능이 저하되는지 확인해야 합니다. 본래 장애 조치는 장애 조치 노드의 처리 성능에 의존합니다. 로드가 가장 많을 때 정상적인 작동 상태에서 처리를 위해 두 개의 노드가 필요하다고 가정할 경우 노드 3은 두 노드에 일반적으로 할당되는 최대 로드를 감당하기가 어렵습니다.
하지만 클러스터를 실행할 수 있는 하드웨어의 가격이 상대적으로 고가인 점을 감안하면 사람들이 두 개의 주 노드에서 동시에 오류가 발생하여 전체 로드를 한 노드에 넘겨야 하는 가능성에 그다지 무게를 두고 있지 않다는 것을 이해할 수 있습니다. 이러한 생각으로 100% 장애 조치 성능을 갖춘 하드웨어를 구입하는 대신 위험을 감수하는 결정을 내리게 되는 것입니다.
몇 가지 좋은 소식도 있습니다. SQL Server 2005는 단일 SAN을 사용하는 클러스터링을 통해 클러스터보다 빠르게 장애 조치를 수행하고 데이터 복사본까지 유지할 수 있는 대체 기술을 포함하여 보다 다양한 HA(고가용성) 옵션을 제공합니다. 이러한 옵션으로는 미러링, 피어 투 피어 복제 등이 있습니다. 이러한 새 대체 기술과 함께, 다양한 HA 기능을 조합할 수 있는 몇몇 기술을 비롯하여 모든 종류의 요구 사항을 충족시킬 수 있는 훨씬 더 다양한 옵션을 사용할 수 있습니다.
이제 Microsoft® Cluster Configuration Validation Wizard(ClusPrep)를 다운로드하여 HCL(Hardware Certification List) 테스팅 대신 사용할 수 있습니다. HCL을 사용하는 경우 구성이 클러스터링에서 지원 가능한지 확인하는 데 몇 달이 소요될 수도 있었습니다. 이제 이 하드웨어 유효성 검사 도구를 통해 DBA는 인증된 하드웨어를 적절히 배치하는 데 드는 시간과 비용을 크게 줄일 수 있게 되었습니다. 이 도구는 이기종 하드웨어의 유효성을 검사하여 이러한 하드웨어를 한 클러스터 노드 집합 내에 배포하는 것도 가능하게 합니다.

Q: 제 컴퓨터 중 하나에서 삭제 프로시저를 실행했는데 12시간이 지난 후에도 완료되지 않고 있습니다. 작업이 차단된 것은 아닙니다. 가장 느린 쿼리 계획을 살펴보니 한 트리거가 87,327초 동안 실행 중인데 이 트리거에서 프로시저가 지연되고 있는 것 같습니다. 어떻게 하면 지연되고 있는 문을 확인할 수 있을까요?

A: 여러 가지 이유로 트리거 내의 루프가 종료되지 않고 있을 가능성이 높습니다. 오랜 시간 동안 작업이 지연되는 경우 현재 실행 중인 문을 보려면 그림 1의 코드를 실행해 보십시오. 그러면 현재 실행 중인 문을 확인할 수 있는데, 이 문으로 인해 컴퓨터가 지연되고 있을 가능성이 큽니다.
Figure 1 현재 실행 중인 문 찾기 (Close Figure 1)
-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20),
        @start int,
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle,
        @start = stmt_start,
        @end = stmt_end
FROM Master..sysProcesses(NOLOCK)
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

Q: 방화벽을 통해 트랜잭션 복제를 지원해야 합니다. 게시자와 배포자는 방화벽 외부에 있고 구독자는 방화벽 내부에 있습니다. 구독자는 1433 포트에서 수신하도록 설정되어 있으며, 컴퓨터 이름은 게시자의 경우 PUBMACHINE, 배포자의 경우 DISTMACHINE, 구독자의 경우 SUBMACHINE입니다. 초기 스냅숏 및 게시 밀어넣기에 성공하려면 어떤 포트를 열어야 합니까?

A: 밀어넣기 구독을 사용하는 경우 배포 에이전트가 배포자 컴퓨터(방화벽 외부)에서 실행되고 스냅숏 에이전트에 의해 생성된 스냅숏 파일에 로컬로 액세스할 수 있으므로 SQL Server 포트(이 경우 1433)만 열어도 충분합니다. 그러나 끌어오기 구독을 사용하는 경우에는 구독자 컴퓨터에서 실행되는 배포자 에이전트가 방화벽을 통해 스냅숏 파일에 액세스할 수 있어야 합니다. 다음과 같은 옵션을 고려할 수 있습니다.
방화벽 외부의 파일 공유에서 스냅숏 파일에 액세스할 수 있다고 가정할 경우, 방화벽을 통해 Windows® 파일 공유 포트를 열어 방화벽 내부에서 실행되는 배포 에이전트가 방화벽 외부에 있는 스냅숏 파일에 액세스하도록 할 수 있습니다. 단, 이 경우 인프라의 다른 부분에서 발생할 수 있는 보안 문제를 고려해야 합니다. 기본 스냅샷 위치(SSMS 기본값)로 로컬 경로를 구성한 경우 배포 에이전트의 /AltSnapshotFolder 옵션을 사용하여 스냅샷 파일 선택 위치를 다시 정의해야 할 수도 있습니다.
스냅샷 파일 전송 시 FTP를 사용하도록 복제를 구성할 수도 있습니다. 이 경우 포트 21을 열어야 합니다.

Q: SQL Server 2005의 SA 계정을 사용하지 않을 경우의 단점과 이렇게 하면 정말로 보안에 도움이 되는지 알고 싶습니다. 이 질문과 관련된 백서가 있을까요?

A: SQL Server 2005를 새로 설치한 경우, 혼합 모드를 사용하지 않으면 SA 계정이 기본적으로 사용되지 않도록 설정되며 이를 위한 임의 암호가 생성됩니다. 이 계정을 사용하지 않도록 직접 설정할 수도 있습니다. 이 질문과 관련된 백서는 없습니다. 하지만 최상의 구현 사례 백서에서 로그인을 사용하지 않도록 설정하거나 이름을 바꾸는 자세한 내용을 볼 수 있습니다.
SA 계정을 손상시키려는 시도로부터 컴퓨터를 보호하려면 계정 이름을 바꿔 보십시오. 단, 사용하지 않도록 설정한 계정을 나중에 사용하는 경우 암호를 새로 설정해야 합니다.
SA 계정을 사용하지 않을 경우 보안에 정말로 도움이 되는지에 대해 말씀드리겠습니다. 이 계정을 사용하지 않음으로써 보안이 개선되는 까닭은 계정이 사용되지 않는 동안에는 암호 추측 시도가 아무런 효과가 없기 때문입니다. 해커나 바이러스가 어떤 방법을 사용하더라도 잠긴 계정에 대한 무작위 공격은 성공하지 못합니다. SA 계정의 이름을 바꾸거나 사용하지 않도록 설정하면 SA 계정을 통해 연결하는 응용 프로그램이 제대로 작동하지 않게 됩니다. 따라서 먼저 이러한 응용 프로그램을 찾아서 수정하거나 제거해야 합니다. 앞에서도 언급했듯이 계정을 다시 사용하도록 설정하기 전까지는 해당 계정으로 데이터베이스에 연결할 수 없습니다. 또한 이전에 인증 절차가 실패했으므로 실패한 시도는 공격받은 시스템에 별로 해가 되지 않습니다.

Q: 대용량 OLTP(Online Transaction Processing) 데이터베이스 중 하나에 데이터 파일 크기의 두 배인 로그 파일이 있습니다. 다음 명령을 사용하여 로그 파일의 크기를 어느 정도 줄였는데 이보다 더 줄이고 싶습니다.
backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

A: backup database 문을 backup log 문으로 변경해야 합니다. 또는 데이터베이스를 단순 복구 모드로 설정한 다음 shrinkfile 문을 실행할 수도 있습니다. 로그 축소가 끝나면 데이터베이스를 다시 이전 복구 모드로 설정한 다음 데이터베이스를 백업합니다. 이렇게 해도 원하는 크기로 축소되지 않으면 dbcc opentran 문을 사용하여 열려 있는 트랜잭션이 있는지 확인하십시오. 자세한 내용은 다음 기술 자료 문서를 참조하십시오. support.microsoft.com/kb/907511.

Q: 예약된 SQL Server 에이전트 작업 중 장애 조치가 수행될 경우 장애 조치가 끝난 후에 이 작업은 어떻게 됩니까? 수동으로 다시 시작해야 합니까?

A: 다른 프로세스가 실행 중인 경우가 아니면 작업을 수동으로 시작해야 합니다. 작업을 수동으로 다시 시작하지 않으려면 작업 완료 시 테이블을 업데이트하는 스크립트를 작성해 보십시오. 값이 1이면 작업이 실행되었음을 나타내고, 값이 1이 아니면 작업이 완료되지 않았으며 나중에 두 번째 작업이 발생하고 시작 명령을 실행함을 나타냅니다. 따라서 작업이 실행되는 동안 장애 조치가 수행되어 작업을 다시 실행해야 하는 경우 스크립트를 작성하면 다음 업무일 이전에 반드시 완료되어야 하는 중요한 야간 작업에 대해 염려할 필요가 없습니다.
팁: 업그레이드 및 DBCC UPDATEUSAGE
SQL Server 2000에서 SQL Server 2005로 업그레이드할 계획입니까?
그렇다면 데이터베이스를 업그레이드한 후 바로 DBCC UPDATEUSAGE를 실행하십시오.
DBCC UPDATEUSAGE는 카탈로그 뷰의 잘못된 페이지 및 행 개수를 보고하고 수정합니다. 정확하지 않은 수치가 있으면 sp_spaceused 시스템 저장 프로시저가 잘못된 공간 사용률 보고서를 반환할 수 있으므로 반드시 수정해야 합니다. SQL Server 2005에서는 이러한 값이 항상 올바르게 유지되므로 데이터베이스에서 잘못된 개수가 발견되는 일이 없습니다. 그러나 SQL Server 2005로 업그레이드된 데이터베이스에는 잘못된 개수가 포함될 수 있으므로 업그레이드 후 DBCC UPDATEUSAGE를 실행해야 합니다.
DBCC UPDATEUSAGE의 작동 원리는 다음과 같습니다. DBCC UPDATEUSAGE는 테이블 또는 인덱스에 있는 각 파티션의 행 수, 사용된 페이지 수, 예약된 페이지 수, 리프 페이지 수 및 데이터 페이지 수를 수정합니다. 시스템 테이블에 개수 오류가 없으면 DBCC UPDATEUSAGE는 데이터를 반환하지 않습니다. 개수 오류가 발견되고 수정되었으며 사용자가 WITH NO_INFOMSGS를 사용하지 않은 경우에는 DBCC UPDATEUSAGE는 시스템 테이블의 업데이트된 행과 열을 반환합니다.
DBCC UPDATEUSAGE는 공간 사용률 카운터를 동기화하는 데도 사용할 수 있습니다. 대용량 테이블이나 데이터베이스에 대해 DBCC UPDATEUSAGE를 실행하는 경우 시간이 많이 걸릴 수 있으므로 일반적으로 sp_spaceused가 잘못된 값을 반환한다고 의심되는 경우에만 DBCC UPDATEUSAGE를 사용하는 것이 좋습니다. 선택적 매개 변수를 사용하면 sp_spaceused에서 테이블이나 인덱스의 공간 정보를 반환하기 전에 DBCC UPDATEUSAGE를 실행하도록 할 수 있습니다.
SQL Server 2005의 DBCC CHECKDB는 페이지 또는 행 개수가 음수일 경우 이를 감지하도록 향상되었습니다. DBCC CHECKDB는 음수를 감지하면 DBCC UPDATEUSAGE를 실행하여 이 문제를 해결하라는 권장 메시지와 경고를 출력합니다. SQL Server 2005로 업그레이드했기 때문에 이 문제가 발생한 것처럼 보일 수도 있지만, 업그레이드 전부터 잘못된 개수가 있었는지 확인해야 합니다.
다음 예제는 현재 데이터베이스의 모든 개체에 대해 페이지나 행 개수 또는 둘 모두를 업데이트하는 방법을 보여 줍니다. 다음 명령에서는 데이터베이스 이름으로 0을 지정하고 DBCC UPDATEUSAGE는 현재 데이터베이스에 대해 업데이트된 정보를 보고합니다.
DBCC UPDATEUSAGE (0);
GO
예를 들어 AdventureWorks의 페이지나 행 개수 또는 둘 모두를 업데이트하되 정보 메시지를 표시하지 않으려면 다음과 같이 데이터베이스 이름으로 AdventureWorks를 지정하고 모든 정보 메시지를 표시하지 않도록 설정하는 다음과 유사한 명령을 실행하십시오.
USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO
자세한 내용은 SQL Server 온라인 설명서의 DBCC UpdateUsage를 참조하십시오.

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.


 Utility Spotlight: SMSMap
Utility Spotlight
SMSMap
Jeff Tondt
이 기사의 코드 다운로드: UtilitySpotlight2007_07.exe (2477KB)

"백문이 불여일견이다"라는 속담이 있는데, 이 유명한 속담은 그림 한 장으로 복잡한 이야기를 쉽게 전달할 수 있으며 이미지 한 개가 장황한 텍스트보다 훨씬 더 효과적임을 나타냅니다. 또한 많은 양의 데이터를 빠르게 전달해야 하는 시각화의 목표도 적절히 설명해 줍니다.
필자를 비롯한 System Management Server(SMS) 애호가들에게는 전반적인 SMS 계층 구조를 하나의 그림으로 그려 보는 것이 인프라의 구조를 파악하는 데 많은 도움이 됩니다. 이러한 그림은 관리 담당자에게 SMS 마이그레이션 계획 이전과 이후의 상황을 보여 주는 데 활용할 수 있습니다. 어떤 문제 해결 상황에서 이 같은 다이어그램은 문제에 대한 해결책을 찾거나 적어도 다른 사람들로부터 도움을 구하는 데 매우 유용합니다. 물론 책임감 있는 SMS 관리자라면 문제 해결이 아닌 다른 이유로도 시스템 계층 구조를 문서화해야 할 필요가 있습니다.

그림 그리기
물론 이러한 다이어그램을 직접 그릴 수도 있습니다. 소매를 걷고 직접 SMS 계층 구조를 그리고 사이트 설정을 문서화할 수도 있습니다. 그러나 Microsoft® Operations Manager(MOM)로 SMS 서버를 모니터링하고 있다면 이를 통해 SMS 계층 구조를 다이어그램으로 나타낼 수 있습니다. 물론 MOM은 그림 전용 프로그램이 아니며 사이트 설정을 문서화하지도 않습니다. 다른 방법이나 손쉬운 도구도 있긴 하지만, 현재로서는 적어도 필자의 마음에 드는 적절하게 세련된 그림을 그리고 사이트 설정을 문서화하는 데 도움이 되는 도구를 찾지 못했습니다.
그래서 직접 이런 도구를 만들기로 결심했고 그 결과 SMSMap 1.0이 탄생하게 되었습니다. SMSMap은 SMS SDK의 SMS 관리 라이브러리를 사용하며 COM을 통해 Microsoft Visio®를 자동화하는 Visual Basic® .NET 응용 프로그램입니다. 이 유틸리티는 대상 SMS 사이트 서버를 쿼리한 다음 시각적으로 뛰어난 Visio 다이어그램을 만들고 사이트 설정을 XML 파일로 내보냅니다. XML을 선택한 이유는 사이트 설정을 문서화하는 가장 호환성이 뛰어난 방식이기 때문입니다. 필자는 다른 SMS 서버와 관련된 실제 서버뿐 아니라 SMS 역할도 보여 주도록 했습니다. 덕분에 Visio 레이어로 다이어그램을 이리저리 수정하여 여러 관점에서 SMS 계층 구조를 볼 수 있게 되었습니다.
그림 1 방사형 형식
그림 1 방사형 형식
현재는 이 프로그램에서 Visio 다이어그램에 여섯 가지 형식 중 하나를 선택하여 사용할 수 있습니다. 예를 들어 그림 1은 방사형 형식을 사용하여 매우 단순한 SMS 계층 구조를 보여 주며 그림 2는 동일한 계층 구조를 순서도를 사용하여 보여 줍니다. 이 유틸리티는 이보다 규모가 큰 계층 구조에도 사용할 수 있지만 여기서는 설명을 간단히 하기 위해 단순한 계층 구조를 사용했습니다.
그림 2 순서도 형식
그림 2 순서도 형식
언젠가는 모든 사이트 설정을 문서화할 수 있는 수준으로 SMSMap이 발전할 것입니다. 현재는 SMS 사이트 역할과 모든 경계만 문서화합니다. 간단하게 훨씬 많은 사이트 설정을 XML 파일로 내보낼 수도 있습니다.

SMSMap 사용
SMSMap의 소스 코드와 설치 파일은 TechNet Magazine 웹 사이트에서 다운로드할 수 있습니다. SMSMap을 설치하려면 설치 과정을 안내하는 SMSMapSetup.msi를 실행하기만 하면 됩니다. SMSMap은 Visio를 사용하므로 Visio도 설치되어 있어야 합니다. 설치한 후에는 C:\Program Files\Microsoft\smsmap\smsmap.exe(SMSMap을 기본 위치에 설치한 경우)를 실행하십시오.
SMSMap은 어느 컴퓨터에서나 실행할 수 있습니다. 그런데 SMSMap을 사이트 서버에서 실행해야 할 필요는 없습니다. 또한 대부분의 SMS 사이트 서버에는 Visio가 설치되어 있지 않습니다. 쿼리를 실행할 SMS 사이트 서버 이름을 입력합니다. 전체 계층 구조를 쿼리하려는 경우 중앙 사이트 이름을 입력합니다. 하위 주 사이트 서버의 이름을 입력할 수도 있지만, 이 경우 해당 하위 주 사이트 아래의 계층 구조만 얻을 수 있습니다. 다음으로, SMS를 쿼리할 수 있는 권한이 있는 계정을 domain\username 형식으로 입력하고 계정의 암호를 입력합니다. 암호는 표시되지 않으므로 다른 사용자가 보는 곳에서 입력해도 괜찮습니다.
여섯 개의 라디오 단추를 사용하여 레이아웃을 선택하고 그림에 SMS 역할을 표시할지 여부를 선택할 수 있습니다. 이러한 확인란은 Options(옵션) 탭에 있습니다. Draw(그리기) 단추를 누르면 유틸리티가 시작됩니다. 이 유틸리티는 먼저 Visio를 사용할 수 있는지 확인한 다음 지정된 SMS 주 사이트 서버를 쿼리하고 Visio 다이어그램에 개체를 추가합니다. SMSMap이 개체를 추가하는 동안에는 Visio 다이어그램이 그다지 세련돼 보이지 않을 수도 있습니다. 그러나 마지막에는 사용자가 처음에 지정했던 형식으로 개체가 알맞게 구성됩니다.
자세히 알아보기
지금까지는 SMSMap으로 SMS 계층 구조를 문서화하는 이유와 그 방법을 살펴보았습니다. 개발 업무를 줄이고 싶은 개발자들을 위해 이제부터 이 유틸리티의 작동 방식에 대해 좀 더 자세히 알아보겠습니다.
SMSMap은 관리되는 SMS 사이트 서버 인터페이스를 사용하여 SMS 정보를 수집하고 Visio 주 Interop 어셈블리를 사용하여 필요한 모든 도형이 준비된 Visio 다이어그램을 생성합니다. SMS 2003 SDK 버전 3.1에는 관리되는 SMS 사이트 서버 인터페이스의 최신 릴리스가 포함되어 있습니다. 이 관리 인터페이스 집합을 이용하면 모든 Microsoft .NET Framework 사용 언어나 응용 프로그램을 통해 SMS 사이트 서버에 연결하여 이를 구성할 수 있습니다.
이러한 인터페이스는 System.Management 네임스페이스를 사용하여 Windows® Management Instrumentation(WMI)을 통해 SMS 공급자와 상호 작용합니다. 이 인터페이스를 사용하려면 C#, Visual Basic .NET 등의 .NET 호환 언어를 사용하여 응용 프로그램을 개발해야 하며 .NET 어셈블리에서 SMS SDK와 함께 제공한 Microsoft.SystemsManagementServer.Automation.dll을 참조해야 합니다.
일관된 개체 지향 모델을 제공하기 위해 .NET Management 클래스에서는 WMI 개체 모델의 특유한 표현법이 대부분 제거되었습니다. WMI 연결, 개체 열거, 메서드 실행, 개체 삭제, 개체 검색 및 이벤트 캡처 등의 기본 작업을 모두 .NET Management 클래스를 통해 수행할 수 있습니다.

Visio 주 Interop 어셈블리
주 Interop 어셈블리를 사용하면 Visio 같은 COM 응용 프로그램을 관리 코드를 통해 프로그래밍 방식으로 제어할 수 있습니다. Visio 주 Interop 어셈블리를 사용하면 Visio의 기능을 관리 응용 프로그램에 통합 및 확장할 수 있습니다.
컴퓨터에 .NET Framework가 이미 설치되어 있는 경우 나중에 Visio를 설치하면 컴퓨터의 GAC(전역 어셈블리 캐시)에 Visio 주 Interop 어셈블리가 추가됩니다. 그러면 관리 응용 프로그램에서 Visio 주 Interop 어셈블리에 대한 참조를 추가할 수 있습니다.
프로젝트에 대한 참조를 추가한 후에는 관리 응용 프로그램에서 Visio 개체를 사용할 수 있습니다. Visio에는 클래스, 인터페이스 및 열거형을 제공하는 광범위한 개체 모델이 있으므로 프로그래밍 방식으로 다이어그램을 만들 수 있습니다.

프로그램 흐름
지금까지 Visio와 SMS의 기본 구성 요소 인터페이스에 대해 설명했으며, 이제부터는 유틸리티 자체의 흐름에 대해 설명하겠습니다.
관리 인터페이스를 사용하는 첫 번째 단계는 SMS 공급자에 연결하는 것입니다. 이를 위해서는 SMSProvider 클래스의 새 인스턴스를 만들면 됩니다. 내부적으로 이 클래스는 지정된 사이트 서버에 대한 SMS 공급자를 찾은 다음 지정된 자격 증명으로 해당 공급자에 연결합니다. 공급자가 로컬 컴퓨터에 있는 경우에는 제공된 자격 증명 대신 현재 로그인한 사용자의 자격 증명이 공급자에 연결할 때 사용됩니다. SMS 서버에서도 SMSMap을 실행할 수는 있지만 가급적이면 Visio가 설치된 별도의 워크스테이션에서 실행하는 것이 좋습니다. 대부분의 SMS 사이트 서버에 Visio가 설치되어 있지 않은 데는 그만한 이유가 있습니다.
SMSProvider 클래스를 통해 SMS 사이트의 데이터에 액세스하는 경우 SMS 관리자 콘솔을 사용할 때와 동일하게 보안 권한이 간주됩니다. 예를 들어 SMSProvider를 통해 사이트 서버의 설정을 구성하려는 경우 공급자에 연결할 때 사용한 계정에는 관리자 콘솔을 사용할 때와 동일한 권한 집합이 있어야 합니다.
SMSProvider 클래스는 현재 사이트(공급자가 속한 사이트)나 특정 사이트 코드의 사이트에 대한 사이트 설정을 가져올 수 있는 GetSiteSettings 메서드를 제공합니다. 그림 3의 코드 조각은 SMSMap이 대상 사이트 서버의 공급자에 연결하는 방법을 보여 줍니다. 사용자 자격 증명은 Domain\User 형식으로 전달됩니다. 현재 컴퓨터를 나타내기 위해 "."을 지정할 수도 있습니다. 그림 3에는 결과를 UI와 로그에 표시하는 데 사용할 수 있는 코드도 포함되어 있습니다.
Figure 3 GetSiteSettings 코드 조각 (Close Figure 3)
Imports System.Management
Imports Microsoft.SystemsManagementServer.Automation

 oProvider = New SMSProvider(txtServer.Text, txtUser.Text, txtPassword.Text)
 oSite = oProvider.GetSiteSettings()
 Trace.WriteLine(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 Application.DoEvents()
...
다음 단계는 그림 4와 같이 대상 사이트 서버의 SMS 정보를 수집 및 기록하는 XML 파일을 설정하는 것입니다.
Figure 4 XML 파일 만들기 (Close Figure 4)
‘ First, Create the XML File
 oWriter = New XmlTextWriter(m_sXmlFile, System.Text.Encoding.UTF8)
 oWriter.WriteStartDocument()
 oWriter.WriteStartElement(“Hierarchy”)

 ‘ Export Target Site to XML
 oWriter.WriteStartElement(“Site”)
 oWriter.WriteAttributeString(“Code”, oSite.SiteCode.ToString.ToUpper)
 oWriter.WriteStartElement(“SiteServer”)
 oWriter.WriteAttributeString(“Name”, oSite.SiteServer.ToString.ToUpper)
 oWriter.WriteEndElement()
 oWriter.WriteStartElement(“ParentSiteCode”)
 oWriter.WriteAttributeString(“SiteCode”, “THIS_IS_THE_TOP”)
 oWriter.WriteEndElement()

...
그런 다음에는 그림 5와 같이 대상 사이트를 Visio 다이어그램에 그리고 UI와 로그에서 사이트가 업데이트되도록 해야 합니다.
Figure 5 Visio에서 사이트 그리기 (Close Figure 5)
 ‘Draw Central Site
 dblXLocation = 4.25
 dblYLocation = 8.5
 vApp = New Visio.Application()
 vDoc = vApp.Documents.Add(“”)
 vStencil = vApp.Documents.OpenEx(TEMPLATEPATH, 4)
 ‘ Add Layers
 vExistingLayers = CType(vDoc.Pages(1).Layers, Visio.Layers)
 vLayer = CType(vExistingLayers.Add(“Site”), Microsoft.Office.Interop.Visio.Layer)

...

 If oSite.SiteType = SiteTypes.PrimarySite Then
 vFlowChartMaster = vStencil.Masters(“Primary Site”)
 ElseIf oSite.SiteType = SiteTypes.SecondarySite Then
 vFlowChartMaster = vStencil.Masters(“Secondary Site”)
 End If
 vToShape = vApp.ActivePage.Drop(vFlowChartMaster, dblXLocation, dblYLocation)
 vLayer.Add(vToShape, preserveMembers)

...
대상 사이트 서버의 전체 계층 구조를 파악하기 위해 SMS를 쿼리하여 Visio에서 이를 그리는 위의 기본 코드가 실행됩니다. 이 코드는 Level이라는 함수이며 계층 구조의 규모에 관계없이 하위 사이트를 모두 쿼리할 때까지 반복해서 호출됩니다. Level은 SMS 사이트 정보를 수집하여 대상 사이트 내 각 하위 사이트의 로그와 UI 및 XML에 이를 기록합니다. 마지막으로 그림 6은 유틸리티를 시작할 때 선택한 형식으로 Visio 다이어그램의 서식이 설정되는 방식을 보여 줍니다. 그런 다음 XML과 로그 파일이 닫힙니다.
Figure 6 마무리 (Close Figure 6)
 vDoc.Pages(1).Layout()
 vDoc.Pages(1).ResizeToFitContents()

 ‘Calculate the page width and height with a 5% boundary
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageHeight”)
 dHeight = visCell.Result(“in”)
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageWidth”)
 dWidth = visCell.Result(“in”)
 dHeight = dHeight + 1
 dWidth = dWidth + 1
 vDoc.Pages(1).PageSheet.Cells(“PageHeight”).Result(“in”) = dHeight
 vDoc.Pages(1).PageSheet.Cells(“PageWidth”).Result(“in”) = dWidth
 vDoc.Pages(1).CenterDrawing()
 Trace.WriteLine(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 vFlowChartMaster = vStencil.Masters(“Background world”)
 vApp.ActivePage.Drop(vFlowChartMaster, 0, 0)

 ‘Finish up
 vDoc.SaveAs(SAVENEWFILE)
 vDoc.Close()
 vApp.Quit()
 vDoc = Nothing
 vApp = Nothing
 GC.Collect()

...

첫걸음
물론 아직까지는 시작에 불과하며 개선의 여지가 많이 남아 있습니다. SDK에서 Device Management Point(장치 관리 지점)를 찾지 못했으므로 이것도 검토해야 합니다. 사이트를 완전하게 문서화하기 위해 여러 가지 다른 사이트 설정을 추가할 수 있습니다. 크고 작은 계층 구조를 보다 보기 좋게 만들려면 보다 많은 시간과 노력을 들여 매우 다양한 Visio 레이아웃 설정을 추가해야 할 것입니다. 레이아웃 유형마다 효과적인 다이어그램을 표현하려 할 때 고유한 어려움이 있습니다. 물론 System Center Configuration Manager 2007에 대한 지원을 추가하는 것도 다음에 달성해야 할 매우 중요한 단계입니다. 그렇지만 이 첫 번째 버전의 SMSMap만으로도 SMS 관리자가 Visio 레이어와 투명성을 통해 대략적인 그림을 표현하고 몇몇 가정 시나리오를 시도하는 데 많은 도움이 될 것입니다.
소스 코드를 다운로드하여 고유의 필요에 맞게 유틸리티를 확장할 수 있습니다. 필자는 SMSMap을 Visio 2003이 설치된 Windows XP SP2와 Visio 2007이 설치된 Windows Vista™ Enterprise에서 테스트했습니다. 이 유틸리티를 개선하는 것과 관련하여 의견이 있으시면 jeff.tondt@microsoft.com으로 전자 메일을 보내주시기 바랍니다.

Jeff Tondt는 Microsoft Consulting Services의 수석 컨설턴트로, 주로 시스템 관리, 자동화 및 패치 관리를 담당하고 있으며 SMS 분야의 전문가입니다. 문의 사항이 있으면 jeff.tondt@microsoft.com으로 연락하시면 됩니다.


 How IT Works: RPC 오류 문제 해결
How IT Works
RPC 오류 문제 해결
Zubair Alexander

다년간 Windows 서버 플랫폼을 사용했다면 RPC(원격 프로시저 호출) 오류를 한두 번 정도는 경험했을 것입니다. RPC 오류는 RPC 서버를 사용할 수 없거나 사용 가능한 끝점이 더 이상 없음을 알려 주며, 그 외에 의미를 이해하기 어려운 경고를 제공하기도 합니다. 이러한 메시지의 의미가 혼동된다면 이 문서를 읽어 보십시오.
이 문서에서는 몇 가지 일반적인 RPC 오류와 이러한 RPC 오류를 식별하는 데 사용할 수 있는 여러 가지 방법을 살펴본 다음 특정한 문제에 대한 해결책을 설명하겠습니다. RPC 오류 및 해결 방법에 대해 구체적으로 설명하기에 앞서 RPC 관련 용어의 의미를 정확하게 짚어 보기로 하겠습니다.

RPC 개요
RPC는 클라이언트와 서버가 통신하는 데 사용되는 IPC(프로세스 간 통신) 기술입니다. 간단히 말해, RPC는 일반적으로 클라이언트 컴퓨터에 설치된 프로그램이 서버 컴퓨터에 설치된 프로그램을 실행하기 위해 사용하는 기술입니다. 예를 들어 Microsoft® Outlook® 클라이언트는 RPC를 통해 Microsoft Exchange Server와 통신합니다. 클라이언트 컴퓨터는 특정 인수를 사용하여 서버 컴퓨터에 메시지를 보냅니다. 서버는 실행된 프로그램에 대한 결과가 들어 있는 메시지로 클라이언트에 응답합니다.
이 프로세스에서 가장 중요한 것은 끝점입니다. 끝점은 서버가 들어오는 클라이언트 요청에 대해 모니터링하는 대상 컴퓨터의 포트 또는 포트 그룹을 의미합니다. 좀 더 구체적으로 말하자면 끝점은 RPC에 사용되는 서버 프로세스의 네트워크 주소입니다.
RPC 하위 시스템의 일부인 끝점 매퍼는 클라이언트 요청에 응답하여 동적 끝점을 확인하는 기능을 수행합니다. 끝점 매퍼가 서버에 끝점을 동적으로 할당하는 기능을 수행하는 경우도 있습니다.
또 한 가지 중요한 RPC 구성 요소는 로케이터 서비스입니다. 로케이터 서비스는 네트워크의 RPC 서비스 및 서버 목록을 유지 관리합니다. Windows® 클라이언트는 SMB(서버 메시지 블록) 포트(TCP 139 및 445)를 통해 도메인 컨트롤러에 연결한 다음, 로케이터 서비스를 통해 RPC 서비스 또는 서버를 검색합니다.
대부분의 Windows 기본 제공 서비스는 RPC를 통해 서로 통신합니다. 예를 들어 인증서 서비스, DCOM, FRS, MSMQ, MAPI, Active Directory® 복제 서비스 등이 RPC를 사용하여 통신합니다. 따라서 네트워크에서 RPC 서비스가 정상적으로 작동하지 않는 경우 수많은 통신 문제가 발생할 수 있습니다.

RPC 오류
이제 RPC 서비스에서 문제가 발생할 경우 나타나는 몇 가지 오류에 대해 살펴보겠습니다. 여기에서 설명하는 오류 외에도 더 많은 오류가 있습니다.
FRS(파일 복제 서비스)에서 문제가 발생한 경우에는 "RPC를 사용할 수 없음" 오류일 수 있습니다. 드라이브를 매핑하는 경우에는 "액세스 거부" 오류가 나타날 수 있습니다. Active Directory 사용자 및 컴퓨터를 사용하는 경우에는 "지정한 도메인이 없거나 연결할 수 없습니다"와 같은 오류 메시지가 나타날 수 있습니다. 도메인에 로그온하면 "주 도메인에서 시스템의 컴퓨터 계정을 찾을 수 없거나 해당 계정의 암호가 올바르지 않으므로 이 도메인에 로그온할 수 없습니다"와 같은 오류 메시지가 나타날 수 있습니다.
Microsoft Outlook 클라이언트가 Exchange Server와 통신하려고 시도할 때 RPC 오류로 인해 "로그온 정보가 올바르지 않습니다" 또는 "Outlook에 로그온할 수 없습니다"와 같은 잘못된 오류가 클라이언트에 표시될 수 있습니다.
RPC 서비스를 사용할 수 없는 경우에는 이러한 오류 외에도 추가적인 문제가 발생할 수 있습니다. 예를 들어 내 네트워크 환경에서 도메인을 찾을 수 없거나 그룹 정책 스냅인을 열지 못할 수 있습니다.
이것은 문제의 원인이 RPC에 있는 것으로 예상하지 못할 수 있는 몇 가지 예에 불과합니다. 이 외에도 많은 예가 있으며, 원격 프로세스와 관련된 문제가 발생하는 경우 RPC가 원인일 수 있습니다. 이제 문제를 확실하게 파악하는 방법과, 더 중요한 문제인 오류를 정확하게 추적하는 방법에 대해 살펴보겠습니다.

문제 해결
RPC 서비스에 문제가 있는 것으로 의심되는 경우 여러 가지 도구를 사용하여 문제를 진단할 수 있습니다.
그 중 하나가 Repadmin 도구입니다. 이 프로그램은 일반적으로 Active Directory 복제 문제를 모니터링하고 해결하는 데 사용되지만 RPC 끝점 매퍼의 문제를 해결하는 데도 사용할 수 있습니다. 이 도구를 실행하려면 명령 프롬프트에서 repadmin /bind를 입력합니다. RPC에 문제가 있으면 "끝점 매퍼에서 사용 가능한 끝점이 더 이상 없습니다"와 같은 메시지가 나타날 수 있습니다. 이 메시지는 RPC와 관련하여 문제가 있음을 나타내는 첫 번째 단서입니다.
또 다른 방법은 도메인 컨트롤러의 문제를 진단하기 위한 명령줄 프로그램인 도메인 컨트롤러 진단 도구(DCDiag)를 사용하는 것입니다. "상태 1722: RPC 서버를 사용할 수 없습니다"와 같은 오류 메시지가 나타나면 RPC 오류가 있으며 도메인 컨트롤러 진단 도구가 이 오류를 발견했음을 알 수 있습니다.
Active Directory를 관리하고 수많은 유지 관리 작업을 수행하는 데 사용하는 명령줄 도구인 Ntdsutil을 사용하는 경우 서버에 연결하려고 하면 종종 RPC 오류가 발생합니다. 이 경우 대개는 "끝점 매퍼에서 사용 가능한 끝점이 더 이상 없습니다"와 같은 일반적인 오류 메시지 중 하나가 나타날 수 있습니다. 이 역시 RPC 서비스에 문제가 있음을 나타내는 단서가 됩니다. 도메인 컨트롤러의 그룹 정책 개체 간의 일관성을 검사하는 Gpotool 도구 또한 RPC가 문제의 원인인 경우 이와 비슷한 오류 메시지를 표시합니다.
Dcpromo 도구를 사용하여 Windows 2000 Server 또는 Windows Server® 2003 서버를 도메인 컨트롤러로 승격할 때 생성되는 Dcpromo.log를 통해 RPC 문제를 확인할 수도 있습니다. 예를 들어 승격에 실패하면 이 로그를 한번 살펴봅니다. 이 로그는 %windir%\debug 폴더에 있습니다. 로그에 기록된 오류는 디렉터리 서비스가 파티션 복제에 실패했거나 개체 생성에 실패한 원인에 대한 정보를 제공합니다. 메시지 끝 부분에는 오류 코드가 있습니다. 다음은 Dcpromo.log에서 볼 수 있는 오류 메시지의 예입니다.

08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)
오류 코드 1722를 유의해서 보십시오. 이 오류 코드는 이 메시지에서 네 번 나오며 RPC 서버를 사용할 수 없음을 나타냅니다. 그림 1에서는 몇 가지 오류 코드와 설명을 보여 줍니다. 더 많은 오류 코드를 보려면 msdn2.microsoft.com/ms681386을 참조하십시오.
Figure 1 오류 코드 및 설명 (Close Figure 1)

오류 코드 | 설명
58 | 지정된 서버가 요청된 작업을 수행할 수 없습니다.
1721 | 리소스가 부족하기 때문에 이 작업을 완료할 수 없습니다.
1722 | RPC 서버를 사용할 수 없습니다.
1723 | RPC 서버의 사용량이 많아 이 작업을 마칠 수 없습니다.
1727 | 원격 프로시저를 호출하지 못했기 때문에 실행하지 못했습니다.
1753 | 끝점 매퍼에서 사용 가능한 끝점이 더 이상 없습니다.

RPC 오류 해결
앞에서는 몇 가지 RPC 오류를 찾는 방법을 살펴봤으므로 지금부터는 몇 가지 해결 방법에 대해 알아보겠습니다.
Microsoft 클라이언트는 포트 135의 RPC 끝점 매퍼에 연결합니다. 그러면 끝점 매퍼는 어떤 포트에서 요청된 서비스를 수신하는지 클라이언트에 알려 줍니다. 포트 번호는 1024에서 65,535 사이의 값 중에서 동적으로 할당됩니다. 끝점 매퍼에서 사용 가능한 끝점이 더 이상 없음을 나타내는 1753과 같은 오류 메시지가 나타나는 경우 이는 RPC 끝점 매퍼가 1024보다 큰 포트를 서비스에 사용할 수 없음을 의미합니다. 이에 대해서는 나중에 보다 자세히 살펴보겠습니다.
이때 가장 먼저 수행해야 할 작업은 서버의 RPC 서비스 상태를 확인하는 것입니다. 서버 역할의 유형에 따라 RPC 및 RPC 로케이터 서비스는 그림 2에 나열된 상태로 되어 있어야 합니다. 두 서비스 중 하나가 그림에 표시된 것처럼 구성되어 있지 않으면 상태를 조정하거나 서버를 다시 부팅하여 문제가 해결되는지 테스트합니다.
Figure 2 RPC 서비스 상태 (Close Figure 2)

서버 역할 | RPC 서비스 | RPC 로케이터 서비스
Windows Server 2003 - 도메인 컨트롤러 | 시작됨, 자동 | 중지됨, 수동
Windows Server 2003 - 구성원 서버 | 시작됨, 자동 | 중지됨, 수동
Windows Server 2003 - 독립 실행형 서버 | 시작됨, 자동 | 중지됨, 수동
Windows 2000 Server - 도메인 컨트롤러 | 시작됨, 자동 | 중지됨, 자동
Windows 2000 Server - 구성원 서버 | 시작됨, 자동 | 시작됨, 수동
시작됨, 수동 | 시작됨, 자동 | 중지됨, 수동
클라이언트에서 연결 문제가 있는 서버에 성공적으로 Ping을 수행할 수 있는지 확인합니다. 예를 들어 IP 주소가 192.168.1.200인 DC1이라는 서버와 통신하는 데 문제가 있는 경우 명령 프롬프트에서 다음 명령을 사용하여 DNS가 호스트 DC1을 올바르게 확인하는지 살펴봅니다.
Ping –a 192.168.1.200
호스트 이름이 아닌 IP 주소와 함께 –a 스위치를 사용해야 합니다.
모든 것이 올바르게 작동하면 그림 3의 Ping 응답과 비슷한 응답을 DC1로부터 받게 됩니다. Ping은 IP 주소 192.168.1.200을 확인하는 데 그치지 않고 호스트 이름인 dc1.contoso.com도 확인합니다. 이로써 DNS 이름 확인이 올바르게 작동하며 호스트 dc1.contoso.com을 올바르게 확인한다는 것을 분명하게 알 수 있습니다.
Figure 3 Ping 응답 (Close Figure 3)
C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms
Windows XP 또는 Windows 2000 클라이언트의 레지스트리에 최소한 그림 4의 오른쪽 창에 있는 나열된 네 개의 ClientProtocols가 포함되어 있는지도 확인해야 합니다.
그림 4 레지스트리에 나열된 RPC ClientProtocols
그림 4 레지스트리에 나열된 RPC ClientProtocols
이 항목 중 하나라도 없으면 그림 4에 표시된 이름 및 데이터 형식을 사용하여 새 문자열 값을 추가합니다. 기본적으로 여기에는 NetBIOS over TCP를 끝점에 대한 프로토콜 패밀리로 식별하는 데 사용되는 ncacn_nb_tcp라는 다섯 번째 항목이 있습니다. 사용자의 구성에 따라 ClientProtocols에 이 항목이 없을 수도 있습니다. 이 경우 이 항목을 수동으로 추가하여 RPC 오류가 해결되는지 확인합니다.
그림에서 왼쪽 창의 Rpc 폴더에 있는 키는 ClientProtocols, NameService, NetBios 및 SecurityService입니다. 아무 값도 지정되지 않은 Internet이라는 키가 있는 경우에는 이 키를 제거하고 컴퓨터를 다시 시작합니다. 이렇게 하면 문제가 해결될 수도 있습니다. 언제나 그렇듯이 Windows 레지스트리를 수정할 때는 세심한 주의를 기울여야 합니다.
앞에서 언급했듯이 RPC는 1024에서 65,535 사이의 포트를 사용할 수 있으므로 이러한 포트가 방화벽으로 차단되지 않았는지 확인해야 합니다. 포트가 열려 있는지 확인하는 가장 쉬운 방법은 포트 쿼리 도구를 사용하는 것입니다. 이 도구는 명령줄 버전(PortQry)과 GUI 버전(PortQueryUI)으로 제공됩니다.
PortQry는 Microsoft 다운로드 센터에서 다운로드할 수 있습니다. 자세한 내용은 "Portqry.exe 명령줄 유틸리티에 대한 설명"을 참조하십시오. 이 문서에서는 PortQry 상태 보고서에 대해 간략하게 설명하고 문제를 해결하는 데 사용할 수 있는 몇 가지 명령을 예로 보여 줍니다. 훨씬 간단한 GUI 버전을 사용할 수도 있습니다. 이 도구는 go.microsoft.com/fwlink/?LinkId=73740에서 다운로드할 수 있습니다.
포트 쿼리 도구는 RPC 오류가 발생하지 않은 컴퓨터에서 RPC 오류가 발생한 컴퓨터를 대상으로 지정하여 실행해야 합니다. 예를 들어 RPC 끝점 매퍼가 사용하는 포트 135가 열려 있는지 확인하려면 명령 프롬프트에서 다음과 같이 PortQry를 사용합니다.
portqry -n [servername] -e 135
PortQry와 PortQueryUI 중 어떤 버전을 사용하든 다음과 같은 결과가 나타납니다.
Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING
마지막 줄은 포트 135가 열려 있음을 보여 줍니다. 포트 135가 열려 있지 않으면 마지막 줄에 NOT LISTENING이 표시됩니다.
포트 범위가 열려 있는지 확인하려면 "135,1024-5000"과 같이 포트 번호 범위를 쉼표로 구분하여 입력합니다.

추가 해결 방법
지금까지 설명한 모든 방법을 시도했지만 문제가 여전히 해결되지 않은 경우 또 다른 방법을 사용할 수 있습니다. 사용자 환경에서 발생한 구체적인 문제에 따라 다음 중 한 가지 방법으로 레지스트리를 수정해 볼 수 있습니다. 그 전에 한 가지 주의해야 할 사항이 있습니다. 레지스트리를 변경하기 전에 시스템, 특히 레지스트리를 백업해 두었는지 반드시 확인해야 합니다. 이렇게 하면 무엇인가 잘못되더라도 컴퓨터를 이전 상태로 복원할 수 있습니다.
한 가지 방법은 응용 프로그램이 시스템에서 사용 가능한 사용자 포트를 요청하는 경우 TCP가 할당할 수 있는 가장 높은 포트 번호를 지정하도록 MaxUserPort를 수정하는 것입니다. 기본적으로 Windows Server 2003에서는 MaxUserPort 값이 5000으로 설정됩니다. 이는 가장 높은 포트 번호로 5000이 사용된다는 것을 의미하며 이 레지스트리 항목이 없는 경우에도 이 값이 사용됨을 나타냅니다. 사용자 구성에 따라 레지스트리에 이 항목이 없을 수도 있습니다. 이 경우 그림 5에 표시된 위치에 이 항목을 추가할 수 있습니다.
그림 5 레지스트리의 MaxUserPort 설정
그림 5 레지스트리의 MaxUserPort 설정
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000
레지스트리를 수정할 때는 해결하기 어려울 수도 있는 다른 부작용의 발생 가능성에 대해 주의해야 합니다. 이 항목을 수정하여 값을 50,000 미만으로 설정하면 Microsoft Exchange Server에 영향을 줄 수 있습니다. Exchange Server Best Practices Analyzer(BPA)는 MaxUserPort 레지스트리 키 값이 50,000 미만임을 발견한 경우 경고 메시지를 표시합니다. 이 값은 60,000으로 설정하는 것이 좋습니다. 그렇지 않으면 이벤트 9040과 같은 NSPI(Name Service Provider Interface) 프록시 경고 메시지가 나타날 수 있습니다. 자세한 내용은 Microsoft에서 제공하는 "MaxUserPort 값이 너무 낮음" 문서를 참조하십시오.
TcpMaxDataRetransmissions를 수정할 수도 있습니다. TCP 패킷은 수신 측으로부터 승인을 기다립니다. 타이머가 만료되기 전에 승인을 받지 못하면 TcpMaxDataRetransmissions 횟수에 도달할 때까지 패킷이 다시 전송됩니다. 이 매개 변수의 기본값은 5이지만 값을 4 또는 3으로 지정할 수도 있습니다. 3보다 작은 값은 사용하지 마십시오.
TcpMaxDataRetransmissions 레지스트리 항목이 없으면 레지스트리의 다음 위치에 다음과 같이 항목을 추가할 수 있습니다.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5
TcpMaxDataRetransmissions에 대한 자세한 내용은 Microsoft 기술 자료 문서 170359 "TCP/IP 최대 재전송 시간 제한을 수정하는 방법"을 참조하십시오.
TcpTimedWaitDelay 레지스트리 값을 수정할 수도 있습니다. 클라이언트가 포트를 너무 많이 사용하는 경우 TCP/IP가 닫힌 연결을 해제하기 전에 사용 가능한 포트가 남지 않을 수 있습니다. 이는 TCP/IP가 두 개의 MSL(Maximum Segment Life)이 끝날 때까지 연결을 해제하지 않기 때문인데, 이를 시간 대기 상태라고 합니다. 뿐만 아니라 각 MSL은 120초로 정의되는데, TCP/IP는 두 MSL이 끝날 때까지 연결을 해제하지 않으므로 TCP/IP가 닫힌 연결을 해제하는 데 최대 240초(4분)가 걸리게 됩니다. 이는 Windows NT®의 알려진 문제이며 서비스 팩을 통해 이미 해결되었으므로 현재는 이러한 문제가 발생할 가능성이 매우 낮습니다. 하지만 RPC 끝점 매퍼 오류를 해결하기 위한 해결 방법 중 하나로 이 설정을 수정하는 것이 좋습니다. 이에 대한 자세한 내용은 기술 자료 문서 "RPC 끝점 매퍼 오류 문제를 해결하는 방법"을 참조하십시오.
TcpTimedWaitDelay는 레지스트리의 다음 위치에 추가됩니다.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)
TcpTimedWaitDelay에 대한 자세한 내용은 기술 자료 문서 "Windows NT 클라이언트의 포트 부족"을 참조하십시오. 이 문서에서는 특정한 값을 권장하지 않지만 TcpTimedWaitDelay를 60(10진수, 단위: 초) 또는 3c(16진수)로 줄이는 것이 좋습니다.

결론
RPC 오류는 네트워크에서 발생하는 수많은 통신 오류의 근본 원인일 수 있습니다. 다행히 이러한 까다로운 문제를 해결하는 데 사용할 수 있는 다양한 독창적인 방법이 있습니다. 이 문서에서 소개한 일부 도구는 기본적으로 제공되며 다른 도구는 Windows Server Resource Kit에서 사용할 수 있습니다. 대부분의 도구는 그림 6에 나와 있습니다. 이러한 도구를 사용하여 RPC 오류의 원인과 오류가 발생한 위치를 찾은 다음, 이 문서에서 제시한 방법 중 하나를 통해 해결할 수 있습니다.
Figure 6 RPC 문제 해결 도구 (Close Figure 6)

도구 | 설명
DCDiag | 도메인 컨트롤러의 상태를 분석합니다.
이벤트 뷰어 | 기록된 이벤트를 표시합니다.
Gpotool | 정책이 올바르며 일관성이 있는지 여부를 확인합니다.
NetDiag | 네트워크 연결을 테스트하는 데 사용합니다.
네트워크 모니터 | 네트워크 트래픽을 모니터링 및 캡처합니다.
Ntdsutil | Active Directory에 관리 기능을 제공합니다.
PortQry, PortQueryUI | TCP/IP 연결을 테스트하는 데 사용합니다.
Repadmin | Windows DC 간 복제 문제를 진단합니다.
RPCDump | 일반적으로 네트워크 모니터와 함께 사용합니다.
RPCPing | RPC 연결을 확인하는 데 사용합니다.

Zubair Alexander는 MCSE, MCT 및 Microsoft MVP이자 IT 교육 및 컨설팅 회사인 SeattlePro Enterprises의 소유주입니다. 또한 저자, 대학 강사, 컨설턴트, 네트워크 엔지니어, 강연자, 보안 설계자, 시스템 관리자, 기술 문서 편집자, 교육 담당자 등 IT 교육 분야에서 다양한 경력을 쌓고 있습니다. 문의 사항이 있으면 alexander@techgalaxy.net으로 연락하십시오.


 The Cable Guy: VPN 연결을 통한 IPv6 트래픽
The Cable Guy
VPN 연결을 통한 IPv6 트래픽
Joseph Davies

인트라넷에서 IPv6(인터넷 프로토콜 버전 6)의 역할을 평가하고 배포를 계획할 때는 먼저 Windows의 VPN(가상 사설망) 연결에서 IPv6 트래픽이 어떻게 지원되는지 이해해야 합니다. VPN 연결을 사용하면 인터넷과 같은 공용 네트워크에서의 연결을 포함하도록 네트워크를 확장할 수 있습니다.
VPN 연결은 연결하는 사용자의 자격 증명에 대해 유효성을 검사하는 강력한 인증 프로토콜과 데이터 기밀성을 유지하는 암호화 수단으로 보호됩니다.
Windows® XP 및 Windows Server® 2003에는 IPv6 프로토콜 스택이 포함되어 있지만 많은 핵심 서비스와 네트워킹 구성 요소에서 IPv6이 지원되지 않습니다. Windows Vista™ 및 Windows Server 2008(이전의 코드 이름 "Longhorn")에서는 IPv6이 완벽하게 지원될 뿐만 아니라 기본적으로 설치되어 사용됩니다. 실제로 Windows Vista와 Windows Server 2008에 포함된 대부분의 네트워킹 응용 프로그램과 서비스에서도 IPv6이 지원됩니다. 이번 달에는 IPv4(인터넷 프로토콜 버전 4) 및 IPv6 인터넷에서 설정된 VPN 연결을 통해 전송되는 IPv6 트래픽이 Windows Vista, Windows Server 2008, Windows XP 및 Windows Server 2003에서 어떻게 지원되는지 살펴보겠습니다.

IPv4 인터넷에서의 VPN 연결
오늘날 대부분의 인트라넷에서는 IPv4 인터넷을 통해 VPN 연결이 설정됩니다. 그림 1에서는 이러한 유형의 VPN 연결에 사용되는 Windows 기반 구성 요소를 보여 줍니다. 이러한 구성 요소는 다음과 같이 구성됩니다.
그림 1 IPv4 인터넷에서의 VPN 연결에 사용되는 Windows 기반 구성 요소
그림 1 IPv4 인터넷에서의 VPN 연결에 사용되는 Windows 기반 구성 요소
VPN 클라이언트 VPN 클라이언트는 VPN 서버에 대한 원격 액세스 VPN 연결을 시작하여 인트라넷 리소스와 통신하는 컴퓨터를 말합니다. 원격 액세스 VPN 연결을 사용하면 VPN 클라이언트가 인트라넷에 직접 연결된 것처럼 작동합니다. VPN 클라이언트에서는 Windows의 클라이언트 버전 또는 서버 버전을 모두 실행할 수 있습니다.
VPN 서버 VPN 서버는 원격 VPN 연결 시도를 수신하고, 인증 및 연결 요구 사항을 적용하고, VPN 클라이언트와 인트라넷 리소스 사이에서 패킷을 라우팅하는 컴퓨터입니다. 일반적으로 VPN 서버에서는 라우팅 및 원격 액세스 서비스가 설치된 Windows 서버 버전이 실행됩니다.
VPN 라우터 VPN 라우터는 사이트 간 VPN 연결 시도를 시작하거나 수신하는 컴퓨터입니다. 사이트 간 VPN 연결은 인트라넷의 두 부분을 상호 연결합니다. VPN 라우터에서는 Windows 서버 버전과 라우팅 및 원격 액세스 서비스가 실행됩니다.
VPN 연결 VPN 연결은 VPN 클라이언트와 VPN 서버 또는 VPN 라우터 간의 논리적 연결로, VPN 프로토콜을 캡슐화하는 방법으로 정의됩니다.
IPv6 지원 인트라넷 IPv6 지원 인트라넷에서는 IPv6 트래픽을 그대로 전달하거나 IPv4 패킷으로 터널링하여 전달할 수 있습니다.
IPv6/IPv4 호스트 이 인트라넷 노드에서는 IPv6 트래픽을 그대로 송수신하거나 IPv4 패킷으로 터널링하여 송수신할 수 있습니다.
Windows 기반 VPN 클라이언트, 서버 및 라우터에서는 VPN 연결을 통해 전송되는 패킷을 PPTP(지점 간 터널링 프로토콜), L2TP/IPsec(Layer Two Tunneling Protocol with Internet Protocol security), SSTP(Secure Socket Tunneling Protocol) 등의 VPN 프로토콜을 사용하여 캡슐화할 수 있습니다. SSTP는 Windows Vista SP1(서비스 팩 1, 현재 베타 테스트 중)과 Windows Server 2008에서만 지원됩니다.
IPv4 인터넷에서의 VPN 연결의 경우 IPv4 패킷으로 터널링된 IPv6 패킷(이하 IPv6-over-IPv4 트래픽) 및 기본 IPv6 트래픽의 두 가지 방식으로 IPv6 전송이 이루어집니다.
이 칼럼에서는 VPN 연결을 통한 IPv6 트래픽 지원을 VPN 프로토콜과 Windows 버전별로 설명합니다. 원격 액세스 VPN 연결의 경우 여기에 언급된 VPN 프로토콜과 Windows 버전의 조합은 Windows의 원격 액세스 클라이언트 및 원격 액세스 서버 구성 요소에서 모두 지원된다는 것을 전제로 합니다.

IPv6-over-IPv4 트래픽
이 방식에서는 인트라넷의 원격 액세스 클라이언트 또는 IPv6/IPv4 호스트가 IPv4 헤더를 사용하여 IPv6 패킷을 캡슐화한 다음 IPv4 패킷으로 전송합니다. 인트라넷의 경우 IPv6/IPv4 노드는 ISATAP(IntraSite Automatic Tunnel Addressing Protocol) IPv6 변환 기술(RFC 4214)을 사용하여 IPv4 전용 인트라넷에서 IPv6 트래픽을 교환할 수 있습니다. ISATAP를 사용하면 IPv6 주소 지정 및 전달을 지원하도록 기존 라우터를 구성하거나 업그레이드하지 않고도 IPv4 전용 인트라넷에서 IPv6 연결을 사용할 수 있습니다. ISATAP에 대한 자세한 내용은 microsoft.com/technet/network/ipv6/ipv6coexist.mspx에서 "IPv6 변환 기술"을 참조하십시오.
그림 2에서는 IPv4 인터넷에서 VPN 연결을 사용하여 IPv4 패킷을 전송할 경우의 일반적인 VPN 트래픽 패킷 구조를 보여 줍니다. IPv4 패킷은 VPN 프로토콜에 의해 헤더, 그리고 VPN 프로토콜에 따라 트레일러로 캡슐화됩니다. 이렇게 IPv4 헤더를 사용하여 캡슐화된 패킷은 IPv4 인터넷을 통해 전달할 수 있습니다.
그림 2 IPv4 인터넷에서 VPN 연결을 사용하는 IPv4 패킷
그림 2 IPv4 인터넷에서 VPN 연결을 사용하는 IPv4 패킷
IPv6-over-IPv4 트래픽의 경우 VPN 연결을 통해 전송되는 IPv4 패킷의 페이로드는 IPv6 패킷입니다. 그림 3에서는 IPv4 인터넷에서 VPN 연결을 사용하여 IPv6-over-IPv4 패킷을 전송할 경우의 일반적인 VPN 트래픽 패킷 구조를 보여 줍니다.
그림 3 IPv4 인터넷에서 VPN 연결을 사용하는 IPv6-over-IPv4 패킷
그림 3 IPv4 인터넷에서 VPN 연결을 사용하는 IPv6-over-IPv4 패킷
원격 액세스 VPN 연결의 경우 IPv4 인터넷에서의 IPv6-over-IPv4 트래픽은 Windows Vista, Windows Server 2008, Windows XP SP1 이상 및 Windows Server 2003에서는 PPTP 및 L2TP/IPsec을 통해 지원되고, Windows Vista SP1 및 Windows Server 2008에서는 SSTP를 통해 지원됩니다. 사이트 간 VPN 연결의 경우 IPv4 인터넷에서의 IPv6-over-IPv4 트래픽은 Windows Server 2008 및 Windows Server 2003에서 PPTP와 L2TP/IPsec을 통해 지원됩니다.

기본 IPv6 트래픽
기본 IPv6 트래픽의 경우 VPN 클라이언트, 서버 또는 라우터에서는 초기 IPv4 캡슐화 없이 VPN 연결을 통해 IPv6 패킷을 전송합니다. 이러한 방식은 IPv6 연결을 기본으로 지원하는 인트라넷에서 작동하며 이 경우 VPN 클라이언트, 서버 및 라우터는 IPV6CP(IPv6 Control Protocol), RFC 2472를 지원해야 합니다. IPV6CP 프로토콜에서는 IPv6 노드가 PPP(지점 간 프로토콜) 기반 연결의 IPv6 구성 옵션을 협상하는 방법을 정의합니다. IPV6CP는 Windows Vista 및 Windows Server 2008에서 지원되며 Windows XP 및 Windows Server 2003에서는 지원되지 않습니다. 그림 4에서는 IPv4 인터넷에서 VPN 연결을 사용하여 기본 IPv6 패킷을 전송할 경우의 일반적인 VPN 트래픽 패킷 구조를 보여 줍니다.
그림 4 IPv4 인터넷에서 VPN 연결을 사용하는 기본 IPv6 패킷
그림 4 IPv4 인터넷에서 VPN 연결을 사용하는 기본 IPv6 패킷
원격 액세스 VPN 연결의 경우 IPv4 인터넷에서의 기본 IPv6 트래픽은 Windows Vista 및 Windows Server 2008에서 PPTP와 L2TP/IPsec을 통해 지원되고, Windows Vista SP1 및 Windows Server 2008에서는 SSTP를 통해 지원됩니다. 사이트 간 VPN 연결의 경우 IPv4 인터넷에서 전송되는 기본 IPv6 트래픽은 Windows Server 2008에서 PPTP와 L2TP/IPsec을 통해 지원됩니다.

IPv6 인터넷에서의 VPN 연결
IPv6 인터넷에서 VPN 연결을 설정할 수도 있습니다. 이러한 방식의 VPN 연결은 아직 널리 사용되고 있지는 않지만 IPv6을 제공하는 인터넷 서비스 공급자가 증가하고 인트라넷 경계 네트워크에 IPv6 인터넷 연결 기능을 구현하는 조직이 늘어나면서 점차 확산되는 추세입니다.
IPv6 인터넷에서 VPN 연결을 지원하려면 IPv6에서의 연결을 지원하는 VPN 프로토콜을 사용해야 합니다. Windows Vista와 Windows Server 2008에서 L2TP/IPsec 및 SSTP VPN 프로토콜은 IPv6에서의 원격 액세스 VPN 연결을 지원합니다. Windows Server 2008의 경우 L2TP/IPsec은 IPv6에서의 사이트 간 연결을 지원합니다. IPv6 인터넷에서의 VPN 연결에는 IPv4 인터넷에서 원격 액세스 VPN 연결과 사이트 간 VPN 연결 모두에 사용되는 것과 동일한 구성 요소 집합이 사용됩니다.
IPv6 인터넷에서의 IPv6 패킷 전송 방법으로는 IPv6-over-IPv4 트래픽 및 기본 IPv6 트래픽의 두 가지가 있습니다. 그림 5에서는 IPv6 인터넷에서 VPN 연결을 통해 전송되는 IPv6-over-IPv4 패킷의 일반적인 구조를 보여 줍니다.
그림 5 IPv6 인터넷에서 VPN 연결을 사용하는 IPv6-over-IPv4 패킷
그림 5 IPv6 인터넷에서 VPN 연결을 사용하는 IPv6-over-IPv4 패킷
원격 액세스 VPN 연결의 경우 IPv6 인터넷에서의 IPv6-over-IPv4 트래픽은 Windows Vista 및 Windows Server 2008에서는 L2TP/IPsec을 통해 지원되고, Windows Vista SP1 및 Windows Server 2008에서는 SSTP를 통해 지원됩니다. 사이트 간 VPN 연결의 경우 IPv6 인터넷에서의 IPv6-over-IPv4 트래픽은 Windows Server 2008에서 L2TP/IPsec을 통해 지원됩니다. IPv6 인터넷에서 IPv6-over-IPv4 트래픽을 사용하려면 IPv4 인터넷에서의 IPv6-over-IPv4 트래픽과 마찬가지로 인트라넷에 ISATAP와 같은 IPv6 변환 기술을 배포해야 합니다.
그림 6에서는 IPv6 인터넷에서 VPN 연결을 통해 전송되는 기본 IPv6 패킷의 일반적인 구조를 보여 줍니다. IPv4 인터넷에서의 기본 IPv6 트래픽과 마찬가지로 IPv6 인터넷에서 기본 IPv6 트래픽을 사용하려면 IPV6CP 지원이 필요하며 인트라넷에 기본 IPv6 연결 기능을 배포해야 합니다.
그림 6 IPv6 인터넷에서 VPN 연결을 사용하는 기본 IPv6 패킷
그림 6 IPv6 인터넷에서 VPN 연결을 사용하는 기본 IPv6 패킷
원격 액세스 VPN 연결의 경우 IPv6 인터넷에서의 기본 IPv6 트래픽은 Windows Vista 및 Windows Server 2008에서 L2TP/IPsec을 통해 지원되고, Windows Vista SP1 및 Windows Server 2008에서 SSTP를 통해 지원됩니다. 사이트 간 VPN 연결의 경우 IPv6 인터넷에서의 기본 IPv6 트래픽은 Windows Server 2008에서 L2TP/IPsec을 통해 지원됩니다.

요약
그림 7에서는 VPN 연결을 통해 IPv6 트래픽을 전송하는 네 가지 방법과 두 가지 VPN 연결 유형에 대한 Windows의 지원 기능을 보여 줍니다. 간단히 설명하면, 인트라넷에서 ISATAP와 같은 IPv6 변환 기술을 사용하는 경우 IPv4 인터넷뿐만 아니라 IPv6 인터넷에서도 VPN 연결을 통해 IPv6-over-IPv4 트래픽을 전송할 수 있습니다. 또한 인트라넷에서 기본 IPv6 연결 기능이 지원되는 경우에는 Windows Vista 및 Windows Server 2008에서 IPv4 인터넷뿐만 아니라 IPv6 인터넷에서도 VPN 연결을 통해 기본 IPv6 트래픽을 전송할 수 있습니다.
Figure 7 Windows의 VPN 연결을 통한 IPv6 트래픽 지원 (Close Figure 7)

IPv6 트래픽 전송 방법 | 원격 액세스 VPN 연결 | 사이트 간 VPN 연결
IPv4 인터넷에서의 IPv6-over-IPv4 트래픽 | Windows Vista, Windows Server 2008, Windows XP SP1 이상, Windows Server 2003에서 지원하는 PPTP 및 L2TP/IPsec과 Windows Vista SP1 및 Windows Server 2008에서 지원하는 SSTP | Windows Server 2008 및 Windows Server 2003에서 지원하는 PPTP 및 L2TP/IPsec
IPv4 인터넷에서의 기본 IPv6 트래픽 | Windows Vista 및 Windows Server 2008에서 지원하는 PPTP 및 L2TP/IPsec과 Windows Vista SP1 및 Windows Server 2008에서 지원하는 SSTP | Windows Server 2008에서 지원하는 PPTP 및 L2TP/IPsec
IPv4 인터넷에서의 IPv6-over-IPv6 트래픽 | Windows Vista 및 Windows Server 2008에서 지원하는 L2TP/IPsec과 Windows Vista SP1 및 Windows Server 2008에서 지원하는 SSTP | Windows Server 2008에서 지원하는 L2TP/IPsec
IPv6 인터넷에서의 기본 IPv6 트래픽 | Windows Vista 및 Windows Server 2008에서 지원하는 L2TP/IPsec과 Windows Vista SP1 및 Windows Server 2008에서 지원하는 SSTP | Windows Server 2008에서 지원하는 L2TP/IPsec

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


 Windows PowerShell: 파이프라인 다시 살펴보기
Windows PowerShell
파이프라인 다시 살펴보기
Don Jones

Windows PowerShell이 지난 수십 년간 주로 UNIX 및 Linux 기반 운영 체제에서 사용되어 온 명령줄 인터페이스 개념에 근거한 것임에도 불구하고 많은 이들이 Windows PowerShell의 차별화되고 새로우며 흥미로운 기능에 대해 언급해 왔습니다. 하지만 Windows PowerShell에서 이전 솔루션에서 사용되는 용어를 그대로 사용함으로써
Windows PowerShell™이 지닌 진정한 유연성 및 고유성과 Windows® 환경에 대한 뛰어난 적합성이 간과되는 경우가 많습니다.
Windows PowerShell에서 가장 자주 언급되면서도 동시에 가장 잘못 인식되고 있는 기능 중 하나는 바로 파이프라인입니다. 이는 파이프라인이 1970년대 초반, 즉 지금과는 전혀 다르고 덜 강력한 기능을 나타내던 때에 정의된 용어를 그대로 사용하고 있기 때문입니다.

파이프의 유래
첫 번째로 개발된 UNIX 셸 중 하나는 매우 원시적이며 변수 없이 가장 기본적인 스크립트 언어 요소의 기능만 가지고 있었던 Thompson 셸이었습니다. Thompson 셸은 본래의 용도인 프로그램 실행에만 적합하도록 설계되었지만 그 당시 다른 셸을 개선하는 핵심 개념인 파이프를 도입했습니다. 따라서 Thompson 셸에서는 < and > 기호를 사용하여 여러 명령을 통해 입/출력을 리디렉션하도록 지시할 수 있었습니다. 즉, 사용자가 파일에 명령 출력을 리디렉션할 수 있게 된 것입니다.
이 구문은 이후에 한 명령의 출력을 파이프로 다른 명령에 입력할 수 있도록 확장되었습니다. 이를 통해 긴 명령 시퀀스를 모두 연결하여 보다 복잡한 작업을 수행할 수 있게 되었습니다. 이 셸의 버전 4에서 파이핑에 세로 줄 문자 "|"가 채택되면서 이 문자가 이후 파이프 문자로 알려지게 되었습니다. MS-DOS®의 최초 버전에서도 이러한 문자를 통해 기본 파이핑을 구현했습니다. 예를 들어 사용자는 이를 통해 type 명령의 출력을 파이프로 more 명령에 입력하여 긴 텍스트 파일을 한 번에 한 페이지가 표시되도록 할 수 있었습니다.
1975년 UNIX 버전 6이 릴리스되던 무렵 Thompson 셸은 많은 사람들 사이에서 부적절한 것으로 간주되었으나 파이프의 이러한 개념은 셸 개발자 및 사용자에게 좋게 인식되어 오늘날 사용되고 있는 여러 기술에까지 활용되고 있습니다.

텍스트 파이핑
거의 모든 셸이 가지고 있는 제한 사항은 내재된 텍스트 기반 특성입니다. UNIX 기반 운영 체제에서 이는 실제 제한이 아닌 OS 자체의 작동 방식을 나타내는 것입니다. UNIX에서 대부분의 리소스는 일종의 파일로 표시될 수 있습니다. 따라서 한 명령으로부터 다른 명령으로 텍스트를 전달하는 기능을 통해 매우 강력한 성능과 유연성을 얻을 수 있습니다.
하지만 텍스트는 관리 정보에 대해서는 매우 제한적입니다. 예를 들어 사용자에게 Windows 컴퓨터에서 실행 중인 서비스 목록을 보여 주는 경우 사용자는 거의 틀림없이 서비스 목록을 파악할 수 있을 것입니다. 첫 번째 열에 서비스 이름을 표시하고 두 번째 열에 시작 모드를 표시하면 사용자는 이러한 텍스트를 보는 즉시 머리 속에서 작업에 사용할 수 있는 의미 있는 정보로 분석하거나 변환합니다. 하지만 컴퓨터의 경우는 인간의 뇌처럼 지능적이지 못합니다. 컴퓨터에서 목록을 가지고 필요한 작업을 수행하려면 컴퓨터에 첫 번째 열은 1-20자로 구성되어 있고 두 번째 열은 22-40자로 구성되어 있음과 같은 정보를 알려 주어야만 합니다.
오랫동안 이러한 유형의 텍스트 파일 구문 분석이 관리자가 여러 명령을 모두 연결하는 데 사용할 수 있는 유일한 방법이었습니다. 사실 하나의 프로그램 또는 명령으로부터 텍스트 출력을 받아 해당 출력을 이후 작업에 사용할 수 있는 유용한 데이터로 구문 분석해야 하는 경우가 대부분이므로 문자열 조작에 있어 VBScript 및 Perl과 같은 스크립트 언어가 훨씬 뛰어납니다. 예를 들어 필자는 Dir 명령의 텍스트 출력을 받아 파일 이름 및 날짜에 대한 출력을 분석한 다음 사용하지 않는 오래된 파일을 보관 위치로 옮기는 VBScript 작업을 작성한 적이 있습니다. 문자열 구문 분석은 입력 데이터가 변형되는 예외가 거의 항상 발생하며 이러한 예외가 발생하는 경우 가능한 모든 순열을 처리하기 위해 스크립트에서 논리를 다시 실행해야 하므로 작업하기가 매우 복잡합니다.
Windows 환경에서의 관리 스크립트 또는 자동화 작업에서는 문자열 구문 분석이 그다지 유용하지 않습니다. 이는 Windows 자체에서 액세스하기 쉬운 텍스트 형식으로는 많은 정보를 저장하지 않기 때문입니다. 대신에 Active Directory®, Windows 레지스트리 및 인증서 저장소와 같은 데이터 중심 저장소를 사용합니다. 따라서 스크립트 개발자는 특정 도구를 사용하여 텍스트 출력 형식을 생성한 다음 스크립트를 사용하여 해당 텍스트를 분석한 후 이를 가지고 필요한 작업을 수행해야 합니다.

작업이 보다 쉬워진 개체
Windows 소프트웨어 개발자는 항상 작업이 보다 용이하도록 노력해 왔습니다. 초창기 Microsoft에서는 Windows의 복잡한 내부 작업을 보다 사용하기 쉬운 방식으로 나타내기 위해 COM을 특수하게 개발했습니다. 오늘날 Microsoft® .NET Framework에서는 이러한 노력의 일환으로 소프트웨어의 내부 작업을 표준화된 방식으로 나타냅니다.
일반적으로 COM 및 .NET은 모두 항목을 개체로 제공합니다. (소프트웨어 개발자는 이렇게 단순화하는 것에 이의를 제기할 수도 있지만 여기에서는 개체라는 하나의 용어를 설명하는 것만으로도 충분합니다.) 이러한 개체에는 모두 다양한 유형의 멤버가 있습니다. 지금 우리가 가장 관심을 가지고 있는 부분은 개체의 속성 및 메서드입니다. 속성은 기본적으로는 개체를 몇몇 방식으로 설명하나 개체 또는 개체의 동작을 수정하기도 합니다. 예를 들어 서비스 개체에는 서비스 이름을 포함하는 속성 및 서비스의 시작 모드를 포함하는 다른 속성이 있을 수 있습니다. 메서드는 개체가 특정 작업을 수행하도록 합니다. 서비스 개체에는 해당 서비스로 수행할 수 있는 다양한 작업을 나타내는 중지, 시작, 일시 중지, 다시 시작 등의 메서드가 있을 수 있습니다.
프로그래밍 또는 스크립트 작성 관점에서 개체 멤버는 점 표기를 사용하여 나타낼 수 있습니다. 개체는 종종 해당 개체를 실제로 조작할 수 있는 방법을 제공하는 변수로 할당됩니다. 예를 들어 서비스를 $service 변수로 할당한 경우 $service.Stop 구문을 사용하여 이 서비스를 중지할 수 있습니다. 또는 $service.Name을 표시하여 서비스의 표시 이름을 검색할 수 있습니다.

파이프 내 개체
Windows는 거대하고 복잡한 운영 체제이며 관리 데이터를 텍스트 스타일 표현으로 저장하지 않으므로 이전 셸 기술은 Windows에 적합하지 않습니다. 예를 들어 서비스와 해당 시작 모드에 대한 형식이 지정된 목록을 생성하는 SvcList.exe라는 명령줄 도구가 있다고 가정해 봅니다. 이러한 경우 수십 년이 넘게 사용되어 온 MS-DOS 셸에 근본을 둔 Windows 명령줄 셸에서 다음과 같은 작업을 실행할 것입니다.
SvcList.exe | MyScript.vbs
이 문은 서비스 목록을 검색하고 이 목록을 VBScript 파일에 파이프로 전달합니다. 따라서 형식이 지정된 목록을 분석하고, 시작 모드가 Disabled인 모든 서비스를 출력하는 등의 필요한 작업을 수행하도록 VBScript 파일을 작성해야 합니다. 이러한 작업은 시간이 많이 소요됩니다. 결국 문제는 SvcList.exe의 출력이 다른 명령에서 쉽게 활용할 수 있는 일반적인 형식을 공유하지 않는 고유한 출력이라는 것입니다.
하지만 개체는 이러한 일반적인 형식을 제공할 수 있으며 바로 이 점이 Windows PowerShell 파이프라인이 텍스트뿐만 아니라 전체 개체에서 작동하는 이유입니다. Get-WMIObject와 같은 cmdlet을 실행하면 실제로는 개체의 그룹(프로그래머 용어로는 컬렉션)을 생성하는 것입니다. 각 개체는 이를 조작할 수 있도록 하는 속성 및 메서드와 함께 생성됩니다. 개체를 Where-Object cmdlet으로 파이프하는 경우 원하는 개체만 표시되도록 이를 필터링할 수 있습니다. Where-Object에서는 텍스트 대신 개체를 받으므로 텍스트를 구문 분석할 필요가 없습니다. 이에 대한 예는 다음과 같습니다.
Get-WMIObject Win32_Service | Where-Object {$_.StartMode -eq “Disabled” }
또한 별칭을 통해 사용할 수 있는 간단한 구문을 선호하는 경우 다음과 같이 할 수도 있습니다.
gwmi Win32_Service | where {$_.StartMode -eq “Disabled” }
재미있는 점은 Windows PowerShell은 항상 파이프라인 아래로 개체를 전달한다는 것입니다. 셸은 더 이상 개체를 전달할 곳이 없는 경우인 파이프라인 종단에 이르러서야 비로소 기본 제공 형식 설정 규칙을 사용하여 개체의 텍스트 표현을 생성합니다. 다음 예를 살펴보겠습니다.
Gwmi Win32_Service | where {$_.StartName –eq “LocalSystem” } | select Name,StartMode
이 세 가지 cmdlet 집합은 내 로컬 컴퓨터의 모든 서비스를 검색하여 LocalSystem 계정을 사용하여 로그온하지 않는 모든 서비스를 필터링한 다음 남아 있는 서비스를 Name 및 StartMode의 두 가지 속성만 출력하는 Select-Object cmdlet으로 전달합니다. 그 결과 보안 감사 등의 용도로 사용할 수 있도록 LocalSystem으로 로그온한 서비스가 간략하게 표시됩니다.
모든 cmdlet에서 공통적인 데이터 형식인 개체를 공유하므로 복잡한 문자열 구문 분석 작업을 수행하지 않고도 각각의 데이터를 공유할 수 있습니다. Windows PowerShell에 개체를 텍스트로 표시하는 고유한 기능이 포함되어 있으므로 이 파이프의 마지막 결과는 사용자가 읽을 수 있는 텍스트 출력으로 나타납니다. 그림 1에서는 생성된 출력의 예를 보여 줍니다.
그림 1 개체를 따라 전달하는 파이프로 연결된 cmdlet에 의해 생성된 텍스트 출력
그림 1 개체를 따라 전달하는 파이프로 연결된 cmdlet에 의해 생성된 텍스트 출력

파이프의 흥미로운 점
Windows PowerShell에서 파이핑을 하는 것이 이토록 놀라운 이유는 Windows PowerShell의 모든 것이 사용자가 사용할 수 있는 속성 및 메서드를 모두 갖춘 개체이기 때문입니다. 텍스트 파일도 원칙적으로 보면 문자열 개체의 집합이며 파일의 각 줄은 고유하고 독립적인 문자열 개체 역할을 합니다. 예를 들어 메모장을 사용하여 C:\Computers.txt라는 텍스트 파일을 만들어 보십시오. 파일에 텍스트를 입력한 다음 Windows PowerShell에서 다음을 실행해 봅니다.
Get-Content C:\Computers.txt | Select-Object Length | Format-List
또는 입력 작업을 별로 안 좋아한다면 다음과 같이 별칭을 사용할 수도 있습니다.
gc C:\Computers.txt | select Length | fl
이 코드는 텍스트 파일에 있는 각 줄의 길이를 문자 수로 나타내는 목록을 작성합니다. Get-Content가 파일로부터 문자열 개체를 검색하고 Select-Object에서 각 Length 속성을 확인한 다음 Format-List에서 사용자가 읽을 수 있는 텍스트 출력을 만듭니다. 이것은 사용하기에 실용적인 관리 도구는 아닐지라도 텍스트 한 줄과 같이 간단한 항목조차 Windows PowerShell의 개체라는 것을 보여 줍니다.
cmdlet에서 cmdlet으로 또는 cmdlet에서 스크립트로 개체를 전달할 수 있게 되면서 놀랍도록 강력한 "one liner"를 작성할 수 있게 되었습니다. 이는 사용자가 원하는 것을 정확하게 제공하기 위하여 긴 파이프라인에 연결되어 개체 집합을 더욱 세분화하는 간단한 문자열로 이루어진 cmdlet입니다. 실제로 스크립트 또는 프로그래밍 작업 없이도 적합한 파이프라인에 연결된 Windows PowerShell cmdlet에서는 뛰어난 결과를 수행할 수 있습니다.

다음 세대 지원
미래의 Microsoft 서버 제품 또한 Windows PowerShell을 기반으로 구축될 예정이므로 이러한 기능을 계속 활용할 수 있습니다. 예를 들어 새 Exchange Server 2007 시스템을 구현하는 경우 Windows PowerShell을 사용하여 모든 사서함을 검색하고 새 메일 서버가 위치할 사무실에 없는 사서함을 모두 필터링한 다음 해당 사서함을 새 서버로 옮기는 작업을 스크립트를 작성하지 않고도 텍스트 한 줄로 모두 수행할 수 있습니다. Exchange Server 2007 팀에서는 강력한 one-liner에 대한 긴 목록을 게시했습니다. 여기에서 파이프라인의 강력한 기능과 파이프라인에서 수행할 수 있는 관리 작업을 볼 수 있습니다.
Windows PowerShell을 사용하는 데 있어 중요한 점은 이 새로운 도구가 그간 UNIX 환경에서 오랫동안 확립되어 온 원칙 및 철학을 기반으로 하면서도 Windows 관리에 있어 그 어느 것보다 적합하다는 것을 이해하는 것입니다. Windows PowerShell이 단지 Windows용으로 고안된 UNIX 셸 모조품이라는 생각을 버리십시오. Windows PowerShell에는 Windows 플랫폼의 장점을 이용하는 새로운 개념이 포함되어 있으며 Windows의 작업 수행 방식과 밀접하게 연관되어 있습니다.

Don Jones는 Windows PowerShell MVP이며 Windows PowerShell 101(ScriptingTraining.com)의 저자입니다. 문의 사항이 있으면 www.ScriptingAnswers.com으로 연락하시기 바랍니다.


 Hey, Scripting Guy!: 스크립트도 겉모양이 중요하다!
Hey, Scripting Guy!
스크립트도 겉모양이 중요하다!
Microsoft Scripting Guys

지난 수백, 수천 년의 세월 동안 여러 철학자와 현자들은 겉모양만을 기준으로 다른 사람이나 사물을 판단해서는 안 된다고 말해 왔습니다. 사람에 있어서나 다른 어떤 것에 있어서나 결국 아름다움이란 보는 사람의 주관적 기준에 따라 달라지기 마련이니까요. 여러분도 이 말이 "진정한 아름다움은 외모가 아니라 내면에 있는 것이며, 어떤 모습인지보다 어떤 사람인지가 훨씬 중요하다"는 의미라는 것은 잘 알 것입니다.
Scripting Guys는 이런 말이 "공염불"이라고 감히 말하고 싶습니다.
그렇습니다. 공염불입니다. 이제 현실을 직시해 봅시다. 세상이 완벽하다면 겉모양이 전혀 중요하지 않겠지만 우리는 그런 완벽한 세상에 살고 있지 않습니다. 정말 세상이 완벽하다면 감자 튀김과 아이스크림을 주식으로 먹고 있을지도 모르겠습니다. 어쨌든 현실에서는 외모가 중요합니다. 그리고 이러한 명제는 스크립트에도 적용됩니다.
명령 창에서 실행되는 VBScript 스크립트의 멋진 모습에 감동의 눈물을 흘릴 사용자는 거의 없다는 건 잘 알고 있습니다. (Scripting Guys 중 한 명인 Dean Tsaltas라면 그럴지도 모르겠네요. 여간해서는 볼 수 없는 사람이죠.)
다른 한편으로 우리가 몸담고 있는 이 첨단 기술 분야에서 스크립트 작성자의 역할은 명령 창에서 실행되는 스크립트를 작성하는 데 국한되지 않습니다. HTA(HTML 응용 프로그램) 덕분에 스크립트 작성자는 스크립트에서 GUI를 구현하는 데 DHTML을 활용할 수 있게 되었습니다. 이 HTML 기술은 여러분도 잘 알다시피 시스템 관리 스크립팅에 일대 혁명을 가져올 새로운 분야인 Windows Vista™ 가젯을 만드는 데도 활용할 수 있습니다. 하지만 GUI에 대해 이야기할 때는 겉모양은 중요하지 않다는 기존의 모든 고정 관념이 무의미해집니다. 그래픽 환경에서 실행되는 스크립트의 경우 모양은 기능과 성능만큼 중요하니까요.
이것이 바로 문제입니다. 스크립트 작성자인 우리가 그래픽 사용자 인터페이스 제작에 대해 아는 바가 없다는 것이죠. 이제 행복은 끝나고 불행이 시작된 것일까요?
어쩌면 그럴 수도 있고 그렇지 않을 수도 있습니다. 어떻습니까? 역시 Scripting Guys는 항상 희망적인 소식을 안겨 주지 않습니까?
흠, 뭐 그렇지 않다면 어쩔 수 없습니다만, 그래도 고마워하실 독자들이 있으리라 생각하고 본론으로 들어가겠습니다.
이 기사를 통해 Scripting Guys가 여러분에게 도움을 주려 한다는 사실을 알아주는 독자가 있다면 그것으로 만족합니다.
놀라운 GUI 세계로의 여행을 시작하기 전에 먼저 HTA의 시작 부분을 살펴보도록 하겠습니다. HTA 작성에 대한 자세한 내용은 HTA 개발자 센터를 참조하시기 바랍니다.
그림 1에는 멋진 데스크톱 정보 시스템의 첫 부분이 나와 있습니다. 그림에서 볼 수 있듯이 첫 번째 단계로 HTA 창의 오른쪽 위 모서리에 작은 그래픽을 배치했습니다. 이것은 HTA가 처음으로 로드되면 로그온한 사용자의 이름을 검색하여 해당 사용자 이름과 컴퓨터 이름을 이 이미지 위에 표시한다는 개념입니다. 나중에 HTA에 여러 가지 멋진 기능을 추가하게 되겠지만, 소위 '중요한 것부터 시작'하겠습니다.
그림 1 멋진 예제 HTA 그래픽 인터페이스 구현의 첫 단계
그림 1 멋진 예제 HTA 그래픽 인터페이스 구현의 첫 단계
이 말을 누가 했을지는 모르겠네요. 앞에서 언급한 철학자들 중 한 명일 수도 있겠죠. 어쩌면 철학자 볼테르일까요? 마치 볼테르가 했을 법한 이야기 같네요.
어쨌든 이 예제 응용 프로그램은 너무 간단하고 Scripting Guy 중 하나인 Dean조차 감동시키지 못할 만큼 아름다움과는 거리가 멉니다. 하지만 여러 가지 상황에 적용할 수 있는 기본 개념을 보여 주는 데는 충분합니다. 그 거창한 Windows Vista 가젯도 대부분 이와 비슷한 원리로 작동합니다. 즉, 세련된 그래픽(예: 게이지 또는 다이얼)을 표시하고 그래픽 위에 텍스트를 쓰는 것입니다. 그러면 실제로는 평범한 그래픽 위에 약간의 동적 텍스트가 오버레이되는 것인데, 마치 사용 가능한 디스크 공간을 표시하는 작고 멋진 모양의 게이지가 나타나는 것처럼 보입니다.
솔직히 우리 자신조차 이것을 이해하기 힘들지만, 이 칼럼을 계속 읽다 보면 좀 더 명확하게 이해할 수 있을 것입니다.
그래픽을 표시한 다음 그 위에 텍스트를 쓴다는 개념에는 한 가지 문제점이 있습니다. 바로 그런 방식으로는 작동하지 않는다는 사실이죠. 대신에 기본 HTML 태그를 사용하면 그림 2와 같은 GUI를 구현할 수 있습니다. 기대했던 것과는 많이 다르죠. 어쩌면 "인간은 그래픽 위에 텍스트를 쓰고자 하는 부질없는 희망을 버려야 한다. 적어도 HTA에서는 말이다."라고 니체가 말했을지도 모르겠습니다.
그림 2 첫 번째 텍스트 오버레이 시도
그림 2 첫 번째 텍스트 오버레이 시도
아니, 니체가 틀렸을 수도 있습니다. 이번에도 "역시 Scripting Guys야..."라는 감탄이 들리는 것 같군요. 아닌가요? 어쨌든 평범한 HTML을 사용해서는 원하는 결과를 얻을 수 없다는 것만은 분명해졌습니다. 이론적으로는 그래픽을 배경 그래픽으로 만든 후 표, 단어 잘림 방지 공백, 기타 여러 가지 간단한 트릭을 사용하여 그림 위에 텍스트를 오버레이할 수도 있습니다. 그러나 "이론적으로"라고 하는 데는 항상 그만한 이유가 있는 법이죠. 이 방법으로는 작동하지 않습니다.
HTA 또는 Windows Vista 가젯에서 멋진 레이아웃을 만드는 더 좋은 방법이 있습니다. 바로 CSS(Cascading Style Sheet)가 그것입니다.
CSS는 글꼴, 여백과 맞춤, 색 등 문서에서 표시되는 다양한 요소를 정의하는 데 사용되며, 특히 웹 페이지에 많이 사용됩니다. HTA와 가젯도 본질적으로 웹 페이지라고 할 수 있으므로 CSS를 동일하게 적용할 수 있습니다. CSS의 용도에 대해 모두 설명하기에는 지면이 부족하므로 자세한 내용은 MSDN®의 CSS 참조 설명서를 참조하여 상세하면서도 유용한 정보를 얻으시기 바랍니다. 여기서는 특정 항목(텍스트)을 다른 항목(그래픽)에 오버레이하는 기능을 비롯하여 HTA의 레이아웃을 세밀하게 제어하는 데 CSS를 사용할 수 있다는 정도만 알면 됩니다.
지금부터 그 방법을 자세히 설명하겠습니다. 우선 그림 3에 나와 있는 간단한 HTA의 코드부터 살펴보겠습니다.
Figure 3 최종 스크립트 (Close Figure 3)
<SCRIPT LANGUAGE="VBScript">

Sub Window_OnLoad
 Set objNetwork = CreateObject("Wscript.Network")

 strUser = objNetwork.UserDomain & "\" & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = "<p align = 'center'> " & _
 "<font style='font-size:18pt;color:white'>" & _
 strUser & "<br>" & strComputer & "</font></p>"
End Sub

</SCRIPT>

<img src="test2.jpg" align="right">
<span id=UserData style="position:absolute;left:770px;top:150px"></span>
실제로 이것은 매우 간단합니다. 먼저 이름에서도 알 수 있듯이 HTA를 시작하거나 새로 고칠 때마다 자동으로 실행되는 Window_OnLoad 서브루틴이 있습니다. 이 서브루틴에 대해서는 잠시 후에 다시 설명하겠습니다. 다음으로 그래픽과 범위를 나타내는 두 가지 HTML 요소가 있습니다. 여러분도 잘 알다시피, 이 태그는 맞춤 특성을 적용하여 그림이 창의 오른쪽에 표시되도록 하면서 그래픽을 삽입하는 데 사용됩니다.
<img src="test2.jpg" align="right">
다음으로 범위에 사용된 HTML 태그는 다음과 같습니다.
<span id=UserData style="position:absolute;
left:770px;top:150px"></span>
범위 태그를 사용하기는 했지만, 대체 범위 태그란 무엇일까요? 의도나 용도에 관계없이 범위는 HTA의 명명된 영역일 뿐입니다. 즉, UserData라는 ID를 지정한 덕분에 프로그래밍 방식으로 식별 가능한 "구분된" HTA 창 섹션인 것입니다. 일단 범위를 설정하면 해당 범위에 텍스트나 HTML 코딩을 할당하는 서브루틴을 작성할 수 있습니다. 사실 앞서 소개한 예제 HTA에서 이미 이것을 구현했습니다.
이에 대해서도 나중에 다시 설명하겠습니다. 지금은 우선 범위 태그에 추가된 style 매개 변수를 살펴봐야 합니다.
style="position:absolute;left:770px;top:150px"
이미 아실 수도 있지만 이 매개 변수는 동적 텍스트를 그래픽 위에 성공적으로 배치하는 데 중요한 요소입니다. 여기서는 세 가지 개별 style 특성을 지정합니다.
Position 우리는 HTA에서 원하는 범위의 위치를 절대(absolute) 위치로 지정했습니다. Position을 absolute로 지정하면 이 예제처럼 텍스트가 다른 항목(예: 그래픽) 위에 작성되는 경우에도 범위의 위치는 항상 동일하게 됩니다.
Left 이 특성은 HTA 창의 왼쪽 가장자리를 기준으로 한 범위의 상대적 위치를 지정합니다. 이 예제의 경우 범위가 왼쪽 가장자리로부터 770픽셀(770px) 떨어진 위치에서 시작됩니다.
Top 이 설정은 Left 특성과 매우 비슷합니다. 단, 이 경우 범위의 위치가 HTA 창의 위쪽 가장자리를 기준으로 한 상대적 위치로 지정됩니다. 이 예제에서는 범위가 창의 위쪽 가장자리로부터 150픽셀(150px) 아래에서 시작됩니다.
이때 원하는 결과를 얻기 위해 범위의 위치를 왼쪽에서 770픽셀, 위쪽에서 150픽셀 떨어진 지점으로 지정해야 한다는 것은 어떻게 알 수 있을까요? 사실 원하는 위치의 정확한 픽셀 지점을 알지는 못합니다. 대신 추측할 수는 있죠. 다시 말해 페이지에 그래픽을 배치해 놓고 범위의 Left 및 Top 특성에 값을 할당해 보는 겁니다. 그런 다음 HTA를 열고 결과를 확인합니다. 정확한 위치에서 약간은 벗어날 수 있으므로 값을 조정하고 HTA를 새로 고친 다음, 다시 확인합니다. 골디락스(Goldilocks)처럼 약간의 시행 착오를 거쳐 원하는 결과를 얻으면 됩니다.
참고로 금발 소녀, 곰 세 마리, 침대와 의자, 그리고 너무 뜨겁거나 차가운 죽 등이 나오는 골디락스와 세 마리 곰이란 동화를 아실지 모르겠습니다. 골디락스를 위대한 철학자라고 할 수 있을지는 의문이지만, 남의 집에 거침없이 들어가서 죽을 먹고, 의자에 앉고, 침대에서 자는 것을 보면 이 소녀가 결코 평범하지 않은 사고 방식을 가지고 있는 것만은 분명합니다.
아무튼 그림 4에는 예제 HTA가 나와 있습니다. 이 작은 응용 프로그램이 걸작은 아닐지 모르지만, 거장 피카소라도 프로그래밍 방식으로 그래픽 위에 정보를 표현하는 일은 어렵지 않을까요?
그림 4 style의 힘
그림 4 style의 힘
그렇다면, 대체 우리는 어떻게 프로그래밍 방식으로 그래픽 위에 정보를 표시한 것일까요? 자, 이제 Figure 5에 나와 있는 Window_OnLoad 서브루틴에 대해 설명할 때가 온 것 같습니다.
Figure 5 Window_OnLoad 서브루틴 (Close Figure 5)
Sub Window_OnLoad
 Set objNetwork = CreateObject("Wscript.Network")

 strUser = objNetwork.UserDomain & "\" & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = "<p align = 'center'> " & _
  "<font style='font-size:18pt;color:white'>" & _
  strUser & "<br>" & strComputer & "</font></p>"
End Sub
이 서브루틴을 좀 더 자세히 살펴보면 실제로 그다지 설명할 만한 내용이 없다는 것을 알 수 있습니다. 여기에서 볼 수 있듯이 먼저 Wscript.Network 개체의 인스턴스를 만듭니다. 그리고 다음 코드 줄을 사용하여 사용자 이름과 도메인, 그리고 컴퓨터 이름을 검색합니다.
strUser = objNetwork.UserDomain & "\" & _
  objNetwork.UserName
strComputer= objNetwork.ComputerName
물론, 이 정보가 바로 우리가 HTA 창에 표시하고자 하는 내용입니다. strUser 변수와 strComputer 변수를 간단한 HTML 태그와 결합한 다음, 해당 문자열을 범위의 InnerHTML 속성에 할당하기만 하면 됩니다.
UserData.InnerHTML = _
  "<p align = 'center'> " & _
  "<font style='font-size:18pt;color:white'>" _
  & strUser & "<br>" & strComputer & _
  "</font></p>"
코드가 다소 복잡해 보이기는 하지만, 그렇게 어렵지는 않습니다. 여러 항목을 단일 문자열로 결합하기 때문에 복잡해 보이는 것뿐입니다. 먼저 텍스트를 단락의 가운데에 맞추는 단락 열기 태그를 추가합니다.
"<p align = 'center'> "
다음으로 18포인트 크기의 흰색 텍스트를 사용하도록 지정하는 글꼴 열기 태그를 추가합니다.
"<font style='font-size:18pt;color:white'>"
strUser는 Domain\UserName 형식의 사용자 이름이 들어가는 변수입니다. "<br>"은 줄 바꿈을 삽입하는 태그입니다. 이 줄 바꿈 태그는 한 줄에 사용자 이름을 표시하고 다른 줄에 컴퓨터 이름을 표시하기 위해 삽입하는 것입니다. strComputer는 컴퓨터의 이름이 들어가는 변수입니다. 마지막으로 글꼴 닫기 태그와 단락 닫기 태그를 추가합니다.
"</font></p>"
코드 조각을 하나씩 살펴보면 코드가 생각보다 복잡하지 않다는 것을 알 수 있습니다.
한 가지 덧붙이자면 HTML 요소는 대부분 아무 위치에나 원하는 대로 배치할 수 있습니다. 예를 들어 그래픽 아래에 가운데 맞춤으로 설정된 단추를 추가하려 한다고 가정해 봅니다. 이 경우 HTA 코드에 다음을 추가하기만 하면 됩니다.
<input type="button" value="Test Button" style="position:absolute;left:820px;top:300px">
결과적으로 그림 6과 같은 HTA가 만들어집니다.
그림 6 단추가 있는 HTA
그림 6 단추가 있는 HTA
이 경우에도 단추를 정확한 위치에 배치하려면 몇 번의 시행 착오를 거치겠지만, 그다지 어렵지는 않을 것입니다. 사실 수학에 자신 있는 사용자라면 정확한 위치를 미리 계산할 수도 있을 것입니다. 개체의 위치는 각 개체의 너비와 높이(style 매개 변수로 지정할 값), 그리고 HTA 창의 너비와 높이만 알면 계산할 수 있습니다. Scripting Guys의 테스트 컴퓨터에서는 기본적으로 HTA가 약 1020픽셀(너비) 및 685픽셀(높이)입니다. 물론, 이 결과는 컴퓨터마다 다를 수 있습니다. 문제가 없다면 이 값으로 시작하여 필요에 따라 조정하면 됩니다.
지금까지 CSS에 대해 매우 개괄적으로 살펴봤습니다. 스크립트를 아름답게 만드는 계기를 제공하는 데는 충분할 것으로 생각합니다. 철학자들이 어쩌면 혀를 차면서 스크립트의 아름다움은 다른 어떤 것도 아닌 그 내용에서 우러나는 것이라고 할 수도 있지만, 이렇게 말하고 싶군요. 역사를 통틀어 가장 위대한 철학자는 누구입니까? 그렇습니다. 플라톤, 소크라테스, 아리스토텔레스라고 할 수 있겠지요. 그렇다면 이러한 철학자들의 사진을 본 적이 있습니까? 겉모양이 중요하지 않다고 역설하는 사람들이 무엇이 두려워 사진 한 장 남기지 않았을까요? 이상하지 않습니까? 앞으로 곰곰이 생각해 볼 문제입니다.

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


 Exchange Queue &amp; A: Edge 및 Hub 전송 역할, 가상 컴퓨터 및 기타 정보
Exchange Queue & A
Edge 및 Hub 전송 역할, 가상 컴퓨터 및 기타 정보
KC Lemson and Nino Bilic

2007년 5월호 Exchange Queue & A에서는 네트워크 공유에 .pst 파일을 저장하는 것과 관련하여 발생하는 문제에 대해 설명했습니다. Windows Server 성능 팀은 최근에 시작한 블로그를 통해
이 문제에 대해 기술적으로 매우 자세히 설명했으므로 관련 링크를 참조하시기 바랍니다. 이제 질문에 대해 살펴보겠습니다.

Q: Microsoft Exchange Server 2007을 배포하려면 Edge 서버 역할을 배포해야 합니까?

A: 그렇지 않습니다. Exchange Server 2007을 배포하기 위해 Edge 서버 역할을 배포할 필요는 없습니다. 단일 컴퓨터에서 사서함, 클라이언트 액세스 및 Hub 전송과 같은 핵심 서버 역할을 실행하여 사용자 도메인에 대한 인터넷 전자 메일을 받아들이고 스팸 방지 및 바이러스 백신 프로그램을 실행하기만 하면 됩니다.

Q: Edge 전송 서버 역할과 Hub 전송 서버 역할의 차이점은 무엇입니까? Edge 전송 서버 역할을 배포하지 않을 경우 사용할 수 없는 기능이 있습니까?

A: Hub 역할이 수행하는 대표적인 기능은 조직 내에서 메일을 라우팅하고 이러한 메시지에 비즈니스 정책을 적용하는 것입니다. Hub 역할을 사용하는 경우 전송 규칙은 사용자, 메일 그룹 등의 Active Directory® 개체에 기반을 둡니다. 또한 Active Directory 구성원 자격을 기반으로 전송 규칙을 적용해야 할 수 있으므로 Hub 역할을 사용하면 메시지에 고지 사항을 추가하거나 사용자 그룹으로 전송되는 메시지를 저널링할 수 있습니다. 예를 들어 DLOfUsersOnLitigationHold로 전송되는 모든 메시지를 저널링하거나 DLOfMembersOfLegalTeam이 보내는 아웃바운드 메일에 고지 사항을 추가할 수 있습니다. Hub 서버에서 스팸 방지 에이전트를 실행할 수는 있지만 이러한 에이전트는 기본적으로 사용되지 않으므로 서버의 \scripts 디렉터리에 있는 install-antispamagents 스크립트를 실행하여 직접 설치해야 합니다.
Edge 역할이 수행하는 대표적인 기능은 조직의 내/외부로 메일을 라우팅하고 해당 메시지에 대해 메시지 관리 작업(스팸 방지, 바이러스 차단, 콘텐츠 또는 첨부 파일 필터링 등)을 수행하는 것입니다. 스팸 방지 기능은 Edge 서버를 설치할 때 사용하도록 설정됩니다. Edge 역할의 고유한 특징 중 하나는 이 역할이 Windows® 도메인에 참가하는 데 아무런 요구 사항이 없다는 것입니다. Edge 역할은 Windows 도메인에 포함되지 않은 독립 실행형 Windows Server® 설치에서도 실행할 수 있으며 이때도 이 역할을 회사 포리스트 내 Exchange 2007 조직의 일부로 관리할 수 있습니다.
이는 특히 작업 그룹에 포함하려는 서버가 경계 네트워크에 있거나 경계 네트워크의 컴퓨터에 대해 명시적으로 별도의 포리스트를 만들려는 경우 유용합니다. 이러한 상황에서 배포한 Edge 서버는 회사 네트워크와 인터넷 간에 전송되는 메일에 대해 모든 메시지 관리 및 라우팅을 수행할 수 있습니다. 또한 이 Edge 서버를 다른 Exchange 2007 시스템 관리와 일관된 방식으로 관리할 수도 있어서 매우 편리합니다.
Edge 서버에서는 전송 규칙이 Active Directory 개체가 아닌 SMTP 주소에 기반을 둡니다. 하지만 Active Directory의 사용자 또는 메일 그룹의 SMTP 주소를 사용할 수 있습니다. Edge 서버에서만 가능한 격리 작업의 경우를 제외하고는 대부분의 경우 Edge 전송 규칙은 Hub 전송 규칙의 하위 집합입니다.
뿐만 아니라 Edge 서버에는 Hub 전송 서버에서는 사용할 수 없는 에이전트를 통해 제공되는 첨부 파일 제거 및 주소 다시 쓰기와 같은 몇 가지 기능이 있습니다. 첨부 파일 제거는 확장명이 .exe 및 .com인 잠재적 위험이 있는 첨부 파일을 선택하여 제거할 수 있는 기능입니다. 주소 다시 쓰기 에이전트에서는 전자 메일 헤더를 다시 쓸 수 있도록 허용하므로 이를 통해 사용자 계정의 도메인 및 기본 SMTP 프록시 주소가 @contoso.com이더라도 인터넷으로 아웃바운드되는 메시지가 @northwindtraders.com에서 온 것처럼 보이게 할 수 있습니다. 또한 Edge 서버는 도메인 또는 주소 공간을 기준으로 해서만 라우팅을 수행하므로 Exchange와 다른 전자 메일 시스템 간에 동일한 SMTP 주소 공간을 공유하는 경우에는 이러한 라우팅을 Hub 서버에서 수행하거나 Edge 서버의 주소 다시 쓰기 에이전트와 협력하여 수행해야 합니다.
또 한 가지 중요하게 고려해야 할 사항은 Exchange 2007 서버가 Hub 서버 역할 또는 Edge 서버 역할 중 어느 역할을 수행하든지에 상관없이 인터넷에 직접 노출되는지 여부입니다. 다시 말해 도메인의 MX 레코드에 지정되어 있는 포트 25에 대한 연결이 어떤 방식으로 Exchange 2007에 연결되는지를 검토해야 합니다. 여러분의 경우 인터넷에 SMTP 게이트웨이, 바이러스 차단 프로그램 또는 사용자 도메인에 대한 메일을 받아들여 회사 네트워크 내의 Exchange로 전달하는 다른 솔루션을 이미 구축했을 수도 있습니다. 인터넷에 직접 노출되도록 Edge 서버 또는 Hub 서버를 배포한 경우 Exchange 2007의 가장 뛰어난 기능 중 하나인 수신 허용 목록 집계 기능을 사용할 수 있습니다. 수신 허용 목록 집계 기능을 사용하는 경우 Microsoft Outlook®의 수신 허용 목록에 보낸 사람을 추가하면 이 목록이 Edge 역할이나 Hub 역할에 안전하게 전파되어 해당 보낸 사람으로부터 전송된 메시지에 대해서는 콘텐츠 필터링이 수행되지 않습니다. 이러한 작업은 소매업자가 보내는 전자 메일이나 인터넷 회보에 대해 일반적으로 수행됩니다. 물론 어떤 사용자에게는 스팸인 전자 메일이 다른 사용자에게는 회보가 될 수도 있기 때문에 수신 허용 목록은 사용자 각각을 기준으로 작성됩니다. 수신 허용 목록 집계 기능의 작동 방식에 대한 자세한 내용은 Exchange 2007 설명서를 참조하십시오.
사용자 도메인에 대한 인터넷 전자 메일을 받아들이는 Hub 역할로 실행되는 서버를 배포한 경우에는 몇 가지 사항을 염두에 두어야 합니다. 가장 먼저 서버가 포트 25와 같은 필수 포트에서만 연결을 수신하도록 적절한 방화벽 또는 포트 필터링 솔루션을 구축해야 합니다. 스팸 방지 에이전트도 기본적으로 설치되지 않거나 설치되더라도 기본적으로 사용하지 않도록 설정되므로 설치해야 합니다. Hub 서버의 가장 일반적인 배포 시나리오는 회사 네트워크 내부에 배포하는 것이므로 기본적으로 익명 연결을 허용하지 않습니다. 하지만 포트 25 수신 커넥터의 AnonymousUsers 권한 그룹을 다시 한 번 확인하는 것이 좋습니다. 수신 허용 목록 집계 기능을 사용하고 이를 정기적으로 실행하여 사용자가 사서함의 수신 허용 목록을 업데이트하면 수신 허용 - 보낸 사람 목록에 있는 보낸 사람이 해당 사용자에게 보내는 메일에 대해 콘텐츠 필터링이 수행되지 않도록 할 수도 있습니다. 자세한 내용은 블로그를 참조하십시오.
다음 코드는 SafeList.bat라는 배치 파일을 사용하여 매일 오후 11시 정각에 모든 서버에서 모든 사서함을 업데이트하는 AT 명령을 보여 줍니다.
at 23:00 /every:M,T,W,Th,F,S,Su cmd /c
“D:\SafeList.bat”
다음 코드는 SafeList.bat 파일의 내용을 보여 줍니다.
“d:\Program Files\Microsoft Command Shell\v1.0\Powershell.exe”
-psconsolefile “d:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1” -command
“get-mailbox | where {$_.RecipientType
-eq [Microsoft.Exchange.Data.Directory.Recipient.RecipientType]::UserMailbox } | update-safelist”
설정이 올바르게 작동하는지 확인해야 하는 경우 이에 대한 자세한 내용은 Exchange 2007 설명서를 참조하십시오.

Q: Exchange가 설치된 가상 PC 이미지를 부팅한 후부터 디렉터리 또는 LDAP 서버 연결과 관련된 문제가 끊이지 않고 있습니다. 389로의 텔넷 연결은 제대로 작동하며 모든 서비스도 실행됩니다. 이유가 무엇일까요?

A: 저도 작년에 Tech•Ed에 참여했을 때 이러한 문제를 경험한 적이 있습니다. 작업하는 컴퓨터에서 복사한 가상 PC 복사본을 랩톱에 저장해 두었습니다. 그리고 다음 달에 Exchange 2007 베타 2 출시와 동시에 관련 문서를 게시하려는 언론사 직원들을 위해 이 이미지를 사용하여 Exchange 2007을 시연해 볼 계획이었습니다.
제품을 수없이 많이 시연해 본 결과 빌드가 안정적이라는 사실을 알고 있었으므로 준비를 철저히 하지는 않았습니다. 월요일 아침, 첫 번째 만남이 있기 불과 몇 시간 전에 가상 PC를 부팅했는데 빌드의 모든 부분에서 도메인 컨트롤러에 연결할 수 없다는 메시지를 표시했습니다. 그때 제가 얼마나 진땀을 흘렸을지는 충분히 상상이 가실 것입니다. 당시 같이 있던 실력이 뛰어난 많은 사람들의 도움 덕분에 이 문제를 신속하게 해결할 수 있었습니다.
Tech•Ed에 참여한 당시 발생한 문제의 원인은 너무도 느린 제 랩톱에서 가상 PC를 실행한 데 있었습니다. 이 문제의 근본 원인은 DNS와 Active Directory의 경합 상태에 있었습니다. 이미지의 DNS 서버는 Active Directory와 통합되도록 구성되어 있었는데 이미지의 서비스가 로드되는 순서로 인해, 그리고 제 랩톱의 낮은 성능으로 인해 DNS 서버가 Active Directory에 연결하려고 할 때에 필요한 디렉터리 서비스가 아직 시작되어 있지 않았습니다.
이러한 상황은 DC와 Exchange를 동일한 컴퓨터에서 실행하는 모든 서버에서 발생할 수 있습니다. 물론 이러한 문제가 가상 이미지에서만 발생하는 것은 아니지만 가상 환경에서는 추가적인 성능 저하가 발생할 수 있으므로 그 확률이 높으며 특히, 제 랩톱과 같이 컴퓨터 성능이 그다지 좋지 않은 경우에는 그 확률이 더욱 높아집니다.
두 컴퓨터 특히, 서로 다른 네트워크에 있는 두 컴퓨터 간에 복사된 가상 PC 이미지에서도 이와 비슷한 문제가 발생한 것을 목격한 적이 있습니다. 여러분도 이와 비슷한 상황이라면 이미지에 있는 OS의 IP 주소를 확인해 보십시오. 이전 네트워크의 오래된 IP 주소일 수 있습니다. 그런 경우라면 새 네트워크에서 IP 주소를 가져와 IP 주소를 새로 고친 다음 문제가 해결되는지 살펴보십시오.
앞으로 이러한 문제가 발생하지 않도록 하려면 게스트의 DNS 서버를 Active Directory와 통합하지 말고 호스트와 게스트 모두에 DNS를 설치하십시오. 알 수 없는 레코드의 경우 게스트가 이를 호스트에게 전달하고 마찬가지로 호스트는 이를 적절한 DNS 서버로 전달하도록 설정하십시오. 그러면 이미지가 부팅된 후 DNS 레코드를 업데이트하려고 하는 경우 실패할 확률이 훨씬 적어집니다.

Q: Exchange 2007 설치 프로그램이 이전 버전의 Exchange 설치 프로그램과는 완전히 다른 것 같습니다. Exchange 2007 설치 프로그램은 어떻게 작동하나요?

A: 그렇습니다. Exchange 2007 설치 프로그램은 여러 단계로 이루어져 있습니다. 전체 프로세스가 작동하는 방법은 다음과 같습니다.

처음 setup.exe를 실행하면 실제 서버 역할을 설치하기 전에 설치해야 할 대부분의 필수 소프트웨어에 대한 링크가 표시됩니다. 이러한 필수 소프트웨어를 모두 설치하고 나면 Install Microsoft Exchange(Microsoft Exchange 설치) 링크가 클릭할 수 있도록 활성화됩니다(그림 1 참조).
그림 1 일반 필수 소프트웨어 설치 후 활성화되는 설치 링크
그림 1 일반 필수 소프트웨어 설치 후 활성화되는 설치 링크
네트워크에서 setup.exe를 실행한 경우 설치 링크를 클릭하면 주요 설치 파일이 로컬 컴퓨터의 %TEMP%\ExchangeServerSetup\ 폴더에 복사됩니다. 그런 다음 설치 마법사가 실행됩니다.
설치 마법사에서는 사용권 계약, 오류 보고, 설치 유형(설치할 서버 역할을 선택하는 단계) 등의 다양한 옵션을 단계별로 안내합니다. 마법사의 각 페이지는 현재 Exchange 조직(있는 경우)의 존재 여부와 그 상태에 따라서 달라집니다.
이 단계를 완료하고 나면 준비 검사가 실행됩니다. 이는 Microsoft Exchange Server Best Practices Analyzer(BPA)의 수정된 버전으로, 최신 필수 XML 파일 다운로드를 위해 기본적으로 인터넷에 연결됩니다. 준비 검사에서는 필수 소프트웨어를 정기적으로 업데이트할 수 있으며 제품이 제공된 후 Exchange 팀에서 발견한 문제를 해결할 수도 있습니다. 선행 조건 검사가 완료되면 그 결과를 검토한 다음 작업을 계속할 수 있습니다. 또한 설치를 계속하기 전에 해결해야 할 문제가 있는 경우에는 해당 문제를 확인할 수도 있습니다. 서버가 선행 조건 검사에 통과하지 못한 경우 대부분은 검사를 다시 시도할 수 있습니다.
선행 조건 검사를 통과하면 앞에서 선택한 역할을 설치할 수 있는 설치 단추가 나타납니다. 설치 단추를 클릭하면 선택한 역할에 필요한 파일만 복사되어 설치됩니다.
설치 프로그램이 끝날 때 Exchange 관리 콘솔을 실행하거나 새로 나온 Exchange 2007 업데이트가 있는 경우 이를 적용할 수 있습니다.

KC Lemson은 Exchange Server 팀의 사용자 환경 관리자로, 온라인 뱅킹 계좌는 일시 정지되어 있습니다.
Nino Bilic은 Exchange Server 팀의 지원 기능 프로그램 관리자로, 최근 신용 카드에 보조 전자 메일 주소를 추가했습니다.


 Security Watch: ACL 관리 도구
Security Watch
ACL 관리 도구
Jesper M. Johansson

Windows에서 액세스 제어 목록(ACL)을 사용하면 사용자와 프로세스의 리소스(예: 파일 및 폴더) 사용을 매우 세밀하게 제어할 수 있습니다. ACL 관리는 사용자 시스템의 보안 유지에 있어 다소 복잡한 작업이 될 수 있지만, 다행히 사용 권한 및 ACL 관련 작업을 자동화하고 간소화하는 데 유용한
여러 유틸리티를 활용할 수 있습니다.
대부분의 독자들은 첫 출시 버전부터 Windows NT®의 모든 버전에 포함되어 왔던 cacls.exe 도구에 친숙할 것입니다. Windows Vista™에서 cacls.exe를 실행하면 화면에 다음과 같은 메시지가 나타납니다.
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

C:\Windows\system32>cacls

 NOTE: Cacls is now deprecated, please use Icacls.
Windows Vista에서 Microsoft는 ACL 업데이트(technetmagazine.com/issues/ 2007/06의 TechNet Magazine 2007년 6월호 참조)는 물론, ACL 관리에 사용하는 일부 도구도 업데이트했습니다. 이러한 업데이트에서 특히 가장 중요한 것은 바로 명령줄 도구 업데이트입니다.
icacls.exe는 Windows Vista에서 새로 등장한 항목으로, Windows Server® 2003 서비스 팩 2에서 하위 수준으로 사용되기도 했습니다. 이 icacls.exe는 결국 cacls.exe를 대체하게 될 것입니다. cacls.exe는 Windows® 2000에서 보다 정밀한 사용 권한을 도입한 이후 지금까지 약 7년 동안 이 기능을 지원하도록 완전히 업데이트되지 않았기 때문입니다.
그런데 놀랍게도 문제의 이 cacls.exe에는 몇 가지 새로운 기능이 추가되었습니다. 첫째, cacls.exe는 이제 연결 지점과 심볼 링크 모두를 인식하여 트래버스할 수 있습니다. 둘째, SDDL(Security Description Definition Language) 문자열을 사용하여 ACL을 인쇄하고 설정할 수도 있습니다.
그러나 cacls.exe의 이러한 업데이트에도 불구하고 icacls.exe가 제공하는 기능은 훨씬 매력적입니다.

ACL 저장 및 복원
지난 10년 동안 필자를 비롯하여 많은 사람들은 나중에 복원할 수 있도록 ACL을 저장하는 기능을 원했습니다. 그러나 이 기능은 ACL에서 수행하기에 가장 복잡한 작업 중 하나로서, 일부 특수한 경우를 제외하면 애초에 ACL을 손상시키지 않고 이전 상태로 정확히 복원하기는 어렵습니다. 그럼에도 불구하고 이 기능은 상당히 유용할 수 있습니다.
ACL을 저장 또는 복원하는 방법을 설명하기 전에, 먼저 이런 작업이 왜 그토록 어려운지 그 이유를 알려드릴까요? 한 대학교의 학생 사용자 데이터가 들어 있는 계층 구조를 예로 들어 봅시다. 2월 1일 ACL을 저장했는데 4월 17일 어떤 이유로 이 ACL이 손상된 것을 발견하여 저장된 사본으로 ACL을 복원해야 합니다. 이 작업에 어떤 복잡한 요소가 있을까요?
우선 새학기는 4월 2일에 시작되었습니다. 그리고 학생의 약 15%가 졸업했으므로 이들의 디렉터리는 이제 존재하지 않습니다. 따라서 백업 파일에 있는 ACL은 유효하지 않습니다. 또 다른 15%의 학생은 새학기에 추가된 신입생들입니다. 따라서 이들에게는 현재 홈 디렉터리가 있지만 백업 파일에는 ACL이 없습니다. 이들의 ACL은 어디에 있을까요? 물론 나머지 70%의 학생은 그대로지만 이들도 새로운 파일과 폴더를 만들고 다른 일부는 삭제하기도 했습니다. 삭제된 파일과 폴더는 무시하면 되겠지만 새로 만든 폴더는 어떻게 구성할까요? 어떤 학생이 3월 4일에 폴더 하나를 친구들과 공유했다면 또 어떻게 될까요? ACL을 복원하면서 이 공유 설정을 해제하시겠습니까?
ACL의 저장과 복원은 이렇게 많은 사람들의 생각과 달리 전혀 단순하지 않으며 매우 신중해야 하는 작업입니다. 결과적으로 정의되지 않은 동작이 초래될 가능성이 높기 때문입니다. 따라서 ACL 복원은 최후의 수단으로 사용해야 합니다. 백업 이후 기간이 길수록 복원할 때 문제가 발생할 가능성이 높습니다.
그래도 이 기능을 사용해야 한다면 /save 스위치와 함께 icacls.exe를 실행하십시오.
icacls <target> /save acls.bin /t
그러면 ACL이 acls.bin이라는 파일에 저장됩니다. 이 파일 안에는 ACL이 있는 각 개체에 대한 줄 다음에 SDDL로 이러한 ACL을 지정하는 줄이 순서대로 들어 있습니다. 이 명령에 사용된 /t 스위치는 사용자가 지정한 개체와 이 개체의 모든 하위 개체 및 컨테이너만을 대상으로 작업하도록 합니다.
도구 키트에 저장 기능이 추가된 것은 반가운 일이지만 여기에도 몇 가지 결함이 있습니다. 예를 들어 이 기능은 DACL(임의 액세스 제어 목록)만 저장하고 SACL(시스템 액세스 제어 목록)은 저장하지 않습니다. SACL이 있어도 이를 나타내는 더미 값만 저장할 뿐 실제로는 SACL의 어떤 부분도 저장하지 않습니다.
ACL이 저장되는 방식에서도 특이한 문제가 발생합니다. 자주 사용하는 텍스트 편집기에서 저장된 ACL을 열기 전에 반드시 다음 사항을 명심하십시오.
저장된 ACL을 절대 편집하지 마십시오!
저장된 ACL이 들어 있는 파일을 텍스트 편집기에서 열면 유니코드(UTF-16) 형식의 텍스트 파일처럼 보입니다. 사실 이것은 틀린 것도 아닙니다. 그래서 사용자는 텍스트 편집기에서 편집하고 저장할 수 있을 것이란 생각이 들 수도 있습니다. 그러나 절대 그렇게 하지 마십시오!
저장된 ACL이 들어 있는 파일을 텍스트 편집기에서 열고 저장하면 이 파일로는 ACL을 복원할 수 없게 됩니다. 이런 파일은 사실상 유니코드 텍스트 파일이 아니기 때문입니다. 유니코드 텍스트 파일은 2바이트 0xfffe로 시작되어야 합니다. 메모장과 같은 텍스트 편집기에서 이런 파일을 저장하면 플래그가 파일의 처음 2바이트에 삽입됩니다. 그러나 icacls.exe 도구는 ACL 데이터가 파일의 바이트 0에서 시작하는 것으로 간주합니다. icacls.exe 도구는 처음 2바이트를 작업 대상 개체를 지정하는 문자열의 일부로 간주하기 때문에 파일에 들어 있는 ACL을 구문 분석할 수 없는 것입니다. 따라서 백업 파일은 사용할 수 없게 됩니다.
Microsoft도 이 문제를 알고 있지만 Windows Vista 베타 버전이 진행되던 중 매우 늦게 보고되었기 때문에 출시 전에 수정하지 못했습니다. 현재로서는 이 문제가 언제 수정될지, 심지어 수정 계획이 있는지도 알 수가 없습니다. 따라서 당분간은 저장된 ACL을 편집하지 않는 것이 최선입니다. 반드시 편집해야 한다면 파일을 .bin 파일로 저장하고 자주 사용하는 개발 도구와 같은 16진 편집기를 사용하십시오.
/save 스위치를 사용해서 ACL을 저장한 다음에는 /restore 스위치와 함께 icacls.exe를 사용하여 이를 복원할 수 있습니다. 가장 단순한 형태의 복원 명령 구문은 다음과 같습니다.
icacls <directory> /restore acls.bin
이 복원 절차는 파일에는 적용되지 않습니다. 이를 확인하려면 그림 1의 명령 시퀀스를 참조하십시오. 여기서 필자는 특정 파일에서 icacls.exe를 선택하여 저장 파일을 만들었습니다. 그런 다음 /save를 /restore로 바꾸어 복원을 시도했습니다. 그러나 restore 명령은 디렉터리에서만 작동하기 때문에 이 시도는 실패했습니다. 이 명령이 수정해야 하는 파일은 acls.bin 파일에 이미 지정되어 있습니다. ACL을 복원하기 위해 필자는 파일 대신 디렉터리를 대상으로 지정했습니다. 마지막 명령에서 "."를 작동 대상 개체로 지정한 것입니다.
Figure 1 ACL 저장 및 복원 (Close Figure 1)
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files

C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
이때 restore 명령은 반드시 상승된 권한으로 실행해야 한다는 점을 주의하십시오! ACL에 대해 읽기 권한만 있으면 하위 수준의 관리자 또는 일반 사용자 계정으로도 명령 프롬프트에서 save 명령을 실행할 수 있습니다. 그러나 ACL을 복원하려면 완전한 관리자 토큰이 필요합니다.

SID 대체
icacls.exe에서 매우 유용한 또 다른 기능은 특정 사용자의 권한을 다른 사용자의 권한으로 대체할 수 있다는 점입니다. 이런 작업은 /substitute 스위치를 사용하여 복원하는 도중 수행됩니다. substitute 스위치에 대한 설명서에서는 SID가 필요한 것으로 나와 있지만 뒷부분에는 일반 사용자 이름을 사용할 수 있다는 설명이 있습니다. 따라서 그림 2의 시퀀스가 제대로 작동하는 것입니다.
Figure 2 복원 중 SID 대체 (Close Figure 2)
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files
여기서 볼 수 있듯이 필자는 결국 이전의 것과 동일한 ACL을 사용하지만, foo에 대한 사용 권한을 지정하는 데 사용된 ACE가 이제는 bar에 대한 사용 권한을 지정하고 있습니다.

소유자 변경
chown 도구는 여러 해 동안 UNIX 시스템에서 중요한 요소였습니다. 원래 Windows는 개체 소유자를 변경할 수 있는 기본 방법이 없었습니다. 그러다가 Resource Kit을 통해 setowner 도구가 등장했고, 이후 Windows NT 4.0에서 takeown.exe 도구가 등장했지만 이 유틸리티에서는 소유권을 뺏는 것이 가능할 뿐 해당 사용자의 암호가 없으면 다른 사용자에게 소유권을 부여할 수 없었습니다. 이제 icacls.exe에서는 개체 소유자를 설정할 수 있는 기능이 기본적으로 제공됩니다. 단, 해당 개체에 소유자를 설정할 수 있는 권한이 있어야 합니다.
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
안타깝게도 icacls.exe는 개체 소유자를 보여줄 수가 없습니다. 명령줄에서 개체 소유자가 누구인지 실제로 확인할 방법이 없는 것입니다. 게다가 개체의 ACL을 저장할 경우 이 개체의 소유자는 저장되지 않습니다.
또한 icacls.exe에는 소유자 변경을 위한 SeTakeOwnershipPrivilege를 호출하지 않는 버그가 있습니다. 사용자에게 ACL에 따라 개체 소유자를 변경할 권한이 있는 경우 icacls.exe는 정상적으로 작동합니다. 그러나 관리자이지만 개체의 ACL에 따라 소유자를 변경할 권한이 없다면 이 버그 때문에 icacls.exe를 사용하여 소유자를 변경할 수는 없습니다. 이런 경우에는 takeown.exe 도구를 사용해야 합니다. 이 도구는 SeTakeOwnershipPrivilege를 호출하지만 임의의 계정이 아니라 사용자의 계정 또는 Administrators 그룹으로만 소유자를 변경할 수 있습니다.
C:\>takeown /f c:\test

SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
물론 Microsoft 다운로드 센터에서 다운로드할 수 있는 subinacl 도구 역시 setowner 스위치를 갖고 있습니다. 그러나 subinacl은 여러 면에서 icacls보다 직관적이지만 사용 방법은 훨씬 복잡합니다.

특정 사용자의 파일 찾기
icacls에 포함된 또 다른 유용한 기능은 특정 사용자에 대한 권한이 들어 있는 파일을 찾을 수 있다는 것입니다. 예를 들면 다음과 같습니다.
C:\windows\system32>icacls “c:\program files” /findsid jesper /t

SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
이 기능은 특정 사용자가 어떤 파일에 액세스할 수 있는지 알아내려 할 때 유용합니다.

ACL 재설정 및 변경
ACL이 손상되었거나 완전히 파괴된 경우, icacls.exe는 이를 재설정하여 부모로부터 상속받을 수 있습니다. 2006년 가을 제로 데이(zero-day) 보안 문제가 발생했을 때 이 기능이 있었더라면 매우 유용했을 것입니다. Windows 구성 요소에서 이 문제를 완화하는 데 사용했던 방법 중 하나는 개체에 대한 Everyone 액세스를 거부하는 것이었습니다. 이 작업은 간단했지만 문제는 Windows XP와 Windows Server 2003에서 기본 제공하는 도구로는 이 ACE(액세스 제어 항목)를 제거하는 것이 거의 불가능하다는 것이었습니다. 그러나 Windows Vista에서는 다음과 같은 명령만 실행하면 됩니다.
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset

processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
물론 icacls.exe에는 표준 grant/deny/remove 기능이 모두 포함되어 있습니다. 이 중 실제로 새로운 항목은 remove뿐입니다. 이 스위치를 사용하면 특정 개체 또는 계층 구조에서 특정 사용자의 모든 Allow ACE, 모든 Deny ACE 또는 둘 모두를 제거할 수 있습니다. 그림 3은 여러 grant, remove, deny 기능의 일부 예를 보여줍니다.
Figure 3 작업 허용, 거부 및 제거 (Close Figure 3)
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files
Deny ACE만 제거하는 기능은 특정 그룹이나 사용자에게 개체에 대한 액세스를 제공할 때 유용합니다.

무결성 수준 설정
icacls.exe는 무결성 수준을 표시하고 설정하는 기능도 갖고 있습니다. Windows Vista는 개체에 무결성 레이블을 지정하는 기능을 지원합니다. icacls.exe는 이런 작업을 수행할 때 사용하는 명령줄 도구입니다.
C:\>icacls c:\test /setintegritylevel high

processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
    Mandatory Label\High Mandatory Level:(NW)

Successfully processed 1 files; Failed processing 0 files
단, icacls.exe는 무결성 레이블이 개체에 명시적으로 설정된 경우에만 이를 표시합니다. 대부분의 파일에 이런 명시적 설정이 없기 때문에 무결성 레이블이 표시되는 경우는 흔치 않습니다.
마지막으로, icacls.exe는 개체에 정식 ACL이 있는지 확인할 수 있습니다. 앞서 언급했듯이 타사 도구는 ACL에 ACE를 잘못된 순서로 입력하는 것으로 알려져 있습니다. icacls.exe는 아래와 같이 이런 종류의 문제를 확인하고 수정할 수 있습니다.
C:\>icacls c:\test /verify
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

ACL UI
ACL UI, 즉 ACL 사용자 인터페이스는 Windows XP에 있던 UI에서 약간 수정되었습니다. 그림 4와 5는 각각 Windows XP와 Windows Vista의 ACL UI 대화 상자를 보여 줍니다.
그림 4 Windows XP의 ACL UI 대화 상자
그림 4 Windows XP의 ACL UI 대화 상자
그림 5 Windows Vista의 ACL UI 대화 상자
그림 5 Windows Vista의 ACL UI 대화 상자
그림을 보면 몇 가지 변화를 알 수 있습니다. 첫째, 이 대화 상자는 현재 작업 중인 개체를 매우 명확하게 보여 주기 때문에 한 번에 여러 개체를 작업할 때 유용할 수 있습니다. 둘째, 하단에는 일부 도움말에 대한 하이퍼링크가 있습니다. 그러나 가장 주목할 만한 변화는 추가 단추와 제거 단추가 사라지고 대신 Windows Vista에서 UAC(사용자 액세스 제어)를 지원하기 위해 폭넓게 제공되는 편집 단추로 대체되었다는 점입니다. 이 단추의 방패 표시를 보면 알 수 있듯이, 이 대화 상자를 연 사용자는 ACL을 편집할 권한이 없습니다. 따라서 권한을 편집하려면 먼저 권한 상승을 수행해야 합니다. 이때 C: 드라이브의 루트에 폴더를 만들고 해당 속성을 즉시 확인해보면 이것이 기본값이 아니라는 것을 알 수 있습니다. 폴더의 소유자는 ACL을 편집할 수 있는 암시적 권한을 갖고 있으므로 방패 모양이 표시되지 않습니다. 방패 표시는 권한 상승 메시지를 실행 프로세스의 일부로 표시하는 데 사용되는 메커니즘인 COM 모니커를 나타냅니다. 편집 단추를 클릭하면 친숙한 권한 상승 대화 상자가 표시되며, 여기서 계속을 클릭하면 Windows XP에서 추가 단추를 클릭했을 때 표시되는 것과 거의 동일한 대화 상자가 나타납니다. ACL UI는 여러 위치에서 이러한 이중 대화 상자 방식을 따르고 있습니다. 즉, 권한 상승 전까지 하나의 대화 상자가 표시되다가 권한을 상승하면 이전 버전의 Windows로부터 친숙한 이전 대화 상자가 표시되는 것입니다.
고급 단추를 클릭하고 감사 탭을 클릭하면 항상 그림 6과 같은 권한 상승 단추가 나타납니다. 개체 소유자로서 개체에 대해 모든 제어 권한을 갖고 있더라도 권한을 상승하지 않으면 감사를 수정할 수 없습니다. GUI 도구에서 '감사 및 보안 로그 관리'라 부르는 SE_SECURITY_NAME 권한이 개체 SACL 수정 기능을 제어하기 때문입니다. 이러한 권한은 기본적으로 관리자만 가지고 있습니다. 그러나 관리 승인 모드(UAC를 사용하는 경우)에서 이러한 권한은 관리자 계정에서 제거되므로 관리자라 해도 권한 상승이 필요합니다.
그림 6 Windows Vista에서 감사 설정을 수정하려면 항상 권한 상승 필요
그림 6 Windows Vista에서 감사 설정을 수정하려면 항상 권한 상승 필요
ACL을 수정할 때 권한 상승에 관해 유의해야 할 마지막 사항은 이러한 모든 설명이 UAC를 해제하지 않은 상태를 전제로 한다는 점입니다. UAC를 해제하면 모양이 다른 대화 상자를 제외하고 모든 동작이 Windows XP에서와 동일한 상태로 돌아갑니다. 그러나 관리자로 로그온한 경우에는 토큰에 항상 Administrators SID가 포함되어 있으므로 권한을 상승할 필요는 없습니다.

기타 도구
icacls.exe는 매우 유용한 도구로서 cacls.exe에 비해 크게 향상되었지만 아직 몇 가지 단점이 남아 있습니다. 가장 두드러진 단점은 아마도 파일과 디렉터리 외에는 다른 개체에 대한 액세스를 관리할 수 없다는 점일 것입니다. Windows Vista는 기타 개체의 ACL에 있어서는 Windows XP에 비해 거의 달라진 점이 없습니다. 그러나 여전히 서비스, 레지스트리 키, 심지어 Active Directory® 개체에 대한 ACL을 관리해야 할 때가 있습니다.
명령줄을 매우 선호하는 사용자라면 이런 작업을 수행하는 데 subinacl.exe가 필요합니다. subinacl.exe는 지원 도구에 포함되어 있으며 다운로드에서도 구할 수 있습니다.
그런데 subinacl.exe는 사용 방법이 그리 간편하지 않습니다. 때때로 기능이 너무 둔할 때도 있습니다. 그래도 subinad.exe는 액세스 제어 관리에 있어 놀랄 만큼 강력한 도구라 할 수 있습니다. 고급 관리자라면 반드시 이 도구가 필요합니다.

레지스트리 ACL
레지스트리 ACL은 파일 시스템 ACL과 똑같은 변화를 거쳤지만 범위 면에서 파일 시스템보다 훨씬 작다고 할 수 있습니다. 이전 버전의 Windows로부터 명확히 달라진 점은 Power Users의 문제점으로 인해 거의 모든 Power User ACE가 없어졌다는 것입니다. 이제 Power Users는 다른 사용자들보다 강력한 것으로 간주되지 않습니다. 그래도 Power Users의 ACE가 모두 제거되지는 않았다는 사실은 ACL이 실제로 얼마나 복잡한 것인지 보여 주는 증거라 할 수 있습니다. 안타깝게도 몇 개는 누락된 것입니다.
레지스트리의 ACL을 살펴보면 몇 군데에서 RESTRICTED라는 SID의 ACE를 볼 수 있습니다. 이 SID는 Windows Vista에서 처음 등장한 것은 아니지만 잘 알려지지는 않은 SID입니다. RESTRICTED SID는 제한 토큰을 표시하는 모든 프로세스를 나타냅니다. 제한 토큰은 CreateRestrictedToken API의 특수한 기능을 통해 생성됩니다. 이러한 토큰은 하나 이상의 제한 SID(별도의 액세스 확인에 사용되는 SID)를 갖고 있습니다. 예를 들어 제한 토큰으로 실행되는 프로세스가 있다고 가정할 경우, 이 프로세스가 RESTRICTED SID에 대한 ACE를 통해 개체 액세스를 시도하면 사실상 Windows가 두 번의 액세스 확인 작업을 수행합니다. 첫 번째는 일반적인 액세스 확인이고, 두 번째는 첫 번째와 똑같은 작업을 토큰의 제한 SID에 대해서만 수행하는 것입니다. 이 두 가지 액세스 확인이 모두 통과해야 합니다.
현재 RESTRICTED SID를 사용하는 몇 가지 ACL(특히 레지스트리에)이 있습니다. 그림 7은 이러한 ACL의 스크린샷입니다.
그림 7 Registry ACL의 몇 군데에 RESTRICTED에 대한 ACE 포함
그림 7 Registry ACL의 몇 군데에 RESTRICTED에 대한 ACE 포함
현재는 특히 제한 SID와 관련하여 제한 토큰 기능을 사용하는 프로세스가 거의 없습니다. 제한 토큰 기능을 사용하는 프로세스의 예를 한 가지 들면 Windows 방화벽, 기본 필터링 엔진 및 진단 정책 서비스를 호스팅하는 서비스 프로세스가 있습니다. 이 프로세스는 쓰기 제한 토큰도 사용합니다. 필자가 찾아본 바로는 현재 Windows Vista에서 RESTRICTED 및 쓰기 제한 토큰을 사용하는 서비스는 9개뿐입니다.
비교적 최근에 출시된 기존 버전의 Windows와 마찬가지로 레지스트리 사용 권한과 관련하여 가장 바람직한 방침은 최대한 신중을 기하는 것입니다. 예외적이고 명백한 목적이 있는 상황 외에는 레지스트리의 사용 권한을 수정하지 마십시오. 레지스트리에서 수행되는 민감한 작업과 복잡한 상속 모델을 감안할 때 레지스트리의 ACL을 잘못 수정하면 치명적 오류가 발생할 가능성이 매우 높아집니다.

요약
대부분의 다른 Windows 버전과 마찬가지로 Windows Vista에서도 액세스 제어에 대해 몇 가지 미묘한 변경이 수행되었습니다. 그러나 최근 출시된 일부 다른 버전과 달리 사소한 변경 사항이 많기 때문에 전체적으로는 액세스 제어 동작이 상당히 변화되었다고 할 수 있습니다. 특히 UAC는 무결성 레이블과 ACL UI의 수정 등 몇 가지 변화가 필요했습니다. 또한 최초로 대규모 ACL 정리 작업이 수행되었습니다.
여러 가지 면에서 Windows의 기본 ACL은 Windows Vista에서 많이 단순해졌으며 이는 최초의 시도라 할 수 있습니다. 그러나 이전 버전과 마찬가지로 액세스 제어에 있어서는 철저히 파악하기 전까지 매우 신중한 자세를 유지해야 합니다. 새로운 OS 버전에서는 특히 조심해야 합니다. 이 컬럼에서 소개된 여러 도구가 여러분의 ACL 관련 작업에 큰 도움이 되기를 바랍니다.

Jesper M. Johansson은 소프트웨어 보안 문제 분야의 수석 보안 엔지니어이며 TechNet Magazine의 객원 편집자로서, MIS 박사 학위를 보유하고 있으며 컴퓨터 보안 분야에서 20여 년 활동해왔습니다. 이 칼럼은 Roger Grimes와 Jesper Johansson의 신간 서적 Windows Vista Security: Securing Vista Against Malicious Attacks(Wiley, 2007)에서 일부를 발췌하여 재구성한 것입니다.


 The Desktop Files: Microsoft Desktop Optimization Pack
The Desktop Files
Microsoft Desktop Optimization Pack
Wes Miller
이 칼럼은 Microsoft Desktop Optimization Pack의 시험판 요소를 기준으로 작성되었습니다. 이 문서에 수록된 모든 정보는 변경될 수 있습니다.

몇 년 전 SA(Software Assurance) 라이선스 프로그램을 시작한 이후 Microsoft에서는 지속적으로 SA에 기능을 추가하여 시간이 지나면서 고객이 더욱 높은 가치를 누릴 수 있도록 하고 있습니다. 이러한 노력을 통해 라이선스에 포함된 Microsoft 제품의 업그레이드는 물론
조직에서 Windows, Office 및 기타 Microsoft 소프트웨어의 사용 환경을 개선하는 데 도움이 되는 제품 및 기술(예: 이러한 개념으로 제공된 최초의 소프트웨어인 Windows® PE)도 제공하게 되었습니다.
이러한 도구와 프로그램 중 대부분은 조직의 SA 적용 범위에 포함된 Windows, Office 및 기타 Microsoft 응용 프로그램의 전반적인 소유 비용을 절감할 수 있는 기능을 제공하는 데 초점을 맞추고 있습니다.
Microsoft는 2006년에 Windows 및 Windows 기반 응용 프로그램의 관리 및 복구와 관련한 소유 비용과 복잡성을 줄일 수 있는 솔루션을 개발하던 몇몇 관련 업체를 인수했습니다. 그리고 새롭게 획득한 다양한 기술을 새 제품에 적용하여 SA를 보유한 고객에게 부가 가치 솔루션으로 제공하고 있습니다. 앞으로 수년 내에 Softricity, DesktopStandard, AssetMetrix, Winternals Software 등의 업체에서 개발한 기술이 Microsoft® Desktop Optimization Pack(MDOP) 구성 요소의 형태로 제공될 예정입니다. 뿐만 아니라 Microsoft에서 자체적으로 개발한 Microsoft System Center Desktop Error Monitoring이라는 구성 요소도 MDOP에 추가될 예정입니다.
Microsoft는 MDOP를 통한 비용 절감 효과가 MDOP 구현 방식에 따라 데스크톱당 매년 100달러에서 500달러에 이를 것으로 추산하고 있습니다. MDOP에 대한 자세한 내용은 windowsvista.com/optimizeddesktop을 참조하십시오.

Microsoft Desktop Optimization Pack의 목표
간단히 말해 MDOP의 주된 목표는 새 운영 체제 릴리스 일정과는 별도로 새로운 관리 기술을 보다 신속하게 제공하는 것이라 할 수 있습니다. 향후 Microsoft는 Windows XP와 Windows Vista™의 경우와 같이 릴리스 간격이 벌어지는 일이 없도록 할 것입니다. 릴리스 간격 중간에도 주기적으로 MDOP 도구를 제공함으로써 Microsoft는 사용자의 요구에 유연하게 대처하고 기업 고객은 소프트웨어 투자의 가치를 극대화할 수 있게 됩니다.
기업에서 보다 신속하게 도구를 이용할 수 있도록 하기 위해 Microsoft는 고객이 DSI(동적 시스템 이니셔티브)와 같이 보다 동적인 인프라로 전환하도록 유도할 전략을 구상하고 있습니다. DSI에 대한 자세한 내용은 microsoft.com/business/dsi의 내용을 참조하십시오.
상위 전략에 대한 이야기는 여기까지만 하고, 이제 MDOP에 포함된 다섯 가지 기술에 대해 살펴보겠습니다.
  • SoftGrid Application Virtualization
  • Asset Inventory Service
  • Diagnostics and Recovery Toolset
  • Advanced Group Policy Management
  • System Center Desktop Error Monitoring

SoftGrid Application Virtualization
Softricity에서 개발한 SoftGrid Application Virtualization은 이름에서도 알 수 있듯이 응용 프로그램 가상화 기능을 제공합니다. 처음 SoftGrid를 분석했을 때 Windows 2000 IntelliMirror®용 응용 프로그램을 어떻게 게시해야 하는지를 잘 보여 주는 도구라는 생각이 들었습니다. 그 이유는 바로 응용 프로그램이 클라이언트에 게시되지 않고 응용 프로그램 전체가 가상화되기 때문입니다. 이렇게 응용 프로그램을 가상화하면 클라이언트 또는 터미널 서버 시스템에서 쉽게 사용할 수 있습니다. 또한 응용 프로그램을 중앙에서 관리할 수 있고 필요에 따라 회수 또는 업데이트할 수 있다는 점도 주목할 만합니다. SoftGrid 모델을 활용하면 기존의 MSI 및 변환 모델과 비교했을 때 응용 프로그램 배포에 따르는 작업 부담과 위험성을 크게 줄일 수 있습니다.
SoftGrid는 일종의 가상 이미지라고도 할 수 있습니다. Windows 및 포함된 응용 프로그램을 시스템에 배포하는 데 사용하는 디스크 이미지에 대해서는 여러분도 잘 아실 것이라 믿습니다. 본질적으로 SoftGrid는 응용 프로그램을 이미지로 만든다는 점에서 디스크 이미지와 유사합니다. 단, 전체 OS 이미지가 아니라 응용 프로그램 이미지로 패키징한다는 것이 다를 뿐입니다.
SoftGrid Application Virtualization은 응용 프로그램 가상화, 응용 프로그램 전달 및 중앙 관리 콘솔이라는 세 가지 핵심 구성 요소로 이루어져 있습니다.
응용 프로그램 가상화 자체는 Windows 파일 시스템(시스템 파일 포함), Windows 레지스트리, 글꼴, .ini 파일, COM/DCOM 개체, 서비스, 커널 개체(세마포, 뮤텍스), 명명된 개체 및 모든 구성 요소의 네임스페이스를 가상으로 표현하는 것입니다.
SoftGrid 가상화와 Windows Vista UAC의 리디렉션 방식을 혼동하지 않는 것이 중요합니다. UAC의 경우 응용 프로그램에서 레지스트리 또는 파일 시스템의 보호된 영역에 쓰거나 해당 영역을 수정하려고 하면 레지스트리와 파일 시스템의 사용자별 보기로 리디렉션됩니다. 반면 SoftGrid의 경우에는 모든 레지스트리 및 파일 시스템 구성 요소를 비롯하여 응용 프로그램을 운영 체제에 완전히 가상화한다는 개념을 바탕으로 합니다. 하지만 SoftGrid의 진정한 가치는 단순히 응용 프로그램을 정의하는 단일 blob가 아니라, 다음과 같이 구성되어 있다는 점입니다.
  • 최대 4GB의 SFT 파일. 이 파일에는 하나 이상의 응용 프로그램과 해당 종속 파일이 들어 있습니다. 단, 대상 시스템에 저장되어야 하는 Windows 종속 파일은 제외됩니다.
  • 약 2KB의 OSD 파일. 이 파일에는 응용 프로그램을 요청하고 실행하는 방법에 대한 정의가 들어 있습니다. OSD 파일은 EXE 파일의 역할을 한다고 볼 수 있습니다.
  • 약 24KB의 ICO 파일. 이 파일은 실제로 응용 프로그램을 실행하는 바로 가기입니다.
  • 약 13KB의 SPRJ 파일. 이 파일은 시퀀서(SoftGrid의 핵심)에서 기존 패키지를 게시하고 열고 업데이트하고 복구하는 데 사용됩니다.
SoftGrid Application Virtualization의 전반적인 작동 방식을 보여 주는 그림은 웹 사이트(softricity.com/products/architecture.asp)를 참조하십시오.
SoftGrid 솔루션의 가장 큰 장점은 중앙 관리 콘솔(그림 1 참조)을 통해 특정 Active Directory® 사용자 또는 사용자 그룹이 사용할 수 있는 응용 프로그램을 지정할 수 있다는 것입니다. 그리고 필요 시 산업 표준 스트리밍 프로토콜을 통해 해당 응용 프로그램을 사용자에게 신속하게 스트리밍할 수 있습니다. 응용 프로그램을 설치하면 응용 프로그램이 로컬에 설치된 것처럼 작동하고, 사용자 지정(로밍 사용자 프로필을 통한 사용자 지정 포함) 내용을 인식하고, 클라이언트가 네트워크에 연결되어 있지 않을 때도 작동합니다. 관리자는 동적으로 또는 자동(예: 설정한 시간이 경과하면 자동으로 중지)으로 사용자에 대한 응용 프로그램 제공을 중지할 수 있습니다.
그림 1 SoftGrid Management Console
그림 1 SoftGrid Management Console
가장 중요한 점은 전체 응용 프로그램을 사용 가능하도록 할 필요가 없는 응용 프로그램 배포 방식이라는 것입니다. 즉, 사용자가 선택한 응용 프로그램을 실행하는 데 필요한 부분만 다운로드됩니다. 모든 Microsoft Office 제품이 사용자에게 패키지로 제공되는 시나리오를 예로 들어 보겠습니다. 사용자가 Word만 실행한다면 Word를 실행하는 데 필요한 구성 요소만 다운로드되고 Excel®, PowerPoint® 등을 실행하는 데 필요한 구성 요소는 다운로드되지 않습니다. 그리고 사용자가 Excel 등의 다른 응용 프로그램을 실행하면 필요에 따라 관련 구성 요소가 즉시 다운로드됩니다.
ERD에 포함된 기능
  • Command prompt
  • Explorer
  • Search
  • Notepad
  • Solution Wizard
  • Administrative Tools: Autoruns, Disk Management, Event Viewer, Registry Editor, Services and Drivers, System Information
  • Networking Tools: File Sharing, Map Network Drive, TCP/IP Configuration
  • System Tools: Crash Analyzer, Disk Commander, Disk Wipe, File Restore, Hotfix Uninstall, Locksmith, System File Repair, System Restore

SoftGrid의 또 다른 구성 요소로 자동 계량 및 라이선스 확인 기능도 있습니다. 이 기능은 소프트웨어를 추가로 구입하지 않고도 소프트웨어 라이선스를 유지하는 데 도움이 됩니다.
거의 모든 응용 프로그램을 가상화할 수 있습니다. 가상화할 수 없는 주요 응용 프로그램으로는 Internet Explorer®와 기타 Windows 구성 요소(핫픽스 및 서비스 팩 포함), 바이러스 백신 소프트웨어, 장치 드라이버 등이 있습니다. SoftGrid의 작동 방식과 응용 범위에 대해 자세히 알아보려면 Softricity.com의 백서를 참조하시기 바랍니다.

Advanced Group Policy Management
DesktopStandard는 그룹 정책 구성 요소 간의 취약한 연결 상태를 보완하는 도구를 개발하면서 유명해진 업체입니다. 이전에 GPOVault로 알려진 도구(현재의 Advanced Group Policy Management)를 MDOP를 통해 제공함으로써 Microsoft는 고객에게 강력하고 경우에 따라 위험하기까지 한 GPO를 보다 안정적으로 제어되는 프로세스로 제공할 수 있게 되었습니다.
소스 제어 소프트웨어의 기본 개념을 잘 아는 사용자라면 Advanced Group Policy Management를 Active Directory 그룹 정책의 소스 제어 기능으로 생각하면 이해하기 쉬울 것입니다. 그림 2에는 Advanced Group Policy Management 콘솔의 스크린 샷이 나와 있습니다. Advanced Group Policy Management 콘솔에서 관리자는 그룹 정책 관리 콘솔과 비슷한 모양의 보고서를 사용하여 기존 정책의 수정 내용을 체크 아웃하고 정책을 변경하고 변경 내용을 다시 체크 인하고 결과를 감사합니다. 그리고 원하는 대로 정책이 설정되면 변경 내용을 커밋하여 활성화할 수 있습니다. 이 과정에서 문제가 발생하면 일반적인 문제 해결 프로세스처럼 추측에 의존할 필요 없이 변경 내용을 신속하고 안전하게 이전 버전으로 롤백할 수 있습니다. 이는 뛰어난 소스 제어 소프트웨어에서 제공되는 기능과 같습니다.
그림 2 Advanced Group Policy Management 콘솔
그림 2 Advanced Group Policy Management 콘솔
이 프로세스에서 중요하게 살펴봐야 할 또 다른 기능은 바로 항상 온라인 상태의 활성화된 시스템에서 정책을 변경해야 하는 것이 아니라 오프라인으로도 정책 변경이 가능하다는 점입니다. 따라서 변경 내용을 도메인이나 OU에 배포하기 전에 격리된 환경에서 테스트해 볼 수 있습니다.
마지막으로 Advanced Group Policy Management는 역할 기반 모델을 통해 미리 설계된 워크플로 프로세스에 따라 변경이 이루어질 수 있도록 합니다. 즉, 관리자가 편집자, 검토자, 승인자 등의 역할을 만들어 정해진 방식으로 변경이 이루어지도록 프로세스를 적용할 수 있습니다. 또한 구현 담당자는 변경 내용을 커밋할 준비가 되었다고 판단되면 강력한 변경 제어 메커니즘을 통해 적절한 승인 과정 없이는 임의로 GPO를 변경하지 못하도록 할 수 있습니다.

Asset Inventory Service
AssetMetrix 인수를 통해 Microsoft가 얻게 된 기술에 기반을 둔 Asset Inventory Service는 매우 강력한 인벤토리 및 자산 관리 솔루션입니다. MDOP의 다른 구성 요소와는 달리 AIS에는 호스팅된 웹 모델이 사용됩니다. 또한 AIS에는 리소스와 대역폭 사용량이 적고 일시적으로 또는 주기적으로 실행 가능한 에이전트가 사용되므로 관리자는 Microsoft에서 호스팅하는 매우 광범위한 400,000개 이상의 응용 프로그램 데이터베이스에서 응용 프로그램을 검색하여 클라이언트 시스템에 설치되어 있는지 확인할 수 있습니다. 그러면 AIS에서 이렇게 수집된 데이터를 바탕으로 사용자가 구매한 라이선스를 조정하여 불필요한 라이선스 구입에 따른 낭비를 줄이면서 라이선스를 유지할 수 있도록 합니다.
AIS는 방화벽 외부에서 호스팅되며 설치된 소프트웨어의 내부 시스템을 인벤토리에 보관하는 모델이기 때문에 일부 관리자의 경우 처음에는 사용을 주저할 수도 있습니다. 하지만 Microsoft는 AIS를 구성하는 응용 프로그램의 핵심 구성 요소를 다시 작성하는 것부터 시작하여 조직의 정보를 보호하기 위해 광범위한 노력을 기울이고 있습니다. 개별 컴퓨터 데이터와 조직의 데이터 간에는 연관성이 없습니다. 또한 Microsoft는 타사와 함께 데이터 전송 기술을 인증하여 고객이 AIS에 사용되는 모델을 신뢰할 수 있도록 할 것입니다.

Diagnostics and Recovery Toolset
지난 몇 달 동안 연재된 필자의 칼럼에서 저자 소개를 읽어 본 독자라면 이미 알겠지만, 필자는 Microsoft가 Winternals를 인수할 당시 그 회사에서 일하고 있었습니다. 필자는 제품 관리자로서 Winternals Administrator's Pak을 비롯하여 Winternals 제품 대부분을 관리했습니다. Winternals Administrator's Pak이 Microsoft Diagnostics and Recovery Toolset(DaRT)으로 바뀌면서, Administrator's Pak에 포함되어 있던 일부 도구가 DaRT에서는 제외되었지만 ERD Commander 제품을 구성하는 주요 구성 요소는 계속 제공됩니다.
DaRT는 시스템이 정상적으로 부팅되지 않은 경우에도 시스템 문제를 진단할 수 있는 도구 집합을 제공하도록 개발되었습니다. 또한 진단된 문제를 오프라인으로 복구할 수도 있습니다.
ERD Commander는 Windows PE를 사용하여 부팅되지 않거나 또는 정상적으로 부팅되지 않는 시스템을 부팅합니다. 또한 Windows 탐색기와 유사한 사용자 지정 사용자 인터페이스를 통해 도구 집합을 제공합니다. 이러한 도구 중에서 Crash Analyzer 및 File Restore는 온라인으로 사용할 수도 있습니다. ERD Commander를 오프라인 진단 또는 복구에 사용하지 않을 경우에는 개별 시스템에 이 두 도구를 설치하여 실행해야 합니다.
그림 3에는 ERD Commander의 DaRT 버전이 나와 있습니다. ERD Commander 구성 요소에 포함된 도구 목록은 'ERD에 포함된 기능'을 참조하십시오. 목록의 처음에 나와 있는 다섯 개 도구 중 Explorer 도구를 제외하고는 모두 일반적인 Windows 운영 체제에서 사용하는 응용 프로그램과 동일합니다. Explorer는 실행에 사용되는 시작 메뉴 응용 프로그램과 마찬가지로 Windows PE에서 실행되도록 특수한 작은 버전으로 개발되었습니다.
그림 3 ERD Commander
그림 3 ERD Commander
동일한 이름의 Sysinternals 도구에서 파생된 Autoruns는 시스템이 부팅되거나 사용자가 로그온할 때 시작되도록 설정된 모든 응용 프로그램을 확인하는 데 사용할 수 있습니다. Disk Management, Event Viewer, Services and Drivers 및 System Information은 일반 사용자 인터페이스에서 제공되는 도구로, 비슷한 이름의 Windows 도구와 유사한 기능을 제공합니다. 특히 Services and Drivers는 장치 드라이버 또는 서비스가 정상적으로 작동하지 않아서 시스템 오류가 발생한 경우 시스템을 부팅할 수 있는 매우 유용한 도구입니다. 마지막으로 오프라인 시스템의 레지스트리를 조작할 수 있도록 Windows Registry Editor가 포함되어 있습니다.
ERD Commander에서 네트워킹 작업도 수행할 수 있습니다. 시스템은 DHCP를 통해 자동으로 구성되지만 TCP/IP 구성 애플릿을 사용하면 정적 IP 주소를 설정할 수 있습니다. DHCP 또는 정적 IP 주소 지정 중 어느 것을 사용하더라도 중지된 시스템에서 네트워크 드라이브 연결 또는 파일 복사를 실행하거나 파일 공유를 사용하여 시스템을 파일 서버로 전환한 후 정상적으로 작동하는 시스템을 사용하여 오류가 발생한 시스템에서 파일을 복사할 수 있습니다.
그 밖에도 다양한 도구가 포함되어 있습니다. Crash Analyzer는 별도로 다운로드하여 설치해야 하는 Debugging Tools for Windows(무료로 제공되며 자주 업데이트됨)를 사용하여 크래시의 원인을 진단합니다. 이 도구는 시스템이 부팅되지 않는 경우 ERD Commander를 통해 오프라인으로 실행할 수도 있고, DaRT가 설치되어 있고 정상적으로 실행되는 시스템에 DMP 파일을 복사한 후 해당 시스템에서 진단할 수도 있습니다. 진단을 통해 새 서비스 또는 드라이버가 오류의 원인으로 파악된 경우 Services and Drivers 도구를 사용하여 해당 서비스 또는 드라이버를 비활성화한 후 시스템이 다시 정상적으로 작동하는지 확인할 수 있습니다.
Disk Commander를 사용하면 삭제된 여러 파일 또는 디렉터리뿐만 아니라 실수로 삭제되었거나 손상된 파티션까지 복구할 수 있습니다. 다른 한편으로 Disk Wipe 도구를 사용하면 DoD 호환 디스크 또는 볼륨 삭제 작업을 수행할 수 있습니다. File Restore는 실수로 삭제한 단일 파일을 온라인 또는 오프라인으로 복구하는 데 사용할 수 있습니다. 이러한 도구 중 어떤 것을 사용하든 복구 가능 여부는 파일 형식과 삭제 후 경과된 시간 및 실행한 디스크 작업에 따라 결정됩니다.
Windows 핫픽스 또는 서비스 팩으로 인해 시스템이 정상적으로 부팅되지 않는 경우에는 Hotfix Uninstall을 사용하여 하나 이상의 핫픽스 또는 서비스 팩을 선택적으로 제거할 수 있습니다. Windows에서는 응용 프로그램의 오프라인 제거 기능이 완벽하게 지원되지 않으므로 이 프로세스를 완료하려면 시스템을 다시 부팅해야 하며 대개의 경우 시스템이 자동으로 다시 부팅됩니다.
Locksmith는 Winternals 시절의 ERD Commander 도구 집합에 포함된 도구 중 가장 많이 사용되었습니다. 이 도구를 사용하면 로컬 사용자의 암호를 다시 설정할 수 있습니다. 이 도구는 도메인 컨트롤러에서 사용할 수 없고 도메인 사용자의 암호를 다시 설정할 수 없습니다. 일반적으로 이 도구는 로컬 관리자의 암호를 잊거나 해당 사용자가 조직을 떠난 경우 암호를 다시 설정하는 데 사용됩니다. System File Repair는 보호된 모든 시스템 파일을 검사하여 손상된 파일이 있는지 확인하고 필요한 경우 파일을 바꿉니다. System Restore는 이름에서 알 수 있듯이 Windows XP 시스템에서 임의의 Windows 시스템 복원 지점으로 롤백하거나 포워드하는 데 사용할 수 있습니다. 기존 복원 지점이 있는 Windows XP에서는 이 기능을 반드시 사용해야 합니다. 필자도 이 고유한 기능의 덕을 톡톡히 본 사용자 중 한 명입니다.
ERD Commander 및 DaRT에 포함된 도구는 다소 두서 없이 구성된 듯하지만, 오랜 기간 동안 Winternals에서 개발한 강력한 유틸리티를 결합한 것입니다. 독자 여러분들도 이러한 도구의 진가를 확인하고 복구 및 문제 해결 작업에 유용하게 활용할 수 있으리라 확신합니다.

System Center Desktop Error Monitoring
System Center Desktop Error Monitoring(DEM)을 사용하여 조직에서는 Windows 크래시와 응용 프로그램 중단 문제를 빠르고 간편하게 중앙 집중식으로 관리 및 진단할 수 있습니다. DEM에서는 크래시 및 작동 중단 보고서를 Microsoft에 보내는 대신에 그룹 정책과 기본 Windows 오류 보고 서비스를 사용하여 조직에서 진단용으로 지정한 서버에 보고서를 보냅니다. 따라서 별도의 소프트웨어 에이전트가 필요하지 않습니다. 모든 DEM 서버 데이터는 SQL Server 데이터베이스에 저장되므로 수집된 데이터를 간단히 쿼리하여 사내 응용 프로그램과 보고에 사용할 수 있습니다. 따라서 조직 내에서 문제를 사전에 진단할 수 있습니다. 이렇게 진단된 정보는 문제를 보고하고, 자주 발생하는 크래시 및 작동 중지 원인을 파악하고, 시스템 가동 중단을 최소화하거나 예방할 수 있도록 Windows 및 응용 프로그램 패치의 우선 순위를 지정하는 데 사용할 수 있습니다.
뿐만 아니라 Microsoft에 결과를 업로드하고 Microsoft 응용 프로그램과 타사 응용 프로그램에 대한 최신 문제 해결 데이터를 자동으로 다운로드하도록 DEM 서버를 구성할 수도 있습니다. 이러한 추가 데이터는 크래시 또는 작동 중지가 발생할 경우에 클라이언트로부터 수집됩니다.

MDOP 라이선스
고객이 MDOP의 라이선스를 취득하려면 먼저 Microsoft SA 계약이 체결되어 있어야 합니다. SA 계약을 보유한 고객은 데스크톱당 7달러에서 10달러의 가격으로 라이선스를 취득할 수 있습니다. 또한 대량 구매 할인과 교육용 특별 가격도 이용할 수 있습니다.
MDOP는 SA 계약과 별도로는 구매할 수 없습니다. 단, 터미널 서버(softricity.com/solutions/sbc.asp 참조) 또는 SMS(softricity.com/products/softgrid-sms.asp 참조)에 SoftGrid 기술을 사용하려는 고객은 MDOP를 별도로 구매할 수 있습니다. AssetMetrix 기술은 향후 SMS 및 System Center Configuration Manager 릴리스에 추가될 예정입니다.

가용성 및 업데이트
MDOP의 초기 구성 요소는 현재 사용할 수 있습니다. 향후 다음 구성 요소가 제공될 예정입니다.
  • SoftGrid는 2007년 초반부터 Microsoft에서 제공하고 있습니다.
  • Microsoft DaRT는 2007년 5월부터 제공되고 있습니다.
  • GPOVault 기술은 2007년 7월부터 제공될 예정입니다.
  • Desktop Error Monitoring은 2007년 7월부터 MDOP에 추가될 예정입니다.
  • AssetMetrix 기술은 2007년 7월에 베타 버전으로 제공되고 8월에 릴리스될 예정입니다.
  • DaRT 구성 요소의 업데이트는 2007년 후반에 Windows Vista의 호환성 업데이트의 일환으로 제공될 예정입니다.
앞으로 매년 두 차례씩 향상된 기능, 업그레이드 및 새로운 기능이 포함된 MDOP 버전을 릴리스할 계획입니다.

MDOP의 방향
앞서 설명했듯이 AssetMetrix 기술의 핵심 구성 요소는 System Center Configuration Manager의 다음 버전에 통합될 예정입니다. 또한 향후 Microsoft는 MDOP 기능을 더욱 개선하여 그 중 일부를 점진적으로 기본 Microsoft 배포, 관리 및 구성 기술에 반영할 것입니다. 이에 따라 Microsoft에서 개발하거나 다른 업체로부터 인수한 새로운 기술도 MDOP의 향후 버전에 추가될 수 있습니다. 한마디로 MDOP는 최신 관리 및 구성 기술을 통합하여 끊임없이 개선되는 패키지라고 할 수 있습니다.

Wes Miller는 텍사스 오스틴에 있는 Pluck의 개발 관리자입니다. 이전에는 오스틴에 있는 Winternals Software에서 근무했으며 Microsoft에서 프로그램 관리자 및 Windows 제품 관리자로도 근무한 경력이 있습니다. 문의 사항이 있으면 technet@getwired.com을 통해 연락하십시오.
이 칼럼을 작성하는 데 도움을 준 Microsoft Desktop Optimization Pack 제품 관리자인 Chad Jones와 Gavriella Schuster에게 감사의 뜻을 전합니다.


 Windows Confidential : 안전 모드의 강력한 복구 성능
Windows Confidential
안전 모드의 강력한 복구 성능
Raymond Chen

"이런, 모두 엉망이 되었어요. 제발 복구해 주세요."라는 모드로도 알려져 있는 Windows 안전 모드는 단순히 드라이버를 비활성화하는 것 이상의 목적으로 Windows® 95에서 처음 개발되었습니다. 또한 안전 모드는 자동으로 복구될 수 있는 구성 요소를 복구한다는 의미도 갖고 있습니다.
예를 들어 아이콘이 화면에 표시되지 않는 상태가 나타날 수도 있으므로 안전 모드로 컴퓨터를 시작하면 Windows 탐색기는 바탕 화면의 모든 아이콘 위치를 확인하여 아이콘이 모두 표시되도록 합니다.
무슨 얘기인지 볼까요? 먼저 바탕 화면에 아이콘 두 개를 왼쪽 모서리 및 오른쪽 모서리에 각각 놓습니다. 그런 다음 Ctrl 키를 누른 채로 두 개의 아이콘을 각각 클릭하여 모두 선택한 상태에서 왼쪽 아이콘을 화면의 오른쪽으로 끌어 놓습니다. 이렇게 하면 오른쪽에 있던 다른 한 아이콘이 왼쪽 아이콘과 상대적으로 동일한 위치를 유지하며 함께 이동합니다. 그 결과, 오른쪽에 있던 아이콘은 화면을 벗어나게 됩니다.
안전 모드를 사용하면 Windows의 문제를 해결할 수 있습니다.
안전 모드를 사용하면 Windows의 문제를 해결할 수 있습니다.
Windows 탐색기가 안전 모드에서 아이콘 위치를 복구하지 못한 경우 문제 해결 지침은 다음과 같이 도움이 되기보다는 오히려 혼동을 줄 수 있습니다.
  1. 컴퓨터를 안전 모드로 시작합니다. (좋습니다.)
  2. 내 컴퓨터 아이콘을 두 번 클릭합니다. (음, 저는 내 컴퓨터 아이콘이 표시되지 않네요.)
  3. ...
이런, 내 컴퓨터 아이콘이 화면에 표시되지 않거나 사용할 수 없습니다. 문제 해결의 두 번째 단계를 수행할 수도 없네요.
몇몇 사용자는 "아이콘을 자동으로 복구하는 방법을 사용하지 말았어야 했어요. 사용자가 이러한 문제로 기술 지원을 요청하는 경우 기술 지원 엔지니어는 사용자에게 바탕 화면에서 마우스 오른쪽 단추를 클릭한 다음 '아이콘 위치 재설정' 옵션을 선택하도록 안내하기만 하면 됩니다. 그럼 모두 해결됩니다. 안전 모드에서 아이콘이 뒤섞이지도 않지요."라고 불만을 제기하기도 했습니다.
무엇보다도 여러분이 "사용자가 이 문제로 기술 지원에 문의하는 경우"라고 말할 때는 이미 이 게임에서 진 것입니다. 사용자가 기술 지원을 요청해야 한다면 여러분이 진 것이지요.
더 나아가 이러한 제안은 안전 모드의 개념을 간과하는 것이기도 합니다. 사용자는 컴퓨터가 올바르게 작동하지 않는 경우 그 다음에 어떻게 해야 하는지 알지 못하더라도 일단 안전 모드로 부팅을 합니다. 사용자가 실제로 하는 일은 어떻게 되는지 그저 지켜보는 것입니다. "무엇인가 잘못되었군. 안전 모드로 부팅해 봐야지." 우리는 Windows 95의 안전 모드에서 다양한 유형의 자동 복구를 구현함으로써 이 개념을 활용했습니다. 결과는 꽤 괜찮았습니다.
게다가 전화로 문의하는 사용자에게 여러분이 "안전 모드로 부팅하세요. 문제가 해결될 것입니다."라고 말한다면 사용자는 "음. 아주 간단하네. 왜 이걸 몰랐을까?"라고 생각하게 될 것입니다.
하지만 사용자에게 "안전 모드로 부팅한 후 여기를 마우스 오른쪽 단추로 클릭하고 이 메뉴 옵션을 선택한 다음 이 상자를 클릭하세요."라고 장황하게 설명한다면 사용자가 안내를 따라 문제를 해결할 수 있겠지만, 컴퓨터 사용에 편리함을 느끼게 하는 데는 아무런 도움이 되지 않을 것입니다. 사용자는 자신의 능력에 고무되는 대신 기가 죽고 위축되며 무력감을 느끼게 될 것입니다. "내가 해결할 수 있는 방법은 없군. 컴퓨터는 정말 사용하기 어려워."라고 말하면서요.

Raymond Chen은 The Old New Thing 웹 사이트와 동명의 저서(Addison-Wesley, 2007)에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있습니다. 그는 일촉즉발의 긴박한 상황에서 문제를 해결하는 것을 즐깁니다.