보안 웹 서비스 : HTTPS를 통한 REST 대 SOAP + WS- 보안. 어떤게 더 좋아? [닫은]

나는 보안 전문가가 아니지만 REST 스타일 웹 서비스를 만드는 것을 선호합니다.

데이터를 안전하게 보관해야하는 새로운 서비스를 만들 때. HTTPS를 사용하는 REST 또는 WS-Security를 ​​사용하는 SOAP WS 인 더 안전한 접근 방식에 대한 토론을 시작했습니다.

모든 웹 서비스 호출에 HTTPS를 사용할 수 있다는 인상을 받았으며이 접근 방식은 안전합니다. 내가 보는 방식은 "HTTPS가 은행 및 금융 웹 사이트에 충분하면 나에게 충분하다"입니다. 다시 한 번이 분야의 전문가는 아니지만이 사람들이이 문제에 대해 상당히 열심히 생각하고 HTTPS에 익숙하다고 생각합니다.

동료가 동의하지 않으며 SOAP 및 WS-Security가 유일한 방법이라고 말합니다.

웹은 여기에 온통 보인다.

여기의 커뮤니티가 각각의 장단점을 고려할 수 있습니까? 감사!

HTTPS는 네트워크를 통한 메시지 전송을 보호하고 서버의 신원에 대해 클라이언트에게 약간의 보증을 제공합니다. 이것이 은행이나 온라인 주식 중개인에게 중요한 것입니다. 클라이언트 인증에 대한 관심은 컴퓨터의 신원이 아니라 귀하의 신원에 있습니다. 따라서 카드 번호, 사용자 이름, 비밀번호 등이 귀하를 인증하는 데 사용됩니다. 그런 다음 일반적으로 제출이 변경되지 않도록하기 위해 몇 가지주의 사항이 취해 지지만 세션에서 발생하는 모든 일은 사용자가 시작한 것으로 간주됩니다.

WS-Security는 메시지 작성에서 메시지 사용에 이르기까지 기밀성 및 무결성 보호 기능을 제공합니다. 따라서 통신 내용을 올바른 서버에서만 읽을 수 있도록하는 대신 서버의 올바른 프로세스에서만 읽을 수 있습니다. 안전하게 시작된 세션의 모든 통신이 인증 된 사용자의 통신이라고 가정하는 대신 각 사용자가 서명해야합니다.

벌거 벗은 오토바이 운전자와 관련된 재미있는 설명이 있습니다.

https://docs.microsoft.com/archive/blogs/vbertocci/end-to-end-security-or-why-you-shouldnt-drive-your-motorcycle-naked

따라서 WS-Security는 HTTPS보다 더 많은 보호 기능을 제공하고 SOAP는 REST보다 풍부한 API를 제공합니다. 제 생각에는 추가 기능이나 보호가 실제로 필요하지 않으면 SOAP 및 WS-Security의 오버 헤드를 건너 뛰어야한다는 것입니다. 나는 그것이 약간의 cop-out이라는 것을 알고 있지만 문제를 친숙하게 알고있는 사람들이 실제로 얼마나 많은 보호가 실제로 정당화되는지에 대한 결정을 내려야한다는 것을 알고 있습니다.

REST 보안은 전송에 의존하지만 SOAP 보안은 그렇지 않습니다.

REST는 기본 전송에서 보안 조치를 상속하는 반면 SOAP는 WS-Security를 ​​통해 자체적으로 정의합니다.

REST에 대해 HTTP를 통해 이야기 할 때 HTTP를 적용한 모든 보안 조치가 상속되며이를 전송 레벨 보안이라고합니다.

전송 수준 보안은 유선 상태 일 때만 메시지를 보호합니다. 전선을 떠나 자마자 메시지는 더 이상 보안되지 않습니다.

그러나 WS-Security를 ​​사용하면 메시지 수준 보안이 유지됩니다. 메시지가 전송 채널을 떠나더라도 여전히 보호됩니다. 또한 메시지 수준 보안을 사용하면 [전체 메시지가 아니라 원하는 부분 만] 메시지를 부분적으로 암호화 할 수 있지만 전송 수준 보안을 사용하면 메시지를 암호화 할 수 없습니다.

WS-Security는 인증, 무결성, 기밀성 및 부인 방지 수단을 가지고 있으며 SSL은 부인 방지 기능을 지원하지 않습니다 [2-legged OAuth로].

성능 측면에서 SSL은 WS-Security보다 훨씬 빠릅니다.

감사...

기술적으로, SOAP 메소드의 통신이 안전하지 않고 REST 메소드가 합법적 인 사용자 인증에 대해 아무 말도하지 않았기 때문에 말 그대로 표현한 방식도 정확하지 않습니다.

HTTPS는 공격자 가 두 시스템 간의 통신 을 도청 하는 것을 방지 합니다. 또한 호스트 시스템 (서버)이 실제로 사용자가 액세스하려는 호스트 시스템인지 확인합니다.

WS-Security는 권한이없는 응용 프로그램 (사용자)이 시스템에 액세스하지 못하게합니다.

