Анализ условий предоставления и получения прав доступа в модели управления доступом MS SQL Server Текст научной статьи по специальности «Компьютерные и информационные науки»

2014 Математические основы компьютерной безопасности №2(24)

МАТЕМАТИЧЕСКИЕ ОСНОВЫ КОМПЬЮТЕРНОЙ БЕЗОПАСНОСТИ

УДК 004.94

АНАЛИЗ УСЛОВИЙ ПРЕДОСТАВЛЕНИЯ И ПОЛУЧЕНИЯ ПРАВ ДОСТУПА В МОДЕЛИ УПРАВЛЕНИЯ ДОСТУПОМ MS SQL SERVER

В. Ю. Смольянинов

Учебно-методическое объединение по информационной безопасности, г. Москва, Россия

E-mail: VladimirSmall@gmail.com

Рассматривается модель управления доступом MS SQL Server, построенная на основе СУБД ДП-модели. Для учёта особенностей управления доступом в СУБД MS SQL Server 2012 в модель добавлены роли, права доступа к учётным записям пользователей и ролям, цепочки владения, а также возможность олицетворения пользователей и активации триггеров и процедур от имени заданных учётных записей пользователей. Доказывается утверждение об эквивалентности возможности выполнения произвольного SQL-кода от имени заданной учётной записи и возможности получения к ней права олицетворения. Обосновываются необходимые и достаточные условия получения и предоставления прав доступа к сущностям при отсутствии кооперации между субъект-сессиями.

Ключевые слова: компьютерная безопасность, модель управления доступом MS SQL Server, система управления базами данных.

Введение

Современные реляционные системы управления базами данных (СУБД) зарекомендовали себя как надёжное и эффективное решение задач поиска, хранения и обработки информации. Разработчики автоматизированных информационных систем используют СУБД не только для решения этих задач, но и для защиты информации и, в частности, для управления доступом к обрабатываемым данным. Существующие формальные модели логического управления доступом [1, 2] ориентированы в основном на применение в ОС и не учитывают некоторых существенных особенностей функционирования автоматизированных информационных систем, построенных с использованием реляционных СУБД, которые могут быть использованы нарушителем для реализации запрещённых доступов и информационных потоков. Таким образом, теоретический анализ условий, при которых возможно несанкционированное распространение прав доступа в автоматизированных информационных системах, использующих штатные механизмы управления доступом СУБД, является важной и актуальной задачей.

В [3] предпринята попытка построения СУБД ДП-модели, в которой учитывается наследование прав доступа к дочерним сущностям, существование прав на предоставление прав доступа, а также возможность автоматического выполнения SQL-кода при реализации доступа к данным и изменения учётной записи пользователя при активации хранимых процедур и триггеров. Тем не менее данная модель не учитывает

в полной мере некоторых существенных особенностей организации управления доступом в новой версии СУБД MS SQL Server 2012. В частности, игнорируются роли, наличие прав доступа к учётным записям пользователей и ролям, цепочки владения, возможность олицетворения и выполнения триггеров и процедур от имени заданных учётных записей.

В настоящей работе на базе СУБД ДП-модели [3] построена модель управления доступом MS SQL Server, в которой учитываются перечисленные особенности управления доступом и проведено необходимое уточнение правил преобразования состояний. Описываются элементы модели, предназначенной для анализа безопасности управления доступом в СУБД MS SQL Server. Построенная модель может быть в дальнейшем адаптирована для анализа безопасности других реляционных СУБД.

1. Определения и обозначения

В предлагаемой модели управления доступом MS SQL Server структура множества сущностей задаётся следующим образом:

— C — множество контейнеров;

— Ot — множество триггеров;

— Op — множество процедур;

— U — множество учётных записей пользователей;

— R — множество ролей;

— P = U U R — множество принципалов, при этом считается, что U П R = 0;

— E = C U Op U P — множество сущностей, при этом считается, что множества процедур, триггеров, контейнеров и принципалов попарно не пересекаются. Множество контейнеров реальных реляционных СУБД включает такие сущности,

как экземпляр СУБД, экземпляры баз данных, схемы и таблицы. В рамках модели не рассматривается управление доступом к отдельным записям таблиц и поэтому в модель не включено множество записей. Причиной этому служит отсутствие в СУБД MS SQL Server штатных механизмов контроля доступа на уровне отдельных записей. Кроме того, согласно [4], присутствующие в СУБД MS SQL Server 2012 штатные механизмы управления доступом к отдельным полям таблиц не рекомендованы к использованию и, возможно, будут исключены в будущем.

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

Считается, что триггеры и процедуры содержат SQL-код, выполнение которого приводит к реализации преобразований системы, задаваемых правилами, описываемыми в п. 2. В реальных системах процедуры могут принимать формальные параметры. При вызове хранимой процедуры ей передаются фактические значения формальных параметров, что приводит к выполнению некоторой фиксированной последовательности операторов. В рамках модели считается, что каждой хранимой процедуре, принимающей входные параметры, соответствует множество процедур. При этом каждой допустимой комбинации значений фактических параметров соответствует отдельная процедура, содержащая SQL-код, являющийся результатом их подстановки в операторы хранимой процедуры. Если внутри хранимой процедуры имеются операторы вызова других хранимых процедур, принимающих параметры, то каждый такой вызов

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

Большинство современных СУБД реализуют, как минимум, дискреционное управление доступом учётных записей пользователей к контейнерам и процедурам. В СУБД MS SQL Server 2012 пользователи представлены на двух уровнях [4]: в виде логинов (logins) на уровне экземпляра СУБД и в виде пользователей (users) на уровне экземпляра базы данных. Для логинов могут быть заданы права к экземпляру СУБД, а для пользователей — права доступа к сущностям, находящимся в базе данных. Каждому пользователю базы данных соответствует единственный логин. В рамках модели различия между логинами и пользователями игнорируются и считается, что каждый пользователь имеет уникальную учётную запись.

Для повышения гибкости управления правами доступа СУБД MS SQL Server реализует элементы ролевого управления доступом. Роли являются совокупностью прав доступа к сущностям. В СУБД MS SQL Server 2012 роли присутствуют на двух уровнях [4]: на уровне экземпляра СУБД (серверные роли, server roles) и на уровне базы данных (роли базы данных, database roles). В рамках модели различия между серверными ролями и ролями базы данных игнорируются. В СУБД роли бывают двух видов: фиксированные роли (fixed roles) и гибкие роли (flexible roles). Отличие фиксированных ролей от гибких состоит в том, что у последних можно управлять не только членством в роли, но и совокупностью предоставленных ей прав доступа к сущностям. Для управления авторизацией на фиксированную роль требуется наличие авторизации на неё у учётной записи инициировавшего операцию пользователя. В рамках модели игнорируется отличие между фиксированными и гибкими ролями.

Для упрощения процедуры администрирования в СУБД поддерживается управление правами доступа с учётом иерархических отношений между сущностями, а также выполняется неявное предоставление всех возможных прав доступа владельцам сущностей. В СУБД обладать правами доступа к сущностям и быть их владельцами могут не только учётные записи пользователей, но и роли. Таким образом, множество принципалов P задаёт участников безопасности, которым могут быть предоставлены права доступа к сущностям. В СУБД права доступа могут быть заданы не только в отношении контейнеров и процедур, но и в отношении самих принципалов, и, следовательно, множество сущностей задаётся как E = C U Op U P. Заметим, что в рамках модели триггеры не рассматриваются как сущности, так как в СУБД MS SQL Server отсутствуют механизмы управления доступом к ним и, значит, они не являются объектами доступа.

Обозначим Eh = E U Ot, элементы которого будем называть сущностями (технически это не совсем корректно, так как триггеры не считаются сущностями; EП Ot = 0). В дальнейшем будем использовать термин «сущность» как в широком смысле (в отношении элементов множества Eh ), так и в узком (в отношении элементов множества E); использование термина будет понятно из контекста. Тогда принципал владельца сущности задаётся с помощью функции owner: Eh ^ P. По определению будем считать, что владельцем учётной записи является она сама, то есть для каждого u Е U верно owner (u) = u.

Заметим, что в СУБД MS SQL Server триггеры не имеют владельцев. Тем не менее в рамках модели удобно считать, что у любого триггера есть владелец, совпадающий с владельцем таблицы, к которой он относится. У каждой сущности задан единственный владелец, который определяется в момент её создания. Для простоты в модели игнорируется присутствующая в СУБД возможность задания принципала владельца

сущности с использованием SQL-выражения ALTER AUTHORIZATION ON (для баз данных, схем, таблиц и процедур), и поэтому выполняется следующее предположение.

Предположение 1. Для любой сущности e учётная запись пользователя владельца owner (e) после создания сущности e не изменяется.

В СУБД MS SQL Server владельцами сущностей могут являться не только учётные записи пользователей, но и роли. Для учёта данной особенности функционирования СУБД областью значений функции owner является множество принципалов P.

Функция owner введена в модель в связи с тем, что в современных СУБД владелец сущности получает к ней все права доступа. Если же сущность является контейнером, то владелец неявно получает все возможные права доступа не только к самому контейнеру, но и ко всем сущностям, которые в нём содержатся.

Используем также следующие обозначения и определения:

— S — множество субъект-сессий пользователей, при этом считается, что S П E = 0;

— user: S ^ U — функция, задающая для каждой субъект-сессии учётную запись пользователя, от имени которой она выполняется;

— U* — множество всех конечных последовательностей учётных записей пользователей;

— user_stack: S ^ U* — функция, задающая для каждой субъект-сессии последовательность учётных записей пользователей, от имени которых она выполнялась.

Субъект-сессии соответствуют сессиям пользователей с СУБД, которые, в отличие от процессов ОС, не являются объектами доступа и потому не считаются сущностями. Субъект-сессии инициируют выполнение SQL-кода, что приводит к реализации заданных в нём преобразований состояний системы.

Субъект-сессии применяют правила преобразования состояний системы от имени учётных записей пользователей из множества U. В реальных СУБД для создания новой сессии требуется указать в строке подключения данные, аутентифицирующие подключающегося пользователя. Изначально субъект-сессия начинает применять правила от имени учётной записи пользователя, инициировавшей её создание. Однако при переходе системы из состояния в состояние допускается изменение значений функции user, что связано с наличием в реальных СУБД возможности выполнения кода хранимых процедур и триггеров от имени учётной записи, не являющейся инициатором их выполнения. Отметим, что возможность изменения значений функции user является существенным отличием от моделей ролевого управления доступом и ДП-моделей, в которых предполагается неизменность её значений.

В СУБД пользователь имеет возможность с применением оператора REV ERT восстановить учётную запись пользователя, от имени которой субъект-сессия выполнялась до момента предыдущего изменения контекста выполнения. Функция user_stack добавлена в модель для обеспечения возможности восстановления субъект-сессией s всех предыдущих значений функции user(s).

Функция cmode: C ^ {creator, parent} задаёт для каждого контейнера режим установки владельца вновь создаваемых дочерних сущностей. Пусть для некоторого контейнера c Е C в рамках сессии s Е S было инициировано создание дочерней сущности контейнера c. Тогда, если значение cmode(c) = creator, то владельцем вновь созданной дочерней сущности становится учётная запись пользователя user(s). В противном случае, если значение cmode(c) = parent, то владельцем вновь созданной дочерней сущности становится принципал owner(c).

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

Предположение 2. Для любого контейнера c Е C режим установки владельца вновь создаваемых дочерних сущностей cmode(c) после его создания не изменяется.

Необходимость во введении функции cmode связана с тем, что в СУБД MS SQL Server владельцем таблиц и процедур является владелец схемы, которой они принадлежат. С другой стороны, владельцем базы данных становится учётная запись создавшего её пользователя.

Для учёта возможности изменения учётной записи пользователя при выполнении триггеров и процедур введена функция execute_as: Op U Ot ^ U U {as_caller}, значение которой задаёт режим выполнения процедур и триггеров, а также определяет учётную запись пользователя, от имени которой субъект-сессии будут выполнять их SQL-код. Отметим, что случай execute_as(e) = u, где u = owner(e) и u Е U, соответствует механизму повышения полномочий SUID в ОС семейства UNIX, а случай execute_as(e) = as_caller — механизму имперсонации (олицетворения) в ОС семейства Windows. Если некоторая субъект-сессия s Е S инициировала выполнение процедуры или триггера e Е Op U Ot и execute_as(e) = as_caller, то код сущности e будет выполняться от имени учётной записи пользователя user(s), от имени которой s выполнялась непосредственно до запуска SQL-кода сущности e. В противном случае, если execute_as(e) = u, где u Е U, то код сущности e будет выполняться субъект-сессией s от имени учётной записи пользователя u.

