Размещено на http://www.allbest.ru/

Оглавление

1. Семантические базы данных

1.1 Обеспечение безопасности семантических баз данных

1.2 Средства обеспечения безопасности

2. Определение уровней безопасности элементов, классов, свойств, индивидов и триплетов онтологий

2.1 Пример контроля результатов логических выводов в СБД

3. Предоставление доступа к хранилищам данных

Заключение

Список используемых источников

1. Семантические базы данных

Понятие семантической БД

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

Под семантической БД (СБД) понимается база данных, в которой хранятся онтологии, семантические метаданные и множество логических правил. Она может быть описана, как DBS = {O, M, R}, где O - онтология, М - семантические метаданные, R - множество логических правил.

Множество логических правил R используется для получения логических выводов на основе известных данных. Данное множество может быть разделено на два подмножества R = {R1, R2}, где R1 - множество онтологических логических правил, включённых в язык описания онтологий; R2 - множество пользовательских логических правил, созданных разработчиками и/или пользователями для получения возможных логических выводов.

Основные элементы семантических БД показаны на рисунке 1.6.

Рисунок 1.6. Структура семантической базы данных

В семантических БД онтологии, метаданные представляются в виде множеств RDF-триплетов, хранящихся в RDF-хранилищах (RDF stores).

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

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

Прежде всего, отметим несоответствие некоторых терминов в лингвистике и информатике. Лингвисты выделяют два противопоставляемых вида элементов семантики - значения и смыслы. Значение лингвистического знака понимается как нечто стабильное, что можно сначала установить, выяснить, а затем знать. Смысл приходится всё время искать, устанавливать, разгадывать. В информатике термин "значение" уже занят. Говоря "переменная имеет значение" подразумеваем не семантику этой переменной, а присваивание ей конкретного экземпляра данных, или означивание, или создание экземпляра переменной, содержащего этот элемент данных. Поэтому элементы семантики мы всегда будем называть смыслами, а "стабильность" или "контекстность" или "вариативность" смыслов будем задавать через классификацию смыслов или вводя в них дополнительные свойства.

Давно известно, что значения и смыслы -- это внеязыковые сущности. В частности, для перевода с одного естественного языка на другой ЕЯ может создаваться специальный язык функций для представления семантики, в который транслируются фразы исходного языка. А уже с этого промежуточного языка осуществляется трансляция на второй ЕЯ. Тезис о внеязыковой природе смыслов мы трансформируем для баз данных в несколько смягчённую форму как утверждение о возможности разделения данных и смыслов.

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

Вернемся к терминологии баз данных. Существует безосновательная, но устойчивая традиция выделять некоторые модели и базы данных как семантические (и мы тут не без греха). Так модель "сущность-связь" считается семантической моделью, по-видимому, по сравнению с табличными моделями данных. Однако, семантика, обычно ограниченная, есть в любых моделях данных. Поэтому, еще в 1988 году Э. Кодд отметил, что "ярлык "семантическое" не должен интерпретироваться в каком-либо абсолютном смысле". В тех же табличных базах семантику определяют, в частности, ключи и ограничения целостности. В базах данных с декларативными языками всегда реализуется операционная семантика, представляемая, например, планами исполнения SQL. Так что следует говорить только о большей или меньшей насыщенности моделей и баз данных семантикой.

Как же отделить элементы семантики, хранимые в базе, от обычных данных? По очень простому признаку: элементы семантики, они же смыслы, обладают активностью. Данные всегда пассивны.

Поясним сказанное на простом примере. Пусть, необходимо выбрать все записи из таблицы, например, инструкцией SELECT * FROM emp. Очевидно, СУБД должна сначала проверить существование таблицы emp по словарю и, может быть, установить, имеются ли у действующего пользователя необходимые права на эту таблицу. Если таблица не существует или недоступна, выдать сообщение об ошибке. В противном случае, установить список столбцов emp и только после этого приступить к выборке данных. Как много делается того, что прямо не было указано! Всё это обеспечивает активность, которой обладают метаданные.

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

Заметим, что активность смыслов выводит модели данных со смыслами за рамки обычных чисто алгебраических моделей данных.

RDF-хранилища

Семантические БД строятся на основе RDF-хранилищ. Под RDF-хранилищем (RDF-Stores, RDF-triple store) понимается информационная подсистема, предназначенная для хранения и предоставления доступа к RDF-данным(триплетам).

По своей архитектуре RDF-хранилища делятся на два типа: реальные RDF-хранилища (native stores) и RDF-хранилища, поддерживаемые реляционными СУБД (DBMS-backed stores).

Реальные RDF-хранилища (native stores) полностью реализуют ядро БД, которое оптимизированно для обработки RDF-данных и работает независимо от любой другой системы управления базой данных (СУБД). В этих хранилищах данные хранятся непосредственно в файловой системе, в одном файле или разделяются на несколько файлов.

RDF-хранилища, поддерживаемые реляционными СУБД (DBMS-backed stores), используются для выполнения хранения и поиска данных существующих СУБД.

Различаются два вида модели хранения: общая схема и схема конкретной онтологии.

