Основные элементы мандатной сущностно-ролевой ДП-модели управления доступом и информационными потоками в СУБД PostgreSQL оС специального назначения Astra Linux Special Edition Текст научной статьи по специальности «Компьютерные и информационные науки»

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

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

УДК 004.94

ОСНОВНЫЕ ЭЛЕМЕНТЫ МАНДАТНОЙ СУЩНОСТНО-РОЛЕВОЙ ДП-МОДЕЛИ УПРАВЛЕНИЯ ДОСТУПОМ И ИНФОРМАЦИОННЫМИ ПОТОКАМИ В СУБД POSTGRESQL ОС СПЕЦИАЛЬНОГО НАЗНАЧЕНИЯ ASTRA LINUX SPECIAL EDITION

А. В. Шумилин

ОАО «НПО РусБИТех», г. Москва, Россия

E-mail: a.shumilin@rusbitech.ru

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

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

1. Введение. Необходимость адаптации модели. Этапы разработки

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

В настоящее время осуществляются попытки построения современных формальных моделей, объединяющих все аспекты дискреционного, мандатного и ролевого

управления доступом с учётом безопасности информационных потоков, для применения в реальных защищённых ОС. Например, при создании перспективной операционной системы специального назначения (ОС СН) Astra Linux Special Edition используется мандатная сущностно-ролевая ДП-модель управления доступом и информационными потоками в операционных системах семейства Linux [3 - 5].

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

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

В настоящее время для обеспечения единого подхода к управлению доступом в СУБД и ОС СН Astra Linux Special Edition автором осуществляется адаптация МРОСЛ ДП-модели с учетом специфики реляционных баз данных. В ходе работы использовались как классические базовые модели управления доступом семейства RBAC [6, 7], так и современные результаты теоретического моделирования управления доступом в СУБД [8, 9]. Кроме того, учитывались подходы к реализации управления доступом в СУБД Oracle, SQL Server и PostgreSQL, базирующиеся на требованиях стандарта SQL [10-13].

Целесообразность адаптации МРОСЛ ДП-модели и построения на её основе новой PostgreSQL ДП-модели связана со следующими особенностями управления доступом к данным, хранящимся и обрабатываемым в СУБД:

— первичная субъект-сессия СУБД создается субъект-сессией ОС;

— в качестве множества сущностей рассматриваются объекты реляционных баз данных;

— доступ к данным осуществляется с помощью языка запросов SQL;

— множество видов доступа, прав доступа и правила распространения прав доступа регламентируются стандартом SQL;

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

Применение специальных моделей управления доступом в СУБД наряду с реализацией выполнения заданных требований по защите информации должно обеспечивать без потери производительности сохранение неотъемлемых качеств СУБД, таких, как:

— целостность и согласованность данных;

— управление данными и их структурой с помощью языка запросов;

— резервное копирование и восстановление.

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

Создание эффективных механизмов управления доступом в реляционных СУБД требует не только хорошего знания реализуемых формальных моделей, но и детального анализа архитектуры и особенностей функционирования реальных систем обработки данных [14-17].

В связи со сложностью решение поставленной задачи выполняется поэтапно.

На первом этапе произведён анализ существующих механизмов управления доступом в рассматриваемой СУБД и возможности использования элементов МРОСЛ ДП -модели.

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

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

2. Элементы модели (описание состояния системы)

При разработке PostgreSQL ДП-модели были взяты за основу элементы МРОСЛ ДП-модели, задающие мандатное и ролевое управление доступом и информационными потоками. При этом для упрощения не рассматривались системы ограничений ролевого управления доступом и мандатный контроль целостности, которому соответствуют некоторые механизмы современных ОС (MIC — Mandatory Integrity Control и UAC — User Account Control в ОС семейства Microsoft Windows).

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

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

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

В отличие от файловой системы ОС, иерархия объектов в СУБД носит более детерминированный характер, так как имеет ограниченную степень вложенности разнотипных объектов (например, база данных/схема/таблица/запись). Это позволяет привнести в модель элементы типизированной матрицы доступа, так как каждая операция SQL содержит информацию о типе объекта. Таким образом, PostgreSQL ДП-модель была расширена соответствующими определениями иерархии типов сущностей. Используем следующие обозначения (аналогичные применяемым в исходной МРОСЛ ДП-модели и работах [3, 8, 9]):

— E = O U C — множество сущностей, где O — множество объектов, а C — множество контейнеров и O П C = 0;

— S — множество субъект-сессий пользователей;

— T — множество типов сущностей;

— type : E ^ T — функция типов сущностей (по аналогии с [8]);

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

— AR — множество административных ролей, при этом по определению AR П R = 0;

— HR : R U AR ^ 2r U 2ar — функция иерархии ролей и административных ролей;

