Безопасность в сервис-ориентированных архитектурах

В качестве основной технологии обеспечения безопасности сообщений на базе 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 структура указывает время создания сообщения и окончание срока его действия.

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

ПОДПИСИ И ИХ ЗАДАЧИ

Благодаря своей инфраструктуре на основе сообщений, сервисы Web поддерживают возможность включения любых промежуточных инстанций (Intermediaries) между конечными точками. C помощью такой архитектуры можно расширить функциональность сервисов Web. Кроме того, эта архитектура становится основой для организации разделения ответственности за реализацию свойств сервиса, особенно требований, не связанных с функциональностью (качество сервиса — Quality of Services, QoS). При вызове сервиса сообщения с запросом и ответом должны пройти через промежуточные инстанции, причем каждая извлекает из сообщения данные, требуемые для выполнения ее задач, и, если понадобится, снабжает его дополнительной информацией. Соответственно, необходимо, чтобы определенные части сообщений были пригодны для чтения и изменения промежуточными инстанциями. Так, с помощью данных WS Addressing из сообщения можно управлять функциями маршрутизации в пределах ESB.

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

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

ЦЕЛОСТНОСТЬ ДАННЫХ

Подписи, кроме прочего, позволяют проверить целостность отдельных блоков данных и распознать манипуляции с сообщениями (изменение, удаление и добавление данных). Для этого с помощью специального криптографического алгоритма создания хэша (к примеру, SHA1, MD5) рассчитываются контрольные суммы для важных блоков данных (Message Digest). Хэш-алгоритмы — необратимые функции, и восстановление исходных данных по известному значению хэша невозможно. Кроме того, его величина для разных данных не должна совпадать (отсутствие коллизий). Для проверки хеша принимающая сторона еще раз рассчитывает контрольную сумму и сравнивает полученный результат с присланным. Если оба значения идентичны, то целостность данных соблюдена, тогда как в остальных случаях велика вероятность изменений сообщения. Однако этот механизм не позволяет установить, какие именно изменения внесены, поскольку подписи сообщают только о верном или неверном результате.

Принцип подписей базируется на формировании контрольных сумм обеими сторонами (отправителем и получателем), поэтому одинаковая форма представления данных является обязательным условием. К примеру, для того чтобы различное написание XML не привело к разнице контрольных сумм, следует ввести промежуточный этап — нормализацию XML (Canonicalization).

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

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

Детлеф Штурм — сотрудник Beta Systems Software.