WS セキュリティ

Web サービス セキュリティ( WS-Security、WSS ) は、 Web サービスにセキュリティを適用するためのSOAPの拡張機能です。これはWeb サービス仕様の 1 つであり、 OASISによって公開されました。

このプロトコルは、メッセージの整合性と機密性をどのように強制するかを指定し、Security Assertion Markup Language (SAML)、Kerberos、X.509などのさまざまなセキュリティ トークン形式の通信を可能にします。主な焦点は、エンドツーエンドのセキュリティを提供するための XML 署名とXML 暗号化の使用です。

WS-Security では、次の 3 つの主要なメカニズムについて説明します。

• 整合性を保証するために SOAP メッセージに署名する方法。署名されたメッセージは否認防止も提供します。
• 機密性を保証するために SOAP メッセージを暗号化する方法。
• 送信者の身元を確認するためにセキュリティ トークンを添付する方法。

この仕様では、さまざまな署名形式、暗号化アルゴリズム、複数の信頼ドメインが許可されており、次のようなさまざまなセキュリティ トークン モデルがサポートされています。

• X.509証明書、
• ケルベロスチケット、
• ユーザーID/パスワードの資格情報、
• SAMLアサーション、および
• カスタム定義トークン。

トークンの形式とセマンティクスは、関連するプロファイル ドキュメントで定義されます。

WS-Security は、アプリケーション層で動作する SOAP メッセージのヘッダーにセキュリティ機能を組み込みます。

これらのメカニズムだけでは、Web サービスに完全なセキュリティ ソリューションを提供することはできません。代わりに、この仕様は、他の Web サービス拡張機能や、より高レベルのアプリケーション固有のプロトコルと組み合わせて使用​​することで、さまざまなセキュリティ モデルやセキュリティ テクノロジに対応できるビルディング ブロックです。一般に、WSS だけではセキュリティは保証されません。フレームワークと構文を実装して使用する場合、結果が脆弱にならないようにするのは実装者の責任です。

キー管理、信頼のブートストラップ、フェデレーション、および技術的な詳細 (暗号、形式、アルゴリズム) に関する合意は、WS-Security の範囲外です。

SOAP 仲介者が必要で、その仲介者の信頼性がそれほど高くない場合は、メッセージに署名し、必要に応じて暗号化する必要があります。これは、TCP (伝送制御プロトコル) 接続を終了するネットワーク境界のアプリケーション レベル プロキシの場合に当てはまります。

否認防止の 1 つの方法は、特定のセキュリティ保護の対象となる監査証跡にトランザクションを書き込むことです。WS-Security がサポートするデジタル署名は、より直接的で検証可能な否認防止証明を提供します。

ほぼすべての SOAP サービスは HTTP バインディングを実装していますが、理論的にはJMSや SMTPなどの他のバインディングを使用することもできます。この場合、エンドツーエンドのセキュリティが必要になります。

Web サービスがトランスポート層セキュリティに依存している場合でも、サービスが (HTTP) リバース プロキシによって中継される場合は、サービスがエンド ユーザーについて認識している必要がある場合があります。WSS ヘッダーを使用して、リバース プロキシによって保証されたエンド ユーザーのトークンを伝達できます。

• サービス プロバイダーとコンシューマーの間で頻繁にメッセージ交換が行われる場合、XML SIG と XML ENC のオーバーヘッドは大きくなります。エンドツーエンドのセキュリティが必要な場合は、WS-SecureConversationなどのプロトコルを使用するとオーバーヘッドが軽減される可能性があります。十分な場合は、暗号化または署名のみを使用してください。両方の組み合わせは、単一の操作を単純に合計した場合よりも大幅に遅くなります。以下のパフォーマンスを参照してください。
• SOAP、SAML、XML ENC、XML SIG などの複数の XML スキーマをマージすると、正規化や解析などのライブラリ関数の異なるバージョンへの依存関係が発生する可能性がありますが、これはアプリケーション サーバーでの管理が困難です。
• CBCモードの暗号化/復号化のみが適用される場合、または復号化前に安全なチェックサム（署名またはMAC ）を検証せずにCBCモードの復号化が適用された場合、実装はパディングオラクル攻撃に対して脆弱になる可能性があります。^[1]

WS-Security では、ネットワーク上のメッセージのサイズの増加、XML および暗号化処理により、SOAP 処理に大幅なオーバーヘッドが追加され、より高速な CPU とより多くのメモリおよび帯域幅が必要になります。

2005 年の評価^[2]では、Pentium 4/2.8 GHz CPU 上で WS-Security と WS-SecureConversation の両方を備えた WSS4J によって処理された、サイズと複雑さが異なる 25 種類の SOAP メッセージが測定されました。次のような結果が得られました。

