Рейтинг@Mail.ru

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.
Просмотров: 8475

Мнения экспертов

  • Родыгин Е.В.Родыгин Е.В.
    Санкт-Петербургский НТЦ ФГУП "НПП "Гамма"
    Заместитель директора
Очень хорошая и полезная статья! В статье отмечены основные объекты доступа и угрозы которые к ним относятся. При этом учтены не только объекты традиционно относящиеся к СУБД но и файлы ПО самой СУБД, о чем даже специалисты часто забывают. Указаны основные и простые практические механизмы и методы защиты данных в СУБД в том числе отражено применение криптографических механизмов. Статья краткая и понятная, не содержит что называется «воды» и будет полезна для ознакомления широкому кругу специалистов использующих и проектирующих АС с использованием СУБД в защищённом исполнении.

Автор предлагает решать задачу защиты данных за счет выборочной защиты данных, хранящихся в конкретных полях или записях БД. При этом, как известно, существующие методы защиты на уровне файлов не обеспечивают должной защиты, и автором предлагается применять специфичные для БД методы защиты: представления (views), триггеры, встроенные функции шифрования данных. Применение указанных методов защиты, является не то что новым, но вполне актуальным и реализуемым на практике. Рассматривая задачу защиты данных, как мне кажется, автору удалось рассмотреть применимость следующих функций защиты:
  • Защита доступа
  • Разграничение доступа
  • Шифрование данных
Однако, как мне кажется, не уделено должного внимания аудиту доступа к данным. На сегодняшний день современные СУБД имеет мощные средства аудита действий пользователей, включающих как доступ к данным, так и события регистрации/выхода и изменения структуры БД. Однако, данные средства аудита не позволяет проследить за действиями, которые совершаются администратором базы данных, а также не мешают ему изменять журнал аудита, удаляя любые строки и не оставляя следов подобных действий. В перспективных СУБД применяется аудит деятельности и защиты данных аудита от привилегированных пользователей, включая администраторов БД. В связи с чем, используется функционал, позволяющий изолировать администратора БД от управления аудитом. При этом обеспечивается более высокий уровень безопасности БД, а также более гибкими становятся правила назначения аудита. При рассмотрении шифрования данных помимо используемых AES и 3DES (с длинами ключей 128,192, соответственно и вариацией длины блока (для AES)), автору можно было привести примеры использования сертифицированных криптографически стойких хеш-функций, использующих алгоритмы описанные в ГОСТ Р 34.11. Это является тем более актуальным, что использование сертифицированных средств криптографической защиты информации является очень актуальным при использовании их рамках проектирования информационных систем персональных данных в соответствии с ФЗ-512 «О персональных данных».

  • Рогожкин О.Ю.Рогожкин О.Ю.
    ООО "Межрегиональная Информационно-техническая Фирма"
    исполнительный директор
Однозначно сложилось мнение, что статья практически бесполезна для большей группы читателей, поскольку затрагивает достаточно специализированную область знаний IT-специалистов, равно как бесполезна и для названной узкой группы IT-специалистов, занимающихся СУБД в части обеспечения безопастности, поскольку изложенные в статье сведения, в силу их отношения к очевидным аксиомам в данной области, вызывают вопрос: «Ну и что? Это вроде всем известно…» Может быть автор так глубоко спрятал смысл информации, которую хотел довести до читателя, что она сразу не бросилась в глаза при прочтении? В этом случае скорее это тоже недостаток...

Ваши комментарии:

Для того, чтобы оставлять коментарии, Вам нужно авторизоваться на Sec.Ru. Если У Вас еще нет аккаунта, пройдите процедуру регистрации.


Автор

Информация

  • Снимай крутую видеорекламу - выкладывай на Sec.Ru!

    Рекламный ролик - один из самых эффективных способов донесения информации. И он отлично подходит для рекламирования любой продукции, в т.ч. и продукции рынка систем безопасности.
    Поэтому редакция Портала решила составить свой рейтинг лучших рекламных видеороликов. Все они разные и все чем-то покоряют: красотой, задумкой, стилем съемки, посылом, необычным финалом.
    Некоторые из них язык не повернется назвать иначе как шедевром короткого метра. Смотрим, наслаждаемся, делаем заметки, учимся творить рекламу правильно.
    Если Вы хотите выложить видеоролик о своей продукции на Sec.Ru, пишите о своем желании на adv@sec.ru!

    Картинка: Jpg, 100x150, 16,47 Кбайт

    Мотор!

Отраслевые СМИ

Все права защищены 2002 – 2016
Rambler's Top100 �������@Mail.ru