앞에서 잠깐 언급을 한 바는 있지만, 웹사이트의 등록정보에서 ‘디렉터리 보안’탭의 ‘익명 액세스 및 인증제어’에서 다루는 ‘인증’이라는 것은 클라이언트가 웹서버에 접근할 때 어떠한 인증을 지원하는지에 관련된 내용이었다. 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웹사이트가 잘 열리는 것을 확인할 수 있다. 웹브라우저 아래의 상태표시줄에 노란 자물쇠를 더블클릭하여 인증서를 확인할 수 있다.

흔히들 착각하는 것중의 하나가 “전자메일 메시지는 안전하다”라는 생각이다. 하지만 아쉽게도 전자메일로 날아다니는 수많은 정보들은 암호화가 되지 않은 깨끗한 상태로 전송이 된다. 중요한 메시지를 전송하고 있다면 이러한 점을 고려해야 한다. 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가 어떻게 사용되는지 알아보았다. 위의 순서를 따라서 직접 구현해 볼것을 권장한다. 눈으로 보는 것은 금새 잊혀진다. 솔직히 이것은 상당히 번거로운 작업이 아닐 수 없다. 그런 이유로 몇몇 업체에서는 대칭키를 이용한 전자메일 보안에 관한 솔루션을 내놓고 사용하기도 하는데 이러한 것들을 통해서 우리는 데이터 보호, 보안 이라는 분야가 업계에서 점점 더 필요성이 커져 가고 있다는 사실을 짐작해 볼 수 있을 것이다. 개념적인 부분은 잘 익혀두고 관심을 가져보길 권하며 이번 장을 마친다.

3-4-1.인증기관의 필요성

공용키 암호화가 어떻게 동작하는지 위에서 설명했다. 앨리스가 보내는 데이터를 암호화하기 위해서는 먼저 밥의 공용키를 얻어야 한다고 했는데, 이때 앨리스는 밥으로부터 공용키를 얻고 나서 한가지 의문이 생긴다. 자신이 받은 공용키가 “진짜 밥의 공용키일까? 밥을 가장한 이브의 공용키는 아닐까?” 하는 의문이 들 것이다. 실제 환경에 적용시켜 보자. 여기서 밥은 웹서버에 해당하고, 앨리스는 웹브라우저에 해당한다. 당신은 인터넷 쇼핑몰을 운영하는 웹서버에 접속한 다음 마음에 드는 물건을 장바구니에 담았다. 마지막으로 구매를 결정하고 [결제하기]버튼을 클릭한 후 신용카드 번호, 유효기간 등의 개인정보를 웹서버에게 제공하려고 한다. 이때 안전하게 데이터를 보내기 위해 웹서버의 공용키를 웹서버로부터 받았다. 당신은 이 공용키를 이용해서 웹서버로 전송했지만 알고보니 이 공용키를 제공했던 것은 악의의 제3자였고, 당신의 중요한 개인정보는 외부로 유출이 되게 되었다.

이것을 해결하기 위해서는 당신이 사용하는 웹브라우저는 웹서버로부터 공용키를 얻게 되면 이것이 진짜 거래의 상대방인 웹서버가 발행한 공용키인지 확인해야 할 필요가 있다. 어떻게 확인할 것인가?

이것은 전자상거래가 오프라인상의 실제상거래에서도 마찬가지이다. 가게에서 물건을 하고 신용카드로 대금을 지불한다고 가정하면 가게에서는 고객을 믿고 물건을 내 주지는 않는다. 제3의 기관인 신용카드 회사(은행)를 믿고 물건을 내 주게 된다. 이것처럼 디지털 세계에서도 거래의 양자간의 각종 불신요소들을 해결하기 위하여 제3의 기관의 필요성이 대두된다.

인증기관(Certificate Authority, CA)은 그러한 필요성에서 의미를 찾을 수 있다. 인증기관은 서버의 신원을 증명해 준다. 때로는 클라이언트의 신원을 증명해 주기도 한다. 서버나 클라이언트가 디지털 세계에서 하고자 하는 작업에 신뢰를 부여하기 위한 인증서를 발행하는 작업, 이것이 인증기관의 주된 업무라고 할 수 있다. <그림3-5>를 통해서 인증기관의 역할을 알아보도록 하자.

그림의 예제는 웹서버와 사용자와의 통신을 그림으로 나타낸 것이다. 안전한 거래를 위해서 먼저 웹서버는 한 쌍의 공용키와 개인키를 생성한다(①). 개인키를 자신의 하드디스크에 안전하게 저장을 한 다음 공용키를 웹서버에 게시를 한다. 사용자들이 웹서버로 보내는 데이터를 웹서버의 공용키를 이용해서 암호화해서 보낼 수 있도록 하기 위한 조치이다. 하지만 사용자가 웹서버의 공용키를 신뢰할 수 없다는 것이 문제이다.

이에 웹서버는 웹서버에서 사용할 한 쌍의 키를 생성한 다음 공용키를 인증받기 위한 과정을 거친다. 자신의 공용키와 서버의 정보등을 첨부해서 CA에게 인증서 발급요청을 넘긴다(②). CA는 인증서 발급요청 정보를 잘 살펴보고 하자가 없다면 인증서를 발행하게 된다. 이 인증서에는 웹서버가 제시했던 공용키, 웹서버의 정보, 인증서의 주체, 마지막으로 CA의 전자서명이 들어있다. 결국 웹서버의 공용키를 제3자에 해당하는 CA가 인증을 해 주었다는 뜻이다(③).

