Правила преобразования состояний СУБД ДП-модели Текст научной статьи по специальности «Компьютерные и информационные науки»

2013 Математические основы компьютерной безопасности №1(19)

УДК 004.94

ПРАВИЛА ПРЕОБРАЗОВАНИЯ СОСТОЯНИЙ СУБД ДП-МОДЕЛИ

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

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

E-mail: [email protected]

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

Ключевые слова: компьютерная безопасность, СУБД ДП-модель, система управления базами данных.

Введение

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

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

В соответствии с «Критериями оценки безопасности информационных технологий» [1] использование формальных математических моделей является обязательным для анализа безопасности управления доступом и информационными потоками в компьютерных системах, начиная с уровня доверия ОУД 5. Существующие формальные модели логического управления доступом [2, 3] ориентированы в основном на применение в ОС и не учитывают некоторых существенных особенностей функционирования автоматизированных информационных систем, построенных с использованием реляционных СУБД, которые могут быть использованы нарушителем для реализации запрещённых доступов и информационных потоков. В частности, ими игнорируется наследование прав доступа к дочерним сущностям, существование прав на предоставление прав доступа, а также возможность автоматического выполнения SQL-кода при реализации доступа к данным и изменения учётной записи пользователя при активации хранимых процедур и триггеров.

Следовательно, теоретический анализ условий, при которых возможно несанкционированное распространение прав доступа, а также возникновение запрещённых информационных потоков в автоматизированных информационных системах, использу-

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

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

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

В предлагаемой СУБД ДП-модели, построенной на основе РОСЛ ДП-модели [4], используются следующие обозначения и определения:

Od — множество сущностей-данных;

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

Ot — множество сущностей-триггеров;

O = OdU Op U Ot — множество сущностей-объектов, при этом считается, что множества сущностей-данных, сущностей-процедур и сущностей-триггеров попарно не пересекаются, то есть Od П Op = 0, Od П Ot = 0 и Op П Ot = 0;

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

E = O U C — множество сущностей, при этом считается, что O П C = 0, то есть контейнеры не являются сущностями-объектами.

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

Условие 1. Пусть Р (е) = {с Е C : е Е H (с)} —множество родительских контейнеров сущности е. Тогда существует единственный корневой контейнер сг Е C, такой, что |P(сг)| = 0 и для каждой сущности е Е E \ {сг} выполняется |Р(е)| = 1.

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

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

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

Определение 3. Будем говорить, что сущность е Е E иерархически подчинена контейнеру с Е C, если существуют контейнеры с1,... , сп Е C, где n ^ 1, такие, что с1 = с, с*+1 Е H(q) для i = 1,... ,n — 1 и е Е H(сп).

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

Замечание 1. Из определений 1 и 3 следует, что для любой сущности е Е E \{сг} существует контейнер с Е C, такой, что е < с. Кроме того, очевидно, что каждая сущность либо является корневой, либо иерархически подчинена корневой сущности сг и содержится ровно в одном из её дочерних контейнеров. Будем считать необходимым условием равенства сущностей их принадлежность одному контейнеру.

Замечание 2. Легко показать, что если для некоторой сущности е Е E существуют контейнеры с1,...,сп Е C, где n ^ 1, такие, что с1 = сг, Q+1 Е H(q) для i = 1,... , n — 1 и е Е H(сп), и контейнеры с1,... , dn, Е C, где n’ ^ 1, такие, что d1 = сг,

di+1 Е H(с') для i = 1,..., n’ — 1 и е Е H(dn,), то n = n’ и di = с для i = 1,..., n, то есть для любой некорневой сущности е Е E существует единственная последовательность, начинающаяся с сг и заканчивающаяся контейнером, содержащим е, такая, что каждый её элемент является родительским для последующего.

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

U — множество учётных записей пользователей, при этом считается, что учётные записи пользователей по определению не являются сущностями, то есть E П U = 0;

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

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

asso/(s): S ^ Op U Ot U {0} — функция, задающая для каждой субъект-сессии s Е S функционально ассоциированную с ней сущность;

owner: E ^ U — функция, задающая для каждой сущности учётную запись её владельца, при этом для каждой таблицы t Е T и каждой сущности е Е H(t) по определению выполняется равенство owner(е) = owner (t);

owners: E ^ 2u — функция, задающая для каждой сущности учётные записи её иерархических владельцев, при этом для каждой сущности е Е E по определению u Е owners(е) тогда и только тогда, когда либо u = owner(е), либо существует контейнер с Е Р (е), такой, что u Е owners (с);

eжecute_as: Op U Ot ^ {as_rn//er, as_owner} — функция, задающая для каждой сущности-процедуры и сущности-триггера режим их выполнения субъект-сессиями (as_rn//er соответствует режиму выполнения сущности от имени учётной записи пользователя, инициировавшей её запуск, а as_owner — от имени учётной записи владельца сущности);

Rr = {readr ,writer, appendr , de/eter, a/terr, exeauter} — множество видов прав доступа к контейнерам и сущностям-процедурам;

Ot* —множество всех конечных последовательностей сущностей-триггеров.

Определение 4. Определим triggers: T х {writer, appendr , de/eter} ^ O^ — функцию, задающую для каждой таблицы связанную с ней последовательность сущностей-триггеров и удовлетворяющую следующим условиям.

Условие 1. Для каждой таблицы t Е T и каждого права доступа ar Е {writer, appendr, de/eter} выполняется triggers(t, ar) С H(t).

Условие 2. Для каждой сущности-триггера ot Е Ot существует единственная таблица t Е T и единственное право доступа ar Е {writer, appendr, de/eter}, такое, что ot Е triggers(t,ar).

Если существуют таблица t Е T, право доступа ar Е {writer, appendr, de/eter} и сущность-триггер ot Е triggers(t, ar), то будем говорить, что сущность-триггер ot имеет тип ar и связана с таблицей t.

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

R С U х (CUOp) х Rr — множество непосредственно заданных прав доступа учётных записей пользователей к контейнерам и сущностям-процедурам;

Rown = {(u,e,ar) : ar Е Rr, е Е C U Op,u = owner(e)} —множество прав доступа учётных записей пользователей — владельцев контейнеров и сущностей-процедур;

RH = {(u, е, ar) : u Е U, е Е C U Op, ar Е Rr, Зс Е C((u, с, ar) Е R U Rown & е < с)} — множество иерархических прав доступа учётных записей пользователей к контейнерам и сущностям-процедурам;

Re = R U Rown U Rh — множество действующих прав доступа учётных записей пользователей к контейнерам и сущностям-процедурам;

Gre = Gr U Grown — множество действующих прав на предоставление прав доступа к контейнерам и сущностям-процедурам, при этом множества Gr и Grown задаются следующим образом:

Gr С U х (C UOp)xRr — множество непосредственно заданных прав на предоставление прав доступа к контейнерам и сущностям-процедурам, удовлетворяющее условию Gr С Re;

Grown = {(u,e,ar) : u Е U, ar Е Rr, e Е C U Op,u Е owners(e)} — множество прав доступа на предоставление прав доступа иерархическими владельцами контейнеров и сущностей-процедур;

Gr(e, ar) = {u Е U : (u, e, ar) Е Gre}, где e Е C U Op, ar Е Rr — множество учётных записей пользователей, которые могут предоставлять право доступа ar Е Rr к сущности e Е C U Op;

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

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

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

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

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

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

time Е No — счётчик моментов времени, значение которого увеличивается на единицу при реализации каждого правила op Е OP;

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

G = (U, S, E, R, Gr, H, user, asso/, owner, exea«te_as, triggers, operations, time, tr) — состояние системы;

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

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

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

Предположение 1. Считается, что в начальном состоянии системы E(G*, OP, G0) отсутствуют субъект-сессии, то есть S0 = 0; кроме того, значение счётчика моментов времени time0 в начальном состоянии равно 0 и последовательность tr0 не содержит элементов.

Поясним введённые обозначения и определения.

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

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

Т а б л и ц а І

Внутренние правила преобразования состояний СУБД ДП-модели

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

switches, o, u, op) s Е S, u Е U, o Е Op U Ot U{0}, op Е OPext G'{user', assocf ,time',tr'} — G', user'{s ^ u} — user, assocf {s ^ o} — assocf, time' = time + 1, tr' = (tr, switch(s, o, u, op))

