Информационная безопасность систем управления базами данных

 

Федеральное государственное автономное

образовательное учреждение

высшего профессионального  образования

«СИБИРСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»

Институт  педагогики психологии и социологии

Кафедра педагогики профессионального обучения

 

 

 

 

 

 

 

 

 

РЕФЕРАТ

 

по Базам  данных и управлением ими

 

Информационная  безопасность систем управления базами данных

 

 

 

 

 

 

 

 

 

 

Преподаватель                                 Кублицкая Ю.Г. 

                                                                    подпись, дата                                 

 

        Студент       ФО10-01    091012069          Горяев Д.А.

 

 

 

 

 

 

 

 

 

Красноярск 2012

Оглавление

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

 

 

1.  Введение

Системы управления базами данных, в  особенности реляционные СУБД, стали  доминирующим инструментом хранения больших  массивов информации. Сколько-нибудь развитые информационные приложения полагаются не на файловые структуры операционных систем, а на многопользовательские  СУБД, выполненные в технологии клиент/сервер. В этой связи обеспечение информационной безопасности СУБД, и в первую очередь  их серверных компонентов, приобретает  решающее значение для безопасности организации в целом. 
Для СУБД важны все три основных аспекта информационной безопасности - конфиденциальность, целостность и доступность [6]. Общая идея защиты баз данных состоит в следовании рекомендациям, сформулированным для класса безопасности C2 в "Критериях оценки надежных компьютерных систем". В принципе некоторые СУБД предлагают дополнения, характерные для класса B1, однако практическое применение подобных дополнений имеет смысл, только если все компоненты информационной структуры организации соответствуют категории безопасности B. Достичь этого непросто и с технической, и с финансовой точек зрения. Следует, кроме того, учитывать два обстоятельства. Во-первых, для подавляющего большинства коммерческих организаций класс безопасности C2 достаточен. Во-вторых, более защищенные версии отстают по содержательным возможностям от обычных "собратьев", так что поборники секретности по сути обречены на использование морально устаревших (хотя и тщательно проверенных) продуктов со всеми вытекающими последствиями в плане сопровождения. 
Для иллюстрации излагаемых понятий и средств будут использоваться СУБД INGRES, Informix и Oracle.

2. Идентификация и проверка подлинности пользователей

Обычно в СУБД для идентификации  и проверки подлинности пользователей  применяются либо соответствующие  механизмы операционной системы, либо SQL-оператор CONNECT. Например, в случае СУБД Oracle оператор CONNECT имеет следующий вид:

CONNECT пользователь[/пароль] [@база_данных];

Так или иначе, в момент начала сеанса работы с сервером баз данных, пользователь идентифицируется своим именем, а  средством аутентификации служит пароль. Детали этого процесса определяются реализацией клиентской части приложения. 
Обратим внимание на следующее обстоятельство. Некоторые операционные системы, такие как UNIX, позволяют во время запуска программы менять действующий идентификатор пользователя. Приложение, работающее с базой данных, как правило, имеет привилегии, значительно превосходящие привилегии обычных пользователей. Естественно, что при этом приложение предоставляет тщательно продуманный, строго фиксированный набор возможностей. Если пользователь сумеет тем или иным способом завершить приложение, но сохранить подключение к серверу баз данных, ему станут доступны по существу любые действия с данными.

3. Управление доступом

Для иллюстрации вопросов, связанных  с управлением доступом, будет  использоваться СУБД INGRES.

1. Основные понятия

Обычно в СУБД применяется произвольное управление доступом, когда владелец объекта передает права доступа  к нему (чаще говорят - привилегии) по своему усмотрению. Привилегии могут  передаваться субъектам (отдельным  пользователям), группам, ролям или  всем пользователям. 
Группа - это именованная совокупность пользователей. Объединение субъектов в группы облегчает администрирование баз данных и, как правило, строится на основе формальной или фактической структуры организации. Каждый пользователь может входить в несколько групп. Когда пользователь тем или иным способом инициирует сеанс работы с базой данных, он может указать, от имени какой из своих групп он выступает. Кроме того, для пользователя обычно определяют подразумеваемую группу. 
Роль - это еще один возможный именованный носитель привилегий. С ролью не ассоциируют перечень допустимых пользователей - вместо этого роли защищают паролями. В момент начала сеанса с базой данных можно специфицировать используемую роль (обычно с помощью флагов или эквивалентного механизма) и ее пароль, если таковой имеется. 
Привилегии роли имеют приоритет над привилегиями пользователей и групп. Иными словами, пользователю как субъекту не обязательно иметь права доступа к объектам, обрабатываемым приложениям с определенной ролью. 
Отметим, что в СУБД Oracle под ролью понимается набор привилегий. Такие роли служат средством структуризации привилегий и облегчают их модификацию. 
Совокупность всех пользователей именуется как PUBLIC. Придание привилегий PUBLIC - удобный способ задать подразумеваемые права доступа.

