로그인

Select the product you need help with

ASP.NET에서 프로세스 및 요청 ID

본 문서에서는 기본 프로세스 계정에 부여된 액세스 권한을 간략히 설명하고 이 권한이 특정 작업에 매우 제한적일 수 있는 몇몇 상황을 설명합니다.

Microsoft Windows 2000 및 Microsoft Windows XP 상의 ASP.NET의 기본 설치에서는 ASP.NET이 작업자 프로세스에서 웹 응용 프로그램 코드를 실행합니다. 이 프로세스의 ID는 기본적으로 ASPNET 계정이라는 로컬 계정(전체 이름이 aspnet_wp 계정임)을 사용합니다. ASP.NET의 베타 릴리스에서 프로세스 ID는 시스템에 많은 액세스 권한을 가진 강력한 관리 계정인 System입니다. 보다 권한이 적은 기본 설치를 제공하기 위해 ASP.NET의 릴리스 버전은 대부분의 웹 응용 프로그램에 적합한 좀더 약한 ASPNET 계정을 사용합니다.

참고 기본적으로 Microsoft Internet Information Services(IIS) 6.0을 사용하는 경우 ASP.NET 웹 응용 프로그램은 NetworkService 계정의 보안 컨텍스트에서 실행됩니다.

위로 가기 | 피드백 보내기

추가 정보

프로세스 ID 구성

설치 루트 디렉터리의 Config 하위 디렉터리에 있는 Machine.config 파일의 <processModel> 섹션에서 프로세스 ID를 구성할 수 있습니다. userName 및 password 특성은 프로세스의 ID를 제어합니다. 이 특성의 기본 값은 다음과 같습니다.

<processModel  userName="machine" password="AutoGenerate" />

machine 및 AutoGenerate 값은 기본으로 제공된 ASPNET 계정을 사용하고 해당 계정의 LSA(로컬 보안 기관)에 저장되어 있는 강력하게 암호화된 임의의 암호를 사용하도록 ASP.NET에 지시합니다.

좀더 많은 액세스 권한이 있는 프로세스를 사용하려면 userName 특성을 System으로 설정합니다. System으로 설정하면 ASP.NET 작업자 프로세스가 Inetinfo.exe 프로세스와 동일한 ID를 사용하여 실행합니다. Inetinfo.exe 프로세스는 기본적으로 System ID로 실행됩니다. System ID를 사용하도록 ASP.NET 작업자 프로세스를 구성하면 ASP.NET 작업자 프로세스는 로컬 컴퓨터의 거의 모든 리소스에 액세스할 수 있습니다. Windows 2000 또는 Windows XP를 실행하는 컴퓨터에서 System 계정은 네트워크 자격 증명도 가지고 있고 시스템 계정으로 네트워크 리소스에 액세스할 수 있습니다. System ID로 실행되도록 프로세스를 구성하려면 <processModel> 섹션의 userName 특성을 다음과 같이 변경합니다.

<processModel  userName="SYSTEM" password="AutoGenerate" />

ASPNET 계정의 기본 사용 권한

ASPNET 계정은 ASP.NET 설치 시 로컬 계정으로 만들어집니다. ASPNET 계정은 해당 컴퓨터의 Users 그룹에만 속합니다. 따라서 ASPNET 계정은 Users 그룹과 연관된 모든 권한을 가지고 있고 Users 그룹에 액세스 권한이 부여된 모든 리소스에 액세스할 수 있습니다. ASPNET 계정은 Users 그룹에서 다음 사용자 권한을 상속합니다.

SeChangeNotifyPrivilege
SeUndockPrivilege
SeInteractiveLogonRight
SeNetworkLogonRight

이 권한 이외에도 ASPNET 계정에는 기본적으로 다음과 같은 권한이 부여됩니다.

SeServiceLogonRight
SeBatchLogonRight
SeDenyInteractiveLogonRight

ASP.NET은 다음 폴더에 ASPNET 계정에 대해 고유한 전체 액세스 권한을 부여합니다.

Temporary ASP.NET Files
%windir%\temp

또한 ASP.NET은 Microsoft .NET Framework 설치 디렉터리에 읽기 권한을 부여합니다.

다음 목록은 ASPNET 계정에 필요한 ACL(액세스 제어 목록)을 간략히 설명합니다. Windows 2000 및 Microsoft .NET Framework의 기본 설치에 이 ACL이 포함됩니다.

