Безопасность Web-сервисного взаимодействия

  ОБЗОРЫ   

Появление Web-сервисов добавило еще один слой, на котором нужно обеспечивать защиту информации

Продолжение. Начало см. PC Week/RE, N 27/2004, с. 20; N 28/2004, с. 19; N 29/2004, с. 18; N 30/2004, с. 20; N 31/2004, с. 22.

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

Сегодня есть несколько наборов спецификаций, говорящих, как решать эти вопросы применительно к Web-сервисам. Первый относится к семейству GXA (Global XML Web Services Architecture), предлагаемому группой компаний, включающей IBM и Microsoft. Он состоит из спецификаций серии WS-*: WS-Security, WS-Trust, WS-SecureConversation, WS-Federation, WS-Policy и пр. Все они проходят утверждение в качестве потенциальных стандартов W3C и OASIS.

Второй набор предлагается группой фирм, более близких к Sun Microsystems и Oracle. К нему относятся две группы стандартов OASIS - SAML и XACML, а также продукция альянса Liberty. Заметим, что в отличие от WS-* это по большей части открытые разработки, т. е. производители ПО могут реализовывать многие из них в своих продуктах бесплатно. Стоит отметить также, что в работе над SAML принимают участие и традиционные противники Sun/Oracle, такие, как те же IBM и Microsoft. Хотя, конечно, роль "первой скрипки" здесь отводится не им.

На 90% оба стека технологий решают однотипные задачи, хотя и различными способами. Некоторые из спецификаций явно предусматривают возможности взаимодействия с системами, построенными на базе технологий конкурентов, и в этом смысле SAML более универсален. Общей базой для всех решений безопасности, похоже, становится WS-Security, а вот в других областях подобной однозначности нет. Например, в качестве основы для построения средств однократной идентификации пользователя большую популярность в уже реализованных решениях приобрели SAML и продукция Liberty. По всей видимости, в обозримой перспективе будут сосуществовать все описываемые ниже технологии.    

Рис. 1. Стек протоколов обеспечения безопасности Web-сервисов в GXA

Данный раздел обзора "Web-сервисы в корпоративной среде" состоит из нескольких частей - вначале будут рассмотрены средства GXA для обеспечения взаимной безопасности двух взаимодействующих через Web-сервисы сторон, затем - как в GXA организуются политики безопасности и взаимодействие многих сторон, и, наконец, технологии, выходящие под эгидой OASIS и Liberty Alliance.

Web Services Security (WS-Security) и др.

Статус: авторская версия, April 2002.

Авторы: IBM, Microsoft, VerySign.

Опирается на: XML Encryption, XML Signature.

Дополняется: Web Services Security Addendum.

Стандартизация: спецификация лежит в основе SOAP Message Security, имеющего статус рабочего документа OASIS, август 2003.

WS-Security описывает базовый слой для многих других технологий в области безопасности Web-сервисов - а именно то, как обеспечить целостность, конфиденциальность и неподдельность авторства (аутентичность) одного отдельно взятого SOAP-сообщения, передаваемого в рамках уже установленных сессий, контекста и политики безопасности. Она обобщает ряд ранних наработок IBM и Microsoft в этой области, в частности SOAP-SEC, WS-Security and WS-License и пр. В спецификации не говорится о том, как устанавливать контекст сессии, производить аутентификацию сторон, обмен ключами, формировать производные ключи, определять границы доверия доменов. Это задачи других спецификаций GXA. Кроме того, в ней задается только рамочная архитектура - для производства реальных операций она полагается на уже имеющиеся технологии вроде PKI, Kerberos и SSL.

Для достижения сформулированной выше цели спецификация определяет набор расширений SOAP - XML-тегов, позволяющих описывать метаданные о защищенной информации, правила ее размещения внутри SOAP-конверта, правила замещения незашифрованных данных зашифрованными. В ней также задается три основных механизма безопасности: передача жетона безопасности (ЖБ), обеспечение целостности сообщения и его конфиденциальности.

Жетоны безопасности

ЖБ представляют собой некоторый набор утверждений, которые делает отправитель сообщения. Смысл этих утверждений в WS-Security не оговаривается, так как он зависит от конкретной реализации. Утверждениями могут быть имя пользователя, ключ, разрешение на операцию и т. п. Жетон может быть заверен (но не обязательно) цифровой подписью, проверяя которую получатель удостоверяется в том, что отправитель знает необходимый ключ, а стало быть, заслуживает доверия. Важным классом являются утверждения, подписанные авторитетной инстанцией, например сертификаты X.509, задающие связь между некой сущностью (identity) и общедоступным ключом. Обладатель такого сертификата может применять связанный с ним секретный ключ для подписания своих собственных утверждений, которые будут ассоциированы с сущностью через сертификат.

