[액티브X 대체기술 1부] - 백조에서 미운오리로 전략한 액티브X의 문제와 해결방안

더 큰 세상으로 가는 문 액티브X 대체기술

 

기획/정리 l 전희용 기자 flytgr@imaso.co.kr

 

마소 독자치고 액티브X 문제와 무관하다고 할 수 있는 사람은 별로 없을 것이다. 그런데, 참 이상한 일은 액티브X 이야기만 나오면 문제의 원인이나 해결책을 이야기하기 보단 목에 핏대부터 세운다. 누군가를 탓하기 위함이다. 하지만 막상 따지고 보면 누구의 잘못이라고 하기는 어려운 일이다. 워낙 오랫동안 쌓아온 일이기 때문이다.
그렇다고 곪을 대로 곪은 상처를 그냥 놓아둘 수도 없는 일. 이번 달 특집에서는 이 상처의 원인에 대해 알아보고, 그 치료방법인 액티브X의 대체 기술들에 대해서도 함께 알아본다. 다들 잘 알다시피 아직 액티브X를 1대1로 대신해 줄 수 있는 기술은 없다. 하지만, 여러 기술들을 이용하여 산적한 문제들을 보완하며 차츰 치료해 나갈 수는 있을 것이다. 깊이 박힌 상처가 하루아침에 낫는 걸 보았는가?

 

1부 | 백조에서 미운오리로 전락한 액티브X 문제와 해결방안 | 정희용

2부 | 발등의 불끄기 공인인증서 대체기술 | 최상훈

3부 | UI 대체는 내게 맡겨라 Ajax를 이용한 UI 개발 | 박영록

4부 | 액티브X 뛰어넘는 기능과 호환성 XPCOM 개발전략 | 김민수

5부 | MS가 내놓은 액티브X의 대안 실버라이트 활용법 | 한용희

 

백조에서 미운오리로 전략한 액티브X의 문제와 해결방안

 

샌프란시스코에서 열리는 자바원 컨퍼런스 2007에서 자바의 아버지 제임스 고슬링을 만난 기자는 한국의 액티브X 문제에 대해 이야기하고, 조언을 구하고자 했다. 하지만 이는 생각보다 훨씬 어려운 일이었다. 한국의 사례가 워낙 독특한 탓에 짧은 영어실력으로는 도저히 우리의 상황조차 이해시키기 어려웠던 탓이다. 특집 1부에서는 우리가 맞게 된 액티브X 문제를 되돌아보고 그 해결 방안들을 찾아본다.

 

정희용 기자 | flytgr@imaso.co.kr

 

어느 날 부터인가 액티브X 문제가 여기저기서 터져 나오기 시작하더니, 이제는 일반인들조차도 이 문제에 관심을 가지는 상황이 되었다. 문제는 그렇게 열을 올리고 있으면서도 대체 왜 문제인지 잘 모르는 사람들도 있다는 데 있다. 심지어 그저 반MS 감정의 연장쯤으로 생각하는 사람들도 있기에 1부에서는 먼저 액티브X 문제가 불거지게 된 배경과 그 해결 방법으로 제시되는 기술들에 대해 알아볼 것이다.

 

 

액티브X 문제의 배경

 

 

마소 독자치고 IMF라는 말이 곱게 들리는 사람은 없을 것이다. 1990년대 말 우리나라는 외환위기를 겪으면서 경제적으로 큰 타격을 입었다. 외국에 빚을 많이 지게 된 우리나라는 부채를 갚기 위해 특단의 조치가 필요하였다. 우리나라의 신 성장 동력을 찾기 위해 국가가 발 벗고 나서야만 했다. 이때 선택한 국가 원동력 중에 하나가 바로 IT산업이다. 독자들 중에도 이때의 IT 붐에 편승하여 전공을 선택하거나 개발자가 된 사람도 있을 것이다. 이맘때쯤 전국적으로 초고속 인터넷망이 설치되면서 인터넷 붐이 일어났고, 모든 것은 인터넷으로 통했다. 바야흐로 전자상거래의 본격적인 태동이 시작된 것이다. 전자상거래를 이용하여 금융거래를 안전하게 할 수 있으려면 강력한 보안이 필수적이었다. 하지만 그 당시의 브라우저는 요즘처럼 강력한 128bit 암호화 기능을 자체적으로 제공하고 있지 않았다.

 