— U — множество учётных записей пользователей, при этом учётные записи в PostgreSQL являются подмножеством ролей, т. е. U С R U AR;

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

— Ra = {reada, writea, appenda} — множество видов доступа;

— Rf = {writem,writet} —множество видов информационных потоков (по памяти и по времени);

— Rr —множество видов прав доступа, элементы которого с учётом специфики рассматриваемой СУБД будут определены далее;

— Rraf = Rr U Ra U Rf — множество видов прав доступа, видов доступа и видов информационных потоков, при этом множества Rr, Ra и Rf попарно не пересекаются;

— P С E х Rr — множество прав доступа к сущностям;

— PA : R U AR ^ 2Р — функция прав доступа к сущностям ролей и административ-

ных ролей;

— F С (E U R U AR) х (E U R U AR) х Rf —множество информационных потоков;

— A С S х E х Ra — множество доступов субъект-сессий к сущностям;

— AA С S х (R U AR) х Ra — множество доступов субъект-сессий к ролям или административным ролям;

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

— Nj — множество учётных записей недоверенных пользователей, при этом по опре-

делению справедливы равенства Lj U Nj = U, Lj П Nj = 0;

— Ls — множество доверенных субъект-сессий;

— Ns — множество недоверенных субъект-сессий, при этом по определению справедливо равенство Ls П Ns = 0.

Сохранены все определения исходной модели, касающиеся мандатного контроля конфиденциальности:

— (LC, ^) —решётка многоуровневой безопасности уровней конфиденциальности;

— (fu, fe, fr, fs) G FC — четвёрка функций уровней конфиденциальности:

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

— fe : E ^ LC — функция, задающая уровень конфиденциальности для каждой сущности;

— fr : R U AR ^ LC — функция, задающая для каждой роли или административной роли её уровень конфиденциальности;

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

— CCR : E U R U AR ^ {true, false} — функция, задающая способ доступа к сущностям внутри контейнеров или ролям в иерархии ролей (с учётом их мандатных уровней конфиденциальности).

Для учёта специфики PostgreSQL дополнительно детализируем состав сущностей, их типов, а также соответствующие функции иерархии:

O — Od U Ocol U Oproc U Otrg U O cnstr U Otyp U Oseq U Oblob U Orule U Ospc U Oglob,

где Od — множество сущностей данных, соответствующих записям таблиц; Ocol — множество столбцов; Oproc — множество хранимых процедур; Otrg —множество триггеров; Ocnstr — множество ограничений целостности; Otyp — множество используемых в СУБД типов данных; Oseq — множество последовательностей; Oblob — множество больших двоичных объектов; Orule — множество правил преобразования (RULE); Ospc — множество табличных пространств (TABLESPACE); Oglob — множество глобальных объектов (CAST, EXTENSION, FOREIGN DATA WRAPPER, FOREIGN SERVER, LANGUAGE);

— coltype : Ocol ^ Otyp — функция типов столбцов, сопоставляющая каждому столбцу его тип данных (домен);

— c = Cd u Cdb u Cnsp u Crel,

где Cdb — множество контейнеров, соответствующих базам данных; Cnsp — множество схем; Crel — множество отношений, включающих таблицы и представления (далее — таблицы); Ccl —множество кластеров СУБД PostgreSQL. Кластер является в модели корневым контейнером, в котором располагаются глобальные объекты, такие, как базы данных, табличные пространства, глобальные описания и роли (субъекты);

— T = {cl, spc, db,nsp,rel, col,proc,trg, cnstr, typ, seq, blob, rule, glob, d} —множество

типов сущностей СУБД (соотносятся с одноимёнными индексами сущностей);

— Ht : T ^ 2T — функция иерархии типов сущностей СУБД (сопоставляющая каждому типу сущности множество типов сущностей Ht(t) С T, которые в ней могут содержаться согласно особенностям реализации СУБД PostgreSQL), такая, что:

— если t G {cl, db, nsp, rel}, то HT(t) = 0;

— если t = cl, то HT(t) = {db, spc};

— если t = db, то HT(t) = {nsp, blob, glob};

— если t = nsp, то HT(t) = {rel,proc, type, seq};

— если t = rel, то HT(t) = {d, col,trg, cnstr, type, rule};

— He : E ^ 2E — функция иерархии сущностей (сопоставляющая каждой сущности e G E множество сущностей He(e) С E, непосредственно в ней содержащихся), удовлетворяющая условиям:

— если сущность e G He (c), то e < c и не существует сущности-контейнера d G C, такой, что e < d, d < c;

— для любых сущностей e1,e2 G E, el < e2, выполняется HE(eA) П HE(e2) = 0;

— для любых сущностей e1,e2 G E, el < e2, выполняется type(el) G HT(type(e2)) (контроль по типу сущностей);

— если o G O, то справедливо равенство He(o) = 0.

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