위치: %installroot%\ASP.NET Temporary Files
사용 권한: 폴더에 대한 읽기/쓰기 및 드라이브의 루트 폴더에 대한 폴더 내용 보기 권한
계정: 프로세스 계정 및 구성된 가장 계정
설명: ASP.NET 동적 컴파일의 위치입니다. 이 위치 아래에 각 응용 프로그램에 대한 별도의 디렉터리에 응용 프로그램 코드가 생성됩니다. <compilation> 섹션에서 tempDir 특성을 사용하여 루트 위치를 구성할 수 있습니다.

참고 ASP.NET 임시 파일을 다른 위치에 저장하도록 machine.config를 변경하려면 ASPNET 계정이 해당 드라이브의 루트 수준에서 폴더 내용 보기 권한을 갖고 있어야 합니다.
위치: %windir%\temp
사용 권한: 읽기/쓰기
계정: 프로세스 계정
설명: XML(eXtensible Markup Language) 웹 서비스가 직렬화 프록시를 생성하는 데 사용하는 위치입니다.
위치: 응용 프로그램 디렉터리
사용 권한: 읽기
계정: 프로세스 계정 및 구성된 가장 계정
설명: 응용 프로그램 콘텐츠가 저장되는 위치입니다. 읽기 권한만 필요합니다.
자세한 내용은 다음 Microsoft 웹 사이트를 참조하십시오.
http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetHT01.asp
(http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetHT01.asp)
위치: 웹 사이트 루트(%systemdrive%\inetpub\wwwroot 또는 기본 웹 사이트가 가리키는 경로)
사용 권한: 읽기
계정: 프로세스 계정 및 구성된 가장 계정
설명: ASP.NET은 drive:\inetpub\wwwroot\web.config에서 구성 파일을 읽고 변경 사항을 모니터링합니다.
위치: %installroot% 계층
사용 권한: 읽기
계정: 프로세스 계정 및 구성된 가장 계정
설명: ASP.NET은 Machine.config 파일(%installroot% 아래의 \Config 하위 디렉터리에 위치)에서 .NET Framework 어셈블리에 액세스할 수 있어야 합니다.
위치: %windir%\assembly
사용 권한: 읽기
계정: 프로세스 계정 또는 구성된 가장 계정
설명: 공유 어셈블리가 포함하고 있는 전역 어셈블리 캐시입니다.

Windows 2000 기반 컴퓨터의 기본 ACL에 대한 자세한 내용은 참조 절에 있는 "Windows 2000의 기본 액세스 제어 설정" 백서(영문)를 참조하십시오.

참고 기본적으로 ASPNET 계정에는 이 문서에서 설명한 몇몇 작업을 수행할 적절한 액세스 권한이 없는 경우가 많습니다.

리소스 액세스

다음 절에서는 다양한 리소스를 사용하는 방법에 대해 설명합니다. 가장을 사용하고 리소스에 대한 가장된 계정 액세스 권한을 부여하면 많은 리소스에 액세스할 수 있습니다. 그러나 응용 프로그램이 Kerberos 또는 기본 인증처럼 위임할 수 있는 인증 메커니즘을 사용하지 않는 경우 원격 리소스에 액세스하려고 할 때 가장을 사용할 수 없는 경우가 많습니다. 고정된 ID를 사용하여 코드 실행 절에서 설명하는 것처럼 COM+ 서비스를 사용하여 리소스에 액세스할 수도 있습니다.

파일 리소스 사용

ASPNET 계정에서 실행하는 응용 프로그램이 파일에 쓸 수 있게 하기 위해 파일에 쓰기 전에 코드에서 특정 사용자를 가장하거나 ASPNET 계정에 대해 쓰기 권한을 부여할 수 있습니다. 개별 파일 또는 디렉터리 계층에 대해 쓰기 권한을 부여할 수 있습니다.

중요 개별 파일 또는 디렉터리 계층에 대한 쓰기 권한을 ASPNET 계정에 부여하면 서버에서 ASPNET 계정으로 실행하는 모든 ASP.NET 웹 응용 프로그램도 이 파일이나 디렉터리 계층에 쓸 수 있습니다. 코드에서 특정 사용자를 가장하는 방법에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

306158

