Особенности защиты баз данных IBM DB2 и Oracle, страница 7

На последнем месте в списке значений поставлен номер метки 20200 (из предыдущего примера – метка ‘CONFIDENTIAL:HR:WEST’).

Альтернативой такому способу является использование функции CHAR_TO_LABEL. Данная функция имеет два входных параметра: имя правил доступа и имя (не номер!) метки. Пример использования:

INSERT INTO app.documents VALUES(1, 'SHARE_WARE', CHAR_TO_LABEL('DOC_POLICY', 'PUBLIC'));

Oracle Label Security является важным и удобным дополнением обычного дискреционного управления доступом. Главное удобство заключается в том, что защита секретной информации выполняется на уровне отдельных строк таблиц.

Шифрование данных

СУБД Oracle поддерживает шифрование данных при передаче между сервером и клиентами, шифрование содержимого таблиц БД и шифрование данных в процессе экспорта/импорта.

Шифрование трафика между клиентом и сервером выполняется с использованием симметричных криптографических алгоритмов. Установка защищенного соединения производится по протоколу SSL.

Защита данных в процессе экспорта/импорта сводится к шифрованию файлов, генерируемых и обрабатываемых утилитой Oracle Data Pump.

Для шифрования данных внутри БД до Oracle Database 10g Release 1 включительно использовались криптографические возможности инструментов DBMS_CRYPTO и DBMS_OBFUSCATION_TOOLKIT, содержавшие в себе функции зашифрования, дешифрования и управления ключами. В Oracle Database 10g Release 2 и далее используется прозрачное шифрование табличных пространств. Данная технология позволяет шифровать некоторые столбцы таблиц незаметно для пользователя, при выполнении операторов DML. Чтобы это было возможно, необходимо создать криптографический ключ и шифрованное табличное пространство. Любая таблица, создаваемая в шифрованном табличном пространстве, всегда будет хранить зашифрованные записи.

Резервное копирование баз данных

Концепция Oracle выделяет две разновидности резервного копирования [8.7]:

·  логическое – экспортирование данных с помощью утилиты Data Pump;

·  физическое – резервное копирование файлов данных или журналов транзакций.

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

Физическое резервное копирование может быть автономным и оперативным.

Автономное резервное копирование аналогично полному резервному копированию в SQL Server и DB2. Оно может быть выполнено только после отключения всех пользователей от БД. Однако автономное резервное копирование в Oracle предполагает копирование не только файлов данных, но и управляющих файлов, оперативных журналов повторов и, по желанию администратора, системных файлов  init.ora и spfile.ora.

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

Оперативное резервное копирование баз данных с большим объемом транзакций выполняется чаще, чем автономное резервное копирование и экспорт. Рекомендуется выполнять резервное копирование в моменты наименьшей активности пользователей, т. е. по ночам и по выходным. Для этого можно настроить систему резервного копирования Oracle на запуск в автоматическом режиме по заданному расписанию. Для БД с большим объемом транзакций рекомендуется выполнять оперативное копирование каждую ночь, а автономное копирование и экспорт – по выходным (еженедельно). Над БД, используемых преимущественно только для чтения, оперативное резервное копирование выполнять не нужно, а периодичность выполнения автономного копирования и экспорта зависит от объема БД.