Оптимальные методы использования собственных веб-служб с поддержкой XML

Статья
12/15/2008

В этом разделе представлены оптимальные методы работы, которые следует рассмотреть при планировании или оценке использования собственных веб-служб SQL Server 2005 с поддержкой XML в своих деловых решениях. Эти рекомендации должны помочь следующим образом.

Защитить установку SQL Server при использовании собственных веб-служб с поддержкой XML в SQL Server 2005.
Улучшить производительность установки SQL Server, предлагая правила работы с веб-службами. Эти правила помогут решить, эффективно ли обслуживается приложение собственными веб-службами SQL Server 2005 с поддержкой XML.

Оптимальные методы обеспечения безопасности

Примите во внимание следующие рекомендуемые практики при развертывании собственных веб-служб с поддержкой XML в SQL Server 2005.

Используйте проверку подлинности Kerberos.
Разрешите соединения с конечной точкой только отдельным пользователям или группам.
Используйте протокол SSL (Secure Socket Layer) для обмена конфиденциальными данными.
Защищайте SQL Server брандмауэром.
Убедитесь, что на сервере отключена гостевая учетная запись Windows.
По мере необходимости контролируйте и обновляйте состояние конечной точки.
По мере возможности используйте безопасные настройки по умолчанию для конечных точек.

Использование проверки подлинности Kerberos

Во время выполнения инструкции CREATE ENDPOINT для создания конечных точек выберите или AUTHENTICATION=KERBEROS, или AUTHENTICATION=INTEGRATED, чтобы в качестве метода проверки подлинности на этой конечной точке использовалась встроенная безопасность Windows под управлением Kerberos. В первом случае единственным методом проверки подлинности на конечной точке будет Kerberos. Во втором случае конечная точка будет поддерживать методы проверки подлинности и NTLM, и Kerberos.

Для проверки подлинности протокол Kerberos предоставляет усиленную защиту, используя такие встроенные функции, как взаимная проверка подлинности. Это значит, что проверяется подлинность и клиентов, и серверов.

При использовании проверки подлинности Kerberos SQL Server должен связать имя участника-службы (SPN) с учетной записью, от имени которой он будет запущен. Дополнительные сведения см. в разделе Регистрация имен участников службы Kerberos в файле Http.sys.

Разрешение соединения с конечной точкой только отдельным пользователям или группам

После создания необходимых для развертывания конечных точек защитите их, определив разрешения на подключение к ним с помощью инструкций Transact-SQL, таких как GRANT CONNECT и ALTER ON ENDPOINT. При назначении разрешений на соединение предоставляйте разрешение только конкретным пользователям или группам, которым доступ к конечной точке SQL Server необходим.

В общем случае разрешения на соединение с конечными точками должны получать только отдельные пользователи. Не рекомендуется предоставлять доступ роли public. Вместо этого следует полностью ознакомиться с моделью разрешений SQL Server. Эту модель можно применять для разумного контроля доступа к конечным точкам.

Важно!
Роль public — специальная роль базы данных, к которой принадлежат все пользователи SQL Server. Эта роль содержит разрешения по умолчанию для всех пользователей, имеющих доступ к базе данных. Так как эта роль базы данных является встроенной в SQL Server и служит для предоставления доступа всем пользователям (аналог разрешений Windows «Все» и «Прошедшие проверку»), необходимо соблюдать осторожность при ее использовании в настройке разрешений SQL Server.

Роль public — специальная роль базы данных, к которой принадлежат все пользователи SQL Server. Эта роль содержит разрешения по умолчанию для всех пользователей, имеющих доступ к базе данных. Так как эта роль базы данных является встроенной в SQL Server и служит для предоставления доступа всем пользователям (аналог разрешений Windows «Все» и «Прошедшие проверку»), необходимо соблюдать осторожность при ее использовании в настройке разрешений SQL Server.

Дополнительные сведения см. в разделе GRANT, предоставление разрешений на конечные точки (Transact-SQL).

Использование протокола SSL (Secure Socket Layer) для обмена конфиденциальными данными

Протокол SSL (Secure Socket Layer) предоставляет поддержку шифрования и расшифровки данных, передаваемых через интерфейс сокетов TCP/IP (сочетания IP-адресов и номеров портов TCP). Чтобы использовать шифрование SSL для конечных точек SQL Server, нужно сначала настроить сертификат.

При регистрации сертификата для порта SSL по умолчанию (443) помните, что этот же сертификат может также использоваться другими приложениями. Например, службы IIS могут передавать SSL-трафик через этот же порт; в этом случае конфигурация может повлиять на пользователей служб IIS. Такое общее использование порта SSL и его сертификатов может привести к нарушениям безопасности.

Дополнительные сведения см. в разделе Настройка сертификата для использования протоколом SSL.

Защита SQL Server брандмауэром

Для наибольшего усиления безопасности следует использовать собственные веб-службы с поддержкой XML в SQL Server 2005 только за брандмауэром. Убедитесь, что все заданные при настройке конечных точек номера портов TCP, предоставляющие доступ через HTTP, защищены брандмауэром. Сетевая конфигурация, разрешающая веб-клиентам открытый доступ к установке SQL Server, не защищенной брандмауэром, не рекомендуется. Дополнительные сведения см. в разделе Анализ безопасности при установке SQL Server.

