달력

022012  이전 다음

  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  •  
  •  
  •  

BillS' IIS Blog  Beta 3 Released Learn what's new in IIS7!

Vista IIS7 개발을 가능하게 해주는 목표로 출시된 반면, Longhorn 서버의 IIS7 실제 개발된 웹응용프로그램이 높은 퍼포먼스로 배포되고 운영되는 것을 목표 하는 버젼입니다. 위의 링크에 새로 추가된 점들이 설명되어있는데, 이를 간략히 옮겨봅니다:

공유된 설정(Shared Configuration) - IIS7 전역 설정을 여러대의 서버에 공유할 있는 기능입니다. 이를 통하여 웹팜(WebFarm)등의 관리를 쉽게할 있습니다.

자동 AppPool 격리 - 이전 버젼에서는 AppPool 직접 만들어줘야했던 반면 IIS7에서는 Site 생성할 때에 자동으로 별도의 AppPool 생성하여줍니다. 부가적으로 해당 AppPool에만 적용되는 별도의 SID 생성하여 격리시켜줍니다.

위임된, 원격 관리 - HTTP/SSL 통한 원격 관리가 가능합니다. 또한 서버 관리자가 관리가 필요한 사이트(Site) 관리 작업을 사이트 관리자에게 위임하여 관리할 있는 기능을 추가하였고, 이는 원격 관리자(Remote Manager)라는 기존의 관리자 업그레이드로 있습니다.

빌트인 FastCGI for PHP 지원 - 기존 프리뷰에서는 다운로드하여 설치해야했던 FastCGI Longhorn 서버에서는 기본적으로 포함하도록 하였습니다. 기능을 설치할때 CGI 설치하면 기존의 CGI 방식과 FastCGI 모두 사용할 있도록 설치하게 됩니다.

FTP 사용한 퍼블리싱 - FTP 사이트를 퍼블리싱할 있도록 새로운 FTP 서버를 만들었습니다. 여기 다운로드 있으며, FTP/SSL 지원과 IIS7 설정 시스템과 관리툴을 지원하는 퍼블리싱 지원, 기본 인증 지원등을 포함합니다.

GoLive 라이센스 지원 - 이번 Longhorn 서버 베타3 IIS7 GoLive 라이센스 적용하여 실제 사이트 운영에 사용할 있도록 하였습니다. 이를 사용하여 IIS7 베타3 호스팅을 무료로 하는 호스팅업체들을 찾을 있습니다.

새로운 개발자 포털 - 개발자가 IIS7 사용할 이용할 있는 리소스를 제공하는 포털입니다.

추가적으로 Windows Server 2003보다 2배의 확장성을 가진 WMS(Windows Media Server) 베타3 버젼 다운로드 있습니다. 이는 Server Core 설치하여 해당 기능만을 위한 서버를 만들 있도록 수도 있습니다.

출처 : bkchung's WebLog

Posted by 상현넘™

댓글을 달아 주세요

서론

IIS7 은 XML 구성 설정 파일들을 완벽하게 조작할 수 있게 해주고 서버 개체들에 대한 편리한 접근을 가능하게 해주는 관리되는 코드로 작성된 포괄적인 관리 응용 프로그램 프로그래밍 인터페이스 (API) 를 제공해줍니다. 본문에서는 서버의 구성 설정을 수정하고 서버 개체들을 관리하기 위해 새로운 관리 API 를 사용하는 방법을 여러분들에게 소개해드리고자 합니다.

IIS7 에는, XML 구성 설정 파일들의 완벽한 조작을 통해 구성 설정을 편집할 수 있게 해줄 뿐만 아니라 서버와 서버의 속성 및 상태를 관리하기 위한 편리한 개체들을 제공해주는, 웹 서버를 위한 새로운 관리 API 인 Microsoft.Web.Administration 이 포함되어 있습니다. 구성 설정 편집이라는 관점에서 볼 때, 이 API 에서는 IIS 구성 설정 파일 계층 및 특정 구성 설정 파일들의 구성 설정 속성들에 대한 프로그래밍적인 접근 방법을 제공해줍니다. 그리고, 개체 관리 측면에서는 서버의 직접적인 관리를 위한 일련의 최상위 관리 개체들을 제공해줍니다. (예: 사이트, 응용 프로그램 풀, 작업자 프로세스 등)

이러한 관리 클래스들은 Microsoft.Web.Administration 네임스페이스에 포함되어 있습니다. 이 클래스들은 구성 설정 섹션들과 편리한 개체들에 접근할 수 있는, 구성 설정상의 특성들에 대응하는 속성들과 (가상 디렉터리의 경로 등) 특정 개체를 대상으로 동작을 수행하는 메서드들을 (응용 프로그램 풀 재생 등) 가지고 있는 약한 유형의 인터페이스를 제공합니다.


전제조건
  1. 반드시 IIS 가 머신에 설치되어 있어야만 합니다. 예를 들어서, 인터넷 익스플로러의 주소창에 http://localhost/ 라고 입력했을 때, "환영합니다." 페이지가 나타나야만 합니다. 만약 IIS 가 설치되어 있지 않다면 설치 방법에 관한 문서를 참고하여 IIS 를 설치합니다.
  2. 먼저 여러분들이 머신에 대한 관리자 권한을 갖고 있는지를 확인하십시오. 만약 여러분들이 내장된 Administrator 계정 이외의 계정으로 로그온했다면, 비록 해당 계정이 머신의 로컬 Administrators 그룹에 추가되어 있는 계정이라고 하더라도 기본적으로 관리자 권한을 갖고 있지 않은 것으로 간주됩니다. (이 기능은 LUA 라고 불리우는 Longhorn 에서 제공되는 새로운 보안 관련 기능으로서, 본문에서 다루고자 하는 범위를 벗어나는 주제입니다.) 내장된 Administrator 계정으로 로그온하거나, 또는 필요하다면 “runas” 명령줄 도구를 사용하여 명시적으로 응용 프로그램을 내장된 Administrator 계정의 권한으로 실행시키십시오. 예를 들어, notepad.exe 를 실행시키기 위해서 “runas /user:administrator notepad.exe” 와 같은 명령어를 실행시킬 수 있습니다. 이 명령어를 실행하면 Administrator 계정의 비밀번호 입력을 위한 대화 상자가 나타날 것입니다. 아니면 “runas /user:administrator cmd.exe” 명령어를 실행하여, 미리 관리자 권한을 가진 명령 프롬프트를 실행하는 것도 또 다른 방법입니다. 이 명령 프롬프트에서 실행되는 응용 프로그램들 역시 모두 관리자 권한으로 실행되며, 명렴 프롬프트에서 “runas” 구문을 사용할 필요가 없어집니다.
  3. 반드시 마스터 구성 설정 파일을 백업하도록 하십시오. 단지 applicationHost.config 파일을 다른 이름으로 복사해 놓기만 하더라도, 나중에 원상태로 복구가 가능합니다. 이 applicationHost.config 파일은 %windir%\system32\inetsrv\config 디렉터리에서 찾을 수 있습니다. 이 작업을 처리하기 위해서는 방금 위에서 설명한 관리자 권한이 필요하다는 점에 주의하십시오.
  4. 본격적인 작업을 시작하기 전에 시스템이 "깨끗한 상태" 가 되도록 하십시오. 이를 위해서, 지금까지 이루어진 applicationHost.config 파일에 대한 모든 변경 사항들을 원래대로 돌려 놓으십시오. (만약, 여러분들이 VPC 이미지를 사용중이라면, 가장 손쉬운 방법은 변경된 상태를 저장하지 않고 이미지를 재시작하는 것입니다.)
  5. Microsoft.Web.Administration 라이브러리를 사용하여 코딩이 가능하도록, 이 라이브러리를 여러분들의 콘솔 응용 프로그램 프로젝트에 참조를 추가해야만 합니다. 비주얼 스튜디오에서는, 솔루션 탐색기에서 프로젝트를 마우스 오른쪽 버튼으로 클릭한 다음 "참조 추가" 메뉴를 클릭하여 손쉽게 작업을 처리할 수 있습니다. MSWEBADMIN 라이브러리는 %WINDIR%\System32\InetSrv 디렉터리에서 찾을 수 있습니다.
  6. 문제점이 발생하면 빨리 대응이 가능하도록 가급적 인터넷 익스플로러의 "HTTP 오류 메시지 표시" 기능을 (도구 > 인터넷 옵션 > 고급) 꺼놓는 것을 권장합니다.
  7. 주의 : .html 파일로부터 텍스트를 복사하는 경우, 숨겨진 문자들까지도 함께 복사가 됩니다. 따라서 여러분들이 복사한 텍스트를 비주얼 스튜디오 같은 편집기, 또는 명령 프롬프트에 붙여 넣으면 겉으로 보기에는 정상적으로 복사가 된 것처럼 보이지만, 숨겨진 문자들을 포함하고 있기 때문에 적절하게 동작을 하지 않게 됩니다. 그래서, 결과적으로는 문제점을 발견해 내기가 매우 어려워집니다. 이 문제를 해결하기 위한 가장 좋은 방법은 복사한 텍스트를 먼저 노트패드에 붙여 넣은 뒤에 노트패드에 복사된 텍스트를 다시 한 번 복사하는 것입니다. 이렇게 하면 숨겨진 문자들이 제거됩니다. 만약 텍스트가 짧다면, 복사해서 붙여 넣는 것이 아니라 여러분들이 직접 타이핑하여 입력하는 것이 더 간단할 수도 있습니다.

새 사이트 만들기 개요

다음의 코드는 “Racing Cars Site” 라는 이름의 사이트를 루트 응용 프로그램 및 루트 가상 디렉터리와 함께 생성합니다. 그리고, 이 사이트는 8080 포트를 통해 HTTP 프로토콜을 사용하도록 설정되며, 물리적인 경로는 d:\inetput\wwwroot\racing 디렉터리로 정의됩니다.

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Web.Administration;

namespace MSWebAdmin_Application
{      
    class Program
    {
        static void Main(string[] args)
        {
            ServerManager serverManager = new ServerManager();
            Site mySite = serverManager.Sites.Add("Racing Cars Site", "d:\\inetpub\\wwwroot\\racing", 8080);
            mySite.ServerAutoStart = true;
            serverManager.CommitChanges();
        }
    }
}

ServerManager 클래스는 강력한 유형으로 사용할 수 있는 속성들과 메서드들을 갖고 있는 편리한 서버 개체들을 포함하고 있는 팩터리 클래스입니다. 이 클래스는 서버 관리를 위해 가장 중요한 진입점입니다. 물론 서버 관리는 다른 비효율적인 방법을 통해서도 (구성 설정 XML 에 직접 접근하거나 상태 APIs 를 호출하는 것과 같은) 이루어질 수도 있습니다만, 이와 같은 개체들을 사용하는 것이 서버 관리를 위한 보다 효과적인 방법입니다. ServerManager 클래스를 이용하여 사용이 가능한 가장 보편적인 개체들의 집합에는, 응용 프로그램, 가상 디렉터리, 사이트, 작업자 프로세스, 그리고 응용 프로그램 도메인 등이 있습니다.

ServerManager serverManager = new ServerManager();

Sites 컬렉션을 사용하면 특정 사이트의 속성과 응용 프로그램에 접근할 수 있습니다. 그리고, 이 컬렉션에는 시스템에 사이트를 추가하거나 시스템에 존재하는 모든 사이트들의 갯수를 얻는 등과 같은 작업을 처리하기 위한 메서드들도 존재합니다. Add 메서드는 사이트의 이름과 루트 가상 디렉터리 경로, 그리고 정수형의 포트 번호를 인자로 받습니다. 그리고, 그 실행 결과인 사이트 개체의 인스턴스를 mySite 개체 변수에 리턴하고, 이 개체의 프로퍼티들을 직접 수정하여 새로 생성된 사이트를 대상으로 작업을 수행할 수 있습니다.

Site mySite = serverManager.Sites.Add("Racing Cars Site", "d:\\inetpub\\wwwroot\\racing", 8080);

이러한 편리한 개체들은 속성의 수정을 간단하게 만들어줍니다. 특정 XML 특성이나 항목들의 의미를 모르고 있다고 하더라도 mySite 개체의 속성들에 접근하여 사이트의 자동-시작 속성을 직접 "true" 로 설정하는 등과 같은 작업이 가능합니다.

mySite.ServerAutoStart = true;

또는, 사이트 개체의 인스턴스를 명시적으로 생성하지 않고 자동-시작 속성을 수정할 수 있는 다른 방법도 존재하는데, 이 경우 사이트 정보를 페치하여 임시 개체를 생성하고 직접 그 속성을 수정하게 됩니다. 관리 개체는 인덱서의 개념을 사용함으로써 전체 개체 집합의 목록을 가져오기 위한 고비용의 호출을 발생시키지 않으면서도 이름이나 인덱스와 같은 키를 통해서 특정 개체를 조회합니다. 다음의 코드에서는 이름을 사용하여 특정 개체를 얻고, 해당 개체에 대한 작업을 수행하고 있습니다.

serverManager.Sites["Racing Cars Site"].ServerAutoStart = true;

변경 사항을 반영하기 위해서, CommitChanges 메서드를 실행시키면 작업 결과가 구성 설정 파일로 직렬화되고, 변경된 사항이 존재하는 경우, 디스크에 기록됩니다.

serverManager.CommitChanges();

지금까지 살펴본 코드를 실행시키면 applicationHost.config 파일의 <sites> 섹션에 다음과 같은 결과를 생성하게 됩니다. 구성 설정 XML 을 항목이나 특성 수준에서 직접 조작하기 보다는, 웹 서버를 관리하기 위해 서버 관리 개체들이 제공해주는 보다 편리한 방법을 사용하십시오.

<site name="Racing Cars Site" id="2" serverAutoStart="true">
     <application path="/">
         <virtualDirectory path="/" physicalPath="d:\inetpub\wwwroot\racing" />
     </application>
     <bindings>
         <binding protocol="http" bindingInformation=":8080:" />
     </bindings>
</site>


새로운 응용 프로그램 풀 생성

다음의 코드는 기존의 “Racing Cars Site” 의 이름을 변경하고 물리적인 경로를 d:\inetput\wwwroot\racing 로 수정합니다. 그리고, 새로운 응용 프로그램 풀을 생성하여 몇 가지 속성들을 설정한 다음, 사이트가 이 응용 프로그램 풀을 사용하도록 설정하고 최종적으로는 응용 프로그램 풀을 재생시킵니다.

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Web.Administration;

