安全なWebサービス：REST over HTTPS vs SOAP + WS-Security。どちらが良いですか？[閉まっている]

私は決してセキュリティの専門家ではありませんが、RESTスタイルのWebサービスを作成することを好みます。

安全に送信するデータを必要とする新しいサービスを作成する場合。どのアプローチがより安全であるかについての議論に入りました-HTTPSを使用したRESTまたはWS-Securityを使用したSOAP WS。

すべてのWebサービス呼び出しにHTTPSを使用でき、このアプローチは安全であるという印象を受けています。私がそれを見る方法は、「HTTPSが銀行や金融のWebサイトに十分であるなら、私には十分です」です。繰り返しますが、私はこの分野の専門家ではありませんが、これらの人々はこの問題についてかなり熱心に考え、HTTPSに慣れていると思います。

同僚は反対し、SOAPとWS-Securityが唯一の方法であると述べています。

Webはこれの全面的なようです。

たぶん、ここのコミュニティはそれぞれの長所と短所を比較検討できるでしょうか？ありがとう！

HTTPSは、ネットワークを介したメッセージの送信を保護し、サーバーのIDについてクライアントに何らかの保証を提供します。これはあなたの銀行やオンライン株式ブローカーにとって重要なことです。クライアントの認証に対する彼らの関心は、コンピュータのアイデンティティではなく、あなたのアイデンティティにあります。そのため、カード番号、ユーザー名、パスワードなどが認証に使用されます。次に、通常、提出物が改ざんされていないことを確認するためにいくつかの予防措置が取られますが、全体として、セッションで発生したことはすべて、ユーザーによって開始されたと見なされます。

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のオーバーヘッドをスキップするべきです。私はそれが少々警戒外れであることを知っていますが、実際にどれだけの保護が正当化されるかについての決定は（構築するのに何がクールであるかだけでなく）、問題を熟知している人々によって行われる必要があります。

RESTセキュリティはトランスポートに依存していますが、SOAPセキュリティはそうではありません。

RESTは基になるトランスポートからセキュリティ対策を継承しますが、SOAPはWS-Securityを介して独自に定義します。

HTTPを介してRESTについて説明する場合、HTTPに適用されるすべてのセキュリティ対策は継承され、これはトランスポートレベルのセキュリティと呼ばれます。

トランスポートレベルのセキュリティ。メッセージがネットワーク上にある間のみ保護されます。ネットワークを離れるとすぐに、メッセージは保護されなくなります。

ただし、WS-Securityを使用すると、メッセージレベルのセキュリティが確保されます。メッセージがトランスポートチャネルを離れても、メッセージは保護されます。また、メッセージレベルのセキュリティでは、メッセージを部分的に暗号化できます[メッセージ全体ではなく、必要な部分のみ]-トランスポートレベルのセキュリティでは、暗号化できません。

WS-Securityには認証、整合性、機密性、否認防止の対策がありますが、SSLは否認防止をサポートしていません[2-legged OAuthの場合]。

パフォーマンスに関しては、SSLはWS-Securityよりもはるかに高速です。

ありがとう...

技術的には、SOAPメソッドの通信はセキュリティで保護されておらず、RESTメソッドは正当なユーザーの認証について何も言わなかったため、あなたの言い方は正しくありません。

HTTPSは、攻撃者が2つのシステム間の通信を盗聴するのを防ぎます。また、ホストシステム（サーバー）が実際にユーザーがアクセスしようとしているホストシステムであることも確認します。

WS-Securityは、不正なアプリケーション（ユーザー）がシステムにアクセスするのを防ぎます。

RESTfulシステムにユーザーを認証する方法があり、WS-Securityを使用するSOAPアプリケーションがHTTPSを使用している場合、実際には両方が安全です。これは、データの表示とアクセスの別の方法です。

wikiの記事を参照してください。

ポイントツーポイントの状況では、たとえばhttpsを介してメッセージを送信することにより、トランスポート層セキュリティ（TLS）を使用してWebサービスに機密性とデータの整合性を適用することもできます。

