Windows Administration

Windows Vista의 ActiveX Installer 서비스

Rob Campbell and Joel Yoker

한 눈에 보기:

• ActiveX 컨트롤 관련 공통 과제
• ActiveX 컨트롤이 설치되는 경로
• 위험한 권한
• Windows Vista의 안전한 프로세스

언제나 같은 이야기를 드리게 되지만 근본적으로 보안을 강화하려면 자유롭고 유동적인 컴퓨터 작업 환경은 어느 정도 포기해야 합니다. 여러분의 환경이 다른 대부분의 조직과 마찬가지라면 데스크톱 운영 체제를 견고히 하여 최종 사용자에게 보다 안전한 컴퓨팅 환경을 제공하고자

하는 바람이 가장 클 것입니다. IT 관리자는 일반적으로 여러 가지 보안 정책 설정, 사용자 권한, 파일 및 레지스트리 ACL(액세스 제어 목록), 시스템 서비스 제한을 사용하여 데스크톱 보안 작업을 수행합니다.

보안이 유지된 데스크톱 환경을 개발할 경우 흔히 걸림돌이 되는 사항 중 하나는 어떻게 하면 사용자의 환경에 알맞은 수준의 응용 프로그램 호환성을 제공하면서 악성 ActiveX® 컨트롤의 위협을 방지할 수 있느냐 하는 문제입니다. 이는 데스크톱 운영 체제와 관련하여 수년 동안 겪고 있는 문제였습니다. 이제 다행히도 Windows Vista™의 새로운 AxIS(ActiveX 컨트롤 Installer 서비스)를 통해 기업 환경에서 ActiveX 컨트롤 관리와 관련된 문제를 해결할 수 있게 되었습니다. AxIS에서는 일반적으로 ActiveX 컨트롤을 설치할 권한이 없는 표준 사용자가 승인된 웹 사이트의 ActiveX 컨트롤을 설치할 수 있는 간단하고 관리하기 용이한 방법을 제공합니다. IT 관리자는 AxIS를 통해 그룹 정책을 제어하여 사용자가 보유한 권한에 상관없이 설치할 수 있는 ActiveX 컨트롤을 결정할 수 있습니다.

이 기사에서는 ActiveX 컨트롤을 관리하는 데 따르는 어려움과 이러한 문제를 이전 버전의 Windows®에서는 어떤 방식으로 해결했는지 살펴보고, Windows Vista의 AxIS에서는 ActiveX 컨트롤 설치를 효율적으로 관리할 수 있는 독특한 방법을 어떤 방식으로 제공하는지 살펴보겠습니다.

ActiveX 컨트롤이란?

ActiveX 컨트롤은 일반적으로 캐비닛 파일 안에 패키지되어 있는 OCX 파일인 실행 코드 조각을 말하며, Internet Explorer®를 통해 사용자에 의해 설치되고 호출됩니다. 표준 HTML이나 간단한 스크립트로는 웹 응용 프로그램에 기능을 추가하기가 쉽지 않으므로 웹 개발자들은 이를 보완하기 위해 ActiveX 컨트롤을 작성합니다.

ActiveX 컨트롤의 주요 특징은 간단한 "다운로드 및 실행" 배포 모델입니다. ActiveX 컨트롤은 HTML object 태그를 통해 설치 및 호출됩니다. HTML object 태그에는 CODEBASE라는 특성이 있으므로 ActiveX 컨트롤이 아직 사용자 컴퓨터에 설치되어 있지 않은 경우 URL을 사용하여 해당 컨트롤을 다운로드할 수 있는 위치를 Internet Explorer에 알려 줍니다. 그러면 Internet Explorer에서 관련 설치 패키지를 다운로드하고, 해당 개체에 대한 신뢰 확인 작업을 수행한 다음, Internet Explorer 알림 표시줄을 통해 사용자에게 설치 허용 여부를 묻는 메시지를 표시합니다(그림 1 참조). 설치 과정에서 해당 컨트롤은 렌더링 페이지에 의해 등록되고 호출됩니다. 설치가 완료되면 모든 표준 사용자가 해당 컨트롤을 호출할 수 있습니다. 이처럼 간단한 배포 및 실행 메커니즘을 통해 개발자들은 웹 응용 프로그램 사용자에게 해당 구성 요소를 손쉽게 배포할 수 있습니다. 이러한 배포 방식이 지닌 문제는 ActiveX 컨트롤 설치를 완료하려면 관리자 권한이 필요하므로 표준 사용자는 ActiveX 컨트롤을 직접 설치할 수 없다는 점입니다.

