Рефераты | Рефераты по информатике, программированию | Row-Level Security в РСУБД |
Теперь предикат безопасности будет выглядеть так:
|
exists ( select * from [Orders Security] os join UserRoles ur on ur.RoleID = os.RoleID where ur.UserID = GetCurrentUserID() and os.OrderID = OrderID ) |
Мы проверяем, что хотя бы одной роли из тех, в которые входит пользователь, предоставлен доступ к соответствующей записи в таблице заказов.
Теперь можно динамически выдавать или отбирать разрешения на записи таблицы заказов каждой из ролей. Очевидно, что сразу после введения предиката в действие никто ничего не увидит – таблица Orders Security пуста. Давайте выдадим вице-президенту разрешение на доступ ко всем заказам:
|
insert into [Orders Security] (OrderID, RoleID) select OrderID, @VicePresidentRoleID from Orders |
Мы предполагаем, что переменная @VicePresidentRoleID уже проинициализирована соответствующим значением. Обратите внимание на то, что выполнение такой команды требует привилегий администратора БД – нужен доступ на чтение из таблицы Orders и запись в таблицу Orders Security. Отметим также то, что, в отличие от ограничений на основе существующих атрибутов, которые автоматически применяются к новым записям, динамические ограничения требуют модификации вспомогательной таблицы при каждой вставке в основную.
Рассмотренный выше способ реализации динамических ограничений может оказаться не самым эффективным. Если в случае естественных ограничений, выражаемых при помощи локального предиката, накладные расходы были связаны только с вычислением дополнительных выражений, то теперь в любом случае требуется обращение к вспомогательной таблице. В большинстве случаев список ролей, которым доступна конкретная запись, достаточно короток. Правило №3 нашей воображаемой корпоративной политики безопасности позволяет связать заказы старше полугода с единственной ролью Everyone, так как все остальные роли уже присутствуют в ней. Это означает, что рано или поздно большинство записей таблицы заказов будут связаны с этой ролью.
В связи с этим возникает искушение сохранить список ролей прямо в защищаемой записи. Некоторые СУБД предоставляют возможность хранить списки значений в поле записи, однако это является экзотикой. Поэтому мы выберем другой способ нарушить требования первой нормальной формы – будем хранить список ролей в виде строки. Язык SQL предоставляет нам возможность проверить строку на наличие заданной подстроки при помощи оператора like.
В таблицу Orders придется внести следующие изменения:
|
alter table orders add ACL varchar(1024) default ',' |
В поле ACL (Access Control List, список контроля доступа) мы будем хранить список идентификаторов ролей, разделенный запятыми. Поэтому предикат безопасности примет такой вид:
|
ACL like '%,' + cast(GetCurrentUserRoleID() as varchar(12)) + ',%' |
Чтобы упростить задачу серверу, нам придется добавить «лишние» запятые в начале и в конце строки.
Стоит отметить, что подобная техника оправдывает себя только в некоторых случаях, так что не стоит применять ее без экспериментальной проверки.
Еще один вариант представления ACL в защищаемой таблице состоит в использовании битовых операций с целыми числами. Предположим, что полное количество ролей в системе ограничено каким-то разумным числом, например 32. Тогда можно хранить ACL в виде целого числа (или нескольких целых чисел, если ролей больше 32х), сопоставив каждой роли фиксированную позицию в этом числе. Предикат безопасности примет вот такой вид:
|
(ACL & GetCurrentUserRoleMask()) > 0 |
Как и в предыдущем случае, производительность подобного способа может быть далека от оптимальной, и перед его внедрением необходимо провести экспериментальную проверку.
До сих пор мы рассматривали исключительно запросы на выборку данных. Модель безопасности, не защищающая данные от несанкционированной модификации, не имеет смысла. Давайте рассмотрим способы распространить наши достижения на остальные типы запросов SQL.
