Безопасен ли SQL Server?

Источник: habrahabr

Я использую SQL Server с тех самых пор, как выучил, каким образом работают базы данных. Перенос БД Access в MS SQL стал моим первым большим проектом в EnGraph. За эти годы я выучил не так много и был застигнут врасплох вопросом клиента - безопасен SQL Server или же нет. Конкретно же клиенты интересовались нашим продуктом ParaPlan Cloud, который мы разместили, воспользовавшись Amazon EC2, и были обеспокоены открытием порта 1433.

Частично я был застигнут врасплох, поскольку мой мыслительный процесс был примерно таким: "Конечно, SQL Server безопасен! Как глупо об этом спрашивать!" Но проработав с SQL Server более десятка лет, я не смог удовлетворительно ответить на их вопрос. Мы построили целую компанию на использовании этого продукта и поэтому, возможно, должны понимать, как работает его безопасность. Поэтому я ответил им, что проделаю дополнительные исследования и вернусь с результатами.

Вот что я нашёл после нескольких часов исследований:

Транзакции передачи логина/пароля всегда зашифрованы (MSDN):

Учетные данные (в пакете входа), передаваемые при соединении клиентского приложения с SQL Server, всегда зашифрованы. SQL Server будет использовать сертификат доверенного корневого центра сертификации, если он есть. Если доверенный сертификат не установлен, то SQL Server сформирует самозаверяющий сертификат при запуске экземпляра и будет шифровать учетные данные с его помощью.

(Далее добавлено мной - прим. переводчика)
Такой самозаверяющий сертификат повышает безопасность, но не обеспечивает защиту от имитации удостоверения сервером. Если используется самозаверяющий сертификат, а параметр ForceEncryption имеет значение Yes, то с помощью такого самозаверяющего сертификата будут зашифрованы все данные, переданные по сети между SQL Server и клиентским приложением.

Можно выполнить дополнительное шифрование базы данных/таблиц/столбцов, но за счёт производительности (Pinal Dave):

Шифрование является очень важной особенностью в области безопасности SQL Server 2005. Длинные и ассиметричные ключи создают неприступное, надёжное шифрование, которое, в свою очередь, сильно нагружает процессор для шифрования данных. Чем надёжнее шифрование, тем медленнее процесс. При необходимости шифрования большого количества данных предполагается использование симметричного ключа. Этот же симметричный ключ сам может быть зашифрован асимметричным ключом с целью обеспечения дополнительной защиты, что приведёт к использованию преимуществ более надёжного шифрования. Перед шифрованием также рекомендуется сжать данные, поскольку зашифрованные данные сжаты быть не могут.

Если вы хотите и далее контролировать доступ к SQL, вы можете блокировать весь исходящий трафик порта 1433, ограничив доступ к нему указанным серверам. Вот так это может быть сделано с помощью Cisco.

Теперь я куда больше знаю о безопасности SQL Server и чувствую себя более уверенно, предложив клиентам эту информацию. Она поможет им решить - продолжать ли работать с продуктом, размещённом в нашем хранилище или же с продуктом, размещённом у EnGraph.

Послесловие переводчика
Не моё дело давать оценку, но как такого уровня заметки попадают в рассылку Code Project - удивлён. С другой стороны, начав что-то переводить, не люблю бросать на полпути. Может быть, кому-то и пригодится.

Centura/Gupta Roadmap - Product Plan.

Как выполнять аудит производительности SQL Server.

Как отслеживать работу приложений и их составных частей в Oracle.

Автоматизация настройки запросов в версии Oracle 10g: некоторые дополнительные возможности.

Не самые известные сведения о внешних ключах.

Главная » Sql