namespace MSWebAdmin_Application
{      
    class Program
    {
        static void Main(string[] args)
        {
            ServerManager serverManager = new ServerManager();
            Site site = serverManager.Sites["Racing Cars Site"];
            site.Name = "Racing Site";
            site.Applications[0].VirtualDirectories[0].PhysicalPath = "d:\\racing";
            serverManager.ApplicationPools.Add("RacingApplicationPool");
            serverManager.Sites["Racing Site"].Applications[0].ApplicationPoolName = "RacingApplicationPool";
            ApplicationPool apppool = serverManager.ApplicationPools["RacingApplicationPool"];
            apppool.ManagedPipelineMode = ManagedPipelineMode.ISAPI;

            serverManager.CommitChanges();

            apppool.Recycle();
        }
    }
}

사이트를 페치하기 위해 인덱싱을 하는 대신, 사이트 개체 인스턴스를 생성하고 그 참조를 설정할 수도 있습니다. 일단 참조가 설정되면, 해당 개체의 속성을 참조하거나 메서드를 호출할 수 있으며, 이 경우에는 사이트 이름이 그 작업 대상으로서 직접 속성을 사용하여 그 이름을 변경하고 있습니다.

Site site = serverManager.Sites["Racing Cars Site"];
site.Name = "Racing Site";

다음은 인덱서를 사용하는 또 다른 사례로서, 루트 응용 프로그램을 얻은 다음 다시 루트 디렉터리를 얻고 그 물리적인 경로를 설정합니다.

site.Applications[0].VirtualDirectories[0].PhysicalPath = "d:\\racing";

또한 사이트 개체 외에도, 상태 메서드와 데이터 뿐만 아니라 구성 설정 속성들을 편리하게 얻거나 설정할 수 있는 방법을 제공해주는 응용 프로그램 풀 개체를 얻습니다. 다음 코드에서는 새로운 응용 프로그램 풀이 생성되고, 그 즉시 사이트가 그 응용 프로그램 풀에 추가됩니다.

serverManager.ApplicationPools.Add("RacingApplicationPool");
serverManager.Sites["Racing Site"].Applications[0].ApplicationPoolName = "RacingApplicationPool";

여러분들은 서버 관리자 사이트 개체를 사용하는 경우와 마찮가지로, 서버 관리자 응용 프로그램 풀 개체를 사용하여 응용 프로그램 풀을 생성하고 참조를 설정할 수 있습니다. 물론 속성들을 얻거나 설정할 수도 있으며 메서드를 호출할 수도 있습니다. 업데이트 호출을 통해 응용 프로그램 풀 구성 설정 데이터가 파일로 직렬화되고 나면, 여러분들은 바로 재생 메서드를 실행시킬 수 있습니다. 이 재생 작업은 필수적인 것은 아니며, 해당 응용 프로그램 풀은 이제 막 생성되었으므로 그다지 필요한 작업은 아닙니다. 그러나, 여기에서는 방금 생성된 개체에 대한 작업은 반드시 그 개체가 디스크로 직렬화되고, 서버가 해당 구성 설정을 페치할 수 있어야만 재생 작업이 실행 가능하다는 점을 보여주고 있습니다.

ApplicationPool apppool = serverManager.ApplicationPools["RacingApplicationPool"];
apppool.ManagedPipelineMode = ManagedPipelineMode.ISAPI;

serverManager.CommitChanges();

apppool.Recycle();

지금까지 살펴본 코드를 실행시키면 applicationHost.config 파일의 <sites> 섹션에 다음과 같은 결과를 생성하게 됩니다. 구성 설정 XML 을 항목이나 특성 수준에서 직접 조작하기 보다는, 웹 서버를 관리하기 위해 서버 관리 개체들이 제공해주는 보다 편리한 방법을 사용하십시오.

<site name="Racing Site" id="2" serverAutoStart="true">
    <application path="/">
        <virtualDirectory path="/" physicalPath="d:\racing" />
    </application>
    <bindings>
        <binding protocol="http" bindingInformation=":8080:" />
    </bindings>
</site>

또한, <applicationPools> 섹션에는 다음과 같은 항목이 추가되어집니다.

<add name="RacingApplicationPool" managedPipelineMode="ISAPI" />


사이트 루트 web.config 구성 설정

다음의 코드는 "Default Web Site" 사이트의 <defaultDocument> 섹션의 “enabled” 특성값을 false 로 설정합니다.

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Web.Administration;

namespace MSWebAdmin_Application
{
    class Program
    {
        static void Main(string[] args)
        {
            ServerManager serverManager = new ServerManager();
            Configuration config = serverManager.GetWebConfiguration("Default Web Site");
            ConfigurationSection section = config.GetSection("system.webServer/defaultDocument");
            ConfigurationAttribute enabled = section.GetAttribute("enabled");
            enabled.Value = true;

            serverManager.CommitChanges();
        }
    }
}

Configuration 클래스는 시스템의 구성 설정 섹션들에 대한 접근을 제공해주는 클래스입니다. 여러분들은 구성 설정을 가져오기 위해 제공되는 다양한 메서드들을 호출하여 applicationHost.config, web.config, administration.config 또는 임의의 다른 구성 설정 파일들에 접근할 수 있습니다. 특히 GetWebConfiguration 메서드를 호출하면 지정한 사이트의 (이 경우에는 Default Web Site) 특정 경로에 대한 (이 경우에는 root) web.config 파일을 얻을 수 있습니다.

Configuration config = serverManager.GetWebConfiguration("Default Web Site");

일단 web.config 파일을 얻고 나면 (만약 파일이 존재하지 않는다면 새로 생성됩니다.) 섹션을 가져오기 위한 호출이 생성됩니다. 우리는 <defaultDocument> 섹션을 비활성화하기 위해 찾고 있습니다. 만약 web.config 파일이 존재하지 않거나, 존재하기는 하지만 파일에 <defaultDocument> 섹션이 명시적으로 설정되어 있지 않다고 하더라도, 여전히 사이트 수준에서 실질적인 구성 설정으로 작용합니다. 이 섹션은 계층적으로 상속되며 재정의 가능한 구성 설정이기 때문입니다.

ConfigurationSection section = config.GetSection("system.webServer/defaultDocument");

여러분들은 섹션 개체의 메서드를 호출하여 enabled 특성을 개체로 가져오고, 이 개체의 Value 속성을 통해서 그 값을 설정할 수 있습니다. 그런 다음, 서버 관리자 개체의 CommitChanges 메서드를 호출하기만 하면 변경 사항들이 직렬화되어 디스크에 저장되고, 즉시 서버로 반영됩니다. 만약, 해당 시점에 구성 설정 개체 인스턴스가 여러개 존재하고 있다면, 서버 관리자 개체의 CommitChanges 메서드 호출은 모든 인스턴스의 변경 사항들을 디스크로 저장하게 됩니다.

ConfigurationAttribute enabled = section.GetAttribute("enabled");
enabled.Value = true;
 
serverManager.CommitChanges();

또 다른 방법으로 인덱서를 사용하여 섹션에서 특성 정보를 읽고 쓸 수도 있습니다. 다음의 코드 라인은 먼저 섹션 개체를 얻은 다음, enabled 특성의 값을 설정할 때 사용이 가능합니다.

section["enabled"] = true;

결과적으로 지정한 사이트의 web.config 파일에는 해당 구성 설정이 이루어지게 됩니다.


사이트 구성 설정을 applicationHost.config 에 설정하기

다음의 코드는 "Default Web Site" 사이트의 <defaultDocument> 섹션의 “enabled” 특성값을 false 로 설정합니다.

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Web.Administration;

namespace MSWebAdmin_Application
{
    class Program
    {
        static void Main(string[] args)
        {
            ServerManager serverManager = new ServerManager();
            Configuration config = serverManager.GetApplicationHostConfiguration();
            ConfigurationSection section = config.GetSection("system.webServer/defaultDocument",
                "Default Web Site");
            ConfigurationAttribute enabled = section.GetAttribute("enabled");
            enabled.Value = false;

            serverManager.CommitChanges();
        }
    }
}

이 코드는 바로 위에서 설명했던 작업 내용과 사실상 정확하게 동일한 작업을 수행하고 있으며, 단지 유일한 차이점은 구성 설정 관리자가 applicationHost.config 파일을 가져오기 위해 GetApplicationHostconfiguration 메서드를 호출한다는 점 뿐입니다. 섹션을 가져오기 위해 메서드를 호출할 때, 읽고 쓰기 위한 섹션과 해당 섹션의 위치 경로도 함께 지정한다는 점에 주의하십시오.

Configuration config = serverManager.GetApplicationHostConfiguration();

결과적으로 applicationHost.config 파일에는 location 태그를 통해 지정된 사이트에 대한 구성 설정이 반영되어 집니다.

출처 : 한국 마이크로소프트 MSDN (2007년 2월)
Posted by 상현넘™

댓글을 달아 주세요

서론

IIS 7.0 에서도 여전히 레거시 구성 설정 스크립트와 응용 프로그램들을 사용할 수 있습니다. 이것이 가능한 이유는 메타베이스 시스템과 그에 대한 프로그래밍 인터페이스인 Admin Base Objects (ABO), 그리고 그 상위에 존재하는 ADSI 제공자와 WMI 제공자를 사용할 수 있게 해주는 선택적 설치 구성 요소가 존재하기 때문입니다. 시스템은 ABO 에 대한 호출을 가로채어 이를 새로운 구성 설정 시스템으로 맵핑합니다. 데이터는 applicationHost.config 파일에 저장되지만, ABO 호출자는 레거시 구성 설정 구조 뷰의 형태로 데이터를 출력합니다.

전제조건

  1. 반드시 IIS 가 머신에 설치되어 있어야만 합니다. 예를 들어서, 인터넷 익스플로러의 주소창에 http://localhost/ 라고 입력했을 때, "환영합니다." 페이지가 나타나야만 합니다. 만약 IIS 가 설치되어 있지 않다면 설치 방법에 관한 문서를 참고하여 IIS 를 설치합니다.
  2. 먼저 여러분들이 머신에 대한 관리자 권한을 갖고 있는지를 확인하십시오. 만약 여러분들이 내장된 Administrator 계정 이외의 계정으로 로그온했다면, 비록 해당 계정이 머신의 로컬 Administrators 그룹에 추가되어 있는 계정이라고 하더라도 기본적으로 관리자 권한을 갖고 있지 않은 것으로 간주됩니다. (이 기능은 LUA 라고 불리우는 Longhorn 에서 제공되는 새로운 보안 관련 기능으로서, 본문에서 다루고자 하는 범위를 벗어나는 주제입니다.) 내장된 Administrator 계정으로 로그온하거나, 또는 필요하다면 “runas” 명령줄 도구를 사용하여 명시적으로 응용 프로그램을 내장된 Administrator 계정의 권한으로 실행시키십시오. 예를 들어, notepad.exe 를 실행시키기 위해서 “runas /user:administrator notepad.exe” 와 같은 명령어를 실행시킬 수 있습니다. 이 명령어를 실행하면 Administrator 계정의 비밀번호 입력을 위한 대화 상자가 나타날 것입니다. 아니면 “runas /user:administrator cmd.exe” 명령어를 실행하여, 미리 관리자 권한을 가진 명령 프롬프트를 실행하는 것도 또 다른 방법입니다. 이 명령 프롬프트에서 실행되는 응용 프로그램들 역시 모두 관리자 권한으로 실행되며, 명렴 프롬프트에서 “runas” 구문을 사용할 필요가 없어집니다.
  3. 반드시 마스터 구성 설정 파일을 백업하도록 하십시오. 단지 applicationHost.config 파일을 다른 이름으로 복사해 놓기만 하더라도, 나중에 원상태로 복구가 가능합니다. 이 applicationHost.config 파일은 %windir%\system32\inetsrv\config 디렉터리에서 찾을 수 있습니다. 이 작업을 처리하기 위해서는 방금 위에서 설명한 관리자 권한이 필요하다는 점에 주의하십시오.
  4. 본격적인 작업을 시작하기 전에 시스템이 "깨끗한 상태" 가 되도록 하십시오. 이를 위해서, 지금까지 이루어진 applicationHost.config 파일에 대한 모든 변경 사항들을 원래대로 돌려 놓으십시오. (만약, 여러분들이 VPC 이미지를 사용중이라면, 가장 손쉬운 방법은 변경된 상태를 저장하지 않고 이미지를 재시작하는 것입니다.)
  5. 문제점이 발생하면 빨리 대응이 가능하도록 가급적 인터넷 익스플로러의 "HTTP 오류 메시지 표시" 기능을 (도구 > 인터넷 옵션 > 고급) 꺼놓는 것을 권장합니다.
  6. 주의 : .html 파일로부터 텍스트를 복사하는 경우, 숨겨진 문자들까지도 함께 복사가 됩니다. 따라서 여러분들이 복사한 텍스트를 비주얼 스튜디오 같은 편집기, 또는 명령 프롬프트에 붙여 넣으면 겉으로 보기에는 정상적으로 복사가 된 것처럼 보이지만, 숨겨진 문자들을 포함하고 있기 때문에 적절하게 동작을 하지 않게 됩니다. 그래서, 결과적으로는 문제점을 발견해 내기가 매우 어려워집니다. 이 문제를 해결하기 위한 가장 좋은 방법은 복사한 텍스트를 먼저 노트패드에 붙여 넣은 뒤에 노트패드에 복사된 텍스트를 다시 한 번 복사하는 것입니다. 이렇게 하면 숨겨진 문자들이 제거됩니다. 만약 텍스트가 짧다면, 복사해서 붙여 넣는 것이 아니라 여러분들이 직접 타이핑하여 입력하는 것이 더 간단할 수도 있습니다.

Windows Vista Starter 에디션과 Home 에디션은 웹 응용 프로그램을 실행하거나 웹 배포를 할 필요가 없는 가정과 개인 사용자들을 대상으로 하고 있습니다. IIS 7 웹 서버와 FTP 서버의 기능들은 이 에디션들에서는 사용할 수 없습니다. 그렇지만, 만약 자세하게 살펴본다면 여러분들은 이 에디션들에 설치할 수 있는 IIS 7 의 특정 구성 요소들을 발견할 수 있을 것입니다. 그러나, 이런 컴포넌트들을 설치한다고 하더라도, 정적 콘텐츠나 클래식 ASP, 또는 ASP.NET 등을 지원하는 웹 서버 기능이 제공되지는 않는다는 점에 주의하시기 바랍니다.

