웹 보안: COM+ 분산 응용 프로그램에 보안 프런트 엔드 설정

요약

인터넷의 경우 개발자는 각각의 클라이언트에게 서로 다른 보안 모델을 제공해야 하며 이 보안 모델은 닫혀진 네트워크에서 사용해야 합니다. 클라이언트와 서버 모두가 서로의 신분을 상대방에게 증명하려면 리소스가 너무 많이 필요하므로 보안 통신을 할 수 있는 다른 방법을 찾아 보아야 합니다.
이 기사는 공개 키 및 개인 키 암호화에 대한 디지털 인증에서부터 SSL(Secure Sockets Layer)과 웹 인증서에 이르기까지 이러한 방법으로 사용되는 다양한 옵션을 다룹니다. 그리고 IIS(Internet Information Services) 고유의 옵션과 함께 IIS에 인증서를 설치하는 방법도 다룹니다.
이 기사는 2000년 7월 발표 예정인 Keith Brown의 Programming Windows Security (Addison-Wesley) 에서 발췌하였습니다.

잘 알고 있겠지만 인터넷 상의 모든 사용자가 Microsoft® Windows®를 실행하지는 않습니다. 따라서 인터넷에는 다른 플랫폼을 사용하는 사람들도 많이 있으며 이들은 DCOM 패킷 전송 또는 수신 방법에 대해 전혀 알지 못할 것입니다. 많은 상업 기업들이 HTTP를 사용해 인터넷 그룹을 만들고 있으며 많은 사용자들이 정보의 고속도로로 뛰어들기를 원하므로 HTTP를 사용자가 상상할 수 있는 어떤 플랫폼에서나 실행되는 프로토콜로 만들기 위해 하드웨어 및 소프트웨어에 대한 엄청난 양의 연구, 개발, 그리고 가장 중요한, 표준화가 이루어져 왔습니다. 예를 들면, 현재, 대부분의 페이지가 웹을 액세스할 수 있습니다. 그리고 식품이 떨어지면 인터넷을 통해 자동으로 채소를 주문하는 냉장고가 개발 중에 있습니다. 이러한 기능을 잘 처리하려면 HTTP와 웹 서버 기술을 구입해야 하며 보안된 트랜잭션을 원한다면 엄청나게 다양한 클라이언트 플랫폼과 방화벽을 갖추고 있다 하더라도 인증 방법에 대해 배워야 합니다.
이 기사와 곧 게시될 다음 파트는 COM+ 분산 응용 프로그램에 웹 프런트 엔드를 설정하는 것에 대한 내용입니다. 아마도 ISAPI, ASP 또는 CGI 응용 프로그램을 프로그램하는 방법은 이미 알고 있을 것입니다. 파트 1과 2를 다 읽고 나면 자신의 응용 프로그램이 정해진 특정한 구성을 실행하는 보안 환경을 보다 분명하게 이해할 수 있게 될 것이므로 Microsoft IIS를 이용한 작업이 보다 편안하게 느껴질 것입니다. 서로 다른 구성 옵션이 너무 많기 때문에 혼동을 일으키기가 쉽습니다.
이 기사에서는 공개 키 암호화와 인증서를 사용하는 웹에서 인증이 어떻게 이루어지는지를 설명합니다. 그리고 파트 2에서는 다양한 클라이언트 인증과 각각의 장단점, 응용 프로그램 격리 옵션, COM+ 응용 프로그램에서 IIS를 게이트웨이로 사용하는 데 대한 몇 가지 팁을 제공합니다.

웹 인증

