졸라 긴 여정 이였습니다... 모두 읽으신 분이 있으시다면 졸필 읽어주신 그 노력에 심심한 감사를 드립니다.

• ASP.NET에서 공유 폴더 액세스 (I) : 공유 폴더 기본 및 파일 서버 설정
• ASP.NET에서 공유 폴더 액세스 (II) : 프로그램에서의 공유 폴더 액세스
• ASP.NET에서 공유 폴더 액세스 (III) : 공유 폴더 액세스와 Impersonation
• ASP.NET에서 공유 폴더 액세스 (IV) : ASP.NET의 프로세스/쓰레드 계정 과 공유 폴더 액세스
• ASP.NET에서 공유 폴더 액세스 (V) 네트워크 드라이브 이용

Accessing Shared Folder in ASP.NET (IV)

ASP.NET에서 공유 폴더를 액세스하는 것은 조또 아니다. 공유 폴더에 대한 기본 사항들을 잘 기억하고, 파일 서버 및 공유 폴더에 적절한 계정, 공유 권한 등을 설정한 담에 이 계정을 사용하여 클라이언트가 공유 폴더에 접근하면 되는 것이다!. 사실 지난 포스트의 흉내내기(impersonation) 코드만 쓰면 ASP.NET 이든 ASP.NET 할아버지든 공유 폴더에 접근하는 것은 100% 성공하기 마련이다.

필자주) 아무리 용서 하려고 해도 Impersonation에 '가장' 이란 용어는 짜증이 밀려온다. 한글판 MSDN에 아무리 맞추려고 해도 의사 전달에 상당한 지장을 초래하는 지랄 맞은 '가장' 이란 용어는 더 이상 사용하지 않겠다. 대신 '흉내내기' 란 용어를 사용하도록 하겠다.

말은 졸라 쉬워도 내용을 모르면 삽질하게 되는 법... ASP.NET 어플리케이션은 지난 포스트의 콘솔 어플리케이션처럼 간단한 프로세스/쓰레드 모델을 갖는 것이 아니기 때문에 혼동이 올 수 있다. 그래서 이 포스트에서는 ASP.NET 어플리케이션의 쓰레드들은 어떤 계정 하에서 작동하는 가를 훑어 보는 것으로 시작하겠다.

ASP.NET Process Model

ASP.NET 어플리케이션은 작업 프로세스(worker process) 상에서 작동한다. 그리고 작업 프로세스는 미리 설정된 계정 하에서 작동하게 된다. 상세한 내용을 여기서 모두 다시 설명하긴 복잡하므로 ASP.NET 어플리케이션이 IIS 버전에 따라서 어떤 작업 프로세스 상에서 작동하는지, 그리고 각 작업 프로세스의 프로세스 계정은 어떤 것인지에 대해서는 필자의 IIS & ASP.NET Security 을 참고하기 바란다.

이렇게만 하고 넘어가면 너무 무성의한 듯 하니 좀 간략하게 정리를 해보면 다음과 같다.

ASP.NET Worker Process Account

ASP.NET 어플리케이션은 항상 IIS의 작업 프로세스에 의해 구동된다. Windows XP 혹은 Windows 2000의 경우(IIS 5.x)를 먼저 살펴보면, 닷넷 프레임워크와 함께 설치되는 특수한 aspnet_wp.exe 프로세스에 의해 ASP.NET 어플리케이션이 구동되게 된다. 모든 ASP.NET 어플리케이션은 이 프로세스에 의해 호스팅 되는 것이다. 이 프로세스의 계정은 machine.config 파일의 <processModel> 설정을 따른다. 이 설정의 의하면 기본적으로 ASPNET 계정에 의해 aspnet_wp.exe 프로세스가 작동하도록 되어 있다. 물론 이 설정을 바꾸면 SYSTEM 계정이나 기타 어떤 계정으로든 aspnet_wp.exe 프로세스를 구동 시킬 수 있다.

Windows 2003의 IIS 6.0은 새로운 작업 프로세스 모델에 의해 어플리케이션 풀 개념(필자의 IIS 6.0 에 대한 글을 읽어 보기 바란다)이 등장했고 이 어플리케션 풀은 w3wp.exe 프로세스에 의해 작동되게 된다. 이 프로세스의 계정은 machine.config 가 아닌 IIS 6.0의 메타베이스 설정을 따르게 된다. 기본값은 NETWORK SERVICE 계정으로 되어 있으며, SYSTEM 계정 혹은 LOCAL SERVICE 계정을 사용할 수도 있지만 별도의 사용자 계정을 사용할 수도 있다.

