Русская версия "индийской защиты", или Защита данных в СУБД Oracle
Константин Демченко,
технический директор ЗАО "Аладдин Р.Д."
konstantin@aladdin.ru
Александр Додохов,
менеджер проекта ЗАО "Аладдин Р.Д."
dodokhov@aladdin.ru
Алексей Сабанов,
коммерческий директор ЗАО "Аладдин Р.Д."
asabanov@aladdin.ru
— Знаешь, сейчас практически все новые версии Oracle
пишут индийские программисты.
— Да, жаль, что не наши…
Из разговора российских программистов
В наши дни многие традиционные меры обеспечения безопасности информации, в основном организационные, давно исчерпали себя. Развитие техники и технологий идет ускоренными темпами, вооружение злоумышленников становится все лучше, как технически, так и профессионально, и это заставляет создавать все более совершенные способы охраны конфиденциальных данных.
Но пока наши законодатели спорят о проектах законов о коммерческой тайне и электронной торговле, в общественных местах — в переходах метро и даже на автостоянках, не говоря уж об Интернете, продолжают продаваться компакт-диски с разнообразными базами данных (БД). Выбор необычайно широк: за 40-60 долл. вам предложат БД МГТС (актуализация — январь 2003 г.), Единой государственной регистрации предприятий (полная информация о предприятиях, зарегистрированных в России в 2003 г.), сведения о прописке в Москве и Московской области, а подороже, за 110 долл., можно купить БД ВЭД и т. д. Слегка "залежалый товар", например, немного устаревшие данные об абонентах МТС (по состоянию на ноябрь 2002 г.), идет всего за 40 "у. е".
Вряд ли любому честному гражданину будет приятно обнаружить свои персональные данные на приобретенном таким способом компакт-диске. Ведь такой диск может легко купить не только "любознательный товарищ", но и так называемые криминальные структуры. Однако самое страшное, что реальных механизмов предотвращения кражи информации и доказательства преступления для наказания злоумышленников до настоящего времени практически не существовало. По данным авторов, на момент написания статьи решение, реализующее защиту данных под управлением СУБД Oracle 9i с помощью электронных ключей еToken, не имеет аналогов на мировом рынке защиты информации.
Суть метода состоит в применении штатных механизмов инфраструктуры открытых ключей и организации доступа пользователей к информации по предъявлению цифровых сертификатов Х.509, поддерживаемых средствами Oracle Advanced Security, в двух уровнях: для аутентификации в корпоративной сети (например, под управлением Microsoft Windows Server 2000/2003) и для доступа к конфиденциальным данным, которые обрабатываются и хранятся на серверах Oracle. Оба сертификата хранятся в персональном идентификаторе в виде USB-ключа или смарт-карты eToken.
Этот метод позволяет значительно снизить риски от потерь, связанных с человеческим фактором, и однозначно персонифицировать действия пользователей информационной системы, работающих с СУБД Oracle 9i.
Основные вопросы
Почему кражи информации случаются в самых разных организациях, даже в силовых ведомствах? Каковы предпосылки утечки данных, и надо ли обладать обширными знаниями и умением взломщика, чтобы преодолеть существующую защиту? Существуют ли способы построения систем защиты информации (СЗИ), позволяющие свести к минимуму риски потери данных? Можно ли защитить корпоративные данные от собственного системного администратора?
Все эти вопросы, связанные с защитой конфиденциальных данных на уровне СУБД, следует рассматривать с разных позиций, учитывая не только архитектуру баз данных и встроенные средства защиты, но и конфигурацию сети предприятия, его систему защиты, а также особенности работы клиентских станций.
Уровни защиты доступа к данным
Типовая модель защиты доступа пользователя к корпоративным данным и приложениям включает в себя четыре элемента:
- организационные меры ограничения доступа к компьютеру, подключенному к корпоративной сети;
- ограничения доступа к корпоративной сети;
- защита доступа к СУБД;
- ограничения на использование прикладного ПО конкретным пользователем.
Поскольку организационные меры и механизмы ограничения доступа к корпоративной сети подробно описаны с точки зрения как методологии [1, 2], так и практической реализации, стоит подробнее остановиться на задачах защиты доступа к СУБД и ограничениях на использование прикладного ПО. Но сначала поговорим о том, какие условия "благоприятствуют" похищению информации.
Почему воруют информацию
Попробуем проанализировать возможные причины успешных попыток краж информации, хранящейся в корпоративных базах данных.
Причина первая и главная — отсутствие системного подхода к оценке угроз. К сожалению, в настоящее время лишь малая часть предприятий применяет на практике международный опыт и подробно описанный в работах Гостехкомиссии общий подход к оценке угроз [3], а также рекомендации по применению адекватных средств защиты информации.
В общем случае для корпоративных БД как объекта защиты от несанкционированного доступа угрозы принято классифицировать по источнику, деля их на внутренние и внешние. Источником внутренней угрозы могут быть легальные пользователи БД или внутренние хакеры, источником внешней — легальные пользователи корпоративной сети либо внешние хакеры.
Кражи информации из БД связаны, как правило, с неправомерными действиями пользователей сети предприятия, т. е. с реализацией внутренних угроз. По данным из разных источников, до 85% краж и компрометации информации совершают легальные пользователи информационной системы предприятия и, что особенно неприятно, администраторы СУБД или прикладной системы. На долю внутренних (т. е. зарегистрированных в корпоративной сети) хакеров, пытающихся получить несанкционированный доступ к информации, по разным оценкам, приходится соответственно до 15% угроз.
Внешние угрозы неправомерного доступа к корпоративным данным также подразделяются на два подкласса, из которых на долю внешних хакеров приходится до 20%, а на долю легальных пользователей корпоративной сети — до 80%.
Причина вторая — несостоятельность парольной защиты. Несмотря на огромное количество публикаций о том, что пароли не обеспечивают должную защиту данных и приложений, этот способ до сих пор наиболее широко распространен, прежде всего из-за своей нулевой стоимости. Достаточно подробно вопрос о несостоятельности парольной защиты рассмотрен, например, в работах [4, 5].
Самое неприятное, что такой подход зачастую применяется и в далеко не мелких организациях. А доступ к ресурсам системы нескольких разных пользователей под одной и той же учетной записью — весьма распространенная и прочно укоренившаяся практика. Например, если в организации работают пять системных администраторов, то все они могут иметь доступ по одному паролю. Хорошо иллюстрирует порочность такой организации доступа аналогия с ездой по улицам крупного города на автомобилях без номеров. Никакой сотрудник ГАИ не сможет четко идентифицировать автомобиль, превышающий дозволенную скорость, в потоке "анонимов", если все едут без номерных знаков.
Причина третья — не полностью задействованные встроенные в СУБД средства защиты информации и мониторинга действий пользователей, а также неоправданные надежды на квалификацию разработчиков прикладного ПО в части организации системы управления правами доступа. На ком реально лежит ответственность за применение/неприменение встроенных в СУБД средств защиты информации? Скорее всего, на разработчиках прикладного ПО, которые внедряют свои системы у заказчиков. Но парадокс заключается в том, что разработчики в подавляющем большинстве не имеют в своем штате специалиста по СЗИ и не знают о штатных возможностях организации защиты СУБД. По самым скромным оценкам, на российском рынке работает несколько тысяч прикладных систем и программных продуктов, базирующихся на использовании промышленных СУБД. При этом в подавляющем большинстве случаев считается, что все вопросы, связанные с безопасностью данных, выполняет сама СУБД*, а доступ в ИС происходит по паролю.
* Обычно промышленные СУБД класса DB2 и Oracle сертифицированы как минимум по классу защищенности С2.
Таким образом, из-за недостаточного внимания к вопросам безопасности со стороны разработчиков прикладного ПО механизмы защиты информации, реализованные собственно в СУБД, приобретают чрезвычайно большое значение. Более того, как говорилось выше, несколько человек могут иметь доступ в систему с максимальными (администраторскими) правами. Отследить действия конкретного лица (иначе говоря, персонифицировать эти действия) в таких условиях не представляется возможным. Даже если удается локализовать канал утечки, пользователь не подлежит никаким, хотя бы административным мерам наказания. Стандартный аргумент нарушителя — ссылка на то, что пароль у него подсмотрели и кто-то под его именем совершил неправомерные действия.
Наконец, последняя, но существенная причина — устойчивое ощущение безнаказанности у злоумышленника. Увы, практика введения строгих регламентов и административных мер без строжайшего документированного контроля не приводит к заметному снижению числа нарушений. Практически все пойманные за руку недобросовестные сотрудники признавались, что не совершили бы подобных действий, если бы знали, что эти действия будут отслежены и самое главное — персонифицированы. Поэтому только сочетание административных и технических мер, подкрепленных программными средствами контроля и мониторинга, позволяет добиться должного уровня защиты конфиденциальных данных.
Встроенные средства защиты
Если рассматривать средства обеспечения безопасности в части доступа к БД, хранения информации и передачи по сети, то сегодня явный лидер** рынка систем управления базами данных — СУБД Oracle. Она предоставляет разработчикам ПО и администраторам прикладных систем полный спектр средств и инструментов, необходимых для построения защищенных систем. Среди них стоит выделить следующие:
Virtual Private Database (VPD) — средства разграничения доступа к данным
на уровне строк (в версии 10g — и на уровне колонок) и возможность организации
работы пользователя только с виртуальной регламентированной частью данных, а
не с реальной базой данных;
Oracle Advanced Security — комплекс средств аутентификации и обеспечения
сетевой безопасности, включающий в себя поддержку защищенных протоколов передачи
данных, в том числе SSL;
Oracle Label Security (OLS) — средства, аналогичные VPD, но с возможностью
проверки уровня доступа пользователя;
Fine Grained Audit Control (FGAC) — инструмент подробного аудита.
** По данным ряда источников, в том числе IDC. — Прим. ред.
Штатные средства Oracle + еToken
Кардинально повысить безопасность работы приложений БД позволяет защита клиентского ПО СУБД Oracle 9i с помощью электронных ключей еToken. Существенно усилить защиту удалось благодаря применению нескольких технологических решений.
Прежде всего метод аутентификации пользователей по имени и паролю был заменен более надежной — двухфакторной аутентификацией с использованием цифровых сертификатов стандарта X.509. И хотя встроенные средства Oracle Advanced Security поддерживают аутентификацию по цифровым сертификатам, вопрос о хранении сертификатов и личных ключей остается открытым. Предлагаемые Oracle способы хранения сертификатов в виде файлов-контейнеров формата PKCS#12 или реестра ОС Windows имеют ряд существенных недостатков. Суть встроенных в Advanced Security возможностей иллюстрирует схема хранения сертификатов (рис. 1).
 |
