Сервисы, идентичность и стандарты

Леонид Черняк

Развитие распределенных сервис-ориентированных архитектур порождает новые проблемы — идентификации субъектов информационного обмена и стандартизации этого процесса.

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

В отечественной литературе термин Identity Management традиционно связывают с идентификацией персонала и переводят, например, как «управление личностными сущностями», делая упор на слово «личностные». Несомненно, идентификация личного состава предприятия является одной из важных задач защиты информации, однако она представляет собой лишь частный случай применения инструментария Identity Management. В данном случае специфика русского языка играет пагубную роль: английское слово identity поневоле ассоциируется с человеческой индивидуальностью, что не совсем точно. Индивидуальными особенностями могут обладать и предметы, а потому подобрать корректный русский аналог довольно сложно. Из множества значений слова identity наиболее близко к предмету Identity Management такое: «уникальный набор характеристик субъекта или объекта», то есть идентичность, подлинность как субъекта, так и объекта (иными словами, ничего «личного»). Да и management — это, конечно, вовсе не «управление», а скорее «оперирование»¹.

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

Автор нескольких научно-популярных бестселлеров Джереми Ривкин в своей книге «Эпоха доступа» (The Age of Access) показал, что принятый прежде в детерминированных монолитных системах анонимный метод передачи транзакций в новых условиях неприменим. В транзакционных и встроенных системах поставщик и преемник данных жестко связаны между собой. Дополнительная идентификация данных не требуется, поскольку обе стороны хорошо знают друг друга и доверяют по определению. Напротив, в сервис-ориентированной экономике, основанной на слабосвязанных системах, входящие в контакт партнеры не имеют прямой априорной связи. Цифровая идентификация ее объектов и субъектов становится острой необходимостью, а соответственно, возрастает роль механизмов Identity Management. Предоставляя и получая сервисы, необходимо быть уверенным в достоверности партнера, связь с которым осуществляется посредством все тех же сервисов через цифровую сеть.

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

Одним из возможных и наиболее принятых сейчас механизмов построения распределенных систем являются технологии на базе Web-сервисов и языка XML. Этот язык используется и как метаязык, служащий для создания новых стандартов. Цель их разработки, в частности, состоит в обеспечении условий для безопасного обмена данными вне границ защищаемого периметра. В условиях устаревания крепостной оборонительной системы приходится говорить не об информационной безопасности домена, а о защите информации в процессе функционирования системы. В рамках этого подхода в центре внимания находятся не обороняемые машины или сети, а передаваемые документы либо другие сведения о действиях, людях или предприятиях. Новая модель обеспечения безопасности намного сложнее старой, поскольку она должна охватывать десятки или даже сотни доменов. Как в таких условиях защититься от несанкционированного доступа к мобильным информационным ресурсам? Сегодняшний ответ таков: с помощью средств Identity Management.

Цифровая идентичность

В Identity Management ключевым понятием является цифровая идентичность (digital identity), которая относит к цифровому представлению набор уникальных качеств объекта или субъекта Identity Management, сетевого субъекта. В качестве сетевого субъекта как предмета цифровой идентификации могут выступать не только человек, группа людей или предприятие, но и программа, устройство или что-то иное, в обычном плане неперсонализированное, что может запросить использование того или иного ресурса. В свою очередь, ресурсом может быть Web-страница, фрагмент данных в СУБД, транзакция по кредитной карте и т.д.

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

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

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

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

Федеративность и Identity Management

Реализация Identity Management в полном объеме потребует новых подходов к интеграции и организации взаимодействия поставщиков и потребителей сервисов. Суть новаций заключается в отношении к границам защищаемого домена. Прежде сервисы, базирующиеся на разных каталогах, были ориентированны на обеспечение идентификации внутри какого-либо домена. С переходом к слабосвязанным архитектурам зона действия идентификации расширяется. Теперь необходимо обеспечивать взаимодействие доменов, поэтому особое значение получают решения на основе Web-сервисов, в которых используются расширяемый язык разметки XML и протокол простого доступа к объектам SOAP. Оба направления, Web-сервисы и Identity Management, параллельно коэволюционируют в соответствии с требованиями рынка и возможностями развивающихся технологий. Web-сервисы позволяют создавать виртуализированные предприятия, а средства Identity Management поддерживают безопасность этих предприятий.

