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

Wes Miller

3년도 더 지난 어느 해에, 필자는 주 Windows 시스템에서 사용자 계정을 로컬 관리자 계정에서 로컬 사용자 계정으로 전환하는 작업에 착수했습니다. 필자는 Microsoft에 7년 이상 근무하면서 항상 모든 권한을 가진 관리자로 시스템을 실행해 왔습니다. 물론 이 방법이 매우 편리하기 때문이지요. 그러나 한편으로는 매일 보안에 취약한

관리자 계정으로 많은 시스템을 실행함에도 불구하고 이에 비해 시스템에 보안 문제가 그리 자주 발생하지 않는다는 점을 확인할 때마다 대부분의 사용자가 그렇겠지만 내가 운이 정말 좋다는 생각이 강하게 들었습니다.

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

어떻게 지금에 이르게 되었을까요?

여러분께 드리는 당부: 어려움을 체험해 보기

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

이전부터 Windows®의 주축을 이루는 사용자 대부분은 시스템에서 관리자로 실행하는 사용자였습니다. Windows NT® 3.1 이전 버전인 Windows 최초 버전의 경우 모든 대화형 사용자는 강력한 권한을 부여받았기 때문에 기능적으로 보안이 전혀 보장되지 않았다고 할 수 있습니다. 집에서 시스템을 실행한 경우에는 그다지 나쁘지 않았습니다. 이 경우는 모든 소프트웨어가 동일한 방식으로 설치되었음을 의미했으니까요. 즉, 여기에는 사용자가 컴퓨터를 소유하고 있고 모든 소프트웨어가 해당 컴퓨터의 모든 사용자를 위해 설치되었다는 가정이 깔려 있었습니다.

Windows NT가 처음 출시되었을 때 이 운영 체제는 일반 소비자는 물론, 기업 시장을 바로 석권하지는 못했습니다. 게다가 32비트 Windows와 Windows NT 간의 Win32® 호환성으로 인해 대부분의 응용 프로그램 공급업체에서는 Windows NT의 보안 인프라를 위해 자사의 응용 프로그램을 다시 빌드하지 않았습니다. 대부분의 소비자 지향적 ISV(Independent Software Vendor)의 경우 Windows 2000이 등장하기 전까지는 Windows NT에 그다지 많은 관심을 기울이지 않았던 것이 사실입니다. 물론 Windows XP 등장으로 인해 Windows 9x 제품군이 더 이상 사용되지 않게 되면서 이 문제가 저절로 해결되었지만 서두요.

그러나 아직도 많은 응용 프로그램이 시스템의 모든 사용자가 Program Files, 레지스트리의 HKEY_LOCAL_MACHINE(HKLM) 및 HKEY_CLASSES_ROOT에 쓰기 권한이 있다는 전제하에 작동되고 있습니다. 실제로는 사용자에게 이러한 권한이 없는데도 말이지요. 이러한 전제하에 작동됨으로써 가장 안 좋은 문제가 발생하는 응용 프로그램 중 하나는 바로 게임입니다. 자세한 내용은 technetmagazine.com/issues/2007/02/Gaming에서 이 주제를 다룬 Matt Clapham의 기사를 참조하시기 바랍니다.

이는 문제가 발생할 소지가 많습니다. 왜냐하면 대부분의 시스템 간 응용 프로그램에서는 파일 및 레지스트리 설정을 위에 언급한 위치에 저장하며 이러한 응용 프로그램을 설치하려면 해당 위치에 대한 읽기/쓰기 권한이 있어야 하기 때문입니다. 이에 따라 안타깝게도 일부 응용 프로그램에서는 설치 후 이러한 키에 대한 쓰기 권한을 요구합니다. 예를 들어 필자의 자녀가 플래시 기반 게임을 하는 경우를 가정해 보겠습니다. 이 게임은 매번 실행할 때마다 사용자 지정 플레이어를 설치하려고 시도합니다. 즉, 아이가 관리자가 아닌 사용자로 실행할 경우 응용 프로그램을 시작할 수 없으며 심각한 오류가 발생하게 됩니다. 이는 비록 극단적인 사례이고 이 프로그램은 소비자 응용 프로그램이지만 실제로 관리자가 아닌 사용자로 실행할 경우 많은 비소비자 응용 프로그램이 제대로 실행되지 않습니다. 관리자 여러분이 필자의 조언을 따른다면(추가 기사 "여러분께 드리는 당부: 어려움을 체험해 보기" 참조) 사용자로 실행하는 경우 Windows 자체에 얼마나 제약이 많은지 알게 될 것입니다.