revert(s, u, o) s Е S, u Е U, o Е Op U Ot U {0} G'{user', assoc'f ,time',tr'} — G', user'{s ^ u} — user, assocf {s ^ o} — assocf, time' = time + 1, tr' = (tr, revert(s, u, o))

execute(s, o, op) s Е S,o Е Op U Ot, op Е OPext, operations(o) = = (opi, .. .,opk), к > 0, Vi Е 1,к opi Е Opext G' = G(switch(s, o, u, op), opi,..., opk, revert(s, user(s), [s])), I owner(o) при execute as(o) = as owner, u= 1 user(s) при execute as(o) = as caller

do insert (s,t1,odl ,t2,od2 ) s Е S, ti, t2 Е T,u = user(s), odi Е Od, od2 Е H(t2) G'{E', H', time', tr'} - G, E' = O' U C, O' = O U {odi}, H'{ti ^ H(ti) U {odi}} - H, time' = time + 1, tr' = (tr, do insert(s, ti, odi, t2, od2))

do update (s,t1,od1 ,t2,od2 ) s Е S, ti, t2 Е T,u = user(s), odl Е H(t1), od2 Е H(t2) G'{time', tr'} — G, time' = time + 1, tr' = (tr, do update(s,ti,odi ,t2,od2))

do deleters, t,od) s Е S,t Е T,u = user(s), od Е H(t) G'{E', H', time', tr'} — G, E' = O' U C, O' = O \ {od}, H'{t ^ H(t) \ {od}} — H, time' = time + 1, tr' = (tr, do delete(s, t, od))

Т а б л и ц а 2

Внешние правила преобразования состояний СУБД ДП-модели

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

1 2 3

create session (u,s) u Е U, s Е S G'{S', user', assocf ,time', tr'} — G, S' = S U{s}, user'{s ^ u} — user, assocf {s ^ 0} — assocf, time' = time + 1, tr' = (tr, create session(u, s))

grant right (s, u, e, ar, with grant) s Е S, u Е U, e Е C U Op, ar Е Rr, user(s) Е Gr(e, ar), with grant Е {yes, no} G'{R', Gr', time', tr'} — G,R' = R U {(u, e, ar)}, ' 1 Gr U {(u, e, ar)} при with grant = yes, 1 Gr при with grant = no time' = time + 1, tr' = (tr, grant right(s,u, e, ar,with grant))

create container (s,cP,c) s Е S,cp Е C,c Е C, (user(s), cp, alterr) Е Re G'{E', H', owner', time', tr'} — G, E' = O U C, C' = CU {c}, H'{c ^ 0,cp ^ H(cp) U{c}} — H, owner'{c ^ user(s)} — owner, time' = time + 1, tr' = (tr, create container(s, cp, c))

create procedure (s, c, op, md, opi,..., opk) s Е S,cЕ C \ T, op Е Op, md Е {as caller, as owner}, к ^ 0, Vi Е 1,к opi Е OPext, (user(s), c, alterr) Е Re G'{E', H', owner', execute as', operations', time', tr'} — G, E' = O' U C, O' = O U {op}, H'{c ^ H(c) U {op}} — H, owner'{op ^ user(s)} — owner, execute as'{op ^ md} — execute as, operations'{op ^ (opi,. .., opk)} — operations, time' = time+1, tr' = (tr, create procedure(s, c, op, md, opi,.. ., opk)

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

1 2 3

