Документация Oracle на русском языке





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

Главная :: Карта


Oracle Database или Oracle RDBMS — объектно-реляционная система управления базами данных компании Oracle.



 

DeepEdit!

Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Управление ключами в Oracle 10g

Мы изучили основы зашифровывания и расшифровывания, а также способы генерирования ключей. Это была простая часть задачи, ведь по большей части мы использовали имеющиеся программы Oracle и создавали для них оболочки. Теперь пришло время самого серьезного этапа шифрования - управления ключами. Нашим приложениям необходимо обращаться к ключу для расшифровывания зашифрованного значения, и наша задача в том, чтобы сделать механизм доступа как можно более простым. С другой стороны, ключ не должен быть простым настолько, чтобы быть легко разгаданным хакерами. В хорошей системе управления ключами простота доступа к ключу уравновешена мерами предотвращения неавторизованного доступа к нему.
Существует три основных подхода к управлению ключами:
Использование одного и того же ключа для всей базы данных
Использование различных ключей для разных строк таблиц с зашифрованными данными
Комбинированный подход
В последующих разделах будут рассмотрены эти три способа управления ключами.
В этой главе рассматриваются возможности версии Oracle 10g, но общая идея также применима и к базе данных Oracle9/, так что информация об управлении ключами окажется полезной и для тех, кто пользуется старой версией.
Использование одного ключа
В этом случае для доступа ко всем данным базы данных используется один и тот же ключ. Программа шифрования считывает всего один ключ (оттуда, где он хранится) и шифрует с его помощью все данные, которые следует защитить (рис. 4.3). Существует несколько возможных мест хранения ключа:
В базе данных

Это самый простой способ. Ключ хранится в реляционной таблице, возможно, в специально созданной для этих целей схеме. Благодаря тому, что ключ находится внутри базы данных, автоматически создается его резервная копия, так что старые значения ключа можно получить ретроспективным запросом (flashback query); кроме того, ключ не может быть украден из операционной системы. Но простота подхода является и его слабым местом: ключ - это просто данные в таблице, так что каждый, кто имеет права на редактирование со-

ответствующей таблицы (например, администратор базы данных), может изменить ключ, разрушив тем самым систему шифрования.
В файловой системе
Ключ сохраняется в файле, который затем может быть прочитан процедурой шифрования при помощи встроенного пакета UTL_FILE. Задав соответствующие привилегии для данного файла, вы гарантируете отсутствие возможности его изменения для пользователей базы данных.
На каком-то съемном носителе, подконтрольном конечному пользователю
Это наиболее надежный способ. Никто кроме конечного пользователя не может расшифровать значения или изменить ключ (это относится и к администратору базы данных, и к системному администратору). В качестве примера съемного носителя можно привести USB-карту, DVD-диск или съемный жесткий диск. Основным недостатком съемного носителя является возможность потери или кражи ключа. Ответственность за сохранность ключа целиком ложится на конечного пользователя. Если ключ потерян, то потеряны (безвозвратно) и зашифрованные данные.
Главное преимущество использования единственного ключа заключается в том, что программам шифрования не приходится выбирать ключи из таблиц или сохранять их каждый раз при обработке записи таблицы. Общая производительность увеличивается за счет уменьшения количества циклов процессора и операций ввода-вывода. Главным недостатком этого подхода является его полная зависимость от одного элемента. Если в базу данных проникает злоумышленник и определяет значение ключа, то вся база данных становится уязвимой. Кроме того, если вы захотите сменить ключ, то придется изменить все строки всех таблиц, что может быть достаточно трудоемкой задачей для больших баз данных (рис. 4.3).
Названные недостатки, особенно последствия потери ключа, делают использование этого подхода чрезвычайно редким. Он может быть полезен лишь в отдельных ситуациях. Например, в системе публикации данных, где ключ используется только при передаче данных, затем уничтожается, и для следующей передачи используется уже новый ключ. Такая система может использоваться агентствами финансовой информации при отправке аналитических данных клиентам или, например, в случае, если одно подразделение компании отправляет конфиденциальные корпоративные данные другому подразделению или головному офису.
Использование ключа для каждой строки
Второй подход заключается в использовании разных ключей для всех строк таблицы (рис. 4.4). Такой подход существенно более надежен,

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

Комбинированный подход