이제 웹서버는 공용키만을 게시하는 것 대신에 CA로부터 받은 ‘인증서(Certificate)’를 게시하게 되고, 사용자가 웹서버로 중요한 데이터를 보내기 전에 웹서버로부터 인증서를 얻는다(④). (이 인증서에는 웹서버의 공용키가 저장되어 있음을 기억하라) 인증서를 받은 사용자는 인증서를 발행한 인증기관(CA)가 믿을만한 인증기관인지, 인증서의 날짜는 유효한지, 인증서의 주체와 현재 접근하는 사이트의 주소는 일치하는 지 등의 내용을 확인한다(⑤).

모든 확인이 끝났으면 이제 인증서안에 있는 공용키를 이용해서 자신이 보내는 데이터를 암호화할 수 있다. 믿고 거래할 수 있게 된 것이다. 이때의 인증서의 역할은 ‘서버의 신원증명’에 해당하는 사항이다.

반대로 생각할 수 있는 인증서의 용도는 인터넷 뱅킹에서 찾아볼 수 있다. 인터넷 뱅킹을 사용하기 위해서 우리는 먼저 은행을 직접 방문하여 인터넷 뱅킹 사용 신청서를 제출하고 사용자 계정을 발급받는다. 그것으로 끝나는 것이 아니라 자신의 컴퓨터에서 인터넷 뱅킹을 하기 위해서는 먼저 은행의 서버에 연결한 다음 ‘인증서’를 발급받아야 하는데 이때의 인증서는 ‘클라이언트의 신원을 증명’하기 위한 인증서에 해당한다.  

3-4-2.내부CA와 외부CA

인증기관을 크게 두가지로 구분해 볼 수 있다. 내부CA와 외부CA로 나누어 보겠다. 여기서 내부CA는 회사에서 임의로 설치한 내부적인 사용목적의 CA가 되겠고, 외부CA는 외부의 다른 서버 혹은 클라이언트와의 통신을 위해 사용할 수 있는 상업용CA라고 할 수 있다. 상업용CA중 대표적인 CA를 들라고 하면 ‘Verisign(베리사인)’을 들 수 있다. 관련분야에서 한마디로 잘 나가는 회사이다. 관심있게 보면 인터넷 쇼핑몰 웹서버의 상당수가 베리사인의 인증서를 사용하는 것을 알 수 있다.

웹서버를 운영하는데 내부CA로부터 인증서를 받을 수도 있고, 외부CA로부터 인증서를 받을 수 있다. 차이가 있다면 금전적인 부분을 먼저 들 수 있는데 외부CA로부터 웹서버 인증서를 하나 받으려면 보통 1년에 100만원 이상의 비용을 지불해야 한다. 상당수의 인터넷 쇼핑몰이 영세성을 면하지 못하고 있는 현실을 고려할 때 거리감을 느끼게 만드는 금액이다. 하지만 그러한 상업용 웹사이트의 경우 필요성을 찾을 수 있게 되는데, 그림을 통해서 접근을 해 보자.

<그림3-6>의 화면은 내부CA로부터 인증서를 받은 웹서버로 https://ssl.secure.pe.kr 를 통해서 접근했을 때 클라이언트의 화면에서 팝업되는 경고메시지이다. 3가지 항목중에서 첫번째 항목에는 노란색 느낌표가 들어있는 세모상자의 아이콘을 볼 수 있다. 메시지를 읽어보면 ‘신뢰 여부를 결정한 적이 없는 회사에서 발급한 보안 인증서입니다. 인증 기관의 신뢰 여부를 결정하려면 인증서를 확인하십시오.’라고 되어 있다. 당신이 관리하는 웹서버가 클라이언트에게 위와 같은 메시지를 주고 있다고 생각을 해 보면 어떠한가? 한글번역된 ‘신뢰여부를 결정한 적이 없다’라는 경고메시지도 치명적이라는 생각이 들게 만드는데, 이러한 메시지를 받은 사용자들이 선뜻 자신의 신용카드 정보등을 제공하고 싶어질까? 이 질문에 대해서는 ‘중요한 정보를 제공하고 싶지는 않지만 그래도 거래는 이루어질 것이다.’라고 개인적으로 생각한다. 그만큼 사용자들이 시스템이 내 보내는 오류, 경고 메시지에 둔감하기 때문에 가능한 일일 것이다. 실제로 국내에서 몇백만명 이상의 회원을 확보한 대규모 웹사이트들도 여전히 상당수의 사이트에서는 이러한 경고메시지를 발생시키는 웹사이트를 찾아 볼 수 있는 것이 현실이다.

언제까지 그렇게 사용자들이 무관심할 수 있을까? 라는 생각을 해 보면 그 시점까지가 내부CA를 이용해서 인증서를 발급받을 수 있는 시기라고 생각된다.

[인증서 보기]버튼을 눌러서 인증서를 확인하면 <그림3-7>과 같다.

그림에서 보면 발급대상이 ssl.secure.pe.kr 이다. 클라이언트가 접근할 때 https://ssl.secure.pe.kr 였으니 발급대상과 사이트 이름은 일치했다. 유효기간도 경과되지 않았으니 문제가 없다. <그림3-6>에서는 이 2가지 항목에 대해서는 녹색 체크 표시 아이콘을 보여준다. 하지만 인증서를 발행한 기관에 대한 신뢰성이 문제가 되는데 이것은 클라이언트가 신뢰하는 인증기관의 목록에서 웹서버의 인증서를 발급한 인증기관을 찾지 못했기 때문에 생기는 결과이다. 클라이언트 컴퓨터에서 ‘인터넷 익스플로러 à도구à인터넷 옵션à내용탭à인증서’ 순서로 접근해 보면 신뢰할 수 있는 인증기관의 목록이 이미 정의되어 있는 것을 알 수 있다. 여기에서 웹서버가 현재 사용하는 인증서를 발급해 준 인증기관의 이름을 찾지 못했다는 것이 경고메시지의 에러표시가 뜻하는 내용이다.

내부CA를 사용하면서 외부의 클라이언트의 웹브라우저에게 이것을 속이는 것은 불가능한 방법이다. 그렇기 때문에 에러메시지는 어쩔 수 없는 결과가 될 것이다. 해결할 수 있는 방법은 이 신뢰된 루트 인증기관의 목록에 있는 인증기관(CA)으로부터 인증서를 받아서 사용하는 방법이다.

<그림3-9>에서는 아무런 에러가 없는 잘 설정된 인증서의 정보를 보여준다. 누구나 알만한 대기업들의 웹사이트들도 이러한 PKI를 도입한 것이 그리 오래 되지 않은 일이다. 그중에서도 상당수의 기업들은 제대로 설정되지 않은 사이트를 오픈하고 있는 실정이니 ‘이제 시작이라 어쩔 수 없는 것인가?’라는 생각을 가지게 만든다. Windows Server 2003에 CA서비스를 추가하는 방법에 대해서는 9장에서 다룬다.

보통 줄여서 PKI라고 부르는 Public Key 구조는 앞에서 설명한 대칭키 기법과는 다른 알고리즘을 가지고 있다. 물론 암호화를 하겠다는 기본적인 생각은 차이가 없다. 대칭키를 사용하는데 있어서의 문제점으로 2가지를 거론했는데 Public Key는 이것을 해결해 주고 있다.

Public Key를 다른 용어로 표현한다면 비대칭키, 페어키(Pair Key)라는 용어를 들 수 있다. 용어에서 느껴지는 것이 있을 것이다. 앞에서 설명한 대칭키 알고리즘은 잠그는 키(암호화키)와 푸는 키(복호화키)가 동일하다는 의미에서 대칭키라고 불리운다고 했다. 그렇다면 비대칭키라는 뜻은 이 두개의 키가 서로 같지 않다는 것을 의미하는 것? 그렇다. Public Key알고리즘에서는 암호화키와 복호화키가 한쌍의 키(Pair Key)를 이루고 있다.

이 한쌍의 키는 Public Key(공용키)와 Private Key(개인키)로 구성되어 있다. 공용키는 누구라도 사용할 수 있도록 공개가 되며, 개인키는 HDD, Smart Card등의 공간에 보관하면서 오로지 키쌍을 만든 주체만 사용할 수 있다는 것이 보장되어야 한다.

이 키들은 다음과 같이 사용된다. Public Key 기법을 사용하기 위해서는 먼저 ‘공용키’와 ‘개인키’라는 한쌍의 키를 생성해야 하고, 공용키로 암호화한 데이터는 오직 해당 공용키와 한쌍으로 생성된 개인키로만 해독할 수 있다는 것이다. 그렇다고 무조건 공용키는 암호화키이고 개인키는 복호화키라는 개념은 아니다. 반대상황도 있다. 개인키로 데이터를 암호화하면? 이번에는 한쌍에 해당하는 공용키로만 해독이 가능하다.

공용키는 이름에서 느껴지는 것처럼 누구나 사용할 수 있는 키다. 공개가 되는 키라는 뜻이다. 이 키는 웹서버에 게시되거나 파일서버에 공유되거나 안전하지 않은 전자메일을 통해서 상대방에게 보내져도 아무 문제가 없다. 대칭키에서 가졌던 비밀키 전송의 문제점을 해결해 주는 것이다. 예를 들어 웹서버가 키쌍을 만든다음 앨리스에게 공용키를 전송해 주었다고 하자. ‘앨리스’는 공용키를 이용해서 웹서버로 보내는 데이터를 암호화할 것이다. ‘이브’역시 이 공용키를 구하는 것이 어렵지 않다. 하지만 공용키를 이용해서 앨리스의 암호화된 데이터를 해독하는 것은 불가능하다. 공용키로 암호화된 데이터는 한쌍이 되는 개인키로만 해독이 가능하기 때문이다.

그러다 보니 이제 웹서버는 1만명의 회원을 위해서 1만개의 키를 생성할 필요가 없다. 오직 하나의 공용키만 가지면 되는 것이다. 1만명의 회원들이 동일한 공용키를 가지게 될 테지만 이들은 공용키로 암호화를 할 수는 있지만 공용키로 암호화된 데이터를 해독하는데 사용할 수는 없다는 것을 기억하라.

개념을 알고 나면 단지 그렇구나! 라고 생각할 수 있겠지만 처음 이러한 알고리즘을 만든 사람들은 대단하다는 생각이 든다. Public Key 알고리즘은 MIT공대에서 개발되었다고 한다. 개발한 사람들의 이니셜을 딴 RSA 프로토콜이 가장 널리 사용되고 있다.

3-3-2.Public Key 암호화 (Confidentiality제공)

