А вот как сделано: регистрируешься на каком-нибудь сайте,

← →
tesseract © (2008-04-02 22:51) [120]

> Причем тут novell ?

Там есть решение нужное олегу :-). Каждая ветка может быть изолирована по уровню доступа, даже от самого верховного Админа.

← →
Ega23 © (2008-04-02 23:00) [121]

Короче, смысл такой:
Есть пользователи, есть "бизнес-действия". На каждое бизнес-действие пользователю либо дано разрешение, либо нет. Раздача таких прав - одно из бизнес-действий. Таким правом могут обладать несколько пользователей.
Задача: исключить возможность разоешения какого-либо бизнес-действия любому пользователю, работая с БД напрямую.
Т.е. я, как разработчик, пририехав на "объект" и подсоединившись к базе напрямую, не мог бы разрешить какому-либо пользователю право на бизнес-действие.

Как-то так.

← →
Ega23 © (2008-04-02 23:01) [122]

> KlGuy (02.04.08 22:47) [119]
>
> Бедлам какой-то. Спецъйалисты :). Куда мне там...

Вы бы зарегистрировались сперва...

← →
Мазут Береговой © (2008-04-02 23:38) [123]

> Ega23 © (02.04.08 23:00) [121]
> Короче, смысл такой:
> Есть пользователи, есть "бизнес-действия". На каждое бизнес-
> действие пользователю либо дано разрешение, либо нет. Раздача
> таких прав - одно из бизнес-действий. Таким правом могут
> обладать несколько пользователей.
> Задача: исключить возможность разоешения какого-либо бизнес-
> действия любому пользователю, работая с БД напрямую.
> Т.е. я, как разработчик, пририехав на "объект" и подсоединившись
> к базе напрямую, не мог бы разрешить какому-либо пользователю
> право на бизнес-действие.
>
> Как-то так.

Надо делать так: суп отдельно - мухи отдельно.
Если программа основана на сереверных вебскриптах (php,asp,...), то проще всего защититься от пользователя создав эккаунт для вебсайта.

1. Защищаем БД от юзеров:
Значит, ренгистрируешь webapp под iis. Создаешь app pool для этого webapp. Даешь этому app pool некий windows (или какая там система) системный эккаунт. Пускаешь этот app pool под этим экаунтом. Регистрируешь этот эккаунт на БД как некого юзера (или trusted или с паролем). Создаешь в БД database role. Включаешь в эту database role эккаунт своего app pool, и указываешь "размеры" допуска этой database role к БД объектам.

2. Строим юзеров:
Создаем таблицу в БД (с отдельным доступом)/xml файл/просто файл/еще что-то где храним уровни доступа/пароли/логины/адреса/явки к ресурсам/страницам/функциям вебсайта. Можно даже использовать Active Directory User Groups (даже предпочтительнее, если вебсайт на локалке).
После того как юзер идентифицирован и впущен, определяем его уровень доступа и храним его в переменной session и используем для определения доступности ресурсов на текущей странице...

← →
Игорь Шевченко © (2008-04-02 23:45) [124]

Ega23 © (02.04.08 23:00) [121]

> Короче, смысл такой:
> Есть пользователи, есть "бизнес-действия". На каждое бизнес-
> действие пользователю либо дано разрешение, либо нет. Раздача
> таких прав - одно из бизнес-действий. Таким правом могут
> обладать несколько пользователей.
> Задача: исключить возможность разоешения какого-либо бизнес-
> действия любому пользователю, работая с БД напрямую.
> Т.е. я, как разработчик, пририехав на "объект" и подсоединившись
> к базе напрямую, не мог бы разрешить какому-либо пользователю
> право на бизнес-действие.
>
> Как-то так.

Ясно. На Oracle бы подумал, про MSSQL не знаю ничего.

← →
Ega23 © (2008-04-02 23:48) [125]

> Ясно. На Oracle бы подумал, про MSSQL не знаю ничего.

Должно быть некое общее решение, "СУБД-независимое"
В принципе, есть некоторые идеи, но они ещё, как бы это сказать, в виде "образов" в башке витают. Как оформятся - отпишу.

> Мазут Береговой © (02.04.08 23:38) [123]

За идею спасибо, но архитектура системы будет несколько сложнее.

← →
Мазут Береговой © (2008-04-02 23:51) [126]

Использование Active Directory Groups.
Если локалка правильно организована, то каждый работник, должен иметь эккаунт для попадания в компутер. Так же юзеры должен быть разделены на группы, которые должны определять уровни доступа к сетевым ресурсам компании. Можно использовать эти же группы, или создать новые исключительно для сайта...