ただし、WS-Securityは、発信元ノードからメッセージが送信されるまでメッセージの整合性と機密性を維持するというより広範な問題に対処し、いわゆるエンドツーエンドのセキュリティを提供します。

あれは：

• HTTPSはトランスポート層（ポイントツーポイント）のセキュリティメカニズムです。
• WS-Securityは、アプリケーションレイヤー（エンドツーエンド）のセキュリティメカニズムです。

あなたが言うように、RESTは銀行にとって十分であり、あなたにとって十分であるはずです。

セキュリティには2つの主要な側面があります。1）暗号化と2）アイデンティティです。

SSL / HTTPSで送信すると、ネットワーク上で暗号化が行われます。ただし、両方のサーバーが、相手が誰であるかを確認できることを確認する必要もあります。これは、SSLクライアント証明書、共有シークレットなどを介して行うことができます。

SOAPは「より安全」であると言えるかもしれませんが、おそらくそれほど重要ではありません。裸のモーターサイクリストのアナロジーはかわいいですが、正確であればインターネット全体が安全ではないことを意味します。

コメントを追加するのに必要な担当者がまだいないか、ベルの回答に追加しただけです。ベルは、2つのアプローチのトップレベルの長所と短所をまとめた非常に良い仕事をしたと思います。あなたが考慮したいと思うかもしれない他のいくつかの要因：

1）クライアントとサービスの間のリクエストは、ペイロードへのアクセスを必要とする仲介者を経由する必要がありますか？その場合、WS-Securityの方が適している可能性があります。

2）実際には、SSLを使用して、相互認証と呼ばれる機能を使用して、クライアントIDに関する保証をサーバーに提供することができます。ただし、構成が複雑であるため、一部の非常に特殊なシナリオ以外では、あまり使用されません。したがって、WS-Secの方がはるかに適しているとBellは言うまでもありません。

3）SSLは、主に証明書の管理上の問題により、（より単純な構成であっても）セットアップと維持に少々手間がかかります。あなたのプラットフォームでこれを行う方法を知っている誰かがいることは大きなプラスになります。

4）何らかの資格マッピングまたはIDフェデレーションを行う必要がある場合、WS-Secはオーバーヘッドに値するかもしれません。RESTを使用してこれを行うことができないということではなく、支援するための構造が少ないだけです。

5）すべてのWS-Security goopをクライアント側の適切な場所に配置することは、思ったよりも大変なことです。

結局のところ、それは実際には私たちが知らない可能性が高い多くのことに依存しています。ほとんどの状況では、どちらのアプローチも「十分に安全」であり、それが主な決定要因であってはならないと私は言います。

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

今日、私はガールフレンドにHTTPSではなくWS-Securityの表現力の違いを説明しなければなりませんでした。彼女はコンピューターサイエンティストであるため、XMLマンボジャンボをすべて知らなくても、暗号化または署名の意味を理解しています（おそらく私よりも優れています）。しかし、私は彼女がそれらがどのように実装されるかではなく、何が有用であるかを本当に理解できる強力なイメージを望んでいました（それは少し後で、彼女はそれを逃れませんでした:-)）。

