마이크로소프트의 Windows 뿐만이 아니라 다른 벤더의 OS도 마찬가지고, 회사 내부의 인트라넷 어플리케이션, 우리가 사용하는 E-mail서버 등, 수많은 어플리케이션이 디렉터리를 요구한다. 이러한 디렉터리를 보다 효율적으로 사용하기 위한 노력이 존재하고 마이크로소프트 역시 효율적인 디렉터리 관리를 위해서 상당한 노력을 기울이고 있다. 디렉터리가 어떻게 관리되는지에 따라서 네트워크 관리모델을 결정할 수가 있게 된다. 마이크로소프트는 관리모델로써 Workgroup과 Domain이라고 하는 두가지 모델을 제공한다.

두 모델의 가장 큰 차이점이라면 디렉터리 데이터베이스의 위치라고 할 수 있다. 먼저 첫번째 그림을 보자. 네트워크에 Windows 2000 server, professional, NT4.0 Server, Workstation 의 서로 다른 4개의 컴퓨터가 있고, 각각의 시스템이 고유한 디렉터리 데이터 베이스를 유지하고 있는 모델이다. 

이러한 형태로 네트워크를 운영할 때 어떤 일이 발생할 것인지를 생각해 보자.

‘홍길동’이라는 사용자가 특정 서버의 공유자원에 접속을 원한다면 해당 서버의 디렉터리 데이터베이스에 사용자 계정이 존재해야 한다. 만일 홍길동이 4대의 서버에 각각 접속을 원한다면 홍길동은 4대의 서버마다 자신의 사용자 계정을 가지고 있어야 하고 또한 그 계정과 각각의 암호를 기억하고 있어야 전체 서버의 자원을 이용할 수 있게 될 것이다.

서버 입장에서는 어떤가? 만일 홍길동이 자신의 공유자원에 접속하기를 원한다면 서버의 관리자는 홍길동을 위해 공유자원에 대한 접근허가를 주기 위해서 자신의 디렉터리 데이터베이스 안에 홍길동이 사용할 계정을 생성해 주어야 한다. 서버가 추가된다면 역시 홍길동의 계정은 추가된 서버의 디렉터리 데이터베이스에 새롭게 생성이 되어야만 한다.

결과적으로는 하나의 사용자가 서버들의 자원에 접근하도록 하기 위해서 각 서버에는 사용자 계정이 생성되어야 하는 번거로움을 감수해야 할 것이다. 이들 4대의 서버를 관리하는 관리자도 마찬가지이다. 관리자 역시 각각의 서버를 관리하기 위해서는 각 서버에서 관리권한을 가진 사용자 계정과 암호를 알고 있어야만 관리가 가능해 지는 것이다. Workgroup을 사용하는데 있어서 불편한 점을 정리해 보면 다음과 같다.

  ① 한 사용자가 자원을 가진 서버마다 별도의 사용자 계정을 가지고 있어야 한다.

  ② 하나의 사용자를 위해서 서버마다 계정을 만들어야 하는 번거로움

  ③ 중앙집중적인 관리의 어려움

서버의 수도 많아지고 사용자의 숫자도 증가하여 네트워크에서 관리해야 할 자원들이 늘어간다면 워크그룹 모델은 분명히 한계가 있다. 제대로 관리를 한다는 것은 너무나 많은 노력을 필요로 하는 일이다.

이것을 해결할 방법은 없는가? 마이크로소프트는 도메인이라는 모델을 제시하고 있다. 생각을 조금만 바꾸면 된다. 회사에 있는 모든 서버들이 자신의 디렉터리 데이터베이스에 사용자 계정을 각각 관리할 것이 아니라, 하나의 마스터 디렉터리 데이터베이스를 두고 모든 서버들은 그 디렉터리 데이터베이스에 접근하여 사용자 계정을 공유한다면 될 것이 아닌가?

이것을 가능하도록 하기 위하여 마이크로소프트는 네트워크 환경에서 특별한 서버를 지정하여 마스터 디렉터리 데이터베이스를 관리하도록 하였고, 이 서버를 도메인 컨트롤러 (Domain Controller, DC)라고 부른다. 그리고 이 도메인 컨트롤러의 마스터 디렉터리를 사용할 수 있는 서버나 클라이언트들을 묶어서 '도메인(Domain)'이라는 논리적인 관리단위를 만들었다. 정리하자면 워크그룹이 가졌던 단점을 해결하고자 한다면 도메인이라는 그룹을 만들고 모든 서버들을 이 도메인의 멤버로 만들고, 클라이언트 역시 도메인으로 로그온하도록 구성을 하면 되는 것이다. 그렇게 하면 도메인의 모든 멤버들은 디렉터리 서비스에 적용을 받고 각각의 계정이 아니라 도메인의 마스터 디렉터리 계정으로서 자원관리를 할 수가 있게 된다.

아래의 그림에서는 디렉터리 데이터베이스가 DC에 집중되어 있는 것을 볼 수 있다.

도메인 환경에서는 앞에서 홍길동의 계정이 서버마다 생성될 필요가 없다. 도메인 컨트롤러의 마스터 디렉터리 데이터베이스에서 한번만 생성이 되면 그뿐이다. 다른 모든 멤버서버들은 도메인 컨트롤러에 접근하여 마스터 디렉터리 데이터베이스에 저장된 홍길동에게 직접 자원에 대한 접근허가를 줄 수 있다.

사용자 입장에서도 자원에 접근하기가 수월해졌다. 자원을 가진 모든 서버마다 별도의 사용자계정과 암호를 기억할 필요가 없이 도메인 컨트롤러의 마스터 디렉터리 데이터베이스에 저장된 사용자 계정과 암호만 기억한다면 그 정보를 이용해서 모든 서버에 접근을 할 수 있다.

도메인 환경에서 새로운 서버가 추가되고 그 서버의 자원에 모든 사용자들이 접근할 수 있게 하려면? 간단해 진다. 새로운 서버를 도메인의 멤버서버로 설정하기만 하면 된다. 그러면 그 서버는 기존에 이미 존재하는 도메인의 디렉터리 데이터베이스에 접근하여 사용자 정보를 사용하는 것이 가능해 지기 때문이다.

관리적인 측면으로 본다면 워크그룹모델은 컴퓨터와 컴퓨터 즉, 자원과 자원간에 아무런 연관성이 없는 개별적인 관리모델이고, 도메인 모델은 도메인에 참여하여 도메인을 구성하고 있는 서버 및 PC들이 도메인이라는 범위내에서 관리정책, 보안정책 등을 서로간에 공유할 수 있는 모델을 말한다.

도메인 모델의 장점을 굳이 언급할 필요는 없다. 워크그룹 모델을 사용하는데 불편했던 점들을 고려한다면 그것들 중의 대부분은 도메인 모델을 채택함으로써 해결될 수 있는 단점이 될 것이다.

Active Directory를 단적으로 표현한다면 'Windows Server 2003 이상의 서버에서 제공하는 디렉터리 데이터베이스'^[1]라고 할 수 있다. Active Directory를 하나의 메이커 형태로 생각하면 이해가 쉽다. 이를 테면 'Active Directory는 마이크로소프트가 Windows Server에서 제공하는 디렉터리'라고 정의를 하자.

그렇다면 디렉터리라는 것이 마이크로소프트만 제공하는 것도 아니고 SUN, IBM, Novell등 다양한 벤더가 모두 지원하고 있는데 왜 유독 Active Directory가 많은 관리자들에게 회자되고 있는 것일까? AD는 무엇인가에 대한 원론적인 개념은 단순하지만 AD를 가지고 무엇을 할 수 있는가? 여러분들은 AD를 가지고 무엇을 할 것인가? 라는 측면은 상당히 고민스러운 부분이다.

왜 Active Directory를 사용해야 할까?

네트워킹에서 디렉터리라고 하는 것은 필수적인 요소이다. 서버가 자신의 자원에 접근을 원하는 사용자들에게 권한을 부여하고자 한다면 서버는 디렉터리를 필요로 한다. 사용자가 네트워크상의 자원에 접근을 하고자 한다면 역시 디렉터리를 필요로 한다. 디렉터리는 “정보저장소”의 역할을 제공한다.

Active Directory는 디렉터리로서 어떤 정보를 저장하고 있을까? Active Directory는 사용자, 그룹, 컴퓨터, 공유폴더, 프린터, 연락처, 조직구성단위(OU) 등의 다양한 정보를 Object(개체)로 저장할 수 있다. 컴퓨터, 공유폴더, 프린터 등까지 디렉터리에 포함하고 있음을 주목하자. 이것은 관리자에게 상당한 편의성을 제공하는 기반이 된다.

Active Directory에 자원을 가진 서버나 자원에 접근하기를 원하는 사용자가 네트워크에서 이들 자원을 찾고자 한다면 사용자들은 Active Directory를 검색함으로써 원하는 자원의 위치정보를 얻어낼 수 있다.

‘그렇구나. 유용한 디렉터리인 것 같긴 하구나.’ 하지만 이 정도 가지고는 특별히 다른 디렉터리와의 차별화된 장점을 제공한다고 보기는 어렵다.

관리편의성과 확장성 2가지 측면에서 AD의 장점을 살펴보자.

Active Directory가 주는 장점 중 가장 큰 부분이라고 할 수 있는 것이 관리편의성 측면이다. <그림13-1>에서 Active Directory에 저장되는 정보중에는 사용자, 컴퓨터가 포함되어 있음을 확인했다. 여기서 컴퓨터라 함은 우리가 사용하는 데스크톱PC뿐이 아니라 서버들도 포함된다. 이것은 무엇을 의미할까?

Active Directory는 마이크로소프트에서 제공하는 디렉터리 서비스이고, 우리가 업무를 위해 사용하는 PC의 대다수 운영체제는 역시 마이크로소프트의 Windows운영체제이다. 필자는 Active Directory가 많은 기업의 핵심 인프라로 자리할 수 있는 배경의 가장 큰 힘이라면 Active Directory가 컴퓨터 정보를 포함함으로써 사용자 및 컴퓨터에 대한 효율적인 관리를 제공할 수 있는 기반을 제공하고, 그 기반위에서 적절하게 사용할 수 있는 수많은 정책들을 함께 제공함으로써 최상의 관리방안을 제시하고 있기 때문이라고 말하고 싶다.

