IIS 관리자 시작하기

서론

본문에서는 IIS7에서 완전히 새로운 사용자 인터페이스를 도입한 이유를 설명하고, 룩앤필, 기능 위임, 구성 설정과의 상호작용, 그리고 원격 관리에 관해서 살펴봅니다. 본문은 롱혼 서버를 기준으로 작성되었으며, 윈도우 비스타에는 본문에서 설명하는 일부 기능 및 특징이 존재하지 않을 수도 있습니다. *

IIS7의 인터넷 정보 서비스(IIS) 관리자는 완전히 새롭게 작성되었습니다.

왜 IIS 관리자는 변경될 수 밖에 없었을까요? 매우 좋은 질문입니다. - 여기에는 다음과 같은 몇 가지 중요한 이유들이 존재합니다:

• IIS와 ASP.NET의 통합:
  IIS6를 사용하는 경우, 웹 사이트를 마우스 오른쪽 버튼으로 클릭한 다음 "속성" 메뉴를 선택해서 띄운 대화 상자를 통해서 다양한 설정들에 대한 한 무더기의 탭들과 만나게 됩니다. 그런데, IIS7의 IIS 관리자는 ASP.NET이나 .NET 프레임워크와 관련된 구성 설정뿐만 아니라, 출력 캐싱, 실패한 요청 추적, 요청 필터링 같은 새로운 기능들을 위한 구성 설정까지 모두 관리해야 합니다. 기존 방식대로라면 모든 새로운 기능들을 또 다시 한 무더기의 탭으로 나타내야 하는데, 이는 그리 현명한 방법이 아닙니다.
• 관리 위임:
  IIS7의 구성 설정 저장소는 메타베이스로부터 .NET 구성 설정 시스템으로 이동되었으며, 이 얘기는 관리자가 허용하는 경우 사용자들이 IIS의 구성 설정을 web.config 파일에 저장할 수 있게 되었다는 것을 의미합니다. 가령, http://www.contoso.com/sales 응용 프로그램을 위한 구성 설정은 루트 구성 설정 파일인 applicationHost.config에 저장될 수도 있고, http://www.contoso.com/ 사이트의 web.config 파일이나, 응용 프로그램 자신의 디렉터리에 존재하는 web.config 파일에 저장될 수도 있습니다. 결과적으로 새로운 IIS 관리자는 1)관리자가 허용한 web.config의 구성 설정을 제어할 수 있어야 하고, 2)관리자와 사용자에게 저장된 구성 설정을 보여줄 수 있어야 합니다. 구 버전의 IIS 관리자는 이 목적에 적합하지 않습니다.
• 기술적인 이유:
  모든 소프트웨어는 각기 수명을 갖고 있습니다. 시간이 흐름에 따라 새로운 기술, 새로운 요구, 새로운 규약이 등장하고, 그 결과 기존에 존재하는 소프트웨어를 유지보수하는 것이 새로운 소프트웨어를 작성하는 것보다 더 노동 집약적이고 고비용이 되는 시기을 맞이하게 됩니다. IIS 관리자의 구버전은 그 수명의 한계에 거의 도달했다고 볼 수 있습니다.

그 밖에 더 알아야 될 것은 없을까요? IIS 관리자를 다시 작성하기로 결정함에 따라, 몇 가지 핵심적인 방법으로 IIS 관리자를 진보시킬 수 있는 기회를 갖게 되었습니다.

• 확장성:
  IIS6의 IIS 관리자를 확장하는 작업은 대단히 어려운 일이었습니다. 새로운 IIS 관리자는 기능 페이지나 트리뷰 노드, 그리고 메뉴 항목을 추가하는 보다 쉬운 방법을 제공해주며, 이 모든 작업에는 관리되는 코드와 윈폼이 사용됩니다. IIS 관리자 확장 기능들은 IIS 관리자 클라이언트가 서버에 원격 접속할 때 자동적으로 감지되고 다운로드됩니다.