RESTful 시스템에 사용자를 인증하는 방법이 있고 WS-Security가있는 SOAP 애플리케이션이 HTTPS를 사용하는 경우 실제로 둘 다 안전합니다. 데이터를 표시하고 액세스하는 다른 방법 일뿐입니다.

참고 항목 위키 기사를 :

지점 간 상황에서, 예를 들어 https를 통해 메시지를 전송함으로써 TLS (Transport Layer Security)를 사용하여 웹 서비스에서 기밀성과 데이터 무결성을 강화할 수 있습니다.

그러나 WS-Security는 원래 노드에서 메시지가 전송 된 후 엔드 투 엔드 보안을 제공 할 때까지 메시지의 무결성과 기밀성을 유지하는 데 따른 광범위한 문제를 해결합니다.

그건:

• HTTPS는 전송 계층 (포인트 간) 보안 메커니즘입니다.
• WS-Security는 응용 프로그램 계층 (엔드 투 엔드) 보안 메커니즘입니다.

당신이 말했듯이 REST는 은행에 충분하기 때문에 충분해야합니다.

보안에는 두 가지 주요 측면이 있습니다. 1) 암호화와 2) ID.

SSL / HTTPS로 전송하면 유선으로 암호화됩니다. 그러나 두 서버 모두 자신이 말하는 사람을 알고 있음을 확인할 수 있어야합니다. SSL 클라이언트 인증서, 공유 비밀 등을 통해 가능합니다.

나는 SOAP가 "보다 안전하다"고 생각할 수 있지만, 그다지 중요하지는 않다. 누드 오토바이 운전자의 비유는 귀엽지 만 정확한 경우 전체 인터넷이 안전하지 않다는 것을 암시합니다.

의견을 추가하는 데 필요한 담당자가 없거나 Bell의 답변에 방금 추가했을 것입니다. Bell은 두 가지 접근법의 최상위 장단점을 요약하는 데 매우 훌륭하다고 생각합니다. 고려해야 할 몇 가지 다른 요소들 :

1) 클라이언트와 서비스 간의 요청이 페이로드에 액세스해야하는 중개자를 거쳐야합니까? 그렇다면 WS-Security가 더 적합 할 수 있습니다.

2) 실제로 SSL을 사용하여 상호 인증이라는 기능을 사용하여 클라이언트 ID에 대한 보증을 서버에 제공 할 수 있습니다. 그러나 이것은 복잡한 구성으로 인해 매우 특수한 시나리오 이외의 용도로는 많이 사용되지 않습니다. 따라서 Bell은 WS-Sec이 여기에 훨씬 더 적합합니다.

3) SSL은 일반적으로 인증서 관리 문제로 인해 설정 및 유지 관리 (심지어 간단한 구성에서도)에 약간의 부담이 될 수 있습니다. 귀하의 플랫폼에 대해이 작업을 수행하는 방법을 아는 사람이 있으면 큰 도움이 될 것입니다.

4) 어떤 형태의 자격 증명 매핑 또는 자격 증명 연동을 수행해야 할 경우 WS-Sec에 오버 헤드가 발생할 수 있습니다. REST를 사용 하여이 작업을 수행 할 수는 없지만 도움이되는 구조가 적습니다.

5) 모든 WS-Security goop을 클라이언트 측의 올바른 위치로 가져가는 것이 생각보다 힘들 수 있습니다.

결국 그것은 실제로 우리가 알지 못하는 많은 것들에 달려 있습니다. 대부분의 상황에서 나는 두 접근 방식이 "충분히 안전"할 것이며 이것이 주요 결정 요인이되어서는 안된다고 말할 것입니다.

Brace yourself, here there's another coming :-)

오늘 저는 여자 친구에게 HTTPS가 아닌 WS-Security의 표현력의 차이점을 설명해야했습니다. 그녀는 컴퓨터 과학자이므로 암호화 또는 서명의 의미를 이해하는 XML 맘보 점보를 모두 알지 못하더라도 이해합니다. 그러나 나는 강한 이미지를 원했고, 그녀는 그들이 어떻게 구현되는지가 아니라 무엇이 유용한 지 실제로 이해하게 만들 수있었습니다.

