использование securestring для sql соединения
Я хочу использовать SecureString для содержания строки подключения для базы данных. Но как только я установил свойство ConnectionString объекта SqlConnection на значение securestring, конечно, это станет видимым к какому-либо другому приложению, которое в состоянии считать память моего приложения?
Я сделал следующие предположения:
a) Я не в состоянии инстанцировать объекта SqlConnection за пределами управляемой памяти
b) любая строка в управляемой памяти может быть считана приложением, таким как Айовец
4 ответа
Your absolutely right the SecureString does not provide you with any benefit when you need to pass the string to a managed API, such as setting a ConnectionString.
It's really designed for secure communication with secure non-managed APIs.
Microsoft could theoretically consider enhancing SqlConnection object to support a secure ConnectionString, but I think they're unlikely to do so because:
SecureString is really only useful in a client app, where e.g. a password is built character by character from user input, without ever having the whole password in a managed string.
In such an environment, it's more common to be using Windows authentication for connections to SQL Server.
On a server there are other ways to protect the SQL Server credentials, starting by limiting access to the server to authorized administrators.
2012
Microsoft did enhance SqlConection object to support a secure ConnectionString by passing a SqlCredential to the new SqlConnection.Credential property:
SecureString pwd = AzureVault.GetSecretStringSecure("ProcessPassword");
SqlCredential = new SqlCredential("Richard", pwd)
connection.Credential = cred;
Unfortunately no other DbConnection descendant (e.g., OdbcConnection, OleDbConnection, OracleConnection, EntityConnection, DB2Connection) supports it.
Присвоение значения SecureString для SQLConnection.ConnectionString приведет к обходу защиты, что сделает ее бесполезной.
SecureString предназначен для исправления этих обычных проблем со строками, ref :
- не закреплено, сборщик мусора может перемещать его, оставляя копии в памяти
- незашифрованными
- Если ваш процесс выгружается на диск, строка будет сидеть в вашем файле подкачки
- не изменяемой, ее изменение сохранит старую версию и новую версию как в памяти
- , так и не удастся очистить ее, когда вы закончите использовать it
IMHO тип SecureString - это патч для дрянной реализации безопасности, и в настоящее время SecureString не реализован во всей структуре, поэтому его преимущества нельзя использовать в полной мере.
У меня та же проблема, я выбираю шифрование RSA для хранения конфиденциальной информации в памяти.
Другое решение - размещение уровня доступа к данным через службу на сервере базы данных, и служба работает под локальной системной учетной записью, которая подключается к базе данных и обслуживает данные, в то время как локальный пользователь не будет иметь доступа к конфигурации службы. .
Почему возникает проблема со строкой подключения? Разве пароль не будет тем, что вы хотите защитить (если вы не вводите пароль в строку подключения, которая является необязательной для всех драйверов, которые я видел). При этом пароль обычно в какой-то момент должен быть "в открытом виде" в памяти (если только у драйвера нет некоторого API, который разрешает зашифрованные пароли или что-то в этом роде, но это, вероятно, в любом случае не сильно поможет).
Обычно это не проблема, потому что процесс находится в безопасной среде, например, на веб-сервере, или работает как учетная запись системного администратора (так что обычные пользователи не могут получить доступ к памяти процесса), или обычно и то, и другое. Если это на клиентской машине, работающей в пользовательском пространстве, вы должны предположить, что процесс все равно скомпрометирован, и это не поможет.
Если вас так беспокоит безопасность, я предлагаю вам включить SSL на сервере SQL и взаимодействовать с ним с помощью SSL.