Row-Level Security в РСУБД - реферат

Row-Level Security в РСУБД

АнтонЗлыгостев

Введение

Разграничение прав доступа является нужной функциональностью хоть какой корпоративной СУБД. Практические все современные СУБД предоставляют набор базисных средств по управлению правами доступа. Обычно, поддерживаются такие концепции, как юзеры и группы, также так именуемая декларативная безопасность – возможность предоставить этим юзерам и группам права доступа Row-Level Security в РСУБД - реферат к определенным объектам базы данных. Важным вопросом является гранулярность этой безопасности, т.е. как детально можно назначить права.

Основными объектами безопасности в СУБД являются таблицы, представления (view), и хранимые процедуры. Зависимо от типа объекта можно управлять правами на определенные деяния с ним. К примеру, в случае таблиц можно независимо управлять Row-Level Security в РСУБД - реферат правами на чтение, добавление, удаление и изменение записей. В тех СУБД, где поддерживаются какие-либо другие объекты (к примеру, пользовательские функции), доступом к ним можно управлять аналогичным образом. В неких системах можно управлять доступом на уровне отдельного столбца представления либо таблицы.

Это довольно эластичная и развитая система, позволяющая админу Row-Level Security в РСУБД - реферат СУБД настраивать права доступа юзеров в согласовании с их служебными обязательствами.

Но в неких случаях интегрированной в СУБД функциональности недостаточно для реализации требований корпоративной политики доступа к данным. Дело в том, что очень немногие СУБД позволяют ограничить доступ юзеров к отдельным строчкам таблиц, хотя схожее требование довольно нередко встречается в Row-Level Security в РСУБД - реферат прикладных задачках. К примеру, менеджеры по продажам не имеют права «видеть» затратные, выписанные в другом кабинете той же компании, а директору по продажам все эти данные доступны. Рядовой бухгалтер не должен изменять документы задним числом, но главному бухгалтеру это дозволительно. В английской традиции данная функциональность именуется Row-Level Security Row-Level Security в РСУБД - реферат. Закоренелой русской терминологии нет, потому мы будем воспользоваться английским термином, время от времени сокращая его до RLS.

Там, где интегрированных средств поддержки таковой функциональности нет, разработчику придется придумать собственный метод гарантировать выполнение требований заказчика. Как и в хоть какой другой задачке, существует большой выбор таких методов. В этой статье Row-Level Security в РСУБД - реферат предлагается несколько из их.

Реализация RLS на клиенте

Одним из более фаворитных решений задачки RLS является встраивание правил безопасности в клиентское приложение. Так как в наши деньки юзеры фактически никогда не разговаривают с СУБД впрямую, это смотрится довольно презентабельно. Все деяния юзера проходят через интерфейс приложения, и разработчик Row-Level Security в РСУБД - реферат имеет возможность заложить сколь угодно сложные правила проверки допустимости действий. Основными преимуществами данного подхода являются:

большая упругость – обычный процедурный язык программирования позволяет делать все, что угодно;

возможность определять, выполнимо ли некое действие, до пробы его выполнения (а все управления по usability безотступно советуют заблаговременно информировать юзера об ограничениях Row-Level Security в РСУБД - реферат на деяния – к примеру, выделяя сероватым соответственный пункт меню);

Но совместно с тем этот подход обладает несколькими существенными недочетами:

Небезопасность. Подразумевается, что юзеры могут подключиться к СУБД только средством определенного клиентского приложения. Если злостный юзер довольно квалифицирован, то он всегда сумеет получить доступ к базе, минуя клиентское приложение, и игнорировать Row-Level Security в РСУБД - реферат реализованные в нем правила безопасности. Еще больше возможным сценарием в корпоративных приложениях является одновременная работа нескольких версий клиентского приложения с отличающимися наборами правил безопасности. Таким макаром, безопасность начинает зависеть уже не от разработчика, а от расторопности системных админов, осуществляющих эксплуатацию.

