웹서버가 한대인데 여러 개의 사이트를 운영할 수 있을까? 흔히들 고려하는 기능이다. 많이 사용되는 기능이기도 하다. 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) 관리도구를 이용해서 작업을 하는 것과 동일한 결과를 보여준다.

웹서버는 웹 클라이언트의 요청을 받아서 그들이 요청하는 파일을 제공하는 일을 한다. 무작정 아무에게나 파일을 주지는 않는다. 웹서버는 클라이언트가 접근을 할 때 제일 먼저 사용자 인증이라는 과정을 거치게 된다. 다만, IIS의 기본설정이 어느 누구라도 접근할 수 있는 “익명 액세스”를 허용하고 있기 때문에 인증이 없는것처럼 보일 뿐이다. 회사의 홍보페이지나 상업용 사이트라면 당연히 홈페이지를 보여주는데 별도의 계정과 암호를 요구해서는 안 될 것이다. 우리가 일반적으로 어떤 사이트에 들어가서 사용자 계정과 암호를 넣어서 로그인을 하게 되는데, 그것과는 구분해야 한다. 그러한 사이트의 홈페이지에 접근할 때는 인증을 요구하지 않는다는 것을 생각하면 될 것이다.

<그림10-20. 웹사이트 등록정보 – 디렉토리 보안 탭>	웹사이트의 인증에 관련된 작업은 웹 사이트 ‘등록정보’의 ‘디렉토리 보안’탭에서 설정할 수 있다. 디렉토리 보안탭은 ‘익명 액세스 및 인증제어’ ‘IP주소 및 도메인 이름 제한’ ‘보안통신” 이라는 3가지 구성으로 되어 있다. 첫번째 [편집]을 눌러 보았다.
<그림10-21. 인증 방법 구성>	‘인증방법’화면으로 접근했더니 ‘익명 액세스’라는 옵션을 볼 수 있다. 기본적으로 체크되어 있다. 윈도우 서버 2003가 설치되면 기본적으로 “IUSR_컴퓨터이름”형식의 계정이 생성되어 있다. 이 계정이 익명액세스를 허용했을 때 사용되는 계정이다. [편집]을 클릭하여 확인할 수 있다.
웹사이트가 회사홍보용이나 상업용이 아닌 내부적으로 사용하기 위한 용도의 컨텐츠를 담고 있다면 익명액세스를 허용하는 것은 바람직하지 않다. 혹은 웹기반의 인트라넷 사이트가 구성되어 직원의 근태관리, 급여관리, 회계관리 등이 이루어진다면 역시 마찬가지이다. 그때는 회사의 직원들이 각각 계정과 암호를 가지고 접근하도록 구성할 필요가 있을 것이다. 익명액세스를 해제하여야 한다. 그러면 계정이 없는 사용자는 더 이상 이 웹사이트에 접근할 수 없다.   인증된 액세스 방법으로는 Windows 통합인증, Windows 도메인 서버의 다이제스트 인증, 기본인증,.NET Passport인증이라는 4가지 방법이 제공되는데 ‘Windows 통합 인증’이 기본값이다. 이 Windows 통합인증은 익명액세스가 허용되지 않는 경우나, 익명액세스가 허용되어 있더라도 웹페이지의 특별한 파일이 IUSR_computer계정에게 NTFS퍼미션이 허용되지 않는 경우에 사용된다. 이름에서 느껴지는 것처럼 Windows 통합인증은 웹사이트에 접근하는 사용자의 현재 Windows 로그온 정보를 그대로 사용한다. 해당 정보를 이용해서 인증에 문제가 있다면 그 때 로그인 창을 팝업시키게 된다. 멤버서버로 설정된 웹서버에 도메인의 계정으로 로그온한 사용자가 접근하고 있다면 사용자는 별도의 인증과정을 거칠 필요 없이 웹서버의 자원에 접근하는 것이 가능하다는 것이다. 이 Windows 통합인증은 Kerberos, NTLM 등의 암호화된 인증을 사용한다. 기본적으로는 Microsoft 의 운영체제에서만 지원한다. 거의 대부분의 회사환경에서 인증을 원한다면 이 Windows 통합인증을 사용하면 무방하다.   “기본인증(암호를 일반 텍스트로 보냄)”옵션은 인증을 하긴 하지만 클라이언트가 서버에게 보내는 인증 요청은 Clear text (평문)로 전송되기 때문에 제3자에 의한 도청의 위험이 있다. 좋지 않은 방법이다. 하지만 가장 뛰어난 호환성이 제공되므로 모든 벤더의 웹브라우저의 버전들과 호환이 된다.   “Windows 도메인 서버의 다이제스트 인증”은 기본인증보다 한단계 향상된 보안을 제공한다. 암호를 전송하기는 하지만 실제로 암호 자체를 전송하는 것이 아니라 MD5 해시함수를 이용한 해시를 인증에 사용하고 있다. 제3자가 도청을 하더라도 해시함수의 특성상 해시를 이용해서 원본을 알기는 어렵기 때문에 안전하다고 할 수 있다. 이 다이제스트 인증을 사용하기 위해서는 Windows 2000 도메인 즉, Active Directory가 필수적으로 있어야 한다. 사용자는 Active Directory에 계정을 가지고 있어야 하며 Active Directory에 저장되는 사용자 계정의 암호는 시스템 자체에서 암호화되지 않은 일반문서 형태로 저장되어 있어야만 사용될 수 있다.   .NET Passport 인증은 IIS6.0에서 추가된 기능이다. 많이들 사용하는 메신저 프로그램인 MSN Messenger를 사용하기 위해서는 MSN, Hotmail등의 계정에 가입하거나 본인의 메일주소를 Passport로 등록해야 한다는 것을 알고 있을 것이다. 그러한 Passport 계정을 IIS6.0에서 인증하도록 하겠다는 것이다. 결국 마이크로소프트에서 전세계 사용자들을 대상으로 등록받은 그야말로 글로벌 디렉터리인  Passport 를 IIS6.0 웹서버에서 인증용으로 사용할 수 있도록 하겠다는 것인데, 참으로 놀라운 일이 아닐 수 없다. 사용자들이 Passport 계정 하나만 가지면 되도록 하겠다는 야심찬 도전이라고 생각된다. 발표당시에는 상당한 이슈가 되었던 것이 사실이지만 현재 시점에서의 보편성에 대해서는 다소 부정적이다. 늘 그렇듯이 새로운 도전이 보편화되기 위해서는 어느 정도 진통을 겪어야 하는 만큼 분위기가 무르익어야 될 것으로 보여진다.
<그림10-22. .NET Passport 인증>	웹서버에서 .NET Passport 인증을 선택했을 때 (익명인증 옵션 제거) 클라이언트가 접근하면 <그림10-22>의 인증창을 볼 수 있다. 기존에 가진 Passport ID와 암호를 입력하면 로그인이 가능하다.
<그림10-23. 해독가능한 암호화 저장>	<그림10-23>을 보면 Active Directory 사용자 및 컴퓨터 스냅인을 이용하여 yhsong 이라는 계정의 옵션을 들여다 보고 있다. ‘해독가능한 암호화를 사용하여 암호를 저장합니다.’ 옵션이 체크되어 있어야만 ‘다이제스트 인증’을 사용할 수 있다.
<그림10-24. IP 주소 액세스 제한>	<그림10-20>에서 이번에는 ‘IP주소 및 도메인 이름제한’에 대한 설정을 살펴보자. 유용한 설정이다. 기본적으로 IIS는 IP제한이나 도메인 제한을 전혀 하지 않고 있다. 사내의 게시판을 위해 사용되는 웹서버라면 외부에서는 아예 접속자체를 차단시킬 수 있는 방법이 된다. 혹은 외부의 특별한 몇몇 컴퓨터들의 IP Address를 기준으로 필터링하는 것도 가능하다. 세가지 유형으로 제한할 수 있는데, 특정한 컴퓨터(IP Address), 컴퓨터그룹(네트워크ID), 도메인이름 중 하나를 선택할 수 있다.
<그림10-25. 단일 컴퓨터 액세스 허가>	대부분의 보안제품들이 그렇듯이 액세스 제한방법은 2가지를 사용할 수 있다. 최대의 보안(모든 것을 막고 필요한 것만 열어주는 방법)과 최소의 보안(모든 것을 열고 필요한 것만 제한하는 방법) 을 사용할 수 있다. 메시지가 다소 헷갈리긴 하지만 논리적으로 생각하면 쉽게 이해할 수 있다. 예제에서는 최소한의 보안을 적용한 것으로 192.168.0.16을 제외한 모든 IP를 허용한 것을 보여준다. 도메인 이름을 이용한 제한을 사용하고자 할때는 DNS서버의 “역방향 조회 영역”의 구성이 되어 있어야 한다.
<그림10-26.IP 주소 액세스 제한 >	192.168.0.16 클라이언트에서 해당 웹사이트에 연결하면 <그림10-26>과 같은 에러메시지를 만나게 된다.
<그림10-27.사용자 지정 오류 메시지>	이러한 경우 뿐만 아니라 IIS서버에는 다양한 오류 메시지가 미리 정의되어 있다. %WinDir%\Help\iisHelp\common를 확인하면 수많은 html 문서들을 볼 수 있다. 이 html문서를 편집해도 좋고, 새로운 오류 메시지 문서를 만들어서 웹사이트에 연결시킬 수도 있다.

 