그림 1을 살펴보면 Windows XP에서 사용자로 IPConfig /release를 실행할 때 어떠한 결과가 나타나는지를 알 수 있습니다. 이를 그림 2와 비교해 보면 Windows Vista에서 동일한 명령을 실행하는 경우 그 기능이 크게 향상되지는 않았으나 최소한 명령이 실패하는 이유를 파악할 수는 있습니다. 참고로 이 네트워킹 도구는 사용자가 IP 주소를 새로 고칠 수 있도록 전체적으로 향상되었습니다. 이와 유사하게 둘 중 한 가지 버전에서 컴퓨터 관리(compmgmt.msc)를 사용자로 실행할 경우 제한된 작업을 수행할 수 있긴 하지만, 대부분 그림 3에서 볼 수 있는 바와 같이 결국에는 작업을 수행할 수 없는 결과에 직면하게 됩니다. Windows Vista에서는 컴퓨터 관리에 포함된 많은 도구를 애초에 실행할 수 없지만 액세스 거부 메시지가 더 명확하게 표시됩니다.

그림 1** Windows XP에서 사용자로 실행하는 경우 **(더 크게 보려면 이미지를 클릭하십시오.)

그림 2** Windows Vista에서 사용자로 실행하는 경우 **(더 크게 보려면 이미지를 클릭하십시오.)

그림 3** Windows XP에서 사용자로 compmgmt.msc를 실행한 후 표시되는 잘못된 메시지 **(더 크게 보려면 이미지를 클릭하십시오.)

이 문제가 중요한 이유

우리가 이 문제를 고려해야 하는 이유는 무엇일까요? IT 전문가의 관점에서 본 정답은, 대화형 사용자가 시스템을 소유하고 있는 것으로 가정하는 응용 프로그램이 있는 경우 해당 응용 프로그램을 모든 권한이 아닌 최소 권한이 부여된 사용자에 맞춰 조정될 수 있도록 강제적인 조치를 취해야 하기 때문입니다.

안타깝게도 관리자에게 레지스트리 키에 대한 쓰기 권한을 허용하는 정책은 사용자 컨텍스트에서 실행되는 모든 맬웨어에게도 ACL(액세스 제어 목록)을 통해 명시적으로 거부되지 않은 모든 항목에 대한 모든 권한을 부여합니다. UNIX 운영 체제에서는 사용자가 루트(Windows Administrator 계정과 동일)로 실행하지 않는 규칙을 따릅니다. 이는 주로 보안 모델의 경계를 확장하는 소프트웨어 환경이 매우 작거나 아예 존재하지 않기 때문입니다.

가장 좋은 방법은 이와 같은 방식을 따르거나 명시적으로 필요한 경우에만 관리자로 실행하는 것입니다. 더욱 좋은 방법은 개별 응용 프로그램을 실행할 때에만 관리자로 실행하는 것입니다. 이렇게 함으로써 앞서 언급했던 인트라 시스템 방화벽 기능을 향상할 수 있습니다. 그러면 맬웨어나 스파이웨어가 시스템을 감염시키기 위해 필요한 레지스트리나 파일 시스템 위치에 쓰기 작업(예: 서비스 또는 드라이버 설치, 모든 사용자를 위한 설치)을 수행할 수 없으므로 공격에 실패합니다. 또한 이렇게 하면 전체 시스템을 위험에 빠뜨리기 전에 맬웨어 방지 소프트웨어에서 인식하는 맬웨어를 방지할 있습니다.

그러나 이러한 사용자가 공격에 강한 것은 아닙니다. 광범위하게 존재하는 것은 아니지만 여전히 개별 사용자 컨텍스트를 감염시키거나 데이터를 파괴할 수 있는 맬웨어가 존재합니다. 하지만 이러한 소프트웨어로 인해 발생하는 공격 요소는 제한적입니다. 결과적으로, Linux 또는 Macintosh의 맬웨어 공격 수를 낮춰 주는 방법(공격에 취약한 요소를 줄여 맬웨어 작성자가 활동할 수 있는 영역을 줄임)을 동일하게 사용하여 최종 사용자는 물론 관리자의 안전을 보장할 수 있습니다.