Заметим, что в модели не рассматриваются два присутствующих в СУБД режима выполнения триггеров и процедур: от имени владельца (AS OWNER) и от имени учётной записи пользователя, последним изменившим их SQL-код (AS SELF). Оба этих режима могут рассматриваться как частные случаи выполнения SQL-кода процедур и триггеров от имени заданной учётной записи пользователя. Заметим, что в СУБД режим выполнения от имени владельца может быть задан только для триггеров и процедур, владельцем которых являются учётные записи, а не роли.

Выше уже отмечалось, что СУБД MS SQL Server поддерживает базовые механизмы ролевого управления доступом, для учёта которых в модель добавлен ряд элементов, в частности функция UA: U ^ 2R — функция авторизованных ролей учётных записей пользователей, задающая для каждой учётной записи пользователя множество ролей, на которые она может быть авторизована.

В дальнейшем будем считать, что выполняется следующее предположение.

Предположение 3. Для каждой роли r Е R существует учётная запись пользователя u, такая, что r Е UA(u). Таким образом, для каждой роли существуют авторизованные на неё пользователи.

Будем считать, что существует выделенная роль public Е R, такая, что для каждого u Е U верно public Е UA(u), то есть на роль public авторизованы учётные записи всех пользователей.

В СУБД MS SQL Server учётные записи пользователей нельзя лишить авторизации на роль public. Роль public считается фиксированной, однако в отличие от других фиксированных ролей существует возможность управлять совокупностью предоставленных ей прав доступа. Именно поэтому в рамках модели данная роль считается гибкой и отнесена с указанными выше ограничениями к множеству ролей R.

Будем считать, что на множестве ролей R задано отношение частичного порядка, которое удовлетворяет следующему определению.

Определение 1. Иерархией ролей называется заданное на множестве ролей R отношение частичного порядка ^. При этом по определению выполняется: если для пользователя u Е U роли r,r' Е R такие, что r Е UA(u) и r' ^ r, то r' Е UA(u).

В случае, когда для двух ролей r1,r2 Е R выполняются условия ri ^ r2 и ri = r2, будем использовать обозначение r1 < r2.

Будем считать, что существует выделенная роль sysadmin Е R, такая, что для каждой роли r Е R выполняется r ^ sysadmin.

В СУБД MS SQL Server фиксированная роль sysadmin считается ролью системных администраторов. Пользователи, авторизованные на данную роль, могут выполнять произвольные действия с любой сущностью СУБД.

В рамках модели считается, что субъект-сессия, выполняемая от имени некоторой учётной записи пользователя, авторизована на все её роли. Следовательно, можно считать, что учётная запись пользователя обладает правами доступа всех ролей, на которые она может быть авторизована. Так как на множестве ролей задана иерархия, учётная запись пользователя обладает правами доступа всех ролей, «иерархически подчиненных» роли, на которую она может быть авторизована.

В СУБД MS SQL Server иерархия на множествах гибких и фиксированных ролей задаётся путём предоставления «членства в роли»: считается, что если роль r2 является членом роли r1, то r1 ^ r2. Отметим, что авторизация пользователей на роль также осуществляется путём предоставления пользователю «членства в роли». Рассмотрим следующий пример. Пусть роль Hackers является членом роли Users и роли Users предоставлено право доступа на чтение к таблице Table, а роли Hackers предоставлено к ней право доступа на запись. Тогда если пользователь Alice является членом группы Users, то ей предоставлено право доступа на чтение к таблице Table, в то время как члену группы Hackers пользователю Bob предоставлено право доступа к таблице Table как на чтение, так и на запись.

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

Определение 2. Определим H: C ^ 2Eh — функцию иерархии сущностей, сопоставляющую каждому контейнеру c Е C множество H(c) С Eh и удовлетворяющую следующим условиям.

Условие 1. Пусть Pr(e) = {c Е C : e Е H (c)} —множество родительских контейнеров сущности e. Тогда существует единственный корневой контейнер cr Е C, такой, что lPr(cr)| = 0, owner(cr) = sysadmin и для каждой сущности e Е EH \ {cr} выполняется lPr(e)l = 1.

Условие 2. Для каждой сущности e Е Eh либо e = cr, либо существуют контейнеры c1, ... ,cn Е C, где n ^ 1, такие, что c1 = cr, ci+1 Е H (ci) для i = 1,... ,n — 1 и e Е H(cn), при этом если e Е P, то n = 1.

Условие 3. Пусть T = {c Е C : 3ot Е Ot (ot Е H (c))} — множество таблиц. Тогда для каждой таблицы t Е T по определению выполняется H(t) С Ot и для каждого ot Е H(t) верно owner(ot) = owner(t).

Условие 4. Для каждой сущности e Е Op U T выполняется равенство cmode(Pr(e)) = parent.

Определение 3. Если для сущности e Е Eh существует контейнер c Е C, такой, что e Е H(c), то будем говорить, что контейнер c содержит сущность e, а сущность e содержится в контейнере c; также будем говорить, что c является родительским контейнером сущности e, а e — дочерней сущностью контейнера c.

Будем считать, что единственный корневой контейнер cr, у которого отсутствуют родительские контейнеры, соответствует экземпляру СУБД. Владельцем корневого контейнера cr является роль sysadmin.

Согласно условию 2 определения 2, родительским контейнером всех принципалов является корневой контейнер cr. В реальных СУБД роли не считаются частью иерархии сущностей, тем не менее владелец экземпляра СУБД обладает всеми правами доступа к принципалам. Следовательно, удобно считать, что все принципалы являются дочерними сущностями cr.

Помимо корневого контейнера cr, в рамках модели выделяется особый вид контейнеров — таблицы. Согласно условию 3 определения 2, для каждой таблицы t Е T выполняется H (t) С Ot, из чего следует, что таблицы не могут иметь дочерних контейнеров и содержат только триггеры. В реальных СУБД триггеры связаны с таблицами, а не содержатся в них, при этом наличие права доступа к таблице на изменение её способа задания (ALTER) позволяет также изменять способ задание её триггеров. Следовательно, в рамках модели удобно считать триггеры частью иерархии и дочерними сущностями таблиц.

Выше отмечалось, что в СУБД MS SQL Server владельцем таблиц и процедур является владелец схемы, в которой они содержатся. Для того чтобы модель соответствовала данному ограничению, в определение 2 введено условие 4: режим установки владельца для контейнеров, содержащих таблицы и процедуры, должен быть равен parent.

Наконец отметим, что в отличие от реальных СУБД модель не накладывает ограничений на число уровней вложенности в иерархии.

В СУБД принципалы, имеющие права доступа к контейнерам, получают также права ко всем сущностям, расположенным ниже по иерархии. Для учёта этой особенности управления доступом введём определение отношения иерархической подчинённости сущностей.

Определение 4. Будем говорить, что сущность e Е Eh иерархически подчинена контейнеру c Е C, если существуют контейнеры c1,... ,cn Е C, где n ^ 1, такие, что c1 = c, ci+1 Е H(ci) для i = 1,... ,n — 1 и e Е H(cn).

В случае, если сущность e Е Eh иерархически подчинена контейнеру c Е C, будем использовать обозначение e < c. В случае, если сущность e Е Eh иерархически подчинена контейнеру c Е C или равна ему, будем использовать обозначение e ^ c.

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

Замечание 1. Из определений 2 и 4 следует, что для любой сущности e Е Eh \ {cr} существует контейнер c Е C, такой, что e < c. Очевидно, что каждая сущность либо является корневой, либо иерархически подчинена корневой сущности cr и содержится ровно в одном из её дочерних контейнеров.

Итак, для каждой сущности, за исключением корневой, существует единственный контейнер, в котором она содержится. Кроме того, в соответствии с условием 3 определения 2 в множество таблиц включаются все контейнеры, содержащие хотя бы один

триггер. Следовательно, для каждого триггера ot Е Ot существует ровно одна таблица t Е T, в которой он содержится, то есть ot Е H(t).