이상으로 IIS의 웹사이트 등록정보에 대해서 필수적인 사항들을 위주로 몇 가지 살펴보았다. IIS서버의 온라인 도움말 페이지를 참고하기 바란다. 이미 MS는 방대한 수준의 자료를 도움말을 통해서 제공하고 있다.

10-2-1-3. 사용자의 웹서비스 요청을 전환시키자.

위의 기본적인 설정들을 활용하여 필요한 상황을 하나 예를 들고자 한다. 필자의 개인 홈페이지인 www.secure.pe.kr 사이트를 예로 들어보자. 필자의 사이트는 http://www.secure.pe.kr 로 접근할 수 있고, http://secure.pe.kr 의 주소로도 접근할 수 있다. 이것이 접근이 되고 안 되고는 일단은 DNS의 호스트 레코드에 달려있다. 클라이언트가 웹브라우저의 주소창에 http://secure.pe.kr 이라고 입력했다면 먼저 secure.pe.kr 호스트의 IP Address를 찾으려는 시도를 하고, 당연히 이 요청은 DNS서버로 가게 될 것이다. 그러면 DNS서버는 secure.pe.kr 이라는 레코드를 가지고 있어야만 IP Address를 응답할 수 있게 된다. 이 레코드는 secure.pe.kr 이라는 도메인의 (공백의) 문자를 할당한 레코드이다. 만일 웹서버의 IP가 192.168.0.16 이라면 secure.pe.kr 을 관리하는 DNS서버에는 www 호스트레코드와 (공백의) 호스트레코드가 있어야 하고 이들은 공히 192.168.0.16 을 가리키고 있어야 하는 것이다.

<그림10-12>는 DNS서버에서 Secure.pe.kr 관리영역에 공백의 문자열을 가진 호스트를 생성하면서 192.168.0.16 이라는 IP Address 를 지정해 주고 있다. 그러면 이제 클라이언트는 http://www.secure.pe.kr , http://secure.pe.kr 둘 중 어떤 주소를 이용해서라도 웹사이트에 접근이 가능해 졌다.

추가로 지금 하고자 하는 작업은 클라이언트가 http://secure.pe.kr 을 입력해서 접근했을 때 자동적으로 클라이언트의 주소창에 보여지는 주소를 http://www.secure.pe.kr 로 바뀌도록 처리하려고 한다. 이럴때 IIS의 URL 리디렉션 기능을 쓰면 된다. 이것을 가능하게 하려면 IIS서버에서는 2개의 웹사이트가 만들어져야 한다. 하나의 사이트는 사이트의 모든 컨텐츠를 담은 www.secure.pe.kr 사이트이고, 하나의 사이트는 www.secure.pe.kr 로 URL 리디렉션을 하게 되는 secure.pe.kr 사이트이다. 예제에서 이미 www.secure.pe.kr 웹사이트는 구축이 되어 있다고 가정한다. 추가로 secure.pe.kr 웹사이트를 만든다음 URL리디렉션을 해 보도록 하자.

<그림10-13. URL 리디렉션 사이트 생성 1>	www.secure.pe.kr 로 URL 리디렉션을 담당할 secure.pe.kr 웹사이트를 생성한다. 인터넷 서비스 관리자에서 서버이름을 마우스 오른쪽 클릭하고 ‘새로 만들기à웹사이트’를 선택한다.
<그림10-14. URL 리디렉션 사이트 생성 2>	웹사이트의 이름으로는 Secure.pe.kr 이라고 입력했다.
<그림10-15. URL 리디렉션 사이트 생성 3>	IP주소 및 포트 설정 화면에서 ‘이 사이트의 호스트 헤더’란에 ‘Secure.pe.kr’가 들어감을 주의깊게 보라. Secure.pe.kr URL을 통해서 접근하는 클라이언트에게는 이 웹사이트를 열어주겠다는 것을 나타낸다.
<그림10-16. URL 리디렉션 사이트 생성 4>	홈디렉터리를 결정한다. URL 리디렉션 할 사이트이므로 텅빈 폴더를 사 용해도 좋다.
<그림10-17. URL 리디렉션 사이트 생성 5>	웹 사이트 액세스 권한을 기본설정을 그대로 두고 [다음]으로 진행하면 웹 사이트 만들기 마법사가 완료된다.
<그림10-18. URL 리디렉션 사이트 생성 7>	Secure.pe.kr 웹사이트가 추가된 것이 보인다. 웹 사이트의 등록정보를 연다.
<그림10-19. URL 리디렉션 사이트 생성 8>	등록정보를 열고 ‘홈 디렉터리’탭을 연 다음 ‘URL로 리디렉션’옵션을 지정한다. ‘다음으로 리디렉션’항목에는 http://www.secure.pe.kr 을 입력했다. 클라이언트가 http://secure.pe.kr 로 접근하면 http://www.secure.pe.kr 로 URL 리디렉션이 될 것이다. 클라이언트 웹브라우저의 주소창에는 URL이 전환되는 모습이 보이게 된다.

10-2-1. 웹서버 기본설치 및 구성

윈도우 서버 2003을 특별한 설정변경없이 기본설치를 이용해 설치하였다면 IIS는 설치되지 않는다. 

“프로그램추가/제거àWindows구성요소à응용프로그램서버à인터넷정보서비스(IIS)로 접근하여 IIS를 설치할 수 있다.

IIS를 설치한 후 인터넷 익스플로어를 이용하여 웹서버의 IP주소로 접근해 보았다.  <그림10-2>과 같이 ‘준비중’이라는 메시지를 보여주는 페이지를 보여줌을 알 수 있다.

IIS를 컴퓨터에 설치하고 난후 IIS가 서비스할 기본 위치는 C:\Inetpub 폴더이다. 웹서버를 위한 폴더는 C:\Inetpub하위폴더인 wwwroot 폴더이다<그림10-3>

웹프로그래머가 새로운 웹사이트를 개발하였다면 그 파일들을 저장할 위치도 바로 이 위치이다. 이 위치에 당신이 만든 웹페이지를 저장하면 기본 웹사이트에서 여러분의 홈페이지를 서비스해 줄 것이다.

지금부터 웹사이트의 등록정보를 통해서 관리를 위해 필요한 사항들을 챙겨보도록 하자. 웹사이트의 등록정보로 접근하는 방법은 두 가지가 제공된다. 인터넷 서비스 관리자 (ISM)를 이용하는 방법과 관리웹페이지를 이용하는 방법이다.

10-2-1-1. IIS 관리도구

관리도구메뉴에서 인터넷 서비스 관리자를 실행한다. 아래의 <그림10-4>와 같은 화면이 열린다.

이 관리도구를 이용하여 당신은 새로운 웹사이트를 추가하고 사이트의 각종 설정들을 변경하는 작업을 할 수 있다. 또 다른 방법은 웹인터페이스를 통해서 접근할 수 있는 관리웹페이지를 이용하는 방법이 있다. 관리웹페이지를 이용하기 위해서는 IIS설치시에 관리웹페이지 옵션을 선택해 주어야 한다. <그림10-4>의 왼쪽패널에서 웹사이트 아래에 있는 Administration 을 마우스 오른쪽클릭하여 ‘속성’을 열었다.

관리페이지의 SSL포트를 확인하고 (예제에서는 8098이다) 웹브라우저에서 https://192.168.0.16:8098 을 입력했다.

