다음을 통해 공유

웹 서비스 세계의 보안: 제안된 아키텍처 및 로드맵

  • 아티클

 

2002년 4월 7일
버전 1.0

© 2001-2002 International Business Machines Corporation. 모든 권한이 예약되어 있습니다.

이 문서는 예비 문서이며 시간이 지남에 따라 크게 변경될 수 있습니다. 이 문서에 포함된 정보는 발행일 기준으로 논의된 문제에 대한 International Business Machine 및 Microsoft Corporation의 현재 보기를 나타냅니다. IBM과 Microsoft는 변화하는 시장 상황에 대응해야 하므로 IBM과 Microsoft의 약정으로 해석되어서는 안 되며 IBM과 Microsoft는 게시 날짜 이후에 제시된 정보의 정확성을 보장할 수 없습니다.

이 문서에 포함된 정보의 프레젠테이션, 배포 또는 기타 보급은 IBM 또는 Microsoft 및 기타 타사에서 소유하거나 제어하는 지적 재산권에 대한 명시적 또는 묵시적 라이선스가 아닙니다. IBM, Microsoft 및 기타 제3자는 이 문서의 주제를 다루는 특허, 특허 출원, 상표, 저작권 또는 기타 지적 재산권을 가질 수 있습니다. 이 문서의 제공은 IBM 또는 Microsoft 또는 다른 제3자의 특허, 상표, 저작권 또는 기타 지적 재산권에 대한 라이선스를 제공하지 않습니다. 예제 회사, 조직, 제품, 도메인 이름, 전자 메일 주소, 로고, 사람, 장소 및 여기에 설명된 이벤트는 가상입니다. 실제 회사, 조직, 제품, 도메인 이름, 전자 메일 주소, 로고, 사람, 장소 또는 이벤트와의 연결은 의도되거나 유추되어야 합니다.

본 문서와 여기에 포함된 정보는 "AS IS" 기준 및 관련 법률에서 허용하는 최대 범위까지 제공되며, IBM과 Microsoft는 AS IS 및 WITH ALL FAULTS 문서를 제공하며, 이에 따라 명시적, 묵시적 또는 법적 조건(명시적, 묵시적 또는 법적 보증을 포함하되 이에 국한되지 않음)을 부인합니다. 업무 또는 상품성 조건, 특정 목적에 대한 적합성, 응답의 정확성 또는 완전성, 결과, 장인 같은 노력, 바이러스 부족, 과실 부족 등 문서 관련 모든 것. 또한 문서와 관련하여 소유권, 조용한 즐거움, 조용한 소유, 설명에 대한 서신 또는 지적 재산권의 NON-INFRINGEMENT 보증 또는 조건이 없습니다.

어떠한 경우에도 IBM 또는 MICROSOFT는 계약, 불법 행위, 보증 또는 기타 계약 또는 이 문서와 관련된 다른 계약에서 발생하는 대체 상품 또는 서비스 조달 비용, 손실된 이익, 사용 손실, 데이터 손실 또는 부수적, 결과적, 직접적, 간접적 또는 특별 손해에 대해 다른 당사자에게 책임을 지지 않습니다. 그러한 당사자가 그러한 손해의 가능성에 대한 사전 통보를 했는지 여부.

추상적인

이 문서에서는 웹 서비스 환경 내에서 보안을 해결하기 위한 제안된 전략을 설명합니다. 다양한 시스템이 플랫폼 및 언어 중립적 방식으로 안전하게 상호 운용할 수 있는 방식으로 널리 사용되는 여러 보안 모델, 메커니즘 및 기술(대칭 및 공개 키 기술 포함)을 지원, 통합 및 통합하는 포괄적인 웹 서비스 보안 모델을 정의합니다. 또한 이러한 사양을 함께 사용하는 방법을 보여 주는 일련의 사양 및 시나리오에 대해서도 설명합니다.

요약

IT 업계는 거의 2년 동안 웹 서비스에 대해 이야기해 왔습니다. 웹 서비스가 파일럿 프로그램과 대규모 프로덕션에서 사용됨에 따라 조직, 기업 및 인터넷을 통해 애플리케이션을 연결하는 느슨하게 결합된 언어 중립적인 플랫폼 독립적 방법을 사용할 경우의 이점은 더욱 분명해지고 있습니다. 앞으로 고객, 업계 분석가 및 언론은 웹 서비스가 더 주류가 될 때 해결해야 할 주요 영역인 보안을 식별합니다. 이 문서에서는 업계가 실제 비즈니스의 웹 서비스 보안 요구 사항을 충족할 수 있을 만큼 포괄적이면서도 유연한 표준 기반 아키텍처를 생성하고 구현할 수 있는 기술 전략 및 로드맵을 제안합니다.

새로운 웹 서비스 아키텍처의 주요 이점은 상호 운용 가능한 통합 솔루션을 제공하는 기능입니다. 포괄적인 보안 모델을 적용하여 웹 서비스의 무결성, 기밀성 및 보안을 보장하는 것은 조직과 고객 모두에게 매우 중요합니다.

고객과 업계 모두에서 표현된 우려에 대응하여 IBM과 Microsoft는 웹 서비스 환경에서 교환되는 메시지에 대한 보호를 제공하는 방법을 다루는 일련의 웹 서비스 보안 사양을 개발하기 위해 이 제안된 웹 서비스 보안 계획 및 로드맵에 대해 공동 작업했습니다.

처음으로 공개 키 인프라, Kerberos 등과 같은 이전에 호환되지 않는 보안 기술을 결합하는 보안 모델을 만들었습니다. 요컨대, 이것은 이상화된 프레임워크가 아니라 오늘날 고객이 살고 있는 다른 유형의 IT 세계에서 보안 웹 서비스를 구축할 수 있는 실용적인 프레임워크입니다.

이 문서에서는 다양한 애플리케이션 및 비즈니스 토폴로지에서 인증, 권한 부여, 개인 정보 보호, 신뢰, 무결성, 기밀성, 보안 통신 채널, 페더레이션, 위임 및 감사를 비롯한 보안 기술을 다루는 광범위한 사양 집합을 제공합니다. 이러한 사양은 확장 가능하고 유연하며 보안 인프라에 대한 기존 투자를 최대화하는 프레임워크를 제공합니다. 이러한 사양은 IBM 및 Microsoft에서 이전에 제안한 유사한 사양(즉, SOAP-Security, WS-Security 및 WS-License 사양)으로 표현된 아이디어를 소급하여 확장합니다.

웹 서비스 모델의 핵심인 자연 확장성을 활용하여 사양은 SOAP, WSDL, XML 디지털 서명, XML 암호화 및 SSL/TLS와 같은 기본 기술을 기반으로 합니다. 이를 통해 웹 서비스 공급자 및 요청자는 애플리케이션의 개별 보안 요구 사항을 충족하는 솔루션을 개발할 수 있습니다.

IBM과 Microsoft는 고객, 파트너 및 표준 기관과 협력하여 단계적 접근 방식으로 이 보안 모델을 발전시키고 개선할 계획입니다. WS-Security 사양을 사용하여 이러한 노력을 시드하고 있습니다. WS-Security 메시지의 무결성 및 기밀성을 보호하기 위한 핵심 기능과 보안 관련 클레임을 메시지와 연결하기 위한 메커니즘을 정의합니다. WS-Security 이러한 노력의 초석이지만, 시작에 불과하며 업계와 협력하여 정책, 신뢰 및 개인 정보 보호 문제를 다룰 추가 사양을 생성할 것입니다.

이 문서에서 설명하는 문제 및 솔루션을 최대한 구체적으로 만들기 위해 웹 서비스의 현재 및 예상 애플리케이션을 반영하는 몇 가지 시나리오에 대해 설명합니다. 여기에는 방화벽 처리, 개인 정보 보호, 브라우저 및 모바일 클라이언트 사용, 액세스 제어, 위임 및 감사가 포함됩니다.

우리는 다양한 제안 사양의 상호 운용성과 일관된 구현을 보장하기 위해 무엇을 할 수 있는지에 대한 우려를 예상합니다. 이 문제를 해결하기 위해 IBM과 Microsoft는 표준 조직, 개발자 커뮤니티 및 WS-I.org 같은 업계 조직과 긴밀히 협력하여 도구 공급업체에 지침을 제공하는 상호 운용성 프로필 및 테스트를 개발할 것입니다.