Производительность. Для запросов на изменение данных данный подход несколько увеличивает Row-Level Security в РСУБД - реферат быстродействие, т.к. в случае запрета на действие вообщем нет необходимости связываться с сервером. Но запросы на чтение будут приводить к передаче по сети лишних данных - тех строк, которые будут отброшены клиентским приложением в согласовании с правилами безопасности.

Целостность данных. Разграничение прав доступа на уровне СУБД производится в декларативном стиле Row-Level Security в РСУБД - реферат, т.е. СУБД гарантированно инспектирует одни и те же ограничения при всех операциях с данными. Но в клиентском приложении будет применен властный стиль. Это значит, что потенциально больше способностей сделать ошибку, либо запамятовать применить единый набор правил для всех вероятных методов воззвания к данным. В вышеперечисленном примере Row-Level Security в РСУБД - реферат с менеджерами продаж просто запамятовать внести надлежащие ограничения в какие-либо отчеты, основанные на данных из таблицы затратных, и дать юзеру возможность обойти правила безопасности.

Единственным методом борьбы с этими недочетами является реализация проверки всех правил безопасности на сервере.

Современные технологии разработки приложений предлагают два варианта реализации RLS на стороне сервера Row-Level Security в РСУБД - реферат - средствами сервера баз данных и средствами сервера приложений.

Если для вашего приложения выбрана трехуровневая модель, то реализация RLS на уровне сервера приложений является полностью применимым, а может быть и лучшим, решением.

Но, если приложение разрабатывается в традиционной клиент-серверной модели, либо подразумевается наличие нескольких серверов приложений, работающих с одним Row-Level Security в РСУБД - реферат сервером данных, то лучше воплотить RLS на уровне базы данных. Вероятные подходы к решению этой задачки мы и разглядим в последующем разделе.

Реализация RLS средствами сервера БД

Итак, пред нами стоит задачка - давать либо не давать определенному юзеру право на выполнение тех либо других действий с разными строчками Row-Level Security в РСУБД - реферат таблицы. На теоретическом уровне, в самом общем случае, это значит, что перед выполнением хоть какого деяния проверяется значение некого предиката (булевой функции). Стандартные средства безопасности СУБД могут инспектировать предикаты, параметрами которых являются идентификатор текущего юзера, идентификатор(ы) таблиц, и, может быть, отдельных столбцов, к которым осуществляется доступ. Это позволяет Row-Level Security в РСУБД - реферат вычислить значение один раз до выполнения хоть какого SQL запроса, и до окончания его обработки к вопросу безопасности не ворачиваться. Таким макаром, сводится к минимуму воздействие проверки безопасности на производительность системы.

Нам придется расширить функциональность таким макаром, чтоб предикат безопасности рассчитывался независимо для каждой строчки таблицы.

В Row-Level Security в РСУБД - реферат определениях SQL это значит, к примеру, что к каждому select-запросу необходимо неявно добавить соответственное условие:

select * from Clients where CompanyName like 'Micro%' AND

В этом случае под предполагается некое булево выражение. Дальше мы будем изучить разные варианты построения таких выражений, но перед этим стоит убедиться в том, что Row-Level Security в РСУБД - реферат мы можем гарантировать проверку этого условия.

Нам нужно изолировать юзера от прямого доступа к данным и гарантировать применение установленных правил безопасности. Если применяемая СУБД не предоставляет интегрированных устройств обеспечения безопасности, то получить настоящее решение задачки не получится.

Обыкновенной техникой для изоляции юзера от хранимых в СУБД данных является построение соответственного представления (view Row-Level Security в РСУБД - реферат), и запрет прямого доступа к нижележащей таблице. В MS SQL Server это можно сделать приблизительно таким макаром:

create view SecureClients as select * from Clients where

deny public read on Clients

grant public read on SecureClients

Тогда при выполнении запроса

select * from SecureClients where CompanyName like 'Micro%'

юзеры автоматом увидят только те Row-Level Security в РСУБД - реферат строчки, для которых возвращает TRUE.

Сейчас разглядим разные варианты предикатов, которые могут употребляться для проверки доступа.

