Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Платформа безопасности в API веб-служб Windows (WWSAPI) предоставляет следующие возможности:
- Обеспечение целостности сообщений, конфиденциальности, обнаружения воспроизведения и проверки подлинности сервера с использованием транспортной безопасности.
- Проверка подлинности клиента, например проверка маркера безопасности, проверка доверия сертификатов и проверки отзыва и т. д., используя безопасность сообщений SOAP или безопасность транспорта.
Модель программирования безопасности
Безопасность ассоциируется с коммуникационными каналами . Защита канала состоит из следующих шагов.
- Создайте и инициализируйте одну или несколько привязок безопасности, соответствующих требованиям безопасности приложения.
- Создайте описание безопасности с этими привязками безопасности.
- Создайте канал или прокси-службы (на стороне клиента), или создайте прослушиватель или узел службы (на стороне сервера), передавая это описание безопасности.
- Выполните обычные действия по программированию каналов Open, Accept, Send, Receive, Close и т. д.
Сообщения, отправленные и полученные на канале, автоматически защищены средой выполнения в соответствии с указанным описанием безопасности. При необходимости эти действия можно настроить, указав один или несколько параметров безопасности на уровне канала в описании безопасности или на уровне привязки в привязке безопасности .
Все необходимые авторизации идентификаций отправителей должны выполняться приложением с помощью результатов обработки безопасности , присоединённых к каждому полученному сообщению. Действия авторизации не указываются в описании безопасности и не выполняются автоматически средой выполнения.
Ошибки в описании безопасности, такие как неподдерживаемые привязки, неприменимое свойство/поля, отсутствие обязательных свойств, полей или недопустимых значений свойств или полей, приведет к сбою создания канала или прослушивателя.
Выбор привязок безопасности
При разработке безопасности для приложения основное решение — выбор привязок безопасности, которые необходимо включить в описание безопасности. Ниже приведены некоторые рекомендации по выбору привязок безопасности, подходящих для сценария безопасности приложения. Полезная эвристика заключается в том, чтобы сначала понять, какие типы учетных данных безопасности (например, сертификаты X.509, имена пользователей и пароли домена Windows, определяемые приложением имена пользователей и пароли) будут доступны приложению, а затем выбрать привязку безопасности, которая может использовать этот тип учетных данных.
Безопасность транспорта, где безопасность применяется на уровне потока транспорта (ниже границ сообщений SOAP), является первым вариантом.
Для сценариев Интернета и для таких сценариев интрасети, где можно развернуть сертификат X.509 на сервере, приложение может использовать WS_SSL_TRANSPORT_SECURITY_BINDING. В следующем примере показан этот параметр. Клиент: HttpClientWithSslExample Server: HttpServerWithSslExample.
Если требуется проверка подлинности клиента с помощью проверки подлинности заголовка HTTP, можно добавить WS_HTTP_HEADER_AUTH_SECURITY_BINDING для предоставления этой функции.
В сценариях интрасети, где соответствующими являются протоколы встроенной проверки подлинности Windows, такие как Kerberos, NTLM и SPNEGO, приложение может использовать WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING. В следующем примере иллюстрируется эта опция: Client: RequestReplyTcpClientWithWindowsTransportSecurityExample Server: RequestReplyTcpServerWithWindowsTransportSecurityExample.
Клиент через именованные каналы: RequestReplyNamedPipesClientWithWindowsTransportSecurityExample
Сервер использующий именованные каналы: RequestReplyNamedPipesServerWithWindowsTransportSecurityExample
В сценариях локального компьютера, где подходят протоколы интегрированной проверки подлинности Windows, такие как Kerberos, NTLM и SPNEGO, приложение может использовать WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING или WS_NAMEDPIPE_SSPI_TRANSPORT_SECURITY_BINDING. В таких сценарияхWS_NAMEDPIPE_CHANNEL_BINDING предпочтительнее, так как он гарантирует, что трафик не покидает компьютер (это свойство WS_NAMEDPIPE_CHANNEL_BINDING).
Безопасность в смешанном режиме, где транспортная безопасность защищает подключение и заголовок WS-Security в сообщении SOAP обеспечивает проверку подлинности клиента, является следующим вариантом. Следующие привязки используются вместе с одной из привязок безопасности транспорта, описанных в предыдущем разделе.
Когда клиент проходит проверку подлинности парой имени пользователя и пароля на уровне приложения, приложение может использовать WS_USERNAME_MESSAGE_SECURITY_BINDING для предоставления данных проверки подлинности. В следующих примерах показано использование этой привязки в сочетании с WS_SSL_TRANSPORT_SECURITY_BINDING:
Когда клиент проходит проверку подлинности по запросу Kerberos, приложение может использовать WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING для предоставления данных проверки подлинности.
При использовании контекста безопасности клиент сначала устанавливает контекст безопасности с сервером, а затем использует этот контекст для проверки подлинности сообщений. Чтобы эту функцию можно было включить, описание безопасности должно содержать WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING. После установки контексты безопасности можно передавать с помощью легковесных токенов, что позволяет избежать отправки потенциально больших и вычислительно дорогостоящих учетных данных клиента с каждым сообщением.
В сценарии федеративной безопасности клиент сначала получает маркер безопасности, выданный службой маркеров безопасности (STS), а затем представляет выданный маркер службе. На стороне клиента: чтобы получить токен безопасности из STS, приложение может использовать WsRequestSecurityToken. Кроме того, приложение может использовать библиотеку поставщика маркеров безопасности на стороне клиента, например CardSpace или LiveID, а затем использовать их выходные данные для локального создания маркера безопасности с помощью WsCreateXmlSecurityToken. Так или иначе, как только маркер безопасности становится доступен клиенту, он может быть представлен службе, используя описание безопасности, содержащее WS_XML_TOKEN_MESSAGE_SECURITY_BINDING. На стороне сервера: если маркер безопасности, выданный STS, является токеном SAML, то сервер может использовать описание безопасности с WS_SAML_MESSAGE_SECURITY_BINDING.
Заметка
Windows 7 и Windows Server 2008 R2: WWSAPI поддерживает только Ws-Trust и Ws-SecureConversation, как определено профилем безопасности упрощенных веб-служб (LWSSP). Дополнительные сведения о реализации корпорацией Майкрософт см. в разделе Синтаксис MESSAGE LWSSP.
Последний вариант, который следует рассмотреть, заключается в использовании привязок проверки подлинности без использования привязки защиты, например WS_SSL_TRANSPORT_SECURITY_BINDING. Это приведет к передаче учетных данных в виде ясного текста и может иметь последствия для безопасности. Использование этого параметра следует тщательно оценить, чтобы гарантировать отсутствие уязвимостей в результате. Примером потенциального использования является обмен сообщениями между внутренними серверами через безопасную частную сеть. Следующие конфигурации поддерживают этот параметр.
- WS_HTTP_HEADER_AUTH_SECURITY_BINDING поддерживает этот параметр во всех конфигурациях.
- WS_USERNAME_MESSAGE_SECURITY_BINDING поддерживает этот параметр на сервере при использовании HTTP в качестве транспорта.
- WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING поддерживает этот параметр на сервере при использовании HTTP в качестве транспорта.
- WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING поддерживает этот параметр на сервере при использовании HTTP в качестве транспорта.
- WS_SAML_MESSAGE_SECURITY_BINDING поддерживает этот параметр на сервере при использовании HTTP в качестве транспорта.
Чтобы включить этот параметр, необходимо явно установить WS_PROTECTION_LEVEL на значение, отличное от WS_PROTECTION_LEVEL_SIGN_AND_ENCRYPT.
Каналы и безопасность
Как отмечалось выше, безопасность ограничивается каналами. Кроме того, операции канала сопоставляются с шагами безопасности последовательно во всех привязках безопасности.
- Создание канала: набор привязок безопасности, указанных в описании безопасности, проверяется и остается фиксированным для канала после этого. Также определяется форма стека каналов, включая любые параллельные каналы, используемые для переговоров на основе WS-Trust.
- Открытие канала: загружаются все учетные данные, предоставленные в рамках привязок безопасности, и устанавливаются сеансы безопасности. Как правило, открытый канал содержит состояние безопасности в режиме реального времени. Открытие клиентского канала также указывает адрес конечной точки сервера, против которого проверка подлинности сервера будет выполнена во время выполнения.
- Между открытием и закрытием канала: сообщения можно безопасно отправлять и получать на этом этапе.
- Отправка сообщения: маркеры контекста безопасности получаются или обновляются по мере необходимости, а безопасность применяется к каждому переданном сообщению в соответствии с описанием безопасности. Ошибки, возникающие при применении безопасности, возвращаются приложению в качестве ошибок отправки.
- Получение сообщения: безопасность проверяется на каждом полученном сообщении в соответствии с описанием безопасности. Все ошибки проверки безопасности сообщений возвращаются приложению в качестве ошибок получения. Эти ошибки по сообщению не влияют на состояние канала или последующие приемы. Приложение может отменить неудачное получение и начать заново получение нового сообщения.
- Прерывание канала: канал может быть прерван в любое время, чтобы остановить все ввода-вывода на канале. При прерывании канал перейдет в состояние сбоя и не позволит больше отправлять или получать. Однако канал может по-прежнему сохранять некоторое "активное" состояние безопасности, поэтому последующее закрытие канала будет необходимо для полного удаления состояния.
- Закрытие канала: состояние безопасности, созданное при открытии, удаляется, и сеансы прекращаются. Маркеры контекста безопасности отменены. Стек каналов остается, но не содержит 'активного' состояния безопасности или загруженных учетных данных.
- Бесплатный канал: стек каналов, созданный при создании, вместе со всеми ресурсами безопасности, освобождается.
API безопасности
Документация по API для безопасности сгруппирована в следующие разделы.
- Описание системы безопасности
- Федерация
- контекст безопасности
- идентификация конечной точки
- Результаты обработки безопасности
Безопасность
При использовании API безопасности WWSAPI приложения сталкиваются с несколькими рисками безопасности:
-
случайная неправильная настройка
-
WWSAPI поддерживает ряд параметров конфигурации, связанных с безопасностью. См. например пример WS_SECURITY_BINDING_PROPERTY_ID. Некоторые из этих параметров, например WS_SECURITY_BINDING_PROPERTY_ALLOW_ANONYMOUS_CLIENTS позволяют приложению снизить уровень безопасности по умолчанию, предоставляемый различными привязками безопасности. Использование таких параметров следует тщательно оценить, чтобы гарантировать отсутствие результирующего вектора атаки.
Кроме того, как описано выше, WWSAPI позволяет приложению намеренно отключать определенные действия, необходимые для полной защиты обмена сообщениями, таких как разрешение на отключение шифрования, даже если учетные данные безопасности передаются. Это разрешено для включения определенных конкретных сценариев и не должно использоваться для общего взаимодействия. WS_PROTECTION_LEVEL должны быть специально снижены, чтобы включить эти сценарии, и приложения не должны изменять это значение, если это не обязательно, так как это приведет к отключению многих проверок, предназначенных для обеспечения безопасной конфигурации.
-
хранение конфиденциальной информации в памяти
-
Конфиденциальная информация, например пароли, хранящиеся в памяти, уязвимы для извлечения привилегированным злоумышленником с помощью, например, файла страницы. WWSAPI делает копию предоставленных учетных данных и шифрует ее, оставляя исходные данные незащищенными. Это ответственность приложения за защиту исходного экземпляра. Кроме того, зашифрованная копия временно расшифровывается при использовании, создавая возможность для её извлечения.
-
отказ в обслуживании
-
Обработка безопасности может использовать значительные ресурсы. Каждая дополнительная привязка безопасности увеличивает эти затраты. WWSAPI прерывает обработку безопасности сразу после возникновения сбоя проверки безопасности, но некоторые проверки, такие как решения о авторизации, могут не выполняться до тех пор, пока не будет выполнена значительная работа.
Пока на сервере обрабатывается сообщение, состояние безопасности хранится в куче сообщений. Приложение может ограничить потребление памяти во время обработки безопасности, уменьшив размер соответствующей кучи с помощью WS_MESSAGE_PROPERTY_HEAP_PROPERTIES. Кроме того, некоторые привязки безопасности, такие как WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING, могут привести к тому, что сервер выделяет ресурсы от имени клиента. Ограничения для этих ресурсов можно настроить с помощью следующих WS_SECURITY_BINDING_PROPERTY_ID значений:
- WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_MAX_PENDING_CONTEXTS
- WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_MAX_ACTIVE_CONTEXTS
- WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_RENEWAL_INTERVAL
- WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_ROLLOVER_INTERVAL
Установка этих ограничений на низкие значения снижает максимальное потребление памяти, но может привести к отклонению допустимых клиентов при достижении квоты.