그림 1** ActiveX 컨트롤 설치 알림 표시줄 **

ActiveX 컨트롤이 Internet Explorer 4.0에 처음 도입되었을 당시의 인터넷은 훨씬 우호적인 환경으로 보였습니다. 그러나 오늘날 웹을 통해 배포되는 실행 코드는 심각한 위협이 될 수 있으므로 Windows에서는 로컬 관리자 권한을 가진 사용자만 ActiveX 컨트롤을 설치할 수 있도록 허용하여 정책 설정에 따라 승인된 설치만 수행되도록 합니다. 관리자가 ActiveX 컨트롤 설치를 완료하면 시스템의 모든 사용자는 해당 컨트롤을 호출할 수 있습니다. Windows의 파일 및 레지스트리 ACL 모음을 통해 이러한 동작을 더 쉽게 수행할 수 있습니다. 이렇게 하면 표준 사용자가 ActiveX 컨트롤을 설치하는 것을 방지할 수 있지만 ActiveX 컨트롤을 설치하는 로컬 관리자 및 수정된 기본 사용 권한을 가진 표준 사용자로 인해 발생하는 위험은 방지할 수 없습니다.

Windows에서 관리자 권한을 가진 경우에만 설치 작업을 수행하도록 허용하는 기본 보호 기능을 사용하면 개인 수준에서는 ActiveX 컨트롤 문제를 해결할 수 있지만, 해당 ActiveX 컨트롤을 대규모 조직 전체에 걸쳐 관리하는 문제는 해결할 수 없습니다. 일반적으로 기업 환경에서 겪고 있는 문제는 신뢰할 수 없는 외부 컨트롤을 통해 전달될 수 있는 위협을 방지하면서 IT 조직에서 신뢰하는 ActiveX 컨트롤에 대한 사용을 어떻게 허용하느냐는 점입니다. 결국 개인 사용자가 갖고 있는 권한에 따라 특정 ActiveX 컨트롤이 좋든 나쁘든지 간에 해당 컨트롤의 설치 여부를 결정해야 하는 경우가 종종 있습니다. 위협에 대응하기 위해 어떤 조직에서는 모든 ActiveX 컨트롤을 차단하는 반면, 다른 조직에서는 최종 사용자의 설치는 허용하되 설치된 모든 맬웨어를 관리하는 방식을 사용하기도 합니다.

악성 컨트롤의 설치를 방지할 수 있는 또 다른 방법은 표준 사용자의 제한된 권한을 사용하도록 적용하고, 필요한 모든 컨트롤은 IT 관리자가 데스크톱 플랫폼에 미리 설치해 두는 것입니다. 이 방법은 사용하고 있는 ActiveX 컨트롤의 특성이 비교적 정적이거나, 데스크톱 업데이트와 함께 예정된 릴리스 프로세스를 사용하여 수정되었거나, 조직에서 Systems Management Server와 같은 소프트웨어 배포 메커니즘을 사용하고 있는 경우 효과적입니다. 그러나 지속적인 관리, 내부 응용 프로그램 개발자의 지속적인 변경 요구, 외부 컨트롤에 대한 종속성과 관련된 문제의 경우 이 방법으로는 효과를 보기 어렵습니다.

만약 사용자가 관리자 권한을 갖고 있다면 문제가 달라집니다. 이 경우에는 이러한 사용자가 승인되지 않은 컨트롤을 설치하지 못하도록 해야 합니다. 이 경우 사용자가 관리자 권한을 갖고 있으므로 최종 사용자에게 ActiveX 컨트롤을 설치할 수 있는 권한이 있을 수 있습니다. 최종 사용자가 로컬 관리자로 실행되도록 하면 조직에 커다란 위험 요소가 될 수 있으므로 대부분의 기업 환경에서는 이를 방지해야 합니다.

한 가지 방법은 승인된 컨트롤을 호스팅하는 내부 인터넷 구성 요소 다운로드 서버를 구현하는 것입니다. 이 방법을 사용하려면 클라이언트 레지스트리의 CodeBaseSearchPath 문자열을 수정해야 합니다. 일반적으로 요청된 HTML 페이지에 CODEBASE 특성이 포함된 개체 태그가 있으면 CodeBaseSearchPath 데이터에 지정된 위치로 Windows 클라이언트가 이동됩니다. 기본적으로 이 레지스트리 문자열에는 ActiveX 컨트롤 갤러리에 대한 인터넷 URL 및 CODEBASE 키워드가 포함되어 있습니다. 인터넷 구성 요소 다운로드 서버를 구현하려면 CodeBaseSearchPath의 기본 데이터를 조직에서 승인된 컨트롤을 호스팅할 내부 서버의 URL로 바꾸어야 합니다. 앞서 언급했던 방법과 마찬가지로, 이 방법을 사용하는 경우에도 지속적인 관리가 필요하며 많은 비용이 소요되고 ActiveX 컨트롤의 내부 서버를 호스팅하기가 복잡하다는 문제가 있습니다.

