[웹 서비스 시큐리티 게이트웨이②] 제품별 평가
상태바
[웹 서비스 시큐리티 게이트웨이②] 제품별 평가
  • Network Computing
  • 승인 2004.03.30 00:00
  • 댓글 0
이 기사를 공유합니다

아직은 진화 단계 … ‘포럼 센트리’ 기능과 편이성 조화
분석과 번역 통해 ‘문제의 바다 평정’
좋았던 시절에는 간단한 레이어 2/3 네트워크 방화벽으로도 네트워크 보안 검열을 통과할 수 있었다. 하지만 포트 80이 널리 열리고 모호한 트래픽들을 받아들이게 된 지금은 더 이상 가능한 얘기가 아니다. 오늘날에는 레이어 7 액세스 제어와 프로토콜 점검이 반드시 필요하다. 물론 레이어 2 점검에 대한 필요가 새삼스러운 것은 아니며 웹 서버와 CGI 애플리케이션을 보호해주는 웹 서버와 CGI 애플리케이션이 나온 지도 한참이 되었다. 그러나 이제 새로운 방안, 즉 WS-시큐리티(Web Services Security) 게이트웨이가 웹 애플리케이션 방화벽의 기능을 통합시키고 SOAP(Simple Object Access Protocol) 종단 URL로 보내지는 XML 바디 콘텐츠를 해독하고 이해하고 있다. 간단하게 들리겠지만 이 기본적인 분석 능력이 문제의 바다를 평정시킨다.

본지에서는 위스콘신주 그린베이에 있는 본지 애플리케이션 랩에 자바 SOAP 웹 서비스들을 집합시키고 마인드 일렉트릭(The Mind Electric)의 글루(Glue) 프레임워크를 이용해 이들을 호스팅해 보았다. 우리는 어떠한 SOAP 클라이언트든 호출할 수 있을 세 가지 서로 다른 프로그램 기능들(작동들)을 갖춘 하나의 자바 클래스를 만들었다. 그리고 컴파일링과 설치, 구성 작업을 했다. 결국에는 SOAP 클라이언트가 이 세 가지 SOAP 작동들 중 어떤 것으로든 액세스하는 데 사용할 수 있는 하나의 HTTP URL을 갖게 되었다.

그리고 문제는 여기에 있다. 개별적인 SOAP 서비스 기능들로의 액세스를 제한하고 싶었지만 전통적인 방화벽으로 레이어 2/3에서 이러한 제한을 할 수가 없었는데, 그 이유는 모든 클라이언트가 포트 80으로의 액세스를 필요로 하기 때문이다. 그리고 웹 서버에는 이 제한을 둘 수가 없었는데, 이는 모든 SOAP 서비스가 같은 URL에서 호스팅되기 때문이다(모든 SOAP 요청을 같은 CGI가 처리하는 것처럼 생각하면 되며, 비결은 기능 호출 이전에 권한부여가 먼저 이뤄지는 것이다).

그러면 표준 SOAP 프로토콜에 정의된 것만을 이용해 어떻게 특정 SOAP 서비스로의 특정 클라이언트 액세스를 제한할 수 있었을까. 우선 손을 놓고 모든 클라이언트가 모든 SOAP 서비스에 액세스하도록 하는 것은 현명하지 못하다고 판단했다. 따라서 다음과 같은 몇 가지 선택이 남는다.

>> SOAP 서비스 로직에서 어떤 유형의 액세스 제어 메커니즘을 이행하라. 하지만 소스가 폐쇄된 써드파티 SOAP 서비스 제품을 가동중이거나 적절한 개발 자원이 없다면 이것은 불가능하다. 또한 클라이언트가 소프트웨어를 업데이트해 새로운 XML 인증 요소들을 수용하도록 할 필요도 있다.

>> 모든 개별적인 SOAP 서비스를 서로 다른 URL 종단지점 안에 설계, 구성 및 이행하라. 최악의 경우에는 서로 다른 서버에서 각각의 SOAP를 호스팅할 수도 있다. 이 또한 자신이 SOAP 서비스 이행을 제어하고 자신의 SOAP 애플리케이션 서버가 URL 종단지점 분리를 허용하며, 분산 SOAP 서비스를 관리할 수 있는 충분한 전문 인력이 있을 때의 얘기다.

