|
Методы защиты данных встроенными средствами СУБД
© Сергей Панасенко, 2011.
В статье рассмотрены основные направления защиты данных, хранящихся или обрабатываемых в системах управления базами данных (СУБД). Описаны способы защиты конфиденциальности и целостности информации с помощью простых в использовании средств, встроенных в СУБД.
Исследования проблем информационной безопасности (см., например, [1]) показывают, что среди максимальных по объему потерь различных организаций от атак разных видов есть такие, которые напрямую являются следствием недостаточной защиты информации в базах данных (БД), а именно:
Проблема защиты данных в СУБД, как и в любой другой информационной системе, может быть разложена на три задачи по обеспечению:
Рассмотрим задачи обеспечения конфиденциальности и целостности данных. В данной статье под целостностью будем подразумевать неизменность данных в процессе их хранения и обработки, а не логическую целостность (непротиворечивость) данных, которой будет посвящена отдельная статья.
Объекты защиты
Для начала рассмотрим, на каких уровнях можно защитить информацию в БД, т. е. определим объекты защиты. Во-первых, мы можем защищать данные, хранящиеся в различных структурных элементах БД, т. е. защищать (см. рис. 1):
Во-вторых, логические структурные элементы БД физически хранятся на жестких дисках и передаются по компьютерным сетям, следовательно, мы можем защищать данные по месту их физического воплощения, например:
Защищать программные модули, а также информацию, хранящуюся на жестком диске и передаваемую по сети, можно точно так же, как и любую аналогичную информацию, не относящуюся к СУБД. Например, с помощью моделей доступа, а также с помощью криптографических методов:
Более интересна задача выборочной защиты данных, хранящихся в конкретных полях или записях БД. В данном случае какие-либо методы защиты на файловом уровне не помогают и кажется необходимым использовать специфичные для БД методы защиты, в частности:
Рассмотрим поочередно данные методы.
Представления
«Представление – это поименованная динамически поддерживаемая сервером выборка из одной или нескольких таблиц» [1]. Иными словами, представление является виртуальной таблицей, все записи которой формируются в процессе обращения пользователя к представлению согласно тому запросу, который был сопоставлен данному представлению.
Таким образом, пользователь получает доступ не к целой таблице (или к нескольким таблицам), а, в простейшем случае, к совокупности столбцов или записей, которые определены в представлении.
Например, существует таблица, которая содержит основную информацию о преподавателях института:
Prep |
||||
NP |
Name |
Position |
ChartNum |
Salary |
1 |
Иванов |
Доцент |
403 |
20 000 |
2 |
Петров |
Ст. преп. |
556 |
10 000 |
3 |
Сидоров |
Профессор |
212 |
30 000 |
И есть три сотрудника института, которым необходимы данные из этой таблицы:
Такое разграничение доступа решается с помощью представлений очень просто:
Упомянутые представления PrepView1 и PrepView2 могут быть созданы следующими простыми запросами (использована нотация СУБД MySQL 5.0 [2]):
Исходя из приведенного выше примера, можно смело утверждать, что представление является простейшим в использовании методом защиты как конфиденциальности, так и целостности данных, который позволяет:
Триггеры
«Триггер (trigger) – это хранимая процедура особого типа, которую пользователь не вызывает непосредственно, а исполнение которой обусловлено наступлением определенного события (действием) – по сути добавлением INSERT или удалением DELETE строки в заданной таблице, или модификации UPDATE данных в определенном столбце заданной таблицы реляционной базы данных» [3].
Таким образом, триггер – это некая подпрограмма, срабатывающая автоматически в случае модификации данных в таблице. Причем, триггер может срабатывать как до, так и после наступления конкретного события, что определяется ключевыми словами AFTER и BEFORE соответственно.
С точки зрения защиты данных в БД триггеры позволяют:
В [3] приведен пример простейшего триггера, который записывает в таблицу аудита (info) информацию о произошедшем изменении строки таблицы district, для которой определяется триггер (нотация СУБД Oracle):
CREATE OR REPLACE TRIGGER DistrictUpdatedTrigger AFTER UPDATE ON district FOR EACH ROW
BEGIN
INSERT INTO info VALUES ('one string in table "district" has changed');
END;
И снова отметим, что триггеры крайне просты в использовании, но при этом позволяют эффективно контролировать целостность данных, а также протоколировать события их модификации.
Функции шифрования
Стоит отметить, что встроенные функции шифрования присутствуют далеко не во всех СУБД. Следовательно, универсальным данный метод назвать нельзя.
Рассмотрим функции шифрования на примере СУБД MySQL 5.0 [2]. Данная СУБД предлагает два однотипных набора функций шифрования, в одном из которых реализован алгоритм DES, а в другом – AES. Кроме того, в MySQL реализовано несколько алгоритмов хэширования. Набор криптографических функций данной СУБД выглядит так:
№ |
Функция |
Назначение |
1 |
AES_ENCRYPT() |
Зашифрование данных алгоритмом AES. |
2 |
AES_DECRYPT() |
Расшифрование данных алгоритмом AES. |
3 |
DES_ENCRYPT() |
Зашифрование данных алгоритмом DES. |
4 |
DES_DECRYPT() |
Расшифрование данных алгоритмом DES. |
5 |
ENCRYPT() |
Зашифрование данных функцией crypt(). |
6 |
MD5() |
Хэширование данных алгоритмом MD5. |
7 |
SHA1() или SHA() |
Хэширование данных алгоритмом SHA-1. |
Функции шифрования данных алгоритмом AES используют 128-битный ключ шифрования, т. е. шифрование ключами размером 192 и 256 бит, предусмотренными стандартом AES [4], в MySQL не реализовано. Ключ шифрования задается явным образом как один из параметров функции.
В отличие от них, функции DES_ENCRYPT() и DES_DECRYPT(), которые шифруют алгоритмом TripleDES, помимо явного задания ключа шифрования, допускают простейший вариант управления ключами в виде ключевого файла, содержащего пронумерованные значения ключей. Однако, данные функции по умолчанию выключены, для их использования необходимо включить поддержку протокола SSL в конфигурации СУБД.
Функция ENCRYPT() может быть использована только в операционных системах семейства Unix, поскольку она шифрует данные с помощью системного вызова crypt().
Что касается используемых функций хэширования, то в документации на MySQL [2] содержится предупреждение о том, что лежащие в их основе алгоритмы взломаны (подробно об этом написано, в частности, в [5]), поэтому использовать их следует с осторожностью. Однако, MySQL пока не предлагает более стойких функций хэширования взамен существующих.
Перечисленные выше криптографические функции также весьма просты в использовании. Например, следующий запрос помещает в таблицу table значение “text”, зашифрованное на ключе “password” [2]:
INSERT INTO table VALUES ( 1, AES_ENCRYPT( 'text', 'password' ) );
Отметим, что формат поля, в которое записывается зашифрованное значение, должен соответствовать ограничениям, накладываемым используемым криптоалгоритмом – в данном случае, оно должно быть двоичным (например, типа VARBINARY) и предполагать выравнивание в соответствии со 128-битным размером блока алгоритма AES.
Заключение
Рассмотренные в статье методы защиты данных встроенными средствами СУБД просты в использовании, но могут достаточно эффективно обеспечить конфиденциальность и целостность данных. Их объединяет один серьезный недостаток – защиту с их помощью достаточно сложно наложить на уже существующую систему. Тем не менее, на этапе проектирования защищенных БД всегда стоит предусмотреть дополнительный рубеж защиты в виде совокупного использования представлений, триггеров и встроенных криптографических функций СУБД.
Литература:
Рисунки:
