ЗАЩИТА КОММУНИКАЦИЙ МЕЖДУ СЕРВЕРОМ И КЛИЕНТАМИ

ЗАЩИТА КОММУНИКАЦИЙ МЕЖДУ СЕРВЕРОМ И КЛИЕНТАМИ
Шангытбаева Г.А.
Казахский национальный технический университет имени К.И.Сатпаева,
г. Алматы, Казахстан
gul_janet@mail.ru
В статье рассматриваются системы управления базами данных, особенности
реляционных СУБД и проблемы защиты коммуникаций между сервером и клиентами,
обеспечение информационной безопасности баз данных в сетях.
Ключевые слова: базы данных, системы управления базами данных, клиент,
сервер, информационная безопасность.
Системы управления базами данных, в особенности реляционные СУБД, стали
доминирующим инструментом хранения больших массивов информации. Скольконибудь развитые информационные приложения полагаются не на файловые структуры
операционных систем, а на многопользовательские СУБД, выполненные в технологии
клиент/сервер. В этой связи обеспечение информационной безопасности СУБД, и в
первую очередь их серверных компонентов, приобретает решающее значение для
безопасности организации в целом.
Обычно в СУБД для идентификации и проверки подлинности пользователей
применяются либо соответствующие механизмы операционной системы, либо SQLоператор CONNECT. Например, в случае СУБД Oracle оператор CONNECT имеет
следующий вид:
CONNECT пользователь[/пароль] [@база_данных];
Так или иначе, в момент начала сеанса работы с сервером баз данных,
пользователь идентифицируется своим именем, а средством аутентификации служит
пароль. Детали этого процесса определяются реализацией клиентской части
приложения.
Обратим внимание на следующее обстоятельство. Некоторые операционные системы,
такие как UNIX, позволяют во время запуска программы менять действующий
идентификатор пользователя. Приложение, работающее с базой данных, как правило,
имеет привилегии, значительно превосходящие привилегии обычных пользователей.
Естественно, что при этом приложение предоставляет тщательно продуманный, строго
фиксированный набор возможностей. Если пользователь сумеет тем или иным
способом завершить приложение, но сохранить подключение к серверу баз данных, ему
станут доступны по существу любые действия с данными.
Обычно в СУБД применяется произвольное управление доступом, когда
владелец объекта передает права доступа к нему (чаще говорят - привилегии) по своему
усмотрению. Привилегии могут передаваться субъектам (отдельным пользователям),
группам, ролям или всем пользователям.
Группа - это именованная совокупность пользователей. Объединение субъектов
в группы облегчает администрирование баз данных и, как правило, строится на основе
формальной или фактической структуры организации. Каждый пользователь может
входить в несколько групп. Когда пользователь тем или иным способом инициирует
сеанс работы с базой данных, он может указать, от имени какой из своих групп он
выступает. Кроме того, для пользователя обычно определяют подразумеваемую группу.
Роль - это еще один возможный именованный носитель привилегий. С ролью не
ассоциируют перечень допустимых пользователей - вместо этого роли защищают
паролями. В момент начала сеанса с базой данных можно специфицировать
используемую роль (обычно с помощью флагов или эквивалентного механизма) и ее
пароль, если таковой имеется.
Привилегии роли имеют приоритет над привилегиями пользователей и групп.
Иными словами, пользователю как субъекту не обязательно иметь права доступа к
объектам, обрабатываемым приложениям с определенной ролью.
Отметим, что в СУБД Oracle под ролью понимается набор привилегий. Такие
роли служат средством структуризации привилегий и облегчают их модификацию.
Совокупность всех пользователей именуется как PUBLIC. Придание привилегий
PUBLIC - удобный способ задать подразумеваемые права доступа.
Пользователей СУБД можно разбить на три категории:

администратор сервера баз данных. Он ведает установкой,
конфигурированием сервера, регистрацией пользователей, групп, ролей и т.п.
Администратор сервера имеет имя ingres. Прямо или косвенно он обладает всеми
привилегиями, которые имеют или могут иметь другие пользователи.

администраторы базы данных. К этой категории относится любой
пользователь, создавший базу данных, и, следовательно, являющийся ее владельцем.
Он может предоставлять другим пользователям доступ к базе и к содержащимся в ней
объектам. Администратор базы отвечает за ее сохранение и восстановление. В
принципе в организации может быть много администраторов баз данных. Чтобы
пользователь мог создать базу и стать ее администратором, он должен получить
(вероятно, от администратора сервера) привилегию creatdb.

