Курсовая работа: Проблемы безопасности баз данных. Обеспечение безопасности в СУБ

5.1. Методы обеспечения безопасности

В современных СУБД поддерживается один из двух широко распространенных подходов к вопросу обеспечения безопасности данных, а именно избирательный подход или обязательный подход. В обоих подходах единицей данных или "объектом данных", для которых должна быть создана система безопасности, может быть как вся база данных целиком или какой-либо набор отношений, так и некоторое значение данных для заданного атрибута внутри некоторого кортежа в определенном отношении. Эти подходы отличаются следующими свойствами:

1. В случае избирательного управления некий пользователь обладает различными правами (привилегиями или полномочиями) при работе с разными объектами. Более того, разные пользователи обычно обладают и разными правами доступа к одному и тому же объекту. Поэтому избирательные схемы характеризуются значительной гибкостью.

2. В случае обязательного управления, наоборот, каждому объекту данных присваивается некоторый классификационный уровень, а каждый пользователь обладает некоторым уровнем допуска. Следовательно, при таком подходе доступом к определенному объекту данных обладают только пользователи с соответствующим уровнем допуска. Поэтому обязательные схемы достаточно жестки и статичны.

Независимо от того, какие схемы используются – избирательные или обязательные, все решения относительно допуска пользователей к выполнению тех или иных операций принимаются на стратегическом, а не техническом уровне. Поэтому они находятся за пределами досягаемости самой СУБД, и все, что может в такой ситуации сделать СУБД, – это только привести в действие уже принятые ранее решения. Исходя из этого, можно отметить следующее:

Во-первых. Результаты стратегических решений должны быть известны системе (т.е. выполнены на основе утверждений, заданных с помощью некоторого подходящего языка) и сохраняться в ней (путем сохранения их в каталоге в виде правил безопасности, которые также называются полномочиями).

Во-вторых. Очевидно, должны быть некоторые средства регулирования запросов доступа по отношению к соответствующим правилам безопасности. (Здесь под "запросом, доступа" подразумевается комбинация запрашиваемой операции, запрашиваемого, объекта и запрашивающего пользователя.) Такая проверка выполняется подсистемой безопасности СУБД, которая также называется подсистемой полномочий.

В-третьих. Для того чтобы разобраться, какие правила безопасности к каким запросам доступа применяются, в системе должны быть предусмотрены способы опознания источника этого запроса, т.е. опознания запрашивающего пользователя. Поэтому в момент входа в систему от пользователя обычно требуется ввести не только его идентификатор (например, имя или должность), но также и пароль (чтобы подтвердить свои права на заявленные ранее идентификационные данные). Обычно предполагается, что пароль известен только системе и некоторым лицам с особыми правами.

В отношении последнего пункта стоит заметить, что разные пользователи могут обладать одним и тем же идентификатором некоторой группы. Таким образом, в системе могут поддерживаться группы пользователей и обеспечиваться одинаковые права доступа для пользователей одной группы, например для всех лиц из расчетного отдела. Кроме того, операции добавления отдельных пользователей в группу или их удаления из нее могут выполняться независимо от операции задания привилегий для этой группы. Обратите внимание, однако, что местом хранения информации о принадлежности к группе также является системный каталог (или, возможно, база данных).

Перечисленные выше методы управления доступом на самом деле являются частью более общей классификации уровней безопасности. Прежде всего в этих документах определяется четыре класса безопасности (security classes) – D, С, В и А. Среди них класс D наименее безопасный, класс С – более безопасный, чем класс D, и т.д. Класс D обеспечивает минимальную защиту, класс С – избирательную, класс В – обязательную, а класс А – проверенную защиту.

Избирательная защита. Класс С делится на два подкласса – С1 и С2 (где подкласс С1 менее безопасен, чем подкласс С2), которые поддерживают избирательное управление доступом в том смысле, что управление доступом осуществляется по усмотрению владельца данных.

Согласно требованиям класса С1 необходимо разделение данных и пользователя, т.е. наряду с поддержкой концепции взаимного доступа к данным здесь возможно также организовать раздельное использование данных пользователями.

Согласно требованиям класса С2 необходимо дополнительно организовать учет на основе процедур входа в систему, аудита и изоляции ресурсов.

Обязательная защита. Класс В содержит требования к методам обязательного управления доступом и делится на три подкласса – В1, В2 и В3 (где В1 является наименее, а В3 – наиболее безопасным подклассом).

Согласно требованиям класса В1 необходимо обеспечить "отмеченную защиту" (это значит, что каждый объект данных должен содержать отметку о его уровне классификации, например: секретно, для служебного пользования и т.д.), а также неформальное сообщение о действующей стратегии безопасности.

Согласно требованиям класса В2 необходимо дополнительно обеспечить формальное утверждение о действующей стратегии безопасности, а также обнаружить и исключить плохо защищенные каналы передачи информации.

Согласно требованиям класса В3 необходимо дополнительно обеспечить поддержку аудита и восстановления данных, а также назначение администратора режима безопасности.

Проверенная защита. Класс А является наиболее безопасным и согласно его требованиям необходимо математическое доказательство того, что данный метод обеспечения безопасности совместимый и адекватен заданной стратегии безопасности.

Хотя некоторые коммерческие СУБД обеспечивают обязательную защиту на уровне класса В1, обычно они обеспечивают избирательное управление на уровне класса С2.

5.2. Избирательное управление доступом

Избирательное управление доступом поддерживается многими СУБД. Избирательное управление доступом поддерживается в языке SQL.

В общем случае система безопасности таких СУБД базируется на трех компонентах:

1. Пользователи. СУБД выполняет любое действия с БД от имени какого-то пользователя. Каждому пользователю присваивается идентификатор – короткое имя, однозначно определяющее пользователя в СУБД. Для подтверждения того, что пользователь может работать с введенным идентификатором используется пароль. Таким образом, с помощью идентификатора и пароля производится идентификация и аутентификация пользователя. Большинство коммерческих СУБД позволяет объединять пользователей с одинаковыми привилегиями в группы – это позволяет упростить процесс администрирования.

2. Объекты БД. По стандарту SQL2 защищаемыми объектами в БД являются таблицы, представления, домены и определенные пользователем наборы символов. Большинство коммерческих СУБД расширяет список объектов, добавляя в него хранимые процедуры и др. объекты.

3. Привилегии. Привилегии показывают набор действий, которые возможно производить над тем или иным объектом. Например пользователь имеет привилегию для просмотра таблицы.

5.3. Обязательное управление доступом

Методы обязательного управления доступом применяются к базам данных, в которых данные имеют достаточно статичную или жесткую структуру, свойственную, например, правительственным или военным организациям. Как уже отмечалось, основная идея заключается в том, что каждый объект данных имеет некоторый уровень классификации, например: секретно, совершенно секретно, для служебного пользования и т.д., а каждый пользователь имеет уровень допуска с такими же градациями, что и в уровне классификации. Предполагается, что эти уровни образуют строгий иерархический порядок, например: совершенно секретно ® секретно ® для служебного пользования и т.д. Тогда на основе этих сведений можно сформулировать два очень простых правила безопасности:

