USER ACCESS MANAGEMENT FOR UNIVERSITY CORPORATIVE AUTOMATED INFORMATION SYSTEM

Full Text

Введение КАИС является системой, функционирующей на основе интегрированной базы данных и развитой телекоммуникационной инфраструктуры вуза [1]. Информационные ресурсы КАИС обрабатываются значительным числом пользователей, имеющих различные права доступа. Проектирование и реализация подсистемы управления доступом пользователей КАИС вуза требует выполнения определенных и трудоемких работ в соответствии с используемой политикой доступа (см. таблицу 1). При этом необходимо решать задачу предоставления субъекту прав доступа, строго не превышая уровня требований предметной области. В целях обеспечения эффективной защиты корпоративных данных, обрабатываемых в распределенном режиме, необходимо решать задачу минимизации привилегий пользователей КАИС. Таблица 1. Перечень задач управления правами доступа пользователей КАИС Уровень проекта КАИС Пользователи (субъекты доступа) Данные (объекты доступа) Операции с данными Комментарий Внешний (обобщенное представление всех пользователей) Выделение, мониторинг, учет изменения состава пользователей Выделение категорий, первичный учет, отслеживание изменения состава обрабатываемых данных Выделение возможных операций манипулирования данными (добавление, обновление, чтение) Уровень доступа пользователя зависит от принадлежности к уровню иерархии организационной структуры подразделений вуза Концептуальный (представления разработчиков компонентов КАИС) Проектирование функциональной составляющей подсистемы управления доступом, структур объектов доступа Выделение связанных подмножеств объектов и субъектов доступа Внутренний (физическая реализация проектных решений) Проектирование объектов базы данных (таблицы, пользователи, роли, представления, пакеты, хранимые процедуры и др.) Реализация политики управления доступом Постановка задачи КАИС вуза является либо собственной автоматизированной системой, либо приобретенным программным продуктом и функционирует на основе систем управления базами данных (СУБД) Oracle, MS SQL, FireBird, платформе SAP/R3 и др. Данные КАИС отражают информационные потоки, связанные с образовательной, научной, маркетинговой, управленческой и другими видами деятельности вуза, и вносят значительный вклад в формирование единой информационной среды вуза. Информационные ресурсы КАИС доступны как в открытом (свободном) режиме доступа посредством сайта образовательной организации, так и в режиме авторизации пользователя. Функции добавления и обновления сведений в рамках КАИС доступны достаточно широкому кругу пользователей - работникам различных подразделений вуза. Решение задач управления доступом пользователей КАИС требуют проведения ряда проектных мероприятий (см. таблицу 1), включающих административно-правовые, технические, технологические и другие виды работ на всех этапах проектирования компонентов, и далее - на всех последующих этапах жизненного цикла системы. На внутреннем уровне проекта КАИС в рамках задач управления доступом пользователей описываются: - функции идентификации пользователей, обработки событий успешной или неуспешной авторизации пользователей, настройки взаимодействия прикладной программы с объектами интегрированной базы данных КАИС и др.; - объекты базы данных для реализации политики управления доступом (представления, функции, пакеты, пользователи, роли и др.). Интегрированные процессы обработки информации в КАИС, как правило, состоят из разнообразных операций; участники процесса, задействованные в отдельных операциях, имеют различные привилегии доступа к данным. Для каждого отдельного пользователя достаточно трудно определить состав минимально необходимых привилегий. Зачастую их дается больше, чем необходимо для выполнения конкретных действий с данными, что может привести к нарушению целостности данных системы. Появляется задача минимизации привилегий, решение которой позволяет определить ограничения, накладываемые на функции, выполняемые в базе данных пользователем. Ограничения формулируются на основе правила: участники процесса обработки данных должны быть наделены теми и только теми привилегиями, которые естественно и минимально необходимы для получения заданного результата. Данное правило лежит в основе проектирования отношений между субъектами и объектами доступа в распределенной автоматизированной системе, управления этими отношениями. Ограничения моделей управления доступом современных СУБД В современных СУБД на физическом уровне реализованы несколько моделей управления доступом, которые необходимо знать и учитывать при проектировании объектов базы данных: политика ролевого управления доступом (RBAC); избирательное управление доступом (DAC); мандатное управление доступом (MAC). Результат анализа трех СУБД (Oracle 11g, MySQL, MS SQL Server 7.0), нашедших самое широкое применение на современном рынке, и поддерживаемых ими политик доступа показал, что нельзя осуществить четкое разграничение прав доступа на уровне структуры объекта доступа - каждый пользователь КАИС вуза получает более широкие полномочия, чем необходимо. Также проведенные исследования привели к выводу, что только поддержка мандатной политики дает возможность поднять класс защищенности автоматизированной системы до необходимого. Рассмотрим реализацию управления доступом субъектов к объектам доступа в СУБД Oracle [2-3]. Для данной СУБД субъект доступа всегда строго определен, если он прошел процедуру аутентификации и идентификации. Субъект доступа имеет права на один или несколько процессов, исполняемыми с определенными правилами (полномочиями) доступа. Полномочия зафиксированы административными регистрационными записями. Субъект характеризуется следующими атрибутами мандатного управления доступом: действующий идентификатор владельца процесса; идентификатор классификационной метки; массив меток на максимально доступный уровень секретности на выполнение действий с данными. Объектами доступа в базе данных под управлением СУБД Oracle являются: таблицы (реляционные отношения), представления, процедуры, функции, пакеты. На все объекты базы данных распространяются правила дискреционной и ролевой политик управления доступом. На ряд объектов, содержащих конфиденциальную, секретную или коммерческую информацию, может распространяться мандатное управление доступом. При мандатном управлении различают следующие типы доступа: чтение данных (для таблиц, представлений, функций); добавление, удаление, обновление данных (для таблиц и представлений). При попытке субъекта осуществить доступ к объекту производится проверка прав доступа строго в следующем порядке: - выполняются правила дискреционной и ролевой политик управления доступом. Если субъект не имеет прав доступа к объекту на основании указанных политик, СУБД выдает отказ в доступе, иначе доступ к объекту разрешается; - выполняются правила мандатной политики управления доступом. Если выявлено, что субъект не имеет прав доступ к объекту, СУБД выдает отказ в доступе, иначе доступ к объекту разрешается. Мандатная модель в СУБД Oracle реализуется путем использования механизма Oracle Label Security (OLS) [2]. Использование мандатной политики позволяет для заданного кортежа реляционного отношения (РО) присвоить метку с уровнем конфиденциальности доступа. Очевидным недостатком становится тот факт, что мандатная политика не поддерживает в полном объеме ограничения предметной области на проведение операций на уровне отдельных атрибутов РО. Ещё одним недостатком мандатной политики является то, что установленные администратором базы данных (АБД) метки не могут динамически (без участия АБД) изменяться в соответствии с изменениями, происходящими в предметной области, влияющими на состав субъектов, объектов и правила доступа, т.е. АБД не имеет возможности переложить правила подчинения данных в предметной области на уровень политики меток. Отношения между классами объектов предметной области в рамках реализации мандатной модели управления доступом можно представить в виде информационно-логической модели (ИЛМ) предметной области в нотации Ричарда Баркера (см. рис. 1); знак «#» в данной методологии отражает уникальный идентификатор класса объектов, знак «*» - опциональность (обязательность значения) свойства класса объектов. Рис. 1. ИЛМ реализации мандатной модели управления доступом Каждая устанавливаемая метка должна относиться к одному конкретному субъекту доступа, правилу доступа (добавить, обновить, удалить, читать данные) и конкретному значению свойства объекта доступа. Объект доступа представлен именем и должен иметь одно или более свойств (структура объекта). Каждому свойству может соответствовать одно или более значений. Со стороны классов объектов «ЭЛЕМЕНТ ЗАГОЛОВКА ОБЪЕКТА ДОСТУПА», «СУБЪЕКТ ДОСТУПА», «ПРАВИЛО ДОСТУПА» и «МЕТКА» отношения (связи) необязательные - метка может устанавливаться не сразу. Рассмотрим правило предметной области (далее - Правило): «Субъект доступа с именем «Субъект_1» имеет правило доступа «читать» у объекта доступа с именем «Объект_1» и заголовком, включающем атрибуты «A1», «A2» и «A3», только значения атрибута «A2», отвечающие заданному условию (далее - Условие)». Для реализации Правила на основе мандатной политики доступа в реляционной базе данных КАИС вуза осуществляются шаги: 1. На основе ИЛМ формируется схема реляционной базы данных, содержащая три главных и три подчиненных реляционных отношения (см. таблицу 2); где FK - внешний ключ, реализующий связи между реляционными отношениями. 2. Выполнение операции соединения между реляционными отношениями SD, «M», «PD», «OD», «ZOD», «ZS» по равенству значений внешних ключей (FK). Формируется реляционное отношение «R», отражающее представление субъектом доступа «Субъект_1» структуры объекта доступа «Объект_1» - субъект доступа не имеет никаких прав на выполнение операций со значениями свойств объекта доступа. Представление отражено на рис. 2а - все строки и столбцы РО, реализующего в базе данных объект доступа, заштрихованы - данные всего отношения не доступны субъекту для выполнения операций. Таблица 2. Формирование реляционной структуры данных Класс объектов предметной области Реляционное отношение СУБЪЕКТ ДОСТУПА (имя субъекта) SD (IS) ОБЪЕКТ ДОСТУПА (имя объекта) OD (IO) ЭЛЕМЕНТ ЗАГОЛОВКА ОБЪЕКТА ДОСТУПА (имя свойства) ZOD (IS, IO(FK)) ПРАВИЛО ДОСТУПА (правило) PD (Р) МЕТКА (номер) M(NM, IA(FK), P(FK)) ЗНАЧЕНИЕ СВОЙСТВА (значение) ZS (Z, IS (FK), NM (FK)) 3. Удаление в реляционном отношении «R» строк и столбцов в соответствии с Правилом и реализацией мандатной политики доступа. Формируется отношение «R1», отражающее результирующее, заданное представление субъектом доступа «Субъект_1» структуры объекта доступа «Объект_1» - субъект доступа имеет право «Читать» значения заданных строк (метка устанавливается в соответствии с Условием). Представление отражено на рисунке 2б - строки, соответствующие Условию, не заштрихованы - данные этих строк отношения доступны субъекту для выполнения операций. Рис. 2. Вид представления структуры объекта доступа субъектом доступа до и после наложения ограничений мандатной политики Таким образом, мандатная политика управления доступом позволяет накладывать ограничения, установленные Правилом предметной области, но на физическом уровне субъект доступа имеет более широкие права (субъект доступа в действительности может видеть значения всех атрибутов заданной строки), что ведет к возникновению угрозы нарушения конфиденциальности данных. Также остается нерешенной задача актуальной поддержки безопасности данных с учетом изменения правил подчинения данных субъектам доступа, которые присущи предметной области в достаточно большом количестве (изменение организационной структуры вуза, добавление, обновление, удаление направлений подготовки, движение контингента обучающихся и работников и др.) - каждый раз АБД на уровне физической модели базы данных необходимо анализировать связи между существующими метками и строками таблиц и представлений, вносить соответствующие изменения в структуры объектов базы данных (представления, роли и др.). Собственная модель управления доступом КАИС вуза После проведенного анализа предметной области и требований к информационной безопасности КАИС стало очевидным, что необходимо разработать собственную модель управления правами доступа, основываясь на мандатной политике. Модель управления, реализуемая на основе СУБД Oracle, должна учитывать ограничения доступа на заданные свойства объекта доступа и гибко реагировать на изменения принадлежности субъекта и объекта доступа к тем или иным узлам иерархии организационной структуры вуза - см. рис. 3. Модель, представленная на рис. 3, в сравнении с предыдущей моделью поддерживает следующие ограничения предметной области: - каждый субъект и объект доступа должен относиться к одному конкретному структурному подразделению; - каждому структурному подразделению может соответствовать один или более субъектов и объектов доступа. Данные ограничения позволяют накладывать дополнительные условия на выборку тех или иных объектов доступа при реализации разграничения полномочий. В модели также реализована связь между элементом заголовка объекта доступа и меткой, что позволяет управлять разграничением доступа на уровне отдельных свойств объекта доступа. Рис. 3. ИЛМ реализации собственной политики управления доступом Для реализации рассматриваемого правила на основе собственной политики управления доступом в реляционной базе данных КАИС вуза осуществляются следующие шаги. 1. В соответствии с ИЛМ формируется схема реляционной базы данных, содержащая два главных и пять подчиненных реляционных отношения (см. таблицу 3). 2. Выполнение операции соединения между реляционными отношениями «IPP», «SD», «M», «PD», «OD», «ZOD», «ZS» по равенству значений внешних ключей (FK). Формирование результирующего РО «RR», отражающего представление субъектом доступа «Субъект_1» структуры объекта доступа «Объект_1» на основе мандатной политики. Представление отражено на рис. 3а: данные не заштрихованных строк доступны субъекту для выполнения операций. 3. Удаление в реляционном отношении «RR» строк и столбцов в соответствии с условиями предложенной модели предметной области и Правила. Формирование результирующего РО «RR1», отражающего заданное представление субъектом доступа «Субъект_1» структуры объекта доступа «Объект_1» - субъект доступа имеет право «Читать» только заданные значения (строки) заданного свойства «А2» (столбца) объекта доступа. Представление отражено на рис. 3б: не заштрихованные ячейки - уровень доступа субъекта; данные только этих ячеек доступны для операций субъекту доступа. Таблица 3. Формирование реляционной структуры данных Класс объектов предметной области Реляционное отношение ИЕРАРХИЯ ПОДЧИНЕНИЯ ПОДРАЗДЕЛЕНИЙ (номер узла) IPP (NU, NUR (FK) СУБЪЕКТ ДОСТУПА (имя субъекта) SD (IS, NU (FK)) ОБЪЕКТ ДОСТУПА (имя объекта) OD (IO, NU (FK)) ЭЛЕМЕНТ ЗАГОЛОВКА ОБЪЕКТА ДОСТУПА (имя свойства) ZOD (IS, IO(FK)) ЗНАЧЕНИЕ СВОЙСТВА (значение) ZS (Z, IS (FK)) ПРАВИЛО ДОСТУПА (правило) PD (Р) МЕТКА (номер) M(NM, IA(FK), IS(FK), P(FK)) Предложенная модель политики доступа позволяет соединить ограничения предметной области и мандатной политики доступа. Заключение Реализация в КАИС вуза связи между субъектами доступа, объектами доступа и структурными подразделениями и отслеживание изменения состояния контингента субъектов доступа, позволяет достаточно тонко реализовать правила конфиденциальности данных предметной области. Рис. 3. Вид представления структуры объекта доступа субъектом доступа на основе собственной модели доступа Предложенная политика управления доступом реализована в рамках проекта информационно-аналитической системы Оренбургского государственного университета (ИАС ОГУ, ias.osu.ru), относящейся к классу корпоративных автоматизированных информационных систем. ОГУ является крупным региональным вузом, осуществляющим образовательные услуги по более 80 направлениям подготовки и специальностям; в качестве пользователей (субъектов доступа) ИАС ОГУ зарегистрировано свыше 900 человек. Особенно актуально использование представленной модели для управления доступом пользователей функциональных подсистем ИАС ОГУ: «Приемная комиссия», «Деканат», «Делопроизводство», «Организация учебного процесса», «Социальная и воспитательная работа», «Организация СКУД», поскольку с задачами данных подсистем работают как в локальной вычислительной сети, так и через службы Интернет сотрудники значительного количества подразделений университета, включая филиалы и колледжи.

About the authors

Irina Pavlovna Bolodurina

Orenburg State University

Email: prmat@mail.osu.ru

Tatyana Victorovna Volkova

Orenburg State University

Email: tv@mail.osu.ru

Nadezhda Alekseevna Ashcheulova

Orenburg State University

Email: nadya@mail.osu.ru

References

Supplementary files