web-dev-qa-db-ja.com

SQL Server2008の証明書

アプリケーションとSQLServer2008間の送信にSSLを実装する必要があります。

私はWindows7、SQL Server 2008、SQL Server Management Studioを使用しており、アプリケーションはc＃で記述されています。

証明書の作成に関するMSDNページと this の下の「特定のクライアントの暗号化」をたどろうとしていましたが、どうしようもなく混乱しました。暗号化を正常に実装するための道をさらに進むには、いくつかの簡単な手順が必要です。

まず、MMCがわかりません。そこにたくさんの証明書があります...これらの証明書は自分の暗号化に使用する必要がありますか、それとも既存のものに使用されていますか？もう1つ、これらの証明書はすべてローカルコンピューターにあるファイルだと思いますが、なぜ「個人」というフォルダーがあるのでしょうか。

次に、上記の問題を回避するために、自己署名アセンブリを使用して少し実験を行いました。上記のMSDNリンクに示されているように、SSMSで実行されたSQLを使用して自己署名証明書を作成しました。次に、次の接続文字列を使用して接続しました。

 Data Source=myServer;Initial Catalog=myDatabase;User ID=myUser;Password=myPassword;Encrypt=True;TrustServerCertificate=True

接続して動作しました。次に、作成したばかりの証明書を削除しましたが、それでも機能しました。明らかにそれは何もしていませんでしたが、なぜですか？それが実際に「機能している」かどうかはどうすればわかりますか？ SSMSからクライアントにファイルを取得する（どういうわけか？）中間ステップが欠落している可能性があると思いますか？

少しでも自分が何をしているのかわからないので、助け、アドバイス、コメント、参考資料をいただければ幸いです。

前もって感謝します。 :)

sql-serversslssl-certificateconnectionencryption
7
Brandi

私がMSDN仕様を正しく理解していれば、必要なのは接続文字列Encrypt=True;TrustServerCertificate=Trueで指定することだけです。これは、クライアントが暗号化を要求し、サーバーが使用する可能性のあるすべての証明書を受け入れる意思があることを意味します。サーバーには、他に何も利用できない場合に使用するために、サーバーの起動時に常に自己署名証明書が生成されます。クライアントがany証明書を受け入れる意思がある場合は、サーバーの一時的な自己署名証明書を受け入れます。これは、他の証明書と同じです。

このような設定が提供するのは、アプリケーションとサーバー間の暗号化された通信チャネルであり、簡単に耳を傾けることができないチャネルです。ただし、チャネルは悪意のある中間者攻撃にさらされています。攻撃者がクライアントをだましてサーバーではなくhimに接続できる場合（たとえば、DNSレコード、より正確にはDNSサーバーIPを制御することによって）クライアントはこれを使用します。これは制御するのに簡単なDHCP設定です）、攻撃者はany証明書を提示でき、クライアントはそれを受け入れます。クライアントとの完全な認証ラウンドトリップ、つまり使用されるSQLユーザー名とパスワードを取得すると、クライアントは実際のサーバーに接続して、すべてのコンテンツを自由に確認しながら、すべての通信をやり取りできます。クライアントは、「監視されている」ことを決して知りません。これは「man-in-the-middle」攻撃です。

上記の状況を防ぐために、クライアント削除する必要があります接続文字列からTrustServerCertificate=True。ただし、これが行われると、サーバーによって使用される証明書はクライアントによって信頼される必要があり、これがすべての問題が発生するときです。暗号化されたトラフィックがある弱い設定で問題がないが、理解している場合は、可能性がありますman-in-the-middle攻撃の対象となり、問題がない場合は、はるかに単純なTrustServerCertificate=True設定を使用します。そうでない場合は、残念ながら、自分が何をしているかを本当に理解する必要があり、些細なことではありません。データがso重要である場合は、おそらくVeriSign、Thawte、またはGlobalSign（これらはすべてのWindowsクライアントによって信頼される3つのルート）の資金を払い出します。サーバーの証明書（〜$ 500 /年）はそれほど風変わりではありません。

5
Remus Rusanu

「個人」は、証明書ストアの誤解を招く名前です。 MMCにいるときに、選択できる証明書が表示されていれば、おそらく問題ありません。実際の証明書を使用することをお勧めします。これは、Microsoft Certificate Serverを使用して社内で作成された証明書、または証明書プロバイダーから購入した証明書の場合があります。自己署名証明書は使用しません。 SQL Serverインスタンスサービスも、有効にするには再起動する必要があります。

いくつかの一般的なヒント：

クライアントに暗号化を適用する場合、クライアント上のすべてのSQL通信はトランスポートレベルの暗号化を使用する必要があります。

サーバーに暗号化を適用する場合、そのインスタンスのすべてのSQL通信はトランスポートレベルの暗号化を使用する必要があります。

選択した構成（選択的または強制的）に関係なく、アプリケーションではさまざまな接続オプションのサポートが必要です。暗号化接続キーワードなど。

個人的には、SQL Native Clientは、組み込みのSQLクライアントよりも説明的なエラーメッセージを提供することがわかりましたが、どちらでも暗号化を使用/適用できます。

Microsoftのドキュメントは少し大雑把ですが、いくつかの優れた記事があります。

SQL Serverへの安全な接続を選択的に使用する
http://blogs.msdn.com/b/sql_protocols/archive/2009/10/19/selectively-using-secure-connection-to-sql-server.aspx

Microsoft管理コンソールを使用してSQL ServerのインスタンスのSSL暗号化を有効にする方法
http://support.Microsoft.com/kb/316898

SQL Server Native Clientでの接続文字列キーワードの使用
http://msdn.Microsoft.com/en-us/library/ms130822.aspx

1
Greg Askew