Public Key를 이용한 암호화에 대해서 <그림3-2>를 보면서 살펴보도록 하자. 앨리스가 밥에게 데이터를 전송하려고 한다. 중요한 데이터인데 이브의 도청이 염려스럽다. 안전하게 보내기 위해서 데이터를 암호화하기로 결정했는데 암호화키가 필요하다. 암호화키로써 데이터를 암호화해서 보내면 데이터를 받은 밥은 복호화를 해야 한다. 역시 복호화키가 필요할 것이다.

먼저 앨리스는 밥의 공용키를 구하는 것이 선행되어야 한다. 그 다음에 자신이 보내고자 하는 데이터를 밥의 공용키로서 암호화하여 전송해 준다. 밥은 암호화된 메시지를 받은 다음 앨리스가 암호화하는데 사용한 공용키와 한쌍으로 생성해 두었던 개인키를 이용해서 복호화하게 된다. 결국 데이터를 꺼낼 수가 있게 되었다.

한가지는 정리하고 가자. PKI를 이용하고자 할 때 상대방에게 안전하게 암호화된 데이터를 전송하고 싶다면 상대방의 공용키를 얻는 것이 첫번째 할일이다. 데이터에는 여러가지가 있을 것이다. 인터넷 쇼핑몰이 운영되고 있는 웹서버로 신용카드와 유효기간 등의 정보를 보낼 수도 있을 것이고, 회사의 중요데이터를 담은 전자메일 메시지일 수도 있다. 웹서버와의 안전한 통신을 위해서는 웹서버로부터, 전자메일을 보내고자 한다면 상대방으로부터, 먼저 할 일은 공용키를 얻어내는 과정이 필요하다는 것이다. 그 공용키로써 암호화를 했을 때 해독할 수 있는 사람은 오직 공용키와 쌍이 되는 개인키를 소유한 사람이다.

3-3-3.Private Key 암호화 (Authenticity제공)

이번엔 다른 관점이다. 개인키를 이용한 암호화가 어떠한 용도로 사용되는지에 대해 정리해 본다. 이번엔 밥의 입장에서 고려를 해 보자. 밥이 앨리스라고 주장(?)하는 사람으로부터 메시지를 받았다고 가정한다. 밥은 자신이 받은 메시지가 정말 앨리스가 보낸 것인지를 확인하고 싶어한다.

현실세계에서 요즘 거의 종이에 펜을 이용해서 글씨를 쓰고 편지를 보내는 일이 드문일이 되었다. 우리는 무엇인가 문서를 만들고 나서 자신이 확인했다는 표시로 ‘자필서명’이라는 것을 하곤 한다. 그러면 상대방은 그 서명을 통해서 받은 편지를 신뢰한다. 디지털 세상에서도 이와 동일한 알고리즘의 작업이 행해지고 있다.

앨리스는 밥에게 보낼 메시지를 만든 다음 자신이 보냈다는 것을 증명하기 위해 “서명”을 한다. 바로 전자서명이 되는 것이다. 서명이 유효하기 위해서는 지켜져야 할 조건이 있다. 당사자가 아닌 다른 사람은 동일한 서명을 할 수 있어서는 안된다는 것이다. 그렇다면 앨리스가 밥에게 보낼 메시지에 서명을 할때는 다른 사람은 가지고 있지 못한 자신만이 가진 유일한 증표를 사용해야 할 것이다. 그것은 바로 자신의 Private Key(개인키)를 이용하는 것이다. 앞에서 공용키는 누구에게나 공개가 되지만 개인키는 오직 키쌍을 생성한 주체만이 가지고 있다고 한 것을 기억하면 될 것이다. 과정을 <그림3-3>을 통해서 설명한다.

그림에서 앨리스는 밥에게 데이터를 전송하고자 한다. 밥에게 자신이 보내는 메시지라는 것을 신뢰할 수 있도록 하기 위해서 자신만이 가지고 있는 개인키를 이용하여 메시지를 암호화한다. 이것을 가리켜서 “Digital Signature (전자서명)”이라고 부른다. 결국 앨리스는 자신이 서명한 메시지를 네트워크를 통해서 밥에게 보낸다. 이 메시지를 받은 밥은 앨리스의 공용키를 이용해서 복호화를 하고, 앨리스의 공용키로써 복호화가 이루어지면 자신이 받은 메시지가 앨리스가 보낸 것이 맞다고 판단을 한다. 앨리스를 가장한 제3자가 보낸 메시지라면 앨리스의 공용키로 해독이 되지 않을 것이다.

만일 이 메시지를 도중에 이브가 가로챘다면? 이브는 당연히 이 메시지를 읽을 수가 있다. 앨리스의 공용키만 있다면 얼마든지 해독이 가능할 것이기 때문이다. 기밀성은 제공되지 않는다는 것을 의미한다.

이렇듯 개인키를 이용해서 암호화하는 것(전자서명)은 제3자가 데이터를 열지 못하게 하기 위한 방법은 아니다. 다만 상대방에게 자신을 가장한 제3자가 아닌 진짜 자신이 보낸 메시지라는 것을 알려주기 위한 방법일 뿐이다.

3-3-4.Hash함수와 Digest (Integrity 제공)

개인키를 이용한 전자서명과 더불어 추가로 고려해야 하는 내용이 있다. 밥이 앨리스로부터 데이터를 받았을 때 밥은 이 데이터가 앨리스가 보낸 원본데이터 그대로인지, 즉 중간에서 변조가 되었다거나 바이러스코드가 추가되었다거나 하는 등의 훼손된 것은 아닌지를 알고 싶다는 것이다. 결국 무결성(integrity)이 보장되어야 한다는 것인데, 이것은 바로 Hash(해시)라고 부르는 함수(Function)와 관련이 있다.

