Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Без_СУБД.doc
Скачиваний:
3
Добавлен:
21.09.2019
Размер:
221.7 Кб
Скачать

1.6. Безопасная среда распределенной базы данных

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

Истоки исследований безопасных РаБД относятся к 1982 г когда были определены две альтернативные архитектуры распределенных СУБД. Общей чертой обеих было наличие надежного компонента переднего плана, который мог подключаться к двум физически раздельным СУБД. В одной из архитектур (показанной на рис. 21-10) одна база данных содержит высокосекретные данные, другая - данные низкой секретности. Компонент переднего плана соответствующим образом направляет выполнение операций (в том числе запросов) над базой данных. Запросы на доступ к высокосекретной информации от процессов и пользователей с необходимым уровнем благонадежности направляются на СУБД высокого уровня, а многоуровневые запросы подвергаются декомпозиции и соответствующим образом распределяются.

Рис. 21-10 Архитектура безопасной распределенной СУБД с раздельными компонентами заднего плана

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

Альтернативная архитектура, изображенная на рис. 21-11, несколько сложнее и предусматривает наличие нескольких уровней в пределах одной СУБД, хотя ее и нельзя назвать истинно многоуровневой. Операции низкого уровня обрабатываются так же, как в первой архитектуре. Но операции высокого уровня и многоуровневые операции обрабатываются СУБД, на которой хранятся высокосекретные данные и копии данных низших степеней секретности. Отметим, что такая архитектура подразумевает использование средств тиражирования, подобных тем, которые обсуждались в гл. 2; следовательно, в ней должны присутствовать менеджеры тиражирования и необходимы соответствующие политики обеспечения целостности данных.

Рис. 21-11 Архитектура безопасной распределенной СУБД с псевдомногоуровневым компонентом заднего плана

В середине 80-х началась работа по расширению предложенных в 1982 г. рекомендаций и выработке новых спецификаций РаСУБД с многоуровневой защитой. Этот проект, получивший название SD-DBMS, не предусматривал реализацию распределенной СУБД в классическом понимании этого термина (т.е. со средствами вертикальной и горизонтальной фрагментации кортежей по организационным соображениям или в соответствии с оценками затрат на сетевые пересылки); распределение использовалось в нем как инструмент для организации принудительного управления доступом (MAC - mandatory access control). SD-DBMS предназначалась для выполнения в локальной сети с многоуровневой защитой.

SD-DBMS следует базовой модели Белл-ЛаПадула (т.е. с определением классов доступа, включающим иерархический и неиерархические компоненты, с понятиями субъектов и объектов и т. п.). Система обеспечивает дискреционное управление доступом (DAC - discretionary access control) посредством представлений доступа (access views) или виртуальных отношений, производных от базовых отношений и подобных традиционным SQL-представлениям. Субъектам (пользователям и процессам) не разрешается обращаться непосредственно к базовым отношениям, они имеют доступ к данным только через посредство представлений с контролируемым доступом.

Обратите внимание на сходство между этим механизмом контролируемого посредством представлений доступа и механизмом, введенным в стандарте SQL-92 для управления метаданными при помощи оператора INFORMATION_SCHEMA (см. разд. 2.3.2), где доступ к метаданным допускается только через представления, а не непосредственно из таблиц.

Дискреционное управление доступом осуществляется при помощи списков управления доступом (ACL - access control list), где задаются допустимые над данным представлением операции с указанием идентификаторов пользователей или групп. Принудительное управление доступом, MAC, обеспечивается путем ассоциирования класса доступа с каждым кортежем базового отношения. Производное отношение, т. е. отношение, полученное в результате применения к существующим представлениям реляционных операций, состоит из производных кортежей, которые подвергаются MAC-разметке. Процедуры разметки - предмет интенсивных исследований. Для управления производными кортежами необходимы соответствующие алгоритмы.

Архитектура SD-DBMS была также основана на физически разделенных компонентах заднего плана, по одному на каждый класс доступа (рис. 21-12). Каждое вновь создаваемое многоуровневое отношение разбивается на одноуровневые фрагменты, хранимые на разных узлах заднего плана в соответствии со своим классом безопасности.

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

Рис. 21-12 Архитектура SD-DBMS

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

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

Рис. 21-13 Возможная архитектура с поддержкой сосуществования мультибаз данных и безопасных баз данных