2. Основные категории пользователей

Пользователей СУБД можно разбить  на три категории:

• администратор сервера баз данных. Он ведает установкой, конфигурированием сервера, регистрацией пользователей, групп, ролей и т.п. Администратор сервера имеет имя ingres. Прямо или косвенно он обладает всеми привилегиями, которые имеют или могут иметь другие пользователи.
• администраторы базы данных. К этой категории относится любой пользователь, создавший базу данных, и, следовательно, являющийся ее владельцем. Он может предоставлять другим пользователям доступ к базе и к содержащимся в ней объектам. Администратор базы отвечает за ее сохранение и восстановление. В принципе в организации может быть много администраторов баз данных. Чтобы пользователь мог создать базу и стать ее администратором, он должен получить (вероятно, от администратора сервера) привилегию creatdb.
• прочие (конечные) пользователи. Они оперируют данными, хранящимися в базах, в рамках выделенных им привилегий.

В последующих  разделах будет детально проанализирована система привилегий СУБД INGRES. Здесь  мы отметим только, что администратор  сервера баз данных, как самый  привилегированный пользователь, нуждается  в особой защите. Компрометация его  пароля фактически означает компрометацию  сервера и всех хранящихся на нем  баз данных. 
Поручать администрирование различных баз данных разным людям имеет смысл только тогда, когда эти базы независимы и по отношению к ним не придется проводить согласованную политику выделения привилегий или резервного копирования. В таком случае каждый из администраторов будет знать ровно столько, сколько необходимо. 
Можно провести аналогию между пользователем ingres и администраторами баз данных с одной стороны, и суперпользователем операционной системы (root в случае ОС UNIX) и служебными пользователями (в ОС UNIX это могут быть bin, lp, uucp и т.д.) с другой стороны. Введение служебных пользователей позволяет администрировать функциональные подсистемы, не получая привилегий суперпользователя. Точно так же информацию, хранящуюся на сервере баз данных, можно разделить на отсеки, так что компрометация администратора одного отсека не означает обязательной компрометации другого.

3. Виды привилегий

Привилегии в СУБД можно подразделить на две категории: привилегии безопасности и привилегии доступа. Привилегии безопасности позволяют выполнять административные действия. Привилегии доступа, в соответствии с названием, определяют права доступа  субъектов к определенным объектам.

1. Привилегии безопасности

 
Привилегии безопасности всегда выделяются конкретному пользователю (а не группе, роли или всем) во время его создания (оператором CREATE USER) или изменения характеристик (оператором ALTER USER). Таких привилегий пять:

• security - право управлять безопасностью СУБД и отслеживать действия пользователей. Пользователь с этой привилегией может подключаться к любой базе данных, создавать, удалять и изменять характеристики пользователей, групп и ролей, передавать права на доступ к базам данным другим пользователям, управлять записью регистрационной информации, отслеживать запросы других пользователей и, наконец, запускать INGRES-команды от имени других пользователей. Привилегия security необходима администратору сервера баз данных, а также лицу, персонально отвечающему за информационную безопасность. Передача этой привилегии другим пользователям (например, администраторам баз данных) увеличивает число потенциально слабых мест в защите сервера баз данных.
• createdb - право на создание и удаление баз данных. Этой привилегией, помимо администратора сервера, должны обладать пользователи, которым отводится роль администраторов отдельных баз данных.
• operator - право на выполнение действий, которые традиционно относят к компетенции оператора. Имеются в виду запуск и остановка сервера, сохранение и восстановление информации. Помимо администраторов сервера и баз данных этой привилегией целесообразно наделить также администратора операционной системы.
• maintain_locations - право на управление расположением баз администраторы сервера баз данных и операционной системы.
• trace - право на изменение состояния флагов отладочной трассировки. Данная привилегия полезна администратору сервера баз данных и другим знающим пользователям при анализе сложных, непонятных ситуаций.

2. Привилегии доступа

 
Привилегии доступа выделяются пользователям, группам, ролям или всем посредством  оператора GRANT и изымаются с помощью  оператора REVOKE. Эти привилегии, как  правило, присваивает владелец соответствующих  объектов (он же - администратор базы данных) или обладатель привилегии security (обычно администратор сервера баз данных). 
Прежде чем присваивать привилегии группам и ролям, их (группы и роли) необходимо создать с помощью операторов CREATE GROUP и CREATE ROLE. 
Для изменения состава группы служит оператор ALTER GROUP. 
Оператор DROP GROUP позволяет удалять группы, правда, только после того, как опустошен список членов группы. 
Оператор ALTER ROLE служит для изменения паролей ролей, а DROP ROLE - для удаления ролей. 
Напомним, что создавать и удалять именованные носители привилегий, а также изменять их характеристики может лишь пользователь с привилегией security. При совершении подобных действий необходимо иметь подключение к базе данных iidbdb, в которой хранятся сведения о субъектах и их привилегиях. 
Привилегии доступа можно подразделить в соответствии с видами объектов, к которым они относятся. В СУБД INGRES таких видов пять:

• таблицы и представления
• процедуры
• базы данных
• сервер баз данных
• события

Присваивание  привилегий доступа производится с  помощью оператора GRANT. В самом  общем виде оператор GRANT имеет следующий  формат:

GRANT привилегии 
ON объекты 
TO кому;

Применительно к таблицам и представлениям можно управлять следующими правами  доступа:

SELECT	- право на выборку данных
INSERT	- право на добавление данных
DELETE	- право на удаление данных
UPDATE	- право на обновление данных (можно  указать определенные столбцы,  разрешенные для обновления)
REFERENCES	- право на использование внешних  ключей, ссылающихся на данную  таблицу (можно указать определенные  столбцы)

По умолчанию пользователь не имеет  никаких прав доступа к таблицам и представлениям - их необходимо передать с помощью операторов GRANT. 
По отношению к процедуре можно предоставить право на выполнение. При этом не нужно заботиться о выделении прав доступа к объектам, обрабатываемым процедурой - их наличие не обязательно. Таким образом, процедуры баз данных являются удобным средством предоставления контролируемого доступа для выполнения строго определенных действий над данными. 
Права доступа к базе данных как к единому целому может предоставлять ее администратор или пользователь с привилегией security. Эти "права" на самом деле устанавливают ряд ограничений на использование базы данных, то есть по сути являются запретительными. Имеется в виду ограничение на число операций ввода/вывода или число строк, возвращаемых одним запросом, ограничение права создания таблиц и процедур и т.п. По умолчанию пользователь не стесняется количественными лимитами и получает право на создание объектов в базе. 
Отметим, что при создании базы данных указывается ее статус - общая или личная. Это влияет на подразумеваемые права доступа к базе. По умолчанию право на подключение к общей базе предоставляется всем. Право на подключение к личной базе нужно передавать явным образом. Право на подключение необходимо для выполнения всех прочих операций с базой и содержащимися в ней объектами. 
Привилегии (которые в данном случае точнее было бы назвать ограничениями) QUERY_IO_LIMIT и QUERY_ROW_LIMIT проверяются на основании оценок, выданных оптимизатором запросов. Если оптимизатор предсказывает, что запрос превысит отведенный лимит числа операций ввода вывода или возвращаемых строк, он (запрос) отвергается. Наложение подобных количественных ограничений препятствует монополизации сервера одним клиентом и может использоваться как один из инструментов поддержания высокой готовности. 
Обратим внимание на следующее любопытное обстоятельство. По умолчанию все пользователи имеют право создавать процедуры в базах данных. Если бы они при этом автоматически получали права на выполнение, то смогли бы осуществить по существу любую операцию с данными, поскольку выполнение процедуры не требует прав доступа к обрабатываемым объектам. К счастью, для передачи привилегии доступа к объектам, и в, частности, для предоставления права на выполнение процедуры, надо быть не только владельцем объекта, но и администратором базы данных. Мы видим, насколько осторожно нужно относиться к предоставлению привилегий выполнения по отношению к новым, непроверенным процедурам. В принципе достаточно одного "троянского коня", чтобы скомпрометировать всю базу данных. Процедуры являются столь же гибким, но и столь же опасным средством, что и UNIX-программы с битом переустановки действующего идентификатора пользователя. 
Отметим, что запретительные привилегии в принципе можно наложить на администратора базы данных или администратора сервера, однако они не будут иметь силы. Тем самым злоумышленник лишен возможности ограничить права доступа администраторов. В частности, он не может создать личную "секретную" базу данных, к которой не будет иметь доступ пользователь ingres. Правда, у подобного положения есть и оборотная сторона - компрометация пароля администратор сервера предоставляет злоумышленнику неограниченные права доступа ко всем базам данных. 
Права доступа к серверу распространяются на все базы данных, обслуживаемые данным серверам. Набор этих прав тот же, что и для отдельных баз данных. 
Привилегии, явно определенные для отдельных баз, имеют приоритет над привилегиями сервера. 
Механизм событий подробно рассмотрен в [1]. Здесь мы отметим лишь, что по отношению к событиям имеются две привилегии - RAISE и REGISTER. Первая позволяет возбуждать события, вторая - регистрироваться для их получения. 
Оператор GRANT может содержать необязательную часть, принципиально важную для защиты СУБД. Имеется в виду конструкция