Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Базы данных. Лекции по курсу. В 4 частях. Ч.4. Учебное пособие
.pdf
3. ПОЛИТИКА БЕЗОПАСНОСТИ
В целом под политикой безопасности понимается совокупность
норм и правил, регламентирующих процесс обработки информации, выполнение которых обеспечивает защиту от определенного множества
угроз и составляет необходимое (а иногда и достаточное) условие безопасности системы.
Формальное выражение политики безопасности называют моделью
безопасности. В целом защита базы данных – это комплекс мер
обеспечению защищенности базы данных от любых угроз и опасностей
с помощью различных компьютерных и некомпьютерных средств.
При построении системы защиты базы данных следует руководство-
ваться аксиомой: полное устранение всех потенциальных угроз инфор-
мационной безопасности баз данных принципиально невозможно.
Реальная задача состоит в снижении вероятности реализации потенциальных угроз до
емлемость уровня угроз может определяться:
областью применения;
выделенным бюджетом;
положениями действующего законодательства.
При этом, как правило, не удается построить дерево угроз со строгой
иерархией.
приемлемого для конкретной системы уровня. При-
по
3.1. ТРИ ЗАДАЧИ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ
БАЗ ДАННЫХ
Обеспечение информационной безопасности баз данных во многом
аналогично обеспечению информационной безопасности
формационных системах и сводится к решению трех задач (см. рисунок):
11
в других ин-
обеспечение конфиденциальности: предоставлено пользовате-
лям доступа только к тем данным, для которых пользователь имеет явное или неявное разрешение на доступ;
обеспечение целостности: защита от преднамеренного или непреднамеренного изменения информации или процессов ее обработки;
обеспечение доступности: возможность авторизованным в си-
стеме пользователям доступа к информации
в соответствии с принятой
технологией (например, 24 часа в сутки, 7 дней в неделю).
Информационная безопасность баз данных
Обеспечение
конфиденциальности БД
Задачи информационной безопасности баз данных
Обеспечение целостности БДОбеспечение доступности
БД
Задача обеспечения конфиденциальности (первая задача) предусматривает комплекс мер по предотвращению несанкционированного
доступа к конфиденциальной информации. Ниже перечислены угрозы
конфиденциальности информации, специфичные для баз данных.
1. Инъекции SQL
Во многих приложениях используется динамический SQL, когда
формирование SQL-предложений в программе выполняется путем конкатенации строк и значений параметров. Зная структуру базы данных,
злоумышленник может
либо выполнить хранимую программу в запросе, либо закомментировать «легальные» фрагменты SQL-кода, внедрив, например, конструкцию UNION, запрос которой возвращает конфиденциальные данные. В последнее время даже появились специальные программы, автоматизирующие процесс реализации подобных
угроз.
2. Логический вывод на основе функциональных зависимостей
Пусть дана схема отношения R(A
, A2, … An). В ней могут иметь место
1
функциональные зависимости X Y. Вот пример функциональной
12
зависимости для схемы отношения (фамилия, имя, отчество, должность,
зарплата): если должность = менеджер, то зарплата = 1200.
При наличии сведений о функциональных зависимостях злоумышленник может вывести конфиденциальную информацию, имея доступ
только к части отношений.
3. Логический вывод на основе ограничений целостности
Для кортежей отношений в реляционной модели данных могут быть
заданы ограничения целостности –
логические условия, которым
должны удовлетворять атрибуты кортежей (некоторый предикат). Выполняя многократные изменения данных и анализируя реакцию системы, злоумышленник может получить те сведения, к которым у него
отсутствует непосредственный доступ. К этому виду угроз конфиденциальности относится также анализ значений первичных/внешних
ключей.
4. Использование оператора UPDATE для получения
конфиденциальной информации
В некоторых стандартах SQL-пользователь, не обладая привилегией
на выполнение оператора SELECT, может выполнить оператор UPDATE
со сколь угодно сложным логическим условием. Поскольку после выполнения оператора UPDATE сообщается, сколько строк он обработал,
пользователь может узнать, существуют ли данные, удовлетворяющие
этому условию.
Задача обеспечения целостности (вторая задача) предусматривает
комплекс мер по предотвращению
непреднамеренного или преднамеренного изменения или уничтожения информации, используемой Информационной системой. Это может быть следствием:
неблагоприятного стечения обстоятельств и состояния внешней
среды (стихийные бедствия, пожары и т. п.);
неадекватных действий пользователей: ошибок при вводе дан-
ных, ошибок операторов;
проблем, возникающих при многопользовательской обработке
данных.
Потенциальная опасность
может возникнуть и из-за того, что поль-
зователь, обладающий привилегиями на выполнение SQL-операторов
UPDATE, INSERT, DELETE, может модифицировать все записи
13
в таблице. Ограничить множество записей, доступных для модификации, можно с помощью создания представлений с оператором CHECK,
но это требует предварительного осмысливания существа задачи и соответствующего проектирования схемы.
Третья задача (обеспечение доступности) предусматривает систему
мер по поддержке всем легитимным пользователям доступа к ресурсам
системы в соответствии с принятым регламентом (например
, круглосуточно). Причиной отказа в доступе (и это касается не только баз данных)
может быть:
перегрузка системы, вызванная потоком «информационного
шума» (спам, искусственно формируемый поток бессмысленных запросов);
перегрузка системы, вызванная объективными причинами (резкое
увеличение потока запросов в связи с некоторыми событиями); например, после известных событий в
Нью-Йорке 11 сентября 2001 года все
новостные ресурсы были заблокированы огромным числом запросов;
действия, направленные на остановку критически важных процес-
сов (например, компонент сервера баз данных, прослушивающий процесс).
Ниже перечислены угрозы доступности информации, специфичные
для баз данных.
1. Использование свойств первичных и внешних ключей
Если используются натуральные, а не генерируемые
системой значения первичных ключей, можно создать такую ситуацию, когда в таблицу невозможно будет вставить новые записи, поскольку там уже
будут записи с такими же значениями первичных ключей. Если в базе
данных поддерживается ссылочная целостность, можно организовать
невозможность удаления родительских записей, умышленно создав
подчиненные записи. Если внешний ключ не проиндексирован
, то при
обновлении связанных записей, например в Oracle, возможна организация взаимной блокировки (dead-lock), что приведет к сбою в транзакции.
2. Блокировка записей при изменении
Заблокировав записи или всю таблицу, злоумышленник может на
значительное время сделать ее недоступной для обновления.
14
3. Загрузка системы бессмысленной работой
Простейший пример – выполнение запроса, содержащего декартово
произведение двух больших отношений. Мощность декартова произведения двух отношений мощности n
и n2 равна их произведению: n1*n2.
1
При вычислении запроса вида
select * from tab1, tab1 order by 1,
где мощность отношения tab1 равна 10 000, мощность результирующего отношения будет 10 000
2
= 100 000 000.
Вычисление соединения (особенно, если указать в виде подсказки
оптимизатору способ соединения, требующий значительных затрат процессорного времени, например, сортировку слиянием и сортировку результирующего отношения) потребует значительных ресурсов системы.
3.2. УГРОЗЫ БЕЗОПАСНОСТИ БАЗ ДАННЫХ
Выделяют две группы угроз – внешние и внутренние.
Внешние дестабилизирующие источники, создающие угрозы функ-
ционированию баз
данных и СУБД:
умышленные, деструктивные действия лиц с целью искажения,
уничтожения или хищения программ, данных и документов системы,
причиной которых являются нарушения информационной безопасности
защищаемого объекта;
искажения в каналах передачи информации, поступающей от
внешних источников, циркулирующих в системе, и передаваемой потребителям;
сбои и отказы в аппаратуре
вычислительных средств;
вирусы и иные деструктивные программные элементы, распро-
страняемые с использованием систем телекоммуникаций;
изменения состава и конфигурации комплекса взаимодействую-
щей аппаратуры системы за пределы, проверенные при тестировании
или сертификации системы.
Внутренние источники угроз баз данных и СУБД:
системные ошибки при постановке целей и задач проектирования
автоматизированных информационных
систем и их компонентов, допущенные при формулировке требований к функциям и характеристикам
средств обеспечения безопасности системы;
15
ошибки при определении условий и параметров функционирова-
ния внешней среды, в которой предстоит использовать информационную систему, и в частности программно-аппаратные средства защиты
данных;
ошибки проектирования при разработке и реализации алгоритмов
обеспечения безопасности аппаратуры, программных средств и баз данных;
ошибки и несанкционированные действия пользователей, адми-
нистративного
и обслуживающего персонала в процессе эксплуатации
системы;
недостаточная эффективность используемых методов и средств
обеспечения информационной безопасности в штатных или особых
условиях эксплуатации системы.
В настоящее время отсутствует общепринятая методология разработки защищенных Информационных систем, можно определить лишь
Принципы построения защищенных систем баз данных:
экономическая оправданность механизма защиты – предписывает использование простейшего из всевозможных вариантов, обеспечивающих достижение желаемой цели;
принцип открытого проектирования – использование алгорит-
мов, основанных на открытых стандартах, отказ от использования «секретных» алгоритмов;
принцип распределения полномочий – для критически важных
приложений использование многокомпонентных схем доступа (аналог
двух ключей от банковского сейфа);
принцип минимально возможных привилегий
для пользователей
и администраторов – пользователь, успешно прошедший аутентификацию в Oracle, ничего не может делать до тех пор, пока для него не будет
определен перечень полномочий (не может даже оператор Connect);
принцип управляемости – поскольку внештатные ситуации (ВС)
неизбежны, должны быть предусмотрены процедуры, минимизирующие
ущерб при ВС, разработаны документы, регламентирующие действия
участников ВС, регулярное проведение инструктажей и тренингов;
принцип психологической приемлемости работы средств за-
щиты – не должно быть чрезмерного усложнения средств защиты, при-
менение механизма защиты должно выполняться автоматически.
16
3.3. АТАКИ, СПЕЦИФИЧНЫЕ ДЛЯ БАЗ ДАННЫХ
3.3.1. ПОДБОР ПАРОЛЕЙ КАК МЕТОД РЕАЛИЗАЦИИ
НЕСАНКЦИОНИРОВАННОГО ДОСТУПА
Технология аутентификации с использованием паролей широко
используется с давних времен. Естественно ожидать, что технология
подбора паролей также находится на достаточно высоком уровне развития. Ниже приведены некоторые методы подбора паролей пользователей.
1. Тотальный перебор. В этом случае злоумышленник последовательно опробует все возможные варианты пароля. Для паролей длиннее
шести символов
метод может быть признан неэффективным.
2. Тотальный перебор, оптимизированный по статистике встре-
чаемости символов. Разные символы встречаются в паролях с разной
вероятностью. Согласно исследованиям, статистика встречаемости символов в алфавите паролей близка к статистике встречаемости символов
в естественном языке. Для подбора паролей по этому методу написано
множество программ, ориентированных на взлом
ОС и СУБД.
3. Тотальный перебор, оптимизированный с помощью словарей.
В большинстве случаев пароли пользователей – слова английского или
русского языка. Пользователю гораздо легче запомнить осмысленное
слово, чем бессмысленную последовательность символов, поэтому
пользователи предпочитают применять в качестве паролей осмысленные слова. При этом количество возможных вариантов пароля резко сокращается. Словарь
Ожегова содержит около 60 000 слов, объем сло-
варя среднестатистического пользователя заметно меньше.
Обычно данный метод используется в комбинации с предыдущим.
4. Подбор пароля с использованием знаний о пользователе. Человек
склонен использовать пароли, которые легко запоминаются: свое имя,
фамилию, дату рождения, имена детей, любимых (в том числе принятые
в узком кругу),
номера телефонов и автомобилей и пр. Некоторая категория мужчин склонна использовать в качестве пароля ненормативную
лексику, а определенная категория женщин часто использует уменьшительно-ласкательные имена домашних животных. В этом случае, если
злоумышленник хорошо изучил пользователя, ему, как правило, достаточно выполнить меньше сотни опробований.
17
3.3.2. НЕЦЕЛЕВОЕ РАСХОДОВАНИЕ
ВЫЧИСЛИТЕЛЬНЫХ РЕСУРСОВ СЕРВЕРА
Если пользователю предоставлена возможность создавать процедуры и их выполнять, то может возникнуть проблема нарушения доступности в связи с нецелевым расходованием ресурсов.
1. Нецелевое использование процессора
Ниже приведен простой пример – загрузка процессора бесконечными (и бессмысленными) вычислениями.
SQL> connect u1/u1psw
Соединено.
SQL> CREATE OR REPLACE PROCEDURE greedy_c IS
2 i number;
3 BEGIN
4 LOOP
5 i := 1;
6 EXIT WHEN i > 2;
7 END LOOP;
8 END;
9 /
Процедура создана.
Ясно, что запуск процедуры приведет к «замиранию всего
живого»
в системе. Как с этим бороться? Эффект от подобной атаки может быть
уменьшен назначением пользователю профиля, ограничивающего максимальное выделяемое время центрального процессора.
Пример выполнения администратором ограничения профиля пользователя по использованию времени центрального процессора для сеанса, делающего невозможным запуск процедуры greedy_c.
SQL> CREATE PROFILE beat_greedy LIMIT
2 PRIVATE_SGA 10K
3 CPU_PER_SESSION 3000;
Профиль создан.
18
SQL> ALTER USER u1 PROFILE beat_greedy;
Пользователь изменен.
SQL> connect u1/u1psw
Соединено.
SQL> exec greedy_c
BEGIN
greedy_c;
END;
*
ошибка в строке 1:
ORA-02392: превышен предел сеанса на использование CPU, вы в про-
цессе выхода из системы
2. Нецелевое расходование памяти сервера баз данных
Еще одним вариантом на заданную тему является процедура, нацеленная на расходование памяти сервера баз данных.
Пример деструктивного использования механизма рекурсии для
нецелевого расходования ресурса памяти сервера баз данных.
CREATE OR REPLACE PROCEDURE greedy_m IS
abc char (1000) := ‘аЬс’ ;
BEGIN
greedy m;
END;
/
Технология борьбы с последствиями запуска подобной процедуры
та же: назначение пользователю профиля, ограничивающего максимально выделяемую память. Приведенный ниже пример иллюстрирует
ситуацию, когда пользователь, запустивший «жадную» процедуру, принудительно выводится из системы.
SQL> exec greedy_m;
BEGIN greedy_m; END;
19
*
ошибка в строке 1:
ORA-04030: выход за пределы памяти процесса при попытке выделить
8204 байт.
Бороться с процедурами, расходующими ресурсы системы нецелевым образом, можно и принудительным завершением процессов-вредителей. Ниже приведен пример принудительного завершения выявленного по идентификатору пользователя процесса.
SQL> select sid, serial# from v$session where username = ‘u1’;
SID SERIAL
-----------------------
149 104
SQL> alter system kill session ‘149,104';
Процесс завершен.
3. Нецелевое расходование внешней памяти
Ниже приведен пример пользовательской процедуры, осуществляющей деструктивную функцию нецелевого расходования внешней памяти с элементами маскировки. По завершении выполнения процедуры
ресурсы внешней памяти будут освобождаться в целях маскировки действий по загрузке сервера нецелевыми операциями с дисковой памятью.
SQL> CREATE TABLE Tab1 (At1 raw(2000));
Таблица создана.
SQL> CREATE OR REPLACE PROCEDURE greedy_dm IS
2 AtX raw (2000);
3 BEGIN
4 for i in 1,,100000 loop
5 AtX := DBMS_CRYPTO.Randombytes(2000);
6 insert into Tab1 values(AtX);
7 end loop;
8 ROLLBACK;
20
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]