1. пользователь имеет доступ к объекту, только если его уровень допуска больше или равен уровню классификации объекта.

2. пользователь может модифицировать объекту, только если его уровень допуска равен уровню классификации объекта.

Правило 1 достаточно очевидно, а правило 2 требует дополнительных разъяснений. Прежде всего следует отметить, что по-другому второе правило можно сформулировать так: любая информация, записанная некоторым пользователем, автоматически приобретает уровень, равный уровню классификации этого пользователя. Такое правило необходимо, например, для того, чтобы предотвратить запись секретных данных, выполняемую пользователем с уровнем допуска "секретно", в файл с меньшим уровнем классификации, что нарушает всю систему секретности.

В последнее время методы обязательного управления доступом получили широкое распространение. Требования к такому управлению доступом изложены в двух документах, которые неформально называются "оранжевой" книгой (Orange Book) и "розовой" книгой (Lavender Book). В "оранжевой" книге перечислен набор требований к безопасности для некой "надежной вычислительной базы" (Trusted Computing Base), а в "розовой" книге дается интерпретация этих требований для систем управления базами данных.

5.4. Шифрование данных

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

Для обсуждения основных концепций кодирования данных следует ввести некоторые новые понятия. Исходные (незакодированные) данные называются открытым текстом. Открытый текст шифруется с помощью специального алгоритма шифрования. В качестве входных данных для такого алгоритма выступают открытый текст и ключ шифрования, а в качестве выходных – зашифрованная форма открытого текста, которая называется зашифрованным текстом. Если детали алгоритма шифрования могут быть опубликованы или, по крайней мере, могут не утаиваться, то ключ шифрования обязательно хранится в секрете. Именно зашифрованный текст, который непонятен тем, кто не обладает ключом шифрования, хранится в базе данных и передается по коммуникационному каналу.

5.5. Контрольный след выполняемых операций

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

Для сохранения контрольного следа обычно используется особый файл, в котором система автоматически записывает все выполненные пользователями операции при работе с обычной базой данных. Типичная запись в файле контрольного следа может содержать такую информацию:

2. терминал, с которого была вызвана операция;

3. пользователь, задавший операцию;

4. дата и время запуска операции;

5. вовлеченные в процесс исполнения операции базовые отношения, кортежи и атрибуты;

6. старые значения;

7. новые значения.

Как уже упоминалось ранее, даже констатация факта, что в данной системе поддерживается контрольное слежение, в некоторых случаях весьма существенна для предотвращения несанкционированного проникновения в систему.

5.6. Поддержка мер обеспечения безопасности в языке SQL

В действующем стандарте языка SQL предусматривается поддержка только избирательного управления доступом. Она основана на двух более или менее независимых частях SQL. Одна из них называется механизмом представлений, который (как говорилось выше) может быть использован для скрытия очень важных данных от несанкционированных пользователей. Другая называется подсистемой полномочий и наделяет одних пользователей правом избирательно и динамично задавать различные полномочия другим пользователям, а также отбирать такие полномочия в случае необходимости.

5.7. Директивы GRANT и REVOKE

Механизм представлений языка SQL позволяет различными способами разделить базу данных на части таким образом, чтобы некоторая информация была скрыта от пользователей, которые не имеют прав для доступа к ней. Однако этот режим задается не с помощью параметров операций, на основе которых санкционированные пользователи выполняют те или иные действия с заданной частью данных. Эта функция (как было показано выше) выполняется с помощью директивы GRANT.

Обратите внимание, что создателю любого объекта автоматически предоставляются все привилегии в отношении этого объекта.

Стандарт SQL1 определяет следующие привилегии для таблиц:

1. SELECT – позволяет считывать данные из таблицы или представления;

INSERT – позволяет вставлять новые записи в таблицу или представление;

UPDATE – позволяет модифицировать записи из таблицы или представления;

DELETE – позволяет удалять записи из таблицы или представления.

Стандарт SQL2 расширил список привилегий для таблиц и представлений:

1. INSERT для отдельных столбцов, подобно привилегии UPDATE;

2. REFERENCES – для поддержки внешнего ключа.

Помимо перечисленных выше добавлена привилегия USAGE – для других объектов базы данных.

Кроме того, большинство коммерческих СУБД поддерживает дополнительные привилегии, например:

1. ALTER – позволяет модифицировать структуру таблиц (DB2, Oracle);

2. EXECUTE – позволяет выполнять хранимые процедуры.

Создатель объекта также получает право предоставить привилегии доступа какому-нибудь другому пользователю с помощью оператора GRANT. Ниже приводится синтаксис утверждения GRANT:

GRANT {SELECT|INSERT|DELETE|(UPDATE столбец, …)}, …

ON таблица ТО {пользователь | PUBLIC}

Привилегии вставки (INSERT) и обновления (UPDATE) (но не привилегии выбора SELECT, что весьма странно) могут задаваться для специально заданных столбцов.

Если задана директива WITH GRANT OPTION, это значит, что указанные пользователи наделены особыми полномочиями для заданного объекта – правом предоставления полномочий. Это, в свою очередь, означает, что для работы с данным объектом они могут наделять полномочиями других пользователей

Например: предоставить пользователю Ivanov полномочия для осуществления выборки и модификации фамилий в таблице Students с правом предоставления полномочий.

GRANT SELECT, UPDATE StName

ON Students ТО Ivanov WITH GRANT OPTION

Если пользователь А наделяет некоторыми полномочиями другого пользователя В, то впоследствии он может отменить эти полномочия для пользователя В. Отмена полномочий выполняется с помощью директивы REVOKE с приведенным ниже синтаксисом.

REVOKE {{SELECT | INSERT | DELETE | UPDATE},…|ALL PRIVILEGES}

ON таблица,… FROM {пользователь | PUBLIC},… {CASCADE | RESTRICT}

Поскольку пользователь, с которого снимается привилегия, мог предоставить ее другому пользователю (если обладал правом предоставления полномочий), возможно возникновение ситуации покинутых привилегий. Основное предназначение параметров RESTRICT и CASCADE заключается в предотвращении ситуаций с возникновением покинутых привилегий. Благодаря заданию параметра RESTRICT не разрешается выполнять операцию отмены привилегии, если она приводит к появлению покинутой привилегии. Параметр CASCADE указывает на последовательную отмену всех привилегий, производных от данной.

Например: снять с пользователя Ivanov полномочия для осуществления модификации фамилий в таблице Students. Также снять эту привилегию со всех пользователей, которым она была предоставлена Ивановым.

ON Students FROM Ivanov CASCADE

При удалении домена, таблицы, столбца или представления автоматически будут удалены также и все привилегии в отношении этих объектов со стороны всех пользователей.

5.8. Представления и безопасность

Создавая представления, и давая пользователям разрешение на доступ к нему, а не к исходной таблице, можно тем самым ограничить доступ пользователя, разрешив его только к заданным столбцам или записям. Таким образом, представления позволяют осуществить полный контроль над тем, какие данные доступны тому или иному пользователю.

Заключение