← →
Мазут Береговой © (2008-04-02 23:53) [127]

Всегда пожалуйста.. :-)

← →
Игорь Шевченко © (2008-04-03 00:16) [128]

Ega23 © (02.04.08 23:48) [125]

> Должно быть некое общее решение, "СУБД-независимое"

В Оракле это можно реализовать ролями. Как это делается в MSSQL я не знаю. Независимое от СУБД решение основано на GRANT и REVOKE :)

← →
Ega23 © (2008-04-03 00:20) [129]

> В Оракле это можно реализовать ролями. Как это делается
> в MSSQL я не знаю. Независимое от СУБД решение основано
> на GRANT и REVOKE :)

да вот как раз это дело в бошке и вертится. только ещё не оформилось окончательно... :)

← →
Игорь Шевченко © (2008-04-03 00:31) [130]

От разработчика ты можешь обезопаситься, а от администратора базы данных - нет.

← →
Мазут Береговой © (2008-04-03 01:54) [131]

> Игорь Шевченко © (03.04.08 00:16) [128]
> Ega23 © (02.04.08 23:48) [125]
>
>
> > Должно быть некое общее решение, "СУБД-независимое"
>
>
> В Оракле это можно реализовать ролями. Как это делается
> в MSSQL я не знаю. Независимое от СУБД решение основано
> на GRANT и REVOKE :)

Это то, о чем я писал в пункте 1;
В MSSQL есть GRANT (неуверен насчет revoke);
Хотя, может это разные вещи в Oracle & MSSQL;

← →
Ega23 © (2008-04-03 07:44) [132]

есть там и grant и revoke

← →
tButton © (2008-04-03 08:02) [133]

недочитал, ибо вариант
хранить права отдельно шифруя мд5(юзер.право)
по одному праву на запись
обратно - перебором.

← →
tesseract © (2008-04-03 10:01) [134]

> хранить права отдельно шифруя мд5(юзер.право)

А Админу как ?

← →
tButton © (2008-04-03 10:55) [135]

просмотр прав пользователей - поиск перебором
добавление права - внесение сгенерированой записи
удаление права - поиск сгенерированой записи и удаление оной

← →
Ega23 © (2008-04-03 11:10) [136]

> просмотр прав пользователей - поиск перебором

Это в смысле брурфорсом? :)

← →
Дмитрий С (2008-04-03 11:31) [137]

> Это в смысле брурфорсом?

А что, долго чтоли?

Кстати, всетаки левый администратор должен не иметь прав только изменять данные, или же изменять и видеть??

← →
Ega23 © (2008-04-03 11:38) [138]

Ну видеть-то он их по-любому сможет.
Нет, только изменять.

Точнее, изменить-то он тоже может. Только вот "повысить" права доступа не сможет.

← →
KlGuy (2008-04-03 16:07) [140]

Сколько еще человек должны повторить эту простую мысль:

> Игорь Шевченко © (03.04.08 00:31) [130]
> От разработчика ты можешь обезопаситься, а от администратора
> базы данных - нет.

?

← →
Дмитрий С (2008-04-03 16:11) [141]

Ну так это ж можно сделать дополнительным полем (контрольный хеш на основе данных о записи и некому секретному ключу, который храниться у программы в другом месте и для каждого клиента уникален и известен только ему).

> и для каждого клиента уникален и известен только ему

Так как редактировать права пользователя, если эта штука известна только ему? :)

На самом деле решение, вроде как найдено. Комбинированный способ через GRAND на 2 разные роли + шифрование по алгоритму.

Сдается мне, что шифрование здесь - это хороший способ выстрелить себе в ногу

> Сдается мне, что шифрование здесь - это хороший способ выстрелить
> себе в ногу

Тут фишка такая, что я, имея прямой доступ к базе, не мог сказать: "вот этому товарищу разрешено это, это и ещё вот это, а другому - только то".
С учётом того, что обращений будет совсем не много - сойдёт.

Ega23 © (03.04.08 16:58) [144]

Так может быть прямой доступ к базе тебе не надо иметь ? А нужный доступ иметь только тем, кому это по должности положено ?

> А нужный доступ иметь только тем, кому это по должности
> положено ?

Вот им и нефиг смотреть.
Игорь, так долго объяснять, я лучше в пятницу расскажу.

А вот как сделано: регистрируешься на каком-нибудь сайте, Найти похожие ветки