Если вы храните ключ шифрования и зашифрованные данные в базе данных, то возникает еще одна потенциальная угроза безопасности. При краже дисков, на которых хранится вся база данных, все данные сразу же рассекречиваются. Для того чтобы обойти эту проблему, следует хранить ключ отдельно, вне диска, на котором хранятся зашифрованные этим ключом данные.
Если ваша база данных полностью изолирована, вы, возможно, не видите смысла в шифровании данных. Однако вы можете захотеть обезопасить себя от кражи диска. В качестве одного из решений можно предложить создание представления для отображения расшифрованного значения. В этом случае, если ключ хранится отдельно, физическая кража диска не приведет к рассекречиванию данных. Данный подход возможен, но требует тщательной, трудоемкой настройки.
Для разрешения подобных ситуаций в Oracle 10^ Release 2 введена новая возможность прозрачного шифрования данных (Transparent Data Encryption - TDE). TDE использует сочетание двух ключей: мастер- ключ хранится вне базы данных в «бумажнике», кроме того, есть еще ключ для каждой таблицы. Для всех строк таблицы используется один и тот же ключ, ключ каждой таблицы уникален (рис. 4.7).
TDE подразумевает, что вы задаете подмножество столбцов для шифрования. Например, если в таблице 4 столбца, как показано на рис. 4.7, и шифруются столбцы 2 и 3, то Oracle сгенерирует ключ и использует его для шифрования данных столбцов. На диске столбцы 1 и 4 будут сохранены в открытом виде, а два других столбца - в зашифрованном.
При выборе пользователем зашифрованных столбцов Oracle незаметно извлекает ключ из «бумажника», расшифровывает столбцы и показывает их пользователю. Если диск с данными похищен, их невозможно извлечь без ключей, которые хранятся в «бумажнике», зашифрованном мастер-ключом, который и сам сохранен не в виде открытого текста. В результате вор не сможет расшифровать данные, даже если украдет диски или скопирует файлы.
Задача Transparent Data Encryption (TDE) состоит в обеспечении защиты данных, хранящихся на таких носителях, как диски и магнитные ленты, которая необходима в соответствии со многими национальными или международными нормативными документами и правилами, такими как Sarbanes-Oxley, HIPAA, Visa Cardholder Information Security Program и т. д.
TDE не является полномасштабной системой шифрования и не должна использоваться в таком качестве. Например, обратите внимание на то, что зашифрованные столбцы расшифровываются в любом случае, вне зависимости от того, кто выбирает данные, что вряд ли удовлетворяет вашим требованиям безопасности. Для получения комплексного решения следует создать собственный инструмент, используя описанные в главе приемы.
Для того чтобы воспользоваться преимуществами TDE, добавьте предложение ENCRYPT (доступное только в Oracle 10^ Release 2) для каждого шифруемого столбца в оператор создания вашей таблицы:
В данном случае столбцы SSN и FOLIO_ID шифруются при помощи AES- алгоритма со 128-битным ключом. Предложение ENCRYPT USING в определении столбца указывает на необходимость перехвата значений в виде открытого текста, их шифрования и сохранения в зашифрованном виде. Когда пользователь выбирает данные из таблицы, значение неявно (прозрачно) расшифровывается.
Нельзя использовать прозрачное шифрование в таблицах, принадлежащих пользователю SYS.
Прежде чем начать использовать TDE, необходимо создать «бумажник», в котором будет храниться мастер-ключ, и обеспечить его безопасность. Рассмотрим процесс управления «бумажниками» пошагово. 1. Выбрать местоположение «бумажника».
Данный оператор выполняет три действия:
a. Создает «бумажник» в каталоге, определенном в шаге 1.
Перед первым применением TDE необходимо создать «бумажник», в котором будет храниться мастер-ключ. По умолчанию «бумажник» создается в каталоге $ORACLE_BASE/admin/$ORACLE_SID/wallet. Вы можете выбрать другой каталог, указав его в файле SQLNET.ORA. Например, если вы хотите, чтобы «бумажник» хранился в каталоге /orac- le_wallet, добавьте приведенные ниже строки в файл SQLNET.ORA. В нашем случае я буду считать, что выбран каталог по умолчанию.
Убедитесь в том, что «бумажник» включен в процесс резервного копирования. 2. Установить пароль для «бумажника».
Теперь вам нужно создать «бумажник» и указать пароль для доступа к нему. Все это можно сделать, выполнив один оператор:
Устанавливает для «бумажника» пароль - «pooh».
Открывает «бумажник» для сохранения и извлечения ключей средствами TDE.
Пароль является регистрозависимым и должен заключаться в двойные кавычки.
3. Открыть «бумажник».
Вы можете закрыть «бумажник» следующей командой:
На предыдущем шаге бумажник был открыт для работы с ним. Однако после того как бумажник создан, вам не придется пересоздавать его. После запуска базы данных вам нужно будет только открыть «бумажник», используя установленный пароль:
Открытие «бумажника» необходимо для работы средств TDE. Если «бумажник» не открыт, то все незашифрованные столбцы будут доступны, а зашифрованные столбцы - недоступны.
В качестве параметров также можно было бы указать AES128, AES256 или 3DES168 (для трехпроходного механизма DES со 168-битным ключом). Посмотрим на таблицу после шифрования столбца:
В предыдущем разделе мы видели, как можно использовать TDE при создании новой таблицы. Так же можно зашифровать столбец существующей таблицы. Для шифрования столбца SSN таблицы ACCOUNTS используем такой оператор:
Создает ключ для столбца SSN.
Преобразует все значения столбца в зашифрованный формат.
Шифрование выполняется внутри базы данных. По умолчанию используется алгоритм AES со 192-битным ключом. Вы можете выбрать другой алгоритм шифрования, указав его название в операторе. Например, чтобы выбрать алгоритм AES со 128-битным ключом, используйте такой оператор:
Обратите внимание на ключевое слово ENCRYPT после типа данных. Для поиска зашифрованных столбцов базы данных используйте новое представление словаря данных DBA_ENCRYPTED_COLUMNS.
А как обстоит дело с производительностью при работе с TDE? При обращении к незашифрованным столбцам никаких дополнительных накладных расходов не возникает. При обращении к зашифрованным столбцам можно ожидать небольшого увеличения накладных расходов. Если потребность в шифровании пропадает, его можно отключить следующим образом:
Что будет, если кто-то каким-то образом узнает ваши TDE-ключи? Можно пересоздать зашифрованные значения, выполнив всего один оператор. В этом операторе можно также выбрать другой алгоритм шифрования, например AES256:
Если кто-то узнает пароль «бумажника», вы можете изменить его, используя программу Oracle Wallet Manager. Введите owm в командной строке, и диспетчер «бумажников» будет запущен (рис. 4.8). Выберите в главном меню Wallet Open и укажите место хранения «бумажника» и его пароль. Для изменения пароля выберите Wallet Change Password. Имейте в виду, что изменение пароля не приводит к изменению ключей.
Шифрование предназначено для сокрытия данных, но бывает так, что зашифрованные данные легко угадать из-за повторений в исходных данных. Например, таблица с информацией о зарплатах весьма вероятно содержит повторяющиеся значения. В этом случае зашифрованные значения также будут одинаковыми. Даже если злоумышленник не сможет расшифровать реальные значения, он сможет определить, в каких записях присутствуют одинаковые зарплаты, а эта информация может быть значимой. Для предотвращения таких ситуаций к данным добавляется соль (salt), благодаря которой зашифрованные значения будут различаться даже для одинаковых исходных данных. TDE использует соль по умолчанию.
В некоторых случаях структуры данных могут способствовать повышению производительности базы данных, а добавление «соли» может ее ухудшить. Например, индексы b-tree ускоряют поиск по условию LIKE, как в следующем запросе:
В данном случае индексам b-tree для получения данных придется пройти только по одной ветви дерева, так как все номера счетов начинаются с цифр 123. Если «соль» добавлена, то реальные значения будут распределены по всей структуре b-tree, что сделает просмотр индекса более трудоемким, и весьма вероятно, что оптимизатор выберет полный просмотр таблицы. В этом случае придется убрать «соль» из индексированных столбцов, например, так:
ALTER TABLE accounts MODIFY (ssn ENCRYPT NO SALT);
Удаление «соли» незначительно влияет на безопасность, поэтому, скорее всего, возможная уязвимость не перевешивает того повышения производительности, которое обеспечивается индексированием.
Использование средств TDE невозможно для столбцов, обладаю
щих одним из приведенных ниже свойств:
Тип данных BLOB или CL0B.
Использование в индексах, отличных от обычных индексов b-tree, таких как bitmap-индексы, индексы на основе функций и т. д.
Использование в ключах секционирования.
Отсутствие возможности использования средств TDE в подобных случаях является еще одной причиной, по которой TDE не может использоваться для всех видов шифрования.
Шифрование обеспечивает доступ к вашим данным только авторизованным пользователям. Это достигается за счет маскировки секрет-
ных данных. Однако в некоторых случаях в маскировке нет необходимости, хочется лишь защитить данные от изменения. Предположим, вы сохранили информацию о платежах вашим поставщикам. Сами по себе данные не настолько секретны, чтобы их шифровать, но хочется иметь уверенность в том, что никто не изменит цифры, с тем чтобы увеличить размер платежа. Как это сделать? Ответом является криптографическое хеширование. Давайте начнем знакомство с ним с примера из реальной жизни.
Предположим, что вы оставили свой сэндвич на столе, когда пошли забрать из факсимильного аппарата важный документ. Вернувшись, вы замечаете, что сэндвич несколько сдвинут влево. Кто-то трогал ваш сэндвич, возможно, подложив в него барбитуратов, чтобы вывести вас из игры и завладеть вашей новой чудесной беспроводной мышью? А может быть, он охотился на книгу по PL/SQL, спрятанную в ящике стола? А может быть, в сэндвиче если не наркотики, так песок? В мозгу прокручивается множество вариантов произошедшего, и есть уже не хочется.
Чтобы развеять свои сомнения, вы решаете проверить целостность сэндвича. Вы настолько осторожны и предусмотрительны, что заранее взвесили свой сэндвич и записали его вес с точностью до десятого знака после запятой. Опасаясь возможного изменения сэндвича, вы снова взвешиваете его и сравниваете результаты. Полное совпадение, вплоть до 10 знака после запятой. Какое облегчение! Если бы кто-то действительно что-то сделал с сэндвичем (например, добавил в него песка или барбитуратов), его вес обязательно бы изменился, свидетельствуя о вмешательстве.
Будем аккуратны с терминологией. Вы не «прятали» сэндвич (то есть не зашифровывали его); вы просто придумали собственный способ вычисления определенного значения, сопоставленного данному сэндвичу. И сравнили начальное и конечное значения. Исследуемое значение могло быть получено с помощью любого алгоритма; в данном случае вы выбрали взвешивание сэндвича.
Если бы речь шла о данных, а не о бутерброде с мясом, вы также могли бы получить некоторое значение по определенному алгоритму. Такой процесс называется хешированием. Отличие хеширования от шифрования в том, что хеширование - это однонаправленный процесс. Вы можете расшифровать зашифрованные данные, но «расхешировать» хеш-значение невозможно. Если вы несколько раз хешируете один и тот же элемент данных, результат будет неизменным при любом количестве выполнений. Если данные каким-то образом меняются, генерируемое хеш-значение изменится, свидетельствуя о «порче» данных.
Теоретически всегда есть риск того, что у двух разных элементов данных окажутся одинаковые хеш-значения, но такую вероятность можно минимизировать, используя достаточно изощренные алгоритмы хеши
рования. Одним из таких алгоритмов является MD (Message Digest - дайджест сообщений). Одна из разновидностей этого алгоритма - MD5, некоторое время была стандартом, но оказалось, что она не обеспечивает достаточной защищенности данных. Сейчас более распространенным является новый стандарт SHA-1 (алгоритм безопасного хеширования - версия 1, Secure Hash Algorithm Version 1), который доступен в Oracle 10g.
| < Предыдущая | Следующая > |
|---|
