10 шагов к обеспечению защищенности базы данных Oracle встроенными механизмами безопасности

Система управления базами данных Oracle DataBase является одной из наиболее популярных и широко используемых баз данных в корпоративном сегменте. И это не удивительно, поскольку ее отличает высокая надежность, производительность, масштабируемость и адаптируемость под бизнес-задачи каждого конкретного пользователя.  Однако, столь широкая популярность оборачивается и другой стороной медали - вектор атак на СУБД остается в топе наиболее существенных угроз.  

В одной и прошлых статей мы рассказывали о экспресс проверке (этакий чек-лист) конфигурации на соответствие требованиям безопасности. В сегодняшней публикации мы рассмотрим 10 простых шагов к повышению безопасности СУБД Oracle DataBase своими силами без использования дополнительного ПО, основываясь лишь на рекомендациях самой компании Oracle, собственном опыты и "best practices". 

Многим эти рекомендации могут показаться слишком банальными и очевидными, однако как показывает практика, именно"простые" ошибки и  невнимательность может привести к очень серьезным последствиям. Описываемые 10 шагов по сути это список самых необходимых последовательных действий для Oracle DataBase, которые необходимо выполнить для  если вы этого еще до сих не сделали.

Введение

Не смотря на все усилия разработчика компании Oracle и многочисленный "best practices", т.к. NIST 800, SANS, CISecurity, защищенность Oracle DataBase порой оставляет желать лучшего. Конечно, можно использовать специализированные средства защиты информации (СЗИ), которые бы обеспечивали безопасность СУБД, однако, в реалиях сегодняшнего дня, их используют далеко не все компании. Причин на то множество,и мы не будем все их рассматривать в рамках данной статьи, лишь проинформируем о самом факте. Как вариант выхода из данной ситуации - это по максимум использовать все встроенные в систему штатные механизмы безопасности о которых мы ниже и поговорим.

Кратко пробежимся по основным типичным причинам, которые способствуют тому, что Oracle DataBase может быть  сконфигурирована без учета требований информационной безопасности:

1.Отсутствие в штате команды ИТ или ИБ департаментов профильных экспертов специализирующихся на безопасности СУБД. 

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

2. Установка "НЕ настраивай безопасность" - заключается в том, что во многих компаниях с недостаточным уровнем зрелости в отношении ИБ, часто сформирована мысль о том, что конфиг безопасности уменьшает производительность и доступность СУБД. В виду этого опции безопасности используются в лучшем случае по умолчанию или вовсе отключатся. 

3. "Безопасность по умолчанию" - связана с предыдущим пунктом формулировка исходя из которой администраторы СУБД часто обходят вниманием настройку механизмов защиты базы данных. Компания Oracle начиная с версии Oracle 9 сделала публичное заявление о том, что продукт "из коробки" уже настроен на "безопасность по умолчанию". Однако, как вы сможете убедиться дочита эту стать,все далеко не так, как заявил вендор. 

Рекомендации собранные в этой статье ориентированы преимущественно на две версии продукта начиная с версии Oracle 10g и до крайнего релиза 11g. Но, я могу с уверенностью полагать, что некоторый из рассмотренных ниже опций будут весьма актуальны и для 12 версии.

И так, давайте начнем!

1. Блокируйте все учетные  записи установленные по умолчанию

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

После инсталляции свежего экземпляра Oracle в системе имеется ряд учетных записей оставляемых по умолчанию, каждая с рядом заранее определенных дефолтных опций. Помощник-инсталлятор (DBCA) запускаемый в начале инсталляции после  выполнения всех операций и финализации установки автоматически блокируется и далее отключает ряд "опасных" с токи зрения  ИБ сервисов.  Кроме того DBCA изменяет учетку SYSTEM с учетом тех параметров,которые  были заданы во время процесса установки.

