September 2008 September 2008
ISA Server: ISA Server 2006 보안을 위한 가이드
ISA Server 2006을 사용하여 환경을 보호하는 조직은 많지만 ISA Server 자체를 보호하기 위한 중요한 단계를 수행하는 조직은 소수입니다. 여기에서는 보안 구성 마법사와 관리자 역할을 사용하여 노출 영역을 제한하고 ISA Server 2006 구현을 보호하는 방법에 대한 지침을 제공합니다. Alan Maddison
ISA Server: ISA Server 2006으로 TS 게이트웨이 보안 향상
Windows Server 2008에서는 새로운 TS 게이트웨이 기능을 사용하여 VPN을 사용하지 않고도 어디에서든 자신의 데스크톱에 액세스할 수 있습니다. ISA Server 2006을 통해 TS 게이트웨이를 게시하는 방법과 클라이언트 상태 적용을 포함하도록 ISA Server 2006 게시 시나리오를 확장하는 방법을 알아보십시오. Dr. Thomas W. Shinder, Yuri Diogenes
IIS 7.0: IIS 7.0의 가장 중요한 10가지 성능 향상
최신 IIS 릴리스는 일반적인 배포와 관리 시나리오에 대한 개선된 지원을 포함한 확장 가능한 모듈식 플랫폼을 도입하여 상당한 수준의 성능 향상을 제공합니다. 여기에서는 이러한 향상을 제공하는 IIS 7.0의 10가지 핵심 영역을 살펴보겠습니다. Mike Volodarsky
Mobility: 기간 업무(LOB) 응용 프로그램에 모바일 기능 구현
최근에는 사무실에서 사용하는 기간 업무(LOB) 응용 프로그램(CRM, ERP 등)을 현장에서 모바일 장치를 통해 액세스해야 하는 모바일 근로자들이 많습니다. Windows Mobile과 Mobile Device Manager을 통해 중요한 기간 업무 응용 프로그램에 필요한 다양한 모바일 기능을 배포하는 방법을 알아보십시오. Matt Fontaine
Security: 공유 계정 암호 관리의 이해
공유 및 권한이 부여된 계정 암호를 흔히 볼 수 있지만 이러한 공유 암호를 올바르게 관리하지 못하는 조직이 많습니다. 이러한 관리 소홀은 심각한 보안 문제로 이어집니다. 공유 및 권한이 부여된 계정과 관련된 위험성을 확인하고 더욱 안전하게 암호를 관리하기 위한 좋은 방법을 확인해 보겠습니다. Chris Stoneff
Columns
From the Editor: 기본으로 돌아가서: | Letters: 독자의 목소리: | Toolbox: IT 전문가를 위한 신제품:
Exchange Queue & A: 디스크 파티션 할당, SCR 계획 및 기타 정보: 2008년 9월호 Exchange Queue & A에서는 필요한 글로벌 카탈로그 서버의 수를 계산하는 방법, 서버의 사이트 구성원을 변경하는 방법 및 기타 정보에 대한 질문에 답해 보겠습니다.Henrik Walther | Utility Spotlight: Windows 메모리 진단: 이 무료 유틸리티를 사용하여 Windows 사용 중 발생하는 문제가 메모리 결함에 의한 것인지 여부를 확인하는 방법을 알아봅니다.Lance Whitney | Inside SharePoint: SharePoint 디렉터리 통합: Pav Cherny와 함께 SharePoint의 기본 제공 디렉터리 관리 서비스에 어떤 제한 사항이 있는지 살펴보고 이 구성 요소를 대체하여 SharePoint 받는 사람 정보를 다른 디렉터리 솔루션과 동기화하는 방법을 알아보겠습니다.Pav Cherny
Windows PowerShell: 문자열 이론: Windows PowerShell은 개체 지향적 특성에도 불구하고 복잡한 문자열의 구문 분석도 가능합니다. Don Jones가 Windows PowerShell에서 Select-String을 사용하여 이 작업을 수행하는 방법을 설명합니다.Don Jones | Hey, Scripting Guy!: 온라인 토스터: 연결이 끊긴 레코드 집합(가상 데이터베이스 테이블)을 사용하여 데이터 정렬과 관련한 VBScript의 한계를 극복하고 대량의 데이터 작업을 수행하는 방법을 알아봅니다.Microsoft Scripting Guys | The Desktop Files: WDS의 고급 기능: Windows 배포 서비스에 대한 Wes Miller의 세 번째 칼럼에서는 성능, 확장성, 로깅 및 명령줄 자동화를 개선하는 기능에 대해 알아봅니다.Wes Miller
Security Watch: 암호와 신용 카드 - 제3부: 총 3부로 구성된 시리즈의 두 번째 편에서 Jesper Johansson은 소프트웨어 공급업체, 보안 제품 및 마케팅 활동이 진정한 보안 활동을 어떻게 저해하는지 조명하고, 그러한 관행이 어떻게 기술 보안 생태계의 붕괴를 초래할 수 있는가도 경고합니다.Jesper M. Johansson | Field Notes: 내부로부터의 혁신: Romi Mahajan이 비교 우위를 유지하기 위한 핵심으로 인간의 창의성과 인적 자본 모두를 강조하는 "내부로부터의 혁신"이라는 자신의 이론을 설명합니다.Romi Mahajan | Windows Confidential: Windows 95 뒷이야기: Raymond Chen이 한 조각의 진단용 코드가 Windows 95 빌드를 지체시킨 사건에 대해 설명합니다.Raymond Chen


ISA Server 2006 보안을 위한 가이드
Alan Maddison
한 눈에 보기:
  • 서버 보안을 위한 최선의 방법
  • 보안 구성 마법사 설정
  • 보안 구성 마법사 따라하기
  • 관리자 역할 할당

목차
서버 보호
보안 구성 마법사 설정
SCW 실행
관리자 역할
많은 IT 전문가들이 자신들의 기술 자산을 보호하기 위해 ISA Server 2006(Internet Security and Acceleration Server 2006)을 사용하면서도 ISA Server 자체를 보호하기 위한 몇 가지 추가 조치를 취하는 데는 인색한 것 같습니다.
최근에 ISA Server 2006을 설치했다면 설치를 완료한 다음 수행할 작업에 대한 알림을 기억할 것입니다. 아쉽게도 IT 전문가 중 많은 수가 이러한 중요한 단계를 수행하지 않거나 시간 여유가 없어서 이러한 목록에 있는 작업이 아예 수행되지 않는 경우가 많습니다.
그러나 현재의 끊임없이 변화하는 보안 환경에서는 ISA Server를 올바르게 보호하지 않는 이러한 실수를 더 이상 용납할 수 없게 되었습니다. 다행스럽게도 ISA Server를 보호하는 데 사용되는 도구가 크게 개선되었습니다. 이제는 더 이상 ISA Server 2004 이전 버전에 있던 여러 보안 강화 마법사를 사용할 필요가 없으며 Windows Server® 2003과 함께 제공되는 SCW(보안 구성 마법사)와 같은 잘 정의된 단계와 도구를 사용할 수 있습니다.
이 기사에서는 서버를 보호하기 위한 일반적인 최선의 방법을 간단하게 다시 살펴보는 기회를 마련했습니다. 보안 구성 마법사를 사용하여 ISA Server의 노출 영역을 줄이고 관리자 역할을 사용하여 ISA Server에 대한 액세스를 제한하여 ISA Server 자체의 보안을 강화하기 위한 단계별 방법을 살펴보겠습니다.

서버 보호
서버가 데이터 센터에 있든지 또는 사무실 바로 옆에 있든지 관계없이 서버를 보호하기 위한 다양한 요소와 최선의 방법이 있습니다. 이러한 최선의 방법과 여러분의 조직에 맞게 이러한 요구 사항을 구현하는 방법을 이해하는 것은 관리자의 책임입니다. 최근 보안에 대한 중요성이 더욱 강조됨에 따라 이러한 핵심 요구 사항을 구성하는 작업에 대해서는 상당히 익숙해졌습니다. 따라서 이러한 부분에 대해 장황하게 설명하기보다는 간단한 개요만 살펴보겠습니다.
여러분의 환경을 보호하는 첫 번째 단계는 서버를 물리적으로 보호하는 것입니다. 실질적으로 이것은 서버에 대한 물리적인 액세스를 제한해야 한다는 의미입니다. 작은 환경에서는 서버실의 문을 잠그고 출입하는 사용자의 수를 최소한으로 유지하는 것이 이에 해당합니다. 이보다 큰 환경에서도 기본적인 요구 사항은 거의 동일하지만 구현에 있어서는 더 정교한 방법이 필요합니다. 예를 들어 전자 모니터링을 사용하는 회사가 많습니다. 전자 모니터링을 사용하면 서버 위치에 대한 접근을 감사하고 업무 책임에 따라 개별 랙이나 데이터 보관소에 대한 액세스를 제한할 수도 있습니다.
ISA Server나 ISA 구성 저장소 서버의 도난이나 물리적인 손상을 처리할 때는 고려해야 할 몇 가지 고유한 요소가 있습니다. 도난당한 서버에서 입수한 정보로 여러분의 환경에 있는 모든 ISA Server와 트래픽(암호화된 트래픽 포함)을 손상시키는 것이 가능할 수 있습니다.
서버가 손상되었거나 도난된 것으로 의심되는 상황에서는 먼저 서버가 현장에 있는 경우 영향을 받는 서버를 즉시 제거하고 증거를 확보하기 위한 표준 절차를 수행해야 합니다. 이러한 단계를 수행한 다음에는 모든 자격 증명 정보를 변경하는 프로세스를 시작해야 합니다. 서버에 설치된 모든 인증서를 해지하고 미리 공유한 키와 공유 암호를 모두 수정해야 합니다. 복제 구성 저장소 서버를 유지하는 경우에는 손상된 서버와 관련된 모든 데이터를 제거해야 합니다.
서버를 물리적으로 보호한 후의 다음 단계는 가상화 계층, OS 및 응용 프로그램을 포함하여 모든 소프트웨어를 패치할 수 있는 구조적인 방법을 마련하는 것입니다. 패치, 업그레이드 및 핫픽스를 정기적으로 검토하고 적용해야 합니다. 중요한 것은 프로덕션 시스템에 적용하기 전에 이러한 업데이트를 테스트해야 한다는 것입니다. 응용 프로그램이나 데이터 무결성을 손상시키는 문제를 일으킨다면 패치는 하지 않는 것이 나을 것입니다.
데이터 무결성이 손상된 경우에는 백업을 사용해야 합니다. 여기에는 인프라를 보호하기 위한 다른 핵심 요소가 있습니다. 필요할 때 신속하고 완벽하게 데이터를 복원하지 못하면 가동 중지 시간이 작업에 심각한 영향을 주어 공격 피해가 증가합니다.
고려할 다른 두 요소로 모니터링과 감사가 있습니다. 응용 프로그램과 시스템 모니터링을 중요한 부분으로 다루어야 바람직한 보안 계획을 수립할 수 있습니다. 로그, 특히 보안 관련 로그를 조사하는 데 시간을 충분하게 투자하지 않으면 피해가 발생하기 전에 침입 시도를 발견할 수 있는 확률이 떨어집니다.
감사 역시 비슷하게 중요합니다. 형식을 갖추고 감사를 실행하는 조직이 많으며 특히 대규모 환경에서는 법률에 의해 요구되는 경우도 많습니다. 노력이 충분한 효과를 거두기 위해서는 어떤 환경에서든지 사용자의 자산을 보호하기 위한 제어와 방법을 정기적으로 검토하는 것이 중요합니다.
참고로 ISA Server 2006은 Windows Server® 2003에서 실행되므로 Windows Server 2003 보안 가이드를 검토하고 필요한 권장 사항을 구현하는 것도 중요합니다. Windows Server 2003 보안 가이드는 microsoft.com/technet/security/prodtech/windowsserver2003/w2003hg/sgch00.mspx에서 볼 수 있습니다.
Microsoft는 현재 기본 보안 정책 템플릿을 구현하도록 권장하고 있지만 이를 위해서는 인터넷 프로토콜 보안(IPsec) 필터를 구현하고 있지 않아야 합니다.

보안 구성 마법사 설정
그렇다면 ISA Server를 더 안전하게 하려면 어떻게 해야 할까요? ISA를 보호하기 위한 기본 도구는 SCW이며 이를 사용하여 노출 영역을 줄일 수 있습니다. SCW는 서버의 서비스, 네트워크 보안, 레지스트리 및 감사 정책을 대상으로 보안 정책을 만들고 필요한 서비스와 기능만 포함하도록 시스템을 구성합니다. 중요한 것은 사용하려는 ISA Server 서비스만 구성해야 한다는 것입니다. 예를 들어 웹 프록시 서비스는 기본적으로 설정되어 있지만 사용할 계획이 없다면 이 기능을 해제해야 합니다. 따라서 SCW에서 제공하는 구성 옵션에 주의를 기울여야 합니다.
SCW는 Windows Server 2003에서 기본적으로 설치되지 않습니다. 따라서 첫 번째 단계는 프로그램 추가/제거 제어판에서 Windows® 구성 요소 추가/제거 애플릿을 사용하여 SCW를 설치하는 것입니다. 참고로 Windows Server 2008에서는 SCW가 기본적으로 설치됩니다. Windows 구성 요소 화면이 로드되면 아래로 스크롤하고 SCW에 해당하는 확인란을 선택합니다.
설치가 완료되면 관리 도구에서 SCW를 사용할 수 있습니다. 마법사를 사용하기 전에 ISA Server 2006용 업데이트(go.microsoft.com/fwlink/?LinkId=122532)를 다운로드하여 SCW를 업데이트해야 합니다. 이 업데이트는 ISA Server 2006 Standard Edition, ISA Server 2006 Enterprise Edition, 그리고 ISA Server 구성 저장소 서버용 역할을 추가합니다.
업데이트를 다운로드한 다음에는 패키지를 실행하고 파일 압축을 해제해야 합니다. 파일 압축을 해제한 다음에는 isa.xml과 isaloc.xml이라는 .xml 파일 두 개를 SCW의 kbs 폴더로 복사합니다. Windows Server 기본 설치의 경우 이 폴더는 c:\windows\security\msscw\kbs입니다.
파일을 복사할 때 같은 이름의 기존 파일을 덮어쓸 것인지 묻는 메시지가 표시됩니다. 이 두 파일은 ISA Server 2004용이며 덮어쓰기 전에 파일을 백업하는 것이 좋습니다. 마지막 단계는 isascwhlp.dll 파일을 bin 폴더로 복사하는 것이며 이 폴더는 일반적으로 c:\windows\security\msscw\bin에 있습니다. SCW에 ISA 역할을 추가하면 설치를 시작할 준비가 됩니다.
Microsoft는 일반적으로 ISA Server 구성을 완료한 다음 SCW를 실행하도록 권장하고 있습니다. Enterprise Edition을 실행하는 경우 여기에는 모든 배열 및 모든 배열 구성원의 구성도 포함됩니다.

SCW 실행
첫 번째 단계는 관리 도구에서 SCW를 시작하는 것입니다. SCW 프로세스를 완료하려면 관리 권한이 필요합니다.
그림 1은 마법사의 첫 번째 화면입니다. 이 화면에 표시되는 텍스트에서 "서버에서 수신하는 인바운드 포트를 검색합니다." 부분을 보면 이 프로세스를 시작하기 전에 ISA Server와 배열을 완전하게 구성하는 것이 중요한 이유를 알 수 있습니다.
그림 1 보안 구성 마법사 시작 (더 크게 보려면 이미지를 클릭하십시오.)
환경을 완전히 구성하지 않은 경우에는 ISA 구성을 완료한 후에 SCW 구성을 수정해야 하는 경우가 많습니다. 그림 2의 다음 화면에서는 어떤 작업을 수행할 것인지 선택할 수 있습니다. 새 보안 정책 만들기 옵션을 선택합니다.
그림 2 새 보안 정책 만들기 (더 크게 보려면 이미지를 클릭하십시오.)
다음은 정책의 기준으로 사용할 서버를 선택하라는 메시지가 표시됩니다. 여기에서는 새 정책을 만드는 것이므로 기본 선택은 SCW를 실행하는 컴퓨터를 사용하는 것입니다. 그러나 이 동작은 이전 화면에서 수행하도록 선택한 작업에 따라 달라집니다. 기본적으로는 기준으로 사용하려는 서버에 SCW를 설치하는 것이 최선의 방법으로서 권장됩니다. 대상 서버에 SCW가 설치되지 않으면 정책을 완료하는 데 사용되는 정보가 누락됩니다. 따라서 작업을 수월하게 하려면 기준으로 사용하려는 서버에서 SCW를 설치하고 실행하십시오.
다음을 누르면 SCW는 사용자의 ISA Server 분석을 시작합니다. 이 분석에는 서버에 설치된 역할, 서버에 설치될 가능성이 높은 역할, 설치된 서비스, 그리고 기본적인 네트워킹 정보 확인이 포함됩니다. 처리가 완료되면 구성 데이터베이스 보기를 선택하여 데이터베이스를 볼 수 있습니다. 구성 데이터베이스에는 모든 지원되는 서버 역할, 클라이언트 기능 및 포트를 포함하여 많은 정보가 포함됩니다.
그런 다음 SCW는 역할 단위 서비스 구성의 단계별 안내를 시작합니다. 다음을 눌러 다음 화면으로 이동하면 그림 3과 같이 서버 역할을 선택할 수 있습니다. SCW가 수행하는 초기 검사는 신뢰할 수 있으며 올바른 서버 역할이 식별되어 있음을 알 수 있을 것입니다. 그러나 충분히 확인하고 불필요한 역할을 모두 제거하는 것이 매우 중요합니다. 그리고 서버가 여러 역할을 수행하는 경우에는 해당하는 역할이 모두 선택되어 있는지 확인합니다.
그림 3 서버 역할 지정 (더 크게 보려면 이미지를 클릭하십시오.)
ISA Server 2006 Enterprise Edition을 실행하는 경우에는 구성 저장소 서버에 대해서도 고려해야 합니다. ISA Server로 작동하는 서버에 구성 저장소 서버를 설치한 경우 구성 저장소 서버 역할도 선택해야 합니다. 이것은 권장되는 최선의 방법에는 위배되지만 이러한 사례는 자주 볼 수 있습니다. 실제로는 ISA Server 2006 역할만 있는 서버의 두 역할을 호스트하는 서버의 기준 검사를 사용해서는 안 됩니다.
다음은 서버의 클라이언트 기능을 선택하라는 메시지가 표시됩니다. 다른 말로 하면 서버에서 요구되는 서비스를 지정해야 합니다. 예를 들어 거의 모든 서버에 DNS 클라이언트가 필요하며 서버가 도메인의 구성원인 경우 도메인 구성원 기능이 필요합니다.
여기까지 수행하면 관리 및 기타 옵션 화면이 표시됩니다. 여기에서는 서비스를 사용하거나 네크워크 연결에 의존하는 응용 프로그램, 관리 및 운영 체제 옵션을 지정합니다. 이 시점까지 선택되지 않는 서비스는 해제됩니다. 선택하고 다음을 누른 후에는 허용하려는 추가 서비스를 선택할 수 있는 옵션이 제공됩니다.
다음은 지정되지 않은 서비스가 처리되는 방법을 지정하는 단계입니다. 여기에서는 기본 데이터베이스에 포함되지 않거나 기준 서버에 설치되지 않은 서비스가 정책을 적용할 때 발견된 경우 어떻게 처리할지 정의합니다. 일반적으로는 최선의 방법에 따라 지정되지 않은 서비스를 해제하여 예상하지 못한 공격 방향을 제한해야 합니다. 아쉽게도 이 옵션은 사용자의 서버가 서로 상당히 다른 경우에는 좋지 않은 결과를 초래합니다. 향후에 응용 프로그램이나 네트워크 서비스를 추가할 때도 이 설정에 대해 기억해야 합니다.
그림 4에 나와 있는 마법사의 다음 섹션에서는 SCW에 의해 수정된 서비스를 검토할 수 있습니다. 이 비교 화면에서는 현재 상태와 정책을 적용한 후의 수정된 서비스 상태를 비교하여 보여 줍니다.
그림 4 서비스 변경 내용 검토 및 확인 (더 크게 보려면 이미지를 클릭하십시오.)
변경될 서비스를 확인한 다음에는 네트워크 보안 섹션으로 진행합니다. 이곳은 SCW에서 사용자가 Windows 방화벽과 IPsec 설정을 수정할 수 있도록 해 주는 위치입니다. 그러나 여기에서는 ISA Server 2006을 구성하는 것이므로 그림 5에 나와 있는 것처럼 이 섹션을 건너 뛰어야 합니다.
그림 5 네트워크 보안 설정 건너뛰기 (더 크게 보려면 이미지를 클릭하십시오.)
마법사는 이제 네트워크 인증 방법과 보안에 초점을 맞추는 레지스트리 설정 구성으로 이동합니다. 이 섹션의 첫 번째 화면은 서버 메시지 블록(SMB) 서명과 연관되어 있습니다. SMB 프로토콜은 핵심 Microsoft 네트워킹 프로토콜이며 서명된 통신에 이러한 설정을 사용하여 메시지 가로채기(man-in-the-middle) 공격 위험을 완화할 수 있습니다.
그림 6에 나와 있는 기본 설정은 ISA Server SMB 통신에 대한 높은 수준의 보안을 제공합니다. 그러나 모든 통신을 서명하는 데 따르는 영향을 고려해야 합니다. 여유 CPU 사이클이 없는 경우 두 번째 옵션은 해제해야 합니다. 또한 이 정책이 적용될 모든 서버에 대해서도 생각해야 합니다. 서버의 워크로드가 다양한 경우에는 이 옵션을 선택할지에 대한 지침으로 CPU 사용률이 가장 높은 서버를 사용해야 합니다.
그림 6 서명된 통신이 필요한지 여부 지정 (더 크게 보려면 이미지를 클릭하십시오.)
다음 화면 집합에서는 ISA Server가 사용할 LMCompatibility 수준을 처리합니다. 이러한 화면 중 첫 번째 화면에서는 세 가지 선택을 제공합니다. Windows 95나 Windows 98과 같은 레거시 Windows 클라이언트가 있거나 액세스 제어에 로컬 계정을 사용하는 경우가 아니라면 도메인 계정이 선택된 기본 선택을 유지해야 합니다.
LMCompatibility 수준을 다루는 두 번째 화면에서는 도메인 컨트롤러에 대한 정보를 제공합니다. Windows NT® 4.0 도메인이 없다면 기본 선택(Windows NT 4.0 서비스 팩 6a 이상 OS)을 그대로 사용할 수 있습니다. 이 대화 상자에서는 또한 시계가 선택한 서버의 시계 옵션과 동기화되도록 선택해야 합니다. 다음을 선택하면 그림 7과 같이 인바운드 LAN Manager(LM) 통신을 위한 몇 가지 추가 구성 옵션이 제공됩니다.
그림 7 인바운드 인증 방법 지정 (더 크게 보려면 이미지를 클릭하십시오.)
LMCompatibility 수준과 연관된 세 번째 화면에서는 Windows NT LAN Manager(NTLM) 버전 2가 필요한지 여부와 LM 해시가 저장될지 여부를 결정합니다. 사용자의 환경이 이 구성을 지원하는 경우에는 이 두 옵션을 해제하여 보안을 크게 개선할 수 있으므로 이 두 옵션을 해제해야 합니다. 다음에는 레지스트리 설정 요약이 제공됩니다. 각 항목을 검토하고 정책 설정이 올바른지 확인합니다.
다음은 마법사의 마지막 섹션인 감사로 이동합니다. 이 섹션의 구성 옵션에 대한 한 가지 중요한 사실은 옵션을 롤백할 수 없다는 것입니다. 그러나 감사는 시스템의 기능에는 영향을 주지 않으므로 이 섹션을 건너뛰지 않도록 해야 합니다.
기본 선택인 "성공 작업 감사"는 로그온 실패에 대한 이벤트 로그 항목은 제공하지 않습니다. 그러나 로그온 실패에 대한 정보는 침입 시도에 대한 매우 중요한 단서를 제공하므로 "성공 및 실패 작업 감사"를 선택하는 것이 일반적인 최선의 방법입니다.
이제는 감사 구성을 검토하고 다음을 두 번 눌러 보안 정책을 저장할 수 있습니다. 그림 8에 나와 있는 것처럼 이 화면에 필요한 것은 파일 이름 하나이지만 간단한 설명을 제공할 수도 있습니다. 이 설명은 여러 다른 관리자가 보안 책임을 공유하는 대규모 환경에서 유용하게 사용될 수 있습니다.
그림 8 보안 정책에 대한 이름 및 설명 제공 (더 크게 보려면 이미지를 클릭하십시오.)
파일을 저장한 다음에는 정책을 즉시 적용하거나 나중에 적용하는 옵션이 제공됩니다. 정책을 나중에 적용하도록 선택하면 프로세스가 완료됩니다. 정책 구성에 문제가 있는 것을 발견하면 감사 설정을 제외하고 정책을 롤백할 수 있습니다.

관리자 역할
ISA Server의 노출 영역을 줄이는 것은 외부 원본으로부터의 위반 가능성을 줄이기 위한 핵심적인 단계입니다. 그러나 ISA Server 내에서 관리자 역할 할당을 검토하여 내부 원본으로부터의 손상 가능성을 제한하는 것 역시 중요합니다. 그림 9와 10에는 관리자 역할 및 연관된 공통 작업의 목록 일부가 나와 있습니다.
그림 9 Standard Edition과 연관된 역할 및 작업
작업 | 모니터링 감사자 | 감사자 | 전체 관리자
대시보드, 경고, 연결, 세션 및 서비스 보기 | 허용됨 | 허용됨 | 허용됨
경고 승인 | 허용됨 | 허용됨 | 허용됨
로그 정보 보기 | – | 허용됨 | 허용됨
경고 정의 만들기 | – | – | 허용됨
보고서 만들기 | – | 허용됨 | 허용됨
세션 및 서비스 중지 및 시작 | – | 허용됨 | 허용됨
방화벽 정책 보기 | – | 허용됨 | 허용됨
방화벽 정책 구성 | – | – | 허용됨
캐시 구성 | – | – | 허용됨
VPN(가상 사설망) 구성 | – | – | 허용됨
그림 10 Enterprise Edition과 연관된 역할 및 작업
작업 | 배열 모니터링 감사자 | 배열 감사자 | 배열 관리자
대시보드, 경고, 연결 및 세션 보기 | 허용됨 | 허용됨 | 허용됨
경고 승인 및 다시 설정 | 허용됨 | 허용됨 | 허용됨
로그 정보 보기 | – | 허용됨 | 허용됨
경고 정의 만들기 | – | - | 허용됨
보고서 만들기 | – | 허용됨 | 허용됨
세션 및 서비스 중지 및 시작 | – | 허용됨 | 허용됨
방화벽 정책 보기 | – | 허용됨 | 허용됨
방화벽 정책 구성 | – | – | 허용됨
캐시 구성 | – | – | 허용됨
VPN(가상 사설망) 구성 | – | – | 허용됨
NLB 드레이닝/중지 수행 | – | 허용됨 | 허용됨
로컬 정보 보기(배열 구성원의 레지스트리에서) | – | 허용됨 | 허용됨
로컬 정보 변경(배열 구성원의 레지스트리에서) | – | – | –
여기에서 알 수 있듯이 ISA Server와 연관된 관리자 작업은 상당히 세분화되어 있습니다. 이를 통해서 사용자의 조직 내에서 수월하게 사용자에게 올바른 역할을 할당할 수 있습니다.
이 밖에도 최소 권한의 개념을 적용하여 역할을 할당하는 것이 최선의 방법이라는 것을 기억해야 합니다. 말하자면 사용자가 작업을 수행하는 데 필요한 최소한의 권한을 부여해야 합니다.
중요한 것은 ISA Server 2006 Standard Edition의 로컬 관리자 그룹의 구성원은 ISA Server 전체 관리자와 같은 권한을 가진다는 것입니다. Enterprise Edition의 경우에는 구성 저장소 관리자 역할이 있는 서버의 로컬 관리자 그룹 구성원은 Enterprise 구성에 대한 완전한 제어를 가집니다. 이것은 ISA Server가 도메인의 구성원인 경우 ISA Server 로컬 관리자 그룹의 구성원인 다른 그룹은 물론이고 Domain Admins 그룹의 구성원을 주의 깊게 검토해야 한다는 것을 의미합니다.

Alan Maddison은 Brocade의 부서인 Strategic Business Systems에서 Microsoft 기술을 전문적으로 담당하는 수석 컨설턴트입니다.


ISA Server
ISA Server 2006으로 TS 게이트웨이 보안 향상
Dr. Thomas W. Shinder, Yuri Diogenes
한 눈에 보기:
  • ISA Server와 TS 게이트웨이를 사용하는 두 가지 시나리오
  • ISA Server 2006 구성
  • 테스트와 모니터링

목차
경계를 넘어
첫 번째 시나리오
ISA Server 2006 구성
클라이언트 액세스 테스트 및 모니터링
ISA Server에서 모니터링
두 번째 시나리오
클라이언트에 필요한 작업
결론
Exchange Server 2007에 포함된 “외부에서 Outlook 사용” 기능이 성공하면서 Windows Server 2008도 어디서든지 안전하고 제어 가능한 방법으로 데스크톱에 액세스하는 기능을 제공하고 있습니다.
Windows Server® 2008의 새로운 터미널 서버 게이트웨이(TS 게이트웨이) 서비스는 Windows® 터미널 서버 서비스의 유연성과 함께 HTTP 연결을 통해 어디에서든 터미널 서버에 연결할 수 있는 기능을 제공합니다. 이 서비스는 터미널 서비스 리소스에 액세스하기 위한 단일 클라이언트 인터페이스를 제공하면서도 보안을 향상시키기 위해 HTTPS(SSL)를 통한 RDP(원격 데스크톱 프로토콜)를 사용합니다.
이 새로운 TS 게이트웨이 서비스는 자신의 컴퓨터를 원격으로 액세스해야 하는 사용자에게 상당한 장점을 제공합니다.
  • RDP를 사용하여 내부 리소스에 연결하기 전에 VPN(가상 사설망) 세션을 설정할 필요가 없습니다.
  • RDP 연결을 제어하기 위한 NAP(네트워크 액세스 보호) 및 Windows 보안 상태 검사를 사용하여 보안을 향상시킵니다.
  • 방화벽을 통해 더 안전하게 웹 게시를 수행하기 위해 TCP 포트 3389 인바운드를 열 필요가 없습니다.
Microsoft® Internet Security and Acceleration (ISA) Server 2006을 사용하여 TS 게이트웨이 서비스의 보안을 향상시키고 내부 리소스에 대한 외부 액세스를 허용할 수 있습니다. 역시 HTTPS를 사용하여 ISA Server 2006이 요청을 수신하고 이를 내부 TS 게이트웨이 서비스로 전달하는 SSL-to-SSL 브리징 시나리오를 구성할 수 있습니다. 요청을 브리징할 때 ISA 방화벽이 SSL 통신의 암호를 해제하고 응용 프로그램 계층 검사를 수행합니다.
HTTP 프로토콜 스트림이 검사를 통과하면 통신을 다시 암호화하여 터미널 서비스 프록시로 전달합니다. 프로토콜 스트림이 검사를 통과하지 못하면 연결이 삭제됩니다.

경계를 넘어
Microsoft는 보안에 상당히 많은 노력을 기울였으며 Windows Server 2008은 가장 안전하고 강력한 Windows 버전입니다. 그러나 사용자가 제품을 구현하는 방법이나 자신의 환경을 안전하게 유지하기 위한 모범 사례를 따르는지에 대한 우려는 여전히 남아 있습니다. 모범 사례는 여러 액세스 지점이나 계층을 보호하는 심층적인 방어 방법을 요구합니다. 여기에서 설명하는 내용과 연관된 계층은 정책, 절차 및 인식, 경계, 내부 네트워크, 그리고 호스트입니다.
ISA Server 서버를 통해 외부 사용자가 내부 리소스에 액세스할 수 있도록 허용할 때는 연관된 각 제품의 경계를 이해해야 합니다. 경계 계층에 대한 보안은 ISA Server 2006과 TS 게이트웨이가 제공하지만 내부 리소스에 대해서는 필요에 따라 액세스를 허용하거나 거부할 정책을 마련해야 합니다. 이를 위해 정책, 절차 및 인식 계층에서 작동하는 NPAS(네트워크 정책 및 액세스 서비스)를 사용할 수 있습니다. 내부 리소스(드라이브, 클립보드, 프린터 등)에 대한 액세스는 내부 네트워크 계층을 처리하는 터미널 서비스 리소스 권한 부여 정책에 의해 정의됩니다.
이 기사에서는 먼저 ISA Server 2006을 통해 터미널 서비스 게이트웨이를 게시하는 방법을 알아보겠습니다. 그런 다음 NAP를 사용하여 클라이언트 상태 적용을 포함하도록 ISA Server 2006 게시 시나리오를 확장할 것입니다. NAP를 사용하면 클라이언트 상태 정책을 만들어 호스트 계층에서의 액세스를 제어하는 데 도움이 됩니다.

첫 번째 시나리오
우리의 목표는 ISA Server 2006을 통해 TS 게이트웨이를 게시하는 방법을 확인하는 것입니다. 그림 1에는 연결 중 컴퓨터와 데이터 흐름이 요약되어 있습니다. 이 시나리오에서는 TS 게이트웨이 자체에 NPS(네트워크 정책 서버) 역할을 구현했지만 중앙 NPS 서버를 사용하는 두 번째 시나리오에서는 다른 방법을 사용할 것입니다. TS 게이트웨이 게시 솔루션의 구성 요소 간에 통신이 작동하는 방법을 이해할 수 있도록 다음의 순서를 따라해 보십시오.
그림 1 ISA Server 2006을 통해 TS 게이트웨이 게시 (더 크게 보려면 이미지를 클릭하십시오.)
  1. 외부 RDP 사용자가 연결을 시작합니다. 클라이언트가 가장 먼저 할 일은 TS 게이트웨이의 외부 이름(이 경우에는 tsg.contoso.com)을 확인하는 것입니다. 외부 DNS가 ISA Server의 외부 IP 주소를 가리키는 이 이름을 확인합니다.
  2. RDP 클라이언트와 ISA Server의 외부 인터페이스 사이에 SSL 터널이 설정됩니다. ISA Server의 TCP 포트 443에는 tsg.contoso.com에 발급된 인증서를 사용하는 웹 게시 규칙이 있습니다.
  3. 규칙을 평가하고 트래픽이 허용되는지 검사한 다음 ISA Server는 도메인 컨트롤러에 위치한 내부 DNS 서버로 웹 게시 규칙에 지정된 서버의 이름을 확인하는 DNS 쿼리를 전송합니다.
  4. ISA Server는 TS 게이트웨이에 대한 SSL 터널을 열고 여기로 인증 요청을 전달합니다.
  5. TS 게이트웨이 서버는 사용자 자격 증명의 유효성을 검사하고 사용자가 연결할 권한이 있는지 확인합니다.
  6. 사용자가 연결할 권한이 있는지 확인한 다음 TS 게이트웨이 서비스는 TCP 포트 443에서 요청을 수신하고 TCP 포트 3389(기본 설정)를 통해 응용 프로그램(예: CRM 응용 프로그램)이 있는 내부 터미널 서버로 RDP 패킷을 전달합니다.