관리 웹사이트가 열린다. 서버이름, 관리자설정 등 다양한 설정을 할 수 있도록 인터페이스를 지원하고 있다. 이 관리 웹사이트를 이용하여 인터넷 서비스 관리자를 통해서 할 수 있는 작업들을 할 수 있다. 이전 버전에 비해 인터페이스가 상당히 깔끔해 지고 기능도 추가되었지만 IIS서버의 관리를 위해 관리웹페이지는 잘 이용되지 않는다. 터미널 서버를 통한 원격관리가 많이 이루어지는데 그렇다면 쓰지 않는 관리 웹페이지가 열려있을 필요가 없다. IIS를 설치할 때 사용여부를 판단하여 불필요하게 설치하지는 않도록 하자.

10-2-1-2. 웹사이트 등록정보

웹사이트의 등록정보를 열어보았다. 여러 개의 탭이 보이는데, 먼저 ‘문서’탭을 열어 보았다. 4개의 파일의 목록이 보인다.

웹서비스도 결국 클라이언트가 서버에게 자신이 원하는 ‘파일’을 요청하고 웹서버는 사용자가 파일에 접근할 권한이 있는지 확인한 다음 ‘파일’을 넘겨주는 작업을 하는 것이다. 복잡한 웹어플리케이션들이 구동되는 요즈음의 웹서비스에 비할바는 아니지만 단순히 생각하면, 결국 파일서비스라는 얘긴데 다만 HTML (Hyper Text Markup Language) 문서형식의 파일을 웹브라우저가 받아서 화면에 뿌려주는 형태로 동작하게 된다. 하지만 보통 우리가 어떤 웹사이트에 접근할 때 http://www.secure.pe.kr 이라는 URL을 통해서 접근할 뿐, 직접 http://www.secure.pe.kr/default.htm 이라는 형태로 주소를 사용하지는 않는다. 그렇다면 웹서버 입장에서는 사용자가 특별한 파일을 요청하지 않고 디렉터리에 접근했을 때 기본적으로 제공할 파일이 정의되어 있어야 할 것이다. 웹사이트 등록정보의 ‘문서’탭은 그러한 파일이름을 지정해 둔 것이다. 웹서버는 해당 디렉터리에서 ‘문서’탭에 있는 순서대로 파일을 검색하여 사용자의 요청에 응답한다. 보통 커뮤니티 사이트로부터 공짜로 얻게 되는 10~20MB정도의 홈페이지 공간을 이용할 때 ‘루트 폴더에 index.htm 파일이 있어야 합니다.’ 등의 안내문을 보는 경우가 있을 것이다. 바로 이러한 파일이 제공하는 웹페이지를 가리켜서 ‘홈페이지’라고 부른다. IIS에서의 기본파일의 이름은 ‘default.htm”이다.

다음에는 ‘웹사이트’탭을 열어보자. 웹사이트 확인, 연결, 로깅사용이라는 세가지 화면으로 구성되어 있는데 웹사이트 확인을 보면 TCP포트, SSL포트 등의 정보를 확인할 수 있다. 기본적으로 웹서버는 TCP 80번 포트에서 서비스된다. 우리가 보통 웹브라우저를 실행하고 http://www.secure.pe.kr 라는 URL(Uniform Resouce Locator)을 이용해서 접근했을 때 실제로는 http://www.secure.pe.kr:80 으로 접근하는 것과 동일하다. ‘80번 포트르 http 요청을 합니다’ 라는 뜻이 된다. 만일 당신이 웹서비스의 TCP포트를 임의로 80번이 아닌 8000번으로 바꾸었다고 가정하면 클라이언트는 더 이상 http://www.secure.pe.kr라는 URL을 통해서 해당 웹서버에 접근할 수 없다. 대신에 http://www.secure.pe.kr:8000 이라는 URL을 이용해야만 접근이 가능하다다. SSL포트 443번은 http 가 아닌 https 를 이용해서 접근할 때 서비스되는 포트이다. SSL서버의 설정은 뒤에서 다룬다.

IP주소 항목도 중요한 의미를 가진다. 이것이 잘못 설정되어 있으면 아예 웹페이지가 열리지 않는 경우가 생긴다. 기본적으로 “(지정하지 않은 모든 IP)”라고 되어 있다. 웹서버의 IP Address로 192.168.10.1과 192.168.10.2  이렇게 2개의 IP가 할당되었다고 가정했을 때 “지정하지 않은 모든 IP “라는 기본설정을 가지고 있으면 2개중 어떠한 IP Address로 찾아오는 http요청이라도 이 웹사이트는 정상적인 응답을 한다. 하지만 당신이 특별히 “지정하지 않은 모든 IP” 대신에 192.168.10.1과 같이 IP Address를 지정하였다면 더 이상 192.168.10.2 로 오는 http 요청은 이 웹사이트가 응답하지 않는다. 오직 192.168.10.1 로 오는 요청에만 응답을 할 뿐이다. 웹사이트가 처리하는 특별한 IP Address를 지정해야 할 필요가 있다거나, 하나의 웹서버에서 여러 개의 웹사이트가 동작하고 있는 경우에만 변경하도록 한다.

나머지는 보통 기본설정을 사용한다. 기본적으로 IIS는 로깅을 이용한다. W3C 확장 로그 파일 형식이 기본인데 계정로깅을 이용하려면 반드시 이 로그형식을 사용해야 한다. [등록정보]를 사용하여 로그파일의 경로, 로깅되는 정보등을 변경해 줄 수 있다.

다음은 ‘홈 디렉터리’탭을 열어보자<그림10-9> 꼭 필요한 몇가지 설정들을 담고 있다.

먼저 가장 위의 메뉴에서는 3개의 라디오 버튼으로 구성된 메뉴들을 볼 수가 있는데, 이것은 웹서버의 웹사이트가 웹서비스를 하는 파일이 어디에 위치해 있는지를 지정해 주는 일을 한다. 웹서버는 세가지 경우의 서비스를 할 수 있는데, 아래의 <그림10-10>을 참고해서 설명한다.

개념적으로 이해할 필요가 있다. <그림10-10>에서 보면 물리적인 웹서버는 하나이다. 이 하나의 웹서버는 여러 개의 복수 웹사이트를 호스팅 할 수 있다. IIS설치와 함께 구성되어 있는 ‘기본 웹 사이트’ 단지 웹서버가 서비스하는 하나의 웹사이트일 뿐이다.  웹사이트는 각각 독립적인 컨텐츠를 가진 다른 사이트와는 아무런 연관성이 없는 독립적인 기능을 한다. 만일 하나의 웹 서버가 3개의 웹사이트를 서비스하고 있다면 이론적으로는 세대의 웹서버가 각각 하나씩의 웹 사이트를 서비스하고 있다고 생각해도 좋다. 이들 웹사이트들을 클라이언트가 요청했을 때 웹서버는 클라이언트가 원하는 파일을 넘겨줘야 하는데, 이때 각 웹사이트들은 클라이언트가 원하는 컨텐츠를 어디서 가져올 것인지 3가지 메뉴에 의해 선택된다.

기본설정은 ‘이 컴퓨터에 있는 디렉터리’로 되어 있다. 그리고 아래쪽의 ‘로컬 경로’에서는 D:\Inetpub\wwwroot 라고 되어 있는데, 이것은 클라이언트가 이 웹사이트로 요청을 보내면 D:\Inetpub\wwwroot 위치에서 서비스할 파일을 찾아서 보내주겠다는 것을 의미한다. 만일 이 사이트의 주소가 www.secure.pe.kr 로 되어 있었다면 클라이언트가 http://www.secure.pe.kr URL을 이용해서 http 요청을 보냈을 때 이 웹서버는 D:\Inetpub\wwwroot 위치에서 앞에서 보았던 ‘문서’탭의 목록을 순서대로 찾는다. 이 위치에 default.htm이라는 파일이 있었다면 이 파일을 클라이언트에게 전송하게 될 것이다.

두번째 옵션인 ‘다른 컴퓨터에 있는 공유디렉터리’를 사용하면 이 웹사이트의 컨텐츠가 웹서버에 저장된 것이 아니라 네트워크에 있는 다른 서버에 저장되어 있는 경우이다. 예를 들어 웹사이트의 컨텐츠가 blueapple 이라는 서버의 secure 라는 공유폴더에 저장되어 있다면 당신은 \\blueapple\secure 라는 UNC Path를 이용하여 지정해 주어야 한다.

