Редишев М. В., Трефилов В. В. Средства и

Редишев М. В., Трефилов В. В.
«Средства и методы обеспечения конфиденциальности и целостности
данных в СУБД»
Введение
В настоящее время большинство видов деятельности связано с использованием и обработкой больших
объемов данных. Приоритетным вопросом при построении любой информационной системы является
защищенность
данных
от
несанкционированного
доступа.
Вследствие
увеличения
ценности
информации в последнее время, появились серьезные требования к конфиденциальности и целостности
данных. Системы управления базами данных, в частности, реляционные базы данных стали основным
инструментом в данной области. При желании достичь высокого уровня безопасности решающим
вопросом будет как раз обеспечение безопасности системы управления баз данных.
СУБД в составе ИС используются для решения различных задач, которые в первую очередь соотносятся
с целями и областями применения самих ИС. Выделяют следующие СУБД: корпоративные (для
использования на уровне предприятия), специализированные (для использования в конкретных
системах, например в АСУ ТП), встраиваемые (применяются в мобильных устройствах), защищенные
(входят в состав решений, обеспечивающих информационную безопасность).[1]
Схема защиты баз данных
Всю структуру защиты баз данных (БД) можно разделить на следующие разделы:
•
Разграничение доступа – любой пользователь получает доступ только к той информации, которая
ему необходима для выполнения должностных обязанностей.
•
Защита доступа – к информации допускаются только те пользователи, которые прошли авторизацию
и аутентификацию в системе.
•
в
Шифрование данных – все данные, которые находятся на физических устройствах или передаются
сеть,
шифруются
для
защиты
от
перехвата,
либо
кражи
или
несанкционированного
просмотра/изменения.
•
Аудит доступа к данным – любое действие (присоединение пользователя, транзакция и т.д.)
протоколируются. Пользователи не должны иметь доступ к журналу. [2]
В безопасности СУБД надо выделить три главных аспекта - целостность, конфиденциальность и
доступность.
Пользователи СУБД
Пользователи СУБД делятся на три основные категории:
•
Прикладные программисты – занимаются написанием программ, которые используют базы
данных. Программисты могут иметь привилегии создавать и обрабатывать объекты.
•
Конечные пользователи – работают с базой данных непосредственно через рабочую станцию
или терминал. Чаще всего конечные пользователи имеют небольшой набор привилегий
манипулирования данными.
•
Администраторы баз данных (Data Base Administrator – DBA)- проектируют базы данных,
выполняют контроль функционирования СУБД, обеспечивают необходимое быстродействие
системы, отвечают за целостность и конфиденциальность информации, производят мониторинг и
сбор статистики. Администраторы также производят реорганизацию и восстановление БД в
случае необходимости, отвечают за обеспечение пользователей доступом к нужным им данным.
Для данной группы людей необходимы не только отличные знания возможностей и особенностей
используемой СУБД, но и операционной системы, под которой она работает. [3]
Авторизация и аутентификация пользователей
Для обеспечения безопасности данных администратор БД обязан использовать средства защиты, в том
числе те, которыми располагает ОС и СУБД. Прежде всего, это меры «3А», что означает «авторизация,
аутентификация, аудит».
Каждому пользователю при регистрации администратор выдает уникальный идентификатор и пароль.
При соединении пользователя с базой данных, он обязан пройти процесс авторизации и
аутентификации. То есть пользователь предоставляет свой идентификатор и пароль, ОС и СУБД
производят проверку подлинности (аутентификация), и, если все проходит успешно, пользователь
получает доступ к информации базы данных согласно набору своих полномочий. Если же процесс
аутентификации пользователь пройти не смог, то он не присоединяется к БД. Более того, если, во время
работы с базой данных авторизированного пользователя, произошло непредвиденное разъединение, то
текущая транзакция обнуляется, и, при возобновлении соединения, потребуется заново ввести логин и
пароль. Вся информация о пользователях, которые зарегистрированы, хранится в системном каталоге.
Пароль пользователь может выбрать себе сам, либо же ему поможет в этом СУБД, т.к. большинство из
них имеет встроенный генератор паролей. Пароли должны быть зашифрованы криптографическими
алгоритмами, также для усиления защиты, они должны периодически меняться.
Для присоединения к базе данных пользователь вводит SQL-предложение. Т.к. современные СУБД не
обладают общим синтаксисом, то, в зависимости от производителя, данный запрос может выглядеть поразному, но чаще всего в нем присутствует команда CONNECT. В качестве примера приведем запрос на
соединение для Oracle и DB2 от IBM:
2
CONNECT [user/password[@база_данных] [AS {SYSOPER|SYSDBA}]]
CONNECT TO база_данных USER “user” USING “password”
Здесь мы увидели разницу синтаксиса и необходимые атрибуты для присоединения к БД. Для
отсоединения в случае завершения работы с базой данных чаще всего используется команда
DISCONNECT. Но бывает отсоединение и непредвиденное, на пример в случае удаления пользователя
администратором, либо при аварийном обрыве канала связи клиента и сервера. Если произошел второй
вариант, то пользователь будет проинформирован о случившемся, а все его действия откатятся до
последнего сохранения изменений в таблицах.
Пользователь может обращаться к базе данных только посредством программ, поставляемых в
дистрибутиве СУБД, и только с помощью штатных средств системы.
Дискреционная защита
В настоящее время данный тип защиты данных в СУБД развит довольно сильно.
Смысл дискреционной защиты состоит в разграничении доступа к объектам баз данных. Такая защита
относится к многоуровневой логической защите. Политика контроля может быть изменена самим
пользователем, то есть он, имея право доступа к объекту, может наделить или отнять это полномочие у
определенных субъектов.
Логическая защита состоит из набора привилегий или ролей. Также к логической защите относится
владение таблицей, владелец таблицы может изменять набор привилегий. Сами данные о логической
защите хранятся в системных таблицах БД.
Привилегии пользователей
Все субъекты системы разделяются на ряд категорий: CONNECT, RESOURCE И DBA. Данные об этом
хранятся в таблице полномочий.
CONNECT — конечные пользователи. По умолчанию им разрешается только соединение с базой
данных и выполнение запросов к данным, все их действия обязательно регламентированы выданными
им привилегиями;
RESOURCE — привилегированные пользователи, обладающие правом формирования новых объектов в
базе данных (таблиц, представлений, синонимов, хранимых процедур). Владелец объекта располагает
полным набором привилегий для управления данным объектом;
DBA — категория администраторов базы данных. Содержит возможности обеих предыдущих категорий,
а также возможность вводить (удалять) в систему (из системы) субъекты защиты или изменять их
категорию. Реализация данной категории в некоторых СУБД проявляется по-разному. На пример в
3
Oracle DBA является администратором сервера баз данных, а в СУБД «Линтер» существует только
понятие администратор конкретной базы данных. В СУБД DB2 от IBM вообще существует несколько
групп администраторов: SYSADM, DBADM, SYSMAINT и SYSCTRL. Каждая из этих групп наделена
своими конкретными привилегиями. [3]
Администратор
занимается
определением
списка
допустимых
субъектов
и
наделением
их
полномочиями. Данные об этих списках могут быть подвержены несанкционированному доступу,
поэтому они подлежат защите, которая реализуется средствами самой СУБД.
На примере СУБД Oracle можно показать, каким предложением происходит формирование нового
пользователя администратором:
CREATE USER IDENTIFIED “user” BY “password”
Назначение набора привилегий может быть реализовано для любого конкретного пользователя или же
группы пользователей. В свою очередь объектом защиты может стать любой объект базы данных, будь
то таблица, представление или на пример, хранимая процедура, а субъектом защиты может быть любой
пользователь, группа пользователей или же роль и т.п.
Если используются хранимые процедуры, то обязательно надо обращать внимание, от имени какого
пользователя они выполняются. Например, в СУБД Oracle раньше хранимые процедуры вызывались от
имени ее владельца, а теперь есть возможность установить, под чьим именем данная хранимая
процедура будет выполняться. А вот в СУБД «Линтер» хранимые процедуры всегда выполняются от
имени пользователя, который ее вызвал. [1]
Предложения управления привилегиями
Назначение/отмена
GRANT privilege [ON object] TO subject [WITH GRANT OPTION]
REVOKE privilege [ON object] FROM subject
Назначение/отмена
привилегии
GRANT privilege [ON object] TO PUBLIC
всем
пользователям системы:
REVOKE privilege [ON object] FROM PUBLIC
Привилегии выборки и модификации данных:
SELECT
Выборка данных
UPDATE
Обновление
данных
(можно
обновления)
4
указать
определенные
столбцы
для
DELETE
Удаление данных;
INSERT
Добавление данных;
Привилегии изменения структуры таблиц:
ALL
Все возможные действия над таблицей
ALTER
Изменение физической/логической структуры базовой таблицы;
INDEX
Создание/удаление индексов на столбцы базовой таблицы;
Для того чтобы ограничить доступ пользователя к таблице, можно использовать представления.
Представление – это выборка кортежей, которая формируется и хранится в таблице. Чаще всего
представление хранится как описание запроса выборки, а сама выборка формируется в момент
выполнение запроса. К представлению можно обращаться так же, как и к таблице.[4]
Мандатная защита
Данная модель ограничения доступа встречается чаще всего в специальных версиях СУБД.
Мандатная модель ограничения доступа определяется как ограничение доступа на основе важности
(представленной некоторой меткой) информации, хранящейся в объектах, и формальное предоставление
доступа субъектам к информации такой важности. При использовании данной модели политика
безопасности
полностью
контролируется
администратором
безопасности.
Пользователям
не
предоставляется доступ на ее изменение.
Метки доступа используются для проверки доступности информации, а также для возможности
организации принудительного управления доступом. Метками доступа снабжается информация всех
уровней – от таблицы, до столбца и записи и даже значения полей записи. Данные метки существуют,
пока существует сам объект защиты, и хранятся вместе с ним на диске.
В качестве примера мандатной защиты рассмотрим защиту СУБД «Линтер», которая получила большую
известность в силовых структурах благодаря своему сертификату по второму классу защиты от НСД.
Все субъекты доступа также снабжаются метками. При проверке доступа субъекта к конкретному
объекту система осуществляет дополнительную проверку, не выполняя недоступные действия.
Метка объекта включает:
- группу субъекта, который внес данный объект;
5
- уровень доступа на чтение – RAL (Read Access Level)
- уровень доступа на запись – WAL (Write Access Level).
Метка субъекта выглядит аналогично:
- группа, к которой принадлежит субъект
- RAL – уровень субъекта, который представляет собой максимальный RAL–уровень доступной
субъекту информации.
- WAL – уровень субъекта, т.е. минимальный уровень RAL-уровень объекта, который может быть создан
данным субъектом.
Все пользователи базы данных считаются разбитыми на непересекающиеся группы. Группа описывает
область доступных пользователю данных. Для каждой группы существует администратор группы
(DBA), созданный администратором SYSTEM. Пользователи одной группы не видят данных
пользователей другой группы. Они могут увидеть данные друг друга, если администраторами групп
установлен флаг доверия.
Уровни доступа вводятся для проверки на уровне ядра СУБД Линтер прав на осуществление
чтения/записи информации.
Вводятся следующие уровни доступа:
1.
Для пользователя (субъекта):
RAL — пользователь имеет возможность получать (читать) информацию, RAL-уровень которой выше
его собственного уровня доступа;
WAL — уровень доверия на понижение уровня конфиденциальности; пользователь не имеет
возможности добавлять информацию с уровнем доступа (RAL-уровнем) более низким, чем данный
WAL-уровень пользователя. То есть пользователь не может сделать доступную ему информацию менее
конфиденциальной, чем указано в данном параметре.
2.
Для информации:
RAL — уровень чтения; пользователь имеет возможность получать (читать) информацию, RAL-уровень
которой не выше его собственного RAL-уровня;
WAL — уровень ценности или уровень доступа на запись (модификацию, удаление); пользователь имеет
возможность изменять (удалять) информацию, WAL-уровень которой не выше его RAL-уровня.
6
Всего вводятся 10 уровней (0-10). Значения 11-15 – резерв. Уровни по умолчанию все равны 0 (все
имеют возможность читать и модифицировать доступные по дискреционному принципу данные).
Создать пользователя с произвольными уровнями может только пользователь SYSTEM. Остальные
администраторы (DBA) могут создавать пользователей только в пределах отведенных им уровней.
Пользователь может принудительно пометить вводимые данные, указав в списке атрибутов уровни
доступа для соответствующих записей и полей. По умолчанию вносимые данные наследуют уровни
пользователя. Защищаемые объекты: пользователи, таблицы, столбцы, записи, поля записей.[1]
Ролевая модель ограничения доступа
Ролевая модель ограничения доступа разработана как подход к ограничению доступа для
авторизованных пользователей. Данная модель является более новой, по сравнению с мандатной и
дискреционной. С помощью данной технологии можно реализовать различные политики безопасности.
С помощью ролевой модели можно симулировать дискреционную и мандатную модели.
Внутри организации создаются безличные роли, соответствующие разным выполняемым функциям.
Доступ к выполнению операции предоставляется конкретным полям. Пользователи, обладающие
такими ролями, приобретают привилегии на выполнение определенных функций. Благодаря тому, что
пользователям не предоставлен доступ непосредственно, а действия они могут выполнять только
посредством предоставленной им роли, управление привилегиями каждого пользователя сводится к
представлению пользователю необходимого набора ролей. Это сильно упрощает процесс введения
новых пользователей или изменения доступа существующих. [4]
Шифрование
В последнее время для защиты от НСД и кражи БД в СУБД часто используются криптографические
средства скрытия информации. Применяется шифрование баз данных, как с помощью персональных
ключей пользователей, так и с помощью единого ключа. Применение шифрования с помощью
персональных ключей повышает защищенность, однако усложняет управление разграничением доступа.
В настоящий момент доступны два режима работы с зашифрованными базами данных. Первый режим
более простой, и заключается в том, что запрашиваемый файл или его часть расшифровывается на
внешнем носителе, с открытой информацией производят некие действия, после этого она опять
зашифровывается. Плюс данного метода заключается в самостоятельности функционирования от СУБД,
однако если на внешнем носителе произойдет какой то сбой, то есть шанс, что часть информации
запишется в открытом виде.
7
Второй режим заключается в том, что запрашиваемые файлы или записи расшифровываются сразу в
оперативной памяти прямо перед выполнением каких либо действий над информацией. Этот режим
доступен, только если данная функция шифрования есть в самой СУБД, однако это усложняет ее
конструкцию.
В качестве примера рассмотрим функции шифрования в СУБД MySQL 5.0.
№
Функция
Назначение
1
AES_ENCRYPT()
Шифрование данных алгоритмом AES
2
AES_DECRYPT()
Расшифрование данных алгоритмом AES
3
DES_ENCRYPT()
Шифрование данных алгоритмом DES
4
DES_DECRYPT()
Расшифрование данных алгоритмом DES
5
ENCRYPT()
Шифрование данных функцией crypt()
6
MD5()
Хэширование данных алгоритмом MD5
7
SHA()
Хэширование данных алгоритмом SHA-1
При шифровании алгоритмом AES используется 128-битный ключ. Этот ключ задается как один из
параметров функции. В отличие от AES в функциях, использующих алгоритм DES, допускается простой
вариант управления ключами, но для использования этих функций необходимо включить поддержку
протокола SSL.
Функцией ENCRYPT() можно воспользоваться только в системах семейства Unix, так как она
производит зашифровывание с помощью системной функции crypt. [5]
8
Пример шифрования
Рассмотрим пошаговый пример использования функций шифрования в СУБД MySQL 5.0
При соединении с БД требуется ввести пароль. Вводим пароль, заданный при установке СУБД. В нашем
случае паролем является ‘system’.
Чтобы посмотреть существующие базы данных, введем команду: show databases.
(Рисунок 1. Существующие БД)
Выберем базу данных test, введя команду ‘use test;’
Как уже говорилось раннее, в данной СУБД присутствуют встроенные функции шифрования и
хэширования.
Для начала проверим, как работает функция шифрования для какого либо слова. Для этого зашифруем
«MTUCI» на ключе «kibia» с помощью алгоритма AES:
(Рисунок 2. Пример AES шифрования)
9
Функции шифрования позволяют шифровать сразу целые столбцы или таблицы. Для следующего
примера создадим таблицу CUSTOMER, где будут храниться имена, e-mail и пароли покупателей
какого-нибудь интернет магазина.
(Рисунок 3. Создание таблицы)
Заполняем таблицу.
(Рисунок 4. Заполнение таблицы)
Теперь нам нужно зашифровать email и password, чтобы в случае хищения данных, злоумышленник не
смог ими воспользоваться:
(Рисунок 5. Шифрование столбцов)
10
Как мы видим, теперь email и password надежно защищены алгоритмом шифрования AES.
Для того, чтобы увидеть зашифрованные данные, следует воспользоваться следующей функцией:
(Рисунок 6. Расшифровка)
Также в СУБД MySQL 5.0 реализованы алгоритмы хэширования. Они используются чаще всего для
хранения паролей пользователей.
Создадим нового пользователя MTUCI, и обновим о нем данные, добавив пароль в таблицу USER, где
хранятся логины и хэши паролей пользователей.
(Рисунок 7. Создание нового пользователя)
11
Как мы видим, сейчас в таблице пароль и логин хранятся в открытом виде. Теперь поменяем
записанный пароль в таблице USER на его хэш с помощью команды PASSWORD:
(Рисунок 8. Команда PASSWORD)
Теперь у нас в таблице с пользователями хранятся хэшированные пароли, которые не представляют для
злоумышленника никакого интереса.
Хранение ключей. Использование сторонних решений.
Вариант хранения сертификатов, закрытых ключей и ключей шифрования, которые используются
средствами обеспечения безопасности СУБД, в контейнерах, как обычные файлы, не отвечает
требованиям безопасности. Поэтому СУБД Oracle с 10 версии позволяет хранить ключевые файлы на
аппаратных устройствах. На российском рынке существует единственный в своем классе продукт
eToken SecurLogon для Oracle от компании Aladdin R.D.[6]
Аудит
Аудит пользователя — это процесс контроля ресурсов, используемых пользователями, на предмет
санкционированного доступа, санкционированного времени работы и разрешенных АБД операций над
12
данными. Он осуществляется обычно с помощью средств ядра СУБД или дополнительных утилит
СУБД. В большинстве операционных систем и СУБД имеются средства генерации и распечатки
соответствующих отчетов, задания расписания проведения аудитов, задания типа аудита (контроля
определенных параметров работы пользователя или программного продукта). Они должны обязательно
регулярно использоваться администратором системы или базы данных согласно выработанной
стратегии.
Благодаря подсистеме аудита можно регистрировать все попытки обойти ограничения, также
регистрируются все попытки подключения пользователей, SQL запросы на предоставление доступа к
БД, любые изменения правил, а также изменения, создания и удаления объектов базы данных. Вся
информация, собранная подсистемой, хранится в системной таблице AUDIT.[7]
SQL инъекции
SQL injection является одной из самый популярный атак на СУБД. Основана данная атака на внедрении
в SQL запрос вредоносного кода. Благодаря этой атаке злоумышленник может выполнить любой запрос
к базе данных, начиная прочтением таблиц и заканчивая изменением или удалением данных. Внедрение
в SQL работает благодаря некорректным обработкам входных данных. [7]
Защитой от данной атаки остается тщательная фильтрация входных параметров, и конечно следует
хранить все пароли в зашифрованном виде, поскольку, если злоумышленнику удастся взломать базу
данных, он не сможет воспользоваться похищенными паролями.
Резервное копирование и восстановление
Восстановление БД — это процесс возвращения БД в состояние, утраченное в результате сбоя или
отказа. Существует множество различных сбоев и отказов, способных повлиять на функционирование
БД. Каждый из них может привести к потерям данных или их целостности. Соответственно для каждого
из них требуются определенные виды восстановления данных. Можно сказать, что восстановление БД
— это защита от потерь методом создания резервных копий и восстановления данных по ним. Любая
СУБД предоставляет средства (утилиты), позволяющие копировать на внешние носители БД и ее
журналы транзакций. Делается это через установленные интервалы времени. Это необходимо для того,
чтобы восстановление данных было возможно при воздействии ошибки прикладной программы
(неверных входных данных) на состояние последней правильной информации. В любом случае
процедуры копирования и восстановления БД крайне ответственны и требуют от администратора базы
данных продуманного и подготовленного подхода. Все возможные в организации стратегии
восстановления и действия должны быть подготовлены АБД заранее, до возникновения ситуации
восстановления.
13
Распределенные СУБД
Распределенной базой данных является совокупность логически взаимосвязанных баз данных, которые
распределены в компьютерной сети. Одним из главных критериев распределенных баз данных является
прозрачность. Прозрачность заключается в том, чтобы для обычного пользователя не было видно
распределенности базы данных. [8] Надо отметить две особенности данных БД. Во первых, система
состоит из множества узлов приема запросов и множества узлов данных. Узлы данных хранят
информацию, а узлы приема нет, они лишь принимают запросы на доступ к данным. Вторая
особенность, это то, что все узлы логически являются независимыми компьютерами с собственной
памятью, а также ОС, причем ОС не обязательно одна и та же на всех узлах. Более того, узел может
управляться своей локальной СУБД и тогда возникает проблема неоднородности, при которой
защищенность СУБД страдает из-за разных типов данных. При распределенных СУБД повышается
надежность системы, поскольку благодаря дублированию данных, исключаются одиночные точки
отказа. Вопрос поддержания целостности в данных решается применением протокола двухфазной
фиксации транзакций, но все равно, этот процесс сложнее, нежели в локальных СУБД. Также, работая с
распределенной СУБД, нужно уделить внимание защите сетевых соединений.
Заключение
После рассмотрения всех выше перечисленных методов и средств обеспечения безопасности СУБД,
можно сделать вывод, что только полноценное использование встроенных средств безопасности и их
разумное дополнение продуктами и решениями сторонних разработчиков даст нам построить надежную
защиту СУБД.
Однако намного важнее иметь квалифицированные кадры (программисты, аналитики, инженеры и т.д.),
которые будут владеть полной информацией, как о встроенных средствах защиты, так и об их
качественном применении. Также следствием этого существующие системы будут использовать
новейшие технологии защиты, в том числе и от других производителей, ведь, как уже говорилось,
обеспечение безопасности требует комплексного подхода.
14
Литература
1.
ЗАО НПП «РЕЛЭКС»
2.
Голицына О.Л., Максимов Н.В. и др., «Базы данных» Москва ФОРУМ - ИНФРА-М 2006 - 352
http://www.linter.ru/
c.
3.
Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных. Учебник.6-е издание. – СПб.:
КОРОНА принт, 2009 - 734 c.
4.
Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс.: Пер. с англ. –
М.: Издательский дом «Вильямс», 2003 - 1088 c.
5.
«Digital Security»
http://www.dsec.ru/
6.
«Аладдин Р.Д.»
http://www.aladdin-rd.ru/
7.
Кузнецов С. Д. Основы современных баз данных. - М.: Изд-во "Интернет-университет
информационных технологий - ИНТУИТ.ру", 2005. - 488 c.
8.
Статья «Википедии» «Распределённые базы данных»
http://ru.wikipedia.org/wiki/Распределённые_базы_данных
15