그 관리방안의 핵심은 Active Directory가 제공해 주는 기능중의 꽃이라고 할 수 있는 ‘그룹정책(Group policy)’에 있다. 그룹정책은 참으로 많은 능력을 가지고 있다. 도메인환경에서 다수의 컴퓨터, 다수의 사용자들에 대한 상당부분의 관리 및 지원기능을 그룹정책 하나를 가지고 자동화시킬 수 있어서 이러한 그룹 정책을 잘 사용하는 것은 관리자의 업무부담을 상당부분 줄여줄 수 있다. 그룹정책을 이용해서 할 수 있는 일을 간단히 정리하였다.

-          사용자의 데스크탑 환경 설정

-          사용자의 데스크탑 제어 (Lock down)

-          레지스트리 수정

-          스크립트 자동 실행 (로그온, 로그오프, 시작, 종료)

-          보안설정

-          소프트웨어 관리 (설치, 업그레이드, 제한, 재설치, 복구, 삭제)

그룹정책을 적용할 수 있는 Active Directory 구조단위는 사이트, 도메인, OU이며, OU(조직단위)는 그룹정책을 적용할 수 있는 최소단위이다. 마이크로소프트는 Windows Server 2003의 Active Directory에서 무려 1,300가지 이상의 그룹정책설정 항목을 제공함으로써 관리자의 편의를 돕고 있다. 스크립트 자동실행 기능이 제공되기 때문에 기본정책만으로 부족하다면 개발자의 프로그래밍 능력에 따라 얼마든지 커스터마이징된 그룹정책을 배포할 수도 있다.

또한 그룹정책은 기본적으로 상속성을 가지고 있다. 도메인의 그룹정책은 OU에 속한 모든 사용자 및 컴퓨터에 적용되고, 상위OU에 설정된 그룹정책은 하위OU에 상속된다. 이를 통해 관리자는 전사적인 레벨의 보안설정 등의 관리항목은 도메인에 그룹정책으로 설정하고, 부서별, 위치별, 업무성격별로 OU에 설정함으로써 차별적인 정책기반의 사용자 및 컴퓨터 관리가 가능하다.

사용자 및 컴퓨터를 정책으로 관리하기 위해서는 이미 기본인프라는 갖춰져 있다는 것을 가정한다. 기본인프라라고 하면 AD가 구성되고 디렉터리에는 사용자가 생성되어야 하며, 컴퓨터는 AD도메인에 참여함으로써 디렉터리에 개체로서 포함되어 있는 것을 의미한다.

이번에는 Active Directory의 확장성 측면을 살펴보자. 먼저 Active Directory가 지원하는 프로토콜에 대해 살펴보면 Active Directory는 대부분의 산업표준 프로토콜을 채택했다. 이것은 큰 의미가 있다. 산업 표준 프로토콜을 채택했다는 것은 마이크로소프트의 솔루션이 아닌 다른 벤더의 OS 및 제품들과의 호환성 측면이 한층 강화되었다는 것을 의미하기 때문이다.

디렉터리라고 하는 것은 마이크로소프트뿐만이 아니라 모든 벤더가 고려해야할 부분이 될 것이므로 한 기업이 전체 기업환경에서의 '글로벌 디렉터리(Global Directory)'를 필요로 한다면 여러 가지 시스템이 섞여 있는 이기종(異機種)에서도 Active Directory는 만족할만한 성능을 발휘해 줄 것이다. 또 다른 측면으로는 기업내에서 개발되는 인트라넷 어플리케이션의 경우 역시 디렉터리를 필요로 하는데, Active Directory는 표준 프로토콜을 채택함으로써 이러한 경우에도 예전에 비해 보다 용이하게 기업이 Active Directory를 선택하도록 유도할 것이다.

Active Directory로 구현할 수 있는 그리고 현재 기업들이 구현하고 있는 확장성을 그림으로 표현해 보았다.

<그림13-2>에 언급된 하나하나의 요소들을 살펴보면 우리가 기업네트워크에서 필요로 하는 대부분의 업무 및 시스템들이 Active Directory와의 연관성을 가진 것을 알 수 있을 것이다. 바꿔 말하면 Active Directory는 이러한 업무들과 연계하는 기업의 통합디렉터리 서비스를 제공함으로써 핵심 인프라가 될 수 있으며 관리자는 통합 디렉터리의 장점을 최대한 활용할 수 있을 것이다.

 이처럼 Active Directory는 단지 Windows 서버 및 PC 만을 관리하기 위한 것은 아니다. 기업의 IT인프라의 핵심 디렉터리 역할을 충분히 제공할 만한 무한한 확장성을 가지고 있다. Active Directory가 인프라로서 다방면에 걸쳐 연관성을 가지고 있기 때문에 도대체 AD가 무엇인가? AD를 가지고 무엇을 할 수 있을 것인가? 에 대한 해답을 찾는 것이 오히려 어려운 일이 되었다는 생각도 든다.

현재 AD를 사용하고 있다면 이것을 어떻게 더 확장해 볼 것인가에 대해 고민을 해야 할 것이고, AD를 사용하고 있지 않다면 먼저 기본인프라를 구축하는 것이 다른 어떠한 솔루션을 도입하는 것보다는 선행되어야 할 첫번째 과제이다.

이를 테면 그룹웨어가 도입 또는 재구축되는 시점이라면 당장은 AD가 관리적인 측면에서 도입되지 않더라도 그룹웨어용 디렉터리를 선정함에 있어 Active Directory를 물망에 올려야 할 것이라는 것은 관리자의 당연한 선택이다.

시스템 관리자 K씨는 요즘 Active Directory에 대해 다음의 고민을 하고 있다.

K씨는 AD에 대해서 전혀 모르지는 않지만 고민스럽기만 하다. AD에 대해서 자료를 찾아보았지만 막연함을 커지고 확신이 서질 않는다. 그러다 보니 K씨는 당면한 문제를 해결하기 손쉬운 해결을 하려고 한다. 00사의 00만 깔면 보안관리가 된다더라. △△사의 △△를 구매하면 윈도우 패치관리가 된다더라… 이렇듯 몇 가지 솔루션을 도입하여 당장 문제점을 해결한 듯 하지만 솔루션 도입후 채 1년이 지나지 않아 많은 돈을 들여서 도입한 솔루션이 그다지 제기능을 해 주지 못함을 알게 되는 경우가 많다. 그러는 와중에 또 다른 이슈를 해결하기 위해 검토하는 과정에서 AD 는 또 다시 언급이 될 것이다. 이제 K씨는 또 다시 같은 고민을 해야 한다.

지금 K씨에게는 단일문제점을 그때 그때 해결해 줄 포인트 솔루션과는 차별적으로 ‘인프라’측면의 인식이 필요한 것이며, 이를 위해서 AD에 대해 보다 명확한 이해가 필요한 상황이다.

이것은 비단 K씨의 경우만이 아니다.  “AD가 뭔가요? 우리 회사에 AD를 도입하면 어떤 효과를 가져다 줄까요? “ 요즘 필자가 고객들을 만나면서 가장 많이 듣는 질문중 하나이다. 간단한 듯 하지만 참 답을 내리기는 쉽지 않아서 늘 고민인 질문이기도 하다.

사실 이러한 질문을 하는 회사의 실무자들은 상당수가 AD에 대해서 비교적 이해를 잘 하고 있는 경우가 많다. 이 질문에 대한 배경에는 AD를 도입하기 위해서는 우선 담당자가 AD를 도입했을 때 과연 효과적일 것인지에 대한 확신이 있어야 하고, AD구축을 추진하기 위해서는 의사결정권자의 결재를 얻어야 할 것인데 그럴 수 있을만큼 AD를 잘 이해하기는 쉽지 않기 때문인 것으로 보인다.

1. 관리자 계정과 암호는 안전한가?

또한 작업을 마친후에 Administrator라는 일반 사용자 권한을 가진 계정을 하나 만들고 아주 어려운 패스워드를 할당해 두라. 패스워드를 기억할 필요도 없다. 당신이 사용할 계정이 아니다. 이 계정은 실제로 사용되기 위한 계정이 아니라 “감사(Audit)”를 통해서 모니터링 할 대상이다. 감사를 통해서 누군가가 이 계정을 공격하는 것을 발견했다면 당신은 해킹의 흔적이 있었음을 알 수 있을 것이다. 

2. 서비스팩, 핫픽스 패치에 인색하지 않는다.

3. 서버용 백신 프로그램을 설치한다.

바이러스는 데스크탑의 전용이 아니다 서버에게도 바이러스는 잘 동작한다. 그것도 아주 잘. 보통 흔히 구할 수 있는 백신프로그램들은 서버에서 동작하지 않는 경우가 많다. 서버용 백신 프로그램을 구입해야 할 것이다. 백신 프로그램의 특성상 지속적인 업데이트가 이루어지지 않으면 무용지물인 경우가 많으므로 신중하게 선택해야 한다. 트렌드마이크로, 안철수연구소, 하우리 등의 회사들이 개발한 백신 소프트웨어가 많이 사용된다.

4. 익명액세스 허용하지 말 것

당신의 서버에 대해서 다른 컴퓨터를 통해서 아래의 테스트를 해 보자. 아래의 내용은 명령프롬프트를 통해서 192.168.10.1 IPAddress를 사용하는 서버에 접근해 본 것이다.

서버에서 익명액세스를 허용하지 않기 위해서는 레지스트리를 편집함으로써 가능해진다. 레지스트리 편집기(regedt32.exe)를 열고 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa 키로 접근한다. 오른쪽 패널에서 Restricanonymous 값을 찾은다음 “0”으로 되어 있는 데이터를 “2”로 변경한다. (Windows NT 4.0 = 1, Windows 2000, 2003 = 2 를 사용)

5. 반드시 NTFS 파일시스템을 사용하자.

Windows NT기반의 시스템에서는 FAT와 NTFS파일시스템을 지원한다. FAT파일시스템에 비해서 NTFS파일시스템은 여러가지 장점을 제공한다. 또한 NTFS파일시스템의 퍼미션은 로컬에서 사용하는 파일서버 등에서만 적용되는 것이 아니다. 사용자가 HTTP나 FTP를 이용해서 웹을 통한 접근을 하더라도 IIS서버는 가장 마지막에 서버의 파일에 접근하는 사용자가 NTFS퍼미션이 있는지를 체크하기 때문에 보다 안전한 서버를 운영할 수 있도록 해 준다. 특정폴더의 모든 파일은 공개되지만 특별한 파일 몇 개는 접근을 거부시키는 방법은 바로 NTFS 퍼미션을 통해서 가능하다는 것을 상기하라.

