9

SecureStringを使用して、データベースの接続文字列を保持したいと思います。しかし、SqlConnectionオブジェクトのConnectionStringプロパティをsecurestringの値に設定するとすぐに、アプリケーションのメモリを読み取ることができる他のアプリケーションから確実に表示されるようになりますか？

私は次のことを前提としています。a）
管理対象メモリの外部でSqlConnectionオブジェクトをインスタンス化できないb）管理対象メモリ内の任意の文字列をHawkeye
などのアプリケーションで読み取ることができる

4

5 に答える 5

5

絶対に正しいSecureStringは、ConnectionStringの設定など、管理対象APIに文字列を渡す必要がある場合には何のメリットもありません。

これは、安全な非管理APIとの安全な通信のために実際に設計されています。

Microsoftは、理論的にはSqlConnectionオブジェクトを拡張して、安全なConnectionStringをサポートすることを検討できますが、次の理由により、そうする可能性は低いと思います。

  • SecureStringは、実際にはクライアントアプリでのみ役立ちます。たとえば、パスワードは、管理対象の文字列にパスワード全体を含めることなく、ユーザー入力から1文字ずつ作成されます。

  • このような環境では、SQLServerへの接続にWindows認証を使用するのが一般的です。

  • サーバーでは、サーバーへのアクセスを許可された管理者に制限することから始めて、SQLServerの資格情報を保護する他の方法があります。

2012年

Microsoftは、 SqlCredentialを新しい SqlConnection.Credentialプロパティに渡すことにより、安全なConnectionStringをサポートするようにSqlConectionオブジェクトを拡張しました。

SecureString pwd = AzureVault.GetSecretStringSecure("ProcessPassword");
SqlCredential = new SqlCredential("Richard", pwd)
connection.Credential = cred;

残念ながら、他のDbConnectionの子孫 （OdbcConnection、OleDbConnection、OracleConnection、EntityConnection、DB2Connectionなど）はこれをサポートしていません。

于 2009-12-17T18:19:56.887 に答える
0

SecureString 値を SQLConnection.ConnectionString に割り当てると、セキュリティがバイパスされ、役に立たなくなります。

SecureString は、これらの通常の文字列の問題を修正するためのものです。ref :

  • ピン留めされていないため、ガベージ コレクターはそれを移動でき、コピーをメモリに残すことができます
  • 暗号化されていない
  • プロセスがディスクにスワップアウトされた場合、文字列はスワップ ファイルに残ります。
  • 変更できません。変更すると、古いバージョンと新しいバージョンの両方がメモリに保持されます
  • あなたがそれを使い終わったときにそれをクリアする方法はありません

私見では、SecureString 型は見掛け倒しのセキュリティ実装のパッチであり、現在、SecureString はフレームワーク全体に実装されていないため、その利点を十分に活用することはできません。

私は同じ問題を抱えています。機密情報をメモリに保存するRSA暗号化を選択しています。

もう 1 つの解決策は、データベース サーバー上のサービスを介してデータ アクセス レイヤーをホストすることです。このサービスは、データベースに接続してデータを提供するローカル システム アカウントで実行されますが、ローカル ユーザーはサービス構成にアクセスできません。

于 2010-04-07T10:19:23.730 に答える
-2

セキュリティが心配な場合は、SQL サーバーで SSL を有効にし、SSL を使用して通信することをお勧めします。

于 2009-12-17T15:08:29.560 に答える