Алгоритмы организации и модели ограничения доступа к отдельным записям таблиц реляционных баз данных

• Автор: Баранчиков, Павел Алексеевич
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2009
• Место защиты: Рязань
• Количество страниц: 229 с. : ил.

Оглавление
ВВЕДЕНИЕ.

1 АНАЛИЗ СУЩЕСТВУЮЩИХ АЛГОРИТМОВ И ПОДХОДОВ К ОГРАНИЧЕНИЮ ДОСТУПА К ИНФОРМАЦИИ В БД.

1.1 Краткая история развития ограничения доступа в БД

1.1.1 е годы. Ранний период.

1.1.2 Среда хранения данных

1.1.3 Реляционный подход и первые реляционные СУБД

1.1.4 Оптимизация запросов.

1.1.5 Системы распределенных баз данных

1.1.6 Доминирующая роль реляционных систем.

1.2 Угрозы информационной безопасности.

1.2.1 Переполнение стека.
1.2.2 Угрозы, характерные для уеЬнриложений.
1.2.3 Сети.
1.2.4 Администрирование БД.
1.3 Многопользовательский доступ.
1.3.1 Авторизация доступа к записям
1.3.2 Реализация идентификацииаутентификацииавторизации.
1.3.3 Трехзвенные приложения.
1.4 Проектирование схем БД.
1.4.1 Ограничение целостности данных.
1.4.2 Уникальность ключей
1.4.3 Восстановление данных
1.4.4 Кластеры.
1.4.5 Аномалия удаления
1.4.6 Борьба с аномалиями
1.4.7 БД реального времени.
1.5 Современные разработки по ограничению доступа в БД.
1.5.1 Гибкий доступ к БД.
1.5.2 Тестирование ограничении доступа.
1.5.3 Практические разработки для ограничения доступа к записям
1.6 Модели ограничения доступа.
1.6.1 Мандатная модель ограничения доступа.
1.6.2 Дискреционная модель ограничения доступа.
1.6.3 Ролевая модель ограничения доступа.
1.6.4 Функциональная модель доступа
1.6.5 Кластеризациошшя модель ограничения доступа
1.7 Способы организации ограничения доступа
1.7.1 Использование сервера приложений.
1.7.2 Использование интерфейса между клиентом и сервером.
1.7.3 Создание отдельной таблицы для каждого класса записей сущности
1.7.4 Создание отдельного представления для каждого класса записей
1.7.5 Создание динамического представления пользователя
1.7.6 Выбор конкретного способа доступа на основе специфики задачи
1.8 Основные результаты
ОГРАНИЧЕНИЕ ДОСТУПА К ЗАПИСЯМ ТАБЛИЦ БД
2.1 Конфликт ключей отношения
2.1.1 Блокировка изменений.
2.1.2 Изменение доступа к записи.
2.2 Ограничение доступа при использовании класгеризационной модели.
2.3 Ограничение доступа при использовании мандатной модели.
2.3.1 Изменения в дочерних отношениях
2.4 Ограничение доступа при использовании
дискрет онноролевой модели
2.4.1 Хранение привилегий в защищаемом отношении
2.4.2 Хранение привилегий в отдельном отношении.
2.5 Ограничение доступа при функциональной модели
2.6 Основные результаты.
3 МАСКИРОВКА ЗАПИСЕЙ В ТАБЛИЦАХ БД
3.1.1 Применение маскировки данных.
3.2 Организация хранения истиной и ложной информации
3.2.1 Организация хранения ложной информации.
3.2.2 Операции над незасекреченными данными
3.2.3 Декомпозиция отношения по принципу секретности.
3.2.4 Хранение истинных и ложных записей в различных отношениях
3.2.5 Изменения дочерних отношений.
3.3 Мандатный доступ
3.3.1 Ключи
3.3.2 Внешние ключи
3.4 Функциональный доступ.
3.4.1 Маскировка атрибутов.
3.4.2 Организация хранения.
3.4.3 Реализация предиката определения доступа.
3.5 Синхронизация данных
3.5.1 Точки входа в алгоритм.
3.5.2 Алгоритм проверки лишних записей.
3.5.3 Алгоритм добавления недостающих ложных записей.
3.5.4 Мандатная модель доступа.
3.5.5 Ролевая модель доступа.
3.5.6 Функциональная модель доступа
3.5.7 Автоматическая генерация ложных записей
3.6 Основные результаты
4 ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ ПРЕДЛОЖЕННЫХ АЛГОРИТМОВ И МОДЕЛЕЙ.
4.1 Испытания
4.1.1 ПО для тестирования запросов.
4.1.2 Разработка хранимых процедур для различных СУБД
4.2 Реализация дискреционноролевого доступа.
4.2.1 Символьные идентификаторы владельца и группы роли.
4.2.2 Числовые идентификаторы
4.2.3 Отношение с привилегиями.
4.2.4 Тестовое отношение.
4.2.5 Статистическая обработка.
4.3 Реализация мандатного доступа
4.3.1 Ограничение доступа
4.3.2 Маскировка данных
4.4 Реализация функционального доступа.
4.4.1 Ограничение доступа
4.4.2 Маскировка данных
4.5 Основные результаты
ЗАКЛЮЧЕНИЕ
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
ВВЕДЕНИЕ
Актуальность