이 에디션들에서 사용 가능한 IIS 7 의 구성 요소들은 마이크로소프트의 Windows Communication Foundation (WCF) 기반 구조를 지원하기 위한 목적으로 제공되는 것입니다. 이러한 기반 구조를 제공하는 IIS 7 의 구성 요소들을 통칭하여 Windows 프로세스 활성화 서비스 (WAS) 라고 합니다. 그러나, WCF 기반의 응용 프로그램을 설치할 때 사용자가 명시적으로 WAS 를 설치할 필요는 없으며, 필요한 경우 WCF 에 의해서 자동으로 설치됩니다.

Vista Starter 에디션과 Home 에디션의 IIS 7 동시 요청 처리 제한값은 3 개 입니다.

이 에디션에서 사용할 수 있는 IIS 7 기능들의 목록은 본문 하단의 기능 정리표를 참고하시기 바랍니다.


ABO를 사용한 가상 전역 설정 기록

이번 단계에서는 AdminBaseObjects (ABO) 인터페이스를 사용하여 전역 설정값을 변경하고, 변경된 값을 applicationHost.config 파일에 기록하는 방법에 대해 살펴봅니다. 이러한 작업을 위해 MBExplorer.exe 도구를 사용할 것입니다.

먼저 IIS 7.0 의 메타베이스 호환성 구성 요소가 머신에 설치되어 있는지부터 확인하시기 바랍니다. 이 구성 요소는 기본적으로 설치되지 않습니다. Longhorn Server 에서는 서버 관리자 도구를 (시작->관리 도구->서버 관리자) 이용하여 "IIS 6.0 메타베이스 호환성" 구성 요소가 설치되어 있는지 확인할 수 있습니다. 아니면, 명령 프롬프트상에서 "net start iisadmin" 명령을 실행하여 IISADMIN 이라는 이름의 NT 서비스가 구동중인지 확인하십시오. 이 명령을 실행했을 때 IISADMIN 이 이미 실행되었다는 메시지가 나타나야만 합니다.

그 다음에 MBExplorer 도구를 웹으로부터 다운로드합니다. MSN 서치 등의 검색 엔진을 이용해서 이 도구를 찾다보면, 결국 여러분들은 Microsoft.com 의 다운로드 센터로 이동하게 되는데, 이 다운로드 센터에서 IIS 6.0 리소스 킷을 다운로드하고 설치해야 합니다. MBExplorer 도구는 바로 이 리소스 킷에 포함되어 있습니다. 정상적으로 설치를 마치고 나면 일반적으로 %ProgramFiles%\IIS Resources\Metabase Explorer\ 폴더에서 MBExplorer 도구의 실행 파일인 MBExplorer.exe 파일을 찾을 수 있습니다.

먼저 MBExplorer.exe 도구를 실행합니다. 이 도구는 AdminBaseObjects (ABO) 인터페이스의 최상단에서 동작하며, 그렇기 때문에 ABO 를 통해 얻어진 구성 설정 계층 정보를 보여줍니다.

좌측 패인에서, LM > W3SVC 노드를 찾습니다. 이 노드는 ABO 뷰 상에서 전역 수준의 구성 설정 계층을 나타내는 노드입니다.

이제 우측 패인에서 AuthFlags 속성을 선택합니다. 목록에서 Name 컬럼 헤더를 마우스로 클릭하여 속성들을 정렬하면 손쉽게 이 속성을 찾을 수 있습니다. 이 속성의 기본값은 5 입니다.


<메타베이스 탐색기>

이 값을 1 에서 7 사이의 정수를 입력하여 변경합니다.

노트패드 같은 텍스트 편집기를 사용하여 다음의 경로에 위치해 있는 ApplicationHost.config 파일을 엽니다.

%windir%\system32\inetsrv\config\ApplicationHost.config

그리고, 이 파일에서 <authentication> 섹션 그룹을 찾습니다. 이 섹션 그룹 하위에 존재하는 인증 섹션들은 여러분들이 설정한 값에 따라서 각각 활성화되거나 비활성화 되어 있을 것입니다. 예를 들어서, 만약 여러분들이 AuthFlags의 값을 2 로 설정했다면, BasicAuthentication 섹션의 enabled 속성값만 true 로 설정되어 있고, 다른 모든 인증 섹션들의 enabled 속성값은 false 로 설정되어 있을 것입니다. 왜냐하면 IIS 6.0 스키마상에서 값 "2" 가 "AUTH_BASIC" 와 매핑되어 있기 때문입니다.

다시 MBExplorer 를 사용하여 이 속성의 값을 바꿔보고 ApplicationHost.config 파일의 내용을 다시 확인해 보십시오. 메타베이스의 AuthFlags 속성값이 변경됨에 따라, 간접적으로 ApplicationHost.config 파일의 인증 스키마들이 활성화되거나 비활성화 되는 것을 확인할 수 있습니다.


ABO를 사용한 가상 디렉터리 설정 기록

이번 단계에서는 ABO 를 사용하여 가상 디렉터리의 속성값을 변경하고, 변경된 값을 applicationHost.config 를 통해서 확인하는 방법에 대해 살펴볼 것입니다. 여러분들이 변경하게 될 내용은 전역 설정에 해당하는 영역이 아니므로, ABO 호환성 계층은 applicationHost.config 파일 내부에 변경된 가상 디렉터리에 대응하는 경로가 포함된 새로운 location 태그를 생성하게 됩니다. 어떠한 web.config 파일도 메타베이스 호환성 구성 요소에 의해 변경되지 않는다는 점을 주의하십시오.

먼저 MBExplorer.exe 도구를 실행합니다.

좌측 패인에서, LM > W3SVC > 1 > ROOT 노드를 찾습니다. 이 노드는 기본 웹 사이트의 루트 응용 프로그램을 나타내는 노드입니다.

이제 AuthFlags 속성값을 설정합니다. 우측 패인에 AuthFlags 속성이 이미 존재한다면 이 과정을 생략할 수 있습니다. 좌측 패인에서 ROOT 노드를 선택하고 Edit 메뉴에서 New > DWORD Record 메뉴를 실행한 다음, Record Name or Identifier 입력란에 6000 을 입력합니다.


<메타베이스 탐색기>

이 작업은 기본값으로 0 이 설정된 AuthFlags 속성을 ROOT 노드에 생성합니다. 오른쪽 패인에서 이 속성을 더블 클릭하고 1 에서 7 사이의 정수를 입력하여 값을 변경합니다.

노트패드 같은 텍스트 편집기를 사용하여 다음의 경로에 위치해 있는 ApplicationHost.config 파일을 엽니다.

%windir%\system32\inetsrv\config\ApplicationHost.config

파일의 마지막 부분을 살펴보면, 여러분들이 설정한 값에 따라 활성화되거나 비활성화 된 authentication 섹션들을 포함한 새로운 <location path="Default Web Site"> 태그를 발견할 수 있을 것입니다.

요약

본문에서 여러분들은 구성 설정 시스템의 호환성 기능을 활성화하고 사용하는 방법에 대해서 살펴보았습니다. 여러분들은 레거시 도구를 사용하여 전역 수준이나 가상 디렉터리 수준의 설정들을 변경할 수 있으며, 이런 방법으로 변경된 내용은 applicationHost.config 파일에 기록됩니다. 여러분들은 맵핑과 기록을 위해서 adsutil.vbs 와 같은 다른 도구들을 사용하고 싶을 수도 있습니다. 또는 기존의 ABO/ADSI/WMI 스크립트들이나 응용 프로그램을 새로운 환경에서도 계속해서 사용할 수 있다는 사실을 확인하고 싶을 수도 있습니다. 또한, 본문에서 살펴본 방법과는 정반대의 방법으로도 동일한 실험을 해 볼 수 있는데, 먼저 applicationHost.config 파일의 값을 변경한 다음에 그 반영된 결과를 MBExplorer 를 비롯한 ABO 를 사용하는 도구들 및 스크립트를 통해서 확인한 수 있습니다.

출처 : 한국 마이크로소프트 MSDN (2006년)

Posted by 상현넘™

댓글을 달아 주세요

개요

다음은 ASP.NET v1.1 을 IIS7 에 설치하기 위한 5 가지 단계입니다.

  • "IIS 메타베이스 호환성" 이 설치되어 있는지 확인합니다.
  • .NET 프레임워크 v1.1 과 .NET 프레임워크 v1.1 SP1 을 설치합니다.
  • ASP.NET v1.1 ISAPI 익스텐션을 활성화합니다.
  • .NET 프레임워크 v1.1 의 machine.config 파일에 system.webServer 라는 이름으로 IgnoreSection 헨들러를 추가합니다.
  • 여러분들의 사이트나 응용 프로그램을 .NET 프레임워크 v1.1 응용 프로그램 풀로 이동합니다.

단계 1: "IIS 메타베이스 호환성" 설치

반드시 IIS 메타베이스 호환성이 설치되어 있어야만, .NET 프레임워크 v1.1 설치 프로세스가 Longhorn Server 에 ASP.NET v1.1 을 정상적으로 설치할 수 있습니다.

만약, 여러분들이 Longhorn Server 상에서 작업을 하고 있다면, 시작을 통해서 서버 관리자를 실행하십시오. 서버 관리자의 좌측 트리뷰에서 서버 관리자 노드를 확장하고 역할 관리를 클릭해보면, Web Server (IIS) 노드를 찾을 수 있습니다. 이 노드를 선택하고 우측 패인을 살펴보면 역할 서비스 추가라는 옵션이 존재합니다. 여러분들은 이 옵션을 사용하여 "IIS 메타베이스 호환성" 을 설치할 수 있는 마법사를 실행시킬 수 있습니다.



만약, 여러분들이 Windows Vista 상에서 작업을 하고 있다면, 시작을 클릭한 다음 제어판을 클릭하여 열고, 프로그램 항목에서 Windows 기능 사용/사용 안 함을 클릭하여 Windows 기능 대화 상자를 실행합니다. 이 대화 상자에서 인터넷 정보 서비스 (IIS) 부분을 살펴보고 "IIS 메타베이스 호환성" 을 설치하십시오.

단계 2: .NET 프레임워크 v1.1 과 .NET 프레임워크 v1.1 SP1 설치

다음의 .NET 프레임워크 v1.1 과 SP1, 그리고 ASP.NET 보안 업데이트를 설치하십시오.

여러분들이 .NET 프레임워크 버전 1.1 과 .NET 프레임워크 버전 1.1 서비스 팩 1 을 설치하려고 하면, 다음과 같은 대화 상자가 나타날 것입니다. 그러면 Run program 버튼을 클릭하십시오.



주의: 만약 여러분들이 .NET 프레임워크 버전 1.1 서비스 팩 1 을 설치하지 않는다면, 아마도 다음과 같은 "IIS 작업자 프로세스가 동작을 멈췄습니다." 와 같은 메시지와 더불어 데이터 실행 방지 (DEP) 오류가 발생할 것입니다. 이는 예상된 결과입니다. 이 문제점은 .NET 프레임워크 버전 1.1 서비스 팩 1 을 설치하면 해결됩니다.



단계 3: ASP.NET v1.1 ISAPI 익스텐션 활성화

이에 대한 구체적인 방법을 알아보시려면 IIS 관리자를 사용하여 익스텐션을 활성화 하는 방법 (영문) 온라인 문서를 참고하시기 바랍니다.

익스텐션: C:\Windows\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
주의: 만약 여러분들이 C:\ 드라이브가 아닌 다른 드라이브에 시스템을 설치했다면 위의 경로에서 드라이브를 적절하게 수정해줘야만 합니다.
그룹 아이디: ASP.NET v1.1
설명: ASP.NET v1.1

또는, 다음과 같은 명령 프롬프트 명령어을 실행하여 동일한 작업을 수행할 수 있습니다.

%windir%\Microsoft.NET\Framework\v1.1.4322\aspnet_regiis -enable

단계 4: ASP.NET v1.1 machine.config 파일에 IgnoreSection 헨들러 추가

만약, 여러분들의 ASP.NET v1.1 응용 프로그램에 IIS 에 대한 구성설정 섹션을 가지고 있는 web.config 파일이 존재한다면, 응용 프로그램 구동시에 ASP.NET v1.1 이 런타임 예외를 던질 것입니다. 따라서, ASP.NET v1.1 로 하여금 IIS 관련 구성설정 섹션을 무시하도록 지시하려면, 먼저 .NET 프레임워크 v1.1 의 machine.config 파일을 열고 (%windir%\Microsoft.NET\Framework\v1.1.4322\config\machine.config), 다음 구성설정 섹션 항목을 섹션 태그가 닫히기 직전에 추가하십시오.

  <section name="system.webServer" type="System.Configuration.IgnoreSectionHandler,
    System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
" />
</configSections>

단계 5: ASP.NET 1.1 응용 프로그램 풀로 사이트 또는 응용 프로그램 이동

NET 프레임워크 v1.1 은 설치과정 중, 구동시에 .NET 프레임워크 v1.1 을 로드하도록 구성된 "ASP.NET 1.1" 이라는 이름의 응용 프로그램 풀을 생성합니다. IIS 관리자를 통해서 여러분들의 웹 사이트나 웹 응용 프로그램을 이 응용 프로그램 풀로 이동하는 구체적인 방법에 대해서는 이 온라인 문서 (영문)를 참고하시기 바랍니다. 또는, 명령 프롬프트 상에서 %windir%\system32\inetsrv 디렉터리로 이동하여 다음의 명령어를 실행시켜도 동일한 작업을 수행할 수 있습니다.

appcmd set app "Default Web Site/" /applicationPool:"ASP.NET 1.1"

만약, 여러분들이 .NET 프레임워크 v1.1 을 로드하도록 구성된 새로운 웹 응용 프로그램 풀을 직접 생성하는 방법을 선호한다면, 응용 프로그램 풀 생성 (영문) 온라인 문서를 참고하시기 바랍니다. 명령 프롬프트 상에서 %windir%\system32\inetsrv 디렉터리로 이동하여 다음과 같은 명령어를 실행시켜도 동일한 작업을 수행할 수 있습니다.

appcmd add apppool /name:"NewPool" /managedRuntimeVersion:"v1.1" /managedPipelineMode:"Classic"

출처 : 한국 마이크로소프트 MSDN (2006년)
Posted by 상현넘™