Распространение формата представления XML на все виды данных, а протокола SOAP — практически на все перемещения данных по сети позволяет создать стандартную программную коммуникационную шину, или, как ее принято называть, корпоративную сервисную шину (Enterprise Service Bus, ESB). С помощью общей шины предприятия (иногда она выходит за его пределы) строится сервис-ориентированная архитектура SOA. Сегодня создание таких архитектур, во всяком случае на уровне обсуждения, представляется важнейшей отраслевой задачей. В рамках SOA приложения могут «просто» подключаться к этой шине, используя стандартные средства, и вступать в отношения с другими приложениями. Слово «просто» взято в кавычки не случайно: с появлением возможности создания общих форматов и протоколов обмена данными индустрия начала сталкиваться с проблемами, которые ранее не были очевидны. В частности, возникают серьезные задачи, связанные с передачей семантики.

В последнее время приходит осознание того, что в нынешнем виде технологии и стандарты, поддерживающие SOA, имеют заметные слабости. Так, протоколы Web-сервисов из стека SOAP, UDDI, WSDL и близкие им сосредоточены лишь на синтаксисе обмена и в этом смысле существенно уступают методу удаленного вызова RMI (remote method invocation), реализованному в Java. Вот почему появляется огромное количество новых, в известной мере компенсирующих, стандартов на основе XML, которые описывают отдельные функции распределенных систем. Среди них и стандарты, необходимые для идентификации субъектов/объектов. Они обеспечивают безопасность коммуникаций по шине, поддерживаемой стандартами XML и SOAP.

Идентификационные данные должны сопровождать сведения, передаваемые по шине. Следовательно, в дополнение к слабосвязанной модели взаимодействия приложений на основе Web-сервисов должна быть создана слабосвязанная архитектура идентификации, которая снабжает данные идентификационными сведениями на основе тех же SOAP и XML. Вместо изолированной «замковой» системы идентификации, призванной делать все и вся, нужна распределенная система, обеспечивающая обмен аутентификационными и авторизационными подтверждениями (assertion).

Если система защиты сумеет использовать и генерировать подтверждения об авторизации или аутентификации в стандартном формате, появится возможность создать федеративную модель Identity Management, объединяющую всю распределенную систему. В результате удастся объединить безопасными слабосвязанными соединениями безопасные домены, и это решение тоже можно назвать «федеративным». Стандарты Web-сервисов, спецификации Liberty Alliance и другие стандарты уже обеспечивают для такой федерации техническую, юридическую и бизнес-основу. Федерация окажется особенно полезной при консолидации операций в случае слияния и поглощений предприятий: можно будет не заниматься объединением баз данных, приложений и выполнением других интеграционных действий, а просто наладить работу на позициях федерации, реализовать принцип одной подписи (Single Sign-On, SSO).

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

Понятно, что сочетание сервис-ориентированной архитектуры с федеративным принципом построения систем Identity Management имеет колоссальный потенциал. Однако следует признать, что информационная индустрия только начала двигаться в данном направлении. Технологические преграды на этом пути велики, но ими препятствия не ограничиваются. С технологической точки зрения уже есть почти все необходимые «компоненты» — сервисы каталогов, механизмы аутентификации, авторизационные сервисы. Но эти составляющие активно развиваются и их требуется собрать воедино. А для создания контекста и приемлемых границ Identity Management в национальном и международном масштабе необходимо учитывать правила, нормы и даже законы, которые тоже постоянно эволюционируют. Кроме того, нужно, чтобы и рынок воспринял федеративную модель Identity Management.

Парад стандартов

Что бы ни утверждали аналитики, федеративный подход к Identity Management делает только первые шаги. В достаточной мере не проработаны необходимые для полноценного понимания проблемы вопросы таксономии и семантики. Однако стандарты, требующиеся для создания корпоративной сервисной шины ESB, развиваются, и этот процесс тесно связан с прогрессом всего стека стандартов Web-сервисов. Назовем лишь некоторые из стандартов, используемых в Identity Management.

