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

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

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

  • Защитить установку SQL Server при использовании собственных веб-служб с поддержкой XML.

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

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

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

  • Используйте проверку подлинности Kerberos.

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

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

  • Защищайте SQL Server брандмауэром.

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

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

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

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

Во время выполнения инструкции CREATE ENDPOINT (Transact-SQL) для создания конечных точек выберите или 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.

Дополнительные сведения см. в разделе 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 только за брандмауэром. Убедитесь, что все заданные при настройке конечных точек номера портов TCP, предоставляющие доступ через HTTP, защищены брандмауэром. Сетевая конфигурация, разрешающая веб-клиентам открытый доступ к установке SQL Server, не защищенной брандмауэром, не рекомендуется. Дополнительные сведения см. в разделе Вопросы безопасности при установке SQL Server.

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

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

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

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

При создании конечной точки с помощью инструкции CREATE ENDPOINT (Transact-SQL) ее состоянием по умолчанию будет STOPPED, если только не запустить ее явно с помощью инструкции STATE = STARTED. Чтобы управлять состоянием существующей конечной точки, используйте инструкцию ALTER ENDPOINT (Transact-SQL) и укажите состояние 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 для конечной точки отключен.

  • LOGIN_TYPE = WINDOWS

    Для пользователей конечной точки разрешена только проверка подлинности Windows.

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

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

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

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

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

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

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

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

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

  • Приложение возвращает или получает XML-данные.

  • Бизнес-логика приложения во многом зависит от хранимых процедур.

  • Для достижения целей архитектуры SOA (Service Oriented Architecture) нужно интегрировать приложение веб-службы, размещенной на SQL Server, с другими приложениями веб-служб, как часть делового решения.

  • Нужна более производительная замена решению SQLXML среднего уровня для развертывания нескольких веб-служб на одном сервере.

  • Нужно создавать и публиковать статические отчеты на веб-сайте интрасети, где обширный набор возможностей и дополнительные издержки служб Службы SQL Server 2005 Reporting Services или более поздней версии могут превысить указанные требования.

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

  • Приложение используется для вставки или получения данных типа 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 нужно определить подходящие параметры языка WSDL для работы со всеми клиентами и операционными системами, пользующимися решением пользователя.

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

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