24 октября 2011
Методы защиты данных встроенными средствами СУБД
В статье рассмотрены основные направления защиты данных, хранящихся или обрабатываемых в системах управления базами данных (СУБД). Описаны способы защиты конфиденциальности и целостности информации с помощью простых в использовании средств, встроенных в СУБД.
Исследования проблем информационной безопасности (см., например, [1]) показывают, что среди максимальных по объему потерь различных организаций от атак разных видов есть такие, которые напрямую являются следствием недостаточной защиты информации в базах данных (БД), а именно:
- кража конфиденциальных данных;
- неавторизованный доступ к данным.
Проблема защиты данных в СУБД, как и в любой другой информационной системе, может быть разложена на три задачи по обеспечению:
- конфиденциальности данных;
- целостности данных;
- доступности данных.
Рассмотрим задачи обеспечения конфиденциальности и целостности данных. В данной статье под целостностью будем подразумевать неизменность данных в процессе их хранения и обработки, а не логическую целостность (непротиворечивость) данных, которой будет посвящена отдельная статья.
Объекты защиты
Для начала рассмотрим, на каких уровнях можно защитить информацию в БД, т. е. определим объекты защиты. Во-первых, мы можем защищать данные, хранящиеся в различных структурных элементах БД, т. е. защищать (см. рис. 1):
- целиком базы данных;
- отдельные таблицы БД;
- записи конкретных таблиц БД;
- значения конкретных полей таблиц или записей.
Рис. 1. Защита элементов БД
Во-вторых, логические структурные элементы БД физически хранятся на жестких дисках и передаются по компьютерным сетям, следовательно, мы можем защищать данные по месту их физического воплощения, например:
- файлы данных;
- программные модули СУБД (от модификации и внедрения программных закладок, изменяющих логику работы СУБД в каких-либо целях атакующего);
- каналы взаимодействия между компонентами СУБД (особенно актуально в случае распределенных СУБД) и каналы взаимодействия между СУБД и пользователями.
Защищать программные модули, а также информацию, хранящуюся на жестком диске и передаваемую по сети, можно точно так же, как и любую аналогичную информацию, не относящуюся к СУБД. Например, с помощью моделей доступа, а также с помощью криптографических методов:
- шифрование файлов и сетевого трафика поможет обеспечить конфиденциальность;
- методы контроля целостности (например, хэширование) позволят сохранять целостность данных и программных модулей.
Более интересна задача выборочной защиты данных, хранящихся в конкретных полях или записях БД. В данном случае какие-либо методы защиты на файловом уровне не помогают и кажется необходимым использовать специфичные для БД методы защиты, в частности:
- представления (views);
- триггеры;
- встроенные функции шифрования данных.
Рассмотрим поочередно данные методы.
Представления
«Представление – это поименованная динамически поддерживаемая сервером выборка из одной или нескольких таблиц» [1]. Иными словами, представление является виртуальной таблицей, все записи которой формируются в процессе обращения пользователя к представлению согласно тому запросу, который был сопоставлен данному представлению.
Таким образом, пользователь получает доступ не к целой таблице (или к нескольким таблицам), а, в простейшем случае, к совокупности столбцов или записей, которые определены в представлении.
Например, существует таблица, которая содержит основную информацию о преподавателях института:
Prep |
NP |
Name |
Position |
ChartNum |
Salary |
1 |
Иванов |
Доцент |
403 |
20 000 |
2 |
Петров |
Ст. преп. |
556 |
10 000 |
3 |
Сидоров |
Профессор |
212 |
30 000 |
И есть три сотрудника института, которым необходимы данные из этой таблицы:
- работник кадровой службы, который не должен иметь доступ к столбцу зарплаты (salary);
- работник бухгалтерии, который должен иметь доступ ко всем полям, но только в том случае, если преподаватель не относится к высокооплачиваемым (скажем, его зарплата не превышает 20 000);
- главный бухгалтер, который должен иметь доступ ко всем полям всех записей.
Такое разграничение доступа решается с помощью представлений очень просто:
- главный бухгалтер работает непосредственно с таблицей Prep;
- работник кадровой службы работает с представлением PrepView1, в котором отсутствует столбец Salary;
- работник бухгалтерии работает с представлением PrepView2, в котором отсутствуют записи о преподавателях с высокой зарплатой.
Упомянутые представления PrepView1 и PrepView2 могут быть созданы следующими простыми запросами (использована нотация СУБД MySQL 5.0 [2]):
- CREATE VIEW PrepView1 AS SELECT NP, Name, Position, ChartNum FROM Prep;
- CREATE VIEW PrepView2 AS SELECT NP, Name, Position, ChartNum, Salary FROM Prep WHERE Salary <= 20000;
Исходя из приведенного выше примера, можно смело утверждать, что представление является простейшим в использовании методом защиты как конфиденциальности, так и целостности данных, который позволяет:
- четко ограничить данные, доступные пользователю;
- контролировать тот набор данных, который пользователь имеет право модифицировать.
Триггеры
«Триггер (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.
Заключение
Рассмотренные в статье методы защиты данных встроенными средствами СУБД просты в использовании, но могут достаточно эффективно обеспечить конфиденциальность и целостность данных. Их объединяет один серьезный недостаток – защиту с их помощью достаточно сложно наложить на уже существующую систему. Тем не менее, на этапе проектирования защищенных БД всегда стоит предусмотреть дополнительный рубеж защиты в виде совокупного использования представлений, триггеров и встроенных криптографических функций СУБД.
Литература
- А. Лихоносов. Безопасность баз данных. Учебное пособие. М., 2010.
- MySQL 5.0 Reference Manual..
- Триггер (базы данных). Материалы из Википедии – свободной энциклопедии.
- FIPS Publication 197. Specification for the Advanced Encryption Standard.– November 26, 2001.
- S. Panasenko. SHA Hash Functions: History & Current State.– 2009.
