VladiChНо существуют и другие способы взлома, для которых эти рекомендации не подойдут, ....
OK, то есть от хэша мы отвязывается.

Честно говоря, обсуждать некую глобальную "защищенность вообще" я не готов, во всяком случае детально. Давайте локально сойдемся вот на чем: данная статья сама по себе никак не свидетельствует о том, что Oracle беззащитен и обязательно должен быть укрыт от непосредственного доступа.

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

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

VladiChЗдесь все очень просто: если потери от простоя СУБД в случае подобной атаки будут превышать стоимость организации необходимой защиты, то собственно такая защита необходима. Время простоя можно оценить с более-менее приемлемой точностью.
Не возражаю. Повторюсь: начинать имхо следует именно с этого, а не "любой организации, которой важна стабильная работа..."

VladiChDoS-атака как правило не позволяет получить контроль над атакуемой машиной, просто выводит соответствующий сервис из строя на некоторое время или до перезагрузки. Следовательно, в случае ограничения доступа к СУБД на сетевом уровне это атакующему никак не поможет, только сломает внешний интерфейс к СУБД, внутренний будет работать как и работал.
Где-то сломанного внешнего интерфейса будет достаточно. Где-то - внешнего интерфейса вообще нет, есть только внутренний. Где-то названная Вами ситуация - устраивает. Oracle, насколько я помню, от DOS-атак защищался. В любом случае все это надо смотреть применительно к конкретному случаю, не из общих соображений.

Поясню: мне, собственно, не нравится точка зрения "заведомо не защищен". Ничего более.

VladiChЭто я и подразумевал, говоря "важна стабильная работа", так что противоречия не вижу.
Противоречие в том, что Ваше понимание стабильности (метрика, которой Вы пользуетесь), не единственно. Как любили когда-то говорить - "поосторожней с кванторами".

Позволю себе цитату:

Я считаю, что организация, для которой важна стабильная работа СУБД и конфиденциальность хранящейся в ней информации, должна строить многуровневую защиту,

Резюме: я считаю, что многим организациям, для которых важна стабильная работа СУБД и конфиденциальность информации в ней, одноуровневая защита даст вполне адекватное решение.

Разница между моим "важно" и Вашим "важно" - исключительно в численном значении метрики.

VladiChЕсли стабильность внешнего интерфейса важна для компании (в том же смысле, что и "важна стабильная работа"), то это отдельный разговор, также как и в случае когда есть только внутренний интерфейс. Разумеется, в каждой конкретной ситуации есть много своих нюансов, но я считаю, что некий обобщенный подход к обеспечению безопасности СУБД можно вывести.
Некий обобщенный подход вывести можно, но в практичности полученного результата я изрядно сомневаюсь. Это будет очередной монстр.

Собственно, такие вот обобщенные подходы уже выведены в других областях. Например, они называются SAP R/3 и Oracle E-Business Suite. Следует ли из этого, что любой фирме, которой важна автоматизация бизнеса, следует внедрять один из этих продуктов?

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

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

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

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

VladiChТо есть я за то, чтобы подходить к оценке безопасности системы изначально пессимистически.
Если говорить о "взламывается все" - безусловно. Вопрос в том, что далеко не всегда имеет смысл подходить к безопасности с точки зрения информации, стоящей, допустим $10.000.000.

VladiChСогласен, данная статья об этом не говорит, она говорит только об одной проблеме и способе относительно надежно эту проблему решить. Но я говорю о проблеме обеспечения безопасности СУБД, которая гораздо шире, а данные из этой статьи являются для меня одним из аргументов в пользу дополнительных уровней защиты.
Хм. Боюсь, не вижу логики в рассуждении: "проблема может быть надежно решена, но тем не менее ее существование является аргументом в пользу поиска дополнительных решений". Опять-таки, пока мы не говорим о некоей абсолютно максимизированной защите.

UrryMcAзаготовка классификации 2/3 звенной архитектуры. Где-то была нормальная (не нашел). Пришлось лабать по памяти.
Я бы отделил варианты User Interface и Remote UI Engine / Terminal (например, для того же веба). Это довольно сильно меняет картину с точки зрения защищенности (в частности, второй вариант в определенной степени защищает бизнес-логику от ошибок переполнения или несовместимой комбинации параметров).

UrryMcAНасколько понял - основная война здесь между адептами п.5, которые думают, что "нормальная" трехзвенка - это 6. и спецов, которые ничего плохого в п.9. не видят.
Не вижу, с чего Вы сделали такой вывод, как впрочем и нашли "войну". Такое впечатление, что просто наткнулись на любимую тему.

VladiChАналогия несколько некорректна. Вы путаете подход с конкретными средствами.
Нисколько. Я указал известный представителей определенного класса средств, реализующих подобный подход.

Попросту - далеко не всегда осмысленно палить из пушки по воробьям.

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

Если говорить о безопасности Оракла, в ней безусловно есть проблемы (как и в любом другом распространенном продукте), но как раз в данном случае я проблемы не вижу ("делайте пароль достаточной длины" - рекомендация абсолютно ко всем).

VladiChВ конечном итоге, вопрос о выборе стратегии защиты, как Вы правильно сказали, упирается в количественные и качественные оценки ситуации, которые, как я вижу, для Вас существенно зависят от доверия к конкретному производителю СУБД.
Отнюдь. Если говорить о качественной оценке ситуации, то я в первую очередь не доверяю наколеночным решениям - из-за низкой вероятности того, что стратегия защиты была продумана компетентными специалистами и реализована со знанием необходимых деталей. Я полагаю эту опасность более серьезной, чем опасность известности проблем известного же продукта.

