Снова о безопасности SOA и XML-firewall'ах

[arkenoi]

Многие читали, наверное, довольно толковую статью. Однако, один момент там совершенно не рассматривается - а что, собственно, такое - XML-firewall? В лучшем случае о нем говорится установкой галочки, что он "есть".

В случае с XML мы оказались примерно в той же ситуации, что пользователи сетей tcp/ip в самом начале 90-х - есть протокол более низкого уровня, есть поверх него протоколы более высокого уровня и нужно как-то при этом отделить овец от козлищ, причем разумно. Галочка "XML-firewall - есть!" это примерно то же самое, что уравнять в правах и функциональности Cyberguard и iptables в коробочке от D-Link.

А что же, собственно, должен делать XML-Firewall? Многим приходит в голову очевидный ответ: XML безопасность == WS-Security. Правильно? Неправильно.

Если воспользоваться нашей аналогией, WS-Security- это такой "ipsec". Аутентикация, identity management, шифрование. А мы работаем с чем? С конкретными сервисами и протоколами. И нам нужно пропускать то, что необходимо, не пропускать все остальное и еще описывать это в понятной человеку, а не только машине, форме.

Что для этого есть? Когда я занимался проектированим firewall для SOAP и XML-based протоколов вообще (реализация проекта была временно отложена, но я надеюсь, что эти наработки еще пригодятся), в диалоге с потенциальным заказчиком и в результате внутренних обсуждений нарисовались два уровня:

1) Валидация. DTD, схемы. Есть очевидная проблема: схемы, а DTD уж тем более, как правило, пишутся "нежестко". То есть они не описывают строгий допустимый и осмысленный формат, а в "вольной форме" излагают, что там "вообще может быть", включая бессмысленные сочетания данных, которые могут быть потенциально небезопасны. Это не недостаток XML-схемы как описательного формата per se, а скорее результат лености авторов, но нужно иметь в виду эту особенность.

2) Политика. Если мы уже знаем, что протокол соответствует спецификации и не может вызвать непредсказуемых переходов состояния в обслуживающем сервисе (блажен, кто верует), то теперь нам нужно наложить политику, какие именно данные являются допустимыми, что нужно протоколировать и т д. Адекватным инструментом выглядит XPath, но он имеет свои ограничения. В частности, описание сложных взаимосвязей между наличием тегов и значениями атрибутов может быть не очень наглядным.

Вот здесь, кстати, есть интересный документ, но в нем глубокого рассмотрения этих вопросов также не видно:
https://www.owasp.org/index.php/Category:OWASP_XML_Security_Gateway_Evaluation_Criteria_Project_Latest

А вот вы при планировании архитектуры безопасности - что именно хотели бы от XML-firewall?

Кстати, от WS-Security я не открещиваюсь - часть функций вполне можно возложить на firewall, просто это - не основное его назначение.

Comments

[alexott.livejournal.com]

Часть функций WS-Security (проверка подписей и т.п.) можно вынести и в firewall, чтобы снизить загрузку сервисов

[arkanoid.livejournal.com]

Да я не отрицаю, возможно это стоит внести в текст.

[pzrk.livejournal.com]

Да как обычно - фильтрацию и валидацию...

[pustota1.livejournal.com]

Я бы хотел, чтобы перестали валять дурака и посмотрели как сделаны
все GSM MAP (который описан в ASN.1) screens, после чего часть
идей следует оттуда украсть с криком -- вот оно -- последнее слово
в IT безопасности, у кого нету -- тот лох и начать заниматься
написанием примерно похожим по функциональности XML-firewall.

[tsw.livejournal.com]

как специалист в теме скажу, что УВЫ - GSM MAP очень плохо спроектированная штука!
отсюда желание ввести MAP-SEC, который скорее всего никогда не приживеться =)

[pustota1.livejournal.com]

Как вышедший постоять, воздухом рядом с экспертами подышать тоже скажу --
GSM MAP, как почти любой плод, коллективоного труда очень неоднродная штука, с
неочевидными для многих предположениями о окружении в котором протколу придется работать, ASN.1 ччасть, однако, никаких ни нареканий, ни вопросов ни у кого не
вызывала. Соответсвенно и screens (экраны) и рекомендации что конкретно экранировать особых вопросов не вызывало.

[xsaper.livejournal.com]

Как бы пошло это ни звучало, я уверен, что промышленные клиенты захотят автоматики вида: есть набор схем/описаний/dtd, как только fw видит протокол, использующий xml, так сразу он проверяет его согласно этим наборам. То есть чтобы не было обязательно ручной настройки по включению проверки на XML fw каждого протокола.

[xsaper.livejournal.com]

Тут возможно появление недостатков, присущих layer-7 для iptables/netfilter.

[liao.livejournal.com]

Слушай, а вот это pustota оно живое или робот? шойта уже который раз как не увижу это у тебя в комментах, так сразу начинаю сомневаться в её органическом происхождении.

[pustota1.livejournal.com]

Мы, роботы органического происхождения, на нашем стальном, высоколегированным хере Ваши сомнения крутили.

[bars-team.livejournal.com]

> А вот вы при планировании архитектуры безопасности - что именно хотели бы от XML-firewall?

1. проверки валидности xml [проверка коретности]
2. проверка по DTD, xsd схемам(нужные схемы загружаются на firewall предварительно) [функции фильтра]
3. в случае обнаружения уязвимостей при обработке определённого xml документа (xml-вирус), сюда же проверку на такой патерн. [функции антивируса]

[arkanoid.livejournal.com]

Ну, то есть я в верно все оценил. Теперь все упирается в реализацию - libxml2 использовать по понятным причинам нельзя ;-)

[alexott.livejournal.com]

arabica с expat backend'ом или xerces-c?

Куплю лицензионный Windows

[(Anonymous)]

Куплю Windows Куплю Windows -2003/XP/Vista sms5@inbox.ru
и другое ЛИЦЕНЗИОННОЕ ПО Microsoft
предложения на е-мейл sms5@inbox.ru

Re: Куплю лицензионный Windows

[arkanoid.livejournal.com]

дядя, эти грибы нельзя запивать текилой.