Отличие предлагаемой модели заключается в том, что в ней, опираясь на существующие модели ролевого управления доступом, делается попытка сочетать исходную МРОСЛ ДП-модель с требованиями стандарта на язык запросов SQL [12, 13]. Несмотря на введённое разделение ролей на административные и неадминистративные, управление правами доступа и ролями сохраняется согласно реализации PostgreSQL.

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

С учётом специфики СУБД PostgreSQL зададим множество видов прав доступа:

— Rr = {selectr ,updater, insertr, deleter ,truncater, referencesr ,triggerr, creater ,usager, connectr, executer, createdbr, loginr, createroler, superuserr, ownr}.

В отличие от [9], вместо функции owner для задания владельца сущности используется принятое в ДП-моделях [7] право доступа владения ownr, так как оно точнее отражает специфику работы механизмов разграничения доступа в СУБД PostgreSQL. При этом выполняются следующие условия:

— в каждый отдельный момент времени только одна роль может обладать правом владения к конкретной сущности;

— роль, создавшая сущность, автоматически получает право владения к ней;

— принадлежащие таблице объекты (доступ к которым явно не управляется) считаются принадлежащими владельцу таблицы, т. е. для t G Crel, e G He(t), r G R U AR выполняется условие: если (t, ownr) G PA(r), то (e, ownr) G PA(r);

— для глобальных объектов, не имеющих владельца (кластер, CAST и т. п.) наличие права доступа superuserr эквивалентно наличию права доступа владения ownr;

— Rck = {createdbr,loginr,createroler,superuserr} — множество видов прав доступа, применимых к кластеру;

— Rdb = {creater,usager,connectr,ownr} —множество видов прав доступа, применимых к базе данных;

— Rspc = {creater, ownr} —множество видов прав доступа, применимых к табличному пространству;

— Rnsp = {creater ,usager ,ownr} —множество видов прав доступа, применимых к схеме;

— Rrel = {selectr ,updater ,insertr, deleter ,truncater, referencesr ,triggerr, ownr } — множество видов прав доступа, применимых к таблицам;

— Rcol = {selectr,updater, insertr, referencesr} —множество видов прав доступа, применимых к столбцам таблиц;

— Rseq = {selectr,updater,usager,ownr} — множество видов прав доступа, применимых к последовательностям;

— Rtype = {usager ,ownr} —множество видов прав доступа, применимых к типам и доменам;

— Rproc = {executer ,ownr} — множество видов прав доступа, применимых к процедурам;

— Rblob = {selectr,updater,ownr} — множество видов прав доступа, применимых к большим двоичным объектам;

— ALLr : E ^ 2Rr —функция применимых к сущности видов прав доступа, такая, что для каждой e G E по определению справедливо ALLr(e) = Raa G type(e).

В СУБД PostgreSQL в каждый момент времени субъект-сессия может исполняться только с одной активной ролью. Активация другой роли (SET ROLE) в модели рассматривается как инициация новой субъект-сессии. Согласно стандарту SQL, сессия в случае наличия активной роли исполняется от её имени, в противном случае — от имени роли учётной записи пользователя, её активизировавшего (функция user). В отличие от [9], вводится функция role:

— role : S ^ R U AR — функция принадлежности субъект-сессии роли, задающая для каждой субъект-сессии активную роль, с которой она выполняется.

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

В СУБД существуют следующие особенности применения доступов субъект-сессии к сущностям как в отношении пользовательских данных, так и в отношении системных объектов (метаданных):

— для ролей рассматриваются только доступы на чтение и запись, так как в СУБД PostgreSQL отсутствует понятие владельца роли, при этом доступом на запись к роли может обладать только доверенная субъект-сессия;

— для сущностей-контейнеров доступ на чтение позволяет получить список содержащихся в них сущностей, на добавление — возможность создать в них новую сущность, на запись — изменить или удалить сущность в их составе;

— операции по модификации свойств сущностей, в том числе состава таблицы (столбцы, ограничения и т. п.), требуют у субъект-сессии наличия доступного по иерархии права доступа владения;

— операции с записями таблиц приводятся к видам доступа общепринятым образом: SELECT — чтение, INSERT — добавление, UPDATE, DELETE — запись.

По аналогии с СУБД ДП-моделью [9] используем обозначения:

— execute_as : Oproc ^ {as_caller,as_owner} — функция, задающая режим выполнения кода сущности-процедуры p субъект-сессией s при следующих условиях:

— если p G Oproc и execute_as(p) = as_caller, то код исполняется от имени роли role(s);

— если p G Oproc и execute_as(p) = as_owner, то код исполняется от имени роли, непосредственно имеющей право доступа владения к p, т. е. роли r G R U AR, для которой выполняется (p,ownr) G PA(r);

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

— triggers : Crel х {updater,insertr,deleter,truncater} ^ O*rg — функция, задающая для таблицы конечную последовательность триггеров, выполняющихся при реализации к нему права доступа определённого вида.

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

