セキュアWebサービス：REST over HTTPS vs SOAP + WS-Security。どちらが良いですか？
私は決してセキュリティの専門家ではありませんが、RESTスタイルのWebサービスを作成することを好みます。
データを安全に送信する必要がある新しいサービスを作成する際に。 HTTPSを使用するRESTまたはWS-Securityを使用するSOAP WSのどちらのアプローチがより安全であるかについて議論を始めました。
すべてのWebサービス呼び出しにHTTPSを使用でき、このアプローチは安全であると思われます。私がそれを見る方法は、「HTTPSが銀行や金融のWebサイトに十分であれば、私には十分です」です。繰り返しますが、私はこの分野の専門家ではありませんが、これらの人々はこの問題についてかなり一生懸命に考えており、HTTPSに慣れていると思います。
同僚が同意せず、SOAPと言い、WS-Securityが唯一の方法です。
これについては、ウェブが全面的に見えます。
ここのコミュニティは、それぞれの長所と短所に重きを置くことができますか？ありがとう！
HTTPSは、ネットワークを介したメッセージの送信を保護し、サーバーのIDについてクライアントにある程度の保証を提供します。これは、銀行またはオンライン株式ブローカーにとって重要なことです。クライアントの認証に対する彼らの関心は、コンピューターのアイデンティティではなく、あなたのアイデンティティにあります。そのため、カード番号、ユーザー名、パスワードなどがユーザーの認証に使用されます。通常、送信が改ざんされていないことを確認するためにいくつかの予防措置が講じられますが、全体として、セッションで発生したことはすべて、ユーザーによって開始されたと見なされます。
WS-Securityは、メッセージの作成から消費まで、機密性と整合性の保護を提供します。そのため、通信のコンテンツを適切なサーバーでしか読み取れないようにするのではなく、サーバー上の適切なプロセスでしか読み取れないようにします。安全に開始されたセッションでのすべての通信は認証されたユーザーからのものであると想定する代わりに、それぞれに署名する必要があります。
裸のバイク乗りが関与する面白い説明がここにあります：
したがって、WS-SecurityはHTTPSよりも強力な保護を提供し、SOAPはRESTよりも豊富なAPIを提供します。私の意見では、追加の機能や保護が本当に必要でない限り、SOAPとWS-Securityのオーバーヘッドをスキップする必要があります。私はそれがちょっとした警戒であることを知っていますが、実際にどれだけの保護を正当化するか（構築するのがクールなものだけでなく）についての決定は、問題をよく知っている人々によって行われる必要があります。
RESTセキュリティはトランスポート依存ですが、SOAPセキュリティは依存しません。
SOAPはWS-Securityを介して独自に定義しますが、RESTは基になるトランスポートからセキュリティ対策を継承します。
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の方がはるかに適していると言っています。
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、ワイルドアイデア
私は毎日このスペースで仕事をしているので、これについての良いコメントをまとめて、これを締めくくりたいと思います。
SSL（HTTP/s）は、次のことを保証する1つのレイヤーにすぎません。
- 接続されているサーバーは、その身元を証明する証明書を提示します（ただし、これはDNSポイズニングによってなりすますことができます）。
- 通信層は暗号化されています（盗聴されません）。
WS-Securityおよび関連する標準/実装では、次のことを行うPKIを使用します。
- クライアントの身元を証明します。
- メッセージが転送中に変更されなかったことを証明します（MITM）。
- サーバーがクライアントを認証/承認できるようにします。
クライアント（呼び出し元）のIDが、サービスからそのようなデータを受信するために承認されるべきかどうかを知ることが最重要である場合、サービスリクエストにとって最後のポイントは重要です。標準SSLは一方向（サーバー）認証であり、クライアントの識別には何もしません。
REST over HTTPS APIプロバイダーがサーバーエンドで認証を実装している限り、安全な方法である必要があります。 Webアプリケーションの場合も、HTTPSと認証/承認を介してWebアプリケーションにアクセスすることは、従来のWebアプリケーションにはセキュリティの問題がなかったため、Restful APIはセキュリティの問題にも問題なく対処できます。
実際の答えは、特定の要件によって異なります。
たとえば、Webメッセージを保護する必要がありますか、それとも機密性は不要で、必要なのはエンドパーティを認証し、メッセージの整合性を確保することだけですか？これが当てはまる場合、そして多くの場合Webサービスを使用する場合、HTTPSはおそらく間違ったハンマーです。
ただし、私の経験からすると、構築しているシステムの複雑さを見落とさないでください。 HTTPSを正しく展開するのが簡単であるだけでなく、トランスポートレイヤーセキュリティに依存するアプリケーションをデバッグするのが簡単です（プレーンHTTP経由）。
がんばろう。
RESTFul呼び出しがHTTP要求のHtml Bodyに埋め込まれたXMLメッセージを送受信する場合、XML暗号化、証明書など、WS-Securityのすべての利点を、あらゆるセキュリティ機能を使用しながらXMLメッセージに含めることができるはずです。 SSL/TLS暗号化などのhttpから入手できます。