Юзеры и группы

На теоретическом уровне, основой вычисления предиката безопасности является идентификатор текущего юзера (он, обычно, доступен в хоть какой СУБД, поддерживающей аутентификацию). Но его прямое внедрение не рекомендуется, т.к Row-Level Security в РСУБД - реферат. как корпоративная политика, в согласовании с которой должна строиться реализация системы, изредка манипулирует персоналиями. В таком случае проблемно сконструировать относительно постоянные правила, которые не придется пересматривать при каждом изменении перечня служащих.

Обычно все правила построены на базе должностей. Их аналогом в программировании являются группы либо роли. Потому в предикатах Row-Level Security в РСУБД - реферат безопасности нам нередко придется использовать выражения типа IsUserInRole(rolename). Если в применяемую СУБД встроена схожая функциональность - отлично, идеальнее всего использовать конкретно ее. В таком случае субъекты безопасности будут создавать единое место как для интегрированной безопасности СУБД, так и для наших расширений.

Если же СУБД не предоставляет средств поддержки групп Row-Level Security в РСУБД - реферат либо ролей, то их тоже придется реализовывать вручную. Одним из простых методов является создание специальной таблицы, содержащей перечень групп либо ролей, и связь ее с таблицей юзеров. Зависимо от потребностей, можно избрать разные схемы. Если юзер может заходить исключительно в одну группу, то довольно добавить ссылку на группу в таблицу Row-Level Security в РСУБД - реферат юзеров. А если ему может быть назначено сразу несколько ролей, то для связи нужно будет сделать отдельную таблицу.

В таких случаях предикат IsUserInRole(rolename) воспринимает вид:

exists(select * from users where ID = CurrentUserID() and user_group = rolename)

либо

exists(select *

from UserRoles

where RoleName = rolename and UserID Row-Level Security в РСУБД - реферат = CurrentUserID())

В предстоящем мы будем иметь в виду под выражением IsUserInRole(rolename) или подходящую встроенную функцию СУБД, или предикат, построенный вручную в согласовании с избранной моделью.

Ограничения на базе имеющихся атрибутов

Если правила корпоративной политики выражаются в определениях предметной области, то можно сформировать соответственный предикат безопасности в определениях данных Row-Level Security в РСУБД - реферат, хранимых в СУБД.

В самом ординарном случае довольно данных из той же таблицы. Представим, доступ к еженедельным документам денежной отчетности компании определяется последующими правилами:

младшие денежные аналитики имеют право чтения отчетов старше 6 месяцев;

старшие денежные аналитики имеют право чтения отчетов старше 1-го месяца;

всем остальным сотрудникам доступ к документам запрещен.

В таком Row-Level Security в РСУБД - реферат случае можно выстроить приблизительно таковой предикат:

(IsUserInRole('senior_analyst') and ReportDate < DateAdd(month, GetDate(), 1))

OR

(IsUserInRole('junior_analyst') and ReportDate < DateAdd(month, GetDate(), 6))

В принципе, тот же самый итог можно получить и другими методами. К примеру, вот такое выражение SQL отражает те же самые правила:

case

when ReportDate > DateAdd Row-Level Security в РСУБД - реферат(month, GetDate(), 1) then false

when ReportDate > DateAdd(month, GetDate(), 6) then

IsUserInRole('senior_analyst')

else IsUserInRole('junior_analyst')

end

Но тут проследить логику уже сложнее, и ситуация станет еще ужаснее, когда в рассмотрение войдут другие поля таблицы. Потому мы ограничим вероятные предикаты вот таковой структурой:

(IsUserInRole() AND )

OR

(IsUserInRole() AND )

OR Row-Level Security в РСУБД - реферат ...

(IsUserInRole() AND )

Таким макаром, предикат определяет для каждой группы юзеров требования, которым должна удовлетворять строчка таблицы, чтоб доступ к ней был разрешен.

Лишение доступа

Форма предиката безопасности, рассмотренная выше, предполагает «пессимистичный» режим, т.е. доступ к данным имеют только те категории юзеров, которые очевидно перечислены в предикате.