이 문서에서는 구현 시 고객이 보안 인프라에 대한 기존 투자를 활용하고 확장하는 상호 운용 가능하고 안전한 웹 서비스를 빌드하는 동시에 웹 서비스 기술이 제공하는 통합 및 상호 운용성 이점을 최대한 활용할 수 있도록 하는 포괄적인 모듈식 솔루션을 간략하게 설명합니다.

1 소개 및 동기 부여

웹 서비스에 대한 보안 기능 및 구성 요소의 포괄적인 모델을 제공하려면 현재 사용 가능한 프로세스와 기술을 향후 애플리케이션의 진화하는 보안 요구 사항과 통합해야 합니다. 통합 개념을 요구합니다. 기술(보안 메시징) 및 비즈니스 프로세스(정책, 위험, 신뢰) 문제에 대한 솔루션이 필요합니다. 마지막으로 플랫폼 공급업체, 애플리케이션 개발자, 네트워크 및 인프라 공급자 및 고객의 조정된 노력이 필요합니다.

사용 가능한 보안 기술의 범위를 통합하면 애플리케이션 보안의 기능 요구 사항이 사용되는 특정 메커니즘에서 추상화되어야 합니다. 예를 들어, 온라인 구매를 하는 고객은 각 장치가 적절한 ID를 안전하게 표현할 수 있는 한 휴대폰 또는 랩톱 컴퓨터를 사용하는지 여부에 영향을 받지 않아야 합니다.

목표는 고객이 다른 유형의 시스템을 사용하여 상호 운용 가능한 솔루션을 쉽게 빌드할 수 있도록 하는 것입니다. 예를 들어 이 문서의 뒷부분에서 제안된 보안 메시징 모델은 보다 일반적인 기능의 특정 구현으로 PKI(공개 키 인프라) 및 Kerberos ID 메커니즘을 모두 지원하며 추가 보안 메커니즘을 지원하도록 확장할 수 있습니다. 단일 보안 모델의 추상화 통합을 통해 조직은 다양한 기술을 사용하여 조직과 통신하면서 보안 기술에 대한 기존 투자를 사용할 수 있습니다.

또한 서로 다른 ID 메커니즘을 사용하는 조직이 웹 서비스를 사용하여 공동 작업할 때 보안 신뢰 모델은 적절한 권한 부여로 구성할 때 조직이 상호 연결할 수 있는 유연한 프레임워크를 제공합니다.

동시에 모든 고객 및 모든 웹 서비스에는 특정 비즈니스 요구 사항 및 운영 환경에 따라 고유한 보안 요구 사항이 있습니다. 예를 들어 작업 그룹 설정 내에서 단순성과 운영 편의성은 가장 중요한 문제이며, 공용 인터넷 애플리케이션의 경우 공동 서비스 거부 공격을 견딜 수 있는 능력이 더 높은 우선 순위입니다. 이러한 요구 사항은 여러 가지 방법으로 결합되고 다양한 수준의 특이성으로 표현될 수 있으므로 웹 서비스 보안에 대한 성공적인 접근 방식을 사용하려면 정책 및 구성을 통해 다양한 보안 솔루션을 사용하도록 설정하는 유연하고 상호 운용 가능한 보안 기본 형식 집합이 필요합니다.

이러한 문제를 해결하기 위해 이 문서에서는 이전에 서로 다른 기술을 통합하는 일련의 보안 추상화를 기반으로 안전하고 상호 운용 가능한 웹 서비스를 만드는 진화적 접근 방식을 제안합니다. 이를 통해 전체 프레임워크 내의 특정 고객 요구 사항을 전문화하는 동시에 시간이 지남에 따라 기술이 발전하고 증분 방식으로 배포될 수 있습니다.

이러한 진화적 접근 방식의 예로, 보안 메시징 모델을 기존 전송 수준 보안 솔루션에 추가할 수 있습니다. 고객은 메시지가 전달되는 기존 웹 서비스(예: SSL/TLS(Secure Sockets Layer))에 메시지 수준 무결성 또는 영구 기밀성(메시지 요소 암호화)을 추가할 수 있습니다. 이제 메시지는 전송 계층을 넘어 유지되는 무결성(또는 기밀성)을 갖게 됩니다.

제안된 모델 및 사양은 여러 공급업체에서 광범위하게 사용할 수 있으며 적절한 표준 조직에서 고려될 것으로 예상합니다. 모델, 사양 및 표준 프로세스를 함께 사용하면 기업은 기존 애플리케이션의 보안을 빠르고 비용 효율적으로 높이고 상호 운용 가능한 안전한 새로운 웹 서비스를 자신 있게 개발할 수 있습니다.

이러한 모델의 비즈니스 이점은 분명합니다. 웹 서비스에 대한 포괄적인 보안 아키텍처를 프레이밍하면 비즈니스 프로세스가 웹 서비스로 점점 더 재구성됨에 따라 조직과 고객은 투자 및 자산을 더 잘 보호할 수 있습니다.

Web Services 보안 모델 용어

용어는 기술마다 다르기 때문에 이 문서에서는 다양한 보안 형식 및 메커니즘에 일관되게 적용될 수 있는 몇 가지 용어를 정의합니다. 따라서 여기서 사용되는 용어는 다른 사양과 다를 수 있으며 독자가 선호하는 어휘에 용어를 매핑할 수 있도록 정의됩니다.

  • 웹 서비스- "웹 서비스"라는 용어는 광범위한 네트워크 기반 애플리케이션 토폴로지에 광범위하게 적용됩니다. 이 문서에서는 "웹 서비스"라는 용어를 사용하여 XML, SOAP, WSDL 및 HTTP를 비롯한 기존 및 새로운 웹 기술 표준을 적용하여 기능 및 인터페이스가 잠재적 사용자에게 노출되는 애플리케이션 구성 요소를 설명합니다. 웹 사이트, 브라우저 기반 상호 작용 또는 플랫폼 종속 기술과 달리 웹 서비스는 정의된 형식 및 프로토콜을 통해 플랫폼 독립적이고 언어 중립적인 방식으로 컴퓨터에서 컴퓨터로 제공되는 서비스입니다.

  • 보안 토큰- 보안 관련 정보(예: X.509 인증서, Kerberos 티켓 및 인증자, SIM 카드의 모바일 디바이스 보안 토큰, 사용자 이름 등)의 표현으로 보안 토큰을 정의합니다.

    다음 다이어그램에서는 다양한 종류의 보안 토큰을 보여 줍니다.

  • 서명된 보안 토큰- 서명된 보안 토큰 발급자에서 암호화하여 보증하는 일련의 관련 클레임(어설션)을 포함하는 보안 토큰으로 정의합니다. 서명된 보안 토큰의 예로는 X.509 인증서 및 Kerberos 티켓이 있습니다.

  • 클레임- 클레임은 주체 또는 주체를 클레임과 연결하는 다른 당사자의 주제에 대한 진술입니다. 중요한 점은 이 사양이 수행할 수 있는 클레임 유형을 제한하지 않으며 이러한 클레임이 표현되는 방식을 제한하려고 하지 않는다는 것입니다. 클레임은 잠재적으로 메시지에 서명하거나 암호화하는 데 사용되는 키에 관한 것일 수 있습니다. 클레임은 보안 토큰이 전달하는 문일 수 있습니다. 예를 들어 클레임을 사용하여 보낸 사람 ID 또는 권한 있는 역할을 어설션할 수 있습니다.

  • 주체- 보안 토큰의 주체는 보안 토큰에 표현된 클레임이 적용되는 보안 토큰의 주체(예: 사람, 애플리케이션 또는 비즈니스 엔터티)입니다. 특히 주체는 보안 토큰의 소유자가 보안 토큰의 소유권을 증명하는 데 필요한 정보를 소유합니다.

  • 소유 증명- 보안 토큰 또는 클레임 집합의 소유권을 증명하는 과정에서 사용되는 정보로 소유 증명 정의합니다. 예를 들어 소유 증명은 공개 키를 포함하는 보안 토큰과 연결된 프라이빗 키일 수 있습니다.

  • 웹 서비스 엔드포인트 정책- 웹 서비스는 메시지를 처리하기 위해 필요한 클레임을 유연하게 지정할 수 있습니다. 이러한 필수 클레임 및 관련 정보를 "웹 서비스 엔드포인트 정책"으로 통칭합니다. 엔드포인트 정책은 XML로 표현될 수 있으며 인증(예: 사용자 또는 그룹 ID 증명), 권한 부여(예: 특정 실행 기능 증명) 또는 기타 사용자 지정 요구 사항과 관련된 요구 사항을 나타내는 데 사용할 수 있습니다.

  • 클레임 요구 사항- 클레임 요구 사항은 메시지의 전체 메시지 또는 요소, 지정된 형식의 모든 작업 또는 특정 상황에서만 작업에 연결할 수 있습니다. 예를 들어 서비스에서 요청자가 명시된 한도보다 큰 구매 금액에 대한 권한을 증명하도록 요구할 수 있습니다.

  • 중간자- SOAP 메시지가 초기 요청자에서 서비스로 전송되므로 메시지 라우팅 또는 메시지 수정과 같은 작업을 수행하는 중개자가 운영할 수 있습니다. 예를 들어 중간자는 헤더를 추가하거나, 메시지의 조각을 암호화 또는 암호 해독하거나, 보안 토큰을 추가할 수 있습니다. 이러한 경우 메시지의 변경이 메시지 무결성을 무효화하거나 신뢰 모델을 위반하거나 책임을 삭제하지 않도록 주의해야 합니다.

  • 행위자- 행위자 URI로 식별되고 SOAP 메시지를 처리하는 중간 또는 엔드포인트(SOAP 사양에 정의됨)입니다. 사용자나 클라이언트 소프트웨어(예: 브라우저)는 행위자가 아닙니다.