고급 사용자는 안전한가요?

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

잃는 게 더 많은 권한

필자가 3월호에 게재한 Windows 씬 클라이언트에 대한 칼럼(technetmagazine.com/issues/2008/03/DesktopFiles)을 읽었다면 공간 절약을 위해 Windows XP를 축소하는 방법에 대한 예상 효과에 대해 필자가 반대 의견을 피력했던 점이 기억이 나실 겁니다. 이와 같은 맥락에서, 관리자에서 사용자로 전환 시 고려해야 할 흔히 사용되는 방법이 있으나 이 방법을 수행할 때에는 매우 주의를 기울여야 합니다. 이 방법은 바로 레지스트리 및 파일 시스템의 ACL을 조정하여 일반적으로 사용자에게 부여되지 않는 이 위치에 대한 쓰기 권한을 부여하는 것입니다. 바로 이 과정에서 응용 프로그램에 문제가 발생할 수 있습니다.

물론 가장 좋은 방법은 업데이트된 응용 프로그램을 구하는 것이고, 이렇게 하면 위와 같은 변경 작업을 수행할 필요도 없지만 이 방법이 항상 가능한 것은 아닙니다. 권한을 변경해야 할 경우에는 이는 곧 권한을 삭제하는 것을 의미하므로 대단히 신중하게 처리해야 합니다. 사용자와 관리자 사이의 방화벽은 레지스트리 및 파일 시스템 권한에 따라 광범위하게 정의되어 있다는 사실을 유념해야 합니다. 권한을 높이면 보안이 취약해지고 맬웨어에 의한 잠재적인 공격 노출 영역이 확장될 수 있으므로 신중하게 판단하여 작업을 수행하십시오.

UAC란 무엇입니까?

Windows Vista의 UAC(사용자 계정 컨트롤)에 대해 언급하지 않고는 관리자에서 사용자로 전환하는 방법을 완벽하게 설명했다고 볼 수 없습니다. UAC는 Mac OS X의 기능과 유사하며 큰 위험 요소 없이 "관리자로" 실행할 수 있게 해 주는 기능입니다.

UAC는 어떤 원리로 작동할까요? Process Explorer에서 cmd.exe에 대해 어떠한 항목을 표시하는지 그림 4를 통해 살펴보십시오. 오른쪽에 표시된 cmd.exe 인스턴스는 관리자로 실행했으므로 권한 상승 없이 시작되었습니다. 결과적으로 오른쪽에 표시된 사용자가 왼쪽(cmd.exe가 권한 상승을 통해 시작된 경우)에 표시된 사용자와 동일한 경우에도 해당 응용 프로그램 자체에는 관리자 권한을 필요로 하는 모든 작업을 수행하는 데 필요한 권한 및 응용 프로그램 및 해당 인스턴스를 실행하는 사용자를 위한 토큰이 없습니다. UAC는 사용자 대화형 컨텍스트 내의 공격 노출 영역을 줄이는 방식으로 작동합니다. 다만 한 가지 문제점은 Windows에서 이 작업을 수행하려면 관리자 권한이 필요하며 사용자에게 이 작업을 완료하는 데 필요한 권한 상승이 허용되는 경우 이 작업을 수행할 수 있음을 지정해야 한다는 점입니다.

그림 4** 서로 다른 권한으로 실행되는 
cmd.exe의 두 인스턴스 **(더 크게 보려면 이미지를 클릭하십시오.)

Windows Vista의 작은 방패 표시는 권한 상승이 필요한 작업을 나타냅니다(그림 5 참조). 이러한 작업은 매번 실행할 때마다 권한 상승을 해야 하며 바로 이 부분이 언론에서 꼽은 Windows Vista의 단점 중 하나입니다. 이에 대한 대안으로 자격 증명을 보다 "까다롭게" 설정하여 손쉽게 시스템을 악용할 수 있는 잠재적인 보안 위협 요소를 제거할 수 있습니다.

그림 5** 권한 상승 필요를 나타내는 Windows Vista의 방패 표시 **(더 크게 보려면 이미지를 클릭하십시오.)

