Мы - центр обработки данных, который использует среду SQL Server 2000, которая предоставляет услуги базы данных для продукта, который мы продаем, который загружается как многофункциональное клиентское приложение на каждого из наших многочисленных клиентов и на их рабочие станции.
В настоящее время приложение использует прямые ODBC-соединения от клиентского сайта к нашему центру обработки данных.
Нам нужно начать шифрование учетных данных - поскольку сегодня все является открытым текстом, а аутентификация слабо зашифрована, - и я пытаюсь определить лучший способ реализовать SSL на сервере с минимизацией воздействия клиента.
Однако кое-что:
1) У нас есть собственный домен Windows, и все наши серверы присоединены к нашему частному домену. Наши клиенты не имеют ничего из нашего домена.
2) Как правило, наши клиенты подключаются к серверам нашего центра обработки данных: а) используя адрес TCP / IP; б) используя DNS-имя, которое мы публикуем через Интернет, передачу зон с наших DNS-серверов нашим клиентам или клиент может добавлять статические HOSTS. записи.
3) Из того, что я понял из включения шифрования, я могу перейти в Сетевую утилиту и выбрать опцию «шифрование» для протокола, который я хочу зашифровать. Такие как TCP / IP.
4) Когда выбран вариант шифрования, у меня есть выбор: установить сторонний сертификат или самозаверяющий. Я протестировал самоподписанный, но у меня есть потенциальные проблемы. Я немного объясню. Если я использую сторонний сертификат, такой как Verisign, или сетевые решения ... какой сертификат я запрашиваю? Это не сертификаты IIS? Когда я создаю самоподписанный через сервер сертификатов Microsoft, мне нужно выбрать «Сертификат аутентификации». На что это влияет в стороннем мире?
5) Если я создаю самозаверяющий сертификат, я понимаю, что имя «проблема для» должно совпадать с полным доменным именем сервера, на котором выполняется SQL. В моем случае я должен использовать свое частное доменное имя. Если я использую это, что это делает для моих клиентов при попытке подключиться к моему SQL Server? Конечно, они не могут разрешить мои частные DNS-имена в своей сети ....
Я также проверил, что при установке самозаверяющего сертификата он должен находиться в локальном личном хранилище для учетной записи пользователя, на которой работает SQL Server. SQL Server запустится только в том случае, если полное доменное имя соответствует «выдаче» сертификата и SQL выполняется под учетной записью, в которой установлен сертификат.
Если я использую самозаверяющий сертификат, означает ли это, что мне нужно, чтобы каждый из моих клиентов устанавливал его для проверки?
6) Если я использовал сторонний сертификат, что звучит как лучший вариант, все ли мои клиенты должны иметь доступ в Интернет при доступе к моим частным серверам их частного WAN-соединения, чтобы использовать их для проверки сертификата?
Что мне делать с полным доменным именем? Похоже, они должны использовать мое частное доменное имя, которое не опубликовано, и больше не могут использовать то, которое я установил для них?
7) Я планирую в ближайшее время перейти на SQL 2000. Является ли настройка SSL проще / лучше с SQL 2005, чем с SQL 2000?
Любая помощь или руководство будут оценены
Честно говоря, лучше всего перестать обращаться непосредственно к серверу базы данных. Это по своей сути слабое решение (с точки зрения безопасности), так как любой может попробовать войти в ваш SQL Server, используя учетную запись sa.
Лучшим решением было бы настроить веб-службу на веб-сервере и заставить ваше приложение отправлять запросы через HTTPS к этой веб-службе, а затем заставить веб-службу перенаправлять запросы в базу данных, при этом база данных отключена (или защищена брандмауэром) от общедоступный Интернет.
Это также дает вам возможность без проблем переключать базу данных, поскольку веб-серверы просто общаются с базой данных. Также вы можете балансировать нагрузку на веб-уровне, чтобы по мере роста вы могли распределять нагрузку на соединение между веб-серверами.