Общая схема RDF-хранилища может состоять из различных таблиц для хранения триплетов, например таблицы, состоящей из трёх столбцов: субъекта, предиката и объекта. При этом необходимо соблюдать принципы нормализации схемы такой БД путём хранения всех URI-идентификаторов и литералов в отдельных таблицах. Такой подход с использованием общей схемы обладает гибкостью представления схемы хранения, однако требует объединения большого количества таблиц для ответа на сложные запросы.

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

§ Для каждого класса онтологии (горизонтальное представление) создаётся отдельная таблица, каждый столбец которой соответствует одному свойству класса, а каждая строка - одному экземпляру класса. Основным недостатком такого подхода является необходимость реструктуризации таблиц БД при изменении структуры онтологии.

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

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

Известными реальными RDF-хранилищами (native stores) являются такие системы, как: 4/5store [46], AllegroGraph [47], OWLIM [48], А примерами RDF-хранилищ, основанных на реляционных СУБД, являются следующие: 3store [49], Jena SDB [39], Oracle 11g [50], а также гибридные хранилища - RedStore [51], Sesame [38], Virtuoso [52], BigData [53].

Области применения RDF:

объединение данных из различных источников, не прибегая к созданию специализированных программ.

необходимость дать другим доступ к вашим данным.

необходимость децентрализовать ваши данные так, чтобы ими всеми не "владел" кто-то один.

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

Имена бывают двух типов. Глобальные имена, имеющие всюду один и тот же смысл, всегда имеют вид URI (Универсальных Идентификаторов Ресурсов). Синтаксис (формат) URI может быть таким же, как у адреса веб-сайта; вы можете встретить RDF-файлы, где используются URI структурой напоминающие URL; такие URI задают глобальные имена для каких-нибудь сущностей. Тот факт, что это похоже по виду на веб-адрес - чистое совпадение. Может быть, действительно существует веб-сайт с таким адресом, а может быть, его не существует, - это не имеет значения. Есть и другие типы URI, не начинающиеся с http:. URN - один из подтипов URI, и он используется, например, для идентификации книг по их ISBN-номеру и т.п. Другой универсальный тип URI - это TAG; пример такого URI - tag:govtrack.us,2005:congress/senators/frist. URI используются для глобальных имён потому, что они позволяют разбить пространство всех возможных имён на блоки, за которыми закреплены владельцы.

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

Так как URI могут быть довольно длинными, то в форматах, используемых для представления RDF, они обычно сокращаются, используя перенятый из XML механизм "пространств имён". Именно поэтому в именах: john, :hasMother и других сущностей в приведённых примерах стоят двоеточия - они означают, что используются сокращённые имена. В примерах им соответствуют полные имена http://www.example.org/#john, http://www.example.org/#hasMother и т.д.

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

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

Граф - это то же самое, что и сеть. Граф состоит из узлов, соединённых рёбрами. Например, в Интернете узлы - это компьютеры, а рёбра - соединяющие их сетевые шнуры. В RDF узлы - это имена (но не сами сущности), а рёбра - утверждения. Каждая стрелка (ребро) - это RDF-утверждение: имя у начала стрелки - это подлежащее утверждения, имя у конца стрелки - его дополнение, и имя у самой стрелки - сказуемое[5]. Когда RDF представлен в виде графа, он содержит всю ту же информацию, что и выписанный в виде троек-утверждений; но графическое представление позволяет человеку легче увидеть структуру описываемых данных.

Для хранения RDF-данных используются два основных вида хранилищ: специализированные (native, "родные", "нативные") и не специализированные (non-native). Специализированные хранилища позволяют достичь большей степени оптимизации, но более трудоёмки в проектировании, так как строятся специально для работы с RDF. Остальные хранилища более просты в проектировании (например, за счёт использования механизмов реляционных СУБД или решений NoSQL), но менее оптимизированы под работу с RDF. Специализированные хранилища делятся по способности оперировать с данными, лишь целиком находящимися в оперативной памяти (in-memory) или же способные использовать и внешнюю память (например, жёсткий диск). Системы для работы с RDF разрабатываются как в рамках исследований, так и для производственного использования. К основным специализированным хранилищам, пригодным для производственного использования, относятся:

решения от Oracle

сервер приложений Virtuoso

4Store

Stardog

Blazegraph (ранее Bigdata)[7]

GraphDB (ранее OWLIM)

Sesame

Jena TBD

Allegrograph

Языки запросов к семантическим данным

Существуют много языков запросов к семантическим данным, таких, как N3QL [26], RDFQ [40], RDQL [41], SeRQL [42] и SPARQL [43].

Наиболее распространённым языком запросов к семантическим данным является язык SPARQL (Semantic protocol and RDF query language) разработанный организацией W3C. В сравнении с другими языками, SPARQL обладает следующими преимуществами [44]:

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

§ обладает возможностями формирования запросов к обязательным и необязательным графовым шаблонам вместе с их конъюнкциями и дизъюнкциями.

§ поддерживает тестирование расширенного значения и ограничение запросов с помощью исходного RDF-графа [45];

§ результаты запросов SPARQL могут быть представлены в виде результирующих наборов или RDF-графов.

