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

Самый большой кошмар вашей организации: кто-то украл ленты с резервной копией вашей базы данных. Несомненно, вы построили защищенную систему, зашифровали наиболее конфиденциальные ресурсы, разместили серверы баз данных за межсетевыми экранами. Но вор выбрал доступный ему способ: он взял ленты с резервной копией, чтобы, вероятно, скопировать вашу базу данных на другом сервере, запустить экземпляр сервера этой базы данных, а затем не спеша просмотреть все ваши данные. Защита содержимого базы данных от такого воровства представляет собой не только хорошую практику; это – требование многих нормативно-правовых и нормативно-технических документов. Как же вы можете защитить вашу базу данных от этой опасности?

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

Новая функциональная возможность сервера Oracle Database 10g Release 2 позволяет вам сделать это: вы можете объявить столбец шифруемым, не написав при этом никаких строк кода приложения. Когда пользователи вставляют данные, сервер базы данных прозрачно шифрует эти данные и сохраняет их в столбце. Точно так же, когда пользователи выбирают этот столбец, сервер базы данных автоматически расшифровывает его. Так как все это делается прозрачно без какого-либо изменения кода приложения, эта функциональная возможность имеет соответствующее название: прозрачное шифрование данных (TDE, Transparent Data Encryption).

Как это работает

Основы шифрования в сервере Oracle Database 10g я изложил в статье "Encrypt Your Data Assets", опубликованной в журнале Oracle Magazine, январь-февраль 2005 г. (прим. пер.: имеется русский перевод – "Шифруем свои ресурсы данных"). Повторяем основные положения: для шифрования входных данных с обычным текстом вам нужно применять алгоритм и ключ шифрования; для успешного дешифрования зашифрованного текста вы должны знать этот же алгоритм и ключ.

В той статье я описал, как строить инфраструктуру шифрования с помощью инструментов шифрования, поставляемых на дистрибутиве Oracle. В среде сервера Oracle Database 10g Release 2 и шифрования TDE, однако, вам не нужно создавать эту инфраструктуру. Все, что вы должны сделать – определить столбец, который будет шифроваться, и сервер Oracle Database 10g создаст криптографически стойкий ключ шифрования для таблицы, содержащей этот столбец, и зашифрует данные обычного текста в этом столбце, используя указанный вами алгоритм шифрования. Защита этого ключа таблицы имеет очень важное значение; сервер Oracle Database 10g шифрует его, используя главный ключ, который хранится в безопасном месте, называемом бумажником (wallet), который может быть файлом сервера базы данных. Зашифрованные ключи таблиц размещаются в словаре данных. Когда пользователь вставляет данные в столбец, определенный как зашифрованный, сервер Oracle Database 10g извлекает из бумажника главный ключ, расшифровывает ключ шифрования для этой таблицы, находящийся в словаре данных, использует этот ключ для шифрования входного значения и сохраняет зашифрованные данные в базе данных, как показано на рис. 1.

Надписи на рисунке:

• Data Dictionary – словарь данных;
• Encrypted Table Key – зашифрованный ключ таблицы;
• Master Key – главный ключ;
• Decrypted – расшифрованный;
• Wallet (outside the DB) – бумажник (за пределами базы данных);
• Decrypted Table Key – расшифрованный ключ таблицы;
• Column – столбец;
• Clear Text – обычный текст;
• Encrypted – зашифрованный;
• Table – таблица;
• Database – база данных.

Вы можете шифровать любой или все столбцы таблицы. Если таблица имеет четыре столбца и столбцы 2 и 3 шифруются (как это показано на рис. 1), сервер Oracle Database 10g генерирует один зашифрованный ключ таблицы и использует его для шифрования этих столбцов. На диске значения столбцов 1 и 4 хранятся в виде обычного текста, а значения двух других столбцов – в шифрованном формате. Данные хранятся зашифрованными, поэтому все компоненты нижнего уровня, такие, как резервные копии и архивные журнальные файлы, также имеют шифрованный формат.

