Мне нужно реализовать SSL для передачи между моим приложением и Sql Server 2008.
Я использую Windows 7, Sql Server 2008, Sql Server Management Studio, и мое приложение написано на C #.
Я пытался следить за страницей MSDN по созданию сертификатов и этот в разделе «Encrpyt для конкретного клиента», но я безнадежно запутался. Мне нужны маленькие шаги, чтобы продвинуться дальше по пути к успешной реализации шифрования.
Во-первых, я не понимаю MMC. Я вижу там много сертификатов ... эти сертификаты я должен использовать для собственного шифрования или они используются для вещей, которые уже существуют? Другое дело, я предполагаю, что все эти сертификаты представляют собой файлы, расположенные на моем локальном компьютере, так почему там папка с именем «Личные»?
Во-вторых, чтобы избежать описанной выше проблемы, я провел небольшой эксперимент с самоподписанной сборкой. Как показано в ссылке MSDN выше, я использовал SQL, выполняемый в SSMS, для создания самозаверяющего сертификата. Затем я использовал следующую строку подключения для подключения:
Data Source=myServer;Initial Catalog=myDatabase;User ID=myUser;Password=myPassword;Encrypt=True;TrustServerCertificate=True
Подключил, заработал. Затем я удалил только что созданный сертификат, но он все еще работал. Очевидно, он никогда ничего не делал, но почему бы и нет? Как мне узнать, действительно ли он «работает»? Я думаю, что мне может не хватать промежуточного шага (каким-то образом?) Для передачи файла из SSMS на клиент?
Я ни в малейшей степени не знаю, что делаю, поэтому я очень благодарен за любую помощь, советы, комментарии, ссылки, которые вы можете мне дать.
Заранее спасибо. :)
Если я правильно понимаю спецификацию MSDN, все, что вам нужно, это указать в строке подключения Encrypt=True;TrustServerCertificate=True. Это означает, что клиент запрашивает шифрование и готов принять любой сертификат, который может использовать сервер. На сервере всегда есть самозаверяющий сертификат, сгенерированный при запуске сервера, который можно использовать, если больше ничего не доступно. Если клиент готов принять любой сертификат, то он примет временный самозаверяющий сертификат этого сервера, так же хорош, как и любой другой.
Такая установка обеспечивает зашифрованный канал связи между вашим приложением и вашим сервером, канал, который нельзя просто пропустить. Однако канал открыт для злонамеренной атаки типа "злоумышленник посередине". Если злоумышленник может обмануть клиента для подключения к ему вместо сервера (например, имея контроль над записями DNS, точнее IP-адресом DNS-сервера, который будет использовать клиент, что является тривиальной настройкой DHCP для управления), злоумышленник может представить любой сертификат, и клиент примет его, затем он может выполнить полную аутентификацию с клиентом, получая таким образом имя пользователя и пароль SQL, затем он может подключиться к истинному серверу и пересылать туда и обратно все сообщения с помощью бесплатно смотреть весь контент. Клиент никогда не узнает, что за ним «наблюдают». Это атака «человек посередине».
Чтобы предотвратить описанную выше ситуацию, клиент должен удалить в TrustServerCertificate=True из строки подключения. Как только это будет сделано, сертификат, используемый сервером имеет чтобы клиент доверял, и тогда возникают все сложности. Если вас устраивает более слабая настройка, при которой у вас есть зашифрованный трафик, но вы понять что ты может подвергнуться атаке "злоумышленник посередине", и вас это устраивает, тогда используйте гораздо более простой TrustServerCertificate=True настройка. Если нет, то, к сожалению, вы должны действительно понимать, что делаете, а это нетривиально. Если данные так важно, то, возможно, тратить деньги на сертификат VeriSign, Thawte или GlobalSign (это 3 корневых сертификата, которым доверяет каждый клиент Windows) для вашего сервера (~ 500 долларов в год), не так уж и нелепо.
«Личный» - это неверное название хранилища сертификатов. Когда вы находитесь в MMC, если вы видите сертификат, который можно выбрать, вы, вероятно, в порядке. Рекомендую использовать настоящий сертификат. Это может быть сертификат, созданный внутри компании с использованием сервера сертификатов Microsoft, или сертификат, приобретенный у поставщика сертификатов. Я бы не стал использовать самозаверяющий сертификат. Чтобы она вступила в силу, также необходимо перезапустить службу экземпляра SQL Server.
Несколько общих советов:
Если вы применяете шифрование на клиенте, все коммуникации SQL на клиенте должны использовать шифрование транспортного уровня.
Если вы применяете шифрование на сервере, все коммуникации SQL для этого экземпляра должны использовать шифрование транспортного уровня.
Независимо от выбранной вами конфигурации (выборочной или принудительной) вашему приложению по-прежнему требуется поддержка различных вариантов подключения. Например, ключевое слово Encrypt connection.
Я лично обнаружил, что собственный клиент SQL предоставляет более подробные сообщения об ошибках, чем встроенный клиент SQL, но вы можете использовать / принудительно использовать шифрование с любым из них.
Документация от Microsoft немного отрывочна, но есть пара хороших статей:
Выборочное использование безопасного подключения к SQL Server
http://blogs.msdn.com/b/sql_protocols/archive/2009/10/19/selectively-using-secure-connection-to-sql-server.aspx
Как включить шифрование SSL для экземпляра SQL Server с помощью консоли управления Microsoft
http://support.microsoft.com/kb/316898
Использование ключевых слов строки подключения с собственным клиентом SQL Server
http://msdn.microsoft.com/en-us/library/ms130822.aspx