alter procedure (s, Op, md, opi,. .., opk) s € S, op € Op, md € {as caller, as owner}, k ^ 0, Vi € 1,k opi € OPext, (user(s), op, alterr) € Re G'{execute as', operations',time',tr'} — G, execute as'{op ^ m} — execute as, operations'{op ^ (opi,. .., opk)} — operations, time' = time+1, tr' = (tr, alter procedure(s, op, md, opi,. .., opk))

create trigger (s, t, ot, ar, md, opi,..., opk) s € S, t € T, ot € Ot, Qr € Rr, md {as caller, as owner}, k ^ 0, Vi € 1,k opi € OPext, (user(s),t, alterr) € Re G'{E', H', owner', execute as', triggers', operations', time', tr'} — G, E' = O' U C, O' = O U {ot}, H'{t ^ H(t) U {ot}} - H, owner'{ot ^ user(s)} — owner, execute as'{ot ^ md} — execute as, triggers'{(t, ar) ^ (triggers(t, ar),ot)} — — triggers, operations'{ot ^ (opi,. .., opk)} — — operations, time' = time + 1, tr' = (tr, create trigger(s, t, ot, ar, md, opi,.. ., opk))

alter trigger (s, t, ot, md, opi,..., opk) s € S,t €T,ot € Ot, md {as caller, as owner}, k ^ 0, Vi € 1,k opi € OPext, (user(s),t, alterr) € Re, ot € H(t) G'{execute as', operations',time',tr'} — G, execute as'{ot ^ md} — execute as, operations'{ot ^ (opi, ..., opk)} — operations, time' = time +1, tr' = (tr, alter trigger(s, t, ot, md, opi,. .., opk))

execute procedure (s,op) s € S, op € Op, (user(s), op, executer) € Re G' = G(execute(s, op, execute procedure(s, op)))

access insert (s,ti,odl ,t2,od2) s € S, ti, t2 € T, u = user(s), (u,ti ,writer) € Re, (u, t2, readr) € Re, trigger s(ti,appendr) = = (ot,i,..., ot,k), k > 0, Vi € 1, k ot i € Ot G' = G(do insert(s,ti,od1 ,t2,od2), execute(s, ot,i, access insert(s,ti, odt ,t2, od2)), execute(s, ot,k, access insert(s, ti, od1, t2, od2)))

access update (s,ti,odi ,t2,od2 ) s € S, ti, t2 € T, u = user(s), (u, ti, writer) Re, (u, t2, readr) € Re, trigger s(ti,writer) = = (ot,i,..., ot,k), k > 0, Vi € 1, k ot,i € Ot G' = G(do update(s,ti,od1 ,t2,od2), execute(s, ot i, access update(s, ti, od1, t2, od2)), execute(s, ot,k, access update(s, ti, od1, t2, od2)))

access delete (s,t,od) s € S,u = user(s), (u, t, deleter) Re, triggers(t, deleter) = = (ot,i,..., ot,k), k > 0, Vi € 1, k ot,i € Ot G' = G(do delete(s, t, od), execute(s, ot,i, access delete(s, t, od)), execute(s, ot,k, access delete(s, t, od)))

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

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

Помимо корневого контейнера сг, в рамках модели выделяется особый вид контейнеров— таблицы. Согласно условию 3 определения 1, для каждой таблицы £ Е Т выполняется Н(£) С и О*, из чего следует, что таблицы не могут иметь дочерних

контейнеров и содержат только сущности-данные и сущности-триггеры.

Обоснуем следующее утверждение.

Утверждение 1. Если |С | > 1, то cr Е T.

Доказательство. Предположим противное, то есть cr Е T.

Из условия утверждения следует, что существует с Е C, с = cr. Тогда по условию 2 определения 1 существуют контейнеры Cl, . . . , cn, где n ^ 1, такие, что Cl = cr, ci+i Е H (ci) для i = 1,... , n — 1 и сЕ H (cn). Это означает, что существует контейнер с1 Е C, такой, что с1 Е H(cr), причём с' Е Od U Ot, так как O П C = 0.

По предположению корневой контейнер сг является таблицей, следовательно, по условию 3 определения 1 выполняется H(сг) с Od U Ot.

Отсюда одновременно имеет место с' Е H(сг) С Od U Ot и с' Е Od U Ot. Пришли к противоречию, следовательно, корневой контейнер сг не является таблицей. ■

В замечании 1 отмечается, что для каждой сущности за исключением корневой существует единственный контейнер, в котором она содержится. Кроме того, в соответствии с условием 3 определения 1 в множество таблиц включаются все контейнеры, содержащие хотя бы одну сущность-данные или сущность-триггер. Следовательно, для каждой сущности-данные и сущности-триггера e Е Od U Ot существует ровно одна таблица t Е T, в которой она содержится, то есть e Е H(t).

Сущности-триггеры соответствуют триггерам таблиц в СУБД, SQL-код которых автоматически выполняется при осуществлении операций вставки, удаления и обновления записей таблиц, с которыми они связаны. Каждая сущность-триггер имеет тип, задаваемый функцией triggers и соответствующий определённому виду доступа. Реализация субъект-сессией доступа вида ar Е {writer, appendr, de/eter} к таблице t Е T автоматически инициирует выполнение ею SQL-кода всех триггеров из последовательности triggers(t, ar).

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

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

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

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

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

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

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

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

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

Утверждение 2. Для каждой сущности e Е E выполняется равенство

owners(e) = {u Е U : Зс Е C (e<c & u = owner (с))} U {owner(e)}.

Доказательство. Обозначим

owners'(e) = {uEU : Зс E C (e<c & u = owner (с))} U {owner(e)}.

Покажем, что для каждой e Е E верно равенство owners'(e) = owners(e). Возможны два случая: e = сг и e = сг.

Если e = сг, то по определению 1 выполняется |Р(сг)| = 0, а значит, из определения 3 следует, что не существует контейнера с Е C, такого, что сг < с. Значит, в данном случае owners'(e) = {owner(e)}. Кроме того, из способа задания функции owners видно, что в случае e = сг выполняется равенство owners(e) = {owner(e)}. Следовательно, в случае e = сг верно равенство owners'(e) = owners(e).