ПРИМЕЧАНИЕ

Строго говоря, если мы Row-Level Security в РСУБД - реферат не опишем ни 1-го правила, то предикат будет пустым и доступ получат все юзеры. Но выдача таким методом доступа хотя бы одной роли автоматом лишит доступа всех других юзеров. Решить эту делему можно раз и навечно - введя дополнительный член ...OR FALSE в предикат безопасности. Но схожий вырожденный случай несложно Row-Level Security в РСУБД - реферат обработать особым образом, и дальше в тексте всюду подразумевается наличие в перечне доступа хотя бы 1-го очевидного разрешения.

Время от времени удобнее обрисовывать правила безопасности в определениях «оптимистичного» режима, т.е. лишить доступа только некое огромное количество юзеров. В данном случае предикат приобретет таковой вид:

NOT

(

(IsUserInRole() [AND ])

OR ...

(IsUserInRole Row-Level Security в РСУБД - реферат() [AND ])

)

В таком случае доступ предоставляется всем, не считая обозначенных ролей, ну и они лишены доступа только к ограниченной части данных.

Соединив эти два подхода, мы получим возможность как «карать», так и «миловать» юзеров:

(-- секцияразрешений

(IsUserInRole() AND )

OR ...

(IsUserInRole() AND )

)

AND NOT

(-- секциязапретов

(IsUserInRole() [AND ])

OR ...

(IsUserInRole() [AND ])

)

Таковой принцип Row-Level Security в РСУБД - реферат защиты очень похож на применяемый в Windows NT.

Разглядим варианты внедрения данной техники на примере базы данных Northwind, которая заходит в поставку MS SQL Server.

Локальные атрибуты

В простом случае предикаты для всех ролей зависят только от значений полей защищаемой записи. Разглядим таблицу Orders (несущественные для рассматриваемой задачки ограничения пропущены Row-Level Security в РСУБД - реферат):

CREATE TABLE Orders (

OrderID int IDENTITY(1, 1) NOT NULL ,

CustomerID nchar(5) NULL ,

EmployeeID int NULL ,

OrderDate datetime NULL ,

RequiredDate datetime NULL ,

ShippedDate datetime NULL ,

ShipVia int NULL ,

Freight money NULL CONSTRAINT DF_Orders_Freight DEFAULT(0),

ShipName nvarchar(40) NULL ,

ShipAddress nvarchar(60) NULL ,

ShipCity nvarchar(15) NULL ,

ShipRegion nvarchar(15) NULL ,

ShipPostalCode nvarchar(10) NULL Row-Level Security в РСУБД - реферат ,

ShipCountry nvarchar(15) NULL ,

CONSTRAINT FK_Orders_Employees FOREIGN KEY (EmployeeID)

REFERENCES Employees (EmployeeID)

)

Представим, что правила корпоративной безопасности по отношению к данным заказов определены последующим образом:

Менеджеры по продажам (роль ‘Sales Representative’) имеют право просматривать только «свои» заказы и не могут созидать заказы, введенные другими менеджерами по продажам Row-Level Security в РСУБД - реферат.

Директор по продажам (роль ‘Vice President, Sales’) имеет право просматривать любые заказы.

Все другие сотрудники доступа к заказам не имеют.

Этим правилам соответствует вот такое представление:

CREATE VIEW [Secure Orders] AS

SELECT * FROM Orders where

(IsUserInRole('Sales Representative') AND EmployeeID = CurrentEmployeeID())

OR

(IsUserInRole('Vice President, Sales') AND TRUE)

Тут предполагается, что Row-Level Security в РСУБД - реферат функция CurrentEmployeeID() некоторым «магическим» образом возвращает идентификатор сотрудника, соответственный юзеру, от имени которого произведено подключение. Реализация этой функции, как и функции IsUserInRole(), находится в зависимости от применяемой СУБД. Направьте внимание на вторую часть предиката: для директора по продажам никаких дополнительных ограничений не предвидено, но для общности мы использовали Row-Level Security в РСУБД - реферат выражение TRUE для представления этого факта. При подготовке предиката вручную кусок AND TRUE можно опустить, хотя оптимизаторы, применяемые в современных СУБД, довольно умственны, чтоб выкинуть лишниие выражения из плана запроса.

