 TechNet Magazine June 2007

TechNet Magazine June 2007

Security : Windows Vista 사용자 계정 컨트롤 들여다보기

UAC(사용자 계정 컨트롤)는 가장 많이 오해를 받고 있는 Windows Vista의 새 기능 중 하나입니다. 하지만 사용자가 표준 사용자 권한으로 실행할 수 있도록 하려는 이 기능의 목표는 많은 보안 문제를 해결합니다. 여기에서는 UAC의 설계 목표를 자세히 살펴보고 이 새로운 기능의 작동 방식을 정확하게 알아보겠습니다.

Mark Russinovich Security: BitLocker 드라이브 암호화를 사용하여 데이터를 보호하기 위한 핵심 사항

BitLocker는 전체 볼륨 데이터를 암호화하는 기능과 Windows Vista가 시작되기 전에 초기 시작 구성 요소의 무결성을 검사하는 방법이라는 두 가지 매우 중요한 기능을 제공합니다. 이 문서에서는 BitLocker의 작동 방식 및 BitLocker를 통해 조직의 데이터를 보호하는 방법에 대해 간략하게 설명합니다.

Byron Hynes Security: Windows 방화벽 자세히 알아보기

모바일 기능이 널리 사용됨에 따라 컴퓨터 위협 요소는 물론 이러한 위험으로부터 컴퓨터를 보호하는 기술 역시 변화하고 있습니다. 네트워크 경계 바깥을 배회하던 랩톱이 네트워크로 다시 진입할 때는 시스템을 보호할 수 있는 보다 확실한 방법이 필요합니다. 여기서는 Windows 방화벽을 사용하여 인터넷 및 내부 네트워크에 연결되어 있는 컴퓨터를 보호할 수 있는 방법에 대해 살펴보도록 하겠습니다.

Steve Riley Security: 보안을 강화하는 Windows Vista의 새로운 ACL

Windows Vista에서 ACL 자체가 크게 변경된 것은 아니지만 Windows Vista 환경에서 ACL을 관리하려면 반드시 알고 있어야 할 중요한 많은 변경이 이루어졌습니다. 이 기사에서는 보안을 강화하기 위해 30개의 ACL이 어떻게 변경되었는지 살펴보고 이러한 변경이 조직에 어떤 영향을 주는지 알아본 다음 사용자 조직에서 이러한 변경을 관리하는 방법을 설명합니다.

Jesper Johansson Security: 그룹 정책을 통한 하드웨어 제한 관리

USB 디스크 키와 기타 이동식 장치는 개인적 삶은 편하게 해 주지만 직업적 삶은 어렵게 합니다. 보안 향상을 위해 사용자가 업무용 시스템에 설치하는 하드웨어 장치를 제어할 방법이 필요하기 때문입니다. 이제 그룹 정책을 사용하여 사용 가능한 장치와 사용 불가능한 장치를 제어할 수 있습니다.

Jeremy Moskowitz Security: 모든 IT 조직이 갖추어야 할 네 가지 보안 기술

많은 기업이 비슷한 보안 문제에 직면해 있습니다. 요즘과 같이 인터넷으로 연결된 환경에서 모든 조직은 네 가지 유형의 보안 도구를 반드시 갖추고 있어야 합니다. 이 문서에서는 먼저 이러한 도구를 소개한 다음 나중에 도구와 관련된 기술을 함께 사용하여 이상적인 보안 솔루션을 만드는 방법에 대해 살펴보겠습니다.

Matt Clapham and Todd Thompson Security: 인증 관리를 위한 새롭고 강력한 도구

인증서는 만료되면 인프라의 작동이 중단될 만큼 중요한 역할을 하는 인프라의 핵심 구성 요소입니다. 새로운 ILM-CM(Identity Lifecycle Manager Certificate Management) 솔루션은 Microsoft PKI 환경을 사용하는 조직에서 인증과 관련된 모든 작업을 원활하게 처리할 수 있도록 지원합니다. 이 문서에서는 ILM-CM으로 조직의 인증 프로세스를 개선하고 인증 관리 비용을 줄이는 방법에 대해 살펴보겠습니다.

Kevin Dallmann From The Editor: 보안 문제

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

Greg Steen SQL Q&A: 64비트 설치, 클러스터 메모리 할당 외

Edited by Nancy Michell Utility Spotlight: Windows Vista를 위한 스크립트 권한 상승 PowerToys

사용자 계정 컨트롤은 보안을 크게 강화하지만 특정 관리 작업과 기능을 수행하려면 권한 상승 기능이 필수적입니다. 여기서는 권한 상승을 더 유연하고 강력하게 수행할 수 있도록 하는 몇 가지 권한 상승 PowerToys를 소개합니다.

Michael Murgolo The Cable Guy: 보안 소켓 터널링 프로토콜

일부 구성에서는 Windows XP 및 Windows Server 2003의 VPN 프로토콜이 작동하지 않습니다. 이와 관련한 여러 가지 문제를 심도 있게 살펴보고 Windows Server "Longhorn" 및 Windows Vista 서비스 팩 1에서 보안 소켓 터널링 프로토콜을 사용하여 이러한 문제를 해결하는 방법을 알아봅니다.

Joseph Davies Windows Powershell: Active Directory 사용

Windows PowerShell은 Get-ADSIObject cmdlet을 제공하지는 않지만 다른 방법으로 여전히 강력한 ADSI 지원을 제공합니다. 이 기사에서는 형식 어댑터를 소개하고 Windows PowerShell을 사용하여 디렉터리 개체를 다루는 방법을 설명합니다.

Don Jones Hey, Scripting Guy!: 구불구불한 빨간 선 스크립팅

한 번에 한 단어씩 수동으로 추가하지 않고 Microsoft Word 사전에 용어를 쉽게 추가할 수 있는 간단한 방법을 찾고 계십니까? 아마 누구나 이런 방법을 알고 싶을 것입니다. 이번 달 Scripting Guy에서는 Microsoft Word에서 사용자 지정 사전을 만들고 이러한 사전을 사용하도록 Word를 프로그래밍 방식으로 구성하는 방법을 소개합니다.

The Microsoft Scripting Guys The Desktop Files: 데이터 보호 방법

중요한 데이터가 손실되는 사고는 믿을 수 없을 만큼 자주 발생합니다. 그러나 사용자가 데이터를 제대로 보호하기만 하면 이러한 정보 손실은 충분히 방지할 수 있습니다. 이러한 의미에서 조직의 데이터를 보호하기 위해 따라야 할 중요한 단계에 대해 알아보겠습니다.

Wes Miller Field Notes: 개발자와의 대화

개발자로 하여금 보다 관리가 용이한 응용 프로그램을 구축하도록 하는 것은 생각보다 쉽습니다. 가장 첫 단계는 바로 의견 교환입니다. 개발자는 소프트웨어를 보는 관점이 관리자와는 다릅니다. 하지만 관리자가 개발자와 대화를 통해 중요하게 생각하는 사항을 설명한다면 개발자는 그에 따라 보다 나은 코드를 설계할 수 있습니다.

David Aiken Windows Confidential: 시작 메뉴의 새로운 기능

새 컴퓨터를 구입하여 Windows를 실행한 다음 시작 단추를 클릭했을 때 빈 메뉴가 나타난다면 어떨지 상상해 보십시오. 컴퓨터를 한 번도 사용하지 않았을 때도 시작 메뉴에 자주 사용하는 응용 프로그램이 표시되는 데, 여기에는 다 그만한 이유가 있습니다. 바로 적절한 최초 사용 환경을 제공하기 위해서입니다. 이때 나타나는 응용 프로그램에 대해 알아보겠습니다.

Raymond Chen Letters: 질문에 대한 답변


 Security : Windows Vista 사용자 계정 컨트롤 들여다보기
Security Mark Russinovich

Windows Vista 사용자 계정 컨트롤 들여다보기
한 눈에 보기:
  • 표준 사용자로 실행
  • 파일 및 레지스트리 가상화
  • 계정 상태 권한 상승

Windows Vista의 UAC(사용자 계정 컨트롤) 기능은 오해를 받을 때가 많습니다. 3부로 구성된 Windows Vista 커널 변경에 대한 TechNet Magazine 기사에서는(technetmagazine.com) 별도의 기사로 다루는 것이 좋을 것으로 생각되어 UAC를 다루지 않았습니다.
이 기사에서는 UAC로 해결되는 문제를 설명하고 구성 요소 기술의 아키텍처와 구현을 설명합니다. 이러한 기술에는 이전에는 관리 권한이 필요했던 작업 리팩터링, 프로그램을 관리 권한 없이 올바르게 실행할 수 있도록 돕는 간단한 가상화, 프로그램이 관리 권한을 명시적으로 요청할 수 있도록 하는 기능, 같은 사용자 데스크톱에서 실행 중인 관리 권한 없는 프로세스와 관리 프로세스와의 격리 등이 포함됩니다.

UAC의 목표
UAC는 사용자가 관리 권한이 아닌 표준 사용자 권한으로 실행할 수 있도록 하는 것을 목표로 합니다. 관리 권한을 가진 사용자는 다른 사용자의 코드와 데이터를 비롯한 운영 체제의 모든 부분과 Windows® 자체를 읽고 수정할 수 있습니다. 관리 권한이 없는 경우 사용자는 시스템 설정을 실수로 또는 일부러 수정할 수 없고, 맬웨어는 시스템 보안 설정을 변경하거나 바이러스 백신 소프트웨어를 해제할 수 없으며, 공유 컴퓨터에서 다른 사용자의 중요한 정보를 침해할 수 없습니다. 따라서 표준 사용자 권한으로 실행하면 기업 환경에서 긴급한 기술 지원 요청이 줄어들고, 맬웨어의 영향이 완화되고, 가정용 컴퓨터가 더 원활하게 실행되며, 공유 컴퓨터의 중요한 데이터를 보호할 수 있습니다.
UAC는 표준 사용자 계정 실행이라는 목표를 현실화하기 위해 몇 가지 문제를 해결해야 했습니다. 먼저 Windows Vista™ 이전의 Windows 사용 모델에서는 기본적으로 관리 권한의 사용을 가정했습니다. 소프트웨어 개발자는 자신이 개발하는 프로그램이 파일, 레지스트리 키 또는 운영 체제 설정을 액세스하고 수정할 수 있다고 가정했습니다. Windows NT®에서 보안이 도입되고 관리 사용자 계정과 표준 사용자 계정이 구분된 뒤에도 설치 프로세스에서는 기본 제공 관리자 계정 또는 관리자 그룹의 구성원인 계정을 사용하도록 안내했습니다.
UAC가 해결해야 했던 두 번째 문제는 소프트웨어 설치, 시스템 시간 변경, 방화벽의 포트 열기 등과 같은 작업을 수행할 때는 사용자에게 관리 권한이 필요하다는 점이었습니다.
이 문제에 대한 UAC의 해결 방법은 대부분의 응용 프로그램을 표준 사용자 권한으로 실행하여 관리자 권한에 대한 필요성을 제거하고 소프트웨어 개발자에게 표준 사용자 권한으로 실행하는 응용 프로그램의 개발을 요청하는 것입니다. UAC는 관리 권한 요청의 필요성을 줄이고, 레거시 응용 프로그램이 표준 사용자 권한으로 실행되도록 하고, 필요할 때는 표준 사용자가 편리하게 관리 권한에 액세스하도록 하고, 관리 사용자라도 표준 사용자처럼 실행할 수 있도록 함으로써 이런 문제를 해결합니다.

표준 사용자로 실행
Windows Vista 개발 단계에서 모든 관리 작업을 감사한 결과 작업 중 많은 부분은 시스템 보안 침해 없이 표준 사용자용으로 설정할 수 있음이 밝혀졌습니다. 예를 들어 Windows XP 데스크톱 시스템에 표준 사용자 계정을 채택한 회사에서도 Windows XP에서는 표준 시간대 변경과 시스템 시간 변경이 구분되지 않는다는 이유 하나 때문에 관리자 그룹에서 모바일 사용자를 제거할 수 없었습니다. 랩톱 사용자가 여행할 때 약속 시간이 일정에 올바르게 표시되도록 하기 위해 현지 시간대를 구성하려면 "시스템 시간 변경" 권한(내부적으로는 SeSystemTimePrivilege)이 있어야 하는데 이 권한은 기본적으로 관리자에게만 부여되어 있습니다.
시간은 Kerberos와 같은 보안 프로토콜에 많이 사용되지만 표준 시간대는 시간이 표시되는 방식에만 영향을 주기 때문에 Windows Vista에서는 그림 1에서처럼 "표준 시간대 변경"(SeTimeZonePrivilege) 권한이 새롭게 추가되어 사용자 그룹에 할당되었습니다. 이를 통해 많은 회사에서 랩톱 사용자가 표준 사용자 계정으로 실행할 수 있게 되었습니다.
그림 1 "표준 시간대 변경" 권한
그림 1 "표준 시간대 변경" 권한
또한 Windows Vista에서는 표준 사용자가 무선 네트워크에 연결할 때 WEP 설정을 구성하고, VPN 연결을 만들고, 전원 관리 설정을 변경하고, 중요 Windows 업데이트를 설치할 수 있습니다. 이외에도 표준 사용자가 IT 관리자의 승인을 얻은 장치 드라이버와 프린터를 설치할 수 있도록 하고 관리자가 승인한 사이트의 ActiveX® 컨트롤을 설치할 수 있도록 하는 그룹 정책 설정도 추가되었습니다.
그렇다면 표준 계정에서 제대로 실행되지 않는 고객 응용 프로그램과 기간 업무(LOB) 응용 프로그램의 문제는 어떻게 해결할까요? 정식으로 관리 권한을 필요로 하는 소프트웨어도 있지만 대부분의 프로그램은 불필요하게 사용자 데이터를 시스템 전역 위치에 저장합니다. Microsoft에서는 관리 권한으로 실행되어야 하는 전역 응용 프로그램 설치 관리자는 %ProgramFiles% 디렉터리 아래에 디렉터리를 만들어서 여기에 응용 프로그램의 실행 파일과 보조 데이터를 저장하고 응용 프로그램 설정에 필요한 내용이 있으면 HKEY_LOCAL_MACHINE\Software 아래에 키를 만들도록 권장합니다. 응용 프로그램이 여러 사용자 계정으로 실행될 수 있으므로 사용자 고유 데이터는 사용자별 %AppData% 디렉터리에 저장하고 사용자별 설정은 HKEY_CURRENT_USER\ Software 아래의 사용자 레지스트리 프로필에 저장하도록 합니다. 표준 사용자 계정에는 %ProgramFiles% 디렉터리나 HKEY_LOCAL_MACHINE\Software에 대한 쓰기 액세스 권한이 없습니다. 그렇지만 Windows Vista 이전에는 대부분의 Windows 시스템이 단일 사용자 시스템이고 대부분의 사용자가 관리자였기 때문에 사용자 데이터와 설정을 지정된 위치에 올바르게 저장하지 않는 응용 프로그램도 정상적으로 작동했습니다.
Windows Vista에서는 파일 시스템 및 레지스트리 네임스페이스 가상화를 통해 이러한 레거시 응용 프로그램을 표준 사용자 계정으로 실행할 수 있습니다. 응용 프로그램이 파일 시스템이나 레지스트리의 시스템 전역 위치를 수정할 때 액세스 거부로 인해 작업이 실패하면 Windows는 작업을 사용자별 영역으로 리디렉션합니다. 응용 프로그램이 시스템 전역 위치에서 읽기 작업을 하면 Windows는 먼저 사용자별 영역에서 데이터를 확인하고 데이터가 없으면 전역 위치에서 읽기를 시도합니다.
이 가상화를 위해 Windows Vista에서는 프로세스가 64비트가 아니라 32비트이고, 관리 권한으로 실행되지 않으며, Windows Vista용으로 작성되었음을 나타내는 매니페스트 파일이 없으면 레거시 프로세스로 취급합니다. 네트워크 파일 공유 액세스를 포함하여 이 정의에 따라 레거시로 분류된 프로세스에서 수행된 작업이 아닌 경우에는 가상화되지 않습니다. 프로세스의 가상화 상태는 토큰에 플래그로 저장됩니다. 이 토큰은 사용자 계정, 그룹 구성원 자격 및 권한을 포함하여 프로세스의 보안 컨텍스트를 추적하는 커널 데이터 구조입니다.
작업 관리자의 프로세스 페이지에 가상화 열을 추가하면 프로세스의 가상화 상태를 볼 수 있습니다. 그림 2에서 바탕 화면 창 관리자(Dwm .exe), 클라이언트 서버 런타임 하위 시스템(Csrss.exe) 및 탐색기를 비롯한 대부분의 Windows Vista 구성 요소를 볼 수 있습니다. 이들 구성 요소는 Windows Vista 매니페스트가 있기 때문에 가상화가 해제되었거나, 관리 권한으로 실행되기 때문에 가상화가 허용되지 않습니다. Internet Explorer®(iexplore.exe)의 경우에는 표준 사용자 권한으로 올바르게 작동하도록 작성되지 않은 것으로 간주해야 하는 여러 ActiveX 컨트롤과 스크립트를 호스팅할 수 있으므로 가상화가 사용됩니다.
그림 2 가상화 상태가 표시된 작업 관리자
그림 2 가상화 상태가 표시된 작업 관리자
레거시 프로세스를 위해 가상화되는 파일 시스템 위치는 몇 개의 특정 하위 디렉터리를 제외한 %ProgramFiles%, %ProgramData% 및 %SystemRoot%입니다. 하지만 .exe, .bat, .scr, .vbs 등을 포함하여 실행 가능한 확장명이 있는 모든 파일은 가상화에서 제외됩니다. 즉, 표준 사용자 계정에서 직접 업데이트되는 프로그램은 전역 업데이트 관리자를 실행하는 관리자에게 보이지 않는 전용 버전의 실행 파일을 만들지 못하고 실패합니다. 제외 목록에 다른 확장명을 추가하려면 다음 레지스트리 키에 이를 추가하고 다시 부팅합니다.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd
다중 문자열 유형을 사용하여 여러 확장명을 구분하고 확장명 이름 앞에 점을 추가하지 마십시오.
레거시 프로세스에서 가상화된 디렉터리에 대해 수정 작업을 수행하면 사용자의 가상 루트 디렉터리인 %LocalAppData%\VirtualStore로 리디렉션됩니다. 예를 들어 필자의 시스템에서 실행 중인 가상화된 프로세스는 C:\Windows\Application.ini를 생성하지만 실제로 이 파일은 C:\Users\Markruss\AppData\Local\VirtualStore\Windows\Application.ini에 생성됩니다. 경로 중 Local 부분은 계정에 로밍 프로필이 있을 때 가상화된 파일이 프로필의 나머지 부분과 함께 로밍되지 않는다는 점을 보여 줍니다.
탐색기에서 가상화된 파일이 있는 디렉터리로 이동하면 그림 3에서처럼 탐색기 도구 모음에 호환성 파일이라는 단추가 표시됩니다. 이 단추를 클릭하면 해당하는 VirtualStore 하위 디렉터리로 이동하여 가상화된 파일이 표시됩니다.
그림 3 가상화된 파일이 있음을 나타내는 호환성 파일 단추
그림 3 가상화된 파일이 있음을 나타내는 호환성 파일 단추
그림 4에서는 UAC 파일 가상화 필터 드라이버(%SystemRoot%\System32\Drivers\Luafv.sys)가 파일 시스템 가상화를 구현하는 방식을 보여 줍니다. 파일 시스템 필터 드라이버이기 때문에 모든 파일 시스템 작업을 감시할 수 있지만 레거시 프로세스의 작업에 대한 기능만 구현합니다. 시스템 전역 위치에 파일을 생성하는 레거시 프로세스의 대상 파일 경로를 변경하지만 Windows Vista 응용 프로그램을 표준 사용자 권한으로 실행하는 프로세스에 대해서는 변경 작업을 수행하지 않습니다. 레거시 프로세스는 사용자가 완전히 액세스할 수 있는 위치에 파일을 실제로 생성하면 작업이 성공한 것으로 간주하지만 \Windows 디렉터리의 기본 사용 권한은 Windows Vista 용으로 작성된 응용 프로그램에 대한 액세스를 거부합니다.
그림 4 파일 시스템 가상화
그림 4 파일 시스템 가상화
레지스트리 가상화는 파일 시스템 가상화와는 약간 다르게 구현됩니다. 대부분의 HKEY_LOCAL_MACHINE\Software 분기가 가상화된 레지스트리 키에 포함되지만 다음과 같은 예외가 많이 존재합니다.
HKLM\Software\Microsoft\Windows
HKLM\Software\Microsoft\Windows NT
HKLM\Software\Classes
레거시 응용 프로그램에 의해 수정되지만 호환성이나 상호 운용성 문제를 일으키지 않는 키만 가상화됩니다. Windows는 레거시 응용 프로그램이 가상화된 키를 수정하는 경우 HKEY_ CURRENT_USER\Software\Classes\VirtualStore에 있는 사용자의 레지스트리 가상 루트로 리디렉션합니다. 키는 사용자의 Classes 하이브인 %LocalAppData%\Microsoft\Windows\UsrClass.dat에 위치하며 이 하이브는 다른 가상화된 파일 데이터와 마찬가지로 로밍 사용자 프로필과 함께 로밍되지 않습니다.
Windows에서 파일 시스템에 대해 작성하는 것처럼 고정된 가상화된 위치 목록을 작성하는 대신 키의 가상화 상태는 키 자체에 REG_ KEY_DONT_VIRTUALIZE 플래그로 저장됩니다. Reg.exe 유틸리티를 사용하면 그림 5에서처럼 이 플래그와 다른 가상화 관련 플래그인 REG_KEY_ DONT_SILENT_FAIL 및 REG_KEY_ RECURSE_FLAG를 볼 수 있습니다. REG_KEY_DONT_SILENT_FAIL이 설정되었고 키가 가상화되지 않은 경우(REG_KEY_DONT_VIRTUALIZE가 설정됨) 키에 대한 작업을 수행하기 위한 액세스가 거부되던 레거시 응용 프로그램에는 응용 프로그램이 요청한 권한이 아니라 사용자가 키에 대해 가진 모든 액세스 권한이 부여됩니다. REG_KEY_RECURSE_FLAG는 새 하위 키가 기본 플래그 대신 부모 키의 가상화 플래그를 상속하는지 여부를 나타냅니다.
그림 5 가상화 플래그를 표시하는 Reg 유틸리티
그림 5 가상화 플래그를 표시하는 Reg 유틸리티
그림 6은 운영 체제 커널 Ntoskrnl.exe의 레지스트리를 관리하는 구성 관리자가 레지스트리 가상화를 구현하는 방식을 보여 줍니다. 파일 시스템 가상화와 마찬가지로 가상화된 키의 하위 키를 생성하는 레거시 프로세스는 사용자의 레지스트리 가상 루트로 리디렉션되지만 Windows Vista 프로세스는 기본 사용 권한에 의해 액세스가 거부됩니다.
일부 응용 프로그램의 경우에는 파일 시스템과 레지스트리 가상화 이외의 추가적인 지원이 있어야 표준 사용자 권한으로 올바르게 실행할 수 있습니다. 예를 들어 계정이 관리자 그룹의 구성원 자격으로 실행되는지 테스트하는 응용 프로그램은 해당 그룹에 있지 않으면 실행되지 않습니다. 따라서 Windows Vista에서는 이러한 응용 프로그램이 작동할 수 있도록 여러 가지 응용 프로그램 호환성 shim을 정의합니다. shim은 대개의 경우 그림 7에 표시된 것처럼 표준 권한의 작업을 위해 레거시 응용 프로그램에 적용됩니다. 회사 IT 전문가는 ACT(Application Compatibility Toolkit, technet.microsoft.com/windowsvista/aa905066.aspx에서 구할 수 있음) 도구와 SUA(Standard User Analyzer) 유틸리티 또는 Aaron Margosis의 LUA Buglight를 사용하여 LOB 응용 프로그램의 shim 요구 사항을 확인할 수 있습니다. ACT의 구성 요소인 Compatibility Administrator를 사용하여 응용 프로그램에 shim을 할당한 다음 생성된 호환성 데이터베이스(.sdb 파일)를 그룹 정책을 통해 데스크톱에 배포합니다. 필요한 경우 로컬 보안 정책 설정을 사용하여 시스템에서 가상화를 완전히 해제할 수 있습니다.
Figure 7 자주 사용되는 사용자 shim (Close Figure 7)

Shim | 용도
ElevateCreateProcess | 응용 프로그램 정보 서비스를 호출해 권한 상승을 묻는 메시지를 표시하도록 하여 ERROR_ELEVATION_REQUIRED 오류를 처리하도록 CreateProcess를 변경합니다.
ForceAdminAccess | 관리자 그룹 구성원 자격의 쿼리를 스푸핑합니다.
VirtualizeDeleteFile | 전역 파일 및 디렉터리의 성공적 삭제를 스푸핑합니다.
LocalMappedObject | 전역 섹션 개체를 사용자의 네임스페이스로 지정합니다.
VirtualizeHKCRLite, VirtualizeRegisterTypeLib | COM 개체의 전역 등록을 사용자별 위치로 리디렉션합니다.
가상화의 효과
작업 관리자에서 마우스 오른쪽 단추를 클릭하면 나타나는 상황에 맞는 메뉴에서 가상화를 선택하면 프로세스의 가상화 상태를 변경할 수 있습니다. 그림 A에서는 가상화 상태가 변경될 때 명령 프롬프트의 동작을 보여 줍니다. 우선 Windows Vista 매니페스트가 있기 때문에 가상화가 해제된 상태로 시작됩니다. 표준 사용자 권한으로 실행되기 때문에 \Windows 디렉터리에 파일을 만들 수 없지만 작업 관리자로 가상화된 뒤에는 파일을 성공적으로 만든 것으로 나타납니다. 가상화가 해제된 상태로 돌아가면 실제로는 사용자의 가상 저장소에 있는 파일을 찾을 수 없게 됩니다.
그림 A 가상화 상태 변경
그림 A 가상화 상태 변경

관리자 승인 모드
표준 사용자 권한으로 사용할 수 있는 프로그램만 실행하더라도 일부 작업에는 여전히 관리 권한이 필요합니다. 대부분의 소프트웨어 설치 작업은 시스템 전역 위치에 디렉터리와 레지스트리 키를 만들거나 서비스 또는 장치 드라이버를 설치하기 위해 관리 권한을 필요로 합니다. 시스템 전역 Windows 및 응용 프로그램 설정을 수정할 때는 Windows Vista 자녀 보호 기능처럼 관리 권한이 필요합니다. 이러한 작업 대부분은 전용 관리 계정으로 전환하여 수행할 수도 있지만 불편하기 때문에 대부분의 사용자가 일반적인 작업을 수행할 때도 관리 계정을 계속 사용할 가능성이 커집니다.
따라서 Windows Vista에는 표준 사용자가 편리하게 관리 권한으로 프로세스를 실행할 수 있도록 하는 "다른 계정으로 실행" 기능이 포함되어 있습니다. 이 기능을 사용하려면 해당 응용 프로그램은 필요에 따라 응용 프로그램 대신 시스템이 관리 권한을 가져올 수 있는 작업을 식별할 수 있어야 합니다. 이에 대해 뒤에서 간략하게 설명하겠습니다.
또한 시스템 관리자 역할을 수행하는 사용자가 표준 사용자 권한으로 실행하되 관리 권한이 필요할 때마다 사용자 이름과 암호를 입력할 필요가 없도록 하기 위해 Windows Vista에는 AAM(관리자 승인 모드) 기능이 도입되었습니다. 이 기능은 로그온 시 사용자에 대해 표준 사용자 권한을 가진 ID와 관리 권한을 가진 ID를 만듭니다. Windows Vista 시스템의 모든 사용자는 표준 사용자이거나 AAM에서 대부분 표준 사용자로 실행되기 때문에 개발자는 모든 Windows 사용자가 표준 사용자인 것으로 가정해야 합니다. 따라서 가상화나 shim 없이 표준 사용자 권한으로 작동하는 프로그램이 많아질 것입니다.
프로세스에 관리 권한을 부여하는 것을 권한 상승이라고 합니다. 표준 사용자 계정에 의해 수행될 때는 관리자 그룹의 구성원인 계정에 대한 자격 증명을 입력해야 하며 이 과정은 마치 다른 사용자가 표준 사용자의 어깨 너머에서 입력하는 것과 같은 방식으로 처리되기 때문에 이를 OTS(Over the Shoulder) 권한 상승이라고 합니다. AAM 사용자가 권한 상승을 수행할 때는 사용자가 관리 권한의 할당을 승인하기만 하면 되므로 승인(Consent) 권한 상승이라고 합니다.
Windows Vista에서는 사용자가 그림 8에 나열된 관리자 유형의 그룹 중 하나의 구성원인 경우에는 관리자로 간주합니다. 나열된 그룹 중 대다수는 도메인에 가입되어 있는 시스템에서만 사용되며 사용자에게 로컬 관리 권한을 직접 부여하지 않지만 도메인 전체에 적용되는 설정의 수정을 허용합니다. 사용자가 이러한 그룹 중 하나의 구성원이지만 실제 관리자 그룹에 속한 것은 아닌 경우 사용자는 승인 권한 상승 대신 OTS 권한 상승을 통해 자신의 관리 권한에 액세스합니다.
Figure 8 관리 그룹 (Close Figure 8)

기본 제공 Administrators
Certificate Administrators
Domain Administrators
Enterprise Administrators
Policy Administrators
Schema Administrators
Domain Controllers
Enterprise Read-Only Domain Controllers
Read-Only Domain Controllers
Account Operators
Backup Operators
Cryptographic Operators
Network Configuration Operators
Print Operators
System Operators
RAS Servers
Power Users
Pre-Windows 2000 Compatible Access
나열된 그룹 중 하나에 속한 사용자가 로그온하면 Windows Vista는 사용자 관리 ID의 표준 사용자 버전을 나타내는 토큰을 생성합니다. 새 토큰에서는 그림 9에 나열된 기본 표준 사용자 권한을 제외한 해당 사용자에게 할당된 모든 권한이 제거됩니다. 또한 새 토큰에서 모든 관리자 유형 그룹은 USE_FOR_DENY_ONLY 플래그로 표시됩니다. 그림 10에서는 microsoft.com/technet/sysinternals에서 다운로드할 수 있는 프로세스 관리 도구인 Sysinternals Process Explorer를 볼 수 있습니다. 이 도구의 왼쪽에는 관리 권한으로 실행되는 프로세스의 그룹 구성원과 권한이, 오른쪽에는 관리 권한 없이 실행되는 프로세스의 그룹 구성원과 권한이 표시됩니다. 부주의한 사용을 방지하기 위한 Windows 보안 모델에 따라 해제된 플래그가 있는 권한을 사용하려면 다시 설정해야 합니다.
Figure 9 표준 사용자 권한 (Close Figure 9)

이름 | 내부 이름
트래버스 검사 무시 | SeChangeNotifyPrivilege
시스템 종료 | SeShutdownPrivilege
도킹 스테이션에서 컴퓨터 제거 | SeUndockPrivilege
프로세스 작업 집합 향상 | SeIncreaseWorkingSetPrivilege
표준 시간대 변경 | SeTimeZonePrivilege
그림 10 AAM 관리자 및 표준 사용자 토큰
그림 10 AAM 관리자 및 표준 사용자 토큰
deny-only 플래그가 있는 그룹은 리소스에 대한 사용자 액세스를 거부하고 허용하지 않을 때만 사용하여 그룹을 함께 제거했을 때 생길 수 있는 보안 공백을 메울 수 있습니다. 예를 들어 관리자 그룹의 모든 액세스는 거부하지만 사용자가 속한 다른 그룹에 대한 액세스는 일부 허용하는 ACL(액세스 제어 목록)이 파일에 있는 경우, 관리자 그룹이 토큰에 없으면 사용자에게 액세스 권한이 부여되어 사용자 ID의 표준 사용자 버전이 관리자 ID보다 많은 액세스 권한을 가지게 됩니다.
일반적인 가정용 컴퓨터와 같은 독립 실행형 시스템과 도메인에 가입되어 있는 시스템은 원격 사용자에 의한 AAM 액세스를 각기 다른 방식으로 처리합니다. 도메인 연결 컴퓨터는 리소스 사용 권한에 도메인 관리 그룹을 사용할 수 있기 때문입니다. 사용자가 독립 실행형 컴퓨터의 파일 공유 위치에 액세스할 때 Windows는 원격 사용자의 표준 사용자 ID를 요청하지만 도메인에 가입되어 있는 시스템의 경우에는 Windows는 사용자의 관리 ID를 요청하여 사용자의 모든 도메인 그룹 구성원 자격을 그대로 사용합니다.

관리 권한에 편리하게 액세스
시스템과 응용 프로그램이 관리 권한의 필요성을 파악하는 방법에는 여러 가지가 있습니다. 그 중 한 가지는 탐색기 UI에 나타나는 "관리자 권한으로 실행" 상황에 맞는 메뉴 항목과 바로 가기 옵션입니다. 이 항목에는 선택했을 때 권한이 상승되는 모든 단추나 메뉴 항목에 나타나는 컬러 방패 모양 아이콘이 표시됩니다. "관리자 권한으로 실행"을 선택하면 탐색기가 "runas" 명령으로 ShellExecute API를 호출합니다.
대부분의 설치 프로그램에는 관리 권한이 필요하므로 실행 파일의 시작을 초기화하는 이미지 로더에는 레거시 설치 프로그램을 식별하기 위한 설치 프로그램 감지 코드가 포함되어 있습니다. 이러한 감지 방법 중에는 이미지의 파일 이름이나 내부 버전 정보에 setup, install 또는 update 등의 단어가 있는지 확인하는 간단한 방식도 있고, 실행 파일에서 타사 설치 래퍼 유틸리티에 많이 사용되는 바이트 시퀀스를 검사하는 정교한 방식도 있습니다.
또한 이미지 로더는 응용 프로그램 호환성(appcompat) 라이브러리를 호출하여 대상 실행 파일이 관리자 권한을 필요로 하는지 확인합니다. 라이브러리는 응용 프로그램 호환성 데이터베이스를 조회하여 실행 파일에 RequireAdministrator 또는 RunAsInvoker 호환성 플래그가 연결되어 있는지 확인합니다.
실행 파일이 관리 권한을 요청하기 위해 가장 많이 사용하는 방법은 응용 프로그램 매니페스트 파일에 requestedElevationLevel 태그를 포함하는 방법입니다. 매니페스트는 이미지에 대한 보충 정보가 포함된 XML 파일입니다. 이 파일은 Windows XP에서 side-by-side DLL 및 Microsoft .NET Framework 어셈블리에 대한 종속성을 식별하는 방법으로 도입되었습니다. Firewallsettings.exe에서 추출된 아래의 문자열 덤프에서 볼 수 있는 것처럼 매니페스트에 trustInfo 요소가 있으면 해당 실행 파일이 Windows Vista용으로 작성되었으며 requestedElevationLevel 요소가 중첩되어 있음을 의미합니다. 요소의 level 특성은 asInvoker, highestAvailable 및 requireAdministrator의 세 값 중 하나일 수 있습니다.
<trustInfo
 xmlns="urn:schema-microsoft-com:asm.v3">
 <security>
  <requestedPrivileges>
   <requestedExecutionLevel
    Level="requireAdministrator"
    uiAccess="false"/>
  </requestedPrivileges>
 </security>
</trustInfo>
Notepad.exe처럼 관리 권한이 필요 없는 실행 파일은 asInvoker 값을 지정합니다. 일부 실행 파일은 관리자에게 항상 액세스 권한이 최대로 필요한 것으로 간주하므로 이런 파일은 highestAvailable 값을 사용합니다. 사용자가 이 값을 가진 실행 파일을 실행하면 해당 사용자가 AAM에서 실행 중이거나 이전에 정의된 규칙에 따라 관리자로 간주되는 경우에만 권한 상승을 묻는 메시지가 나타나며, 관리 권한에 액세스하려면 권한을 상승해야 합니다. highestAvailable을 사용하는 응용 프로그램에는 Regedit.exe, Mmc.exe 및 Eventvwr.exe 등이 있습니다. 마지막으로 requireAdministrator는 항상 권한 상승 요청을 하며 관리 권한이 없이 작동하면 실패하는 모든 실행 파일에 사용됩니다.
내게 필요한 옵션 지원 응용 프로그램은 권한이 상승된 프로세스의 창 입력을 위해 uiAccess 속성에 "true"를 지정하며 서명이 되어 있어야 하고 %SystemRoot% 및 %ProgramFiles%를 포함한 몇 개의 보안 위치 중 하나에 있어야 해당 기능을 수행할 수 있습니다.
다음과 같이 Sysinternals Sigcheck 유틸리티로 매니페스트를 확인하면 실행 파일에 의해 지정된 값을 쉽게 알아낼 수 있습니다.
sigcheck –m <executable>
관리 권한을 필요로 하는 이미지를 실행하면 서비스 호스트 프로세스(%SystemRoot%\System32\Svchost .exe) 내에서 실행되는 AIS(응용 프로그램 정보 서비스, %SystemRoot%\System32\Appinfo.dll에 포함됨)가 Consent.exe(%SystemRoot%\System32\Consent.exe)를 시작합니다. Consent는 화면의 비트맵을 캡처하여 페이드 효과를 적용하고 로컬 시스템 계정에만 액세스할 수 있는 데스크톱으로 전환한 다음 비트맵을 배경으로 칠하고 실행 파일에 대한 정보가 포함된 권한 상승 대화 상자를 표시합니다. 별도의 데스크톱에 표시함으로써 사용자 계정에 있을 수 있는 맬웨어가 대화 상자의 모양을 수정하는 것을 방지할 수 있습니다.
그림 11 OTS 권한 상승 대화 상자
그림 11 OTS 권한 상승 대화 상자
이미지가 Microsoft에서 디지털 서명한 Windows 구성 요소이며 이미지가 Windows 시스템 디렉터리에 있으면 그림 11의 맨 위에서 볼 수 있는 것처럼 대화 상자 상단에 파란색 막대가 표시됩니다. 가운데 대화 상자의 회색 막대는 Microsoft 이외의 누군가에 의해 디지털 서명된 이미지를, 맨 아래 대화 상자의 주황색 막대는 서명되지 않은 이미지를 나타냅니다. 권한 상승 대화 상자에는 이미지의 아이콘, 설명 및 디지털 서명된 이미지의 게시자가 표시되지만 서명되지 않은 이미지의 경우에는 일반 아이콘, 파일 이름 및 "알 수 없는 게시자"가 표시됩니다. 이 때문에 맬웨어는 정상 소프트웨어의 모양을 흉내내기가 어려워집니다. 대화 상자 아래쪽의 Details(세부 정보) 단추를 클릭하면 실행될 때 실행 파일에 전달될 명령줄이 표시됩니다. 그림 12의 AAM Consent(AAM 승인) 대화 상자도 비슷한 기능을 제공하지만 관리자 자격 증명을 묻는 대신 계속 및 취소 단추를 제공합니다.
그림 12 AAM 권한 상승 대화 상자
그림 12 AAM 권한 상승 대화 상자
사용자가 권한 상승을 거부하면 Windows는 실행을 시작한 프로세스에 액세스 거부 오류를 반환합니다. 사용자가 관리자 자격 증명을 입력하거나 계속을 클릭하여 권한 상승에 동의하면 AIS는 CreateProcessAsUser를 호출하여 적절한 관리 ID로 프로세스를 시작합니다. 기술적으로 보면 AIS는 권한 상승된 프로세스의 부모지만, AIS는 프로세스의 부모 프로세스 ID를 해당 프로세스를 원래 시작한 프로세스의 ID로 설정하는 CreateProcessAsUser API의 새로운 기능을 사용합니다(그림 13 참조). 이런 이유 때문에 프로세스 트리가 표시되는 Process Explorer와 같은 도구에서 권한 상승된 프로세스가 AIS 서비스 호스팅 프로세스의 자식으로 나타나지 않습니다.
그림 13 권한 상승 흐름
그림 13 권한 상승 흐름
권한 상승 대화 상자가 별도의 보안 데스크톱에 표시되기는 하지만 사용자는 기본적으로 현재 표시된 대화 상자가 정상적이며 맬웨어가 표시한 대화 상자가 아니라는 것을 확인할 방법이 없습니다. 맬웨어는 가짜 승인 대화 상자로 관리 권한을 얻을 수 없기 때문에 AAM에 있어서 이는 문제가 아닙니다. 하지만 맬웨어가 표준 사용자의 OTS 권한 상승을 기다렸다 이를 가로채 트로이 목마 대화 상자를 사용하여 관리자 자격 증명을 확보하는 것은 가능하므로 이렇게 확보한 자격 증명으로 관리자의 계정에 액세스하여 감염시킬 수도 있습니다.
이런 이유 때문에 회사 환경에서는 OTS 권한 상승을 사용하지 말 것을 강력하게 권장합니다. OTS 권한 상승 기능을 사용하지 않으려면(그래서 지원 부서 호출을 줄이려면), 로컬 보안 정책 편집기(Secpol.msc)를 실행하고 "사용자 계정 컨트롤: 표준 사용자 계정일 때 권한 상승 확인 방법"을 "권한 상승 요청 자동으로 거부"로 구성합니다.
보안의 중요성을 알고 있는 가정용 컴퓨터의 사용자는 OTS 권한 상승에서 맬웨어가 가로채거나 시뮬레이션하지 못하는 SAS(Secure Attention Sequence)를 사용하도록 구성해야 합니다. SAS를 구성하려면 그룹 정책 편집기(Gpedit.msc)를 실행하고 컴퓨터 구성 | 관리 템플릿 | Windows 구성 요소 | 자격 증명 사용자 인터페이스로 이동하여 "자격 증명 입력 시 신뢰할 수 있는 경로를 요구합니다."를 설정합니다. 이제부터 권한 상승 대화 상자에 액세스하려면 Ctrl+Alt+Delete를 눌러야 합니다.