(http://support.microsoft.com/kb/306158/ )

ASP.NET 응용 프로그램에서 가장(Impersonation)을 구현하는 방법

파일의 ACL(액세스 제어 목록)을 변경하려면 다음과 같이 하십시오.

Windows 탐색기를 엽니다.
사용 권한을 변경할 파일이나 폴더를 선택합니다.
파일 메뉴에서 등록 정보를 누릅니다.
보안 탭을 누릅니다. 필요한 사용 권한 확인란을 선택합니다.

또한 스크립트나 Cacls.exe 명령줄 도구(Windows에 포함)를 사용하여 파일의 ACL을 변경할 수 있습니다.

ASP.NET 1.1에서는 <DriveName>\Documents and Settings\<MachineName>\ASPNET 폴더를 사용하여 프로세스 파일을 저장합니다. 여기서 <DriveName>은 ASP.NET이 설치된 컴퓨터의 드라이브 이름이며 <MachineName>은 컴퓨터 이름입니다.

가장 사용

가장을 사용하면 요청 엔티티의 보안 컨텍스트에서 인증된 사용자나 익명 사용자로 실행합니다. ASP.NET에서 가장은 선택적인 사항이며 기본적으로 설정되어 있지 않습니다. 컴퓨터나 응용 프로그램 수준에서 가장을 설정하려면 Machine.config 또는 Web.config 파일의 <system.web> 섹션에서 다음 구성 지시문을 추가합니다.

<identity impersonate="true"/>

데이터베이스 사용

SQL 인증을 사용하여 데이터베이스에 연결하는 응용 프로그램은 ASPNET 계정으로 전환하는 작업으로 인해 일반적으로 영향을 받지 않습니다. 또한 통합 인증 및 가장을 사용하는 응용 프로그램에서도 마찬가지입니다. 그러나 응용 프로그램이 가장하지 않고 Windows 인증을 사용하는 경우 ASPNET 계정에 데이터베이스 액세스 권한을 부여해야 합니다.

명명된 파이프를 통해 Windows 통합 인증을 사용하여 Microsoft SQL Server를 인증하려고 할 때 ASPNET 계정을 사용할 수 없습니다. 그러나 TCP(전송 제어 프로토콜) 전송 상에서는 Windows 통합 인증을 사용하여 ASPNET 계정을 사용할 수 있습니다.

응용 프로그램이 Microsoft Access 데이터베이스를 사용해야 하는 경우 ASPNET 계정은 데이터베이스 파일에 쓸 수 있어야 합니다. 관리자는 파일 사용 권한을 상황에 맞게 조정해야 합니다.

이벤트 로그 사용

응용 프로그램 이벤트 로그에 써야 하는 응용 프로그램은 ASPNET 계정으로 실행되는 동안 응용 프로그램 이벤트 로그에 쓸 수 있습니다. 응용 프로그램이 새 이벤트 로그 범주를 만들어야 하는 경우 응용 프로그램은 HKEY_LOCAL_MACHINE 레지스트리 하이브 아래에 레지스트리 키를 만들어야 하지만 ASPNET 계정으로 이 작업을 할 수 없습니다.

실행 중인 상태에서 범주를 만들려면 가장을 설정한 다음 좀더 많은 액세스 권한이 있는 계정을 가장해야 합니다. 또는 관리자가 범주를 만들고 응용 프로그램이 실행 중에 이 범주에 쓸 수 있도록 할 수 있습니다.

응용 프로그램이 새 이벤트 로그 범주를 만들어야 하는 경우 설치 시 해당 범주를 만드십시오. 범주가 만들어지면 ASPNET 계정에서 응용 프로그램 이벤트 로그에 쓸 수 있습니다.

System.DirectoryServices 및 Active Directory 사용

웹 응용 프로그램이 Active Directory에 액세스해야 하는 경우 응용 프로그램은 위임을 지원하는 환경에서 가장을 사용할 수 있습니다. 또는 응용 프로그램이 명시적 자격 증명을 System.DirectoryServices 네임스페이스의 DirectoryEntry 생성자에 제공하여 Active Directory에 액세스할 수 있습니다. 응용 프로그램이 명시적 자격 증명을 사용하면 응용 프로그램은 COM+ 생성 문자열 같은 기술을 사용하거나 Windows 데이터 보호 API(응용 프로그래밍 인터페이스)를 사용하여 자격 증명을 적절히 저장해야 합니다.

성능 카운터 사용

ASPNET 계정은 성능 카운터 데이터에 쓸 수 있는(읽을 수는 없음) 충분한 권한을 갖고 있습니다. 응용 프로그램이 성능 카운터 데이터를 읽거나 성능 카운터 범주를 만들어야 하는 경우 Administrator 또는 Power User 권한이 필요합니다.

응용 프로그램이 새 성능 카운터 범주를 만들어야 하는 경우 설치 시 해당 범주를 만드십시오. 범주가 만들어지면 ASPNET 계정이 카운터에 쓸 수 있습니다.

ASPNET 계정을 사용할 때 성능 모니터 도구(Perfmon.exe)를 사용하여 ASP.NET 성능 카운터를 모니터링할 수 있습니다.

Windows 2000의 경우 다음 단계를 수행하십시오.

레지스트리 편집기를 실행합니다.
다음 레지스트리 키를 찾습니다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ASP.NET_1.1.4322\Names
보안 탭을 누릅니다.
다음과 같은 사용 권한을 갖는 작업자 프로세스 ID를 추가합니다.
- 값 쿼리
- 값 설정
- 하위 키 만들기
- 하위 키 열거
- 알림
- 읽기 제어

Windows Server 2003에서는 해당 ID를 IIS_WPG 그룹에 추가합니다.

Out-of-Process COM 서버 시작

ASPNET 계정으로 실행하는 동안 Out-of-Process COM 서버를 시작해야 하는 응용 프로그램은 Dcomcnfg.exe 도구를 사용하여 계정에 시작 권한을 따로 부여할 수 있습니다.

디버깅 문제

기본적으로 클라이언트 응용 프로그램에서 XML 웹 서비스 호출을 한 단계씩 실행할 수 없습니다. XML 웹 서비스를 한 단계씩 실행하려면 XML 웹 서비스를 실행하는 컴퓨터의 Debugger Users 그룹에 ASPNET 계정을 추가해야 합니다.

고정된 ID를 사용하여 코드 실행

COM+ 서비스에서 고정된 ID를 사용하여 코드를 실행할 수 있습니다. System.EnterpriseServices 네임스페이스의 ServicedComponent 클래스를 사용하여 COM+ 서비스를 사용하는 관리된 코드 구성 요소를 작성할 수 있습니다. ServicedComponent에서 파생되어 사용 권한을 가진 기능을 클래스에 래핑한 다음 구성된 ID를 사용하여 이 클래스를 COM+ 서버 응용 프로그램으로 실행할 수 있습니다.

UNC 공유에서 코드 숨김 파일 컴파일

ASP.NET에서는 여러 가지 방법을 사용하여 응용 프로그램 파일을 개발할 수 있습니다.

.aspx 파일에서 HTML(Hypertext Markup Language)을 사용한 다음 Bin 디렉터리에 미리 컴파일된 어셈블리의 페이지 코드를 저장할 수 있습니다. 이 방식이 Microsoft Visual Studio .NET 모델입니다.
모든 코드 및 HTML 콘텐츠는 필요할 때 컴파일되는 단일 원본 파일로 패키지할 수 있습니다.
ASP.NET 파일에 HTML 프레젠테이션을 넣은 다음 <%@ Assembly %> 지시어에 src 특성을 사용하여 해당 파일의 연관된 원본 코드를 동적으로 컴파일할 수 있습니다.

참고 응용 프로그램 콘텐츠가 네트워크 공유에 있으면 컴파일러는 ASPNET 계정에서 시작되기 때문에 파일에 액세스할 네트워크 자격 증명이 없습니다. 네트워크 공유를 사용하면 src 특성을 사용하여 파일을 가리킬 수 없습니다. 대신 다른 방법 중 하나를 사용해야 합니다.

주 도메인 컨트롤러 또는 백업 컨트롤러에서 ASP.NET 사용

기본적으로 도메인 컨트롤러에서 ASP.NET 1.1을 사용하면 ASP.NET 웹 응용 프로그램은 IWAM_<ComputerName> 계정의 보안 컨텍스트에서 실행됩니다. 여기서 <ComputerName>은 사용자의 컴퓨터 이름입니다.

자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

315158

(http://support.microsoft.com/kb/315158/ )

FIX: 도메인 컨트롤러에서 비 관리자 도메인 계정을 사용하면 ASP.NET이 작동하지 않는다

맨 위로

IIS 메타베이스 읽기

ASPNET 계정은 Microsoft Internet Information Services(IIS) 메타베이스를 읽을 수 없습니다. 응용 프로그램이 메타베이스 설정에 액세스해야 하는 경우 Metaacl.exe 유틸리티를 사용하여 선택적으로 메타베이스 노드에 읽기 액세스 권한을 부여할 수 있습니다.

응용 프로그램에서 검색 서비스를 제공하기 위해 IIS 메타베이스를 읽어야 하는 .disco 파일을 사용해야 하는 경우 ASPNET 계정의 메타베이스에 읽기 액세스 권한을 부여해야 합니다.

System.Management 및 WMI 사용

WMI(Windows Management Instrumentation)는 Windows 기반 컴퓨터를 관리하고 모니터링하는 데 사용할 수 있는 강력한 관리 기능을 제공합니다. 그러나 ASP.NET 응용 프로그램이 ASPNET 계정으로 실행될 때 이 계정은 Everyone과 동일한 기본 액세스 권한만 가집니다. 기본 액세스 권한에는 WMI 데이터 읽기, 공급자 데이터 쓰기 및 로컬 컴퓨터의 공급자에 대한 메서드 실행 등이 포함됩니다. WMI 보안 메커니즘에 대한 자세한 내용은 WMI Platform SDK 설명서나 MSDN을 참조하십시오.

참고 SP3 이상이 설치되지 않은 Windows 2000이나 SP1 이상이 설치되지 않은 Windows XP에서는 ASPNET 계정으로 실행되는 ASP.NET 웹 응용 프로그램이 작동되지 않고 "액세스가 거부되었습니다(0x80041003)" 오류 메시지가 나타날 수 있습니다. 이러한 문제는 계정에 특정 WMI 네임스페이스를 액세스할 수 있는 충분한 권한이 없기 때문에 발생합니다. 이 문제를 해결하려면 Windows XP SP1 이상이나 Windows 2000 SP3 이상을 설치합니다. 이 문제를 해결하려면 다음 단계를 수행하십시오.

컴퓨터 관리 MMC(Microsoft Management Console) 스냅인을 엽니다.
서비스 및 응용 프로그램을 확장한 다음 WMI 컨트롤을 선택합니다.
WMI 컨트롤을 마우스 오른쪽 단추로 누르고 등록 정보를 누릅니다.
WMI 컨트롤 등록 정보 대화 상자에서 보안 탭을 누릅니다.
Root를 확장하고 CIMV2를 선택한 다음 보안을 누릅니다.
보안 대화 상자에서 고급을 누릅니다.
액세스 컨트롤 설정 대화 상자에서 추가를 누릅니다. localMachineName\ASPNET를 선택한 다음 확인을 누릅니다.
사용 권한 항목 대화 상자에서 적용 대상이 이 이름 공간과 하위 이름 공간으로 설정되었는지 확인합니다.
'계정 사용' 허용 및 '원격으로부터 사용 가능' 허용 확인란이 선택되었는지 확인합니다.
WMI 컨트롤 등록 정보 대화 상자로 돌아갈 때까지 각 대화 상자에서 확인을 누릅니다.
응용 프로그램이 액세스할 다른 WMI 네임스페이스에 대해 5-10 단계를 반복합니다.
IIS를 다시 시작합니다. IIS를 다시 시작하려면 명령줄에서 IISRESET을 실행합니다.

기본적으로 ASP.NET은 ASPNET 계정에 대해 강력하게 암호화된 암호를 생성합니다. 따라서 이 방법은 ASPNET 계정 암호가 기본값 외의 다른 값으로 재설정되거나 컴퓨터 사이에 공유되지만 않는다면 안전한 해결 방법입니다.

데스크톱과 상호 작용

IIS 서비스가 데스크톱과 상호 작용할 수 있도록 구성할 때 기본 윈도우 스테이션 및 데스크톱의 DACL(임의 액세스 제어 목록)로 인해 ASPNET 계정에는 데스크톱에 액세스할 적절한 권한이 없습니다. 관리자가 이 DACL을 변경하거나 사용자가 이 개체에 액세스할 권한이 있는 계정으로 프로세스를 실행할 수 있습니다.

ASP.NET 제거

ASP.NET를 제거하면 ASPNET 계정은 사용되지 않고 시스템에 남아 있습니다. ASP.NET을 다시 설치할 계획이 없다면 ASPNET 계정을 삭제해도 됩니다.

ASPNET 계정을 명시적으로 삭제한 후 ASP.NET을 다시 설치하면 새로운 SID(보안 식별자)를 가진 새 ASPNET 계정이 만들어집니다. 따라서 이전 ASPNET 계정을 참조하는 어떤 ACL도 새로 만들어진 ASPNET 계정에 더 이상 적용되지 않습니다.

위로 가기 | 피드백 보내기