Рефераты | Рефераты по информатике, программированию | Row-Level Security в РСУБД | страница реферата 7 | Большая Энциклопедия Рефератов от А до Я
Большая Энциклопедия Рефератов от А до Я
  • Рефераты, курсовые, шпаргалки, сочинения, изложения
  • Дипломы, диссертации, решебники, рассказы, тезисы
  • Конспекты, отчеты, доклады, контрольные работы


    • Рефераты | Рефераты по информатике, программированию | Row-Level Security в РСУБД


    Рефераты | Рефераты по информатике, программированию | Row-Level Security в РСУБД

    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 |




    Поделитесь этой записью или добавьте в закладки

       

    Категории:



    Разделы сайта




    •