Защита соединений баз данных с помощью Securestring .net framework 4.5’s
Авторы: Don Kiely
Перевод: Гриневич И.Е.
Источник: http://www.devproconnections.com/article/net-framework-402/protect-database-connections-net-framework-45s-securestring-142810
Аннотация
В статье рассмотрено предложение более высокого уровня
безопасности с SqlCredential и SqlConnection-объектов в .NET Framework 4.5.
Ключевые
слова: Database
Connections, SecureString, .NET Framework 4.5, SqlConnetion.
Текст статьи
Одной из проблем при подключении базы данных с помощью
строки является частая необходимость предоставления учетных данных для входа в
базу данных, чтобы установить соединение. Вам приходится брать на себя
ответственность за хранение сохранности и безопасности, но ввод этих учетных
данных в строку соединения делает их потенциально небезопасными, поскольку они
хранятся в памяти ещё некоторое время и могут быть обнаружены. Этой проблемы
можно избежать с помощью встроенной проверки
подлинности Windows (IWA). Microsoft настоятельно рекомендует
использоватьIWA, когда вы можете, но это не всегда возможно для некоторых
сценариев, в которых приложение обращается к базе данных за
пределами домена.
Другая
проблема заключается в том, что типичные .NET-строки не являются
безопасными. Строки являются неизменными после их создания,
и после окончания работы с ними вы не можете направить туда сборщик
мусора. Это ограничение означает, что строка подвержена риску
заражения при сканировании памяти и других атаках, в том
числе при чтении открытым текстом из файла
подкачки и дампе памяти.
Эти
проблемы решаются при помощь объектов SecureString, которые
первоначально присутствуют в. NET Framework 2.0. Текстовое
значение SecureString автоматическишифруется с помощью Data
Protection API (DPAPI). Вы можете менять значениеSecureString до
тех пор, пока вы не смените права доступа на Read-Only при помощи метода
MakeReadOnly. Кроме того, можно сразу удалить строку из памяти,
когда приложение завершается строкой или при регулярной оработке
сборщиком мусора. Для еще
большей защиты, SecureString закреплена в памяти,
так что она не может быть перемещена или скопирована. Кроме того, вы
не можете напрямую задать значение SecureString в строку, потому
что для этого потребуется пароль или другая конфиденциальная
информация для существования в памяти. Вместо этого, вы должны
устанавливать значения защищенной строки по одному
символу за один раз, так как нет других надежных средств,
чтобы установить значение. Хотя эта особенность
делает SecureString неудобной для сипользования, она же
делает ваши строки более безопасными.
SecureString может
пойти длинным путём в направлении защиты учетных данных для
входа в памяти, но так не было бы способа
использовать SecureStrings со строками подключения. Эта
ситуация изменится с помощью .NET Framework 4.5, который
представляет объект SqlCredential и
добавляет поддержку SqlConnection-объектов для
безопасности полномочий. SqlCredential работает,
позволяя предоставить учетные данные для подключения отдельно
от информации о подключении. Например, можно
установить текстовое значение SecureString с паролем и
инициализировать SqlCredential-объект, используя те же SecureString.
Затем возможно установление учетных свойств на
новый объект SqlConnection к SqlCredential-объектам
и подключение к базе данных.
Код на
рисунке 1 показывает, как SecureString может работать со
строками подключения в. NET Framework 4.5. Представьте,
что вы предлагаете пользователю ввести имя пользователя
и пароль. Вы можете использовать свойство SecurePassword из
класса PasswordBox для безопасного создания SecureString,
изменить права доступа строки на Read-Only, а также использовать строки
для создания объекта SqlConnection. Вы можете
передавать учетные данные в качестве второго аргумента в
новый конструктор для объекта SqlConnection или
использовать свое свойство в качестве учетных
данных в коде показано на рисунке 1. Microsoft также
рекомендует установление свойства PersistSecurityInfo в False, в
строке соединения, так что данные не доступны как
часть соединения. Обратите внимание, что свойство
PersistSecurityInfo по умолчанию имеет значение False.
Рисунок 1 -
Использование учетных свойство объекта SqlConnection
Одной из
проблем, с которыми вы можете столкнуться, состоит в том,
что различные учетные данные, используемые при
неизменной строке соединения будут использовать различные пулы
соединения. Тем не менее, связи, которые используют ту же строку
связи с теми же учетными данным, будут использовать тот же пул
соединений. Эта ситуация не очень отличается от нынешнего положения
вещей, потому что, если вы предоставите другое имя пользователя или
пароль в строке соединения, ADO.NET не разделит соединение
на пулы соединений. Разница
лишь в том, что всясхема теперь понимает отдельные полномочия.
В
целом, SecureStrings в. NET Framework 4,5 будет
великолепной новой функцией, которая позволит
сделать приложения, которые подключаются к базе даннях, более
безопасным. И эта функция является ещё одной причиной, почему с
нетерпением ждут выпуска .NET Framework 4.5.