>> 일종의 SOAP 암호화와 인증 익스텐션이 구축된 SOAP 애플리케이션 서버를 구하라. 하지만 여기에도 여전히 SOAP 서비스로의 변경이 포함될 것이다.

이 방안들 가운데 그리 마음에 드는 것은 없다. 다행히도 WS-시큐리티 게이트웨이는 웹 및 SOAP 애플리케이션 서버가 하는 것처럼 들어오는 SOAP 요청들을 파싱 및 번역한 다음 특정 SOAP 설명서(particulars)를 기반으로 SOAP 요청들을 라우팅, 권한부여 및 제한하는 데 필요한 툴을 제공한다. 이게 없을 경우에는 방화벽이나 웹 서버에서 SOAP 요청들을 알아차릴 수가 없다.

위와 같은 상황에서 WS-시큐리티 게이트웨이를 사용하면 다양한 WS-시큐리티 게이트웨이들이 보통 지원하는 XML 보안 익스텐션에 포함된 많은 인증 방안들을 이용해 어떤 클라이언트가 어떤 SOAP 서비스에 액세스할 수 있는지를 규정할 수 있다. 그리고 무엇보다도 SOAP 애플리케이션 로직에 단 한 번의 변경도 가할 필요 없이 할 수 있다는 점이 가장 좋다.

인증은 WS-시큐리티 게이트웨이가 제공하는 기능들 중 한 가지에 불과하다. 이 프로토콜은 또한 데이터 무결성과 암호화를 처리한다. 예를 들어 일부 SOAP 서비스는 B2B 파트너들이 프로세싱을 위해 데이터베이스에 직접 정보를 제출할 수 있게 해준다. 공격자가 데이터베이스로 직접 버려지고 있는 많은 오염된 데이터나 오류 데이터를 만들어내는 맨 인 더 미들(man-in-the-middle) 공격을 한다고 하자. 암호 서명과 같은 데이터 무결성 메커니즘은 그 데이터가 파트너에게서 나온 것이 아니며, 따라서 데이터베이스 프로세싱을 위해 SOAP 서비스로의 액세스를 허용해서는 안 된다는 것을 증명할 수 있다.

WS-시큐리티 게이트웨이는 또한 다양한 알려진 공격 유형들로부터 웹 및 애플리케이션 서버를 숨길 수 있다. 따라서 마이크로소프트의 악명 높은 비보안 IIS 웹 서버에서 호스팅되는 데 대해 걱정할 필요가 없이 마이크로소프트의 닷넷 SOAP 프레임워크를 사용할 수 있게 된다.

이론상으로 볼 때 매우 좋은 얘기라 우리는 실제로도 이러한지를 확인해 보기로 했다. 본지 그린베이 애플리케이션 랩으로 WS-시큐리티 게이트웨이를 보내줄 것을 요청한 업체는 데이터파워 테크놀로지(DataPower Technology), 포럼 시스템즈(Forum Systems), 리액티비티(Reactivity), 사비가(Sarvega), 베리사인(VeriSign), 웨스트브리지 테크놀로지(Westbridge Technology) 및 엑스트라다인 테크놀로지스(Xtradyne Technologies) 등이었다. 사비가는 처음에는 수락을 했지만 나중에 다소 미적거리더니 자원 문제를 들며 거절을 했다. 다른 모든 업체들은 제품을 보내주었으며 본지 네오햅시스 파트너 랩에서 동기화 작업 후 본격적으로 테스트를 시작할 수 있었다.

무엇을 할 수 없는가

업체들의 선전 문구와는 달리 모든 위험을 없애주는 ‘궁극의 보안 제품’은 없으며, WS-시큐리티 게이트웨이도 예외는 아니었다. WS-시큐리티 게이트웨이가 어떤 일을 할 수 있는지를 아는 것도 중요하지만 할 수 없는 일을 하는 것 또한 마찬가지로 중요하다.