Для минимизации риска потерь необходима реализация комплекса нормативных, организационных и технических защитных мер, в первую очередь: введение ролевого управления доступом, организация доступа пользователей по предъявлению цифрового сертификата, а в ближайшей перспективе – промышленное решение по выборочному шифрованию и применение алгоритмов ГОСТ для шифрования выбранных сегментов базы.

Для полного решения проблемы защиты данных администратор безопасности должен иметь возможность проводить мониторинг действий пользователей, в том числе с правами администратора. Поскольку штатная система аудита не имеет достаточных средств защиты, необходима независимая система, защищающая корпоративную сеть не только снаружи, но и изнутри. В будущем должны также появиться типовые методики комплексного решения задачи защиты баз данных для предприятий разного масштаба – от мелких до территориально распределенных.

Внутренняя операционная информация компании, персональные данные сотрудников, финансовая информация, информация о заказчиках и клиентах, интеллектуальная собственность, исследования рынка, анализ деятельности конкурентов, платежная информации - это сведения, которые чаще всего интересуют киберпреступников, и почти всегда они хранятся в корпоративных базах данных.

Значимость и ценность этой информации приводит к необходимости обеспечения защиты не только элементов инфраструктуры, но и самих баз данных. Попробуем комплексно рассмотреть и систематизировать вопросы безопасности различных систем управления базами данных (СУБД) в свете новых угроз, общих тенденций развития информационной безопасности и их возрастающей роли и разнообразия.

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

История развития СУБД

Исторически развитие систем безопасности баз данных происходило как реакция на действия злоумышленников. Эти изменения также были обусловлены общим развитием баз данных от решений на мейнфреймах до облачных хранилищ.

Можно выделить следующие архитектурные подходы:

полный доступ всех пользователей к серверу БД;
разделение пользователей на доверенных и частично доверенных средствами СУБД;
введение системы аудита (логов действий пользователей) средствами СУБД;
введение шифрования данных; вынос средств аутентификации за пределы СУБД в операционные системы и промежуточное ПО; отказ от полностью доверенного администратора данных.

Введение средств защиты как реакции на угрозы не обеспечивает защиту от новых способов атак и формирует разрозненное представление о самой проблеме обеспечения безопасности.

С учетом таких эволюционных особенностей появилось и существует большое количество разнородных средств обеспечения безопасности, что в итоге привело к отсутствию понимание комплексной безопасности данных. Отсутствует общий подход к безопасности хранилищ данных. Усложняется и прогнозирование будущих атак, а также разработка защитных механизмов. Более того, для многих систем сохраняется актуальность уже давно известных атак, усложняется подготовка специалистов по безопасности.

Современные проблемы обеспечения безопасности БД

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

проблемами безопасности серьезно занимаются только крупные производители;
программисты баз данных, прикладные программисты и администраторы не уделяют должного внимания вопросам безопасности;
разные масштабы и виды хранимых данных требуют разных подходов к безопасности;
различные СУБД используют разные языковые конструкции для доступа к данным, организованным на основе одной и той же модели;
появляются новые виды и модели хранения данных.

Многие уязвимости сохраняют актуальность за счет невнимания или незнания администраторами систем баз данных вопросов безопасности. Например, простые SQL-инъекции широко эксплуатируются сегодня в отношении различных web-приложений, в которых не уделяется достаточного внимания входным данным запросов.

Применение различных средств обеспечения информационной безопасности является для организации компромиссом в финансовом плане: внедрение более защищенных продуктов и подбор более квалифицированного персонала требуют больших затрат. Компоненты безопасности зачастую могут негативно влиять на производительность СУБД.

Эти проблемы усугубляются с появлением и широким распространением нереляционных СУБД, оперирующих другой моделью данных, однако построенных по тем же принципам, что и реляционные. Многообразие современных NoSQL-решений приводит к разнообразию применяемых моделей данных и размывает границу понятия БД.

Следствием этих проблем и отсутствия единых методик является нынешняя ситуация с безопасностью . В большинстве NoSQL-систем отсутствуют не только общепринятые механизмы безопасности вроде шифрования, поддержки целостности и аудита данных, но даже развитые средства аутентификации пользователей.

Особенности защиты БД

Хранилища данных включает в себя два компонента: хранимые данные (собственно БД) и программы управления (СУБД).

Обеспечение безопасности хранимой информации, в частности, невозможно без обеспечения безопасного управления данными. Исходя из этого, все уязвимости и вопросы безопасности СУБД можно разделить на две категории: зависящие от данных и не зависящие от данных.

Уязвимости, независящие от данных, являются характерными и для всех прочих видов ПО. Их причиной, например, может стать несвоевременное обновление ПО, наличие неиспользуемых функций или недостаточная квалификация администраторов ПО.

Большинство аспектов безопасности СУБД является именно зависящими от данных. В то же время многие уязвимости являются косвенно зависимыми от данных. Например, большинство СУБД поддерживают запросы к данным с использованием некоторого языка запросов, содержащего наборы доступных пользователю функций (которые, в свою очередь, тоже можно считать операторами запросного языка) или произвольные функции на языке программирования.

Архитектура применяемых языков, по крайней мере, то, что касается специализированных языков и наборов функций, напрямую связана с моделью данных, применяемой для хранения информации. Таким образом, модель определяет особенности языка, и наличие в нем тех или иных уязвимостей. Причем такие уязвимости, например, как инъекция, выполняются по-разному (sql-инъекция, java-инъекция) в зависимости от синтаксиса языка.

Требования к безопасности БД

На основании разделения уязвимостей можно выделить зависящие и независящие от данных меры обеспечения безопасности хранилищ информации.

Не зависящими от данных можно назвать следующие требования к безопасной системе БД:

Функционирование в доверенной среде.

Под доверенной средой следует понимать инфраструктуру предприятия и ее защитные механизмы, обусловленные политиками безопасности. Таким образом, речь идет о функционировании СУБД в соответствии с правилами безопасности, применяемыми и ко всем прочим системам предприятия.

Организация физической безопасности файлов данных.

Требования к физической безопасности файлов данных СУБД в целом не отличаются от требований, применяемых к любым другим файлам пользователей и приложений.

Организация безопасной и актуальной настройки СУБД.

Данное требование включает в себя общие задачи обеспечения безопасности, такие как своевременная установка обновлений, отключение неиспользуемых функций или применение эффективной политики паролей.

Следующие требования можно назвать зависящими от данных :

Безопасность пользовательского ПО.

Сюда можно отнести задачи построения безопасных интерфейсов и механизмов доступа к данным.

Безопасная организация и работа с данными.

Вопрос организации данных и управления ими является ключевым в системах хранения информации. В эту область входят задачи организации данных с контролем целостности и другие, специфичные для СУБД проблемы безопасности. Фактически эта задача включает в себя основной объем зависящих от данных уязвимостей и защиты от них.

Основные аспекты создания защищенных БД

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

Разработка комплексных методик обеспечения безопасности хранилищ данных на предприятии.

Создание комплексных методик позволит применять их при разработке и внедрении хранилищ данных и пользовательского ПО. Следование комплексной методике позволит избежать многих ошибок управления СУБД и защититься от наиболее распространенных на сегодняшний день уязвимостей.

Оценка и классификация угроз и уязвимостей СУБД.

