웹 서비스 보안의 해결책

정지훈
jhjeong@rocozen.com

이러한 웹 서비스 아키텍처는 크게 서비스를 제공 하는 서비스 제공자(provider)와 서비스를 필요로 하는 서비스 수 요자, 이들 사이를 중개하는 서비 스 중개자(broker)로 구성된다. 그리고 이들 사이에서는 서비스 를 발행(publish)하고, 이를 검색 (find)하고 나서 제공자와 수요자 사이의 서비스에 대한 결합 (bind)이라는 기본적인 세 가지 기능을 갖게 된다.

웹 서비스 아키텍처를 구현하 면, 서비스 간의 상호작용을 관리 하고 제어하기 위해 필요한 인증 (authentication) 기법이나 요금 정산과 같은 기본적인 환경에서 의 선결 조건을 환경설정 수준으 로 쉽게 정의할 수 있게 된다.

웹 서비스는 전통적인 프로그 래밍 방식인 컴파일을 통한 정적 바인딩에서 벗어나 실행시에 동 적으로 서비스를 검색하는 살아 움직이는 e-비즈니스의 서막을 알린다는 측면에서 그 의미가 깊 다. 이러한 상호협력을 통한 동적 인 서비스 제공을 통해 플랫폼이 나 프로그래밍 언어에 중립적인 구현을 할 수 있게 된다.

CORBA나 자바 RMI와 같은 기존 분산 컴퓨팅 환경은 시스템에 존재하는 다양한 컴포넌트가 밀접하게 연관되어 있기 때문 에 인터넷처럼 오버헤드를 줄이고, 효율성을 높여야 하며, 산 재된 B2B e-비즈니스 영역의 특징과 잘 맞지 않는 부분이 있 다. 이러한 접근 방법은 비즈니스 시스템 간의 공통된 컨텍스 트를 요구한다.

이에 비해 애플리케이션 영역의 현재 경향은 이렇게 밀접하 게 연관(tightly coupled)된 시스템보다는 동적으로 컴포넌트 사이의 바인딩이 일어날 수 있는 느슨한 연관(loosely coupled)을 선호하고 있다. 이러한 원칙에 의해 작성된 시스 템은 더 유연한 구조를 갖게 되므로 변화가 심한 차세대 e-비 즈니스 시스템의 특성에 더 잘 어울린다. 웹 서비스를 디자인할 때는 다양한 환경 요소를 반드시 고 려해야 한다. 예를 들어, 서비스 중개자에 대한 보안 요구는 배포 환경에 따라 다양하다. 대부분의 인트라넷 배포는 보안 에 대한 요구가 많지 않지만 높은 가격의 B2B 트랜잭션이 발 생하는 시스템은 훨씬 높은 수준의 보안을 요구한다. 이런 측 면에서 웹 서비스의 보안은 웹 서비스 기술이 세계를 주도하 는 기술로서 그 자리를 확고하게 차지하기 위해 가장 중요한 요소라고 말할 수 있다.

보안은 과거에 독립적인 애플리케이션을 만들 때도 어느 정 도 중요한 부분이었다. 그런데 애플리케이션이 여러 네트워크 에 분산되면서 보안의 중요성이 점점 더 강조되는 분위기가 되 고 있다. 웹 애플리케이션의 경우에는 그 중요성이 더욱 부각 된다. 웹의 특성상 외부에서 접근이 쉽기 때문에 웹 애플리케 이션에 침입하려는 시도가 많아질 수밖에 없다. 그러므로 웹 서비스 세계에서 보안은 단순한 중요성 이상의 의미가 있다.

보안의 주요카데고리

보안에는 여러 카테고리가 있다. 기본적으로 사용자는 인증을 받아야 하며, 리소스에 접근하기 위해 권한을 설정해야 한다. 컴퓨터 시스템은 리소스에 대한 감사(auditing)를 하고 로그 를 기록해야 한다. 저장된 정보는 언제나 무결성을 유지해야 하며, 아무나 볼 수 없도록 암호화(encryption)되어 있어야 한다. 그리고 프라이버시(privacy)가 지켜져야 하며, 이를 위 해 디지털 서명(digital signature) 등을 사용한다. 웹 서비스 보안에 대한 본격적인 논의를 하기 전에 이와 같은 보안의 주 요 카테고리에 대해 먼저 간략하게 알아보자.

인증

인증은 사용자와 컴퓨터, 애플리케이션이 다른 사용자, 컴퓨 터, 애플리케이션이 누구이고 무엇을 하려고 하는지를 확인하는 프로세스다. 보통 패스워드나 PIN(Personal Identifi cation Number), 스마트 카드와 같은 크레덴셜(credential) 을 이용해 인증한다.

웹 서비스에서 인증은 애플리케이션 사이에서 주로 이루어 지며, 크레덴셜은 패스워드나 인증서(certificate)를 이용한다.

권한부여

