10

REST APIにメッセージレベルのセキュリティを実装する必要があり、いくつかの懸念事項と質問があります。私はここで答えを見つけました： RESTWebサービスのメッセージレベルのセキュリティ

部分的にしか役に立ちません。

現在、標準のSSLトランスポートセキュリティと、次のようないくつかの認証方法をサポートしています。

  • 基本http認証（APIと通信する一部のネットワーク機器サービスで必要）
  • SHA1フレーバーとSHA256フレーバーの両方で事前共有秘密鍵を使用するHMAC。
  • TLSレベルで送信されるクライアントID証明書。
  • SAML 2.0

メッセージレベルのセキュリティが必要な理由：

  • 顧客業界には、とりわけヘルスケア、金融、政府が含まれ、SSLのみに眉をひそめることがよくあります。
  • エンドツーエンドのセキュリティを保証する必要があります。リバースプロキシ、SSLアクセラレータなどを介して...
  • サービスを介して渡される一部のデータには、非常に機密性の高いデータが含まれます。
  • SOAPのWS-*セキュリティ標準は「エンタープライズストレングス」のWebサービスであり、REST APIはそうではないと主張する顧客に対して、適切な回答を得る必要があります。

私の最初の考えは、クライアントアプリケーションがエンベロープ応答の処理方法を理解している場合、オプションとしてPKCS＃7エンベロープを使用することです。

クライアントアプリケーションに、セキュリティで保護された応答が必要であることをAPIに通知するか、POSTまたはPUTingしているメッセージがセキュリティで保護されていることをAPIに通知してもらいたいです。

私の本当の質問は、これはメディアタイプを介して伝達されるべきかということです。例えば：

  • コンテンツタイプ：application / vnd.resourcetype1 + json + pkcs7
  • コンテンツタイプ：txt / csv + pkcs7

エンベロープされているメディアタイプに関する情報を失いたくありません。

場合によっては署名で十分なので、複雑になります。その他にも暗号化が必要です。「pkcs7」という用語は、エンベロープの作成方法に関してあいまいです。

クライアントとサーバーが、送信しているコンテンツの種類と、標準のHTTPヘッダーを介して理解しているコンテンツの種類を相互に伝えてほしい。

4

1 に答える 1

1

もちろん、APIを定義する方法はあなた次第です。正しい方法も間違った方法もありませんが、S / MIMEは非常によく理解されているメッセージ形式であり、インターネットに適しています。分散型の信頼階層を希望する場合は、 PGP/MIMEも同様です。これらはよく理解されている形式であるため、クライアントは既存のライブラリを採用してこれらのメッセージ本文を処理できます。

マルチパート応答を使用したくない場合は、Content-Typeだけでなく、 Content-Encodingヘッダーも確認することをお勧めします。次に、署名/暗号化形式をカスタムエンコーディングタイプとして指定できます。

トランスポートプロトコルだけでなく、アプリケーションプロトコルとしてHTTPを使用することには大きな利点がありますが、それはすでに理解しているようです。q値を含め、Accept*ヘッダーを正しく設定および解析してください。デフォルトのq=1は等しい（降順ではない）優先度を意味し、q=0などに注意してください。

于 2012-12-05T13:51:19.873 に答える