XML и безопасность

Документы XML, безусловно, следует ограждать от любопытных глаз и «дурного» влияния Internet, однако язык XML сам может стать средством обеспечения безопасности для многих приложений.

Любой знаток сериала Star Trek подтвердит, что универсальные трансляторы — непременный атрибут общения для существ из разных галактик, каждый из которых говорит на своем языке. В мире Internet намечается тенденция к созданию аналогичного коммуникационного механизма. Однако в киберпространстве такие виды деятельности, как прикладное программирование и обработка приложений, должны регламентироваться весьма специфическими требованиями — этим и объясняется появление расширяемого языка разметки (Extensible Markup Lan-guage, XML).

XML предлагает структурированный метод добавления контекста в совокупность данных, чтобы и он мог совместно использоваться различными приложениями. Если в старых системах для пакетной передачи файлов применялся текстовый формат ASCII, то системы XML поддерживают так называемые «переходные наборы данных» с заранее определенными записями, обработка которых осуществляется в режиме реального времени с помощью очередей сообщений и серверов приложений.

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

XML очень удобно использовать для сообщений о сделках на рынке B2B с участием таких организаций, как банки, поставщики автозапчастей, сети розничных магазинов и т. п. Но и здесь бреши в системе безопасности могут привести к плачевным результатам.

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

ИЗ ИСТОРИИ XML

Спецификация XML была разработана на базе появившегося еще в 80-х гг. структурированного обобщенного языка разметки (Structured Generalized Markup Language, SGML). В 1996 г. специалисты под эгидой консорциума W3C (World Wide Web Consortium) организовали рабочую группу, перед которой была поставлена задача создания SGML-подобного стандарта для Internet, в конечном итоге получившего имя XML.

Спецификации XML вводят «базовый» язык, который описывает синтаксис специализированных языков разметки, формулирует требования к стилям, используемым при представлении и преобразовании данных для тех или иных целей, и предлагает возможности логического связывания документов с источниками данных. (Подробнее об основах XML см. статью Дж. Эйнджела «XML: время пришло» в ноябрьском номере LAN за 1999 г.)

XML отличается от HTML прежде всего тем, что позволяет поставщикам информации определять свои собственные теги и элементы (логические структуры данных в составе документов XML), поддерживает вложенность и отношение «родительский/дочерний» (дочерний элемент вложен в другой, родительский, элемент), а также определяет правила грамматики, чтобы ими можно было пользоваться. У HTML есть собственная спецификация на базе XML, под названием XHTML.

Поскольку XML в браузерах Web поддерживается в ограниченном объеме и к тому же на страницах Web широко используются объекты Java и ActiveX, пользователи не заметят особых изменений во внешнем виде своих документов, когда XML станет применяться по-настоящему широко. Провайдеры данных будут по-прежнему преобразовывать свою информацию в формат XHTML для представления пользователю. Однако истинная мощь XML проявится — и уже скоро — там, где данные передаются на обработку в одну или несколько баз данных. Источники и адресаты данных могут обмениваться информацией, потому что XML действует подобно «динамическому словарю данных», предоставляя данные, которые содержат элементы и атрибуты или ссылаются на них.

БЕЗОПАСНОСТЬ ЭКЗЕМПЛЯРОВ XML

Главные достоинства языка XML — в его гибкости и расширяемости, в сочетании с удобной семантикой и структурой. Однако, как уже упоминалось выше, эти свойства могут обернуться серьезными проблемами безопасности.

Экземпляры объектов, или фрагменты, XML могут представлять данные из нескольких источников. Компоненты экземпляра XML легко сравнить с ингредиентами, используемыми при выпечке, — вы должны смешивать их в том или ином соотношении так, как написано в рецепте. Эти ингредиенты, как правило, разбросаны по всей «кухне» Internet. Такое рассредоточение информации может вызвать трудности с проверкой ее источников. Если не предложить надежный метод проверки источника данных и правильности самой информации, какой-нибудь хакер может подставить ложные данные в транзакцию или процедуру преобразования данных.

Экземпляры XML нередко используют ссылки на ресурсы, превращая их в нечто эфемерное. Когда вся рецептура определена, XML предлагает на выбор два варианта: вы можете «испечь торт», собрав и представив всю информацию XML в экземпляре XML, либо просто «сделать снимок торта», объединив указатели и ссылки на необходимую информацию.

В обоих случаях пользователь увидит один и тот же конечный результат. Полностью укомплектованный экземпляр XML может быть представлен таким образом, что внутри него не будет никаких реальных данных — только унифицированные идентификаторы ресурсов (Uniform Resource Identifiers, URI), указывающие на конкретные элементы. Такая возможность заставляет более широко толковать правило, гласящее, что «надежность системы безопасности определяется надежностью ее слабейшего звена», — может оказаться, что вы обладаете ограниченным контролем в отношении некоторой части данных, но вынуждены тем не менее полагаться на обслуживающие их механизмы безопасности. Однако проверка источника по-прежнему остается на повестке дня, и любая потребность в долгосрочной архивации еще более усугубляет эту проблему. Приложение должно гарантировать, что данные вместе со своим контекстом собраны и хранятся таким образом, чтобы их можно было проверить и годы спустя.

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

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

УСИЛИЯ ПО ОБЕСПЕЧЕНИЮ БЕЗОПАСНОСТИ XML

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

Другие специалисты пытаются на базе XML расширить функции системы безопасности. Они группируются вокруг технического комитета по службам безопасности в составе Организации по развитию стандартов структурирования информации (Organization for the Advancement of Structured Information Standards, OASIS); в настоящее время этот комитет работает над языком разметки заявлений системы безопасности (Security Assertion Markup Language, SAML). Среди других инициатив отметим усилия компании Verisign в сфере XML: в частности, спецификации управления ключами XML (XML Key Management Specification, XKMS) и спецификация служб заявлений о доверии для XML (XML Trust Assertion Services Specification, XTASS), которые подробнее рассматриваются ниже.

БЕЗОПАСНОСТЬ ДОКУМЕНТОВ XML

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

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

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

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

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

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

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

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

ПОДПИСИ XML

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

Спецификация XML Signature (подпись XML) определяет синтаксис, необходимый для подписывания всего экземпляра XML или его части. Язык XML, несмотря на все свои богатые возможности и чрезвычайную гибкость, не вполне удобен для применения цифровых подписей, где из-за пробела, стоящего не на месте, может получиться совершенно новое значение подписи, не поддающееся проверке. Чтобы избавиться от этих проблем, была предложена концепция канонизации (XML-C14N), описанная в предварительной спецификации W3C под названием Canonical XML (канонический XML). Она использует заранее определенный набор правил обработки, по которым можно структурировать экземпляр для приведения его к простейшей форме. Такая стандартизация позволила бы гарантировать, что экземпляры всякий раз будут структурироваться одинаково, и это предотвратило бы возможную путаницу с цифровыми подписями вследствие стилистических различий, например иначе поставленными пробелами. Заметьте, что даже при использовании C14N необходимо указать используемый набор правил или метод для обеспечения дополнительных гарантий.

Рисунок 1. Элементы подписи XML.

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

• Метод канонизации определяет конкретный набор правил C14N для упрощения и структурирования экземпляра XML до составления подписи. Эти сведения обеспечивают надлежащий вид подписываемых данных, чтобы алгоритм проверки дал положительный результат, если содержательные данные не были изменены.
• Метод подписи определяет алгоритм подписи дайджеста сообщения. Дайджест сообщения — это уникальная символьная строка фиксированного размера, она является результатом обработки данных с помощью односторонней хэш-функции, задаваемой методом дайджеста. Цифровая подпись удостоверяет личность или процесс, подписывающий данные, тем самым обеспечивая аутентификацию и защиту от дезавуирования авторства.
• Метод дайджеста — алгоритм составления дайджеста сообщения, подписываемого с помощью заданного метода подписи. Задание определенного метода дайджеста гарантирует обработку данных одним и тем же способом.
• Значение дайджеста — собственно дайджест сообщения, т. е. строка фиксированной длины, выдаваемая в результате обработки данных с помощью алгоритма дайджеста. Такая строка является уникальной и необратимой: ее практически невозможно получить из другого содержимого, как и невозможно воссоздать по ней исходные данные. Это как бы «отпечаток пальцев» для подписываемых данных; положительный результат сравнения значений дайджеста гарантирует целостность содержимого.
• Справочная информация — некоторые сведения о подписываемых данных. В частности, здесь может быть указан тип подписанных данных, если это не данные XML.
• Свойства подписи дополняют подпись определенным контекстом, в который вносятся отметка времени или порядковый номер. Такие элементы могут сами быть подписаны и включены в справочную информацию относительно самой подписи.
• Манифест группирует несколько ссылок и создает общее значение дайджеста для подписей одного или нескольких пользователей. Это, например, позволяет супервизору подтвердить несколько индивидуально подписанных транзакций в совокупности, не выделяя каждую транзакцию в отдельности.

Процесс «базовой генерации» подписи экземпляра XML начинается с канонизации, т. е. упрощения структуры данных. Дальнейшие действия аналогичны стандартному процессу добавления цифровой подписи: для данных создается значение дайджеста с помощью заданного метода. Затем это значение подписывается закрытым ключом субъекта.

Для проверки подписи в спецификации XML Signature предусмотрен процесс «базовой проверки подлинности», состоящий из двух шагов. Вначале проверяется сама подпись, чтобы обеспечить аутентификацию ее владельца и предотвратить отказ от авторства. Затем происходит проверка значения (или значений) дайджеста, чтобы убедиться, что данные не изменились, и подтверждается целостность содержимого. Спецификация XML Signature — результат совместной работы IETF и W3C. В настоящее время она имеет статус предлагаемой рекомендации W3C и предлагаемого стандарта IETF; в мае 2001 г. она должна была получить статус рекомендации W3C и предварительного стандарта IETF.