Классификация угроз и уязвимостей СУБД позволит упорядочить их для последующего анализа и защиты, даст возможность специалистам по безопасности установить зависимость между уязвимостями и причинами их возникновения. В результате при введении конкретного механизма в СУБД, у администраторов и разработчиков появится возможность установить и спрогнозировать связанные с ним угрозы и заранее подготовить соответствующие средства обеспечения безопасности.

Разработка стандартных механизмов обеспечения безопасности.

Стандартизация подходов и языков работы с данными позволит создать средства обеспечения безопасности, применимые к разным СУБД. В данный момент они могут быть лишь методическими или теоретическими, так как, к сожалению, появление готовых комплексных программных средств защиты во многом зависит от производителей и разработчиков СУБД и их желания создавать и следовать стандартам.

Об авторе

Максим Советкин окончил механико-математический факультет Белорусского государственного университета, работает в Itransition уже более семи лет. Сегодня он - ведущий системный инженер, отвечает за проектирование, развитие и поддержку корпоративной ИТ-инфраструктуры.

В настоящее время БД являются ключевыми компонентами любого web-приложения, давая web-сайтам возможность предоставлять разнообразное динамическое содержимое. Поскольку в таких БД может храниться очень секретная или высокоточная информация, вы должны предусмотреть их основательную защиту.

Для получения или сохранения любой информации вам необходимо установить соединение с БД, отправить верный запрос, получить результат и закрыть соединение.
В настоящее время чаще всего используется язык запросов Structured Query Language (SQL). См., как взломщик может .

PHP сам по себе не может защитить вашу БД. Последующие разделы являются введением в основы доступа и манипулирования БД в PHP-скриптах.

Запомните простое правило: максимальная защита. Необходимо защищать БД как можно сильнее, что уменьшит вероятность успеха взлома и получения, нарушения или уничтожения ценной информации.

Дизайн БД

Первый шаг - это всегда создание БД, если только вы не хотите использовать готовую БД стороннего производителя. Когда БД создаётся, она назначается пользователю, который выполняет оператор создания. Обычно только владелец/owner (или superuser) может выполнять действия с объектами в БД, а чтобы и другие пользователи могли пользоваться этой БД, необходимо дать привилегии доступа.

Приложения никогда не должны соединяться с БД как её owner или superuser, поскольку эти бюджеты могут выполнять любой запрос, модифицировать схему (например, стереть таблицы) или удалять всё содержимое полностью.

Вы можете создать различных пользователей БД для каждого аспекта вашего приложения с ограничениями на использование объектов БД. Нужно давать только самые необходимые привилегии и необходимо исключать возможность работы с БД одного пользователя в разных вариантах использования. Это значит, что, если взломщик получает доступ к вашей БД с использованием одних привилегий, он сможет делать все изменения, какие только можно сделать ваше приложение.

Мы советуем не реализовывать всю бизнес-логику в web-приложении (т.е. в ваших скриптах), а использовать для этого схему БД с триггерами, просмотрами или правилами. Если система разрастается, понадобятся новые порты для БД, и вы должны будете заново реализовывать всю логику для каждого отдельного клиента БД. Вместо этого, можно использовать тригеры для прозрачной и автоматической обработки полей, что часто необходимо при отладке ваших приложений или при трассировке отката транзакций.

Соединение с БД

Вы можете установить соединение через SSL с целью шифровки соединения клиент/сервер для повышения защиты или использовать ssh для шифровки сетевого соединения между клиентами и сервером БД. Если вы реализуете что-нибудь из этого, то мониторинг вашего трафика и получение информации значительно усложнится.

Модель шифровки при хранении/Encrypted Storage

SSL/SSH защищает передачу данных с клиента на сервер, SSL/SSH не защищает постоянные данные, хранимые в БД. SSL это протокол on-the-wire.

Если взломщик получил прямой доступ к вашей БД (в обход web-сервера), он получит доступ к закрытым данным и может использовать их или повредить, если информация не защищена на уровне самой БД. Шифровка данных - хороший способ предотвратить это, но мало какие БД предлагают этот тип шифровки данных.

Простейший способ решения этой проблемы - создать сначала ваш собственный пакет шифрования данных, а затем использовать его PHP-скриптах. PHP может в этом случае помочь вам различными расширениями, такими как Mcrypt и Mhash , покрывающими большое количество алгоритмов шифрования данных. Скрипт сначала шифрует сохраняемые данные, а затем дешифрует их при запросе. См. в описании следующих примеров о том, как работает шифрование.

Инъекция SQL

Многие web-разработчики не в курсе того, как запросы SQL могут быть подделаны, и считают, что SQL-запрос это надёжная команда.
SQL-запросы могут обойти управление доступом, стандартную аутентификацию и проверку авторизации, а некоторые SQL-запросы могут даже дать доступ к командам ОС хоста.

Direct SQL Command Injection это такая техника, когда взломщик создаёт или изменяет текущие команды SQL для получения доступа к скрытым данным, их переопределения или даже для выполнения опасных команд системного уровня на хосте БД. Это выполняется с помощью приложения, принимающего пользовательский ввод, и сочетания его со static-параметрами для построения SQL-запроса. Следующие примеры (к сожалению...) основаны на реальных фактах.

Благодаря отсутствию проверки ввода и соединения с БД или поведению superuser"а или того, кто может создавать пользователей, взломщик может создать superuser"а в вашей БД.

Обычно пользователи щёлкают ссылки "next", "prev", где $offset кодируется в URL. Скрипт ожидает, что входящее $offset это 10-ричное число. Однако кто-нибудь может попытаться вломиться, присоединив urlencode() "ированную форму следующей информации к URL:

// в PostgreSQL 0; insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd) select "crack", usesysid, "t","t","crack" from pg_shadow where usename="postgres"; -- // в MySQL 0; UPDATE user SET Password=PASSWORD("crack") WHERE user="root"; FLUSH PRIVILEGES;

Если это произойдёт, то скрипт даст доступ superuser"а к нему. Заметьте, что 0; предоставлен для того, чтобы задать правильное смещение/offset для запроса-оригинала и прервать его.

Примечание: обычной техникой является форсирование игнорирования SQL-разборщиком остальной части запроса, написанного разработчиком, с помощью -- (знака комментария в SQL).

Возможно получение паролей путём обмана ваших страниц с результатами поиска. Взломщику нужно лишь проверить, имеется ли отправленная переменная, используемая в SQL-операторе, которая не обрабатывается надлежащим образом. Эти фильтры могут быть установлены обычно в предыдущей форме для специализирования вариантов WHERE, ORDER BY, LIMIT и OFFSET в операторах SELECT . Если ваша БД поддерживает конструкцию UNION , взломщик может попытаться присоединить к оригинальному запросу целый запрос на список паролей из произвольной таблицы. Использование шифрованных полей password настоятельно рекомендуется.

Статическая часть запроса может комбинироваться с другим оператором SELECT , который выявит все пароли:

" union select "1", concat(uname||"-"||passwd) as name, "1971-01-01", "0" from usertable; --

