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