사용자, 컴퓨터, 애플리케이션이 인증되면 파일이나 데이터베 이스, 웹 서비스 등의 리소스에 접근하게 되는데 이 때 접근레 벨(access level)을 먼저 점검해 해당 리소스에 접근할 권한이 있는 사람에게만 접근을 허용한다. 이를 접근제어(access control)라고 한다. 접근제어를 실제로 구현하는 방법은 운영 체제에 따라 매우 다양하지만 보통 적당한 롤(role)이나 그룹 에 접근레벨이 부여되고, 접근레벨이 해당 리소스에 부여되어 이들이 적절하게 맵핑된 경우에 접근을 허용하거나 거부하게 된다. 접근이 허용되면 이를 해당 리소스에 대한‘권한부여 (authorization)가 됐다’고 한다.

감시와 로그

컴퓨터 시스템은 리소스에 접근하기 위한 시도와 리소스에 수 행한 오퍼레이션들에 대한 정보를 모아서 로그를 남기고 이를 감사할 수 있어야 한다. 로그는 시스템에 문제가 발생했을 때 가장 중요한 정보가 된다.

암호화

암호화는 중간에 데이터를 가로채더라도 이를 읽을 수 없도록 함으로써 무결성을 확보한다. 암호화를 위해서는 암호화 키와 패스워드가 필요하다. 암호화 자체는 수학적인 영역이며 여기 에 대해 자세하게 논의하는 것은 한 권의 책을 쓸 수 있는 분 량이므로 생략한다.

중요한 것은 암호화 기술에보통 크게 대칭적(symmetric) 인 방법과 비대칭적(asymmetric)인 방법이 있다는 것이다. 대칭적 알고리즘은 암호키와 해독키가 동일한 알고리즘이며, 비대칭적 알고리즘은 다른 말로 공개키(public key) 알고리즘 이라고도 하는데 개인키(private key)는 각자가 관리하고, 다 른 사람들에게 해독을 위한 키로 공개키를 배포하는 방법이다. 이 밖에 해시(hash)나 다이제스트(digest) 함수 같은 것을 이용해제공하는디지털 서명이암호화와관련이 있는부분이다.

공개키 알고리즘과 해시다이제스트 기능을 이해하면 디 지털 인증서(digital certificate)에 대해서도 이해할 수 있다. 앞서도 인증서에 대해 간단히 언급한 바 있는데, 인증을 할 때패스워드와 함께 가장 널리 이용되는 방법이 인증서를 이용하 는 방법이다. 전송자는 개인키를 이용해 암호화한 메시지를 해독하기 위해 공개키를 이용하고 이를 위해 공개키의 유효성 을 확인해야 한다. 이 때 인증서를 이용한다. 인증서는 공개키 에 대한 정보를 가진 이진(binary) 데이터로 여기에는 인증을 한 사람이나 기관, 유효기간, 인증한 사람의 디지털 서명 등이 들어가 있다. 디지털 인증서의 가장 흔한 포맷이 바로 X.509 인증서다. 자세한 정보를 원하는 독자는 http://www.ietf. org/rfc/rfc2459.txt RFC 문서를 참고하기 바란다.

부인봉쇄와 디지털 서명

부인봉쇄(Non-repudiation)는 어떤 액션이 일어났다는 것을 증명하기 위한 메커니즘을 제공한다. 즉, 특정 사용자컴퓨 터애플리케이션 등이 어떤 트랜잭션이 일어났다는 것을 거 부할 수 없도록 하는 것이다. 여기에는 인증이나 감사와 로그 등의 보안 기술이 포함되며, 법적인 의미를 내포한다.

디지털 서명은 파일이나 메시지에 붙어서 날아가는 일종의 서명으로 데이터의 무결성을 보장하기 때문에 데이터를 중간 에 가로채 조작하면 이 값이 변경되므로 수신 측에서 원본과 다른 메시지가 날아왔다는 것을 알아를 담아 보내서 공개키 알고리즘으로 암호화한 데이터를 해독할 때도 이용된다.

디지털 서명을 검증하기 위해서는 일단 수신하는 프로그램 이 전송자의 공개키를 이용해서 해시를 해독한다. 물론 공개 키는 전자메일이나 웹 등을 통해 얻을 수 있다. 이 때 전송자의 공개키만이 개인키로 암호화한 메시지를 해독할 수 있다. 그 다음에는 수신한 프로그램이 메시지나 파일에서 같은 종류의 해시를 만든 다음에 이들을 서로 비교해서 같으면 메시지가 중간에 변경되지 않았다는 것을 증명하므로 서명이 검증된다.

공개키 암호화

공개키 암호화(public key cryptography)는 비교적 최근 들 어 각광 받는 기술이다. 다른 형태의 암호화로는 메시지에 대 한 비밀키(secret key)를 이용해 암호화를 진행하고, 같은 키 를 이용해 해독하는 형태도 있다. 암호화 알고리즘 자체로는 훌륭한 것이 많다. 하지만 이런 방식의 가장 큰 문제점은 암호 화 과정 자체에 있는 것이 아니라 암호화하는 쪽과 해독하는 쪽 모두가 기본적으로 비밀키를 필요로 한다는 것이다.

