상위 질문
타임라인
채팅
관점

WS-Security

위키백과, 무료 백과사전

Remove ads

웹 서비스 보안(Web Services Security, WS-Security, WSS)은 SOAP에 보안을 적용하기 위한 확장으로 웹 서비스에 적용된다. 이는 웹 서비스 사양의 일원이며 OASIS에 의해 발행되었다.

이 프로토콜은 메시지에 대한 무결성과 기밀성을 어떻게 적용할 수 있는지 명시하며, 보안 어설션 마크업 언어 (SAML), 케르베로스, X.509와 같은 다양한 보안 토큰 형식의 통신을 허용한다. 주요 초점은 XML 서명 및 XML 암호화를 사용하여 엔드 투 엔드 보안을 제공하는 것이다.

기능

WS-Security는 세 가지 주요 메커니즘을 설명한다:

  • 무결성을 보장하기 위해 SOAP 메시지에 서명하는 방법. 서명된 메시지는 또한 부인봉쇄를 제공한다.
  • 기밀성을 보장하기 위해 SOAP 메시지를 암호화하는 방법.
  • 발신자의 신원을 확인하기 위해 보안 토큰을 첨부하는 방법.

이 사양은 다양한 서명 형식, 암호화 알고리즘 및 여러 신뢰 도메인을 허용하며 다음과 같은 다양한 보안 토큰 모델에 개방되어 있다:

  • X.509 인증서,
  • 케르베로스 티켓,
  • 사용자 ID/비밀번호 자격 증명,
  • SAML 어설션, 및
  • 사용자 정의 토큰.

토큰 형식 및 의미는 관련 프로필 문서에 정의되어 있다.

WS-Security는 응용 계층에서 작동하며 SOAP 메시지의 헤더에 보안 기능을 통합한다.

이러한 메커니즘만으로는 웹 서비스에 대한 완전한 보안 솔루션을 제공하지 못한다. 대신, 이 사양은 다양한 보안 모델과 보안 기술을 수용하기 위해 다른 웹 서비스 확장 및 상위 수준 응용 프로그램별 프로토콜과 함께 사용될 수 있는 빌딩 블록이다. 일반적으로 WSS 자체는 어떠한 보안 보장도 제공하지 않는다. 프레임워크와 구문을 구현하고 사용할 때, 그 결과가 취약하지 않도록 보장하는 것은 구현자의 책임이다.

키 관리, 신뢰 부트스트랩, 연합 및 기술적 세부 사항 (암호, 형식, 알고리즘)에 대한 합의는 WS-Security의 범위를 벗어난다.

Remove ads

사용 사례

엔드 투 엔드 보안

SOAP 중간자가 필요하고, 중간자가 덜 신뢰할 수 있는 경우 메시지에 서명하고 선택적으로 암호화해야 한다. 이는 TCP (전송 제어 프로토콜) 연결을 종료하는 네트워크 경계의 응용 프로그램 수준 프록시의 경우일 수 있다.

부인봉쇄

부인봉쇄를 위한 한 가지 방법은 특정 보안 보호 조치가 적용되는 감사 추적에 트랜잭션을 기록하는 것이다. WS-Security가 지원하는 디지털 서명은 보다 직접적이고 검증 가능한 부인봉쇄 증명을 제공한다.

대체 전송 바인딩

거의 모든 SOAP 서비스가 HTTP 바인딩을 구현하지만, 이론적으로 JMS 또는 SMTP와 같은 다른 바인딩을 사용할 수 있다. 이 경우 엔드 투 엔드 보안이 필요할 것이다.

리버스 프록시/공통 보안 토큰

웹 서비스가 전송 계층 보안에 의존하더라도 서비스가 최종 사용자에 대해 알아야 할 수도 있다. 서비스가 (HTTP-) 리버스 프록시에 의해 중계되는 경우이다. WSS 헤더는 리버스 프록시가 보증하는 최종 사용자의 토큰을 전달하는 데 사용될 수 있다.

Remove ads

문제점

  • 서비스 제공자와 소비자 간에 메시지 교환이 빈번하면 XML SIG 및 XML ENC의 오버헤드가 상당하다. 엔드 투 엔드 보안이 필요한 경우, WS-SecureConversation과 같은 프로토콜은 오버헤드를 줄일 수 있다. 암호화 또는 서명만으로 충분하다면, 두 가지를 함께 사용하는 것이 단일 작업의 단순 합계보다 현저히 느리므로 단일 작업만 사용한다. 아래 성능을 참조한다.
  • SOAP, SAML, XML ENC, XML SIG와 같은 여러 XML 스키마를 병합하면 정규화 및 파싱과 같은 라이브러리 함수의 다른 버전에 대한 종속성이 발생할 수 있으며, 이는 응용 프로그램 서버에서 관리하기 어렵다.
  • CBC 모드 암호화/복호화만 적용되거나, 복호화 전에 보안 체크섬 (서명 또는 MAC)을 확인하지 않고 CBC 모드 복호화가 적용되는 경우 구현은 패딩 오라클 공격에 취약할 가능성이 높다.[1]

성능

WS-Security는 전송 중 메시지 크기 증가, XML 및 암호화 처리로 인해 SOAP 처리에 상당한 오버헤드를 추가하여 더 빠른 CPU와 더 많은 메모리 및 대역폭을 요구한다.