이외에도 Internet Explorer 영역 URLAction 수정, 그룹 정책을 통한 관리자 승인 컨트롤 지정, 방화벽 규칙에 의한 경계에서 모든 컨트롤 설치 차단과 같은 기타 방법들이 있습니다. 그러나 앞서 살펴보았듯이 이러한 모든 방법에는 각기 문제점이 있으며 대부분의 경우 유연성이 떨어지므로 결국 사용되지 않고 있습니다. 더욱 문제가 되는 것은 이러한 일부 방법의 경우 사용자에게 관리자 권한을 요구한다는 점입니다. 결국 이러한 수정 방법에서는 ActiveX 컨트롤이 들어오는 곳이나 호출되는 곳을 제어 또는 차단하는 등의 방법을 통해 일부 문제를 해결하고자 하지만, 관리자 권한을 갖지 않은 사용자의 경우 ActiveX 컨트롤을 설치할 수 없다는 근본적인 문제는 해결하지 않습니다.

AxIS의 장점은 무엇입니까?

기업 관리자의 경우 Windows Vista의 AxIS를 사용하면 사용자가 기본 파일 시스템 설정을 사용하는 표준 사용자로 실행되므로 강력한 보안 환경을 유지하는 동시에 ActiveX 컨트롤을 관리할 수 있습니다. AxIS에서는 ActiveX 컨트롤의 신뢰할 수 있는 소스를 구성할 수 있는 그룹 정책 옵션을 제공하며 표준 사용자를 대신하여 이렇게 구성된 신뢰할 수 있는 소스의 컨트롤을 설치할 수 있는 중개 프로세스를 지원합니다. 가장 핵심적인 이점은 중앙 집중식 관리 제어를 통해 사용자 워크스테이션에서 관리자가 아닌 사용자의 보안 환경을 유지 관리할 수 있다는 점입니다. AxIS는 IT 관리자가 확인한 ActiveX 컨트롤의 신뢰할 수 있는 소스(일반적으로 인터넷 또는 인트라넷 URL)에 따라 작업을 수행합니다. 개체 태그가 Internet Explorer에 컨트롤을 호출하도록 지시하면 AxIS에서는 다음 단계를 수행합니다.

1. 컨트롤이 설치되어 있는지 확인합니다. 설치되어 있지 않으면 사용하기 전에 먼저 설치해야 합니다.
2. AxIS 정책 설정을 검토하여 컨트롤이 신뢰할 수 있는 소스의 컨트롤인지 확인합니다. 여기에서는 개체 태그의 CODEBASE 특성에 지정된 URL 호스트 이름을 정책에 지정된 신뢰할 수 있는 위치 목록과 비교합니다.
3. 사용자 대신 컨트롤을 다운로드하고 설치합니다.

AxIS 정책 설정 목록에 소스 URL의 호스트 이름이 없는 경우 설치를 완료하려면 관리자 권한이 필요하다는 내용의 일반 UAC(사용자 계정 컨트롤) 관련 메시지가 호출됩니다. 또한 AxIS에서는 응용 프로그램 이벤트 로그에 원본 AxInstallService에서 발생한 ID가 4097인 이벤트를 기록하여 시도된 ActiveX 컨트롤 설치에 대한 개괄적인 내용을 특정 컨트롤 다운로드 경로와 함께 표시합니다. 4097 이벤트에 대한 예는 그림 2에 표시되어 있습니다. 기업 관리자는 이 이벤트 로그 항목의 데이터를 참조하여 추후에 해당 웹 사이트를 방문할 경우 AxIS에서 컨트롤을 설치할 수 있도록 그룹 정책을 수정할 수 있습니다.

그림 2** 4097 AxInstallService 이벤트 **