해시는 주로 원본을 감추고 확인하기 위한 용도의 함수인데, ‘단방향 함수’이며 원본이 1비트만 달라져도 두 개의 문서는 서로 다른 결과값을 가진다는 특징을 가지고 있다. Y=f(x) 라는 일반적인 공식에 대입시켜 보자. 해시함수 역시 모든 함수가 그렇듯이 x값을 대입시키면 결과값(y)이 나오는데, 거꾸로 y값을 가지고는 x가 무엇이었는지를 구할 수가 없다는 특징을 가진 함수이기 때문에 ‘단방향 함수’라고 부른다. 이것은 네트워크 상에서 상당히 유용하게 쓰일 수 있다. 어떤 사용자가 서버로 자신의 암호인 1234 를 전송하고 있다고 가정을 했을 때, 1234를 그대로 전송하면 제3자의 도청위험에 노출되게 된다. 하지만 1234를 그대로 전송하는 것이 아니라 해시함수를 이용해서 해시하여 전송하게 되면 설사 제3자가 이 패킷을 도청했다고 하더라도 1234라는 암호는 감출 수가 있기 때문이다.

제3자는 이 패킷을 가지고 원래 암호를 알아내기 위해 노력하겠지만 해시함수의 특성상 원본을 알아내는 것은 어렵다고 판단된다. 해킹에 조금 관심을 가진 독자라면 흔히 ‘패스워드 크랙킹 툴’들에 대한 이야기를 접할 수 있을 것이다. 이러한 암호 크랙킹 툴들중에는 “사전공격(Dictionary Attack)’이라는 공격방법을 이용하는 툴들이 많은데, 이러한 툴들은 해시값을 역으로 추적해서 원본데이터를 알아내는 것이 아니라 원본데이터를 유추하는 방식을 사용한다. 즉 암호를 짐작하여 생성한 다음 해시함수를 이용하여 해시하고 그 값을 자신이 네트워크에서 훔쳐낸 값과 비교하는 방법을 이용한다. 두 값이 같으면 자신이 유추한 암호가 사용자의 암호라고 판단하는 것이다. 이 때 원본데이터에 해당하는 단어들을 정의한 사전파일을 사용하고 있어서 이를 “사전공격(Dictionary Attack)’이라고 한다. 대부분의 보안지침에서 ‘사전에서 쉽게 찾을 수 있는 단어를 암호로 사용하지 말라’라고 하는 이유는 바로 이러한 공격의 위험을 염두에 둔 것이다.

원본데이터를 해시함수를 이용하여 계산하여 나오는 값을 Digest(요약)이라고 부른다. 원본데이터중에서 뽑아낸 요약된 비트라는 의미에서다.

구체적으로 무결성(Integrity)을 보장하기 위해서 어떻게 해시함수가 사용되는지 <그림3-4>를 통해서 설명한다. 그림의 번호순으로 차근차근 접근해 보자.

그림에서는 앨리스가 밥에게 데이터를 전송하려고 한다. 먼저 앨리스는 데이터를 해시하여 다이제스트를 생성한다. 다이제스트는 해시함수를 이용하여 얻은 결과값이다. 이 다이제스트를 자신의 개인키를 이용하여 암호화한다. 개인키를 가진 사람만이 할 수 있는 이 작업이 ‘전자서명’이라고 설명한 바 있다. 그 다음에 네트워크를 통해서 밥에게 ‘전자서명된 데이터’를 전송한다. ‘전자서명된 데이터’라는 표현을 잘 음미해 보라. 앨리스가 전자서명을 어떻게 만든 것인지를 보면 결국 앨리스가 보내는 ‘전자서명된 데이터’가 의미하는 것은 ‘원본데이터+다이제스트’라는 것을 알 수 있을 것이다.

이 메시지를 받은 밥은 몇 가지 작업을 거친다. 먼저 앨리스가 보낸 메시지라는 것을 확인하기 위해 앨리스의 공용키를 이용해서 ‘전자서명’이라는 암호문을 해독한다. 이 복호화의 결과로 얻는 것은 앨리스가 보내준 ‘다이제스트’이다. 그 다음에 원본데이터를 앨리스가 사용한 것과 동일한 해시함수로 해시하여 다이제스트를 생성한다. 그리고 2개의 다이제스트를 비교하는 일을 한다. 이 2개의 다이제스트가 정확히 일치한다는 것이 밝혀지면 다이제스트를 생성한 원본이 동일하는 것을 증명해 주는 것이다. 밥이 받은 데이터가 도중에 훼손되었다면 밥이 직접 생성한 다이제스트는 앨리스가 만들어서 보낸 다이제스트와 ‘불일치’라는 결과를 보일 것이다.

이러한 방법을 이용해서 데이터 무결성을 보장해 줄 수 있다.

그림의 내용을 다시 정리해 보았다.

오래된 암호화 방법이다. 대칭키 알고리즘을 흔히 비밀키 알고리즘이라고도 부른다. A와 B만이 아는 비밀키를 이용해서 암호화 통신을 한다는데서 기인한다. 여기에서 핵심은 대칭키라는데 있다. 키가 대칭을 이룬다? 이것은 암호화키와 복호화키가 동일하다(대칭을 이룬다)라는 데서 정답을 얻을 수 있다.

