V Защита информации в Oracle

ДЕ20: Доступ к данным в Oracle

Реализация контроля доступа к данным в Oracle

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

Защиту данных под управлением СУБД Oracle 9i с помощью электронных ключей еToken, не имеет аналогов на мировом рынке защиты информации.

Суть метода состоит в применении штатных механизмов инфраструктуры открытых ключей и организации доступа пользователей к информации по предъявлению цифровых сертификатов Х.509, поддерживаемых средствами Oracle Advanced Security, в двух уровнях: для аутентификации в корпоративной сети (например, под управлением Microsoft Windows Server 2000/2003) и для доступа к конфиденциальным данным, которые обрабатываются и хранятся на серверах Oracle. Оба сертификата хранятся в персональном идентификаторе в виде USB-ключа или смарт-карты eToken.

Этот метод позволяет значительно снизить риски от потерь, связанных с человеческим фактором, и однозначно персонифицировать действия пользователей информационной системы, работающих с СУБД Oracle 9i.

Почему кражи информации случаются в самых разных организациях, даже в силовых ведомствах? Каковы предпосылки утечки данных, и надо ли обладать обширными знаниями и умением взломщика, чтобы преодолеть существующую защиту? Существуют ли способы построения систем защиты информации (СЗИ), позволяющие свести к минимуму риски потери данных? Можно ли защитить корпоративные данные от собственного системного администратора?

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

Уровни защиты доступа к данным

Типовая модель защиты доступа пользователя к корпоративным данным и приложениям включает в себя четыре элемента:

-организационные меры ограничения доступа к компьютеру, подключенному к корпоративной сети;

-ограничения доступа к корпоративной сети;

-защита доступа к СУБД;

-ограничения на использование прикладного ПО конкретным пользователем.

ДЕ21:Привилегии доступа

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

Почему воруют информацию

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

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

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

Кражи информации из БД связаны, как правило, с неправомерными действиями пользователей сети предприятия, т. е. с реализацией внутренних угроз. По данным из разных источников, до 85% краж и компрометации информации совершают легальные пользователи информационной системы предприятия и, что особенно неприятно, администраторы СУБД или прикладной системы. На долю внутренних (т. е. зарегистрированных в корпоративной сети) хакеров, пытающихся получить несанкционированный доступ к информации, по разным оценкам, приходится соответственно до 15% угроз.

Внешние угрозы неправомерного доступа к корпоративным данным также подразделяются на два подкласса, из которых на долю внешних хакеров приходится до 20%, а на долю легальных пользователей корпоративной сети - до 100%.

Причина вторая - несостоятельность парольной защиты. Несмотря на огромное количество публикаций о том, что пароли не обеспечивают должную защиту данных и приложений, этот способ до сих пор наиболее широко распространен, прежде всего из-за своей нулевой стоимости. Достаточно подробно вопрос о несостоятельности парольной защиты рассмотрен, например, в работах [4, 5].

Самое неприятное, что такой подход зачастую применяется и в далеко не мелких организациях. А доступ к ресурсам системы нескольких разных пользователей под одной и той же учетной записью - весьма распространенная и прочно укоренившаяся практика. Например, если в организации работают пять системных администраторов, то все они могут иметь доступ по одному паролю. Хорошо иллюстрирует порочность такой организации доступа аналогия с ездой по улицам крупного города на автомобилях без номеров. Никакой сотрудник ГАИ не сможет четко идентифицировать автомобиль, превышающий дозволенную скорость, в потоке "анонимов", если все едут без номерных знаков.

Причина третья - не полностью задействованные встроенные в СУБД средства защиты информации и мониторинга действий пользователей, а также неоправданные надежды на квалификацию разработчиков прикладного ПО в части организации системы управления правами доступа. На ком реально лежит ответственность за применение/неприменение встроенных в СУБД средств защиты информации? Скорее всего, на разработчиках прикладного ПО, которые внедряют свои системы у заказчиков. Но парадокс заключается в том, что разработчики в подавляющем большинстве не имеют в своем штате специалиста по СЗИ и не знают о штатных возможностях организации защиты СУБД. По самым скромным оценкам, на российском рынке работает несколько тысяч прикладных систем и программных продуктов, базирующихся на использовании промышленных СУБД. При этом в подавляющем большинстве случаев считается, что все вопросы, связанные с безопасностью данных, выполняет сама СУБД1, а доступ в ИС происходит по паролю.

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

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

Встроенные средства защиты

