내용 목차
WebtoB는 기본적으로 인증(Authentication)과 SSL(Secure Socket Layer)을 지원한다. 이는 기존의 다른 웹 서버들에서도 기본적으로 지원하는 것으로 웹에서 보안를 보장하기 위해 가장 많이 사용되는 방법들이다. 근본적으로 개방형 통신망을 지향하는 인터넷에서 사용자들의 정보를 보호하고, 자료의 유출을 막기 위해 전자 상거래 등의 거대한 규모의 사이트에서 반드시 검증하고 이용해야 할 방법들이다.
인증(Authentication)의 방법은 매우 단순하다. 사용자가 사용자명과 비밀번호를 웹 서버에 보내고 웹 서버는 사용자가 접근 권한을 가지고 있는지 확인하기 위하여 이름과 암호화된 비밀번호가 있는 파일을 열고 해당 정보들을 검색한다. 그리고 검색된 정보에서 사용자명과 비밀번호의 일치를 확인하고 문제가 없으면 사용자에게 정당한 권리를 부여하는 방식이다.
이는 개인별로 나누어서 접근 권한의 설정도 가능하고 몇몇 사람들을 그룹으로 묶어서 접속 권한을 주거나 거부하도록 설정하는 것도 가능하다. 전체 모든 사용자들에 대한 설정도 가능하다. 실제 브라우저와 서버 간의 작동은 다음과 같다.
사용자가 어떤 서버에 접속해서 어떤 자료를 요청한다고 하는 경우 사용자가 요청한 자료가 중요한 자료이기 때문에 특정 사용자들만 보거나 실행할 수 있는 권한이 있다면, 서버는 사용자에게 "Authentication Required [HTTP 401]" 신호를 전달한다. 그러면 사용자는 웹 서버에 자신의 사용자명과 비밀번호를 같이 보내고 웹 서버는 이를 가지고 사용자 인증을 수행한다. 이때, 사용자의 사용자명과 비밀번호가 인터넷으로 전달되는데 정보가 유출되면 문제가 될 수 있기 때문에 사용자의 사용자명과 비밀번호를 암호화한다.
WebtoB에서는 전자 상거래 사이트를 위해서 안전한 보안 방식인 SSL(Secure Socket Layer)을 제공한다. WebtoB에서 구현된 SSL을 사용하는 방법을 설명하기 전에 먼저 SSL에 대해서 설명한다. SSL은 웹 서버가 제공하는 것이기 때문에 SSL에 대한 내용만 이해한다면 사용하는 방법은 아주 간단하다.
Netscape사에서 개발한 암호화 전송 프로토콜 (RC2, RC4로 암호화) X.509 Certificate를 이용하여 서버와 클라이언트간의 인증을 한다. 40bit Key를 사용하는 SSL은 보안에 있어서 신뢰를 주지 못하고, 128bit Key의 SSL을 사용하여야 하며 현재 SSL 버전은 3.0이다.
SSL은 Layer를 기반으로 하는 프로토콜이다. 각 Layer의 메시지는 length, description, content field를 포함한다. SSL이 전송해야 할 메시지를 가질 때 SSL은 그것을 제어 가능한 크기의 Block으로 나누고, 선택적으로 데이터를 압축한다. 압축한 데이터에 인증 코드(MAC : Message Authentication Code)을 추가하고 암호화를 한 후 결과를 전송한다. 데이터가 도착하게 되면 복호화를 하고 MAC을 인증한 후 압축된 데이터를 원래 상태로 만들고, Block을 재배열하여 얻어진 메시지를 상위 레벨로 넘겨주게 된다.
SSL을 지원하는 웹 서버에 연결을 할 경우 흔히 사용하는 URL 표기 방식인 "http://*" 대신에 "https://*"를 사용해야 한다. 보통의 경우(http)에 포트 번호 80을 사용하는데 SSL을 사용할 경우(https)에는 포트 번호 443을 호출하므로 하나의 브라우저를 이용하여 "http://*"와 "https://*"를 동시에 사용할 수가 있다.
SSL이 동작하기 위해서 필요한 사전 작업들이 "handshake" 과정에서 수행된다.
이 작업들을 정리하면 다음과 같다.
클라이언트와 서버가 서로 자신의 인증서(Certificate)를 교환한다. 그리고 각각은 자신이 받은 인증서에 기록되어 있는 유효기간, 서명을 확인한다.
클라이언트는 이후에 수행될 암호화와 메시지 인증 코드(MAC)의 생성에 필요한 난수(비밀 Key)를 생성하여 이것을 서버의 공개 Key로 암호화하여 서버에게 전송한다.
서비스를 받는 동안 사용할 암호화 알고리즘과 hash 함수의 종류를 결정한다. 이 과정에서는 클라이언트는 자신이 받아 들일 수 있는 암호화 알고리즘의 리스트를 서버에게 제시하고 이들 중에서 하나를 서버가 선택한다.
SHTTP는 EIT(Enterprise Integration Technology)에서 개발한 프로토콜로서 기존의 HTTP 프로토콜에 보안기능을 갖게 하기 위하여 몇 가지의 헤더를 추가한 것이다. SSL은 서비스를 단위로 암호화와 인증을 받지만 SHTTP의 경우에는 전달되는 메시지를 단위로 암호화와 인증을 받는다.
SSL과 비슷한 점이 있다면 클라이언트가 서버에게 SHTTP를 이용한 커넥션을 만드는 과정에서 다양한 종류의 암호화 기법들 중에서 하나를 선택할 수 있고 암호화의 정도를 선택할 수 있다는 점이다.
SHTTP가 지원하는 암호화 기법의 특징 및 알고리즘을 정리하면 다음과 같다.
RSA, Diffie-Hellman 또는 Kerberos 인증기법을 사용한다.
공개 Key 인증서(certificate) 양식은 X.509 또는 PKCS-6를 사용한다.
디지털 서명 알고리즘은 RSA 또는 DSA(Digital Signature Algorithm)를 사용한다.
암호화를 40bit, 128bit 중 정하는 것은 주어진 데이터를 인코딩하는 데 필요한 Key의 길이이고, Key의 길이는 길수록 훨씬 안전하다. 보통 SSL 등을 지원하는 타 웹 서버들은 자체적으로 128bit를 지원하나, 이러한 128bit Encryption을 지원하기 위해서는 서버뿐만 아니라 클라이언트 역시 이를 지원해야 한다.
Ciphers는 암호화에 사용되는 알고리즘으로 더욱 더 안전하고 강력한 것들을 선택할 수 있다. 일반적으로 Ciphers가 암호화할 때 더 많은 bit를 사용할수록 그 데이터를 해독하기가 더 어렵고 어떠한 양방향 암호화 과정에서도 양자는 같은 Cipher를 사용해야 한다. 이러한 Cipher에는 여러 가지 종류가 있어서 서버는 가장 많이 알려진 것을 사용할 수 있어야 하고, 클라이언트가 서버와의 SSL 접속을 시작하면 정보를 암호화하는 데 선호하는 Cipher를 서버에 알리게 된다.
현재 WBSSL에서 제공되는 Ciphers 종류는 다음과 같다.
Cipher suite Protocols KeyExch. Authen. Encryption Mac TLS_AES_256_GCM_SHA384 TLSv1.3 any any AESGCM(256) AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 any any CHACHA20/POLY1305(256) AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 any any AESGCM(128) AEAD ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH RSA AESGCM(256) AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 ECDH ECDSA AESGCM(256) AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH RSA AES(256) SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 ECDH ECDSA AES(256) SHA384 ECDHE-RSA-AES256-SHA SSLv3 ECDH RSA AES(256) SHA1 ECDHE-ECDSA-AES256-SHA SSLv3 ECDH ECDSA AES(256) SHA1 SRP-DSS-AES-256-CBC-SHA SSLv3 SRP DSS AES(256) SHA1 SRP-RSA-AES-256-CBC-SHA SSLv3 SRP RSA AES(256) SHA1 SRP-AES-256-CBC-SHA SSLv3 SRP SRP AES(256) SHA1 DH-DSS-AES256-GCM-SHA384 TLSv1.2 DH/DSS DH AESGCM(256) AEAD DHE-DSS-AES256-GCM-SHA384 TLSv1.2 DH DSS AESGCM(256) AEAD DH-RSA-AES256-GCM-SHA384 TLSv1.2 DH/RSA DH AESGCM(256) AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH RSA AESGCM(256) AEAD DHE-RSA-AES256-SHA256 TLSv1.2 DH RSA AES(256) SHA256 DHE-DSS-AES256-SHA256 TLSv1.2 DH DSS AES(256) SHA256 DH-RSA-AES256-SHA256 TLSv1.2 DH/RSA DH AES(256) SHA256 DH-DSS-AES256-SHA256 TLSv1.2 DH/DSS DH AES(256) SHA256 DHE-RSA-AES256-SHA SSLv3 DH RSA AES(256) SHA1 DHE-DSS-AES256-SHA SSLv3 DH DSS AES(256) SHA1 DH-RSA-AES256-SHA SSLv3 DH/RSA DH AES(256) SHA1 DH-DSS-AES256-SHA SSLv3 DH/DSS DH AES(256) SHA1 DHE-RSA-CAMELLIA256-SHA SSLv3 DH RSA Camellia(256) SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 DH DSS Camellia(256) SHA1 DH-RSA-CAMELLIA256-SHA SSLv3 DH/RSA DH Camellia(256) SHA1 DH-DSS-CAMELLIA256-SHA SSLv3 DH/DSS DH Camellia(256) SHA1 GOST2001-GOST89-GOST89 SSLv3 GOST GOST01 GOST89(256) GOST89 GOST94-GOST89-GOST89 SSLv3 GOST GOST94 GOST89(256) GOST89 ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH/RSA ECDH AESGCM(256) AEAD ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 ECDH/ECDSA ECDH AESGCM(256) AEAD ECDH-RSA-AES256-SHA384 TLSv1.2 ECDH/RSA ECDH AES(256) SHA384 ECDH-ECDSA-AES256-SHA384 TLSv1.2 ECDH/ECDSA ECDH AES(256) SHA384 ECDH-RSA-AES256-SHA SSLv3 ECDH/RSA ECDH AES(256) SHA1 ECDH-ECDSA-AES256-SHA SSLv3 ECDH/ECDSA ECDH AES(256) SHA1 AES256-GCM-SHA384 TLSv1.2 RSA RSA AESGCM(256) AEAD AES256-SHA256 TLSv1.2 RSA RSA AES(256) SHA256 AES256-SHA SSLv3 RSA RSA AES(256) SHA1 CAMELLIA256-SHA SSLv3 RSA RSA Camellia(256) SHA1 PSK-AES256-CBC-SHA SSLv3 PSK PSK AES(256) SHA1 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH RSA AESGCM(128) AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 ECDH ECDSA AESGCM(128) AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH RSA AES(128) SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 ECDH ECDSA AES(128) SHA256 ECDHE-RSA-AES128-SHA SSLv3 ECDH RSA AES(128) SHA1 ECDHE-ECDSA-AES128-SHA SSLv3 ECDH ECDSA AES(128) SHA1 SRP-DSS-AES-128-CBC-SHA SSLv3 SRP DSS AES(128) SHA1 SRP-RSA-AES-128-CBC-SHA SSLv3 SRP RSA AES(128) SHA1 SRP-AES-128-CBC-SHA SSLv3 SRP SRP AES(128) SHA1 DH-DSS-AES128-GCM-SHA256 TLSv1.2 DH/DSS DH AESGCM(128) AEAD DHE-DSS-AES128-GCM-SHA256 TLSv1.2 DH DSS AESGCM(128) AEAD DH-RSA-AES128-GCM-SHA256 TLSv1.2 DH/RSA DH AESGCM(128) AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH RSA AESGCM(128) AEAD DHE-RSA-AES128-SHA256 TLSv1.2 DH RSA AES(128) SHA256 DHE-DSS-AES128-SHA256 TLSv1.2 DH DSS AES(128) SHA256 DH-RSA-AES128-SHA256 TLSv1.2 DH/RSA DH AES(128) SHA256 DH-DSS-AES128-SHA256 TLSv1.2 DH/DSS DH AES(128) SHA256 DHE-RSA-AES128-SHA SSLv3 DH RSA AES(128) SHA1 DHE-DSS-AES128-SHA SSLv3 DH DSS AES(128) SHA1 DH-RSA-AES128-SHA SSLv3 DH/RSA DH AES(128) SHA1 DH-DSS-AES128-SHA SSLv3 DH/DSS DH AES(128) SHA1 DHE-RSA-SEED-SHA SSLv3 DH RSA SEED(128) SHA1 DHE-DSS-SEED-SHA SSLv3 DH DSS SEED(128) SHA1 DH-RSA-SEED-SHA SSLv3 DH/RSA DH SEED(128) SHA1 DH-DSS-SEED-SHA SSLv3 DH/DSS DH SEED(128) SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 DH RSA Camellia(128) SHA1 DHE-DSS-CAMELLIA128-SHA SSLv3 DH DSS Camellia(128) SHA1 DH-RSA-CAMELLIA128-SHA SSLv3 DH/RSA DH Camellia(128) SHA1 DH-DSS-CAMELLIA128-SHA SSLv3 DH/DSS DH Camellia(128) SHA1 ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH/RSA ECDH AESGCM(128) AEAD ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 ECDH/ECDSA ECDH AESGCM(128) AEAD ECDH-RSA-AES128-SHA256 TLSv1.2 ECDH/RSA ECDH AES(128) SHA256 ECDH-ECDSA-AES128-SHA256 TLSv1.2 ECDH/ECDSA ECDH AES(128) SHA256 ECDH-RSA-AES128-SHA SSLv3 ECDH/RSA ECDH AES(128) SHA1 ECDH-ECDSA-AES128-SHA SSLv3 ECDH/ECDSA ECDH AES(128) SHA1 AES128-GCM-SHA256 TLSv1.2 RSA RSA AESGCM(128) AEAD AES128-SHA256 TLSv1.2 RSA RSA AES(128) SHA256 AES128-SHA SSLv3 RSA RSA AES(128) SHA1 SEED-SHA SSLv3 RSA RSA SEED(128) SHA1 CAMELLIA128-SHA SSLv3 RSA RSA Camellia(128) SHA1 IDEA-CBC-SHA SSLv3 RSA RSA IDEA(128) SHA1 PSK-AES128-CBC-SHA SSLv3 PSK PSK AES(128) SHA1 ECDHE-RSA-RC4-SHA SSLv3 ECDH RSA RC4(128) SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 ECDH ECDSA RC4(128) SHA1 ECDH-RSA-RC4-SHA SSLv3 ECDH/RSA ECDH RC4(128) SHA1 ECDH-ECDSA-RC4-SHA SSLv3 ECDH/ECDSA ECDH RC4(128) SHA1 RC4-SHA SSLv3 RSA RSA RC4(128) SHA1 RC4-MD5 SSLv3 RSA RSA RC4(128) MD5 PSK-RC4-SHA SSLv3 PSK PSK RC4(128) SHA1 ECDHE-RSA-DES-CBC3-SHA SSLv3 ECDH RSA 3DES(168) SHA1 ECDHE-ECDSA-DES-CBC3-SHA SSLv3 ECDH ECDSA 3DES(168) SHA1 SRP-DSS-3DES-EDE-CBC-SHA SSLv3 SRP DSS 3DES(168) SHA1 SRP-RSA-3DES-EDE-CBC-SHA SSLv3 SRP RSA 3DES(168) SHA1 SRP-3DES-EDE-CBC-SHA SSLv3 SRP SRP 3DES(168) SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 DH RSA 3DES(168) SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 DH DSS 3DES(168) SHA1 DH-RSA-DES-CBC3-SHA SSLv3 DH/RSA DH 3DES(168) SHA1 DH-DSS-DES-CBC3-SHA SSLv3 DH/DSS DH 3DES(168) SHA1 ECDH-RSA-DES-CBC3-SHA SSLv3 ECDH/RSA ECDH 3DES(168) SHA1 ECDH-ECDSA-DES-CBC3-SHA SSLv3 ECDH/ECDSA ECDH 3DES(168) SHA1 DES-CBC3-SHA SSLv3 RSA RSA 3DES(168) SHA1 PSK-3DES-EDE-CBC-SHA SSLv3 PSK PSK 3DES(168) SHA1
인터넷과 같은 개방형 통신망에서 일어날 수 있는 사용자 데이터의 보안 및 사용자 신원인증을 위한 방법으로는 공개 Key 암호화 알고리즘이 있다. 이 알고리즘은 데이터를 암호화하는 Key와 암호화된 문을 해독하는 Key가 쌍으로 구성된다.
비밀 Key는 해독할 사람 본인이 가지고 있고, 공개 Key는 공개하여 다른 사람들이 비밀 Key의 소유자에게 메시지를 전할 때 그 공개 Key로 암호화해서 보내는 방식이다. 이 방법에서 문제가 되는 것은 그 공개 Key가 정말로 사용자 본인의 것인가 아닌가 하는 점인데, 이를 확인하기 위해 공개 Key를 증명해주는 기관을 별도로 두게 되며, 이를 인증기관(Certification Authority, CA)이라고 한다.
메시지 송신자와 수신자가 모두 신뢰할 수 있는 제3의 인증기관을 바탕으로 그 인증기관에서 발행하는 사용자 인증서를 상호 교환 및 확인을 통하여 원격지 상대방의 신원인증 및 송수신되는 데이터의 보안을 하게 된다. 인증기관에서 발행하는 인증서에는 인증기관 인증서(CA Root 인증서), 웹 서버 인증서, 사용자 인증서의 3종류로 구분한다.
인증서(Certificate)란 어떤 소프트웨어나 어떤 기관 또는 개인을 보증하는 Q마크와 같은 것이다. 잘 모르는 신제품에 대하여 고객은 KS나 Q마크를 믿고 그 제품을 구입하게 되는데 인터넷에서도 이와 같은 개념으로 도입된 것이 인증서이다. 반대로 상점의 입장에서 보면 물건을 사러 온 고객이 믿어도 좋은 사람인지 고객의 신분증을 보고 신용카드 거래를 허용할 수도 있다.
인증서는 사용하는 입장에서 보면 '서버 인증서'와 '클라이언트 인증서' 2가지로 나누어 볼 수 있고 트리(Tree) 구조를 따라서 보다 상위 기관에서 그 신뢰도를 인증하는 계층구조로 이루어져 있는 것이 보통이다. 사용자 데이터 보호와 사용자 신원의 추가 확인용으로만 사용될 뿐 전자 서명용으로 사용할 때는 전자서명법에 의한 법적효력을 갖지 않는 것이 일반적이다.
온라인 인증서는 인증하고자 하는 대상에 관한 몇 가지 내용을 기술한 문서라고 볼 수 있는데 개인적으로 생성할 수도 있고 발급기관에 요청할 수 있으며 그 형식은 ITU(International Telecommunication Union)에서 제정한 X.509의 양식 또는 RSA Data Security사에서 제정한 PKCS-6의 양식 및 PEM을 따르는 인증서를 사용한다. 이러한 인증서는 cert.crt와 같은 형식으로 배포될 수 있으며 이것은 개인 Key를 제외하고 배포되는 공개 Key라고 생각할 수 있다.
다음은 PKCS-6의 예이다.
Certificate: Data: Version: 0 (0x0) Serial Number: 02:41:00:00:01 --------------------------- ① Signature Algorithm: MD2 digest with RSA Encryption ----- ② Issuer: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority ---------------- ③ Validity: Not Before: Wed Nov 9 15:54:17 1994 Not After: Fri Dec 31 15:54:17 1999 --------------------- ④ Subject: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority Subject Public Key Info: Public Key Algorithm: RSA Encryption Public Key: Modulus: 00:92:ce:7a:c1:ae:83:3e:5a:aa:89:83:57:ac:25: 01:76:0c:ad:ae:8e:2c:37:ce:eb:35:78:64:54:03: e5:84:40:51:c9:bf:8f:08:e2:8a:82:08:d2:16:86: 37:55:e9:b1:21:02:ad:76:68:81:9a:05:a2:4b:c9: 4b:25:66:22:56:6c:88:07:8f:f7:81:59:6d:84:07: 65:70:13:71:76:3e:9b:77:4c:e3:50:89:56:98:48: b9:1d:a7:29:1a:13:2e:4a:11:59:9c:1e:15:d5:49: dd:2d:d6:c8:1e:7b Exponent: 65537 (0x10001) Signature Algorithm: MD2 digest with RSA Encryption Signature: 88:d1:d1:79:21:ce:e2:8b:e8:f8:c1:7d:34:53:3f:61:83:d: b6:0b:38:17:b6:e8:be:21:8d:8f:00:b8:8b:53:7e:44:67:1: 22:bd:97:27:e0:9c:85:cc:4a:f6:85:3b:b2:e2:be:92:d3:e: 0d:e9:af:5c:0e:0c:46:95:ff:a1:1c:5e:3e:e8:36:58:7a:7: a6:0a:f8:22:11:6b:c3:09:38:7e:26:bb:73:ef:00:bd:02:a: f3:14:0d:30:3f:61:70:7b:20:fe:32:a3:9f:b3:f4:67:52:d: b4:ee:84:8c:96:36:20:de:81:08:83:71:21:8a:0f:9e:a9
위의 인증서의 각 의미는 다음과 같다.
①은 인증서의 시리얼 번호이다.
②는 인증서에서 RSA 암호화 알고리즘과 MD2(Message Digest 2)라는 메시지 압축 알고리즘을 사용하였음을 나타낸다.
③은 인증서를 발급한 기관에 관한 정보를 나타낸다.
| 구분 | 설명 |
|---|---|
| C | country |
| O | Organization |
| OU | Organization Unit |
④는 인증서의 유효기간이 '1994년 11월 9일 15시 54분17초'에서부터 '1999년 12월 31일 15시 54분 17초'까지라고 표시하고 있다. CA는 인증서를 발급해주는 기관의 서버를 의미한다.
확실한 보안 통신을 위해서는 서버뿐만 아니라 클라이언트에서의 인증서가 필요하다. 클라이언트의 경우에 "정말로 내가 요청한 서비스를 해줄 적법한 서버인가?"를 확인하는 것이 필요할 것이고, 서버의 경우에 "정말로 서비스를 요청한 실체가 적법한 클라이언트인가?"를 확인하는 작업이다. 보통 서버는 의무적으로 인증서를 제공하고, 클라이언트에서 인증서를 요구할 것인가 하는 것은 발급하는 정책에 따라 여러 가지가 있을 수 있다.
인증서 발급 정책(Certificate Issuing Policy)은 일반적으로 다음의 4가지 형태로 존재하게 된다.
인증과정이 필요 없다. (No certificate required.)
클라이언트는 올바른 인증서를 제공할 수도 있다. 인증서가 제공되면, 서버가 가지고 있는 인증서와 일치하는 인증기관(Certification Authority)에서 인증한 것이어야 한다.
클라이언트는 올바른 인증서를 반드시 제공해야 한다.
클라이언트는 올바른 인증서를 제공할 수도 있다. 그러나 반드시 서버의 인증기관과 일치할 필요는 없다.
일반적으로, 영화표 예매나 사이버 증권사와 같은 곳에서는 고객의 ID와 비밀번호만 있으면 서버의 인증서를 바탕으로 보안 통신이 이루어지게 되는 type0 형식을 사용한다. 한국통신에서 진행하는 banktown 21c 프로젝트에서는 보다 확실한 보안을 위한 type1 형식을 사용한다. 서비스를 이용하기 위해서는 웹 사이트에서 [인증서 제출] 버튼을 클릭해서 인증서를 제출하면(일반적으로는 브라우저에서 이것을 제공하게 할 수도 있다) 전자통장이 실행되고, 동시 서버에서 인증서를 발급받아 상호 간의 인증(Mutual Authentication)을 획득하게 되는 것이다. type0과 같이 단순히 비밀번호를 입력하는 방법보다는 인증서를 이용하는 방법이 인증서와 비밀번호를 동시에 이용하기 때문에 더욱 안전하다.
은행의 ATM 단말기를 이용할 때 은행에서 발급한 카드를 넣고 비밀번호를 입력한 후에 현금을 인출한다. 이러한 과정에서 카드가 인증서에 해당한다고 볼 수 있다. ATM 단말기에 넣은 카드로 은행의 서버에 자신의 실체를 알리고, 비밀번호 입력을 통해 적법한 사용자임을 인증하는 것이다. 이것은 디지털 서명에서 사용한 방법과 동일한 것이다.
Verisign은 세계적으로 가장 유명한 사설 인증기관이다. Verisign 홈페이지(www.verisign.com)에서 SSL Server Certificate를 선택하면 인증서를 받을 수 있다. 인증서는 구입하여 영구적으로 권한을 사용할 수도 있고, 일정기간(14일) trial로 사용해 볼 수도 있는데, 실제로 구입하기 위해서는 약간 더 복잡한 과정이 필요하다.
인증서란 어떤 대상을 인증기관에서 신용을 보증하는 것이기 때문에 Verisign사는 인증서를 요청한 기관이나 업체에 사업허가서 등의 제반 서류를 요청하게 되는데, D&B라는 Business Database에 등록되어 있다면 이러한 과정이 훨씬 간단해 질 수 있고, 현재는 주로 미국 내의 기업들만이 등록되어 있다.
이전에 설명외에 SSL은 더 복잡한 구조와 인증 방법을 가지고 있다. 또한, SSL(Secure Socket Layer)은 TCP 프로토콜과 HTTP 프로토콜 레벨 사이에 있는 데이터를 암호화할 수 있는 Layer이기 때문에, SSL의 암호화를 통하여 데이터가 인터넷 등의 개방형 통신망으로 나간다 할지라도 암호를 해독할 가능성이 거의 없어 데이터에 대한 보안성이 생기게 된다. 따라서 이는 보안성이 특히 중요한 전자상거래 등에서 많이 사용되며, 국내에서도 대부분의 전자상거래에서 많은 사용자들이 이용하고 있다.
하지만 이는 TCP 프로토콜과 HTTP 프로토콜 레벨 사이에서 데이터를 암호화해야 하기 때문에 성능상에 문제점을 초래할 수 있다. 특히 SSL을 지원하는 타 웹 서버에서는 SSL Package와 복잡한 연동 문제로 인하여 처리 속도가 느려지는 문제점이 발생하게 된다. 그 이유는 웹 서버가 SSL을 외부의 함수로 이용하여 자신들의 내부 엔진과 결합성이 떨어지기 때문이다. WebtoB에서는 이들을 내부 엔진과 결합하여, 성능에 문제가 될 수 있는 모든 요인들을 제거하고 효율성에 초점을 맞추었다.
실제 SSL의 사용은 매우 단순하다. 현재 사용자들이 많이 이용하는 브라우저가 거의 모두 SSL을 지원하기 때문에 https로 시작하는 사용자 요구들을 스스로 SSL로 간주하여 웹 서버로 보내게 된다. 또한, 웹 서버에서는 이런 요구를 받아 위에서 설명한 인증 방법 등을 동원하여 사용자를 인증하게 된다. 이는 모두 웹 서버와 사용자 브라우저 내에서 이루어지는 일로 사용자가 복잡하게 직접 관여할 필요는 없다.
본 절에서는 인증에 사용되는 명령어와 SSL 사용법에 대해서 설명한다.
WebtoB에서 인증을 설정하는 방법은 환경설정에 AUTHEN 절에서 설명한다. 자세한 내용은 “3.15. AUTHENT 절”의 설명을 참고한다.
인증을 이용하기 위해서는 WebtoB에서의 설정뿐 아니라 실제 사용자의 사용자명과 비밀번호를 만들어서 저장해야 할 필요가 있다. 사용자명과 비밀번호를 생성하기 위해서 wsmkpw 실행 파일을 사용한다. wsmkpw 파일은 WebtoB가 설치된 디렉터리에 있는 "bin/" 디렉터리 아래에 있다.
다음은 wsmkpw의 사용법과 옵션에 대한 설명이다.
$ wsmkpw [-d] [-p passwd] [-r realm] <file_path> <username>
항목
| 항목 | 설명 |
|---|---|
| file_path | 인증 파일이 있는 전체 경로이다. |
| user_name | 인증에 사용될 사용자 이름이다. |
옵션
| 옵션 | 설명 |
|---|---|
| [-d] | Digest로 인증하기 위한 암호를 생성한다. |
| [-p passwd] | 옵션을 통해 암호를 입력한다. 이 옵션을 사용하면 암호를 입력받는 프롬프트 없이 암호를 생성한다. 터미널에 암호가 노출되므로 주의해야 한다. |
| [-r realm] | Digest 인증을 위한 realm을 설정한다. |
다음은 "/data1/gloria/webtob/auth" 아래에 passwd라는 파일이 생기고 newuser라는 새로운 사용자가 저장되고 내부에는 입력한 비밀번호가 암호화되어 저장되는 예제이다. 이 파일을 이용하여 WebtoB는 실제 인증을 수행한다.
wsmkpw /data1/gloria/webtob/auth/passwd newuser New Password: ***** Retype Password: *****
WebtoB의 환경설정 중에 AUTHENT 절에 UserFile 항목에 passwd라는 파일을 등록하면 WebtoB가 인증을 수행하는 과정에서 이 파일을 이용하여 인증 작업을 하게 된다.
wsmkpw 실행 파일을 이용하여 사용자명과 비밀번호를 등록한 후 원하는 항목에 이것을 추가하면 사용자가 그 항목에 대한 요구를 하는 경우마다 WebtoB는 인증 작업을 수행한다.
인증 작업은 간단한 응용으로 사용자의 인증 작업을 수행할 수 있기 때문에 웹의 초기에 많이 이용되었다. 그러나 인증에 사용하는 암호화 방법이 아주 일반적이고도 해독이 가능하기 때문에 전자 상거래를 구현한 사이트 등에서는 많이 외면 되고 있다. 또한 사용자의 비밀번호가 인터넷에 유출되면 나쁜 의도로 비밀번호를 중간에 capture하여 해독하는 사례도 발생하면서 더 강력한 인증과 암호화 방법이 강구되었다.
이러한 문제에 대처하기 위해 Netscape사에 의해서 SSL(Secure Socket Layer)이 등장하였다. 이는 기존 암호화 방법을 한 차원 높게 만든 것으로 비밀번호와 사용자명을 가져갔다 하더라도 암호를 해독하는 것이 아주 어렵고 거의 불가능하기 때문에 보안에 완벽을 기할 수 있는 방법으로 인정받고 있다.
WebtoB에서 인증과 SSL을 이용하기 위해서는 WebtoB의 환경 파일에 이를 이용하기 위한 별도의 설정이 필요하다.
인증 기능을 사용하기 위해서는 AUTHENT 절을 설정해야 한다. AUTHENT 절은 WebtoB에서 보안을 위하여 설정할 인증에 대한 정의를 하는 절이다. 그리고 AUTHENT 절에서 선언한 것을 각각의 서버 그룹에 선언을 한다. 각 서버 그룹 단위로 인증을 설정하는 것이 가능하다. 만약 사용자가 CGI에 대해서 인증을 사용하는 경우 CGI를 선언한 서버 그룹에 AUTHENT 절에서 선언한 인증 이름을 선언한다. 자세한 내용은 “3.15.1. 설정 항목”을 참고한다.
다음은 AUTHENT 절을 설정하는 방법이다.
*AUTHENT
AUTHENT name Type,
UserFile
| 항목 | 설명 |
|---|---|
| AUTHENT name | 사용자가 원하는 이름을 설정한다. |
| Type | 사용자가 이용하고 싶은 Encryption 방법을 설정한다. 일반적으로 이용되는 방법은 Basic과 Digest, MD5, RSA 등이 있다. WebtoB에서는 Basic과 Digest를 지원한다. |
| UserFile | wsmkpw를 이용하여 생성된 password 파일을 설정한다. password 파일을 이 AUTHENT 절에서 이용해야 하기 때문에 그 파일의 위치를 입력해야 한다. password 파일은 사용 전에 생성되어야 한다. |
다음은 AUTHENT 절을 설정한 예제이다.
*AUTHENT
authent1 Type = Basic,
UserFile = "/usr/local/webtob/bin/pwfile"
위와 같은 설정을 하였다면 사용자가 원하는 설정으로 인증 파일을 사용할 기본적인 준비가 된 것이다. 해당 설정을 사용해서 원하는 작업에 이 AUTHENT 절에서 정의한 항목을 실제로 연결하면 된다. 사용자가 이용하는 WebtoB의 설정 항목은 'AUTHENT name' 이다. 이를 이용하여 AUTHENT 절에 선언한 인증 방법을 이용한다. 설정에 대한 자세한 내용은 “3.15. AUTHENT 절”을 참고한다.
간단한 예로 사용자가 CGI 작업에 인증을 설정하고 싶다면 다음과 같이 설정한다(authen1은 위의 예에서 설정되었다).
*SVRGROUP
cgig NodeName = webmain, SvrType = CGI,
AuthentName = authent1
위와 같은 형식으로 설정하면 WebtoB는 사용자가 CGI 서비스를 요청할 때마다 사용자에게 인증 작업을 수행할 것이다. 이때 주의할 것은 이 인증 작업이 서버 그룹 단위로 이루어진다는 점이다.
따라서 CGI 그룹을 설정하면 이에 대응하는 서버들은 모두 인증 작업을 수행할 것이다. 따라서 만약 사용자가 특정 CGI는 인증을 수행하고 또 다른 CGI는 아니라면 2개의 서버 그룹을 설정해야 한다.
이에 대한 예는 다음과 같다.
*SVRGROUP
cgig NodeName = webmain, SvrType = CGI
cgig_authent NodeName = webmain, SvrType = CGI,
AuthentName = authent1
*SERVER
cgi1 SvgName = cgig
cgi2 SvgName = cgig_authent
*URI
uri1 Uri = "/cgi-bin/", SvrType = CGI,
SvrName = cgi1
uri2 Uri = "/cgi/", SvrType = CGI,
SvrName = cgi2
*ALIAS
alias1 Uri = "/cgi-bin/",
Realpath = "${WEBTOBDIR}/cgi-bin/"
alias2 Uri = "/cgi/",
Realpath = "${WEBTOBDIR}/cgi/"
위와 같이 2가지로 그룹을 설정한 후 인증을 원하는 것은 cgig_authent라는 서버 그룹을 이용하여 서버를 설정하고, 다른 것들은 cgig를 그대로 이용하여 설정하면 된다. 이런 설정은 SVRGROUP 절에 선언될 수 있는 모든 것에 적용된다.
WebtoB에서 SSL을 이용하기 위해서는 별도의 설정이 필요하다. 다른 인증이나 LOG 절의 선언과 마찬가지로, SSL 절을 선언하고 이를 이용하는 방식으로 진행된다. 자세한 내용은 “3.17. SSL 절”을 참고한다.
WebtoB에서 SSL을 이용하기 위해서는 먼저 NODE 절이나 SSL을 이용하고 싶은 Virtual Host를 선언한 VHOST 절에서 SslFlag 항목을 설정해야 한다. 기본적으로 WebtoB는 SSL을 사용하도록 되어 있지 않다. SslFlag 항목은 'Y'나 'N'으로 설정하는 것이 가능하다. 'Y'라는 값을 입력하면, SSL을 사용한다는 것이 되고, 'N'은 이와 반대의 역할을 한다. SslFlag 항목에 대한 설정이 없으면, 기본적으로 SSL을 이용하는 것이 아니기 때문에, 'N'은 거의 사용하지 않는다.
다음은 SslFlag 항목의 사용 예이다.
SslFlag = Y
위와 같이 SslFlag를 'Y'로 설정하여 SSL을 사용하겠다고 설정한 후에는 SSL에 대한 설정을 해야 한다.
다음은 SSL 절의 형식이다.
*SSL
SSL NAME Certificatefile, CertificateKeyFile,
CACertificatePath, CACertificateFile,
VerifyDepth, VerifyClient, RandomFile,
...
위 예제는 기본적인 설정에 필요한 정보만 기술한 것이다. 설정한 SSL을 AUTHENT 절에서 하듯이 각각의 SSL을 설정한다. SSL 설정은 SslName 항목을 사용한다. 설정하는 SslName 항목의 내용은 SSL 절에서 설정한 내용과 동일하게 설정한다.
인증관련 내용은 SVRGROUP 절에서 설정하고 SSL 절은 NODE 절이나 VHOST 절에서 SSL을 사용하는 곳에 설정한다.
다음은 SslName 항목 설정에 대한 예제로 ssl1으로 설정된 값으로 SSL을 사용하는 예제이다.
SslName = "ssl1"
ssl1이라는 항목은 SSL 절에서 설정한다. 다음은 SSL 절 설정에 대한 예제이다.
*SSL
ssl1 CertificateFile = "/user/webtob/ssl/newcert.pem",
CertificateKeyFile = "/user/webtob/ssl/newcert.pem",
RandomFile = "/user/webtob/bin/.rnd, 2048",
RandomFilePerConnection = "/user/webtob/bin/.rnd, 512",
VerifyClient = 0,
VerifyDepth = 10,
FakeBasicAuth = Y
다음은 SSL을 실제 적용하는 방법에 대한 예제이다. NODE 절에서 SSL을 이용하기 위해서 SslFlag 항목을 설정하고 SslName 항목을 설정한다.
*NODE
test WebtoBDir = "/user/webtob",
SHMKEY = 69000,
HTH = 1,
Port = "80",
SslFlag = Y,
SslName = "ssl1",
...
SslName = "ssl1" 설정에 의해 이 NODE는 ssl1에서 정의된 항목을 통해서 SSL 서비스를 한다는 것을 알 수 있다.