45799 (Row-Level Security в РСУБД), страница 3
Описание файла
Документ из архива "Row-Level Security в РСУБД", который расположен в категории "". Всё это находится в предмете "информатика" из , которые можно найти в файловом архиве . Не смотря на прямую связь этого архива с , его также можно найти и в других разделах. Архив можно найти в разделе "рефераты, доклады и презентации", в предмете "информатика, программирование" в общих файлах.
Онлайн просмотр документа "45799"
Текст 3 страницы из документа "45799"
Битовые маски
Еще один вариант представления ACL в защищаемой таблице состоит в использовании битовых операций с целыми числами. Предположим, что полное количество ролей в системе ограничено каким-то разумным числом, например 32. Тогда можно хранить ACL в виде целого числа (или нескольких целых чисел, если ролей больше 32х), сопоставив каждой роли фиксированную позицию в этом числе. Предикат безопасности примет вот такой вид:
| (ACL & GetCurrentUserRoleMask()) > 0 |
Как и в предыдущем случае, производительность подобного способа может быть далека от оптимальной, и перед его внедрением необходимо провести экспериментальную проверку.
Ограничения на модификацию
До сих пор мы рассматривали исключительно запросы на выборку данных. Модель безопасности, не защищающая данные от несанкционированной модификации, не имеет смысла. Давайте рассмотрим способы распространить наши достижения на остальные типы запросов SQL.
Точно так же, как и для запросов Select, мы должны вычислить предикат безопасности для каждой из строк, которые пользователь попытается модифицировать. Нам нужно сообщить пользователю об ошибке, а также позаботиться о неизбежной отмене результатов некорректного действия. Этого можно добиться, применяя триггеры.
В слеующих примерах выражение означает предикат, аналогичный рассмотренным выше. Как и для select, предикат может быть представлять либо естественное, либо динамическое ограничение.
Для естественных ограничений принципиально важны два предиката: условие, которое проверяет состояние данных до изменения, и отдельное условие, которое проверяет состояние данных после изменения. Первое условие необходимо проверять в триггерах на удаление и изменение записей, а второе – в триггерах на изменение и вставку записей. Может появиться искушение использовать более сложные правила для изменения данных, однако делать этого обычно не стоит. Слишком легко получить нецелостную схему безопасности, которая позволяет пользователю получить различные результаты в зависимости от порядка действий. Например, запрет на увеличение суммы заказа более чем на 500 рублей (в один прием) легко обходится путем последовательного неоднократного увеличения суммы. А запрет на удаление заказов VIP-клиента, не сопровожденный запретом на изменение таких заказов, может привести к искушению просто «переписать» заказ на другого клиента.
Для динамических ограничений придется хранить чуть больше информации, чтобы учесть возможность раздельного предоставления прав на различные типы модификаций.
Примерно так будут выглядеть наши триггеры на T-SQL:
Delete
| create trigger CheckSecurity on as if exists (select * from deleted where not ) begin RAISERROR ('Access denied', 16, 1) ROLLBACK TRANSACTION end |
Insert
| create trigger CheckSecurity on as if exists (select * from inserted where not ) begin RAISERROR ('Access denied', 16, 1) ROLLBACK TRANSACTION end |
Update
Этот пример чуть-чуть сложнее, т.к. нам надо проверить не только старые, но и новые значения в таблице:
| create trigger CheckSecurity on as if exists (select * from inserted where not ) or exists (select * from deleted where not ) begin RAISERROR ('Access denied', 16, 1) ROLLBACK TRANSACTION end |
Заключение
Эти рассуждения носили в значительной мере теоретический характер. С одной стороны, это вселяет уверенность в том, что никакие важные особенности поставленной задачи не остались без внимания и излишние подробности не отвлекали от решения.
С другой стороны, тем читателям, которым захочется применить RLS на практике, придется довольно много потрудиться. Для них предназначен следующий раздел.
Соображения по реализации
Первый и основной совет: экспериментируйте, прежде чем запускать модификацию в эксплуатацию. Убедитесь, что предикаты составлены верно.
Второе: производительность. Самые невинные запросы теперь будут скрывать в себе дополнительные вычисления. Поэтому не забывайте про индексы. Несомненно, помимо создания и модификации таблиц потребуется создать необходимые индексы. Возможно, некоторые из уже существующих индексов придется изменить, чтобы планы запросов не слишком пострадали. Проверяйте не только фактическое время выполнения запросов, но и планы, которые строит СУБД.
Ну и последнее: не забудьте аккуратно назначить привилегии на объекты СУБД таким образом, чтобы пользователи не могли получить прямой доступ к данным, минуя проверки. Кроме того, позаботьтесь о защите самих определений триггеров и представлений от модификации.
Альтернативы
Ведущие производители СУБД не оставили рассмотренный в статье вопрос без своего внимания. Oracle 8i и выше поддерживает так называемый fine grained access control. Фактически, это применение точно такой же математики, но несколько другими техническими средствами. Вместо механизма View используются специальные возможности дополнительных пакетов Oracle по установлению политики безопасности.
MS SQL Server 2005 (codename “Yukon”) также будет поддерживать возможности RLS. Подробная документация на этот механизм еще не опубликована. Точно известно лишь то, что в T-SQL будут введены специальные конструкции. Судя по имеющимся документам, предикаты безопасности (RULES) будут создаваться как отдельные сущности, а специальные версии команд grant и revoke будут назначать эти предикаты пользователям и группам.
Список литературы
Для подготовки данной работы были использованы материалы с сайта http://www.rsdn.ru/