지금부터 RDP 클라이언트가 ISA Server를 통해 TS 게이트웨이 서비스로 전송하는 모든 패킷은 내부 터미널 서버로 전달되며 반대의 경우에는 반대 방향으로 전달됩니다.
내부적으로 사용되는 RDP over HTTPS는 단지 RDP/RPC/HTTPS입니다. RDP 클라이언트는 RPC 헤더로 RDP 통신을 캡슐화하며, RPC 헤더는 SSL(또는 Transport Level Security, TLS)을 통해 보안이 적용되는 HTTP 헤더를 사용하여 캡슐화됩니다. RPC over HTTPS 솔루션에 필요한 모든 구성 요소가 있어야 합니다. 이것이 TS 게이트웨이 역할 서비스를 설치할 때 RPC over HTTP 프록시가 자동으로 설치되는 이유입니다. 이 프로토콜이 작동하는 방법에 대한 자세한 내용을 보려면 ISA Server 팀 블로그(blogs.technet.com/isablog)에서 "Testing RPC over HTTP through ISA Server 2006 Part 1; Protocols, Authentication and Processing(ISA Server 2006을 통해 RPC over HTTP 테스트 1부; 프로토콜, 인증 및 처리)"이라는 포스트를 읽어 보십시오.
이 구현에는 터미널 서버 게이트웨이가 설치된 Windows Server 2008이 필요하며 이 기능은 RPC over the HTTP 프록시를 사용합니다. RDP over RPC over HTTP 프록시 기능은 IIS(인터넷 정보 서비스) 7.0이 설치되어 있어야 작동합니다. NPAS(네트워크 정책 및 액세스 서비스)도 필요하지만 원하는 경우에는 TS 게이트웨이가 이전에는 IAS(인터넷 인증 서비스)라고 했던 NPS 서버를 사용하도록 구성하여 저장소, 관리 및 TS CAP(터미널 서비스 연결 권한 부여 정책) 유효성 검사를 중앙 집중화할 수 있습니다. 참고로, 아직 없는 경우에는 TS 게이트웨이 서버용 SSL 인증서를 준비해야 합니다. ISA Server 2006이 인증서를 발급한 CA(인증 기관)를 신뢰해야 한다는 것도 중요합니다. 따라서 인증서를 신뢰할 수 있는 루트 인증 기관 저장소로 가져와야 합니다.
TS 게이트웨이 서버로 연결하기 위해 사용자가 Active Directory 보안 그룹의 구성원이어야 하도록 TS 게이트웨이 권한 부여 정책을 구성하는 경우에는 Active Directory® 도메인 서비스만 있으면 됩니다. 이 특정 구성에서는 Windows Server 2003 SP2를 실행하는 컴퓨터의 Active Directory를 사용하겠습니다.
터미널 서비스 게이트웨이 서비스 설치를 완료하면 설치된 구성 요소를 보여 주는 그림 2와 같은 화면이 표시됩니다. TS 게이트웨이를 연결하려면 클라이언트가 Windows Vista®, Windows XP SP2 및 RDP 6.0 이상, Windows Server 2008, Windows Server 2003 SP1 이상 및 RDP 6.0 이상 중 하나를 실행해야 합니다. TS 게이트웨이 구성에 대한 자세한 내용은 go.microsoft.com/fwlink/?LinkId=122251에 있는 Windows Server 2008 TS 게이트웨이 서버 단계별 설치 가이드를 참조하십시오. 다음은 ISA Server 2006을 구성하는 방법을 살펴보겠습니다.
그림 2 TS 게이트웨이 설치 요약 (더 크게 보려면 이미지를 클릭하십시오.)

ISA Server 2006 구성
첫 번째 단계는 외부 RDP 클라이언트로부터의 요청을 처리할 웹 수신기를 만드는 것입니다. 여기에서 사용할 웹 수신기는 다음과 같은 매개 변수를 가집니다.
  • 인증: 기본
  • 인증 유효성 검사: Windows(Active Directory)
  • 연결: 포트 443에서 SSL(HTTPS) 연결 설정
  • 인증서: tsg.contoso.com으로 인증서 발행
  • 네트워크: 외부
다음은 웹 게시 규칙을 만들어야 합니다. ISA Server 2006 관점에서 RDP 클라이언트는 외부에서 Outlook® 사용 기능과 동일한 프로토콜을 사용하므로 Exchange Server 2007 마법사를 선택하고 다음 단계를 따릅니다.
  1. 방화벽 정책을 마우스 오른쪽 단추로 클릭하고 새로 만들기를 선택한 다음 Exchange 웹 클라이언트 액세스 게시 규칙을 클릭합니다.
  2. 새 웹 게시 규칙 생성 마법사 시작 페이지에서 규칙의 이름을 입력하고 다음을 클릭합니다.
  3. 규칙 동작 선택 페이지에서 허용 옵션을 선택하고 다음을 클릭합니다.
  4. 새 Exchange 게시 규칙 페이지에서 Exchange 버전(이 경우에는 Exchange Server 2007)을 선택합니다. 외부에서 Outlook 사용(RPC/HTTP(s))을 선택하고 다음을 클릭합니다. 참고: Exchange Server for Outlook 2007 클라이언트에 추가 폴더 게시 옵션은 선택하지 마십시오.
  5. 게시 유형 페이지에서 단일 웹 사이트 또는 부하 분산 장치 게시 옵션을 선택하고 다음을 클릭합니다.
  6. 서버 연결 보안 페이지에서 SSL을 사용하여 게시된 웹 서버 또는 서버 팜에 연결을 선택하고 다음을 클릭합니다.
  7. 내부 게시 정보 페이지에 있는 내부 사이트 이름 입력란에 TS 게이트웨이 서버의 이름을 입력합니다. 컴퓨터 이름 또는 IP 주소를 사용하여 게시된 서버에 연결 확인란을 선택하고 컴퓨터 이름 또는 IP 주소 입력란에 서버 이름을 입력합니다. TS 게이트웨이 서버의 이름을 모르는 경우에는 찾아보기를 클릭하여 해당 위치로 이동합니다. 이 페이지에서 사용하는 이름은 TS 게이트웨이 웹 사이트에 바인딩되는 웹 사이트 인증서의 일반 이름이나 주체 이름과 일치해야 합니다.
  8. 공개 이름 정보 페이지에 있는 다음에 대한 요청 허용 드롭다운 목록에서 이 도메인 이름(아래에 입력)을 선택하고 공개 이름 입력란에 이 URL에 대해 발행된 인증서의 이름과 일치하는 공개 이름(이 예에서는 tsg.contoso.com)을 입력합니다. 다음을 클릭합니다.
  9. 웹 수신기 선택 페이지에서 드롭다운 목록을 클릭한 다음 이전에 만든 웹 수신기를 선택하고 다음을 클릭합니다.
  10. 인증 위임 페이지에서 위임 안 함 - 클라이언트에서 직접 인증 옵션을 선택하고 다음을 클릭합니다.
  11. 사용자 집합 페이지에서 기본 옵션(모든 사용자)가 선택되어 있는지 확인하고 다음, 마침을 차례로 클릭하고 이를 적용합니다.