Рис. 1. Схема хранения цифровых сертификатов Oracle в архитектуре Oracle Advanced Security с использованием eToken.
|
Файл-контейнер, например, может быть похищен злоумышленником, имеющим права на чтение соответствующего ключа реестра или файла-контейнера. В то же время работа с СУБД разрешена только пользователю, для которого сформирован соответствующий контейнер и, более того, он "привязан" к определенной рабочей станции (где находится файл-контейнер). Чтобы избежать этих "неприятностей", необходимо хранить цифровые сертификаты непосредственно в памяти электронного ключа eToken, а для выполнения криптографических операций с закрытым ключом использовать встроенный в него криптопроцессор с дополнительной PIN-авторизацией пользователя.
Очевидно, что, помимо повышения надежности, аутентификация с использованием eToken дает ряд преимуществ по сравнению с традиционным (логин/пароль) методом. Прежде всего электронный ключ дает возможность пользователю различных приложений не хранить "где попало" и не запоминать необходимые имена и пароли. Зная один PIN-код и выбрав сертификат из предложенного списка, можно, имея соответствующие права и привилегии, обращаться к конкретной БД, причем c любой рабочей станции.
Администратор безопасности получает при этом дополнительные удобства в виде
централизованного управления доступом и контроля работы системных администраторов.
Все эти возможности управления обеспечивает единый инструмент — служба каталогов
Oracle Internet Directory. Существующие приложения получают "в лице" службы
каталогов единую точку входа — своего рода портал архитектуры клиент-сервер.
При этом в большинстве случаев изменений в прикладном ПО не требуется.
Что нужно для защиты |
|
|
На сервере:
|
На рабочей станции-клиенте:
|
Архитектурные особенности
Предложенное решение базируется на использовании цифровых сертификатов стандарта X.509 и протокола Secure Sockets Layer (SSL), поддерживающего строгую двухфакторную аутентификацию пользователей СУБД Oracle, а также шифрование информации, передаваемой по сети между сервером БД и клиентской рабочей станцией (рис. 2). При этом задействованы лишь штатные настройки СУБД и клиента Oracle, описанные в документации по Oracle Advanced Security [6]. Установка на рабочей станции сервисов eToken дает возможность применять имеющиеся на ключе сертификаты для аутентификации в СУБД Oracle (cм. врезку "Процедура аутентификации в СУБД Oracle с использованием eToken").
 |