Замечание 2. Легко показать, что если для некоторой сущности e Е Eh существуют контейнеры c1,...,cn Е C, где n ^ 1, такие, что c1 = cr, ci+1 Е H(q) для i = 1,... ,n — 1 и e Е H(cn), и контейнеры d1,... ,dn, Е C, где n' ^ 1, такие, что d1 = cr, c'i+1 Е H(ci) для i = 1,... ,n' — 1 и e Е H(dn,), то n = n' и d{ = ci для i = 1,... ,n. Это означает, что для любой некорневой сущности e Е Eh существует единственная последовательность, начинающаяся с cr и заканчивающаяся контейнером, содержащим e, такая, что каждый её элемент является родительским для последующего.

Определение 5. Функция holders: EH ^ 2P задаёт для каждой сущности принципалы её иерархических владельцев, при этом для каждой сущности e Е Eh по определению p Е holders(e) тогда и только тогда, когда либо p = owner(e), либо существует контейнер c Е Pr(e), такой, что p Е holders(c).

Принципалы иерархических владельцев сущности обладают к ней всеми возможными правами доступа. Заметим, что значения функции holders однозначно определяются функцией иерархии сущностей H и функцией задания владельцев сущностей owner, и поэтому она не рассматривается в качестве самостоятельного элемента состояния системы.

Введём множество видов прав доступа к сущностям Rr, которые соответствуют по смыслу и назначению традиционным для СУБД разрешениям SELECT, UPDATE, INSERT, DELETE, ALTER, EXECUTE и IMPERSONATE:

Rr = {selectr, insertr,updater, deleter, alterr, executer, impersonater}.

Считается, что наличие у учётной записи пользователя прав доступа selectr, insertr, updater или deleter к таблице позволяет реализовать к ней соответствующее право доступа (то есть выполнить операции выборки, вставки, обновления и удаления соответственно). Обладание правом доступа alterr к процедуре позволяет задавать её SQL-код и режим выполнения. Право доступа alterr к таблице позволяет создавать в ней триггеры, а также изменять SQL-код связанных с ней триггеров и режим их выполнения. Наличие права доступа executer к процедуре позволяет выполнять её SQL-код. Наличие права доступа impersonater к учётной записи пользователя позволяет инициировать выполнение SQL-кода от её имени. Заметим, что право доступа impersonater неприменимо к ролям, и поэтому область значений функции execute_as задана как U U {as_caller}, а не как P U {as_caller}. Кроме того, наличие права доступа alterr к процедуре op Е Op и impersonater к учётной записи u Е U позволяет установить режим выполнения процедур op от имени учётной записи пользователя u. Аналогично, для задания режима выполнения триггеров таблицы t Е T от имени учётной записи пользователя u Е U требуется наличие права доступа alterr к таблице, а также права доступа impersonater к учётной записи пользователя u.

В СУБД MS SQL Server существует разрешение TAKE OWNERSHIP, позволяющее стать владельцем сущности. По умолчанию, разрешение TAKE OWNERSHIP к сущности может быть предоставлено только её владельцем и администраторами СУБД. В рамках модели возможность изменения владельцев сущностей игнорируется.

Введём Rd С P х E х Rr — множество непосредственно заданных прав доступа принципалов к сущностям. Права доступа к сущностям добавляются в множество Rd в результате явного применения правил преобразования системы, а не в результате обладания ролью или правами доступа к контейнеру, которому иерархически подчинена сущность.

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

Введём Ксушп = {(Р,е,аг) : е Є Е,р = ошиег(е),аг Є Кг} —множество прав доступа принципалов владельцев к сущностям. В соответствии со способом задания К(шп принципалы владельцев сущностей обладают к ним всеми правами доступа.

Для учёта того, что принципалы, имеющие право доступа к контейнеру, также обладают им ко всем его иерархически подчинённым сущностям, вводится множество иерархических прав доступа принципалов к сущностям:

Кн = {(р, е, аг) : р Є Р,е Є Е,аг Є Кг, За Є С((р, с, аг) Є Ка и Кошп & е < с)}.

Обозначим РК = Ка и Кошп и Кн. Введём Ке — множество действующих прав доступа с учётом того, что на множестве ролей задана иерархия и каждая субъект-сессия авторизована на все роли, на которые авторизована учётная запись пользователя, от имени которой она выполняется. Заметим, что для удобства множество Ке задано таким образом, чтобы роли имели права доступа всех иерархически подчинённых им ролей:

Ке = {(и, е, аг) : и Є и,е Є Е,аг Є Кг((и, е, аг) Є РК)}и и{(и,е,аг) : и Є и,е Є Е,аг Є Кг, Зг Є К((г,е,аг) Є РК & г Є иА(и))}и и{(г, е, аг) : г Є К,е Є Е,аг Є К, Зг' Є К((г', е, аг) Є РК, г' ^ г)}.

При определении возможности применения правил преобразования состояний учитываются права доступа, содержащиеся в множестве Ке. Полагается, что субъект-сессии в, функционирующей от имени учётной записи пользователя и = ивег(в), разрешено реализовать доступ вида аг к сущности е в случае, если (и,е,аг) Є Ке, то есть у учётной записи пользователя и есть действующее право доступа аг к сущности е (далее в этом случае будем говорить о наличии права доступа).

Отметим, что множество Ке включает права доступа учётных записей пользователей с учётом ролей, на которые они авторизованы.

Очевидно, что из способа задания множеств Кн и Ке следует

Замечание 3. Если и Є и, е,е' Є С и Ор, аг Є Кг, е ^ е' и (и,е',аг) Є Ке, то

(и, е, аг) Є Ке.

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

Как правило, в ОС, реализующих механизмы дискреционного управления доступом, назначать права доступа к сущности может только её владелец и, возможно, пользователь, обладающий привилегиями администратора. Указанные пользователи могут предоставить произвольное право доступа к сущности любому другому пользователю системы. В то же время в современных СУБД присутствуют штатные механизмы, позволяющие делегировать предоставление прав доступа к сущности заданному для неё кругу учётных записей пользователей. При этом СУБД позволяют ограничить для каждой учётной записи из этого круга набор прав доступа к сущности, которые она может предоставлять.

Обозначим:

— Grd С P x E x R, — множество непосредственно заданных прав принципалов на предоставление прав доступа к сущностям, удовлетворяющее условию Gr'd С Rd;

— Grhld = {(p^,а,) : а, Є R,,e Є E,p Є holders(e)} —множество прав доступа принципалов на предоставление прав доступа иерархическими владельцами сущностей;

— PGr = Gr'd U Grhld. Тогда, с учётом того, что учётная запись пользователя обладает правами всех ролей, на которые она может быть авторизована, а также с учётом того, что роль обладает правами всех иерархически подчинённых ей ролей, введём множество действующих прав доступа учётных записей пользователей на предоставление прав доступа к сущностям:

Gre = {(u, e, а,) : u Є U,e Є E,а, Є R, ((u^,а,) Є PGr)}U U{(u, e, а,) : u Є U,e Є E,а, Є R,, 3r Є R((r, e, а,) Є PGr к r Є UA(u))}U U{(r, e^,) : r Є R,e Є E,а, Є R, 3r' Є R^r^e^,) Є PGr,r' ^ r)}.

Множество Gre включает права доступа на предоставление прав доступа учётных записей пользователей, с учётом ролей, на которые они могут быть авторизованы. Заметим, что для удобства множество Gre задано таким образом, чтобы роли имели возможность предоставлять права доступа к сущностям, к которым могут предоставлять права их иерархически подчинённые роли.

Множества Grhld и Gre однозначно определяются множеством непосредственно заданных прав доступа учётных записей пользователей на предоставление прав доступа к сущностям Gr'd, функцией иерархии сущностей H, функцией авторизованных ролей пользователей UA, а также функцией задания владельцев сущностей owner и поэтому не рассматриваются в качестве самостоятельных элементов состояния системы.

Для удобства введём обозначение Gr(e, а,) = {p Є P : (p, e, а,) Є Gre} — множество принципалов, которые могут предоставлять право доступа а, Є R, к сущности e Є E. В рамках модели полагается, что субъект-сессии s, функционирующей от имени учётной записи пользователя u = user(s), разрешено предоставить право доступа вида а, к сущности e, если u Є Gr(e, а,), то есть учётная запись пользователя u обладает действующим правом доступа на предоставление права доступа а, к сущности e (далее в этом случае будем говорить о наличии права доступа на предоставление права доступа).

В современных СУБД для того чтобы пользователь имел возможность предоставить право доступа к сущности, требуется, чтобы он сам обладал к ней этим правом доступа. Обоснуем, что в рамках модели необходимым условием наличия у учётной записи пользователя u Є U права на предоставление права доступа а, к сущности e Є E является наличие у u права доступа а, к e.

Утверждение 1. Gre С Re.

Доказательство. Заметим, что, согласно способу задания множеств Re и Gre, достаточно показать, что PGr С PR. По способу задания PGr = Grd U Grhld и Grd С Rd С PR. Покажем, что Grhld С PR. Пусть (p, e, а,) Є Grhld, где e Є E, а, Є R, и p Є holders(e). В случае p = owner(e), согласно способу задания множества Rown, выполняется (p^^,) Є Rown С PR. Пусть p = owner(e). Согласно условию З определения 2, для каждой сущности e Є E либо e = c,, либо существуют контейнеры c1,...,cn Є C, где n ^ І, такие, что c1 = c,, ci+1 Є H(c,) для i = І,...,п — І и e Є H(cn). Согласно замечанию 2, такая последовательность единственна. Следовательно, в соответствии со способом задания множество holders(e) состоит из элемен-

тов owner (ci),..., owner(cn), owner(e). Так какp = owner (e), существует i Є {1,..., n}, такое, что p = owner {сі) и e < ci. Так как p = owner(ci), по способу задания множества Rcywn выполняется {p,ci,ar) Є Rcywn. Таким образом, выполняется p Є P, e Є E, ar Є Rr и существует контейнер ci Є C, такой, что {p, сі, ar) Є Rown и e < ci. Тогда по способу задания множества Rh выполняется {p, e, ar) Є Rh ^ PR. ■

Используем следующие обозначения:

— OPint — множество внутренних правил преобразования состояний, заданных в табл.1;

— OPext —множество внешних правил преобразования состояний, заданных в табл. 2;

— OP = OPint U OPext —множество правил преобразования состояний;

— OP*xt —множество всех конечных последовательностей внешних правил преобразования состояний;

— OP* —множество всех конечных последовательностей правил преобразования состояний;

— tr Є OP * —последовательность всех применённых правил, из которой исключены правила, условия применения которых не были выполнены;

— assocf {s): S ^ Op U Ot U {0} — функция, задающая для каждой субъект-сессии s Є S функционально ассоциированную с ней сущность. Для сущностей, функционально-ассоциированных с субъект-сессией s, используется обозначение [s];

— operations: Op U Ot ^ OP*xt — функция, задающая для каждой процедуры и триггера соответствующие им последовательности внешних правил преобразования состояний, реализуемых при выполнении субъектами-сессиями их SQL-кода.

Т а б л и ц а І

Внутренние правила преобразования состояний

Правило Исходное состояние G Результирующее состояние G'

do switch(s, o,u) s Є S,o Є OpUOtU{0}, u Є U G'{user', assocf ,tr'} ~ G, user' {s ^ u} ~ user, assocf {s ^ o} ~ assocf, tr' = (tr, do switches, o, u))

execute(s, o) s Є S, o Є Op U Ot,e = [s], operations(o) = = (opi, .. .,opk), k > 0, Vi Є {1, ..., k}(opi Є OPext) G'' = G(do switch(s, o, u), opi,. .., opk, do switch(s,e,user(s))), где 1 user(s) при execute as(o) = as_caller, 1 иначе execute as(o) G'{user stack'} ~ G'', где user stack' = user stack

Т а б л и ц а 2

Внешние правила преобразования

Правило Исходное состояние G Результирующее состояние G'

create session (s,u) u Є U, s Є S G'{S', user', user stack', assoc1',tr'} ~ G, S' = S U {s}, user'{s ^ u} ~ user, user stack' {s ^ (u)} ~ user stack, assocf {s ^ 0} ~ ~ assocf, tr' = (tr, create session(s,u))

switch(s, u) s Є S, u Є U, (user(s),u, impersonate,.) Є Re G'' = G(do switch(s, [s],u)), G'{user stack', tr'} ~ G'', user stack'{s ^ (user stack(s),u)} ~ user stack'', tr' = (tr'', switch(s,u))

revert(s) s Є S, user stack(s) = = (ui,. .. ,uk-i,uk), k > 1 G'{user', user stack',tr'} ~ G, user'{s ^ ^ umax(i,fe-i)} ~ user, user stack'{s ^ (ui, ..., umax(i,fc-i))} ~ user stack, tr' = (tr, revert(s))

Окончание таблицы 2

Правило Исходное состояние G Результирующее состояние G'

grant right (s, p, e, ar, with grant) s E S, p E P, e E E, ar E Rr, user(s) E Gr(e, ar), with grant E {yes, no} G'{R'd, Gr'd, tr'} ~ G, Rd = Rd U {(p, e, ar)}, I Grd U {(p, e, ar)} при with grant = yes, Grd = < . 1 Grd при with grant = no tr' = (tr, grant right(s,p,e,ar ,with grant))

add member (s, r, u) s E S, r E R, u EU (user(s),r, alterr) E Re G'{UA',tr'} - G, UA'{u ^ UA(u) U{r' eR : r' < r}} - UA, tr' = (tr,add role member(s,r,u))

create container (s, cp, c, mode) s E S, cp E C, c/C, (user(s), cp, alterr) E Re mode E {creator,parent} G'{E'H, H', owner', cmode',tr'} — G, EH = C' U Op U P U Ot, C' = C U {c}, H'{c ^ 0,cp ^ H(cp) U {c}} — H, owner'{c ss p} — owner, где I user(s) при cmode(cp) = creator, p= 1 owner(cp) при cmode(cp) = parent cmode'{c s mode} — cmode, tr' = (tr, create container(s, cp, c, mode))

create procedure (s, c, op, md, opi,. .., opk) s E S,cE C \ T, op E Op, cmode(c) = parent, mdEU U {as_caller}, k^0, Vi E {1, .. . k}(opi E OPext), (user(s), c, alterr) E Re; если md U, то (user(s), md,impersonater) E Re G'{E'H, H', owner', execute as', operations', tr'} — G, E'H = C U O'p U P U Ot, O'p = Op U {op}, H'{c s H(c) U {op}} - H, owner'{op s owner(c)} — owner, execute as'{op s md} — execute as, operations'{op s (opi,. .., opk)} — operations, tr'=(tr, create procedure(s, c, op, md, opi,. .., opk))

alter procedure (s, op, md, opi, ..., opk) s S, op Op, mdEU U {as_caller}, k^0, Vi E {1, . ..k}(opi E OPext), (user(s), op, alterr) E Re; если md U, то (user(s), md,impersonater) E Re G'{execute as', operations',tr'} — G, execute as'{op s m} — execute as, operations'{op s (opi,. .., opk)} — operations, tr' = (tr, alter procedure(s, op, md, opi, .. ., opk))

create trigger (s, ot,t, ar, md, opi, ..., opk) s E S, t E T, ot E Ot, ar E {insertr, updater, deleter }, mdEU U {as_caller}, k^0, Vi E {1, .. . k}(opi E OPext), (user(s),t, alterr) E Re; если md U, то (user(s), md,impersonater) E Re G'{E'H, H', owner', execute as', triggers', operations',tr'} — G, E'H = Eh U O't, O' = Ot U {ot}, H'{t s H(t) U {ot}} — H, owner'{ot s owner(t)} — owner, execute as'{ot s md} — execute as, triggers'{(t, ar) s (triggers(t, ar),ot)} — — triggers, operations'{ot s (opi,. .., opk)} — — operations, tr' = (tr, create trigger(s, ot,t, ar, md, opi, ..., opk))

alter trigger (s, ot,t, md, opi,..., opk) s E S,t E T, ot E H(t), mdEU U {as_caller}, k^0, Vi E {1, .. . k}(opi E OPext), (user(s),t, alterr) E Re; если md U, то (user(s), md,impersonater) E Re G'{execute as', operations', tr'} — G, execute as'{ot s md} — execute as, operations'{ot s (opi, .. ., opk)} — operations, tr' = (tr, alter trigger(s, t, ot, md, opi, .. ., opk))

execute procedure (s,op) s S, op Op, (user(s), op, executer) E Re или [s] = 0 и owner ([s]) = = owner (op) G' = G(execute(s, op))