AxIS는 Windows Vista Business, Enterprise 및 Ultimate SKU에서 제공되는 선택적 구성 요소이며, 무인 옵션 또는 그림 3에서와 같이 제어판 대화 상자(프로그램 | 프로그램 및 기능 | Windows 사용/사용 안 함)에서 사용하도록 설정할 수 있습니다. AxIS를 사용하도록 설정하면 Internet Explorer에서 컨트롤을 요청할 때마다 앞서 설명한 단계에 따라 작업을 수행합니다.

그림 3** 제어판에서 AxIS 설정 **

관리자의 경우 Windows Vista에서 이벤트에 작업을 연결하는 기능을 사용하면 ActiveX 컨트롤 설치가 차단된 경우 AxIS 서비스를 통해 알림을 쉽게 받을 수 있습니다. ActiveX 컨트롤이 최종 사용자가 웹 사이트에서 액세스하는 URL 호스트 이름에서 설치되지 않을 수도 있다는 점을 반드시 유의해야 합니다. 따라서 설치를 위해 컨트롤을 가져올 호스트를 확인하는 데 AxInstallService 4097(시도된 설치) 이벤트에서 제공하는 정보가 매우 유용할 수 있습니다.

이벤트에서 얻은 정보로 그룹 정책에서 신뢰할 수 있는 위치를 구성할 수 있습니다. 로컬 또는 그룹 정책의 AxIS 설정은 Computer Configuration(컴퓨터 구성) 설정에서 확인할 수 있습니다(그림 4 참조). Approved Installation Sites for ActiveX Controls(ActiveX 컨트롤용 승인된 설치 사이트) 정책 설정을 사용하면 신뢰할 수 있는 위치의 호스트 URL을 지정할 수 있습니다(그림 5 참조). 승인된 사이트를 설정하려면 설치를 위해 ActiveX 컨트롤을 가져올 호스트 위치 및 설치 동작의 두 가지 정보가 필요합니다.

그림 4** 그룹 정책 개체 편집기의 설정 **

그림 5** AxIS에서 승인된 설치 사이트 **

앞서 언급한 바와 같이, 컨트롤의 신뢰할 수 있는 위치를 나타내려면 우선 호스트 URL을 지정해야 합니다. 개발자가 컨트롤을 수정하는 경우 자주 변경되는 컨트롤의 CLSID를 알고 있어야 했던 이전 솔루션과는 달리, AxIS를 사용하면 전반적인 관리 작업 부담은 줄이면서 신뢰할 수 있는 위치의 모든 컨트롤을 설치할 수 있습니다. 두 번째로는 각각 ActiveX 컨트롤 다운로드 환경에 대한 동작을 지시하는 네 가지 값이 쉼표로 구분된 문자열 정보를 지정해야 합니다. 이러한 값은 TPSSignedControl, SignedControl, UnsignedControl, ServerCertificatePolicy의 네 가지 속성을 지정합니다. 처음 두 가지 속성(TPSSignedControl, SignedControl)은 0, 1 또는 2의 세 값 중 하나로 설정할 수 있으며 이러한 값은 URLAction 설정의 값과 비슷합니다. 값 0은 컨트롤이 설치되는 것을 방지하며, 값 1은 사용자에게 설치 허용 여부 메시지를 표시하고, 값 2는 사용자의 개입 없이 자동으로 컨트롤이 설치되도록 합니다. 서명되지 않은 컨트롤은 자동으로 설치할 수 없으므로 UnsignedControl 값은 0 또는 1로만 설정할 수 있습니다. 정책을 모두 지정하지 않으면 기본값인 2, 1, 0이 사용됩니다.

마지막 속성은 서명된 설정 컨트롤의 인증서 설정에 따라 설치 동작을 지정합니다. 대부분의 SSL 사이트와 마찬가지로 인증서는 그 유효성을 확인하기 위해 일련의 보안 테스트를 거쳐야 합니다. 유효하지 않은 인증서 속성은 실제로 서명된 ActiveX 컨트롤의 구현인 경우가 있습니다. AxIS의 구성을 사용하면 관리자는 URL별로 인증서에 의해 표시되는 유효하지 않은 정보에 대처할 수 있습니다. 마지막 속성은 그림 6과 같이 비트 마스크 값의 조합으로 나타납니다.

Figure 6 ServerCertificatePolicy

기본 설정인 0은 모든 보안 검사를 통과해야 AxIS에서 설치를 완료한다는 것을 의미합니다. 그림 7에서 호스트 설정의 조합 및 정책 설정에 지정된 네 가지 값을 확인할 수 있습니다.

그림 7** 승인된 AxIS 호스트 URL **

결론

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

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

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

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