現在、クライアントアプリケーションと単一のWebサービスで構成されるシステムを設計しています。クライアントはいくつかのマシン(私または同僚がインストールしたマシン)に分散されており、クライアントとサーバー間の通信はインターネットを介して行われます。
私が探しているのは、クライアントアプリケーションを最初にインストールした物理マシンからのみWebサービスがリクエストを受信できるようにする方法です。
コンピュータはある種のWindowsを実行するでしょう、私はまだ正確にどのエディションかわかりません。また、WebサービスはWCFベースになります。
私の現在の考えは、マシンにクライアント証明書をインストールし、それをWebサービスでの認証に使用することです。証明書を物理マシンにロックするメカニズムがあるかどうか、または証明書がエクスポートされて別のマシンにインストールされるのを防ぐためにパスワードを保護するメカニズムがあるかどうかはわかりません。
証明書に関する私の知識は非常に基本的です。そのため、これが実行可能なアプローチのように見えるのか、それともより効果的な別の方法があるのかを尋ねています。
編集:私の元の質問は、これをどの程度安全にしたいかについて少し漠然としていたことを理解しています。
クライアントアプリケーションは、それを使用することを余儀なくされたユーザーにとって毎日の煩わしさと見なされるかもしれません。また、アプリケーションのポイントの1つは、特定の時点でこの場所/コンピューターに人がいたことを通知できることです。そのため、リクエストが「私のマシン」からのものではないことをウェブサービスから確認できるようにしたいと考えています。これは、「迷惑なユーザー」が、クライアントアプリコンピューターが配置されている場所にいる必要がないようにするためのスキームを考えないようにするためです。単にアプリケーションをラップトップコンピュータにコピーするなど。
つまり、自分のコンピューターからアプリケーションのインストールを使用する簡単な方法を回避することです。そして、ユーザーの種類はITのバックグラウンドを持つ人ではありません。
これまでに役立つ多くの回答をありがとう
インサイダーの脅威についてどの程度懸念していますか。それがあなたの最大の要因です。攻撃者がハードドライブにアクセスしたり、ハードドライブにアクセスしすぎると、マシンのハードドライブに配置したほとんどすべてのセキュリティメカニズムが解読される可能性があります。これにかかる時間は、ドライブを安全に保護するための要素です。
これを行う方法はたくさん考えられます。
IPフィルタリング(スプーフィング可能)
インストール中にIPSECトンネルをセットアップする
証明書ベースの認証
トークンの疑似ランダムキージェネレーターなどでVPN認証を要求する
適切な脅威があれば、何でもハッキング可能です。
各メカニズムには、攻撃または侵害の方法が異なります。 IPアドレスが偽装されたり、攻撃者がハードドライブに侵入したり、コンピュータのセキュリティデータを悪用したりすると、IP Secトンネルや証明書が侵害される可能性があります。鍵生成トークンは、マシンから分離するのに最適ですが、COTSソフトウェアが必要であり、高価になる可能性があります。
クライアントで認証されたSSLによる証明書認証は、通常、設定するのにそれほど悪くありません。Webサーバーは非常に単純な認証シナリオを実行し、証明書の識別名に基づいて信頼できるクライアントのリストにサーバーを制限できるはずです。ソフトウェア証明書を使用する場合は、クライアントごとに個別の秘密鍵をインストールする必要があります。これは、ある程度の入念なキー管理を意味します。秘密キーをブラウザや他の証明書ストアにアップロードして、秘密キーをエクスポートしないようにルールをOSに設定できます。これの一部は、ユーザーの権限に応じてハッキングまたは変更される可能性があり、インサイダー脅威の問題です。
証明書認証をSSLクライアント認証に制限する場合、より具体的な特権管理要件がない限り、Webサービスのロジックを変更する必要はありません。
まず、必要なのは Webサービスでの適切なセッションID管理 です。
次に、クライアント側の証明書をマシンIDに結び付けるために Cookie Revolver Framework のようなものをお勧めします(例:NICのMACアドレスおよび/またはハードドライブ)と静的IPアドレスですが、これらはおそらく、今日の仮想化ハードウェアを使用して偽造され、非常に簡単に古くなる可能性があります。
私は、クライアント側の証明書がAladdin USB eToken(2048ビットがいいでしょう)のようなものに保存されているものに行きますが、物理的に接着し、そうでなければデバイスをUSBソケットに改ざんするのを防ぎます。それも実際にはうまく機能しません-おそらく、オンボードTPMチップはそうでしょうか? TrouSerS を試してみてください。TPMIDに基づくEAP-TLS認証があるようです。
ここでの最良のアプローチはシッククライアントインストールでクライアント証明書をインストールすることだと私には思えます。別のレイヤーを追加したい場合は、ファイアウォールフィルタリングを使用して、クライアントがアクティブになるとホワイトリストを更新することができます。
エンドユーザーが証明書を抽出することを困難にするいくつかのことを行うことができます。 Windows CryptoAPIとローカル証明書ストアを使用すると、秘密キーのエクスポートが困難になり(不可能ではない場合)、アプリケーションでCSPを利用して要求をWebサービスに渡すことができます。
あなたのプロファイルから、クライアントを.NETで作成したと思いますので、これのほとんどは、手元にあるMSDNリソースで見つけることができます。 (ここから始めましょう: http://msdn.Microsoft.com/en-us/library/ms867080.aspx )
秘密鍵のエクスポートの防止が証明書ストアから回避されたかどうかについては何も見つかりません。それが不可能ではないという意味ではありませんが、それが行われた場合、Google検索で見つけることは困難です。