прочие (конечные) пользователи. Они оперируют данными, хранящимися
в базах, в рамках выделенных им привилегий.
Для СУБД важны все три основных аспекта информационной безопасности конфиденциальность, целостность и доступность. Общая идея защиты баз данных
состоит в следовании рекомендациям, сформулированным для класса безопасности C2
в "Критериях оценки надежных компьютерных систем". В принципе некоторые СУБД
предлагают дополнения, характерные для класса B1, однако практическое применение
подобных дополнений имеет смысл, только если все компоненты информационной
структуры организации соответствуют категории безопасности B. Достичь этого
непросто и с технической, и с финансовой точек зрения. Следует, кроме того,
учитывать два обстоятельства. Во-первых, для подавляющего большинства
коммерческих организаций класс безопасности C2 достаточен. Во-вторых, более
защищенные версии отстают по содержательным возможностям от обычных
"собратьев", так что поборники секретности по сути обречены на использование
морально устаревших (хотя и тщательно проверенных) продуктов со всеми
вытекающими
последствиями
в
плане
сопровождения.
Для иллюстрации излагаемых понятий и средств будут использоваться СУБД INGRES,
Informix и Oracle.
Проблема защиты коммуникация между сервером и клиентами не является
специфичной для СУБД, она присуща всем распределенным системам. Вполне
естественно, что и решения здесь ищутся общие, такие, например, как в
распределенной вычислительной среде (Distributed Computing Environment, DCE)
концерна OSF. Разработчикам СУБД остается "погрузить" свои программные продукты
в эту среду, что и сделала компания Informix, реализовав Informix- DCE/Net.
Informix-DCE/Net открывает доступ к сервисам DCE для всех инструментальных
средств Informix, а также любых приложений или инструментальных комплексов от
независимых поставщиков, которые используют интерфейс ODBC.
Ключевым компонентом в реализации взаимодействий клиент-сервер в среде
DCE является сервис безопасности. Основные функции, предоставляемые этим
сервисом, - аутентификация, реализуемая средствами Kerberos, авторизация (проверка
полномочий) и шифрование.
Informix-DCE/Net использует все средства обеспечения безопасности,
имеющиеся в DCE. Например, для каждого приложения клиент-сервер администратор
может задать один из пяти уровней защиты:

Защита пересылаемых данных только при установлении соединения
клиента с сервером.

Защита данных только на начальном этапе выполнения удаленного
вызова процедуры, когда сервер впервые получает запрос.

Подтверждение подлинности источника данных. Проверяется, что все
поступающие на сервер данные получены от определенного клиента.

Подтверждение подлинности источника и целостности данных.
Проверяется, что отправленные данные не были изменены.

Подтверждение
подлинности
источника,
целостности
и
конфиденциальности данных.
Выполняются проверки, предусмотренные на предыдущем уровне и
осуществляется шифрование всех пересылаемых данных.
Сервис аутентификации DCE, поддерживаемый Informix-DCE/Net, существенно
улучшает характеристики безопасности распределенной среды, упрощая в то же время
деятельность как пользователей, так и администраторов. Достаточно иметь единое
входное имя и пароль для DCE, чтобы обращаться к любой погруженной в эту среду
базе
данных.
При
запуске
приложения
Informix-DCE/Net
запрашивает
аутентификационную информацию пользователя у DCE, и подключает его к требуемой
базе.
Наличие единой точки администрирования входных имен и прав доступа к
базам данных и приложениям способствует упорядочению общей ситуации с
безопасностью. Например, если уничтожается входное имя DCE, то администратор
может быть уверен, что данный пользователь уже не сможет получить доступ ни к
одному из системных ресурсов.
Конфигурация, к которой имеет доступ хотя бы один программист, не может
считаться безопасной. Поэтому обеспечение информационной безопасности баз данных
- дело весьма сложное во многом в силу самой природы реляционных СУБД.
Помимо систематического применения всего арсенала средств, описанных в настоящей
работе, необходимо использование административных и процедурных мер. Только
тогда можно рассчитывать на успех в деле обеспечению информационной
безопасности современных серверов баз данных.
Литература
1.
Ладыженский Г.М. Системы управления базами данных - коротко о
главном. - Jet Infosystems, 1995.
2.
Ладыженский Г.М. Тиражирование данных в СУБД INGRES. - Jet
Infosystems, 1994.
3.
Polk T.W., Bassham L.E. Security Issues in the Database Language SQL. NIST Special Publication 800-8.
4.
G. Chung. Informix-DCE/NET Technical White Paper. - Informix Systems
Journal, Vol. 1, Number 3, July-August 1995.
Регистрационная карта
Ф.И.О. (полностью)
Ученая степень и ученое звание
Место работы и должность
Мобильный и контактный телефоны
Электронный адрес
Направление (секция)
Тема доклада
Он-лайн или заочное участие
Шангытбаева Гульмира Асаугаликызы
Казахский национальный технический
университет имени К.И.Сатпаева, докторант
PhD
87014678204
gul_janet@mail.ru
Секция 4. Физико-математические науки
Защита коммуникаций между сервером и
клиентами
заочное участие