Как можно использовать прозрачное шифрование данных(TDE) и развить этот метод.
Ключевые слова: Oracledatabase, encryption, dataprivacy, Прозрачное шифрование данных, Расширяемое управление ключами.
Acknowledgements (Благодарности)
I would like to express my sincere gratitude to ministry of higher education and scientific research Iraqi, for her valuable guidance. That provided me this scholarship in addition to the financial and moral support in order to complete my studies
Введение
Прозрачное шифрование данных (Transparent Data Encryption (TDE) позволяет шифровать конфиденциальные данные, такие как номера кредитных карт, хранящиеся в таблицах и табличных областях. Зашифрованные данные явно расшифрованы для пользователя базы данных или приложения, которое имеет доступ к данным. TDE помогает защитить данные, хранящиеся на устройствах, в случае похищения носителя данных или файла данных. Oracle использует аутентификацию, авторизацию и механизмы проверки для защиты данных в базе данных, но не в файлах данных операционной системы, где хранятся данные. Для защиты этих файлов данных в Oracle предусмотрено TDE. TDE шифрует конфиденциальные данные, хранящихся в файлах данных. Для предотвращения несанкционированной расшифровки, TDE хранит ключи шифрования в модуле защиты внешне по отношению к базе данных.
Прозрачное шифрование данных
Средствами TDE обеспечивается шифрование данных перед записью на диск и расшифровывание данных, прежде чем они возвращаются в приложение. Процесс зашифровывания и расшифровывания выполняется на уровне SQL и полностью прозрачен для прикладных программ и пользователей. Резервные копии баз данных, записанные на диск или магнитную ленту, будут содержать эти данные в зашифрованном виде. TDE, при необходимости, может быть использовано в сочетании с Oracle RMAN для зашифровывания всей СУБД Oracle в ходе резервирования на диски.
Варианты использования TDE
TDE входит в состав опции Oracle Advanced Security с версии 10g. Позволяет «прозрачно» для приложений шифровать данные на уровне колонок таблиц или табличных пространств (с версии 11g).
TDE на уровне колонок
Работа TDE на уровне колонок выглядит следующим образом:
- приложение обращается к зашифрованной колонке;
- сервер БД определяет по словарю данных, что колонка зашифрована;
- сервер БД извлекает из словаря данных зашифрованный ключ шифрования
Данной колонки;
- сервер БД расшифровывает ключ шифрования колонки с помощью мастер-ключа;
- сервер БД расшифровывает или зашифровал данные ключом колонки в зависимости от типа доступа (чтение/запись).
Рис. 1. Шифрование с помощью TDE на уровне колонок
Условия для прозрачного шифрования на уровне колонки:
- должен быть создан wallet;
- в wallet должен быть создан мастер-ключ;
- wallet с мастер-ключом должен быть «открыт», т. е. сделан доступным для сервера БД;
- колонки таблиц должны быть зашифрованы.
TDEна уровне табличных пространств
Работа TDE на уровне табличных пространств выглядит следующим образом:
- приложение обращается к колонке таблицы, размещённой на зашифрованном табличном пространстве;
- сервер БД извлекает из словаря данных зашифрованный ключ шифрования данного табличного пространства;
- сервер БД расшифровывает ключ шифрования табличного пространства с помощью мастер ключа;
- сервер БД читает зашифрованные блоки данных из файла, расшифровывает данные ключом табличного пространства и помещает в свой кэш для последующей обработки и отправки клиенту. В случае записи операция шифрования происходит непосредственно при записи блоков данных в файл.
Рис. 2.Шифрование с помощью TDE на уровне табличных пространств
Условия для прозрачного шифрования на уровне колонки:
- должен быть создан wallet;
- в wallet должен быть создан мастер-ключ;
- wallet с мастер-ключом должен быть «открыт», т. е. сделан доступным для сервера БД;
- табличное пространства должны быть зашифрованы.
Краткое описание управления ключами шифрования
TDE автоматически создает ключ шифрования, когда проводится зашифровывание данных столбца в таблице базы данных. Ключ шифрования — уникальный для каждой таблицы. Если в таблице зашифровывается более одного столбца, то для каждого из столбцов используется один и тот же ключ шифрования. Ключи шифрования для таблиц сохраняются в справочнике Oracle и зашифровываются при помощи первичного ключа (мастерключа) шифрования TDE. Первичный ключ шифрования сохраняется вне базы данных в «тубусе для ключей» Oracle Wallet (файл формата PKCS#12), который зашифрован с помощью пароля, определяемого администратором безопасности или DBA в процессе создания. Новым в Oracle Database 11g Advanced Security является возможность сохранять первичный ключ в устройстве HSM, используя PKCS#11 интерфейс.
Решение каких задач по плечу TDE?
Если злоумышленник смог получить доступ к защищаемым данным через SQL Server, то Transparent Data Encryption (TDE) оказывается абсолютно бесполезным. Данные зашифрованы только на диске, а в памяти — нет. Зашифрованная база данных выглядит для пользователей абсолютно так же, как и незашифрованная.
Для защиты от администраторов Transparent Data Encryption (TDE) так же бессильно. Администратор SQL Server может шифрование просто отключить. Системный администратор при желании также сможет найти тысячу и один способ получить доступ к зашифрованным данным (даже если он не является администратором SQL Server).
Что реально может сделать Transparent Data Encryption (TDE), так это защитить файлы баз данных и резервные копии на случай их похищения. И это уже неплохо. Если снять копию с файлов активной БД не так просто (хотя и возможно), то похищение резервной копии при наличии к ним доступа не представляет никаких проблем (какие могут быть проблемы сунуть носитель с резервной копией в карман).
Но и тут есть свои ограничения. Файлы БД и резервные копии будут надежно защищены, только если злоумышленнику не удастся вместе с данными заполучить и ключ. Если ему это удастся, то он без проблем расшифрует секретные данные. Самым слабым звеном тут является главный ключ службы (SMK), который находится на вершине иерархии ключей и который защищается с помощью DPAPI. Подробнее об этом можно почитать в моем блоге (http://blogs.gotdotnet.ru/yliberman) в сообщении ”Вся правда о Service Master Key в SQL Server 2005”.
Также следует отметить, что Transparent Data Encryption (TDE) — это не замена тем криптографическим возможностям, которые есть в SQL Server 2005. Если шифрование в SQL Server 2005 работает на уровне значений и столбцов (за что часто называется ”cell-level”-шифрованием), то Transparent Data Encryption (TDE) работает на гораздо более высоком уровне — на уровне базы данных. Задачи, которые решаются с помощью обоих подходов во многом пересекаются, но у каждого из них есть свои преимущества и недостатки. Оба подхода используют одни и те же криптографические алгоритмы (с теми же длинами ключей), так что криптографически оба подхода обеспечивают одинаковый уровень защиты данных.
Прозрачное шифрование данных TDE
SQL Server 2008 предоставляет новую опцию шифрования, известную как прозрачное шифрование данных (transparent data encryption — TDE). TDE шифрует каждую страницу вашей базы данных и автоматически расшифровывает каждую страницу по мере обращения к ней. Это средство позволяет защитить всю базу данных, не беспокоясь о деталях шифрования на уровне столбцов. Кроме того, оно имеет дополнительное преимущество, позволяя защитить базу данных прозрачно, не внося изменений в интерфейсные приложения. TDE не требует дополнительного пространства для хранения и может генерировать намного более эффективные планы запросов, чем для запросов к данным, зашифрованным на уровне столбцов, поскольку TDE позволяет SQL Server использовать правильные индексы.
Отрицательной стороной средства TDE является то, что оно требует дополнительных накладных расходов, поскольку SQL Server вынужден расшифровывать страницы данных при каждом запросе. Чтобы включить TDE и зашифровать базу данных, вы должны сначала создать DMK и серверный сертификат в базе данных master. Второй шаг — создание ключа шифрования базы данных и включение шифрования в базе, которую вы хотите защитить. Алгоритмы, доступные оператору CREATE DATABASE ENCRYPTION KEY, ограничены представленными на слайде.
TDE предоставляет преимущество прозрачности шифрования для клиентских приложений и выполняет полную работу по защите данных. Недостатком TDE является то, что он сильно загружает процессор и память при каждом обращении к базе данных, поскольку при каждом доступе приходится расшифровывать целые страницы базы. TDE также шифрует базу данных tempdb, что может повлиять на производительность всех прочих баз в пределах одного экземпляра SQL Server.
Шифрование на уровне столбца обладает тем преимуществом, что обеспечивает исключительную точность и дополнительную гибкость при защите данных. Главные аргументы против заключаются в том, что шифрование на уровне столбца требует дополнительного программирования, так что вам может понадобиться изменить существующие клиентские приложения, а, кроме того, этот способ не позволяет эффективно использовать индексы на шифрованных данных, чтобы оптимизировать запросы.
При выборе стратегии шифрования ваших баз данных рекомендуется тщательно взвешивать все за и против TDE и шифрования уровня столбцов.
Расширяемое управление ключами
В дополнении к TDE, SQL Server 2008 включает новое средство — расширяемое управление ключами (extensible key management — EKM). EKM позволяет использовать программный интерфейс Microsoft Cryptographic API (CryptoAPI) для шифрования и генерации ключей.
Поддержка EKM предназначена для того, чтобы позволить независимым поставщикам предлагать оборудование генерации ключей — аппаратные модули безопасности (hardware security modules — HSM). Поставщики HSM могут предлагать массу преимуществ перед стандартной встроенной функциональностью шифрования, включая аппаратное ускорение шифрования и дешифрации, пакетное шифрование и дешифрацию. HSM может представлять собой смарт-карту, устройство USB, флэш-карту или специализированный внешний модуль.
Заключение
Защита ваших данных от атак и соблюдение бесчисленных законов, которые регламентируют бизнес, — не тривиальная задача. Средства TDE позволяют вам безотлагательно обеспечить шифрование данных и соответствие нормативным документам без какого-либо кодирования и сложности управления ключами, так что вы можете сосредоточиться на задачах своей работы, для решения которых необходим более сложный стратегический подход. Встроенные в СУБД Oracle алгоритмы криптографии, применяемой для защиты данных, ключей шифрования, контроля целостности не соответствуют требованиям законодательства РФ.
Литература:
1. Петрова Т. М., Дмитриева Л. Н. Методические указания по теории механизмов и машин «Кинематический и силовой расчет механизма», М., МАМИ, 1990г.
2. Соболева Т. А. Введение // История шифровального дела в России. — М.: ОЛМА-ПРЕСС Образование, 2002. — 512 с. — (Досье). — 5 000 экз. — ISBN 5–224–03634–8
3. Гатчин Ю. А., Коробейников А. Г. Основы криптографических алгоритмов. Учебное пособие. — СПб.: СПбГИТМО(ТУ), 2002.
4. Иванов М. А. Криптографические методы защиты информации в компьютерных системах и сетях. — М.: КУДИЦ-ОБРАЗ, 2001, — 368 с.
