Отсутствие требуемого уровня безопасности — главное препятствие на пути новых технологий
Марк Джонс: «На практике еще никому не удалось предложить совершенный способ организации B2B-коммуникаций»

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

Современные Web-службы имеют стандартные интерфейсы на базе протокола Simple Object Access Protocol (SOAP), утвержденного консорциумом World Wide Web Consortium. Но поскольку SOAP не обеспечивает требуемой степени безопасности, Web-службы оказываются непригодными для электронной коммерции класса B2B и интеграции платформ, используемых разными партнерами.

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

«Отсутствие требуемого уровня безопасности я бы сегодня назвал главным препятствием на пути дальнейшего распространения новых технологий», — отметил вице-президент ассоциации National Student Clearinghouse Марк Джонс. NSC — некоммерческая организация, которая занимается распределением выпускников вузов и предоставляет услуги контроля качества их подготовки работодателям и представителям бизнеса. Ассоциация получает информацию из первых рук и в ближайшее время планирует развернуть Web-службы, которые помогут миллионам ее потенциальных партнеров упростить процедуру сбора и распространения данных.

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

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

И в этом Джонс не одинок. Обзоры Hurwitz Group и ZapThink показывают, что невыполнение требований, предъявляемых к безопасности, сдерживает дальнейшее распространение корпоративных Web-служб.

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

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

В ожидании утверждения стандартов и появления соответствующих расширений многие ограничивают рамки использования Web-служб проектами сетей intranet или же сами начинают заниматься обеспечением безопасности и импровизировать, когда информация Web-служб пересекает границы компании. Подобная импровизация предусматривает обеспечение безопасности своими силами, использование при реализации проектов спецификаций уже устоявшихся стандартов Internet или продуктов собственной разработки, подписание с внешними компаниями договоров на предоставление ими услуг обеспечения безопасности. По словам ИТ-менеджера NSC Дуга Фолка, двигаться по лабиринту стандартов в нужном направлении ему помогает инструментарий компании Flamenco Networks, который обеспечивает аутентификацию, авторизацию и организацию управления с помощью Web-служб.

«Мы, вероятно, могли бы начать с примитивного шифрования и принять за основу модель, в которой будет применяться протокол HTTP-S и средства аутентификации, анализирующие идентификатор и пароль пользователя, — заметил Фолк. — Все это обеспечило бы работоспособность на тот период, пока клиенты не предъявят новые требования и существующая модель перестанет их удовлетворять».

На подходе

Между тем группы, занимающиеся стандартами XML, тоже не сидят без дела. Internet Engineering Task Force (IETF), Organization for the Advancement of Structured Information Standards (OASIS) и W3C занимаются проектированием или уже завершили разработку по крайней мере 13 протоколов безопасности, которые могут оказаться полезными для Web-служб. Эти протоколы включают в себя расширения для шифрования, цифровых подписей, схем строгого выполнения обязательств и давно обещанные средства адаптации существующих технологий (например, Kerberos) к особенностям Web-служб.

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

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

Первым шагом к кооперации стало появление спецификаций WS-Security, представленных IBM, Microsoft и VeriSign в апреле и переданных ими в августе на рассмотрение OASIS. Ядро технологии WS-Security, позволяющей Web-службам передавать безопасные и снабженные электронной подписью сообщения SOAP, поддерживает спецификации W3C XML Encryption и XML Digital Signature и добавляет шесть других расширений для функций, описывающих политику безопасности, доверительные отношения, параметры объединения и авторизации.

Помимо технологий XML Digital Signature и XML Encryption, консорциум W3C разрабатывает архитектуры XML Key Management Specification и Web Service Architecture, которые изначально включают в себя средства обеспечения безопасности. Ассоциация OASIS занимается проектированием спецификаций языка Security Assertion Markup Language, предназначенного для аутентификации и авторизации, форматов Extensible Access Control Markup Language, Service Provisioning Markup Language и XML Common Biometric Format.

IETF работает над централизацией и стандартизацией обеспечения безопасности на транспортном уровне, на котором OASIS и W3C проектируют протоколы безопасности приложений.

«Необходимо разработать концептуальную модель ?стека безопасности?, которая бы иллюстрировала, в чем протоколы могут опираться друг на друга, а не соперничать, — заметила эксперт по безопасности, работающая со средствами OASIS и W3C, Энн Томас Мэйнс. — Элементы верхнего уровня будут здесь иметь преимущество над элементами нижнего уровня. Таким образом, у WS-Security сохраняется зависимость от XML Digital Signature, XML Encryption, SAML и SOAP».

Давление корпоративного рынка

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

«Мы используем для решения этой задачи стандартный межсетевой экран с шифрованием на уровне SSL и шлюз Web-служб собственной разработки, который предназначен для проведения аутентификации и авторизации», — отметил Гереон Фредриксон, начальник отдела технологических продуктов компании Galileo International, предоставляющей информационные услуги организациям транспортной отрасли.

Пока в Galileo ждут появления стандартов, обеспечивающих требуемую интероперабельность, производители (в том числе компании BEA Systems, Cape Clear, Flamenco, Grand Central, IBM, Iona, Kenamea, Microsoft, Oracle, Sonic, Sun Microsystems, Systinet и Tibco) продолжают работы над программным обеспечением промежуточного слоя, повышающим безопасность Web-служб.

Специалисты компании Galileo, представившей в августе свою первую Web-службу, считают, что никаких активных действий до прояснения ситуации со стандартами предпринимать не следует. «Колебания в ту или иную сторону неизбежно будут происходить до тех пор, пока положение в этой области не стабилизируется, — отметил Фредриксон. — А когда это произойдет, станет ясно, где можно использовать данные технологии».

Некоторые признаки стабилизации уже видны — спецификации WS-Security приняты за точку отсчета. Они определяют, каким образом должно осуществляться безопасное взаимодействие между Web-службами и как интегрировать протоколы безопасности с SOAP. В соответствии со спецификациями WS-Security информация системы безопасности добавляется к заголовкам сообщений SOAP с помощью технологий XML Encryption, XML Digital Signatures и протоколов идентификации (таких, как SAML или Kerberos).

«Мы находимся лишь в самом начале трудного пути к обеспечению идеальной безопасности Web-служб, а именно такой она и должна быть, — подчеркнул директор IBM по разработке стратегии стандартов организации электронного бизнеса Боб Сатор. — Но с появлением WS-Security можно сказать, что первый камень в фундамент этого здания уже заложен».

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

В августе в IBM и Microsoft приняли решение объединить спецификации Web Services Flow Language и XLANG с целью создания нового языка Business Process Execution Language for Web Services.

Этот язык поможет пользователям определять набор Web-служб и порядок, в котором они должны выполняться в рамках бизнес-процесса, например оформления заказа. Аналогичные усилия предпринимает корпорация Sun, занимающаяся проектированием интерфейса Web Services Choreography Interface и протоколов для спецификаций OASIS, обеспечивающих ведение электронного бизнеса в формате XML.

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