Когда пользователь выбирает зашифрованные столбцы, сервер Oracle Database 10g прозрачно извлекает из словаря данных зашифрованный ключ таблицы, а главный ключ – из бумажника и расшифровывает ключ таблицы. Затем сервер базы данных расшифровывает зашифрованные на диске данные и возвращает пользователю обычный текст.

Благодаря такому шифрованию, если данные будут украдены с диска, они не могут быть извлечены без главного ключа, который находится в бумажнике, не входящим в украденные данные. Даже если украден и бумажник, главный ключ не может быть извлечен из него без знания пароля бумажника. Следовательно, вор не сможет расшифровать данные, даже если он украл диски или копии файлов данных. Это удовлетворяет требованиям соответствия многим нормативным и руководящим документам. И все это было сделано без изменения приложения или написания сложной системы шифрования и управления ключами. Теперь я покажу вам, как включать TDE и использовать его возможности.

Одноразовая настройка

Перед тем, как начать использовать возможности TDE, вы должны определить местоположение бумажника, установить его пароль и открыть бумажник.

1. Определите местоположение бумажника.

Перед включением возможностей TDE вы должны создать бумажник, в котором будет храниться главный ключ. По умолчанию бумажник создается в каталоге $ORACLE_BASE/admin/$ORACLE_SID/wallet. Так, если $ORACLE_BASE –/u01/app/oracle, а $ORACLE_SID – SWBT4, то бумажник будет храниться в каталоге /u01/app/oracle/admin/swbt4/wallet. Вы можете также выбрать другой каталог, указывая его в файле sqlnet.ora, который находится в каталоге $ORACLE_HOME/network/admin. Например, если вы хотите, чтобы бумажник находился в каталоге /orawall, вставьте в файл sqlnet.ora следующие строки:

ENCRYPTION_WALLET_LOCATION =
 (SOURCE=
   (METHOD=file)
     (METHOD_DATA=
       (DIRECTORY=/orawall)))

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

2. Создайте бумажник.

Теперь вы должны создать бумажник и установить пароль для доступа к нему. Для этого как пользователь с привилегией ALTER SYSTEM выполните следующий оператор:

alter system set encryption key 
authenticated by "remnant";

Этот оператор:

• создает бумажник в каталоге, который был определен на шаге 1;
• устанавливает пароль бумажника – "remnant";
• открывает бумажник для хранения и извлечения главного ключа средствами TDE.

Пароль зависит от регистра, и его необходимо заключать в двойные кавычки. Заметим, пароль "remnant" не показывается в виде обычного текста ни в каких динамических представлениях производительности или журнальных файлах.

Откройте бумажник

Бумажник создается только один раз, поэтому вы больше не должны повторять два предыдущих шага. Тем не менее после запуска экземпляра сервера базы данных бумажник необходимо открывать явно. Когда вы создаете бумажник (как выше на шаге 2), вы также открываете бумажник для работы с ним. После создания бумажника и установки его пароля каждый раз, когда вы открываете базу данных, вы должны открывать и бумажник, используя его пароль:

alter system set encryption wallet open authenticated by "remnant";

Вы можете закрывать бумажник, используя оператор:

alter system set encryption wallet close;

Чтобы средства TDE работали, бумажник должен быть открытым. В противном случае, вы сможете получить доступ только ко всем незашифрованным столбцам, но не к зашифрованным.

Зашифруйте столбцы

Чтобы шифровать столбцы, используя средства TDE, все, что вы должны сделать, это добавить к определениям столбцов простое предложение – ENCRYPT. А до этого вы должны решить, какой вы будете использовать тип шифрования и длину ключа. Для детального обсуждения этой проблемы обратитесь к моей статье "Шифруем свои ресурсы данных", упомянутой выше.

Предположим, что у вас в обычной схеме имеется таблица владельцев банковских счетов ACCOUNTS, определенная следующим образом:

ACC_NO      NUMBER
ACC_NAME    VARCHAR2(30) 
SSN         VARCHAR2(9)