Worker Thread Account

지난 포스트에서도 살펴보았듯이 공유 폴더를 액세스할 때 프로세스 계정보다 중요한 것은 현재 쓰레드의 쓰레드 계정이다. ASP.NET 어플리케이션이 작동할 때 어떤 쓰레드 계정이 사용되는 가는 IIS 설정, ASP.NET의 web.config 설정 등에 따라서 매우 다르다. IIS & ASP.NET Security 에서도 언급하였지만 여기서 다시 한번 간략히 설명하겠다.

먼저 web.config 설정을 기준으로 말하자면, web.config의 <identity> 설정이 지대한 영향을 미친다. 이 설정은 IIS의 디렉터리 보안 설정과 더불어 ASP.NET를 수행하는 쓰레드의 계정을 지정하는데 사용된다. <identity> 설정에 impersonate 속성이 false로 되어 있다면 작업 쓰레드는 항상 프로세스의 계정을 사용한다. 즉, ASP.NET의 작업 쓰레드는 전혀 "흉내내기"를 수행하지 않으므로 작업 프로세스의 계정이 사용되는 것이다. <identity> 설정의 impersonate 속성의 기본값은 false 임을 알아 두자.

<identity> 설정의 impersonate 속성이 true 이면, IIS 메타베이스의 "디렉터리 보안"의 설정에 의해 쓰레드의 계정이 결정된다. IIS 설정(IIS 6.0)에서 "디렉터리 보안" 탭의 화면1에서 익명 액세스 가능 설정이 선택되어 있는가, 그리고 인증된 액세스에 어떤 것이 설정되어 있는가에 따라 쓰레드의 계정이 설정된다는 말이다. '익명 액세스 가능'이 선택되어 있다면 쓰레드 계정은 일단 IUSR_XXX 계정이 사용된다.

화면1. IIS의 디렉터리 보안 설정에서 인증 방법 다이얼로그

IIS & ASP.NET Security 에서의 설명이 반복되지만, 익명 액세스와 인증된 액세스 중 하나가 선택되어 있다면, IIS는 먼저 익명 액세스를 시도한다. 만약 이 익명 액세스가 실패한 경우(해당 .aspx 파일 혹은 기타 파일들에 대한 액세스가 실패하는 경우)에는 웹 클라이언트(웹 브라우저)에게 인증을 요구할 것이다. 웹 브라우저는 현재 브라우저를 수행하는 사용자 계정 혹은 인증 다이얼로그을 이용하여 IIS의 인증 요구에 부응할 것이고 이 계정이 웹 서버에 유효한 계정이라면 이 계정으로 "흉내내기"를 수행한다. 이러한 작업에 대한 구체적인 테스트 및 결과는 IIS & ASP.NET Security 에 다 설명한 내용이므로 반복하진 않겠다.

요약하자면, ASP.NET 어플리케이션의 쓰레드 계정은 web.config의 <identity> 설정에 의해 프로세스 계정이 사용되던가 아니면 IUSR_XXX 계정 혹은 웹 브라우저가 IIS의 인증 요구에 의해 제시한 계정이 사용된다.

Overriding ASP.NET Thread Account

ASP.NET의 web.config 설정은 IIS의 계정 설정과 무관하게 항상 하나의 계정을 쓰레드 계정으로 사용할 수 있다. <identity> 설정의 impersonate 속성을 true로 주고, 구체적으로 흉내내기 할 사용자 ID와 암호를 명시하면 이 사용자 계정을 항상 ASP.NET 쓰레드 계정으로 사용하게 된다. 예를 들어 다음과 같은 <identity> 설정이 있다고 가정하면, ASP.NET 코드를 수행하는 쓰레드 계정은 IIS 설정이나 브라우저를 수행하는 클라이언트의 계정에 무관하게 항상 TestUser로 설정되어 버린다는 것이다.

