Детализированные Права доступа Записи Базы данных (например, Группа "X" и Человек “Smith” может просмотреть Запись Z),

Это движение в сторону RBAC - управления доступом на основе ролей. Вы также можете задаться вопросом, использовать ли LBAC - контроль доступа на основе меток. И, в зависимости от вашей СУБД, могут быть другие способы достижения этого (например, рассмотрим Oracle VPD - виртуальную частную базу данных). Все это скорее или очень специфично для СУБД - разные решения для разных СУБД.

Кажется, вы говорите об управлении на уровне строк. То есть одна строка в таблице контактов может быть доступна всем, другая - только одному набору отделов, другая - только одной группе людей и т. Д.

Помните, что реляционные СУБД лучше всего работают с наборы. Единая группа - это набор групп с одним членом; один пользователь - это набор групп с одним пользователем-членом. Это означает, что у нас меньше дел.

Если вы хотите реализовать это в стандартном SQL, то, я думаю, вам понадобится комбинация представлений, использующих объединения с управляющими таблицами и т. Д. Сложными частями такой системы являются заполнение управляющих таблиц и ограничение административных пользователей (фактически, ограничение администраторов всегда является одной из сложных частей).

Базовый метод будет:

• Создать базовую таблицу с соответствующим столбцом, чтобы определить набор привилегий, который применяется к каждой строке в таблице.
• Отменить весь открытый доступ к таблице.
• Создать представление для базовой таблицы, в котором отображаются все разрешенные столбцы из базовой таблицы. Это будет представление соединения с контрольной таблицей, которое будет определено в ближайшее время. Условия запроса представления также будут обусловлены текущим пользователем.
• Предоставьте соответствующий доступ к представлению.
• Создайте соответствующие триггеры INSTEAD OF в представлении для обработки операций вставки, удаления и обновления в представлении, передавая изменения в базовую таблицу.
• Создайте управляющую таблицу для соединения с базовой таблицей.
• Заполните ее. с соответствующими данными.
• Светло-синий прикоснитесь к бумаге и отойдите подальше.

Теперь о соединении столбца и контрольной таблицы ...

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

Есть несколько способов структурировать управляющую таблицу:

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

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

Я согласен с Джонатоном насчет техники, но не обязательно насчет кошмара. Я реализовал это с помощью единого представления объединения прав на основе:

• кто создал базовую запись
• бизнес-подразделение, указанное в базовая запись
• специальная группа пользователей, указанная на базовая запись
• внутренний отдел указал на базовая запись
• специальные гранты отдельным пользователям
• административные роли

Производительность была хорошей, хотите верьте, хотите нет, хотя базовая таблица никогда не была больше, чем около 250 000 записей ... очевидно, большая базовая таблица могла бы требуют более проработанного дизайна. Но в нашем случае это сработало, и администрирование не представляло большого труда. Назначение созданных и специальных групп пользователей было единственными правилами, которые действительно широко использовались. Назначение / отмена доступа к группам было постоянной задачей, но она решается территорией.