Журнал о компьютерных сетях и телекоммуникационных технологиях
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК:
    Домой
 
   
АРХИВ ЖУРНАЛА
   

2008: 1 2 3 4 5 6 7 8 9 10 11 12 13
2007: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2006: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2005: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2004: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2003: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2002: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2001: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2000: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
1999: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1998: 1 2 3 4 5 6 7 8 9 10 11 12
1997: 1 2 3 4 5 6 7 8 9 10 11 12
1996: 1 2 3 4 5 6 7 8 9 10


Rambler's Top100

  

Рискованное дело

Энди Дорнан

«Перевесят» ли преимущества свободного доступа бизнес-партнеров к вашим SOA-приложениям связанный с этим риск?

Веб-сервисы всегда рекламировались как средство разделения данных между организациями: предприятие может выборочно открывать свои внутренние системы клиентам, партнерам и поставщикам, автоматизируя транзакции, работа с которыми когда-то требовала вмешательства человека. До сих пор большинство предприятий избегали делать это, однако надежная защита веб-сервисов межсетевыми экранами (МЭ), развитие сервис-ориентированной архитектуры (Service-Oriented Architecture — SOA) и появление технологии Web 2.0, похоже, скоро изменят эту ситуацию.

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

Учитывая высокую динамичность этого рынка, прежде чем приобрести какие-либо компоненты безопасности SOA, следует хорошенько протестировать их. В конце концов, отмечаемое нами движение рынка является хорошей новостью для ИТ-подразделений предприятий, поскольку означает более широкий выбор средств безопасности SOA и — в перспективе — снижение числа производителей, с которыми им придется иметь дело. Вместе с тем это усложняет процесс принятия решения о покупке нужного продукта. Например, открытые для доступа из Интернет веб-сервисы нуждаются в МЭ, известных также как шлюзы безопасности SOA. Однако эта категория продуктов постепенно исчезает с рынка, что связано с наблюдаемой в настоящее время его консолидацией.

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

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

Самый крупный конфликт связан с управлением идентификационной информацией — весьма сложным процессом обеспечения права зарегистрированного в системах одной компании пользователя обращаться к системам ее партнера. Здесь имеется два несовместимых друг с другом стандартных подхода, предоставляющих, по существу, одну и ту же функциональность. Первый из них — SAML (Security Assertion Markup Language) — поддерживают почти все производители ПО, за исключением Microsoft. Последняя предпочитает более новый стандарт WS-Federation, который теснее привязан к другим стандартам веб-сервисов. Хотя оба эти стандарта используют язык XML, они несовместимы друг с другом. Это означает, что предприятия с общедоступными веб-сервисами должны либо поддерживать оба стандарта, либо позаботиться, чтобы все их бизнес-партнеры, реализующие безопасные веб-сервисы, выбрали один и тот же стандарт.

Смешанные сообщения

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

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

WS-Security является одним из наиболее зрелых стандартов WS-*, и его поддерживают почти все производители веб-сервисов и архитектур SOA. Тем не менее и у него есть слабое место — как и все стандарты WS-*, он требует протокола SOAP (тем предприятиям, которые для поддержки своего бизнеса используют веб-сервисы, основанные на архитектуре REST (Representational State Transfer), протокол SOAP, вообще говоря, не нужен).

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

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

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

Федерализируйте идентификацию

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

Хотя в настоящее время продукты ESB (Enterprise Service Bus) и средства управления веб-сервисами еще слишком новые, чтобы оказывать заметное влияние на пользователей, в конечном итоге большую часть вышеупомянутых технологий будут поддерживать производители продуктов обеих категорий.

Исключением станет федеративная идентификация, в которой относительно новые спецификации WS-Federation и WS-Trust конкурируют со стандартом SAML 2.0, также учрежденным организацией OASIS. Федеративная идентификация пользователей обеспечивает их единую регистрацию (Single Sign-On — SSO) путем отделения процедуры аутентификации от того ресурса, к которому осуществляется доступ. Пользователь регистрируется на сервере провайде-ра идентификационной информации, а последний предо-ставляет ему удостоверение личности (credential) для доступа к самым разным ресурсам.

Удостоверение личности пользователя, называемое «подтверждением» (assertion) в SAML и «жетоном» (token) в 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 — в веб-сервисах REST.

Место МЭ

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