<그림3-1. 대칭키 알고리즘>

<그림3-1>의 예제에서 보듯이 대칭키 알고리즘에서는 암호화를 할 때 사용하는 키와 복호화를 할 때 사용하는 키가 동일해야 한다. Alice가 ‘1234’를 키로서 데이터를 암호화했다면 Bob역시 ‘1234’라는 키를 알아야만 복호화를 할 수 있다는 것이다. 이 대칭키 알고리즘을 사용하는 대표적인 암호화 프로토콜로는 DES(Data Encryption Standard, 56bit, ‘데쓰’ 프로토콜로도 읽는다.), 3DES(Triple DES, 168bit)가 있다. DES를 세번 반복하는 3DES는 상대적으로 안전하기는 하지만 당연히 키 길이가 길어짐으로써 더 느려진다는 단점이 있다. 56bit키를 사용하는 DES는 사용을 권장하지 않는다. 현재 대부분의 상업용 암호화는 128비트 이상의 암호화가 구현되는 것이 일반적이다.

이러한 대칭키 알고리즘은 작은 키 길이를 사용함으로써 빠르게 암호화와 복호화가 이루어진다는 장점이 있지만 몇가지 문제점을 안고 있다.

첫번째 문제는 암호화 키 교환의 어려움이다. Alice가 ‘1234’라는 암호화키를 이용해서 암호문을 만들었다면 암호화된 메시지를 받은 Bob은 역시 ‘1234’라는 키를 알아야만 한다. Bob은 이 키를 어떻게 알 수 있을까? 이때 사용된 암호화키는 웹사이트에 게시하거나 공유폴더에 저장해 둘수는 없다. Bob이 아닌 제3자가 이 Key를 가져간다면 Alice의 암호문을 해독하는 것이 가능하기 때문이다. 전자메일을 사용해서 key를 전송하는 것 역시 조금은 낫지만 바람직한 방법은 아니다. 결국 안전한 방법은 디스켓에 담아서 직접 상대방에게 가져다 주는 방법을 사용해야 할 것이다. 번거로운 일이 아닐 수 없다. 이것을 해결하기 위해서 SSL, Kerberos등의 다른 암호화 방법과 더불어 키 교환을 제공하고 있지만 대칭키 알고리즘 자체로만 보자면 고려되어야 할 부분이다.

두번째 문제는 키 관리의 어려움을 들 수 있다. 예를 들어서 웹사이트 하나가 있고 1만명의 회원이 있다고 하자. 1만명의 모든 회원들은 웹서버에 신용카드번호, 유효기간, 비밀번호 등을 전송해야 하는데 당연히 고려할 점은 웹서버가 아닌 어느 누구도 이 데이터를 열수 있어서는 안된다. 이 경우 키는 몇 개가 필요할까? 웹서버가 한대이니 키도 한 개만 있으면 좋겠지만 아쉽게도 키는 1만개가 있어야 한다. 1만명의 회원들에게 각각 고유한 비밀키를 할당해 주어야 한다는 것이다. Alice라는 회원과 Eve라는 회원의 키가 동일하다면 Alice가 암호화한 데이터를 Eve도 해독할 수 있기 때문이다. 그렇게 되면 Confidentiality는 깨지고 만다.

이것에 비해 PKI는 보다 유연한 관리를 가능하게 만든다. 하지만 다음장에서 설명할 PKI는 대칭키 방식에 비해서 키 길이가 길고 알고리즘이 복잡하여 성능면에서 상대적으로 떨어진다. 그런 이유로 현재 사용되는 형태를 보면 대칭키 알고리즘과 공용키 알고리즘이 공존하여 쓰이고 있는 형태이다.

암호화가 왜 필요한가? 이것이 하고자 하는 목표는 뚜렷하다. A가 B에게 데이터를 전송할 때 이 데이터는 B가 아닌 다른 어느 누구도 들여다 봐서는 안된다는 것이다. 그것을 만족시키기 위해서는 A와 B만이 알고 있는 방법을 이용해서 원본 데이터를 위장할 필요가 있다. 제3자는 A가 보내는 데이터를 네트워크에서 훔쳐낼 수는 있지만 A가 보낸 완전한 원본 데이터를 알아낼 수는 없다. 그 방법은 B만이 알고 있기 때문이다.

A가 B에게 보내는 데이터의 종류는 중요하지 않다. A가 B라는 인터넷쇼핑몰에서 물건을 구입하고 자신의 신용카드 번호를 넘겨주는 것일 수도 있고, A가 B라는 사용자에게 회사의 기밀을 담고 있는 전자메일을 전송하는 것일 수도 있다. 어떠한 유형의 데이터이든지 상대방이 아닌 다른 사람은 데이터를 열수 없도록 하기 위해서는 ‘암호화’와 같은 방법이 필요하다.

현재 이러한 암호화가 제공하고자 하는 것, 즉 업계에서 암호화를 통해서 얻고자 하는 요구사항은 크게 4가지로 정리해 볼 수 있다. 잘 정리해 보자. 앞으로의 내용들을 이해하는데 필수적인 사항들이다.

암호화를 통해서 위의 4가지 요구사항을 해결해야 한다. 암호화를 한다는 것은 데이터를 통신의 양자간에만 알 수 있는 ‘방법’을 통해서 데이터를 변경시키는 작업을 의미한다. 이때 ‘방법’에 해당하는 것이 바로 ‘키(Key)’이다. 이 Key가 어떻게 사용되는가가 암호화를 이해하는데 가장 관건이 된다.