웹 서비스 보안 모델 원칙

URI로 식별된 서비스 엔드포인트에 SOAP 메시지를 보내고, 특정 작업을 요청하고, SOAP 메시지 응답(오류 표시 포함)을 수신하여 웹 서비스에 액세스할 수 있습니다. 이러한 맥락에서 웹 서비스 보안의 광범위한 목표는 메시지의 무결성 및 기밀성을 확보하고 정책이 요구하는 클레임을 표현하는 메시지의 요청에 대해서만 서비스가 작동하도록 하는 기능을 제공하는 자회사의 목표로 나뉩니다.

현재는 TLS(사실상 전송 계층 보안)와 함께 SSL(Secure Socket Layer) 사용하여 웹 서비스 애플리케이션에 대한 전송 수준 보안을 제공합니다. SSL/TLS는 인증, 데이터 무결성 및 데이터 기밀성을 비롯한 여러 보안 기능을 제공합니다. SSL/TLS를 사용하면 지점 및 지점 보안 세션을 사용할 수 있습니다.

IPSec 웹 서비스에 중요할 수 있는 전송 보안을 위한 또 다른 네트워크 계층 표준입니다. SSL/TLS와 마찬가지로 IPSec은 호스트 인증, 데이터 무결성 및 데이터 기밀성을 갖춘 보안 세션도 제공합니다.

오늘날의 웹 서비스 애플리케이션 토폴로지에는 모바일 디바이스, 게이트웨이, 프록시, 부하 분산 장치, DMZ(완만 영역), 아웃소싱 데이터 센터 및 전역적으로 분산되고 동적으로 구성된 시스템의 광범위한 조합이 포함됩니다. 이러한 모든 시스템은 메시지 처리 중개자가 메시지를 전달하는 기능을 사용합니다. 특히 SOAP 메시지 모델은 물리적 네트워크 및 애플리케이션 인프라를 추상화하여 중간 행위자와 다중 홉 토폴로지를 자주 통합하는 논리적 엔드포인트에서 작동합니다.

전송 계층을 벗어나는 중개자가 데이터를 받고 전달하면 데이터의 무결성과 데이터와 함께 흐르는 모든 보안 정보가 손실될 수 있습니다. 이렇게 하면 모든 업스트림 메시지 프로세서가 이전 중개자가 수행한 보안 평가에 의존하고 메시지 내용의 처리를 완전히 신뢰하게 됩니다. 포괄적인 웹 서비스 보안 아키텍처에 필요한 것은 엔드 투 엔드 보안을 제공하는 메커니즘입니다. 성공적인 웹 서비스 보안 솔루션은 전송 및 애플리케이션 계층 보안 메커니즘을 모두 활용하여 포괄적인 보안 기능 제품군을 제공할 수 있습니다.

지점 및 지점 구성

엔드 투 엔드 구성

여기에 설명된 웹 서비스 보안 모델을 사용하면 다음 프로세스를 통해 이러한 목표를 달성할 수 있습니다.

  • 웹 서비스는 들어오는 메시지가 클레임 집합(예: 이름, 키, 권한, 기능 등)을 증명하도록 요구할 수 있습니다. 필요한 클레임 없이 메시지가 도착하면 서비스에서 메시지를 무시하거나 거부할 수 있습니다. 필요한 클레임 및 관련 정보 집합을 정책참조합니다.
  • 요청자는 보안 토큰을 메시지와 연결하여 필요한 클레임 증명이 포함된 메시지를 보낼 수 있습니다. 따라서 메시지는 모두 특정 작업을 요구하고 보낸 사람에게 작업을 요구하는 클레임이 있음을 증명합니다.
  • 요청자에게 필요한 클레임이 없는 경우 요청자 또는 대신 다른 사용자가 다른 웹 서비스에 문의하여 필요한 클레임을 가져오려고 시도할 수 있습니다. 보안 토큰 서비스라고 하는 이러한 다른 웹 서비스에는 자체 클레임 집합이 필요할 수 있습니다. 보안 토큰 서비스는 보안 토큰을 발급하여 서로 다른 트러스트 도메인 간의 트러스트를 중개합니다.

이 모델은 아래 그림에 설명되어 있으며, 모든 요청자가 서비스일 수도 있고 보안 토큰 서비스가 정책을 표현하고 보안 토큰을 요구하는 것을 포함하여 웹 서비스일 수도 있음을 보여 줍니다.

클레임, 정책 및 보안 토큰인 이 일반 메시징 모델은 ID 기반 보안, 액세스 제어 목록 및 기능 기반 보안과 같은 몇 가지 더 구체적인 모델을 하위로 사용하고 지원합니다. X.509 공개 키 인증서, Kerberos 공유 비밀 티켓 및 암호 다이제스트와 같은 기존 기술을 사용할 수 있습니다. 나중에 설명하겠습니다. 또한 시스템이 서로 다른 보안 기술 간의 브리지를 구축할 수 있도록 통합 추상화도 제공합니다. 일반 모델은 상위 수준 키 교환, 인증, 권한 부여, 감사 및 신뢰 메커니즘을 생성하기에 충분합니다.

2 웹 서비스 보안 사양

여기에 명시된 보안 전략과 아래에 도입된 WS-Security 사양은 이 제안된 웹 서비스 보안 모델의 전략적 목표와 초석을 제공합니다.

앞으로도 고객, 파트너 및 표준 조직과 협력하여 초기 웹 서비스 보안 사양 집합을 개발하는 프로세스를 계속하고 있습니다.

이 집합에는 다른 보안 사양의 기초를 제공하는 메시지 보안 모델(WS-Security)이 포함됩니다. 이에 계층화된 웹 서비스 엔드포인트 정책(WS-Policy), 트러스트 모델(WS-Trust) 및 개인 정보 모델(WS-Privacy)을 포함하는 정책 계층이 있습니다. 이러한 초기 사양은 트러스트 도메인 간에 보안 상호 운용 가능한 웹 서비스를 설정하기 위해 노력할 수 있는 기반을 제공합니다.

이러한 초기 사양을 기반으로 고객, 파트너 및 표준 조직과 지속적으로 협력하여 보안 대화(WS-SecureConversation), 페더레이션 신뢰(WS-Federation) 및 권한 부여(WS-Authorization)를 포함하는 페더레이션 보안에 대한 후속 사양을 제공할 것입니다.

이러한 보안 사양의 조합은 오늘날의 더 기본적인 보안 메커니즘으로 구현하기 어려운 많은 시나리오(이 문서의 뒷부분에 설명되어 있음)를 가능하게 합니다.

이와 동시에 감사, 관리 및 개인 정보 보호와 관련된 사양을 사용하여 웹 서비스 보안 프레임워크를 향상시키는 관련 활동을 제안하고 앞으로 나아갈 것입니다.

또한 IBM과 Microsoft는 상호 운용성 프로필에 대한 WS-I 같은 조직과 협력하기 위해 최선을 다하고 있습니다.

