Одной из глобальных тенденций последний лет в области ИТ стал переход к сервис-ориентированной архитектуре (СОА). На то есть целый ряд причин — как технологических, так и экономических. Но если ранее СОА продвигалась главным образом разработчиками бизнес-приложений, то в последнее время к этому процессу подключились сетевые вендоры.

Стало очевидно, что добиться всех преимуществ этой архитектуры только за счет приложений невозможно. Во всех без исключения проектах ее построения присутствует сетевой уровень, возможности которого не были полностью задействованы. Это приводит к "утяжелению" ПО — так как, например, такие ресурсоемкие процессы, как маршрутизация приложений, сетевое оборудование способно делать гораздо эффективнее. Но, главное, современное сетевое оборудование для СОА способно обеспечить ее комплексную безопасность от "родовых" уязвимостей протокола XML — основы этой архитектуры, так как СОА оперирует не столько IP пакетами, сколько сообщениями (неким объемом контекстно — ориентированной информации).

XML-угрозы уже здесь

Протокол XML создавался не с точки зрения безопасности, а с точки зрения взаимодействия приложений. Как следствие, вопросам безопасности должного внимания не уделялось. Это классическая проблема, характерная для любой технологии: будь то IP-телефония, беспроводный доступ или мобильный банкинг. Сначала создается технология под конкретную задачу, а потом появляются сообщения об огромном количестве дыр, и начинается процесс их "затыкания". То же самое было и с протоколом XML. Те проблемы, которые в нем есть сейчас, могут привести к отказу в облуживании, возможности появления червей на базе XML, несанкционированному выполнению тех или иных команд, краже данных и т.п. Проблемы, в общем, те же, но на базе нового протокола.

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

В итоге статистика за период последних двух десятков лет показывает, что каждая тысяча строк кода содержит 15 критичных ошибок. А, учитывая, сколько кода содержится в ПО ведущих разработчиков операционных систем, баз данных, CRM и т.к., можно представить, какое количество дыр там существует. Что касается критических ошибок, напрямую связанных с безопасностью, то их количество оценивается в 5% от числа тех 15-ти, о которых говорилось выше.

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

Если опять вернуться к статистике, то с 2003 года уже известно о 13 тысячах уязвимостей в продуктах на базе XML. Но самое главное, что классические средства защиты, которые использовались ранее (те же самые межсетевые экраны или системы предотвращения атак) не способны бороться с угрозами по отношению к этим уязвимостям (по данным сообщества WebServicesSummit.com). Не потому, что у них у самих есть недостатки, а потому, что они разрабатывались совершенно для других целей — для контроля преимущественно сетевого уровня. Вот здесь классические межсетевые экраны, сетевые антивирусы и т.д. работают идеально, они для этого и предназначены. С HTTP они уже работают хуже. А с SOAP и XML протоколами "классика" работает из рук вон плохо.

Если обратиться к исследованиям Gartner, то станет понятно, что этот вопрос родился не сегодня. Еще в 2002 году аналитики указывали, что "Web-сервисы заново откроют 70% путей для атак, ранее закрытых межсетевыми экранами, потому что Web-сервисы могут обойти традиционную защиту периметра, неся любую информацию в поле данных (т.е. будучи по сути легитимными) и взаимодействуя с любым приложением в сети".

Одна из главных причин — открытие на межсетевом экране 80-го порта для работы с HTTP (именно на базе него работают XML, SOAP и Web-сервисы). Но классический межсетевой экран не "понимает", что такое Web-сервисы, он не "знает" о присущих им проблемах. Поэтому, открывая этот порт (или иной другой HTTP-порт) без должных средств защиты, мы впускаем в компанию (и, соответственно, выпускаем из нее) огромное количество проблем, связанные с теми самыми 13-ю тысячами обнаруженными уязвимостями, связанными с XML.

Мировой рынок межсетевых экранов для Web приложений, млн долларов

Источник: Forrester Research, 2007

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

Мировые объемы продаж некоторых продуктов ИБ, млн долларов

Источник: Yankee Group, 2007

Надо признать, что "старые угрозы" никуда ни делись — наоборот, они даже множатся. Владимир Бычек, руководитель направления контент-безопасности (eSafe) компании "Аладдин", считает, что открытый 80-й порт является источником огромного количества угроз безопасности, в том числе и со стороны XML-эксплойтов. "Однако, если общее число уязвимостей, связанных с XML, оценивается приблизительно в 13 тыс., то общее количество эксплойтов, а также других современных Web-угроз, использующих для проникновения в корпоративные сети 80-ый порт, исчисляется сотнями тысяч, если не единицами миллионов. Поэтому фильтрация Web-трафика именно от этих угроз представляется как на сегодня, так и на среднесрочную перспективу существенно более актуальной задачей для подавляющего большинства организаций, чем фильтрация XML, которую  можно рассматривать лишь в качестве подмножества системы защиты корпоративной инфраструктуры", — утверждает эксперт.