마지막 옵션인 ‘URL로 리디렉션’을 선택하면 이 웹사이트로 들어오는 요청을 다른 웹사이트로 전환시키는 것이 가능하다. 사용용도는 응용하기 나름이다. 이를 테면, 클라이언트가 접속해야 되는 웹페이지가 너무 길어서 사용자가 접근하기가 어렵다거나, 회사의 도메인 이름이 여러 개인데 하나의 웹사이트로 집중시킨다거나 하는 경우에 쓸 수 있다.

기본적으로 IIS의 “URL리디렉션”기능은 클라이언트이 웹브라우저의 주소창에 고정식 주소를 지원하지는 않는다. 예를 들어 http://www.secure.pe.kr 웹사이트가 http://forgarden.tistory.com 으로 URL 리디렉션이 되고 있을 때, 클라이언트가 웹브라우저의 주소창에 http://www.secure.pe.kr 을 입력해서 접근하게 되면 웹서버에서는 http://forgarden.tistory.com 으로 URL리디렉션을 시키게 되고, 역시 클라이언트의 주소창에는 주소가 http://forgarden.tistory.com 으로 변환되는 것을 보게 된다.

만일 클라이언트의 웹브라우저의 주소창이 고정되도록 하고자 한다면 아래와 같은 방법을 사용해 볼 수 있다. http://www.secure.pe.kr 웹사이트에 ‘이 컴퓨터에 있는 디렉터리’ 로 설정을 한 다음, 해당 위치에 아래의 박스에 있는 것과 같은 내용을 담은 default.htm 파일을 저장하는 것이다.

<그림10-11. 고정 URL 을 지원하기 위한 Html 문서>

<그림10-11>에서 간단한 html 문서가 만들어져 있는데, 이것은 웹페이지에 상/하 프레임으로 나누고 하위의 프레임은 안 보이도록 감추고, 상위의 프레임에는 실제 URL 리디렉트할 주소를 기록했다. 그러면 실제로 www.secure.pe.kr 웹사이트는 오직 하나의 파일인 default.htm 만 있으면 되는 것이고 사용자들은 http://forgarden.tistory.com 에 접근을 하겠지만, default.htm 파일의 상위프레임에서만 움직이는 것이기 때문에 웹브라우저에서 보이는 URL은 고정이 된다. 이것은 웹서버의 URL리디렉션 기능을 사용한 것이 아니다. 단지 html 문서상의 태그를 통해 구현할 수 있는 기능일 뿐이다.