댓글을 달아 주세요

서론

URLScan 은 이전 버전의 IIS 에 애드-온 형태로 제공되던 보안 도구로 관리자들은 이 도구를 사용하여 웹 서버에 엄격한 보안 정책을 적용할 수 있었습니다. IIS 7.0 에서는 URLScan 의 모든 핵심적인 기능들이 요청 필터링이라는 모듈에 병합되었으며 숨겨진 네임스페이스라는 기능이 추가되었습니다. 본문에서는 요청 필터링이 제공하는 각각의 기능들에 대해서 알아보고 여러분들이 접하고 있는 환경에 적용이 가능하도록 실제 상황에서의 예제를 살펴보겠습니다.

이중 인코딩 요청 필터링

기능 개요

이 기능은 이중 인코딩된 요청을 이용한 공격을 방지합니다. 이 시나리오는 공격자가 주의 깊게 만들어진 이중으로 인코딩된 교묘한 요청을 IIS 로 전송하는 경우에 적용됩니다. 이와 같은 공격이 발생한다면 IIS 는 요청이 유효한 경우에만 허용하고 그렇지 않다면 거부할 것입니다. 이 기능이 활성화되면 IIS 는 해당 URL 을 두 번 디코딩하는데, 만약 첫 번째 디코딩 결과와 두 번째 디코딩 결과가 다르다면 요청은 거부되어질 것입니다. 이 기능에 의해서 요청이 거부되면 404.11 오류 코드가 로그에 기록됩니다.

URLScan 의 동일한 기능
이 기능은 URLScan 의 VerifyNormalization 옵션의 기능과 동일합니다.

실제 예제
이 예제에서는 서버 관리자가 서버로 전송되는 이중으로 인코딩된 요청을 결코 허용하지 않기를 원한다고 가정합니다. 이 시나리오를 반영하기 위해 다음과 같은 구성설정을 사용할 수 있습니다.

<configuration>
  <system.webServer>
    <security>
      <requestFiltering allowDoubleEscaping="false"></requestFiltering>
    </security>
  </system.webServer>
</configuration>


최상위 비트 설정 문자 필터링

기능 개요
이 기능은 IIS 로 전달되는 비 ASCII 문자가 포함된 모든 요청들을 허용할지 또는 거부할지를 결정합니다. 이 기능에 의해서 요청이 거부되면 404.12 오류 코드가 로그에 기록됩니다.

URLScan 의 동일한 기능
이 기능은 URLScan 의 AllowHighBitCharacters 옵션의 기능과 동일합니다.

실제 예제
이 예제에서는 서버 관리자가 전체 서버에 전송되는 최상위 비트가 설정된 문자들을 허용하지 않기를 바라지만, 오직 하나의 응용 프로그램에서는 이를 허용하기 원한다고 가정합니다. 이를 위해서 서버 관리자는 applicationHost.config 파일에는 allowHighBitCharacters=”false” 를 설정했지만, 비 ASCII 문자를 받아들이기 바라는 응용 프로그램의 루트 아래에는 web.config 파일을 생성했습니다. 다음의 구성설정이 바로 그 web.config 파일에 사용된 설정입니다.
<configuration>
  <system.webServer>
    <security>
      <requestFiltering allowHighBitCharacters="true"></requestFiltering>
    </security>
  </system.webServer>
</configuration>


파일 확장자에 기반한 필터링

기능 개요

이 기능은 IIS 가 서비스 할 수 있는 파일 확장자들의 집합을 정의합니다. 이 기능에 의해서 요청이 거부되면 404.7 오류 코드가 로그에 기록됩니다.

URLScan 의 동일한 기능

이 기능은 URLScan 의 AllowExtensions 옵션과 DenyExtensions 옵션의 기능과 동일합니다.

실제 예제

이 예제에서는 서버 관리자가 ASP 파일은 서비스 되지 않지만 그 외의 모든 파일들은 서비스 되기를 원한다고 가정합니다. 이를 위해서 서버 관리자는 allowUnlisted 옵션을 “true” 로 설정하고, 명시적으로 서비스 되지 않기를 바라는 ASP 파일을 위해 다음과 같은 파일 확장자 항목을 정의합니다.

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <
fileExtensions allowUnlisted="true" >
          <add fileExtension=".asp" allowed="false" />
        </fileExtensions>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>


요청 제한에 기반한 필터링

기능 개요

이 기능은 다음 세 가지 기능들의 조합으로 이루어집니다.

  • maxAllowedContentLength ? Content-Length 요청 헤더값의 최대 크기를 지정합니다.
  • maxUrl ? 쿼리스트링을 제외한 URL 의 최대 길이를 지정합니다.
  • maxQueryString ? 쿼리스트링의 최대 길이를 지정합니다.

이 기능에 의해서 요청이 거부되면 다음과 같은 오류 코드가 로그에 기록됩니다.

  • 404.13 콘텐츠가 너무 큰 경우
  • 404.14 URL 이 너무 긴 경우
  • 404.15 쿼리스트링이 너무 긴 경우
URLScan 의 동일한 기능

이 각각의 기능들은 URLScan 의 다음 기능들과 동일합니다.

  • maxAllowedContentLength
  • maxUrl
  • maxQueryString
실제 예제

이는 소스 코드에 접근할 수 없는 소프트웨어를 구매하는 기업들에게는 매우 일반적인 상황입니다. 코드에 내제된 취약성들이 발견되었을 때, 그 영향을 받는 코드를 갱신하는 것이 매우 어려울 수도 있습니다. 이러한 취약성들은 대부분 응용 프로그램으로 전송되는 URL 이나 쿼리스트링이 단지 ‘너무 커서’ 또는 ‘콘텐츠가 너무 많아서’ 발생하는 경우가 대부분입니다. 서버 관리자가 안전한 최대값을 결정할 수 있다면, 응용 프로그램의 이진 파일들을 수정하지 않고서도 아래와 같은 구성설정을 사용해서 그 제한값을 적용할 수 있습니다.

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <
requestLimits
          maxAllowedContentLength="30000000"
          maxUrl="260"
          maxQueryString="25" />
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>


HTTP 동사 필터링

기능 개요

이 기능은 IIS 가 요청으로 받아들일 동사들의 목록을 정의할 수 있게 해줍니다. 이 기능에 의해서 요청이 거부되면 404.6 오류 코드가 로그에 기록됩니다.

URLScan 의 동일한 기능

이 기능은 URLScan 의 UseAllowVerbs 옵션, AllowVerbs 옵션, 그리고 DenyVerbs 옵션의 기능과 동일합니다.

실제 예제

이 예제에서는 서버 관리자가 오직 하나의 동사, 즉 GET 동사만 허용하기를 원한다고 가정합니다. 이를 위해서 서버 관리자는 먼저 구성설정 파일에 allowUnlisted=”false” 옵션을 설정하여 명시적으로 지정하지 않은 모든 동사를 허용하지 않도록 설정합니다. 그리고, 그 다음에 허용하고자 하는 동사들의 목록을 명시적으로 지정합니다. 이 예제에서는 오직 GET 동사만을 허용합니다.

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <
verbs allowUnlisted="false">
          <add verb="GET" allowed="true" />
        </verbs>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>


URL 문자열 시퀀스에 기반한 필터링

기능 개요

이 기능은 IIS 가 거부할 문자열 시퀀스의 목록을 정의합니다. 이 기능에 의해서 요청이 거부되면 404.5 오류 코드가 로그에 기록됩니다.

URLScan 의 동일한 기능

이 기능은 URLScan 의 DenyUrlSequences 옵션의 기능과 동일합니다.

실제 예제

이 기능은 매우 강력합니다. 만약 IIS 에 의해 서비스 되지 않기를 바라는 어떤 문자열 시퀀스가 있다면, 그 문자열 시퀀스를 다음과 같이 구성설정에 추가할 수 있습니다.

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <denyUrlSequences>
          <add sequence=".." />
        </denyUrlSequences>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

이 예제에서는 ‘..’ 시퀀스를 거부합니다. 그러나, 보다 현실적인 시나리오는 여러분들이 이미 폐업한 판매자로부터 구매한 응용 프로그램을 갖고 있으며, 특수한 시퀀스의 문자열이 이 응용 프로그램으로 전송되었을 때 문제가 발생할 수 있다는 사실을 발견한 경우입니다. 여러분들은 이 기능을 사용하여 해당 응용 프로그램의 코드를 수정하지 않고서도 단순히 거부 목록에 URL 시퀀스를 추가하는 것만으로 응용 프로그램을 보호할 수 있습니다.


숨겨진 네임스페이스 필터링

기능 개요

이 기능은 ‘서비스 가능한’ 네임스페이스를 (또는 URL 구역) 정의할 수 있도록 해줍니다. 이 기능에 의해서 요청이 거부되면 404.8 오류 코드가 로그에 기록됩니다.

URLScan 의 동일한 기능

이 기능은 IIS 7.0 에서 새롭게 제공되는 기능으로 URLScan 에는 존재하지 않습니다.

실제 예제

이해를 돕기 위해서 서버에 다음과 같은 두 개의 URL 이 존재하는 경우의 예제를 생각해 보겠습니다.

  • http://site.com/bin
  • http://site.com/binary

우리들이 원하는 것은 binary 디렉터리의 콘텐츠들은 서비스를 허용하지만 bin 디렉터리의 콘텐츠들은 서비스를 허용되지 않는 것입니다. 그렇지만, 만약 URL 시퀀스 필터링 기능을 사용하여 “bin” 시퀀스를 거부하도록 설정한다면, 결국 두 개의 URL 이 모두 거부되고 말 것입니다. 다음과 같은 구성설정을 사용하여 오직 bin 디렉터리에 대한 접근만을 거부하고 binary 디렉터리 하위에 존재하는 콘텐츠에 대한 접근은 계속해서 허용하도록 지정할 수 있습니다.

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <
hiddenNamespaces>
          <add hiddenDirectory="BIN" />
        </hiddenNamespaces>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>


요약

이전 버전의 IIS 에서 관리자들은 URLScan 을 사용하여 전역적인 수준의 보안 정책을 정의하고 자신들이 관리하는 시스템에 이를 적용할 수 있었습니다. IIS 7.0 에서 관리자들은 전역적인 수준뿐만 아니라 각각의 URL 들을 대상으로 동일한 정책을 적용할 수 있게 되었으며, 새롭고 풍부한 기능의 대체 모델이 제공하는 이점들을 이용할 수도 있습니다.

본문을 통해서 우리들은 요청이 거부될 때 요청 필터링이 리턴하는 몇 가지 새로운 오류 코드를 살펴보았습니다. 다음은 모든 IIS 로그 오류 코드를 정리한 간단한 참조 목록입니다.

오류

상태 코드

요청된 포트에서 웹 사이트에 액세스할 수 없습니다.

404.1

웹 서비스 확장 잠금 정책으로 인해 이 요청이 거부됩니다.

404.2

MIME 맵 정책으로 인해 요청이 거부됩니다.

404.3

핸들러가 존재하지 않습니다.

404.4

요청 필터링: URL 시퀀스로 인해 요청이 거부됩니다.

404.5

요청 필터링: HTTP 동사로 인해 요청이 거부됩니다.

404.6

요청 필터링: 파일 확장자로 인해 요청이 거부됩니다.

404.7

요청 필터링: 숨겨진 네밍스페이스로 인해 요청이 거부됩니다.

404.8

숨겨진 파일 속성이 설정되어 요청이 거부됩니다.

404.9

요청 필터링: 요청 헤더가 너무 길어서 요청이 거부됩니다.

404.10

요청 필터링: 이중 인코딩된 URL 로 인해 요청이 거부됩니다.

404.11

요청 필터링: 비 ASCII 문자로 인해 요청이 거부됩니다.

404.12

요청 필터링: 콘텐츠 길이가 너무 커서 요청이 거부됩니다.

404.13

요청 필터링: URL 이 너무 길어서 요청이 거부됩니다.

404.14

요청 필터링: 쿼리스트링이 너무 길어서 요청이 거부됩니다.

404.15

출처 : 한국 마이크로소프트 MSDN (2006년)
Posted by 상현넘™

댓글을 달아 주세요

Windows Vista와 Windows Server Longhorn의 에디션에 따른 IIS 7의 차이점 개요

IIS 7 은 Windows Vista 와 Windows Server Longhorn 배포본의 모든 주요 Windows 에디션에서 최초로 사용할 수 있습니다. 그리고, Windows 서버상에서 IIS7 은 지금까지 마이크로소프트가 제공한 적이 없었던 최고의 웹 서버 역할을 제공하게 될 것입니다.

Windows Vista 의 각각의 에디션에서, IIS 7 은 두 가지 역할을 수행합니다. 그 첫 번째로, IIS 7 은 Windows XP 에서와 동일하게 웹 개발자들에게 서버에 배포하기 위한 웹 응용 프로그램 구축과 테스트를 위한 완벽한 웹 플랫폼 경험을 제공합니다. 두 번째로, 프로세스 활성화 및 관리, 그리고 Windows Communication Foundation (.NET 프레임워크 3.0) 을 사용하여 만들어진 연결된 소비자 활성화 시나리오에 필요한 HTTP 기반 구조를 제공합니다.

Windows Vista Starter 에디션과 Home 에디션

Windows Vista Starter 에디션과 Home 에디션은 웹 응용 프로그램을 실행하거나 웹 배포를 할 필요가 없는 가정과 개인 사용자들을 대상으로 하고 있습니다. IIS 7 웹 서버와 FTP 서버의 기능들은 이 에디션들에서는 사용할 수 없습니다. 그렇지만, 만약 자세하게 살펴본다면 여러분들은 이 에디션들에 설치할 수 있는 IIS 7 의 특정 구성 요소들을 발견할 수 있을 것입니다. 그러나, 이런 컴포넌트들을 설치한다고 하더라도, 정적 콘텐츠나 클래식 ASP, 또는 ASP.NET 등을 지원하는 웹 서버 기능이 제공되지는 않는다는 점에 주의하시기 바랍니다.

이 에디션들에서 사용 가능한 IIS 7 의 구성 요소들은 마이크로소프트의 Windows Communication Foundation (WCF) 기반 구조를 지원하기 위한 목적으로 제공되는 것입니다. 이러한 기반 구조를 제공하는 IIS 7 의 구성 요소들을 통칭하여 Windows 프로세스 활성화 서비스 (WAS) 라고 합니다. 그러나, WCF 기반의 응용 프로그램을 설치할 때 사용자가 명시적으로 WAS 를 설치할 필요는 없으며, 필요한 경우 WCF 에 의해서 자동으로 설치됩니다.