개념은 단순하다.

A는 데이터를 암호화키(Encryption Key)를 이용해서 걸어잠그고(암호화하고), B는 복호화키(Decryption Key)를 이용해서 해독하는 것이다.

요즘 IT관련지를 들여다 보면 빠지지 않고 등장하는 것이 VPN, 무선네트워크, PKI 등의 용어일 것이다. PKI를 이해할 때는 이것을 하나의 기술로만 이해하기보다는 하나의 커다란 ‘인프라’라고 이해할 필요가 있다. 전자상거래, 인터넷 뱅킹, 기밀 데이터의 보호, 사용자의 인증 등 안전한 데이터전송을 필요로 하는 수많은 분야에서 PKI기반의 보안이 구현되고 있고 이것에 대한 수요는 향후 보다 급속도로 확산되고 있다.

데이터를 보호하기 위한 기본적인 생각은 제3자는 읽을수 없도록 데이터를 암호화하자는 것이다. 필자는 독자들에게 ‘암호학’에 대해서 이야기 하자는 것이 아니다. 암호학에 관련한 내용은 필자도 모른다. 다만 암호화기술이 어떤 기본 알고리즘을 가지고 있고, 어떻게 네트워크 환경에 적용되어 사용되는지, 그리고 어떻게 당신이 관리하는 회사에서 응용을 할 수 있을 것인지에 대해 알아보자는 것이다. 기본 알고리즘 역시 몰라도 구현하는데는 큰 지장이 없지만, 서두에서 말했듯이 우리에게 비교적 생소한 기술이기 때문에 막연히 툴을 이용하여 구현하고자 한다면 상당히 어렵고 구현을 하고서도 ‘내가 도대체 지금 무슨 작업을 한 거지?’라는 의문을 가지게 될 것이다.

2-4-1. CIDR - Subnetting

회사의 전체직원이 210명인 회사가 있다고 가정을 해 보겠다. 회사에서는 1인당 1대의 컴퓨터를 사용하고 있다. 회사에서는 보다 빠른 회선으로 업그레이드를 하면서 새로운 ISP로부터 인터넷 서비스를 받게 되고, 207.46.230.0 이라는 C Class Network ID를 할당받았다. 당신은 이 Network ID를 이용해서 회사의 클라이언트들에게 IP Address를 할당하는 작업을 해야 한다.

C Class Network ID 하나를 가지고 지원되는 호스트의 수는 최대 254까지이다. 회사의 전체 호스트 숫자가 210대이므로 C Class 하나만 가지면 충분히 지원할 수 있지만 이들

전체를 하나의 네트워크로 만들어 사용을 하기보다는 네트워크를 보다 작게 여러 개로 나누어 효율성을 기하고 싶다.

네트워크에 호스트수가 많아질수록 바로 브로드캐스트 통신이 문제가 되는데 네트워크에서는 이러한 브로드캐스트를 줄이는 방법으로 OSI 3계층 장비인 라우터를 통하여 네트워크를 여러개의 브로드캐스트 도메인으로 세그먼트하는 방법을 사용한다. 네트워크를 여러개로 나누면 각각의 네트워크에서 발생되는 브로드캐스트 패킷은 해당 네트워크에 한정되기 때문에 그만큼 효율적인 네트워크의 사용이 가능해 지는 것이다.

당신의 회사 역시 네트워크를 4개로 나눠서 한 세그먼트에 호스트의 숫자를 60대 미만으로 셋팅하고자 한다. 이러한 상황을 고려해 보겠다.

여기에서 당장에 혼란이 생긴다. 앞에서 서로 다른 물리적인 네트워크에서는 반드시 서로 다른 네트워크ID를 사용해야 한다고 했는데 당신은 ISP로부터 하나의 C Class 네트워크ID를 할당받았을 뿐이다. 이 하나의 네트워크ID를 4개의 세그먼트에 나눠서 차례대로 할당할 수는 있지만 그렇게 했을 때 이들 서로간에는 서로 통신을 할 수가 없게 된다. 같은 네트워크ID를 가지고 물리적으로 서로 다른 네트워크에 위치해 있으니 통신이 안 되는 것은 당연한 일이다.

ISP에 추가로 C Class네트워크 ID 3개를 요청했지만 추가비용을 요구한다. 거기다가 가만히 생각해 보니, 각각 254개를 쓸 수 있는 C Class ID를 3개 더 받아서 하나의 네트워크당 60개만 사용한다고 가정하니 나머지 194개씩의 IP는 버려질 수밖에 없는 노릇이다. IP Address의 낭비가 너무 심하다는 생각이 든다.

이것이 Class 체계의 IP Address가 가지는 맹점인 것이다. 보다 효율적인 방법은 없을까? 물론 있다. CIDR(Classless Inter Domain Routing)이라는 기법을 이용하여 IP Address를 보다 효율적으로 관리할 수 있다. 구현하는 방법은 의외로 간단하지만 처음 접근할 때 많이들 어려워하는 개념이다. 차근차근 접근해 보도록 하겠다. 실제로는 대기업 환경이나, ISP에서 쓰임새가 많은 기술이지만 시스템관리자에게는 상식적인 사항이 될 수 있다.