• 원격 관리:
  모든 원격 관리는 HTTPS 상에서 이뤄지므로 방화벽 사용에도 문제가 없으며 관리를 보다 쉽게 만들어줍니다. 원격 관리를 활성화시켜주는 웹 관리 서비스(WMSVC)는 선택 가능한 설치 구성 요소입니다.
• 새로운 룩앤필:
  IIS 관리자는 구성 설정을 출력하기 위한 보다 새롭고 뛰어난 확장 가능한 모델을 필요로 했으며, 그 결과 기능 목록 뷰는 제어판의 형태를 닮게 되었습니다. 목록 뷰는 정렬 및 그룹화가 가능하고 각기 다른 방법으로 출력 가능하며, 이런 기능들은 여러분이 필요한 항목들을 찾기 쉽게 만들어줍니다. IIS 관리자의 탐색 기능도 최신의 윈도우 탐색기 주소 표시줄과 비슷하게 바뀌었으며 브라우저와 매우 비슷한 느낌의 형태를 갖게 되었습니다.

새로운 룩앤필

지난 버전의 인터넷 정보 서비스(IIS) 관리자에서는 뒤로/앞으로 형태의 탐색 기능을 제공했었습니다. 그에 더하여 새로운 IIS 관리자에서는 비스타에서 제공해주는 새로운 윈도우 탐색기와 유사한 형태의 주소 표시줄이 추가적으로 제공됩니다.

그림 1: 새로운 IIS 관리자

홈 페이지

일단 IIS 관리자를 사용하기 시작하면 얼마 지나지 않아 홈 페이지가 매우 친숙하게 느껴지기 시작할 것입니다. 중앙에 위치한 기능 목록은 기능 이름이나 설명을 기준으로 정렬 가능하며, 영역이나 범주를 기준으로 그룹화할 수 있을 뿐만 아니라 다양한 레이아웃으로 출력할 수 있습니다.

그림 2: IIS 관리자 그룹화

기능 범위

트리뷰에 존재하는 서버, 사이트, 응용 프로그램, 가상 디렉터리, 그리고 폴더 노드들은 모두 홈 페이지를 통해서 각각의 기능 목록을 제공합니다. 대다수의 기능들은 이러한 유형의 노드들이 선택되었을 때 항상 홈 페이지에 나타나지만, 여기에는 약간의 예외가 존재합니다.

다음과 같은 기능들은 서버 수준의 구성 설정이나 데이터 또는 정보들을 다루기 때문에 서버 노드의 홈 페이지에서만 나타납니다:

• ISAPI 및 CGI 제한
• 서버 인증서 (원격 연결시에는 나타나지 않습니다.)
• 관리 서비스 (원격 연결시에는 나타나지 않습니다.)
• 작업자 프로세스

다음과 같은 기능들은 응용 프로그램 관련 구성 설정이며 논리적으로 서버 수준에 적합하지 않거나, 그렇게 동작하는 것이 더 바람직하기 때문에(SSL) 서버 노드의 홈 페이지를 제외한 모든 홈 페이지에 나타납니다:

• 멤버쉽 사용자 *
• 멤버쉽 역할 *
• 프로필 *
• SSL

권한 위임과 관련된 기능들은 어떤 경우에 나타나는지 별도의 규칙을 갖고 있습니다:

• 기능 위임: 언제나 해당 연결의 루트 노드에만 나타난다.
• 관리자: 서버, 사이트 응용 프로그램 노드에만 나타난다. **

기능 페이지 레이아웃

IIS 관리자에는 목록 페이지와 속성 그리드, 그리고 대화 상자 페이지의 세 가지 페이지 유형이 존재합니다.

목록 페이지

목록 페이지에는 목록이 존재합니다. 대부분의 목록 페이지는 한 가지 이상의 방법으로 그룹화 할 수 있는 기능을 제공해줍니다. 웹 사이트나 응용 프로그램 풀 같은 핵심적인 목록 페이지에서는 입력한 문자열과 일치하는 목록 컬럼을 조회하여 목록 항목들을 필터링하기 위한 방법을 제공해줍니다.

