Перейти к содержимому
Аладдин Р.Д.
Библиотека

Русская версия "индийской защиты", или Защита данных в СУБД Oracle

БиблиотекаБиблиотека

Август, 2004

Метод защиты доступа к конфиденциальным данным основан на совместном использовании штатных средств СУБД Oracle 9i и персональных идентификаторов eToken, где хранятся цифровые сертификаты Х.509, обеспечивающие доступ к данным.

Традиционные, в основном организационные, меры обеспечения безопасности давно исчерпали себя: техника и вооружение злоумышленников совершенствуются, требуя всё более совершенной охраны данных. Но пока законодатели спорят о проектах законов, в переходах метро, на автостоянках и в Интернете продаются компакт-диски с базами данных: за 40–60 долларов — БД МГТС (актуализация январь 2003), Единой государственной регистрации предприятий (полная информация о зарегистрированных в России предприятиях, 2003), сведения о прописке в Москве и области; за 110 — БД ВЭД; “залежалый товар” вроде данных абонентов МТС (ноябрь 2002) — всего за 40 “у.е.”. Честному гражданину неприятно обнаружить свои персональные на таком диске — тем более что его легко покупают и криминальные структуры. Страшнее всего, что реальных механизмов предотвращения кражи и доказательства преступления практически не существовало; на момент написания статьи решение по защите данных Oracle 9i электронными ключами eToken не имеет аналогов на мировом рынке. Суть метода — штатные механизмы инфраструктуры открытых ключей и доступ по предъявлению цифровых сертификатов Х.509 (Oracle Advanced Security) на двух уровнях: аутентификация в корпоративной сети (например, Windows Server 2000/2003) и доступ к конфиденциальным данным на серверах Oracle; оба сертификата хранятся в eToken (USB-ключ или смарт-карта). Метод значительно снижает риски человеческого фактора и однозначно персонифицирует действия пользователей, работающих с Oracle 9i.

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

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

Причина первая и главная — отсутствие системного подхода к оценке угроз: лишь малая часть предприятий применяет международный опыт и общий подход Гостехкомиссии [3]. Угрозы для корпоративных БД классифицируются по источнику на внутренние (легальные пользователи БД, внутренние хакеры) и внешние (легальные пользователи корпоративной сети, внешние хакеры). Кражи из БД связаны прежде всего с внутренними угрозами: до 85% краж и компрометаций совершают легальные пользователи и, особенно неприятно, администраторы СУБД или прикладных систем; на внутренних хакеров — до 15%. Внешние: на внешних хакеров до 20%, на легальных пользователей корпоративной сети — до 80%.

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

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

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

Явный лидер рынка СУБД — Oracle, предоставляющий полный спектр средств построения защищённых систем. Virtual Private Database (VPD) — разграничение доступа на уровне строк (в 10g — и колонок), работа пользователя с виртуальной регламентированной частью данных, а не с реальной базой. Oracle Advanced Security — комплекс средств аутентификации и сетевой безопасности с поддержкой защищённых протоколов, включая SSL. Oracle Label Security (OLS) — аналогично VPD, но с проверкой уровня доступа пользователя. Fine Grained Audit Control (FGAC) — инструмент подробного аудита.

Кардинально повысить безопасность позволяет защита клиентского ПО Oracle 9i электронными ключами eToken. Метод аутентификации по имени и паролю заменён двухфакторной с цифровыми сертификатами Х.509. Встроенные средства Oracle Advanced Security поддерживают аутентификацию по сертификатам, но вопрос их хранения остаётся открытым: предлагаемые Oracle файлы-контейнеры PKCS#12 или реестр Windows имеют существенные недостатки — файл может быть похищен злоумышленником с правами на чтение ключа реестра или файла, а работа с СУБД разрешена только пользователю контейнера, “привязанному” к конкретной станции. Чтобы избежать этих “неприятностей”, сертификаты хранятся непосредственно в памяти eToken, а криптооперции с закрытым ключом выполняет встроенный криптопроцессор с дополнительной PIN-авторизацией. Помимо надёжности — преимущества и в удобстве: не нужно хранить “где попало” и запоминать имена и пароли; зная один PIN-код и выбрав сертификат из списка, можно (при соответствующих правах) обращаться к конкретной БД с любой рабочей станции. Администратор безопасности получает централизованное управление доступом и контроль работы системных администраторов; единый инструмент — служба каталогов Oracle Internet Directory, своего рода портал архитектуры клиент-сервер и единая точка входа; в большинстве случаев изменений в прикладном ПО не требуется.

Решение базируется на цифровых сертификатах Х.509 и протоколе SSL, поддерживающем строгую двухфакторную аутентификацию пользователей СУБД Oracle и шифрование информации, передаваемой между сервером БД и клиентской станцией. Задействованы лишь штатные настройки СУБД и клиента Oracle, описанные в документации Oracle Advanced Security; установка сервисов eToken на станции позволяет применять сертификаты на ключе для аутентификации в СУБД. Сертификаты и закрытые ключи хранятся в защищённой памяти eToken (доступна только встроенному криптопроцессору); для криптооперций пользователь вводит PIN-код. Реализуется двухуровневая модель защищённого доступа: легальные пользователи корпоративной сети (например, под контроллером домена Windows 2000/2003) авторизуются в сети только после успешной аутентификации по смарт-карте с предъявлением соответствующего сертификата (первый уровень); на втором уровне доступ авторизованных пользователей к защищённым данным СУБД — только при предъявлении соответствующего сертификата Oracle.

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

Это краткая аннотация статьи, полную версию читайте в первоисточнике.


Читать полную версию

Первоисточник: BYTE, август 2004

Эксперт: Константин Демченко, Аладдин