Если e = сг, то, согласно замечанию 2, существует единственная последовательность контейнеров с1,...,сп Е C, где n ^ 1, таких, что с1 = сг, Q+1 Е H(сг) для

i = 1,..., n — 1 и e Е H(сп).

Покажем, что не существует контейнера с Е C, такого, что e < с и с = с^, j = 1,... , n. Предположим противное. Так как с1 = сг и по предположению с = с1, то, согласно замечанию 2, существует единственная последовательность контейнеров d1,...,dk Е C, где к ^ 1, таких, что d1 = сг, с'+1 Е H(с') для i = 1,...,k — 1 и с Е H(ск). Кроме того, так как e < с, то по определению 3 существуют контейнеры ск+1,..., dn, Е C, где n' ^ к + 1, такие, что ск+1 = с, с'+1 Е H(с') для i = к + 1,..., n' — 1 и e Е H(dn,). Следовательно, существует последовательность контейнеров d1,...,dn,, таких, что с1 = сг, с'+1 Е H(с') для i = 1,... , n' — 1 и e Е H(сП,). Так как по замечанию 2 существует лишь единственная последовательность контейнеров, удовлетворяющая данным свойствам, то n' = n и с' = сг, i = 1,... ,n. Следовательно, существует j = к + 1, j Е {1,... , n} и с = dj = с^, а по предположению с = с^ для всех j = 1,... , n. Пришли к противоречию.

Отсюда имеем, что {с Е C : e < с} = {с1,... ,сп}. Следовательно, верно равенство

п

owners'(e) =( (J owner(ci^ U{owner(e)}. (1)

i=1

Доказательство для случая e = сг проведем индукцией по n — количеству элементов в последовательности контейнеров с1,... ,сп Е C, где n ^ 1, таких, что с1 = сг, сг+1 Е H(сг) для i = 1,... ,n — 1 и e Е H(сп). При n =1 из (1) следует выполнение равенства

owners'(e) = owner(^) U owner(e). (2)

Пусть u E owners(e). Из способа задания функции owners следует, что возможны два случая: либо u = owner(e), либо существует контейнер с Е P(e), такой, что u Е owners^). Если u = owner(e), то из (2) следует, что u Е owners'(e). Рассмотрим

второй случай. Пусть существует контейнер с Е P(e), такой, что u Е owners^). Так

как e Е H(с1), то с = с1, а следовательно, u Е owners(с1). В этом случае из (2) следует, что u Е owners'(e).

Пусть u Е owners'(e). Из (2) следует, что возможны два случая: u = owner(e) и u = owner(^). В случае u = owner(e) из способа задания функции owners следует, что u Е owners(e), а если u = owner(с1), то u Е owners(с1). Таким образом, существует контейнер с1 Е P(e), такой, что u Е owners(с1), а следовательно, u Е owners(e).

Итак, в случае n =1 выполняется равенство owners'(e) = owners(e).

Пусть n > 1 и равенство owners'(e) = owners(e) выполняется для всех к < n. Заметим, что из (1) следует owners'(e) = owners'(^) U {owner(e)}. Число элементов в последовательности с1,... , сп-1 меньше, чем n, и, следовательно, по предположению индукции owners'(сп) = owners(сп). Таким образом, верно равенство

owners'(e) = owners(^) U {owner(e)}. (3)

Пусть u E owners(e). Из способа задания функции owners следует, что возможны два случая: либо u = owner(e), либо существует контейнер с Е P(e), такой, что u Е owners(c). Если u = owner(e), то из (3) следует u Е owners'(e). Рассмотрим случай u = owner(e). Так как с Е P(e) и e Е H(сп), то с = сп, а следовательно, u Е owners(^). Тогда из равенства (3) видно, что u owners'(e).

Пусть u Е owners'(e). Из (3) следует, что возможны два случая: u = owner(e) и u Е owners(сп). Если u = owner(e), то из способа задания функции owners следует u Е owners(e). Рассмотрим случай u Е owners(сп). Ввиду e Е H(сп) имеем сп Е P(e). Таким образом, сп Е P(e) и u Е owners(cn), откуда, по способу задания функции owners, верно u Е owners(e). Следовательно, для случая k = n индуктивный шаг доказан и owners'(e) = owners(e). ■

Таким образом, для каждой сущности e E множество owners(e) состоит из учётной записи владельца сущности e, а также учётных записей владельцев контейнеров, которым иерархически подчинена сущность e. Заметим, что значения функции owners однозначно определяются функцией иерархии сущностей H и функцией задания владельцев сущностей owner, и поэтому она не рассматривается в качестве самостоятельного элемента состояния системы.

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

Замечание 3. Присутствующий в реальных СУБД режим выполнения сущностей-процедур и сущностей-триггеров от имени фиксированной учётной записи в рамках модели не рассматривается.

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

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

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

При определении возможности применения правил преобразования состояний в модели учитываются права доступа, содержащиеся в множестве действующих прав доступа учётных записей пользователей Re. Полагается, что субъект-сессии s, функционирующей от имени учётной записи пользователя user(s) = u, разрешено реализовать доступ вида ar к сущности e в случае, если (u,e,ar) Е Re. Множество действующих прав доступа Re включает множество непосредственно заданных прав доступа R, множество прав доступа учётных записей владельцев Ro^, а также множество иерархических прав доступа R# . Из способа задания множества R^n, следует, что учётная запись владельца сущности обладает к ней всеми правами доступа. Кроме того, из способа задания множества R# следует, что учётная запись пользователя, имеющего непосредственно заданное право доступа ar к контейнеру с либо являющегося его владельцем, также обладает этим правом доступа и к любому его иерархически подчинённому контейнеру и сущности-процедуре. Таким образом, верно следующее замечание.