Большая часть запросов SPARQL включает набор шаблонов триплетов, который называется основным графовым шаблоном. Шаблоны триплетов подобны RDF-триплетам, за исключением того, что каждый субъект, предикат и объект может быть переменной. Основной графовый шаблон соответствует подграфу RDF-данных, следовательно, RDF-термины данного подграфа могут быть заменены на переменные, а результатом также является RDF-граф. запрос программирование безопасность

1.1 Обеспечение безопасности семантических баз данных

Проблемы обеспечения безопасности

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

В настоящее время был разработан набор моделей, методов и алгоритмов обеспечения безопасности операционных систем [72 - 77] и реляционных баз данных [78 - 81], но они не могут быть применены для семантических БД, так как в СБД имеются сильная иерархическая связанность между элементами и возможность получения новой информации пользователями на основе известных фактов путём использования логических правил [3].

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

§ контроль доступа пользователей к отдельным элементам онтологий;

§ контроль доступа пользователей к триплетам и их компонентам (субъекту, предикату, объекту);

§ контроль доступа пользователей к RDF-графам в СБД.

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

Кроме этого, как уже было отмечено, в семантических БД на основе известных данных с помощью логических правил можно получать результаты логических выводов [82]. С использованием этого пользователи U могут получить информацию, к которой они не имеют права доступа. Вследствие этого, актуальной является задача контроля результатов логических выводов в семантических БД. В настоящее время существует метод контроля логических выводов в семантических БД путём контроля доступа пользователей к логическим правилам [90]. Данный метод не гарантирует, что пользователи будут получать результаты логических выводов в соответствии с их правами доступа.

Таким образом, можно выделить следующие две основные группы задач, которые необходимо решить для обеспечения безопасности семантических БД:

§ Контроль доступа пользователей к отдельным элементам СБД.

§ Контроль результатов логических выводов в СБД.

Средства контроля доступа

В настоящее время уже известны следующие методы, модели и системы контроля доступа пользователей к СБД:

§ Подсистема безопасности в хранилище BigData [83], созданная на основе модели контроля доступа пользователей к именованным RDF-графам.

§ Модель AC4RDF[84], разработанная на основе методов контроля доступа пользователей на уровне триплетов RDF-хранилища.

§ Подсистема безопасности AllegroGraph [91], разработанная на основе фильтров безопасности.

§ Система RAP (Policy-Based Access Control for an RDF Store) [88], созданная на основе политики контроля доступа к RDF-хранилищу.

§ Методы контроля доступа пользователей к онтологии [85 - 89].

§ Контроль логических правил [90].

Модель безопасности RDF-хранилища на уровне RDF-графов

В данной модели контроль доступа пользователей к данным RDF-хранилища выполняется следующим образом:

1. Все триплеты собираются в наборы триплетов, которые называются именованными графами.

2. Каждому именованному графу задаются уровень безопасности.

3. Каждому пользователю задаются роль и права доступа.

4. Пользователь U может иметь доступ и выполнить разные операции над триплетами в соответствии с политикой безопасности, заданной именованному графу, которому эти триплеты принадлежат.

Данная модель обладает высокой эффективностью в случае, когда в каждом именованном графе сгруппирована большая группа триплетов. Однако если в именованном графе имеются только одно или два утверждения, то используется модель "statement level provenance" [92], которая позволяет определить происхождение каждого триплета с помощью SPARQL-запросов, таким образом можно реализовать политику безопасности для триплетов.

Данная модель использована для обеспечения безопасности данных в RDF-хранилище BigData.

Модель AC4RDF

Модель Access Control for RDF stores (AC4RDF) реализует контроль доступа пользователей на уровне триплетов RDF-хранилища. Данная модель используется для обеспечения безопасности RDF-хранилища Sesame. Это выполняется путём проверки прав пользователей, в результате которой определяется, кто имеет права доступа к RDF-триплету, хранящемуся в RDF-хранилище.

В данной модели, права доступа описываются владельцем RDF-данных с помощью редактора PolicyEditor [93], который позволяет задать доступ пользователей к каждому RDF-утверждению или к графу RDF-данных, которые хранятся в RDF-хранилище.

Общая архитектура системы AC4RDF показана на рисунке 1.9.

При отправке пользователями U запроса q к RDF-хранилищу модуль Access Control находит информацию об учётной записи пользователей и использует модуль "политик Protune" [92] для выбора политики, применяющейся для данного запроса пользователей. Модуль Rei перезаписывает запрос в соответствии с определённой политикой. Переписанный запрос отправляется в RDF-хранилище и пользователи U могут получить ответы на данный запрос.

Рисунок 1.9. Общая архитектура системы AC4RDF

Подсистема безопасности AllegroGraph 4.11

В семантической БД AllegroGraph 4.11 для контроля доступа пользователей к RDF-хранилищам применяется подсистема безопасности, построенная на основе фильтра безопасности (filter secrutiry) [91], который создаётся администратором хранилища.