만약 A, B, C가 사적으로 양방향 통신을 수행하려고 한다 면 세 개의 비밀키가 필요할 것이다. 하나는 A-B 사이에, 다 른 하나는 A-C 사이에, 마지막 것은 B-C 사이에 이용된다. 키 값을 교환하는 것은 다른 키들을 이용하거나 아예 다른 방 식으로 전달해야 한다.

공개키 암호화에는 키페어(key pair)라 부르는 두 개의 키 를 이용한다. 하나의 키는 서명을 읽을 수 있도록 하기 위해 다른 사람에게 전달되는 것인데, 이를 공개키라고 한다. 그리 고 나머지 하나는 사인을 생성할 때 이용하는 키로 이를 개인 키라고 한다. 이들은 모두 커다란 숫자로 구성된 일종의 데이 터 블럭으로 반드시 같은 프로세스에 의해 동시에 생성되어야 한다. 공개키를 메시지에 적용하면 암호문(cipher text)을 얻 게 된다. 이 메시지는 개인키를 이용해서만 해독할 수 있다.

참고로 반대도 가능하다. 즉 공개키로 암호화하고 개인키로 해독하거나 개인키로 암호화하고 공개키로 해독할 수도 있다. 그러므로 공개키 암호화는 디지털 사인이 될 수도 있으며 동 시에 프라이버시를 보호하는 용도로 이용할 수도 있다. 비밀스런 메시지를 보내기 위해서는 통신을 하려는 대상의 공개키를 이용해 암호화를 수행하고, 메시지를 읽기 위해서는 수신자가 개인키를 이용해 해독하게 된다.

공개키 암호화의 장점은 일단 일반적인 비밀키를 이용하는 방식에 비해 많은 수의 키를 생성할 필요가 없고, 키를 분배하 는 문제에 있어서도 각각의 대상자에게 비밀키를 전송할 필요 가 없기 때문에 안전하다. 키페어는 필요할 때 로컬 호스트 컴 퓨터에서 만들 수 있다. 키페어를 만들고 나서 공개키를 전자 메일이나 웹 페이지, 데이터베이스 등을 통해 공개할 수 있다. 키페어를 만들어낸 쪽에서는 이제 자신의 개인키만 잘 보관하 고 있다가 이를 이용해 암호화하거나 공개키로 암호화된 메시 지를 해독할 수 있다. 물론, 일반적인 비밀키를 이용한 암호화에도 장점이 있는데 암호문을 만들어내는 속도가 다소 빠르며 생성된 암호문의 길 이도 비교적 짧게 유지할 수 있다.

디지털 서명과 디지털 인증서

공개키 암호화 방법을 통해 키페어를 생성하면 일단 개인키는 만들어낸 당사자만 갖고 있게 된다. 그러므로 이를 이용해 자 신의 정체를 증명할 수 있는데 이를 디지털 서명이라고 한다. 데이터에 디지털 서명을 부착하면 해당되는 데이터를 수신한 쪽에서 이 데이터를 보낸 사람이 누구인지 확실히 알 수 있으 며, 해당되는 사람이 안전하다고 판단하면 접근을 허용하게 되는데 이를 인증이라고 한다.

여기서 조금 더 진척되면 디지털 서명 알고리즘을 이용해 전송 과정에 데이터가 변경된 적이 없다는 것을 보장할 수도 있 다. 이러한 과정을 데이터 무결성(data integrity)이라고 한다. 여기에서 중요한 것은 디지털 서명과 함께 전송된 데이터는 암호화되어 있지 않으므로 데이터를 가로챈 누구라도 데이터 를 읽을 수 있다는 것이다. 즉, 이 경우 인증과 데이터 무결성 은 확보되지만 프라이버시는 지켜지지 않는다.

디지털 서명을 이용할 때 가장 일반적으로 제기되는 문제점 은 어떻게 통신을 하고자 하는 상대방의 공개키를 신뢰할 수 있으면서도 안전한 방법으로 얻을 수 있는지에 대한 부분이 다. 이러한 문제에 대한 해답을 제시하는 것이 디지털 인증서 다. 디지털 인증서는 기본적으로 잘 알려지고 신뢰도가 높은 개인이나 단체에서 제공하는 공개키를 관리하자는 아이디어 에서 시작된 것으로 이와 같이 신뢰를 받는 곳을 CA(Certifi cation Authorities)라고 한다. 가장 널리 알려진 CA로는 베 리사인(Verisign)과 같은 곳이 있다.

웹 서비스 시대에 보안이 지니는 의미

