웹서버라고 하면 “웹(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이다. 이것을 목적지로 한 패킷은 갈곳이 없다.

방법은 있다. NAT서버에서 약간의 설정을 통하여 내부의 서버가 공용네트워크에 서비스를 제공할 수 있게 할 수 있다. 2가지 방법이 제공되는데 각각의 기능은 차이점을 보이게 된다.

먼저, 특수포트 매핑의 방법이 있다.

NAT서버의 공인IP가 211.232.71.131라고 가정해 보자. DNS서버의 www레코드는 211.232.71.131를 가리키고 있어야 한다. 외부에서 보기에는 NAT서버가 회사의 웹서버가 되는 것이다. 클라이언트의 http요청은 NAT서버에게 날아올 것이다. 이때 NAT서버에서는 이 요청을 자신이 처리하는 것이 아니라 개인 네트워크로 요청을 포워딩 해 주면 된다.

아래와 같이 구성한다.

<그림8-27. NAT 인터페이스 등록정보 >	‘라우팅 및 원격 액세스’ 관리콘솔에서 NAT프로토콜을 선택하고, Public 인터페이스를 선택한 다음 등록정보를 연다.
<그림8-28. 특수포트 매핑 1>	'서비스 및 포트'탭을 클릭하면 이미 몇가지 주요한 네트워크 서비스 템플릿이 구성되어 있다. 웹서버를 구성하고자 하기 때문에 ‘웹 서버(HTTP)’를 선택하고 [편집]을 눌렀다.
<그림8-29. 특수포트 매핑 2>	<그림8-29>의 서비스 편집 화면에서 211.232.71.131로  HTTP요청이 왔을 때 포워딩하여 내부네트워크에서 웹서비스를 제공할 서버의 IP 주소를 입력해야 한다. 예제 화면에서는 192.168.200.15를 입력했다.
또 다른 방법은 Address Pool (주소풀)을 이용하는 방법이다. 이것은 공인 IP가 추가로 필요하다. 하나의 IP만 가지고 있을 경우에는 구현할 수 없는 방법이다. NAT서버에게 여러개의 공인 IP주소를 할당해 두고 이 공인 IP를 내부의 사설IP로 예약해 두겠다는 것인데, 이렇게 하면 NAT서버에게 할당해 둔 공인 IP에게 요청이 들어오면 내부의 예약된 개인IP를 가진 컴퓨터들에게 요청을 포워딩 해 줄 수가 있게 된다.
<그림8-30. NAT 인터페이스 등록정보 - 주소풀 추가 >	NAT의 Public인터페이스의 등록정보에서 '주소풀'을 선택하면 아래의 <그림8-23>을 볼 수가 있다. 먼저 [추가]버튼을 클릭하여 NAT서버가 추가로 가지고 있게 될 IP주소를 입력한다. 예제에서는 192.168.0.201 부터 192.168.0.253까지의 IP를 추가했다.
<그림8-31. NAT 인터페이스 등록정보 – 주소예약>	다음에 [예약]버튼을 클릭하여 위에서 할당한 공인 IP와 개인네트워크 내부의 시스템의 개인 IP를 매핑시킨다. 예제에서는 192.168.0.251을 192.168.200.15로 매핑시켰다. 그 다음에 '이 주소로 들어오는 세션 허용' 항목을 체크하고 [확인]을 눌러 마친다. 이렇게 하면 NAT서버는 192.168.0.251을 목적지로 하는 모든 패킷들을 개인 네트워크의 192.168.200.15 서버에게 포워딩하게 된다. 결과적으로는 인터넷상의 사용자가 개인네트워크 내의 컴퓨터에게 접속할 수 있게 구성이 된 것이다.

DNS서버의 www 레코드는 더 이상 NAT서버의 공용IP Address를 가리키고 있어서는 안된다. <그림8-31>에서 예약한 192.168.0.251을 가리키고 있어야 할 것이다.

8-4-3. NAT가 지원하지 못하는 것들

NAT서버는 큰 단점이 있다. 클라이언트의 숫자가 늘어날수록 성능면에서 상당한 저하를 가져올 수 밖에 없다는 것이다. 보통 20명에서 최대 30여명 정도의 클라이언트가 있는 환경에서는 그런대로 쓸만 하지만 보다 많은 사용자를 지원해야 한다면 NAT는 권장할만한 솔루션은 아니다.

또한 NAT서버가 개인네트워크와 공용네트워크간의 연결성을 훌륭하게 수행하긴 하지만 아쉽게도 모든 프로토콜이 허용되는 것은 아니다. 일반적으로 사용하는 http, ftp, smtp, pop3등은 잘 동작하지만 Kerberos, IPSec, DCOM, LDAP등의 프로토콜을 NAT에서 지원이 되지 않는다. 개인네트워크의 NAT 클라이언트가 NAT서버를 이용해서 외부의 서버와 통신을 할 때, 만일 이러한 NAT에서 지원되지 않는 프로토콜이 필요하다면 그 때는 NAT서버를 사용할 수는 없다. 예를 들면, 도메인 환경에서 클라이언트가 로그온을 한다든가, Active Directory에 쿼리를 한다든가, L2TP를 이용한 VPN을 구현한다든가 하는 경우가 있다.

또한 NAT는 개인네트워크에 여러 개의 서브넷을 지원하지 못한다. 공용인터페이스 하나, 개인 인터페이스 하나, 이걸로 끝이다. 여러 개의 서브넷을 만들고 각각 서로 다른 수준의 보안설정을 하는 작업을 지원하지 않는다는 것이다.

또한 NAT는 사용자 인증을 지원하지 않는다. 물리적으로 개인 네트워크에 있는 클라이언트가 NAT서버의 IP Address만 알고 있다면 누구라도 NAT를 이용해서 인터넷에 액세스하는 것이 가능하다.

프로토콜 필터링 또한 지원하지 않는다. 물론 이것은 라우팅 및 원격액세스의 필터링 기능과 연동하여 사용하면 가능하긴 하지만 NAT자체적으로 필터링을 지원하는 것은 아니다. 이를 테면 관리자들은 FTP를 사용하게 하고, 영업부 직원들은 http를 사용하지 못하게 하는 등의 사용자별 프로토콜별 필터링을 통한 통제가 되지 않는다는 것이다.

음.. 적고 보니 안 되는 기능이 너무 많은 듯 하다. 하지만 소규모의 기업네트워크 환경이라면 위의 단점으로 지적한 기능들이 현실적으로 문제가 되지는 않는다.

그렇다면 이런 경우에는 해결책이 없는가? 물론 있다. MS의 솔루션으로는 ISA (Internet Security & Acceleration) Server를 들 수 있다. 현재 ISA Server 2004가 출시되어 있다.

ISA Server 는 제품이름에서 알 수 있듯이 단순히 개인네트워크와 공용네트워크와의 연결성 뿐만이 아니라 웹캐싱 기능을 통해서 보다 빠른 인터넷 액세스를 제공하고, 사용자관리를 통한 인터넷 액세스 제한, 특정 사이트 접근 제한 등의 부가적인 기능을 가지고 있으며 이전버전에 비해 향상된 파이어월의 기능을 제공하여 Microsoft의 야심작인 닷넷플랫폼에 있어서 보안을 담당하는 중요한 인프라의 관문역할을 담당하고 있다. 마이크로소프트 웹사이트 ( http://www.microsoft.com/korea/isaserver/ )를 참고한다.

개인네트워크와 공용네트워크 사이의 인터페이스 역할로 두 번째로 고려할 수 있는 서비스로는 NAT를 들 수 있다. 이것은 Windows 2000 Server이상에서 지원되는 기능이다. ICS에 비해서는 OS가 서버여야 한다는 제약이 있지만 그만큼 추가기능들을 지원하므로 작은 규모의 회사환경에서 ICS보다는 권장할 만한 기능이다.

예제의 상황은 동일하다. 다만 개인네트워크와 공인 네트워크를 연결하는 방법으로 ICS가 아니라 NAT라는 서비스를 이용하는 것이라는 차이만 있다.

<그림8-8. ipconfig 결과 >

<그림8-8>에서는 NAT서비스를 구현하고자 하는 서버에서 ipconfig를 입력한 결과를 보여준다.    NAT는 ICS와 비교해서 설치하는 방법부터가 다르다. '관리도구à라우팅 및 원격액세스'를 이용해서 관리한다.

 예제의 화면은 Windows Server 2003에서 작업한 화면을 캡처한 것이다.