권한 상승된 프로세스 격리
Windows Vista에서는 권한 상승된 프로세스 주위에 경계를 설정하여 같은 데스크톱에서 표준 사용자 권한으로 실행되는 맬웨어로부터 보호합니다. 경계가 없으면 맬웨어는 창 메시지를 통한 창 입력과 마우스 입력을 함께 전송하여 관리 응용 프로그램을 구동할 수 있습니다. 또한 표준 Windows 보안 모델에 의해 표준 사용자 권한으로 프로세스에서 실행 중인 맬웨어가 다른 사용자로 실행 중인 권한 상승된 프로세스를 변경하는 것이 방지되기는 하지만, 관리 사용자의 표준 권한 버전으로 실행 중인 맬웨어가 사용자의 권한 상승된 프로세스를 열고 코드를 삽입하고 여기에서 스레드를 시작하여 삽입된 코드를 실행하는 것을 막을 수는 없습니다.
창 메시지에 대한 Windows Vista의 방어 기능을 UIPI(User Interface Privilege Isolation)라고 합니다. 이 기능은 Windows Vista가 권한 상승된 프로세스 주위의 경계로 이용하는 새로운 Windows 무결성 메커니즘을 기반으로 합니다. 이 새로운 보안 모델에서는 모든 프로세스와 개체에 무결성 수준이 있으며 개체의 무결성 정책에 따라 Windows DAC(Discretionary Access Control) 보안 모델에서 프로세스에 부여할 수 있는 액세스 권한이 제한될 수 있습니다.
무결성 수준(IL)은 사용자와 그룹도 표시하는 보안 ID(SID)로 표현됩니다. 이 보안 ID에서는 무결성 수준이 SID의 관련 ID(RID)에 인코딩됩니다. 그림 14에서는 네 개의 기본 IL에 대한 SID의 RID의 표시 이름, SID 및 16진수 버전을 볼 수 있습니다. 16진수 숫자는 향후 확장 가능성과 UI 내게 필요한 옵션 지원 응용 프로그램에서 사용할 때에 대비하여 중간 수준을 사용할 수 있도록 각 수준 간 간격이 0x1000으로 유지됩니다.
Figure 14 기본 무결성 수준 (Close Figure 14)

이름 | SID | RID
낮은 필수 수준 | S-1-16-4096 | 0x1000
중간 필수 수준 | S-1-16-8192 | 0x2000
높은 필수 수준 | S-1-16-12288 | 0x3000
시스템 필수 수준 | S-1-16-16384 | 0x4000
그림 15에서는 개체 IL 정책과 각 정책이 제한하는 액세스 유형(개체에 대해 정의된 일반 액세스에 해당됨)을 나열합니다. 예를 들어 No-Write-Up은 IL이 낮은 프로세스가 GENERIC_WRITE 액세스로 표시되는 액세스 권한을 얻지 못하도록 합니다. 파일 및 레지스트리 키를 포함하여 대부분 개체의 기본 정책은 No-Write-Up이며 이 정책은 개체의 DACL(임의 액세스 제어 목록)이 사용자에게 해당 액세스를 허용하더라도 프로세스가 자신보다 IL이 높은 개체에 대한 쓰기 액세스 권한을 얻지 못하도록 합니다. 다른 정책을 가지는 유일한 개체는 프로세스 및 스레드 개체입니다. 이 두 개체의 정책인 No-Write-Up 및 No-Read-Up은 낮은 IL로 실행 중인 프로세스가 높은 IL을 갖는 프로세스에 코드를 삽입하고 암호와 같은 데이터를 읽지 못하도록 합니다.
Figure 15 무결성 수준 정책 (Close Figure 15)

정책 | 효과
No-Write-Up | 낮은 IL 프로세스가 높은 IL 개체를 수정할 수 없음
No-Read-Up | 낮은 IL 프로세스가 높은 IL 개체에서 읽을 수 없음
No-Execute-Up | 낮은 IL 프로세스가 높은 IL 개체를 실행할 수 없음
Windows는 모든 프로세스에 IL을 할당하며 이 IL은 프로세스를 실행하는 사용자가 속하는 그룹의 SID와 함께 프로세스 토큰에 저장됩니다. 그림 16에서는 여러 IL이 할당된 프로세스의 예를 보여 줍니다. 프로세스는 일반적으로 부모 프로세스의 IL을 상속하지만 프로세스는 AIS가 권한 상승된 프로세스를 시작할 때처럼 IL이 다른 프로세스를 시작할 수도 있습니다. 프로세스 무결성 수준은 기본 제공 Whoami 유틸리티에 /all 옵션을 지정하거나, Sysinternals Process Explorer 또는 AccessChk를 사용하여 확인할 수 있습니다. Process Explorer에 무결성 수준 열을 추가하면 프로세스 IL을 표시할 수 있습니다.
Figure 16 샘플 프로세스 무결성 수준 할당 (Close Figure 16)

무결성 수준 | 예제 프로세스
낮은 필수 수준 | 보호 모드 Internet Explorer와 보호 모드 Internet Explorer에 의해 시작된 프로세스
중간 필수 수준 | 표준 사용자 및 권한 상승되지 않은 AAM 프로세스
높은 필수 수준 | 관리 권한으로 실행되는 프로세스
시스템 필수 수준 | 로컬 시스템, 로컬 서비스 및 네트워크 서비스 프로세스
모든 검색 가능 개체에는 명시적이거나 암시적인 IL이 있습니다. 프로세스, 스레드 및 토큰 개체에는 항상 명시적으로 할당된 IL이 있으며 이 IL은 일반적으로 해당 프로세스 토큰에 저장된 것과 같습니다. 대부분의 개체에는 명시적 IL이 없으며 중간 IL이 기본값으로 사용됩니다. 중간 이외의 IL로 생성되는 유일한 개체는 낮은 IL에서 실행되는 프로세스에 의해 생성되어 낮은 IL을 가지는 개체입니다. 기본 제공되는 iCacls 도구(%SystemRoot%\System32\iCacls.exe)를 사용하여 파일의 IL을 볼 수 있고 Sysinternals AccessChk 유틸리티를 사용하여 파일, 레지스트리, 서비스 및 프로세스의 IL을 볼 수 있습니다. 그림 17에서는 보호 모드 Internet Explorer로 액세스할 수 있어야 하는 디렉터리의 IL이 낮은 수준임을 알 수 있습니다.
그림 17 사용자의 즐겨찾기 디렉터리의 IL이 표시된 AccessChk
그림 17 사용자의 즐겨찾기 디렉터리의 IL이 표시된 AccessChk
개체에 명시적 IL이 있는 경우 해당 IL은 개체 보안 설명자의 SACL(시스템 액세스 제어 목록)에서 Windows Vista의 새로운 액세스 제어 항목(ACE)인 레이블 ACE에 저장됩니다(그림 18 참조). ACE의 SID는 개체의 IL에 해당하며 ACE의 플래그는 개체의 무결성 정책을 인코딩합니다. Windows Vista 이전에는 SACL에 감사 ACE만 저장되었으며 이 경우 "감사 및 보안 로그 관리" 권한(SeSecurityPrivilege)이 필요했지만 읽기 권한(READ_CONTROL) 액세스만 있으면 레이블 ACE를 읽을 수 있었습니다. 프로세스가 개체의 IL을 수정하려면 개체에 대한 소유자 변경(WRITE_OWNER) 액세스 권한과, 개체와 같거나 그보다 높은 IL을 갖고 있어야 하며 프로세스는 IL을 자신의 IL 이하로만 설정할 수 있습니다. 새로운 "개체 레이블 수정"(SeRelabelPrivilege) 권한을 가진 경우 프로세스는 해당 프로세스가 액세스 권한을 갖고 있는 모든 개체의 IL을 변경할 수 있으며 IL을 프로세스 자신의 IL보다 높게 올릴 수도 있지만 이 권한은 기본적으로 어떠한 계정에도 할당되지 않습니다.
그림 18 개체의 레이블 ACE
그림 18 개체의 레이블 ACE
프로세스가 개체를 열려고 하면 커널의 SeAccessCheck 함수에서 표준 Windows DACL 검사가 수행되기 전에 무결성 검사가 수행됩니다. 기본 무결성 정책이 적용될 경우 프로세스는 IL이 개체의 IL과 같거나 높고 DACL에서도 프로세스에 액세스를 허용하는 경우에만 쓰기 액세스를 위해 개체를 열 수 있습니다. 예를 들어 낮은 IL 프로세스는 DACL에서 프로세스에 쓰기 액세스를 허용하더라도 중간 IL 프로세스를 쓰기 액세스를 위해 열 수 없습니다.
기본 무결성 정책에서 프로세스는 개체의 DACL에서 읽기 액세스를 허용한 경우 읽기 액세스 권한으로 프로세스 및 스레드 개체를 제외한 모든 개체를 열 수 있습니다. 즉, 낮은 IL로 실행 중인 프로세스가 해당 프로세스를 실행 중인 사용자 계정이 액세스할 수 있는 모든 파일을 열 수 있습니다. 보호 모드 Internet Explorer에서는 IL을 사용하여 맬웨어에서 사용자 계정 설정을 수정하여 Internet Explorer에 영향을 주지 못하도록 하고 있지만 이 방법으로 맬웨어가 사용자의 문서를 읽는 것을 막지는 못합니다.
프로세스 및 스레드 개체의 무결성 정책에는 No-Read-Up도 포함되기 때문에 예외입니다. 즉, 프로세스의 IL이 해당 프로세스가 열려고 하는 IL과 같거나 높아야 하며 DACL에서 액세스를 허용해야 열 수 있습니다. DACL에서 원하는 형태의 액세스를 허용한다고 가정할 때 그림 19에서는 중간 및 낮은 수준에서 실행 중인 프로세스가 다른 프로세스와 개체에 대해 갖는 액세스 권한을 보여 줍니다.
그림 19 개체 및 프로세스 액세스
그림 19 개체 및 프로세스 액세스
Windows 메시징 하위 시스템도 프로세스가 일부 정보용 창 메시지를 제외한 모든 메시지를 높은 IL의 프로세스가 소유한 창으로 보내지 못하도록 하는 방법으로 무결성 수준을 고려하여 UIPI를 구현합니다. 이를 통해 표준 사용자 프로세스가 권한 상승된 프로세스의 창에 입력을 전달하거나 내부 버퍼 오버플로를 트리거하는 잘못된 형식의 메시지를 전송하여 권한 상승된 프로세스에 문제를 일으키는 것을 방지할 수 있습니다. 프로세스는 ChangeWindowMessageFilter API를 호출하여 추가 메시지가 보호를 통과하도록 선택할 수 있습니다. 또한 UIPI는 창 후크가 높은 IL 프로세스의 창에 영향을 주는 것을 차단하여 예를 들어 표준 사용자 프로세스가 관리 응용 프로그램 등에 사용자가 입력하는 내용을 기록할 수 없도록 합니다.

권한 상승 및 보안 경계
UAC 권한 상승은 편리하게 이용할 수 있는 기능이지만 보안 경계는 아니라는 점을 인식해야 합니다. 보안 경계가 되려면 경계를 통과할 수 있는 항목이 보안 정책에 명시되어야 합니다. 사용자 계정의 경우 특정 사용자가 다른 사용자의 권한이 없으면 해당 사용자의 데이터에 액세스할 수 없기 때문에 Windows의 보안 경계에 속합니다.
권한 상승은 보안 경계가 아니기 때문에 시스템에서 표준 사용자 권한으로 실행 중인 맬웨어가 권한 상승된 프로세스를 악용하여 관리 권한을 획득할 수 없다는 점을 보장하지 못합니다. 예를 들어 권한 상승 대화 상자는 권한 상승될 실행 파일만 식별하며 해당 파일을 실행했을 때 어떤 작업을 하는지에 대해서는 아무것도 표시하지 않습니다. 실행 파일은 명령줄 인수를 처리하고, DLL을 로드하고, 데이터 파일을 열고, 다른 프로세스와 통신합니다. 맬웨어가 이런 작업을 악용하여 권한 상승된 프로세스를 공격하고 관리 권한을 얻을 수도 있습니다.
낮은 IL 샌드박스 다루기
보호 모드 Internet Explorer는 낮은 IL에서 실행되어 프로세스를 감염시킬 수 있는 맬웨어 주위에 경계를 만듭니다. 이를 통해 맬웨어가 사용자 계정 설정을 변경하고 자동 시작 위치에 자신을 설치하는 것을 방지합니다. Sysinternals PsExec 유틸리티를 -l 스위치와 함께 사용하면 샌드박스를 탐색하기 위해 임의의 프로세스를 낮은 IL에서 실행해 볼 수 있습니다. 그림 B에서는 낮은 IL에서 실행 중인 명령 프롬프트가 중간 IL을 가진 사용자 임시 디렉터리에 파일을 만들 수 없지만 낮은 IL을 가진 Internet Explorer 임시 디렉터리에는 만들 수 있는 것을 볼 수 있습니다.
그림 B명령 프롬프트는 비슷한 IL에서만 파일 생성 가능

권한 상승된 AAM 프로세스는 AAM 사용자의 표준 권한 프로세스와 같은 사용자 계정에서 실행되며 사용자의 프로필을 공유하기 때문에 공격에 특히 취약합니다. 사용자 프로필에 등록된 확장을 로드하고 설정을 읽는 응용 프로그램이 많기 때문에 맬웨어에 권한 상승의 기회가 제공될 수 있습니다. 예를 들어 일반적인 제어 대화 상자는 사용자의 레지스트리 키에 구성된(HKEY_CURRENT_USER 아래) 셸 확장을 로드하기 때문에 맬웨어는 자신을 확장으로 추가함으로써 해당 대화 상자를 사용하는 권한 상승된 프로세스에 로드되도록 할 수 있습니다.
표준 사용자 계정에서 권한 상승된 프로세스도 공유된 상태 때문에 공격받을 우려가 있습니다. 로그온 세션에서 실행 중인 모든 프로세스는 Windows가 이벤트, 뮤텍스, 세마포 및 공유 메모리를 저장하는 내부 네임스페이스를 공유합니다. 권한 상승된 프로세스가 프로세스 시작 시 특정 공유 메모리 개체를 열고 읽으리라는 것을 맬웨어가 알고 있으면 맬웨어는 버퍼 오버플로를 트리거하여 권한 상승된 프로세스에 코드를 삽입하는 내용의 개체를 만드는 것이 가능합니다. 이러한 유형의 공격은 비교적 복잡하지만 그 가능성만으로도 OTS 권한 상승이 보안 경계가 아니라는 점을 보여 줍니다.
기본적으로 권한 상승은 기본적으로 표준 사용자 권한으로 실행하기 위해 관리 권한에 액세스하고자 하는 사용자의 편의를 위해 도입된 기능입니다. 보다 견고한 보안 경계를 필요로 하는 사용자는 편리함을 포기하고 일상 작업에는 표준 사용자 계정을 사용하고 관리 작업을 수행할 때는 빠른 사용자 전환(FUS)을 통해 전용 관리자 계정으로 전환하는 방법을 선택할 수 있습니다. 반면 보안 대신 편리함을 원하는 사용자는 제어판의 사용자 계정 대화 상자에서 시스템 UAC를 해제할 수 있습니다. 이 경우에는 Internet Explorer의 보호 모드도 해제된다는 점을 알아 두어야 합니다.

결론
표준 사용자로 실행하면 시스템을 우발적 또는 의도적 손상으로부터 보호하고 시스템을 공유하는 사용자의 무결성과 데이터를 인증되지 않은 액세스로부터 보호할 수 있다는 점을 비롯한 다양한 이점이 있습니다. UAC의 다양한 변경 사항과 기술은 Windows 사용 모델에 큰 변화를 가져올 것입니다. Windows Vista를 통해 Windows 사용자는 처음으로 대부분의 일상 작업과 대부분의 소프트웨어를 표준 사용자 계정으로 실행할 수 있게 되었으며 이제 많은 회사들이 표준 사용자 계정을 배포할 수 있게 되었습니다.

Mark Russinovich는 Microsoft의 플랫폼 및 서비스(Platform and Services) 부서에서 근무하는 기술 연구원으로, Microsoft Windows Internals(Microsoft Press, 2004)의 공동 저자이자 다양한 IT와 개발자 회의의 단골 연설자이며 최근 Microsoft에서 인수한 Winternals Software의 공동 설립자이기도 합니다. 그는 또한 Sysinternals를 설립했으며 이곳에서 Process Explorer, Filemon 및 Regmon 유틸리티를 발표했습니다.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 Security: BitLocker 드라이브 암호화를 사용하여 데이터를 보호하기 위한 핵심 사항
Security Byron Hynes

BitLocker 드라이브 암호화를 사용하여 데이터를 보호하기 위한 핵심 사항
한 눈에 보기:
  • 전체 볼륨 암호화
  • BitLocker 키
  • BitLocker 설정

Windows BitLocker 드라이브 암호화는 분명히 Windows Vista의 가장 주목할 만한 기능 중 하나입니다. 하지만 대부분의 사용자는 아직까지 BitLocker를 테스트해 볼 기회가 많지 않았습니다.
이로 인해 BitLocker가 수행하는 작업이나 그 작동 방식을 직접 확인해 볼 기회가 없었으며, 특히 TPM(신뢰할 수 있는 플랫폼 모듈)이 장착된 컴퓨터에서는 그 기회가 더욱 없었습니다. 이 기사에서는 사용자가 BitLocker™의 잠재적 우수성을 평가하고 업그레이드 계획에 이를 포함할 수 있도록 BitLocker의 기본 개념을 소개합니다. 먼저 BitLocker에 대한 배경 정보와 개념 정보를 설명한 다음 BitLocker 설정, 데이터 복구 및 관리에 대해 살펴보고 컴퓨터의 수명이 다했을 때 BitLocker를 어떻게 활용할 수 있는지 알아봅니다. 여기서 언급하는 용어에 대한 설명은 "디스크 및 볼륨" 추가 기사를 참조하십시오.
디스크 및 볼륨
디스크 및 볼륨과 관련된 용어는 혼동을 가져다주는 경우가 많습니다. 다음은 참조할 수 있는 몇 가지 용어입니다.
파티션. 파티션은 물리적 하드 디스크의 한 구역으로 디스크에 저장된 파티션 테이블에 정의되어 있는 논리적 구조입니다.
볼륨. 볼륨은 하나 이상의 파티션으로 구성되고 볼륨 관리자라는 Windows 구성 요소를 통해 정의되는 Windows의 논리적 구조입니다. 볼륨 관리자와 시작 구성 요소를 제외한 운영 체제의 나머지 요소와 응용 프로그램에서는 파티션이 아니라 볼륨을 사용합니다. Windows Vista를 비롯한 Windows 클라이언트 운영 체제에서는 파티션과 볼륨이 대개 일대일 관계를 이룹니다. 서버에서는 일반적인 RAID 구성에서 볼 수 있듯이 하나의 볼륨이 여러 개의 파티션으로 구성되는 경우가 많습니다.
활성 파티션. 한 번에 한 파티션만 활성 파티션으로 표시될 수 있습니다. 활성 파티션은 운영 체제를 시작하는 데 사용되는 부팅 섹터가 포함된 파티션입니다. 활성 파티션을 시스템 파티션이나 시스템 볼륨으로 부르는 경우도 있지만 Windows OS 볼륨과는 다른 개념입니다.
Windows OS 볼륨. 이 볼륨에는 System 및 System32 폴더를 비롯한 Windows 설치 관련 폴더가 포함됩니다. Windows Vista가 릴리스되기 전에는 부팅 파티션이라는 용어가 사용되었으며 지금도 종종 사용됩니다. 하지만 Windows OS 볼륨이라는 용어의 의미가 더 명확하며 이 용어를 사용하면 부팅 파티션을 시스템 파티션과 혼동하는 문제를 피할 수 있습니다. 예전에는 강사들이 "시스템 파티션에서는 부팅하고 부팅 파티션에서는 시스템 파일을 찾는다"는 점을 기억하라고 학생들에게 설명하곤 했습니다.
Windows Vista 이전에는 Windows OS 볼륨(부팅 파티션이라고도 함)과 활성 파티션(시스템 파티션이라고도 함)이 같았습니다. 이는 대부분의 클라이언트 컴퓨터에서 하드 디스크가 크기가 큰 단일 파티션으로 구성되었기 때문입니다. 그림 A에서는 Windows Vista 디스크 관리 콘솔에서 각 파티션 또는 볼륨에 할당된 기능을 볼 수 있습니다.
그림 A 파티션 기능
그림 A 파티션 기능

BitLocker는 상호 보완적이지만 명확히 다른 두 가지 작업을 수행합니다. 첫째, BitLocker는 Windows® OS 볼륨에 대한 전체 볼륨 암호화 기능을 제공합니다. 둘째, 호환 TPM이 장착된 컴퓨터에서 Windows Vista™ 시작을 허용하기에 앞서 초기 시작 구성 요소의 무결성을 검사하는 방법을 제공합니다.
BitLocker의 모든 기능을 사용하려면 컴퓨터에 호환 TPM 마이크로칩과 BIOS가 있어야 합니다. 여기서 호환 TPM 마이크로칩 및 BIOS는 TCG(Trusted Computing Group)에서 정의한 대로 TPM과 Static Root of Trust Measurement를 지원하는 버전 1.2 TPM 및 BIOS를 의미합니다. 하지만 호환 TPM 및 BIOS가 없는 컴퓨터에서도 BitLocker 암호화를 사용할 수 있습니다.

전체 볼륨 암호화
BitLocker는 Windows OS 볼륨에 기록되는 모든 데이터가 암호화되도록 전체 볼륨 암호화 기능을 제공합니다. 이는 조직의 컴퓨터, 특히 랩톱 및 모바일 컴퓨터에 저장된 기밀 정보를 보호하는 데 매우 중요한 역할을 합니다.
모바일 컴퓨터는 언제든지 분실하거나 도난당할 수 있습니다. 휴대용 컴퓨터의 용량이 늘어나고 모바일 작업자의 수가 증가함에 따라 한 작업자가 수백 기가바이트에 이르는 조직의 영업 비밀, 기밀 문서 또는 고객의 PII(개인 식별 정보)를 휴대할 수 있게 되었습니다. 어느 뉴스 사이트를 보더라도 이러한 데이터 중 상당량이 분실되고 있다는 소식을 쉽게 접할 수 있습니다. 사생활 권리 정보 센터(Privacy Rights Clearinghouse)는 2005년 이후 개인 정보가 포함된 레코드 중 분실되거나 노출된 레코드가 1억 4백만 개가 넘는다고 밝히고 있습니다.
대부분의 조직은 이미 법률적 규제 및 조직 내부의 규정에 따라 다양한 종류의 개인 정보를 보호하고 있습니다. 또한 개인 정보 보호가 법적 강제 사항이 아닌 조직에서도 개인 정보 보호가 비즈니스를 수행하기 위한 필수 요소임을 인식하고 있습니다.

전체 볼륨을 암호화하는 이유
경험이 많은 Windows 관리자라면 EFS(파일 시스템 암호화) 같은 Windows 기반 암호화 옵션 및 RMS(Rights Management Services)가 제공하는 암호화 및 보호 기능에 대해 잘 알고 있을 것입니다. BitLocker는 한번 설정하고 나면 전체 볼륨에 대해 사용자의 개입 없이 자동으로 암호화를 수행한다는 점에서 앞의 다른 암호화 기능과는 큰 차이가 있습니다.
예를 들어 EFS를 사용하는 경우 보호할 파일과 폴더를 사용자가 구체적으로 지정해야 합니다. Windows Vista에는 EFS를 보다 유연하게 사용할 수 있는 새로운 몇 가지 옵션이 있습니다. 또한 EFS와 RMS는 각각 BitLocker가 해결할 수 없는 몇몇 시나리오를 해결합니다. 하지만 EFS와 RMS는 볼륨에 저장되는 모든 데이터를 보호하도록 설계되지 않았을 뿐만 아니라 관리자의 구성 작업을 꽤 많이 필요로 합니다.
이와는 달리 BitLocker는 BitLocker로 보호되는 볼륨에 기록되는 모든 데이터, 즉 운영 체제 자체, 레지스트리, 최대 절전 모드 파일 및 페이징 파일, 응용 프로그램, 응용 프로그램에 사용되는 데이터를 모두 암호화합니다.
단, 부팅 섹터, 이미 읽을 수 없는 것으로 표시된 불량 섹터, 볼륨 메타데이터 등 세 가지 항목은 암호화되지 않습니다. 볼륨 메타데이터는 볼륨에 대한 통계 정보를 비롯하여 BitLocker를 관리하는 데 사용되는 데이터에 대한 중복 복사본 세 개와 몇몇 암호 해독 키에 대한 보호된 복사본으로 구성됩니다. 이러한 항목은 고유하지도 않고 귀중한 데이터도 아니며 개인 식별 정보에 해당하지도 않으므로 암호화할 필요가 없습니다.
전체 볼륨 암호화는 운영 체제를 우회함으로써 시작되는 공격의 일종인 오프라인 공격으로부터 데이터를 보호합니다. 일반적인 오프라인 공격의 한 예로 컴퓨터를 훔쳐 하드 드라이브를 떼어낸 다음 이를 Windows의 다른 복사본이나 다른 운영 체제를 실행하는 컴퓨터에 보조 드라이브로 설치하여 사용자 암호를 입력하지 않고 NTFS 권한 없이 데이터를 읽는 것을 들 수 있습니다. 하지만 BitLocker로 보호되는 볼륨은 이러한 종류의 공격으로 읽을 수 없습니다.

BitLocker의 데이터 암호화 방식
BitLocker는 128비트 키와 함께 AES(고급 암호화 표준) 알고리즘을 사용합니다. 그룹 정책이나 BitLocker WMI(Windows Management Instrumentation) 공급자를 통해 128비트 키를 256비트 키로 늘려 데이터를 더욱 안전하게 보호할 수 있습니다.
볼륨의 각 섹터는 개별적으로 암호화되며 암호화 키의 일부는 섹터 번호에서 파생됩니다. 따라서 암호화되지 않은 동일한 데이터가 포함된 두 개의 섹터가 있더라도 디스크에는 서로 다른 암호화된 바이트가 기록되므로 알려진 일부 정보를 만들고 암호화하는 방법으로는 키를 알아내기가 훨씬 어려워졌습니다.
BitLocker는 AES로 데이터를 암호화하기 전에 디퓨저라는 알고리즘도 사용합니다. 간단히 설명하자면 디퓨저는 일반 텍스트가 조금이라도 변경되면 암호화된 암호 텍스트의 전체 섹터를 변경하는 알고리즘입니다. 이 알고리즘 또한 공격자가 키나 데이터를 검색하기 어렵게 만듭니다.
BitLocker 암호화 알고리즘에 대한 자세한 내용은 이에 관해 Neil Ferguson이 작성한 "AES-CBC와 Elephant 디퓨저 결합: Windows Vista의 디스크 암호화 알고리즘"을 참조하십시오.

BitLocker 키
암호화 기능을 사용하려면 키에 대해서 잘 알아야 하며 BitLocker도 예외는 아닙니다. BitLocker에서는 정교하지만 다소 복잡한 키 구조를 사용합니다.
섹터 자체는 FVEK(전체 볼륨 암호화 키)라는 키로 암호화됩니다. 하지만 사용자는 FVEK를 사용하지도, 이에 액세스할 수도 없습니다. FVEK는 다시 VMK(볼륨 마스터 키)라는 키로 암호화됩니다. 이러한 수준의 추상화에는 나름대로의 장점도 있지만 이로 인해 암호화 프로세스가 다소 이해하기 어려울 수도 있습니다. FVEK가 노출되면 모든 섹터를 다시 암호화해야 하므로 FVEK는 집중 보호되는 기밀 데이터로 보관됩니다. 이러한 작업은 시간이 많이 소요되므로 FVEK를 사용하고 싶지 않을 수도 있습니다. 이러한 이유로 시스템에서는 대신 VMK를 사용합니다.
FVEK는 VMK로 암호화되어 볼륨 메타데이터의 일부로 디스크 자체에 저장됩니다. FVEK가 로컬에 저장되기는 하지만 암호화되지 않은 상태로 디스크에 기록되는 일은 결코 없습니다.
VMK도 하나 이상의 키 보호기를 통해 암호화되거나 "보호"됩니다. 기본 키 보호기는 TPM입니다. TPM 사용에 대해서는 무결성 검사에 관해 설명하는 다음 단원에서 살펴봅니다. 비상시에 대비해 키 보호기 역할을 하는 복구 암호도 생성됩니다. 복구에 대해서도 뒷부분에서 설명합니다.
TPM을 USB 드라이브에 저장된 부분 키나 숫자 PIN과 함께 사용하면 보안을 강화할 수 있습니다. 이러한 각 방식을 이중 인증의 한 형식이라고 할 수 있습니다. 컴퓨터에 호환 TPM 칩과 BIOS가 없는 경우 키 보호기를 전적으로 USB 드라이브에 저장하도록 BitLocker를 구성할 수 있습니다. 이를 시작 키라고 합니다.
데이터의 암호를 해독하지 않고 BitLocker를 비활성화할 수 있습니다. 이 경우 VMK는 암호화되지 않은 상태로 저장된 새 키 보호기를 통해서만 보호됩니다. 이 일반 키 덕분에 시스템에서는 보호되지 않은 것처럼 보호된 드라이브에 액세스할 수 있습니다.
시스템이 시작될 때 시스템에서는 TPM을 쿼리하고 USB 포트를 확인하여 적절한 키 보호기를 검색합니다. 또는 필요한 경우 사용자에게 키 보호기를 요청하는데 이를 복구라고 합니다. 키 보호기를 찾으면 VMK, FVEK, 디스크에 저장된 데이터의 순서로 암호가 해독됩니다. 이 프로세스는 그림 1에 나와 있습니다.
그림 1 BitLocker 기본 시작 프로세스
그림 1 BitLocker 기본 시작 프로세스

무결성 검사
시작 프로세스의 최초 단계와 관련된 구성 요소의 경우 암호화되지 않은 상태로 사용할 수 있어야 컴퓨터를 시작할 수 있습니다. 따라서 공격자는 디스크의 데이터가 암호화되어 있는 경우에도 루트킷(rootkit)과 같은 도구를 사용하여 이러한 초기 시작 구성 요소의 코드를 변경하여 컴퓨터에 액세스할 수 있습니다.
이러한 공격을 통해 침입자는 BitLocker 키나 사용자 암호와 같은 기밀 정보에 액세스한 다음 이러한 정보를 이용하여 다른 보안 보호 기능을 뚫을 수 있습니다.
이러한 종류의 공격을 방지하는 것이 BitLocker라는 프로그램과 이 프로그램을 만든 팀의 원래 목표 중 하나였습니다. 그리고 어느 정도까지는 암호화를 통해 이러한 목적을 달성할 수 있었습니다. BitLocker는 전체 볼륨 암호화를 통해 시스템의 무결성을 보호하고 초기 시작 구성 요소가 변경된 경우 Windows가 시작되지 않도록 합니다.
호환 TPM이 장착된 컴퓨터의 경우 컴퓨터가 시작될 때마다 BIOS, MBR(마스터 부트 레코드), 부팅 섹터, 부팅 관리자 코드 등의 초기 시작 구성 요소가 각각 실행하려는 코드를 검토하고 해시 값을 계산하여 이를 TPM 내의 특정 레지스터인 PCR(플랫폼 구성 레지스터)에 저장합니다. 한번 PCR에 값이 저장되고 나면 시스템을 다시 시작하지 않는 한 값을 바꾸거나 삭제할 수 없습니다. BitLocker는 TPM과 PCR에 저장된 값을 사용하여 VMK를 보호합니다.
TPM은 특정 PCR 값과 연결된 키를 만들 수 있습니다. TPM에서는 이러한 키를 만든 다음 암호화하므로 해당 TPM에서만 키의 암호를 해독할 수 있습니다. 하지만 이보다 중요한 기능은 현재 PCR 값이 키 생성 시 지정된 값과 일치하는 경우에만 TPM이 키의 암호를 해독한다는 것입니다. 이를 TPM에 키를 봉인한다고 합니다.
기본적으로 BitLocker는 CRTM(Core Root of Trust of Measurement)의 측정값, BIOS 및 플랫폼 확장, 옵션 ROM 코드, MBR 코드, NTFS 부팅 섹터 및 부팅 관리자에 키를 봉인합니다. 이러한 항목 중 하나라도 예기치 않게 변경되면 BitLocker가 드라이브를 잠가서 액세스되거나 암호가 해독되지 않도록 보호합니다.
기본적으로 BitLocker는 TPM을 찾아서 사용하도록 구성되어 있습니다. 그룹 정책이나 로컬 정책 설정을 통해 TPM을 사용하지 않고 외부 USB 플래시 드라이브에 키를 저장하도록 BitLocker를 구성할 수 있습니다. 하지만 TPM이 없으면 BitLocker가 시스템 무결성을 확인할 수 없습니다.

최초 BitLocker 설정
BitLocker는 Windows Vista Enterprise 및 Windows Vista Ultimate에서 사용할 수 있습니다. 다음 버전의 Windows Server®인 코드 이름 "Longhorn"에는 BitLocker가 선택적 구성 요소로 포함될 것입니다.
아래 내용에서는 테스트에 사용할 수 있는 호환 TPM이 컴퓨터에 설치되어 있다고 가정합니다. TPM이 없는 컴퓨터에서 BitLocker를 사용하려는 경우 "TPM 없이 BitLocker 사용" 추가 기사에 나오는 단계를 따르십시오.
TPM 없이 BitLocker 사용
BitLocker는 기본적으로 TPM을 사용하도록 구성되어 있으므로 TPM이 없으면 Windows를 설치한 후 바로 BitLocker를 사용할 수 없습니다. 하지만 Windows BitLocker 드라이브 암호화 단계별 가이드에 설명되어 있는 다음 절차를 수행하면 TPM 없이 BitLocker를 사용할 수 있습니다.
이 단계를 수행하려면 관리자로 로그온해야 합니다. TPM이 없더라도 컴퓨터를 시작하는 동안 USB 플래시 드라이브에서 읽을 수는 있어야 합니다. 또한 BitLocker를 설정할 때와 컴퓨터를 다시 시작할 때마다 USB 플래시 드라이브를 사용할 수 있어야 합니다.
호환 TPM이 없는 컴퓨터에서 BitLocker 드라이브 암호화를 설정하려면 다음 단계를 따르십시오.
  1. 시작을 클릭하고 검색 시작 상자에 gpedit.msc를 입력한 다음 Enter 키를 누릅니다.
  2. 사용자 계정 컨트롤 대화 상자가 나타나면 제안된 작업이 필요한 작업인지 확인한 다음 계속을 클릭합니다.
  3. 그룹 정책 개체 편집기 콘솔 트리에서 로컬 컴퓨터 정책, 관리 템플릿, Windows 구성 요소를 차례로 클릭한 다음 BitLocker 드라이브 암호화를 두 번 클릭합니다.
  4. 제어판 설정: 고급 시작 옵션 사용을 두 번 클릭합니다. 그러면 제어판 설정: 고급 시작 옵션 사용 대화 상자가 나타납니다.
  5. 사용 옵션을 선택하고 호환되는 TPM이 없이 BitLocker 허용 확인란을 선택한 다음 확인을 클릭합니다. TPM 대신 시작 키를 사용하도록 정책 설정을 변경했습니다.
  6. 그룹 정책 개체 편집기를 닫습니다.
  7. 그룹 정책을 즉시 적용하려면 시작을 클릭하고 검색 시작 상자에 gpupdate.exe /force를 입력한 다음 Enter 키를 누릅니다. 프로세스가 완료될 때까지 기다립니다.