При установке базы данных Oracle вручную, DBCA никогда не запускается, и  соответственно не вносит никаких изменений в системные учетные записи оставляя их в привилегированном режиме с рядом "опасных" значений в опциях устанавливаемых по умолчанию. К примеру, оставляет значение пароля точно  таким же как имя пользователя. И это будут одним из первых действий, которые предпримет хакер при попытке взлома базы данных! Рекомендуется настроить для каждой системной учетной записи свой уникальный пароль отвевающий требованиям  безопасности. А если эти аккаунты и вовсе не требуются для работы то они должны быть заблокированы.

To change the password, execute the following SQL code:

sqlplus> connect mydba
sqlplus> alter user SYSTEM account lock and expire

The following SQL can be used to lock and expire those default accounts:

sqlplus> connect mydba

sqlplus> alter user SYSTEM account lock and expire

Учетные записи, которые устанавливаются по умолчанию с Oracle могут варьироваться в зависимости от версии. Ниже краткие сведения об учетках, которые установлены по умолчанию (если DBCA никогда не запускался) для версий системы Oracle 9, 10 и 11

Oracle 9	Oracle 10 – Release 1 and 2	Oracle 11
SYSTEM	SYSTEM	SYSTEM
SYS	SYS	SYS
SCOTT		SYSMAN
DBSNMP		MGMT_VIEW
		DBSNMP

Начиная с Oracle версии 11g, выводя список admins DBA можно легко найти все аккаунты с паролями по умолчанию (так же, как имя пользователя) с помощью команды:

view DBA_USERS_WITH_DEF_PWD.

2. Используйте усиленный SID для подключении всех пользователей к БД

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

Если производить подключение  используя неправильный SID то в ответ будет получено сообщение “ORA-12505: TNS:listener does not currently know of SID given in connect descriptor". Главный риск для SID это то, что он может быть взломан с помощью брутфорса. К примеру, существует множество инструментов для подбора пароля в прикладных пакетах типо  metasploit, OAT, OAK, SIDGuess и т. д.

Наибольшей  опасностью для взлома админиского SID для перебора паролей является не правильные настройки  усиления SID-записи. Так примеру не соблюдаются такие требования к паролю:

1. Используются общеизвестные фразы 

2. Длина пароля менее 10 символов

3. Не соблюдается сложность парольной фразы (спец символы, цифры, буквы)

Использование данных правил усиления парольной защиты для админского SID, хоть и не гарантирует абсолютную защиту, но таки существенно снижает риск взлома с применением техник подбора пароля.  

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

Риск состоит в том,что злоумышленник может скомпрометировать как минимум один такой файл для системы, которая настроена для подключения к базе данных Oracle, путем извлечения данных о SID из файла TNSNAMES.ORA. Однако, подумайте о тех случаях, когда злоумышленник является внешним по отношению к организации и осуществляет попытки взлома извне, т.е. хакера у которого изначально нет клиентского ПО Oracle для подключения с СУБД. 

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

3. Устанавливаете все критические обновления (патчи) от Oracle как можно скорее

Это одна из тех рекомендации по безопасности, которая в большинстве компаний может игнорироваться. В зависимости от используемой схемы (архитектуры) базы данных в вашей организации, пакеты обновлений Oracle Critical Patch Updates (CPU’s) могут иметь очень большое  значение для производительности и безопасности фермы Oracle. Одно, нужно помнить, что даже критические патчи необходимо тестировать перед установкой на боевые системы в избежание сбоев и во избежание иного рода проблем.

Корпорация Oracle выпускает критические обновления раз в квартал. во вторник ближе к 17-му дню месяца. На официальной страничке Oracle есть страница посвященная  бюллетеню обновлений, в котором описываются все наиболее важные замечания по пакету обновлений. К счастью, CPU’s носят коммулятивный характер. Т.е. вам нужно просто установить одну из крайних версий CPU’s что бы для Oracle применились и все ранее вышедшие исправления от состояния  первоначального выпуска продукта.