UAC가 설정되어 있으며 사용자가 간단하게 사용자 계정으로 실행 중인 경우 관리자 권한이 필요한 응용 프로그램 실행 시 관리자 자격 증명을 요구하는 메시지가 사용자에게 나타납니다. 이 경우 UAC를 사용하는 상태에서 관리자로서 실행하는 것과 달리, runas 또는 psexec를 사용하는 경우와 마찬가지로 해당 응용 프로그램은 말 그대로 관리자가 시작한 사용자의 컨텍스트에서 실행됩니다. 따라서 해당 작업은 관리자의 컨텍스트에서 실행되나 상승된 권한으로 실행됩니다.

Windows Vista를 사용자로 실행하는 경우

필자는 개인적으로 Windows Vista를 UAC를 사용하는 상태에서 관리자로 실행하는 것보다 사용자로 실행하는 것을 선호합니다. 그 이유는 이 방법이 현재까지로는 일반 기업에 가장 적합하다고 여기기 때문입니다. 결과적으로 사용자는 시스템에 대한 모든 권한을 가지며 관리자는 맬웨어의 침입 기회를 줄일 수 있습니다.

뿐만 아니라 그룹 정책, 바이러스 백신, 맬웨어 방지 또는 기타 소프트웨어를 사용하여 사용자를 관리하는 동시에 이러한 작업의 실제 적용 또는 수행 여부를 중앙에서 제어하려는 경우 최종 사용자가 관리자가 아니도록 하는 것은 매우 중요한 절차입니다. 사용자가 관리자인 경우에는 사용자가 서비스 중지, 드라이버 추가 또는 제거를 비롯한 기타 작업을 수행할 수 있기 때문입니다. 물론 사용자 계정으로 실행하는 잔꾀가 많은 최종 사용자 중에는 Windows PE를 사용하여 몇몇 보안 장애물을 피할 수도 있습니다. BitLocker®를 사용하면 이러한 작업을 까다롭게 할 수는 있지만 물리적으로 액세스할 수 있는 최종 사용자가 충분한 시간과 정보를 갖고 노력하면 해당 컴퓨터에서 원하는 모든 작업을 수행할 수 있다는 사실을 유념해야 합니다.

Windows Vista를 사용자로 실행하는 것은 Windows XP를 사용자로 실행하는 것과 크게 다르지 않습니다. 필자는 PSExec, RunAs 등 Windows XP에서 사용한 것과 동일한 도구 및 UAC(현재 사용)를 사용하여 필요한 경우 관리자로서 작업을 실행합니다. 좋은 점은 Windows XP에서는 관리자 권한이 필요했던 상당히 많은 작업을 수행하는 데 더 이상 관리자 권한이 필요 없어졌다는 것입니다. 예를 들어 Windows Vista 사용자는 로컬 프린터를 설치할 수 있습니다. Windows XP의 경우 사용자는 네트워크 프린터를 설치할 수는 있었지만 로컬 프린터를 설치하려면 관리자 권한이 필요했습니다. Windows Vista에서는 사용자가 컴퓨터를 물리적으로 조작할 수 있고 드라이버 저장소에 프린터 드라이버가 있기만 하면 프린터 설치는 물론 인쇄 작업까지 관리할 수 있습니다. 자세한 내용은 go.microsoft.com/fwlink/?LinkId=111534를 참조하십시오. 참고로 Windows Server 2008에서는 이 기능을 사용할 수 없습니다.

물론 Windows XP에서 사용자로 실행할 때 나타나는 시계 기능이나 그 기능 부족을 놀림거리로 삼는 사용자도 있습니다. 이 시계가 두 번 클릭되는 경우 날짜를 보여 주는 방식으로 작동하도록 지정되었는지에 관계없이 사용자들은 때때로 날짜를 확인하기 위해 시계를 두 번 클릭하는 경우가 있으므로 사용자로 실행할 때 시계를 두 번 클릭해 보십시오. 이 경우 그림 6과 같은 오류 메시지가 표시됩니다. 그다지 우호적이지는 않은 메시지라 할 수 있겠지요. Windows XP에서는 사용자가 이와 같은 작업을 수행할 수 있도록 정책을 수정할 수 있었지만 Windows Vista에서는 원래 방식 그대로 작동하도록 변경되었습니다. 따라서 Windows Vista에서는 UAC를 사용하거나, 공식 사용자로 실행하거나, 다른 사용자로 권한을 상승하거나 하는 경우에 상관없이 사용자로 실행할 경우 Windos XP보다 훨씬 개선된 환경을 경험할 수 있습니다.