Администратор имеет все права для управления данными и создания прав доступа для регистрированных пользователей. Пользователю задаётся роль, значение которой выбирается из множества {Superuser, Start sessions, Evaluate arbitrary code, Control replication} и права - из множества {чтение, запись, модификация или удаление}.

По фильтру безопасности администратор задаёт пользователям права доступа к каким-либо хранилищам, категориям данных. Кроме этого, пользователи U могут иметь доступ только к конкретному триплету или ко всем триплетам, в которых содержится конкретный предикат, субъект или объект.

Пример политики безопасности: пользователи U имеют права на просмотр всех триплетов, в которых содержится предикат rec:Sarary.

Система RAP

В процессе работы с триплетами в RDF-хранилище пользователь U может удалить или добавить основные триплеты, которые являются элементами онтологий или общей схемы, следовательно, структура схемы (онтологии) данных нарушена. Для решения данной проблемы была разработана система контроля доступа пользователей к RDF-хранилищу, основанная на политиках, определяющих права доступа пользователей [88].

Все действия пользователей над хранилищем проходят через модуль политики системы RAP, чтобы определить действие "разрешено" или "запрещено". В системе RAP все триплеты метаданных и политики доступа к ним хранятся в самом RDF-хранилище (рисунок 1.11).

Система RAP построена на основе фреймворка Jena, в которой поддерживает средство анализа и выполнения простого логического вывода на RDF, RDFS и OWL. Политики системы RAP задаются как правила, которые используются в её онтологии для работы со средствами логического вывода RETE [94]. Общая архитектура данной системы показана на рисунке 1.12. Система RAP поддерживает выполнение пользователями различных операций, таких, как добавления, удаление и модификация RDF-триплетов в соответствии с их правами доступа и с корректностью схемы данных в RDF-хранилище.



Рисунок 1.11. Данные в RDF-хранилище

Рисунок 1.12. Архитектура системы RAP

Методы контроля доступа к онтологиям

Проблема обеспечения безопасности онтологии рассматривалась многими авторами. Qin L. и Atluri V. [85] предложили схему политики безопасности для управления доступом к понятиям онтологий и их экземплярам. Понятиям онтологии создаются уровни безопасности, а пользователям - уровни доступа.

Управление доступом пользователей к онтологиям выполнено путём сравнения уровней безопасности понятий с уровнями доступа пользователей. Если уровень доступа пользователей обльше уровней безопасности понятий, то пользователи имеют доступ к понятиям онтологии, следовательно, они могут иметь доступ ко всем экземплярам данных понятий.

Данная система может выполнять контроль только на уровне понятий онтологии, но не понимает семантику и отношения между элементами онтологий.

Yialelis N., Lupu E. и Sloman M. [85] создали систему контроля доступа пользователей к отдельным элементам онтологии, построенную на основе подхода CLP (constraint logic programming - логическое программирование в ограничениях). В данной системе создана модель, в которой содержатся схемы онтологий и семантических данных. Данные в этой модели представляются в виде RDF-дерева, на основе которого выполняются все операции, позволяющие контролировать доступ пользователей к элементам онтологии.

Кроме вышеперечисленных методов и систем контроля доступа пользователей к онтологии и RDF-хранилищам также существуют и другие методы, описанные в [88, 89].

Контроль логических правил

В настоящее время также предложены и разные методы контроля доступа к логическим правилам [90]. В основном все они основаны на использования уровней доступа для логических правил. В общем виде они могут быть описаны следующим образом: Пусть DBS = {O, М, R}, где O - онтологии; М - семантические метаданные; R = {r1, ..., rn} - множество логических правил. Тогда используется следующая политика безопасности семантических БД, включающих логические правила:

1. Определяется множество уровней безопасности SL = {sl1, ..., slk}.

2. Каждому пользователю U задаётся уровень доступа slU ? SL для выполнения логических правил.

3. Каждому логическому правилу ri ? R задаётся уровень доступа slri ? SL.

4. Если slU ? slri, то пользователь U может выполнять логическое правила ri; иначе он это правило использовать не может.

Данный метод позволяет пользователю U выполнять логические правила в соответствии с его уровнем доступа, но не гарантирует, что он будет получать результаты в соответствии с его правами доступа. Это связано с тем, что в семантических БД данным могут быть заданы уровни безопасности, которые превышают уровень доступа пользователей к правилам slU.

1.2 Средства обеспечения безопасности

Для каждого пользователя U семантической БД в системе поддержки безопасности создаётся учётная запись, содержащая сведения, которые пользователь U сообщает о себе системе обеспечения безопасности. Основными элементами учётной записи пользователя являются имя пользователя и пароль доступа. Значение пароля доступа хранится в зашифрованном или хэшированном виде [11] для обеспечения его безопасности.

Учётная запись может содержать также дополнительные данные, описывающие информацию о пользователях, такие, как имя, фамилия, отчество, пол, дата рождения, e-mail адрес, домашний адрес, рабочий адрес, номер домашнего теле- фона и т.п.

Учётная запись пользователей хранится в самой семантической БД.

Под политикой безопасности управления доступом (security policy ассеss control) понимается совокупность правил управления доступом пользователей к защищаемой информации (данным).