Существует также патчи для  Oracle которые имеют статус критических и рекомендованы для установки как можно скорее. Как правило то связано с найденной уязвимостью в системе.  Потому Oracle вымоет выпустить патчи в обход своего основного плана-графика. Программа CPU’s была начата компанией в 2005 году,  и только несколько раз разработчик выпускал пачти вне запланированного плана. Перед установкой необходимо внимательно читать все замечания к выпуску обновления, что поможет избежать абсолютное большинство проблем при установки патча.

4. Удалите все ненужные привилегии для PUBLIC ролей в системе

В Oracle существуют расширенные процедуры, которые позволяют минимизировать количество привилегированных учетных записей для выполнения системных функций, которые им строго необходимы для обеспечения правильного функционирования СУБД. Эти процедуры называются пакетами (packages), и примерно  эквиваленты расширенным хранимым процедурам  в Microsoft SQL Server. Особую роль, именуемую PUBLIC, используют в системе  как роль по умолчанию для каждого пользователя в базе данных Oracle. Таким образом любой пользователь базы данных может выполнять задачи с привилегиями , которые зафиксированы как PUBLIC. Это часто эксплуатируется хакерами в части эскалации уязвимостей при взломе.

Эти пакеты (packages) и все их подтипы (subtype) должны быть удалены из PUBLIC ролей и  выполняться  для пользовательского приложения только в случае крайней необходимости!

Ниже в таблице в порядке убывания риска перечислены наиболее опасные пакеты, назначенные по умолчанию PUBLIC роли

Package or Subtype	Description
DBMS_SQL*	This package provides an interface to use dynamic SQL to parse any data manipulation language (DML) or data definition language (DDL) statement from within PL/SQL. David Litchfield discovered the vulnerability in this package and presented it at Blackhat in 2007. He demonstrated that a user could escalate their privileges through cursor snarfing and cursor injection. This problem has been fixed in Oracle 11g, but is still present in other versions. Given that this package is extremely dangerous, and any database user can escalate to SYS, its necessity should be closely scrutinized. If native dynamic SQL is not required, the package should be removed.
DBMS_XMLGEN	The DBMS_XMLGEN package converts the results of a SQL query to a canonical XML format in real-time. An attacker can exploit this package with SQL injection. Similarly to the DBMS_SQL package, all data, including user credentials can be extracted from the database. Given that this package is extremely dangerous, its necessity should be closely scrutinized. If dynamic XML database queries are not required, the package should be removed.
UTL_TCP*	This package facilitates outgoing network connections to be established by the database server to any receiving (or waiting) network service. Granting this package to PUBLIC may permit arbitrary data may to be sent between the database server and any waiting network service.
DBMS_RANDOM	This package can be used to encrypt stored data. Generally, most users should not have the privilege to encrypt data- since encrypted data may be non-recoverable if the keys are not securely generated, stored, and managed, etc.
UTL_HTTP*	This package allows the database server to request and retrieve data using HTTP. By default, it allows every user to access data over the Internet from HTTP. An attacker could exploit this package with an HTTP request to send a SQL injection to the database to dump user’s credentials, and other sensitive data. According to the least privilege principle, revoke all grants to this package if your applications do not need it.
HTTPURITYPE	This subprogram is a subtype of the UriType that provides support for the HTTP protocol. It uses the UTL_HTTP package underneath to access the HTTP URLs. By default, it allows every user to transfer data from the database via HTTP. An attacker could exploit this package with an HTTP request to send a SQL injection to the database to dump user’s credentials, and other sensitive data. According to the least privilege principle, revoke all grants to this package if your applications do not need it.
DBMS_ADVISOR	This package DBMS_ADVISOR is part of the Server Manageability suite of Advisors, a set of expert systems that identifies and helps resolve performance problems relating to the various database server components. Because this package allows direct file system access, it can be used by an attacker to interact with the file system, outside of the database.
UTL_SMTP	This package permits arbitrary mail messages to be sent from one arbitrary user to another arbitrary user. An attacker could use this as a part of a larger social engineering attack. Most likely your application will not need this type of functionality from the database, and you should revoke all grants to this package.
UTL_INADDR	This package allows arbitrary domain name resolution to be performed from the database server, which could allow an attacker to enumerate your internal resources. According to the least privilege principle, revoke all grants to this package if your applications do not need DNS resolution.