access(s, t, ar) s S, t T, ar {insertr, updater, deleter}, triggers(t, ar) = = (ot,i,..., ot,k), k > 0, Vi E {1, . . . , k}(ot,i E °t^ (user(s),t, ar) E Re или [s] = 0 и owner([s]) = = owner(t) G' = G(execute(s, ot,i), ..., execute(s, ot,k))

Необходимость во введении нового обозначения assocf (s) обусловлена тем, что в отличие от других моделей полагается, что в каждый момент времени множество функционально-ассоциированных с субъект-сессией s сущностей assocf (s) либо содержит ровно один выполняемый им в текущий момент времени триггер или процедуру, либо не содержит элементов. Последнее означает, что субъект-сессия выполняет SQL-код, который не относится ни к одной процедуре или триггеру. В последнем случае считается, что выполнение такого SQL-кода эквивалентно непосредственному применению субъект-сессией правил преобразования состояний из множества OPext. В дальнейшем будем полагать, что по определению выполняется равенство [s] = assocf (s).

SQL-код может либо относиться к одной из процедур или триггеров, либо не относиться ни к одной из них. Считается, что SQL-код содержит инструкции, выполнение которых непосредственно приводит к применению внешних правил из множества OPext. При этом предполагается, что SQL-код не может содержать инструкции, выполнение которых непосредственно приводит к применению внутренних правил из множества OPint. Выполнение внутренних правил инициируется опосредованно как составная часть преобразований системы, задаваемых внешними правилами. Например, выполнение SQL-кода триггеров осуществляется только при применении внешних правил, связанных со вставкой, удалением и обновлением записей таблиц.

В рамках модели предполагается, что триггеры и процедуры не содержат динамически генерируемого SQL-кода и условий, а их выполнение приводит к применению фиксированной последовательности правил, задаваемой соответствующим значением функции operations.

В СУБД MS SQL Server существует специальный режим проверки прав доступа при наличии «цепочки владения» (ownership chaining). При выполнении DML-инструкций (Data Manipulation Language) SQL-кода процедуры не выполняется проверка прав доступа при обращении к сущностям, владелец которых совпадает с владельцем выполняемой процедуры. Аналогичные проверки не производятся и в отношении DML-инструкций SQL-кода триггеров. Модель учитывает данную особенность функционирования СУБД при задании условий применения внешних правил преобразования состояний системы.

Определение 6. Обозначим через Ot* множество всех конечных последовательностей триггеров. Определим triggers: T х {insertr ,updater, deleter} s Ot* — функцию, задающую для каждой таблицы связанную с ней последовательность триггеров и удовлетворяющую следующим условиям.

Условие 1. Для каждой таблицы t E T и каждого права доступа ar E {insertr, updater, deleter} выполняется triggers(t,ar) С H(t).

Условие 2. Для каждого триггера ot E Ot существует единственная таблица t E T и единственное право доступа ar E {insertr,updater, deleter}, такое, что ot E triggers(t,ar).

Если существуют таблица t E T, право доступа ar E {insertr ,updater, deleter} и триггер ot E triggers(t, ar), то будем говорить, что триггер ot имеет тип ar и связан с таблицей t.

Каждый триггер имеет тип, задаваемый функцией triggers и соответствующий определённому виду доступа. Реализация субъект-сессией права доступа вида ar E {insertr, updater, deleter} к таблице t E T с применением правила access(s,t,ar) (см. табл. 2) автоматически инициирует выполнение ею SQL-кода всех триггеров из последовательности triggers(t, ar).

Введём следующие обозначения:

— G = {Eh, H, UA, S, Rd, Grd, user, user_stack, assocf, owner, cmode, execute_as,

triggers, operations, tr) — состояние системы;

— T,{G*, OP) —система, где G* —множество всех возможных состояний;

— T,{G*, OP, Go) — система T,{G*, OP) с начальным состоянием G0.

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

В дальнейшем будем использовать следующее предположение.

Предположение 4. В начальном состоянии системы T.{G*, OP, G0) отсутствуют субъект-сессии, то есть So = 0, и последовательность tro не содержит элементов.

2. Правила преобразования состояний

Будем использовать запись вида G'{I[,...,I'k} ~ G для обозначения того, что все элементы состояния G/ равны соответствующим элементам состояния G, за исключением элементов II,... , I'k состояния G/. Будем также использовать запись вида f/{x 1, ...,xk } f для обозначения того, что значения функции f/{x) равны значениям

функции f{x) для всех аргументов x, за исключением x]_,... ,xk. Кроме того, будем использовать запись вида f/{x 1 M yi,...,xk M yk} ~ f для обозначения того, что значения функции f /{x) равны значениям функции f {x) для всех аргументов x, кроме x -]_, ... ,xk, и при этом f/(x 1) = y 1, ..., f/{xk) = yk. Очевидно, что если выполняется G/{I/,..., I'k} ~ G, то также верно и G{Ib ..., Ik} ~ G/.

Используем обозначение: G -op G/ — переход системы Tj{G*,OP) из состояния G в состояние G/ с применением правила преобразования состояний op OP, при этом если условия применения правила op не выполняются, то по определению справедливо равенство G/ = G.

Запись вида G/ = G(opi,... , opk) означает, что состояние G/ есть результат последовательного применения правил преобразования состояний op 1,... , opk, начиная с состояния G, то есть существуют состояния G]_,... ,Gk, такие, что G -opi Gi -op2 ... -opk Gk и G/ = Gk.

В модели определены приведённые в табл. 1 и 2 правила преобразования состояний из множества OP, в которых учтены особенности управления доступом СУБД MS SQL Server 2012.

Замечание 4. Будем считать, что все правила из табл. 1 и 2, за исключением правила create_session(s, u), получают в качестве первого параметра субъект-сессию, инициировавшую их выполнение.

Будем использовать обозначение op(s) в случае, если применение правила инициировано субъект-сессией s. Будем считать, что применение правила create_session(s,u) также инициировано субъект-сессией s.

Определение Т. Будем говорить, что применение правила op OP инициировано учётной записью пользователя u Є U, если либо op = create_session(s,u), либо op имеет в качестве первого параметра субъект-сессию s, такую, что u = user(s).

Поясним приведённые в табл. 1 условия и результаты применения внутренних правил преобразования системы.

В отличие от внешних, внутренние правила применяются субъект-сессиями опосредованно в ходе выполнения SQL-кода как составная часть преобразований системы, задаваемых внешними (см. описание правил execute procedure, access, switch в табл. 2) или другими внутренними правилами (см. описание правила execute).

В результате применения внутреннего правила do_switch(s,o,u) в качестве учётной записи, от имени которой функционирует субъект-сессия s, устанавливается u, а o становится функционально-ассоциированной с s сущностью. Запись вида (tr, op), использованная при определении нового значения tr', означает, что в возможно пустую последовательность tr добавляются данные о применяемом правиле op.

Внутреннее правило execute(s, o) задаёт состояние системы после выполнения SQL-кода, содержащегося в процедуре или триггере o E Op U Ot субъект-сессией s E S. Перед выполнением SQL-кода сущности o производится изменение учётной записи пользователя, от имени которой субъект-сессия s будет последовательно применять внешние правила op1,... , opk. Учётная запись пользователя, от имени которой функционирует субъект-сессия s, устанавливается в соответствии с режимом выполнения кода процедуры или триггера o, задаваемых значением функции execute_as(o). Кроме того, в результате применения правила do_switch перед выполнением SQL-кода сущности o в качестве функционально-ассоциированной с субъект-сессией s сущностью устанавливается сущность o. После завершения описанных подготовительных действий производится выполнение SQL-кода сущности o, что приводит к реализации преобразований состояний системы, задаваемых последовательностью правил operations(o) = (opi,...,opk). После выполнения кода с использованием правила do_switch производится восстановление исходной функционально-ассоциированной сущности с субъект-сессией s, а также учётной записи пользователя, от имени которой она выполнялась до применения внутреннего правила execute(s, o). После завершения описанных действий производится восстановление исходной последовательности учётных записей, от имени которых выполнялась субъект-сессия s, до применения правила execute(s, o).

В табл. 2 приведены внешние правила преобразования состояний из множества OPext, которые могут быть непосредственно применены субъект-сессиями. Поясним условия и результаты применения внешних правил преобразования состояний.

В результате применения правила create_session(s,u) создаётся новая субъект-сессия s, которая в дальнейшем может выполнять действия от имени учётной записи пользователя u E U. Заметим, что после создания субъект-сессии множество функционально-ассоциированных с ней сущностей пусто. Отметим, что изначально в последовательность учётных записей, от имени которых выполнялась субъект-сессия, заносится учётная запись пользователя u, инициировавшего создание субъект-сессии s. В реальных СУБД при подключении к базе данных пользователь должен указать информацию, аутентифицирующую его учётную запись.

Определение 8. Пусть G h^ G — переход системы Tj(G*,OP) из состояния G в состояние G'. Назовём переход G hop G' инициированным извне, если op E OPext и либо op = create_session(s, u), либо правило op получает в качестве первого параметра субъект-сессию s, такую, что [s] = 0. Если переход G hop G' инициирован извне, то будем называть правило op инициированным извне, при этом если user(s) = u, то будем использовать обозначение op[u].

В дальнейшем будем считать, что выполняется следующее предположение.

Предположение 5. Применение правила create_session(s,u) может быть инициировано только извне.

В результате применения правила switch(s, u) в качестве учётной записи, от имени которой функционирует субъект-сессия s, устанавливается u. Необходимым условием применения данного правила является наличие у учётной записи, от имени кото-

рой функционирует субъект-сессия s, права доступа impersonater к учётной записи пользователя u. Запись вида (user_stack(s),u), использованная при определении нового значения user_stack/(s), означает, что в возможно пустую последовательность user_stack(s) добавляется учётная запись пользователя u. Отметим, что в результате применения правила switch(s,u) функционально ассоциированная с s сущность не изменяется. Заметим, что правилу switch соответствует SQL-оператор EXECUTE AS, используемый в реальных СУБД для выполнения действий от имени учётной записи заданного пользователя.

Правило revert(s) предназначено для восстановления учётной записи, от имени которой функционировала субъект-сессия s до момента предыдущего применения ею правила switch. Заметим, что восстановление организовано по принципу LIFO (Last In — First Out). Единственное отличие состоит в том, что учётная запись пользователя, от имени которого была создана субъект-сессия s, никогда не удаляется из последовательности user_stack(s). В СУБД для восстановления контекста выполнения до применения оператора EXECUTE AS используется оператор REVERT.

Замечание 5. Из способа задания внешних правил в табл. 2 видно, что при применении правил учитываются права учётной записи пользователя, от имени которой в текущем состоянии выполняется субъект-сессия s, а не права учётной записи пользователя, инициировавшего создание субъект-сессии s. Следовательно, наличие права impersonate,,, к учётной записи u позволяет с использованием switch инициировать применение любого внешнего правила преобразования состояний системы с правами учётной записи пользователя u. Это означает, что наличие права impersonater к учётной записи u равносильно обладанию информации, аутентифицирующей учётную запись пользователя u. Кроме того, можно считать, что наличие права impersonater к учётной записи u равносильно функционированию в кооперации с субъект-сессией, создание которой было инициировано ею.

В результате применения правила grant_right(s,p, e, ar,with_grant) принципалу p предоставляется право доступа аг к сущности e. Необходимым условием является наличие у учётной записи пользователя, от имени которой выполняется субъект-сессия s, права давать право доступа аг к сущности e, то есть user(s) Є Gr(e, ar). Если параметр with_grant равен yes, то принципалу p даётся также право предоставлять право аг к сущности e. Правило grant_right соответствует SQL-оператору GRANT, позволяющему предоставлять права пользователям и ролям к сущностям базы данных.

Назначение правила add_member(s, r,u) состоит в предоставлении учётной записи пользователя u авторизации на роль r, а также на все роли, которые «иерархически подчинены» роли r. Необходимым условием применения данного правила является наличие у учётной записи, от имени которой выполняется субъект-сессия s, права доступа alterr к роли r.

Замечание б. Исходя из способа задания внутренних и внешних правил преобразования состояний, можно сделать вывод, что единственным способом изменения множества действующих прав доступа учётных записей пользователей на предоставление прав доступа к сущностям Gre является применение правила grant_right. В то же время изменение множества действующих прав доступа Re возможно с применением либо правила grant_right, либо add_member.

Правило create_container(s, cp, c, mode) позволяет субъект-сессии s создать новый контейнер с, включив его в существующий контейнер cp. Необходимым условием применения данного правила является наличие у учётной записи пользователя user(s)

права доступа alter, к контейнеру cp. Владельцем вновь созданного контейнера с назначается в зависимости от режима установки владельца вновь создаваемых дочерних сущностей контейнера cp либо учётная запись пользователя, инициировавшая применение правила (режим cmode(cp) = creator), либо принципал владельца контейнера cp (режим cmode(cp) = parent). Режим установки владельца создаваемого контейнера устанавливается равным параметру mode.

В СУБД MS SQL Server способ установки владельца экземпляра СУБД и экземпляров баз данных соответствует режиму creator, то есть владельцем становится пользователь, инициировавший их создание. С другой стороны, у схем способ установки соответствует режиму parent. Таким образом, владельцем создаваемых таблиц и триггеров становится владелец схемы, в которой выполняется операция создания.

В результате применения правила create_procedure(s, c, op, md, op^ ... , opk) в контейнере c, не являющемся таблицей, создаётся новая процедура op, содержащая SQL-код, выполнение которого приводит к реализации правил преобразования состояний op-\_,... , opk, при этом владельцем вновь созданной процедуры op становится принципал владельца контейнера с, а режим выполнения op устанавливается равным md. Необходимым условием выполнения данного правила является наличие у учётной записи пользователя user(s) права доступа alter, к контейнеру с. Для назначения режима выполнения процедуры от имени заданной учётной записи пользователя требуется наличие к ней у user(s) права доступа impersonate,.

В результате применения правила alter_procedure(s, op, md, op^ ... , opk) производится изменение режима выполнения существующей процедуры op, а также замена её SQL-кода на новый, выполнение которого приводит к реализации правил преобразования состояний op 1,..., opk. Необходимым условием выполнения данного правила является наличие у учётной записи пользователя user(s) права доступа alter, к процедуре op. Для назначения режима выполнения процедуры от имени учётной записи пользователя требуется наличие к ней права доступа impersonate,. Отметим, что, в отличие от правила create_procedure, владелец процедуры op не изменяется.

