К сожалению, функция DES3GETKEY недоступна в версии Oracle8i. Вам придется создать собственный генератор случайных строк для получения подходящего ключа. Здесь пригодятся наши знания о генерации случайных строк (см. главу 7). Итак, в ранних версиях можно создать свою собственную функцию get_key следующим образом:
В строке 6 генерируется случайная строка печатных символов длиной 24 байта. В строке 7 она приводится к значению типа RAW, а затем преобразуется в шестнадцатеричное значение, как это было сделано в примере для Oracle9i. Наконец, строка возвращается для использования в качестве ключа.
Функция работает, но сгенерированная строка недостаточно произвольна с криптографической точки зрения. Однако с учетом того, что ранние версии Oracle не предоставляют средства формирования ключей, единственной альтернативой нашей функции является задание ключа вручную, что невозможно в реальной жизни. Так что предложенный подход является единственно возможным, но пользоваться им следует с осторожностью.
Получим такой результат:
Используя функции get_key, get_enc_val и get_dec_val мы можем создать полную систему шифрования, о чем будет рассказано в следующем разделе.
Как нам использовать только что полученные знания о шифровании в реальной жизни? Давайте рассмотрим таблицу ACCOUNTS.
Я хочу защитить данные, зашифровав столбцы BALANCE и ACCOUNT_NAME. Как я уже не раз повторял, наиболее важным элементом шифрования является ключ, и к его выбору следует подходить серьезно. Я могу сгенерировать ключ, использовать его для шифрования значения столбца, затем сохранить где-нибудь ключ и зашифрованное значение для последующего извлечения. Как именно я должен действовать? Есть несколько вариантов.
Можно определить представление для таблицы следующим образом:
Добавить в таблицу столбцы ENC_BALANCE и ENC_ACCOUNT_NAME для хранения зашифрованных значений соответствующих столбцов.
Добавить еще один столбец - ENC_KEY, для хранения ключа, использованного для шифрования.
Создать представление VW_ACCOUNTS:
Создать триггеры INSTEAD OF для обработки (при необходимости) операций обновления и вставки данных в таблицу.
Создать публичный синоним ACCOUNTS для представления VW_ACCOUNTS.
Выдать все привилегии на VW_ACCOUNTS и отозвать все привилегии на
ACCOUNTS.
В результате подобных манипуляций владелец схемы, а также любые пользователи, имеющие прямые привилегии на таблицу ACCOUNTS, бу-
дут видеть незашифрованные значения. Всем же остальным пользователям будут доступны только зашифрованные значения.
Можно зашифровать сами столбцы и использовать представление для отображения расшифрованных данных, то есть поступить следующим образом:
Добавить столбец ENC_KEY для хранения ключа для данной строки.
Сохранить в столбцах BALANCE и ACCOUNT_NAME соответствующие зашифрованные значения.
Создать представление VW_ACCOUNTS:
Теперь таблица будет содержать зашифрованные значения, а представление - незашифрованные, привилегии на которые можно выдать соответствующим пользователям.
Создать триггеры на таблицу для преобразования открытых значений в зашифрованные перед их вставкой или обновлением.
Преимуществом этого подхода является отсутствие необходимости в изменении самой таблицы.
Можно хранить ключи отдельно от таблицы. Оба описанных выше подхода имеют серьезный недостаток - ключ хранится в таблице. И любой, кто имеет доступ на выборку данных из таблицы, сможет увидеть ключ и расшифровать значения. Разумнее хранить ключи вне исходной таблицы, поступая следующим образом:
Создать таблицу ACCOUNT_KEYS, содержащую всего два столбца:
ACCOUNT_NO, который соответствует ACCOUNT_NO записи таблицы ACCOUNTS.
ENC_KEY - ключ, используемый для шифрования значения.
Сделать так, чтобы в реальной таблице ACCOUNTS содержались не открытые, а зашифрованные значения.
Создать триггеры для таблицы ACCOUNTS. Триггер AFTER INSERT генерирует ключ, использует его для шифрования реального значения, предоставленного пользователем, заменяет реальное значение на зашифрованное перед сохранением и затем сохраняет ключ в таблице ACCOUNT_KEYS.
Создать представление для отображения расшифрованных данных, соединив две таблицы.
Хранение ключей - это наиболее ответственная часть шифрования. И если не организовать его должным образом, то весь смысл шифрования как защиты данных может быть утерян. Существует множество вариантов хранения:
Этот подход, использованный в только что рассмотренном примере, наиболее удобен для работы с ключами. Однако у него есть серьезный недостаток: не существует способа защиты от администратора базы данных, который имеет права доступа к любой таблице.
Файл операционной системы
Файл может создаваться клиентским процессом во время исполнения с помощью встроенного пакета UTL_FILE или внешних таблиц, а затем - использоваться для расшифровки. После считывания файл может быть уничтожен. Этот способ обеспечивает более полную защиту от всех пользователей, включая и администратора базы данных.
Пользовательский ввод
Пользователь предоставляет функции ключ для дешифрования во время исполнения. Это наиболее надежный, но и наименее практичный способ из всех трех. Его недостаток в том, что пользователь может забыть ключ, в результате чего зашифрованные данные не удастся расшифровать никогда.
Начиная с версии Oracle 10^ Release 1 Oracle предлагает для поддержки шифрования пакет DBMS_CRYPTO. В этом разделе будет рассказано о генерировании ключей и шифровании данных средствами нового пакета. Однако сначала поговорим об отличиях DBMS_CRYPTO и DBMS_OBFUSCATION_ TOOLKIT.
Пакет DBMS_OBFUSCATION_TOOLKIT также доступен в Oracle 10^, но корпорация Oracle рекомендует пользоваться новым пакетом, так как возможности старого на его фоне оказываются ограниченными.
Существует ряд важных отличий DBMS_CRYPTO от DBMS_OBFUSCATION_TOOLKIT: Стандарт AES
Алгоритмы DES и DES3 уже устаревают, и многие организации уже перешли на более надежный алгоритм симметричного шифрования - Advanced Encryption Standard (AES). Пакет DBMS_OBFUSCATION_TOOLKIT
не поддерживает шифрование по этому новому стандарту, а DBMS_CRYPTO поддерживает. Потоковое шифрование (Stream cyphering)
Шифрование может применяться к данным поблочно, и такой процесс называется блочным шифрованием. Это широко распространенный и простой в использовании метод. Однако не все системы имеют возможность передавать данные равномерными порциями. В качестве примера можно привести зашифрованный контент, передаваемый в широковещательных и других сетях. В таких случаях содержимое должно шифроваться по мере поступления. Это так называемое потоковое шифрование. Пакет DBMS_OBFUSCATION_TOOLKIT не поддерживает потоковое шифрование, а DBMS_CRYPTO поддерживает.
| < Предыдущая | Следующая > |
|---|
