Введение Существующие классические модели безопасности не обеспечивают должной гибкости при настройке прав доступа к защищаемым объектам в автоматизированных библиотечных информационных системах (АБИС). Это связано прежде всего с тем, что читателю необходимо предоставлять доступ максимально комфортно, быстро и, желательно, без дополнительных шагов по его аутентификации и авторизации, но в то же время необходимо учитывать требования Закона «Об авторском праве и смежных правах», а также регламент работы библиотеки и Закон «О персональных данных». Это подразумевает различные варианты организации доступа к информации, в том числе полнотекстовым ресурсам (объектам), начиная от открытого доступа и заканчивая строго ограниченным определённой группой пользователей. Кроме того, доступ может быть лимитирован по времени; удостоверяться электронной подписью, выданной внутрикорпоративным удостоверяющим центром (например, «VipNet», «Автограф» и т. д.) или сторонним удостоверяющим центром; предоставляться только с определённых IP-адресов (или их диапазонов) сети Интернет, или может быть ограничен ещё какими-либо условиями. Наличие в АБИС пользователей, которые не являются полноценными читателями, но которым необходимо получить единовременный доступ к одному или нескольким объектам (так называемые «внешние временные читатели»), также увеличивает объём работ для администратора безопасности АБИС. Поскольку всё вышеперечисленное в конечном счёте может привести к возникновению ошибок прав доступа, целью нашего исследования стала разработка новой модели безопасности, учитывающей особенности предоставления доступа к данным в АБИС, а именно различные варианты аутентификации, ограничения по времени доступа, ограничения по группам пользователей, с учётом степени конфиденциальности объектов. Обзор существующих АБИС В настоящее время в библиотеках АБИС внедряются повсеместно [1, 2]. Такая система обычно состоит из реляционной базы данных, программного обеспечения, которое взаимодействует с базой данных, и двух графических пользовательских интерфейсов (один для читателей, второй для персонала). Каждый читатель (посетитель) и объект (книги, журналы, диски и т. д.) имеют уникальный идентификатор в базе данных, который позволяет АБИС отслеживать историю обращений, заказов, загрузок и т. д. Данный рынок программного обеспечения достаточно инертен и в России представлен в основном либо бесплатными (open-source) системами управления библиографической информацией (Evergreen, CDS Invenio, Koha, NewGenLib, PhpMyBibli, Greenstone, OpenBiblio и др.), либо национальными платными системами (КАБИС, Абсотек Юникод (Absotheque Unicode), МАРК-SQL, Руслан, Либэр, УФД/Библиотека, Senayan, OPAC-Global, Ирбис и др.). У вышеназванных категорий программного обеспечения есть свои преимущества и недостатки. Так, первые решения (open-source) ориентированы в первую очередь на западный рынок (т. к. разрабатываются и поддерживаются в основном зарубежными программистами для своих потребителей), используют западные стандарты библиографического описания и имеют достаточно ограниченные возможности по настройке прав доступа к объектам хранения. У вторых web-интерфейсы для читателей значительно проигрывают их зарубежным аналогам (даже бесплатным). У тех и других отсутствует также возможность быстрой интеграции АБИС в корпоративную среду организации. Так, например, у большинства систем нет возможности внешней аутентификации читателей (например, Active Directory в локальной или корпоративной сети), нет возможности встроенного разграничения доступа к объектам по IP-адресам (или диапазонам), отсутствуют возможности по созданию ограниченного по времени (и (или) количеству скачиваний) доступа к объекту (группе объектов). Во всех системах в настоящее время отсутствует возможность наиболее безопасной аутентификации электронной подписью, выданной внутрикорпоративным удостоверяющим центром (например, «VipNet», «Автограф» и т. д.) или сторонним удостоверяющим центром. Во многих системах отсутствует также возможность разграничения права доступа по отделам и службам библиотеки при обработке объектов. Информация, обрабатываемая в АБИС, включает в себя персональные данные читателей, следовательно, доступ к такой информации должен быть ограниченным и строго контролируемым [3, 4]. Существующие подходы к защите данных, используемых в АБИС Наиболее надежным с точки зрения безопасности считается подход, подразумевающий проверку прав доступа пользователей на уровне базы данных. Во многих современных СУБД имеются встроенные средства аутентификации и авторизации пользователей, использующие комбинацию дискреционной и ролевой модели безопасности. В данном случае защитой обеспечиваются «сущности» баз данных, в том числе таблицы, представления и т. д. (они являются объектами безопасности). В качестве субъектов безопасности выступают пользователи (или их группы) АБИС. Для каждого субъекта может быть определено право доступа к объекту (или их группе): например вставка, выборка, редактирование, удаление [5, 6]. Однако такой подход к защите данных не решает всех задач, которые возникают в процессе работы библиотеки и эксплуатации АБИС, и его применение в чистом виде является недостаточным и неудобным. Прежде всего это связано со спецификой работы библиотек, которые делятся на публичные, вузовские, отраслевые, заводские и т. д. И это определяет степень открытости информации, размещаемой в АБИС, её конфиденциальность, варианты её получения читателем (далее будут рассматриваться, помимо классической книговыдачи, варианты электронной доставки объектов безопасности с использованием web-технологий). К особенностям электронной доставки объектов можно отнести большое количество защищаемых объектов, зависимость прав доступа, обеспечение возможности быстрой аутентификации нестандартным методом (IP-адрес или диапазон, аутентификация через социальные сети с подтверждением профиля читателя, посредством электронной подписи и т. д.), обеспечение возможности для работы внешних читателей с ограничением по списку объектов и по времени с обязательным соблюдением требований Закона «Об авторском праве и смежных правах» и Закона «О персональных данных». Права доступа зависят от следующих факторов: - время доступа к данным; по прошествии определенного времени доступ на чтение для субъекта должен быть закрыт, это определяется датой окончания действия читательского билета; - текущие операции чтения должны быть максимально комфортными для читателей; на время действия читательского билета или на время обучения (например, для случая вузовской библиотеки) читатель должен получать доступ к объектам, согласно его спискам разрешений, максимально быстро (желательно без дополнительных шагов по его аутентификации); - возможность работы временных внешних читателей с ограничением по спискам объектов и по времени; - доступ читателя к ограниченным спискам объектов в зависимости от свойств субъекта (читателя); например, в вузовской библиотеке может предоставляться ограниченный доступ к сформированным коллекциям учебно-методических материалов в зависимости от специальности, направления обучения, текущего курса; - личная информация читателя относится к персональным данным, и, хотя, обычно в электронных библиотечных системах хранятся общедоступные сведения (ФИО и, в худшем случае, электронная почта), доступ к этой информации должен быть ограничен; - степень конфиденциальности информации; доступ к некоторым объектам должен быть открыт только узкому кругу лиц независимо от других условий. Наличие большого количества защищаемых объектов предполагает ограничение доступа к защищаемым объектам не только на уровне таблиц, но и на уровне их записей, а также сессий web-сервера. Таким образом, для обеспечения этого требования с учетом особенностей, указанных выше, достаточно часто приходится переопределять права доступа читателей к АБИС (в вузовских библиотеках как минимум раз в год, в связи со сменой курса обучения читателей). Учитывая огромное количество в АБИС защищаемых объектов, можно сделать вывод, что обеспечить такой режим работы штатными средствами весьма затруднительно. В любом случае объем работы администратора безопасности существенно увеличится, что неизбежно приведет к ошибкам и несвоевременному переназначению прав доступа. Таким образом, актуальной является задача модификации стандартного механизма аутентификации и авторизации с целью избавления администратора безопасности от большого объема рутинной работы. Для достижения поставленной цели прежде всего необходимо разработать модель системы безопасности обобщенной АБИС. Формальное описание новой модели С учетом требований к модели разграничения доступа в АБИС была разработана следующая модель. Основные элементы: S - множество субъектов; G - множество групп субъектов (читателей, пользователей); O - множество объектов (права доступа на некоторые объекты могут быть заданы явно, для остальных объектов права определяются динамически); ACL - множество списков контроля доступа (для явного задания прав); - список контроля доступа; R - множество прав доступа; (L, ≤) - решетка уровней конфиденциальности; - метка времени, представляющая собой объект, дату/время его создания, предельную дату/время доступа к нему; I - множество меток времени (определяют предельную дату/время доступа к объекту); - функция, возвращающая значение времени, по истечении которого доступ к объекту для группы прекращается; - метка времени, представляющая собой субъект, время его создания, предельное время его доступа к АБИС; K - множество меток времени (определяют предельную дату/время доступа субъектов в АБИС); - функция, возвращающая значение времени, по истечении которого доступ субъекта в АБИС прекращается; AUTH - множество способов аутентификации субъектов; - функция, возвращающая дескриптор безопасности субъекта при выбранном способе аутентификации; - множество IP-адресов, которые могут быть привязаны к субъектам для быстрой аутентификации при соответствующем способе аутентификации ; COL - множество коллекций объектов, которые могут быть доступны субъектам при соответствующих назначенных правах доступа, при этом ; - функция, определяющая для каждого субъекта права доступа на определенный объект в зависимости от взаимоотношений между ними; - множество привилегированных групп, члены которых имеют полный доступ ко всем объектам; - функция, определяющая множество прав группы на объект ; при этом объекты могут быть сгруппированы в коллекции для упрощения назначения прав доступа, поэтому - функция, определяющая множество прав группы на коллекцию объектов ; - множество групп, к которым принадлежит субъект; - функция, определяющая множество групп, к которым принадлежит субъект ; - функция, определяющая доступность права r субъекта s на объект ; - состояние системы; Q - множество состояний системы. В данной модели используются следующие операторы: - создать объект с уровнем конфиденциальности , меткой времени . Условие выполнения: , . Новое состояние системы: , , , , , , , , , , - создать коллекцию с уровнем конфиденциальности . Условие выполнения: , . Новое состояние системы: , , , , , , , , , - включить объект в множество коллекций . Условие выполнения: , , . Новое состояние системы: , , , , , , , , , , , - создать группу с уровнем конфиденциальности , множеством прав доступа на объекты и их коллекции . Условие выполнения: , . Новое состояние системы: , , , ,, , , , , , - добавить право доступа группы на объект или коллекцию путем изменения/добавления списка контроля доступа . Условие выполнения: , . Новое состояние системы: , , , , , , , , , , - удалить право доступа группы на объект или коллекцию путем изменения/удаления списка контроля доступа . Условие выполнения: . Новое состояние системы: , , , , , , , , , , - создать субъект , принадлежащий множеству групп и использующий множество способов аутентификации . Условие выполнения: , . Новое состояние системы: , , , , , , , , , , - включить субъект в множество групп . Условие выполнения: , , . Новое состояние системы: , , , , , , , , , , , - исключить субъект из множества групп . Условие выполнения: , . Новое состояние системы: , , , , , , , , , , , - включить группу в множество привилегированных. Условие выполнения: , . Новое состояние системы: , , , , , , , , , , - исключить объект из множества коллекций . Условие выполнения: , , . Новое состояние системы: , , , , , , , , , , , - исключить группу из множества привилегированных. Условие выполнения: , . Новое состояние системы: , , , , , , , , , , - уничтожить объект . Условие выполнения: . Новое состояние системы: , , , , , , , , , , - уничтожить группу . Условие выполнения: . Новое состояние системы: , , , , , , , , , , - уничтожить субъект . Условие выполнения: . Новое состояние системы: , , , , , , , , , , - определить доступность права субъекта с уровнем доступа на объект с уровнем конфиденциальности или коллекцию с уровнем конфиденциальности . Если , то ; Иначе При использовании данной модели процедура определения доступности объекта выглядит следующим образом. Каждый субъект (пользователь АБИС) использует определённый набор способов аутентификации. Это могут быть: встроенная в АБИС система аутентификации, доменная (LDAP) аутентификация в корпоративной сети организации, аутентификация через социальные сети, упрощенная аутентификация по IP-адресу (или диапазону адресов) субъекта, аутентификация посредством электронной подписи и т. д. Любой из этих способов должен вернуть один и тот же дескриптор безопасности субъекта в АБИС. Так, например, в корпоративной сети вуза за кафедрой можно закрепить диапазон IP-адресов, и субъекты (читатели), обращающиеся из сети кафедры к АБИС вуза, будут иметь возможность быстрого доступа к учебным материалам (коллекциям объектов), относящимися конкретно к данной кафедре. В этом случае IP-адреса необходимо закрепить за группами (учебными) субъектов. Каждый субъект входит в определенные группы, имеет временные метки создания и окончания срока действия читательского билета. Если текущее время превышает предельное время активности читательского билета, доступ к АБИС прекращается. Группы могут быть привилегированными и непривилегированными (обычными). Под группой может пониматься и учебная группа (в случае вузовской АБИС). Каждая группа обладает определенным уровнем конфиденциальности. Права доступа субъектов определяются как совокупность прав, явно указанных ему, и прав, указанных для групп. При попытке субъекта совершить определенную операцию над объектом происходит проверка доступности данной операции. Если пользователь входит в одну из привилегированных групп, он имеет полный доступ к любому объекту. Иначе происходит проверка меток времени. Если текущее время превышает предельную дату/время доступа к объекту, субъект не имеет права доступа к нему. Следующим шагом является проверка явно указанных прав и меток конфиденциальности. Если одна из групп, в которые входит пользователь, обладает правами на данную операцию и уровень доступа субъекта больше либо равен уровню конфиденциальности объекта (коллекции), доступ гарантируется. Вторым условием гарантии доступа является наличие возможности осуществлять данную операцию исходя из взаимоотношений между объектом (коллекцией) и субъектом непосредственно (при этом не учитываются уровни конфиденциальности). Таким образом, в систему заведомо добавляются необходимые группы со всеми атрибутами и списком прав доступа. Наличие меток конфиденциальности обусловливается обширным списком условий, по которым доступ должен или не должен предоставляться, а также большим количеством объектов. Разделение пользователей на группы необходимо для того, чтобы разграничивать права в зависимости от должности пользователя и места пребывания пациента. Для реализации представленной модели нами предлагается использовать механизм триггеров, в которых должна быть реализована логика расширенной проверки прав пользователя на выполнение операции в соответствии с разработанной моделью, а также расширить базовый функционал реляционной базы данных возможностями, предлагаемыми web-сервером и языками разработки web-приложений (php, ASP, ASP.NET и т. д.). Блок-схема расширенной проверки прав пользователя на выполнение операции представлена на рис. 1, пример реализации - на рис. 2. В частности, для работы с IP-адресами в PHP можно использовать суперглобальный массив $_SERVER['REMOTE_ADDR'], в ASP - системный объект Request.ServerVariables("remote_addr"). Возможность аутентификации посредством Active Directory по протоколу LDAP или любой другой способ также могут быть реализованы программно. Рис. 1. Блок-схема расширенной проверки прав пользователя на выполнение операции Рис. 2. Пример окна web-приложения, предоставляющего доступ к коллекции и использующего предложенную модель безопасности, в том числе аутентификацию по IP-адресам, штрих-коду и паролю читательского билета, внешнюю аутентификацию (по протоколу LDAP) В соответствии с представленной моделью безопасности нами для научно-технической библиотеки Сибирского государственного индустриального университета разработано web-приложение, работающее совместно ИБС «Virtua» корпорации «Innovative», которое расширяет базовый функционал системы до необходимого уровня. Пример окна приложения, предоставляющего доступ к одной (монографии учёных СибГИУ) из многих коллекций, представлен на рис. 2. Приложение написано на ASP.NET с использованием C#. Администраторская панель приложения позволяет определять дополнительные параметры безопасности, предусмотренные предлагаемой моделью. Заключение Предполагается, что применение предложенной модели управления доступом типовой библиотечной информационной системы позволит существенно снизить вероятность возникновения ошибок настройки прав доступа, а уровень обеспечения безопасности данных системы существенно возрастет. Дальнейшее развитие предложенной модели в перспективе предполагает сокращение объема работы администратора безопасности системы.