주동력은‘애플리케이션 통합·B2B 이행’… 가장 큰 장애물은 ‘보안’
성숙한 표준의 결핍 또한 문제가 된다. 최근 피어스톤 리서치(Peerstone Research) 설문조사에서는 기업의 52%가 미성숙한 표준이 큰 장애물이라고 말했으며, 나머지 응답자들 중 43%는 이것을 웹서비스의 배치에 있어 작지만 심각한 장애물이라고 답했다.
하지만 이 모든 장애물들과 빡빡한 예산에도 불구하고, 일부 기업들을 웹서비스에 깊이 빠져들게 하는 두 가지 핵심 요소들이 있다.
첫 번째, 애플리케이션 통합은 특히 EAI(Enterprise Application Integration) 면에서 가장 많은 기업 마인드를 점유하고 있다. 전통적인 애플리케이션 통합에는 EAI 제품에 막대한 투자를 필요로 할 수 있다. 이런 애플리케이션들은 애플리케이션을 비즈니스 프로세스에 통합하는 데 필요한 시간을 줄여주지만, 교육과 개발자 자원에, 혹은 값비싼 통합 컨설턴트에 막대한 투자를 필요로 한다. 이와 대조적으로, 웹서비스를 사용할 경우 통합 애플리케이션에 포함된 돈과 시간을 대폭 줄여줄 수 있다.
웹서비스는 원래 플랫폼과 언어 모두에 불가지론적이기 때문에, 개발자는 통합되고 있는 애플리케이션의 기술적인 세부 사항에 대해 알 필요가 없으며, 새로운 프로그래밍 언어를 배우거나 시스템의 API 문서를 들여다보느라 몇 시간씩 보내지 않아도 된다.
사실, 웹서비스를 지원하는 대부분의 개발 환경은 개발자가 웹서비스 인터페이스를 제공하는 애플리케이션의 WDSL(Web Services Definition Language) 파일을 로딩하고 클라이언트 인터페이스를 자동으로 생성함으로써, 애플리케이션 비즈니스 로직 추가에 역점을 두는 데 더 많은 시간을 쓸 수 있게 해주는 메커니즘을 제공한다.
두 번째 동력은 웹서비스가 B2B 관계를 이행 및 배치하는 데 필요한 시간을 대폭 줄여줌으로써 기업간 상호작동을 수월하게 해줄 수 있다는 점이다. 공급업체가 웹서비스 인터페이스를 지원한다는 것을 전제로 할 경우, 개발자는 WSDL을 다운로드하고, 클라이언트를 생성하며, 원격 시스템을 비즈니스 프로세스에 통합시킬 비즈니스 로직을 만들 수 있다. 이번 호에서는 웹서비스 플랫폼과 이들의 개발 환경을 분석해 보았으며, 다행히도 이러한 자동화가 헛된 꿈은 아니라는 사실을 알 수 있었다.
웹서비스 배후의 가장 큰 소득은 비즈니스의 민첩성(agility), 즉 변화하는 경제적 환경에 신속하고 비용 효율적으로 반응할 수 있는 능력이다. 예를 들어, 오늘날 기업들은 비즈니스 작업을 수행하는 애플리케이션의 수가 얼마나 되든 거기서 같은 컴포넌트를 이용하고 있을 것이다. 만약 작업이 바뀌면 그 특정 컴포넌트를 바꿔야할 뿐만 아니라, 그 컴포넌트에 의존하고 있는 모든 애플리케이션들을 재배치해야 한다. 하지만 웹서비스가 있으면 하나의 컴포넌트만 바꾸면 된다.
보안 문제
업계 전문가들은 보안이 하나의 큰 불안 요인이라는 데 입을 모으고 있다. XML 및 웹서비스에 주력하는 리서치 회사인 잽씽크(ZapThink)의 선임 분석가, 로널드 슈멜쩌는 “보안은 오늘날 웹서비스 채택에서 가장 중요하고 시급한 장애물”이라며 “이것은 단지 XML이 텍스트 기반이고 HTTP와 같은 전송 프로토콜을 통해 전송되기 때문만이 아니다. SSL과 같은 일반적인 암호화 기술로 이 문제는 해결될 수 있지만 보다 큰 문제는 인증과 권한부여”라고 말했다.
이것이 바로 문제의 핵심이다. WSDL은 내부 업무 공정과 데이터 스트럭처에 인간이 읽을 수 있는 포인터를 제공하는데 이것은 아마도 신용카드 번호와 인증 번호, 및 제품번호와 같은 돈 되는 정보들을 유출시킬 수 있다. 하나의 WSDL 파일만 있어도 누구든 당신이 사용할 수 있는 서비스가 무엇인지를 확인할 수 있으며, 불행히도 여기에 액세스할 수 있는 방법까지 알 수 있다. 이렇게 쉽게 누출되는 정보들 때문에 반드시 권한이 부여된 사용자에 의해서만 서비스가 시작되도록 해야 한다.
B2B 웹서비스 또한 고려해야 한다. 아무나 구매 주문이나 송장을 제출할 수 있게 되기는 원치 않을 것이다. 액세스에 대한 강력한 통제권을 가지고 자신의 웹서비스를 누가 이용하고 있는지를 감시할 수 있는 수단을 갖추는 일이 중요하다.
SSL은 보통 전송하는 동안 데이터를 감시할 수 있는 최선의 방안으로 받아들여지고 있지만 이것이 만병통치약은 아니다. SSL은 트랜잭션이 전송되고 있는 중에만 이것을 보호할 수 있다. 웹서비스 소비자를 인증할 수 있는 클라이언트측 인증서를 이용하지 않는다면 SSL은 필요한 수준의 보안을 제공할 수 없게 된다.
어떤 것들은 아직 진행 중이긴 하지만 이런 보안 문제를 해결하기 위해 몇 가지 표준들이 나오고 있다. WS-시큐리티, XML-SIG 및 XML-인크립션(XML-Encryption)은 이런 것들 중 가장 초창기 사양에 속한다. WS-시큐리티(현재 오아시스 산하)는 메시지 레벨 보안 이행에 사용될 수 있는 SOAP(Simple Object Access Protocol) 익스텐션을 소개한다. WS-시큐리티의 경우는 기본적인 웹서비스 보안을 위한 기본틀을 규정하는 데 목표를 두고 있으며, 하나의 완벽한 보안 솔루션을 포함하고 있다고는 볼 수 없다. 단순히 보안 시스템 구축을 돕기 위해 만들어진 WS-시큐리티는 X.509 인증서와 같은 다른 보안 제품들과 함께 사용될 경우에만 성공할 수 있다.
XML-인크립션은 교환되고 있는 실질적인 데이터를 보안하기 위한 메커니즘을 규정하며, 필요한 경우 엘리먼트(element) 레벨까지 내려간다. 이 표준을 사용하면 작은 하나의 데이터 엘리먼트들까지 암호화할 수 있다. 그리고 XML-SIG는 개별적인 엘리먼트나 전체 XML 문서가 부인방지 기능(nonrepudiation)을 위해 전자적으로 서명될 수 있는 방법을 규정하고 있다.
하지만 이런 어떤 표준도 개별적인 서비스 보안의 실질적 문제를 해결해주는 것은 없는데, 그 이유는 어느 것도 무허가 사용자가 서비스를 시작하는 것을 막아주지 못하기 때문이다. 이런 종류의 보안을 위해서는 코어 레벨에서의 통합이 필요하며, 이상적으로 볼 때는 서비스 레벨에서 웹서비스를 보안하도록 설계된 외부 시스템에 의해 관리될 필요가 있다. 데이터파워(DataPower), 리액티비티(Reactivity) 및 웨스트브리지 테크놀로지즈(Westbridge Technologies) 등과 같은 어플라이언스와 소프트웨어들은 기업 내 웹서비스로의 단일 진입지점을 제공한다.
이런 방안은 웹서비스가 기존의 보안 인프라를 통해 보안될 수 있는 하나의 중앙 지점을 제공한다. 게다가 웹서비스의 사용에 대한 세부적인 로그를 유지할 수 있는 능력도 갖추게 된다. 웹서비스 플랫폼도 필요한 수준의 세부 정보를 제공할 수 있지만, 여기에는 보통 기반 코드 변경이 수반된다.
웹서비스 보안은 다음과 같은 네 가지 범주로 분류된다.
>> 보안 전송 : 엿보는 시선들로부터 데이터 은폐
SSL: 네트워크 레벨
XML-인크립션: 데이터 레벨
>> 데이터 무결성 : 데이터가 전송 중 변경되지 않게 보장
XML-인크립션: 데이터를 암호화하고 체크섬을 이용해 무결성 보장
XML-SIG: 엘리먼트나 문서에 서명을 하고 부인방지 기능을 제공
>> 인증 : 클라이언트 신원확인
WS-시큐리티 : 토큰 기반 신원확인
SSL : 클라이언트측 전자 인증서
>> 권한부여 : 서비스로의 클라이언트 액세스 결정
WS-시큐리티 : 메시지 레벨 액세스, 토큰는 일부 조직에서와 같은 연방 규정 위배 가능성을 포함해 장애의 가능성이 크기 때문에, 웹서비스 인프라를 구축할 때는 처음부터 보안을 염두에 두어야 한다.
