Непростое путешествие по проблемам безопасности в SOA

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

Перевесит ли выгода риски, связанные с открытием доступа к внутренним сервисам через web? К тому же проблемы взаимодействия осложняются незрелостью стандартов безопасности SOA. Чтобы ограничить возможности крупной сети web-сервисов, включающей несколько предприятий, все должны прийти к соглашению по технологиям и даже по политике безопасности: бессмысленно требовать от своих сотрудников использовать биометрические параметры и физические метки, если сотрудники вашего бизнес-партнера заходят в систему посредством простых паролей.

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

Например, Web-сервисы, видимые в Интернете, используют брандмауэры SOAP/XML, также называемые шлюзом защиты SOA. Однако эта категория продукта на сегодня исчезает, благодаря продолжающемуся расширению технологий и SOA, в частности.
 

Между тем, стоит вопрос: какое решение использовать, учитывая, что функциональность брандмауэра XML реализуется в виде специализированных устройств или программ на Web-сервере? Успешность применения даже базовых решений зависит от масштаба и предсказуемости роста самих web-сервисов каждого конкретного предприятия. А технологии виртуализации только еще больше все усложняют.


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

Самые большие противоречия вызывает управление уровнем полномочий - сложный механизм, гарантирующий, что пользователь или процесс, вошедший в систему одного из предприятий, имеет полномочия использовать те же функции в системе партнера. При этом встречаются два несовместимых стандарта, предлагающие практически одну и ту же функциональность. Первый – язык разметки, предусматривающий защиту данных SAML ( icmm.ru/PH/H8269QR2.doc xml.com/lpt/a/1525 ) поддерживается почти всеми за исключением Microsoft. Они предпочитают более новый стандарт - WS-Federation ( schemas.xmlsoap.org/ws/2003/07/secext/ ), который более тесно связан с другими стандартами web-сервисов. Хотя оба стандарта используют XML, они - несовместимы. И это означает, что предприятия с web-сервисами общего доступа должны или поддерживать оба стандарта, или обеспечить, чтобы все их бизнес-партнеры, использующие защищенные web-сервисы, выбирали один и тот же стандарт.

Стало немного яснее?

Проблемы разных форматов обмена данными

Все технологии защиты web-сервисов основаны на XML Encryption и XML Signature. Это
стандарты W3C для вставки зашифрованных данных и электронных подписей в XML-документы. Так как XML Encryption не обязательно зашифровывает сообщение целиком, что позволяет ИТ подходить избирательно: может быть закодирована конфиденциальная информация, например, такая как данные паспортов или номера кредитных карт, а менее важные данные и мета данные SOA посылаются в открытом виде. Разные части документа так же могут быть зашифрованы с использованием разных ключей, чтобы их могли прочитать только определенные получатели.

Обратная сторона: размещение зашифрованных данных в сообщениях XML может вызвать проблемы взаимодействия, потому что участники должны заранее прийти к соглашению по некоторым вопросам: где в сообщении будут размещены зашифрованные данные, какие элементы будут зашифрованы и, как будет происходить обмен ключами. Чтобы помочь в этих вопросах, Oasis (Organization for the Advancement of Structured Information Standards,
Организация по продвижению стандартов структурированной информации, oasis-open.org/ ) создала WS-Security - стандарт для применения в Web-сервисах XML Security и XML Encryption.

