June 2008 June 2008
Security: 대논쟁: 은둔 보안 방식
은둔 보안 방식에서는 공격 요소를 제거하는 대신 감추는 방식을 사용합니다. 일부 사람들은 이것이 좋지 않은 방식이라고 말하고, 또 다른 사람들은 큰 전략의 일부로서 중요하다고 주장합니다. 이 논쟁은 상당히 뜨거우며, 몇몇 유명 보안 전문가들이 은둔 보안 방식에 대한 서로 다른 의견을 제시하며 양쪽으로 의견이 대립되어 있습니다. Jesper M. Johansson and Roger Grimes
Security: 새로운 Windows Vista용 Elevation PowerToy
Michael Murgolo가 Elevation PowerToy 업데이트 버전을 가지고 돌아왔습니다. 타사 스크립팅 도구와 함께 작동되는 향상된 Run as Administrator 기능, Windows Vista에서 제거된 편리한 Windows XP 기능을 대체하는 새로운 방법 및 많은 유용한 도구들이 포함되었습니다. Michael Murgolo
보안: BitLocker 드라이브 암호화의 발전
Windows Vista SP1 및 Windows Server 2008에서는 데이터 볼륨 지원, 암호화 공격에 대한 보호 향상 등 중대한 변화를 BitLocker에 도입했습니다. Byron Hynes가 이러한 새 기능을 살펴보고, 서버에서 BitLocker를 사용하는 방법 및 BitLocker와 관련된 최근의 언론 보도 몇 가지에 대해 설명합니다. Byron Hynes
보안: 소프트웨어 제한 정책을 사용하여 응용 프로그램 잠금
조직에서 사용하는 데스크톱 시스템의 총 소유 비용을 줄이려는 경우, 지원되지 않는 응용 프로그램과 관련된 IT 문제를 응용 프로그램 잠금으로 제한하면 크게 도움이 됩니다. 소프트웨어 제한 정책과 그룹 정책을 사용하여 IT 인프라에서 실행 중인 응용 프로그램을 제어하는 방법을 알려 드립니다. Chris Corio and Durga Prasad Sayana
보안: Windows Vista 방화벽 관리
최근 업데이트된 Windows Vista 방화벽은 인상적인 신기능을 제공하며 기업 환경에 맞는 탁월한 선택이 될 것입니다. Jesper Johansson이 Windows 방화벽의 발전에 대해 간단히 설명하고 새로운 규칙과 프로파일, 도메인 격리, 암호화 등 관리자가 알아야 할 향상된 기능을 자세히 소개합니다. Jesper M. Johansson
보안: 디지털 인증서를 사용하여 전자 메일 보안
S/MIME(Secure Multi-Purpose Internet Mail Extensions)을 통해 전송 도중 정보를 숨기고, 보낸 사람을 확인하고, 메시지를 인증할 수 있습니다. 디지털 인증서를 사용하여 전자 메일의 보안을 유지하는 방법과 S/MIME 시스템에서 발생할 수 있는 문제의 해결 방법을 알아보겠습니다. Matt Clapham and Blake Hutchinson
Columns
From the Editor: 대논쟁: | Letters: 독자의 목소리: | Toolbox: IT 전문가를 위한 새로운 제품:
SQL Q&A: I/O 오류, 데이터베이스 미러링 및 기타: Paul Randal 이사가 SQL Server에 관한 질문에 답변하면서 테스트 데이터베이스에서 손상을 일으키는 방법과 축소-증가-축소-증가의 순환을 피하는 방법을 알려주고 성능 저하 없이 미러링할 수 있는 데이터베이스의 최대수를 결정하는 방법에 대해 설명합니다.Paul S. Randal | Utility Spotlight: Windows Vista 업그레이드 관리자: 사용 중인 시스템을 Windows Vista로 업그레이드할 준비가 되셨나요? Windows Vista 업그레이드 관리자를 사용하여 사용 중인 시스템에서 Window Vista를 지원할 수 있는지 및 지원되는 버전이 무엇인지 확인할 수 있는 방법에 대해 알아봅니다.Lance Whitney | Inside Sharepoint: 사이트 관리 분산화: SharePoint 인프라에 대한 중앙 집중식 관리 제어를 유지하면서 SharePoint 사이트의 관리 제어권을 개별 부서에 위임할 때의 장점과 이러한 위임이 지니는 의미를 살펴보겠습니다.Pav Cherny
Windows PowerShell: 출력 서식 지정하기: Windows PowerShell의 개체 지향 특성을 통해 출력에 서식을 적용하는 방법에 대해 살펴봅니다.Don Jones | Hey, Scripting Guy!: 그리 힘들지 않은 일에도 보상은 있다: Scripting Guys는 고된 업무, 진정한 행복, 그리고 읽을 수 있는 테이블 형식으로 명령 창에 데이터를 출력하는 것에 대해 곰곰이 생각해 봅니다.The Microsoft Scripting Guys | The Desktop Files: 보안과 규정 준수: IT 전문가들은 흔히 서로 모순되는 목표를 발견하곤 합니다. 규정 준수를 위해 보안성을 낮춰야 하는 경우도 종종 있습니다.Wes Miller
The Business of IT: 환경 리더가 되기 위한 10가지 주요 포인트: IT 부서가 기업의 환경 보호를 위한 노력에서 점차 중요한 역할을 담당하게 됨에 따라 IT 전문가는 회사와 업계에서 변화를 이끌고 사고의 리더(Thought Leader)가 되기 위한 기회를 모색하고 있습니다. 여기서는 조직에서 환경 및 지속 가능성 이니셔티브를 이끌어내는 유능한 사고의 리더가 되기 위한 방법을 간략하게 설명합니다.Michael Walsh and Eliza Walsh | Field Notes: 화면 분할 공유: Microsoft Research India에서 개발한 화면 분할 기능을 사용하면 두 사용자가 각각 별도의 OS 인스턴스를 실행하면서 모니터를 공유할 수 있습니다.Kentaro Toyama | Windows Confidential: 가장 최악의 PC 2대: Raymond Chen은 최악의 두 컴퓨터로 작업하던 옛 시절을 회상합니다.Raymond Chen


Security
대논쟁: 은둔 보안 방식
Jesper M. Johansson and Roger Grimes
한 눈에 보기:
  • 은둔 보안 방식 정의
  • 은둔 보안 방식 평가
  • Administrator 계정 이름 바꾸기 가치 평가
  • 정보에 근거한 위험 관리 결정

"은둔 보안 방식"이라는 용어는 보안 관련 종사자, 특히 자신을 전문가라고 생각하는 사람들로부터 조롱을 받기도 합니다. 이 분야에서 거의 상소리에 버금가는
은둔 보안 방식은 Wikipedia(en.wikipedia.org/wiki/Security_through_obscurity)에 나온 대로 보안 분야에서 논란의 중심에 있는 용어 중 하나입니다. 노력이 헛수고가 된 사람들을 놀리며 가리킬 때 흔히 "은둔 보안 방식 같다"라는 소리를 들을 수 있을 것입니다.
은둔 보안 방식은 요약하면 설계가 상대편에게 알려지지 않았기 때문이 아니라 설계 자체로 인해 시스템의 보안이 유지되어야 한다는 Kerckhoffs의 원칙에 어긋납니다. Kerckhoffs 원칙의 기본 전제는 비밀이 오랫동안 비밀로 유지되지 않는다는 것입니다.
좋은 예로 초기에 설계 비밀로 생각되었던 Windows NT® LAN Manager(NTLM) 인증 프로토콜이 있습니다. UNIX 기반 운영 체제용 Samba 상호 운용성 제품을 구현하기 위해 Samba 팀이 프로토콜을 리버스 엔지니어링해야 했습니다. 결과적으로 수많은 버그 발견과 함께 NTLM에 대한 가장 포괄적인 문서(monyo.com/technical/samba/translation/ntlm.en.html)가 작성되었습니다. 대부분의 보안이 암호화를 통해 구현되었고 많은 비밀 설계가 누설됨에 따라 여러 보안 전문가들은 모든 정보 보안이 Kerckhoffs의 원칙을 따라야 한다고 믿고 있습니다.
하지만 은둔 보안 방식이 언제나 좋지 않은 것일까요? 이 기사에서는 은둔 보안 방식이 무엇이고, 많은 사람들이 이를 시간 낭비라고 생각하는 이유(및 그 반대 의견)에 대해 간략히 설명하며, 언제나 그렇듯이 이에 대한 답변이 처음에 생각했던 것보다 매우 복잡한 이유에 대해 살펴봅니다.

은둔 보안 방식 소개
기본 설정 변경 금지 - Steve Riley
저는 이름 바꾸기 문제에서 "바꾸지 말자"는 쪽입니다. 이것은 사실 보안 문제가 아닌 시스템 관리 문제입니다. 시스템 관리 부분에 대한 고민을 할수록(관리와 보안은 하나가 되고 있으므로) 잠재적으로 시스템의 취약성을 높일 수 있는 작업은 하지 않는 것이 좋다는 믿음이 생깁니다. 취약성을 높일 수 있는 한 가지 확실한 방법은 기본 설정을 변경하는 것입니다. 사람들이 기본 설정을 변경하는 이유는 두 가지(또는 세 가지)입니다.
  • 변경을 해야 작동하는 기능이 있습니다.
  • 변경으로 보안이 높아질 것이라는 믿음이 있습니다.
  • (주의: 웃지 말것) 잡지 기사에서 읽었습니다.
첫 번째 이유로 기본 이름을 변경해야 한다면 그렇게 하십시오. 이러한 종류의 변경은 이미 테스트된 경우가 많기 때문에 거의 시스템 취약성으로 이어지지 않습니다.
두 번째 이유로 기본 설정을 변경한다면 일단 중지하고 다시 생각해 보십시오. 이러한 종류의 변경은 소프트웨어 제조업체에서 거의 테스트되지 않았으므로 변경 후 시스템이 어떻게 동작할지 예측할 수 없습니다. 더욱이, 일반적으로 보안 향상을 제공하는 훨씬 더 좋은 대안이 있습니다.
나쁜 사람이 계정 이름을 알게 되었다고 해서 뭐가 달라집니까? 이러한 사람들로부터 시스템을 보호하는 것은 암호 및 암호의 강도입니다. Administrator 및 Guest와 같은 기본 계정 이름을 추측하기 어려운 것으로 변경한다는 것은 사실 강력한 암호 또는 암호 구문을 사용하지 않으려는 의도를 나타냅니다. 진정한 문제(형편없는 암호)를 해결하면 취약성(기본 이름 변경)을 피할 수 있습니다.

은둔 보안 방식에는 문제를 완화하는 조치가 전혀 포함되어 있지 않습니다. 예를 들어, 경계 라우터에서 직원들이 신문을 읽지 못하도록 NNTP(Network News Transfer Protocol)를 차단하지만 아웃바운드 SSH(Secure Shell)를 허용하는 조직에서는 은둔 보안 방식을 사용하지 않습니다. SSH는 모든 프로토콜을 터널링하므로 문제가 숨겨지지 않습니다. 구현된 어리석은 완화 조치는 정당한 사용자가 보안 정책을 위반하지 않고 정당한 작업을 수행하는 것을 방해할 뿐입니다. 이러한 방식은 은둔 보안 방식이 아니며 단지 어리석고 의미가 없는 것입니다.
"은둔 보안 방식"의 "보안"이 의미하는 대로 이 방식에서 어느 정도의 보호를 받습니다. 하지만 실제로 하나 이상의 요소에 대한 공격을 막아내지 못한다는 문제가 있습니다. 공격 요소는 공격자가 시스템에 액세스할 수 있는 방법입니다.
공개 공격 코드를 사용하여 TCP 포트 80을 통해 공격할 수 있는 취약한 웹 서버가 있다고 가정해 보겠습니다. 이 특정 요소를 막으려면 웹 서버를 패치하거나 종료할 수 있는데, 두 방법 모두 이 요소를 완전히 차단할 것입니다. 방화벽 또는 IPsec를 사용하여 일부 컴퓨터를 제외한 모든 컴퓨터에 대해 포트 80을 막아 이 공격 요소를 부분적으로 차단할 수도 있습니다. 이 방법은 공격 요소를 완전히 차단하지는 못하지만 문제를 크게 완화합니다.
반면, 은둔 보안 방식에서는 공격 요소를 차단하지 않고 단지 감추는 조치를 취합니다. 예를 들어, 웹 서버를 알고 있는 사람만 해당 작업을 수행할 수 있도록 웹 서버를 포트 80 대신 81로 이동하기로 결정할 수 있습니다. 여기서도 논란의 여지가 있지만, 실제로 웹 서버를 포트 81로 이동하면 일부 공격은 차단할 수 있지만 대부분 최종 사용자만 불편하게 됩니다. 노련한 침입자는 많은 수의 포트에 대해 포트 검색기 및 웹 배너 수집기를 실행하여 비표준 포트를 사용하는 웹 서버를 찾아냅니다. 침입자가 웹 서버를 찾아낼 경우 실제로는 공격 요소를 없애지 않고 단지 (일시적으로) 감추어 두었기 때문에 서버에 대해 공격을 시작할 수 있습니다.
그렇다면 이러한 방식은 시도할 만한 가치도 없는 것일까요? 대답은 상황에 따라 다릅니다. 정보 보안 분야의 다른 것들과 마찬가지로 모든 것은 위험 관리로 귀속됩니다. 고려할 주요 요소를 이해하려면 몇 가지 은둔 보안 방식을 더 검토한 다음 Administrator 계정 이름 바꾸기와 같은 조치에 대해 좀 더 자세히 논의할 필요가 있습니다.

보안 조치 평가
은둔 보안 방식의 예는 많습니다. 여기에는 시스템 및 네트워크 관리자가 취하는 조치 또는 소프트웨어 개발자가 시작한 조치가 있을 수 있습니다. 하지만 공통적으로는 취약점을 공격자로부터 숨겨 취약점을 완화하려는 의도가 있습니다.
이러한 조치는 적어도 약간의 긍정적 효과는 있지 않을까요? 모든 은둔 보안 방식은 좋지 않다고 말할 수 있을까요? 적어도 이러한 조치 중 몇 가지를 지지하는 사람들을 발견할 수 있을 것입니다. 예를 들어, Windows®의 경우 Windows 탐색기에서 드라이브 문자를 숨길 수 있습니다. 학교 컴퓨터 실습실과 같은 많은 환경에서는 이 방법을 사용하여 사용자가 하드 드라이브에 데이터를 저장하지 못하도록 하고 있습니다. 물론 대부분의 응용 프로그램은 여전히 데이터를 하드 드라이브에 저장할 수 있으므로 완벽한 보안 조치로 볼 수는 없습니다. 하지만 이 방법을 구현한 기관에서는 이를 통해 하드 드라이브의 데이터를 줄일 수 있다고 합니다.
Windows에서 구현되는 또 하나의 은둔 보안 방식 유형은 관리 네트워크 공유(C$, Admin$ 등)를 해제하는 것입니다. 많은 사람들은 이 방법을 사용하면 공격자가 원격으로 컴퓨터에 연결하지 못하는 것으로 알고 있습니다. 실제로는 그렇지 않으며, 관리 공유를 사용할 수 있는 계정을 알고 있는 공격자는 해당 공유를 다시 사용하도록 원격으로 설정할 수 있습니다. 하지만 많은 조직에서는 이러한 공유를 사용하지 않도록 설정하면 네트워크에서 맬웨어 발생이 줄어든다고 말합니다.
헛수고일 수 있는 좋은 예 중 하나는 Windows의 "로그온할 필요 없이 도킹 해제 허용" 설정입니다. 이것을 사용하지 않도록 설정하면 "컴퓨터 도킹 해제" 단추가 로그온 화면에서 사라집니다. 이 방법에 대한 이면에는 이를 통해 공격자가 쉽게 컴퓨터 도킹을 해제하지 못할 것이라는 생각이 있습니다. 물론, 침입자는 이 단추의 표시 여부와 상관없이 컴퓨터와 도킹 스테이션을 모두 가방에 넣고 가져갈 수 있습니다. 이 방법은 은둔 보안 방식으로 볼 수도 없습니다.
또 다른 좋은 예는 Server Operators 그룹 구성원인 사용자가 작업 일정을 설정할 수 있도록 하는 "Server Operator가 작업을 예약하도록 허용" 설정입니다. 이러한 작업은 로컬 시스템으로 실행할 수 있고 관리자만 로컬 시스템으로 실행되는 작업을 예약할 수 있어야 하기 때문에 민감한 문제입니다. 물론, 서버 운영자는 다른 여러 요소를 통해 자신을 관리자로 만들 수 있으므로 이와 같은 방식으로 작업 예약을 하지 못하도록 하는 것은 실제로 의미가 없습니다.
하지만 많은 조직에서는 엔지니어를 관리자 대신 서버 운영자로 지정할 수 있어, 실수로 서버를 손상시킬 위험이 줄어들기 때문에 이 설정을 선호합니다. 이 방법은 자체만으로도 어느 정도 이점이 있습니다.
그렇다면 결론은 무엇일까요? 분명히 이러한 문제 중 일부는 매우 복잡할 수 있습니다. 우리는 이러한 유형의 조치에 대해 토론하느라 흥미로운 시간을 보냈습니다. Roger는 이러한 조치에서 가치를 찾느라 애쓰고 있습니다. 한편, Jesper는 이러한 조치가 대부분의 경우 시간 낭비라고 믿고 있습니다. 은둔 보안 방식 중 가장 자주 인용되고 논란이 되는 예인 Administrator 계정 이름 바꾸기에 대해 살펴보겠습니다. Roger는 이 조치에 대해 찬성하고, Jesper는 반대합니다. 보안 전문가인 Aaron Margosis와 Steve Riley도 추가 기사 "Administrator 계정 이름 바꾸기"와 "기본 설정 변경 금지"에서 각각 의견을 제시하고 있습니다.

Administrator 계정 숨기기
RID(relative identifier) 500인 Administrator 계정 이름을 일반적으로 알려지지 않은 다른 이름으로 바꾸는 것은 여러 보안 전문가들이 권장하고 있으며 많은 Microsoft 보안 강화 안내서에도 포함되어 있습니다. 그림 1과 같이 그룹 정책에도 Administrator 계정 이름 바꾸기에 대한 설정이 포함되어 있습니다. 여기에는 Administrator 계정 이름이 바뀌면 공격자가 실제 관리자로 로그인하는 데 좀 더 어려울 것이라는 의도가 있습니다. 물론, 이 작업에 대해 그룹 정책을 사용할 경우 그룹 정책 개체가 적용된 모든 컴퓨터에 이름이 바뀐 Administrator 계정 이름이 동일하게 사용되는 문제가 있습니다. 그러면 이 특정 보안 조치의 효과가 떨어집니다.
그림 1 Administrator 계정 이름 바꾸기
그림 1 Administrator 계정 이름 바꾸기 (더 크게 보려면 이미지를 클릭하십시오.)
또한 이 방식에서는 정당한 계정을 가진 사용자는 Administrator 계정 이름 변경 여부와 상관없이 이 이름을 검색할 수 있다는 것을 알아야 합니다. Administrator 계정의 RID는 항상 500입니다. RID 500인 계정의 이름을 간단히 조회하면 계정을 가진 모든 사용자가 그림 2와 같이 실제로 불려지는 이름을 볼 수 있습니다.
그림 2 이름이 바뀐 Administrator 계정 찾기
그림 2 이름이 바뀐 Administrator 계정 찾기 (더 크게 보려면 이미지를 클릭하십시오.)

Roger의 의견
Administrator 계정 이름 바꾸기에 반대하는 주요 의견은 보안 주체 계정 이름을 관련 SID(security identifier)로 변환하고 해당 RID를 찾기가 쉽다는 것입니다. 그리고 실제 Administrator 계정은 항상 RID 500을 가진다는 것입니다. 그렇다면 공격자가 사용자 계정 이름을 SID/RID 조합으로 쉽게 변환하고 RID 500을 찾을 수 있다면 이런 조치를 할 필요가 있습니까?
하지만 이것도 그리 간단하지 않습니다. 사용자 계정 이름을 SID/RID로 변환하기 위해서는 NetBIOS 또는 LDAP 포트에 대한 액세스 권한이 있어야 합니다. 대부분의 경계 방화벽에서는 인터넷을 통해 이러한 유형의 액세스를 허용하지 않으므로 공격자가 방화벽을 완전히 우회할 때까지는 어떤 것도 변환할 수 없습니다. 더욱이, 익명 SID 변환은 DC(도메인 컨트롤러)에 있는 경우를 제외하고 Windows XP 및 이후 버전의 Windows에서 작동하지 않습니다. 가장 외부에 있는 컴퓨터(위험이 가장 높은 컴퓨터)에 대해 이름-SID 변환을 수행하려면 공격자에게 인증된 자격 증명이 필요합니다.
따라서 변환 공격을 시작하기 위해서는 뚫어야 하는 많은 방어망이 존재합니다. 그리고 공격자가 여기까지 도달했다면 계정 이름이 바뀌지 않았더라도 상황은 같아집니다. Administrator 계정 이름 바꾸기는 보안을 높일 뿐 아무런 해도 되지 않습니다.
또 하나의 비밀. 공격자가 Administrator 계정 이름을 알지 못할 경우 공격자가 알아야 하는 암호와 마찬가지로 또 하나의 "비밀"이 됩니다. 사용자 계정 이름은 관리 암호만큼 복잡하지 않겠지만 그래도 암호 추측/해킹 문제를 복잡하게 만드는 또 하나의 장애물입니다. 암호 해킹 테스트를 해 본 경험이 있다면 사용자 이름과 암호를 모두 추측하는 데 얼마나 많은 작업이 필요한지 알 것입니다. 이를 통해 이미 어려운 작업을 더 어렵게 만들 수 있습니다.
자동화된 맬웨어 및 스크립트 공격 차단. 저는 현재 22년 동안 Windows 보안 방어를 연구 중이며, 지난 5년간 8대의 Windows 허니팟(honeypot)을 인터넷에 노출시키고 있습니다. 하지만 지금까지 자동화된 맬웨어(모든 공격의 상당수 차지)에서 Administrator(또는 *NIX 시스템의 경우 root) 이외의 다른 사용자 계정 레이블을 사용한 것을 본 적이 없습니다. Administrator 계정 이름을 바꾸면 Administrator 이름에 의존하는 모든 맬웨어를 즉시 차단할 수 있으며, 결과적으로 보안 위험이 낮아집니다.
스크립트 공격도 마찬가지입니다. 제가 알고 있는 모든 "근사한" Windows 해킹 매뉴얼에서는 이름-SID 변환 방법을 언급하고 있지만, 어떤 이유인지 "가짜" Administrator 계정을 인터넷에 노출된 허니팟에 던져 놓아도 내 컴퓨터에서 이러한 사례를 목격하지 못했습니다. 노련한 해커는 자신이 찾아낸 Administrator 계정이 실제 Administrator(RID 500)인지 항상 확인해야 하지만 그렇지 않습니다. 이유는 잘 모르겠습니다. 단지 게으른 해커이거나 일반적인 인간의 행동으로 생각하고 있습니다.
대부분의 전문 해커도 차단. 이렇게 말하면 대부분의 사람들이 놀랍니다. 몇 년간 허니팟을 운영하고 있다면 자동화된 공격, 스크립트 공격 및 전문가를 빠르게 구별해 낼 수 있을 것입니다. 지난 5년간 제 허니팟에 대해 보고된 수많은 공격 중에도 가짜 Administrator 계정이 존재한 경우 전문 해커가 SID 변환을 수행하는 것을 목격하지 못했습니다.
일부 전문 해커는 SID 변환을 수행하겠지만 소수에 불과할 것으로 판단되며 실제로 저도 경험한 적이 없습니다. 전문 해커들이 그렇게 하지 않는 이유가 무엇일까요? 제 생각에는 많은 사람들이 그렇게 하지 않는 상황에서 자기만 시도할 이유를 찾지 못하는 것 같습니다.
경고 단순화. 이제 반대 입장의 사람들은 Administrator 계정 이름 바꾸기가 보편화되면 은둔 방식으로서의 가치를 잃게 되는 것이라고 반박할 수 있습니다. 맬웨어, 스크립트 공격 및 전문 해커가 기본 전략을 바꾸어 Administrator 이외의 다른 이름도 공격 대상으로 고려한다는 것입니다. 맞는 말입니다. 하지만 다행히도 기본적인 조건은 바뀌지 않습니다. 무엇보다, Windows Super 권한을 가진 계정 이름이 Administrator로 지정되지 않을 경우 악의적인 해커가 많은 작업을 해야 합니다. 이것이 중요합니다. 그리고 악의적인 해커가 더 많은 작업을 해야 한다면 공격 시도 횟수가 줄어 다른 방어망 중 하나에서 악의적인 공격을 더 신속하게 감지할 수도 있습니다.
이제 이름 바꾸기에 찬성하는 마지막 이유를 말씀드리겠습니다. Administrator 계정이 Administrator로 지정된 적이 없고 그림 3과 같이 해당 이름으로 다른 계정을 만든다면 좋은 경고 체계를 갖추게 됩니다. 이벤트 모니터링에서 기본 이름을 사용하여 시도된 로그온을 감지한다면 즉시 조사할 필요가 있는 이벤트입니다.
그림 3 Administrator라는 이름의 유인 계정에 대한 로그인 시도로 조기 경고 가능
그림 3 Administrator라는 이름의 유인 계정에 대한 로그인 시도로 조기 경고 가능 (더 크게 보려면 이미지를 클릭하십시오.)
이벤트 로그는 별 의미가 없는 "잘못된" 로그온으로 가득 찹니다. 단지 잘못된 암호나 이와 유사한 것을 사용하여 로그인하려고 시도하는 사용자(또는 Windows)입니다. 하지만 Administrator 계정 이름이 Administrator로 지정되어 있다면 일반적인 로그온 시도와 악의적인 로그온 시도를 어떻게 쉽게 구별할 수 있겠습니까? Administrator라는 로그온 계정이 없고 해당 계정 이름을 사용하여 시도된 로그온을 감지한다면 악의적인 시도임을 알 수 있습니다. 영향이 별로 없는 조기 경고는 오늘날 방어에서 큰 가치가 있습니다.

Jesper의 의견
Administrator 계정 이름 바꾸기 - Aaron Margosis
이상적인 세계라면 Jesper의 말이 맞습니다. 암호는 항상 무작위(brute-force) 추측이 불가능할 정도로 충분히 강력해야 하고, -500 로컬 관리자 계정은 긴급 복구 상황에서만 사용되어야 합니다. 하지만 실제 세계에서는 그렇지 않습니다.
Jesper의 뛰어난 보안 강의 및 특히 집필한 암호 구문 시리즈( go.microsoft.com/fwlink/?LinkId=113157, go.microsoft.com/fwlink/?LinkId=113159 및 go.microsoft.com/fwlink/?LinkId=113160의 "The Great Debates: Pass Phrases vs. Passwords" Part 1, 2 및 3)에도 불구하고 많은 시스템 관리자는 강력한 암호의 구성 요소에 대해 이해하지 못하고 있습니다.
여러 문자 집합에서 가져온 8자리의 임의 문자로 구성된 암호가 강력했던 시기는 그리 오래 전이 아닙니다. 결국 이것은 무어의 법칙으로 사라지게 되었습니다. 사용자(및 시스템 관리자) 교육은 미약하며, 케이블 뉴스 채널에서 강력한 암호에 대해 대대적으로 보도될 때까지 대부분의 사람들은 현재 상태로 남아 있을 것입니다.
따라서 오늘날 실제 암호 추측에 6,000억 년이 필요한 것도 아니고 점심 시간만 사용하면 가능하겠지만, x1000 배수를 추가하면 실질적인 도움이 될 수 있습니다. 그리고 Administrator라는 이름의 계정을 뚫으려고 시도하는 많은 자동화된 공격에 대해 계정 이름을 바꾸면 취약점이 완화됩니다.
admin 계정 이름을 바꾸는 데 필요한 시간과 노력은 크지 않으며, 일반적으로 알고 있는 대로 단순한 GPO 설정입니다. 사실, 미국 정부의 Federal Desktop Core Configuration(csrc.nist.gov/fdcc)에서는 -500 계정 이름을 변경하도록 규정하고 있습니다. 이름 바꾸기는 필요한 많은 설정 중 하나이며, 많은 시간이나 주의가 필요한 작업이 아닙니다. 또한 이름 바꾸기의 가치와 관련하여 잘못된 보안 의미로 인식한 사람을 본 적이 없으며, "admin 계정의 이름을 바꾸었기 때문에 패치 관리가 필요하지 않다"고 말하는 사람도 없습니다.
조직 전체에서 계정 이름이 동일하게 바뀔 경우 이름 바꾸기의 의미가 있을까요? 의미가 크지는 않겠지만 어느 정도의 의미는 있습니다. 첫 번째로, Administrator에 대한 자동화된 공격을 차단할 수 있으며, 두 번째로, 잠재적 공격자가 새 이름을 알고 있는 "모든 사람" 중에 포함되지 않을 수도 있다는 것입니다. (이름 변경 여부와 상관없이 로컬 admin 계정이 조직 전체적으로 동일한 암호를 공유할 때 더 큰 위험이 있습니다. 이러한 암호 관리가 더 크고 중요한 문제입니다. -500 계정을 사용하지 않는 것은 이를 해결하는 한 가지 방법이지만, 이 경우 도메인 계정을 사용할 수 없을 때 사용할 수 있는 중요한 복구 통로가 차단됩니다.) 보안 지침에서는 오래 전부터 기본 계정 이름 바꾸기를 권장해 왔으므로 충분한 테스트를 통해 완벽하게 지원되고 있습니다.
지금까지의 논의를 통해 은둔 보안 조치만으로는 충분한 방어가 되지 않는다는 것을 알게 되었습니다. 하지만 이를 통해 다른 보안 조치를 강화할 수 있으며, 이것은 Roger의 데이터를 보면 분명하게 알 수 있습니다. 구현 비용만 낮다면 조직에서 이러한 조치를 배제하지 말아야 합니다.

찬성 논리에 대해 Administrator 계정 이름 바꾸는 것을 반대하는 합당한 논리가 있습니다. 하지만 이보다 먼저 저는 Roger의 마지막 주장은 확실히 옳다고 생각합니다. 그러나 엄격하게 관리되는 환경에서는 Administrator 계정이 긴급 복구 상황 이외에는 사용되어서는 안 되기 때문에 이 계정에 대한 모든 로그온을 조사해야 합니다.
무용지물. Administrator 계정 이름을 바꾸면 완화되는 것으로 추정되는 주요 위험은 암호를 원격으로 추측하는 것에 대한 위험입니다. 그러나 컴퓨터에서 인증된 다른 계정을 가지고 있지 않은 사용자만 Administrator 계정 이름 바꾸기로 차단됩니다. 이러한 공격자는 일반적으로 일련의 임의 암호를 사용하여 Administrator 계정에 대한 로그인을 시도합니다. 하지만 이러한 공격자는 계정 이름을 틀리게 추측했는지 또는 암호를 틀리게 추측했는지에 상관없이 동일한 오류 메시지를 받게 됩니다.
이것은 스크립트 공격이 사라진다는 Administrator 계정 이름 바꾸기의 주요 주장 중 하나에 문제가 있음을 나타냅니다. Administrator 계정 이름을 바꾸어도 원래 이름일 때보다 공격을 빨리 포기하지는 않습니다. 둘을 구분할 수 없기 때문입니다! 이들은 어쨌든 동일한 임의 암호 집합을 추측하고 다음 공격 대상으로 이동할 것입니다.
이것은 Administrator 계정에 대한 암호가 공격을 막아낼 수 있을 만큼 강력하다면 계정 이름 바꾸기가 별 소용이 없음을 의미합니다. Administrator 계정 암호에 전체 키보드에서 선택된 대소문자, 숫자 및 기호로 구성된 15자리 암호가 있다고 가정해 보겠습니다. 네트워크를 통해 이 암호를 추측하려면 약 591,310,404,907년이 걸립니다. 이것은 우주가 생겨난 것보다 약 43배나 긴 시간입니다.
이제 Administrator 계정 이름을 바꾸고 1,000개의 가능한 값 중 하나인 경우를 생각해 보겠습니다. 암호 추측 시간은 591,310,404,906,787년으로 늘어나며, 이것은 우주가 생겨난 것보다 43,161배나 긴 시간입니다. 그러면 보다 안전합니까? 물론 세 자리 연도가 늘어난 만큼 더 안전합니다. 그렇다고 공격자가 암호를 추측할 가능성이 낮아졌습니까? 그 가능성은 두 경우 모두 극미하게 낮습니다. 달리 말하면, 사실상 원래 Administrator 계정 이름을 사용해도 마찬가지라는 것입니다. 계정 이름을 바꾸면 해당 계정을 사용하려고 시도하는 맬웨어를 차단한다고 해서 계정 이름을 바꾸지 않으면 맬웨어가 성공한다는 것은 아닙니다. 사실, 강력한 암호만 사용한다면 계정 이름과 상관없이 공격이 성공하지 못하도록 할 수 있습니다.
많은 보안 지침에서 Administrator 계정 이름 바꾸기를 권장한다는 것은 분명하지만 그렇다고 중요하거나 올바른 보안 조치가 될 수는 없습니다. 적절한 위험 관리 결정을 내리기 위한 능력에 방해가 될 뿐입니다. 보안 지침에서는 별 의미가 없는 설정을 매우 자주 요구하고 있으며, 많은 경우 해당하는 설정이 존재하지도 않습니다. 결과적으로 보안 분야에서 진일보하려면 요구 사항을 한 단계 뛰어넘어, 실제로 문제를 분석하고, 완화 조치가 실제 의미가 있는지 여부를 평가해야 합니다. 여기에서 한 가지 중요한 사항을 염두에 두어야 합니다. 즉, 공격자는 자체 기능을 수정할 이유가 충분하지 않은 기능을 공격 대상으로 삼는다는 것입니다. 기능을 수정하지 않으면 공격을 받을 수 있다고 충분히 예상되는 경우에만 해당 기능을 수정해야 합니다.
강력한 암호를 사용할 경우 계정 이름 변경 여부에 상관없이 공격 성공 가능성은 사실상 0입니다. 따라서 강력한 암호만 가지고 있다면 계정 이름을 바꿀 특별한 보안상의 이유가 없습니다. 더욱이, 컴퓨터는 조정 및 변경이 적을수록 더욱 안정적이라는 저와 같은 원칙(사실 합당한 사실임)을 가지고 있다면 Administrator 계정 이름을 바꿀 이유가 더더욱 없어집니다.
낮은 가치의 완화 조치로 초점 이동. 낮은 가치의 은둔 보안 방식을 통한 완화 조치에서의 한 가지 문제점은 조직의 초점이 높은 가치의 완화 조치에서 낮은 가치로 이동할 위험이 있다는 것입니다. 예를 들어, Administrator 계정 이름을 바꾸는 데 투자한 시간과 노력은 다른 작업에 사용할 수 없습니다. 다른 작업이 Administrator 계정 이름을 바꾸는 것보다 높은 가치를 제공한다면 조직은 기회를 잃는 것입니다. 현실적으로 들리지 않을 수 있지만 50,000개의 Administrator 계정 이름을 바꾼다고 상상하면 이해가 갈 것입니다.
더 큰 문제는 낮은 가치의 완화 조치가 마련되면 조직의 리더들이 안심하게 될 가능성이 크다는 것입니다. 경영진에서 은둔 보안 방식을 통한 완화 조치가 가져오는 낮은 가치를 항상 이해하는 것이 아니므로 추가 단계를 취하지 않을 수도 있습니다. 경영진에서 구현되는 완화 조치의 가치를 이해하기 위한 시간과 노력을 투자한다면 위험을 충분히 피할 수 있겠지만 그렇지 못할 경우 이로 인해 조직에 큰 위험이 따를 수 있습니다.
높은 관리 비용. 마지막으로 완화 조치가 얼마나 잘 구현되었는지에 따라 관리 비용이 증가할 수 있습니다. 간단히 GPO(그룹 정책 개체)를 설정하여 Administrator 계정의 이름을 바꾼다면 비용은 매우 낮습니다. 모든 사람이 이름을 알고 있으므로, 구현 비용도 거의 들지 않습니다. 하지만 이미 언급한 대로 계정이 있는 모든 사람이 Administrator 계정 이름이 무엇인지 알기 때문에 이러한 조치로 인한 효과는 매우 미약합니다. 따라서 이 완화 조치에서 최대한의 효과를 얻으려면 여러 호스트에서 서로 다른 이름을 사용해야 하고, 이 경우 시스템 관리 비용이 크게 증가하게 됩니다.
대신 passgen(protectyourwindowsnetwork.com/tools.htm)과 같은 도구를 사용하여 네트워크 전체의 모든 Administrator 계정에 대해 100자의 완전한 임의 암호를 설정하고, 일상적인 관리를 위해서는 다른 계정을 사용하는 것이 더 좋습니다. Administrator 계정을 순전히 재해 복구용(Windows Small Business Server 2003 제외)이라고 생각하면 네트워크 관리 시스템에 전혀 영향을 주지 않을 것입니다. 더욱이, 공격자는 Administrator 계정에 대한 암호를 정확하게 추측하는 것보다 태평양 밑바닥에서 바늘을 찾을 확률이 더 높습니다. 대신 강력하고 고유한 암호에 초점을 맞추는 것이 스크립트 공격으로부터 더 안전합니다.

위험 관리의 중요성
거의 모든 은둔 보안 방식의 조치는 이와 같은 방식으로 분석할 수 있습니다. 어떤 방식이든 각각 장단점이 있고, 한 조직에 올바른 방식이 다른 조직에는 그렇지 않을 수 있습니다. 결국 모든 것은 위험 관리의 문제입니다. 위험이 솔루션 구현 비용을 능가합니까? 정보 자산을 보호하기 위해 내리는 모든 결정은 정보에 근거한 위험 관리 결정이어야 하고, 양자 택일일 가능성은 낮습니다.
사실 몇 가지 결정은 이미 내려졌습니다. 예를 들어, 신용 카드 정보를 암호화하지 않거나 신용 카드 검증 코드를 저장하지 않도록 선택할 수 있지만 이 두 경우 모두 결제 수단으로 신용 카드를 받을 자격이 사라지게 됩니다. 이러한 결정에 대한 사업상 부정적인 영향은 실제로 선택의 여지가 없다는 것입니다. 즉, 분명 위험 관리 결정이지만 누구나 내릴 수 있는 쉬운 결정입니다.
마찬가지로, 제정신을 가진 사람이라면 개방형 무선 네트워크를 실제 상점 내부 네트워크의 백엔드에 연결하지는 않을 것입니다. 하지만 그렇다고 이 결정이 위험 관리 결정이 아니라는 의미는 아닙니다. 위험 관리 결정입니다. 선택을 할 수 있고, 선택을 한다면 그에 따른 결과도 감수해야 합니다(애석하게도 실제로 이렇게 하는 사람은 없는 것 같음).
여기서 취해야 할 중요한 단계는 해결해야 할 문제, 해당 문제에 대해 제안된 솔루션 및 각각의 장단점을 분명하게 파악하는 것입니다. 이렇게 되면 정보에 근거한 위험 관리 결정을 내리는 데 필요한 정보를 보유하게 됩니다. 이러한 정보 없이는 직감에 의존하여 결정을 내리게 되고 거의 현명한 결정으로 이어지지 않습니다.

Jesper M. Johansson은 보안 소프트웨어 분야의 소프트웨어 설계자이며 TechNet Magazine의 객원 편집자로서, 정보 관리 시스템 분야 박사 학위와 20여 년의 보안 관련 경력을 가지고 있는 Enterprise Security 영역의 Microsoft MVP입니다. Jesper의 최근 저서로는 Windows Server 2008 Security Resource Kit가 있습니다.
Roger Grimes(CPA, CISSP, MCSE: 보안)는 Microsoft ACE 팀의 선임 보안 컨설턴트로서, 컴퓨터 보안에 대한 8권의 저서를 집필 또는 참여했으며 200건 이상의 잡지 기사를 기고했습니다. 보안 컨퍼런스 발표자로 많은 활동을 하고 있으며 InfoWorld 보안 칼럼니스트입니다.
© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


Security
새로운 Windows Vista용 Elevation PowerToy
Michael Murgolo
한 눈에 보기:
  • 타사 스크립팅 도구용 Run as Administrator
  • Run as Another User
  • CMD 및 Windows PowerShell용 Prompt Here as System
  • Elevation Gadget에 끌어서 놓기
이 기사의 코드 다운로드: Elevation2008_06.exe (197KB)

Windows Vista용 Elevation PowerToy 새 버전을 소개합니다. TechNet Magazine 2007년 6월호에서 이 유틸리티에 대해 자세히 설명한 적이 있습니다. 그로부터 1년이 지난 지금, 이번에는 Run as Administrator 기능을
즐겨 사용하는 타사 스크립팅 도구로 확장하는 방법, Windows Vista®에서 제거된 편리한 Windows® XP 기능을 대체하는 방법, 그리고 Elevation PowerToy에 포함된 몇 가지 유용한 도구에 대해 살펴보겠습니다.

추가 스크립팅 도구용 Run as Administrator
이전 기사(technet.microsoft.com/magazine/cc162321.aspx)에서 다루었던 한 가지 주제는 기본 Windows 스크립팅 도구에 대한 Run as Administrator 옵션 지원에 대한 것이었습니다. 여기서는 다음과 같은 타사 스크립팅 도구에 대한 Run as Administrator PowerToy를 소개합니다.
  • AutoIt v3(www.hiddensoft.com)
  • AutoHotkey(www.autohotkey.com)
  • ActivePerl(www.activestate.com)
  • KiXtart 2010(www.kixtart.org)
이러한 각 도구에 대한 코드는 technetmagazine.com에서 이 기사와 함께 다운로드할 수 있습니다. 실제 파일의 이름은 각각 ElevateAutoIt3.inf, ElevateAutoHotKey.inf, ElevatePerlScript.inf 및 ElevateKiXtart.inf입니다. AutoIt v3, AutoHotkey 및 ActivePerl의 경우에는 간단히 설치할 수 있습니다. 단순히 해당 응용 프로그램을 다운로드하여 기본 위치에 설치하면 됩니다. 사용하고자 하는 응용 프로그램을 설치한 후 각 도구에 대해 해당 Run as Administrator PowerToy를 설치하기만 하면 됩니다.
안타깝게도 Kixtart 2010은 설치 관리자를 제공하지 않습니다. 그래서 KiXtart가 표준 위치에 설치되어 PowerToy가 올바르게 작동되도록 하기 위해 Program Files\KiXtart에 KiXtart 2010(v 4.60)을 설치하고 .kix 파일 확장명을 등록하는 INF 파일을 제공했습니다.
www.kixtart.org/?p=downloads로 이동하여 KiX2010_460.zip을 다운로드하고 폴더로 압축을 풉니다. 이 기사와 함께 제공되는 코드 다운로드에 포함된 Install_KiXtart.inf 파일을 동일 폴더로 복사합니다. 그런 다음 Install.Kixtart.inf를 마우스 오른쪽 단추로 클릭하고 "설치"를 선택합니다. 다음에는 ElevateKiXtart.inf PowerToy를 설치하면 됩니다.

Run as Another User PowerToy
사용자, 심지어 관리자도 표준 사용자 권한으로 대부분의 응용 프로그램을 실행하도록 하여 운영 체제의 맬웨어에 대한 취약성을 낮추기 위해 UAC(사용자 계정 컨트롤)가 생성되었습니다. UAC는 관리 작업 및 기타 응용 프로그램 기능을 위한 권한 상승 기능을 제공합니다. 이 권한 상승 기능은 Run as Administrator 옵션을 통해 제공되며, 이 옵션은 실행 파일을 마우스 오른쪽 단추로 클릭하면 나타납니다. 2007년 6월 기사에서 설명했던 Elevation PowerToy에는 이 기능을 다른 파일과 개체 유형에도 적용되도록 확장했습니다.
Windows Vista에 기본으로 제공된 기능은 다양한 관리 작업에 잘 맞는 편입니다. 하지만 Windows Vista에는 한 가지 중요한 시나리오가 빠졌습니다. 많은 IT 부서에서는 네트워크 관리자가 일상 작업(전자 메일 사용, 문서 작성 등)용으로 하나의 사용자 계정을 사용하고 네트워크 관리(또는 로컬 컴퓨터 관리) 전용으로 또 하나의 계정을 사용하도록 하는 정책을 사용합니다.
이러한 정책은 네트워크 관리자가 일상 작업을 수행하는 중에 우발적으로 맬웨어를 실행하는 경우 관리자가 전체 시스템이나 해당 도메인을 손상시키지 않도록 위험을 낮추기 위한 목적입니다. 이 목적은 Windows XP에서 "...(으)로 실행" 오른쪽 클릭 옵션의 사용을 통해 실현되었습니다. 하지만 Windows Vista에서는 이 옵션이 제거되고 Run as Administrator 옵션으로 대체되었습니다.
그러나 runas 명령줄 도구는 Windows Vista에도 여전히 존재합니다. 안타깝게도, Microsoft® Management Console(MMC) 스냅인을 실행하는 가장 일반적인 이중 계정 작업에는 이 도구를 사용할 수 없습니다. 예를 들어, Active Directory®에서 일부 계정 관리 작업이 여러분에게 위임되었다고 가정해 보겠습니다. 일상적인 작업을 위해서는 표준 사용자로 실행하며, UAC를 사용하는 Windows Vista 컴퓨터에서는 네트워크 관리 계정도 로컬 관리 그룹의 구성원이므로 필요할 경우 네트워크 관리 도구를 설치할 수 있습니다. 이제 Active Directory 관리 계정을 사용하여 ADU&C(Active Directory 사용자 및 컴퓨터)를 시작하려고 하며, 다음과 같이 runas 명령을 시도합니다.
runas /user:mydomain\admin
"mmc.exe %windir%\system32\dsa.msc"
안타깝게도 이 명령을 실행해도 ADU&C가 시작되지 않습니다. 대신 "요청한 작업을 수행하려면 권한 상승이 필요합니다"라는 runas 오류가 표시됩니다. 이 경우는 MMC 실행 파일이 highestAvailable 권한 수준에서 실행되도록 표시되어 있음을 의미합니다. 네트워크 관리자 계정에 대한 highestAvailable 수준은 관리자이기 때문에 이 방식으로 ADU&C를 시작하려면 권한 상승이 필요합니다. runas는 권한 상승 프롬프트를 나타내지 못하므로 오류가 발생합니다.
따라서 Windows Vista에서는 "...(으)로 실행"에 대한 상황에 맞는 메뉴 항목을 제공하지 않고 프로세스를 권한 상승이 필요한 다른 사용자로 실행할 수 있는 기본 수단을 제공하지 않으므로 이 시나리오를 해결하기 어렵습니다.
이 시나리오에 대한 솔루션이 없다면 매우 실망스럽겠지만 다행히도 솔루션이 있습니다. 이전 Elevation PowerToy 중 하나가 두 번째 문제를 해결하기 위한 키를 제공하며, 첫 번째 문제에 대한 솔루션도 준비하고 있습니다. 솔직히 제가 권한 상승 문제에 대한 솔루션을 개발했다고 주장하고 싶지만 이 솔루션은 Windows AppCompat 팀의 Gov Maharaj로부터 얻은 것입니다.
Elevate Command PowerToy를 runas 명령과 함께 사용할 수 있는 것으로 나타났습니다. 이전 명령은 권한 상승 프롬프트를 나타내지 못했지만 다음 코드는 권한 상승 프롬프트를 나타냅니다.
runas /user:mydomain\admin
"elevate mmc.exe%windir%\system32\dsa.msc"
이 코드를 실행하면 runas가 elevate.cmd(기술적으로 말하면 시작되는 프로세스는 cmd.exe임)를 다른 사용자 권한으로 시작하며 elevate 명령이 권한 상승 프롬프트와 함께 mmc.exe 시작을 담당합니다.
최종적으로 이 방법을 사용하여 이를 .exe 및 .msc 파일에 대한 파일 연결과 결합한 후 HTML 응용 프로그램 UI를 제공하여 오른쪽 클릭 메뉴를 통해 사용할 수 있는 Run as Another User 옵션을 생성하는 PowerToy를 만들었습니다. Run as Another Use를 선택하면 그림 1과 같은 HTML 응용 프로그램이 나타납니다.
그림 1 Run as Another User 도구
그림 1 Run as Another User 도구 (더 크게 보려면 이미지를 클릭하십시오.)
여기서 로컬 컴퓨터 계정으로 간단히 사용자 이름과 도메인을 입력하고 "Use Local Account" 확인란을 선택합니다. 그런 다음 "Run" 단추를 클릭하여 해당 응용 프로그램을 표준 사용자로 시작하거나, "Run as Admin" 단추를 클릭하여 상승된 권한으로 응용 프로그램을 시작할 수 있습니다. 이 두 가지 단추 중 하나를 클릭한 후에는 runas.exe가 실행되고 암호 또는 스마트 카드 PIN을 요청하는 프롬프트가 표시됩니다.
이 PowerToy에서는 Elevate Command PowerToy를 사용하기 때문에 Elevate Command PowerToy를 먼저 설치해야 합니다. 그런 다음 RunAs.inf 파일을 마우스 오른쪽 단추로 클릭하고 "설치"를 선택한 다음 권한 상승을 승인합니다. 이 도구를 제거하려면 "프로그램 및 기능" 제어판을 사용합니다.
관리 도구에 있는 .msc 파일에 대한 일부 바로 가기(컴퓨터 관리 등)가 이 PowerToy와 작동함을 알 수 있습니다. 하지만 adminpak.msi를 사용하여 Windows Server® 2003 관리 도구를 설치하는 경우 생성되는 바로 가기는 .msc 파일에 대한 표준 바로 가기가 아닙니다. 대신 이러한 바로 가기는 Windows Installer 바로 가기이므로 Windows 탐색기에 이러한 바로 가기에 대한 Run as Another User 옵션이 표시되지 않습니다.
이러한 바로 가기의 경우 실제 .msc 파일을 찾아서 마우스 오른쪽 단추로 클릭하거나 .msc 파일에 대한 새 바로 가기를 만들어야 합니다. 또한 Internet Explorer가 Windows Vista의 보호 모드에 맞게 다시 설계되었기 때문에 runas가 Internet Explorer®에서는 작동하지 않습니다. 이 문제에 관한 자세한 내용은 support.microsoft.com/?id=922980을 참조하십시오.
참고: 이러한 PowerToy를 완성한 후 이 기사를 작성하는 사이에 Windows Sysinternals에서 Run as Another User PowerToy와 매우 비슷하게 작동하는 새로운 도구를 발표했습니다. ShellRunas라는 도구로 Windows Sysinternals 사이트 technet.microsoft.com/sysinternals/cc300361에서 찾아볼 수 있습니다.
Sysinternals에서는 전문적으로 실제 코드를 작성하기 때문에 이 도구가 사용하기 더 좋을 수도 있습니다. 제가 만든 유틸리티는 스크립트 코드와 함께 HTML 응용 프로그램을 사용하여 어떻게 특히 이 작업 및 일반적인 셸 확장을 수행할 수 있는지에 대한 예로 그대로 기사에 남겨 두기로 했습니다.

CMD Prompt Here as System 및 PowerShell Prompt Here as System
로컬 시스템 컨텍스트에서 프로그램을 실행해야 할 때가 있습니다. 예를 들면, System Center Configuration Manager(SCCM) 등 많은 소프트웨어 배포 도구는 로컬 시스템으로 실행되는 클라이언트 에이전트를 사용하여 작업을 수행합니다.
SCCM과 같은 제품의 배포를 시도하기 전에 로컬 시스템으로 실행되는 소프트웨어 설치 프로그램의 동작을 테스트하려면 로컬 시스템으로 실행되는 명령 프롬프트를 사용하여 설치 관리자를 시작하는 것이 유용할 수 있습니다. 따라서 저는 CMD 및 PowerShell Prompt Here as System PowerToy를 작성하기로 했습니다.
Windows XP를 사용할 때는 이와 같은 기능을 다음 명령 셸 스크립트를 사용하여 수행하곤 했습니다.
@echo off
sc create CmdAsSystem type= own type= interact
binPath= "cmd /c start cmd /k (cd c:\ ^& color ec ^&
title ***** SYSTEM *****)"
net start CmdAsSystem
sc delete CmdAsSystem
하지만 Windows Vista에서는 권한이 상승된 명령 프롬프트에서 이 코드를 실행하려 할 경우 다음 오류 메시지가 표시되고 시스템으로 실행되는 명령 프롬프트가 나타나지 않습니다.
경고:  CmdAsSystem 서비스는 대화형으로 구성되어 있으며
지원되지 않고 않습니다.
서비스가 올바르게 작동하지 않을 수 있습니다.
문제는 이 스크립트가 대화식 서비스를 생성 및 시작하려 한다는 점입니다. 대화식 서비스는 Windows Vista의 세션 0 격리로 인해 올바르게 작동하지 않습니다. 세션 0 격리에 대한 설명은 microsoft.com/whdc/system/vista/Vista_Services.mspx에서 볼 수 있는 "Services in Windows Vista" 백서를 참조하십시오.
이 제한을 해결하기 위해 저는 Sysinternals에서 개발한 Psexec 도구를 사용했습니다. 이 도구에 대한 자세한 내용은 technet.microsoft.com/sysinternals/bb897553.aspx를 참조하십시오. 이 도구를 사용하면 프로세스를 시스템 컨텍스트에서 시작할 수 있습니다. 안타깝게도 대부분의 Sysinternationals 도구에는 설치 관리자가 포함되어 있지 않습니다. 따라서 저는 Psexec를 포함하는 전체 Sysinternals Suite를 Program Files\Sysinternals Suite에 설치하기 위한 INF 파일(코드 다운로드에 제공)을 제공했습니다. 추가 보너스로 이 INF 파일은 Sysinternals Suite의 그래픽 도구에 대한 시작 메뉴 바로 가기도 만듭니다.
이 Sysinternals Suite를 설치하려면 먼저 technet.microsoft.com/sysinternals/bb842062.aspx에서 SysinternalsSuite.zip을 다운로드하여 폴더에 압축을 풉니다. 그런 다음 INF 파일(Install_SysinternalsSuite.inf)을 해당 폴더로 복사한 후 Install_SysinternalsSuite.inf를 마우스 오른쪽 단추로 클릭하고 "설치"를 선택합니다. 이러한 새 PowerToys에서는 Elevate Command PowerToy를 사용하므로 다음으로 이 유틸리티를 설치합니다. 이렇게 한 후에는 CmdHereAsSystem.inf와 PowerShellHereAsSystem.inf를 설치할 수 있습니다. 이러한 PowerToy를 설치하고 나면 그림 2와 같이 Windows 탐색기에서 폴더 및 드라이브에 대한 오른쪽 클릭 항목으로 CMD Prompt Here as System과 PowerShell Prompt Here as System 옵션을 사용할 수 있습니다.
그림 2 CMD Prompt Here as System 및 PowerShell Prompt Here as System 옵션
그림 2 CMD Prompt Here as System 및 PowerShell Prompt Here as System 옵션
그림 3은 시스템으로 실행되는 CMD 프롬프트를 보여 줍니다. 이 프롬프트가 시스템으로 실행 중이며 잘못된 명령을 입력할 경우 시스템에 예기치 않은 문제가 발생하고 시스템이 손상될 수 있다는 것을 경고하기 위해 밝은 색상을 선택했습니다.
그림 3 CMD Prompt as System은 신중하게 사용해야 합니다.
그림 3 CMD Prompt as System은 신중하게 사용해야 합니다.
마지막으로 PowerToy에서 이러한 프롬프트가 실행 대화 상자나 CMD 프롬프트에서 시작될 수 있도록 시스템에 명령을 추가합니다. 예를 들어, "실행" 상자에서 다음 명령을 실행하면 WIndows 폴더에서 CMD 프롬프트가 시스템으로 시작됩니다.
cmdassystem "c:\windows"
이에 해당하는 Windows PowerShellTM 명령은 psassystem입니다. 또한 각각 cmdasadmin 및 psasadmine라는 유사한 명령을 설치하도록 CMD 및 PowerShell Prompt Here as Administrator PowerToy도 수정했습니다.

Elevation Gadget
대부분의 PowerToy에서는 마우스 오른쪽 단추를 클릭해야 합니다. 하지만 이 업데이트의 보너스로 좀 더 재미있는 부분을 포함시켰습니다. 바로 Windows 사이드바 가젯인데, 저는 이 가젯을 Elevation Gadget(그림 4 참조)이라고 부릅니다. 이 가젯에는 끌어서 놓기 기능을 사용할 수 있습니다. Windows 탐색기에서 runas 동작이 정의되어 있는 스크립트 또는 실행 파일을 끌어다 놓기만 하면 상승된 권한으로 시작됩니다.
그림 4 Elevation Gadget에 끌어서 놓기
그림 4 Elevation Gadget에 끌어서 놓기
이전 Elevation PowerToy를 설치한 경우 Windows Script Host 스크립트, Windows PowerShell 스크립트, HTML 응용 프로그램, Windows Installer 패키지 및 패치, Windows Vista에서 기본적으로 runas 동작이 정의되어 있는 실행 파일 및 명령 셸 스크립트에 대해 이 가젯이 작동합니다. 또한 한 번에 두 개 이상의 항목을 끌어다 놓을 수도 있습니다. 폴더 하나를 가젯으로 끌어다 놓고 어떻게 되는지 보십시오.
이 가젯을 설치하려면 Elevation.gadget(코드 다운로드에 제공)을 두 번 클릭합니다. 가젯 코드를 살펴보려면 .cab 확장명을 파일 이름에 추가하면 됩니다. 그런 다음 Cab 파일의 내용을 추출할 수 있습니다.

요약
이 기사의 다운로드에는 새 PowerToy와 이전 기사에 소개된 PowerToy가 모두 포함되어 있습니다. 이전 PowerToy 중 일부를 조금 수정했습니다. 예를 들면, Windows PowerShell Prompt Here as Administrator 및 Elevate WSH Script의 이전 버전은 모두 고유의 elevate.cmd 및 elevate.vbs 사본을 설치했습니다. 몇몇 새 PowerToy도 이 파일에 의존하므로 이러한 도구를 변경하여 Elevate Command PowerToy를 설치하여 해당 사본을 공유하도록 했습니다. PowerToy에서 Elevate Command PowerToy 설치를 필요로 하는지 확인하려면 INF 파일의 헤더를 보면 됩니다.
다른 이전 PowerToy도 기능적인 부분은 아니지만 조금씩 변경되었습니다. 최신 버전의 PowerToy를 설치하려면 항상 이전 버전을 제거해야 합니다. 이 유틸리티 모음에 현재 17가지 도구가 포함되어 있으므로 전체 유틸리티 모음을 설치 및 제거할 수 있는 InstallAllPowerToys.cmd 및 UninstallAllPowerToys.cmd라고 하는 명령 셸 스크립트를 각각 추가했습니다. 사용하려는 도구만 설치 및 제거하도록 이 스크립트를 사용자 지정할 수도 있습니다.
InstallAllPowerToys.cmd는 기본적으로 타사 스크립팅 도구용 Run as Administrator PowerToy는 설치하지 않습니다. 설치된 소프트웨어에 해당하는 PowerToy만 설치하도록 이 스크립트를 수정할 수 있습니다. 이러한 도구 중 하나를 실행하면 해당 도구가 상승된 권한으로 다시 시작됩니다. UninstallAllPowerToys.cmd는 이러한 도구의 이전 버전을 모두 제거합니다.
모든 PowerToy와 마찬가지로 이러한 도구에 대한 지원은 없으며 사용으로 인한 위험은 사용자 스스로 감수해야 합니다. 이 도구는 Microsoft 정식 제품이 아니며 개인적으로 작성한 것입니다. 이 도구는 32비트 Windows Vista에서 영어를 기본 언어로 하여 저와 몇몇 자원자를 통해서만 테스트되었습니다. 마지막으로 이러한 PowerToy 전체 또는 일부는 향후 출시되는 Windows 업데이트, 서비스 팩 또는 운영 체제 버전에서 작동하지 않을 수도 있습니다.

Michael Murgolo는 Microsoft Consulting Services의 수석 인프라 컨설턴트로, 운영 체제, 배포, 네트워크 서비스, Active Directory, 시스템 관리, 자동화 및 패치 관리를 담당하고 있습니다. 데스크톱 배포와 마이그레이션 분야의 전문가입니다.


보안
BitLocker 드라이브 암호화의 발전
Byron Hynes
한 눈에 보기:
  • BitLocker 기능 향상
  • BitLocker 구하기 및 설치
  • 서버에서 BitLocker 사용
  • 완벽한 데이터 보호를 위한 고려 사항

작년에 저는 TechNet Magazine을 통해 보안 문제를 다루면서 초기 Windows Vista 릴리스에서 Windows BitLocker 드라이브 암호화를 어떻게 구현했는지 설명하기 위해 Windows BitLocker의 몇 가지 기능을 간단히 소개한 바 있습니다. 그리고 이제
Windows Vista® 서비스 팩 1과 새로운 Windows Server® 2008 운영 체제가 릴리스되었으므로 BitLocker®에 대해 다시 살펴볼 때가 되었습니다.
이 기사에서는 최신 버전의 몇 가지 달라진 점을 설명하고, BitLocker를 서버에 설치하여 사용하는 방법을 간단히 알아본 다음, 최근 보고된 고려할 사항을 일부 소개합니다. 작년의 기사 "BitLocker 드라이브 암호화를 사용하여 데이터를 보호하기 위한 핵심 사항"을 보려면 technet.microsoft.com/magazine/cc138009.aspx로 이동하십시오.

새로운 기능
BitLocker 이번 릴리스에 도입된 새로운 기능으로 기본 작업의 변화 없이 유연성이 향상되었습니다. 여기서는 데이터 볼륨 지원, 시스템 액세스 3단계 인증 허용, 64비트 시스템을 위한 새로운 산업 표준 펌웨어인 UEFI(Unified Extensible Firmware Interface) 지원, 볼륨 메타데이터의 암호화 공격에 대한 보호 향상, TPM(신뢰할 수 있는 플랫폼 모듈) 사용 폭 확대 등의 변경 사항에 대해 알아보겠습니다.

데이터 볼륨
Windows Vista가 처음 출시되었을 때는 BitLocker 제어판에서 Windows® 운영 체제 볼륨(일반적으로 C: 드라이브)에 대해서만 암호화를 설정할 수 있었습니다. 가정용 컴퓨터는 보통 모든 사용자 데이터와 프로그램을 운영 체제와 동일한 볼륨에 저장하도록 구성되어 있기 때문에 일반 사용자의 경우 대개 이 기능으로 충분했습니다. 그러나 기업의 경우, 특히 서버 컴퓨터는 여기에 해당되지 않습니다. 따라서 컴퓨터에 설치되어 있는 OS 볼륨 이외의 다른 볼륨, 즉 데이터 볼륨의 암호화 기능을 요구하는 고객들이 많았습니다(BitLocker는 이동식 미디어를 암호화하도록 설계되지 않음).
그림 1에서 보듯이 이 컴퓨터에는 세 개의 사용 가능한 볼륨이 있습니다. 시스템 시작에 사용하는 작은 활성 파티션까지 하면 실제 볼륨은 네 개가 됩니다. 제 운영 체제는 C: 드라이브에 설치되어 있으며(아이콘에 Windows "플래그" 표시) 두 개의 데이터 볼륨 E: 및 P:가 있습니다. P: 볼륨은 BitLocker로 이미 암호화되어 현재 잠겨 있습니다. E: 볼륨은 아직 암호화되지 않았습니다. Windows Vista SP1 및 Windows Server 2008의 경우 BitLocker 제어판 애플릿에서 이런 데이터 볼륨을 암호화하고 잠금 해제할 수 있습니다.
그림 1 Bitlocker 인터페이스
그림 1 Bitlocker 인터페이스 (더 크게 보려면 이미지를 클릭하십시오.)
운영 체제 볼륨을 BitLocker로 암호화한 경우 기본적으로 운영 체제 볼륨을 잠금 해제할 때마다 이 암호화된 볼륨이 잠금 해제됩니다. 제어판을 사용하여 데이터 볼륨을 잠금 해제하면 그림 2와 같이 이 옵션의 확인란이 표시됩니다.
그림 2 자동 잠금 해제를 위한 키 저장
그림 2 자동 잠금 해제를 위한 키 저장 (더 크게 보려면 이미지를 클릭하십시오.)
데이터 볼륨의 "자동 잠금 해제"를 설정하거나 해제하려면 manage-bde.wsf 명령줄 도구를 사용합니다. Windows에 포함되어 있는 Manage-bde.wsf는 BitLocker와 함께 설치된 기본 WMI(Windows Management Instrumentation)﻿ 공급자를 사용하는 강력한 스크립트입니다.
예를 들어 데이터 볼륨 P:를 수동으로 잠금 해제하도록 표시하려면 다음 명령을 사용합니다.
manage-bde.wsf –autounlock –disable P:
P:에 대한 자동 잠금 해제를 다시 설정하려면 다음 명령을 사용합니다.
manage-bde.wsf –autounlock –enable P:
BitLocker와 데이터 볼륨으로 할 수 있는 모든 작업이 BitLocker 제어판에 표시되지는 않기 때문에 -? 옵션으로 manage-bde.wsf 명령을 탐색해야 합니다. manage-bde.wsf 구문은 "Windows BitLocker Drive Encryption Design Guide" 및 "Windows BitLocker Deployment Guide"에도 수록되어 있습니다. 이 설명서는 Microsoft 다운로드 센터(go.microsoft.com/fwlink/?LinkId=115215)에서 구할 수 있습니다.

TPM+USB+PIN
고객이 BitLocker로 추가 인증 단계를 사용하고자 할 수도 있습니다. BitLocker는 사용자 컴퓨터의 TPM 칩을 사용하여 플랫폼의 무결성을 확인합니다. 즉, BIOS를 비롯한 초기 시작 구성 요소가 변조되거나 손상되지 않았는지 확인합니다. 그러나 Windows Vista 릴리스부터는 BitLocker를 활성화할 때 만들어진 키가 들어 있는 USB 플래시 드라이브나 PIN을 요청할 수도 있습니다.
Windows Server 2008 및 Windows Vista SP1에서는 세 기능을 모두 결합할 수 있습니다. 그러면 TPM은 플랫폼 무결성을 계속 확인하고 USB 키는 "현재 보유 중인 요소"를, PIN은 "알려진 요소"를 표시하게 됩니다. 이 구성을 사용하면 권한 없는 사용자가 컴퓨터를 시작하고 BitLocker로 보호된 드라이브를 잠금 해제하지 못하도록 매우 강력하게 보호할 수 있습니다.
그러나 보안이란 것이 대개 그렇듯이 이 기능에도 대가가 필요합니다. BitLocker를 이 방식으로 구성하면 컴퓨터 자동 시작이 불가능해집니다. 예를 들어 서버의 경우 자연스런 재시작과 높은 수준의 보호 중 어느 것이 더 중요한지를 결정해야 합니다.

UEFI 지원
Windows Server 2008 및 Windows Vista SP1에는 UEFI(Unified Extensible Firmware Interface)가 설치된 컴퓨터에 대한 지원이 추가되었습니다. UEFI는 대부분의 컴퓨터에서 시작할 때 사용하는 기존의 BIOS를 현대화한 사양입니다. UEFI 사양에 대한 자세한 내용은 www.uefi.org를 참조하십시오.

향상된 보호
시스템 변경이 감지되거나 시작할 때 필요한 PIN 또는 USB 키를 사용할 수 없는 경우 BitLocker는 복구 모드로 들어갑니다. 복구 모드에서 BitLocker 사용 볼륨은 잠긴 상태를 유지하며 "복구 콘솔"이라는 텍스트 모드의 대화 상자가 표시됩니다.
드라이브를 잠금 해제하려면 키보드 또는 USB 플래시 드라이브에서 복구 암호(48자리 숫자)를 입력해야 합니다. USB 플래시 드라이브에 저장된 암호는 텍스트가 아니라 이진 형식이므로 복구 키라고도 합니다.
BitLocker는 복구 암호를 사용하여 볼륨 메타데이터에 저장된 키인 VMK(볼륨 마스터 키)와 FVEK(전체 볼륨 암호화 키)를 차례로 해독하여 드라이브의 잠금을 해제합니다. 성공적으로 복구하려면 복구 암호의 복사본이 있어야 합니다.
따라서 개인 저장소(예: USB 플래시 드라이브) 외에 중앙 위치에도 복구 암호를 저장하는 것이 좋습니다. ADDS(Active Directory® 도메인 서비스)에 복구 암호를 저장하는 운영 체제 기능이 있습니다.
볼륨 메타데이터에 저장된 비밀(예: VMK)은 암호화되고 전체 볼륨 메타데이터의 무결성이 암호로 보호됩니다. 이 볼륨 메타데이터의 변조가 감지되면 BitLocker는 해당 메타데이터의 사용을 거부하고 보호된 볼륨의 잠금을 해제하지 않습니다. 복구 암호만으로는 이러한 상태의 드라이브 잠금을 해제할 수 없습니다.
이러한 상황은 컴퓨터에 대한 계획적인 보안 공격이 있을 때만 발생합니다. 그 경우 악의적인 공격자가 이미 컴퓨터를 장악하여 사용자의 통제 범위를 벗어났을 가능성이 높습니다. 계획에 없던 단순한 플랫폼 변경이 있거나 PIN을 잊어 버렸을 때 이러한 상황이 발생하는 것은 아닙니다.
볼륨을 잠금 해제하려면 다음 세 가지 항목이 필요합니다.
  • 복구 암호(텍스트로 입력하거나 USB 플래시 드라이브에 저장)
  • FVEK 및 VMK의 암호화된 버전을 포함하는 이진 키 패키지
  • BitLocker 복구 도구
간단히 말해, 회사에서는 위 항목 모두에 항상 액세스할 수 있어야 합니다.
복구 암호를 수동 또는 자동으로 백업할 수 있습니다. 그룹 정책 설정을 사용하여 복구 암호를 Active Directory 도메인 서비스에 자동으로 백업하는 것이 좋습니다.
그림 3과 같이 이 설정을 구성할 때 이진 키 패키지의 백업 옵션을 선택하십시오. 이진 키 패키지에는 암호화된 버전의 VMK 및 FVEK가 들어 있으므로 필요한 경우 BitLocker 복구 도구를 사용할 수 있습니다.
그림 3 복구 정보에 키 패키지를 포함하도록 그룹 정책 구성
그림 3 복구 정보에 키 패키지를 포함하도록 그룹 정책 구성 (더 크게 보려면 이미지를 클릭하십시오.)
BitLocker 복구 도구는 BitLocker를 사용하는 손상된 디스크에서 데이터를 복구할 수 있도록 설계되었습니다. 이것은 숙련된 관리자를 위한 고급 도구입니다. BitLocker 복구 도구에 대한 자세한 내용은 Microsoft 기술 자료 문서(support.microsoft.com/kb/928201) 또는 웹 캐스트 "Microsoft BitLocker in the Enterprise: BitLocker Tools to Make Your Life Easier"(라이브 데모 포함)(go.microsoft.com/fwlink/?LinkId=114985)를 참조하십시오.
BitLocker를 사용하더라도 데이터를 백업해야 합니다. 손상되거나 계획적인 공격을 당한 디스크에서 BitLocker 복구 도구를 사용하여 모든 데이터는 커녕 일부 데이터라도 복구할 수 있다는 보장은 없습니다.

TPM 사용 폭 확대
기술적으로는 BitLocker의 변화라고 할 수 없지만 설명할 가치가 있습니다. SP1 이전에는 Windows OS에서 TPM을 사용하는 것이 BitLocker뿐이었지만 지금은 일부 다른 기능도 TPM을 사용합니다. 예를 들어, TPM을 사용할 수 있는 경우 Windows는 난수를 생성할 때 TPM을 사용하여 엔트로피를 증가시킵니다. 그러면 모든 종류의 암호화 품질이 향상되며, 심지어 게임도 훨씬 자연스럽게 진행됩니다.
그러나 이벤트 뷰어에 표시되는 TPM 관련 이벤트가 모두 BitLocker와 관련된 것은 아닙니다. IT 전문가라면 다른 시스템 구성 요소나 다른 공급업체의 소프트웨어에서도 TPM을 사용할 수 있는지, 그리고 그로 인해 이벤트가 기록되는지 궁금할 것입니다.

Windows Server 2008의 BitLocker
Windows Vista와 Windows Server 2008은 코드베이스를 공유하므로 SP1에 나타나는 BitLocker의 변경 사항은 Windows Server 2008에서도 동일합니다. 그러나 BitLocker가 서버와 무슨 관련이 있을까요? BitLocker는 본질적으로 오프라인 공격으로부터 컴퓨터를 보호하는 도구입니다. 다시 말해, BitLocker는 실행 중인 시스템을 보호하지 않는데 서버는 일반적으로 항상 실행 중인 것으로 간주됩니다.
사실은 서버나 서버의 하드 디스크가 오프라인 공격에 노출될 수 있는 경우가 있습니다. 그런 경우가 아니더라도 BitLocker는 서버 또는 하드 디스크를 중단해야 할 때 큰 도움이 됩니다. 이에 대해서는 나중에 살펴보겠습니다. 먼저 BitLocker를 서버에 설치하여 실행하는 방법을 알아보겠습니다.

BitLocker 구하기 및 설치
BitLocker는 모든 Windows Server 2008 버전에 포함되어 있지만 선택적 구성 요소 또는 기능이므로 서버 관리자나 명령줄에서 설치해야 합니다. BitLocker는 부분적으로 NTFS 필터 드라이버로 구현됩니다. 이 필터 드라이버를 설치하려면 컴퓨터를 다시 시작해야 합니다. 즉, 서버에서 BitLocker를 활성화하려면 다시 부팅해야 합니다. Windows Vista와 마찬가지로 BitLocker에도 부하 분산 구성이 필요하므로 컴퓨터 시작에 사용하는 활성 파티션은 암호화되지 않은 상태로 유지됩니다. 제조업체에서 사전 구성되지 않은 서버의 경우, BitLocker 드라이브 준비 도구를 사용하여 BitLocker를 지원하도록 하드 디스크를 구성하면 편리합니다. 그러나 하드 드라이브 분할에 익숙한 사용자라면 하드 디스크를 수동으로 구성할 수도 있습니다.
BitLocker를 Windows Server 2008에 설치하려면 그림 4와 같이 서버 관리자 그래픽 인터페이스를 사용하여 기능 목록에서 BitLocker를 선택하거나 서버 관리자 명령줄 인터페이스에 다음 명령을 입력합니다.
그림 4 서버 관리자에서 BitLocker 선택
그림 4 서버 관리자에서 BitLocker 선택 (더 크게 보려면 이미지를 클릭하십시오.)
ServerManagerCmd –install BitLocker –restart
서버 관리자를 사용하면 BitLocker와 BitLocker용 관리 도구가 설치됩니다. BitLocker를 설치하지 않고 관리 구성 요소를 설치할 수도 있습니다. 이 경우 필터 드라이버가 포함되지 않기 때문에 시스템을 다시 시작할 필요가 없습니다. 이 구성 요소의 이름은 "RSAT-BitLocker"입니다.
BitLocker는 Server Core 설치 옵션을 실행하는 컴퓨터에서 제대로 작동하지만, 서버 관리자를 사용하여 Server Core에 BitLocker를 설치하거나 그래픽 사용자 인터페이스를 사용하여 Server Core의 BitLocker를 관리할 수는 없습니다. 구성 요소를 설치하려면 명령줄 도구 pkgmgr 또는 ocsetup를 사용해야 합니다.
BitLocker 이진을 설치하고 부하 분산의 필수 구성으로 디스크를 구성한 경우 OS 볼륨에서 BitLocker를 사용할 수 있습니다. Windows Server 2008의 BitLocker 제어판 애플릿에는 Windows Vista SP1에서와 동일한 아이콘과 옵션이 있습니다. BitLocker를 고급 모드로 사용하려면 서버에 적용되는 그룹 정책 개체 또는 로컬 정책 편집기를 사용하여 기본 설정을 조정해야 합니다.
Server Core에서 또는 manage-bde.wsf(제어판을 사용하지 않을 경우)를 사용하여 BitLocker를 설정할 수 있습니다. C: 드라이브에서 BitLocker를 사용하려면 다음과 같이 입력합니다.
manage-bde.wsf –on C: -RecoveryPassword –RecoveryKey F:\
여기서 C:는 암호화할 볼륨이고, F:\는 복구 키 복사본을 이진 형식으로 저장할 USB 키 또는 다른 볼륨입니다. UNC 경로를 사용하여 네트워크 드라이브에 복구 키를 저장할 수도 있습니다. 숫자 텍스트 형식의 복구 암호도 생성되어 표시됩니다. 하드웨어 플랫폼이 BitLocker 요구 사항을 모두 충족하는 경우 –skiphardwaretest 매개 변수를 추가할 수 있습니다. 그러면 다시 부팅하는 횟수를 한 번 더 줄일 수 있습니다.

서버 시나리오
이제 서버에서 BitLocker가 진가를 발휘하는 몇 가지 구체적인 시나리오를 살펴보겠습니다. 설명한 것처럼 BitLocker는 Windows가 실행 중이 아닐 때 이루어지는 오프라인 공격으로부터 보호하도록 설계되었습니다.
지점 서버에서 BitLocker를 사용하는 가장 큰 이유 중 하나는 Windows Server 2008 지점 전략의 일환으로 사용하기 위해서입니다. 서버의 1/4 ~ 1/3은 지점에 설치됩니다. 즉, 서버 중 일부는 물리적 보안 수준이 낮고 IT 지원에 대한 액세스 권한이 부족하며 데이터 센터 연결 수준도 낮은 지점에 설치됩니다. 또한 지점은 매력적인 공격 대상이기도 합니다. BitLocker를 RODC(읽기 전용 도메인 컨트롤러) 등의 기능과 함께 사용하면 반드시 지점에 저장해서 사용해야 하는 중요 데이터를 보호할 수 있지만, 데이터 센터처럼 물리적 보안이 쉽지는 않습니다.
여기서 올바른 보안 수준에 대해 잠시 생각해 보겠습니다. 데이터에 대한 무단 액세스 차단과 사용자 개입 없는 즉각적인 서버 작동 재개 중 어느 것이 더 중요합니까? 대부분의 지점에서는 서버를 다시 시작할 때 PIN 입력을 요구하는 것으로 충분하다고 생각됩니다. 그러나 결정은 해당 회사에서 내려야 합니다.
디스크 배송 하드 드라이브의 데이터를 멀리 배송해야 하는 경우가 있습니다. 디스크 하나를 배송하거나, 전체 서버를 미리 구성한 후 배송할 수 있습니다. 배송 중에는 이러한 디스크의 데이터를 제어할 수 없으므로 데이터 복제, 손실 또는 도난의 위험이 있습니다.
이러한 위험을 줄이려면 배송하기 전에 컴퓨터의 볼륨에서 BitLocker를 사용하도록 설정한 다음 복구 키 또는 복구 암호를 제외한 모든 키 보호기를 제거합니다. 이 키 또는 암호는 서버와 별도로 직접 전달하거나 전화 또는 암호화된 전자 메일로 데이터를 받을 담당자에게 전달할 수 있습니다. 배송된 컴퓨터 또는 디스크를 받은 쪽에서는 복구 암호를 사용하여 드라이브의 잠금을 해제합니다. 원하는 경우 드라이브를 암호화된 상태로 두고 다른 키 보호기를 추가하거나, 배송 후 디스크를 완전히 해독할 수 있습니다.
이 방법은 지점의 도메인 컨트롤러나 서버를 준비할 때 특히 효율적입니다.
서버 도난 이전 단원에서 설명한 것처럼 서버, 특히 도메인 컨트롤러는 도난 당할 위험이 높습니다. 랩톱은 견물생심으로 훔치는 경우가 있지만 서버 절도범들은 세심하게 목표를 선별합니다. TPM 무결성 검사만 요구하도록 BitLocker를 구성한 경우 훔친 서버의 전원을 켜고 간단히 부팅할 수 있습니다. 반면에 서버의 드라이브가 BitLocker로 보호되어 있고 BitLocker는 고급 모드로 구성되어 USB 키나 PIN 또는 둘 다 필요한 경우에는 도둑이 적절한 시간 내에 유용한 정보를 얻기가 매우 어려워집니다.
디스크 도난 반대로 디스크만 도난 당한 경우에는 TPM으로 상당한 보호가 가능합니다. BitLocker로 보호된 드라이브는 원본 서버의 TPM이 있어야만 잠금 해제되므로 디스크를 다른 컴퓨터에 넣어도 읽을 수 없습니다.
노출 감소 TPM 칩이 포함된 서버 하드웨어를 주문하고 BitLocker 플랫폼 무결성 검사를 사용하여 일부 형태의 맬웨어에 대한 방어 수준을 높입니다. 특히 BitLocker는 Windows가 오프라인 상태일 때 변경된 사항이나 초기 시작 구성 요소에 대한 변경을 감지합니다. rootkit와 같은 맬웨어가 설치를 위해 재부팅을 요구할 때는 더욱 그러합니다. 완벽한 솔루션은 아니지만 Windows 코드 무결성 기능이나 Microsoft® ForefrontTM Client Security와 같은 제품과 함께 사용하면 효율적인 심층 방어 계층이 하나 더 형성됩니다.
안전한 폐기 BitLocker가 가장 빛을 발하는 상황 중 하나는 서버 또는 디스크의 수명 주기가 만료될 때입니다. 서버나 서버의 디스크를 제대로 파기하지 않고 폐기하는 상황에 대한 이야기를 들어본 적이 있습니까? 폐기된 하드 드라이브의 유용한 정보를 사용하려는 비양심적인 구매자들로 인해 경매 사이트에서 중고 하드 드라이브가 새 제품보다 비싸게 팔리는 것을 알고 있습니까?
BitLocker가 있으면 디스크에서 유용한 데이터를 정리하는 데 많은 비용과 시간을 들이는 대신 다른 방법을 사용할 수 있습니다. 기본적으로, 어떤 정보도 사용하기 편한 형식으로 디스크에 기록되지 않습니다. 암호화된 데이터는 사용할 수 없기 때문에 키 정보를 모두 제거하면 빠르고 간단하게 해결됩니다. 그런 뒤에는 디스크 하드웨어가 어떻게 되더라도 문제가 없습니다. 데이터가 악의적인 사용자의 손에 들어가는 것을 걱정할 필요 없이 디스크를 판매하거나, 재활용하거나, 용도 변경할 수 있습니다.
Windows Vista 및 Windows Server 2008에서는 반복 덮어쓰기할 때를 비롯하여 BitLocker 키를 삭제하도록 format 명령이 업데이트되었습니다. 이제 드라이브를 간단하고 효율적으로 폐기할 수 있습니다.

최신 뉴스
여러분이 이 게시물을 접하기 몇 주일 이전에 이미 수많은 최신 자료, 논문 및 뉴스 기사 등에서 하드웨어의 몇 가지 흥미로운 특징과 그러한 특징이 BitLocker, 다른 Windows 보안 기능 및 여러 공급업체의 각종 암호화 제품에 미치는 영향에 대해 다루었습니다. 그 중 일부를 잠시 살펴보겠습니다.
프린스턴 대학의 연구원들은 첨단 컴퓨터 메모리의 특성인 "DRAM 잔류 자기"(citp.princeton.edu/pub/coldboot.pdf)의 존재를 매우 효율적으로 증명하는 논문을 출판했습니다. 간단히 말해, 메모리 전원이 차단된 뒤에도 일정 시간 동안 컴퓨터 메모리의 내용에 액세스할 수 있습니다. 물론 Windows가 실행 중인 동안에는 BitLocker가 키를 사용하여 메모리의 데이터 해독을 차단하지만, 문제는 권한 없는 사용자가 이 키를 습득할 수 있다는 것입니다.
Adam Boileau의 다른 데모(security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf)에서는 IEEE 1394(FireWire)를 사용하여 DMA(직접 메모리 액세스)를 허용하는 방법을 보여 줍니다. 이 방법으로 암호나 해독 키 등 Windows의 비밀 정보를 확보할 수 있습니다. 재미 있는 것은 DMA가 1394의 핵심이라는 점입니다. 이는 결함이 아니라 Firewire의 설계 의도에 부합하는 것입니다.
이러한 두 가지 공격의 공통점은 실행 중이거나 아주 최근에 실행된 컴퓨터에 물리적으로 액세스해야 한다는 것입니다. BitLocker는 온라인 공격을 차단하도록 설계되지 않았기 때문에 어느 정도의 물리적인 보안은 필요합니다. 적절한 심층 방어를 위해서는 많은 도구와 기능을 사용하고, 물리적 보안 환경을 구축하고, 기본적인 회사 정책을 수립하고, 사용자를 지속적으로 교육해야 합니다.
물론 이것이 새로운 발견은 아닙니다. 이러한 사실은 이미 알려져 있으며 Microsoft® DET(데이터 암호화 도구 키트)에 설명되어 있습니다. DET의 위험 분석 기능은 고객이 보안과 가용성, 구현 및 관리 비용을 적절하게 절충할 수 있도록 돕기 위한 것입니다. 간단한 일은 아니지만, 교육받은 고객이라면 보안, 가용성, 비용 사이에서 적절한 균형점을 찾아 결정을 내릴 것입니다.
DET 외에도 몇 가지 우수한 논평과 지침을 알려 주신 분들이 있습니다. Russ Humphries는 그의 블로그(go.microsoft.com/fwlink/?LinkId=115217)에서 DRAM 잔류 자기를 감안한 보안 절충안에 대해 설명했습니다. 또한 Douglas MacIver는 SI(System Integrity) 팀 블로그(go.microsoft.com/fwlink/?LinkId=115218)에서 구체적인 추가 구성 단계와 현재 선택할 수 있는 대처 방안에 대해 설명하고 있습니다. 이들 두 유용한 블로그를 읽어 보시기 바랍니다. 또한 DET도 읽어보시기 바랍니다.
이러한 권장 사항의 핵심은 컴퓨터를 절전 모드로 두고 자리를 떠나지 말고(대신 최대 절전 모드 사용) USB 키 또는 PIN을 요구하는 고급 모드를 사용하라는 것입니다.

결론
BitLocker는 Windows Vista의 가장 유용한 기능 중 하나입니다. SP1 릴리스에서는 사용할 수 있는 상황을 늘리고 더 많은 데이터 보호 요건을 충족하라는 고객의 의견을 그대로 반영하여 이 기능을 더욱 개선했습니다. 휴지 상태의 데이터 보호 기능을 Windows Server 2008에 도입한 결과, 서버나 클라이언트 워크스테이션, 데이터 센터, 지점, 모바일 작업자 등 데이터의 저장 위치를 불문하고 데이터 보호 및 규정 준수 방안이 확대되었습니다.

Byron Hynes는 Microsoft EPG(Enterprise and Partner Group)의 엔터프라이즈 기술 전략가로 보안 기능과 제품을 주로 다루고 있습니다. Byron Hynes는 Windows Server 부서에서 근무하다가 EPG에 합류했으며 2005년부터 BitLocker(System Integrity) 팀과 긴밀하게 협력해 왔습니다. 여러분의 의견과 질문을 기다리겠습니다. Tech•Ed 2008로 연락하거나 bhynes@microsoft.com으로 전자 메일을 보내주십시오.


보안
소프트웨어 제한 정책을 사용하여 응용 프로그램 잠금
Chris Corio and Durga Prasad Sayana
한 눈에 보기:
  • 소프트웨어 제한 정책의 작동 방식
  • 사용자 환경의 응용 프로그램 인벤토리
  • 정책 만들기 및 적용

IT 전문가들은 데스크톱 시스템의 총 소유 비용(TCO)을 줄여야 할 때 흔히 두 가지 핵심 전략을 생각합니다. 첫 번째 전략은
Administrators 그룹에서 데스크톱 사용자의 계정을 가져오는 것이고, 두 번째 전략은 사용자가 실행할 수 있는 응용 프로그램을 제한하는 것입니다. 엔터프라이즈 환경에서 이러한 문제를 해결하기는 대단히 어려울 수 있으나, Windows Vista®에는 이 목표를 달성하는 데 도움이 되는 몇 가지 기능이 있습니다.
Windows Vista 및 UAC(사용자 계정 컨트롤) 기능이 비약적으로 발전한 결과, IT 전문가들은 엔터프라이즈 사용자를 Users 그룹(표준 사용자)의 구성원으로 실행할 수 있게 되었습니다. UAC 기능으로 인해 모든 응용 프로그램의 기본 보안 컨텍스트가 Administrator 그룹이 아닌 User 그룹으로 바뀌었습니다. Users 그룹으로 마이그레이션하는 것은 만만찮은 작업이지만 시간이 지나고 업계가 이 새로운 패러다임에 적응해 갈수록 점점 더 쉬워질 것입니다.
대부분의 관리자는 사용자를 Users 그룹으로 이동하는 문제를 분석하는 도중이나 분석을 마친 후에﻿ 사용자에게 필요한 응용 프로그램의 카탈로그를 작성하고 그러한 응용 프로그램만 허용할 방법이 무엇인지 고민합니다. 소프트웨어 제한 정책 기능은 IT 전문가들의 이러한 고민을 해결하기 위해 설계되었습니다.
즉, 실행을 허용할 응용 프로그램을 지정한 다음 그 정책을 그룹 정책으로 배포하기만 하면 됩니다. 이러한 정책을 전사적으로 적용하면 TCO를 줄일 수 있을 뿐 아니라 이 잠금으로 인해 지원되지 않는 응용 프로그램 관련 문제도 제한됩니다. 추가 기사 "핵심 소프트웨어 제한 정책"에서 다룬 것처럼 매우 특이하고 흥미로운 방식으로 소프트웨어 제한 정책을 사용할 수도 있습니다.

소프트웨어 제한 정책의 작동 방식
소프트웨어 제한 정책의 목적은 Windows Vista 시스템에서 사용자가 실행할 수 있는 코드를 정확히 제어하는 데 있습니다. 관리자는 해당 환경에서 실행 가능한 작업과 불가능한 작업을 정의하는 정책을 작성합니다. 그런 다음 코드를 실행할 가능성이 있는 모든 시기와 위치를 감안하여 이 정책을 평가합니다. 여기에는 프로세스를 생성할 때, ShellExecute를 호출할 때, 스크립트를 실행할 때 등이 모두 포함됩니다. 더 자세한 내용은 조금 뒤에 설명하겠습니다.
실행이 허용된 응용 프로그램은 그대로 시작되지만, 실행을 허용하지 않기로 결정된 응용 프로그램은 차단하고 사용자에게 그 사실을 알립니다. 예를 들어, "시작" 메뉴에서 "카드놀이"를 실행하려고 하는데 이 프로그램의 실행이 허용되지 않았다면 그림 1과 비슷한 대화 상자가 표시됩니다.
그림 1 차단된 응용 프로그램에 나타나는 대화 상자
그림 1 차단된 응용 프로그램에 나타나는 대화 상자 (더 크게 보려면 이미지를 클릭하십시오.)
소프트웨어 제한 정책을 정의하기 위한 UI는 GPOE(그룹 정책 개체 편집기)에 있으며, 여기서 잠금 정책을 작성합니다. 실행 가능한 코드와 실행 불가능한 코드를 정의하는 방법은 다양합니다. 정책을 작성하고 테스트를 마친 뒤 해당 정책을 배포할 수 있습니다.

소프트웨어 제한 정책 정의
가장 먼저 내려야 할 주요 결정은 기본 규칙 유형을 선택하는 것이며, 이 결정은 해당 환경에서 소프트웨어 제한 정책의 작동 방식을 크게 좌우합니다. 소프트웨어 제한 정책은 "허용 목록" 또는 "거부 목록" 모드로 배포할 수 있습니다. 기본적으로, 사용자 환경에서 실행을 허용할 모든 응용 프로그램을 설명하는 정책을 만들지 아니면 실행할 수 없는 모든 응용 프로그램을 정의하는 정책을 만들지 선택하는 것입니다.
"허용 목록" 모드에서 정책의 기본 규칙은 "제한됨"이며 명시적으로 실행을 허용하지 않은 모든 응용 프로그램은 차단됩니다. "거부 목록" 모드의 기본 규칙은 "제한 없음"이고 명시적으로 나열된 응용 프로그램만 제한합니다.
짐작하시다시피, 응용 프로그램 잠금을 통해 대폭적인 TCO 절감과 보안상의 이점을 추구하려는 경우 "거부 목록" 모드는 비현실적인 방법입니다. 모든 맬웨어와 문제가 있는 기타 응용 프로그램을 차단하는 대규모 목록을 작성하여 유지하는 것은 거의 불가능하므로, 기본 규칙이 "제한됨"인 "허용 목록" 모드로 소프트웨어 제한 정책을 구현하는 것이 좋습니다.

사용자 환경의 응용 프로그램 인벤토리
실행 가능한 응용 프로그램을 지정하는 정책을 설계하려면 사용자에게 필요한 응용 프로그램이 무엇인지 정확히 파악해야 합니다. 소프트웨어 제한 정책은 매우 간단한 정책으로 사용자 환경에서 실행 중인 응용 프로그램을 정확하게 이해하기 위한 고급 로깅 기능을 제공합니다.
사용자 환경의 샘플 시스템에서 기본 규칙이 "제한 없음"으로 설정된 소프트웨어 제한 정책을 배포하고 그 밖의 추가 규칙은 모두 제거합니다. 이 계획에서는 소프트웨어 제한 정책을 사용하기는 하지만 응용 프로그램을 제한하는 대신 실행 중인 응용 프로그램을 모니터할 뿐입니다.
그런 다음 아래와 같은 레지스트리 값을 만들어 고급 로깅 기능을 지정하고 로그 파일을 기록할 경로를 설정합니다.
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>
이제 응용 프로그램을 실행하여 소프트웨어 제한 정책이 평가되면(모두 실행 허용하는 정책도 평가됨) 로그 파일에 항목이 기록됩니다﻿.
각 로그 항목에는 소프트웨어 제한 정책의 호출자, 호출 프로세스의 프로세스 ID(PID), 평가 대상, 적용된 소프트웨어 제한 정책의 유형, 규칙 식별자 등이 포함됩니다. 다음은 사용자가 notepad.exe를 두 번 클릭할 때 기록된 샘플 항목입니다.
explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}
이 로그 파일에는 응용 프로그램을 차단하도록 설정하여 사용 중인 소프트웨어 제한 정책이 검사할 실행 파일의 코드 부분이 모두 표시됩니다. 즉, 로그 파일의 각 항목에 대해 "허용 목록"에 포함할지 여부를 결정해야 합니다. 시스템을 작동하는 데 필요한 Windows®의 일부 이진 코드가 검사됩니다.
여기서 설명하는 로깅 기법은 해당 환경에서 소프트웨어 제한 정책이 적용될 응용 프로그램을 정확하게 파악할 수 있는 방법이지만 이 작업을 수행하는 유일한 방법은 아닙니다.
Microsoft® 응용 프로그램 호환성 도구 키트 5.0에 포함된 Inventory Collector를 사용하여 해당 환경에서 사용 중인 응용 프로그램의 인벤토리를 작성할 수 있습니다. 이 도구를 여러 가지 방법으로 사용하여 사용자 환경에 설치된 응용 프로그램을 검색하고 그 결과를 중앙 데이터베이스에 통합할 수 있습니다.

추가 규칙 작성
이제 해당 환경에서 실행을 허용할 응용 프로그램 목록을 작성했으므로 이러한 응용 프로그램을 실행하도록 허용하는 실제 규칙을 만들 준비가 되었습니다. 소프트웨어 제한 정책 기능에서는 두 가지 방법으로 정책을 식별합니다. 즉, 응용 프로그램의 암호화 속성을 기반으로 하는 방법(예: 해시)과 신뢰할 수 있는 응용 프로그램이 있는 신뢰할 수 있는 경로 또는 폴더를 정의하는 방법이 있습니다.
그림 2는 GPOE(gpedit.msc)의 소프트웨어 제한 정책 노드에서 응용 프로그램을 실행하도록 허용하는 규칙을 추가할 위치를 보여 줍니다. 사용자 환경에서 응용 프로그램을 정의하는 가장 쉬운 방법은 로깅 단계에서 발생하는 모든 이진 코드에 대해 하나의 해시 규칙을 만드는 것입니다.
그림 2 gpedit.msc를 사용하여 소프트웨어 제한 정책 작성
그림 2 gpedit.msc를 사용하여 소프트웨어 제한 정책 작성 (더 크게 보려면 이미지를 클릭하십시오.)
해시는 특정 비트 집합에 대해 반환되는 고유한 값이기 때문에 정책의 각 이진은 서로 다른 해시를 갖게 됩니다. 이 방법은 정책 내의 특정 이진만 실행을 허용하므로 매우 안전합니다.
물론 이 방법의 단점도 몇 가지 있습니다. 예를 들어, 사용자 환경에는 수천 개의 이진이 있을 수 있습니다. 소프트웨어 제한 정책 UI로 이러한 규칙을 모두 작성하는 것은 어려울 뿐만 아니라 규칙 수가 늘어나면 성능에 영향을 미칠 수 있습니다. 또한 사용자 환경에서 응용 프로그램이 업데이트될 때마다 하나 이상의 새 해시 규칙을 배포해야 합니다. 응용 프로그램이 업데이트될 때 이 대형 정책을 함께 업데이트하는 것은 엄청난 부담이 될 수 있습니다.
다행히 ﻿사용자 환경에서 소프트웨어 제한 정책을 사용하기 쉽도록 하는 규칙 식별 방법이 두 가지 더 있으므로 이러한 부담을 피할 수 있습니다. 암호화 보안 경로를 준수하여 특정 인증서로 서명된 모든 이진의 실행을 허용하는 규칙을 만들 수 있습니다.
응용 프로그램을 업데이트할 때 새 이진도 대개 이전과 동일한 인증서로 서명되기 때문에 이런 방법으로 정책 목록을 손쉽게 유지 관리할 수 있습니다. 그러나 이전 버전의 이진을 사용자 환경에서 실행하지 않으려는 경우에는 ﻿"제한됨" 해시 규칙을 추가하여 해당 파일의 실행 허용을 차단해야 합니다.
기본적으로 소프트웨어 제한 정책에 대해서는 인증서 규칙 평가를 사용하지 않습니다. 그렇게 해야 하는 두 가지 이유가 있습니다.
첫째, 소프트웨어 제한 정책의 인증서 규칙은 해당 시스템의 "신뢰할 수 있는 게시자" 저장소에 있는 항목에 따라 정의됩니다. "신뢰할 수 있는 게시자" 저장소는 소프트웨어 제한 정책의 규칙 외에 다른 용도로도 사용되기 때문에, 소프트웨어 제한 정책 기능에 이 저장소를 사용하는 것은 시간을 두고 더 고려해야 합니다.
둘째, 파일의 서명이 유효한지 여부를 결정하기 위해서는 해당 파일의 해시를 가져와서 서명 정보와 비교해야 합니다. 디스크에서 전체 파일을 읽어온 다음 처리하여 해시를 계산해야 하는 파일 해싱은 많은 비용이 소요되는 작업입니다.
인증서 규칙을 사용하려면 "소프트웨어 제한 정책" 노드로 이동하여 결과 창에서 "적용 개체"를 선택합니다. 그런 다음 해당 속성 대화 상자를 두 번 클릭하여 열고 "인증서 규칙 적용" 라디오 옵션을 선택합니다.
코드 식별에 흔히 사용되는 다른 방법으로는 로컬 시스템의 코드 경로를 사용하는 방법이 있습니다. 이것은 효율적이고 효과적인 기법이지만 한 가지 단점이 있습니다. 즉, 해당 폴더의 보안 설정이 제대로 설정되어 있는지 주의해서 확인해야 합니다.
사용자의 파일 기록을 허용하는 특정한 경로 규칙(예: 바탕 화면)을 추가하면 사용자들이 원하는 실행 파일을 해당 폴더에 넣고 무엇이든 실행할 수 있게 됩니다. 그러나 Administrators 그룹에 속하지 않는 사용자는 Program Files 또는 Windows 디렉터리의 항목을 수정할 수 없습니다. 즉, 모든 응용 프로그램이 Program Files 디렉터리에 있고 사용자가 Administrators 그룹에 속하지 않는 경우에는 매우 간단하고 효과적인 정책을 적용하기 위한 경로 규칙이 필요합니다.
경로 규칙은 몇 가지 기능으로 인해 일부 환경에 더 적합합니다. 와일드카드가 허용되며, 환경 변수를 사용하여 해당 환경 내에서 변경 가능한 규칙을 손쉽게 정의할 수 있습니다. 즉, 사용자에 따라 %systemdrive%가 ﻿c:\가 아닐 수도 있습니다.
성능과 유지 관리를 고려할 때 이것은 가장 문제가 적은 코드 식별 방법입니다. 경로 규칙은 분명 고려해야 할 방법이지만, 그에 따르는 보안 문제도 생각해야 합니다.

네트워크 영역 규칙
소프트웨어 제한 정책에는 현재 사용되지 않는 네트워크 영역 규칙이라는 규칙 유형도 있습니다. 이 규칙은 원래 식별 및 신뢰할 수 있는 소스의 실행 파일 코드는 실행을 허용한다는 생각으로 만들어졌습니다. 그러나 그렇게 하기는 매우 어려웠으며, 따라서 잘 되지도 않았습니다. 현재 소프트웨어 제한 정책의 진입점에 해당하는 대부분의 위치에서는 이 규칙 유형을 적용하지 않습니다.
대부분의 응용 프로그램이 %Program Files% 디렉터리에 설치되어 있고 특정 인증서로 서명된 나머지 실행 파일은 다른 곳에 설치되어 있다면 서로 다른 유형의 규칙을 사용할 수 있습니다. 해시 규칙 몇 개와 경로 규칙 두어 가지로 적당한 정책을 만들 수 있을 것입니다.
그림 3과 같이 규칙은 순서에 따라 처리된다는 것을 명심하십시오. 인증서 규칙이 가장 구체적이고, 그 다음에는 해시 규칙, 경로 규칙, 와일드카드가 있는 경로 규칙의 순서입니다. 따라서 해시 규칙 및 경로 규칙으로 식별되는 코드의 경우 해시 규칙의 보안 수준이 우선 적용됩니다.
그림 3 규칙﻿ 처리 순서
그림 3 규칙﻿ 처리 순서 (더 크게 보려면 이미지를 클릭하십시오.)

정책 적용
소프트웨어 제한 정책 기능은 보안되는 시스템에서 폭넓게 활용됩니다. 코드 실행이 가능한 모든 위치에 소프트웨어 제한 정책을 적용하고 이 정책을 검사하여 실행 파일 코드의 실행이 허용되었는지 확인하는 것입니다.
여러 곳에서 소프트웨어 제한 정책을 검사할 수 있지만 가장 쉬운 진입점은 CreateProcess입니다. CreateProcess 도중에 정책을 검사하여 해당 응용 프로그램의 이진 실행을 허용할지 여부를 결정합니다. 정책 검사는 SaferIdentifyLevel API에서 수행하고 그 내용을 공개적으로 기록합니다. 일반적인 프로세스는 그림 4에 나와 있습니다. SaferIdentifyLevel에 대해 좀 더 자세히 살펴보겠습니다.
그림 4 SaferIdentifyLevel을 사용하여 이진 실행 여부 결정
그림 4 SaferIdentifyLevel을 사용하여 이진 실행 여부 결정 (더 크게 보려면 이미지를 클릭하십시오.)
소프트웨어 제한 정책이 적용되는 API 중 CreateProcess 다음으로 많이 사용되는 것은 ShellExecute입니다. ShellExecute는 사용자가 시작 메뉴에서 응용 프로그램을 클릭하거나 바탕 화면에서 두 번 클릭할 때 호출되는 API입니다.
다양한 파일 형식에서 ShellExecute를 호출할 수 있습니다. .txt 파일의 경우 파일에서 ShellExecute를 호출해도 기술적으로 해당 파일이 열리기는 하지만 실제로 실행되지는 않습니다. 그러므로 ShellExecute가 호출될 때 검사할 파일 형식을 제어할 수 있도록 소프트웨어 제한 정책에 실행 파일 형식 목록이 포함됩니다. 소프트웨어 제한 정책 UI에서 ﻿이 실행 파일 형식 목록을 사용자 지정할 수 있습니다.
CreateProcess 및 ShellExecute 외에 LoadLibrary와 스크립트 호스트도 중요한 통합 지점입니다. LoadLibrary가 실행 파일 코드를 검사하기에 중요한 위치인 것은 분명하지만 불행히도 몇 가지 특수한 제약 조건이 있습니다.
대부분의 응용 프로그램은 실행 파일 하나와 DLL 여러 개를 로드합니다. 그리고 보통 시스템에서는 많은 응용 프로그램을 실행합니다. 즉, LoadLibrary는 많은 정책을 검사해야 합니다. 코드 식별 정책에 따라서는 적용에 상당한 비용이 드는 진입점이 될 수 있습니다. 예를 들어, 시스템에 로드된 모든 DLL의 해시를 검사하려면 해당 이진을 해싱한 다음 이를 수천 개의 해시와 비교해야 합니다.
이 기능은 기본적으로 사용하지 않지만 수동으로 설정할 수도 있습니다. gpedit.msc에서 소프트웨어 제한 정책 노드로 이동하여 "적용"을 두 번 클릭한 다음 "모든 소프트웨어 파일" 라디오 단추를 선택하면 됩니다.
설명한 것처럼 소프트웨어 제한 정책은 시스템에 있는 대부분의 스크립트 호스트와 통합됩니다. 여기에는 cmd, VBScript, Cscript, JScript® 등이 포함됩니다. 다른 진입점과 마찬가지로 이러한 진입점에서도 소프트웨어 제한 정책 적용 API로 SaferIdentifyLevel을 주로 사용합니다.
SaferIdentifyLevel API는 해당하는 소프트웨어 제한 정책의 식별 정보를 조사하여 지정된 실행 파일의 실행을 허용할지 여부를 결정합니다. 이 API는 문서로 공개된 API입니다. 타사 스크립트 호스트 및 실행 파일 환경에서는﻿ 실행 파일 코드의 실행 허용 여부를 결정하는 소프트웨어 제한 정책을 통합할 때 이 API를 사용할 수 있고 또 사용해야 ﻿합니다.

표준 사용자로 실행
소프트웨어 제한 정책의 잘 알려지지 않은 기능으로, 특정 응용 프로그램을 시작할 때 그 권한을 필터링하는 기능이 있습니다. 이 기능은 Windows XP에서 도입되었으나 소프트웨어 제한 정책 UI에 사용하기 시작한 것은 Windows Vista부터입니다.
이 방법을 사용하면 ﻿Administrators 그룹의 구성원인 사용자도 표준 사용자로서 응용 프로그램을 실행할 수 있으므로 Windows Vista UAC의 전신인 셈입니다. 규칙을 만들고 "추가 규칙" UI에서 "보안 수준"을 "일반 사용자"로 설정한 경우에 이러한 상황이 벌어집니다.
UAC의 토큰 필터링 기능과 소프트웨어 제한 정책의 "일반 사용자" 규칙은 모두 ﻿CreateRestrictedToken API와 동일하게 동작하는 기본 API를 활용합니다. 그러나 두 기술의 전체 아키텍처에는 큰 차이가 있으며, UAC는 몇 가지 중요한 부분에서 소프트웨어 제한 정책과 다릅니다.
첫째, UAC를 사용하는 Windows Vista에서 모든 응용 프로그램은 Administrator 그룹에 속하는 사용자의 경우에도 기본적으로 Users 그룹의 구성원과 비슷한 보안 토큰으로 시작됩니다. 소프트웨어 제한 정책으로도 이러한 결과를 얻을 수 있지만, 응용 프로그램을 설치하는 등의 작업을 해야 하는 사용자는 자신의 실제 토큰인 Administrator 토큰으로 응용 프로그램을 시작할 수 없습니다. 기본 보안 컨텍스트의 변화와 더불어 사용자의 전체 관리자 토큰에 대한 액세스가 쉽다는 것이 UAC의 주된 장점입니다.
두 번째 차이점은 실행 파일의 경우 코드 작동에 필요한 권한 수준이 코드 자체에 표시된다는 점입니다. ISV(독립 소프트웨어 공급업체)와 개발자들은 자신의 코드에 필요한 사항을 알고 있으므로 이것은 중요한 차이점입니다. 예를 들어, 관리자 권한이 필요한 항목을 편집해야 하는 제어판 응용 프로그램이라면 매니페스트에 그러한 요구 사항을 지정할 수 있습니다. 따라서 ISV는 특정한 권한 수준을 부과하는 대신 그 수준을 변경할 수 있는 수단 없이도 해당 응용 프로그램에 필요한 권한을 지정할 수 있습니다.
"일반 사용자" 규칙을 완전히 이해할 때까지 당분간 이 규칙은 사용하지 마십시오. UAC는 Administrators 그룹의 데스크톱 사용자를 줄이는 데 유용한 기능이므로 엔터프라이즈 환경에서 UAC를 그대로 사용하는 것을 신중하게 고려하십시오.

현재 사용되는 소프트웨어 제한 정책
소프트웨어 제한 정책을 사용할 때는 여러 가지 유동적인 부분을 고려해야 합니다. 사실 생각과 달리 모르는 사이에 소프트웨어 제한 정책을 사용하고 있는 경우도 있습니다. 예를 들어, Windows Vista 시스템에서 자녀 보호 기능을 실행한다면 응용 프로그램 실행을 제한하는 소프트웨어 제한 정책을 사용하고 있는 것입니다.
Windows XP에 소프트웨어 제한 정책을 처음 도입했을 때 이것은 중요한 기술적 발전이었습니다. 그러나 현재 IT 전문가들이 주목하는 것은 응용 프로그램 잠금입니다.
Windows Vista의 소프트웨어 제한 정책 기능에는 아직 다듬어져야 할 몇 가지 단점이 있지만, 관리자들이 자신의 환경에서 실행 중인 프로그램을 제어할 수 있는 이 향상된 기능을 원하는 것은 분명합니다. 다행히 이 기술은 앞으로도 계속 발전할 것이며 IT 전문가들은 손쉽게 시스템을 관리하고 Microsoft Windows 환경의 운영 비용을 절감하게 될 것입니다.﻿
핵심 소프트웨어 제한 정책
Windows를 키오스크 모드로 잠그는 정책을 만드는 것도 소프트웨어 제한 정책을 적용하는 한 가지 방법입니다. 사실 Microsoft에서는 이러한 키오스크를 만들 수 있도록 SteadyState™라는 도구 키트를 제작했습니다. 그러나 실행 가능한 응용 프로그램을 잠그는 기능만 필요하다면 이보다 간단한 방법이 있습니다.
Windows Vista에 로그온하는 데 필요한 응용 프로그램을 최소한으로 허용하려면 %windir%\system32에서 logonui.exe 및 userinit.exe를 실행하도록 허용하는 정책을 만듭니다. 또한 대부분의 사용자에게 다음과 같은 응용 프로그램의 실행을 허용해야 합니다.
dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....
기본 Windows 셸을 원한다면 %windir%\explorer.exe를 추가할 수도 있습니다.
또는 Internet Explorer®와 같은 응용 프로그램으로 곧장 부팅되도록 할 수 있습니다. 이 경우 explorer.exe 대신 iexplore.exe를 지정해야 합니다.
이 핵심 정책의 또다른 특징은 사용자가 Administrators 그룹의 구성원이 아니어야 한다는 것입니다. 사용자가 정책을 우회하지 못하도록 하려면 이 점이 중요합니다. 그러나 사용자들은 매우 기본적인 응용 프로그램만 실행할 수 있고 Administrator 권한이 없기 때문에 응용 프로그램을 설치하거나 시스템을 유지 관리할 수는 없습니다.
따라서 해당하는 시스템에 대해 그러한 작업을 수행하기 위한 다른 방법이 필요합니다. Administrator 계정으로 로컬에서 로그온하여 이러한 시스템을 업데이트하고 유지 관리하려면 로컬 관리자를 제외한 모든 사용자에게 소프트웨어 제한 정책을 적용하는 라디오 단추를 선택해야 합니다. 또한 consent.exe 및 cmd.exe가 이 정책에 포함되어야 합니다. 그러면 Administrator가 Administrator 명령 프롬프트에서 모든 관리 옵션을 시작할 수 있게 됩니다.
UAC는 기본적으로 사용자의 보안 토큰 권한을 제한하여 해당 토큰이 Administrators 그룹에 속하지 않는 것처럼 보이게 합니다. Administrators에게 정책을 적용하지 않도록 위의 설정을 지정하더라도 사용자에게는 정책이 적용됩니다. Administrator가 실제로 완전한 관리자 권한을 가지도록 하고 소프트웨어 제한 정책이 적용되지 않게 하려면 UAC 권한 상승 과정을 마쳐야 합니다.

Chris CorioChris Corio는 Microsoft의 Windows 보안 팀에서 5년 이상 근무하면서 Windows 보안을 위한 응용 프로그램 보안 기술 및 관리 기술을 주로 담당해 왔습니다. 문의 사항이 있으면 winsecurity@chriscorio.com으로 연락하십시오.
Durga Prasad Sayana﻿Durga Prasad Sayana는 Windows 핵심 보안 팀에서 소프트웨어 설계 엔지니어 겸 테스트를 담당하고 있습니다. 주로 보안 기술 및 소프트웨어 테스트 업무를 처리합니다. 문의 사항이 있으면 durgas@microsoft.com으로 연락하십시오.


보안
Windows Vista 방화벽 관리
Jesper M. Johansson
한 눈에 보기:
  • 규칙 유형 및 시나리오
  • 방화벽 프로필
  • 도메인 격리 규칙
  • 아웃바운드 필터링의 문제

얼마 전 저는 Windows Vista 방화벽에 대한 글을 블로그에 남겼습니다. 당시 몇 가지 뛰어난 기능을 간단히 소개했지만 배포에 대한 조언은 별로 없었습니다.
이 글에서는 엔터프라이즈 관리를 용이하게 하는 Windows Vista® 방화벽의 기능을 보다 자세히 설명하고자 합니다. 또한 업무를 더욱 간소화하고 사용자를 더욱 안전하게 보호하는 방법에 대해서도 말씀드리겠습니다.
최근 Windows Vista SP1의 발표로 Windows Vista 엔터프라이즈 배포를 고려 중인 분이 계실 것입니다. (보통 기업에서는 새로운 OS로 마이그레이션하기 전에 첫 번째 서비스 팩이 발표될 때까지 기다립니다.) Windows Vista를 전보다 더 심각하게 고려 중인 엔터프라이즈 환경의 IT 전문가라면 방화벽에 대해 자세히 알아볼 필요가 있습니다. Windows Vista 방화벽의 가능성을 알고난 뒤에는 타사의 보안 패키지 계약에서 방화벽 제품을 빼고자 할 수도 있습니다.

Windows 방화벽의 과거와 현재
처음 릴리스된 Windows® XP의 방화벽에는 부족한 부분이 많았습니다. 당시 상용 호스트 기반 방화벽의 보안 기능을 대체하기에는 충분했지만 새롭거나 혁신적인 기능은 없었습니다.
Windows XP SP2의 방화벽은 완전히 바뀌었습니다. 특히 엔터프라이즈 관리가 용이하도록 설계되었습니다. Windows XP SP2 방화벽은 경량이며, 중앙에서 관리가 가능하고, 효과적이며, 방해가 되지 않는다는 점에서 매우 매력적입니다. 그러나 Windows XP SP2 방화벽의 가장 중요한 기능은 부팅 시 시스템을 보호하는 점이라고 생각됩니다.
이 마지막 기능은 매우 중요합니다. 과거에는 방화벽을 사용하고 있는데도 부팅 중 감염되는 시스템이 많았습니다. 사실 Blaster가 최고로 유행할 때는 4분에 하나씩 공격을 받을 정도였습니다. 즉, 보호되지 않은 컴퓨터로 인터넷에 접속할 경우 평균 4분에 한 대씩 감염될 수 있다는 것입니다. 그리고 부팅 시 시스템을 보호하지 않는 방화벽을 사용할 경우 12대 중 한 대가 재부팅 시 감염되었습니다. 이 수치는 Microsoft가 Windows XP SP2 방화벽이 부팅 시 시스템을 보호하도록 만드는 계기가 되었습니다.
Windows Vista에서 방화벽은 다시 한 번 탈바꿈하게 됩니다. 관리 측면에서 가장 눈에 띄는 변화는 IPsec(Internet Protocol Security)와 방화벽의 관리 인터페이스가 통합된 것입니다. 이것은 매우 자연스러운 변화입니다. IPsec와 방화벽은 둘 다 허용되지 않는 것을 차단하기 위해 설계되었습니다. 차이점이라면 방화벽의 경우 허용 항목을 정의하는 매개 변수가 별로 세밀하지 않고, IPsec에서는 대량의 주소 공간을 차단하거나 허용하기가 불편하다는 것입니다.
관리 인터페이스 하나에 두 기능이 모두 있다면 관리자는 어디에는 IPsec 규칙이 필요하고 어디에는 방화벽 필터가 필요한지 염려하지 않고 두 가지 기술을 효과적으로 활용할 수 있습니다. 즉, 시스템의 네트워크 공격 지점을 한꺼번에 볼 수 있으며 이로써 실수를 저지를 위험이 최소한으로 줄어듭니다.
Windows Vista SP1의 방화벽은 몇 가지 향상된 안정성 기능을 갖추고 있습니다. 또한 IPsec용의 새로운 기능(특히 Suite B 알고리즘)이 추가되었습니다. 이것은 AES(Advanced Encryption System), ECC(Elliptic Curve Cryptography), SHA(Secure Hash Algorithm) 256 및 384로 구성된 암호화 관련 알고리즘의 집합입니다.
그러나 가장 중요한 점은 서비스 팩 1에 NAP(네트워크 액세스 보호) 지원이 추가되었다는 것입니다. NAP는 관리되고 보안이 유지된 클라이언트가 네트워크에 연결하기 전에 최신 보안 정책, 업데이트 및 맬웨어 방지 정의를 적용하는 정책 적용 도구입니다. 악성 호스트의 네트워크 연결을 NAP로 막을 수는 없지만, 크게 손상되지 않은 한 관리되는 모든 호스트에 정책이 철저하게 적용되도록 할 수는 있습니다.
고급 보안 기능의 Windows 방화벽이라고 불리는 Windows Vista 방화벽은 Windows Server® 2008에도 포함됩니다. 모든 기능은 원격으로 관리가 가능하며 그룹 정책을 사용하여 네트워크 전체에 대해 구성할 수 있습니다.

규칙 유형 및 시나리오
방화벽과 IPsec 기능을 관리 인터페이스에 결합한 결과 방향 규칙과 연결 규칙이라는 두 가지 서로 다른 유형의 규칙이 존재하게 되었습니다. 방향 규칙은 해당 방향에서 허용할 트래픽을 정의하는 표준 방화벽 규칙입니다. 연결 규칙은 컴퓨터 간 연결에 대한 보호 매개 변수를 정의합니다. 방향 규칙은 이전의 방화벽에서 사용하던 방화벽 규칙과 유사하고, 연결 규칙은 Windows XP SP2에서 방화벽과 함께 사용하던 IPsec 규칙과 유사합니다.
방화벽과 IPsec를 한 인터페이스에 결합한 결과 여러 가지 매우 흥미로운 시나리오가 가능해졌습니다. 예를 들어, 네트워크에서 시스템을 서로 격리하는 것은 오늘날 매우 중요한 보안 개념 중 하나입니다. Microsoft에서는 이것을 "서버와 도메인 격리"라고 합니다.
서버와 도메인 격리에서는 IPsec 기능과 방화벽 기능을 모두 사용합니다. 따라서 새로운 방화벽 관리 인터페이스에 격리 규칙을 위한 기능을 추가했습니다. 이 기능은 도메인 구성과 같이 소스 또는 대상 시스템의 속성을 기준으로 연결을 제한할 때 유용합니다.
그림 1에서 보듯이 "새 연결 보안 규칙 마법사"를 시작하면 어떤 유형의 규칙을 만들 것인지 묻습니다. "격리"를 선택하면 마법사가 격리 규칙에 맞는 설정을 미리 구성해 줍니다.
그림 1 새 연결 보안 규칙 마법사로 격리 규칙 만들기
그림 1 새 연결 보안 규칙 마법사로 격리 규칙 만들기 (더 크게 보려면 이미지를 클릭하십시오.)
그림 1을 보면 격리 규칙에 상태도 나타남을 알 수 있습니다. 서버와 도메인 격리에 사용되는 규칙은 사실 NAP에 사용하는 규칙과 동일합니다.
일부 유형의 트래픽에는 인증을 적용할 수 없습니다. 예를 들어, DNS 확인을 위해 인증을 요구하는 일은 없을 것입니다. 이러한 유형의 트래픽 끝점에 대해서는 인증 예외 규칙이 필요합니다. 인증 예외 규칙이란 말 그대로 IPsec 요구 사항에서 해당 트래픽을 제외하는 것입니다.
서버 간 규칙은 이름이 약간 잘못 붙여졌습니다. 서버에서 더 많이 사용되기는 하지만 클라이언트에서도 사용할 수 있습니다. 서버 간 규칙에서는 인증을 요구하도록 연결을 구성합니다. 격리 규칙의 경우 인증을 요구하고 도메인 구성 또는 상태와 같이 추가 기준의 이행을 요구한다는 점에서 서버 간 규칙과 다릅니다.
터널 규칙에서는 기본적으로 사이트 간 VPN(가상 사설망)과 게이트웨이 간 터널을 정의합니다. Windows Vista를 게이트웨이에 사용하는 일은 거의 없으므로 Windows Vista에서 터널 규칙은 거의 사용되지 않습니다. 완전히 사용자 지정된 규칙을 만들고 이를 통해 규칙의 모든 매개 변수를 사용자 지정할 수 있습니다.

규칙 순서 지정
규칙 순서 지정은 얼핏 보면 약간 복잡합니다. 규칙 순서 지정을 이해하는 비결은 먼저 순서를 잊는 것입니다. 이것은 순서 지정이라기보다 일치 항목을 선택하는 것에 더 가깝습니다. 인바운드 트래픽을 예로 들어보겠습니다. 허용 규칙과 일치하지 않는 인바운드 트래픽은 기본적으로 차단됩니다. 이것을 "허용 규칙부터 고려"하는 순서 지정으로 생각할 수 있지만 완전히 정확하지는 않습니다. 특정 패킷이 허용 규칙과 차단 규칙 양쪽에 모두 일치하는 경우 차단 규칙이 우선합니다. 간단히 말해, 일치는 다음과 같습니다.
  1. 차단 규칙. 이러한 규칙 중 하나와 일치하는 패킷 또는 연결은 삭제됩니다.
  2. 허용 규칙. 이러한 규칙 중 하나와 일치하는 패킷 또는 연결은 허용됩니다.
  3. 기본 방향 프로필 동작. 일치하는 차단 규칙 또는 허용 규칙이 없는 트래픽은 프로필에 해당 방향의 프로필에 대해 기본값으로 지정된 동작에 따라 처리됩니다. 모든 프로필에서 인바운드 방향은 기본 구성에서 해당 트래픽 차단을 의미합니다. 아웃바운드 방향은 기본적으로 기본 구성에서 트래픽을 허용한다는 의미입니다.
일치 프로세스는 인증된 우회(IPsec) 규칙으로 조정할 수 있습니다. 이 규칙 유형을 사용하면 규칙의 다른 매개 변수와 일치하는 모든 인증된 트래픽은 다른 규칙과의 일치 여부에 상관없이 허용됩니다. 인증된 우회 규칙은 그림 2와 같이 차단 규칙 무시 옵션이 선택된 방향 규칙입니다. 이러한 규칙은 인증된 트래픽이 시스템에 항상 도달하도록 하기 위해 가장 먼저 고려됩니다. 이것은 인증된 호스트의 트래픽을 허용하면서 다른 호스트의 트래픽은 손쉽게 차단하는 방법입니다. 이 규칙을 순서 지정에서 0순위로 고려할 수 있습니다. 따라서 전체 규칙 순서 목록은 다음과 같습니다.
그림 2 차단 규칙 무시 옵션을 선택하여 인증된 우회 규칙 구성
그림 2 차단 규칙 무시 옵션을 선택하여 인증된 우회 규칙 구성 (더 크게 보려면 이미지를 클릭하십시오.)

0. 인증된 우회 규칙
1. 차단 규칙
2. 허용 규칙
3. 기본 방향 프로필 동작

각 클래스에 트래픽 패턴과 일치하는 규칙이 여럿 있어도 별로 상관 없습니다. 트래픽과 일치하는 규칙이 나타나는 즉시 규칙 처리가 중지됩니다.

공개, 개인 및 도메인
네트워킹 리소스
  • TechNet 보안 센터
  • Netsh Advfirewall 명령줄 도구 사용
  • Windows Vista 및 Windows Server 2008의 Windows 방화벽과 IPsec 기반 연결에 대한 보안 규칙
  • Security Watch Windows Server 2008에서 SCW 사용

새 방화벽에는 공개, 개인 및 도메인의 세 가지 프로필이 있습니다. 반면, Windows XP SP2 방화벽에는 표준과 도메인의 두 가지 네트워크 프로필이 있습니다. 도메인 프로필은 컴퓨터에서 도메인 컨트롤러를 찾을 수 있는 경우 자동으로 호출됩니다. 그렇지 않은 경우 Windows XP에서는 표준 프로필을 사용했습니다. 로밍 중인 컴퓨터를 완전히 잠그면서도 조직의 네트워크에서는 필요한 원격 관리 기능을 모두 허용하는 이 프로필은 보안 관리자를 위한 강력한 기능을 제공했습니다. 그러나 일부 사용자(특히 가정의 개인 네트워크 사용자)의 경우에는 약간의 문제가 있었습니다. 도메인 컨트롤러에 접근할 수 없을 때 언제나 표준 프로필을 사용했기 때문에 사용자의 가정에서는 시스템이 차단되었습니다.
Windows Vista의 새로운 개인 프로필은 이 문제를 해결하는 데 도움이 됩니다. 이제 시스템을 새 네트워크에 연결하면 네트워크가 공개(이전 표준 프로필의 새 이름)인지 아니면 개인인지 묻고 그에 따라 시스템을 구성합니다. 시스템은 네트워크의 인프라 서버에서 제공하는 네트워크 매개 변수를 기준으로 특정 네트워크에 연결될 때마다 해당 프로필을 기억합니다. 이 방법은 그렇게 간단하지 않지만 더 많은 네트워크를 효율적으로 차단하는 데 도움이 됩니다.
시스템이 도메인에 있는지 여부를 감지하는 논리도 향상되었습니다. 보다 빠르고 안정적인 전환이 가능해졌으며, 시스템이 실제로 도메인에 있을 때 공개 또는 개인 프로필을 사용하는 경우가 적어졌습니다.
규칙을 특정 유형의 네트워크에 연계함으로써 너무 많은 정보가 노출되거나 신뢰할 수 없는 네트워크의 시스템에 연결하지 않도록 할 수 있습니다. 이것은 방화벽과 IPsec의 통합으로 얻을 수 있는 이점 중 하나입니다.
이러한 새 규칙을 사용하면 이전에는 불가능하던 몇 가지 제한을 적용할 수 있습니다. 예를 들어, 수 년간 Windows 네트워킹에서 공격자들은 사용자가 신뢰할 수 없는 호스트에 SMB(서버 메시지 블록) 연결하도록 유도한 뒤 인증 시퀀스를 통해 암호 해킹에 필요한 질의-응답 쌍을 얻으려고 유인하는 공격을 시도했습니다. 이 공격의 이전 버전은 일반 텍스트 인증으로 다운그레이드하거나 사용자의 질의-응답 쌍을 원래 컴퓨터에 반영시키는 데 사용되기도 했습니다. 앞의 방법은 몇 년 전 해결되었습니다. 뒤의 방법은 Windows XP SP2에서 그 위험이 줄어들었지만 질의-응답 쌍을 노출하는 것은 현명하지 않은 행동입니다.
Windows Vista 방화벽의 또 다른 새 기능인 아웃바운드 필터링으로 이를 방지할 수 있습니다. 예를 들어, 관리자는 공개 프로필에서 모든 아웃바운드 SMB 연결(TCP 135, 139, 445 및 UDP 137, 138, 445 포트 연결)을 차단하도록 결정할 수 있습니다. 그러면 유인 공격에서 질의-응답 쌍을 얻기 위해 시스템을 사용하기가 더욱 어려워지고 인터넷에서 신뢰할 수 없는 Windows 파일 공유에 액세스하지 못하게 됩니다.
다시 말하지만 이 방법은 간단하지 않습니다. 예를 들어, 시스템의 보안이 이미 무력화되었다면 공격자가 간단히 규칙을 사용하지 않도록 설정할 수 있으므로 이 규칙으로 시스템의 통신을 막을 수 없습니다. 그러나 잘 작동하지만 위험에 노출될 수 있는 시스템을 보호하는 방법으로는 매우 유용할 수 있습니다.
Windows XP SP2와 마찬가지로 Windows Vista 및 Windows Server 2008에서도 한 번에 하나의 프로필만 활성화할 수 있다는 것을 기억해야 합니다. 시스템에 네트워크 인터페이스가 두 개 있는데 하나는 도메인에 있고 다른 하나는 공개 네트워크에 있는 경우 공개 방화벽 프로필이 양쪽 네트워크에 적용됩니다. 언제나 가장 제한적인 프로필이 사용됩니다. 짐작하시겠지만 공개 프로필이 개인 프로필보다 제한적이고, 개인 프로필이 도메인 프로필보다 제한적입니다. 따라서 아웃바운드 SMB 차단 규칙은 VPN 연결을 통해 많은 트래픽을 허용할 수 있습니다.
컴퓨터가 공개 또는 개인 네트워크에 있을 때 VPN 연결을 통한 트래픽을 허용하려면 VPN 인터페이스에만 적용되는 방향 규칙을 만듭니다. 이것이 작동하려면 Windows가 VPN 인터페이스를 그렇게 인식해야 합니다. Microsoft® 라우팅 및 원격 액세스 서비스 VPN 서버를 사용하지 않는 경우, 전체적으로 구현하기 전에 이 기능을 테스트하십시오. 클라이언트로 들어오는 인바운드 트래픽과 사용자 지정 아웃바운드 규칙에서 주로 문제가 발생할 수 있습니다.

방화벽 규칙 만들기
방화벽 규칙 만들기는 새 방화벽에서 더욱 쉬워졌습니다. 그림 3의 새 규칙 마법사에서 모든 일반 유형의 규칙을 정의할 수 있습니다. 그리고 여기에는 특정 서비스용으로 사전 정의된 규칙도 포함됩니다.
그림 3 새 규칙 마법사에서 사전 정의된 규칙
그림 3 새 규칙 마법사에서 사전 정의된 규칙 (더 크게 보려면 이미지를 클릭하십시오.)
사전 정의된 규칙은 특히 중요합니다. 서버 격리는 기본적으로 꼭 필요한 시스템에서만 서비스를 사용할 수 있도록 제한하는 것입니다. 서버 제품에서 Windows 보안 구성 마법사(SCW)를 사용하여 비교적 쉽게 이 작업을 수행할 수 있습니다. (TechNet Magazine 2008년 3월호에서 SCW에 대해 다루었습니다.)
그러나 클라이언트 버전의 Windows에는 아직까지 이와 유사한 기능이 없습니다. 사전 정의된 규칙 유형을 사용할 경우 서비스에 사용되는 끝점을 파악하는 것과 같은 힘든 작업이 대부분 사라집니다. 방화벽은 "iSCSI 서비스"가 나타내는 프로그램이 무엇인지 안다는 점에서 응용 프로그램을 인식할 뿐 아니라, 특정 기능을 설명하는 사전 정의된 규칙도 포함하고 있습니다. 그러므로 어떤 규칙으로 어떤 컴퓨터를 커버할 것인지만 생각하면 됩니다. 이것도 어렵고 시간이 많이 걸리기는 하지만 적어도 사용자의 환경에 맞출 수 있습니다.
인증 방화벽에서 기대할 수 있는 유연성을 모두 갖춘 사용자 지정 규칙(그림 3에 드롭다운으로 가려져 있음)도 있습니다. 예를 들어, IPsec 암호화 트래픽만 허용하는 규칙을 원한다면 그림 2에 표시된 마법사의 "동작" 페이지에서 보안 연결만 허용하는 옵션을 선택합니다.
이 옵션을 선택하면 암호화를 사용하는 옵션도 활성화됩니다. 이 옵션을 비워 둘 경우 해당 트래픽은 ESP-NULL(NULL 키로 캡슐화된 보안 페이로드)을 사용합니다. IPsec을 인증에 사용하는 경우 이 방법을 권장합니다. 그러면 트래픽이 암호화 없이 네트워크를 통과하므로 대부분의 네트워크 관리 도구를 계속 사용할 수 있고, 암호화를 원할 때는 확인란을 선택하기만 하면 됩니다.
많은 경우 네트워크 트래픽의 암호화는 악성 호스트로부터 트래픽을 받지 않는 것만큼 중요하지는 않습니다. 네트워크에서 트래픽 암호화를 통해 네트워크에 대한 액세스 권한을 얻은 악성 사용자가 패킷 내용을 보지 못하도록 막을 수 있습니다. 인증을 요구하면 패킷 자체를 전송하지 못하게 되므로 공격을 피할 수 있습니다. 네트워크 수준 암호화가 필요한 상황이 많다는 것은 분명하지만, 인증만으로 충분한 상황도 많습니다.

도메인 격리 규칙 만들기
대부분의 환경에서는 제한된 수의 컴퓨터만 워크스테이션에 트래픽을 보낼 수 있도록 하려고 할 것입니다. 적어도 모든 워크스테이션은 도메인 격리 규칙으로 구성되어야 합니다. Windows XP에서 복잡하던 이 작업이 Windows Vista에서는 쉬워졌습니다.
우선 관리 도구를 열고 "연결 보안 규칙" 노드를 선택합니다. 그런 다음 노드를 마우스 오른쪽 단추로 클릭하고 "새 규칙"을 선택하면 그림 1과 같은 대화 상자가 나타납니다. "격리" 규칙을 선택하고 "다음"을 클릭합니다. 이제 규칙을 강제로 적용할지 여부를 선택해야 합니다. 대부분의 워크스테이션에서는 인바운드 트래픽에 대한 인증이 필요합니다. 그러면 도메인에 가입되지 않은 컴퓨터가 워크스테이션에 트래픽을 보낼 수 없게 됩니다. 하지만 인프라 서비스에서 서비스를 요청하려면 시스템에서 일부 아웃바운드 트래픽이 암호화 없이 통과하도록 허용해야 합니다. 그러므로 가장 좋은 옵션은 인바운드 연결에는 인증을 사용하고 아웃바운드 연결에는 인증을 요청하는 것입니다.
이제 인증 방법을 선택합니다. 기본 선택은 "기본값"입니다. 별로 도움 되는 이름은 아니죠? 고급 보안이 설정된 Windows 방화벽 노드를 마우스 오른쪽 단추로 클릭하고 속성을 선택하면 나타나는 IPsec 속성에서 각 컴퓨터의 기본 인증 방법을 구성할 수 있습니다. 기본 인증 방법은 항상 가장 단순하면서도 안전한 Kerberos입니다. 그러나 확실히 하기 위해 말씀드리지만 규칙을 만들 때 이 방법을 실제로 선택하는 것이 좋습니다. 대개 사용자는 제외하고 컴퓨터만 인증하기를 원합니다. 둘 다 인증하도록 요구할 경우 익명으로 전송된 SNMP 트래픽과 같은 특정 유형의 관리 트래픽을 받지 못할 수 있습니다.
인증 방법을 선택했으면 이 규칙을 사용할 프로필만 선택하면 됩니다. Kerberos 티켓을 제공할 수 있는 도메인에 가입한 컴퓨터에 적용되는 규칙이므로 개인 또는 공개 프로필에서 이 특정 출구를 열어둘 필요는 없습니다. 규칙을 저장하면 작업이 완료됩니다.
기본 격리 규칙은 더 이상 복잡하지 않습니다. 하지만 IPsec의 강력한 기능을 격리에 활용하려면 워크스테이션에서도 서버 격리를 구현해야 합니다. 이렇게 하면 워크스테이션에서 다른 클라이언트를 수신하지 않도록 제한할 수 있습니다. 대신 워크스테이션은 해당하는 관리 스테이션에만 응답합니다. 클라이언트 시스템이 다른 클라이언트에 대한 수신을 거부한다면 각종 맬웨어의 발생 비율이 얼마나 줄어들지 상상해 보십시오.

방화벽 스크립트 작성
새 방화벽에는 구현 및 평가를 스크립트할 수 있는 중요한 API가 있습니다. 구현에 그룹 정책을 사용하는 것이 이상적이지만, 그룹 정책을 항상 사용할 수 있는 것은 아니므로 적절한 API 집합으로 방화벽을 구성하는 것이 중요합니다. 이 API는 INetFWPolicy2 API 그룹에 속합니다. SDK(소프트웨어 개발 키트) 및 MSDN® Library에 이 API의 사용 방법에 대한 자세한 설명이 있으나 몇 가지 예를 통해 핵심을 이해할 수 있을 것입니다.
한 가지 일반적인 사례를 들자면 규칙 그룹의 사용 여부를 결정해야 할 때가 있습니다. 예를 들어, 응용 프로그램 또는 관리자가 시스템에서 파일 및 프린터 공유의 필요성 여부를 결정해야 한다고 가정합시다. 이 작업은 INetFWPolicy2::IsRuleGroupCurrentlyEnabled를 통해 가능합니다. 그림 4는 이 기능을 보여주는 VBScript 샘플입니다.
Figure 4 INetFWPolicy2::IsRuleGroupCurrentlyEnabled 사용
' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
    fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if
파일 및 프린터 공유 설정이 해제되어 있으며 이를 사용하도록 설정해야 하는 경우, 먼저 그러한 작업을 수행할 수 있는지와 그룹 정책에 의해 무효화되지 않을 것인지를 확인해야 합니다. 이 작업은 INetFWPolicy2::LocalPolicyModifyState API로 수행합니다. 실제 코드가 채워질 기본 구조는 다음과 같습니다.
Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
  Case NET_FW_MODIFY_STATE_OK
  Case NET_FW_MODIFY_STATE_GP_OVERRIDE
  Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

명령줄 및 인터페이스 유형
관리에 사용할 적절한 명령줄이 없는 방화벽은 완전하지 않습니다. netsh에 advfirewall이라는 하위 컨텍스트가 있습니다. advfirewall 컨텍스트는 그래픽 UI에서 수행할 수 있는 모든 작업에 대한 명령줄 액세스를 제공합니다. 예를 들어, 포트 445에서 아웃바운드 차단을 구현하려는 경우 권한 상승된 명령줄에서 다음 명령을 실행할 수 있습니다.
netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any
그런 다음 같은 명령을 실행하여 TCP를 UDP로 바꾸고 차단을 완료해야 합니다. 이로써 규칙 구현이 완료됩니다.
방화벽의 멋진 기능 중 하나는 네트워크 인터페이스 유형을 기준으로 규칙을 구성할 수 있다는 것입니다. 어떤 규칙은 VPN 연결에 영향을 줄 수도 있습니다. Windows에서 VPN 인터페이스로 인식하는 한, 이 유형의 규칙을 사용하여 해당 인터페이스를 통해 전달되는 트래픽을 제외시킬 수 있습니다.
netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS
GUI에서도 이 작업을 수행할 수 있지만 규칙을 만들기 전까지는 불가능합니다. 이 경우 규칙을 마우스 오른쪽 단추로 클릭하고 "속성"을 선택한 다음 "고급" 탭을 클릭해야 합니다. 여기에 있는 "인터페이스 유형" 섹션에서 적절한 인터페이스 유형을 선택할 수 있습니다.

아웃바운드 필터링
Windows XP SP2 방화벽에 아웃바운드 필터링 기능이 없다는 사실은 내장 방화벽이 보안용으로는 부족하다는 주요 이유로 지적되었습니다. Windows XP SP2 방화벽은 아웃바운드 필터링 기능이 없기 때문에 안전하지 않다는 기사가 수천 가지나 있었습니다. 이것은 바꾸어 말하면 Windows XP에서는 어떠한 방화벽도 아웃바운드 필터링을 안전하게 제공할 수 없다는 것을 의미합니다.
아웃바운드 필터링을 단순한 과속 방지턱에서 유용한 보안 도구로 만드는 기본적인 기능(또는 정책 적용 도구)이 Windows XP에는 없습니다. 하지만 Windows Vista에서는 가능합니다. 따라서 새 방화벽에서는 이 기능을 사용할 수 있습니다. 기본적으로, 인바운드 트래픽은 대부분 차단되고 아웃바운드 트래픽은 대부분 허용됩니다.
새 Windows Vista 방화벽의 아웃바운드 필터링은 기본적으로 필요 없는 트래픽의 서비스 이용만 차단합니다. 이 기능은 사실상 아웃바운드 필터를 제공하는 호스트에서 공격 방어를 위해 수행할 수 있는 전부이며, Windows XP에서는 이 기능이 별 의미가 없었을 것입니다.
Windows Vista의 서비스는 매우 제한적인 토큰으로 실행할 수 있습니다. 기본적으로 각 서비스에는 고유한 보안 식별자(SID)가 있습니다. 이 서비스 SID를 사용하여 네트워크 포트와 같은 리소스에 대한 액세스를 제한할 수 있습니다. 이것은 앞에서 사용자에게 트래픽을 제한할 때 살펴보았던 기능과 동일합니다. 즉, NetworkService로 두 서비스를 실행할 수 있더라도 서로의 프로세스를 관리할 수는 없으며, 방화벽에서는 이 중 하나만 외부 통신이 가능하도록 구성할 수 있습니다. 차단된 서비스가 공격을 당하더라도 허용된 서비스는 영향을 받지 않으며, 포트는 서비스 SID로 제한되므로 허용되는 포트를 사용하여 외부와 통신할 수 있습니다.
이 기능은 Windows Vista에 추가된 훌륭한 보안 기능 중 하나이며, 새 방화벽에서는 아웃바운드 방화벽 필터링으로 뛰어난 보안 수준을 얻을 수 있습니다.
사실 서비스 SID에 대한 방화벽 필터링은 새 방화벽에서 기본적으로 사용됩니다. 하지만 이를 구성할 수 있는 GUI가 없습니다. 규칙은 HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices 레지스트리 키에 사전 정의되어 있습니다. 그러나 이 키를 직접 수정할 수는 없으므로 주의해야 합니다.

아웃바운드 필터링으로 가능한 보안 수준
보안 커뮤니티에서 잘못 이해하고 있는 문제 중 하나는 아웃바운드 필터링의 실질적인 보안 가치가 얼마나 되느냐 하는 것입니다. 지금까지 아웃바운드 필터링을 통한 두 가지 보안 시나리오를 소개했지만, 둘 다 이전에는 사용할 수 없었던 Windows Vista의 새로운 기능을 사용하고 있습니다. 그럼에도 불구하고, 대개 아웃바운드 필터링이 유용하며 구매할 방화벽을 결정할 때 이 점을 중요하게 고려해야 한다는 생각이 일반적입니다.
아이러니하게도 아웃바운드 필터링 기능을 보고 방화벽을 구매한 많은 조직들이 일단 방화벽이 구현된 후에는 아웃바운드 필터링을 사용하지 않았습니다. 이것은 결국 정보 보안 그룹의 비용과 인력 낭비로 이어집니다. 실제 위협에 대한 실질적인 분석보다 무엇인가 보안에 좋을 것 같다는 느낌으로 방화벽을 구매하는 것 같습니다. 이렇게 "보안 위협"에 대한 느낌으로 결정을 내리지 말고, 사실을 기반으로 결정해야 합니다.
지지자들이 책임지지 못하는 아웃바운드 필터링에 대한 매우 단순한 사실이 있습니다. 호스트 기반 방화벽 제공업체들은 웜이나 악의적인 사용자의 공격을 받는 시스템이 아웃바운드 필터링을 통해 그 웜이 다른 시스템을 감염시키는 것을 막거나 공격자가 외부와 통신하지 못하도록 한다고 주장합니다. 그것은 사실이 아닙니다.
사실 다른 모든 조건이 같다면 지금까지 알려진 맬웨어를 아웃바운드 필터링으로 막을 수 있습니다. 하지만 Windows XP에 아웃바운드 필터링 기능이 있었다면 지금까지 발견된 웜 역시 이 기능을 해제하거나 회피하는 방법으로 만들어졌을 것입니다.
Windows XP(및 이전 버전의 Windows)에서 서비스로 실행되는 모든 웜(및 서비스로 실행되지 않는 모든 일반 웜)의 경우 그렇게 되었을 가능성이 있습니다. 그러나 그렇게 되지 않았던 한 가지 이유는 사실상 아웃바운드 필터링을 사용하는 환경이 없었고, 따라서 사용하지 않도록 할 필요가 없었기 때문입니다. 대화형 공격에서는 공격자가 마음대로 아웃바운드 필터를 회피할 수 있습니다. 임의 코드를 실행할 수 있는 공격자라면 간단한 작업입니다. 그리고 필요하다면 공격자는 사용자가 필터를 회피하도록 유인할 수도 있습니다.
아웃바운드 호스트 기반의 방화벽 필터 회피는 실제 공격 시나리오에 따라 여러 가지로 이루어질 수 있습니다. 가장 간단한 방법은 권한을 가진 사용자에게 그렇게 하도록 "요구"하는 것입니다. 아직도 너무 많은 환경에서 일반 사용자를 관리자로 실행하고 있습니다. 이러한 사용자는 원한다면 보안 정책을 회피할 권한이 있습니다. 공격자는 파악할 수 없고 즉각적이지 않은 보안 이점과 사용자에게 더 가치가 있는 어떤 것(유명한 춤추는 돼지 등) 중 하나를 사용자가 선택하도록 하기만 하면 됩니다.
많은 사용자는 이러한 유형의 대화 상자가 표시되면 실제로 무슨 일이 발생할지 예측하지 못하고 빠르게 마우스를 클릭합니다. 이것이 아웃바운드 필터링의 첫 번째 문제입니다. 보안이냐 아니면 춤추는 돼지처럼 흥미로운 것이냐, 둘 중 하나를 선택하라고 하는 대부분의 대화 상자에서는 결정을 내리는 데 필요한 실제 정보를 제공하지 않으므로 매번 춤추는 돼지가 이기게 됩니다.
보안 결정을 요구하는 대화 상자에 결정을 내리는 데 필요한 기본 정보를 충분히 표시하는 것은 생각만큼 쉽지 않습니다. 방화벽과 같은 보안 제품에서 요청하는 포트, 프로토콜 및 응용 프로그램을 이해해야 할 뿐만 아니라 그 요청이 실제로 무슨 의미이고 사용자에게 어떤 영향을 미치는지 알아야 하기 때문입니다. 이러한 정보는 프로그래밍을 통해 얻기가 매우 어렵습니다. 예를 들어, Microsoft Word가 아웃바운드 연결을 시도하고 있다는 사실은 그 연결을 통해 Word가 무엇을 시도하고 있는지만큼 흥미롭지가 않습니다.
의미 없는 대화 상자의 수를 늘리지 말고 줄여야 하는데, 아웃바운드 필터링 방화벽은 여기에 도움이 되지 않습니다. 사용자에게 꼭 필요한 정보를 제공한다는 주요 호스트 기반 방화벽 제공업체의 판촉물을 살펴보았습니다. 브로셔에서는 방화벽의 아웃바운드 필터링 기능과 권고 기능을 선전하고 있었습니다. 권고 기능은 사용자가 시도하려는 작업을 감지하고 적절한 권고를 해 줍니다. 또는 이론상 그렇게 한다고 되어 있습니다. 브로셔의 텍스트에는 스크린샷과 함께 "이 프로그램에는 아직 권고 기능을 사용할 수 없습니다. 자세한 내용은 아래를 선택하거나 추가 정보를 클릭하십시오."라고 되어 있습니다. 마케팅 자료를 보아도 이런 공급업체들은 정보가 담긴 대화 상자를 만들 수 없는 것 같습니다.
사용자에게는 올바른 보안 결정을 내리기 위한 정보가 없기 때문에 모든 아웃바운드 필터링을 구성하는 것은 관리자의 책임입니다. 따라서 관리자의 관리 부담이 크게 증가합니다.
방화벽의 질문에 사용자가 "아니요. 나중에 다시 알림"을 클릭하더라도 대개의 맬웨어는 방화벽을 회피할 수 있습니다. 악성 코드가 실행되는 동안 사용자가 일부 포트에서 아웃바운드 연결을 열 수만 있다면 악성 코드는 간단히 해당 포트를 사용할 수 있게 됩니다. 즉, 어떤 프로세스든 기존의 프로세스를 활용할 수 있습니다. 낮은 수준의 운영 체제에서는 이런 것이 허용됩니다. Windows Vista부터는 프로세스를 적절하게 제한할 수 있습니다. 이것이 기본 제한되는 서비스, 즉 아웃바운드 필터를 사용하여 기본적으로 차단하는 서비스가 있는 이유입니다.
애석하게도 대부분의 사람들은 아웃바운드 호스트 기반의 방화벽 필터링을 통해 손상된 자산이 다른 자산을 공격하지 못하도록 할 수 있다고 생각하고 있습니다. 하지만 이것은 불가능한 일입니다. 공격 당한 자산에 대해 보호 조치를 취하면서 다른 자산을 공격하지 않도록 하는 것은 소용이 없습니다. 보호라는 것은 보호하려는 자산에 대해 수행해야 하는 것이지 막아야 하는 대상을 위한 것이 아닙니다. 이미 집안으로 들어온 도둑에게 물건을 가져가지 말라고 요청하는 것은 처음부터 집에 들어오지 못하게 하는 것만 못합니다.

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


보안
디지털 인증서를 사용하여 전자 메일 보안
Matt Clapham and Blake Hutchinson
한 눈에 보기:
  • 확인 가능한 ID 만들기
  • 인증서 상태 업데이트
  • 인증서 얻기 및 교환
  • S/MIME 시스템 문제 해결

오래 전부터 사람들은 전송 중 정보 숨기기, 보낸 사람 확인 및 메시지 인증을 위해 다양한 방법을 사용해 왔습니다. 사회가 발달하면서 이 세 가지를 한 번에 해결하는 방법이 개발되었고 널리 사용되기 시작했습니다. S/MIME(Secure Multi-Purpose Internet Mail
Extensions)은 암호화 및 디지털 서명을 사용하여 전자 메일을 안전하게 보내는 시스템입니다.
현재의 암호화(숨기기) 기술은 크게 두 가지로 나눌 수 있는데, 하나는 DES(Data Encryption Standard) 또는 AES(Advanced Encryption Standard)와 같은 대칭(비밀) 키 알고리즘이고 다른 하나는 RSA 또는 ECC(Elliptical Curve Cryptography)와 같은 비대칭(공개/개인) 키 알고리즘입니다. 보낸 사람을 확인하는 이 현대적 도구는 해시라고 불리며, 고유한 서명을 만드는 수학적 단방향 함수입니다. 많이 사용되는 두 가지 해시 방법은 MD5(Message Digest Algorithm 5) 및 SHA(Secure Hash Algorithm)입니다. 컴퓨터는 이 방법으로 개별 원본 텍스트에 대응하는 고유한 해시 또는 숫자를 생성할 수 있습니다(동일한 원본 텍스트는 동일한 값으로 해시됨). 이 간단한 도구를 토대로 조합하여 만들어진 것이 PKI(공개 키 인프라) 시스템입니다.

확인 가능한 ID
인증 기관 리소스
  • 암호화 파일 서비스를 위해 인증 기관 사용
  • 네트워크에서 인증 기관 서버 이름을 바꾸거나 제거할 수 없음
  • 도메인의 컴퓨터에서 신뢰할 수 있는 인증 기관을 제거하는 방법
  • Windows 엔터프라이즈 인증 기관 역할을 해제하고 Windows Server 2003 및 Windows 2000 Server에서 모든 관련 개체를 제거하는 방법
  • 인증 기관을 도메인 컨트롤러에서 실행 중인 새 서버로 이동하는 방법

PKI 시스템에서 디지털 인증서를 사용하여 관리되는 ID는 대부분의 사람들이 국경을 넘을 때 소지해야 하는 정부 발급 신분증, 즉 여권과 다르지 않습니다. 디지털 인증서 세계의 여권 표준은 S/MIME, IPsec(Internet Protocol Security), SSH(Secure Shell), 무선 네트워크 보안, VPN(가상 사설망), 보안 서버 통신(예: SSL 웹 사이트) 등의 기술에서 서명 및 암호화를 위해 널리 사용되는 X.509 형식입니다.
인증서는 비대칭 암호화 및 해시를 기반으로 작성됩니다. 인증서를 만들려면 요청자(상위 기관에서 서명한 키를 원하는 엔티티)가 개인 키를 생성해야 합니다. 이 키는 유효성이 의심되지 않도록 잠겨 있습니다. 개인 키와 함께 그 짝이 되는 공개 키도 생성됩니다. 이름에서 알 수 있듯이, 한 쌍의 키에서 공개되는 키 부분은 비밀이 아니며 유효성이 보장되는 방식으로 자유롭게 배포됩니다.
이 키 쌍은 두 가지 기본 기능을 수행합니다. 첫째, 누구든지 공개 키로 암호화하고 이것이 개인 키로만 해독되도록 할 수 있습니다. 둘째, 개인 키로 암호화된 것을 공개 키로 해독할 수 있습니다. 이것은 개인 키로만 만들 수 있는 서명을 확인하는 데 중요합니다.
인증 기관에 보내는 요청에는 해당 키를 사용할 개인이나 컴퓨터의 ID, 알고리즘 유형 및 강도, 키 쌍의 공개 부분과 같은 정보가 포함됩니다. 인증 기관(CA)은 요청의 정보를 수신하여 검증하고, 해시 알고리즘을 사용하여 이 정보에 맞는 고유한 식별자를 만듭니다.
CA는 개인 키를 사용하여 정보의 해시를 암호화하고 이를 표준 형식(X.509 등)으로 조합하여 원래 요청에 따른 인증서를 만듭니다. X.509 인증서에는 인증서의 ID(주체), 유효 기간, 공개 키, 인증서 용도 등의 클레임 목록이 포함됩니다. 그런 다음 이 인증서를 요청자에게 반환합니다. 사실 인증서는 "본 인증 기관(CA)은 이 공개 키와 그에 해당하는 개인 부분이 여기 설명된 모든 용도에 적합함을 보증합니다"라고 말하는 토큰입니다.
루트 CA(신뢰 체인의 최상위 CA)의 인증서는 자체 서명됩니다. 널리 통용되는 루트 CA는 기본 운영 체제 또는 응용 프로그램에 미리 설치되어 있으며 패키지 또는 엔터프라이즈 구성을 통해 업데이트하거나 변경할 수 있습니다. 루트 CA와 리프 노드(대개 개인 또는 개별 시스템) 사이에는 하나 이상의 중간 CA가 있을 수 있습니다.
이 체인은 모든 노드 및 노드에 포함된 모든 상위 인증서(해당 수준의 CA 서명)로 구성됩니다. 제3자가 인증서의 유효성을 검사할 때는 로컬에서 계산된 해시를 확인하고 해당 CA 또는 개인의 공개 키를 사용하여 인증서에서 해독한 값과 계산된 값을 비교합니다. 그러면 최하위에서 루트까지 유효성이 완벽하게 검사된 신뢰 체인이 완성됩니다. 물론 루트를 신뢰할 수 있어야 합니다.

인증서 상태 업데이트
모든 정상적인 CA에는 더 이상 신뢰할 수 없는 인증서 목록을 배포하는 방법이 있습니다. 이 인증서 해지 목록(CRL)은 해당 CA가 특별히 무효화한 발급 항목을 설명합니다. 편의상 CRL은 대개 CA 인증서의 속성에 위치합니다.
CA는 정기적으로 일정(예: 2주마다) 또는 이벤트(발급된 인증서를 더 이상 신뢰할 수 없는 상황)의 두 가지 기준으로 CRL을 발행합니다. 그리고 발행된 CRL에 CA 서명을 하여 게시합니다. 수신 시스템에서 체인의 유효성을 평가할 때는 대개 해당 체인에 속하는 각 발행 CA의 CRL을 확보하려고 합니다(인증서 자체에 포함된 정보 또는 사전 정의된 신뢰할 수 있는 배포 메커니즘 이용). CRL을 얻을 수 없는 경우, 클라이언트는 최근 캐시에 저장된 복사본 중 지정된 CRL 업데이트 기간보다 오래되지 않은 것을 사용할 수 있습니다. 이것도 실패하면 클라이언트 시스템에서는 인증서가 유효한 것 같지만 해지 상태를 확인할 수 없음을 나타내는 일종의 오류를 표시합니다.
많은 응용 프로그램의 경우, 체인 또는 체인에 포함된 각 노드의 CRL을 검증할 수 없으면 인증서를 로드하는 데 시간이 오래 걸립니다. 인증서의 보호 대상이 무엇인지에 따라 사용자가 신뢰하기도 하고 않기도 합니다. 모든 CA, 특히 공개 루트에는 정기적으로 업데이트되고 널리 사용 가능한 CRL 배포 지점이 반드시 있어야 합니다.
루트는 인증서 체인의 토대이며, 체인화는 모든 인증서 계층의 토대입니다. 대부분의 클라이언트 시스템이나 응용 프로그램에서는 신뢰할 수 있는 루트와 체인으로 연결된 경우에만 리프 노드 인증서가 유효하다고 간주합니다. 여기서 신뢰할 수 있는 루트란 특정 회사가 소유 및 운영하는 엔터프라이즈 CA 또는 공개 루트 CA(VeriSign 등) 등입니다.
공개 루트 CA의 경우 상당히 전문적으로 운영되며 무결성이 보장된다는 기대가 있습니다. 기업은 해당 환경에 있는 루트 CA의 신뢰성이 중요한 것만큼 내부 작업에 대해서도 동일한 수준을 달성하기 위해 노력해야 합니다. 최적의 보호를 위해 루트 CA는 오프라인 상태를 유지하다가 인증서 발행 및 CRL 업데이트에만 사용해야 합니다. 가장 좋은 CA 운영 방법에 대한 자세한 내용은 "인증 기관 리소스" 추가 기사를 참조하십시오.
키 복구 문제도 반드시 고려해야 합니다. 사용자가 데이터를 잠가 검색이 불가능해지는 일을 방지하고 검사 속도를 높이려면 모든 사용자 발행 키의 백업 사본을 만들어야 합니다. 또한 이 백업 사본을 안전한 장소에 보관해야 합니다. 이렇게 하면 스마트 카드를 택시에 두고 내렸을 때처럼 사용자의 키가 없어지더라도 해당 키로 보호된 콘텐츠에는 계속해서 액세스할 수 있게 됩니다.
마지막으로, 모든 우수한 암호화 시스템에는 수명 주기 관리라는 개념이 있습니다. 컴퓨터가 빨라질수록 알고리즘은 약해집니다. 제대로 된 암호화 시스템이라면 시간이 흐름에 따라 자체 갱신을 통해 새로운 알고리즘과 키 크기에 적응하는 능력을 갖춰야 합니다. CA는 암호화의 약점이 발견되었을 때 및 특정 기능을 도입 또는 퇴출할 때 적절히 업데이트되어야 합니다.

S/MIME 구현
서명되거나 암호화된 전자 메일을 S/MIME을 사용하여 부트스트랩, 작성, 전송 및 수신하려면 여러 단계를 거쳐야 합니다. 여기서는 일반적인 S/MIME 시나리오를 통해 이에 대한 자세한 내용과 문제점 및 가능한 해결 방법에 대해 설명합니다. 이 시나리오에서는 서로 다른 Active Directory® 포리스트 및 서로 다른 인증 기관 체인에 속하는 두 명의 사용자(즉, 사내/외를 불문하고 업무상 분리된 엔티티)가 Microsoft® Office Outlook® 2007을 사용하여 서명되거나 암호화된 전자 메일을 서로에게 보냅니다.
여기서 설명할 작업에 필요한 인프라는 이미 갖추어져 있다고 가정합니다. 이 시나리오에서는 Active Directory 통합 엔터프라이즈 인증서 서버를 사용합니다.

인증서 얻기
첫 번째로 해야 할 일은 알맞은 인증서를 얻는 것입니다. 이를 위해 인증서 관리자 MMC(certmgr.msc)를 열고 Personal 폴더를 마우스 오른쪽 단추로 클릭한 다음 팝업 목록에서 "모든 작업"을 선택하고 목록에서 "새 인증서 요청"을 선택합니다.
그러면 그림 1과 같이 "인증서 등록" 마법사가 시작됩니다. 기본적으로 엔터프라이즈 위주의 몇 가지 옵션이 표시되지만 중요한 것은 "사용자" 인증서입니다. 나중에 서명 및 암호화 프로세스에서 이 인증서를 사용하게 됩니다. 인증서는 다음에 대해 사용할 수 있어야 합니다.
그림 1 인증서 요청
그림 1 인증서 요청 (더 크게 보려면 이미지를 클릭하십시오.)
  • 디지털 서명(만든 사람의 유효성이 포함된 메시지 작성)
  • 키 암호화(암호화 파일 시스템 등의 기술에서는 한 키를 다른 키로 보호)
  • 보안 메일(짝이 되는 개인 키를 가진 해당 수신자만 읽을 수 있도록 암호화된 메시지)
S/MIME 서명된 전자 메일을 보내는 데 키 암호화 속성은 필요하지 않습니다. 그러나 암호화된 메일을 보내거나 받을 때는 서명 속성은 필요 없지만 이 속성은 필요합니다. 기본적으로 Windows® 인증서 서비스의 템플릿을 통해 이러한 세 가지 속성을 사용할 수 있습니다. 사용자가 새 인증서를 요청할 수 없는 경우 마법사가 시작될 때 아무것도 표시되지 않습니다. 사용 가능한 엔터프라이즈 CA가 없는 경우 해당 도메인 또는 CA에 연결할 수 없음을 나타내는 "등록 오류"가 표시됩니다. 여기서는 인증서 하나로 서명과 암호화를 모두 허용한다고 가정합니다.

인증서 교환
두 사용자가 암호화된 전자 메일을 상대에게 보내는 가장 쉬운 방법은 서명된 메시지를 보내는 것입니다. 메시지를 작성한 후 "서명" 단추를 클릭하면 됩니다. (Outlook에서 이 단추는 기본적으로 숨겨져 있으며 한 번 사용한 뒤부터 표시될 수 있습니다. 새 메시지에서 "옵션" 설정을 클릭하고 "보안 설정..." 단추를 클릭한 다음 "보안 속성" 대화 상자에 있는 "이 메시지에 디지털 서명 추가" 상자를 선택하면 이 단추가 나타납니다.) 서명 단추("서명"이라고 표시된 빨간색 리본이 달린 작은 노란색 봉투)를 누르면 원본의 유효성을 설정하는 디지털 서명이 메시지에 추가됩니다.
"보내기" 단추를 누른 사용자에게 스마트 카드를 넣거나 PIN을 입력하라는 등 키 보유 사실을 입증하는 추가 토큰을 요청할 수 있습니다. 이 부분은 조직의 키 보호 방법에 따라 다릅니다.
S/MIME 서명된 메시지를 받은 사용자가 보낸 사람의 이름을 마우스 오른쪽 단추로 클릭하여 상황에 맞는 메뉴에서 "Outlook 연락처에 추가"를 선택하면 새 연락처 항목이 추가되거나 기존 연락처가 업데이트됩니다. 그리고 인증서가 해당 연락처 항목과 연결됩니다. 공용 Active Directory 환경(동일한 포리스트 또는 회사에 있는 두 사용자)에서는 사용자의 Active Directory 개체 속성에 따라 공개 사용자 인증서 배포가 자동으로 수행됩니다.
인증서를 교환하는 또 다른 방법은 각 사용자가 S/MIME 인증서를 첨부 파일로 보내는 것입니다. 이를 위해서는 두 당사자가 인증서를 CER 파일로 내보내야 합니다. 두 사용자는 인증서를 확인하고 그림 2와 같이 개인 키를 함께 내보내지 않도록 주의하면서 이어서 설명할 내보내기 프로세스를 수행합니다.
그림 2 인증서를 교환할 때 개인 키 내보내지 않기
그림 2 인증서를 교환할 때 개인 키 내보내지 않기 (더 크게 보려면 이미지를 클릭하십시오.)
그런 다음 각 수신자가 Outlook에서 수동으로 연락처 항목을 만들고 보낸 사람의 항목에 인증서를 추가합니다. 인증서를 교환한 뒤부터 두 사용자는 서로 암호화된 전자 메일을 주고 받을 수 있습니다.

문제 해결
때때로 수신자가 암호화된 메시지를 여는 데 어려움을 겪을 수 있습니다. 이때 발생하는 문제의 세 가지 주된 원인은 신뢰할 수 없는 루트 CA, 확인할 수 없는 중간 CA, 그리고 사용할 수 없는 CRL입니다.
신뢰할 수 없는 루트 CA는 Outlook에서 "서명에 문제가 있습니다. 자세한 내용을 보려면 서명 단추를 클릭하십시오."라는 해당 서명과 연결된 오류 메시지로 표시됩니다. 이 문제를 해결하려면 Outlook에서 인증서를 열고 팝업 대화 상자에서 "인증 기관 보기" 단추를 클릭합니다. 인증서 속성 대화 상자의 일반 탭에 있는 메시지를 확인합니다. CA 루트 인증서를 신뢰할 수 없으며 설치해야 한다고 하면 "자세히" 탭으로 이동합니다. "파일에 복사..." 단추를 클릭하고 마법사에 따라 모든 기본값을 수용하고 파일 이름과 폴더를 입력합니다.
이제 시스템 관리자 계정으로 새 Microsoft 관리 콘솔(MMC)을 엽니다. "파일|스냅인 추가/제거(Ctrl+M)"로 이동하여 "인증서"를 선택한 다음 프롬프트가 나타나면 "로컬 컴퓨터"를 선택하여 해당 컴퓨터 계정에 대해 그 인증서를 추가합니다. 그런 다음 왼쪽 트리에서 "인증서" 노드를 확장하고 신뢰할 수 있는 루트 인증 기관에 대해 동일한 작업을 수행합니다. 마우스 오른쪽 단추를 클릭하고 팝업 메뉴에서 "모든 작업|가져오기"를 선택합니다. 앞에서 내보낸 인증서 파일을 "신뢰할 수 있는 루트 인증 기관"으로 가져온 뒤 "마침"을 클릭합니다. 그런 다음 해당 사용자가 Outlook을 다시 시작하도록 합니다.
이 방법은 신뢰할 수 있는 루트 CA를 추가할 때만 사용해야 합니다. 모든 루트가 동등하게 생성되지는 않습니다. 이 방법으로 시스템 전체의 저장소에 루트를 추가하려면 먼저 해당 루트 CA를 누가 소유하고 운영하는지 확인하십시오. 그룹 정책을 통해 신뢰할 수 있는 루트 목록을 제어하는 경우, 클라이언트 시스템으로 구성이 푸시됩니다. 이 경우에는 이 방법이 통하지 않을 수 있습니다. 전자 메일은 완벽하게 보호되는 통신 수단이 아니므로, 보안 웹 사이트나 서버 등 다른 데이터 교환 방법을 찾아야 합니다.
위에서 언급한 두 번째 문제인 확인할 수 없는 중간 CA는 대개 두 가지 상황에서 발생합니다. 인증서 검증을 시도하는 클라이언트가 인증서에 정의된 AIA(Authority Information Access) 위치에 접근할 수 없거나 CA가 발행하는 인증서와 일치하지 않는 중간 CA 인증서 버전이 클라이언트에 있는 경우(대개 클라이언트 버전이 더 낮음)입니다. 이러한 상황은 Outlook 사용자 인터페이스에서도 매우 유사하게 나타납니다. 체인의 중간 수준 CA가 만료되고 거기서 발행한 다른 하위 인증서가 만료되기 전에 이를 다시 발행한 아주 특별한 상황에서만 이런 문제가 발생했습니다.
기본적으로 이 문제는 체인이 끊어졌을 때 나타납니다. 상위 인증서가 제대로 정의되지 않았거나 리프 노드에 올바르게 포함되지 않은 경우 상황은 더 복잡해집니다.
이 문제를 해결하려면 보낸 사람이 새 메시지를 열고 새 메시지 "옵션"을 클릭한 다음 "보안 설정" 단추와 "설정 변경" 단추를 차례로 클릭해야 합니다. 이제 서명할 인증서에 대해 "선택" 단추를 클릭하고 팝업 대화 상자에서 "인증서 보기" 단추를 클릭합니다. "인증서 경로" 탭으로 이동하여 리프 노드의 발행자(체인에서 한 수준 상위)를 선택하고 "인증서 보기" 단추를 클릭합니다. "자세히" 탭을 클릭하고 "파일에 복사..." 단추를 클릭한 다음 내보내기 마법사를 완료하고 PKCS #7(.P7B)을 선택합니다. 그림 3과 같이 "인증 경로에 있는 인증서 모두 포함" 옵션이 선택되었는지 확인합니다. 마지막으로 내보낸 체인 파일을 원하는 수신자에게 보냅니다.
그림 3 인증서 체인의 공백 해결
그림 3 인증서 체인의 공백 해결 (더 크게 보려면 이미지를 클릭하십시오.)
내보낸 인증서 체인을 받은 수신자는 앞서 루트를 가져올 때처럼 그 체인을 열어 가져와야 합니다. 한 가지 차이점은 선택한 저장 폴더가 중간 인증 기관이어야 한다는 것입니다. Outlook에서 메시지가 열리고 인증서가 유효한 것으로 표시되면 올바르게 작동하는 것입니다.
세 번째 문제인 사용할 수 없는 CRL은 해결 방법이 비교적 간단합니다. Outlook의 초기 반응은 앞의 문제와 매우 유사합니다. 하지만 루트 또는 중간 서명 CA를 신뢰할 수 있는 경우에도 오류가 표시됩니다. 인증서 체인에서 리프 위쪽의 각 수준에 대해 인증서 속성을 열고 "자세히" 탭으로 이동하여 "CRL 배포 지점" 필드를 확인합니다.
나열된 각 CRL 배포 지점(특히 인터넷 액세스 가능 지점)에 대해 CRL 파일 URL이 열리는지 확인합니다. 체인에서 한 수준씩 올라가면서 모두 검사합니다. CRL을 얻을 수 없다면 그것이 문제의 원인일 수 있습니다. 문제를 해결하려면 로컬 네트워크 정책에서 액세스를 차단하고 있지 않은지 확인해야 합니다. 차단되어 있지 않다면 해당 CA의 소유 회사에 문의하거나 CA의 CRL 배포 지점이 작동 상태로 돌아올 때까지 기다립니다.

인증서 배포
배포는 쉽습니다. 기본적으로 서명된 메시지는 메일 서버로 전송되고, 메일 서버는 검증된 방법인 SMTP를 통해 한 위치에서 다른 위치로 메시지를 보냅니다. 서명되거나 암호화된 메일을 전송할 때 발생하는 한 가지 문제는 일부 메일 시스템에서 서명 또는 암호화된 메시지를 거부하거나 차단한다는 것입니다. 해결 방법은 시스템 IT 관리자의 도움을 얻어 그러한 메시지 유형을 허용하는 것입니다. 물론, 어떤 메시지 유형은 계속해서 차단해야 할 수도 있습니다. 특정 운영 환경에서 암호화된 메시지를 허용하지 않을 타당한 이유가 수신자에게 있을 수 있기 때문입니다.

회신 암호화
암호화된 회신을 작성하려면(위의 부트스트랩 프로세스가 이미 완료되었다고 가정) 보내는 사람이 메시지를 작성한 다음 메시지 작성 창에서 "암호화" 단추(암호화라고 표시된 파란색 자물쇠가 있는 작은 노란색 봉투)를 클릭하면 됩니다. "암호화" 단추를 사용할 수 없는 경우 서명된 메시지 보내기 단계를 수행합니다. 단, 마지막 단계에서 "메시지 내용과 첨부 파일 암호화" 확인란을 선택합니다.
수신자에게 암호화된 메시지를 보낼 때 S/MIME 서명이 꼭 필요한 것은 아니지만, 서명을 하면 읽는 사람이 보낸 사람을 확인할 수 있으므로 두 가지를 함께 사용하는 것이 좋습니다(암호화 기능에는 보낸 사람에 대한 요구 사항이 없음). 암호화 프로세스에서는 모든 수신자에게 알려진 공개 키를 사용하여 메시지 암호화를 시도합니다. 인증서를 찾을 수 없는 일부 수신자의 경우, 위의 그림 4와 같이 암호화되지 않은 메시지를 보내도록 팝업 대화 상자에 표시됩니다.
그림 4 인증서에 문제가 있을 때 암호화되지 않은 메시지 보내기
그림 4 인증서에 문제가 있을 때 암호화되지 않은 메시지 보내기 (더 크게 보려면 이미지를 클릭하십시오.)
기본적으로 서명 및 암호화는 다르게 구성된 클라이언트 시스템에서도 작동해야 하지만, 하위 수준에서 지원되지 않는 해시 또는 암호화 알고리즘을 사용한 경우 다른 버전으로 암호화되거나 서명된 메시지에서 문제가 발생할 수도 있습니다. 서명된 전자 메일(SHA-512 해시 알고리즘 사용)을 Windows XP SP2 사용자에게 보낼 때 이러한 문제가 발생했습니다. 수신 시스템에서 해시를 지원하지 않기 때문에 사용자는 서명을 확인하거나 메시지를 읽을 수 없었습니다. 그러나 Outlook 기본값이 변경되지 않았다면 이 단계에서 많은 문제가 발생하지는 않습니다.
공개 인증서와 연결된 개인 키를 사용할 수 있다면 메시지를 받은 의도된 수신자가 해당 메시지를 열 수 있어야 합니다. 이때 사용자는 구현 방식에 따라 개인 키의 보유 사실을 입증하기 위한 추가 토큰을 다시 제공해야 할 수 있습니다. 이와 유사한 부트스트랩 프로세스를 완료한 다른 사용자들도 비슷한 서명 및 암호화 통신에 참여할 수 있습니다. 컴퓨터 분실 등으로 인해 개인 키를 변경한 사용자는 인증서를 다시 요청하고 암호화된 메일 교환을 기다리는 다른 사람에게 서명된 메시지나 인증서 파일을 재배포해야 합니다.

결론
서로 다른 두 디렉터리 또는 조직 사이의 서명 및 암호화된 S/MIME 작업은 대개 여기서 설명한 것보다 복잡하지 않습니다. 서명은 메시지에 유효성을 더하는 것이므로 제대로 사용하면 매우 간단합니다. 민감한 정보의 경우, 암호화된 메시지를 사용하여 전송 중인 데이터의 비밀을 한 단계 더 강하게 유지할 수 있습니다. 두 방법을 함께 사용하면 원본의 유효성과 데이터 비밀을 모두 유지할 수 있습니다. 여기서 설명한 프로세스에 따르면 대부분의 사용자가 어렵지 않게 이러한 이점을 활용할 수 있을 것입니다.

Matt Clapham은 CISSP이며 Microsoft IT의 보안 엔지니어입니다. 주로 LOB 응용 프로그램에 대한 보안 리뷰를 작성하고 기술, 게임, 컴퓨터 음악, 보안 등에 대한 해박한 지식을 가지고 있습니다. Puget Sound IT 보안 커뮤니티에서 의견을 발표하기도 합니다. 문의 사항이 있으면 matt.clapham@microsoft.com으로 연락하십시오.
Blake Hutchinson은 Microsoft의 BOSG(Business Online Services Group)에서 지원 분석가로 활약하고 있습니다. BOSG의 기업 고객을 위한 자체 제작 LOB 도구의 운영 지원 및 프로젝트 검토 업무를 담당하며 취미는 사진, 스키 및 컴퓨터 게임입니다. 문의 사항이 있으면 blakeh@microsoft.com으로 연락하십시오.


From the Editor 대논쟁
Joshua Hoffman

전 논쟁이 좋습니다. 다양한 의견과 강력한 개성이 의식 없는 충돌을 불러오는 진부한 의견 차이를 말하는 것이 아닙니다. 이런 건 시간 낭비일 뿐이죠. 하지만 진정한 논쟁은 서로 다른 시각을 가진 현명한 사람들이 함께 모여 심사 숙고해야 할 자신들의 주장을 열성적으로 표현하는 것이며, 강력한 힘을 발휘합니다. 계몽 운동을 생각해 보십시오. 소크라테스를 생각해 보십시오.
이번 달에는 IT 업계에서 실제 대논쟁의 대상 중 하나인 은둔 보안 방식을 소개합니다. 여기서는 개념을 설명하겠지만, 은둔 보안 방식이라는 세 단어를 다 읽을 쯤에는 여러분 중 대부분이 이미 이 주제에 대한 자신의 의견을 표현했을 것이며 아마도 강하게 주장할 것입니다. 또한 여러분 중 대부분이 "은둔 보안 방식은 완전히 무용지물이다" 또는 "이것 역시 보안이라면 조금은 도움이 된다"라는 두 가지 의견 중 하나로 자신의 의사를 분명히 표현할 것이라고 확신합니다.
이번 달에는 이 논쟁의 양측을 대표하는 유명한 보안 전문가 Jesper Johansson과 Roger Grimes를 함께 모셨습니다. 또한 이 분야의 권위자이신 Aaron Margosis와 Steve Riley 두 분의 각 측에 대한 특별 지지 논평도 포함시켰습니다. 저는 우리가 출간하는 모든 내용에 특별한 자부심을 느끼고 있지만, 이렇게 흡족한 기사는 정말 오래간만입니다. 이 대논쟁에서 여러분이 지지하는 쪽이 어는 쪽이든 상관없이 열린 마음으로 이 기사를 읽어주시기를 바랍니다. 반드시 즐거운 시간이 되실 것입니다.
연례 보안 특집호인 이번 호에도 다양한 내용이 수록되어 있습니다. 지난 해 특집호에서 다루었던 주제 중 몇 가지를 다시 다루었습니다. 지난 해 논의되었던 가장 인기 있던 주제 중 하나는, 객원 편집자인 Michael Murgolo의 Script Elevation Power Toy로, Windows Vista의 사용자 계정 제어 기능과 함께 권한이 상승된 컨텍스트에서 VBScript 또는 Windows PowerShell 스크립트 실행을 지원하는 유틸리티입니다. Michael은 이와 관련하여 많은 호의적인 평가를 받았으며, 그래서 올해도 자신의 원래 코드를 확장한 일련의 새로운 유틸리티를 가지고 돌아왔습니다. 이 유용한 도구를 한 번 사용해 보시기 바랍니다.
Byron Hynes도 지난 해 Windows Vista의 BitLocker 드라이브 암호화를 소개하며 우리와 함께 했었습니다. 이번 호에서도 Windows Vista SP1 및 Windows Server 2008 릴리스에서 BitLocker가 어떻게 변경되었는지 살펴보는 역할을 다시 한 번 맡아 주었습니다. 또한, 소프트웨어 제한 정책, Windows Vista 방화벽 관리, S/MIME 문제 해결, 새로운 Inside SharePoint 칼럼 2판, 지속 가능한 컴퓨팅을 개발하기 위한 비즈니스 아이디어, 기타 등등 그 밖에도 많은 유용한 기사가 포함되어 있습니다. 자, 그러면 흥미롭게 읽으시기 바랍니다. —Joshua Hoffman

도움을 주신 Microsoft 기술 전문가: Troy Funk, Aaron Margosis, Michael Murgolo, Steve Peschka, Steve Riley, Mark Russinovich, Jon Schwartz 및 Jim Truher


Letters 독자의 목소리

Windows 백업
Windows Server® 2008 관련 기사(TechNet Magazine, 2008년 3월호, technet.microsoft.com/magazine/cc268370)를 읽고 매우 들뜬 마음으로 출시 이벤트에 참여하여 홈 네트워크용 사본을 받았습니다. 설치에는 아무런 문제가 없었습니다. 하지만 백업에서 문제가 발생했습니다.
NT Backup이 제거되었고, OS에서는 테이프 드라이브를 지원하지만 새 Windows Server Backup에서는 지원하지 않습니다. 저는 Active Directory® 및 Exchange Server 2007 등 개인 데이터를 테이프 드라이브로 백업합니다.
이 설치에 Microsoft® Data Protection Manager(DPM)를 사용할 필요가 없을 수도 있겠지만 웹에 나온 힌트에 따라 DPM를 다운로드해 보았습니다. 하지만 DPM이 Windows Server 2008에는 설치되지 않으며, 수동 설치 지침대로 해 봤지만 소용 없었습니다. 백업을 위해 간단히 설치할 수 있는 것이 있습니까?
—Ravi S.

Windows Server 2008의 새 솔루션은 디스크 기반 저장소용으로 최적화되어 있으므로 사실상 DPM이 테이프 백업용 솔루션인 셈입니다. 몇 개월 내에 DPM에서 공식적으로 Windows Server 2008을 지원하게 될 것입니다.
—Karandeep Anand, 선임 프로그램 관리자, Microsoft

설문 조사 워크플로
2008년 2월 기사인 "강력한 설문 조사 인프라 구축"(technet.microsoft.com/magazine/cc194407)의 "WSS만을 이용한 작업" 섹션에 "또한 설문 조사에 워크플로를 할당할 수도 있습니다"라는 문장이 있습니다.
Windows® SharePoint® Services 3.0(WSS) 및 Microsoft Office SharePoint Server 2007(MOSS)에서 설문 조사 응답 내용과 연결된 워크플로를 지원하지 않는 것으로 알고 있습니다. 하지만 SharePoint Designer에서는 이러한 연결을 허용하고 있다고 하여, 워크플로와 설문 조사 응답 내용을 연결하려고 시도해 보았으나 워크플로에서 항상 "시작하지 못함" 오류가 발생했습니다. 설문 조사 응답 내용과 연결된 워크플로가 지원되지 않음을 명확하게 설명한 기술 자료 문서(support.microsoft.com/kb/926370)가 있습니다.
이벤트 수신기를 설문 조사에 연결한 다음 다른 프로세스를 시작할 수 있지만 이것이 실제로 SharePoint에서 일반적으로 말하는 워크플로는 아니라고 이해하고 있습니다. 그럼 이 문장이 잘못된 것인가요? 아니면 제가 잘못 이해한 부분이 있나요?
—Matt B.

지적하신 문장이 있는 단락에서는 WSS가 단계별 설문 조사 작성 프로세스를 진행하기 위해 마법사를 어떻게 제공하는지에 대해 설명하고 있습니다. 또한 다양한 옵션(분기 논리, 공개/비공개 질문 등)에 대해서도 설명하고 있습니다.
마법사가 실제로 제공하는 옵션 중 하나는 워크플로 할당입니다. 따라서 "설문 조사에 워크플로를 할당할 수 있습니다"라는 표현은 절대로 잘못된 표현이 아닙니다. 워크플로를 할당할 수 있지만, 귀하께서 지적하셨듯이, 어떤 이유로 해당 옵션이 포함되어 있기는 하지만 설문 조사의 워크플로는 작동하지 않습니다. 그 이유를 설명해 드리겠습니다.
워크플로를 설문 조사에 연결한 후 시작하려고 하면 "시작하지 못함" 오류가 발생합니다. 이 작업에 대한 로그는 다음과 같습니다.
RunWorkflow: System.ArgumentException: Invalid field name.
{<<< GUID>>>} at ...
이 GUID가 워크플로 인스턴스를 나타냅니다. 이는 "설문 조사" 목록 유형에서 워크플로 특성을 지원하지 않는다는 점을 제외하고는 올바른 워크플로가 트리거되는지 확인하는 좋은 방법인 것 같습니다. 단지 코딩되어 있지 않은 것입니다. 그래서 워크플로가 MakeActivation 메서드를 활성화하여 다음과 같은 작업을 할 때
internal static void MakeActivation(SPWorkflow workflow, SPWorkflowEvent e)
{e.EventData = new object[ ] { workflow.InstanceId, new SPWorkflowActivation
Properties(workflow, e.RunAsUserId, associationData, initiationData) };
...
}
다음과 같이 SPWorkflowActivationProperties를 호출합니다.
internal SPWorkflowActivationProperties(SPWorkflow workflow,
int runAsUserId, string associationData, string initiationData)
{
...
this.m_itemGuid = new Guid((string)
this.Item[SPBuiltInFieldId.GUID]);
...
}
따라서 설문 조사의 특성으로 GUID 문자열을 필요로 하고(기본 제공된다고 가정함) 설문 조사에서 워크플로 GUID에 대한 특성이 없는 경우에는 결코 작동하지 않습니다.
해결 방법이 있으므로 생각하신 대로 해도 별 문제는 없습니다. 해결 방법은 워크플로를 트리거하는 사용자 지정 목록을 작성하고 ItemEventReceiver를 사용하여 이벤트 수신기를 설문 조사에 연결하는 것입니다. 이 이벤트 수신기는 사용자 지정 목록에 항목을 만드는데, 이 항목이 워크플로를 트리거합니다. 하지만 귀하의 생각이 맞습니다. 실제로는 같다고 볼 수 없습니다. 간단히 말해서, 잘 지적해 주셨으며, 실제로는 작동하지 않습니다.
—Pav Cherny, 칼럼니스트, Inside SharePoint, TechNet Magazine


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

네트워크를 통한 공지
NetSupport Notify
www.netsupportnotify.com
PC 기반의 작업 환경은 사무실 내의 어디에서나 일반화되어 있습니다. 대부분의 사용자가 업무 시간 동안 네트워크에 연결된 화면을 마주하고 있으므로 관리하기에 유리합니다. 회사 네트워크는 공유 리소스, 응용 프로그램 및 인터넷 전송에 이용될 뿐 아니라 중요한 메시지를 사용자에게 전달하기 위한 조직 전략의 일환으로 사용되기도 합니다. LAN 및 WAN(Wide Area Network)에서 사용자에게 메시지를 전달할 때 사용하는 도구로 NetSupport Limited의 NetSupport Notify가 있습니다.
이 간단한 응용 프로그램 서버를 사용하면 빠르고 안정적인 브로드캐스트 메시징 지원이 가능합니다. 예를 들어 갑작스러운 공유 리소스 서비스 중단을 손쉽게 경고하거나, 보안 경고가 실수로 발령되었음을 알리거나, 건물의 비상 사태를 직원들에게 알릴 수 있습니다.
현재 사용되는 간단한 브로드캐스트 메시징 도구 중에는 설치된 LAN에서만 작동하는 것도 있습니다. 그러나 에이전트를 기반으로 하는 NetSupport Notify는 알림 게이트웨이 구성 요소를 통해 네트워크 토폴로지를 쉽게 통과하여 Windows® 클라이언트와 Mac 클라이언트 모두에 연결할 수 있습니다. 이때 무선 연결을 이용한 직접 연결인지 가상 사설망을 통한 연결인지 여부는 상관이 없습니다.
알림 서비스는 Windows 서비스로 실행되며, 사용자는 이 서비스와 동일한 시스템 또는 다른 시스템에 설치된 관리 알림 콘솔을 통해 서비스에 연결합니다. 서비스에서 보내는 알림의 심각도는 메시지, 경고, 중요의 세 가지로 나뉩니다. 메시지가 수신되면 클라이언트는 이벤트 로그 항목을 생성하고 해당 서버에 메시지를 수신했다고 알립니다. 그 밖의 메시지 옵션으로는 창을 표시할 때 경고음 울림, 항상 알림 표시, 메시지가 자동으로 닫히는 제한 시간 설정 등이 있습니다.
특정한 알림 그룹에만 메시지를 보낼 수도 있습니다. 알림 콘솔은 여러 알림 서버에 연결할 수 있으므로 콘솔 하나를 메시지 브로드캐스트 센터로 사용할 수 있습니다.
NetSupport Notify에는 이러한 서버와 콘솔 외에도 최종 사용자의 데스크톱으로 가지 않고도 에이전트를 원격으로 배포할 수 있는 배포 도구가 있습니다. IP 주소 범위를 사용하거나 Windows 네트워킹 도메인 및 작업 그룹 검색을 통해 대상 시스템을 지정할 수 있습니다.
또한 배포 콘솔에는 설치된 에이전트의 버전은 물론 DNS 이름, MAC 주소, IP 주소, 플랫폼, 원격 시스템에 대한 액세스 권한이 있는지 여부 등의 필수 정보가 표시되므로 네트워크를 신속하게 파악할 수 있습니다. Active Directory®를 사용하는 경우 구성 및 배포를 그룹 정책으로 관리할 수 있습니다.
에이전트와 콘솔은 허용되지 않은 브로드캐스트(예: "4시에 내 방으로 모이세요!")를 차단하기 위해 WMI(Windows Management Instrumentation) 키 문자열과 비슷한 보안 코드를 사용합니다. 또한 경고 보내기 기능을 Active Directory 정책으로 제어할 수도 있습니다.
가격: 75개 사용자 라이선스(180달러~)
NetSupport Notify를 사용한 직원 공지
NetSupport Notify를 사용한 직원 공지 (더 크게 보려면 이미지를 클릭하십시오.)

네트워크 모니터링
NetOptics: Teeny Tap
www.netoptics.com
수동적 네트워크 탭을 우수한 모니터링 응용 프로그램과 함께 사용할 경우 취약한 네트워크 문제를 해결하고, 잘못 작동하는 응용 프로그램을 수정하고, 인프라에 대한 잠재적 위협을 완화하는 데 꼭 필요한 도구가 될 수 있습니다. NetOptics의 완벽한 휴대용 Teeny Tap은 10/100 네트워크용으로 출시되어 눈길을 끌었던 멋진 탭입니다.
3.125x1.5인치 크기의 이 "소형" 장치는 계층 1 이상에서 전이중 트래픽 모니터링이 가능하므로 10/100 네트워크에서 손쉽게 트래픽을 추출 검사하거나 지속적으로 모니터링할 수 있습니다. 이 장치는 RJ45 모니터링 포트 2개를 사용하여 전이중 모니터링을 수행합니다. 즉, 두 개의 네트워크 포트를 네트워크 모니터, 프로토콜 분석기, IDS/IPS 또는 기타 검색 장치에 연결하여 네트워크 포트의 양쪽에서 흐르는 트래픽을 자세히 볼 수 있습니다.
Teeny Tap에는 IP 주소가 필요 없습니다. 사용자를 네트워크에서 격리시켜 보이지 않게 함으로써 사용자의 존재 사실이 악용될 빌미를 주지 않고 네트워크 조작을 막을 수 있습니다. 한편 탭에 대한 전원 공급이 중단되어도 탭을 통한 트래픽 흐름에는 영향이 없도록 하는 Zero Delay 기능이 있으므로 지연 또는 패킷 손실이 발생하지 않습니다.
탭 전원 공급에는 USB 또는 포함된 전원 공급 장치를 사용하거나 둘 다 사용하여 중복성을 꾀할 수 있습니다. 소형 장치 치고는 놀랄 만한 기능입니다. 또한 Teeny Tap은 네트워크 카메라나 IP 전화기 등의 PoE(Power over Ethernet) 기반 서비스와 호환됩니다. 따라서 PoE 서비스의 트래픽도 모니터링하여 통신 보안을 보장할 수 있습니다.
Teeny Tap 키트는 탭, 범용 전원 공급 장치, 크로스오버 RJ45 케이블 2개, 직선 RJ45 케이블 2개 및 운반용 케이스로 구성됩니다. 이보다 높은 사양이 필요한 환경이라면 NetOptics의 다른 네트워크 탭 제품을 찾아보십시오. NetOptics 제품군에는 소규모 사무실 네트워크에서 대기업 환경에 이르기까지 10MB ~ 10GB 범위의 구리 및 광섬유 네트워크를 모두 아우르는 다양한 제품이 포함됩니다.
가격: $325(직판가)
Teeny Tap을 사용한 네트워크 모니터링
Teeny Tap을 사용한 네트워크 모니터링 (더 크게 보려면 이미지를 클릭하십시오.)

컴퓨터 최적화
DTweak Pro
www.daoisoft.com
IT 전문가나 보통의 기술 애호가들은 시스템을 조정하여 일상적인 활동에 맞게 최대한의 성능을 끌어내고 최대한 사용자 지정된 환경을 구축할 수 있기를 바랍니다. Windows Vista®를 실행하는 컴퓨터에서 사용자 환경을 최적화하고 사용자 지정하는 도구가 많이 출시되어 있습니다. 그 중 저렴한 제품이 Daoisoft의 DTweak Pro입니다. Windows® XP 및 Windows Server® 2003용 버전도 있습니다.
이 응용 프로그램은 다양한 Windows Vista용 도구와 사용자 지정에 대한 여러 가지 빠른 액세스 보기를 제공합니다. 예를 들어 "Daily Tools" 섹션에서는 레지스트리 클리너, 파일 정리 유틸리티, 레지스트리 및 디스크 조각 모음 도구, 하드 디스크 성능 모니터 등을 실행할 수 있습니다.
DTweak를 사용하면 시작 항목을 손쉽게 확인하여 조정하고, CPU 정보(CPU ID, 버스 속도, 클럭 속도 등) 및 컴퓨터 정보(공급업체, 부팅 상태, 메모리 구성, 시스템 종류 등)를 수집할 수 있습니다. 충돌하는 프로그램과 중단된 서비스를 종료할 때까지의 대기 시간 및 I/O 캐시 메모리를 조정할 수도 있습니다.
"GUI Tools" 섹션에는 diskpart 및 시스템 복원과 같은 Windows Vista의 기본 제공 도구에 대한 링크와 finger, ping, netstat, nslookup 등 간편한 네트워크 도구에 대한 링크가 있습니다. 그 밖의 네트워크 조정 기능으로는 최대 전송 단위 조정, TCP/IP TTL 및 DNS 시간 제한 설정 조정, QoS 패킷 스케줄러 서비스를 이용한 대역폭 제한 등이 있습니다.
가격: $29.95(직접 다운로드)
DTweak를 이용한 시스템 조정 및 최적화
DTweak를 이용한 시스템 조정 및 최적화 (더 크게 보려면 이미지를 클릭하십시오.)

서평
Microsoft Exchange Server 2007 관리자 도우미
www.microsoft.com/mspress
전자 메일이 다루기 힘든 야수가 될 수도 있습니다. 예를 들어, 사실 사용자는 수신되는 메시지의 흐름을 제어하지 못합니다. SMTP 서버를 일시 중단하여 수신되는 전자 메일을 지연시켜서 큐를 줄이려고 하는 경우 보낸 사람에게 "메시지를 배달할 수 없습니다"라는 알림이 전달될 위험이 있습니다. 이것은 배관 시스템과 매우 유사합니다. 즉, 물이 항상 흐르고 있으므로 특정 구간의 밸브를 아래로 구부리면 다른 구간의 파이프가 터질 위험이 있습니다. 사업 전반의 원활한 운영을 위해서는 제대로 계획 및 조정된 유연한 전자 메일 인프라가 필요합니다.
Microsoft Exchange Server® 2007은 방대한 양의 메일을 처리하도록 설계되었으며 현재는 물론 미래에도 사용자 조직의 필요에 맞게 인프라를 조정할 수 있습니다. 그러나 Exchange 2007을 배포하기 위해서는 선택해야 할 옵션과 내려야 할 결정이 너무 많습니다. 그리고 Exchange에는 전자 메일 외에도 수많은 기능이 있으므로 일은 훨씬 더 복잡해집니다.
아키텍처 및 관리에 대해 올바른 결정을 내리려면 훌륭한 참조 자료가 필요합니다. Microsoft Exchange Server 2007 관리자 도우미는 빼놓을 수 없는 참조 자료입니다.
이 책에서는 계획 및 배포에서 유지 관리와 보안에 이르기까지 제품 배포의 수명 주기를 설명합니다. 또한 Exchange 2007에 사용할 수 있는 다양한 클라이언트 및 클라이언트 연결 옵션에 대해서도 다룹니다. 먼저 여러 버전 간의 차이점을 간단히 알아본 다음 Exchange 2007의 새로운 기능을 소개합니다. 이와 함께 Exchange Server 2007의 다양한 아키텍처 구성 요소에 대한 전반적인 개요를 제공합니다.
이어지는 섹션에서는 Exchange 배포 계획 방법을 설명하고 필요한 저장소 용량, 서버 및 프로세서 요구 사항을 계산하고 내결함성을 추가하는 방법을 보여 줍니다. 그런 다음 설치 및 배포의 실제 사례를 토대로 Exchange 배포를 위한 서버 준비 방법과 다양한 소프트웨어 구성 요소의 설치 방법을 제시합니다. Exchange 서비스를 클러스터링하여 보다 높은 수준의 가용성을 확보하는 방법도 자세히 소개되어 있습니다.
설명서의 그 다음 부분에서는 Exchange MMC 패널 및 Windows PowerShell™ 기반의 새로운 Exchange 관리 셸 등 사용자가 자유롭게 사용할 수 있는 다양한 관리 도구에 대해 다룹니다. 또한 사서함을 만드는 방법부터 저장소 그룹과 백업 및 복원 작업을 만드는 방법까지 모든 내용을 설명합니다. 이와 함께 관리 GUI 및 Windows PowerShell의 명령줄을 통해 이 모든 작업을 수행하는 방법도 이 섹션에 수록되어 있습니다.
Exchange 2007에는 한 시스템에서 데이터 및 음성 통신을 모두 관리할 수 있는 다양한 통합 메시징 기능이 있으며, 음성 메시징, 팩스 메시징, 받은 편지함 음성 액세스 등을 설정하고 사용하는 방법도 이 책에 수록되어 있습니다.
그리고 이 책에서는 유지 관리에 대해 보다 자세히 설명하면서 기본적인 문제 해결 기법과 도구, 손상 및 재해 복구, 성능 조정 등을 다룹니다. 보안은 모든 통합 메시징 시스템에서 가장 중요한 문제이므로 이 설명서에서는 배포 보안에 대해 철저히 탐구합니다. 보안 정책 및 지침, 바이러스 백신 및 스팸 방지 기능, 공용 키 인프라 등에 대해 소개합니다.
마지막으로 Exchange 클라이언트에 대해 알아보고, 조직에서 사용하는 기타 POP3 및 IMAP(Internet Message Access Protocol) 클라이언트를 지원하는 방법을 알려 줍니다. 결론적으로 이 책은 Exchange Server 2007 서버 통합 메시징 플랫폼을 계획 중이거나, 유지 관리하거나, 그저 관심이 있는 사람을 비롯하여 모든 관리자를 위해 작성된 훌륭한 일반 참조서입니다.
가격: $49.99(정가)
(더 크게 보려면 이미지를 클릭하십시오.)

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


SQL Q&A I/O 오류, 데이터베이스 미러링 및 기타
Paul S. Randal

Q. 제가 관리하는 데이터베이스에서 정기적으로 일관성 확인을 실행하기로 하고 사용자 쿼리에서 발생하는 I/O 오류를 잡아내기 위해 몇 가지 SQL 에이전트 경고도 추가했습니다. 그런데 손상 문제가 발생한 데이터베이스가 없어서 확인 및 경고를 위해 구현한 논리가 제대로 작동하고 있는지 알 수가 없습니다. 제가 설정한 대로 올바르게 작동하는지 확인하기 위해 테스트 데이터베이스에서 손상을 일으킬 방법이 있습니까? 또한 I/O 오류를 감지하려면 무엇을 더 해야 하는지도 알려 주십시오.
A. SQL Server® 2000에서 테스트를 위해 손상된 데이터베이스를 만들 때는 주로 테스트 데이터베이스의 sysindexes 테이블에서 한 행을 수동으로 삭제하는 방법을 썼습니다. 그러나 SQL Server 2005에서는 이 방법으로 시스템 테이블을 손상시키기가 매우 어렵습니다. 테스트 데이터베이스를 직접 손상시키는 가장 좋은 방법은 데이터베이스를 종료한 상태에서 16진 편집기를 사용하여 데이터 파일을 수정하는 것입니다. 방법은 다음과 같습니다.
  • 데이터 파일이 잠기지 않도록 데이터베이스를 종료합니다. (데이터베이스가 분리되지 않도록 주의하십시오. 잘못된 페이지를 손상시키면 다시 연결하지 못하게 될 수 있습니다.)
  • 파일에 대해 100페이지 이상의 오프셋(819200바이트 이상)을 선택하되 8192바이트 경계(페이지 경계)에 맞춥니다. 그러면 치명적인 메타데이터 페이지 및 할당 비트맵을 피하여 데이터베이스를 시작하고 DBCC CHECKDB를 실행할 수 있습니다.
  • 선택한 오프셋에서 몇 바이트의 0을 파일에 기록합니다. 이렇게 하면 거의 확실히 페이지 헤더 손상 오류가 일어납니다.
한편, 손상된 테스트 데이터베이스를 얻는 가장 빠른 방법은 다른 사람이 이미 만들어 둔 손상된 데이터베이스를 사용하는 것입니다. 제 블로그(go.microsoft.com/fwlink/?LinkId=115151)에도 손상된 SQL Server 2000 및 SQL Server 2005 데이터베이스 샘플(설명 포함)이 있습니다.
I/O 오류를 감지하기 위해 필요한 조치를 묻는 두 번째 질문에 대한 답변은 페이지 체크섬을 사용하시라는 것입니다. 이 기능은 I/O 하위 시스템에서 발생한 오류로부터 전체 데이터베이스 페이지를 보호하기 위한 수단으로 SQL Server 2005에 도입되었습니다.
기본적으로, 디스크에 페이지를 기록할 때 SQL Server에서 마지막으로 이루어지는 작업은 전체 8KB 페이지에 대한 체크섬을 계산하고 그 체크섬을 해당 페이지에 스탬프로 찍는 것입니다. 디스크에서 페이지를 읽을 때 페이지 체크섬이 있으면 체크섬을 다시 계산하여 해당 페이지에 저장된 것과 비교합니다. 양쪽 값이 일치하지 않으면 SQL Server 외부의 원인으로 페이지가 손상된 것이며 824 오류가 발생합니다. 이 오류는 해당 페이지를 읽도록 한 연결에 표시되고 SQL Server 오류 로그 및 Windows® 응용 프로그램 이벤트 로그에도 기록됩니다.
SQL Server 2005 및 SQL Server 2008에서 만들어진 모든 데이터베이스는 기본적으로 페이지 체크섬을 사용합니다. 그러나 이전 버전의 SQL Server에서 업그레이드한 데이터베이스의 경우에는 페이지 체크섬을 수동으로 설정해야 합니다. 다음 코드로 페이지 체크섬을 사용하도록 설정할 수 있습니다.
ALTER DATABASE mydb SET PAGE_VERIFY CHECKSUM;

팁: 기본 SQL Server 포트 변경
기본적으로 SQL Server 인스턴스용으로 구성된 포트는 1433입니다. 한 인스턴스에서 이 포트를 사용하고 있을 때는 다른 인스턴스에서 사용할 수 없습니다. 따라서 tcp를 사용하여 net에서 수신하는 두 번째(명명된) 인스턴스를 설치하려면 다른 포트가 필요합니다. 또한 관리자가 모호화를 위해 포트를 변경하고자 하는 경우도 있습니다(이러한 모호화 방법은 부수적이며 포트 검색기로 쉽게 감지됨). 물론 이 경우에는 클라이언트가 다른 포트를 사용하도록 구성해야 합니다. 주로 사용하는 방법은 다음 세 가지입니다.
첫째, 만일 관리자가 인스턴스의 포트를 5555로 변경했다면 MyServername,5555 구문을 사용하여 연결하려는 컴퓨터 이름 안에 해당 인스턴스의 포트 번호를 지정하면 됩니다. 포트가 다시 변경되면 클라이언트에서도 connectionStrings를 다시 변경해야 합니다.
두 번째 방법은 클라이언트에 구성된 SQL Server 별칭을 사용하는 것입니다. 별칭 이름을 지정하는 동시에 서버 이름, 포트 이름 및 프로토콜도 지정해야 합니다. 이렇게 구성하면 이 별칭을 서버 이름처럼 사용하여 데이터베이스 인스턴스에 연결할 수 있습니다. 이 방법의 장점은 설정이 레지스트리에 저장되므로 서버 구성의 변경을 도메인 관리자가 배포할 수 있다는 것입니다.
사용자가 명명된 인스턴스의 이름만 아는 상태에서 MachineName\InstanceName을 사용하여 connectionString 내에 그 이름을 지정하는 세 번째 방법은 SQL Server Browser 서비스를 사용하는 것입니다. 이 서비스는 실행 서비스의 일환으로 SQL Server 2000에서 이미 구현되었습니다. 그러나 SQL Server 2005에는 SQL Server Browser 서비스가 별도의 서비스로 내장되어 있습니다. 이 서비스는 시스템에서 인스턴스를 검색하는 것 외에도 요청된 인스턴스에 대한 적합한 포트 번호로 포트 1434에서 수신 UDP(User Datagram Protocol) 요청에 응답하여 클라이언트 리디렉션을 가능하게 하고 투명한 연결을 지원합니다.
—Jens K. Suessmeyer, Microsoft 데이터베이스 컨설턴트

Q. 데이터베이스에서 조각화를 모두 없애기 위해, SQL Server 2005 Enterprise Edition SP2에서 실행되는 프로덕션 데이터베이스의 모든 인덱스를 다시 구축하는 야간 유지 관리 계획을 설정했습니다. 그랬더니 데이터베이스가 너무 커지고 디스크 공간이 부족해져서 잉여 공간을 모두 축소하는 단계를 추가했습니다. 그러자 이제는 재구축 단계가 작동하지 않는 것 같습니다. 왜 그럴까요?
A. 유지 관리 계획을 수립할 때 자주 발생하는 문제입니다. 축소-증가-축소-증가의 덫에 빠지셨습니다.
인덱스를 재구축할 때는 기존 인덱스를 삭제하기 전에 인덱스 복사본을 새로 만듭니다. 이를 위해 데이터베이스 파일에 여분의 공간이 있어야 합니다. 필요한 공간의 크기는 대개 현재 인덱스에 사용되는 공간과 동일합니다. SQL Server 2000에서는 인덱스 행을 정렬하기 위한 추가 공간(인덱스 크기의 약 20%)도 필요했으나 SQL Server 2005부터는 단순 인덱스 재구축의 경우 필요가 없어졌습니다.
관리자는 인덱스 재구축 중 만들어진 추가 공간을 제거하기 위해 유지 관리 계획에서 재구축 단계 다음에 축소 작업을 추가하기도 합니다. 하지만 이러한 축소가 알고리즘의 특성상 인덱스 조각화를 일으킨다는 사실은 잘 알려져 있지 않습니다. 즉, 새로 재구축 및 조각 모음한 인덱스가 즉시 다시 조각으로 나뉘어 재구축 효과가 전혀 나타나지 않게 됩니다.
다음 번 인덱스 재구축을 수행할 때 데이터베이스 파일이 다시 커진다면 데이터베이스에 추가 공간을 남겨두고 축소 작업은 전적으로 피하는 것이 좋습니다. (한편 데이터베이스 파일의 증가-축소가 반복되면 OS 수준의 파일 조각화가 일어나 인덱스 조각화와 마찬가지로 성능이 저하될 수 있습니다.)
마지막으로 고려해야 할 한 가지는 인덱스 재구축 빈도를 줄이는 것입니다. 제가 SQL Server 2000용으로 작성했던 구형 DBCC INDEXDEFRAG나 SQL Server 2005 및 SQL Server 2008의 새로운 ALTER INDEX REORGANIZE 구문 등 다른 방법을 시도해 볼 수도 있습니다.
인덱스 조각화를 설명하고 조각 제거 시기에 대한 지침을 제시하는 유용한 백서가 있습니다(go.microsoft.com/fwlink/?LinkId=115154). SQL Server 2000용으로 작성된 백서이지만 개념은 같습니다.

Q. 저희 조직에서 재해 복구 전략을 평가하고 있는데, 데이터 미러링이 현재 상황에 가장 적합한 방법이라고 생각됩니다. 이전에 서버 통합 프로젝트를 실시한 결과 보호하려는 서버에 관련 없는 데이터베이스가 많이 생겨났으며, 이들 전부에 대해 데이터베이스 미러링을 사용하고자 합니다. 성능 저하 없이 미러링할 수 있는 데이터베이스의 수는 최대 몇 개나 되는지 알고 싶습니다.
A. 이 질문에 대한 답변은 제가 자주 쓰는 말로 해야겠군요. 그때 그때 다릅니다. 안내서에는 미러링하는 데이터베이스가 인스턴스당 10개를 넘지 않도록 하라고 되어 있지만, 여기서 10개는 대부분의 사용자에게 해당되는 최대값을 추정한 수입니다. 여러분은 하드웨어 상황을 토대로 다음 요소를 고려해야 합니다.
  • 주 인스턴스와 미러 인스턴스의 메모리 용량은 얼마입니까? (동일한 것이 이상적입니다.)
  • 주 인스턴스와 미러 인스턴스의 처리 성능은 얼마입니까? (이것도 동일해야 합니다.)
  • 미러 인스턴스의 I/O 하위 시스템 대역폭은 얼마나 됩니까? (주 인스턴스와 동일해야 합니다.)
  • 각 데이터베이스에서 작업 부하로 생성되는 트랜잭션 로그는 얼마나 됩니까?
  • 주 인스턴스와 미러 인스턴스 간에 사용할 수 있는 네트워크 대역폭은 얼마나 됩니까?
마지막 두 요소가 가장 중요합니다. 두 인스턴스 간에 사용할 수 있는 네트워크 대역폭이 미러링되는 모든 데이터베이스에서 초당 생성되는 트랜잭션 로그를 처리하기에 부족하면 주 데이터베이스의 성능이 저하됩니다. SQL Server 2008에서는 로그 스트림 압축으로 이 부담을 어느 정도 줄일 수 있습니다.
다음으로 중요한 문제는 미러링에 필요한 메모리 및 스레드 요구 사항입니다. 미러링된 각 데이터베이스는 스레드 하나와 약간의 메모리를 사용합니다. 저성능의 서버에 미러링되는 데이터베이스가 많고 여기에 통상적인 작업 부하가 더해지면 서버에 너무 큰 부담이 될 수 있습니다.
또한 데이터베이스 미러링의 실행 방법도 고려해야 합니다. 동기 모드에서는 모든 트랜잭션 로그 레코드가 미러링된 데이터베이스의 트랜잭션 로그에 복사될 때까지 주 데이터베이스에서 트랜잭션을 커밋할 수 없습니다. 따라서 네트워크 과부하로 인한 지연 때문에 주 데이터베이스에서 작업 부하 성능 문제가 발생할 수 있습니다.
비동기 모드에서는 주 데이터베이스에서 기다리지 않고 트랜잭션을 커밋할 수 있지만, 네트워크 지연으로 인해 미러 데이터베이스로 전송 대기 중인 트랜잭션 로그의 양이 증가할 수 있습니다. 이 경우 트랜잭션 로그 크기 문제가 발생할 수 있습니다. 더욱이, 전송되지 않은 트랜잭션 로그는 오류 발생 시 손실되므로 전송되지 않은 트랜잭션 로그가 많아질수록 복구 상황에서 데이터 손실 가능성이 높아집니다.
상황에 따라 매우 다양한 시나리오가 가능하며, 실제 프로덕션 환경에서 흥미로운 상황을 여러 번 목격했습니다. 일례로, 작업량이 매우 적고 동시에 모두 사용하는 일도 없는 데이터베이스 150개로 구성된 환경이 있었습니다. 이 환경에서는 150개의 데이터베이스가 모두 문제 없이 미러링되었습니다.
반대로, 부하가 매우 큰 데이터베이스 3개뿐이지만 네트워크 연결이 좋지 않은 환경도 있었습니다. 이 환경에서는 네트워크 대역폭 부족으로 작업 부하 성능 저하가 발생하여 하나의 데이터베이스도 제대로 미러링할 수 없었습니다.
성공의 관건은 다름 아닌 로그 생성을 계산하는 것입니다. 미러링하려는 데이터베이스 수를 지원하기에 충분한 네트워크 대역폭이 확보된다면 괜찮습니다. 실전에 들어가기 전에 구성을 테스트하여 데이터베이스 유지 관리 작업을 비롯하여 트랜잭션 로그가 생성될 수 있는 모든 작업이 포함되도록 하십시오.

Paul S. Randal은 SQLskills.com의 관리 이사 겸 SQL Server MVP이며, 1999년부터 2007년까지 Microsoft의 SQL Server 저장소 엔진 팀에서 근무했습니다. DBCC CHECKDB/repair for SQL Server 2005를 작성했고 SQL Server 2008 개발 과정에서 핵심 저장소 엔진 부분을 담당했습니다. 재해 복구, 고가용성 및 데이터베이스 유지 관리 분야의 전문가인 Paul 이사는 각종 컨퍼런스에서도 꾸준히 의견을 발표하고 있습니다. 블로그 주소는 SQLskills.com/blogs/paul입니다.


Utility Spotlight Windows Vista 업그레이드 관리자
Lance Whitney

드디어 Windows Vista®로의 업그레이드 계획을 시작할 시기가 닥쳤습니다. 다른 업그레이드의 경우처럼 몇 가지 사항에 대해 생각해 보아야 합니다. 네트워크 클라이언트가 하드웨어 및 소프트웨어 요구 사항을 충족합니까? 예상되는 호환성 문제는 무엇입니까? 이러한 질문에 대한 대답을 찾을 수 있도록 Microsoft에서는 Windows Vista 업그레이드 관리자를 무료로 제공합니다. 이 유틸리티는 업그레이드가 가능한지 여부를 확인하기 위해 PC에 설치된 모든 하드웨어와 소프트웨어를 검사합니다. 업그레이드가 가능할 경우 Windows Vista 업그레이드 관리자는 권장되는 Windows Vista 최적 버전을 표시하고 업그레이드하기 전에 해결해야 할 문제가 있으면 알려줍니다.
업그레이드 관리자 검사에는 일반적으로 몇 분이 소요됩니다. 검사가 실행되는 동안 각각의 기능을 비교한 다양한 Windows Vista 버전 목록이 표시됩니다. 특정 버전(Ultimate, Home Premium, Business 또는 Home Basic)을 선택하여 간략한 설명과 주요 기능 목록을 볼 수도 있습니다. 검사가 완료된 후에는 보고서 정보 화면에 해당 PC에서 Windows Vista를 사용할 수 있는지 여부와 권장 버전이 표시됩니다. 표시되는 정보는 다음과 같습니다.
시스템 요구 사항 은 CPU, RAM, 비디오 메모리 및 CD/DVD 드라이브 등 하드웨어가 충분한지 알려줍니다. 충분하지 않으면 추가해야 할 메모리의 양 등 PC를 업그레이드하는 데 필요한 요소에 대한 자세한 정보를 표시합니다.
장치 에는 모뎀, 프린터, 스캐너, 사운드 카드, 모니터 및 비디오 카드 등 모든 외부 장치 및 드라이버에 대한 검사 정보가 표시됩니다. 장치가 호환성 테스트를 통과하지 못한 경우 제조업체의 웹 사이트에서 최신 드라이버를 다운로드하라는 등 사용자가 수행해야 할 작업에 대한 설명이 보고서에 표시됩니다. 사용자의 편의를 위해 해당 웹 사이트에 대한 링크가 제공됩니다.
업그레이드 관리자는 알려진 호환성 문제와 이러한 문제를 해결하기 위한 권장 방법을 알려줍니다.
업그레이드 관리자는 알려진 호환성 문제와 이러한 문제를 해결하기 위한 권장 방법을 알려줍니다. (더 크게 보려면 이미지를 클릭하십시오.)
프로그램 에서는 설치된 소프트웨어를 분석합니다. Windows Vista에서 그대로 실행할 수 있는 응용 프로그램에는 어떤 것이 있고 호환성 테스트를 통과하기 위해 업그레이드해야 하거나 호환되지 않는 응용 프로그램에는 어떤 것이 있는지 알려줍니다.
구성 요소 중 하나가 Ultimate와 같은 Windows Vista 고급 버전에서 호환성 테스트를 통과하지 못한 경우 소개 화면으로 돌아가서 Business와 같은 다른 버전을 선택할 수 있습니다. 그런 다음 PC가 해당 버전의 모든 요구 사항을 충족하는지 확인할 수 있습니다.
마지막으로 작업 목록에 PC의 하드웨어 구성이 설명되고 Windows Vista를 설치하기 이전과 이후에 수행해야 할 작업이 항목별로 나열됩니다. 또한 스크린 샷에 표시된 것처럼 이전 화면의 항목이 요약되고 추가 권장 사항이 제공됩니다. 작업 목록을 인쇄하거나 HTML 파일로 저장할 수 있습니다.
업그레이드 관리자는 32비트 Windows Vista 또는 Windows® XP 서비스 팩 2에서 실행되며 Microsoft® .NET Framework 2.0 및 MSXML 6.0이 필요합니다. 이 도구를 다운로드하고 자세히 알아보려면 microsoft.com/windows/products/windowsvista/buyorupgrade/upgradeadvisor.mspx로 이동하십시오.

Lance Whitney는 IT 컨설턴트 겸 강사이자 테크니컬 라이터로, Windows 워크스테이션과 서버를 분석하는 데 많은 시간을 할애하고 있습니다. 원래 저널리스트였던 그는 15년 전 IT 업계에 뛰어들었습니다.


Inside Sharepoint 사이트 관리 분산화
Pav Cherny

이 기사의 코드 다운로드: SharePoint2008_06.exe (1160KB)

Microsoft Windows SharePoint Services(WSS) 3.0 및 Microsoft Office SharePoint Server(MOSS) 2007에서는 IT 조직에서 웹 서버 및 데이터베이스 서버 등의 인프라 구성 요소에 대한 제어를 중앙으로 집중하고 호스트된 사이트 모음 및 사이트에 대한 제어를 분산시킬 수 있도록 하는
유연한 관리 및 보안 모델을 지원합니다. SharePoint® 인프라를 중앙으로 집중시키면 유지 관리 오버헤드 절감, 비즈니스 논리 통합, SharePoint 리소스에 대한 단일 액세스 지점 제공 및 불필요한 기술 투자 감소의 이점을 얻을 수 있습니다.
동시에, 사이트 관리를 분산시키면 개별 부서에서 SharePoint 사이트 모음, 사이트, 문서 라이브러리, 목록, 워크플로 솔루션 및 기타 SharePoint 리소스에 대한 자율적인 제어를 유지할 수 있습니다. 하지만 사이트 관리를 개별 부서로 위임할 경우 IT 부서에 대한 유지 관리 복잡성이 증가한다는 단점도 있습니다. 예를 들어, 환경 내에서 사이트 모음 및 사이트에 액세스할 수 없다면 리소스 사용, 만료된 SharePoint 사이트 및 중앙 집중식 인프라의 오래된 콘텐츠를 어떻게 관리하겠습니까?
이 기사에서는 SharePoint 인프라에 대한 중앙 집중식 관리 제어를 유지하면서 SharePoint 사이트의 관리 제어권을 개별 부서에 위임할 때의 장점과 이러한 위임이 지니는 의미를 비롯하여 WSS 3.0의 보안 모델에 대해 설명합니다. 위임된 사이트 관리의 운영 방식, 사이트, 목록 및 항목 수준에서의 액세스 권한 및 보안 조정을 통해 사용자에게 친숙한 보안 작업 환경을 유지하는 방법, 그리고 웹 팜 관리자가 상승된 SharePoint 권한 없이 필요한 사이트 통계에 액세스할 수 있는 방법에 대해 알아보겠습니다.
테스트 환경에서 이 설명에 따라 실행하려면 technetmagazine.com에서 이 칼럼에 대한 첨부 자료를 다운로드하십시오. 이 자료에는 여러 부서로 이루어진 회사의 프로덕션 환경을 잘 반영한 Windows Server® 2008 기반 웹 팜에 대한 자세한 배포 지침이 포함되어 있습니다.

SharePoint 인프라 및 사이트 모음 관리
단일 서버 배포 또는 웹 팜 배포를 기반으로 SharePoint 인프라를 구축할 수 있습니다. 사실 회사에서는 대체로 두 가지 배포 방식을 모두 사용합니다. 단일 서버 배포는 빠르고 간단한 공동 작업 솔루션을 필요로 하는 개별 부서에 적합합니다. 성능 및 안정성 요구 사항이 최소 수준입니다. 사용자는 흔히 워크스테이션 하드웨어에 배포된 부서 SharePoint 서버를 사용할 수 없는 경우 대체로 이해심이 많은 편입니다. 그 이유는 시스템 유지 관리가 부서 고유의 책임이고 부서 내의 사용자는 결국 IT 관리자가 아니기 때문입니다.
하지만 이러한 분위기는 IT 부서에서 유지 관리되는 서버 리소스의 경우에는 전혀 다릅니다. 성능과 안정성이 중요한 요인이 되므로, 흔히 SLA(서비스 수준 계약)를 준수할 수 있는 고가용성 솔루션을 배포해야 합니다. 부하가 분산된 웹 팜 배포, SQL Server® 장애 조치(failover) 클러스터 및 SAN(저장 영역 네트워크)에 저장된 데이터베이스는 회사의 성능 및 고가용성 요구 사항을 충족시키는 데 도움이 됩니다. 그림 1은 이러한 아키텍처를 표시한 것입니다.
그림 1 SQL Server 장애 조치(failover) 클러스터 및 SAN이 포함된 SharePoint 인프라
그림 1 SQL Server 장애 조치(failover) 클러스터 및 SAN이 포함된 SharePoint 인프라 (더 크게 보려면 이미지를 클릭하십시오.)
그림 1에서 볼 수 있듯이 중앙 집중식 SharePoint 인프라에서 리소스를 관리하려면 여러 유형의 관리자가 함께 작업해야 하며, 이러한 각각의 관리자는 환경을 서로 다른 관점에서 바라봅니다. 예를 들면 인프라의 서버는 사이트 모음 관리자에게는 보이지 않습니다. 사이트 모음 관리자는 표준 SharePoint 사용자 인터페이스를 사용합니다. 이 인터페이스는 사이트를 사무실에서 WSS 3.0을 실행하는 워크스테이션 컴퓨터에 호스트하든 데이터 센터의 웹 팜에 호스트하든 변경되지 않습니다.
SharePoint 인프라는 데이터베이스 관리자와 SAN 저장소 엔지니어에게도 보이지 않습니다. 이러한 관리자의 경우 SharePoint 데이터베이스는 다른 SQL Server 데이터베이스와 다르지 않으며, SQL Server 장애 조치(failover) 클러스터의 LUN(논리 단위 번호)도 다른 LUN과 다르지 않습니다. SharePoint 인프라와 가장 직접적인 관련이 있는 관리자는 웹 팜 관리자이지만, 이 관리자에게는 사이트 모음, 데이터베이스 또는 LUN에 대한 제어 권한이 없습니다.
부서 사이트 모음 관리자는 일반적으로 인프라 세부 사항에 대해 모른다고 말할 수 있습니다. 결국 부서 내의 팀과 그룹에 액세스 권한을 위임하고 사이트를 구축하는 데는 이러한 세부 사항을 알 필요가 없습니다. 쉽게 새로운 사이트를 만들고 공동 작업을 시작할 수 있으며, SAN 기술과 관련된 높은 저장소 비용 등의 문제가 좀처럼 중요하게 여겨지지 않기 때문입니다.
모든 프로젝트 및 이니셔티브를 진행하면서 새로운 팀 사이트가 나타나고 만료된 사이트가 사라지지 않으며 오래된 콘텐츠가 삭제되지 않아 시스템 관리자가 더 이상 무시할 수 없는 수준에 도달할 때까지 SharePoint 환경은 굉장한 속도로 급격히 퍼집니다. 예를 들면, Microsoft IT에서 2006년 간소화 이니셔티브를 시작하기 전에 Microsoft의 내부 SharePoint 환경에는 한때 180,000개가 넘는 사이트가 포함된 적이 있습니다.
사이트 모음 관리자에 대한 교육은 중앙 집중식 SharePoint 인프라에서 모든 부분에 대한 제어 상태를 유지하는 데 도움이 될 수 있습니다. 사이트 모음 할당량과 잠금을 적용하는 것도 유용하지만, 이러한 방법은 귀중한 저장소 및 백업 리소스를 낭비하는 오래된 팀 사이트 및 콘텐츠를 다룰 때는 그다지 효과적이지 않습니다.
오래된 콘텐츠로 인해 사이트 모음이 반드시 할당량을 초과하지는 않기 때문입니다. 물론 전자 메일 알림을 사이트 모음 소유자에게 전송하고 SharePoint 3.0 중앙 관리 사이트의 "사이트 사용 확인 및 삭제" 기능을 사용하여 지정된 기간이 경과되면 사용되지 않는 사이트 모음을 자동으로 삭제하도록 SharePoint를 구성할 수 있지만, 이 기능은 개별 사이트 수준에서는 작동하지 않습니다. 사이트 모음에는 현재 사이트와 더 이상 사용되지 않는 사이트가 포함될 수 있지만 "사이트 사용 확인 및 삭제" 기능은 이러한 세부 수준에서는 작동하지 않습니다.
뒷부분에서 사이트 모음에 대한 액세스 권한이 없어도 문서 및 목록 항목의 마지막으로 수정한 날짜를 확인하여 사용되지 않는 사이트와 오래된 콘텐츠를 식별하는 방법에 대해 설명하겠습니다. 이 보고 기능은 바로 사용할 수 있는 기능은 아니지만 다행히도 구현하기가 어렵지 않습니다.

분산된 SharePoint 사이트 관리
SharePoint 사이트 관리 권한을 위임하는 일은 매우 간단합니다. SharePoint 3.0 중앙 관리 사이트, 명령줄 도구인 Stsadm.exe 또는 사용자 지정 구축 도구를 사용하면 인프라에서 웹 응용 프로그램, 관리 경로 및 사이트 모음을 만들 수 있습니다. 웹 팜 관리자는 사이트 모음을 만들 때 기본 및 보조 사이트 모음 관리자를 지정할 수 있습니다. 이러한 사이트 모음 관리자는 일반 도메인 사용자일 수 있습니다. 웹 팜이나 다른 인프라 서버에 대한 관리 권한이 필요하지 않습니다. 이들은 웹 브라우저를 사용하여 SharePoint 사용자 인터페이스에서 사이트 관리 작업을 직접 수행할 수 있습니다.
그림 2는 첨부 자료의 워크시트에 있는 단계별 지침에 따라 위임된 사이트 관리를 나타낸 것입니다. 이 예에서 웹 팜 관리자는 HR 부서(http://sharepoint/hr) 및 IT 부서(http://sharepoint/it)에 대한 개별 사이트 모음을 구축했습니다.
그림 2 위임된 SharePoint 사이트 관리
그림 2 위임된 SharePoint 사이트 관리 (더 크게 보려면 이미지를 클릭하십시오.)
그러면 HR 및 IT 관리자는 SharePoint 사용자 인터페이스의 "사이트 작업" 메뉴에서 사용할 수 있는 "사이트 및 작업 영역" 기능을 사용하여 하위 수준 사이트를 만들고 하위 수준 사이트에 대한 새로운 관리 및 사용자 권한을 정의하거나 상위 사이트의 권한을 적용할 수 있습니다. 명시적으로 달리 구성하지 않은 경우 모든 사이트가 동일한 SharePoint 환경에서 호스트되어도 웹 팜 관리자는 최상위 수준 또는 하위 수준 사이트에 액세스할 수 없으며, HR 관리자는 IT 사이트에 액세스할 수 없고, IT 관리자는 HR 사이트에 액세스할 수 없습니다.
사이트 모음 및 사이트 계층의 설계는 조직의 요구 사항에 따라 달라집니다. 그림 2 예에서 http://sharepoint/hr 및 http://sharepoint/it 위에 마스터 사이트를 만들지 않았습니다. 다시 말해서 http://sharepoint 경로에는 사이트 모음이 없다는 뜻입니다. 하지만 이 경로 또는 http://sharepoint/sites/hr 및 http://sharepoint/sites/it 등 다른 관리 경로에서 사이트 모음을 쉽게 만들 수 있습니다.
또한 http://hr 및 http://it 등 보다 직관적인 기본 URL을 설정하도록 HR 및 IR용 개별 웹 응용 프로그램을 만든 다음, 일반적인 부서 포털 사이트를 구축한 후, 웹 파트를 롤업하여 이러한 마스터 사이트에 있는 하위 수준 사이트의 정보를 나열할 수 있습니다. 개별 사이트 모음은 자율 관리를 촉진하며, 부서 정보에 대한 액세스를 제한하고 마스터 페이지, 페이지 레이아웃, 템플릿, 웹 파트 및 탐색 컨트롤에 대한 개별 사용자 지정 기능을 제공합니다. 또한 다른 사이트 모음 및 콘텐츠 데이터베이스와는 별도로 전용 콘텐츠 데이터베이스 내에 중요 데이터를 보관하기 위해 사용할 수 있습니다.

역할, 사이트 권한 및 보안 조정
사이트 모음이 존재하고 관리 권한이 위임된 후에는 사이트 모음 관리자가 최상위 수준 사이트를 열고 "사이트 작업" 메뉴에 제공되는 "사이트 설정" 기능을 사용하여 사이트 모음을 관리할 수 있습니다. 여기에는 전체 권한을 가진 다른 사이트 모음 관리자를 사이트 모음 내 모든 사이트에 추가 또는 제거, 그룹 만들기, 이러한 그룹과 역할 연결, 그리고 읽기 및 참가자 권한을 부여하기 위해 이러한 그룹에 사용자 추가 등의 작업이 포함됩니다. 또한 하위 수준 그룹 사이트 및 팀 사이트 구축도 포함됩니다.
SharePoint 권한을 사용자에게 개별적으로 부여할 수 있지만 특정 역할에 따라 SharePoint 그룹을 만드는 것이 더 좋습니다. 예를 들면, SharePoint에는 방문자, 참가자 및 소유자 역할에 대한 세 가지 기본 그룹이 포함됩니다. 방문자는 읽기 전용 권한을 가지며, 참가자는 항목을 목록과 문서 라이브러리에 추가하고 웹 페이지를 개인 설정할 수 있습니다. 그리고 소유자에게는 모든 권한이 부여됩니다.
SharePoint에서 사용자 역할에 따라 보안 조정을 수행한다는 점에 주목할 필요가 있습니다. 다시 말해서 사용자 인터페이스에 사용자가 실제로 액세스할 수 있는 권한을 가진 링크 및 항목만 표시된다는 뜻입니다. "목록 설정"에서 명시적 권한을 구성하여 목록에 대한 사용자 액세스를 허용하거나 해당 항목의 상황에 맞는 메뉴에서 "권한 관리" 명령을 사용하여 선택한 목록 항목에 대한 사용자 액세스를 허용하는 것과 같은 방법으로 리소스에 대한 사용자 액세스를 허용하지 않을 경우 이러한 목록이나 항목이 해당 사용자에게 나타나지 않습니다. 사용자가 브라우저에서 항목의 URL을 직접 지정하면 사용자에게 "오류: 액세스 거부" 페이지가 표시됩니다.
그림 3은 실행 중인 보안 조정을 보여 줍니다. HR 관리자는 모든 권한을 가지고 있으므로 "사이트 작업" 메뉴에서 관리 작업을 수행할 수 있습니다. 한편, HR 방문자에게는 사이트 모음에 대한 읽기 전용 권한만 부여되므로 이 메뉴가 표시되지 않습니다.
그림 3 SharePoint 인터페이스에서 사용자 역할에 따라 보안 조정
그림 3 SharePoint 인터페이스에서 사용자 역할에 따라 보안 조정 (더 크게 보려면 이미지를 클릭하십시오.)
보안 조정은 액세스할 수 없는 기능, 링크 및 항목을 숨기는 데 유용하지만, 웹 팜 관리자가 액세스 권한 없이는 SharePoint 사용자 인터페이스를 사용하여 사이트 및 사이트 리소스를 나열할 수 없음을 의미하기도 합니다. 웹 페이지 또는 웹 파트에서 이러한 리소스를 볼 수 없습니다. 또한, SharePoint 엔터프라이즈 검색 기능이 쿼리를 전송하는 사용자의 ID에 따라 쿼리 시 보안 조정을 수행하기 때문에 액세스할 수 없는 리소스가 검색 결과에 나타나지 않습니다.

명령줄은 어떻습니까?
사이트 모음 수준에서의 상승된 권한 없이는 그래픽 사용자 인터페이스에서 원하는 정보에 액세스할 수 없는 경우 명령줄 도구 Stsadm.exe가 이러한 문제의 해결책을 제공할 수도 있을 것입니다. 예를 들면, 다음과 같은 명령을 사용하여,
Stsadm -o enumsites -url http://sharepoint
http://sharepoint 웹 응용 프로그램 내 모든 사이트 모음 및 소유자를 나열할 수 있다고 생각할 수 있습니다. 그런 다음에는 다음 명령을 사용하여 모든 하위 사이트를 나열할 수 있을 것입니다.
Stsadm -o enumsubwebs -url <사이트 모음>
하지만, 웹 팜 환경에서 Stsadm.exe는 일반적으로 데이터베이스 액세스 권한이 없음을 나타내는 오류 메시지를 표시합니다. 사용자가 웹 팜 관리자이고 SharePoint 3.0 중앙 관리에서 사이트 모음을 관리할 수 있더라도 Stsadm.exe에서는 사이트 모음을 열거할 수 없습니다. 다음은 SQL Server 액세스 권한 없이 웹 팜에서 Stsadm.exe를 사용할 경우 표시되는 오류 메시지입니다.
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o enumsites -url http://sharepoint
<Sites Count="2">
<Site Error="로그인에서 요청한 데이터베이스 &quot;WSS_Content&quot;을(를) 열 수 없습니다. 로그인이 실패했습니다.&#xD;&#xA;사용자 'CONTOSO\SPAdmin'이(가) 로그인하지 못했습니다.">
<Site Error="로그인에서 요청한 데이터베이스 &quot;WSS_Content&quot;을(를) 열 수 없습니다. 로그인이 실패했습니다.&#xD;&#xA;사용자 'CONTOSO\SPAdmin'이(가) 로그인하지 못했습니다." />
Stsadm.exe가 CONTOSO\SPAdmin과 같은 로그온된 사용자의 컨텍스트에서 실행되는 반면 SharePoint 3.0 중앙 관리 사이트는 CONTOSO\WssConfigAdmin과 같은 SharePoint 중앙 관리 v3 응용 프로그램 풀과 연결된 시스템 계정의 컨텍스트에서 SharePoint 데이터베이스에 액세스하기 때문에 웹 팜 관리자에게 이 오류가 표시됩니다. 계정에 SQL Server의 콘텐츠 데이터베이스에 대한 db_owner 권한을 부여하여 Stsadm -o enumsites -url http://sharepoint 명령을 실행할 수 있도록 해도 여전히 사이트 모음 내의 하위 수준 사이트는 열거할 수 없습니다. Stsadm -o enumsubwebs -url <사이트 모음> 명령에서 "액세스 거부(예외가 발생한 HRESULT: 0x80070005(E_ACCESSDENIED))"가 반환되고 사용자를 원래 위치로 되돌립니다. 하지만 상승된 SQL Server 권한이 필요하지 않은 보다 효과적인 방법도 있습니다.

콘텐츠 데이터베이스의 사이트 정보
표준 SharePoint 인터페이스 및 도구를 통해 필요한 정보를 얻을 수 없는 경우 SharePoint 콘텐츠 데이터베이스로 직접 이동해야 합니다. 하지만 이 방법에는 각별한 주의가 필요하며, 마지막 수단으로 사용해야 합니다! 콘텐츠 데이터베이스는 고객의 직접적인 데이터베이스 작업을 제한하기 위해 Microsoft에서 WSS 3.0 SDK 내에 부분적으로만 문서화해 놓은 전용 스키마와 데이터베이스 구조에 의존합니다. 원하는 정보에 액세스하려는 경우 가능한 한 SharePoint 사용자 인터페이스, 명령줄 도구, 개체 모델 또는 웹 서비스를 사용해야 합니다.
다른 대안이 없어서 데이터베이스로 직접 이동해야 하는 경우에는 최소한 솔루션을 읽기 전용 액세스로 제한해야 합니다. 데이터베이스 스키마 또는 데이터베이스 구조에 대한 수정은 지원되지 않으며 백업에서 사이트 모음을 복원하거나 SharePoint 웹 팜을 다시 설치해야 하는 심각한 문제가 발생할 수 있습니다.
콘텐츠 데이터베이스에 직접 액세스하는 보고 솔루션을 구현하기 위한 대안은 웹 팜 관리자 계정을 사이트 모음 구성에 보조 소유자로 지정하는 것입니다. 웹 팜 관리자는 SharePoint 3.0 중앙 관리 사이트에서 이 단계를 수행할 수 있습니다. "응용 프로그램 관리" 페이지의 "SharePoint 사이트 관리" 아래에 해당 사이트 모음 관리자 링크가 있습니다.
사이트 모음 보조 관리자는 웹 브라우저에서 사이트 모음을 열고 "사이트 설정"을 표시한 후 "사이트 관리" 아래에서 "사이트 사용 현황 보고서" 링크를 클릭할 수 있습니다. 단, SharePoint 3.0 중앙 관리에서 "사용 현황 분석 프로세스"가 설정되어 있어야 합니다. SharePoint 서버에 있는 로그 파일에서 사용 현황 데이터를 추적하려는 경우 "작업" 페이지에서 "기록 및 보고" 아래를 살펴봅니다. "사이트 사용 현황 보고서" 기능은 기본적으로 사용하지 않도록 설정됩니다.
하지만 웹 팜 관리자에게 필요한 권한을 부여할 수 없도록 하는 엄격한 요구 사항이 적용되거나 사이트 모음의 수가 많은 환경에서는 개별 사이트 모음에 대한 사이트 사용 현황 보고서를 수동으로 작성하는 것이 효과적이지 않습니다. 보다 효과적인 방법은 그림 4와 같이 항목 수, 모든 항목의 전체 통합 크기 및 항목의 마지막 수정 날짜 등 중요 통계와 함께 콘텐츠 데이터베이스의 모든 사이트 모음 및 사이트를 나열하는 간단한 ASP.NET 보고 응용 프로그램을 구현하는 것입니다.
그림 4 콘텐츠 데이터베이스에서 사이트 통계 직접 가져오기
그림 4 콘텐츠 데이터베이스에서 사이트 통계 직접 가져오기 (더 크게 보려면 이미지를 클릭하십시오.)
SharePoint 중앙 관리 v3 응용 프로그램 풀 계정 ID에서 이 응용 프로그램을 실행하면 상승된 SQL Server 권한이 없어도 콘텐츠 데이터베이스에 액세스할 수 있습니다. 앞에서 설명했듯이, 중앙 관리 계정에는 이미 필요한 SQL Server 권한이 있습니다.
첨부 자료에는 SQL Server에서 콘텐츠 데이터베이스에 대해 SELECT 쿼리를 사용하는 간단한 보고 솔루션과 웹 서버에 이 솔루션을 배포하기 위한 단계별 지침이 포함되어 있습니다. 아무런 보안 검사도 구현하지 않았다는 점에 주목하십시오. 이 솔루션은 익명 인증으로 실행됩니다.
중앙 관리 계정에서 콘텐츠 데이터베이스에 액세스하는 데 필요한 보안 컨텍스트를 제공하기 때문에 사용자를 인증할 필요가 없습니다. Windows Server 2008에서 Windows® 방화벽을 통해 차단되는 솔루션 웹 사이트에 대해 사용자 지정 포트를 사용했으므로 로컬 사용자만 웹 응용 프로그램을 열 수 있습니다. 이것으로 테스트 환경에서의 보안 요구 사항은 충족되었지만, 프로덕션 환경에서는 Windows 인증 사용 및 ASP .NET 응용 프로그램의 가상 디렉터리에 대한 제한적인 액세스 권한 구성 등을 통해 보안을 더욱 강화해야 합니다.

결론
SharePoint에서는 회사의 특정 요구에 따라 사이트 관리를 분산시키면서 SharePoint 인프라를 중앙으로 집중시킬 수 있도록 하는 유연한 사이트 모음 및 사이트 관리 기능을 제공합니다. 통합된 환경은 비용을 절감하고, 부서 내부 및 부서 간 정보 공유를 촉진하며, 고도의 보안, 안정성 및 확장성을 갖춘 환경을 유지하기 위해 계획된 방법으로 전문 지식을 적용하기 위한 기초를 제공하고, 사용자에게 회사 네트워크 내 사이트 및 SharePoint 리소스에 대한 단일 액세스 지점을 제공하므로, 중앙 집중식 인프라는 규모에 상관없이 모든 회사에 유용할 수 있습니다.
동시에 개별 부서 및 사업부에서 SharePoint 리소스를 지속적으로 제어할 수 있습니다. 웹 팜 관리자는 IT 부서의 개입 없이 자신의 책임 영역 내에서 사이트 관리 작업을 수행하는 사이트 모음 관리자를 지정할 수 있습니다.
하지만 제어권을 부서로 위임할 경우 웹 팜 관리자는 표준 SharePoint 기능 및 도구를 사용하여 인프라 내의 리소스 사용률을 모니터링할 수 있는 능력도 잃게 됩니다. 콘텐츠 데이터베이스에 할당량을 적용하고, 사이트 모음 관리자에게 전자 메일 알림을 발송하며, 보고용 사용 현황 데이터를 추적하여 이 문제를 완화할 수는 있지만, SharePoint 인프라를 효율적으로 관리하려면 콘텐츠 데이터베이스에서 읽기 전용 방식으로 필요한 사이트 메타데이터를 직접 추출하는 추가적인 도구가 웹 팜 관리자에게 필요합니다.
사용할 수 있는 옵션으로는 SQL Server 2005 Reporting Services 또는 유사한 엔터프라이즈 수준의 보고 솔루션 사용이 있습니다. 첨부 자료의 예에서 볼 수 있듯이 SQL Server SELECT 쿼리를 사용하여 필요한 정보를 얻을 수도 있습니다.

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


Windows PowerShell 출력 서식 지정하기
Don Jones

스크립트로 보다 멋진 출력을 얻고 싶은 욕심은 특별한 것이 아니며, 저도 종종 테이블 같은 형태를 출력하기 위한 최상의 방법에 대한 질문을 받곤 합니다. 실제로 이러한 작업을 수행하는 데는 몇 가지 방법이 있습니다. 첫 번째 단계는 데이터, 즉 서식이 있는 형태로 표시할 모든 데이터를
$data1, $data2 및 $data3이라는 이름이 지정된 변수에 넣는 스크립트를 작성하는 것입니다. 그러면 데이터 서식 지정 단계로 들어갈 수 있습니다.

텍스트 방식
웹에서
이 달의 Windows PowerShell 컬럼에서 설명한 기법을 간략하게 살펴보시겠습니까? Don Jones가 이러한 cmdlet를 어떻게 사용하는지 보려면 technetmagazine.com/video로 이동하십시오.

이 작업을 수행하기 위한 가장 일반적인 방법은 VBScript, Perl, KiXtart 또는 기타 텍스트 지향 언어에서 작업할 때와 동일한 방식을 사용하는 것입니다. 다음과 같은 열 머리글을 화면에 입력하는 것부터 시작할 수 있습니다.
Write-Host "ColumnA'tColumnB'tColumnC"
`t는 탭 문자를 삽입하는 Windows PowerShellTM의 특수 이스케이프 시퀀스입니다. 데이터가 $data1, $data2 및 $data3일 때 테이블의 각 행을 표시하는 방법에는 몇 가지가 있습니다. 한 가지 방법은 다음과 같이 큰 따옴표 안의 내용으로 변수를 대체할 수 있는 셸 기능을 사용하여 간단히 변수를 작성하는 것입니다.
Write-Host "$data1't$data2't$data3"
약간 더 매력적인 또 한 가지 방법은 -f 연산자를 사용하는 것입니다. 이 기법은 데이터와 서식을 분리하며, 코드를 보다 읽기 쉽고 관리하기 쉽게 하는 방법입니다.
Write-Host "{0}'t{1}'t{3}" –f $data1,$data2,$data3
그러나 이 전체적인 접근 방법에는 심각한 문제가 있습니다. 먼저 콘솔 창의 고정 탭 정지 위치에 의존함으로써 뜻밖의 서식이 생길 수 있습니다. 예를 들면, 특정 테이블 행의 첫 번째 열에 20자의 값이 있는 경우 이 행의 전체 서식이 맞지 않게 될 수 있습니다. 또한 Write-Host를 사용하여 이 텍스트를 출력하므로 콘솔 디스플레이로만 제한됩니다.
이 출력을 파일로 보내거나 다른 서식으로 전환할 수 있는 간단한 방법은 없습니다. 가장 중요한 점은 이 텍스트 기반 접근 방식에서는 본질적으로 작업 중인 개체 기반 셸을 완전히 무시하므로 Windows PowerShell에서 제공하는 모든 훌륭한 기법과 기능을 활용할 수 없다는 사실입니다.

Windows PowerShell 방식
Windows PowerShell은 개체 지향 셸입니다. 따라서 가급적이면 작업하는 모든 요소가 개체여야 합니다. 그래야만 셸에서 필요할 때 텍스트 디스플레이로 전환할 수 있습니다. 하지만 임의의 데이터에 대해 개체를 어떻게 생성할까요?
이 예에서는 빈 사용자 지정 개체를 만들어서 그 개체를 변수에 저장하는 것부터 시작합니다.
$obj = New-Object PSObject
이렇게 하면 사용할 수 있는 새로운 빈 개체가 만들어집니다. 그런 다음 데이터를 속성 형태로 개체에 추가합니다. 이렇게 하기 위해 개체를 Add-Member cmdlet로 간단히 파이프합니다. NoteProperty라는 것을 추가하고 속성 이름을 지정한 다음 속성 값으로 데이터를 삽입합니다. 속성의 이름을 지정할 때는 열 머리글을 사용하는 것이 좋습니다.
$obj | Add-Member NotePropertyColumnA $data1
$obj | Add-Member NotePropertyColumnB $data2
$obj | Add-Member NotePropertyColumnC $data3
이제 간단히 이 개체를 콘솔이 아닌 파이프라인으로 출력합니다.
Write-Output $obj
그런 다음 출력해야 할 각 테이블 행에 대해 위의 단계를 반복하면 됩니다. 다음은 문자열을 받아 원래 문자열과 함께 대/소문자 버전을 출력하는 간단한 함수입니다.
functionStringVersions {
param([string]$inputString)
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty Original($inputString)
  $obj | Add-Member NoteProperty Uppercase($inputString.ToUpper())
  $obj | Add-Member NoteProperty Lowercase($inputString.ToLower())
  Write-Output $obj
}
$strings = @("one","two","three")
foreach ($item in $strings) {
StringVersions $item
}
문자열 변수 배열로 시작하여 한 번에 각각 하나씩 진행하며 각 변수를 함수로 보냅니다. 그리고 함수의 출력이 파이프라인에 기록됩니다.
이 코드를 작성하는 보다 간단한 방법도 있지만, 여기서는 설명하려는 점을 명확히 보여 주기 위해 이 기법을 선택했습니다. 이 코드 실행에 따른 결과는 그림 1에 표시된 것처럼 완벽하게 서식이 지정된 테이블입니다. 이러한 결과는 셸이 테이블에서 개체에 대한 서식을 어떻게 지정할지 이미 알고 있기 때문입니다.
그림 1 테이블에 표시된 Windows PowerShell 출력
그림 1 테이블에 표시된 Windows PowerShell 출력 (더 크게 보려면 이미지를 클릭하십시오.)
개체의 속성이 네 개 이하인 경우 Windows PowerShell에서는 테이블을 자동으로 선택합니다. 따라서 아무 작업을 수행하지 않고도 멋진 모양의 테이블이 생성됩니다.

추가 기능
이달의 Cmdlet: Get-Command
사용 가능한 Windows PowerShell cmdlet 목록을 검토하기 위해 한두 번은 Get-Command 또는 간편한 앨리어스 gcm을 사용해 보았을 것입니다. 하지만 gcm이 실제로 얼마나 유연한지는 모를 수 있습니다. 예를 들어, 서비스를 사용하여 Windows PowerShell에서 수행할 수 있는 모든 것을 보려면 gcm -noun service를 실행합니다. 또는 Windows PowerShell 내보내기 옵션을 모두 보려면 gcm -verb export를 실행해 봅니다. PowerShell Community Extensions와 같은 특정 스냅인을 통해 추가된 cmdlet만 확인하려는 경우에는 gcm -pssnapin pscx를 실행합니다. "pscx"를 다른 스냅인 이름으로 바꾸면 해당 스냅인의 cmdlet를 볼 수 있습니다.
보시는 것처럼 이 Get-Command는 Windows PowerShell의 검색 기능에서 중요 역할을 담당합니다. Get-Command를 사용하면 설명서를 보지 않고도 사용할 수 있는 기능을 알아볼 수 있습니다. 또한 gcm은 Help*와 같은 명령을 사용할 때보다 훨씬 더 정확한 검색 기능을 제공합니다. Help 함수는 사용 가능한 도움말 항목만 나열합니다. 필요로 하는 cmdlet가 있다고 해도 help와 함께 제공되지 않은 cmdlet는 도움말 목록에 표시되지 않습니다.

이 기법의 이점은 테이블보다 훨씬 더 뛰어난 기능을 제공한다는 점입니다. 개체 작업 시 Windows PowerShell은 다양한 작업을 수행하는 방법을 알고 있습니다. CSV 파일 형태의 데이터를 원하십니까? Export-CSV를 사용하십시오. HTML 테이블을 선호하십니까? 개체를 ConvertTo-HTML로 파이프하십시오. 목록 서식이 필요하십니까? 개체를 Format-List로 파이프하십시오. 개체를 사용하면 셸에서 이미 수행 방법을 알고 있는 모든 기능을 사용할 수 있습니다. 다음은 위의 코드를 수정한 예입니다.
functionStringVersions {
  PROCESS {
   $obj = New-Object PSObject
   $obj | Add-Member NoteProperty Original($_)
   $obj | Add-Member NoteProperty Uppercase($_.ToUpper())
   $obj | Add-Member NoteProperty Lowercase($_.ToLower())
   Write-Output $obj
}
}
여기서는 파이프라인 입력을 허용하고 파이프라인으로 출력하도록 함수를 수정했습니다. 개체를 사용하려는 경우에는 언제나 이 방법이 더 좋습니다.
이제 이 함수의 PROCESS 스크립트 블록 내부에 코드가 들어 있습니다. 따라서 이 함수가 파이프라인 입력을 허용하고 파이프된 각 개체에 대해 한 번씩 PROCESS 스크립트 블록을 실행합니다.
PROCESS 스크립트 블록 내에서 특수 $_ 변수는 처리 중인 현재 파이프라인 개체를 나타냅니다. 이 예를 통해 문자열 배열로 간단히 파이프할 수 있다는 점을 알 수 있습니다.
@("one","two","three") | StringVersions
이 함수가 출력을 파이프라인에 추가하기 때문에 결과적으로 테이블이 만들어집니다. 파이프라인 끝에서 셸은 서식 지정 하위 시스템을 호출해야 한다는 사실을 알고 있습니다. 따라서 파이프라인의 개체 속성이 5개 미만이므로 테이블을 사용하기로 결정합니다. 속성이 더 많을 경우 셸은 기본적으로 목록을 사용합니다.
하지만 기본 동작에 의존할 필요는 없습니다. 이러한 개체를 간단히 다른 cmdlet에 파이프하여 개체로 다른 작업을 수행할 수도 있습니다.
@("one","two","three") | StringVersions | Format-List
@("one","two","three") | StringVersions | ConvertTo-HTML | Out-File "strings.html"
@("one","two","three") | StringVersions | Export-CSV "strings.csv"
@("one","two","three") | StringVersions | Select Uppercase,Lowercase -unique
그림 2는 두 번째 예의 결과 HTML을 웹 브라우저에 표시한 것입니다. 단지 출력 데이터를 단순 텍스트가 아닌 개체로 표현함으로써 이제 셸에 기본으로 제공되는 다양한 서식 지정 레이아웃, HTML 변환, 내보내기 옵션, 정렬, 필터링 및 그룹화 기능 등 풍부한 기능을 최대로 활용할 수 있습니다.
그림 2 HTML 형식으로 출력된 Windows PowerShell 데이터
그림 2 HTML 형식으로 출력된 Windows PowerShell 데이터 (더 크게 보려면 이미지를 클릭하십시오.)
이것은 매우 유용한 기능입니다. 가급적이면 작성하는 모든 스크립트에서 개체를 출력으로 생성하는 것이 좋습니다. 그러면 추가 코드를 한 줄도 작성하지 않고도 가능한 한 다양한 방법으로 출력을 사용할 수 있습니다.

Don Jones는 Windows 관리 자동화 전문가이며 Windows PowerShell: TFM 및 VBScript, WMI, and ADSI Unleashed 등의 서적을 집필했습니다. ScriptingAnswers.com의 포럼을 통해 Don Jones와 만날 수 있습니다.


Hey, Scripting Guy! 그리 힘들지 않은 일에도 보상은 있다
Microsoft Scripting Guys

이 기사의 코드 다운로드: HeyScriptingGuy2008_06.exe (150KB)

지난 수백 년 동안 사람들은 힘들게 일하면 그만큼의 보상이 따르며, 진정한 만족은 하루를 땀 흘리며 정직하게 일하는 데 있고, 진정한 행복은 여정이 아닌 목적지에서 도달했을 때 얻어진다는 등(이해가 되시죠?)에 대한 믿음을 가지고 있습니다. 신데렐라처럼 불평 없이 고된 일을 묵묵히 해내면 언젠가는 그만한 댓가가 주어질 것입니다.
참고: 과연 그럴까요? 여러분이 열심히 일하면 언젠가는 더 행복한 날이 오고 노력의 댓가가 있을까요? 왜 이와 같은 질문을 하냐구요?
물론, 신데델라의 경우에는 운이 좋았습니다. 어쨌든 여러분도 사악한 의붓 어머니 및 의붓 언니들과 살게 된다면 열심히 일할 수 있는 모든 기회를 갖게 됩니다. 하지만 신데렐라처럼 운이 좋지 않으면 어떻게 될까요? 사악한 의붓 어머니 및 의붓 언니와 살지 않는다면 어떻게 될까요? 여러분이 가혹하고 보람 없는 긴 고된 나날을 보내게 된다면 어떻게 될까요? 과연 진정한 행복은 어떻게 찾아야 할까요?
뼈빠지게 일하겠다는 확고한 계획이 있다면 Scripting Guys는 그림 1처럼 멋진 테이블 형식으로 데이터를 출력하는 스크립트 작성을 시도해 보라고 제안하겠습니다.
그림 1 테이블 형식의 출력
그림 1 테이블 형식의 출력 (더 크게 보려면 이미지를 클릭하십시오.)
앞에서 말했듯이 신데렐라는 운이 매우 좋은 사람이었습니다. 그녀는 집의 굴뚝부터 바닥까지 청소했으며, 청소가 끝나면 재와 검댕을 뒤집어쓰고 화로 앞에 앉아 있어야 했습니다. 하지만 신데렐라도 테이블 형식으로 데이터를 표시할 수 있는 스크립트를 작성해야 했다면 좌절했을 것입니다. 재와 검댕을 뒤집어쓰고 앉아 있는 것과 데이터를 테이블 형식으로 출력하는 스크립트를 작성하는 것은 전혀 다른 문제입니다.
참고: 스크립트를 작성하기 위해 화로 앞에 앉아야 하는 경우만 아니라면 두 문제는 거의 같다고 볼 수 있습니다.
신데렐라가 이 작업에서 왜 좌절하게 될까요? 저주스러울 정도로 너무 어려우니까요. VBScript에서 데이터를 테이블 형식으로 표시할 수 있는 유일한 방법은 다음 작업을 차례로 실행하는 것입니다.
  • 먼저 각 열의 최대 크기를 결정합니다. 예를 들면 서비스의 표시 이름으로 52자 공간을 채우고자 할 수도 있습니다.
  • 그런 다음 데이터 하나의 문자 수를 계산합니다. 예를 들면 표시 이름 Adobe LM Service는 16자로 되어 있습니다.
  • 표시 이름이 52자 제한을 초과할 경우 할당된 공간에 맞게 문자열 끝부분에서 잘라내야 하는 문자 수를 결정합니다. 표시 이름이 52자 공간을 초과하지 않는 경우 정확히 52자가 되도록 문자열 끝부분에 추가할 공백 수를 결정합니다.
  • 다음 데이터 집합에 대해서도 위 작업을 반복합니다. 그리고 나서 그 다음 데이터 집합으로 넘어갑니다. 이런 식으로 계속 반복합니다.
신데렐라 이야기에 대해 잘 알고 있다면 주인공을 돕는 요정이 갑자기 나타나서 정말 간단히 쥐를 시스템 관리자로 변신시켜 쥐가 여러분을 대신하여 이 스크립트를 작성하게 할 수도 있다고 생각할 것입니다. 하지만 아마도 그런 일은 기대하지 않는 것이 좋을 것입니다. 여기서는 아마도 여러분 스스로 해결해야 할 것입니다.
하지만 긍정적으로 본다면 여러분은 세상에서 가장 큰 만족감을 얻는 사람이 될 것입니다. 왜냐하면 세상에서 가장 열심히 일하는 사람이 될테니까요. 아주 열심히 일해야 합니다.
물론 일부 사람들의 경우 이같이 그렇게 힘든 일을 피할 수 있는 기회가 있다면 자신의 만족감 중 어느 정도는 기꺼이 포기하려 할 수도 있을 것입니다. 여러분이 이러한 부류 중 한 사람이라면 아마도 이렇게 생각할지도 모릅니다. "Scripting Guys가 있어서 정말 다행이야. 이들이 내게 쥐를 시스템 관리자로 변신시키는 방법을 알려주고 이 쥐를 시켜 테이블 형식으로 출력하는 방법을 알려줄거야." 하지만, 유감스럽게도 나쁜 소식을 전해드려야 할 것 같습니다. Scripting Guys는 쥐를 시스템 관리자로 변신시키는 방법을 모릅니다. 하지만 여러분이 원한다면 시스템 관리자를 쥐로 바꿀 수는 있습니다. Scripting Guys는 데이터를 테이블 형식으로 출력할 스크립트는 물론이고, 여러분을 대신하여 스크립트를 작성할 누군가를 찾을 수 있는 방법도 모릅니다.
하지만 괜찮습니다. Windows® XP 또는 Windows Server® 2003(여러분 중 대부분이 사용)을 실행하는 경우라면 여러분을 대신하여 스크립트를 작성해 줄 쥐가 필요하지 않습니다. (죄송하지만 이것은 Windows Vista®에는 해당되지 않습니다.) 대신, Microsoft.CmdLib 개체 덕분에 최소한의 노력만으로 여러분 스스로 이 작업을 수행할 수 있습니다. 그림 2의 샘플 스크립트를 살펴보겠습니다.
Figure 2 테이블 형식으로 출력하기
Dim arrResultsArray()
i = 0

Set objCmdLib = _
  CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = _
  WScript.Application

arrHeader = Array("Display Name", _
  "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" _
  & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery _
  ("Select * FROM Win32_Service")

For Each objService In colServices
  ReDim Preserve arrResultsArray(i)
  arrResultsArray(i) = _
  Array(objService.DisplayName, _
    objService.State,objService.StartMode)
  i = i + 1
Next
objCmdLib.ShowResults arrHeader, _
  arrResultsArray, arrMaxLength, _
  strFormat, blnPrintHeader, arrBlnHide
궁금해 하실 분들을 위해 미리 말씀 드리자면, Microsoft.CmdLib는 Windows XP 및 Windows Server 2003과 함께 제공되는 COM 개체입니다. 이 개체에는 다양한 기능이 있으며, 자세한 정보를 보려면 명령 프롬프트에서 cmdlib.wsc /?를 입력한 후 화면에 표시되는 스크립트 파일의 설명을 읽어보시기 바랍니다. 여기서는 Microsoft.CmdLib 기능 중 데이터를 테이블 형식으로 표시하는 기능에만 관심이 있습니다.
그렇다면 대체 데이터를 테이블 형식으로 어떻게 표시합니까? 자 그럼 그 방법에 대해 알아보겠습니다. 보시는 것처럼 샘플 스크립트는 arrResultsArray라는 동적 배열을 정의함으로써 시작됩니다.
Dim arrResultsArray()
일반적인 스크립트에서 데이터는 검색될 때 화면에 신속히 다시 출력됩니다. 하지만 왜 Scripting Guys가 일반적인 방식으로 작업을 수행할 것이라고 생각하십니까? 이 스크립트에서는 데이터가 검색될 때 데이터가 다시 화면에 출력되지 않도록 할 것입니다. 대신, 반환된 모든 데이터를 배열 내에 저장한 후 Microsoft.CmdLib를 통해 데이터의 서식을 지정하여 표시하도록 합니다.
다시 말하면, 이러한 이유로 동적 배열(스크립트 과정 중에 크기를 변경할 수 있는 배열)을 작성하는 일부터 시작합니다. 배열을 정의한 후에는 i라는 카운터 변수 값을 0으로 설정하고 이 변수를 사용하여 배열의 현재 크기를 추적할 것입니다.
궁금해 하실 분들을 위해 미리 말씀 드리자면, 배열의 첫 번째 항목에는 항상 인덱스 번호 0이 지정되므로 i 값을 0으로 설정하는 것입니다. 따라서 첫 번째 항목을 배열에 추가할 때 항목 1이 아닌 항목 0을 추가합니다.
다음에는 Microsoft.CmdLib 개체 인스턴스를 초기화해야 하므로 다음 두 줄의 코드가 필요합니다.
Set objCmdLib = _
CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = WScript.Application
그럼 다음과 같은 작은 코드 블록이 필요합니다.
arrHeader = Array("Display Name", "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)
여기서는 출력 구성을 위한 몇 가지 매개 변수를 설정합니다. 첫 번째 줄에서는 arrHeader라는 배열에 값을 할당합니다. 예상한 대로 이 값이 출력 테이블 내 각 열의 머리글입니다. 이 샘플 스크립트의 경우, 컴퓨터에서 실행되는 서비스에 대한 정보를 검색한 다음 각 서비스에 대한 DisplayName, State 및 StartMode 속성 값을 표시하려고 합니다.
크게 놀랄 것도 없겠지만, 배열에 열 이름 Display Name, State 및 Start Mode를 할당합니다. 원한다면 A, B 및 C, Larry, Moe 및 Curly 또는 그 밖의 원하는 이름을 열에 쉽게 할당할 수 있습니다. 열 이름이 속성 이름과 같을 필요는 없습니다.
참고: 의붓 언니의 이름을 비롯하여 신데렐라 이야기에는 다양한 여러 변형 요소가 있습니다. 신데렐라의 디즈니 버전에서 의붓 언니 이름은 Drizzella와 Anastasia인데, 글쎄 이 이름이 저희 스크립트 편집자의 첫 번째 이름과 중간 이름입니다.
코드의 두 번째 줄에서는 arrMaxLength라는 또 다른 배열에 값을 할당합니다. 이 배열에는 테이블 내 각 열의 크기를 저장합니다. 출력의 열 1(서비스 표시 이름)에는 52자 공간을 할당하려고 합니다. 그런 다음 서비스 상태 및 시작 모드에는 각각 12자 공간을 할당하려고 합니다. Microsoft.CmdLib에서 열 사이에 빈 공간을 자동으로 삽입합니다. 열 크기를 52, 12 및 12자 공간으로 설정하려는 경우 다음과 같은 코드를 사용하면 됩니다.
arrMaxLength = Array(52, 12, 12)
세 번째 줄은 데이터의 출력 형식을 지정합니다. 데이터를 테이블로 표시하려고 하므로 strFormat(출력 유형을 저장하는 변수)의 값을 Table로 설정합니다. 데이터를 쉼표로 구분된 값 목록으로 표시하려고 한다고 가정해 보겠습니다. 이 경우에는 다음과 같이 형식을 CSV로 설정해야 할 것입니다.
strFormat = "CSV"
이렇게 하면 다음과 비슷한 출력을 얻게 됩니다.
"Display Name","State","Start Mode"
"Adobe LM Service","Stopped","Manual"
"Adobe Active File Monitor V4","Stopped","Manual"
"Alerter","Stopped","Manual"
"Application Layer Gateway Service","Running","Manual"
"Apple Mobile Device","Running","Auto"
"Application Management","Stopped","Manual"
Microsoft.CmdLib에서 각 항목 사이에 쉼표를 추가할 뿐만 아니라 개별 값을 따옴표로 묶었습니다. 이 기능은 처음에 생각했던 것보다 더 멋진 기능입니다. 즉, 이 작업을 수동으로 수행하려면 다음과 같은 코드를 사용해야 할 것입니다.
Wscript.Echo Chr(34) & objService.DisplayName & Chr(34) & "," & Chr(34) & objService.State & Chr(34) & "," & Chr(34) & objService.StartMode & Chr(34)
역시 이 방법도 안 되겠군요.
그런데 테이블을 좋아하지 않는 경우, CSV 형식도 좋아하지 않을까요? 그렇다면 형식을 List로 설정해 보십시오. 그러면 다음과 같은 출력을 얻게 됩니다.
Display Name: Adobe LM Service
State:        Stopped
Start Mode:   Manual
Display Name: Adobe Active File Monitor V4
State:        Stopped
Start Mode:   Manual
하지만 본론을 벗어난 내용이네요. (가끔씩 이렇게 본론에서 벗어나게 되죠.) 출력 형식을 정의한 후에는 blnPrintHeader라는 변수의 값을 True로 설정합니다.
blnPrintHeader = True
blnPrintHeader를 사용하여 Microsoft.CmdLib에 열 머리글을 출력하도록 지시하려고 합니다. 열 머리글 출력을 원하지 않는다면 어떻게 해야 하나요? 괜찮습니다. 이 경우에는 blnPrintHeader를 False로 설정하면 됩니다.
blnPrintHeader = False
마지막으로 다음과 같은 코드가 있습니다.
arrBlnHide = Array(False, False, False)
데이터를 표시할 때가 되면 Microsoft.CmdLib에서 열을 표시할지 숨길지 선택할 수 있는 옵션을 제공합니다. 특정 속성에 대한 데이터를 표시하지 않기 위해 열을 숨기려면 해당 속성의 값을 True로 설정합니다. 열을 표시하려면 해당 값을 False로 설정합니다.
출력에서 DisplayName, State 및 StartMode 속성의 값을 순서대로 표시하려 하므로 배열에서 False, False, False 값을 사용합니다. DisplayName을 표시하고, State를 숨기며 StartMode를 표시하려는 경우에는 어떻게 해야 하나요? 이 경우에는 다음 코드를 사용하면 됩니다.
arrBlnHide = Array(False, True, False)
열을 표시하려면 False를, 열을 숨기려면 True를 사용한다는 것을 기억하시기 바랍니다.
이제 데이터를 출력할 준비가 되었습니다. 실제로 데이터가 있다면요. (Scripting Guys가 데이터를 출력하지 못하는 스크립트를 작성한 적이 있나요? 이로 인해 엄청난 시간을 들여 스크립트를 디버깅하려고 했으나, 알고보니 처음부터 실제로 검색할 데이터가 없었던 적은 없나요? 물론 아니겠죠. 그런데 어떻게 장담하시나요?)
이를 고려하여, 다음 단계는 로컬 컴퓨터에서 Windows Management Instrumentation(WMI) 서비스에 바인딩한 후 ExecQuery 메서드를 사용하여 해당 컴퓨터에 설치된 모든 서비스에 대한 정보를 검색하는 것입니다.
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery ("Select * FROM Win32_Service")
이 작업이 WMI 데이터로만 제한되는 것은 아닙니다. 예상한 대로 Microsoft.CmdLib는 모든 종류의 데이터에 사용할 수 있습니다. WMI는 일련의 데이터를 검색하기 위한 한 가지 유용한 방법일 뿐입니다.
서비스 관련 데이터 컬렉션이 있으면 For Each 루프를 설정하여 컬렉션의 모든 서비스를 순환할 수 있습니다. 하지만 각 서비스의 속성 값을 다시 화면에 출력하는 대신 다음 코드를 실행합니다.
ReDim Preserve arrResultsArray(i)
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
i = i + 1
이 코드 블록에서 수행하는 작업은 무엇일까요? 첫 번째 줄에서는 ReDim Preserve 명령을 사용하여 배열 크기를 조정하고 해당 배열에 있는 기존 데이터를 유지합니다. Preserve 키워드가 없으면 배열 크기는 조정되지만 해당 배열에 현재 들어 있는 데이터가 지워집니다.
만들려는 배열의 크기는 어떻게 됩니까? 루프를 처음 실행할 때는 크기가 0인 배열을 만듭니다. 다시 말해서 하나의 요소만 포함하는 배열을 만드는 것입니다. 크기가 0인 배열이 만들어진다는 것을 어떻게 확실히 알 수 있을까요? 카운터 변수 i를 사용하고 있으며 이 변수의 값이 0이기 때문입니다.
그렇다면 변수 i를 사용하여 배열 크기를 나타내는 경우 크기가 항상 0으로 설정됨을 의미하나요? 글쎄요. 루프를 실행할 때마다 i의 값을 1씩 증가시키는 것을 제외하고는 그렇다고 볼 수 있습니다. 보시는 것처럼 코드 블록의 세 번째 줄에서 이 작업을 수행합니다.
이제 우리가 걱정해야 할 코드를 한 줄만 남겨 놓고 있습니다.
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
여기서는 단순히 위에서 언급했던 DisplayName, State 및 StartMode라는 속성 값을 사용하며 이러한 속성 값을 arrResultsArray에 추가하려고 합니다. 속성 값을 개별적으로 추가하지 않고, 대신에 값 배열로 추가합니다. 이 부분은 다소 일반적이지 않을 것입니다. 즉 arrResultsArray 배열의 각 항목이 또 하나의 배열이 됨을 의미합니다. 이는 단순히 Microsoft.CmdLib의 작동 방식일 뿐입니다.
물론, 이 부분으로 인해 다시 걱정이 생길 수도 있을 것입니다. "배열의 배열? 전체가 배열로 이루어진 배열에서 모든 개별 값에 액세스하려면 도대체 어떻게 해야 할까요?" 겁먹지 마세요. 매우 간단합니다. 그냥 Microsoft.CmdLib에 맡기면 됩니다.
참고: 안타깝게도, 배열로 이루어진 배열의 모든 개별 값에 액세스하는 일은 Microsoft.CmdLib가 여러분을 위해 할 수 있는 유일한 일입니다. 하지만, 개체의 다음 릴리스에서는 사악한 의붓 엄마의 침실 청소, 설거지, 못된 언니들의 옷 만들기 등 다른 기능도 고려될 것입니다.
사실 ShowResults 메서드를 호출한 후 이 메서드를 스크립트 앞쪽에서 구성한 모든 배열 및 변수에 전달하면 간단히 데이터를 깔끔한 테이블 형식으로 출력할 수 있습니다.
objCmdLib.ShowResults arrHeader, arrResultsArray, arrMaxLength, strFormat, blnPrintHeader, arrBlnHide
어떻게 보일까요? 그림 1에서 보고 기대했던 멋진 형식의 출력처럼 보일 것입니다.
나쁘지 않죠? 멋진 출력을 얻었지만 거의 별도의 작업이 필요하지 않았습니다. 다음 스크립트는 이 첫 번째 스크립트를 조금만 변경하면 되므로 훨씬 더 쉬울 것입니다.
물론, 신데렐라가 스크립트를 테이블에 출력할 수 있었을 때나 그녀가 하루 종일 그리고 밤새도록 노예 생활을 하며 느꼈을 똑같은 만족감을 여러분은 얻지 못할 것입니다. 솔직히 말하면, 아마도 여러분은 왕자와 결혼하지 못할 것입니다. 이건 흥정에 포함되는 부분이 아니니까요. 하지만 이건 특히 왕자가 요즘과 같은 세상에서는 어떤 것을 좋아할지 고려하여 아주 싸게 VBScript 스크립트에서 멋진 출력을 사는 것과 같습니다.
그리고 누가 알겠습니까? 결국 여러분 스스로 왕자를 차지하게 될지 말입니다. 아무튼 왕족이라도 컴퓨터에 설치된 모든 서비스에 대한 정보가 필요합니다. 그렇죠?

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

2008년 6월: PowerShell Pathway
이러한 각 퍼즐에서 글자를 가로, 세로 및 대각선 방향으로 연결하여 Windows PowerShell cmdlet의 이름을 만듭니다. 각 글자는 한 번씩만 사용할 수 있습니다. 다음은 퍼즐 풀이 예입니다.
이 퍼즐에서 만들어진 cmdlet는 New-Alias입니다. 이제 여러분 차례입니다. 다음 세 가지 퍼즐을 풀어보세요.

ANSWER:
Dr. Scripto의 Scripting Perplexer
정답: PowerShell Pathway, 2008년 6월

Read-Host

Set-AuthenticodeSignature

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


The Desktop Files 보안과 규정 준수
Wes Miller

IT 전문가로서 여러분은 서로 보완되어야 하지만 그대신 종종 서로 경쟁하는 목표에 직면할 수 있습니다. 보안과 규정 준수는 하나를 실현하면 다른 한 쪽도 향상되어야 하는 조직 차원의 두 가지 목표입니다. 그러나 그렇지 않은 경우가 일반적입니다. 여기서는
보안 유지가 여러분에게 요구되는 이니셔티브에 대한 준수를 항상 의미하지는 않는 이유 및 종종 규정 준수가 보안을 의미하지 않거나 규정 준수가 보안과 진정으로 동등시 되는 경우에도 실현해야 할 최소한의 보안을 의미하지 않는 이유에 대해 간략하게 설명하려고 합니다.

보안은 필수
SDL 리소스
  • The Security Development Lifecycle, Michael Howard와 Steve Lipner 공저(Microsoft Press, 2006)
  • 보안 개발 수명 주기 블로그
  • Microsoft에서 보안 개발 수명 주기 살펴보기
  • 보안 개발자 센터
  • 신뢰할 수 있는 컴퓨팅 보안 개발 수명 주기

규정 준수에는 일반적으로 외부로부터 조직, 업계, 회사 또는 제품에 부과되는 요구 사항(인력, 프로세스, 인프라, 기술 등)이 수반됩니다. 경우에 따라서는 업계 내에서 발표된 표준(예: PCI-DSS(Payment Card Industry Data Security Standard))을 준수해야 합니다. 이상적으로 이러한 표준은 최소한 어느 정도까지는 조직의 기존 운영 방식과 맞는 이니셔티브입니다. 표준 채택이 급증함에 따라 비즈니스를 목적으로 하지 않는 경우라면 몰라도 이러한 표준을 간과할 수는 없습니다. 결국 표준을 채택하여 이를 최대한 활용해야 합니다.
일반적으로 좀 더 까다로운 준수 유형도 있습니다. 여기에는 HIPAA(Health Insurance Portability and Accountability) 및 Sarbanes-Oxley와 같이 이행과 시기에 대한 선택권이 거의 주어지지 않는 정부에서 제정한 이니셔티브가 포함됩니다.
규정 준수를 이해하는 데 중요한 포인트는 준수가 대체로 "하향식" 접근 방식을 사용한다는 점입니다. 일반적으로 이니셔티브를 정의하는 획일적인 템플릿이 제공되며, 여러분은 제품과 프로세스를 살펴보고 이 이상한 모양의 템플릿에 이를 어떻게 끼워 맞출 수 있을지 알아내야 합니다. 규정 준수 이니셔티브의 의도뿐만 아니라, 아마도 보다 중요한 문제일 수도 있는, 규정을 준수하지 않을 경우 또는 성공하지 못할 경우 발생될 수도 있는 법률 또는 재정적 파장이 있다면 이것이 무엇인지도 인식하고 있어야 합니다.
우리는 많은 규정 준수 이니셔티브의 의도에 충분히 공감하지만, 이행이 쉽지 않은 경우가 종종 있으며 원하는 목표를 실현하지 못할 수도 있습니다. 또한, 유감스럽게도 효과적이지 못한 규정이 많습니다. 즉, 준수하지 않을 경우 받게 될 수 있는 직접적인 법률적 또는 재정적 불이익이 없습니다.
의료 환자 중 한 명인 저도 여러분에게 HIPAA의 실익을 완벽하게 설명할 수 없습니다. 여러분에게 말씀드릴 수 있는 점은 병원에 갈 때마다 다루어야 할 서류가 엄청나게 많다는 사실입니다. 더 심한 것은 의도하지 않은 결과가 발생될 수도 있다는 것입니다. 한 의사나 진료 기관에서 다른 의사나 진료 기관으로 중요한 의료 정보를 이관하려고 한 적이 있으십니까? 서면 승인이 없는 경우에는 해당 정보가 아무리 시급하게 필요할지라도 절대로 불가능합니다.
한마디로, 여러 의미에서 일부 규정 준수 이니셔티브는 선택적 이니셔티브가 되는 셈입니다. 즉, 여러분은 프로세스나 제품을 오로지 이러한 규정 준수 이니셔티브를 충족시키기 위해서 수정하거나 설계하고 있는 것입니다. 세 살 짜리 제 아이에게도 가끔 묻는 질문인데요, "그게 좋은 생각일까요?"
한편, 보안은 올바르게 실현될 경우 상향식 이니셔티브입니다. 소프트웨어 제품을 설계하든 조직의 새로운 네트워크를 위한 아키텍처를 설계하든 기억해야 할 주요 개념은 시작하기 전에 철저히 준비해야 한다는 것입니다. 예를 들어, 제품 아키텍처를 설계하는 경우 바람직한 시작 단계에서는 통신, 지역화, 버전 등에 대해 다룰 것입니다. 이와 마찬가지로 처음부터 응용 프로그램에 포함시킬 보안 요소를 다루고 개발 과정 전체에 걸쳐 계속 조사하고 조정해 나가야 합니다.
여러분 중 대다수에 해당될 것으로 생각되는데, 다른 사람에게 이어받은 응용 프로그램이나 아키텍처로 작업 중인 경우에도 제가 여기서 자주 언급하는 심층적인 보안 검토를 반드시 수행해야 합니다. 어떻게 작동하는지 이해하지 못한다면 보안 상태를 어떻게 점검할 수 있겠습니까? Microsoft® Security Development Lifecycle(SDL)에 대한 자세한 내용은 "SDL 리소스" 추가 기사를 참조하십시오.

큰 그림
오래전에 보안은 단순히 암호화, ACL(액세스 제어 목록), TLS 또는 PKI(공개 키 인프라)를 구현하는 것과는 다르다고 배운 적이 있습니다. 진정한 보안은 큰 그림을 파악하는 것입니다. 즉, 특정 프로토콜 버전이 제외되었거나 지원되지 않는 이유, 새로운 기능에서 man-in-the-middle 공격을 차단하는 이유, 제품 V1이 훨씬 더 빠름에도 불구하고 어떻게 제품 V2를 구현하는 것이 V1보다 훨씬 더 안전한지 등 다양한 측면을 파악해야 합니다. 또한 인프라의 모든 부분이 어떻게 맞아 떨어지는지도 이해해야 합니다.
한편, 규정 준수는 기술을 채택하고 구축한 인프라를 특정 기준에 맞추는 것을 의미합니다. PCI-DSS(Payment Card Industry Data Security Standard) 또는 NERC(North American Electric Reliability Council)와 같은 일부 이니셔티브는 그 취지가 좋으며 실질적인 보안 변화를 촉진할 수 있습니다. 하지만 다양한 "규정 준수 이니셔티브"를 고유의 특정 프로젝트와 끼워 맞춰야 하고 사용 가능한 리소스가 한정되어 있다면 보안 이니셔티브에 대한 지지는 낮아지게 됩니다.
보안은 오랫동안 소프트웨어 개발 부분에서 주목을 받지 못했습니다. 여러분 중 대다수가 보안에 대해 "나중에 하죠"라고 답하는 그런 조직에서 근무해 왔을 것입니다. 그러나 이제는 보안에 시간적 여유가 있다는 생각에 문제가 있으며 결코 그럴 수 없다는 인식이 퍼져 규정 준수 이니셔티브가 서서히 정착하고 있습니다.

충분하다-잘못된 인식
최근에 저는 직장을 옮겼습니다. 현재 저는 여기 텍사스주 오스틴에서 예전에 Winternals에서 Protection Manager 제품을 사용하여 구축했던 기술과 유사한 응용 프로그램 허용목록 방식(whitelisting) 기술을 구축하는 새로운 일을 시작했습니다. 여기서 근무하면서 저는 고객이 말하고 싶어하는 매우 흥미로운 주제 중 하나가 그들이 현재 기술을 얼마나 안전하다고 느끼는지 또는 좀 더 구체적으로 말하면 그들이 사용 중인 기술 제품이 인프라를 얼마나 안전하게 구축하고 있다고 생각하는지에 대한 것이었습니다. 대부분의 제품이 전체적으로 안전하며 보안 취약점이 거의 없다고 생각되지만, 흔히 저를 조금 움찔하게 만드는 그들의 평가는 시스템의 "보안이 충분하다"라는 표현이었습니다.
규정 준수 이니셔티브는 흥미롭습니다. 이러한 이니셔티브를 충족하거나 충족하지 못하거나 둘 중 하나입니다. 책임은 여러분에게 있습니다. 이니셔티브를 충족하지 못할 경우 일반적으로 벌금 또는 위약금이 부과되거나 조직에서 퇴출됩니다. 대체로 이러한 처벌은 실질적인 변화를 가져오는 데 충분하지 않습니다.
연방 정부에서 요구하는 이니셔티브의 경우, "감사자를 만족시키기에 충분하다"라는 태도 또는 HIPAA와 같은 지원 법률에서 시행에 대한 충분한 투자가 이루어지지 않는다는 것을 빌미로 규정 준수 프레임워크가 실제로 마련되지 않은 상태에서도 이를 실행하겠다는 무모한 의도를 어김 없이 접하게 됩니다. 다시 말해서 보험 없이 운전할 때는 비용이 훨씬 덜 드는 것 같지만 결국 나중에는 위험한 결과에 직면할 수 있다는 것을 의미합니다.
보안도 종종 이와 같은 장애에 부딪히지만 제 생각으로는 최소한 보안은 보다 실제적입니다. 개발자나 구현자가 규격을 벗어난 섹션을 그대로 둘 경우 제품이 규정을 위반할 가능성이 높아질 것이라고 관리 부서에 적극적으로 피력한다면 최소한 제품이 출시되거나 배포가 완료된 후 "그렇게 될 것라고 이미 경고했습니다"라는 말은 할 수 있을 것입니다. 제 경험상 규정 준수 이니셔티브는 대체로 제한된 가용 예산 내에서 급하게 실현됩니다. 목표는 단순히 이니셔티브에서 요구하는 최소 사항만 충족하는 것입니다. 따라서 제가 보기에 그것은 진정한 의도가 아닌 단지 글자 그대로의 이니셔티브를 충족하는 것뿐입니다.

현재 상태 파악
보안 및 규정 준수 리소스
  • 보안 및 규정 준수 솔루션 지침
  • 보안 지침
  • PC-DSS(Payment Card Industry Data Security Standard) 규정 준수 계획 가이드
  • 규정 준수 및 보안 업데이트
  • 규정 준수 실현
  • 민권 사무국(Office for Civil Rights)—HIPAA
  • PCI 보안 표준 협회(PCI Security Standards Council)
  • 북미 전기 신뢰성 협회(North American Electric Reliability Council)

이상적으로는 제품과 조직을 가능한 한 안전하게 만들어야 한다고 말할 수도 있겠지만, 현실에서 대부분의 규정 준수 이니셔티브는 서투른 엔지니어링 또는 흔히 자기 만족의 결과로 인한 절충안 정도의 수준입니다. 우리는 안타깝게도 "충분하다"가 정말로 충분한 수준으로 인식되고 있는 세계에 살고 있습니다. 하지만 보안 부분에서 "충분하다"는 대체로 신중한 결정이 아닙니다. IT 전문가들인 우리는 규정 준수 이니셔티브를 마음에 새기고 그 진정한 의도와 실행이라는 두 가지를 모두 충족시키기 위해 노력하며, 가능한 수준에서의 보안이 아니라, 반드시 갖추어야 할 필수 수준의 보안을 유지할 수 있는 인프라를 구축하도록 해야 합니다. 다시 말해서 단순히 이니셔티브를 충족시키는 수준이 아니라 실질적인 보안을 통해 규정을 준수해야 합니다.
대규모 시스템에 통합하려는 일련의 기술이든 하나의 상용 소프트웨어이든 구축하고 있는 기술을 한 걸음 뒤로 물러나서 살펴보는 것도 중요합니다. 시스템에서 서로 맞물리는 부분, 모든 부분이 함께 작동되는 방식, 시스템에 대한 보다 큰 위협을 파악하는 일은 매우 중요합니다.
각자가 속해 있는 업계에 따라 다양한 규정 준수 이니셔티브가 여러분 업무와 연관되어 있을 수 있습니다. 이러한 규정 준수 이니셔티브를 일상 생활에서 접할 수도 있고 새 프로젝트 또는 기술을 설계할 때만 접할 수도 있습니다. 또는 이러한 규정 준수 이니셔티브가 특별 지시에 따른 규정 준수 검토 또는 감사 과정 중에만 업무의 한부분이 되는 경우도 있습니다. 어떤 경우든 상관없습니다. 규정 준수 이니셔티브를 무시해서도 안 되지만, 현재의 상태도 바람직하지 않습니다. 업무와 연관된 규정 준수 이니셔티브를 충족하는 데만 급급해 하지 말고, 대신 여러분의 기술을 완벽히 이해할 수 있도록 보안에 대한 철저한 검토를 수행하고 규정 준수 검토와 동시에 보안을 모델링해야 합니다.

손해볼 것이 없음
궁극적으로 규정 준수 이니셔티브를 충족시키지 못하여 부과되는 위약금이 모호하게 느껴질 수도 있습니다. 그러나 규정을 준수하지 않으면 이니셔티브가 제안된 상황과 동일한 위험이 닥칠 때 보호를 받을 수 없습니다. 결과가 막연하거나 먼 얘기 같겠지만 현실로 나타날 것입니다. 이러한 결과는 개인적인 결과에 그치지 않을 수도 있습니다. 따라서 실제적이어야 하지만 항상 최악의 상황을 염두에 두어야 합니다.
엄격한 보안적 관점에서 동일한 공간을 살펴보면 위협은 명백합니다. 따라서, 특히 취약점을 보완하지 않은 상태로 둘 경우 발생할 수 있는 잠재적인 비용을 즉시 식별할 수 있어야 합니다.
저와 함께 이 주제를 논의했던 많은 사람들은 규정 준수 이니셔티브에는 종종 해석의 여지가 너무 많기 때문에 때로는 규정 준수 이니셔티브의 진실이 숨겨져 있다는 사실을 강조합니다. 하지만 보안 검토를 수행하고 나면 보안 누락에 대해서는 이 말이 사실이 아니라는 것을 알게 됩니다. 보안을 무시하면 이로 인해 즉각적인 위협이 닥치게 됩니다. 그렇지 않다면 보안 검토에 투입된 사람을 다시 고려해 보아야 할 수도 있습니다. 솔루션에서 실제 문제를 찾아낼 수 있는 주요 팀원이 빠져 있기 때문일 수도 있으니까요.

악순환
지난 해 보안 특집 칼럼에서 "데이터 보호 방법"(technet.microsoft.com/magazine/cc162325)에 대해 설명한 적이 있습니다. 1년의 시간이 지나는 동안 더 많은 시스템이 손상되었고, 암호화되지 않은 랩톱이 더 많이 분실되었으며, 더 많은 개인 정보가 신뢰할 수 없는 자들에게 유출되었습니다. 보안에 있어서 어떠한 진전이 있었는지 말하기가 매우 어렵습니다. 왜 우리는 여전히 같은 곳에 머물러 있는 걸까요? 흔히 프로젝트는 적은 예산을 기반으로 터무니없이 광범위한 리소스를 사용하여 너무나 짧은 기간 내에 너무 많은 기능을 제공하려고 안간힘을 쓰다가 예상보다 늦어집니다.
안타깝게도, 이러한 환경은 아주 최소한의 작업을 하는 것이 일반화되는 분위기를 유도합니다. 이것은 확실히 솔루션의 보안 또는 규정 준수를 보장하기 위한 방법이 아니며 또한 프로젝트의 기간이나 비용에도 전혀 도움이 되지 않습니다.
개인적으로 저는 다음과 같은 확고한 신념을 가지고 있습니다.
  1. 보안을 유지하지 않으려면 솔루션을 구축해서는 안 됩니다.
  2. 새로운 기능을 추가할 때마다 시작하기 전에 보안을 먼저 설계해야 합니다.
  3. 조직에서 엔지니어링 프로세스의 한 단계로 보안을 구축할 의향이 없다면 전체 회사 또는 조직 목표가 무엇인지에 대해 의문을 제기해야 합니다.
조직에서 안전하게 유지해야 할 고객 또는 파트너 개인 데이터의 양이 점점 더 많아지고 있습니다. 너무나 자주 보안이 기본적으로 보장되지 않고 직원이 조직의 보안 조치에 대해 의문을 가지고 이를 안전하게 느끼지 못하는 세계에서 우리가 살고 있다는 사실은 참으로 안타까운 일입니다.
규정 준수가 아닌 실제 보안 실패가 너무나 일반적으로 "시스템 보안을 구축해야 할 시점"을 나타내는 계기로 작용하며, "신원 도용 보험"이 개인 데이터, 잠재적인 재무적 평안이 손상된 고객, 학생, 환자 및 직원을 달래기 위한 표준 책임 전략이 되어 왔습니다.
우리 모두는 일반적으로 매우 짧은 시간 동안 매우 작은 부분을 위해 너무나 많은 것을 하라는 요구를 받습니다. 하지만 IT 전문가로서 우리는 보안이 주목을 받지 못하는 이유, 관리 부서에서 흔히 규정 준수 이니셔티브 또는 보안 실패 및 실제 또는 잠재적인 법적 위협(조직을 궁지에 빠뜨리고 위태롭게 할 수도 있는)을 직면할 때만 보안을 생각하는 이유에 대해 문제를 제기해야 할 책임이 있습니다.

도전
무엇보다도 현재의 상태에 도전할 것을 권유합니다. 규정 준수 목표만을 충족시키라는 지시를 받는 경우 단지 누군가의 보안 개념을 충족시키는 데 시간을 낭비하지 말고 규정 준수 목표가 확실히 충족되도록 노력하십시오. 여러분의 목표는 시스템 보안을 유지하는 것이어야 하며, 그 과정에서 규정 준수 이니셔티브를 충족하기 위한 인프라 또는 프로세스를 충분히 정의하십시오. 이 주제에 대한 자세한 내용은 "보안 및 규정 준수 리소스" 추가 기사를 참조하십시오.
요약하자면, 규정 준수는 대부분의 경우 보안으로 가는 길이 아닙니다. 하지만 올바르게 구현되고 갖춰진 보안은 규정 준수로 가는 길일 수 있습니다.

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


The Business of IT 환경 리더가 되기 위한 10가지 주요 포인트
Michael Walsh and Eliza Walsh

모든 회사에서 환경 보호를 위한 노력에 대해 이야기하고 있는 것 같습니다. IT는 이러한 환경 보호 노력에서 중요한 역할을 담당할 수 있습니다. 따라서 IT 전문가인 여러분은 변화를 이끌고 회사와 업계에서 사고의 리더가 될 수 있는 좋은 기회를 창출할 수 있습니다. 하지만 어디서부터 시작해야 할까요? 다음은 조직에서 환경 및 지속 가능성 이니셔티브를 이끌어내는 유능한 리더가 되기 위한 10가지 주요 포인트입니다.
문제에 대한 이해
첫 번째 단계는 환경 지속 가능성과 컴퓨팅에 대한 광범위하고 심층적인 전문성을 개발하는 것입니다. IT 전문가로서 여러분은 전원 관리, 하드웨어 통합 및 환경 폐기물 관리 등 컴퓨팅의 환경적 영향을 줄이기 위한 방법을 올바르게 이해하는 것부터 시작해야 합니다.
또한 환경 리더로서 소프트웨어와 하드웨어가 IT 부서 이외의 업무로 인한 환경 영향을 줄이는 데 어떻게 도움이 될 수 있는지도 상상해 보아야 합니다. HR 관리자, 변호사 및 비즈니스 관리자와의 긴밀한 협력을 통해 회사의 전체 환경 영향을 다루는 정책을 정의할 수 있습니다. 이러한 정책은 아마도 출장 정책에서 글로벌 탄소 배출량 규정에 이르는 모든 부분을 다룰 것입니다.
회사 내외의 인사들은 환경, 회사, 그리고 회사가 속한 업계에서 여러분의 전문성을 기대할 것입니다. 그러므로 여러분은 자신의 환경 지속 가능성 및 지속 가능한 컴퓨팅에 대한 이해도는 물론, 회사의 장단기 고유 요건을 평가해야 합니다.
회사에 새로 입사했거나 새로운 직무를 배정받은 경우 업무를 신속하게 처리해야 한다는 압박을 실제건 느낌상이건 받게 될 수 있습니다. 특히 회사가 환경을 고려하여 운영해 온 적이 거의 없으나 이제 환경을 의식한 운영을 시급하게 도입하려는 경우에 특히 압박을 느낄 수 있습니다.
너무 빨리 진행하기를 요구하는 이러한 유혹으로부터 견뎌내야 합니다. 이러한 유혹은 여러분의 신용은 물론 회사의 신용도 위험에 빠뜨릴 수 있습니다. 단기적으로는 충분한 준비를 갖추거나 어느 정도(ramp-up) 기간이 지날 때까지 시급한 문제에 중점을 두고 전략적 이니셔티브에 대한 커뮤니케이션은 잠시 미루도록 합니다.

회사에 대한 객관적인 평가
다음 단계는 회사 또는 기간 업무(LOB)의 환경 및 지속 가능성을 정확하게 평가하는 것입니다. 이렇게 하려면 주요 이해 관계자와 회사 내외의 기타 영향력 있는 인사들이 참여해야 합니다.
이해 관계자의 에코시스템 정의를 지원할 수 있는 인사로 구성된 내부 및 외부 연락망을 구축해야 합니다. 이들은 환경 지속 가능성 측면에서 현재 회사의 상태를 이해하는 데 도움을 줄 수 있습니다.
여러분에게 주어진 책임에 따라 환경 규정, 표준 및 법규에 대한 회사의 현재 및 미래의 준수 상태를 파악해야 할 수도 있습니다. 경쟁자 및 분석가의 예상을 고려하여 회사의 현재 상태를 평가해야 할 수도 있습니다. 또한 고객, 파트너, 정부 기관 및 영향력 있는 고객 지지자들이 회사와 회사의 환경적 노력을 얼마나 이해하고 있는지도 파악해야 합니다. 이니셔티브와 관련하여 현재 및 미래의 기술적, 재정적 및 환경적 제한도 판단해야 합니다.
회사의 규모와 예산에 따라 추가 조사를 고려해 보아야 할 수도 있습니다. 건설적인 통찰력은 내부 설문 조사, 포커스 그룹 및 외부 조사 기관을 통해 얻을 수 있습니다. 이러한 통찰력은 과거 기업의 환경적 활동에 관한 직원 만족도, 경쟁자에 대한 회사의 입지, 잠재 시장 기회가 존재하는 영역 등을 보다 잘 파악하는 데 도움이 됩니다. 하지만 여기서 가장 큰 잠재적 가치는 주요 이해 관계자가 가지고 있는 의견을 논박하거나 입증할 수 있는 외부 조사 기관의 능력입니다.

지향하는 목표 및 시기 설정
이제 단기 및 장기적으로 회사가 도달해야 할 목표를 파악해 나갈 수 있습니다. 먼저 각각 1년과 5년으로 이러한 목표를 설정한 다음 특정 필요에 맞게 이 기간을 조정합니다. 여기서 절대적으로 간과해서는 안 될 중요한 포인트는 환경은 분명 단기적인 문제가 아니며 이 부분에서 단기간에 입지를 세우려 할 경우 회사, 이해 관계자, 파트너 및 고객에게 심각한 피해를 가져오게 된다는 점입니다.
1년과 5년 각각의 기간 동안 회사가 어느 목표까지 도달해야 하는지 판단하려면 현재 및 미래의 비즈니스를 조망해 보아야 합니다. 여기에는 회사의 문화, 회사의 단기 및 장기 비즈니스 목표, 현재 및 미래의 예산 제한, 지리적 확장 계획, 그리고 업계의 변화하는 법률 및 규정 환경이 모두 포함됩니다.
예를 들면, 데이터 센터에서는 전술적인 의사 결정과 전략적 포지셔닝 사이에서 충돌이 발생할 수 있습니다. 과거에는 데이터 센터 설계 시 공간이 주요 고려 사항이었습니다. 하지만 지난 몇 년 동안 점차적으로 전력이 공간의 확장 제한 요인으로 크게 작용하게 되었고 운영 비용의 증가를 가져왔습니다. 이러한 전력에 대한 중요성 증가가 장기적으로 미칠 영향을 인식한 데이터 센터 운영자는 에너지 비효율성을 줄이기 위한 조치를 취했습니다. 여기에는 주요 공간 기반 결정 요인을 부정하는 데이터 센터 관리의 급진적인 변화가 포함되었습니다. 경우에 따라 기존 방식을 유지하는 것과 비교할 때 전력 감소를 위한 투자에 상당한 단기 비용이 들 수도 있습니다. 하지만 에너지 가격이 크게 증가하는 추세를 고려할 때, 몇 년 전에 데이터 센터 관리 방침을 미리 변경한 데이터 센터 운영자가 지금은 예언자처럼 보이고 회사에서는 초기 투자 이상의 이익을 거두고 있을 것입니다.

비전과 전략 개발
이제 비전과 전략을 개발해야 합니다. 분명히 말하지만 이 단계는 비즈니스의 현재 상태와 도달할 목표를 충분히 파악한 상태에서 수행해야 합니다. 비전과 전략을 설정할 때 이러한 것들이 기본적으로 영구적이라고 생각해서는 안 됩니다. 회사의 환경적 노력은 지속될 수 있지만 여러분의 비전과 전략은 그렇지 못할 수 있습니다. 규정 요구 사항의 변화, 고객 인식의 변화 및 새로운 비즈니스 요구 출현 등 내부 및 외부 변수로 인해 비전과 전략을 여러 차례 수정하게 될 것입니다. 회사의 환경 이니셔티브가 수립된 상태에서 IT 비전과 전략을 더 큰 기업 비전과 전략에 맞추는 것이 중요합니다.
비전을 설정할 때 비즈니스의 방향을 설정하게 됩니다. 신중하고 간결하며 일관되면서 소모적이지 않도록 어휘를 주의하여 선택해야 합니다. 비전은 회사가 환경을 고려하여 수행하는 모든 행위를 다루기 위한 것이 아닙니다. 비전에서는 직원과 파트너를 올바른 방향으로 이끌기 위해 언급해야 할 문제만 다루어야 합니다. 흔히 사명서(또는 비전 선언문)가 비전을 전달하는 데 사용됩니다. 처음 6개월 내에 비전에 대한 커뮤니케이션을 시작해야 합니다.
전략 설정을 통해 방향을 정의할 뿐만 아니라, 명시적인 비즈니스 목표와 목적을 설정하고 이러한 목표와 목적에 도달하는 데 필요한 투자의 윤곽을 그리게 됩니다. 전략적 계획의 조직적 수립을 위해 기존 모델이 도움이 될 수 있습니다. 환경 및 지속 가능성 문제에 적합한 두 가지 모델은 SWOT(강점, 약점, 기회 및 위협)와 PESTLE(정치, 경제, 사회, 기술, 법률 및 환경) 모델입니다. 그런 다음 전략 계획서 등의 문서에 전략을 정의할 수 있습니다.
문서화된 사명서를 공표하기 전에 비전과 전략을 수용하는 채용자와 반대하는 이해 관계자로부터 비전과 전략에 대한 의견을 광범위하게 구하는 리더가 성공할 가능성이 더 높습니다. 특히 최종 계획에 반대자의 의견을 반영하는 경우 성공 가능성이 높습니다.

비즈니스 필수성 전파
비전과 전략을 발표할 때까지 전달을 미룰 필요는 없습니다. 그보다는 여러분이 직무를 맡은 날부터 전달을 시작해야 합니다. 하지만 비전과 전략을 공표하고 나면 내부 및 외부적으로 보다 공적인 역할을 수행해야 합니다. 처음에는 여러분이나 대리인이 직원, 분석가, 미디어, 파트너, 고객 및 고객 지지자 등 영향력 있는 그룹에게 비전을 전달해야 합니다. 여러분의 비전과 전략을 신뢰하도록 이들을 격려하고 의욕을 심어주며 전략이 회사와 관련자에게 최대 이익이 된다는 것을 설득력 있게 주장해야 합니다.
적당한 시점이 되면 전략의 개별 요소에 중점을 두어야 합니다. 또한 처음부터 끝까지 성공을 보여 주는 확실한 이정표를 세우고 전략상의 변화를 전달하며 회사나 업계에서 일반적으로 가지고 있는 당면 과제에 대해 솔직한 의견을 말하면서 이러한 관련자에게 주기적으로 새로운 정보를 제공해야 합니다.
각 관련자가 다양한 관심과 요구를 표현하는 것에 대비해야 합니다. 각 관련자의 특정 요구와 관심에 대해 논의해야 하겠지만 기본 비전과 전략의 일관성은 유지되어야 합니다. 이렇게 하면 다양한 관련자로부터 보다 효과적으로 지지를 이끌어 낼 수 있습니다.
충돌하는 "비즈니스 요구"를 관철시키려는 충동을 자제하여 다양한 관련자를 격려합니다. 이러한 충동을 자제하지 못하는 리더는 문제에 대한 신뢰성을 얻을 수 없습니다. 결과적으로 이러한 충동적 행동은 변화를 이끌어 내는 데 그다지 효과적이지 못하며, 최악의 경우에는 전체 회사의 신뢰성까지도 위험에 빠뜨릴 수 있습니다. 그림 1 메시지를 효과적으로 전달하기 위한 7가지 주요 포인트
그림 1 메시지 전달을 위한 7가지 주요 포인트
그림 1 메시지 전달을 위한 7가지 주요 포인트 (더 크게 보려면 이미지를 클릭하십시오.)

메시지 전달 관리
비전과 전략을 전달할 때 내부 및 외부 메시지 전달의 전문성과 무결성을 고려합니다. 환경 및 지속 가능성은 제품 개발, 서비스, 판매 및 마케팅과 관련되어 있는 만큼 기업의 사회적 책임과도 깊이 관련되어 있습니다. 조직에서 여러분에게 환경 지속 가능성을 위한 사회 참여 운동에 동참하는 직접적인 책임을 부여하지 않고 직무상으로 환경 리더의 역할을 배정했다고 해도 여러분은 사회 참여 운동 리더와 동일한 표준을 준수하며 직무를 수행해야 합니다.
환경 문제에 대한 외부 관련자의 지대한 관심과 환경을 고려한 비즈니스 수행에 대한 친밀감을 과소 평가해서는 안 됩니다. 특히, 무결성이 부족한 경우 또는 확언이 너무 많거나 너무 적은 경우 여러분의 의견을 분석할 수 있는 그들의 능력을 과소 평가해서는 안 됩니다. 그렇지 않으면 회사가 "그린워셔(greenwasher)"로 낙인 찍힐 수 있습니다.
따라서 적절한 커뮤니케이션 전략이 필요합니다. 여기에는 공개적인 입장을 표명하기 전에 내부 전문가의 의견을 듣는 검토 프로세스가 포함되어야 합니다. 커뮤니케이션 전략은 기업 환경 보고서, 메시지 전달 프레임워크, 공식 대변인 및 화제 등 메시지의 주요 요소로 이루어져야 합니다. 명확한 구조와 일관성을 갖추는 데 중요한 커뮤니케이션 전략은 비전과 전략을 개발한 후 곧바로 수립해야 합니다. 메시지 전달의 주요 책임자에게 개인적 책임을 부과하는 것이 도움이 될 수 있습니다.

측정을 통한 관리 강화
비전과 전략 범위 내에 속한 책임을 관리하는 것이 중요합니다. 운영, 제품 개발, 판매와 마케팅 등 목표 및 목적을 달성할 수 있는 여러분의 능력에 영향을 미치는 요인을 정의해야 합니다. 이러한 요인을 간결한 목록으로 구성하고 전체 전략 계획과 연결해야 합니다. 그런 다음 이러한 요인의 정성적 및/또는 정량적 기준을 세우고 향후 분석을 가능케 하는 추적 기준을 설정해야 합니다. 또한 이러한 기준을 적극적으로 관리해야 합니다.
이러한 추적 기준에 대한 보고 책임을 명확히 정의하고 모든 주요 이해 관계자가 참여하는 회의를 정기적으로 개최해야 합니다. 그러면 이해 관계자는 추적 기준을 요인과 연결하고 요인을 다시 전략 계획의 개별 요소에 연결함으로써 추적 기준이 전략 계획의 현 상태에 미치는 영향에 대해 논의할 수 있습니다.
안타깝게도 환경 리더가 속해 있는 조직 중 상당수가 이와 같은 추적 기준과 측정 도구를 지원할 준비가 되어 있지 않을 것입니다. 하지만 이러한 도구는 환경 및 지속 가능성 노력을 올바르게 분석하고 보고하는 데 필요한 정성적 및 정량적 데이터를 제공하기 위해 반드시 필요합니다. 따라서 비즈니스 프로세스 재설계, 공동 작업 및 측정 기술 배포, 사용자 지정된 내부 도구 개발을 통해 전문화된 측정 도구를 개발해야 합니다.
이러한 측정 도구에 대한 회사의 투자와 관련하여 고위 경영진의 지원이 없다면 아마도 추가 인원을 투입할 비용으로 우선 올바른 측정 도구를 개발해야 하는지 여부에 대한 심각한 비용-이익 결정을 내려야 할 것입니다.

환경적 영향 분석 및 보고
정성적 및 정량적 데이터 수집을 통해 심층적 분석이 가능해집니다. 이 분석은 이니셔티브가 얼마나 성공적인지, 그리고 본인의 활동이 회사와 기간 업무에 어떠한 영향을 미쳤는지 파악하려는 리더에게 대단히 중요합니다.
환경에 관련된 규정, 표준화, 법률 및 자발적인 기업 보고 풍토의 변화로 인해 환경 영향에 대한 상세 정보 발표에 대한 기업 압박이 점점 더 거세지고 있습니다. 관리, 측정 및 분석을 지원하기 위해 필요한 도구와 프로세스가 준비되어 있으면 필수 연례 보고서, 필수 보고 서류 및 자발적인 기업 지속 가능성 보고서에 필요한 정보를 보다 쉽게 수집할 수 있습니다. 따라서 현재 및 미래의 보고 요구 사항을 파악하는 것이 중요합니다. 그래야만 비즈니스 요구와 함께 성장할 통합 관리, 측정, 분석 및 보고 인프라 부분에 투자할 수 있습니다.
분석 및 보고 기술은 사고의 리더로 부상하고자 하는 회사에게는 매우 중요합니다. 소프트웨어(특히, 환경 관리, 프로세스 설계, 데이터 수집, 데이터 조작, 원격 감지, 공동 작업, 시각화 및 프레젠테이션에 사용되는 소프트웨어)는 이 부분에서 중요한 역할을 담당합니다.
상용 소프트웨어를 경우에 따라 환경 공간의 특정 용도에 맞게 사용자 지정해야 할 수도 있습니다. 따라서 통합된 관리, 측정, 분석 및 보고 인프라를 가능케 하려면 기술 부문에 대한 상당한 투자가 필요할 수도 있습니다.

사고의 리더 되기
사고의 리더는 모든 환경 리더의 목표입니다. 사고의 리더에는 다양한 유형이 있지만(그림 2의 예 참조) 모두 다음과 같은 공통점이 있습니다. 바로 이들의 전문성이 직함에서 비롯되는 것이 아니라 무결성과 개방성을 통해 변화를 이끌고 스스로 실천하는 데서 비롯된다는 것입니다.
그림 2 사고의 리더 유형
그림 2 사고의 리더 유형 (더 크게 보려면 이미지를 클릭하십시오.)
글로벌 환경 지속 가능성 에코시스템은 변화를 이끄는 사고의 리더에 의존하고 있습니다. 관영, 민간, 산업 및 소비자 보호 단체에 걸친 방대한 연락망을 보유하고 있는 사고의 리더는 이러한 영향력 있는 관계자와 연결하여 긴밀한 협력이 필요한 문제를 해결할 수 있습니다. 또한 사고의 리더는 글로벌 커뮤니티에서 우려하고 있는 새로운 환경 문제 중 상당 부분에 정통하며 이러한 문제를 전세계 관련자에게 알리는 선봉에 설 수 있습니다.
마지막으로 사고의 리더는 이제 막 업계의 광범위한 주목을 받기 시작한 중요한 문제에 대한 솔루션을 생각합니다. 이러한 솔루션을 개발하려면 경쟁자를 비롯하여 다른 사람에게 영향을 미치고 공동 작업을 수행해야 할 수도 있으며, 여러분의 회사를 아직 확실하지 않은 시장에 밀어넣을 수도 있지만, 대신에 결과적으로 사고의 리더는 글로벌 수준의 변화를 가져올 수 있습니다.

현실 주시
환경 문제는 근래에 부상하고 있는 분야로 전문적인 사항이 주기적으로 변경되고 있습니다. 지속적인 신뢰성을 유지하려면 다른 환경 리더가 장려한 다양한 과학, 정책, 법률, 경제, 기술 및 비즈니스 관점에 대한 학술적인 이해가 필요합니다. 또한 현재의 주도적인 의견을 따르기 보다는 환경 지속 가능성과 컴퓨팅에 대한 전문적인 이해에 기반을 둔 독자적인 시각을 개발하는 것이 바람직합니다. 이 무결성은 업계의 많은 환경 리더 또는 사고의 리더가 되고자 하는 사람을 구분하는 주요 요소입니다.
또한 확실한 리더는 관심 주제에 대한 특정 지식을 보유한 부하 직원에게 책임을 위임하며, 계약상 필요한 경우 회사 내 환경 정책의 고위 대표자의 의견을 안심하고 따라야 합니다. 상사와의 정기적인 회의와 보고를 통해 환경 지속 가능성에 대한 회사의 노력을 포괄적으로 파악할 수 있지만, 회사를 대변해 의견을 피력해야 하는 시점을 아는 것이 중요합니다. 그러기 위해서는 여러분의 기본 책무를 명확히 파악해야 하며, 여기에는 내부 및 외부 관련자가 기대하는 환경에 대한 신념을 지지하기 위해 여러분이 가져야 할 진정한 책임이 반영되어야 합니다.

Michael Walsh는 Microsoft의 수석 환경 제품 관리자입니다.
Eliza Walsh는 커뮤니케이션 전략 컨설턴트이며, 이전에는 Microsoft 중국 지사 커뮤니케이션 전문가로 근무한 경력이 있습니다.


Field Notes 화면 분할 공유
Kentaro Toyama

PC 액세스 확장 은 가능한 많은 사람이 PC를 사용할 수 있도록 하려는 Microsoft Research India의 훌륭한 목표로, 이 목표는 여러 개의 마우스를 사용하여 많은 사용자가 한 대의 PC와 상호 작용할 수 있도록 하는 프로그램인 MultiPoint(TechNet Magazine 2008년 5월호에 소개됨)를 통해 실현되었습니다.
화면 분할은 Microsoft Research India에서 착상해 낸 동시 공유 액세스 컴퓨팅의 또 다른 형태입니다. 이 프로그램은 단일 PC에 두 대의 키보드와 두 개의 마우스를 설치한 다음 터미널 서비스를 사용하여 모니터를 중간에서 분할합니다. 그러면 두 사람이 각각 개별적으로 선택한 소프트웨어와 별도의 OS 인스턴스를 실행하면서 모니터를 공유할 수 있습니다(research.microsoft.com/users/udaip/splitscreen.htm). 예를 들어, 한 사람이 스프레드시트 작업을 하는 동안 다른 한 사람은 워드 프로세싱 작업을 수행할 수 있습니다.
화면 분할을 설정하기 위해서는 Windows Server® 2003 내에서 실행되는 터미널 서버의 세 가지 개별 인스턴스를 사용합니다(현재 Windows Server 2008로 업그레이드 중임). 첫 번째 인스턴스는 컨테이너로, 모든 마우스 및 키보드 이벤트를 캡처하여 다시 배포합니다. 이 계층에서는 MultiPoint에 사용된 것과 동일한 기법이 사용되며, 모든 마우스 및 키보드 이벤트가 장치 ID와 함께 캡처됩니다. Windows®에서는 USB 장치가 연결될 때 고유 ID를 자동으로 할당합니다. 이러한 ID는 하드웨어 장치 고유의 ID는 아니지만 현재의 작업 인스턴스 내에서는 고유합니다. 이 정도면 두 마우스 클릭이 동일한 마우스에서 오는지 아니면 다른 마우스에서 오는지를 충분히 식별할 수 있습니다. 또한 이 컨테이너는 두 마우스 커서를 표시합니다.
이 컨테이너에서 각각 한 화면에 관련된 이벤트만을 받는 터미널 서버의 추가 인스턴스 두 개를 엽니다. 예를 들어, 기본 모드에서 ID x를 가진 마우스의 모든 마우스 이벤트는 왼쪽 화면 분할에서 받고 반면, ID y의 이벤트는 오른쪽 화면 분할에서 받습니다.
화면 분할 - 터미널 서비스를 사용하여 PC 모니터를 중간에서 분할
화면 분할 - 터미널 서비스를 사용하여 PC 모니터를 중간에서 분할 (더 크게 보려면 이미지를 클릭하십시오.)
어떤 이벤트가 어디에 속하는지 완벽히 제어하고 더 많은 고급 기능을 지원하려면 터미널 서버의 컨테이너 인스턴스가 있어야 합니다. 예를 들어, 오른쪽 커서를 왼쪽 화면으로 이동하여 단순히 가리키거나(아마도 자습서용으로) 다른 창과 상호 작용하도록 할 수 있습니다.
이 경우, 오른쪽 마우스 이벤트의 일부분이 왼쪽 화면으로 전달될 것입니다. 또한 Windows의 가상화 기술을 사용하여 비슷한 기능을 수행하는 것을 고려해 보았으나 비슷한 기능을 수행할 수는 있었지만 더 많은 리소스가 사용되었습니다.
연구자들은 사용자가 화면의 절반만 사용하는 것을 불편해 할 수도 있다고 우려했습니다. 우리는 저소득의 도시 젊은이들에게 컴퓨터 기초를 가르치는 Hope Foundation과 함께 인도의 방갈로르에서 연구를 수행했습니다. IT 교육을 위한 제한적인 작업이기는 했지만 학생들은 화면 분할 기능을 사용해도 단일 PC를 사용하여 학습할 때와 별 차이가 없는 것 같았습니다. 또한 인체 공학적 문제도 살펴보았지만, 14인치 화면에서도 별 문제가 없었습니다. 무엇보다도 IT 교육 센터는 동일한 수의 PC를 가지고 두 배의 학생들을 가르칠 수 있다는 점에 매우 기뻐했습니다.
Microsoft Research India는 화면 분할이 시장에 출시할 만한 기술인지 여부를 판단하기 위해 터미널 서비스 및 다른 Microsoft 그룹과 계속 논의 중입니다. 화면 분할이 여러분에게 필요한 기술이라고 생각되시면 이 기술을 어떤 상황에서 사용하고 싶으신지 저희에게 알려주십시오. splitscr@microsoft.com으로 전자 메일을 보내시면 됩니다.

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


Windows Confidential 가장 최악의 PC 2대
Raymond Chen

2007년 3월 , PCWorld에서 사상 최악의 PC 10종을 선정했을 때, 저는 최상위 두 컴퓨터에 주목하지 않을 수 없었습니다. 저희 회사에서 이 두 PC를 실제로 업무에 모두 사용했었기 때문입니다. "사용"이라는 단어는 엄청난 의미를 지니고 있습니다. 이 PC들은 Microsoft 사무실에서 컴퓨터의 수명 중 대부분을 소비했으므로 저는 이러한 컴퓨터를 눈앞에서 직접 목격했다고 말할 수 있습니다.
Mattel 브랜드 Barbie PC는 PC World 목록에서 두 번째 최악의 컴퓨터였습니다. 이 컴퓨터는 진부한 색상의 저가 컴퓨터치고는 상당히 기능이 향상된 편이었지만, 케이스, 모니터, 스피커에 분홍색 스티커를 붙여 장식할 수 있는 촌스러운 색상의 저가형 컴퓨터였습니다. 또한 Barbie 테마 소프트웨어가 미리 설치되어 제공되었습니다.
저희는 테스트 컴퓨터 중 하나로 이 컴퓨터를 구입했으며, 이 컴퓨터 앞에 하루 종일 붙어 있어야 하는 불쌍한 테스터는 컴퓨터를 "디자인 의도대로" 설치하기 위해 모든 스티커와 장식을 붙여 놓고는 쏟아지는 조롱을 인내심을 가지고 즐겨야 했습니다. 복도에서 훤히 보이는 테이블 위에 놓여져 있었으므로 복도를 지나가며 밝은 분홍색의 끔찍한 컴퓨터를 본 사람이면 누구나 다가와 한마디씩 하며 놀려댔습니다.
Barbie PC는 계속해서 우리에게 즐거움을 주었습니다. 이 컴퓨터에서 문제가 발생하여 개발자가 컴퓨터를 디버깅하기 위해 사무실을 방문해야 할 때마다 손봐야 할 컴퓨터가 뭔지 알고는 항상 화들짝 놀라는 시늉을 하거나 "끝내 주네요!"하는 농담을 던지곤 했습니다. 어느 여름에는 대학교 인턴 사원이 Barbie PC에 Windows Server®의 Datacenter Editon 사본을 설치했다가 시스템이 엉망이 되었다는 소리를 들었습니다.
1위의 영예를 안은, 보다 정확히 말하면 가장 치혹스러운 평가를 받은 컴퓨터는 Packard Bell PC였습니다. 지난 기억을 더듬어 볼 때 이 컴퓨터가 얼마나 잘 설계되었는지 보여 주는 단적인 예로, 즉시 사용 가능한 구성으로 각 확장 슬롯이 채워져 있었다는 점을 들 수 있습니다. 아마도 이 컴퓨터의 제조업체에서는 "우리 회사 컴퓨터는 너무 완벽해서 업그레이드할 필요가 없어!"라고 생각했겠죠.
Windows® 95 프로젝트 시절, 임원 중 한 분이 이 PC를 가정용 PC로 구입한 후 테스트 목적으로 Windows 95의 최신 빌드를 주기적으로 설치했습니다. 예상했듯이, 많은 문제가 발생하여 수시로 디버깅하러 이 PC를 가져오곤 했습니다.
Windows 95 프로젝트의 개발 관리자는 문제 해결을 위해 직접적이고 대담한 접근법을 사용하는 매우 똑똑한 사람이었습니다. 예를 들어, Windows 95가 다양한 응용 프로그램과 호환되는지 확인하기 위해 지역의 컴퓨터 상점으로 픽업 트럭을 몰고 가 상점 안에 있는 모든 PC 프로그램을 한 개씩 구입했습니다. 그리고 나서는 카페에 앉아 테이블에 소프트웨어를 올려놓고 Windows 95 프로젝트 팀원을 불러 소프트웨어를 두 개씩 나눠주면서, 나눠준 소프트웨어를 설치하여 실행한 후 제대로 작동하지 않을 경우 아무리 사소한 버그라도 모두 기록하도록 요청했습니다. 그 대신 그 소프트웨어는 팀원들이 가지도록 했습니다. 카페의 전경은 좋은 제품을 고르기 위해 테이블의 제품을 이리저리 뒤적이고 동료에게 흥분된 목소리로 어떤 제품을 골랐는지 묻는 모습이 마치 벼룩 시장 같았습니다.
그 임원이 자신의 가정용 컴퓨터를 디버깅하기 위해 너무 자주 방문하여 당혹스러워했던 Windows 95 프로젝트의 개발 관리자는 다시 한 번 직접적인 접근법을 사용했습니다. 지역의 컴퓨터 상점으로 가서 임원이 구입했던 것과 동일한 Packard Bell PC를 구입했죠.
이러한 두 컴퓨터가 존재한다는 사실만으로도 충분히 괴로운 일이었는데, 더욱 불행한 것은 두 번째 컴퓨터가 제게로 왔으며 이 PC에 Windows 95의 모든 새 빌드를 설치한 후 발생하는 문제를 모두 디버깅하는 업무를 제가 맡게 된 것이었습니다. 이렇게 하면 임원이 자신의 가정용 컴퓨터에 최신 빌드를 설치했을 때는 빌드에 아무런 문제도 없게 되는 것이죠.
지금까지 제 이야기를 제대로 이해하셨다면 이 계획에 문제가 있다는 사실을 이미 아셨을 것입니다. Packard Bell PC에는 여유 확장 슬롯이 전혀 없었으므로 네트워크 어댑터 카드를 설치할 곳이 없었습니다. 다른 특수한 방법을 사용하여 네트워크에 연결해야 했습니다. 전 정말이지 이 컴퓨터가 싫었습니다.

Raymond Chen은 자신의 웹 사이트인 The Old New Thing과 동제목의 서적에서 Windows의 역사와 Win32 프로그래밍에 대해 다루었습니다. Raymond가 회상하는 최악의 PC는 생각보다 우리에게 더 가까이 있습니다.