Смекни!
smekni.com

Управление данными на веб портале ВУЗа (стр. 2 из 2)

  • формирование состава (добавление, исключение) пользователей Web-портала ;
  • предоставление сервиса аутентификации пользователя компонентам Web-портала ;
  • управление полномочиями пользователей по доступу к цифровым ресурсам и службам Web-портала ;

Требования к системе управления доступом

Система управления доступом, реализуемая Службой безопасности Web-портала , должна отвечать следующим требованиям:

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

Архитектура системы управления доступом

С точки зрения обеспечения информационной безопасности для построения системы управления доступом необходимо определить состав и способы взаимодействия защищаемых объектов. В архитектуре образовательного Web-портала выделены следующие объекты защиты:

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

Связи между защищаемыми объектами представлены на рис.1:

На самом нижнем уровне находятся сервисы функционального ядра портала. Сюда относятся, например, исполнитель запросов Object Query Language и другие сервисы, абстрагирующие доступ к базе данных. Эти сервисы используются объектами, представляющими информационные ресурсы, такие как "организация", "персона", "публикация", "web-стица" для извлечения и модификации своих данных. Помимо объектов-ресурсов, существуют объекты-сервисы, например: сервис визуализации, поисковый сервис, подписка на уведомления о модификациях. Эти объекты используют, помимо сервисов функционального ядра, объекты-ресурсы для реализации своей функциональности.

Доступ к защищаемым объектам Web-портала может осуществляться по различным протоколам. Так, при доступе через браузер (HTTP) будет использоваться сервис визуализации, который будет извлекать информацию из соответствующих объектов-ресурсов. При доступе по протоколу SOAP будет работать другой компонент: Web-сервис.

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

Базовая функциональность Службы безопасности портала.

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

Наиболее распростены системы с использованием пароля. Они просты и удобны, в том числе, с точки зрения реализации, но при этом у систем защиты, основанных на паролях, есть ряд недостатков:

  • логин не является "реальным" идентификатором пользователя в том смысле, что связь между человеком и идентификатором очень условна;
  • пароли часто легко подбираются/взламываются.

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

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

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

В процессе определения наличия либо отсутствия в массиве троек ("объект"-"пользователь"-"операция") элемента для заданных объекта, пользователя и операции над объектом происходит авторизация аутентифицированного пользователя. Можно выделить две основные проблемы авторизации:

описание массива троек "объект"-"пользователь"-"операция" наиболее удобным способом;

наиболее эффективное определение наличие или отсутствие в нем конкретной тройки.

Существует несколько методик описания прав доступа. Наиболее широко распростена в настоящее время методика назначения на объекты списков прав доступа (access control list - ACL). Каждый элемент этого списка содержит идентификатор пользователя (идентификатор группы, идентификатор субъекта) и назначенный этому идентификатору вид доступа. Расширения этой схемы позволяют включать в список элементы, явно запрещающие доступ к объекту, а также указывать возможность наследования элемента списка вниз по иерархии объектов.

Список доступа может быть сохранен вместе с объектом. Достоинство хранения списка доступа вместе с защищаемым объектом состоит в том, что оказывается легко проверить назначенные права доступа к любому объекту, а также легко их изменить. Однако при большой мощности и высокой динамике множества защищаемых объектов, а именно такую характеристику имеют интегрированные в Web-портал цифровые ресурсы, преимущества становятся недостатком: списки занимают значительное место, а административные усилия по управлению ими могут стать неприемлемо большими. Это в еще большей степени относится к системам, где множество объектов неоднородно, а связи между ними имеют более сложную, чем древовидную, структуру, что не позволяет простым образом задать наследование прав доступа.

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

Под ролью обычно понимают множество объектов, к которым пользователь имеет доступ, и, возможно, список допустимых операций над ними. Для использования механизма ролей в Web-портале , а именно обоснованность формирования ролей является ключевым вопросом ролевой безопасности, имеются весьма выгодные предпосылки. Именно, в есть достаточно строгая (с позиции информационной безопасности) иерархия, основанная на структуре подразделений академических организаций и структуре должностей. Основываясь на этой иерархии, Сервис авторизации при назначении, например, роли "администратор отдела X" дает возможность полного доступа к объектам "сотрудник", работающим в отделе "X", а также к объектам, представляющим подчиненные подразделения и их сотрудников. При этом создание нового подчиненного подразделения автоматически включает его в область действия этой роли. Конечно, во всех организациях существует много отделов, и для каждого, в таком случае, нужно создавать аналогичную роль. Однако, хотя все такие роли и будут содержать разные множества объектов, но все они используют один и тот же алгоритм его вычисления для заданного отдела.

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

Список литературы:

    Брежнева, В.В. Информационное обслуживание: продукты и услуги, предоставляемые библиотеками и службами информации предприятий [Текст] / В.В. Брежнева, В.А. Минкина; СПбГУКИ. – 2-е изд., перераб. – СПб.: Профессия, 2006. – 304 с. – (Серия «Библиотека»)
    Пунина, Т.Г. Проектирование и размещение в сети Интернет административных сайтов образовательных учреждений: Учебно-методическое пособие / Т. Г. Пунина
    Рогачева, Г.И. Современные информационные образовательные ресурсы [Текст] / Г.И. Рогачева // Информатизация школьного образования: Материалы междунар. науч.-практ. конф. 17-18 сентября 2002 г. – Барнаул, 2003. – С. 34-36
    Борк Дж. Что может сделать EIP? // Еженедельник "Computerworld", № 10, 2001.