<identity>에 구체적으로 계정을 명시할 때는 항상 주의해야 할 사항이 있다. 이렇게 쓰레드의 계정으로 일반 사용자 계정이 사용되면 ASP.NET 엔진이 액세스하는 웹 서버의 일부 디렉터리들에 대한 사용권한이 없을 수 있기 때문이다. 일반적으로 ASP.NET 쓰레드 계정은 SYSTEM, NETWORK SERVICE, LOCAL SERVICE, ASPNET, IUSR_XXXX 계정이고 이들 계정들에 대해서는 ASP.NET이 수행하는 데 필요한 웹 디렉터리들(inet_pubs\wwwroot 및 그 하위 디렉터리들), ASP.NET이 생성하는 DLL 을 위한 임시 디렉터리 등에 대한 사용권한이 적절히 할당되어 있다. 하지만 위와 같이 TestUser 같은 일반 사용자 계정을 사용하는 경우엔, 이 계정이 이들 디렉터리에 사용권한이 없을 가능성이 매우 높기 때문에 화면2와 같은 오류를 유발할 수 있다.

화면2. 잘못된 ASP.NET 쓰레드 계정이 사용되는 경우 발생하는 예외 메시지

이러한 오류를 제거하는 방법은 해당 폴더 및 하위 폴더에 흉내내기 할 계정(이 경우, TestUser)이 적절한 권한을 갖도록 설정해 주어야 한다. IIS 5.x에서는 웹 어플리케이션의 디렉터리와 ASP.NET의 임시 디렉터리(화면2 참조) 등을 돌아다니면서 적절한 권한을 주어야 한다. 하지만 IIS 6.0 에서는 IIS_WPG 라는 새로운 그룹이 제공된다. 그리고 IIS 및 ASP.NET이 액세스하는 폴더들에는 이 그룹에 대해 적절한 권한이 주어져 있다. 따라서 흉내내기에 사용된 계정을 이 그룹에 포함시키는 것만으로 ASP.NET은 오류 없이 잘 작동할 것이다.

Accessing Shared Folder in ASP.NET

지금까지의 필자가 주저리 주저리 이야기 했던 것을 배경 삼아 ASP.NET 웹 어플리케이션에서 공유 폴더를 액세스하는 상황을 고려해 보자. 다시 한번 말하자면, 공유 폴더에 액세스하기 위해서는 파일 서버에 로그온 가능하며 공유 폴더 및 파일 서버의 공유된 디렉터리에 권한이 있는 계정을 사용해야 한다. 쉽게 말해 현재 여러분의 ASP.NET 어플리케이션이 사용하는 프로세스 계정 혹은 쓰레드 계정이 공유 폴더를 액세스할 권한이 있으면 되는 것이다. 사실 중요한 것은 쓰레드 계정이지만 web.config 설정이나 IIS 설정에 의해 프로세스 계정이 그대로 쓰레드 계정으로 사용되는 경우(이미 이러한 상황에 대해서 앞서 언급하였다)도 있으므로 프로세스 계정 역시 무시할 수는 없다.

가장 먼저 해야 할 작업은 현재 ASP.NET 어플리케이션이 어떤 쓰레드 계정을 사용하고 있는지 파악하는 일이 되겠다. 현재 사용되는 쓰레드 계정이 무엇인가 알아내는 코드는 이미 지난 포스트에서 살펴본 바 있다. 명시적으로 특별한 계정을 사용하지 않는 한 ASP.NET의 쓰레드 계정은 NETWORK SERVICE, SYSTEM, LOCAL SERVICE, ASPNET 혹은 IUSR_XXXX 계정일 것이다. 이들 계정은 모두 공유 폴더를 액세스하기에는 적합하지 않다는 것을 이 시리즈의 첫 번째 글에서 이미 밝힌 바 있다. 고로, ASP.NET을 수행하는 쓰레드가 적절한 계정을 사용하도록 설정을 바꾸어 주거나 코드를 추가해 주어야 한다.

Changing ASP.NET Process Account

그다지 권장하고 싶지 않은 방법이지만, 첫 번째 방법은 프로세스 계정을 바꾸는 것이다. IIS 6.0 이라면 어플리케이션 풀의 계정을 바꾸던가, IIS 5.x 라면 machine.config를 수정하여 aspnet_wp.exe 프로세스의 계정을 바꾸면 된다. <identity> 설정에 impersonate 속성이 true 가 아니라면 프로세스 계정이 그대로 쓰레드 계정이 되기 때문에 프로세스 계정을 바꾸어 주자는 것이다. 프로세스 계정을 바꿀 때에 주의할 점은 바뀐 프로세스 계정이 ASP.NET 어플리케이션이 구동하는데 필요한 사용 권한을 가져야 한다는 것이다. 앞서 잠깐 언급한 것과 동일하게 새롭게 설정된 프로세스 계정은 웹 서버의 디렉터리들과 ASP.NET의 임시 디렉터리 등에 대해 적절한 사용권한이 있어야 한다.

