Я использую 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 — удивлён. С другой стороны, начав что-то переводить, не люблю бросать на полпути. Может быть, кому-то и пригодится.
Частично я был застигнут врасплох, поскольку мой мыслительный процесс был примерно таким: «Конечно, 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 — удивлён. С другой стороны, начав что-то переводить, не люблю бросать на полпути. Может быть, кому-то и пригодится.