CIDR은 Subnetting과 Supernetting이라는 두가지로 구분해 볼 수 있다. 위의 예제의 경우에는 Subnetting이 필요한다. 할당받은 C Class ID는 네트워크 ID로 3개의 옥텟(24bit)을 사용하고 호스트ID로 1개의 옥텟(8bit)가 사용된다. 현재의 상황은 네트워크ID가 더 필요한 상황임을 고려하자. 해결방법은 호스트ID가 사용할 8bit중 일부를 네트워크ID용도로 전환하면 문제는 간단해 진다.

<그림2-21. CIDR기법- subnetting>

<그림2-21>에서 보듯이 호스트ID 8비트중에서 3비트를 네트워크ID 용도로 전환하여 사용하려고 한다. 이때 이 3비트를 "서브넷ID"라고 부르게 된다. 크게 본다면 네트워크ID에 포함될 수 있다. 좀 더 단계적으로 전체적인 계산방법을 알아보겠다.

2-4-2.  Subnetting 계산 방법

Subnetting을 계산할 때 익숙해지면 암산으로도 가능해진다. 하지만 지금은 단계별로 접근해 볼 것이다. 다섯단계로 구분을 해서 계산을 해 볼 것이다. 차근차근 한단계씩 이해하고 넘어가도록 하자.

2-4-2-① 회사에서 필요로 하는 네트워크의 수 결정

서브넷팅을 하기전 가장 먼저 할 일은 회사에서 필요로 하는 네트워크의 수를 파악하는 일이다. 이때 고려할 사항은 당장 필요한 것도 중요하지만 향후 네트워크의 확장이 고려된다면 네트워크의 여유가 있을 때 그 부분을 미리 고려하는 것도 필요한 일이다. 위의 예제상황에서는 총 4개의 네트워크가 필요하다고 결정되었다.

2-4-2-② 필요한 네트워크ID를 만들기 위해 전환할 bit수의 결정

①에서 결정된 4개의 네트워크를 지원하려면 호스트ID가 사용하는 8개의 비트중에서 몇 개의 비트를 네트워크ID로 전환시켜 사용해야 할까? 2²⁼ 4라는 결과가 나오니 2개의 비트가 있으면 되겠다. ( 만일 6개의 네트워크가 필요하다면 어떻게 할까? 2³=8이 되니 3개의 비트가 있으면 된다)

2-4-2-③ 서브넷 마스크(User defined Subnet Mask, Custom Subnet Mask) 계산

다음 해야 할 작업은 변경된 서브넷 마스크를 계산해야 한다. C Class의 기본서브넷 마스크는 255.255.255.0이었다. 이것은 C Class IP Address중에서 네트워크ID부분은 1, 호스트ID부분은 0으로 채운 결과 나온 값이었는데, 지금은 상황이 조금 달라졌다. 서브넷ID가 할당됨으로써 네트워크ID가 변동이 생겼으니 서브넷 마스크도 달라져야 한다. <그림2-22>에서는 변경된 서브넷 마스크가 계산되는 과정을 보여준다. 네 번째 옥텟의 호스트ID가 8비트에서 6비트로 줄어들고 상대적으로 네트워크ID가 2비트가 늘어났다. 일반적인 서브넷 마스크는 255.255.255.0 이었지만 호스트비트중 앞의 두 비트가 1로 바뀌었으므로 다시 계산하면 사용자정의된 서브넷 마스크는 255.255.255.192가 된다.

<그림
<2-22.사용자 정의 서브넷 마스크 계산방법>

여기서 한가지 고려해 볼 것이 있는데, 서브넷 마스크가 바뀌었다는 것이 무엇을 의미할까? 앞에서 우리는 호스트가 TCP/IP통신을 하는 절차를 보았는데 그때 호스트는 목적지 호스트가 자신과 로컬에 있는지 원격지에 있는지를 결정하게 되었다. 그 방법으로 자신의 서브넷 마스크를 이용해서 자신과 목적지 호스트의 네트워크ID를 계산한 다음에 결과값을 살펴서 같으면 로컬, 다르면 원격지로 판단한다고 했다. 위에서 계산된 새로운 서브넷 마스크를 이용하면 하나의 C Class인 207.46.230.0을 사용하더라도 범위에 따라서 서로 다른 네트워크ID라는 결과를 얻을 수가 있게 된다. 결국 하나의 C Class ID로써 여러개의 네트워크ID를 가진 효과를 내게 되는 것이다. 

2-4-2-④ 서브넷 ID 계산

 <그림2-23. Subnet ID 계산>

서브넷팅된 Network ID (Subnet ID)를 계산해야 한다. 207.46.230.0 네트워크 ID는 건드릴 수 없다. 호스트 비트인 8비트 중에서 앞의 2비트를 서브넷ID로 사용하고자 하기 때문에 <그림2-23>에서 노란색부분인 Subnet ID 2비트로써 생성할 수 있는 모든 경우의 수를 구해본다. 위의 그림에서 보듯이 00, 01, 10, 11 이라는 4가지 경우의 수가 나온다. 이것을 십진수로 전환하면 각각 0,64,128,192가 된다. 결국 서브넷 ID를 정리하면 다음과 같다.

- 207.46.230.0

- 207.46.230.64

- 207.46.230.128

- 207.46.230.192

2-4-2-⑤ 서브넷별 호스트ID의 범위 계산

이제 마지막 단계이다. 각 서브네트워크별 사용할 호스트ID의 범위를 구해야 한다. ④에서 구한 4개의 서브넷ID마다 생성할 수 있는 호스트ID의 범위를 구하기 위해 <그림2-24>를 참고해 보겠다.