Замечание 4. Если u Е U, e,e' Е C U Op, ar Е Rr, e ^ e' и (u,e',ar) Е Re, то

(u, e, ) E Re.

Заметим, что множества прав доступа Rc^, Rh и Re однозначно определяются множеством прав доступа R, функцией иерархии сущностей H и функцией задания владельцев сущностей owner и поэтому не рассматриваются в качестве самостоятельных элементов состояния системы.

Считается, что наличие у учётной записи прав доступа readr, writer, appendr или de/eter к таблице позволяет выполнять над иерархически подчинёнными ей сущно-стями-данными операции выборки, обновления, вставки и удаления соответственно. Наличие права доступа de/eter к контейнеру позволяет удалять его дочерние контейнеры и сущности-процедуры. Обладание правом доступа a/terr к сущности-процедуре позволяет задавать её SQL-код и режим выполнения. Право доступа a/terr к таблице позволяет создавать в ней сущности-триггеры, а также изменять SQL-код связанных с ней сущностей-триггеров и режим их выполнения. Наличие права доступа executer на сущность-процедуру позволяет выполнять её SQL-код.

При введении множества непосредственно заданных прав доступа R для простоты игнорируется, что права доступа readr, writer и appendr могут применяться только к контейнерам, а право доступа executer неприменимо к таблицам. Отметим, что способ задания множества R учитывает, что большинство современных СУБД предоставляют возможность устанавливать права доступа к контейнерам и сущностям-процедурам, не позволяя определять их на уровне отдельных сущностей-данных и сущностей-триггеров.

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

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

Для учёта данной особенности в модель вводится множество действующих прав на предоставление прав доступа к контейнерам и сущностям-процедурам Gre. Полагается, что если (u,e,ar) Є Gre, то субъект-сессия s, функционирующая от имени учётной записи пользователя user(s) = u, может дать любой другой учётной записи пользователя право доступа ar к сущности e. Помимо множества непосредственно заданных прав на предоставление прав Gr, в Gre включаются права иерархических владельцев сущностей, заданные множеством Grown. При этом субъект-сессия, функционирующая от имени одного из иерархических владельцев сущности, может дать любые права доступа к ней. Заметим, что множества Gre и Grown однозначно определяются множеством Gr, функцией иерархии сущностей H и функцией задания владельцев сущностей owner и поэтому не рассматриваются в качестве самостоятельных элементов состояния системы.

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

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

Доказательство. По способу задания Gre = Gr U Grown и Gr С Re. Покажем, что Grown С Re. Пусть e Є C U Op, ar Є Rr, (u,e,ar) Є Grown, где u Є owners(e). В случае u = owner(e), согласно способу задания множества Rown, выполняется (u,e,ar) Є Rown С Re. Если же u = owner(e), то, согласно утверждению 2, существует контейнер с Є C, такой, что e < с и u = owner(с). Так как u = owner (с), то по способу задания множества Rown выполняется (u, с, ar) Є Rown. Таким образом, выполняется u Є U, e Є C U Op, ar єRr и существует контейнер с Є C, такой, что (u,c, ar) Є Rown и e < с. Следовательно, согласно способу задания множества RH, выполняется (u,e,ar) Є RH С Re. ■

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

Будем использовать запись вида G/{I1,... , Ik} ~ G для обозначения того, что все элементы состояния G/ равны соответствующим элементам состояния G, за исключением элементов I1,... , Ik состояния G/. Будем также использовать запись вида //{Х1, ... ,Xk} / для обозначения того, что значения функции //(x) равны значениям

функции /(х) для всех аргументов х, за исключением ж1,... , Xk. Кроме того, будем использовать запись вида //{х1 м y1,...,xk м yk} ~ / для обозначения того, что значения функции //(х) равны значениям функции / (х) для всех аргументов х, кроме х1, . . . ,хд;, и при этом //(х1) = y1, . . ., /^хд;) = yk. Очевидно, что если выполняется G/{I1,..., Ik} ~ G, то также верно и G{I1,..., Ik} ~ G/.

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

Запись вида G/ = G(op1,... , opk) означает, что состояние G/ есть результат последовательного применения правил преобразования состояний op1, . . . , opk в начальном состоянии G, то есть существуют состояния G1,...,Gk, такие, что G hopi G1 hop2

. . . hopk Gk и G/ = Gk.

В СУБД ДП-модели определены приведённые в табл. 1 и 2 правила преобразования состояний из множества ОР, в которых учтены особенности управления доступом в современных СУБД.

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

В отличие от внешних правил, внутренние правила применяются субъект-сессиями опосредованно в ходе выполнения Б^Р-кода как составная часть преобразований системы, задаваемых внешними (см. описание правил ежесм^е ргосе^иге, ассезз_тзег£, ассезз_ир^а£е и ассезз_^е/е£е в табл. 2) или другими внутренними правилами (см. описание правила ежеси^е).

Запись вида (£г, ор), использованная при определении нового значения £г;, означает, что в возможно пустую последовательность £г добавляются данные о применяемом правиле ор.

В результате применения внутреннего правила зи’йсЛ^з, о, и, ор) в качестве учётной записи, от имени которой функционирует субъект-сессия 5, устанавливается и, а о становится функционально-ассоциированной с 5 сущностью. Параметр ор Е ОРех* задаёт внешнее правило, в результате применения которого было инициировано выполнения правила зи’йсЛ^з, о, и, ор).

Правило гетег^з, и, о) предназначено для восстановления состояния субъект-сессии 5 до активации ею сущности-триггера или сущности-процедуры. В результате применения правила гетег£(з, и, о) в качестве учётной записи, от имени которой функционирует субъект-сессия 5, устанавливается и, а о становится функционально-ассоциированной с 5 сущностью.