ШИФРОВАНИЕ XML

Ключевое значение для безопасности данных XML имеет корректное шифрование, особенно если речь идет об особо секретных данных, передаваемых через такие незащищенные сети, как Internet. Итак, переходим к спецификации XML Encryption.

Шифрование нередко представляют как самодостаточную операцию — просто данные шифруются на одном конце и затем дешифруются на другом. Однако на самом деле для ее успешного выполнения требуется гораздо больше информации. В экземпляре XML в связи с этим выделяются четыре основных типа данных.

• Шифрованное содержимое — собственно зашифрованные данные или ссылка на их местоположение. Разнообразие подлежащих шифрованию типов данных и методов их логической организации практически ничем не ограничено.
• Нешифруемое содержимое — прочая информация, относящаяся к контексту взаимодействия, но по какой-то причине не подлежащая шифрованию: например, по соображениям быстродействия или потому, что считается не настолько секретной, чтобы ее стоило шифровать.
• Информация о ключах — сведения (или указатели на сведения) о ключах, с помощью которых выполняется шифрование и, соответственно, дешифрование. Они могут храниться в другом месте и заменяться в экземпляре XML на ссылку URL.
• Информация о получателях — сведения об одном или нескольких предполагаемых получателях зашифрованных данных. Это необязательные параметры, так как возможны ситуации, когда соответствующая информация о получателях уже известна или предоставляется отдельно, как, например, при общении партнеров по бизнесу, уже связанных договорными отношениями.

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

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

XML РАСШИРЯЕТ ФУНКЦИИ ЗАЩИТЫ

Напомним, что у безопасности XML есть обратная сторона: использование возможностей XML позволяет обеспечить высокий уровень защиты для широкого спектра приложений и процессов. SAML — один из множества языков разметки, которые сейчас создаются на основе синтаксиса и семантики XML в рамках технического комитета по службам на базе безопасности XML, входящего в организацию OASIS. Данный язык использует XML для расширения функций безопасности, относящихся к аутентификации и авторизации. Главные задачи SAML — построить базовые конструкции, необходимые для обмена мандатами, определить протоколы для запросов, ответов и основных правил, а также описать связи SAML с другими протоколами, такими, как HTTP, SOAP (Simple Object Access Protocol) и ebXML. Язык SAML позволяет совместно использовать одну и ту же информацию о мандатах на различных узлах Web или приложениях, действуя подобно службе CredEx: эти данные доставляются в режиме реального времени — в любое время и в любое место.

SAML представляет собой попытку объединить две разработки — спецификацию аутентификации и авторизации в XML (Authentication and Authorization in XML, AuthXML) компании Securant и язык разметки для служб безопасности (Security Services Markup Language, S2ML) компании Netegrity. Эти две спецификации, появившиеся в конце 2000 г., были созданы, чтобы определить условия и цели применения XML для выполнения функций управления доступом в системах безопасности.

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

ПРИМЕРЫ ПРИМЕНЕНИЯ

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

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

ДРУГИЕ ЯЗЫКИ БЕЗОПАСНОСТИ

Еще около полдюжины языков находятся сейчас на ранних стадиях разработки и поддержки. Так, спецификация XKMS (XML Key Management System), продвигаемая компанией Verisign, обеспечивает регистрацию, поиск и проверку достоверности ключей, используемых для целей безопасности. Другая специфика-ция, XTASS (XML Trust Assertion Service Specification), предлагает стандартный метод составления заявлений о доверии, необходимых при установлении отношений делового партнерства (эту спецификацию также вводит Verisign). Третий язык, XACML (eXtensible Access Control Markup Language), позволяет создавать правила управления доступом и применять их к экземплярам XML. Эта спецификация обсуждается в техническом комитете SAML, но развивается преимущественно в направлении сближения с XML Signature и XML Encryption.

Работа над упомянутыми стандартами идет непрерывно и обещает расширить возможности взаимодействия служб безопасности в среде Internet.

XML, ВЕЛИКИЙ И МОГУЧИЙ

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

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

Ресурсы Internet

Подробнее о безопасности XML можно прочитать на следующих узлах Web.

Информация о деятельности консорциума W3C (World Wide Web Consortium) в области XML размещена по адресу: http://www.xml.com/pub/a/2001/01/03/w3c.html.

Содержание спецификации XML с комментариями см. по адресу: http://www.xml.com/axml/axml.html.

Предварительный проект стандарта SAML (Security Assertion Markup Language) находится по адресу: http://www.oasis-open.org/committees/security/docs/draft-sstc-saml-01.pdf/.

Сведения о спецификациях XKMS (XML Key Management Specification) и XTASS (XML Trust Assertion Services Specification) можно узнать по адресу: http://www.xmltrustcenter.org.