Mainframe_старыйДавно пора в вузах ввести курс - управления правами доступа.
Хм. Неужели изложение мысли "не изобретай велосипед" должно занимать целый семестр? Имхо тех, для кого оно так, лучше сразу пристрелить, дабы других не мучали....

Mainframe_старыйПолучилось неплохо, местами даже лучше, чем в классике, но возможно за это время мы могли бы сделать еще кое-что полезное.
Делать именно RBAC или нечто очень похожее имхо неоправданно - согласен, лучше потратить это время на что-нибудь полезное. Имхо свою безопасность имеет смысл делать ради какой-то другой либо другой идеологии защиты, той же мандатной. Скажем, я имел дело с одной интересной собственной системой безопасности; там идеология была кардинально расширена за счет следующих моментов:

1. Набор допустимых результатов был шире, нежели "пустить/отказать". Кроме этого было кажется три варианта, объединенных смыслом "запросить разрешение на операцию" - то есть, "ответственному" уезжал скриншот и информация вида "пользователь такой-то просит разрешения сделать то-то", ответственный давал добро, и после этого операция выполнялась (один из вариантов - пользователь повторно выполнял то же действие, и на этот раз безопасность его пускала).

2. Permission-ы были параметризованными. То есть, например, операция "выписать подарок клиенту". Для продавца лимит цены подарка установлен в 20 у.е., для ведущего продавца - в 100 у.е. Соответственно, подарки в пределах лимита сотрудник выписывает под собственную ответственность; при превышении лимита запрашивается разрешение начальника отдела.

LSVРазделять доступ к данным в полной мере не получится, т.к. далеко не вся логика укладывается в права чтения/записи определенной таблицы. Всё равно неизбежно использование мер безопасности на клиенте.
Хм. Странное утверждение.

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

2. Насчет "неизбежно".... Вы имхо очень преувеличили. Я бы сказал, большинство приложений таки избегают.

Как запретить пользователю менять данные в док-те с определенным статусом ?
Триггер.

Как запретить менять(видеть) конкретное поле ?
Триггер (view).

Как запретить ставить определенные значения ?
Триггер.

Как запретить менять(видеть) определенные записи ?
Триггер (view).

Единственный выход для хорошей безопасности - всё делать через хранимые процедуры.
Но там появится масса других проблем.
И это тоже вариант. В MSSQL, кстати, в этом плане хороша концепция inline table function (хотя я и продолжаю считать, что их следовало бы назвать параметризованными view).

Авторизатор- Программа в общем случае представляет набор форм которые работают к таблицами БД (MSSQL2к).
- Собственно разрешение на запуск формы и лимитирует пользователей в правах.
Этого как правило недостаточно - как правило, требуется выдавать права на отдельные операции на форме (точнее - оказывается слишком неудобным делать свою форму под каждую операцию, нуждающуюся в автономной выдаче прав). Даже если сейчас это устраивает, серьезно подумайте, сохранится ли такая ситуация в будущем.

Ну а теперь: исходя из этого, получаем следующее:

1. В БД создается набор ролей, соответствующий формам (либо роль для каждой формы, либо объединенные роли для нескольких форм с заведомо одинаковыми правами)

2. Права на объекты, используемые формой, грантуются этой роли. При необходимости создаются объекты-прокладки (скажем, если форма должна смотреть записи из таблицы только за последний месяц, делается view, и роли грантуется это view; если должна вызывать ХП с параметром А обязательно равным 1, создается промежуточная ХП с меньшим количеством параметров, и грантуется она)

3. Форма знает свою роль и так или иначе отказывается вызываться, если у пользователя роли нет.

Вот и все. Дешево, просто и без извратов получаем неплохо защищенную систему; администратору остается только вовремя применять патчи безопасности сервера.

Mainframe_старыйА не пробовали делать Пермишины на максимальное в единый момент времени число пользователей ? меня в веб-приложениях это сильно смущает, не уверена, что стоит ломать копья. Лучше на организационном уровне договариваться.
Делал когда-то ограничение на максимальное количество сессий одного пользователя. Но такие лимиты сейчас как правило спокойно поддерживаются серверным софтом, на уровне приложения вроде ни к чему.

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

Shtock Никаким грантом Вы не пропасете сумму. А в триггере-это уже что-то писать надо. Разговор шел именно об этом!
Не совсем так, или даже совсем не так.

Говоря формально, LSV выдвинул утверждение, состоящее из верной посылки (I), ложной посылки (II), доказательства и вывода. Я подбросил ему примеров, показывающих ложность посылки II и соответственно вывода. Вы же пытаетесь объяснить мне, что посылка I истинна, и "разговор шел именно об этом".

Bibber8. коннект от SQL-пользователя к БД возможно осуществить только из приложения (так как никто кроме него не умеет расшифровывать пароль).

Bibberвы сомневаетесь в том, что программными средствами возможно зашифровать пароль так, что не зная ключа его будет трудно расшифровать за короткий срок?
Я восхищаюсь наивностью авторов подобных схем и подобных утверждений.

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

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

- читал блок, используя стандартную подпрограмму чтения (с расшифровкой)
- записывал блок мимо подпрограммы шифровки/записи.

Вот и все. Если мне не изменяет память, на все и про все - часа полтора работы.

Bibberдаже если злоумышленник получит доступ к коннекшину, то это будет доступ к его коннекшину.
Если хранимка не будет сделана столь же безответственным разработчиком и не предоставит ему пароли от чужих аккаунтов.

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

Bibberправильно я понимаю, что вы рекомендуете использовать windows-аутентификацию
Нет. Я нигде не упоминал способ аутентификации и не готов обсуждать их сравнительные достоинства.

Bibberи управлять правами на уровне сервера?
Да.

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

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

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

модХорошая оговорка - именно терминал.
И?

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

Не путайте предлоги "на" и "в" :)

DVEУспешно используется как минимум в 4-х ИС.
Сколько раз получали благодарности от взломщиков за общий вход?

DVEЕсли нужны подробности то расскажу
Хм. Лучше расскажите хоть про что-то нестандартное, что в ней есть. Хоть про что-то, что выделяло бы среди прочих.