Oracle DBA Forum  

Вернуться   Oracle DBA Forum > Oracle University Official Study Notes (RUS) > База данных Oracle 10g Администрирование > База данных Oracle 10g Администрирование II

Ответ
 
Опции темы Опции просмотра
  #1  
Старый 14.10.2009, 16:33
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию 15 Безопасность базы данных

__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #2  
Старый 14.10.2009, 16:35
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Рассматриваемые вопросы



Дополнительные источники информации

По адресу: http://www.oracle.com/technology/obe...r2_manage.html доступны следующие примеры использования возможностей Oracle (Oracle by Example - OBE) для версии 10g:

"Using Transparent Data Encryption"
"Restricting Data Access using Virtual Private Database"

Документация:

Oracle Database Security Guide
Oracle Database Advanced Security Administrator's Guide
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #3  
Старый 14.10.2009, 16:36
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Обзор прозрачного шифрования данных (TDE) в Oracle



Обзор прозрачного шифрования данных (TDE) в Oracle

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

Автоматическое шифрование важной информации

Большинство решений шифрования вызывает необходимость использования вызовов определенных функций шифрования внутри кода приложения. Это дорогие решения, так как они обычно требуют углубленного понимания не только приложения, но и возможностей написания и сопровождения программного обеспечения. Как правило, большинство организаций не имеют времени и опыта изменения существующих приложений и внесения в них вызовов программ шифрования. Oracle Transparent Data Encryption позволяет решить проблему шифрования с помощью встроенной в базу данных Oracle возможности шифрования.


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

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

Шифрование обычно вызывает проблемы для существующих индексов приложения, так как индексные данные не шифруются. Функциональная возможность Oracle Transparent Data Encryption шифрует индексные значения, связанные с данной таблицей приложения. Это означает, что в результате поиск по совпадению ключа лишь незначительно понизит производительность.


Использование ключа шифрования

Oracle Transparent Data Encryption предоставляет инфраструктуру управления ключами, необходимую для реализации шифрования. Шифрование производится путем передачи открытых текстовых данных вместе с секретным ключом (secret) в программу шифрования. Используя предоставленный ключ, программа шифрует открытые текстовые данные и возвращает зашифрованные данные. Обычно раньше за создание и сопровождение секрета (secret) или ключа отвечало приложение. Oracle Transparent Data Encryption решает эту задачу, автоматически генерируя главный ключ (master key) для всей базы данных. Сразу после старта БД Oracle администратор должен с помощью пароля открыть объект, называемый Oracle Wallet. Пароль должен отличаться от системного и пароля АБД. Объект wallet (цифровой бумажник) использует сертификат от уполномоченной стороны (Certificate Authority). После открытия цифрового бумажника администратор инициализирует главный ключ БД, который генерируется автоматически.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #4  
Старый 14.10.2009, 16:38
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Процесс TDE



Процесс TDE

Хотя механизмы авторизации и аутентификации эффективно защищают информацию базы данных, они не препятствуют доступу на уровне операционной системы к файлам, в которых хранятся данные. Возможность Transparent Data Encryption позволяет зашифровать важные данные, находящиеся в столбцах БД, и хранить их в зашифрованном виде в файлах операционной системы, делая невозможным выборку данных из файлов в открытом виде.

TDE использует внешний модуль безопасности (External Security Module - ESM) для генерации ключей шифрования, предоставления функций шифрования и дешифрования, а также для безопасного хранения ключей шифрования внутри и вне базы данных.

Для таблицы с шифруемыми столбцами используется единственный ключ столбцов (column key), независимо от количества шифруемых столбцов таблицы. Ключи для всех таблиц хранятся в единственном столбце таблицы словаря базы данных. Этот столбец шифруется с помощью главного ключа (master key) сервера баз данных, что препятствует несанкционированному доступу и использованию этих ключей. Главный ключ хранится в цифровом бумажнике (wallet) вне базы данных. Цифровой бумажник создается с помощью Oracle Wallet Manager, а главный ключ генерируется с помощью ESM.

На слайде представлена таблица EMPLOYEES, два столбца которой должны быть зашифрованы. Ключ столбцов для таблицы EMPLOYEES поступает от ESM и используется для шифрования этих столбцов. С помощью такого механизма можно шифровать и дешифровать столбцы в базе данных, используя простую команду ALTER TABLE. После того, как произведено шифрование столбцов, их содержимое можно получить в открытом виде, используя обычные команды SELECT (прозрачное дешифрование данных выполняет ESM).
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #5  
Старый 14.10.2009, 16:40
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Реализация прозрачного шифрования данных



Реализация прозрачного шифрования данных

Для реализации и конфигурирования этой возможности требуется выполнить небольшое число шагов:

1. Необходимо создать цифровой бумажник (wallet). Это можно сделать либо вручную, используя Oracle Wallet Manager, либо программное обеспечение Transparent Data Encryption (TDE) создаст его автоматически, если директория для цифрового бумажника указана в файле SQLNET . ORA. По умолчанию незашифрованный цифровой бумажник (cwallet. sso) создается при инсталляции базы данных.
Однако для TDE рекомендуется использовать зашифрованный цифровой бумажник (ewallet .р12).

Пример записи в файле SQLNET.ORA:

Код:
ENCRYPTION_WALLET_LOCATION= (SOURCE=(METHOD=FILE)(METHOD_DATA= (DIRECTORY=/opt/oracle/product/10.2.0/db_1/)))