В результате применения правила create_trigger(s, t, ot, а, ,md, op ^..., opk) в таблице t создаётся новый триггер ot, содержащий SQL-код, выполнение которого приводит к реализации правил преобразования состояний op^... , opk, при этом владельцем вновь созданного триггера ot становится принципал владельца таблицы t, а режим выполнения ot задаётся равным md. Созданный триггер активизируется только при реализации к таблице t права доступа а, с использованием правила access(s,t, а,). Необходимым условием выполнения правила create_trigger является наличие у учётной записи пользователя user(s) права доступа alter, к таблице t. Для назначения режима выполнения триггера от имени заданной учётной записи пользователя требуется наличие к ней у user(s) права доступа impersonate,.

В результате применения правила alter_trigger(s, t, ot, md, op^ ..., opk) в таблице t производится модификация режима выполнения существующего триггера ot, а также замена его SQL-кода на новый, выполнение которого приводит к реализации правил преобразования состояний op 1,... , opk. Необходимым условием выполнения данного правила является наличие у учётной записи пользователя user(s) права доступа alter, к таблице t. Для назначения режима выполнения триггера от имени учётной записи пользователя требуется наличие к ней у user(s) права доступа impersonate,. Отметим, что, в отличие от правила create_trigger, не выполняется изменение учётной записи владельца триггера ot, а также вида права доступа, при реализации которого активизируется триггер ot.

Замечание Т. В результате применения правил create_container, create_proce-dure и create_trigger не выполняется добавление в множества Rd и Grd прав доступа учётной записи владельца к вновь созданной сущности. Это связано с тем, что при задании учётной записи владельца в соответствии с правилами задания в множества Re и Gre включаются права доступа всех её иерархических владельцев.

Будем использовать обозначение op -< expression в случае, если операция op имеет вид expression. Например, если операция op имеет вид create_session(s,...), то будем использовать обозначение op -< create_session(s,...). Будем использовать обозначение op 7^ expression в случае, если операция op не имеет вид expression.

Предположение б. Будем считать, что выполнение SQL-кода триггеров и процедур не приводит к применению правил create_container, create_procedure, alter_procedure, create_trigger или alter_trigger, то есть перечисленные правила могут быть применены только извне. Следовательно, при применении правила op -< create_procedure{..., opь ..., opk), либо op -< alter_procedure{..., op]_,..., opk),

либо op -< create_trigger{..., op]_,..., opk), либо op -< alter_trigger{..., op]_,..., opk)

для каждого i = 1,...,k правило opi ^ create_procedure, opi ^ alter_procedure, opi 7^ create_trigger и opi, ^ alter_trigger.

Замечание S. Заметим, что если o Є Op U Ot, operations{o) = (op]_,... , opk), где k ^ 0, то opi ^ create_session для каждого i = І,... ,k. Предположим противное: существует i Є {І,..., k}, такое, что opi -< create_session. В соответствии со способом задания внутреннего правила execute(s, o) на время применения правил сущности o, она становится функционально-ассоциированной с субъект-сессией s. Это противоречит предположению о том, что применение правила opi -< create_session может быть инициировано только извне. Следовательно, правила, связанные с процедурами и триггерами, не могут включать правила вида create_session. Кроме того, при применении правил вида create_procedure{..., opь ..., opk), alter_procedure{..., op]_,..., opk), create _trigger {... ,op l,...,opk) и alter _trigger{... ,op l,...,opk) для каждого i = = І,... ,k выполняется opi, ^ create_session.

Допустим, что o Є Op U Ot, operations{o) = (opb ... , opk), где k ^ 0. Будем использовать обозначение op Є operations(o) в случае, если существует i Є {І,..., k}, такое, что op = opi,.

Замечание 9. Пусть o Є Op U Ot и op Є operations (o). В соответствии с предположением б и замечанием S, правило op не может иметь вид create_container, create_procedure, alter_procedure, create_trigger, alter_trigger и create_session. Учитывая это, а также то, что op Є OPext, по определению функции operations получаем, что либо op -< grant_right, либо op -< add_member, либо op -< execute_procedure, либо op -< access.

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

Предположение Т. Считается, что в начальном состоянии Tj{G*,OP,G0) для каждого o Є Op0 U Ot0 и каждого op Є operations0(o) выполняется op ^ grant_right и op add_member.

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

Правило execute_procedure(s, op) позволяет субъект-сессии s выполнить SQL-код процедуры op. Необходимым условием применения данного правила является либо наличие у учётной записи пользователя, от имени которой выполняется s, права доступа execute, к процедуре op, либо совпадение принципала владельца процедуры op и принципала владельца процедуры или триггера, в рамках выполнения SQL-кода которых предпринята попытка применения правила execute procedure(s,op). Последний случай соответствует специальному режиму проверки прав доступа при наличии «цепочки владения». Отметим, что при выполнении SQL-кода процедуры может осуществляться активация других процедур и триггеров.

Применение правила access(s,t, а,) приводит к активации триггеров типа а, таблицы t субъект-сессией s. Необходимым условием применения данного правила является либо наличие у учётной записи пользователя, от имени которой выполняется s, права доступа а, к таблице t, либо совпадение принципала владельца таблицы t и принципала владельца процедуры или триггера, в рамках выполнения SQL-кода которых предпринята попытка применения правила access(s,t, а,). Отметим, что при выполнении SQL-кода триггера может осуществляться активация других процедур и триггеров.

Замечание 10. Заметим, что в реальных СУБД активация триггеров таблицы выполняется только при внесении в неё изменений.

Замечание 11. Будем считать, что при активации правил преобразования состояний, связанных с процедурами и триггерами, не возникает циклов, являющихся результатом повторного применения правил ранее активированных сущностей.

Замечание 12. В соответствии со способом задания применение внешних и внутренних правил не приводит к удалению элементов из множеств, являющихся элементами состояния системы T.(G*,OP). Следовательно, все правила системы T,{G*,OP) являются монотонными.

Учитывая монотонность правил системы, а также то, что в условиях применения правил grant_right, add_member alter_procedure, alter_trigger, execute_procedure, access нет проверок на отсутствие элементов в состоянии системы T,{G*, OP), отметим, что верно следующее замечание.

Замечание 13. Пусть G — состояние системы T.{G*, OP) и opт_,... , opk Є OP, где k ^ І, G/ = G(op]_,... , opk), op является одним из перечисленных выше правил. Пусть в состоянии G выполнены условия применения правила op субъект-сессией, функционирующей от имени учётной записи пользователя u U. Тогда в состоянии G/ также будут выполнены условия применения правила op субъект-сессией, функционирующей от имени учётной записи пользователя u.

З. Функция vestige

В соответствии со способом задания правил преобразования состояний в результате применения правил execute procedure и access может быть инициировано выполнение правил триггеров и процедур. Введём функцию vestige(G, op]_,... , opk), значением которой является последовательность всех правил преобразований состояний системы, применение которых является результатом последовательного применения правил op]_,... , opk в состоянии G.

Определение 9. Пусть заданы состояния системы G,G]_,..., Gk, где k ^ І, и правила преобразования состояний op^... , opk, такие, что G -opi G1 -op2 ... -opk Gk и для каждого i = І,... ,k переход Gi-1 -opi G-i инициирован извне и trk = (tr, op ^_,... , opm),

где m ^ 0. Обозначим через vestige(G, op 1,..., opk) последовательность правил преобразования состояний (op 1,... , opm).

Замечание 14. Заметим, что последовательность правил vestige(G, op 1,... , opk) однозначно определяется состоянием системы G и последовательностью инициированных извне правил op 1,... , opk, поэтому в дальнейшем vestige будет рассматриваться как функция G* х OP*xt ^ OP*.

Замечание 15. Отметим, что в соответствии со способом задания перехода системы из состояния в состояние последовательность правил преобразования состояний vestige(G, op 1,... , opk) не включает правила, условия применения которых не выполняются.

Пусть заданы состояния системы G0,... , Gk, где к ^ 1, и правила преобразования состояний op 1,... , opk, такие, что G0 hopi G1 hop2 ... hopk Gk и для каждого i = 1,... ,к переход Gi-1 hopi Gi инициирован извне и vestige(G0,op 1, ...,opk) = (op 1,... ,opm). Пусть состояния G0, G1,..., Gm таковы, что G0 = G0 и G0 hop1 G1 hop2 ... hopm Gm. Функция vestige обладает следующими свойствами.

Свойство 1. Gk = Gm.

Свойство 2. vestige(G0,opl,... ,opk) = (vestige(G0,opl,... ,opk-1 ),vestige(Gk-1, opk)) = (vestige(G0,opl),vestige(Gl,op2),... ,vestige(Gk-1, opk)) (для удобства будем считать, что запись ((op 1,... , opm), (opm+1,... , opn)) эквивалентна последовательности

(Op i,...,Opm,6pm+1 ,...,Opn)).

Свойство 3. Если в состоянии G0 не выполнены условия применения правила op E OPext, то vestige(G0,op) = ().

Свойство 4. Если выполнены условия применения правила op E OPext в состоянии G0 и op ^ access и op ^ execute_procedure, то vestige(G,op) = (op).