BitLocker를 설정할 때는 볼륨이 올바르게 구성되어 있는지 확인하는 것이 중요합니다. BitLocker를 사용하는 경우 활성 파티션이 암호화되어 있지 않아야 부팅 섹터, 부팅 관리자 및 Windows 로더 프로그램을 읽을 수 있습니다. 이러한 구성 요소는 앞에서 설명한 시스템 무결성 단계를 통해 보호됩니다. 다른 Windows 구성 요소에서도 임시로 활성 파티션을 사용해야 할 수 있으므로 활성 파티션의 크기를 1.5GB 이상으로 구성하는 것이 좋습니다. 사용자가 이 볼륨에 실수로 데이터를 기록할 수 없도록 NTFS 권한을 구성하는 것도 좋은 방법입니다.
Windows 자체는 암호화가 가능한 더 큰 두 번째 볼륨에 설치됩니다. 새 시스템에 Windows를 설치하는 경우 Windows BitLocker 드라이브 암호화 단계별 가이드에 나오는 지침에 따라 볼륨을 직접 구성할 수 있습니다.
BitLocker Drive Preparation Tool(드라이브 준비 도구)을 사용하면 BitLockr를 사용하도록 시스템을 설정하는 작업을 쉽게 마칠 수 있습니다. 이 도구는 드라이브를 구성하는 번거로운 작업을 대신 수행해 줍니다. 이 도구는 Windows Vista Ultimate Extra로 제공되거나 Windows Vista Enterprise를 배포하는 고객에게 제공됩니다. BitLocker 드라이브 준비 도구에 대한 자세한 내용은 support.microsoft.com/kb/930063을 참조하십시오.
BitLocker 드라이브 준비 도구는 볼륨이 한 개만 있는 경우 이를 자동으로 축소하고 두 번째 파티션을 만들어 이를 활성 파티션으로 설정하고 필요한 모든 구성 변경 작업을 수행하며 시작 파일을 적절한 위치로 옮깁니다.
볼륨만 구성되면 BitLocker를 설정하는 작업은 매우 쉽습니다. 제어판의 보안 섹션에서 BitLocker 드라이브 암호화 아이콘을 클릭합니다. UAC 동의 관련 메시지에 동의하면 그림 2와 비슷한 화면이 나타납니다.
그림 2 BitLocker 설정
그림 2 BitLocker 설정
다음에 수행되는 작업의 정확한 순서는 컴퓨터에 내장된 TPM 칩의 상태에 따라 다릅니다. TPM 칩이 초기화되어 있지 않으면 TPM 초기화 마법사가 실행됩니다. 표시되는 메시지에 따라 컴퓨터를 다시 시작하는 과정을 포함하여 TPM 초기화를 수행하십시오.
TPM이 초기화된 후에는 그림 3의 복구 암호 저장 페이지가 나타납니다. TPM에 오류가 발생하거나 다른 문제가 발생한 경우 복구 암호가 있어야 데이터를 복구할 수 있습니다. 이 페이지에서는 USB 플래시 드라이브나 로컬 디스크 또는 네트워크 디스크에 복구 암호를 저장하거나 복구 암호를 인쇄하여 안전한 위치에 보관할 수 있습니다. 이러한 옵션 중 적어도 하나는 선택해야 하며 복사본을 여러 개 저장할 수도 있습니다. 복구 암호를 저장하고 나면 다음 단추가 활성화됩니다. 다음 단추를 클릭합니다.
그림 3 복구 암호 저장
그림 3 복구 암호 저장
Encrypt the selected disk volume(선택한 디스크 볼륨 암호화) 페이지가 나타나면 암호화를 시작하기 전에 시스템 검사를 실행할지 여부를 선택합니다. 시스템 검사를 실행하려면 시스템을 다시 시작해야 합니다. TPM, BIOS 및 USB 포트가 BitLocker와 문제없이 작동하도록 하려면 시스템을 다시 시작하는 것이 가장 좋습니다. 시스템을 다시 시작한 후 문제가 발견되면 오류 메시지가 표시됩니다. 그렇지 않으면 암호화 진행 중 상태 표시줄이 나타납니다.
이게 다입니다. 암호화가 백그라운드에서 수행되므로 컴퓨터를 계속해서 사용할 수 있습니다. 초기 암호화가 완료되면 이를 알리는 메시지가 표시됩니다. 마우스 커서를 화면 맨 아래의 도구 모음에 있는 BitLocker 드라이브 암호화 아이콘 위로 끌어 디스크 볼륨 암호화의 진행 상태를 모니터링할 수도 있습니다. 자세한 내용은 앞에서 언급한 단계별 가이드를 참조하십시오.
컴퓨터가 시작될 때 BitLocker가 사용자에게 메시지를 표시하지 않거나 다른 간섭 작업을 수행하지 않는 것에 대해 의아해하는 사용자도 있었습니다. 이는 기본 구성의 경우 BitLocker가 볼륨 잠금을 해제하기에 앞서 TPM을 통해 시스템 무결성을 확인하기 때문입니다. 이 작업은 사용자 모르게 자동으로 수행됩니다.
컴퓨터 시작 시 PIN 입력을 요구하거나 USB 플래시 드라이브에 저장된 키가 있어야 컴퓨터를 시작하도록 BitLocker를 구성할 수 있습니다. 이렇게 하면 보안이 한층 강화됩니다. 따라서 PIN을 입력하는 불편함을 감수하더라도 보안을 중요하게 고려해야 하는 환경에서는 이렇게 하는 것이 좋습니다. 필자의 견해로는 항상 이 방법을 사용하는 것이 좋습니다. 예를 들어 필자의 경우 데스크톱에서는 PIN을 입력해야 하고 랩톱 컴퓨터에서는 USB 키가 있어야 시스템을 시작할 수 있도록 구성해 놓았습니다.

BitLocker 복구
특히 비즈니스 환경이나 엔터프라이즈 환경에서 암호화 기능을 사용할 때는 권한을 가진 사용자가 정상적인 액세스 방법이나 키를 사용할 수 없는 경우에도 자신의 데이터를 복구할 수 있는 방법을 마련하는 것이 필수입니다. BitLocker에서는 이를 복구라고 합니다.
초기 시작 구성 요소에서 무언가가 예기치 않게 변경되거나 USB 시작 키가 없어지거나 사용자가 자신의 PIN 번호를 기억하지 못하면 BitLocker가 정상적인 시작 프로세스를 완료할 수 없습니다. 이 경우 BitLocker는 볼륨을 잠긴 상태로 두므로 Windows를 시작할 수 없습니다. 대신 부팅 관리자의 BitLocker 코드에서 텍스트 화면을 표시합니다. 복구 암호(또는 복구 키)를 USB 플래시 드라이브에 저장한 경우에는 그림 4와 같은 화면이 나타납니다.
그림 4 복구 키 검색
그림 4 복구 키 검색
컴퓨터를 시작할 때 USB 플래시 드라이브가 이미 연결되어 있어야 BitLocker가 USB 플래시 드라이브를 읽을 수 있습니다. 따라서 복구 암호가 저장된 USB 플래시 드라이브가 있으면 USB 플래시 드라이브를 삽입하고 Esc 키를 누릅니다. USB 플래시 드라이브가 없으면 Enter 키를 누릅니다. 그러면 그림 5와 같은 화면이 나타납니다. 이 화면은 USB 드라이브에 복구 키를 저장하지 않은 경우에도 나타납니다.
그림 5 BitLocker 암호 입력
그림 5 BitLocker 암호 입력
그러면 BitLocker가 드라이브 잠금을 해제하는 데 사용할 수 있는 48자리의 숫자 암호를 검색합니다. 복구 암호를 인쇄하도록 선택한 경우에는 해당 페이지에 이 번호가 있으며 복구 암호를 폴더에 저장한 경우에는 파일에도 복구 암호가 저장되어 있습니다.
비즈니스 환경에서 복구 암호를 관리하는 가장 쉬운 방법은 Active Directory®에 복구 암호가 자동으로 저장되도록 구성하는 것입니다. Active Directory에 복구 암호가 자동으로 저장되도록 구성하는 방법에 대한 자세한 내용은 go.microsoft.com/fwlink/?LinkId=87067을 참조하십시오.
향후에 제공될 후속 기사에서 BitLocker의 관리 효율성에 대해 자세히 설명하겠습니다. 이 문서에서는 BitLocker에는 WMI 호환 WBEM(Web-Based Enterprise Management) 시스템을 통해 BitLocker(및 TPM)를 관리할 수 있도록 하는 완전한 WMI 공급자가 포함되어 있다는 사실만 언급하고 넘어가겠습니다. 이는 VBScript 또는 Windows PowerShell™과 같은 WMI 개체에 액세스할 수 있는 모든 스크립팅 언어를 사용하여 BitLocker를 스크립팅할 수 있음을 의미합니다.
BitLocker에는 WMI 공급자를 사용하는 manage-bde.wsf라는 명령줄 도구도 포함되어 있습니다. 이 도구를 사용하면 로컬 또는 원격 컴퓨터에서 BitLocker를 관리할 수 있습니다. 자세한 내용을 보려면 명령 프롬프트를 실행한 다음 manage-bde.wsf /?를 입력하십시오.

안전한 폐기
모든 컴퓨터는 언젠가는 폐기해야 합니다. 일반적으로 기업은 컴퓨터를 폐기하기 전에 디스크 드라이브의 데이터가 완전히 삭제되었는지 확인하는 데 많은 비용과 노력을 들입니다. 디스크 드라이브에서 기밀 데이터를 제거하는 대부분의 프로세스에는 시간과 비용이 많이 들며 결국에는 하드웨어를 영구히 폐기하는 것으로 끝나기도 합니다. BitLocker는 보다 비용 효과적인 다른 옵션을 제공합니다.
BitLocker는 사후에 데이터 제거에 대해 걱정하는 대신 처음부터 위험한 방식으로 디스크에 기밀 데이터가 저장되지 않도록 합니다. 디스크에 기록되는 모든 내용이 암호화되므로 암호화 키의 복사본만 모두 삭제하면 데이터에 영구히 액세스할 수 없습니다. 하드 디스크 자체는 전혀 손상되지 않으므로 다시 사용할 수 있습니다.
다양한 방법으로 BitLocker로 보호된 볼륨을 폐기할 수 있습니다. 볼륨 메타데이터에서 키 복사본을 모두 삭제하고 대신 안전한 중앙 사이트에 보관하는 방법을 선택할 수 있습니다. 이렇게 하면 시스템을 안전하게 운송할 수 있으며 시스템을 장기간 방치해야 하는 경우 임시로 폐기할 수 있습니다. 이 경우 권한을 가진 사용자는 계속해서 데이터에 액세스할 수 있지만 장치를 새로 소유하게 된 권한이 없는 사용자는 데이터에 액세스할 수 없습니다.
또는 저장되지 않은 새 키를 만들고 볼륨 메타데이터 및 Active Directory 같은 모든 보관소에서 키 복사본을 모두 삭제하는 방법을 선택할 수 있습니다. 이 경우 암호 해독 키가 없으므로 아무도 데이터를 복구하거나 검색할 수 없습니다.
두 경우 모두 볼륨 메타데이터에 포함된 키의 제거와 파기가 거의 동시에 이루어지며 관리자는 이 작업을 여러 시스템에 걸쳐서 수행할 수 있습니다. 따라서 최소한의 시간과 노력으로 데이터를 강력하고 영구적으로 보호할 수 있습니다. Windows Vista의 포맷 유틸리티는 포맷 명령으로 볼륨 메타데이터를 삭제하고 해당 섹터를 덮어써서 BitLocker 키를 안전하게 삭제할 수 있도록 업데이트되었습니다.

결론
BitLocker는 특정 위협으로부터 시스템을 보호하기 위해 설계된 강력한 도구이며 그 역할을 훌륭하게 수행합니다. 하지만 BitLocker가 모든 위협으로부터 시스템을 보호한다고 생각하면 오산입니다. 이전과 마찬가지로 강력한 암호 등의 적절한 방어책 및 제어 기능을 사용하는 것이 매우 중요합니다.
BitLocker는 오프라인 공격에 대비하여 설계된 도구입니다. 따라서 Windows가 실행 중일 때는 BitLocker가 볼륨 잠금을 해제합니다. 즉, BitLocker는 실행 중인 시스템은 보호하지 않습니다. EFS 및 RMS 같은 기술은 OS가 실행 중일 때 정보를 보호함으로써 BitLocker를 보완합니다.
BitLocker에 대한 자세한 내용은 Microsoft 웹 사이트(technet.microsoft.com/windowsvista/aa905065.aspx)를 참조하십시오. TPM 사양 및 TCG에 대한 자세한 내용은 TCG 웹 사이트에서 TPM 사양 섹션(go.microsoft.com/fwlink/?LinkId=72757)을 참조하십시오.

Byron Hynes는 Microsoft의 Windows Server User Assistance 그룹에서 근무하고 있으며 이전에는 컨설턴트와 교육 담당자로 근무하였습니다. 문의 사항이 있으면 bhynes@microsoft.com으로 연락하십시오.


 Security: Windows 방화벽 자세히 알아보기
Security Steve Riley

Windows 방화벽 자세히 알아보기
한 눈에 보기:
  • 인바운드 보호와 아웃바운드 보호 비교
  • Windows 필터링 플랫폼
  • 고급 보안 인터페이스
  • 네트워크 프로필

아주 오래 전 구시대적 컴퓨터를 사용하던 시절, 각자의 컴퓨터에 방화벽을 설치해야 한다는 생각을 하는 사람은 아무도 없었습니다. 그럴 필요가 없었지요. 인터넷이라는 말을 들어본 사람도, TCP/IP에 대해 아는 사람도 없었을 뿐더러 LAN 프로토콜이 라우팅할 수 있는 범위도 건물이나 캠퍼스에 제한되었으니까요. 중요한 정보는
메인프레임이나 파일 서버에 저장되어 있었습니다. 사용자들의 데스크톱에 저장된 정보 중 기밀 정보는 극히 드물었으며 컴퓨터의 무게로 인해 물리적인 보안도 어느 정도 보장되었지요. 만약 인터넷 연결을 사용할 수 있었다면 프로토콜 변환기가 사용되었을 테고 네트워크 경계에 패킷 필터링 라우터, 즉, '방화벽'이 존재했을 것입니다. 엄청나게 많은 규칙과 예외로 구성된 방화벽 말입니다.
현대의 컴퓨팅 환경은 옛날과는 전혀 다른 양상으로 폭넓고 다양하게 변화하고 있습니다. 이제는 모든 것이 인터넷에 연결되어 있고 모두가 TCP/IP에 대해 알고 있으며 휴대용 장치를 사용하는 것이 보편화되었습니다. 또한 직장에서는 직원들에게 랩톱을 제공합니다. 직원들을 아끼는 마음 때문이 아니라, 더욱 많은 생산성을 얻어내기 위한 것이지요. 5분 정도의 시간과 Wi-Fi 연결만 있다면 언제 어디서든 일해 주기를 기대하면서 말입니다. 랩톱이 데스크톱보다 가격은 더 나갈지 모르지만 이러한 투자는 생산성 향상이라는 분명한 보상을 받게 됩니다. 문제는 이러한 이동성이 우리는 물론 우리의 적에게도 너무나 유혹적인 대상이라는 점입니다.
이런 경우를 생각해 봅시다. 랩톱의 전원을 켜고 네트워크에 연결하고 있는 총 시간 중 회사의 네트워크에 연결하고 있는 시간은 몇 퍼센트나 될까요? 필자와 비슷하다면 아마 최대 20% 정도일 것입니다. 이는 곧 필자가 사용하고 있는 랩톱이 Microsoft의 네트워크 범위 안에서 네트워크 경계 방어에 의해 외부의 공격으로부터 안전하게 보호받는 시간이 전체의 20%에 불과함을 의미합니다. 그럼 여러 가지 목적으로 인터넷에 직접 연결하여 랩톱을 사용하는 나머지 80%의 시간은 어떨까요? (게다가 필자는 지구상에서 가장 위험한 네트워크에 꽤나 자주 접속하곤 합니다. 바로 컴퓨터 보안 회의에 참석할 때 사용하게 되는 호텔의 LAN이지요!) 또한 필자가 회사 네트워크에 연결하고 있을 때 이러한 환경에 있는 다른 컴퓨터로 인해 위험에 노출된다면 어떻게 해야 할까요?
보안 제어 기술은 위험 요소의 뒤를 따르면서 발전합니다. 때로는 한참 뒤쳐져 있는 경우도 있지만요. 과거에 바이러스는 클라이언트의 문제였습니다. 사용자들이 플로피 디스크를 돌려 가면서 썼기 때문이지요. 따라서 바이러스 백신 프로그램은 클라이언트에서 처음 선을 보이게 되었습니다. 그 후 전자 메일이 대중화되고 맬웨어가 전자 메일을 통해 웜으로 발전하게 되자 맬웨어 방지 프로그램이 탄생했고 전자 메일 게이트웨이에 도입되었습니다. 웹의 시대가 도래함에 따라 맬웨어는 트로이 목마로 진화했고 맬웨어 방지 프로그램도 인터넷 액세스 프록시 서버로 옮겨 가게 되었습니다. 지금까지 이야기한 내용은 아무도 토를 달지 않을 만큼 모두에게 익히 잘 알려진 보안 제어의 발전 경로입니다.
그럼 이제 같은 논리를 방화벽에 적용해 보겠습니다. 과거에는 네트워크 경계에 위치한 방화벽이 위협 요소로부터 충분히 보호할 수 있었지만, 이제 이러한 방화벽으로는 더욱 복잡하고 보다 빠르게 확산되는 새로운 유형의 위협을 방어할 수 없습니다. 또한 사람들이 사용하는 장치와 작업 방식도 크게 달라졌습니다. 많은 컴퓨터에 기밀 정보가 저장되어 있으며 컴퓨터 사용자들은 회사 네트워크에서 벗어난 곳, 즉 네트워크 경계 바깥에서 많은 시간을 할애하고 있습니다. 따라서 방화벽은 개별 클라이언트를 보호하는 방향으로 나아갈 수밖에 없는 것입니다. 확실히 클라이언트 방화벽은 이제 더 이상 선택이 아닌 필수입니다. 여러분의 컴퓨터를 회사 네트워크와 인터넷에서 모두 보호하려면 클라이언트 방화벽을 반드시 구축해야 합니다.

클라이언트 방화벽 및 보안 연극(security theater)
많은 사람들은 Windows® XP의 초기 릴리스에 클라이언트 방화벽이 포함되어 있다는 사실을 알지 못했습니다. 그다지 놀라운 일이 아닌 것이, 방화벽 기능은 기본적으로 해제되어 있고 다른 많은 기능 뒤에 가려져 잘 드러나지 않았기 때문이지요. 클라이언트 방화벽은 눈에 띄는 알림이나 사용법에 대한 지침도 없이 매우 조용하게 존재합니다. 그러나 분명히 실행되고 있습니다. 여러분이 클라이언트 방화벽을 사용하고 있었다면 Nimda, Slammer, Blaster, Sasser, Zotob을 비롯하여 네트워크 포트를 향해 원치 않는 트래픽 공격을 가한 여러 가지 위험으로부터 안전하게 보호받았을 것입니다. 클라이언트 보호의 중요성을 인식하게 되면서, Windows XP 서비스 팩 2(SP2)에서는 기본적으로 방화벽을 사용하도록 설정했고 두 개의 프로필(인터넷 및 회사 네트워크)을 만들었으며, 그룹 정책을 사용할 수 있도록 허용했습니다.
그러나 안타깝게도 두 가지 장애 요인으로 인해 Windows XP SP2 방화벽의 도입이 늦어지게 되었습니다. 바로 응용 프로그램 문제와 보안 연극(security theater) 문제 때문이었습니다. 많은 사용자들은 방화벽 때문에 응용 프로그램의 정상적인 실행이 중단되지 않을까 우려했습니다. 그러나 방화벽의 설계상 이러한 일이 일어나는 경우는 극히 드뭅니다. 방화벽은 컴퓨터에서 나가는 모든 아웃바운드 트래픽은 허용하지만 이전의 일부 아웃바운드 요청에 대한 응답이 아닌 모든 인바운드 트래픽은 차단합니다. 이러한 설계로 인해 클라이언트의 응용 프로그램이 중단되는 유일한 경우는 해당 응용 프로그램이 수신 대기 소켓을 생성한 다음 인바운드 요청을 수신하려고 하는 때에 해당합니다. Windows XP 방화벽에서는 프로그램이나 포트에 대한 예외를 간단히 추가할 수 있습니다. 그러나 그룹 정책을 통해서는 해당 작업을 수행할 수 없습니다.
이보다 더 큰 장애물은 다른 클라이언트 방화벽의 제조업체에서 실행하는 보안 연극이었습니다. 어떤 사람들은 모든 아웃바운드 트래픽을 무제한으로 허용하는 Windows XP 방화벽의 설계가 클라이언트 방화벽으로 사용하기에 부족한 점이 있다고 생각했습니다. 논쟁의 쟁점은 충분한 기능을 갖춘 클라이언트 방화벽이라면 사용자가 특별히 권한을 부여받지 않은 경우 인바운드 트래픽과 아웃바운드 트래픽을 포함한 모든 트래픽을 차단해야 한다는 데 있었습니다.
그럼 한번 생각해 볼까요. 두 가지 시나리오를 생각해 볼 수 있습니다.
  • 현재 로컬 관리자로 실행 중인데 맬웨어에 감염되었습니다. 이 맬웨어는 방화벽의 기능을 아주 간단하게 해제할 수 있습니다. 이 경우 아무 대책이 없습니다.
  • 반면, 로컬 관리자로 실행하고 있지 않으면서 맬웨어에 감염되었습니다. 이 맬웨어는 타사의 방화벽에 포트 및 IP 주소와 관련된 외국어가 빼곡히 적힌 대화 상자를 띄우고는 "이를 허용하시겠습니까?"라고 매우 심각하게 묻습니다. 물론 유일한 응답은 "예, 멍청한 컴퓨터씨. 날 좀 그만 괴롭혀요!"입니다. 그리고 대화 상자가 사라지면, 여러분의 보안도 그대로 안녕을 고하는 것이지요. 또는 이보다 더욱 일반적인 경우라면, 사용자가 승인한 프로그램의 세션을 맬웨어가 가로채 대화 상자 자체가 아예 나타나지 않는 것입니다. 이 경우에도 아무 대책이 없습니다.
여러분이 반드시 알고 넘어가야 하는 보안의 중요한 법칙이 있습니다. 보호라는 것은 여러분이 보호하려는 자산에 대해 수행되어야 하는 것이지 막아야 하는 대상에 대한 것이 아니라는 사실입니다. 보안을 위한 올바른 접근법은 조직의 모든 컴퓨터에 기능은 간단하지만 효과적인 Windows 방화벽을 실행하여 각각의 컴퓨터를 전 세계의 다른 모든 컴퓨터로부터 보호하는 것입니다. 이미 손상된 컴퓨터에서 나가는 아웃바운드 연결을 차단하려고 할 때 해당 컴퓨터가 사용자의 요청을 제대로 이행할 수 있다고 어떻게 장담할 수 있을까요? 그럴 수 없다는 것이 정답입니다. 아웃바운드 보호는 보안 연극입니다. 실질적으로 보안을 개선하기 위한 노력은 아무것도 하지 않으면서 마치 그렇게 하고 있는 것 같은 느낌을 주는 일종의 눈속임이라 할 수 있지요. 이 때문에 Windows XP 및 Windows Vista™ 방화벽에는 이러한 아웃바운드 보호 기능이 없는 것입니다. (Windows Vista에서의 아웃바운드 제어에 대해서는 이후에 좀 더 설명하도록 하겠습니다.)

Windows Vista의 새로운 기능
Windows 필터링 플랫폼은 새로운 네트워크 스택의 일부로, Windows Vista 방화벽의 토대가 되는 부분입니다. Windows XP와 마찬가지로 Windows Vista 역시 기본적으로 인바운드 트래픽을 차단합니다. 컴퓨터에서 사용하고 있는 프로필에 따라 네트워크 서비스에 대해 기본적인 예외가 있을 수 있습니다. 프로필에 대해서는 차후 다시 설명하도록 하겠습니다. 원하는 경우 인바운드 연결을 허용하는 규칙을 작성할 수 있습니다. Windows XP와 같이 Windows Vista에서도 기본적으로 대화형 프로세스에서 모든 아웃바운드 트래픽을 허용하지만 서비스 제한에 참여하는 서비스의 아웃바운드 트래픽은 제한합니다. 또한 추가로 아웃바운드 연결을 차단하는 규칙을 작성할 수 있습니다.
Windows XP와 Windows Vista의 가장 큰 차이점은 고급 보안 인터페이스 및 구성과 규칙에 대한 완전한 그룹 정책 기능의 지원입니다(그림 1 참조). 이전의 제어판 UI도 그대로 사용되며 변경된 내용은 거의 없지만 새로운 UI에 위치한 로깅 및 ICMP(Internet Control Message Protocol) 설정에 변경 사항이 있습니다. 이 새로운 UI인 고급 보안 MMC 스냅인을 통해 새롭고 유연한 모든 기능을 사용할 수 있습니다. netsh 명령 netsh advfirewall의 새 컨텍스트를 통해 규칙 추가 및 삭제를 스크립팅할 수 있고, 글로벌 정책 및 프로필별 정책을 설정 및 표시할 수 있으며, 방화벽의 활성 상태를 나타낼 수 있습니다. 또한 개발자는 FirewallAPI.dll 및 Netfw.h를 사용하여 방화벽의 모든 설정을 프로그래밍적인 방법으로 제어할 수 있습니다.
그림 1 고급 보안이 설정된 Windows 방화벽
그림 1 고급 보안이 설정된 Windows 방화벽
고급 보안 MMC는 마법사를 기반으로 합니다. 규칙을 만들 때 '프로그램, 포트, 미리 정의됨, 사용자 지정'의 네 가지 유형 중 하나를 선택할 수 있습니다. 이에 대한 설명은 그림 2를 참조하십시오.
Figure 2 규칙의 네 가지 유형 (Close Figure 2)

유형 | 목적
프로그램 | 특정 프로그램에 대한 트래픽을 허용하거나 차단하는 데 사용됩니다.
포트 | 특정 TCP 또는 UDP 포트의 트래픽을 허용하거나 차단하는 데 사용됩니다.
미리 정의됨 | 네트워크에서 파일 및 인쇄 공유 또는 원격 지원과 같은 Windows 기능을 사용할 수 있는 미리 정의된 기존의 규칙 그룹을 사용합니다.
사용자 지정 | 사용자가 원하는 대로 규칙을 구성할 수 있도록 모든 구성 요소를 제공합니다.
규칙을 작성할 때 참조할 수 있는 여러 가지 요소가 있으며, 모든 요소는 로컬 규칙에 사용할 수 있습니다. 또한 해당 규칙은 그룹 정책을 통해 적용됩니다. 여기에는 Active Directory® 사용자 및 컴퓨터 계정 및 그룹, 소스 및 대상 IP 주소, 소스 및 대상 TCP 및 UDP 포트, IP 프로토콜 번호, 프로그램 및 서비스, 인터페이스 유형(유선, 무선 또는 원격 액세스), ICMP 유형 및 코드 등의 요소가 있습니다.
구성이 완료되면 방화벽에서는 다음 순서에 따라 규칙을 처리합니다.
서비스 제한 Windows Vista의 일부 서비스는 Blaster와 같은 유형의 공격을 제어하기 위해 자체적으로 자신의 서비스를 제한합니다. 이러한 제한 중의 하나가 서비스에서 필요로 하는 포트 목록입니다. 방화벽에서는 이를 적용하고 서비스에서 다른 포트의 사용(또는 사용 요청 수신)을 차단합니다.
연결 보안 규칙 고급 보안 MMC는 방화벽은 물론 IPsec도 통합합니다. IPsec 정책에 포함되는 모든 규칙은 다음 순서로 처리됩니다.
인증된 우회 이를 사용하면 인증된 특정 컴퓨터에서 다른 규칙을 우회할 수 있습니다.
차단 규칙 이 규칙은 지정된 들어오는 트래픽 또는 나가는 트래픽을 명시적으로 차단합니다.
허용 규칙 이 규칙은 지정된 들어오는 트래픽 또는 나가는 트래픽을 명시적으로 허용합니다.
방화벽 규칙은 레지스트리에 저장되어 있습니다. 그러나 정확히 어디인지는 여러분께 말씀 드리지 않을 생각입니다. 아, 좋습니다. 알려 드리지요. 바로 다음의 위치에서 찾으실 수 있습니다.
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Defaults\FirewallPolicy\FirewallRule
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System
그렇지만 규칙을 절대 레지스트리에서 직접 편집하지 마십시오. 잘못하면 애지중지하던 컴퓨터를 옥션에 내놓아야 할 수도 있습니다. 설사 그런 일이 생기지 않는다 하더라도, 규칙을 편집하는 바람직한 방법은 고급 보안 MMC를 사용하는 것입니다.

네트워크 프로필
Windows Vista에서는 도메인, 개인, 공개의 세 가지 네트워크 프로필을 정의합니다. 컴퓨터가 도메인에 가입되어 있고 해당 도메인에 로그인되어 있는 경우 컴퓨터에는 도메인 프로필이 자동으로 적용되므로 사용자는 이를 직접 선택하여 적용하지 않아도 됩니다. 가정 또는 소형 사무실 네트워크와 같이 도메인이 없는 내부 네트워크에 컴퓨터가 연결되어 있는 경우 사용자 또는 관리자는 컴퓨터에 개인 프로필을 적용해야 합니다. 마지막으로, 컴퓨터가 인터넷에 직접 연결되어 있는 경우 사용자는 컴퓨터에 공개 프로필을 적용해야 합니다.
Windows Vista에서는 컴퓨터의 위치를 어떻게 결정할까요? 새 IP 주소를 수신하거나 새로운 기본 게이트웨이를 확인하거나 새 인터페이스를 받는 것과 같은 네트워크 변경 사항이 있을 때면, NLA(Network Location Awareness)라는 서비스가 해당 변경 사항을 감지하게 됩니다. 그리고 네트워크 프로필을 구축하게 됩니다. 이 프로필에는 컴퓨터가 도메인 컨트롤러에서 인증되었는지 여부, 게이트웨이의 MAC 주소 등과 같은 기존 인터페이스에 대한 정보가 포함되며 여기에 GUID가 할당됩니다. 그 다음 NLA에서 방화벽에 알림을 보내고 방화벽에서는 해당 정책(세 가지 프로필 각각에 대해 정의된 정책)을 적용합니다.
이 인터페이스가 지금까지 보지 못한 새로운 인터페이스이고 NLA에서 도메인 프로필을 선택하지 않은 경우, 연결할 네트워크 유형을 묻는 대화 상자가 나타나게 됩니다. 그리고 홈, 회사, 공공 장소, 이 세 가지 선택 사항이 나타납니다. 회사가 도메인 프로필이라고 생각할 수도 있으나 사실은 그렇지 않습니다. 컴퓨터가 도메인에 로그온하면 NLA에서 자동으로 도메인 프로필을 선택하게 되므로 사용자는 도메인 프로필을 전혀 볼 수 없습니다. 실제로 홈과 회사는 개인 프로필에 해당합니다. 이 둘은 아이콘 모양만 다를 뿐 기능적으로는 같습니다. (참고: 개인 프로필을 선택하려면 로컬 관리자이거나 로컬 관리자로 승격될 수 있어야 합니다.) 그리고 예상할 수 있듯이 공공 장소는 공개 프로필에 해당합니다.
Windows Vista에서는 네트워크 프로필이 컴퓨터의 모든 인터페이스에 적용됩니다. 다음은 NLA 의사결정 트리의 개요입니다.
  1. 모든 연결된 네트워크를 확인합니다.
  2. 공개로 분류된 네트워크에 연결된 인터페이스가 있습니까? 그렇다면 컴퓨터의 프로필을 공개로 설정하고 끝냅니다.
  3. 개인으로 분류된 네트워크에 연결된 인터페이스가 있습니까? 그렇다면 컴퓨터의 프로필을 개인으로 설정하고 끝냅니다.
  4. 모든 인터페이스에서 도메인 컨트롤러를 확인할 수 있으며 컴퓨터가 성공적으로 로그온되었습니까? 그렇다면 컴퓨터의 프로필을 도메인으로 설정하고 끝냅니다.
  5. 그 밖의 경우에는 컴퓨터의 프로필을 공개로 설정합니다.
최대한 제한적인 프로필을 선택하는 것이 우리의 목표입니다. 그러나 여기에는 두 가지 분명한 부작용이 있습니다. 우선, 컴퓨터의 이더넷 포트가 회사 네트워크에 연결되어 있고 이 네트워크의 무선 NIC가 아래층에 있는 스타벅스에 연결되어 있다면, 컴퓨터에서는 도메인 프로필이 아닌 공개 프로필을 선택하게 됩니다. 두 번째로, 컴퓨터가 공개 프로필로 인터넷에 직접 연결되어 있거나 개인 프로필로 가정의 LAN에 연결되어 있고 회사 네트워크에 연결하기 위해 VPN 연결을 설정한 경우 컴퓨터의 공개 프로필 또는 개인 프로필이 그대로 유지됩니다.
그렇다면 이것은 무엇을 의미할까요? 도메인 프로필에 대한 방화벽 정책에는 원격 지원, 원격 관리, 파일 및 인쇄 공유 등에 대한 규칙이 포함됩니다. 이 규칙에 의존하여 클라이언트에 원격으로 액세스하게 되면 클라이언트가 다른 프로필을 선택한 경우 원격으로 액세스할 수 없게 됩니다. 그러나 너무 실망하지는 마십시오. 필요한 인바운드 연결 유형에 상관없이 허용되며 VPN 연결에만 적용할 방화벽 규칙을 작성할 수 있습니다. 그러면 클라이언트가 도메인 프로필에 없어도 VPN을 통해 클라이언트를 관리할 수 있습니다.

아웃바운드 연결 제어
앞에서 클라이언트 방화벽의 전형적인 아웃바운드 보호 형식은 보안 연극에 불과하다고 말씀 드린 바 있습니다. 그러나 아웃바운드 제어 형식 중 한 가지는 매우 유용하게 사용할 수 있습니다. 바로 허용하지 않으려는 특정 유형의 트래픽을 관리적으로 제어하는 것입니다. Windows Vista 방화벽에서는 서비스 제한을 위해 이미 이 기능을 지원하고 있습니다. 방화벽은 서비스가 허용된 특정 포트에서만 통신할 수 있도록 허용하고 그 외에 서비스에서 시도하는 모든 작업을 차단합니다. 조직의 보안 정책에 맞게 특정 트래픽을 허용하거나 차단하는 별도의 규칙을 작성하여 이 방법을 구축할 수 있습니다(그림 3 참조).
그림 3 새 인바운드 규칙 마법사
그림 3 새 인바운드 규칙 마법사
예를 들어 사용자가 특정 인스턴트 메시징 클라이언트를 실행할 수 없게 하려면 해당 클라이언트의 로그인 서버에 대한 연결을 차단하는 규칙을 그룹 정책에서 만들면 됩니다.
그러나 이 방법에는 실질적인 제한이 있습니다. 예를 들어 Windows Live™ Messenger(이전의 MSN® Messenger)의 경우 로그인에 사용할 수 있는 서버가 여러 대이며 그 목록도 항상 변경됩니다. 또한 기본 포트 1863/tcp가 차단되면 80/tcp 포트로 대체됩니다. Windows Live Messenger가 로그인 서버에 연결할 수 없도록 차단하는 일은 매우 복잡하고 불확실한 작업입니다. 이 예를 든 이유는 관리를 위한 아웃바운드 제어가 유용하기는 하지만 소프트웨어의 설치와 실행이 허용된 소프트웨어 사용자에 대한 엄격한 제어가 필요할 경우에는 이 제어 방법이 소프트웨어 제한 정책을 대체할 수는 없다는 사실을 설명하기 위해서입니다.

컴퓨터 보호
이제 네트워크 경계는 사라졌습니다. 모든 컴퓨터는 각자 자신의 보안에 책임을 져야 합니다. 맬웨어 방지 프로그램이 클라이언트에서 네트워크 경계로 옮겨 갔듯이, 방화벽도 네트워크 경계에서 클라이언트로 옮겨 가야 합니다. 여러분은 지금 바로, 여러분의 컴퓨터에 이미 설치되어 있는 방화벽이 실행되도록 설정해야 합니다.
Windows XP에서 시스템을 실행 중이거나, Windows Vista로 전환한 경우 모두, 전체 클라이언트에 Windows 방화벽을 사용할 수 있으며 조직 내부 보안을 강화해야 할 경우 그에 충족하는 보안을 제공할 수 있습니다. 사무실에서 수천 킬로미터 떨어진 곳에서 모바일 장치를 사용하고 있는 작업자의 경우에도 말이지요.

자세한 정보
  • Windows Vista TechCenter: 고급 보안이 설정된 Windows 방화벽 시작
  • Windows Vista TechCenter: 고급 보안이 설정된 Windows 방화벽 - 진단 및 문제 해결
  • Steve Riley의 TechEd 유럽 지역 프레젠테이션: Windows Vista 방화벽과 IPSec의 향상된 기능
  • The Cable Guy: Windows Vista 및 Windows Server "Longhorn"의 새 Windows 방화벽
  • Windows Vista 방화벽 가상 실습

Steve Riley는 Microsoft Trustworthy Computing Group의 수석 보안 전략 전문가이자 TechNet Magazine의 객원 편집자로 활동하고 있습니다. 또한 전 세계 각지의 회의장에서 강연을 하고 있으며 고객의 보안 유지를 위해 노력을 기울이고 있습니다. 그의 최근 저서로는 Protect Your Windows Network(Addison-Wesley, 2005)가 있습니다. 문의 사항이 있으면 steve.riley@microsoft.com으로 연락하십시오.


 Security: 보안을 강화하는 Windows Vista의 새로운 ACL
Security Jesper Johansson

보안을 강화하는 Windows Vista의 새로운 ACL
한 눈에 보기:
  • ACL의 새로운 기능
  • 관리자에 대한 보다 강력한 제어
  • 신뢰할 수 있는 설치 관리자 권한
  • 수정된 사용자 및 그룹

Windows Vista에서 ACL(액세스 제어 목록)의 기본 구조는 크게 변경되지 않았습니다. 하지만 반드시 알고 있어야 할 작지만 중요한 많은 변경이 이루어졌습니다. Windows® XP에서 발생하는 몇 가지
문제는 ACL과 관련이 있었으므로 몇몇 변경은 필수 불가결한 것이었습니다. 첫 번째 문제는 대부분의 Windows XP 사용자가 관리자로 시스템을 실행한다는 것입니다. 즉, 대부분의 Windows XP 사용자는 기본 제공 Administrators 그룹의 구성원인 계정을 사용합니다. 가정에서 Windows XP를 사용하는 사용자의 경우 설치 중 추가되는 모든 계정이 관리자가 되므로 대부분 이러한 문제가 발생합니다. 따라서 이러한 사용자가 실행하는 프로그램도 운영 체제에 대한 무제한 액세스를 제공하는 관리자 권한으로 실행됩니다. 특히 이러한 프로그램이 유해한 종류의 프로그램일 경우에 문제가 될 수 있습니다.
두 번째 문제는 이전 버전 Windows의 기본 ACL의 경우 Everyone, Power Users 등에 대한 ACE(ACL 항목)를 포함하므로 대부분의 사용자들이 꺼려한다는 점입니다. 예를 들어 Windows XP의 부팅 볼륨 루트(일반적으로 C:\)에 대한 기본 ACL은 Everyone에는 읽기 권한을 부여하고 Users 그룹 구성원에게는 폴더를 만들 수 있는 권한을 부여했습니다. 마지막 문제는 Windows XP에서는 ACL로 수행할 수 있는 작업이 제한된다는 것입니다. 예를 들어 Windows XP에는 개체의 현재 소유자에게 권한을 할당할 수 있는 방법이 없었습니다. 소유자에게 권한을 부여할 수는 있었지만 소유자가 변경되는 경우 해당 권한이 새 소유자에게 상속되지 않았습니다. 마찬가지로 소유자는 개체에 대해 어떤 권한을 할당받았는지에 관계없이 항상 개체에 대한 암시적 권한을 가지고 있었습니다.
Windows Vista™를 개발하면서 Microsoft는 이러한 문제의 대부분을 해결하는 동시에 UAC(사용자 계정 컨트롤) 같은 다른 기능을 지원하기 위한 프로젝트에 착수했습니다. 이 기사에서는 Windows Vista의 액세스 제어와 관련된 주요 변경 사항에 중점을 두고 설명하며 다음 달에 제공할 기사에서 계속해서 액세스 제어를 관리하는 데 사용할 수 있는 도구에 대해 살펴보도록 하겠습니다.