보안 사양, 관련 활동 및 상호 운용성 프로필의 조합을 통해 고객은 상호 운용 가능한 보안 웹 서비스를 쉽게 빌드할 수 있습니다.

제안된 각 사양은 아래에 요약되어 있습니다.

초기 사양

  • WS-Security: SOAP 메시지에 서명 및 암호화 헤더를 연결하는 방법을 설명합니다. 또한 X.509 인증서 및 Kerberos 티켓과 같은 이진 보안 토큰을 포함한 보안 토큰을 메시지에 연결하는 방법을 설명합니다.
  • WS-Policy: 중개자 및 엔드포인트에 대한 보안(및 기타 비즈니스) 정책의 기능 및 제약 조건(예: 필수 보안 토큰, 지원되는 암호화 알고리즘, 개인 정보 보호 규칙)을 설명합니다.
  • WS-Trust: 웹 서비스가 안전하게 상호 운용될 수 있도록 하는 신뢰 모델의 프레임워크를 설명합니다.
  • WS-Privacy: 웹 서비스 및 요청자가 개인 정보 기본 설정 및 조직의 개인 정보 취급 방침을 명시하는 방법에 대한 모델을 설명합니다.

Follow-On 사양

  • WS-SecureConversation: 보안 컨텍스트 교환 및 세션 키 설정 및 파생을 포함하여 당사자 간의 메시지 교환을 관리하고 인증하는 방법을 설명합니다.
  • WS-Federation: 페더레이션 ID에 대한 지원을 포함하여 다른 유형의 페더레이션 환경에서 트러스트 관계를 관리하고 중개하는 방법을 설명합니다.
  • WS-Authorization: 권한 부여 데이터 및 권한 부여 정책을 관리하는 방법을 설명합니다.

WS-Security 보안을 제공하려면 다양한 기능 영역에서 설명, 사양 및 프로필의 프로덕션에 대한 실사가 필요합니다. 이러한 문서는 사양 프로세스를 진행하면서 고객의 요구와 웹 서비스 개발 커뮤니티의 요구 사항 및 자체 교육 프로세스의 균형을 맞추는 프로세스를 통해 변경되고 발전할 것입니다.

WS-Security

WS-Security 메시지 무결성 및 메시지 기밀성을 통해 보호 품질을 제공하기 위해 SOAP 메시징의 향상된 기능을 설명합니다. 또한 이 사양은 SOAP 메시지 내에 보안 토큰을 연결하고 포함하는 방법을 정의합니다. 마지막으로 이진 인코딩된 보안 토큰(예: X.509 인증서)을 지정하기 위한 메커니즘이 제공됩니다. 이러한 메커니즘은 다양한 보안 모델 및 암호화 기술을 수용하기 위해 독립적으로 또는 함께 사용할 수 있습니다.

WS-Security 보안 토큰을 메시지와 연결하기 위한 범용 메커니즘을 제공합니다. WS-Security특정 유형의 보안 토큰이 필요하지 않습니다. 확장 가능하도록 설계되었습니다(예: 여러 보안 토큰 형식 지원). 예를 들어 요청자는 특정 비즈니스 인증을 가지고 있다는 ID 증명과 증거를 제공할 수 있습니다.

메시지 무결성은 XML 서명 보안 토큰(키 데이터를 포함하거나 암시할 수 있음)과 함께 활용하여 수정 없이 메시지가 전송되도록 하여 제공됩니다. 무결성 메커니즘은 여러 행위자가 여러 서명을 지원하고 추가 서명 형식을 지원하도록 확장할 수 있도록 설계되었습니다. 서명은 보안 토큰을 참조(즉, 가리키기)할 수 있습니다.

마찬가지로, 메시지 기밀성은 XML 암호화 보안 토큰과 함께 활용하여 SOAP 메시지의 일부를 기밀로 유지함으로써 제공됩니다. 암호화 메커니즘은 여러 행위자의 추가 암호화 기술, 프로세스 및 작업을 지원하도록 설계되었습니다. 암호화는 보안 토큰을 참조할 수도 있습니다.

마지막으로 WS-Security 이진 보안 토큰을 인코딩하는 메커니즘을 설명합니다. 특히 이 사양에서는 X.509 인증서 및 Kerberos 티켓을 인코딩하는 방법과 불투명한 암호화된 키를 포함하는 방법을 설명합니다. 또한 메시지에 포함된 보안 토큰의 특성을 자세히 설명하는 데 사용할 수 있는 확장성 메커니즘도 포함되어 있습니다.

WS-Policy

WS-Policy 보낸 사람과 수신자가 요구 사항 및 기능을 지정하는 방법을 설명합니다.

WS-Policy 완전히 확장 가능하며 설명될 수 있는 요구 사항 및 기능 유형에 제한을 두지 않습니다. 그러나 사양은 개인 정보 특성, 인코딩 형식, 보안 토큰 요구 사항 및 지원되는 알고리즘을 포함하여 몇 가지 기본 서비스 특성을 식별할 가능성이 높습니다.

이 사양은 보안 정책 이상을 지원할 수 있는 일반 SOAP 정책 형식을 정의합니다. 또한 이 사양은 서비스 정책을 SOAP 메시지와 연결하거나 연결하는 메커니즘을 정의합니다.

WS-Trust

WS-Trust 직접 및 조정된 트러스트 관계(제3자 및 중개자 포함)를 설정하는 모델을 설명합니다.

이 사양에서는 보안 토큰 발급 서비스 생성을 통해 트러스트를 중개하기 위한 기준으로 기존 직접 신뢰 관계를 사용하는 방법을 설명합니다. 이러한 보안 토큰 발급 서비스는 WS-Security 기반으로 하여 해당 토큰의 무결성과 기밀성을 보장하는 방식으로 필요한 보안 토큰을 전송합니다.

그런 다음 이 사양에서는 이 트러스트 모델과 함께 여러 기존 트러스트 메커니즘을 사용하는 방법을 설명합니다.

마지막으로 트러스트 모델은 보안 주체에 의한 위임 및 가장을 명시적으로 허용하지만 위임은 허용하지 않습니다. 위임은 가장과 일치하지만 추가적인 수준의 추적 기능을 제공합니다.

WS-Privacy

웹 서비스를 만들고 관리하고 사용하는 조직은 종종 개인 정보 취급 방침을 명시해야 하며 들어오는 요청이 보낸 사람의 이러한 정책 준수에 대해 클레임하도록 요구합니다.

WS-Policy, WS-Security및 WS-Trust의 조합을 사용하여 조직은 명시된 개인 정보 보호 정책에 대한 준수를 명시하고 나타낼 수 있습니다. 이 사양에서는 개인 정보 보호 언어를 WS-Policy 설명에 포함할 수 있는 방법과 WS-Security 사용하여 개인 정보 보호 클레임을 메시지와 연결하는 방법에 대한 모델을 설명합니다. 마지막으로, 이 사양은 WS-Trust 메커니즘을 사용하여 사용자 기본 설정 및 조직 사례 클레임 모두에 대해 이러한 개인 정보 보호 클레임을 평가하는 방법을 설명합니다.

WS-SecureConversation

WS-SecureConversation 웹 서비스가 요청자 메시지를 인증하는 방법, 요청자가 서비스를 인증하는 방법 및 상호 인증된 보안 컨텍스트를 설정하는 방법을 설명합니다.

이 사양에서는 세션 키, 파생 키 및 메시지별 키를 설정하는 방법을 설명합니다.

마지막으로, 이 사양은 서비스가 컨텍스트(보안 특성 및 관련 데이터에 대한 클레임 컬렉션)를 안전하게 교환하는 방법을 설명합니다. 이를 위해 사양은 WS-Security 및 WS-Trust에 정의된 보안 토큰 발급 및 교환 메커니즘의 개념을 설명하고 기반으로 . 예를 들어 서비스에서 이러한 메커니즘을 사용하면 약한 대칭 키 기술을 사용하여 보안 토큰을 지원하고 비공유(비대칭) 키를 사용하여 더 강력한 보안 토큰을 발급할 수 있습니다.

WS-SecureConversation 메시지가 다양한 전송 및 중개자를 트래버스할 수 있도록 SOAP 메시지 계층에서 작동하도록 설계되었습니다. 이는 다른 메시징 프레임워크 내에서의 사용을 배제하지 않습니다. 시스템의 보안을 더욱 강화하기 위해 전송 수준 보안을 선택한 링크에서 WS-Security 및 WS-SecureConversation 함께 사용할 수 있습니다.

