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

[Вудруф]

У Вас  "схема" применялась по принципу - одна схема - один АРМ или более глобально?

Открытый пользователь - один, закрытых схем - несколько. Но сделано так, скорее, из исторических соображений. Ну и независимые схемы удобнее обслуживать.
Реально достаточно одного открытого пользователя (с известным паролем) для подключения к БД web-сервера и одну схему другого пользователя, содержащую функциональную часть всех приложений.

[-QT-]

У Вас  "схема" применялась по принципу - одна схема - один АРМ или более глобально?

Открытый пользователь - один, закрытых схем - несколько. Но сделано так, скорее, из исторических соображений. Ну и независимые схемы удобнее обслуживать.
Реально достаточно одного открытого пользователя (с известным паролем) для подключения к БД web-сервера и одну схему другого пользователя, содержащую функциональную часть всех приложений.

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

[-QT-]

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

[Вудруф]

Попробую пояснить, почему мы не пользовались схемой, обеспечивающей "control access to data at the row, or even column, level".
У нас - несколько тысяч сотрудников. Большинству из них приходится работать с нашей системой. Именно поэтому проще делать web-ориентированные АРМы.
Далее, если мы будем использовать встроенные в базу данных ограничения по принципу unix-way (rwx), то нам придётся создавать столько пользователей БД, сколько у нас сотрудников. Таким количеством пользователей базы данных очень сложно управлять. Выход - создание отдельных таблиц для работы с пользователями и их правами доступа. При этом все проверки основываются на "разрешениях". Есть таблица "тип разрешения", есть таблица "разрешение", пользователю или группе. Для специфических типов разрешений в таблице групп хранится название процедуры, проверяющей соответствие текущего пользователя (не базы данных, а зарегистрированного при помощи вызова login) группе. Так сделано для доступа к разделам, доступным пользователям только на момент их нахождения в той или иной должности. Иначе же мы должны были бы давать такие права людям отдельно, при их увольнении или смены должности - их забирать обратно. Повторяю, пользователей - тысячи.
Кстати, проверка доступа на уровне строк может строиться и на основе предикатов. Если предикат истинен - строка в выборку попадает. Это так, к сведению.
Однако, нами для доступа к информации применяются функции, возвращающие курсор (ещё один вариант - представления). В обоих случаях пользователю попадают только строки на основе его разрешений (проверяемые нами, а не БД).

Вот так вот, несколько сумбурно... Будут вопросы - welcome

[-QT-]

Попробую пояснить, почему мы не пользовались схемой, обеспечивающей "control access to data at the row, or even column, level".
У нас - несколько тысяч сотрудников. Большинству из них приходится работать с нашей системой. Именно поэтому проще делать web-ориентированные АРМы.

=== Да с таким кол-вом пользователей Ваш подход вполне оправдан

Далее, если мы будем использовать встроенные в базу данных ограничения по принципу unix-way (rwx), то нам придётся создавать столько пользователей БД, сколько у нас сотрудников. Таким количеством пользователей базы данных очень сложно управлять.
 
=== Позвольте не согласиться с этим, Чем больше людей занимается производством продукции - тем больше менеджеров занимается их управлением, это же справедливо и для нашей ситуации: 30-пользователей --> 1 сервер + 1 админ ;
                                                                                                  100-пользователей --> 2 сервера + 2 админа;
                                                                                                  1000- пользователей --> 5 серверов + 4 адимна + 2 аникейщика поддержки
(это просто для примера, но на практике приблизительно так-же)

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

=== Вот это и реализует Veil.

Кстати, проверка доступа на уровне строк может строиться и на основе предикатов. Если предикат истинен - строка в выборку попадает. Это так, к сведению.

=== Об этом поподробнее пожалуста. 

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

=== Да, да это тоже вариант решения но ним можно управлять не для всех групп пользователей.

Вот так вот, несколько сумбурно... Будут вопросы - welcome

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

2. После выбора АРМ идентифицировать себя как лицо тобиш ФИО  Иванов Иван Иванович таб. № 548714258 
   (На уровне пользователя набор кортежей ему доступный с указанными правами для него или его группы)

3. Доступ к данным пофамильно для ведения логов и разрешения конфликтных ситуаций типа (А Я Ваши документы в ГЛАЗА не видел,
    и не удалал я ничего - отстаньте от меня!!!!) 

Если Вы считаете что я не прав - готов к конструктивным гонениям.

[Вудруф]

Извините, что с такой задержкой отвечаю
Не совсем понял про количество серверов и прочее. Я говорил про то, что пользователями базы данных (на уровне СУБД) сложно управлять.
Про Veil почитаю, может, мы придумывали колесо

Об этом поподробнее пожалуста.

Ну, я не знаю, есть ли такое в PostgreSQL. В Oracle можно накладывать ограничения на выборку из таблицы на основе предиката. Мы задаём некоторую функцию-предикат, если строка ей удовлетворяет - она попадает в выборку, иначе - нет. То же самое можно реализовать и в представлениях/встроенных функциях, возвращающих курсор, но писать надо меньше Работает именно для пользователей БД.
Может, я что-то не то говорю, я с этим средством подробно не разбирался.

но ним можно управлять не для всех групп пользователей

почему? по-моему, для каждого АРМ мы можем прописать свои специфические проверки

3 - да, именно так
1, 2 - не совсем. У каждого пользователя есть своя учётная запись (одна). Он может находиться в нескольких группах пользователей (в некоторые он попадает автоматически, по какому-то критерию, в некоторые - заносится вручную). Права на работу с тем или иным приложением выдаются либо непосредственно пользователям, либо группе вручную. Далее, все АРМы находятся в одной системе. Т.е. пользователь входит в систему и может работать со всеми теми приложениями, с которыми ему разрешено работать, с тем уровнем привелегий, которые ему были даны.

[andrew.k]

Тип внутренне представлен int'ом.
При выводе text row_acl_out() преобразует интовую маску в текстовое представление
Есть гистовый индекс для этого типа.

Расскажите, как это реализовано. Как поле int преобразовать к набору битов и как их значения использовать в запросах?