새롭게 수정된 사용자 및 그룹
Windows Vista에서는 몇 가지 사용자와 그룹이 새로 도입되었으며 Windows XP에 있었던 몇 가지 이전 사용자와 그룹은 제거되었습니다. 일부 사용자와 그룹의 작동 방식도 수정되었습니다. 이러한 변경은 액세스 제어를 관리하는 방법에 영향을 줍니다.
Administrator - 기본적으로 사용되지 않음 RID(관련 식별자)가 500인 기본 제공 Administrator 계정은 이제 대부분의 경우 기본적으로 사용되지 않습니다. Administrator 계정은 원래는 다른 모든 계정이 실패한 경우 컴퓨터를 복구하는 데 사용하기 위한 비상용 계정으로 만들어졌습니다. 하지만 이 계정은 이러한 원래 용도에서 벗어나 표준 관리 계정으로 사용됨에 따라 몇 가지 보안 원칙을 위배하기에 이르렀습니다. 이 중 가장 주목할 만한 것은 책임에 관한 부분으로 시스템에서 변경 작업을 수행하는 사용자를 추적할 수 없다는 점입니다. 이에 따라 이 계정은 부분적으로 사용되지 않게 되었습니다. 그 결과 Microsoft는 이 계정을 완전히 사용하지 않으려고 했지만 결국에는 기본적으로 사용하지 않는 쪽으로 방향을 바꿨습니다. Administrators 그룹에 다른 로컬 계정이 없는 경우에는 복구 콘솔과 안전 모드에서 RID 500을 여전히 사용할 수 있습니다. 하지만 그 외의 경우에는 RID 500을 사용할 수 없으며 사용해서도 안 됩니다.
기본 제공 Administrator 계정과 Administrators 그룹에 포함된 다른 계정은 서로 다릅니다. RID가 500인 계정을 가리킬 때는 "Administrator"로 첫 글자를 대문자로 표기함으로써 이 계정을 기본 제공 Administrators 그룹의 구성원으로 포함되어 있는 다른 계정인 "관리자"와 구별합니다. 그룹 이름도 이와 비슷하게 첫 글자를 대문자로 표기합니다.
Windows XP의 기본 제공 Administrator 계정은 다른 관리자가 가지고 있지 않은 많은 특수한 권한을 가졌습니다. Windows Vista에서는 두 가지 예외적인 경우를 제외하고는 이러한 대부분의 권한이 제거되었습니다. 첫째, 다른 로컬 관리자가 없는 경우에 한해 사용하지 않도록 설정된 Administrator 계정을 복구 콘솔에서 사용할 수 있습니다. 둘째, Administrator 계정은 UAC의 영향을 받지 않으며 항상 모든 관리 액세스 토큰을 가집니다. Domain Administrator(도메인에서 RID가 500인 계정)에도 동일한 사항이 적용됩니다.
Power Users 권한 제거 이전의 Power Users 그룹은 완전히 실용적인 목적으로 제거되었습니다. 그룹 자체는 남아 있지만 그룹에 부여되었던 대부분의 권한이 제거되었습니다. Power Users 그룹의 구성원인 사용자는 자신을 관리자로 설정하지 않았을 뿐이지 사실상 관리자였다는 것은 모두 다 아는 사실입니다. 예전에 Windows XP 서비스 팩 2(SP2)를 실행하는 완벽하게 패치된 시스템을 인수받은 적이 있었는데 자신에게 관리자 권한을 부여하여 인수 작업을 수행한 결과 작업을 마치는 데 45분도 걸리지 않았습니다. 이는 조사, C++를 사용한 간단한 프로그램 작성, 인수를 완료하기 위해 로그오프 후 다시 로그온하는 작업 등에 소요된 시간이 모두 포함된 것이며 이 모든 작업은 Power Users 그룹의 구성원이었기 때문에 가능했습니다.
대부분의 조직에서 Power Users 그룹에 고급 권한을 부여한 다음 조직의 사용자를 이 그룹의 구성원으로 추가하므로 Windows Vista에서 이 그룹을 제거한다는 것은 현실적으로 가능하지 않았습니다. 하지만 Microsoft는 다음 버전 Windows에서는 Power Users 그룹을 완전히 제거하려고 계획하고 있습니다. 따라서 현재 Power Users 그룹을 사용하고 있다면 서서히 마이그레이션에 대한 계획을 세우는 것이 좋습니다.
신뢰할 수 있는 설치 관리자 신뢰할 수 있는 설치 관리자는 실제로는 서비스이며 사용자가 아닙니다. 신뢰할 수 있는 설치 관리자에 부여된 권한을 파일 시스템 전체에서 볼 수 있더라도 혼동하지 마십시오. 이제 서비스 강화를 통해 각 서비스를 다른 사용자와 마찬가지로 권한을 할당할 수 있는 완전한 보안 사용자로 취급할 수 있게 되었습니다. 이 기능에 대한 개요는 TechNet Magazine 2007년 1월호를 참조하십시오. Windows Vista Security(Grimes와 Johansson 공동 집필, Wiley Press, 2007)에서는 방화벽 및 IPsec과 같은 다른 기능을 활용하여 서비스를 강화하는 방법에 대해 자세히 다룹니다.
서비스 SID는 이제 예전과는 달리 NT AUTHORITY나 도메인과 같은 권한에서 발급되지 않습니다. TrustedInstaller 가상 계정의 전체 이름은 NT SERVICE\TrustedInstaller이고 SID는 다음과 같습니다.
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
그림 1과 같이 sc showsid 명령을 실행하면 존재하지 않는 서비스의 SID까지 포함하여 모든 서비스의 SID를 볼 수 있습니다.
그림 1 sc showsid로 존재하지 않는 서비스의 SID를 포함한 모든 서비스의 SID 표시
그림 1 sc showsid로 존재하지 않는 서비스의 SID를 포함한 모든 서비스의 SID 표시
이 SID는 S-1-5-80으로 시작합니다. 여기서 첫 번째 하위 권한은 SECURITY_SERVICE_ID_BASE_RID를 나타내는 80으로, 이는 이 SID가 NT SERVICE 하위 권한에 의해 서비스에 발급되었음을 의미합니다. 이는 어느 서비스에나 동일하게 적용됩니다. 나머지 하위 권한과 RID는 서비스 이름 자체를 기준으로 만들어집니다. 이름이 미리 결정되어 있으며 컴퓨터마다 다르지 않으므로 개발자는 서비스를 실제로 빌드 및 설치하지 않고도 자신의 서비스에 권한을 부여할 수 있습니다.
서비스 관리자에서 TrustedInstaller 서비스를 찾을 수 없는 경우 표시 이름이 "Windows 모듈 설치 관리자"인 서비스를 찾으십시오.
도움말 및 지원 계정 제거 Windows Vista를 새로 설치하는 경우에는 Support_xxxxxx 및 HelpAssistant 계정이 모두 제거되어 없으며 이전 버전 Windows에서 업그레이드하는 경우에는 그대로 남아 있습니다. Support_xxxxxx 계정은 지원 센터에서 스크립트를 실행하는 데 사용되었습니다. 자체 도움말 콘텐츠를 제공하는 일부 OEM에서도 고유의 지원 계정을 제공했을 수 있습니다. 이러한 OEM 계정이 어떻게 될지는 확실하지 않지만 OEM에서 이러한 계정을 더 이상 만들지 않는다는 것은 확실합니다. 엄밀하게 말하면 이러한 계정은 더 이상 필요하지 않습니다. 사실 보안 측면에서는 사용자가 또 다른 사용자로 도움말 센터에서 스크립트를 실행하도록 허용하는 것이 적절한 방법이 아니므로 이러한 계정은 제거하는 것이 바람직합니다. Windows Vista에는 이 작업을 수행하기 위한 새로운 메커니즘이 도입되었습니다.
HelpAssistant 계정은 원격 지원 중에 사용되었습니다. 도움말 센터와 마찬가지로 원격 지원 기능도 HelpAssistant 계정이 필요하지 않도록 다시 설계되었으며 이에 따라 HelpAssistant 계정도 제거되었습니다.
새로운 네트워크 위치 SID Windows NT® 기반 운영 체제에는 사용자가 네트워크에서 대화식으로 로그온함을 나타내는 NETWORK, INTERACTIVE 등의 몇몇 네트워크 위치 기반 SID가 있습니다. 터미널 서비스를 통해 로그온하는 사용자에게 할당되는 REMOTE INTERACTIVE LOGON SID도 있습니다. 터미널 서비스 사용자의 토큰에는 REMOTE INTERACTIVE LOGON과 INTERACTIVE LOGON이라는 SID가 모두 있습니다. Windows Vista에서는 DIALUP과 INTERNET이라는 두 개의 SID가 추가되었습니다. 전화 접속 연결을 통한 로그온을 나타내는 계정이 추가된 이유는 다소 불분명합니다. 특히 전화선이 사용 가능한 유일한 네트워크라면 아예 온라인을 포기하려는 사용자가 대부분일 것이므로 이러한 계정이 왜 필요한지 다소 모호하지만 Windows Vista에는 어쨌든 이 계정이 있습니다. INTERNET은 LAN 외부에서 사용자가 로그온함을 나타내기 위한 SID입니다. 하지만 NETWORK는 인터넷을 비롯하여 네트워크에서 로그온하는 모든 사용자를 나타냅니다.
OWNER RIGHTS 및 소유자 권한 Windows Vista에는 파일 액세스 시 파일을 소유하게 된 모든 사용자에게 적용되는 OWNER RIGHTS에 대한 SID가 추가되었습니다. 이 SID는 주로 소유자가 파일에 수행할 수 있는 작업을 제한하는 데 사용됩니다. Windows XP에 비해 Windows Vista의 소유자 권한 작동 방식은 두 가지 측면에서 크게 변경되었습니다. 첫째, 개체의 소유자이지만 개체에 대한 ACE가 소유자에게 적용되는 경우 ACE의 권한이 개체의 소유자라는 사실보다 우선합니다. 개체 소유자는 개체에 대한 암시적 권한을 가진다는 사실에 익숙해진 사용자에게 이는 시스템 관리의 일부 측면에 많은 영향을 주는 중대한 변경입니다. 둘째, 소유자가 개체에 수행할 수 있는 작업을 추가로 제한하는 데 OWNER RIGHTS SID를 사용할 수 있습니다.
그림 2와 같이 Jesper라는 사용자가 소유자이며 ACL이 있는 폴더가 있다고 가정해 봅니다. Jesper는 폴더의 소유자이지만 폴더에 대한 읽기 권한만 가지고 있습니다. Jesper에게는 폴더에 쓸 수 있는 권한이 없으므로 폴더에 파일을 복사하려고 하면 복사 작업이 실패합니다. 하지만 오류 메시지만 보고는 이유를 정확하게 알 수 없습니다. Windows 탐색기®에서 소유하고 있지만 쓰기 권한은 없는 폴더에 파일을 복사하려고 하는 경우 먼저 탐색기에서 파일을 복사하려면 권한을 높여야 한다는 메시지를 표시하고 권한을 높일 것을 요청합니다. 하지만 이 폴더에 복사할 수 있는 권한이 없으므로 파일 복사 작업이 실패합니다. "이 작업을 수행하기 위한 권한이 필요합니다."라는 오류 메시지와 함께 "다시 시도"(도움이 되는 것처럼 보임) 및 "취소" 단추가 표시됩니다. 이 동작은 사용자가 폴더의 소유자라는 점을 무시하고 수행됩니다.
그림 2 로컬 시스템과 한 명의 다른 사용자만 이 폴더에 액세스할 수 있음
그림 2 로컬 시스템과 한 명의 다른 사용자만 이 폴더에 액세스할 수 있음
Jesper가 파일에 대한 ACL을 변경하려고 하면 해당 작업을 수행하기 위해 토큰을 승격하라는 메시지가 표시됩니다. Jesper는 파일 소유자이므로 토큰을 승격할 수 있습니다. 달리 명시된 OWNER RIGHTS에 대한 ACE가 있지 않는 한 소유자는 ACL을 읽고 변경할 수 있는 암시적 권한(READ_CONTROL 및 WRITE_DAC)을 가집니다.
OWNER RIGHTS SID가 어떤 효과를 주는지 이해하려면 위의 ACL에 이 SID를 추가해 보십시오. 이제 그림 3에 나와 있는 권한을 가집니다.
그림 3 폴더에 대한 OWNER RIGHTS 권한을 추가하여 Jesper의 권한 변경
그림 3 폴더에 대한 OWNER RIGHTS 권한을 추가하여 Jesper의 권한 변경
이제 Jesper가 폴더 소유자이자 적절한 권한을 가지므로 Jesper 계정으로 이 폴더에 항목을 복사하려고 시도하면 복사 작업이 즉시 성공합니다. 하지만 Jesper가 개체에 대한 ACL을 변경하려고 하면 작업이 실패합니다. OWNER RIGHTS에 대한 ACE는 소유자에게 수정 권한만 허용할 뿐 DACL(임의 액세스 제어 목록)을 수정할 수 있는 권한은 부여하지 않습니다. 따라서 OWNER RIGHTS는 보안 설명자를 수정할 수 있는 권한인 WRITE_DAC를 소유자에게서 제거하는 데 주로 사용됩니다.
관리자가 개체 소유자를 변경하는 경우 OWNER RIGHTS 권한이 새 소유자에게 자동으로 상속되지 않습니다. 이 경우 OWNER RIGHTS ACE는 상속 전용이나 컨테이너, 개체 등 어떤 항목에도 적용되지 않음으로 표시하여 사용하지 않도록 설정됩니다. 이는 개체가 완전히 잠겨 관리자가 이를 사용할 수 없는 상황을 방지하기 위해서입니다. OWNER RIGHTS ACE를 다시 적용하려면 Administrator가 직접 ACE를 다시 설정하는 작업을 수행해야 합니다. 이를 위해서는 필요에 따라 이 ACE를 해당 폴더, 해당 폴더의 하위 폴더 및 폴더 내의 파일에 적용되는 것으로 표시해야 합니다.
사용자가 파일 서버에 파일과 폴더를 만드는 것은 허용하되 해당 폴더에 대한 ACL을 변경하는 것은 허용하지 않으려는 경우와 같이 관리자가 OWNER RIGHTS SID를 유용하게 사용할 수 있는 몇몇 흥미로운 시나리오가 있습니다. 사용자가 과거에 한 그룹의 구성원으로서 몇몇 개체를 만들었는데 나중에 비즈니스상의 이유로 그룹에서 제거된 경우를 예로 들 수 있습니다. 그룹에서 제거된 후에는 자신이 만든 개체에 대한 설정을 수정할 수 없습니다.
OWNER RIGHTS는 서비스 강화 영역에서 매우 광범위하게 사용됩니다. 서비스가 런타임에 임시 개체를 생성하는 경우 해당 개체를 만든 이는 서비스 자체의 SID가 아니라 서비스 프로세스의 기본 SID로 일반적으로 LocalSystem, NetworkService 또는 LocalService입니다. 이는 같은 프로세스 컨텍스트에서 실행 중인 다른 서비스가 개체를 수정할 수 있다는 것을 의미하며 결코 바람직한 동작이 아닙니다. 이러한 개체에 대해 OWNER RIGHTS SID를 설정하면 다른 서비스가 개체에 액세스하는 것을 방지할 수 있습니다.

기본 ACL
Windows XP의 기본 ACL도 사용하는 데 문제가 없었습니다. 사용자가 부팅 볼륨의 루트에 파일을 저장하는 것을 허용하는 것과 같은 몇몇 사소한 문제를 제외하고는 전반적으로 괜찮았습니다. 하지만 일부 OEM은 적절한 보안을 위해 좋은 것이 무엇인지는 자신들이 더 잘 안다고 생각했습니다. 그림 4의 화면은 주요 OEM에서 구성한 Windows XP Media Center Edition 컴퓨터의 Windows 디렉터리에 대한 ACL을 보여 줍니다. 이 OEM은 파일 시스템 보안을 기본적으로 사용하지 않았습니다.
그림 4 OEM에서 구성한 ACL
그림 4 OEM에서 구성한 ACL
Microsoft는 Windows Vista에서 ACL을 약간 수정했습니다. Windows XP에 친숙한 사용자라면 무엇보다도 모든 OS 파일을 Administrators 그룹이 소유하며 관리자는 OS 파일에 대한 모든 권한을 가진다는 사실을 잘 알고 있을 것입니다. Administrators 그룹의 구성원은 OS 파일에 무제한으로 액세스할 수 있었습니다. 하지만 Windows Vista에서는 그렇지 않습니다.
신뢰할 수 있는 설치 관리자 Windows Vista에서는 대부분의 OS 파일을 TrustedInstaller SID가 소유하며 이 SID만 OS 파일에 대한 모든 권한을 가집니다. 이는 Windows Vista에 포함된 시스템 무결성 작업의 일부이며, 특히 관리자나 로컬 시스템으로 실행되는 프로세스에서 자동으로 파일을 바꾸는 것을 방지합니다. 따라서 운영 체제 파일을 삭제하려면 운영 체제 파일에 대한 소유권을 확보한 다음 이를 해당 파일에 대해 삭제를 허용하는 ACE에 추가해야 합니다. 신뢰할 수 있는 설치 관리자는 LocalSystem으로 실행되며 시스템 무결성 레이블이 지정된 프로세스를 어느 정도 보호합니다. 이보다 낮은 무결성을 가진 프로세스는 소유권을 변경하기 위해 자신의 권한을 높일 수 없습니다. 예를 들어 일부 서비스는 로컬 시스템으로 실행되기는 하지만 무결성 수준이 보통일 수 있습니다. 이러한 서비스는 시스템 파일을 바꿀 수 없습니다. 따라서 이전과는 달리 이러한 서비스 중 하나를 악용하여 운영 체제 파일을 바꿀 수 없으므로 시스템에 루트킷이나 다른 맬웨어를 설치하는 것이 더 어려워졌습니다. 몇몇 시스템 바이너리가 있는 것만으로도 번거로워하는 시스템 관리자가 있는데 이제 이러한 시스템 관리자가 시스템 바이너리를 제거하는 것도 더 어려워졌습니다.
Deny ACE 파일 시스템에 있는 대부분의 개체의 경우 Everyone에 대해 Deny ACE가 설정되어 있는데 대부분의 관리자는 이러한 사실에 매우 놀라워합니다. "숨김 파일 및 폴더 표시" 옵션을 설정하면 친숙한 Documents and Settings 디렉터리가 표시됩니다. 하지만 이 디렉터리를 클릭하면 액세스 거부 오류 메시지가 나타납니다. Documents and Settings에서 어떤 작업이 수행되는지 알아보려면 그림 5의 디렉터리 목록을 살펴보십시오.
그림 5 디렉터리가 아니라 연결 지점인 Documents and Settings
그림 5 디렉터리가 아니라 연결 지점인 Documents and Settings
Documents and Settings는 실제로는 디렉터리가 아니라 연결 지점입니다. 연결 지점은 액세스를 다른 위치로 리디렉션하는 심볼 링크와 비슷합니다. 여기서는 C:\Users라는 디렉터리로 이동됩니다. Microsoft는 Windows Vista의 파일 시스템 네임스페이스를 대폭 수정했으며 그 결과 사용자 데이터가 C:\Users로 이동되었습니다. 이전의 "C:\Documents and Settings\<Username>" 네임스페이스 아래에 있던 다른 요소들도 이동되었습니다. 예를 들어 "C:\Documents and Settings\<Username>\Application Data"는 C:\Users\<username>\appdata\roaming으로 이동되었습니다. 그림 5와 같이 명령줄을 표시한 다음 dir /a 명령을 사용하면 이러한 변경 사항을 분명하게 확인할 수 있습니다. 네임스페이스가 이토록 대폭 수정된 이유는 사용자에게 디렉터리를 보다 알아보기 쉽게 표시하고 문서와 데이터를 보다 명확하게 구분하기 위해서입니다. 이제 개발자는 모든 데이터 파일을 My Documents 폴더에 저장하는 대신 사용자 프로필 아래에 고유의 폴더를 만들어 저장할 수 있으며 사용자는 여기에서 파일을 확인할 수 있습니다. 모든 사용자의 응용 프로그램 데이터는 이제 Documents and Settings\All Users\Application Data 대신 %systemroot%\ProgramData라는 숨겨진 폴더로 이동되었습니다.
Microsoft는 "C:\Documents and Settings" 네임스페이스를 제거하지 않았는데 이는 이전 응용 프로그램이 %USERPROFILE%과 같은 기본 환경 변수가 아니라 해당 이름을 사용하도록 하드 코드되어 있을 수도 있기 때문입니다. 이러한 응용 프로그램은 "C:\Documents and Settings"가 없으면 작동하지 않습니다. 이제 이러한 폴더는 이전 버전과의 호환성을 위해 연결 지점이나 심볼 링크로 표시됩니다. 이러한 경로를 하드 코드하는 응용 프로그램은 응용 프로그램에서 경로의 데이터에 액세스하는 방식에 따라 여전히 작동하지 않을 수 있습니다. 하지만 이러한 응용 프로그램은 영어가 아닌 다른 언어의 Windows 버전에서 이미 작동하지 않았습니다. 이게 바로 핵심입니다. Windows XP SP2, Windows Vista 등의 Windows 업데이트로 인해 타사 프로그램이 작동하지 않는 경우 그 원인은 대부분 해당 프로그램의 개발자가 올바르지 않은 가정을 하거나 바람직하지 않은 방식으로 Windows를 사용하는 데 있었습니다.
예를 들어 "C:\Documents and Settings\<Username>\My Documents\foo.txt"를 입력하여 파일을 여는 경우 해당 위치에 foo.txt라는 파일이 있으면 파일이 올바르게 열립니다. 하지만 "C:\Documents and Settings\<Username>\My Documents"로 이동하려고 하면 "액세스 거부" 오류 메시지가 표시됩니다. 그림 6의 ACL을 보면 그 이유를 알 수 있습니다.
그림 6 Documents and Settings에 설정된 Deny ACE
그림 6 Documents and Settings에 설정된 Deny ACE
목록의 첫 번째 ACE를 살펴보십시오. 이 ACE는 폴더 내용을 나열할 수 없도록 Everyone에 대해 설정된 Deny ACE입니다. Everyone은 트래버스 검사 무시 권한(SeChangeNotifyPrivilege)을 가지고 있으므로 프로그램은 연결 지점을 무시하고 절대 경로를 사용하여 문서를 열 수 있습니다. 하지만 사용자나 프로세스에서 연결 지점이 나타내는 디렉터리를 나열하려고 시도하는 경우에는 Deny ACE로 인해 실패하게 됩니다. 바로 이 때문에 사용자는 C:\Documents and Settings 내의 내용을 볼 수 없으며 "디렉터리"를 삭제할 수도 없습니다. Deny ACE를 설정하는 주요 이유는 사용자가 연결 지점을 삭제하여 이전 응용 프로그램이 작동되지 않게 되는 상황을 방지하는 데 있습니다. Deny ACE는 개발자에게 이전 네임스페이스를 사용하여 응용 프로그램을 코딩하는 대신 앞으로는 환경 변수나 레지스트리 문자열을 사용함으로써 향후의 변경 및 여러 언어를 사용함으로써 발생하는 문제로부터 응용 프로그램을 보호하도록 상기시키는 역할도 합니다.
모든 연결 지점은 기본적으로 숨겨져 있으므로 대부분의 사용자에게는 연결 지점이 표시되지 않습니다. Microsoft는 사용자가 연결 지점을 삭제할 수 없도록 "폴더 목록"에 대해 Deny ACE를 설정했습니다.
트래버스 검사 무시 사용자가 권한이 없는 폴더(또는 연결 지점) 내에 있는 파일에 대한 권한을 가진 경우 해당 파일에 액세스할 수 있는 이유는 모든 사람에게 트래버스 검사 무시 권한이 있기 때문입니다. 트래버스 검사 무시(SeChangeNotifyPrivilege)는 사실상 Windows의 가장 기본적인 권한으로, 프로세스에서 이 권한도 제거하도록 특별히 요청한 경우가 아니면 프로세스에 다른 모든 권한이 제거된 경우에도 이 권한은 부여됩니다. 이 동작은 Windows Vista에서 runas /trustlevel:0x10000 < 줄을 사용하여 프로세스를 실행하는 경우 수행됩니다. 즉, <command>에 지정된 프로그램이 제한된 토큰으로 실행되고 SeChangeNotifyPrivilege를 제외한 모든 권한이 프로세스 토큰에서 제거됩니다.
여기서 흥미로운 사실을 설명하자면 trustlevel 0x20000은 일반적인 SID 집합은 포함되어 있지만 권한은 제거된 토큰을 제공하며 0x40000은 완전히 일반적인 토큰을 제공합니다.

기본 사용 권한
Windows Vista의 파일 시스템에 대한 기본 사용 권한은 Windows XP와는 약간 다르게 변경되었습니다. Windows XP나 Windows Server® 2003에서 %systemdrive%(일반적으로 C: 드라이브인 부팅 볼륨)에 대한 ACL을 보면 기본 사용 권한을 확인할 수 있으며 Windows XP 초기 버전에서도 이와 비슷한 기본 사용 권한을 볼 수 있습니다.
D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU)
다음은 Windows Vista의 동일한 디렉터리에 대한 동일한 ACL입니다.
D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)
여기에는 눈여겨볼 만한 많은 차이점이 있습니다. 첫째, BA(BUILTIN\Administrators)에 대한 ACE가 이제 한 개가 아니라 두 개입니다. 하지만 최종 결과는 같습니다. Windows Vista에서는 둘 중 한 ACE는 상속되지 않으며 루트에 대한 모든 권한을 부여합니다. 다른 한 ACE는 IO(상속 전용) ACE로, 컨테이너와 개체에 상속되며 GA(일반 전체 또는 모든 권한)를 부여합니다. SY(LocalSystem)에 대한 한 ACE를 Windows Vista의 두 ACE로 대체하는 경우에도 결과가 동일합니다. Windows XP에서는 단일 ACE가 모든 권한을 부여했으며 개체와 컨테이너에 상속되었습니다. 다시 말해 결과만 보면 변경된 것이 없습니다. ACL이 변경된 주된 이유는 ACL을 보다 쉽게 관리하고 더 나아가 복원할 수 있도록 권한을 명료하게 분류하는 데 있습니다.
이보다 흥미로운 사실은 CO(Creator/Owner)에 대한 ACE가 사라졌다는 것입니다. 즉, 사용자가 파일 시스템 루트에 개체를 만드는 경우 더 이상 만든 이에게 특별한 권한이 부여되지 않습니다.
WD(Everyone)에 대한 ACE가 제거되었다는 사실도 알 수 있습니다. 보안에 관심이 있는 대부분의 사용자는 이 ACE가 수행하는 작업의 의미를 완벽하게 이해하지도 못하면서 이에 대해 지나치게 걱정하는 경향이 있었습니다. Microsoft는 Everyone이 기능적으로는 기본 제공되는 Users와 동일하다는 점을 설명하기 위해 수년 동안 노력했지만 허사였습니다. 결국 이 ACE를 포기하고 완전히 제거했습니다. BU(BUILTIN\Users)에 대해서도 동일한 ACE가 있으며 이 ACE도 컨테이너와 개체에 상속되므로 결과만 놓고 보면 변경된 것이 없습니다.
뿐만 아니라 BU(기본 제공 Users)에 대한 ACE 중 두 개가 AU(Authenticated Users)에 대한 ACE로 대체되었습니다. 그 이유는 INTERACTIVE가 기본 제공 Users의 구성원이라는 이유로 Guest 계정이 기본 제공 Users의 구성원이 되기 때문입니다. 하지만 Guest가 Authenticated Users의 구성원은 아닙니다. Guest 계정이 파일을 읽고 실행할 수 있도록 0x1200a9(읽기 및 실행) ACE는 BU에 계속 부여됩니다. 하지만 파일과 폴더를 만들 수 있는 권한을 부여하는 ACE는 대신 Authenticated Users에 부여되었습니다. 이는 Windows XP로부터 변경된 것입니다. Windows XP에서는 Guest가 루트에 파일을 만들 수 있었습니다. Windows Vista에서는 Guest가 이런 식으로 파일을 만들 수 없습니다. 하지만 Guest 계정이 설정되어 있는 경우 게스트가 부팅 볼륨의 루트에 액세스할 수 있는 방법이 없다면 이는 문제가 될 수 있습니다. 기본적으로 Guest 계정은 사용하지 않도록 설정됩니다.
위의 두 목록에는 매우 흥미로우면서도 문제의 소지가 있는 두 개의 ACE가 있습니다. Windows XP에서는 기본 제공 Users에 대해 0x100004를 지정하여 컨테이너에 ACE가 상속되도록 했습니다. 이 ACE는 컨테이너에 상속되므로 Users에 하위 폴더, 하위 폴더의 하위 폴더 등을 만들 수 있는 권한을 부여합니다. 하위 폴더에 상속되는 0x100002에 대한 상속 전용 ACE도 있습니다. 이 ACE는 루트 아래에 만든 폴더에 파일과 하위 폴더를 만들 수 있는 권한을 사용자에게 부여합니다. 다시 말해 이 두 ACE는 Guest 등의 사용자가 루트 아래에 파일과 폴더를 만들 수 있도록 허용합니다.
Windows Vista에서는 이 ACE가 컨테이너와 파일 모두에 상속되고 SD(보안 설명자 읽기)와 함께 GR(일반 읽기), GX(일반 실행) 및 GW(일반 쓰기)를 부여하는 상속 전용 ACE와 루트 자체에만 적용되며 LC 권한을 부여하는 ACE의 두 ACE로 바뀌었습니다. LC는 Active Directory®의 ACE의 간략한 용어입니다. Active Directory에서 LC는 사용자가 자식 개체를 나열할 수 있음을 의미합니다. 하지만 LC의 16진수 값은 0x4입니다. 디렉터리의 경우 0x4는 0x100004와 기능적으로 동일한 FILE_ ADD_SUBDIRECTORY를 의미합니다. 이는 0x100000(동기화를 위해 개체를 사용할 수 있는 권한)은 0x1200a9 ACE를 통해 이미 가지고 있기 때문입니다. 다시 말해 LC는 Windows XP에서와 정확하게 동일한 결과를 줍니다. 즉, 사용자가 루트 아래에 하위 디렉터리를 만들 수 있습니다.
이 16진수 값은 어디에서 온 것이며 무엇을 의미할까요? 지금쯤이면 이미 아셨겠지만 액세스 제어는 0x1200a9와 같이 모두 16진수(base16) 숫자로 구성됩니다. 이러한 값은 실제로는 "on"으로 설정된 액세스 마스크의 비트에 대한 비트 마스크 표현이며 값이 특정 ACE에서 사용된다는 것을 나타냅니다. icacls, sc 또는 secedit 같은 도구를 사용하여 ACL을 나열하면 이러한 비트 마스크가 각각 일치하는 텍스트 문자열이 있는 경우 훨씬 친숙한 텍스트 문자열로 표시됩니다.
따라서 LC가 무엇을 의미하는지 알아보려면 MSDN® 웹 사이트로 이동하고 문자열 LC를 찾은 다음 해당 Access right value(액세스 권한 값) 열에서 ADS_RIGHT_ACTRL_DS_LIST를 봅니다. 그런 다음 Iads.h 헤더 파일을 열어 해당 문자열을 찾으면 LC가 0x4에 해당한다는 것을 알 수 있습니다. 앞에 "ADS_RIGHT"가 없는 비 Active Directory 문자열의 경우 AccCtrl.h에서 16진수 값을 찾습니다. 16진수 값만 알면 WinNt.h 또는 AccCtrl.h의 액세스 마스크에서 이 값을 찾아 그 의미를 쉽게 확인할 수 있습니다.
이에 대한 자세한 설명이 필요하면 Protect Your Windows Network(Jesper Johansson과 Steve Riley 공동 집필, Addison-Wesley, 2005)를 구해서 읽어 보십시오. 이 책의 17장에는 SDDL(Security Description Definition Language) 문자열과 ACE를 분석하는 방법에 대한 자세한 설명이 나와 있습니다.
Windows Vista에서는 이러한 하위 디렉터리에 부여된 권한이 전적으로 (A;OICIIO;SDGXGWGR;;;AU) ACE에 의해 관리되는데 바로 이점이 Windows Vista와 Windows XP의 가장 큰 차이점입니다. Windows XP와는 달리 Windows Vista에서는 하위 디렉터리를 만든 사람에게 모든 권한을 부여하지 않고 대신 인증된 사용자에게 수정 권한을 부여합니다.
이 새로운 ACL이 가져다 주는 궁극적인 결과는 이제 개체를 만든 사람이 더 이상 특별한 권한을 가지지 않으며 권한 관련 작업이 좀 더 명료하게 수행된다는 것입니다. 가장 크게 변경된 사항이라 할 수 있는 것은 Authenticated Users가 관리자가 만든 하위 폴더에 대해서도 수정 권한을 가진다는 것이며 이는 Windows XP와 크게 다른 점입니다. Windows XP의 Users와 Authenticated Users에게는 관리자가 루트 아래에 만든 개체에 대한 아무런 권한도 없었습니다. Windows Vista의 변경된 ACE는 다소 혼란스러울 수도 있지만 궁극적으로는 Windows XP의 ACE에서 개선되었습니다.
요약하자면 Windows Vista에서는 Guest 사용자를 비롯한 모든 사람이 루트에서 파일을 읽고 실행할 수 있습니다. 파일과 폴더를 만드는 작업은 인증된 사용자만 수행할 수 있으며 이 경우 인증된 사용자에게 해당 파일과 폴더에 대한 수정 권한이 부여됩니다. 다시 말해 Windows Vista에서는 Guest 계정을 기본적으로 사용하지 않지만 Windows XP보다 사용 권한이 보다 강력하게 관리된다고 할 수 있습니다.

토큰 변경
Windows XP에서는 Administrators 그룹의 구성원인 사용자가 로그온하는 경우 사용자 토큰에 Administrators 그룹 SID가 포함되어 있으므로 사용자가 Administrators 그룹이 수행할 수 있는 모든 작업을 수행할 수 있습니다. 하지만 Windows Vista에서는 사용자 계정 컨트롤로 인해 이러한 일이 더 이상 가능하지 않습니다. 토큰에 Administrators SID는 여전히 포함되어 있지만 그림 7의 Process Explorer 스크린샷에서 볼 수 있듯이 이 SID만 Deny(거부)로 설정되어 있습니다.
그림 7 권한을 높이지 않은 한 UAC에서 액세스 거부용으로만 사용되는 Administrators SID
그림 7 권한을 높이지 않은 한 UAC에서 액세스 거부용으로만 사용되는 Administrators SID
액세스 제어를 수행할 때 이러한 토큰 내의 항목은 액세스를 거부하는 데에만, 즉 Deny ACE와 비교하는 데에만 사용됩니다. 해당 SID에 대한 Allow ACE는 모두 무시됩니다. 이는 사용자가 시스템에 관리자로 로그온한 경우를 비롯하여 항상 관리자가 아님을 의미합니다.

무결성 수준
이제 Windows에서는 무결성 수준으로 프로세스와 개체에 레이블을 지정할 수 있습니다. 이러한 무결성 수준은 실제로는 ACE로도 표시되지만 DACL에는 표시되지 않습니다. 대신 몇 가지 특수 플래그가 지정되어 SACL(시스템 액세스 제어 목록)에 포함됩니다. 예를 들어 NW 플래그는 낮은 무결성 수준의 프로세스가 높은 무결성 수준의 개체에 쓰지 못하도록 차단되었음을 나타내는 데 사용됩니다(SDDL_NO_WRITE_UP). Mark Russinovich는 TechNet Magazine 이번 호에서 제공하는 "Windows Vista 사용자 계정 컨트롤 들여다보기" 기사에서 이에 대해 자세히 다룹니다.

결론
Windows 2000과는 달리 Windows Vista의 액세스 제어는 눈에 띄게 수정된 것은 없지만 사소한 부분에서 많은 변경이 이루어졌습니다. 이러한 변경을 하나씩 놓고 보면 별 의미가 없어 보입니다. 하지만 이들을 전체적으로 보면 시스템 관리 시 수행해야 할 작업에 대해 재고할 점이 많다는 것을 알 수 있습니다. 더 나아가 이러한 변경은 UAC 및 서비스 강화와 같은 다른 많은 이니셔티브를 지원합니다. Windows Vista를 처음 사용하는 경우 불편함을 느낄 관리자도 있을 수 있습니다. 필자는 Windows Vista가 이런 저런 이유로 원치 않는 운영 체제 일부를 삭제할 수 있는 기능을 제한하는 "독재적인 운영 체제"라는 비판을 이미 들은 바 있습니다. 하지만 이러한 변경이 이루어진 데에는 그만한 이유가 있습니다. 시간을 들여 어떤 변경들이 이루어졌는지 꼼꼼히 분석해 보면 변경이 이루어진 이유를 이해할 수 있을 것입니다.

Jesper Johansson은 대규모 전자 상거래 회사의 보안 설계자로, 속성 및 서비스 범위와 관련된 응용 프로그램 보안 전략을 수립하는 업무를 담당하고 있습니다. 보안 분야에서 20년 동안이나 근무했으며 보안과 관련된 두 권의 책과 많은 기사를 집필했습니다. 정보 보안 관련 업무를 하지 않을 때는 스쿠버 다이빙을 가르칩니다.


 Security: 그룹 정책을 통한 하드웨어 제한 관리
Security Jeremy Moskowitz

그룹 정책을 통한 하드웨어 제한 관리
한 눈에 보기:
  • 하드웨어 설치 제한
  • 특정 장치 제한
  • 장치 클래스 제한

USB 디스크 키와 이동식 장치는 개인적 삶은 편하게 해 주지만 직업적 삶은 어렵게 합니다. 설치할 수 있는 하드웨어 장치와 설치할 수 없는 하드웨어 장치를 제어할 방법이 필요하기 때문입니다.
다행히 Windows Vista™와 차기 버전 Windows Server®(코드명 "Longhorn")의 그룹 정책을 사용하면 USB 마우스는 허용하고 열쇠고리형 USB 드라이브는 허용하지 않거나, CD-ROM 리더는 허용하고 DVD 라이터는 허용하지 않거나, Bluetooth는 허용하고 PCMCIA는 허용하지 않을 수 있습니다.
그룹 정책의 두 섹션인 컴퓨터 구성 | 관리 템플릿 | 시스템 | 이동식 저장소 액세스(그림 1 참조)와 컴퓨터 구성 | 관리 템플릿 | 시스템 | 장치 설치 | 장치 설치 제한(그림 2 참조)을 통해 하드웨어 보안을 강화할 수 있습니다.
그림 1 그룹 정책의 미리 정의된 하드웨어 제한
그림 1 그룹 정책의 미리 정의된 하드웨어 제한
그림 2 제한할 하드웨어 종류 사용자 지정
그림 2 제한할 하드웨어 종류 사용자 지정
첫 번째 집합인 이동식 저장소 액세스에서는 그 이름에서 알 수 있듯이 이동식 저장소(CD/DVD, 플로피 디스크 등)에 대한 정책 설정을 활성화하여 필요한 경우 해당 장치 유형 전체의 읽기 또는 쓰기를 제한할 수 있습니다. 그러나 장치 설치 제한만큼 강력하지는 않습니다.
이동식 저장소 액세스에는 사용자 지정 클래스: 읽기 권한 거부와 사용자 지정 클래스: 쓰기 권한 거부라는 정책 설정 그룹이 있습니다. 그런데 이동식 저장소 액세스 정책은 실제로 드라이버의 설치를 차단하지 않습니다. 하드웨어가 발견될 때는 해당 클래스의 드라이버가 이미 설치된 상태입니다. 정책이 실제로 차단하는 것은 장치의 읽기 또는 쓰기입니다. 다음 절에서는 장치 설치 제한 정책 설정을 살펴보면서 드라이버를 완전히 사용하지 못하도록 해 보겠습니다.