암호화 기술로 채택된 액티브X

 

결국 보안 기술을 따로 만들어야 했지만, 미국은 선뜻 128bit 암호화 기술을 내주지 않았다. 보안상의 이유로 128bit 암호화 기술은 수출 금지 품목이었기 때문이다. 이에 정보통신부 산하 기관인 KISA(한국정보보호진흥원)에서는 시드(Seed)라는 128bit 대칭키 블록 암호화 알고리즘을 개발하였고 이를 브라우저에 탑재하기 위하여 액티브X 컨트롤을 사용하였다. 이는 곧 국내 표준이 되었다. 금융감독원은 이 기술을 전자상거래를 위한 보안성 심의 기준으로 삼았으며, 결국 액티브X 컨트롤의 확산에 단단히 한 몫을 하게 되었다.

 

국제 표준이 되어버린 SSL

 

하지만 2000년대 이후 128bit 암호화 기술을 사용하는 SSL (Secure Sockets Layer)이 로열티를 지불하지 않는 국제표준으로 인정되면서 대부분의 브라우저에서 이 기술을 채택하게 되었다. 하지만 우리나라는 이미 액티브X를 이용하여 자체적으로 구현하고 있는 암호화 기술이 있었다. 애써 만들고 구축한 시스템은 쉽사리 SSL로 대체되지 않았다.

 

윈도우 비스타와 IE7의 등장

 

하지만 액티브X 기술이 가지고 있는 보안상의 문제점은 지속적으로 제기되어 왔고, 마이크로소프트(이하 MS)도 보안에 취약한 액티브X 컨트롤로 인하여 상당한 이미지의 타격을 입게 되었다. 결국 새로운 운영체제(Vista)와 새 브라우저(IE7)를 출시하면서 극단의 처방으로 액티브X 컨트롤에 대한 보안을 강화하기에 까지 이른 것이다. MS의 입장에서도 태생적으로 보안에 취약한 액티브X 컨트롤을 그대로 방치해 두기에는 보안에 취약한 운영체제라는 오명을 벗을 수 있는 길이 없었던 탓이다.

 

액티브X 사태 확산과 해결 노력

 

올해 초 비스타 출시에 맞춰 금융감독원에서는 비스타 호환성 이슈를 해결하지 못한 사이트는 보안상의 문제로 인하여 금융 거래를 할 수 없도록 막았다. 그제야 액티브X 컨트롤 사태가 전국적으로 이슈가 되기 시작했고 각 사이트들은 액티브X 컨트롤 문제를 해결하기 위하여 부랴부랴 대응 방안을 마련하고 대응 컨트롤을 제작하게 된 것이다.

하지만 이런 노력들은 장기적인 대안이 되질 않는다. 결국 비스타와 IE7 보안 기준에 맞춘 또 다른 액티브X 컨트롤을 만들고 있기 때문이다. 우리나라 웹사이트는 금융 거래를 하는 사이트 몇 개만 들락날락 거려도 수십 개의 액티브X 컨트롤이 설치된다. 각자 서로 다른 액티브X 컨트롤을 구축해서 사용하기 때문에 사용자 입장에서는 상당히 불편한 점 중에 하나이다.

 

정부의 자각

 

정부도 이러한 액티브X 사태를 겪으면서 이러한 문제가 다시 나타나지 않게 하기 위한 방안들을 모색 중이다. 그 시작은 신규 발주 사업의 제안 요청서에 특정 업체의 제품(기술)만 지원하지 않도록 웹 표준을 준수해 다양한 운영체제와 여러 브라우저에서 작동할 수 있도록 구현할 것을 명시한 것이다. 즉 이제는 액티브X 컨트롤처럼 한 가지 OS나 한 가지 브라우저에서만 작동하는 웹 사이트는 안 만들겠다는 뜻이다.

문제의 근본 원인

 

그렇다면 이와 같은 문제점의 근본적인 원인은 무엇일까? 그것은 바로 브라우저가 가진 기능의 한계에 있다. 초기의 브라우저는 단순히 정보를 표현하는 도구로 출발을 하였다. HTML 태그를 이용하여 정보를 만들고 이를 서로 링크로 연결하여 정보의 네트워크를 만들어 표현하는 것이 주목적이었다. 그러다 보니 브라우저라는 것은 결국 정보를 표현하는 것이 주된 목적이었던 것이다. 여기에 128bit 암호화 기술이나, 키보드 보안 기술은 고려 대상이 아니었다. 하지만 웹이 가진 네트워크라는 속성은 서로를 연결시켜주는 폭발적인 힘으로 작용하면서 전 세계가 웹 하나로 급속하게 연결 되었다.