2005년의 평가[2]에서는 펜티엄 4/2.8GHz CPU에서 WSS4J가 WS-Security와 WS-SecureConversation으로 처리한 다양한 크기와 복잡성을 가진 25가지 유형의 SOAP 메시지를 측정했다. 일부 결과는 다음과 같다:

  • 암호화가 서명보다 빨랐다.
  • 암호화와 서명을 함께 사용하면 서명만 사용할 때보다 2~7배 느렸고, 훨씬 더 큰 문서를 생성했다.
  • 메시지 유형에 따라 WS-SecureConversation은 차이가 없거나 최상의 경우 처리 시간을 절반으로 줄였다.
  • 100킬로바이트 배열까지 서명 또는 암호화하는 데 10밀리초 미만이 걸렸지만, SOAP에 대한 보안 작업을 수행하는 데 약 100~200밀리초가 걸렸다.

2006년의 또 다른 벤치마크[3]는 다음 비교를 가져왔다:

자세한 정보 보안 메커니즘, 초당 메시지 수 ...
Remove ads

역사

웹 서비스는 처음에는 기본 전송 보안에 의존했다. 사실, 대부분의 구현은 여전히 그렇다. SOAP는 HTTP 및 SMTP와 같은 여러 전송 바인딩을 허용하므로 SOAP 수준의 보안 메커니즘이 필요했다. 전송 보안에 대한 의존성으로 인한 엔드 투 엔드 보안의 부족도 또 다른 요인이었다.

이 프로토콜은 원래 IBM, 마이크로소프트, 베리사인이 개발했다. 그들의 원래 사양[4][5]은 2002년 4월 5일에 발표되었고, 2002년 8월 18일에 추가 사양[6]이 이어졌다.

2002년에 OASIS WSS 기술 위원회에 두 가지 제안이 제출되었다:[7] 웹 서비스 보안 (WS-Security) 및 웹 서비스 보안 추가 사양. 그 결과 WS-Security가 발표되었다:

  • WS-Security 1.0은 2004년 4월 19일에 출시되었다.
  • 버전 1.1은 2006년 2월 17일에 출시되었다.

OASIS가 발표한 버전 1.0 표준은 IBM, 마이크로소프트, 베리사인 컨소시엄이 제안한 표준과 여러 중요한 차이점을 포함했다. 많은 시스템이 제안된 표준을 사용하여 개발되었으며, 이러한 차이점은 OASIS 표준으로 개발된 시스템과 호환되지 않게 만들었다.

일부는 OASIS 이전 사양을 "WS-Security Draft 13"[8] 또는 웹 서비스 보안 핵심 사양이라고 부른다. 그러나 이러한 이름은 널리 알려져 있지 않으며, 오늘날 응용 프로그램이나 서버가 OASIS 이전 또는 이후 사양을 사용하고 있는지 명확하게 식별하기 어렵다. 대부분의 포럼 게시물은 "wsse" XML 네임스페이스 접두사를[9] URL (및 다른 버전의 유사 URL)에 사용하도록 의무화했기 때문에 OASIS 이전 버전을 지칭할 때 "WSSE" 키워드를 사용한다.

이 프로토콜은 공식적으로 WSS라고 불리며 Oasis-Open에서 위원회를 통해 개발되었다.

Remove ads

관련 사양

다음 초안 사양은 WS-Security와 관련이 있다: WS-Federation, WS-Privacy, WS-Test.

다음 승인된 사양은 WS-Security와 관련이 있다: WS-Policy, WS-SecureConversation, WS-Trust, ID-WSF.

다음 아키텍처는 WS-Security를 사용한다: TAS3.

대안

점대점 상황에서 기밀성 및 데이터 무결성은 전송 계층 보안 (TLS)을 사용하여 웹 서비스에 적용될 수도 있다. 예를 들어, HTTPS를 통해 메시지를 보내는 것이다. 그러나 WS-Security는 메시지가 시작 노드에서 전송된 후에도 메시지의 무결성과 기밀성을 유지하는 더 넓은 문제를 해결하여 소위 엔드 투 엔드 보안을 제공한다.

TLS를 적용하면 키와 메시지 서명을 전송 전에 XML로 인코딩할 필요가 없어 관련된 오버헤드를 크게 줄일 수 있다. TLS 사용의 한 가지 과제는 메시지가 응용 프로그램 수준 프록시 서버를 통과해야 하는 경우인데, 이 경우 라우팅을 위해 요청을 볼 수 있어야 한다. 이러한 예에서 서버는 클라이언트가 아닌 프록시에서 오는 요청을 보게 된다. 이는 프록시가 클라이언트의 키와 인증서 사본을 가지고 있거나, 서버가 신뢰하는 서명 인증서를 가지고 있어 클라이언트와 일치하는 키/인증서 쌍을 생성할 수 있도록 하여 해결할 수 있다. 그러나 프록시는 메시지에서 작동하지 않으므로 엔드 투 엔드 보안이 아닌 점대점 보안만 보장한다.

Remove ads

같이 보기

각주

외부 링크

Loading related searches...

Wikiwand - on

Seamless Wikipedia browsing. On steroids.

Remove ads
Remove ads