보안 웹 서비스 : HTTPS를 통한 REST 대 SOAP + WS- 보안. 어떤게 더 좋아? [닫은]
나는 보안 전문가가 아니지만 REST 스타일 웹 서비스를 만드는 것을 선호합니다.
데이터를 안전하게 보관해야하는 새로운 서비스를 만들 때 HTTPS를 사용하는 REST 또는 WS-Security를 사용하는 SOAP WS 인 더 안전한 접근 방식에 대한 토론을 시작했습니다.
모든 웹 서비스 호출에 HTTPS를 사용할 수 있다는 인상을 받았으며이 접근 방식은 안전합니다. 내가 보는 방식은 "HTTPS가 은행 및 금융 웹 사이트에 충분하면 나에게 충분하다"입니다. 다시 한 번이 분야의 전문가는 아니지만이 사람들이이 문제에 대해 상당히 열심히 생각하고 HTTPS에 익숙하다고 생각합니다.
동료가 동의하지 않으며 SOAP 및 WS-Security가 유일한 방법이라고 말합니다.
웹은 여기에 온통 보인다.
여기의 커뮤니티가 각각의 장단점을 고려할 수 있습니까? 감사!
HTTPS는 네트워크를 통한 메시지 전송을 보호하고 서버의 신원에 대해 클라이언트에게 약간의 보증을 제공합니다. 이것이 은행이나 온라인 주식 중개인에게 중요한 것입니다. 클라이언트 인증에 대한 그들의 관심은 컴퓨터의 정체성이 아니라 당신의 정체성에 있습니다. 따라서 카드 번호, 사용자 이름, 비밀번호 등이 귀하를 인증하는 데 사용됩니다. 그런 다음 제출이 변경되지 않도록하기 위해 일반적으로 몇 가지주의 사항이 취해 지지만 세션에서 발생하는 모든 일은 사용자가 시작한 것으로 간주됩니다.
WS-Security는 메시지 작성에서 메시지 사용에 이르기까지 기밀성 및 무결성 보호 기능을 제공합니다. 따라서 통신 내용을 올바른 서버에서만 읽을 수 있도록하는 대신 서버의 올바른 프로세스에서만 읽을 수 있습니다. 안전하게 시작된 세션의 모든 통신이 인증 된 사용자의 통신이라고 가정하는 대신 각 사용자가 서명해야합니다.
벌거 벗은 오토바이 운전자와 관련된 재미있는 설명이 있습니다.
따라서 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는 응용 프로그램 계층 (end-to-end) 보안 메커니즘입니다.
당신이 말했듯이 REST는 은행에 충분하기 때문에 충분해야합니다.
보안에는 두 가지 주요 측면이 있습니다. 1) 암호화와 2) ID.
SSL / HTTPS로 전송하면 유선으로 암호화됩니다. 그러나 두 서버 모두 자신이 말하는 사람을 확인할 수 있는지 확인해야합니다. SSL 클라이언트 인증서, 공유 비밀 등을 통해 가능합니다.
나는 SOAP가 "보다 안전하다"고 생각할 수 있지만, 그다지 중요하지는 않다. 누드 오토바이 운전자의 비유는 귀엽지 만 정확한 경우 전체 인터넷이 안전하지 않다는 것을 암시합니다.
댓글을 추가하는 데 필요한 담당자가 없거나 Bell의 답변에 방금 추가했을 것입니다. Bell은 두 가지 접근법의 최상위 장단점을 요약하는 데 매우 훌륭하다고 생각합니다. 고려해야 할 몇 가지 다른 요소들 :
1) 클라이언트와 서비스 간의 요청은 페이로드에 액세스해야하는 중개자를 거쳐야합니까? 그렇다면 WS-Security가 더 적합 할 수 있습니다.
2) 실제로 SSL을 사용하여 상호 인증이라는 기능을 사용하여 클라이언트 ID에 대한 보증을 서버에 제공 할 수 있습니다. 그러나 이것은 복잡한 구성으로 인해 매우 특수한 시나리오 이외의 용도로는 많이 사용되지 않습니다. 따라서 Bell은 WS-Sec이 여기에 훨씬 더 적합합니다.
3) SSL은 일반적으로 인증서 관리 문제로 인해 설정 및 유지 관리 (심지어 간단한 구성에서도)에 약간의 부담이 될 수 있습니다. 귀하의 플랫폼에 대해이 작업을 수행하는 방법을 아는 사람이 있으면 큰 도움이 될 것입니다.
4) If you might need to do some form of credential mapping or identity federation then WS-Sec might be worth the overhead. Not that you can't do this with REST, you just have less structure to help you.
5) Getting all the WS-Security goop into the right places on the client side of things can be more of a pain than you would think it should.
In the end though it really does depend on a lot of things we're not likely to know. For most situations I would say that either approach will be "secure enough" and so that shouldn't be the main deciding factor.
Brace yourself, here there's another coming :-)
Today I had to explain to my girlfriend the difference between the expressive power of WS-Security as opposed to HTTPS. She's a computer scientist, so even if she doesn't know all the XML mumbo jumbo she understands (maybe better than me) what encryption or signature means. However I wanted a strong image, which could make her really understand what things are useful for, rather than how they are implemented (that came a bit later, she didn't escape it :-)).
So it goes like this. Suppose you are naked, and you have to drive your motorcycle to a certain destination. In the (A) case you go through a transparent tunnel: your only hope of not being arrested for obscene behaviour is that nobody is looking. That is not exactly the most secure strategy you can come out with... (notice the sweat drop from the guy forehead :-)). That is equivalent to a POST in clear, and when I say "equivalent" I mean it. In the (B) case, you are in a better situation. The tunnel is opaque, so as long as you travel into it your public record is safe. However, this is still not the best situation. You still have to leave home and reach the tunnel entrance, and once outside the tunnel probably you'll have to get off and walk somewhere... and that goes for HTTPS. True, your message is safe while it crosses the biggest chasm: but once you delivered it on the other side you don't really know how many stages it will have to go through before reaching the real point where the data will be processed. And of course all those stages could use something different than HTTP: a classical MSMQ which buffers requests which can't be served right away, for example. What happens if somebody lurks your data while they are in that preprocessing limbo? Hm. (read this "hm" as the one uttered by Morpheus at the end of the sentence "do you think it's air you are breathing?"). The complete solution (c) in this metaphor is painfully trivial: get some darn clothes on yourself, and especially the helmet while on the motorcycle!!! So you can safely go around without having to rely on opaqueness of the environments. The metaphor is hopefully clear: the clothes come with you regardless of the mean or the surrounding infrastructure, as the messsage level security does. Furthermore, you can decide to cover one part but reveal another (and you can do that on personal basis: airport security can get your jacket and shoes off, while your doctor may have a higher access level), but remember that short sleeves shirts are bad practice even if you are proud of your biceps :-) (better a polo, or a t-shirt).
I'm happy to say that she got the point! I have to say that the clothes metaphor is very powerful: I was tempted to use it for introducing the concept of policy (disco clubs won't let you in sport shoes; you can't go to withdraw money in a bank in your underwear, while this is perfectly acceptable look while balancing yourself on a surf; and so on) but I thought that for one afternoon it was enough ;-)
Architecture - WS, Wild Ideas
I work in this space every day so I want to summarize the good comments on this in an effort to close this out:
SSL (HTTP/s) is only one layer ensuring:
- The server being connected to presents a certificate proving its identity (though this can be spoofed through DNS poisoning).
- The communications layer is encrypted (no eavesdropping).
WS-Security and related standards/implementations use PKI that:
- Prove the identity of the client.
- Prove the message was not modified in-transit (MITM).
- Allows the server to authenticate/authorize the client.
The last point is important for service requests when the identity of the client (caller) is paramount to knowing IF they should be authorized to receive such data from the service. Standard SSL is one-way (server) authentication and does nothing to identify the client.
The answer actually depends on your specific requirements.
For instance, do you need to protect your web messages or confidentiality is not required and all you need is to authenticate end parties and ensure message integrity? If this is the case - and it often is with web services - HTTPS is probably the wrong hammer.
However - from my experience - do not overlook the complexity of the system you're building. Not only HTTPS is easier to deploy correctly, but an application that relies on the transport layer security is easier to debug (over plain HTTP).
Good luck.
REST Over HTTPS Should be a secure method as long as API provider implements authorization a server end. In a case of web application as well what we do is accessing a web application via HTTPS and some authentication/authorization, traditionally web applications did not have security issues then Restful API would also counter security issues without problem !
If your RESTFul call sends XML Messages back and forth embedded in the Html Body of the HTTP request, you should be able to have all the benefits of WS-Security such as XML encryption, Cerificates, etc in your XML messages while using whatever security features are available from http such as SSL/TLS encryption.
'Programming' 카테고리의 다른 글
| 정수를 삽입하려고 할 때 MongoDB 삽입 부동 (0) | 2020.05.18 |
|---|---|
| data.table에서 이름으로 열을 어떻게 삭제합니까? (0) | 2020.05.18 |
| VueJs 2.0-`props '변경을 듣는 방법 (0) | 2020.05.18 |
| 숫자의 가장 큰 소인수를 구하는 알고리즘 (0) | 2020.05.18 |
| MySQL은 다른 열과 함께 하나의 열 DISTINCT를 선택합니다. (0) | 2020.05.18 |