1. Получение конфиденциальной информации на основе логических выводов.
Возможны ситуации, когда пользователь, не имея прямого доступа к некоторой информации, может полностью или частично восстановить ее, строя логические умозаключения на основе той информации, которая ему доступна. Отправной точкой могут быть, к примеру, сообщения об ошибках. Предположим, пользователь пытается добавить в некоторую таблицу новую запись, а в ответ получает сообщение о нарушении ограничения целостности: новая строка содержит уже имеющееся в таблице значение ключевого поля. В результате пользователь узнает о том, что одна из записей данной таблицы содержит некоторое значение ключевого поля. При этом он не прибегает к операции чтения, которая может оказаться для него явно запрещенной.
2. Агрегирование данных.
Агрегирование - это метод получения новой информации путем комбинирования данных, которые были добыты легальным образом из различных таблиц. Агрегированная информация может оказаться более секретной, чем каждый из ее компонентов. Единственный способ противостоять агрегированию – тщательное проектирование БД и не менее тщательная разработка политики безопасности.
3. Покушение на доступность.
К СУБД применима специфическая форма DoS-атаки, когда злоумышленник запускает на выполнение транзакцию, которая захватывает и блокирует на долгое время большое число ресурсов. Другие транзакции уже не смогут воспользоваться теми же ресурсами и будут вынуждены ожидать их разблокирования. При этом растет вероятность появления «мертвых блокировок». Не все атаки подобного рода могут автоматически обнаруживаться средствами СУБД.
4. Проявление случайных и умышленных дефектов в БД.
Как было отмечено ранее, БД – это достаточно сложный объект. В ходе ее проектирования и реализации разработчики могут допускать ошибки, приводящие к появлению дефектов. Рассмотрим простой пример. Пусть имеется БД перевозки грузов. Для каждого перевозимого груза указывается его масса. Если разработчик БД не создаст ограничения целостности, согласно которому масса груза может быть больше либо равна нулю, у пользователей появится возможность регистрировать грузы с «отрицательными массами». Последствия подобных действий заранее не предсказуемы: они могут и не повлечь за собой особого вреда; однако некорректные данные часто приводят и к серьезным сбоям в работе АИС, что, в свою очередь, может представлять угрозу здоровью и даже жизни людей.
Любой, даже случайно допущенный, дефект является уязвимостью защиты. Злоумышленник, приложив определенные усилия, может использовать дефект с целью осуществления атаки. Неправильно спроектированная схема данных, ошибки в реализации ограничений целостности, триггеров, хранимых процедур и функций, - все это порождает дефекты и связано с угрозами нарушения безопасности информации.
Наибольшую опасность представляют дефекты, целенаправленно внедряемые в БД разработчиками. К числу таковых дефектов относятся программные закладки. Они могут встречаться в хранимых процедурах, функциях и триггерах. Идея использования программных закладок состоит в том, что они не описываются в документации на БД, и об их существовании известно только ограниченному кругу лиц (включая самого разработчика). Закладки реализуются, как правило, не в виде отдельных процедур, а в виде фрагментов кода, встраиваемого в полезные процедуры. Чтобы закладка не активизировалась каждый раз во время вызова процедуры, разработчик задает некое логическое условие запуска закладки: наступление определенного момента времени или события. Действия, выполняемые программными закладками, носят, как правило, деструктивный характер: фактически они реализуют алгоритм проведения заранее спланированной атаки.
Долгое время пользователи могут работать с БД (в том числе и с ее процедурами), не подозревая о существовании закладок. Однако в нужный момент злоумышленник активизирует закладку известным ему способом, и атака выполняется по сути дела автоматически.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.