Oracle пароль не соответствует требованиям безопасности
Обновлено: 04.07.2024
- Главная /
- Статьи /
- Oracle /
- RMAN В ПРИМЕРАХ - Конфигурирование окружения RMAN. Глава 4. Часть 4
Практическое администрирование Oracle - Файл паролей. Часть 1.
Администратору базы данных Oracle часто приходиться выполнять специальные операции, например, такие, как завершение или запуск базы данных. Поскольку исполнять их должен только он, а никто другой, его учётная запись требует безопасной аутентификации. Существует несколько способов аутентификации. Кроме использования стандартной аутентификации по словарю, для администратора базы данных доступны ещё три способа:
- Аутентификация операционной системы
- Аутентификация на основе файла паролей
- Устойчивая аутентификация на основе сетевой службы, такой как, например Oracle Internet Directory
Все три последних метода аутентифицируют административного пользователя даже тогда, когда база данных ещё не запущена.
Как известно, административные привилегии, которые требуются для выполнения основных операций с базой данных, предоставляются через две специальных системных привилегии SYSDBA и SYSOPER. Эти привилегии дают пользователю доступ к экземпляру даже тогда, когда он остановлен, и могут рассматриваться как специальные типы соединений, позволяющие выполнять команды, привилегии на которые не могут быть выданы обычными средствами.
Для аутентификации таких привилегированных пользователей, Oracle может использоваться специально созданный файл паролей. Чтобы данный метод аутентификации заработал, необходимо выполнение трёх условий. Должен быть правильно установлен один из параметров инициализации, файл паролей должен быть создан, в файл должны быть добавлены учётные записи пользователей имеющих привилегии SYSDBA и SYSOPER.
Рассмотрим более подробно этот процесс. Так как большинство примеров будет производиться локально, от имени пользователя операционной системы oracle, временно отберём у него группу dba, чтобы его аутентификация в базе данных не происходила на основе операционной системы:
Здесь стоит упомянуть, что аутентификация операционной системы является превалирующей над аутентификацией на основе файла паролей.
Установка параметра инициализации
Для того чтобы начала действовать аутентификация основанная на использовании файла пароля, параметр инициализации REMOTE_LOGIN_PASSWORDFILE должен быть установлен в значение EXCLUSIVE:
Данное значение является значением по умолчанию для данного параметра и поэтому его не требуется специально устанавливать после инсталляции. Если же параметр имеет другое значение, то стоит помнить, что он не является динамическим, поэтому для того чтобы аутентификация основанная на файле паролей заработала, придётся перезагрузить экземпляр:
Создание файла паролей
По умолчанию файл паролей создаётся в процессе установки Oracle Database помощником по конфигурированию сервера базы данных (DBCA). В системе UNIX файл имеет формат имени вида orapwORACLE_SID и располагается в каталоге ORACLE_HOME/dbs. В Windows, файл будет называться PWDORACLE_SID.ora и находится в каталоге ORACLE_HOME\database.
Ниже предоставлены различные примеры названий такого файла:
Если файл паролей, по каким то причинам отсутствует или требуется его пересоздание, то можно использовать утилиту ORAPWD. Синтаксис этой команды имеет следующий вид:
Аргумент FILE задаёт имя файла и путь файла пароля, ENTRIES – максимальное количество учётных записей в файле, FORCE – задаёт флаг, который отвечает за генерацию ошибки, если файл с таким именем уже существует, IGNORECASE – позволяет включать, выключать пароль, зависящий от регистра.
Рассмотрим более подробно на примерах создание файла паролей. Для начала определим наличие файла:
В системе присутствует файл паролей orapworcl , который был создан по умолчанию при установке. Удалим его и создадим новый:
Новый файл создан. В него добавлен пользователь SYS , пароль которого запрашивался при запуске утилиты. Если попытаться повторить процедуру создания файла снова, то будет сгенерирована ошибка о том, что такой файл присутствует, и что его надо переименовать или удалить:
Чтобы подавить такой вывод ошибки и пересоздать файл, необходимо при запуске orapwd указать опцию force=y:
Данная опция может быть полезна в пакетных командных файлах.
Включение пользователей в файл паролей
И так, файл паролей создан. При его создании, в него был включён единственный пользователь SYS, пароль которого вводился при запуске утилиты ORAPWD. Если требуется, чтобы данный вид аутентификации использовался и для других пользователей, то необходимо их так же включить их в файл паролей. К счастью, для этого не надо использовать какие-либо дополнительные утилиты, Oracle сам об этом побеспокоится. Единственное что надо сделать, так это предоставить таким пользователям привилегии SYSDBA или SYSOPER и Oracle сам добавит их в файл паролей. В качестве примера попробуем создать пользователя USER1 и предоставим ему привилегию SYSDBA:
При выдаче пользователям привилегий SYSDBA или SYSOPER следует учитывать, что данные привилегии являются специальным видом привилегий. Они не могут предоставляться пользователю с правом их передачи другим пользователям, а так же не могут быть включены в состав ролей. Рассмотрим это на примере. Выдадим привилегию SYSDBA пользователю USER1 с опцией WITH ADMIN OPTION:
Как видим, ошибок при выдаче привилегий с опцией WITH ADMIN OPTION не возникло. Но не всё так просто как кажется. Теперь создадим пользователя USER2, подключимся пользователем USER1 и попробуем выдать привилегию SYSDBA пользователю USER2:
Возникла ошибка. Просто так предоставить другим привилегии SYSDBA и SYSOPER у простого пользователя не получится. Опция WITH ADMIN OPTION здесь не действует. Необходимо предварительно аутентифицироваться с помощью файла паролей и только тогда можно предоставить привилегии другому пользователю:
В отличие от прав передачи, при предоставлении привилегий SYSDBA или SYSOPER роли ситуация однозначная. Сразу возникает ошибка. Так как данные привилегии могут работать и при выгруженном экземпляре, а роли действуют только при запущенной базе данных, предоставление их роли не имеет никакого смысла:
Просмотр пользователей включённых в файл паролей
В файле паролей на данный момент времени должны присутствовать три пользователя SYS, USER1 и USER2. Как убедиться, что они действительно туда попали? Конечно, можно просто посмотреть содержимое двоичного файла, но есть и более простой путь - это системное представление V$PWFILE_USERS:
Как видно из запроса, в файле паролей присутствуют три пользователя USER1, USER2 и SYS. Представление показывает не только присутствие этих пользователей в файле, но и предоставляет информацию о том, какие из привилегий SYSDBA и SYSOPER были выданы пользователю. Эта информация может быть полезна в дальнейшем при исключении пользователя из файла паролей или пересоздании файла.
Подключение с использованием файла паролей
Для того чтобы аутентифицироваться в локальной или удалённой базе данных с использованием файла паролей, пользователь при подключении должен указать этот вид аутентификации. Сделать это можно разными способами. Например, в утилите SQLPLUS для этого используются служебные слова AS SYSDBA или AS SYSOPER, которые могут быть указаны в команде CONNECT или в аргументах запуска утилиты из командной строки:
Некоторые утилиты oracle, такие как RMAN, вообще не требуют указания ключевых слов. Подключение с использованием файла паролей у них идет по умолчанию:
Что же касается сторонних утилит, то тут возможность подключения пользователя с использованием файла паролей полностью ложиться на плечи их разработчиков и зависит от целей, для которых эти утилиты предназначаются. В большинстве случаев такая поддержка, конечно, реализуется, ведь её отсутствие делает, например, невозможным подключение пользователя SYS, для которого вид аутентификации по файлу паролей является единственно возможным:
Хотя в большинстве утилит Oracle возможность аутентификации с использованием файла паролей реализована, работа пользователя в данном режиме подключения обычно не рекомендуется. Исключения здесь составляют только административные действия с базой данных и доступ к специфической служебной информации, например x$ таблицы. Стоит учитывать, что данный вид аутентификации использует совершенно другие алгоритмы подключения к базе данных, в корне отличающиеся от обычных соединений. Например, когда пользователь подключается к базе данных с привилегиями SYSDBA (SYSOPER) ему определяется схема по умолчанию SYS (PUBLIC), а вовсе не схема соответствующая его имени, как это происходит при обычном подключении:
Из-за этого несоответствия могут возникнуть ошибки при доступе к объектам расположенным в схеме пользователя, если в командах не прописана схема или в системе отсутствуют синонимы на объект.
Так как пользователь, соединяющийся с использованием файла паролей, подключается как пользователь SYS, все действия такого пользователя не попадают в основную базу стандартного аудита. Это сильно затрудняет наблюдение за ним. По той же причине триггеры на уровне базы данных не срабатывают для данного вида подключения. Об этом то же стоит не забывать.
Пароли чувствительные к регистру
Начиная с одиннадцатой версии, в Oracle введена возможность использовать пароли с учётом регистра. Для обычных подключений по умолчанию этот режим включен и определяется параметром инициализации SEC_CASE_SENSITIVE_LOGON:
Файл паролей по умолчанию так же использует пароли чувствительные к регистру. Причём этот режим никак не зависит от установок параметра SEC_CASE_SENSITIVE_LOGON. Продемонстрируем это на примере.
Для начала выключим зависимость паролей от регистра:
Перезагрузим экземпляр. Изменим пароль пользователя USER1 на верхний регистр:
Теперь попробуем подключиться к экземпляру в обычном режиме и с помощью файла паролей:
Как видно, при аутентификации с помощью файла паролей, пароль зависит от регистра независимо от того, что параметр SEC_CASE_SENSITIVE_LOGON выключен.
Если возникает необходимость в том, что бы пароли пользователей, включённые в файл паролей, не зависели от регистра, то необходимо, при создании файла с помощью утилиты ORAPWD, указать опцию IGNORECASE. Попробуем продемонстрировать это на примере. Для начала пересоздадим файл паролей с данной опцией:
Теперь пароли пользователей, помещаемых во вновь созданный файл, не будут зависеть от регистра. Проверим это. Так как файл был создан заново, включим в него опять пользователя USER1 и попробуем под ним подключиться:
Как видно подключение прошло успешно в не зависимости от того, в каком регистре пароль был набран.
В статье описаны пошаговые инструкции по настройке парольной политики популярной СУБД Oracle в соответствии с требованиями стандарта PCIDSS.
Довольно часто при проведении аудита на соответствие стандарту PCI DSS, да и аудита безопасности в целом, приходится сталкиваться с отсутствием правильно настроенных парольных политик. Собственно из-за этого в итоге мы и получаем на выходе пароли типа "12345" и прочие уже приевшиеся аудиторскому глазу наборы символов, которые потом мелькают в очередном обзоре самых популярных паролей. И если на контроллере домена худо-бедно политика настроена, да и то, в основном, потому что настраивается по умолчанию, то в СУБД мы видим довольно грустную картину.
А ведь чем по сотне раз на дню объяснять пользователям кошмары про подбор паролей, не проще ли один раз внедрить адекватную парольную политику и избавиться уж как минимум от 90% популярных паролей, тем более, что в этом нет ничего сложного и весь набор технических требований раздела 8.5 стандарта, как ни странно, можно реализовать даже не прибегая к дополнительным приложениям, потратив минимальное количество времени.
Итак, не будем больше терять драгоценного времени и приступим к настройке парольной политики в
СУБД Oracle . Определимся с техническими требованиями:
Теперь перейдём к реализации. Собственно, основная часть требований реализуется при помощи
настройки профилей:
• Создаём новый профиль для парольной политики с соответствующими значениями:
CREATE PROFILE BANK_USERS LIMIT
PASSWORD_LIFE_TIME 80 -- требование 1 и 2
PASSWORD_GRACE_TIME 10 -- требование 1 и 2
PASSWORD_REUSE_TIME 450 -- требование 3
PASSWORD_REUSE_MAX 4 -- требование 3
FAILED_LOGIN_ATTEMPTS 6 -- требование 4
PASSWORD_LOCK_TIME 1/48 -- требование 5
IDLE_TIME 15; -- требование 6
Проверить установленные значения можно следующим запросом:
select PROFILE, RESOURCE_NAME from dba_profiles;
• Для выполнения требования 7 необходимо указать так называемую функцию проверки, в которой можно настроить более тонкие параметры и даже, при желании, внедрить любые свои функции. Пример данной функции находится по умолчанию в директории $ORACLE_HOME/rdbms/admin/UTLPWDMG.SQL. Для соответствия требованиям необходимо внести в эту функцию одно изменение, а именно - найти в скрипте строку, отвечающую за длину пароля и изменить значение с 4 на 7 (от себя добавлю, что лучше поставить 9):
-- Check for the minimum length of the password
IF length(password) < 7 THEN
raise_application_error(-20002, 'Password length less than 7');
END IF;
Управление устареванием 1 паролей в СУБД Oracle реализуется через использование profile с помощью операторов create profile и alter profile. Они обеспечивают возможность проверки качества (сложность) пароля и настройку политики устаревания паролей. Администраторы могут использовать для этой цели profile пользователя в БД и встроить в него свою функцию проверки качества пароля, чтобы заставить пользователей принимать более сильные пароли.
Приемлемая длина пароля зависит от количества вычислительных ресурсов, доступных злоумышленнику и длительности его сеанса связи. Предполагая, что злоумышленник обладает современным аппаратным взломщиком DES, организации требуется не менее 12 знаков пароля, чтобы обеспечить срок его устаревания в 60 дней при проведении злоумышленником силовой атаки. В приложении 3 излагается математический аппарат, позволяющий оценить вероятность взлома Вашей парольной защиты.
Процедура проверки качества пароля - это функция на PL/SQL в схеме SYS, принимающая на входе логин пользователя, старый пароль и новый пароль, и возвращающая TRUE, в зависимости от качества выбранного пользователем пароля. Простейший пример такой функции
Эта функция выдает ошибку, если длина нового пароля менее 12 знаков. Эта функция не выполняет никаких других проверок пароля. Реальная функция проверки пароля должна быть, конечно, гораздо сложнее.
После создания такой функции ее необходимо ассоциировать с профилем. По умолчанию, в СУБД Oracle всегда существует профиль DEFAULT. С ним и будем ассоциировать:
Это средство также полезно, когда нужно заставить всех пользователей поменять их пароли.
Управление историей хранения паролей реализуется с помощью параметров password_reuse_max и password_reuse_time. Эти параметры не позволяют пользователю завести для себя два пароля и менять их поочередно. Бывают пользователи, которые, только что сменив пароль на какой-нибудь новый, тут же повторно меняют его на старый. Эти параметры запрещают пользователю вернуться к одному из старых паролей, пока не пройдет определенный период времени. Один из параметров определяет, сколько дней должно пройти прежде, чем пароль можно будет использовать повторно, а другой определяет сколько раз нужно сменить пароль, прежде, чем его можно будет использовать повторно. СУБД запоминает все введенные пароли (точнее, их хеши) и сравнивает их.
С точки зрения СУБД Oracle это взаимоисключающие параметры, т.е. когда одному присваивается какое-либо числовое значение, то второй должен принимать значение UNLIMITED. Оба параметра не могут принимать числовые значения, но могут принимать значения UNLIMITED. Установка обоих параметров в UNLIMITED разрешает немедленное повторное использование паролей.
Один из способов управления паролями заключается в редактировании и выполнении скрипта, предназначенного для настройки политики парольной защиты - $ORACLE_HOME/rdbms/utlpwdmg.sql. Этот скрипт имеет ряд предварительно установленных параметров, поэтому в большинстве случаев администратор может просто выполнить его.
Скрипт utlpwdmg.sql присваивает параметру password_reuse_time=1800, а password_reuse_max=UNLIMITED. Методологически целесообразнее присваивать значение параметру password_reuse_time, а не password_reuse_max, потому что настойчивый пользователь может обойти ограничение password_reuse_max, поменяв пароль password_reuse_max+1 раз.
При создании БД автоматически создается профиль DEFAULT. Он содержит в числе прочих настроек еще и политику устаревания паролей.
Вот параметры до изменения
| PROFILE | RESOURCE_NAME | RESOURCE_TYPE | LIMIT |
|---|---|---|---|
| DEFAULT | FAILED_LOGIN_ATTEMPTS | PASSWORD | 10 |
| DEFAULT | PASSWORD_LIFE_TIME | PASSWORD | UNLIMITED |
| DEFAULT | PASSWORD_REUSE_TIME | PASSWORD | UNLIMITED |
| DEFAULT | PASSWORD_REUSE_MAX | PASSWORD | UNLIMITED |
| DEFAULT | PASSWORD_LOCK_TIME | PASSWORD | UNLIMITED |
| DEFAULT | PASSWORD_GRACE_TIME | PASSWORD | UNLIMITED |
| DEFAULT | PASSWORD_VERIFY_FUNCTION | PASSWORD | NULL |
| Название RESOURCE_NAME | Смысл RESOURCE_NAME |
|---|---|
| FAILED_LOGIN_ATTEMPTS | Допустимое количество неуспешных попыток регистрации до блокировки учетной записи |
| PASSWORD_LIFE_TIME | Время жизни пароля |
| PASSWORD_REUSE_TIME | Число дней, в течение которых пароль нельзя использовать повторно. |
| PASSWORD_REUSE_MAX | Необходимое число изменений пароля, прежде чем им можно будет воспользоваться повторно. |
| PASSWORD_VERIFY_FUNCTION | Скрипт проверки стойкости пароля. Допускается создавать собственные функции проверки пароля. |
| PASSWORD_LOCK_TIME | Длительность блокировки в днях. Сколько времени будет заблокирована учетная запись после блокировки |
| PASSWORD_GRACE_TIME | Продолжительность дополнительного периода в днях. В течение этого времени разрешается подключение к БД, но выводится предупреждение о смене пароля. |
| PROFILE | RESOURCE_NAME | RESOURCE_TYPE | LIMIT |
|---|---|---|---|
| DEFAULT | FAILED_LOGIN_ATTEMPTS | PASSWORD | 3 |
| DEFAULT | PASSWORD_LIFE_TIME | PASSWORD | 60 |
| DEFAULT | PASSWORD_REUSE_TIME | PASSWORD | 1800 |
| DEFAULT | PASSWORD_REUSE_MAX | PASSWORD | UNLIMITED |
| DEFAULT | PASSWORD_LOCK_TIME | PASSWORD | .0006 |
| DEFAULT | PASSWORD_GRACE_TIME | PASSWORD | 10 |
| DEFAULT | PASSWORD_VERIFY_FUNCTION | PASSWORD | VERIFY_FUNCTION |
- Проверка, что пароль такой же, как логин
- Проверка, что пароль длиннее 4-х знаков
- Проверка, что пароль не 'welcome', 'database', 'account', 'user', 'password', 'oracle', 'computer', 'abcd'
- Проверка того, что пароль содержит не менее 1 буквы & 1 цифру & один знак пунктуации.
- Проверка, что пароль отличается от предыдущего пароля не менее чем в 3-х знаках в соответствующих позициях.
Администратор может самостоятельно изменить параметры профиля примерно так:
Полный синтаксис этой команды:
Руководствуясь параметром failed_login_attempts, сервер автоматически блокирует учетную запись после заданного числа неуспешных попыток регистрации в системе.
Поскольку эта особенность может быть использована злоумышленником для блокировки работающих учетных записей, то средства блокировки можно настроить так, чтобы учетная запись разблокировалась автоматически через время password_lock_time (в днях). Если password_lock_time устанавливается в UNLIMITED, то автоматической разблокировки не происходит. Разблокировать учетную запись может только член группы ДБА.
Параметр password_lock_time=0.0006 указывается в сутках, величина 1/1440 означает задержку в 51,84 секунды.
Если попытки подключения прекратились, не достигнув значения failed_login_attempts, то по истечении времени password_lock_time счетчик блокировки будет сброшен в 0.
Для отмены политики управления паролями можно несколько раз выполнить команду Alter profile default limit, установив изменяемый параметр в unlimited, чтобы сбросить настроенные параметры к их значению по умолчанию:
Обеспечение безопасности работы СУБД и конфиденциальности обрабатываемой в ней информации не менее важные задачи чем, например, обеспечение производительности или отказоустойчивости системы. Наиболее популярной и мощной в промышленном использование СУБД на сегодня является Oracle DataBase. Хотя по безопасности Oracle написано множество книг и посвящено других материалов, тем менее хотелось бы сделать некий шаблон безопасности или чек-лист по которому можно было быстро набросать эскиз политики безопасности или провести экспресс-аудит.
За основу составления статьи послужили следующие материалы:
Контрольный список вопросов безопасности Oracle
- Инсталляция только необходимых компонентов
Дистрибутив Oracle9i, кроме собственно системы управления базами данных (СУБД), содержит массу различных опций и продуктов. Инсталлируйте их только тогда, когда они нужны. Если используется типовая инсталляция, ненужные опции и продукты можно всегда деинсталлировать после ее завершения.
В таком случае для обеспечения защиты от случайного или несанкционированного использования инсталлированных, но не используемых, опций и продуктов, их не придется изучать, испытывать и т.д.
- Явно блокируйте вход в систему пользователей, создаваемых по умолчанию
Во время инсталляции Oracle по умолчанию создается ряд преопределенных пользователей БД. Если для инсталляции используется инструментальное средство Database Configuration Assistant (DBCA), автоматически блокируется вход в систему всех пользователей, создаваемых по умолчанию (и явно устанавливается дли них истечение срока действия пароля), кроме следующих, требуемых после успешного завершения инсталляции сервера БД:
- SYS
- SYSTEM
- SCOTT
- DBSNMP
- OUTLN
- Три пользователя JSERV.
Если выполняется ручная инсталляция (без DBCA), после успешного завершения инсталляции сервера БД никакие пользователи по умолчанию не блокируются. Их требуется блокировать вручную (для этого в дистрибутиве предусмотрен соответствующий командный файл SQL).
Список созданных пользователей БД и их статус можно проверить в представлении словаря данных DBA_USERS. После типовой инсталляции Oracle9i с помощью DBCA он выглядит следующим образом:
Если после инсталляции какой-то заблокированный пользователь по каким-то причинам понадобится вновь, АБД может его просто разблокировать и задать новый значащий (осмысленный) пароль.
- Изменение паролей пользователей, создаваемых по умолчанию.
- Изменяйте пароли по умолчанию административных пользователей.
- Изменяйте пароли по умолчанию всех пользователей.
- Используйте средства сопровождения паролей.
Изменяйте пароли по умолчанию административных пользователей
Пользователь SYS инсталлируется с паролем по умолчанию CHANGE_ON_INSTALL. Пользователь SYSTEM инсталлируется с паролем по умолчанию MANAGER.
Для предотвращения несанкционированного доступа к БД необходимо сразу же после завершения процедуры создания базы данных Oracle изменить пароли пользователей SYS и SYSTEM. Эти пароли документированы и не изменялись много лет.
Изменяйте пароли по умолчанию всех пользователей
После завершения инсталляции сервера БД немедленно измените пароли пользователей SCOTT, DBSNMP, OUTLN и JSERV. По представлению словаря данных DBA_USERS (ACCOUNT_STATUS = OPEN) проверьте наличие других открытых пользователей и примите решение по их блокированию или изменению их паролей.
Если потребуется активизировать других пользователей, заблокированных во время инсталляции, назначайте им новые значащие (осмысленные) пароли.
Используйте средства сопровождения паролей
Oracle рекомендует использовать основные правила сопровождения паролей (длина пароля, хронология, сложность и т.п.) для всех пользователей БД, а также требовать от пользователей регулярного изменения паролей.
Парольная система Oracle включается установкой параметра инициализации RESOURCE_LIMIT = TRUE и позволяет:
Механизм сопровождения паролей в Oracle базируется на ресурсных ограничениях типа PASSWORD, устанавливаемых в профилях пользователей:
Шаблон процедуры проверки сложности пароля входит в состав дистрибутива сервера Oracle (см. командный файл utlpwdmg.sql). Этот шаблон можно использовать при разработке новой процедуры проверки сложности пароля, отвечающей требованиям заказчика (его политике безопасности).
В процедуре verify_function выполняются следующие явно минимальные проверки сложности пароля:
Oracle также рекомендует использовать, если это возможно, опцию Oracle Advanced Security (входит в Enterprise Edition) с сервисами сетевой аутентификации (такими, как Kerberos, токен-карты, смарт-карты или сертификаты X.509). Эти сервисы обеспечивают сильную аутентификацию и, следовательно, лучшую защиту от несанкционированного доступа.
Oracle рекомендует защищать словарь данных от доступа пользователей с системными привилегиями типа ANY. Для включения защиты следует установить параметр инициализации O7_DICTIONARY_ACCESSIBILITY:
После этого доступ к словарю данных будут иметь только пользователи с административными привилегиями (например, пользователи, которые могут соединяться с БД как CONNECT / AS SYSDBA).
Если каким-то пользователям требуется, например, просмотр словаря данных, им можно выдать системную привилегию SELECT ANY DICTIONARY в Oracle9i или роль SELECT_CATALOG_ROLE в Oracle8i.
- Применение принципа минимальности привилегий
- Выдавайте пользователям только требуемые привилегии.
- Отбирайте ненужные привилегии у группы пользователей БД PUBLIC.
- Ограничивайте права доступа в динамически запускаемых средствах.
Выдавайте пользователям только требуемые привилегии
Oracle обеспечивает реализацию принципа минимальности привилегий (principle of least privilege), суть которого заключается в том, что пользователи должны получать минимальный набор привилегий, требуемый для выполнения их конкретных задач.
Для реализации принципа минимальности привилегий:
Самым простым и эффективным способом предоставления и управления привилегиями является использование для этого ролей базы данных Oracle. Механизм ролей обеспечивает:
В Oracle9i появились защищенные роли приложений (Secure Application Role), которые можно включать только в авторизованных пакетах PL/SQL. Это позволяет ограничить их использование только приложениями. Преимущества защищенных ролей приложений:
- не требуется хранение паролей;
- для включения используются авторизованные пакеты PL/SQL.
В предыдущих версиях Oracle пароль нужно было вставлять в текст приложения, либо хранить в таблице БД или файле ОС. При создании защищенной роли приложений указывается пакет с правами вызывающего (домен защиты в процедурах с правами владельца изменять нельзя), авторизованный для ее включения:
CREATE ROLE роль IDENTIFIED USING [схема].пакет_с_правами_вызывающего;
В авторизованном пакете для обеспечения дополнительной защиты можно c помощью контекста приложения разрешать включение ролей, например, только для пользователей, соединяемых через proxy-сервер:
Замечание: защищенные роли приложений остаются включенными даже после завершения работы процедур авторизованного пакета, поэтому можно разработать специализированную процедуру, которая определяет возможность использования роли в оставшейся части сеанса.
Отбирайте ненужные привилегии у группы пользователей БД PUBLIC
Группа пользователей БД PUBLIC работает как роль по умолчанию, доступная всем пользователям Oracle. Любой пользователь может воспользоваться привилегиями PUBLIC, включая привилегию выполнения (EXECUTE) различных пакетов PL/SQL. Приведем список пакетов, право выполнения которых должно предоставляться только в индивидуальном порядке:
Разрешает установление сервером БД исходящих сетевых соединений с любыми принимающими (или ожидающими) сетевыми службами. Произвольные данные БД могут быть посланы в любую ожидающую сетевую службу.
При неправильном конфигурировании разрешает текстовый доступ к любому файлу операционной системы сервера БД. Даже при правильном конфигурировании этот пакет не различает вызывающие приложения, когда приложение с доступом к пакету пишет произвольные данные в то же самое место, в которое данные записывает другое приложение.
Может быть использован для шифрования хранимых данных. В общем, большинство пользователей не должно иметь привилегий для шифрования данных, т.к. они могут оказаться не восстанавливаемыми, если ключи неправильно генерируются или хранятся.
Ограничивайте права доступа в динамически запускаемых средствах
Пример более защищенного динамического вызова:
- Правильно выполняйте аутентификацию клиентов.
- Ограничивайте количество пользователей операционной системы.
- Правильно выполняйте аутентификацию клиентов
Удаленная аутентификация пользователей выполняется на удаленной клиентской машине, соединенной с Oracle. Таким образом, Oracle неявно доверяет клиентам, что они аутентифицировали себя правильно. Перекладывание аутентификации на операционную систему клиента может серьезно скомпрометировать безопасность.
В более защищенной конфигурации удаленная аутентификация должна быть выключена:
Ограничивайте количество пользователей операционной системы
Максимально ограничивайте на сервере количество пользователей операционной системы, независимо от уровня выдаваемых им привилегий ОС.
Oracle также не рекомендует изменять права доступа к файлам и директориям Oracle, создаваемых во время инсталляции, если только это не рекомендует сделать сама Oracle Corporation.
- межсетевые экраны с proxy-возможностями, включая:
- Gauntlet от Network Associates;
- Raptor от Axent;
- межсетевые экраны с фильтрацией пакетов, включая:
- межсетевые экраны с контролем, изменяющем параметры своего состояния в процессе работы (более совершенные межсетевые экраны с фильтрацией пакетов), включая:
Это приведет к появлению ряда существенных слабых мест в системе защиты, включая:
Предотвращение несанкционированного администрирования Oracle Listener
Для предотвращения удаленного конфигурирования Oracle Listener всегда следует устанавливать для него осмысленный, правильно сформированный пароль.
Кроме того, в управляющем файле Oracle Listener (listener.ora) следует установить параметр защищенной конфигурации:
Это будет также предотвращать несанкционированное администрирование Oracle Listener.
Для разрешения или отказа в доступе к процессам сервера Oracle используйте возможность проверки в Oracle Net допустимых узлов ("valid node checking"). Для этого в конфигурационном файле Oracle Net (protocol.ora) следует установить параметры:
Oracle Corporation рекомендует, если возможно, шифровать сетевой трафик между клиентами, серверами баз данных и серверами приложений, используя для Oracle Advanced Security,. (опция Oracle Advanced Security доступна только в Oracle Enterprise Edition).
Ограничивайте функции операционной системы
Как UNIX, так и платформы Windows, обеспечивают разнообразные сервисы, большинство из которых не требуется для большинства прикладных систем: FTP, TFTP, TELNET и т.д.
При отключении таких сервисов следует не забывать о закрытии как портов UDP, так и портов TCP, для каждого отключаемого сервиса. Отключение одного типа портов и не отключение другого типа портов не делают операционную систему более защищенной.
Минимальная конфигурация операционной системы MS Windows NT 4.0 для сервера Oracle может иметь следующие характеристики:
- Операционная система MS Windows NT Server 4.0.
- Режим установки Standalone Server.
- Установленный Service Pack 3 или более поздний.
- Наличие одной или нескольких сетевых карт Ethernet.
- Наличие сетевого протокола TCP/IP.
- Отсутствие всех других сетевых протоколов.
- Отсутствие на сервере любого программного обеспечения, кроме программного обеспечения операционной системы и сервера Oracle.
Читайте также: