보안 문제 해결이 급선무 … 통합 기능 갖춘 곳 거의 없어
상태바
보안 문제 해결이 급선무 … 통합 기능 갖춘 곳 거의 없어
  • 데이터넷
  • 승인 2007.11.01 00:00
  • 댓글 0
이 기사를 공유합니다

Strategic Security / SOA 보안
SOA(Service Oriented Architecture)를 비즈니스 파트너에게 개방하게 되는 위험을 감수할 준비가 돼 있는가? 더군다나 SOA 보안 표준의 미성숙함으로 인해 상호운용성에 대한 걱정도 더욱 심해지고 있는 형편이다. 다중 기업을 포함하고 있는 대형 웹 서비스 네트워크를 잠그려면, 모든 사람이 기술들과 더불어 보안 정책에도 동의를 해야 하는 형편이다.

위험한 여행, “꼭 해야 하나”
보안 문제 해결이 급선무 … 통합 기능 갖춘 곳 거의 없어

웹 서비스는 언제나 조직들간에 데이터를 공유하기 위한 하나의 수단으로 선전돼 왔다. 기업에서는 고객, 파트너 및 공급업체에게 내부 시스템을 선택적으로 개방할 수 있으며, 한 때는 인간의 개입을 필요로 했던 트랜잭션을 자동화할 수 있다. 대부분의 기업들이 아직까지는 웹 서비스를 방화벽 뒤에서 안전하게 유지하면서 깔끔히 처리해 오긴 했지만, 서비스 지향형 아키텍처(Service Oriented Architecture; SOA)의 성장과 웹 2.0의 등장으로 이러한 상황은 바뀔 것 같다.
내부의 서비스를 웹으로 공개하는 위험을 과연 감수할 만한 가치가 있을까? 더군다나 SOA 보안 표준의 미성숙함으로 인해 상호운용성에 대한 걱정도 더욱 심해지고 있는 형편이다. 다중 기업을 포함하고 있는 대형 웹 서비스 네트워크를 잠그려면, 모든 사람이 기술들은 물론, 심지어 보안 정책에도 동의를 해야 한다. 파트너 회사의 직원이 취약한 패스워드로 시스템에 액세스한다면 당신 회사 직원에게 생체인식 기술이나 물리적 토큰을 사용하도록 요구하는 게 아무 소용이 없다.

SOA 보안 시장 유동적
SOA 보안의 구성 요소들을 구입하기 이전에 먼저 해야 할 일들이 있는데, 그 이유는 이 시장이 유동적이기 때문이다. 모든 것을 고려할 때 우리가 목격하고 있는 움직임은 결과적으로 IT에게는 좋은 소식이다. 왜냐하면 이는 곧 더 많은 선택을 의미하며, 접해야 하는 업체 수가 줄어들 수도 있기 때문이다. 하지만 이것은 또한 구매에 대한 의사 결정을 훨씬 더 복잡하게 만드는 것이기도 하다.
예를 들어 인터넷에 노출되는 웹 서비스는 XML 방화벽을 필요로 하는데, 이것은 SOA 보안 게이트웨이라고도 부른다. 하지만 이 부문의 제품은 계속되는 SOA 통합 덕분에 현재 사라지고 있는 추세다.
한편, XML 방화벽의 기능성이 관리 플랫폼에서부터 코어 스위치에 이르는 모든 것에 투입되면서, 어떤 종류의 제품을 사용해야 하는지는(심지어 하드웨어를 사용해야 하는지 소프트웨어를 사용해야 하는지와 같은 기본적인 의사결정까지도) 각 기업 웹 서비스의 규모와 예상 성장률뿐만 아니라 기존의 어떠한 SOA 인프라에 따라서도 달라지게 될 것이다. 여기다 가상화까지 추가되면 상황은 더욱 복잡해진다.
암호화와 인증을 둘러싼 논의는 더욱 거세지고 있는데, 왜냐하면 이들이 하나의 조직에 의존하지 않기 대문이다. 웹 서비스 엑스트라넷에 있는 모든 사람이 같은 기술을 사용해야 할 필요가 있으며, 현재 몇 가지 표준들이 경합을 벌이고 있다.
가장 큰 충돌은 아이덴티티 관리를 둘러싼 것으로, 이는 한 회사의 시스템에 로그온 된 사용자나 프로세스가 파트너 회사 시스템을 사용할 수 있게 허용되도록 보장하는 복잡한 절차다. 현재 서로 호환은 불가능하고 상당 부분 같은 기능을 하는 두 가지 표준이 나와 있다. 첫째는 SAML(Security Assertion Markup Language)로, 이것은 마이크로소프트를 제외한 거의 모든 회사에 의해 지원되고 있다.
마이크로소프트는 나중에 나온 WS-피더레이션(WS-Federation)을 선호하고 있는데, 이 표준은 다른 웹 서비스 표준과 보다 긴밀하게 연결이 된다. 두 가지 모두 XML을 사용하긴 하지만 이들은 서로 호환이 되지 않으며, 이는 곧 퍼블릭 웹 서비스가 있는 기업에서 두 가지 모두를 지원하거나, 혹은 보안 웹 서비스를 이용하는 회사의 모든 비즈니스 파트너들로 하여금 같은 표준을 선택하게 해야 한다는 얘기다. 이제 이 수정 구슬을 얻기가 그리 만만해 보이지는 않을 것이다.

SOAP와 REST
모든 웹 서비스 보안 기술은 XML 인크립션(Encryption)과 XML 시그너처(Signature)를 기반으로 하는데, 이들은 암호화된 데이터와 전자 서명을 XML 문서나 메시지 안에 임베딩하는 데 쓰이는 W3C 표준들이다. XML 인크립션은 꼭 전체 메시지를 암호화하는 것은 아니기 때문에 IT에서는 선택을 할 수가 있다. 즉 주민등록번호나 신용카드 번호 같은 사적인 데이터는 암호화가 될 수 있으며, 반면 덜 민감한 구성요소나 SOA 메타 데이터는 그대로 전송이 된다. 문서의 서로 다른 부분들도 또한 다른 키를 이용해 암호화가 될 수 있기 때문에 의도했던 수신자에 의해서만 읽힐 수가 있다.
이들의 단점은 전체 XML 메시지에 암호화된 데이터를 흩어놓음으로 인해 상호운용성 문제가 발생할 수 있는데, 그 이유는 참가자들이 암호화된 데이터가 메시지 내 어디에 배치돼야 하는지, 어떤 요소들이 암호화돼야 하는지, 그리고 어떤 키가 교환될 수 있는지 같은 문제들에 대해 미리 동의를 해야 하기 때문이다. 이를 돕기 위해 오아시스(OASIS: Organization for the Advancement of Structured Information Standards)는 웹 서비스 내에 XML 시큐리티와 XML 인크립션을 적용시키기 위한 표준인 WS-시큐리티를 만들었다.
WS-시큐리티는 WS-* 표준들 가운데 가장 성숙한 편에 속하며, 거의 모든 웹 서비스 및 SOA 업체들로부터 지원되고 있다. 가장 큰 취약점은 다른 모든 WS-* 표준과 마찬가지로 SOAP
를 필요로 한다는 것이며, 이것은 REST(Representational State Transfer, SOAP를 사용하지 않는 XML 웹 서비스를 설명하는 방식)를 돌리는 웹 서비스로 비즈니스를 하는 사람에게는 적용되지 않는다.
SOAP(Simple Object Access Protocol) 대신 REST를 사용하는 가장 큰 이유는 단순성이며, 따라서 대부분의 REST 사용자는 SSL을 고수하고 있다. REST는 HTTP를 필요로 하며 점 대 점 링크용으로 사용되는 경향이 있기 때문에 SSL 터널로 충분한 경우가 많다. REST에 메시지 레이어 보안을 적용시키고자 하는 기업에서는 자체 프로토콜과 데이터 포맷을 만들 필요가 있을 것이다.
모든 비즈니스 파트너를 함께 풀링하고, REST용의 맞춤식 보안 XML 포맷을 디자인하는 것은 대부분의 기업에서 받아들이기 힘든 일이기 때문에, WS-시큐리티의 존재는 SOAP에 대한 강력한 논거가 될 수 있다. 하지만 아마존닷컴이나 구글 같은 대형 웹 서비스 사업자들은 REST를 잠그는 자체적인 방식을 개발하는 데 성공해 본질적으로 공유되는 비밀이라고 할 수 있는 보안 토큰을 사용하고 있다.
이들은 비록 전용이긴 하지만 사용자들 사이에 매우 인기가 높다. 아마존은 또한 WS-시큐리티와의 SOAP 인터페이스도 제공하고 있지만, 자사 고객들이 대다수가 REST를 선호하고 있다는 사실을 발견했다. 대부분의 아마존 사용자들은 전체 SOA를 구축하지 않고 아마존 서비스에 액세스하고 있을 뿐이며, 따라서 SOAP의 복잡성이 필요치 않다.

아이덴티티 연합
WS-시큐리티는 SOAP 메시지를 암호화하고 서명하는 데 도움이 되긴 하지만 AAA(Authentication, Authorization, Accounting)나 보안 정책에 대해서는 아무런 언급이 없다. 이들은 다른 표준들에 의해 처리가 되는데, 이러한 표준들은 보안 영역 안에서 모두 WS-시큐리티를 기반으로 한다. 이러한 표준들의 대부분은 결국 ESB(Enterprise Service Bus)와 웹 서비스 관리, 두 영역의 모든 업체들에 의해 지원이 되겠지만, 아직은 사용자에게 큰 영향을 미치기에는 너무나 새로운 것들이다.
예외적인 것으로 연합 아이덴티티(federated identity)가 있는데, 여기서는 상대적으로 새로운 WS-피더레이션(WS-Federation)과 WS-트러스트(WS-Trust)가 역시 오아시스에서 내놓은 기존의 표준인 SAML 2.0과 경합을 벌이고 있다. 연합 아이덴티티는 액세스되는 자원으로부터 인증을 독립시킴으로써 SSO(Single Sign-On)을 가능하게 하는 것을 목표로 한다.
사용자는 자신에게 다중 자원들로 액세스하는 데 사용할 수 있는 증명서(credential)를 주는 아이덴티티 사업자에게 로그온을 한다. 증명서는 SAML에서는 ‘검증(assertion)’, WS-트러스트에서는 ‘토큰(token)’으로 불리며, 전자 인증서와 비슷하다. 즉 이것은 사용자의 아이덴티티를 보증하고 사용자가 언제 어떻게 인증되는지와 같은 정보를 추가한다. SAML은 전체 SSO 프로세스를 다루는 반면 WS-*스택은 이것을 두 가지 표준으로 나눈다. WS-트러스트는 첫 인증과 토큰 발급을 처리하며, 그런 다음 이러한 토큰들을 이용해 다른 자원으로 액세스하는 부분은 WS-피더레이션의 몫이다.

병화벽은 어디로
한 가지 실질적인 큰 차이점은 SAML은 XML 인트립션과 XML 시그너처를 직접적으로 사용한다는 것인데, 이는 곧 SAML이 REST와 작동이 가능하다는 의미며, 이에 반해 WS-피더레이션은 SOAP를 필요로 한다.
일부 다른 표준 전쟁들과는 달리, 이것은 단순히 마이크로소프트와 나머지 다른 업체들의 싸움이 아니다. 마이크로소프트는 IBM과 WS-피더레이션을 만들었으며, IBM은 또한 SAML의 큰 후원자이기도 하다. 그리고 SAML 군단에 있는 다른 모든 업체들은 여기에 대한 수요가 있을 경우 WS-피더레이션을 지원한다고 약속했다. 장기적으로 볼 때는 두 가지가 모두 사용될 가능성이 많으며, 마이크로소프트와 SOAP 환경에서는 WS-피더레이션이, REST 웹 서비스에서는 SAML이 사용될 것이다.
공중 인터넷에서 방화벽은 웹 서비스의 가장 첫 동력 가운데 하나였다. 조직에 따라 보안 정책도 다르긴 하지만 거의 모든 조직들이 포트 80을 개방시켜 둘 필요가 있으며, 따라서 업체와 표준 기구들은 HTTP에서 실행되는 텍스트 기반 프로토콜에 끌렸다. 그리고 같은 이유로, 공격자와 멀웨어도 그렇게 됐다.
결과적으로 인터넷에 웹 서비스를 퍼블리싱하는 회사들은 전통적으로 애플리케이션 보안 게이트웨이를 사용해 왔으며, 이들은 애플리케이션 레이어의 문서를 읽고 이해할 수 있는, 그리고 잠재적인 공격을 걸러낼 수 있는 어플라이언스들이다. 이러한 장비는 언제나 ‘XML 방화벽’으로 불리긴 했지만 선량한 이들은 단순한 XML 이상의 것을 이해할 수 있을 것이다. REST를 이용하는 웹 서비스는 HTTP 헤더나 URL 내에 얼마간의 정보를 인코딩할 것이며, 브라우저 기반의 RIA 개발자들은 XML을 너무 부풀려졌다고 보고 JSON(JavaScript Object Notation)이나 명문(plain text)을 선호하는 경우가 많다.
보안 게이트웨이는 방화벽 이상이며 인증, 권한부여 및 어카운팅을 처리하는 SOA 관리 스위트에 있는 모든 기능들을 더해준다. 웹 서비스가 엔터프라이즈 SOA에 대한 하나의 인터페이스로 작동을 할 때, 보안 게이트웨이는 JMS와 HTTP간의 변환을 필요로 하는 경우가 많은데 이는 대부분의 SOA에서 진정한 웹 서비스를 내부적으로 사용하지 않기 때문이다.
외부 세상으로 접속할 일이 없다면 방화벽을 통과할 수 있는 능력은 매우 부정적인 것이다. 게다가 게이트웨이는 우선 해독하지 않고는 문서를 효과적으로 스캐닝할 수 없기 때문에, 대부분은 또한 SSL이나 WS-시큐리티, 혹은 SAML을 이용해 암호화와 인증을 해야 하는 책임도 지고 있다. DPI
(Deep-Packet Inspection)와 공격을 인식하는 데 요구되는 XML에 대한 이해도 또한 보안 게이트웨이를 XML 변형이나 라우팅에 유용하도록 만들어 주며, SSL이나 XML 가속화 전문 하드웨어 덕분에 이 부분에 있어 관리 소프트웨어보다 나은 경우도 많다.
대부분의 보안 게이트웨이는 여전히 스탠드얼론 제품들로, 전통적인 방화벽과 상당 부분 유사하게 설치되며, 전문 업체들에 의해 판매되고 있다.
처음 등장한 보안 게이트웨이의 업체들 가운데 현재 네 곳이 인수가 되었는데, 사베가(Sarvega)는 인텔에 의해, 넷스케일러(NetScaler)는 시트릭스(Citrix)에 의해, 그리고 데이터파워(DataPower)는 IBM에 의해, 리액티비티(Reactivity)는 시스코시스템즈에 흡수됐다. 다른 업체들이 맞춤 ASIC가 아니라 표준 CPU를 중심으로 한 XML 소프트웨어나 어플라이언스를 구축하는 데 도움을 주기 위해 사베가 기술을 이용하는 인텔의 제외하고 모든 업체들은 여전히 게이트웨이를 판매하고 있다. 하지만 이들이 제품을 취급하는 방향은 다르다.
시트릭스의 넷스케일러 어플라이언스는 XML 방화벽과 AFE(Application Front End)를 기능적으로 통합시켰는데, 이것은 시스코에서 자사의 애플리케이션 컨트롤 엔진 제품 라인에 리액티비티를 통합시킴으로써 얻고자 계획하고 있는 것이기도 하다. AFE는 또한 네트워크 에지에 놓여 SSL을 가속화시키기 때문에, 이러한 통합은 고객에게나 신규 시장으로의 진입을 원하는 AFE 업체, 모두에게 큰 효과를 낼 수 있다. F5는 이미 XML 방화벽을 추가하겠다고 발표하고, 내부적으로 개발을 했으며, 경쟁자들도 곧 그 뒤를 따를 것 같다.

자리잡는 가상화
레이어 7, 보델(Vordel) 및 엑스트라다인 등 다른 독립 게이트웨이 업체들은 반대 쪽, 즉 소프트웨어와 가상화 방향으로 이동하고 있다. 보델과 엑스트라다인은 언제나 자신들의 게이트웨이를 전담 블레이드 서버에 설치되는 소프트웨어로 배포해 왔다. 이들은 가상 어플라이언스를 환영하고 있으며, 레이어 7과 보델은 이미 VM웨어에서 돌아가는 소프트웨어 버전을 판매 중이다.
가상화로 인한 성능 감소는 가상 어플라이언스가 아직 전용 서버를 따라가지 못한다는 의미기 때문에, 보델은 이제 자사의 가상 버전을 생산보다 테스팅과 통합에 목표를 두고 있다. 레이어 7은 전용 XML 및 SSL 실리콘을 가진 맞춤 어플라이언스 업체로 출발했기 때문에, 가상화를 아직 전용 하드웨어 비용을 정당화할 중소형 고객을 위한 진입 지점으로 보고 있다. 하지만 ‘소프트웨어 전용’이 지금은 예산을 염두에 둔 주문이라 하더라도 앞으로 곧 모든 규모의 기업에서는 가상 어플라이언스가 사용될 것이다.
가상 기계의 성능은 급속이 향상되고 있으며, 가상화가 가져다 주는 유연성은 SOA에서 실질적으로 쓸모가 있다. 신규 서비스들이 배포되고 재사용됨에 따라 SOA 인프라는 적응할 필요가 있으며, 가상화는 하드웨어 역할(role)들간에 신속히 재할당될 수 있게 해준다. 하지만 하드웨어 자원을 공유하기 위해서는 다른 서버들이 가상화될 필요가 있으며, 이로 인해 보안 문제가 야기될 수 있다. 보고된 VM웨어 보안 취약성은 몇 되지 않지만, 다중 VM을 관리하는 데 따르는 복잡성으로 인해 트래픽이 우발적으로 방화벽을 우회하게 될 가능성이 더 많다.
중복되는 기능성이 너무 많기 때문에 보안 게이트웨이는 웹 서비스 관리 소프트웨어와 통합되고 있다. 데이터파워와 리액티비티는 둘 다 인수되기 이전에 관리 시장에 발을 들여 놓았으며, 최소한 다른 하나의 방화벽 업체가 같은 길을 가려고 계획 중이다. 관리 업체들은 아직 풀 XML 방화벽을 추가함으로써 반격을 가하지 않고 있는데, 이는 주로 이들의 소프트웨어가 에지에서보다는 전체 SOA에서 실행되도록 만들어졌기 때문이다.
SSL의 인기로 인해 SSL 가속화는 보안 게이트웨이에서 유비쿼터스가 됐으며, 심지어 가상 어플라이언스 업체들조차 SSL 가속기 카드가 있는 하드웨어를 지원하고 있다. XML 가속화는 전용 XML 칩을 포함하고 있는 IBM, 시스코 및 레이어 7 제품들을 제외하고는 훨씬 드물며, IBM에서는 자체 구축을 하고 시스코와 레이어 7은 타라리(Tarari)에 의존하고 있다. 이는 부분적으로는 인텔에서 사베가 기술을 사용하기 때문이지만(레이어 7은 하드웨어 시장이 점차 소프트웨어로 바뀔 것이라고 믿고 있다) 주된 원인은 아직 애플리케이션 레이어 가속화에 대한 수요가 많지 않기 때문이다.
XML 가속화는 주로 SOAP나 SAML 메시지 같은 비교적 긴 XML 문서를 전송하는 웹 서비스에서 유용하다. 이것은 브라우저 기반 애플리케이션을 지원하고자 만들어진 웹 서비스에서는 많이 사용되지 않는데, 그 이유는 이들이 각 세션에서 비교적 얼마 안되는 데이터(TCP/IP와 HTTP 헤더로 감싸진 상태로 하나의 XML 엘러먼트나 JSON 객체)를 전송하기 때문이다. 자바스크립트와 플래시는 사용자가 동작을 수행할 때마다 전체 페이지를 다시 불러올 필요가 없기 때문에 대부분의 웹 2.0 애플리케이션에는 정적 XHTML을 이용해 구축된 비슷한 애플리케이션들보다도 애플리케이션 레이어 트래픽이 적게 포함돼 있다.
하지만 RIA들은 웹 서버의 짐을 쉽게 덜어주지 않을 것이다. 이들은 XML 트래픽을 줄여줄지는 모르지만 RIA는 서버가 처리해야 하는 HTTP 접속 수를 대폭 늘일 수 있다. 대부분의 RIA는 사용자가 링크를 클릭하기를 기다리는 대신 실시간으로 돌아가며, 몇 초마다 계속 새 접속을 초기화한다. 이로 인해 과부하된 서버는 SSL 가속화나 다른 AFE 기술들(부하분산 및 HTTP 압축)을 활용할 수 있는 경우가 많다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.