17

複数の企業 (数百) に展開される WCF サービスとクライアントがあります。ソフトウェアをネットワークで実行する企業もあれば、インターネット経由で実行する企業もあります (オフィスでは WCF サーバー、別のオフィスでは WCF クライアント)。

WCF サーバーとクライアント間の通信を暗号化します。クライアントがサーバーにログオンするために使用する独自のユーザー名/パスワード ログインがあるため、WCF セキュリティを使用して cient / サブスクライバーを認証する必要はありません。

  • 一部のユーザーはインターネット経由で Wi​​ndows 認証を実行し、WCF サーバーは WCF クライアントと同じドメインにない可能性があるため、Windows 認証に依存することはできません。
  • 「本物の」証明書*を使用する場合、ソフトウェアを実行している企業は CA から証明書を購入してインストールし、それを使用するようにソフトウェアを構成する必要がありますが、ほとんどの企業にとってこれは複雑すぎます。
  • WCF サーバーのインストール中に証明書を自動作成することもできますが、証明書を証明書ストアに自動的にインストールし、証明書を読み取るための IIS アクセス許可を何らかの方法で自動的に付与する必要があります。これは私たちが望むよりも複雑です。

要するに、暗号化が共有シークレット、この場合はユーザーがログオンしているユーザー名/パスワードに基づいている単純なソリューションが必要です。これが利用可能な最高の暗号化を提供しないことは理解していますが、ソフトウェアの展開を容易にするために、セキュリティの一部を喜んで交換します.

これは可能ですか？

*「本物の」証明書とは、認証局から購入した証明書を意味し、自分で作成した/自己署名した証明書ではありません。

4

5 に答える 5

17

トランスポートでメッセージを暗号化したい場合 (これは非常に良いアイデアです!)、送信者 (クライアント) とサーバーの間で共有された知識が必要です。これはハードコーディングできますが、それはまったく良い考えではありません。その「共通の共有」知識が危険にさらされると、攻撃者がすべてのメッセージを解読して読み取る可能性があります。

また、これは絶対に推奨される方法ではないため、WCF では共有シークレットの使用を簡素化するためのサポートは一切ありません。あなたは独力です - あなたは自分自身で100％転がさなければなりません。

共通の共有秘密を安全な方法で交換する唯一の実行可能な方法は、証明書を使用することです。これは仕方ありません、ごめんなさい。証明書は、ユーザー認証などに使用する必要さえありませんが、呼び出し元とサービスの間で共有秘密を確立するため、呼び出し元は、意図した受信者だけが実際に復号化して使用できるようにメッセージを暗号化できます。彼ら。

したがって、サーバーに証明書を保持する方法はまったくわかりません。すべてのクライアントにある必要はありませんが、サービスが実行されるすべてのサーバーにある必要はありません。

マルク

PS:「ハードコードされた共有シークレット」アプローチを本当に調査したい場合は、次のことを考慮する必要があります。

  • 共有シークレットをすべてのクライアントに安全に保存するにはどうすればよいでしょうか?
  • メッセージを暗号化するために、その保存された共有シークレットからの情報をどのように使用しますか?

通常、アプローチは次の 2 つになります。

  1. 何らかの形式の秘密鍵と公開鍵のペアを交換します。サーバーはキー ペアを生成し、秘密キーをそれ自体に保持し、公開キーをクライアントと共有します (たとえば、WCF メッセージを介して)。
  2. その秘密鍵と公開鍵のペアを使用して、メッセージを対称的に暗号化する「暗号化鍵」などの共通の共有秘密を交換します（対称であるため、サーバーは同じ鍵を使用してメッセージを復号化できます）
  3. クライアントにインフラストラクチャをセットアップし (例:動作と呼ばれる WCF 拡張機能)、メッセージが送信される前に検査し、共有シークレットで暗号化します。

全体として、それは本当に些細なことではありません。それより単純なものは、「セキュリティ」と呼ぶ価値はまったくありません。

あなたがしなければならないすべての作業を見ると、WCF 組み込みの証明書メカニズムを使用する方が簡単ではないでしょうか??

まともなセキュリティを確保するのは困難です。すべての作業を自分で行うのではなく、利用可能なものを活用しないでください。さらに悪いことに、すべてをクリアテキストで送信するのと同じくらい簡単にクラックできる中途半端なソリューションを考え出してください... .. 最も基本的なセキュリティ シナリオを処理するために必要なコードの複雑さと量を過小評価しないでください。WCF は、これらすべてを無料で、信頼性が高く安全な方法で行います。使用してください。あなたはそれを後悔しません！

于 2009-10-15T09:11:10.907 に答える
3

まあ、WCF を使用すると、メッセージ レベルでパスワード資格情報を使用し、トランスポート レベルで SSL を使用できます。これで十分だと思います。

ここを参照してください。

于 2009-10-15T08:26:43.220 に答える
1

メッセージのセキュリティのために、クライアントはいくつかの資格情報を提供し、サーバーはいくつかの資格情報を提供します。このセットアップとシナリオでは、カスタムユーザー名バリデーターでクライアントのユーザー名とパスワードを使用できず、サーバー証明書を使用してサーバーの資格情報を提供できませんでした。このアプリケーションシナリオは、カスタム検証構成に置き換える必要があるaspNetメンバーシップセクションを除いて、これを達成するために必要な構成セットアップの公正な方法を提供します。

サーバーにはまだ有効な証明書が必要です（クライアントには証明書は必要ありません）が、これを回避する方法はわかりません。

于 2009-10-19T08:47:07.137 に答える
1

次のサンプルを見てください。

http://www.codeproject.com/KB/WCF/wcfcertificates.aspx

証明書を使用しますが、証明書ストアがないため、セットアップは必要ありません。

于 2011-06-14T14:32:05.380 に答える
1

うーん..単純なものを使用できるかもしれません。暗号化をソフトウェアからハードウェアに移行します。各クライアント ネットワークから独自のネットワークに VPN を接続すると、WCF トランスポートで好きなことを行うことができます。行は明確なテキストではなく、問題は解決されています。

もちろん、これは言うは易く行うは難しですが、ほとんどのネットワーク ベンダーは非常に簡単な VPN 構成を提供しており、SSL 証明書のインストーラーを開発してクライアントを構成するよりも簡単かもしれません。

それが役立つことを願っています！

于 2012-07-12T12:32:42.300 に答える