• 暗号化は署名よりも高速でした。
• 暗号化と署名を組み合わせると、署名のみの場合よりも 2 ～ 7 倍遅くなり、生成されるドキュメントのサイズが大幅に大きくなります。
• メッセージのタイプに応じて、WS-SecureConversation は効果がない、または最良の場合で処理時間を半分に短縮しました。
• 100キロバイトまでの配列に署名または暗号化するには10ミリ秒未満しかかかりませんでしたが、SOAPのセキュリティ操作を実行するには約100〜200ミリ秒かかりました。

2006年の別のベンチマーク^[3]では、次のような比較が行われました。

Web サービスは当初、基盤となるトランスポート セキュリティに依存していました。実際、ほとんどの実装では今でもそうしています^{[引用が必要]}。SOAP では、HTTP や SMTP などの複数のトランスポート バインディングが許可されているため、SOAP レベルのセキュリティ メカニズムが必要でした。トランスポート セキュリティへの依存によるエンドツーエンドのセキュリティの欠如も、もう 1 つの要因でした。

このプロトコルはもともとIBM、Microsoft、VeriSignによって開発されました。最初の仕様^{[4] [5]}は2002年4月5日に公開され、2002年8月18日に補遺^[6]が発行されました。

2002年に、OASIS WSS技術委員会に2つの提案が提出されました。^[7] Webサービスセキュリティ（WS-Security）とWebサービスセキュリティ補遺。その結果、WS-Securityが公開されました。

• WS-Security 1.0 は 2004 年 4 月 19 日にリリースされました。
• バージョン 1.1 は 2006 年 2 月 17 日にリリースされました。

OASIS によって公開されたバージョン 1.0 標準には、IBM、Microsoft、および VeriSign コンソーシアムによって提案された標準との重要な相違点がいくつかありました。提案された標準を使用して開発されたシステムが多くありましたが、相違点により、OASIS 標準に従って開発されたシステムとの互換性がありませんでした。

OASIS以前の仕様を「WS-Security Draft 13」^[8]または Web Services Security Core 仕様と呼ぶ人もいます。しかし、これらの名前は広く知られておらず、実際、今日ではアプリケーションまたはサーバーが OASIS 以前の仕様を使用しているか、OASIS 以降の仕様を使用しているかを明確に識別することは困難です。ほとんどのフォーラム投稿では、OASIS 以前のバージョンを指すためにキーワード「WSSE」を使用しています。これは、^[9] URL (および異なるバージョンの同様の URL)に「wsse」 XML 名前空間プレフィックスを使用することが義務付けられていたためです。

このプロトコルは正式には WSS と呼ばれ、Oasis-Open の委員会を通じて開発されました。

WS-Security に関連するドラフト仕様は、WS-Federation、WS-Privacy、WS-Test です。

WS-Security に関連付けられている承認済みの仕様は、WS-Policy、WS-SecureConversation、WS-Trust、ID-WSFです。

次のアーキテクチャは WS-Security を利用します: TAS3。

ポイントツーポイントの状況では、たとえばHTTPS経由でメッセージを送信するなど、トランスポート層セキュリティ(TLS)を使用して Web サービスで機密性とデータの整合性を強化することもできます。ただし、WS-Security は、発信元ノードからメッセージが送信されるまでメッセージの整合性と機密性を維持するというより広範な問題に対処し、いわゆるエンドツーエンドのセキュリティを提供します。

TLS を適用すると、送信前にキーとメッセージ署名をXMLにエンコードする必要がなくなるため、関連するオーバーヘッドを大幅に削減できます。TLS を使用する場合の課題は、メッセージがアプリケーション レベルのプロキシ サーバーを経由する必要がある場合です。ルーティングのために要求を確認できる必要があるためです。このような例では、サーバーはクライアントではなくプロキシからの要求を確認します。これを回避するには、プロキシにクライアントのキーと証明書のコピーを持たせるか、署名証明書をサーバーが信頼し、クライアントのものと一致するキー/証明書のペアを生成できるようにします。ただし、プロキシはメッセージに対して操作を行わないため、エンドツーエンドのセキュリティは保証されず、ポイントツーポイントのセキュリティのみが保証されます。

• WS-Securityベースの製品とサービス
• サムエル
• WS-I 基本セキュリティ プロファイル
• 509 の
• XACML – きめ細かい動的認証の標準。

• Web サービス セキュリティ 1.1.1 (仕様ドキュメントをダウンロードするためのリンクが含まれています。)
• WS-I 基本セキュリティ プロファイル
• Web サービス セキュリティ ドキュメント
• WSS4J (Apache からの WS-Security Java 実装)
• Apache Rampart ( Apache Axis2からの WS-Security Java 実装)
• WSIT Java プラットフォームと Windows Communication Foundation (WCF) 間の相互運用性を実現する Web サービス相互運用性テクノロジ (WSIT)
• Python WS セキュリティの例