Без надлежащего обеспечения безопасности сервис-ориентированную архитектуру (Service-Oriented Architecture, SOA) невозможно использовать в критически важных для предприятия областях, где к защите данных предъявляются особые требования, к примеру, поддержка сквозной безопасности (End-to-End Security). В качестве первичной технологии утвердился стандарт OASIS WS-Security, определяющий применение шифрования, подписей, токенов безопасности и отметок о времени в среде сервисов Web.

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

ХОРЕОГРАФИЯ БЕЗОПАСНОСТИ

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

Для осуществления контактов между клиентом и сервисом — не только рабочих, но и связанных с вопросами обеспечения безопасности — требуется реализовать согласованные действия. На профессиональном языке описание этих мер в отношении используемых механизмов безопасности и порядка их выполнения называется «хореографией безопасности».

Понятие «хореография» имеет греческие корни и состоит из двух слов: «хорея» (пляска) и «графо» (пишу). Как правило, оно применяется для описания танцевальных па. Применительно к безопасности указанный термин означает следующее: взаимобезопасная коммуникация между клиентом и сервисом возможна лишь тогда, когда оба используют одинаковую хореографию в отношении элементов (механизмов безопасности) и их хронологии (порядка выполнения). При этом необходимо заранее согласовать хореографию между клиентом и сервисом, поскольку не существует какой-либо центральной инстанции, на которую можно переложить ответственность за управление и контроль (Рисунок 1). Понятие «хореография безопасности» не следует путать с «хореографией WS» в стандарте W3C — последнее относится к языку описания потока сообщений при взаимодействии между сервисами Web в рамках деловых процессов.

Из-за разнородности среды в SOA решения безопасности различных производителей и платформ должны быть интероперабельными. К сожалению, при рассмотрении вопросов совместимос-ти недостаточное значение придается тому, что требуется обеспечить не только согласованное внедрение криптографических алгоритмов и согласованное отображение данных в XML, но и одинаковое понимание хореографии безопасности.

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

Хореография, используемая при коммуникации между клиентом и сервисом, определяется сервисом, выступающим в качестве поставщика услуг, а клиент обязан подчиняться предписаниям. Требуемая информация предоставляется клиенту сервисом через WSDL. Ранее WSDL содержал функциональное описание сервиса (действия, сообщения), а также различную информацию о доступе (адрес, порт, протокол). С введением стандарта OASIS WS-SecurityPolicy эта информация дополняется описанием требований к безопасности.

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

В основе дальнейшего рассмотрения хореографии лежит следующий сценарий: действующее лицо со стороны клиента состоит из пользователя «Элис» (запрашивающая сторона) и програм-много компонента «инициатор», осуществляющего по поручению Элис коммуникацию с сервисом. Сервисная сторона воплощена в виде программного компонента «получатель» и поставщика услуг Bob Corporation (проверяющая сторона). Обычно инициатор на стороне клиента отправляет сообщение с запросом, получатель производит определенные действия и отправляет ответное сообщение. Базовый сценарий иллюстрирует Рисунок 2.

Для наглядной демонстрации отдельных хореографий безопасности используется схематическое изображение, представляющее собой набор диаграмм действий и потоков данных. Схема (см. Рисунок 3) включает уровни действий клиента (слева), сервиса (справа) и сообщений (посередине), где отображаются важнейшие данные в пределах сообщения. На каждом уровне действий отображены соответствующие структуры данных, а также главные действия, в том числе токены безопасности (ключи). Внутренний поток данных между данными и действиями отображается путем горизонтального последовательного размещения элементов. За счет отказа от традиционных стрелок возникает компактная форма отображения, которая, благодаря фокусировке на самом существенном, лучше всего подходит для сравнения различных хореографий.

Действиям соответствуют комплементарные парные методы шифрования и дешифрования, а также генерирования и проверки подписей. Генерирование подписей и их проверка представляют собой сложные процессы. Схематичное изображение упрощено до такой степени, что в нем присутствуют только задействованные ключи и важнейшие данные, требующие подписи. Примеры схем шаблонов показаны на Рисунке 5.

Хореографические шаблоны состоят из комбинации различных механизмов безопасности, которые, в свою очередь, основываются на базовых криптографических алгоритмах. Перед детальным рассмотрением нескольких типичных хореографий еще раз (путем изображения шаблонов) продемонстрируем лежащие в их основе алгоритмы. На Рисунке 4 приведено краткое описание использованных символов.

