Три подхода к использованию встроенных технических средств защиты баз данных под управлением Oracle

Со вступлением в силу Федерального Закона "Об электронной цифровой подписи" - наша страна сделала значительный шаг вперед в сфере создания электронного документооборота, как более технологичного и экономного, но при этом имеющего тот же статус и полномочия, что и бумажное ведение документации. Принятие данного законодательного акта обеспечило возможность применения электронной цифровой подписи (ЭЦП), как аналога собственноручной, для подтверждения личности пользователя и достоверности электронных документов. ЭЦП до сих пор является наиболее совершенным решением для однозначной идентификации документа, его автора и сторон его подписавших (подписантов). Эти возможности ЭЦП открыли ряд перспектив развития для государственных и корпоративных информационных систем в области защиты информации от несанкционированного доступа, надёжной аутентификации сторон информационного обмена, обеспечении целостности и достоверности электронных документов. Технологической базой для реализации ЭЦП в информационных системах является PKI – инфраструктура открытых ключей.

Как надо защищать

Для баз данных (БД) известны следующие основные функции защиты информации:

• Защита доступа – доступ к данным может получить пользователь, прошедший процедуру идентификации и аутентификации.
• Разграничение доступа — каждый пользователь, включая администратора, имеет доступ только к необходимой ему согласно занимаемой должности информации.
• Шифрование данных — шифровать необходимо как передаваемые в сети данные для защиты от перехвата, так и данные, записываемые на носитель, для защиты от кражи носителя и несанкционированного просмотра/изменения нештатными средствами системы управления БД (СУБД).
• Аудит доступа к данным — действия с критичными данными должны протоколироваться. Доступ к протоколу не должны иметь пользователи, на которых он ведется.

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

Защита доступа

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

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

II. Аутентификация при помощи сетевых сервисов. Данный вид аутентификации обеспечивает опция сервера Oracle Advanced Security. Она предоставляет возможность SSL-аутентификации, а так же аутентификацию с помощью служб третьих сторон, в роли которых могут выступать Kerberos, PKI, RADIUS или служба LDAP-каталога.

III. Аутентификация в многоуровневых приложениях. Приведенные выше методы аутентификации также могут быть применены и в многоуровневых приложениях. Как правило, для доступа к приложениям из сети Интернет используется аутентификация по имени и паролю (в том числе с использованием протокола RADIUS), либо по протоколу SSL. Прочие методы используются для работы пользователей в локальной сети.

Разграничение доступа

Для обеспечения разграничения доступа в версии СУБД 10g Release 3 компания Oracle выпустила новый продукт Database Vault. Данная опция предназначена для защиты и ограничения доступа к критичным данным и приложениям. Разработчикам преследовалась цель защиты БД от внутренних злоумышленников. Database Vault предназначена для предотвращения несанкционированного доступа к информации пользователей, в том числе наделенных особыми полномочиями, например, администраторов базы данных. Набор правил в Database Vault, разграничивающих доступ, достаточно широк. Например, руководство организации может определить правила, согласно которым для решения задач, предполагающих доступ к критичной информации, потребуется одновременное присутствие двух сотрудников. Таким образом, Database Vault решает следующие проблемы:

• ограничение доступа к данным администратора БД и других привилегированных пользователей;
• предотвращение манипулирования с базой данных и обращения к другим приложениям администратора приложений;
• обеспечение контроля над тем, кто, когда и откуда может получить доступ к приложению.

Шифрование данных

Для защиты данных, передаваемых по сети, в СУБД Oracle, начиная с версии 8i, используется возможности опции Oracle Advanced Security, в которой предусмотрена функция Network encryption, позволяющая шифровать весь поток данных. Безопасность информации обеспечивается секретностью ключа, которым шифруются данные. Network encryption позволяет добиться высокого уровня безопасности. Поддерживаются следующие алгоритмы шифрования: Advanced Encryption Standard (AES) и RC4 , DES, 3DES.

