132
Глава 5. СТАНДАРТЫ И СПЕЦИФИКАЦИИ ПО ОБЕСПЕЧЕНИЮ
БЕЗОПАСНОСТИ БАЗЫ ДАННЫХ
5.1. Архитектура и принцип функционирования подсистемы
безопасности базы данных
Системы управления базами данных, в особенности реляционные
СУБД, стали доминирующим инструментом хранения больших массивов
информации. Сколько-нибудь развитые информационные приложения
полагаются не на файловые
структуры операционных систем, а на
многопользовательские СУБД, выполненные в технологии клиент/сервер. В
связи с этим, обеспечение информационной безопасности СУБД, и в первую
очередь их серверных компонентов, приобретает решающее значение для
безопасности организации в целом. Как мы уже отметили, для СУБД важны
все
три
основных
аспекта
информационной
безопасности
-
конфиденциальность, целостность и доступность. Общая идея защиты баз
данных состоит в следовании рекомендациям, сформулированным для класса
безопасности C2 в «Критериях оценки надежных компьютерных систем». В
принципе некоторые СУБД предлагают дополнения, характерные для класса
B1, однако практическое применение подобных дополнений имеет смысл,
только если все компоненты информационной структуры организации
соответствуют категории безопасности B.
Достичь этого непросто и с
технической, и с финансовой точек зрения. Следует, кроме того, учитывать
два
обстоятельства.
Во-первых,
для
подавляющего
большинства
коммерческих организаций класс безопасности C2 достаточен. Во-вторых,
более защищенные версии отстают по содержательным возможностям от
обычных «собратьев», так что поборники секретности по сути обречены на
использование морально устаревших (хотя и тщательно проверенных)
продуктов со всеми вытекающими последствиями в плане сопровождения.
Идентификация и проверка подлинности пользователей.
133
Обычно в СУБД для идентификации и
проверки подлинности
пользователей
применяются
либо
соответствующие
механизмы
операционной системы, либо SQL-оператор CONNECT. Например, в случае
СУБД Oracle оператор CONNECT имеет следующий вид:
CONNECT пользователь[/пароль] [@база_данных].
Так или иначе, в момент начала сеанса работы с сервером баз данных,
пользователь идентифицируется своим именем, а средством аутентификации
служит пароль. Детали этого процесса определяются реализацией клиентской
части приложения.
Некоторые операционные системы, такие как UNIX, позволяют во
время
запуска
программы
менять
действующий
идентификатор
пользователя. Приложение, работающее с базой данных, как правило, имеет
привилегии,
значительно
превосходящие
привилегии
обычных
пользователей. Естественно, что при этом приложение предоставляет
тщательно
продуманный, строго фиксированный набор возможностей. Если
пользователь сумеет тем или иным способом завершить приложение, но
сохранить подключение к серверу баз данных, ему станут доступны по
существу любые действия с данными.
Управление доступом.
Для иллюстрации вопросов, связанных с
управлением доступом, будет использоваться СУБД INGRES.
Обычно в СУБД применяется произвольное
управление доступом,
когда владелец объекта передает права доступа к нему (чаще говорят -
привилегии) по своему усмотрению. Привилегии могут передаваться
субъектам (отдельным пользователям), группам, ролям или всем
пользователям.
Привилегии роли имеют приоритет над привилегиями пользователей и
групп. Иными словами, пользователю как субъекту не обязательно иметь
права
доступа к объектам, обрабатываемым приложениям с определенной
ролью. Отметим, что в СУБД Oracle под ролью понимается набор
134
привилегий. Такие роли служат средством структуризации привилегий и
облегчают их модификацию.
Совокупность всех пользователей именуется как PUBLIC. Придание
привилегий PUBLIC - удобный способ задать подразумеваемые права
доступа. Поручать администрирование различных баз данных разным людям
имеет смысл только тогда, когда эти базы независимы и по отношению к ним
не придется проводить согласованную политику выделения привилегий или
резервного копирования. В таком случае каждый из администраторов будет
знать ровно столько, сколько необходимо.
Можно провести аналогию между
пользователем INGRES и
администраторами баз данных с одной стороны, и суперпользователем
операционной системы (root в случае ОС UNIX) и служебными
пользователями (в ОС UNIX это могут быть bin, lp, uucp и т.д.) с другой
стороны. Введение служебных пользователей
позволяет администрировать
функциональные подсистемы, не получая привилегий суперпользователя.
Точно так же информацию, хранящуюся на сервере баз данных, можно
Do'stlaringiz bilan baham: 