だからこのようになります。あなたが裸で、オートバイを特定の目的地まで運転しなければならないとします。（A）の場合、透明なトンネルを通過します。わいせつな行動で逮捕されないというあなたの唯一の望みは、誰も見ていません。それはあなたが思いつくことができる最も安全な戦略ではありません...（男の額からの汗の滴に注意してください:-)）。これは、POSTを平文で表したものに相当します。「同等」と言った場合、それはそうです。（B）の場合は、より良い状況にあります。トンネルは不透明なので、そこに旅行する限り、公の記録は安全です。ただし、これはまだ最良の状況ではありません。あなたはまだ家を出てトンネルの入り口に到達する必要があり、いったんトンネルの外に出ると、おそらく降りてどこかを歩く必要があります...そしてそれはHTTPSに当てはまります。確かに 最大の亀裂を通過する間、メッセージは安全です。しかし、いったん反対側に配信した後は、データが処理される実際のポイントに到達するまでに通過する必要があるステージの数がわかりません。そしてもちろん、これらすべてのステージでは、HTTPとは異なる何かを使用することができます。たとえば、すぐには処理できない要求をバッファリングする従来のMSMQです。彼らがその前処理リンボにいる間に誰かがあなたのデータを潜んでいる場合はどうなりますか？うーん。（この「hm」を、「あなたが呼吸している空気だと思いますか？」という文の終わりにモーフィアスが発声したものと読んでください。）この比喩の完全な解決策（c）は痛々しいほど簡単です。自分自身、特にバイクに乗っているときはヘルメットを身に着けてください!!! したがって、環境の不透明性に依存する必要なく、安全に移動できます。メタファーはうまくいけば明確です：メッセージレベルのセキュリティと同様に、平均や周囲のインフラストラクチャに関係なく、服はあなたと一緒に来ます。さらに、ある部分をカバーして別の部分を明らかにすることもできます（個人的に行うこともできます：空港のセキュリティはジャケットと靴を脱ぐことができますが、医師はより高いアクセスレベルを持っている可能性があります）が、半袖シャツはあなたが上腕二頭筋を誇りに思っているとしても、悪い習慣:-)（ポロ、またはTシャツの方がいい）。

彼女が要点を得たと言って嬉しいです！私は服のメタファーは非常に強力だと言わざるを得ません。私はそれをポリシーの概念を導入するために使用したくなりました（ディスコクラブはスポーツシューズではあなたを許可しません。あなたは下着の銀行でお金を引き出すことはできません。 、これはサーフィンで自分のバランスをとっている間は完全に許容できる外観ですが、等）しかし、午後にはそれで十分だと思いました;-)

アーキテクチャ-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つのレイヤーにすぎません。

1. 接続先のサーバーは、身元を証明する証明書を提示します（ただし、これはDNSポイズニングによって偽装される可能性があります）。
2. 通信層は暗号化されます（盗聴はありません）。

WS-Securityおよび関連する標準/実装は、以下のPKIを使用します。

1. クライアントの身元を証明します。
2. メッセージが送信中に変更されなかったことを証明します（MITM）。
3. サーバーがクライアントを認証/承認できるようにします。

最後のポイントは、クライアント（呼び出し元）のIDが、サービスからそのようなデータを受信することを承認されるべきかどうかを知ることが最も重要である場合、サービス要求にとって重要です。標準SSLは一方向（サーバー）認証であり、クライアントの識別には何も行いません。

答えは実際には特定の要件によって異なります。

たとえば、Webメッセージを保護する必要があるか、または機密性は不要であり、エンドパーティを認証してメッセージの整合性を確保することだけが必要ですか？これが当てはまる場合-そしてそれは多くの場合Webサービスにあります-HTTPSはおそらく間違ったハンマーです。

ただし、-私の経験から-構築しているシステムの複雑さを見落とさないでください。HTTPSを正しくデプロイする方が簡単なだけでなく、トランスポート層のセキュリティに依存するアプリケーションのデバッグも（プレーンHTTPを介して）簡単です。

幸運を。

REST over HTTPSは、APIプロバイダーがサーバー側の承認を実装している限り、安全な方法である必要があります。Webアプリケーションの場合も、HTTPSといくつかの認証/承認を介してWebアプリケーションにアクセスすることで、従来のWebアプリケーションにはセキュリティの問題がありませんでしたが、Restful APIも問題なくセキュリティの問題に対抗しました！

RESTFul呼び出しがHTTPリクエストのHTMLボディに埋め込まれたXMLメッセージを送受信する場合、セキュリティ機能を使用しながら、XMLメッセージでXML暗号化、証明書などのWS-Securityのすべての利点を享受できるはずです。 SSL / TLS暗号化などのhttpから入手できます。