그림 3: IIS 관리자 목록 페이지

작업 패인에 존재하는 추가/편집/제거 링크를 사용해서 목록의 콘텐츠를 조작할 수 있습니다. 목록의 특정 항목을 지정하지 않는 기능 설정도 존재할 수 있는데, 가령 로컬 요청에 대해 미리 정의된 오류 페이지가 없는 오류가 발생하는 경우 사용되는 기본 오류에 대한 설정은, 기능 설정 편집... 링크를 통해서 구성됩니다.

그림 4: IIS 관리자 작업

속성 그리드

속성 그리드 페이지는 관련된 속성들의 그리드를 보여줍니다. 속성 그리드의 상단에 위치한 표시 선택자를 사용하면 친숙한 속성 이름이나 구성 설정 상의 이름, 또는 이 두 가지 모두를 속성 그리드에 출력할지 말지를 선택할 수 있습니다. 다음 이미지는 두 가지 모두를 출력한 경우입니다.

그림 5: IIS 관리자의 속성 그리드

대화 상자

대화 상자 페이지는 체크 박스, 텍스트 박스, 그리고 라디오 버튼 등이 존재하는 가장 일반적이고 친숙한 유형의 페이지입니다. 작업 페인의 적용/취소 링크를 사용해서 변경된 사항을 저장할 수 있습니다.

콘텐츠 뷰

콘텐츠 뷰는 읽기 전용 화면이며 파일 및 폴더를 생성하거나 복사, 이동 또는 삭제할 수 없습니다. IIS 관리자의 중앙 하단에 위치한 기능 보기/콘텐츠 보기 스위치에서 콘텐츠 보기를 클릭하거나, 트리뷰 상의 노드를 마우스 오른쪽 버튼으로 클릭해서 콘텐츠 보기로 전환 메뉴를 선택하면 콘텐츠 뷰로 전환할 수 있습니다.

특정 파일에 대한 구성 설정을 수행하는 유일한 방법은 먼저 콘텐츠 뷰로 전환한 다음, 파일을 선택하고, 컨텍스트 메뉴나 작업 패인에서 기능 보기로 전환 메뉴를 선택하는 것입니다. *

그림 6: 기능 보기로 전환

기능 위임

만약, 여러분이 서버 관리자지만 서버의 콘텐츠를 제공하는 중추적인 사용자가 아니거나, 개발자지만 자신의 응용 프로그램에 대해 보다 많은 제어권을 확보하고 싶다면, 기능 위임 기능에 대해서 많은 관심을 갖게 될 것입니다.

결론적으로 IIS7 의 기능 위임이란:

• 특정 구성 설정이 web.config 파일에 저장될 수 있는지 여부를 제어하는 구성 설정 섹션 잠금을 관리하거나,
• 잠겨져 있지 않은 구성 설정 섹션의 기능을 보거나 설정하기 위해서 IIS 관리자를 사용할 수 있도록 허가된 사이트 및 응용 프로그램 사용자들을 관리하는 작업을 의미합니다.

본문에서는 IIS 관리자의 기능 위임에 대한 피상적인 내용들만 다룹니다. 더 자세한 정보는 IIS 7의 원격 관리 및 기능 위임 구성하기 문서를 참고하시기 바랍니다.

구성 설정 잠금

만약, 어떤 구성 설정 섹션이 기본값으로 잠겨 있다면 이 구성 설정은 applicationHost.config 파일에서만 설정 가능합니다. IIS 관리자는 서버 관리자가 IIS 구성 설정 섹션의 잠금을 풀 수 있게 해줍니다. 구성 설정 섹션의 잠금이 풀리면 관리자가 아닌 사용자들도 web.config 파일에서 해당 섹션을 설정할 수 있습니다.

