Некоторые итоги
Итак, рассмотренная техника позволяет обеспечить разделение прав доступа в терминах значений защищаемых данных. Во многих случаях этот способ является наиболее удобным, и его главное преимущество – малые усилия по административной поддержке. Модификации потребуются только при изменении корпоративной политики, а это достаточно редкое явление. Не требуется динамического управления доступом на уровне отдельных объектов – например, заказы, отгруженные сегодня, автоматически станут доступными всем сотрудникам через полгода.
Однако в некоторых случаях требуется предоставлять или отказывать в доступе к конкретным записям в административном порядке, независимо от хранящихся в них значений. Такие требования могут быть связаны с быстроменяющимися правилами безопасности, для которых недопустимы задержки в реализации, неизбежные при модификации схемы базы данных. Кроме того, иногда быстродействия СУБД будет недостаточно для вычисления предикатов безопасности на основе существующих атрибутов.
Естественным решением данной задачи является внесение в базу дополнительной информации, не связанной напрямую с моделируемой предметной областью. Модификация этих данных и позволит управлять доступом к конкретным записям без изменения схемы БД. Способы реализации такого рода решений рассматриваются в следующем разделе.
Ограничения на основе дополнительных атрибутов
Все соображения, рассмотренные ранее для существующих атрибутов, остаются справедливыми и для дополнительных атрибутов. Мы по-прежнему будем рассматривать предикаты безопасности общего вида. Однако теперь задача ставится несколько шире: если раньше основной проблемой было преобразовать правила корпоративной безопасности в соответствующие выражения с использованием существующей модели, то теперь нам предстоит дополнить модель данных. Теперь нужно отдельно хранить информацию о том, каким ролям предоставлен доступ к каким записям.
Вспомогательная таблица
С точки зрения реляционной модели, записи защищаемой таблицы и роли пользователей находятся в отношении многие-ко-многим. Традиционным способом реализации таких отношений является создание вспомогательной таблицы:
| CREATE TABLE [Orders Security] ( OrderID int CONSTRAINT Order_FK REFERENCES Orders(OrderID), RoleID int CONSTRAINT Role_FK REFERENCES UserRoles(RoleID), CONSTRAINT [Orders_Security_PK] PRIMARY KEY (OrderID, RoleID)) |
Теперь предикат безопасности будет выглядеть так:
| 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.
Точно так же, как и для запросов Select, мы должны вычислить предикат безопасности для каждой из строк, которые пользователь попытается модифицировать. Нам нужно сообщить пользователю об ошибке, а также позаботиться о неизбежной отмене результатов некорректного действия. Этого можно добиться, применяя триггеры.
В слеующих примерах выражение <Security_Check_Ok> означает предикат, аналогичный рассмотренным выше. Как и для select, предикат может быть представлять либо естественное, либо динамическое ограничение.
Для естественных ограничений принципиально важны два предиката: условие, которое проверяет состояние данных до изменения, и отдельное условие, которое проверяет состояние данных после изменения. Первое условие необходимо проверять в триггерах на удаление и изменение записей, а второе – в триггерах на изменение и вставку записей. Может появиться искушение использовать более сложные правила для изменения данных, однако делать этого обычно не стоит. Слишком легко получить нецелостную схему безопасности, которая позволяет пользователю получить различные результаты в зависимости от порядка действий. Например, запрет на увеличение суммы заказа более чем на 500 рублей (в один прием) легко обходится путем последовательного неоднократного увеличения суммы. А запрет на удаление заказов VIP-клиента, не сопровожденный запретом на изменение таких заказов, может привести к искушению просто «переписать» заказ на другого клиента.
Для динамических ограничений придется хранить чуть больше информации, чтобы учесть возможность раздельного предоставления прав на различные типы модификаций.
Примерно так будут выглядеть наши триггеры на T-SQL:
Delete
| create trigger CheckSecurity on <table_name> for deleteas if exists (select * from deleted where not <Security_Check_Ok>)begin RAISERROR ('Access denied', 16, 1) ROLLBACK TRANSACTIONend |
Insert
| create trigger CheckSecurity on <table_name> for insertas if exists (select * from inserted where not <Security_Check_Ok>)begin RAISERROR ('Access denied', 16, 1) ROLLBACK TRANSACTIONend |
Update
Этот пример чуть-чуть сложнее, т.к. нам надо проверить не только старые, но и новые значения в таблице:
| create trigger CheckSecurity on <table_name> for insertas if exists (select * from inserted where not <Insert_Check_Ok>) or exists (select * from deleted where not <Delete_Check_Ok>)begin RAISERROR ('Access denied', 16, 1) ROLLBACK TRANSACTIONend |
Эти рассуждения носили в значительной мере теоретический характер. С одной стороны, это вселяет уверенность в том, что никакие важные особенности поставленной задачи не остались без внимания и излишние подробности не отвлекали от решения.
С другой стороны, тем читателям, которым захочется применить RLS на практике, придется довольно много потрудиться. Для них предназначен следующий раздел.
Первый и основной совет: экспериментируйте, прежде чем запускать модификацию в эксплуатацию. Убедитесь, что предикаты составлены верно.
Второе: производительность. Самые невинные запросы теперь будут скрывать в себе дополнительные вычисления. Поэтому не забывайте про индексы. Несомненно, помимо создания и модификации таблиц потребуется создать необходимые индексы. Возможно, некоторые из уже существующих индексов придется изменить, чтобы планы запросов не слишком пострадали. Проверяйте не только фактическое время выполнения запросов, но и планы, которые строит СУБД.
Ну и последнее: не забудьте аккуратно назначить привилегии на объекты СУБД таким образом, чтобы пользователи не могли получить прямой доступ к данным, минуя проверки. Кроме того, позаботьтесь о защите самих определений триггеров и представлений от модификации.
Ведущие производители СУБД не оставили рассмотренный в статье вопрос без своего внимания. Oracle 8i и выше поддерживает так называемый fine grained access control. Фактически, это применение точно такой же математики, но несколько другими техническими средствами. Вместо механизма View используются специальные возможности дополнительных пакетов Oracle по установлению политики безопасности.
MS SQL Server 2005 (codename “Yukon”) также будет поддерживать возможности RLS. Подробная документация на этот механизм еще не опубликована. Точно известно лишь то, что в T-SQL будут введены специальные конструкции. Судя по имеющимся документам, предикаты безопасности (RULES) будут создаваться как отдельные сущности, а специальные версии команд grant и revoke будут назначать эти предикаты пользователям и группам.