Защита передаваемых в сети данных в приложениях Oracle обеспечивается протоколом SSL по алгоритмам, которые поддерживается сервером приложений, как правило, это Web-сервер Oracle. Защиту данных на носителе обеспечивают два компонента СУБД Oracle – пакеты, реализующие алгоритмы шифрования и опция Transparent Data Encryption. Начиная с версии 8i, СУБД Oracle предоставляет для разработчиков приложений пакеты хранимых процедур, реализующих алгоритмы:

• DES с длиной ключа 56 бит
• TripleDES с длиной ключа 112, 168 бит
• AES с длиной ключа 128, 192, 256 бит (только 10g/11g)
• RC4 (только 10g/11g).

Опция Transparent Data Encryption появилась в версии СУБД Oracle 10g Release 2 как составная часть Advanced Security. Она позволяет выборочно шифровать колонки таблиц с применением алгоритмов Triple DES (c длиной ключа 168 бит), AES (c длиной ключа 128, 192 или 256 бит). Управление ключами шифрования берет на себя ядро БД, а применение такого шифрования не требует переделки клиентского и серверного прикладного ПО. В версии СУБД 11g и выше появилась возможность зашифрования табличного пространства целиком.

Аудит доступа к данным

СУБД Oracle имеет мощные средства аудита действий пользователей, включающих как доступ к данным, так и события регистрации/выхода и изменения структуры БД. Начиная с версии 9i, СУБД оснащается опцией подробного аудита (Fine Grained Audit Control), которая позволяет проводить аудит доступа по условиям, определяемым достаточно гибкими настраиваемыми правилами. Однако, данные средства аудита не позволяет проследить за действиями, которые совершаются администратором базы данных, а также не мешают ему изменять журнал аудита, удаляя любые строки и не оставляя следов подобных действий. Возникшая необходимость аудита деятельности и защиты данных аудита от привилегированных пользователей, включая администраторов БД, побудило Oracle разработать новую концепцию аудита. В данную концепцию положена идея, на которой основан функционал Database Vault, то есть администратор БД изолирован от управления аудитом. Тем самым обеспечивается более высокий уровень безопасности БД. Как и в случае Database Vault, правила назначения аудита в Audit Vault очень гибкие.

Достаточно ли встроенных средств защиты?

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

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

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

Сценарий I. Встроенные средства безопасности не используются

Аргумент: парольная защиты достаточно

Простота использования парольной защиты не вызывает сомнений. Но вот с точки зрения надежности, безопасности и удобстве эксплуатации – такая технология себя изживает. Надежность пароля и, следовательно, безопасность его использования, напрямую зависит от его длины и качества (применяемые символы, их регистр, отличие от осмысленных слов). А удобство использования стремительно падает даже при незначительном усилении «безопасности» пароля – запомнить нечитаемую комбинацию из 20 символов довольно сложно. Обратимся к цифрам и фактам. Пароли пользователей хранятся в СУБД Oracle в виде хеш-значений и доступны для чтения привилегированным пользователям. Алгоритм вычисления хеша пароля давно известен. Наиболее полное исследование стойкости паролей в Oracle проведено компанией Red-Database-Security GmbH – ведущего мирового эксперта в области безопасности продуктов Oracle. Данные по стойкости паролей для версий СУБД 7-10g на компьютере с Pentium 4 3GHz при условии атаки простым перебором выглядят следующим образом: 10 секунд - все 5-символьные комбинации, 5 минут все 6-символьные комбинации, 2 часа - все 7-символьные комбинации и др. И это при использовании далеко не самого мощного компьютера, да и не самого эффективного метода атаки (атака по словарю прошла бы ещё быстрее). Однако, нельзя сказать, что Oracle не реагирует на подобное положение дел – в версии СУБД 11g положение значительно улучшилось. Был усилен алгоритм выработки хеша и качество формирования паролей. В результате затрачиваемое время для реализации атаки увеличилось в 2.5-3 раза. И, не смотря на эти улучшения, Oracle рекомендует использовать средства усиленной аутентификации, которые также были доработаны в лучшую сторону, например, стало возможно использовать HSM (Hardware Security Module) для аутентификации и хранения ключей шифрования.