Если рассматривать средства обеспечения безопасности в части доступа к БД, хранения информации и передачи по сети, то сегодня явный лидер рынка систем управления базами данных - СУБД Oracle. Она предоставляет разработчикам ПО и администраторам прикладных систем полный спектр средств и инструментов, необходимых для построения защищенных систем. Среди них стоит выделить следующие:

Virtual Private Database (VPD) - средства разграничения доступа к данным на уровне строк (в версии 10g - и на уровне колонок) и возможность организации работы пользователя только с виртуальной регламентированной частью данных, а не с реальной базой данных;

Oracle Advanced Security - комплекс средств аутентификации и обеспечения сетевой безопасности, включающий в себя поддержку защищенных протоколов передачи данных, в том числе SSL;

Oracle Label Security (OLS)- средства, аналогичные VPD, но с возможностью проверки уровня доступа пользователя;

Fine Grained Audit Control (FGAC) - инструмент подробного аудита.

Штатные средства Oracle + еToken

Кардинально повысить безопасность работы приложений БД позволяет защита клиентского ПО СУБД Oracle 9i с помощью электронных ключей еToken. Существенно усилить защиту удалось благодаря применению нескольких технологических решений.

Прежде всего метод аутентификации пользователей по имени и паролю был заменен более надежной - двухфакторной аутентификацией с использованием цифровых сертификатов стандарта X.509. И хотя встроенные средства Oracle Advanced Security поддерживают аутентификацию по цифровым сертификатам, вопрос о хранении сертификатов и личных ключей остается открытым. Предлагаемые Oracle способы хранения сертификатов в виде файлов-контейнеров формата PKCS#12 или реестра ОС Windows имеют ряд существенных недостатков. Суть встроенных в Advanced Security возможностей иллюстрирует схема хранения сертификатов (рис. ).

Рис. Схема хранения цифровых сертификатов 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").

Рис. Архитектура предоставления доступа.

Процедура аутентификации в СУБД Oracle с использованием eToken

Этап 1. Установление соединения клиент-сервер

Клиент посылает запрос на установление SSL-соединения.

Сервер отвечает на запрос посылкой своего сертификата и делает запрос сертификата клиента.

Клиент проверяет целостность, дату и срок действия сертификата, а также то, что сертификат подписан доверенным издателем.

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

Сервер проверяет целостность, дату и срок действия сертификата, а также то, что сертификат клиента подписан доверенным издателем, и при подтверждении подлинности "дает согласие" на обмен данными (в обратном случае - отказ в доступе).

Клиент и сервер обмениваются ключевой информацией, используя криптографические алгоритмы с открытым ключом. На данной стадии запрашивается авторизация пользователя в eToken (ввод PIN-кода).

На основании ключевой информации формируется сессионный ключ для шифрования трафика в течение сессии с использованием наилучшего симметричного алгоритма, доступного и для клиента, и для сервера.

Соединение клиента с сервером установлено. Этап 2. Авторизация пользователя сетевыми службами Oracle в БД

В LDAP-каталоге (Oracle Internet Directory) проводится поиск отличительного имени пользователя, соответствующего полю Subject сертификата клиента.

Если найдено соответствие, то по строке связи соединения определяется нужная БД, а по полю Subject сертификата клиента - схема доступа пользователя к указанной БД.

Определяются роли масштаба предприятия (enterprise roles) и их соответствие ролям в выбранной схеме пользователя.

Устанавливается соединение с БД.

Сертификаты и связанные с ними закрытые ключи хранятся в защищенной памяти eToken (она доступна только встроенному в него криптопроцессору). Чтобы выполнить криптографические операции с закрытым ключом, пользователь должен ввести PIN-код. Такой подход позволяет на практике реализовать модель организации защищенного доступа пользователя к данным (СУБД) с использованием цифровых сертификатов Х.509, установленных в eToken, в двух уровнях. Легальные пользователи корпоративной сети (например, под управлением контроллера домена Windows 2000/2003) могут авторизоваться в сети (рис. 3) только после успешного завершения процесса аутентификации по смарт-карте, включающего предъявление соответствующего сертификата (первый уровень). На втором уровне защиты доступ авторизованных пользователей корпоративной сети к защищенным данным СУБД возможен только при предъявлении соответствующего сертификата Oracle.

Рис. Двухуровневая модель доступа к защищенным данным с помощью цифровых сертификатов Х.509.

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

Обычно промышленные СУБД класса DB2 и Oracle сертифицированы как минимум по классу защищенности С2.