Практически - я видел впечатлившее меня количество/качество реализаций, которые именно что ослабляли суммарную защиту относительно варианта "выставить неприкрытую БД". Скажем, в этой статье говорится о "соли". Правильно говорится - но как Вам вариант, в котором защита опиралась на первые пять букв логина?

Это, разумеется, не относится к частным решениям проверенного и подтвержденного качества.

VladiChВы рассуждаете несколько абстрактно об этом, а теперь попробуйте поставить себя на место человека, который, я извиняюсь, своей задницей отвечает за безопасность системы, и при этом есть довольно ненулевая вероятность того, что эту систему будут ломать. Я думаю, в этом случае для Вас приоритеты выстроятся примерно в той же последовательности.
У меня на это будет два ответа.

1. То есть, говоря абстрактно, Вы таки ставите задачу максимизации; сколь возможно защищено независимо от стоимости. Если помните, я сразу сказал, что в этом случае, безусловно, защита СУБД должна быть последним рубежом и перед ней должна быть куча других.

2. Я стоял на этом месте, только не в плане безопасности, а в плане надежной-бесперебойной работы. Довольно быстро моим рекомендациям стали доверять, по-моему не столько из-за аргументации, сколько из-за того, что предсказанные мной проблемы пару раз сбывались.

UrryMcAМожно картинку?

[Storage, BL] <---> [BL, Remote UI Engine] <---> [Terminal/Browser], примерно так.

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

UrryMcA>>Такое впечатление, что просто наткнулись на любимую тему
Тема N-tier - скорее "больная" или "животрепещущая".
И это тоже.

Просто, судя по Вашим письмам, Вы пробежали тему весьма мельком (что вполне понятно, учитывая размер) и говорите "по старой памяти", по следам кучи других таких тем. Например, я здорово не уверен, что Вы сможете показать в этой теме хоть одного "апологета 5", если не спутал, "который считает, что трехзвенка - это 6". А такой подход типичен для случая, когда позиция сформирована, забронирована и принципиально непоколебима задолго до начала обсуждения. Сравните, например, с письмом Aviant чуть выше.

OK. В целом я согласен с Вами, исключительно отдельные замечания, которые наверное стоит опустить для экономии места и времени.

Кстати, веб-приложения - это все-таки 3-хзвенка. В вырожденном варианте, когда браузер используется только для отображения информации, эта модель близка к 2-хзвенной,
У меня на эту модель есть хороший пример - это такая же трехзвенка, как если я возьму RAdmin, XWindows или любое другое приложение, поддерживающее концепцию удаленного десктопа, зайду им на машину, на которой крутится клиент "обычного двухзвенного приложения" и буду так работать.

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

VladiChДанные ездят в любом веб-приложении, так что сравнивать их с терминалом некорректно.
Данные в тонком клиенте ездят практически так же, как в терминале, только собранными в пакеты.

Главное здесь - в обоих случаях, вмешавшись в работу на этом участке, я не смогу сделать того, чего не позволяет интерфейс (в том виде, как он реализован на UI Engine). Если же я подключаюсь непосредственно к слою бизнес-логики, я могу вызвать любые процедуры в любой последовательности с любыми параметрами итп - соответственно, возрастает уязвимость этого слоя.

VladiChНо я говорил не об этом. Веб-приложения бывают ведь разные.
Безусловно. И если не ошибаюсь, я нигде не говорил, что "все веб-приложения являются тонкими клиентами". Я сказал "например, веб" - поскольку такая организация типична именно для веб-приложений.

UrryMcA>>Если подключаюсь непосредственно к слою бизнес-логики, я могу вызвать
>>любые процедуры в любой последовательности с любыми параметрами итп -
>>соответственно, возрастает уязвимость этого слоя.

Не факт.
Факт. Впрочем, возможно мы уперлись в терминологические различия.

UrryMcAДо того как данные дойдут до слоя бизнес-логики они в любом случае пройдут ч/з процесс аутенификации, анмаршаллинга и валидации (это кстати заметно увеличит время отклика).
Безусловно, пройдут. Все это - сугубо технические операции, не имеющие отношения к сути выполняемых действий.

UrryMcA"Просто так" послать "от балды" пакет данных и повесить сервер(испортить данные) не получится (по крайней мере в грамотно спроектированой системе).
Это можно сделать только "разобрав" клиента и переписав его.
C точностью до терминологии - безусловно. И "от балды" - нигде не предлагается.

Постараюсь сформулировать еще раз, максимально четко:

Допустим, у нас есть бизнес-функции P1, P2, ... PN, PSuper.

Интерфейс может быть организован и практически всегда организован так, что эти бизнес-функции могут быть вызваны только в некоторых из теоретически возможных комбинаций. Например, только так: Pi ¹ , PSuper, Pi ² , PSuper, .....

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

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

В случае, если терминальный сервер, ?sp-движок итп. расположен на промежуточном звене, подобное нарушение невозможно.

Вывод: организация сервера "с открытой наружу бизнес-логикой" в принципе является определенным фактором риска и терминальная организация работы с этой точки зрения имеет некоторое преимущество.

UrryMcAНо и это не даст 100% гарантии хака БД. Т.к. есть еще слои, которые отвечают за логическую целостность БД и система прав доступа.
Безусловно. Но мы же говорим с позиции человека, которому нужно 0% вероятности..

awhilerЭто значит ошибку архитектора.
Допустим. И кому легче от того, что система будет взломана из-за ошибки архитектора?