В публикациях этого периода можно найти обсуждение и конструктивные предложения по таким вопросам, как стратегии распределения данных и проектирование распределенных баз данных, организация справочников в распределенных системах, управление параллелизмом и синхронизация обновлении, распределенная обработка транзакций, защита целостности данных, оптимизация запросов в распределенных системах, техника восстановления базы данных и др. Используемый до настоящего времени двухфазный протокол фиксации транзакций (2РС) был предложен, как уже отмечалось, именно в этот период. В этих первых СУБД уже были реализованы ограничения доступа как в разработках IBM [], так и в Беркли []. Благодаря успешному созданию исследовательских прототипов и первых коммерческих систем конца -х гг. В течение -х гг. СУБД для различных программноаппаратных платформ. В г. СУБД SQL/DS начала компания IBM. Спустя два года компания выпустила новую систему DB2, положившую начало линии SQL-серверов баз данных, поставляемой IBM до настоящего времени. Был создан ряд новых коммерческих версий системы Ingres, в том числе поддерживающих язык SQL. Было выпущено несколько новых версий Oracle, появилась реляционная СУБД Rdb компании Digital для платформы VAX/MVS. К концу рассматриваемого десятилетия реляционные системы были созданы практически для всех серийно выпускаемых аппаратных платформ и поддерживаемых на них операционных систем, в частности и для персональных компьютеров. Успешному распространению реляционных технологий в значительной мере способствовала результативная деятельность по созданию стандарта реляционного языка данных. Как известно, в г. ANSI на основе разработанного IBM языка SQL. В г. ANSI практически без изменений были одобрены ISO и получили статус международного стандарта. В г. ANSI и ISO приняли следующую версию стандарта — SQL-, которая отличалась от первой лишь несколькими нововведениями. С переходом к постиндустриальному, или информационному, обществу цена информации сильно возросла. Так, предприятие может иметь большой финансовый ущерб от потери данных по своим клиентам и финансовым отчетам по работе. Часто используется резервирование информации, предназначенное для минимизации такого ущерба. Однако в динамично работающие ИС может быть внесено очень много изменений между моментами резервирования. Таким образом, резервирование позволяет минимизировать финансовые потери от утраты информации, но не свести их к нулю. Предприятие может иметь большой ущерб от хищения информации. Например, данные по клиентам предприятия могут быть похищены конкурентами, что может привести к заключению договоров клиентов с конкурентами. Также при хищении информации могут быть раскрыты персональные данные работников или клиентов предприятия, что может привести к судебным искам против предприятия, так как персональные данные защищены законодательством. В информационную систему могут быть внедрены ложные данные, что может привести к неверному трактованию ситуации и принятию неадекватных решений. Все вышеперечисленные угрозы стали появляться, как было описано ранее, с переходом к информационному обществу. Уже давно используются различные методы защиты информации, которые позволяют уменьшить вероятность реализации этих угроз. Среди них используются как организационные методы, так и методы технического характера. Производственный процесс должен быть организован так, чтобы утрата, хищение или повреждение информации не могли быть совершены работниками. Несмотря на то, что организационные методы защиты информации оказывают существенное влияние на вероятность повреждения, хищения или утери информации, технические средства защиты информации не должны давать работникам совершать те действия, которые им запрещены по регламенту работы с ИС. БД стали разрабатываться довольно масштабно. Часто, безопасности и стабильности разработок не придавалось значения. Это породило ряд программных уязвимостей, которые также распространяются и на БД. Переполнение буфера (Buffer Overflow) — явление, возникающее, когда компьютерная программа записывает данные за пределами выделенного в памяти буфера. Переполнение буфера обычно возникает из-за неправильной работы с данными, полученными извне, и памятью, при отсутствии жесткой защиты со стороны подсистемы программирования (компилятор или интерпретатор) и операционной системы. В результате переполнения могут быть испорчены данные, расположенные следом за буфером (или перед ним).