Безопасность SOA: одно сомнительное путешествие

Энди Дорнан

Вы готовы к рискам, открывая деловым партнерам свою сервисно-ориентированную архитектуру?

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

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

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

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

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

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

Самый большой конфликт существует  в управлении идентификацией - сложном механизме, гарантирующем, что пользователь или процесс, авторизовавшийся в системе одного из предприятий, имеет те же полномочия в системе партнера. При этом мы имеем два несовместимых стандарта, предлагающих во многом одну и ту же функциональность. Первый – язык разметки для систем обеспечения безопасности SAML, поддерживается почти всеми, за исключением Microsoft. Редмонд предпочитает более новый стандарт - WS-Federation, который теснее связан с другими стандартами web-сервисов. Несмотря на то, что оба стандарта используют XML, они  являются несовместимыми, что автоматически  означает, что предприятия с web-сервисами общего доступа должны либо поддерживать оба стандарта, либо сделать так, чтобы все их деловые партнеры, использующие защищенные web-сервисы, выбирали этот же стандарт.

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

СМЕШАННЫЕ СООБЩЕНИЯ

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

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

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

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

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

ОБЪЕДИНЯЙТЕ ВАШИ ДАННЫЕ ИДЕНТИФИКАЦИИ

Хотя WS-Security помогает шифровать и подписывать SOAPсообщения, в нем ничего не сказано об AAA («authentication, authorization, andaccounting», т.е. аутентификация, авторизация и аудит) или о политиках безопасности. Эти данные поддерживаются другими стандартами, которые в части безопасности основаны на WS-Security (см. «Стандарты WS-* Security: хорошегопонемногу?», informationweek.com/1148/security_sb.htm).

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

Можно ли купить все в одном месте? Нет

Исключением является только объединение данных идентификации, где относительно новые WS-Federation и WS-Trust конкурируют с SAML 2.0, стандартом, утвержденным и опубликованным Oasis. Объединенные данные идентификации направлены на то, чтобы обеспечить единый вход, отделяя таким образом процесс аутентификации от запрашиваемых ресурсов (см. «Объединенные данные идентификации и единый вход», informationweek.com/1148/security_ diagram.htm). Пользователь обращается к системе разграничения доступа и ему выдается разрешение, которое он может затем использовать для доступа к различным ресурсам. Разрешение называемое в SAML  «утверждением» (assertion), а в WS-Trust - «маркером» (token), похоже на цифровой сертификат и подтверждает личность пользователя и содержит данные о способе и времени проверки прав доступа. SAML охватывает весь процесс SSO (Single Sign-On, единый вход), в то время как множество 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 (Rich InternetApplications, насыщенные Интернет приложения) на основе браузеров часто считают XML слишком раздутым и предпочитают JSON (JavaScript Object Notation, текстовый формат обмена данными, основанный на JavaScript) или плоский текст.

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

Если не говорить о внешних связях, то возможность проходить через брандмауэр – это большой минус.

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

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

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

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

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

ПРОБЛЕМЫ ВИРТУАЛИЗАЦИИ
Основная проблема виртуализации заключается в том, что виртуальное аппаратное обеспечение пока не может тягаться со специализированными серверами, и поэтому, к примеру, компания Vordel скорее видит своей целью тестирование и интегрирование виртуальной версии, а не запуск ее в производство. Layer7 начала свою деятельность в качестве поставщика специализированного XML и SSLаппаратного обеспечения, поэтому она рассматривает виртуализацию как решения начального уровня для более мелких компаний, для которых использование специализированного аппаратного обеспечения не оправдано. И хотя сейчас «чисто программные» решения  являются скорее «мантрами» для экономии бюджета, вероятно, что вскоре виртуальное аппаратное обеспечение будет использоваться компаниями всех размеров.

Производительность виртуальных машин растет очень быстро, и гибкость, которую дает такая виртуализация, для SOAособенно полезна. При распространении и использовании новых сервисов инфраструктура SOA вынуждена адаптироваться, и виртуализация как раз позволяет быстро перераспределить аппаратное обеспечение по задачам. Но для разделения аппаратных ресурсов требуется, чтобы были виртуализированы и другие серверы, что может вызвать проблемы безопасности. Несмотря на то, что пока известны всего несколько уязвимых мест безопасности виртуального аппаратного обеспечения, сложность управления множеством виртуальных машин увеличивает шанс того, что трафик случайно обойдет брандмауэр (см. очерк по безопасности виртуализации в номере издания «Стратегическая безопасность» от 20 августа).

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

Из-за своей популярности SSLв шлюзах безопасности, акселераторы 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.

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