서비스 지향 아키텍처/웹 서비스(SOA/WS)의 도입이 확산됨에 따라 이와 관련된 보안 문제도 떠오르고 있다. 전사적으로 SOA/WS의 도입을 보호하고 관리하는데 있어 발생하는 문제가 무엇이고 그 해결책은 어떤 것이 있는지 살펴본다. <편집자>
연재순서
1회 : SOA로의 진입
2회 : SOA 보안에 대한 이해 (이번호)
3회 : 다양한 산업에 대한 SOA 적용
조상원 //
한국CA 보안시니어컨설턴트
Sangwon.cho@ca.com
소수의 웹 애플리케이션만을 보유하던 시대가 지나자 웹 애플리케이션에 보안을 직접 적용시키는 사일로 기반 접근 방식은 확장이 불가능할 뿐만 아니라 관리도 안전하지 않고, 비용도 많이 든다는 것이 입증되면서 효용성을 잃어 갔다.
이에 따라 1990년대 들어 인증과 권한부여, 감사, 사용자 관리 기능을 중앙화한 관리 형태와 보다 확장 가능한 보안 인프라(현재 기업의 모든 웹 애플리케이션에서 사용될 수 있는 방식)로 외부화(externalize)할 수 있는 새로운 계층의 보안 애플리케이션이 등장했다. 이와 동시에, LDAP이라 불리는 사용자 디렉터리를 위한 표준 기술 또한 확산됐다. LDAP 기술은 외부화된 보안 인프라를 확대하는데 중요한 레포지토리(Repository)를 중앙화해 제공하는 것이다.
웹 애플리케이션과 SOA/WS 기반 애플리케이션 간에는 유사점이 많다. 둘 다 내부 사용을 위한 인트라넷이나 비즈니스 파트너를 위한 엑스트라넷에서 모두 구축될 수 있다. 더 나아가 소비자들은 위한 공중 인터넷에서도 둘 모두 사용이 가능하다.
웹 애플리케이션과 SOA/WS 기반 애플리케이션의 가장 큰 차이점은 SOA에서는 사용자가 브라우저를 띄워 웹 페이지를 보는 사람이 아니라 XML이나 WDSL, SOAP의 언어로 대화하는 또 다른 기기가 될 수 있다는 것이다. 하지만 보안과 관련된 문제는 기본적으로 동일하며, 유사한 보안 관리 방법을 사용해 해결할 수 있다.
보안 문제 해결이 가능한 솔루션을 알아보기 전에 SOA/WS의 보안 요구 사항을 좀 더 자세히 살펴보자. 대부분 전통적인 웹 애플리케이션의 보안 요구 사항과 일치하지만 몇 가지 차이점도 있으며, 대표적인 사항은 다음과 같다.
SOA/WS 기반 애플리케이션의 보안 요구 사항
● 위협/멀웨어 방지 - XML 트래픽은 악의적인 네트워크 트래픽을 목적지까지 운반하는데 사용 가능하다는 점에서 웹 트래픽이나 이메일 트래픽과 차이가 없다. 다른 형태의 트래픽에서와 마찬가지로, 들어오는 XML 트래픽 모두를 네트워크 경계나 DMZ 등에서 스크린 해 멀웨어가 없는지, 혹은 바이러스나 서비스 거부 등 비즈니스 서비스를 향한 공격이 없는지 확인하는 방법이 최선이다.
● 인증 - 서비스에 액세스하려는 사람이 누구인가? 그 대상자가 컴퓨터 프로세스이건 웹 서비스이건, 승인을 하기 전에 요청자의 신원을 확인해야 한다. 이러한 승인 과정 없이는 누구도 웹 애플리케이션에 접근해서는 안 되며 이는 SOA/WS 기반의 애플리케이션에서도 마찬가지이다.
● 인가 - 서비스 사용자를 승인했다면 웹 서비스에 대한 사용 수준을 정해야 한다. 어떤 서비스에 접근을 허용할 것이며 어떤 데이터에 사용을 허가할 것인지, 어떤 트랜잭션이나 비즈니스 기능을 사용하도록 할 것인지 등에 대한 권한을 부여해야 한다. 웹 포털에서 사용자에게 특정 기능을 사용하도록 권한을 제공하듯이 웹 서비스의 제공도 서비스 사용자가 내부이건 외부이건 상관없이 권한을 부여해야 한다.
● 감사와 보고 - 정보 누출 등의 문제가 발생할 경우에 대비해 모든 트랜잭션에 대한 로깅과 비즈니스 운영에 대한 엄격한 모니터링을 해야 한다는 법적 규정을 감안해 볼 때, SOA/WS 환경은 각 트랜잭션을 추적해야 하며, 법적으로 충분한 방식으로 비즈니스 활동을 재구성해 줄 수 있어야 한다. 이와 동일하게, 비즈니스 활동에 대해 전사적인 보고를 제공하는 것도 중요하다.
● ID(Identity) 관리 - 기업들이 현재 전통적인 IT 아키텍처에서 관리하는 방식과 마찬가지로 SOA/WS 기반의 애플리케이션에 있어 ID, 인증정보 및 권한 역시 관리해야 한다. 웹 서비스는 종종 사용자나 다른 애플리케이션 또는 프로세스로서 활동하는 경우가 많기 때문에 싱글사인온(SSO), 인증정보의 전달 및 접근 권한 등은 SOA/WS 환경을 안전하게 확장하는데 매우 중요하다.
● 전사적 관리 및 정책 관리의 중앙화 - SOA/WS 기반의 접근 방법을 통해 이용 가능한 잠재적인 서비스는 헤아릴 수 없을 정도이기 때문에, 수많은 SOA 기반의 애플리케이션 운영에 대한 전사적인 전략을 수립해야 한다. 더욱이, 비즈니스 서비스에 영향이나 변경을 주지 않고, 비즈니스 요구 사항에 따라 신속히 변경이 가능한 중앙화된 보안 정책을 수립하고 집행하는 것이 중요하다.
● 세션 관리 - 웹 애플리케이션 싱글사인온(Web SSO)과 마찬가지로, 웹 서비스는 전체 트랜잭션을 위해 여러 웹 서비스에 걸쳐 세션이 관리돼야 하는 비즈니스 프로세스의 일부가 될 수 있다. 이는 웹 서비스를 위한 SSO 형태로 간주될 수 있다.
● 이기종 인프라 지원 - 웹과 현재의 웹 서비스 기반 애플리케이션의 핵심적인 이점은 서로 교환이 가능한 표준 기술을 이용할 경우 별도의 하드웨어나 네트워크 또는 애플리케이션을 요구하지 않는다는 점이다. 웹 서비스는 다양한 형태로 도입이 가능하며 의심할 여지 없이 많은 대형 조직에서 구축할 수 있다. 따라서 이러한 이기종 환경을 지속적으로 보호하는 능력이 중요하다.
● 성능, 신뢰성, 가용성, 확장성 - 엔터프라이즈급 컴퓨팅 환경의 모든 요소를 보유하는 것은 말할 필요가 없다. 많은 웹 애플리케이션은 99.999%의 가용률로 수많은 사용자들에게 확장 가능해야 한다. 이와 같이, 재활용성이 핵심적인 강점인 SOA 기반 애플리케이션은 웹 애플리케이션과 동일한 수준의 99.999%의 가용성이 요구된다. 게다가 SOA/WS 기반 애플리케이션은 상호 의존적이기 때문에 한 서비스에서 장애가 발생할 경우 다른 서비스에도 영향을 끼친다.
● 표준 지원 - SOA/WS는 WS시큐리티(WS-Security) 등 다양한 보안 표준을 포함한 여러 표준(XML, WSDL, SOAP 등)에 의해 발전하고 있다. 이러한 표준 지원은 상호운용성을 미리 확보함으로써 내부와 외부 서비스를 위한 도입과 관리가 한층 쉬워진다는 의미다.
위에 언급한 보안 요구 사항은 SOA/WS의 이점이 달성될 수 있도록 유연하고 엔터프라이즈급 환경에서 제공돼야 한다. 결국 상당수 기업들이 다양한 자급자족 형태의 요소들로 구성된 수많은 SOA 기반의 웹 서비스를 보유할 것으로 볼 때, 보안 기능을 각각의 컴포넌트에 구현하는 것은 실용적이지 않다. 따라서 SOA 보안은 가장 높은 수준의 유연성과 효율성을 유지하도록 중앙화된 인프라나 서비스로 제공돼야 한다.
SOA 보안 계층
SOA/WS를 위한 보안은 애플리케이션 구조에 따라 다양한 곳에서 도입이 가능하다. SOA/WS 보안은 네트워크의 경계나 SOA 플랫폼 내부, 또는 SOA 애플리케이션 컨테이너에서 구현되는 경우가 많다. 지금까지는 이러한 분산된 보안 도메인 간의 통합이 거의 이뤄지지 못했다는 점을 감안해 볼 때, 성능이 중복되는 결과가 초래될 수밖에 없다. 따라서 기업들은 SOA/WS 아키텍처의 여러 부분에서 유사한 보안 정책을 관리해야만 한다.
이러한 여러 보안 정책을 관리하는 것은 많은 이유로 문제가 될 수 있다. 리소스가 훨씬 많이 투입되며 보안에서 틈새가 발생되고 유사한 보안통제가 중복된다. 최고의 해결책은 SOA 보안에 대해 방어 수단을 계층화하는 것이지만 이러한 계층은 중앙화된 정책을 통해 일관적이며 조화를 이루면서 관리돼야 한다.
결국, SOA/WS 보안 솔루션은 각 컴포넌트 서비스를 어떻게 보호할 것인지 등에 대한 세세한 사항을 개발자가 고민하지 않도록 지원해 줄 수 있어야 한다. 또한 이와 동시에, 모든 웹 서비스에 걸쳐 전체적인 리포팅을 보장해 줄 수 있도록 전사적 정책을 강제할 수 있는 중앙화되고 구조화된 방법 역시 중요하다. 결국 많은 기업이 세계적 수준의 중앙화된 관리를 제공하면서도 필요한 유연성을 갖춘 SOA/WS 보안 시스템을 구축하기 위해서는 이들 간의 균형을 이뤄야 한다. SOA 각 보안 계층을 좀 더 자세히 살펴보면 다음과 같다.
● 경계 보안 - 기업의 DMZ에 위치해 하드웨어나 소프트웨어 형태로 제공되는 경계 기반 시스템은 XML 보안 게이트웨이나 XML 방화벽으로도 알려져 있으며 SOA/WS 애플리케이션을 제 일선에서 방어하는데 사용된다. 이러한 시스템은 일반적으로 XML 트래픽의 리버시 프록시(reverse proxy) 방식으로 구축되기 때문에 보안 정책을 따르는지 확인하기 위해 모든 인바운드 메시지가 검사되고 처리된다. 이러한 XML 보안 게이트웨이는 바이러스와 서비스 거부 공격 등 XML을 토대로 한 멀웨어와 인바운드 트래픽에 있는 위협 요인을 점검한다. 구축된 애플리케이션과 기타 표준과의 호환성을 보장하기 위한 프로토콜 변환 역시 이곳에서 일어난다.
● SOA 플랫폼 보안 - 대기업에 도입되는 수많은 서비스들 중 상당수가 SOA/WS에 대해 이용 가능한 서비스를 연결하고 중개하며, 관리하는 매개체 역할을 하는 ‘플랫폼’ 형태로 구현한다. SOA/WS 개발 업체들은 SOA 플랫폼 내부에 통합된 보안 기능 중 일부만 사용할 수도 있지만, 그럴 경우 보안 수단의 중복 문제 혹은 보안 틈새를 남겨두거나 관리와 규제 문제를 일으키는 등의 보안 사일로를 생성하는 등 여러 위험성을 초래할 수 있다. SOA 플랫폼의 경우 권한을 부여하고 내/외부에 있는 서로 다른 시스템간의 연동을 지원하기 위해 SOA/WS 보안 표준(WS-*을 포함)을 사용하는 경향이 있다.
● SOA 컨테이너 보안 - OA/WS 애플리케이션은 자바 J2EE나 마이크로소프트의 닷넷(.NET) 스펙을 사용해 구성되는 ‘컨테이너(container)’ 내부에 구축된다. SOA/WS은 표준 기반이기 때문에 개발 환경은 서비스 자체의 구축을 위한 재료가 아니라 환경을 보호하고자 한다는 점에서 차이가 있다. SOA 플랫폼과 마찬가지로, J2EE와 닷넷은 개발자의 재량에 따라 애플리케이션에 직접 구현될 수도 있지만 기능이 중복된다든가 관리 및 규제 문제를 야기하는 보안 사일로를 생성하거나 애플리케이션 내부에 보안 틈새를 남겨둔다는 유사한 위험성을 가지고 있다.
SOA/WS 보안과 관련된 추가 사항
위에서 언급한 바와 같이, 다양한 SOA 영역(경계, 플랫폼, 컨테이너)에 걸친 보안 기능의 중복 문제는 확실히 비효율적이며 IT 비용 상승을 초래하는 추가적인 관리와 개발자 리소스를 요구한다. 이러한 이중적인 문제 외에도, 모든 계층에 걸쳐, 그리고 모든 분산된 애플리케이션에 대해 일관된 보안 정책을 구현하기가 어려워진다.
이러한 상황은 웹 액세스 관리에서도 동일하다. 웹 액세스 관리에는 원래 다양한 수준의 보안이 경계와 컨테이너, 애플리케이션 내부에 도입됐는데, 이후 보안 수준을 향상시키고 애플리케이션 보호에 필요한 시간과 리소스를 줄이기 위해 공통된 보안 인프라로 통합됐다. 다행히 이러한 문제점은 웹 기반의 애플리케이션 도메인에서 해결됐으며 이와 동일한 기술이 SOA/WS에도 직접 적용될 수 있다.
SOA 기반의 애플리케이션은 예전의 웹 기반의 애플리케이션과 동일한 진화 경로를 따를 가능성이 높다. 이러한 가능성은 애플리케이션의 모든 계층에 걸쳐 중앙화된 보안을 집행함으로써 두 진영을 모두 아우르는 새로운 세대의 SOA/WS 보안 솔루션의 등장을 예고케 하는 것이다. 오늘날의 SOA/WS 애플리케이션은 각 계층에서 최고의 보안을 요구하는 동시에 공통된 관리 인터페이스를 사용하며 일관된 정책 집행, 전체 SOA 전체 체계에 걸쳐 감사와 컴플라이언스를 위한 통합된 리포팅을 요구한다.