프로세스 계정을 바꾸는 것은 그다지 좋지 않은 방법이다. 잘 작동하는 웹 어플리케이션이라면 공연히 프로세스 계정을 바꾸었다가 다른 기능들이 작동하지 않는 경우가 허다하다. COM+를 사용하고 있다든가, 아니면 다른 특별한 파일 액세스를 한다던가 할 때 새로운 계정이 이러한 것들에 대해 모두 적절한 권한이 있어야 하기 때문이다. 이러한 권한을 일일이 찾아서 설정하기 매우 귀찮기 때문에, Administrators 그룹에 사용할 프로세스 계정을 포함시켜버리는 경우가 허다한데 이거 보안상 대단히 좋지 못하다고 할 수 있다.

Changing ASP.NET Thread Account using <identity> section

프로세스 계정을 바꾸지 않는다면 쓰레드 계정을 바꾸면 된다. web.config의 <identity> 설정을 이용하여 공유 폴더를 액세스할 수 있는 계정이 ASP.NET의 쓰레드 계정으로 사용되도록 설정하면 될 것 아닌가? 그렇다. 게다가 <identity> 설정은 각 폴더마다 web.config를 만들어 서로 다르게 줄 수도 있으므로, 공유 폴더를 액세스하는 .aspx 파일이 존재하는 폴더에만 <identity>  설정을 해 줄 수도 있어서 모든 웹 어플리케이션의 쓰레드 계정을 바꾸어야 하는 위험(?)을 감수하지 않아도 된다.

<identity> 설정을 주는 것이 특정 폴더 상의 .aspx 들의 쓰레드 계정만을 바꾼다고 하지만 해당 폴더에 많은 .aspx 들이 존재하고 그들 중 공유 폴더를 액세스하는 것이 겨우 한 두 개라면, 다른 .aspx 파일들이 새로운 쓰레드 계정 하에서 잘 작동한다는 보장이 없을 수도 있다. 정말 필요로 하는 것은 공유 폴더를 액세스하는 해당 .aspx 만의 쓰레드 계정만을 바꾸고 싶을 것이다.

Changing ASP.NET Thread Account using Impersonation Code

가장 좋은 방법으로는 해당 .aspx의 공유 폴더를 액세스하는 특정 코드 부분만을 다른 계정(공유 폴더 액세스 권한이 있는)으로 흉내내기 하는 것이다. 코드의 특정 부분만이 흉내내기를 함으로써 다른 코드들이 변경된 쓰레드 계정에 의해 권한 오류를 발생하는 것을 막을 수 있기 때문이다. 즉, 흉내내기에 의해 쓰레드 계정이 변경되는 코드 부분을 최소화 시키자는 것이다. ASP.NET에서 쓰레드 계정을 바꾸기 위한 설정으로는 앞서 언급한 바 대로 <identity> 섹션의 설정을 바꾸는 것인데 이 설정은 web.config 파일의 설정이고 web.config는 디렉터리 별로 설정할 수 있으므로 아무리 적은 단위로 쪼개어도 디렉터리에 존재하는 .aspx 들은 모두 이 설정을 따르게 된다. 따라서 .aspx 코드의 일부분 만이 다른 쓰레드 계정(공유 폴더에 액세스 가능한 계정)으로 흉내내기 하고자 한다면 직접 코딩에 의해 흉내내기를 수행할 수 밖에 없다.

지난 포스트에서 닷넷 코드를 통해 흉내내기 하는 방법에 대해선 이미 살펴보았다. 따라서 이 코드를 이용하여 공유 폴더를 액세스 하기 직전에 "흉내내기"를 수행하고 공유 폴더 액세스가 끝나면 다시 "흉내내기"를 취소(?) 하면 될 것이다. 구체적인 예제 코드는 여기서 다시 밝히지 않겠다. 바보가 아닌 이상 이전 포스트에서 보여준 예제를 이용하여 이 정도의 코딩은 할 수 있을 거라 믿는다.

