Мне необходимо реализовать 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 на клиенте?
Я совершенно не понимаю, что делаю, поэтому буду очень признателен за любую помощь, советы, комментарии, ссылки.
Заранее спасибо. :)
решение1
Если я правильно понял спецификацию MSDN, то все, что вам нужно, это указать в строке подключения Encrypt=True;TrustServerCertificate=True. Это означает, что клиент запрашивает шифрование иготов принять любой сертификат, который может использовать сервер. Сервер всегда имеет самоподписанный сертификат, сгенерированный во время запуска сервера, для использования, если ничего другого не доступно. Если клиент готов принятьлюбойсертификат, то он примет временный самоподписанный сертификат этого сервера, который так же хорош, как и любой другой.
Такая настройка обеспечивает зашифрованный канал связи между вашим приложением и вашим сервером, канал, который нельзя легко перехватить. Однако этот канал открыт для вредоносной атаки типа «человек посередине». Если злоумышленник сможет обмануть клиента, чтобы подключиться кемувместо сервера (например, имея контроль над записями DNS, точнее над IP-адресом DNS-сервера, который будет использовать клиент, что является тривиальной настройкой DHCP для управления), то злоумышленник может представитьлюбойсертификат, и клиент примет его, затем он может выполнить полную аутентификацию туда и обратно с клиентом, таким образом получив имя пользователя SQL и используемый пароль, затем он может подключиться к настоящему серверу и пересылать туда и обратно все общение, с бесплатным просмотром всего контента. Клиент никогда не узнает, что за ним «следят». Это атака «человек посередине».
Чтобы предотвратить указанную выше ситуацию, клиентнеобходимо удалитьиз TrustServerCertificate=Trueстроки подключения. Однако как только это будет сделано, сертификат, используемый серверомимеетбыть доверенным клиентом, и вот тут-то и возникают все сложности. Если вас устраивают более слабые настройки, на которых у вас зашифрованный трафик, но выпониматьчто тыможетподвергаться атаке типа «человек посередине» и вас это устраивает, то используйте гораздо более простую TrustServerCertificate=Trueнастройку. Если нет, то, к сожалению, вы должны действительно понимать, что вы делаете, и это не тривиально. Если данныетакважно, то, возможно, покупка сертификата VeriSign, Thawte или GlobalSign (эти три корневых сертификата пользуются доверием каждого клиента Windows) для вашего сервера (~500 долларов США в год) не будет такой уж нелепой.
решение2
«Персональный» — это вводящее в заблуждение название хранилища сертификатов. Если вы находитесь в MMC и видите сертификат, который можно выбрать, то, скорее всего, все в порядке. Я рекомендую использовать настоящий сертификат. Это может быть сертификат, созданный внутри компании с помощью Microsoft Certificate Server, или сертификат, приобретенный у поставщика сертификатов. Я бы не стал использовать самоподписанный сертификат. Служба экземпляра SQL Server также должна быть перезапущена, чтобы изменения вступили в силу.
Несколько общих советов:
Если вы принудительно используете шифрование на клиенте, все SQL-соединения на клиенте должны использовать шифрование на транспортном уровне.
Если вы принудительно используете шифрование на сервере, все SQL-соединения для этого экземпляра должны использовать шифрование на транспортном уровне.
Независимо от выбранной конфигурации (выборочной или принудительной) вашему приложению по-прежнему требуется поддержка различных параметров подключения. Например, ключевого слова Encrypt connection.
Я лично обнаружил, что клиент SQL Native выдает более описательные сообщения об ошибках, чем встроенный клиент SQL, но вы можете использовать/принудительно применять шифрование с помощью любого из них.
Документация от Microsoft немного отрывочна, но есть пара хороших статей:
Выборочное использование безопасного соединения с SQL Server
Связь
Как включить SSL-шифрование для экземпляра SQL Server с помощью консоли управления Microsoft
http://support.microsoft.com/kb/316898
Использование ключевых слов строки подключения с собственным клиентом SQL Server
http://msdn.microsoft.com/en-us/library/ms130822.aspx