— trigger_proc : Otrg ^ Oproc — функция, задающая для триггера реализующую его процедуру.

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

— rules : Crel х {selectr,updater,insertr,deleter} ^ O*ule — функция, задающая для таблицы конечную последовательность правил, выполняющихся при реализации к ней права доступа определённого вида;

— rule_op : Orule ^ {access_select, access_insert, access_update, access_delete} — функция, задающая для правила таблицы соответствующее правило преобразования состояния модели из набора правил работы с данными в таблице.

Для обеспечения поддержки специальных административных ролей МРОСЛ ДП-модели в PostgreSQL ДП-модели вводятся соответствующие параметры субъект-сессии СУБД, которые наследуются при создании субъект-сессии СУБД от субъект-сессии ОС:

— sop : S ^ {downgrade_admin_sop,...} — функция получения параметров новой субъект-сессии СУБД из субъект-сессии ОС, такая, что при наличии у субъект-сессии ОС доступа на чтение к административным ролям ОС (например, downgrade_admin_role в МРОСЛ ДП-модели) она отображает их в соответствующие параметры (например, downgrade_admin_sop);

— session_options : S ^ {downgrade_admin_sop,...} — функция, определяющая для каждой субъект-сессии её параметры.

Для описания процесса делегирования прав доступа аналогично [9] введено множество Gr С (R U AR) х P — множество прав доступа на сущности, которые могут быть переданы ролью другой роли. Могут быть переданы только права доступа, которыми роль уже обладает к сущностям, которыми владеет, либо полученные к другим сущностям с опцией WITH_GRANT_OPTION, т. е. Gr(r) С PA(r).

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

— public G R — особая наименьшая в иерархии роль, используемая для задания общих для всех прав доступа, такая, что

— для любой r G R U AR выполняется public G HR(r);

— не существует такой роли r G R U AR, что r < public.

При создании некоторых сущностей ряд видов прав доступа предоставляется всем ролям с помощью PUBLIC (connectr —для баз данных, executer —для процедур и usager — для некоторых глобальных объектов). Состав прав доступа по умолчанию может быть изменён администратором.

В отличие от МРОСЛ ДП-модели, осуществляется возврат к следующим обозначениям:

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

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

Аналогично передаче прав доступа осуществляется и управление иерархией ролей. Для описания этого процесса дополнительно введено множество Adm:

— Adm С (R U AR) х (R U AR) —множество ролей, доступных для делегирования членства, при этом без административного права createroler может быть передано только членство в ролях, полученное с опцией WITH_ADMIN_OPTION.

Управление ролями разрешено только роли, имеющей административное право доступа createroler или получившей членство с опцией WITH_ADMIN_OPTION. Управление ролями, имеющими право доступа superuserr, разрешено только ролям, в свою очередь имеющим это право доступа. При отборе членства возможен отбор опции WITH_ADMIN_OPTION.

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

Особенностью реализации наследования прав доступа в иерархии ролей в СУБД PostgreSQL является наличие признака, разрешающего или запрещающего подобное наследование. Права доступа наследуются только в случае наличия у роли свойства INHERIT. Для описания подобного поведения введена функция role_inherit:

— role_inherit : R U AR ^ {true, false} — функция наследования прав доступа, задающая для каждой роли режим их наследования; если значение функции равно true, то роль, стоящая в иерархии выше текущей, наследует её права доступа, иначе нет. При этом role_inherit(public) = true.

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