이러한 발전은 웹이 더 이상 단순히 정보만 보여주는 도구가 아니라, 사용자가 정보를 스스로 생산해 내고 참여하게 만드는 새로운 네트워크 질서의 패러다임(웹2.0)으로 바뀌어 갔다. 그러다 보니 브라우저는 이제 그 능력의 한계를 드러내고 이 능력을 확장하기 위하여 액티브X 컨트롤과 같은 기술이 나타났던 것이다.

 

급속한 IT 성장의 부작용

 

지금까지 살펴본 일련의 과정을 정리하면 액티브X 문제를 거론하며 정부와 MS만을 탓할 수만은 없다는 걸 알 수 있을 것이다. 우리나라는 너무 일찍 태동한 전자상거래 탓에 남들보다 빠른 보안 기술을 개발하여 사용하게 되었고, 시간이 지난 뒤에 오래된 기술이 취약점을 드러냈다고 볼 수도 있는 탓이다.

해외 여러 나라와 달리 유독 우리나라에서만 액티브X 컨트롤 사태가 이슈화 되는 이유도 바로 그런 배경 때문이다. 이제는 잘잘못을 가릴 때가 아니라 지난 날 우리의 과오를 인정하고 새로운 대안들을 찾으면 될 일이다.

 

 

액티브X의 대체 기술들

 

 

액티브X의 대체 기술에 대해 이야기 하려면 먼저 세 가지로 나누어 생각해 봐야한다. 흔히, 공인인증서 문제에 대해서만 많이 보도되고 있지만, 개발자들에게 산적된 문제는 인증서에만 국한되지 않기 때문이다.

 

비스타에서의 액티브X 호환성 확보하기

 

그 중에서 가장 먼저 알아봐야 할 것은 발등에 떨어진 불을 어떻게 하면 끌 수 있을 지에 대한 것으로 임시방편이라고도 할 수 있겠다. MS는 비스타에 설치된 IE7에서의 액티브X 컨트롤 문제를 해결하기 위해 몇 가지 방법을 내놓았다. 뒤에 좀 더 자세히 알아보겠지만 먼저 간단히 정리해 보면 액티브X 컨트롤의 권한을 상승시키는 방법과 보호 모드의 예외 정책을 이용하는 방법 그리고 브로커를 이용하여 관리자 권한이 필요한 액티브X가 실행되도록 하는 것이다.

 

플랫폼 독립적인 공인인증서 만들기

 

두 번째로 검토해 봐야 할 문제는 특정 운영체제와 브라우저에서만 동작하는 액티브X를 대체하면서도 여러 플랫폼(운영체제와 브라우저)에서 실행될 수 있는 공인인증서이다. 몇 차례 보도를 통해 알려진 것처럼 현재 이런 문제의 해결을 위해 가장 큰 관심을 받고 있는 분야는 자바 기술이다. 애초에 한 번 만들어서 어디에서나 실행되도록 한다는 WORA(Write Once, Run Anywhere)에 입각해 만들어진 자바이기에 보다 다양한 운영체제와 브라우저에서 실행되는 인증서 컨트롤을 만들 수 있기 때문이다. 물론, 기존 액티브X 공인인증서를 완전히 대체할 수 있으려면 아직 해결해야 할 문제들이 산적해 있지만, 이미 사설 인증서를 만든 국내 업체도 있고 자바를 통해 공인인증서 서비스를 하고 있는 해외 사례들도 있어 가장 현실적인 방법으로 꼽히고 있다.

 

액티브X 대체 기술 확보

 

바로 이 부분이 이번 특집을 통해 주로 다뤄질 내용들이다. 언론을 통해 결제나 공인인증서 문제만 다뤄지다 보니 액티브X가 마치 그런 일에만 사용되는 것처럼 느껴질 정도다. 하지만, 실제로 액티브X가 사용되는 분야는 훨씬 많다. 이런 액티브X 애플리케이션을 대체하는 애플리케이션을 만들기 위해 사용할 수 있는 기술들이 있다. 바로 XPCOM과 Ajax, 실버라이트다. 이 내용들은 각각 특집 3, 4, 5부에서 자세히 다뤄진다.

 

 

