Три подхода к использованию встроенных технических средств защиты баз данных под управлением Oracle
Апрель, 2008
ФЗ “Об электронной цифровой подписи” сделал ЭЦП аналогом собственноручной подписи для подтверждения личности пользователя и достоверности электронных документов — до сих пор это наиболее совершенное решение для однозначной идентификации документа, его автора и подписантов. Технологическая база ЭЦП — инфраструктура открытых ключей (PKI), открывшая гос- и корпоративным системам перспективы защиты от несанкционированного доступа, надёжной аутентификации сторон и обеспечения целостности документов.
Как надо защищать
Заголовок раздела «Как надо защищать»Основные функции защиты БД: защита доступа (данные — только прошедшим идентификацию и аутентификацию), разграничение доступа (каждый, включая администратора, — только к необходимой по должности информации), шифрование данных (передаваемых в сети от перехвата и записываемых на носитель — от кражи и несанкционированного просмотра нештатными средствами СУБД) и аудит доступа (действия с критичными данными протоколируются, доступ к протоколу закрыт для тех, на кого он ведётся). Практически всеми этими функциями оснащены СУБД и приложения Oracle — что выгодно отличает их от конкурентов.
Защита доступа: аутентификация в Oracle — проверка подлинности пользователя, приложения или устройства, после которой авторизация назначает роли и привилегии; способы: аутентификация средствами ОС (по сетевым учётным данным без указания имени/пароля — считается небезопасной, в основном для администратора СУБД), сетевые сервисы через опцию Oracle Advanced Security (SSL, а также Kerberos, PKI, RADIUS, LDAP-каталог) и аутентификация в многоуровневых приложениях (из Интернета — имя/пароль, в т.ч. по RADIUS, либо SSL; прочие методы — для локальной сети); пароли передаются по сети в зашифрованном виде.
Разграничение доступа: в 10g Release 3 Oracle выпустила Database Vault — защиту от внутренних злоумышленников, включая наделённых особыми полномочиями администраторов БД. Правила гибкие — например, для доступа к критичной информации может требоваться одновременное присутствие двух сотрудников; решаются задачи ограничения доступа администратора БД и привилегированных пользователей, предотвращения манипулирования базой со стороны администратора приложений и контроля того, кто, когда и откуда получает доступ.
Шифрование данных: для передачи по сети — Network encryption опции Oracle Advanced Security (с версии 8i) на алгоритмах AES, RC4, DES, 3DES; в приложениях — SSL средствами сервера приложений. На носителе — два компонента: пакеты хранимых процедур для разработчиков (с 8i; DES 56 бит, TripleDES 112/168, AES 128/192/256 и RC4 в 10g/11g) и Transparent Data Encryption (10g Release 2, часть Advanced Security) — выборочное шифрование колонок TripleDES/AES с управлением ключами ядром БД и без переделки клиентского и серверного ПО; в 11g — зашифрование табличного пространства целиком.
Аудит: Oracle имеет мощные средства аудита, с 9i — Fine Grained Audit Control с гибкими правилами, но они не прослеживают действия администратора БД и не мешают ему изменять журнал аудита. Это побудило Oracle к новой концепции Audit Vault: администратор БД изолирован от управления аудитом — как в Database Vault, с очень гибкими правилами.
Достаточно ли встроенных средств защиты?
Заголовок раздела «Достаточно ли встроенных средств защиты?»Обзор показывает солидный задел Oracle, но на практике (за редким исключением) арсенал встроенных средств не используется. Три распространённых сценария: не используются вовсе (достаточно парольной защиты); заменяются собственными разработками или готовыми с рынка; дополняются ПО сторонних разработчиков.
Сценарий I — “парольной защиты достаточно”. Надёжность пароля зависит от длины и качества, а удобство стремительно падает при усилении. Пароли в Oracle хранятся в виде хеш-значений, доступных привилегированным пользователям, алгоритм хеша давно известен. По исследованию Red-Database-Security GmbH (ведущий мировой эксперт по безопасности Oracle), на Pentium 4 3 GHz простым перебором: все 5-символьные комбинации — 10 секунд, 6-символьные — 5 минут, 7-символьные — 2 часа (атака по словарю прошла бы быстрее). В 11g алгоритм усилен — время атаки выросло в 2,5–3 раза, и Oracle рекомендует средства усиленной аутентификации, включая HSM (Hardware Security Module). “Низкая стоимость владения” — заблуждение: значительные затраты на обслуживание забытых паролей и потери от низкой надёжности; парольная защита перестала отвечать требованиям и репутации, и законодательства.
Сценарий II — “встроенные средства недостаточны и изобилуют уязвимостями”. Аргумент относится в основном к парольной защите — она действительно ненадёжа, и Oracle предлагает широкий спектр усиления; “неиспользование” скорее объясняется дополнительными затратами. С уязвимостями Oracle работает ответственно: 4 раза в год выходят CPU (Critical Patch Update) — например, в октябрьском CPU 2007 года устранены 27 уязвимостей в СУБД, 11 в сервере приложений и 13 в приложениях (учитывая число продуктов, версий и платформ — немного). “Своя разработка лучше поддержки вендора”: не всякая компания может позволить себе специалистов по ИБ в подразделении разработки.
Сценарий III — встроенные средства дополняются продуктами сторонних разработчиков. Основная идея — максимум штатных средств плюс дополнение недостающей функциональности: этого требуют бизнес и законодательство. Важнейшее дополнение — российская криптография (ЭЦП по ГОСТ Р 34.10-2001, защита канала по ГОСТ 28147-89 и ГОСТ Р 34.11-94, шифрование данных), которую Oracle не реализует нигде. Библиотеки, CSP и SDK предлагают КриптоПро, Сигнал-Ком, Инфотекс, Лисси, КриптоКом, КриптоЭкс и др., но заставить продукты Oracle работать с ними проблематично: встраивание не должно нарушать лицензионного соглашения о целостности ПО, и если с сервером приложений и приложениями Oracle проблем обычно нет, то ядро СУБД не имеет программного интерфейса к криптооперациям — приходится применять обходные пути (протокол Kerberos, генераторы одноразовых паролей с RADIUS, защита канала сертифицированными программными средствами). От опции TDE часто приходится отказываться по трём причинам: не поддерживаются некоторые типы данных (решается DbEncrypt for Oracle, eToken SafeData, The Encryption Wizard for Oracle); нет российских криптоалгоритмов (eToken SafeData — с дополнительной сборкой под конкретного криптопроизводителя — или Encryption Wizard, по которому нужной информации найти не удалось); нет реальной защиты от привилегированных пользователей (TDE + Database Vault лишь перекладывает полномочия на администратора Vault). Наконец, хранение ключевого материала: встроенные средства держат сертификаты и ключи в “бумажниках” (wallets) — обычных файлах с паролем, что не всегда отвечает требованиям, особенно на клиентских станциях; с 10g Oracle позволяет хранить закрытые ключи на аппаратных устройствах PKCS#11, но гарантирует работу только с устройствами nCipher — если нужны сертифицированные средства, на российском рынке единственный в своём классе продукт — eToken SecurLogon для Oracle.
Оптимум — полноценное использование встроенных средств защиты и разумное дополнение продуктами сторонних разработчиков. Но надёжная защита часто упирается в нехватку квалифицированных кадров: слабое владение возможностями встроенных средств Oracle и продукцией других производителей. Следствие — системы продолжают жить с устаревшими парольными защитами, обрастая доработками и регламентами, а новые ИС разрабатываются со старыми технологиями. Выход — подготовка кадров с экспертными знаниями по ИБ, линейке Oracle и интеграции российских разработок, начиная с профильных ВУЗов и наращиванием опыта в обучающих центрах — при поддержке Oracle и других производителей рынка ИБ России.
Алексей Сабанов, заместитель генерального директора, компания Aladdin
Александр Додохов, руководитель направления защиты баз данных, компания Aladdin
Это краткая аннотация статьи, полную версию читайте в первоисточнике.
Первоисточник: Connect! №4/2008, апрель 2008
Эксперт: Алексей Сабанов, Аладдин Эксперты: Алексей Сабанов (Аладдин), Александр Додохов (Аладдин)