클래스와 ID에 대한 핸들 얻기
먼저 제한할 대상을 파악해야 합니다. 제한할 대상은 구체적 또는 포괄적으로 지정할 수도 있습니다. 즉, 특정 장치 "클래스"를 제한할 수도 있고 더 구체적으로 하나의 하드웨어 유형만 제한할 수도 있습니다. 또는 반대로 USB 마우스와 같은 특정 장치 클래스만 허용할 수도 있습니다. 그런데 이러한 작업이 실제로 효과를 내려면 제한하고자 하는 하드웨어를 찾아내야 합니다.
따라서 조이스틱 드라이버를 설치할 수 없게 하거나 USB 마우스만 설치할 수 있게 하려면 조이스틱과 USB 마우스를 가지고 있어야 합니다. 다른 방법은 인터넷을 사용하여 하드웨어 ID, 호환 가능 ID 또는 장치 클래스를 찾아내는 것입니다. 그런데 실제로 장치가 있으면 훨씬 간단해집니다. 장치가 있으면 이를 시스템에 연결하여 하드웨어 ID, 호환 가능 ID 또는 장치 클래스를 직접 확인할 수 있기 때문입니다. 이러한 정보를 확인하고 나면 장치를 사용하거나 사용하지 못하게 하는 방법을 정확히 알 수 있게 됩니다.
다음 예제에서는 Creative AutoPCI ES1371/ES1373이라는 특정 사운드 카드 제품군을 사용하지 못하도록 해 보겠습니다. 특정 USB 장치, USB 포트 등의 다른 장치를 사용하지 못하도록 할 때도 원하는 장치로 바꿔 이 방법을 사용하면 됩니다.
하드웨어 항목이 이미 설치된 시스템에서 장치 관리자를 엽니다. 장치를 마우스 오른쪽 단추로 클릭하고 속성을 선택한 다음 자세히 탭을 선택합니다. 기본적으로 "장치 설명"이 표시됩니다. 이 정보는 흥미롭긴 하지만 그다지 유용하지는 않습니다. 속성 드롭다운을 선택하고 그림 3에서처럼 "하드웨어 ID"를 선택합니다.
그림 3 장치의 자세히 탭
그림 3 장치의 자세히 탭
하드웨어 ID 페이지에는 장치 ID가 위에서부터 가장 구체적인 것부터 가장 포괄적인 것 순으로 표시됩니다. 하드웨어 ID 값 목록에서 최상위 항목을 자세히 보면 이 사운드 카드가 구체적으로 ES1371 사운드 보드의 Rev 2임을 알 수 있습니다. 매우 구체적인 정보입니다. 목록에서 아래로 내려갈수록 설명은 점차 범위가 넓어져 전체 제품군을 포괄하게 됩니다.
또한 속성을 호환 가능 ID로 변경할 수 있습니다. 여기서도 하드웨어가 설명되지만 하드웨어 ID의 정보보다 덜 구체적입니다. 호환 가능 ID의 정보는 이렇게 덜 구체적이고 더 많은 결과를 생성할 수 있기 때문에 사용 금지 목록에 비슷한 하드웨어를 더 많이 넣을 때 사용할 수 있습니다. 물론 제한하고 싶지 않는 하드웨어가 제한될 수도 있는 단점이 있습니다.
마지막으로, 속성 드롭다운에서 장치 클래스를 선택하면 가장 포괄적인 범주를 찾을 수 있습니다. 필자의 경우 사운드 카드가 단순하게 미디어로 표시됩니다. 하지만 미디어로 간주될 수 있는 장치가 많기 때문에 포괄적일수록 더 많은 주의를 기울여야 합니다.
사용할 값을 결정한 다음에는 잊어버리거나 잘못 입력할 경우에 대비하여 해당 값을 마우스 오른쪽 단추로 클릭하고 복사를 선택한 후 메모장에 붙여 넣습니다. 다음 단계에서 값을 정확하게 입력해야 하기 때문에 표시된 그대로 복사하는 것이 중요합니다. 값의 대문자와 소문자를 모두 정확하게 복사해야 합니다.
장치 관리자 대신 명령줄 명령을 사용하여 하드웨어 ID나 장치 클래스를 얻으려면 support.microsoft.com/kb/311272에서 Devcon 유틸리티를 살펴보십시오. 또한 Microsoft에서는 자주 사용되는 클래스에 대한 ID를 많이 제공하고 있으며 이 정보는 장치를 보유하고 있지 못한 경우에 유용합니다. 자세한 내용은 go.microsoft.com/fwlink/?LinkId=52665를 참조하십시오.

그룹 정책을 통한 하드웨어 액세스 제어
컴퓨터 구성 | 관리 템플릿 | 시스템 | 장치 설치 | 장치 설치 제한(그림 2 참조)에 있는 모든 정책 설정을 살펴보겠지만 장치의 사용 가능 여부를 제어하기 위해 필요한 설정은 실제로 하나뿐입니다.
먼저 GPO(그룹 정책 개체)를 만들어 제어하고자 하는 Windows Vista 시스템이 포함된 OU(또는 도메인 등)에 연결합니다. 그런 다음 GPO에서 컴퓨터 구성 | 관리 템플릿 | 시스템 | 장치 설치 | 장치 설치 제한 | 이러한 장치 ID와 일치하는 장치 설치 금지로 이동합니다. 정책 설정에서 사용을 선택하고 표시를 클릭한 다음 "내용 표시" 대화 상자에서 추가를 선택합니다. 그런 다음 그림 4에서처럼 "항목 추가" 대화 상자에서 이전에 저장한 장치 정보를 붙여 넣습니다.
그림 4 장치 ID를 붙여 넣어 정확하게 설명 얻기
그림 4 장치 ID를 붙여 넣어 정확하게 설명 얻기
여기서 중요한 문제가 있습니다. 시스템에 장치가 이미 설치된 경우에는 자동으로 제거되지 않으며 액세스가 제한되지 않습니다. 따라서 하드웨어를 제한하려면 Windows Vista 배포의 초기 단계에서 제한해야 합니다. 그런데 Windows Vista는 장치가 제거되었다 다시 설치될 때마다 재확인한다는 점을 유의해야 합니다. 주로 재확인되는 항목으로는 꺼냈다가 다시 넣는 USB 드라이브가 있습니다. Windows Vista는 장치가 다시 연결되는 경우에만 재확인하므로 처음에는 시스템에 장치 드라이버가 로드되었더라도 이 시점에서는 장치가 제한됩니다. 더 어려운 문제는 시스템과 함께 제공되어 제거되었다 재설치되지 않는 장치입니다. 이러한 장치에 대해서는 아직 확실한 해결책이 없습니다.
하드웨어 장치를 연결한 적 없는 시스템을 켜면 Windows는 드라이버 설치를 시도하면서 진행 중에 상태 정보를 제공합니다. 이러한 장치를 제한하는 정책을 설정하면 그림 5와 같은 결과를 볼 수 있습니다.
그림 5 금지된 장치 설치
그림 5 금지된 장치 설치

추가적인 하드웨어 제한
위의 예제에서는 하나의 장치만 제한했습니다. 원하는 경우에는 이와 반대로 기본적으로 모든 하드웨어를 제한하고 일부만 허용할 수 있습니다. 이러한 정책 설정의 목록은 그룹 정책의 컴퓨터 구성 | 관리 템플릿 | 장치 설치 | 장치 설치 제한 분기가 표시된 그림 2에서 볼 수 있습니다. 몇 가지 사용 가능한 설정에서 선택할 수 있습니다.
먼저 "관리자가 장치 설치 제한 정책을 다시 정의하도록 허용"이 있습니다. 기본적으로 Windows Vista의 로컬 관리자는 설정된 제한을 따라야 하지만, 이 설정을 사용하면 로컬 관리자가 기존 제한을 다시 정의하여 원하는 하드웨어를 모두 설치할 수 있습니다.
다음으로 "이러한 장치 설치 클래스와 일치하는 드라이버를 사용한 장치 설치 허용"이 있는데, 이 정책 설정에 장치 설명을 입력하면 시스템에 해당 장치를 설치할 수 있도록 명시적으로 허용하게 됩니다. 이 정책 설정은 예제에 사용되는 것처럼 장치 ID가 아니라 설치 클래스만 기준으로 삼는다는 점에 유의하십시오.
반대 효과를 얻으려면 "이러한 장치 설치 클래스와 일치하는 드라이버를 사용한 장치 설치 금지"을 설정할 수 있습니다.
그림 5에 나온 "정책에서 설치를 금지하는 경우 사용자 지정 메시지 표시(풍선 텍스트)"와 "정책에서 설치를 금지하는 경우 사용자 지정 메시지 표시(풍선 제목)"의 두 설정은 메시지를 사용자 지정하는 데 도움이 됩니다.
앞서 말했듯이 하드웨어를 설명하는 가장 포괄적인 방법은 하드웨어 클래스를 기반으로 하는 것입니다. "이 장치 ID 중 하나와 일치하는 장치 설치 허용" 정책 설정은 클래스 ID 설명을 기준으로 하지 않는 점에 유의해야 합니다. 클래스 ID 설명을 사용하려면 "이러한 장치 설치 클래스와 일치하는 드라이버를 사용한 장치 설치 허용" 또는 "이러한 장치 설치 클래스와 일치하는 드라이버를 사용한 장치 설치 금지"를 사용합니다. 두 번째 정책은 "다른 정책 설정에 의해 기술된 장치 설치 방지" 설정과 함께 사용할 때 가장 효과적입니다. 기본적으로 모든 것을 금지한 다음 이 설정을 사용하면 허용할 장치를 세밀하게 지정할 수 있습니다.
예제에서는 "이러한 장치 ID와 일치하는 장치 설치 금지" 정책을 사용하여 장치 ID를 기준으로 특정 하드웨어 유형을 제한했습니다. 장치 클래스를 사용하여 제한을 구현하려면 "이러한 장치 설치 클래스와 일치하는 드라이버를 사용한 장치 설치 허용" 또는 "이러한 장치 설치 클래스와 일치하는 드라이버를 사용한 장치 설치 금지" 등의 다른 구체적인 정책 설정을 이용해야 합니다.
"이동식 장치 설치 금지"는 USB 장치를 포함하여 이동식으로 설명되는 모든 하드웨어 장치를 제한하는 빠르고 일반적인 방법입니다. 이 설정은 상당히 포괄적이기 때문에 너무 자주 사용하지 않는 것이 좋습니다. 대신 앞서 설명한 방법을 사용하여 적당하게 제한적인 장치 ID를 얻어 구체적으로 금지하는 것이 좋습니다.
마지막으로, "다른 정책 설정에 의해 기술된 장치 설치 방지"는 설치할 수 있는 장치를 명시적으로 지정한 경우를 제외하고 기본적으로 모든 하드웨어를 제한하는 포괄적인 정책 설정입니다. "이 장치 ID 중 하나와 일치하는 장치 설치 허용" 등의 여러 "허용" 정책을 이 정책과 함께 사용하면 해당 환경에서 원하는 하드웨어만 허용할 수 있는 강력한 방법이 됩니다.

결론
Windows Vista의 그룹 정책에는 해당 환경에서 원하는 하드웨어만 허용하려고 할 때 매우 유용한 강력한 여러 가지 항목이 추가되어 있습니다. 배포 초기 단계에 정책 설정을 구현하기만 하면 네트워크에서 허용하고 싶지 않은 하드웨어의 연결을 완전히 차단할 수 있습니다.
Microsoft 그룹 정책 수석 프로그램 관리자인 Michael Dennis와의 인터뷰
최근 필자는 Microsoft의 그룹 정책 팀을 초창기부터 이끌어온 Michael Dennis와 인터뷰를 했습니다. Michael은 그룹 정책 팀을 떠나 Microsoft의 다른 분야에 진출할 예정입니다. 필자는 Michael과의 인터뷰를 통해 그룹 정책 팀의 지난 9년 동안의 발자취와 향후 전망에 대해 이야기를 나눴습니다.

Jeremy Moskowitz Microsoft에서 그룹 정책 팀을 이끄는 동안 달성한 최고의 성과는 무엇이라고 생각하십니까?

Michael Dennis 최고의 성과는 그룹 정책이라는 것의 개발에 집중하던 때로 거슬러 올라갑니다. 이미 Windows NT® 4.0에 시스템 정책이 있었기 때문에 저희는 이것을 분석하고 문제점을 찾았습니다. 당시는 Active Directory® 개발 단계였기 때문에 클라이언트와 서버의 관리 작업을 보다 효과적으로 처리하는 데 필요한 사항을 찾고 있었습니다.
그룹 정책을 계층 구조에 통합한다는 개념과 이 개념이 현실화된 적이 없었다는 것이 저희에게 가장 어려운 문제였습니다. 따라서 저희는 코어 인프라, 클라이언트 프로세스 및 Active Directory와의 통합에 주력했습니다.
최고의 성과에는 최악의 성과도 따랐습니다. Windows 2000에 도입한 GUI에 문제가 많았기 때문이죠. 그룹 정책의 경우 관리자가 전반적인 작동 방식을 잘 알아야 했기 때문에 이를 효과적으로 사용하려면 그룹 정책 박사가 되어야 했습니다. 그래서 저희는 그때 GPMC(그룹 정책 관리 콘솔)와 RSoP(정책 결과 집합)를 만들어서 제공했으면 좋겠다는 생각을 했고 사양에 포함했었습니다.

JM 그룹 정책 환경에 포함하고자 했던 항목으로는 무엇이 있습니까?

MD 다행인 점은 Windows 2000이 출시된 이후로 줄곧 원해 왔던 RSoP, GPMC, 향상된 여러 설정 등이 이제 Windows Vista에 포함되었다는 것입니다. 더 일찍 포함했으면 좋았을 것이라는 생각을 합니다.
또한 파트너가 보다 쉽게 그룹 정책 인프라를 확장할 수 있기를 바랬습니다. 저희가 개발한 서버/클라이언트 측 확장 모델에는 개발자의 작업이 많이 필요합니다. 그런데 분명한 건 ADM/ADMX 템플릿 구조에서 쉽게 확장할 수 있는 프레임워크를 제공하고 있다는 것입니다. 그렇지만 사용자가 이를 통해 더 많은 유형의 설정을 확장할 수 있으면 더 좋았을 것입니다.
또한 파트너와 타사 도구 개발자가 보다 쉽게 GPMC 보고 기능을 확장할 수 있기를 원했는데, 이 부분은 타사 도구 공급업체에서 요구가 많았던 사항이기도 합니다.

JM 그룹 정책 팀에 대해 사람들이 잘 모르고 있는 것은 무엇입니까?

MD 사람들은 때로 그룹 정책 팀이 전체 프로젝트에서 차지하는 역할에 대해 의아해합니다. 기본적으로 저희 팀은 인프라, 전달, 서버 및 클라이언트 측 기능을 구축합니다. Windows Vista 하나만 놓고 볼 때 저희는 Microsoft에서 약 120개의 팀과 함께 작업하여 새로운 설정을 도입했습니다.
부팅이나 로그온 시 시스템 속도 저하 문제가 전적으로 그룹 정책 때문이라고 생각하지 않으셨으면 좋겠습니다. 속도가 느려진다면 그 책임은 그룹 정책이 아니라 그룹 정책의 작업량에 있는 것입니다. 무언가 부하가 큰 작업을 하도록 그룹 정책에 지시하면 그룹 정책은 그 지시에 따를 뿐입니다. Microsoft Office를 시스템 단위로 설치하라고 지시하는 경우를 예로 들어보겠습니다. 그룹 정책은 지시된 작업을 수행하며 로그온 프롬프트가 나타나기 전에 모든 Office를 설치합니다. 이때 속도가 느려질까요? 당연합니다. 그런데 이는 그룹 정책 때문이 아니며 프로그램을 배포한 관리자가 자초한 결과일 뿐입니다.

JM 그룹 정책을 사용할 때 자랑할 만한 것들은 무엇이 있습니까?

MD 요즘에는 Windows Vista에 추가된 여러 가지 새로운 설정을 내세우고 싶습니다. USB 스틱 등의 하드웨어를 제한하는 이동식 장치 설정은 사용자의 요구가 많았던 설정입니다. Windows Vista에는 관리자의 제어 수준을 크게 높여 주는 약 2,400개의 설정이 있습니다. 저는 먼저 사용자에게 무엇을 제어하고 싶은지 물어본 다음 그 방법을 보여드립니다.

JM ADM 파일을 ADMX 파일로 바꾼 이유는 무엇입니까?

MD 기술적으로 Windows Vista의 새로운 중앙 저장소 기능에 액세스하기 위해 변경한 것은 아닙니다. ADMX로 변환한 주요 이유는 여러 언어를 적절히 지원하기 위해서였습니다.
기존의 다중 언어 환경에서는 GPO 내의 ADM 파일 내용이 다른 언어로 기록되는 상황이 종종 있었습니다. 그 유래를 살펴보면 ADM 형식은 Windows NT 4.0에서 차용되었고, 그 이전에는 Windows 98에서 차용되었으며, 다시 그 이전에는 Windows 95에서 차용되었습니다. 당시에 XML이 있었다면 XML이 유력한 파일 형식이었을 것입니다.
그런데 이제는 XML이 있기 때문에 보다 쉽게 여러 언어를 지원할 수 있게 되었으며, 앞으로는 저희가 제공하는 체계화된 언어로 레지스트리와 설정을 향상시킬 기회가 많아질 것입니다.

JM 그룹 정책 팀에서 일하면서 내부에서 극복해야 했던 가장 큰 어려움은 무엇이었습니까?

MD 저희 팀이 겪는 가장 큰 어려움은 Windows의 다른 구성 요소에서 정책을 통해 해당 기능을 활성화하도록 하는 것입니다.
다른 팀이 &quot;저희 팀에서 방금 이 새로운 멋진 기능을 개발했는데, 사용자가 이 기능을 끌 필요가 있을까요&quot;라고 말할 수 있으며, 충분히 이해가 가는 말입니다. 그러나 저희 팀은 이러한 문제를 무수히 많이 처리했습니다.
또한 새로운 기능인 WFAS(고급 보안이 포함된 Windows 방화벽)와 같이 정책으로 무언가를 활성화하는 작업에 대한 기술적 어려움도 존재합니다. WFAS는 다루기가 쉽지 않습니다. 정책으로 올바르게 이 기능을 활성화하는 것은 쉽지 않습니다. WFAS 팀이 Windows Vista용으로 개발한 인터페이스는 매우 우수하지만 이를 제대로 작업하기는 어려웠습니다.
Windows Vista 이전 버전의 Windows에서는 제품 팀이 정책을 통해 자신들의 구성 요소를 활성화하는 것에 대해 고려하지 않는 경우가 있었습니다. 그러나 Windows Vista 개발 단계에서는 상당히 많은 팀에서 저희 팀에게 이러한 방법을 문의했습니다. 이는 큰 발전이었습니다.
JM 향후 계획은 무엇입니까?

MD 저는 스마트 폰, Pocket PC 등을 담당하는 &quot;Mobile Information Worker&quot; 팀으로 옮깁니다 이 팀에서 저는 Windows Server System의 관리 기술 일부를 Windows Mobile® 장치로 확장하는 일을 담당할 것입니다.
관리 편의성에 대한 저의 시각과 열정을 이 새로운 분야에도 그대로 적용할 것입니다. 저는 그룹 정책 팀이 저 없이도 더 발전할 수 있는 매우 좋은 상황에서 이 팀을 떠납니다.

JM 독자에게 하고 싶은 다른 말씀이 있습니까?

MD 그룹 정책 개발에서 중요한 한 가지 단계는 고객에게 다가가 그들이 원하는 것을 이해하는 것이었습니다. 고객이 그룹 정책으로 처리하고자 하는 시나리오에 대해 체계적인 의견을 가지고 있고 무언가를 하기 위한 비즈니스 사례가 있다면 저희에게 알려 주셔야 합니다.
훌륭한 의견 수렴 페이지인 WindowsServerFeedback.com을 통해 누구든지 의견을 전달하실 수 있습니다. 여기서 Group Policy(그룹 정책) 단추를 찾아주십시오.
당면 문제와 비즈니스 사례, 시스템에서 수행해야 하는 작업과 그 이유 등을 포함하여 의견을 적어 주시면 상당히 도움이 될 것입니다. 그룹 정책에 대한 의사 결정을 내리는 담당자가 고객이 보낸 의견에서 모든 정보를 꼼꼼하게 살펴봅니다.
그룹 정책의 발전에 도움이 될 만한 의견이 있으면 필요한 것을 저희에게 말씀해 주십시오. 그러나 이유에 대한 설명 없이 &quot;이러 이러한 것을 수행하는 정책 설정이 필요합니다.&quot;라는 식의 의견은 피해주십시오. &quot;방법&quot;을 찾는 것이 저희의 일입니다. 그룹 정책 팀에서 진정으로 알아야 하는 것은 &quot;이유&quot;입니다.
JM Microsoft 그룹 정책 팀에서의 경험을 말씀해 주시기 위해 시간 내주셔서 감사합니다. 유용한 시간이었습니다.
MD 감사합니다.

Jeremy Moskowitz는 그룹 정책 분야의 MCSE이자 MVP로, 그룹 정책과 관련된 커뮤니티 포럼인 GPanswers.com을 운영하고 있으며 그룹 정책에 관한 집중적인 교육 워크숍도 진행하고 있습니다. 그는 최근에 Group Policy: Management, Troubleshooting and Security(Sybex, 2007)라는 저서를 집필했습니다. 문의 사항이 있으면 www.GPanswers.com을 통해 연락하십시오.


 Security: 모든 IT 조직이 갖추어야 할 네 가지 보안 기술
Security Matt Clapham and Todd Thompson

모든 IT 조직이 갖추어야 할 네 가지 보안 기술
한 눈에 보기:
  • 위험 관리 대시보드
  • 맬웨어 방지 프로그램
  • 네트워크 이상 탐지

대부분의 기업은 IT 보안과 관련하여 처리해야 할 거의 동일한 문제를 안고 있습니다. Microsoft도 예외는 아닙니다. 저희는 MMS(Microsoft® Managed Solutions)의 위험 관리 및 준수 팀에서 2년 동안 근무한 경험을 통해 이러한 상황에 대해 잘 알고 있습니다.
MMS에 대한 자세한 내용은 "자사 IT 부서를 위해 Microsoft가 제공하는 활력제"를 참조하십시오.
위험 관리 및 준수 팀은 고객 응대 서비스 및 인프라 통합을 위해 모든 MMS 환경의 위험 상황을 정의하고 모니터링하고 수정하는 작업을 담당하고 있습니다. 팀 구성 초기부터 팀 관리자인 Arjuna Shunn은 중앙 집중화되고 통합된 방식으로 필요한 제어 및 모니터링 기능을 제공하는 기술 솔루션이 있어야 한다는 점을 이미 인식하고 있었습니다. 이 문서에서 설명하는 기술들은 초기의 여러 아이디어와 2년 동안 팀 작업에서 Microsoft와 타사의 다양한 제품을 사용한 경험을 결합하여 얻은 직접적인 결과입니다.
무엇보다도 저희는 예방, 검색, 수정이라는 세 가지 기본 제어 유형을 포괄할 뿐 아니라 감사 및 보고 기능까지 제공하는 보안 솔루션이 필요했습니다. 저희는 이러한 도구 집합을 위험 관리 대시보드, 맬웨어 방지 프로그램, 네트워크 이상 탐지, 바람직한 구성 관리라는 네 가지 범주로 나누었습니다. 그리고 각 범주를 대표하는 기능을 위험 관리 작업에 적어도 하나씩은 포함하려고 했습니다. 또한 네 가지 영역의 기술을 활용하면 IT 보안 팀이 비용과 효율성 간에 적절한 균형을 이룰 수 있다는 것도 알게 되었습니다.
이러한 접근 방식을 취함으로써 보안 사고 대응 및 준수 관리라는 두 가지 주요 보안 관리 작업에서 많은 성과를 얻을 수 있었습니다. 하지만 이러한 도구 간에 궁극적으로 원하는 통합을 달성하기 위해 아직도 가야 할 길이 남아 있습니다. 통합된 기술 집합이 있다면 작업의 효율성 측면에서 훨씬 많은 부분이 개선될 것입니다. 하지만 아직까지 IT 업계는 이러한 통합 시스템을 갖추지 못했습니다.
그렇다고 IT 보안 팀이 아무것도 갖지 못한 것은 아닙니다. 네 가지 시스템이 함께 작동하고 상호 운영되어 더 나은 결과를 가져오기까지 단지 시간이 좀 더 필요할 뿐입니다. 이러한 시스템이 함께 작동하게 되면 시스템 보안 상황을 적극적으로 모니터링할 수 있을 뿐만 아니라 감사나 다른 일상적인 IT 작업에도 유용한 도구로 사용될 것입니다. 이 문서에서는 각 시스템의 이상적인 기능에 대해 설명하고 런타임 사용 환경에서 가져온 몇 가지 예를 소개하겠습니다.

위험 관리 대시보드
저희가 판단하기에 RMD(위험 관리 대시보드)는 필수 불가결한 요소입니다. RMD는 IT 보안 팀의 작업에서 단연 가장 중요한 기술입니다. 기밀성(Confidentiality), 무결성(Integrity), 사용 가능성(Availability) 및 신뢰성(Accountability)이라는 기업의 CIA2 위험 요소가 데이터 집계, 연결 및 위험 치료를 위한 단일 인터페이스가 없는 여러 시스템과 프로세스를 통해 모니터링되는 경우가 많습니다. 뿐만 아니라 규정 요구 사항으로 인해 기업이 충족해야 하는 데이터 투명성 수준은 갈수록 높아지는데 생성에서 실행에 이르기까지 정책을 신속하게 추적하기 위한 효율적인 시스템은 아직 준비되어 있지 않습니다. 이는 기업이 데이터 습득, 연결, 평가, 치료 및 준수에서 공통적으로 어려움을 겪고 있는 것을 보면 분명히 알 수 있습니다. 그림 1에 나오는 System Center Operations Manager 2007은 이 문서에서 제시하는 완전한 RMD 솔루션은 아니지만 다양한 리소스를 모니터링하고 관련 경고를 수집하는 단일 인터페이스를 제공합니다.
그림 1 네트워크 전체에서 경고를 보고 리소스를 관리하는 단일 인터페이스를 제공하는 System Center Operations Manager 2007
그림 1 네트워크 전체에서 경고를 보고 리소스를 관리하는 단일 인터페이스를 제공하는 System Center Operations Manager 2007
여러 소스에서 데이터를 얻어 이를 정규화할 수 있는 방법이 없으면 데이터 습득이 제한됩니다. 데이터 집계는 데이터를 모아 보관하기만 하는 일반적인 방식에서 탈피하여 데이터를 수집하고 이에 대해 보고하기까지 해야 하므로 그 자체로 매우 힘든 작업입니다. 데이터 집계를 마친 후에는 데이터 정규화라는 더 힘든 작업이 기다리고 있습니다. 데이터 정규화가 까다로운 이유는 이를 지원하는 데 필요한 공통 프레임워크를 구축하기가 매우 어렵기 때문입니다. 데이터를 정규화하지 않으면 서로 다른 시스템에서 가져온 보안 및 상태 관련 이벤트를 의미 있는 방식으로 비교할 수 없습니다.
필요한 자동화를 수행하려면 RMD가 이 문서에서 설명하는 보안 기술 이외의 소스에서 제공하는 데이터에 액세스해야 합니다. 전반적인 위험 상황을 결정하는 데는 보안과 관련이 없는 수많은 데이터가 사용될 수 있습니다. 라우터 로그, 자산 추적, 패치 상태, 현재 로그온한 사용자, 성능 보고, 변경 관리 데이터 등의 정보는 모두 보안 사고를 조사하는 사람에게 관련 정보를 제공합니다. 따라서 전체 시스템에서 이러한 모든 데이터에 액세스해야 합니다. 저희는 Microsoft 제품을 선호하는 기업의 인프라에도 타사 기술이 포함되어 있다는 사실을 잘 알고 있었으므로 공통 인터페이스를 통해 타사 기술에서 얻은 데이터도 허용하는 RMD를 만들려고 했습니다.
데이터 습득과 정규화가 가능해지면 그 다음 단계는 데이터를 연결하는 것입니다. 이 작업의 목표는 네트워크 이상 이벤트, 바이러스 백신 프로그램의 보고 이벤트, 바람직한 구성에서 벗어난 구성 이벤트 등 일련의 이벤트를 대처 가능한 위험 관련 데이터와 연결하는 것입니다. 의미 있는 위험 기반 경고를 생성하는 연결 논리를 만들어 내려면 많은 수동 작업이 필요합니다. 현재 사용할 수 있는 기술로도 어렵긴 하지만 이러한 연결 논리를 만들 수 있습니다.
데이터를 평가하는 데도 많은 수동 작업이 필요합니다. 연결이 가능한 경우에는 분석 담당자가 연결된 데이터를 검토하여 그 유효성을 결정해야 합니다. 연결된 데이터의 유효성은 연결의 기반이 되는 규칙이 얼마나 강력한가에 달려 있습니다. 따라서 IT 환경에 대한 위험을 평가하려면 이러한 연결된 데이터를 사람이 직접 분석하는 작업이 추가로 필요합니다. 이 경우 명확하고 체계적인 위험 관리 프레임워크가 있다면 적절한 평가 수준에 도달하는 데 필요한 수동 작업을 줄일 수 있습니다. 이러한 프레임워크가 없다면 해당 구현 환경에서 실제로 사용할 수 있는 연결 규칙 집합을 개발하기가 어렵습니다.
시스템이 위험을 평가할 수 있는 수준에 도달했다고 가정할 경우 그 다음 단계는 자동 치료입니다. 현재 기업에서 실제로 사용할 수 있는 기술은 자동 치료뿐이며 그것도 패치 관리나 바이러스 백신 프로그램과 같은 제한된 몇몇 기술에서만 가능합니다. RMD 시스템의 선봉에 있는 자동 치료는 IT 관리자가 IT 위험을 허용 가능한 수준으로 유지 관리할 수 있는 탁월한 기능을 제공합니다. 여러 가지 위험이 동시에 식별된 경우에는 연결 논리를 통해 자산 등급 데이터를 기준으로 사고 대응 작업의 우선 순위를 결정할 수 있습니다.
마지막 기술인 다양한 규정 요구 사항의 준수를 증명하는 작업은 IT 부서가 담당하고 있는 매우 어려운 작업이며 앞에서도 언급했듯이 이 시스템은 이러한 기능을 지원해야 합니다. 정책에 연결된 중앙 집중화된 위험 관리 시스템은 보고 자료와 준수 증거를 생성하는 데 매우 유용한 도구가 될 수 있습니다. 하지만 정책은 단순히 위치와 원인을 지정하는 것 이상이어야 합니다. 자동 치료를 용이하게 하기 위해서는 정책을 대시보드에서 모니터링 및 적용하고 피드백을 제공할 수 있는 표준 집합으로 변환해야 합니다.
따라서 이상적인 RMD는 기업의 상태 평가, 규정 및 정책의 준수, 위험 관리 프로세스에 사용할 수 있는 통합 인터페이스를 제공하는 수단이라고 정의할 수 있습니다. 이는 보안 및 상태와 관련된 여러 가지 제품 및 소스의 정보를 하나의 통합적인 위험 관련 보기에 결합함으로써 달성할 수 있습니다. 적절한 RMD 솔루션은 다음을 수행해야 합니다.
  • 여러 소스에서 데이터 집계, 정규화 및 연결
  • 자동화된 정보 수집 및 위험 평가 기능 제공
  • 정책에 규정 요구 사항 매핑 및 감사와 보고 지원
  • 조직의 필요에 맞게 수정이 가능한 통합 프레임워크 제공
대시보드는 유형별 또는 소스 시스템별로 가장 자주 발생하는 사고, 보류 중인 사고, 해결된 사고 등을 보여 줌으로써 데이터를 의미 있는 방식으로 구성 및 표시할 수 있어야 합니다. 또한 각 보고서 항목을 상세히 표시하여 보다 자세한 정보를 볼 수 있고, 사용자가 이벤트를 검토할 때 모든 관련 데이터에 쉽게 액세스할 수 있어야 합니다. 이를 통해 의사 결정 과정이 개선되어 사용자가 신속하게 의사 결정을 내릴 수 있게 됩니다.
RMD는 보안 직원뿐 아니라 관리자에게도 유용합니다. 대시보드는 환경을 전체적으로 볼 수 있도록 해 주므로 RMD는 모든 직원이 현재 상태를 볼 수 있는 중앙 위치의 역할을 합니다. 예를 들어 대시보드는 SMTP 게이트웨이에서 발생한 서비스 거부 공격에 대해 메시징 팀에 경고를 보낼 수도 있습니다. 이 사고는 위험 관리 팀에는 보안 관련 사고이지만 메시징 팀에는 사용 가능성 관련 사고입니다. 메시지 팀이 이러한 사고의 발생 지점을 파악하여 이를 해결하는 업무를 담당하지는 않더라도 팀이 관리하는 자산에 영향을 주는 이와 같은 사고에 대해 적어도 알고 있기를 원할 것입니다.

맬웨어 방지 기술
광범위한 맬웨어 방지 시스템은 코드와 사용자 작업에 숨겨진 예측할 수 없는 위협으로부터 인프라를 보호하는 데 매우 중요한 역할을 합니다. 현재 맬웨어로부터 인프라를 보호하기 위해 일반적으로 사용되는 두 가지 도구는 바이러스 백신 프로그램과 스파이웨어 방지 프로그램입니다. 예를 들어 그림 2의 Windows® Defender는 스파이웨어 방지 프로그램에 해당합니다. 이 두 도구 모두 다양한 유형의 침입을 효과적으로 예방하고 검색하며 해결합니다. 이 두 가지 보호 수단을 단일 솔루션으로 통합하여 시스템에 하나의 맬웨어 방지 스택을 두는 것은 단지 시간 문제일 뿐입니다.
그림 2 스파이웨어로부터 클라이언트를 보호하는 Windows Defender
그림 2 스파이웨어로부터 클라이언트를 보호하는 Windows Defender
완벽한 맬웨어 방지 솔루션이라면 실시간 모니터링 및 정기적인 검색을 수행해야 합니다. 또한 일반적인 위험 동작을 기준으로 알려진 맬웨어(바이러스, 스파이웨어, 루트킷 등)와 알려지지 않은 맬웨어를 중앙에서 보고해야 합니다. 강력한 맬웨어 방지 기술은 OS 및 응용 프로그램에 긴밀하게 통합되어 파일 시스템, 레지스트리, 셸, 브라우저, 전자 메일, 네트워크에 연결된 응용 프로그램 등 일반적인 시스템 진입점을 모두 감시합니다.
또한 맬웨어 방지 솔루션은 단순히 호스트 보안뿐 아니라 SharePoint®, 인스턴트 메시징과 같이 감염된 파일이 통과하기 쉬운 일반적인 메시징 및 공동 작업 서비스도 감시해야 합니다. 뿐만 아니라 알려지고 의심스러운 작업을 중지하는 것은 물론 사용자 데이터를 샅샅이 검색하여 사용자 문서에 숨겨져 있지만 아직 시스템을 감염시키지 않은 매크로 바이러스 같은 위험 요소를 제거함으로써 자동 예방 기능을 제공해야 합니다.
업데이트되지 않은 맬웨어 방지 프로그램은 무용지물이라는 것은 말할 필요도 없습니다. 최근에 나타나는 위협보다 한발 앞서 항상 맬웨어의 서명과 제거 체계를 업데이트해야 합니다. 새로운 위협이 출현하는 경우 공급업체는 다음 제로 데이 위협(Zero-Day Threat)이 발생하기 전에 추가 보호 수단을 마련하여 제공해야 합니다. 관리하기 쉬운 맬웨어 방지 솔루션은 또한 중앙에서 구성 및 업데이트할 수 있습니다.
물론 이러한 보호를 위해서는 어느 정도의 성능 저하를 감수해야 합니다. 성능이 저하되면 생산성도 떨어집니다. 그 결과 사용자가 맬웨어 방지 솔루션을 비활성화하기도 하는데 이 경우 시스템이 무방비 상태에 놓이게 됩니다.
마지막으로, 맬웨어 방지 시스템을 지원하는 보완 기술의 중요성을 간과해서는 안 됩니다. 방화벽, 사용자 권한 제한 등의 다른 전략도 악성 코드 및 사용자 작업으로부터 인프라를 보호하는 데 도움이 됩니다.

네트워크 이상 탐지
맬웨어 방지 프로그램은 시스템을 감시하는 반면, NAD(네트워크 이상 탐지)는 공통 경로를 모니터링하여 의심스러운 동작의 잘 알려진 징후를 감시하고 치료를 위해 이러한 정보를 RMD에 보고합니다. 예를 들어 그림 3에 나오는 방화벽이 이 범주에 포함됩니다. 의심스러운 동작의 예로는 잘 알려진 공격 트래픽(예: 웜 또는 서비스 거부) 또는 특정 패턴(예: 주민 등록 번호)과 일치하며 전자 메일을 통해 전송되는 데이터를 들 수 있습니다.
그림 3 네트워크 이상 탐지 솔루션으로서 중요한 역할을 하는 방화벽
그림 3 네트워크 이상 탐지 솔루션으로서 중요한 역할을 하는 방화벽
IT 관리에 투자하는 수많은 노력에도 불구하고 대규모 기업의 네트워크에서는 맬웨어 사고가 종종 발생할 수밖에 없습니다. NAD는 신속하게 치료하는 데 도움이 되는 초기 경고 시스템을 제공합니다. 또한 NAD 데이터 모니터링 기능과 중요한 정보의 누출을 식별하고 이를 중지하는 기능은 데이터 누출 방지와 규정 준수를 중요시하는 환경에서 정보를 보호하는 데 도움이 되는 간편한 도구입니다.
맬웨어 방지 기술과 마찬가지로 NAD도 최근의 위협이나 중요한 데이터 유형에 맞춰 꾸준히 변화되지 않는다면 무용지물이 될 수밖에 없습니다. 뿐만 아니라 뛰어난 NAD 시스템이라면 가양성(false positive) 보고 횟수를 최소화할 수 있도록 실제 이상에 대해 충분히 파악하고 있어야 합니다. 그렇지 않은 경우 관리자는 NAD의 보고서를 또 다른 허위 경보로 간주하고 이를 무시하게 됩니다.
NAD 시스템을 약간만 조정하고 사용해 보면 일반적인 트래픽 사용 패턴을 인식하고 모니터링할 수 있습니다. 새로운 종류의 맬웨어나 다른 공격이 사용 패턴의 변화와 함께 나타날 수도 있으므로 이는 매우 중요합니다. NAD 솔루션은 라우터, 스위치 및 방화벽의 데이터를 처리해야 하므로 네트워킹 장치도 전체 NAD 시스템에서 중요한 역할을 합니다. NAD 경고는 RMD의 연결 엔진을 통해 처리될 수 있습니다.
여기서 한 가지 흥미로운 가능성을 생각해 볼 수 있습니다. NAD 프로그램을 호스트 맬웨어 방지 소프트웨어나 방화벽에 기본 제공함으로써 관련된 모든 컴퓨터가 공격을 감시하여 공격이 전파되기 전에 이를 중단하는 총체적인 보호 기능을 구축하는 것입니다.