ASP.NET Impersonation Utility

아주 가끔... 기존 코드에 흉내내기 코드를 추가하기 어려울 때가 있다. 소스코드를 구할 수 없다든가, 아니면 내가 작성한 소스가 아니여서 수정하기 영 까칠하다던가 등등... 이럴 때 손쉽게 사용할 ASP.NET Http Handler를 소개한다. 필자가 간단히 작성한 ImpersonateHandler 는 web.config의 <identity> 와 동등한 역할을 한다. <identity> 설정은 해당 디렉터리의 모든 .aspx, .asmx 등에 대해 "흉내내기"를 수행해 버리지만 필자의 ImpersonateHandler는 특정 .aspx 파일을 대상으로만 흉내내기를 수행하도록 해준다.

Impersonate Handler 다운로드~

사용법은 대단히 간단하다. 먼저 DLL을 bin 폴더에 복사해 넣고, <system.web> 섹션에 <httpHandlers> 서브 섹션을 추가하고 필자의 ImpersonateHandler 를 추가한다. 추가할 때 "흉내내기"를 수행할 .aspx 파일 명 혹은 와일드 카드를 이용하여 파일 패턴을 명시해 준다. 여기서 명시해 줄 .aspx는 당근 공유 폴더를 액세스 해야 하는 웹 페이지 일 것이다. 구체적으로 예를 들자면, 업로드 된 파일을 파일 서버에 저장해야 하는 .aspx 파일 정도?

리스트1. ImpersonateHandler 등록 설정

리스트1과 같이 Http Handler를 등록해 두면 해당 경로(파일)가 액세스 되면 ImpersonateHandler가 수행될 것이다. 이제 ImpersonateHandler는 페이지를 정상 수행시키기 전에 흉내내기를 수행하고 나서 주어진 웹 페이지를 정상 수행한다. 소스코드를 다운로드 받아 살펴보면 알겠지만, System.Web.UI.PageParser 클래스의 GetCompiledPageInstance() 메쏘드를 호출하면 주어진 페이지를 수행시킬 수 있다. 여기서 말하는 페이지란 ImpersonateHandler에 의해 가로채진 페이지를 말한다. 흉내내기에 사용할 계정은 <appSettings> 에 설정된 ImpersonateUserID, ImpersonatePassword, ImpersonateDomain 값에 의해 결정된다. 뭐 복잡할 것은 없고 <identity> 과 동등하지만 그것이 미치는 범위를 좀더 세밀하게 줄 수 있다고 생각하면 되겠다.

마지막으로 ImpersonateTest 설정은 흉내내기를 테스트하기 위한 설정으로 이 설정이 주어지면(그 값에 상관없이) 페이지를 수행한 계정을 자바 스크립트로 화면3과 같이 표시해 준다. 흉내내기가 성공했는지 실패했는지를 판단할 때 사용하면 되겠다. (소스를 보면 알겠지만, 사실 그다지 중요한 테스트를 해주는 것은 아니다. -_-) ImpersonateTest 설정을 없애면 이 다이얼로그는 나타나지 않는다.

화면3. ImpersonateTest 설정 테스트 결과

Summary

ASP.NET에서 공유 폴더를 액세스하기 위해서는 코드를 수행하는 쓰레드의 계정을 공유 폴더를 액세스 가능한 계정으로 만들어 주면 된다. 대개 기본적으로 사용되는 NETWORK SERVICE, SYSTEM, LOCAL SERVICE, ASPNET, IUSR_XXX 계정은 공유 폴더를 액세스하기엔 부적한 점이 많기 때문에 쓰레드 계정을 바꾸어 주는 것이 좋다.

web.config 의 <identity> 설정을 사용하여 쓰레드 계정을 바꾸어 줄 수도 있지만 어플리케이션의 모든 코드가 이 계정 하에서 수행될 때 다른 보안 오류가 발생할 수 있기 때문에, 공유 폴더를 액세스하는 코드 부분만을 흉내내기 코드에 의해 쓰레드 계정을 '잠시 동안만' 바꾸어 주는 것이 좋다. 소스 코드를 수정할 수 없는 상황이라면 필자의 ImpersonateHandler 유틸리티를 사용하는 것도 고려해 볼 수 있겠다.

필자의 유틸리티를 사용해볼 독자라면 코드에 대한 피드백을 부탁하는 바이다.