Внутреннее правило ежеси^е^, о, ор) задаёт состояние системы после выполнения Б^Р-кода, содержащегося в сущности-процедуре или сущности-триггере о Е Ор и О* субъект-сессией 5 Е Б. Перед выполнением Б^Р-кода сущности о производится изменение учётной записи пользователя, от имени которой субъект-сессия 5 будет последовательно применять внешние правила ор1,..., орк. Учётная запись пользователя устанавливается в соответствии с режимом выполнения кода сущности-процедуры или сущности-триггера о, задаваемой значением функции ежесм^е_ав(о). Кроме того, перед выполнением Б^Р-кода сущности о в качестве функционально-ассоциированной с субъект-сессией 5 сущностью устанавливается сущность о. После завершения описанных подготовительных действий производится выполнение Б^Р-кода сущности о, что приводит к реализации преобразований состояний системы, задаваемых последовательностью правил орега^гопв(о) = (ор1,...,орк). После выполнения кода производится восстановление исходной функционально-ассоциированной сущности с субъект-сессией 5, а также учётной записи, от имени которой она выполнялась до применения внутреннего правила ежеси^е^, о, ор). Параметр ор Е ОРех* задаёт внешнее правило, в результате применения которого было инициировано выполнение правила ежеси£е(з, о, ор).

Применение внутреннего правила ^о_тзег£(з, ^1, о^1 , £2,о^2) приводит к добавлению сущности-данные о^1 в таблицу ^1, при этом содержимое сущности-данные о^2 копируется во вновь создаваемую сущность-данные о^1.

Применение внутреннего правила ^о_ир^а£е(з, ^1, о^1, £2, о^2) приводит к замене содержимого сущности-данные о^1 на содержимое сущности-данные о^2.

Внутреннее правило ^о_^е/е^е(в, £, о^) позволяет активировавшей его субъект-сессии 5 выполнить удаление сущности-данные о^ из содержащей её таблицы £.

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

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

В результате применения правила сгеа£е_зеззгоп(и, в) создаётся новая субъект-сессия з, которая в дальнейшем может выполнять действия от имени учётной записи пользователя и Є Р.

Предположение 3. Будем считать, что все правила из табл. 1 и 2, за исключением правила сгеа£е_зеззгоп(и, в), получают в качестве первого параметра субъект-сессию, инициировавшую выполнение данного правила. В рамках вновь созданной субъект-сессии повторное применение правила сгеа£е_зеззгоп(и, в) не допускается.

Определение 5. Будем говорить, что применение правила ор Є ОР инициировано учётной записью пользователя и Є и, если либо ор = сгеа£е_зеззгоп(и, в), либо ор имеет в качестве первого параметра субъект-сессию 5, такую, что и = изег(з).

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

Определение 6. Пусть О Ьор О' — переход системы Е(О*,ОР) из состояния О в состояние О'. Назовём переход О Ьор О1 инициированным извне, если ор Є ОРєжі и либо ор имеет вид сгеа^е_5е55гоп(и, в), либо правило ор получает в качестве первого параметра субъект-сессию з, такую, что [в] = 0. Если переход О Ьор О' инициирован извне, то будем называть правило ор инициированным извне.

Замечание 5. Согласно предположению 3, применение правила сгеа£е_зез-віоп(и, в) не может быть инициировано ранее созданной субъект-сессией. Следовательно, правило сгеа£е_зеззгоп(и, в) может быть инициировано только извне.

Допустим, заданы состояния системы О0, ... , О к, где к ^ 1, и внешние правила преобразования состояний орі,... , орк Є ОРєх*, такие, что О0 Ьорі Оі Ь^ ... Ь^ Ок и для каждого і = 1,... , к переход Оі-1 Ь^ О^ инициирован извне учётной записью пользователя и Є Р0, причем ор1 = сгеа£е_зеззіоп(и, в1). Предположим, что в результате применения указанных правил были созданы субъект-сессии в1,... ,вт, где т ^ 1. Согласно замечанию 5, субъект-сессии могут быть созданы только в результате применения правил, инициированных извне. Следовательно, для каждого і Є {1,..., т} существует і Є {1,... , к}, такой, что ор^ = сгеа£е_зеззіоп(и, ^). Обозначим через ор1,..., ор&/, где к' ^ 1, последовательность правил, полученную из ор1,... , орк путём исключения всех правил вида сгеа£е_зеззіоп(и, ^), і ^ 2, и заменой всех случаев использования ^ на в1. Пусть состояния системы О0, ..., Ок таковы, что О0 Ь^ О1 Ь^ ... Ьор/ О'кі. Заметим, что состояние О^ удовлетворяет соотношению Окі{5'к/} ~ Ок, Бк = Бк\{з2, ... , вт}. Следовательно, без ограничения общности, будем считать, что выполняется следующее предположение.

Предположение 4. В процессе перехода системы из состояния в состояние для каждой учётной записи пользователя создаётся не более чем одна соответствующая ей субъект-сессия. Будем считать, что в начальном состоянии О0 системы Е(О*, ОР) для каждой учётной записи пользователя и Є Р существует единственная соответствующая ей субъект-сессия з Є Б.

Замечание 6. Как видно из табл. 2, в результате применения внешних правил производится изменение значения счётчика времени. В большинстве правил значение этого счётчика увеличивается на единицу. Однако в результате выполнения Б^Р-кода

сущностей-процедур и сущностей-триггеров (при применении правил a^ess^nsert, a^ess_update, a^ess_de/ete и execute_procedure) значение счётчика времени увеличивается на величину, большую чем единица.

Определение Т. Пусть заданы состояния системы G0,... , Gk, где k ^ 1, и правила преобразования состояний op1,... , opk, такие, что G0 hopl G1 hop2 ... hopk Gk и для каждого i = 1,... , k переход Gi-1 hopi G^ инициирован извне и trk = (tr0, Op1,... , Opm), где m ^ 0. Обозначим через vestige(G, op1,..., opk) последовательность правил преобразования состояний (Op1,... , Opm).

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

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

Пусть заданы состояния системы G0,... , Gk, где k ^ 1, и правила преобразования состояний op1,... , opk, такие, что G0 hopl G1 hop2 ... hopk Gk и для каждого i = 1,... , k переход Gi-1 hop. G^ инициирован извне и vestige(G0, op1, ... , opk) = (Op1,... , Opm). Пусть состояния G0, G^ ... , Gm таковы, что G0 = G0 и G0 hop1 G1 hop2 ... hopm Gm. Заметим, используя приведённые выше обозначения, что функция vestige обладает следующими свойствами.

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

Свойство 2. Для каждого i = 1,... , m выполняется time = timei-1 + 1.

Свойство 3. vestige(G0, op1,..., opk) = (vestige(G0, op1,..., opk-1), vestige(Gk-1, opk)) = (vestige(G0, op1), vestige(G1, op2),..., vestige(Gk-1, opk)).

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

Свойство Б. Если выполнены условия применения правила op Є OPext в состоянии G0 и op не является правилом вида a^ess_insert, a^ess_update, a^ess_de/ete и execute_procedure, то vestige(G, op) = (op).

Свойство б. vestige(G0, op1,..., opk) не может включать правила преобразования состояний следующего вида: a^ess_insert, a^ess_update, a^ess_de/ete, execute и execute_procedure — и может включать правила следующего вида: swifch, revert, do_insert, do_update, do_de/ete, ^eate_session, create_procedure, a/ter _procedure, create_trigger, a/ter_trigger или grant_right.

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

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

Правило CTeate^ontaine^s, с?, с) позволяет субъект-сессии s создать новый контейнер с, включив его в существующий контейнер с?, при этом владельцем вновь со-