В настоящее время существует много политик безопасности. Наиболее известными являются дискреционная, мандатная и ролевая политики безопасности [9]. На основе данных политик создаётся система обеспечения безопасности работы с семантическими БД [5], в которой политика безопасности основывается на следующих правилах:

1. существует набор ролей Ur и прав доступа Up;

2. создаётся множество меток уровней безопасности MS;

3. всем данным в DBS задаются уровни безопасности slD;

4. каждому пользователю U задаётся уровень доступа slU;

5. владелец может указать уровень безопасности slD для своих данных.

6. пользователь имеет доступ к данным тогда, когда ему заданы права доступа к данным дискреционной политикой или slU ? slD.

Для определения возможности получения доступа пользователей к данным СБД выполняется сравнение уровня доступа пользователей slU с уровнями безопасности данных slD, хранящихся в СБД.

Система поддержки безопасности работы с семантическими БД

Зарегистрированные пользователи U, имеющие уровень доступа slU и права доступа Up, могут отправлять SPARQL-запросы q к семантической БД для просмотра, получения, добавления или изменения их данных D и для выполнения логических правил r для получения результатов логических выводов rL.

Семантическая БД считается безопасной, если удовлетворяет следующим условиям [10]:

· пользователь U может иметь право доступа на просмотр данных D, если slU ? slD;

· пользователь U имеет права на изменение, удаление и добавление данных D, если slU ? slD и Up = {просмотр, изменение, удаление, добавление};

· пользователь U может выполнять логические правила r, если slU ? slr;

· пользователь может получить результаты логических выводов rL, если slU ? slrL.

На рисунке 1 показан общий процесс обеспечения безопасности СБД. Процесс обеспечения безопасности СБД выполняется следующим образом:

Если запрос пользователей к СБД является прямым запросом, то модуль "управление доступом" выполняет следующие действия:

· проверяет уровни доступа пользователей;

· определяет уровни безопасности полученных ответов на запрос;

· даёт результаты пользователям в соответствии с их уровнями доступа.

Рисунок 1 - Процесс обеспечения безопасности СБД

Если запрос является логическим запросом, то модуль "подсистема выполнения логических выводов" выполняет следующие действия:

· проверяет уровни доступа пользователей;

· определяет возможность выполнения логических правил; выполняет логические выводы;

· обнаружит нарушения результатов логических выводов; контролирует результаты логических выводов;

· даёт результаты пользователям в соответствии с их уровнями доступа.

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

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

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

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

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

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

Механизм представлений, который был впервые реализован в одной из наиболее развитых реляционных СУБД System R (SQL/DS) [1], основывается на выделении каждому пользователю собственной подсхемы схемы базы данных и работе только с этой подсхемой. Так, если БД содержит отношения АНКЕТА и ЗАРПЛАТА со схемами АНКЕТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ДАТА-РОЖДЕНИЯ, ПОЛ, СЕМЕЙНОЕ-ПОЛОЖЕНИЕ, ДОЛЖНОСТЬ) и ЗАРПЛАТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ОКЛАД-ПО-ДОЛЖНОСТИ, НАДБАВКА-ЗА-ВЫСЛУГУ-ЛЕТ, ПРЕМИЯ, НАЛОГ, ОБЩАЯ-СУММА), то одной группе пользователей могут быть выделены подсхемы отношений АНКЕТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО.ДОЛЖНОСТЬ) и ЗАРПЛАТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ОКЛАД-ПО-ДОЛЖНОСТИ) а другой - только подсхема первого отношения АНКЕТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ДАТА-РОЖДЕНИЯ). Администрация БД работает с полными схемами обоих отношений. При этом, естественно, значения атрибутов, не входящих в выделенные подсхемы, соответствующим пользователям недоступны.

Механизм модификации запроса, поддерживаемый, в частности, другой эффективной реляционной СУБД INGRES [2,3], основывается на принудительном (невидимом пользователю) приформировывании к тексту запроса дополнительных условий отбора, исключающих возможность получения сведений, доступ к которым пользователю запрещен. СУБД обрабатывает модифицированный таким образом запрос и выдает пользователю ответ, в котором содержатся только разрешенные элементы информации. Указанные условия отбора могут быть установлены и, как правило, устанавливаются индивидуально для каждого пользователя. Так, применительно к БД, содержащей отношения с приведенными выше схемами, подобные условия могут иметь следующий вид: ДОЛЖНОСТЬ = (МНС,СНС,ЗАВЕДУЮЩИЙ СЕКТОРОМ) & ДАТА-РОЖДЕНИЯ >31.12.1931 для отношения АНКЕТА и ОБЩАЯ СУММА < 1500 для отношения ЗАРПЛАТА. Первое позволяет выдавать пользователю сведения только о младших и старших научных сотрудниках и заведующих секторами, родившихся в 1932-м и последующих годах. Второе условие пзволяет выдавать сведения о заработной плате только тех сотрудников, которые получают менее 1500 рублей. При поступлении от пользователя запроса вида АНКЕТА: ДАТА-РОЖДЕНИЯ<01.01.1963 & ДОЛЖНОСТЬ = (ЗАВЕДУЮЩИЙ СЕКТОРОМ, ЗАВЕДУЮЩИЙ ОТДЕЛОМ) он будет преобразован в АНКЕТА: ДАТА-РОЖДЕНИЯ<01.01.1963 & ДОЛЖНОСТЬ = (ЗАВЕДУЮЩИЙ СЕКТОРОМ, ЗАВЕДУЮЩИЙ ОТДЕЛОМ) & ДОЛЖНОСТЬ = (МНС,СНС,ЗАВЕДУЮЩИЙ СЕКТОРОМ) & ДАТА-РОЖДЕНИЯ >31.12.1931. При этом пользователь получит анкетные данные только о заведующих секторами, родившихся в 1932-1962 г.г., тогда как затребованные им сведения о заведующих отделами, родившихся до 1962 г., а также о заведующих секторами, родившихся до 1932 г., не будут включены в ответ.

