Row-Level Security в РСУБД
| Категория реферата: Рефераты по информатике, программированию
| Теги реферата: в контакте сообщения, контрольная по алгебре
| Добавил(а) на сайт: Korablin.
Предыдущая страница реферата | 1 2 3 4 5 6 7 8 9 10 | Следующая страница реферата
|
(IsUserInRole('Sales Representative') AND select(EmployeeID from Orders o where o.OrderID = OrderID) = CurrentEmployeeID()) OR (IsUserInRole('Vice President, Sales') AND TRUE) OR (IsUserInRole('Everyone') AND select(ShippedDate from Orders o where o.OrderID = OrderID) < DateAdd(month, -6, GetDate()) |
К сожалению, такой вид предиката не слишком нагляден. Он не отражает взаимосвязи между правилами безопасности для деталей заказов и для самих заказов. Поэтому лучше применить немного другой способ построения представления, чем был рассмотрен ранее:
|
create view [Secure Order Details] as select od.* from [Order Details] od join [Secure Orders] so on od.OrderID = so.OrderID |
В таком виде сущность используемого ограничения безопасности очевидна. Кроме того, изменение правил безопасности для заказов (которое повлияет на определение представления Secure Orders) автоматически отразится и на их деталях.
В данном случае мы не накладываем никаких дополнительных ограничений на детали заказа. Однако при необходимости мы можем точно так же добавить локальный предикат безопасности в условие where.
Некоторые итоги
Итак, рассмотренная техника позволяет обеспечить разделение прав доступа в терминах значений защищаемых данных. Во многих случаях этот способ является наиболее удобным, и его главное преимущество – малые усилия по административной поддержке. Модификации потребуются только при изменении корпоративной политики, а это достаточно редкое явление. Не требуется динамического управления доступом на уровне отдельных объектов – например, заказы, отгруженные сегодня, автоматически станут доступными всем сотрудникам через полгода.
Однако в некоторых случаях требуется предоставлять или отказывать в доступе к конкретным записям в административном порядке, независимо от хранящихся в них значений. Такие требования могут быть связаны с быстроменяющимися правилами безопасности, для которых недопустимы задержки в реализации, неизбежные при модификации схемы базы данных. Кроме того, иногда быстродействия СУБД будет недостаточно для вычисления предикатов безопасности на основе существующих атрибутов.
Естественным решением данной задачи является внесение в базу дополнительной информации, не связанной напрямую с моделируемой предметной областью. Модификация этих данных и позволит управлять доступом к конкретным записям без изменения схемы БД. Способы реализации такого рода решений рассматриваются в следующем разделе.
Ограничения на основе дополнительных атрибутов
Все соображения, рассмотренные ранее для существующих атрибутов, остаются справедливыми и для дополнительных атрибутов. Мы по-прежнему будем рассматривать предикаты безопасности общего вида. Однако теперь задача ставится несколько шире: если раньше основной проблемой было преобразовать правила корпоративной безопасности в соответствующие выражения с использованием существующей модели, то теперь нам предстоит дополнить модель данных. Теперь нужно отдельно хранить информацию о том, каким ролям предоставлен доступ к каким записям.
Вспомогательная таблица
С точки зрения реляционной модели, записи защищаемой таблицы и роли пользователей находятся в отношении многие-ко-многим. Традиционным способом реализации таких отношений является создание вспомогательной таблицы:
|
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) Рекомендуем скачать другие рефераты по теме: оценка реферата, диплом анализ. Категории:Предыдущая страница реферата | 1 2 3 4 5 6 7 8 9 10 | Следующая страница реферата Поделитесь этой записью или добавьте в закладки |
|
Главная