Разделение прав доступа

Драга
Дата: 04.03.2004 18:13:07
Вопрос вот созрел, по правам доступа.

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

подумал над созданием единого интерфейса, который бы в зависимости от пользователя выдавал необходимые поля, например создать view со следующим запросом:

selece case when user in ('vasya') then password
else ''
end AS password,
case when user in ('vasya','petya') then login
else ''
end AS login
from table1

и так сформировать некий абстрактный интерфейс для доступа к базе.

Вот только думаю, может велосипед изобретаю? Может кто уже сталкивался с чем-подобным и имеем какой-нибудь опыт?
Shweik
Дата: 05.03.2004 15:55:57
Таких глобалистских желаний пока не возникало разве что идея :
Есть вьюшка регистраций пользователей - каждое новое подключение при логине добавляет
в нее строку - регистрируется -
(при этом можно отбить подключение если кто-то с таким логином уже есть или логин забанен)
- однако если все нормально - проверяется статус пользователя и динамическим
сиквелом создаются вьюшки для него. Тут основная проблема-корректно чистить эти вещи
в соответствии с существующими форками постгреса. Но мне кажется это вполне решаемо.
Maxim Timofeyev
Дата: 11.03.2004 12:21:47
автор
Есть вьюшка регистраций пользователей - каждое новое подключение при логине добавляет в нее строку - регистрируется


view же r/o. как можно в нее что-то добавить?
Покрайне мере в 7.4.1 они еще r/o.

Или я не догоняю? ;(
Maxim Timofeyev
Дата: 11.03.2004 12:23:57
автор
и так сформировать некий абстрактный интерфейс для доступа к базе.


А схемы это не то?
Я ими не пользовался пока, но кажется, что это именнг оно и есть...
assa
Дата: 11.03.2004 12:46:28
2 Maxim Timofeyev
Maxim Timofeyev
view же r/o. как можно в нее что-то добавить?


пишите RULE на INSERT и (если надо) на UPDATE

(а вью - это нынче RULE "_RETURN" AS ON
SELECT TO "имя_вьюхи" DO INSTEAD ... )

к примеру у меня работает:

CREATE OR REPLACE RULE "_INSERT" AS ON INSERT
TO tree_leaf
DO INSTEAD

(INSERT INTO tree (id, pid, pos, uname_create, uname_modify, date_create, date_modify, status )
VALUES (new.id, new.pid, new.pos, new.uname_create, new.uname_modify, new.date_create, new.date_modify, new.status );
INSERT INTO leaf (id, aid, company, kind, date, name, description, search_name, leaf_from, leaf_to, currency, value, payment_kind, planfact )
VALUES (new.id, new.aid, new.company, new.kind, new.date, new.name, new.description, new.search_name, new.leaf_from, new.leaf_to, new.currency, new.value, new.payment_kind, new.planfact ); );
CM Hungry
Дата: 11.03.2004 20:15:50
Делать доступ не через view, а через процедуры, в которые передавать id пользователя, скажем.
PostgreSQL user
Дата: 18.03.2004 14:47:19
> Хотелось бы организовать доступ к базе с разделением полномочий.

Выбираешь ssa модель - и реализуешь ее в базе данных. Посмотри на ibase.ru - по этому поводу была статья.
Shweik
Дата: 11.06.2004 18:22:22
PostgreSQL user
> Хотелось бы организовать доступ к базе с разделением полномочий.

Выбираешь ssa модель - и реализуешь ее в базе данных. Посмотри на ibase.ru - по этому поводу была статья.

Что есть и как расшифровывается SSA??? Не знаю.
Единственный материал посвященый сабжу и расположенный на ibase.ru
предлагает два пути решения проблемы ACL(Access Control Lists) и RWD - по аналогии с используемыми в WinNT(W2K/Xp) и Unix методами разделения доступа к файлам.
http://www.ibase.ru/devinfo/treedb2.htm
IMHO схема RWD (Read Write Delete/Drop??) по многим признакам идеально подходит для реализации в Postgres. У кого есть другие мнения?
guest
Дата: 16.06.2004 10:27:35
>> Хотелось бы организовать доступ к базе с разделением полномочий.

Работал на Oracle счас много делаю на Postgres. Механизм работы описанный ниже - не только мой стить - стиль многих коллективов разработчиков в финансовой сфере...

Общая безопасность и доступ к обьектам :
1. На все таблици существуют вьюхи и клиент читает только их, тем более
часто в разработках плоские таблици используются редко (только справочники некоторые - все равно есть вьюхи), организация связи таблиц тож во вьюхах.
Прав на таблици у клиентов вообще никаких нет. В итоге имеем для чтения
данных только вьюхи.
2. Модификация данных только через функции. Во первых всю бизнес логику
я размещаю только на серваке, во вторых всяческие проверки/валидности тож на серваке. Функцию создаем с опцией - например SECURITY DEFINER - она будет работать с правами создателя, юзеру дадим права только на выполнение функции. В итоге модификация данных происходит по строгим правилам описанным в функции.

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

Теперь про разделение полномочий юзверей:

1. Можно сделать свою табличку юзверей и много колонок с различными признаками (о синхронизации создания юзверя в табличке и на сервере я рассказывать не буду). Создаеш функции проверки всяки какие угодно и ...
2. Для чтения нужных строк во вьюхе(она уже готова) вставляеш например

"where check_read_record(user) = 1" - "check_read_record" - это название функции которую сделаеш.

3. Для модификации данных в процедуре вставляеш например

" if (check_add_record(user) = 0) then
RAISE EXCEPTION \'У вас нет прав на добавление записи !\';
end if;
"

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

Николай.
guest_20040621
Дата: 21.06.2004 16:21:46
> ACL(Access Control Lists) и RWD

Оно. Только "в лоб" использованить ни то, ни другое не рекомендую.

> IMHO схема RWD (Read Write Delete/Drop??) по многим признакам идеально
> подходит для реализации в Postgres.

Она подходит для реализации в любой реляционной СУБД.

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

То, что описал Николай постом выше - хорошее решение, но несколько однобокое. ;) Попробуй его реализовать - поймешь, почему.