В качестве основной технологии обеспечения безопасности сообщений на базе SOAP (изначально Simple Object Access Protocol) прочно закрепился стандарт безопасности служб Web (Web Services Security, WS Security), ратифицированный OASIS, организацией по развитию стандартов структурированной информации. WS Security состоит из целого пакета спецификаций и множества механизмов, которые комбинируются согласно требуемому сценарию применения.

Базовые концепции

OASIS приняла стандарт WS Security в марте 2004 г. в качестве дополнения к протоколу SOAP. К настоящему времени он признан вполне зрелым и пригодным к применению. WS Security не определяет никаких новых технологий, а опирается на уже существующие стандарты, к примеру, XML Encryption, XML Signature, сертификаты X.509 или различные криптографические алгоритмы. Базовая концепция основывается на механизмах сообщений, поэтому вместо защиты, ориентированной на транспорт, возможно обеспечение безопасности из конца в конец (End-to-End Security), к примеру, посредством протокола SSL. Такой подход необходим, чтобы избежать возникновения сквозных коммуникационных структур в пределах SOA, а также обеспечить передачу асинхронных сообщений или использование промежуточных станций (к примеру, сервисной шины предприятия — Enterprise Service Bus, ESB).

Основная задача WS Security — обеспечение целостности, конфиденциальности и аутентичности сообщения и его отправителя при одновременном сохранении открытости для расширений. Основными элементами стандарта являются следующие базовые механизмы (см. Рисунок 1): токены безопасности, шифрование, подписи и отметки о времени.

Токены безопасности (Security Token). Аутентификация отправителя — базовая предпосылка для обеспечения контроля доступа (Access Control) со стороны сервиса, а кроме того, она необходима для организации учета и контроля. Подтверждения идентификации (Credentials), без которых невозможна аутентификация, передаются внутри сообщения в виде токенов. Сама аутентификация не входит в состав WS Security — это самостоятельный процесс провайдера услуг. Для различных форматов токенов OASIS предлагает отдельные спецификации в виде профилей WS Security. Так, «Профиль токена с именем пользователя» (Username Token Profile) регулирует алгоритм широко распространенного метода аутентификации пользователя посредством идентификационного номера (User ID) и соответствующего пароля.

Идентификация приложений или деловых процессов обычно осуществляется с помощью сертификатов, и в этом случае управлять паролями на стороне клиента не нужно. Обращение с сертификатами для указанного метода аутентификации описывается в профиле X.509 Certificate Token Profile. Существуют и другие профили, к примеру, для использования токенов языка разметки утверждений безопасности (Security Assertion Markup Language, SAML) или Kerberos.

Двоичные или базирующиеся на XML токены безопасности нужны не только для аутентификации. Они выполняют еще одну функцию, представляя собой основу для транспорта или привязки ключей (Keys), применяемых в криптографии.

Шифрование. Чтобы обеспечить защиту конфиденциальных данных, используется криптографическое шифрование. Поскольку протокол SOAP базируется на XML, то WS Security не определяет новый стандарт, а использует спецификацию XML Encryption из W3C. Зашифрованные данные и их метаинформация, в свою очередь, включаются в сообщение в виде структур XML. Однако, согласно спецификации SOAP, нельзя шифровать элементы «конверт» (Envelope), «заголовок» (Header) и «тело» (Body), поскольку они задают структуру сообщения и должны быть всегда читаемыми.

Принципиально различают два механизма шифрования: симметричное и асимметричное. При симметричном шифровании (метод «секретного ключа» — Secret Key) для шифрования и дешифровки используется общий ключ, всегда доступный обеим сторонам. При асимметричном шифровании (алгоритм с открытыми ключами — Public Key) для шифрования и дешифровки применяются разные ключи, что существенно сокращает затраты усилий на их распределение: личный ключ (Private Key) остается у владельца, а общий ключ (Public Key) распространяется свободно. Однако по сравнению с секретными ключами механизм открытых ключей работает значительно медленнее, поэтому оба подхода часто объединяют, в результате чего появляются новые гибридные варианты. Клиент генерирует симметричный ключ сеанса (Session Key) и использует его для симметричного шифрования больших объемов данных. В заключение симметричный ключ шифруется с помощью асимметричного алгоритма, вкладывается в сообщение и предоставляется в распоряжение сервиса.