Если этот запрос (играя с " и --) присоединить к одной из переменных, используемых в $query , запрос чудовищно изменится.

SQL UPDATEs также являются субъектами атаки на ваши БД. Есть угроза их расчленения и присоединения к ним совершенно нового запроса. Взломщик может поработать с SET . В этом случае нужно обладать некоторой схемой информации для успешного манипулирования запросом. Это можно сделать, проверив имена переменных формы, или просто выполнив грубое форсирование. Есть не так уж много соглашений по именованию полей для хранения паролей и имён пользователей.

Но пользователь-злоумышленник отправляет значение " or uid like"%admin%"; -- в $uid для изменения пароля admin"а или просто устанавливает в $pwd значение "hehehe", admin="yes", trusted=100 " (с ведомым пробелом) для получения дополнительных привилегий. Затем запрос скручивается:

Если взломщик отправляет значение a%" exec master..xp_cmdshell "net user test testpass /ADD" -- в $prod , то $query будет:

$query = "SELECT * FROM products WHERE id LIKE "%a%" exec master..xp_cmdshell "net user test testpass /ADD"--"; $result = mssql_query($query);

MSSQL Server выполняет операторы SQL в пакетном режиме, включая и команды добавления нового пользователя в локальную БД бюджетов. Если такое приложение запущено как sa и служба MSSQLSERVER запущена с достаточными привилегиями, хакер сможет получить бюджет для доступа к данной машине.

Примечание: некоторые из вышеприведённых примеров касаются определённых серверов БД. Это не означает, что аналогичные действия невозможны в отношении других продуктов. Работа вашего сервера БД может быть нарушена каким-нибудь другим способом.

Как этого избежать

Вы можете утешать себя тем, что хакер, в большинстве примеров, обязан владеть некоторой информацией о схеме БД. Вы правы, но вы никогда не знаете, когда и как будет предпринята попытка взлома, и если это произойдёт, ваша БД может оказаться доступной для просмотра. Если вы используете свободный ресурс или публично доступный пакет работы с БД, который может относиться к системе менеджмента содержимого или форуму, взломщики легко создадут копию участка вашего кода. Риск для системы безопасности может быть также и в случае плохо сформированного кода.

Этим атакам в основном подвергается код, написанный без учёта требований безопасности. Никогда не доверяйте вводу любого рода, особенно тому, который поступает со стороны клиента, даже если он приходит от select-списка, скрытого/hidden поля или куки/cookie. Первый пример показывает, что такой небезупречный запрос может привести к тяжким последствиям.

Помимо всего прочего, вы можете извлечь пользу из запросов логинга в вашем скрипте или в самой БД, если она это поддерживает. Очевидно, что логинг не может предотвратить попытку нанесения вреда, но может помочь для трассировки "обманутого" приложения.
log полезен не сам по себе, а содержащейся в нём информацией. Чем больше деталей, тем обычно лучше.

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

Далее для назначения/отмены привилегий используется язык SQL, включающий операторы GRANT, REVOKE и т. п. Большинство современных реляционных СУБД поддерживает дискреционную (DAC) и мандатную (MAC) модели разграничения доступа, а также дополнительные средства обеспечения безопасности.

На всех стадиях жизненного цикла информационной системы, построенной на основе реляционной СУБД, возможны реализации большого числа угроз различных классов. Эти возможности следуют как из свойств самой реляционной модели данных, так и из особенностей реализации СУБД различными производителями и используемой модели разграничения доступа. Защита информации в реляционных базах данных имеет специфику, заключающуюся в том, что семантика обрабатываемых данных дает большие возможности по реализации различных угроз применительно к базе данных, чем. скажем, к файловой системе.

Под угрозой обычно понимают потенциально возможное событие, действие (воздействие), процесс или явление, которое может привести к нанесению ущерба чьим-либо интересам.

Угрозой информационной безопасности автоматизированной информационной системе (АИС) назовем возможность воздействия на информацию, обрабатываемую в системе, приводящего к искажению, уничтожению, копированию, блокированию доступа

к информации, а также возможность воздействия на компоненты информационной системы, приводящего к утрате, уничтожению или сбою функционирования носителя информации или средства управления программно-аппаратным комплексом системы.

Угроза нарушения конфиденциальности данных включает в себя любое умышленное или случайное раскрытие информации, хранящейся в вычислительной системе или передаваемой из одной системы в другую. К нарушению конфиденциальности ведет как умышленное действие, направленное на реализацию несанкционированного доступа к данным, так и случайная ошибка программного или неквалифицированного действия оператора, приведшая к передаче по открытым каналам связи незащищенной конфиденциальной информации.

Угроза нарушения целостности включает в себя любое умышленное или случайное изменение информации, обрабатываемой в информационной системе или вводимой из первичного источника данных. К нарушению целостности данных может привести как преднамеренное деструктивное действие некоторого лица, изменяющего данные для достижения собственных целей, так и случайная ошибка программного или аппаратного обеспечения, приведшая к безвозвратному разрушению данных.

Первый шаг в анализе угроз - их идентификация. Рассматриваемые виды угроз следует выбирать исходя из соображений здравого смысла (исключив, например, землетрясения, однако не забывая о возможности захвата организации террористами), но в пределах выбранных видов провести максимально подробный анализ.

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

2.1. Источники угроз информации баз данных

Разработка системы информационной безопасности должна базироваться на определенном перечне потенциальных угроз безопасности и установлении возможных источников их возникновения. Проектирование конкретной системы безопасности для любого объекта, в том числе и для систем баз данных, предполагает выявление и научную классификацию перечня источников угроз безопасности.

Сформулируем перечень внешних и внутренних угроз информационной безопасности баз данных.

Внешними дестабилизирующими факторами, создающими угрозы безопасности функционированию систем баз данных и СУБД, являются:

Умышленные, деструктивные действия лиц с целью искажения, уничтожения или хищения программ, данных и документов системы, причиной которых являются нарушения информационной безопасности защищаемого объекта;

Искажения в каналах передачи информации, поступающей от внешних источников, циркулирующих в системе и передаваемой потребителям, а также недопустимые значения и изменения характеристик потоков информации из внешней среды и внутри системы;

Сбои и отказы в аппаратуре вычислительных средств;

Вирусы и иные деструктивные программные элементы, распространяемые с использованием систем телекоммуникаций, обеспечивающих связь с внешней средой или внутренние коммуникации распределенной системы баз данных;

Изменения состава и конфигурации комплекса взаимодействующей аппаратуры системы за пределы, проверенные при тестировании или сертификации системы.

Внутренними источниками угроз безопасности баз данных и СУБД являются:

Системные ошибки при постановке целей и задач проектирования автоматизированных информационных систем и их компонент, допущенные при формулировке требований к функциям и характеристикам средств обеспечения безопасности системы;

Ошибки при определении условий и параметров функционирования внешней среды, в которой предстоит использовать информационную систему и, в частности, программно-аппаратные средства защиты данных;

Ошибки проектирования при разработке и реализации алгоритмов обеспечения безопасности аппаратуры, программных средств и баз данных;

Ошибки и несанкционированные действия пользователей, административного и обслуживающего персонала в процессе эксплуатации системы;

Недостаточная эффективность используемых методов и средств обеспечения информационной безопасности в штатных или особых условиях эксплуатации системы.

Полное устранение всех потенциальных угроз информационной безопасности баз данных принципиально невозможно. Реальная задача состоит в снижении вероятности реализации потенциальных угроз до приемлемого для конкретной системы уровня. Приемлемость соответствующего уровня угроз может определяться областью применения, выделенным бюджетом или положениями действующего законодательства. Как правило, не удается построить дерево угроз со строгой иерархией. Поэтому совокупный риск является достаточно сложной функцией уязвимости компонентов системы. Различные негативные воздействия также достаточно сложным образом влияют на основные характеристики качества и безопасности систем баз данных.

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

2.2. Классификация угроз информационной безопасности баз данных

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

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

Реализация всестороннего анализа угроз информационной безопасности любого объекта, в том числе и систем баз данных, требует проведения классификации. Научная классификация опирается на анализ предшествующего опыта, объединяет близкие по содержанию случаи в выделенные разделы классификатора. Независимо от принятого подхода к определению безопасности классификация угроз и их источников представляет самостоятельный интерес. Наличие различных классификаций позволяет исследователю не пропустить существенную для конкретной системы угрозу из богатого списка угроз информационной безопасности баз данных.

Проблема обеспечения информационной безопасности баз данных является многогранной. Сами базы данных - это модель реального мира, который бесконечно многообразен. Проектирование и сопровождение систем баз данных требуют современных программно-аппаратных средств обработки данных и достаточно сложных схем и структур организационного управления. Поэтому можно выбрать много оснований для классификации угроз информационной безопасности баз данных. Учитывая высокий темп изменений в компьютерной и телекоммуникационной индустрии, следует ясно понимать, что вряд ли представленная классификация является исчерпывающей.

Анализ современной научной литературы позволил выделить следующие варианты классификации возможных угроз нарушения информационной безопасности баз данных.

Классификация по цели реализации угрозы:

1. Нарушение конфиденциальности информации, т. е. использование информации, хранящейся в системе, лицами или процессами, которые не были определены владельцами информации.

2. Нарушение целостности информации, т. е. модификация или уничтожение информации для ее обесценивания путем утраты соответствия с состоянием моделируемых сущностей реального мира.

3 Полное или частичное нарушение работоспособности системы за счет вывода из строя или некорректного изменения режимов работы компонентов системы, включая их модификацию или подмену.

Классификация по природе возникновения угрозы:

1. Естественные угрозы - угрозы, вызванные воздействием на систему баз данных и ее компоненты объективных физических процессов или стихийно развивающихся природных явлений.

2. Искусственные угрозы - угрозы информационной безопасности систем баз данных, связанных с деятельностью человека.

Классификация по локализации источника угрозы представляется следующим образом:

1. Угрозы, непосредственным источником которых является человек:

Разглашение, передача или утрата атрибутов разграничения доступа (паролей, ключей шифрования, электронных замков и т. п.) легальными пользователями системы;

Подкуп или шантаж обслуживающего персонала или пользователей, имеющих необходимые полномочия, с целью получения их параметров для процедур аутентификации;

Копирование конфиденциальных данных легальным пользователем системы с целью неправомерного использования (продажа, шантаж и т. п.);

Взлом системы защиты с целью выполнения деструктивных действий лицом, не являющимся законным пользователем системы;

Внедрение агентов фирм-конкурентов или преступных организаций в обслуживающий персонал атакуемой информационной системы (в том числе в административную группу, в группу обеспечения информационной безопасности).

2. Угрозы, непосредственным источником которых являются штатные программно-аппаратные средства информационной системы:

Неквалифицированное использование или ошибочный ввод параметров программ, способных привести к полной или частичной потере работоспособности системы (аварийное завершение системных процессов, нецелевое расходование вычислительных ресурсов и т. п.);

Неквалифицированное использование или ошибочный ввод параметров программ, способных привести к необратимым изменениям в системе (инициализация баз данных, форматирование или реструктуризацию носителей информации, удаление данных и т. п.);

Отказы и сбои в работе операционной системы, СУБД и прикладных программ.

3. Угрозы, непосредственным источником которых являются несанкционированно используемые программно-аппаратные средства:

Нелегальное внедрение и использование программ, не являющихся необходимыми для выполнения нарушителем своих служебных обязанностей;

Нелегальное внедрение (из-за халатности легального пользователя) и использование троянских программ, предназначенных для исследования параметров автоматизированной информационной системы, сбора данных, зомбирования компьютера с последующим нецелевым расходованием ресурсов и т. п.;

Заражение компьютера вирусами с деструктивными функциями;

Работа генераторов шума и подобных источников электромагнитного излучения.

4. Угрозы, непосредственным источником которых является среда обитания:

Внезапное и длительное отключение систем электропитания;

Техногенные и природные катастрофы;

Всплески природных электромагнитных излучений.

Классификация по расположению источника угроз.

1. Угрозы, источник которых расположен вне контролируемой зоны места расположения автоматизированной информационной системы:

Нарушение нормальной работы или разрушение систем жизнеобеспечения зданий, в которых расположены технические средства и обслуживающий персонал системы;

Блокирование физического доступа на объект размещения автоматизированной системы обслуживающего персонала или пользователей;

Нарушение нормальной работы или разрушение внешних каналов связи (проводные линии, радиоканалы, оптоволокно).

2. Угрозы, источник которых расположен в пределах контролируемой зоны расположения автоматизированной информационной системы, исключая места расположения клиентских терминалов и серверных помещений:

Нарушение нормальной работы или разрушение систем электропитания и водоснабжения помещений, в которых расположены технические средства, обеспечивающие работу автоматизированной системы;

Физическое разрушение линий связи или аппаратуры, обеспечивающей работу информационной системы;

Считывание конфиденциальной информации из аппаратных средств телекоммуникационной или вычислительной техники с использованием перехвата электромагнитных излучений;

Выведения из рабочего состояния обслуживающего персонала (организация саботажа, применение отравляющих веществ, психотропных средств и т. п.).

3. Угрозы, источник которых имеет доступ к терминальным ус тройствам автоматизированной информационной системы:

Получение параметров входа в систему и аутентифицирующей информации с использованием видеонаблюдения, клавиатурных закладок и технологий подбора паролей;

Получение параметров входа в систему и аутентифицирующей информации с использованием мошеннических приемов, насилия или угрозы насилия;

Получение возможности несанкционированного входа в систему в период, когда легальный пользователь покинул рабочее место, не завершив сеанс взаимодействия с системой;

Получение конфиденциальной информации из распечаток результатов выполнения запросов и иных выводимых системой данных.

4. Угрозы, источник которых имеет доступ к помещениям, где расположены серверы автоматизированной информационной системы:

Физическое разрушение элементов серверов и коммутационной аппаратуры;

Выключение электропитания серверов и коммутационной аппаратуры;

Остановка серверных и иных критически важных для функционирования автоматизированной системы процессов;

Уничтожение или модификация критически важных для функционирования автоматизированной системы файлов операционной системы;

Нарушение штатной работы базовой операционной системы, например, за счет запуска процессов, активно расходующих ресурсы системы, критически важных для функционирования операционной системы файлов и т. п.;

Классификация по способу воздействия на методы и средства хранения данных информационной системы.

1. Угрозы нарушения информационной безопасности данных, хранимых на внешних запоминающих устройствах:

Нарушение конфиденциальности, уничтожение или модификация данных, сохраненных средствами создания резервных копий на магнитных носителях, путем незаконного восстановления баз данных с последующей заменой реальной копии или без таковой;

Нарушение конфиденциальности, уничтожение или модификация данных, созданных штатными средствами ведения журнала изменений баз данных;

Дискредитация криптографических систем защиты информации путем создания копии носителей ключевой информации;

Создание несанкционированных копий файлов операционной системы, содержащих информацию баз данных для проведения последующего анализа с целью доступа к конфиденциальной информации.

2. Угрозы нарушения информационной безопасности данных, хранимых в оперативной памяти серверов и клиентских компьютеров:

Изменение информации в оперативной памяти, используемой СУБД для кэширования данных, организации хранения промежуточных результатов выполнения запросов, констант и переменных процессов обработки данных;

Изменение информации в оперативной памяти, используемой операционной системой для кэширования данных, организации многопользовательского режима работы, констант и переменных процессов обработки данных;

Изменение информации в оперативной памяти, используемой прикладными программами в процессе организации и выполнения сессии взаимодействия с сервером баз данных и прослушивающим процессом.

3. Угрозы нарушения информационной безопасности данных, отображаемой на терминале пользователя или принтере:

Организация имитации процесса установления взаимодействия с сервером (ложной сессии) с целью получения идентификаторов и аутентифицирующей информации пользователей;

Изменение элементов данных, выводимых на терминал пользователя за счет перехвата потока вывода;

Изменение элементов данных, выводимых на принтер за счет перехвата потока вывода.

Классификация по характеру воздействия на информационную систему (целесообразно выделить два варианта):

Активное воздействие, т. е. выполнение пользователем системы баз данных каких-либо действий, выходящих за рамки его обязанностей, предусматривающих взаимодействие с системой, или действия внешнего по отношению к ИС пользователя или процесса, нацеленные на достижение одной или нескольких перечисленных выше целей;

Пассивное воздействие, т. е. наблюдение пользователем значений каких-либо параметров СУБД или системы баз данных, а также различных побочных эффектов и косвенных признаков с целью получения конфиденциальной информации на основе анализа собранных данных.

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

Физического;

Технологического;

Логического (процедурного);

Человеческого.

Характеристика физического измерения показывает, насколько эффективно обеспечена физическая защита элементов, образующих техническую основу информационной среды электронного бизнеса. Компьютеры, маршрутизаторы, линии связи должны быть физически недоступны для потенциальных носителей деструктивных воздействий. Экраны мониторов, электромагнитные излучения аппаратуры не должны быть источником конфиденциальной информации.

Характеристика технологического измерения показывает, насколько эффективно обеспечена программно-аппаратная реализация процедур, обеспечивающих требуемый уровень безопасности: аутентификация пользователей, разграничение доступа, обеспечение целостности информационной инфраструктуры и т. п. Н значительной степени средствам и методам, характерным для данного измерения безопасности баз данных, посвящен материал данного учебного пособия.

Характеристика логического (процедурного) измерения показывает, насколько адекватны логические основы заложенных в систему механизмов безопасности. Если неправильно определены блоки критически важной информации, то она становится уязвимой не из-за недостатков программно-аппаратного комплекса, а из-за ошибок проектирования системы.

Характеристика человеческого измерения показывает, насколько адекватно поведение людей, отвечающих за безопасность системы. Методики измерения этой характеристики должны быть выбраны из арсенала гуманитарных наук. В любой автоматизированной информационной системе есть люди, обладающие критически важной информацией и отвечающие за безопасность системы. Различные мотивы (алчность, неудовлетворенность чем-либо, тщеславие и т. п.) могут привести к добровольной передаче этой информации злоумышленнику либо к непринятию необходимых мер для эффективного противодействия деструктивному воздействию на систему.

Представленные четыре измерения в некотором смысле ортогональны друг другу. Меры, улучшающие характеристики некоторого измерения, не всегда приводят к повышению безопасности системы в целом. Характеристики различных измерений должны быть сбалансированы.

2.3. Угрозы, специфичные для систем управления базами данных

Существует несколько оснований для классификации угроз, специфичных для систем управления базами данных. Будем использовать упрощенную классификацию угроз по следующим основаниям: угрозы конфиденциальности информации, угрозы целостности информации и угрозы доступности.

Угрозы конфиденциальности информации.

К угрозам такого типа можно отнести:

1. Инъекция SQL. Во многих приложениях используется динамический SQL- формирование SQL-предложений кодом программы путем конкатенации строк и значений параметров. Зная структуру базы данных, злоумышленник может либо выполнить хранимую программу в запросе, либо закомментировать «легальные» фрагменты SQL-кода, внедрив, например, конструкцию UNION, запрос которой возвращает конфиденциальные данные. II последнее время даже появились специальные программы, автоматизирующие процесс реализации подобных угроз.

2. Логический вывод на основе функциональных зависимостей.

3. Логический вывод на основе ограничений целостности.

Для кортежей отношений в реляционной модели данных (РМД) можно задать ограничения целостности - логические условия, которым должны удовлетворять атрибуты кортежей.

4. Использование оператора UPDATE для получения конфиденциальной информации. В некоторых стандартах SQL пользователь, не обладая привилегией на выполнение оператора SELECT, мог выполнить оператор UPDATE со сколь угодно сложным логическим условием. Так как после выполнения оператора UPDATE сообщается, сколько строк он обработал, фактически пользователь мог узнать, существуют ли данные, удовлетворяющие этому условию.

Рассмотрим угрозы целостности информации, специфические для систем управления базами данных. Модификация данных в реляционных СУБД возможна с помощью SQL-операторов UPDATE, INSERT и DELETE. Потенциальная опасность возникает из-за того, что пользователь, обладающий соответствующими привилегиями, может модифицировать все записи в таблице. Ограничить множество записей, доступных для модификации, можно с помощью создания представлений с оператором CHECK, но этот (равно как и любой другой) требует предварительного осмысливания существа задачи и соответствующего проектирования схемы.

Специфичными для систем управления базами данных угрозами доступности являются:

1. Использование свойств первичных и внешних ключей. В первую очередь сюда относится свойство уникальности первичных ключей и наличие ссылочной целостности. В том случае, если используются натуральные, а не генерируемые системой значения первичных ключей, можно создать такую ситуацию, когда в таблицу невозможно будет вставить новые записи, так как там уже будут записи с такими же значениями первичных ключей. Если в базе данных поддерживается ссылочная целостность, можно организовать невозможность удаления родительских записей, умышленно создав подчиненные записи. Важной особенностью реализации ссылочной целостности является вопрос об индексировании внешнего ключа.

2. Блокировка записей при изменении. Заблокировав записи или всю таблицу, злоумышленник может на значительное время сделать ее недоступной для обновления.

3. Загрузка системы бессмысленной работой. Простейший
пример - выполнение запроса, содержащего декартово произведение двух больших отношений. В реляционных СУБД возможны реализации и других классических угроз, например атаки типа «троянский конь» - запуска пользователями программ, содержащих выполняющий опреде-иснные действия код, внедренный туда злоумышленником.

Практически все современные СУБД имеют встроенный процедурный язык программирования (PL/SQL, Transact SQL и т.п.) Программы на этом языке хранятся внутри базы данных и выполняются исполняющей подсистемой сервера баз данных. наличие и широкое использование производителями прикладного программного обеспечения механизма скрытия исходных текстов хранимых программ затрудняют его обнаружение. Также возможны многочисленные скрытые каналы, обусловленные семантикой данных и необходимостью обеспечения работы в условиях многопользовательского доступа.

На основании проведенного анализа можно сделать вывод, что в современных реализациях реляционных СУБД имеется значительное число уязвимостей, которые могут быть использованы для различных атак на информационные системы, построенные на их базе. Эта проблема отчасти может быть решена использованием специализированных программных средств анализа уязвимостей и защиты от угроз различных типов.

В финансовой сфере и госогранах требования к защите баз данных предъявляют регуляторы, а безопасность СУБД коммерческих компаний остается на совести владельцев бизнеса. Хотя на первый взгляд вопрос безопасности баз данных кажется достаточно понятным, универсального решения для защиты СУБД нет. Автоматизированные банковские системы АБС, CRM, ERP, системы документооборота, интернет-банкинг, системы дистанционного банковского обслуживания (ДБО) - после первой попытки разобраться в «зоопарке» различных систем в одной компании любой специалист задумывается о специализированном решении для защиты баз данных.

Базовые средства защиты баз данных

Первая линия безопасности баз данных должна исходить от IT-отдела компании и от администраторов СУБД в частности. Базовая защита БД - это настройка межсетевых экранов перед СУБД, чтобы заблокировать любые попытки доступа от сомнительных источников, настройка и поддержание в актуальном состоянии парольной политики и ролевой модели доступа. Это действенные механизмы, которым должно уделяться внимание. Следующий этап защиты информации в базах данных - аудит действий пользователей, прямая задача отдела информационной безопасности. Значимость аудита объясняется тем, что в промышленной системе сложно тонко настроить права доступа к данным, к тому же бывают и исключительные ситуации.

Например, сотруднику отдела “А” временно понадобился доступ к клиенту отдела “Б”. С большой вероятностью внесение изменений в матрицу доступа к данным не будет иметь обратного характера, что в конечном итоге приводит к наличию учетных записей с сильно расширенными привилегиями, за использованием которых стоит следить.

Штатный аудит баз данных

Для проведения такого мониторинга многие организации пользуются «штатным аудитом» – средствами защиты баз данных, входящими в состав коммерческих СУБД. Штатный режим защиты включает ведение журнала подключения к СУБД и выполнения запросов теми или иными пользователями. Если коротко, принцип работы штатного аудита – это включение и настройка триггеров и создание специфичных функций – процедур, которые будут срабатывать при доступе к чувствительной информации и вносить данные о подобном доступе (кто, когда, какой запрос делал) в специальную таблицу аудита. Этого бывает достаточно для выполнения ряда отраслевых требований регуляторов, но не принесет практически никакой пользы для решения внутренних задач информационной безопасности, таких как расследование инцидентов.

Ключевые недостатки штатного аудита как защиты баз данных:

Дополнительная нагрузка на серверы баз данных (10-40% в зависимости от полноты аудита).
Вовлечение администраторов баз данных в настройку аудита (невозможность контроля администраторов – основных привилегированных пользователей).
Отсутствие удобного интерфейса продукта и возможности централизованной настройки правил аудита (особенно актуально для крупных распределенных компаний, в задачи защиты которых входит целый перечень СУБД).
Невозможность контроля действий пользователей в приложениях с трехзвенной архитектурой (наличие WEB и SQL-сегмента, что сейчас используется повсеместно из соображений безопасности).

Автоматизированные системы защиты баз данных

Более эффективный подход – использование специализированных систем информационной безопасности в области защиты бд – решений классов DAM и DBF.

DAM (Database Activity Monitoring) – это решение независимого мониторинга действий пользователей в СУБД. Под независимостью здесь понимается отсутствие необходимости переконфигурации и донастройки самих СУБД. Системы такого класса могут ставиться пассивно, работая с копией трафика и не оказывая никакого влияния на бизнес-процессы, частью которых являются базы данных.

Такие системы позволяют разбирать трафик взаимодействия пользователей с базами данных, классифицировать SQL-запросы по принадлежности к определенных группам. Вести полный аудит SQL-запросов и ответов на них. Кроме того, решения обладают глубокой системой фильтрации, позволяющей из сотен миллионов запросов выявить потенциальные инциденты и сохранять полный архив действий пользователей, как для удовлетворения требований регуляторов, так и для задач ретроспективного анализа при расследовании инцидентов. Кроме того, специализированные системы DAM позволяют синхронизоваться с защищаемыми базами данных с целью:

Классификации – определение местонахождения критичной для компании информации. Опция позволяет, просканировав СУБД, увидеть названия таблиц и полей, в которых могут содержаться персональные данные клиентов. Это крайне важно для упрощения последующей настройки политик безопасности.
Проверки на уязвимости – соответствие конфигурации и настройки СУБД лучшим практикам.
Получение матрицы доступа к данным – задача решается для выявления расширенных привилегий доступа, неиспользуемым правам, и наличие так называемых «мертвых» учетных записей, которые могли остаться после увольнения сотрудника из компании.

Преимущество систем такого класса – гибкая система отчетности и интеграции с SIEM-системами большинства вендоров, для более глубокого корреляционного анализа выполняемых запросов.

DBF (Database Firewall) – это смежное по классу решение, которое также обладает возможностью «проактивной» защиты информации. Достигается это блокировкой нежелательных запросов. Для решения этой задачи уже недостаточно работы с копией трафика, а требуется установка компонентов системы защиты «в разрыв».

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

На российском рынке представлено решение класса DAM «Гарда БД» от компании "Гарда Технологии". Это программно-аппаратный комплекс, который проводит непрерывный мониторинг всех запросов к базам данных и веб-приложениям в реальном времени и хранит их в течение длительного срока. Система проводит сканирование и выявление уязвимостей СУБД, такие как незаблокированные учётные записи, простые пароли, неустановленные патчи. Реагирование на инциденты происходит мгновенно в виде оповещений на e-mail и в SIEM-систему.

Система защиты баз данных устанавливается пассивно, то есть не влияет на производительность сети компании. Интеллектуальная система хранения позволяет формировать архив запросов и ответов к базам данных за любой период времени для дальнейшего ретроспективного анализа и расследования инцидентов. Это первая система класса DAM, вошедшая в реестр отечественного ПО и установленная в ряде крупных российских банков.

В следующей статье мы более подробно рассмотрим задачи, которые часто стоят перед DAM-системами, расскажем, почему для DAM так важно умение работы с http/http’s трафиком и как обеспечить защиту от SQL инъекций.