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

На значительный потенциал служб Web для интеграции приложений как внутри компании, так и при организации удаленного взаимодействия указывалось уже не раз. Однако многих пользователей до сих пор смущает необъятность технологий и большое количество стандартов. К этому добавляются сомнения в безопасности, поскольку передача по «туннелям HTTP» сообщений SOAP, с которыми используются компоненты служб Web, исключает возможность применения в качестве механизмов защиты традиционных брандмауэров, если те разрешают передачу трафика НТТР. К тому же стандарт SOAP сам по себе не предусматривает механизмов защиты. Не чрезмерна ли открытость служб Web для задач интеграции?

СТАНДАРТЫ БЕЗОПАСНОСТИ

Усилия по обеспечению безопасности в контексте XML и служб Web предпринимаются относительно давно. Но какая технология существует исключительно на бумаге, а какая действительно доступна? И как с их помощью на практике защитить свои службы Web? Прежде чем ответить на эти вопросы, необходимо пояснить некоторые особенности совместной работы важнейших стандартов безопасности WS Security: языка разметки утверждений безопасности (Security Assertion Markup Language, SAML) и цифровой подписи XML. В качестве исходного пункта возьмем несколько упрощенное сообщение (см. Листинг 1), представляющее собой вызов функции newOrder с тремя параметрами для осуществления нового заказа. При его отправке службе Web атакам может подвергнуться как само сообщение, так и принимающая его служба: это может быть подслушивание, фальсификация, изменение маршрута, уничтожение сообщения или передача собственного сообщения неавторизованным отправителем.

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

На первый из этих вопросов отвечает язык разметки утверждений безопасности — стандарт XML от консорциума OASIS, в терминологии которого информация о безопасности называется «утверждение» (Assertion). Если отправитель, к примеру, пытается зарегистрироваться в службе аутентификации, она может выдать утверждение аутентификации (Authentication Assertion), как показано на Листинг 2.

Подобное утверждение свидетельствует о том, что тот, кто его выдал, аутентифицировал указанного субъекта. Все службы обеспечения безопасности могут принимать это утверждение как доказательство идентичности, если они относятся к выдавшей его стороне с соответствующей степенью доверия. Привязка утверждения к сообщению SOAP и, кроме того, обеспечение его целостности и аутентичности реализуются посредством цифровой подписи. На вопросы, как и куда они прикрепляются и где в сообщении размещается утверждение, отвечают следующие два стандарта безопасности: спецификация безопасности служб Web (Web Services Security Specification, WS-S) от OASIS и стандарт цифровой подписи XML от W3C.

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

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

БЕЗОПАСНОСТЬ НА БАЗЕ ПЛАТФОРМЫ

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

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

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

Кроме того, подобная архитектура требует, чтобы отправители сообщений предъявляли все необходимые мандаты в предусмотренной форме.

БЕЗОПАСНОСТЬ НА БАЗЕ ПРИЛОЖЕНИЙ

Производители платформ часто предлагают дополнительные программные интерфейсы приложений, с помощью которых реализации сервисов самостоятельно осуществляют определенную проверку безопасности. Microsoft, к примеру, для своей платформы DotNet поставляет библиотеки «расширений служб Web» (Web Services Enhancements), они позволяют проверять цифровые подписи XML, а потому приложения сами отвечают за необходимую защиту. Недостатки этого метода — высокие затраты на разработку и отсутствие осознанного отношения у разработчиков к проблемам безопасности, что случается довольно часто. Кроме того, неудачно и объединение функционального пользовательского кода с запросами к программному интерфейсу приложений обеспечения безопасности, т. е. включение правил безопасности в код.

ШЛЮЗЫ БЕЗОПАСНОСТИ ДЛЯ СЛУЖБ WEB

Шлюзы безопасности выполняют функции защиты на уровне протокола еще до того, как сообщение достигнет приложений. Шлюзы SOAP анализируют формат и содержимое сообщений SOAP с учетом названных стандартов безопасности и предлагают полную функциональность АААА (аутентификация, авторизация, аудит, администрирование) при прозрачной интеграции. По функциональному охвату они намного опередили брандмауэры с фильтрацией пакетов, которые проводят лишь простейшую проверку формата. Функции обеспечения безопасности корпоративных брандмауэров могут быть дополнены на прикладном уровне аутентификацией на базе SAML, проверкой схем XML, фильтрацией сообщений SOAP с учетом содержимого, а также ролевым контролем доступа. Одновременно централизованное управление правилами распространяется на платформы всех производителей, что заметно упрощает применение единой политики.

На Рисунке 1 показано, как комбинируются подобные шлюзы со стороны отправителя и получателя для достижения большей безопасности сквозных соединений между конечными узлами или только шлюзами. В одном из таких сценариев шлюз со стороны отправителя на лету вставляет в исходящее сообщение необходимую информацию о безопасности в стандартном синтаксисе. Если шлюз на стороне получателя заслуживает доверия, он может быть признан, к примеру, уполномоченным по аутентификации. Кроме того, исходящий шлюз в состоянии проводить «отображение мандатов»: в частности, преобразовывать роли внутренней корпоративной инфраструктуры в известную получателю ролевую систему.

Рисунок 1. Шлюзы обеспечения безопасности SOAP предназначены для защиты служб Web.

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

ЗАКЛЮЧЕНИЕ

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

Геральд Брозе — менеджер Xtradyne Technologies. С ним можно связаться по адресу: gg@lanline.awi.de.

? AWi Verlag