Если все-таки предположить, что прогноз аналитиков Yankee Group и Forrester по вытеснению с рынка обычных межсетевых экранов сбудется, то чем можно "заткнуть" эту дыру в безопасности? Так, например, в дополнение к продукции Cisco, обеспечивающей сетевую безопасность, появился специальный "слой", ориентированный на СОА, Web-сервисы и на взаимодействие приложений. Это AON и решения, входящие в группу ACE.

Если посмотреть на то, как работает то или иное бизнес-приложение, то, например, представим, что существует брокер, который работает с фондовой биржей, и есть приложение, которое принимает заявки на куплю-продажу акций. Есть также приложение, которое проводит эти сделки. На пакетном уровне (т.е. там, где работают межсетевые экраны, маршрутизаторы и т.д.) все выглядит одинаково. Традиционные средства защиты не понимают разницы между работой приложений нашего брокера и передачей электронной почты или звонком по IP телефонии. И там и там передаются обычные IP пакеты. И все, что мы можем сделать на этом уровне — защитить от атак типа "отказ в обслуживании", от перехвата трафика и каких-то стандартных сетевых атак.

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

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

Что такое XML Security Gateway? Это программно-аппаратный комплекс, который выполняет несколько задач — ускорение и более эффективная обработка XML, разгрузка центральных процессоров серверов, масштабируемость, это управляемость и безопасность. Т.е. это функционал XML-файервола — полный анализ того, что происходит с XML в контексте безопасности.

Если посмотреть на инфраструктуру СОА, то станет понятно, что весь XML трафик проходит через это устройство и на нем реализуется политика безопасности Web-сервисов. Т.е миновать этот ПАК, сервисы не могут, а мы в состоянии контролировать, что можно делать тем или иным пользователям и сервисам, а что нельзя.

Т.е. суть его проста — контролировать все запросы, но мы их анализируем с точки зрения XML. Ну, а поскольку мы работаем на едином стандарте XML, нам абсолютно не важно, какие имеется приложения — это может быть BEA, Oracle или Microsoft. Но это пока еще не бизнес-логика, это пока технологический уровень. Оно может внедряться как в демилитаризованной зоне, так и на периметре сети, так и в ЦОДе или в ключевых сегментах.

Новые технологии защиты бизнес-логики

Все бизнес-транзакции между приложениями достаточно точно можно восстановить, в частности, за счет решения Cisco AON, предназначенного для защиты бизнес-логики, по которой они работают — до вполне конкретных функций пользователей:  осуществлена отгрузка продукта такого-то…, ордер на покупку акция или кадровый приказ. В результате чего возникает возможность оперировать языком бизнеса, а не терминами технологий. Решение AON "понимает" этот язык. Такой подход позволяет реализовать некоего "посредника" между приложениями и сетью. С одной стороны — это сетевое устройство, с другой — это элемент бизнеса. Это позволяет реализовывать эффективные механизмы управления бизнес — логикой именно на уровне сети, там, где это возможно.

Разумеется, вендор не берет на себя задачу полного управления бизнесом, а только то, что касается сетевого уровня. Само решение может быть выполнено в виде модуля для маршрутизатора ISR или коммутатора Catalyst, а так же реализовано в специализированном программно — аппаратном комплексе, который обеспечивает максимальную производительность. В итоге базовая функциональность AON — это интеллектуальная обработка сообщений, маршрутизация по контенту, трансформация и трансляция протоколов, а также балансировка нагрузки. Что касается безопасности, то это — аутентификация, шифрование, проверка подписи, обеспечение целостности и безотзывности и управление сертификатами. Все это дополняется функционалом "видимости событий" — возможность захвата и регистрации для дальнейшего аудита, уведомлений в случае нарушения каких-либо требований бизнес-политики и т.д.

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

В комплект поставки AON входят средства для программирования бизнес-логики и специализированной обработки той или иной задачи. При разработке этого решения Cisco впервые отошла от принципа поставки коробочного продукта в пользу "конструктора", из которого можно создать всё, что необходимо для бизнеса конкретного предприятия.

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

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

Какой синергетический эффект может дать совместная работа сетевых  и бизнес-приложений других вендоров в рамках СОА? В настоящее время разработан совместный продукт Cisco & SAP GRC (Government, Risk and Compliance). Это решение для комплексного управления рисками. Как, связанными с бизнесом вообще, так и с операционными, значительную часть которых составляют угрозы со стороны ИТ. На сегодняшний день разработаны три ключевых элемента данного решения — это обеспечение конфиденциальности данных и обнаружения её утечек, это защита ИТ-инфраструктуры и повышение ее отказоустойчивости, а также анализ качества обслуживания. Все это обеспечивает непрерывность бизнеса и вызывает живой интерес заказчиков, для которых это важнейшее требование к ИТ-инфраструктуре — например, предприятия ТЭК и банки.