— HR. : R U AR ^ 2r U 2ar — рекурсивная функция доступных ролей с учётом наследования прав доступа, удовлетворяющая для каждой роли r G R U AR условию: если значение функции role_inherit(r) = true, то HR(r) = {r} U (J HR(r'),

r'eHn{r)

иначе HR(r) = {r};

— PAR : R U AR ^ 2P — рекурсивная функция прав доступа к сущностям ролей и административных ролей с учётом иерархии, задающая множество всех доступных роли прав доступа, удовлетворяющая для r G R U AR условию: если значение функции role_inherit(r) = true, то PAR(r) = PA(r) U (J PAR(r'), иначе

r'eHn{r)

PAR(r) = PA(r).

Функция PAR позволяет получить всё множество доступных заданной роли прав доступа.

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

— lookup : S х E \ Od ^ {true, false} — функция доступа субъект-сессии к сущности в контейнере с учётом прав доступа к сущностям-контейнерам, её содержащим, такая, что по определению для субъект-сессии s G S и сущности e G E \ Od справедливо равенство lookup(s,e) = true тогда и только тогда, когда e G Ccl (доступ субъект-сессии к кластеру по определению есть) или если e G E \ Od и существует последовательность сущностей e0,... ,en G E, где n ^ 1, eo G Ccl, e = en, удовлетворяющих следующим условиям:

— ei G He(ei-i), где 1 ^ i ^ n;

— существует ri G R U AR, такая, что (s,ri, reada) G AA и если ei G Cdb, то (ei,connectr) G PA (r^,

если ei G Cnsp, то (e.i,usager) G PA (ri),

для других типов контейнеров дополнительных условий не требуется;

— fe(ei) ^ fs(s), или CCR(ei) = false, или downgrade_admin_sop G session_-option(x).

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

Определим G = (UA, AUA, PA, user, role, FC, CCR, A, AA, F, HR, HE, Lv, Ls) — состояние системы; используем обозначения: (G*, OP) —система, при этом:

— G* — множество всех возможных состояний;

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

— G hop G' — переход системы (G*, OP) из состояния G в состояние G' с использованием правила преобразования состояний op G OP.

В начальном состоянии О0 = (иА0, АиА0, РА0,пвег0, го1е0, РС0, ССК0, А0, АА0, Р0, Нп0, НЕо, Ьи0, Ь$0) по определению справедливо А0 = 0, АА0 = 0, Р0 = 0.

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

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

Для упрощения описания правил преобразования будем записывать только те составляющие состояния О', которые меняются относительно состояния О.

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

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

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

1 2 3

access read(x,y) x G S, y G (E \ Od) U R U AR, [y G E \ Od, (либо lookup(x, y) = true и feiy) ^ fs(x), либо downgrade -admin sop G session option(x))], [y G RU AR, (либо fr (y) < fs(x), либо downgrade admin sop G session -option(x))] если y G E \ Od, то A' = A U {(x, y, reada)}, AA' = AA, если y G R U AR, то AA' = AA U {(x, y, reada)}, A' = A

access write(x, y) x G S, y G (E \ Od) U R U AR, [y G E \ Od, (если y G Cd, то (y, superuserr) G P Ar" (role(x)), если y G Cdb U Cnsp, то (y,creater) G G PA~(role(x))), (либо lookup(x,y) = = true и ife(y) = fs (x) или ifs(x) < < feiy) и CCR(y) = false)), либо downgrade admin sop G session option(x))], [y G R U AR, (y, createroler) G G PA~(role(x)), (либо fr(y) = fs(x), либо downgrade admin sop G session option(x))] если y G E \ Od, то A' = A U {(x, y, writea)}, AA' = AA, если y G R U AR, то AA' = AA U {(x, y, writea)}, A' = A

access appendix, y) x G S, y G (E \ Od), (если y G Cci, то (y, superuserr) G G PA~(role(x)), если y G Cdb U Cnsp, то (y,creater) G PAr'J (role(x))], (либо fs(x) < fe(y), либо downgrade -admin sop G session option(x))) A' = A U {(x, y, reada)}, AA' = AA

delete access(x,y, aa ) x G S,y G E U R U AR, (x, y, aa) G A U AA если y G E, то A' = A \ (x, y,aa), AA' = AA, если y G R U AR, то AA' = AA \ (x, y,aa), A' = A

access select(x, y, {colj : 1 ^ j ^ k}, Dout) x G S, y G Crei, (x,y,reada) G A, {colj :1 < j < k} G Ocoi П He (y), Dout С Od П He(y), (либо (y,selectr) G PA~(role(x)), либо (colj, selectr) G PA~(role(x)), 1 ^ <j<k), (либо УtGDoutifeit)^fsix)), либо downgrade admin sop G session option(x)) A' = A U {(x,t, reada) : t G Dout}, Ver G rules(y, selectr) выполняется execute rule(er)

Продолжение таблицы

1 2 3

access insert(x,y, Din) x G S, y G Crei, (x, y, appenda) G A, Din £ O, (либо (y,insertr) G PA~(role(x)), либо (c, insertr) G PA~(role(x)), c G {c : c G He(y),type(c) = col}) A' = A U {(x,t, appenda) : t G Din}, Vt G Din fe(t) = fs (x), O'd = Od U Din, H'e(y) = He(y) U Din, Ver G rules(y, insertr) выполняется execute rule(er), Vet G triggers(y, insertr) выполняется execute procedure(trigger proc(et))

access update(x, y, {colj : 1 ^ j ^ k}, Dmod) x G S, y G Crei, (x,y,writea) G A, {colj : 1 < j < k} G Ocoi П He (y), Dmod С Od П HEiy), (либо (y,updater) G PAT(role(x)), либо (colj,updater) G PAT(role(x)), 1 < j < k), (либо Vt G Dmod(fe(t) = fs (x)), либо downgrade admin sop session -option(x)) A' = A U {(x,t, writea) : t G Dmod}, Ver G rules(y,updater) выполняется execute rule(er), Vet G triggers(y, updater) выполняется execute procedure(trigger proc(et))

access delete(x,y, Ddei) x G S, y G Crei, (x,y,writea) G A, Ddei С Od П He (y), (либо (y,deleter) G PA'J(role(x)), либо (c,deleter) G PA~(role(x)), c G {c : c G He(y),type(c) = col}), (либо Vt G Ddei(fe(t) = fs(x)), либо downgrade admin sop session -option(x)) O'd = Od \ Ddei, HE(y) = He(y) \ Ddei, Ver rules(y, deleter) выполняется execute rule(er), Vet triggers(y, deleter) выполняется execute procedure(trig-ger proc(et)), A' = A \ {(s,t,aa) : s G s, t G Ddei,aa G Ra}

create rel(x,y,z, Qcol, Qcnstr ) x G S,y G E,z G Cnsp, type(y) = rel, Ve G Qa type(e) = a и e G E, (x, z, appenda) G A, Ve' G Qcoi (x,coltype(e'),reada) G A E' = E U{y}U Qcoi U Qcnstr, (C' = CU{y}, O' = OU Qcoi u Qcnstr), He(z) = HE(z) U {y} HE(y) = Qcoi U Qcnstr, fe (y) = fs(x),CCR'(y) = P A' (role(x))=P A(role(x))UALLr (y), Gr'(role(x)) = Gr(role(x)) U ALLr(y)

create procedure(x, y, z, as option, {opj :1 < j < k}) x G S,y G E, z G Cnsp, as option G {as caller, as owner}, {opj : 1 ^ j ^ k} С OP, (x, z, appenda) G A O' = O U {y} (Oproc = Oproc U {y} C' = C), HE(z) = He(z) U{y}, operations'(y) = {opj : 1 ^ j ^ k}, fe (У~) = fs(x) execute as' (y) = as option, PA'(role(x))=PA(role(x))UALLr(y), Gr' (role(x)) = Gr(role(x))U ALLr (y), PA'(public) = PA(public) U {(y,exe-cuter)}