Описанные механизмы, вообще говоря, не делают различия между операциями, выполняемыми над защищаемой информацией: считается, что информационный объект либо доступен пользователю, либо недоступен, причем в первом случае пользователь может выполнять над объектом любые операции, а во втором - никакие. Более тонкие механизмы реализуют избирательную защиту информации, когда для каждой операции и каждого пользователя определяется свое множество информационных объектов, над которыми она может быть выполнена пользователем. Например, одному из пользователей могут быть разрешены внесение, удаление и отбор любых элементов отношения АНКЕТА и отбор любых элементов отношения ЗАРПЛАТА. В это же время другому пользователю может быть разрешено внесение и удаление элементов отношения АНКЕТА, значениями атрибута ДОЛЖНОСТЬ, в которых не являются ЗАВЕДУЮЩИЙ ОТДЕЛОМ и ЗАВЕДУЮЩИЙ СЕКТОРОМ, а также отбор элементов отношения ЗАРПЛАТА по сотрудникам, не занимающим указанные должности.

Механизмы обеспечения безопасности контекстно-чувствительной информации существенно сложнее и в настоящее время находятся в стадии теоретической проработки и экспериментальных программных реализаций [4].

Основные требования по безопасности в базах данных

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

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

Требования по управлению доступом в базах данных

Под управлением доступом в БД понимается защита данных в БД от НСД. Обычно выделяют следующие требования по безопасности, связанные с доступом в БД.

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

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

3. Управляемость доступом. Пользователь должен иметь доступ только к тем данным, для работы с которыми он имеет полномочия. При этом пользователи могут быть ограничены различными типами доступа (чтение, модификация, добавление, удаление и т.п.) к одним и тем же данным.

Требования по управлению целостностью в базах данных

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

С поддержанием целостности связаны следующие основные требования.

1.Обеспечение достоверности. В каждый элемент данных информация заносится точно в соответствии с описанием этого элемента. Должны быть предусмотрены механизмы обеспечения устойчивости элементов данных и их логических взаимосвязей к ошибкам или неквалифицированным действиям пользователей.

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

3. Восстановление. Хранимые в БД данные должны быть устойчивы по отношению к неблагоприятным физическим воздействиям (аппаратные ошибки, сбои питания и т.п.) и ошибкам в программном обеспечении. Поэтому должны быть предусмотрены механизмы восстановления за предельно короткое время того состояния БД, которое было перед появлением неисправности.

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

2. Определение уровней безопасности элементов, классов, свойств, индивидов и триплетов онтологий

Согласование уровней безопасности классов онтологии.

· В онтологиях O нет классов сx, не имеющих уровней безопасности slСx .

· Уровень безопасности slCx класса сx должен быть больше или равен уровню безопасности его суперкласса slCsup, slCx ? slCsup.

· Если класс сx связывается с классом сy, имеющим уровень безопасности slу, с помощью отношений owl:sameAs, owl: equivalentClass, то

slСx = MAX(slСx, slCу);

Согласование уровней безопасности свойств онтологии.

· В онтологиях O нет свойств px, не имеющих уровней безопасности slPx .

· Уровень безопасности slPx свойства px должен быть больше или равен уровню безопасности его суперсвойства slPsup, slPx ? slPsup.

· Если px связывается с другими свойствами py по отношением rdfs:subPropertyOf, owl:inverseOf, owl:equivalentProperty, owl:InverseFunctionalProperty, то slPx = MAX(slPx, slPy), где slPy - уровень безопасности свойства py .

Согласование уровней безопасности индивидов.

· В семантических БД каждому индивиду ix задан начальный уровень безопасности slIx .

· Уровень безопасности slIx индивида ix должен быть больше или равен уровню безопасности slСy класса, которому он принадлежит, slIx ? slCy .

В онтологии O имеется множество классов C = {с 1, ..., сm} и множество заданных им уровней безопасности SLC ={slC1, ..., slCm}, где slC1, ..., slCm - уровни безопасности классов c1, ..., cm соответственно.

Уровень безопасности slСx класса сx ? С может быть определён следующим образом:

1. если уровень безопасности slСx класса сx не задан, то slСx = 0;

2. если сх связывается с сy отношением owl:sameAs, owl: equivalentClass, то slСx = MAX(slСx, slСу), где slСу - уровень безопасности класса cy ;