Аргумент: низкая стоимость владения

Широко распространенное заблуждение. Статистика подтверждает факты значительных затрат на обслуживание, скажем, забытых паролей. Еще более ощутимые потери несут компании из-за низкой надежности и безопасности парольной защиты.

Аргумент: достаточность парольной защиты

Надежность и безопасность использования паролей для защиты ИС в настоящее время перестала отвечать требованиям компаний, которые, с одной, стороны заботятся о своей репутации, а с другой – обязаны выполнять требования текущего законодательства.

Сценарий II. Встроенные средства заменяются собственными разработками

Аргумент: встроенные средства защиты явно недостаточны и изобилуют уязвимостями

Этот аргумент в пользу второго сценария приводится по отношению к наиболее распространенному методу защиты в Oracle – парольной защите. Как уже было показано выше, она действительно ненадежна и это понимают в Oracle, предлагая использовать свой достаточно широкий спектр встроенных средств усиленной защиты. Скорее всего проблема «неиспользования» этих средств состоит в дополнительных затратах на программно-аппаратное обеспечение на реализацию данной функциональности. Что же касается уязвимостей встроенных средств защиты в Oracle, то ситуация здесь ровно такая же как и в других сложных системах. Корпорация Oracle традиционно ответственно относится к обнаружению и устранению найденных уязвимостей. Регулярно (4 раза в год) выпускаются обновления CPU (Critical Patch Update), устраняющие бреши, обнаруженные как самой корпорацией Oracle, так и десятками других компаний, наиболее известная из которых – уже упоминавшаяся Red-Database-Security GmbH. Так, например, в CPU за октябрь 2007 г. были устранены 27 уязвимостей в СУБД, 11 – в сервере приложений, 13 – в различных приложениях. Учитывая число продуктов Oracle, их версий и программно-аппаратных платформ для них, это не так уж и много.

Аргумент: своя разработка лучше поддержки вендора

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

Аргумент: система управления паролями сможет решить проблемы информационной безопасности.

Здесь можно лишь повторить, что парольная защита на сегодняшний день не отвечает требованиям, предъявляемым к безопасности ИС.

Сценарий III. Встроенные средства дополняются продуктами сторонних разработчиков

Аргумент: применение отечественных криптографических алгоритмов Использование по максимуму встроенных средств защиты и дополнение их, в случае недостающей функциональности, продуктами сторонних вендоров – такова основная идея третьего сценария применения средств защиты. В его пользу говорят, прежде всего, растущие нужды бизнеса с точки зрения безопасности и требования законодательства. Так, одним из важных дополнений штатных средств может стать использование российской криптографии. Криптографические алгоритмы могут применяться в процессе аутентификации, выработки ЭЦП (ГОСТ Р 34.10-2001), для защиты канала связи (ГОСТ 28147-89, ГОСТ Р 34.11-94) и шифрования данных (ГОСТ 28147-89). Встроенные средства Oracle не реализуют данные алгоритмы ни в СУБД, ни в сервере приложений, ни в приложениях. Реализацию криптографии в виде библиотек, стандартных поставщиков криптографии (CSP), комплектов разработчика (SDK) предлагают несколько российских производителей – КриптоПро, Сигнал-Ком, Инфотекс, Лисси, КриптоКом, КриптоЭкс и др. Однако, заставить продукты Oracle работать с предлагаемыми библиотеками достаточно проблематично. Дело даже не в том, что данные средства не совместимы на уровне программно-аппаратного обеспечения – встраивание криптографии в продукты Oracle не должно нарушать лицензионного соглашения вендора относительно целостности ПО. Если с ИС, построенными на основе сервера приложений Oracle или всего множества приложений Oracle, проблем со встраиванием, как правило, не возникает, то с СУБД дело обстоит сложнее. Вследствие того, что ядро СУБД не имеет программного интерфейса к криптооперациям (аутентификация, шифрование), приходится применять обходные пути. Например, использовать протокол аутентификации Kerberos или генераторы одноразовых паролей с протоколом RADIUS, а защиту канала связи осуществлять с помощью сертифицированных программных средств.