СОВЕТ

Время от времени предикат безопасности возможно окажется так сложным, что оптимизатор СУБД не сумеет без помощи других выстроить лучший план выполнения запроса Row-Level Security в РСУБД - реферат. В таких случаях может потребоваться ручное преобразование выражения предиката в более адекватную форму. Пока мы будем считать, что оптимизатор безупречен, и все выражения будут представлены в более комфортном для чтения виде.

Если в дальнейшем управление компании решит, что доступ к заказам, отгруженным более 6 календарных месяцев вспять Row-Level Security в РСУБД - реферат, можно предоставить всем работникам компании, то предикат безопасности воспримет таковой вид:

(IsUserInRole('Sales Representative') AND EmployeeID = CurrentEmployeeID())

OR

(IsUserInRole('Vice President, Sales') AND TRUE)

OR

(IsUserInRole('Everyone') AND ShippedDate < DateAdd(month, -6, GetDate())

Стоит направить внимание на две особенности предиката:

Во-1-х, (снова же из суждений общности) в дополнительном условии проверяется принадлежность текущего юзера Row-Level Security в РСУБД - реферат к группе Everyone. Эта особая группа по определению включает всех служащих, и выражение IsUserInRole('Everyone') является тождественно настоящим. Это позволяет исключить его из предиката в целях оптимизации.

Во-2-х, условие сопоставления даты отгрузки заказа с текущей датой сформулировано так, чтоб к полю не применялось никакой функции Row-Level Security в РСУБД - реферат. Другие представления такого же выражения:

DateAdd(month, 6, ShippedDate) < GetDate()

и

DateDiff(month, ShippedDate, GetDate()) >= 6

хотя и являются математически эквивалентными, вероятнее всего, помешают оптимизатору СУБД использовать индекс по полю ShippedDate (если он есть).

Атрибуты связанных таблиц

В корпоративную политику безопасности могут заходить и поболее сложные правила, которые связывают разные сути предметной области Row-Level Security в РСУБД - реферат меж собой. К примеру, представим, что компания Northwind выросла, и в ней есть несколько филиалов. Структура таблицы служащих претерпевает надлежащие конфигурации:

ALTER TABLE [Employee]

ADD [DivisionID] int CONSTRAINT [DivisionID_FK]

REFERENCES [Division]([DivisionID])

Новый вариант правила №1 из предшествующего раздела формулируется так:

Менеджеры по продажам (роль ‘Sales Representative’) имеют право просматривать только Row-Level Security в РСУБД - реферат заказы, введенные менеджерами из такого же филиала.

Соответственная часть предиката безопасности сейчас воспримет таковой вид:

(IsUserInRole('Sales Representative')

AND

(select DivisionID from Employees where EmployeeID = CurrentEmployeeID())

= (select DivisionID from Employees where EmployeeID = EmployeeID)

Очередной пример правил безопасности, требующий воззвания к другим таблицам, связан с защитой подчиненных таблиц Row-Level Security в РСУБД - реферат. Совместно с записями в таблице заказов нужно защитить и записи в таблице деталей заказов. Применим правила из предшествующего примера (где еще не было филиалов) к таблице Order Details:

(IsUserInRole('Sales Representative')

AND

select(EmployeeID from Orders o where o.OrderID = OrderID)

= CurrentEmployeeID())

OR

(IsUserInRole('Vice President, Sales') AND Row-Level Security в РСУБД - реферат TRUE)

OR

(IsUserInRole('Everyone')

AND

select(ShippedDate from Orders o where o.OrderID = OrderID)

< DateAdd(month, -6, GetDate())

К огорчению, таковой вид предиката не очень нагляден. Он не отражает связи меж правилами безопасности для деталей заказов и для самих заказов. Потому лучше применить мало другой метод построения представления, чем подвергся рассмотрению ранее:

create view [Secure Row-Level Security в РСУБД - реферат Order Details] as select od.* from [Order Details] od

join [Secure Orders] so on od.OrderID = so.OrderID

В таком виде суть применяемого ограничения безопасности явна. Не считая того, изменение правил безопасности для заказов (которое воздействует на определение представления Secure Orders) автоматом отразится и на их деталях.

В этом случае Row-Level Security в РСУБД - реферат мы не накладываем никаких дополнительных ограничений на детали заказа. Но по мере надобности мы можем точно так же добавить локальный предикат безопасности в условие where.

Некие итоги

Итак, рассмотренная техника позволяет обеспечить разделение прав доступа в определениях значений защищаемых данных. В почти всех случаях этот метод является более комфортным Row-Level Security в РСУБД - реферат, и его главное преимущество – малые усилия по административной поддержке. Модификации потребуются только при изменении корпоративной политики, а это довольно редчайшее явление. Не требуется динамического управления доступом на уровне отдельных объектов – к примеру, заказы, отгруженные сейчас, автоматом станут доступными всем сотрудникам через полгода.

Но в неких случаях требуется предоставлять Row-Level Security в РСУБД - реферат либо отказывать в доступе к определенным записям в административном порядке, независимо от хранящихся в их значений. Такие требования могут быть связаны с быстроменяющимися правилами безопасности, для которых недопустимы задержки в реализации, неминуемые при модификации схемы базы данных. Не считая того, время от времени быстродействия СУБД будет недостаточно для вычисления предикатов безопасности Row-Level Security в РСУБД - реферат на базе имеющихся атрибутов.

Естественным решением данной задачки является внесение в базу дополнительной инфы, не связанной впрямую с моделируемой предметной областью. Модификация этих данных и позволит управлять доступом к определенным записям без конфигурации схемы БД. Методы реализации такового рода решений рассматриваются в последующем разделе.

Ограничения на Row-Level Security в РСУБД - реферат базе дополнительных атрибутов

Все суждения, рассмотренные ранее для имеющихся атрибутов, остаются справедливыми и для дополнительных атрибутов. Мы как и раньше будем рассматривать предикаты безопасности вида. Но сейчас задачка ставится несколько обширнее: если ранее основной неувязкой было конвертировать правила корпоративной безопасности в надлежащие выражения с внедрением имеющейся модели, то сейчас нам Row-Level Security в РСУБД - реферат предстоит дополнить модель данных. Сейчас необходимо раздельно хранить информацию о том, каким ролям предоставлен доступ к каким записям.

Вспомогательная таблица

Исходя из убеждений реляционной модели, записи защищаемой таблицы и роли юзеров находятся в отношении многие-ко-многим. Обычным методом реализации таких отношений является создание вспомогательной таблицы:

CREATE TABLE Row-Level Security в РСУБД - реферат [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 Row-Level Security в РСУБД - реферат() and os.OrderID = OrderID

)

Мы проверяем, что хотя бы одной роли из числа тех, в которые заходит юзер, предоставлен доступ к соответственной записи в таблице заказов.

Сейчас можно динамически выдавать либо отбирать разрешения на записи таблицы заказов каждой из ролей. Разумеется, что сходу после введения предиката в действие никто ничего не увидит – таблица Row-Level Security в РСУБД - реферат Orders Security пуста. Давайте выдадим вице-президенту разрешение на доступ ко всем заказам:

insert into [Orders Security] (OrderID, RoleID)

select OrderID, @VicePresidentRoleID from Orders

Мы предполагаем, что переменная @VicePresidentRoleID уже проинициализирована подходящим значением. Направьте внимание на то, что выполнение таковой команды просит льгот админа БД – нужен доступ Row-Level Security в РСУБД - реферат на чтение из таблицы Orders и запись в таблицу Orders Security. Отметим также то, что, в отличие от ограничений на базе имеющихся атрибутов, которые автоматом используются к новым записям, динамические ограничения требуют модификации вспомогательной таблицы при каждой вставке в основную.

Хранение данных в той же таблице

Рассмотренный выше метод Row-Level Security в РСУБД - реферат реализации динамических ограничений возможно окажется не самым действенным. Если в случае естественных ограничений, выражаемых с помощью локального предиката, затратные расходы были связаны только с вычислением дополнительных выражений, то сейчас в любом случае требуется воззвание к вспомогательной таблице. Почти всегда перечень ролей, которым доступна определенная запись, довольно короток. Правило №3 нашей Row-Level Security в РСУБД - реферат воображаемой корпоративной политики безопасности позволяет связать заказы старше полугода с единственной ролью Everyone, потому что все другие роли уже находятся в ней. Это значит, что в какой-то момент большая часть записей таблицы заказов будут связаны с этой ролью.

В связи с этим появляется искушение сохранить перечень ролей прямо в защищаемой записи Row-Level Security в РСУБД - реферат. Некие СУБД предоставляют возможность хранить списки значений в поле записи, но это является экзотикой. Потому мы выберем другой метод нарушить требования первой обычной формы – будем хранить перечень ролей в виде строчки. Язык SQL предоставляет нам возможность проверить строчку на наличие данной подстроки с помощью оператора like.

В таблицу Row-Level Security в РСУБД - реферат Orders придется внести последующие конфигурации:

alter table orders add ACL varchar(1024) default ','

В поле ACL (Access Control List, перечень контроля доступа) мы будем хранить перечень идентификаторов ролей, разбитый запятыми. Потому предикат безопасности воспримет таковой вид:

ACL like '%,' + cast(GetCurrentUserRoleID() as varchar(12)) + ',%'

Чтоб упростить задачку серверу, нам придется Row-Level Security в РСУБД - реферат добавить «лишние» запятые сначала и в конце строчки.

Необходимо отметить, что схожая техника оправдывает себя исключительно в неких случаях, так что не стоит использовать ее без экспериментальной проверки.

Битовые маски

Очередной вариант представления ACL в защищаемой таблице состоит в использовании битовых операций с целыми числами. Представим, что общее количество ролей в Row-Level Security в РСУБД - реферат системе ограничено каким-то разумным числом, к примеру 32. Тогда можно хранить ACL в виде целого числа (либо нескольких целых чисел, если ролей больше 32х), сопоставив каждой роли фиксированную позицию в этом числе. Предикат безопасности воспримет вот таковой вид:

(ACL & GetCurrentUserRoleMask()) > 0

Как и в прошлом случае, производительность подобного метода может быть Row-Level Security в РСУБД - реферат далека от хорошей, и перед его внедрением нужно провести экспериментальную проверку.

Ограничения на модификацию

До сего времени мы рассматривали только запросы на подборку данных. Модель безопасности, не защищающая данные от несанкционированной модификации, не имеет смысла. Давайте разглядим методы распространить наши заслуги на другие типы запросов SQL.

Точно так же Row-Level Security в РСУБД - реферат, как и для запросов Select, мы должны вычислить предикат безопасности для каждой из строк, которые юзер попробует видоизменять. Нам необходимо сказать юзеру об ошибке, также позаботиться о неминуемой отмене результатов неправильного деяния. Этого можно достигнуть, применяя триггеры.

В слеующих примерах выражение значит предикат, аналогичный рассмотренным выше. Как Row-Level Security в РСУБД - реферат и для select, предикат может быть представлять или естественное, или динамическое ограничение.

Для естественных ограничений принципно важны два предиката: условие, которое инспектирует состояние данных до конфигурации, и отдельное условие, которое инспектирует состояние данных после конфигурации. 1-ое условие нужно инспектировать в триггерах на удаление и изменение записей, а 2-ое – в триггерах на Row-Level Security в РСУБД - реферат изменение и вставку записей. Может показаться искушение использовать более сложные правила для конфигурации данных, но делать этого обычно не стоит. Очень просто получить нецелостную схему безопасности, которая позволяет юзеру получить разные результаты зависимо от порядка действий. К примеру, запрет на повышение суммы заказа более чем на 500 рублей (в один Row-Level Security в РСУБД - реферат прием) просто обходится методом поочередного многократного роста суммы. А запрет на удаление заказов VIP-клиента, не сопровожденный запретом на изменение таких заказов, может привести к искушению просто «переписать» заказ на другого клиента.

Для динамических ограничений придется хранить чуток больше инфы, чтоб учитывать возможность раздельного предоставления прав на Row-Level Security в РСУБД - реферат разные типы модификаций.

Приблизительно так будут смотреться наши триггеры на T-SQL:

Delete

create trigger CheckSecurity on for delete

as

if exists (select * from deleted where not )

begin

RAISERROR ('Access denied', 16, 1)

ROLLBACK TRANSACTION

end

Insert

create trigger CheckSecurity on for insert

as

if exists (select * from inserted where not )

begin

RAISERROR ('Access denied', 16, 1)

ROLLBACK TRANSACTION

end

Update

Этот пример немножко Row-Level Security в РСУБД - реферат труднее, т.к. нам нужно проверить не только лишь старенькые, да и новые значения в таблице:

create trigger CheckSecurity on for insert

as

if exists (select * from inserted where not )

or

exists (select * from deleted where not )

begin

RAISERROR ('Access denied', 16, 1)

ROLLBACK TRANSACTION

end

Заключение

Эти рассуждения носили в значимой мере теоретический нрав. С Row-Level Security в РСУБД - реферат одной стороны, это вселяет уверенность в том, что никакие принципиальные особенности намеченной цели не остались без внимания и лишние подробности не отвлекали от решения.

С другой стороны, тем читателям, которым захочется применить RLS на практике, придется достаточно много потрудиться. Для их предназначен последующий раздел.

Суждения по реализации

1-ый и Row-Level Security в РСУБД - реферат основной совет: экспериментируйте, до того как запускать модификацию в эксплуатацию. Удостоверьтесь, что предикаты составлены правильно.

2-ое: производительность. Самые невинные запросы сейчас будут скрывать внутри себя дополнительные вычисления. Потому не запамятовывайте про индексы. Непременно, кроме сотворения и модификации таблиц будет нужно сделать нужные индексы. Может быть, некие из уже Row-Level Security в РСУБД - реферат имеющихся индексов придется поменять, чтоб планы запросов не очень пострадали. Инспектируйте не только лишь фактическое время выполнения запросов, да и планы, которые строит СУБД.

Ну и последнее: не забудьте аккуратненько назначить привилегии на объекты СУБД таким макаром, чтоб юзеры не могли получить прямой доступ к данным, минуя проверки. Не Row-Level Security в РСУБД - реферат считая того, похлопочите о защите самих определений триггеров и представлений от модификации.

Кандидатуры

Ведущие производители СУБД не оставили рассмотренный в статье вопрос без собственного внимания. Oracle 8i и выше поддерживает так именуемый fine grained access control. Практически, это применение вточности такой же арифметики, но несколько другими техническими средствами Row-Level Security в РСУБД - реферат. Заместо механизма View употребляются особые способности дополнительных пакетов Oracle по установлению политики безопасности.

MS SQL Server 2005 (codename “Yukon”) также будет поддерживать способности RLS. Подробная документация на этот механизм еще не размещена. Точно понятно только то, что в T-SQL будут введены особые конструкции. Судя по имеющимся документам, предикаты безопасности (RULES) будут Row-Level Security в РСУБД - реферат создаваться как отдельные сути, а особые версии команд grant и revoke будут назначать эти предикаты юзерам и группам.



rr-vrrsrrsrryor-srrrrv-rrsrrrrryor-rrrssrssrsryorrrrr-rrrrsr-r-rrsssrrrrryoryo-rrrrrrr-ryo-srrsrr-r-rrrsrrryorryosrrrrrsr-rsrrrs.html
rrguliev-pomoshnik-prokurora-i-priravnennih-k-nim-prokuratur.html
rrr-63066302303-rrsrsrss.html