가령, IIS 관리자의 오류 페이지 기능은 구성 설정의 system.webServer/httpErrors 섹션과 대응됩니다. 그러나, 서버 관리자가 IIS 관리자 또는 APPCMD 명령어를 사용해서 system.web/httpErrors 섹션의 잠금을 풀면, 다음과 같이 applicationHost.config 파일에 overrideMode 속성값이 Allow로 설정된 location 태그가 새로 생성되고 그 내부에 httpErrors 섹션이 존재하게 됩니다.

<location path="" overrideMode="Allow">
    <system.webServer>
        <httpErrors/>
    </system.webServer>
</location>

이렇게 oerrideMode 속성값이 Allow로 설정되면, 다음과 같이 web.config 파일에도 httpErrors 섹션에 대한 구성 설정을 저장할 수 있게 됩니다:

<configuration>
    <system.webServer>
        <httpErrors>
            <remove statusCode="404" subStatusCode="-1" />
            <error statusCode="404" path="/errors/404.aspx" responseMode="Redirect" />
        </httpErrors>
    </system.webServer>
</configuration>

구성 설정 잠금이 연결에 어떤 영향을 미치는지를 파악하고 싶다면, 본문의 하단에 위치한 서버, 사이트 및 응용 프로그램 연결 섹션을 살펴보시기 바랍니다. 또한, 구성 설정 잠금에 대한 보다 자세한 정보를 알고 싶다면 How to Use Locking in IIS 7.0 Configuration 문서를 참고하시기 바랍니다.

사이트 및 응용 프로그램 관리자

그리고, 서버 관리자들은 IIS 관리자를 통해서 사이트나 응용 프로그램에 연결할 수 있는 비-관리자들을 활성화시킬 수 있습니다. 이런 사이트나 응용 프로그램에 연결할 수 있는 비-관리자들을 사이트 관리자나 응용 프로그램 관리자라고 부르며, 이런 사용자들은 다음과 같은 작업들을 수행할 수 있습니다:

• 연결된 사이트나 응용 프로그램의 잠금이 풀린 구성 설정들을 관리합니다. (설정값들은 web.config 파일에 저장됩니다.)
• 잠긴 구성 설정들을 볼 수는 있지만 수정은 불가능합니다.
• 연결된 사이트나 응용 프로그램에 대해 또 다른 사이트 및 응용 프로그램 관리자를 추가할 수 있습니다.

사이트나 응용 프로그램 관리자를 생성하는 방법에 대하여 보다 상세한 정보를 파악하려면, Create Site and Application Administrators for Delegation 문서를 참고하시기 바랍니다.

서버, 사이트 및 응용 프로그램 연결 *

머신 관리자들만 IIS 관리자로 웹 서버에 연결할 수 있습니다. 이런 서버 연결 상태에서는 루트 구성 설정 파일인 applicationHost.config와 루트 web.config, 그리고 분산된 web.config 파일 모두에 구성 설정을 저장할 수 있습니다. 만약, 구성 설정 섹션이 applicationHost.config 파일에서 잠겨 있다고 하더라도, 서버 연결 상태에서 그에 대응하는 기능은 읽기/쓰기 상태로 나타나게 됩니다. 이런 경우, 변경된 구성 설정값이 applicationHost.config 파일의 location 태그에 기록되기 때문입니다.

머신 관리자들과 지정된 사이트 관리자들은 웹 사이트에 연결할 수 있습니다. 그러나, 사이트 연결 상태에서는 해당 사이트의 루트 폴더에 위치한 web.config 파일에만 기록이 가능합니다. 만약, 구성 설정 섹션이 applicationHost.config 파일에서 잠겨 있다면, 사이트 연결 상태에서 그에 대응하는 기능은 읽기 전용으로 나타나게 되는데, 그 이유는 사이트 연결하에서는 applicationHost.config 파일에 구성 설정을 저장할 수 없기 때문(location 태그 포함)입니다. 이 결과는 머신 관리자와 사이트 관리자 모두에게 해당됩니다.

