Реферат 1 Введение 3 Аналитическая часть 5

• Название: Реферат 1 Введение 3 Аналитическая часть 5
• Дата: 11.03.2018
• Размер: 1.24 Mb.
• Имя файла: diplom_-_Copy_1_checked.docx
• Тип: Реферат; #38138
• страница: 11 из 16

Разработка модель функционирования системы ролей

Обоснование выбранной ролевой политики контроля доступа

Для разрабатываемой автоматизированной системы обучения и контроля знаний рассматривались три рассмотренные в аналитической части политики контроля доступа: мандатная, избирательная и ролевая. В итоге выбор пал на ролевую систему (RBAC). Подход на основе ролей имеет следующий ряд преимуществ.[18]

• 
  Управление разрешениями: политика на основе ролей выгодно отличается логической независимостью в выдаче прав пользователю, разбивая эту задачу на две составные части. Первая назначает пользователям роли, а вторая назначает права доступа ролям к объектам. Это значительно упрощает управление контролем доступа.
  

Например, предположим, что обязанности пользователя изменились из-за его продвижения по службе. Тогда текущие роли пользователя могут быть легко изъяты и взамен могут быть назначены новые роли, соответствующие его новым обязанностям. Если все разрешения выставляются непосредственно между пользователями и объектами (как в MAC или DAC), становится необходимой отмена всех существующих прав доступа пользователя и назначение новых. Это может быть громоздкой и трудоемкой задачей.

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

• 
  Принцип наименьших привилегий: роли позволяют пользователю войти в систему с наименьшими привилегиями, необходимыми для конкретной задачи. Люди, уполномоченные более мощными ролями, не должны пользоваться ими, пока эти привилегии не станут действительно необходимы. Это сводит к минимуму опасность непредумышленных ошибок в системе или доступ к системе злоумышленниками под видом обычных пользователей.
  

• 
  Разделение обязанностей: принцип, что ни одному пользователю не должно быть уделено достаточно привилегий, чтобы он смог единолично злоупотреблять своими правами в системе. Разделение обязанностей может быть обеспечено либо статически (введением противоречивых ролей, т.е. ролей, которые не могут быть выполнены одним и тем же пользователем) или динамически (путем контролирования соблюдения принципа во время доступа).
  

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

• 
  Классы объектов: политика на основании ролей обеспечивает классификацию пользователей в соответствии с деятельностью, которую они выполняют. Аналогично, должна быть предусмотрена классификация объектов.
  

Например, как правило, бухгалтер должен иметь доступ к банковским счетам, в то время как секретарь должен иметь доступ к письмам и к памяткам (или к некоторому подмножеству из них). Объекты могут быть классифицированы в соответствии с их типом (письма, руководства) или с их областью применения (коммерческие письма, рекламные буклеты). Разрешения, присваиваемые ролям, должны быть основаны на классах объектов, а не на конкретных объектах. Например, роли секретаря могут быть даны разрешения на чтение и запись всего класса писем, вместо того, чтобы давать явные разрешение для каждого отдельного письма. Этот подход имеет ещё одно преимущество: управление разрешениями намного проще и эффективнее контролировать. Кроме того, разрешения для каждого объекта автоматически определяется в соответствии с типом объекта без необходимости указания разрешения при каждом создании нового объекта.

Наибольший интерес для автоматизированной системы обучения и контроля знаний представляли удобное и гибкое управление разрешениями, принцип наименьших привилегий, разделение обязанностей. Таким образом, ролевая политика доступа наиболее полно отвечает предъявленным к системе контроля доступа требованиям.

Проектирование системы ролей с учётом специфики автоматизированной системы обучения и контроля знаний

Основные идеи, используемые при проектировании, состоят в том, что:

• 
  Во-первых, весь функционал системы может быть представлен в виде дерева. В контексте системы обучения и контроля знаний, это дерево – двухуровневое. Листьями этого дерева являются элементарные функции пользователя, например: просмотр расписания определенного преподавателя или редактирование новости. Верхний уровень, обычно, соответствует крупным подсистемам, например: модуль расписания, модуль новостей и т.д.
  

• 
  Во-вторых, эти функции привязываются не к учетным записям отдельных пользователей, а к ролям. Роли также могут подвергаться многоуровневой группировке (иерархия ролей), но учитывая потенциальных пользователей (учителя, студенты, сотрудники кафедры) в контексте автоматизированной системы обучения и контроля знаний вполне достаточной оказывается «плоская» система ролей.
  

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

Рассмотрено, каким именно образом может осуществляться привязка функций к ролям. Доступны 2 варианта решения проблемы: привязка либо непосредственно в программном коде, либо в базе данных.

Первый вариант может осуществляться за счет использования, например, строковых констант. Основное достоинство такого варианта привязки – простота. Однако, этот механизм не походит, если:

• 
  система обладает разветвленным функционалом;
  
• 
  количество отдельных ролей может быть велико (больше 3-5);
  
• 
  в системе предполагается множество вариантов конфигурации или/и поставки (в том или ином варианте присутствует система плагинов).
  

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

В итоге было решено использовать второй подход, как обладающий большей гибкостью и организованностью.

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

1. 
   Использовать привязку к функции по URL в базе данных (каждой функции в системе соответствует какой-то URL-адрес)
   
2. 
   Использовать возможности метаданных в коде.
   

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

При выбранном подходе, тем не менее, нужно каким-то способом идентифицировать функции. Было принято решение давать всем функциям некоторые абстрактные от их реализации названия. Причём в этих названиях должно присутствовать явное разделение функций на 2 уровня (напомним, что дерево функционала – двухуровневое).

Таким образом, решено давать функциям нижнего уровня названия в виде AAA.BBB, где AAA соответствуют функции верхнего уровня (например, “News” – модуль новостей), а BBB – это конкретная функция (например, “createRecord” – создание новой новости). Тогда полное название выглядит как, например, “News.createRecord”.

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

Концептуальная схема системы ролей и логическая модель базы данных представлены в приложении A.

Взаимодействие системы ролей и функционала модулей системы обучения и контроля знаний

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

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

Первый уровень проверки происходит на этапе генерации HTML-страницы, т.е. перед тем, как вывести на страницу код кнопки (или элементов другого вида пользовательского интерфейса), ссылающейся на функцию, проверяется наличие доступа к этой функции у текущего пользователя.

Второй уровень проверки происходит непосредственно на уровне перехода пользователя по этой ссылке, т.е. был реализован некоторый фильтр, осуществляющий проверку доступа на этапе HTTP-запроса. Это предупреждает пользователя от попытки воспользоваться неразрешённым ему функционалом, просто введя в браузере URL-адрес.

Если пользователь пробует перейти по URL адресу к функционалу, который ему недоступен, происходит перенаправление на экран ошибки «Такая страница не существует».

Диаграмма деятельности при осуществлении двухуровневой проверки представлена в приложении B.

Модуль администрирования ролями

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

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

Модуль администрирования ролями должен предоставлять следующие возможности:

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

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

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

Диаграмма вариантов использования представлена в приложении C.