|
|
|
Ваши замечания и предложения отправляйте редактору По техническим вопросам обращайтесь к вебмастеру Дата публикации: 20.06.05 | |
| © Владимир Пржиялковский, координатор Евро-Азиатской Группы Пользователей Oracle, преподаватель УКЦ Interface Ltd. | |
|
Уж давно я тайну эту Хороню в груди своей И бесчувственному свету Не открою тайны сей ... | |
| К. Прутков, "Путник" | |
Введение
Пакет DBMS_OBFUSCATION_TOOLKIT
Пакет DBMS_CRYPTO
Дополнительная информация
Современные промышленные СУБД позволяют хранить в своих базах данные одновременно многих пользователей, и поэтому желание защитить собственные данные от постороннего глаза вполне понятно. Некоторым решениям этого вопроса в Oracle были посвящены ранее публиковавшиеся статьи Выводимые таблицы с хранимым результатом. Часть 1, Выводимые таблицы с хранимым результатом. Часть 2, К каждой строке охранника приставишь! и В версии Oracle10 "виртуальные частные базы данных" данных стали избирательнее. Однако эти решения Oracle не позволяют закрыть проблему конфиденциальности полностью.
Дело в том, что СУБД Oracle, так же как и другие промышленные системы, построена по принципу суперпользователя, который всегда способен прочитать все данные любого пользователя. Суперпользователем в Oracle является SYS. У него есть полномочие ("привилегия") SELECT ANY TABLE, а значит он может прочитать данные всех таблиц в БД. У него есть привилегия ALTER USER, а значит он может временно подменить любому пользователю пароль, войти в систему под чужим именем и работать неотличимо от оригинала, так что никакой аудит не обнаружит несанкционированный доступ. Тем самым сотрудник, которыму предоставлено право работать под именем SYS, должен быть крайне доверенным лицом в организации, где используется БД под Oracle. Но можно ли снизить риск утечки собственных данных через суперпользователя?
Ответ лежит вовне Oracle. Если перед помещением данных в БД их зашифровать, суперпользователь, хотя и прочтет, что хранится в БД, но ничего не поймет. Сделать это можно в клиентской программе, однако для сложного приложения организационно удобнее шифровать централизованнно, на сервере. Для этой цели можно воспользоваться двумя пакетами, специально предназначенных в Oracle для работы с шифрованными данными. Примеры такой работы приводятся далее.
Начиная с версии 8.1.6 с Oracle поставляется пакет для шифрования и расшифровки методом DES под названием DBMS_OBFUSCATION_TOOLKIT. Процедурой DESENCRYPT этого пакета можно с помощью ключа зашифровать текстовую строку, а процедурой DESDECRYPT расшифровать.
Пример в SQL*Plus:
SET SERVEROUTPUT ON
DECLARE
input_string VARCHAR2(4000) := 'Morgen, morgen, nur nicht heute';
work_string VARCHAR2(4000);
encrypted_string VARCHAR2(4000);
decrypted_string VARCHAR2(4000);
BEGIN
DBMS_OUTPUT.PUT_LINE(input_string);
work_string := RPAD
(
input_string
, (TRUNC(LENGTH(input_string) / 8) + 1 ) * 8
, CHR(0)
);
DBMS_OBFUSCATION_TOOLKIT.DESENCRYPT
(
input_string => work_string
,key_string => 'MagicKey'
,encrypted_string => encrypted_string
);
DBMS_OBFUSCATION_TOOLKIT.DESDECRYPT
(
input_string => encrypted_string
,key_string => 'MagicKey'
,decrypted_string => work_string
);
decrypted_string := RTRIM(work_string, CHR(0));
DBMS_OUTPUT.PUT_LINE(decrypted_string);
END;
/
Для шифрования использован восьмибайтовый ключ MagicKey. Так как алгоритм DES работает только со строками, кратными 8 байтам, мы вынуждены искусственно удлиннять входную строку. Для общего случая в качестве дополняющего символа наиболее естественным выглядит CHR(0), хотя в конкретных ситуациях он может и оказаться неприемлемым. В следующем разделе предложено более современное решение проблемы дополняющего символа.
В этом же пакете имеются аналогичные процедуры для более стойкого алгоритма 3DES, а также для получения свертки текста по алгоритму MD5, что можно использовать для гарантии целостности данных (защита от несанкционированной подмены).
Сценарий заведения пакета в БД находится в rdbms\admin\catobtk.sql.
В версии 10 в состав системных пакетов включен (в перспективе - на замену DBMS_OBFUSCATION_TOOLKIT) более функциональный пакет DBMS_CRYPTO, позволяющий шифровать данные других типов (не RAW и VARCHAR2, а RAW, CLOB и BLOB) и другими алгоритмами (не только DES, 3DES, но еще и AES, и RC4, и 3DES_2KEY плюс алгоритмы хеширования плюс параметризация этих алгоритмов). Он построен по иной технике, когда для шифрования используются всего две общие функции ENCRYPT и DECRYPT, а ссылка на конкретный алгоритм передается параметром. Вот как с помощью DBMS_CRYPTO может выглядеть DES-шифрование той же строки тем же ключом, что и выше:
DECLARE
input_string VARCHAR2(255) := 'Morgen, morgen, nur nicht heute';
raw_input RAW(4000);
key_string VARCHAR2(8) := 'MagicKey';
raw_key RAW(16);
encrypted_raw RAW(4000);
encrypted_string VARCHAR2(4000);
decrypted_raw RAW(4000);
decrypted_string VARCHAR2(4000);
BEGIN
DBMS_OUTPUT.PUT_LINE(input_string);
raw_input := UTL_I18N.STRING_TO_RAW (input_string, 'AL32UTF8');
raw_key := UTL_RAW.CAST_TO_RAW(CONVERT(key_string, 'AL32UTF8'));
encrypted_raw := DBMS_CRYPTO.ENCRYPT
(
TYP => DBMS_CRYPTO.DES_CBC_PKCS5
,SRC => raw_input
,KEY => raw_key
);
decrypted_raw := DBMS_CRYPTO.DECRYPT
(
TYP => DBMS_CRYPTO.DES_CBC_PKCS5
,SRC => encrypted_raw
,KEY => raw_key
);
decrypted_string := UTL_I18N.RAW_TO_CHAR (decrypted_raw, 'AL32UTF8');
DBMS_OUTPUT.PUT_LINE(decrypted_string);
END;
/
(Чтобы пример проработал, нужно будет выполнить от имени SYS:
CREATE PUBLIC SYNONYM DBMS_CRYPTO TO PUBLIC;
Скорее всего разработчики забыли вставить это предложение в сценарий заведения пакета и в будущих версиях этого нам делать не придется).
Здесь технология не требует искусственного удлинения строки до нужной кратности, но зато необходимо предъявлять параметры в формате RAW и в кодировке AL32UTF8, что тоже приводит к усложнению текста.
Константа DBMS_CRYPTO.DES_CBC_PKCS5 выше есть сумма трех констант ENCRYPT_DES (алгоритм шифрования, размер ключа), CHAIN_CBC (размер блоков, на которые в процессе шифрования будет разбиваться исходная строка) и PAD_PKCS5 (схема дополнения строки до требуемой кратности). В этом легко удостовериться:
SQL> EXEC DBMS_OUTPUT.PUT_LINE(DBMS_CRYPTO.ENCRYPT_DES)
1
PL/SQL procedure successfully completed.
SQL> EXEC DBMS_OUTPUT.PUT_LINE(DBMS_CRYPTO.CHAIN_CBC)
256
PL/SQL procedure successfully completed.
SQL> EXEC DBMS_OUTPUT.PUT_LINE(DBMS_CRYPTO.PAD_PKCS5)
4096
PL/SQL procedure successfully completed.
SQL> SELECT 1 + 256 + 4096 FROM DUAL;
1+256+4096
----------------
4353
SQL> EXEC DBMS_OUTPUT.PUT_LINE(DBMS_CRYPTO.DES_CBC_PKCS5)
4353
PL/SQL procedure successfully completed.
Чтобы в точности воспроизвести пример с DBMS_OBFUSCATION_TOOLKIT выше, нужно будет дополнять шифруемую строку нулями, и тогда вместо
TYP => DBMS_CRYPTO.DES_CBC_PKCS5
указать
TYP => DBMS_CRYPTO.ENCRYPT_DES
+ DBMS_CRYPTO.CHAIN_CBC
+ DBMS_CRYPTO.PAD_ZERO
Упражнение. Проверить, что алгоритм DES реализован в обоих пакетах идентично, зашифровав строку процедурой DESENCRYPT пакета DBMS_OBFUSCATION_TOOLKIT, а расшифровав функцией DECRYPT пакета DBMS_CRYPTO.
Тем не менее, современная технология не рекомендует на практике дополнять строку нулями, а советует пользоваться схемой дополнения PKCS5.
Пример указания алгоритма шифрования AES ключом в 128 разрядов:
TYP => DBMS_CRYPTO.ENCRYPT_AES128
+ DBMS_CRYPTO.CHAIN_CBC
+ DBMS_CRYPTO.PAD_PKCS5
Прочие возможности пакета DBMS_CRYPTO приведены в документации.
| INTERFACE Ltd. |
| ||||