web-dev-qa-db-ja.com

RESTサービスのエンドツーエンドのセキュリティ、新しい標準はありますか？

私は、エンドツーエンドのセキュリティが重要であるヘルスケアセクターの統合に取り組んでいます。多数のSOAP=サービスと統合し、WS-セキュリティ機能を使用してリクエストとレスポンスを暗号化して署名します。

リクエストとレスポンスは、統合シナリオのいくつかの中間層を通過します。したがって、データ自体が暗号化されていることが重要です（メッセージセキュリティ）。 HTTPS（トランスポートセキュリティ）を使用すると、SSLが終了するまでメッセージが保護されます。

また、RESTスタイルのサービスと統合します。 AFAIK、RESTペイロードを保護するための（WS-securityのような）標準的なアプローチはありません。

RESTペイロードを署名および暗号化するための新しい標準はありますか？

[〜＃〜]編集[〜＃〜]

  • Amazon S3サービス 暗号化を実装 。 S3アップロードクライアントがSOAPまたはRESTスタイルの呼び出しを使用しているかどうかはわかりません。
  • この修士論文 は約RESTセキュリティです。
encryptiondigital-signatureweb-servicerest
7
codeape

RESTfulスタックを介したIDの伝播について質問していると思います。つまり、ダウンストリームシステムがユーザーごとに承認を検証できるように、要求を元のユーザーに関連付ける必要があります。私も最近この問題を調査しています。

根本的には、いいえ、RESTサービスのID伝播には標準が定義されていません。REST自体は標準ではなく、アーキテクチャパターンです。

Kerberos（ JAX-RS など）または HTTPバインディング経由のSAML などの既存の標準との統合を提供するライブラリがいくつかあります。

JSON Web Token（JWT）を使用したさまざまなアプローチが一般的になりつつありますが、これは「独自のロール」アプローチに近いものであり、柔軟性を提供しますが、実装リスクは犠牲になります。これはやや最先端の​​エッジです。 JWTのRFCは、2015年4月にのみ承認されました。

2
JaimeCastells

JWTは主に認証用ですが、トークンをカスタマイズしてロールを含め、承認に使用することもできます。

Httpメッセージの署名と暗号化については、JSON Web Signature（JWS）とJSON Web Encryption（JWE）をご覧ください。これらはどちらもJSON Object Signing and Encryption（JOSE）フレームワークの一部であるRFCです。

0
Paulo Merson

エンドツーエンドのセキュリティが重要な要素である場合、採用するための最良のアプローチはその間の何も信頼しないことです。その場合、セキュリティで保護されている場合とそうでない場合があるため、どのプロトコルまたはAPIがその間に使用されているかは関係ありません。 IMOこれは公正な仮定です。複数の中間層を持つ合理的に複雑なシステムでは、通信チャネルが適切に保護されている保証はありません。または、不必要にデータを必要以上に長くキャッシュしないため、機密データが開示される可能性のあるウィンドウが開きます。

提案：

  • 宛先サーバーは鍵のペア（公開+秘密鍵）を生成します。例えば。 4096ビットのRSA。
  • 公開鍵をクライアントに配布します。例えば。モバイルクライアントは、アプリに既にパッケージ化された公開キーを持つことができます。
  • クライアントは、公開データを使用して機密データを暗号化し、暗号文を送信します。宛先サーバーのみが暗号文を復号化できます。
0
HTLee