5. Обязательно включите режим аудита Базы Данных

1. Аудит SYS операций

По умолчанию в базе данных Oracle не активирован аудит исполняемых команд SQL, выполняемый в привилегированном режиме от учетки SYS, а так же при подключении пользователей с привилегиями (учетками) SYSDBA или SYSOPER. Так если ваша база данных будет взломана, эти учетки будут использованы  хакерами в  первую очередь. Но, к счастью  аудит SQL-команд из этих привилегированных учеток очень просто включить следующей командой

sqlplus> alter system set audit_sys_operations=true scope=spfile;

2. Включение аудита Базы Данных

Опять же, по умолчанию в Oracle аудит команд SQL не включен по умолчанию. По рекомендациям разработка аудит должен быть включен для всех команд SQL. Аудит базы данных включается с применением параметра audit_trail:

sqlplus> alter system set audit_trail=DB,EXTENDED scope=spfile;

3. Включение аудита наиболее важны объектов СУБД

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

AUDIT CREATE USER BY ACCESS; 

AUDIT ALTER USER BY ACCESS; 

AUDIT DROP USER BY ACCESS; 

AUDIT CREATE ROLE BY ACCESS; 

AUDIT SELECT ON DBA_USERS BY ACCESS; 

AUDIT CREATE EXTERNAL JOB BY ACCESS; -- 10g Rel.2 

AUDIT CREATE JOB BY ACCESS; -- 10g Rel.1 

AUDIT CREATE ANY JOB BY ACCESS; 

AUDIT CREATE ANY LIBRARY BY ACCESS; 

AUDIT ALTER DATABASE BY ACCESS; 

AUDIT ALTER SYSTEM BY ACCESS; 

AUDIT AUDIT SYSTEM BY ACCESS; 

AUDIT EXEMPT ACCESS POLICY BY ACCESS; 

AUDIT GRANT ANY PRIVILEGE BY ACCESS; 

AUDIT GRANT ANY ROLE BY ACCESS; 

AUDIT ALTER PROFILE BY ACCESS; 

AUDIT CREATE ANY PROCEDURE BY ACCESS; 

AUDIT ALTER ANY PROCEDURE BY ACCESS; 

AUDIT DROP ANY PROCEDURE BY ACCESS; 

AUDIT CREATE PUBLIC DATABASE LINK BY ACCESS; 

AUDIT CREATE PUBLIC SYNONYM BY ACCESS; 

AUDIT EXECUTE ON DBMS_FGA BY ACCESS; 

AUDIT EXECUTE ON DBMS_RLS BY ACCESS; 

AUDIT EXECUTE ON DBMS_FILE_TRANSFER BY ACCESS; 

AUDIT EXECUTE ON DBMS_SCHEDULER BY ACCESS; 

AUDIT EXECUTE ON DBMS_JOB BY ACCESS; 

AUDIT SELECT ON SYS.V_$SQL BY ACCESS; 

AUDIT SELECT ON SYS.GV_$SQL BY ACCESS; 

AUDIT EXECUTE ON SYS.KUPP$PROC BY ACCESS; 

AUDIT EXECUTE ON DBMS_XMLGEN BY ACCESS; 

AUDIT EXECUTE ON DBMS_NETWORK_ACL_ADMIN BY ACCESS; -- 11g 

6. Настройте использование триггеров для схемы аудита и ряда событий в системе 