바람직한 구성 관리
대규모 기업의 IT 부서가 직면하고 있는 가장 큰 과제 중 하나는 시스템 구성을 적절한 상태로 유지하는 것입니다. 관리 용이성, 확장 단순화, 준수 보장, 다양한 형태의 침입으로부터 시스템 차단, 생산성 향상 등 다양한 이유로 시스템 구성을 유지 관리하지만 대부분은 보안을 위해서입니다.
DCM(바람직한 구성 관리)은 그 복잡함과 시작 비용으로 인해 대부분의 기업에서 아직까지는 상당 부분 개척되지 않은 영역입니다. 하지만 여러 연구에서 보여 주듯이 시스템 유지 관리는 장기적으로 비용을 절감하고 안정성을 향상시킵니다. 시스템 유지 관리에서 DCM(바람직한 구성 모니터링) 솔루션이 도움이 될 수 있습니다.
적절한 DCM 시스템은 자동으로 네트워크를 검색하여 새로운 시스템이 바람직하게 배포되도록 하고 구축된 시스템이 규정을 준수하는지 확인합니다. 최신 패치가 배포되었는지 확인하는지, 또는 도메인 권한을 가진 사용자의 수를 최소화는지에 관계없이 완전한 DCM 솔루션은 시스템을 구성 및 분석하고 각 구성이 이상적 구성과 얼마나 비슷한지 보고해야 합니다. 수정 작업은 네트워크에 새 시스템이 배포될 때 시스템을 패치하는 것과 같이 간단할 수도 있고 사용자에게 전자 메일 클라이언트 설정을 강제로 적용하는 것과 같이 강제적일 수도 있습니다. 여기서 핵심은 수정 작업을 조직의 정책 및 규정과 연결하는 데 있습니다. 단순한 유형의 맬웨어를 검색 결과에서 쉽게 찾아낼 수 있으므로 DCM은 맬웨어 감염을 식별하고 제거하는 데도 도움이 됩니다.
DCM은 RMD의 연결 엔진에 보고하는 주요 데이터 보고 기능 중 하나이며 문제의 호스트가 정상 상태에서 얼마나 벗어나 있는지에 대한 자세한 정보를 제공합니다. DCM 데이터의 적시성에 따라 1에서 5 경고 수준의 보안 사고가 결정되어 자산의 가치에 비례하는 간격으로 자산이 검색되도록 할 수 있습니다. 예를 들어 중요도가 낮은 자산은 매달 검색하고 중요도가 보통인 자산은 매주 검색하며 중요도가 높은 자산은 적어도 하루에 한 번은 검색하도록 설정할 수 있습니다.
DCM 설정은 적절한 NAP(네트워크 액세스 보호) 메커니즘에서도 중요한 부분을 차지합니다. DCM 설정을 통해 시스템은 연결된 모든 시스템이 적절하게 구성되었는지 확인할 수 있으며 새 시스템이나 알려지지 않은 시스템을 그 유효성이 검증될 때까지 차단할 수 있습니다. 뿐만 아니라 DCM은 공유의 취약한 액세스 제어 목록과 같은 구성상의 취약점도 찾아내 관리자가 이에 대한 적절한 조치를 취할 수 있도록 합니다.
클라이언트나 서버 같은 호스트에만 DCM이 적용된다고 단정하지 마십시오. 네트워킹 장치와 코어 디렉터리 자체도 DCM의 적용 대상이 될 수 있습니다. 적절하게 잘 설계된 네트워크가 있는 경우 이상적인 DCM 시스템이 관련 장치에 표준을 적용하는 것은 간단합니다. 여러 가지 가능성들을 상상해 보십시오. 라우터 구성을 수동으로 조정하는 대신 DCM에서 구현을 처리할 수도 있습니다. 또는 특정 서버 집합이나 클라이언트 집합과 연결된 표준 그룹 정책 설정 집합이 있다고 가정해 보십시오. DCM은 이러한 설정을 모니터링하여 도메인 설정이 변경되는 경우 경고를 보냅니다.
DCM으로 수집된 데이터는 IT 감사에 사용할 수 있을 만큼 신뢰성이 높습니다. 적절한 DCM은 변경 관리 및 규정 준수 제어 기능과 연결되어 감사 관련 문제를 시기 적절하며 지속적인 방식으로 처리할 수 있습니다. 예를 들어 저희 팀에서 수행하는 일상적인 제어 검사 중 하나는 MMS 서버의 로컬 관리자 구성원 자격이 변경되지 않았는지 확인하는 것입니다. 이러 식의 규칙 적용이 바로 DCM이 만들어진 목적입니다.
사용자의 IT 부서가 자동 수정 DCM 시스템을 사용할 준비가 되어 있지 않은 경우에는 바람직한 구성 모니터링이라는 DCM의 변형된 시스템을 배포하여 탁월한 결과를 얻을 수도 있습니다. 이 시스템 또한 구성 문제에 대한 보고 및 경고 기능을 제공합니다. 다만 치료 작업을 대부분 수동으로 수행해야 하므로 확장의 경제성 측면에서는 DCM 수준의 성과가 달성되지 않을 수도 있습니다. 하지만 중요한 것은 RMD에 필요한 알림과 데이터를 연결할 수 있다는 것입니다.
하지만 주의해야 할 한 가지 사항이 있습니다. 앞에서 설명한 두 가지 형태의 DCM, 즉 바람직한 구성 관리와 바람직한 구성 모니터링은 그 적용 범위를 표준 자산 수집 데이터와 결부하여 최소한의 중요 구성 항목으로 제한해야 합니다. 그렇지 않으면 IT 팀에 필요한 융통성이 떨어질 수 있습니다. DCM 구성 지침이 시대에 뒤떨어질 경우 이는 유용한 도구가 아니라 순식간에 운영상의 부담으로 전락하게 됩니다. 따라서 최적의 자산 구성 방법이 무엇인지에 대한 최신 동향을 따라가는 것이 매우 중요합니다. 더 나아가 해당 자산이나 응용 프로그램을 위한 최선의 구성 방법에 따라 DCM 구성 지침에 대한 정기적인 업데이트를 DCM 시스템에 포함할 것을 권장합니다.

결론
조직에서 자체적으로 만든 것이든 저명한 공급업체에서 구입한 것이든 대시보드는 사고에 대응하기 위한 팀의 기본 도구 역할을 수행하므로 매우 중요합니다. 맬웨어 방지 프로그램 또한 나날이 급증하는 위협으로부터 인프라를 보호하므로 역시 중요합니다. 네트워크 이상 탐지는 단순히 맬웨어 서명과 호스트 침입을 탐지하는 것에서 벗어나 이제 데이터 유출 탐지까지 포함하는 수준으로 변화하고 있습니다. 특히 마지막의 데이터 유출 탐지 기능은 다음 단계라고 할 수 있는 네트워크 위반을 방지하는 데 도움이 됩니다. 바람직한 구성 관리는 아직까지는 생소한 개념이기는 하지만 조만간 구성을 모니터링하고 유지 관리하기 위한 기반으로 자리잡을 것입니다. 어느 공급업체의 도구를 사용하는지는 중요하지 않습니다. 네 범주에 해당하는 도구를 각각 하나씩은 갖추고 있어야 합니다.
지금까지 살펴본 바에 따르면 Microsoft를 비롯하여 이 네 가지 영역을 모두 다루는 단일한 종합 솔루션을 제공하는 공급업체는 없습니다. 각자의 필요에 맞는 제품을 찾아서 선택하는 것은 여러분의 몫입니다. 이 문서에서 사용자 조직의 보안 관리를 위해 고려해야 할 사항과 조직이 달성하려는 목표가 무엇이고 이상적인 솔루션이 수행하는 작업이 무엇인지 파악하셨기 바랍니다.

Matt Clapham은 Microsoft IT 부서 내 인프라 및 보안 그룹의 보안 엔지니어로, 이전에는 Microsoft Managed Solutions의 위험 관리 및 준수 팀에서 2년 동안 근무했습니다.
Todd Thompson은 Microsoft IT 부서 내 인프라 및 보안 그룹의 보안 엔지니어로, 이전에는 Microsoft Managed Solutions의 위험 관리 및 준수 팀에서 2년 동안 근무했습니다.


 Security: 인증 관리를 위한 새롭고 강력한 도구
Security Kevin Dallmann

인증 관리를 위한 새롭고 강력한 도구
한 눈에 보기:
  • ILM-CM 아키텍처
  • 관리 및 템플릿
  • 워크플로 생성

여느 때와 다름없이 업무를 보고 있는데 헬프 데스크 담당자로부터 프로덕션 시스템 중 하나에서 인증서가 만료되었다는 소식을 갑자기 전해 들었다고 가정해 보십시오. 현재 시스템이 다운되었으므로 인증서를 갱신할 때까지 회사의 작업이 중단되고 그로 인해 수익 손실이 발생할 것입니다.
PKI(공개 키 인프라) 관리를 담당하고 있다면 인증서가 예기치 않게 만료되어 매우 놀랐을 것입니다. 평온한 날이 이제는 꿈이 되어버립니다.
Microsoft는 Windows® 2000과 Windows Server® 2003에 PKI를 추가함으로써 조직이 저렴하면서도 효율적인 방식으로 고유의 내부 PKI 환경을 구현할 수 있는 방법을 제공했습니다. 그러나 아쉽게도 Microsoft® PKI 서비스에는 생성된 인증서의 수명 주기를 관리할 수 있는 기능이 없습니다. 그런데 Microsoft는 최근 인증 관리 제품을 확보한 후 인증 관리와 Microsoft® Identity Integration Server(MIIS)의 ID 준비 기능 및 제어 기능이 결합된 ILM(Identity Lifecycle Manager)을 출시했습니다. 이 문서에서는 ILM으로 조직의 인증서 및 스마트 카드 관리 업무를 보다 쉽게 수행하는 방법에 대해 살펴보겠습니다.

ILM-CM 아키텍처
ILM-CM 아키텍처를 구성하는 핵심 요소는 ILM-CM 서버와 관련 구성 요소입니다(그림 1 참조). ILM-CM 서버는 하나 또는 여러 개의 CA(인증 기관)와 상호 작용하도록 설정된 단일 서버에 설치할 수 있습니다. ILM-CM을 사용하려면 인증서 환경을 관리하는 데 사용되는 인증서 정보, 정책 및 기타 관련 데이터를 저장하는 SQL Server™가 있어야 합니다. 또한 사용자 및 보안 권한을 관리할 수 있도록 Active Directory®가 있어야 합니다. 필요한 구성 요소 및 버전을 보려면 그림 2를 참조하십시오.
Figure 2 ILM-CM 지원 인프라 (Close Figure 2)

구성 요소 | 버전
Active Directory | Windows Server 2003
데이터베이스 서버 | SQL Server 2000 SP3 이상 또는 SQL Server 2005
인증 기관 | Windows Server 2003 Enterprise Edition 또는 Data Center Edition
SMTP | SMTP 서버
그림 1 ILM-CM 아키텍처
그림 1 ILM-CM 아키텍처
ILM-CM 환경이 완전하게 설치되고 나면 모든 인증서 요청이 ILM-CM 서버와 통신하게 됩니다. ILM-CM 서버는 인증서와 관련된 모든 정보를 SQL Server 데이터베이스에 저장해야 하며, 이러한 정보는 향후에 인증서와 관련된 보고를 하거나 경고를 생성하거나 워크플로 환경을 유지 관리하는 데 사용할 수 있습니다.
ILM-CM 소프트웨어 아키텍처는 기본적으로 ILM-CM 서버, CA 플러그 인, 클라이언트 측 구성 요소라는 세 개의 상위 요소로 구성됩니다. 서버 소프트웨어는 CA나 ILM-CM 전용의 서버에 설치하여 실행할 수 있습니다. 서버 소프트웨어가 설치되면 ILM-CM 서버가 CA, SQL Server 데이터베이스 및 Active Directory와 통신합니다. 서버는 인증서 관리자가 인증서 정책 및 워크플로를 구성하고 인증서 구독자가 소프트웨어 인증서를 요청 및 갱신하는 데 사용할 수 있는 웹 포털도 제공합니다.
CA가 ILM-CM 서버와 통신하기 위해서는 관리하려는 모든 CA에 ILM-CM 정책 모듈과 끝내기 모듈을 설치하고 구성해야 합니다. 이 두 모듈은 데이터베이스에 인증서 정보를 기록하는 데 사용됩니다. CA에서 인증서를 발급하면 끝내기 모듈이 인증서 정보를 ILM-CM 서버로 보내고, 그러면 서버는 데이터베이스에 인증서 정보를 기록합니다.
해당 환경에서 스마트 카드를 관리하려는 경우에는 ILM-CM 스마트 카드 클라이언트 소프트웨어를 설치해야 합니다. 이 소프트웨어는 ILM-CM 서버와 상호 작용해야 하는 모든 클라이언트 컴퓨터에 필요합니다.

ILM-CM 설치
마법사가 설치 과정을 단계별로 안내하므로 ILM-CM 서버 설치 작업은 매우 쉽습니다. 그러나 마법사를 실행하려면 몇 가지 기능이 사전에 설치되어 있어야 합니다.
ILM-CM을 설치하려면 무엇보다도 Active Directory와 ILM-CM 스키마 확장이 필요합니다. 스키마 확장에서는 ILM-CM이 프로필 템플릿을 구현하는 데 필요한 몇 가지 추가 Microsoft .NET Framework 보안 특성을 추가합니다.
이외에도 .NET Framework 2.0과 앞에서 언급한 SQL Server, CA, SMTP 서버 등의 구성 요소가 설치되어 있어야 합니다. CA와 다른 서버에 ILM-CM을 설치하려는 경우 해당 CA에서 ILM-CM 설치 마법사를 실행하여 CA에 ILM-CM 모듈을 설치해야 합니다. 설치가 끝나면 브라우저에서 http://hostname/CLM으로 이동하여 ILM-CM 포털에 연결할 수 있습니다.
인증서 만료/갱신 알림을 사용하려면 ILM-CM 서버에서 ILM-CM 서비스를 구성해야 합니다. 먼저 Active Directory에 적절한 계정을 만듭니다. ILM-CM 서비스를 연 다음 이 계정을 로그온 계정으로 추가합니다. 그런 다음 해당 사용자를 ILM-CM 서버 내의 IIS_WPG 그룹 및 로컬 관리자 그룹에 추가하고, 그룹 정책을 통해 "운영 체제의 일부로 작동, 보안 감사 생성 및 프로세스 수준 토큰 바꾸기" 권한을 추가합니다. ILM-CM 서비스를 설정하고 나면 ILM-CM 서버에서 SQL Server 데이터베이스를 검색하여 만료된 인증서를 확인할 수 있으며 인증서 소유자나 관리자에게 전자 메일 알림을 보낼 수 있습니다.

ILM-CM 관리
ILM-CM은 각각 사용자, 인증서 및 스마트 카드 관리 작업과 관련된 기능별 영역으로 나뉘어져 있는 웹 인터페이스를 통해 관리합니다. 적절한 관리 권한으로 ILM-CM 포털에 연결하면 ILM-CM 환경을 관리하는 데 사용할 수 있는 여러 가지 관리 작업이 표시됩니다(그림 3 참조). Common Tasks(일반 작업) 구역에는 새 인증서 집합이나 스마트 카드에 사용자를 등록하는 등의 관리 옵션이 있습니다. 여기에서 요청을 관리하고 승인할 수도 있습니다.
그림 3 ILM-CM 관리 포털 작업
그림 3 ILM-CM 관리 포털 작업
사용자나 인증서를 찾아야 하는 경우 Manage Users and Certificates(사용자 및 인증서 관리) 작업 영역을 사용합니다. 이 영역의 작업을 통해 인증서를 찾거나, 복구하거나, 해지하거나, 갱신할 수 있습니다. 해지 목록을 찾을 수도 있습니다.
스마트 카드를 사용하는 조직에는 Manage User Smart Cards(사용자 스마트 카드 관리) 영역이 매우 유용합니다. 예를 들어 사용자가 자신의 카드를 잠근 경우 인증서 관리자가 여기에서 카드 잠금을 해제할 수 있습니다. 로컬 카드 판독기에서 스마트 카드를 검색하고 볼 수도 있습니다.
Requests(요청) 영역에서는 인증서 관리자가 사용자의 인증서 요청을 검토하고 승인할 수 있습니다. 예를 들어 보류 중 상태의 요청에 포함된 모든 인증서를 볼 수 있습니다. Administration(관리) 영역에서는 프로필 템플릿을 만들고 관리할 수 있습니다. 마지막으로 Reports(보고서) 영역은 이름에서 알 수 있듯이 사용자 및 인증서와 관련된 보고서를 개발하고 만드는 데 사용합니다.
ILM-CM 포털에 대해 인증할 때 계정에 관리 권한이 없는 경우 인증서 사용자를 위한 자체 서비스 관리 기능을 제공하는 구독자 페이지가 표시됩니다(그림 4 참조). 이 포털에서 사용자는 해당하는 특정 정책 구성에 따라 자신의 인증서와 스마트 카드를 보고 관리할 수 있습니다. 일반 작업에는 인증서 또는 스마트 카드 요청, 기존 인증서 검토, 스마트 카드 PIN 변경 등이 있습니다.
그림 4 사용자의 자체 관리를 위한 구독자 포털 페이지
그림 4 사용자의 자체 관리를 위한 구독자 포털 페이지
어느 조직에서나 인증서 또는 스마트 카드의 발급, 갱신, 대체 및 해지를 위한 높은 수준의 위임 워크플로 프로세스를 제공하는 것은 어려운 작업입니다. 이제 ILM-CM을 통해 이러한 작업을 위임함으로써 보안을 보다 확실하게 보장할 수 있게 되었습니다. 한 사용자가 자신의 스마트 카드 PIN을 잊어버렸다고 가정해 보십시오. 위임 워크플로 모델을 사용하는 경우 사용자가 헬프 데스크 지원 부서에 도움을 요청할 수 있으며 지원 부서의 직원은 확인을 위해 사용자에게 몇 가지 질문을 할 수 있습니다. 사용자가 질문에 올바르게 대답하면 지원 부서 직원이 사용자의 스마트 카드 잠금을 해제합니다. 위임 워크플로 모델의 또 다른 예로, 랩톱 컴퓨터를 분실하거나 인증서가 실수로 삭제된 경우 사용자의 EFS(암호화 파일 시스템) 인증서를 복구하는 것을 들 수 있습니다.

프로필 템플릿
프로필 템플릿은 ILM-CM의 전체 워크플로 관리 프로세스를 사용할 수 있게 해 주는 기본 구성 요소로서, 하나 이상의 인증서 템플릿이 포함된 단일 관리 개체로 간주됩니다. 프로필 템플릿은 해당 인증서 환경에서 워크플로 프로세스의 작동 방식을 관리할 수 있도록 생성 및 구성됩니다. 프로필 템플릿의 가장 중요한 특징은 단일 항목으로 관리할 수 있는 여러 개의 인증서 템플릿을 포함할 수 있다는 것입니다. 즉, 인증서의 전체 수명 주기에 걸쳐 인증서 프로세스를 추적하는 한 개의 템플릿으로 여러 사용자를 관리할 수 있습니다.
인증서를 컴퓨터에 저장하거나(소프트웨어 기반) 스마트 카드에 저장하도록(하드웨어 기반) 프로필 템플릿을 구성할 수 있습니다. ILM-CM 관리 포털의 샘플을 복제하여 이러한 템플릿을 만들 수 있으며, 프로필 템플릿 내에 여러 가지 관리 정책 구성 요소를 정의할 수 있습니다(그림 5 참조).
그림 5 프로필 템플릿
그림 5 프로필 템플릿
대부분의 정책 구성 요소는 소프트웨어 및 스마트 카드 프로필 모두에 적용할 수 있습니다(그림 6 참조). 이들 중 몇몇 정책 구성 요소에 대해서는 부연 설명이 필요합니다. 인증서 등록 프로세스를 수행하는 동안 Enroll Policy(등록 정책) 구성 요소를 사용하여 등록 프로세스의 흐름과 관련된 특정 기준을 정의할 수 있습니다. 예를 들어 사용자가 부서 코드, 전자 메일 주소, 관리자 등의 정보를 입력하도록 데이터 수집 기능을 설정할 수 있습니다. 사용자가 인증서를 등록하고 나면 이와 관련된 공문을 자동으로 인쇄하는 정의를 만들 수도 있습니다.
Online Update Policy(온라인 업데이트 정책)는 조직에 매우 유용합니다. 이 정책은 인증서 내용, 인증서 템플릿, 스마트 카드의 애플릿을 업데이트할 수 있으며, 인증서 만료 날짜가 다가오면 인증서 자체를 업데이트한다는 점을 제외하고는 Renew Policy(갱신 정책)와 비슷합니다. 이 정책을 완전하게 사용하려면 Active Directory의 다중값 특성에 대한 액세스를 허용하도록 ILM-CM 서비스와 web.config 파일을 설정해야 합니다. 또한 클라이언트 컴퓨터에 온라인 업데이트 서비스를 설치해야 합니다.
EFS 암호화를 사용하는 회사에는 Recover On Behalf Policy(대리 복구 정책)가 매우 유용합니다. 누군가가 실수로 자신의 암호화 인증서를 삭제했다고 가정해 보십시오. 이 정책 구성 요소를 사용하면 헬프 데스크 보안 팀이 사용자의 개인 키를 요청하는 워크플로를 설정할 수 있습니다. 그러면 사용자는 ILM-CM 서버에서 생성한 비밀 암호가 포함된 전자 메일을 받아 자신의 개인 키를 검색할 수 있으며, 마지막으로 ILM-CM 서버의 비밀 웹 링크로 이동하여 관련 개인 키로 인증서를 검색할 수 있습니다. Recover On Behalf Policy(대리 복구 정책)는 특히 직원이 조직을 떠났지만 보관을 위해서나, 회사의 규정을 따르거나, 기타 용도로 해당 직원의 데이터를 복구해야 하는 경우에도 매우 유용합니다.
Renew Policy(갱신정책)를 사용하면 인증서를 갱신하는 데 필요한 일회용 암호 비밀 키를 설정하여 사용자에게 이를 전자 메일로 보냄으로써 갱신 프로세스를 보다 안전하게 만들 수 있습니다. 인증서를 해지한 다음 이를 복원하고 CRL(인증서 해지 목록)에서 제거하려는 경우 Reinstate Policy(복원 정책)를 사용하여 해당 워크플로 프로세스를 정의할 수 있습니다.
Recover Policy(복구 정책) 및 Revoke Policy(해지 정책)라는 두 가지 고유한 정책 구성 요소는 소프트웨어 인증서 정책에만 관련이 있으며 스마트 카드와는 관련이 없습니다. 컴퓨터에 저장된 사용자 인증서가 삭제되거나, 컴퓨터가 다시 구성되거나 도난당하는 경우 Recover Policy(복구 정책)를 사용하여 CA에 보관된 인증서나 키를 복원하는 프로세스를 정의할 수 있습니다. Revoke Policy(해지 정책)를 사용하면 정적 해지 사유를 설정하거나 해지 요청을 하는 사용자가 해지 시 사유를 지정하도록 허용할 수 있습니다.
이외에도 스마트 카드 프로필 템플릿과 관련된 다섯 개의 추가 관리 정책이 있습니다(그림 7 참조).
Figure 7 스마트 카드 프로필 정책 (Close Figure 7)

구성 요소 | 설명
Replace Policy(바꾸기 정책) | 사용자의 스마트 카드가 분실되거나 도난당하는 경우에 대비하여 프로필을 정의합니다.
Disable Policy(해제 정책) | 인증서가 만료되기 전에 스마트 카드의 인증서를 해제하는 프로세스를 정의합니다.
Retire Policy(폐기 정책) | 스마트 카드의 모든 인증서를 해지하는 프로세스를 정의합니다.
Unblock Policy(차단 해제 정책) | 스마트 카드의 사용자 PIN 차단을 해제할 수 있는 사람을 정의합니다.
Temporary Cards Policy(임시 카드 정책) | 임시로 사용할 대체 스마트 카드를 정의합니다. 이 경우 사용자는 새로운 서명 인증서를 받지만 기존의 프로필 암호화 인증서를 가져와 이 인증서의 정보를 해독할 수 있습니다.
Retire Policy(폐기 정책)에는 스마트 카드의 사용자 데이터 삭제, 사용자 및 관리 PIN 차단, 관리 PIN 재설정 등의 여러 가지 다양한 작업을 정의할 수 있습니다. Unblock Policy(차단 해제 정책)는 일반적으로 사용자가 자신의 PIN을 잊어버렸거나 ILM-CM에서 할당한 PIN으로 새 카드가 제공된 경우에 사용합니다. 이 경우 사용자는 스마트 카드의 차단을 해제해 줄 것을 요청합니다.
다른 관리 제품과 마찬가지로 보고는 매우 유용한 기능입니다. 인증서나 스마트 카드 환경의 스냅숏을 캡처하는 기능은 어느 조직에나 매우 중요합니다. ILM-CM에는 스마트 카드 인벤토리, 요청 요약, 인증서 사용과 만료 및 다른 많은 기능이 포함된 여러 개의 보고서가 기본적으로 포함되어 있습니다. 모든 데이터는 SQL Server 데이터베이스에 저장되므로 추가 보고서가 필요한 경우에는 다른 보고 시스템과 마찬가지로 사용자 지정 쿼리를 작성할 수 있습니다.

워크플로 개발
이제 ILM-CM으로 생산성이 높은 워크플로 프로세스를 정의하는 방법을 살펴보겠습니다. 여러 명의 시스템 관리자가 각 시스템의 SSL 인증서를 관리 및 유지하고 있다고 가정해 보십시오. 이때 첫 번째로 던져야 할 질문은 프로세스의 핵심적인 측면이 무엇인가 하는 것입니다.
시스템의 유형에 따라 인증서 요청 파일을 만드는 다양한 방법이 프로세스에 포함되어야 할 수도 있습니다. 따라서 가장 먼저 수행해야 할 작업은 모든 시스템에서 인증서 요청을 만드는 방법에 대한 자세한 지침을 제공하는 인트라넷 페이지를 개발하는 것입니다.
관리자가 요청 파일을 만들고 나면 인증서 승인을 위해 이를 ILM-CM 사용자 포털로 전송할 수 있습니다. 관리자는 ILM-CM 워크플로 프로세스를 통해 인증서 요청을 확인하고 승인해야 하는 여러 명의 승인자를 정의할 수 있습니다. 인증서가 승인되고 나면 사용자가 ILM-CM에서 인증서를 검색할 수 있습니다. ILM-CM은 SQL Server 데이터베이스에 인증서 정보를 저장하므로 관리자가 기록 정보를 검색할 수 있습니다.
1년 후 인증서의 만료 날짜가 다가오면 ILM-CM은 인증서 만료 날짜가 다가오므로 인증서를 갱신해야 함을 알리는 전자 메일 알림을 요청자에게 보냅니다. 이러한 워크플로 프로세스를 마련해 놓으면 인증서가 예기치 않게 만료되어 하루 일과를 모두 망치는 일이 없을 것입니다.

요약
Microsoft PKI 환경을 사용하는 회사에서 ILM-CM을 사용하면 PKI 환경을 관리하는 데 많은 도움이 됩니다. ILM-CM은 조직이 보안 인증 프로세스를 개선하고 디지털 인증서 및 스마트 카드를 관리하는 데 드는 비용과 복잡함을 줄일 수 있도록 지원합니다. 또한 ILM-CM은 오늘날 대부분의 회사에서 필요로 하는 인증서 및 스마트 카드 워크플로 프로세스를 개발하는 기반이 됩니다.
Microsoft는 ILM-CM을 위한 외부 API 지원도 구현했습니다. 조직에서 사용자 지정 응용 프로그램을 사용하는 경우 이러한 응용 프로그램에서 ILM-CM API 지원을 사용할 수도 있습니다.
ILM-CM에 대한 자세한 내용은 microsoft.com/technet/clm을 참조하십시오. go.microsoft.com/fwlink/?LinkId=87336에서 빠른 시작 안내서를 참조할 수도 있습니다.

Kevin Dallmann은 Accenture의 수석 시스템 엔지니어 컨설턴트로, 주로 대규모 엔터프라이즈 환경의 Active Directory 및 PKI 환경을 지원하는 업무를 담당하고 있습니다. 또한 MCSE와 MCT 자격증을 보유하고 있으며 Microsoft 교육 과정의 강사로 활동하고 있습니다.


 From The Editor: 보안 문제
From The Editor
보안 문제
Joshua Trupin

최근 들어 보안 문제의 관리가 다소 용이해졌다고 느끼지 않으십니까? 물론, 그 공로를 TechNet Magazine에서 일하는 우리 자신에게 모두 돌리고 싶지만, 다른 몇 가지 중요한 요인이 있습니다. 그 중 가장 큰 두 가지가 바로 인식과 견고성입니다.
인식은 잠재적인 위협과 사회 공학 트릭을 인지하는 동시에 설치된 소프트웨어를 보호하는 정기 패치와 업데이트에 지속적으로 주의를 기울이는 것을 말합니다. 반면에 견고성은 소프트웨어를 보다 안전하게 만들고 노출되는 기능을 기본적으로 해제함으로써 공격 노출 영역을 최소화할 수 있다는 것을 말합니다.
TechNet Magazine을 정기적으로 읽는 것도 빼놓을 수 없는 요인입니다. 매우 중요한 요인이죠. 이미 명성이 자자한 이 보안 특별판에는 회사에서 보다 뛰어난 보안 분석가/담당자가 되는 데 유용한 7가지 기사가 실려 있습니다. Mark Russinovich가 UAC에 대해 자세히 설명하는 기사를 시작으로, Windows 방화벽에 대한 Steve Riley의 기사와 Windows Vista의 ACL 변경 사항에 대한 Jesper Johansson의 기사가 이어집니다. 또한 Jeremy Moskowitz는 그룹 정책과 하드웨어 잠금에 대해 다루고 Michael Murgolo는 스크립트 권한 상승 PowerToys에 대해 기고합니다. 이번 호는 실로 지금까지 출간된 최고의 간행물이라 할 수 있습니다.
보안에 대한 경계를 늦추지 않는 것과 더불어 Microsoft에서 제공하는 최신 보안 서비스 및 제품에 대해서도 알아보아야 합니다. 클라이언트 운영 체제, 응용 프로그램 서버, 네트워크 경계 등 세 가지 분야에서 보호 기능을 제공하는 비즈니스 보안 제품인 Microsoft Forefront는 "견고성"의 대명사라 할 수 있습니다. 이 제품에는 Exchange Server 및 SharePoint용 보안 도구는 물론, 네트워크 트래픽용 ISA Server 및 Intelligent Application Gateway가 포함되어 있습니다. 그리고 Microsoft System Center는 &quot;인식&quot;을 대표하는 제품으로, 시스템에 대한 정보를 수집하고, 운영 및 관리를 합리화하고, 보고서를 생성하고, 서비스 제공 수준을 향상하는 등의 기능이 통합되어 있습니다. 또한 차세대 구성 관리 및 작업 모니터링 기술을 비롯한 다양한 도구도 포함되어 있습니다.
Forefront 및 System Center에 대한 자세한 내용은 Microsoft Infrastructure 사이트(Microsoft.com/infrastructure)를 참조하십시오. 그리고 보안 문제에 대한 최선의 해결 방안을 얻으려면 항상 TechNet Magazine을 잊지 마시기 바랍니다.
—Joshua Trupin

많은 Microsoft 기술 전문가들께서 도움을 주셨습니다. Conrad Bayer, David Cross, Michael Dennis, Shon Eizenhoefer, Jason Garms, Russ Humphries, Jesper Johansson, John Lambert, Eric Perlin, Mark Russinovich, Jon Schwartz, David Solomon, Greg Stemp, John Stephens, Kevin Sullivan, Jim Truher, 그리고 Buck Woody에게 감사의 말을 전합니다.


 Toolbox: IT 전문가를 위한 새로운 제품
Toolbox IT 전문가를 위한 새로운 제품 and Greg Steen
myLittleAdmin의 변경 가능한 인터페이스
웹 기반 UI는 새 데이터베이스 만들기, 기존 데이터베이스 및 데이터베이스 콘텐츠 관리, 스냅숏 및 스키마 사용 등 대부분의 데이터베이스 작업을 지원합니다. myLittleAdmin을 사용하면 기존 데이터베이스 개체의 속성을 쉽게 편집할 수 있습니다. myLittleAdmin에는 테이블의 개별 행을 수정하는 데 사용할 수 있는 편집 가능한 데이터 표도 포함되어 있습니다. 트리 뷰 인터페이스는 SQL Server Management Studio의 트리 뷰와 매우 유사하므로 응용 프로그램 사용법을 새로 배울 필요가 없습니다. 한 가지 다른 점이 있다면 마우스 오른쪽 단추를 클릭하는 경우 상황에 맞는 메뉴가 표시되지 않는다는 것입니다.
myLittleAdmin을 사용하여 SQL 인스턴스의 로그인, 서버 역할 및 자격 증명을 편집할 수도 있습니다. 특히 백업 장치 및 연결된 서버를 만들고 편집하는 작업을 원격 위치에서도 수행할 수 있어서 매우 편리합니다.
뿐만 아니라 myLittleAdmin으로 임시 쿼리 실행, 데이터베이스 연결 및 분리, 데이터베이스 백업 및 복원, CSV 데이터 가져오기, 데이터베이스 축소 등의 작업도 수행할 수 있으며, 문제 해결을 위해 오류 로그와 작업 모니터를 검색할 수도 있습니다.
가격: 단일 서버 라이선스(590달러~), 고객 지원용 웹 호스팅 도구 집합에 포함된 경우 단일 서버 라이선스(990달러~)


 SQL Q&amp;A: 64비트 설치, 클러스터 메모리 할당 외
SQL Q&A 64비트 설치, 클러스터 메모리 할당 외 and 편집자: Nancy Michell
그림 1Windows Live의 SQL Server 온라인 설명서 검색
하지만 SQL Server가 서버의 RAM을 모두 사용하는 상태에서 새 SQL Server 인스턴스가 시작된다면 원래 SQL Server 인스턴스의 메모리는 어떻게 되나요? 이 경우 한 노드만 가동되어 모든 SQL Server 인스턴스가 이 노드에서 실행되는 최악의 경우가 발생할 수 있으므로 이에 대한 계획을 세워야 할 것 같은데요.
A: 최대 서버 메모리 값은 시스템에서 사용할 수 있는 총 메모리보다 낮게 설정하는 것이 가장 좋다는 것이 일반적인 정설입니다. 하지만 해당 환경에서 총 메모리의 3분의 1이라는 값이 최적의 구성인지에 대해서는 좀 더 신중하게 검토해야 합니다.
클러스터에 있는 네 개의 서버 중 세 개의 서버가 동시에 다운되어 세 개의 SQL Server 인스턴스가 네 번째 노드에서 실행되는 상황이 우려된다고 하셨는데, 이와 같은 상황이 발생할 가능성은 매우 낮습니다.
대부분의 경우 각 노드의 사용 가능한 메모리를 모두 사용하도록 각 인스턴스를 구성하는 것이 좋습니다. 각 노드에 32GB의 RAM이 있다고 가정하면 각 인스턴스의 최대 서버 메모리를 28GB로 설정하는 것이 적절합니다.
그러면 노드에 오류가 발생할 경우 해당 노드에서 실행되는 인스턴스가 패시브 노드로 장애 조치되어 이 노드에서 사용 가능한 28GB의 메모리에 액세스할 수 있습니다. 다른 두 인스턴스는 영향을 받지 않은 채 클러스터의 다른 두 노드에서 계속해서 실행됩니다.
다섯 개의 SQL Server 인스턴스와 한 개의 분석 서비스 인스턴스가 있는 4노드 장애 조치 클러스터에 대해 말씀하셨는데, AWE(Address Windowing Extensions)와 함께 SQL Server 2000을 실행하는 경우 관계형 엔진이 확보한 메모리를 해제하려 하지 않으므로 관계형 엔진 인스턴스의 몇몇 메모리 최대값을 신중하게 선택하여 설정해야 합니다. AWE 사용 여부에 관계없이 대규모 주소 공간에 액세스할 수 있는 SQL Server 2005 및 64비트 인스턴스라는 보다 융통성 있는 환경에서는 이러한 상황이 달라집니다. AWE를 사용하더라도 메모리 사용이 동적이어서 필요한 경우 메모리를 해제할 수 있습니다. 따라서 컴퓨터에서 새 인스턴스가 새로 시작되는 경우 원래 SQL Server 인스턴스와 장애 조치 상황에서 확보한 메모리에 어떤 일이 발생하는지는 SQL Server 2000과 SQL Server 2005 중 어떤 버전을 실행하고 있는지와 AWE를 사용하는지 여부에 따라서 달라집니다.
최악의 경우에 대비하여 계획을 세우는 것은 물론 원칙적으로는 훌륭한 생각입니다. 하지만 실제 환경에서는 시스템을 오버 엔지니어링한 경우가 아니라면, 다섯 개의 SQL Server 관계형 엔진 인스턴스와 한 개의 분석 서비스 인스턴스를 실행하는 클러스터에서 네 개의 노드 중 세 개가 다운될 가능성은 거의 없습니다. 이 경우 나머지 한 개의 노드는 비슷한 성능 수준으로 원래 인스턴스를 실행할 수 있을 만큼 충분한 CPU 리소스를 사용할 수 없게 됩니다. 따라서 노드 한 개 정도는 작동되지 않더라도 최적의 성능이 유지되지만 두 개 이상의 노드가 작동되지 않는 경우에는 약간의 수동 작업이 필요하도록 솔루션을 엔지니어링하는 것이 좋습니다. 이렇게 하면 HA(고가용성)를 지원하는 동시에 값비싼 리소스를 적절히 활용할 수도 있습니다.
마지막으로 SQL Server 2005의 경우 최종 사용자가 최대 8개의 노드를 수용하도록 클러스터를 확장할 수 있습니다. SQL Server 2000에서는 4노드 클러스터까지만 지원됩니다.