6. 서버에 불필요한 소프트웨어는 설치하지 않는다.

서버는 서버용도로 사용해야 할 것이다. 서버에서 관리자가 일부 작업을 한다고 해서 관리자가 개인적으로 필요한 소프트웨어를 사용한다든가 하는 등의 일은 서버를 아프게 해서 빨리 죽게 하는데는 좋은(?) 방법이다.

 

7. DNS서버의 보안을 고려하자.

DNS서비스를 등한시 하는 경우가 있다. DNS서버가 문제가 발생하면 웹서비스, 메일서비스 등 전반적인 서비스가 동작하는데 문제가 생긴다. DNS에서 고려해야 할 보안을 제대로 챙기는 것도 전반적인 서버의 건강과 직결되는 문제이다.

 

-DNS 영역전송 보안 : 기본적으로 Windows 2000 DNS서버는 아무 서버에게나 영역전송이 허용되도록 되어 있다. 이것은 DNS가 가진 전체 레코드를 한꺼번에 외부로 유출시키는 결과를 초래할 수 있다. DNS영역전송을 보조DNS서버로만 제한하는 것이 필요하다. Windows Server 2003 DNS의 기본설정은 ‘영역전송 허용안함’이다. 좋은 설정이다.

 

-DNS 동적 업데이트 허용 않음 : DNS 동적업데이트는 관리상 유용한 기능인 것은 분명하지만 외부에 공개된 DNS서버가 동적업데이트를 허용하도록 구성되어 있으면 물리적인 방법에 의해 외부의 제3자가 의도하는 레코드로 업데이트가 일어날 수 있다. 회사의 www 호스트레코드가 엉뚱하게도 음란사이트가 운영되는 서버의 IP로 바뀌었다고 생각해 보라. 어처구니 없는 노릇이지만 얼마든지 일어날 수 있는 일이다. 외부DNS서버는 동적 업데이트를 허용하지 말아야 할 것이다.

 

-내, 외부 DNS영역설정 : DNS서버에 있어서는 최상위의 보안을 제공할 수 있는 방법이다. 외부에서 접근해야 하는 리소스들의 레코드를 가진 외부DNS와 내부의 사용자들만이 접근하는 리소스들의 레코드를 가진 내부DNS서버를 분리시킴으로써 보다 안전하게 DNS서버를 운영하는 방법이 될 수 있다.

 

8. 반드시 필요한 서비스만 오픈시킨다.

 

이것은 중요한 의미를 가진다. 웹서버를 구동중이라면 웹서비스를 정상적으로 운영하는데 필요하지 않은 그밖의 서비스들은 돌고 있지 않아야 한다. 웹서버를 철통같이 방어했다고 하더라고 해커가 다른 서비스에서 발견된 버그를 통해서 접근한다면 결국 서버는 안전하지 못하기 때문이다.

<참고> 일반적으로 시작되어 있는 서비스들중 꼭 필요하지는 않은 서비스들 Aleter Service Computer Browser Service DHCP Client DHCP Server Distributed File System FTP Publishing Service Messenger Indexing Service Remote Registry Service Routing and Remote Access Service Server Service Simple TCP/IP Service SMTP Service SNMP Service Task Scheduler Service Telnet Service Terminal Service Windows Media Services   * 서비스별 역할 및 사용하지 않을 때의 영향 참고 자료 http://www.microsoft.com/korea/technet/prodtechnol/windows2000serv/deploy/prodspecs/win2ksvc.asp )

 

9. IIS와 SQL서버는 분리시킨다.

 

많은 관리자들이 IIS에 대한 보안을 상당히 신경쓰면서도 그밖의 서비스에 대해서는 무관심한 경우가 있다. IIS에서 ASP를 사용하고 SQL서버가 하나의 서버에서 동작하고 있다면 IIS가 아닌 SQL서버에 대한 공격이 시도될 수 있다. 데이터베이스가 공격을 받게 되었을 때 그 영향은 상당히 치명적이다. IIS와 SQL서버를 분리시키고 SQL서버는 개인네트워크로 구성하면 그만큼 SQL서버에 대한 직접적인 공격에 대한 위험요소가 감소한다.

 

10. 웹서비스 폴더에서 불필요한 파일들을 제거한다.

 

- IISLockDown을 통하여 IIS의 반드시 필요하지 않은 서비스나 가상디렉터리를 삭제한다.