execute proce-dure(x,y) x G S,y G Oproc, (x, y, reada) G A, (y,executer) G PA~(role(x)) если execute as(y) = as owner, то: 1) 3r G R U AR (y, ownr) G PA(r) role'(x) = r; 2) выполняется G hopi ... I~opn Gn = = G', opi G operations(x), i = 1,. .. ,n; 3) role'(x) = role(x), иначе выполняется G hopi ... hop„ Gn = G', opi G operations(x), 1 ^ i ^ n

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

1 2 3

create trigger(x, y, z,p, {rj : Kj<k}) x G s, y G E, zG Crei, p G Oproc, {rj : 1 ^ j ^ k} С {insertr,updater, deleter ,truncater }, (x, z, writea) G A, (x,p, reada) G A, (z,triggerr) G PAT(role(x)) O' = O U {y} (°'trg = Otrg U {y} C' = C),HE(z) = He(z) U{y}, f'e(y) = fs(x), trigger_proc'(y) = p, triggers'(z, rj) = triggers(z, rj) U {y}, 1 < j < k

create rule(x, y, z, op, r) x G S, y G E, zG Crei, op {access select, access insert, access update, access delete}, r G {selectr,insertr,updater,deleter}, (x, z, writea) G A, (z,ownr) G PA~(role(x)) O' = O U {y} (Oruie = Oruie U {y} C' = C),HE(z) = He(z) U{y}, fe(y) = fs (x), rule_ op'(y) = op, rules'(z, r) = rules(z, r) U {y}

execute rule(x, y, z, r) x G S, y G Oruie, У G He(z), r G {selectr,insertr,updater,deleter}, (x, z, a) A, (a = reada для r = = selectr, a = appenda для r = = insertr, a G {reada, writea} для r G {updater, deleter}) выполняется G hop(y) Gop(y) = G'

grant rights(x,r, {(y, arj) : Kj<k}, grant option) x G S, y G E \ (Od U Cci), r G R U AR, {(y, arj) : 1 < j < k} С ALLr(y), {(y, arj) : 1 ^ j ^ k} С Gr(role(x)), grant option G {true, false}, (x,r,writea) G AA PA'(r) = PA(r) U {(y, arj) : 1^j^k}, (если r = public и grant option = = true, то Gr'(r) = Gr(r) U {(y, arj) : 1 < j < k})

revoke rights(x,r, {(y, arj) : Kj<k}, grant option) x G S, y G E \ (Od U Cci), r G R U AR, {(y, arj) : 1 < j < k} С ALLr(y), {(y, arj) : 1 ^ j ^ k} С Gr(role(x)), grant option G {true, false}, (x,r,writea) G AA [ если r = public, то Gr'(r) = Gr(r) \ \{(y,arj) :1 < j < k})L [ если r = public или grant option = =false, то PA'(r)=PA(r) \ {(y, arj) : 1 < j < k}]

