Rambler's Top100
Статьи ИКС № 4 2008
Алексей ЛУКАЦКИЙ  07 апреля 2008

Спасение утопающих, или Безопасность SOA

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

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

Сложность простоты

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

Переход к каталогам стандартизованных сервисов делает проблему уязвимости ПО чрезвычайно острой. Уязвимый сервис на базе WSDL или интерфейс взаимодействия сервисов UDDI делает задачу злоумышленника существенно более простой, чем «до SOA», поэтому очень важно соблюдать жизненный цикл разработки ПО (Software Development Life Cycle, SDLC). Ошибки (а в каком ПО их нет?!) и просто уязвимости – настоящие враги SOA.

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

SOA с точки зрения классической безопасности

Как бы то ни было, не стоит полагаться только на умение разработчика следовать SDLC. Спасение утопающих – дело рук самих утопающих, а потому необходимо предусмотреть в своей ИТ-инфраструктуре дополнительные механизмы защиты. Классические средства обеспечения безопасности не способны эффективно работать в SOA-окружении – хотя межсетевые экраны (МСЭ) и называют эффективным средством защиты SOA-окружения на базе веб-сервисов.

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

Кроме того, в ИТ-инфраструктуре компании неизбежно найдутся участки, не входящие в SOA. При разработке архитектуры защиты следует учитывать необходимость обеспечения ИБ минимум для трех типов систем: входящих в SOA; не входящих в нее, но взаимодействующих с этой архитектурой; не входящих в SOA и не взаимодействующих с нею. Следовательно, на границе SOA нужно использовать сетевые устройства, пропускающие через себя все сервисные запросы и проверяющие их на соответствие политике безопасности. Примеры таких решений – продукты Xwall (Forum Systems), ACE XML Gateway (Cisco), XML Guardian (Sarvega) и XS40 (DataPower). Все они могут быть отнесены к классу прикладных межсетевых экранов (application firewall).

Безопасность с точки зрения классической SOA

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

Другое дело – реализация защиты в контексте самой SOA. Тогда ИБ становится одним из сервисов, к которому обращаются приложения и другие сервисы. Сейчас далеко не все в ИБ-области можно «транслировать» в сервис, но есть и механизмы, идеально подходящие для этой роли, например идентификация, авторизация и др. (рис. 1).

Сервисы защиты, претендующие на звание SOA-совместимых или SOA-ориентированных, должны удовлетворять пяти основным принципам: компонуемость, многократность использования, инкапсуляция, слабая связность (независимость), модульность. К сожалению, межсетевое экранирование и предотвращение атак пока не могут быть реализованы в рамках концепции SOA, но не за горами день, когда этого удастся добиться. Уже сегодня известно по крайней мере об одной инициативе, в рамках которой «свойство» сервис-ориентированности получают МСЭ, IPS, средства антивирусной и контентной фильтрации.

Среди поставщиков средств защиты, построенных в полном соответствии с SOA, можно назвать Oracle, SAP и ряд других игроков ИТ-рынка. Традиционные же разработчики средств обеспечения безопасности пока лишь присматриваются к этому сегменту. Так, Cisco явно интересуется SOA. Иначе зачем в ноябре 2007 г. она купила компанию Securent, которая имеет в своем портфолио инструменты управления идентификацией, аутентификацией, авторизацией и доступом именно для продуктов, созданных в рамках SOA (MS SharePoint, BEA WebLogic, IBM WebSphere, Oracle и др.)?

Стандарты защиты SOA

Рассуждая о SOA в контексте веб-сервисов и спецификации SOAP, нужно отметить: они чаще всего используют для взаимодействия протокол HTTP, который изначально не предназначался для гарантированной доставки. Более того, он не может похвастать механизмами обеспечения целостности и конфиденциальности, что также негативно сказывается на работоспособности инфраструктуры на базе SOA и достоверности находящейся в ней информации. Именно поэтому было разработано множество стандартизованных протоколов безопасности, действующих поверх базовых протоколов SOAP и XML (рис. 2).

И все же их недостаточно для того, чтобы считать SOA защищенной. Не полагайтесь на слова поставщика, утверждающего, что его решение соответствует указанным на рис. 2 протоколам и интерфейсам или поддерживает их! Увы, это не гарантирует истинной защищенности такого решения. Наличие всего одной уязвимости или архитектурного просчета в продукте, формально соответствующем стандартам, может «открыть» его для злоумышленников. И, конечно же, принятые стандарты не всегда позволяют получить действительно защищенную SOA. Вам могут понадобиться собственные, внутрикорпоративные стандарты, интерфейсы и протоколы.

Подводные камни

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

Первое – у потребителей отсутствует понимание бизнес-контекста. Защита SOA гораздо ближе к бизнесу, чем использование традиционных МСЭ, средств предотвращения атак и других ИБ-систем, однако многие специалисты по безопасности незнакомы с ИБ на уровне SOA. Кроме того, само решение и поставщика SOA обычно выбирает департамент ИТ в тесном контакте с бизнес-подразделениями, а служба ИБ в этом проекте обычно не участвует. С учетом стоимости SOA-решений это может обойтись слишком дорого.

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

. . .

«Уж сколько раз твердили миру», что о безопасности надо начинать думать не в процессе внедрения того или иного решения, а еще на этапе его проектирования. SOA – не исключение. Выбирая решение, нужно спрашивать производителя даже не о количестве уязвимостей в его продуктах, а о том, следует ли он SDLC. Отрицательный ответ заставит вас задуматься, стоит ли тратить сотни тысяч долларов на фактически незащищенное решение. Но и получив утвердительный ответ, не забывайте о «самозащите», использовании средств ИБ SOA-протоколов и сервисов безопасности.
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!