Аргумент: шифрование данных без использования TDE

Несмотря на чрезвычайную простоту опции Oracle TDE, от ее использования часто приходится отказываться. Основных причин три:

• не поддерживаются некоторые типы данных;
• нет возможности штатно применить российские криптоалгоритмы;
• нет реальной защиты от привилегированных пользователей.

Первая проблема в принципе решается с помощью продуктов сторонних разработчиков - DbEncrypt for Oracle (Application Security, Inc.), eToken SafeData (Aladdin Software Security R.D.), The Encryption Wizard for Oracle (Relational Database Consultants, Inc.). Вторая проблема принципиально решается таким же образом, но здесь вариантов меньше - eToken SafeData или The Encryption Wizard for Oracle. Причем для первого продукта требуется дополнительная сборка версии (в зависимости от применяемого производителя сертифицированной криптографии), а по второму продукту, просто не удалось найти нужную информацию. Третья проблема, в принципе, могла бы быть решена с помощью совместного использования опций TDE и Oracle Database Vault, но в этом случае полномочия администратора СУБД плавно перетекают к администратору Database Vault, т.е. проблема защиты от привилегированных пользователей сохраняется.

Аргумент: необходимость надёжного хранение ключевого материала

Ключевой материал (сертификаты, закрытые ключи, ключи шифрования), используемые встроенными средствами обеспечения безопасности Oracle для аутентификации или шифрования данных, хранятся в ключевых контейнерах, (т.н. бумажниках - wallets) как обычные файлы. Для доступа к информации в бумажнике требуется пароль. Часто такой способ хранения не отвечает требования по безопасности, особенно на рабочих станциях клиентов. СУБД Oracle, начиная с версии 10g, позволяет хранить закрытые ключи на аппаратных устройствах, поддерживающих стандарт PKCS#11. В то же время Oracle никак не гарантирует работу аппаратных устройств, отличных от устройств производства nCipher (nCipher Corporation Ltd.). Это не всегда приемлемо, например, если предполагается использование только сертифицированных аппаратных средств. В этом случае проблема хранения ключей и сертификатов может быть решена с помощью решений сторонних производителей. На российском рынке, пожалуй, единственным в своем классе продуктом является eToken SecurLogon для Oracle (Aladdin Software Security R.D.).

Общие выводы

Подводя итог, можно сказать, что настоящее время требования к безопасности со стороны потребителей достаточно высоки, и оптимальное решение состоит в полноценном использовании встроенных средств безопасности и разумным их дополнением продуктами и решениями сторонних разработчиков. Однако часто стремление построить надежную защиту ИС упирается в банальную нехватку квалифицированных кадров – разработчиков, аналитиков, инженеров техподдержки, консультантов. Следствием этого являются слабое владение информацией о возможностях встроенных средств защиты Oracle и их корректного использования. Другим следствием является та же ситуация, но уже по отношению к продукции других производителей программно-аппаратных средств защиты информации и их использованию совместно с технологиями и продуктами Oracle. Как итог – существующие системы продолжают использовать устаревшие парольные системы защиты, обрастая ненужными доработками и ворохами дополнительных регламентов, и, что еще хуже, разрабатываются новые ИС со старыми технологиями защиты. Выход из такой ситуации видится прежде всего в подготовке кадров, обладающих экспертными знаниями в собственно информационной безопасности, в линейке продуктов Oracle и умеющих интегрировать разработки российских компаний со встроенными средствами защиты. Подобное обучение должно начинаться уже в профильных ВУЗ'ах, и специалисты в данной области должны иметь возможность наращивать опыт и навыки в обучающих центрах. Хотелось бы видеть поддержку в данном вопросе как со стороны Oracle, так и со стороны других производителей, работающих на рынке информационной безопасности России.