Наиболее зрелым из WS-* стандартов, поддерживаемых почти всеми Web-сервисами и поставщиками SOA, является WS-Security. Слабое место этого стандарта в том, что, как и всем WS-* стандартам, WS-Security требуется SOAP (протокол обмена структурированными сообщениями в распределённой вычислительной среде (ru.wikipedia.org/wiki/SOAP ). Не нуждаются в нем только те, кто работает с Web-сервисами на технологии REST (стиль передачи репрезентативного состояния), - это способ описания XML Web-сервисов, которые не используют SOAP.

Основной довод, почему использование REST предпочтительнее, чем SOAP – это простота, и большинство пользователей REST остаются верны SSL. Так как REST требует HTTP, и его часто используют для связи «точка-точка», в большинстве случаев достаточно каналов SSL. Предприятия, которые хотят применять защиту на уровне сообщений в REST, будут вынуждены создавать собственные протоколы и форматы данных.

Большинству предприятий сложно реализовать объединение всех бизнес-партнеров и разработку своего безопасного формата XML для REST, поэтому весомым доводом в пользу SOAP может послужить существование WS-Security. Однако крупные поставщики Web-сервисов, включая Amazon и Google, успешно разработали собственные способы ограничить возможности REST, используя маркеры доступа, которые известны только нужной группе лиц. Это очень распространено среди пользователей: Amazon также предлагал интерфейс SOAP с WS-Security, но выяснили, что клиенты предпочитают REST в отношении: пять к одному. Большая часть пользователей Amazon использует только доступ к сервисам Amazon (вся архитектура SOA не нужна), а значит, не требуется и использовать сложный SOAP.
 

Объединенные данные идентификации

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

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

Исключением является только объединение данных идентификации, где конкурируют относительно новые WS-Federation и WS-Trust с SAML 2.0, утвержденным стандартом, также опубликованным Oasis. Объединенные данные идентификации направлены на то, чтобы обеспечить единый вход отдельной проверкой прав доступа, запущенной из того ресурса, куда был запрошен доступ.

Пользователь обращается к системе доступа, ему выдается ключ, который он может затем использовать для доступа к различным ресурсам. Ключ в SAML называется «утверждением», а в WS-Trust он называется «маркером». Он похож на цифровой сертификат, который подтверждает личность пользователя и добавляет информацию о способе и времени проверки прав доступа. SAML покрывает весь процесс SSO, в то время как WS-* делят процесс на два стандарта: WS-Trust выполняет начальную проверку полномочий и выдает маркер, а затем WS-Federation использует маркеры для доступа к другим ресурсам.

Основное отличие в том, что SAML использует XML Encryption и XML Signature напрямую, что означает возможность работы с REST, а для WS-Federation требуется SOAP. У SAML также есть большой парк установленного оборудования, хотя это многого не стоит, потому что такой авторитет, как Microsoft, стал на сторону WS-Federation и заявил, что не будет поддерживать SAML.

В отличие от других баталий среди стандартов, это не просто дело Microsoft против кого-то еще. Microsoft разработал WS-Federation вместе с IBM, который также покровительствует SAML, и все остальные поставщики в лагере SAML обещали, что будут поддерживать WS-Federation, если на него будет спрос. В долгосрочном периоде, вероятно, будут использоваться оба стандарта: WS-Federation в Microsoft и среде SOAP, а SAML в Web-сервисах REST.

Где разместить фаейрвол?

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

В результате компании, публикующие Web-сервисы в Интернете, традиционно использовали шлюзы защиты, приложения, которые могут читать и понимать документы уровня приложений, отражая потенциальные атаки. Такие устройства обычно называют «XML файерволами», хотя они подразумевают больше, чем XML. Web-сервис, использующий REST, может зашифровать некоторую информацию внутри заголовков HTTP или URL, в то время, как разработчики RIA на основе браузеров часто считают XML слишком раздутым и предпочитают JSON (текстовый формат обмена данными, основанный на JavaScript) или плоский текст.

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

Если не говорить о внешних связях, то необходимость проходить через файервол – это большой минус.
В дополнение, шлюз защиты не может эффективно проверять документ, прежде не расшифровав его, поэтому большая их часть также работает с шифрованием, опознанием пользователя, используя SSL, WS-Security или SAML. Глубокая проверка и понимание XML, требуемые, чтобы распознавать атаки, делает шлюзы защиты также полезными для преобразования XML и маршрутизации, и часто они для этого подходят лучше, чем программное обеспечение по управлению, благодаря специализированному аппаратному обеспечению или XML-акселератору.

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



Из начального множества поставщиков шлюзов защиты сейчас нарасхват идут четыре: Sarvega от Intel, NetScaler от Citrix, DataPower от IBM, и Reactivity от Cisco Systems. За исключением Intel, который использует технологию Sarvega, чтобы помочь другим поставщикам построить программное обеспечение XML или аппаратное обеспечение на основе стандартного процессора, а не узкоспециализированных интегральных схем. Все остальные занимаются продажей шлюзов защиты. Но они используют продукты в иных направлениях.

Аппаратное обеспечение NetScaler Citrix объединяет в себе файервол XML и клиентскую часть приложения или функциональность AFE. Это то, что Cisco планирует сделать, объединяя Reactivity с линейкой продуктов Application Control Engine. AFE находятся также на границе сети и ускоряют SSL. Это объединение имеет большой смысл, как для клиента, так и для поставщиков, которые хотят выйти на новые рынки. F5 уже объявили, что они добавят файервол XML, - свою внутреннюю разработку - и конкуренты, вероятно, последуют примеру.

Другие независимые поставщики шлюзов защиты - Layer 7, Vordel и Xtradyne, движутся в противоположном направлении - в сторону программного обеспечения и виртуализации. Vordel и Xtradyne всегда распространяли свои шлюзы защиты как программное обеспечение, предназначенное для установки на специальных blade-серверах. Они включают в себя виртуальное аппаратное обеспечение, Layer 7 и Vordel уже продают версии своего ПО, которое работает под VMware.

Проблемы виртуализации

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

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

Шлюзы защиты сливаются с программным обеспечением по управлению Web-сервисами, т.к. они содержат много пересекающейся информации. И DataPower, и Reactivity вышли на рынок управления до того, как их купили, и, по меньшей мере, еще один поставщик файерволов хочет поступить так же. Поставщики ПО для управления еще не пытались сопротивляться, добавляя полные XML файерволы, в основном, потому что их ПО предназначено для запуска во всей SOA, а не на границе.

Из-за своей популярности в шлюзах защиты повсеместно распространяется акселератор SSL. Даже поставщики виртуального аппаратного обеспечения поддерживают его с помощью акселератора SSL. Акселерация XML встречается намного реже, только у Layer 7, Cisco и IBM в решениях есть специальные XML чипы. IBM разработал свой собственный, Cisco и Layer 7 доверились чипам Tarari. Это произошло частично из-за того, что Intel использует технологию Sarvega. Layer 7 полагает, что рынок аппаратного обеспечения будет постепенно переходить к программному обеспечению, но в основном из-за того, что на акселераторы для приложений еще нет достаточного спроса.

Акселерация XML крайне полезна для Web-сервисов, которые передают длинные XML-документы, такие как сообщения SOAP или SAML. А в сервисах, разработанных для поддержки приложений на основе браузера, такая акселерация почти не используется, так как эти сервисы передают за каждую сессию мало данных, может только один элемент XML или объект JSON, заключенный в заголовки TCP/IP и HTTP. Так как клиентам JavaScript и Flash не требуется перегружать всю страницу каждый раз, когда пользователь выполняет какое-то действие, большинство приложений Web 2.0 вызывают меньший поток на уровне приложений, чем сопоставимые приложения, созданные с использованием статичного XHTML.

До сих пор богатый выбор Интернет приложений не выпускает так легко Web-сервисы. Пока они могут уменьшить поток XML, RIA может значительно увеличить количество соединений HTTP, с которыми работает сервер. Вместо ожидания того, как пользователь воспользуется ссылкой, большинство RIA работает в реальном времени, запуская новые соединения каждые несколько секунд. Серверы, перегруженные такой работой, могут выиграть от использования акселераторов SSL и других устройств AFE, включая распределение нагрузки и HTTP-сжатие.


Andy Dornan, Аналитик InformationWeek©
Перевод и адаптация: Алексей Маринин
12NEWS©
Photograph by Tim Flach/Stone/Getty Images

© Издание 12NEWS (ИП Маринин А.Л.), 2007