Это движение в сторону RBAC — управления доступом на основе ролей. Вы также можете задаться вопросом, следует ли использовать LBAC — управление доступом на основе меток. И, в зависимости от вашей СУБД, могут быть другие способы достижения этого (например, Oracle VPD — виртуальная частная база данных). Все это либо скорее, либо очень специфично для СУБД - разные решения для разных СУБД.
Вы, кажется, говорите об управлении на уровне строки. То есть одна строка в таблице контактов может быть доступна всем, другая — только одному набору отделов, третья — только одной группе людей и так далее.
Помните, что реляционные СУБД лучше всего работают с множествами. Одна группа — это набор групп с одной группой-членом; один пользователь — это набор групп с одним пользователем-членом. Это означает, что у нас меньше дел для рассмотрения.
Если вы хотите реализовать его в стандартном SQL, то, я думаю, вам нужно будет использовать комбинацию представлений, использующих соединения с управляющими таблицами и т. д. Сложные части такой системы — заполнение управляющих таблиц и ограничение административных пользователей ( на самом деле ограничение администраторов всегда является одной из самых сложных частей).
Основной техникой будет:
- Создайте базовую таблицу с соответствующим столбцом, чтобы определить набор привилегий, который применяется к каждой строке в таблице.
- Отменить любой публичный доступ к таблице.
- Создайте представление в базовой таблице, которое показывает все разрешенные столбцы из базовой таблицы. Это будет представление соединения с управляющей таблицей, которое будет определено в ближайшее время. Условия запроса просмотра также будут зависеть от текущего пользователя.
- Предоставьте соответствующий доступ к представлению.
- Создайте соответствующие триггеры INSTEAD OF в представлении для обработки операций вставки, удаления и обновления в представлении, ретранслируя изменения в базовую таблицу.
- Создайте контрольную таблицу для соединения с базовой таблицей.
- Заполните его соответствующими данными.
- Светло-голубой коснитесь бумаги и отойдите подальше.
Теперь о том столбце соединения и контрольной таблице...
Кто-то должен указать, какие разрешения применяются к вновь вставленным строкам в таблице — какой доступ предоставляется по умолчанию. И кто-то должен определить, как можно переопределить доступ по умолчанию. И то, и другое может быть грязным.
Существует несколько способов структурирования контрольной таблицы:
Один механизм основан на том, что каждая строка в базовой таблице имеет уникальный идентификатор (который может быть автоматически сгенерированным идентификатором или просто значением первичного ключа). Затем управляющая таблица включает копию этого уникального идентификатора и определяет, какие пользователи или группы могут получить к ней доступ. Это означает, что в таблице управления может быть несколько записей для данной строки, по одной для каждого пользователя или группы, которые могут получить доступ к строке. В этой схеме управляющая таблица имеет внешний ключ, ссылающийся на базовую таблицу.
Другой механизм встраивает идентификационный номер в базовую таблицу, которая является внешним ключом для управляющих таблиц. В основном он идентифицирует набор привилегий, а ссылка в базовой таблице означает, что строка имеет разрешение на доступ, связанное с идентификатором управления доступом. Структура управляющей таблицы может заключаться в том, что идентификатор 0 не имеет доступа ни для кого (через представление), идентификатор 1 имеет доступ для всех, а другие значения обозначают комбинации пользователей и групп — каждая отдельная комбинация имеет другой идентификатор. При этом в наборе управляющих таблиц может быть несколько таблиц, и мы также обсуждаем наличие набора этих управляющих таблиц для каждой защищенной таблицы.
Понятно, что доступ к контрольным таблицам строго ограничен, но также имеет решающее значение для управления тем, кто что может видеть.
Оба они являются административными кошмарами, поэтому вы, вероятно, в конечном итоге получите механизм управления доступом, предоставляемый СУБД, а не универсальное решение SQL.
person
Jonathan Leffler
schedule
13.09.2009