Свойство 5. Для каждого i = 1,...,m либо opi -< switch, либо opi -< revert, либо (У[){ < create_session, либо opi -< create_procedure, либо opi -< alter_procedure, либо (У[){ < create_trigger, либо opi -< alter_trigger, либо opi -< grant_right, либо opi < add_member.

Свойство 6. Для каждого i = 1,...,m выполняется opi ^ access и opi ^ exe-cute_procedure.

Выполнение указанных свойств следует из определения функции vestige и способа задания внутренних и внешних правил преобразования состояний в табл. 1 и 2.

4. Анализ условий выполнения SQL-кода от имени заданной

учётной записи

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

Введём определение возможности применения правила от имени заданной учётной записи.

Определение 10. Пусть G — состояние системы T.(G*, OP), u,u' E U, op E OPext, s E S. Пусть в состоянии G выполнены условия применения внешнего правила op субъект-сессией, функционирующей от имени учётной записи пользователя u'. Определим предикат can_execute_as(u,u',op,G), истинный тогда и только тогда, когда существуют инициированные извне правила opl (s),... ,opk (s) E OPext, где к > 0, такие, что op\_ (s) = create _session(s,u), vestige(G,opl (s),...,opk (s)) = (opl,... ,opm) и существует i E {2,... , m}, что opi = op и useri-1 (s) = u'.

Для теоретического анализа условий выполнения SQL-кода от имени заданной учётной записи введём следующее определение.

Определение 11. Пусть G — состояние системы T.(G*, OP), u, u' E U. Определим предикат can_act_as(u, u', G), истинный тогда и только тогда, когда истинен предикат can_execute_as(u,u',op,G) для любого внешнего правила op E OPext, для которого в состоянии G выполнены условия его применения субъект-сессией, функционирующей от имени учётной записи пользователя u'.

В соответствии с замечанием 5 обладание учётной записью пользователя u правом доступа impersonater к учётной записи пользователя u' позволяет применить правило switch и в дальнейшем выполнить любое внешнее правило преобразования состояния системы от её имени. Для анализа возможности получения права impersonate,,, введём следующее определение.

Определение 12. Пусть G — состояние системы Tj(G*,OP), u, u' E U, s / S. Определим предикат can_become(u, u',G), истинный тогда и только тогда, когда существуют инициированные извне правила opl(s),..., opk(s) E OPext, где к > 0, такие, что opl(s) = create_session(s, u), Gk = G(opl(s),..., opk(s)) и (u, u', impersonater) E Rek.

В случае истинности предиката can_become(u,u',G) субъект-сессия s, созданная пользователем u, без кооперации с другими субъект-сессиями может получить право доступа impersonater к учётной записи пользователя u'.

4.1. Эквивалентность возможности выполнения п р о и з в о л ь н о г о S Q L - к о д а о т и м е н и у ч ё т н о й з а п и с и п о л ь з о в а т е л я и в о з м о ж н о с т и п о л у ч е н и я к н е й п р а в а о л и ц е т в о р е н и я

Справедливо следующее утверждение о связи между возможностью выполнения произвольного SQL-кода от имени заданной учётной записи и возможностью получения к ней права доступа impersonater.

Утверждение 2. Пусть G — состояние системы T.(G*, OP), u,u' E U. Тогда предикат can_act_as(u,u',G) истинен тогда и только тогда, когда истинен предикат can_become(u, u',G).

Доказательство. Пусть s / S.

Пусть истинен предикат can_act_as(u,u', G). В соответствии со способом задания множества Gre владелец сущности может предоставить к ней любые права доступа. Отсюда, учитывая, что owner(u') = u', следует, что u' E Gr(u', impersonater). Это означает, что в состоянии G выполнены условия применения op = grant_right(s, u, u', impersonater, yes) в случае, если субъект-сессия s функционирует от имени учётной записи пользователя u'. В этом случае, по определению 11, истинен предикат can_execute_as(u,u',op,G). Значит, существуют инициированные извне прави-

ла op 1 (s),...,opk(s) Є OPext, где k > О, такие, что op\_(s) = create _session(s,u), vestige(G, opl(s),..., opk(s)) = (op^^,..., op^), и существует i Є {2,..., m}, что = op и useri-1 (s) = u/. В соответствии с замечанием 15 последовательность vestige(G, op 1 (s) ...,opk (s)) не включает правила, условия применения которых не выполняются. Значит, выполнены условия применения правила op = grant_right(s/,u,u/, impersonate,, yes), откуда (u,u/, impersonate,) Є Rei. Из монотонности правил преобразования состояний системы следует, что (u,u/, impersonate,) Є Rek, а значит, по определению истинен предикат can_become(u,u/,G).

Пусть истинен предикат can_become(u, u/, G). По определению 12 существуют инициированные извне правила opl(s),... ,opk(s) Є OPext, где k > О, такие, что op 1 (s) =

= create _session(s,u), Gk = G(op 1 (s),..., opk (s)) и (u,u/, impersonate,) Є Rek. Пусть для правила op Є OPext в состоянии G выполнены условия его применения субъект-сессией, функционирующей от имени учётной записи пользователя u/. Легко заметить, что в результате применения внешних правил преобразований значение функции user_stack не изменяется. Таким образом, user_stackk(s) = user_stack 1 (s) = (u), откуда userk(s) = u. Так как (u,u/, impersonate,) Є Rek, в состоянии Gk выполнены условия применения правил opk+1 (s) = switch(s,u/) и userk+1 (s) = u/.

Покажем, что в состоянии Gk+1 выполнены условия применения правила op.

Во всех внешних правилах, за исключением create_session, create_trigger, create_procedure и create_container, нет проверок на отсутствие элементов в состоянии системы. Отсюда, в силу монотонности правил преобразования состояний, в состоянии Gk+1 выполнены условия применения op, а следовательно, по определению истинен предикат can_execute_as(u, u/, op, G).

Согласно предположению 5, применение правила create_session не может быть инициировано ранее созданной субъект-сессией, а следовательно, в рамках определения 10 правило op не может иметь вид create_session.

Пусть op -< create_container(... ,c,...). Если с Є Ck+1, то в силу монотонности правил в состоянии Gk+1 выполнены условия применения правила op. Пусть с Є Ck+1. Тогда, согласно предположению б, существует i Є {І,...^}, такое, что opi(s) -< create_container(... ,c,...). Заменим в правилах преобразования состояний opi(s),... , opk+1 (s) все случаи использования контейнера с на С Є Ci-1. Очевидно, что в этом случае (u,u/, impersonate,) Є Rek+1 и c Є Ck+1, тогда в силу монотонности правил в состоянии Gk+1 выполнены условия применения правила op, а следовательно, истинен предикат can_execute_as(u, u/, op, G).

Проводя аналогичные рассуждения для случаев create_procedure и create_trigger, можно показать, что предикат can_execute_as(u,u/,op,G) также будет истинен.

Следовательно, предикат can_execute_as(u, u/, op, G) истинен для любого правила op Є OPext, для которого в состоянии G выполнены условия применения субъект-сессией, функционирующей от имени учётной записи пользователя u/, а значит, по определению истинен предикат can_act_as(u,u/, G). ■

Следовательно, для определения условий истинности предиката can_act_as(u, u/, G) необходимо и достаточно обосновать условия истинности предиката can_become(u, u/, G).

4.2. Достаточные условия выполнения SQL -кода от имени з а д а н н о й у ч ё т н о й з а п и с и п о л ь з о в а т е л я

Покажем, что если в начальном состоянии системы Go в результате применения извне правил субъект-сессией, созданной пользователем u, были выполнены правила

вида grant_right и add_member от имени учётной записи пользователя u', то предикат can_act_as(u, u', G0) истинен.

Утверждение 3. Пусть G0 — начальное состояние системы T.(G*,OP), s / S, opl(s),..., opk(s) E OPext, opl(s) = create_session(s, u), vestige(G0, opl(s),..., opk(s)) = = (opl,..., opm) и существует i E {2,..., m}, что opi -< grant_right или opi -< add_-member и useri-1(s) = u'. Тогда истинен предикат can_act_as(u,u', G0).

Доказательство. Возможны два случая: 1) [s^_ l = 0 и 2) [s^_ l = o, где

o E Opt-i U Oti-i. ^

Рассмотрим первый случай. Если [s^_ l = 0, то применение правила opi было инициировано извне субъект-сессией s. Следовательно, существует j E {1,...,k}, такое, что opj(s) = opi. Так как useri-1(s) = u', имеем userj-1(s) = u'. Положим opj(s) = = grant _right(s, u, u' ,impersonater, no). Так как (u' ,u' ,impersonater) E Rej-1, в состоянии Gj-1 выполнены условия применения правила opj (s) субъект-сессией, функционирующей от имени учётной записи пользователя u', откуда (u,u', impersonater) E E Rej. Тогда по определению истинен предикат can_become(u, u', G0) и, в соответствии с утверждением 2, истинен предикат can_act_as(u,u',G0).

Рассмотрим второй случай. Возможны следующие два варианта: 2.1) o E Op0 U Ot0 и 2.2) oEOp0 U Ot0.

Рассмотрим случай 2.1. В соответствии с предположением 7 в начальном состоянии T.(G*,OP,G0) для каждого o E Op0 U Ot0 и каждого op E operations0(o) выполняется op ^ grant _right и op ^ add_member. Следовательно, существует i' E {2,... ,i — 1}, такое, что либо opii -< alter_procedure, либо 6pif -< alter_trigger. Выберем значение i' максимальным. В соответствии с предположением 6 применение правил alter_procedure и alter_trigger возможно только извне. Следовательно, существует j E {1,... , к}, такое, что opj(s) = op^. Возможны два случая: o E Op0 и o E Ot0. В первом случае opj (s) = alter_procedure(opb ..., opi) и существует j' E {1,..., l}, такое, что opj, = opi. Заменим в правиле opj(s) в последовательности (opь... ,6pl) правило opj, на grant_right(s, u, u',impersonater, no). Из максимальности выбора i' следует, что в состоянии Gj-1 верно равенство operationsj-1(o) = (o'pl,... ,opji-1, grant_right(s,u, u', impersonater, no), opj,+1,..., opl), откуда < grant_right(s, u, u', impersonater, no)

и useri-1 (s) = u'. Так как (u',u',impersonater) E Rei-1, в состоянии Gi-1 выполнены условия применения правила и (u,u', impersonater) E Rei, а значит, в силу монотонности правил преобразования состояний, (u,u', impersonater) E Rek. Тогда по определению истинен предикат can_become(u,u', G0) и, по утверждению 2, истинен предикат can_act_as(u,u', G0). Случай o E Ot0 обосновывается аналогично.

Рассмотрим случай 2.2. В соответствии с предположением 6 применение правил create_procedure и create_trigger возможно только извне. Так как o / Op0 U Ot0, существует j E {1,...,к}, такое, что o / Opj-1 U Otj-1, o / Opj U Otj и либо opj (s) ^ create_procedure, либо opj (s) ^ create_trigger. Возможны следующие два случая: 1) operations i-1 (o) = operations j (o); 2) operations i-1 (o) = operations j (o). Если operationsi-1 (o) = operations j (o), то, проводя рассуждения, аналогичные случаю 2.1, можно показать, что истинен предикат can_act_as(u, u', G0). Рассмотрим второй случай: operations j (o) = (op l,..., opl), тогда существует j' E {1,... , l}, такое, что opj, = opi. Заменим в правиле opj(s) в последовательности (op]_,... ,6pl) правило opj,

на grant _right(s, u, u' ,impersonater, no). Так как operationsi-1 (o) = operations j (o), получим opi ^ grant_right(s, u, u', impersonater, no) и useri-1(s) = u'. В соответствии

со способом задания (u/,u/, impersonate,) Є Rei_ 1, и значит, в состоянии Gi-1 выполнены условия применения правила o>pi и (u,u/, impersonate,) Є Rei, откуда, в силу монотонности правил преобразования состояний, (u,u/, impersonate,) Є Rek. Тогда по определению истинен предикат can_become(u,u/, Go) и в соответствии с утверждением 2 истинен предикат can_act_as(u,u/,Go). ■

Б. Ролевые цепочки получения прав доступа

Пусть G — состояние системы Y.(G*, OP), p Є P, r Є R, e Є E, аr Є Rr. Будем использовать обозначение (p, r, e, аr) <G в случае, если (p, r, alterr) Є Re и (r, e, аr) Є Re.

Пусть u Є U, тогда будем использовать обозначение (u^^,) <1 G в случае, если существуют роли r -]_,... ,rk Є R, где k ^ І, такие, что (u, r -\_,r2, alterr) < G, для каждого

i = І,... ,k — 2 выполняется (rj,, ri+1, ri+2, alterr) < G и (rk-1 ,rk, e, аr) < G. В последнем случае будем использовать также обозначение (u,rk,e, а,) < G. В случае (u,e, а,) < G будем говорить, что учётная запись пользователя u обладает «ролевой цепочкой» получения права доступа аr к сущности e. Если (u^^e^,) < G, то будем говорить, что учётная запись пользователя u обладает «ролевой цепочкой» получения права доступа а, к сущности e через роль r.

Будем использовать обозначение (u, e, а,) М G в случае, если существуют роли r ]_,... ,rk Є R, где k ^ І, такие, что (u, r і,г2, alterr) < G, для каждого i = І,... ,k — 2 выполняется (ri,ri+1 ,ri+2, alter,) < G и (rk-1 ,rk, alter,) Є Re и rk Є Gr(e^r). Если (u, e, аr) М G, то будем говорить, что учётная запись пользователя u обладает «ролевой цепочкой» предоставления права доступа а, к сущности e. Очевидно, что если (u^^,) М G, то (u,e^r) < G.

В силу монотонности правил преобразования состояний справедливы следующие замечания.

Замечание 1б. Если G — состояние системы 'E(G*,OP), p Є P, r Є R, e Є E,

а., Є Rr, (p, r, e, а,) < G, op і,..., opk Є OPext, где k ^ І, Gk = G(op і,..., opk), то (p,r,e, а,) < Gk.

Замечание 1Т. Если G — состояние системы 'E(G*,OP), u Є U, e Є E, аr Є Rr, {u,e^r) < G, op і, ...,opk Є OPext, где k ^ І, Gk = G(op і,... ,opk), то {u,e^r) < Gk.

Замечание 18. Если G — состояние системы 'E(G*,OP), u Є U, e Є E, аr Є Rr, {u,e^r) М G, op і, ...,opk Є OPext, где k ^ І, Gk = G(op і,... ,opk), то {u,e^r) М Gk.

Утверждение 4. Если G — состояние системы Tj(G*,OP), u Є U, r Є R, e Є E, аr Є Rr, (u, r, e, аr) < G, s Є S, user(s) = u, Gі = G(add_member(s, r, u)), то (u, e, аr) Є Re1 .

Доказательство. Следует из того, что в состоянии G выполнены условия применения правила add_member (s, r, u) от имени учётной записи u и при этом (r, e, аr) Є Re. ■

Докажем, что если в результате применения извне правил субъект-сессией, созданной пользователем u, у принципала p появится право доступа alterr к роли r, то в начальном состоянии Go существует учётная запись пользователя u/, обладающая ролевой цепочкой получения права доступа а, к сущности e через роль r, и u имеет возможность выполнения от её имени произвольного SQL-кода.

Утверждение Б. Пусть Go —начальное состояние системы 'E(G*,OP), u Є U, p Є P, r Є R, e Є Eo, аr Є Rr, (r^e^,) Є Re0, s Є So, op^(s),...,opk(s) Є OPext, где op\_(s) = create_session(s,u), Gk = Go(opі(s),...,opk(s)), (p,r,alter,) Є Re0 и

(p,r, alterr) E Rek. Тогда существует u' E U, такое, что предикат can_act_as(u,u',G0) истинен и (u',r,e,ar) < G0.

Доказательство. Пусть vestige(G0, opl(s),..., opk(s)) = (opl,..., oipm).

Так как (p, r, alterr) / Re0 и (p, r, alterr) E Rek, существует i E {1,..., m}, такое, что (p,r, alterr) / Rei_ 1 и (p,r, alterr) E Rei. Заметим, что в соответствии с замечанием 15 в состоянии Gi-1 выполнены условия применения правила opi. Пусть l — количество правил вида grant_right и add_member в последовательности (opl,... ,opi). Доказательство проведём индукцией по l.

Пусть l = 1. Обозначим useri-1 (s) как u'. В соответствии с утверждением 3 истинен предикат can_act_as(u,u', G0). Так как l = 1, opi — единственное правило вида grant_right и add_member, откуда Rei-1 = Re0.

