Введение в дисциплину «Безопасность систем баз данных». Теоретические основы построения реляционных баз данных. Верификация баз данных и проведение аудита в СБД. Распределенные базы данных, страница 31

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

5. Модификация запросов клиентских приложений.

Клиентские программные приложения «общаются» с сервером СУБД, отправляя ему SQL-запросы для выполнения. Обычно предполагается, что набор запросов, оправляемых каким-либо одним приложением, встроен в программный код этого приложения, и поэтому ограничен, строго фиксирован и практически не зависит от воли конечного пользователя. Максимум, что разрешается конечному пользователю, - это вводить некоторые параметры заранее запрограммированного запроса (например, ключ поиска). Однако, пользуясь ошибками разработчиков приложения, пользователь-злоумышленник способен модифицировать отправляемый с клиента на сервер SQL-запрос и с его помощью выполнить некоторый набор непредусмотренных (и потому несанкционированных) действий. Последствия SQL-инъекций трудно предсказуемы: они могут не дать злоумышленнику полезных результатов, если в СУБД корректно работают механизмы защиты; в других случаях SQL-инъекции приводят к реализации несанкционированного доступа, похищению и уничтожению важной информации и даже к полному захвату сервера: некоторые системные хранимые процедуры открывают пользователям доступ к ресурсам и сервисам операционной системы через СУБД.

4.2. Меры защиты БД и СУБД

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

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

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

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

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

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