그림 7: IIS 관리자의 구성 설정 계층 **

머신 관리자들과 지정된 응용 프로그램 관리자들, 그리고 특정 응용 프로그램의 부모 사이트를 관리하는 사이트 관리자들은 응용 프로그램에 연결할 수 있습니다. 응용 프로그램 연결 상태에서는 오직 해당 응용 프로그램의 루트 폴더에 위치한 web.config 파일에만 기록이 가능합니다. 이 경우에도 구성 설정 섹션이 applicationHost.config 파일이나 사이트의 web.config 파일에서 잠겨 있다면, 응용 프로그램 연결 상태에서 그에 대응하는 기능은 읽기 전용으로 나타나게 됩니다.

서버, 사이트 또는 응용 프로그램에 연결하는 자세한 방법은 Managing Connections in IIS 7.0 문서를 참고하시기 바랍니다.

구성 설정

만약, 구성 설정 잠금이나 기능 위임을 사용하지 않을 계획이라고 하더라도 IIS 관리자가 구성 설정 저장 위치를 결정하는 방법에 대해 알고 싶은 수도 있을 것입니다. 이 판단 기준에 대한 두 가지 규칙이 존재합니다:

• ApplicationHost.config 파일 vs. 루트 Web.config 파일:
  IIS 관리자의 ASP.NET 영역 목록에 출력된 기능의 서버 수준 구성 설정은 .NET 프레임워크 v2.0의 루트 web.config 파일에 기록됩니다. 반면, IIS 관리자의 IIS 영역 목록에 출력된 기능의 서버 수준 구성 설정은 applicationHost.config 파일에 기록됩니다. 단 하나의 예외는 IIS 영역의 인증 기능에서 제공되는 폼 인증에 대한 규칙입니다.
• 잠겨져 있는 구성 설정 vs. 풀려져 있는 구성 설정:
  모든 ASP.NET 구성 설정 섹션과 일부 IIS 구성 설정 섹션은 기본적으로 잠금이 풀려 있습니다. IIS 관리자는 이처럼 잠금이 풀려져 있는 섹션들에 대해서는 사이트나 응용 프로그램에 대한 구성 설정이 변경되면 사이트의 web.config 파일에 변경된 내용을 저장합니다. 반면, 대부분의 IIS 구성 설정 섹션들은 기본적으로 잠겨 있습니다. IIS 관리자는 이렇게 잠겨져 있는 섹션들에 대해서는 변경된 내용이 사이트나 응용 프로그램에 대한 내용이라고 하더라도 언제나 applicationHost.config 파일에 저장합니다.

상태 표시줄 *

IIS 관리자의 상태 표시줄은 구성 설정이 기록될 위치를 보여줍니다:

구성: '<config_file_object_path>' <config_file_name>, <location path="<path>">

이 형식에서 <config_file_object_path> 부분은 구성 설정 파일 개체의 경로를 의미합니다. 가령:

• "localhost":
  서버-수준 구성 설정; IIS 기능인 경우에는 applicationHost.config 파일, ASP.NET 기능인 경우에는 루트 web.config 파일.
• "localhost/Default Web Site":
  Default Web Site의 물리적인 경로에 위치한 web.config 파일.
• "localhost/Default Web Site/careers/technical":
  Default Web Site 하위의 URL인 /careers/technical과 맵핑된 물리적인 경로에 위치한 web.config 파일.

그리고, <config_file_name> 부분은 설정이 저장될 구성 설정 파일명을 나타냅니다. 가령:

• "applicationHost.config 또는 루트 Web.config" **:
  IIS 기능인 경우에는 applicationHost.config 파일, ASP.NET 기능인 경우에는 루트 web.config 파일.
• "web.config":
  웹 이름 경로상의 web.config 파일.

마지막 <location_path> 부분은 해당 개체의 구성 위치 경로를 뜻합니다. (위치 경로에 대한 보다 자세한 정보는 Configuration Overview 문서를 참고하시기 바랍니다.) 이 부분은 해당 기능에 대응하는 구성 설정 섹션이 상위 수준에서 잠겨 있는 경우에만 나타납니다.

