Мы создаем облачное приложение, основанное на базе данных входа в систему, а также на множестве отдельных клиентских баз данных. Используя rackspace, мы настроили сервер (Windows Server 2012) с SQL Management Studio 2012 (Web) и находимся в процедурах тестирования / обеспечения качества перед запуском.
Используя средство просмотра событий серверов для поиска некоторой отладочной информации, я заметил, что несколько IP-адресов пытались установить соединение с нашей базой данных SQL каждую минуту или около того. Мы используем пользователя sa по умолчанию в качестве суперпользователя.
Мои вопросы:
Можем ли мы установить максимальное количество запросов для каждого отдельного IP-адреса, прежде чем на него каким-то образом будет наложен «бан»?
Будет ли полезно изменить имя учетной записи пользователя на что-то довольно случайное?
Можем ли мы предпринять какие-либо другие шаги для защиты нашей базы данных?
Вам следует действительно отключите SQL Server от Интернета и используйте брандмауэр, чтобы внешний доступ был запрещен. Затем используйте VPN для каждого клиентского сайта. Да, это не самая простая установка, но это единственный способ заблокировать попытки случайного подключения в любое время дня. Кроме того, скорость «атак» увеличивается по мере того, как все больше зондов обнаруживают, что ваш экземпляр SQL открыт для внешнего мира.
На реализацию того, что делается, необходимо смотреть с точки зрения безопасности. Кроме того, это доступ к самому SQL Server; SSMS просто говорит с ним на языке SQL, чтобы вы могли им управлять.
Прежде всего, вы не должны использовать SA, как указывали другие.
Во-вторых, этот сервер не должен быть доступен в Интернете по причинам, которые вы видели. Что сказал Натан С. настроить VPN.
Наконец, если вы специально не настроили SQL с сертификатом, трафик по умолчанию не зашифрован и подлежит анализу. (Не имя пользователя / пароль, а ваши фактические данные.)
Серьезно, это почти наверняка нарушение PCI. Пожалуйста, отключите брандмауэр.
Как уже упоминалось другими, ваша структура безопасности совершенно неверна ... При этом здесь приведены некоторые передовые методы, на которые следует обратить внимание ... также см. Ссылку на полную статью ниже. Я предлагаю с нуля переосмыслить вашу структуру и подход к безопасности.
http://www.serverwatch.com/tutorials/article.php/3554051/Lock-Down-IIS-and-SQL-Server.htm
Контрольный список базовой безопасности SQL Server
Установите пароль для своей учетной записи SA и ограничьте его использование. Кроме того, периодически меняйте пароль, чтобы он не «распространялся» и не использовался разработчиками или слишком большим количеством администраторов. Измените пароль SA, если кто-то, кто знает его, уйдет из компании. Используйте инструмент eEye для сканирования вашей сети на наличие серверов SQL без пароля SA.
Разместите свой SQL Server за брандмауэром, отдельно от IIS или веб-серверов. Разрешать подключения к серверу SQL только с указанных веб-серверов. Ваш SQL-сервер никогда не должен выходить в Интернет или быть общедоступным.
Удалите BUILTIN / Administrators из роли sysadmin и предоставьте права sysadmin в SQL конкретным учетным записям домена, которые в этом нуждаются.
По возможности используйте проверку подлинности Windows и режим только Windows. Таким образом, потенциальный хакер должен сначала пройти аутентификацию в домене, а не только в SQL Server.
Не запускайте SQL Server на контроллере домена.
Измените стартовую учетную запись службы SQL Server на другую, отличную от LocalHost.
Включите параметр «Неудачный вход» («Свойства сервера» | вкладка «Безопасность»), чтобы вы могли искать неудачные попытки входа в систему, чтобы узнать, пытается ли неавторизованный доступ получить доступ к серверу. Следите за журналами SQL и настройте предупреждения в SQL, используя NETSEND или электронную почту, если это возможно.
Следите за обновлениями и пакетами обновлений для операционной системы и SQL. См. Некоторые параметры в разделе Инструменты для защиты IIS.
Защитите любые расширенные хранимые процедуры. Контролируйте весь доступ к данным с помощью хранимых процедур и предоставляйте доступ к ним вместо предоставления общих разрешений db_datareader и db_datawriter для самих данных. См. Часть I этой статьи для получения дополнительной информации.
Измените стандартный порт SQL Server в служебной программе настройки сети сервера и заблокируйте порт по умолчанию 1433. Вместо этого попросите администратора сети разрешить новый порт.
Убедитесь, что у группы «Все» нет доступа на запись в разделы реестра SQL Server.
Я бы заблокировал TCP-порт 1433 (порт, используемый SQL Management Studio) в брандмауэре для внешних IP-адресов и разрешил бы только localhost или набор доверенных IP-адресов.