Если opi -< grant _right, то -< grant _right(s,... ,e', alter r,...), где ё E {r,cr} и u' E Gri-1(e',alterr), а значит, (u',e', alterr) E Rei_1. Заметим, что r ^ e', откуда (u', r, alterr) E yei-1. Ранее было показано, что Rei_1 = Re0, а значит, (u', r, alterr) E Re0. По условию (r,e,ar) E Re0, следовательно, (u',r,e,ar) <1 Go.

Пусть op.i -< add_member, тогда p E U, op.i = add_member(s,r',p), где r' E R, (u', r', alter r) E Rei-1 и (r' ,r, alter r) E Rei-1. Так как Rei-1 = Re0, имеем (u',r',alterr) E E Re0 и (r' ,r, alter r) E Re0. По условию (r,e,ar) E Re0, а значит, (u',r,e,ar) < G0.

Пусть условия утверждения выполняются для всех l < N, где N > 1. Покажем, что оно верно и при l = N. Обозначим use'ri-1(s) как u''. В соответствии с утверждением 3 истинен предикат can_act_as(u,u'', G0).

Если op.i -< grant _right, то -< grant _right(s,... ,e', alter r,...), где e E {r,cr}

и u" E Gri-1(e',alterr), а значит, (u'',e', alterr) E Rei-1. Заметим, что r ^ e', откуда (u'',r,alterr) E yei-1. Возможны случаи: 1) (u'',r,alterr) E Re0; 2) (u'',r,alterr) / Re0.

Случай 1. Положим u' = u''. По условию (r, e, ar) E Re0, откуда (u', r, e, ar) < G0.

Случай 2. Так как (u'' ,r, alter r) / Re0 и (u'',e', alter r) E Rei_1, существует j E {1,... ,i — 1}, что (u'', r, alterr) / yej-1 и (u'', r, alterr) E Rej. Так как opi ^ grant_-right и j < i, для u'', r и e выполнено предположение индукции с количеством правил вида grant_right и add_member в последовательности (op-у,..., opj), меньшим чем N. Тогда по предположению индукции существует u' U, такое, что истинен предикат

can_act_as(u,u',G0) и (u',r,e,ar) < G0.

Пусть opi ^ add_member. Тогда p E U, opi = add_member(s,r',p), где r' E R, (u'' ,r', alter r) E Rei_1 и (r' ,r, alter r) E Rei_1. Возможны случаи: 1) (u'' ,r', alter r) E Re0 и (r' ,r, alter r) E Re0; 2) (u'' ,r', alter r) / Re0 и (r' ,r, alter r) E Re0; 3) (r' ,r, alter r) / Re0.

Случай 1. Положим u' = u''. По условию (r,e,ar) E Re0, следовательно, (u', r, e, ar) < G0.

Случай 2. Так как (u'',r', alterr) / Re0 и (u'',r', alterr) E Rei-1, существует j E {1,...,i — 1}, такое, что (u'',r',alterr) / yej-1 и (u'',r',alterr) E Rej. Так как opi ^ add_member и (r' ,r, alter r) E Re0, для u'', r' и r выполнено предположение индукции с количеством правил вида grant_right и add_member в последовательности (opу, ... , opj), меньшим чем N. Тогда по предположению индукции существует u' E U, такое, что истинен предикат can_act_as(u,u', G0) и (u',r',r, alterr) < G0. По условию (r,e,ar) E Re0, откуда (u',r,e,ar) < G0.

Случай 3. Так как (r' ,r, alter r) / Re0 и (r' ,r,alterr) E Rei-1, существует j E {1,...,i — 1}, такое, что (r' ,r, alter r) / Rej-1 и (r' ,r, alter r) E Rej. Так как opi add_member, для r', r и e выполнено предположение индукции с количеством

правил вида grant_right и add_member в последовательности (opь ..., opj), меньшим чем N. Тогда по предположению индукции существует u/ U, такое, что истинен

предикат can_act_as(u,u',Go) и (u1 ,r,e, а,) < Go. ■

б. Необходимые и достаточные условия предоставления прав доступа

Введём предикат can_grant_right{u,e,аr,G), истинный тогда, когда в результате применения правил субъект-сессией, созданной пользователем u, учётная запись пользователя u получает возможность предоставлять право доступа а, к сущности e.

Определение 13. Пусть G — состояние системы Tj(G*,OP), u Є U, e Є E, а, Є Є Rr, s Є S. Определим предикат can_grant_right(u, e, аr ,G), истинный тогда и только тогда, когда существуют инициированные извне правила opl (s),... , opk (s) Є OPext, где k > О, такие, что op\_(s) = create_session(s,u), Gk = G(opl(s),...,opk(s)) и u Є Grk(e, аr).

Покажем, что если в результате применения извне правил субъект-сессией, созданной пользователем u, у принципала p появляется право на предоставление права доступа а, к сущности e, то в начальном состоянии Go существует учётная запись пользователя u', имеющая право на предоставление этого права к e, и u имеет возможность выполнения от её имени произвольного SQL-кода.

Утверждение б. Пусть Go —начальное состояние системы 'E(G*,OP), u Є U, e Є Eo, аr Є Rr, s Є So, opl(s),...,opk(s) Є OPext, где opl(s) = create _session(s,u),

Gk = Go(opl(s),... ,opk(s)), p Є P, p Є G^^^.) и p Є Grk(e^r). Тогда существует u' Є U, такое, что истинен предикат can_act_as(u,u', Go) и либо u' Є Gro^^,), либо (u', e, аr) М Go.

Доказательство. Пусть vestige(Go, opl(s),..., opk(s)) = (opb ..., 0ipm).

Так как p Є G^^^.) и p Є Grk(e^r), существует i Є {І,... ,m}, такое, что p Є Gri-1(e^r) и p Є Gr^e^,). Пусть l — количество правил вида grant_right и add_member в последовательности (opь... , op) Доказательство проведём индукцией по l.

Пусть l = І. Обозначим useri-1(s) как u'. В соответствии с утверждением З истинен предикат can_act_as(u,u', Go). Заметим, что в соответствии с замечанием 15 в состоянии G—l выполнены условия применения правила 0pi. Так как l = І, opi — единственное правило вида grant_right и add_member, откуда Rei-1 = Re0 и Grei-1 = Gre0.

Пусть 0>pi -< grant_right, тогда 0>pi = grant_right(s^^^,, yes) и u' Є Gri-;l(e^r). Так как Grei_ 1 = Gre0, получаем u' Є Gro^{e^,,.), а значит, выполнено условие утверждения.

Пусть 0[){ < add_member, тогда p Є U, opi = add_member(s,r,p), где r Є R, (u', r, alterr) Є Rei-1 и r Є Gri-1(e, аr). Так как Rei_1 = Re0 и Grei-1 = Gre0, имеем (u', r, alterr) Є Re0 и r Є Gr0{e,аr). Следовательно, (u^e^,) М Go, а значит, выполнено условие утверждения.

Пусть условия утверждения выполняются для всех l < N, где N > І. Покажем, что оно верно и при l = N. Обозначим use'ri-1(s) как u''. В соответствии с утверждением З истинен предикат can_act_as(u,u//, Go).

Пусть < grant_right, тогда < grant _right(s^^^,, yes) и u" Є Gri-1 (e,а,). Возможны два случая: 1) u" Є Gr^e^,); 2) u" Є Gr0{e,аr).

Случай 1. Если u'' Є Gr^e^,), то, положив u' = u'', видим, что выполнены условия утверждения.

Случай 2. Так как u" / Gr0(e,ar) и u" E Gri-у(e,ar), существует j E {1,

... ,i — 1}, такое, что u" / Grj-у(e,ar) и u" E Grj(e,ar). Так как -< grant_right

и j < i, в последовательности (opl,...,opj) количество правил вида grant_right и add_member меньше N. Значит, по предположению индукции существует u' U, такое, что истинен предикат can_act_as(u,u', G0) и либо u' E Gr0(e,ar), либо (u', e, ar) M G0.

Пусть op.i -< add_member, тогда p E U и -< add_member(s,r,p), где r E R, (u'' ,r, alter r) E Rei-1 и r E Gri-у (e,ar). Возможны три случая: 1) (u'' ,r,alterr) E Re0 и r E Gr0(e,ar); 2) r / Gr0(e,ar); 3) (u'',r,alterr) / Re0 и r E Gr0(e,ar).

Случай 1. Легко заметить, что (u'',e,ar) M G0. Положив u' = u'', видим, что выполнены условия утверждения.

Случай 2. Так как r / Gr0(e,ar) и r E Gri-у(e,ar), существует j E {1,

... ,i — 1}, что r E Grj-у (e, ar) и r E Grj (e, ar). Так как op.i -< add_member и j < i, в по-

следовательности (opl,...,opj) количество правил вида grant_right и add_member меньше N. Значит, по предположению индукции существует u' U, такое, что исти-