온라인 상태에서 여기저기를 돌아볼 때에는 일반적으로 통신을 통해 방문할 장소와 특별한 목적 등에 대한 중요한 정보를 전송합니다. 그리고 티켓을 구입하거나 숙소 또는 렌트 카를 예약하기 위해서는 통신을 통해 신용 카드 번호를 전송해야 하는 경우도 있습니다. 수많은 사람들이 자신의 통신이 얼마나 안전한지에 대해 파악하지도 않고 기꺼이 그러한 정보를 제공한다는 것은 정말 놀라운 일입니다. 보안에 대해 염려하는 대부분이 사용자들은 Netscape Communicator의 작은 열쇠나 Microsoft Internet Explorer의 작은 자물쇠를 찾아 보고는 이 통신이 암호화되므로 나쁜 사람들이 중요한 정보를 볼 수 없을 것이라고 편하게 생각합니다. 하지만 그 메시지를 받는 사람이 누구인지를 모른다면 메시지를 암호화하는 것이 무슨 소용이 있습니까? 상대방이 나쁜 사람이 아니라 정말 Amazon.com인지 어떻게 압니까? Jeff Bezos가 Amazon 고객 하나하나와 식사를 함께 하면서 나중에 세션 키를 만들 때 사용할 수 있는 비밀 암호 구문을 알려 주는 것도 아닌데 말입니다. 따라서 전 세계 네트워크로 확장할 수 있는 일정한 인증 형태가 필요합니다.
I지난 Security Briefs 칼럼에서 한 사용자의 신분을 다른 사용자에게 증명하는 데 사용할 수 있는 두 가지 인증 프로토콜인 Windows NTLM(NT® Challenge/Response Authentication)과 Kerberos에 대해 설명했습니다. 이 기술을 지금과 같은 특정한 문제에 적용할 수 있을까요?
먼저, NTLM은 클라이언트의 신분을 서버에 증명하기 위한 것으로 일반적으로 한 회사 내에서와 같은 제어된 환경에서 제 기능을 발휘합니다. 사용자는 서버의 신분을 절대 확신할 수 없으며 일반적으로 인터넷에서 서버를 스풀하는 것보다 내부 서버를 스풀하는 것이 훨씬 더 어렵습니다. 웹 상에서는 라우터 손상이 발생할 가능성이 훨씬 더 높으므로 초점을 바꾸어 스풀된 서버로부터 사용자를 보호하는 것이 가장 중요합니다. 전자 상거래 사이트는 여전히 일정한 형태의 사용자 인증이 필요하긴 하지만 신용 카드 번호를 요금 청구 주소와 서로 연관시켜 보는 등의 아주 단순한 방법일 경우가 많습니다. 그리고 클라이언트 인증은 신용 카드 기관에 떠밀어 버립니다. NTLM을 역으로 사용하여 클라이언트가 서버의 자격을 확인하려면 이 서버가 개별 클라이언트 또는 그 클라이언트의 인증 기관과 공유 비밀을 가지고 있어야 하는데 이 또한 Amazon.com의 CEO가 점심 식사 자리에서 클라이언트의 귀에 공유 암호 구문을 속삭이는 것과 별반 다를 것이 없습니다.
그렇다면, Kerberos는 어떨까요? IETF (http://www.ietf.org/rfc/rfc1510.txt )가 정의하였고 Windows 2000에서 사용되는 분산 보안용 프로토콜인 Kerberos는 특정한 상호 인증 규정을 제공합니다. 즉, 클라이언트가 인증 작업 시 서버의 신분을 확인할 수 있습니다. 그런 다음 그 작업에서 만들어진 세션 키를 사용해 클라이언트가 암호화하여 서버로 전송한 정보는 그 클라이언트가 처음에 인증한 서버에만 유용합니다. 그 서버만이 세션 키를 알고 있으며 들어오는 메시지를 해독할 수 있기 때문입니다.
확장성에 있어서도 Kerberos는 분명 좋은 방법입니다. 만료 시간이 약 10시간인 티켓을 발행하므로 인증 요청 시 매번 인증 기관과 연락을 해야 하는 NTLM과 같은 프로토콜을 사용하는 경우보다 인증 기관의 로드가 크게 줄어 들기 때문입니다.
그렇다면 Amazon.com은 왜 Kerberos를 사용하여 클라이언트에게 자사의 신분을 증명하지 않는 걸까요? 그 이유는 다음과 같습니다. Kerberos를 사용할 경우 클라이언트는 자신의 신분을 서버에게 증명해야 합니다. 물론 Kerberos에는 서버가 자신의 신분을 클라이언트에게 증명하는 우수한 옵션 기능이 있긴 하지만 Amazon.com의 경우에는 이 방법이 도움이 되지 않습니다. 이 회사는 각각의 클라이언트를 암호화하여 인증해야 하며 따라서 이 경우에도 개별 클라이언트를 개인적으로 만나서 비밀을 알려주어야 하기 때문입니다.

그림 1 Kerberos가 역으로 적용되는 경우

하지만, Kerberos를 역으로 적용한다면 어떨까요? 일반적인 다른 방법과는 달리 서버가 클라이언트에게 자신의 신분을 증명하는 티켓을 제시할 수 있을 것입니다. 그림 1은 이 방법이 어떻게 이루어지는 지를 보여 줍니다. 클라이언트가 서버에 요청을 하면 서버는 자신의 신분을 확인할 수 있도록 티켓과 인증자를 클라이언트에게 전송합니다. 이 티켓에는 서버의 이름과 만료 날짜, 그리고 클라이언트와 서버가 통신을 보안하기위해 사용할 수 있는 키가 들어 있습니다. 이 정보는 서버가 아니라 인증 기관에서 암호화하므로 클라이언트가 인증 기관을 신뢰한다면 이 티켓도 손상되지 않았음을 신뢰할 것입니다. 클라이언트가 이 정보를 해독하여 인증자를 확인해 그 서버가 실제로 이 메시지를 보냈으며 메시지가 도난 당하거나 재생되지 않았음을 확인할 수 있다면 클라이언트는 확신을 가지고 이 티켓에 있는 키를 사용해 서버에 비밀 메시지를 전송할 수 있습니다.
Kerberos 개념에서 응용할 수 있는 좋은 아이디어들을 살펴 봅시다. Kerberos 티켓에는 암호화된 세션을 만드는 데 사용할 수 있는 키가 들어 있으며 NTLS와 같은 방법보다 인증 프로토콜을 더 잘 확장할 수 있도록 해 주는 만기 날짜가 들어 있고 소유권 개념(서버 이름이 이 티켓에 들어 있으며 서버임을 주장하려면 반드시 이 티켓과 관련된 비밀 키를 알고 있음을 증명해야 합니다)이 들어 있습니다. 가장 큰 문제는 이 티켓 대상 또한 고정되어 있다는 것입니다. 이 경우 대상은 한 클라이언트입니다. Amazon.com이 Alice에게 자신의 신분을 증명하고자 한다면 Alice를 대상으로 한 티켓을 얻어야 합니다. 그리고 Amazon.com이 Mary에게 자신의 신분을 증명하려면 Mary를 대상으로 한 티켓을 얻어야 합니다. 이는 모든 사람, 즉, 클라이언트 조차도 Kerberos 인증 기관에 등록을 해야 한다는 것을 뜻합니다. 클라이언트는 단순히 익명의 인터넷 사용자여서는 안되며 그럴 경우에는 이 방법을 이용해 서버의 신분을 확인할 수 있는 가능성이 전혀 없습니다.
왜 이런 제한이 있는 걸까요? 이는, 티켓과 임시 세션 키를 발행하는 Kerberos 키 배포 센터(KDC)가 전적으로 기본적인 암호화에 의존하여 그 티켓의 원본을 증명하기 때문입니다. 지금까지 설명한 역-Kerberos 방법을 사용할 경우 Alice가 Amazon.com에서 받는 티켓은 Alice와 그 인증 기관이 공유하는 비밀 키를 사용해 암호화되어 있습니다. Alice는 자신이 이 티켓을 성공적으로 해독할 수 있으며 따라서 이 티켓이 자신의 인증 기관에서 온 것임을 알 수 있기 때문에 그 티켓의 내용을 신뢰합니다. 하지만 웹을 통한 암호 키 체인을 형성하기 위해 Amazon.com(또는 그 Kerberos 인증 기관)이 인터넷 상에 있는 모든 클라이언트의 인증 기관에 사용자로서 등록한다는 것은 불가능합니다.
한편, 인증 기관이 특정한 비밀 키를 사용해 티켓을 암호화하고 누구나 비밀이 아닌 다른 키(잘 알려진 값)를 사용해 그 티켓을 해독하도록 할 수 있는 방법이 있다면 문제가 반쯤은 해결되었다고 할 수 있습니다. Alice가 Amazon.com에서 이 티켓을 받은 다음 인증 기관의 잘 알려진 키를 사용해 그 티켓을 해독할 수 있다면 Alice는 그 내용이 실제로 그 인증 기관에서 만들어진 것임을 믿을 수 있을 것입니다.
물론, 이것만으로 문제가 완전히 해결된 것은 아닙니다. 인증 기간의 잘 알려진 키를 사용해 누구나 그 티켓을 해독할 수 있다는 사실은 Alice가 Amazon.com으로 전송할 데이터를 암호화하기 위해 사용할, 그 티켓에 들어 있는 비밀 키를 누구나 볼 수 있다는 것을 뜻합니다. 그런 티켓에는 비밀을 넣을 수 없습니다. 따라서 인증 기관은 그 티켓에 비밀 대신에 Amazon.com의 잘 알려진 키를 넣습니다. 인증기관이 티켓을 암호화할 때 사용하는 키와 마찬가지로 누구나 이 잘 알려진 키를 사용하여 메시지를 암호화할 수 있지만 Amazon.com만이 그 메시지를 해독할 해당 비밀 키를 알고 있습니다. 그럴 경우 티켓에는 비밀이 담겨있지 않으므로 암호화할 필요가 없습니다. 대신 인증 기관은 앞서 언급한 특별한 비밀 키를 사용하여 그 티켓에 서명만 하면 됩니다. 두 쌍의 키(공개 키 와 비밀 키)를 사용하는 암호화 시스템으로 약간은 기묘하게 보이는 이 아이디어는 1970년대 중반에 Whitfield Diffie가 고안했습니다. 이 방법을 공개 키 암호화라고 합니다. 이제 지금부터 얘기하려는 티켓은 Kerberos 티켓이 아니라 디지털 인증서입니다.

공개키 암호화

공개 키 암호화 개념은 공개 키 사용 방법에 관한 자세한 사항을 파고들지 않더라도 쉽게 이해할 수 있습니다. 암호화 및 해독에 사용할 수 있는 비밀 키를 하나만 갖는 대신 이 키는 공개 키와 개인 키로 나누어집니다. 그리고 한 엔티티만 이 개인 키를 알고 있으며 공개 키는 말 그대로 공개됩니다. 대부분의 공개 키 암호화 시스템은 다음과 같은 방식으로 이루어집니다. 즉, A키를 사용해 일반 텍스트를 암호화하면 B키를 사용해서만 그 암호화된 텍스트를 해독할 수 있습니다 (그림 2 참조) 암호화와 해독에 서로 다른 두개의 키를 사용해야 하므로 공개 키 알고리즘은 비대칭 알고리즘이라고도 불리며 이에 비해 키를 하나만 사용하는 기존의 암호화 시스템은 대칭 알고리즘이라고 합니다.

그림 2 공개 키 암호화

다음은 공개 키 알고리즘의 예에 대한 설명입니다. 디지털 서명 알고리즘(DSA)에서 A 키는 개인 키이며 B 키는 대응하는 공개 키입니다. 이는 한 사람만이 일반 텍스트를 암호 텍스트로 암호화할 수 있지만 그 텍스트를 해독할 수 있는 사람은 많다는 것을 뜻합니다. 물론, 공개 키를 가진 사람은 누구나 이 암호 텍스트를 해독할 수 있으므로 이 방법을 사용해 비밀을 전송할 수는 없지만 서명에는 바로 이런 종류의 메커니즘이 필요합니다. 일반 텍스트의 단방향 해시를 계산하고 개인 키를 사용해 그 해시를 암호화하면 대응하는 공개 키를 아는 사람은 누구나 그 서명을 확인할 수 있습니다. 이러한 종류의 디지털 서명을 확인하면 사용자는 그 일반 텍스트가 원래의 장소에서 서명 되었으며 그 서명을 만들 수 있는 엔티티는 관련 개인 키를 알고 있는 사람뿐이라는 것을 알므로 그 일반 텍스트가 손상되지 않았다는 것을 알 수 있습니다.
가장 잘 알려진 디지털 서명 알고리즘은 그 투자자인 Rivest, Shamir, Adleman의 이름을 딴 RSA입니다. 이 알고리즘은 DSA와 마찬가지로 디지털 서명을 만드는 데 사용할 수 있지만 비밀을 전송하는 데에도 사용할 수 있습니다. 이 모드에서는 키를 반대로 사용합니다. 즉, 공개 키를 아는 사람은 누구나 일반 텍스트를 암호화할 수 있지만 개인 키를 아는 사람만이 그 결과 만들어진 암호 텍스트를 해독할 수 있습니다. RSA는 양방향으로 사용할 수 있다는 점 때문에 편리합니다. 즉, 같은 알고리즘을 사용하여 비밀을 암호화할 수도 있고 키 사용 방식을 반대로 바꾸면 서명을 만들 수도 있다는 것입니다. 하지만 이 두 작업에 동일한 키 쌍을 사용하는 것은 좋은 생각이 아닙니다. 따라서 일반적으로 서명과 암호화에는 서로 다른 키 쌍을 사용합니다(그림 3 참조).

그림 3 RSA 암호화 및 서명 생성

비대칭 알고리즘에서 두드러지는 점은 이 알고리즘이 해시 값(해시 값은 일반적으로 128~256 비트임)만 암호화하거나 해독하면 되는 서명을 만들고 확인하기에는 좋은 방법이지만 다량의 데이터를 암호화하기에는 대단히 취약한 방법이라는 것입니다. 대량 암호화의 경우에는 대칭 알고리즘이 수백 배 더 빠릅니다. 실제로 Alice가 Bob의 공개 키를 사용하여 Bob에게 암호화된 메시지를 보내려고 한다면 Alice는 임의의 기본 키를 만들어 밥의 공개 키로 암호화한 다음 Bob에게 보내기만 하면 됩니다. 그런 다음에는 Alice는 대칭 알고리즘을 사용해 데이터를 암호화하여 원하는 만큼의 데이터를 Bob에게 전송할 수 있습니다. 즉, 실제로 공개 키는 디지털 서명을 만들고 대칭 키(세션 키라고도 함)를 교환하는 두 가지 용도로 사용됩니다.

인증서

공개 키 암호화를 처음 배울 때에는 이 방법이 모든 키 교환 문제를 해결해 줄 만능의 해결책으로 생각되었습니다. 하지만 적절히 사용할 경우 보다 확장성 큰 암호화 시스템을 이끌어낼 수 있지만 이 키 교환 처리도 쉬운 방법은 아니라는 사실을 곧 깨달았습니다.
기본 암호화 시스템을 사용할 경우 모든 키는 비밀 키입니다. KDC가 Kerberos 티켓을 만들어 그 안에 세션 키를 넣을 때에는 나쁜 사람이 삽입된 키를 찾아내지 못하도록 티켓의 내용을 신중히 암호화합니다. 이는, 나쁜 사람이 세션 키를 자신이 아는 값으로 변경하기 위해 티켓에 손을 댄다면 그 티켓이 적절히 해독되지 않으므로 그 티켓을 받은 서버는 티켓이 손상되었다는 사실을 알 수 있다는 것을 뜻합니다. 세션 키 값이 변경되면 혼란이 발생할 수 있지만 Kerberos를 구현하면 이러한 종류의 골칫거리는 발생하지 않습니다.
공개 키를 통신상에서 전송할 경우 보호할 필요가 없다고 생각할 수도 있습니다. 물론, 공개 키는 비밀이 아니므로 Kerberos가 세션 키를 티켓 내부에 숨기듯 숨길 필요는 없지만 나쁜 사람이 중간에서 이 키를 부당하게 변경할 경우 어떤 일이 발생할 지를 한번 상상해 보십시오. 즉, Bob이 자신의 공개 키를 Alice에게 보내는데 Fred가 그 메시지를 중간에서 가로채서 Bob의 공개 키를 자신의 공개 키로 바꾼 다음 그 메시지를 Alice에게 전송한다면 그 다음부터 Alice가 손상된 키를 사용해 Bob에게 보내는 비밀을 Fred가 읽을 수 있게 됩니다. 하지만 Bob이 이러한 메시지 중 일부를 직접 받고 이 메시지에 대해 주의를 조금이라도 기울인다면 이러한 메시지가 전혀 알 수 없는 문장으로 해독된다는 사실을 알 수 있을 것입니다. Fred만이 자신의 공개 키를 사용해 암호화된 메시지를 완벽하게 해독할 수 있기 때문입니다. 하지만 Fred가 Alice와 Bob 사이의 라우터를 훔친다면 끝장입니다. Fred는 Alice가 암호화한 메시지를 매번 중간에서 손쉽게 가로채 해독하여 읽고 그 내용을 자신이 원하는 내용으로 변경한 다음 Bob의 공개 키를 사용해 암호화할 수 있기 때문입니다. 그럴 경우 Alice와 Bob은 Fred가 둘 사이에 있다는 것을 전혀 눈치 챌 수 없습니다. Bob이 Alice의 공개 서명 키도 요청하는 경우 Fred는 자신의 키를 대신 사용할 수 있습니다. 그렇게 되면 Fred는 Bob에게 가는 메시지에 자신이 서명을 하고 Bob은 Alice가 서명자라고 속게 될 것입니다. (.(이 사기에 대해서는 그림 4 참조). T이 문제에서 가장 중요한 점은 Alice나 Bob이 통신으로 받은 공개 키를 안전하게 사용할 수 있으려면 어떤 방법으로든 개인 키를 가진 사람의 신분을 확인해야 한다는 것입니다.
Bob이 Alice에게 보내는 키에 서명을 해서 Alice가 그 키가 실제로 Bob에게서 온 것임을 확인할 수 있도록 할 수는 없을까요? 이는 닭이 먼저냐, 아니면 달걀이 먼저냐와 같은 문제입니다. Bob의 공개 서명 키를 받아야만 Alice가 Bob의 서명을 확인할 수 있는데 Alice는 어떻게 그 키를 확인할 수 있을까요? 즉, 보안 키 교환은 비밀이 아닌 공개 키의 경우에도 아주 어렵습니다. 이 문제 해결에는 다음 두 가지 방법이 널리 사용됩니다.

• s 최소의 공개 키를 친구들과 교환하여(필요할 경우 직접) Fred가 중간에 낄 수 없도록 만듭니다. 그런 다음 이 친구들을 트러스트된 인증 기관으로 취급합니다. 이 방법이 바로 PGP(Pretty Good Privacy)에서 사용하는 모델입니다.
  
• s 트러스트된 인증 기관 계층을 사용합니다. 이 방법은 IETF가 설명한 디지털 인증 모델인 X-509가 사용하는 모델입니다 (http://ietf.org/ids.by.wg/pkix.html ).
  

그림 5 인증서

그림 6 트러스트 계층

그림 6, 에서 Foo라는 이름의 회사는 Bar가 발행한 Bob의 인증서를 받아들이기로 할 수도 있습니다. Bar는 Foo가 신뢰하는 인증 기관에서 인증을 받았기 때문입니다. 이는 Bob의 인증서에서 시작해서, Bob의 인증서는 Bar가 서명했고, Bar의 인증서는 Quux가 서명했고 하는 식으로 계속되는 일련의 인증서 체인을 형성합니다. Quux는 루트 인증 기관이므로 자신의 인증서에 스스로 서명을 합니다. 이 인증서가 바로 웹 브라우저와 같은 소프트웨어와 함께 분산되는 잘 알려진 인증서입니다. Foo가 이 체인에 속하는 인증서 중 하나(이 경우에는 Quux)를 신뢰하는 한 Foo는 Bob의 인증서도 신뢰합니다.
웹 서버는 X.509 인증서를 사용하여 자신의 인증을 클라이언트에게 증명하며 개별 클라이언트는 웹 서버의 인증서를 입수하면 그 신분의 증거를 요청하고 트러스트되는 인증 기관을 찾을 때까지 트러스트 계층을 따라 올라갑니다.

SSL, PCT, 그리고 TLS

1994년 Netscape Communications가 SSL(Secure Sockets Layer) 2.0이라고 알려진 네트워크 인증 프로토콜을 개발하여 보급했습니다. 1995년이 되자 Microsoft가 SSL 2.0보다 향상된 PCT(Private Communications Technology) 1.0이라는 프로토콜로 반격을 가했습니다. 하지만 거의 비슷한 시기에 Netscape가 독자적인 향상판인 SSL 3.0 프로토콜을 릴리스했으며 이 프로토콜이 현재 웹을 지배하고 있습니다. SSL 3.0은 1996년에 인터넷 초안으로 IETF에 제출되었으며 권장사항을 개발하기 위해 IETF 작업 그룹이 구성되었습니다. 1999년 1월, IETF는 RFC 2246을 발행하면서 그 그룹의 노력의 결과이자 사실상 SSL 3.0과 거의 다르지 않은 TLS(Transport Layer Security) 프로토콜 1.0을 문서화했습니다. 따라서 TLS 1.0을 IETF가 승인한 SSL 3.1 버전으로 보면 됩니다.
TLS로 표준화되었으므로 앞으로 TLS라는 용어를 사용하고 싶긴 하지만 TLS와 SSL은 거의 차이가 없으며 모두가 이 프로토콜을 여전히 SSL이라고 부릅니다. 따라서 이 자료에서도 SSL이라고 부르기로 하겠습니다.
보안 채널을 의미하는 SCHANNEL이라는 용어를 들어 보셨을 것입니다. 이 용어는 앞서 설명한 네 개의 인증 프로토콜 - SSL 2.0, PCT 1.0, SSL 3.0, TLS 1.0 - 을 모두 구현하는 Windows의 보안 지원 공급자(SSP) 이름입니다. SCHANNEL은 Windows 고유의 이름으로 종종 MSDN™ 문서에서 이러한 모든 인증 프로토콜의 보호물로 거론되곤 합니다.
IANA(Internet Assigned Numbers Authority)는 SSL을 통한 HTTP를 위해 포트 443을 예약하였으며(PCT와 TLS를 비롯한 다른 모든 SSL 또한 이 포트를 사용하긴 하지만) HTTPS는 이 포트에 사용되는 URL 체계의 이름입니다. 따라서 http://www.develop.com과 같은 URL은 vanilla HTTP를 사용해 포트 80으로 연결되며 https://www.develop.com은 SSL을 통해 HTTP를 사용하여 포트 443으로 연결된다는 것을 나타냅니다.

SSL

SSL의 핵심은 압축, 암호화, 메시지 인증 코드(MAC) 생성 및 확인뿐만 아니라 메시지 프레이밍, 타이핑 및 조각화를 제공하는 기록 프로토콜입니다. MAC 인증은 메시지 자체를 인증하는 데 사용되며 암호화 차원에서 두 가지 특성, 즉, 이 메시지가 전송 중 손상되지 않았는지, 그리고 그 메시지가 사용자가 안전한 대화를 나눈 바로 그 사람에게서 온 것인지를 증명합니다. 보낸 사람은 일반적으로 통신의 한쪽에서 쌍방이 공유한 기본 세션 키를 사용해 메시지의 단방향 해시를 암호화하여 MAC를 만들어 그 MAC를 메시지에 첨부합니다. 그러면 받은 사람은 동일한 절차를 실행하여 MAC를 확인합니다.
SSL은 일반적으로 연결 지향적인 통신, 즉, TCP가 사용된다고 가정합니다. 따라서, 기본 통신 프로토콜로부터 메시지 조각을 정확한 순서로 받지 않으면 받은 사람이 그 스트림을 해독할 수 없습니다(개별 조각은 독립적으로 해독되지 않습니다).
MAC를 암호화하거나 생성/확인하기 위해서는 양 종점이 세션 키라고도 하는 비밀 키를 공유해야 합니다. 레코드 프로토콜의 상단에서 SSL은 핸드셰이크 프로토콜이라는 더 높은 수준의 프로토콜을 사용해 이 키를 교환하고 클라이언트와 서버를 서로에게 인증합니다. 인증은 기술적인 옵션이며 SSL을 사용할 수 있는 모드는 상호 인증, 서버 전용 인증(서버가 누구인지를 클라이언트가 알게 됩니다), 그리고 인증 안됨의 세 가지입니다.
세 번째 옵션은 생각해볼 필요도 없습니다. 암호화되었지만 인증되지 않은 링크를 통해 중요한 데이터를 교환한다는 것은 외진 식당의 어두운 한쪽 구석에 두 스파이가 앉아 상대방이 누구인지도 전혀 모른 채 비밀을 속삭이는 것과 같기 때문입니다. 오늘날 웹을 통한 대부분의 상업용 HTTPS 트래픽은 서버만 인증하는 모드에서 SSL을 사용합니다. 즉, 클라이언트는 익명이며(SSL이 관여하는 한) 서버만 인증을 받는 것입니다.
SSL은 이 세 경우에 대해 네 가지 핸드셰이크를 사용합니다(그림 7 참조). 이 핸드셰이크에 대해서는 인증 및 키 교환에 필요한 요소에 대해서만 중점적으로 설명하겠습니다. 클라이언트(Alice)가 먼저 서버(Bob)에게 클라이언트 Hello 메시지를 보내 자신이 새로운 SSL 세션을 만들기를 원한다고 알립니다. 이 메시지에는 정렬된 기본 설정 cipher suite 집합뿐만 아니라 Alice가 만든 임의의 숫자가 들어 있습니다 각각의 cipher suite는 키 교환 알고리즘, 일괄 암호화 알고리즘, 그리고 MAC 알고리즘을 나타냅니다.

그림 7 SSL 세션 만들기

Bob은 들어오는 요청을 확인하여 Alice가 제안한 목록에서 cipher suite를 선택해(받아들일 수 있는 것이 하나 있다면) 서버 Hello 메시지를 Alice에게 보냅니다. 이 메시지에는 Bob이 독자적으로 만든 임의의 숫자와 함께 Bob이 Alice의 목록에서 선택한 cipher suite가 들어 있습니다. Bob이 키 교환 알고리즘에 따라 자신의 신분을 증명해야 하는(인증 안됨 옵션만 그럴 필요가 없음) cipher suite를 선택했다면 자신의 X.509 인증서도 함께 전송합니다. 키 교환 알고리즘에 따라 Bob은 키 교환을 허용하거나 미국 수출 규제에 따르는 추가 정보를 포함시켜야 할 수도 있습니다(측면의 (What is Server Gated Cryptography? "참조). 하지만 단순하게 Bob이 Alice에게 보낸 인증서도 키 교환에 직접적으로 사용할 수 있다고 가정합시다. 마지막으로, Bob이 자신의 인증서를 제공한다면 그는 Alice의 인증서에 대한 요청서를 함께 보낼 수 있습니다.
Alice가 Bob에게서 이 정보를 받으면 Alice는 Bob의 인증서를 확인할 수 있습니다. 루트 인증 기관의 서명을 자신이 가지고 있는, 그 기관의 잘 알려진 공개 키 사본과 비교 확인하는 과정이 뒤따릅니다(인증서 확인에 대해서는 인증서 해지를 다루는 부분에서 다시 다룹니다). 이 때, Alice는 자신이 Bob의 공개 키는 가지고 있지만 상대방이 실제로 Bob이라는 아무런 증거도 가지고 있지 않다는 것을 압니다. 세션 키를 전혀 교환하지 않았으므로 Alice는 이제부터 이 문제를 해결해야 합니다.
Alice가 Bob에게 자신의 인증서(Bob이 요청한 경우)와 Bob의 공개 키로 암호화한 프리마스터 비밀이라고 하는 또 다른 임의의 숫자를 전송합니다. Bob이 인증서를 요청한 경우에 Alice는 핸드셰이크 처리 시 지금까지 레코드 계층으로 보내거나 받은 모든 데이터에 자신의 서명을 추가합니다.
지금까지 SSL 레코드 계층은 NULL 일괄 데이터 암호화 알고리즘을 사용해 데이터를 스트림하기만 했으며 암호화는 전혀 하지 않았습니다. Alice은 이제 "별도의 명시가 없는 한 나는 향후의 모든 아웃풋에 대해 조금 전 협상한 cipher suite를 사용하도록 레코드 계층을 지정할 것이다"라는 요지의 cipher spec 변경 메시지를 보냅니다. 이는 Alice가 결국은 프리마스터 비밀에 대한 함수인 일괄 데이터 암호화 및 MAC 생성/확인을 위한 키와 첫 번째 두 메시지에서 클라이언트와 서버가 개별적으로 만든 두 임의의 숫자를 계산해야 한다는 것을 뜻합니다.
마지막으로 Alice는 레코드 계층이 암호화한 마침 메시지 스트림을 보냅니다. 이 메시지에는 Alice가 핸드셰이크 도중 지금까지 레코드 계층과 주고 받은 모든 데이터의 MAC가 들어 있습니다.
Alice의 트랜스미션을 받으면 Bob은 인증서를 요청한 경우 Alice의 인증서를 확인하고 자신의 개인 키를 이용해 해독하여 프리마스터 비밀을 알아 내며 Alice가 전송한 인증서를 사용하여 지금까지 받은 핸드셰이크 메시지에 있는 Alice의 서명을 확인합니다. 그런 과정을 거친 다음에는 통신의 상대편에 있는 사람이 진짜 Alice라는 것을 신뢰하게 됩니다.
Bob은 이제 Alice의 cipher spec 변경 메시지를 받아 일괄 데이터 암호화 키와 MAC 생성/확인 키를 계산하고 이 새 cipher suite를 사용해 들어 오는 전송을 해독하도록 자신의 레코드 계층에 지시합니다. 이렇게 하면 Bob은 Alice가 마지막으로 전송한 마침 메시지를 읽을 수 있습니다. MAC이 지금까지 교환한 핸드셰이크 메시지 전체를 보호하므로 마침 메시지에서 MAC를 확인하면 Bob은 핸드셰이크와 cipher suite 협상이 모두 손상되지 않았음을 신뢰할 수 있게 됩니다.
마지막으로, Bob은 이 새 cipher suite를 사용하여 나가는 메시지를 암호화하도록 레코드 계층을 지정하여 cipher spec 변경 메시지를 다시 Alice에게 보냅니다. 이 메시지 다음에는 마침 메시지가 뒤따르며 여기에도 지금까지 교환한 모든 메시지의 MAC가 포함됩니다.
cipher spec 변경 메시지를 받으면 Alice는 협상된 cipher suite를 사용하여 들어오는 메시지를 해독하도록 자신의 레코드 계층을 지정하고 Bob이 보낸 마침 메시지를 읽습니다. 이 메시지가 성공적으로 해독되고 Bob이 보낸 MAC를 확인할 수 있으면 Alice는 Bob의 신분을 신뢰하게 됩니다. Bob만이 Alice가 보낸 프리마스터 비밀을 해독할 수 있으며 그러기 위해서는 Bob이 MAC를 만들 수 있어야 하기 때문입니다.
이제 Alice와 Bob은 cipher suite를 협상하고 일괄 데이터 암호화와 메시지 인증을 위한 공유 키를 교환했으며 Alice는 자신의 상대방이 Bob이라는 것을 알게 되었습니다. 그리고 Bob 또한 Alice의 인증서를 요청했다면 Alice의 신분을 알 것입니다.

인증서 해지

인증서 사용에 있어서 가장 큰 위험 중 하나는 인증서의 서명이 확인이 되었고 아직 만료되지 않았다는 사실 만으로 그 인증서가 유효하다고 생각하는 경향이 많다는 점입니다. 암호 기반 인증 시스템에서는 Bob의 암호가 손상되면 Bob은 간단히 자신의 암호를 변경할 수 있습니다. NTLM에서는 인증 기관이 모든 네트워크 인증 교환에 관계하므로 인증 기관은 즉시 모든 새 인증 요청(도메인 컨트롤러 간 복제 대기시간 제외)에 이러한 변경 사항을 실행합니다. 하지만 Kerberos의 경우에는 이러한 변경 사항은 일반적으로 (Bob의 TGT가 만료된 후) 10시간 내에 실행됩니다. 그렇다면, Bob의 개인 키가 손상될 경우 인증서 기반 시스템에서는 어떤 일이 발생할까요? Bob은 자신의 인증 기관에 이를 통지하고 새 인증서를 받으며 그 인증 기관은 구 인증서를 파기하게 됩니다.
하지만, Bob이 실행한다고 생각하고 있지만 사실은 Fred가 Bob의 구 개인 키를 불법 복제하여 훔친 서버에 연결한 Alice에게는 이러한 사실이 무엇을 의미할까요? Fred는 약 1년간은 만료되지 않을 Bob의 구 인증서를 손쉽게 Alice에게 보낼 수 있습니다. 그리고 그는 관련 개인 키를 가지고 있으므로 인증서에 대한 소유권을 증명할 수 있습니다. Alice가 해지를 확인하지 않는다면 자신이 대화를 나누는 상대가 Fred라는 사실을 절대 모를 것입니다. 따라서, 공개 키 암호화는 모든 문제를 해결할 수 있는 솔루션이 아니라는 점을 다시 한번 알 수 있습니다. Alice는 인증 기관을 확인해 보아야만 Bob의 인증서가 취소되지 않았는지 확인할 수 있으며, Bob의 인증 기관은 Alice가 매일이나 한 주에 한번 간격으로 받아볼 수 있도록 인증서 해지 목록(CRL)을 발행하여 이 목록 사본으로 Bob의 인증서를 확인할 수 있도록 합니다. 예를 들면, Internet Explorer 5.0은 브라우저가 CRL을 다운로드하여(또는 갓 캐시된 CRL을 검색하여) 서버 쪽 인증서가 취소되지 않았음을 확인하도록 하는 "Check for server certificate revocation"이라는 보안 설정이 있습니다. 인증서에 만료 날짜가 있는 이유는 CRL이 너무 길어지지 않도록 하기 위한 것입니다.

인증서 발급 및 설치

지금까지 SSL 인증이 어떻게 이루어지는지를 설명했으므로 IIS에서 이 인증을 사용하는 것은 주로 관리 작업이라는 것을 알 수 있을 것입니다. SSL이 효과적이라는 것을 생각할 때 최소한 어느 한쪽은 인증을 할 수 있도록 서버가 반드시 인증서를 가지고 있어야 합니다. IIS에서 웹 사이트의 등록 정보를 보면 [웹 사이트] 탭에서, 기본적으로 SSL 포트 항목을 사용하지 않도록 설정되어 있는 것을 볼 수 있습니다( 그림 8 참조). IIS는 서버쪽 인증서가 없으면 SSL을 지원하지 않습니다.

그림 8 SSL 포트 사용 안함

인정된 회사에 대한 웹 서버 인증서를 발급 받아 설치하는 방법은 매우 쉽습니다. 이 예에서는 IIS 5.0을 사용해 설명하겠습니다. IIS는 이 작업을 쉽게 할 수 있도록 마법사를 제공합니다. IIS를 사용하면 하나의 컴퓨터에서 여러 개의 웹 사이트를 사용할 수 있으며 각각의 웹 사이트에 대한 인증서를 가질 수 있습니다(아닐 수도 있습니다). 중요한 점은 웹 사이트 각각에 대해 개별적으로 인증서를 설정해야 한다는 것입니다. 인증서를 받고자 하는 웹 사이트를 선택하고 그 등록 정보 시트를 불러와서 [디렉터리 보안] 탭을 선택합니다. 그리고 [서버 인증서] 단추를 눌러 마법사를 불러옵니다.
이 마법사를 사용하여 인증 요청서를 만들고 새 인증서를 설치하며 기존의 인증서를 제거하는 등의 작업을 할 수 있습니다. 개별 작업마다 간단한 몇 가지 질문에 대답을 해야 합니다. 회사 자체의 인증 기관을 사용하여 인증서를 직접 발행하려는 것이 아니라면 인증서를 발급받아 설치하는 작업은 네 단계로 이루어 집니다. (Windows 2000 도메인 컨트롤러에 인증서 서비스를 설치할 경우에는 여기에 Active Directory™을 통합하여 "엔터프라이즈" 인증 기관으로 만들 수 있습니다.) 첫 번째 단계는 요청서를 만드는 작업입니다. 먼저 인증서의 키 강도(1024비트 이상을 사용하는 것이 좋습니다)를 선택하고 인증서에 표시될 아래 항목에 대해 문자열을 입력합니다.
이름 이 인증서를 사용자가 앞으로 받을 지도 모르는 다른 인증서와 구분해 주는 친숙한 이름입니다. 이 이름은 인증에서는 중요하지 않지만 인증서의 기타 등록 정보로 포함됩니다.
조직 이름 회사 이름을 말합니다.
조직 단위 일반적으로 부서 이름을 말합니다.
일반 이름 웹 서버 액세스에 URL을 인증할 때 사용되는 이름이므로 클라이언트가 사용할 것으로 예상하는 DNS 이름과 일치하는 것이 좋습니다. 예를 들면, DevelopMentor 웹 사이트의 일반 이름은 www.develop.com 입니다.
국가/지역 설명할 필요가 없겠죠.
시/도 약어를 사용해서는 안됩니다. 즉, TX 대신 Texas라고 표시해야 합니다.
구/군/시 설명할 필요가 없군요.
위 항목을 모두 입력하면 요청서를 보낼 텍스트 파일 이름을 선택하라고 표시됩니다. 이 파일이 만들어질 때까지 마법사는 CryptoAPI를 호출해 인증서에 대한 공개/개인 키 쌍을 만들고 개인 키를 로컬 컴퓨터에 저장합니다. 공개 키는 사용자가 입력한 다른 정보와 함께 텍스트 요청 파일에 포함되며, 이 파일을 인증 기관(예: VeriSign)에 전송할 수 있습니다. 이렇게 만들어진 파일에는그림 9 처럼 요청서에 있는 모든 정보의 64 기수로 인코드된 ASCII 렌더링이 들어 있습니다.
두 번째 단계는 이 요청서를 인증 기관에 보내는 단계입니다. 일반적으로 연락처 정보, 도메인 소유 증명, 명시한 조직 이름을 내세워 사업을 할 수 있는 권리에 대한 증명과 함께 인증 기관의 웹 기반 인증서 응용 프로그램 양식에 요청서를 붙이면 됩니다. 제 3 인증 기관이 이 서비스 수수료를 청구하며, 수수료는 서비스 및 보안 수준에 따라 다릅니다. 본 자료 작성 현재, 올해에 만료되는 인증서 수수료는 약 100~1,000달러입니다.
세 번째 단계는 인증 기관이 요청을 받아 들일지 거부할 지를 결정하는 단계입니다. 인증 기관이 제출자의 신분을 확인할 수 있다면(예를 들면, 주소를 확인하고 전화를 걸어 보는 등의 방법을 통해) 일반적으로 영업일 며칠 내에 인증 요청이 수락되었으며 파일 형식으로 된 인증서를 다운로드할 수 있다는 전자 메일을 받게 됩니다. 그 내용은 인증 요청서와 아주 비슷합니다.
마지막으로 네 번째 단계는 다운로드한 인증서를 설치하는 단계입니다. 인증서 마법사를 다시 실행하면 이 응답 과정을 간단히 처리할 수 있습니다. 인증 기관에서 다운로드한 파일 경로를 지정하고 마법사를 실행하면 됩니다.
이 요청/응답 단계에서 개인 키는 요청서를 만든 컴퓨터에 그대로 있습니다. 따라서 인증서를 설치하기 전에 마법사를 사용해 진행 중인 요청을 삭제하면 이 개인 키가 지워지므로 모든 과정을 다시 시작해야 합니다. 공개 키 서명을 위해 제 3 인증 기관에 이미 돈을 지불했다면 정말 곤란해질 수 있으므로 주의해야 합니다.
일단 인증서를 설치하고 나면 웹 서버가 충돌하여 개인 키를 복구할 수 없게 될지도 모르는 사태에 대비하여 그 인증서를 대응하는 개인 키와 함께 파일로 내보내기한 다음 그 파일을 플로피 디스크에 저장하여 오프라인 저장소에 저장할 수 있습니다. 이렇게 하려면 웹 페이지에 대한 등록 정보 페이지를 불러와 [디렉터리 보안] 탭으로 간 다음 [인증서 보기] 단추를 누릅니다. 그리고 대화 상자가 표시되면 [자세히] 탭으로 가서 [파일에 복사]를 선택합니다. 개인 키 내보내기를 선택하면 그 파일 암호화에 사용할 암호를 묻습니다. 정말 보안이 걱정된다면 별도의 저장소에 그 암호를 저장할 수 있지만 솔직히 말하면 웹 서버를 침입하여 그곳에서 개인 키를 훔쳐가는 사람을 더 걱정해야 할 것입니다. 불행히도 웹 서버의 경우에는 개인 키를 오프라인으로 유지하는 것이 그리 큰 의미가 없습니다. 새 HTTPS 세션을 만들 때마다 개인키가 필요하기 때문입니다.
인증서를 설치하고 나면 웹 사이트의 등록 정보 시트에 있는 [웹 사이트] 탭의 [SSL 포트] 필드가 이제 사용되며 HTTPS의 표준 포트 번호가 443으로 설정되었음을 알 수 있습니다. 이제 이 https 체계를 이용해 브라우저에서 자신의 웹 사이트를 액세스할 수 있습니다.

IIS 메타베이스를 통한 HTTPS 요청

IIIS에 서버 인증서를 설치하고 나면 HTTP나 HTTPS를 통해 모든 가상 디렉터리를 액세스할 수 있습니다. 특정한 리소스때문에 HTTPS가 필요한 경우에는 메타베이스를 사용할 수 있습니다. 메타베이스에 대해 간단히 설명하자면, 메타베이스는 웹 사이트 배치를 흉내낸 계층적인 데이터 구조입니다. 메타베이스 트리는 IIS MMC 스냅인을 사용하는 웹 사이트를 관리할 때 보게 되는 것으로, Windows 2000에서 사용되는 DACL 상속 체계와 다소 유사한 특성 상속 체계를 사용합니다. 한 노드의 특성을 변경하면 그 특성에 대한 자체적인 정의를 가지고 있는 하위 개체를 제외한 모든 하위 개체에 변경 사항이 확산됩니다.
HTTPS 필요성 여부를 제어하는 특성은 AccessSSL입니다. 다음은 기본 웹 사이트에 있는 보안이라는 이름의 가상 디렉터리에 이 특성을 적용하는 스크립트입니다.

set vd = getObject("IIS://localhost/W3SVC/1/Root/secure") vd.accessSSL = true vd.setInfo

메타베이스에서 하위 노드가 이미 특성을 정의했다면 상속 흐름은 그 노드에서 중단됩니다. 개체에서 그 특성을 제거하여 해당 특성에 대한 상속 흐름 차단을 해제하려면 PutEx 메서드를 사용해야 합니다:

set vd = getObject("IIS://localhost/W3SVC/1/Root/secure") vd.putEx 1, "AccessSSL", "" vd.setInfo

가상 디렉터리에서 AccessSSL을 사용할 경우 자체 정의를 규정한 하위 노드가 없다면 하위 노드는 자동으로 새 설정을 상속하고 그 디렉터리 하위의 모든 리소스는 클라이언트에게 HTTPS를 사용하도록 요청합니다. 클라이언트가 vanilla HTTP를 통해 이 리소스를 액세스하려고 하면 HTTPS로 전환하라는 오류 메시지를 받게 됩니다. 대부분의 메타베이스 설정과 마찬가지로 필요한 경우 개별 파일 단위로 이러한 설정을 제어할 수 있습니다. 사용자 인터페이스를 통해 이 등록 정보를 액세스하려면 해당 리소스에 대한 등록 정보 시트를 불러와 웹 사이트나 가상 디렉터리 개체에 대한 [디렉터리 보안]이나 개별 파일에 대한 [파일 보안]을 선택한 다음 [보안 통신] 섹션에서 [편집] 단추를 누르면 됩니다.그림 10 에 설명된 메타베이스 키는 대부분 매우 분명한 사용자 인터페이스 표시를 가지고 있지만 일부는 사용자 인터페이스를 통해 절대 액세스할 수 없습니다.

결론

이 기사에서는 SSL 실행 방법을 검토하고 서버측 인증서를 얻어서 설치하는 방법을 설명하였으며 IIS 메타베이스의 보안 설정을 간단히 알아보았습니다.
다음 기사에서는 보안의 관점에서 ISAPI 응용 프로그램 독립 프로세스를 이동하는 것이 왜 중요한지를 설명하고 이러한 이동을 가능하게 하는 Web Application Manager를 소개합니다. 그리고 모든 형태의 클라이언트 인증을 다루고, 주어진 상황에 따라 어떤 형태를 선택할지를 결정하는 데 도움이 되는 팁을 제공합니다. 외에도, IIS를 기존의 3계층 COM+ 응용 프로그램으로 들어가는 게이트웨이로 사용하는 몇 가지 옵션에 대해 설명할 것입니다.

Keith Brown 씨는 DevelopMentor에서 COM 및 Windows NT 보안 커리큘럼을 개발하고 있습니다.Effective COM (Addison Wesley, 1999)의 공동 저자이며 분산 보안에 대한 개발자 가이드를 집필 중입니다. 연락처는 http://www.develop.com/kbrown입니다. http://www.develop.com/kbrown .