- 웹서비스 폴더내에 불필요한 파일을 삭제한다.(예, *.bak 등) 웹저작도구로써 많이 사용하는 몇몇 프로그램들은 html 파일을 생성하면 자동적으로 *.bak 라는 백업파일을 만들게 되는데, 이것을 그대로 방치하면 IIS서버에서 SQL서버의 ODBC연결에 사용되는 SQL로그인ID와 암호 등의 정보를 너무나 쉽게 알려주는 결과를 초래한다. IIS LockDown 툴은 IIS서버에서 사용하지 않는 서비스들과 폴더 등을 제거하여 보안에 도움을 줄 수 있는 도구이다.(관련자료 : http://www.microsoft.com/korea/technet/security/tools/locktool.asp ) 파일을 다운로드 받은 다음 테스트해 보자.

 

11. 계정 및 자원에 대한 감사정책을 구현하자.

소잃고 외양간 고치는 경우가 많은데 그중에 하나가 바로 감사정책이다. 시스템이 엉망이 된 후에 도대체 누가 언제 이런 일을 한 것인지 알고자 하지만 뒤늦은 후회일 뿐이다. 감사정책은 그러한 위험요소를 사전에 점검해 보고, 문제발생시 이벤트뷰어를 통한 보안로그를 통해서 로깅된 정보를 확인할 수 있다.

 

12. FTP서버 운영시 신중을 기하자.

- FTP를 사용하는 경우 쓰기권한을 제한하여 업로드를 하지 못하도록 설정한다.

- FTP를 사용하는 경우는 익명 계정 서비스만 권장한다. FTP 로그온 인증에 암호화가 이루어지지 않음을 고려해야 한다.

- FTP를 사용하는 경우 VPN 사용을 고려한다.

 

13. 주기적으로 점검하는 것을 잊지 않는다.

MBSA(Microsoft Baseline Security Analyzer)는 보안관련된 각종 구성정보들을 점검하고 대비할 수 방법을 제공하는 효율적인 도구이다. 시스템을 전체적으로 점검해 볼 수 있는 좋은 도구이니 활용할 수 있도록 한다.(참고: http://www.microsoft.com/korea/technet/security/tools/tools/mbsahome.asp)

<그림10-123. Microsoft Baseline Security Analyzer (MBSA) 도구>

서버에서 동작하고 있는 서비스를 모니터링 한다. 관리자가 의도하지 않은 서비스나 프로그램이 동작하고 있어서 서버에서 동작하는 프로세스가 있다면 바이러스나 백도어 해킹프로그램일 확률이 높다.

è  작업관리자, Fport ( http://www.foundstone.com http://www.securityfocus.com )

 

14. 무엇보다 가장 중요한 것은?

당신이 관리하는 서버에 대해 끊임없는 관심만이 상대적으로 안전한 서버를 운영할 수 있는 유일한 방법이라는 생각이 필요하다. 당신이 회사의 서버를 관리하는 동안 한차례도 해킹 등의 사고가 없었다면? 자랑할만한 기분 좋은 일이다.

10-8-1. FTP서비스

FTP(File Transfer Protocol)서비스는 대용량 파일전송을 위해 지원되는 서비스이다. 주로 사용자들은 웹호스트팅을 받는 서버에 자신의 홈페이지 데이터를 업로드 한다거나 자료실을 관리하는 용도로 사용하고 있다. 마이크로소프트의 IIS서버는 FTP서비스를 포함하고 있다. FTP서비스는 꼭 필요하지 않다면 보안상의 이유로 서비스를 제거하는 것이 바람직하다고 생각한다. IIS서버의 FTP서비스에 대한 기본구성을 살펴보도록 하자.

<그림10-105. FTP서버 등록정보1 >	인터넷 서비스 관리자 (ISM)를 열고 기본FTP사이트의 등록정보를 열었다. 몇가지 정보가 보인다. 인터페이스는 기본 웹사이트와 유사하므로 쉽게 접근할 수 있을 것이다. FTP서비스의 기본포트인 TCP포트21번이 설정되어 있다. FTP서버에서 이 TCP포트를 변경하였다면 FTP사용자는 바뀐 포트를 알아야만 FTP서버에 연결할 수 있다.
<그림10-106. FTP서버 등록정보 2 >	‘보안계정’탭을 열어보니 ‘익명연결허용’이 선택되어 있는 것이 보인다. 기본적으로 FTP서버에는 어느 누구나 접근하도록 설정되어 있다. 이것을 해제시키라는 것이 아니다. FTP사용을 할 때 보안을 필요로 하다면 ‘디렉터리 보안’ 탭을 이용하여 Access List 를 관리하는 것이 바람직하다.
<그림10-107. FTP서버 등록정보 3 >	‘메시지’탭에는 간단한 설정을 할 수 있도록 해 준다. 사용자가 로그인했을때의 메시지, 로그오프할때의 메시지, 허용된 연결을 초과했을때의 메시지 등을 설정한다.
<그림10-108. FTP서버 등록정보 4 >	‘홈 디렉터리’탭에서는 FTP서비스를 제공할 폴더를 지정할 수 있고, 해당 디렉터리에 대해서 어떤 권한이 할당되었는지를 보여준다. ‘쓰기’권한은 기본적으로 없다. FTP사용자가 파일 업로드를 할 수 있도록 하기 위해서는 ‘쓰기’를 허용해 주어야 한다. ‘쓰기’허용이 되어 있다고 무조건 FTP사용자가 파일 업로드를 할 수 있는 것은 아니다. FTP사용자는 최종적으로 NTFS파일시스템에 주어진 권한을 따르게 되기 때문에 NTFS파일시스템에 쓰기 권한이 없다면 파일 업로드는 불가능하다.   ‘쓰기’권한을 설정할때는 신중을 기해야 한다. NTFS허가, 디스크 할당량 관리 등을 통해서 피해를 최소화할 기본방안은 마련이 되어야 할 것이다.
<그림10-109. FTP서버 등록정보 5>	마지막으로 ‘디렉터리 보안’탭에서는 접근하는 클라이언트의 IP주소에 대해 접근제어를 관리할 수 있다.

FTP클라이언트로 접근하여 FTP서버에 접근해 보자. WS_FTP, CUTE_FTP등 사용자 인터페이스가 편리한 많은 FTP 클라이언트가 존재하지만, Windows2000에서 기본제공되는 클라이언트 유틸리티도 사용법을 익혀두는 것이 좋다. 어차피 모든 클라이언트 유틸리티는 결국 이러한 명령어 들을 보다 쉽게 구현하도록 만들어진 것이니 테스트 환경에서 편리하다.

10-8-2. FTP서버로 계정 서비스

IIS서비스에 포함된 FTP서버를 이용해서 회사의 직원들에게 각각 특정용량의 디스크 공간을 할당하고, FTP 클라이언트로서 접근해서 파일을 업로드할 수 있도록 하기를 원한다. 당연히 각각 자신의 데이터에만 접근할 수 있어야 하며 다른 사용자들은 접근할 수 없도록 해야 할 것이다. 많은 인터넷 서비스 회사들이 가입을 하면 사용자 계정별로 홈페이지 공간을 할당 받고, 자신의 홈페이지 관리를 위해서 FTP를 이용해서 파일을 업로드 하는 경우가 있다. 그러한 서비스를 별도의 써드파티툴을 이용하지 않고, IIS 의 기본기능으로 제공할 수 있다.

몇 가지 설정만 한다면 방법은 간단하다. 차근차근 접근해 보자.

일단 FTP사용자를 생성해 보자. 일반서버라면 '관리도구à컴퓨터관리'를 이용하고 도메인 컨트롤러라면 '관리도구àActive Directory 사용자 및 컴퓨터'를 이용하게 된다. 예제에서는 홍길동이라는 이름의 사용자를 'kdhong' 이라는 계정으로 생성하였다. 테스트 환경에서 사용자가 도메인컨트롤러에 구성된 FTP서버로 로그인을 하기 위해서는 서버측의 로컬정책을 수정해 주어야 한다. 이 내용에 대해서는 13장의 “대화형으로 로그온 할 수 없습니다.” 를 참고하라.
FTP 사용자들이 접근하게 될 폴더는 NTFS 파티션에 존재해야 한다. 만일 NTFS파티션이 없다면 새롭게 만들거나, 기존의 FAT 파티션을 NTFS 로 변경해야 한다. 명령프롬프트에서 convert 명령을 사용하여 변경할 수 있다. 테스트 환경에서 D: 는 NTFS 파티션으로 포맷이 되어 있다.
<그림10-110. FTP 계정서비스3>	FTP서버의 FTP루트 폴더는 기본적으로 C:\Inetpub\ftproot 폴더이다. Ftproot 의 NTFS퍼미션을 조정하여 Users 그룹을 제거시킨다. 이것은 사용자들이 자신의 FTP홈폴더로 접근한 다음 상위로 이동하여 FTP루트에 접근하는 것을 막아준다.   먼저 NTFS 파티션으로 포맷된 드라이브에 각 사용자별로 폴더를 생성하기 전에 FTP에서 사용자 홈폴더 저장소로 사용될 폴더를 하나 생성한다. 예제에서는 "ftpuser"라는 이름으로 폴더를 생성하였다.
<그림10-111. FTP 계정서비스4>	[확인]을 눌러서 설정을 마친다음 'ftpuser'아래에 FTP 사용자 계정과 같은 폴더이름을 생성한다. 홍길동의 사용자 계정이 'kdhong'이었으므로 폴더이름도 'kdhong'이 되어야 한다. 이것이 일치하지 않으면 사용자는 홈폴더를 사용할 수 없게 된다.
<그림10-112. FTP 계정서비스5>	위에서 생성한 사용자의 홈폴더인 kdhong의 등록정보를 열어서 모든 기본 사용권한을 제거하고, 홍길동(kdhong@windowsnetwork.msft)에게만 '모든 권한'이 주어질 수 있도록 사용권한 설정을 한다.
<그림10-113. FTP 계정서비스6>	폴더설정을 마쳤다. 이제는 IIS의 FTP 서비스 설정을 해야 한다. 관리도구-인터넷 서비스 관리자(ISM)을 실행하고, 기본 FTP사이트를 클릭한 다음 '새로 만들기à가상 디렉터리'를 선택한다.
<그림10-114. FTP 계정서비스7>	가상 디렉터리 별칭을 입력한다. 예제에서는 홍길동의 사용자 계정에 해당하는 kdhong을 입력했다.
<그림10-115. FTP 계정서비스8>	'FTP사이트 컨텐트 디렉터리'창에서 사용자를 위해 설정했던 물리적인 폴더가 있는 경로를 [찾아보기]를 이용하여 지정해 준다.
<그림10-116. FTP 계정서비스9>	가상 디렉터리에 대한 기본 권한은 '읽기(R)'로 되어 있다. 사용자가 파일을 업로드 할 수 있도록 '쓰기(W)'옵션을 체크해 준다. NTFS 퍼미션이 '모든 권한'으로 되어 있더라도 가상 디렉터리에 대한 액세스 권한이 '읽기(R) '만 지정되어 있으면 사용자가 FTP로써 서버에 접속하면 읽기 권한만 가지게 된다.
<그림10-117. FTP 계정서비스10>	구성이 완료되었다. [마침]을 눌러서 마법사를 마친다.
<그림10-118. FTP 계정서비스11>	마법사를 완료하면 기본 FTP 사이트 아래에 kdhong 의 가상 디렉터리가 생성된 것을 확인할 수 있다. FTP 사이트는 기본적으로 '익명 연결 (Anonymous Access)'을 허용하고 있다. 사용자별로 계정관리를 하려고 하기 때문에 익명연결을 허용하지 않도록 구성해야 한다. 기본 사이트의 등록정보로 접근하여 '보안계정'탭을 누른후 '익명 연결 허용'옵션의 체크박스를 해제한다.
<그림10-119. FTP 계정서비스12>	암호화를 하지 않는다는 메시지를 보여준다. 아쉽지만 그렇다. 네트워크 채널 보안을 위해서는 IPSec, VPN 등의 구현을 검토해야 한다. 계속해서 [예]를 선택한다.

이제 테스트를 해 보자. 이번에는 인터넷 익스플로어를 통해서 FTP 서버로 연결해 보자. 간단하게 웹 브라우저를 가지고 접근해 보자. 인터넷 익스플로러를 실행하고 ftp://ftp.windowsnetwork.msft 로 접근을 시도했다. 익명 연결이 허용되지 않으므로 사용자 인증을 위한 창이 뜬다. kdhong 으로서 로그인을 시도해 보았다.

인증이 마쳐지고, 화면에는 testftp.txt 파일이 보인다. kdhong의 홈폴더인 kdhong 폴더가 열린 것이다.

예제에서 확인해 본 바와 같이 서버측에서 NTFS 퍼미션 설정을 하고, FTP서비스를 구성했더니 사용자는 자신의 홈폴더를 가지게 되었다. NTFS퍼미션이 해당 사용자에게만 허용되었기 때문에 다른 사용자들은 이 폴더에는 접근을 할 수 없다. 처음의 시나리오를 만족하는 설정이 완료된 것이다.

이렇게 사용자의 FTP 홈폴더는 생성되었고, 사용자별로 용량제한은 어떻게 해야 할까? 이전 버전에서는 이러한 기능이 제공되지 않아서 많은 관리자들이 아쉬워 하던 점 중의 하나였다. Windows 2000 부터 ‘디스크 할당량’을 관리할 수 있도록 향상된 파일시스템을 제공한다. 자세한 설명은 ‘12장.파일서버관리’를 참고하라.

위와 같은 작업들을 대량으로 작업을 하기 위해서는 스크립팅 언어를 이용해 프로그래밍이 되어야 한다. 웹사이트를 통해서 가입자를 받고, 그 사용자들에게 자동적으로 계정서비스를 하도록 구성을 할 수가 있을 것이다. 응용하기에 따라서 얼마든지 원하는 방향을 끌어낼 수가 있을 것이다.

앞에서 잠깐 언급을 한 바는 있지만, 웹사이트의 등록정보에서 ‘디렉터리 보안’탭의 ‘익명 액세스 및 인증제어’에서 다루는 ‘인증’이라는 것은 클라이언트가 웹서버에 접근할 때 어떠한 인증을 지원하는지에 관련된 내용이었다. Windows 통합인증의 경우는 사용자가 서버로 제시하는 사용자 계정과 암호정보를 Kerberos, NTLM 등의 보안 인증 프로토콜을 통하여 처리하기 때문에 상대적으로 안전하다고 할 수 있지만, 그것은 어디까지나 인증에 한정된 개념일 뿐이다. 일단 인증이 이루어지고 나면 그때부터 서버와 클라이언트간의 데이터는 암호화되지 않은 트래픽으로 네트워크로 전송된다. 제3자에 대해 도청의 위험에 노출된다는 것을 의미한다.

또한 인터넷쇼핑몰이나 여러 커뮤니티 사이트등은 웹사이트에 접근하는 사용자들이 ‘로그인’을 해서 자신의 메일을 확인한다거나, 개인정보를 변경하는 등의 작업을 할 수 있도록 하고 있는데, 그렇다면 과연 이러한 로그인 정보를 제3자가 도청했다면 어떻게 할까? 또 만일 로그인 정보뿐만이 아니라, 인터넷 쇼핑몰에서 상품을 주문하고 자신의 신용카드 정보를 입력하여 결제를 하고 있는 상황이라면 웹서버로 전송되는 개인의 중요한 데이터가 안전하게 보내지고 있다고 믿을수 있을 것인가?

이름만 들으면 누구나 알 수 있을 만한 유명한 웹사이트들에서도 사용자들의 로그인 정보에 암호화를 지원하기 시작한 것은 그리 오랜일이 아니다. 늦었지만 바람직한 일이다. 아직 이러한 기본적인 ‘고객정보보호’에 대해서 무관심한 사이트가 너무도 많다. 또 우습게도 인터넷 쇼핑몰을 운영하고 있는 회사에서 고객들의 신용카드 번호와 같은 민감한 트래픽을 암호화조차 없이 인터넷을 통해서 데이터를 전송받고 있는 경우도 어렵지 않게 찾아볼 수 있다.

웹브라우저로부터 웹서버로 보내는 데이터, 그것은 로그인 정보일 수도 있고, 신용카드 번호, 유효기간, 게시판에 포스팅하는 글 등일수 있다. 이렇게 송신측에서 보내는 모든 데이터를 안전하게 전송하고자 할 때 ‘암호화(Encryption)’를 사용한다고 이야기한 바 있다. 3장.PKI 단원을 건너뛰었다면 잠시 책을 앞으로 돌려 3장의 내용을 먼저 이해하고 넘어오길 바란다.

이번 예제에서는 웹서버가 인증기관(CA)으로부터 발급받은 ‘인증서(Certificate)’를 이용해서 SSL서버를 구성하여 클라이언트가 https 프로토콜을 이용해서 안전한 통신을 할 수 있도록 네트워크 채널에 대한 보안의 기반을 마련하고자 하는 작업을 해 보도록 한다.

SSL서버 설치는 다음과 같은 순서로 진행된다.

10-7-1. CSR(Certficate Signing Request) 생성

SSL서버구성을 위해서 첫번째로 해야 할 일은 인증서를 발급받는 작업인데, 인증서를 발급받기 위해서는 SSL서버로 구성하고자 하는 웹서버에서 CSR (Certificate Signing Request; 인증요청서)을 생성하는 것이 선행되어야 한다. 이 과정은 어떠한 인증기관(CA)을 이용하든지 동일한 방법이다. 인증기관과는 무관하게 웹서버에서 이루어지는 작업이기 때문이다. 먼저 CSR을 생성해 보자. 이 CSR을 가지고 인증서를 발급해줄 CA에 접근하여 인증서를 발급받을 수 있다.

<그림10-57. CSR(인증 요청서) 생성 1 >	웹서버에서 SSL을 적용하고자 하는 웹사이트의 등록정보를 연다.
<그림10-58. CSR(인증 요청서) 생성 2 >	등록정보의 ‘디렉터리 보안’탭을 확인한다. [인증서 보기]가 비활성화되어 있음을 기억하자. [서버인증서]를 클릭한다.
<그림10-59. CSR(인증 요청서) 생성 3 >	웹 서버 인증서 마법사가 실행된다. [다음]을 누른다.
<그림10-60. CSR(인증 요청서) 생성 4 >	서버 인증서 화면에서는 ‘새 인증서를 만듭니다.’를 선택한다.
<그림10-61. CSR(인증 요청서) 생성 5 >	‘요청을 지금 준비하지만 나중에 보냅니다.’를 선택한다. 이 옵션이 CSR을 생성하게 해 준다.
<그림10-62. CSR(인증 요청서) 생성 6 >	인증서 이름을 입력하고, 인증서 요청에 포함시킬 공개키의 길이를 결정한다. 필자는 1024비트를 선택했다. [다음]으로 진행한다.
<그림10-63. CSR(인증 요청서) 생성 7 >	인증서에 들어갈 조직, 조직구성단위 등을 입력한다. 나중에 이 웹서버에 연결하는 클라이언트들이 인증서를 통해서 확인하게 될 정보이므로 명확하게 입력할 필요가 있다.
<그림10-64. CSR(인증 요청서) 생성 8>	사이트 일반 이름 화면이 열리는데, 아주 중요한 옵션이다. 예제에서는 ssl.windowsnetwork.msft 을 입력했는데 클라이언트는 https://ssl.windowsnetwork.msft  URL을 이용해서 접근하게 될 것이다. 이 이름이 잘못되면 웹서버로 접근하는 클라이언트측에서는 인증서의 이름이 웹사이트의 이름과 맞지 않는다는 에러 메시지를 보여주게 된다.
실제로 웹서비스를 할 웹사이트의 이름을 정확히 입력해 준다. 예를 들어서 쇼핑몰을 운영하는 www.mscs.co.kr 웹사이트가 있다고 가정하자. 클라이언트가 이 쇼핑몰에 처음 접근할 때는 http://www.mscs.co.kr URL을 이용해서 접근할 것이다. 이러한 경우는 암호화된 통신이 이루어지지 않는다. 사용자 계정과 암호를 넣고 로그인을 하는 트래픽도 마찬가지로 대부분의 경우 암호화를 하지 않고 있다. 앞으로 관리자들의 의식이 바뀌어 가고 고쳐가야 할 부분이다.   하지만 사용자가 쇼핑을 하면서 구입하고자 하는 아이템을 장바구니에 담고 최종적으로 결제하고자 할때는 [결제하기]버튼을 누르면 그때는 https 프로토콜을 이용해서 SSL통신을 하게 되는데(모든 쇼핑몰 사이트가 그렇다는 것은 아니다. 안타깝게도 사용자의 신용카드 정보와 유효기간 등을 요구하는 결제페이지가 암호화를 지원하지 않는 사이트도 보았다), 만일 이 회사의 결제 페이지의 이름이 payment.mscs.co.kr 이었다면 그때 클라이언트가 접근하게 되는 URL은 https://payment.mscs.co.kr 이 될 것이다. 그렇다면 인증서에도 발급대상의 이름란에는 payment.mscs.co.kr 가 들어있어야 한다. 이렇게 인증서의 발급대상 주소와 인증서가 실제 사용되는 웹사이트의 주소가 정확하게 일치하지 않으면 이 서버에 접근하는 사용자는 인증서 관련한 에러를 만나게 될 것이고 뭔가 믿음이 가지 않는 꺼름직한 기분을 느끼게 될 것이다.
<그림10-65. CSR(인증 요청서) 생성 9>	‘지역정보’란에 회사의 위치에 해당하는 국가명, 시/도, 구/군/시 등의 정보를 입력하고 [다음]으로 진행한다.
<그림10-66. CSR(인증 요청서) 생성 10 >	인증서 요청 (CSR) 파일을 저장할 위치를 지정하고 요청파일의 이름을 잘 기억해 둔다. 기본적으로 파일이름은 certreq.txt 로 저장된다.
<그림10-67. CSR(인증 요청서) 생성 11 >	이제 거의 마쳤다. ‘요청 파일 요약’정보를 잘 확인하고 [다음]을 누른다. 잘못 되어서 인증서 재발급을 받아야 한다면 인증서 발급 기관 (CA)에 추가비용을 지불해야 할 것이다. [다음]을 눌러서 마법사를 마친다.
<그림10-68. CSR(인증 요청서) 생성 12>	위에서 지정한 위치로 이동하여 certreq.txt 파일을 열어보았더니 알 수 없는 글자가 잔뜩 쓰여진 것을 알 수 있다. ‘------ BEGIN NEW CERTIFICATE REQUEST ------‘로 시작하고, ‘------ END NEW CERTIFICATE REQUEST ------‘ 로 끝나는 메시지를 담고 있다.

10-7-2. 서버 인증서 발급 요청

앞에서 생성한 CSR을 이용해서 인증기관(CA)에 인증서 발급요청을 해야 한다. 예제에서는 Windows 2000 독립실행형 루트CA로 구성된 www.windowsnetwork.msft 에게 인증서 발급요청을 하고 있다.

<그림10-69. 인증서 발급요청 1 >	인증서 발급 요청을 위해 웹브라우저를 실행하고 http://www.windowsnetwork.msft/certsrv URL을 이용하여 접근하였다. WindowsNetwork CA 가 응답하고 있는 화면이다. ‘인증서 요청’을 선택하고 [다음]을 눌렀다.
<그림10-70. 인증서 발급요청 2>	요청 유형을 결정하는 화면이 나온다. ‘고급인증서요청’을 선택했다.
<그림10-71. 인증서 발급요청 3 >	‘고급 인증서 요청’ 화면에서 두번째 메뉴인 ‘Base 64 인코딩 CMC 또는 PKCS #10파일을 사용하여…’을 선택하고 [다음]을 누른다.
<그림10-72. 인증서 발급요청 4 >	‘인증서 또는 갱신 요청 제출’화면에서 ‘저장된 요청’상자에 CSR이 생성된 certreq.txt 파일의 내용을<그림10-68> “------ BEGIN NEW CERTIFICATE REQUEST ------‘부터 ‘------ END NEW CERTIFICATE REQUEST ------‘까지 포함하여 복사하여 웹브라우저의 창으로 붙여넣기 하고 [제출]을 누른다.
<그림10-73. 인증서 발급요청 5 >	‘인증서 대기중’화면이 보인다. 인증기관으로 인증요청은 전송되었고 인증기관이 보류중이라는 상태를 보여준다. 이 화면은 인증기관의 정책에 따라 달라질 수 있다. Windows Server 2003 독립실행형 CA의 경우는 기본설정이 인증서 발급요청에 대해 대기중으로 처리된다.

<참고> 윈도우 서버 인증기관(CA)의 인증서 발급과정   웹서버에서 SSL서버를 사용하고자 인증기관으로 인증요청을 보냈을 때 인증기관에서는 어떻게 처리되는지 확인해 보자. 인증기관 서비스가 동작하고 있는 서버에서 ‘관리도구à인증기관’을 실행했다. <그림10-74. 보류중인 인증서 발급 요청>   예제의 화면에서는 WindowsNetwork CA 의 인증서 관리콘솔을 보여주는데, 보류중인 요청을 보니 오른쪽 패널에 하나의 인증서 발급 요청이 올라와 있는 것을 확인할 수 있다. 마우스 오른쪽 클릭하여 ‘모든 작업à발급’을 선택했다. <그림10-75. 발급된 인증서 확인>   이제 발급된 인증서 항목에서 인증서를 확인할 수 있게 되었다.

<그림10-76. 인증서 발급요청 6 >	인증서 발급이 되었는지 확인하기 위하여 다시 웹브라우저를 이용하여 http://www.windowsnetwork.msft/certsrv 로 접근했다. 이번에는 보류중인 인증요청을 확인하려는 것이니 마지막 메뉴인 ‘대기중인 인증서 요청의 상태표시’를 선택하고 [다음]을 누른다.
<그림10-77. 인증서 발급요청 7 >	현재 보류중인 요청을 보여준다. 링크를 클릭한다.
<그림10-78. 인증서 발급요청 8 >	인증서가 발급되었다. 인증서를 다운로드 할 수 있다. ‘인증서 다운로드’를 선택한다.
<그림10-79. 인증서 발급요청 9>	인증서를 다운로드 한다는 메시지가 팝업되었다. [저장]을 누른다.
<그림10-80. 인증서 발급요청 10 >	저장할 위치를 결정한다. 접근의 편의를 위해서 바탕화면에 저장하였다. 이제 인증서를 발급받는 작업을 마쳤다.

10-7-3. SSL서버 구성

지금까지 인증서를 발급받는 작업을 마쳤다. 이제 이 인증서를 이용해서 SSL서버를 구성해 보도록 하자. 다시 인터넷 서비스 관리자(ISM)를 이용해서 접근한다.

<그림10-81. SSL 서버 구성 1 >	SSL서버를 구성하고자 하는 웹사이트의 등록정보를 열고 ‘보안통신’항목을 연 다음, [서버 인증서]를 클릭한다.
<그림10-82. SSL 서버 구성 2 >	웹서버 인증서 마법사가 열렸다.
<그림10-83. SSL 서버 구성 3 >	처음 CSR을 생성하기 위해 접근했을때와는 다른 화면을 보여준다. 웹서버에서 기존에 CSR을 생성하고 인증서를 설치하기 위해 보류중이기 때문에 다른 화면이 보이는 것이다. ‘보류 중인 요청을 처리한 다음 인증서를 설치합니다.’를 선택하고 [다음]을 누른다.
<그림10-84. SSL 서버 구성 4 >	인증서의 위치를 묻는 화면이 나온다.
<그림10-85. SSL 서버 구성 5 >	바탕화면에 저장해 둔 certnew.cer 파일을 지정해 준 다음 [다음]을 누른다.
<그림10-86. SSL 서버 구성 6 >	SSL통신에 사용할 포트번호를 묻고 있다. 기본포트인 443 포트를 사용하고자 한다.
<그림10-87. SSL 서버 구성 7>	인증서 요약 정보를 보여준다. 잘 확인해 본 후 [다음]을 누른다. 이제 웹 서버 인증서 마법사를 완료하였다.

<참고> 웹서버에서 ‘신뢰된 루트 인증기관’ 확인   웹서버가 발급받은 인증서를 발급해준 인증기관(CA)이 ‘신뢰된 인증기관’의 목록에 있는지 확인해 보도록 하자. 베리사인 등의 상업용 외부CA로부터 인증서를 발급받았거나, 도메인환경에서 웹서버와 인증기관 모두가 같은 도메인에 있을 때 인증서를 발급받은 것이라면 신뢰된 인증기관의 목록에서 인증기관의 이름을 찾을 수 있을 것이다. 이 경우는 바로 SSL서버구성을 시작해도 좋다.   그렇지만 테스트환경에서 웹서버와 인증기관은 아무런 관계가 없다. 또한 테스트에서 사용한 인증기관은 자체적인 내부CA로 구성된 인증기관이므로 이대로 사용하면 웹서버에서 SSL서버 구성하는 작업을 진행하기 전에 먼저 웹서버에서 자신이 발급받은 인증서를 발급해준 인증기관을 ‘신뢰된 인증기관’의 목록에 추가시키는 작업을 해 줘야 한다. 상업용 CA로부터 받았더라도 아래의 인터페이스를 통해서 확인해 보도록 하자. <그림10-88. 신뢰된 인증기관 구성1> ‘제어판à인터넷 옵션à내용à인증서’를 클릭한다. <그림10-89. 신뢰된 인증기관 구성2> 신뢰된 루트 인증기관의 목록을 확인하였다. 당신의 인증서를 발급해준 인증기관의 이름을 찾을 수 있는가? 찾을 수 없다면 [가져오기]를 클릭한다. <그림10-90. 신뢰된 인증기관 구성3> 인증서 가져오기 마법사가 시작된다. <그림10-91. 신뢰된 인증기관 구성4> 인증기관으로부터 발급받은 인증서의 위치를 찾는다. 바탕화면에 certnew.cer 로 저장했음을 기억하자. 인증서에는 발급대상의 정보도 있지만 더불어 발급해준 인증기관의 전자서명도 들어있다. 웹서버에서 사용할 인증서를 인증기관이 전자서명을 통해서 ‘신뢰성’을 부여하는 것이다. 가져올 파일의 위치를 잘 확인한 다음 [다음]을 누른다. <그림10-92. 신뢰된 인증기관 구성6> 인증서 저장소의 위치를 묻는다. ‘모든 인증서를 다음 저장소에 저장’을 선택하고 ‘신뢰된 루트 인증기관’을 선택하였다. <그림10-93. 신뢰된 인증기관 구성8> 인증서를 저장소에 추가하겠다는 메시지가 나왔다. 잘 읽어보자. [예]를 선택하면 인증서 가져오기가 완료된다. 이제 ‘신뢰된 루트 인증기관’목록에서 Secure.pe.kr CA의 이름을 찾을 수 있다. 이상으로 신뢰된 루트 인증기관 구성을 마쳤다.

계속해서 웹서버에 SSL통신을 하도록 구성을 해 보자.
<그림10-94. SSL 서버 구성 1 >	이제 서버에 인증서가 설치되었으니 이 인증서를 이용해서 SSL통신을 하도록 구성을 하면 되는데, 이것은 웹사이트, 가상 디렉터리, 특별한 파일 하나, 어떠한 부분에서라도 할 수 있다. 웹사이트 전체에서 구현하려면 웹사이트에서 등록정보로 접근하고, 특정 가상디렉터리에만 적용하려면 가상디렉터리에서, 특정 파일만 SSL통신을 하도록 하려면 해당 파일을 클릭하고 등록정보로 접근한다.   예를 들어서 웹서버에 사용자 로그인 처리할때는 SSL통신을 통해서 사용자 정보를 보호하겠다고 생각했다면 로그인을 처리하는 asp파일에만 SSL인증을 구현할 수도 있다.   예제에서는 웹사이트 등록정보를 열고 ‘디렉터리 보안’탭을 열었다. 이제 보안통신 항목에 [인증서 보기]가 활성화된 것을 확인할 수 있다. 인증서를 확인하기 위해서 [인증서 보기]를 눌렀다.
<그림10-95. SSL 서버 구성 2>	인증서를 확인해 보니, 용도는 ‘원격 컴퓨터의 신분을 확인합니다.’로 되어 있고, 발급대상은 ‘ssl.windowsnetwork.msft’, 발급자는 ‘WindowsNetwork CA’이다. 이상없는 인증서이다. 추가로 자세히탭과 인증경로탭도 확인해 보라. 여러가지 정보를 확인할 수 있을 것이다.   다시 ‘디렉터리 보안’탭으로 돌아와서 ‘보안통신’항목의 [편집]버튼을 클릭했다.
<그림10-96. SSL 서버 구성 3 >	보안통신 화면에서 ‘보안 채널 필요(SSL)’항목을 체크했다. 이제 이 서버는 https 프로토콜을 통해서 접근하는 클라이언의 요청만 받아들일 것이다.

10-7-4. SSL서버 연결 테스트

늘 그렇듯이 빠트릴 수 없는 것. 무엇인가 설정을 했으면 잘 동작하는지 테스트를 해 보는 것은 필수적인 과정이다. SSL서버에 연결이 제대로 되는지 테스트를 해 보자.

<그림10-97. SSL 서버 연결 테스트1>	웹브라우저를 열고 http://ssl.windowsnetwork.msft사이트에 접근했다. ‘보안채널을 통해서 보아야 한다’는 메시지를 출력한다. 웹서버에서 <그림10-96>과 같이 ‘보안 채널 필요’를 선택한 결과이다.
<그림10-98. SSL 서버 연결 테스트2>	다시 https 로 바꿔서 접근해 보았다. https:// ssl.windowsnetwork.msft 를 이용해서 접근했더니 이번에는 그림처럼 ‘보안경고’ 창이 팝업된다. 클라이언트는 https 프로토콜로 접근하고 있고 SSL서버로부터 서버인증서를 확인하였는데, 인증서에 문제가 있음을 알려주는 경고창이다. 3가지 항목중 맨 위의 항목인 ‘신뢰여부를 결정한 적이 없는 회사가 발행한 인증서’라는 경고메시지가 보일 것이다.   클라이언트쪽에는 이미 ‘신뢰된 인증기관’의 목록이 있는데 이 목록에서 ssl.windowsnetwork.msft 사이트에서 가지고 있는 인증서를 발행한 인증기관의 이름을 찾을 수 없었기에 이러한 경고메시지를 내 보내는 것이다.   하지만 경고메시지의 맨 위에있는 내용은 ‘이 사이트와 교환한 정보는 다른 사람이 보거나 변경할 수 없습니다.’라는 내용을 보여준다. 암호화를 통한 SSL통신에는 문제가 없다는 것을 나타낸다.
<그림10-99. SSL 서버 연결 테스트3>	웹서버의 인증서를 확인하기 위해 [인증서 보기]를 눌렀다. ssl.windowsnetwork.msft 사이트에서 내부CA로부터 발급받은 인증서를 사용했기 때문에 생기는 에러메시지이다. 한가지 사실을 알게 되었다. 내부CA를 사용하더라도 SSL 통신에는 문제가 없다. 다만 가장 중요한 문제는 ‘신뢰성’의 여부에 달려 있는 것이다.
<그림10-100. 신뢰할 수 있는 인증기관1>	이대로는 뭔가 찜찜한 기분이 남아있다. 어떻게 해결할 것인가? Active Directory 도메인 환경에서는 그룹정책을 이용하여 사용자들의 PC에 인증기관의 인증서를 ‘신뢰할 수 있는 인증기관’에 추가시키는 작업이 가능하다. 그러면 깔끔해지겠지만, 도메인 환경이 아니라면 약간의 작업을 해 줄 필요가 있다. 서버에서 그랬던 것처럼 클라이언트도 동일하게 웹브라우저를 열고 http://www.windowsnetwork.msft/certsrv 인증서 서비스 웹페이지에 접근한 다음 ‘CA인증서, 인증서 체인 또는 CRL다운로드’를 선택한다.
<그림10-101. 신뢰할 수 있는 인증기관2>	<그림10-101>화면에서 ‘이 CA 인증서 체인을 설치하십시오’ 링크를 클릭한다.
<그림10-102. 신뢰할 수 있는 인증기관3>	인증서를 추가하도록 [예]를 선택하여 신뢰할 수 있는 루트인증기관에 WindowsNetwork CA를 추가하고자 한다.
<그림10-103. 신뢰할 수 있는 인증기관4>	설치를 마쳤다.
<그림10-104. SSL 서버 연결 테스트1>	다시 https://ssl.windowsnetwork.msft 로 접근해 보았다. 아무런 에러 메시지가 없이 SSL웹사이트가 잘 열리는 것을 확인할 수 있다. 웹브라우저 아래의 상태표시줄에 노란 자물쇠를 더블클릭하여 인증서를 확인할 수 있다.

웹서버가 한대인데 여러 개의 사이트를 운영할 수 있을까? 흔히들 고려하는 기능이다. 많이 사용되는 기능이기도 하다. IIS가 제공하는 기능을 통해서 다중웹사이트를 호스팅하는 방법을 정리하고자 한다. 설명보다는 한가지 예제를 통해서 처음부터 마지막까지 구현하는 것으로 마치도록 할 것이다. 차분히 읽어보면 기능을 익힐 수 있을 것이라 생각한다.

예제로 쓰일 시나리오를 잠깐 설명한다. 당신은 웹호스팅회사의 시스템 관리자이다. A.com B.com c.com도메인을 사용하는 회사가 웹호스팅을 받고자 하여 그들에게 웹서비스를 제공하고자 한다. 한대의 서버로 3개의 웹사이트를 모두 서비스하는 것을 구현하고자 한다.

당신은 a.com b.com c.com을 위해서 서버 한대에 3개의 웹사이트를 생성했다. 작업을 마친 화면을 보도록 하자.

위의 화면은 IIS가 설치된 Windows Server 2003에서 “인터넷 서비스 관리자”관리도구를 실행한 화면이다. 현재는 기본 웹사이트만 있는 상태이다.

<그림10-37. a.com b.com c.com 웹사이트>

a.com, b.com, c.com 각각의 도메인의 네임서버는 웹서버의 IP 주소로 하나의 웹서버를 가리키고 있어야 하는 것은 당연하다. 예제에서는 하나의 DNS서버에 각각 도메인을 추가해 두었다.

<그림10-36>에서 마우스 오른쪽 단추를 이용하여 a.com 사이트를 동작시키기 위해 ‘시작’을 눌렀다.

<그림10-38. 포트 중복으로 인한 바인딩 에러 메시지>

<그림10-38>과 같은 에러메시지가 나오면서 시작되지 않음을 확인할 수 있다. IIS5.0에 비해서는 상당히 적극적인 에러메시지를 보여 준다. “이 사이트에 구성한 포트를 다른 사이트에서 사용중인 것 같다”고 한다. 메시지에 해결책이 들어있다.

에러메시지의 원인을 확인하고 해결책을 찾아보도록 하자.

<그림10-39. a.com 사이트 등록정보>

a.com사이트의 등록정보를 열어보면 <그림10-39>와 같다. TCP포트가 80번이다. A.com 웹사이트를 생성하기 전에 이미 존재하는 기본 웹사이트도 역시 TCP포트 80번을 사용하고 있었음을 기억해 보라. 새롭게 추가한 웹사이트인 a.com사이트가 기본웹사이트와 동일한 포트넘버를 사용함으로써 포트충돌이 발생한 것이다.

TCP/IP 환경에서 통신을 이해하는데 계층구조를 이해하면 접근이 쉬워진다. 무슨 소린가 하는 독자는 이 책의 1장.TCP/IP Network 단원을 참고하라. "Inetinfo process (웹서비스)àTCP Port NumberàIP AddressàMAC Address" 의 흐름으로 어플리케이션부터 물리적인 네트워크 어댑터 카드까지 데이터를 전송할 수 있게 된다. 이것을 하나의 흐름으로 묶어주는 과정을 바인딩(Binding)이라고 한다. 이미 기본웹사이트à하나의 IP Addressà80 포트로써 바인딩되어 서비스가 시작되어 있는데, 동일한 포트를 다른 웹사이트에 바인딩하려는 시도를 했기 때문에 충돌이 발생하고 사이트를 시작하지 못했다는 에러를 보여주는 것이다. 그렇구나.. 그럼 충돌이 발생안하도록 하면 될거 아냐?? 맞다. 그럼 된다.

방법은 있다. 3가지의 방법을 고려해 볼 수 있다.

10-6-1. TCP Port 변경

일단 DNS서버에서는 3개의 이름이 192.168.0.16 과 같이 하나의 IP Address를 가리키도록 설정을 해야한다. 웹서버가 한대이니 IP Address역시 하나이다. 당연히 www.a.com, www.b.com, www.c.com 은 하나의 IP Address를 가리키도록 DNS설정이 되어야 한다. 이들 세개의 도메인이 하나의 DNS서버에 있어야 한다는 것은 아니다. DNS가 하는 일이라고는 www.a.com의 IP Address를 요청했을 때 IP Address를 응답하는 ‘단순한’ 역할을 할 뿐이다. 그 DNS서버들이 어디에 있는가는 문제가 되지 않는다.

첫째로 포트 번호를 변경하는 방법을 생각할 수 있다. 아래의 <그림10-40>의 예제에서는 TCP포트 번호를 '8002'로 변경하였다.

그 다음 중지되어 있는 사이트를 클릭하고 마우스 오른쪽 버튼을 눌러 [시작]을 클릭한다. 그러면 이번에는 에러메시지가 없이 사이트가 시작됨을 확인할 수 있다.<그림10-41>

클라이언트로서 잘 접근이 되는지 테스트를 해 보자. URL 창에 http://www.a.com 만 입력하면 에러가 발생한다. URL창에 http://www.a.com 라고 입력하는 것은 http://www.a.com:80 과 같은 의미이다. 웹서버의 Well-known port인 80번이 생략되어 있는 것이기 때문이다. 위에서 80번 포트를 8002번으로 변경했으므로 당연히 http://www.a.com:8002 라고 입력을 해 주어야만 한다.

잘 동작하긴 하지만 뭔가 석연찮다. 이게 뭐야? 라는 소리가 나올 독자도 있을 것이다. 기껏 웹사이트를 개발했는데, 사용자들이 이 웹사이트로 접근하려면 8002라는 숫자까지 기억하도록 해야만 된다는 얘기네? 간단한 방법이긴 하지만, 실제로 제시한 해결책으로서 포트변경은 완전한 방법은 되질 못한다. 사용용도라고 하면, 이미 있는 기본 웹사이트 내에서 다른 사이트로 하이퍼링크 형태로 제공되는 경우(예를 들면 인터넷 쇼핑몰에서 링크를 클릭하여 결제페이지로 이동한다거나 하는)라면 어차피 사용자들이 직접 주소를 입력할 필요가 없으니 상관없겠지만, 별도의 홈페이지로서 서비스하기엔 URL로서 부족한 면이 있다. 다른 방법도 알아보자.

10-6-2. 복수 IP Address 할당 (각 사이트마다 다른 IP사용)

다음으로 사용할 수 있는 방법은 사이트마다 서로 다른 IP Address를 할당하여 바인딩을 성공시키는 방법이 있다. 하나의 웹서버에 여러 개의 IP Address를 할당하는 것이다. 하나의 서버가 복수의 IP를 가지는 방법은 두가지가 있다. 서버에 필요한 개수만큼 Network Adapter card를 추가하고 각각 다른 IP Address를 할당할 수도 있고, 하나의 Network Adapter card에 여러 개의 IP Address를 할당할 수도 있다. 후자의 예를 들어서 설명하도록 한다.

예제의 상황은 다음과 같다.

하나의 네트워크 어댑터 카드에 위에서 필요한 3개의 IP Address를 할당해야 한다. ‘네트워크 및 전화접속연결’을 통해서 TCP/IP 등록정보를 연 다음, [고급]버튼을 눌러서 [IP설정]탭으로 접근한다. [추가]버튼을 이용하여 <그림10-43>의 예제처럼 필요한 IP Address를 추가한다. 예제에서는 기본 IP Address인 192.168.0.16 외에 192.168.0.15와 192.168.0.17 의 IP Address를 추가하였다.

IP Address를 추가한 다음, 명령프롬프트에서 ipconfig를 수행하면 아래와 같은 결과를 얻을 수 있다.

그리고, DNS에서 호스트 이름분해가 잘 이루어지는지를 확인하기 위해 Ping 테스트를 해 보았다.

각각의 사이트가 서로 다른 IP Address로 응답이 잘 오고 있다. 이제 TCP/IP설정은 마쳤다.

다음엔 “관리도구à인터넷서비스관리자 (ISM)”를 이용하여 각각의 웹사이트를 위한 설정을 한다.

<그림10-46. IP 주소 및 포트설정>	"IP주소 및 포트설정"화면에서 기본설정은 (지정하지 않은 모든 IP) 라는 설정으로 되어 있다. IP주소 드롭다운콤보박스를 클릭하면 앞에서 설정한 IP Address들을 볼 수 있다. www.c.com 웹서버로 할당된 IP Address인 192.168.0.17을 선택한다.
<그림10-47. 3개의 웹사이트 구성이 완료된 화면>	이제 웹사이트가 추가되었고, 잘 동작하고 있음을 보여준다. 웹사이트를 시작하는데 문제가 있었다면 c.com 옆에 (중지됨)이라는 메시지를 보여줄 것이다. 같은 방법으로 나머지 사이트도 추가를 했다.
<그림10-48. www.c.com 접근 테스트>	이제 테스트를 해 보자. 웹 브라우저를 띄우고 URL창에 "http://www.c.com"을 입력해 보았다. DNS를 통해서 www.c.com 의 IP Address가 192.168.0.17인 것을 알아내고, http 프로토콜로서 웹서버에 홈페이지를 요청하는 get 명령어를 전송한다. 페이지를 볼 수가 있게 되었다.

위에서 접근한 방법은 웹사이트마다 서로 다른 IP Address를 할당함으로써 다중웹사이트 호스팅을 가능하도록 하였다. 웹사이트가 10개라면 서버는 10개의 IP Address를 가지고 있어야 한다. 만일 회사에서 IP Address의 여분이 없다면 어떻게 할까? 혹은 Network Adapter Card 하나에 IP Address 하나만 가지고 여러 웹사이트를 호스팅하고 싶다면 어떻게 해야 할까? 그때는 마지막으로 소개하는 “호스트 헤더”를 이용한 방법이 유용하다. 이 방법이 가장 널리 사용되고 있는 방법이기도 하다. 독자들도 위에서 설명한 내용을 이해할 필요는 있지만 다음에 소개할 방법을 먼저 고려해 보아야 할 것이다.

10-6-3. 호스트헤더 기법

하나의 웹서버에서 여러 개의 웹사이트가 동작하기 위한 조건은 바인딩이 잘 이루어지도록 충돌을 막아주는 설정들을 추가하면 된다. 위에서 포트를 변경한다거나, IP Address를 다르게 가져가는 등의 방법이 그러했다. 이번에는 모든 설정을 기본설정으로 그대로 둔 상태에서 “호스트 헤더”라는 추가정보를 입력함으로써 충돌을 없애고 웹사이트를 정상적으로 시작시킬 수 있는 방법을 살펴보자.

이제 웹서버는 하나의 IP Address만 가지고 있을 뿐이다. 192.168.0.16 이 웹서버의 IP Address라고 가정하자.

<그림10-49. DNS레코드 확인을 위한 테스트>	DNS서버의 설정은 www.a.com www.b.com www.c.com 의 DNS호스트 레코드가 더 이상 제각각 다른 IP Address로 설정되어서는 안된다. 192.168.0.16이라는 하나의 IP Address를 가리키도록 설정을 한다. <그림10-49>에서는 Ping 테스트를 이용하여 이들 세개의 호스트이름이 192.168.0.16 이라는 하나의 IP Address로 설정되어 있음을 확인했다.
<그림10-50. 호스트헤더 설정1>	a.com 웹 사이트에서 접근해 보자. 등록정보를 열고 ‘웹사이트’탭에서 ‘웹 사이트 확인’항목에서 [고급]을 누른다.
<그림10-51. 호스트헤더 설정2>	‘고급 웹 사이트 확인’화면을 보면 세번째 상자에 ‘호스트 헤더 이름’을 입력할 수 있다. 여기에 www.a.com 이라고 입력한 다음 [확인]을 누른다.
<그림10-52. 호스트헤더 설정3>
같은 방법으로 www.b.com, www.c.com 도 작업을 마쳤다. 화면에서 보면 세개의 웹사이트는 정상적으로 시작되었고, 오른쪽 패널에서는 호스트 헤더이름들이 설정되어 있음을 보여준다.
<그림10-53. 호스트헤더 설정4>	http://www.a.com 을 이용해서 테스트해 보았다. a.com 웹사이트가 열린 것을 확인할 수 있다.
이렇게 호스트헤더를 사용했을때는 클라이언트가 다른 호스트이름을 통해서 이 서버에 접근했을 때는 서버는 응답하지 않고 에러메시지를 내 보낸다. 예를 들면 www.b.com 의 IP Address가 192.168.0.16이고, test.b.com 의 IP Address역시 192.168.0.16 이라고 가정했을 때 클라이언트가 http://www.b.com 으로 접근하면 해당 웹사이트가 응답하지만, http://test.b.com 으로 접근을 하면 비록 DNS쿼리가 정상적으로 이루어져 웹서버의 IP Address인 192.168.10.1로 접근이 된다고 하더라도 웹서버는 해당 웹사이트의 홈페이지를 제공하지 않는다.   그렇기 때문에 만일 하나의 웹사이트가 여러 개의 이름으로 접근하도록 설정해야 할 필요가 있다면 호스트헤더를 추가로 입력해 주어야 한다. 예제로 들어보자. www.b.com 사이트에 클라이언트가 http://b.com URL을 이용해서도 웹사이트에 접근하도록 해 주고자 한다.
<그림10-54. 호스트 헤더 추가구성>	인터넷 서비스 관리자를 실행하고 b.com 웹사이트의 등록정보를 열고, 호스트헤더 이름항목의 www.b.com 아래에 “b.com”을 추가했다.
<그림10-55. b.com 호스트 레코드 생성>	DNS서버에서도 한가지 작업이 있어야 한다. b.com은 b.com도메인에 공백의 이름으로 할당된 하나의 호스트레코드이다. DNS관리콘솔을 열고 b.com 관리영역에 호스트이름을 비워두고 192.168.0.16을 가리키도록 A레코드를 생성했다. <그림10-55>를 참고한다.
<그림10-56. b.com 사이트 접속>	테스트를 해 보았다. 웹브라우저를 실행하고 http://b.com 으로 접근해도 http://www.b.com 으로 접근할때와 동일한 웹사이트가 펼쳐지는 것을 확인할 수 있다. 실습이 성공했다.

하나의 웹서버에서 여러 개의 웹사이트를 운영하는 방법으로 이러한 호스트 헤더를 이용한 방법이 가장 많이 사용되고 있는 방법이다. 다만 호스트헤더가 설정된 웹사이트에서는Secure Socket Layer (SSL)을 지원하지 않는다. SSL에서는 http 요청이 암호화되어 호스트 헤더가 감추어지기 때문이다.

하지만 이러한 사항들만 생각한다면 간단한 설정으로 하나의 서버에서 여러개의 웹사이트를 호스팅 할 수 있다는 것은 큰 매력이 아닐 수 없다. 대부분이 기능이 그렇듯이 우리가 흔히 생각하는 많은 기능들은 이미 구현이 되어 있다.

하나의 웹 서버는 다수의 웹사이트를 가질 수 있고, 하나의 웹사이트는 다수의 가상 디렉터리를 가질 수 있다. (웹 서버 > 웹 사이트 > 가상 디렉터리)

웹 서비스는 사용자가 웹 브라우저를 실행시켜 서버의 데이터를 요청할 때 그 요청과 서버의 데이터 사이에서 인터페이스 역할을 한다. 또한 웹 서버는 웹사이트와는 별개로 가상디렉터리라는 것을 제공하고 있는데, 천리안의 예를 들어보면 천리안은 가입자들에게 일정공간의 홈페이지를 서비스해 준다. 회원들의 홈페이지를 호스팅하는 웹사이트는 http://user.chollian.net 이다. 회원들은 http://use.chollian.net 아래에 ~runner02, ~windows 등의 별도의 폴더로 분리된 공간을 할당받게 되고 그들의 홈페이지에 접속하기 위해서는 http://user.chollian.net/~runner02 의 URL을 사용하여 접근하게 된다. 이때 ~runner02은 user.chollian.net 웹사이트의 가상디렉터리 라고 부른다. 그렇다면 왜 ‘가상’디렉터리일까? 그것은 실제 물리적인 폴더의 위치와는 상관이 없이 웹 서버에서 논리적으로 생성하였다는 데서 나온 이름이다.

또한 이러한 가상디렉터리는 물리적인 디렉터리와도 일치한다. 예를 들면 wwwroot라는 기본폴더내에 test라는 이름의 서브폴더가 있었다면 서버의 기본웹사이트에는 test라는 가상디렉터리가 생성된 것을 확인할 수 있다. 그런가 하면 전혀 다른 위치의 물리적인 폴더를 wwwroot 폴더아래에 가상디렉터리로 생성할 수도 있다.

가상디렉터리를 생성하기 위해서는 가상디렉터리를 생성하고자 하는 웹사이트를 통하여 접근한다.

<그림10-28.가상 디렉터리 생성 1>	웹사이트를 추가하는 것과는 분명히 구분해야 한다. 가상 디렉터리를 만들고자 하는 웹사이트에서 마우스 오른쪽 클릭하여 ‘새로 만들기à가상 디렉터리’를 선택한다.
<그림10-29.가상 디렉터리 생성 2>	가상 디렉터리 별칭을 입력하는 화면이다. 이것은 중요한 이름이다. http://www.windowsnetwork.msft사이트에서 생성되는 wonsuk 이라는 가상디렉터리는 http:// www.windowsnetwork.msft/wonsuk 이라는 URL을 가지게 된다.
<그림10-30.가상 디렉터리 생성 3>	Wonsuk 이라는 가상디렉터리를 실제 물리적인 폴더와 연결시켜주어야 한다. 예제에서는 D:\Inetpub\wwwroot\wonsuk 폴더를 선택했다.
<그림10-31.가상 디렉터리 생성 4>	액세스 권한은 ‘읽기’와 ‘스크립트 실행’이 기본설정이다. 그대로 두고 [다음]으로 진행하면  가상 디렉터리 생성이 왼료된다.
<그림10-32.가상 디렉터리 접근 테스트1>	인터넷 서비스 관리자를 통해서 보면 ‘Wonsuk’이라는 가상 디렉터리가 생성된 화면을 보여준다. 마우스 오른쪽 클릭하여 ‘웹 페이지로 보기’를 선택한다.
<그림10-33.가상 디렉터리 접근 테스트2>	웹브라우저가 실행되고, http:// www.windowsnetwork.msft/wonsuk URL을 가리키는 것을 볼 수 있다. 홈페이지가 잘 열리는 것을 볼 수 있다.
<그림10-34.윈도우 탐색기를 통한 가상 디렉터리 생성1>	사실 IIS는 가상디렉터리 생성작업을 너무나 쉽게 지원해 주고 있다. 이번에는 윈도우 탐색기를 통해서 접근해 보자.   윈도우 탐색기를 열고 가상디렉터리로 만들고자 하는 물리적인 폴더를 찾은 다음 마우스 오른쪽 클릭하여 ‘공유 및 보안’을 선택한다.
<그림10-35.윈도우 탐색기를 통한 가상 디렉터리 생성2>	‘웹 공유’탭을 선택하고, 공유위치에서는 가상 디렉터리를 생성할 웹 사이트를 선택한 후 ‘별칭’을 결정해 주면 가상디렉터리 생성이 된다. 이것은 인터넷 서비스 관리자(ISM) 관리도구를 이용해서 작업을 하는 것과 동일한 결과를 보여준다.