зданного контейнера становится учётная запись пользователя user(s). Необходимым условием применения данного правила является наличие у учётной записи пользователя user(s) права доступа a/terr к контейнеру cp.

Замечание 9. В результате применения правил alter_procedure, a/ter_trigger и create_container в множества R и Gr не выполняется добавление прав доступа учётной записи владельца к вновь созданной сущности. Это связано с тем, что при задании учётной записи владельца в соответствии с правилами задания в множества Re и Gre включаются права доступа всех её иерархических владельцев.

В результате применения правила create_procedure(s, с, op, md, op1, ..., opk) в контейнере с, не являющемся таблицей, создаётся новая сущность-процедура op, содержащая SQL-код, выполнение которого приводит к реализации правил преобразования состояний op1,... , opk, при этом владельцем вновь созданной сущности-процедуры op становится учётная запись пользователя user(s), а режим выполнения op устанавливается равным m. Необходимым условием выполнения данного правила является наличие у учётной записи пользователя user(s) права доступа a/terr к контейнеру с.

В результате применения правила a/ter_procedure(s, op, md, op1, ..., opk) выполняется изменение режима выполнения существующей сущности-процедуры op, а также замена её SQL-кода на новый, выполнение которого приводит к реализации правил преобразования состояний op1,..., opk. Необходимым условием применения данного правила является наличие у учётной записи пользователя user(s) права доступа a/terr к сущности-процедуре op. Отметим, что в отличие от правила create procedure владелец сущности-процедуры op не изменяется.

В результате применения правила create_trigger(s, t, ot, ar, md, op1,..., opk) в таблице t создаётся новая сущность-триггер ot, содержащая SQL-код, выполнение которого приводит к реализации правил преобразования состояний op1,... , opk, при этом владельцем вновь созданной сущности-триггера ot становится учётная запись пользователя user(s), а режим выполнения ot задаётся равным m. Созданная сущность-триггер активизируется только при реализации к таблице t права доступа ar. Если создаваемая сущность-триггер имеет тип ar = appendr, то она активизируется при применении в отношении таблицы t внешнего правила access_insert. В случае если ot имеет тип ar = writer, то ot активизируется при применении в отношении таблицы t внешнего правила access_update. Если же ar = de/eter, то сущность-триггер ot активизируется при применении к таблице t внешнего правила access_de/ete. Необходимым условием применения правила create_trigger является наличие у учётной записи пользователя user(s) права доступа a/terr к таблице t.

В результате применения правила a/ter_trigger(s, t, ot, md, op1,..., opk) в таблице t выполняется модификация режима выполнения существующей сущности-триггера ot, а также замена её SQL-кода на новый, выполнение которого приводит к реализации правил преобразования состояний op1,... , opk. Необходимым условием применения данного правила является наличие у учётной записи пользователя user(s) права доступа a/terr к таблице t. Отметим, что в отличие от правила create_trigger не выполняется изменение учётной записи владельца сущности-триггера ot, а также вида доступа, при реализации которого активизируется сущность-триггер ot.

Предположение Б. Будем считать, что выполнение SQL-кода сущностей-триггеров и сущностей-процедур не приводит к применению правил create_container, create_procedure, a/ter_procedure, create_trigger или a/ter_trigger, то есть перечисленные правила могут быть применены только извне. Из данного предпо-

ложения следует, что при применении правил create _procedure (... , op1,...,opk), alter_procedure(... ,op1,..., opk), create_trigger(... ,op1,... ,opk) и alter_trigger(..., op1,... , opk) ни одно из правил op1,... , opk не должно быть равно create_procedure, alter_procedure, create_trigger или alter_trigger.

Замечание І0. Заметим, что если o Є Op U Ot, operations(o) = (op1,...,opk), где k ^ 0, то для каждого i = 1,...,k выполняется неравенство op^ =

= create_session. Предположим противное: существует i Є {1,...,k}, такое, что op^ = create_session. Согласно способу задания правил преобразования состояний системы, выполнение правил сущностей-триггеров и сущностей-процедур o осуществляется ранее созданной субъект-сессией s S. Следовательно, приме-

нение правила op^ = create_session инициируется субъект-сессией s, что противоречит предположению З о том, что в рамках вновь созданной субъект-сессии повторное применение правила create_session не допускается. Следовательно, правила, связанные с сущностями-процедурами и сущностями-триггерами, не могут включать правила вида create_session. Кроме того, при применении правил create_procedure(s, с, op, md, op1,..., opk), alter_procedure(s, op, md, op1,..., opk), create_trigger(s, t, ot, m, op1,..., opk) и alter_trigger(s, t, ot, md, op1,..., opk) ни одно из правил op1,..., opk не должно иметь вид create_session.