현재의 WS-시큐리티 게이트웨이는 SOAP 서비스로 제출된 데이터를 이해하는 데 있어서는 무지하다. 물론 데이터 유형(문자열, 정수, 어레이)이 스키마에 대조해 확인되긴 하지만 이것만으로는 모자라는 게 많다. 상세히 설명된 스키마를 통하지 않고는 적합한, 혹은 부적합한 특성을 규정할 수가 없다. 따라서 스키마에 이 정보가 포함돼 있지 않으면 SQL 탬퍼링 공격에서 사용되는 것으로 알려진 특성들을 허용하지 않도록, 혹은 포맷 스트링 공격 같은 것이 보일 때 프로세싱을 중단하도록 WS-시큐리티 게이트웨이를 구성할 수가 없다. 이상적인 WS-시큐리티 게이트웨이는 사촌인 웹 애플리케이션 방화벽처럼 엘리먼트당 데이터 필터링을 제공해야 한다.

WS-시큐리티 게이트웨이 업체들 중 일부는 이 문제를 해결했다고 주장하고 있다. 예를 들어 리액티비티는 자사 제품이 SQL 탬퍼링 공격을 중단할 수 있다고 말한다. 테스트 결과 이 제품은 알려진 SQL 명령어의 작은 서브세트들용으로 일반 패턴 매치(generic-pattern match)를 수행했다. 하지만 서브세트가 SQL 탬퍼링 공격을 중단시킬 만큼 충분히 포괄적이지 못했으며, 그 패턴 매칭 기능이 그다지 강력한 것도 아니었다. 리액티비티의 시도는 이런 공격을 중단시키지 못한다고 인정한 다른 업체들보다는 발전적이지만 최소한 이들은 정직하기는 하다.

또 한 가지 단점은 WS-시큐리티 게이트웨이와 웹 애플리케이션 방화벽간에 교차점이 없다는 사실이다. 테스트한 시큐리티 게이트웨이들 중에서 HTTP를 통해 포스팅된 XML 문서나 SOAP 서비스 외에 다른 것을 보안하려고 시도한 것은 하나도 없었다. 전형적인 웹 자재와 SOAP 서비스를 같은 시스템에 모두 통합하려는 사람은 운이 없는 셈이다. 카바도(Kavado)의 스캔두(ScanDo)나 인터두(InderDo), 그리고 프로세스 소프트웨어(Process Software)의 멀티넷(MultiNet) 등과 같은 몇몇 웹 애플리케이션 방화벽들이 기본적인 SOAP 보안을 처리하긴 하지만 이들은 WS-시큐리티 지원이 제대로 되지 않아 이번 리뷰에서 제외시켰다.

성능도 또한 문제가 된다. 우리는 데이터파워와 포럼 시스템즈의 어플라이언스처럼 하드웨어 가속기에 의존해 오류율 제로의 성능 수준을 제공하는 제품에 어울리는 소프트웨어 제품을 제공하는 데 있어 엑스트라다인을 많이 이용했다. 혼성 ‘어플라이언스’ 제품들은 티어 1 업체나 기타 소프트웨어 전문 업체들의 스톡 OS 및 브랜드 하드웨어 이상 아무 것도 아니며, 오류가 없이는 간단한 프록시 서비스조차도 이행할 수가 없다. 그리고 더 중요한 것은 이런 제품들이 오류난 트랜잭션을 통보해주지 못했다는 점이다. 아무런 말없이 트랜잭션이 사라지는 것은 웹 서비스를 통해 매출이 생성되거나 감소되는 환경에서는 받아들이기 힘들다.

또 한 가지 짚고 넘어갈 것은 이런 장비를 구성하는 데 필요한 경험이다. 다행히도 대부분의 WS-시큐리티 게이트웨이는 간단한 구성에서 출발할 수 있는데, 그 이유는 보호하고자 하는 웹 서비스의 WSDL(Web Services Definition Language) 파일로부터 기본 규정 세트를 임포팅해올 수 있기 때문이다. 이 단계를 넘어가서 규정을 추가하려 할 때는 복잡해질 수 있다. 데이터파워의 XS40과 같은 극단적인 경우에는 일부 고급 기능들을 구성하는 데 XSLT(Extensible Stylesheet Language Transformation)에 대한 완벽한 이해가 필요하기도 한다.

이 이야기의 교훈은 WS-시큐리티 게이트웨이는 SOAP 서비스에 누가 액세스를 하는지는 제어할 수 있지만 애플리케이션 레벨의 보안 위협을 완화하는 데 대한 책임은 여전히 상당 부분이 SOAP 서비스 자체에 있다는 것이다.