Для того, чтобы эффективно отслеживать все изменения схемы БД и событий входа и выхода пользователей в систему, Oracle предоставляет возможность настроить триггеры DDL для включения аудита всех изменений схемы и формирования отчета фиксирующего в деталях все изменения, а именно: когда оно было сделано, и каким пользователем (учетной записью). Существует несколько вариантов аудита в Oracle с использование Триггеров, но следующих три команды рекомендуются в Best Practices for Oracle Databases

1. Настройка триггеров события входа в систему

С помощью logon trigger, вы можете отслеживать все события входа и выхода в режиме реального времени в любой системе. Для автоматизации оповещения можно настроить стандартный системный системный демон syslog.

В примере ниже показано как будут отправляться все события входа и выхода из системы на веб-сервере в режиме реального времени.

Command (as user SYS):

SQL> create or replace trigger sec_logon after logon on database

DECLARE

rc VARCHAR(4096);

begin

begin

rc:=utl_http.request('http://192.168.2.201/logon_user='||user||';sessionid

='||sys_context('USERENV','SESSIONID')||';host='||sys_context('USERENV','H

OST')||';ip='||ora_client_ip_address||';sysdate='||to_char(sysdate, 'YYYY-MM-DD hh24:mi:ss'));

exception 

when utl_http.REQUEST_F AILED then null; end;

End sec_logon;/

NOTE: Change the IP address to your web server’s address. 

2. Настройка DDL_Trigger

С помощью Data Definition Language (DDL) можно запрограммировать триггеры в Oracle DBA, которые будут автоматически отслеживать все изменения в базе данных, включая изменения таблиц, индексов и других обетов. Данные получаемые из настроенных триггеров является особенно полезным для контроля изменений о которых необходимо знать администраторам Oracle.

Ниже приведен пример отправляющий извещения о действиях GRANT, ALTER, CREATE, DROP. 

Command (as user SYS):

SQL> create or replace trigger DDLTrigger 

AFTER DDL ON DATABASE 

DECLARE 

rc VARCHAR(4096); 

BEGIN 

begin 

rc:=utl_http.request('http://192.168.2.201/user='||ora_login_user||'; 

DDL_TYPE='||ora_sysevent||';DDL_OWNER='||ora_dict_obj_owner||';DDL_NA 

ME='||ora_dict_obj_name||';sysdate='||to_char(sysdate, 'YYYY-MM-DD 

hh24:mi:ss'); 

exception 

when utl_http.REQUEST_FAILED then null; end; 

END; 

/ 

NOTE: Change the IP address to your web server’s address. 

3. Настройка Error Triggers

Триггеры ошибок генерируют сообщения об ошибках в Oracle. Они могут быть полезны для обнаружения атак с использованием SQL-инъекций и других методов атаки.

Command (as user SYS):

SQL> CREATE OR REPLACE TRIGGER after_error

AFTER SERVERERROR ON DATABASE

DECLARE pragma autonomous_transaction; id NUMBER;

sql_text ORA_NAME_LIST_T; v_stmt CLOB; n NUMBER;

BEGIN

n := ora_sql_txt(sql_text);

IF n >= 1 THEN

FOR i IN 1..n LOOP

v_stmt := v_stmt || sql_text(i);

END LOOP;

END IF;

FOR n IN 1..ora_server_error_depth LOOP

IF ora_server_error(n) in ( 

'900','906','907','911','917','920','923','933','970','1031','1476','1719'

,'1722','1742','1756','1789','1790','24247',' 29257','29540') THEN

INSERT INTO system.oraerror VALUES (SYS_GUID() , sysdate, ora_login_user, 

ora_client_ip_address, ora_server_e rror(n), ora_server_error_msg(n), 

v_stmt);

END IF; END LOOP; 

END after_error; /

NOTE: Change the IP address to your web server’s address.

7. Используйте Database Activity Monitoring (DAM) в качестве дополнительного уровня защиты

Если вы располагаете финансовыми ресурсами то можете доустановить дополнительное ПО для мониторинга активности эксплуатации БД. Это решает проблему, в том случае, когда Вы не можете контролировать весь штат системных администраторов, их дейсвтия, или когда риск недоверия админу СУБД велик. Мониторинг так же предоставляет полезную информацию для отслеживания опасных SQL-запросов и модификаций производимых в системных Role, которые потенциально могут свидетельствовать о злоумышленных действиях в базе данных. Ключевая особенность DAM заключается в том, что это приложение мониторинга работает в оперативной памяти сервера Oracle и продолжает работать независимо от внесения негативных изменений в функции аудита и журналирования. Для тех, кто знаком с сетевыми системами обнаружения вторжений (IDS) отметим,что DAM имеет аналогичную функцию.

8. Включите Управление паролями для всех Oracle Logins 

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

Ниже преставление рекомендуемые настройки:

1. Создание профилей

Oracle profiles are created with: 

CREATE PROFILE profilename LIMIT SQL statement

Users are added to the profile with: 

ALTER USER login(s) PROFILE profilename

2. Блокировка аккаунтов 

Блокировка учетных записей будет выполняться после 5 неудачных попыток в течение 30 дней, что значительно снижает риск атак брутфорсом. Если 30 дней кому то покажется очень большим сроком, то его вполне можно установить, к пример, на 1 день, что в любом случае поможет значительно снизить риск атаки типо брутфорс.

FAILED_LOGIN_ATTEMPTS 5 

PASSWORD_LOCK_TIME 30 

3. Истечение срока действия пароля

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

PASSWORD_LIFE_TIME 90

4. Ведение истории изменения паролей

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

PASSWORD_REUSE_TIME 1 

PASSWORD_REUSE_MAX 10 

5. Требовании к сложности пароля 

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

В Oracle используется PL/SQL-скрипт, который осуществляет проверку сложности пароля пользователя.

В общем, функция проверки пароля должны обеспечивать следующие критерии:

• в пароле используются буквы и цифры, а так же спецсимволы
• пароль не содержится в словарях для брутфорса
• длина пароля составляет не меньше 10 символов

9. Проводите регулярную оценку безопасности СУБД

Как бы мы не защищали СУБД описанными выше методами, всегда есть вероятность, что система будет взлома с помощью атак 0-day или других методов взлома, которые заранее учесть нельзя. Поэтому весьма не лишним будет периодически использовать автоматизированные инструменты поиска уязвимостей, к примеру сканеров безопасности и различных тулз от самого разработчика которые помогают оценить безопасность систем. Не лишним будет мониторить различные bug track-ресурсы и информационные порталы, посвященные ИБ. Много полезных сведений можно получить из материалов различных хакерских конференция, т.к. BackHat USA, DefCon, ZeroNights, PHDays и других. Ну и конечно же регулярно читать обвиняющиеся фреймворки посвященные лучшим практикам обеспечения ИБ.

Так же не забывайте о резервном копировании и плане обеспечения непрерывности восстановления деятельности.

10. Шифруйте сетевой трафик используемый БД

Эта последняя рекомендация из приведенных в сегодняшней статье, которая, кстати, и редко выполняется. СУБД Oracle поддерживает шифрование на уровне сети, используя такие протоколы как SSL, стандарт цифровых сертификатов X.509v3  и встроенное шифрование без использования сертификатов.

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

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

• Oracle 10g- Configuring Network Data Encryption and Integrity for Oracle Servers and Clients
• Oracle 11g- Configuring Network Data Encryption and Integrity for Oracle Servers and Clients

Все, всем спасибо! И удачи друзья!

При подготовке статьи использовались:

1. Марлен Терьо, Аарон Ньюмен, Oracle. Руководство по безопасности
2. Сэм Р. Алапати, Oracle Database 11g. Руководство администратора баз данных
3. Oracle Security simple guide By Chris Star