3. если класс сx является подклассом класса сz, который имеет уровень безопасности slСz, то slСx = MAX(slСx, slСz).

Входными данными являются: онтология O, множество классов C и соответствующие им уровни безопасности SLC.

Выходными данными является уровень безопасности slСx класса сx .

Вначале в онтологии O свойствам P = {p1, ..., pn} задаются начальные уровни безопасности SLP ={slP1, ..., slPn}, где slP1, ..., slPn - соответствующие уровни безопасности свойств p1, ..., pn.

Уровни безопасности slPx свойства px ? P согласуются между собой следующим образом:

1. если уровень безопасности slPx свойства px не задан, то slPx = 0;

2. если свойство pх связано со свойством py одним из отношений owl:inverseOf, owl: equivalentProperty, owl:SymmetricProperty или owl:InverseFunctionalProperty, то slPx = MAX(slPx, slPy), где slPy - уровень безопасности свойства py ;

3. если свойство px является подсвойством свойства pz, который имеет уровень безопасности slPz, то slPx = MAX(slPx, slPz).

Входными данными являются онтология O, множество свойств P = {p1, ..., pn} и их соответствующие уровни безопасности SLP.

В семантических БД DBS имеется множество индивидов IDB = {i1, ..., ik} и множество их начальных уровней безопасности SLI ={slI1, ..., slIk}, где slI1, ..., slIк - уровни безопасности индивида i1, ..., ik соответственно.

Уровень безопасности slIx индивида ix ? iDB может быть определён следующим образом:

· Если начальный уровень безопасности slIx индивида ix не задан, то slIx = 0.

· Если индивид iх включается в класс cy, имеющий уровень безопасности slCy, и если slIx < slCy, то slIx = slCy .

Входными данными являются: С = {с 1, ..., сm} - множество классов, SLC = {slC1, ..., slCm} - множество уровней безопасности классов, I = {i1, ..., ik} - множество индивидов, SLI = {slI1, ..., slIк} - множество уровней безопасности индивидов.

Выходными данными является множество индивидов и их соответствующих уровней безопасности.

В семантических БД компоненты каждого триплета t = [s, p, o] (s - субъект, p - предикат, o - объект) могут иметь разные уровни: sls - уровень безопасности субъекта, slp - уровень безопасности предиката, и slo - уровень безопасности объекта. Тогда общий уровень безопасности всего триплета slt будет определяться как максимальное значение уровней безопасности его компонентов (sls, slp, slo):

slt = MAX {sls, slр, slo}, (1)

Пара безопасности триплета sc триплета t описывается следующим образом:

sc = {t, slt}. (2)

Каждый триплет семантических метаданных может быть определён как TМ = {(C | I), (B | A), (C | I | H)}. Следовательно, для любого триплета t = [s, p, o] ? M всегда могут быть определены функции f1, f2, f3, позволяющие определять соответствие каждого компонента триплета с одним из элементов онтологии следующим образом:

f1: s > s' ? (C | I); (3)

f2: p > p' ? (B | A); (4)

f3: o > o' ? (C | I | H). (5)

