Автор работы: Пользователь скрыл имя, 25 Декабря 2012 в 16:56, реферат
Системы управления базами данных, в особенности реляционные СУБД, стали доминирующим инструментом хранения больших массивов информации. Сколько-нибудь развитые информационные приложения полагаются не на файловые структуры операционных систем, а на многопользовательские СУБД, выполненные в технологии клиент/сервер. В этой связи обеспечение информационной безопасности СУБД, и в первую очередь их серверных компонентов, приобретает решающее значение для безопасности организации в целом.
1. Введение 2
2. Идентификация и проверка подлинности пользователей 3
3. Управление доступом 3
3.1. Основные понятия 3
3.2. Основные категории пользователей 4
3.3. Виды привилегий 5
3.3.1. Привилегии безопасности 5
3.3.2. Привилегии доступа 6
3.3.3. Получение информации о привилегиях 9
3.4. Использование представлений для управления доступом 9
3.5. Иерархия прав доступа 10
3.6. Метки безопасности и принудительный контроль доступа 12
4. Поддержание целостности данных в СУБД 14
4.1. Ограничения 14
4.2. Правила 16
5. Средства поддержания высокой готовности 17
5.1. Кластерная организация сервера баз данных 17
5.1.1. Аппаратная организация SPARCcluster PDB Server 17
5.1.2. Программная организация SPARCcluster PDB Server 18
5.1.3. Нейтрализация отказа узла 19
5.2. Тиражирование данных 20
6. Угрозы, специфичные для СУБД 22
6.1. Получение информации путем логических выводов 22
6.2. Агрегирование данных 25
6.3. Покушения на высокую готовность (доступность) 26
7. Защита коммуникаций между сервером и клиентами 27
8. Заключение 28
9. Литература 28
CREATE TABLE dept (
name char(10) NOT NULL,
location char(20),
CONSTRAINT dept_unique UNIQUE(name)
);
CREATE TABLE emp (
name char(10),
salary decimal(10,2),
edept char(10) CONSTRAINT empref REFERENCES dept(name)
);
Если требуется удалить
ALTER TABLE dept
DROP CONSTRAINT dept_unique cascade;
Слово cascade означает, что следует удалить
также все ограничения, прямо или косвенно
зависящие от dept_unique. В данном случае будет
изъято ограничение empref. Если вместо cascade
указать restrict, то есть сделать попытку
удалить только ограничение dept_unique, СУБД
зафиксирует ошибку. Тем самым обеспечивается
целостность системы ограничений.
В СУБД INGRES делается попытка примирить
контроль ограничений и эффективность
функционирования. При массовом копировании
данных контроль ограничений отключается.
Это значит, что необходимо дополнять
копирование запуском процедуры глобальной
проверки целостности.
Правила позволяют вызывать выполнение
заданных действий при определенных
изменениях базы данных. Обычно действие
- это вызов процедуры. Правила
ассоциируются с таблицами и
срабатывают при изменении этих
таблиц.
В отличие от ограничений, которые являются
лишь средством контроля относительно
простых условий, правила позволяют проверять
и поддерживать сколь угодно сложные соотношения
между элементами данных в базе.
Как и в случае ограничений, проверка правил
отключается при массовых операциях копирования.
Администратор базы данных может также
явным образом отменить проверку правил,
воспользовавшись оператором
SET NORULES;
Оператор
SET RULES;
позволит затем восстановить работу
механизма правил. По умолчанию этот
механизм включен.
Для удаления правил служит оператор
DROP RULE правило;
СУБД обеспечивает автоматическое
удаление правил в тех случаях, когда
удаляется соответствующая
В контексте информационной безопасности
важно отметить, что создать правило, ассоциируемое
с таблицей, может владелец этой таблицы,
имеющий право на выполнение соответствующей
процедуры. Пользователь, действия которого
вызывают срабатывание правила, должен
обладать лишь необходимыми правами доступа
к таблице. Тем самым правила неявно расширяют
привилегии пользователей. Подобные расширения
нуждаются в строгом административном
контроле, поскольку даже незначительное
изменение правила или ассоциированной
процедуры может кардинально повлиять
на защищенность данных. Ошибка же в сложной
системе правил вообще чревата непредсказуемыми
последствиями.
В коммерческих приложениях высокая
готовность аппаратно-программных
комплексов является важнейшим фактором.
Применительно к СУБД средства поддержания
высокой готовности должны обеспечивать
нейтрализацию аппаратных отказов,
особенно касающихся дисков, а также
восстановление после ошибок обслуживающего
персонала или прикладных программ.
Подобные средства должны с самого начала
закладываться в архитектуру комплекса.
Например, необходимо использовать тот
или иной вид избыточных дисковых массивов.
Конечно, это сделает аппаратно-программное
решение более дорогим, но зато убережет
от возможных убытков во время эксплуатации.
Мы будем понимать под кластером
конфигурацию из нескольких компьютеров
(узлов), выполняющих общее приложение
(такое, например, как сервер баз
данных). Обычно кластер содержит также
несколько дисковых подсистем, совместно
используемых узлами-компьютерами, и
избыточные связи между компонентами.
С внешней точки зрения кластер
выглядит как единое целое, а наличие
нескольких узлов способствует повышению
производительности и устойчивости
к отказам.
В настоящем разделе будет рассмотрена
разработка компании Sun Microsystems, Inc - SPARCcluster
PDB Server (параллельный сервер баз данных
на основе SPARC-кластера).
В минимальной конфигурации SPARCcluster
PDB Server состоит из двух узлов SPARCserver 1000,
двух дисковых подсистем SPARCstorage Array и консоли
кластера (SPARCclassic). Узлы- компьютеры соединяются
между собой посредством быстрого Ethernet
(100 Мбит/с), дисковые подсистемы подключаются
через оптоволоконные каналы. В более
мощной конфигурации вместо SPARCserver 1000
может использоваться SPARCcenter 2000, а число
дисковых подсистем способно достигать
32 (до 1 Тб дискового пространства). Каждый
узел кластера - это многопроцессорный
компьютер, к которому, помимо прочих,
подключены накопители на DAT-лентах (или
автозагрузчики кассет с такими лентами).
Все связи с компьютерами и дисковыми
подсистемами продублированы.
Следующий рисунок поясняет аппаратную
организацию SPARCcluster PDB Server.
Рисунок. 1. Аппаратная организация SPARCcluster PDB Server (на рисунке не показаны связи кластера с внешним миром)
Подобная аппаратная архитектура
обеспечивает устойчивость к отказам
(никакой одиночный отказ не вызывает
остановки работы кластера в целом).
В то же время избыточные компоненты
(компьютеры, дисковые подсистемы) отнюдь
не ограничиваются ролью горячего резерва
- они полностью задействованы
в процессе обычной работы.
Вся аппаратура устроена так, что допускает
замену в горячем режиме, без остановки
других компонентов кластера.
Если рассматривать
Рассмотрим компоненты программного обеспечения
SPARCcluster PDB Server.
Устойчивый к отказам распределенный
менеджер блокировок (Fault Tolerant Distributed Lock
Manager, FT-DLM) управляет параллельным доступом
к базам данных, устанавливая и снимая
блокировки. Кроме того, FT-DLM нейтрализует
последствия отказов, снимая блокировки,
установленные вышедшим из строя узлом.
FT-DLM взаимодействует с сервером Oracle для
поддержки неблокируемых операций чтения
и для блокировки на уровне строк при записи
в таблицы. В результате обеспечивается
целостность и сериализация транзакций
в сочетании с параллельной работой узлов
кластера и с параллельным доступом к
нескольким дисковым подсистемам.
Рисунок. 2. Программная организация SPARCcluster PDB Server (узлы кластера работают под управлением ОС Solaris версии 2.4 или выше)
Распределенность менеджера блокировок
означает, что на каждом узле кластера
работает свой экземпляр FT-DLM и что FT-DLM
умеет динамически реконфигурировать
себя (как при выходе узлов из строя, так
и при добавлении новых узлов). В результате
выход из строя одного узла не означает
краха всего сервера баз данных - сервер
жив, пока работает хотя бы один менеджер
блокировок.
В рассматриваемом контексте основное
назначение распределенного менеджера
томов - поддержка зеркалирования дисков
с тем важным дополнением, что устройства,
составляющие пару, могут принадлежать
разным дисковым подсистемам.
Подсистема обнаружения и нейтрализации
отказов постоянно отслеживает доступность
ресурсов, составляющих кластер. При обнаружении
неисправности запускается процесс реконфигурации,
изолирующий вышедший из строя компонент
при сохранении работоспособности кластера
в целом (с выходом из строя диска справляется
менеджер томов).
Подсистема управления кластером состоит
из трех инструментов с графическим интерфейсом:
консоли кластера, менеджера томов и менеджера
сервера Oracle. Их интеграция обеспечивает
централизованное оперативное управление
всеми ресурсами кластера.
Рассмотрим, как в SPARCcluster PDB Server реализована
нейтрализация самого неприятного из
отказов - отказа узла. Программное обеспечение
предпринимает при этом следующие действия:
В этот период транзакции обрабатываются исправными узлами, но, вероятно, несколько медленнее, чем обычно.
Монитор транзакций повторно направляет в кластер неподтвержденные транзакции.
Отметим, что
все действия, исключая ремонт отказавшего
компонента, выполняются в автоматическом
режиме и не требуют вмешательства
обслуживающего персонала. Следует
учитывать, однако, что если следующая
поломка случится до окончания ремонта,
кластер может на какое-то время
стать неработоспособным, поэтому
затягивать ремонт не рекомендуется.
Строго говоря, SPARCcluster PDB Server не поддерживает
одну из важных кластерных функций - с
внешней точки зрения кластер не выглядит
как единое целое. Прикладные программы
могут напрямую подключаться к его узлам,
и тогда отказы узлов требуют нейтрализации
на прикладном уровне. В то же время использование
мониторов транзакций позволяет сгладить
этот недостаток, обеспечивая к тому же
балансировку загрузки между узлами.
В контексте информационной безопасности
тиражирование можно
Развитые возможности тиражирования предоставляет
СУБД INGRES. Им посвящена статья [2]. Здесь мы рассмотрим возможности другого
популярного сервера СУБД - Informix OnLine Dynamic
Server (OnLine-DS) 7.1. В отличие от предыдущего
раздела, речь пойдет об обычных (а не кластерных)
конфигурациях.
В Informix OnLine-DS 7.1 поддерживается модель
тиражирования, состоящая в полном отображении
данных с основного сервера на вторичные.
В конфигурации серверов Informix OnLine-DS с тиражированием
выделяется один основной и ряд вторичных
серверов. На основном сервере выполняется
и чтение, и обновление данных, а все изменения
передаются на вторичные серверы, доступные
только на чтение (рис. 3). В случае отказа
основного сервера вторичный автоматически
или вручную переводится в режим доступа
на чтение и запись (рис. 4). Прозрачное
перенаправление клиентов при отказе
основного сервера не поддерживается,
но оно может быть реализовано в рамках
приложений.
После восстановления основного сервера
возможен сценарий, при котором этот сервер
становится вторичным, а бывшему вторичному,
который уже функционирует в режиме чтения-записи,
придается статус основного; клиенты,
которые подключены к нему, продолжают
работу. Таким образом, обеспечивается
непрерывная доступность данных.
Тиражирование осуществляется путем передачи
информации из журнала транзакций (логического
журнала) в буфер тиражирования основного
сервера, откуда она пересылается в буфер
тиражирования вторичного сервера. Такая
пересылка может происходить либо в синхронном,
либо в асинхронном режиме. Синхронный
режим гарантирует полную согласованность
баз данных - ни одна транзакция, зафиксированная
на основном сервере, не останется незафиксированной
на вторичном, даже в случае сбоя основного
сервера. Асинхронный режим не обеспечивает
абсолютной согласованности, но улучшает
рабочие характеристики системы.
|
Тиражирование |
| ||||
|
|
|
| |||
|
||||||
|
|
|
| |||
Основной |
Вторичный |
Рисунок. 3. Тиражирование. Основной сервер доступен на чтение и запись, вторичный - только на чтение.
|
| |||||
|
|
|
|
| ||
|
||||||
|
|
|
|
|
| |
Основной |
Стандартный |
Рисунок. 4. Когда основной сервер выходит из строя, вторичный переводится в режим доступа и на чтение, и на запись.
Побочный положительный эффект
тиражирования - возможность вынести
преимущественно на вторичный сервер
ресурсоемкие приложения поддержки
принятия решений. В этом случае они
могут выполняться с
Главный источник угроз, специфичных
для СУБД, лежит в самой природе
баз данных. Основным средством взаимодействия
с СУБД является язык SQL - мощный непроцедурный
инструмент определения и манипулирования
данными. Хранимые процедуры добавляют
к этому репертуару управляющие
конструкции. Механизм правил дает возможность
выстраивать сложные, трудные для
анализа цепочки действий, позволяя
попутно неявным образом
Мы рассмотрим несколько угроз, возникающих
при использовании злоумышленником средств
языка SQL.
Информация о работе Информационная безопасность систем управления базами данных