WS-Federation

이 사양은 WS-Security, WS-Policy, WS-Trust 및 WS-SecureConversation 사양을 사용하여 페더레이션된 트러스트 시나리오를 생성하는 방법을 정의합니다. 예를 들어 아래 시나리오에 설명된 대로 Kerberos 및 PKI 인프라를 페더레이션하는 방법을 설명합니다.

또한 조정되는 신뢰 유형을 나타내고 제한하고 식별하기 위한 트러스트 정책이 도입되었습니다.

또한 이 사양은 트러스트 관계를 관리하기 위한 메커니즘을 정의합니다.

WS-Authorization

이 사양에서는 웹 서비스에 대한 액세스 정책을 지정하고 관리하는 방법을 설명합니다. 특히 보안 토큰 내에서 클레임을 지정하는 방법과 엔드포인트에서 이러한 클레임을 해석하는 방법을 설명합니다.

이 사양은 권한 부여 형식 및 권한 부여 언어와 관련하여 유연하고 확장 가능하도록 설계되었습니다. 이렇게 하면 가장 광범위한 시나리오를 사용할 수 있으며 보안 프레임워크의 장기 실행 가능성을 보장합니다.

3 오늘날의 보안 모델과 웹 서비스 보안 관련

이 웹 서비스 보안 모델은 현재 일반적으로 사용되는 인증, 데이터 무결성 및 데이터 기밀성을 위한 기존 보안 모델과 호환됩니다. 따라서 웹 서비스 기반 솔루션을 다른 기존 보안 모델과 통합할 수 있습니다.

  • 전송 보안- 보안 소켓(SSL/TLS)과 같은 기존 기술은 메시지에 대한 간단한 지점 간 무결성 및 기밀성을 제공할 수 있습니다. Web Services 보안 모델은 이러한 기존 보안 전송 메커니즘을 WS-Security(및 기타 사양)와 함께 사용하여 종단 간 무결성을 제공하고 특히 여러 전송, 중개자 및 전송 프로토콜에서 기밀로 사용할 수 있도록 지원합니다.
  • PKI- 높은 수준에서 PKI 모델에는 인증서를 발급하는 인증 기관이 공용 비대칭 키 및 키 소유권 이외의 속성을 어설션하는 기관(예: 특성 기관)이 포함됩니다. 이러한 인증서의 소유자는 연결된 키를 사용하여 ID를 비롯한 다양한 클레임을 표현할 수 있습니다. 웹 서비스 보안 모델은 공용 비대칭 키를 사용하여 보안 토큰을 발급하는 보안 토큰 서비스를 지원합니다. PKI는 여기서 가장 광범위한 의미로 사용되며 특정 계층 또는 모델을 가정하지 않습니다.
  • kerberos— Kerberos 모델은 KDC(키 배포 센터)와의 통신을 사용하여 양 당사자에 대해 암호화된 대칭 키를 발급하고 서로 "소개"하여 당사자 간의 신뢰를 중개합니다. 웹 서비스 모델은 암호화된 대칭 키와 암호화된 증명을 사용하여 보안 토큰을 발급하여 보안 토큰 서비스가 신뢰를 중개하는 핵심 모델을 기반으로 합니다.

모델은 호환되지만 상호 운용성을 보장하려면 서명 및 암호화에 대한 어댑터 및/또는 일반적인 알고리즘을 합의하거나 개발해야 합니다.

페더레이션, 권한 부여(위임 포함), 개인 정보 보호 및 신뢰에 대한 기존 모델은 덜 일반적이며 더 임시적인 모델입니다. 이러한 보안 속성을 해결하기 위한 사양은 전략의 이후 단계에서 식별됩니다.

종종 기존 트러스트 모델은 비즈니스 계약을 기반으로 합니다. 이 예제는 UDDI 웹 서비스입니다. UDDI에는 API 집합을 지원하는 계약을 통해 유니버설 비즈니스 레지스트리를 제공하는 여러 참가자가 있습니다. 특정 인증 메커니즘의 요구 사항을 통해 "신뢰"에 대한 단일 모델을 정의하는 대신 UDDI의 "신뢰 모델"은 정보의 보유자인 노드에 대한 인증에 대한 책임을 줍니다. 즉, UDDI 웹 서비스의 각 구현에는 자체 인증 메커니즘이 있으며 자체 액세스 제어 정책을 적용합니다. "신뢰"는 운영자와 요청자와 해당 정보의 보유자인 연산자 사이에 있습니다.

4개 시나리오

아래에서는 사용 중인 제안된 웹 서비스 보안 사양을 구상하는 방법을 보여주는 여러 시나리오를 제공합니다. 이러한 시나리오는 전체 보안 전략의 기능을 설명하기 위해 의도적으로 기술 세부 정보에 초점을 맞춥니다. 자세한 비즈니스 사용 시나리오를 제공하는 도우미 설명서가 있습니다.

여기에 표시된 예제 회사, 조직, 제품, 도메인 이름, 전자 메일 주소, 로고, 사람, 장소 및 이벤트는 가상입니다. 실제 회사, 조직, 제품, 도메인 이름, 전자 메일 주소, 로고, 사람, 장소 또는 이벤트와의 연결은 의도되거나 유추되어야 합니다.

아래 목록에서는 제안된 초기 사양 및 관련 결과물에서 지원될 수 있는 몇 가지 시나리오를 간략하게 소개합니다.

  • 사용자 이름/암호 및 Transport-Level 보안을 사용하는 직접 신뢰 - 이 시나리오에서는 전송 보안과 함께 사용자 이름 및 암호를 사용하는 인증을 보여 줍니다.
  • 보안 토큰을 사용한 직접 신뢰 - 이 시나리오에서는 X.509 인증 및 KERberos ST(서비스 티켓)를 사용하는 직접 트러스트를 보여 줍니다.
  • 보안 토큰 획득 - 이 시나리오에서는 메시지와 독립적으로 저장된 보안 토큰을 사용하는 인증을 보여 줍니다.
  • 방화벽 처리 - 이 시나리오에서는 방화벽이 이 보안 모델을 활용하여 제어 수준을 높이는 방법을 보여 줍니다.
  • 발급된 보안 토큰 - 이 시나리오에서는 기본 인증을 보여 줍니다.
  • 비즈니스 정책 적용 - 이 시나리오에서는 비즈니스 프로세스를 코딩하기 위해 보안 토큰 발급을 사용하는 방법을 보여 줍니다.
  • 개인 정보 보호 - 이 시나리오에서는 클라이언트와 서비스가 개인 정보 보호 정책을 전달하는 방법을 보여 줍니다.
  • 웹 클라이언트 - 이 시나리오에서는 웹 브라우저를 클라이언트로 사용하는 방법을 보여 줍니다.
  • 모바일 클라이언트 - 이 시나리오에서는 모바일 클라이언트가 웹 서비스와 안전하게 상호 작용하는 방법을 보여 줍니다.

두 번째 시나리오 집합은 더 정교합니다. 이러한 시나리오는 현재 결과물을 기반으로 빌드할 수 있지만 상호 운용성을 원활하게 하기 위해 후속 사양(예: WS-SecureConversation)이 필요합니다.

  • 페더레이션 사용 - 이 섹션에서는 페더레이션 트러스트와 관련된 여러 가지 시나리오에 대해 설명합니다.
  • 유효성 검사 서비스: 메시지의 보안(예: 서명)의 유효성을 검사하는 서비스를 사용하는 방법을 설명합니다.
  • 위임 지원 - 위임에 보안 토큰을 사용하는 방법을 보여 줍니다.
  • Access Control - 웹 서비스 보안이 기존의 액세스 제어 목록 기반 보안을 지원하는 방법을 보여 줍니다.
  • 감사 - 감사를 사용하여 보안 관련 활동 및 인시던트 추적을 보여 줍니다.

아래 설명에서 요청자라는 용어는 웹 서비스의 광범위한 잠재적 사용자를 설명하는 데 사용되며 요청자의 특성을 제한하기 위한 것이 아닙니다. 요청자는 B2B 환경 내에서 서비스와 상호 작용하는 비즈니스 엔터티 또는 브라우저 또는 모바일 디바이스에서 서비스에 액세스하는 개인을 포함할 수 있습니다.

