О дополнительных возможностях защиты данных в среде СУБД Oracle9i

Александр Додохов, менеджер проекта,
Алексей Сабанов, к. т. н., коммерческий директор,
Aladdin Software Security R.D.

Обеспечению конфиденциальности данных под управлением СУБД Oracle посвящено немало работ. С одной стороны, это объясняется распространенностью данной СУБД: по данным разных источников, Oracle используется в 60-80% государственных организаций России и не менее чем в 30-35% коммерческих. С другой стороны, широко известны факты краж и последующего коммерческого распространения баз данных ГАИ, ГТК, УВД, МРП, МГТС, МТС, которые штатно использовались в среде СУБД Oracle. Цель данной статьи — рассказать о технологиях, позволяющих не только надежно защитить данные, но и выявить покушавшегося на них злоумышленника.

Актуальность: зарубежные данные и российская действительность

Долгое время защита баз данных ассоциировалась с защитой локальной сети предприятия
от внешних угроз — атак хакеров, вирусов и т. п. Данные консалтинговых компаний,
появившиеся в последние годы, выявили другие, не менее важные направления защиты
информационных ресурсов компаний. Исследования убедительно показывают, что от
утечки информации, ошибок персонала и злонамеренных действий "всесильных" администраторов
баз данных не спасают ни межсетевые экраны, ни VPN, ни даже "навороченные" системы
обнаружения атак и анализа защищенности. Обратимся к данным о статистике угроз,
опубликованным в конце 2004 г. на известном российскому ИТ-сообществу сайте
http://www.CNews.ru (рис. 1).

Рис. 1. Статистика угроз. Источник: 2003 CSI/FBI Computer Crime and Security Survey (данные по 1000 компаний).

Результаты данного исследования справедливы для западного рынка, российской специфики они не учитывают. Тем не менее можно утверждать, что и в России есть все перечисленные угрозы, а проблема сохранности конфиденциальных данных стоит еще более остро. В докладе руководителя ГУСТМ МВД РФ Б. М. Мирошникова на Х Международном форуме "Технологии безопасности" в феврале 2005 г. отмечалось, что число фактов неправомерного доступа к информационным ресурсам государственных и коммерческих организаций в целях хищения данных и их последующего сбыта за 2004 г. удвоилось, причем это только видимая часть айсберга.

Проводимые компанией Ernst&Young исследования по проблемам внутренних угроз дают следующие цифры: около 20% сотрудников предприятий уверены, что конфиденциальная информация уходит "на сторону" по вине их коллег, при этом руководители большинства компаний практически бездействуют. В чем причины этого? Согласно данным Ernst&Young, такая ситуация связана прежде всего с тем, что подобные преступления имеют высокую латентность (т. е. о понесенных потерях в компании узнают по прошествии некоторого времени) и достаточно редко раскрываются. Эксперты называют следующие цифры, касающиеся их сокрытия: США — 80%, Великобритания — до 85%, Германия — 75%, Россия — более 90%. К тому же политика руководства "не выносить сор из избы" усугубляет ситуацию. Как отмечает в выводах Эдвин Беннет (Edwin Bennett), управляющий Technology and Security Risk Services компании Ernst&Young, во многих организациях даже не представляют себе, каким образом им причиняют ущерб и в каком объеме. И в то время как паникеры фокусируют внимание пользователей на внешних угрозах, аргументируя это некими оценками потерь, более серьезную опасность для организаций представляют неправомерные действия инсайдеров, халатность, недосмотр сотрудников. "Поскольку многие инсайдерские инциденты тщательно маскируются и не контролируются, организации часто оказываются не в курсе, что они подвергаются атаке изнутри", — утверждает г-н Беннет.

Среди других причин в исследовании Ernst&Young называется низкий интерес к разработке средств, ликвидирующих или уменьшающих риски, связанные с внутренними угрозами, и слабая популяризация таких решений (в результате чего о средствах и методах защиты от кражи информации легальными пользователями знают немногие), а также недостаточное предложение на рынке комплексных систем для борьбы с внутренними угрозами, особенно в отношении краж информации из баз данных.

Очень ярко характеризует положение дел тот факт, что, по данным Ernst&Young, почти 100% опрошенных подтвердили использование в корпоративных сетях антивирусного ПО, 71% назвали антиспамовые системы, но о защите от внутренних угроз не упомянул никто.