В некоторых случаях может не подойти ни один из описанных ранее способов. Давайте выделим положительные и отрицательные стороны каждого из них.
• Использование одного ключа:
Чрезвычайно простое управление ключами. Есть всего один ключ, который нужно создать, прочитать и сделать для него резервную копию.
Ключ можно сохранить во многих местах, к которым удобно обращаться приложениям.
c. С другой стороны, как только ключ украден, вся база данных становится уязвимой.
Использование отдельного ключа для каждой строки:
Количество ключей равно количеству строк, что усложняет управление ключами: больший объем данных нужно хранить, резервировать и т. д.
С другой стороны, кража одного ключа приводит к рассекречиванию только одной строки, но не всей базы данных. Общая безопасность системы повышается.
Очевидно, что оба подхода несовершенны. Пользователю нужно найти какое-то компромиссное решение, то есть использовать некий подход, сочетающий в себе качества уже рассмотренных. Можно использовать новый ключ для каждого столбца (при этом к каждой строке будет применен один и тот же ключ), или новый ключ для каждой таблицы независимо от количества столбцов, или новый ключ для каждой схемы, или что-то еще. Количество ключей, используемых любым из предложенных подходов, значительно уменьшится, упростив управление ключами, но возрастет уязвимость данных.
Давайте рассмотрим еще один подход. Будем использовать комбинацию ключей (рис. 4.5):
Один ключ для каждой строки плюс
Мастер-ключ для всей базы данных.
Речь не идет о шифровании зашифрованного значения (фактически это невозможно). Несмотря на то что определяется ключ для каждой

строки, при шифровании используется не тот ключ, который был сохранен для данной строки, а результат побитовой операции XOR (исключающее ИЛИ) для двух значений: сохраненного ключа и мастер- ключа. Мастер-ключ может храниться отдельно от других ключей, как показано на рис. 4.6. Для успешного расшифровывания зашифрованного значения злоумышленнику придется найти оба ключа.
Встроенный пакет UTL_RAW содержит функцию BIT_XOR, которую можно использовать для выполнения побитовой операции «исключающее ИЛИ». Выполним побитовую операцию XOR для двух значений: 12345678 и 87654321.

Для выполнения побитовой операции сначала преобразуем значения к типу данных RAW (как это сделано в строке 8: вызов функции UTL_I18N. STRING_TO_RAW преобразует значение к типу RAW). В строке 7 вызываем побитовую функцию «исключающее ИЛИ», а в конце выводим два входных значения, преобразованные к типу RAW, а также результат операции XOR.
Результат будет таким:

Обратите внимание, что результат побитовой операции XOR совсем не похож ни на одно из входных значений. Таким образом, на основе двух значений - сохраненного ключа для строки и мастер-ключа - мы можем сгенерировать новый (отличный от них) ключ, который и будет использован для шифрования. Для того чтобы получить этот настоящий ключ (результат операции XOR), вам нужны оба значения. Поэтому человек, узнавший одно из значений, не сможет расшифровать значение, полученное с помощью XOR, и соответственно получить реальный ключ.
Данный способ не является повторным шифрованием зашифрованных данных посредством нового ключа. Пакет DBMS_CRYPTO не позволяет повторно зашифровать уже зашифрованное значение. Если бы вы попытались выполнить подобную операцию, то получили бы сообщение об ошибке ORA-2823, информирующее о том, что данные уже зашифрованы.
Изменим нашу программу шифрования так, чтобы в ней использовался мастер-ключ. Добавляем (в строке 6) новую переменную l_mas- ter_key, которая принимает значение от пользователя (переменная подстановки &master_key). В строках 15-17 выполняем операцию XOR для ключа и мастер-ключа и используем результат в качестве ключа шифрования вместо переменной l_key в строке 22.



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


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

Мы видим сообщение об ошибке: использование неверного мастер- ключа приводит к тому, что зашифрованные данные не расшифровываются. Наш усовершенствованный механизм базируется на двух разных ключах, и оба ключа необходимы для успешной расшифровки. Если вы спрячете мастер-ключ, то этого будет достаточно для предотвращения неавторизованного расшифровывания.
Т. к. мастер-ключ хранится на клиентском компьютере и пересылается по сети, то потенциальный злоумышленник может использовать специальное средство (снифер) для перехвата значения в момент его передачи. Защититься от этого можно следующими способами:
Можно создать виртуальную локальную сеть (virtual local area network - VLAN) между сервером приложений и сервером базы данных. VLAN в значительной мере защищает сетевой трафик между серверами.
Вы можете изменить мастер-ключ каким-то предопределенным способом, например, изменив порядок символов на обратный; тогда злоумышленник, получив ключ, переданный по сети, не получает реально используемый мастер-ключ.
Наконец, действительно надежным решением является использование опции расширенной безопасности ASO - Oracle Advanced Security Option (предоставляемой за дополнительную плату), обеспечивающей безопасность трафика между клиентом и сервером.
 



jAntivirus