웹 서비스 아키텍처에 대한 보안은 전통적인 의미의 보안에다 가 개방되고 동적인 웹 환경에서 서비스를 찾아내고 실행할 수 있는 새로운 모델이 가미된 것이다. 서비스 지향적인 아키 텍처에서 보안의 목표는 롤 사이의 신뢰할 수 있는 상호작용 을 가지는 것이다. 보안을‘위협(threats)에 대한 보호’라고 정의한다면 웹 서비스의 상호작용에서 위협이 될 만한 것들과 이러한 위협에 대한 대처방법을 제시해야 한다. 신뢰라는 것 은 두 개의 파티(party)가 서로의 위험을 이해하고 문제가 될 여지가 있는 것들에 대한 측정과 보호 장치를 가할 때 만들어 질 수 있다.

웹 서비스에서 위협을 알아내고 이에 대한 대응책을 찾는 데 어려움이 있는 것은 웹 서비스가 서로 연결되어 상호작용 을 가지므로 위협을 알아내고 여기에 대한 대응책을 세울 때 이것이 또 다른 위협이 될 수 있기 때문이다. 그러므로 대응책 을 정의하는 데 매우 신중해야 한다. 그렇다고 시스템을 디자 인할 때 앉아서 모든 가능한 위협과 대응책이 완벽하게 도출 될 때까지 마냥 기다릴 수는 없는 법. 이제부터 현 단계의 웹 서비스 보안에 대해 지금까지 도출된 위협과 이에 대해 제시 된 대응책을 바탕으로 웹 서비스 지향적인 아키텍처의 보안에 대해 접근해 보자. 보안 방법의 진화는 새로운 경제의 진화에 있어 매우 중요 한 부분이지만 성공적이 되기 위해서는 디자인하고 이용하기 쉬워야 하며 비용 효과가 우수해야 한다. 그렇지 않으면 사람 들이 쓰지 않을 것이다. 다음에 나열하는 것은 몇 가지 영역에 서 도출된 위협들이다.

◆ 런타임에서 중개자와 요구자(requestors), 제공자가 공유하는 정보에 대한 보안이 필요하다.

◆ 런타임이 배포되는 네트워크에 대한 보안이 필요하다.

◆ 안전한 프로그래밍을 위해 디자인 타임에 이용할 API, 스켈레톤과 스텁 등이 필요하다.

디자인 타임의 애플리케이션 보안 모델에 대한 이슈에는 애 플리케이션 개발 환경 그 자체에 대한 보안 이슈도 있다. 어쨌 든 앞에서 언급한 세 가지 보안은 웹 서비스에 있어 기본적인 보안의 목표가 될 것이다. 사실 가장 어려운 것은 새로운 모델 을 제시하는 것보다 레거시 보안 프로그래밍 모델과 메커니즘 을 통합해 새로운 디자인으로 가져가는 것이다.

어쨌든 대부분의 웹 서비스는 현재 웹 서버에 의존하고 있 다. 만약에 환경설정이 잘못되면 웹 서버가 버퍼 오버플로우 공격이나 URL 버튼을 끊임없이 작동하게 하는 종류의 공격 에 무방비로 노출될 수 있다. 버퍼 오버플로우 공격은 웹 서버 에 치명적인 텍스트 스트림으로 구성되는데, 이를 통해 실행 가능한 코드를 메모리에 로드하게 만든 후 웹 서버를 크래킹 하는 방식의 공격이다.

이런 것들과 관련하여 이미 많은 수의 보안 패치가 발표됐 다. 마이크로소프트의 IIS에 대해 수없이 많은 보안 패치가 발 표됐다는 것을 독자들도 모두 기억할 것이다. 어쨌든 웹 서비 스가 웹 서버를 이용하는 만큼 웹 서버에 대한 보안을 잘 하는 것은 필수사항이다.

여기에 SOAP은 웹 서버를 공격하는 또 다른 구실을 만들어 주었는지도 모르겠다. 앞서 설명한 버퍼 오버플로우 공격의 경 우 웹 서버 자체에 대한 공격도 있을 수 있지만 웹 서버의 SOAP 엔진을 대상으로 하는 경우도 생각해볼 수 있을 것이다.

SDA 디지털 서명

디지털 서명은 문서에 대한 암호화된 일종의 다이제스트다. 다이제스트는 문서를 특정 해싱 알고리즘에 집어넣으면 얻을 수 있고, 보통 간단한 바이트 문자열로 구성된다. 이렇게 만들 어진 다이제스트를 서명하는 사람의 개인키로 암호화하면 디 지털 서명이 만들어진다. 디지털 서명을 검사할 때는 문서에 서 다이제스트를 다시 만들어내고, 이를 서명한 사람의 공개 키를 이용해 해독한 후 이들이 같은지 비교하면 된다. SOAP 1.1에는 이러한 디지털 서명이 포함되어 있지 않으며, 보안에 취약한 측면이 있다. 여기에 디지털 서명을 포함시킨 것이 바 로 SOAP-DSIG(Digital Signature)다. SOAP 디지털 서명은 XML 디지털 서명과 SOAP-SEC 규격으로 이루어져 있다.

XML-DSIG

SOAP 메시지는 XML 문서로 구성되어 있기 때문에 SOAPDSIG는 XML-DSIG의 XML 서명 규격을 이용한다. 규격을 자세히 보고 싶은 독자는 http://www.w3.org/Signature를 참고하기 바란다. XML-DSIG는 XML에 디지털 서명을 하 고, 여러 개의 문서가 하나의 서명에 참조될 수 있는 방법도 제공한다.

하나의 XML 서명이 XML 문서 내부에 있으면 이를 ‘enveloped’됐다고 하고, XML 서명이 XML 문서를 감싸는 경우에는‘enveloping’이라고 한다. 또 하나는‘external’이 있는데, 이는 XML 문서와 독립된 문서로 존재하는 경우로 URI를 이용해 참조할 수 있다.

XML 서명은 XML 트랜잭션에서 이용할 수 있도록 디자인 된 디지털 서명이다. 이 규격에서는 디지털 서명 오퍼레이션 의 결과를 가져올 수 있는 스키마를 정의하고 인증과 데이터 무결성, 서명된 데이터에 대한 부인봉쇄 등을 지원하기 위한 내용이 포함되어 있다.

XML 서명의 기본적인 특징은 XML 문서 전체에 대한 서 명만 가능한 것이 아니라 일부 부분에 대한 서명도 가능하다 는 것이다. 어떤 경우에는 특정 엘리먼트에만 서명하거나 어 떤 경우에는 특정 엘리먼트의 데이터 값에만 서명할 수도 있 다. 이러한 유연성은 실제 비즈니스 플로우에서 매우 중요하 다. 예를 들어, 서명된 XML 문서가 최소한 두 개 이상의 비 즈니스 엔티티에 의해 작성되어야 하는 경우 문서 전체에만 서명할 수 있다면 한 쪽에서 서명한 문서를 다른 쪽에서는 전 혀 변경할 수 없게 된다. 그에 비해 일부분에만 서명이 가능하 면 경우에 따라 업데이트한 후 결재 라인을 타거나 협상이 이 루어지게 할 수가 있다. XML 서명의 구조는 다음과 같다.

서명되어야 하는 각각의 리소스는 엘리먼트에 서 URI로 지정한다. 엘리먼트에는 참조되는 리소스의 컨텐트에 대한 다이제스트를 만들기 전에 해야 하는 작업들을 먼저 나열한다. 그리고 엘리먼트에 참조된 리소스의 실제 다이제스트 값이 들어간다. 엘리먼트에는 엘리먼트에 있는 다 이제스트의 암호화된 값이 들어가며, 엘리먼트에 는 서명을 검증할 키에 대한 정보를 입력한다.

그러면 간단하게 XML 서명을 어떻게 만드는지 알아보자. 가장 먼저 할 일은 어떤 리소스에 서명할 것인지 결정하는 것 이다. 간단하게 URI로 지정하면 된다. 예를 들어 http:// www.rocozen.com/index.html은 웹에 있는 HTML 페이지 가 서명의 대상이 되는 것이며, http://www.rocozen.com/ xml/ex.xml이라고 지정하면 XML 파일에 서명하는 것이다.

그 다음에는 리소스에 대한 다이제스트를 만들어야 한다. XML 서명에서 각각의 참조되는 리소스는 엘리 먼트에서 지정되며, 여기에 대한 다이제스트가 엘리먼트에 기록된다. 다음 예를 보면 쉽게 이해가 될 것이다.

Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1”/>

j6lwx3rvEPO0vKtMup4NbeVu8nk=

20000228/signature-example.xml”>

Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1”/>

UrXLDLBIta6skoV5/A8Q38GEw44=

엘리먼트에서는 다이제스트를 만드는 알 고리즘으로 무엇을 사용할 것인지를 지정한다. 앞의 예에서는 SHA-1을 이용했다. 다이제스트를 계산한 후 값을 지정했으 면,엘리먼트를 모아서 서명으로 구성해야 한다. 서명 전체에 대한 구성은 다음과 같은 형태가 된다.

20000228/signature-example.xml”>

Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1”/>

UrXLDLBIta6skoV5/A8Q38GEw44=

엘리먼트는 엘리먼트에 있는 값들에 대한 공백문자와 캐리지 리턴 문제를 해 결하기 위한 방법을 지정한다. 즉, 동일한 XML 정보 세트에 대한 서로 다른 데이터 스트림에 대해 동일한 텍스트 표현방 식을 지정하는 것이다. 엘리먼트는 서명값을 만들어내는 알고리즘을 지정한다. 앞의 예에서는 DSASHA1을 이용한다. 이제엘리먼트에 있는 내용을 바탕으로 서명 을 계산해 다음과 같은 방법으로 기록하면 된다. 서명이 기록 되는 곳은 엘리먼트다.

MC0E LE=

이렇게 서명된 문서를 받아보려면 키에 대한 정보를 제공해야 한다. 키에 대한 정보는 엘리먼트에 기록한다.다음 예는 X.509 인증서에 포함되어 있는 키 정보를 전송자 가 이용하는 것으로 서명을 검증하는 데 필요한 공개키가 포 함되어 있다.

CN=Jeong, O=ROCOZEN, ST=... ,C=…

MIID5jCCA0+gA...lVN

마지막으로 , , 엘리먼트를 한데 모아서 엘리먼트에 담으면XML 서명이 완료된다. 완성된 형태는 <리스트 1>과 같다.

XML 서명이 날아오면 이를 검증하는 방법은 엘리먼트에 있는 서명을 검증하면 된다. 이를 위해 먼저 엘리먼트의 다이제스트를 엘리먼트에 지정된 다이제스트 알고리즘을 이용해 다시 계산한 후 엘리먼트에 있는 값을 에있는 공개키를 이용해 해독한 값과 동일한지를 검토하면 된다.

그 다음에 각각의 레퍼런스에 대한 다이제스트도 검증할 수 있는데, 엘리먼트에 들어 있는 각각의 엘리먼트들에 대한 다이제스트를 계산하고 이를 엘리먼트 값과 동일한지 검토하면 제대로 서명됐는지, 그리고 중간에 문제가 없었는지 알아볼 수 있다.

SOAP-SEC은 2001년 2월에 IBM과 마이크로소프트가 W3C에 제출한 규격이다. 이는 SOAP 1.1 메시지에 SOAPSEC: Signature라는 새로운 헤더 엔트리를 추가하는 방식으 로 디지털 서명을 지원하는 것이다. 그리고 SOAP-SEC를 위 해 actor와 mustUnderstand라는 기존 헤더 아이템을 이용 한다. actor는 헤더 엘리먼트의 수신자를 가리키며, mustUnderstand는 애플리케이션이 반드시 XML 서명에 대 해 검증해야 하는지 여부를 지정한다.

SOAP-SEC에서는 Canonicalization 알고리즘을 이용한 다. XML 서명을 할 때 이 알고리즘을 이용하는 이유는 XML문서는 약간의 변경이 있더라도 경우에 따라서

는 유효하다고 인정해야 하기 때문이다. 예를 들어, XML 문서가 DOM 프 로세싱을 거친다면 엘리먼트 사이의 불필요한 공백문자를 제 거하게 되며 경우에 따라서는 유닉스와 윈도우 시스템 줄의 마지막 문자의 차이도 있을 수 있다. 이러한 변화가 디지털 서 명에 영향을 주지 않아야 하므로 서명을 하기 전에 XML 문 서는 반드시 엘리먼트 사이에 있는 공백문자들을 완전히 제거 한 canonical 폼으로 먼저 변환해야 한다.

SAML과 XACML

SAML(Security Assertion Markup Language)은 OASIS 에서 주도하는 규격으로 웹 서비스에 대한 인증과 권한부여 정보를 안전하게 주고받을 수 있도록 하는 데 그 목적이 있다. SAML은 사용자들이 하나의 인증 서비스에 접근하는 병목 현상을 완화시켜 사용자들의 크레덴셜을 다른 서비스로 전이 할 수 있도록 하고 있다. 이때 사용자들은 서비스에 접근하기 위해 다시 인증을 받지 않아도 된다. 이와 비슷하게 웹 서비스 의 모든 사용자들이 같은 방식으로 인증을 받을 필요도 없다. 이러한 기능을 SSO(Single Sign-On)라고 한다. 즉, 어떤 경 우에는 사용자이름/패스워드, 어떤 경우에는 클라이언트 인 증서를 이용하도록 할 수 있다. 현재까지는 접근 관리와 SSO 제품들이 대부분 단일한 도메인에서만 이용될 수 있었지만 SAML을 통해 이러한 제품들이 XML 스키마를 정의해 인터 넷에서도 통용될 수 있는 길을 열어 놓은 것이다.

SAML은 XML 디지털 서명을 이용해 메시지가 중간에 변 경되지 않았으며, 전송한 쪽의 정체를 명확하게 하고 있다. SAML 1.0은 2002년 2월 14일에 OASIS에서 워킹 드래프 트(Working Draft) 수준으로 발표된 것이 있으며, 이를 참고 하고 싶은 독자는 http://www.oasis-open.org/committees/ security에서 문서를 받아볼 수 있다.

SAML에 대한 전체 내용을 알아보는 것은 지나치게 방대 한 내용이므로 이 중에서 SAML의 도메인 모델과 주요 SAML Assertion 스키마에 대해 간단하게 소개하겠다. <그림 1>은 SAML 도메인 모델을 나타낸 것이다. SAML에서 XML 기반의 보안 정보는 서브젝트(사람 또는 컴퓨터)에 대한 어서션(assertion)의 형태로 표현된다. 서브 젝트의 전형적인 예는 사람이다. 보통 전자메일 주소와 같은 것으로 식별될 수 있다. 어서션에는 서브젝트에 의해 수행된 인증 관련 행위 정보, 서브젝트의 각종 애트리뷰트, 그리고 서브젝트가 특정 리소스 에 접근할 때 권한부여가 어떤 식으로 결정됐는지 등에 대한

정보가 포함된다. 어서션은 XML로 표현되며, 중첩된 구조 다. <그림 1>에서 SAML로 표시된 영역에 인증, 애트리뷰트, 권한부여 결정에 대한 어서션이 있는 것이 바로 이런 의미다. 이러한 어서션은 <그림 1>처럼 SAML 권한(authority)에 의 해 결정된다. 인증 권한, 애트리뷰트 권한, 정책 결정 포인트 (policy decision point)가 각각 인증, 애트리뷰트, 권한부여 결정에 대한 어서션을 결정한다.

그리고 SAML은 클라이언트가 요청 어서션(request assertion)을 SAML 권한에 요구하고, 여기에 대한 응답 (response)을 얻는 과정에 대한 프로토콜을 정의한다. 이 프 로토콜은 XML 기반의 request/response 메시지 포맷으로 되어 있는데, 개념적으로 여러 통신 프로토콜을 지원할 수 있 지만 현재는 SOAP over HTTP 바인딩만 지원한다. SAML 권한들은 외부 정책 스토어나 요청에 들어 있는 어 서션 등과 같은 다양한 종류의 정보를 이용해 응답 메시지를 만들어낼 수 있다.

SAML 어서션은 하나 이상의 문장으로 구성된 정보의 패 키지다. SAML에는 특정 시간의 서브젝트 인증과 관련한 인 증 어서션, 특정 서브젝트가 특정 리소스에 접근하기 위한 요 청의 접근허용 여부에 대한 권한부여 결정 어서션, 특정 서브 젝트와 연관된 애트리뷰트에 대한 애트리뷰트 어서션 등이 있 다. SAML에 대해 더 자세한 내용은 앞서 언급한 규격 문서 를 참고하기 바란다.

XACML(XML Access Control Markup Language) 역시 OASIS에 의해 주도되는 표준으로 SAML에 부족한 접근제어 정책을 XML로 표현한다. 일단 SAML 어서션을 웹 서비스가 수신하면 웹 서비스는 SAML PDP(Policy Decision Point) 에 요청을 보내 PRP(Policy Retrieval Point)에서 XACML정책을 검사하도록 한다. 이렇게 XML을 이용해 접근제어를 하면 다양한 접근제어 제품이 갖고 있는 정책들에 쉽게 접근 할 수 있다.

XACML에 대한 더 자세한 내용은 OASIS의 XACML에 대한 공식 홈페이지인 http://www.oasis-open.org/commi ttees/xacml/index.shtml의 URL을 참고하기 바란다.

XML 암호화

XML 암호화는 W3C에서 표준화를 추진하는 규격으로 http: //www.w3.org/Encryption의 URL에서 구체적인 내용을 찾 아볼 수 있다. XML 암호화는 단순한 암호화에 대한 내용뿐 만 아니라 서명된 디지털 문서에 대한 메타 정보를 표현하므 로 이 문서를 처리하는 프로세서가 문서를 암호화할 때 어떤 알고리즘을 쓸 것인지 알게 된다. XML 암호화는 암호화의 범위도 지정할 수 있도록 하고 있 다. 엘리먼트 이름만 암호화될 수도 있고, 그 내부에 포함된 데이터를 같이 암호화할 수도 있으며, 데이터만 암호화할 수 도 있다.

XML 암호화와 XML 서명 규격은 XML 문서에 대해 동시 에 적용되어 해당 문서가 서명되고 암호화되도록 할 수 있다. 예를 들어, SOAP 메시지에 SOAP-SEC를 이용해 서명하 있다. 데이터의 서명을 검사하기 위해 먼저 암호화한 첨부 문서를 해독해야 가능하도록 할 수도 있다.

그럼 간단한 예를 통해 XML 암호화에 대해 잠시 알아보자. 다음 XML 문서는 간단한 책을 주문하는 내용을 담고 있다. 이렇게 전자상거래 주문과 관련해서는 보안이 무척 중요하다. 한 가지 방법은 SSL을 이용하는 것이다. 이렇게 하면 일단 트 랜스포트 레이어에서 전체 통신에 대한 보안을 하게 된다. 그 다음에 생각할 수 있는 것이 XML 암호화다. XML 암호화를 이용하면 암호화를 특정 부분에만 이용하게 할 수 있다.

Book

123-456

3

1234-5678-9012

VISA

12-2005

◆ 수신자로 하여금 메시지가 특정 라이선스를 가진 소유자, 예를 들어 X.509 인증서를 갖고 있거나 커버로스 티켓의 소유자에게서 온 것인지 확인하게 한다.

이러한 두 가지 목표를 달성하기 위해 WS-Security에서는 XML 서명을 이용해 전체 SOAP 메시지나 일부 메시지에 디 지털 서명을 하도록 한다. XML 서명 규격에 따르면 디지털 서명은 http://www.w3.org/2000/09xmldsig# 네임스페이 스에 속해 있는 엘리먼트에 하는 것으로 되어 있다. 그렇다면 SOAP 메시지에는 어디에 이 서명을 집어넣어 야 할까 WS-Security에서 정의하는 것은 이 부분이다. WS-Security는 무결성과 관련한 SOAP 헤더를갖고 있으며, 여기에 엘리먼트를 포함한다. 다음은 이와 관련한 SOAP 메시지의 뼈대다.