Подпись (Signature). Для подтверждения целостности сообщений применяются подписи. Они позволяют распознать неправомерные модификации: изменение, удаление или добавление данных. Реализация этого подхода в рамках WS Security опирается на стандарт XML Digital Signature от W3C. Принцип подписей основан на создании контрольных сумм с помощью специальных алгоритмов (дайджет). Результаты присоединяются к сообщению и передаются в частично зашифрованном виде. Сервисная сторона формирует контрольную сумму и сравнивает ее со значением, присланным клиентом. Поскольку в XML различные способы написания логически идентичны, перед формированием контрольной суммы необходимо произвести нормализацию данных. Для этого используются стандартизованные алгоритмы XML Canonicalization, также позаимствованные из W3C.

Кроме того, подписи предоставляют возможность установления аутентичности отправителя. Эту информацию можно использовать в юридических целях для установления авторства.

Отметка о времени (Timestamp). Идея услуг в рамках SOA подразумевает, что сервисы должны производить определенное действие и таким образом поддерживать взаимодействие без учета состояния (Stateless). Однако данный принцип коммуникации без установления сеанса открывает простор для атак сброса (Replay), когда атакующий повторно отправляет либо сообщения целиком, либо отдельные их части. Чтобы воспрепятствовать таким атакам, необходимо гарантировать уникальность сообщений, для чего каждое из них получает свой идентификационный номер (Message ID), который сервис проверяет на предмет его уникальности. Поэтому идентификационные номера уже полученных сообщений необходимо сохранять. Срок действия, а значит, и время хранения отдельных идентификационных номеров сообщений на стороне сервиса ограничивается содержащейся
в сообщении отметкой о времени.

Помимо использования традиционной структуры отметок о времени в заголовке безопасности (Security Header), токен с именем пользователя предлагает собственное управление отметками о времени во избежание несанкционированного повторного использования данных для аутентификации. Идентификационный номер сообщения должен соответствовать спецификации WS Addressing. А токены с именем пользователя получают случайное криптографическое значение (Nonce).

В рамках SOA каждый из упомянутых четырех базовых механизмов охватывает лишь один аспект обеспечения безопасности. Сформировать целостное решение можно лишь при условии взаимодействия всех компонентов. Вполне традиционна комбинация механизмов безопасности на основе сообщений (WS Security), ориентированных на транспорт (SSL). Сценарий, представленный на Рисунке 2, подробно разъясняет необходимость использования комбинации различных механизмов.

Аутентификация. Любой контроль доступа на стороне сервиса предполагает аутентификацию клиента. Сервисной стороне необходимо иметь сведения о подтверждении идентификации. В случае метода с пользовательским идентификационным номером и паролем WS Security предоставляет механизм токенов с именем пользователя, где пароль является конфиденциальной информацией, поэтому необходимо предотвратить его считывание в процессе транспорта. Шифрование необходимо, даже если механизм, определенный в спецификации токенов с именем пользователя, предполагает передачу пароля только в виде контрольной суммы. При использовании читаемой контрольной суммы возникает угроза атаки методом подбора пароля (Brute Force) путем проверки всех возможных комбинаций, поскольку пароли ограничены по длине и набору символов.

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

Конфиденциальность. Предотвратить хищение пароля во время пересылки сообщения призвано шифрование токена с именем пользователя. В некоторых случаях достаточно применить широко распространенный протокол SSL. Однако необходимо учесть, что вследствие принципа соединения двух точек, свойственного SSL, использование промежуточных узлов, к примеру, сервисной шины предприятия (Enterprise Service Bus, ESB), невозможно, и защита данных после их передачи не обеспечивается.

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

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

Уникальность сообщения. Для того чтобы предотвратить повторную отправку сообщения (атака Replay), на сервисной стороне необходимо проверить уникальность сообщения. Для этого к сообщению, представленному в стандартизованном виде, добавляется идентификационный номер. Стандарт WS Addressing, определенный в W3C, предусматривает, среди прочего, задание идентификационного номера сообщения, который помогает установить его уникальность. Определенная в рамках WS Security структура указывает время создания сообщения и окончание срока его действия.

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