●     WS-Security поддерживает безопасность протокола SOAP, конфиденциальность и целостность сервисов; согласован с другими средствами авторизации подтверждения, такими как сертификаты X.509, Kerberos и SAML.

●     Security Assertion Markup Language (SAML) служит для обмена подтверждениями об аутентификации и авторизации между доменами (см. www.opensaml.org). В русском языке не установился общепринятый перевод термина SAML; поэтому его трактуют и как «язык разметки утверждений безопасности», и как «язык разметки допуска к информации», и как «язык разметки для инфраструктуры безопасности». Каждый из переводов по-своему корректен, и в совокупности они верно передают смысл. Спецификация Liberty Alliance 1.0 уточняет SAML.

●     XML Access Control Markup Language (XACML), язык разметки управления доступом, является расширением XML для создания конструкций, служащих для автоматизации авторизации и управления доступом к информации. Средства XACML определяют те директивы, которые формируются и передаются для управления доступом.

●     Extensible Rules Markup Language (XrML), язык управления правами собственности в мультимедиа, порожден движением Digital Rights Management и в какой-то мере составляет конкуренцию языку XACML.

●     XML Encryption и XML Digital Signature, стандарты криптографии и цифровой подписи.

●     Service Provisioning Markup Language (SPML) задуман как средство описания вспомогательных данных, необходимых для установления отношений между сервисами. Разрабатывается ассоциацией OASIS для обмена данными между кооперирующимися организациями (см. также www.openspml.org).

●     XML Key Management Specification (XKMS) служит стандартом для инфраструктуры открытых ключей XKISS (XML Key Information Service Specification) и регистрационной спецификации XKRSS (XML Key Registration Service Specification). Спецификация призвана упростить обмен ключами по схеме, предложенной Диффи и Хеллманом.

За исключением языка SAML (он принят практически всеми производителями Web-решений и другими компаниями, специализирующимися на информационной безопасности), перечисленные стандарты еще не получили однозначного признания. Корпорация Microsoft ориентируется на использование Kerberos-билетов (Kerberos ticket) и подтверждений XrML (XrML assertion) в подтверждающих знаках (assertion token) для Passport и TrustBridge, а другие компании в большей степени нацелены на SAML. Достигнута договоренность между IBM, Microsoft и Sun Microsystems о совместной поддержке комбинации SOAP, WS-Security и SAML.

И хотя в последние годы индустрия сделала серьезные шаги к стандартизации в области безопасности Web-сервисов, остается целый рад спорных вопросов, разногласий и опасностей фрагментации. К примеру, языки XACML и XrML имеют точки пересечения, а спецификации WS-Trust WS-Federation, разрабатываемые IBM и Microsoft, не вполне согласованы с SAML и предложениями Liberty Alliance. Нет и полного взаимопонимания между комитетами OASIS, рабочими группами W3C и ведущими производителями.

«Каркас» для Identity Management

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

●     integrity and non-repudiation — целостность и невозможность отказа от авторства посланного сообщения;

●     confidentiality — конфиденциальность;

●     authentication and authorization — аутентификацияиавторизация;

●     identity provisioning — подготовка идентичности;

●     representing and managing authorization policy — представление и управление авторизационной политикой.

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

Целостность и невозможность отказа. XML-подписи. Реализация этих качеств обеспечиваются посредством цифровых XML-подписей (XML-Signature). XML-подпись служит для проверки целостности принятых сообщений и полной либо частичной аутентификации XML-документов. Стандарт цифровой подписи XML-Signature Syntax and Processing разработан консорциумом W3C в 2002 году. Он определяет синтаксис представления цифровых подписей и правила их обработки, а также сервисы, обеспечивающие целостность данных (в том числе документов XML в передаваемом сообщении или вне его), установление подлинности сообщения и подписавшего его лица.

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

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

Рекомендации W3C XML-Signature Syntax and Processing опубликованы по адресу www.w3.org/TR/xmldsig-core/.