Vista Starter 에디션과 Home 에디션의 IIS 7 동시 요청 처리 제한값은 3 개 입니다.

이 에디션에서 사용할 수 있는 IIS 7 기능들의 목록은 본문 하단의 기능 정리표를 참고하시기 바랍니다.

Windows Vista Home Premium 에디션

Windows Vista Home Premium 에디션의 IIS 7 은 비전문적인 웹 개발자들이나 취미로 웹 개발을 하는 개발자들을 지원하기 위한 것으로서, 웹 사이트를 개발하기 위해 반드시 필요한 IIS 7 웹 서버의 대부분의 기능들이 지원됩니다. 그렇지만, 비전문적인 웹 개발에서 보편적으로 사용되지 않는 FTP 서버나 향상된 웹 인증과 권한 부여, 그리고 원격 관리등과 같은 기능들은 Vista Home Premium 에디션에서는 사용할 수 없습니다.

Vista Home Premium 에디션의 IIS 7 동시 요청 처리 제한값은 3 개 입니다.

이 에디션에서 사용할 수 있는 IIS 7 기능들의 목록은 본문 하단의 기능 정리표를 참고하시기 바랍니다.

Windows Vista 프로페셔널 에디션

Windows Vista 프로페셔널 에디션의 IIS 7 은 전문적인 웹 개발자들을 그 직접적인 대상으로 하고 있으며, 전문적인 웹 개발자들이 웹 응용 프로그램을 설계, 개발, 그리고 테스트하기 위해 필요로 하는 모든 기능들을 제공합니다. (여기에서 얘기하고 있는 프로페셔널 에디션에는 Vista Business 에디션, Enterprise 에디션, 그리고 Ultimate 에디션이 포함됩니다.) 원격 관리를 제외한 Windows Server Longhorn 에서 제공하는 모든 IIS 7 의 기능들을 프로페셔널 에디션에서도 동일하게 사용할 수가 있습니다. 그리고, 프로페셔널 에디션에서는 동시 요청을 한 번에 10 개 까지 처리할 수 있습니다.

이 에디션에서 사용할 수 있는 IIS 7 기능들의 목록은 본문 하단의 기능 정리표를 참고하시기 바랍니다.

Windows Server Longhorn 에디션

Windows Server Longhorn 의 IIS 7 은 원격 관리를 비롯한 모든 기능들에 대한 웹 응용 프로그램의 완전한 배포를 위해 준비되었으며, 당연히 동시 요청 처리에도 제한이 존재하지 않습니다.

이 에디션에서 사용할 수 있는 IIS 7 기능들의 목록은 본문 하단의 기능 정리표를 참고하시기 바랍니다.

IIS 7 Vista 에디션별 기능 정리표

화면 출력명 / 계층 패키지 업데이트명 Server Pro Premium Basic & Starter
인터넷 정보 서비스

IIS-WebServerRole

가능 가능 가능 가능
  World Wide Web 서비스

IIS-WebServer

기본 기본 기본 기본
    공통 Http 기능

IIS-CommonHttpFeatures

기본 기본 기본 기본
      정적 콘텐츠

IIS-StaticContent

기본 기본 기본 N/A
      기본 문서

IIS-DefaultDocument

기본 기본 기본 N/A
      디렉터리 나열

IIS-DirectoryBrowsing

기본 기본 기본 N/A
      HTTP 오류

IIS-HttpErrors

기본 기본 기본 기본
      HTTP 리디렉션

IIS-HttpRedirect

가능 가능 가능 가능
    응용 프로그램 개발 기능

IIS-ApplicationDevelopment

가능 가능 가능 가능
      ASP.NET

IIS-ASPNET

가능 가능 가능 N/A
      .NET 확장성

IIS-NetFxExtensibility

가능 가능 가능 가능
      ASP

IIS-ASP

가능 가능 가능 N/A
      CGI

IIS-CGI

가능 가능 가능 N/A
      ISAPI 익스텐션

IIS-ISAPIExtensions

가능 가능 가능 N/A
      ISAPI 필터

IIS-ISAPIFilter

가능 가능 가능 N/A
      Server-Side Includes

IIS-ServerSideInclude

가능 가능 가능 N/A
    상태 진단

IIS-HealthAndDiagnostics

기본 기본 기본 기본
      HTTP 로깅

IIS-HTTPLogging

기본 기본 기본 기본
      로깅 도구

IIS-LoggingLibraries

가능 가능 가능 가능
      요청 진단

IIS-RequestMonitor

기본 기본 기본 기본
      추적

IIS-HttpTracing

가능 가능 가능 가능
      사용자 정의 로깅

IIS-CustomLogging

가능 가능 가능 N/A
      ODBC 로깅

IIS-ODBCLogging

가능 가능 N/A N/A
    보안

IIS-Security

가능 가능 가능 가능
      기본 인증

IIS-BasicAuthentication

가능 가능 가능 N/A
      Windows 인증

IIS-WindowsAuthentication

가능 가능 N/A N/A
      다이제스트 인증

IIS-DigestAuthentication

가능 가능 N/A N/A
      클라이언트 인증서 맵핑 인증

IIS-ClientCertificateMappingAuthentication

가능 가능 N/A N/A
      IIS 클라이언트 인증서 맵핑 인증

IIS-IISCertificateMappingAuthentication

가능 가능 N/A N/A
      URL 인증

IIS-URLAuthorization

가능 가능 가능 가능
      요청 필터링

IIS-RequestFiltering

가능 가능 가능 가능
      IP 보안

IIS-IPSecurity

가능 가능 가능 가능
    성능

IIS-Performance

기본 기본 기본 가능
      정적 콘텐츠 압축

IIS-HttpCompressionStatic

기본 기본 기본 N/A
      동적 콘텐츠 압축

IIS-HttpCompressionDynamic

가능 가능 가능 가능
  웹 관리 도구

IIS-WebServerManagementTools

기본 기본 기본 기본
    IIS 관리 콘솔

IIS-ManagementConsole

기본 기본 기본 N/A
    IIS 관리 스크립트 및 도구

IIS-ManagementScriptingTools

가능 가능 가능 가능
    IIS 관리 서비스

IIS-ManagementService

가능 가능 가능 N/A
    IIS 6 관리 호환성

IIS-IIS6ManagementCompatibility

가능 가능 가능 가능
      IIS 메타베이스 및 IIS 6 호환성

IIS-Metabase

가능 가능 가능 가능
      IIS 6 WMI 호환성

IIS-WMICompatibility

가능 가능 가능 N/A
      IIS 6 스크립팅 도구

IIS-LegacyScripts

가능 가능 가능 N/A
      IIS 6 관리 콘솔

IIS-LegacySnapIn

가능 가능 가능 N/A
  FTP 퍼블리싱 서비스

IIS-FTPPublishingService

가능 가능 N/A N/A
    FTP 서버

IIS-FTPServer

가능 가능 N/A N/A
    FTP 관리 콘솔

IIS-FTPManagement

가능 가능 N/A N/A
Windows 활성화 서비스

WAS-WindowsActivationService

가능 가능 가능 가능
  프로세스 모델

WAS-ProcessModel

기본 기본 기본 기본
  .NET 환경

WAS-NetFxEnvironment

가능 가능 가능 가능
  구성설정 APIs

WAS-ConfigurationAPI

가능 가능 가능 가능
         
 동시 요청 처리 제한값  

제한
없음

10

3

3


요약

본문에서는 Windows Vista 와 Server Longhorn 의 각각의 에디션이 제공하는 IIS 7 의 차이점들에 대해서 살펴보았습니다. 각각의 Windows Vista 와 Windows Server Longhorn 에디션에서 IIS 7 설치를 사용자 정의하는 방법에 대한 추가적인 정보들은 다음의 관련 링크들에서 살펴보실 수 있습니다.

관련 링크

보다 자세한 정보는 다음의 기사들을 참고하십시오.

IIS7 설치 개요 (영문)
Longhorn Server 에서 IIS7 을 설치하는 방법 (영문)
Windows Vista Beta 2 에서 IIS7 을 설치하는 방법 (영문)
명령 프롬프트를 통한 IIS7 설치 방법 (영문)
IIS7 무인 설치 방법 (영문)

출처 : 한국 마이크로소프트 MSDN (2006년)

Posted by 상현넘™

댓글을 달아 주세요

서론

이전 버전의 IIS 에는 설치시에 생성되는 IUSR_MachineName 라는 로컬 계정이 존재했습니다. 이 IUSR_MachineName 계정은 익명 인증이 활성화되어 있는 경우 IIS 에 의해서 기본 신원계정으로 사용되며, FTP 서비스와 HTTP 서비스 모두 이 계정을 사용했습니다. 그리고, 응용 프로그램 풀의 신원 계정으로 사용되는 모든 계정들을 포괄하기 위한 목적으로 IIS_WPG 라는 그룹도 존재했습니다. IIS 가 설치되는 동안 시스템에 존재하는 모든 적절한 리소스에는 IIS_WPG 그룹에 대한 올바른 권한 모음이 설정되었습니다. 그래서, 관리자들은 새로운 응용 프로그램 풀 계정을 생성하면 그 계정을 IIS_WPG 그룹에 추가해야만 했었습니다.

이 모델은 대단히 잘 동작했지만, 대부분의 설계들이 그런 것처럼 이 모델에도 단점은 존재했으며, 그 중에서도 IUSR_MachineName 계정과 IIS_WPG 그룹이 생성된 시스템에 국한되는 계정이라는 점이 가장 큰 단점이었습니다. Windows 의 모든 계정과 그룹은 다른 계정들과 구분되는 SID (Security IDentifier) 라고 불리우는 유일한 번호를 부여받는데, ACL 이 생성될 때 바로 이 SDI 가 사용됩니다. IIS 의 기존 버전에서는 IUSR_MachineName 계정 정보가 metabase.xml 파일에 저장되도록 설계되었는데, 여러분들이 metabase.xml 파일을 한 머신에서 다른 머신으로 복사한다고 하더라도, 대상 머신의 IUSR_MachineName 계정은 본래 머신의 계정과 다른 SID 를 가지고 있기 때문에 IIS 가 곧바로 동작하지 않았습니다. 게다가, 머신과 머신간의 SID 는 서로 다르므로 'xcopy /o' 명령만으로는 한 머신에서 다른 머신으로 ACL 을 복사할 수도 없습니다. 도메인 계정을 사용하는 방법도 있지만, 그렇게 되면 여러분들의 네트워크 기반 구조에 엑티브 디렉터리를 추가해야만 합니다. 그리고, IIS_WPG 그룹도 권한과 관련된 비슷한 문제점을 갖고 있었습니다. 만약 여러분들이 어떤 머신의 파일 시스템에 IIS_WPG 그룹에 대한 ACL 을 설정한 다음, 'xcopy /o' 명령을 사용하여 또 다른 머신으로 복사를 시도한다면 그 작업은 실패하게 될 것입니다. IIS 팀에서는 이러한 문제점에 대한 피드백을 받아들여 내장 계정과 그룹을 사용하여 IIS 7.0 을 개선했습니다.

내장 계정과 그룹은 운영체제 시스템에 의해 언제나 동일한 SID 를 보장받습니다. 그리고, IIS 는 이를 더욱 적극적으로 받아들여 새로운 계정과 그룹의 실제 이름이 결코 지역화되지 않도록 보장합니다. 예를 들어서, 설치된 Windows 의 언어와는 관계없이, 언제나 IIS 계정의 이름은 IUSR 가 되고 그룹의 이름은 IIS_IUSRS 가 됩니다.

이를 정리하면, IIS 7.0 에서는:

  • IUSR 내장 계정이 기존의 IUSR_MachineName 계정을 대체합니다.
  • IIS_IUSRS 내장 그룹이 기존의 IIS_WPG 그룹을 대체합니다.

내장된 계정인 IUSR 계정은 비밀번호가 필요하지 않습니다. 그리고, 여러분들은 논리적으로 이 계정은 NETWORKSERVICE 계정이나 LOCALSERVICE 계정과 동일한 것으로 간주할 수 있습니다. 다음 섹션에서 IUSR 계정과 IIS_IUSRS 그룹에 대해서 보다 깊게 알아보도록 하겠습니다.

새로운 IUSR 계정에 대한 이해

앞에서 설명했던 것과 같이, IIS 7.0 에서는 IUSR 계정이 IUSR_MachineName 계정을 대체합니다. 그러나, IUSR_MachineName 계정도 여전히 생성되고 사용되는데, 이는 오직 FTP 서버가 설치된 경우에만 해당됩니다. 만약 FTP 서버가 설치되지 않는다면 이 계정은 결코 생성되지 않을 것입니다.

IUSR 내장 계정은 비밀번호를 요구하지 않으며 익명 인증이 활성화된 경우 기본 신원계정으로 사용되어집니다. 만약, 여러분들이 applicationHost.config 파일을 살펴본다면 다음과 같이 정의된 부분을 쉽게 찾아보실 수 있을 것입니다.

<anonymousAuthentication enabled="true" userName="IUSR" defaultLogonDomain="" />

이 부분은 우리들이 모든 익명 인증 요청에 대해서 이 새로운 내장 계정을 사용하기를 원한다는 것을 IIS 에게 말해줍니다. 이러한 결과로 우리들이 얻을 수 있는 커다란 이점은 다음과 같습니다.

  • 탐색기나 그 밖의 다양한 명령 프롬프트 도구들을 사용하여 IUSR 계정에 대한 파일 시스템 권한을 설정할 수 있습니다.
  • 더 이상 IUSR 계정의 비밀번호 만료에 대해서 걱정할 필요가 없습니다.
  • 파일들을 소유권 정보와 ACL 정보까지 포함하여 xcopy /o 명령을 통해 다른 머신에 완벽하게 복사할 수 있습니다.

