web-dev-qa-db-ja.com

相互TLSを使用してペイロードAPIをREST APIに追加する理由はありますか？

クライアント証明書認証を備えたB2B Rest APIがあります。
このAPIにペイロード署名チェックも追加する理由はありますか？

APIにデジタル署名ペイロードパラメータを追加する多くのサービスプロバイダーを見かけます。

すでにクライアント証明書認証が行われている場合、それは冗長なチェックですか、それとも別の目的に役立ちますか？
取引の否認防止に役立つ可能性があることを読みました。

authenticationdigital-signaturerestnon-repudiation
3
systempuntoout

これは「あなたのアーキテクチャに依存する」という大きなものになるのではないかと思います。そのため、ランダムなインターネットの人々はあなたに完全な答えを与えることができません。

ここからは、クライアント認証TLS andペイロードシグネチャを使用することが理にかなっているシナリオをいくつか紹介します。 1つ目はネットワークの制約です。

  • TLSはCloudFrontによって終了され、アプリサーバー/バックエンドはクライアント証明書を表示できません。
  • サーバーのバックエンドをプレーンテキストでバウンスしている間でも、メッセージの改ざん防止機能を維持する必要があります。

次に、TLS接続とAPIリクエストを論理的に分離できるホストがいくつかあります。

  • ログインしているすべてのユーザーのリクエストをルーティングする1つのサーバー<->サーバーTLS接続があります。
  • ペイロード署名は、おそらくライセンス上の理由で、ある種のAPIキーに関連付けられています。
  • 否認防止と監査：ユーザーには、TLS証明書よりも高いセキュリティレベルで保持される否認防止キーがあります。
3
Mike Ounsworth

両方が必要な理由の1つは、APIがインフラストラクチャで使用されており、クライアント証明書の検証とペイロードの検証が分離されている場合です。一部の環境では、クライアント証明書のチェックはエッジレベルで実行されますが、ペイロード検証は、負荷分散またはプロキシシステムのいくつかの層を通過した後、アプリケーションレベルで実行されます。

これは、クライアント証明書がシステムへの接続に有効であるが、内部ペイロードが実際には別のクライアントに対応する、巧妙な形式の攻撃を可能にする可能性があります-クライアント証明書が有効であるため、エッジシステムはアクセスを許可し、アプリケーションシステムは、どのユーザーがリクエストを行ったかを確認する方法がないため、アクションの実行を許可しますが、有効なリクエストのみを許可するようにEdgeレイヤーを信頼します。

ただし、ペイロードが署名されている場合、アプリケーションは、クライアント証明書チェックにアクセスできない場合でも、要求されたアクションが接続しているクライアントに適切であることを確認できます。

2
Matthew

ペイロードを検証するシステムとは別のシステムで終了するTLSに関する回答に加えて、TLSが同じホストで終了する場合でも、否認防止に役立つことが正しく聞こえました。

クライアント証明書は、サーバーに対してクライアントを認証するだけであり、送信されたデータを（直接）認証することはありません。クライアントとサーバー間で送信されるデータは暗号化されており、クライアントとサーバーだけが知っているキーで MACed であるため、通常これは問題ではありません。サーバーは受信したデータのMACをチェックできるので、クライアントから来たはずであることをitselfに簡単に証明できます（サーバーがそれを送信しないでください、それはクライアントであったに違いありません）しかし、サーバーはデータを作成しなかったことをothersに簡単に証明できません。 TLSキーを使用して暗号化し、MACを使用します。

こちら 関連する答え。

2
AndrolGenhald

相互TLSの代替案を提案しています...

法人のお客様がSAASサーバーで相互TLSを設定しようとすると、多くのサポート問題が発生しました。さらに、リーフ証明書を変更/更新しながら100％の稼働時間を維持するための適切なソリューションはありません。

代わりにデュアルHMACヘッダーの使用を検討することをお勧めします。

また、HMACは、TLS /相互TLSのトランスポート層チェックとは異なり、コンテンツの有効性のエンドツーエンドチェックを提供します

良い解決策については、Boxの記事をご覧ください。

1
Larry K