Содержание к диссертации
Введение
Глава 1. Методы исследования моделей и алгоритмов представления структур данных для предметных областей с ранжируемыми атрибутами 15
1.1. Тенденции развития методологии проектирования информационных структур хранения данных 15
1.2. Обзор исследований в области реинжиниринга 18
1.3. Проектирование схем РБД 31
1.4. Методика проектирования схем РБД на основе анализа актуальных структур хранения и данных 46
1.5. Основные результаты 58
Глава 2. Методы и алгоритмы извлечения из актуальных данных структурных закономерностей в даталогии предметной области 59
2.2 Разработка алгоритмов ключевых этапов реинжиниринга 63
2.3 Поиск идентичных атрибутов 76
2.4 Алгоритмы объединения и корректировки схем различных БД 84
2.5 Разработка алгоритмов определения семантических зависимостей 103
2.6 Реинжиниринг при мандатной модели доступа 107
2.7 Реинжиниринг при дискреционной модели доступа 114
2.8 Основные результаты 119
Глава 3. Верификация и сравнительный анализ информационных структур хранения данны, полученных в результате экспертного анализа и извлечения информации из актуальных данных 120
3.1. Проблема эквивалентности схем баз данных 120
3.2. Нормализация 121
3.3. Алгоритм проверки на эквивалентность по данным схем РБД 131
3.4. Исследование алгоритма 139
3.5. Проверка структуры базы данных на правильность логического построения с использованием табло 153
3.6. Алгоритм поиска ошибок и избыточности в структуре баз данных 161
3.7. Построение схемы реляционной БД 166
3.8. Выводы 168
Глава 4 Разработка алгоритмов построения схем РБД с ранжируемыми атрибутами 170
4.1 Разработка алгоритмов построения схем РБД с учетом ранжируемых атрибутов, основанных на нормализации отношений 178
4.2 Разработка алгоритмов построения схем РБД, основанных на синтезе отношений 199
4.3 Основные результаты 231
Глава 5. Модификация структур хранения данных для обеспечения дополнительной защиты данных на структурном уровне 232
5.1 Разграничение пользовательского доступа к отдельным кортежам 232
5.2 Проблема дублирования ключей в различных отношениях 233
5.3 Разграничение предоставления доступа при кластеризационной модели 242
5.4 Разграничение предоставления доступа при мандатной модели 244
5.5 Использование дискреционно-ролевой модели для реализации доступа...250
5.6 Организация разграничения с использованием функциональной модели 255
5.7 Маскировка данных 260
5.8 Организация хранения информации при маскировании данных 262
5.9 Метод реализации маскирования при мандатной модели доступа 274
5.10 Маскирование данных при функциональном доступе 279
5.11 Синхронизация маскируемых и маскирующих данных 290
5.12 Основные результаты 298
Глава 6. Практическая реализации результатов работы и экспериментальное исследавание разработанных алгоритмов 301
6.1 Специализированный программный инструментарий для проведения экспериментальных исследований 301
6.2 Экспериментальные исследования разработанных алгоритмов 316
6.3 Сбор и обработка данных экспериментов 338
6.4 Примеры использования полученных результатов для практических нужд 360
6.5 Основные результаты 362
Заключение 365
Список литературы
- Обзор исследований в области реинжиниринга
- Разработка алгоритмов определения семантических зависимостей
- Алгоритм проверки на эквивалентность по данным схем РБД
- Разграничение предоставления доступа при кластеризационной модели
Обзор исследований в области реинжиниринга
В отличие от предыдущих работ, в [155] деятельность по реинжинирингу рассматривается в качестве одной из форм деятельности по эволюции унаследованных ИС, когда, требуется более сильнодействующее «лекарство» для «лечения» ИС, нежели серия локальных инкрементальных изменений .
Так, в [233] описывается каркас (enterprise framework), характеризующий: глобальную среду, в которой осуществляется эволюция системы; действия, процессы и рабочие продукты (артефакты), которые сопровождают деятельность по эволюции системы.
Авторами подчеркивается, что помимо технических вопросов, связанных с эволюцией унаследованных ИС, существует так же множество организационных вопросов. Например, «Как планировать эволюцию большой сложной системы, включая ее реинжиниринг?», «Какие существуют критичные факторы успеха эволюции системы?», «Как оценить, что люди, осуществляющие эволюцию системы, на правильном пути?». Кроме этого, важным является необходимость учета стратегических, организационных, и других аспектов бизнеса, влияющих на эволюцию унаследованной ИС.
В [155] авторами предлагается комплексный, основанный на рассмотренном ранее каркасе, подход к эволюции систем, который определяется в контексте унаследованных систем и современных программных технологий. В основу подхода положены следующие положения (принципы): различие между эволюцией систем и сопровождением программных средств; использование описанного ранее каркаса (enterprise framework) при поддержке принятия решений в процессе эволюции системы; достижение технического понимания систем на высоком уровне абстракции; применение технологий распределенных объектов, технологии «wrapping» для эволюции системы; применение «net-centric» [155] вычислений для эволюции системы.
Определяя различие между сопровождением программных средств и эволюцией систем в части реинжиниринга ИС, авторы рассматривают сопровождение как «мелкозернистую», «краткосрочную» деятельность, направленную на планирование и внесение локализованных изменений. При сопровождении структура (архитектура) системы остается относительно неизменной, а требуемая «порция» вносимых за определенный промежуток изменений, как правило, связана с изменением какого-либо одного требования к системе. Такие изменения, обычно, не сопровождаются существенным изменением значений характеристик и атрибутов качества программных средств.
В отличие от сопровождения, эволюция систем рассматривается как «крупнозернистая», «высокоуровневая», форма изменений на уровне структуры (архитектуры) системы. Вносимые в процессе эволюции изменения, приводят к изменениям значений атрибутов качества, что, как правило, существенно упрощает сопровождение систем. Для этого при внесении изменений в структуру системы могут использоваться стратегии «снизу вверх» и «сверху вниз», применение которых основано на ревизии программного кода, восстановлении описания архитектуры унаследованной системы, проектировании новой структуры, новой формы документации и т.д.
Авторами подчеркивается, что эволюция позволяет адаптировать систему сразу с учетом большого количества выдвигаемых к ней требований (включая приобретение новых возможностей), что в конечном итоге увеличивает стратегическую и экономическую значимость программных средств. При этом акцент смещается от понимания программ к пониманию систем, от сопровождения к эволюции и миграции, от стратегий «снизу вверх» к стратегиям «сверху вниз».
В отличие от рассмотренных ранее работ, в [245] основное внимание уделяется исследованию и решению технических проблем, связанных с миграцией уна 28 следованных систем. Характеризуя понятие «миграция ИС» в данной работе выделяются отдельно эволюция, сопровождение и миграция ИС. Основываясь на том факте, что объектом эволюции и сопровождения является унаследованная ИС, а объектом миграции как унаследованная, так и новая (целевая) системы, авторы разделяют миграцию и другие процессы ЖЦ ИС. При этом миграция рассматривается как деятельность, которая начинается с унаследованной ИС и заканчивается сопоставимой целевой ИС.
В основу предлагаемого авторами подхода положена декомпозиция структуры системы на компоненты пользовательского интерфейса, компоненты - приложения и компоненты управления базами данных. При этом в качестве основных инкрементально выполняемых шагов миграции выступают:
В [203] детально исследуются вопросы классификации, определяющей структуризацию на множестве существующих подходов, методов и технологий ре 29 инжиниринга ИС, в меньшей степени в [201]. Так, в [176] выделяются основные фазы процесса реинжиниринга ИС, а для каждой фазы определяются действия (деятельности) и соотносимые с ними потоки управления. Процесс дается в самом общем виде и не зависит от каких-либо ограничений, например используемых программных технологий. В [203] авторами так же определяется выполняемый в рамках процесса реинжиниринга поток работ. Однако, здесь основное внимание уделяется вопросам технического характера, а выполняемые при реинжиниринге шаги предусматривают декомпозицию структур, соответственно, унаследованной и целевой системы на компоненты пользовательского интерфейса, компоненты -приложения и компоненты управления базами данных. В отличие от предыдущих работ в [203] авторами основной акцент сделан на решение задач оценки унаследованных систем и поддержки принятия решений при реинжиниринге ИС.
Разработка алгоритмов определения семантических зависимостей
Из полученных значений можно сделать предположение, какие данные являются конфиденциальными, а какие общедоступны (например, уровень конфиденциальности у DATA2 выше, чем у других данных). USER l =3+3+2+1+1=10/18=0.6; USER 2 =3+3+2+1+1+1=11/18=0.6; USER 3 =3+2+2+1=8/18=0.4 Из полученных значений можно предположить, каким уровнем доступа обладает каждый из пользователей (например, USER3 обладает правами ниже рангом чем другие пользователи). Оценка временной сложности алгоритмов
Мерой объема входной информации будет число элементов, подлежащих обработке, т.е. размер входного множества. Тогда порядок времени выполнения О(п) будет определяться как время выполнения в наихудшем случае, как максимум времени выполнения по всем входным данным размера п .
Операторы присваивания имеют постоянное время выполнения, независящее от размера входных данных, имеющее порядок 0{\) , т.е. время, равнозначное некоторой константе. Правило вычисления времени выполнения цикла заключается в суммировании времени выполнения каждой итерации цикла. Рассмотрим сложность алгоритмов Monitoring-D-D и Monitoring-D-U.
Временная сложность циклов for (1) и (2) - N и п2 соответственно. Временная сложность в теле цикла для операций умножения на число и операции сложения равна N . Так как оценка временной сложности выбирается по наихудшему случаю, то сложность данного алгоритма 0(п
В граничных условиях (и— oo,/w—юо) этот предел не существует, но, учитывая реальную ситуацию, эти значения всегда будут конечны. В реальных информационных системах мощность множества атрибутов (п) всегда определена и конечна, а мощности множеств доменов (т) конечны. Пусть
Разработаны алгоритмы выявления простых и составных ключей в схеме базы данных, предложен способ выявления «ложных ключей», а также оценка вероятности его ложности.
Разработан алгоритм извлечения функциональных зависимостей из схемы базы данных, предложен алгоритм определения приближенных функциональных зависимостей, а также проведена оценка временной сложности алгоритмов.
Рассмотрены подходы к определению идентичности атрибутов, предложен новый алгоритм поиска идентичных атрибутов при реинжиниринге БДО, основанный на анализе активных доменов.
Рассмотрены подходы к определению атрибутов конфиденциальности при мандатной и дискреционной моделях доступа в базе данных, предложены алгоритм поиска атрибутов конфиденциальности при реинжиниринге БД. Проведены оценки временной сложности и сходимости алгоритмов. Материалы главы изложены в следующих работах автора [1,2, 11, 15, 18, 19, 20,21,45,46,47,50,51,58]. Верификация и сравнительный анализ информационных структур хранения данны, полученных в результате экспертного анализа и извлечения информации из актуальных данных
Классическая технология проектирования реляционных баз данных связана с теорией нормализации, основанной на анализе функциональных зависимостей между атрибутами отношений. Понятие функциональной зависимости является фундаментальным в теории нормализации реляционных баз данных. Функциональные зависимости определяют устойчивые отношения между объектами и их свойствами в рассматриваемой предметной области.
Функциональные зависимости определяют не текущее состояние БД, а все возможные ее состояния, то есть они отражают те связи между атрибутами, которые присущи реальному объекту, который моделируется с помощью БД.
При выполнении эквивалентных преобразований сохраняется множество исходных фундаментальных функциональных зависимостей между атрибутами отношений.
Процесс проектирования с использованием декомпозиции представляет собой процесс последовательной нормализации схем отношений, при этом каждая последующая итерация соответствует нормальной форме более высокого уровня и обладает лучшими свойствами по сравнению с предыдущей.
В основе классического процесса проектирования лежит последовательность переходов от предыдущей нормальной формы к последующей. Однако в процессе декомпозиции мы сталкиваемся с проблемой обратимости, то есть возможности восстановления исходной схемы.
Условие обратимости требует, чтобы декомпозиция сохраняла эквивалентность схем при замене одной схемы на другую: выполнение одних и тех же операций с данными исходной и декомпозированной схем должны приводить к одному и тому же результату. То есть после выполнения данных операций при аналогичной декомпозиции исходной схемы должна получиться схема, идентичная ранее декомпозированной и наоборот, при выполнении соединения соответствующих таблиц декомпозированной схемы должна получиться схема, эквивалентная исходной. Под эквивалентностью понимается идентичность множеств кортежей и выполнение идентичных множеств функциональных зависимостей.
Схемы БД называются эквивалентными, если содержание исходной БД может быть получено путем естественного соединения отношений, входящих в результирующую схему, и при этом не появляется новых кортежей в исходной БД [225].
Согласно [106] две схемы SQ и Sd эквивалентны, если они способны представлять одну и ту же информацию.
Таким образом, чтобы проверить две схемы на эквивалентность необходимо сравнить данные, полученные путем естественного соединения отношений, принадлежащих схемам. 3.2. Нормализация
Нормализация — это разбиение таблицы на несколько, обладающих лучшими свойствами при обновлении, включении и удалении данных. Можно дать и другое определение: нормализация — это процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в 5НФ [131].
Эта процедура основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида K F , где К — первичный ключ, a F — некоторое другое поле. Заметим, что это следует из определения первичного ключа таблицы, в соответствии с которым К — F всегда имеет место для всех полей данной таблицы. "Один факт в одном месте" говорит о том, что не имеют силы никакие другие функциональные зависимости. Цель нормализации состоит именно в том, чтобы избавиться от всех этих "других" функциональных зависимостей, т.е. таких, которые имеют иной вид, чем К — F
Алгоритм проверки на эквивалентность по данным схем РБД
Алгоритмы построения схем реляционных баз данных MdekompPre, MdekompPost и MdekompF [13], учитывающие различную степень конфиденциальности атрибутов, не учитывают многозначные зависимости (MV-зависимости) [106], что требует расширить функциональность алгоритмов за счет учета их наличия.
Возникает задача разработки алгоритма построения схемы РБД на основе многозначных и функциональных зависимостей, учитывающего атрибуты различной степени конфиденциальности, с использованием нормализации отношений. Такие схемы баз данных удовлетворяют особой разновидности четвертой нормальной формы (4НФ).
Поскольку схема R отношения г находится в четвертой нормальной форме (4НФ) тогда и только тогда, когда в случае существования таких подмножеств А и В атрибутов этой схемы отношения R, для которых выполняется нетривиальная многозначная зависимость А В, все атрибуты схемы отношения R также функционально зависят от атрибута А [89], то алгоритм может базироваться на этом свойстве.
Для соблюдения требований к нормализации итоговых схем баз данных и учета конфиденциальности их атрибутов воспользуемся правилами Si и S2.
Поскольку MV-зависимости связаны с декомпозицией без потерь следующим образом: отношение г удовлетворяет MV-зависимости X—— Y тогда и только тогда, когда г без потери информации разлагается в отношения со схемами Ri=XY и R2=XZ, где г - отношение со схемой R; X, Y, Z - множества из R такие, что Z=R-(XY) [106], то для выполнения правил Si и S2 необходимо ввести во входное множество F- и MV-зависимостей избыточность для учёта конфиденциальности атрибутов, вид которой будет описан далее.
В разработанных алгоритмах, основанных на нормализации, поставленная задача была решена относительно множества F-зависимостей; множество MV-зависимостей не рассматривалось.
Прежде чем приступить к описанию алгоритма, сформулируем понятия связанные с правилами Si и S2 и нормальными формами.
Определение 4.1. Отношение находится в усиленной, с точки зрения конфиденциальности атрибутов, третьей нормальной форме (S-усиленной ЗНФ или 3SNF), если оно находится в ЗНФ и все неключевые атрибуты отношения относятся к одному уровню конфиденциальности.
Понятие 3SNF использовалось в [9] в виде правил определенных для выходных данных разработанных алгоритмов нормализации и синтеза.
Определение 4.2. Отношение находится в усиленной, с точки зрения конфиденциальности атрибутов, четвёртой нормальной форме (S-усиленной 4НФ или 4SNF), если оно находится в 4НФ и все неключевые атрибуты отношения относятся к одному уровню конфиденциальности.
Понятие S-усиленной нормальной формы может быть определено для других нормальных форм, в том числе 5НФ, НФБК и других форм более высоких порядков.
Рассмотрим приведение исходной схемы отношения R={Ri, R2, ..., Rk, ..., Rm} к 4SNF, основанное на декомпозиции отношений Rk в том случае, если они не удовлетворяют условиям нормализации и конфиденциальности. В работе [62] описаны алгоритмы, позволяющие получать отношения, удовлетворяющие условиям 3SNF для множества F-зависимостей. Для множества MV-зависимостей, по ранее описанным требованиям к отношениям Rk для удовлетворения 4SNF, происходит декомпозиция данных отношений. Алгоритм построения схемы реляционной базы данных на основе многозначных зависимостей, учитывающий атрибуты различной степени конфиденциальности, будет выглядеть следующим образом: алгоритм DekompMV [43]: вход: множество зависимостей U, включающее подмножества F-зависимостей F и MV-зависимостей MV (U = F u MV), множества X (открытых) и Y (конфиденциальных) атрибутов, принадлежащих R (X n Y= 0 и X u Y = R).
Шаг 1. Добавление избыточности во входное множество атрибутов. Для каждого входного конфиденциального ключевого атрибута К; схемы R вводится избыточность в виде атрибутов К; , таких что: где К - множество входных ключевых атрибутов, К - множество атрибутов, введённых для однозначного определения конфиденциальных ключевых атрибутов. Шаг 2. Обработка схем отношений Rk. Происходит декомпозиция схем отношений Rk, либо неудовлетворяющих ЗНФ, либо удовлетворяющих MV-зависимостям. Перебор схем отношений Rk: Если схема Rk содержит транзитивную зависимость вида А — В, В — С, где А - потенциальный ключ отношения Rk, В и С множества неключевых атрибутов, то разложить схему Rk на схемы: Rki = ABD и Rk2=AC, где D = R-ABC (оставшаяся часть заголовка схемы отношения Rk). Исключить текущую F-зависимость из дальнейшего рассмотрения.
Разграничение предоставления доступа при кластеризационной модели
В рассмотренном примере АА может быть представлено как множество {ВТ, безопасность, ДЗ}. Соответственно возможные комбинации АА из отношений aau или aar будут следующие:
На любом предприятии или организации используется много программного обеспечения различного применения: ОС, офисные приложения, e-mail клиенты, браузеры, СУБД, файловыесерверы... И в каждом из них присутсвуют уязвимости, позволяюще не санкционированно изменить привилегии пользователя . Эти уязвимости, чаще всего, присутсвуют в конкретной версию программного продукта. Отсюда скрытие информации о программном продукте снижает вероятность использования его злоумышленником.
При реализации ограничения доступа эта прозрачность играет существенную роль. Если предположить, что злоумышленник не знает, что информация защищена, то возможность попытки взлома БД значительно снижается. Отсюда, ставится задача организации прозрачной системы безопасности используя ограничения доступа к кортежам таблиц , описанные выше.
Предположим, что пользователь знает, что в г содержится запись ги Реально он не имеет к ней доступа. Если пользователь знает значения атрибутов А і ... А„ кортежа ГІ, то он может судить о наличие гг в отношении г. Остальные атрибуты содержат не известнве пользователю значения и их надо скрыть - В і ... В„.
Среди атрибутов А і ... А„ должен содержится ключ г., поскольку они однозначно определяют кортеж (все атрибуты вместе) в ГІ, что по определению и есть ключ отношения г.
Получив г, как результат запроса, злоумышленник будет уверен, что нужная ему запись, с набором значений а і... а„ в г присутствует. Такой метод будем называть маскированием данных . Организация хранения информации при маскировании данных Допустим наличие отношения г, часть информации в котором необходимо замаскировать. Пользователь [/обладает доступом к подмножеству ги записей отношения г. Тогда в г имеется кортеж га с ключем kd, не доступный пользователю Если пользователь U выполнит запрос к записи Yd (kd), то система выдаст пользователю сообщение об отсутсвии такой записи в отношении г , либо об от сутвии у пользователя доступа к этой нея. Оба способа обладают конкретными недостатками. Пользователь получает сообщение,об отсутствии записи. Тогда логично, что он попытается сам добавить запись г„ с ключом kd в отношение. Это инициализирует ошибку в СУБД, поскольку в г уже есть запись га со значениями ключей kd. Такая ошибка может быть обработана двумя вариантами: 1. пользователь получаете сообщение об ошибке. Тогда он начинает выяснять характер этой ошибки. При этом он может догадаться о том, что у него нет доступа. 2. СУБД без выдачи сообщения запрещает вставить злоумышленнику запись r„, . Тогда, он может еще раз запросить запись с ключом kd. После осознания отсутствия записи г„ в отношении г, он поймет, что произошла ошибка. Тогда можно снова перейти к пункту 1.
Злоумышленнику сообщается, что у него отсутсвуют права на доступ к записи с ключом гп. Здесь он 1) узнает, что кортеж с заданным ключом / в г имеется, 2) существует система ограничения доступа, 3) он не обладает доступом к кортежу с ключом г п.
В том случае, когда злоумышленник знает о существовании ограничения доступа, ему может прийти мысль попробовать использовать уязвимости, предоставляющие доступ к данным или повышающие привилегии. Если он не имеет такой информации, то снижается вероятность организации попытки взлома.
Уязвимости присутсвуют во всех программных продуктах без исключения. Таким образом, при проектировании защищенной системы не следует полностью полагаться на работу ее составляющих полностью в соответсвии с задекларированными возможности. Отсюда следует необходимость использования дополнительных мероприятий для повышения уровня защиты информационной системы. Здесь могут использоваться дополнительные средства аутентификации и авторизации, определенные организационные меры и другое. Предожим методы повышения эффективности защиты информации в БД с использованием штатных средств СУБД.
Поскольку для снижения вероятности попытки несанкционированного доступа со стороны злоумышленника, нужно создать для него иллюзию необходимого доступа при наличии ограничений, не препятсвующих ему произвести желаемые дейстсвия нужными ему данными.
Допустим, пользователю при попытке добавить запись г„, будет возвращена для манипуляций другая запись, с такими же значениями ключевых атрибутов — kd, но не запись Yd. Тогда, на запрос злоумышленника о вводе записи, надо ввести запись Y„ в Y, при этом сохраняя информацию, что запись не истинная, при этом надо предоставить к этой записи полный доступ злоумышленнику.
Поскольку доступ злоумышленнику к Yd не был дан, то в ответ на запрос должна вернуться именно добавленная им запись Y„, содержащая отличающиеся данные. С записью Yd (kd) должны совпадать исключительно значения ключевых атрибутов При генерации маскированной записи, несекретные значения атрибутов Д берутся из записи Yd, для создания иллюзии нахождения злоумышленником искомой записи и того, что он имеет к ней доступ.