Де-юре правила access_read(x, у), access_write(x, у) и access_append(x,y) аналогичны одноименным правилам МРОСЛ ДП-модели и позволяют субъект-сессии x получить соответствующий доступ к сущности у с определёнными условиями на уровень конфиденциальности субъект-сессии. Отличие заключается в замене функции execute_container(x, у) на функцию lookup(x,y). Кроме того, при доступе к кластеру необходимо наличие у роли субъект-сессии доступного по иерархии права superuserr, а при доступе к базам данных и схемам — наличие права creater к ним. Для нарушения требований к уровню конфиденциальности субъект-сессии требуется наличие у субъект-сессии параметра downgrade_admin_sop. Де-юре правило delete_access(x, у, aa) позволяет субъект-сессии x, обладающей доступом аа к сущности, роли или административной роли у, удалить этот доступ.

Де-юре правила access_select(x, у, {colj : 1 ^ j ^ k},Dout), access_insert(x, у, Din), access_update(x, у, {colj : 1 ^ j ^ k},Dmod) и access_delete(x, у, Ddel) отражают специфику работы с данными в таблицах БД и позволяют субъект-сессии x получить доступ на выборку, вставку, изменение и удаление данных D сущности-таблицы у. Для выполнения операции необходимо наличие у роли субъект-сессии x доступных по иерархии необходимых доступов к таблице и соответствующего операции права доступа. Операции затрагивают только доступные по мандатным атрибутам записи таблицы (для нарушения указанного поведения требуется наличие у субъект-сессии параметра downgrade_admin_sop). При выполнении операции вызываются на исполнение соответствующие реализованному праву доступа триггеры и правила, заданные для указанной таблицы функциями triggers и rules соответственно.

Правила создания контейнеров рассмотрим на примере де-юре правила создания таблицы create_rel(x, y, z,Qcol,Qcntsr), которое позволяет субъект-сессии СУБД x создать новую контейнер-таблицу y в схеме z с указанным множеством столбцов Qcol и ограничений Qcnstr. Для этого требуется наличие у субъект-сессии x доступа на добавление к схеме z и на чтение к сущностям-типам, указанным для столбцов из Qcoi. При этом новая сущность-контейнер приобретает уровень конфиденциальности, равный уровню доступа субъект-сессии x, и мандатный атрибут CCR, равный true. Роль субъект-сессии получает все права доступа к новой сущности с опцией их делегирования (множество Gr).

Де-юре правило create_procedure(x,y,z, as_option, {opj - І ^ j ^ k}) позволяет субъект-сессии x создать процедуру y в контейнере z Є Cnsp при наличии к нему доступа на добавление. Для создаваемой процедуры указывается режим выполнения кода as_option Є {as_caller, as_owner} и упорядоченный конечный набор операций {opj - І ^ j ^ k}, входящих в множество OP правил преобразования состояния модели. При этом новая сущность приобретает уровень конфиденциальности, равный уровню доступа субъект-сессии x, указанный режим исполнения кода, а в качестве кода — состав указанных операций. Роль субъект-сессии получает все права доступа к новой сущности с опцией их делегирования (множество Gr). Для процедур по умолчанию предоставляется право на исполнение executer группе PUBLIC.

Де-юре правило execute_procedure(x,y) позволяет субъект-сессии x выполнить процедуру y при наличии к ней доступа на чтение и доступного по иерархии права исполнения executer для указанной процедуры у роли субъект-сессии. В ходе исполнения процедуры согласно упорядоченному набору операций, составляющих тело процедуры operations, последовательно выполняются преобразования состояния модели. При этом если для процедуры указан режим исполнения кода as_owner, перед выполнением процедуры текущая роль субъект-сессии меняется на роль, обладающую правом владения к процедуре; после исполнения исходная роль субъект-сессии восстанавливается.

Де-юре правила create_trigger(x, y, z,p, {rj - І ^ j ^ k}) и create_rule(x, y, z, op, r) позволяют субъект-сессии x создать для таблицы z Є Crel новый триггер или правило, выполняющиеся при реализации прав доступа {rj - І ^ j ^ k} С {insertr, updater,deleter,truncater} или r Є {selectr,insertr,updater,deleter} соответственно. При создании триггера указывается активируемая процедура p Є Oproc, причём необходимо наличие у субъект-сессии z доступов на запись к таблице z и чтение к процедуре p и доступного по иерархии права создания триггера triggerr для указанной таблицы у роли субъект-сессии. При создании правила указывается операция op из перечисленных {access_select, access_insert, access_update, access_delete} Є OP правил преобразования состояния модели, причём необходимо наличие у субъект-сессии x доступного по иерархии права владения к таблице z. Новая сущность приобретает уровень конфиденциальности, равный уровню доступа субъект-сессии x, помещается в иерархию таблицы z, обновляются функции triggers и rules соответственно; устанавливается связь между триггером и активируемой процедурой или правилом таблицы и правилом преобразования состояния модели.