사용자 이름/암호 및 Transport-Level 보안을 사용하여 직접 신뢰

다음은 웹 서비스 보안을 기존 전송 보안 메커니즘과 함께 사용하는 방법을 보여 주는 매우 기본적인 예제입니다.

요청자는 보안 전송(예: SSL/TLS)을 사용하여 웹 서비스에 대한 연결을 엽니다. 요청을 보내고 사용자 이름과 암호를 포함하는 보안 토큰을 포함합니다. 서비스는 정보를 인증하고, 요청을 처리하고, 결과를 반환합니다.

이 시나리오에서는 메시지 기밀성 및 무결성이 기존 전송 보안 메커니즘을 사용하여 처리됩니다.

이 시나리오에서는 두 당사자가 이미 공유 비밀(요청자 암호)을 설정하는 몇 가지 메커니즘을 사용했다고 가정합니다. 이러한 당사자 간의 조직 관계에 대한 가정은 없습니다.

보안 토큰을 사용하여 직접 신뢰

이 시나리오에서는 웹 서비스에서 직접 신뢰하는 보안 토큰을 사용하는 방법을 보여 줍니다. 여기서 직접 신뢰는 요청자의 보안 토큰(또는 서명 기관)이 웹 서비스에서 알려지고 신뢰할 수 있음을 의미합니다. 이 시나리오에서는 두 당사자가 보안 토큰을 사용하기 위해 트러스트 관계를 설정하는 몇 가지 메커니즘을 사용했다고 가정합니다. 이 트러스트는 애플리케이션을 구성하거나 보안 전송을 사용하여 키를 교환하여 수동으로 설정할 수 있습니다. 키를 안전하게 전송하면 SSL(또는 기타 메커니즘 또는 프로세스)과 같은 전송을 신뢰할 수 있는 당사자가 키 또는 보안 토큰의 유효성을 받는 사람에게 어설션하는 방법으로 사용할 수 있습니다. 당사자 간의 조직 관계에 대한 가정은 없습니다.

요청자는 서비스에 메시지를 보내고 서명된 보안 토큰을 포함하며 서명과 같은 보안 토큰의 소유 증명을 제공합니다. 서비스는 증명을 확인하고 보안 토큰을 평가합니다. 보안 토큰의 서명은 유효하며 서비스에서 직접 신뢰합니다. 서비스는 요청을 처리하고 결과를 반환합니다.

직접 신뢰는 개인 정보 보호 정책이 관련 당사자에 의해 잘 이해된다고 가정합니다.

보안 토큰 획득

경우에 따라 사용된 보안 토큰이 메시지의 일부로 전달되지 않습니다. 대신 토큰을 찾고 획득하는 데 사용할 수 있는 보안 토큰 참조가 제공됩니다.

요청자는 서비스에 요청을 발급하고 보안 토큰에 대한 참조를 포함하고 소유 증명을 제공합니다. 웹 서비스는 제공된 정보를 사용하여 토큰 저장소 서비스에서 보안 토큰을 가져오고 증명의 유효성을 검사합니다. 웹 서비스는 보안 토큰을 신뢰(메시지 의미 체계 외부에서 트러스트가 설정됨)하므로 요청이 처리되고 응답이 반환됩니다.

방화벽 처리

방화벽은 웹 서비스 보안 아키텍처의 중요한 구성 요소로 남아 있습니다. 경계 처리 규칙을 계속 적용할 수 있어야 합니다.

아래와 같이 방화벽은 들어오는 SOAP 메시지를 검사하고 "권한 있는" 요청자의 메시지만 방화벽에 침투할 수 있도록 허용합니다.

이 시나리오에서는 두 명의 요청자가 방화벽 내의 웹 서비스로 메시지를 보냅니다. 방화벽은 메시지를 검사하여 요청자가 방화벽 내의 지정된 웹 서비스로 메시지를 보낼 수 있는 "권한"이 있는지 확인합니다.

이 시나리오에서 방화벽은 메시지에 서명하는 데 사용되는 보안 토큰을 검사하여 이 결정을 내립니다. 서명이 유효하고 보안 토큰에 대한 서명 기관이 방화벽에 메시지를 권한을 부여하도록 신뢰할 수 있고, 토큰이 방화벽에 메시지를 권한을 부여한다고 표시되면 메시지가 허용됩니다. 그렇지 않으면 거부됩니다. 경우에 따라 서명은 특히 방화벽을 SOAP 행위자로 참조할 수 있습니다.

다른 시나리오에서는 방화벽이 보안 토큰 발급 기관 역할을 하며 방화벽에서 발급한 보안 토큰의 소유 증명을 포함하는 메시지만 허용할 수 있습니다.

발급된 보안 토큰

다음은 웹 서비스 보안이 신뢰할 수 있는 당사자의 간단한 인증을 지원하는 방법을 보여 주는 예제입니다.

처음 두 단계에서는 요청자가 인증 기관과 통신하여 보안 토큰, 특히 요청자의 ID를 증명하는 서명된 어설션 명령문을 가져옵니다.

웹 서비스에 적절한 형식의 보안 토큰이 필요하도록 요구하는 정책이 있기 때문에 요청자가 보안 토큰을 얻었습니다(이 경우 ID 증명).

다음으로 요청자는 보안 토큰과 소유 증명이 메시지에 첨부된 메시지(인증자 또는 서명된 챌린지라고 생각)가 포함된 메시지를 웹 서비스에 보내고 응답을 받습니다.

위의 설명에서 ID 인증 서비스의 작업은 자세히 설명되지 않았습니다. ID 보안 토큰을 얻기 위해 요청자는 기존 보안 프로토콜을 사용하거나 웹 서비스 보안 사양을 활용할 수 있습니다.

요청자가 웹 서비스 보안 사양을 사용한다고 가정하면 시스템은 다음과 같이 작동합니다. ID 서비스는 정책의 요구 사항을 설명하고 요청자는 ID 증명과 함께 보안 토큰을 요청할 수 있습니다.

ID 서비스는 보안 토큰 서비스일 뿐입니다. 또한 웹 서비스의 대칭을 사용하면 모든 웹 서비스가 보안 토큰 서비스를 캡슐화할 수 있습니다.

마지막으로 웹 서비스는 보안 토큰 서비스에서 요청자를 대신하여 보안 토큰을 가져와 후속 메시지에 사용할 요청자에게 반환할 수 있습니다.

비즈니스 정책 적용

많은 비즈니스 프로세스에는 적용해야 하는 특정 정책이 있습니다. 예를 들어 서비스에서는 소비자가 특정 등급 또는 특정 감사 회사와 함께 있어야 할 수 있습니다. 웹 서비스를 사용하면 이러한 정책의 대부분을 자동으로 코딩하고 유효성을 검사하여 전체 프로세스를 간소화할 수 있습니다.

다음 예제를 고려하세요.

Nicholas의 대리점에는 부품 공급업체와 상호 작용하는 데 사용하는 웹 서비스가 있습니다. 그러나 제조업체에서 부품을 인증받은 공급업체만 처리하려고 합니다.

부품 회사인 Joshua's Parts는 제조업체에 가서 ID 보안 토큰(예: 설명된 보안 토큰 서비스)을 제출(및 증명)하고 인증된 부품 딜러라고 명시하는 보안 토큰을 제조업체에 요청합니다(인증되고 양호하다고 가정). 그런 다음 조슈아의 부품은 니콜라스의 대리점에 연락하여 두 가지 보안 토큰을 제공하고 증명할 수 있습니다.

Nicholas의 대리점이 비즈니스 정책을 서비스 정책으로 명문화한 경우 정책 준수의 부담은 부품 회사(예: Joshua의 부품)에 미리 로드될 수 있습니다.

또한 서비스 정책은 개인 정보 취급 방침 준수를 보장하기 위해 제조업체가 저장할 수 있는 정보에 대한 제약 조건을 지정할 수 있습니다.

사생활

개인 정보 보호는 광범위한 문제를 포함하며 이 전략에서 나오는 각 사양에서 고려해야 합니다.

기본 개인 정보 보호 문제는 서비스 정책 내에서 개인 정보 취급 방침을 제공하여 해결됩니다. 위임 및 권한 부여와 관련된 보다 정교한 시나리오는 해당 시나리오와 관련된 사양에서 다룹니다.