윈도우 비스타 IE7의 액티브X 개발 방법

 

 

윈도우 비스타가 기존 윈도우와 가장 다른 점은 보안이 상당히 강화되었다는 점이다. 문제는 이 보안 강화가 기존 액티브X 컨트롤의 사용에 제약이 된다는 점이다. 특히, 윈도우 비스타에 IE7을 설치하여 사용할 때 기본으로 제공되는 UAC(User Account Control)와 보호모드(Protected Mode)가 문제다. 보안 기능 탓에 몇몇 웹 사이트에서 기존에 제공하고 있던 액티브X 컨트롤의 사용이 어려워졌고, 아직도 이 문제를 해결하지 못한 사이트도 있을 정도다. 이번에는 UAC와 보호모드에 대해 알아보고, MS에서 권고하고 있는 방법들을 기반으로, 윈도우 비스타 환경의 IE7에서도 실행되는 액티브X 컨트롤 개발 방법에 대해 알아보자.

 

UAC란?

 

UAC란 User Account Control의 약자로 사용자 계정을 제어하는 기능이다. 그럼, 왜 이런 기능이 만들어졌고 대체 무엇 때문에 이 기능이 문제시 되는 것일까?

기존 윈도우의 사용자들은 윈도우를 설치하고 나면 관리자 권한으로 등록하여 모든 기능들을 자유롭게 사용하였다. 하지만, 이런 사용자 패턴이 보안에 치명적인 문제를 일으킬 수도 있기 때문에, 비스타에서는 사용자가 관리자 그룹에 속해 있더라도 자동으로 관리자 권한을 사용할 수 없도록 막고 있다. 대체 이게 무슨 소리일까? 윈도우XP와 비교하며 좀 더 자세히 살펴보자.

윈도우XP에도 나름의 보안 개념은 있었다. 그래서 일반 사용자 권한으로는 응용프로그램의 설치나 시스템의 시계 설정, 네트워크나 프린터 설정 등을 변경하지 못하도록 제한하고 있었다. 그러나 기자를 포함하여 보안 의식이 낮은 사용자들에게 애플리케이션을 설치하거나 설정을 변경할 때마다 관리자 권한으로 다시 로그인 하는 것은 무척 귀찮은 일이었다. 그래서 그냥 관리자 권한을 기본 계정으로 사용해 왔던 것이다. 관리자 권한으로 사용하고 있으니 여기에 그레이웨어나 해킹 프로그램 등이 접속하면 시스템을 통째로 들었다 놨다 할 수 있는 상황이 자주 벌어진 것이다.

비스타에서는 바로 이런 문제를 원천적으로 봉쇄하기 위해 기본적으로는 관리자 계정을 비활성화 시켜서 사용할 수 없도록 만들어 버린 것이다. 아무리 관리자 그룹에 속해있는 사용자라도 보통 때에는 표준 사용자 권한으로 사용해야 한다. 그리고 관리자 권한이 필요할 때에는 사용자의 동의를 얻거나 관리자 계정 정보를 입력하여 관리자 권한을 일시적으로 획득하여 사용하도록 만들어진 기능이다.

여기에 추가로 사용자가 생성한 프로세스는 시스템 영역의 데이터를 건드릴 수도 없고 오직 사용자 계정 폴더에만 데이터를 쓰거나 수정할 수 있다. 레지스트리 기록도 마찬가지다. HKEY_CURRENT_USER 이외의 시스템에는 접근이 제한된다. 적절한 사전 작업 없이는 Win32 API의 호출도 불가능하다.

 

권한 상승과 가상화

 

이러한 UAC 기능 탓에 기존에 만들어 둔 액티브X 컨트롤이 재 기능을 하지 못한다면 권한 상승(Elevation)이나 가상화(Virtualization)를 활용해 볼 수 있다. 그 밖에도 몇 가지 방법이 더 있지만 여기에서는 이 두 가지 방법에 대해서만 간단히 알아본다.

 

● 권한 상승