Стороны могут принимать и не подтвержденные подписью ЖБ - в случае, когда уже установлены доверительные отношения между отправителем и получателем, скажем, по защищенному каналу. Особый класс неподтвержденных претензий - доказательства обладания (proof-of-possession), в которых отправитель демонстрирует, что знает определенные сведения, и факт этого знания заинтересованные участники могут проверить. Такой претензией, скажем, может быть комбинация имени пользователя и зашифрованного пароля доступа.

Средством реализации модели жетонов является вводимый спецификацией блок в заголовке SOAP-сообщения. Сообщение может иметь несколько таких блоков, предназначенных для разных SOAP-узлов на его пути. Элементы блока хранят сведения об операциях шифрования и подписания, производимых над другими элементами сообщения - включая части его тела, заголовка и вложений (attachments). Заполнение блока происходит по мере произведения этих операций, что решает проблему влияния более поздних этапов на более ранние. В этом же блоке хранятся двоичные жетоны и сертификаты безопасности (элемент), выданные сторонними системами, например X.509 или Kerberos. Стандарт предусматривает механизм ссылки из текста сообщения на данные в них, в частности для извлечения ключа. Для этого используется синтаксис аналогичный синтаксису, языка XPath. Имеется способ для извлечения жетонов из внешних источников по ссылке на них (элемент). Неподтвержденные претензии оформляются здесь же - в элементе.    

Рис. 2. Пример SOAP-сообщения с данными WS-Security. Пространство имен

ds принадлежит спецификации XML Signature, xenc - XML Encription, а wsse - WS-Security

Рис. 3. Пример использования WS-SecureConversation в рамках уже установленной сессии

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

Подписание и шифрование

Для обеспечения целостности сообщения WS-Security опирается на стандарт цифровой подписи XML Signature. Все подписи хранятся в блоке. Спецификация позволяет присоединить к сообщению несколько подписей (имеющих даже разные типы), относящихся к различным, в том числе перекрывающимся, его частям.

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

В заключение стоит сказать, что WS-Security задает еще некоторые правила кодирования двоичных жетонов безопасности, в частности подробно рассматриваются правила кодирования сертификатов X.509, "билетов" Kerberos и включения замаскированных (opaque) зашифрованных ключей. Предусмотрен и механизм расширения для включения в сообщения дополнительных полей мандатов (credentials).

Web Services Trust Language (WS-Trust)

Статус: черновик, версия 1.1, май 2004.

Авторы: BEA Systems, Computer Associates, IBM, Layer 7 Technologies, Microsoft, Netegrity, Oblix, OpenNetwork Technologies, Ping Identity, Reactivity, RSA Security, VeriSign и Westbridge Technology.

Для того чтобы установить защищенное соединение между двумя участниками, им необходимо явно или неявно обменяться некими мандатами доверия. И каждая из сторон должна иметь механизм, позволяющий определить, может ли она доверять мандату, присылаемому ей от ее визави. WS-Trust определяет средства для этого, а именно: расширения WS-Security, обеспечивающие выдачу, обновление и проверку жетонов безопасности, а также установление доверительных отношений между доменами, в том числе с использованием услуг посредников.    

Рис. 4. Иллюстрация установления доверительных отношений между доменами с помощью WS-Trust.

Стрелки изображают коммуникационные пути; клиент может получить жетон напрямую от сервиса ЖБ или неявно.

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

безопасности, либо запрашивает сервис жетонов безопасности проверить полученный им ЖБ.    

Модель безопасности, определенная в WS-Trust, основывается на многостадийном процессе, в ходе которого Web-сервис проверяет сообщения клиента на предмет правомочности включенных в них ЖБ. При отсутствии подобных доказательств или несовпадении списка утверждений жетона с тем, что сервис считает нужным, производится отказ в обслуживании. Сервис может перечислить требуемые им утверждения и доказательства, а также связанную с ними информацию, в политиках, описываемых спецификациями WSPolicy и WS-PolicyAttachment. Для усиления безопасности аутентификация запросов предварительно осуществляется еще и на сетевом и транспортном уровнях, например, при помощи IPSec и SSL.

Один из способов, которым клиент может продемонстрировать наличие авторизации на использование ЖБ, состоит в цифровом подписании каждого утверждения в запросе. При этом клиент должен приложить к сообщению еще один жетон безопасности, например сертификат PKI или X.509. Такой жетон должен иметь вес для сервиса, т. е. быть выдан авторитетной инстанцией, именуемой в спецификации сервисом жетонов безопасности (СЖБ). Для каждого сервиса эта инстанция может быть своя, и она указывается в политике безопасности. Но клиент и сам может потребовать от сервиса предъявления доказательств своей идентичности, например жетона, выданного признаваемым им СЖБ. Таким образом формируется иерархия доверительных отношений между разными доменами, в вершине которой находится СЖБ.