아직 미성숙한 제품 발견

우리는 6개의 게이트웨이에 본지 인프라에 있는 웹 서비스를 보안하라는 임무를 준 다음 이들을 레이어 4에서 유심히 관찰했다. 그 결과 아직도 진화하고 있는 표준용으로 미성숙한 제품들을 발견할 수 있었으며, 데이터 센터에 꼭 필요하다고 스스로를 입증하려 애쓰는 업체들 사이에서는 상당한 혼란이 있었다.

가장 불안한 것은 WS-시큐리티 1.0이 번역하는 데 있어서의 느슨함이었다. WS-시큐리티 사양에서는 준수를 주장하기 위해 지원되어야 하는 것들의 목록이 나와 있는데, 이들은 유저네임토큰(UsernameToken), 바이너리시큐리티토큰(BinarySecurityToken: X.509나 커버로스), 시큐리티토큰레퍼런스(SecurityTokenReference), XML 시그니처 및 XML 인크립션 등이다. 표준을 지원한다는 것과 이것을 준수한다는 것은 매우 다르다. 베리사인과 엑스트라다인은 WS-시큐리티 1.0 준수를 함축하고 있다는 죄목이 있다. 베리사인은 인증의 한 방안으로 X.509만을 지원하며(코어 비즈니스를 감안하면 놀랄 일도 아니다), 엑스트라다인은 SAML(Security Assertion Markup Language)외에는 지원하지 않는다. 선전 문구에서 제품이 제안된 WS-시큐리티 1.0 표준을 지원한다는 말이 있는데, 이는 보통 여기에 표준을 준수하는 것과는 거리가 먼 한정된 기능 서브세트가 있다는 것을 의미한다.

혼란을 더욱 가중시키는 것은 이러한 제품이 보안 사양으로 무엇을 제공해야 하는지에 대한 명확한 규정도 합의점도 없다는 사실이다. 심지어 공통적으로 사용되고 있는 기술도 없는 실정이다(대부분의 개념들은 다른 영역에서 끌어내 채택할 수 있긴 하다). 어떤 제품에서 ‘클라이언트’는 또 다른 제품의 ‘소비자’가 되며, 어떤 제품에서 ‘작동(operation)’은 다른 제품에서 ‘기능(function)’이 된다.

신중하게 검토한 후 우리는 WS-시큐리티 게이트웨이에서 기대해야 할 간단한 기능 목록을 꼽아 보았다.

>> XML 스크루빙(콘텐츠 점검)
>> WS-시큐리티 1.0 준수
>> 서비스 및 운영 모두에 대한 액세스 제어
>> LDAP나 액티브 디렉토리와 같은 기존의 신원 저장소와의 통합
>> WSDL 지원
>> 오류율 제로 성능(장비나 프로그램이 어떠한 트랜잭션 유실도 없이 무거운 부하 아래서 요청을 처리할 수 있는 능력)
>> 스키마 검증 및 자동 SOAP 엔벌로프(SOAP-envelope) 검증
>> 트랜잭션과 정책 모두를 위한 포괄적인 감사 추적 생성 및 로깅

수개월의 엄정한 테스트 후 이런 요구조건을 충족시킨다는 견지에서 우리는 포럼시스템즈의 포럼 센트리 1504 2.0(Foum Sentry 1504 2.0)을 에디터즈 초이스로 선정했다. 이 제품은 사실상 전문 지식이 전혀 필요치 않은 구성 및 관리 유틸리티를 보너스로 제공해 경쟁 제품들보다 기대치 이상이었다. 포럼 센트리는 완벽한 것과는 아직 거리가 멀지만(몇 가지 고급 구성에서는 XSLT 변환을 필요로 하며, 콘텐츠 점검 기능은 한정적이다), WS-시큐리티 게이트웨이에서 기대하는 방향으로 진화할 수 있는 강력한 기반을 갖추고 있다.

포럼 센트리 라인은 XML 문서용 보안을 제공하도록 만들어졌기 때문에, 웹 서비스를 지원하는 쪽으로 이동하는 것이 자연스러웠다. 이 장비의 1U 폼팩터과 듀얼 10/100Mbps NIC는 프록시 기반 아키텍처를 지원한다. 보안 구성용으로 별도의 관리 포트도 제공된다.


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