이렇게됩니다. 벌거 벗은 상태에서 오토바이를 특정 목적지로 운전해야한다고 가정하십시오. (A)의 경우 투명 터널을 통과합니다. 음란 한 행동으로 체포되지 않기를 원하는 유일한 사람은 아무도보고 있지 않다는 것입니다. 그것은 당신이 나올 수있는 가장 안전한 전략이 아닙니다 ... (남자 이마에서 땀이 떨어지는 것을 주목하십시오 :-)). 이것은 분명히 POST와 동일하며, "동등"이라고 말하면 의미합니다. (B)의 경우 더 나은 상황에 처해 있습니다. 터널은 불투명하기 때문에 터널에 들어가면 공개 기록이 안전합니다. 그러나 이것이 여전히 최상의 상황은 아닙니다. 당신은 여전히 ​​집을 떠나 터널 입구에 도달해야합니다. 그리고 터널 밖으로 나가면 아마도 내려 가서 걸어 가야 할 것입니다 ... 그리고 그것은 HTTPS로갑니다. 진실, 메시지는 가장 큰 틈새를 넘나 드는 동안 안전합니다. 그러나 다른쪽에 전달한 후에는 데이터가 처리 될 실제 지점에 도달하기 전에 얼마나 많은 단계를 거쳐야하는지 실제로 알 수 없습니다. 물론 이러한 모든 단계는 HTTP와 다른 것을 사용할 수 있습니다. 예를 들어, 즉시 처리 할 수없는 요청을 버퍼링하는 클래식 MSMQ입니다. 전처리 림보에있는 동안 누군가 데이터를 숨기면 어떻게됩니까? 흠. (문의 끝에 Morpheus가 발언 한 것으로 "hm"을 읽습니다. "호흡하는 공기라고 생각하십니까?"). 이 은유의 완전한 해결책 (c)는 고통스럽게 사소한 일입니다. 오토바이를 타는 동안 특히 헬멧을 착용하십시오. 따라서 환경의 불투명도에 의존하지 않고도 안전하게 이동할 수 있습니다. 은유는 분명합니다. 메시지 수준 보안과 마찬가지로 평균 또는 주변 인프라와 상관없이 옷이 제공됩니다. 또한, 당신은 한 부분을 커버하지만 다른 것을 공개하기로 결정할 수 있습니다 (그리고 당신은 개인적으로 그것을 할 수 있습니다 : 공항 보안은 재킷과 신발을 벗을 수 있지만 의사는 더 높은 접근 수준을 가질 수 있습니다), 짧은 소매 셔츠는 팔뚝을 자랑스러워도 나쁜 습관 :-) (폴로 또는 티셔츠가 더 좋습니다).

나는 그녀가 요점을 얻었다 고 기쁘다! 나는 옷의 은유가 매우 강력하다는 것을 말해야한다. 나는 정책의 개념을 소개하기 위해 그것을 사용하고 싶어했다. (디스코 클럽은 당신을 스포츠 신발에 넣지 않을 것이다; 당신은 속옷 은행에 돈을 인출 할 수 없다 , 이것은 서핑에서 자신을 균형 잡는 동안 완벽하게 수용 가능한 모양이지만;)) 나는 오후에 충분하다고 생각했습니다.

건축-WS, 야성적 인 아이디어

예의 : http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked. aspx

나는 매일이 공간에서 일하고 있으므로 이것을 끝내기 위해 좋은 의견을 요약하고 싶습니다.

SSL (HTTP / s)은 단 하나의 계층입니다.

1. 연결되는 서버는 ID를 증명하는 인증서를 제공합니다 (DNS 중독을 통해 스푸핑 될 수 있음).
2. 통신 계층은 암호화됩니다 (도청 없음).

WS-Security 및 관련 표준 / 구현물은 다음과 같은 PKI를 사용합니다.

1. 클라이언트의 신원을 증명하십시오.
2. 메시지가 전송 중 수정되지 않았 음을 증명하십시오 (MITM).
3. 서버가 클라이언트를 인증 / 인증 할 수 있도록합니다.

마지막 요점은 클라이언트 (발신자)의 신원이 서비스로부터 그러한 데이터를 수신 할 권한이 있는지를 아는 것이 가장 중요 할 때 서비스 요청에 중요합니다. 표준 SSL은 단방향 (서버) 인증이며 클라이언트를 식별하기 위해 아무 것도 수행하지 않습니다.

대답은 실제로 특정 요구 사항에 따라 다릅니다.

예를 들어, 웹 메시지를 보호해야합니까, 기밀성이 필요하지 않고 엔드 파티를 인증하고 메시지 무결성을 보장하기 만하면됩니까? 이 경우 (그리고 종종 웹 서비스의 경우) HTTPS는 아마도 잘못된 망치 일 것입니다.

그러나 내 경험으로는 구축중인 시스템의 복잡성을 간과하지 마십시오. HTTPS를 올바르게 배포하는 것이 더 쉬울뿐만 아니라 전송 계층 보안을 사용하는 응용 프로그램은 일반 HTTP를 통해 디버깅하기가 더 쉽습니다.

행운을 빕니다.

HTTPS를 통한 REST API 제공자가 서버 엔드 권한을 구현하는 한 안전한 방법이어야합니다. 웹 응용 프로그램뿐만 아니라 HTTPS와 일부 인증 / 권한을 통해 웹 응용 프로그램에 액세스하는 경우 전통적으로 웹 응용 프로그램에는 보안 문제가 없었으며 Restful API는 문제없이 보안 문제를 처리합니다!

RESTFul 호출이 HTTP 요청의 HTML 본문에 임베드 된 XML 메시지를주고받는 경우 보안 기능을 사용하면서 XML 메시지에 XML 암호화, Cerificates 등과 같은 WS-Security의 모든 이점을 가질 수 있어야합니다. SSL / TLS 암호화와 같은 http에서 사용할 수 있습니다.