예를 들어, 개인은 개인이 개인을 대신하여 행동하는 애플리케이션이 개인 정보로 수행하는 것을 허용하거나 허용하지 않으려는 것을 설명하는 일련의 "개인 정보 보호 기본 설정"을 명시합니다. 개인을 대신하여 작업하는 일정 애플리케이션은 이제 일련의 "개인 정보 취급 방침 규칙"을 사용하는 일정 서비스에 액세스하여 개인 정보의 사용 및 공개에 대한 진술 및 결정을 내릴 수 있습니다. 일정 서비스는 개인 정보 취급 방침 규칙을 개인 정보 기본 설정과 결합하여 제안된 사용 또는 공개가 허용되는지 여부를 결정합니다.

웹 클라이언트

중간 계층 웹 애플리케이션과 통신하는 웹 클라이언트가 있는 경우 다른 도메인의 웹 서비스와 안전하게 통신하는 예제를 생각해 보세요. 웹 서비스를 인식하는 중간 계층 웹 애플리케이션은 웹 클라이언트에 대한 보안 토큰을 가져오려고 합니다.

또한 이 시나리오에서는 보안 토큰을 통해 중간 계층 애플리케이션이 서비스와 대화할 때 클라이언트를 대신하여 작동할 수 있다고 가정합니다.

이 시나리오를 사용하도록 설정하기 위해 웹 클라이언트의 브라우저는 중간 계층 애플리케이션에 액세스하고 연결된 ID 서비스로 리디렉션됩니다. 인증되면(예: HTML 양식 및 https 사용) 요청이 중간 계층 애플리케이션으로 다시 리디렉션됩니다. ID 서비스는 원래 중간 계층 애플리케이션 웹 서버(예: HTTPS를 통해 전송된 쿼리 문자열 사용)에 보안 토큰(ID 및 위임 어설션)을 제공합니다. 이제 웹 서버는 이러한 보안 토큰을 사용하고 자체 ID에서 웹 서비스로 요청을 실행할 수 있습니다. 웹 서비스는 요청을 처리하고 결과를 웹 서버로 반환합니다. 여기서 결과는 형식이 지정되고 브라우저로 반환됩니다.

모바일 클라이언트

위의 이 문서에 설명된 사양은 모바일 보안에 고유한 디자인 문제를 해결하는 데 상당한 유연성을 제공합니다.  웹 서비스 접근 방식의 유연성을 통해 계산 및 스토리지 기능이 제한된 디바이스에서 강력하고 성능이 뛰어난 암호화 보호를 제공하는 여러 암호화 기술을 지원할 수 있습니다.  마찬가지로 네트워크 운영자는 네트워크 게이트웨이와 같은 보안 프록시를 제공하여 모바일 클라이언트를 대신하여 작동할 수 있습니다. 

다음은 이러한 두 아이디어를 결합하는 예제입니다.  네트워크 운영자가 모바일 클라이언트를 지원하는 경우(이러한 웹 서비스 보안 사양 사용) 네트워크 운영자의 게이트웨이를 통해 요청을 보내도록 해당 클라이언트를 구성할 수 있습니다.  이 시나리오에서 게이트웨이는 전체 메시지 흐름에 적극적으로 참여하는 SOAP 중개자입니다. 특히 네트워크 운영자는 모바일 디바이스용으로 설계된 값 추가 암호화 알고리즘을 제공합니다.  게이트웨이는 메시지의 보안 토큰 및 보호 품질을 보강하거나 변경할 수 있습니다.  이 웹 서비스 보안 모델에 내재된 유연성은 디바이스가 외래 네트워크에서 로밍하는 경우에도 이 솔루션을 허용합니다. 

아래 예제에 나와 있습니다.

페더레이션 사용

웹 서비스 보안 모델은 페더레이션을 지원하도록 설계되었습니다. 다음은 ID 페더레이션의 간단한 예입니다.

Adventure456의 Alice는 Business456에서 통화 웹 서비스를 사용하려고 합니다. 통화 서비스는 Business456에서 발급한 보안 토큰을 사용하여 요청만 처리합니다. Alice에는 Adventure456에서 발급한 ID 클레임(즉, ID 보안 토큰)이 있는 보안 토큰만 있습니다.

이 시나리오에서는 Business456이 Adventure456으로 보안 페더레이션을 수락하려는 경우에만 Alice가 Currency 서비스에 액세스할 수 있습니다.

다음 하위 섹션에서는 보안 페더레이션에 대한 몇 가지 방법을 설명합니다.

보안 토큰 교환을 사용한 페더레이션

이 방법에서 통화 서비스의 정책은 Business456에서 발급한 보안 토큰만 허용한다고 명시하고 있습니다. 정책은 필요한 보안 토큰을 가져올 위치를 나타내므로 Alice는 Adventure456 보안 토큰을 Business456 보안 토큰 서비스에 제시하고 증명하며 Business456 보안 토큰을 받습니다. 그런 다음 통화 서비스에 대한 요청에서 이 보안 토큰을 제시하고 증명합니다. 아래 다이어그램에 나와 있습니다.

이 방법에서 Business456 보안 토큰 서비스는 Adventure456에서 발급한 ID 클레임으로 보안 토큰을 허용하도록 구성되었습니다.

이 예제는 비즈니스 정책 적용 시나리오의 예제와 매우 유사합니다. 이는 웹 서비스 보안 모델의 유연성을 보여 줍니다.

트러스트 체인을 사용한 페더레이션

이 방법에서 통화 서비스는 보안 토큰을 사용하여 요청을 수락하지만 제공된 보안 토큰(및 증명)에 따라 Business456 보안 토큰을 가져올 수 없는 한 요청을 처리하지 않습니다.

이를 위해 통화 서비스는 초기 보안 토큰을 평가하는 Business456 보안 토큰 서비스에 원래 요청을 전달합니다. 유효한 경우 요청을 보증하며 Alice가 후속 요청에 사용할 Business456 보안 토큰을 포함할 수 있습니다. 아래 그림에 나와 있습니다.

이 방법에서 Business456 보안 토큰 서비스는 Adventure456에서 발급한 ID 클레임으로 보안 토큰을 허용하도록 구성되었습니다.

보안 토큰 교환을 사용한 페더레이션(PKIKerberos)

이 방법에서 Adventure456은 Alice에게 공개 키 보안 토큰을 발급했으며 통화 서비스의 정책은 KDC의 Kerberos 보안 토큰만 허용한다는 것을 나타냅니다.

통화 서비스 정책의 방향에서 Alice는 공개 키 보안 토큰을 Business456의 보안 토큰 서비스에 제시하고 증명합니다. 보안 토큰 서비스는 Business456의 KDC를 캡슐화합니다. 결과적으로 Alice의 공개 키 보안 토큰의 유효성을 검사하고 통화 서비스에 대한 Kerberos 보안 토큰을 발급할 수 있습니다. 아래 그림에 나와 있습니다.

이 방법에서 Business456 보안 토큰 서비스는 Adventure456에서 발급한 ID 클레임을 사용하여 공개 키 보안 토큰을 허용하도록 구성되었습니다.

보안 토큰 교환을 사용하는 페더레이션(KerberosSecurity 토큰 서비스)

이 방법에서 Adventure456은 Alice에게 Kerberos 보안 토큰을 발급했으며 통화 서비스의 정책은 자체 보안 토큰 서비스에서 발급한 보안 토큰만 허용한다는 것을 나타냅니다.

여기서는 Adventure456 및 Business456의 관리자가 보안을 페더레이션하기 위해 공개 키 인증서를 교환한 것으로 가정합니다. 또한 Alice는 대칭 키 기술만 지원한다고 가정합니다.

통화 웹 서비스 정책에 따라 Alice는 Business456에서 보안 토큰 서비스에 액세스하는 데 사용할 수 있는 보안 토큰을 획득해야 합니다. Alice는 대칭 키 보안 토큰을 사용하므로 Alice는 먼저 보안 토큰 서비스에 연결하여 Business456 보안 토큰 서비스를 위한 보안 토큰을 획득합니다. 이 보안 토큰에는 Business456 보안 토큰 서비스의 공개 키로 인코딩된 대칭 키인 Sab가 포함됩니다.

Alice는 Business456 보안 토큰 서비스를 위한 보안 토큰을 사용하여 통화 서비스에 대한 보안 토큰을 요청합니다. Business456 보안 토큰 서비스는 Alice에게 통화 서비스에 대한 대칭 키, Sac 및 보안 토큰을 제공합니다.

