WS-Безопасность

Безопасность веб-служб ( WS-Security , WSS ) — это расширение SOAP, позволяющее применять безопасность к веб-службам . Он является членом спецификаций веб-сервисов и был опубликован OASIS .

Протокол определяет, как можно обеспечить целостность и конфиденциальность сообщений, и позволяет передавать различные форматы токенов безопасности, такие как язык разметки утверждений безопасности (SAML), Kerberos и X.509 . Его основное внимание уделяется использованию XML-подписи и XML-шифрования для обеспечения сквозной безопасности.

Функции

WS-Security описывает три основных механизма:

Как подписывать сообщения SOAP для обеспечения целостности. Подписанные сообщения также обеспечивают неотказуемость .
Как зашифровать сообщения SOAP для обеспечения конфиденциальности.
Как прикрепить токены безопасности для установления личности отправителя.

Спецификация допускает различные форматы подписей, алгоритмы шифрования и несколько доверенных доменов и открыта для различных моделей токенов безопасности, таких как:

сертификаты X.509,
билеты Керберос,
Идентификатор пользователя/пароль, учетные данные,
Утверждения SAML и
пользовательские токены.

Форматы и семантика токенов определяются в связанных документах профиля.

WS-Security включает функции безопасности в заголовок сообщения SOAP, работая на уровне приложения .

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

Управление ключами, начальная загрузка доверия, федерация и согласование технических деталей (шифров, форматов, алгоритмов) выходят за рамки WS-Security.

Варианты использования

Сквозная безопасность

Если требуется посредник SOAP и он не пользуется большим или меньшим доверием, сообщения необходимо подписывать и, при необходимости, зашифровывать. Это может быть случай прокси-сервера уровня приложения на периметре сети, который завершает соединения TCP (протокол управления передачей).

Неотказ от ответственности

Одним из методов обеспечения неотказуемости является запись транзакций в журнал аудита, на который распространяются особые меры безопасности. Цифровые подписи, поддерживаемые WS-Security, обеспечивают более прямое и поддающееся проверке доказательство неотказуемости.

Альтернативные транспортные привязки

Хотя почти все службы SOAP реализуют привязки HTTP, теоретически и другие привязки, такие как JMS можно использовать или SMTP; в этом случае потребуется сквозная безопасность.

Обратный прокси/общий токен безопасности

Даже если веб-служба полагается на безопасность транспортного уровня, ей может потребоваться знать о конечном пользователе, если служба ретранслируется с помощью обратного прокси-сервера (HTTP-). Заголовок WSS может использоваться для передачи токена конечного пользователя, подтвержденного обратным прокси-сервером.

Проблемы

Если между поставщиком услуг и потребителем происходит частый обмен сообщениями, накладные расходы XML SIG и XML ENC будут значительными. Если требуется сквозная безопасность, такой протокол, как WS-SecureConversation, может снизить накладные расходы. Если этого достаточно, используйте только шифрование или подпись, поскольку их сочетание значительно медленнее, чем простая сумма отдельных операций. См. «Производительность» ниже.
Объединение нескольких схем XML, таких как SOAP, SAML, XML ENC, XML SIG, может вызвать зависимости от разных версий библиотечных функций, таких как канонизация и синтаксический анализ, которыми сложно управлять на сервере приложений.
только шифрование/дешифрование в режиме CBC Если применяется или если расшифровка в режиме CBC применяется без проверки безопасной контрольной суммы ( подписи или MAC ) перед расшифровкой, то реализация, вероятно, будет уязвима для атак оракула с заполнением . ^[1]

Производительность

WS-Security добавляет значительные накладные расходы на обработку SOAP из-за увеличения размера сообщения в сети, XML и криптографической обработки, что требует более быстрых процессоров, большего объема памяти и пропускной способности.

Оценка в 2005 году ^[2] измерили 25 типов сообщений SOAP различного размера и сложности, обработанных WSS4J с помощью WS-Security и WS-SecureConversation на процессоре Pentium 4/2,8 ГГц.Некоторые выводы были следующими:

Шифрование было быстрее, чем подписание.
Совместное шифрование и подписание были в 2–7 раз медленнее, чем подписание по отдельности, и создавали документы значительно большего размера.
В зависимости от типа сообщения WS-SecureConversation либо не имело никакого значения, либо в лучшем случае сокращало время обработки вдвое.
Подписание или шифрование массива размером до 100 килобайт занимало менее 10 миллисекунд, но выполнение операций безопасности для SOAP занимало около 100–200 миллисекунд.

Еще один ориентир 2006 г. ^[3] привело к такому сравнению:

Механизм безопасности	Сообщений/секунду
WS-Security (X.509) Подпись и шифрование XML	352
Подпись и шифрование XML WS-SecureConversation	798
Безопасность транспортного уровня	2918

История

Веб-сервисы изначально полагались на базовую транспортную безопасность. Фактически, большинство реализаций все еще делают ^{[ нужна ссылка ]}. Поскольку SOAP допускает несколько привязок транспорта, таких как HTTP и SMTP, потребовался механизм безопасности на уровне SOAP. Еще одним фактором было отсутствие сквозной безопасности из-за зависимости от транспортной безопасности.

Протокол был первоначально разработан IBM , Microsoft и VeriSign . Их первоначальная спецификация ^[4]^[5] был опубликован 5 апреля 2002 года, за которым последовало дополнение ^[6] 18 августа 2002 г.

В 2002 году в Технический комитет OASIS WSS были представлены два предложения: ^[7] Безопасность веб-служб (WS-Security) и Приложение по безопасности веб-служб. В результате был опубликован WS-Security:

WS-Security 1.0 был выпущен 19 апреля 2004 года.
Версия 1.1 была выпущена 17 февраля 2006 года.

Стандарт версии 1.0, опубликованный OASIS, содержал ряд существенных отличий от стандарта, предложенного консорциумом IBM, Microsoft и VeriSign. Многие системы были разработаны с использованием предложенного стандарта, и различия сделали их несовместимыми с системами, разработанными в соответствии со стандартом OASIS.

Некоторые называют предварительную спецификацию OASIS «WS-Security Draft 13». ^[8] или как Основная спецификация безопасности веб-служб. Однако эти имена не широко известны, и сегодня трудно четко определить, использует ли приложение или сервер спецификацию до или после OASIS. В большинстве сообщений на форумах для обозначения версии до OASIS используется ключевое слово «WSSE», поскольку оно требовало использования префикса пространства имен XML «wsse» для ^[9] URL-адрес (и аналогичные URL-адреса разных версий).

Протокол официально называется WSS и разработан комитетом Oasis-Open.

Сопутствующие спецификации

С WS-Security связаны следующие проекты спецификаций: WS-Federation , WS-Privacy , WS-Test .

С WS-Security связаны следующие утвержденные спецификации: WS-Policy , WS-SecureConversation , WS-Trust , ID-WSF .

Следующие архитектуры используют WS-Security: TAS3 .

Альтернатива

В ситуациях «точка-точка» конфиденциальность и целостность данных также можно обеспечить в веб-службах с помощью протокола Transport Layer Security (TLS), например, путем отправки сообщений по протоколу HTTPS . Однако WS-Security решает более широкую проблему поддержания целостности и конфиденциальности сообщений до тех пор, пока сообщение не будет отправлено с исходного узла, обеспечивая так называемую сквозную безопасность .

Применение TLS может значительно снизить накладные расходы, устраняя необходимость кодирования ключей и подписей сообщений в XML перед отправкой. Проблема при использовании TLS может заключаться в том, что сообщения должны проходить через прокси-сервер уровня приложения , поскольку он должен иметь возможность видеть запрос на маршрутизацию. В таком примере сервер увидит запрос, исходящий от прокси, а не от клиента; это можно обойти, если у прокси-сервера есть копия ключа и сертификата клиента или имеется сертификат подписи, которому доверяет сервер, с помощью которого он может генерировать пару ключ/сертификат, соответствующую парам ключей и сертификатов клиента. Однако, поскольку прокси-сервер не обрабатывает сообщение, он не обеспечивает сквозную безопасность, а обеспечивает только двухточечную безопасность.

См. также

Продукты и услуги на базе WS-Security
SAML
Базовый профиль безопасности WS-I
Х.509
XACML – стандарт детальной динамической авторизации.

Ссылки

^ Сабарный, Сергей. «Атаки Padding Oracle – взлом теоретически безопасных криптосистем в реальном мире» (PDF) . Рурский университет в Бохуме.
^ «Хунбин Лю, Шридип Палликара, Джеффри Фокс: Эффективность безопасности веб-сервисов» (PDF) . Архивировано из оригинала (PDF) 24 февраля 2021 года . Проверено 12 января 2010 г.
^ Франсуа Лассель, Аарон Флинт: Производительность безопасности WS. Безопасный разговор по сравнению с профилем X509
^ Боб Аткинсон и др.: Безопасность веб-служб (WS-Security) . msdn.microsoft.com
^ Боб Аткинсон и др.: Безопасность веб-служб (WS-Security) . Schemas.xmlsoap.org
^ Джованни Делла-Либера, Филип Халлам-Бейкер, Мэриэнн Хондо: Приложение по безопасности веб-сервисов
^ TC безопасности веб-служб OASIS
^ Безопасность веб-служб: безопасность сообщений SOAP - рабочий проект 13
^ схемы.xmlsoap.org

Внешние ссылки

Web Services Security 1.1.1 (Содержит ссылки для загрузки документов со спецификациями.)
Базовый профиль безопасности WS-I
Документация по безопасности веб-служб
WSS4J (реализация Java WS-Security от Apache)
Apache Rampart (реализация WS-Security Java от Apache Axis2 )
Технологии взаимодействия веб-служб WSIT (WSIT), обеспечивающие взаимодействие между платформой Java и Windows Communication Foundation (WCF).
пример Python ws-security

[1] Сабарный, Сергей. «Атаки Padding Oracle – взлом теоретически безопасных криптосистем в реальном мире» (PDF) . Рурский университет в Бохуме.

[Lui-2] «Хунбин Лю, Шридип Палликара, Джеффри Фокс: Эффективность безопасности веб-сервисов» (PDF) . Архивировано из оригинала (PDF) 24 февраля 2021 года . Проверено 12 января 2010 г.

[3] Франсуа Лассель, Аарон Флинт: Производительность безопасности WS. Безопасный разговор по сравнению с профилем X509

[Atkinson-4] Боб Аткинсон и др.: Безопасность веб-служб (WS-Security) . msdn.microsoft.com

[Atkinson-alt-5] Боб Аткинсон и др.: Безопасность веб-служб (WS-Security) . Schemas.xmlsoap.org

[Della-Libera-6] Джованни Делла-Либера, Филип Халлам-Бейкер, Мэриэнн Хондо: Приложение по безопасности веб-сервисов

[wss-tc-7] TC безопасности веб-служб OASIS

[draft13-8] Безопасность веб-служб: безопасность сообщений SOAP - рабочий проект 13

[9] схемы.xmlsoap.org

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]