Механизмы установления доверия

WS-Trust выделяет четыре способа выстраивания доверительных отношений:

- прямые доверительные отношения - запрос на жетон, необходимый для доступа к сервису, делается в СЖБ самим клиентом или третьей стороной от его имени;

- делегированный запрос - запрос от клиента передается сервису через посредника и от его имени. Посредник и предъявляет свои полномочия;

- получение жетона "out of band" - авторитетная инстанция передает ЖБ сервису заранее, не дожидаясь запроса со стороны своего клиента. Сервис сохраняет жетон в ожидании действий клиента;

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

Кроме того, спецификация определяет инфраструктуру работы с жетонами безопасности - протоколы обмена сообщениями (т.е. наборы SOAP-команд), необходимые для получения ЖБ (в том числе с ключами шифрования), и соответствующие описания Web-сервисов, выдающих эти жетоны. Команды запросов и ответов этих протоколов (/) помещаются в тело SOAP-сообщений, а заголовки обязаны содержать блок , нужный для авторизации сообщений.

Схемы обмена такими сообщениями могут быть достаточно сложными, например, в рамках протокола challenge - response ("брошенный вызов - ответ") Web-сервис авторизации может попросить от клиента дополнительных сведений, скажем, если ему не понравилась печать о времени выдачи в предъявленном ЖБ. Это может быть требование подписать какую-либо строку, сгенерированную сервисом, или запрос на дополнительный жетон безопасности.

Как итог можно сказать, что модель WS-Trust, элементами которой являются утверждения, политики и жетоны безопасности, обобщает несколько более специфических моделей авторизации: на базе сущностей, списков контроля доступа и возможностей. Она допускает использование существующих технологий, таких, как сертификаты с открытым ключом X.509, XML-жетоны, билеты Kerberos (опирающиеся на совместное использование секретного ключа) и даже хэш-функции от паролей.

Web Services Secure Conversation Language (WS-SecureConversation)

Статус: авторский документ, версия 1.1, май 2004.

Авторы: OpenNetwork, Layer 7, Netegrity, Microsoft, Reactivity, IBM, VeriSign, BEA, Oblix, RSA Security, Westbridge, Computer Associates, Ping Identity.

Эта спецификация определяет расширения WS-Security и WS-Trust, необходимые для создания безопасного канала, по которому можно переслать не одно, а много сообщений. Для решения данной задачи применяются три механизма:

- создание общего контекста безопасности;

- совместное использование этого контекста (в том числе его расширение дополнительными сведениями);

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

Применение этих механизмов позволяет поднять как общий уровень безопасности, так и эффективность обмена сообщениями.

Контекст безопасности, определяемый WS-SecureConversation, передается внутри элемента в жетоне, обозначаемом тегом (жетон контекста безопасности, ЖКБ). Жетон содержит одно обязательное поле - уникальный двоичный идентификатор контекста, а также любое число дополнительных. Он имеет имя, указываемое в атрибуте wsu:Id, по которому на него можно ссылаться из других мест сообщения. Подобные ссылки делаются при помощи механизмов WS-Security - элемента - и применяются, например, для указания информации о ключе шифрования, использованном для кодирования определенной части сообщения.    

Рис. 5. Протокол "бросания вызова" WS-Trust

ЖКБ генерируется системой по стандартному запросу WS-Trust , в котором в качестве параметра передается специальный URI. Задается три алгоритма для его создания и распространения:

- сервисом жетонов по запросу от инициатора создания контекста. Далее инициатор рассылает контекст всем участникам;

- одним из участников; затем он передается другим в SOAP-сообщениях. Эта модель работает, когда отправителю можно доверить создание нового контекста;

- через процесс торга/обмена, т. е. множественного обмена сообщениями.

Кроме того, в WS-SecureConversation есть возможность потребовать от сервиса пополнить контекст безопасности дополнительными данными. Для этого применяется механизм команд спецификации WS Addressing - возможность отсылки сервису запроса с URI-идентификатором требуемого действия, помещаемым в поле заголовка.

И наконец, спецификация задает механизм генерации производных ключей. Установленный контекст безопасности предполагает, что стороны обмена сообщениями имеют какой-то общий секрет, содержащий и ключи шифрования. Однако производные от этого секрета ключи усиливают безопасность. В частности, стороны могут применять разные ключи для подписания и шифрования документов. Нередко используется и такой прием: генерация нового производного ключа при отправке очередного сообщения. Для оформления подобных ключей в переписке применяется жетон в блоке заголовка сообщения. Поля этого жетона указывают, как сформировать нужный ключ, например, поле указывает на номер поколения применяемых ключей. Производные ключи оформляются как ЖБ, имеющие специальный URI-тип. Они применяются в соответствии с требованиями WS-Security.

***

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

(Продолжение следует)