<그림10-11>에서 보면 ‘홈디렉터리’탭에는 추가로 ‘응용 프로그램’설정이 있는데, 이것은 워드, 엑셀 등의 어플리케이션과는 구분되어 보통 ‘애플리케이션’ 혹은 ‘웹애플리케이션’이라고 부르고 있다. 웹 애플리케이션이라고 하면 asp, cgi, php 등의 프로그램을 일컫는 것이다. 이러한 웹 애플리케이션은 클라이언트의 요청을 서버의 데이터베이스에 SQL문을 이용해서 쿼리하여 답을 얻은 다음 다시 html 문서로 변환하여 클라이언트에 제공하는 등 클라이언트의 요청이 웹서버와 상호작용할 수 있도록 해 주는 서버에서 동작하는 프로그램들(Server Side Program)이다.  보통 IIS에서는 ASP, Apache에서는 PHP 로 프로그램되는 것이 일반적이다. CGI 역시 유명한 웹 애플리케이션 프로그램중의 하나였지만 점점 더 사라져가는 추세인 듯 하다. IIS에서는 기본적으로 ASP, ASP.NET 등의 프로그램이 동작한다. CGI, PHP등을 구동시키려면 Active Perl ( http://www.activeperl.com )등의 프로그램을 별도로 설치해 주어야 한다.

이러한 프로그램들을 어떠한 파일(필터라고 부른다)이 구동시켜줄 것인지를 지정하는 것이 이 메뉴에서 이루어진다. ‘홈 디렉터리’탭의 중간에 위치한 ‘스크립트 소스 액세스’ ‘읽기’’쓰기’’디렉터리 검색’등은 특별한 경우가 아니면 건드리지 말아야 한다. ‘읽기’가 기본설정인 것을 확인하자. 각각의 옵션에 대해서 필요하다면 IIS도움말을 참고하라. 많은 정보를 얻을 수 있을 것이다.

웹서버라고 하면 “웹(Web)서비스를 제공하는 컴퓨터”가 되겠다. 이러한 웹서버로 가장 많이 구현되는 2가지가 있는데 바로 윈도우즈기반의 IIS서버와 유닉스(리눅스)기반의 아파치 서버이다. 마이크로소프트가 자사의 Windows 계열의 서버제품군에서 제공하는 IIS (Internet Information Server)는 웹서비스 하나로만 이루어진 것은 아니다. 실제로는 FTP (File Transfer Protocol)서버, NNTP (Network News Transfer Protocol)서버, SMTP (Simple Mail Transfer Protocol)서버, 그리고 마지막으로 WWW (World Wide Web)서버, 이렇게 몇가지의 서비스가 묶여서 하나의 IIS라는 제품을 구성하고 있다.

IIS가 지금의 모양새를 가진 것은 NT Server 4.0 에서 추가로 설치하게 되는 NT Option Pack 이라는 이름으로 발표된 패키지에 포함된 IIS 4.0 버전부터이다. Windows 2000에서는 IIS 5.0이 기본설치되며, 윈도우 서버 2003에서는 IIS 6.0을 제공하면서 버전업되고 있다.

IIS에 포함된 각각의 서비스들에 대해서 간단히 정리를 해 보자.

한가지 확실한 것은 IIS의 전체 옵션을 체크하여 전체설치를 하게 되면 그만큼 성능도 떨어질 뿐더러 보다 열악한 보안의 위험에 노출되게 된다는 점을 명심하자. 반드시 필요한 서비스만 동작할 수 있도록 해야 한다. 이 점에 대해서는 이 장의 마지막에서 자세히 설명하도록 한다.

흔히들 착각하는 것중의 하나가 “전자메일 메시지는 안전하다”라는 생각이다. 하지만 아쉽게도 전자메일로 날아다니는 수많은 정보들은 암호화가 되지 않은 깨끗한 상태로 전송이 된다. 중요한 메시지를 전송하고 있다면 이러한 점을 고려해야 한다. PKI는 보안 전자메일을 위해서 2가지 기능을 제공한다. 첫번째는 메시지 암호화이며, 두번째는 발신자의 신원증명이다.

3장 PKI에서 설명한 기본개념을 그대로 적용시켜 보면 된다. 앨리스가 밥에게 보안 전자메일을 보내고자 한다면? 먼저 할 일은 앨리스는 밥의 공용키를 구하는 일이다. 이 공용키에 신뢰성을 부여하는 작업은 ‘인증기관(CA)’이 해 줄 것이다. 결국 앨리스는 밥의 공용키가 포함된 인증서를 구하면 되는 것이다. 이번엔 alice@secure.pe.kr 메일계정을 사용하는 앨리스가 밥에게 메일을 보냈는데, 밥은 메일 메시지의 From 헤더에 찍힌 정보를 확인해서 alice@secure.pe.kr 가 보낸 메일이라는 것은 확인할 수 있지만 정말 앨리스가 보낸 것이 맞는지에 대한 신뢰를 할 수가 없다. 사실 스팸메일이 극성을 부리고 있고 그러한 스팸메일의 발신자는 전혀 엉뚱한 사이트의 전자메일 주소가 찍혀있는 경우가 허다하다. 언뜻 봐서는 스팸메일이라고 판단하기 어려울 정도의 메일들을 받는 것은 너무나 흔한 일중의 하나이다. 앨리스는 밥에게 메일을 보낼 때 ‘전자서명(Digital Sign)’을 해서 보내고 싶다. 앞에서 전자서명은 자신의 개인키로써 암호화하는 과정이라고 설명하였다. 앨리스가 서명한 메일을 받은 밥은 앨리스의 공용키로써 해독을 하게 되고 “진짜 앨리스”가 보낸 메일이라는 확인이 가능하다.

이러한 것들을 구현하기 위해서는 어떻게 접근을 해야 하는지 예제를 통해서 설명하도록 하겠다. 예제에서는 apple 메일계정을 사용하는 사용자가 wonsuk 메일계정을 사용하는 사람에게 전자메일을 보내려 하고 있다. apple 은 자신이 보내는 메일 메시지에 전자서명을 해서 상대방에게 신뢰해도 좋다는 표시를 하고 싶다. 먼저 할일은 “인증서”를 발급받는 작업이다. 예제는 상업용CA를 서비스하고 있는 “베리사인(http://www.verisign.com)”으로부터 Trial Certificate를 발급받는 것부터 시작된다. 한국전자인증(http://www.crosscert.com)등의 사이트에서 60일 Trial version 인증서를 발급받을 수 있다.

<그림9-10. 인증서 발급요청 1>	Verisign의 E-mail 인증서 발급 웹사이트에서 60일간 사용할 수 있는 “Trial ID”를 받고자 한다.
<그림9-11. 인증서 발급요청 2>	인증서에 포함될 정보를 제공해 주어야 한다. Name=”Wonsuk Song”, E-mail Address=apple@secure.pe.kr, 나머지 사항은 당장은 중요하지 않다. 정보를 입력하고 [다음]으로 진행한다.
<그림9-12. 인증서 발급요청 3>	E-mail로 인증서를 전송하였다는 메시지를 보여준다. 잠시후 apple@secure.pe.kr 의 메일주소로 베리사인으로부터 인증서가 전송되어 올 것이다.
<그림9-13. 인증서 발급요청 4>	apple@secure.pe.kr 전자메일로 인증서가 발급되었음을 알리는 메일이 왔다. 메시지의 [Continue]링크를 클릭하여 인증서를 받기 위해 이동한다.
<그림9-14. 인증서 발급요청 5>	다시 베리사인의 웹사이트에 접속하였다. Digital ID가 발급되었고, 인스톨 할 수 있는 화면이다. [INSTALL]버튼을 클릭한다.
<그림9-15. 인증서 발급요청 6>	설치가 되었다. 인터넷 익스플로러-도구-인터넷 옵션을 클릭한다.
<그림9-16. 인증서 발급요청 7>	인터넷옵션의 내용탭을 열고 [인증서]버튼을 클릭해서 인증서를 확인한다.
<그림9-17. 인증서 발급요청 8>	Verisign으로부터 Wonsuk Song에게 발급된 인증서가 있는 것을 보여준다. [보기]를 눌러서 인증서를 확인해 보자.
<그림9-18. 인증서 발급요청 9>	인증서의 ‘일반’탭에서는 인증서의 용도가 ‘전자메일 보호’ ‘원격 컴퓨터에 사용자의 신분을 증명’이라는 용도가 기록되어 있다. 발급대상은 Wonsuk Song 이고, 발급자는 Verisign Class 1 CA 임을 알 수 있다.
<그림9-19. 인증서 발급요청 10>	자세히탭을 눌러 보니 이번에는 또 다른 여러가지 정보를 보여주고 있다. 다 빼놓을 수 없는 정보이긴 하지만 중요한 정보는 ‘주체’에 담겨있는 정보이다. apple@secure.pe.kr 에게 발급되었음을 보여준다. 바로 아래의 ‘공개키’를 보면 RSA프로토콜 1,024비트라는 표기가 되어 있다. 인증서에 저장된 apple@secure.pe.kr의 공개(공용)키이다.
<그림9-20. 인증서 발급요청 11>	마지막으로 ‘인증경로’탭을 열어보니 인증기관에 대한 정보를 보여주고 있다. 이것은 인증서에 인증기관이 서명을 했음을 보여주는 것이다. 인증기관의 이름을 클릭하고 [인증서 보기]버튼을 누르면 인증기관의 인증서를 확인할 수 있다.

이제 apple@secure.pe.kr 은 외부CA로부터 전자메일용 인증서를 발급받았다. 또한 자신의 컴퓨터에는 인증서에 저장된 공용키와 한쌍이 되는 개인키가 저장되어 있다. 이제 apple 은 메일을 전송할 때 전자서명을 할 수 있게 되었다. 전자서명을 해서 메일을 보내보도록 하자.

<그림9-21. 전자서명된 메일 전송 1>	Outlook Express를 이용해서 메일 메시지를 작성하고 있다. 메시지를 작성한 다음 전자서명을 하기 위해 ‘도구메뉴à디지털서명’을 클릭했다.
<그림9-22. 전자서명된 메일 전송 2>	보낸 사람 메일주소 오른편에 빨간색으로 인증서 표시가 보인다. 전자서명을 이용하겠다는 것이다. 메일을 보내기 위해서 [보내기]버튼을 눌렀다.
<그림9-23. 전자서명된 메일 전송 3>	전자서명은 개인키로 암호화하는 과정을 일컫는 말이라고 한 바 있다. 전자서명을 하기 위해 개인키를 이용하겠다는 화면이 나왔다. [확인]을 눌러 계속 진행하면 메일이 전송된다.
<그림9-24. 전자서명된 메일 전송 4>	wonsuk 의 계정으로 메일이 도착했다. 미리보기 창에서 메시지에 전자서명이 되어 있음을 가르쳐 준다. 전자서명된 메시지는 메일 상대방의 신원을 증명해 준다는 문구를 찾을 수 있을 것이다. 메시지중 아래의 [Continue]를 클릭하면 메시지를 확인할 수 있다.
<그림9-25. 전자서명된 메일 전송 5>	apple@secure.pe.kr 로부터 전송된 메일을 확인할 수 있다. Security 항목을 보니 “Digitally signed and verified”라는 메시지가 보인다. 아무런 문제가 발생하지 않았다. apple@secure.pe.kr 가 사용한 인증서(디지털ID)를 발행한 Verisign이 신뢰된 인증기관(CA)이므로 받는 사람측에서는 정상적으로 확인이 가능했던 것이다.

다음 작업은 Wonsuk 이 Apple 에게 보내는 메일 메시지를 암호화해서 보내는 과정을 예제로 설명한다. wonsuk은 먼저 apple 의 공용키를 얻어야 한다. 즉 디지털 ID (인증서)를 구해야 한다는 것이다. 앞에서 wonsuk 은 apple 로부터 인증서가 포함된 메일을 받은 적이 있으므로 주소록을 확인하면 apple의 메일주소를 찾을 수 있고, 거기에는 이미 인증서가 있음을 알 수 있다. 이 인증서를 통해서 암호화된 메일을 전송할 수 있다.

<그림9-26. 암호화된 메일 전송1>	Wonsuk은 새로운 메일을 작성하고 있다. 받는사람을 선택하기 위해서 주소록을 열었더니 거기에는 Apple의 메일주소가 등록되어 있었다. 일전에 메일을 받은적이 있었기 때문이다. 또 Apple이 메일을 보낼 때 전자서명을 해서 보냈기 때문에 Apple의 디지털ID(인증서)도 가지고 있는 상태이다. Apple에게 메일을 보내기 위해 받는사람에 apple@secure.pe.kr 을 추가했다.
<그림9-27. 암호화된 메일 전송2>	메시지에 암호화를 하기 위해 도구메뉴-암호화(Encrypt)를 선택했다. 이제 ‘보내기’버튼을 누르면 Apple의 공용키로 암호화된 메시지는 중간에 제3자가 해독하지 못하고 오직 Apple만이 자신의 개인키로 해독해서 읽을 수가 있다.
하지만 위와 같은 형태로 암호화 메일을 보내기 위해서는 먼저 Apple이 전자서명된 메일을 보냈다는 것을 조건으로 하고 있다. 그렇지 않고 Wonsuk이 먼저 Apple에게 메일을 보내는데 메시지를 암호화하고자 한다면 어떻게 할까? 당연히 Apple의 공용키를 구해야 한다. 그렇지 않고서 암호화된 메일을 보낼 수는 없는 것이다. 역시 주소록에서 [찾기]기능을 이용하여 검색을 하는 것이 가능하다.
<그림9-28. 암호화된 메일 전송3>	받는사람을 선택하기 위해 주소록을 열었지만 상대방의 주소를 찾을 수가 없었다. <그림9-28>의 [찾기]버튼을 클릭한다.
<그림9-29. 암호화된 메일 전송4>	찾는위치를 ‘Verisign 인터넷 디렉터리 서비스’로 바꾼 다음 전자메일 창에 메일을 보내고자 하는 상대방의 인증서를 찾기 위해 ‘apple@secure.pe.kr’라고 입력하고 [지금 찾기]버튼을 클릭했다. 그랬더니 잠시후 검색된 결과를 보여준다. Verisign에서 발행한 인증서를 찾아낸 것이다. [주소록에 추가]버튼을 클릭했다.
<그림9-30. 암호화된 메일 전송5>	Outlook Express 메일 클라이언트 프로그램의 주소록에 추가될 상대방의 정보를 입력한다. 마지막에 있는 ‘디지털ID’탭을 클릭한다.
<그림9-31. 암호화된 메일 전송6>	디지털ID탭을 클릭하니 Wonsuk Song (기본값)이라는 목록이 보인다. [속성]을 클릭한다.
<그림9-32. 암호화된 메일 전송7>	인증서를 확인할 수 있다. Verisign Class 1 CA로부터 Wonsuk Song 에게 인증서가 발급되었음을 알 수 있고, 현재 인증서 상태는 ‘올바른 인증서입니다.’라고 되어 있다.
<그림9-33. 암호화된 메일 전송8>	이제 상대방의 인증서를 구했으니 암호화된 메시지를 전송할 수 있게 되었다. 도구-암호화를 선택하여 메시지를 암호화하도록 설정한 다음 메시지를 전송하기 위해 [보내기]를 클릭했다.
<그림9-34. 암호화된 메일 전송9>	에러메시지처럼 보이는데 그렇지는 않다. 이 메일 메시지는 암호화된다. 해독할 수 있는 사람은? 당연히 Apple이다. Apple은 자신이 가진 개인키를 이용해서 암호문을 해독할 것이다.
이 메시지는 전송하고 나면 보낸편지함에서 이 메시지를 읽을 수 없다는 것을 설명하고 있다. 자신이 보낸 메시지를 자신이 보지 못한다는 것이 어폐가 있어보이긴 하지만 필자는 해결할 방법을 찾지 못했다. 한편으로는 오히려 보안상 확실한 방법이라는 생각도 든다. 메일을 받은 Apple쪽에서는 어떻게 보이는지 살펴보자.
<그림9-35. 암호화된 메일 수신1>	Apple의 컴퓨터에서 메일프로그램을 열고 wonsuk으로부터 온 메일에 접근하자 ‘개인키’에 액세스하겠다는 메시지를 보여준다. 메일 메시지는 Apple의 공용키로 암호화되었다는 것을 상기하자. 당연히 해독하기 위해서는 Apple의 개인키가 필요하다. 그러한 메시지이다.
<그림9-36. 암호화된 메일 수신2>	화면에서 메일의 상태를 잘 설명해 주고 있다. 암호화가 되었고 다른 사람이 읽지 않았음을 나타낸다는 문구를 찾을 수 있다. 메일을 읽기 위해서는 [계속]을 누른다.
<그림9-37. 암호화된 메일 수신3>	메일을 읽을 수 있었다. 복호화가 이루어진 것이다. 보안의 상태가 암호화가 되었음을 나타낸다.
이번에는 확실하게 이해하기 위해 2가지를 동시에 사용해 보자. Wonsuk은 자신의 회사에 있는 내부CA로부터 받은 인증서를 이용하여 자신의 인증서로 서명되고, 또한 Apple의 공용키로 암호화된 메시지를 Apple에게 전송하고자 한다. 먼저 Secure.pe.kr CA라는 이름의 내부CA로부터 전자메일 보안을 위한 인증서를 발급받는 과정부터 시작된다.
<그림9-38. 보안메일 전송1>	인터넷 익스플로러를 열고 인증기관 서비스에 연결해 주는 웹서버에 접근했다.   http://ca.secure.pe.kr/certsrv URL을 입력하니 인증서 요청 화면이 열린다. Request a Certificate를 선택하고 [Next]를 누른다.
<그림9-39. 보안메일 전송2>	User Certification request 항목에서 E-mail Protection Certificate를 선택하고, [Next]버튼을 눌렀다.
<그림9-40. 보안메일 전송3>	인증서에 사용될 이름, 전자메일, 회사 등의 정보를 입력한 다음 [제출]을 누른다.
<그림9-41. 보안메일 전송4>	인증서가 발급되었다. Install this certificate 링크를 클릭하여 인증서를 컴퓨터에 설치한다.
<그림9-42. 보안메일 전송5>	확인하기 위하여 인터넷익스플로러-도구-인터넷옵션-내용탭-인증서를 클릭한다.
<그림9-43. 보안메일 전송6>	Secure.pe.kr CA로부터 ‘송원석’에게 발급된 인증서를 확인할 수 있다.
<그림9-44. 보안메일 전송7>	이제 이 인증서를 이용해서 전자서명을 할 수 있게 되었다. 메일의 상대방인 Apple의 인증서로 메시지를 암호화하고, Wonsuk의 인증서로 전자서명을 하도록 2가지를 모두 선택하고 [보내기]를 눌러 메일을 전송하였다.
<그림9-45. 보안메일 전송8>	메일을 받은 Apple측에서 메시지를 열었을 때 보이는 화면이다. ‘디지털 서명되고 암호화된 메시지’라는 정보를 보여주는데, 하이라이트된 부분을 보면 ‘디지털 ID서명을 신뢰할 수 없습니다.’라고 되어 있다. [계속]버튼을 클릭한다.
<그림9-46. 보안메일 전송9>	보기에도 음침해 보이는 화면을 보여준다. 보안문제를 경고하고 있는데, ‘이 메시지에 사용된 디지털ID를 신뢰할 것인지 여부를 결정하지 않았습니다.’라는 내용이 굵은 글씨체로 되어 있다.   Wonsuk 은 Secure.pe.kr CA로부터 인증서를 받아서 전자서명을 했는데 이 Secure.pe.kr CA가 내부CA이므로 Apple의 컴퓨터에서는 Secure.pe.kr CA가 신뢰할 수 있는 CA의 목록에 없기 때문에 이런 경고가 발생한 것이다. 아래쪽의 [디지털 ID 보기]를 눌러보았다.
<그림9-47. 보안메일 전송10>	발급자와 발급대상을 볼 수 있는데 인증서 정보는 완전하지 않다는 것을 알 수 있다.
<그림9-48. 보안메일 전송11>	<그림9-46>의 화면에서 [메시지 열기]버튼을 누르면 경고를 무시하고 메시지를 열어서 볼 수 있다. 또한 [신뢰편집]을 눌러서 ‘인증서를 신뢰함’으로 설정을 해 주면 다음부터는 이 인증서에 대해서 보안경고를 발생시키지 않는다.

이상으로 보안 전자메일에서 PKI가 어떻게 사용되는지 알아보았다. 위의 순서를 따라서 직접 구현해 볼것을 권장한다. 눈으로 보는 것은 금새 잊혀진다. 솔직히 이것은 상당히 번거로운 작업이 아닐 수 없다. 그런 이유로 몇몇 업체에서는 대칭키를 이용한 전자메일 보안에 관한 솔루션을 내놓고 사용하기도 하는데 이러한 것들을 통해서 우리는 데이터 보호, 보안 이라는 분야가 업계에서 점점 더 필요성이 커져 가고 있다는 사실을 짐작해 볼 수 있을 것이다. 개념적인 부분은 잘 익혀두고 관심을 가져보길 권하며 이번 장을 마친다.

윈도우 서버 2003을 이용하여 인증기관(CA)을 만들 수 있다. 이 인증기관에서는 인증서를 필요로 하는 서버나 클라이언트에게 인증서를 발급하고 인증한다. 3장에서 이러한 내부CA는 ‘상업적인 목적의 사용’이라는 측면에서는 완전하지 못하다는 설명을 한 바 있지만, 회사 내부적인 목적의 사용이라면 당연히 비싼 돈을 들여서 외부의 CA를 이용할 이유가 없다. 다만 ‘신뢰성’이 떨어진다는 측면만 고려하면 되는 것이었다. 여기서 말하는 ‘신뢰성’이라고 하는 측면은 클라이언트가 자신이 접속하고자 하는 서버로부터 인증서를 받았을 때 이것을 신뢰할 것인지의 여부에 달려있다. 회사의 네트워크 환경에서는 모든 클라이언트 컴퓨터의 ‘신뢰할 수 있는 인증기관의 목록’에 회사 내부에서 구성한 CA를 추가시켜 주면 해결된다. 기업에 Active Directory 환경을 구성하면 자동으로 클라이언트들의 목록에 내부CA의 목록이 추가된다. 또한 그룹정책을 사용하여 목록을 클라이언트들에게 일괄적으로 배포하는 작업도 가능하다. 뒤에서 Active Directory에 대해서는 자세히 설명하기로 한다.

또 다른 측면은 윈도우 서버 2003에 상업용 외부CA에 대한 자식CA를 구성하는 방법이 있다. 상업용외부 CA로부터 인증서를 발급받은 후 자신이 하부CA로서 클라이언트에게 인증서를 발급하도록 구성 할 수도 있다. 그렇다면 윈도우 서버2003 CA는 더 이상 내부CA라고만 하기에는 어렵다. 외부CA처럼 자신이 발급하는 인증서는 제3의 클라이이언트들이 신뢰할 수 있기 때문이다.

윈도우 서버 2003의 CA서비스는 크게 2가지, 또 거기서 다시 2가지로 세분화된다. 먼저 엔터프라이즈CA와 독립실행형 CA로 나눌 수가 있고, 이것은 각각 루트CA와 하위CA로 세분화된다. 엔터프라이즈CA와 독립실행형 CA를 구분하면 이것은 Active Directory의 유무를 근거로 판단할 수 있다. 엔터프라이즈CA를 구성하기 위해서는 Active Directory가 있어야 한다. 그밖의 경우는 독립실행형CA를 사용할 수 있다. 웹서버에서 SQL서버 데이터베이스에 저장된 사용자들에게 인증서를 발행해야 한다면 그때는 독립실행형CA를 사용해야 한다. 예제에서는 독립실행형CA를 구축해 보도록 하자.

<그림9-1. 독립실행형 인증기관(CA)설치 1>	“제어판à프로그램추가/제거àWindows구성요소à인증서서비스”를 체크하고 [다음]을 누른다.
<그림9-2. 독립실행형 인증기관(CA)설치 2>	인증서서비스를 설치하면 컴퓨터의 이름을 바꾸거나 도메인의 멤버가 되는 등의 작업은 할 수가 없다. 그럴 필요가 있다면 그것은 CA서비스를 제거한 후에나 가능한 일이다.
<그림9-3. 독립실행형 인증기관(CA)설치 3>	인증기관 종류 화면에서는 윈도우 서버 2003이 지원하는 4가지의 인증기관 종류를 보여준다. 필자의 테스트 환경에서 이 컴퓨터는 도메인 컨트롤러이고 현재 작업을 하는 사용자는 도메인의 관리자였다. 만일 당신의 테스트환경이 독립실행형 서버라면 “엔터프라이즈 CA”를 구성하는 옵션을 비활성화된다. 웹서버를 위한 인증서 발행을 목적으로 인증기관을 설치하고 있다면 세번째 메뉴인 ‘독립 실행형 루트 CA’를 선택한다.
<그림9-4. 독립실행형 인증기관(CA)설치 4>	‘CA확인정보’화면에서는 인증기관의 정보를 입력해 준다. CA의 공통이름(Common Name; CN)정보가 앞으로 자신이 발행할 인증서에 표기되는 정보이니 정확히 입력해야 한다. 예제에서는 “WindowsNetwork CA”라고 인증기관 이름을 결정하고 5년 기한의 유효기간을 설정하였다.
<그림9-5. 독립실행형 인증기관(CA)설치 5>	인증서 데이터베이스와 로그를 저장할 경로를 지정한다. 기본경로는 %WinDir%\system32\CertLog 이다.
<그림9-6. 독립실행형 인증기관(CA)설치 6>	IIS서비스를 멈추었다가 다시 시작해야 한다. 클라이언트가 인증기관에게 인증서 발급요청을 할 때 IIS를 통한 웹인터페이스를 통해서 접근하도록 이때 certsrv라는 가상디렉터리를 생성하게 된다.
<그림9-7. 독립실행형 인증기관(CA)설치 7>	설치가 진행되고 있다.
<그림9-8. 독립실행형 인증기관(CA)설치 8>	설치가 끝나면 관리도구에서 ‘인증 기관’ 관리콘솔을 찾을 수 있다. 실행해 보자. WindowsNetwork CA가 동작하고 있고, 해지된 인증서, 발급된 인증서, 대기 중인 요청, 실패된 요청 등의 메뉴를 볼 수 있다. 인증기관 설치가 완료되었다.

엔터프라이즈 CA가 설치되었다면 클라이언트는 인증서 관리콘솔과 웹브라우저, 이 두가지 방법을 통해서 인증서 발급요청을 할 수 있지만, 독립실행형 CA가 설치되었다면 오직 웹브라우저를 통해서만 인증서 발급요청을 할 수 있다.

<그림9-9. 인증서 발급 요청 화면>

IIS가 동작하고 있는 서버에서 인증기관이 설치되면 IIS서버의 기본웹사이트에는 %WinDir%\System32\CertSrv 를 물리적 경로로 하는 Certsrv 가상 디렉터리가 자동으로 생성된다. 인증서 발급요청을 하고자 하는 클라이언트는 http://서버의 IP 혹은 호스트이름/certsrv URL을 이용하여 인증서 발급 페이지에 연결할 수 있다. 아래의 <그림9-9>에서는http://192.168.0.16/certsrv 를 이용하여 인증서 서비스 웹페이지에 연결한 것을 보여준다.

회사 내부의 사용자계정정보, 네트워크의 각종 자원들, 이러한 정보들은 분명히 외부로부터 보호되어야 한다. 가장 좋은 방법은 회사의 네트워크를 Active Directory등을 담고 있는 내부(Internal) 네트워크와 외부로 공개해야 할 웹서버, 메일 서버, DNS서버 등을 담고 있는 외부(External)네트워크로 분리하는 방법이다.

추가로 인터넷에서 내부의 네트워크에 접근하기 위해 먼저 알아야 하는 컴퓨터의 주소, 즉 IP Address를 감춰야 할 필요가 있는데 이것은 DNS서버에 대한 보안을 유지함으로써 챙겨줄 수 있다. 방법은 외부DNS와 내부DNS를 구분하여 공개된 네트워크에 배치하는 외부 DNS는 웹서버, 메일서버, VPN서버등의 레코드를 가지도록 구성하며, 내부DNS는 Active Directory, 파일서버 등의 내부네트워크에서만 접근할 수 있도록 레코드를 구성하는 것이다. 이것은 가장 먼저 고려해야 할 간단하지만 아주 좋은 구성이라고 하겠다.

또한 클라이언트 컴퓨터들중 일부가 IP Address가 부족하여 어쩔 수 없이 개인네트워크의 IP Address를 사용하고 NAT서버나 프록시서버를 통해서 인터넷에 접근하도록 할 수는 있지만, 이제는 어쩔수 없는 상황이 아니라 IP Address가 충분하더라도 반드시 고려해야 할 필수적인 환경이 개인네트워크를 구성하는 것이다.

이러한 사항들을 토대로 구현해 본 네트워크 디자인이 아래의 <그림8-33>과 같다.

그림을 주의깊게 살펴보라. 라우터의 이더넷 포트에는 방화벽이 물려있고 이곳을 통과한 패킷들은 다시 스위치를 통하여 확장되고 있다. 스위치로 확장된 네트워크를 통하여 프록시서버(또는 파이어월), 메일서버, 웹서버, DNS서버 등을 배치하였다. 이들 4개의 서버가 물리적으로는 한대의 서버에서 구현될 수도 있다. 어디까지나 기능적인 측면이다. 이들 4개의 서버들은 공용 네트워크에 배치하였다. 역시 공인 IP Address를 가지게 된다. 여기서 내부네트워크로 들어오기 위한 관문이 프록시서버 혹은 내부 방화벽이 된다. 이 사이 구간을 가리켜서 비무장지대(D.M.Z)라고 부른다. 그리고 프록시 서버에서는 내부로 하나의 스위치로 네트워크를 확장하여 여기에 모든 클라이언트 컴퓨터를 배치하고 내부 네트워크를 구현하였다. 프록시서버를 통해서 한단계 더 걸러지는 개인네트워크를 구현한 것이다. 이것은 당연히 공용네트워크에 있는 컴퓨터들보다는 안전하다.

회사가 Active Directory도메인과 메일,웹서버의 도메인으로 Secure.pe.kr 이라는 도메인을 사용하고 있을 때, 외부 네트워크의 DNS서버는 secure.pe.kr이라는 영역(Zone)을 주영역으로 생성하고 외부에서 접근해야 하는 자원들, 웹서버(www), 메일서버(MX) 등의 레코드를 가지고 있어야 한다. 이 DNS서버가 내부의 자원의 목록을 가지지 않도록 주의해야 한다. 또한 내부 네트워크의 DNS서버 역시 secure.pe.kr 영역을 주영역으로 생성하며 도메인 컨트롤러의 정보(SRV)를 포함한 내부네트워크의 모든 서버들의 정보를 담고 있어야 한다. 관리자는 이 DNS서버에 외부 네트워크에 있는 www, MX 등의 레코드들을 수작업을 통해 구성하는 것을 잊지 말아야 할 것이다. 또한 내부DNS서버가 외부DNS서버를 포워더 서버로 구성해서 내부네트워크의 클라이언트가 인터넷에 접근할 수 있도록 구성해 주어야 한다.

포워더 서버 구성은 내부 DNS서버에서 DNS관리콘솔을 열고 왼쪽 패널의 서버이름을 마우스 오른쪽 클릭하여 등록정보로 접근한 후, ‘전달자’탭에서 구성할 수 있다.

외부네트워크와 내부네트워크의 경계 역할을 하는 프록시서버(파이어월)은 프로토콜, IP필터링을 통해서 DNS트래픽이 통과할 수 있도록 구성해 줄 필요가 있다.

큰 개념적인 내용은 위에서 정리한 바와 같다. 하지만 현실적으로 생각해 볼 필요가 있다. 회사가 중요하게 고려해야 할 부분이 어느것인가 하는 부분이다. 네트워크의 성능이 가장 중요한지, 보안이 가장 중요한 것인지, 아니면 비용을 줄이는 것이 가장 중요한 것인지, 관리자에게는 여기에 바로 선택의 여지를 남겨둘 것이다. 시스템관리자들에게는 가급적이면 위와 같은 네트워크 구성을 권하고 싶다. 잘 구성된 초기네트워크와 잘 설정된 방화벽의 필터규칙들은 관리자에게 네트워크의 문제점을 줄여줄 수 있는 기반이 될 수 있다.

보안이나 성능도 무시할 수 없지만, 위와 같은 모델을 채택하기에는 상대적으로 비용부담이 너무나 크다고 생각되었다면 기본모델을 유지하는 상태에서 조금씩 타협점을 찾아갈 수 있다. 중요한 것은 관리자가 지속적으로 흐름은 잃지 말아야 한다는 것이다. 아래에 비용이 조금 덜 들어가는 모델을 두가지 더 구성해 보았다.

위의 그림 역시 기본적으로 개인네트워크와 공용네트워크를 구분한 모델이다. 프록시 서버가 내부네트워크로 2가지의 연결을 가지고 있다. <그림8-33>에 비해 방화벽이 하나 줄어들었다. 성능면에서는 떨어질 수 있지만 보안 측면에서는 메일서버, 웹서버, DNS서버 등을 프록시서버 안쪽의 개인네트워크에 배치함으로써 여전히 안전성 있는 네트워크 환경을 구축하였다.

<그림8-36>은 가장 간단하면서도 중소규모 회사에서는 큰 비용부담없이 검토해 볼만한 보안을 생각한 네트워크 모델이다. 프록시서버에서 Publishing(인터넷에서 개인네트워크에 접근할 수 있도록 허용해 주는 작업)을 해야 할 서버들은 메일서버, 웹서버, DNS서버(외부)이다. 내부DNS서버와 외부DNS서버가 각각 가지고 있어야 하는 레코드들에는 차이가 없다. 역시 내부DNS서버는 외부DNS서버를 포워더 서버로 지정해 주어야 하며, 내부DNS서버가 인터넷에서 감춰짐으로써 내부 자원들의 목록을 보호할 수 있는 방법을 제공한다. 중소규모 회사에서는 전혀 무방비 상태의 회사에 비한다면 한결 안전해 지는 네트워크 환경을 구성하는 것이다. 웹서버의 응답속도 등의 성능이 우선시 되어야 한다면 상대적으로 권장하지 않는 모델이다.

몇가지 모델을 살펴보았지만 이들은 한결같이 네트워크를 보호하고자 하는데 초점이 맞춰져 있다는 것을 알 수 있다. 회사의 여건이 어느 것을 먼저 필요로 하는지 잘 검토해 보아야 할 것이고 일단 회사의 여건에 따른 요구사항이 명확히 결정되었다면 기술적인 구현은 여러분들이 생각하는 방향대로 얼마든지 구현할 수 있을 것이다.

현재 대부분의 회사환경에 개인(사설) 네트워크를 도입하는 것은 ‘선택’이 아니라 ‘필수’이다.

위에서는 개인네트워크의 클라이언트들이 인터넷을 사용하기 위한 기본적인 기능을 설명했다. 추가로 NAT가 가지는 몇가지 유용한 기능에 대해서도 설명한다.

8-4-1. DHCP서비스

개인네트워크의 클라이언트들은 NAT서버의 개인네트워크 인터페이스와 같은 네트워크ID의 IP Address가 할당되어야 한다. 이러한 작업을 수동으로 해도 되겠지만 만일 많은 수의 NAT클라이언트들을 관리해야 한다면 DHCP서비스를 고려할 수 있을 것이다. 별도의 DHCP서버를 두지 않고 NAT서버에서 DHCP서버 역할을 제공할 수 있다. 라우팅 및 원격 액세스 서비스 관리콘솔에서 왼쪽패널의 NAT를 클릭하고 등록정보로 접근하면 <그림8-25>의 메뉴를 볼 수 있다.

"주소할당"탭에서 'DHCP를 사용하여 IP주소 자동 할당'옵션을 체크하면 DHCP서비스를 제공할 수 있다. IP주소 항목에는 NAT서버의 개인 네트워크 인터페이스에 해당하는 네트워크 ID를 적어준다. 예를 들어서 NAT서버의 개인네트워크 IP가 192.168.200.1이라면 IP 주소항목에는 192.168.200.0이 된다.

위와 같이 구성하면 클라이언트는 IP주소와 서브넷마스크를 NAT에서 설정한 대로 할당받게 되고, NAT의 개인네트워크 인터페이스에 할당된 IP주소를 클라이언트의 기본 게이트웨이로 사용하도록 구성된다.  TCP/IP환경에서 클라이언트가 인터넷을 쓰기 위해서는 추가로 구성되어야 할 항목이 있다. 바로 DNS서버의 IP를 가져야 하는데 이것까지도 NAT서버를 통해서 받게 하고 싶다면 추가로 "이름확인"탭까지 구성을 해 주면 된다.

<그림8-24>에서 '이름확인'탭에서 '클라이언트가 DNS를 사용'이라는 옵션을 체크하였다. 이렇게 하면 NAT 클라이언트는 IP주소, 서브넷마스크, 기본게이트웨이 뿐만 아니라 DNS의 IP까지도 할당받을 수 있게 된다. 

NAT서버의 이러한 설정을 클라이언트가 사용하고 싶다면 클라이언트의 시스템에서는 TCP/IP설정을 DHCP클라이언트로 변경해야 한다. <그림8-25>에서는 클라이언트의 TCP/IP설정을 '자동으로 IP받기'를 선택함으로써 DHCP클라이언트로서 셋팅한 것을 보여준다.

8-4-2. 외부 네트워크에서의 개인네트워크 액세스 허용

ICS, NAT가 제공하는 또 다른 측면이라면 그것은 정반대의 기능도 제공한다는 것이다. 개인네트워크의 클라이언트들이 외부 인터넷으로 접근하도록 지원하지만 또 다른 측면은 인터넷상의 클라이언트들이 개인네트워크의 서버로 연결할 수 있도록 지원하는 것도 역시 ICS, NAT등의 기능이다.

<그림8-26>의 예제에서 보여지듯이 인터넷에서 접근하는 사용자에게 웹서비스를 제공하고자 하는데, 만일 웹서버를 공용네트워크에 두는 것이 아니라 개인네트워크에 배치하고 싶다면 어떻게 할까? 당연히 웹서버는 개인네트워크 IP Address를 가지게 될 것이고, 외부에서 그 IP Address로 접근을 시도하더라도 웹서버까지 요청은 도달될 수 없다. InterNIC에서는 개인 네트워크 IP주소를 위해 특별히 네트워크 ID를 예약해 두었고, 그 IP는 인터넷에서는 통용되지 않는 개인네트워크를 위해서 사용이 되고 있다. 192.168.x.x 네트워크 ID 역시 개인 네트워크 용도로 할당된 ID이다. 이것을 목적지로 한 패킷은 갈곳이 없다.