| Рис. 2. Архитектура предоставления доступа.
|
Процедура аутентификации в СУБД Oracle с использованием eToken |
|
|
Этап 1. Установление соединения клиент-сервер
|
Этап 2. Авторизация пользователя сетевыми службами Oracle в БД
|
Сертификаты и связанные с ними закрытые ключи хранятся в защищенной памяти
eToken (она доступна только встроенному в него криптопроцессору). Чтобы выполнить
криптографические операции с закрытым ключом, пользователь должен ввести PIN-код.
Такой подход позволяет на практике реализовать модель организации защищенного
доступа пользователя к данным (СУБД) с использованием цифровых сертификатов
Х.509, установленных в eToken, в двух уровнях. Легальные пользователи корпоративной
сети (например, под управлением контроллера домена Windows 2000/2003) могут
авторизоваться в сети (рис. 3) только после успешного завершения процесса аутентификации
по смарт-карте, включающего предъявление соответствующего сертификата (первый
уровень). На втором уровне защиты доступ авторизованных пользователей корпоративной
сети к защищенным данным СУБД возможен только при предъявлении соответствующего
сертификата Oracle.
 |
Рис. 3. Двухуровневая модель доступа к защищенным данным с помощью цифровых сертификатов Х.509.
|
***
Подведем итоги. Предложенный метод защиты данных существенно ограничивает возможности
кражи информации. А в случае совершения преступления он предоставляет обоснованные
свидетельства для применения наказания, поскольку владелец электронного ключа
и хранимых в нем сертификатов всегда известен.
Источники дополнительной информации
|