В настоящее время все данные этой таблицы хранятся в виде обычного текста. Вы хотите преобразовать столбец SSN (Social Security Number, номер социального страхования), чтобы он хранился в зашифрованном виде. Для этого вы можете выполнить оператор:

alter table accounts modify (ssn encrypt);

Этот оператор делает две вещи:

• создает ключ шифрования для таблицы. Если вы измените другой столбец этой же таблицы, чтобы он также хранился в зашифрованном виде, будет использоваться этот же ключ таблицы;
• преобразовывает все значения столбца SSN в зашифрованный формат.

Этот оператор не изменяет тип данных или размер столбца, и он также не создает никаких триггеров или представлений.

По умолчанию для шифрования используется алгоритм AES (Advanced Encryption Standard, усовершенствованный стандарт шифрования) с 192-битовым ключом. Вы можете также выбрать другой алгоритм, указывая в операторе соответствующее дополнительное предложение.

Например, чтобы использовать 128-битовое шифрование по алгоритму AES, вы можете выполнить оператор:

alter table accounts modify (ssn encrypt using 'AES128');

Вы можете использовать предложения AES128, AES192, AES256 или 3DES168 (168-bit Triple DES , трехкратное применение алгоритма DES (Data Encryption Standard, стандарт шифрования данных) с 168-битовым ключом).

После шифрования столбца вы увидите в описании таблицы следующее:

SQL> desc accounts

Name           Null?          Type
------------   ------------   --------------------------
ACC_NO         NUMBER
ACC_NAME       VARCHAR2(30)
SSN            VARCHAR2(9)    ENCRYPT

Обратите внимание на ключевое слово ENCRYPT, указанное после типа данных. Для поиска в базе данных зашифрованных столбцов можно воспользоваться представлением словаря данных DBA_ENCRYPTED_COLUMNS. (Средства TDE нельзя применять к таблицам схемы SYS.)

Вопросы производительности

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

alter table account modify (ssn decrypt);

Также проанализируйте использование индексов. Предположим, в вышерассмотренном примере есть индекс столбца SSN с именем in_accounts_ssn. Если запрос к таблице ACCOUNTS имеет предикат равенства:

select * from accounts 
where ssn = '123456789';

то индекс in_accounts_ssn используется. Если же в запросе указан предикат LIKE:

select * from accounts 
where ssn like '123%';

то индекс будет игнорироваться и будет использоваться полный просмотр таблицы. Причина проста. Структура B-дерева индекса гарантирует, что значения с совпадающими первыми символами физически размещаются близко друг от друга. Обрабатывая предикат LIKE, сервер Oracle Database 10g ищет записи индекса, сопоставимые с образцом, и физическая близость помогает ускорить поиск по индексу, который выполняется быстрее полного просмотра таблицы.

Однако если столбец зашифрован, фактические значения в индексе будут совсем другими (поскольку они зашифрованы), и, следовательно, разбросаны по всему индексу. Это делает просмотры индекса более дорогими по сравнению с полными просмотрами таблиц. Поэтому в этом примере запроса с предикатом LIKE сервер Oracle Database 10g будет игнорировать индекс и выполнять полный просмотр таблицы.

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

Управление ключами и паролями

Что, если кто-то узнал ваши ключи таблиц, или вы подозреваете, что кто-то, возможно, расшифровал зашифрованные ключи таблиц? В этом случае вы можете просто, используя несложный оператор, создать новый ключ для таблицы или, другими словами, сменить ключ таблицы (rekey table), и вновь создать зашифрованные значения столбцов, используя этот новый ключ таблицы. Делая это, вы можете также выбрать другой алгоритм шифрования, такой, как AES256. Вы можете сделать все это следующим образом:

alter table accounts rekey using 'aes256';

Что, если кто-то узнал пароль бумажника? Вы можете изменить его с помощью диспетчера бумажников Oracle Wallet Manager. Для запуска этого графического инструмента введите в командной строке OWM (см. рис. 2). В главном меню выберите Wallet -> Open (бумажник -> открыть) и выберите местоположение бумажника, которое вы определили, а затем задайте пароль бумажника. После этого для изменения пароля выберите Wallet -> Change Password (бумажник -> изменить пароль). Заметим, что изменение пароля бумажника не изменяет ключи.