미러링 제한
Q: SQL Server 2005 데이터베이스 미러링에 관한 글을 읽다가 데이터베이스 미러링은 서버 인스턴스당 데이터베이스를 최대 10개까지만 지원할 수 있는 제한이 있음을 알게 되었습니다. 제 환경에서는 별도의 저장소가 있는 두 개의 SQL Server 인스턴스가 있어야 하고, 두 인스턴스 간에 자동 장애 조치가 수행되어야 하며, 데이터 중복 기능이 제공되어야 합니다.
P2P(피어 투 피어) SQL Server 2005 트랜잭션 복제와 Microsoft® Cluster Server(MSCS)를 결합함으로써 두 노드 중 한 노드만 대상으로 하는 클러스터 IP를 사용하여 모든 삽입, 업데이트, 삭제 및 읽기 트래픽이 클러스터의 단일 노드로만 향하도록 하려고 합니다. 두 번째 노드는 패시브 노드로 만들고 이 노드에 트랜잭션이 복제되도록 하려고 합니다. 오류가 발생할 경우에는 MSCS가 해당 IP를 다른 노드로 장애 조치하고 클러스터가 P2P 및 양방향으로 구성되어 있으므로 다른 노드(백업된 경우)에 트랜잭션 게시를 시작하기 위해 수동 프로세스를 수행할 필요가 없습니다. 또한 MSCS 내에 MNS(주 노드 집합) 구성을 사용하면 쿼럼용 공유 디스크 리소스를 둘 필요가 없게 됩니다.
테이블에는 여전히 미러링 옵션이 설정되어 있습니다. SQL Server 클러스터당 1,000개에서 100개로 데이터베이스를 줄였는데도 시스템에 이런 유형의 부하를 계속 놔두어야 합니까?
A: SQL Server 미러링과 관련된 자세한 내용이나 안내서를 보려면 온라인 설명서, SQL Server Tech Center(microsoft.com/technet/prodtechnol/sql) 및 msdn2.microsoft.com/sql을 참조하십시오.
이 질문에 대답하려면 많은 설명이 필요합니다. 여기서는 질문자의 시나리오와 관련하여 가장 적절한 대답만 제시하겠습니다.
첫 번째는 해당 인스턴스에서 미러링할 수 있는 데이터베이스의 수에는 정해진 제한이 없다는 것입니다. 인스턴스당 최대 10개의 데이터베이스만 미러링하는 것이 좋다는 내용의 문서를 참조하신 것 같은데, 이 수치는 대략적인 것일 뿐이며 특별히 정해진 제한은 없습니다. 미러링할 수 있는 데이터베이스의 수는 전적으로 해당 시스템에서 사용할 수 있는 리소스에 달려 있습니다.
미러링이 옵션이 될 수 있지만, 성능이 매우 우수한 서버를 사용하는 경우가 아니라면 일반 서버에서 가능한 데이터베이스의 수는 최대 1,000개 정도입니다. 공유 저장소를 사용하지 않고 기본 제공되는 SQL Server 기술을 사용하려는 경우에는 미러링, 로그 전달 또는 복제 기능을 사용할 수 있습니다. 각 기능마다 나름대로의 장단점이 있습니다.
두 번째로, 공유 저장소 대신 다수의 데이터베이스가 있고 Microsoft에서 제공하는 장애 복구 솔루션을 사용하려는 경우 일련의 간단한 사용자 지정 도우미 프로그램을 사용하여 관리 오버헤드를 줄일 수 있는 로그 전달 기능을 검토해 보십시오. 한 프로그램으로 각 데이터베이스를 순서대로 백업 및 복원할 수 있으므로 여러 개의 로그 전달 에이전트를 실행하지 않아도 됩니다. 하지만 데이터가 손실될 가능성도 있다는 점을 염두에 두십시오. 기본 제공되는 솔루션은 모두 데이터 손실을 방지하기 위해 공유 저장소나 DBMS 중 하나를 필요로 합니다.
물론 MSCS로 어떻게 오류를 검색하고 장애 조치를 수행하느냐의 문제도 있습니다. 클러스터에 MNS를 구성하더라도 쿼럼용 전용 공유 LUN을 둘 필요성만 없어질 뿐이지 공유 저장소의 필요성이 완전히 사라지는 것은 아닙니다. IP와 네트워크 이름만 관리하도록 클러스터를 구성한다면 해당 계획을 실현하는 것이 가능합니다. 하지만 SQL Server는 공유 저장소 없이는 클러스터링할 수 없으므로, 이 경우 SQL 서비스를 클러스터링할 수 없게 됩니다. 즉, 일반적인 구성에서는 클러스터가 SQL Server 서비스를 검색하고 모니터링할 수 없습니다.
SQL Server 서비스를 일반 서비스로 추가하여 클러스터링하면 모니터링할 수 있지만, 이 경우 장애 조치에서 문제가 발생합니다. 다시 말해 서비스가 클러스터링되어 있으면 MSCS가 장애 조치 시 패시브 노드에서 서비스를 온라인 상태로 전환하려고 하지만 일부 SQL 서비스는 이미 실행되고 있는 문제가 발생합니다. 물론 IP와 네트워크 이름만 클러스터링한 다음 필요한 경우 수동으로 장애 조치를 수행할 수는 있습니다. NLB(네트워크 부하 분산)를 통해 같은 목적을 달성할 수도 있는데, 이 방법은 어딘가에서 실행되고 있기도 합니다. 자세한 내용은 microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog04.mspx 문서를 참조하십시오.
지원하려고 하는 데이터베이스의 수를 고려하면 로그 전달 솔루션이 더 적합합니다. 물론 DTS/SSIS(Data Transformation Services/SQL Server Integration Services) 패키지를 사용하여 프로세스를 자동화해야 합니다. 그렇지 않으면 오류가 발생할 경우 활성 로그를 수동으로 백업, 이동 및 적용하는 데 많은 시간이 걸릴 수 있습니다.

기술적 자문을 주신 Microsoft IT 전문가: Boris Baryshnikov, Chad Boyd, Alan Doby, Patrick Gallucci; Cindy Gross, Chuck Ladd, Pat Martin, Vipul Shah, Nelson Taggart, Kartik Tamhane, Ken Tanner, Chuck Timon, George Walters, Kevin Warren, 그리고 Buck Woody에게 감사를 전합니다.


 Utility Spotlight: Windows Vista를 위한 스크립트 권한 상승 PowerToys
Utility Spotlight Windows Vista를 위한 스크립트 권한 상승 PowerToys and Michael Murgolo
이 기사의 코드 다운로드: Utility2007_06.exe (159KB)
사용자 계정 컨트롤은 보안을 크게 강화하지만 특정 관리 작업과 기능을 수행하려면 권한 상승 기능이 필수적입니다. 여기서는 권한 상승을 더 유연하고 강력하게 수행할 수 있도록 하는 몇 가지 권한 상승 PowerToys를 소개합니다.
Windows Vista에서는 보안 문제의 해결을 위해 많은 기능이 도입되었지만 UAC(사용자 계정 컨트롤)는 그 중 중요한 기능이라고 할 수 있습니다. 사용자 계정 컨트롤을 사용하면 관리자 권한을 가진 사용자가 대부분의 응용 프로그램을 표준 권한으로 실행하고 특정 관리 작업과 응용 프로그램 기능은
상승된 권한으로 실행할 수 있습니다. Windows Vista™를 여러 달 사용하다 보면 필요에 따라 작업이나 응용 프로그램의 권한을 상승해야 하는 경우가 많습니다. 하지만 필자는 Windows Vista에서 몇몇 유형의 작업에서 권한을 상승하려고 할 때 몇 가지 어려움을 발견하고 불편함을 느끼게 되었습니다.
그래서 필자는 Windows® PowerToys의 정신에 따라 이러한 한계를 극복할 수 있는 스크립트 권한 상승 PowerToys 몇 가지를 직접 개발했습니다. 여기서 소개하는 모든 PowerToys는 technetmagazine .com/code07.aspx의 코드 다운로드 섹션에서 다운로드할 수 있습니다. 또한 UAC의 작동 방식에 대한 자세한 설명은 2006년 11월호에 Alex Heaton가 기고한 기사인 "사용자 계정 컨트롤을 사용하여 관리자가 아닌 사용자로 실행"에서 볼 수 있습니다("추가 리소스" 참조).

권한 상승 명령 PowerToy
첫 번째 불편한 점은 명령줄이나 실행 대화 상자에서 응용 프로그램의 권한을 상승할 방법이 없다는 점이었습니다. 따라서 필자는 Microsoft 내 여기저기에서 문의한 끝에 결국 John Stephens(Microsoft의 소프트웨어 설계 엔지니어)의 샘플 스크립트에서 필요한 정보를 얻을 수 있었습니다. "runas"라는 명령을 ShellExecute API 또는 COM에서 이에 해당하는 메서드인 Shell.Application의 ShellExecute 메서드에 전달하면 응용 프로그램 실행 시 권한 상승을 확인하는 메시지가 표시되는 것을 알게 되었습니다(자세한 내용은 추가 기사 참조). 이를 통해 첫 번째 권한 상승 PowerToy인 권한 상승 명령 PowerToy를 만들 수 있었습니다.
ElevateCommand.inf, elevate.cmd 및 elevate.vbs 파일로 구성된 이 도구는 시스템에 권한 상승 명령을 추가하므로 이를 통해 명령줄, 스크립트 또는 실행 대화 상자에서 권한 상승을 확인하는 응용 프로그램을 시작할 수 있습니다. 예를 들어 다음 명령은 메모장에서 Win.ini를 엽니다(권한 상승 확인 메시지 표시 후).
elevate notepad c:\Windows\Win.ini
Windows Script Host(WSH), Windows PowerShell™ 또는 다른 스크립트에서 권한 상승 명령을 사용할 때는 스크립트 호스트 실행 파일(예: wscript, cscript 또는 powershell)을 응용 프로그램으로 지정해야 합니다. 예를 들어 vbs를 실행하려면 다음과 같이 지정합니다.
elevate wscript “C:\windows\system32\
slmgr.vbs” –dli
그림 2상승된 권한으로 프롬프트 표시

설치 및 구현
이 PowerToys를 설치하려면 INF 파일을 마우스 오른쪽 단추로 클릭하고 설치를 선택한 다음 권한 상승을 승인합니다. 제거할 때는 제어판의 프로그램 및 기능을 사용합니다.
INF 파일을 분석하다 보면 이 PowerToys가 왜 elevate.cmd와 elevate.vbs를 서로 다른 위치에 설치하는지 궁금할 것입니다. 이에 대해 설명하겠습니다. 대부분의 PowerToys는 레지스트리에서 HKEY_CLASSES_ROOT\objecttype\Shell 키에 개체 유형에 대해 runas 하위 키를 추가하는 방법으로 구현됩니다.
하지만 일부 PowerToys의 경우에는 권한 상승을 위한 상황에 맞는 메뉴 항목이 두 개 있는 것이 좋은 개체 유형이 있습니다. 예를 들어 드라이브 및 디렉터리 개체 유형의 경우에는 "CMD Prompt Here as Administrator(관리자로 CMD 프롬프트 표시)"와 "PowerShell Prompt Here as Administrator(관리자로 PowerShell 프롬프트 표시)", 모든 WSH 개체 유형의 경우에는 "관리자로 실행"과 "Run as Administrator with Command Prompt(명령 프롬프트를 사용하여 관리자로 실행)"이 있는 것이 좋습니다. 하나의 개체 유형에는 하나의 runas 키만 있을 수 있으므로 elevate 명령을 호출하여 두 번째 작업을 구현해야 했습니다. 하지만 각 INF를 개별적으로 설치 및 제거할 수 있도록 하기 위해 필자는 연관된 elevate.cmd 및 elevate.vbs를 서로 다른 위치에 두어야 했습니다. 원시 INF 파일에서 파일 사용 카운터를 증가시킬 수 없습니다. 물론 MSI 설치 관리자가 더 좋을 수 있지만 필자는 텍스트 편집기로 만들고 수정할 수 있는 설치 관리자를 원했습니다. 이 방법의 한 가지 단점은 runas 키를 사용하여 구현된 상황에 맞는 메뉴 항목만 메뉴에서 방패 모양이 표시된다는 점입니다.

요약
이 도구가 유용하게 사용되고 이를 통해 UAC를 좀 더 편리하게 사용할 수 있기를 바랍니다. 이 도구를 사용하다 보면 PowerToys를 직접 만들어 보고 싶은 마음이 생길 것입니다. Windows Vista에서 Perl이나 Python 같은 스크립팅 언어를 사용하는 사용자는 해당 언어를 위한 "권한 상승 스크립트" PowerToy를 쉽게 만들 수 있을 것입니다. 모든 PowerToys와 마찬가지로 이 도구를 사용하는 데 따른 "모든 위험은 사용자 책임"이며 별도의 지원이 제공되지 않습니다. 많은 도움이 되기를 바랍니다.
추가 리소스
  • 사용자 계정 컨트롤을 사용하여 관리자가 아닌 사용자로 실행
  • 사용자 계정 컨트롤 개요
  • ShellExecute를 통한 권한 상승
  • ShellExecute 메서드
  • 동사와 파일 연결
  • 새로 수정된 기존의 PowerToy


 The Cable Guy: 보안 소켓 터널링 프로토콜
The Cable Guy 보안 소켓 터널링 프로토콜 and Joseph Davies
이 칼럼은 Windows Server 코드 이름 "Longhorn"의 시험판 버전의 일부를 기준으로 작성되었습니다. 이 칼럼에 수록된 모든 정보는 변경될 수 있습니다.
일부 구성에서는 Windows XP 및 Windows Server 2003의 VPN 프로토콜이 작동하지 않습니다. 이와 관련한 여러 가지 문제를 심도 있게 살펴보고 Windows Server "Longhorn" 및 Windows Vista 서비스 팩 1에서 보안 소켓 터널링 프로토콜을 사용하여 이러한 문제를 해결하는 방법을 알아봅니다.
Windows XP와 Windows Server 2003에서는 컴퓨터가 로컬 이더넷 포트에 연결되어 있는 것처럼 인터넷을 통해 개인 인트라넷에 연결할 수 있는 VPN(가상 사설망)을 지원합니다. 그러나 일부 방화벽 구성에서는 Windows XP 및 Windows Server 2003의 VPN 프로토콜이 작동하지 않습니다.
또한 컴퓨터가 NAT(Network Address Translator)나 웹 프록시 서버를 통해 연결된 경우와 같이 VPN 연결의 트래픽이 차단된 몇 가지 간접 구성에서도 VPN 프로토콜이 작동하지 않습니다. 이러한 문제를 해결하기 위해 Windows Server®의 다음 버전인 코드 이름 "Longhorn"과 Windows Vista™ 서비스 팩 1(두 가지 모두 베타 테스트 중)에서는 새로운 SSTP(보안 소켓 터널링 프로토콜)를 지원합니다.

VPN 액세스 문제
Windows® XP 및 Windows Server 2003에서 지원하는 VPN 프로토콜은 PPTP(지점간 터널링 프로토콜)와 L2TP/IPsec(Layer Two Tunneling Protocol with Internet Protocol security)으로 이를 통해 인터넷을 통한 인트라넷 원격 액세스 연결을 설정할 수 있습니다. 이 두 프로토콜은 원격 액세스 클라이언트와 해당 클라이언트가 연결된 인트라넷 간에 전송된 패킷을 캡슐화하는 기능을 제공합니다.
PPTP 기반 VPN 트래픽은 터널 유지 관리를 수행하는 VPN 서버의 TCP 포트 1723에 대한 TCP 연결과 VPN 데이터의 GRE(Generic Routing Encapsulation) 방식으로 캡슐화된 패킷으로 구성됩니다. 그러나 PPTP 트래픽은 방화벽, NAT 및 웹 프록시에서 문제를 일으킬 수 있습니다. 따라서 이러한 문제를 방지하려면 TCP 연결과 GRE 방식으로 캡슐화된 데이터를 모두 허용하도록 방화벽을 구성해야 합니다. GRE는 표준 IP 패킷 캡슐화 방식이지만 많은 ISP(인터넷 서비스 공급자)에서 이 패킷을 버리기 때문에 데이터 손실이 발생합니다. 뿐만 아니라 호텔이나 커피숍에 설치된 인터넷 연결의 경우 대개 일반 웹 및 전자 메일 트래픽용으로 구성되어 있으므로 PPTP 트래픽이 허용되지 않을 수 있습니다. 또한 컴퓨터가 NAT를 통해 연결되어 있으면 NAT에서 GRE 트래픽을 변환할 수 있어야 합니다. GRE 트래픽을 변환할 수 없는 경우 TCP 연결은 설정할 수 있지만 GRE 방식으로 캡슐화된 데이터는 주고 받을 수 없습니다. 마지막으로 PPTP 트래픽은 웹 프록시를 통해 전송될 수 없습니다.
Windows XP 및 Windows Server 2003에서 사용되는 또 다른 VPN 프로토콜인 L2TP/IPsec은 IKE(인터넷 키 교환)를 사용하여 VPN 트래픽의 IPsec ESP(Encapsulating Security Payload) 보호 수준을 협상하며, 이 프로토콜 역시 방화벽, NAT 및 웹 프록시에서 문제를 일으킵니다.
이 설정의 경우 IKE 트래픽과 ESP 방식으로 캡슐화된 데이터를 모두 허용하도록 방화벽을 구성해야 합니다. VPN 클라이언트 컴퓨터가 NAT를 통해 연결되어 있으면 VPN 클라이언트와 VPN 서버가 모두 IPsec NAT-T(NAT 통과)를 지원해야 합니다. 그러나 VPN 서버는 NAT를 통해 연결될 수 없으며 L2TP/IPsec 트래픽은 웹 프록시를 통해 전송될 수 없습니다.

새로운 VPN 솔루션
이미 설명했듯이 Windows XP와 Windows Server 2003의 VPN 프로토콜 작업에는 여러 가지 문제가 있습니다. 다행스러운 것은 Windows Vista 서비스 팩 1 및 Windows Server "Longhorn"에서 지원하는 SSTP가 HTTP over SSL(Secure Sockets Layer)을 사용하여 이러한 VPN 연결 문제를 해결한다는 점입니다. SSL은 TLS(전송 계층 보안)라고도 합니다. TCP 포트 443의 HTTP over SSL은 오래 전부터 웹에서 신용카드 번호나 기타 개인 데이터를 수집하는 데 사용되어 온 프로토콜입니다. 즉, https:로 시작하는 웹 주소에 연결할 때마다 HTTP over SSL을 사용하고 있는 것입니다.
HTTP over SSL을 사용하면 여러 가지 VPN 프로토콜 연결 문제를 해결할 수 있습니다. 이 트래픽 형식은 워낙 널리 사용되므로 방화벽, NAT 및 웹 프록시에서도 일반적으로 허용됩니다.
SSTP는 VPN 클라이언트와 서버 간에 HTTP-over-SSL 세션을 사용하여 캡슐화된 IPv4 또는 IPv6 패킷을 주고 받습니다. HTTP-over-SSL 기반 원격 액세스 VPN 연결은 HTTP over SSL을 사용하는 응용 프로그램에서 설정하는 연결과는 다릅니다. 예를 들어 Outlook® Web Access(OWA)에서는 인터넷을 통해 회사의 Microsoft Exchange 전자 메일에 액세스할 수 있습니다. OWA에서는 HTTP over SSL 암호화 세션을 사용하지만 이 연결은 원격 액세스 연결과는 다릅니다. 따라서 OWA로 전자 메일을 볼 수는 있지만 Exchange 전자 메일 메시지에 포함된 인트라넷 URL 위치에 액세스할 수는 없습니다.
(SSTP는 HTTP Connect 요청이 있는 동안 프록시에서 일부 인증 양식을 필요로 하는 인증된 웹 프록시 구성을 지원하지 않습니다.)
Windows의 HTTP-over-SSL 구현을 활용하면 원격 액세스 솔루션 유지 관리 비용을 크게 줄일 수 있습니다. 예를 들어 HTTP over SSL을 구현할 경우 헬프 데스크 지원 요청을 줄이고 NAT를 통해 연결된 VPN 서버와 관련한 문제를 해결할 수 있습니다. 뿐만 아니라 SSTP는 모든 구성에 문제없이 사용할 수 있으므로 사용자의 만족도와 생산성도 높일 수 있습니다.
SSTP는 Windows에 기본적으로 포함되어 있으므로 클라이언트 컴퓨터에서 설치 및 관리하기 위해 타사 VPN 클라이언트 소프트웨어에 연결하거나 VPN 서버에 설치하기 위해 추가 소프트웨어에 연결할 필요가 없습니다. 또한 SSTP는 사용 가능한 SSL 부하 분산 기능을 통해 VPN 연결 부하를 효과적으로 분산할 수 있습니다.
새로운 SSTP 기능
  • SSTP에는 시스템 상태 요구 사항을 준수하도록 함으로써 네트워크 자산을 보다 효과적으로 보호하는 데 사용할 수 있는 NAP(네트워크 액세스 보호)에 대한 통합 지원이 추가되었습니다. NAP에 대한 자세한 내용은 microsoft.com/nap를 참조하십시오.
  • 또한 SSTP에서는 IPv6 인터넷을 통한 IPv6 기반 SSTP 연결 및 SSTP 터널 내에서 전송되는 네이티브 IPv6 트래픽도 지원합니다.
  • 뿐만 아니라 SSTP 클라이언트에서 SSTP 서버로 연결된 단일 HTTP over SSL 세션을 설정합니다. 다른 타사 SSL 기반 VPN 솔루션은 두 개의 HTTP over SSL 세션을 사용합니다. 단일 HTTP over SSL 세션을 사용하면 네트워크 사용량을 줄이고 부하를 효과적으로 분산할 수 있습니다.
  • 마지막으로 SSTP는 Windows Vista 서비스 팩 1 및 Windows Server &quot;Longhorn&quot;의 VPN 클라이언트 구성 요소, Windows Server &quot;Longhorn&quot;의 라우팅 및 원격 액세스에 완벽하게 통합됩니다. SSTP는 VPN 프로토콜의 하나로, Network Connections 폴더 및 연결 관리자와 같이 PPTP 또는 L2TP/IPsec 기반 연결에 사용되는 모든 인증 프로토콜과 구성 방법을 사용할 수 있습니다.
Windows XP와 Windows Server 2003의 PPTP 및 L2TP/IPsec 프로토콜과는 달리 SSTP는 사이트 간 VPN 연결을 지원하지 않습니다.

Windows의 SSTP
Windows Server "Longhorn" 및 라우팅 및 원격 액세스를 실행하는 컴퓨터는 SSTP 기반 VPN 서버입니다. 이 경우 라우팅 및 원격 액세스에서 특정 URI(Uniform Resource Identifier) /sra_{BA195980-CD49-458b-9E23- C84EE0ADCD75}/를 통해 들어오는 연결을 수신하므로 IIS를 설치할 필요가 없습니다. 하지만 원하는 경우 라우팅 및 원격 액세스와 IIS를 같은 서버에 함께 설치할 수 있습니다.
Windows Vista 서비스 팩 1(향상된 기능이 추가되어 올해 말에 릴리스될 예정) 또는 Windows Server "Longhorn"을 실행하는 컴퓨터는 SSTP 기반 VPN 서버로의 SSTP 연결을 시작할 수 있는 SSTP 기반 VPN 클라이언트입니다. SSTP 서버에는 서버 인증 또는 범용 EKU(향상된 키 용도) 속성을 사용하는 컴퓨터 인증서가 설치되어 있어야 합니다. 이 컴퓨터 인증서는 SSL 세션 설정 시 SSTP 클라이언트에서 SSTP 서버를 인증하는 데 사용됩니다. 이때 SSTP 클라이언트는 SSTP 서버의 컴퓨터 인증서를 확인합니다. 컴퓨터 인증서를 신뢰하려면 SSTP 서버의 컴퓨터 인증서를 발급한 CA(인증 기관)의 루트 CA가 SSTP 클라이언트에 설치되어 있어야 합니다.
그림 1에는 Windows Server "Longhorn" 및 Windows Vista 서비스 팩 1의 여러 가지 VPN 프로토콜 특성이 비교되어 있습니다. SSTP 기능에 대한 자세한 내용은 "새로운 SSTP 기능" 추가 기사를 참조하십시오.
Figure 1 여러 VPN 프로토콜 비교 (Close Figure 1)
그림 2SSTP 패킷 구조
IPv4 또는 IPv6 패킷은 먼저 PPP 헤더와 SSTP 헤더로 캡슐화됩니다. 그런 다음 IPv4 또는 IPv6 패킷, PPP 헤더 및 SSTP 헤더의 조합이 SSL 세션을 통해 암호화됩니다. 여기에 TCP 헤더와 IPv4 헤더(IPv4 인터넷을 통한 SSTP 연결의 경우) 또는 IPv6 헤더(IPv6 인터넷을 통한 SSTP 연결의 경우)가 추가되어 패킷이 완성됩니다.
SSTP에 대한 자세한 내용은 라우팅 및 원격 액세스 블로그(blogs.technet.com/rrasblog)를 참조하십시오.


 Windows Powershell: Active Directory 사용
Windows Powershell Active Directory 사용 and Don Jones Windows PowerShell은 Get-ADSIObject cmdlet을 제공하지는 않지만 다른 방법으로 여전히 강력한 ADSI 지원을 제공합니다. 이 기사에서는 형식 어댑터를 소개하고 Windows PowerShell을 사용하여 디렉터리 개체를 다루는 방법을 설명합니다.
Windows PowerShell로 작업한 적이 있다면 십중팔구는 Get-WMIObject cmdlet(또는 편리한 별칭인 gwmi)을 사용해 보았을 것입니다. 지난 달 칼럼에서 설명한 것처럼 이 cmdlet은 이전 스크립팅 언어 및 명령줄 셸과 비교했을 때 Windows PowerShell의 주요 개선점을 보여 줍니다(technetmagazine.com/issues/2007/05/PowerShell 참조).
gwmi를 사용하면 WMI(Windows® Management Instrumentation)에 쉽고 빠르게 액세스할 수 있으므로 복잡한 스크립트를 작성할 필요 없이 무수히 많은 작업을 수행할 수 있습니다.
Get-WMIObject는 Windows PowerShell™로 수행할 수 있는 작업을 보여 주는 좋은 예입니다. 필자가 수업에서 이를 소개할 때마다 학생들은 그 기능을 통해 Windows 관리의 다른 영역까지 추정합니다. 대개 학생들은 가장 먼저 "Get-ADSIObject cmdlet도 있나요?"라고 묻습니다.

Windows PowerShell의 ADSI 지원
ADSI는 Active Directory® Services Interface의 약어입니다. 하지만 이름과 달리 ADSI의 사용은 실제로 Active Directory에 국한되지 않습니다. ADSI는 Windows NT 도메인을 비롯한 Windows NT® 유형의 디렉터리와 같은 다양한 디렉터리 서비스뿐 아니라 독립 실행형 및 구성원 컴퓨터의 로컬 SAM(Security Accounts Manager)에도 연결할 수 있기 때문에 이 이름은 "액티브(쉬고) 디렉터리 서비스 인터페이스"로 읽는 편이 더 정확합니다. 이 같은 유연성이 있는 Get-ADSIObject cmdlet은 매우 유용합니다. 그러나 안타깝게도 Windows PowerShell의 최초 버전에는 이 cmdlet이 포함되어 있지 않습니다.
그렇다고 Windows PowerShell에 ADSI 지원이 없다는 의미는 아닙니다. 사실 Windows PowerShell의 ADSI 지원은 매우 뛰어나기 때문에 Get-ADSIObject cmdlet이 없다는 것을 개의치 않아도 될 정도입니다.
ADSI 지원에 대해 설명하려면 먼저 [ADSI] 형식 어댑터를 살펴보아야 합니다. 형식 어댑터에는 약간의 설명이 필요합니다. Windows PowerShell은 Microsoft® .NET Framework 2.0 이상에서 기본 제공된다는 점을 상기하십시오. 따라서 WMI 개체부터 파일 및 폴더에 이르기까지 Windows PowerShell의 거의 모든 것이 Framework의 개체로 표현됩니다. 하지만 Windows PowerShell 팀에서는 원시 Framework 개체를 Windows 관리자에게 노출하는 것만으로는 만족하지 못했습니다. 예를 들어 많은 Framework 개체가 다소 일관되지 않게 작동하므로 일관성이 Windows PowerShell의 주요 설계 목표였습니다. 또 다른 이유는 일부 Framework 개체가 Windows 관리에서 보면 필요 이상의 개체이기 때문에 단순함도 Windows PowerShell의 주요 설계 고려 사항 중 하나였습니다. 이런 이유로 형식 어댑터가 탄생했습니다.
형식 어댑터는 그 이름에서 알 수 있듯이, .NET Framework 개체 형식을 더 일관되고 경우에 따라서는 더 단순한 형식으로 변환합니다. 예를 들어 다음과 같은 새 문자열 변수를 만든다고 가정해 보겠습니다.
[string]$var = “Hello”
여기서는 .NET 어댑터에 의해 처리되는 System.String 형식의 인스턴스를 사용했습니다. [ADSI] 형식 어댑터는 DirectoryEntry 형식을 포함한 .NET Framework DirectoryServices 클래스에 연결됩니다.

디렉터리에서 개체 검색
디렉터리 개체로의 연결은 꽤 쉽습니다. 예를 들어 Contoso.com 도메인의 IT OU(조직 구성 단위)에서 Don이라는 사용자에 연결하려면 다음과 같은 구문을 사용합니다.
$user = [ADSI]”LDAP://cn=Don,ou=IT,dc=
Contoso,dc=com”
VBScript나 다른 언어에서 ADSI를 다룬 적이 있다면 꽤 익숙할 것입니다. 이것은 Active Directory에 액세스하기 위한 기본적인 방법인 표준 LDAP(Lightweight Directory Access Protocol) 쿼리 문자열입니다. DC(도메인 컨트롤러) 이름이나 다른 세부 정보를 지정할 필요가 없습니다. 이 FQDN(정규화된 도메인 이름)에는 DC를 찾아서 개체를 검색(물론 그럴 권한이 있는 경우)하기에 충분한 정보가 들어 있기 때문입니다.
로컬 보안 계정을 다루는 작업에서는 LDAP 공급자 대신 WinNT 공급자를 사용한다는 점을 제외하면 거의 동일한 프로세스가 사용됩니다.
$user = [ADSI]”WinNT://don-pc/don”
그림 1개체 속성의 목록 검색
개체 검색은 기본적으로 쿼리 문자열을 구성하는 방법의 문제입니다. WinNT 공급자를 사용하면 꽤 쉽습니다. 컴퓨터나 도메인 이름과 슬래시, 그리고 개체 이름을 차례로 지정하기만 하면 됩니다. 이 방법은 Active Directory 도메인에서 문제 없이 작동합니다. 즉, Windows NT 도메인과 하위 호환됩니다. 또한 WinNT 공급자는 도메인에 대한 기본 뷰를 제공하기 때문에 경우에 따라서는 WinNT 공급자를 사용하는 것이 Active Directory에서 개체를 검색하는 가장 쉬운 방법입니다. WinNT 공급자는 OU를 인식하지 않기 때문에 개체가 위치한 OU를 알 필요가 없습니다.
LDAP 개체의 검색은 조금 더 복잡합니다. 우선 개체의 정식 이름(cn) 또는 OU의 이름 등과 같은 가능한 가장 구체적인 정보로 시작해야 합니다. 그런 다음 상위 컨테이너에서 도메인 자체에 이르는 개체의 전체 경로를 제공합니다. Contoso.com 도메인의 West OU에 있는 Sales라는 OU에 위치한 사용자 Don을 예로 들면 다음과 같습니다.
LDAP://cn=Don,ou=Sales,ou=West,dc=Contoso,
dc=com
이 형식에는 약간의 연습이 필요하며 개체의 위치를 알고 있어야 합니다. 그림 2에서는 FQDN의 여러 구성 요소를 요약합니다.
Figure 2 FQDN 구성 요소 (Close Figure 2)

구성 요소 | 용도 | 예
cn | 개체의 정식 이름입니다. 사용자 및 컴퓨터와 같은 OU가 아닌 컨테이너에도 사용됩니다. | cn=Don
ou | 조직 구성 단위입니다. | ou=Sales
dc | 도메인 이름 구성 요소입니다. DNS 도메인 이름의 각 구성 요소마다 고유한 “dc=” 구성 요소가 사용됩니다. | dc=domain, dc=com

친구의 작은 도움
개체를 만들고 삭제하려면 일반적으로 먼저 OU와 같은 개체 컨테이너에 연결한 다음 컨테이너에 개체의 생성이나 삭제를 요청해야 합니다. 필자의 경우 올바른 구문을 잊는 경우가 많은데 다행히 Microsoft Scripting Guys가 제공하는 ADSI Scriptomatic에서 도움을 받을 수 있습니다.
ADSI Scriptomatic은 원래 VBScript용으로 개발되었지만 실제 ADSI 구문은 동일하므로 Windows PowerShell에서도 유용합니다. 예를 들어 필자는 도구를 다운로드한 후 새 사용자를 만드는 옵션을 선택합니다. 그리고 "End connect to a container" 코드까지 도구가 생성하는 모든 스크립트 코드를 무시하면 다음과 같은 코드가 남습니다.
Set objUser =
 objContainer.Create(“user”, “cn=” & strName)
objUser.Put “sAMAccountName”, strName
objUser.SetInfo
Windows PowerShell로 변환하는 것은 쉽습니다. 먼저 사용자를 생성할 컨테이너에 연결합니다. Scriptomatic 코드와의 일관성을 유지하기 위해 변수 $objContainer를 사용하여 OU를 나타냅니다. 또한 새 사용자의 이름을 저장할 변수 $strName도 만듭니다.
$strName = “Don”
$objContainer = “LDAP//ou=Test,dc=Contoso,
dc=com”
그런 다음 Scriptomatic 코드를 복사하고 VBScript Set 문의 모든 흔적을 제거하고 변수 이름에 $를 추가합니다.
$objUser = $objContainer.Create(“user”,
  “cn=” & $strName)
$objUser.Put “sAMAccountName”, $strName
$objUser.SetInfo()
이렇게 하면 Contoso .com 도메인의 Test OU에 새 사용자가 만들어집니다.

디렉터리 개체 수정
사용자나 그룹과 같은 개체에 연결되면 이를 수정할 수 있습니다. WinNT 공급자를 사용하면 그림 1에 나오는 것 같은 많은 속성을 직접 수정할 수 있습니다. 예를 들어 사용자의 Description 속성을 표시하고 변경하려면 다음과 같이 합니다.
Write-Host $user.Description
$user.Description = “New Description”
$user.SetInfo()
여기서 기억해야 할 중요한 사항은 속성 변경은 로컬 속성 캐시에서 수행되며 이 캐시는 ADSI가 컴퓨터에서 유지하는 임시 저장 영역이라는 점입니다. SetInfo 메서드를 호출하면 개체를 검색했던 도메인이나 컴퓨터로 캐시가 기록되어 변경 내용이 디렉터리에 저장됩니다.
Active Directory 개체는 대부분의 개체 특성에 대한 직접 속성을 제공하지 않으므로, 대신 Get 및 Put 메서드를 사용해야 합니다.
Write-Host $user.Get(“Description”)
$user.Put(“Description”,”New Description”)
$user.SetInfo()
Windows NT 디렉터리 서비스는 사용자나 그룹과 같은 개체에 대한 정보는 많이 저장하지 않기 때문에 WinNT 개체는 대체로 매우 단순합니다. 반면 Active Directory는 많은 정보를 저장하므로 올바른 특성 이름을 알아내는 것이 어려울 수 있습니다. 예를 들어 사용자의 성을 변경하려면 Sn 속성을 변경해야 합니다. 속성 이름이 Sn인 이유는 surname(성)을 나타내기 때문입니다.
다행히 Microsoft에서는 유용한 상호 참조를 제공하는데, 이 참조는 msdn2.microsoft.com/ms677286.aspx에서 구할 수 있습니다. 이 참조는 Active Directory 사용자 및 컴퓨터 콘솔의 각 주요 영역에 대한 특성 이름을 보여 주므로 콘솔에서 변경하고자 하는 것을 알고 있으면 기본 특성 이름을 알 수 있습니다. 전체 콘솔/특성 상호 참조는 Cade Fassett가 집필한 ADSI Scripting: TFM(SAPIEN Press, 2007)에서 볼 수 있습니다.

할 수 없는 작업
불행히도 Windows PowerShell의 ADSI 지원은 WMI 등의 다른 기술에 대한 지원만큼 강력하지 않습니다. 예를 들어 로컬 컴퓨터 그룹의 구성원을 열거하기가 다소 어렵습니다. Active Directory를 다룰 때도 많은 까다로운 상황이 발생합니다. 필자의 경험으로는 기본적인 개체 검색, 생성 및 삭제는 잘 작동합니다. 일부 속성에는 액세스할 수 없지만 개체 속성 수정도 꽤 잘 작동합니다. 가장 까다로운 작업은 WinNT 공급자를 통해 로컬 개체와 그룹을 다루는 작업입니다.
그렇다고 작업을 전혀 할 수 없다는 의미는 아닙니다. 어떤 작업은 단순히 조금 어려운 수준이거나 덜 직관적일 뿐입니다. 다음 예제를 통해 설명하겠습니다.
$group = [ADSI]”LDAP://cn=Techs,cn=users,
  dc=contoso,dc=com”
$group.Member.Add(“cn=user1,cn=users,
  dc=contoso , dc=com”)
$group.psbase.CommitChanges()
이 예제는 Techs라는 그룹에 User1이라는 이름의 사용자를 추가합니다. 시작 부분은 꽤 쉽습니다. FQDN을 사용하여 그룹을 검색합니다. 그런 다음 그룹의 Member 컬렉션, 구체적으로는 이 컬렉션의 Add 메서드를 사용하여 원하는 사용자의 FQDN을 추가합니다. 하지만 마지막 단계는 그리 직관적이지 않습니다. 숨겨진 PSBase 클래스의 CommitChanges 메서드를 호출하여 변경 내용을 저장합니다.
PSBase는 기본.NET Framework 개체를 직접 나타내는 특별 클래스입니다. 이 경우 CommitChanges가 Windows PowerShell에서 직접 노출되지 않으므로(실제로 ADSI 어댑터에 의해 노출되는 메서드가 없음) 기본 클래스에 액세스해야 합니다. 이 방법이 불가능한 것은 아니지만 직관적인 방법도 아닙니다. 또한 디렉터리 서비스 기능이 아직 Windows PowerShell에 완전히 적용되지 않았다는 사실도 보여 줍니다.
그 이유로는 여러 가지가 있습니다. 우선 Windows PowerShell 팀에서는 개발 주기의 후반부에 현재의 ADSI 지원을 셸에 추가했습니다. 셸 설계자인 Jeffrey Snover가 종종 말하듯이 "출시는 선택의 문제”입니다. 팀은 고정된 시간 내에 셸의 개발과 출시를 완료해야 하므로 다음 버전을 위해 남겨두어야 할 기능을 결정해야 했습니다. 이렇게 하지 않으면 몇 년 동안 기능만 추가하다 결국 지원 제품을 출시하지 못하게 될 것입니다.
하지만 또 다른 원인은 기본 .NET Framework에 있습니다. DirectoryServices 클래스가 꽤 복잡하고 이 복잡성을 Windows PowerShell에 적용하려면 많은 시간과 신중한 계획이 필요합니다. 필자 생각으로, Framework 클래스는 또한 Active Directory에 편향되어 있어서 WinNT 공급자에 대한 강력한 지원을 제공하지 않습니다. 당연히 Windows PowerShell도 Framework의 이러한 한계를 그대로 물려받습니다.
필자는 Windows PowerShell이 결국에는 매우 폭넓은 디렉터리 지원을 갖추기를 바랍니다. 이 지원은 ADSI 계층을 통한 지원이 아니라 .NET Framework의 기본 향상을 통한 지원일 수 있습니다. 그 동안에는 Windows PowerShell에서 사용 가능한 ADSI 지원을 통해 사용자 생성, 공통 사용자 속성 수정과 같은 다양한 관리 작업을 수행할 수 있습니다.
많은 디렉터리 서비스 작업을 WMI를 통해 할 수 있다는 점을 잊지 마십시오. microsoft.com/technet/scriptcenter/scripts의 스크립트에서는 WMI를 사용하여 로컬 그룹에 대해 ADSI 자체에서 제공하는 정보보다 더 광범위한 정보를 제공하는 훌륭한 몇 가지 예제를 볼 수 있습니다.


 Hey, Scripting Guy!: 구불구불한 빨간 선 스크립팅
