Вопросы разграничения доступа к данных в
системах управления базами данных/знаний
стр.
1. Введение...................................................
2. Системы управления базами данных с многоуровневым разгра-
ничением доступа...........................................
3. Разграничение доступа в базах данных.......................
3.1. Методика разграничения доступа........................
3.2. Механизм реализации разграничения доступа.............
3.3. Построение MLS/DBMS...................................
3.3.1. Основные черты.................................
3.3.2. Обработка запросов.............................
3.3.3. Операция обновления............................
4. Защита данных в системах управления базами знаний..........
4.1. Основные положения....................................
4.2. Компоненты базы знаний................................
4.3. Обработка запросов в KBMS.............................
4.4. Пример запроса........................................
4.5. Дальнейшие направления защиты данных в KBMS...........
Рассматривается понятие системы управления базами данных с мно-
гоуровневым разграничением доступа (MLS/DBMS) и сложности, встречаю-
щиеся в разработке таких систем. Затем определяется методика разгра-
ничения доступа для MLS/DBMS и определяются вопросы проектирования
запросов и операций обновления. В заключении исследуется понятие сис-
темы управления базами знаний с многоуровневым разграничением доступа
(MLS/KBMS) и вопросы организации запросов к ней.
1. Введение
Хранение и использование информации с использованием баз данных
имеет решающее значение в настоящее время в большинстве предметных
областей. Хотя базы данных имеют много преимуществ, защита данных,
содержащихся в них, является сложной задачей. Публикуется все больше
литературы относительно разграничения доступа в DBMS. Для внедрения
разграничения доступа в системы управления базами данных (СУБД -
DBMS) предложены некоторые решения. Однако эти решения не достаточно
эффективны, чтобы удовлетворить строгим ограничениям в военных приме-
нениях. Для таких применений рекомендовано многоуровневое разграниче-
ние доступа. В статье будет рассмотрено и обсуждено понятие системы
управления базами данных с многоуровневым разграничением доступа
(MLS/DBMS) и сложностей, встречающихся при проектировании таких сис-
тем. Модель данных, которая мы используется в базе данных, является
реляционной. В заключение описывается, каким образом концепция много-
уровневого разграничения доступа, разработанная для СУБД, может быть
применена для систем управления базами знаний (СУБЗ - KBMS).
В разделе 2 вводится понятие MLS/DBMS и обсуждаются трудности,
встречающиеся при их проектировании. В разделе 3 рассматриваются воп-
росы разграничения доступа. В часности, рассматриваются методика раз-
граничения доступа, удовлетворяющая повышенным требованиям в военных
приложениях, и механизм обработки запросов и выполнения операций об-
новления. В разделе 4 рассматривается понятие MLS/KBMS и описывается
архитектура таких систем.
2. Системы управления базами данных
с многоуровневым разграничением доступа
Известно, что в MLS/DBMS не ко всем данным, содержащимся в базе
данных, доступ осуществляется одинаково. Однако современные СУБД, как
правило, не имеют адекватных средств диагностики и механизма опреде-
ления того, что пользователь имеет возможность доступа только к тем
данным, которые являются релевантными. Таким образом, MLS/DBMS отли-
чается от соответствующих DBMS, по-крайней мере, следующими двумя
особенностями:
- каждый элемент данных в базе данных связан с уровнем доступа;
- доступ пользователя к данным должен контролироваться релевант-
ностью для данного пользователя.
Разработка сервиса MLS/DBMS в современных компьютерных системах
представляет много проблем. До настоящего времени внедрение многоу-
ровневого разграничения доступа в операционную систему представляет
собой значительные трудности. Решение этой проблемы в виде аббревиа-
туры обозначается ТСВ. Хотя в разрешении вопросов ТСВ для удаленных
пользователей в MLS/DBMS вводятся компромиссы, остается много проб-
лем, которые требуется разрешать. Наиболее очевидная проблема состоит
в том, что вопросы классификации в СУБД значительно сложнее, чем в
файловых системах и могут быть сложнее реализованы. Другая проблема
состоит в том, что для классификации данных, содержащих контекстные
представления, временные параметры, их композицию, необходимы унифи-
цированные базы данных.
3. Разграничение доступа в базах данных
3.1. Методика разграничения доступа
Вопросы, рассматриваемые в методике разграничения доступа для
MLS/DBMS, должны включать произвольный доступ, контекстную, временную
классификацию, функциональное манипулирование, агрегирование , вывод,
иерархическую классификацию, дискретный доступ и целостность данных.
Кратко обсудим каждый из этих вопросов.
Управление произвольным доступом требует, чтобы пользователь
имел доступ только к релевантным данным. Контекстная классификация
назначает уровень доступа данным в зависимости от их контекста. Кон-
текстная классификация назначает уровень доступа данным в зависимости
от частных контекстов, в которых появляются данные. Время представля-
ет собой пример внешней зависимости. Например, пункт приземления по-
лета может быть классифицирован только после взлета самолета. Функци-
ональное манипулирование над данными может включать в себя использо-
вание таких функций как вычисление суммы и среднего. Агрегирование
данных может осуществляться на различных уровнях, а не только на ин-
дивидуальных элементах, образующих обобщение. Правила вывода встреча-
ются, когда данные высшего уровня могут быть выведены из множеств
данных нижнего уровня. Иерархическая классификация представляет собой
процесс понижения уровня доступа для данных. Механизм управления дис-
кретным доступом дает возможность пользователю обеспечить другим
пользователям доступ к данным, которые он создал. Управление целост-
ностью должно обеспечивать корректность и непротиворечивость данных.
Методика разграничения доступа, которая будет сформулирована ни-
же, рассматривает только подмножество множества выше рассмотренных
вопросов. Это возникает вследствие того, что основная особенность со-
стоит в том, что пользователю, находящемуся на определенном уровне
доступа требуется только информация, которая классифицирована на уро-
вне, доминирующем его уровень.
(Уровень доступа L1 доминирует уровень L2, если:
1. множество всех уровней доступа образует частично-упорядочен-
ную решетку;
2. L2 <= L1.
Поэтому такие вопросы, как дискретный доступ и целостность здесь
не обсуждаются. Эта методика представляет собой следующие основные
аспекты:
1. Всем пользователям гарантируется максимальный уровень реле-
вантности данных. Они могут быть помещены в уровень доступа, который
доминирует максимальный уровень релевантности. Объекты доступны для
пользователей уровня доступа, на котором находятся пользователи.
2. Объектами являются данные из базы данных. Они назначаются
уровню доступа, в зависимости от их содержания, контекста, агрегиро-
вания и времени.
3. Субъекты имеют доступ по чтению для объектов, только если
уровень доступа субъекта доминируется уровнем доступа объекта.
4. Субъект имеет доступ по записи для объекта, если уровень дос-
тупа субъекта доминирует уровень доступа объекта или субъект является
привилегированным пользователем.
5. Ответ на запрос не должен реализовываться для субъекта, если этот
субъект или другие субъекты, которые могут прочитать этот ответ, могут
скомбинировать ответ из ранее реализованных ответов и вывести данные
на уровне доступа, который не доминирует уровень субъекта.
Заметим, что предложения 2 и 3 методики являются упрощением ме-
тодики Bell и La Padula, которые используются для разрешения многих
вопросов в проблеме ТСВ. Предложение 5 является вариацией ранее исс-
ледованной проблемы вывода. Хотя ранее эта проблема стояла более
сильно, когда пользователь не только комбинировал предыдущие ответы с
текущим ответом, но также использовал знания реального мира, которыми
он обладал для вывода информации, к которой он не имел доступа.
Методика разграничения доступа, которую мы представили ранее,
может быть формализована следующим образом:
1. Если субъект (S) имеет уровень доступа L, то записываем
Level(S, L) Это означает, что субъект S имеет уровень L.
2. Если объект (О) имеет уровень L, то записываем Level(O, L).
3. Read (S, O), если и только если Level (S, L1) и Level (O, L2)
и L1>=L2, где запись Read(S, O) означает, что субъект S может читать
объект O.
4. Write(S, O), если и только если а) Level(S, L1) и Level(O,
L2) и L1<=L2 или б) S привилегированный пользователь, где Write(S, O)
означает, что S может писать в объект O.
5. Для уровня доступа L существует соответствующая среда Е(L),
содержащая все ответы, реализуемые на уровне L. Пусть S - субъект с
уровнем доступа L, сделавший запрос для ответа R. Этот ответ R реали-
зуется только при выполнении следующего условия:
Для всех L1>=L, Level (Infer(R, E(L1)))<=L1,
где Infer(R, E(L1)) представляют собой все данные, которые могут
быть выведены из R и E(L1), и Level(Infer(R, E(L1))) представляет со-
бой наибольшую верхнюю границу всех уровней доступа, которые назначе-
ны для индивидуальных данных в Infer(R, E(L1)).
3.2. Механизм реализации разграничения
доступа
Механизм, который используется для реализации методики разграни-
чения доступа, описан ранее и представляет собой совокупность класси-
фикационных правил. Разграничение доступа обеспечивает базис методики
классификации, так как подмножества данных могут быть специфицированы
и назначаться уровню статически или динамически.
Простые ограничения обеспечивают классификацию содержимого базы
данных так же, как и при классификации отношений и атрибутов. Семан-
тические ограничения классифицируют кортежи и элементы. Контекстные
ограничения классифицируют отношения между данными. Дополнительно ре-
зультаты применения функций к атрибутам, таких как сумма, среднее и
другие, могут быть использованы на различных уровнях классификации
данных. Наконец, классификационный уровень данных может изменяться
динамически на основе изменения времени, содержания или контекста.
Ограничения содержат спецификацию данных и их классификацию.
Спецификация данных определяет подмножества базы данных с использова-
нием реляционной алгебры, а классификация определяет уровень доступа
этого подмножества.
Например, рассмотрим базу данных, содержащую отношение:
EMP(NAME, SALARY, SOC-SEC#)
описывающее служащего некоторого учреждения по его имени и зарп-
лате с SOC-SEC# в виде ключа.
Ограничения по содержанию, которые классифицируют все имена слу-
жащих с заработком выше 50 $ при разграничении доступа, выражаются в
виде:
LEVEL (PROJECT [NAME] (SELECT [SALARY > 50 $] EMP)) = SECRET
а контекстные ограничения, классифицирующие все имена служащих и
зарплату, которые доступны совместно на одном уровне, выражаются в
виде:
LEVEL (PROJCT [NAME, SALARY] EMP) = SECRET.
Простые ограничения, которые классифицируют все имена служащих и
заработную плату, взяты индивидуально на определенном уровне разгра-
ничения доступа, выражаются в виде:
LEVEL (PROJECT [NAME] EMP) = SECRET.
LEVEL (PROJECT [SALARY] EMP) = SECRET.
Заметим, что операции SELECT и PROJECT являются реляционными ал-
гебраическими операциями.
Ограничения доступа могут распространяться также на метаданные и
на сами ограничения. Например, они могут классифицировать существова-
ние атрибута или отношения на определенном уровне доступа. Они также
могут определять привилегированный уровень для контекстно-зависимых
ограничений, которые определяют имена служащих, имеющих зарплату бо-
лее 50 $, на определенном уровне доступа. Однако, при нашем подходе
мы предлагаем, что ограничения распространяются только на данные, а
не на метаданные или на сами ограничения. Разграничение доступа ис-
пользуется при манипулировании в схемах отношений, запросах и опера-
циях обновления. В операциях манипулирования в схемах отношений разг-
раничение доступа используется для определения уровня доступа для
файлов, применяемых для хранения части отношений или всего отношения.
Мы предлагаем, что файл имеет только один уровень доступа. Поэтому
многоуровневые отношения, в которых данные имеют различные уровни
доступа, могут храниться в одном или в разных файлах.
Например, контекстные ограничения, классифицирующие именаслужа-
щих , у которых зарплата больше, чем 50 $, распространяются только на
один уровень доступа, поэтому отношение ЕМР будет храниться в двух
файлах. Кортежи, соответствующие зарплате, превышающей 50 $, будут
храниться в закрытом файле. Остальные кортежи будут храниться в нек-
лассифицированном файле.
Для контекстно-зависимых ограничений упорядочивание отношений
является более сложным. Если, например, контекстно-зависимые ограни-
чения, классифицирующие все имена и зарплату, совместно распространя-
ются на определенном уровне доступа (каждый из них может быть неклас-
сифицированным), то возможен подход, при котором один из атрибутов
(имя или зарплата) хранится в неклассифицированном файле, а другие
атрибуты в закрытом файле. Другой возможный подход состоит в том, что
все атрибуты хранятся в неклассифицированном файле. Второй подход не
желателен, так как, если простой пользователь затребует только имена,
то субъект, действующий в интересах этого пользователя, открывает
файл, и должен читать имена служащих так же, как и зарплату.
Третий подход характеризуется тем, что каждый атрибут, включен-
ный в контекстные ограничения, должен храниться в соответствующих
классифицированных файлах, а все оставшиеся атрибуты в одном неклас-
сифицированном файле. Если применяется этот последний подход, то каж-
дый из атрибутов (имя, зарплата, номер) будет храниться в соответст-
вующем неклассифицированном файле.
В статье рассматривается подход, близкий к третьему ввиду отсут-
ствия переклассификации атрибутов. Это означает, что при применении
соответствующего управления при разграничении доступа неклассифициро-
ванный субъект не сможет иметь доступ к обоим атрибутам имени и зарп-
латы служащего. Одно из преимуществ такого хранения имени и зарплаты
в различных файлах состоит в том, что когда имя будет прочитано нек-
лассифицированным пользователем, то процедуры управления доступом ис-
пользуются таким образом, что файл зарплаты не будет открыт для субъ-
екта, действующего по поручению этого пользователя.
При обработке запросов разграничение доступа используется для
модификации запроса таким образом, что если модифицированный запрос
сформулирован, сгенерированный ответ будет доминировать запрос субъ-
екта данного уровня доступа. В прошлом для разрешения других проблем
с базами данных использовались различные вариации технологии модифи-
кации запроса. Проиллюстрируем эту технологию на простом примере.
Предположим, что неклассифицированный пользователь выдаёт запрос на
поиск всех имен служащих, и контекстные ограничения классифицируют
имена служащих, зарплата которых больше 50 $, для данного уровня дос-
тупа. Следовательно, запрос будет модифицирован на поиск всех имен
служащих, чья зарплата меньше или равна 50 $. Существуют формальные
алгоритмы модификации запроса. Если пользователь с полномочиями дан-
ного уровня имеет этот же запрос, то никаких изменений не осуществля-
ется. Вместо этого кортежи читаются из обоих файлов и объединяются
для генерации ответа.
В качестве операций изменения можно рассматривать операции
вставки, удаления или модификации. В нашем подходе разграничение дос-
тупа используется в операциях обновления для определения уровня дос-
тупа данных, которые будут обновляться. Например, в случае операции
вставки ограничения используются для определения уровня доступа дан-
ных, которые должны быть введены. Данные затем вводятся в файлы на
соответствующих уровнях. Другой возможный подход состоит в назначении
уровня доступа по запросу субъекта для обновляемых данных. При этом
подходе возможно для двух пользователей с различными уровнями доступа
вставить различные кортежи с тем же самым первичным ключом. Эта ситу-
ация ограничения на первичный ключ в реляционной базе данных называ-
ется многозначным представлением.
3.3. П О С Т Р О Е Н И Е M L S / D B M S
3.3.1 Основные черты
В этом разделе будут обсуждены архитектурные принципы обработки
запросов и модификаций в MLS/DBMS. Для каждой операции рассмотрим ар-
хитектуру её реализации и ограничения.
Предположим, что MLS/DBMS является удаленной компьютерной базой
данных конечного пользователя, на которую распространяется технология
Bell и LaPadula. Таким образом, чтение и запись в файлы контролирует-
ся согласно этой технологии. Наши основные предпосылки в проектирова-
нии состоят в следующем:
- в предположении, что пользователи не получают информации, ко-
торая для них не доступна, снижение объема верифицируемого кода нас-
колько это возможно.
3.3.2. Обработка запросов
Архитектура обработки запросов представлена на рис.1. Процессор
запроса получает запрос от пользователя, осуществляет его анализ, вы-
полняет операции модификации запроса согласно разграничению доступа и
модификацию представления. Таким образом, получается внутреннее пред-
ставление запроса. Для этих операций, выполняемых процессором мета-
данных, который управляет ограничениями, также как и метаданными,
требуются ограничения и метаданные. Оптимизатор запроса берет внут-
реннее представление запроса и выполняет некоторую оптимизацию, если
необходимо.
¦ запрос
----------+---------¬ ---------¬
¦ Процессор запроса +--------¬ ¦Метадан-¦
L---------T---------- ¦ ¦ ные ¦
¦ ¦ L----T----
----------+---------¬ ¦ ¦
¦Оптимизатор запроса+------¬ ¦ --------+------¬
¦ L---------T---------- ¦ L-----+ Процессор ¦
¦ ¦ L-------+ ¦
¦ ----------+---------¬ ----------+ метаданных ¦
¦ ¦Генератор стратегий+----- ------+ ¦
¦ L---------T---------- ¦ L---------------
¦ ответ ¦ ¦
¦ ----------+---------¬ ¦
L--------+Файловый процессор +---------
L---------T----------
¦
-----+----¬
¦ База ¦
¦ данных ¦
L----------
Рис.1. Процессор запросов для DBMS
Оптимизированный запрос затем трансформируется генератором стра-
тегий в выполняемую стратегию. Таким образом, запрос, определенный на
отношениях базы данных, трансформируется в операции над файлами.
Стратегия реализуется файловым процессором и вырабатывается ответ.
Перед выполнением стратегии файловым процессором он проверяет
сначала контекстные ограничения для открытых файлов, специфицирован-
ных в стратегии, которые будут нарушать разграничения доступа. Напри-
мер, контекстные ограничения, классифицирующие имя и зарплату, нахо-
дятся вместе на одном уровне доступа и распространяются на отношение
EMP. Как указывалось ранее, имя служащего, зарплата и номер хранятся
соответственно в трех неклассифицированных файлах с идентификатором
пользователя для классификации кортежей. Предположим, что неклассифи-
цированный пользователь сначала выдает запрос по имени. Файл, содер-
жащий имя служащего, будет открыт, и значения имени будут возвращены
пользователю. Будет записан факт о том, что файл, содержащий имена
служащих, был открыт неклассифицированным субъектом. Далее предполо-
жим, что тому же самому пользователю потребовались сведения о зарпла-
те. Стратегия выполнения для этого запроса будет состоять в следую-
щем: открытие файла, содержащего зарплату, чтение её значений в этом
файле и помещение их в буфер. Однако перед выполнением этой стратегии
проверяется конкретное ограничение в качестве исторической информа-
ции, определяющей тот факт, что имя файла уже открывалось. Следова-
тельно, файл зарплаты не будет открыт. Таким образом, неквалифициро-
ванный пользователь не будет иметь возможности иметь доступ к именам
и значению зарплаты служащего. Другой возможный подход будет состоять
в том, что файловый процессор функционирует дальше и выполняет стра-
тегию. Однако после того, как файл зарплаты открыт и читается, кон-
текстные ограничения и файл истории будут проверяться и значения зар-
платы не будут освобождаться. Мы будем придерживаться первого подхо-
да, так как будем стремиться избегать лишнего открытия файлов.
Рассмотрим, каким образом проектируемый процессор запроса должен
удовлетворять сочетанию двух целевых требований. Первое состоит в
том, что пользователь не должен получать запрашиваемые им данные, к
которым он не имеет доступа. Достижение этой цели сводится к разреше-
нию проблемы вывода. До настоящего времени нет полного решения для
проблемы вывода. Процессор запроса, который мы описывали, поддержива-
ет только выводы, являющиеся результатами конкретных ограничений. Од-
нако, как известно о разрешимости проблемы вывода, мы предлагаем та-
кой метод, по которому алгоритм может быть применен для манипулирова-
ния информацией в файле истории так, что ограничения, которые можно
вывести, могут быть обнаружены. Вопрос состоит в том, с какой ретрос-
пективой должен поддерживаться файл истории, чтобы обеспечивать раз-
решимость? Будет ли это в процессе сеанса связи, или это будет фикси-
рованный период времени: неделя, месяц, год ?
Вторая цель состоит в снижении, насколько это максимально воз-
можно, объёма верифицируемого кода. Если система верифицируется цели-
ком, то в ней не только будут разрешимы проблемы доступа, но и будет
гарантировано то, что сгенерированный ответ будет корректным. Так как
разграничение доступа - наиболее важная черта нашей системы, мы будем
жертвовать другими чертами, такими как целостность. Поэтому верифици-
руется только часть кода, и затем файловый процессор проверяет кон-
текстные ограничения и исторический файл; поэтому открываются не все
файлы, которые определены в стратегии выполнения. Заметим, что про-
цесс модификации запроса не чуствителен к разграничению доступа. Поэ-
тому, возможно для модифицируемого запроса целиком различать запросы
и то, будет ли сгенерированный ответ тем, что затребовал пользова-
тель. Однако уровень доступа ответа не всегда будет доминировать уро-
вень доступа пользователя.
3.3.3. Операция обновления
Архитектура, которая соответствует операции обновления, предс-
тавлена на рис. 2. Запрос на операцию обновления делается для базово-
го отношения. Заметим, что пользователь "видит" только часть базового
отношения, хранящегося в файле, уровень доступа которого доминируется
уровнем доступа пользователя, вследствие чего не нарушаются контекст-
ные ограничения.
Запрос на обновление
¦
--------+----------¬ -------------¬
¦Процессор запроса +--------+ Решающий ¦
¦ L-------T----------+-----¬ ¦ блок ¦
¦ ¦ ¦ L-----T-------
¦ --------+-------¬ ¦ ¦
¦ ¦Генератор стра-¦ ¦ ------+------¬ ------------¬
¦ ¦тегии обновления-----¬ L--+ Процессор +--+ Метадан- ¦
¦ L-------T-------- L-----+ метаданных ¦ ¦ ные ¦
¦ статус ¦ -----+------------- L------------
¦ --------+-------¬ ¦
¦ ¦ Файловый +-------
L-------+ процессор ¦
L-------T--------
¦
-----+----¬
¦ База ¦
¦ данных ¦
L----------
Рис. 2. Процесс обновления в DBMS
Опишем, каким образом выполняется запрос пользователя на встав-
ку, удаление и операцию модификации.
В случае операции вставки сначала проверяются ограничения досту-
па для определения уровня защиты данных, которые вставляются. Напри-
мер, пусть контекстные ограничения уровня доступа распространяются на
имена служащих, зарплата которых превышает 50 $. Как упомянуто ранее,
кортежи в EMP будут храниться в неклассифицированном файле и файле
защиты данных. Далее, если неклассифицированный пользователь затребо-
вал вставку кортежа (имя1, 60$, SS1) в EMP, то вычисляется уровень
защиты этого кортежа. Неклассифицированный субъект может записать
этот кортеж в соответствующий файл, так как TCB не сохраняет эту опе-
рацию. Однако в нашей разработке мы можем создать новый объект на
уровне доступа. Мы предполагаем, что нижележащий TCB будет позволять
создавать такие объекты. Следовательно, старый объект будет удален по
этой причине. Следовательно, остальная часть обработки может быть вы-
полнена на данном уровне доступа. Следовательно, заново созданный об-
ъект с заданным уровнем доступа будет осуществлять операцию вставки
кортежа в защищенный файл, хранящий кортежи из EMP.
Функции компонент архитектуры, проиллюстрированных на рис.2,
следующие. Процессор запроса получает запрос, осуществляет разбор
запроса и транслирует его во внутреннее представление. Решающий блок
проверяет ограничения защиты данных и вычисляет уровень для данных,
которые будут вставляться. Если вычисленный уровень объекта доминиру-
ет уровень данных, то операция вставки не выполняется. Соответствую-
щее сообщение будет выдано пользователю. Пользователь может подклю-
читься с высшим уровнем и выполнить тот же самый запрос. Если уровень
данных доминируется вычисленным уровнем для объекта, то, как указано
ранее, новый объект будет создан на верхнем уровне и старый объект
будет удален. Оставшаяся часть обработки будет выполнена на высшем
уровне. Эта обработка состоит в генерации стратегии выполнения обнов-
ления генератором стратегий и выполнении стратегии файловым процессо-
ром.
В случае операции удаления данные могут быть удалены из файла,
если пользователь имеет доступ на запись согласно предлагаемой мето-
дике. В этом случае не только необходимо вычислять уровень данных.
Процессор запроса получает запрос, распознает его и транслирует его в
некоторое внутреннее представление. Генератор стратегии генерирует
стратегию обновления, и файловый процессор выполняет эту стратегию.
Операция модификации может рассматриваться как операция удаления,
следующая за операцией вставки. Поэтому правила, применяемые для опе-
раций удаления и вставки, также применяются и для операции модифика-
ции.
Чувствительными к защите данных в процессе выполнения операции
обновления являются функции решающего блока. Поэтому проверяется
часть кода, для которого вычисляется уровень защиты, устанавливаемый
при операции обновления. Как только уровень защиты данных определен,
будеедт создан новый объект, если это необходимо для продолжения об-
работки. Этот новый объект не может вставлять данные в файлы верхнего
уровня защиты.
4. ЗАЩИТА ДАННЫХ В СИСТЕМАХ УПРАВЛЕНИЯ БАЗАМИ ЗНАНИЙ
4.1. Основные положения
В настоящее время делаются значительные усилия для интеграции
искусственного интеллекта и технологии баз данных для разработки сис-
тем управления базами знаний (СУБЗ - KBMS). При этом осуществляются
попытки объединить в одной системе преимущества как искусственного
интеллекта, так и баз данных. Искусственный интеллект лучше использо-
вать в целях представления, вывода рассуждений и поиска решений, в то
время, как базы данных эффективнее в обработке большого количества
данных/знаний. Так как рассматриваются такие вопросы, как обработка
запросов, поиск решений, моделирование данных и управление, необходи-
мо уделить больше внимания вопросам защиты данных. Некоторые предло-
жения в этом направлении были сделаны при разработке систем искусст-
венного интеллекта и систем баз знаний. Эти усилия концентрировали
своё внимание, в основном, на решении вопроса защиты данных в экспер-
тных системах и не исследовали вопросы защиты данных, когда интегри-
руются базы данных и технология искусственного интеллекта. Этот раз-
дел посвящен вопросам многоуровневого разграничения доступа в СУБЗ.
Естественно, вопросы защиты данных в СУБЗ значительно сложнее,
чем в системах управления базами данных. Это происходит потому, что
СУБЗ не только вопросно-ответная система, но и система принятия реше-
ний. Поэтому очень важно защитить данные/знания от пользователей,
доступ которых к ним не разрешён. Необходимо отметить, что должны
поддерживаться целостность данных/знаний и задач, которые манипулиру-
ют данными/знаниями. Мы в этом разделе будем концентрироваться на
вопросах защиты данных в СУБЗ. Поэтому наша цель - рассмотреть вопро-
сы неавторизованного доступа пользователей к данным/знаниям.
Одна из проблем, возникающих при защите данных для систем управ-
ления базами данных, состоит в возможности проведения логических вы-
водов. В СУБЗ логический вывод встраивается в систему. Поэтому, когда
поставлен вопрос, система сама будет логически выводить всю информа-
цию, которая может быть выведена из соответствующей информации. Ответ
на запрос будет содержать не только фактическую, но и логическую ин-
формацию. Поэтому при защите данных в СУБЗ система должна прежде про-
верять для каждого объекта данных/знаний, имеет ли пользователь дос-
туп к этой информации. Заметим, что в случае СУБД отсутствует соот-
ветствующий механизм логического вывода. Поэтому до тех пор, пока в
СУБД не будет механизма логического вывода, который будет уже отно-
сить систему к специальному виду СУБЗ, пользователю возвращаются
только фактографические данные. Однако, используя композицию фактог-
рафических данных, пользователь может вывести информацию, к которой
не имеет доступа. Как можно заметить, человек на это затратит значи-
тельно больше времени, чем машина логического вывода.
В этом разделе обсудим вопросы защиты данных в СУБЗ, специфичес-
кие вопросы представления знаний, компоненты базы знаний, архитектуру
обработки запросов к защищенным данным. Выполнение запросов иллюстри-
руется примерами.
4.2. Компоненты базы знаний
Будем предполагать, что база знаний содержит факты и логические
правила, которые позволяют машине логического вывода выводить новую
информацию. Факты образуют базу данных. Таким образом, база знаний
состоит из базы знаний и базы правил. Эта схема представления позво-
лит нам не только понять вопросы защиты данных в СУБЗ, но и обеспечит
базис для описания проблемы логического вывода. Это позволит осущест-
вить взаимосвязь между вопросами защиты данных в СУБД, обсужденным
ранее, и вопросами защиты данных в СУБЗ; эти положения могут быть
расширены до тех случаев, когда база данных/база знаний состоит толь-
ко из базы знаний.
Структура базы знаний такая же, как в предыдущем разделе. Для
упрощения наших рассуждений предполагаем, что база данных имеет реля-
ционную модель и что правила базы знаний представляют собой Хорновс-
кие дизъюнкты. Мы выбираем такое представление ввиду тесной взаимос-
вязи между реляционными базами данных и системой логического програм-
мирования, основанной на дизъюнктах Хорна. Ввиду того, что все реля-
ционные базы данных являются дизъюнктами Хорна в системе логического
программирования, то наши рассуждения о защите данных будут рассмат-
ривать только реляционную модель. Далее, без потери общности, наши
предположения будут справедливы относительно базы правил, содержащих
дизъюнкты Хорна в системе логического программирования. Хотя полное
исчисление, основанное на дизъюнктах Хорна, не выразимо полностью в
логике первого порядка, многие из правил и ограничений, которые мы
будем выражать, могут представляться в данном подмножестве. Далее, в
качестве механизма вывода для дизъюнктов Хорна используется резолю-
тивный принцип, обладающий полнотой. Поэтому этот механизм вывода ис-
пользуется для выявления нарушений защиты данных. Однако заметим, об-
суждения могут быть расширены включением другого представления для
базы знаний. Компонента базы знаний, состощая из правил, состоит из
следующих составных частей:
- ограничения защиты доступа;
- область действия для каждого уровня защиты данных;
- ограничения целостности;
- правила вывода;
- информация реального мира.
Ограничения защиты доступа представляют собой классификационные
правила, описанные в предыдущем разделе. Эти ограничения могут расп-
ространяться на данные в базе данных и на правила в базе правил. Об-
ласть действия, соответствующая уровню доступа, связана с множеством
всех ответов, которые реализуются на этом уровне доступа. Заметим
также, что и область действия также определяется соответствующим
уровнем доступа. Например, область действия защиты доступа будет оп-
ределяться уровнем защиты доступа. Ограничения целостности включают
ограничения, которые распространяются на значения данных и на отноше-
ния между атрибутами. Правила вывода используются для вывода косвен-
ных данных. Например, если "Х отец У", "У отец Z", то из правила вы-
вода "отец отца является дедом", можно вывести, что "Х дед Z". Инфор-
мация реального мира представляет собой факты, не представляющие со-
бой часть базы данных. Например, "Джон является президентом" может
представлять собой информацию реального мира, не содержащуюся в базе
данных.
4.3. Обработка запросов в СУБЗ
Архитектура для обработки запросов представлена на рис.3. Запрос
будет определяться в виде Хорновских выражений. Диспетчер интерфейса
пользователя представляет собой интерфейс между внешним миром и СУБЗ,
который получает запрос и посылает его процессору запроса. Функции
процессора запросов следующие:
- определение того, можно ли ответить на вопрос с помощью только
консультирования, используя базу правил, или необходимо обращаться к
базе данных в процессе обработки запросов. Возможен случай, что зап-
рос может быть модифицирован перед обращением к базе данных;
- преобразование части ответа, который может быть получен кон-
сультированием, только с использованием базы правил;
- если запрос модифицируется перед доступом к базе данных, то
выполняются модификации запроса, если необходимо.
Ответ, полученный только с помощью
Запрос ¦ базы правил ¦ Ответ
в логическом ¦ -------------------------------¬ ¦
виде --+------+--¬ -------------¬ ---+--+-----¬
¦ Процессор ¦ ¦ Машина ¦ ¦ Процессор ¦
¦ +-----+логического +-----+ ¦
¦ запроса ¦ ¦ вывода ¦ ¦ ответа ¦
L-----T------ L------------- L----T-------
Модификация логи- ¦ ¦
ческого запроса ¦ ¦
------+-----¬ -------------¬ ¦
¦ Транслятор¦ ¦ База ¦ ¦
¦ ¦ ¦ ¦ ¦
¦ запроса ¦ ¦ правил ¦ ¦
L-----T------ L------------- ¦ Ответ и ин-
Запрос в реляцион-¦ ¦ формация, ис-
ной алгебре ¦ ¦ пользуемая
-----+----------------¬ ¦ для генера-
¦ D B M S +------------------- ции ответа
L-T----------------T---
-----+---¬ --------+-¬
¦ База ¦ ¦ Мета- ¦
¦ данных ¦ ¦ данные ¦
L--------- L----------
Рис.3. Обработка запроса в СУБЗ
Машина логического вывода в СУБЗ применяется для вывода правил
или вывода новой информации из существующей информации в процессе об-
работки запроса. Заметим, что правила расположены в одноуровневом
файле. Заметим, что методика Bell и La Padula, распространяющаяся на
нижележащие ТСВ, будет предохранять объекты высшего уровня от чтения
из файлов высокого уровня. Однако нарушение защиты данных путем логи-
ческого вывода не определяется на этой стадии. Это происходит потому,
что наша основная цель состоит в минимизации объема верифицируемого
кода. Поэтому функции процессора запросов не чувствительны к защите
данных. Далее, ни ограничения защиты данных, ни область их действия
не проверяются на этой фазе. Кратко говоря, функции процессора запро-
сов в СУБЗ с защитой данных не отличаются от функций процессора зап-
росов простой СУБЗ.
Непосредственный выход процессора запросов - это или нулевой
запрос или один из следующих двух вариантов:
- ответ, сгенерированный из базы правил;
- вопрос или модифицированный вопрос, поддерживаемый для среды
СУБД.
Перед выполнением запроса СУБД, он первоначально транслируется в
соответствующий реляционный язык запросов. Оттранслированный запрос
обрабатывается реляционной СУБД. Заметим, что база данных записывает-
ся в один или более одноуровневых файлов и предлагаемая методика уп-
равляет доступом к этим файлам. Ответ, сгенерированный СУБД, трансли-
руется в соответствующий формат и посылается процессору запросов. До-
полнительная информация об отношениях, атрибутах и файлах, которая
использовалась для преобразования ответа, также передается процессору
запроса. Аналогично процессор запроса посылает сгенерированный ответ,
также как и информацию о правилах и файлах, которые использовались
для генерации ответа процессором ответа. Процессор ответа преобразует
оба ответа. Заметим, что запрос, представленный пользователем, должен
также передаваться процессору ответа, для того чтобы определить реле-
вантность сгенерированного ответа.
Функции процессора ответа чувствительны к защите данных. С этой
точки зрения необходимо отметить, что ограничения защиты данных так
же, как и область их действия, исследуются для определения того, ка-
ким образом ответ может быть реализован для запроса объектов. Далее,
существенно также, что как только информация посылается процессору
ответа, то она является корректной. Таким образом, выполнение функции
транспортировки также чувствительно к уровню доступа.
Заметим также, что весь процесс с этой точки зрения будет состо-
ять в запросах объектов уровня доступа. Однако, когда ответ сформиро-
ван на определенном уровне доступа, все области действия, уровни дос-
тупа которых доминируют, должны быть проверены с помощью логического
вывода на нарушение защиты данных. Методика не допускает доступа для
выполнения операции чтения, если область действия уровня доступа до-
минирует уровень доступа объектов запроса.
Поэтому в нашей разработке предполагается, что каждая область
действия имеет функционирующий сервер. Когда в данной области дейст-
вия происходит операция чтения, сообщение передается такому серверу,
который будет функционировать на этом или более высоком уровне объек-
тов запроса. Сервер определяет область действия и устанавливает с по-
мощью логического вывода нарушение защиты данных в процессе формиро-
вания ответа. Дедукция выполняется машиной логического вывода. Соот-
ветствующие сообщения будут посылаться объектам, инициирующим уни-
кальные сообщения. Это может быть операция записи. Если нет нарушения
защиты данных, то выдается ответ. Иначе выдается нулевой ответ.
4.4. Пример запроса
В этом подразделе мы иллюстрируем примерами, каким образом зап-
росы обрабатываются с помощью архитектуры СУБЗ, рассмотренной ранее.
Пример 1. База правил содержит следующие правила:
R1 : NAME(X) <- EMP(X, Y, Z)
R2 : SAL(Y) <- EMP(X, Y, Z)
R3 : SS#(X) <- EMP(X, Y, Z)
R4 : Level(X, Secret) <- EMP(X, Y, Z)/\GREATER(Y, 80K)
R5 : SEN-EMP(X) <- EMP(X, Y, Z)/\GREATER(Y, 50K)
R6 : SEN-EMP(John)<-
Здесь R1, R2 и R3 представляют собой ограничения целостности,
утверждающие, что если EMP (X, Y, Z) истинно, то Х является именем, Y
- зарплатой и Z - номером служащего, R4 - контекстное ограничение,
классифицирующее всех служащих, имеющих зарплату более 80$, на данном
уровне доступа. R5 - правило вывода, утверждающее, что все служащие,
имеющие зарплату, превышающую 50 $, являются старшими служащими. R6
утверждает, что John является старшим служащим. Предположим, что все
правила являются неклассифицированными.
База данных состоит из отношений ЕМР, содержащего следующие кор-
тежи:
Т1 : (N1, 60K, SS1)
T2 : (N2, 30K, SS2)
T3 : (N3, 90K, SS3)
T4 : (N4, 100K, SS4)
T5 : (N5, 20K, SS5)
Кортежи Т3 и Т4 записываются в защищенный файл, а остальные кор-
тежи записываются в неклассифицированный файл.
Предположим, что неклассифицированный пользователь выдаёт запрос
на поиск имен всех старших служащих. Запрос будет иметь следующий
вид:
SEN - EMP (X).
Процессор запроса сначала осуществляет отрицание запроса:
<---- SEN - EMP (X).
Полученный вид запроса разрешается относительно правил базы.
Вывод процессора запроса - это имя "John" и модифицированная
версия запроса:
существует Y, Z (EMP (X, Y, Z) /\ GREATER (Y, 5OK)).
Модифицированная версия запроса преобразуется в реляционный
язык, выраженный в формализме реляционной алгебры. Эквивалентные спе-
цификации в реляционной алгебре выглядят следующим образом:
PROJECT [NAME] (SELECT [SALARY > SOK] EMP).
СУБД обрабатывает сформированный запрос. Заметим, что некласси-
фицированный пользователь может открыть и читать неклассифицированные
файлы Поэтому ответ, сгенерированный на этот запрос, - это список
(N1).
Этот ответ вместе с именем "John" и информация об отношениях, о
правилах и файлах, использованная для обработки запроса, так же как и
сам запрос, посылается процессору ответа. Процессор ответа будет про-
верять все области действия на неклассифицированном уровне и выше с
целью проверки, будет ли полученный список (John, N1) осуществлять
нарушение защиты данных. В этом примере мы предполагаем, что области
действия первоначально пусты. Далее, так как нет контекстных и объе-
диненных ограничений, результирующий список для неклассифицированного
файла не будет вызывать нарушение защиты данных. Поэтому список
(John, N1) будет сгенерирован в виде ответа. Следующие правила будут
вставлены в неклассифицированную область действия:
R6: SEN - EMP (John) <----
R7: SEN - EMP (N1) <----
Дополнительно следующие правила будут вставлены в базу правил:
R8: RELEASE (John, Unclassified) <---- SEN - EMP (John)
R9: RELEASE (N1, Unclassified) <---- SEN - EMP (N1)
Пример 2. База знаний содержит следующие правила:
R1: NAME (X) <---- EMP (X, Y, Z)
R2: SAL (X) <---- EMP (X, Y, Z)
R3: SS# (Z) <---- EMP (X, Y, Z)
R4: Level (X, Secret) <---- EMP(X, Y)/\RELEASE (Y,
Unclassified)
R5: Level (Y, Secret) <---- EMP(X, Y, Z)/\RELEASE (X,
Unclassified).
Здесь R1, R2 и R3 аналогичны приведенным в примере 1. R4, R5 -
вариации контекстных ограничений, классифицирующих и зарплату служа-
щих, находящихся в защищенном файле. Тогда, как только выдается имя,
соответствующая зарплата защищена. Аналогично, если обрабатывается
зарплата, то соответствующее имя защищено.
База данных идентична базе из примера 1. Однако ограничением по
отношению к обсуждению защиты данных СУБД, рассмотренной ранее, явля-
ется то, что отношение EMP хранится в трех неклассифицированных фай-
лах: одном для имен, одном для зарплаты и одном для номеров. Иденти-
фикаторы кортежей связаны с каждым элементом в файле так, что имена,
зарплаты и номера связаны друг с другом.
Предположим, что неклассифицированный пользователь выдает два
запроса: первый из них на поиск имен, а второй - на поиск зарплаты.
Обработка первого запроса аналогична ранее рассмотренному примеру.
Все неклассифицированные имена будут выданы неклассифицированному
пользователю, выдавшему запрос. Далее на неклассифицированной области
действия будет сделана попытка обновления путем вставки всех имен,
которые были выданы. Будет также вставлено следующее правило:
R6: RELEASE (X, Unclassified) <---- EMP (X.Y.Z).
Далее будет обрабатываться запрос на поиск всех зарплат. Процес-
сором запроса не будет выполнено модификаций запроса. Запрос трансли-
руется в так называемую реляционно-алгебраическую форму и будет обра-
батываться СУБД. Значения зарплаты вместе с информацией о файлах и
отношениях будут посланы процессору ответа. Исследованием области
действия и правил R1- R6 будет определено, что значения зарплаты не
выдаются пользователю.
Заметим, что если запрос пользователя на имена и зарплату осу-
ществлен в одно и то же время, то файлы имен и зарплата будут откры-
ваться и читаться. Процессор ответа должен проверять, выдавать поль-
зователю или имена, или зарплату. Сначала он должен оперативно обно-
вить базу правил включением того факта, что имена выдаются. Затем он
должен проверить, могут ли также выдаваться значения зарплаты. В этом
примере невозможно выдавать их оба. Поэтому обновление базы данных не
изменяет положения, и ответ не будет выдан пользователю.
4.5. Дальнейшие направления защиты данных в СУБЗ
Мы рассмотрели пример и показали обработку запроса в СУБЗ. Сис-
тема логического вывода, основанная на доказательстве теорем и резо-
лютивном принципе, использованная в машине логического вывода, может
быть использована для сложных выводов. Однако, ввиду неразрешимости
логики предикатов первого порядка, невозможно определить все типы вы-
водов. Дальнейший шаг состоит в классификации различных логических
выводов, которые могут встречаться, и определение решения среди них.
При проектировании процессора запросов мы предполагаем, что дан-
ные в базе данных и правила в базе правил хранятся в одноуровневых
файлах согласно определенным ограничениям защиты данных. Однако до
сих пор не определено, каким образом упорядочивать правила и отноше-
ния. Хорошее начальное приближение, рассматриваемое в качестве на-
чальной точки отсчета для построения обработчика стратегий для СУБЗ,
- это генератор стратегий для СУБД, рассмотренный в предыдущем разде-
ле.
Как указывалось ранее, в СУБЗ, помимо обработки запросов и их
модификации, выполняются также операции поиска решений. Проектирова-
ние компоненты защиты данных с использованием логического решателя в
СУБЗ будет рассматривать проблему классификации и связанные с ней
проблемы дополнительно к классификации данных и правил, используемых
для проблемы поиска решений. Предполагается, что эти задачи вызовут
постановку новых задач в решении проблемы защиты данных в СУБЗ.
По материалам статьи:
THURAISINGHAM M.B. Towards the design of secure data/
knowledge base management system. Data & Knowledge
Engineering 5 (1990) p.59-72.
|
