использование securestring для подключения к SQL

Question

Я хочу использовать SecureString для хранения строки подключения к базе данных. Но как только я установлю свойство ConnectionString объекта SqlConnection в значение securestring, оно обязательно станет видимым для любого другого приложения, способного считывать память моего приложения?

Я сделал следующие предположения:
а) Я не могу создать экземпляр объекта SqlConnection вне управляемой памяти
b) любая строка в управляемой памяти может быть прочитана таким приложением, как Соколиный глаз

Answer 1

Да, вы можете, и да, вы должны использовать SecureString, чтобы пароль не оставался в памяти и не подвергался атакам. Вместо использования строки подключения sql вам нужно использовать новый класс SqlCredential, свойство Password которого является SecureString. Пожалуйста, обратитесь к следующим статьям за помощью.

https://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcredential.password(v=vs.110).aspx

http://www.codeproject.com/Tips/408901/Storing-your-connection-string-password-in-SecureS

Answer 2

Вы абсолютно правы, SecureString не дает вам никаких преимуществ, когда вам нужно передать строку в управляемый API, например, установить ConnectionString.

Это действительно разработано для безопасной связи с безопасными неуправляемыми API.

Microsoft теоретически может рассмотреть возможность расширения объекта SqlConnection для поддержки безопасной ConnectionString, но я думаю, что они вряд ли сделают это, потому что:

• SecureString действительно полезна только в клиентском приложении, где, например, пароль строится посимвольно из пользовательского ввода, при этом весь пароль не находится в управляемой строке.

• В такой среде чаще используется проверка подлинности Windows для подключений к SQL Server.

• На сервере существуют другие способы защиты учетных данных SQL Server, начиная с ограничения доступа к серверу авторизованным администраторам.

---

2012

Microsoft сделал улучшение SqlConection объект для поддержки безопасного ConnectionString путем передачи SqlCredential до нового SqlConnection.Credential свойство:

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

К сожалению, нет других DbConnection потомок (например, OdbcConnection, OleDbConnection, OracleConnection, EntityConnection, DB2Connection) поддерживает это.

Answer 3

Присвоение значения SecureString для SQLConnection.ConnectionString обойдет защиту, сделав ее бесполезной.

SecureString предназначена для исправления этих обычных проблем с строками, ref :

• не закреплено, сборщик мусора может перемещать его, оставляя копии в памяти
• не зашифровано
• Если ваш процесс выгружается на диск, строка будет находиться в вашем файле подкачки
• не изменяемый, его изменение сохранит старую и новую версии в памяти
• нет способа очистить его, когда вы закончите с его использованием

ИМХО тип SecureString - это патч для некачественной реализации безопасности, и в настоящее время SecureString не был реализован во всей среде, поэтому его преимущества нельзя использовать полностью.

У меня та же проблема, я выбираю шифрование RSA для хранения конфиденциальной информации в памяти.

Другим решением является размещение слоя доступа к данным через службу на сервере базы данных, и служба работает под учетной записью локальной системы, которая подключается к базе данных и обслуживает данные, в то время как локальный пользователь не будет иметь доступа к конфигурации службы .

Answer 4

Почему проблема в строке подключения? Не будет ли пароль тем, что вы хотите защитить (если вы не введете пароль в строку подключения, которая является необязательной для всех драйверов, которые я видел). При этом пароль в какой-то момент обычно должен находиться «в открытом виде» в памяти (если только у драйвера нет некоторого API, который разрешает зашифрованные пароли или что-то в этом роде, но, вероятно, в любом случае это не очень поможет).

Обычно это не проблема, поскольку процесс находится в защищенной среде, например на веб-сервере, или работает как учетная запись типа системного администратора (поэтому обычные пользователи не могут получить доступ к памяти процесса), или, как правило, и то, и другое. Если это на клиентском компьютере, работающем в пользовательском пространстве, вы должны предположить, что процесс в любом случае скомпрометирован, и это не поможет. Как только вы закрепите процесс, вам не придется беспокоиться о таких вещах.

Answer 5

Если вас беспокоит безопасность, я предлагаю вам включить SSL на SQL-сервере и взаимодействовать с ним с помощью SSL.