Разграничение доступа

← →
KygECHuK © (2006-07-13 17:14) [0]

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

← →
Desdechado © (2006-07-13 17:41) [1]

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

← →
KygECHuK © (2006-07-13 17:49) [2]

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

← →
Desdechado © (2006-07-13 17:55) [3]

Если функциональность отражает структуру БД, читать GRANT и REVOKE в справке по СУБД.
Если часть данных в таблице разрешена, часть нет, то механизмов много, но все разные и зависят от возможностей СУБД. Например, в Оракле есть row-level security.

← →
KygECHuK © (2006-07-13 18:00) [4]

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

P.S. Предлагаю продолжить завтра ,а то рабочий день подошел к концу.

← →
Юрий Зотов © (2006-07-13 18:56) [5]

> Desdechado © (13.07.06 17:41) [1]

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

:о)

← →
MikProg © (2006-07-13 19:10) [6]

> к определенным северам баз данных,

Да и к серверам вообще. Вы не подумали что пользователь может просмотреть базу и мимо вашей программы (MS Query например), если имеет соовтетствующие права

← →
Desdechado © (2006-07-13 19:10) [7]

Юрий Зотов © (13.07.06 18:56) [5]
Ай, зачем так?
Аспекты защиты непересекающиеся, а множества - запросто.
Аспект защиты - место раздачи прав.

← →
Юрий Зотов © (2006-07-13 19:14) [8]

> Desdechado © (13.07.06 19:10) [7]

Гы... да все понятно, специально же смайлик поставил...
:о)

А прикольно получилось, да? Вроде, все логично, а в итоге фигня полная.

← →
Desdechado © (2006-07-13 19:27) [9]

> в итоге фигня полная
Ну почему же? Наоборот, если
> итоговые права пользователя обычно никакие
то админу меньше проблем. Никто ничего не испортит
:))

← →
Юрий Зотов © (2006-07-13 20:20) [10]

> Да и к серверам вообще. Вы не подумали что пользователь
> может просмотреть базу и мимо вашей программы (MS Query
> например), если имеет соовтетствующие права

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

> Поводом возникновения требования разграничить права стала
> простая боязнь того, что один человек сможет по ошибке испортить
> то что сделал другой.

т.е. они вместе могут редактировать одни и те же таблицы и в то же время не изменять то что сделал другой?

вообще ответ на твой вопрос [1] можно дать только если приведешь полностью описание всей логики разграничения прав.

Логика разграничения прав проста: S.I.U.D. для каждойт аблицы. Конечно я не отвергаю решение проблемы с помощь средст серверов баз данных, но при внедрении системы заказчик не даст прав создания новых пользователей. А возможен ли перхват событий изменений данных на уровне BDE ?

Разграничение доступа Найти похожие ветки