1. 웹 서비스 보안의 필요성
웹 서비스의 출현은 폐쇄 환경의 분산 컴퓨팅을 개방 환경으로 바꾸어 놓았다. 웹 서비스의 기능을 원하는 회사 또는 개인이 언제든지 공개적으로 이용할 수 있게 된다.
SOAP은 HTTP 80 포트를 사용함으로써 방화벽 너머로도 원격 프로시저 호출 요청을 보낼 수 있다. 물론 이것은 장점인 동시에 단점이 될 수 있다.
이는 일반적으로 웹 서비스 시스템 뒤편에는 폐쇄 환경의 분산 컴퓨팅 기술이 있기 때문이다.
예를 들어, J2EE 플랫폼의 비즈니스 컴포넌트인 EJB가 실행되고 있을 수 있다. EJB가 가지고 있는 비즈니스 메소드를 웹 서비스 시스템의 원격 프로시저가 언제든지 실행할 수 있다면, 문제가 심각해진다.
단순한 정보를 반환하는 원격 프로시저라면 문제가 되지 않겠지만, 중요한 데이터를 다루는 원격 프로시저의 호출이라면 먼저 웹 서비스 클라이언트의 인증을 받아야 한다. 즉 클라이언트의 신원을 확인하고 원하는 정보를 제공해야 한다.
또한 HTTP를 통한 SOAP 메시지로 원격 프로시저를 호출할 때 전송 매체인 HTTP에 대한 암호화가 필요하다. 암호화가 되어 있지 않다면 신용카드와 개인 비밀 정보가 누출될 가능성이 크기 때문이다. 그리고 SOAP 메시지 자체에 대한 암호화도 필요할 것이다.
다음은 SOAP 메시징을 위한 보안 아키텍쳐를 보여준다.
일반적으로 보안에는 여러 가지 카테고리가 있다. 기본적으로 사용자는 인증(authentication)을 받아야 하며, 리소스에 접근하기 위해서는 권한설정(authorization)이 되어야 하고, 컴퓨터 시스템은 리소스를 감사(auditing)하고 로그(logging)를 기록해야 한다. 그리고 저장된 정보는 언제나 무결성이 유지되어야 하며, 아무나 볼 수 없도록 암호화(encryption)되어 있어야 한다. 또한 프라이버시가 지켜져야 하며, 이를 위해 디지털 서명(digital signature) 등이 사용된다.
2. 암호화
암호학(Cryptography)은 데이터의 비밀을 유지하기 위한 학문이다. 암호학의 용어에서는 암호화 되지 않은 데이터를 평문(plaintext/cleartext)이라고 한다. 데이터를 중간에서 가로채는 이들이 알아보지 못하도록 인코딩 하는 것을
암호화(encryption)라고 한다.
이렇게 암호화된 데이터를 암호문(ciphertext)이라고 한다. 암호문을 다시 평문으로 바꾸는 과정을 복호화(decryption)라고 한다.
현대의 모든 암호 알고리즘에서는 암호화와 복호화를 위해 키(key)를 사용한다. 즉, 암호화할 때 사용한 키와 한 쌍인 복호화 키가 있어야만 메시지를 복호화할 수 있다. 이와 같이 키를 기반으로 하는 알고리즘은 크게 두 가지 부류로 나뉜다.
(1) 대칭 알고리즘
대칭 알고리즘은 암호화와 복호화에 동일한 키를 사용하는 방식을 말한다.
작은 네트워크 환경에서 서로 가까이 있는 이들끼리만 비밀 암호화 키를 교환하면 되기 때문에 대칭 알고리즘을 적용하는 경우 손쉽게 데이터를 보호할 수 있다.
하지만 네트워크 규모가 커지면 비밀 암호화 키의 교환이 어렵다. 서로 통신을 하고자 하는 모든 이들 마다 서로 다른 비밀 키를 가지고 있을 경우 키 관리와 관련된 문제도 발생할 수 있다. 따라서 대칭 알고리즘은 어느 정도 이상의 규모에서는 맞지 않는다. 그 결과 인터넷에서는 적용하기 어렵다.
대칭 알고리즘 중에서는 Data Encryption Standard(DES)가 가장 많이 알려져 있다.
(2) 비대칭 알고리즘
비대칭 알고리즘은 암호화와 복호화에 서로 다른 키를 사용하는 방식을 말한다.
비대칭 알고리즘에서는 암호화 키를 공개할 수 있어서 누구라도 공개된 키를 이용해서 메시지를 암호화할 수 있다. 그러나 오직 복호화 키를 알고 있는 수신자만이 메시지를 복호화할 수 있다. 이때 암호화 키를 공개키라고 하며, 복호화 키를 개인키 혹은 비밀키라고 한다.
비대칭 알고리즘 중에서는 RSA가 가장 많이 알려져 있다. RSA는 1978년 미국 MIT 연구원 리베스트(Rivest), 섀미르(Shamir), 애들먼(Adleman) 등이 매우 큰 두 소수의 곱으로 이루어진 숫자의 소인수 분해가 매우 어렵다는 것을 발견하고 이것에 기반을 두고 만들어진 것이다.
RSA 공개키는 누구든지 사용할 수 있다. 반면 RSA 개인키는 개인키 소유자만 알고 있다. 비밀 메시지를 보내려면 메시지 수신자의 공개키를 사용해서 메시지를 암호화하면 된다. 이렇게 암호화된 메시지는 수신자의 개인키로만 복호화가 가능하다.
반대로 RSA 개인키 소유자는 그들의 개인키를 사용해서 데이터를 암호화할 수 있다. 이렇게 암호화된 데이터는 자기의 공개키를 가지고 있는 수신자에 의해서 복호화될 수 있다.
즉 RSA는 데이터를 암호화하고 복호화하는데 한 쌍의 키를 이용한다. 한 키로 암호화하면 다른 키로 복호화할 수 있는 것이다.
3. 디지털 서명과 인증서
3.1 디지털 서명
디지털 서명은 손으로 쓴 서명을 전자식으로 만든 것과 같다. 디지털 서명은 송신자의 신원 확인과 전송 데이터의 무결성 보장을 위해 파일이나 메시지에 첨부되어 전송되는 암호화된 코드이다.
디지털 서명은 비대칭 알고리즘으로 만들어진 암호화된 비트 블록으로, 데이터의 무결성을 보장하기 때문에, 중간에 누군가가 가로채서 데이터를 수정한 경우에는 이 값이 변경되어 수신쪽에서 원본과 다른 메시지가 전송되었다는 것을 알 수 있다.
다음은 송신자가 디지털 서명을 만드는 과정이다.
① 송신자는 해시 함수를 사용해서 전송할 메시지에 대한 해시 값을 얻는다. 이 해시 값을 다이제스트(digest)라고 한다.
② 송신자는 자신의 개인키로 다이제스트를 암호화한다. 이것이 디지털 서명이다.
다음은 수신자가 디지털 서명을 이용해서 송신자의 신원을 확인하는 과정이다.
① 수신자는 송신자의 공개키로 다이제스트를 얻어낸다.
② 수신자는 해시 함수를 이용해서 수신한 메시지에 대한 다이제스트를 얻어낸다.
③ 이 값과 송신자가 보낸 다이제스트 값을 비교하여 데이터의 무결성과 송신자의 신원을 확인한다.
3.2 디지털 인증서
디지털 인증서(digital certificates)는 개인 및 회사의 공개키가 정확히 그 개인 및 회사의 것인지를 확인하기 위해 제 3자인 공인된 인증기관이 발급한 디지털 서명을 말한다.
디지털 인증서를 발급하는 공인된 인증기관은 CA(Certificate Authorities)라고 한다.
인증기관은 개인 및 회사의 공개키 내용을 인증기관의 개인키로 디지털 서명한다. 일반적으로 디지털 인증서는 “cer" 확장자 명을 가진 파일로 저장된다.
수신자는 디지털 인증서를 인증기관의 공개키로 복호화하여 정확한 송신자의 공개키로 얻어낸 다음, 송신자가 보낸 디지털 서명을 복호화하는데 이용한다.
4. 전송 수준의 보안
4.1 개요
웹 서비스의 보안을 이야기할 때는 보통 전송(transport) 수준의 보안과 애플리케이션 수준의 보안으로 나누어볼 수 있다. 그리고 애플리케이션 수준의 보안에서는 SOAP과 관련 있는 보안과 XML 전반에 대한 보안으로 다시 세분화할 수 있다.
전송 수준의 보안은 웹 서비스가 이용하려는 프로토콜의 전송 계층 자체의 보안을 말한다. 전송 수준의 보안이 중요한 이유는 SOAP 메시지가 전송 계층에서 제공하는 패키징 메커니즘을 이용해서 캡슐화되기 때문이다. 여기서 주목할 것은 전송 수준의 보안은 ‘점대점(point-to-point) 보안’ 이라는 점이다. 점대점 보안이라는 것은 중간에 어떤 중개자 없이 직접 연결되어 있는 경우를 말한다. 이와 대별되는 개념이 end-to-end 보안인데, 여기에는 SOAP 중개자가 있을 수 있으며 이 경우에는 전송 수준의 보안으로는 충분하지 않고, XML 기반의 보안 기술을 포함하는 애플리케이션 수준의 보안이 필요하게 된다. 참고로 네트워크 수준에서 전송 수준의 보안을 구현한 대표적인 것이 있는데 바로 IPSec(Internet Protocol Security)이다. IPSec은 암호화 기법과 IP 인증, 프라이버시, 데이터 무결성을 구현한다.
4.2 HTTP 프로토콜 보안
HTTP는 웹 서비스에서 가장 중요한 전송 프로토콜로 동기식 프로토콜이다. 즉 일단 요청을 전송하고 클라이언트가 응답을 받아야 종결된다는 것이다. HTTP의 요청/응답 메시지는 사람이 쉽게 읽을 수 있는 텍스트 메시지이다. 그리고 각각의 요청/응답 쌍이 다른 요청/응답 쌍과는 전혀 관계가 없는 독립적인 이벤트로 구성된 무상태 프로토콜이다. 그러므로 클라이언트와 서버 사이에 세션이 유지될 필요가 없는데 지금까지 HTTP에 상태 정보를 이용할 수 있도록 하기 위해서 쿠
키를 많이 이용하곤 했다.
무상태 통신의 장점은 인터넷처럼 큰 규모의 분산 시스템에서 효율적이고 확장성이 좋다는 점이다. 이런 특징 때문에 웹 브라우저를 포함한 많은 제품이 HTTP를 지원하고 있으며 HTTP를 지원하는 것이 현재 인터넷 환경에서는 거의 필수적인 요소가 되고 있다. HTTP가 많이 퍼져 있기 때문에 그 만큼 HTTP 프로토콜 보안에 대한 관심이 항상 1순위가 될 수 밖에 없다. HTTP 프로토콜의 보안으로는 기본 인증(Basic Authen-tication)과 폼 기반의 인증(Form-based Authentication), SSL(Secure Socket Layer), 클라이언트 인증서를 이용하는 방법 등이 있다.
(1) 기본 인증
기본 인증은 HTTP 프로토콜 규격에 들어있는 간단한 인증 프로토콜이다. 거의 모든 웹 서버와 브라우저가 기본 인증은 지원하고 있다. 기본 인증은 방화벽과 프록시 서버가 있어도 잘 동작하며, 대부분의 SOAP 툴킷을 지원한다. 기본 인증의 최대 장점은 이렇게 널리 퍼져있다는 것이고, 단점으로 기본 인증에서는 암호를 Base64 인코딩 포맷으로 보내는데 쉽게 해독할 수 있기 때문에 보안의 정도가 약하다는 점이다.
(2) 폼 기반의 인증
HTML로 작성한 로그인 폼을 이용해서 로그인한 사용자 이름과 암호로 인증하는 방법이다. 이 방법은 널리 사용되기는 하지만 암호화하지 않은 HTML 문서 형태로 전송되기 때문에 보안이 취약하다.
(3) SSL
HTTP를 통한 기본 인증의 경우 크레덴셜(credential)이 일반적인 텍스트로 구성되기 때문에 보안에 문제가 있다. 이 문제를 해결하기 위해서 제시된 방법 중 하나가 SSL이다. SSL은 네트워크를 통해 통신하는 양쪽에서 주고받는 데이터를 암호화하는 것으로 SSL을 HTTP에 적용하면 ‘HTTPS’ 또는 ‘HTTP Secured'라는 프로토콜이 된다. SSL은 서버쪽에 설치된 디지털 인증서를 요구하고, 이 디지털 인증서를 이용해서 클라이언트가 서버를 인증한다. 여기서 중요한 것은 서버가 클라이언트에게 어떤 종류의 인증서도 요구하지 않는다는 점이다. 디지털 인증서는 앞서 설명한 인증기관에서 발급받는다. 물론 인증기관으로 유명한 베리사인이 아닌 다른 회사에서 인증서를 발급받거나, 자신의 인증서 서버를 운용해서 인증서를 발급할 수도 있다.
(4) 클라이언트 인증서
SSL을 이용한 서버 인증서와 함께 클라이언트 인증서도 이용할 수 있다. 클라이언트 인증서를 이용하면 클라이언트가 서버를 인증한다. 클라이언트가 웹 사이트에 접근하면 서버쪽 인증서가 클라이언트를 검증하고, SSL과 같은 암호화된 채널을 통해서 정보를 교환한다. 서버는 클라이언트가 자신을 밝힐 수 있는 방법을 요구하며, 클라이언트 인증서는 클라이언트가 단순히 사용자 이름과 암호만을 가지고 자신을 증명하는 것이 아니라 CA에서 발급받은 인증서를 통해 클라이언트를 증
명하는 것이다. 클라이언트 인증서는 서버 인증서만으로 부족하며 비교적 높은 수준의 보안이 필요한 경우에 이용한다.
5. 애플리케이션 수준의 보안
전송 수준의 보안은 SOAP 메시지에는 직접적인 영향을 주지 않는다. 그렇지만 애플리케이션 수준의 보안을 위해서는 SOAP 메시지 자체를 수정해야 한다. 이런 방식으로 수정한 SOAP 메시지는 어떤 프로토콜을 통해서도 전송할 수 있다.
5.1 SOAP 메시지의 크레덴셜
애플리케이션 수준의 보안에서는 인증을 위해 사용자 이름과 암호 크레덴셜을 요청 메시지에 담아서 웹 서비스로 전송해야 한다. 이 방법은 구현이 쉬운 대신, 전송량을 약간 증가시키지만 비교적 효율적이다. 애플리케이션 수준의 보안에서 가장 기본적인 방법은 모든 웹 서비스 연산에 사용자 이름과 암호를 매개변수로 추가하는 것이다. 이렇게 하면 해당 연산에 대해서 사용자 이름과 암호로 구성된 크레덴셜을 웹 서비스 쪽에서 확인하고 문제가 없으면 실행한 다음, 결과값을 SOAP 응답 메시지로 넘겨주면 된다. 다른 방법으로는 SOAP 메시지 헤더에 크레덴셜을 담아서 보내는 방법이 있다. 여기서 문제가 되는 것은 크레덴셜이 텍스트 형태로 전송된다는 것이다.
5.2 커버로스와 티켓 기반의 인증
커버로스(Kerberos)와 티켓 기반의 인증은 실제로 현재 웹 서비스에서 적용되는 보안 개념이다.
가장 대표적인 것이 바로 마이크로소프트 닷넷 플랫폼의 패스포트다. 패스포트는 일종의 싱글 사인온(Single Sign-On)으로 패스포트만 있으면 여러 웹 서비스를 실행할 수 있다.
티켓 기반의 인증은 애플리케이션 수준에서 일어난다. 보통 티켓 기반의 인증을 위해서는 디지털 서명과 디지털 인증서, 공유키/공개키 암호화 기술 등을 이용한다. 애플리케이션 내부에 인증을 위한 코드가 포함되어 컨텐츠를 암호화하고, 송수신하는 메시지들에게 디지털 서명을 부여하거나 서명을 검증한다. 커버로스는 MIT에서 인증 서비스를 위해 개발한 기술로, 기본적으로 모든 네트워크가 안전하지 않다고 가정하고 사용자와 서비스들 사이의 상호 인증을 통해서만 인증할 수 있도록 하는 것이다. 커버로스는 대칭키 암호화를 이용하기 때문에 메시지를 암호화하고 해독하는 키가 동일하다.
티켓 기반의 인증과 커버로스는 현재까지의 보안 방법 중에서 비교적 발전된 방법이면서 몇몇 웹 서비스에서 구현하고 있는 방법이다. 그렇지만 문제는 XML 또는 SOAP 메시지에 티켓 기반의 인증과 커버로스를 어떻게 구현할 것인지에 대한 지침이 아직 부족하다는 것이다. 이런 문제를 해결하기 위해 몇 가지 XML 관련 보안 규격이 연구되고 있다.
6. 웹 서비스 시대에서 보안의 의미
웹 서비스 아키텍처에서 보안은 전통적인 의미의 보안에, 개방적이고 동적인 웹 환경에서 서비스를 찾아내고 실행할 수 있는 새로운 모델을 가미한 것이다. 서비스 지향적인 아키텍쳐(SOA)에서 보안의 목표는 요소들 사이의 신뢰할 수 있는 상호 작용이 되도록 하는 것이다. 보안을 ‘위협(threats)에 대한 보호’라고 정의한다면, 웹 서비스의 보안은 상호 작용에서 위협이 될만한 것을 차단하고, 이러한 위협에 대한 대처 방법을 제시해야 한다. ‘신뢰’라는 것은 2개의 파티(party)들이 서로의 위험을 이해하고 문제가 될 여지가 있는 것을 측정하고 여기에 보호 장치를 가할 때 만들어질 수 있다.
웹 서비스 상호 작용에서 위협을 알아내고 이에 대한 대응책을 찾는데 어려움이 있는 것은 웹 서비스가 서로 연결되어 상호 작용하기 때문에, 위협을 알아내고 여기에 대응책을 세우면 이것이 또 다른 위협이 될 수 있기 때문이다. 그러므로 대응책을 정의하는 데 매우 신중해야 한다. 그렇다고 해서, 시스템을 디자인할 때 마냥 앉아서 가능한 모든 위협과 대응책이 완벽하게 도출될 때까지 기다릴 수는 없는 법이다.
보안 방법의 진화는 새로운 경제의 진화에 있어 매우 중요한 부분이지만, 성공적이 되기 위해서는 디자인하고 이용하기 쉬워야 하며 비용 효과도 우수해야 한다. 그렇지 않으면 사람들이 쓰지 않을 것이다. 다음에 나열하는 것들은 웹 서비스의 영역에서 도출된 위협에 대해 대응할 보안이다.
• 런타임에서 중개자와 요구자, 제공자가 공유하는 정보에 대한 보안이 필요하다.
• 런타임에 배포되는 네트워크에 대한 보안이 필요하다.
• 안전한 프로그래밍을 위해 디자인 타임에 이용할 API, 스켈레톤과 스텁 등이 필요하다.
디자인 타임에서의 애플리케이션 보안 모델에 대한 이슈에는 애플리케이션 개발 환경 자체에 대한 보안 이슈도 있다. 어쨌든 이와 같은 3가지 보안은 웹 서비스에서 기본적인 보안의 목표가 될 것이다.
사실 가장 어려운 것은 새로운 모델을 제시하는 것보다 레거시 보안 프로그래밍 모델과 메커니즘을 통합해서 새로운 디자인으로 가져가는 것이다. 현재 대부분의 웹 서비스는 웹 서버에 의존하고 있다. 그런데 만약에 환경 설정이 잘못되면 웹 서버가 버퍼 오버플로우 공격이나 URL 버튼을 끊임없이 작동하게 하는 종류의 공격에 무방비로 노출될 수 있다. 버퍼 오버플로우 공격은 웹 서버에 치명적인 텍스트 스트림으로 구성되는데, 이를 통해 실행 가능한 코드를 메모리에 로드하게 만든 다음에 웹 서버를 해킹하는 방식의 공격을 말한다. 관련하여 이미 많은 수의 보안 패치들이 발표되었다. 예를 들어, 마이크로소프트의 IIS같은 경우에는 수없이 많은 보안 패치가 발표되었다는 것을 여러분도 모두 기억할 것이다. 웹 서비스가 웹 서버를 이용하는 만큼 웹 서버에 대한 보안을 잘 하는 것은 필수사항이다.
여기에 SOAP은 웹 서버를 공격하는 또 다른 구실을 만들어주었는지도 모르겠다. 버퍼 오버플로우 공격의 경우 웹 서버 자체에 대한 공격도 있을 수 있지만, 웹 서버의 SOAP 엔진을 대상으로 하는 경우도 생각해볼 수 있는 것이다.
7. SOAP 디지털 서명
웹 서비스와 클라이언트 사이의 통신을 안전하게 보장하기 위해서 'HTTP over SSL'이나 최근의 TLS(Transport Layer Security)와 같은 것들이 제시되고 있다. 그리고 SOAP과 웹 서비스 자체에 대한 보안도 최근에는 가장 중요한 주제로 부각되고 있는 것이 사실이다.
SOAP DSIG(Digital SIGnatures)는 그 중에서도 비교적 최근에 정해진 규격으로 SOAP메시지의 무결성을 보장하기 위해 메시지에 디지털 서명을 하도록 한다.
7.1 SOAP 디지털 서명의 등장
SOAP 1.1에는 디지털 서명이 포함되어 있지 않으며, 보안 부분이 취약하다. SOAP 1.1에 디지털 서명을 포함시킨 것이 바로 SOAP-DSIG이다. SOAP-DSIG는 SSL을 이용한다.
웹 서비스를 이용해서 SOAP 기반의 B2B 애플리케이션을 작성한다면, 보안 이슈가 매우 중요하다. 특히 엔터프라이즈 시스템 사이에 비즈니스 트랜잭션이 있다면 부인방지(nonrepudiation)에 대한 보안을 요구하는 것이 당연하다. SOAP-DSIG 규격은 이러한 부분을 해결하기 위해 등장한 것이다. 부인방지가 필요한 이유는 악의적인 전송자가 있기 때문이다. 부인방지는 메시지를 전송한 자와 메시지를 만든 자가 동일하다는 것을 보장하는 것이다.
부인방지를 만족시키기 위해서는 메시지 인증과 전송자 인증이 동시에 이루어져야 한다. 메시지 인증은 디지털 서명을 통해서 이루어지지만 이것만으로는 충분하지 않다. 이는 서명이 메시지의 전송자인지 아니면 중간에 누군가가 가로챈 다음에 보낸 것인지를 보장할 수 없기 때문이다. 예를 들어, A가 디지털 서명을 한 구매 주문을 B에게 전송한다고 가정하자. 이때 C가 주문의 복사본을 얻어서 B에게 재전송하면 B는 2개의 구매 주문을 받은 셈이 된다. 마찬가지로 전송자 인증 역시
부인방지의 충분조건이 되지 못한다. 이 경우에는 메시지가 중간에 변경되었다는 것을 보장하지 못한다. 그러므로 부인방지 원칙을 만족시키기 위해서는 디지털 서명을 이용해서 메시지 인증과 전송자 인증을 모두 할 수 있어야 한다.
7.2 XML-DSIG의 XML 서명
XML 디지털 서명의 표준안을 주도하는 XML-DSIG(W3C의 워킹 그룹)는 XML에 디지털 서명을 할 수 있는 표준안을 정의하고 있다.
XML-DSIG는 XML에 디지털 서명을 하고, 여러 개의 문서가 하나의 서명을 참조할 수 있는 방법도 제공한다. 하나의 XML 서명이 XML 문서 내부에 있으면 이를 'enveloped' 되었다고 하고, XML 서명이 XML 문서를 감싸는 경우에는 'enveloping'이라고 한다. 또 하나는 'external'이 있는데, 이는 XML 문서와 독립된 문서로 존재하는 경우로 URL를 이용해서 참조할 수 있다.
XML 서명은 XML 트랜잭션에서 이용할 수 있도록 디자인된 디지털 서명이다. 이 규격은 디지털 서명 오퍼레이션의 결과를 가져올 수 있는 스키마를 정의하고, 인증과 데이터 무결성, 서명한 데이터에 대한 부인방지 등을 지원하기 위한 내용을 포함한다.
XML 서명의 기본적인 특징은 XML 문서 전체에 대한 서명만 가능한 것이 아니라 일부에 대한 서명도 가능하다는 것이다. 어떤 경우에는 특정 엘리먼트에만 서명을 할 수 있으며, 어떤 경우에는 특정 엘리먼트의 데이터 값에만 서명할 수도 있다. 이러한 유연성은 실제 비즈니스 플로우에서 매우 중요한 역할을 한다. 예를 들어, 서명된 XML 문서가 최소한 2개 이상의 비즈니스 엔티티에 의해서 작성되어야 하는 경우, 문서 전체에만 서명할 수 있다면 한 쪽에서 서명한 문서를 다른 쪽에서는 전혀 변경할 수가 없다. 그에 비해 일부분에만 서명이 가능하면 경우에 따라서 업데이트를 한 뒤에 결재 라인을 타거나, 협상이 이루어지도록 할 수 있다. XML 서명의 구조는 다음과 같다.
| <Signature> <SignedInfo>
<CanonicalizationMethod .../>
<SignatureMethod .../>
<Reference URI=...>
<Transforms .../>
<DigestMethod .../>
<DigestValue .../>
</Reference>
</SignedInfo>
<SignatureValue .../>
<KeyInfo>
</Signature>
|
서명해야 하는 각각의 리소스는 <Reference> 엘리먼트에서 URI로 지정한다. <Transforms> 엘리먼트에서는 참조하는 리소스의 컨텐츠에 대한 다이제스트를 만들기 전에 해야 하는 작업을 먼저 나열한다. 그리고 <DigestValue> 엘리먼트에 참조한 리소스의 실제 다이제스트 값이 들어간다. <SignatureValue>엘리먼트에는 <SignedInfo> 엘리먼트에 있는 다이제스트의 암호화된 값이 들어가며, <KeyInfo> 엘리먼트에는 서명을 검증할 키에 대한 정보를 입력한다.
| <?xml version="1.0" encoding="UTF-8"?> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo Id="Sample"> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> <Reference URI="http://www.rocozen.com/index.htm"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> <Reference URI="http://www.w3.org/TR/2000/~/signature-example.xml"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>UrXLDLBlta6skoV5/A8Q38GEw44=</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0E~LE=</SignatureValue> <KeyInfo> <X509Data> <X509SubjectName>CN=Jeong, O=ROCOZEN, ST= , C= </X509SubjectName> … … <X509Certificate> MIID5jCCA0+gA IVN … </X509Certificate> </X509Data> </KeyInfo> </Signature> |
XML 서명이 전달되면 이를 검증하는 방법은 <SignedInfo> 엘리먼트에 있는 서명을 검증하는 것이다. 이를 위해서 먼저 <SignedInfo> 엘리먼트의 다이제스트를 <SignatureMethod> 엘리먼트에 지정한 다이제스트 알고리즘을 이용해서 다시 계산한 다음에, <SignatureValue> 엘리먼트에 있는 값을 <KeyInfo>에 있는 공개키를 이용해서 해독한 값과 동일한지를 검토하면 된다. 그 다음에 각각의 참조에 대한 다이제스트도 검증할 수 있는데, <SignedInfo> 엘리먼트에 들어 있는 각각의
<Reference> 엘리먼트에 대한 다이제스트를 계산하고 이를 <DigestValue> 엘리먼트의 값과 동일한지 검토하면 서명이 제대로 이루어졌고 중간에 문제가 없었는지 확인할 수 있다.
7.3 SOAP-SEC
SOAP-SEC는 2001년 2월에 IBM과 마이크로소프트가 W3C에 제출한 규격으로 SOAP 1.1 메시지에 SOAP-SEC:Signature라는 새로운 헤더 엔트리를 추가하는 방식으로 디지털 서명을 지원하는 것이다. 그리고 SOAP-SEC를 위해서 'actor'와 'mustUnderstand'라는 기존의 헤더 아이템을 이용한다. actor는 헤더 엘리먼트의 수신자를 가리키며, mustUnderstand는 애플리케이션이 XML 서명을 반드시 검증해야 하는지 여부를 지정한다. 또한 SOAP-SEC에서는 Canonicalization 알고리즘을 이용한다. XML 서명을 할 때 이 알고리즘이 이용되는 이유는 XML 문서는 약간의 변경이
있더라도 경우에 따라서는 유효하다고 인정해야 하기 때문이다. 예를 들어, XML 문서가 DOM 프로세싱을 거친다면 엘리먼트 사이의 불필요한 공백문자를 제거하게 되며, 경우에 따라서는 유닉스와 윈도우 시스템에서 줄의 마지막 문자도 각각 다를 수가 있다. 즉, 운영체제에 따라 차이가 있을 수 있다. 이러한 변화가 디지털 서명에 영향을 주지 않아야 하므로, 서명하기 전에 XML 문서는 반드시 엘리먼트 사이에 있는 공백문자들을 완전히 제거한 canonical 폼으로 먼저 변환이 되어야 한다.
8. XML 암호화
XML 암호화는 W3C에서 표준화를 추진하고 있는 규격으로, 단순히 암호화에 대한 내용뿐만 아니라 서명된 디지털 문서에 대한 메타 정보까지도 표현하므로 이 문서를 처리하는 프로세서가 문서를 암호화할 때 어떤 알고리즘을 쓸 것인지 알 수 있다.
XML 암호화는 암호화의 범위도 지정할 수 있도록 하고 있다. 엘리먼트 이름만 암호화할 수도 있고, 그 내부에 포함된 데이터를 같이 암호화 할 수도 있으며, 데이터만 암호화할 수도 있다. XML 암호화와 XML 디지털 서명 규격은 같이 XML 문서에 적용할 수 있다. 예를 들어, SOAP-SEC를 이용해서 SOAP 메시지를 서명하고, 여기에 암호화한 첨부 문서를 포함하여 전달할 수도 있다. 데이터의 서명을 검사하기 위해서는 먼저 암호화된 첨부 문서를 해독해야 한다.
(1) 암호화 방법
예를 들어서, XML 암호화에 대해서 살펴보자. 다음 XML 문서는 간단한 책을 주문하는 내용을 담고 있다. 이렇게 전자상거래 주문과 관련해서는 보안이 무척이나 중요하다. 한 가지 방법은 SSL을 이용하는 것이다. 이렇게 하면 일단 전송 계층에서 전체 통신에 대한 보안을 하게 된다.
그 다음에 생각할 수 있는 것이 XML 암호화다. 암호화를 이용하면 특정 부분에 대해서만 암호화를 이용할 수 있다.
| <purchaseOrder> <Order> <Item>Book</Item> <Id>123-456</Id> <Quantity>3</Quantity> </Order> <Payment> <CardId>1234-5678-9012</CardId> <CardName>VISA</CardName> <ValidDate>12-2005</ValidDate> </Payment> </purchaseOrder> |
다음 문서는 앞의 문서에 XML 암호화를 적용한 XML 문서로, 전체 문서를 암호화한 것이다.
<CipherData>와 <CipherValue> 엘리먼트의 의미를 파악하면 쉽게 이해될 것이다. 실제 암호화한 값이 <CipherValue> 엘리먼트에 포함되며, 완전한 <CipherData> 엘리먼트는 <EncryptedData> 엘리먼트 내부에 나타난다. <EncryptedData> 엘리먼트에는 암호화에 이용되는 XML 네임스페이스가 포함된다. 여기에서 주목할 것은 실제 암호화 대상이 되는 컨텐츠의 네임스페이스가 Type 속성에 지정된다는 점이다. 다른 리소스의 경우에는 다른 URI가 이 속성에 지정된다.
| <?xml version='1.0'?> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'> <CipherData> <CipherValue>A12B34C56</CipherValue> </CipherData> </EncryptedData> |
전체 문서가 아닌 특정 엘리먼트만 암호화 하고 싶을 때는 어떻게 할까? 다음 문서는 <Payment> 엘리먼트의 내용만 암호화한 것이다.
| <?xml version='1.0'?> <PurchaseOrder> <Order> <Item>Book</Item> <Id>123-456</Id> <Quantity>3</Quantity> </Order> <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element' xmlns='http://www.w3.org/2001/04/xmlenc#'> <CipherData> <CipherValue>A12B34C5678</CipherValue> </CipherData> </EncryptedData> </PurchaseOrder> |
전체 문서를 암호화한 것과 비교하면, 암호화하지 않아도 좋은 부분에 대해서는 기존의 XML 문서 체계를 그대로 가져가고, 암호화할 부분만 <EncryptedData> 엘리먼트에 포함시킨다. 그리고 <EncryptedData> 엘리먼트의 Type 속성에도 차이가 있는데, 전체 문서를 암호화 할 때에는 IANA의 XML 리소스에 대한 네임스페이스를 지정한데 비해, 여기에서는
‘http://www.w3.org/2001/04/xmlenc#/Element’를 네임스페이스로 이용한다.
이제부터 중요한 것은 암호화한 키를 어떻게 교환하고, 이를 이용해서 어떻게 암호화하는 지에 대해서 살펴보자
(2) 키의 교환
키의 교환에 대해서 설명하기 위해 가정할 시나리오에서는 전송자는 자신의 공개키를 전송하고, 수신자는 건네받은 공개키를 이용해서 비밀키를 암호화 한다. 다음 XML 문서는 키를 교환하는 요청 메시지다. A와 B가 키를 교환한다고 하면, 아래 코드에는 없지만 A가 공개키 교환 요청을 초기화하고 공개키를 <EncryptedKey>라는 엘리먼트에 담아서 전송한다.
| <?xml version='1.0'?> <SecureCommunicationDemonstration> <EncryptedKey CarriedKeyName="A" xmlns='http://www.w3.org/2001/04/xmlenc#'> <EncryptedMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <CipherData> <CipherValue>abc123def456123sdfwe</CipherValue> </CipherData> </EncryptedKey> </SecureCommunicationDemonstration> |
CarriedKeyName 속성은 전송되는 키의 이름을 나타낸다. 이것은 XML 디지털 서명과 밀접한 관계가 있는데, 엘리먼트 이름이 <EncryptedKey>이며, 여기에는 ds:KeyInfo와 ds:KeyValue 엘리먼트가 포함된다. 이들은 모두 XML 디지털 서명 네임스페이스에 속해 있다. 다시 말해, XML 암호화는 키를 교환하는 방식에 대해 XML 서명에서 이용하는 방식을 그대로 이용하는 것이다.
(3) 교환한 키를 이용한 암호화
비대칭 암호화를 이용할 때 비밀키를 교환했으면, 그 다음에는 이 키를 이용해서 데이터를 암호화 하면 된다. 앞의 예를 가지고 설명하면, B는 A가 보낸 공개키를 이용해서 자신의 비밀키를 암호화해서 다시 A에세 보냈을 것이므로, A는 이 비밀키를 자신의 개인키로 일단 해독한다. 그 다음에 A는 B에게 전송할 데이터를 이 비밀키를 이용해서 암호화한 다음, 이 값을 <CipherValue> 엘리먼트에 집어넣는다. 다음은 이러한 과정을 완료한 전체 XML문서는 다음과 같다.
| <?xml version='1.0'?> <SecureCommunicationDemonstration> <Order> <Item>Book</Item> <Id>123-456</Id> <Quantity>3</Quantity> <CardName>VISA</CardName> <ExpDate>12-2005</ExpDate> <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element' xmlns='http://www.w3.org/2001/04/xmlenc#'> <EncryptedMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc'/> <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> <ds:KeyName>A</ds:KeyName> </ds:KeyInfo> <CipherData> <CipherValue>A12B34C56789</CipherValue> </CipherData> </EncryptedData> </Order> </SecureCommunicationDemonstration> |
9. XKMS
XKMS(XML Key Management Specification) 규격은 공개키 암호화와 관련한 여러 가지 기반 기술을 웹 서비스에 적용한 것이다. XKMS는 웹 서비스 보안의 빌딩 블록으로만 보기에는 다소 광범위한 특징이 있다. XKMS에는 X-KISS(XML Key Information Service Specification)도 포함되어 있어서 사용자의 디지털 인증서가 믿을만한 것인지 질의할 수도 있다. XKMS 서비스를 이용해서 디지털 인증서를 등록할 수도 있는데 이 서비스가 XKMS 의 또 다른 서브 컴포넌트인
X-KRSS이다.
PKI를 이용하기 위해서는 애플리케이션이 키를 잘 관리해야 하며, 이러한 키 관리 문제가 PKI 기술을 적용하는데, 가장 커다란 장애물이 되고 있다. 이를 극복하기 위해서 세계 최대의 보안 인증 회사인 베리사인(VeriSign)이 주도가 되어 XKMS가 등장하게 된 것이다. 이 규격에는 애플리케이션이 키 페어를 등록하고, 키의 위치를 지정하며, 키와 관련된 정보를 검증하는 등의 여러 XML 메시지를 정의한다. XKMS 규격은 개방된 규격이기 때문에 어떤 회사에서도 이를 구현해서 마음
대로 이용할 수 있다. 베리사인에서는 개발자들이 이 웹 서비스를 많이 이용하도록 하기 위해서 'XML Trust Center' 라고 불리는 XML 트러스트 서비스(인증서 발급 서비스)지원하고 있으며, 개발자들을 위해서는 XKMS 클라이언트 API를 구현한 자바 API를 이용할 수 있도록 하고 있다.
XKMS 클라이언트 API에는 XML 디지털 서명 규격도 구현하고 있어서 XML 문서에 서명하는 API 패키지도 이용할 수 있다. 애플리케이션에서는 XKMS 자바 API를 이용해서 암호키 쌍을 생성하고 이 키들을 XKMS 서비스에 등록할 수 있다. 그리고 XKMS 서비스를 이용해서 키에 대한 정보도 가져올 수 있다. 예를 들어, A라는 회사에서 <Price>를 요청하면서 B회사로 요청에 대한 공개키를 전송한 경우, A사는 요청을 XKMS 서비스에게 보내서 키에 대한 정보를 달라고 요구하고, 여기에 대한 검증을 하게 된다.
10. 새로운 보안 표준 WS-Security
2001년 10월 23일에 마이크로소프트는 웹 서비스 보안에 대한 규격으로 'WS-Security'라는 규격을 발표하였다. WS-Security는 <credentials>, <integrity>, <confidentiality>라는 엘리먼트를 이용해서 디지털 인증서, 디지털 서명, 그리고 암호화에 이르는 기본적인 보안 이슈를 모두 다루고 있어, SOAP-SEC에 비해 훨씬 자세하면서도 한층 진보한 규격으로 알려지고 있다. 여기에 IBM도 참여하고 있어 실질적으로 가장 널리 채택될 웹 서비스 보안 표준이 될 전망이다. 2002년 4월 10일에 발표된 IBM의 WSTK 3.1에는 WS-Security를 구현한 것이 포함되어 있다.
WS-Security는 기본적으로 XML 서명과 XML 암호화 표준을 기반으로 작성되었다. 그리고 SOAP 규격의 기본적인 컨텍스트를 계승하고 있어서, 어떻게 보면 SOAP을 확장해서 인증과 메시지의 보안 및 비밀성을 증진시킨 규격이라고 할 수 있겠다. SOAP을 확장하기 위해서 WS-Security는 SOAP 헤더를 이용하는데, 여기에서 디지털 인증서와 디지털 서명, 그리고 암호화와 관련된 각종 엘리먼트가 포함된다.
정리하기
(1) 일반적으로 보안은 애플리케이션을 개발하는 과정에서 가장 나중에 고려되는 경우가 많다. 그래서 대부분의 경우에 애플리케이션의 개발이 거의 완료되는 시점에 누군가가 보안에 대한 문제점을 제기할 때야 비로소 본격적으로 고민하게 된다. 더 심한 경우에는 실제 운용을 하다가 문제점이 발견되는 경우도 허다하다. 이런 면이 있기 때문에 보안을 이야기할 때 가장 먼저 언급되는 것이 보안에 대한 태도이다.
(2) 그리고 보안과 관련해서 반드시 알아두어야 할 또 다른 면은 ‘편리함’과 ‘보안’이라는 것은 언제나 상극이 될 수 밖에 없다는 것이다. 암호를 엄격하게 관리하거나, 강력한 보안 정책을 펼치게 되면 해당 정보 시스템을 이용하는 사용자들은 상당히 불편하게 여길 수 밖에 없다. 그러므로 최고 수준의 보안에서 가장 낮은 수준의 보안에 이르는 여러 가지 스펙트럼을 적절하게 혼용해서 사용자들의 불편을 최소화하면서 중요한 부분에 대해서는 강력한 보안을 가져갈 수 있도록 하는 것이 가장 중요하다.
(3) 보안을 구현하는 것은 일종의 프로세스이다. 이 프로세스는 새로운 위협이나 보안에서의 버그, 결함이 있을 경우에 지속적으로 개정하고 갱신할 수 있어야 한다. 일반적으로 보안에 대한 전체적인 프로세스를 언급한 좋은 리소스로서는 다음과 같은 것이 있다.
① CERT/CC (CERT Coordination Center)
SEI(Software Engineering Institute)와 미국 연방 정부가 연구 목적으로 기금을 모아 인터넷 보안을 연구하는 곳으로 카네기멜론 대학에서 운영하고 있다.
② IETF(Internet Engineering Task Force)의 Site Security Handbook
보안 정책 수립과 인터넷에 있는 기관들이 지켜야 하는 보안 프로시저에 대한 가이드를 제공한다.
http://www.ietf.org/rfc/rfc2196.txt
③ NIST의 CSRC(Computer Security Resouces Center)
보안과 관련한 여러 리소스의 URL이 나열되어 있다.
(4) 이번 시간에 언급한 여러 보안 관련 주제/내용들에 대해서 폭 넓게 추가적인 학습을 할 수 있기를 바란다.
'정보과학 > 웹서비스특론' 카테고리의 다른 글
| 웹 서비스 공개 및 검색, UDDI (0) | 2023.09.13 |
|---|---|
| 웹 서비스 명세화, WSDL (0) | 2023.09.12 |
| 웹 서비스 클라이언트 개발 (1) | 2023.09.11 |
| 웹 서비스 시스템 개발 (1) | 2023.09.09 |
| SOAP API (0) | 2023.09.08 |