Российская действительность еще тревожнее. В опубликованном в феврале 2005
г. отчете компании Infowatch (http://www.infowatch.ru)
приводятся данные опроса представителей 387 государственных и коммерческих структур.
Вот основные выводы данного исследования:

• 62% респондентов считают, что действия инсайдеров — самая большая угроза для российских организаций;
• 98% признали нарушение конфиденциальности информации самой большой внутренней ИТ-угрозой;
• 99,4% допускают наличие незарегистрированных инцидентов внутренней ИБ;
• 87% считают технические средства эффективным способом защиты, однако всего 1% респондентов используют их, а 68% никаких действий не предпринимают;
• российские организации осознают опасность внутренних ИТ-угроз, но не знают, как с ней бороться: 58% не осведомлены о существующих технологических решениях;
• чем больше организация, тем выше ее озабоченность угрозой утечки конфиденциальной информации.

Рис. 2 иллюстрирует один из этих выводов: на нем приведены данные об оценке главных ИТ-угроз в компаниях, где число работников превышает 2500 человек. Видно, что риски, связанные с действиями внутренних злоумышленников, лидируют по сравнению с такими традиционными и "раскрученными" опасностями, как воздействие вредоносных программ и хакерских атак. Известно, что к инсайдерам относят в первую очередь нечестных, обиженных и уволенных сотрудников (тех, у кого случайно или намеренно осталась возможность доступа к конфиденциальным данным).

Рис. 2. Оценка угроз. Данные компании Infowatch, октябрь-декабрь 2004 г.

Действительно, в средних и крупных организациях гораздо труднее отследить действия инсайдеров традиционными средствами HR-менеджмента и службы физической безопасности, а цена реальных потерь от утечки информации возрастает пропорционально количеству сотрудников. В этой ситуации наиболее эффективным способом защиты информации становится комплексный подход, основанный на комбинации технических средств и организационных мер.

Один из способов технического решения задачи персонификации действий пользователей,
имеющих доступ к конфиденциальным данным, был описан в статье "Русская версия
"индийской защиты", или Защита данных в СУБД Oracle" ("BYTE/Россия",
№ 8'2004). Это решение, появившееся в начале 2004 г., реализует защиту данных
под управлением СУБД Oracle9i с помощью электронных ключей еToken. Успешное
его тестирование с различными прикладными системами, проведенное специалистами
компаний РНТ, "Борлас", ФОРС, КРОК, "Инфосистемы Джет", доказывает целесообразность
его промышленного применения. Однако, поскольку процесс принятия решений растянут
во времени, а развитие предложенного метода продолжается, сформулируем еще раз
постановку задачи и покажем, какие преимущества для пользователей и администраторов
безопасности в плане надежности и удобства организации защищенного доступа к
данным дает данный подход.

Суть проблемы

Попробуем кратко сформулировать основные причины несанкционированного доступа к данным и — поставленного в ряде случаев на промышленные рельсы — сбыта баз данных, содержащих персональные данные клиентов, партнеров или сотрудников и коммерческие тайны компаний. Итак, имеем следующие исходные данные:

1. многие не догадываются о том, что их базы данных крадут;
2. кража и причиненный ущерб обладают латентностью;
3. если факт кражи данных установлен, большая часть компаний замалчивает причиненный им ущерб. Одна из причин этого — отсутствие реальных механизмов доказательства совершения кражи конкретным пользователем;
4. технологии, позволяющие строго персонифицировать действия пользователей и разграничить их права, неизвестны большинству руководителей, заинтересованных в защите данных;
5. не слишком хорошо известны и возможности защиты данных от системных администраторов;
6. бюджеты на защиту данных, как правило, невелики, и это не позволяет решить проблему комплексно (введение штатных единиц, отвечающих за информационную безопасность, формирование и проведение в жизнь политик безопасности, обучение персонала, установка систем защиты и т. д.).

Рассмотрим способы решения задачи защиты данных даже в таких неблагоприятных условиях.

Общее решение

Естественным способом защиты конфиденциальной информации, хранящейся в таблицах БД, может показаться ее зашифрование с помощью достаточно стойкого криптоалгоритма. Это обеспечивает хранение информации в "нечитаемом" виде. Для получения "чистой" информации пользователи, имеющие санкционированный доступ к зашифрованным данным, указывают ключ и применяют алгоритм расшифрования. Конечно, тут возникает проблема хранения ключей шифрования — вспомним хотя бы о "пароле под ковриком мыши".

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

Чтобы техническими средствами снизить риски от внутренних угроз в БД, существуют следующие способы:

• надежная аутентификация пользователя (это позволит повысить степень персонализации доступа и не даст пользователю отказаться от совершенных действий);
• шифрование трафика между клиентской рабочей станцией и сервером БД (это предотвратит попытки кражи информации на сетевом уровне);
• криптографическое преобразование данных, которые необходимо защитить (устранит возможность физической кражи информации, например, путем просмотра или копирования файлов БД);
• хранение аутентификационной информации и ключей шифрования на персонализированном внешнем носителе, например, на смарт-карте или USB-ключе (снимает проблему "забытых паролей" и повышает персональную ответственность сотрудника);
• аудит критических (в плане безопасности) действий пользователей, желательно не средствами аудита БД. Сочетание аудита и точной персонализации — достаточно веский для потенциальных нарушителей аргумент в пользу отказа от противоправных действий.

Эффект от реализации подобного подхода будет ощутимым. Разработка и внедрение регламентов и политик безопасности, а также тренинги персонала по работе с конфиденциальными данными сделают результат еще более весомым.

Таким образом, для минимизации риска потерь от внутренних угроз необходим комплекс технических, нормативных и других защитных мер. Их разумное сочетание, соответствующее условиям функционирования организации, обеспечит эффективный отпор новым угрозам.

Решение, прозрачное для приложений

Сложность, а иногда и невозможность промышленной реализации предложенных выше
подходов нередко связана с объемами требующейся доработки в существующих информационных
системах. Предлагаемые компанией Aladdin (http://www.aladdin.ru)
решения для информационных систем на базе СУБД Oracle обеспечивают защиту таких
систем без их переделки. При этом полностью задействуются штатные механизмы
безопасности сервера и клиента Oracle. Самое интересное из предлагаемых решений
— строгая двухфакторная аутентификация в Oracle для архитектуры приложения клиент-сервер.
Рассмотрим это решение подробнее.

Не секрет, что из всего разнообразия методов аутентификации, предоставляемых СУБД Oracle (имя/пароль, RADIUS, Kerberos, SSL, SecureID), в 99% случаев приложения используют аутентификацию по имени пользователя и паролю, и объясняется это простотой данного метода. Однако его удобство и, что более важно, безопасность оставляют желать лучшего.

Наиболее надежным методом сегодня считается аутентификация по сертификату формата X.509, и Oracle9i его поддерживает. Сертификаты пользователей и закрытые ключи могут храниться либо в файлах стандартного формата PKCS#12, либо в реестре Windows на рабочих станциях, при этом они защищены паролем. Это порождает проблемы в плане безопасности — ключевые контейнеры можно скопировать и впоследствии взломать простым перебором паролей. Некоторые неудобства вызывает и привязка ключевого контейнера к конкретной рабочей станции.

Предлагаемое решение снимает обе названные проблемы: во-первых, сертификаты хранятся непосредственно в смарт-карте или USB-ключе eToken, секретный ключ находится в защищенной памяти и никогда ее не покидает; во-вторых, сертификаты "мобильны" — работать с приложениями Oracle можно с любой рабочей станции и от имени любого пользователя корпоративной сети. Схема решения показана на рис. 3.

Рис. 3. Принцип хранения сертификатов в решении компании Aladdin.

Все, что требуется для настройки на стороне клиента, — это указать, что ключевой контейнер помещен в хранилище сертификатов (Certificate Store) Microsoft. В момент запроса на соединение с БД служба eToken RTX позволяет сетевым драйверам Oracle "видеть" сертификаты, установленные на eToken (рис. 4). Аутентификация проходит в два этапа:

• запрос на выбор сертификата (в зависимости от выбранного сертификата пользователь будет работать с определенной БД, схемой и правами). Если сертификат единственный, он выбирается автоматически;
• запрос PIN-кода (рис. 5) смарт-карты или USB-ключа eToken для авторизации на операции с закрытым ключом.

Рис. 4. Выбор требуемого сертификата (соединение с Oracle установлено без указания имени и пароля).

Рис. 5. Запрос PIN-кода.

Приведем пример аутентификации по сертификату. Если соединение установлено успешно, пользователь получит результат, показанный на рис. 6. Что же происходит "за кадром" процесса аутентификации? Получив от клиентского приложения команду на соединение с БД (см. рис. 4, conn = connect), клиентское ПО Oracle (клиент) анализирует состояние соединения. По настройке сетевого алиаса (@orclssl) определяется хост сервера БД (сервер), порт и протокол соединения (в данном случае SSL). Клиент Oracle передает серверу запрос на соединение. Далее происходит взаимная аутентификация сервера и клиента, определяемая протоколом SSL.

Рис. 6. Соединение успешно установлено.

Когда от клиента требуется предъявить свой сертификат, служба eToken "подсказывает" ему, что сертификат следует брать из смарт-карты или USB-ключа (рис. 4). Чтобы подтвердить подлинность сервера, клиенту требуется личный ключ для расшифрования ответа сервера. Личный ключ находится в защищенной памяти смарт-карты или USB-ключа, и все операции с ним выполняет встроенный криптопроцессор. Для таких операций требуется дополнительная авторизация — запрашивается PIN-код (рис. 5). Когда между клиентом и сервером установлены доверительные отношения, сервер проверяет наличие отличительного имени пользователя, для которого издан сертификат клиента, в LDAP-каталоге — Oracle Internet Directory. Если таковой найден, дополнительно определяется экземпляр БД, схема и набор прав для клиента. После этого сервер создает сессию пользователя с указанными параметрами (рис. 6). Сетевой обмен между клиентом и сервером происходит по соединению, защищенному выбранным криптоалгоритмом.

Что получает заказчик, настроивший сервер БД и клиентские рабочие станции,
установивший сертификаты пользователей на eToken? Он получает надежную аутентификацию,
шифрованный трафик между рабочими станциями и сервером, а самое главное — персонализацию
доступа в БД. При этом все приложения, взаимодействующие с Oracle — от DOS-консоли
до сложных ERP систем, — работают с новым методом аутентификации без переделок
и доработок.