그림 6** Windows XP에서는 관리자가 아닌 사용자의 경우 시간을 변경할 수 없음 **(더 크게 보려면 이미지를 클릭하십시오.)

제한 사항에 유의할 것

사용자를 관리자가 아닌 사용자로 전환하는 것이 만병 통치약은 아니라는 점을 기억해 두십시오. 극성스러운 최종 사용자는 여전히 자신의 PC를 물리적으로 조작할 수 있으며 자신의 시스템을 악용하기 위한 작업을 꾸준히 수행할 수 있습니다. 특히 정책이나 사용자 권한으로 인해 작업을 완료하지 못하도록 저지당하는 경우 더욱 그럴 수 있습니다.

사용자가 관리자 계정으로 실행하는 경우에는 적용된 그룹 정책을 무시하기 위해 그다지 많은 작업을 수행할 필요가 없습니다. 물론 사용자도 조금 더 수고하면 Windows PE로 부팅하여 일반적으로 권한이 부여되지 않는 권한이 부여되도록 수정할 수 있습니다. 그러나 관리자가 BitLocker 또는 기타 드라이브/볼륨 암호화를 사용하면 이러한 작업이 불가능하거나 실행하기 매우 까다롭도록 할 수 있습니다.

아직 조직에서 최종 사용자들이 사용자로 실행하도록 전환하지 않은 경우 관리자가 할 수 있는 가장 중요한 일은 왜 관리자와 조직이 시간과 비용, 그리고 노력을 들여 조직의 사용자가 관리자로 실행하지 않도록 전환해야 하는지에 대해 제대로 파악하는 것입니다.

물론 기존의 익숙한 응용 프로그램을 버리는 것은 어려운 일입니다. 그러나 사용자 계정으로는 간단히 실행할 수 없는 응용 프로그램을 그대로 갖고 있는 것은 조직의 보안 유지 비용을 낭비하는 잘못된 생각일 뿐입니다. 따라서 해당 응용 프로그램을 가상화, 즉 말 그대로 가상 컴퓨터로 이동하는 방법을 고려해야 합니다. 이러한 가상 컴퓨터에서는 사용자가 관리자 권한을 가질 수 있습니다. 이렇게 하면 필요한 경우 해당 응용 프로그램을 사용할 수 있을 뿐만 아니라 관리자를 사용자로 전환함으로써 나머지 시스템을 안전하게 보호할 수 있습니다.

이번 칼럼의 전체 내용에서 필자는 "잠금" 또는 이 용어에서 파생된 단어를 사용하지 않았습니다. 관리자를 사용자로 전환하는 작업을 고려하는 상당수의 관리자 중 이 단어를 사용하여 설명하는 경우가 더러 있습니다. 아마도 필자의 주관적인 견해이거나 필자가 종사하고 있는 마케팅 분야에서만 그런 것인지 모르겠지만, 이러한 단어는 의미적인 수준에 불과할지라도 최종 사용자에게 권한을 박탈당한다는 느낌을 줄 수 있으므로 지양하는 편이 좋다고 생각합니다.

그 대신 조직에서 얻을 수 있는 보안상의 이점에 중점을 두어 설명하고, 사용자 계정으로 실행할 수 없는 특수 사용자의 경우나 관리자 권한이 필요한 특정 작업이 있는 경우와 같이 극단적인 경우에 대비할 수 있는 좋은 계획이 있음을 충분히 설명하십시오. Run.vbs 스크립트(technetmagazine.com/issues/2007/03/DesktopFiles에서 참조)와 같은 수동 해결 방법을 사용하든, 전환하는 데 도움이 되는 상용 솔루션을 사용(최종 사용자에게 세부 정보를 숨기고 작업을 "수행만" 함)하든지 간에 최대한 빨리 관리자가 아닌 계정으로 전환하는 것이 중요합니다. TechNet Magazine의 상시 기고가인 Aaron Margosis는 관리자가 아닌 사용자로 전환하는 작업을 적극적으로 지지하고 있습니다. Aaron Margosis의 블로그(blogs.msdn.com/aaron_margosis)를 아직 방문하지 않았다면 지금이라도 방문해 보십시오. 이 주제에 대한 깊이 있는 정보를 얻을 수 있는 최고의 리소스입니다.

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

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..