нен предикат can_act_as(u,u', G0) и либо u' E Gr0(e,ar), либо (u',e,ar) M G0.

Случай 3. Так как r E Gr0(e,ar), верно (r,e,ar) E Re0. Кроме того, так как (u'',r, alterr) E Rei_ 1, в силу монотонности правил преобразования состояний, (u'' ,r, alter r) E Rek. Заметим, что так как (u'' ,r,alterr) / Re0, (u'' ,r,alterr) E Rek и (r, e, ar) Re0, выполнены условия утверждения 5. Следовательно, существует u' U, такое, что истинен предикат can_act_as(u, u', G0) и (u', r, e, ar) < G0. Легко заметить, что ввиду (u', r, e, ar) < G0 и r E Gr0(e, ar) выполнено (u', e, ar) M G0. ■

Покажем, что справедливы следующие необходимые и достаточные условия истинности предиката can_grant_right.

Теорема 1. Пусть G0 —начальное состояние системы T.(G*,OP), u E U, e E E0, ar E Rr. Предикат can_grant_right(u,e,ar,G0) истинен тогда и только тогда, когда существует u' E U, такое, что истинен предикат can_act_as(u,u', G0) и выполнено одно из условий:

Условие 1. u' E Gr0(e,ar).

Условие 2. (u',e,ar) M G0.

Доказательство. Обоснуем достаточность условий утверждения.

Пусть выполнено условие 1. Положим op = grant_right(s, u, e, ar, yes). Так как u' E Gr0(e,ar), то в G0 выполнены условия применения правила op субъект-сессией, функционирующей от имени учётной записи пользователя u'. Тогда в соответствии с определением 11 из истинности предиката can_act_as(u,u', G0) следует, что истинен предикат can_execute_as(u,u',op,G0). Отсюда по определению 10 существуют инициированные извне правила opу(s),...,opk(s) E OPext, где к > 0 и s / S0, такие, что opl (s) = create _session(s, u), vestige(G0 ,opl (s),..., opk (s)) = (opу, ..., opm), и существует i E {2,... , m} такое, что oypi = op и useri-у (s) = u'. Заметим, что в соответствии с замечанием 15 последовательность oyp , . . . , oypm не включает правила, условия применения которых не выполняются, поэтому выполнены условия применения правила opi в состоянии Gi-у, а значит, u E Grj,(e,ar). Пусть Gk = G0(opl(s),... ,opk(s)). В силу монотонности правил преобразования состояний u Grk(e, ar). Значит, по

определению 13 истинен предикат can_grant_right(u,e,ar,G0).

Пусть выполнено условие 2. Согласно утверждению 2, из истинности предиката can_act_as(u,u', G0) следует истинность предиката can_become(u,u', G0). Отсюда, по определению 12, существуют инициированные извне правила opу(s),..., opk(s) E OPext,

где к > 0, такие, что opl(s) = create_session(s,u), Gk = G0(opl(s),...,opk(s)) и (u,u', impersonater) E Rek. Положим opk+у (s) = switch(s, u'). Заметим, что в состоянии Gk выполнены условия применения правила opk+у (s) и user'k+у (s) = u'. В соответствии с замечанием 18 (u',e,ar) M Gk+у. Значит, существуют роли rl,...,rn E R, где n ^ 1, такие, что (u',r]_,r2,alterr) < Gk+у, для каждого i = 1,...,n — 2 выполняется (ri,ri+1 ,ri+2, alterr) < Gk+1, и (rn-1 ,rn,alterr) E Rek+1, и rn E Grk+1 (e,ar).

Положим opk+2(s) = add_member(s,rl,ul),..., opk+n(s) = add_member(s,rn-у,u'). Пусть Gk+n = Gk+1(opk+2(s), ..., opk+n(s)). Так как userk+1(s) = u', то, учитывая, что (u',r]_,r2,alterr) < Gk+у, в соответствии с утверждением 4 (u',r2, alterr) E Rek+2. В силу замечания 16, (rl,r2,r3, alterr) < Gk+2, откуда (r2,r3, alterr) E Rek+2, а значит, (u',r2,r3,alterr) < Gk+2. Проводя аналогичные рассуждения, легко показать, что (u' ,rn, alterr) E Rek+n. Положим opk+n+у (s) = add_member(s,rn,u). Пусть Gk+n+ у = = Gk+n(opk+n+ У (s)). Заметим, что в состоянии Gk+n выполнены условия применения правила, а значит, rn E UAk+n+ у(u). Так как rn E Gr'k+у(e,ar), то в силу монотонности правил преобразования состояний rn E Grk+n+у(e,ar). Тогда u E Grk+n+ у(e,ar), а значит, по определению 13 истинен предикат can_grant_right(u,e,ar,G0).

Обоснуем необходимость выполнения условий утверждения. Пусть истинен предикат can_grant_right(u,e,ar,G0), тогда существуют инициированные извне правила opу(s),...,opk(s) E OPext, где к > 0, такие, что opl(s) = create_session(s,u), Gk = = G(opу (s),... , opk(s)) и u E Grk(e, ar). Заметим, что так как (u, u, impersonater) E Re0, истинен предикат can_become(u,u,G0), а значит, согласно утверждению 2, истинен предикат can_act_as(u,u,G0). Если u E Gr0(e,ar), то так как истинен предикат can_become(u,u,G0), выполнено условие 1 утверждения. Если u / Gr0(e,ar), то выполнены условия утверждения 6 и существует u' U, такое, что истинен предикат

can_act_as(u,u',G0) и либо u' E Gr0(e,ar), либо (u',e,ar) M G0. ■

Из утверждения 6 и теоремы 1 очевидна справедливость следующего следствия.

Следствие 1. Пусть G0 — начальное состояние системы T.(G*,OP), u E U, e E E0, ar E Rr, s / S0, opу(s),...,opk(s) E OPext, где opl(s) = create_session(s,u), Gk = G0(opу(s),... ,opk(s)), p E P, p E Gr0(e,ar) и p E Grk(e,ar). Тогда истинен предикат can_grant_right(u, e, ar, G0).

7. Необходимые и достаточные условия получения прав доступа

Введём предикат can_get_right(u, e, ar,G), который будет истинен, когда в результате применения правил субъект-сессией, созданной пользователем u, учётная запись пользователя u может получить право доступа ar к сущности e.

Определение 14. Пусть G — состояние системы Tj(G*,OP), u E U, e E E, ar E Rr, s E S и (u,e,ar) / Re. Определим предикат can_get_right(u, e,ar,G), который будет истинным тогда и только тогда, когда существуют инициированные извне правила opу(s),... ,opk(s) E OPext, где к > 0, такие, что opу(s) = create_session(s,u), Gk = G(opl(s),... ,opk(s)) и (u,e,ar) E Rek.

Обоснуем необходимые и достаточные условия получения учётной записью пользователя прав доступа к сущности в начальном состоянии системы G0.

Теорема 2. Пусть G0 —начальное состояние системы Tj(G*,OP), u E U, e E E0, ar E Rr и (u, e, ar) / Re0. Предикат can_get_right(u, e, ar, G0) истинен тогда и только тогда, когда существуют u' E U, e' E E0, такие, что предикат can_act_as(u,u', G0) истинен, e ^ e' и выполнено одно из следующих условий.

Условие 1. u'E Gr0 (e', ar).

Условие 2. (u', e', ar) < G0.

Доказательство. Достаточность.

Пусть выполнено условие 1. Положим op = grant_right(s, u, e',ar, no). Так как u' E Gr0(e',ar), в G0 выполнены условия применения правила op субъект-сессией, функционирующей от имени учётной записи пользователя u'. Тогда в соответствии с определением 11 из истинности предиката can_act_as(u, u', G0) следует, что истинен предикат can_execute_as(u,u',op,G0). Значит, существуют инициированные извне правила opу(s),... ,opk(s) E OPext, где s / S0, такие, что opl(s) = create_session(s,u), vestige(G0,op у (s),... ,opk (s)) = (opу, ... ,opm) и существует i E {2,... ,m}, что = op и useri-у (s) = u'. Заметим, что в соответствии с замечанием 15 последовательность oyp , . . . , oypm не включает правила, условия применения которых не выполняются, поэтому выполнены условия применения правила в состоянии (yi-у , а значит, (u,e',ar) E Rei. Пусть Gk = G0(opу(s),..., opk(s)). В силу монотонности правил преобразования состояний, (u,e',ar) E Rek. Отсюда, так как e ^ e', в соответствии с замечанием 3 (u,e,ar) E Rek. Значит, по определению 14 истинен предикат can_get_right(u, e, ar, G).

Пусть выполнено условие 2. Согласно утверждению 2, из истинности предиката can_act_as(u,u', G0) следует истинность предиката can_become(u,u',G0). Значит, по определению 12 существуют инициированные извне правила opу(s),..., opk(s) E OPext, где к > 0, такие, что opl(s) = create_session(s,u), Gk = G(opl(s),... ,opk(s)) и (u,u', impersonater) E Rek. Положим opk+у(s) = switch(s,u'). Заметим, что в состоянии Gk выполнены условия применения правила opk+у (s) и, следовательно, user'k+у (s) = u'. В соответствии с замечанием 17 (u',e',ar) < Gk+у. Значит, существуют роли r]_,..., rn E R, где n ^ 1, такие, что (u', rу, r2, alterr)<Gk+у, для каждого i = 1,... , n — 2 выполняется (rj,, ri+у, ri+2, alterr) < Gk+у и (rn-у, rn, e', ar) < Gk+у. Положим opk+2(s) = add_-member(s,rl,u'),..., opk+n(s) = add_member(s,rn-у,u'). Пусть Gk+n = Gk(opk+2(s), ...,opk+n(s)). Так как userk+у(s) = u', учитывая (u',rl,r2,alterr) < Gk+у, в соответствии с утверждением 4 получим (u',r2, alterr) E Rek+2. В силу замечания 16 (r l,r2,r3, alterr) < Gk+2, откуда (r2,r3, alter r) E Rek+2, а значит, (u' ,r2,r3, alter r) < Gk+2. Проводя аналогичные рассуждения, легко показать, что (u',rn,alterr) E Rek+n. Положим opk+n+1(s) = add_member(s,rn,u). Пусть Gk+n+1 = Gk+n(opk+n+1(s)).

Заметим, что в состоянии Gk+n выполнены условия применения правила, а значит, rn E UAk+n+у(u). Так как (rn-у,rn,e',ar) < Gk+у, в силу замечания 16 имеем (rn-у, rn,e',ar) < Gk+n+1, а значит, (rn,eJ,ar) E Rek+n+1, и тогда (u,e',ar) E Rek+n+1. Отсюда, так как e ^ e', в соответствии с замечанием 3 (u,e,ar) E Rek+n+1. Значит, по определению 14 истинен предикат can_get_right(u,e,ar,G0).

Необходимость.

Пусть истинен предикат can_get_right(u,e,ar,G0). Тогда, согласно определению 14, существуют инициированные извне правила opу(s),...,opk(s) E OPext, где к ^ 0 и s E S0, такие, что op у (s) = create _session(s, u), Gk = G0(opl (s),... ,opk (s)) и (u,e,ar) E Rek. Пусть vestige(G0,opl(s),... ,opk(s)) = (opl,..., opm).

Так как (u,e,ar) / Re0 и (u,e,ar) / Rek, существует i E {1,... ,m}, что (u,e,ar) / / Rei-1 и (u, e, ar) E Rei. Пусть l — количество правил вида grant_right и add_member в последовательности (opу, ... , opi). Доказательство проведём индукцией по l.

Пусть l = 1. Обозначим useri-у (s) как u'. В соответствии с утверждением 3 истинен предикат can_act_as(u,u', G0). Заметим, что в соответствии с замечанием 15 в состо-

янии (yi-у выполнены условия применения правила op,. Так как l = 1, op, — единственное правило вида grant_right и add_member, откуда Rei-1 = Re0 и Grei-1 = Gre0.

Пусть opi -< grant_right, тогда opi = grant _right(s,... ,e', ar,...), e' E Ei-у , e ^ e'

и u' E Gri-у(e',ar). В системе отсутствуют правила, приводящие к изменению родительских контейнеров сущностей, поэтому e' E E0. Так как Grei_ 1 = Gre0, выполняется u' E Gr0(e',ar), а значит, выполнено условие 1 утверждения.

Если op, -< add_member, то op, = add_member(s,r,u), r E R, (u',r,alterr) E Rei_1 и (r,e',ar) E Rei_ 1, где e! E Ei-у и e ^ e'. В системе отсутствуют правила, приводящие к изменению родительских контейнеров сущностей, поэтому e' E E0. Так как Rei_ 1 = = Re0, имеем (u',r,alterr) E Re0 и (r,e',ar) E Re0. Следовательно, (u',e',ar) < G0, а

значит, выполнено условие 2 утверждения.

Пусть условия утверждения выполняются для всех l < N, где N > 1. Покажем, что они верны и при l = N. Обозначим useri-у (s) как u''. В соответствии с утверждением 3 истинен предикат can_act_as(u,u'', G0).

Пусть op, -< grant_right, тогда op, -< grant _right(s,... ,e', ar,...), e E Ei-у , e ^ e!

и u'' Gri- (e', ar). В системе отсутствуют правила, приводящие к изменению роди-

тельских контейнеров сущностей, поэтому e' E E0. Возможны следующие два случая: 1) u'' E Gr0(e',ar); 2) u'' / Gr0(e',ar).

Случай 1. Если u'' E Gr0(e',ar), то, положив u' = u'', видим, что выполнено условие 1 утверждения.

Случай 2. Так как u'' E Gri-у(e',ar), в силу монотонности правил преобразования состояний u'' E Grk(e',ar). Так как u'' / Gr0(e',ar) и u" E Grk(e',ar), в соответствии с утверждением 6 существует u' U, такое, что истинен предикат

can_act_as(u,u',G0) и либо u' E Gr0(e',ar), либо (u',e',ar) M G0. Учитывая, что в случае (u',e',ar) M G0 также выполняется (u',e',ar) < G0, видим, что выполнены условия 1 и 2 утверждения.

Пусть op, -< add_member, тогда op, ^ add_member(s,r,u), где r E R, (u'',r, alterr) E Rei_1 и (r,e',ar) E Rei_1, где e! E Ei-у и e ^ e'. В системе отсутствуют правила, приводящие к изменению родительских контейнеров сущностей, поэтому e E E0. Возможны три случая: 1) (u'' ,r, alter r) E Re0 и (r,e',ar) E Re0; 2) (r,e',ar) / Re0;

3) (u'',r,alterr) / Re0 и (r,e',ar) E Re0.

Случай 1. Легко заметить, что (u'',e',ar) < G0. Положив u' = u'', видим, что выполнено условие 2 утверждения.

Случай 2. Так как (r, e',ar) / Re0 и (r, e',ar) E Rei-1, существует j E {1,... ,i — 1}, такое, что (r, e', ar) / Rej-1 и (r, e', ar) E Rej. Так как op, ^ add_member и j < i, в последовательности (op ]_,..., opj) количество правил вида grant _right и add_member меньше N. Значит, по предположению индукции существует u' U, такое, что истинен предикат can_act_as(u,u', G0) и либо u' E Gr0(e',ar), либо (u',e',ar) < G0.

Случай 3. Так как (u'',r, alterr) E Rei_ 1, в силу монотонности правил преобразования состояний получим (u'',r, alterr) E Rek. Заметим, что ввиду (r,e',ar) E Re0, (u'' ,r, alter r) / Re0 и (u'' ,r, alter r) E Rek, в соответствии с утверждением 5 существует u' E U, такое, что истинен предикат can_act_as(u,u', G0) и (u',r,e',ar) < G0. Отсюда следует, что (u',e',ar) < G0, а значит, выполнено условие 2 утверждения. ■

Заключение

Таким образом, для обеспечения возможности теоретического анализа безопасности СУБД построена формальная модель, в которую добавлены новые элементы, поз-

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

ЛИТЕРАТУРА

1. Девянин П. Н. Ролевая ДП-модель управления доступом и информационными потоками в операционных системах семейства Linux // Прикладная дискретная математика. 2012. №1(15). С. 69-90.

2. Колегов Д. Н. Дискреционная модель безопасности управления доступом и информационными потоками в компьютерных системах с функционально или параметрически ассоциированными сущностями: дис. ... канд. техн. наук. Томск, 2009.

3. Смольянинов В. Ю. Правила преобразования состояний СУБД ДП-модели // Прикладная дискретная математика. 2013. №1(18). С. 50-68.

4. Bruchez R. Microsoft SQL Server 2012 Security Cookbook. Pact Publishing, 2012. 307с.