스마트 클라이언트 배포하기 - 2   저 자 : 정성태

강력한 이름 서명 이 제에 대한 사항은 끝마쳤고, 서버 측 코드로 넘어가 보자. 여러분은 자신이 만든 컨트롤에 대해서 ‘강력한 이름 서명’을 해서 배포하기를 원할 것이다. 기존 독립 애플리케이션만을 만들어 본 독자라면 우선 AssemblyKey 특성만을 지정하여 SNK 파일과 연결할 텐데, 스마트 클라이언트에서는 그것만으로는 부족하다. 스마트 클라이언트에서는 ‘강력한 이름 서명’이 된 어셈블리의 경우 다음과 같이 반드시 AllowPartiallyTrustedCallers(이하, APTC) 특성을 포함시켜야만 한다. [assembly: AllowPartiallyTrustedCallers] [assembly: AssemblyKeyFile(“rich.snk”)] 우 선 동작 결과만을 놓고 본다면 APTC 특성을 제외시키는 경우 정상적인 활성화가 이루어지지 않는다. 원래 ‘강력한 이름 서명’이 된 어셈블리의 경우 ‘부분 신뢰를 받고 있는 어셈블리’에 의한 호출이 원칙적으로 허용되지 않는다. 이 규칙은 상식적으로 생각해 보면 쉽게 이해된다. ‘강력한 이름 서명’이 된 어셈블리라면 분명한 자격 증명을 가진 것이고 구현된 동작 역시 중요한 역할을 한다고 볼 수 있다. 그러한 어셈블리를 신뢰할 수 없는 또 다른 어셈블리가 자유롭게 인스턴스화해서 호출한다는 것은 분명 문제가 아닐 수 없다. 예를 든다면, 시스템에 중요한 기능을 하는 ‘DxType’이라는 어셈블리가 있다고 가정하자. 이 경우 어느 사이트에 방문해서 다운받아 실행한 ‘AttackType’이라는 어셈블리가 ‘DxType’을 생성해서 실행할 텐데 이런 경우는 절대 있어선 안된다(사실 그 동안은 그것이 자연스러웠다). 닷넷 환경에서는 그러한 접근까지도 막겠다는 것인데 개발자로서는 번거롭겠지만 찬성할만 한 개념이다. APTC 특성으로 인해 주의해야 할 사항이 몇 가지 있다. 첫 번째로 독립 애플리케이션에서 제공되는 ‘강력한 이름 서명’된 어셈블리에 APTC 특성을 설정하는 것은 위험하니 특별한 사유가 아니라면 아예 쓰지 말라는 것이고, 두 번째는 그 어셈블리가 GAC에 등록될지의 여부에 따라 더욱 더 코드에 대한 주의를 기울여야 한다는 것이다. 현실적으로 스마트 클라이언트에 APTC 특성을 사용한다고 해도 외부 어셈블리에서 스마트 클라이언트 DLL에 있는 타입을 생성하는 것은 거의 불가능하다. 그런데 독립 애플리케이션에서 GAC에 등록되는 어셈블리라면 사정이 달라진다. 그런 경우 외부 프로그램에서 자유롭게 타입을 생성할 수 있으므로 APTC 특성을 명시했다는 것은 모든 어셈블리로 하여금 접근을 허용하도록 한다고 볼 수 있기 때문이다. 애플리케이션 설정 파일 배포로 인해 발생하는 또 하나의 고민은 애플리케이션 설정 파일의 위치 문제이다. 이 위치에 대한 문제 해결은 ‘네트워크 모니터’ 등의 툴을 통해 쉽게 알 수 있다. 우선 TreeControl.cs 파일의 TreeCon trol_Load 이벤트 핸들러에서 다음과 같은 코드를 넣어보자. AppSettingsReader reader = new AppSettingsReader(); bool bDebugEnable = (bool)reader.GetValue( “DebugEnable”, typeof( bool ) ); 이제 컴파일을 하고, DLL 파일을 웹에 배포한 후 웹 폼 페이지를 IE를 이용해 방문하고 그 사이 오고가는 네트워크 패킷을 ‘네트워크 모니터’를 통해 살펴보자. 그럼 다음과 같은 유형의 GET 패킷을 볼 수 있다. GET /IEXPLORE.EXE.config HTTP/1.1 Connection: Keep-Alive Host: 192.168.100.19 위치를 알았으니 웹 사이트의 루트 폴더에 IExplore.exe.config 파일을 생성하고 다음과 같이 내용을 넣어두자. <?xml version=”1.0” encoding=”utf-8” ?> <configuration> <appSettings> <add key=”DebugEnable” value=”True” /> </appSettings> </configuration> AppSettingsReader 클래스로 앞의 Config 파일에 담긴 설정을 액세스할 수 있다. /iexplorer.exe.config의 이름과 경로에서 알 수 있듯이 여러 개의 스마트 클라이언트 DLL이 있다고 해도 각각에 대한 설정 파일을 나눌 수 없고 오직 루트 경로에 있는 IEXPLORE.EXE. config 파일을 공유해야 한다. 아울러 여기서도 IEHost.dll의 이해할 수 없는 현상이 하나 있는데, 네트워크 모니터를 주의깊게 살펴 본 독자라면 알겠지만 IExplorer.exe.config에 대한 GET 호출이 연이어 두 번 발생해서 똑같은 내용의 파일이 전송되는 것을 확인할 수 있다. 클라이언트 보안 설정 자동화 일 단 이 정도로 배포에 관한 HTML과 컨트롤 측의 코드에 대해서 알아보는 것은 끝난 것 같다. 이제 1~2회 연재에서 수작업으로 기본 설정하고 넘어갔던 스마트 클라이언트의 동작에 필요한 보안 설정에 관해 살펴보자. 여러분은 지금까지 만들었던 액티브X 컨트롤을 생각해 볼 때, 그와 동일한 기능의 스마트 클라이언트를 만들고자 한다면 대개의 경우 기본 ‘Internet’ 권한 집합에서 제공하는 권한 목록 이외의 것들을 필요로 하게 된다는 것을 알게 될 것이다. 그런 경우에 사용자로 하여금 직접 권한 설정을 하도록 유도하는 것이 현실적으로 어려운 일이라는 것을 이미 알고 있을 것이다. 여기서 스마트 클라이언트에 대한 한 가지 ‘아이러니컬’한 상황이 발생하게 된다. 필자는 첫 회에서 액티브X 컨트롤은 클라이언트에 대해서 무제한적인 액세스가 가능하다는 문제를 지적했다. 그래서 가능한 액티브X를 자제하고 이후부터는 제한된 보안 환경 속에서 닷넷 스마트 클라이언트를 써야 한다고 얘기했다. 그런데 ‘보안 설정’에 와서는 어쩔 수 없이 다시 액티브X의 힘을 빌려야 하는 상황으로 오게 된다. 보안 설정을 추가하기 위해서는 그러한 권한을 가진 어셈블리만이 가능할 것이고, 스마트 클라이언트 어셈블리는 기본 ‘Internet’ 권한 집합만 가지고 있기 때문에, 스스로 자신에 대한 보안 사항을 허용할 수 없으며 또한 보안 설정을 전담하는 스마트 클라이언트조차도 불가능한 시나리오일 뿐이다. 중요한 것은 최초의 ‘신뢰받은’ 모듈이 ‘스마트 클라이언트’를 위한 보안 설정을 반드시 해 줘야만 하는데, 지금의 윈도우 환경에서 ‘신뢰받는’ 모듈에 대한 선택으로 취할 수 있는 현실적인 방안은 ‘액티브X’ 뿐이다. 조금 덜 현실적인 방법도 몇 가지가 있다. 예를 들어, 보안 설정을 해 주는 닷넷 독립 실행 파일을 만들어서 사용자로 하여금 다운받게 하고 직접 실행해 주는 것도 방법이다. 그렇게 사용자로 하여금 단계를 더 거치도록 하는 것을 웹 사이트 운영자 입장에서는 원하지 않을 것이다. 사실 사용자들이 그런 단계를 싫어하기 때문에 운영자 역시 원하지 않게 된다. 사용자들은 모든 것이 ‘원클릭’ 방식으로 이루어지기를 바라고 가능하면 어떠한 질문도, 어떠한 팝업도 뜨는 것을 원치 않는다. 그렇기 때문에 결국 현실적인 방안으로 인증서를 포함한 액티브X가 실행돼 단지 ‘확인’ 버튼만 눌러주면 보안 설정이 끝나도록 개발돼야만 하는 것이다. 그러니 결국 다시 ‘액티브X’로 돌아온 것이다. 물론, 이전 상황과는 많이 다르다. 단지 설정하는 것에만 액티브X를 사용할 뿐 나머지 모든 컨트롤에 대해서는 닷넷 스마트 클라이언트로 제작될 것이므로 생산성 측면에서는 여전히 우위를 차지하게 된다. 그리고 다를 수 있는 점이 하나 더 있다. 고급 사용자를 위한 ‘보안 설정’ 방법을 설명하는 도움말을 해당 웹 사이트에 올려 놓는다면, 사용자들은 한결 마음 편하게 액티브X를 설치할 수 있을 것이다. 즉 해당 액티브X는 공개한 ‘보안 설정’ 이외의 것은 아무것도 하지 않는다는 무언의 약속을 사용자들에게 보장해 준다. 그런 선택이 주어진다면 내려받는 액티브X 컨트롤에 대해서 사용자들은 이전보다 훨씬 신뢰할 수 있을 것이다. 보안 설정 방법 이 미 보안에 관계됐던 APTC 특성을 살펴보면서 느끼는 거지만, 보안은 역시 어려운 것으로 다가온다. 사실 들춰보면 그다지 어렵지 않지만 그동안 배워 온 다른 것보다 상대적인 기준으로 어렵기 때문에 다가서는 것이 가장 마지막 단계로 밀려나기 마련이다. 필자도 아직 닷넷 프레임워크에서 제공되는 ‘Code Access Security’에 대한 깊은 지식이 없으므로 스마트 클라이언트 분야에 해당하는 보안 설정 부분을 위주로 설명해 나가겠다. 이외의 자세한 닷넷 보안에 대한 자료는 참고자료를 보기 바란다. 여기 서는 첫 회에서 다룬 수작업 보안 설정을 프로그램으로 자동화해 주는 애플리케이션을 제작해 볼 것이다. 그 방법에는 두 가지가 있는데, 첫 번째는 Caspol.exe를 실행시켜 설정하는 방법이고, 두 번째는 닷넷 BCL에서 제공되는 System.Security를 이용한 프로그래밍으로 직접 제어하는 방법이다. 두 가지 방법을 소개하기에 앞서 기본적인 사항부터 짚고 넘어가자. 먼저 첫 회에서 설정했던 ‘SmartClientSet’ 권한 집합과 ‘InternetSmartClient_Zone’ 코드 그룹에 대한 변경이 어디에 저장되는지 살펴보자. Enterprise : %SystemRoot%\Microsoft.NET\Framework\v1.0.3512\config\enterprisesec.config Machine : %SystemRoot%\Microsoft.NET\Framework\v1.0.3512\config\security.config User : %APPDATA%\Microsoft\CLR Security Config\v1.0.3512\security.config * SystemRoot : C:\Windows와 같이 OS가 설치된 폴더 * APPDATA : C:\Documents and Settings\Administrator\Application Data와 같이 현재 로그인한 계정의 응용 프로그램 데이터를 저장하는 폴더 [출처] IE에서 닷넷 스마트 클라이언트 개발3-스마트 클라이언트 배포하기2|작성자 선경