Правила преобразования состояний СУБД ДП-модели | ПДМ. 2013. № 1(19).

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

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

Transformation rules for states in the DBMS DP-model.pdf Введение В настоящее время при проектировании, разработке и эксплуатации автоматизированных информационных систем особое значение стали приобретать вопросы обеспечения информационной безопасности. Практика показала, что одной из наиболее важных задач является обеспечение корректности управления доступом, а также анализ условий, приводящих к реализации запрещённых информационных потоков. Для обеспечения возможности поиска, хранения и обработки информации разработчики автоматизированных информационных систем традиционно используют реляционные системы управления базами данных (СУБД). Современные СУБД предоставляют разработчикам прикладных приложений развитые средства управления доступом, которые имеют отличия от механизмов, применяемых в операционных системах (ОС). В соответствии с «Критериями оценки безопасности информационных технологий» [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 G C множество H(c) С E и удовлетворяющую следующим условиям. Условие 1. Пусть P (e) = {c G C : e G H (c)} —множество родительских контейнеров сущности e. Тогда существует единственный корневой контейнер cr G C, такой, что |P(cr)| = 0 и для каждой сущности e G E \ {cr} выполняется |P(e)| = 1. Условие 2. Для каждой сущности e G E либо e = cr, либо существуют контейнеры c1,... , cn G C, где n ^ 1, такие, что c1 = cr, ci+1 G H(q) для i = 1,... , n — 1 и e G H(cn). Условие 3. Пусть T = {c G C : 3e G Od U Ot (e G H (c))} — множество таблиц. Тогда для каждой таблицы t G T по определению выполняется H(t) С Od U Ot. Определение 2. Если для сущности e G E существует контейнер c G C, такой, что e G H(c), то будем говорить, что контейнер c содержит сущность e, а сущность e содержится в контейнере c; также будем говорить, что c является родительским контейнером сущности e, а e — дочерней сущностью контейнера c. Определение 3. Будем говорить, что сущность e G E иерархически подчинена контейнеру c G C, если существуют контейнеры c1,... , cn G C, где n ^ 1, такие, что c1 = c, ci+1 G H (q) для i = 1,..., n — 1 и eG H (cn). В случае, если сущность e E иерархически подчинена контейнеру c C, будем использовать обозначение e < c. В случае, если сущность e G E иерархически подчинена контейнеру c G C или равна ему, будем использовать обозначение e ^ c. Замечание 1. Из определений 1 и 3 следует, что для любой сущности e G E \{cr} существует контейнер c C, такой, что e < c. Кроме того, очевидно, что каждая сущность либо является корневой, либо иерархически подчинена корневой сущности cr и содержится ровно в одном из её дочерних контейнеров. Будем считать необходимым условием равенства сущностей их принадлежность одному контейнеру. Замечание 2. Легко показать, что если для некоторой сущности e G E существуют контейнеры c1,...,cn G C, где n ^ 1, такие, что c1 = cr, ci+1 G H(q) для i = 1,..., n — 1 и eG H (cn), и контейнеры d1,...,dn, G C, где n' ^ 1, такие, что d1 = c. r ; c'+1 G H(ci) для i = 1,..., n' — 1 и e G H(dn,), то n = n' и ci = c для i = 1,..., n, то есть для любой некорневой сущности e G E существует единственная последовательность, начинающаяся с cr и заканчивающаяся контейнером, содержащим e, такая, что каждый её элемент является родительским для последующего. Используем также следующие обозначения и определения: U — множество учётных записей пользователей, при этом считается, что учётные записи пользователей по определению не являются сущностями, то есть E П U = 0; S — множество субъект-сессий пользователей, при этом считается, что S П U = 0 и S П E = 0; user: S ^ U — функция, задающая для каждой субъект-сессии учётную запись пользователя, от имени которой она выполняется; assoc/(s): S ^ Op U Ot U {0} — функция, задающая для каждой субъект-сессии s G S функционально ассоциированную с ней сущность; owner: E ^ U — функция, задающая для каждой сущности учётную запись её владельца, при этом для каждой таблицы t G T и каждой сущности e G H(t) по определению выполняется равенство owner(e) = owner (t); owners: E ^ 2U — функция, задающая для каждой сущности учётные записи её иерархических владельцев, при этом для каждой сущности e G E по определению u G owners(e) тогда и только тогда, когда либо u = owner(e), либо существует контейнер c G P(e), такой, что u G owners(c); execute_as: Op U Ot ^ {as_ca//er, as_owner} — функция, задающая для каждой сущности-процедуры и сущности-триггера режим их выполнения субъект-сессиями (as_ca//er соответствует режиму выполнения сущности от имени учётной записи пользователя, инициировавшей её запуск, а as_owner — от имени учётной записи владельца сущности); Rr = {readr ,writer, appendr, de/eter, a/terr, executer} — множество видов прав доступа к контейнерам и сущностям-процедурам; Ot* —множество всех конечных последовательностей сущностей-триггеров. Определение 4. Определим triggers: T х {writer, appendr, de/eter} ^ O^ — функцию, задающую для каждой таблицы связанную с ней последовательность сущностей-триггеров и удовлетворяющую следующим условиям. Условие 1. Для каждой таблицы t G T и каждого права доступа ar G {writer, appendr, de/eter} выполняется triggers(t, ar) С H(t). Условие 2. Для каждой сущности-триггера ot G Ot существует единственная таблица t G T и единственное право доступа ar G {writer, appendr, de/eter}, такое, что ot G triggers(t,ar). Если существуют таблица t G T, право доступа ar G {writer, appendr, de/eter} и сущность-триггер ot G triggers(t, ar), то будем говорить, что сущность-триггер ot имеет тип ar и связана с таблицей t. Введём также следующие обозначения: R С U х (CUOp) х Rr — множество непосредственно заданных прав доступа учётных записей пользователей к контейнерам и сущностям-процедурам; Rown = {(u,e,ar) : ar G Rr, e G C U Op,u = owner(e)} —множество прав доступа учётных записей пользователей — владельцев контейнеров и сущностей-процедур; RH = {(u, e, ar) : u G U, e G C U Op, ar G Rr, 3c G C((u, c, ar) G R U Rown & e < c)} — множество иерархических прав доступа учётных записей пользователей к контейнерам и сущностям-процедурам; Re = R U Rown U Rh — множество действующих прав доступа учётных записей пользователей к контейнерам и сущностям-процедурам; Gre = Gr U Grown — множество действующих прав на предоставление прав доступа к контейнерам и сущностям-процедурам, при этом множества Gr и Grown задаются следующим образом: Gr С U х (C UOp)xRr — множество непосредственно заданных прав на предоставление прав доступа к контейнерам и сущностям-процедурам, удовлетворяющее условию Gr С Re; Grown = {(u,e,ar) : u G U, ar G Rr, e G C U Op,u G owners(e)} — множество прав доступа на предоставление прав доступа иерархическими владельцами контейнеров и сущностей-процедур; Gr(e, ar) = {u G U : (u, e, ar) G Gre}, где e G C U Op, ar G Rr — множество учётных записей пользователей, которые могут предоставлять право доступа ar G Rr к сущности e C U Op; OPint — множество внутренних правил преобразования состояний, заданных в табл. 1; OPext — множество внешних правил преобразования состояний, заданных в табл. 2; OP = OPint U OPext — множество правил преобразования состояний; OPe*xt — множество всех конечных последовательностей внешних правил преобразования состояний; OP* —множество всех конечных последовательностей правил преобразования состояний; operations: Op U Ot ^ OPe*xt — функция, задающая для каждой сущности-процедуры и сущности-триггера соответствующие им последовательности внешних правил преобразования состояний, реализуемых при выполнении субъектами-сессиями их SQL-кода; time G N0 — счётчик моментов времени, значение которого увеличивается на единицу при реализации каждого правила op G OP; tr G OP * —последовательность всех применённых правил, начиная с нулевого момента времени, непосредственная реализация которых привела к изменению значения счётчика времени; G = (U, S, E, R, Gr, H, user, assoc/, owner, execute_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 не содержит элементов. Поясним введённые обозначения и определения. Сущности-данные модели соответствуют записям таблиц СУБД. В отличие от реальных СУБД считается, что у записей таблиц отсутствует внутренняя структура, то есть нет отдельных полей. Причина подобного подхода к рассмотрению записей состоит в том, что в большинстве современных СУБД отсутствуют механизмы контроля доступа не только на уровне полей записей таблиц, но и на уровне отдельных записей таблиц. Следовательно, построение формальных моделей управления доступом к отдельным полям записей таблиц для современных СУБД не является актуальной задачей. Внутренние правила преобразования состояний СУБД ДП-модели Таблица 1 Правило Исходное состояние G Результирующее состояние G' switches, o, u, op) s G S,u G U, o G Op U Ot U{0}, op G 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 G S,u G U, o G Op U Ot U {0} G'{user', assocf ,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 G S,o G Op U Ot, op G OPext, operations(o) = = (opi^. .,opk), k > 0, Vi G 1, k opi G 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 G S, ti, t2 G T,u = user(s), od! G Od,od2 G H(t2) G'{E', H', time', tr'} - G, E' = O' U C, O' = O U {od!}, H'{ti ^ H(ti) U {od!}} - H, time' = time + 1, tr' = (tr, do insert(s, ti, odt, t2, od2)) do update (s,t1,odl ,t2,od2) s G S, ti, t2 G T,u = user(s), od! G H(ti), od2 G H(t2) G'{time', tr'} — G, time' = time + 1, tr' = (tr, do update(s,ti,odt ,t2,od2)) do deleters, t,od) s G S, t G T,u = user(s), od G 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 G U, s g 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, , with grant) s G S, u G U, e G C U Op, ar G Rr, user(s) G Gr(e, ar), with grant G {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 G S,cpG C,c G C, (user(s), cp, alterr) G 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) sGS,cGC \ T, op G Op, md G {as caller, as owner}, k > 0, Vi G 1, k opi G OPext, (user(s), c, alterr) G 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 3 1 2 seS, op e Op, md € {as_caller, as_owner}, к > 0, Vi € 1, k opj € OPext, (user(s), op, alterr) € Де alter _procedure (s, op, md, opi,. .., opk) 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)) s € S, t € T, ot € Ot, ar € Rr, md € {as_caller, as_owner}, к > 0, Vi € 1, к opj € 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)) create_trigger (s, t, ot, ar, md, opi,..., opk) s e S,t eT,ot e Ot, md € {as_caller, as_owner}, к > 0, Vi € 1, к opi € OPext, (user(s),t, alterr) € Re, ot H(t) alter _trigger (s, t, ot, md, opi,..., opk) 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)) G' = G(execute(s, op, execute_procedure(s, op))) execute _procedure (s, op) s S, op Op, (user(s), op, executer) € Re s € S, ti, t2 € T, u = user(s), (u, ti, writer) Re, (u, t2, readr) € Re, trigger s(ti,appendr) = = (ot,i,..., ot,k), к > 0, Vi € 1, к ot i € Ot access_insert (s,ti,odl ,t2,od2) G' = G(do _insert(s,ti, odl ,t2, od2), execute(s, ot,i, access _insert(s,ti, odl ,t2, od2)), execute(s, ot,k, access_insert(s, ti, odl, t2, od2))) s € S, ti, t2 € T, u = user(s), (u, ti, writer) Re, (u, t2, readr) € Re, triggers(ti,writer) = = (ot,i,..., ot,k), к > 0, Vi 1, к ot,i Ot access_update (s,ti,odi ,t2,od2) 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))) s € S, u = user(s), (u,t,deleter) € Re, triggers(t, deleter) = = (ot,i,..., ot,k), к > 0, Vi 1, к 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))) access _delete (s, t, od) Множество контейнеров реальных реляционных СУБД включает такие сущности как экземпляр СУБД, экземпляры баз данных, схемы и таблицы. При этом иерархия сущностей на этом множестве контейнеров задаётся неявно. Как правило, с экземпляром СУБД связаны экземпляры баз данных, которые, в свою очередь, содержат схемы данных, являющиеся контейнерами для хранимых процедур, а также таблиц вместе с содержащимися в них записями и триггерами. Будем считать, что корневой контейнер cr, у которого отсутствуют родительские контейнеры, соответствует экземпляру СУБД. В отличие от реальных СУБД, модель не накладывает ограничений на число уровней вложенности в иерархии. Помимо корневого контейнера cr, в рамках модели выделяется особый вид контейнеров— таблицы. Согласно условию 3 определения 1, для каждой таблицы t e T выполняется H(t) С U Ot, из чего следует, что таблицы не могут иметь дочерних контейнеров и содержат только сущности-данные и сущности-триггеры. Обоснуем следующее утверждение. Утверждение 1. Если |C | > 1, то cr G T. Доказательство. Предположим противное, то есть cr G T. Из условия утверждения следует, что существует c G C, c = cr. Тогда по условию 2 определения 1 существуют контейнеры c1,... , cn, где n ^ 1, такие, что c1 = cr, ci+1 G H (c) для i = 1,... , n — 1 и cG H (cn). Это означает, что существует контейнер c' G C, такой, что c' G H(cr), причём c' G Od U Ot, так как O П C = 0. По предположению корневой контейнер cr является таблицей, следовательно, по условию 3 определения 1 выполняется H(cr) С Od U Ot. Отсюда одновременно имеет место c' G H(cr) С Od U Ot и c' G Od U Ot. Пришли к противоречию, следовательно, корневой контейнер cr не является таблицей. ■ В замечании 1 отмечается, что для каждой сущности за исключением корневой существует единственный контейнер, в котором она содержится. Кроме того, в соответствии с условием 3 определения 1 в множество таблиц включаются все контейнеры, содержащие хотя бы одну сущность-данные или сущность-триггер. Следовательно, для каждой сущности-данные и сущности-триггера e G Od U Ot существует ровно одна таблица t G T, в которой она содержится, то есть e G H(t). Сущности-триггеры соответствуют триггерам таблиц в СУБД, SQL-код которых автоматически выполняется при осуществлении операций вставки, удаления и обновления записей таблиц, с которыми они связаны. Каждая сущность-триггер имеет тип, задаваемый функцией triggers и соответствующий определённому виду доступа. Реализация субъект-сессией доступа вида ar G {writer, appendr, de/eter} к таблице t G T автоматически инициирует выполнение ею SQL-кода всех триггеров из последовательности triggers(t, ar). Сущности-процедуры соответствуют хранимым процедурам СУБД, выполнение SQL-кода которых может быть инициировано в рамках взаимодействия с системой. В реальных СУБД хранимые процедуры могут находиться только в схемах данных. В рамках модели считается, что сущности-процедуры могут находиться в любом контейнере, не являющемся таблицей. Считается, что сущности-триггеры и сущности-процедуры содержат SQL-код, выполнение которого приводит к реализации преобразований системы, задаваемых правилами, описываемыми в п. 2. В рамках модели предполагается, что сущности-триггеры и сущности-процедуры не содержат динамически генерируемого SQL-кода и условий, а их выполнение приводит к применению фиксированной последовательности правил, задаваемой соответствующим значением функции operations. В реальных системах сущности-процедуры могут принимать формальные параметры. При вызове хранимой процедуры ей передаются фактические значения формальных параметров, что приводит к выполнению некоторой фиксированной последовательности операторов. В рамках модели считается, что каждой хранимой процедуре, принимающей входные параметры, соответствует множество сущностей-процедур. При этом для каждой допустимой комбинации значений фактических параметров задаётся отдельная сущность-процедура, содержащая SQL-код, являющийся результатом их подстановки в операторы хранимой процедуры. Если внутри хранимой процедуры имеются операторы вызова других хранимых процедур, принимающих параметры, то каждый такой вызов заменяется оператором активации соответствующей сущности-процедуры, полученной подстановкой фактических параметров. Субъект-сессии соответствуют сессиям пользователей с СУБД, которые, в отличие от процессов ОС, не являются объектами доступа и потому не считаются сущностями. Субъект-сессии инициируют выполнение SQL-кода, что приводит к реализации заданных в нём преобразований состояний системы. SQL-код может либо относиться к одной из сущностей-процедур или сущностей-триггеров, либо не относиться ни к одной из них. Считается, что SQL-код содержит инструкции, выполнение которых непосредственно приводит к применению внешних правил из множества OPext. При этом предполагается, что SQL-код не может содержать инструкции, выполнение которых непосредственно приводит к применению внутренних правил из множества OPint. Выполнение внутренних правил инициируется опосредованно как составная часть преобразований системы, задаваемых внешними правилами. Например, выполнение SQL-кода сущностей-триггеров осуществляется только при применении внешних правил, связанных со вставкой, удалением и обновлением сущностей-данных таблиц. Традиционно для сущностей, функционально-ассоциированных с субъект-сессией s, используется обозначение [s]. Необходимость во введении нового обозначения assoc/ (s) обусловлена тем, что в отличие от других моделей полагается, что в каждый момент времени множество функционально-ассоциированных с субъект-сессией s сущностей assoc/ (s) либо содержит ровно одну выполняемую им в текущий момент времени сущность-триггер или сущность-процедуру, либо не содержит элементов. Последнее означает, что субъект-сессия выполняет SQL-код, который не относится ни к одной сущности-процедуре или сущности-триггеру. В последнем случае считается, что выполнение такого SQL-кода эквивалентно непосредственному применению субъект-сессией правил преобразования состояний из множества OPext. В дальнейшем будем полагать, что по определению выполняется равенство [s] = assoc/ (s). Субъект-сессии применяют правила преобразования состояний системы от имени учётных записей пользователей из множества U. В реальных СУБД для создания новой сессии требуется указать в строке подключения данные, аутентифицирующие подключающегося пользователя. Изначально субъект-сессия начинает применять внешние правила от имени учётной записи пользователя, инициировавшей её создание. Однако при переходе системы из состояния в состояние допускается изменение значений функции user, что связано с наличием в реальных СУБД возможности выполнения кода хранимых процедур и триггеров от имени учётной записи пользователя, не являющегося инициатором их выполнения. Отметим, что возможность изменения значений функции user является существенным отличием от моделей ролевого управления доступом и ДП-моделей, в которых предполагается неизменность её значений. Функция owner введена в модель в связи с тем, что в современных СУБД владельцы сущностей-контейнеров неявно получают все возможные права доступа как к самому контейнеру, так и ко всем его иерархически подчиненным сущностям. Из определения функции owner следует, что владельцем сущностей-данных и сущностей-триггеров является владелец содержащей их таблицы. Это отражает тот факт, что в реальных СУБД у записей таблиц и триггеров не существует непосредственно задаваемой учётной записи владельца. Предположение 2. Для любой сущности e учётная запись пользователя владельца owner (e) после создания сущности e не изменяется. Функция owners задаёт для каждой сущности учётные записи всех её иерархических владельцев, которые обладают к ней всеми возможными правами доступа. При этом справедливо следующее Утверждение 2. Для каждой сущности e G E выполняется равенство owners(e) = {u G U : 3c G C (e 1 и равенство owners'(e) = owners(e) выполняется для всех k < n. Заметим, что из (1) следует owners'(e) = owners'(cn) U {owner(e)}. Число элементов в последовательности c1,... , cn-1 меньше, чем n, и, следовательно, по предположению индукции owners'(cn) = owners (cn). Таким образом, верно равенство owners'(e) = owners(cn) U {owner(e)}. (3) Пусть u € owners(e). Из способа задания функции owners следует, что возможны два случая: либо u = owner(e), либо существует контейнер c € P(e), такой, что u € owners(c). Если u = owner(e), то из (3) следует u e owners'(e). Рассмотрим случай u = owner(e). Так как c e P(e) и e e H(cn), то c = cn, а следовательно, u e owners(cn). Тогда из равенства (3) видно, что u e owners'(e). Пусть u € owners'(e). Из (3) следует, что возможны два случая: u = owner(e) и u e owners(cn). Если u = owner(e), то из способа задания функции owners следует u € owners(e). Рассмотрим случай u € owners(cn). Ввиду e € H(cn) имеем cn € P(e). Таким образом, cn € 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_caller, то код сущности e будет выполняться от имени учётной записи user(s), в противном случае, если execute_as(e) = as_owner, то код сущности e будет выполняться субъект-сессией s от имени учётной записи владельца сущности e, то есть от имени учётной записи пользователя owner(e). Отметим, что режим выполнения as_owner соответствует механизму повышения полномочий SUID в ОС семейства UNIX, а режим as_caller — механизму имперсонации (олицетворения) в ОС семейства Windows. Замечание 3. Присутствующий в реальных СУБД режим выполнения сущностей-процедур и сущностей-триггеров от имени фиксированной учётной записи в рамках модели не рассматривается. Виды прав доступа из множества Rr соответствуют по смыслу и назначению традиционным для СУБД правам доступа SELECT, UPDATE, INSERT, DELETE, ALTER и EXECUTE. Большинство современных СУБД реализуют, как минимум, дискреционное управление доступом учётных записей пользователей к контейнерам и сущностям-процедурам. При этом для упрощения процедуры администрирования прав доступа в СУБД поддерживается управление правами учётных записей пользователей с учётом иерархических отношений между сущностями, а также выполняется неявное предоставление всех возможных прав доступа учётным записям владельцев сущностей. При определении возможности применения правил преобразования состояний в модели учитываются права доступа, содержащиеся в множестве действующих прав доступа учётных записей пользователей Re. Полагается, что субъект-сессии s, функционирующей от имени учётной записи пользователя user(s) = u, разрешено реализовать доступ вида ar к сущности e в случае, если (u,e,ar) G Re. Множество действующих прав доступа Re включает множество непосредственно заданных прав доступа R, множество прав доступа учётных записей владельцев Rown, а также множество иерархических прав доступа rh . Из способа задания множества Rown следует, что учётная запись владельца сущности обладает к ней всеми правами доступа. Кроме того, из способа задания множества rh следует, что учётная запись пользователя, имеющего непосредственно заданное право доступа ar к контейнеру c либо являющегося его владельцем, также обладает этим правом доступа и к любому его иерархически подчинённому контейнеру и сущности-процедуре. Таким образом, верно следующее замечание. Замечание 4. Если u G U, e,e' G C U Op, ar G Rr, e ^ e' и (u,e',ar) G Re, то (u, e, ar) G Re. Заметим, что множества прав доступа Rown, 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 € C, такой, что e < c и u = owner(c). Так как u = owner(c), то по способу задания множества Rown выполняется (u, c, ar) € Rown. Таким образом, выполняется u € U, e € C U Op, ar € Rr и существует контейнер c € C, такой, что (u,c, ar) € Rown и e < c. Следовательно, согласно способу задания множества RH, выполняется (u,e,ar) € RH С Re. ■ 2. Правила преобразования состояний Будем использовать запись вида G'{I1,... , Ik} ~ G для обозначения того, что все элементы состояния G' равны соответствующим элементам состояния G, за исключением элементов Tj,...,/' состояния G'. Будем также использовать запись вида /'{ж1,... , Xfc} ~ / для обозначения того, что значения функции / '(x) равны значениям функции /(x) для всех аргументов x, за исключением x1,... , xk. Кроме того, будем использовать запись вида /'{x1 м- y1,...,x k м- yk} ~ / для обозначения того, что значения функции /'(x) равны значениям функции / (x) для всех аргументов x, кроме x1,... ,xk, и при этом /'(x1) = y1, ..., /'(xk) = 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 Ь^ . . . hopk Gk и G' = Gk. В СУБД ДП-модели определены приведённые в табл. 1 и 2 правила преобразования состояний из множества OP, в которых учтены особенности управления доступом в современных СУБД. Поясним приведённые в табл. 1 условия и результаты применения внутренних правил преобразования системы. В отличие от внешних правил, внутренние правила применяются субъект-сессиями опосредованно в ходе выполнения SQL-кода как составная часть преобразований системы, задаваемых внешними (см. описание правил execute_procedure, access_insert, access_update и access_de/ete в табл. 2) или другими внутренними правилами (см. описание правила execute). Запись вида (tr, op), использованная при определении нового значения tr', означает, что в возможно пустую последовательность tr добавляются данные о применяемом правиле op. В результате применения внутреннего правила switch(s, o, u, op) в качестве учётной записи, от имени которой функционирует субъект-сессия s, устанавливается u, а o становится функционально-ассоциированной с s сущностью. Параметр op G OPext задаёт внешнее правило, в результате применения которого было инициировано выполнения правила switch(s, o, u, op). Правило revert(s, u, o) предназначено для восстановления состояния субъект-сессии s до активации ею сущности-триггера или сущности-процедуры. В результате применения правила revert(s, u, o) в качестве учётной записи, от имени которой функционирует субъект-сессия s, устанавливается u, а o становится функционально-ассоциированной с s сущностью. Внутреннее правило execute(s, o, op) задаёт состояние системы после выполнения SQL-кода, содержащегося в сущности-процедуре или сущности-триггере o G Op U Ot субъект-сессией s G S. Перед выполнением SQL-кода сущности o производится изменение учётной записи пользователя, от имени которой субъект-сессия s будет последовательно применять внешние правила op1,..., op^. Учётная запись пользователя устанавливается в соответствии с режимом выполнения кода сущности-процедуры или сущности-триггера o, задаваемой значением функции execute_as(o). Кроме того, перед выполнением SQL-кода сущности o в качестве функционально-ассоциированной с субъект-сессией s сущностью устанавливается сущность o. После завершения описанных подготовительных действий производится выполнение SQL-кода сущности o, что приводит к реализации преобразований состояний системы, задаваемых последовательностью правил operations(o) = (op1,...,op^). После выполнения кода производится восстановление исходной функционально-ассоциированной сущности с субъект-сессией s, а также учётной записи, от имени которой она выполнялась до применения внутреннего правила execute(s, o, op). Параметр op G OPext задаёт внешнее правило, в результате применения которого было инициировано выполнение правила execute(s, o, op). Применение внутреннего правила do_insert(s, t1, odl, t2,od2) приводит к добавлению сущности-данные odl в таблицу t1, при этом содержимое сущности-данные o^2 копируется во вновь создаваемую сущность-данные odl. Применение внутреннего правила do_update(s, t1, odl, t2, od2) приводит к замене содержимого сущности-данные odl на содержимое сущности-данные od2. Внутреннее правило do_de/ete(s, t, od) позволяет активировавшей его субъект-сессии s выполнить удаление сущности-данные od из содержащей её таблицы t. В табл. 2 приведены внешние правила преобразования состояний из множества OPext, которые могут быть непосредственно применены субъект-сессиями. Поясним приведённые в табл. 2 условия и результаты применения внешних правил преобразования состояний. В результате применения правила create_session(u, s) создаётся новая субъект-сессия s, которая в дальнейшем может выполнять действия от имени учётной записи пользователя u U. Предположение 3. Будем считать, что все правила из табл. 1 и 2, за исключением правила create_session(u, s), получают в качестве первого параметра субъект-сессию, инициировавшую выполнение данного

Ключевые слова

компьютерная безопасность, СУБД ДП-модель, система управления базами данных, computer security, DBMS DP-model, database management system

Авторы

ФИООрганизацияДополнительноE-mail
Смольянинов Владимир ЮрьевичУчебно-методическое объединение по информационной безопасности (г. Москва)научный сотрудникVladimirSmall@gmail.com
Всего: 1

Ссылки

Руководящий документ. Безопасность информационных технологий. Критерии оценки безопасности информационных технологий: в 3 ч. Введён в действие Приказом Гостехкомиссии России от 19.06.02 г. № 187.
Девянин П. Н. Модели безопасности компьютерных систем. Управление доступом и информационными потоками: учеб. пособие для вузов. М.: Горячая линия-Телеком, 2011. 320 с.
Колегов Д. Н. Дискреционная модель безопасности управления доступом и информационными потоками в компьютерных системах с функционально или параметрически ассоциированными сущностями: дис.. канд. техн. наук. Томск, 2009.
Девянин П. Н. Ролевая ДП-модель управления доступом и информационными потоками в операционных системах семейства Linux // Прикладная дискретная математика. 2012. №1(15). С. 69-90.
 Правила преобразования состояний СУБД ДП-модели | ПДМ. 2013. № 1(19).

Правила преобразования состояний СУБД ДП-модели | ПДМ. 2013. № 1(19).

Полнотекстовая версия