Hey, Scripting Guy! 구불구불한 빨간 선 스크립팅 and Microsoft Scripting Guys
이 기사의 코드 다운로드: HeyScriptingGuy2007_06.exe (151KB)
한 번에 한 단어씩 수동으로 추가하지 않고 Microsoft Word 사전에 용어를 쉽게 추가할 수 있는 간단한 방법을 찾고 계십니까? 아마 누구나 이런 방법을 알고 싶을 것입니다. 이번 달 Scripting Guy에서는 Microsoft Word에서 사용자 지정 사전을 만들고 이러한 사전을 사용하도록 Word를 프로그래밍 방식으로 구성하는 방법을 소개합니다.
그림 1맞춤법 오류가 표시된 Word 문서
특별한 점이 있나요? 그렇습니다. Word는 Msgbox 같은 스크립팅 용어 아래에 구불구불한 선을 표시합니다. 왜 그럴까요? Word는 이러한 용어를 인식하지 못하기 때문입니다. 이런 용어를 인식하지 못한다구요? 이런...지난 몇 년 동안 Scripting Guy는 Msgbox를 몇 백만 번이나 입력했고 수 백만 번이나 맞춤법 검사를 실행했지요. 그리고 Word에게 Msgbox의 맞춤법이 올바르다고 알려 줬지만, 아직도 Word는 Msgbox, StrReverse, LTrim 같은 단어가 잘못되었다고 표시하고 있습니다. 도대체 뭐가 문제일까요?
독자 여러분이 Word를 위해 변호하지 않아도 이러한 단어를 Microsoft Word 사전에 수동으로 추가할 수 있다는 것을 잘 알고 있습니다. 하지만 우리는 Scripting Guy가 아닙니까? 수작업에는 서툴단 말입니다. 게다가 VBScript 함수, WMI(Windows® Management Instrumentation) 클래스 이름, ADSI(Active Directory® 보안 인터페이스) 개체 특성 등을 일일이 입력하는 것은 얼마나 지루한 일인지 모릅니다. 그리고 모든 컴퓨터에서 반복적으로 이러한 수작업을 한다고 상상해 보십시오. 또는 이와 같은 올바른 맞춤법 기준을 독자 여러분과 공유하려고 한다면 어떻게 해야 합니까? 더 많은 예를 들지 않아도 이쯤에서 이해했으리라 믿습니다.
어쨌든 중요한 점은 한 번에 한 단어씩 일일이 추가하지 않고도 스크립팅 용어(또는 다른 모든 용어)를 사전에 추가할 수 있는 방법이 있다는 것입니다.
아, 착각을 했네요. 그런 방법은 없다고 합니다. 그럼, 다음 달에 뵙겠습니다.
농담입니다. 물론 사전에 용어를 손쉽게 추가하는 방법이 있습니다. 그리고 이제부터 그 방법을 소개하도록 하겠습니다. 그러나 그 전에 사전에 대해서 간단히 설명하겠습니다.
사전과 관련해서 재미있는 사실이 하나 있습니다. 왜 미국인들은 영국인들과 달리 color를 colour로 적지 않을까요? 그리고 왜 centre 대신 center로 적을까요? 그 이유는 바로 최초의 미국 사전을 편찬한 Noah Webster가 영국식 맞춤법을 싫어해서 여러 단어의 맞춤법을 임의로 바꾸었기 때문입니다.
자, 본론에서 벗어난 주제는 이쯤에서 마치고, 사전에 대해 정말로 흥미로운 사실을 알아보도록 하겠습니다.
Microsoft Word에서는 응용 프로그램에서 기본 제공되는 표준 사전 외에도 사용자가 여러 개의 사용자 지정 사전을 만들 수 있습니다. 기본적으로 Word에는 Custom.dic이라는 사용자 지정 사전이 포함되어 있습니다. 이 사전은 일반적으로 사용자 프로필 폴더(Windows XP의 경우 기본적으로 \Documents and Settings\username)의 Application Data\Microsoft\Proof 폴더에 있습니다. 맞춤법 오류가 있는 단어를 마우스 오른쪽 단추로 클릭하고 사전에 추가를 선택하면 해당 단어가 Custom.dic에 추가됩니다.
Custom.dic은 단순한 일반 텍스트 파일입니다. 이 파일을 메모장에서 열면 다음과 같은 단어 목록을 볼 수 있습니다.
Aaberg
Aalling
Abbas
Abercrombie
Abola
Abolrous
Abrus
이 방법으로 스크립팅 용어를 Microsoft Word의 사전에 프로그래밍 방식으로 추가할 수 있습니다. 즉, 추가할 용어가 모두 포함된 텍스트 파일을 만들어 사용자 지정 사전으로 사용하도록 Word를 구성하기만 하면 됩니다. 이 과정은 얼마나 어려울까요? Scripting Guy가 기꺼이 이 작업을 하려는 걸로 봐서는 하나도 어렵지 않은 게 분명합니다.
그렇지만 이 작업을 수행하기 전에 알아 두어야 할 사항이 있습니다. Microsoft Word 개체 모델에서 사용자 지정 사전에 대한 정보는 CustomDictionaries 컬렉션에 저장됩니다. 그리고 이 컬렉션은 Word.Application 개체와 CustomDictionaries 속성을 참조하여 프로그래밍 방식으로 액세스할 수 있습니다. 예를 들어 그림 2에는 Microsoft Word에 연결된 모든 사용자 지정 사전에 대한 정보를 반환하는 스크립트가 나와 있습니다.
Figure 2 사용자 지정 사전 정보를 검색하는 스크립트 (Close Figure 2)
Set objWord = CreateObject(“Word.Application”)

Set colDictionaries = objWord.CustomDictionaries

For Each objDictionary in colDictionaries
  Wscript.Echo “Name: “ & objDictionary.Name
  Wscript.Echo “Language ID: “ & objDictionary.LanguageID
  Wscript.Echo “Language-specific: “ & objDictionary.LanguageSpecific
  Wscript.Echo “Location: “ & objDictionary.Path
  Wscript.Echo “Read-only: “ & objDictionary.ReadOnly
  intType = objDictionary.Type
  Select Case intType
    Case 0 Wscript.Echo “Type: Spelling”
    Case 1 Wscript.Echo “Type: Grammar”
    Case 2 Wscript.Echo “Type: Thesaurus”
    Case 3 Wscript.Echo “Type: Hyphenation”
    Case 4 Wscript.Echo “Type: Spelling (complete)”
    Case 5 Wscript.Echo “Type: Spelling (custom)”
    Case 6 Wscript.Echo “Type: Spelling (legal)”
    Case 7 Wscript.Echo “Type: Spelling (medical)”
    Case 8 Wscript.Echo “Type: Hangual-Hanja Conversion”
    Case 9 Wscript.Echo “Type: Hangual-Hanja Conversion (custom)”
  End Select
  Wscript.Echo
Next

objWord.Quit
그림 2의 스크립트를 실행하면 다음과 같은 정보가 반환됩니다.
Name: CUSTOM.DIC
Language ID: 0
Language-specific: False
Location: C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof
Read-only: False
Type: Spelling (custom)
훌륭합니다.
물론 기존 사전에 대한 정보를 가져오는 것은 새 사용자 지정 사전을 만드는 것과 아주 같지는 않습니다. 사실 두 가지 작업 간의 차이는 수십 억의 재산을 가진 사람에 대한 이야기를 읽는 것과 수십 억의 재산을 가진 사람이 되는 것의 차이와 비슷합니다. 그럼 Word에서 새 사용자 지정 사전을 만드는 방법을 살펴보겠습니다.
먼저 Scripting.dic이라는 새 사전에 모든 VBScript 함수를 추가합니다. 여기서 VBScript 함수를 먼저 추가하는 이유는 특별히 수행해야 할 단계가 있기 때문입니다. 물론 이후에는 WMI 클래스, ADSI 특성 및 Windows PowerShell™ cmdlet을 손쉽게 사전에 추가하는 방법을 설명하겠습니다. 무엇이든 손쉽게 할 수 있는 방법이라면 Scripting Guy가 전문가니까요.
Microsoft Word에서는 다음과 같이 간단하게 사용자 지정 사전을 만들 수 있습니다.
Set objWord = CreateObject _
  (“Word.Application”)

Set colDictionaries = _
  objWord.CustomDictionaries
colDictionaries.Add “Scripting.dic”

objWord.Quit
코드에서 보듯이 먼저 Word.Application 개체의 인스턴스를 만듭니다. Visible 속성을 True로 설정하지 않으므로 Word가 화면에 표시되지 않는다는 것을 알 수 있습니다. 왜 이렇게 할까요? 이 스크립트는 실행하는 데 1초 정도밖에 걸리지 않기 때문입니다. 따라서 Word를 화면에 표시해도 바로 사라지므로 의미가 없습니다. 그러나 단순히 스크립트가 실제로 작동되는지 알기 위해서 Word 인스턴스를 표시하려면 다음을 스크립트의 두 번째 코드 줄로 추가하면 됩니다.
objWord.Visible = True
Word.Application 개체를 만든 후에는 다음 코드 줄을 사용하여 CustomDictionaries 컬렉션에 대한 개체 참조를 만듭니다.
Set colDictionaries = _
  objWord.CustomDictionaries
그런 다음 Add 메서드를 호출하여 사용자 지정 사전을 추가합니다. Word에서 Scripting.dic이라는 파일을 찾지 못하면 같은 이름으로 빈 파일을 새로 만들므로 이 파일은 없어도 됩니다. 사용자 지정 사전을 추가하는 코드는 다음과 같습니다.
colDictionaries.Add “Scripting.dic”
새 사전을 추가할 때 경로를 지정하는 대신 Add 메서드에 파일 이름(Scripting.dic)을 제공한 것을 알 수 있습니다. 이는 물론 문제가 되지 않습니다. 이 경우 사전 및 기타 언어 교정 도구의 기본 폴더(예: C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof)에 Scripting.dic 파일이 만들어집니다.
사전을 다른 위치에 만들려면 어떻게 해야 할까요? 간단합니다. 다음 명령을 사용하면 C:\Scripts 폴더에 Scriptiong.dic이 만들어집니다.
colDictionaries.Add _
  “C:\Scripts\Scripting.dic”
그렇다면 나중에 사용자 지정 사전을 제거하려면 어떻게 해야 할까요? 이것도 어렵지 않습니다. 해당 사전만 바인딩하고 Delete 메서드를 사용하여 삭제하면 됩니다.
Set objWord = CreateObject _
  (“Word.Application”)
Set objDictionary = _
  objWord.CustomDictionaries _
  (“C:\Scripts\Scripting.dic”)
objDictionary.Delete

objWord.Quit
그림 3사용자 지정 사전을 추가한 후의 Word 문서
특히 Scripting.dic과 사용자 지정 사전 만들기 스크립트를 다른 사람과 공유할 수 있다는 점을 감안할 때 이는 매우 유용한 기능입니다. 사용자 지정 사전을 공유하는 즉시 해당 사용자의 Word에서 Msgbox가 맞춤법이 정확한 단어로 간주됩니다. 사실 Scripting Guy가 게을러서 여기서 이번 호 칼럼을 끝내더라도 독자들은 이미 유용한 정보를 얻은 셈입니다. 그러나 진짜 유용한 내용은 이제 시작입니다.
참고로, 우리가 게으른 건 사실이지만 이번 칼럼의 남는 공간을 채워야 했기 때문에 한두 가지의 보너스 스크립트를 싣기로 했습니다.
이미 알고 계시겠지만 VBScript와 Windows 스크립트 호스트는 모두 약간 수줍은 경향이 있어서 자신을 잘 드러내지 않습니다. 그러나 WMI, ADSI 또는 Windows PowerShell은 다릅니다. 조회만 하면 해당 클래스, 속성, 메서드 등 원하는 정보를 모두 얻을 수 있습니다.
ADSI를 예로 들어 보겠습니다. 그림 4에 나와 있는 스크립트는 Active Directory 스키마에 바인딩되어 사용자 계정 개체의 모든 특성을 검색합니다. 그런 다음 해당 특성을 C:\Scripts\Scripting.dic 파일에 기록합니다.
Figure 4 사용자 지정 사전에 ADSI 특성 이름 추가 (Close Figure 4)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

Set objSchemaUser = GetObject(“LDAP://schema/user”)

For Each strAttribute in objSchemaUser.MandatoryProperties
  objFile.WriteLine strAttribute
Next

For Each strAttribute in objSchemaUser.OptionalProperties
  objFile.WriteLine strAttribute
Next

objFile.Close
아주 훌륭합니다. 단 몇 줄의 코드로 Active Directory 사용자 개체의 특성이 모두 포함된 사전을 만들었으니 말입니다. 이 코드를 동료와 공유하면 streetAddress나 givenName과 같은 특성 이름이 맞춤법이 잘못된 단어로 표시되는 일이 없을 것입니다. 뿐만 아니라 이러한 사전은 무한히 확장할 수 있습니다. 컴퓨터 클래스의 속성을 추가하려면 다음 코드로 대체하면 됩니다.
Set objSchemaComputer = _
  GetObject(“LDAP://schema/computer”)
또는 WMI 클래스를 추가하고 싶다면 그림 5에 나와 있는 스크립트로 root\cimV2 네임스페이스의 모든 WMI 클래스를 검색하여 해당 정보를 C:\Scripts\Scripting.dic에 기록하면 됩니다.
Figure 5 사용자 지정 사전에 WMI 클래스 이름 추가 (Close Figure 5)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

strComputer = “.”

Set objWMIService=GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)

For Each objClass in objWMIService.SubclassesOf()
  objFile.WriteLine objClass.Path_.Class
Next

objFile.Close
Windows PowerShell 사용자는 잊었냐고요? Scripting Guy가 그럴 리가 있겠습니까? 사실은 깜박했지만, 모든 cmdlet 이름을 반환하고 C:\Scripts\Scripting.dic에 기록하는 다음 한 줄의 스크립트만 사용하면 됩니다.
Get-Command | Foreach-Object `
{Add-Content c:\scripts\scripting.dic -value `
$_.Name}
이번 호 칼럼의 장점은 독자는 물론, Scripting Guy도 배울 내용이 있었다는 것입니다. 독자는 Microsoft Word에서 사용자 지정 사전을 만들고 이러한 사용자 사전을 사용하도록 Word를 프로그래밍 방식으로 구성하는 방법을 배웠습니다. 그리고 Scripting Guy는 무언가 해야 할 일이 있다면 언제나 다른 사람이 대신 하도록 하는 것이 낫다는 점을 배웠습니다. 그리고 불가피한 경우에만 스스로 하면 되죠.


 The Desktop Files: 데이터 보호 방법
The Desktop Files 데이터 보호 방법 and Wes Miller 중요한 데이터가 손실되는 사고는 믿을 수 없을 만큼 자주 발생합니다. 그러나 사용자가 데이터를 제대로 보호하기만 하면 이러한 정보 손실은 충분히 방지할 수 있습니다. 이러한 의미에서 조직의 데이터를 보호하기 위해 따라야 할 중요한 단계에 대해 알아보겠습니다.
정보는 근본적으로 자유롭습니다. 누구에게 맡기든, 얼마나 철저하게 지키든, 0과 1의 조합으로 구성된 정보는 항상 유출되기 마련입니다. 매일 크고 작은 정보 유출 뉴스를 접할 수 있는데, 이러한 뉴스를 접할 때마다 중요한 정보가 그렇게 쉽게 유출된다는 사실에 어처구니가 없습니다.
그림 2알기 쉬운 잘못된 암호 선택
암호 무결성과 로컬 인증이 물론 중요하기는 하지만, 그것만으로는 로컬 시스템에 있는 데이터의 보안에 대해 안심할 수 없습니다. 물리적 보안이나 암호화 수단도 필요합니다. 암호만으로는 확실한 보안 해결책이 될 수 없기 때문입니다. 사용자 암호는 다른 도구는 사용하지 않고 시스템에 대한 직접 액세스에만 영향을 주려는 공격자가 그렇게 못하도록 하는 수단일 뿐입니다.

물리적 보안
물리적으로 위험에 노출될 가능성이 있거나 사무실에서 가지고 나갈 수 있는 시스템에는 중요한 데이터가 없어야 합니다. 누군가 Windows PE로 부팅하여 데이터를 검색할 경우 시스템이 위험에 노출될 가능성이 있다면 다른 문제가 있는 것입니다. Windows PE는 문제의 원인이 아닙니다. 다음 중 하나 이상이 문제의 근원입니다. 첫째, 시스템이 물리적으로 적절하게 보호되지 않았습니다. 또는 시스템이 물리적으로 보호되었지만, 액세스 권한이 있는 사용자를 신뢰할 수 없고, 시스템의 데이터가 물리적으로 안전하지 않거나(또는 물리적으로 보호할 수 없거나) 물리적으로 보호되지 않은 시스템에 데이터가 있으며, Windows Vista의 BitLocker™ 기능과 같은 볼륨 암호화 도구를 사용하여 물리적 손상 위협을 완화하지 않았습니다. BitLocker에 대한 자세한 내용은 이번 호 TechNet Magazine에서 Byron Hynes의 기사를 참조하십시오.
어떤 시스템이 위험에 노출되어 있는지 생각해 보십시오. 이러한 시스템을 물리적으로 보호할 수 있습니까? 데이터센터나 액세스가 제한된 그 밖의 구역에 배치하지 않는 이유는 무엇입니까? 그러한 구역에 배치할 수 없거나 모바일 시스템이라면, 볼륨 암호화 소프트웨어를 사용하고 있습니까? 이러한 단계를 적용할 수 없다면 데이터를 안전하거나 암호화되는 시스템으로 옮기십시오. 앞서 언급한 것처럼 랩톱을 도난당한 경우 안전한 볼륨 암호화 도구로 볼륨을 암호화했다면 데이터가 도용될 위험이 거의 없다고 할 수 있습니다.
시스템을 데이터센터에 두었다고 해서 전적으로 안심할 수 있는 것은 아닙니다. 인터넷으로 연결되는 T1 선을 여러 개 연결한 경우에는 여전히 위험에 노출될 수 있기 때문입니다. 인터넷 연결은 악의적인 사용자에게 물리적 액세스를 제공하는 결과를 낳을 수 있으므로 시스템에 대한 위협에 주의를 기울여야 합니다. 따라서 인터넷과 시스템 사이에 다른 수준의 네트워크 보호가 이루어지도록 별도의 네트워크 세그먼트로 시스템을 옮기는 것이 좋습니다.

데이터 위험 완화
다른 보안 예방책으로는 물리적으로 안전한 서버에 데이터를 격리하는 씬 클라이언트 도구나 응용 프로그램을 통해 사용자가 액세스하도록 하는 방법이 있습니다. 이 경우 다른 곳에 있는 사용자가 액세스할 수 있도록 VPN을 통해 액세스를 제공할 수도 있습니다. 그런데 사용자의 물리적 제약에 따라 데이터 취급 방법을 결정해서는 안 됩니다. 즉, 광대역이나 기타 고속 액세스가 불가능한 지역에 있는 사용자가 액세스를 필요로 한다고 해서 데이터를 사용자 컴퓨터의 로컬 인스턴스로 이동해서는 안 됩니다. 안전하지 않은 위치에 있는 시스템을 이동하기가 불가능하다면 볼륨 암호화를 사용하여 데이터를 보호해야 합니다.

시스템 내부 보안
모든 보안 조치에도 불구하고 누군가 하드 디스크를 제거하여 NTFS ACL을 다시 설정할 수 있는 다른 Windows 시스템에 설치하는 방법으로 시스템에 액세스할 가능성에도 대비해야 합니다.
Windows Vista에 포함된 볼륨 암호화 기능을 사용하면 이러한 문제에 대비할 수 있습니다. 다른 대부분의 Windows 버전에서는 여러 가지 타사 도구를 사용할 수 있습니다. 이러한 도구는 사용상의 복잡성이나, EFS(암호화 파일 시스템)에 따른 전체 볼륨 암호화와 개별 파일 또는 디렉터리 암호화를 수행하는 기능이 제각기 다릅니다. 볼륨을 암호화하면 최고 수준의 해커 공격을 제외한 대부분의 공격으로부터 보호됩니다.

보관 보안
백업 데이터도 보호해야 합니다. 사람들이 시스템을 안전하게 백업하지 않는 두 가지 이유는 백업 시에 암호화할 경우 시간이 너무 오래 걸리거나 백업 소프트웨어에서 암호화 기능을 지원하지 않기 때문입니다.
그러나 시스템을 백업할 때, 특히 백업을 오프사이트에 보관하는 경우에는 백업에 포함할 데이터를 보호해야 합니다. 그 방법으로는 가능한 경우 EFS 또는 기타 볼륨 암호화 소프트웨어(예: Windows Vista의 BitLocker 기능 또는 타사 소프트웨어)를 사용하거나, 암호화 기능이 포함되어 있고 적절한 수준으로 암호화를 수행하는 백업 소프트웨어를 구입하는 방법이 있습니다. 백업 테이프에 저장된 데이터가 알아보기 어렵다거나 디스크 기반 백업 솔루션에서 분할되었다고 해서 안전하다고 할 수는 없습니다. 전송 메커니즘 자체도 위험을 초래할 수 있다는 사실을 알아야 합니다.

전송 보안
인터넷을 통해 전송되는 모든 데이터는 보호해야 합니다. 원격 시스템에 액세스할 때는 안전한 프로토콜만 사용합니다. 또한 암호화된 버전의 프로토콜을 사용하고 항상 MITM(Man-In-The-Middle) 공격 가능성에 대비해야 합니다. 그리고 약하게 암호화되거나 아예 암호화되지 않은 프로토콜을 사용해서는 안 되며, 암호화를 사용할 때는 약한 암호화 수준 또는 알고리즘을 사용해서도 안 됩니다. 조직에서 누군가는 인프라에서 시스템 간에 사용되는 모든 통신 프로토콜과 암호화 알고리즘을 이해하고 있어야 합니다.

안전한 삭제
eBay 또는 지역의 벼룩 시장에서 구입한 하드 디스크나 기타 저장소 장치에서 추적 소프트웨어나 일반적인 복구 유틸리티를 사용하여 드라이브를 판매하기 전에 완전히 삭제한 데이터를 찾아내어 도용하는 사례를 종종 접하곤 합니다.
조직에서 UFD를 사용한다면 강제 암호화 유틸리티를 도입하는 것이 좋습니다. 위험성이 높은 데이터가 들어 있는 모든 디스크는 암호화해야 합니다. 일반적으로 알려진 사실과는 달리, 폐기 전에 볼륨을 암호화하는 것만으로는 디스크를 안전하게 폐기할 수 없습니다. 앞서 언급한 의료 폐기물 비유를 기억하십니까? 이러한 시스템의 데이터를 위험한 폐기물이라고 하면 안전한 데이터 삭제 유틸리티는 적절한 취급 방법이라고 할 수 있습니다. 따라서 디스크와 시스템을 중고 시장에 내놓기 전에, 또는 조직 내에서 다른 위치로 이동하기 전에도 Mark Russinovich의 SDelete와 같은 데이터 삭제 도구를 사용하여 DoD 5220.22-M 사양에 맞게 데이터를 삭제해야 합니다. 그렇지 않으면 다음 사용자가 이전 사용자의 데이터를 모두 도용할 수 있습니다.

감사
마지막으로 중요한 데이터 보안 구성 요소는 바로 감사와 조직의 데이터 수명 주기를 바탕으로 한 위협 모델링입니다. 데이터 누출이 발생할 수 있는 취약점을 파악하고 이러한 취약점을 신중하게 감시하는 것입니다. Windows에는 몇 가지 기본 제공 감사 도구가 포함되어 있습니다. 그러나 감사 기능을 사용하면 데이터 오버플로가 발생하기 쉽습니다. 따라서 올바른 영역을 감사하고 있는지, 그리고 데이터가 과도하게 생성되지 않는지를 항상 확인해야 합니다. 파악된 취약점은 일시적인 미봉책이 아닌 충분한 완화 수단으로 적절히 보완해야 합니다. 또한 사용자에게 적절한 데이터 취급 방법을 교육해야 합니다. 사용자는 조직의 여러 부문에서 중요한 연결 고리가 됩니다. 이외에도 "추가 리소스"에 여러 가지 추가 지침이 나와 있습니다. 안전한 정보 이용을 위해서는 여기에서 제시한 제안 사항을 따르시기 바랍니다.
추가 리소스
"핵심 인프라 최적화 구현 도구 리소스 가이드—기본 수준에서 표준화 수준으로"에서는 IT 인프라를 수작업 비율이 높고 사후 대응적인 기본 수준에서 보다 자동화되고 구성 표준이 적용되고 작업이 개선된 표준화된 수준으로 전환하는 방법에 대해 설명합니다. 이 가이드는 go.microsoft.com/?linkid=5795711에서 다운로드할 수 있습니다. 또한 microsoft.com/io에서는 "추가 인프라 최적화 구현 도구 리소스 가이드"를 다운로드할 수 있습니다. 마지막으로 "10가지 불변의 보안 법칙"에서 추가 보안 팁을 참조하시기 바랍니다.


 Field Notes: 개발자와의 대화
Field Notes 개발자와의 대화 and David Aiken 개발자로 하여금 보다 관리가 용이한 응용 프로그램을 구축하도록 하는 것은 생각보다 쉽습니다. 가장 첫 단계는 바로 의견 교환입니다. 개발자는 소프트웨어를 보는 관점이 관리자와는 다릅니다. 하지만 관리자가 개발자와 대화를 통해 중요하게 생각하는 사항을 설명한다면 개발자는 그에 따라 보다 나은 코드를 설계할 수 있습니다.
이상하게도, 개발자는 관리자와 다른 관점으로 소프트웨어를 파악합니다. 개발자는 코드, 추적, XML 구성 파일, GUID, 어셈블리 등을 사용하는 반면, 관리자는 스크립트와 MMC(Microsoft® Management Console) 스냅인을 사용합니다. 적어도 이러한 것들을 선호합니다.
사실 한 걸음 물러나서 보면 어떤 날은 전체 소프트웨어 개발 프로세스가 망가진 것처럼 보입니다. 우리는 수많은 리소스를 사용하여 최종 사용자의 요구 사항을 파악합니다. 프로토타입을 만들고, 유용성을 조사하고, 면담을 실시하고 그 외 무엇이든 다 하지만, 간단하고 일관된 관리 환경은 제대로 제공하지 못합니다. 기준에 훨씬 못 미치게 말입니다.
예전에는 Xcopy, Regedit 및 메모장이 소프트웨어를 설치하는 최선의 수단이라고 생각했습니다. 그러나 이제는 사용자 지정, 설치 및 제거가 가능한 MSI(Microsoft Installer)가 최선이라고 생각합니다. 관리자가 메모장을 사용하여 XML을 편집하는 방법으로 웹 서비스를 구성하기를 기대하는 것은 좋은 생각이 아니라는 사실과 MMC 스냅인이나 Windows PowerShell™ 스크립트를 택하는 것이 훨씬 낫다는 사실을 잘 알고 있습니다. 또한 사용자나 관리자는 스택 추적을 통해 문제의 근본 원인과 가능한 해결 방법을 찾기가 어려우며, 응용 프로그램 로그에 잘 작성된 이벤트가 훨씬 낫다는 사실도 잘 압니다. 마지막으로, 관리자가 관리 및 운영할 수 있는 소프트웨어를 만들려면 관리자를 사용자와 똑같이 생각해야 한다는 것도 알게 되었습니다.
관리자를 사용자와 동일시하면 사용 사례를 파악하고, 프로토타입을 만들고, 유용성을 조사하는 등의 프로세스를 진행할 수 있습니다. 그리고 결과적으로 관리자에게 가장 적합한 환경을 제공할 수 있습니다. 다시 말해, 개발자의 도움 없이도 소프트웨어를 설치하고, 구성하고, 모니터링하고, 수정하고, 문제를 해결하는 데 도움이 된다는 것입니다. 관리자에게 익숙한 운영 체제에서 기본 제공되는 관리 기능을 사용한다면 문제 해결 단계가 줄어 응용 프로그램 실행 비용을 절감할 수 있을 뿐만 아니라, 응용 프로그램 작동 중단이 줄고 사용자가 직접 문제를 신속하게 해결할 수 있으므로 사용자 만족도를 높일 수 있고, 우리 소프트웨어를 더 많이 구매하도록 할 수 있습니다. 그러면 재벌이 되는 건 시간 문제겠죠.
재벌은 헛된 꿈일지 모르지만, 개발자로 하여금 보다 관리가 용이한 응용 프로그램을 구축하도록 하는 것은 절대 꿈이 아니라 실현 가능한 목표입니다. 그리고 여러분이 그렇게 하도록 도울 수 있습니다. 다음에 소프트웨어에서 문제가 발생하면 개발자에게 전자 메일 메시지를 전달하거나 조용히 이름을 부르는 대신, 응용 프로그램 로그에 이벤트를 작성하거나 성능 카운터 또는 기타 문제를 나타낼 수 있는 수단을 제공하도록 제안해 보십시오. 가능한 원인과 해결 방법까지 제시한다면 금상첨화입니다. 또한 응용 프로그램을 구성할 수 있는 Windows PowerShell 스크립트나 MMC 콘솔을 만들어 달라고 부탁해 보십시오. 요지는 개발자가 여러분의 요구 사항은 물론 여러분의 존재도 고려하지 않을 때가 많다는 사실입니다. 따라서 여러분이 먼저 개발자와 대화를 시작해 보십시오.


 Windows Confidential: 시작 메뉴의 새로운 기능
Windows Confidential 시작 메뉴의 새로운 기능 and Raymond Chen 새 컴퓨터를 구입하여 Windows를 실행한 다음 시작 단추를 클릭했을 때 빈 메뉴가 나타난다면 어떨지 상상해 보십시오. 컴퓨터를 한 번도 사용하지 않았을 때도 시작 메뉴에 자주 사용하는 응용 프로그램이 표시되는 데, 여기에는 다 그만한 이유가 있습니다. 바로 적절한 최초 사용 환경을 제공하기 위해서입니다. 이때 나타나는 응용 프로그램에 대해 알아보겠습니다.
처음에는 이 비어 있는 초기 시작 메뉴를 텍스트로 채우는 방법을 고려했습니다. "지금은 이 공간이 비어 있지만 프로그램을 실행하고 나면 여기에 프로그램이 표시될 것입니다."와 같은 텍스트를 삽입한다면 이 공간이 더 이상 우스꽝스럽게 보이지 않으리라고 생각한 것입니다. 그러나 이렇게 하면 우스꽝스러울 뿐만 아니라 볼품 없기까지 하다는 사실을 알게 되었습니다.
여러 가지 실험을 거친 후 결국 Windows XP에서 지금 여러분이 보는 것과 같은 초기 시작 메뉴를 결정할 수 있었습니다. 지난 호에서는 자주 사용하는 프로그램 목록이 점수 시스템을 기반으로 한다는 사실을 설명했습니다. 점수가 가장 높은 프로그램이 이 동적 목록에 표시되는 겁니다. 그리고 새 사용자의 경우 여러 프로그램에 임의의 점수를 부여하여 표시되도록 했습니다. 결과적으로 초기 시작 메뉴에 흥미로운 프로그램을 샘플로 표시하여 기능에 대한 이해를 돕도록 했습니다.
임의의 점수는 자주 사용하는 프로그램 목록에 원하는 프로그램을 표시하는 데는 충분하지만 사용자가 응용 프로그램을 실행함에 따라 실제로 부여되는 점수보다는 크지 않도록 신중히 부여되었습니다.
그러나 사용자가 Windows 2000에서 업그레이드한 경우에는 이러한 임의 점수가 부여되지 않습니다. 이 경우 Windows 2000 시작 메뉴에서 Intellimenus에 사용한 점수가 Windows XP 점수 시스템의 초기 점수로 사용됩니다. 따라서 Windows 2000에서 가장 자주 실행한 프로그램이 업그레이드된 Windows XP의 시작 메뉴에 즉시 반영됩니다.
Windows XP의 초기 릴리스에서는 임의 점수가 부여되어 자주 사용하는 프로그램 목록의 6개의 슬롯 중 처음 3개가 Windows에 의해 선택되고 나머지는 컴퓨터 제조업체에 의해 선택됩니다. 미리 설치된 버전이 아니라 정품 버전의 Windows XP를 구입한 경우에는 컴퓨터 제조업체의 슬롯 3개 중 2개가 Windows에 의해 채워지고 나머지 슬롯은 비어 있게 됩니다. 따라서 처음 실행한 프로그램이 시작 메뉴에 즉시 표시됩니다.
Windows XP 서비스 팩 1에서는 이러한 6개 슬롯에 변화가 있었습니다. 슬롯 중 2개는 Windows에 의해 선택되고 하나는 미국 법무부, 그리고 나머지 3개는 컴퓨터 제조업체에서 선택하게 된 것입니다. 이전과 마찬가지로 정품 버전의 Windows XP를 구입한 경우에는 컴퓨터 제조업체 슬롯 중 2개가 Windows에 의해 할당되고 나머지는 비어 있게 됩니다.
시작 메뉴는 Windows 사용자 인터페이스에서 가장 자주 보게 되는 부분으로, 지금까지 설명한 내용에서 알 수 있듯이 많은 노력을 거쳐 현재와 같이 자연스럽고 직관적인 모습을 갖추게 되었습니다.


 Letters: 질문에 대한 답변
Letters 질문에 대한 답변
Windows PE 시작
TechNet Magazine 2006년 9월호에 게재된 Wes Miller의 기사 "Windows PE 시작"을 읽은 후 HTA(HTML for Applications) 기반 마법사로 메뉴를 만들어 보았습니다. Windows® PE 2.0에서 메뉴가 작동하도록 하는 것에 대해 몇 가지 질문이 있습니다.
—Andy

다음은 질문하신 각 내용과 그에 대한 Wes의 답변입니다.

선택적 소프트웨어 구성 요소 HTA와 WSH(Windows 스크립트 호스트)가 ISO 파일에서 실행되는지 여부를 알려면 어떻게 해야 합니까?
기사의 안내에 따라 ISO 파일에 선택적 구성 요소를 설치했으면 정상적으로 작동할 것입니다. 작동하지 않는 경우에는 다음 두 가지 시나리오가 주된 원인인 것으로 알고 있습니다. peimg /prep를 실행하여 이미지를 준비하지 않았거나, 분리할 때 Windows PE에 변경 내용을 실제로 커밋하기 위해 ImageX에 /commit 매개 변수를 사용하지 않았기 때문입니다.

WMI(Windows Management Instrumentation)가 설치되어 있어야 합니까? 기사의 마법사 파일의 경우 Internet Explorer® 오류가 발생합니다.
마법사 파일은 매우 기본적이기 때문에 HTA가 설치되어 있으면 정상적으로 작동합니다. WMI는 필요하지 않으며, 필자는 실제로 Windows PE에 WMI를 추가할 수 있기 전에 이 파일을 작성했습니다.

startnet.cmd 파일에 OC.bat를 포함해야 하는 이유가 무엇입니까?
Windows PE 2.0을 사용하고 있으면 OC.bat를 사용할 필요가 전혀 없습니다. 이 파일은 1.x에서만 필요합니다. Windows PE 2.0에서는 OC.bat에서 수행되는 과정을 사용하지 않고도 구성 요소를 추가할 수 있습니다.

정상 작동이 확인된 후 제 메뉴에 Wes의 코드 일부를 사용해도 됩니까?
코드 샘플을 자유롭게 가져가서 원하는 대로 재사용하십시오. 하지만 샘플 코드 패키지의 일부로 재배포하거나 재판매할 수는 없습니다. 자세한 내용은 TechNet Magazine 웹 사이트의 사용권 계약을 참조하십시오.

Windows PE는 어디에서 구할 수 있습니까?
Windows PE 빌드 도구는 어디에서 찾을 수 있습니까? 다운로드할 수 있습니까? 아니면 구입해야 합니까?
—Franklin
Windows Vista™용 Windows PE 빌드 도구는 WAIK(Windows 자동 설치 키트)의 일부로, go.microsoft.com/fwlink/?LinkId=85377에서 다운로드할 수 있습니다.
WAIK는 Windows Vista 운영 체제 제품군에만 제공됩니다. Windows XP의 경우에는 Business Desktop Deployment Solution Accelerator에서 비슷한 도구를 찾아볼 수 있습니다. 하지만 Windows Vista에서는 Windows PE에 대한 라이선스가 변경되었습니다. Windows XP 이전의 Windows PE는 Software Assurance 라이선스를 통해서만 사용할 수 있습니다. 자세한 내용은 microsoft.com/licensing/sa/benefits/winpe.mspx를 참조하십시오.

파일 서버 리소스 관리자
Windows Server® 2003의 원본 릴리스에서 사용할 수 있도록 파일 서버 리소스 관리자 패키지의 공개 다운로드가 제공될 예정입니까? 아니면 이 패키지는 R2 릴리스와만 호환됩니까?
—Dan
파일 서버 리소스 관리자는 Windows Server 2003 R2의 기능입니다. 이 버전에서의 종속성 때문에 현재로서는 이전 릴리스에서 호환되도록 만들 계획이 없습니다.

커널 속으로
Mark Russinovich의 기사 "Windows Vista 커널 속으로: 3부"를 읽은 후 두 가지 의문이 생겼습니다. 첫 번째로 Process Explorer에서 exe 또는 DLL 파일이 임의로 각 부트 세션에 배치되는 것을 발견했습니다. 맬웨어가 이 메커니즘을 사용하여 악용하려는 코드의 위치를 알아내는 것이 가능합니까? 두 번째로 불규칙화가 시작될 수 있는 위치가 256개라면(제가 기사를 제대로 이해했다면) 대상 코드가 세션에 대해 정적 상태를 유지하는 경우 맬웨어의 "무작위 공격" 탐색을 방지할 방법은 무엇입니까?
—Joe

Mark가 이 질문에 대한 답변을 제공했습니다.

Process Explorer에서는 '닭이 먼저냐, 달걀이 먼저냐'와 같은 상황이 생깁니다. 즉, 맬웨어는 DLL 위치를 반환하는 API의 위치를 알 수 없기 때문에 DLL의 위치를 알아낼 수 없습니다. 맬웨어 "무작위 공격" 탐색의 경우 맬웨어의 추측이 틀리면 감염시키려 하는 응용 프로그램이 중단될 가능성이 크기 때문에 확실한 침입 방법이 아닙니다. 불규칙화는 최소한 바이러스의 전파 속도를 늦추며 최상의 경우에는 맬웨어의 시스템 감염을 방지합니다.

문의처
의견이 있으시면 언제든지 알려주십시오. 독자 여러분의 의견을 항상 환영합니다. tnmag@microsoft.com으로 전자 메일을 보내 주십시오.