Симметричное шифрование. При симметричном шифровании отправитель и получатель применяют один и тот же ключ. Предварительно обе стороны должны обменяться этим ключом, что, как правило, требует дополнительных усилий и противоречит слабой связи между клиентами и сервисами. При наличии множества клиентов у этого механизма проявляются многочисленные недостатки в отношении масштабируемости, кроме того, с увеличением числа распределенных ключей понижается уровень безопасности. Преимущество данного метода заключается в низкой нагрузке на процессор, а значит, этот алгоритм оптимален для шифрования и дешифрования больших объемов данных. Типичные симметричные алгоритмы: 3DES, AES/Rijndael, Blowfish и RC4.

Асимметричное шифрование. Асимметричные механизмы шифрования базируются на использовании двух различных ключей: общего ключа (Public Key) для шифрования данных и личного ключа (Private Key) для их дешифрования. Это метод не предполагает обмена секретными ключами. Открытый ключ обычно предоставляется с помощью сертификата X.509. Поскольку личный ключ находится во владении единственного получателя (по крайней мере, подобное требование диктуют правила), то асимметричное шифрование автоматически обеспечивает возможность аутентификации получателя. Таким образом, Элис на стороне клиента может аутентифицировать сервис, предоставляемый Bob Corporation. Недостатком является сложность асимметричных алгоритмов и связанная с этим низкая производительность, из-за чего данный метод оказывается пригодным лишь для небольших объемов данных. Типичные асимметричные алгоритмы: RSA, El-Gamal и Diffie-Hellman.

Гибридное шифрование. Речь идет о комбинации симметричных и несимметричных алгоритмов. Симметричный метод предназначается для шифрования больших объемов данных. Ключ генерируется для каждого сообщения и предоставляется получателю в зашифрованном виде. Однако для шифрования симметричного ключа используется асимметричный метод, тем самым, помимо распределения ключей на базе сертификатов, автоматически обеспечивается аутентификация получателей (Рисунок 5).

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

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

Асимметричная подпись. Метод основывается на обращении механизма асимметричного шифрования: данные шифруются посредством личного ключа, а декодируются с помощью общего. Этот алгоритм позволяет получателю идентифицировать отправителя, что равнозначно цифровой подписи. Однако конфиденциальность данных не обеспечивается, поскольку каждый, кто обладает общим ключом, сможет их расшифровать и прочитать. Рисунок 5 показывает хореографии для различных типов подписей.

WS-SECURITY POLICY

WS-SecurityPolicy — часть обширного семейства правил, состоящего из множества спецификаций. В качестве базового стандарта WS-Policy предоставляет общий расширяемый язык для описания утверждений (Assertion). На основе этой грамматики определяются конкретные описания для свойств безопасности, базирующихся на механизмах WS-Security и других спецификаций, таких как WS-Trust и WS-SecureConversation. Правила дополняются стандартом WS-PolicyAttachment, где определяется, каким образом отдельные описания будут внедряться в документы WSDL или UDDI.

Модель утверждений WS-Security-Policy состоит из отдельных комбинируемых групп. К примеру, утверждения защиты (Protection Assertion) определяют, какие части сообщений необходимо защитить посредством шифрования или подписи. А обязательные утверждения безопасности (Security Binding Assertions) и поддержки токенов (Supporting Token Assertions) в значительной мере определяют хореографию безопасности между клиентом и сервисом. При этом можно задать следующие свойства:

  • вид токенов безопасности, предоставляемых путем передачи сообщений;
  • механизмы транспорта криптографических ключей (Key);
  • требуемые элементы сообщений (к примеру, отметка о времени для предотвращения атак сброса (Replay));
  • порядок элементов в заголовке без-опасности сообщения SOAP;
  • порядок отдельных выполняемых механизмов безопасности;
  • дополнительные опции для отдельных алгоритмов.

На Рисунке 6 представлен общий вид структуры утверждений в WS-Security-Policy. Задача WS-SecurityPolicy заключается в описании надежного обмена сообщениями между клиентом и службой на базе WS-Security. Посредством такого описания правил все исходящие сообщения защищаются соответствующими механизмами безопасности, а все входящие сообщения проверяются на предмет соблюдения правил.

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

  • соглашение о транспорте (Transport Binding);
  • асимметричное соглашение (Asym-metric Binding);
  • симметричное соглашение (Sym-metric Binding).