Де-юре правило execute_rule(x, y, z, r) позволяет субъект-сессии x выполнить правило y таблицы z при реализации права доступа r. Данное правило вызывается автоматически при реализации заданного права доступа к таблице. Для этого необходимо наличие соответствующего доступа к таблице. При выполнении этого правила реально исполняется указанное при создании правило op преобразования состояния модели.

Де-юре правила grant_rights(x,r, {(у,а^) : 1 ^ j ^ k}, grant_option) и revoke_-rights(x,r, {(у, arj) : 1 ^ j ^ k}, grant_option) позволяют субъект-сессии x добавить или удалить соответственно права доступа к сущности у из множества прав доступа роли или административной роли r. Для применения правил необходимо наличие у субъект-сессии x доступа на запись к роли r и перечисленных прав доступа в списке делегирования Gr роли субъект-сессии. Параметр grant_option соответствует опции SQL WITH_GRANT_OPTION, предоставляющей роли r возможность делегировать полученные права. Данная опция не может быть применена к встроенной группе PUBLIC. При удалении, если параметр grant_option установлен в true, отбирается только возможность делегирования.

Де-факто правила, используемые для отражения факта получения субъект-сессией де-факто владения субъект-сессиями или факта реализации информационного потока по памяти или по времени, схожи с аналогичными правилами МРОСЛ ДП-модели.

Заключение

Основной целью адаптации МРОСЛ ДП-модели для использования в реляционной СУБД PostgreSQL и разработки новой PostgreSQL ДП-модели является обеспечение единого подхода к управлению доступом в СУБД и ОС СН Astra Linux Special Edition.

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

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

ЛИТЕРАТУРА

1. Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищённости от несанкционированного доступа к информации. М.: Военное издательство, 1992.

2. Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации. М.: Военное издательство, 1992.

3. Девянин П. Н. О разработке мандатной сущностно-ролевой ДП-модели управления доступом и информационными потоками в операционных системах семейства Linux // Методы и технические средства обеспечения безопасности информации: материалы 21-й науч.-технич. конф. 24-29 июня 2012 г. СПб.: Изд-во Политехн. ун-та, 2012. С. 91-94.

4. Девянин П. Н. Об опыте внедрения мандатной сущностно-ролевой ДП-модели управления доступом и информационными потоками в защищенную ОС Astra Linux Special Edition // Методы и технические средства обеспечения безопасности информации: материалы 22-й науч.-технич. конф. 08-11 августа 2013 г. СПб.: Изд-во Политехн. ун-та, 2013. С. 78-80.

5. Операционные системы Astra Linux [Электронный ресурс]. http://www.astra-linux.ru/.

6. Sandhu R. Rationale for the RBAC96 family of access control models // Proc. 1st ACM Workshop on Role-Based Access Control. ACM, 1997.

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

8. Колегов Д. Н. О построении иерархического ролевого управления доступом // Прикладная дискретная математика. 2012. №5. С. 69-71.

9. Смольянинов В. Ю. О достаточных условиях похищения прав доступа в СУБД ДП-модели // Прикладная дискретная математика. 2012. №5. С. 75-76.

10. Смирнов С. Н. Безопасность систем баз данных. М.: Гелиос АРВ, 2007. 352 с.

11. PostgreSQL 9.2.1 Documentation. The PostgreSQL Global Development Group, 2012. 2605 p.

12. Information technology — Database languages — SQL — Part 1: Framework (SQL/Framework). ISO/IEC 9075:1999, 1999.

13. Information technology — Database languages — SQL — Part 2: Foundation (SQL/Foundation). ISO/IEC 9075:1999, 1999.

14. Sumathi S. and Esakkirajan S. Fundamentals of Relational Database Management Systems. Springer, 2007. 776 p.

15. Lane T. A Tour of PostgreSQL Internals. Great Bridge, LLC, 2000. 25 p. [Электронный ресурс.] http://www.postgresql.org/files/developer/tour.pdf.

16. Шумилин А. В. Перспективный подход к обеспечению защиты информации от несанкционированного доступа в СУБД // Новые технологии. Программная инженерия. 2012. № 1. С. 35-40.

17. Шумилин А. В. Подход к оцениванию влияния сpедств pазгpаничения доступа к данным на пpоизводительность pеляционных СУБД // Новые технологии. Программная инженерия. 2013. №4. С. 29-33.

18. Шумилин А. В. Применение мандатной сущностно-ролевой ДП-модели управления доступом и информационными потоками в СУБД операционной системы специального назначения Astra Linux Special Edition // Методы и технические средства обеспечения безопасности информации: материалы 22-й науч.-технич. конф. 08-11 августа 2013г. СПб.: Изд-во Политехн. ун-та, 2013. С. 87-89.