Alexey Rovdo VladiCh
Вообще обеспечить гарантию неизменности клиента - задача нереальная, да и смысла в этом я особого не вижу.

Аппаратно вероятно решаемо и будет таки решено. Например, с переменным успехом это удается делать производителям игровых приставок (XBOX, PS ...) , которые ведут постоянную борьбу с пользователями, модифицирующими эти приставки для разных целей. Разработанные в этой борьбе технологии элементарно затем перенесутся и во все другие области.
Полностью нерешаемо в принципе. Аппаратный взлом просто более дорогой, не у каждого хакера есть доступ к соответствующему оборудованию и технологиям. Я согласен, если есть _грамотная_ аппаратная защита, обойти ее очень сложно, но ничего невозможного нет :).

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

Подниму топик....
На 9 странице тут обсуждалась проблема слабости хэшей в MSSQL.
Недавно оказалось, что и Oracle в этом плане ничем не лучше, если не хуже.
Подробности тут . Так что... еще один камень в огород тех, кто полагается только на механизмы security СУБД.

softwarerХм. Боюсь, с этой ссылкой у меня что-то не в порядке, но подозреваю, речь в очередной раз идет о теоретической возможности вскрыть по хэшу пароль сиса.
Там во втором фрейме должен pdf-документ открываться. Прямая ссылка тут . Да, речь идет о взломе хэша. Возможность для меня тоже чисто теоретическая, т.к. я сам взолмом профессионально не занимаюсь, но я знаю пару людей, которые этим занимаются вполне профессионально, и это для них сугубо практическая возможность. Если вы читали например мое сообщение про способ обойти стандартную систему security MSSQL, то поймете в чем дело. Там даже не надо иметь права на чтение из системных таблиц. Да, у инсайдера больше возможностей для такого взлома, т.к. как правило члены домена имеют бОльшие права на сервере СУБД, чем внешние пользователи. Но и у внешних пользователей такие возможности есть плюс постоянно появляются новые и сисадмину нужно очень быстро закрывать различные дырки, т.к. если кто-то целенаправленно хочет взломать именно эту систему, он будет использовать все имеющиеся возможности для этого.

softwarerМои же выводы таковы: во-первых, сочетая имеющиеся инструменты и пару мелких трюков, возможность атаки Oracle через хэш можно свести до сугубо теоретической; во-вторых, я думал, как ломал бы этот сервер, и считаю более перспективным другое направление, о котором, по-моему, особо никто не задумывался (во всяком случае не видел публикаций на эту тему).
Какое направление вы считаете болеее перспективным, если не секрет?

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

softwarerВывод этой статьи конечно практичен, но он тоже не панацея.Если смотреть с Вашей (видимо) точки зрения, панацеи нет вообще.

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

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

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

softwarer
Далее, на любой приведенный Вами аргумент легко найти ответ, например, DoS-атака - СУБД может быть устойчива к ней, а вот предыдущий уровень рухнуть и позволить атакующему решить свою задачу. И не забывайте, что ахиллесова пята многоуровневой защиты - возможность (при мелкой ошибке в ее организации) достичь необходимого, не взламывая последние рубежи.

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

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

Разумеется. Я регулярно консультируюсь с такими специалистами по различным вопросам, и считаю что моих знаний + знаний этих консультантов вполне хватит для того, чтобы продумать стратегию защиты. Конкретные меры конечно же должны принимать соответствующие специалисты.