Безопасность транспорта для зеркального отображения баз данных и групп доступности AlwaysOn (SQL Server)

Статья
06/25/2013

Защита транспорта в SQL Server 2005 и более поздних версиях подразумевает проверку подлинности и (необязательно) шифрование сообщений, которыми обмениваются базы данных. Для зеркального отображения базы данных и Группы доступности AlwaysOn проверка подлинности и шифрование настраиваются в конечной точке зеркального отображения базы данных. Базовые сведения о конечных точках зеркального отображения базы данных см. в разделе Конечная точка зеркального отображения базы данных (SQL Server).

В этом разделе.

Проверка подлинности
Шифрование данных
Связанные задачи

Проверка подлинности

Проверка подлинности — это процесс проверки того, что пользователь является тем, за кого себя выдает. Подключения между конечными точками зеркального отображения базы данных требуют проверки подлинности. Запросы соединения зеркального или следящего сервера должны проходить проверку подлинности.

Тип проверки подлинности, применяемый экземпляром сервера при зеркальном отображении базы данных или Группы доступности AlwaysOn, является свойством конечной точки зеркального отображения базы данных. Для конечных точек зеркального отображения базы данных доступны два типа защиты передачи данных: Проверка подлинности Windows (интерфейс поставщика службы безопасности, SSPI) и проверка подлинности на основе сертификатов.

Проверка подлинности Windows

При проверке подлинности Windows каждый экземпляр сервера входит в систему на зеркальную сторону, используя учетные данные Windows учетной записи пользователя Windows, под которой выполняется процесс. Проверка подлинности Windows может потребовать небольшой настройки вручную учетных записей следующим образом.

Если экземпляры SQL Server выполняются как службы в одной и той же учетной записи домена, то дополнительная настройка не требуется.
Если экземпляры SQL Server выполняются как службы под разными учетными записями домена (одного и того же или доверенных доменов), то необходимо создать имя входа для каждой учетной записи в master на каждом экземпляре сервера и предоставить ему разрешение CONNECT на конечную точку.
Если экземпляры SQL Server выполняются как учетные записи сетевой службы, имя входа для каждой учетной записи главного компьютера (DomainName**\**ComputerName$) необходимо создать в master на каждом из прочих серверов и предоставить ему разрешение CONNECT на конечную точку. Это обусловлено тем, что экземпляр сервера, выполняемый под учетной записью Network Service, выполняет проверку подлинности с помощью учетной записи домена главного компьютера.

Примечание
Пример установки сеанса для зеркального отображения базы данных с помощью проверки подлинности Windows см. в разделе Пример. Настройка зеркального отображения базы данных с помощью проверки подлинности Windows (язык Transact-SQL).

Пример установки сеанса для зеркального отображения базы данных с помощью проверки подлинности Windows см. в разделе Пример. Настройка зеркального отображения базы данных с помощью проверки подлинности Windows (язык Transact-SQL).

Сертификаты

В некоторых ситуациях, например, когда экземпляры сервера находятся не в доверенных доменах или SQL Server выполняется как локальная служба, проверка подлинности Windows недоступна. В этом случае для проверки подлинности запросов на соединение вместо учетных данных пользователя требуются сертификаты. Зеркальную конечную точку каждого экземпляра сервера необходимо настроить с собственным, локально созданным сертификатом.

Метод шифрования определяется при создании сертификата. Дополнительные сведения см. в разделе Включение использования сертификатов для исходящих соединений в конечной точке зеркального отображения базы данных (Transact-SQL). Соблюдайте осторожность при управлении действующим сертификатом.

Чтобы установить идентичность при соединении, экземпляр сервера использует закрытый ключ собственного идентификатора. Экземпляр сервера, который принимает запрос на соединение, для проверки подлинности отправителя использует открытый ключ идентификатора отправителя. Рассмотрим два экземпляра сервера: сервер_A и сервер_В. Сервер_A перед отправкой запроса на подключение к серверу_В использует закрытый ключ для шифрования заголовка соединения. Сервер_В использует открытый ключ сертификата сервера_A для расшифровки заголовка соединения. Если дешифрованный заголовок верен, сервер_B знает, что он был зашифрован сервером_A, и соединение авторизуется. Если дешифрованный заголовок неверен, сервер_B знает, что запрос на соединение не является достоверным, и отказывает в подключении.

Шифрование данных

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

Примечание
Зеркальные конечные точки, созданные Среда SQL Server Management Studio, или требуют шифрования, или создаются с отключенным шифрованием. Чтобы изменить параметры шифрования на SUPPORTED, используется инструкция ALTER ENDPOINT Transact-SQL. Дополнительные сведения см. в разделе ALTER ENDPOINT (Transact-SQL).

Зеркальные конечные точки, созданные Среда SQL Server Management Studio, или требуют шифрования, или создаются с отключенным шифрованием. Чтобы изменить параметры шифрования на SUPPORTED, используется инструкция ALTER ENDPOINT Transact-SQL. Дополнительные сведения см. в разделе ALTER ENDPOINT (Transact-SQL).

При необходимости пользователь обладает возможностью управлять алгоритмом шифрования, который может быть использован конечной точкой, путем определения одного из следующих значений для параметра ALGORITHM в инструкции CREATE ENDPOINT или в инструкции ALTER ENDPOINT:

RC4

Указывает на то, что конечная точка должна использовать алгоритм RC4. Это режим по умолчанию.

Алгоритм RC4 устарел. В будущей версии Microsoft SQL Server этот компонент будет удален. Не используйте его при работе над новыми приложениями и как можно быстрее измените приложения, в которых он в настоящее время используется. Вместо этого рекомендуется использовать алгоритм AES.

AES

Указывает на то, что конечная точка должна использовать алгоритм AES.

AES RC4

Указывает на то, что две конечных точки будут согласовывать алгоритм шифрования, оставляя приоритет за алгоритмом AES.

RC4 AES

Указывает на то, что две конечных точки будут согласовывать алгоритм шифрования, оставляя приоритет за алгоритмом RC4.

Если подсоединяемые конечные точки указывают оба алгоритма, но в разной последовательности, используется тот алгоритм, который указан принимающей стороной.

Примечание
Алгоритм RC4 поддерживается только в целях обратной совместимости. Когда база данных имеет уровень совместимости 90 или 100, новые материалы могут шифроваться только с помощью алгоритмов RC4 или RC4_128. (Не рекомендуется.) Используйте вместо этого более новые алгоритмы, например AES. В SQL Server 2012 материалы, зашифрованные с помощью алгоритмов RC4 или RC4_128, могут быть расшифрованы на любом уровне совместимости. Алгоритм RC4 является относительно слабым, хотя работает значительно быстрее по сравнению с AES, в то время как AES является довольно надежным алгоритмом. Поэтому рекомендуется использовать алгоритм AES.

Алгоритм RC4 поддерживается только в целях обратной совместимости. Когда база данных имеет уровень совместимости 90 или 100, новые материалы могут шифроваться только с помощью алгоритмов RC4 или RC4_128. (Не рекомендуется.) Используйте вместо этого более новые алгоритмы, например AES. В SQL Server 2012 материалы, зашифрованные с помощью алгоритмов RC4 или RC4_128, могут быть расшифрованы на любом уровне совместимости.

Алгоритм RC4 является относительно слабым, хотя работает значительно быстрее по сравнению с AES, в то время как AES является довольно надежным алгоритмом. Поэтому рекомендуется использовать алгоритм AES.

Дополнительные сведения о синтаксисе Transact-SQL для задания шифрования см. в разделе CREATE ENDPOINT (Transact-SQL).