См. Рисунок 2

Хотите добавить к данным "соль"?

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

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

alter table accounts modify 
(ssn encrypt no salt);

Если вы попытаетесь создать индекс по столбцу, который зашифрован с "солью", вы получите ошибку:

SQL> create index in_acc_01 
on accounts (ssn);

ORA-28338: cannot encrypt indexed column(s) with salt 

(нельзя шифровать с "солью" индексированный столбец (столбцы))

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

Использование утилит Data Pump в среде TDE

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

$ expdp arup/arup tables=accounts

ORA-39173: Encrypted data has been stored unencrypted in dump file set

(зашифрованные данные сохранены в наборе дамп-файлов незашифрованными)

Это – только предупреждение, не ошибка; строки будут экспортироваться.

Для защиты ваших данных зашифрованных столбцов в дамп-файлах утилиты EXPDP вы может при экспорте таблицы защитить эти дамп-файлы паролем. Этот пароль, задаваемый параметром ENCRYPTION_PASSWORD в команде EXPDP, применяется только в этом процессе экспорта; это не пароль бумажника. На листинге 1 показана команда EXPDP, выполняемая с паролем "pooh". Обратите внимание, что в выводе этой команды на листинге 1 не показан пароль "pooh" – он скрыт строкой звездочек. Результирующий дамп-файл для столбцов, зашифрованных средствами TDE, не будет иметь видимых данных в обычном тексте.

$ expdp arup/arup ENCRYPTION_PASSWORD=pooh tables=accounts
 
Export: Release 10.2.0.0.0 - Beta on Friday, 01 July, 2005 16:14:06
 
Copyright (c) 2003, 2005, Oracle.  All rights reserved.
 
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.0.0 - Beta
With the Partitioning, OLAP and Data Mining options
Starting "ARUP"."SYS_EXPORT_TABLE_01":  arup/******** ENCRYPTION_PASSWORD=********* tables=accounts 
Estimate in progress using BLOCKS method...
Processing ...

При импорте этого зашифрованного дамп-файла вы должны будете предоставить тот же самый пароль, который был использован при экспорте, как это показано на листинге 2.

$ expdp arup/arup ENCRYPTION_PASSWORD=pooh tables=accounts
 
Export: Release 10.2.0.0.0 - Beta on Friday, 01 July, 2005 16:14:06
 
Copyright (c) 2003, 2005, Oracle.  All rights reserved.
 
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.0.0 - Beta
With the Partitioning, OLAP and Data Mining options
Starting "ARUP"."SYS_EXPORT_TABLE_01":  arup/******** ENCRYPTION_PASSWORD=********* tables=accounts 
Estimate in progress using BLOCKS method...
Processing ...

Если при импорте вы опустите параметр ENCRYPTION_PASSWORD, результат будет следующим:

$ impdp arup/arup tables=accounts

ORA-39174: Encryption password must 
be supplied

(должен быть указан пароль шифрования).

Если вы укажете неправильный пароль, результат будет следующим:

$ impdp arup/arup ENCRYPTION_PASSWORD
=piglet tables=accounts

ORA-39176: Encryption password is 

incorrect

(неправильный пароль шифрования).

Первоначальная утилита экспорта (EXP) не может экспортировать таблицы с зашифрованными столбцами.

Заключение

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

 

ЧИТАЙТЕ более подробно о шифровании
Шифруем свои ресурсы данных
Protect from Prying Eyes: Encryption in Oracle 10g

более подробно о прозрачном шифровании данных
Oracle Database Advanced Security Administrator's Guide

---

Арап Нанда (Arup Nanda) ( arup@proligence.com ) – главный администратор баз данных компании Starwood Hotels and Resorts (White Plains, New York). Он – соавтор книги Oracle Privacy Security Auditing (издательство Rampant TechPress, 2003) – "Средства аудита в СУБД Oracle, обеспечивающие информационную безопасность".