규칙을 두 번 클릭하고 경로 탭으로 이동하면 유일한 경로인 /rpc/*를 볼 수 있습니다. 이것은 앞에서 Exchange Server 2007 외부에서 Outlook 사용 설정 마법사를 사용했기 때문입니다.

클라이언트 액세스 테스트 및 모니터링
앞에서 설명한 것처럼 TS 게이트웨이에 연결하려면 RDP 6.0 이상 클라이언트가 필요합니다. RDP 클라이언트 응용 프로그램을 구성하려면, 먼저 이를 시작하고 연결하려는 터미널 서버의 이름을 컴퓨터 입력란에 입력합니다. 옵션 단추, 고급 탭, 설정을 차례로 클릭하고 그림 3과 같이 TS 게이트웨이 서버의 외부 이름을 입력합니다. 이 예에서 이 이름은 들어오는 요청을 수락하기 위한 웹 게시 규칙에서 사용되는 웹 수신기에 바인딩되는 인증서의 이름입니다. 이 예에서는 Windows NT® LAN Manager 인증이 사용되었습니다. 완료되면 확인, 연결을 차례로 클릭합니다. 인증을 수행하라는 메시지가 표시됩니다. 터미널 서버에 액세스할 수 있는 사용자의 자격 증명을 입력하고 확인을 클릭합니다.
그림 3 RDP 클라이언트 구성 (더 크게 보려면 이미지를 클릭하십시오.)
RDP 6.0 클라이언트(Windows XP 및 Windows Server 2003용)에서는 그림 3과 같은 화면을 표시합니다. 인증을 수행하라는 메시지는 두 번 표시됩니다. 첫 번째 인증은 TS 게이트웨이 컴퓨터를 위한 것이며 두 번째 인증은 액세스하려는 터미널 서버를 위한 것입니다. 이것이 ISA Server 구성 때문이라고 생각할 수 있지만 실제로는 "모든 사용자"에 적용되는 웹 게시 규칙에 의해 ISA 방화벽을 통한 익명 연결이 허용되므로 ISA Server는 인증을 전혀 처리하지 않는다는 점이 중요합니다.
Windows Server 2008과 함께 제공되는 RDP 클라이언트에는 그림 4에 나와 있는 것처럼 원격 컴퓨터에 TS 게이트웨이 자격 증명 사용 옵션이 제공됩니다. 이 옵션을 선택하면 자격 증명을 두 번 입력할 필요가 없으므로 사용 환경이 편리해집니다. 이 Single Sign-On 옵션은 Windows Vista에서도 SP1을 적용한 후에 사용할 수 있습니다.
그림 4 Windows Server 2008 RDP 클라이언트 (더 크게 보려면 이미지를 클릭하십시오.)
모니터링 옵션을 사용하면 TS 게이트웨이 관리자를 통해 연결을 모니터링할 수 있습니다. TS 게이트웨이 서비스는 또한 승인되지 않은 사용자가 서버로 연결하려고 시도하면 상세 정보를 제공합니다. 그림 5의 이벤트 뷰어에는 권한이 없는 사용자가 TS 게이트웨이를 통해 연결하려는 시도가 나와 있습니다.
그림 5 TS 게이트웨이 서비스에 기록된 이벤트 (더 크게 보려면 이미지를 클릭하십시오.)
이 이벤트의 경우에는 웹 게시 규칙에서 요청이 ISA Server 컴퓨터에서 시작된 것으로 표시 옵션이 설정되었으므로 ISA Server 2006의 내부 IP 주소가 기록됩니다. 원래 클라이언트 IP 주소를 등록하려면 ISA Server 2006 웹 게시 규칙을 변경하고 대상 탭에서 요청이 원래 클라이언트에서 시작된 것으로 표시 옵션을 선택합니다.

ISA Server에서 모니터링
ISA Server 2006 Supportability Update의 새로운 기능을 사용하면 내부 네트워크에 대한 각 연결을 세부적으로 조사하고 살펴볼 수 있습니다. 그림 6에는 연결 중 하나가 강조 표시되어 있으며 Request: 줄의 RPC_IN_DATA 동사는 RPC over HTTP 프록시에 대한 URL임을 나타냅니다.
그림 6 Supportability 업데이트를 사용한 ISA Server 2006 로깅 (더 크게 보려면 이미지를 클릭하십시오.)
로깅을 계속 살펴보면 다른 RPC over HTTP 동사인 RPC_OUT_DATA를 볼 수 있습니다. HTTP 방식은 RDP/HTTP의 경우 RPC_IN_DATA 및 RPC_OUT_DATA이며 어떤 HTTP 방식이 사용되는지 인식하는 것이 중요합니다. 이러한 방식을 차단하기 위해 HTTP 필터링을 구성했다면 ISA Server에서 해당 트래픽이 차단됩니다. 사용자의 환경을 잠그려는 경우에는 이러한 두 방식만 허용하도록 RDP/HTTP 웹 게시 규칙을 구성할 수 있습니다. 게시에 일반적으로 사용되는 HTTP 방식에 대한 자세한 내용은 technet.microsoft.com/library/cc302627에서 "ISA Server 2004의 HTTP 필터링"을 참조하십시오.

두 번째 시나리오
이 시나리오에서 TS 게이트웨이는 다른 서버에 있는 NPS 중앙 정책을 사용합니다. 여기에서는 TS 게이트웨이를 통해 원격으로 연결하는 클라이언트에 NAP 정책을 적용할 것입니다. 여기에도 시나리오 1에서 사용되던 것과 동일한 구성 요소가 사용되며 NPS 서버만 추가됩니다. 그러나 NAP 적용 때문에 그림 7에 나온 것처럼 클라이언트 쪽에는 더 많은 구성 요소가 사용됩니다.
그림 7 시나리오 2 토폴로지의 기본 구성 요소 (더 크게 보려면 이미지를 클릭하십시오.)
개별 구성 요소에 대한 설명은 다음과 같습니다. Windows Vista 클라이언트에서 SHA(시스템 상태 에이전트)는 클라이언트의 상태를 모니터링 및 보고하는 클라이언트 쪽 구성 요소로 구성됩니다. Windows Vista에는 Windows SHA가 제공되지만 다른 공급업체에서 자체 SHA를 개발하고 있습니다.
클라이언트의 NAP 에이전트는 클라이언트가 네트워크에 액세스하려고 시도할 때 NAP 적용 서버와 통신을 설정하는 역할을 수행합니다. NAP 에이전트는 클라이언트의 SoH(상태 설명)를 해당 서버로 보냅니다.
TS 게이트웨이에서 어떤 컴퓨터가 들어오는 RDP 요청을 수신할 수 있을지 결정하는 구성 요소는 TS RAP(TS 리소스 권한 부여 정책)입니다. TS RAP는 어떤 사용자가 특정 서버에 대한 RDP 연결을 설정할 수 있는지도 결정합니다.
중앙 NPS는 내부 컴퓨터에 대한 액세스를 규정하는 조건, 제약 조건 및 설정을 제어하는 역할을 맡습니다. 중앙 NPS의 SHV(시스템 상태 검사기)는 클라이언트가 제출한 SoH가 관리자가 설정한 정책을 준수하는지 확인합니다.
이제 NPS 중앙 서버를 가리키도록 TS 게이트웨이를 변경하겠습니다. TS 게이트웨이 관리자 콘솔을 열고 서버 이름을 마우스 오른쪽 버튼으로 클릭한 다음 속성 옵션을 선택합니다. 서버의 속성 창에서 TS CAP 저장소 탭을 클릭한 다음 중앙 NPS 서버를 선택합니다. NPS 서버의 이름이나 IP 주소를 입력하고 추가 단추를 클릭합니다. 그러면 공유 암호 창이 열립니다. 암호를 입력하고 확인을 클릭한 다음 다시 확인을 클릭하여 창을 닫습니다. 이 암호는 NPS 서버에서 사용되므로 기억해야 합니다.
NPS가 이미 다른 서버에 설치되어 있는 경우에는 다음과 같은 단계를 따르면 됩니다.
  1. 네트워크 정책 서버 콘솔을 열고 왼쪽 창에서 NPS(로컬)를 클릭합니다.
  2. 오른쪽 창에서 NAP 구성을 클릭합니다. NAP에서 사용할 네트워크 연결 방법 선택 페이지가 표시됩니다.
  3. 네트워크 연결 방법에 있는 드롭다운 목록에서 TS 게이트웨이(터미널 서비스 게이트웨이)를 선택하고 다음을 클릭합니다.
  4. TS 게이트웨이를 실행하는 NAP 적용 서버 지정 페이지에서 추가 단추를 클릭합니다.
  5. 새 TS 게이트웨이 창에 TS 게이트웨이 서버의 이름과 IP 주소를 입력합니다. 그런 다음 창 맨 아래에 TS 게이트웨이 서버의 구성에 있는 것과 동일한 암호를 사용하여 공유 암호를 입력합니다. 확인을 클릭합니다.
  6. 클라이언트 장치 리디렉션 및 인증 방법 구성 페이지에서 리디렉션되는 장치와 허용되는 인증 방법(암호 또는 스마트 카드)을 지정할 수 있습니다. 이 예에서는 기본 옵션을 그대로 두고 다음을 클릭합니다.
  7. 사용자 그룹 및 컴퓨터 그룹 구성 페이지에서 연결할 수 있도록 허용되는 사용자 그룹을 추가합니다. 이 예에서는 사용자 그룹: (필수)에서 사용자 추가 단추를 클릭하고 Domain Admins를 선택합니다. 확인을 클릭하고 다음을 클릭합니다.
  8. NAP 상태 정책 정의 페이지에 기본 SHV가 이미 선택되어 있는 것을 볼 수 있습니다. 이 페이지의 맨 아래쪽을 보면 준수하지 않는 컴퓨터는 액세스가 거부되는 것을 볼 수 있습니다. 기본 선택 사항을 그대로 두고 다음을 클릭합니다.
  9. NAP 적용 정책 및 RADIUS 클라이언트 구성 완료 페이지에서 이전에 선택한 옵션을 검토합니다. 구성 세부 정보 하이퍼링크를 클릭하면 선택 사항에 대한 요약이 포함된 HTML 페이지가 열립니다. 작업이 완료되면 마침을 클릭합니다.
이 마법사는 여러 중요한 정책(연결 요청 정책, 네트워크 정책 및 상태 정책) 설정의 구성을 처리하여 이 시나리오에서 NAP를 구성하는 데 필요한 작업을 상당히 줄여 줍니다.

클라이언트에 필요한 작업
이제 서버를 설정하고 구성하는 작업을 완료했습니다. 클라이언트에는 어떤 작업이 필요할까요?
NAP 적용 정책을 활용하려면 클라이언트가 Windows Server 2008이나 Windows Vista여야 합니다. Windows XP의 경우에는 NAP 클라이언트가 포함된 SP3이 설치되어 있어야 합니다.
운영 체제 요구 사항 외에도 클라이언트 쪽에서 활성화해야 하는 몇 가지 관련 서비스와 설정이 있습니다. 이러한 항목은 다음과 같습니다.
  • TS 게이트웨이 서버 이름을 클라이언트의 신뢰할 수 있는 서버 목록에 추가합니다.
  • NAP 에이전트 서비스를 시작하고 서비스 시작 유형을 자동으로 설정합니다.
  • TS 게이트웨이 격리 적용 클라이언트를 활성화합니다.
이 솔루션의 배포를 간소화하기 위해 Microsoft는 터미널 서비스 NAP 클라이언트 구성 명령(Tsgqecclientconfig.cmd)을 만들었습니다. 이 명령은 go.microsoft.com/fwlink/?LinkId=122267에서 다운로드할 수 있습니다. 명령을 실행하면 클라이언트는 TS 게이트웨이를 위한 NAP 적용 클라이언트로 구성됩니다. 이 명령은 상승된 권한으로 실행해야 합니다.
이 기사의 주요 목적은 Windows Server 2008에서 사용할 수 있는 새로운 TS 게이트웨이 기능에 대해 설명하고 이를 ISA Server 2006을 통해 안전하게 게시하는 방법을 살펴보는 것뿐만 아니라 여러분의 회사에서 두 제품을 조합해서 사용하여 얻을 수 있는 보안상의 장점을 전반적으로 이해하는 것입니다.
오늘날 어디에서든 연결할 수 있는 능력은 기업의 성공에 핵심적인 요구 사항이 되고 있습니다. 그러나 이러한 연결 기능을 제공하기 위해 사용자의 개선된 환경이 저해되는 일이 있어서는 안 됩니다. 그리고 이보다 중요한 것은 이러한 모든 작업이 보안을 보장하는 방법으로 수행되어야 한다는 것입니다.

Dr. Thomas W. Shinder는 MCSE이자 ISA Server MVP이며 1996부터 기술 강사, 저자, 그리고 컨설턴트로 일했습니다. Dr. Shinder는 ISA 방화벽에 대한 6권의 책을 저술했으며 인터넷에서 가장 큰 ISA 방화벽 관리자와 사용자 커뮤니티인 ISAserver.org에서 사고의 리더이자 주요 실행자이기도 합니다.

Yuri Diogenes는 MCSE+S, MCTS, MCITP, Security+, Network+ 이자 CCNP이며 Microsoft ISA Server/IAG 팀에서 보안 지원 엔지니어로 일하고 있습니다. 현재는 Microsoft TechNet 라이브러리와 ISA Server 팀 블로그를 위한 기사를 작성하고 있습니다. Yuri는 1993년에 Microsoft에 입사했으며 Microsoft에 입사하기 전에는 Microsoft 강사, 지원 분석가 및 컨설턴트로 일했습니다.


IIS 7.0
IIS 7.0의 가장 중요한 10가지 성능 향상
Mike Volodarsky
한 눈에 보기:
  • 사용자 응용 프로그램의 공간 최소화
  • 대역폭 비용 감소
  • 향상된 캐싱 기능 사용

목차
간결한 웹 서버
간결한 OS를 기반으로 활용
특화된 응용 프로그램 포톨로지
응용 프로그램 지원 개선
응용 프로그램 밀도 향상
압축을 통한 대역폭 감소
미디어 비트 전송률 제한
출력 캐싱
ISAPI 코드를 IIS 7.0 모듈로 변환
서버 확장성
결론
IIS 7.0을 도입하려는 회사의 관계자와 이야기할 때 빠지지 않는 질문 중 하나는 IIS 7.0을 도입하면 서버나 응용 프로그램의 성능이 개선될 것인지에 대한 것입니다. 보통은 이 질문에
예라고 답하지만 응용 프로그램을 처음 IIS 7.0으로 마이그레이션하고 성능 향상이 보이지 않는다고 해도 놀라지는 마십시오.
이러한 현상을 이해하려면 최신 릴리스의 특성을 이해할 필요가 있습니다. IIS 6.0은 강력한 보안, 높은 안정성 및 성능 향상이라는 세 가지 목표를 위한 엔지니어링 릴리스였습니다. 반면에 IIS 7.0은 플랫폼 릴리스이며 이전 버전의 고품질 기본 웹 서버 코어를 핵심적인 최신 배포 및 관리 시나리오 지원을 갖춘 모듈 방식의 확장성 높은 플랫폼으로 전환하는 목적을 가지고 있습니다.
아키텍처에 대한 여러 가지 변경과 새로운 기능이 실제로는 웹 서버의 성능에 좋지 않은 영향을 줄 수 있습니다. 예를 들어 최적화된 웹 서버 코드 경로가 핵심적인 변경 사항 중 하나에 의해 독립 실행형 모듈로 분리되어 웹 서버에서 특별한 대우를 받지 못하게 될 수 있습니다. 그러나 성능 향상을 위한 IIS 팀의 노고 덕분에 IIS 7.0은 이전 버전과 비교했을 때 여러 부분에서 동등하며 특정 영역에서는 오히려 앞서는 성능을 보여 줍니다. 웹 서버 코어와 통합 파이프라인 개발에 참여했던 필자의 개인적인 관점에서 볼 때 이것이 가능했던 것은 디자인 면에서 많은 독창성과 제품 구현의 노력이 있었기 때문입니다.
IIS 7.0이 이전 IIS 릴리스에 비해 상당한 성능 향상을 제공하고 서버 팜에서 성능 관련 비용을 줄일 수 있는 잠재력이 훨씬 높다는 점은 분명합니다.
단순히 IIS 7.0으로 마이그레이션하여 반드시 이러한 혜택을 볼 수 있는 것은 아니지만 일부 환경에서는 곧바로 혜택을 볼 수 있습니다. Microsoft.com에서는 10%의 CPU 효율 향상을 경험했습니다. 완전한 분석 자료는 Microsoft.com 팀 블로그(go.microsoft.com/fwlink/?LinkId=122497)에서 볼 수 있습니다. 이 밖에도 SSL(Secure Sockets Layer), Windows® 인증(이 둘은 이제 커널에서 수행됨), 그리고 다중 코어 및 다중 프로세서 시스템에서 개선된 수직 확장성을 포함하여 특정 영역에서 분명한 개선이 있습니다.
그러나 IIS 7.0의 진가는 기존 기능에 대한 성능 향상보다는 적극적인 활용이 필요한 새로운 기능을 통해서 확인할 수 있습니다. 이러한 기능은 플랫폼의 유연성과 확장성 특성과 새로운 성능 기능에 기반을 두는 경우가 많습니다. 이 기사에서는 IIS 7.0으로 전환하여 성능 향상을 거둘 수 있는 가장 중요한 10가지 부분을 살펴보겠습니다.

간결한 웹 서버
간결한 IIS 7.0 서버를 배포하는 능력은 서버의 모듈식 아키텍처 덕분에 가능해졌습니다. 실질적으로 모든 웹 서버 기능은 모듈식 구성 요소로 구현되었으므로 별도로 추가하거나 제거할 수 있습니다. 따라서 응용 프로그램의 작업에 필요하지 않은 모든 서버 기능을 제거하여 공격 가능 영역과 작업 공간을 크게 줄이고 성능을 향상시키는 것과 같은 많은 혜택을 얻을 수 있습니다.
전체 IIS 7.0 웹 서버 기능에는 통합 파이프라인에 서비스를 제공하는 네이티브 IIS 모듈과 ASP.NET 모듈을 포함하여 44개의 모듈이 포함되어 있습니다. 이러한 모듈은 인증(Windows 인증 및 다이제스트 인증 모듈), 응용 프로그램 프레임워크 지원(FastCGI 모듈), 응용 프로그램 서비스(세션 상태 모듈), 보안(요청 필터링 모듈) 및 성능(출력 캐시 모듈)과 같은 서비스를 제공합니다. 놀랍게도 정적 콘텐츠만 제공하면 되는 최소한의 웹 서버는 단 두 개의 모듈로도 작동이 가능합니다!
불필요한 모듈로 인한 오버헤드는 가령 요청 로깅이나 실패한 요청 추적 모듈의 경우에는 상당히 높은 수준까지 발생할 수 있습니다. 환경에서 필요 없는 이러한 모듈을 제거하면 전체 처리량을 높이고 서버 워크로드에 대한 TTFB(첫 번째 바이트까지의 시간) 및 TTLB(마지막 바이트까지의 시간)를 낮추어 응답 성능을 개선할 수 있습니다.
그림 1에는 HTML 파일(정적 워크로드) 및 hello world ASP.NET 페이지(ASP.NET 워크로드)를 전체 기능 집합, 해당 워크로드를 위한 기본 기능 집합 및 워크로드에 필요한 최소 기능 집합 구성에서 제공하는 간단한 처리량 테스트의 결과가 나와 있습니다. 전체 구성에서도 대부분의 불필요한 기능은 이미 해제되어 있지만 최소 구성에서 이를 완전하게 제거하면 정적 워크로드와 ASP.NET 워크로드 모두에서 상당한 처리량 상승을 경험할 수 있습니다.
그림 1 동시 클라이언트가 100개일 때 세 가지 다른 구성에서 정적 워크로드와 ASP.NET 워크로드의 처리량 비교 (더 크게 보려면 이미지를 클릭하십시오.)
또한 메모리 용량과 사이트 밀도가 향상된 것을 볼 수 있으며 이러한 효과는 공유 호스팅 환경이나 많은 수의 작업자 프로세스가 사용 중인 경우에 더욱 높아집니다. 일반적으로 성능 개선은 각 프로세스에 적은 수의 DLL을 로드하고 모듈 초기화와 요청 처리 중에 발생하는 메모리 할당을 취소화함으로써 얻어집니다. 그림 2에는 동일한 처리량 테스트에서의 메모리 사용량(IIS 작업자 프로세스의 개인 바이트)이 나와 있습니다. 이 예에서는 ASP.NET appdomain 오버헤드가 모듈을 제거하여 얻는 기본 향상보다 비교적 높기 때문에 성능 향상이 두드러지게 나타나지 않고 있지만 향상되는 양상은 예상대로입니다.
그림 2 동시 클라이언트가 100개일 때 세 가지 다른 구성에서 정적 워크로드와 ASP.NET 워크로드의 메모리 사용량(개인 바이트) (더 크게 보려면 이미지를 클릭하십시오.)
IIS 7.0은 응용 프로그램 수준에서 사용할 모듈에 대한 추가 제어를 제공하며 모듈 전제 조건을 통해 워크로드를 바탕으로 모듈 사용량에 대한 제어도 제공합니다. 이렇게 하려면 추가적인 고급 구성을 수행해야 하지만 다중 사이트 환경이나 여러 고유 워크로드를 지원하는 응용 프로그램에 추가적인 장점을 제공할 수 있습니다.
한 가지 주의할 것은 필요한 기능을 결정하기가 까다로울 수 있다는 것입니다. 응용 프로그램 프레임워크를 지원하기 위한 최소한의 기능뿐 아니라 응용 프로그램이 간접적으로 사용하는 추가 기능도 고려해야 합니다. 예를 들어 여러분의 응용 프로그램이 특정한 인증 방법을 사용하거나 다양한 IIS 기능에서 제공되는 권한 부여 체계에 의존하는 경우가 있을 수 있습니다. 이러한 경우 해당 모듈을 제거하면 응용 프로그램의 보안에 나쁜 영향을 줄 수 있습니다. 비슷하게 여러분의 응용 프로그램이 기능이나 성능 효과를 위해 다른 모듈을 사용하는 경우가 있으며 이때 이러한 모듈을 제거하면 작동에 문제가 생기거나 성능 저하가 발생합니다.

간결한 OS를 기반으로 활용
Windows Server® 2008에서는 웹 서버의 노출 영역을 더욱 줄일 수 있는 OS 수준 구성 요소화를 제공합니다. Server Core는 최소한의 핵심 OS 하위 시스템 집합이 포함되어 있는 Windows Server 2008 운영 체제의 최소 설치 옵션입니다. Server Core는 간결한 IIS 7.0 웹 서버를 위한 이상적인 환경입니다.
그러나 Server Core를 평가할 때는 응용 프로그램에 영향을 줄 수 있는 몇 가지 제약 사항에 주의해야 합니다. Server Core는 Microsoft® .NET Framework를 지원하지 않으므로 ASP.NET, IIS용 .NET 확장성 및 IIS 관리자를 사용할 수 없습니다. 또한 MMC(Microsoft Management Console)가 없기 때문에 명령줄 도구를 사용하여 로컬 관리 작업을 수행해야 합니다. IIS 구성 요소화를 이미 올바르게 활용하고 있다면 성능의 관점에서는 Server Core 또는 전체 Windows Server 구현 중 어디에서 여러분의 응용 프로그램 워크로드를 실행하더라도 메모리 공간이나 처리량 면에서는 차이가 없을 것입니다. 이것은 작업이 IIS에서 실행되며 응용 프로그램 자체는 두 플랫폼에서 동일하기 때문입니다. 그러나 서버의 전체 공간에 있어서는 디스크 공간이나 메모리 사용량에 있어 차이가 있습니다.
그림 3에는 정적 워크로드 테스트를 전체 Windows Server 2008 구성과 Server Core에서 수행한 경우 공간의 차이가 나와 있습니다. IIS 공간은 두 경우에 거의 동일하지만 Server Core의 전반적인 OS 공간 사용이 적기 때문에 훨씬 적은 양의 메모리로 워크로드를 지원할 수 있습니다. 사용 공간이 적다는 것은 응용 프로그램 워크로드를 덜 강력한 하드웨어에 배포하고 운영 체제 환경이 아니라 응용 프로그램의 요구를 처리하는 데 집중할 수 있다는 것을 의미합니다. 물론 같은 이유로 가상화된 환경에서도 Server Core는 훌륭한 옵션입니다.
그림 3 정적 워크로드 테스트를 수행한 후의 전체 Windows Server 2008과 Server Core 메모리 공간 비교 (더 크게 보려면 이미지를 클릭하십시오.)

특화된 응용 프로그램 포톨로지
응용 프로그램 워크로드를 최적화할 때는 워크로드를 고유한 부분으로 분리할 수 있습니다. 예를 들어 동일한 웹 서버 30대로 구성된 팜에서 실행하던 응용 프로그램을 웹 서버 10대, 응용 프로그램 서버 5대, 그리고 캐싱 및 압축을 수행하는 프록시 서버 3대로 구성된 팜에서 실행할 수 있습니다.
이러한 특화가 효과를 발휘하는 몇 가지 이유가 있습니다. 첫째, 응용 프로그램 워크로드의 성능은 메모리와 같이 응용 프로그램의 여러 부분에서 경합을 벌이는 다양한 공유 리소스의 영향을 받는 경우가 많습니다. 리소스에 대한 이러한 경쟁은 각 서버가 다른 리소스를 완벽하게 사용하는 데 방해가 되는 병목 현상의 원인입니다. 응용 프로그램의 부분을 분리하면 기존에 경합을 벌여야 했던 리소스에 쉽게 액세스할 수 있게 되어 동일한 하드웨어 리소스에서도 높은 효율을 거둘 수 있습니다.
둘째, 특화를 통해서 응용 프로그램의 캐시 효율이 향상되어 성능도 개선될 수 있습니다. 이러한 캐시에는 가상 메모리 TLB(Translation Lookaside Buffer), 파일 시스템 캐시, 다른 운영 체제 및 응용 프로그램 캐시가 있습니다. CPU에서도 효율 향상 효과를 얻을 수 있습니다. 응용 프로그램의 특정 부분에 집중함으로써 병렬 작업의 수를 줄이고 CPU가 수행해야 하는 컨텍스트 전환 횟수를 줄임으로써 작업 성능을 극대화할 수 있습니다.
셋째, 특화를 통해 워크로드별 최적화를 수행하여 응용 프로그램의 각 부분이 더 효율적으로 작동하도록 만들 수 있습니다. 전체 응용 프로그램이 같은 서버에서 지원되는 경우에는 응용 프로그램의 다른 부분에 대한 요구가 충돌하여 이러한 최적화 중 많은 항목이 불가능합니다.
이 현상이 발생하는 일반적인 장소 중 하나로 동시성에 상당히 큰 영향을 주며 여러 응용 프로그램에서 메모리 사용, 대기 시간 및 처리량에 간접적인 영향을 주는 IIS와 ASP.NET 스레딩 구성이 있습니다. IIS 정적 파일 워크로드는 상당히 비동기적이며 높은 동시 요청 한계가 필요하지만 사용 가능한 스레드 수가 상당히 적어도 작동합니다. 반면에 ASP.NET 기능 중에는 동기적이고 오랫동안 차단하며 스레드가 많이 필요한 기능이 많으며 일부는 메모리에 대한 영향을 줄이기 위해 낮은 동시성 제한을 필요로 합니다. 정적 워크로드를 분리하고 요청 처리 파이프라인 부분을 별도의 프로세스나 서버로 분리하면 각 개별 워크로드의 동시성을 최적화할 수 있습니다.
마지막으로 특화를 통해 응용 프로그램이 서로 연관이 없는 별도의 워크로드나 응용 프로그램 부분을 수직적으로 확장할 수 있게 되어 전반적인 확장성이 향상됩니다. 이를 통해 전체 응용 프로그램에 동일한 템플릿을 적용할 필요 없이 응용 프로그램 토폴로지에서 가장 필요한 곳에 증가한 용량과 중복성을 제공할 수 있게 됩니다. 이 모델에서 특화된 리소스는 실제 서버이거나 가상 서버 또는 심지어 같은 시스템의 응용 프로그램 풀이 될 수 있습니다.
여러분의 응용 프로그램 토폴로지에 특화를 적용함으로써 얻을 수 있는 잠재적인 혜택을 평가할 때는 먼저 응용 프로그램에서 프로세싱 또는 리소스를 많이 사용하는 병목 현상을 찾는 것으로 시작하십시오. 이러한 영역을 격리하면 상당한 최적화 잠재성이 제공되고 가장 높은 수준의 수평 확장성을 요구하므로 가장 먼저 특화 후보로 고려해야 합니다. 그런 다음 이러한 영역을 격리하면 응용 프로그램의 나머지 부분이 리소스를 더 효과적으로 활용할 수 있는지 평가합니다. 마지막으로 격리된 응용 프로그램 구성 요소를 연결하는 데 필요한 연결 메커니즘의 오버헤드를 평가해야 합니다.

응용 프로그램 지원 개선
IIS 7.0에는 여러 공개 소스 응용 프로그램 프레임워크에서 지원되는 공개 프로토콜인 FastCGI를 통해 확장된 응용 프로그램 프레임워크 지원이 제공됩니다. 이러한 지원이 없었다면 IIS와의 안정적이고 성능이 뛰어난 네이티브 통합이 불가능했을 것입니다. 오랫동안 IIS에서 지원된 CGI(Common Gateway Interface) 프로토콜과는 달리 FastCGI는 Windows 플랫폼에서 훨씬 개선된 성능을 제공합니다. 이것은 주로 심한 요청별 프로세스 생성 오버헤드를 없애서 클라이언트가 지속적으로 유지되는 연결을 활용할 수 있도록 하는 FastCGI 재사용 가능 프로세스 아키텍처 덕분입니다.
IIS에서 CGI나 다른 메커니즘을 사용하여 응용 프로그램 프레임워크를 지원하는 경우에는 이를 FastCGI 프로토콜로 변환하여 성능(경우에 따라서는 안정성까지)을 개선할 수 있습니다.
이 지원을 활용하는 첫 번째 응용 프로그램 프레임워크는 PHP입니다. 실제로 IIS 팀에서는 IIS FastCGI에서 PHP가 잘 작동하고 Windows에서 PHP 프레임워크의 성능을 개선할 수 있도록 Zend Technologies와 직접 협력하여 작업을 진행했습니다. 프로젝트에 대한 자세한 내용은 필자의 블로그(go.microsoft.com/fwlink/?LinkId=122509)를 참조하십시오. IIS에서 실행되는 ASP 또는 ASP.NET 응용 프로그램, PHP 또는 다른 기술을 사용하는 FastCGI 호환 응용 프로그램 프레임워크를 포함하여 웹 서버 기술을 혼합해서 사용하고 있다면 이러한 응용 프로그램을 IIS 7.0 플랫폼에서 통합할 수 있습니다.
PHP 및 다른 응용 프로그램 프레임워크를 IIS 7.0 및 FastCGI로 전환하면 ASP.NET 통합 파이프라인을 포함하는 다양한 IIS 7.0 기능을 활용할 수 있습니다. 이렇게 하면 응용 프로그램 프레임워크를 ASP.NET으로 변환하지 않고도 ASP.NET 서비스를 활용하여 향상시킬 수 있는 매우 편리한 옵션이 제공됩니다. 또한 다른 프레임워크를 사용하는 응용 프로그램이 공동 작업하는 기반이 마련됩니다. 이 방법을 사용하여 코드를 전혀 변경하지 않고도 기존 응용 프로그램의 기능과 성능을 향상시키는 방법에 대한 예는 msdn.microsoft.com/magazine/cc135973.aspx에서 필자의 MSDN 기사 "통합된 ASP.NET 파이프라인을 활용한 응용 프로그램 향상"을 참조하십시오.

응용 프로그램 밀도 향상
IIS 7.0에는 단일 서버에서 호스트되는 응용 프로그램의 밀도를 높이기 위한 향상된 기능이 많이 포함되어 있습니다. 이러한 향상된 기능은 공유 호스팅의 품질을 개선하기 위해 IIS 7.0에서 제공하는 개선된 사이트 프로비전 및 응용 프로그램 격리를 포함하는 다양한 기능의 일부입니다.
성능 측면에서 이러한 향상은 IIS 7.0 서버에서 프로비전할 수 있는 응용 프로그램의 수를 늘리는 것과 동시에 활성화할 수 있는 응용 프로그램의 수를 늘리는 두 가지 측면에서 집중적으로 이루어졌습니다.
IIS 7.0은 이전 버전에 비해 각 서버에서 더 많은 수의 응용 프로그램을 프로비전할 수 있습니다. 내부 테스트에 의하면 단일 서버에서 최대 100,000개의 사이트를 프로비전할 수 있었습니다. 이러한 결과는 더 많은 수의 사이트와 응용 프로그램을 만들고 구성하는 능력을 통해 가능해졌습니다.
한 가지 주의할 것은 고속 프로비전을 수행하려면 새로운 구성 API로 전환해야 한다는 것입니다. 기존 구성 API로는 이를 달성할 수 없습니다. 또한 모든 IIS 구성 API가 동일한 성능 특성을 제공하는 것은 아니므로 높은 성능을 보장하기 위해서는 신중하게 선택해야 합니다. 확신이 없는 경우에는 Microsoft.Web.Administration 네임스페이스, AppCmd.exe 명령줄 도구, 그리고 스크립트, .NET 또는 C++ 코드에서 액세스하는 IIS COM 구성 개체를 포함하여 새로운 IIS 구성 개체를 직접 활용하는 구성 옵션을 선택하십시오.
요청을 처리하기 위해 영구적 응용 프로그램 및 작업자 프로세스를 사용하는 IIS 아키텍처에서 프로비전할 수 있는 사이트의 수와 활성화할 수 있는 사이트의 수 사이에는 매우 중요한 차이가 있습니다. 이 모델에서 활성 응용 프로그램은 서버에서 더 많은 리소스를 소비하지만 캐싱을 사용하고 초기화 비용이 제거되어 더 나은 지속 성능을 제공합니다.
권장되는 응용 프로그램 격리 모델을 사용하는 경우 각 활성 응용 프로그램에 특정한 양의 메모리와 별도의 작업자 프로세스가 필요하므로 활성 응용 프로그램의 수는 응용 프로그램 메모리 공간에 크게 좌우됩니다. 따라서 정적 콘텐츠만 제공하는 단일 응용 프로그램은 작업자 프로세스에 3MB만 필요할 수 있으며 심지어 다른 정적 콘텐츠 응용 프로그램과 같은 작업자 프로세스를 공유하는 것도 가능하지만 일부 동적 응용 프로그램에서는 사용량이 낮은 경우에도 100MB 이상의 RAM이 필요할 수 있습니다. 따라서 최대 가능 밀도를 정의할 때 IIS 작업자 프로세스 자체의 메모리 오버헤드는 응용 프로그램의 공간과 비교하면 중요성이 떨어집니다.
일반적인 공유 호스팅 시나리오에는 요청의 80%가 사이트 중 20%에 집중되는 80/20 분포라는 현상이 자주 나타납니다. 이에 따라 동시에 활성화할 수 있는 사이트의 비율이 낮아집니다. IIS 7.0에서는 활성 사이트의 수를 늘리기 위해 비활성 응용 프로그램에서 메모리를 회수하여 더 많은 활성 응용 프로그램을 호스트할 수 있도록 하는 활성 수명 관리라는 기능을 제공합니다.
IIS 7.0에는 서버에서 사용 가능한 메모리를 바탕으로 작업자 프로세스의 유휴 시간 제한을 사전에 조정하는 동적 유휴라는 새로운 알고리즘이 도입되었습니다. 사용 가능한 메모리가 줄어들면 유휴 응용 프로그램을 더 빠르게 제거하여 더 많은 활성 응용 프로그램을 호스트할 수 있습니다. 그리고 메모리가 충분한 경우에는 시간 제한을 길게 유지하여 더 나은 성능을 제공하고 응용 프로그램 상태를 유지할 수 있습니다. 동적 유휴를 사용하면 더 많은 응용 프로그램을 활성 상태로 유지할 수 있는 것은 물론 스래싱(Thrashing)으로 인한 심각한 성능 저하의 원인인 메모리 부족 현상을 방지하는 데 도움이 됩니다.
활성 응용 프로그램을 더 많이 호스팅하려면 OS에서 4GB보다 많은 메모리를 주소 지정할 수 있는 64비트 운영 체제를 활용해야 합니다. 64비트 운영 체제에서도 IIS 작업자 프로세스를 32비트 모드(SysWoW64)로 실행하여 메모리를 더 적게 소비하면서도 OS는 32비트 환경보다 더 많은 메모리 공간을 주소 지정할 수 있습니다.

압축을 통한 대역폭 감소
인터넷 연결 데이터 센터를 운영하는 데 필요한 비용 중 대역폭 비용이 가장 높다는 사실은 놀라운 일이 아닙니다. 또한 요청된 콘텐츠를 제공하는 데 필요한 대역폭은 응용 프로그램의 응답성에 중요한 핵심 요소입니다.
응용 프로그램 응답을 제공하는 데 필요한 대역폭을 줄이는 가장 효과적인 방법 중 하나는 HTTP 압축을 사용하는 것입니다. 이렇게 하면 응답의 크기를 상당히 줄일 수 있으며 HTML과 같이 압축이 용이한 텍스트 콘텐츠에 적용하는 경우에는 1/10 수준까지 압축할 수 있습니다. 게다가 거의 모든 브라우저에서 압축을 지원하며 데스크톱 하드웨어에서 압축 해제를 수행하기 위한 비용은 데이터를 적게 전송하여 얻는 대기 시간 감소와 비교하면 사소한 수준입니다. 또한 압축은 HTTP 1.1 프로토콜에 정의된 콘텐츠-인코딩 협상에 기반을 두므로 압축을 지원하지 않는 클라이언트에서도 안전하게 이 기능을 사용할 수 있습니다. 이러한 클라이언트는 단순히 콘텐츠의 압축되지 않은 버전을 수신합니다.
IIS 7.0은 이전 버전에 도입된 정적 압축과 동적 압축의 두 가지 압축 기능을 제공합니다. 정적 압축은 정적 콘텐츠를 미리 압축하여 디스크에 저장하므로 향후 요청에 압축 오버헤드 없이 압축된 콘텐츠를 제공할 수 있습니다. 동적 압축은 실시간으로 응답을 압축하므로 응용 프로그램에서 생성된 응답을 압축할 수 있습니다. ASP, ASP.NET 또는 PHP를 포함하여 IIS 7.0의 모든 응용 프로그램 프레임워크는 동적 압축을 활용할 수 있습니다.
일반적인 통념과는 달리 동적 압축이 CPU 오버헤드를 심각하게 유발하지는 않습니다. 실제로 사용량이 많은 서버에서 동적 압축에 사용되는 전체 CPU 사용률은 5% 미만입니다. 동적 압축은 모든 응용 프로그램 워크로드에서 최대한의 대역폭을 저장할 수 있도록 비교적 자유롭게 배포할 수 있습니다.
압축 강도를 구성하면 원하는 압축 수준과 CPU 오버헤드 비율을 조정하여 압축 오버헤드를 최적화할 수 있습니다. 여기에서 그치지 않고 응용 프로그램이 압축된 콘텐츠를 캐싱할 수 있도록 구성하면 이미 압축된 콘텐츠에 대해서는 다시 압축하는 오버헤드를 방지할 수 있습니다. ASP.NET과 IIS 출력 캐시는 기능을 지원하는 클라이언트를 위해 압축된 콘텐츠를 캐시하는 것은 물론 압축되지 않은 콘텐츠가 필요한 클라이언트의 요청을 처리할 수 있는 선택적인 기능을 포함하도록 업그레이드되었습니다.

미디어 비트 전송률 제한
미디어 콘텐츠를 제공하는 사이트의 수가 증가함에 따라 많은 기업의 대역폭 비용 또한 빠른 속도로 증가하고 있습니다. 문제는 클라이언트로 전송된 미디어 콘텐츠의 많은 부분이 아예 사용되지 않기 때문에 대역폭 낭비가 심각하다는 사실입니다. 왜 이러한 문제가 발생할까요?
브라우징하면서 최근에 온라인 비디오를 보았던 기억을 떠올려 보십시오. 이러한 비디오를 끝까지 보셨습니까? 비디오 사이트를 브라우징하는 동안 비디오의 특정 부분만 감상하고 다른 비디오를 보거나 페이지를 떠나는 경우가 일반적입니다. 그러나 비디오를 제공하는 데 점진적 다운로드를 사용하는 웹 서버는 이러한 몇 초간의 재생 시간에 필요한 것보다 훨씬 많은 양의 데이터를 전송합니다. 이러한 데이터 대부분은 아예 사용되지 않습니다.
비디오를 5초 동안 감상하기 위해 이 5초 동안 30초 분량의 비디오 데이터를 전송(버퍼링)한다면 대역폭의 80% 이상을 낭비하는 것입니다.
필자는 1년 전에 IIS 7.0 베타 릴리스를 도입하는 고객의 환경에서 이 문제가 발생하지 않도록 비디오 비트 전송률을 자동으로 감지하여 이와 거의 비슷한 속도로 클라이언트에 비디오를 전송하는 대역폭 제한 모듈을 개발했습니다. IIS 미디어 팀에서는 비트 전송률 제한 모듈(그림 4 참조)이라고 하는 이 모듈을 선택하고 iis.net 다운로드 센터에서 제공하고 있습니다(iis.net/downloads/?tabid=34&g=6&i=1640). 자세한 내용은 Scott Guthrie의 블로그(go.microsoft.com/fwlink/?LinkId=122514)를 참조하십시오.
그림 4 비트 전송률 제한을 통해 대역폭 사용 최소화 (더 크게 보려면 이미지를 클릭하십시오.)
비트 전송률 제한 모듈은 가장 많이 사용되는 비디오 유형의 인코딩 속도를 자동으로 감지합니다. 빠른 시작을 위해 초기 버퍼링 대기 시간을 없애도록 클라이언트에 미리 전송할 데이터의 양과 인코딩 속도에 대한 콘텐츠 전송 비율도 제어할 수 있습니다. 최대 대역폭 및 동시 연결과 같은 다른 여러 옵션을 구성할 수 있으며 모듈을 프로그래밍 방식으로 제어할 수도 있습니다.

출력 캐싱
일반적으로 캐싱은 반복적인 작업을 수행하는 응용 프로그램의 성능을 개선하는 최선의 방법입니다. 응용 프로그램별 성능 개선에는 상당히 많은 노력과 응용 프로그램의 프로세싱 오버헤드에 대한 세밀한 조사가 필요하지만 캐싱은 동일한 콘텐츠에 대한 반복된 요청에 따르는 오버헤드를 제거하는 방법입니다.
IIS 7.0 이전에는 IIS 커널 캐시와 ASP.NET 캐시 형식으로 IIS와 ASP.NET이 각각 캐시 기능을 제공했습니다. IIS 커널 캐시는 최고의 성능을 제공했지만 주로 정적 콘텐츠로 사용이 제한되었습니다. ASP.NET 출력 캐시는 동적 콘텐츠를 캐싱하기 위한 훨씬 완전한 솔루션이었지만 성능과 메모리 관리 효율이 떨어졌습니다. IIS 7.0의 새로운 출력 캐시는 IIS 커널 캐시와 ASP.NET 출력 캐시의 부족한 점을 보완했습니다.
IIS 7.0 출력 캐시는 ASP, ASP.NET, PHP 및 다른 IIS 7.0 호환 응용 프로그램 프레임워크를 포함하여 모든 응용 프로그램에서 동적 콘텐츠를 캐싱할 수 있습니다. 이 새로운 기능은 콘텐츠 가변성과 만료를 지원할 수 있으므로 IIS 커널 캐시에서는 캐시할 수 없었던 콘텐츠까지 캐싱을 구현합니다. 또한 제한을 충족하지 않는 콘텐츠에도 커널 캐시를 사용할 수 있습니다.
또한 IIS 7.0 출력 캐시는 ASP.NET 출력 캐시에서만 제공되는 고급 캐싱 기능(예: 캐시 종속성 또는 무효화)이 요구되지 않은 ASP.NET 콘텐츠를 위해 보다 높은 성능을 제공하는 ASP.NET 출력 캐시의 대안으로도 사용할 수 있습니다.
출력 캐시에 있어 과제는 일반적으로 효과적인 응답 캐싱을 가능하게 하면서도 요구되는 캐시 정확성 및 유효성을 유지하도록 올바른 콘텐츠 만료, 무효화 및 가변성 정책을 정의하는 것입니다. 대부분의 경우에는 간단히 올바른 캐싱 규칙을 구성하는 것으로 충분하지만 일부 경우에는 런타임 정보를 바탕으로 복잡한 정책이 필요합니다. 이를 처리하기 위해 IIS 7.0 출력 캐시는 필요한 캐싱 동작을 보장하기 위한 프로그래밍 API를 제공합니다. 이를 통해 이전에는 캐싱의 혜택을 볼 수 없었던 콘텐츠에 대해서도 캐싱 성능 향상을 경험할 수 있습니다. 또한 ASP.NET 통합 파이프라인을 통해 비 ASP.NET 콘텐츠에서도 ASP.NET 출력 캐시를 사용할 수 있습니다.
동적 콘텐츠를 위한 출력 캐시를 배포하기는 까다로우며 IIS 7.0 플랫폼의 다양한 캐싱 기능의 효율성과 유연성을 활용하는 다중 계층 전략이 필요합니다. 이를 위한 단계에는 응답에 영향을 주는 여러 매개 변수를 기술하고, 캐시의 유효성을 유지하기 위한 만료와 무효화 전략을 정의하며, 어떤 캐시가 필요한 의미 체계를 지원하는지 확인하는 등이 포함됩니다.
그러나 이러한 복잡성에 대한 대가는 충분합니다. IIS 7.0 출력 캐시를 구현하면 응용 프로그램의 전체 처리량을 최대 몇 배까지 향상시킬 수 있으며 데이터베이스와 비즈니스 계층 구성 요소에서의 부하도 이에 상응하는 수준으로 줄일 수 있습니다.

ISAPI 코드를 IIS 7.0 모듈로 변환
IIS 7.0에는 모든 IIS 7.0 모듈이 기반을 두는 새로운 서버 API가 도입되었습니다. 이 API는 IIS 이전 버전에 사용되던 기존 ISAPI 필터와 ISAPI 확장 API를 대체합니다. 이전 버전을 지원할 필요가 없는 새로운 모듈의 경우 새로운 API가 사용하기 쉽고 더 안정적인 서버 쪽 코드를 작성할 수 있도록 지원하는 것은 물론 더 강력합니다.
그러나 기존 ISAPI 필터와 확장에 대한 지원이 필요한 경우 IIS 7.0은 선택적인 IIS 7.0 모듈을 통해 구현되는 호환성 계층을 사용할 수 있는 옵션을 제공합니다. 이 옵션을 사용하면 기존 ISAPI 구성 요소를 다시 작성하지 않고도 IIS 7.0에서 사용할 수 있습니다.
기존 ISAPI 기반을 활용하면 IIS 7.0 마이그레이션에 대한 장벽을 낮출 수 있지만 레거시 ISAPI 코드를 새로운 IIS 7.0 API로 이식하는 것을 신중하게 고려해야 합니다. 코드를 이식하면 ISAPI 호환성 계층에 의한 오버헤드가 제거되고 ISAPI 구성 요소에서는 제공되지 않는 성능상의 장점을 활용할 수 있습니다. ISAPI 구성 요소에서 수행되는 작업에 따라서는 상당히 높은 수준까지 성능상의 장점을 누릴 수 있습니다. 예를 들어 IIS 7.0 모듈 API는 구성 요소 내부 작업의 속도를 크게 높일 수 있는 사이트, 응용 프로그램 및 URL과 연관된 임의의 데이터와 구성 메타데이터 캐싱을 위한 기본 제공 지원을 제공합니다.
또한 IIS 모듈 API는 모듈이 요청 엔터티 데이터 수신이나 응답 전송과 같이 오랫동안 실행되는 작업을 비동기적으로 수행할 수 있도록 허용합니다. 이러한 작업을 비동기적으로 수행할 수 있도록 허용하면 기존에는 요청 스레드의 수에 대한 제한 때문에 수십 개나 수백 개로 제한되었던 동시 클라이언트의 수를 수만 개까지 크게 확장할 수 있습니다. 비동기 프로세싱은 또한 메모리 사용량을 줄이고 CPU 사용률을 크게 개선하여 응용 프로그램에서 다른 요청과 작업을 처리하는 데 따르는 영향을 없애 줍니다.
성능에 영향을 주는 특정한 패턴을 기반으로 네이티브 API는 개발자에게 요청 처리 작업에 대한 높은 수준의 유연성을 제공합니다. 이를 통해 서버 구성 요소의 디자인을 개선하고 결과적으로 효율성을 크게 높일 수 있습니다. 예를 들어 이전에는 와일드카드 ISAPI 확장과 자식 요청 실행이 필요했던 특정 필터링 작업을 이제는 원래 요청 중에 한 모듈에서 실행하고 응답을 위해 IIS 커널 캐싱을 설정할 수도 있습니다.
이를 위해서는 마이그레이션의 장점을 극대화할 수 있는 최적의 디자인을 결정하기 위한 약간의 프로토타입 작성과 실험이 필요합니다. ISAPI와 IIS 7.0 모듈 API 간의 근본적인 아키텍처 차이 때문에 직접적인 이식 경로가 항상 올바른 방법은 아닙니다. 다행스러운 것은 IIS 7.0 모듈 API는 ISAPI보다 사용하기 쉽게 때문에 마이그레이션이 다소 수월하다는 것입니다.

서버 확장성
IIS 7.0은 완벽한 확장성을 제공합니다. 확장을 위해서는 서버 작업에 대한 상당한 수준의 사전 지식이 필요하지만 응용 프로그램별 성능 향상에 대한 막대한 가능성을 열어 줍니다. 서버 아키텍처와 요청 처리에 대한 어느 정도 지식을 갖추면 이 확장성을 활용하여 여러분의 응용 프로그램, 워크로드 및 하드웨어 요구 사항에 맞춘 사용자 지정 성능 솔루션을 설계할 수 있습니다.
이러한 솔루션을 기본 제공 IIS 7.0 기능을 사용자 지정 구현으로 대체함으로써 사용할 수 있습니다. IIS 7.0 기능은 많은 최적화와 성능 테스트를 거쳤지만 모든 사용 예에 맞게 최적화된 것은 아닙니다. 따라서 여러분의 특정 워크로드에 맞는 최적화를 작성하여 특정 모듈의 성능을 개선할 수 있습니다. 예를 들어 파일 시스템 API를 사용하여 파일을 열거하지 않고 디렉터리 목록을 메모리에 캐시하도록 디렉터리 목록 모듈을 다시 구현할 수 있습니다.
또한 확장성을 활용하여 성능 관련 기능을 새로 작성할 수 있습니다. 이러한 기능의 기본 제공 예로는 출력 캐시, 압축 모듈 및 기타 다른 내부 캐시가 포함됩니다.
사용자 지정 성능 관련 기능이 필요한지 확인하려면 사용자 응용 프로그램과 해당 워크로드의 성능 특성을 이해해야 하며 해결해야 하는 병목 현상에 대해서도 알아야 합니다. IIS 7.0에서는 필요한 기능의 요구 사항과 가능한 디자인을 명확하게 확인하기 위한 성능 분석을 수행하는 진단 지원을 풍부하게 제공합니다.

결론
IIS 7.0 릴리스는 기능 릴리스에 가깝지만 모듈식 아키텍처, 구성 기능 및 새로운 성능 기능 덕분에 높은 수준의 성능 향상을 제공합니다. 기업에서는 서버 통합, 대역폭 비용 절감은 물론 향상된 사용자 환경 제공이라는 이러한 향상된 기능을 통해 상당한 절감 효과를 거둘 수 있습니다.
이러한 많은 향상된 기능을 올바르게 활용하려면 현재 응용 프로그램 플랫폼에 대한 철저한 분석과 IIS 7.0 아키텍처에 대한 충분한 이해가 필요한 경우가 많습니다. IIS 7.0 아키텍처에 대한 자세한 내용과 이 기사에서 언급한 기능에 대해 알아보려면 iis.net을 방문해 보십시오. 필자는 블로그(mvolo.com)에서 IIS 7.0을 적극적으로 활용하여 응용 프로그램 성능을 개선하고 운영 비용을 절감하는 기술을 다루고 있습니다.
Mike Volodarsky는 이전에 Microsoft IIS 팀에서 프로그램 관리자로 일했으며 지난 5년 동안 ASP.NET 2.0과 IIS 7.0 핵심 기능의 설계와 개발을 주도했습니다. 현재 그는 IIS 7.0과 Windows Server 2008을 사용하는 고성능 웹 팜을 위한 고급 웹 서버 기술을 개발하고 있습니다. Mike는 IIS 7.0 Resource Kit의 저자로서 집필을 이끌고 있으며 MSDN Magazine과 그의 IIS 7.0 블로그(mvolo.com)에서 활발하게 글을 쓰고 있습니다.


Mobility
기간 업무(LOB) 응용 프로그램에 모바일 기능 구현
Matt Fontaine
한 눈에 보기:
  • 모바일 기간 업무(LOB) 응용 프로그램에 대한 비즈니스 요구 사항
  • mLOB 개발 및 배포를 위한 강력한 플랫폼
  • 무선 보안, 관리 및 프로비전

목차
원격 작업자 지원 및 관리
보안 및 장치 관리
상호 운용성
IT 및 사용자 생산성
개발 및 배포
결론
최근에는 기존의 음성, 메시징 및 생산성 기능 외에 모바일 기간 업무(mLOB) 응용 프로그램을 통해 모바일 근로자가 사무실에서와 같이 기간 업무(LOB)에 액세스할 수 있도록
하는 기업이 늘어나고 있습니다. 그 대표적인 시스템 활용 사례로 CRM(고객 관계 관리), ERP(엔터프라이즈 리소스 계획), BI(비즈니스 인텔리전스), 금융 및 회계 응용 프로그램 등을 들 수 있습니다. 당연한 이야기지만 mLOB 기능을 사용하면 모바일 사용자가 다양한 비즈니스 응용 프로그램에 액세스하여 사용하고 이동 중에 실시간으로 데이터 작업을 수행함으로써 영업 시간은 단축하고 고객 만족도와 업무 생산성은 높일 수 있습니다. 일반적인 비즈니스 시나리오를 소개하자면 다음과 같습니다.
  • 영업 팀은 Microsoft Dynamics™ CRM Mobile을 사용하여 어디서든 고객 데이터를 확인하고 업데이트할 수 있습니다. 또한 다른 mLOB 응용 프로그램을 통해 실시간 가격 및 재고 데이터에 액세스할 수 있을 뿐만 아니라, 영업 직원은 전용 장치를 사용하여 현장에서 주문서를 작성하거나 서명을 받는 등 영업 관련 문서를 작성할 수 있습니다. 사실 바코드를 스캔하고 신용 카드를 읽은 후 처리하기 위해 백 엔드 LOB 데이터 시스템에 연결하는 Windows Mobile® 장치용 POS(Point of Sale) 응용 프로그램도 있습니다.
  • 각 개인의 약속과 위치에 따라 담당자를 배정하는 ERP 솔루션을 활용해 현장 서비스 담당자의 일정을 관리하고, GPS 지원 Windows Mobile 장치로 현장 서비스 담당자를 자동으로 추적할 수 있습니다. 필드 서비스 직원이 매일 첫 업무만 선택하면 해당 업무 완료 시에 다음 업무가 자동으로 배정됩니다(그림 1 참조).
  • 제조업체의 경우 RFID(전파 식별) 검색 기능이 있는 Windows Mobile 장치를 RFID 지원 창고에서 재고 관리에 사용할 수 있습니다. 이 경우 데이터베이스에 무선으로 정보를 즉각적으로 채워넣을 수 있습니다. 또한 주요 안전 요구 사항에 부합하면서 거친 작업 환경에서도 데이터를 제공할 수 있는 강화 Windows Mobile 장치 또는 "본질 안전(Intrinsically Safe)" 인증을 획득한 Windows Mobile 장치도 있습니다.
  • 고객과의 회의, 임원회, 기자간담회 등을 다니며 하루 종일 집이나 사무실에서 먼 곳으로 이동이 잦은 임원은 어떤 장소에서든 재무 정보, 비용 보고서 또는 고객 정보를 받을 수 있습니다.
이 외에도 많은 비즈니스 시나리오가 유수의 회사들이 mLOB 응용 프로그램을 도입하는 계기가 되고 있습니다. 이 기사에서는 IT 전문가가 Windows Mobile 및 Mobile Device Manager를 함께 사용하여 오늘날의 비즈니스에 요구되는 다양한 모바일 기능을 배포하는 방법을 설명합니다.
그림 1 완료된 현장 서비스 작업을 보여 주는 mLOB 응용 프로그램

원격 작업자 지원 및 관리
Windows Mobile은 다양한 산업에서 원격 작업자를 지원할 수 있는 강력한 플랫폼으로 입증되었습니다. 기존 Windows® 기반 IT 자산과 문제없이 통합될 뿐만 아니라 Exchange Server 및 Office Communications Server를 통해 모바일 메시징 기능과 UC(통합 통신) 기능이 제공되고 사용자와 IT 전문가가 모두 쉽게 이해하여 사용할 수 있는 익숙한 Windows 환경을 제공하기 때문입니다.
Mobile Device Manager가 발표되면서 Windows Mobile은 비즈니스 기반 구축의 일환으로서 모바일 장치 배포 분야에서 입지를 더욱 공고히 하게 되었습니다. Mobile Device Manager는 모바일 장치를 네트워크에 연결된 PC 또는 파일 공유와 마찬가지로 Active Directory®와 그룹 정책을 사용하여 무선으로 프로비전, 관리 및 보호할 수 있도록 해줍니다. 정책과 소프트웨어를 전화로 자동으로 배포할 수 있으며, 다양한 인벤토리 보고 기능을 사용하면 보안, 소프트웨어 및 하드웨어 정책을 세부적으로 관리할 수 있습니다.
이러한 혁신의 이면에는 모바일 장치가 자체 미들웨어라는 허상 속이 아니라 IT 시스템의 자연스러운 확장의 하나로 존재해야 한다는 의식이 원동력이 되고 있습니다. Windows Mobile 장치에서 단순한 메시징, 통신 및 기본 생산성 기능 이상을 구현하려는 회사는 모바일 장치를 네트워크의 최우선 구성 요소로 만들어야 합니다.
그렇다면 이렇게 기본 기능 이상의 모바일 장치 기능을 제공하려는 회사의 IT 전문가는 어떻게 해야 할까요? Windows Mobile와 Mobile Device Manager의 몇 가지 기능으로 mLOB 응용 프로그램을 위한 플랫폼을 제공함으로써 이를 실현하는 방법을 살펴보겠습니다.

보안 및 장치 관리
mLOB 응용 프로그램의 유용한 기능(예: 때와 장소에 구애 받지 않는 고객, 재무, 재고 등과 관련한 중요 비즈니스 정보 액세스)은 보안 문제를 더욱 까다롭게 하기도 합니다. 사용자가 여러 장소에서 공용 네트워크를 통해 소형 장치로 정보를 입력하고 액세스하게 되기 때문입니다.
이미 VPN(가상 사설망) 연결 기능이 있는 랩톱을 통해 인트라넷의 다른 공유 리소스 및 도구와 마찬가지로 LOB 응용 프로그램에 액세스할 수 있도록 해 놓은 회사는 이미 많습니다. Mobile Device Manager는 이 기능을 모바일 VPN 기능이 있는 Windows Mobile 장치로 확장합니다(그림 2 참조). 또한 Mobile Device Manager Gateway Server는 Windows Mobile 클라이언트와 네트워크 간에 IPsec 암호화 터널을 설정함으로써 인터네싱나 무선 패킷 데이터 네트워크와 같은 공용 연결을 통해 회사 방화벽으로 보호되는 정보에 안전하게 액세스할 수 있도록 해줍니다. Windows Mobile은 이러한 설정에서 다양한 암호화 유형을 지원합니다.
그림 2 Mobile Device Manager를 사용한 향상된 장치 관리, 보안 및 모바일 VPN(더 크게 보려면 이미지를 클릭하십시오.)

상호 운용성
암호화 정책은 장치와 저장소 카드에 저장된 데이터에 대해 설정하고 적용할 수 있습니다. mLOB 응용 프로그램을 사용하는 작업자가 모바일 장치로 다운로드하는 기밀 정보는 다른 네트워크 장치에 비해 도용되기가 훨씬 쉽습니다. 다행히 데이터 연결 기능이 있는 모든 모바일 VPN 지원 장치에서는 원격 장치 지우기를 실행할 수 있습니다(그림 3 참조). 예를 들어 제약회사 영업 사원이 회사의 CRM 시스템에서 자신의 모바일 장치로 고객 파일을 다운로드한 다음 장치를 택시에 두고 내린다면 심각한 결과로 이어질 수 있습니다.
그림 3 모바일 장치를 분실하거나 도난당한 경우 정보를 원격으로 제거할 수 있음 (더 크게 보려면 이미지를 클릭하십시오.)
Mobile Device Manager는 이러한 문제를 해결하도록 설계되었습니다. 구체적으로 말하면 Mobile Device Manager는 Windows Mobile 장치의 기능과 사용자 정책에 대한 대부분의 측면을 관리할 수 있도록 해줍니다. 여기에는 특정 하드웨어 기능을 해제하는 것에서부터 설치 가능한 응용 프로그램을 제어하여 특정 네트워크 리소스에 대한 액세스를 제한하는 것까지 포함됩니다. 하나의 솔루션에서 이러한 모든 작업을 무선으로 수행할 수 있는 것입니다. 사용자가 mLOB 기능을 갖춘 경우에는 이러한 기능의 중요성이 더 커집니다. 예를 들어 제어되지 않는 장치로의 다운로드에 이용될 수 있는 Bluetooth 네트워킹을 사용자가 사용하지 못하도록 제한할 수 있습니다. 또한 특정 사용자만 모바일 회계 소프트웨어 클라이언트를 설치할 수 있게 제한하려는 경우에는 필요한 사용자에게만 자동으로 업로드 및 설치되도록 클라이언트를 설정할 수도 있습니다.
추가 리소스
  • Microsoft System Center Mobile Device Manager 2008
  • Microsoft System Center Mobile Device Manager 2008 소개
  • Microsoft System Center Mobile Device Manager 2008: 기술 백서
  • Microsoft System Center Mobile Device Manager 2008 기업 사용자를 위한 소개
  • Business Solution Accelerator 2008의 Windows Mobile용 제품군
또한 Mobile Device Manager는 다른 가용성을 제공하거나 보안 중단점이 될 수 있는 보안 타사 NOC(네트워크 작업 센터)를 회사 데이터 없이도 통과할 수 있습니다. 기본적으로 Mobile Device Manager는 거의 모든 규모에서 모바일 장치 배포를 완벽하게 제어할 수 있도록 해줍니다. 따라서 mLOB 기능을 쉽게 배포, 관리 및 보호할 수 있습니다.
네트워크 통합에 따른 다른 이점도 있습니다. 즉, 모바일 장치를 다른 네트워크 클라이언트와 별도로 관리할 필요 없이 Active Directory와 그룹 정책을 이용하여 매우 세부적으로 제어할 수 있습니다. 결과적으로 비용과 시간이 절감됩니다. 그러나 무엇보다 점은 일관된 보안 및 액세스 정책을 적용할 수 있다는 사실입니다. 그룹 정책을 사용하면 LOB 데이터에 대한 모바일 액세스를 매우 효율적으로 제어할 수 있습니다. 액세스가 필요한 사용자에게는 손쉽게 액세스를 제공하고 다른 사용자는 일괄적으로 또는 개별적으로 제한할 수 있습니다.
mLOB 배포(일반적으로 말해서 모바일 장치)를 관리하는 데 있어서는 기존 인프라와의 상호 운용성도 고려해야 합니다. 일부 모바일 장치 운영 체제는 Windows Mobile과 달리 다른 IT 형태와 일관성이 없어 자체 언어, 서버 및 도구를 필요로 합니다. 이러한 요인은 모바일 장치에서 복잡한 응용 프로그램과 중요 데이터 액세스를 제공할 때 특히 중요합니다.
Windows Mobile과 Mobile Device Manager는 바로 이러한 상호 운용성을 제공합니다. Windows Mobile은 Windows OS로서 Microsoft® Exchange Server, Microsoft Forefront™, SQL Server®, Microsoft Office Communications Server 등의 다른 Windows 기반 IT 자산과 문제없이 함께 사용할 수 있습니다. 이러한 제품군 내 상호 운용성은 새로운 mLOB 기능을 쉽게 설계하고 빌드할 수 있는 기반이 됩니다.
예를 들어 응용 프로그램 간 통신을 가능하게 하는 Microsoft .NET Framework 기술인 Windows Communication Foundation(WCF)의 경우 SOA(서비스 지향 아키텍처)를 활용한 mLOB 구현에서 Exchange Server를 메시지 전달 유틸리티로 사용할 수 있도록 해줍니다. 간헐적으로 연결하는 작업자는 새로운 Sync Framework를 사용하여 최신 데이터를 유지할 수 있습니다. 이 기술은 SQL Server Compact 3.5와 SQL Server 2008의 회사 데이터를 사용하여 Windows Mobile 장치 간에 데이터를 손쉽게 동기화할 수 있도록 해줍니다. 다양한 기본 네트워크 리소스와 함께 사용할 수 있는 모바일 인프라가 없다면 이러한 시나리오를 구현하기가 훨씬 어려울 겁니다.

IT 및 사용자 생산성
생산성 향상은 mLOB 배포의 중요한 목표 중 하나입니다. 하지만 기능이 작업자가 사용하기 어렵고 IT 전문가가 관리하기도 힘들다면 얻어지는 이점에 비해 비용이 턱없이 높거나 ROI(투자 수익률)을 떨어뜨릴 수 있습니다. Windows Mobile 개발 시에는 가능한 한 데스크톱 Windows 환경에 가깝게 만드는 것을 목표로 합니다. 친숙한 환경은 사용자나 IT 전문가 모두에게 있어서 솔루션의 가치를 높여 줍니다.
IT 측면에서 보면 Mobile Device Manager를 사용하는 Windows Mobile은 Windows Mobile 장치를 일반 네트워크 환경으로 가져오도록 설계되었다고 할 수 있습니다. 이러한 기능은 친숙한 기능, 특히 Active Directory와 Windows Server®를 사용하여 구현됩니다. Mobile Device Manager는 전세계의 많은 IT 전문가가 사용하는 IT 관리 솔루션 중 System Center 계열에 속합니다. Windows 기반 환경에 익숙한 IT 전문가는 전혀 생소한 도구와 사용 방법을 익힐 필요 없이 이미 잘 알고 있는 Microsoft Management Console 스냅인을 사용할 수 있습니다.
사용자의 입장에서도 마찬가지입니다. 데스크톱과 유사한 Windows Mobile의 사용 환경은 빨리 익히는 데 도움이 됩니다. Office Mobile Outlook®을 포함한 Office Mobile 제품군을 사용하여 새 응용 프로그램을 배우지 않고 바로 작업을 수행할 수 있습니다. 장치 관리도 중앙 집중식으로 이루어지므로 신경 쓸 필요가 없습니다. mLOB 응용 프로그램은 같은 프로그램의 데스크톱 버전 사용자에게 익숙한 방식으로 작동하도록 설계할 수 있으며, 새 도구의 모양이나 동작 방식을 일반 Windows 소프트웨어와 유사하게 만들 수 있습니다. 사용자에게 익숙한 환경은 결과적으로 지원 요청을 줄이고 지원 사례의 심각도를 낮춰 IT 전문가에게도 도움이 됩니다.
생산성 향상에 기여하는 Windows Mobile과 Mobile Device Manager 플랫폼의 측면은 이뿐만이 아닙니다. 모바일 VPN은 빠른 다시 연결 기능을 제공하는 것은 물론이고, 여러 네트워크 간에도 원활하고 일관된 연결을 제공하기 때문에 사용자가 필요할 때 쉽게 연결할 수 있어 사용자가 자주 문의하는 지원 부서 문의 사항을 줄입니다. Windows Mobile에서는 다양한 장치 사양이 지원되므로 회사에서 적은 수의 장치에 표준화하면서도 직원이 필요한 장치를 선택할 수 있도록 충분한 선택의 폭을 제공할 수 있습니다. 이러한 장치의 다양성도 바코드 기반 재고 관리 시스템이나 GPS 지원 장치를 사용한 경로 추적 시스템과 같은 mLOB 시나리오에서 생산성 향상 요인이 됩니다.

개발 및 배포
데이터의 다양성, 성능, 전문화된 기능 등 LOB 응용 프로그램을 정의하는 특징은 대개 응용 프로그램 기반 생산성에 주안점을 두고 설계된 모바일 플랫폼에서 가장 잘 나타납니다. Windows Mobile은 모바일 작업자에게 데스크톱과 유사한 환경을 제공합니다. 이는 곧 mLOB 응용 프로그램을 쉽게 개발, 배포 및 관리할 수 있음을 의미합니다.
우선 Windows Mobile은 .NET Compact Framework라는 .NET 버전을 지원합니다. .NET Framework는 전세계 수백 만 개발자가 사용하는 프로그래밍 도구 집합으로, 이미 많은 IT 부서에서 맞춤형 Windows Mobile용 mLOB 응용 프로그램 개발에 필요한 기술을 내부적으로 갖추고 있습니다. 그렇지 않은 경우에도 바로 활용이 가능한 기술이 시중에서 제공되고 있습니다.
또한 Windows Mobile은 상용으로 판매되는 많은 mLOB 응용 프로그램을 지원합니다. Microsoft의 경우 Microsoft Dynamics CRM Mobile, Microsoft Dynamics AX Mobile Sales 등의 mLOB 솔루션을 Microsoft Dynamics 제품군의 일부로 제공하고 있습니다. 뿐만 아니라 Microsoft Dynamics Mobile 개발 도구는 소프트웨어를 모바일 환경으로 확장하는 데 필요한 기술을 제공합니다. Microsoft는 곧 발표될 Microsoft Dynamics NAV 지원을 통해 앞으로 다른 Microsoft Dynamics 솔루션까지 모바일 지원을 확대할 예정입니다. 또한 SAP, Siebel, PeopleSoft, SalesForce.com 등 주요 LOB 솔루션은 대부분 Windows Mobile 호환 버전으로도 제공됩니다.
구입하거나 개발한 mLOB 응용 프로그램은 Mobile Device Manager와 Windows Server Update Services 3.0을 사용하여 무선으로 배포하고 관리할 수 있습니다. 그리고 응용 프로그램을 수신할 장치와 장치에서 액세스 가능한 기능은 그룹 정책을 통해 설정할 수 있습니다. 응용 프로그램 업데이트도 같은 방식으로 손쉽게 수행할 수 있습니다.

결론:
직원과 임원에게 mLOB 응용 프로그램을 제공하는 회사가 늘면서 모바일 기능은 IT 시스템의 배포와 관리를 담당하는 IT 전문가에게 새로운 과제가 되고 있습니다. Windows Mobile과 Mobile Device Manager는 네트워크 지원 모바일 장치라는 비전을 바탕으로 관리하기 쉬운 mLOB 개발 및 배포 플랫폼을 제공합니다. 이러한 플랫폼은 IT 부서의 부담과 인프라 투자를 최소화하는 동시에 보안 기능과 사용자 생산성은 극대화합니다. 대규모 사용자까지 mLOB 배포 범위를 확대할 수 있는 Mobile Device Manager는 사용자당 소요되는 mLOB 개발 및 배포 비용을 줄이면서 사용자당 ROI는 증대시킵니다. 결과적으로, Mobile Device Manager를 사용하여 Windows Mobile을 관리함으로써 초기에 구축 방법을 고민하는 대신 mLOB 응용 프로그램을 최대한 효과적으로 사용할 방안을 찾는 데 집중할 수 있습니다.

Matt Fontaine은 워싱턴주 시애틀에서 작가이자 컨설턴트로 활동하고 있습니다. Matt는 고성능 컴퓨팅, 기업 소프트웨어, 보험 수리, 상업용 부동산, 엔지니어링, 건설, 소비재 등의 다양한 분야에서 활동 중이며 Evergreen State College를 졸업한 인재입니다.


Security
공유 계정 암호 관리의 이해
Chris Stoneff
한 눈에 보기:
  • 공유되고 권한이 부여된 계정 암호의 위험성
  • 암호가 저장되는 방법
  • 공유 암호 관리 및 보안
  • 규정 준수

목차
문제의 이해
길수록 강력해지는 암호
도메인에서의 위험성
다양한 변명들
감사관이 원하는 것
자동화된 방법
고려할 내용
관리자가 반드시 해결해야 하는 일반적인 문제 중 하나로
기본 제공 관리자이나 루트 계정, 파이어콜(firecall) 계정 또는 심지어 프로세스 계정과 같은 공유되고 권한이 부여된 계정의 암호를 주기적으로 변경하는 것이 있으며 이러한 문제의 중요성은 날로 높아지고 있습니다. 정의를 내리자면 기본 제공 관리자 또는 루트 계정은 모든 Windows®, Linux 및 UNIX 버전에서 제공되는 계정이며 항상 동일한 SID(보안 식별자)나 UID(사용자 식별자)를 가집니다. 파이어콜 계정은 보안 시스템에 대한 응급 액세스를 원활하게 수행하도록 지원하기 위해 만드는 다른 계정입니다. 이러한 파이어콜 또는 관리자 계정은 가끔 문제가 발생하는 경우 권한이 없는 사용자가 핵심 시스템에 대한 액세스를 얻는 데 사용됩니다. 마지막으로 프로세스 계정은 서비스, 작업, COM+ 응용 프로그램, 그리고 로그인이 필요한 스크립트 및 다른 이진 파일과 같은 포함된 항목을 실행하는 데 사용되는 계정입니다.
지금은 설치 스크립트나 이미지를 사용하여 시스템을 배포하는 경우가 많습니다. 게다가 모든 워크스테이션이나 서버의 관리자 계정 이름이 같고 시스템을 처음 배포한 이후로 변경하지 않은 동일한 8문자 암호가 설정되어 있는 경우가 많습니다. 여기에서 문제는 동일한 하나의 암호가 사용된다는 것입니다.
관리자는 모범 사례를 따르거나 SOX(Sarbanes-Oxley), PCI(Payment Card Industry) 또는 HIPAA(Health Insurance Portability and Accountability Act)에서 요구되는 규정 준수 요구 사항을 충족하기 위해 암호를 변경합니다. 이 밖에도 이러한 암호를 알고 있는 이전 관리자나 기술자가 퇴사하거나 보안 위반이 알려질 우려가 있거나 또는 신용 카드 가맹점 자격을 잃을 우려 때문에 관리자가 나서서 암호를 변경하기도 합니다. 이러한 요인에도 불구하고 결국 회사 자체 및 회사에서 보호해야 하는 데이터에 대한 단순한 보안을 위해 이러한 암호를 변경하는 일은 관리자의 몫입니다.

문제의 이해
이러한 계정 및 해당 암호를 처리할 때 이해해야 할 몇 가지 요인이 있습니다.
  1. 암호가 오래될수록 암호의 보안성은 저하됩니다.
  2. 일반적으로 암호가 길수록 해독하기 어렵습니다.
  3. 컴퓨터가 도메인에 속해 있더라도 인증 방법이 달라지지는 않습니다. 모든 도메인에는 작업 그룹의 핵심이 있습니다.
"암호가 오래될수록 암호의 보안성은 저하됩니다."라는 내용에는 오해의 소지가 있습니다. 이 문장의 실질적인 의미는 컴퓨터에 칩입하려는 의지가 있다면 정말로 필요한 것은 시간뿐이라는 것입니다. 암호를 해독하는 데 시간이 얼마나 걸리는지 묻는 질문에 대한 명확한 대답은 일반적으로 없다고 할 수 있지만 특정 시스템에 해당하는 답을 알아내는 데 도움이 되는 몇 가지 힌트가 있습니다.
  • 암호를 아는 사람이 몇 명입니까?
  • 이들이 아직 회사에서 일하고 있습니까?
  • 계정 암호를 아는 사람이 퇴사했다면 이들이 퇴사할 때 우호적이었습니까?
  • 플로피 디스크, CD 또는 DVD 드라이브, 네트워크로부터의 부팅을 금지하고 있습니까?
  • 컴퓨터의 사용자가 로컬 관리자이기도 합니까?
  • 사용자의 모든 시스템이 해당 시스템의 권한이 부여된 계정에 완전히 같은 암호를 사용하고 있습니까?
목록 맨 위의 항목부터 시작하면, 비밀을 아는 사람이 많아지면 그것은 더 이상 비밀이 아니라고 할 수 있습니다. 필자가 예전에 근무하던 한 회사에서는 관리자가 편의를 위해서 공유 암호를 동일하게 설정하고, 다른 사용자가 요청할 때 자신이 암호를 대신 입력해 주기보다는 인턴을 포함한 모든 IT 직원에게 암호를 알려 주었습니다. 시간이 지나면서 이 회사에서는 승인되지 않는 다양한 설정을 가진 시스템이 생겼으며 일반적인 네트워크 사용자가 이러한 계정에 로그인하는 경우도 많아졌습니다.
암호를 아는 사람이 모두 회사에서 근무하고 있고 회사에 만족하는 성실한 직원이라면 이 액세스 위험은 다소 완화됩니다. 그러나 불만을 품은 악의적인 사용자가 있을 수도 있습니다. 이러한 사용자 중 누구라도 좋지 않은 감정을 가지고 회사를 떠난다면 추적할 수 없는 계정으로 여러분의 네트워크에 칩입할 수 있는 악의적 요소가 생기는 것입니다.
하드 디스크 외의 다른 방법을 통한 부팅을 금지하지 않으면 컴퓨터의 파일 시스템에서 직접 읽기를 수행하고 컴퓨터의 보안 저장소에 액세스할 수 있는 Windows PE나 다양한 Linux 시스템과 같은 승인되지 않은 이미지를 사용하여 부팅할 수 있도록 허용하는 것이나 다름이 없습니다. 침해의 많은 부분이 내부 요소에서 발생한다는 점을 알아 두십시오. 모든 직원과 인턴이 회사에서 근무하고 있더라도 암호와 시스템이 안전하다는 보장은 없습니다.
필자는 이전에 근무하던 회사의 네트워크에 거리낌 없이 로그온하는 사람들을 자주 보았습니다. 시스템 암호를 변경하지 않는 잘못된 정책을 지적한다는 긍정적인 측면도 생각할 수 있긴 하지만 이들이 악의를 가지고 있을 경우 가할 수 있는 피해를 생각하면 가볍게 볼 수 없는 문제이기도 합니다.
사용자가 DVD나 네트워크를 통해 부팅하는 것을 금지하지 않으면 사용자가 하는 일을 감사할 수 없습니다. 즉, 사용자가 Linux 부트 디스크나 네트워크 이미지를 사용하여 파일 시스템에 직접 액세스할 수 있게 됩니다. 시스템에서 권한이 부여된 계정에 같은 사용자 이름과 암호를 사용한다면 심각한 문제를 자청해서 불러들이는 것이나 마찬가지입니다. 이 부분에 대해서는 뒤에서 다시 설명하겠습니다.
암호 사용 기간과 길이는 암호를 해독하는 데 사용되는 방법과 관련이 있습니다. 무차별 공격으로 암호를 알아내는 경우에는 무엇보다 시간이 중요한 요소입니다. 암호 사용 기간이 길어질수록 크랙커가 암호를 해독에 사용할 수 있는 시간대도 길어집니다.
비슷하게 암호가 길어질수록 문자 조합이 기하급수적으로 늘어나므로 암호를 해독하는 데 더 많은 시간이 소요됩니다. 따라서 암호의 길이를 7자 미만으로 할 것인지, 8-14자로 할 것인지, 또는 15자 이상으로 할 것인지 고려하는 것이 중요합니다. Windows를 사용하고 있고 암호가 15자 미만이라면 시스템 구성 과정의 일부나 그룹 정책에 따라 LM(LAN Manager) 해시를 비활성화했는지도 확인해야 합니다.
암호의 길이가 어떻게 다른 부분에까지 영향을 주는 것일까요? Windows의 경우에는 그 이유가 간단합니다. Microsoft 해싱 프로세스의 역사는 생략하고 본론으로 넘어가면, Microsoft는 암호를 위한 두 가지 유형의 해시로 LM 해시와 MD4(메시지 다이제스트 4) 해시를 구현합니다. Microsoft는 기본적으로 LM 해시를 사용하는데 명시적으로 이러한 해시 저장을 비활성화하지 않으면 14자까지의 모든 암호에 대한 해시를 저장합니다. 이러한 암호는 그림 1에 나와 있는 것처럼 처음 부분과 나중 부분이 모두 7문자로 구성된 두 개의 7문자 값으로 나누어집니다.
그림 1 샘플 해시 테이블
계정 이름 | RID | LM 해시 | NT 해시 | 암호 | 참고
Administrator | 500 | aad3b435b51404ee: aad3b435b51404ee | 31d6cfe0d16ae931: b73c59d7e0c089c0 | 빈 암호 | LM 해시는 20자 암호 LM 해시와 동일합니다.
Administrator | 500 | 0182bd0bd4444bf8: aad3b435b51404ee | 328727b81ca05805: a68ef26acb252039 | 7문자 암호 = 1234567 | 처음 7문자를 나타내는 처음 부분이 8문자 암호와 동일합니다.
Administrator | 500 | 0182bd0bd4444bf8: 36077a718ccdf409 | 0182bd0bd4444bf8: 36077a718ccdf409 | 8문자 암호 = 12345678 | 처음 7문자를 나타내는 처음 부분이 8문자 암호와 동일하지만 나중 부분은 다릅니다.
Administrator | 500 | aad3b435b51404ee: aad3b435b51404ee | b79d07c2ecb3d565: 033ece663f5a0b2e | 20문자 암호 = 9876543210 9876543210 | 암호가 14문자보다 긴 경우에는 LM 해시를 만들 수 없기 때문에 LM 해시가 빈 암호와 동일합니다.
Fred | 1221 | e52cac67419a9a: 224a3b108f3fa6cb6d | 8846f7eaee8fb117: ad06bdd830b7586c | 동일함 | 이러한 세 가지 예에서 LM 및 NT 해시가 동일한 것을 확인할 수 있습니다. 이러한 모든 계정에 대해서 암호가 모두 동일하다는 것을 의미합니다. Microsoft는 해싱 알고리즘에 변화를 적용하지 않습니다.
Monday | 1385 | e52cac67419a9a: 224a3b108f3fa6cb6d | 8846f7eaee8fb117: ad06bdd830b7586c | 동일함
SvcAcctX | 1314 | e52cac67419a9a: 224a3b108f3fa6cb6d | 8846f7eaee8fb117: ad06bdd830b7586c | 동일함
즉, 7문자 길이 암호는 단일 LM 해시에 보관됩니다. Microsoft에서는 오랫동안 암호에 최소한 8문자를 사용하도록 권장해 왔습니다. 이렇게 하면 8번째 문자 때문에 암호를 두 개의 LM 해시 값으로 나누어야 하기 때문입니다.
중요한 것은 LM 해시가 널리 파악되고 있으며 매우 쉽게 이를 우회할 수 있다는 사실입니다. 현재 솔루션에서 LM 해시를 사용하는 것은 단지 Windows NT® 4.0과 같은 이전 버전에 대한 호환성을 유지하기 위해서 입니다.
이제는 15문자 이상의 암호를 사용해야 하며 아예 LM 해시를 생성하지 않도록 이보다 긴 암호를 사용하는 것도 고려할 수 있습니다. 여러분의 환경에서 15문자 암호를 요구하는 데 무리가 있는 경우에는 이미지 생성 프로세스(로컬 정책 사용)와 Active Directory® 그룹 정책에서 모두 LM 해시 저장을 비활성화해야 합니다.
이 정책은 Computer Configuration(컴퓨터 구성)\Windows Settings(Windows 설정)\Security Settings(보안 설정)\Local Policies(로컬 정책)\Security Options(보안 옵션)에 있습니다. "네트워크 보안: 다음 암호 변경 시 LAN Manager 해시 값 저장 안 함" 정책을 사용으로 설정하면 됩니다.
대/소문자와 숫자 또는 특수 문자를 함께 사용하도록 요구하는 것도 좋은 정책이지만 이보다 15문자 이상을 사용하도록 요구하는 것이 더 좋은 정책입니다.

길수록 강력해지는 암호
컴퓨터에 침입하기 위한 최근의 방법 중 하나인 레인보우 테이블은 LM 해시를 사용합니다. 그러나 암호가 길면 레인보우 테이블의 효과가 감소합니다.
보안을 담당하는 관리자 중에서 레인보우 테이블을 잘 모르거나 혹은 아예 모르는 사람들이 많다는 사실은 상당히 놀라운 일입니다. 다양한 알고리즘을 처리하기 위한 레인보우 테이블을 만드는 여러 가지 방법이 있지만 이러한 테이블은 기본적으로 0-14 문자의 모든 LM 해시를 포함하는 미리 계산된 목록입니다.
레인보우 테이블을 사용하려면 공격자가 먼저 LM 해시를 입수해야 합니다. 앞에서 설명한 대로 CD나 DVD를 통해서 시스템을 부팅할 수 있거나 사용자가 로컬 관리자인 경우에는 pwdump와 같은 무료 도구를 사용하여 간단하게 LM 해시를 추출할 수 있습니다. 그런 다음 레인보우 테이블을 사용하여 해시를 검색하여 암호를 알아낼 수 있습니다.
여러분의 호기심을 충족시키기 위해서 필자는 시스템의 기본 제공 관리 계정 암호를 설정해 보았습니다. 암호의 길이는 14문자로 설정하고 다양한 대/소문자와 특수 문자, 숫자를 모두 포함하도록 했습니다. 그런 다음 인터넷에서 무료로 레인보우 테이블을 다운로드하고 필자의 시스템에서 모든 계정에 대한 암호 해시를 추출한 다음 관리자의 암호를 알아내는 데 걸린 시간은 2분도 되지 않았습니다.
실제로 처음 LM 해시를 해독한 다음 이어서 나중 해시를 해독하고 이렇게 다시 암호를 얻는 과정을 직접 보면 멋있다는 생각까지 듭니다. 다시 정리하자면, 앞서 설명한 대로 정책을 통해 LM 해시를 비활성화했다면 이러한 공격 방향은 아예 차단되거나 크게 제한됩니다.

도메인에서의 위험성
도메인이 문제를 해결해 주지는 않습니다. 도메인 안에 있는 컴퓨터도 여전히 같은 방법으로 인증해야 합니다. 그리고 앞에서 이야기했듯이 모든 도메인에는 작업 그룹의 핵심이 있습니다. 항상 명백하게 이를 확인할 수 있는 것은 아닙니다. 필자는 이 주제로 많은 대화를 나누었는데 그때마다 관리자들에게 시스템에 액세스하는 데 필요한 사용자 이름과 암호라는 두 가지 요소를 강조하게 됩니다. 작업 그룹에서 Windows가 어떻게 작동하는지에 대해서 먼저 살펴보아야 할 것 같습니다.
시스템에 액세스하려면 원격 시스템에 대한 사용자 이름과 암호를 제공해야 합니다. Windows는 통합된 인증을 사용하여 여러분 대신 이 작업을 수행합니다. 이것은 다른 Windows 시스템에 액세스하는 경우 Windows는 현재 로그인한 사용자 이름과 암호를 사용한다는 것을 의미합니다. 다른 Windows 시스템에 액세스하는 경우 원격 시스템에 동일한 사용자 이름과 암호가 있으면 사용자 이름과 암호를 묻는 메시지를 표시하지 않습니다.
이러한 기능을 통과 인증이라고도 합니다. 이 프로세는 도메인 간은 물론 작업 그룹에서도 작동합니다. 최악의 경우에는 시스템에서 사용자 이름과 암호를 묻지만 간단하게 사용자의 로그온 정보를 다시 입력하면 됩니다.
워크스테이션이나 서버를 도메인에 등록하여 Active Directory가 중앙 계정 리포지토리가 되더라도 이러한 시스템에서 모든 로컬 SAM(보안 계정 관리자)이나 로컬 계정 저장소가 저절로 사라지지는 않습니다. 이러한 로컬 SAM은 이제 관리와 보안의 대상에서 벗어나기 때문에 오히려 문제의 온상이 됩니다. 여러분의 시스템에서 기본 제공 관리자 계정이나 루트 계정을 마지막으로 변경한 것이 언제입니까? 더구나 모든 계정의 암호 사용 기간을 보여 주고 결과가 감사를 통과하는지 확인하는 보고 유틸리티를 다운로드하여 실행한 경우는 더 드물 것입니다.
여러분이 직접 확인해 보려면 도메인 워크스테이션 중 하나에서 관리자 권한이 있는 도메인 계정으로 로그온해 보십시오. 사용자의 시스템에서 시스템 관리를 열고 ToldYouSo라는 로컬 사용자 계정을 만듭니다. 계정에 이름을 지정하고 이를 사용자 시스템의 로컬 관리자 그룹에 추가합니다. 이제 이 과정을 두 번째 도메인 시스템에서 반복합니다.
이제 두 시스템 중 하나에서 로컬 ToldYouSo 계정으로 로그온한 다음 두 번째 시스템에 액세스하여 \\systemName\c$로 이동해 보십시오. 관리자 공유 위치에 액세스할 수 있는 것은 물론이고 암호를 입력할 필요조차 없습니다! 너무 놀라지는 마십시오. 그러나 심각한 문제인 것은 사실입니다. 다시 반복하자면 시스템이 도메인에 속해 있다고 해도 이러한 모든 시스템은 여전히 작업 그룹에 속해 있는 것처럼 작동합니다.
공유 및 권한이 부여된 계정 암호를 거의 바꾸지 않거나 아예 바꾸지 않는다면 여러분이 공유 및 권한이 부여된 계정은 위험에 노출되어 있는 것입니다. 이 경우에는 시간만 있으면 여러분의 전체 네트워크를 손상시킬 수 있습니다.

다양한 변명들
여러 관리자와 심지어 CIO들과 이야기를 나누어 보면 이러한 계정 암호를 변경하지 않는 몇 가지 같은 이유를 들을 수 있었습니다.
  • 시스템은 너무 많고 이러한 계정을 변경할 시간이나 인력이 부족합니다.
  • 예산이 부족합니다.
  • 관리자 계정을 완전히 사용할 수 없게 비활성화했습니다.
  • 아직 피해를 입은 적이 없기 때문에 문제라고 생각하지 않습니다.
  • 감사자도 알아차리지 못하는 것 같습니다.
처음 두 가지 이유에 대해서는 필자도 공감하지만 올바른 변명은 아닙니다. 어떤 이유에서든지 이러한 문제를 해결하지 않는 회사에서 필자의 개인 정보를 저장한다고 생각하면 두려워질 정도입니다.
네트워크에 있는 모든 시스템에 민감한 정보가 저장되는 것은 아니지만 이러한 컴퓨터의 사용자는 여러분의 주민 등록 번호나 의료 정보 또는 재무 정보와 같은 중요한 정보에 액세스할 수 있습니다. 시스템의 관리자인 사용자는 키 로거와 화면 캡처 유틸리티를 설치하고 그룹 정책 적용을 중단하며 다양한 하위 시스템에 shim을 추가하여 데이터를 캡처하고 전송하는 등 다양한 작업을 할 수 있습니다. 게다가 사용자가 개별 컴퓨터 수준에서 Administrator라는 이름으로 이러한 작업을 하기 때문에 이러한 악성 사용자를 감지하기가 어렵습니다.
Windows에서 기본 제공 관리자 계정을 비활성화하더라도 계정으로 로그온할 수 있다는 것을 알고 있습니까? 궁금하다면 지금 시스템을 안전 모드로 다시 시작하고 기본 제공 관리자 계정으로 로그온해 보십시오. 원래 이미지에서 계정에 할당된 암호를 사용하면 로그온할 수 있을 것입니다. 이러한 동작에 대한 자세한 내용은 Microsoft® 기술 자료 문서 "HOWTO: Administrator 계정을 해제한 후 컴퓨터에 액세스하기"(support.microsoft.com/kb/814777)를 참조하십시오.

감사관이 원하는 것
SOX, PCI, HIPAA 및 기타 규정을 맞추는 일은 상당히 까다롭습니다. 이들의 요구 사항은 포괄적이고 명확하게 정의되지 않기 때문에 이를 이해하기가 쉽지 않습니다. 일반적으로 이러한 규정에서 요구하는 사항은 다음과 같이 요약할 수 있습니다.
첫째, 모든 권한이 부여된 계정과 정보에 항상 액세스할 수 있도록 보장하고 이를 증명할 수 있는 방법을 마련해야 합니다. 이 요구 사항을 충족하면 모든 시나리오에서 바람직한 결과를 가져옵니다. 권한이 부여된 계정은 임의의 시스템에 무엇이든지 할 수 있는 권한이 있는 계정입니다. 말하자면 기본 제공 관리자 계정, 파이어콜 계정, 그리고 전체 지원 부서 직원과 모든 관리자가 알고 있는 계정입니다.
이러한 공유 계정 암호를 관리하는 솔루션을 구현하도록 선택하면 현재는 존재하지 않는 기본 제공 관리자 계정에 대한 감사 내역을 만드는 것입니다. 즉, 유동적인 암호를 사용하게 되며 솔루션이 자동화되므로 이러한 암호를 변경하느라 소중한 작업 시간을 허비할 필요도 없습니다. 궁극적으로 이러한 솔루션은 감사 기능을 제공하므로 회사가 감사를 통과하는 데도 유리합니다.

자동화된 방법
이러한 계정을 처리하는 가장 효과적인 방법은 주기적으로 계정을 변경하여 두 계정이 같은 암호를 공유하지 않도록 하는 것입니다. 암호가 공유되는 경우 하나의 시스템을 손상되면 다른 시스템도 손상될 수 있다는 의미입니다. 다른 말로 하면 공통적인 로컬이나 도메인 계정을 없애야 합니다.
이러한 암호를 관리하고 불규칙화할 수 있는 자동화 솔루션을 마련할 때는 감사자가 요구하는 최소한의 조건만 충족하는 것에서 만족해서는 안 됩니다. 예를 들어 부가적인 노력 없이도 15, 20 또는 127문자 암호를 사용할 수 있다면 8문자 암호에 만족할 이유가 없습니다(그림 2 참조).
그림 2 자동화를 통해 매우 긴 암호 생성 (더 크게 보려면 이미지를 클릭하십시오.)
또한 그림 3과 같이 권한이 부여된 계정을 매일 불규칙화하는 것도 고려해 볼 수 있습니다. 매달이나 보름 심지어 매일도 할 수 있는 일을 90일마다 할 이유는 없습니다. 무엇보다 절차를 자동화하므로 여러분이 추가로 작업할 필요가 없습니다. 또한 주기적으로 계정을 불규칙화하면 사용자가 도구의 감사되는 검색 인터페이스를 통해 암호를 접수하도록 할 수 있으므로 이전에는 없었던 감사 내역이 추가됩니다. 암호를 적은 봉투를 누군가의 사무실 한쪽에 있는 금고에 저장했다면 이러한 암호에 대해서는 암호 관리 솔루션과 같은 감사 내역을 제공할 수가 없습니다.
그림 3 권한이 부여된 계정을 매일 불규칙화 (더 크게 보려면 이미지를 클릭하십시오.)
마지막으로 사용자가 암호를 접수한 다음에는 일정 기간이 지나면 암호를 다시 불규칙화하도록 할 수 있습니다. 여기에서는 앞서 설명한 예약된 불규칙화를 이야기하는 것이 아니며, 몇 달이 아니라 단 몇 시간만 유효한 일회용 암호를 말하는 것입니다. 이 방법 역시 사용자가 도구의 감사되는 검색 인터페이스에서 암호를 접수해야 하므로 감사 내역이 제공됩니다.

고려할 내용
공유 계정 암호 관리의 문제는 반드시 해결해야 합니다. 즉, 여러분의 암호를 안정적이고 정기적으로 변경할 수 있는 방법을 마련해야 합니다. 이 솔루션은 확장 가능하고 유연해야 합니다. 이 솔루션은 암호에 대한 안전한 액세스를 제공해야 하며, 도구에서 수행한 모든 동작과 모든 도구 사용자가 수행한 동작을 감사할 수 있어야 합니다. 또한 공유된 계정 정보로 인한 침입을 방지할 수 있도록 모든 시스템에 고유한 암호를 생성해야 합니다.
여러 해 동안 많은 공급업체가 이 문제를 해결하기 위해 진출했으며 앞으로도 많은 공급업체가 이 분야에 진출할 것입니다. 모든 새로운 도구에 대해 충분히 조사하고 확인하여 여러분의 환경에 맞는 솔루션을 선택하십시오.

Chris Stoneff는 Lieberman Software(liebsoft.com)의 제품 관리자이자 보안 및 시스템 관리 소프트웨어 개발자입니다. 그의 이러한 추진력을 뒷받침하는 가장 큰 힘은 어떤 일이 특정한 방향으로 일어나는 방식뿐만 아니라 그 이유에 대해서까지 알아내고자 하는 열정입니다.


최근 몇 주 동안 필자는 운 좋게도 IT 전문가 업무에 대한 재교육 과정을 수료할 기회가 있었습니다. 여름이 막바지에 접어들면소 이렇게 기본으로 돌아가 보는 것은 상당히 좋은 기회였습니다. 그러나 동시에 다소 놀라운 경험이기도 했습니다.
여러분도 아시다시피 Microsoft Magazine 팀(MSDN Magazine과 TechNet Magazine 발행을 담당하는 그룹)은 기존 프로세스를 검토하고 향상하는 과정을 진행 중에 있습니다. 이제는 남아 있는 종이 레이아웃과 색연필 표시를 버리고 완전히 디지털 방식으로 전환하기로 결정한 것입니다. 나름 혁신적이지 않습니까! 이제는 효율성을 높일 수 있다고 하는 이러한 큰 회사들의 선전에도 귀를 기울일 때가 되었다고 생각되었습니다.
새로운 디지털 워크플로를 조정하는 과정에서 우리는 기사의 상태를 추적하는 도구 때문에 작업이 더뎌지고 있다는 것을 깨달을 수 있었습니다. 이 도구는 이미 디지털 방식이었지만 매우 구식 기술에 기반을 두고 있었으며 각 레이아웃 위에 인쇄된 작은 색 상자로 보완하는 방식이었습니다. 첨단 기술과는 거리가 멀지 않습니까? 그래서 필자는 개념 증명 대안을 구상하기 시작했고, SharePoint가 최적이라는 사실을 발견했습니다.
결론부터 말하자면 SharePoint 관리자에 대한 새로운 존경심이 싹트는 계기가 되었습니다. SharePoint 플랫폼의 강력함이나 기능에 대해서는 이미 알고 있었기 때문에 처음 접하는 것은 아니었지만 SharePoint에서 사용자 지정 워크플로 솔루션을 만드는 것은 정말 어려웠습니다! 다행스러운 것은 새로운 Inside SharePoint 칼럼의 도움을 받을 수 있었다는 것입니다. 일선에서 손을 뗀 지 몇 년 만에 직접 이 과제를 해결하기 위해 뛰어드는 데는 용기가 필요했지만 필자에게는 다시 기본으로 돌아갈 필요가 있었습니다.
기본적인 내용을 살펴보려는 경우는 물론 새로운 기술을 배우려는 경우에도 TechNet의 새로운 "How Do I?" 비디오 시리즈(technet.microsoft.com/cc138021)를 비롯하여 Magazine(.com/video)에서 제공하고 있는 스크린캐스트, 그리고 TechNet Edge(edge.technet.com)에 이르기까지 다양한 리소스가 준비되어 있습니다. 그러나 지금은 TechNet Magazine 자체에서 우리의 "기본"을 확장할 시기인 것 같습니다. 자랑같지만 지금까지 우리는 심층적인 기술 정보를 제공하는 데 상당히 많은 성과를 거두었습니다. 그러나 이따금 기본적인 내용을 다시 돌아보는 것도 도움이 된다고 생각합니다. 남은 여름을 즐겁게 보내시기를 바랍니다. 이제 기본으로 돌아갈 시간이 얼마 남지 않았습니다. —Joshua Hoffman

도움을 주신 Microsoft 기술 전문가: Nathan Bigman, Nino Bilic, Mai-lan Tomsen Bukovec, Eric Charran, Trina Gorman, Gershon Levitz, Thomas Marquardt, Mandy Maxwell, Michael Murgolo, Sanjeev Nair, Michelle Rutzer, Jez Sadler, Jim Truher, Shimon Yannay


Letters 독자의 목소리

SharePoint 용량 계획 도구
우리 회사의 직원은 600명 미만이며 대부분은 PC나 인트라넷을 그다지 활발하게 사용하지 않습니다. 그렇지만 기업 통신이나 공동 작업에 대한 공통적인 요구가 있습니다. 우리의 작업 환경에는 Windows® SharePoint® Services(WSS) 3.0이 최적이라고 생각하지만 경영진에서는 서버 한 대에 해당하는 예산만 배정한 상태입니다.
SharePoint 용량 계획 도구를 사용하려고 했지만 단일 서버 모델을 시뮬레이트할 수가 없었습니다. 단일 서버를 위한 시뮬레이션 옵션이 있습니까?
—Allen M.
단일 서버용 옵션은 없습니다. 그러나 모든 사용자의 동작을 고려하지 않고 크기를 설정하기란 어렵습니다. 쿼드 코어 CPU와 8GB RAM으로 시작해 보십시오. 기본적으로 중간급 서버라면 무리가 없을 것입니다.
참조할 만한 자료로 Joel Oleson이 작성하여 그의 블로그(blogs.msdn.com/joelo/archive/2007/07/09/capacity-planning-key-links-and-info.aspx)에서 제공하는 다양한 크기 참조가 있습니다. 회사의 요구 사항을 충족하는 최선의 결정을 내리는 데 도움이 될 것입니다.
—Pav Cherny, 칼럼니스트,
Inside SharePoint

Microsoft Bob
Windows Confidential 칼럼 "공간을 차지하는 이전 도구"(2008년 7월, technet.microsoft.com/magazine/cc565089)의 의도가 Windows XP 디스크에 숨겨져 있던 Microsoft® Bob 프로그램을 알리는 것이라는 점은 알겠습니다. 그러나 우리 아이들이 정말 좋아했고 기본적인 컴퓨터 문서 작성을 배우는 데 사용했던 프로그램이 혹평을 받은 것 같아 아쉬운 생각이 듭니다. Bob을 처음 접한 것은 첫 번째 가정용 컴퓨터로 구입한 Window 95가 설치된 NEC Ready에서였습니다. 우리 아이들은 자라면서 Bob를 가지고 놀고 유용하게 사용했습니다.
이 칼럼에서 Bob은 실패한 기술 제품으로 조롱당했지만 사실은 대상을 성인으로 정한 것이 실수였을 뿐 그 자체는 훌륭한 소프트웨어였습니다. Bob은 어린이를 위한 소프트웨어였습니다. 어린이에 맞게 제공되었다면 전혀 다른 대접을 받았을 것이고 지금의 운명도 달랐을 것입니다. 처음부터 어린이를 위한 프로그램으로 제공되었다면 지금 우리 손자들도 사용하고 있을지 모르는 일입니다.
—Jim S.

인쇄의 시대는 갔다.
2008년 7월 Editor's Note, "인쇄의 시대는 갔다"(technet.microsoft.com/magazine/cc595615)를 상당히 흥미롭게 읽었습니다. 제 생각에는 IT 분야의 인쇄된 책은 이제 곧 종말을 고하고 디지털 매체로 대체될 것 같습니다. 하지만 칼럼에서는 90%의 독자가 인쇄된 매체를 선호한다고 밝히고 있습니다. 조사가 제대로 된 것인지 의심이 듭니다. 아니면 인쇄 매체를 통해 연락 가능한 사용자들만 설문에 응답한 것 아닌가요? 이러한 사용자 그룹에는 더 이상 신문이나 잡지를 구독하지 않고 모든 정보를 온라인에서 얻는 젊은 사용자는 포함되지 않을 것입니다.
인쇄된 텍스트를 읽으면서 텍스트에 연결된 비디오나 웹캐스트를 열 수는 없습니다. 인쇄된 인터넷 링크를 마우스로 클릭하여 홈 페이지, 뉴스 그룹 또는 블로그를 열 수도 없으며 인쇄된 텍스트에 소개된 추가 기능이나 도구를 마우스로 클릭하여 다운로드할 수도 없습니다.
요약하자면 인쇄된 책은 좋지 않은 타협안이라는 것입니다. DVD가 제공하는 장점과 비교하면 인쇄된 책의 장점은 지극히 제한적이라는 것을 체감하게 될 것입니다. DVD의 전체 내용을 노트북으로 복사하면 언제 어디서든 콘텐츠에 액세스할 수 있습니다.
—Ulrich S.
지적과 의견에 감사드립니다! 독자 여러분의 90%가 인쇄 매체를 선호한 것과 관련해서 말씀드리면, 조사는 구독자와 웹 독자 모두를 거의 반반씩 대상으로 매년 수행되는 편집부 여론 조사의 일환으로서 인쇄된 매체가 아닌 인터넷을 통해 수행되었습니다. 질문은 두 가지(인쇄 및 온라인)를 모두 읽는다고 답한 독자에게 주어졌으며 90%의 독자가 인쇄된 매체를 선호한다고 답했습니다.
온라인으로 콘텐츠를 게시할 때의 장점(풍부한 미디어, 전 세계 독자에 대한 노출, 클릭할 수 있는 링크 등)에 대해서도 전적으로 동감하지만 아무래도 인쇄된 페이지를 읽을 때의 몰입감을 대신할 수는 없는 것 같습니다. 개인적으로는 인쇄된 매체가 더 편안하고 내용에 대한 집중도도 높게 느껴집니다. 그리고 많은 사람들이 이와 비슷한 느낌을 공감하고 있습니다. 그러나 이러한 두 매체는 각기 장점을 제공하며 TechNet Magazine에서 두 가지를 모두 사용하는 것도 바로 이 때문입니다. 다시 한번 감사 드립니다.
—Joshua Hoffman, 편집장


Toolbox IT 전문가를 위한 신제품
Greg Steen

서버 모니터링
Mastering SQL Server 2005 Reporting Services Infrastructure Design
sybex.com
인프라가 복잡해질수록 관리자가 처리해야 할 데이터의 양도 범람하게 되는데 이러한 데이터는 대부분 파일이나 데이터베이스에 기록됩니다. 이러한 정보를 유용하게 사용하려면 분석 엔진과 함께 분석된 데이터를 유용한 형태로 제공하는 도구가 필요합니다. 이러한 매우 유용한 도구 중 하나가 Microsoft® SQL Server® 2005 Reporting Services입니다. 이 도구를 사용하면 해당하는 모든 데이터를 집계 형식으로 가져오고 이를 사람이 읽을 수 있는 형식으로 만들 수 있습니다. 또한 여러 장소에 자동으로 또는 주문형으로 정보를 전달할 수 있어 비즈니스 사용자가 현명한 비즈니스 의사 결정을 내리는 데 필요한 거의 실시간에 가까운 데이터를 제공합니다.
여러분의 회사에 필요한 기능을 제공하고 회사가 성장하는 동안 함께 성장할 수 있는 성공적인 Reporting Services 인프라(또는 필요한 경우 새로운 서버 인프라)를 계획, 배포 및 관리하려면 준비와 노하우, 그리고 약간의 용기가 필요합니다. Reporting Services 인스턴스 배포를 고려하고 있다면 Joseph L. Jorden의 저서 Mastering SQL Server 2005 Reporting Services Infrastructure Design(Sybex, 2007)을 통해 이해의 폭을 넓히고 성공적인 운영을 위한 핵심적인 지침을 얻을 수 있습니다.
이 책은 Reporting Services 배포에 대해 본격적으로 설명하기에 앞서 간과되기 쉬운 시스템 구현의 측면을 자세하게 소개하고 있습니다. 이러한 기본적인 측면에는 시스템을 구현하는 이유의 확인, 해당 기업에서 사용하는 요구 사항, 그리고 최종 사용자의 예상을 관리하는 방법의 정의가 포함됩니다. 사용자의 보고 시스템에서 변경 관리를 위한 전략에 대한 장도 있습니다. 이 섹션에서는 변경 관리를 위한 다양한 방법을 설명하고 변경 관리 요청 양식을 위한 템플릿과 지침을 제공합니다. 필자는 관료 주의의 장점을 주장하는 사람은 아니지만 어느 정도의 구조를 갖추면 훨씬 안정적인 환경을 보장할 수 있습니다.
Reporting Services의 비즈니스 측면을 다룬 다음에는 본격적으로 배포에 대한 내용을 다루면서 설치, 확장, 자동화 및 구성에 대해 설명합니다. 이 밖에도 Microsoft WSS(Windows® SharePoint® Services)를 통합하는 방법에 대한 팁을 제공합니다. 또한 순조롭게 출발할 수 있도록 일반적인 문제를 피하기 위한 배포 검사 목록을 제공합니다.
SQL Server 2005 Reporting Services의 새로운 훌륭한 기능 중에 임시 보고 기능이 있습니다. 이 기능을 사용하면 사용자가 즉시 보고서를 만들 수 있습니다. 책에서는 이 기능을 활성화하는 방법과 보고서 작성기 도구를 설정하는 방법을 설명합니다. 그런 다음 일정에 따라 보고서를 생성하고 전자 메일, 파일 공유 또는 통합 SharePoint 배달을 통해 배포할 수 있도록 보고서에 대한 구독을 만드는 방법을 알아봅니다.
모든 시스템은 시간이 흐름에 따라 관리가 필요하므로 다음 장에서는 인스턴스 백업, 보고서 내용 관리, 그리고 제공되는 로그를 사용하여 문제를 해결하는 방법과 같은 필수적인 작업을 다룹니다. 이 밖에도 사용자의 배포에서 선택할 수 있는 인증 및 권한 부여 옵션을 설명하는 충실한 내용의 보안 관련 장이 있습니다.
Reporting Services를 확장하는 방법을 설명하는 장과 Microsoft .NET Framework 기반 응용 프로그램을 통해 보고서를 액세스 및 조작하는 방법을 설명하는 장은 프로그래머에게 매우 유용합니다. RDL(Report Definition Language)은 Reporting Services의 핵심적인 측면 중 하나이므로 이 책에서는 여러분이 사용할 수 있는 일부 핵심 요소, RDL 파일의 구조, 그리고 이러한 파일을 만들고 배포하는 기본적인 방법을 다루는 장을 따로 마련했습니다.
이 책은 마지막으로 Reporting Services 배포의 성능을 튜닝하는 데 유용한 몇 가지 팁과 트릭으로 끝을 맺고 있습니다. 여기에는 성능을 측정하고, 구성 파일을 수정하며, 성능 콘솔을 사용하는 데 대한 정보가 있습니다. Reporting Services를 SharePoint와 통합하는 방법을 설명하는 부록도 있습니다. 여러분의 환경에 SQL Server 2005 Reporting Services를 도입을 고려하고 있다면 이 책을 놓치지 마십시오. 한발 앞선 출발을 하는 데 도움이 될 것입니다.

가격: 49.99달러(직판가)

사용자의 환경 감사
Alloy Discovery Professional Edition
alloy-software.com
여러분이 담당하고 있는 영역의 특정 시스템에서 신속하게 정보를 검색하는 능력은 작업을 수행하고, 문제를 해결하며, 해당 시스템이 보안 및 소프트웨어 정책에 따라 최신 상태로 유지되고 있는지 확인하는 데 필수적입니다. 그리고 이러한 정보를 비즈니스 사용자가 쉽게 볼 수 있는 형식으로 제공하고 인프라에 대한 전체적인 평가를 수행할 수 있도록 한다면 관리를 효율적으로 수행할 수 있음은 물론이고 상당한 장점이 됩니다. 여기에서 그치지 않고 신속하게 정보에 액세스할 수 있으면 특정 소프트웨어를 사용하는 사용자를 격리하여 사용자에게 올바른 라이선스를 부여할 수 있습니다. 이를 위한 인벤토리 및 감사 도구 중 하나로 Alloy Software에서 개발한 Alloy Discovery Professional Edition이 있습니다.
이 응용 프로그램은 매우 쉽게 구성할 수 있으며 사용자의 LAN에서 시스템 그룹이나 범위에 대해 신속하게 감사를 시작할 수 있습니다. UI를 사용하여 사용자의 시스템을 Internet Explorer®에서와 비슷하게 정리된 보기로 그룹화할 수 있으며 감사를 적용할 수 있는 시스템 그룹을 설정한 다음에는 간단하게 클릭으로 그룹에 대한 감사를 수행할 수 있습니다. 수집되는 정보는 하드웨어, 소프트웨어, 프린터와 같은 장치, 공유, 심지어 이벤트에 이르기까지 광범위합니다. 이 밖에도 자산 태그, 일련 번호, 가동 시간 통계, 환경 변수, 네트워크 구성 및 로컬 사용자 계정도 볼 수 있습니다. 건강을 위해서는 조금씩 움직이는 것이 좋겠지만 환경에 대해 알아야 할 모든 정보를 여러분의 책상에서 수집할 수 있습니다.
요청에 따라 시스템을 감사하는 기능 외에도 감사를 예약할 수 있습니다. 시스템이 사용자의 직접적인 LAN 외부에 있거나 원격 연결에서 감사 작업을 수행하기 위한 권한이 부여되지 않는 경우를 위해 Alloy Discovery는 대상 시스템에 대한 에이전트 기반 감사 기능을 제공합니다. 이러한 유형의 쿼리를 스크립트로 작성하고 주기적으로 실행하도록 예약하거나 에이전트를 통해 실행하여 에이전트에서 사용자의 기본 Alloy Discovery 리포지토리로 전자 메일로 전송하도록 구성할 수 있습니다. 또한 플래시 드라이브에 에이전트를 넣어서 시스템마다 직접 이동하여 감사를 시작하는 옵션도 있습니다. 감사를 수행한 다음에는 기본 리포지토리에서 사용된 방법에 따라 자동 또는 수동으로 정보를 동기화할 수 있습니다.
Alloy Discovery에는 결과에 적용하여 전체 인벤토리를 분석할 수 있는 필터도 있습니다. 예를 들어 응용 프로그램을 지원하기 위해 메모리 업그레이드가 필요한 시스템의 수를 확인하거나 환경에서 Windows® XP Professional이나 Windows Vista® Business 버전을 실행하는 시스템의 수를 확인할 수 있습니다.
데이터를 얻은 다음에는 이를 사용하여 보고서를 만들 수 있습니다. 응용 프로그램에는 여러분이 자세히 살펴볼 수 있도록 HTML 페이지로 보고서를 게시하는 기능이 있습니다. 또한 이러한 보고서를 주기적으로 생성하도록 작업을 예약하는 기능도 있으며 이러한 기능은 네트워크 작업 센터에 특히 유용합니다. 이 밖에도 모든 감사 정보를 XML, CSV 또는 Microsoft Excel®로 내보내서 감사자에게 증거를 제공할 수 있습니다.

가격: 795달러(직판가) 기본 제품 가격, 노드당 3달러 추가 ﻿
Alloy Discovery를 통해 환경 활용 극대화 (더 크게 보려면 이미지를 클릭하십시오.)

사용자의 암호 관리
Password Corral
cygnusproductions.com
암호는 오늘날 세계가 서로 연결되어 있다는 증거입니다. 생체 인식을 통해 모든 인증이 수행되거나 완벽한 신뢰가 보장되는 유토피아를 만든다면 더 이상 암호가 필요 없겠지만 이러한 일이 가까운 장래에 실현되지는 않을 것입니다. 필자의 경우에는 다양한 환경에 따라 다양한 유형의 암호를 사용하며 매체에 따라서도 다른 암호를 사용합니다.
일반적인 사용자를 위한 이러한 암호 외에도 관리자 계정, 서비스 계정 및 다양한 도메인 계정을 위한 시스템 암호가 있습니다. 그리고 이러한 다양한 암호에는 다양한 사용자 이름이 연결되어 있습니다. 이 밖에도 다양한 사용자 이름과 암호가 사용됩니다. 이러한 암호를 안전하고 쉽게 관리하려면 어떻게 해야 할까요?
한 가지 방법은 모든 데이터를 강력하게 암호화된 파일에 보관하는 암호 리포지토리를 사용하는 것이며 Password Corral은 이러한 훌륭한 솔루션 중 하나입니다. 2001년에 첫선을 이 응용 프로그램은 사용하기 쉽고 강력한 암호화를 제공하며 Diamond2나 Blowfish 암호화를 통해 모든 암호를 하나의 파일로 암호화합니다. 이 응용 프로그램은 그동안 충분한 테스트를 거쳤으며 지금도 현재 및 향후 릴리스를 위한 활발한 지원과 개발이 계속되고 있습니다.
프로그램을 설치한 다음에는 새로운 사용자를 만들고 사용자의 시스템(또는 네트워크 드라이브)에서 암호 파일의 위치를 선택하여 새로운 암호 파일을 준비합니다. 이제부터는 사용자의 모든 계정에 대한 중요한 암호 정보를 하나의 Password Corral 파일에 보관하므로 Password Corral 암호는 매우 강력해야 하며 자주 변경해야 합니다. 이 암호는 이제 사용자가 기억하고 보호해야 할 유일한 암호이므로 현명하게 선택해야 합니다.
인증을 거친 다음 Password Corral은 왼쪽에 계층 폴더 구조가 있고 오른쪽에 상세 정보 창이 있는 Internet Explorer와 비슷한 UI를 제공합니다. 트리와 비슷한 폴더 구조에 사용자의 암호를 정리할 수 있습니다. 각 암호에는 설명, 사용자 이름, 암호, 참조 URL, 참조 전자 메일 주소, 그리고 계정에 대한 설명을 지정할 수 있습니다. 이 밖에도 응용 프로그램에서 각 계정에 대한 암호 정책을 만료 주기 일수와 암호가 만료되기까지 남은 일수로 지정할 수 있습니다.
보기 옵션 중에는 만료된 암호를 필터링하여 계정 중에서 다음에 암호를 사용하기 위해 재설정이 필요한 항목을 보여 주는 것이 있습니다. 이 밖에도 사용자가 직접 모든 계정에 강력한 암호를 만들 필요가 없도록 자동으로 암호를 생성하는 편리한 기능이 있습니다. 이 암호 생성기도 원하는 길이, 복잡도 및 문자 조합을 설정하여 사용자 지정할 수 있습니다.
모든 암호를 입력한 다음에는 데이터를 입력한 모든 필드를 간단하게 검색할 수 있으므로 폴더 구조 깊숙히 저장된 자주 사용되지 않은 계정에 대한 정보도 쉽게 찾을 수 있습니다. 또한 깜박하고 Password Corral을 종료하지 않은 경우를 위해 응용 프로그램 시간 제한을 설정하여 사용자의 중요한 정보를 보호할 수 있습니다. 게다가 암호를 버퍼로 복사한 경우에는 응용 프로그램이 종료될 때 자동으로 클립보드를 삭제하는 기능이 있습니다.
암호에 대한 지속적인 액세스가 필요한 경우에는 응용 프로그램의 시스템 트레이 아이콘 옵션을 사용하여 간단하게 두 번 클릭으로 응용 프로그램을 시작할 수 있습니다. Password Corral을 사용하는 동안 계정을 다른 곳에 저장하려는 경우에는 파일에서 데이터를 가져오는 기능을 사용하여 데이터를 다시 입력하는 수고를 덜 수 있습니다. 물론 모든 암호를 내보내고 인쇄하는 기능도 제공합니다. 물론 암호를 인쇄한 경우에는 사용이 끝나면 용지를 반드시 폐기해야 합니다! 종합하자면 매우 유용한 무료 도구입니다.

가격: 무료
Password Corral을 사용하여 모든 암호를 관리 (더 크게 보려면 이미지를 클릭하십시오.)

파일 사용 감사
File System Auditor
scriptlogic.com
공유 파일 시스템에서 감사 추적을 유지 관리할 수 있으면 많은 문제를 미연에 방지할 수 있습니다. 더 중요한 것은 특정한 정보 보존 정책 표준을 충족해야 할 필요성이 있다는 것입니다. 누가 언제 무엇을 했는지 알아보려면 ScriptLogic의 File System Auditor에 관심을 가져 보십시오. 이 응용 프로그램은 대상 시스템에서 파일 사용을 거의 실시간으로 추적하고 이 정보를 사용 보고를 위해 SQL Server 데이터베이스에 저장하는 중앙 집중식 관리 시스템입니다.
File System Auditor는 MSDE(Microsoft SQL Server Desktop Engine), SQL Server 2000, 그리고 모든 SQL Server 2005 버전(무료 SQL Server 2005 Express 포함)을 지원합니다. 모니터링되는 각 시스템에는 파일 사용을 모니터링하고 SQL Server로 보고하는 에이전트를 설치해야 합니다. 설치한 다음에는 데이터베이스 마법사를 사용하여 모든 감사 정보를 기록할 데이터베이스 리포지토리를 만듭니다.
시스템 관리자라면 이 시점에 사용량이 많은 시스템의 대역폭과 복잡함 때문에 걱정이 되겠지만 다행스럽게도 응용 프로그램은 여러 작업을 단일 감사 항목으로 결합하는 지능적인 감사 시스템을 사용합니다. 대역폭을 보자면 File System Auditor는 파일에 대한 첫 번째 액세스에 100바이트 데이터를 사용하며, 이후 액세스마다 10~20바이트를 사용합니다.
네이티브 Windows 감사 기능을 사용하지 않는 이유는 중앙 집중식 관리, 이벤트 병합 및 보고 기능 면에서 전용 모니터링 응용 프로그램이 더 유연하고 사용하기 쉽기 때문입니다. 게다가 이러한 모든 정보를 SQL 데이터베이스에 저장하기 때문에 다른 시스템에서 참조하기도 쉽습니다.
데이터베이스를 구성한 다음에는 Agent Configuration Console(에이전트 구성 콘솔)을 사용하여 에이전트를 설정합니다. 서버의 이름을 입력하거나 Active Directory®를 사용하여 찾아볼 수 있습니다. File System Auditor는 클러스터 파일 서버도 지원하므로 클러스터 인스턴스의 이름을 입력해도 됩니다. 다음은 에이전트 서비스를 설치하고(사용자의 계정에 원격 액세스가 있는 경우에는 한 번의 단추 클릭으로) 에이전트가 File System Auditor 데이터베이스에 연결하는 데 사용할 Windows 또는 SQL Server 계정을 선택합니다.
서버별로 Path Filters(경로 필터), Process Exclusion Filters(프로세스 제외 필터) 및 User Exclusion Filters(사용자 제외 필터)의 세 가지 다른 유형의 모니터링 제외를 설정할 수 있습니다. 경로 필터를 사용하면 경로를 지정하고 모든 파일이나 특정 파일 유형에 대한 사용 권한 변경, 생성 및 삭제와 같은 특정 폴더 및 파일 이벤트를 포함하거나 제외하도록 선택할 수 있습니다. 프로세스 제외와 사용자 제외를 사용하면 대상 서버의 특정 프로세스와 관련된 파일 및 폴더 이벤트에 대해 동일한 작업을 수행할 수 있지만 여기에는 파일 유형 필터는 지원되지 않습니다.
이벤트 감사를 설정하고 시작한 후에는 Report Configuration Console(보고서 구성 콘솔)을 시작하고 감사 데이터를 사용할 수 있습니다. 사용자, 특정 파일 또는 폴더 이벤트, 경로, 서버, 프로세스 및 날짜 범위를 포함하여 데이터에 대해 여러 필터를 설정하여 보고서를 구성할 수 있습니다. 또한 보고서를 예약하고 응용 프로그램이 게시된 보고서를 사용자의 SMTP 서버를 통해 전자 메일로 전송하도록 할 수 있습니다. 마지막으로 시스템의 파일에 어떤 작업이 수행되는지 실시간으로 보려면 File System Auditor의 Real Time Viewer(실시간 뷰어)를 시작하여 로그 파일을 "추적"하듯이 원시 이벤트 스크롤을 볼 수 있습니다.

가격: 약 800달러(직판가)부터, 프로그램 및 단일 서버 라이선스
File System Auditor를 사용하여 파일 사용 감사 (더 크게 보려면 이미지를 클릭하십시오.)

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


Utility Spotlight Windows 메모리 진단
Lance Whitney

코드 다운로드 위치: Utility2008_09.exe (640KB)

목차
Windows 메모리 진단받기
메모리 테스트
여러분이 지원을 담당하는 PC 중 한 대가 말썽을 일으켜 멈추고, 충돌하고, 블루 스크린을 띄웁니다. 하드웨어 중 어딘가에 문제가 생긴 것일까요? 새로 설치한 응용 프로그램이 문제의 원인일까요? 아니면 메모리 결함일까요? 문제의 원인을 확실히 밝혀내는 한 가지 방법은 Microsoft® Windows® 메모리 진단 유틸리티를 사용하는 것입니다. 이 도구는 PC의 RAM에서 다양한 테스트를 실행하여 메모리 모듈에 결함이 있는지 여부를 확인합니다.

Windows 메모리 진단받기
Windows 메모리 진단을 받으려면 oca.microsoft.com/en/windiag.asp에서 mtinst.exe 파일을 다운로드하여 실행하십시오. Windows 메모리 진단은 설치할 필요가 없습니다. 스크린샷에서 볼 수 있듯이 이 도구는 두 가지 옵션을 제공합니다.
그림 1 부팅 가능한 미디어를 만들기 위한 Windows 메모리 진단 옵션(더 크게 보려면 이미지를 클릭하십시오.)
  • Create Startup Disk(시작 디스크 만들기)를 선택하면 시작 플로피 디스크를 만들 수 있습니다.
  • Save CD Image to Disk(CD 이미지를 디스크에 저장)를 선택하면 프로그램의 ISO 이미지를 하드 드라이브에 저장할 수 있습니다. 그런 다음 CD 작성 소프트웨어를 사용하여 이 이미지를 CD에 구워 부팅 가능한 미디어로 만들 수 있습니다. 부팅 가능한 미디어를 작성한 후에는 PC를 다시 부팅하여 플로피 또는 CD에서 진단을 시작합니다.
메모리 테스트
프로그램은 로드된 후 즉시 RAM을 검사하기 시작합니다. Windows 메모리 진단 도구는 Standard(표준) 모드로 시작하는데, 여기에는 6가지의 연속되는 메모리 테스트가 포함되며 각 테스트는 고유한 알고리즘을 사용하여 서로 다른 유형의 오류를 검사합니다. 화면에는 개별 테스트가 실행되는 모습이 표시되며 진행률과 검사 대상 메모리 범위가 나타납니다. 6가지 테스트가 완료되면 동일한 테스트를 사용하여 또 다른 패스가 시작됩니다. 사용자가 소프트웨어를 종료하기 전까지 이렇게 패스가 계속 진행됩니다. 일반적으로 한 번의 패스만으로도 메모리에 문제가 있는지 여부를 파악하기에는 충분합니다.
더 포괄적으로 테스트하려면 Extended(확장) 모드로 전환하여 11가지의 개별 메모리 테스트를 실행할 수 있습니다. 2가지 테스트만 실행하는 Basic(기본) 모드도 있지만 철저히 테스트하려면 Standard(표준) 및 Extended(확장) 모드를 사용해야 합니다. 확장 테스트 모음을 실행하는 경우 Windows 메모리 진단 도구를 야간에 실행하는 것이 좋습니다.
각 테스트가 완료된 후에는 Succeeded(성공) 또는 Failed(실패) 메시지가 표시됩니다. Failed(실패) 메시지 다음에는 실패에 대한 세부 정보가 표시되며 일반적으로 RAM 모듈 중 하나에 문제가 있다는 내용이 나타납니다. 사용자의 PC 환경에 따라 특정 모듈로 메모리 문제의 범위를 더 좁힐 수도 있습니다.
이 경우 메모리 모듈별로 오류를 볼 수 있는 옵션이 메뉴에 표시됩니다. 이 옵션을 사용하면 교체가 필요한 문제의 모듈을 확인할 수 있습니다.
Advanced(고급) 옵션 화면에서는 Basic(기본), Standard(표준) 및 Extended(확장) 모드 사이를 전환할 수 있습니다. 또한 이 화면에서 검사 중에 프로세서의 캐시를 비활성화하도록 선택하면 도구가 RAM의 데이터에 직접 액세스하므로 보다 철저한 테스트가 가능합니다. System Information(시스템 정보) 명령을 실행하면 각 슬롯에 설치된 RAM의 용량과 종류가 나열됩니다.
Windows 메모리 진단 도구는 Intel Pentium 및 Celeron 프로세서와 AMD K6, Athlon 및 Duron CPU를 포함한 x86 기반 플랫폼을 지원합니다. 다만 이 도구는 최대 4GB의 RAM만 테스트할 수 있으며 이 용량을 초과하는 부분에 대해서는 검사를 수행하지 않습니다.
Windows Vista®의 관리 도구와 Windows Vista 설치 미디어의 복구 옵션에도 이 진단 도구가 있습니다. 단, Windows Vista 버전의 경우 시각적 피드백이나 옵션이 그다지 다양하지 않습니다. 따라서 다음번 PC가 말썽을 일으킬 때를 대비하여 독립 실행형 버전을 준비해 두는 것이 좋습니다.
Lance Whitney는 IT 컨설턴트 겸 강사이자 테크니컬 라이터로, Windows 워크스테이션과 서버를 분석하는 데 많은 시간을 할애하고 있습니다. 원래 저널리스트였던 그는 15년 전 IT 업계에 발을 들여 놓았습니다.


Inside SharePoint SharePoint 디렉터리 통합
Pav Cherny

코드 다운로드 위치: SharePoint2008_09.exe (2,775 KB)

목차
SharePoint 디렉터리 관리 서비스
사용자 지정 디렉터리 관리 서비스
SharePoint와 ILM
결론
Microsoft WSS(Windows SharePoint Services) 3.0과 MOSS(Microsoft Office SharePoint Server) 2007에는 Active Directory에서 SharePoint 리소스용 메일 사용이 가능한 연락처와 그룹 개체를 프로비전할 수 있는 디렉터리 관리 서비스 형식의 디렉터리 동기화 기능이 포함되어 있습니다.
이렇게 SharePoint® 리소스에 대한 받는 사람 개체를 프로비전하면 사용자는 문서 및 다른 정보를 전송할 때 Microsoft® Outlook® 주소록에서 SharePoint 라이브러리, 목록 및 그룹을 직접 선택할 수 있게 됩니다.
SharePoint 받는 사람 개체는 또한 Exchange Server 조직에서 메시지 전송과 형식 변환을 제어할 수 있는 방법을 제공합니다. 무엇보다 중요한 것은 스패머와 같은 무단 전송자가 Active Directory®의 메시지 배달 제한을 설정하여 SharePoint 라이브러리에 메시지를 전송하는 것을 방지한다는 것입니다.
그러나 SharePoint 디렉터리 관리 기능은 다소 제한적이며 이 기사는 기본 메시지 시스템이 Exchange Server 2003이라고 가정하고 작성했습니다. Exchange Server 2007이나 타사 메시징 시스템을 사용하고 있다면 기본 제공 디렉터리 관리 기능을 확장하거나 사용자 지정 솔루션으로 대체해야 원하는 수준의 상호 운용성을 달성할 수 있습니다.
이 칼럼에서는 SharePoint 디렉터리 관리 기능을 간단하게 검토하고 기존의 한계를 극복하는 방법을 논의해 보겠습니다. 디렉터리 관리 서비스는 가장 기본적인 사용자 요구 사항만 충족합니다. 다양한 메시징 시스템과 디렉터리 플랫폼을 포함하는 환경에서는 높은 유연성과 많은 기능이 필요합니다. 기본 제공 구성 요소를 사용자 지정 솔루션으로 대체하면 API나 가져오기 기능을 제공하는 모든 디렉터리 솔루션을 사용하여 SharePoint 받는 사람 정보를 동기화할 수 있습니다.
Exchange Server 2007과 호환되는 방법으로 SharePoint 받는 사람 정보를 동기화하는 방법을 살펴보면서 이를 확인해 보겠습니다. 비슷하게 사용자 지정 솔루션을 사용하여 IBM Lotus Notes나 다른 시스템과 받는 사람 정보를 동기화할 수 있습니다.
또한 Microsoft ILM(Identity Lifecycle Manager) 2007 Feature Pack 1에 포함되어 있는 Identity Information Server와 같은 메타디렉터리 서비스를 바탕으로 디렉터리 프로비전 프로세스를 중앙 집중화할 수 있습니다. 여기에서는 SharePoint를 ILM 2007과 통합하여 SharePoint 문서 라이브러리용 디렉터리 개체의 프로비전을 조정하는 방법을 살펴보겠습니다. 이 솔루션을 빌드하기 위한 도구, 소스 코드 및 단계별 지침은 technetmagazine.com의 코드 다운로드 섹션에 있는 이 칼럼의 첨부 자료에 포함되어 있습니다.

SharePoint 디렉터리 관리 서비스
거의 모든 구성 및 받는 사람 정보를 위해 Active Directory를 사용하는 Exchange Server와는 달리 SharePoint는 구성 및 콘텐츠 데이터베이스를 사용합니다. 따라서 SharePoint는 해당 데이터베이스에서 메일 사용이 가능한 라이브러리, 목록 및 그룹에 대한 받는 사람 정보를 디렉터리로 전파해야 합니다. 메시징 클라이언트는 일반적으로 디렉터리 개체를 사용하여 생성되는 주소록에서 받는 사람 정보를 찾습니다.
SharePoint에는 이러한 목적을 위한 디렉터리 관리 서비스가 기본적으로 포함되어 있습니다. 디렉터리 관리 서비스는 SharePoint 3.0 중앙 관리의 작업 페이지에 있는 받는 전자 메일 설정에서 구성할 수 있는 전자 메일 통합 웹 서비스(SharepointEmailWS.asmx)의 일부입니다. 그림 1에서는 기본 제공 디렉터리 관리 서비스가 작동하는 방법을 보여 줍니다.
그림 1 SharePoint 디렉터리 관리 서비스 아키텍처 (더 크게 보려면 이미지를 클릭하십시오.)
디렉터리 관리를 위한 웹 팜을 설정하고 메시지를 수신하기 위해 EmailSettings.aspx 등을 사용하여 전자 메일 주소에 라이브러리, 목록 또는 그룹을 할당하면 암시적으로 전자 메일 통합 웹 서비스를 호출하여 Active Directory에서 해당하는 받는 사람 개체를 프로비전하게 됩니다. 먼저 SharePoint는 콘텐츠 데이터베이스에 전자 메일 주소 정보를 저장합니다. 그런 다음 SharePoint는 사용자를 대신하여 웹 응용 프로그램 풀 계정의 ID를 사용하여 전자 메일 통합 웹 서비스에 요청을 프로비전합니다. 프로비전 요청이 실패하면 콘텐츠 데이터베이스에는 전자 메일 주소 정보가 있지만 Active Directory에는 이에 해당하는 받는 사람 개체가 없게 됩니다.
추가 리소스
  • SharePoint 제품 및 기술 웹 사이트
  • Windows SharePoint Services TechCenter
  • Windows SharePoint Services 개발자 센터
  • Microsoft SharePoint 제품 및 기술 팀 블로그
프로비전 요청이 실패하는 데는 여러 가지 이유가 있습니다. 가장 일반적인 이유는 IIS 메타데이터 액세스 권한이 없기 때문입니다. SharepointEmailWS.asmx는 응용 프로그램 풀 계정을 위한 웹 서비스로 설계되었기 때문에 이 웹 서비스는 호출자가 응용 프로그램 풀 계정인지 확인하기 위해 IIS 메타데이터를 검사하며 해당하지 않은 경우에는 사용자의 SharePoint 계정과 Active Directory 사용 권한 수준에 관계없이 액세스를 거부합니다.
SharepointEmailWS.asmx는 호출자의 ID로 이 액세스 검사를 수행하므로 호출 응용 프로그램 풀 계정은 자체 액세스 권한을 확인하기 위해 메타데이터에 대한 액세스가 필요합니다. 따라서 응용 프로그램 풀 계정에 상승된 사용 권한을 부여해야 이 작업이 성공합니다.
물론 웹 서버에서 상승된 사용 권한을 사용하면 보안에 대한 우려가 가중됩니다. 이보다는 ASP.NET 웹 서비스에 대한 액세스를 제어하는 것이 더 나은 방법입니다. 게다가 SharePoint는 중앙 관리 사이트에서 디렉터리 관리 서비스를 찾으려고 시도하지만 웹 팜에서는 노출 영역을 줄이기 위해 잠겨 있으므로 이 사이트를 영구적으로 사용할 수 없습니다. 따라서 사용자의 SharePoint 프로덕션 환경에서 기본 제공 디렉터리 관리 서비스를 사용하여 약화된 보안 구성을 수용해야 합니다.
기본 제공 디렉터리 관리 서비스는 밀접하게 연관된 클라이언트/서버 아키텍처에 기반을 두고 있기 때문에 추가적인 제한이 발생합니다. Microsoft.SharePoint.dll은 System.DirectoryServices.dll을 직접 사용하므로 프로비전 프로세스를 사용자 지정하기 위해 직접 논리를 구현할 수 없습니다. 예를 들어 기본 제공 디렉터리 관리 서비스 구현은 Exchange Server 2007을 지원하기 위한 모든 받는 사람 특성을 기록하지 않으며 특성 생성 규칙을 사용자 지정하기 위한 옵션이 없습니다.
논리를 직접 구현할 수 없다는 것은 가령 프로비전 프로세스를 사용자 지정하여 사용자 지정 승인을 구현하는 등의 작업이 불가능하다는 것을 의미합니다. SharePoint는 그룹용 승인 프로세스를 지원하지만 이 기능은 중앙 관리 사이트에 기반을 두고 있습니다. SharePoint 팜 관리자만 보류 중인 요청을 승인할 수 있지만 SharePoint 관리자가 항상 Active Directory 프로비전 프로세스를 승인하는 업무를 담당하는 것은 아닙니다.
이보다 더 중요한 것은 메일 사용이 가능한 문서 라이브러리와 목록에 대한 승인 프로세스가 없다는 것입니다. 디렉터리 관리를 설정하면 기본적으로 웹 팜의 모든 사이트 관리자에게 Active Directory에 메일 사용이 가능한 연락처와 그룹을 만들 수 있는 권한이 부여됩니다. 웹 팜의 받는 사람 개체는 모두 동일한 OU에 배치되므로 조직 구성 단위(OU)를 기반으로 받는 사람 관리를 구성하는 것도 불가능합니다.
디렉터리 관리 서비스는 SharePoint OU에서 받는 사람 개체를 찾으므로 받는 사람 개체를 다른 OU로 옮길 수 없으며 SharePoint 중앙 관리 응용 프로그램 풀 계정에 Active Directory에 대한 관리 권한을 부여해야 합니다. 또한 SharePoint의 Active Directory 간의 양방향 동기화를 구현할 수 있는 방법이 없습니다. Active Directory에서 개체 특성을 변경해도 변경 내용이 SharePoint 환경으로 전파되지 않습니다.

사용자 지정 디렉터리 관리 서비스
지금까지 기본 제공 디렉터리 관리 서비스에 추가적인 유연성을 위한 여지가 있다는 것을 설명했으므로 다음은 몇 가지 대안을 살펴보겠습니다. 다행스러운 것은 SharePoint는 여러분이 직접 디렉터리 관리 서비스를 구현하도록 허용한다는 것입니다. SharePoint 3.0 중앙 관리의 작업 페이지에 있는 받는 전자 메일 설정에서 여러분의 웹 서비스를 원격 디렉터리 관리 서비스로 등록하기만 하면 됩니다.
사용자 지정 웹 서비스를 배포하고 등록하는 데 대한 자세한 단계별 지침은 첨부 자료에서 "Directory Integration Based on a Custom Directory Management Service.xps" 워크시트를 참조하십시오. 또한 필자의 웹 서비스를 보면 Active Directory에서 cmdlet이나 Exchange 관리 도구를 사용하지 않고 Exchange Server 2007과 호환되는 받는 사람 개체를 프로비전하는 방법을 알 수 있습니다. 해당하는 소스 코드는 EmailIntegrationService 폴더에 있습니다. 그림 2에는 솔루션 아키텍처가 나와 있습니다.
그림 2 사용자 지정 디렉터리 관리 서비스 아키텍처 (더 크게 보려면 이미지를 클릭하십시오.)
사용자 지정 웹 서비스의 인터페이스는 SharePoint SDK에 문서화된 내용에 따라 디렉터리 관리 서비스 인터페이스를 준수해야 합니다. MSDN® 웹 사이트(msdn.microsoft.com)에서 "SharepointEmailWS"에 대해서 검색해 보면 필요한 세부 사항을 찾을 수 있습니다. 첨부 자료의 EmailIntegrationService\App_Code 폴더에 있는 Service.cs 파일도 확인해 보십시오. 이 파일은 필요한 웹 서비스 인터페이스를 구현하며, Active Directory 개체를 프로비전하는 실제 코드는 SPRecipient.cs에 있습니다. 예를 들어 SPRecipient.cs의 UpdateRecipientAttributes 함수는 필요한 Exchange Server 2007 특성을 생성합니다. SPRecipient.cs는 직접 사용자 지정 디렉터리 관리 서비스를 개발하기 위해 반드시 대체해야 하는 코드 파일입니다.
사용자 지정 디렉터리 관리 서비스는 상승된 사용 권한이라는 요구 사항을 극복하고 SharePoint를 타사 디렉터리나 메시징 시스템과 통합하기 위한 좋은 도구입니다. 응용 프로그램 풀 계정에 대한 웹 액세스를 제한하기 이해 IIS 메타데이터를 확인할 필요는 없으며 <authorization> 섹션을 웹 서비스의 web.config 파일(사용 예는 첨부 자료 참조)에 추가하면 됩니다.
그러나 SharePoint가 여러분의 디렉터리 관리 서비스를 호출할지 여부와 호출하는 시점을 제어할 수 없기 때문에 약간의 문제가 남아 있습니다. 무엇보다 SharePoint는 여러분이 메일 사용이 가능한 문서 라이브러리나 목록을 삭제할 때 디렉터리 관리 서비스를 호출하지 않으므로 잘못된 받는 사람 개체가 Active Directory에 남게 됩니다. 기본 제공 디렉터리 관리 서비스나 사용자 지정 솔루션 중 어떤 것을 사용하더라도 Active Directory의 받는 사람 정보가 SharePoint 리소스와 일치한다고 보장할 수 없습니다.

SharePoint와 ILM
안정적인 디렉터리 통합을 달성하려면 ILM과 같은 전문적인 디렉터리 관리 패키지를 배포하는 것을 고려할 수 있습니다. 이 시스템은 끌어오기 기반 디렉터리 동기화 모델을 사용합니다. 관리 에이전트는 해당하는 연결된 원본에서 정보를 끌어오고, 공용 메타디렉터리로 이를 가져온 다음, 메타디렉터리에서 해당 연결된 시스템으로 정보를 내보냅니다. 원본 시스템은 일반적으로 자체 정보를 메타디렉터리로 밀어넣지 않습니다. 정보를 끌어옴으로써 각 동기화 주기에서 일관성을 보장할 수 있습니다.
ILM을 사용할 때의 다른 혜택으로는 Active Directory, Lotus Notes 및 다양한 다른 시스템을 지원하는 여러 관리 에이전트가 기본적으로 제공된다는 것입니다. SharePoint 정보를 여러분의 환경에 있는 다른 지원되는 디렉터리 플랫폼과 동기화하려면 SharePoint용 사용자 지정 관리 에이전트만 구현하면 됩니다.
SharePoint에서 원하는 정보를 검색하고, 가져오기 파일에 정보를 저장하며, 가져온 정보를 메타디렉터리로 전송하는 논리를 구현해야 합니다. 그러나 메타디렉터리에서 이러한 정보를 Active Directory나 다른 디렉터리 플랫폼으로 내보내는 논리는 구현할 필요가 없습니다. 그림 3에는 ILM을 사용하여 SharePoint에서 Active Directory로의 동기화를 구현하는 방법이 나와 있습니다. 디렉터리 개체용 SharePoint 리소스를 프로비전하여 다른 방향으로 동기화를 달성하는 것도 가능하지만 이러한 기능은 불필요하거나 선택적입니다.
그림 3 ILM(Identity Lifecycle Manager) 기반 디렉터리 통합 (더 크게 보려면 이미지를 클릭하십시오.)
SharePoint 관리 에이전트 개발하려는 경우 Alex Tcherniakhovski의 기사 "SharePoint Services 목록으로 Connecting ILM 2007 연결(blogs.msdn.com/alextch/archive/2007/09/02/wsslistsandilm.aspx)"을 참조하면 시작하는 데 도움이 될 것입니다. Alex는 또한 문서 라이브러리에 제출된 InfoPath® 기반 프로비전 요청을 사용하는 ILM 기반 디렉터리 관리 솔루션을 만드는 방법도 보여 주고 있습니다. Alex의 관리 에이전트는 문서 라이브러리에서 승인된 모든 요청을 검색한 다음 연결된 디렉터리로 내보낼 수 있는 해당 메타디렉터리 개체를 만듭니다.
그러나 기본적으로 SharePoint는 목록이나 그룹을 메일이 가능하도록 설정해도 InfoPath 기반 프로비전 요청을 생성하지 않습니다. 사용자 지정 디렉터리 관리 서비스를 통해 이를 해결할 수 있지만 이렇게 하면 SharePoint가 모든 상황에서 디렉터리 관리 서비스를 호출하지는 않기 때문에 앞에서 언급한 대로 일관성 문제가 발생합니다. 따라서 관리 에이전트가 원하는 SharePoint 받는 사람 정보를 사이트 컬렉션의 목록과 그룹에서 직접 검색하는 방법을 사용하는 것이 좋습니다. 승인 프로세스가 필요하다면 관리 에이전트에서 새로운 리소스를 위한 InfoPath 기반 프로비전 요청을 생성한 다음 모든 승인 요청을 처리하면 됩니다.
SharePoint 정보를 검색하는 데는 몇 가지 방법이 있습니다. 즉, 콘텐츠 데이터베이스에서 직접 정보를 읽거나 SharePoint 개체 모델을 사용하거나 또는 SharePoint 웹 서비스를 활용할 수 있습니다.
데이터베이스 구조가 향후에 변경되면 디렉터리 관리 솔루션에 문제가 발생하므로 콘텐츠 데이터베이스에 직접 액세스하는 방법은 사용하지 않는 것이 좋습니다.
여러분의 관리 에이전트에서 SharePoint 개체 모델을 직접 사용하는 것도 비슷한 이유로 까다롭습니다. 개체 모델을 위해 로컬로 코드를 실행해야 하지만 환경에 있는 모든 SharePoint 팜의 웹 서버에 ILM을 설치하면 디렉터리 관리 인프라가 복잡해집니다.
SharePoint 웹 서비스를 사용하는 것을 고려할 수 있지만 SharePoint 웹 서비스를 통해서는 SharePoint 그룹에 대한 전자 메일 주소 정보나 받는 전자 메일 서버 표시 주소와 같은 원하는 정보를 쉽게 액세스할 수 없으므로 다른 문제가 발생합니다.
결국에는 SharePoint 개체 모델을 사용하여 원하는 정보를 검색하고, 이를 XML 문서 형식으로 호출자에 반환하는 사용자 지정 SharePoint 웹 서비스를 구현하는 것이 최적의 선택입니다. 이제 그림 3에 나와 있는 것처럼 ILM 배포를 중앙 집중화하고 사용자 지정 SharePoint 웹 서비스의 개별 인스턴스를 통해 원하는 수의 팜과 사이트 컬렉션을 통합할 수 있습니다.
ILM 기반 디렉터리 통합을 사용하더라도 사용자 지정 디렉터리 관리 서비스의 필요성이 사라지는 것이 아니라는 점에 주의할 필요가 있습니다. ILM이 디렉터리 개체를 프로비전하므로 이 사용자 지정 서비스는 아무 작업을 수행할 필요가 없지만 SharePoint 3.0 중앙 관리에서 디렉터리 관리를 수행하려면 사용자 지정 서비스를 제공해야 합니다. 그렇지 않으면 그룹에 전자 메일 주소를 할당하는 등의 작업을 할 수 없습니다. 그림 4에는 결과 솔루션 아키텍처가 나와 있습니다.
그림 4 웹 서비스 기반 SharePoint 디렉터리 통합 (더 크게 보려면 이미지를 클릭하십시오.)
web.config 파일의 OpMode 매개 변수를 <add key="OpMode" value="dummy"/>와 같이 설정하여 첨부 자료에 포함되어 있는 사용자 지정 디렉터리 관리 서비스를 더미 서비스로 변경할 수 있습니다. 이 구성에서 사용자 지정 서비스는 프로비전 호출에 대한 응답으로 아무 작업도 수행하지 않고 항상 SUCCESS를 반환합니다.
또한 사용자 지정 서비스는 SharePoint 관리 에이전트가 NetBIOS 기반 사용자 이름으로 고유 이름을 확인하는 데 필요한 ResolveUsers 메서드를 공개합니다. 이 과정은 그룹을 프로비전할 때 필수 단계입니다. SharePoint는 NetBIOS 기반 사용자 계정 이름의 목록으로 그룹 등록 정보를 반환하지만 Active Directory에는 고유 이름이 필요합니다. 이것으로 끝입니다. 최종 솔루션을 배포하는 데 대한 자세한 내용은 첨부 자료에서 "Configuring Directory Integration based on ILM 2007.xps"를 참조하십시오.
WSS 3.0과 MOSS 2007에는 SharePoint를 Exchange Server 2003과 통합하여 메시징 기반 크로스 플랫폼 공동 작업을 구현하는 디렉터리 관리 서비스가 포함되어 있습니다.
하지만 몇 가지 제한 사항이 있습니다. 사용자가 기본 제공 디렉터리 관리 서비스를 사용자 지정 솔루션으로 대체해야 합니다. ILM과 같은 전문 디렉터리 관리 솔루션을 사용하여 SharePoint를 디렉터리 관리 인프라로 통합할 수도 있습니다. 이렇게 하면 높은 수준의 유연성을 제공할 수 있으며 끌어오기 기반 동기화 모델에서 정보의 일관성을 보장하는 데 도움이 됩니다.

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


Windows PowerShell 문자열 이론
Don Jones

목차
실제 사례
복잡한 일치
문자열 세계
필자는 Tech•Ed 또는 TechMentor와 같은 컨퍼런스에서 연설할 때면 Windows PowerShell과 같은 요소의 핵심 사항을 기억하는 데 도움이 되는 일반적인 규칙을 선언하는 버릇이 있습니다. 최근에는 "Windows PowerShell에서 문자열을 구문 분석하고 있다면 무엇인가 잘못하고 있는 것입니다."라고 선언했습니다.
이것은 개체 지향 셸인 Windows PowerShell™에 관한 필자의 철학에서 나온 것입니다. 만약 어떤 서비스가 시작되었는지 확인하기 위해 서비스 목록을 텍스트 파일로 수집한 다음 해당 텍스트 파일을 구문 분석하고 있다면 정말 어렵게 일하는 것입니다. 이것은 UNIX와 같은 텍스트 기반 OS에서는 유효한 방법이지만, Windows® 자체는 물론 Windows PowerShell에서는 훨씬 더 효과적으로 개체를 사용할 수 있습니다.
비디오
Windows PowerShell을 사용하여 복잡한 문자열을 구문 분석하는 방법에 대한 Don Jones의 설명을 볼 수 있습니다.

셸의 다양한 서식, 필터링, 내보내기 및 기타 명령을 사용하여 스크립트의 출력을 조작하려면 직접 작성한 스크립트에서도 서식 있는 텍스트가 아닌 개체를 생성해야 합니다. (2008년 7월 Windows PowerShell 칼럼에서 스크립트 출력으로서의 사용자 지정 개체 개념에 대한 자세한 내용을 볼 수 있습니다.)
플로리다주 올랜도에서 개최된 최근 TechMentor에서 필자의 학생 중 한 명이 거의 모든 규칙들, 특히 일반적인 규칙에는 예외가 있다는 사실을 일깨워 주었습니다. "IIS 로그 파일에서 무언가를 찾는 경우에는 어떻게 합니까? 이 경우에는 텍스트 구문 분석이 필요하지 않을까요?"
맞는 말입니다. 다행히 Windows PowerShell은 개체 친화적일 뿐만 아니라 텍스트 문자열을 구문 분석하는 면에 있어서도 떨어지지 않습니다. 말이 나온 김에 생각해 보면 IIS 로그 파일, 방화벽 로그 파일 및 기타 텍스트 기반 로그를 전형적인 예로 들 수 있습니다.

실제 사례
실제로 필자는 예전에 일했던 한 회사에서 일련의 방화벽 로그 파일을 구문 분석해야 했습니다. 한 직원이 부적절한 웹 사이트를 방문했다가 적발되었는데, 이에 대한 후속 조사의 일환으로 인사 부서에서 해당 직원이 방문했던 광범위한 웹 사이트 목록을 요구했습니다. 단 하루 동안의 로그 파일을 뽑아내는 것도 꽤 어려운 작업인데, HR 담당자들은 수동으로는 수행할 엄두도 나지 않는 몇 주 동안의 기록을 원했습니다.
회사의 DHCP(Dynamic Host Configuration Protocol) 서버를 확인한 결과 해당 직원의 컴퓨터는 수개월 동안 동일한 IP 주소(이 예에서는 192.168.17.54라고 가정)를 사용한 것으로 나타났습니다. 꺼지는 일이 거의 없는 데스크톱 컴퓨터였음을 감안하면 특이한 일은 아니었습니다. 또한 방화벽 로그에서 원본 IP 주소의 기록을 보관하고 있었기 때문에 Windows PowerShell을 사용하면 작업이 수월할 것이라 생각했습니다.
이 작업의 핵심은 간과하기 쉬운 Select-String 명령에 있습니다. 또한 정규식에 대한 실무적 지식도 필요합니다(Windows PowerShell 2007년 11월호 참조).
Select-String 명령은 텍스트 파일의 파일 경로, 정규식 또는 검색할 단순 문자열을 받습니다. 그런 다음 각 로그 파일에서 정규식 또는 단순 문자열에 일치하는 각 줄을 출력합니다. 필자는 우선 직원이 사용한 데스크톱 컴퓨터의 IP 주소가 포함된 모든 줄을 얻고자 했습니다. 각 로그 파일 줄에는 인사 부서에서 원하는 날짜 및 타임스탬프가 포함되어 있었습니다.
이 작업을 수행하는 명령은 다음과 같습니다.
select-string -path c:\logs\*.txt -pattern "192.168.17.54"
-allmatches –simplematch
–simpleMatch 매개 변수는 필자가 제공한 패턴이 정규식이 아닌 단순 문자열임을 지정합니다. 그림 1은 파일로 전달할 수도 있는 출력의 일부를 보여 줍니다. 출력에는 일치 항목이 발견된 파일 이름 및 줄 번호가 모두 포함되어 있다는 점에 주목하십시오. 이는 특정 지점으로 돌아가거나 자세한 정보를 알고자 하는 경우에 상당히 유용합니다.
이달의 cmdlet: Start-Sleep
이 cmdlet은 긴 하루 일과 중에 필요한 것, 바로 잠깐의 낮잠을 제공합니다. 그런데 Start-Sleep이 주는 이 짧은 휴식은 여러분이 아니라 Windows PowerShell 스크립트를 위한 것입니다.
스크립트에서 잠깐의 중지는 흔히 필요한 요소입니다. 예를 들어 서비스를 시작하고, 이 서비스가 준비되어 실행될 때까지 몇 초간 기다린 후, 해당 서비스에 의존하는 몇 가지 다른 작업을 수행해야 한다고 가정해 보십시오. Start-Sleep은 바로 이러한 동작에 필요합니다. 예를 들어 Start-Sleep 10을 실행하면 셸이 10초 동안 일시 중지됩니다. 더욱 정밀하게 제어해야 할 경우 Start-Sleep -milli 100을 실행하면 100밀리초 동안 일시 중지됩니다. Start-Sleep은 지정한 시간 동안 스크립트, 파이프라인 및 기타 모든 요소를 포함하는 셸을 완전히 일시 중단할 수 있습니다. 이제 누군가가 Start-Nap이라는 cmdlet을 작성해서 우리에게도 낮잠 시간이 좀 생기면 좋을텐데 말이죠.
그림 1 Select-String 명령의 출력(더 크게 보려면 이미지를 클릭하십시오.)

복잡한 일치
필자는 HR 담당자들이 요청한 정보를 정확히 전달했는데, HR 담당자들은 그제야 그 정보가 자신들이 원했던 것이 아님을 깨달았습니다. 필자의 보고서에는 207.68.172.246(MSN® 웹 사이트)을 비롯하여 해당 직원이 방문했던 수많은 IP 주소가 포함되어 있었으니까요. 조사 담당자의 다음 요청은 필자의 보고서를 정리하여 문제의 웹 사이트 중 하나에 속한 것으로 확인된 특정 IP 주소에 대한 방문만 뽑아내는 것이었습니다. 이 칼럼에서는 조사에 연루된 실제 IP 주소는 공개하지 않고 대신 207.68.172.246을 사용하겠습니다. MSN 웹 사이트를 부적절한 사이트로 간주하는 경우는 별로 없지만요.
이 요청은 해결하기가 약간 더 어려울 수 있습니다. 필자가 작업했던 로그 파일에서 원본 IP 주소와 대상 IP 주소는 쉼표로 구분된 상태로 서로 인접해 있었습니다. 덕분에 간단히 검색 문자열을 "192.168.17.54,207.68.172.246"으로 바꾸고 검색을 반복할 수 있었습니다.
그러나 두 개의 IP 주소 사이에 변수 데이터가 저장되는 보다 복잡한 로그 파일이라면 단순 문자열 일치는 제대로 작동하지 않습니다. 이러한 시나리오에서는 정규식을 사용해야 합니다. 정규식은 간단한 로그 형식에서도 잘 작동하므로 여기에서는 정규식에 대해 살펴보겠습니다.
정규식 내에서는 마침표가 모든 단일 문자에 대한 와일드카드입니다. 또한 하위 식(.)*을 사용하여 두 개의 IP 주소 사이에서 문자를 수에 관계없이 검색할 수 있습니다. IP 주소 자체에 쓰이는 리터럴 마침표로 이스케이프하려면 백슬래시를 사용해야 합니다.
완성된 명령은 다음과 같습니다.
select-string -path c:\logs\*.txt -pattern
"192\.168\.17\.54(.)*207\.68\.172\.246" –allmatches
이번에는 정규식을 사용하므로 –simpleMatch 매개 변수를 제거했습니다. 결과 출력에는 문제의 직원이 사용한 컴퓨터에서 부적절한 사이트로 판명된 특정 웹 사이트에 대한 방문만 표시되었습니다. 또한 조사 담당자가 원했던 날짜 및 타임스탬프 정보도 포함되어 출력되었습니다. 그림 2는 이와 같은 명령을 실행할 경우 얻게 되는 출력의 일부분을 보여 줍니다.
그림 2 특정 사이트에 대한 방문만 표시되도록 좁혀진 검색 결과(더 크게 보려면 이미지를 클릭하십시오.)
하지만 이보다 한 단계 더 나아가 Format-Table에 출력을 전달하고 Format-Table의 기능을 사용하여 계산된 열을 표시할 수 있습니다. 테이블에 로그 파일의 파일 이름과 일치가 발생한 줄 번호를 포함할 수 있고, 일치하는 줄 자체를 표시할 수도 있습니다. 한편 셸에서 빈 문자열로 정규식 일치를 대체하여 나머지 줄(이 예에서는 날짜 및 타임스탬프)만 표시되도록 할 수 있습니다. 다음은 고급 기법으로, Windows PowerShell에서 하나의 명령줄로 문자열 데이터를 조작하고 폭넓게 사용자 지정된 출력을 생성하는 방법을 더 세부적으로 보여 줍니다.
select-string -path c:\logs\*.txt -pattern
"192\.168\.17\.54(.)*207\.68\.172\.246" -allmatches |
ft  filename,linenumber,@{"Label"="Time";
"Expression"={$_.line.replace
($_.matches[0],"")}} –auto
7 그림 3은 최종 결과의 형태를 보여 줍니다.
그림 3 서식이 적용된 Select-String 명령의 출력(더 크게 보려면 이미지를 클릭하십시오.)

문자열 세계
필자는 Windows PowerShell의 가장 큰 장점의 하나로 개체 지향적 특성을 꼽습니다. 그러나 개체를 사용할 수 없는 경우도 있습니다.
Windows PowerShell의 주 무대는 개체 지향적 환경일 것입니다. 그러나 다행히 Windows PowerShell 팀은 사용자가 속한 환경에는 서식 있는 문자열로 된 외부 데이터가 포함되는 경우가 많다는 사실을 인식하고 Select-String 명령도 넣어 두었습니다. Select-String으로 무장하고 정규식에 익숙해진다면 Windows PowerShell을 사용하여 가장 복잡한 문자열까지 구문 분석하는 한 줄짜리 코드를 작성할 수 있습니다.

Don Jones는 Windows PowerShell: TFM의 공동 저자이며 그 외 다수의 IT 관련 서적을 집필하였습니다. www.concentratedtech.com의 블로그를 통해 Don Jones와 만날 수 있습니다.


Hey, Scripting Guy! 온라인 토스터
Microsoft Scripting Guys

코드 다운로드 위치: HeyScriptingGuy2008_09.exe (150 KB)

현대 사회를 단 두 마디로 표현하자면 연결 사회라고 할 수 있습니다. 휴대폰 덕분에 집에서 전화가 오기를 기다릴 필요 없이 밤이든 낮이든 어디서나 자유롭게 다른 사람과 통화할 수 있습니다. (아! 이 얼마나 멋진 세상입니까.) 무선 컴퓨팅 덕분에 꼭 사무실이 아니더라도 집, 공원 벤치 등 어디서나 편리하게 일할 수 있습니다.
일화를 하나 소개하자면, 얼마 전 Scripting Editor의 부모님께서 캠핑 여행을 떠나셨는데 캠프장의 무선 네트워크에 연결하는 데 문제가 있어 마치 위대한 탐험가 루이스와 클락처럼 원시적인 생활을 할 수밖에 없었다고 합니다. 위성 TV가 잘 작동한 게 그나마 다행이었죠.
이건 시작에 불과했습니다. GPS 장치는 현재 위치를 수십 센티미터 단위로 정확하게 알려 줍니다. 장치에 따라서는 자신의 정확한 위치를 다른 사람에게 알릴 수도 있습니다. ("달아날 수는 있지만 숨을 곳은 없다"는 옛말이 딱이죠.) 이 칼럼을 쓰고 있는 Scripting Guy는 마음만 먹으면 당좌 계좌에서 발행한 수표가 결제될 때마다 휴대폰으로 메시지를 보내도록 할 수 있습니다. 자동차가 매달 상태를 보고하는 전자 메일을 보내도록 할 수도 있죠. 심지어는 필자가 휴가를 가면 토스터가 강아지를 산책시키고 화분에 물을 주기도 합니다.
흠, 맞습니다. 뭐 마지막 이야기는 아직 실현되지는 않았습니다. 하지만 필자가 마음만 먹으면 얼마든지 인터넷을 지원하는 토스터를 구입할 수 있습니다. 그리고 집에 가는 길에 전화로 토스터에 지시하여 도착할 쯤에 따끈한 토스트가 준비되도록 할 수 있습니다. 솔직히 따끈한 토스트를 미리 준비해야 할 필요가 있나 싶기는 하지만요. 그래도 뭐 원한다면…
물론 모두가 이렇게 항상 네트워크에 연결되기를 원할 때 Scripting Guy(시류에 한 번도 편승한 적이 없는)만 연결 끊기를 주창한다고 해서 놀랄 일은 아닙니다. 그렇다고 휴대폰이나 랩톱 컴퓨터를 내던져 버리라는 의미일까요? 아닙니다. 아무리 Scripting Guy라도 그 정도로 멍청하지는 않습니다. 그들이 말하는 바는 연결이 끊어진 레코드 집합을 스크립팅 무기로 갖추라는 것입니다. 그래도 휴대폰이나 랩톱 컴퓨터를 버리겠다면 뭐, 할 수 없죠.
참고 Harris Interactive에서 실시한 설문 조사에 따르면 미국인의 43%가 휴가 중에 업무 관련 전자 메일을 확인하거나 보내기 위해 랩톱 컴퓨터를 사용한 적이 있다고 합니다. 그리고 미국인의 50% 이상은 휴가 중에 휴대폰으로 전자 메일 및/또는 음성 메일을 확인하는 것으로 나타났습니다. 그런데 더 놀라운 사실은 아예 여기에 포함되지도 않은 40%의 미국인은 1년 내내 휴가를 한 번도 가지 않는다는 것입니다.
많은 사람들이 기꺼이 연결이 끊긴 레코드 집합을 스크립팅 무기의 하나로 추가하리라는 점은 두말할 필요도 없지만, 문제는 연결이 끊긴 레코드 집합이 무엇인지를 모른다는 거죠. 이 개념이 생소하게 느껴지는 독자를 위해 간단히 설명하면, 연결이 끊긴 레코드 집합은 실제 데이터베이스에 연결되지 않은 데이터베이스 테이블로서 스크립트에 의해 생성되고 메모리 내에만 존재하며 스크립트가 끝나는 순간 사라집니다. 바꿔 말해 연결이 끊긴 레코드 집합이란 단 몇 분 동안만 존재한 후 데이터와 함께 사라지는 인공 데이터 구조라고 할 수 있습니다. 정말 유용할 것 같지 않습니까? Scripting Guy에게 고맙다는 인사를 해야겠군요.
솔직히 연결이 끊긴 레코드 집합이 그다지 흥미롭게 들리지는 않는다고요? 맞습니다. 하지만 사용하기에 따라 매우 유용할 수 있습니다. 전문 VBScript 작성자라면 다 잘 알겠지만 VBScript의 데이터 정렬 기능이 최고 수준이라고 할 수는 없습니다. (세계의 어떤 데이터 정렬 기능도 최고라고 하기에는 부족하다고 생각하는 분들도 있겠지만) 마찬가지로, 대량의 데이터를 처리하는 VBScript 기능도 한정되어 있습니다. 속성이 2개 이하인 항목을 작업에 사용하도록 제한하는 Dictionary 개체나 대개 단일 속성 데이터 목록으로 제한되는 배열, 이 정도가 다입니다.
연결이 끊긴 레코드를 사용하면 다른 여러 문제와 함께 이 두 가지 문제를 해결할 수 있습니다. 데이터, 특히 다중 속성 데이터를 정렬해야 하는 경우? 문제 없습니다. 앞서 설명했듯이 연결이 끊긴 레코드 집합은 가상 데이터베이스 테이블과 같은데, 세상에서 데이터베이스 테이블을 정렬하는 것보다 쉬운 일은 없습니다. (예예, 알겠습니다. 엄밀하게 따지면 물론 데이터베이스 테이블을 아예 정렬하지 않는 편이 더 쉽죠.) 또는 속성이 여러 개 있는 많은 수의 항목을 추적하려는 경우? 역시 문제 없습니다. 다시 한번 말하지만 연결이 끊긴 레코드 집합이 가상 데이터베이스 테이블과 같으니까요. 정보를 일정 방식으로 필터링하건 데이터에서 특정 값을 검색해야 하는 경우? 가상 데이터베이스 테이블만 이용할 수 있다면 문제가 없는데 말이죠.
자, 이제 본론으로 들어가야 할 때인 것 같군요. (이쯤이면 본론에서 어떤 내용을 설명할지 다 이해했으리라 봅니다.) 우선 그림 1에서 MLB.com 웹 사이트에서 수집하여 탭으로 구분된 값 파일 C:\Scripts\Test.txt에 저장한 야구 통계를 살펴보겠습니다.
그림 1 탭으로 구분된 값 파일에 저장한 통계
선수 | 홈런 | 타점 | 타율
D Pedroia | 4 | 28 | .276
K Kouzmanoff | 8 | 25 | .269
J Francouer | 7 | 35 | .254
C Guzman | 5 | 20 | .299
F Sanchez | 2 | 25 | .238
I Suzuki | 3 | 15 | .287
J Hamilton | 17 | 67 | .329
I Kinsler | 7 | 35 | .309
M Ramirez | 12 | 39 | .295
A Gonzalez | 17 | 55 | .299
그런데 이 선수 목록을 홈런 수를 기준으로 정렬하여 표시해야 한다고 가정해봅니다. 이 경우 연결이 끊긴 레코드 집합이 도움이 될까요? 지금부터 알아보도록 하죠. 먼저 그림 2를 살펴보십시오. 그렇습니다. 코드가 복잡하죠? 보기만큼 어렵지는 않으니 너무 겁먹지는 마십시오.
그림 2 연결이 끊긴 레코드 집합
Const ForReading = 1
Const adVarChar = 200
Const MaxCharacters = 255
Const adDouble = 5

Set DataList = CreateObject("ADOR.Recordset")
DataList.Fields.Append "Player", _
  adVarChar, MaxCharacters
DataList.Fields.Append "HomeRuns", adDouble
DataList.Open

Set objFSO = _
  CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile _
  ("C:\Scripts\Test.txt", ForReading)

objFile.SkipLine

Do Until objFile.AtEndOfStream
    strStats = objFile.ReadLine
    arrStats = Split(strStats, vbTab)

    DataList.AddNew
    DataList("Player") = arrStats(0)
    DataList("HomeRuns") = arrStats(1)
    DataList.Update
Loop

objFile.Close

DataList.MoveFirst

Do Until DataList.EOF
    Wscript.Echo _
        DataList.Fields.Item("Player") & _
        vbTab & _
        DataList.Fields.Item("HomeRuns")
    DataList.MoveNext
Loop
먼저 상수를 4개 정의합니다.
  • ForReading: 이 상수는 텍스트 파일을 열고 데이터를 읽을 때 사용합니다.
  • adVarChar: Variant 데이터 형식을 사용하는 필드를 만드는 표준 ADO 상수입니다.
  • MaxCharacters: Variant 필드에 들어갈 수 있는 최대 문자 수(예: 255)를 나타내는 ADO 상수입니다.
  • adDouble: 마지막 ADO 상수로, 실수(Double) 데이터 형식을 사용하는 필드를 만드는 데 사용됩니다.
상수를 정의한 후에는 다음 코드 블록이 나옵니다.
Set DataList = CreateObject _
    ("ADOR.Recordset")
DataList.Fields.Append "Player", _
    adVarChar, MaxCharacters
DataList.Fields.Append "HomeRuns", _
    adDouble
DataList.Open
스크립트의 이 부분에서 연결이 끊긴 레코드 집합을 실제로 설정하고 구성하게 됩니다. 이 작업을 수행하기 위해서는 먼저 ADOR.Recordset 개체의 인스턴스를 만들어야 합니다. 잘 알겠지만 이 개체는 가상 데이터베이스 테이블(즉, 연결이 끊긴 레코드 집합)을 만듭니다.
그리고 다음 코드 줄과 Append 메서드를 사용하여 레코드 집합에 새 필드를 추가합니다.
DataList.Fields.Append "Player", adVarChar, MaxCharacters
보다시피 복잡할 것이 하나도 없습니다. 다음 매개 변수 3개를 사용하여 Append 메서드를 호출하기만 하면 되니까요.
  • 필드 이름(Players)
  • 필드의 데이터 형식(adVarChar)
  • 필드에 저장할 수 있는 최대 문자 수(MaxCharacters)
Players 필드를 추가한 후에는 실수(adDouble) 데이터 형식 필드인 HomeRuns를 추가합니다. 필드를 모두 추가했으면 Open 메서드를 호출하여 레코드 집합이 열려 있으며 사용할 준비가 되었음을 선언합니다.
다음으로 Scripting.FileSystemObject의 인스턴스를 만들고 C:\Scripts\Test.txt 파일을 엽니다. 스크립트의 이 부분은 연결이 끊긴 레코드 집합과는 실질적인 관련이 없으며 단지 텍스트 파일에서 데이터를 검색하는 데 사용됩니다. 텍스트 파일의 첫째 줄에는 헤더 정보가 들어 있습니다.
Player     Home Runs     RBI        Average
예제 레코드 집합에는 이 정보가 필요 없기 때문에 파일을 연 후에 가장 먼저 SkipLine 메서드를 호출하여 첫째 줄을 건너뜁니다.
objFile.SkipLine
이제 실제 데이터가 있는 첫째 줄로 이동했으므로 파일의 나머지 내용을 줄 단위로 읽을 수 있는 Do Until 루프를 설정합니다. 파일에서 한 줄씩 읽을 때마다 해당 값이 strLine라는 변수에 저장되고, Split 함수가 탭에 도달할 때마다 줄바꿈하여 데이터 줄을 값의 배열로 변환합니다.
arrStats = Split(strStats, vbTab)
요점만 간단하게 설명했지만 텍스트 파일에서 정보를 검색하는 방법을 모두 잘 아시리라 믿습니다. 간단히 요약해서 루프를 처음 실행하면 arrStats라는 배열에 그림 3의 항목이 포함됩니다.
그림 3 배열 내용
Item Number | Item Name
0 | D Pedroia
1 | 4
2 | 28
3 | .276
이제부터 흥미로워집니다.
DataList.AddNew
DataList("Player") = arrStats(0)
DataList("HomeRuns") = arrStats(1)
DataList.Update
여기서는 선수 1(D Pedroia)에 대한 정보를 연결이 끊긴 데이터 집합에 추가합니다. 레코드 집합에 레코드를 추가하려면 먼저 AddNew 메서드를 호출합니다. 그러면 작업에 사용할 수 있는 빈 새 레코드가 만들어집니다. 다음 코드 두 줄에서는 두 레코드 집합 필드(Player 및 HomeRuns)에 값을 할당하고 Update 메서드를 호출하여 해당 레코드를 레코드 집합에 정식으로 씁니다. 그리고 다시 루프의 맨 위로 돌아와서 파일의 다음 줄(다음 선수)에 대해 프로세스를 반복합니다. 간단하지 않습니까? 코드가 많기는 하지만 모두 간단하고 이해하기 쉽습니다.
레코드 집합에 선수가 모두 추가된 후에는 어떻게 될까요? 텍스트 파일을 닫은 후 다음 코드 블록을 실행합니다.
DataList.MoveFirst

Do Until DataList.EOF
  Wscript.Echo _
    DataList.Fields.Item("Player") & _
    vbTab & _
    DataList.Fields.Item("HomeRuns")
  DataList.MoveNext
Loop
첫째 줄에서는 MoveFirst 메서드를 사용하여 커서를 레코드 집합의 시작 부분으로 이동합니다. 이렇게 하지 않으면 레코드 집합에 데이터 중 일부만 표시될 수 있습니다. 다음으로 더 이상 처리할 데이터가 없을 때까지, 즉 레코드 집합의 EOF(end-of-fle) 속성이 True일 때까지 계속 실행되는 Do Until 루프를 설정합니다.
이 루프에서는 Player 필드와 HomeRuns 필드의 값을 출력할 뿐입니다. 여기서는 특정 필드를 나타내는 데 DataList.Fields.Item("Player")과 같은 다소 특이한 구문이 사용되었습니다. 이제 MoveNext 메서드를 호출하여 레코드 집합의 다음 레코드로 이동하면 됩니다.
두말할 필요도 없을 정도로 쉽습니다. 루프 실행이 완료되면 다음과 같은 결과를 얻게 됩니다.
D Pedroia       4
K Kouzmanoff    8
J Francouer     7
C Guzman        5
F Sanchez       2
I Suzuki        3
J Hamilton      17
I Kinsler       7
M Ramirez       12
A Gonzalez      17
그런데 이 결과만 봐서는 전혀 유용할 것이 없어 보입니다. 선수 이름과 홈런 합계가 그대로 출력되었을 뿐이고 홈런 수를 기준으로 정렬되지는 않았습니다. 왜 연결이 끊긴 레코드 집합이 데이터를 자동으로 정렬해 주지 않은 것일까요?
사실 합당한 이유가 있습니다. 정렬 기준이 될 필드를 지정하지 않았기 때문입니다. 하지만 MoveFirst 메서드 호출 바로 앞에 정렬 정보가 추가되도록 스크립트를 수정하기만 하면 됩니다. 즉, 스크립트의 해당 부분이 다음과 같이 됩니다.
DataList.Sort = "HomeRuns"
DataList.MoveFirst
여기서도 특별한 비법은 필요 없고 HomeRuns 필드에 Sort 속성을 할당하기만 하면 됩니다. 스크립트 실행 후 출력되는 결과를 살펴보겠습니다.
F Sanchez       2
I Suzuki        3
D Pedroia       4
C Guzman        5
J Francouer     7
I Kinsler       7
K Kouzmanoff    8
M Ramirez       12
J Hamilton      17
A Gonzalez      17
이제야 제대로 된 것 같군요. 한 가지만 빼고 말이죠. 보통 홈런 기록은 홈런을 가장 많이 친 선수가 맨 위에 오는 내림차순으로 나열됩니다. 그렇다면 연결이 끊긴 레코드 집합을 내림차순으로 정렬할 방법은 없을까요?
물론 있습니다. 다음과 같이 유용한 DESC 매개 변수를 추가해야 합니다.
DataList.Sort = "HomeRuns DESC"
DESC 매개 변수는 어떤 역할을 할까요? 바로 결과를 다음과 같이 정렬하는 것이죠.
A Gonzalez      17
J Hamilton      17
M Ramirez       12
K Kouzmanoff    8
I Kinsler       7
J Francouer     7
C Guzman        5
D Pedroia       4
I Suzuki        3
F Sanchez       2
여러 속성을 기준으로 정렬하는 데도 아무 문제가 없습니다. 정렬 순서에 각 속성을 할당하기만 하면 됩니다. 예를 들어 먼저 홈런을 기준으로 정렬하고 다시 타율을 기준으로 정렬하려면 다음 명령을 사용하면 됩니다.
DataList.Sort = "HomeRuns DESC, RBI DESC"
직접 스크립트를 실행하여 결과를 확인해보십시오. 휴가지에서 전자 메일을 확인할 때만큼 신나지는 않겠지만 나름대로 재미가 있을 겁니다.
참고 레코드 집합에 추가되지 않은 필드를 기준으로 정렬할 수는 없습니다. 이것이 의미하는 바가 무엇일까요? Sort 문에 RBI와 같은 속성을 추가하기 전에 스크립트의 적절한 위치에 다음 코드 줄을 추가해야 함을 의미합니다.
DataList.Fields.Append "RBI", adDouble

DataList("RBI") = arrStats(2)
출력 결과를 확인하려면 Wscript.Echo 문도 다음과 같이 수정해야 합니다.
Wscript.Echo _
  DataList.Fields.Item("Player") & _
  vbTab & _
  DataList.Fields.Item("HomeRuns") & _
  vbTab & DataList.Fields.Item("RBI")
연결이 끊긴 레코드 집합으로 또 무엇을 할 수 있을까요? 한 가지 들자면 모든 선수에 대해 모든 정보를 검색하여 타율을 기준으로 데이터를 정렬할 수 있습니다. (그렇게 하려면 우선 RBI와 BattingAverage라는 필드를 만들도록 원래 스크립트를 수정해야 합니다.) 출력은 다음과 같습니다.
J Hamilton      17      67      0.329
I Kinsler       7       35      0.309
A Gonzalez      17      55      0.304
C Guzman        5       20      0.299
M Ramirez       12      39      0.295
I Suzuki        3       15      0.287
D Pedroia       4       28      0.276
K Kouzmanoff    8       25      0.269
J Francouer     7       35      0.254
F Sanchez       2       25      0.238
좋습니다. 그런데 타율이 .300 이상인 선수 목록을 표시하려면 어떻게 해야 할까요? 즉, 특정 조건에 맞는 선수만 표시되도록 데이터를 제한하려면 어떻게 해야 할까요? 한 가지 방법으로 레코드 집합에 Filter를 지정할 수 있습니다.
DataList.Filter = "BattingAverage >= .300"
일반적으로 레코드 집합 필터는 데이터베이스 쿼리와 같은 용도로 사용됩니다. 즉, 반환된 데이터를 레코드 집합의 일부 레코드로 제한하는 메커니즘을 제공합니다. 예제의 경우 BattingAverage 필드 값이 30 이상인 레코드만 남기고 나머지는 모두 제외시키는 Filter를 지정하면 됩니다. 그러면 바로 우리가 원하는 다음과 같은 결과를 얻게 됩니다.
J Hamilton      17      67      0.329
I Kinsler       7       35      0.309
A Gonzalez      17      55      0.304
우리 애들도 지금 여러분과 같은 반응을 보여 주면 좋을 텐데 말이죠.
그건 그렇고 단일 필터에 여러 조건을 사용할 수도 있습니다. 예를 들어 다음 명령은 반환되는 데이터를 BattingAverage 필드가 .300 이상이고 HomeRuns 필드가 11 이상인 레코드로 제한합니다.
DataList.Filter = _
  "BattingAverage >= .300 AND HomeRuns > 10"
반면 다음 필터는 BattingAverage 필드가 .300이거나 HomeRuns 필드가 11 이상인 레코드로 데이터를 제한합니다.
DataList.Filter = "BattingAverage >= .300 OR HomeRuns > 10"
두 스크립트를 모두 실행해보면 그 차이를 확인할 수 있을 겁니다. 흠, 내친 김에 다음 필터도 한번 실행해보십시오.
DataList.Filter = "Player LIKE 'I*'"
여기서 보듯이 필터에 와일드카드도 사용할 수 있습니다. 와일드카드를 사용하려면 등호 대신 LIKE 연산자를 사용하고 dir C:\Scripts\*.txt 같은 MS-DOS® 명령을 사용할 때처럼 별표를 사용합니다. 위의 예제 스크립트를 실행하면 이름이 문자 I로 시작하는 선수 목록이 출력됩니다. "그 다음 문자는 관계없이 Player 필드 값이 I로 시작하는 모든 레코드의 목록을 표시"하도록 지시하는 구문을 사용했기 때문입니다. 이제 무슨 말을 할지 이미 눈치챘으리라 믿습니다. 맞습니다. 직접 실행해보십시오.
그런데 타율이 0.309로 표시되는 데 대해서는 걱정할 필요가 없습니다. (일반적으로 타율은 앞에 0을 붙이지 않고 .309와 같이 표시합니다.) FormatNumber 함수를 사용하면 원하는 방식으로 타율의 형식을 지정할 수 있으니까요.
FormatNumber (DataList.Fields.Item("BattingAverage"), 3, 0)
숫자를 표시할 때 이 함수를 Wscript.Echo 문에 추가하기만 하면 됩니다. (또는 출력 결과에 변수를 할당하고 해당 변수를 Echo 문에 추가해도 됩니다.)
Wscript.Echo _
  DataList.Fields.Item("Player") & _
  vbTab & _
  DataList.Fields.Item("HomeRuns") & _
  vbTab & DataList.Fields.Item("RBI") & _
  vbTab & _
  FormatNumber _
  (DataList.Fields.Item("BattingAverage"), _
   3, 0)
재미 있으셨습니까?
아쉽게도 이번 달 칼럼은 여기서 마무리해야겠군요. 마지막으로 요약하자면... 아, 죄송합니다. 전화가 오는군요.
어쨌든 마지막으로 하고 싶은 말은... 이런, 이번에는 휴대폰이 울리는군요. 토스터가 이런 전자 메일도 보냈고요. "중요: 따끈한 토스트가 준비되었습니다. 버터와 잼 중 무엇을 바를까요?" 어쩔 수 없이 이만 끝내야 할 것 같습니다. 하지만 다음 달에 다시 만날 테니 너무 아쉬워하지는 마십시오.
Dr. Scripto의 Scripting Perplexer
매달 퍼즐 풀기 실력뿐만 아니라 스크립팅 능력까지 시험해 볼 수 있는 문제입니다.

2008년 9월: 스크립팅 단어 찾기
간단한(어려울 수도 있겠지만) 단어 찾기 퍼즐을 하나 소개하겠습니다. 목록에서 VBScript 함수와 명령문을 모두 찾으면 됩니다. 한 가지 알아야 할 점은 나머지 문자를 조합하면 Windows PowerShell™ cmdlet가 된다는 사실입니다.
단어 목록: Abs, Array, Atn, CCur, CLng, CInt, DateValue, Day, Dim, Else, Exp, Fix, InStr, IsEmpty, IsObject, Join, Len, Log, Loop, LTrim, Mid, Month, MsgBox, Now, Oct, Replace, Set, Sin, Space, Split, Sqr, StrComp, String, Timer, TimeValue, WeekdayName.

정답:
Dr. Scripto의 Scripting Perplexer
정답: 2008년 9월: 스크립팅 단어 찾기

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


The Desktop Files WDS의 고급 기능
Wes Miller

목차
명령줄 관리
이미지 저장소
멀티캐스트
WDS 로깅
기타 문제
요약
지난 두 회에 걸쳐 WDS(Windows 배포 서비스)에 대해 살펴보았습니다. 먼저 Microsoft에서 출시한 PXE(Pre-boot eXecution Environment) 기반 배포 도구의 역사를 살펴본 다음 WDS의 개요를 설명했습니다. 이번 달에는 더 고급 주제로 들어가 보겠습니다.
살펴볼 대상은 WDSUtil(WDS를 위한 강력한 명령줄 유틸리티), WDS 이미지 저장소, WDS 로깅, 그리고 Windows Server® 2008용 WDS의 멀티캐스트 기능 사용 방법입니다.
Windows® 2000 및 Windows Server 2003에 탑재된 RIS(원격 설치 서비스)는 많은 사람들의 기대와 달리 그다지 기능이 풍부하지 않았습니다. 특히 다음과 같은 세 가지 영역에서 이 현상이 두드러졌습니다.
  • 성능(보다 확장성 높은 배포)
  • 로깅/감사
  • 명령줄 자동화
이번 달 칼럼을 읽으면서 알게 되겠지만 WDS의 첫 릴리스, 더 구체적으로 말하자면 Windows Server 2008의 WDS 릴리스에서는 이러한 세 가지 영역 각각에 대해 상당한 진전이 이루어졌습니다.

명령줄 관리
필자는 지난 달 WDS가 훨씬 더 향상된 관리 콘솔을 제공한다고 언급했습니다. 그러나 대부분의 기업들에게 더 중요한 점은 WDS가 관리를 위한 새로운 명령줄 유틸리티인 WDSUtil.exe(그림 1 참조)를 제공한다는 사실입니다. WDSUtil은 Windows Server 2003(SP1+WDS 또는 SP2)에서 WDS Optional Component와 함께 설치됩니다.
그림 1 WDSUtil을 사용하여 architecture discovery 옵션을 yes로 설정(더 크게 보려면 이미지를 클릭하십시오.)
WDSUtil은 놀라울 정도로 강력한 유틸리티지만 복잡합니다. 실제로 MMC(Microsoft® Management Console)를 사용하여 할 수 있는 모든 작업, 그리고 그 이상을 WDSUtil을 통해 수행할 수 있습니다. 사실 문제가 발생한 경우 이를 분석하기 위한 가장 좋은 방법 중 하나이기도 합니다. 이 유틸리티의 사용 예를 보려면 다음을 실행해 보십시오.
wdsutil /get-server /show:config
실행 결과는 WDS MMC에서 볼 수 있는 부분을 거의 모두 반영합니다. 다만 WDSUtil은 읽기 쉬운 형식으로 출력할 수 있으며, 여러분은 이를 다시 텍스트 파일로 출력할 수 있습니다.
정보가 부족하다구요? 다음 명령을 실행하면 더 많은 결과가 반환됩니다.
wdsutil /get-server /show:all /detailed
그리고 다음을 실행하면 WDS 서버를 중지한 후 다시 시작할 수 있습니다.
wdsutil /stop-server
wdsutil /start-server
go.microsoft.com/fwlink/?LinkId=112194에서 WDSUtil을 위한 명령 참조를 볼 수 있습니다. 원할 경우 go.microsoft.com/fwlink/?LinkId=89381에서 이 참조의 .chm 버전을 WDS 2008 문서와 함께 다운로드할 수 있습니다.
Active Directory® 서비스 인터페이스의 달인이 아닌 한 RIS에서는 명령줄을 통해 특정 MAC 주소 또는 GUID가 Active Directory의 MAO(Machine Account Object)와 연결되었는지 여부를 쉽게 확인할 방법이 없었습니다. WDSUtil을 사용하면 이 두 가지 중 하나를 기반으로 쿼리할 수 있습니다.
GUID는 이진 문자열 또는 GUID로 입력이 가능하게 때문에 혼란스러울 수 있으며 다른 점은 바이트 순서와 하이픈의 부재밖에 없습니다. MAC 주소는 다음 코드 줄 중 하나를 사용하여 하이픈과 함께, 또는 하이픈 없이 입력할 수 있습니다.
wdsutil /get-device /id:01-23-45-67-89-AB
wdsutil /get-device /id:0123456789AB
다음 명령을 사용하여 이진 문자열로 장치 정보를 가져올 수 있습니다.
wdsutil /get device /id:ACEFA3E81F20694E953EB2DAA1E8B1B6
또는 다음 명령을 사용하여 GUID 문자열로 장치 정보를 가져올 수 있습니다.
wdsutil /get device /id:E8A3EFAC-201F-4E69-953-B2DAA1E8B1B6
여러분의 컴퓨터 중 상당수는 아마 64비트 버전의 Windows를 실행할 수 있겠지만 일부는 아키텍처를 제대로 보고하지 못합니다. WDS의 일부로 제공되는 작은 네트워크 부팅 프로그램을 실행하여 시스템이 64비트를 지원하는지 여부를 WDS 스스로 확인하도록 할 수 있습니다. 그림 1에서 볼 수 있듯이 다음을 통해 이를 수행할 수 있습니다.
wdsutil /set-server /architecturediscovery:yes
사실 WDSUtil /set-server 명령을 사용하면 많은 서버 설정을 구성할 수 있습니다. 다음 명령을 실행하면 가능한 항목을 볼 수 있습니다.
wdsutil /set-server /?
Windows Server 2003 WDS 서버를 Windows Server 2008로 업그레이드한 경우 다음을 실행하면 모든 RIPrep 이미지를 WIM(Windows 이미징 형식) 이미지로 변환할 수 있습니다.
WDSUtil /convert-RIPrepImage
WDSUtil은 RIPrep 이미지를 변환할 수 있지만 나머지 RISetup 이미지(기존 RIS/레거시 WDS 스크립트 설치)는 변환할 수 없습니다.
WDSUtil의 강력함은 반복적인 작업을 자동화하는 기능에 있습니다. 그림 2의 명령을 통해 WDSUtil의 기능을 엿볼 수 있습니다. WDS 서버를 배포하는 경우든, 여러 서버에 걸쳐 이미지를 추가 또는 수정하는 경우든, 멀티캐스트 인프라를 관리하는 경우든, 특정 부팅 클라이언트에 사용할 네트워크 부팅 프로그램을 지정하는 경우든 WDSUtil은 이전의 RIS에서는 볼 수 없었던 강력한 기능을 제공합니다.
그림 2 WDSUtil 명령
명령 | 설명
/add | 장치, 이미지 또는 이미지 그룹을 추가합니다.
/approve-AutoAddDevices | 보류 중인 Auto-Add 장치를 승인하고 이에 대한 구성 정보를 설정하도록 합니다.
/convert-RiprepImage | 기존 RIPrep 이미지를 WIM 이미지로 변환합니다.
/copy-Image | 이미지 저장소 내에서 이미지를 복제합니다.
/delete-AutoAddDevices | 보류 중인 모든 또는 특정 Auto-Add 장치를 삭제합니다.
/disable | WDS 서버 또는 전송 서버를 비활성화합니다.
/disconnect-Client | 멀티캐스트 전송 또는 네임스페이스로부터 클라이언트의 연결을 해제합니다.
/enable | WDS 서버 또는 전송 서버를 활성화합니다.
/export-Image | ImageX의 /export와 마찬가지로 이미지 저장소의 기존 이미지를 WIM 이미지로 내보냅니다.
/get | 장치, 이미지, 이미지 그룹, WDS 서버 또는 전송 서버에 대한 속성 및 특성을 가져옵니다.
/initialize-Server | 처음 설치한 후 WDS 서버를 사용하도록 구성합니다.
/new | 캡처를 만들거나 이미지, 멀티캐스트 전송 및 네임스페이스를 검색합니다.
/progress | 주어진 명령이 실행되는 동안 진행률을 표시합니다.
/reject-AutoAddDevices | 보류 중인 모든 또는 특정 Auto-Add 장치를 거부합니다.
/remove | 이미지, 이미지 그룹, 멀티캐스트 전송 및 네임스페이스를 제거합니다.
/replace-Image | 이미지를 새 이미지로 대체합니다(덮어씀).
/set | 장치, 이미지, 이미지 그룹, WDS 서버 또는 전송 서버에 대한 속성 및 특성을 설정합니다.
/start | WDS 서버 또는 전송 서버를 시작합니다.
/stop | WDS 서버 또는 전송 서버를 중지합니다.
/uninitialize-Server | 서버 초기화 중에 수행된 서버의 변경 사항을 되돌립니다(구성되지 않은 상태로 되돌림).
/update-ServerFiles | 서버의 REMINST 공유에 있는 파일을 서버의 System32\RemInst 디렉터리에 있는 최신 버전으로 업데이트합니다.
/verbose | 주어진 명령이 실행되는 자세한 정보 출력을 표시합니다.

이미지 저장소
지난 달 필자는 RIS에서 디스크에 보다 효율적으로 파일을 저장하는 데 사용된 SIS(단일 인스턴스 저장소)가 WDS에서는 어째서 배제되었는지에 대해 설명했습니다. 이제 모든 기본 모드(WIM) 이미지는 OS에 관계없이 WDS 이미지 저장소에 보관됩니다. 지난 칼럼에서 언급했듯이 이 단일 인스턴스 기능은 볼륨 이미지에 관련 파일이 있는 경우 .wim 파일의 공간을 줄일 수 있도록 해 줍니다. WDS 이미지 저장소도 마찬가지 기능을 합니다. 실제로 WDS 이미지 저장소는 WIM 기능을 사용하여 이미지를 저장합니다.
이미지 저장소를 사용하려면 적어도 하나 이상의 이미지 그룹이 있어야 합니다. WDS를 초기화하면 일반적으로 이미지 그룹을 만들라는 메시지가 표시됩니다. 설치 이미지를 추가할 때 새 이미지 그룹을 만들 수도 있으며, 그러면 이 이미지 그룹에 이미지가 추가됩니다(그림 3 참조).
그림 3 새 이미지 그룹 만들기(더 크게 보려면 이미지를 클릭하십시오.)
그렇다면 이미지 저장소는 무엇일까요? RemoteInstall 디렉터리의 Images 디렉터리를 보면 여러분이 만든 각 이미지 그룹에 대한 디렉터리를 찾을 수 있습니다. 그림 4에서 볼 수 있듯이 이미지 그룹으로 가져온 각 설치 이미지별로 하나의 .wim 파일과 하나의 .rwm파일(Resource WIM)이 있습니다.
그림 4 이미지 그룹의 내용(더 크게 보려면 이미지를 클릭하십시오.)
그림 4의 파일을 자세히 살펴보십시오. 이 이미지 그룹은 다음과 같이 구성되어 있습니다.
  • install.wim(Windows Server 2008, Standard Edition)
  • install-(2).wim(Windows Server 2008, Enterprise Edition)
  • install-(3).wim(Windows Server 2008, Datacenter Edition)
  • install-(4).wim(Windows Server 2008, Standard Edition(Server Core)
  • install-(5).wim(Windows Server 2008, Enterprise Edition(Server Core)
  • install-(6).wim(Windows Server 2008, Datacenter Edition(Server Core)
이제 이러한 파일의 크기를 그림 5에 나온 MMC의 파일 크기와 비교해 보십시오. 그림 4의 각 .wim 파일 크기는 Res.rwm 파일에 비해 훨씬 더 작습니다. 왜일까요? 공간 절약을 위해 그림에 표시된 .wim 파일은 실제 파일의 스텁일 뿐입니다. 여기에는 .wim 파일을 복원하기 위한 메타데이터가 포함되지만 실제 파일 리소스는 포함되어 있지 않습니다. 이미지 그룹의 모든 파일 리소스는 해당 이미지 그룹에 대한 .rwm 파일에 저장됩니다.
그림 5 서버 관리자에 표시되는 이미지 (더 크게 보려면 이미지를 클릭하십시오.)
이미지 저장소의 설치 이미지를 편집하려면 이미지를 내보내고 편집한 다음 이미지를 대체(또는 다시 가져옴)하거나, MMC에서 해당 설치 이미지를 비활성화하고 .wim 파일을 탑재 및 수정하여 편집하는 방법 중 하나를 사용할 수 있습니다.
RIS의 고질적인 문제는 이미지 복제였습니다. 네트워크를 통해 SIS 파일을 복사하면 SIS는 NTFS 특성이므로 손실됩니다. 즉, 40GB 용량의 RISetup 및 RIPrep 이미지가 있고, 이를 다른 서버로 복제할 경우 SIS Groveler에 의해 이 크기가 5GB까지 줄어들더라도 네트워크에서는 여전히 40GB의 용량을 복제하게 됩니다. WDS 이미지 저장소에서는 이런 일이 발생하지 않습니다. 사실 이미지 저장소는 아키텍처 특성상 DFS(분산 파일 시스템) 서버에 저장하고 DFS-R(DFS-복제)를 사용하여 이 사이트에서 저 사이트로 복제할 수 있습니다.
이에 대한 세부 사항은 WDS의 버전에 따라 다릅니다. Windows Server 2003의 경우 go.microsoft.com/fwlink/?LinkId=81031에서 다운로드할 수 있는 설명서의 7장 "이미지 작업"을 참조하십시오. Windows Server 2008의 경우 go.microsoft.com/fwlink/?LinkId=121960의 “DFS를 사용하여 이미지 저장 및 복제”를 참조하십시오. 모든 리소스는 .rwm 파일로 저장되므로 한 서버의 이미지 그룹을 다른 서버로 복사하는 경우에도 네트워크를 통해 전송되는 데이터의 양은 전체 .wim 파일이 전송되는 경우(기존 RIS SIS 아키텍처)에 비해 훨씬 더 적습니다..
그렇다면 언제 새 이미지 그룹을 만들고, 언제 기존 이미지 그룹을 사용할까요? 이 규칙은 대체로 .wim 파일에 대한 규칙과 동일합니다. 대부분 Windows Server 2008 이미지로 구성된 이미지 그룹에 Windows XP Professional SP3 이미지를 넣을 수는 있지만 이 경우 절약되는 공간이 많지 않으므로 별 효과가 없습니다. .wim 파일의 경우와 마찬가지로 최소 다음에 대한 이미지 그룹이 있어야 합니다.
  • 각 특정 Windows 릴리스 - 여기에서 릴리스는 SKU(Windows XP Professional) 및 서비스 팩 수정 버전(SP3)입니다.
  • Windows Server 2003 및 이전 버전: 지역화된 각 언어 릴리스(다국어 사용자 인터페이스 아님). Windows Vista® 이전에는 각 지역화된 빌드는 서로 완전히 다른 바이너리이므로 단일 인스턴싱 측면에서 .wim 파일에 제대로 저장되지 않습니다.
  • 각 릴리스의 각 서비스 팩. Windows Server 2008과 Windows Vista SP1 이미지를 함께 저장할 수는 있지만 이 기능이 현재 조직 내에서 적절한지 여부를 검토하십시오.
이미지 저장소는 디스크와 네트워크 전송 두 가지 측면 모두에서 이전의 SIS보다 공간 절약 능력이 더 뛰어나고, 일반적으로 별다른 작업 없이도 잘 작동합니다.

RIS의 가장 큰 약점 중 하나는 확장성의 부재였습니다. 멀티캐스트 배포는 이 문제를 수정하기 위한 것입니다. 사람들은 흔히 멀티캐스트를 “더 빠른” 배포로 생각하지만 사실 멀티캐스트는 “더 빨리”가 아닌 “더 많이”를 위한 개념입니다. RIS를 통해 여러 시스템에 배포할 수 있습니다. 실제로 RIS는 약 75개 시스템의 배포를 동시에 처리할 수 있습니다.
그러나 이 수에 도달하기 한참 전에 성능이 떨어지기 시작하고 각 설치에 걸리는 시간도 점차 길어지게 됩니다. 게다가 설치 수가 증가할수록 오류 가능성도 함께 증가합니다. 또한 복수 설치로 인해 SMB(서버 메시지 블록) 네트워크 트래픽이 네트워크를 과다하게 소모하고, 이로 인해 배포 중에 직원들이 Microsoft Exchange Server와 같은 중요 네트워크 리소스에 접근할 수 없게 되는 경우도 있습니다.
멀티캐스트는 배포 수를 늘리기 위한 방법입니다. 4대의 서버를 배포하든 100개의 시스템으로 컨퍼런스 센터를 배포하든 관계없이 멀티캐스팅을 사용하면 짧은 시간 내에, 네트워크 과부하를 일으키기 않고 배포를 완료할 수 있습니다. 멀티캐스트를 사용하여 단일 시스템을 배포할 수도 있지만 확장의 이점은 여러 시스템이 전송을 대기하는 경우에만 누릴 수 있습니다.
멀티캐스트를 사용하려면 멀티캐스트를 지원하는 라우터가 있어야 합니다. 일반적으로 이는 IGMP(Internet Group Management Protocol) 스누핑이 활성화되어야 함을 의미합니다. 또한 Windows Vista RTM과 함께 제공되는 버전(2.0)은 멀티캐스트 전송을 수신하는 기능이 없으므로 Windows PE 2.1(Windows Server 2008 RTM 또는 Windows Vista SP1)이 필요합니다.
동일한 네트워크에 여러 WDS(또는 다른 멀티캐스트)가 있는 경우 사용자 지정 IP 주소 범위를 지정해야 합니다. 이는 WDS MMC를 통해 서버를 마우스 오른쪽 단추로 클릭하고 속성, 네트워크 설정 탭을 차례로 클릭하여 손쉽게 변경할 수 있습니다.
멀티캐스트 브로드캐스트를 수행하는 경우 멀티캐스트 서버는 가장 느린 클라이언트가 수신할 수 있는 속도에 맞추거나 좀더 높은 속도를 정해놓고 여기에 미치지 못하는 클라이언트를 버릴 수 있습니다. 안정성을 위해 WDS는 가장 느리게 전송을 수신하는 클라이언트의 속도에 맞춰 실행됩니다.
전송 성능이 예상보다 낮게 나올 경우 wdsutil /Get-MulticastTransmission/Show-clients를 실행하십시오. 그러면 전송을 제한하는 마스터 클라이언트가 표시됩니다. 해당 클라이언트의 연결을 해제하면 클라이언트는 멀티캐스트 대신 SMB를 사용하도록 되돌아갑니다. 느린 클라이언트의 연결을 자동으로 해제하는 스크립트의 예는 go.microsoft.com/fwlink/?LinkId=121961에서 볼 수 있습니다.
멀티캐스트 전송을 만들려면 설치 이미지를 마우스 오른쪽 단추로 클릭하고 멀티캐스트 전송 만들기를 선택하거나 WDS 콘솔에서 멀티캐스트 전송을 마우스 오른쪽 단추로 클릭하고 멀티캐스트 전송 만들기를 선택하면 됩니다. 멀티캐스트 전송을 만들 때 자동 캐스트 또는 예약된 캐스트를 만들 수 있습니다. 자동 캐스트는 똑같은 이미지가 필요한 여러 클라이언트가 정기적으로 온라인 상태가 되는 경우 유용합니다. 새 클라이언트는 설치 이미지를 처음 요청한 클라이언트에 의해 시작된 진행 중인 전송에 자동으로 추가됩니다. 예약된 캐스트를 사용하면 그룹 크기를 설정할 수 있습니다. 이 크기에 이르면 전송이 시작됩니다.
지정된 시간에 전송이 시작되도록 설정할 수도 있습니다. 클라이언트가 멀티캐스트 전송을 사용하게 되면 이미지 이름을 클릭하여 이러한 클라이언트를 볼 수 있습니다. 오른쪽 창에는 전송에 연결된 클라이언트에 대한 세부 정보가 표시됩니다.
일반적으로 최종 사용자는 WDS 설치 클라이언트에서 멀티캐스트를 사용합니다. WDSMCast라는 명령줄 유틸리티도 있습니다. 이 유틸리티는 Windows Server 2008 WAIK(Windows Automated Installation Kit)와 함께 제공되며 WDS에서 멀티캐스트 전송을 통해 .wim 파일을 요청할 수 있게 해 줍니다. .wim 파일은 전체로 전송되어 클라이언트에 적용되어야 하므로 저장 및 적용될 이미지를 위한 디스크 공간이 충분한지 확인해야 합니다. 다음 달에는 WDSMCast를 각자의 고유한 사용자 지정 배포 프로세스에 통합하는 방법에 대해 알아보겠습니다.

WDS 로깅
WDS는 많은 로깅 및 추적을 수행할 수 있지만 공간 절약을 위해 기본적으로 이 기능은 비활성화되어 있습니다. 이벤트 로깅에는 클라이언트가 Windows 이벤트 로그에 쓸 때, 그리고 WDS의 다른 측면에 대해 추적 로그에 쓸 때의 두 가지 유형이 있습니다.
그러나 Windows Server 2008에서 WDS는 기본적으로 여러 로깅을 수행합니다. 이러한 로그는 관리 도구 | 이벤트 뷰어에서 볼 수 있습니다. WDS 로그는 이벤트 뷰어를 통해 응용 프로그램 및 서비스 로그 | Microsoft | Windows | 배포 서비스 진단에서 볼 수 있습니다. 이러한 로그는 MMC에서 WDS 역할을 볼 때 표시되는 로그와 동일합니다(그림 6 참조).
그림 6 서버 관리자에서 WDS 이벤트 보기 (더 크게 보려면 이미지를 클릭하십시오.)
WDS 클라이언트 로깅(그림 6의 이벤트 로그에서 볼 수 있음)은 다음 인수로 WDSUtil을 실행하여 시작할 수 있습니다.
wdsutil /wdsclientlogging /enabled:yes /logginglevel:info
WDS의 다양한 하위 구성 요소에 대한 추적 로깅을 활성화할 수도 있습니다. 추적을 구성하려면 그림 7의 레지스트리 키에서 DWORD 레지스트리 값을 적절히 설정합니다. 모든 추적 로그는 \Windows\tracing에 저장됩니다. 로깅을 시작하려면 해당 구성 요소를 다시 시작해야 합니다.
그림 7 추적 로깅 설정
WDS 구성 요소 | 레지스트리 키 | 레지스트리 값 | 로그 이름
서버 | HKLM\SOFTWARE\Microsoft\Tracing\WDSServer\EnableFileTracing | 1 | wdsserver.log
멀티캐스트 | HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSMC\TraceDisabled | 0 | wdsserver.log
관리 구성 요소 | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMGMT\EnableFileTracing | 1 | wdsmgmt.log
MMC | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMMC\EnableFileTracing | 1 | wdsmmc.log
WDS에는 성능 카운터도 있습니다(go.microsoft.com/fwlink/?LinkId=121962에 설명되어 있음). 시스템 성능 문제가 발생할 경우, 또는 미리 시스템 성능 분석을 수행하려는 경우 이 성능 카운터를 모니터링할 수 있습니다. 앞서 언급했듯이 문제가 발생한 경우에는 WDSUtil에서 /detailed, /verbose 또는 /progress 스위치를 사용하여 더 자세한 정보를 얻을 수 있습니다.
WDS 클라이언트와 WDS 서버의 연결 또는 상호 작용에 문제가 있는 경우 Microsoft Netmon(네트워크 모니터)을 사용하여 문제를 디버깅할 수 있습니다. 네트워크 모니터는 go.microsoft.com/fwlink/?LinkId=121491에서 다운로드할 수 있습니다.

기타 문제
언급하고 넘어갈 몇 가지 문제가 있습니다. 첫 번째는 메모리입니다. 기본적으로 WDS는 Windows PE 2.x를 기반으로 한다는 사실을 기억하십시오. 이는 WDS 클라이언트에 최소 384MB의 RAM이 필요함을 의미합니다. 현실적으로 최적의 성능을 위해서는 512MB를 확보해야 합니다. 또한 Windows PE 2.x는 비ACPI(고급 구성 및 전원 인터페이스) 시스템에서는 부팅하지 못하며, 비교적 신형 시스템도 비ACPI 시스템일 수 있다는 점도 알아 두십시오. 비교적 신형 시스템 중 ACPI를 지원하지 않는 시스템에 대한 보고서가 나와 있습니다.
이러한 시스템은 Windows Vista 또는 Windows Server 2008도 지원하지 않습니다. ACPI를 지원하지 않는 시스템의 경우 이러한 클라이언트가 미리 준비되어 있는 Windows Server 2003 또는 그 이전 버전의 WDS나 RIS 서버를 그대로 유지하거나 PXE가 아닌 다른 메커니즘을 통해 Windows를 설치하십시오.
마지막으로, Windows Server 2008의 WDS는 Windows PE 1.x 이미지(RAMDisk 또는 PXE)를 부팅하지 못하므로 서버에서 Windows PE 1.x를 부팅하려면 Windows Server 2003 또는 그 이전 버전의 WDS나 RIS 서버를 사용해야 합니다.

요약
지금까지 WDS의 역사, 기본 사항 및 고급 주제에 대해 살펴보았습니다. 다음 달에는 몇 가지 사용자 지정 WDS 시나리오에 대해, 구체적으로 말하자면 기존 WDS/설치 환경을 사용하지 않고 WDS와 상호 작용하는 방법과 필요한 작업을 수행하도록 WDS를 조정하는 방법에 대해 살펴보겠습니다.

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


Security Watch 암호와 신용 카드 - 제3부
Jesper M. Johansson

목차
비대해진 업데이트 기술
일관성 없는 보안 메시지
기능 확인란 채우기 경쟁
도움 요청
지난 2회의 TechNet Magazine에서 필자는 보안 전문가와 IT 업계가 소비자에게 혼란을 주고 사실상 효과적인 보안 노력을 방해하는 양상에 대해 설명했습니다. 이 시리즈의 첫 2회에서는 소비자에게 잘못된 정보를 제공하고 로그온 워크플로의 부담을 가중시키고
잘못된 행동을 유도하는 문제점에 대해 집중적으로 살펴봤습니다. 지금까지 다양한 예를 통해 소비자의 보안을 우려하는 업계가 사실은 필요 이상으로 상황을 악화시키고 있음을 확인했습니다. 이번 시리즈의 마지막인 3부에서는 소비자에게 제공되는 가장 중요한 기술 중 일부가 어떻게 사용자의 기대에 부응하지 못하는지에 대해 살펴보겠습니다. 모든 내용은 최종적으로 도움 요청으로 이어집니다.

비대해진 업데이트 기술
전자적인 의미에서 안전함을 유지하기 위한 가장 기본적인 원칙이자 필수 요구 사항 중 하나는 소프트웨어를 항상 최신 상태로 유지하는 것입니다. 거의 모든 주요 소프트웨어 공급업체는 최소한 일부만이라도 소프트웨어를 최신 상태로 유지하기 위한 일종의 반자동 메커니즘을 보유하고 있습니다. 그러나 이 과정은 그리 간단하지 않습니다.
우선 소프트웨어가 많을수록 소프트웨어 업데이트도 많아집니다. 또한 많은 업체의 소프트웨어를 사용할수록 더 많은 업데이트 메커니즘을 다루어야 합니다. 이는 혼란을 유발하는 요인입니다.
예를 들어 Internet Explorer®를 기본 상태 그대로 두면 자동으로 업데이트가 수행됩니다. 그러나 Internet Explorer는 사실 다른 기술을 위한 컨테이너일 뿐입니다. 이로 인한 잠재적 영향은 2008년 CanSecWest 컨퍼런스에서 Shane Macaulay가 Java와 Adobe Flash의 취약점을 조합하여 Mac을 해킹한 사례를 통해 엿볼 수 있습니다. 칼럼 작성 시점을 기준으로 이 결함은 아직 공개되지 않은 상태였기 때문에 이와 관련된 세부적인 정보는 거의 없었습니다. 필자가 말하고자 하는 부분은 이 두 기술 모두 기본 제공 구성 요소가 아님에도 불구하고 인터넷에서 너무나 광범위하게 사용되고 있기 때문에 거의 모든 컴퓨터에 설치되어 있다는 점입니다. 이 두 가지 기술은 모두 최신 상태로 유지하기가 까다롭습니다. 각각 자동 업데이트 메커니즘이 있지만 자주 실행되지는 않습니다.
게다가 대부분의 최종 사용자는 이런 기술이 있고 업데이트가 필요하다는 사실조차 알지 못합니다. 많은 경우 이 기술은 컴퓨터의 OEM 이미지로 제공되기 때문에 소비자로서는 운영 체제와 구별할 방법이 없습니다. 최종 사용자 입장에서는 Windows ® Update에서 업데이트가 없다고 하면 그것으로 업데이트는 끝입니다.
두 번째 문제는 업데이트 메커니즘이 필요 이상으로 복잡한 경우가 많다는 점입니다. 완전 자동 모드가 없는 업데이트 메커니즘은 폭넓게 사용되기가 어렵습니다. 대부분의 사용자들은 업데이트 도구를 실행해야 한다는 사실을 모르기 때문입니다. 또한 대부분의 경우 업데이트를 설치하려면 관리자 자격이 필요합니다. 최악의 시나리오에서는 업데이트가 나왔다는 알림조차 관리자 자격이 있어야 받을 수 있습니다.
마지막으로, 사용자가 설치하지도 않은, 전혀 관계 없는 소프트웨어를 배포하는 데 소프트웨어 업데이트 기술을 이용하는 경우가 점차 일반화되고 있습니다. 툴바 따위가 그 예입니다. 소프트웨어 업데이트 기술은 원래 소프트웨어 업데이트 배포라는 특정 목적을 위한 기술이었지만 이제는 부가 소프트웨어를 배포하는 데 사용되는 기술로 변질되었습니다.
이러한 현상을 볼 수 있는 대표적인 두 가지 사례가 Microsoft® Windows Update 서비스(그림 1 참조)와 Apple Software Update(그림 2 참조)입니다. Apple과 Microsoft는 모두 각자의 업데이트 메커니즘을 사용하여 소프트웨어 업데이트뿐만 아니라 사용자가 원래 설치하지 않은 새 소프트웨어까지 배포하기로 결정했습니다.
그림 1 Windows Update를 사용한 Silverlight 배포(더 크게 보려면 이미지를 클릭하십시오.)
그림 2 Apple Software Update를 사용한 Safari 배포(더 크게 보려면 이미지를 클릭하십시오.)
Apple의 경우 사용자가 QuickTime만 설치했더라도 iTunes와 Safari 두 가지가 제시됩니다. 또한 재미있게도 두 가지 모두 기본적으로 선택됩니다.
Windows Update의 경우 업데이트 서비스를 통해 배포된 최근의 새로운 소프트웨어는 Silverlight™입니다. Microsoft는 과거에도 이 방법으로 새 소프트웨어를 배포했습니다. 다만 Microsoft는 새 소프트웨어를 설치하는 확인란은 기본적으로 비워 두었습니다.
업데이트 메커니즘을 사용하여 새 소프트웨어를 배포하는 이 방식으로 인해 사용자는 두 가지 문제를 겪게 됩니다. 첫째, 많은 사용자가 의도하지 않은 소프트웨어를 컴퓨터에 설치하게 됩니다. 주지하다시피 모든 소프트웨어에는 버그가 있고, 이러한 버그 중 일부는 잠재적인 보안 취약점이 될 수 있습니다. 그리고 이러한 취약점 중 일부는 결국 어떤 형태로든 공격에 이용됩니다. 결과적으로 몇몇 사용자는 소프트웨어 업데이트 메커니즘을 통해 컴퓨터에 배포된, 본인에게 필요도 없고 사용하지도 않는 소프트웨어를 통해 공격을 받게 됩니다.
두 번째 문제는 소프트웨어 업데이트 메커니즘의 가치에 대해 사용자들에게 잘못된 인식을 심어줄 수 있다는 점입니다. 소프트웨어 업데이트 메커니즘이 새 업데이트가 아니라 새 소프트웨어를 배포하는 데 이용된다는 사실을 알게 될 경우 사용자는 이 업데이트 메커니즘을 골칫거리로 여기고 사용을 중단할 수 있습니다. 소프트웨어 업데이트 메커니즘을 통해 받은, 본인은 사용하지도 않는 프로그램의 취약점으로 인해 공격을 받게 될 경우 사용자가 어떤 기분을 느낄지 상상해 보십시오.
건전하고 안전한 기술 생태계에 있어서 사용자의 안전을 지켜야 할 기술에 대해 사용자가 신뢰를 잃는 것보다 더 위험한 것은 거의 없습니다. 사용자가 신뢰를 잃은 기술은 외면받고 결국 도태되고 맙니다. 업데이트 기술과 같이 안전을 위해 중요한 기술이 도태된다면 기술 생태계 전체가 위험에 처하게 됩니다. Microsoft가 불법 복제 소프트웨어를 실행하는 것으로 밝혀진 컴퓨터에도 보안 업데이트를 배포하는 것은 이러한 기술 생태계를 보호하기 위해서입니다.
두 회사와 달리 Mozilla Firefox의 깨끗하고 목적이 분명한 업데이트 인터페이스에 대해 필자는 진심으로 경의를 표합니다(그림 3 참조). 필자는 Mozilla가 자체 Software Update 도구를 통한 추가 소프트웨어 배포의 유혹을 계속 뿌리칠 수 있기를 바랍니다.
그림 3 업계에서 가장 깨끗한 편에 속하는 Firefox의 Software Update 인터페이스(더 크게 보려면 이미지를 클릭하십시오.)

일관성 없는 보안 메시지
업계 전체가 소비자를 향한 공통적인 메시지에 합의한다면 얼마나 좋을까요. 경쟁이 업계에서 필수적인 요소라고는 해도 소비자 입장에서는 보안이 무엇을 의미하는지를 알아야 합니다. 그러나 업계에서 서로 엇갈리는 메시지를 전달하는 한 소비자들은 그 의미를 알 수 없습니다. 솔직히 말해 기업들이 각자의 메시지에라도 일관성을 지키면 좋겠습니다.
업계 전체가 공통적인 메시지에 합의할 일은 아마 앞으로도 없겠지만 최소한의 일관성과 정직함은 필요합니다. 고객이 보안 기술에 대해 지속적인 신뢰를 갖는 것이 얼마나 중요한지 감안하면 업계 전체적인 개선이 필요한 상황입니다.
마찬가지로, 우리는 현재 실질적 가치를 제공하는 것이 무엇인지도 물어야 합니다. 예를 들어 필자는 바이러스 백신 소프트웨어가 오늘날 업계에서 사람들에게 각인시킨 것만큼 효과적이지도, 중요하지도 않다고 생각합니다. 필자의 7살짜리 아들이 사용하는 컴퓨터와 집안 부엌에 있는 컴퓨터를 살펴봅시다. 두 컴퓨터에는 모두 바이러스 백신 소프트웨어가 설치되어 있지만 처음 설치한 후 3년 동안 무언가 탐지했다는 경고가 뜬 적은 한 번도 없습니다. 바이러스 백신 소프트웨어를 버리자는 말이 아닙니다. 현재 바이러스 백신은 기술 생태계의 핵심 구성 요소입니다. 모두가 바이러스 백신 소프트웨어를 일시에 제거한다면 공격자는 재빨리 이러한 상황을 이용할테고 그러면 바이러스 감염도 증가할 것입니다.
필자가 말하고자 하는 바는 사용자가 보안 제품에서 정말 필요로 하는 기능이 무엇인지, 이러한 기능이 얼마나 효과적인지, 기업들이 이러한 필요성과 가치를 소비자에게 어떻게 전달할 수 있는지에 대해 업계가 고민해야 한다는 점입니다. 현재 사용자들에게는 서로 모순되고 과장될 뿐만 아니라 많은 경우 사실과 다른 보안 메시지가 과도할 만큼 전달되고 있습니다.

기능 확인란 채우기 경쟁
한 예로 보안 소프트웨어 업계를 보면 끼워넣기가 대세입니다. 현재 보안 소프트웨어는 대부분 전혀 무관해 보이는 기능들이 뒤섞인 꾸러미 형태로 배포됩니다. 게다가 사용자에게 실제로 필요한 기능이 무엇인지에 대한 정보는 제공되지 않습니다.
이러한 상황은 결국 누가 더 많은 기능을 넣느냐의 경쟁으로 치닫습니다. 기능 체크리스트는 제품을 비교하는 데 유용하긴 하지만 이와 동시에 필요하지도, 바람직하지도, 타당하지도 않은 기능까지 포함시키는 부작용을 일으킵니다. 그림 4부터 그림 7까지는 4개의 보안 소프트웨어 업체에서 제공하는 각각의 기능 확인표를 보여 줍니다. 해당 기능이 있음을 의미하는 확인 표시가 17개인 제품이 10개인 제품보다 더 뛰어나다고 단정할 수 있을까요?
사실 필자는 이 그림들을 보면서 우습다는 생각을 했습니다. 그림 4를 보면 제품은 새 버전이라는 이유로 확인 표시 한 개를 받았습니다. 그림 5의 제품은 업체측에서 말하기를 “불법 웹 사이트의 공격을 중단시키는 기능”으로 확인 표시 한 개를 받았습니다. 그림 6의 제품은 “온라인에서 어린이를 보호한다”는 이유로 추가 점수를 얻었습니다. 물론 어린이를 보호하지 못하는 제품은 아무도 원하지 않겠지요. 레지스트리 정리, 하드 디스크 조각 모음과 같은 기능을 보안 제품군에 넣은 1등 제품의 기능 목록은 독창적이기까지 합니다. 레지스트리 정리는 거의 필요가 없는 기능이고, 하드 디스크 조각 모음은 이미 OS에 포함되어 있는 기능입니다. 사실 Windows OS에는 그림 7의 17개 확인 표시 중 15개에 해당하는 솔루션이 이미 포함되어 있습니다.
그림 4 최고급 제품의 확인 표시가 10개뿐입니다.(더 크게 보려면 이미지를 클릭하십시오.)
그림 5 이 제품은 확인 표시가 11개이니까 더 낫겠지요.(더 크게 보려면 이미지를 클릭하십시오.)
그림 6 잠깐만요, 이 제품의 확인 표시는 12개입니다.(더 크게 보려면 이미지를 클릭하십시오.)
그림 7 그러나 17개의 확인 표시가 있는 이 제품이 최고의 솔루션이겠지요? (더 크게 보려면 이미지를 클릭하십시오.)
이러한 확인표 채우기 경쟁 추세는 혼란을 유발합니다. 이들 제품에는 운영 체제에 이미 포함된 기능이 중복되어 있을 뿐만 아니라(마케팅 문구에서는 이러한 사실을 명시하지 않음), 제품에서 주장하는 내용도 사실과 다릅니다. 예를 들어, 현존하는 어떤 보안 소프트웨어도 공격을 중단시키지는 못합니다. 그저 공격을 막는 데 도움을 줄 뿐입니다. 또한 어떤 제품도 공격자로부터 여러분의 존재를 완전히 숨길 수는 없습니다.
문제는 소프트웨어 보안 비즈니스의 주 기반이 다른 업체가 만든 제품에 의해 발생한 취약점으로부터 사용자를 보호하는 데 있다는 점입니다. 그러나 이러한 업체들이 각자의 고객을 스스로 보호하기 위한 기능을 지속적으로 개선함에 따라 보안 소프트웨어 업계의 비즈니스 모델은 위협을 받고 있습니다. 새로운 위험이 드러나면서 보안 소프트웨어 업계에서 제공할 기능의 여지는 많지만 업체들은 사실상 더 이상 위협이 되지 않는 위협에 대비한 방어가 아니라, 고객이 위험을 관리하도록 도와야 합니다.

도움 요청
3부로 구성된 이번 시리즈에서 한 가지만 기억한다면, 그것은 우리 업계가 사용자 및 고객에게 솔직해져야 한다는 점입니다. 우리는 위험에 대해, 그리고 사용자가 이 위험을 처리하는 방법에 대해 설명해야 합니다. 그리고 최종적으로는 사람들이 스스로를 보호할 수 있는 도구를 갖추도록 해야 합니다.
필자가 지금의 이런저런 “솔루션”에서 가장 우려하는 점은 이들로 인해 결국 장기적으로 보안이 약화될 가능성이 높다는 것입니다. 사용자, 심지어 IT 관리자들까지 이러한 제품들이 실제 보안 위험을 해결할 수 있다고 믿게 된다면(특히 제품이 해결할 수 있다고 오도하는 위험들) 우리는 사람들에게 진정 스스로를 보호하는 방법을 알려 줄 기회를 잃을지도 모릅니다.
암호 인증 시스템을 예로 들어 보겠습니다. 이 시리즈의 1부에서 설명한 암호 기반 인증 시스템에 대한 취약한 추가 기능이 실제로 자신을 보호한다고 믿는다면 이 사용자는 결국 더 해이해지고 더 약한 암호를 사용하게 됩니다. 이 시리즈에서 필자가 강조한 최악의 경우에는 기술로 인해 사실상 사용자는 새로운 기술이 구현되지 않은 경우보다 오히려 더 취약한 보안을 사용하게 됩니다. 이는 악의적인 사용자가 이러한 시스템을 무력화하는 방법을 알아낸다면 우리는 지금보다 더 좋지 않은 상황에 처하게 된다는 것을 의미합니다. 이로 인해 심각한 신뢰 문제가 발생하고 사람들은 진정한 가치를 제공하는 솔루션까지 외면하게 됩니다.
바로 지금 우리의 비즈니스를 지탱하는 기술 생태계를 보호하기 위한 조치를 취해야 합니다. 물론 혁신은 독려해야 하지만, 이와 동시에 혁신을 위한 혁신이 실제 위험 분석을 방해하는 일이 없도록 신중을 기해야 합니다. 그렇지 않으면 보안 연극(security theater)만 남게 되고 우리를 둘러싼 이러한 보안 연극은 결국 붕괴될 것입니다.
필자가 언급한 다른 예에서도 마찬가지입니다. 무의미한 보안 표시를 예로 들어 보겠습니다. 이러한 무의미한 보안 표시는 사용자에게 전혀 득이 되지 않으며, 사실과 다른 메시지로 사용자를 안심시키고, 온라인 서비스 공급자가 최적화를 하지 않도록 유도하여 사용자에게 간접적으로 해를 끼칩니다. 한편 사용자에게 올바른 정보를 제공하는 데 드는 비용은 일반적으로 수천 달러, 많아봤자 수만 달러밖에 되지 않습니다. 업체들에게 그들 자신의 고객과 비즈니스를 보호하는 데 이 정도의 비용을 투자하라고 요구한다면 지나치게 무리한 요구일까요?
여기에는 많은 의미가 내포되어 있습니다. 첫째, 사용자는 결정을 내릴 능력이 없고, 사용자가 결정하도록 두어서도 안 된다는 인식부터 고쳐야 합니다. 사용자는 교육을 통해 결정을 내릴 수 있습니다. 따지고 보면 사용자들은 컴퓨터를 구매하기로 결정하거나, 여러분의 사이트를 이용하기로 결정하거나, 여러분의 제품 또는 서비스 중 하나를 구매하기로 결정하는 등 지금까지 많은 결정을 내려 왔습니다. 안전하게 운전하는 방법을 배워야 하듯이 안전하게 컴퓨터를 사용하는 방법만 배우면 됩니다. 오늘날 공격은 사용자를 직접적으로 겨냥하며, 기술에 전적으로 의사 결정을 맡길 수는 없습니다. 대신 보안 기술은 의사 결정을 지원하는 시스템이 되어야 하며 적시에 적절한 정보를 제공하여 사용자가 이성적 결정을 내릴 수 있도록 해야 합니다.
모든 종류의 의사 결정을 사용자에게 보이지 않도록 숨기거나, 가용한 모든 데이터를 무성의하게 사용자에게 쏟아내도록 디자인된 보안 솔루션의 인터페이스는 최악의 사용자 인터페이스에 속합니다. 두 가지 방식 모두 잘못된 것입니다. 올바른 선택을 전적으로 기술에 맡길 수는 없으므로 전자는 사용자를 위험에 처하도록 합니다. 또한 기술이 비즈니스 목표에 방해가 된다고 인식할 경우 사용자는 머지 않아 해당 기술을 사용하지 않게 됩니다. 후자의 방식 역시 실패합니다. 사용자는 IP 주소, 프로세스 ID 및 기타 사용자에게 무의미한 데이터를 붙잡고 씨름하기는 원하지 않기 때문입니다. 사용자는 그저 사용자의 암호와 신용 카드가 컴퓨터에서 어떤 작업에 사용되는지만 알면 됩니다. 결국 바로 이것이 보안의 실질적 의미입니다.

Jesper M. Johansson은 보안 소프트웨어 분야의 소프트웨어 설계자이며 TechNet Magazine의 객원 편집자로서, 정보 관리 시스템 박사 학위를 소지하고 20여 년간 보안 분야에 종사해 온 기업 보안 MVP입니다. 그의 최근 저서로는 Windows Server 2008 Security Resource Kit가 있습니다.


Field Notes 내부로부터의 혁신
Romi Mahajan

저명한 관리 전문가이자 비즈니스 전략가인 Gary Hamel은 그의 저서 The Future of Management에서 그 자체가 관리 기술 발전의 산출물인 혁신 문화를 만들어야만 장기적인 비교 우위를 확보할 수 있다고 주장합니다. 업계는 셀 수 없이 스스로를 혁신하고 재창조했지만 많은 회사가 아직도 계층적 관리 문화에 젖어 있습니다. 계층적 관리 문화는 인간의 창의성과 인적 자본에 상응하는 결과를 내놓지 못하기 때문에 진정한 혁신적 문화 조성을 저해합니다.
이러한 계층은 혁신을 가로막는 걸림돌입니다. 인간의 창의성은 제대로 발휘될 경우 장기적인 혁신 비교 우위를 위한 핵심적 원동력이 됩니다. 창의성이 제한되면 작업자의 80% 이상은 자신이 하는 일에 몰입하지 못합니다. Hamel은 이것이 비즈니스 측면에서뿐만 아니라 윤리적 측면에서도 문제가 된다고 믿고 있습니다.
기본적인 수준에서 보면 이 문제는 업계로 하여금 과도한 계층 없애기에 나설 것을 종용하는 역할을 합니다. 본질적으로 이 논쟁은 애초부터 반관료적입니다. 의사 결정 권력이 업무에 무관한 관리자와 경영진에 맡겨져서는 안 됩니다.
Hamel은 IT가 아니라 관리가 혁신의 근원이라고 주장합니다. 결국 IT가 일용화될 수 있다면 여기에서 어떻게 비교 우위를 얻을 수 있을까요? IT가 혁신의 근원이 아니고 생산성 향상, 가동 시간 연장, 안정성, 새로운 응용 프로그램의 신속한 배치, 그리고 Single Sign-On 등이 비교 우위를 제공하는 요소가 아니라면 우리가 이러한 부분에 대해 고민하는 이유는 무엇일까요?
Hamel의 주장이 타당한지 확인하기 위해 여러분의 IT 조직과 회사를 전체적으로, 깊이 있게 살펴볼 의향이 있습니까? IT가 일용품으로 간주되지 않는다고 어떻게 확신할 수 있습니까?
Hamel이 주장한 내용 중 가장 중요한 개념을 수용하고, 이를 사용하여 혁신의 허브로서 IT 조직이 스스로의 미래를 지키도록 돕기 위해 필자는 내부로부터의 혁신이라는 이론을 만들었습니다. 인간의 창의성과 인적 자본을 최적의 방법으로 사용하는 것은 비교 우위를 유지하기 위한 핵심 요소이며, 뛰어난 조직은 조직의 기능에 혁신을 본질적 요소로 갖추어야 합니다. 조직에서는 관료주의가 아니라 커뮤니티를 받아들여야 합니다. 무엇보다 중요한 점은 진정한 혁신을 관리가 가로막는 경우가 너무나 많다는 사실입니다. 관리가 발전해야 진정한 혁신이 가능합니다.
IT 조직을 살펴봅시다. IT 직원들은 대체로 영리하고 열성적이며 영향력을 행사하기를 갈망합니다. 이들은 적은 리소스로 많은 일을 하도록 요구받는 경우가 많기 때문에 기본 업무를 보는 데 대부분의 시간을 소비하며 혁신을 위한 시간은 거의 갖지 못합니다.
필자가 만든 내부로부터의 혁신 개념은 Hamel의 이론을 IT 영역에 적용합니다. 핵심 원리는 다음과 같습니다.
  • IT 직원들 특유의 창의성을 감안할 때, 이러한 잠재력을 활용하는 IT 관리 모델을 확보하는 것이 가장 유리합니다.
  • 혁신은 IT의 고유한 프로세스인 체계적이고 공격적인 생각-시도-오류-수정 프로세스를 통해 구현됩니다.
  • 커뮤니티를 깊이 있게, 개방적으로 수용하면 기술적인 솔루션이 도출됩니다. IT가 이를 이끌 수 있습니다. 시작해 보십시오!
  • IT에서는 오직 사람이 비교 우위의 근원입니다.
  • 프로젝트 및 예산 중심에서 새롭고 흥미로운 혁신 관리 중심으로 IT 관리를 발전시켜야 합니다.
  • IT의 중심을 비용 억제가 아닌 우수한 결과 생산에 두어야 합니다.
이 이론을 믿을 준비가 되셨습니까? 내부로부터의 혁신 개념을 적용하고, IT 조직이 이러한 원대한 실험을 수행하기에 알맞은 영역임을 증명할 수 있을까요? 관리자들은 권력을 포기하고 커뮤니티를 받아들일 준비가 되어 있습니까? 경영진은 권력을 포기하고 집단 지성을 받아들일 준비가 되어 있습니까?

Romi Mahajan은 Ascentium Corporation의 최고 마케팅 책임자입니다. Ascentium에 입사하기 전에는 Microsoft에서 7년 이상 근무했으며 마지막 직책은 기술 사용자 및 플랫폼 마케팅 부문 책임자였습니다. Romi는 기술, 정치, 경제 및 사회 과학 영역에서 널리 알려진 인사입니다.


Windows Confidential Windows 95 뒷이야기
Raymond Chen

Windows® 95용 32비트 프로그램은 보편적인 32비트 컴파일러로 개발할 수 있었고 16비트 프로그램은 보편적인 16비트 컴파일러로 개발할 수 있었지만 Windows 95 자체를 개발하는 데는 32비트와 16비트 영역을 모두 이해하고 둘 사이를 잇는 특별한 컴파일러가 필요했습니다. 또한 Windows 95에는 이러한 두 가지 유형의 코드를 연결할 줄 아는 사용자 지정 링커도 필요했고, VxD(Windows 95의 드라이버 형식)를 위한 사용자 지정 링커도 필요했습니다.
Windows 95 팀은 언어 및 도구 사업부의 도움을 받아 이러한 특수 목적 컴파일러와 링커를 제공받을 수 있었습니다. 언어 사업부의 입장에서 "X, Y 그리고 Z 작업을 수행하면서, 수명이 다할 때까지 오직 두 개의 DLL을 컴파일하는 데만 사용될 컴파일러를 작성해 달라”라는 요청은 생소하게 들렸을 것입니다. 사실입니다. 다만 이 두 가지는 아주 중요한 DLL이었습니다.
얼핏 말이 안 되는 요청이었지만 어쨌든 언어 및 도구 사업부는 요구 사항에 따랐고, 고도로 전문화된 이 컴파일러와 링커는 Windows 95 빌드 프로세스의 일부가 되었습니다. 물론 컴파일러가 처음부터 완벽하게 제공된 것은 아닙니다. Windows 팀은 예비 버전을 받았고 이후 새로운 최적화가 구현되고 버그가 수정된 업데이트를 정기적으로 받았습니다.
그러던 어느 날 Windows 95 빌드가 예기치 못한 지체에 직면했습니다. 원래 몇 초에 불과했던 파일 링크 시간이 훨씬 더 늘어났던 것입니다. 파일 생성은 여전히 정상적으로 이루어졌지만 시간이 너무 많이 걸렸습니다. 게다가 이 문제는 개발자 한 명의 컴퓨터가 아니라 전체 팀원들에게서 일어났습니다. 코드가 갑자기 링커의 약점을 건드린 것일까요? 아니면 링커의 버그였을까요?
얼마간의 디버깅 후 문제의 근원을 찾았습니다. 최신 버전의 링커에 언어 팀 직원들이 Windows 팀에 코드를 넘기기 전에 깜박하고 제거하지 않은 약간의 진단용 코드가 포함되어 있었던 것입니다. 이 진단용 코드는 출력을 파일에 기록했고, 이 파일은 한 컴파일러 팀원 자리에 있는 컴퓨터에 저장되었습니다. 그런데 이 컴퓨터가 꺼진 것입니다. 이 사건은 분산 시스템을 “다운된 사실이 알려지지 않은 한 컴퓨터로 인해 아무런 작업도 완료할 수 없게 되는 시스템”으로 묘사하여 유명해진 Leslie Lamport를 연상시킵니다.
문제의 링커 버전은 그전까지 몇 주 동안 아무 문제 없이 실행되었습니다. 누군가가 Windows 95를 빌드할 때 VxD를 링크하려고 시도할 때마다 그 컴파일러 팀원의 컴퓨터에 위치한 파일이 업데이트되었습니다. 이 컴퓨터가 켜져 있고 네트워크에 연결되어 있는 동안에는 아무도 문제를 알아채지 못했습니다. 그런데 어느 날 이 컴퓨터가 꺼지면서 모든 작업이 지체된 것입니다.
일단 문제의 원인이 밝혀지자 컴파일러 담당 직원들은 오래지 않아 링커의 진단용 코드를 제거하는 패치를 Winodws 팀에 전달했습니다.
이 이야기에는 화자에 따라 여러 가지 반전이 숨어 있습니다. 필자가 이 이야기를 할 때 반전은 “그 컴파일러 개발자가 나중에 Windows 팀으로 와서 내 상관이 됐잖아”입니다. 필자는 이 이야기를 가벼운 우스개로 종종 써먹곤 합니다.
그런데 필자의 상관이 이야기의 화자라면 반전은 이렇게 달라집니다. “나중에 밝혀진 사실이지만 그 진단용 코드를 작성한 사람은 내가 아니야. 코드의 주인은 내 동료 중 한 명인데, 이 친구가 자기 컴퓨터 대신 내 컴퓨터로 진단 정보가 전송되도록 한 거라구!”

Raymond Chen은 자신의 웹 사이트 The Old New Thing에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있으며 동명의 저서에서도 이에 대해 다루었습니다. Raymond의 DNA는 아마 폐기된 코드로 가득 차 있을 것입니다.