Из формул (3) - (5) может быть определена обратная функция f = (f1 -, f2 -, f3 -), отображающая набор троек [s' ? (C | I), p' ? (B | A), o' ? (C | I | H)] в триплет t = [r, p, v] ? M, которая обозначается следующим образом:

f: [s' ? (C | I), p' ? (B | A), o' ? (C | I | H)] > t = [s, p, o] ? M. (6)

Если набор троек [s' ? (C | I), p' ? (B | A), o' ? (C | I | H)] обозначить как pt = [s' ? (C | I), p' ? (B | A), o' ? (C | I | H)], тогда функция отображения может быть переписана следующим образом: f: pt > t = [s, p, o] ? M.

Определение 1. В онтологии O функция f: pt > t = [s, p, o] ? M позволяет связать три элемента pt = [s' · (C | I), p' ? (B | A), o' ? (C | I | H)] онтологии с одним триплетом t = [s, p, o], который содержится в метаданных.

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

Каждый элемент тройки pt = [s', p', o'] имеет согласованный уровень безопасности sls', slр', slo' (в результате решения задачи 1). Следовательно, pt имеет следующий согласованный уровень безопасности slpt = MAX(sls', slр', slo').

В результате отображения функции f: pt > t каждый триплет t будет иметь уровень безопасности slpt.

Определение 2. Пусть pt и t являются триплетами. Если существует модель отображения f: pt > t и pt имеет уровень безопасности slpt, то триплету t задаётся уровень безопасности slpt.

В семантических БД, если триплет t имеет начальный уровень безопасности sl't, то в результате отображения f согласованный уровень безопасности триплетов t определяется следующим образом:

slt = MAX (slpt, sl't). (7)

Тогда с помощью функции f множество пар всех триплетов TM ? M и их соответствующих уровней безопасности определяется следующим образом:

SCF ={TM, SLT} = {TM, MAX (slpti, sl'ti)}, (8)

где TM - множество всех триплетов метаданных, SLT = {slt1, ..., sltn} - множество уровней безопасности всех триплетов метаданных в результате отображения.

Может быть определено множество пар безопасности всех триплетов онтологии:

SСO = {TO, SLO} = {TO, (SLC | SLP)}, (9)

где ТО - множество всех триплетов онтологии O, а SLO ? множество согласованных уровней безопасности триплетов онтологии.

Вначале триплетам метаданных М задаются начальные уровни безопасности SLM = {slt1, ..., sltn}. Множество пар безопасности триплетов метаданных определяется следующим образом:

SСM = {TM, SLM} = {TM, {slt1, ..., sltn}}. (10)

Входными данными алгоритма являются: SLС, SLP, SLI - множества согласованных уровней безопасности множеств классов С, свойств P и индивидов I соответственно; TМ = {ti, ..., tn} - множество всех триплетов семантических метаданных; SLM = {slt1, ..., sltk} - множество начальных уровней безопасности триплетов семантических метаданных.

Выходными данными является покрытие безопасности S = {s1, ..., sk}, где sj= (ti, slj), slj - согласованный уровень безопасности триплета tj .

Любой пользователь U, имеющий уровень доступа slU, для просмотра данных, может отправлять SPARQL-запросы q к элементам или триплетам СБД.

В запросе q шаблон "WHERE" - это множество триплетов SP = {pt1, ..., ptn}, где pti = [s, p, o] ? Pt. Если компоненты s, p или o являются переменными, то их уровни безопасности равны 0. С учётом этого уровень доступа каждого запроса q может быть определён следующим образом:

slq = MAX (slpt1, ..., slptn), (11)

где slpti - уровень безопасности триплета pti ? SP. Из выражения 1 уровень безопасности триплета запроса SLq определяется, как:

slq = MAX (МАХ (slsi, slpi, sloi)), где i = 1, ..., n. (12)

Таким образом, пользователь U имеет право выполнения запроса q, если slU ? slq [3].

В таблице 1 показаны основные виды триплетов в шаблоне запроса и условия для выполнения запросов пользователей [7].

Запрос q может быть прямым или логическим запросом. В связи с этим данный запрос выполняется следующим образом:

1) Если q является логическим запросом:

· Запрос q совпадает с телом логического правила ri : (b1 ?...? bk) > a. Пользователь может выполнить запрос q, если slU > slri .

· В результате выполнения логического запроса даётся множество результатов логических выводов RL = {rL1, ..., rLk}. Могут быть определены их уровни безопасности SLT = {slt1, ..., sltn}.

· Можно определить множество несанкционированных результатов логических выводов R'L. На основе этого пользователь получит только результат A = RL \ R'L.

Таблица 1 - Основные условия для выполнения запросов пользователей

2) Если q является прямым запросом:

· В результате выполнения прямого запроса результат представляет собой множество триплетов T = {t1, ..., tn}.

· Выбираются уровни безопасности триплетов SLT = {slt1, ..., sltn} для множества T.

· Определяется множество T1 = {t1, ..., tk}, состоящее из элементов, у которых slt ? slU или sle ? slU [8].

· Пользователь будет получать только триплеты A = T1.

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

· Если q не является частью тела логического правила ri : (b1 ?...? bk) > a, то пользователь получит ответ T1 = {t1, ..., tk}.

· Если q является частью тела ((b1 ?...? bh) ? (b1 ?...? bk)) логического правила ri : (b1 ?...? bk) > a. Тогда, если часть результатов T'1 ? T1 является основным фактом и пользователь может использовать T'1 и результат выполнения другого прямого запроса q' = (b1 ?...? bk) \ (b1 ?...? bh) для получения несанкционированных результатов логических выводов a', то в этом случае пользователю запрещается видеть T'1. С учётом этого он получит только ответы A = T1 \ T'1.

2.1 Пример контроля результатов логических выводов в СБД

Пусть имеется семантическая БД, которая содержит множество элементов онтологии и триплетов метаданных со своими уровнями безопасности (таблицы 2,3), основные характеристики свойств онтологии (таблица 4), множество логических правил (таблица 5). Предположим, что пользователь U имеет уровень доступа slU = 2. Требуется контролировать прямой и логический запросы, которые выполняются пользователем U.

Таблица 2 - Уровни безопасности элементов в семантической БД

Таблица 3 - Связи между элементами БД

Таблица 4 - Характеристики отношений

Таблица 5 - Логические правила БД

Шаг 1: определение всех RDF-графов.

На основе заданной информации (таблицы 2,3) БД представляется в виде RDF-графа Q (рисунок 2).

Рисунок 2 - Исходный RDF-граф БД

Используются основные характеристики свойств (таблица 4) на основе RDF-графа Q для получения RDF-графа Ql (рисунок 3).



Рисунок 3 - RDF-граф

В связи с тем, что уровень доступа пользователя slU = 2, следовательно, он получает доступ только к триплетам, имеющим уровни безопасности не больше, чем 2.

На рисунке 4 показаны видимый граф Qt (рёбра обозначены линией) и невидимый Qh (рёбра обозначены линией) RDF-графы для пользователя U.