WS-보안

WS-Security

웹 서비스 보안(WS-Security, WSS)은 웹 서비스에 보안을 적용하기 위한 SOAP의 확장이다.웹 서비스 사양에 가입되어 있으며, OASIS에서 발행하였다.

프로토콜은 메시지에 대해 무결성과 기밀성이 어떻게 집행될 수 있는지를 명시하고, SAML(Security Assertion Markup Language), Kerberos, X.509와 같은 다양한 보안 토큰 형식의 통신을 허용한다.그것의 주요 초점은 엔드투엔드 보안을 제공하기 위해 XML 시그니처와 XML 암호화의 사용이다.

특징들

WS-Security는 다음과 같은 세 가지 주요 메커니즘을 설명한다.

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

규격은 다양한 서명 형식, 암호화 알고리즘, 다중 트러스트 도메인을 허용하며, 다음과 같은 다양한 보안 토큰 모델에 개방된다.

  • X.509 인증서,
  • 케르베로스 표,
  • 사용자 ID/암호 자격 증명,
  • SAML 주장 및
  • 사용자 정의 토큰

토큰 형식과 의미론은 관련 프로파일 문서에 정의되어 있다.

WS-Security는 SOAP 메시지의 헤더에 보안 기능을 통합하여 애플리케이션 계층에서 작업한다.

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

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

사용 사례

엔드 투 엔드 보안

SOAP 중개자가 필요하며, 그 중개자가 신뢰도가 높거나 낮을 경우, 메시지는 서명되고 선택적으로 암호화되어야 한다.이는 TCP(전송 제어 프로토콜) 연결을 종료하는 네트워크 경계에서 애플리케이션 수준 프록시의 경우일 수 있다.

부인하지 않음

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

대체 전송 바인딩

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

프록시/공통 보안 토큰 역방향

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

문제들

  • 서비스 제공자와 소비자 사이에 빈번한 메시지 교환이 있을 경우 XML SIG와 XML ENC의 오버헤드가 상당하다.엔드투엔드 보안이 필요한 경우 WS-SecureConversation과 같은 프로토콜은 오버헤드를 줄일 수 있다.충분할 경우 암호화 또는 서명만 사용하십시오. 두 작업의 조합은 단일 작업의 합보다 상당히 느리기 때문이다.아래 성능을 참조하십시오.
  • SOAP, SAML, XML EnC, XML SIG와 같은 여러 XML 스키마타의 병합은 애플리케이션 서버에서 관리하기 어려운 표준화와 구문 분석과 같은 서로 다른 버전의 라이브러리 함수에 종속성을 야기할 수 있다.
  • CBC 모드 암호화/암호 해독만 적용하거나 암호 해독 전 보안 체크섬(서명 또는 MAC)을 확인하지 않고 CBC 모드 암호 해독을 적용하면 패딩 오라클 공격에 취약할 가능성이 높다.[1]

퍼포먼스

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

2005년[2] 평가에서는 WSS4J가 펜티엄 4/2.8GHz CPU에서 WS-SecureConversation 및 WS-SecureConversation을 통해 처리한 크기와 복잡성이 다른 25가지 SOAP 메시지를 측정했다. 일부 결과는 다음과 같다.

  • 암호화는 서명보다 빨랐다.
  • 암호화와 서명은 단독 서명보다 2-7배 느렸고 상당히 큰 문서를 생산했다.
  • 메시지 유형에 따라 WS-SecureConversation은 최적의 경우 처리 시간을 절반으로 줄이거나 차이가 없었다.
  • 최대 100킬로바이트의 배열까지 서명하거나 암호화하는 데 10밀리초가 채 걸리지 않았지만 SOAP의 보안 작업을 수행하는 데 약 100~200시간이 걸렸다.

2006년의[3] 또 다른 벤치마크는 다음과 같은 비교 결과를 낳았다.

보안 메커니즘 메시지/초
WS-보안(X.509) XML 서명 및 암호화 352
WS-SecureConversation XML 서명 및 암호화 798
전송 계층 보안 2918

역사

웹 서비스는 처음에 기본 전송 보안에 의존했다.사실 대부분의 구현은 여전히[citation needed] 그렇다.SOAP가 HTTP, SMTP 등 다중 전송 바인딩을 허용함에 따라 SOAP 수준의 보안 메커니즘이 필요했다.교통안전에 대한 의존도 때문에 종단간 보안이 없었던 것도 한 요인이었다.

이 프로토콜은 원래 IBM, Microsoft, VeriSign에 의해 개발되었다.그들의 원래 명세서는[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 Graft 13"[8] 또는 Web Services Security Core Specification이라고 부른다.그러나 이러한 이름들은 널리 알려져 있지 않고 실제로 오늘날 애플리케이션이나 서버가 OASIS 이전 또는 사후 사양을 사용하고 있는지 명확하게 식별하기 어렵다.대부분의[9] 포럼 게시물은 "wssE" XML 네임스페이스 접두사 사용을 URL(및 다른 버전의 유사한 URL)에 의무화했기 때문에 "WSE"라는 키워드를 사용하여 OASIS 이전 버전을 참조한다.

이 프로토콜은 공식적으로 WSS라고 불리며 오아시스 오픈에서 위원회를 통해 개발된다.

관련 사양

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

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

WS-Security를 활용하는 아키텍처는 다음과 같다.TAS3.

대안

지점간 상황의 경우, 예를 들어, HTTPS를 통해 메시지를 전송함으로써 기밀성과 데이터 무결성이 웹 서비스에서도 집행될 수 있다. 그러나 WS-Security는 메시지가 전송된 후까지 메시지의 무결성과 기밀성을 유지하는 광범위한 문제를 해결한다.팅 노드, 이른바 엔드 투 엔드 보안을 제공하는 노드.

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

참고 항목

참조

  1. ^ Sabarnij, Sergej. "Padding Oracle Attacks – breaking theoretical secure cryptosystems in the real world" (PDF). Ruhr Universität Bochum.
  2. ^ 홍빈 류, 슈라이데프 팔리카라, 제프리 폭스: 웹 서비스 보안의 성능
  3. ^ Francois Lascelles, Aaron Flint: WS 보안 성능.X509 프로파일 대비 안전한 대화
  4. ^ 밥 앳킨슨 외:웹 서비스 보안(WS-Security)
  5. ^ 밥 앳킨슨 외:웹 서비스 보안(WS-Security)
  6. ^ Giovanni Della-Libera, Phillip Hallam-Baker Maryann Hondo: 웹 서비스 보안 부록
  7. ^ OASIS 웹 서비스 보안 TC
  8. ^ 웹 서비스 보안: SOAP 메시지 보안 – 작업 초안 13
  9. ^ schemas.xmlsoap.org

외부 링크