Убедитесь, что на сервере отключена гостевая учетная запись Windows

Гостевая учетная запись — это встроенная учетная запись, существующая во многих версиях Microsoft Windows. В она отключена по умолчанию. В и она по умолчанию включена.

Чтобы снизить риск поверхностных атак при использовании конечных точек, убедитесь, что на сервере, где запущен SQL Server, отключена гостевая учетная запись. Дополнительные сведения см. в подразделе «Выключение и включение учетной записи локального пользователя» справки Windows.

По мере необходимости контролируйте и обновляйте состояние конечной точки

При создании конечной точки с помощью инструкции CREATE ENDPOINT ее состоянием по умолчанию будет STOPPED, если только состояние не задано явно параметром STATE = STARTED. Чтобы контролировать состояние существующей конечной точки, используйте инструкцию ALTER ENDPOINT и укажите состояние STOPPED, STARTED или DISABLED.

Например, с помощью следующих инструкций можно запускать или останавливать ранее созданную конечную точку sql_endpoint.

ALTER ENDPOINT sql_endpoint STATE=STARTED

ALTER ENDPOINT sql_endpoint STATE=STOPPED

Следует также отключать конечные точки и удалять отдельные веб-методы конечных точек или сами точки, если их использование более не планируется.

В следующем примере показано отключение конечной точки:

ALTER ENDPOINT sql_endpoint STATE=DISABLED

Примечание.
После отключения конечная точка не может быть перезапущена до перезапуска службы SQL Server (MSSQLServer).

Чтобы удалить веб-метод конечной точки, используйте инструкцию, аналогичную следующей:

ALTER ENDPOINT sql_endpoint

FOR SOAP

(

DROP WEBMETHOD 'SayHello'

)

Чтобы удалить конечную точку, используйте инструкцию DROP ENDPOINT.

По мере возможности используйте безопасные настройки по умолчанию для конечных точек

При создании или изменении конечной точки с помощью инструкций CREATE ENDPOINT и ALTER ENDPOINT применяются следующие значения по умолчанию, если иное не указано явно.

BATCHES = DISABLED
Transact-SQL Режим batch для конечной точки отключен.
LOGIN_TYPE = WINDOWS
Для пользователей конечной точки разрешена только проверка подлинности Windows.

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

Подробные сведения о выборе алгоритма шифрования см. в разделе Выбор алгоритма шифрования.

Оптимальные методы сохранения производительности

Развертывайте подходящие сценарии.
Учитывайте необходимость дополнительных ресурсов при планировании решений с использованием SOAP.
Используйте подходящие параметры WSDL.

Развертывание подходящих сценариев

Собственные веб-службы с поддержкой XML в SQL Server 2005 лучше всего подходят для сценариев со следующими требованиями.

Приложение возвращает или получает XML-данные.
Бизнес-логика приложения во многом зависит от хранимых процедур.
Для достижения целей архитектуры SOA (Service Oriented Architecture) нужно интегрировать приложение веб-службы, размещенной на SQL Server, с другими приложениями веб-служб, как часть делового решения.
Нужна более производительная замена решению SQLXML среднего уровня для развертывания нескольких веб-служб на одном сервере.
Нужно создавать и публиковать статические отчеты на веб-узле интрасети, где обширный набор функциональных возможностей и дополнительные издержки SQL Server 2005 Reporting Services (SSRS) могут превысить указанные требования.

Аналогичным образом в сценариях со следующими требованиями не рекомендуется использовать собственные веб-службы с поддержкой XML в SQL Server 2005.

Приложение используется для вставки или получения данных типа BLOB, например больших значений типов binary, image или text.
Приложение требует обработки транзакций в реальном времени, а время ответа критически важно.
SQL Server используется в сочетании с другими приложениями интенсивной обработки данных, например с приложениями TPC Benchmark C (TPC-C).

Учитывайте необходимость дополнительных ресурсов при планировании решений с использованием SOAP

При планировании ресурсных затрат помните, что, в отличие от протокола потока табличных данных (TDS), производительность SOAP зависит от приложения и может требовать дополнительных ресурсных издержек. Например, во время предварительного тестирования SQL Server 2005, выполненного командой разработчиков SQL Server, в сценариях, где возвращались большие XML-документы, доступ по протоколу SOAP занимал на 20-30% больше времени, чем при использовании протокола TDS.

Используйте подходящие параметры WSDL

Перед развертыванием собственных веб-служб с поддержкой XML в SQL Server 2005 нужно определить подходящие параметры WSDL для работы со всеми клиентами и операционными системами, пользующимися решением пользователя.

Для достижения наиболее эффективного взаимодействия в гетерогенных средах, где клиенты веб-служб включают в себя операционные системы, отличные от Windows, используйте значение простой язык WSDL. В средах, включающих в себя только Windows, где ведется разработка в Microsoft Visual Studio 2005, для доступа к различным типам, включенным в Visual Studio 2005, можно использовать язык WSDL по умолчанию.

Иногда SOAP-клиенты сторонних разработчиков требуют для взаимодействия собственные варианты языка WSDL. Дополнительные сведения см. в разделе Реализация поддержки пользовательского формата WSDL.

См. также