Как результат компании, публикующие веб-сервисы в сети Интернет, традиционно устанавливали шлюзы безопасности, т. е. устройства, способные читать и понимать документы прикладного уровня и отфильтровывать потенциальные атаки. Эти устройства обычно называют «межсетевыми экранами XML», хотя хороший МЭ XML может не только читать документы XML, но и делать кое-что другое. Использующий протокол REST веб-сервис способен кодировать отдельную информацию внутри заголовков HTTP или указателей URL, однако разработчики основанных на браузере развитых Интернет-приложений (Rich Internet Application — RIA) считают язык XML слишком громоздким, предпочитая ему нотацию JSON (JavaScript Object Notation) или незашифрованный текст.

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

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

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

Из исходной группы производителей шлюзов безопасности четыре фирмы были куплены, как говорится, прямо «на корню»: Sarvega — компанией Intel, NetScaler — компанией Citrix, DataPower — компанией IBM и Reactivity — компанией Cisco Systems. Все перечисленные компании, за исключением Intel, использующей технологию Sarvega в целях содействия другим производителям при создании ПО или устройств XML на базе ЦПУ общего назначения, по-прежнему продают шлюзы. Однако продукты этих компаний эволюционируют в разных направлениях.

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

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

Виртуализация на своем месте

Негативное влияние виртуализации на производительность системы означает, что виртуальное устройство пока не может работать со скоростью выделенного сервера. Поэтому в настоящее время виртуальная версия шлюза безопасности компании Vordel предназначена в основном для тестирования и интеграции, а не для производственных целей. Компания Layer 7 начинала свою деятельность как производитель специализированных устройств и ИС поддержки XML и SSL, и сейчас она рассматривает виртуализацию в качестве отправной точки для создания SOA-сред относительно небольших предприятий, которые не могут пока позволить себе расходы на специализированное оборудование. Однако, хотя словосочетание «только программный» может служить сегодня заклинанием для администраторов стесненных в средствах предприятий, вполне вероятно, что уже в ближайшее время виртуальные устройства будут иметь предприятия любого масштаба.

Производительность виртуальных машин растет сегодня весьма быстрыми темпами, а обеспечиваемая виртуализацией гибкость будет особенно полезной для архитектуры SOA. Когда развертываются и повторно используются новые сервисы, то к ним необходимо адаптировать инфраструктуру SOA, и виртуализация позволяет быстро переназначать «роли» оборудованию. Однако разделение аппаратных ресурсов требует также виртуализации других серверов, а это может повлечь за собой возникновение проблем безопасности. Хотя уведомлений об обнаруженных в ПО VMware уязвимостях было совсем немного, сложность управления множе-ством виртуальных машин может увеличить вероятность случайного прохождения трафика мимо МЭ.

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

Благодаря высокой популярности протокола SSL практически все шлюзы безопасности сегодня наделяются функцией SSL-акселерации: даже производители виртуальных устройств и те поддерживают оборудование с платами акселерации SSL. Акселерация XML встречается гораздо реже, и только устройства компаний Layer 7, Cisco и IBM оснащаются специализированным ИС для XML-акселерации; корпорация IBM разработала свою собственную ИС, а Cisco и Layer 7 используют ИС компании Tarari. Отчасти это связано с применением Intel фирменной технологии Sarvega (в компании Layer 7 полагают, что рынок оборудования постепенно будет смещаться в сторону программных решений), но главная причина происходящего — спрос на акселерацию уровня приложений в настоящее время остается все еще незначительным.

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

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

  
2 '2008
СОДЕРЖАНИЕ

бизнес

• IP-коммуникации и операторы связи

• Как заслужить звание «лучшего работодателя»?

инфраструктура

• Особенности построения ЦОДа для оператора связи

• Планирование ЦОДа с нуля: выбор места размещения

• Точки доступа БЛВС: от «толстых» к «тонким» и снова на круги своя

информационные системы

• Обеспечь поддержку виртуализации или уходи

• Анализаторы речи для контакт-центров

• XenServer Enterprise — достойный вариант виртуализации

• Тестируем продукты управления производительностью приложений

• Идеальная поисковая машина

сети связи

• Видеосервисы нового поколения

• IP-телефония: продвижение в некоммерческом секторе

• Windows Mobile 6 набирает обороты

• Нужны ли вам фемтосоты?

кабельные системы

• Оптические кабельные инфраструктуры: соединительное и распределительное оборудование

• На пути к 100-Гбит/с технологии Ethernet

защита данных

• Рискованное дело

новые продукты

• Концентраторы абонентского доступа для сетей NGN; Разъемы Smart Quick-Fit компании Huber-Suhner


• Калейдоскоп


Реклама:
 Copyright © 1996-2008 ООО "Сети и Системы Связи". вверх