Bitaholic

웹서비스 보안 1 (Web service security overview and Transport-Level-Securiyt) 본문

Computer/WebService

웹서비스 보안 1 (Web service security overview and Transport-Level-Securiyt)

Bitaholic ...Simple is beautiful Bitaholic 2008. 5. 22. 02:35

사용자 삽입 이미지

 

최근의 분산환경을 구축하는데 많이 쓰이는 기술이 웹서비스이다. 웹서비스 자체가 SOAP이라는 XML으로 데이터를 교환하고 보안채널이 아닌 HTTP나 JMS같은 프로토콜로 통신을 하니 보안에 아주 취약하다. 그 이유가 프로토콜 자체에서 메세지를 보호해 주지 않고 (물론 HTTPs를 쓸수도 있다) XML특성상 사람이 읽을 수 있는 형태로 메세지를 표현하기 때문이다.

 

물론 이 웹서비스에 보안을 적용할 수 있다.

여러가지 방법이 있는데 프로토콜의 보안기능을 이용하느냐 아니면 메세지 자체에 보안기능을 넣느냐에 따라 2가지로 나눌 수 있다.

  • Transport-Level Security
  • Message-Level Security

또 보안을 적용한 다는 것은 보통 3가지를 말한다.

  • Message Identity
  • Message Confidentiality
  • Authentication

Message Identity란 클라이언트에서 서버로 메세지를 보낼때 또는 반대의 경우에 보낸 메세지가 중간에 누구에 의해 변경되지 않고 그대로 전달되었느냐를 보장해주 는 것이다.

Message Confidentiality는 메세지를 일반 텍스트가 아닌 암호화 하여 중간에 누가 가로채 훔쳐보아도 무슨내용인지 알수 없게 하는 것이다.

Authentication(인증)은 클라이언트가 서버의 웹서비스를 요청할 때, 서비스를 쓸 수 있는 권한이 있는지 확인하는 것이다. 즉 가장 보편적인 방법인 아이디&패스워드를 확인하는 것이다.

 

Transport-Level Security

 1.Authentication

먼저 전송레벨 보안을 살펴보면,

전송레벨 보안은 전송 프로토콜 상에 (Http or Https) 보안을 이용하여 인증을 한다

 

사용자 삽입 이미지

 

위의 그림과 같이 HTTP의 헤더에 userid : password 의 인증정보를 넣어서 인증을 시도한다. 물론 위와같이 plain text로 아이디/패스워드가 전달되는 것이 아니라Base64인코딩을 한 후 헤더에 실어 보낸다. 물론 인증을 Username/Password 조합으로만 하는 것은 아니다 다른 여러가지 방법이 있다.

Transport-Level에서 할수 있는 다른 것들은 "Digest access authentication"도 있고X509 인증서를 이용한 방법도 있다. 방법만 다를 뿐이지 클라이언트에서 자신이 서버에서 인증된 즉 허가된 사람, 혹은 프로그램인지 증명하는 어떠한 것(Token)을 제공한다는 점은 동일한다.

 

 2. Message Confidential

다음은 웹서비스 호출을 위해 클라이언트에서 서버로 혹은 그 반대로 메세지를 보낼 때 중간에 다른 이들이 가로채도 읽을 수 없게 (읽어도 무슨내용인지 알수 없게) 암호하는 보안 방법을 알아보겠다.

예를 들어 내가 내가 네이버에 로그인을 하기 위하여 아이디/패스워드를 로그인 창에서 넣어서 네이버 서버로 보냈는데 누군가 중간에서 가로채 아이디/패스워드를 봐버린다면 내 개인 정보가 노출 될뿐만 아니라 나를 가장하여 범죄에 이용될 수도 있다. 따라서 중간에 혹 가로채더라도 그 정보를 해독할 수 없도록 암호화하는것이 바로 Message Confidential의 내용이다.

 

보통 암호화는여러가지 방법이 있겠지만 (사실 필자가 다음의 2가지 방법밖에 모른다 ㅎㅎ)대표적인 방법으로 대표적인 키를 이용한 방법으로 "Symmetric-key cryptography"와 "Public-key crpytograph" 2가지 가 있다 이 2가지 방법의 차의점은 암호화(Encrpytion), 복호화(Decrpytion)할 때 같은 키를 이용하는냐, 아니면 각각 다른 키를 이용하냐이다.

 

Symmetric-key cryptograph는 암호화, 복호화 할 때같은 키를 사용하는 방법이다. 이 방법은 Public-key 방법보다 구현이 쉽고? (이부분은 자세히 보지 않아 확실하진 않다), 성능상 이점이 있다고 한다. 그리고 보통 암호화 해서 메세지를 보내는게 같은 도메인이 아닌 Remote환경에서 많이 쓰기 때문에 키를 전달 하는 방법이 중요하다. 아무래도 공개적으로 키를 전달하기엔 위험할 것이다. 누군가 키만 확보를 하면 쉽게 메세지를 복호화하여 훔처 볼수 있기 때문이다. 이에 반해Public-key Crpytograph2개의 키를 사용한다. 2개의 키는 Private-Key, Public-Key인데 이름에서 알수 있듯이 Public-Key는 누구나 획득할 수 있는 키이고 Private-Key는 공개되면 안되는 키이다. Public-Key로 암호화 한것은 Private-Key로만 복호화할 수 있고, 그 반대도 마찬가지이다.

 

사용자 삽입 이미지

위의 그림과 같이 "I can read'라는 메세지를 Public Key를 이용하여 "dcd989b7103"과같은 메세지로 암호화하고 다시 수신측에서 Private Key로 메세지를 원래의 메세지인 "I can read"로 복호화한다.

이러한 메카니즘으로 Public key 암호화는 키를 상대방에 전달하기가 용의하다

 

Transport-Level에서 이 Confidential을 구현하기 위해서 SSL을 이용한다. SSL은 Public Key Cryptograph를 사용한다. SSL은 클라이언트와 서버간 서로의 Public key를 교환하고(SSL Handsaking), 그 Public Key로 메세지를 암호화 하여 보내고 Private Key를 이용해 메세지를 복호화 하는 일과 보안 방법중 마지막인 Identity를 보장하기위해 key로 메세지에 Signature를  추가하고 확인하는 일도 한다.

 

클라이언트에서 서버로 보내는 메세지만 암호화 하냐, 아니면 서버에서 클라이언트로 보내는 메세지 둘다 하냐에 따라 1-way SSL, 2-way SSL로 나누어 진다.

 

1-Way SSL

사용자 삽입 이미지

1-way SSL은 Client에서 Server로 보내는 메세지만 암호화 할 때 쓰인다. 이 때 서버측은 Private key/Public key를 셋트로 갖고 있어야 한다. 그리고 클라이언트가 서버로 메세지를 전달할려고 할 때 (웹서비스의 경우 Client에서 Web Service로 SOAP 메세지를 HTTPs로 전달을 할려고 할 때) 서버측에서 Public ker를 획득하고 그 키를 이용하여 메세지를 암호화 하여 보내면 서버쪽은 그 Public key와 같은 셋트인 Private Key를 이용하여 메세지를 복호화 한다.

 

2-Way SSL

사용자 삽입 이미지

 

2-way SSL은 양쪽 방향 메세지 모두 암호화 할 때 쓰이고, 서버, 클라이언트 각각 Private/Public key 셋트를 갖고 있어야 한다. 메세지를 보내기 전 서로의 Public Key를 획득하고 그 public key를 이용하여 요청(Request)/응답(Response) 메세지를 암호화 하고 Private Key를 이용하여 복호화 한다.

 

3. Message Identity

Message Identity란 송신측에서 보낸 메세지가 중간에 변조 되지 않고 수신측으로 전달 되는 것을 보장 하는 것이다. 예를 들어 내가 은행에 내 계좌에서 B라는 계좌로 10만원을 이체 하라고 했는데 누군가 중간에서 내 메세지를 가로채 C라는 계좌로 100만원으로 보내라고 바꾼다음 은행서버로 보냈다고 하면 보안상 아주 문제가 클 것이다. 따라서 보안에서 Messaeg Identity를 보장하는 것은 아주 중요한 일 중에 하나다.

 

Web Service에서 Message Identity를 보장하기 위해서 암호화 와 마찬가지로 SSL을 이용한다. (SSL자체가 Message Confidential과 Message Indentity를 보장하는 기술이다.)

Public Key를 교환하는 방식은 위의 방법과 동일하고 차의점은 Key를 이용하여 메세지를 암호화 하는것이 아니라 메세제에 Signature라는 값을 추가한다. 또한 Encrpytion할 때는 Public key를 이용하여 메세지를 암호화 하고 대응되는 Private key를 이용하여 복호화 하는데 반해 Signature는 Private Key를 이용하여 메세지에 Signature를 계산,추가를 하고 Public Key를 이용하여 그 Signature를 검증한다.

 

여기서 Signature란 어떠한 메세지와 키를 이용하여 만들 수 있는 유일한Hash값이다. 즉 명시된 특정 해쉬 함수와 키를 이용하여 해시 값을 구한게 바로 Signature이다 Private과 Hash함수로 구한 이 Sign(Signature)을 메세지 뒷부분에 추가 하여 보내면, 수신측에서 Public 키와 정해진 Hash함수를 이용하여 받은 메세지의 해쉬 값을 계산을 하고 보내온 해쉬 값과 비교하여 중간에 메세지가 변조되었나 안되었나를 판단하는 것이다. 판단 후 메세지에서 해쉬값(Signature)를 떼어 낸뒤 상위 레이어에 원래 메세지를 전달한다.

사용자 삽입 이미지
사용자 삽입 이미지

 

Conclusion

Web Service 보안 중 Transport-Level Security는 Http의 인증 기능과 SSL/TLS의 PKI 를 이용한 Encryption, Signature 기능을 이용하여 보안을 구현을 한다.

하지만 이 방법은 실제 환경에서 사용하기엔 부족한다. 이 그 이유는

첫째, SSL은 Point-to-Point 까지 보안만 보장을 한다.

둘째, SSL은 All or Nothing 방식으로 보안처리를 한다.

먼저 Point-to-Point 방식은

사용자 삽입 이미지

위의 그림에서 보는 바와 같이 클라이언트 - 서버 2개의 노드의 구성이 아닌 3개 이상의 노드로 구성이 되어 있을 때 Message가 Source에서 Target까지 계속 암호화가 유지되는 것이 아니라 SOURCE <->NODE A구간 과 NODE A <-> TARGET 구간이 각각 SSL을 이용한 보안 상태가 유지된다는 것이다. 따라서 중간의 NODE A에서 Message 내용이 노출이 된다는 문제가 있다.

 

또 다른 All or Nothing 은 SOAP 메세지의 일부분만 암호화, 사인을 남기고 싶은데 SSL은 메세지의 전체를 암호화 하거나 아니면 안하던가 둘중에 하나만 지원한다는 것이다. 따라서 효율적인 보안처리를 할 수 없는 문제가 있다.

 

이를 보완하기 위한 방법이 Message-Level Security이다. 이 것에 대한것은 다음 글로 미뤄야 겠다

또한 Transport-Level Security를 이용한 웹서비스 구축 및 클라이언트 작성도 다음 글에서 이어 쓰겠다.

 

PS) 휴 간단하게 한번에 다 쓸려고 했는데 쓰다보니, 넘 길어졌다. 한번에 다쓰긴 어려울 것 같다 한 3~4개는 써야 다 쓸 수 있을 듯...

3 Comments
댓글쓰기 폼