“웹 서비스 데이터의 안전을 보장하라”
XML은 인간 판독이 가능하고 코어 웹 서비스 표준에 원격으로 보안 흉내를 낼 수 있는 게 아무 것도 없어서 웹 서비스는 본질적으로 취약성을 갖고 있다. 위험 요소들의 일부는 아키텍처의 특정 프로토콜 및 이행과 관련이 있으며, 모든 웹 기반 애플리케이션과 서버에 공통되는 위험들도 있다.
예를 들어 SOAP는 HTTP를 통해 가장 일반적으로 전송되는 것이다. 이는 곧 HTTP에 가해지는 어떠한 위협이든 SAP에서 물려받게 된다는 얘기다. 예를 들어 비보호 웹 서비스에 대한 SYN 흐름은 유사하게 구성된 웹 서버에 침투되는 것과 같은 효과를 갖게 될 것이다. 기반 전송 메커니즘을 보호하지 않으면 웹 서비스는 위험에 처하게 된다. 보안을 다루는 거의 모든 웹 서비스 관련 사양이 SSL과 TLS(Transport Layer Security)를 이용해 전송 계층에서 이것을 처리하고 있다.
문제는 SSL이 만병통치약이 아니며, 그렇게 고려돼서도 안 된다는 것이다. SSL이나 이와 유사한 전송 암호화 프로토콜들은 전송 중인 콘텐츠를 보호해주긴 하지만 이런 프로토콜이 보호하고자 하는 취약성은 웹 서비스에만 해당되는 게 아니다. 이런 메커니즘들은 웹 서비스에 내재된 실질적인 비보안성을 아직 해결하지 못하고 있다.
허가와 관계없이 기능 사용
XML은 인간 판독이 가능하기 때문에 전송 중에 가로채질 경우 교환되고 있는 데이터에서 뿐만 아니라 그 데이터의 구조에서부터도 많은 정보를 유출하게 될 수 있다. HTML 양식 데이터와 XML에는 모두 이름 값 쌍이 포함돼 있긴 하지만 XML은 계층적이며 내부 데이터베이스 스키마를 모델링함으로써 HTML 양식으로 인코딩된 데이터에 비해 데이터간의 관계를 보다 쉽게 보이도록 해주는 경우가 많다.
IIS로부터 직접적으로 XML 출력을 지원하게 되면 결과적으로 동일한 취약성이 생기게 되는데, 이는 곧 스키마와 결과물들이 데이터베이스에서 직접 풀링되고 테이블과 컬럼들을 매핑하는 데 사용될 수 있기 때문에 조직의 내부 작업들을 속속들이 파악할 수 있게 된다는 것이다.
대부분의 웹 서비스 개발 툴과 플랫폼들은 서비스의 신속한 배치를 약속하지만 웹 서비스를 만드는 데 필요한 생성된 WSDL 및 XML 스키마에서 쉽게 추출되는 민감한 기업 스트럭처의 노출 등과 같은 성가신 문제들에 대해서는 언급하지 않는다.
또한 웹 서비스 아키텍처에서 노출되는 데는 특정 도구(method)나 기능이 요구된다. 일반적으로 WSDL로 문서화된 방식은 코드에서 풀링되며 혼란케 하는 경우가 거의 없는데, 이는 웹 기반 양식 제출에서와 마찬가지다. 서비스 지향적 아키텍처에서 요구되는 정밀성은 곧 내부 비즈니스 프로세스가 거기에 연관된 애플리케이션 코드에서 추출될 수 있다는 것을 의미한다. HTML 양식은 정보를 다시 애플리케이션으로 전달하겠지만, 기반 기능 호출(보통 의미에 따라 이름이 붙여진다)은 노출되지 않는다.
그래서 뭐가 대수란 말인가. 결국 누구든 HTML 페이지의 소스를 볼 수 있고 나쁜 사람들이 보지 않았으면 하는 모든 보물을 찾아낼 수 있는 것 아닌가. 숨겨진 필드는 브라우저 안에서 보여지지 않는 것뿐이지 페이지 안에 여전히 존재하며 쉽게 읽힐 수 있다. 양식의 제출 지점은 페이지에 존재해야 하며 특별한 노력을 기울이지 않아도 소스에서 뽑아낼 수 있다. 쿠키는 플레인 텍스트로 저장되며 웹 페이지의 소스만큼이나 간단하게 볼 수 있다.
문제는 대부분의 경우 전통적인 웹 기반 애플리케이션을 통해 다른 기능에 대한 정보에 닿을 수가 없는데, 그 이유는 애플리케이션이 액세스를 허가받은 것만을 볼 수 있게 하기 때문이다. 반면에 웹 서비스는 다른 쪽 종단의 사람이 액세스를 허가받았는지 여부에 관계없이 모든 기능을 사용할 수 있게 지원한다.
결론적으로 대부분의 웹 기반 애플리케이션들은 액세스를 사전에 제한하는 반면 웹 서비스는 사후 반응적이며, 문제는 여기에 있다. 개발 작업 동안 웹 서비스를 보안하기 위해서는 이것을 수정해 각각의, 그리고 모든 기능이 허가받은 액세스만이 허용되도록 보장하는 듀 딜리전스(due diligence)를 수행토록 해야 한다. 개발자로 하여금 사용자 입력을 검증하도록 요구하는 게 바람직하고, 모든 기능에 대한 권한 허가를 검증하는 게 실현 불가능한 일은 아니지만, 이것은 서비스를 사용 불가능하게 만들 정도로 성능을 저하시킬 것이다.
웹 서비스에 효과적인 보안을 제공하기 위해서는 인증 및 권한 부여의 사전준비 모델로 이동해야 한다. 일단 들어오고 난 침입자를 내쫓는 것보다는 문 앞에서 초대장을 요구하는 게 훨씬 더 쉽고 안전하다. 사전준비 모델은 관리하기가 더 수월할 뿐만 아니라 기업에서 정책을 일관성 있게 강행해주는 중앙 보안 아키텍처를 제공한다.
무결성을 지켜라
웹 서비스-시큐리티(WS-Security)와 SAML(Security Assertion Markup Language)은 소비자(클라이언트)와 생산자(웹 서비스)간에 신뢰 관계를 구축할 수 있는 메커니즘을 제공한다. 두 가지 사양 모두 유연하며 소비자 신원증명서를 검증하기 위한 많은 옵션들을 제공하고 있다(사용자 이름-패스워드 조합, X.509, 이메일 주소와 토큰뿐만 아니라 신원 확인과 권한부여를 위한 전자 서명 등). 웹 서비스는 원래 개방된 것이기 때문에 클라이언트 신원증명서가 웹 서비스에 의해 검증 및 신뢰받도록 하는 일은 필수적이다. SAML 편집자이자 WS-시큐리티 사양의 공동 저자인 필립 할램베이커 박사는 “기밀성(confidentiality)보다 무결성(integrity)이 훨씬 더 중요하다”고 말했다. 그는 또 “이것은 단순한 보안이 아니라 신용”이라고 말했는데, 전적으로 동감하는 바다.
일부 제품들은 XML 문서 안에 있는 요소들로부터 사용자 증명서를 끌어올 수 있는 능력이 있다. 하지만 증명서 검증 방식은 이 프로세스가 웹 서비스 보안 전략에 속하도록 보장하는 만큼 중요하진 않다. WS-시큐리티는 SAML과 마찬가지로 널리 지원되고 있는데, 사실 SAML은 소비자에게서 생산자에게로 증명서를 전달해 주는 한 가지 방식으로 WS-시큐리티 사양에 지정돼 있다. XML은 컴퓨터 어쏘시에이츠, 네티그리티, 노벨 및 오블릭스 등과 같은 많은 신원관리 시스템 사업자들이 지원하고 있기 때문에 인프라로 쉽게 통합할 수 있으며 기존의 인프라 투자를 활용할 수도 있다.
생산자는 소비자의 증명서를 검증하는 일 뿐만 아니라 문서 구조를 예상 스키마에 대조해 검증해 보아야 한다. 웹 서비스는 양식 기반의 선행주자들과 마찬가지로 SQL 투입과 같은 데이터 계층 공격에 취약하다. 대부분의 잘 짜여진 XML 스키마는 문서의 포맷을 지정할 뿐만 아니라 예상 데이터 유형까지 세부적으로 설명해준다. 예를 들어 스키마가 정수를 엘리먼트 유형으로 규정한다면, 숫자 데이터만이 허용될 것이다. 입력되는 문자열의 길이가 지정된다면 맞지 않는 엘리먼트가 있는 문서는 거부돼야 한다. 사용자 입력 검증은 어떤 애플리케이션에서든 필수조건이 돼야 하며 웹 서비스도 예외는 아니다.
그 곳의 문서나 엘리먼트가 전자적으로 서명이 된다면 한층 더 나아가 증명서가 검증되고 CRL(Certificated Revo cation List)가 컨설팅되는 것도 기대할 수 있다. 증명서가 CRL에서 발견되지 않는다면 발급자 고리를 통해 증명서를 확인해보는 게 좋으며, 이 모든 것이 CA(Certificate Authority)로 가는 길이 된다. 암호화된 엘리먼트들은 또한 암호가 해제되어 다시 검증되어야 한다. 일단 수용 가능한 것으로 판명되면 소비자의 증명서를 이용해서 클라이언트가 요청되고 있는 서비스와 작동에 액세스할 권한이 있는지 여부를 파악해야 한다. 그런 다음에야 요청이 처리될 수 있는 게 순서다.
입력 및 증명서 검증은 비단 웹 서비스뿐만 아니라 어떠한 웹 환경에서든 보안 애플리케이션 개발에서 필수 단계가 돼야 한다는 사실을 명심하라.
2계층 보안 구조
웹 서비스 보안은 어느 한 가지만으로는 부족하다. 잘 짜여진 웹 서비스 아키텍처에는 네트워크 단계에서의 단일 진입 지점과 서비스 단계에서의 정밀 제어 단계가 모두 포함될 것이다.
XML 게이트웨이, XML 방화벽, 혹은 SOAP 프록시라고 불리기도 하는 WS-시큐리티 게이트웨이는 허가받지 않은 액세스와 전송, 그리고 애플리케이션 계층 공격을 막는 데 필요한 네트워크 보안 기능들을 제공할 수 있다.
웹 서비스 생산자는 보통 BEA 시스템즈, 아이비엠, 마이크로소프트, 혹은 노벨 등과 같은 업체의 애플리케이션 서버가 되는데, 이들은 소비자 증명서와 요청 혹은 제출되는 특정 데이터를 기반으로 특정 작동으로의 권한부여를 제어할 수 있게 해준다. WS-시큐리티 게이트웨이는 권한부여 작업과 같은 메시지 단계 보안을 제공할 수 있겠지만 이것이 실현 불가능한 상황들도 있다(써드파티 서비스를 보안하고 있을 때 등). CRM, ERP 및 HP 애플리케이션은 통합의 한 방법으로 웹 서비스를 제공하겠지만 이들은 가끔씩 인증 및 권한부여에 내부의 전용 방안을 사용하기도 한다. 이런 경우에는 애플리케이션이 운영 단계의 권한부여 기능을 제공해야 한다.
생산자는 또한 처리될 준비가 된 데이터를 검증해야 하며 소비자가 제공받은 파라미터 안에 있는 질문에서의 작동에 액세스를 허가받았는지를 확인해야 한다. 예를 들어 회사의 웹 서비스 지원 HR 시스템을 생각해 보자. 모든 직원이 이 시스템에 액세스를 할 수 있겠지만 그 시스템 안에 있는 데이터를 볼 수 있는 권한은 조직내에서의 직무에 따라 직원마다 다를 것이다. 웹 서비스의 경우 배송부서에서는 ‘직원정보’ 서비스로 액세스를 허가받아서 ‘봉급정산’에 대한 요청을 만들 수는 있겠지만 자기 것만 볼 수 있다.
이러한 2계층 보안 구조가 웹 서비스용으로 가장 적합한 데는 다음과 같은 몇 가지 이유가 있다:
>> 성능: 암호화, 암호해제, 서명 및 서명 확인 등은 CPU 집약적인 작업들이다. 액셀러레이티드 인크립션 프로세싱(Accelerated Encryption Processing), 브로드콤(Broadcom), 엔사이퍼(nCipher) 및 레인보우 테크놀로지스(Rainbow Technologies) 등 업체들의 암호 가속기 하드웨어가 CPU 부담을 덜어줄 수 있긴 하지만 이런 작업들은 네트워크의 에지에서 하는 게 좋다. 그래야 IDS 및 부하조절기와 같은 다른 보안 장비를 통합할 수 있기 때문이다. 또한 에지에서는 애플리케이션 서버가 많은 자원을 요청 처리에 할애할 수 있으며 여러 가속기 카드와 증명서를 관리하는 데 드는 비용이 경감된다.
>> 단일 진입 지점: WS-시큐리티 게이트웨이는 기업으로 향한 웹 서비스의 단일 진입 지점뿐만 아니라 기업에서의 정책 이행을 위한 단일 지점도 제공하기 때문에, 보안 정책 애플리케이션에서의 일관성을 향상시키고 관리 비용을 줄여준다. 감사 및 로깅 또한 게이트웨이에서 통합이 가능해 요청과 응답을 정확하게 추적할 수 있다. 전사적으로 여러 개의 서버를 통합할 필요 없이 한 두개의 장비만 하면 되기 때문에 비용을 줄일 수 있으며, 이는 특히 써드파티 신원증명 사업자들을 이용하고 있을 때 더욱 그러하다.
>> 업체 중립성: 애플리케이션 로직 안에 보안 정책을 탑재하게 되면 한 업체에 묶일 수 있다. 보안을 별도의 장비로 이동시키면 특정 이행에 대한 의존성을 없앨 수 있다. 이러한 이동은 또한 상호운용성도 향상시키는데, 이는 웹 서비스-시큐리티 게이트웨이가 다양한 업체 이행들과 잘 작동할 것이므로 다양한 웹 서비스와 신원관리 플랫폼과의 상호운용 및 통합 가능성이 높아지기 때문이다.
보안 메커니즘으로 매개 수단을 이용하겠다는 생각은 새로운 것은 아니다. WS-시큐리티 게이트웨이도 프록시나 방화벽, 웹 애플리케이션 보안 게이트웨이와 같은 다른 보안 매개자들과 같은 원칙에서 작동하며 동일한 경제적 및 운영적 이점을 갖고 있다. 그러나 이런 다른 장비들이 웹 서비스를 보호하는 데 필요한 수준의 보안을 제공해줄 것이라고 지레 짐작해서는 안 된다. 이들 중에 WS-시큐리티 게이트웨이에 있는 것과 같은 검증, 인증 및 권한 부여 기능을 제공할 수 있는 것은 없다.
WS-시큐리티 게이트웨이는 또한 아웃바운드 보안도 제공하는데 이는 B2B를 시도할 때 필수며, 아웃바운드 문서를 전자 서명 및 암호화할 수 있을 뿐만 아니라 웹 서비스를 통해 비즈니스 프로세스를 자동화하는 데 필요한 보안 헤더를 삽입할 수도 있다.
힘든 ROI 계산
보안 제품의 ROI 모델은 언제나 계산하기 힘든 법인데, 그 이유는 이들이 주로 이행을 통해 여기에 연관된 위험과 비용을 경감시키리라는 전망을 기반으로 하고 있기 때문이다. 하지만 이것은 특정 위험 시나리오와 관련된 경험 비용의 증거 없이는 추측에 불과할 수밖에 없다. 일례로 美 네트워크컴퓨팅紙와 같이 웹 서비스를 수익 창출의 방편으로 사용하고 있는 조직에서는 이런 비용이 매출 흐름에 대한 공격이나 사기로 인한 결과와 밀접하게 연관될 수 있다.
NWC에서는 웹 서비스를 통해 시간당 약 4천475달러를 벌어들이고 있다. 이 서비스에 대한 공격으로 인해 24시간의 다운타임이 발생한다면 회사에서 입게 될 손실은 약 10만5천달러가 될 것이다. 공격이 SQL 주입 공격처럼 기간업무 데이터베이스의 무결성을 해치는 것이라면 공격 비용은 데이터베이스를 복구하고 이것을 다시 재가동시키는 데 대한 필요성만큼 늘어나게 될 것이다. 전체 주문의 단 1%만 사기라고 하더라도 연간 23만달러의 손실을 보게 된다. 이를 WS-시큐리티 게이트웨이의 예상가와 비교해보면 금방 비용회수를 확인할 수 있을 것이다.
단 이 시나리오에서는 규정 준수 문제의 가능성이 참작되지 않았으며 명예훼손으로 인한 손실이나 법적 문제를 해결하는 데 드는 수수료, 혹은 웹 서비스를 통해 데이터로 공격하거나 허가받지 않은 액세스를 하는 데 따르는 막대한 추가 비용 손실 또한 고려되지 않았다.
또한 노출된 서비스용으로 모든 보안 기능을 제공하는 웹 서비스 플랫폼에 있는 일층 솔루션을 이행하는 데 따르는 비용도 고려해야 한다. 암호화, 서명 및 정책 시행 등의 추가 부담으로 인해 성능 감소가 발생할 가능성이 많다는 점을 감안한다면 하나의 WS-시큐리티 게이트웨이와 같은 수준의 성능을 제공하기 위해서는 최소 두 개의 서버를 준비해야 할 것이다. SSL 인증에 추가로 드는 비용을 따져본다면 애플리케이션 소프트웨어와 하드웨어는 WS-시큐리티 게이트웨이가 보안 기능뿐만 아니라 비용 절감 차원에서도 도움이 된다는 사실을 입증해 준다. 
