Source: http://www.itblogs.ru/blogs/borkus/archive/2007/08/19/ws-security.aspx
Одно из основных правил программирования говорит о том, что специализированное решение в своей узкой области как правило будет лучше обобщенного. Это свойство всегда проявляется при выработке стандартов – в них закладывается либо самая общая, либо «усредненная» модель. В первом случае стандарт получается очень сложным, во втором – открывается поле для всевозможных фирменных расширений, его «улучшающих».
Примерно так обстоит дело со стандартами в области безопасности SOA. В стеке WS-* запланирована очень глобальная модель безопасности, включающая почти десяток всяких спецификаций (WS-Security, WS-Secure Conversation, WS-Trust, WS-Federation, WS-Policy, а также XML Digital Signature, Security Tokens Profiles (для SAML, Kerberos,X.509) и т. п.
Благодаря этому возникает целый комплекс очевидных проблем для SOA:
1) Не все эти стандарты реализованы одинаково во всех продуктах, что делает разные компоненты SOA несовместимыми.
2) Так как общие стандарты разрабатываются медленно, открывается поле для "частных" расширений вендоров, которые еще более снижают совместимость.
Я бы не стал писать про это статью, но на днях натолкнулся на интересное выступление на эту тему специалиста в области безопасности Брэда Хилла (http://www.isecpartners.com/files/iSEC_HILL_AttackingXMLSecurity_bh07.pdf). В почти 200-страничной презентации обстоятельно показывается, почему стек WS-S -- пока не лучший способ для обеспечения безопасности для открытых в Интернете сервисов,B2B-сервисов и внутрикорпоративных web-сервисов.
Во первых, для любых внутрикорпоративных и B2B ИТ-систем характерна более высокая степень доверия к их пользователям, и проблемы безопасности как правило решаются "не внутрикорпоративными фаерволами, а организационными мероприятиями и [в случае B2B] адвокатами". Главное, что должна обеспечить общая инфраструктура безопасности -- это протоколирование всех действий и точную идентификацию пользователей, получивших доступ к конкретной системе. Это тезис, с которым сложно не согласиться.
Но для этих задач ЛУЧШЕ всего подходит стандартный SSL, при одновременном применении _клиентского_ и северного сертификатов. В самом деле, у него есть набор явных преимуществ:
1) Он решает как задачу безопасной аутентификации (по сертификату);
2) Он защищает трафик от пользователя к системе;
3) Что еще более важно -- он совершенно ОДИНАКОВО реализован во всех системах, в том числе старых -- пяти и даже более летней давности;
4) Он покрывает 99% процентов того, что нужно для решения реальных задач.
Модель же безопасности на уровне сообщений, примененная в WS-S, не дает в этом смысле никаких преимуществ, так как опять-таки в 99% случая все, что от нее требуется -- это аутентификация пользователей. Но он также неодинаково реализован на новых и старых системах, а применение агентов-посредников тоже не всегда удобно и эффективно. Также WS-S (в конечном итоге за счет XML Digital Signature) опирается на шифрование больших объемов данных открытыми ключами – очень ресурсоемкая операция по сравнению с симметричным шифрованием в SSL. Поэтому при использовании для интеграции внутрикорпоративных систем WS-Security оказывается менее адекватен, чем SSL.
Но и _самостоятельное_ применение этого стека для интернет-бизнеса пока просто опасно. Так как WS-S задает модель безопасности на уровне сообщений, то каждый раз проектируя композитную систему, ИТ-разработчик по сути строит свой протокол безопасности не осознавая этого. Нет вопросов -- специалисты, которые в таких вещах хорошо разбираются не работают в обычных компаниях, а значит такой протокол будет почти наверняка ущербен с самого начала.
WS-Security плох тем, что для его реализации используется работа многих слоев (от XML Encryption, XML Digital Signature, Security Tokens Profiles (SAML, Kerberos, X.509), WS-Trust, WS-Federation и т.п) -- слишком много точек для потенциальной атаки, слишком сложно заставить все это скоординировано работать.
Брэд Хилл показывает в своей презентации как можно эти уязвимости использовать, какие есть стандартные "дыры" в реализации этих спецификаций, например, в XML Парсере. Эти дыры можно было бы отключить настройками, но сегодняшние продукты таких настроек не предоставляют. И в любом случае получается слишком много предположений о квалификации среднего корпоративного разработчика.
Вместе с тем, стек WS-S создает ряд бизнес-возможностей, таких, как цифровые деньги, DRM-применения, распределенная аутентификация, и транзакции, в которых участвуют много сторон. Но так как последствия для безопасности от самостоятельного использования этих протоколов пока до конца не изучены, то WS-S рекомендуется применять не самостоятельно, а вместе с отлаженной базой SSL.
Published 19 августа 2007 г. 23:09 by Vlad Borkus Edit
Filed under: SOA, Безопасность
arkanoid said:Елашкин мне так трансляцию из ЖЖ и не настроил - а я, собственно, имел бы что об этом сказать..августа 20, 2007 0:07
abukavnev said:
Никогда не писал в блогах (в том числе и в этом) о SOA, так как все подобные дискуссии больше похожи на детский сад (no offence для блоггеров, просто констатирую факт).
Но тут задело – так что даже зарегистрировался.
Давно не читал более пристрастного анализа, чем этот Бреда Хилла.
Из текста становится ясно, что стек WS-Sec слишком сложен для ‘average systems engineer’, и вот отсюда могут возникнуть проблемы с безопасностью. Великолепный анализ! Very up-town!
А посмотрите на шедевр - Reason 2 на странице 34: Бред доказывает ненужность обмена сообщениями – так как у людей могут быть неверные “deep and unexamined expectations”.
А чего стоит сочиненные им несуществующие проблемы с SSL (Debunking SSL Myths), разбитые Бредом в пух и прах. Ай, маладца! Только ведь это известный принцип демагогов – придумать неверные аргументы, приписать их своему оппоненту, а затем их опровергнуть.
А некоторые фразы вообще бьют наповал:
“And WS-I is considered dead in the water at this point by most”. За что так WS-I? И это, заметьте, при том, что WS-I Basic Profile требует поддержки SSL, а отнюдь не стека WS-Sec.
Бог с ним! Вообще, оценивать этот поток сознания по пунктам просто не имеет смысла – там можно придраться практически к любой фразе. Перечислю просто ряд проблем, где SSL/TLS НЕ ДОСТАТОЧНО для обеспечении безопасности в SOA:
1) в SSL/TLS шифруется все сообщение, нельзя шифровать часть. А это создает следующие проблемы: невозможен content-based routing на пути от потребителя сервиса к провайдеру сервиса (например, в шине) без расшифровки сообщения; так же нельзя шифровать различные части сообщения для различных получателей на пути сообщения от потребителя к провайдеру
2) Автор, упоминая о AAA, забывает о еще одном критически важном требовании (в частности, в финансовой сфере) – невозможность одной из сторон отказаться от совершенного действия (Non-Repudiation), обеспечить которое с использованием SSL/TLS просто невозможно, так как non-repudiation требует асимметричного шифрования
3) SSL/TLS – это обеспечение безопасности точка-точка (на один хоп), обеспечить безопасность end-to-end с использованием SSL/TLS и нескольких промежуточных точек между потребителем и провайдером невозможно.
Из своей практики могу привести ряд случаев, когда использование WS-Sec более чем оправдано:
1) Когда на пути от потребителя к провайдеру есть промежуточные точки, на которых необходимо получать доступ к содержимому части сообщения, не нарушая безопасности (пример такой точки – брокер ESB)
2) Когда транспорт отличен от HTTPS или, скажем, SSL over MQI
3) При множественности security-доменов (B2B сценарии)
4) Когда необходимо обеспечить безопасность только для части сообщения, что очень часто встречается при создании композитных сервисов и BPEL-процессов
5) Когда необходимо обеспечить такие требования как SSO или federated identity (замечу, что SSL/TLS сам по себе не решает, да и не может решить этих задач)
6) Когда надо сохранять сообщения в зашифрованном виде по завершении транспортного соединения
В одном Бред прав – если основными требованиями выступает производительность и интероперабельность, то тут SSL/TLS вне конкуренции. Но для доказательства этого тезиса не надо городить весь этот бред.
Кстати, с появлением акселераторов вроде XS-40 вопрос производительности при использовании стека WS-Sec в принципе решен, в чем я имел возможность лично убедиться.
С уважением,
Алексей Букавнев,
IT Architect,
IBM Certified SOA Solution Designer,
Renaissance Credit.
августа 20, 2007 17:38
IT для бизнеса: it4business.ru » WS-Security: начинание благое, но безопасность SOA не обеспечивает said:
PingBack from http://it4business.ru/analytics/481/
августа 20, 2007 18:32
Tolik said:
2Алексей
"Из текста становится ясно, что стек WS-Sec слишком сложен для ‘average systems engineer’, и вот отсюда могут возникнуть проблемы с безопасностью. Великолепный анализ! Very up-town!
А посмотрите на шедевр - Reason 2 на странице 34: Бред доказывает ненужность обмена сообщениями – так как у людей могут быть неверные “deep and unexamined expectations”."
Налицо общая проблема умных людей и хороших специалистов - они искренне полагают всех вокруг столь же умными и тоже разбирающимися в своём предмете. Ну как в этом можно не разбираться?
Но! Брэд Хилл не только умен, но и мудр. Он знает, что ‘average systems engineer’, увы, не настолько умен и не настолько разбирается. И любая система (даже самая великолепная), превышающая его возможности понимания - увы - только во вред. Ибо никогда не будет использована правильно.
Хороший урощенный пример на тему - интерфейсы, созданные программистами (иощные, удобные, настраиваемые) - увы, не годятся для пользователя, непонятны ему и не повышают его эффективности. Эффективно он работает с чем-то искусственно упрощенным, от чего программистов воротит.
августа 20, 2007 19:40
Vlad Borkus said:
Толя, еще можно добавить принцип, использованный когда-то Microsoft: если что-то достаточно хорошо, то его и достаточно :)
Все сводится к тому, а часто ли нужна безопасность на уровне сообщения? Может чаще достаточно шифровать трафик, ну и постоянные и транзитные хранилища (в WS-S, кстати, намучаешься потом ключами управлять). Этого, насколько я знаю, хватает даже нашим спецслужбам для большинства задач. Да, будут проблемы в гетерогенной среде. Да есть проблемы при многоузловой марушрутизации. Но может проще доступ к узлам ограничить и отказаться от гетерогенного транспорта? Пусть в КИС везде стоит MQ Series, кто против?
Опять, весь это задача баланса цены скрываемых секретов и затрат на реализцию безопасности. А Хилл на самом деле просто поднял вопросы из области здравого смысла.
А Анатолий, помню, про управление рисками написал целую статью. :))
августа 20, 2007 20:33
abukavnev said:
Уважаемый Tolik,
мой пост просто преследовал целью показать, что Бред Хилл, используя явные демагогические приемы (умалчивание неудобных фактов, передергивание и местами прямой обман) пытается доказать, что SSL/TLS "лучше", чем WS-Sec. Это больше напоминает религиозные мантры, чем объективный анализ.
Я привел несколько случаев, где SSL/TLS не работает, а WS-Sec - отлично справляется. Их всего 3. Так что у вас есть возможность объективно доказать, что для указанных мной случаев SSL работает (что, скажем сразу, Вам не удастся), доказав тем самым правоту Бреда о единственно верном разбивании яиц с острого конца. А рассуждения о умности/мудрости тех или иных субъектов - субъективны и не проверяемы.
Уважаемый Vlad,
" Может чаще достаточно шифровать трафик" - может. Никто и не спорит. Дело лишь в том, что SSL подходит для обеспечения безопасности в SOA не всегда. Попытка доказать обратное, предпринятая Бредом, убога и просто смешна любому, кто в теме.
Что "ну и постоянные и транзитные хранилища"?
"в WS-S, кстати, намучаешься потом ключами управлять" - Вы пробовали?
"Этого, насколько я знаю, хватает даже нашим спецслужбам для большинства задач" - о спецлужбах не мне судить (не буду даже спрашивать, какая из обилия служб решила применить подход SOA). Опять вы про "большинство задач", когда достаточно шифровать траффик.. Приведенные мной 3 случая - как раз типовые для SOA, и в SOA они вполне могут входить в это "большинство".
"Но может проще доступ к узлам ограничить и отказаться от гетерогенного транспорта?" - что именно ограничить - не совсем понятно. Сформулируйте более четко, пожалуйста. "Отказаться от гетерогенного транспорта" - в практике не всегда возможно и даже зачастую строго противопоказано по огромному ряду объективных как технических, так и организационных причин.
"Пусть в КИС везде стоит MQ Series, кто против?" - объективная реальность против.
"А Хилл на самом деле просто поднял вопросы из области здравого смысла" - он их не поднял, а постарался закрыть, отказавшись от этого самого здравого смысла.
С уважением,
Алексей Букавнев,
IT Architect,
IBM Certified SOA Solution Designer,
Renaissance Credit.
августа 20, 2007 21:56
Vlad Borkus said:
Уважаемый Алексей,
этот спор тяжко вести по той причине, что я совсем не против WS-S (хотя броский заголовок я и дал). Но я не считаю WS-S инструментом, который нужно непременно применять везде. Более того, мне кажется, что чаще, чем реже можно пользоваться более простыми решениями.
По пунктам
п.1. Есть такая проблема. Но насколько она критична? В большинстве ERP данные вообще не шифруются. Часто ли нужно, чтобы они были зашифрованы на шине ESB внутри организации _при условии_, что все каналы между узлами ESB защищены и транзитные хранилища тоже? Это вопрос доверия к безопасности серверов на которых стоит ESB.
п.2. Невозможность отказаться от совершенного действия обеспечивается договором сторон (юридическими документами), а не техникой. На самом деле пример – я использую систему клиент-банк, и не могу отказаться от проведенной в ней операции по условиям договора. Да, банк принял технические меры защиты (кстати, там используется SSL-шифрование и аутентификация. SSL использует несимметричные ключи, симметричные – это только на период сессии), но веб-сервисов и WS-S там и близко не нет. Усилит ли банк безопасность, если он на каждое мое сообщение будет навешивать ярлык и его потом хранить? Возможно немного усилит, но насколько это для банка важно? Ведь все риски я принял на себя. И более того, _приближающуюся по силе_ вещь (хотя совсем не идентичную) он может сделать за счет взаимной авторизации всех серверов, а также авторизации конечного клиента. Иначе говоря, если одна система банка доверяет другой системе банка. Дальше – вопрос журналов и их неподдельности. Да, риски раступ пропорционально числу обрабатывающих серверов, но так ли много серверов по пути? (Есть еще одна ветвь -- расширение данных. Но всегда ли нужно запрашивать у других систем данные именно от имени клиента?)
п.3. Да, на уровне сообщения безопасность end2end обеспечить не возможно. Но за счет установления комплекса доверительных отношений между системами/узлами – можно обеспечить _возможно приемлемую_ безопасность КИС в целом. Если таких доверительных отношений построить нельзя, то, вариантов кроме WS-S нет. Но опять-таки WS-S против SSL – это классический разговор про атаку «человека посередине». Ее можно устранять (WSS) или минимизировать разными способами. Вопрос цены.
По другим вопросам.
Про ключи. Для SOA, не делал, но было для других задач. Беда ключей и ЭЦП в том, что они имеют срок годности. Возникает вопрос о том, сколько времени можно хранить эти сообщения. 5 лет -- OK, больше – чего делать с ключами и сообщениями? Вторая беда -- разрастание хранилища уже самих ключей.
Да, не всегда удается добиться негетерогенной среды (скажем в B2B точно). Но в гетерогенной среде будет масса своих проблем. Самая мелкая из которых – что делать, когда есть «тонкие различия» в поддержке WS-S и шифрования участниками взаимодействия? ((Кстати, у IBM есть Red Book на тему как стыковать разные изолированные ESB. Первая фраза – «лучше этого не делать». А далее 200 страниц текста, как сделать хотя бы плохо работающее решение.))
Опять-таки, на мой взгляд, проблема со стеком WS-S – это появление нового довольно сложного звена в системе. О нем приходится помнить. Это overhead.
Есть только один абсюлютный мотив -- мы снижаем зависимость от администраторов системы. Но опять возникают вопросы цены и рисков.
августа 21, 2007 0:22
Tolik said:
2Алексей
Понимаешь, мы так никогда не придем к согласию, ибо дискутируем о перпендикулярных вещах. Да, конечно WS-Security функциональнее, кто же спорит-то? Проблема - вовсе не в недостаточной функциональности, она в избыточной и вызванной ею сложности, тут аспекты не технические, а психологические. Об этом Б.Х. и писал.
А рассказывая, как тонко можно настроить WS-Security - ты льёшь воду именно на его мельницу. Он О ТОМ ЖЕ САМОМ, только выводы противоположные. :-)
Просто "здравый смысл" немного разный. Само собой - при дискуссии о том, что есть "здравый смысл" - мы дискутируем на уровне разных аксиом, а не общих аксиом и разных выводов. Естественно - при такой дискуссии оппонент будет неизбежно демагогичен - ибо из ТВОИХ аксиом - следует прямая неверность его выводов, а значит и подтасовки.
августа 21, 2007 6:06
abukavnev said:
Уважаемые Vlad, Tolik,
так как дискуссия, на мой взгляд, потеряла фокус и ушла куда-то в сторону, предлагаю ее завершить. Честно говоря, я потерял интерес.
Большое спасибо.
С уважением,
Алексей Букавнев,
IT Architect,
IBM Certified SOA Solution Designer,
Renaissance Credit.
августа 21, 2007 10:30
Vlad Borkus said:
>так как дискуссия, на мой взгляд, потеряла фокус и ушла куда-то в сторону
Алексей, не совсем. В статье г-на Хилла по сути была всего пара ключевых мыслей
1) В WS-S все же есть потенциальные дыры, которых не понимает рядовой девелопер (про это -- была часть II его доклада, хотя насколько они критичны -- большой вопрос)
2) В 95-99% случаев для _практически встречающихся задач_ обеспечения безопасности достаточно более простого пути -- SSL. Хотя есть новый класс задач, для которых и SSL не достаточно. Вокруг того, что это за задачи и их частоте разговор получился и у нас.
Но, конечно, беседа получется предметной, когда рассматривается совсем конкретная ситуация -- пять серверов, кто-то подменяет данные посередине или что-то похожее. Без этого, неизбежно будет преп "про вообще", к сожалению.
августа 21, 2007 11:56
От редактора said:
Так получилось, что редакторская статья промахнулась мимо двухнедельного срока и обозревает период в
сентября 4, 2007 10:30
Одно из основных правил программирования говорит о том, что специализированное решение в своей узкой области как правило будет лучше обобщенного. Это свойство всегда проявляется при выработке стандартов – в них закладывается либо самая общая, либо «усредненная» модель. В первом случае стандарт получается очень сложным, во втором – открывается поле для всевозможных фирменных расширений, его «улучшающих».
Примерно так обстоит дело со стандартами в области безопасности SOA. В стеке WS-* запланирована очень глобальная модель безопасности, включающая почти десяток всяких спецификаций (WS-Security, WS-Secure Conversation, WS-Trust, WS-Federation, WS-Policy, а также XML Digital Signature, Security Tokens Profiles (для SAML, Kerberos,X.509) и т. п.
Благодаря этому возникает целый комплекс очевидных проблем для SOA:
1) Не все эти стандарты реализованы одинаково во всех продуктах, что делает разные компоненты SOA несовместимыми.
2) Так как общие стандарты разрабатываются медленно, открывается поле для "частных" расширений вендоров, которые еще более снижают совместимость.
Я бы не стал писать про это статью, но на днях натолкнулся на интересное выступление на эту тему специалиста в области безопасности Брэда Хилла (http://www.isecpartners.com/files/iSEC_HILL_AttackingXMLSecurity_bh07.pdf). В почти 200-страничной презентации обстоятельно показывается, почему стек WS-S -- пока не лучший способ для обеспечения безопасности для открытых в Интернете сервисов,B2B-сервисов и внутрикорпоративных web-сервисов.
Во первых, для любых внутрикорпоративных и B2B ИТ-систем характерна более высокая степень доверия к их пользователям, и проблемы безопасности как правило решаются "не внутрикорпоративными фаерволами, а организационными мероприятиями и [в случае B2B] адвокатами". Главное, что должна обеспечить общая инфраструктура безопасности -- это протоколирование всех действий и точную идентификацию пользователей, получивших доступ к конкретной системе. Это тезис, с которым сложно не согласиться.
Но для этих задач ЛУЧШЕ всего подходит стандартный SSL, при одновременном применении _клиентского_ и северного сертификатов. В самом деле, у него есть набор явных преимуществ:
1) Он решает как задачу безопасной аутентификации (по сертификату);
2) Он защищает трафик от пользователя к системе;
3) Что еще более важно -- он совершенно ОДИНАКОВО реализован во всех системах, в том числе старых -- пяти и даже более летней давности;
4) Он покрывает 99% процентов того, что нужно для решения реальных задач.
Модель же безопасности на уровне сообщений, примененная в WS-S, не дает в этом смысле никаких преимуществ, так как опять-таки в 99% случая все, что от нее требуется -- это аутентификация пользователей. Но он также неодинаково реализован на новых и старых системах, а применение агентов-посредников тоже не всегда удобно и эффективно. Также WS-S (в конечном итоге за счет XML Digital Signature) опирается на шифрование больших объемов данных открытыми ключами – очень ресурсоемкая операция по сравнению с симметричным шифрованием в SSL. Поэтому при использовании для интеграции внутрикорпоративных систем WS-Security оказывается менее адекватен, чем SSL.
Но и _самостоятельное_ применение этого стека для интернет-бизнеса пока просто опасно. Так как WS-S задает модель безопасности на уровне сообщений, то каждый раз проектируя композитную систему, ИТ-разработчик по сути строит свой протокол безопасности не осознавая этого. Нет вопросов -- специалисты, которые в таких вещах хорошо разбираются не работают в обычных компаниях, а значит такой протокол будет почти наверняка ущербен с самого начала.
WS-Security плох тем, что для его реализации используется работа многих слоев (от XML Encryption, XML Digital Signature, Security Tokens Profiles (SAML, Kerberos, X.509), WS-Trust, WS-Federation и т.п) -- слишком много точек для потенциальной атаки, слишком сложно заставить все это скоординировано работать.
Брэд Хилл показывает в своей презентации как можно эти уязвимости использовать, какие есть стандартные "дыры" в реализации этих спецификаций, например, в XML Парсере. Эти дыры можно было бы отключить настройками, но сегодняшние продукты таких настроек не предоставляют. И в любом случае получается слишком много предположений о квалификации среднего корпоративного разработчика.
Вместе с тем, стек WS-S создает ряд бизнес-возможностей, таких, как цифровые деньги, DRM-применения, распределенная аутентификация, и транзакции, в которых участвуют много сторон. Но так как последствия для безопасности от самостоятельного использования этих протоколов пока до конца не изучены, то WS-S рекомендуется применять не самостоятельно, а вместе с отлаженной базой SSL.
//Влад Боркус, www.konnasi.ru
Published 19 августа 2007 г. 23:09 by Vlad Borkus Edit
Filed under: SOA, Безопасность
Comments
arkanoid said:Елашкин мне так трансляцию из ЖЖ и не настроил - а я, собственно, имел бы что об этом сказать..августа 20, 2007 0:07
abukavnev said:
Никогда не писал в блогах (в том числе и в этом) о SOA, так как все подобные дискуссии больше похожи на детский сад (no offence для блоггеров, просто констатирую факт).
Но тут задело – так что даже зарегистрировался.
Давно не читал более пристрастного анализа, чем этот Бреда Хилла.
Из текста становится ясно, что стек WS-Sec слишком сложен для ‘average systems engineer’, и вот отсюда могут возникнуть проблемы с безопасностью. Великолепный анализ! Very up-town!
А посмотрите на шедевр - Reason 2 на странице 34: Бред доказывает ненужность обмена сообщениями – так как у людей могут быть неверные “deep and unexamined expectations”.
А чего стоит сочиненные им несуществующие проблемы с SSL (Debunking SSL Myths), разбитые Бредом в пух и прах. Ай, маладца! Только ведь это известный принцип демагогов – придумать неверные аргументы, приписать их своему оппоненту, а затем их опровергнуть.
А некоторые фразы вообще бьют наповал:
“And WS-I is considered dead in the water at this point by most”. За что так WS-I? И это, заметьте, при том, что WS-I Basic Profile требует поддержки SSL, а отнюдь не стека WS-Sec.
Бог с ним! Вообще, оценивать этот поток сознания по пунктам просто не имеет смысла – там можно придраться практически к любой фразе. Перечислю просто ряд проблем, где SSL/TLS НЕ ДОСТАТОЧНО для обеспечении безопасности в SOA:
1) в SSL/TLS шифруется все сообщение, нельзя шифровать часть. А это создает следующие проблемы: невозможен content-based routing на пути от потребителя сервиса к провайдеру сервиса (например, в шине) без расшифровки сообщения; так же нельзя шифровать различные части сообщения для различных получателей на пути сообщения от потребителя к провайдеру
2) Автор, упоминая о AAA, забывает о еще одном критически важном требовании (в частности, в финансовой сфере) – невозможность одной из сторон отказаться от совершенного действия (Non-Repudiation), обеспечить которое с использованием SSL/TLS просто невозможно, так как non-repudiation требует асимметричного шифрования
3) SSL/TLS – это обеспечение безопасности точка-точка (на один хоп), обеспечить безопасность end-to-end с использованием SSL/TLS и нескольких промежуточных точек между потребителем и провайдером невозможно.
Из своей практики могу привести ряд случаев, когда использование WS-Sec более чем оправдано:
1) Когда на пути от потребителя к провайдеру есть промежуточные точки, на которых необходимо получать доступ к содержимому части сообщения, не нарушая безопасности (пример такой точки – брокер ESB)
2) Когда транспорт отличен от HTTPS или, скажем, SSL over MQI
3) При множественности security-доменов (B2B сценарии)
4) Когда необходимо обеспечить безопасность только для части сообщения, что очень часто встречается при создании композитных сервисов и BPEL-процессов
5) Когда необходимо обеспечить такие требования как SSO или federated identity (замечу, что SSL/TLS сам по себе не решает, да и не может решить этих задач)
6) Когда надо сохранять сообщения в зашифрованном виде по завершении транспортного соединения
В одном Бред прав – если основными требованиями выступает производительность и интероперабельность, то тут SSL/TLS вне конкуренции. Но для доказательства этого тезиса не надо городить весь этот бред.
Кстати, с появлением акселераторов вроде XS-40 вопрос производительности при использовании стека WS-Sec в принципе решен, в чем я имел возможность лично убедиться.
С уважением,
Алексей Букавнев,
IT Architect,
IBM Certified SOA Solution Designer,
Renaissance Credit.
августа 20, 2007 17:38
IT для бизнеса: it4business.ru » WS-Security: начинание благое, но безопасность SOA не обеспечивает said:
PingBack from http://it4business.ru/analytics/481/
августа 20, 2007 18:32
Tolik said:
2Алексей
"Из текста становится ясно, что стек WS-Sec слишком сложен для ‘average systems engineer’, и вот отсюда могут возникнуть проблемы с безопасностью. Великолепный анализ! Very up-town!
А посмотрите на шедевр - Reason 2 на странице 34: Бред доказывает ненужность обмена сообщениями – так как у людей могут быть неверные “deep and unexamined expectations”."
Налицо общая проблема умных людей и хороших специалистов - они искренне полагают всех вокруг столь же умными и тоже разбирающимися в своём предмете. Ну как в этом можно не разбираться?
Но! Брэд Хилл не только умен, но и мудр. Он знает, что ‘average systems engineer’, увы, не настолько умен и не настолько разбирается. И любая система (даже самая великолепная), превышающая его возможности понимания - увы - только во вред. Ибо никогда не будет использована правильно.
Хороший урощенный пример на тему - интерфейсы, созданные программистами (иощные, удобные, настраиваемые) - увы, не годятся для пользователя, непонятны ему и не повышают его эффективности. Эффективно он работает с чем-то искусственно упрощенным, от чего программистов воротит.
августа 20, 2007 19:40
Vlad Borkus said:
Толя, еще можно добавить принцип, использованный когда-то Microsoft: если что-то достаточно хорошо, то его и достаточно :)
Все сводится к тому, а часто ли нужна безопасность на уровне сообщения? Может чаще достаточно шифровать трафик, ну и постоянные и транзитные хранилища (в WS-S, кстати, намучаешься потом ключами управлять). Этого, насколько я знаю, хватает даже нашим спецслужбам для большинства задач. Да, будут проблемы в гетерогенной среде. Да есть проблемы при многоузловой марушрутизации. Но может проще доступ к узлам ограничить и отказаться от гетерогенного транспорта? Пусть в КИС везде стоит MQ Series, кто против?
Опять, весь это задача баланса цены скрываемых секретов и затрат на реализцию безопасности. А Хилл на самом деле просто поднял вопросы из области здравого смысла.
А Анатолий, помню, про управление рисками написал целую статью. :))
августа 20, 2007 20:33
abukavnev said:
Уважаемый Tolik,
мой пост просто преследовал целью показать, что Бред Хилл, используя явные демагогические приемы (умалчивание неудобных фактов, передергивание и местами прямой обман) пытается доказать, что SSL/TLS "лучше", чем WS-Sec. Это больше напоминает религиозные мантры, чем объективный анализ.
Я привел несколько случаев, где SSL/TLS не работает, а WS-Sec - отлично справляется. Их всего 3. Так что у вас есть возможность объективно доказать, что для указанных мной случаев SSL работает (что, скажем сразу, Вам не удастся), доказав тем самым правоту Бреда о единственно верном разбивании яиц с острого конца. А рассуждения о умности/мудрости тех или иных субъектов - субъективны и не проверяемы.
Уважаемый Vlad,
" Может чаще достаточно шифровать трафик" - может. Никто и не спорит. Дело лишь в том, что SSL подходит для обеспечения безопасности в SOA не всегда. Попытка доказать обратное, предпринятая Бредом, убога и просто смешна любому, кто в теме.
Что "ну и постоянные и транзитные хранилища"?
"в WS-S, кстати, намучаешься потом ключами управлять" - Вы пробовали?
"Этого, насколько я знаю, хватает даже нашим спецслужбам для большинства задач" - о спецлужбах не мне судить (не буду даже спрашивать, какая из обилия служб решила применить подход SOA). Опять вы про "большинство задач", когда достаточно шифровать траффик.. Приведенные мной 3 случая - как раз типовые для SOA, и в SOA они вполне могут входить в это "большинство".
"Но может проще доступ к узлам ограничить и отказаться от гетерогенного транспорта?" - что именно ограничить - не совсем понятно. Сформулируйте более четко, пожалуйста. "Отказаться от гетерогенного транспорта" - в практике не всегда возможно и даже зачастую строго противопоказано по огромному ряду объективных как технических, так и организационных причин.
"Пусть в КИС везде стоит MQ Series, кто против?" - объективная реальность против.
"А Хилл на самом деле просто поднял вопросы из области здравого смысла" - он их не поднял, а постарался закрыть, отказавшись от этого самого здравого смысла.
С уважением,
Алексей Букавнев,
IT Architect,
IBM Certified SOA Solution Designer,
Renaissance Credit.
августа 20, 2007 21:56
Vlad Borkus said:
Уважаемый Алексей,
этот спор тяжко вести по той причине, что я совсем не против WS-S (хотя броский заголовок я и дал). Но я не считаю WS-S инструментом, который нужно непременно применять везде. Более того, мне кажется, что чаще, чем реже можно пользоваться более простыми решениями.
По пунктам
п.1. Есть такая проблема. Но насколько она критична? В большинстве ERP данные вообще не шифруются. Часто ли нужно, чтобы они были зашифрованы на шине ESB внутри организации _при условии_, что все каналы между узлами ESB защищены и транзитные хранилища тоже? Это вопрос доверия к безопасности серверов на которых стоит ESB.
п.2. Невозможность отказаться от совершенного действия обеспечивается договором сторон (юридическими документами), а не техникой. На самом деле пример – я использую систему клиент-банк, и не могу отказаться от проведенной в ней операции по условиям договора. Да, банк принял технические меры защиты (кстати, там используется SSL-шифрование и аутентификация. SSL использует несимметричные ключи, симметричные – это только на период сессии), но веб-сервисов и WS-S там и близко не нет. Усилит ли банк безопасность, если он на каждое мое сообщение будет навешивать ярлык и его потом хранить? Возможно немного усилит, но насколько это для банка важно? Ведь все риски я принял на себя. И более того, _приближающуюся по силе_ вещь (хотя совсем не идентичную) он может сделать за счет взаимной авторизации всех серверов, а также авторизации конечного клиента. Иначе говоря, если одна система банка доверяет другой системе банка. Дальше – вопрос журналов и их неподдельности. Да, риски раступ пропорционально числу обрабатывающих серверов, но так ли много серверов по пути? (Есть еще одна ветвь -- расширение данных. Но всегда ли нужно запрашивать у других систем данные именно от имени клиента?)
п.3. Да, на уровне сообщения безопасность end2end обеспечить не возможно. Но за счет установления комплекса доверительных отношений между системами/узлами – можно обеспечить _возможно приемлемую_ безопасность КИС в целом. Если таких доверительных отношений построить нельзя, то, вариантов кроме WS-S нет. Но опять-таки WS-S против SSL – это классический разговор про атаку «человека посередине». Ее можно устранять (WSS) или минимизировать разными способами. Вопрос цены.
По другим вопросам.
Про ключи. Для SOA, не делал, но было для других задач. Беда ключей и ЭЦП в том, что они имеют срок годности. Возникает вопрос о том, сколько времени можно хранить эти сообщения. 5 лет -- OK, больше – чего делать с ключами и сообщениями? Вторая беда -- разрастание хранилища уже самих ключей.
Да, не всегда удается добиться негетерогенной среды (скажем в B2B точно). Но в гетерогенной среде будет масса своих проблем. Самая мелкая из которых – что делать, когда есть «тонкие различия» в поддержке WS-S и шифрования участниками взаимодействия? ((Кстати, у IBM есть Red Book на тему как стыковать разные изолированные ESB. Первая фраза – «лучше этого не делать». А далее 200 страниц текста, как сделать хотя бы плохо работающее решение.))
Опять-таки, на мой взгляд, проблема со стеком WS-S – это появление нового довольно сложного звена в системе. О нем приходится помнить. Это overhead.
Есть только один абсюлютный мотив -- мы снижаем зависимость от администраторов системы. Но опять возникают вопросы цены и рисков.
августа 21, 2007 0:22
Tolik said:
2Алексей
Понимаешь, мы так никогда не придем к согласию, ибо дискутируем о перпендикулярных вещах. Да, конечно WS-Security функциональнее, кто же спорит-то? Проблема - вовсе не в недостаточной функциональности, она в избыточной и вызванной ею сложности, тут аспекты не технические, а психологические. Об этом Б.Х. и писал.
А рассказывая, как тонко можно настроить WS-Security - ты льёшь воду именно на его мельницу. Он О ТОМ ЖЕ САМОМ, только выводы противоположные. :-)
Просто "здравый смысл" немного разный. Само собой - при дискуссии о том, что есть "здравый смысл" - мы дискутируем на уровне разных аксиом, а не общих аксиом и разных выводов. Естественно - при такой дискуссии оппонент будет неизбежно демагогичен - ибо из ТВОИХ аксиом - следует прямая неверность его выводов, а значит и подтасовки.
августа 21, 2007 6:06
abukavnev said:
Уважаемые Vlad, Tolik,
так как дискуссия, на мой взгляд, потеряла фокус и ушла куда-то в сторону, предлагаю ее завершить. Честно говоря, я потерял интерес.
Большое спасибо.
С уважением,
Алексей Букавнев,
IT Architect,
IBM Certified SOA Solution Designer,
Renaissance Credit.
августа 21, 2007 10:30
Vlad Borkus said:
>так как дискуссия, на мой взгляд, потеряла фокус и ушла куда-то в сторону
Алексей, не совсем. В статье г-на Хилла по сути была всего пара ключевых мыслей
1) В WS-S все же есть потенциальные дыры, которых не понимает рядовой девелопер (про это -- была часть II его доклада, хотя насколько они критичны -- большой вопрос)
2) В 95-99% случаев для _практически встречающихся задач_ обеспечения безопасности достаточно более простого пути -- SSL. Хотя есть новый класс задач, для которых и SSL не достаточно. Вокруг того, что это за задачи и их частоте разговор получился и у нас.
Но, конечно, беседа получется предметной, когда рассматривается совсем конкретная ситуация -- пять серверов, кто-то подменяет данные посередине или что-то похожее. Без этого, неизбежно будет преп "про вообще", к сожалению.
августа 21, 2007 11:56
От редактора said:
Так получилось, что редакторская статья промахнулась мимо двухнедельного срока и обозревает период в
сентября 4, 2007 10:30
Комментариев нет:
Отправить комментарий