그림 8: 위치 경로 ***

예제: applicationHost.config 파일 설정 vs. 루트 web.config 파일 설정

압축 기능은 IIS 관련 기능으로 홈 페이지 기능 목록에서 영역을 기준으로 그룹핑이나 필터링해보면 IIS 영역에서 찾아 볼 수 있습니다. 만약, 서버-수준 압축 페이지에서 정적 압축을 비활성화시키면, IIS 관리자는 이 구성 설정을 다음과 같이 %windir%\Windows\system32\inetsrv\applicationHost.config 파일에 저장합니다.

<urlCompression doStaticCompression="false" />

.NET 컴파일 기능은 .NET 프레임워크 관련 기능으로 홈 페이지 기능 목록에서 영역을 기준으로 그룹핑이나 필터링해보면 ASP.NET 영역에서 찾아 볼 수 있습니다. 만약, 서버 수준 .NET 컴파일 페이지에서 기본 언어를 C#으로 설정하면, IIS 관리자는 루트 web.config 파일의 compilation 섹션에 defaultLanguage 속성을 다음과 같이 추가합니다. (%windir%\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config):

<compilation defaultLanguage="C#">

그리고, 이 두 가지 경우 모두 상태 표시줄에는 다음과 같이 표시됩니다: **

구성: 'localhost' applicationHost.config 또는 루트 web.config

예제: 잠겨져 있는 구성 설정 vs. 풀려져 있는 구성 설정

IIS의 defaultDocument 구성 설정 섹션은 기본적으로 잠금이 풀려 있습니다. 만약, Default Web Site의 기본 문서 설정을 변경하면 IIS 관리자는 변경 내용을 %windir%\inetpub\wwwroot\web.config 파일에 다음과 같이 기록할 것입니다:

<configuration>
    <system.webServer>
        <defaultDocument>
            <files>
                <clear />
                <add value="default.aspx" />
            </files>
        </defaultDocument>
    </system.webServer>
</configuration>

그리고, 상태 표시줄에는 다음과 같이 표시됩니다:

구성: 'Default Web Site' web.config

반면, IIS의 httpErrors 구성 설정 섹션은 기본적으로 잠겨 있습니다. 만약, Default Web Site의 HTTP 404 응답 오류를 재정의했다면 IIS 관리자는 변경 내용을 %windir%\Windows\system32\inetsrv\applicationHost.config 파일에 다음과 같이 기록할 것입니다:

<location path="Default Web Site" overrideMode="Allow">
    <system.webServer>
        <httpErrors>
            <remove statusCode="404" subStatusCode="-1" />
            <error statusCode="404" path="/err/404.aspx" responseMode="Redirect" />
        </httpErrors>
    </system.webServer>
</location>

그리고, 상태 표시줄에는 다음과 같이 표시됩니다: **

구성: 'localhost' applicationHost.config 또는 루트 web.config , <위치 경로="Default Web Site">

IIS 관리자 원격 관리 기능

IIS6를 비롯한 이전 버전의 IIS에서는 IIS 관리자를 통한 원격 관리 기능이 기본적으로 활성화되어 있었습니다. 반면, IIS7의 IIS 관리자 원격 관리 기능은 반드시 명시적으로 활성화시켜야만 사용할 수 있습니다. 모든 원격 관리 작업은 HTTPS 상에서 이루어지며, 웹 관리 서비스(WMSVC)라는 IIS 구성 요소에 의해 처리됩니다. IIS 관리자를 사용한 IIS7의 원격 관리 활성화에 대한 보다 자세한 정보는 IIS 7의 원격 관리 및 기능 위임 구성하기 문서를 참고하시기 바랍니다.

웹 관리 서비스(WMSVC)