Соглашение о транспорте реализует защиту сообщений с помощью надежного транспортного канала, к примеру, посредством использования HTTPS, причем механизмы шифрования и подписей на уровне сообщений не нужны. И наоборот, асимметричное и симметричное соглашения реализуют — благодаря комбинации базовых механизмов — независимую от транспорта защиту сообщений. Поскольку язык описания WS-SecurityPolicy отличается большей степенью абстракции, отдельные базовые механизмы распознать не так просто. Далее мы детально рассмотрим типичные хореографические шаблоны, основанные на обоих видах соглашений о взаимодействии.

Если и клиент, и сервис обладают токенами безопасности, к примеру, в виде сертификатов X.509, включая соответствующий личный ключ, то в этом случае можно воспользоваться асимметричным соглашением. На Рисунке 7 показана хореография такого соглашения. Шифрование данных в сообщении-запросе осуществляется на стороне клиента с помощью сгенерированного симметричного ключа, который шифруется посредством общего ключа от Bob Corporation и затем предоставляется в распоряжение сервиса. Подпись выполняется с применением личного ключа Элис. Соответственно, на стороне сервиса для расшифровки данных потребуется личный ключ Bob Corporation, а для подтверждения подписи — общий ключ от Элис.

Обработка ответного сообщения осуществляется в соответствии с теми же принципами, только пары ключей меняются местами. WS-SecurityPolicy определяет токен инициатора и токен получателя. Для такого типа соглашения характерна возможность взаимной аутентификации на базе сертификатов, поэтому на практике данную хореографию часто называют «взаимный сертификат» (Mutual Certificate).

При симметричном соглашении используется только сертификат X.509 со стороны сервиса. На Рисунке 8 изображена соответствующая хореография. Для непосредственного шифрования и подписи на стороне клиента генерируется симметричный ключ, который применяется как при запросе, так и при ответе. Симметричный ключ, часто называемый сеансовым (Session Key), шифруется с помощью общего ключа от Bob Corporation, включается в сообщение с запросом и предоставляется сервису. WS-SecurityPolicy определяет для этого типа соглашения защитный токен (Protection Token). Преимущество заключается в простоте обработки ответного сообщения. Поскольку аутентификация клиента невозможна, эта хореография часто именуется «анонимной» (Anonymous).

Чтобы при симметричном соглашении все-таки удалось осуществить аутентификацию клиента, базовая хореография дополняется «удостоверяющей» подписью (Endorsing Signature). В этом случае личным ключом Элис заверяется уже существующая симметричная подпись, благодаря которой сервисная сторона получает возможность идентифицировать клиента и обеспечить взаимную аутентификацию на базе сертификатов даже в случае симметричного соглашения. В WS-SecurityPolicy необходимо задать дополнительный токен, поддерживающий эту подпись (Endorsing Supporting Token). Соответствующая хореография представлена на Рисунке 9.

Еще один популярный вариант добавления аутентификации клиентов в симметричное соглашение — использование токена с именем пользователя (Username Token), позволяющего аутентифицировать клиента с помощью идентификационного номера пользователя (User ID) и пароля. Для обеспечения конфиденциальности и целостности такой информации токен нужно зашифровать и включить в подпись сообщения. Для этого в WS-SecurityPolicy задается утверждение Username Token в рамках утверждения Signed Supporting Token.

Помимо удостоверяющей подписи и токена с именем пользователя базовую хореографию в случае симметричного соглашения можно дополнить другими механизмами для аутентификации клиентов. Так, токены на базе SAML применяются преимущественно в сценариях с интегрированными личностями (Federated Identity).

ЗАКЛЮЧЕНИЕ

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

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

Детлеф Штурм — старший менеджер по продуктовым технологиям компании Beta Systems Software AG.

Рисунок 1. Хореография безопасности.

Рисунок 2. Базовый сценарий.

Рисунок 3. Схема изображения.

Рисунок 4. Список используемых символов.

Рисунок 5. Хореографии для шифрования и подписей.

Рисунок 6. Структура утверждений WS-SecurityPolicy.

Рисунок 7. Хореография асимметричного соглашения.

Рисунок 8. Хореография симметричного соглашения.

Рисунок 9. Хореография симметричного соглашения и удостоверяющей подписи.