가장 중요한 점은 IUSR 계정이 LOCALSERVICE 계정과 유사하게 네트워크상에서 익명으로 동작한다는 사실입니다. NETWORKSERVICE 계정과 LOCALSYSTEM 계정은 머신의 자격 증명으로 동작할 수 있지만 IUSR 계정은 권한 승격으로 인해서 그럴수가 없습니다. 만약, 여러분들이 익명 계정에 네트워크 권한을 부여하고자 한다면, 기존 버전에서 익명 인증을 위해서 작업했던 것과 같이 새로운 계정을 생성하고 수작업으로 사용자 이름과 비밀번호를 설정해야만 합니다. IIS 관리자를 사용하여 이 작업을 처리하려면:

  • 시작을 클릭한 다음 'INetMgr.exe' 를 입력하고 엔터키를 누릅니다. (만약, 보안 경고 대화 상자가 나타난다면 "계속' 버튼을 선택하여 권한을 승격시키십시오.)
  • "Connections" 섹션에서 여러분들의 머신 이름이 적힌 노드 좌측에 위치한 "+" 버튼을 클릭합니다.
  • 웹 사이트 노드에서 여러분들이 관리하고자 하는 사이트를 더블 클릭합니다.
  • "Feature Name" 이 "Authentication" 인 항목을 더블 클릭합니다.
  • "Anonymous Authentication" 을 선택하고, 화면 오른편에 위치한 "Actions" 섹션에서 "Edit" 버튼을 클릭하여 "Edit Anonymous Authentication Credentials" 대화 상자를 불러옵니다.
  • "Specific User" 옵션을 선택하고 그 옆의 "Set" 버튼을 누릅니다.
  • 원하는 사용자 이름과 비밀번호, 비밀번호 확인을 입력하고 "OK" 버튼을 누릅니다.

새로운 IIS_IUSRS 그룹에 대한 이해

이미 앞에서 설명했던 것처럼, IIS_IUSRS 그룹은 IIS_WPG 그룹을 대체하기 위한 목적으로 만들어 졌습니다. 이 내장 그룹은 필요한 모든 파일과 시스템 리소스에 대한 접근 권한을 갖고 있으며, 바로 그렇기 때문에 어떤 계정이 이 그룹에 포함되면, 아무런 문제없이 응용 프로그램 풀 신원 계정으로 동작할 수 있게 됩니다.

내장 IUSR 계정의 경우와 마찮가지로 내장 IIS_IUSRS 그룹도 몇 가지 XCOPY 배포의 문제점들을 해결해줍니다. 만약, 여러분들이 IIS_WPG 그룹에 대해서 - IIS 6 시스템에서 사용가능한 - 여러분들의 파일에 권한을 설정하고, 그 파일들을 다른 Windows 머신에 복사하려고 한다면, 이 그룹의 SID 는 머신들마다 다르므로 여러분들의 사이트 구성설정은 깨지게 될 것입니다.

그러나, IIS7 에서 IIS_IUSRS 그룹의 SID 는 롱혼이 실행되는 모든 시스템에서 동일하기 때문에, 'xcopy /o' 명령을 사용하여 머신에서 머신으로 파일들을 복사할 때 소유권 정보와 ACL 정보가 그대로 유지됩니다. 결과적으로 XCOPY 배포가 극단적으로 쉬워지는 것입니다.

고객들이 요청한 두 번째 사항은 '응용 프로그램 풀의 신원 계정을 설정하면 IIS 가 사용자를 대신하여 자동으로 필요한 모든 변경작업을 대신 처리해달라.' 라는 것이었습니다. IIS 팀에서는 이 피드백을 수용하여 IIS 7.0 에서는 이 작업을 보다 편리하게 만들었습니다. IIS 가 작업자 프로세스를 시작할 때, 이 작업에는 작업자 프로세스에서 사용될 토큰의 생성이 필요합니다. 이제는 이 토큰이 생성될 때, IIS 가 자동적으로 IIS_IUSRS 그룹의 계정들을 런타임시에 작업자 프로세스 토큰에 추가합니다. 그래서 결과적으로 '응용 프로그램 풀 신원 계정'으로 동작하도록 정의된 계정을 더 이상 명시적으로 IIS_IUSRS 그룹에 포함시킬 필요가 없어졌습니다. IIS 팀에서는 이러한 변화가 여러분들의 시스템 설정을 보다 덜 번거롭도록 도와주고 전반적인 작업을 편리하게 만들어줄 것이라고 믿고 있습니다.

그러나, 만약 여러분들이 이 새로운 기능을 비활성화 시키고 수작업으로 IIS_IUSRS 그룹에 계정을 추가하는 것을 선호한다면, 언제라도 manualGroupMembership 속성의 값을 'true' 로 설정하여 이 새로운 기능을 비활성화시킬 수 있습니다. 다음은 defaultAppPool 을 대상으로 해당 설정을 적용한 예입니다.

<applicationPools>
  <add name="DefaultAppPool">
    <processModel manualGroupMembership="true" />
  </add>
</applicationPools>

출처 : 한국 마이크로소프트 MSDN (2006년)
Posted by 상현넘™

댓글을 달아 주세요

통합된 ASP.NET 모드의 이용

II7 에서 ASP.NET 응용 프로그램은 기본적으로 통합 모드로 실행됩니다. 그렇지만, 견고한 통합이 제공하는 이점을 이용하기 위해서는 응용 프로그램 구성설정을 일부 수정해야만 합니다. 더 나아가, 여러분들의 응용 프로그램에 보다 강력한 기능을 부여하기 위해서 여러분들은 통합 모드를 이용하는 새로운 ASP.NET 구성요소를 개발할 수도 있습니다.

모든 유형의 콘텐츠에 대한 ASP.NET 서비스 활성화

통합 모드에서 ASP.NET 모듈에 의해 제공되는 서비스들은 모든 유형의 콘텐츠 요청을 대상으로 실행될 수 있습니다. 그러나, 하위 호환성을 유지하기 위한 목적 때문에 기본적으로 ASP.NET 모듈은 ASP.NET 콘텐츠에 대한 요청만을 대상으로 실행되도록 구성되어져 있습니다.

이러한 결과는 서버 수준의 구성설정 섹션에 설정된 각각의 ASP.NET 모듈에 추가된 managedHandler 전제 조건 속성값으로 인해 얻어집니다.

<modules>
  <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule"
    preCondition="managedHandler" />
  <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"
    preCondition="managedHandler" />
  
</modules>

이 preCondition 속성은 서버가 해당 모듈이 모든 요청을 대상으로 실행되어야 할지 말아야 할지를 결정하기 위해 사용하는 기준값입니다. managedHandler 속성값은 지금 현재 ASP.NET 핸들러와 맵핑되어 있는 콘텐츠 유형들에 대한 요청에 대해서만 ASP.NET 모듈이 실행되도록 지정합니다.

만약 여러분들이 ASP.NET 모듈이 제공하는 기능을 모든 요청을 대상으로 적용하고 싶다면, 해당 모듈 항목을 제거한 다음, 여러분들의 응용 프로그램의 최상위 web.config 파일에 preCondition 속성만을 제외하여 다시 추가하면 됩니다. 예를 들어서, ASP.NET 폼 기반 인증을 여러분들의 응용 프로그램 전체를 대상으로 적용하고 싶다면 다음과 같이 지정하면 됩니다.

<modules>
  <remove name="FormsAuthentication" />
  <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
  
</modules>

이렇게 변경함으로서 FormsAuthentication 모듈은 여러분들의 응용 프로그램에 대한 모든 요청을 대상으로 동작할 것입니다. 그리고 폼 기반 인증 서비스가 여러분들의 응용 프로그램 콘텐츠 전체를 보호해주게 됩니다. 모든 응용 프로그램 콘텐츠를 대상으로 폼 기반 인증을 제공하기 위해 통합 모드를 활용하는 방법에 대한 보다 많은 정보를 얻으시려면, Taking advantage of Integrated mode walkthrough 를 참고하시기 바랍니다.

그리고, 여러분들이 "managedHandler" 전제 조건에 관계없이, 모든 관리되는 (ASP.NET) 모듈들이 응용 프로그램에 대한 모든 요청을 대상으로 동작하도록 활성화시킬 수 있는 손쉬운 방법도 존재합니다. 각각의 모듈 항목에서 일일이 "managedHandler" 전제 조건을 제거하지 않으면서도 모든 요청을 대상으로 모든 관리되는 모듈을 활성화시키려면, 다음과 같이 <modules> 섹션에 runAllManagedModulesForAllRequests 속성을 추가합니다.

<modules runAllManagedModulesForAllRequests="true" />

이 속성이 사용되면, "managedHandler" 전제 조건은 무시되고 모든 관리되는 모듈들은 모든 요청을 대상으로 동작합니다.

여러분들은 다른 ASP.NET 모듈들이 여러분들의 전체 응용 프로그램에 적용되도록 활성화시는 실험을 해볼 수도 있습니다. 대표적인 경우로, ASP 페이지의 출력을 캐시하기 위해 ASP.NET 출력 캐시 모듈을 적용해본다거나, 여러분들의 사진에 대한 접근 제한 설정을 하기 위해 Url 인증과 역할 관리자를 적용해볼 수도 있습니다. 아니면, 여러분들이 직접 자신만의 모듈을 개발하여 여러분들의 전체 웹 사이트에 ASP.NET 의 기능들을 적용할 수도 있습니다.

보다 강력한 ASP.NET 서비스의 구현

통합 모드에서 ASP.NET 모듈은 모든 콘텐츠를 대상으로 서비스를 제공할 수 있습니다. 게다가 통합 모드에서 ASP.NET 은 통합된 요청 처리 파이프 라인상에서 실행되기 때문에, 네이티브 서버 모듈과 동일한 요청 처리 단계를 구독할 수 있으며 동일한 작업을 수행할 수 있습니다. 또한, ASP.NET APIs 는 이전에는 사용할 수 없었던 몇 가지 중요한 기능들이 제공되는 것을 제외한다면 대부분 예전과 동일합니다.

런타임 충실도

통합 모드상에서 모듈에 노출되어 있는 ASP.NET 요청 처리 단계들은 IIS 파이프 라인의 일치하는 단계에 직접적으로 연결되어 있습니다. 전체 파이프 라인은 다음의 단계들을 포함하고 있으며, 이 단계들은 ASP.NET 상에서 HttpApplication 이벤트로 노출됩니다.

  1. BeginRequest. 요청 처리를 시작합니다.
  2. AuthenticateRequest. 요청이 인증됩니다. 이 단계에서 IIS 와 ASP.NET 인증 모듈이 인증을 수행합니다.
  3. PostAuthenticateRequest
  4. AuthorizeRequest. 요청에 권한이 부여됩니다. IIS 와 ASP.NET 권한 부여 모듈이 인증된 사용자에게 요청된 리소스에 접근할 권한이 있는지 검사합니다.
  5. PostAuthorizeRequest
  6. ResolveRequestCache. 캐시 모듈이 해당 요청에 대한 응답이 이미 캐시에 존재하는지 파악하고, 남아 있는 이후의 단계들을 실행하는 대신 캐시에 존재하는 응답을 리턴할 수 있습니다. ASP.NET 출력 캐시 기능과 새로운 IIS 출력 캐시 기능이 모두 이 단계에서 실행됩니다.
  7. PostResolveRequestCache
  8. MapRequestHandler. ASP.NET 의 내부 단계이며, 요청 핸들러가 결정됩니다.
  9. PostMapRequestHandler
  10. AcquireRequestState. 요청 실행을 위해 필요한 상태를 가져옵니다. ASP.NET 세션 상태, 그리고 프로파일 모듈들이 이 단계에서 데이터를 가져옵니다.
  11. PostAcquireRequestState
  12. PreExecuteRequestHandler. 핸들러가 실행되기 전에 필요한 일련의 작업들이 이 단계에서 실행될 수 있습니다.
  13. ExecuteRequestHandler. 요청 핸들러가 실행됩니다. ASPX 페이지, ASP 페이지, CGI 프로그램, 그리고 정적 페이지들이 이 단계에서 처리됩니다.
  14. PostExecuteRequestHandler
  15. ReleaseRequestState. 변경된 요청 상태가 저장되고 정리됩니다. 이 단계에서 ASP.NET 세션 상태와 프로파일 모듈들의 상태가 정리됩니다.
  16. PostReleaseRequestState
  17. UpdateRequestCache. 다음에 사용될 응답이 캐시에 저장됩니다. 이 단계에서 ASP.NET 출력 캐시와 IIS 출력 캐시 모듈이 각각의 캐시에 응답을 저장하기 위해 실행됩니다.
  18. PostUpdateRequestCache
  19. LogRequest. 요청 처리 결과를 로그에 기록합니다. 만약 오류가 발생하더라도 이 단계는 실행됩니다.
  20. PostLogRequest
  21. EndRequest. 일련의 마지막 처리가 수행됩니다. 만약 오류가 발생하더라도 이 단계는 실행됩니다.

통합 모드에서 실행되는 ASP.NET 요청 처리 단계들이 IIS 모듈과 같은 단계를 공유한다는 사실은, 과거 네이티브 ISAPI 필터나 익스텐션을 사용해서만 가능했던 많은 작업들을, 이제는 친숙한 ASP.NET APIs 와 풍부한 .NET 플랫폼의 기능들을 사용하는 관리되는 코드만으로도 가능하게 만들었습니다. 예를 들어서, 여러분들은 다음과 같은 작업을 처리하는 모듈을 작성할 수도 있습니다.

  1. 요청이 다른 작업에 의해서 처리되기 전에 가로챌 수 있습니다. 예를 들어서 Url 을 다시 기록하거나 보안 필터링을 실행할 수 있습니다.
  2. 기본 제공되는 인증 모드를 교체할 수 있습니다.
  3. 요청 헤더와 같은 들어오는 요청의 내용을 수정할 수 있습니다.
  4. 모든 콘텐츠 유형의 나가는 응답을 필터링할 수 있습니다.

사용자 정의 ASP.NET 인증 모듈을 사용하여 IIS 를 확장하는 훌륭한 샘플을 Developing an IIS7 module with .NET (영문) 에서 살펴볼 수 있습니다.

ASP.NET APIs 확장

여전히 ASP.NET APIs 는 이전 버전과의 하위 호환성을 유지하고 있으며, 이는 기존의 모듈들이 수정없이 IIS7 에서 동작할 수 있도록 해주고 모든 응용 프로그램 콘텐트의 코드 변경을 불필요하게 만들어줍니다.

그렇기는 하지만, IIS7 통합 모드를 위해 작성된 모듈들은 지금까지는 처리가 불가능했던 핵심적인 요청 처리 시나리오를 지원하기 위해 추가된 몇 가지 APIs 의 이점을 얻을 수 있습니다.

이를테면, 새로운 HttpResponse.Headers 컬렉션을 이용하여 다른 응용 프로그램 구성요소에 의해서 생성된 요청 헤더를 모듈로 분석하거나 조작할 수 있습니다. 한 가지 예로, 여러분들은 브라우저에 다운로드 대화상자가 나타나도록 ASP 페이지에서 생성된 Content-Type 헤더를 변경할 수도 있습니다. 더군다나 HttpResponse 클래스가 제공하는 Cookies 컬렉션은 요청 처리 작업의 일부로 만들어진 쿠키의 수정까지도 가능하도록 개선되었으며, 심지어는 쿠키가 ASP.NET 외부에서 생성되었다고 하더라도 변함없이 수정이 가능합니다.

HttpRequest.Headers 컬렉션도 기록이 가능해졌으며 모듈에서 들어오는 요청 헤더를 조작할 수 있게 해줍니다. 이와 같은 변화는 다른 서버 구성요소의 동작을 변경하는데 사용될 수 있습니다. 예를 들어서, 여러분들은 Accept-Language 헤더의 값을 동적으로 변경하여 지역화된 응용 프로그램이 다른 언어를 사용하여 클라이언트에게 응답하게 할 수 있습니다.

마지막으로 HttpRequest.ServerVariables 컬렉션도 역시 기록이 가능해졌으며 IIS 서버 변수들의 값을 설정할 수 있게 되었습니다. ASP.NET 모듈은 IIS 가 제공하는 값들을 변경하거나, PHP 와 같은 다른 응용 프로그램 프레임워크에게 노출하기 위한 목적으로 새로운 서버 변수를 만들어 낼 수도 있습니다.

런타임 통합

새롭게 제공되는 APIs 와 함께, 통합 모드는 기존의 ASP.NET 의 기능들이 여러분들의 응용 프로그램에 보다 많은 가치를 제공해줄 수 있도록 지원해줍니다.

이제 System.Diagnostics.Trace 클래스와 ASP.NET 페이지 추적 기능 등, ASP.NET 으로부터 제공되는 추적 기능들은 추적된 정보를 IIS 추적 시스템으로 출력할 수 있습니다. 결과적으로 IIS 나 ASP.NET 이 요청을 처리하면서 발생한 모든 추적 정보를 단일 로그 파일에 저장할 수 있게 되었으며, 서버상의 문제점들을 분석하기가 더욱 편리해졌습니다.

클라이언트로 응답이 전송되기 전에 스트림 인터페이스를 통해 응답 내용을 수정할 수 있도록 해주는 ASP.NET 의 응답 필터링 기능 역시, 비 ASP.NET 콘텐츠를 대상으로도 동작할 수 있도록 향상되었습니다. 따라서 여러분들은 ASP.NET 필터링을 모든 서버 콘텐츠에 적용하거나, 일부 원하는 유형의 콘텐츠들만을 대상으로 동작하도록 선택적으로 설치할 수 있습니다. 이 기능을 이용하면, 해당 콘텐츠가 ASPX 페이지인지 정적 파일인지 전혀 신경쓰지 않고서도, 여러분들의 사이트 응답에서 임의의 콘텐츠들을 대상으로 주입 또는 검열을 실시하는 필터링 기능을 작성할 수 있습니다.

요약

IIS7 과 ASP.NET 의 통합은 ASP.NET 의 모든 가능성을 활짝 열어주어, 개발자들로 하여금 쉽고 풍부한 기능의 ASP.NET 과 .NET 프레임워크를 사용하여 강력한 서버 구성 요소들을 작성할 수 있도록 해줍니다. 기존 응용 프로그램들을 위한 ASP.NET 통합 모드 활용에 대한 보다 상세한 내용은 통합된 ASP.NET 모드의 이용을 참고하시기 바랍니다. 그리고, 서버 확장을 위한 새로운 ASP.NET 구성요소를 작성하는 방법에 관한 정보는 Developing an IIS7 module with .NET (영문) 을 참고하시기 바랍니다.

출처 : 한국 마이크로소프트 MSDN (2006년 10월)

TAG IIS7
Posted by 상현넘™

댓글을 달아 주세요

호환성

가장 주목할 만한 부분은, 통합된 아키텍처가 기존의 ASP.NET 런타임 아키텍처와 APIs 를 여전히 지원하므로, 기존의 ASP.NET 응용 프로그램과 서비스 대부분이 수정을 거치지 않고서도 정상적으로 동작한다는 점입니다. 게다가 단지 약간의 수정만으로도 새로운 ASP.NET 기능들의 이점을 누리도록 변경할 수 있습니다.

ASP.NET 응용 프로그램을 통합 모드에서 실행할 수 있도록 설정하는 방법에 대한 보다 자세한 정보는 IIS7 통합 모드를 위한 ASP.NET 응용 프로그램의 마이그레이션을 참고하시기 바랍니다.

게다가, 개발자들은 런타임 통합으로 인한 이득을 누리면서도, 계속해서 친숙한 기존의 ASP.NET APIs 를 사용하여 새로운 응용 프로그램을 작성할 수 있습니다.

IIS7 은 통합 모드에서 지원되지 않는 특정한 호환성이 요구되는 ASP.NET 응용 프로그램을 위한 "클래식" ASP.NET 모드를 지원합니다. 관리자는 응용 프로그램 풀 단위로 필요한 통합 모드를 선택할 수 있으며, 결과적으로는 새로운 통합 모드를 사용하는 응용 프로그램과 클래식 ASP.NET 모드를 사용하는 응용 프로그램을 동일한 서버에서 함께 운영할 수 있습니다.

두 가지 ASP.NET 통합 모드간의 전환에 대한 보다 많은 내용을 보시려면 응용 프로그램을 위한 ASP.NET 모드 변경을 참고하시기 바랍니다.


IIS7 통합 모드를 위한 ASP.NET 응용 프로그램의 마이그레이션

기본적으로 IIS7 은 ASP.NET 이 새로운 통합 모드에서 동작하도록 구성되어 있습니다. 따라서, 여러분들의 응용 프로그램은 최소한의 변경만으로도 향상된 통합 모드의 이점을 얻을 수 있습니다.

구성설정이 통합되었기 때문에 일부 응용 프로그램들은 통합 모드에서 운영되기 위해서는 마이그레이션이 필요할 수도 있습니다. 기본적으로 서버는 마이그레이션을 지원하기 위해 응용 프로그램이 마이그레이션을 필요로 하는지를 감지하고, 응용 프로그램을 마이그레이션하기 위해 요구되는 내용들을 오류 메시지로 리턴합니다.

다음과 같은 구성설정은 마이그레이션 오류를 발생시킵니다.

  1. 응용 프로그램의 web.config 파일이 <httpModules> 구성설정 섹션을 정의합니다.
    응용 프로그램이 새로운 ASP.NET 모듈을 로드하거나, 기존 모듈 중 하나를 제거합니다. 통합 모드상에서 ASP.NET 모듈은 네이티브 모듈과 함께 통합된 <system.webServer>/<modules> 구성설정 섹션에 지정됩니다. <system.web>/<httpModules> 구성설정 섹션에 지정된 ASP.NET 모듈이 정상적으로 동작하기 위해서는 새로운 구성설정 섹션으로 이동되어야만 합니다. 새로운 ASP.NET 모듈은 통합된 섹션에 직접 추가되어야만 합니다.
  2. 응용 프로그램의 web.config 파일이 <httpHandlers> 구성설정 섹션을 정의합니다.
    응용 프로그램이 일부 콘텐츠 유형을 대상으로 사용자 정의 핸들러 맵핑을 사용합니다. 통합 모드에서 ASP.NET 핸들러 맵핑이 정상적으로 동작하기 위해서는 통합된 <system.webServer>/<handlers> 구성설정 섹션을 통해 지정되어야만 합니다. 새로운 ASP.NET 핸들러 맵핑은 통합된 <handlers> 섹션에 직접 추가되어야만 합니다. <handlers> 섹션은 이전 버전에서 ASP.NET 핸들러 맵핑을 설정하기 위해 사용되던 ASP.NET <httpHandlers> 구성설정과 IIS 스크립트맵 구성설정을 모두 대체합니다.
  3. 응용 프로그램의 web.config 파일이 <identity impersonate=”true” /> 구성설정 섹션을 정의합니다.
    응용 프로그램이 클라이언트의 신원을 가장합니다. (대부분 인트라넷 응용 프로그램의 경우) 통합 모드에서 클라이언트 신원 가장 기능은 일부 초기 요청 처리 단계에서 사용이 불가능합니다. 이런 경우, 대부분 오류 발생을 무시하도록 설정해도 크게 문제가 되지 않으며, 또는 응용 프로그램이 클래식 ASP.NET 모드에서 실행되도록 구성할 수도 있습니다.

이와 같은 오류가 발생하는 경우, 일반적으로 응용 프로그램의 구성설정을 마이그레이션하거나 (첫 번째나 두 번째 경우 추천), 응용 프로그램이 클래식 ASP.NET 모드를 사용하도록 전환할 수 (세 번째 경우 추천) 있습니다.


응용 프로그램 구성설정 마이그레이션

IIS7 은 마이그레이션 작업을 수행해주는 APPCMD.EXE 명령줄 도구를 통해서 여러분들의 응용 프로그램 마이그레이션 작업을 여러분 대신 처리해줄 수 있습니다. 대부분의 마이그레이션 오류 메시지에는 여러분들의 응용 프로그램을 통합 모드에 알맞게 즉시 마이그레이션 할 수 있게 해주는, 관리자 권한 명령어 실행창에서 실행 가능한 명령어가 포함되어 있습니다.

마이그레이션 명령어의 기본적인 형식은 다음과 같습니다.

%systemroot%\system32\inetsrv\APPCMD.EXE migrate config [Application Path]

[Application Path] 에는, 예를 들어서 “기본 웹 사이트/app1” 과 같은 사이트 이름을 포함한 가상 경로가 위치합니다.

마이그레이션을 마친 뒤, 여러분들의 응용 프로그램은 통합 모드와 클래식 모드 양쪽에서 모두 정상적으로 동작할 것입니다.

일단 마이그레이션을 마친 뒤에는, 여러분들이 다시 구성설정을 변경한다고 하더라도 서버는 다시 마이그레이션을 하라는 메시지를 지원하지 않는다는 점을 명심하시기 바랍니다. 최초의 마이그레이션 작업이 끝난 다음부터 두 모드 사이의 구성설정 동기화에 대한 모든 책임은 여러분들의 몫입니다. – 여러분들은 다시 한 번 APPCMD.EXE 명령줄 도구를 실행하여 수작업으로 응용 프로그램의 마이그레이션을 수행할 수 있습니다.


클래식 ASP.NET 통합 모드 전환

만약 여러분들이 다시 클래식 ASP.NET 모드를 사용하고 싶다면, 그저 간단히 여러분들의 응용 프로그램을 클래식 모드에서 실행되도록 구성된 응용 프로그램 풀로 이동하기만 하면 됩니다. 해당 응용 프로그램 외의 다른 모든 응용 프로그램들은 클래식 모드 응용 프로그램과 함께 여전히 새로운 통합 모드에서 실행될 것입니다.

응용 프로그램을 클래식 ASP.NET 모드로 이동하는 방법에 대한 보다 많은 내용을 보시려면 응용 프로그램을 위한 ASP.NET 모드 변경을 참고하시기 바랍니다.

마이그레이션 오류 메시지 비활성화

만약 여러분들이 수작업으로 응용 프로그램을 마이그레이션하거나, 통합 모드를 사용함에도 불구하고 구성설정을 마이그레이션하고 싶지 않다면 (추천하지 않음), 응용 프로그램의 web.config 파일에 다음과 같은 구성설정 섹션을 추가하여 마이그레이션 오류 메시지를 비활성화 시킬수 있습니다.

<system.webServer>
   <validation validateIntegratedModeConfiguration="false" />
</system.webServer>

주의 : 앞에서 설명한 APPCMD.EXE 명령줄 도구를 사용하여 구성설정을 마이그레이션하고 나면 서버는 자동적으로 오류 메시지를 비활성화 시킵니다. 만약 수작업으로 마이그레이션 오류 메시지를 비활성화 시킨다면, 여러분들은 앞에서 설명했던 지원되지 않는 구성설정에 대한 어떠한 경고 메시지도 더이상 서버로부터 제공되지 않는 상태에서, 응용 프로그램이 통합 모드상에서 적절히 동작하도록 책임져야만 합니다.


응용 프로그램을 위한 ASP.NET 모드 변경

만약 여러분들의 응용 프로그램이 통합된 ASP.NET 모드에서 올바르게 동작하지 않는다면, 응용 프로그램을 다른 응용 프로그램 풀로 이동하여 간단하게 클래식 ASP.NET 모드로 이동할 수 있습니다. 이는 각각의 응용 프로그램 풀이 개별적으로 필요한 통합 모드를 사용하도록 구성되어질 수 있기 때문에 가능한 일입니다. 게다가 이러한 특징은 서로 다른 ASP.NET 통합 모드를 사용하는 응용 프로그램들의 그룹이 동일 서버상에서 함께 실행될 수 있게 해줍니다.

응용 프로그램의 ASP.NET 통합 모드를 변경하려면 다음과 같이 하십시오.

  1. 원하는 모드로 구성된 응용 프로그램 풀을 찾거나 생성하십시오.
    기본적으로 시스템상의 모든 새로운 응용 프로그램 풀은 통합 모드에서 실행됩니다. ASP.NET 은 "Classic .NET AppPool" 라는 이름의 클래식 ASP.NET 통합 모드로 실행되는 응용 프로그램 풀을 제공합니다. 여러분들은 새로운 통합 모드에서 실행되면 안되는 응용 프로그램들을 위해서 이 응용 프로그램 풀을 사용할 수 있습니다. 그리고 여러분들은 IIS7 관리 도구 또는 APPCMD.EXE 명령줄 도구를 사용하거나, 수작업으로 응용 프로그램 풀 구성설정을 변경하여 기존 응용 프로그램 풀의 ASP.NET 모드를 변경할 수도 있습니다.
  2. 해당 응용 프로그램 풀을 사용하도록 응용 프로그램을 설정하십시오.
    각각의 응용 프로그램들은 개별적으로 응용 프로그램 풀을 사용하도록 구성됩니다. 기본적으로 모든 응용 프로그램은 통합 모드에서 동작하는 "DefaultAppPool" 이라는 이름의 기본 응용 프로그램 풀을 사용합니다. 여러분들은 IIS7 관리 도구 또는 APPCMD.EXE 명령줄 도구를 사용하거나, 수작업으로 응용 프로그램의 응용 프로그램 풀 설정을 변경할 수 있습니다.


응용 프로그램을 위한 ASP.NET 버전 선택

역사적으로 IIS 는 여러 버전의 ASP.NET / CLR 을 동시에 지원해 왔으며, 예를 들어 동일한 서버에서 .NET 프레임워크 v1.1 을 사용하는 ASP.NET 응용 프로그램과 .NET 프레임워크 v2.0 을 사용하는 ASP.NET 응용 프로그램이 동시에 실행될 수 있습니다. 이와 같은 지원은 IIS 스크립트맵 구성설정을 기반으로, ASP.NET 콘텐츠 요청을 처리하기 위한 적절한 버전의 ASPNET_isapi.dll 파일이 맵핑됨으로서 제공됩니다.

예를 들어서, 동일한 서버에서 여러 버전의 ASP.NET / CLR 을 동시에 지원하기 위해 다음과 같은 스크립트맵을 구성할 수 있습니다.

  1. ASP.NET v1.1 응용 프로그램인 /app1
    *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
  2. ASP.NET v2.0 응용 프로그램인 /app2:
    *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll

응용 프로그램에 *.aspx 파일에 대한 요청이 도착하면, IIS 는 지정된 aspnet_isapi.dll 파일을 로드하고, 이 로딩된 aspnet_isapi.dll 파일이 올바른 버전의 CLR 을 작업자 프로세스에 로딩함으로서 해당 요청을 처리합니다.

그리고 ASP.NET 은 동일한 서버에서 여러 버전의 ASP.NET / CLR 을 동시에 지원하기 위한 다음과 같은 구성 방법을 제공합니다.

  1. ASP.NET MMC 익스텐션. 사용자가 사용하고자 하는 ASP.NET 의 버전을 지정할 수 있으며, 익스텐션은 자동적으로 응용 프로그램을 위한 올바른 버전의 aspnet_isapi.dll 파일을 지정하여 스크립트맵을 구성하게 됩니다.
  2. ASP.NET aspnet_regiis.exe. ASP.NET aspnet_regiis.exe. 사용자는 적절한 ASP.NET 버전을 지정하는 스크립트맵을 설치하기 위해 -i 와 -r 옵션을 사용할 수 있습니다.

공교롭게도, 단일 작업자 프로세스에는 하나의 CLR 버전만 로드될 수 있다는 제약 때문에, 서로 다른 버전을 사용하는 두 응용 프로그램이 같은 응용 프로그램 풀을 사용하게 구성되지 않도록 주의를 기울여야만 합니다. 그렇지 않으면, 최초의 요청으로 인해서 그에 대응하는 aspnet_isapi.dll 파일의 CLR 이 로드되고, 직후에 뒤따라 발생한 같은 응용 프로그램 풀의 다른 버전에 대한 요청은 실패하게 됩니다.

IIS7 은 응용 프로그램 풀을 ASP.NET 버전관리의 최소 단위로 간주합니다. 따라서 응용 프로그램 풀에 로드되는 CLR / ASP.NET 의 버전은 응용 프로그램 풀 구성설정에 명확하게 설정됩니다. IIS 는 작업자 프로세스가 로딩될 때 이 구성설정에 지정된 버전의 CLR 을 기본적으로 미리 로드할 것입니다. (버전정보가 공백으로 설정된 경우는 제외)

응용 프로그램 풀이 .NET 프레임워크 버전관리의 경계선이기 때문에, 다음과 같은 작업은 ASP.NET 응용 프로그램의 버전에 변화를 주게 됩니다.

  1. 응용 프로그램을 원하는 ASP.NET 버전을 사용하는 응용 프로그램 풀로 이동합니다.
    기본적으로 응용 프로그램은 ASP.NET v2.1 통합 모드로 실행되는 “DefaultAppPool” 이라는 이름의 기본 응용 프로그램 풀을 사용합니다. ASP.NET v2.1 클래식 모드를 사용하기 위해 응용 프로그램을 “Classic .NET AppPool” 이라는 응용 프로그램 풀, 또는 여러분들이 선택한 다른 응용 프로그램 풀로 이동할 수 있습니다.
  2. 응용 프로그램이 실행되는 응용 프로그램 풀을 원하는 ASP.NET 버전을 사용하도록 설정합니다.
    기본적으로 모든 새로운 응용 프로그램 풀은 ASP.NET 2.1 통합 모드에서 실행되도록 구성됩니다.

특정 응용 프로그램을 대상으로나 전반적으로 ASP.NET 의 버전을 구성하기 위해서는 aspnet_regiis /i 또는 /r 옵션을 사용하면 안된다는 점에 주의하시기 바랍니다.

II7 은 설정된 CLR 버전과 응용 프로그램 풀의 관리되는 통합 모드에 따라 자동적으로 핸들러 맵핑의 올바른 집합을 (클래식 모드에서의 ASPNET_isapi.dll 파일 또는 통합 모드에서의 관리되는 핸들러 유형들을 위한) 선택하기 위해 미리 구성된 핸들러 맵핑을 사용합니다. 이러한 핸들러 맵핑은 ASP.NET 2.0 설치시 서버 수준에서 설치됩니다.

출처 : 한국 마이크로소프트 MSDN (2006년 10월)

Posted by 상현넘™

댓글을 달아 주세요

서론

ASP.NET 은 처음 발표된 이래로 Windows / IIS 플랫폼에서 웹 응용 프로그램 개발을 위해 가장 먼저 선택되어지는 플랫폼이 되었습니다. ASP.NET 2.0 은 웹 응용 프로그램 개발을 완전히 새로운 수준으로 이끌었고 개발자들로 하여금 보다 강력한 응용 프로그램을 과거의 그 어느때 보다도 신속하게 작성할 수 있도록 해주었습니다.

IIS7 은 ASP.NET 런타임 확장성 모듈과 핵심 서버를 통합함으로서 ASP.NET 을 또 한 단계 끌어올렸습니다. 이는 개발자들이 저수준의 IIS C++ APIs 를 사용하지 않고서도, ASP.NET 2.0 과 .NET 프레임워크가 제공하는 풍부한 기능들만을 사용하여 IIS 서버 전체를 확장할 수 있게 해줍니다. 게다가 기존의 ASP.NET 응용 프로그램도 폼 인증, 역할, 그리고 출력 캐시 등과 같은 ASP.NET 으로부터 제공되는 기존의 기능들을 모든 유형의 콘텐츠를 대상으로 확장할 수 있게 됨으로서, 견고한 통합으로부터 얻어지는 직접적인 이점을 즉시 누릴수 있게 됩니다.

물론 IIS7 이 진보된 ASP.NET 통합을 기본으로 제공하기는 하지만, 그 선택은 여전히 여러분들의 몫으로 남겨져 있습니다. IIS7 은 하나의 서버상에서 동시에 운영될 수 있는 새로운 통합 모드와 기존 통합 모드를 모두 지원합니다.

본문에서는 새로운 ASP.NET 통합 모드에 의해 소개된 개선점들과, 두 가지 모드의 아키텍처, 그리고 ASP.NET 응용 프로그램을 위해 통합 모드를 선택하거나 구성하는 방법에 대해서 설명합니다.

IIS7 에서의 ASP.NET 의 향상

보다 개선된 IIS7 과 ASP.NET 의 통합은 기존의 응용 프로그램들을 향상시키며, 새롭게 작성되는 응용 프로그램들이 ASP.NET 기능들의 이점을 새로운 방법으로 누릴 수 있도록 해줍니다.

  1. ASP.NET 의 서비스들이 모든 유형의 콘텐츠들을 대상으로 사용될 수 있습니다.
    지금까지는 폼 인증, 역할, URL 권한 부여 그리고 출력 캐시 등과 같은 ASP.NET 의 기능들은 오직 ASP.NET 콘텐츠 유형 (예를 들어, ASPX 페이지) 들을 대상으로만 사용할 수 있었습니다. 정적 파일들과 ASP 페이지들, 그리고 다른 유형의 파일들은 이러한 서비스들의 이점을 누릴 수가 없었습니다. IIS7 에서 모든 ASP.NET 서비스들은 모든 콘텐츠들을 대상으로 일관되게 제공될 수 있습니다. 이를테면, ASP.NET 인증, 멤버자격 그리고 로그인 컨트롤들로 작성된 여러분들이 이미 보유하고 있는 ASP.NET 2.0 접근 제어 솔루션을 사용하여, 이미지 파일들과 ASP 페이지들을 포함한 여러분들의 모든 콘텐츠들을 보호하는 것이 가능합니다.
  2. ASP.NET 을 사용하여 완벽한 IIS 의 확장이 가능합니다.
    IIS 의 과거 버전에서는 ASP.NET 의 런타임 제약으로 인해서 네이티브 ISAPI 필터나 익스텐션 확장성 모드를 통해 작성되는 서버 확장성이 빈번하게 요구되곤 했었습니다. IIS7 에서는 ASP.NET 모듈을 네이티브 (C++) 서버 API 를 사용하여 개발된 모듈과 완벽하게 동일한 방법으로 직접 서버의 파이프 라인에 끼워 넣을수 있습니다. ASP.NET 모듈은 요청 처리 파이프 라인의 모든 런타임 단계에서 실행될 수 있으며, 네이티브 모듈에 대해서 어떠한 순서로도 실행되어질 수 있습니다. ASP.NET API 또한 이전에 가능했던 것보다 더 많은 요청 처리 제어를 위해 확장되어질 수 있습니다.
  3. 통합된 서버 런타임.
    견고한 ASP.NET 통합은 IIS 와 ASP.NET 간의 많은 기능들까지도 통합되어질 수 있게 해줍니다. IIS7 의 기능들은 IIS 와 ASP.NET 모듈 그리고 핸들러에 대한 구성설정을 통합합니다. 사용자 정의 오류, 그리고 추적을 포함한 다른 많은 기능들도 보다 나은 관리와 집중된 응용 프로그램 디자인을 위해 통합되었습니다.

IIS7 의 새로운 ASP.NET 모드가 제공하는 이점을 활용하는 방법에 대해 보다 많은 내용을 보시려면 Taking Advantage of the Integrated ASP.NET mode 를 참고하시기 바랍니다.

ASP.NET 통합 아키텍처

IIS6 와 그 이전의 릴리스들에서, ASP.NET 은 IIS ISAPI 익스텐션으로 구현되었습니다.

ASP.NET 콘텐츠 유형에 대한 요청은 먼저 IIS 에 의해서 처리되어지고, 그 뒤에 ASP.NET 요청 파이프 라인과 페이지 프레임워크를 호스팅하는 ASP.NET ISAPI DLL 로 전달됩니다. 반면 ASP 페이지나 정적 파일과 같은 비 ASP.NET 콘텐츠들에 대한 요청은 IIS 나 다른 ISAPI 익스텐션들에 의해 처리되며, ASP.NET 쪽으로는 전혀 전달되지 않습니다.

이 모델의 가장 명확한 한계는 ASP.NET 모듈들이나 사용자 정의 ASP.NET 응용 프로그램 코드가 비 ASP.NET 요청에 대해 그 어떠한 서비스도 제공할 수 없다는 점입니다. 더군다나 ASP.NET 실행 경로의 전과 후에 발생하는 IIS 요청 처리의 각각의 부분들에 대해서 ASP.NET 모듈은 일말의 영향도 미칠수 없습니다.


그림1: IIS 6.0 ASP.NET 통합. ASP.NET 요청은 우선 IIS 에 의해 처리되고, 그 다음에 ASP.NET 처리를 위해 ASP.NET ISAPI 익스텐션으로 전달됩니다.

IIS7 에서는 ASP.NET 요청 처리 파이프 라인이 IIS 의 파이프 라인에 직접적으로 중첩되며, 이는 단순하게 끼워 넣어지는 것이 아니라 본질적인 레퍼로서 제공되는 것입니다.

콘텐츠 유형과는 무관하게, 도착한 모든 요청은 IIS 에 의해 전체 과정의 모든 단계에서 요청 처리 제공이 가능한 네이티브 IIS 모듈과 ASP.NET 모듈 양쪽 모두를 통해서 처리됩니다. 바로 이 점으로 인해서 폼 인증 또는 출력 캐시 등과 같은 ASP.NET 모듈이 제공하는 서비스들을 ASP 페이지, PHP 페이지, 정적 파일 등에도 제공할 수 있게 되는 것입니다.

이처럼 서버 파이프 라인에 ASP.NET 모듈을 직접 끼워 넣을 수 있기 때문에, ASP.NET 모듈로 IIS 의 기능을 대체하거나, 특정한 IIS 기능이 실행되기 직전이나 직후에 ASP.NET 모듈을 실행하는 것이 가능합니다. 예를 들어서, 멤버자격 서비스와 SQL 서버 사용자 데이터베이스를 사용하도록 작성된 사용자 정의 ASP.NET 기본 인증 모듈을 사용하여, 오직 Windows 계정에 대해서만 동작하는 내장 IIS 기본 인증 기능을 대체할 수도 있습니다.

게다가, 확장된 ASP.NET APIs 는 요청 처리 작업에 대한 더 많은 직접 통합의 이점을 누립니다. 예를 들어서, ASP.NET 모듈은 ASP 응용 프로그램이 사용자 선호도에 따라 지역화된 콘텐츠를 클라이언트로 강제 전송하는 작업을 실행하기 전에 Accept-Language 헤더를 추가하는 등, 다른 구성 요소들이 특정 요청을 처리하기 이전에 미리 해당 요청의 헤더 정보를 변경할 수도 있습니다.


그림2: IIS 7.0 통합 모드. ASP.NET 구성요소는 IIS 요청 처리 파이프 라인에 직접적으로 끼워 넣어지며, 콘텐츠 유형을 구분하지 않고 모든 요청을 대상으로 실행됩니다.

런타임 통합으로 인해서, IIS 와 ASP.NET 은 서버 모듈들의 활성화와 정렬, 그리고 핸들러 맵핑 구성을 위해 동일한 구성설정을 사용할 수 있게 되었습니다. 추적, 사용자 정의 오류, 그리고 출력 캐시 등을 포함한 다른 통합된 기능들도 마찮가지 입니다.

출처 : 한국 마이크로소프트 MSDN (2006년 10월)

Posted by 상현넘™

댓글을 달아 주세요