...

...

...

...

...

그러면 실제 SOAP 메시지에 크레덴셜과 무결성 헤더를 포함시킨 메시지는<리스트 3>과 같은 형태가 된다.

복잡해 보이지만 지금까지의 내용을 잘 읽어온 독자들이라면 한 눈에 파악했을 것이다. 주목할 부분을 몇 가지 지적하면먼저 크레덴셜 헤더에 있는 엘리먼트에 크레덴셜의 종류를 지정한다. id=X509License로 설정한 것은X.509 인증서를 이용한다는 것을 의미한다. 그 다음 무결성헤더 부분으로 넘어가면 바로 엘리먼트가 나온다. 여기에는 XML 서명 규격에 맞는 디지털 서명을 정의한다. 이 중에서 엘리먼트에 들어있는 엘리먼트에 X509License라는 엘리먼트를 참조하도록 하고있다. 이는 헤더에서 언급한 X.509 인증서에 대한 부분을 참조하도록 한 것이다. 다시 말해 X.509 인증서가 이 메시지에서는 전송자의 크레덴셜의 일부로, 그리고서명의 키 정보로 두 번 언급되는 것이다.

들어있는 웹 서비스가 라우팅 SOAP 헤더를 변경해 다른 곳 으로 전송되도록 할 수도 있다. 이 경우 클라이언트가 전체 SOAP 메시지에 서명해 변경을 금지해 버리면 라우팅 정보를 변경할 수 없다. 이 문제를 해결하기 위해서는 WS-Security 에서 SOAP 메시지의 일부분만 디지털 서명이 되어 있다고 선언해 라우팅 헤더를 변경할 수 있도록 해야 할 것이다.

비밀성

디지털 서명이 된 메시지는 데이터 무결성을 보장하지만 비밀 성을 보장하는 것은 아니다. 그 이유는 메시지 자체가 사실 텍 스트 문자열로 전송되기 때문이다. 비밀성을 제공하기 위해서 는 암호화와 관련한 부분에 대책이 있어야 한다. 이를 위해 WS-Security에서는 앞서 설명한 XML 암호화를 이용한다. XML 암호화는 XML 문서 전체를 암호화할 수도 있고, 일부 엘리먼트만 암호화할 수도 있다.<리스트 4>는 XML 암호화를 이용해 비밀성을 보장하는 WS-Security 규격을 적용한 SOAP 메시지의 예다. 암호화가 필요한 데이터는 엘리먼트에 포함되도록 하면 된다. XML 암호화 규격에서는 SOAP 메시지뿐만 아니라 다른 바이너리 데이터에 대해서도 SOAP with Attachments 또는 DIME 등의 규격을 이용해 암호화할 수 있다. 이 경우에는 암 호화되는 바이너리 부분이 SOAP 메시지와 분리되어 있고, 비밀성 SOAP 헤더가 메시지에 붙어있는 형태다.

대세가 되어가는 欖버

처음부터 완벽한 것은 별로 매력이 없다. 필자는 중고등학교 시절에 무협지를 즐겨 읽었는데 항상 주인공이 처음부터 강하 게 등장하는 것보다는 모진 고초를 겪고 죽음의 문턱까지 간 후 이를 이겨내고 절세무공의 초절정 고수가 되는 뻔한 스토 리를 보면서 감동을 느끼곤 했다.

현재 웹 서비스가 가는 길도 이와 별반 다르지 않은 것 같 다. 혜성처럼 등장해 각광을 받았지만 곧 무수한 약점을 노출 시키면서 공격을 받게 되고, 여기에 대응하는 여러 가지 무공 을 선보이면서 발전하는 모습이 조만간 초절정 고수가 되지 않을까 하는 기대를 해본다.

웹 서비스에 대한 공부를 시작한 것이 필자 개인적으로는 이제 1년이 넘어가고 있다. 그 동안의 자료를 모아서 웹 서비 스와 관련된 책을 한 권 집필했는데, 현재까지는 국내에서 본 격적으로 웹 서비스를 처음으로 다룬 책으로 참고자료 ①이 그것이다. 이번 테크니컬 컬럼의 내용도 이 책의 내용에서 상 당 부분 발췌해 작성한 것이므로 웹 서비스에 대해 더 심도 있 는 공부를 원하는 독자들에게 추천한다. 웹 서비스가 대세로 등장하는 것은 이미 거스를 수 없는 것 으로 보인다. 독자들도 웹 서비스에 대한 관심을 꾸준히 갖고공부하기 바라며, 필자도 새로운 기술이나 참고할 만한 내용이 발견되는 데로 이 컬럼을 통해 소개할 것이다.

제공 : DB포탈사이트 DBguide.net