Замечание ІІ. Допустим, что o Є Op U Ot, operations(o) = (op1,..., opk), где k ^ 0, op Є operations(o), то есть существует i Є {1,... , k}, такое, что op = op^. Следовательно, в соответствии с предположением 5 и замечанием І0 правило op не может иметь вид create_container, create_procedure, alter_procedure, create_trigger, alter_trigger и create_session. Учитывая это, а также то, что op Є OPext по определению функции operations, получаем, что в соответствии c табл. 2 op может иметь вид grant_right, execute_procedure, access_insert, access_update или access_delete.

Замечание І2. Из способа задания внешних правил видно, что владельцем созданной сущности (сущности-триггера, сущности-процедуры или контейнера) становится учётная запись пользователя, от имени которой выполнялась субъект-сессия, инициировавшая её создание. В соответствии с предположением 2 в системе отсутствуют внешние и внутренние правила, позволяющие изменять учётную запись владельца сущности.

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

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

Применение правила access_insert(s, t1, odl,t2,od2) приводит к добавлению сущности-данные odl в таблицу t1, при этом содержимое сущности-данные Od2 копируется во вновь создаваемую сущность-данные odl. При применении правила access_insert выполняется активация всех сущностей-триггеров типа appendr, связанных с таблицей t1 . Необходимым условием применения данного правила является наличие у учётной записи пользователя user(s) прав доступа на чтение к таблице t2, а также права

доступа на запись к целевой таблице t1, в которую выполняется добавление сущности-данные odl.

В результате применения правила access_update(s, t1, odl , t2,od2) выполняется обновление сущности-данные Od1 с использованием данных, содержащихся в сущности-данные Od2. При применении правила access_update выполняется активация сущностей-триггеров типа writer таблицы, содержащей сущность-данные Od1. Необходимым условием применения данного правила является наличие у учётной записи пользователя user(s) прав доступа на чтение к таблице t2, а также права доступа на запись к целевой таблице t1.

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

Замечание І4. Заметим, что условия применения правил access_insert(s, t1, Od1, t2,od2), access_update(s, t1, odl,t2,od2) и access_delete(s, t, od) ослаблены по сравнению с соответствующими внутренними правилами do_insert(s, t1, odl,t2,od2), do_update(s, t1,Od1 ,t2,Od2) и do_delete(s,t,Od). Отличие в условиях применения указанных правил состоит в отсутствии требований, связанных с наличием или отсутствием сущ-ностей-данных в соответствующих таблицах. Необходимым условием применения перечисленных правил остаётся только наличие соответствующих прав доступа к таблицам. Отметим, что указанные ослабления условий применения правил access_insert, access_update и access_delete потенциально могут привести к появлению дополнительных путей распространения прав доступа в системе. Если в дальнейшем будут определены достаточные условия, при выполнении которых невозможно распространение прав доступа, то эти достаточные условия будут применимы и при наличии дополнительных ограничений на условия применения правил.

Замечание ІБ. В соответствии со способом задания применение внешних правил (за исключением access_delete) не приводит к удалению элементов из множеств, являющихся элементами состояния системы E(G*, OP). Учитывая, что в условиях применения правил grant_right, alter_procedure, alter_trigger, execute_procedure, access_insert, access_update и access_delete нет проверок на отсутствие элементов в состоянии системы, отметим, что верно следующее замечание. Если в состоянии G0 системы E(G*, OP) выполнялись условия применения правила op Є OP, являющегося одним из перечисленных выше правил, и существуют правила преобразования состояний op1,... , opk Є OP, где k ^ О, то условия применения правила op Є OPext будут выполняться и в состоянии G/ = G(op1, . . . , opk).

З. Условия передачи прав доступа

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

Утверждение 4. Пусть G0 — состояние системы E(G *, OP), u Є U0, e Є C0 U Opo и пусть ar Є Rr — некоторое право доступа. Тогда существуют состояния G1, ... , Gk, где k ^ О, правила преобразования состояний op1,... , opk, такие, что G0 hopl G1 hop2 ... hopk Gk, (u, e, ar) Є Rek и для каждого i = 1,... , k переход Gi-1 hop. G^ инициирован извне.

Доказательство. Если (и,е,аг) € Яео, то к = 0 и условия утверждения выполнены. Пусть (и,е,аг) € Яео. Заметим, что ввиду Сгоадгао С Сг0 и способа задания множеств Сгоадгао и Сг0(е,аг) выполняется соотношение

{(и,е,аг) : и € ои>пегз0(е)} С Сг0(е,аг). (4)

Так как множество ои’пегз^е) включает, как минимум, учётную запись пользователя о^пег(е), то из (4) следует, что множество Сг0(е,аг) не пусто и существует пользователь и € Сг0(е,аг). Рассмотрим следующую последовательность внешних правил: ор = сгеа^е_5в55гоп(и/, з), ор2 = дгап£_ггдЛ,£(з, и, е, аг, по). Тогда существуют состояния С1 и С2, такие, что С0 Ьор1 С С2. Заметим, что выполнены условия применения правила ор2, так как и/ € Сг0(е,аг), а следовательно, изег^з) = и/ € € Сг1(е,аг) = Сг0(е,аг). Отсюда (и, е,аг) € Яе2 и все переходы С0 Ьор1 С1, С1 С2 инициированы извне. ■

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

Заключение

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

ЛИТЕРАТУРА

1. Руководящий документ. Безопасность информационных технологий. Критерии оценки безопасности информационных технологий: в 3 ч. Введён в действие Приказом Гостехкомиссии России от 19.06.02 г. № 187.

2. Девянин П. Н. Модели безопасности компьютерных систем. Управление доступом и информационными потоками: учеб. пособие для вузов. М.: Горячая линия-Телеком, 2011. 320 с.

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

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