앞서도 이야기한 것처럼 윈도우 비스타에서는 기본적으로 표준 사용자 계정을 사용하도록 되어 있고, 관리자 권한이 필요한 경우 권한 상승 과정을 거쳐야 한다. 여기에서 말하는 권한 상승 과정이란 사용자가 관리자 권한을 가지고 있는지 인증하는 것을 말하는데, 상황에 따라 두 가지 창이 표시되어 인증을 하도록 되어있다. 그중 하나는 사용자가 관리자 그룹의 계정으로 사용하고 있는 경우인데, 이때에는 사용자 동의 창이 표시되어 관리자 권한이 필요한 프로그램을 실행시킬 것인지 묻는다. 만약, 사용자가 일반 사용자 그룹에 속한 계정을 사용하고 있다면 관리자 계정 정보 입력을 요구하는 창이 표시된다.

그런데, 권한이 상승되는 방법이 몇 가지 더 있다. 윈도우 비스타에서 권한이 상승되는 경우는 다음의 네 가지다.

• 사용자가 직접 권한 상승할 때 (관리자 권한으로 실행)
• 프로그램 호환성 탭에 관리자 권한으로 실행하도록 설정된 경우
• 설치 프로그램을 실행할 때
• 관리자 권한으로 마킹된 실행 파일을 실행할 때

여기에서 눈여겨봐야 할 부분은 마지막에 있는 관리자 권한으로 마킹된 실행 파일을 실행할 때 자동으로 권한이 상등된다는 부분이다. 애플리케이션의 매니페스트(manifast)에 높은 레벨(관리자 권한)을 설정하면 자동으로 권한 상승이 일어나기 때문이다.

이 방법을 사용하면 액티브X 컨트롤이 윈도우 비스타의 IE7에서 실행되도록 할 수 있다. 윈도우 XP에서의 매니페스트는 DLL이나 COM 객체들의 의존성을 정의하는 용도로 사용되었지만, 비스타에서는 애플리케이션의 실행 권한을 명시하는 용도가 추가되었다. 매니페스트에 마킹하여 권한을 상승시키는 방법과 예제는 http://www.microsoft.com/korea/windows/ie/ ie7/technology/default.mspx에 있는 ‘Windows Vista 상에서 ActiveX Control 개발 방법’을 참고하길 바란다.

 

● 가상화

MS에서 임시방편으로 제공해 주고 있는 UAC 해결 방법이 하나 더 있다. 바로 가상화를 이용하는 방법이다. 가상화는 다시 파일 가상화와 레지스트리 가상화로 나눠진다.

이중에서 파일 가상화는 애플리케이션이 파일을 시스템 폴더에 저장할 때 발생하는 문제를 해결하기 위해 사용되는 기술이며, 레지스트리 가상화는 HKEY_LOCAL_MACHINE\SOFTW ARE 아래의 레지스트리 키에 사용할 수 있다. 이 위치에 설정 정보를 저장해야 할 경우 레지스트리 가상화 기능을 이용하여 실제 키를 HKU\{SID}_Classes\VirtualStore\Machine\Software로 리디렉션하여 사용하는 것이다. 마찬가지로 파일 가상화도 시스템 폴더 대신 사용자별 가상 경로에 파일을 저장하도록 해 준다.

그런데 주의할 점은 이 기술이 계속 지원되지는 않는다는 점이다. 그렇기 때문에 기존에 만들어 놓은 액티브X의 호환성 문제를 일시적으로 해결하기 위한 용도로만 사용해야 한다.

 

IE7의 보호모드와 예외정책

 

윈도우 비스타에 설치된 IE7에서만 동작하는 보호모드는 모든 프로세스와 보안 객체에 저마다의 접근 수준을 지정하여 접근 수준이 낮은 객체가 그보다 높은 수준의 데이터를 기록하지 못하도록 한다. 접근 수준은 각각 높음과 보통, 낮음으로 나뉘는데 윈도우 비스타에서의 IE7은 기본적으로 ‘낮음’으로 실행되기 때문에 ‘높음’이나 ‘보통’ 수준의 시스템 자원에 접근하는 것이 불가능하다. 이 문제는 브로커를 이용하여 접근수준을 높이는 방법으로 해결할 수 있다. 참고 자료에 링크되어 있는 ‘Windows Vista 상에서 ActiveX Control 개발 방법’에는 이와 관련된 정보와 예제들이 자세히 설명되어 있으니 참고하길 바란다.

 

출처명 : 한국마이크로소프트 [2007년 6월호]