Конфиденциальность. XML-криптография. XML-криптография (XML encryption) как процесс шифрования и дешифровки цифрового контента XML заключается в использовании определенных синтаксиса и алгоритмов. В этом отношении она мало чем отличается от традиционной криптографии.

Подобно любому другому передаваемому документу, XML-документ может быть зашифрован, затем передан получателю и им дешифрован. Допустимы и другие методы; например, защита канала с помощью SSL обеспечивает безопасность всех передаваемых сообщений. Но такие методы не вполне применимы, поскольку отдельные части XML-сообщений нередко нужно оставлять открытыми. Скажем, части (или все тело) сообщения SOAP нуждаются в защите, но заголовки должны оставаться открытыми, а информация, необходимая для маршрутизации и других промежуточных действий, — быть доступной.

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

В марте 2002 года рабочая группа W3C XML Encryption Working Group выпустила рекомендации Candidate Recommendation Specification, и вместе с W3C в декабре того же года утвердила их. В рекомендациях определены требования к XML-криптографии (XML Encryption Requirements), синтаксис и правила обработки (XML Encryption Syntax and Processing). Рекомендации XML Encryption Syntax and Processing W3C Recommendation 10 December 2002 можнонайтипоадресуwww.w3.org/TR/2002/ REC-xmlenc-core-20021210/.

Аутентификация и авторизация. Стандарт SAML. К конечном счете SAML является стандартом работы с мандатами. Он определяет, как с помощью XML можно представлять безопасные мандаты и безопасно передавать их из одного домена, представляющего авторизованный сервис, в другой. В сочетании с WS-Security стандарт SAML можно использовать для передачи мандатов с помощью сообщений SOAP. Это происходит так: клиент делает запрос о субъекте в авторитетный орган SAML (SAML authority), и тот возвращает подтверждение об идентичности клиента в определенный безопасный домен. Таким образом, обеспечивается обмен информацией об авторизации и аутентификации.

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

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

Подготовка идентичности. Язык SPML. Средства SAML решают проблему обмена информацией об идентичности между системами. Однако остается открытым вопрос, как подготовить системы к возможности такого обмена. Этот «пробел» заполняет SPML, устанавливающий отношения между запрашивающим авторитетом (Requesting Authority), отвечающим ему поставщиком сервиса (Provisioning Service Provider) и посредником (Provisioning Service Target).

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

Описание и управление политиками безопасности. Язык XACML. Обычно политики безопасности описываются на естественном языке (русском, английском), а затем реализуются в системах вручную. Если политика меняется, изменения нужно, опять же вручную, провести по всем системам. Разработчики языка разметки управления доступом XACML намерены систематизировать и автоматизировать этот процесс, предложив стандартный переносимый способ описания сущностей и их атрибутов. Описание стандарта XACML, принятого в феврале 2006 года, опубликовано на сайте OASIS (www.oasis-open.org).

Идентичность как метасистема

В своей работе «Законы идентичности» Ким Камерон, должность которого в корпорации Microsoft называется «архитектор идентичности», образно описал цели построения системы идентификации (www.identityblog.com/stories/2005/ 05/13/TheLawsOfIdentity.pdf). По его представлению, развитие любой технологии в конечном счете приводит к созданию метасистемы, а скорее, среды, в которой слабая связанность компонентов является естественной. Камерон считает современное аппаратное обеспечение слабосвязанным, поскольку развитие индустрии драйверов обеспечило возможность подключения самых разных устройств без дополнительных настроек.

С этим сталкивается каждый, подключая флэш-память, фотоаппарат или иное устройство. В сетях развитие сокетов и TCP/IP привело к тому, что приложение не должна интересовать реальная физическая природа сети (будь то Token Ring, Ethernet, X.25, frame relay или какое-то еще не изобретенное беспроводное устройство). В конечном счете должна быть создана унифицированная метасистема идентичности, обеспечивающая интерфейс по своей прозрачности, удобству и всеобщности подобный интерфейсам, поддерживаемым драйверами периферии или сетевыми сокетами.