웹 관리 서비스(WMSVC)는 윈도우 서비스에 의해서 호스팅되는 독립적인 웹 서버(호스팅 가능한 웹 코어: HWC)입니다. WMSVC가 설치되고 실행되면 모든 지정되지 않은 IP 주소의 8172번 포트로 전달되는 요청을 대기합니다. WMSVC는 다음과 같은 단 네 종류의 요청만 허용하며, 각각의 요청들은 대응하는 처리기에 의해 서비스됩니다: *

• 로그인 요청을 처리하는 login.axd
• 코드 다운로드 요청을 처리하는 download.axd
• 관리 서비스 요청을 처리하는 service.axd
• Ping 요청을 처리하는 ping.axd

로그인 요청

IIS 관리자는 연결을 초기화하기 위해 네트워크를 통해 로그인 요청을 전송합니다. 이 때, NTLM 인증이나 기본 인증 중 한 가지 방법이 사용되며, 이 중 어떤 방법이 사용될 것인지는 연결 대화 상자에서 사용자가 선택한 결과에 따라 좌우됩니다.

그림 9: 신원계정 지정

코드 다운로드 요청

로그인이 성공하면 WMSVC는 해당 연결에 유효한 UI 모듈들의 목록을 리턴해줍니다. 가령, 오류 페이지 같은 IIS 관리자 페이지들은 각각 하나의 모듈과 대응되는데, 만약 로컬 IIS 관리자가 해당 모듈을 갖고 있지 않다면 서버로부터 해당 모듈의 바이너리를 다운로드 받기 위해 코드 다운로드 요청을 전송하게 됩니다. (예를 들어서, 서버 관리자가 새로운 RSA 보안 제품을 자신이 관리하는 운영 서버에는 설치했지만, 자신의 데스크탑에는 해당 제품을 설치하지 않은 상태에서 원격 관리를 위해 IIS 관리자를 사용해서 서버에 연결하는 경우를 생각해 볼 수 있을 것입니다.)

관리 서비스 요청

연결이 맺어지고 나면 사용자가 IIS 관리자의 사용자 인터페이스를 사용함에 따라 관리 서비스 요청이 발생하게 됩니다. 관리 서비스는 서버의 구성 설정이나 런타임 상태, 그리고 제공자들을 읽거나 쓰기 위해 직접 WMSVC의 모듈 서비스로 요청을 전송합니다.

Ping 요청

Ping 요청은 WMSVC 내부에서 주기적으로 자동 발생되어 자신을 호스트하는 웹 서버(HWC)로 전송됩니다. 결론적으로 Ping 요청은 호스트 가능한 웹 코어가 지속적으로 응답할 수 있도록 하기 위한 단순한 메커니즘에 불과합니다.

서비스 설정 **

WMSVC는 설정이 가능한 약간의 구성 설정 정보를 레지스트리 내부에 갖고 있습니다. 반면, 매번 서비스가 시작될 때마다 %windir%\ServiceProfiles\LocalService\AppData\Local\Temp\WMSvc<GUID>\ 폴더에 다시 생성되는 웹 구성 설정 파일들은 관리자조차 설정이 불가능합니다.

그림 10: 레지스트리 설정 변경

보안

IIS 관리자와 웹 관리 서비스(WMSVC)를 통한 원격 관리는 기능의 단순성과 보안이라는 두 가지 면을 모두 만족시키기 위해 전반적으로 재검토되었습니다. 그 결과 다음과 같은 몇 가지 보안 방안이 적용되었습니다:

• 원격 IIS 관리자 클라이언트와 WMSVC간 전달되는 모든 데이터는 보안을 위해 SSL(HTTPS)을 필수로 요구합니다.
• 권한 최소화를 위해 로컬 서비스 계정으로 실행됩니다. ***
• 호스트 가능한 웹 코어(HWC)의 구성 설정은 접근이 엄격히 차단되었으며 **, 필요한 최소한의 모듈들만을 포함하고 있고, 주의 깊게 만들어진 요청 필터링 규칙이 적용되어 있습니다. ****