Пакет DBMS OBFUSCATION TOOLKIT 1683

Эта возможность протокола Net8 обеспечивает шифрование всего потока данных, так что никто не сможет перехватить ключи при передаче по сети.

Если ключ безопасно хранится в клиентском приложении (это должны обеспечить вы сами) и используется ASO, это решение будет вполне надежным.

Хранение ключей в той же базе данных

Предполагается хранение ключей вместе с данными в базе. Это решение - не идеально, поскольку есть вероятность, что при наличии достаточного времени администратор базы данных (или хакер, получивший привилегии учетной записи администратора) сможет найти ключи и получить зашифрованные с их помощью данные. В подобных случаях следует максимально затруднить поиск ключей, соответствующих данным. Сделать это сложно, поскольку и ключи, и данные хранятся в одной базе.

Приложение не должно напрямую связывать таблицу ключей с таблицей данных. Предположим, имеется таблица со столбцами CUSTOMER ID, CREDIT CARD и другими данными. Столбец CUSTOMER ID неизменен - это первичный ключ (а мы знаем, что изменять первичный ключ не стоит). Можно создать другую таблицу:

ID number primary key, ЗА varchar2(255)

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

Пакет будет предоставлять две основные функции.

Функция 1: добавление нового клиента. В данном случае функция будет выполнять некоторые действия с идентификатором клиента, чтобы скрыть его (преобразовать в другую строку). Функция должна быть детерминированной, чтобы по заданному идентификатору клиента всегда выдавалась одна и та же строка. Чуть позже мы поговорим о том, что делать с идентификатором клиента или любой другой строкой. Для клиента также генерируется случайный ключ. Ниже представлен ряд способов генерации этого ключа. Затем с помощью динамического SQL строка вставляется в таблицу ключей. (Не стоит называть таблицу KEY TABLE или еще как-нибудь, чтобы по имени было понятно ее назначение.)

Функция 2: получение ключа для клиента. Функция принимает идентификатор клиента, пропускает его через ту же детерминированную функцию, что и предыдущая, а затем с помощью динамического SQL находит и возвращает ключ для клиента. Все это выполняется, только если текущий пользователь работает в соответствующей среде.

Динамический SQL используется для того, чтобы нельзя было понять, что пакет используется для управления ключами. Пользователь может обратиться к представлению ALL DEPENDENCIES и выяснить, на какие таблицы статически ссылается пакет. При использовании динамического SQL не будет никакой связи между пакетом и таблицей

1684

Приложение А

ключей. Это не позволит скрыть таблицу ключей от очень умного человека, но максимально затруднит ее поиск.

Теперь о том, как скрыть идентификатор клиента или любой набор неизменных данных в строке. (Первичный ключ для этого подходит только при условии, что всегда остается неизменным.) Для этого имеется множество алгоритмов. Если бы я использовал Oracle 8.1.7, то мог бы послать результат конкатенации этих данных с некоторым постоянным значением (его часто называют затравкой - salt ) функциям резюмирования по алгоритму MD5 для получения 16-байтовой контрольной суммы. Именно ее я бы использовал в качестве ключа. В Oracle 8.1.6 я мог бы использовать такое же действие, но передавал бы значение функции DBMS UTILITY.GET HASH VALUE с очень большим размером хеш-таблицы. Можно б1ло бы применить операцию XOR после изменения порядка байтов в CUSTOMER ID. Подойдет любой алгоритм, который сложно угадать по полученному результату.

Вы можете возразить, что администратор базы данных может прочитать код, увидеть алгоритм и разобраться во всем этом. Нет, если скрггь (wrap) код. Скрыть PL/SQL-код очень просто (см. описание утилиты WRAP в руководстве PL/SQL Users Guide and Reference). Она берет исходных код и шифрует его. В базу данных загружается зашифрованная версия кода. Теперь код никто прочитать не сможет. Средств дешифрации для wrap нет. Сохраните только в каком-либо безопасном месте текст алгоритма. Восстановить текст после применения утилиты wrap и получить исходный код из базы данных не удастся.

Для генерации ключа необходим своего рода генератор случайных строк. Его можно создать разными способами. Можно использовать те же приемы, что и для сокрытия значения CUSTOMER ID. Можно использовать реальный генератор случайных чисел (например, пакет DBMS RANDOM или собственной разработки). Задача в том, чтобы генерировать значение, которое будет сложно угадать на основе имеющейся информации.

Лично я предпочел бы хранить ключи именно в базе данных. Если ключи находятся в клиентском приложении, всегда остается риск их потери вследствие сбоя носителя или другой катастрофы в системе. При хранении ключей в файловой системе риск остается. Только хранение ключей в базе данных гарантирует, что зашифрованные данные всегда удастся расшифровать: база данных всегда синхронизирована, а процедуры резервного копирования и восстановления - надежны.

Хранение ключей в файловой системе сервера базы данных

Ключи шифрования данных можно также хранить в файловой системе сервера и обращаться к ним с помощью внешней процедуры на языке С. Я рекомендую использовать внешнюю процедуру на языке С, поскольку цель состоит в том, чтобы спрятать ключи от администратора базы данных, который обычно имеет доступ к учетной записи владельца программного обеспечения Oracle. Пакет UTL FILE, работа с объектами типа BFILE и вызов хранимых процедур на языке Java, выполняющих ввод-вывод, осуществляется с правами пользователя-владельца программного обеспечения Oracle. Если

Пакет DBMS OBFUSCATION TOOLKIT 1685

администратор базы данных работает с правами владельца программного обеспечения Oracle, он может прочитать файлы. А прочитав, сможет найти в них ключи. При использовании внешней процедуры, написанной на языке С, можно запустить службу EXTPROC (и соответствующий процесс прослушивания для службы EXTPROC) от имени другого пользователя. В этом случае пользователь Oracle не увидит ключи. К ним можно получить доступ только через процесс прослушивания EXTPROC. Это добавляет еще один уровень защиты. Подробнее о реализации этого подхода см. в главе 18.

Резюме

Мы достаточно подробно рассмотрели пакет DBMS OBFUSCATION TOOLKIT.

Я научил вас создать для него пакет-оболочку, предоставляющий те же функциональные возможности нужным образом (если моя реализация вам не подходит, напишите другую оболочку). Вы научились использовать динамический SQL для создания пакетов, которые можно устанавливать на серверах с разными возможностями (речь шла о возможностях шифрования в версиях 8.1.6 и 8.1.7). Мы обсудили проблему переноса данных на другую платформу при использовании пакета DMBS OBFUSCATION TOOLKIT, связанную с изменением порядка байтов в ключах. Вы узнали о возможности решать эту проблему переупорядочением байтов ключа. Интересным расширением пакета CRYPT PKG было бы автоматическое определение порядка байтов в системе и перестановка байтов в ключе, чтобы избавить пользователя от необходимости учитывать это различие. Эта идея становится еще более привлекательной, если учесть, что в версиях начиная с 8.1.7.1 менять порядок следования байтов больше не нужно - соответствующий код в этой версии можно не выполнять, что обеспечивает одинаковые функциональные возможности во всех версиях сервера.

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