Примечание: В файле sqlnet. ora можно найти две похожих записи: первая содержит параметр WALLET_LOCATION и используется для аутентификации по SSL (Secure Sockets Layer, протокол защищенных сокетов): вторая запись с параметром ENCRYPTION_WALLET_LOCATION задается ДЛЯ TDE.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #6  
Старый 14.10.2009, 16:42
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Реализация прозрачного шифрования данных (продолжение)



Реализация прозрачного шифрования данных (продолжение)

2. Необходимо сгенерировать главный ключ, который хранится в цифровом бумажнике. Главный ключ следует перегенерировать только в случае его несанкционированного раскрытия. Частая перегенерация главного ключа может привести к отсутствию доступного места в цифровом бумажнике. Вы можете установить или переустановить главный ключ, используя команду ALTER SYSTEM, как это показано на слайде. Если в вашей директории нет зашифрованного цифрового бумажника, команда создает зашифрованный бумажник (ewallet. р12). Кроме того, команда открывает бумажник, а также создает или пересоздает главный ключ для TDE.

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

4. Теперь можно создавать таблицы с шифруемыми столбцами. На слайде приводится пример создания таблицы ЕМР, содержащей шифруемые столбцы. По умолчанию столбцы шифруются с применением "соли или помехи" (salt). Использование "соли" -это метод, повышающий защиту шифруемых данных. Salt -случайная строка, добавляемая к данным перед тем, как они шифруются. Это усложняет для злоумышленника расшифровку данных, которую он выполняет путем сопоставления зашифрованного текста с известными образцами шифруемого текста. Однако "соль" нельзя использовать (NO SALT), если для зашифрованного столбца будет создаваться индекс.


Для TDE по умолчанию используется алгоритм AES (Advanced Encryption Standard -усовершенствованный стандарт шифрования) с 192-битовым ключом (AES192). Как показано в примере, вы можете выбрать другой алгоритм, например, 3DES (Triple Data Encryption Standard- трехкратное применение алгоритма DES).
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #7  
Старый 14.10.2009, 16:44
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Существующие таблицы и TDE



Существующие таблицы и TDE

Шифруемый столбец добавляется в существующую таблицу по команде ALTER TABLE ADD, в которой новый столбец указывается фразой ENCRYPT.

Существующие незашифрованные столбцы в таблице также можно зашифровать. Для этого используется команда ALTER TABLE MODIFY, в которой для незашифрованных столбцов задается фраза ENCRYPT.

Для совместимости с предыдущими версиями или по причинам производительности может понадобиться отключить шифрование. Используйте для этого команду ALTER TABLE MODIFY с фразой DECRYPT.

По умолчанию база данных добавляет случайную строку, называемую "помехой или солью" ( "salt") к открытому тексту столбца перед его шифрованием. Для столбца, который будет использоваться в индексе или внешнем ключе, необходимо указывать опцию NO SALT. Добавление или удаление "помехи" шифруемого столбца производится по команде ALTER TABLE MODIFY с параметром SALT (по умолчанию) или NO SALT, указанным в фразе ENCRYPT.

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


Примечание: дополнительные сведения о команде ALTER TABLE и ее опциях см. в документе Oracle Database SQL Reference.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #8  
Старый 14.10.2009, 16:52
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Прозрачное шифрование данных: указания



Прозрачное шифрование данных: указания

Нельзя шифровать столбцы таблиц, принадлежащих пользователю SYS. Для данных типа LONG и LOB шифрование не поддерживается.

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

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

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

Зашифрованные данные должны дешифроваться перед обработкой в выражениях, используемых в запросах и операциях DML (например, должны быть предварительно дешифрованы данные выражений в списке выбора команды select, в ограничении check, в условиях where или when).


Примечание: рекомендуется резервировать цифровой бумажник (wallet) перед переустановкой главного ключа и после этого действия.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #9  
Старый 14.10.2009, 16:54
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Поддержка имен пользователей и паролей в цифровом бумажнике



Поддержка имен пользователей и паролей в цифровом бумажнике

Теперь парольные мандаты (password credentials, имена пользователей и их пароли) для соединения с базами данных можно хранить на клиентской стороне в Oracle Wallet.. Такой цифровой бумажник является безопасным контейнером хранения парольных мандатов для аутентификации и мандатов цифровых подписей (signing credentials).

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

Когда на клиенте сконфигурировано безопасное внешнее хранение паролей, подсоединение приложений к базе данных производится с помощью команды следующего вида, в которой не указываются имя и пароль для входа в базу данных: connect /@db_connect_string.
Мандаты баз данных помешаются в цифровой бумажник Oracle (Oracle Wallet), созданный для их безопасного хранения. Возможность автоподсоединения (autologin feature) при использовании Oracle Wallet включена, поэтому в системе не требуется указывать пароль для открытия цифрового бумажника.

Чтобы сконфигурировать описанную возможность, необходимо создать Oracle Wallet на стороне клиента с помощью команды mkstore. Затем следует добавить имя пользователя и пароль для определенной строки соединения. Это действие также выполняется с помощью утилиты mkstore.

После этого необходимо убедиться в том, что в файле sqlnet. ога в параметре WALLET_LOCATION находится правильный указатель месторасположения бумажника.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #10  
Старый 14.10.2009, 16:55
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Утилита Data Pump и прозрачное шифрование данных



Утилита Data Pump и прозрачное шифрование данных

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

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

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

Однако при переносе внешней таблицы ключ недоступен в новом месторасположении. Поэтому для такой таблицы вы должны указать свой собственный пароль, чтобы зашифровать столбцы. Затем после переноса данных можно воспользоваться этим же паролем для регенерации ключа. В результате вы можете получить доступ к зашифрованным столбцам в новом месторасположении.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
Ответ
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 19:16. Часовой пояс GMT +3.


Powered by vBulletin®