Alice는 통화 서비스 및 연결된 대칭 키를 위한 보안 토큰을 사용하여 통화 서비스에 요청합니다.

자격 증명 교환을 사용한 페더레이션(KerberosKerberos)

이 방법에서 Adventure456은 Alice에게 Kerberos 보안 토큰을 발급했으며 통화 서비스의 정책은 KDC를 캡슐화하는 자체 보안 토큰 서비스에서 발급한 Kerberos 보안 토큰만 허용한다는 것을 나타냅니다.

여기서는 Adventure456 및 Business456의 관리자가 영역 간 전이적 신뢰를 설정하지 않고 보안을 페더레이션하기 위해 공개 키 인증서를 교환하려고 하는 것으로 가정합니다. 또한 Alice와 Currency 서비스 모두 대칭 키 기술만 지원한다고 가정합니다.

이전 예제와 마찬가지로 보안 토큰 서비스는 해당 신뢰 도메인 내의 서비스에 대칭 키 보안 토큰을 제공할 수 있습니다. 결과적으로 위에서 설명한 접근 방식은 이 시나리오에서 작동합니다.

유효성 검사 서비스

또한 이 웹 서비스 보안 모델은 요청자가 메시지 처리 및 보안 토큰 유효성 검사를 아웃소싱을 시나리오를 지원합니다. 이러한 서비스를 오용하면 확장성 문제가 발생할 수 있다는 점에 유의해야 합니다. 즉, 구현에 따라 서비스에서 유효성 검사 서비스를 수행하는 데 더 저렴하거나 비용이 많이 들 수 있습니다. 웹 서비스 보안 모델은 두 방법 중 하나를 지원하므로 이 시나리오를 사용할 수 있습니다.

이 시나리오에서는 유효성 검사 서비스를 보안 토큰 서비스와 분리했습니다. 다른 시나리오에서는 결합되거나 직접 신뢰 관계를 가질 수 있습니다(따라서 WS-Federation필요하지 않음).

이 시나리오에서 요청자는 보안 토큰 서비스에서 보안 토큰을 가져옵니다. 그런 다음 웹 서비스에 메시지를 보내고 소유 증명(예: 서명)을 포함합니다. 웹 서비스는 서명 블록, 보안 토큰 및 유효성 검사 서비스에 서명된 다이제스트의 계산을 보냅니다. 웹 서비스에서 신뢰하는 유효성 검사 서비스는 유효/잘못된 결정을 내립니다.

유효성 검사 서비스는 적절한 클레임을 어설션하는 요청자를 대신하여 보안 토큰을 발급하여 결정을 나타낼 수 있습니다.

지원 위임

웹 서비스 보안은 위임을 지원합니다. 다음은 접근 방식의 유연성을 보여 주도록 설계된 정교한 위임 시나리오입니다. Alice는 calendar456을 사용하여 일정을 관리합니다. 그녀는 Bob이 화요일에 그녀와 회의를 열 수 있도록 허용하고 싶어합니다. 그러나 Bob은 예약을 직접 수행하지 않습니다. 대신 Bob은 서비스인 schedule456을 사용하여 Alice의 일정에 배치해야 하는 모임을 설정합니다.

Alice는 Bob이 모임을 예약하는 방법을 알지 못하지만 일정을 볼 수 있는 서비스 집합을 제한하려고 합니다.

Alice는 Bob에게 일정에서 모임을 예약할 수 있는 보안 토큰을 제공합니다. 이 보안 토큰에는 Bob이 모임을 화요일로 예약하는 기능을 제한하는 클레임이 포함되어 있습니다. 또한 이 보안 토큰을 사용하면 주체가 타사 서비스인 TrustUs456에서 개인 정보 인증을 받았다는 것을 증명할 수 있는 한 Bob이 후속 보안 토큰을 발급할 수 있습니다.

서비스 Schedule456은 TrustUs456에 의해 감사되었으므로 개인 정보 인증을 어설션하는 보안 토큰이 있습니다.

일정 서비스가 Calendar456에서 Alice의 일정에 액세스하는 경우 개인 정보 보호 인증의 소유 증명 및 Alice의 보안 토큰에 따라 Bob을 통해 자체적으로 모임에 액세스하고 예약하는 클레임을 증명할 수 있습니다.

액세스 제어

함께 작업하는 동안 Alice와 Bob은 자주 서로 모임을 예약하고 신뢰 수준을 개발한다는 것을 알게 됩니다. 따라서 Alice는 Bob이 매번 위임하지 않고도 모임을 예약할 수 있도록 허용하려고 합니다. 위임 보안 토큰의 만료를 늘릴 수 있지만 다시 발급해야 하며, Bob의 모임 예약 능력을 철회하려는 경우 문제가 됩니다.

Alice는 일정 서비스와 통신하고(자신을 인증) 권한 부여 목록을 가져옵니다. Bob이 약속 있음/없음 데이터를 보고 모임을 예약할 수 있도록 권한 부여 목록을 업데이트하고 서비스에 제출합니다. 이제 Bob이 이러한 작업을 위해 일정 서비스에 액세스할 때 Alice의 위임 보안 토큰이 필요하지 않습니다.

감사

위의 위임 시나리오에서는 적대자가 위임 보안 토큰이나 만료된 보안 토큰을 사용하여 모임을 예약하려고 할 수 있습니다. 이러한 경우 길항제가 필요한 클레임을 증명할 수 없으므로 요청이 실패합니다.

이러한 유형의 활동을 추적하기 위해 서비스에서 감사 기능을 제공할 수 있습니다. 즉, 인증 또는 입증되지 않은 클레임 또는 잘못된 서명과 같은 보안 관련 이벤트가 발생하면 기록됩니다. 관리자는 안전하게 로그에 액세스하여 보안 관련 이벤트를 검토하고 로그를 관리할 수 있습니다.

예를 들어 길항제는 Bob을 모방하려고 할 수 있습니다. 보안 관리자인 Carol은 모니터/관리 도구를 사용하여 감사 로그를 검토하고 Alice의 일정에 많은 보안 오류가 있는 것을 확인합니다. 데이터를 검토할 때 서명이 메시지와 일치하지 않거나 메시지가 오래되었으므로 Bob의 요청이 실패하는 경우가 있습니다(재생됨). 결과적으로 Carol은 길항제를 추적하는 데 사용할 감사 레코드를 수집합니다.

5 요약

웹 서비스가 더 광범위하게 적용됨에 따라 방화벽, 부하 분산 장치 및 메시징 허브와 같은 중개자를 지원하기 위해 애플리케이션 토폴로지가 계속 진화하고 조직이 직면한 위협에 대한 인식이 더 잘 이해됨에 따라 웹 서비스에 대한 추가 보안 사양의 필요성이 분명해집니다.  이 문서에서는 통합 웹 서비스 보안 모델 및 해당 모델을 실현하기 위한 일련의 사양을 제안합니다. 이러한 새로운 사양은 기존 보안 기술과 자산을 대체하지 않고 확장 및 활용함으로써 고객과 조직이 안전하고 상호 운용 가능한 웹 서비스를 보다 신속하게 개발할 수 있도록 합니다.

IBM과 Microsoft는 이것이 포괄적인 웹 서비스 보안 전략을 정의하는 첫 번째 단계라고 생각합니다.  그것은 우리가 지금까지 확인 한 도전과 솔루션을 반영합니다. 웹 서비스를 보호하기 위해 고객, 파트너 및 표준 조직과 계속 협력하면서 전략을 완료하는 데 필요한 추가 아이디어와 사양이 있을 것으로 기대합니다. 

참여자

이 문서는 IBM과 Microsoft가 공동으로 작성했습니다.

주요 기여는 포함 (사전순): 조반니 델라 - Libera, 마이크로 소프트; 브렌던 딕슨, Microsoft; 조엘 파렐, IBM; Praerit Garg, Microsoft; Maryann Hondo, IBM; Chris Kaler, Microsoft; 버틀러 램프슨, Microsoft; 켈빈 로렌스, IBM; Andrew Layman, Microsoft; Paul Leach, Microsoft; John Manferdelli, Microsoft; 마루야마 히로시, IBM; 앤서니 나달린, IBM; 나타라즈 나가라트남, IBM; Rick Rashid, Microsoft; John Shewchuk, Microsoft; Dan Simon, Microsoft; 아자무 웨슬리, IBM

참조