Печать

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

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

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

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

Рассмотрим более подробно этот процесс. Так как большинство примеров будет производиться локально, от имени пользователя операционной системы oracle, временно отберём у него группу dba, чтобы его аутентификация в базе данных не происходила на основе операционной системы:

[root@ora11g oracle]# gpasswd -d oracle dba
Removing user oracle from group dba

Здесь стоит упомянуть, что аутентификация операционной системы является превалирующей над аутентификацией на основе файла паролей.

Установка параметра инициализации

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

NAME                                 TYPE	 VALUE
------------------------------------ ----------- ---------------------
remote_login_passwordfile            string      EXCLUSIVE

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

SQL> alter system set remote_login_passwordfile=exclusive scope=spfile;

System altered.

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

По умолчанию файл паролей создаётся в процессе установки Oracle Database помощником по конфигурированию сервера базы данных (DBCA). В системе UNIX файл имеет формат имени вида orapwORACLE_SID и располагается в каталоге ORACLE_HOME/dbs. В Windows, файл будет называться PWDORACLE_SID.ora и находится в каталоге ORACLE_HOME\database.

Ниже предоставлены различные примеры названий такого файла:

PWDXE.ora
orapworcl

Если файл паролей, по каким то причинам отсутствует или требуется его пересоздание, то можно использовать утилиту ORAPWD. Синтаксис этой команды имеет следующий вид:

ORAPWD FILE=filename [ENTRIES=numusers] [FORCE={Y|N}] [IGNORECASE={Y|N}]

Аргумент FILE задаёт имя файла и путь файла пароля, ENTRIES – максимальное количество учётных записей в файле, FORCE – задаёт флаг, который отвечает за генерацию ошибки, если файл с таким именем уже существует, IGNORECASE – позволяет включать, выключать пароль, зависящий от регистра.

Рассмотрим более подробно на примерах создание файла паролей. Для начала определим наличие файла:

[oracle@ora11g ~]$ cd $ORACLE_HOME/dbs
[oracle@ora11g dbs]$ ls -l orapw*
-rw-r-----. 1 oracle oinstall 1536 Дек 17 13:48 orapworcl

В системе присутствует файл паролей orapworcl , который был создан по умолчанию при установке. Удалим его и создадим новый:

[oracle@ora11g dbs]$ rm orapworcl
[oracle@ora11g dbs]$ orapwd file=orapworcl

Enter password for SYS: 
[oracle@ora11g dbs]$ ls -l orapw*
-rw-r-----. 1 oracle oinstall 1536 Дек 20 13:11 orapworcl

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

[oracle@ora11g dbs]$ orapwd file=orapworcl

Enter password for SYS: 

OPW-00005: File with same name exists - please delete or rename

Чтобы подавить такой вывод ошибки и пересоздать файл, необходимо при запуске orapwd указать опцию force=y:

[oracle@ora11g dbs]$ orapwd file=orapworcl force=y

Enter password for SYS:

[oracle@ora11g dbs]$ ls -l orapw*
-rw-r-----. 1 oracle oinstall 1536 Дек 24 13:33 orapworcl

Данная опция может быть полезна в пакетных командных файлах.

Включение пользователей в файл паролей

И так, файл паролей создан. При его создании, в него был включён единственный пользователь SYS, пароль которого вводился при запуске утилиты ORAPWD. Если требуется, чтобы данный вид аутентификации использовался и для других пользователей, то необходимо их так же включить их в файл паролей. К счастью, для этого не надо использовать какие-либо дополнительные утилиты, Oracle сам об этом побеспокоится. Единственное что надо сделать, так это предоставить таким пользователям привилегии SYSDBA или SYSOPER и Oracle сам добавит их в файл паролей. В качестве примера попробуем создать пользователя USER1 и предоставим ему привилегию SYSDBA:

SQL> grant connect, sysdba to user1 identified by pass;

Grant succeeded.

При выдаче пользователям привилегий SYSDBA или SYSOPER следует учитывать, что данные привилегии являются специальным видом привилегий. Они не могут предоставляться пользователю с правом их передачи другим пользователям, а так же не могут быть включены в состав ролей. Рассмотрим это на примере. Выдадим привилегию SYSDBA пользователю USER1 с опцией WITH ADMIN OPTION:

SQL> revoke sysdba from user1;

Revoke succeeded.

SQL> grant sysdba to user1 with admin option;   

Grant succeeded.

Как видим, ошибок при выдаче привилегий с опцией WITH ADMIN OPTION не возникло. Но не всё так просто как кажется. Теперь создадим пользователя USER2, подключимся пользователем USER1 и попробуем выдать привилегию SYSDBA пользователю USER2:

SQL> grant connect to user2 identified by pass;

Grant succeeded.

SQL> connect user1/pass;
Connected.

SQL> grant sysdba to user2;
grant sysdba to user2
*
ERROR at line 1:
ORA-01031: insufficient privileges

Возникла ошибка. Просто так предоставить другим привилегии SYSDBA и SYSOPER у простого пользователя не получится. Опция WITH ADMIN OPTION здесь не действует. Необходимо предварительно аутентифицироваться с помощью файла паролей и только тогда можно предоставить привилегии другому пользователю:

SQL> connect user1/pass as sysdba;
Connected.
SQL> grant sysdba to user2;

Grant succeeded.

В отличие от прав передачи, при предоставлении привилегий SYSDBA или SYSOPER роли ситуация однозначная. Сразу возникает ошибка. Так как данные привилегии могут работать и при выгруженном экземпляре, а роли действуют только при запущенной базе данных, предоставление их роли не имеет никакого смысла:

SQL> create role role1;

Role created.

SQL> grant sysdba to role1;
grant sysdba to role1
*
ERROR at line 1:
ORA-01931: cannot grant SYSDBA to a role

Просмотр пользователей включённых в файл паролей

В файле паролей на данный момент времени должны присутствовать три пользователя SYS, USER1 и USER2. Как убедиться, что они действительно туда попали? Конечно, можно просто посмотреть содержимое двоичного файла, но есть и более простой путь - это системное представление V$PWFILE_USERS:

SQL> select * from v$pwfile_users 
 
USERNAME SYSDBA SYSOPER SYSASM
-------- ------ ------- ------
SYS      TRUE   TRUE    FALSE 
USER1    TRUE   FALSE   FALSE 
USER2    TRUE   FALSE   FALSE 

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

Подключение с использованием файла паролей

Для того чтобы аутентифицироваться в локальной или удалённой базе данных с использованием файла паролей, пользователь при подключении должен указать этот вид аутентификации. Сделать это можно разными способами. Например, в утилите SQLPLUS для этого используются служебные слова AS SYSDBA или AS SYSOPER, которые могут быть указаны в команде CONNECT или в аргументах запуска утилиты из командной строки:

SQL> connect user1/pass as sysdba
Connected.

[oracle@ora11g ~]$ sqlplus user1/pass as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Tue Jan 32 13:16:51 2013

Connected to:

Некоторые утилиты oracle, такие как RMAN, вообще не требуют указания ключевых слов. Подключение с использованием файла паролей у них идет по умолчанию:

RMAN> connect target user1/pass;
connected to target database: ORCL (DBID=1330046917)

Что же касается сторонних утилит, то тут возможность подключения пользователя с использованием файла паролей полностью ложиться на плечи их разработчиков и зависит от целей, для которых эти утилиты предназначаются. В большинстве случаев такая поддержка, конечно, реализуется, ведь её отсутствие делает, например, невозможным подключение пользователя SYS, для которого вид аутентификации по файлу паролей является единственно возможным:

SQL> connect sys/pass;
ERROR:
ORA-28009: connection as SYS should be as SYSDBA or SYSOPER

Warning: You are no longer connected to ORACLE.    

Хотя в большинстве утилит Oracle возможность аутентификации с использованием файла паролей реализована, работа пользователя в данном режиме подключения обычно не рекомендуется. Исключения здесь составляют только административные действия с базой данных и доступ к специфической служебной информации, например x$ таблицы. Стоит учитывать, что данный вид аутентификации использует совершенно другие алгоритмы подключения к базе данных, в корне отличающиеся от обычных соединений. Например, когда пользователь подключается к базе данных с привилегиями SYSDBA (SYSOPER) ему определяется схема по умолчанию SYS (PUBLIC), а вовсе не схема соответствующая его имени, как это происходит при обычном подключении:

SQL> connect user1/pass;
Connected.
SQL> select sys_context('userenv', 'current_schema') from dual;

SYS_CONTEXT('USERENV','CURRENT_SCHEMA')
---------------------------------------
USER1

SQL> connect user1/pass as sysdba
Connected.
SQL> select sys_context('userenv', 'current_schema') from dual;

SYS_CONTEXT('USERENV','CURRENT_SCHEMA')
---------------------------------------
SYS

Из-за этого несоответствия могут возникнуть ошибки при доступе к объектам расположенным в схеме пользователя, если в командах не прописана схема или в системе отсутствуют синонимы на объект.

Так как пользователь, соединяющийся с использованием файла паролей, подключается как пользователь SYS, все действия такого пользователя не попадают в основную базу стандартного аудита. Это сильно затрудняет наблюдение за ним. По той же причине триггеры на уровне базы данных не срабатывают для данного вида подключения. Об этом то же стоит не забывать.

Пароли чувствительные к регистру

Начиная с одиннадцатой версии, в Oracle введена возможность использовать пароли с учётом регистра. Для обычных подключений по умолчанию этот режим включен и определяется параметром инициализации SEC_CASE_SENSITIVE_LOGON:

SQL> show parameters sec_case
 
Параметр                 Тип     Значение
------------------------ ------- --------
sec_case_sensitive_logon boolean TRUE    

Файл паролей по умолчанию так же использует пароли чувствительные к регистру. Причём этот режим никак не зависит от установок параметра SEC_CASE_SENSITIVE_LOGON. Продемонстрируем это на примере.

Для начала выключим зависимость паролей от регистра:

SQL> alter system set sec_case_sensitive_logon=false;
System altered. 

Перезагрузим экземпляр. Изменим пароль пользователя USER1 на верхний регистр:

SQL> alter user user1 identified by PASS;
User altered.

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

SQL> connect user1/pass;
Connected.

SQL> connect user1/pass as sysdba
ERROR:
ORA-01031: insufficient privileges

Warning: You are no longer connected to ORACLE.

SQL> connect user1/PASS as sysdba
Connected.

Как видно, при аутентификации с помощью файла паролей, пароль зависит от регистра независимо от того, что параметр SEC_CASE_SENSITIVE_LOGON выключен.

Если возникает необходимость в том, что бы пароли пользователей, включённые в файл паролей, не зависели от регистра, то необходимо, при создании файла с помощью утилиты ORAPWD, указать опцию IGNORECASE. Попробуем продемонстрировать это на примере. Для начала пересоздадим файл паролей с данной опцией:

[oracle@ora11g dbs]$ pwd
/u01/app/oracle/product/11.2.0/dbhome_1/dbs
[oracle@ora11g dbs]$ orapwd file=orapworcl force=y ignorecase=y

Enter password for SYS:

Теперь пароли пользователей, помещаемых во вновь созданный файл, не будут зависеть от регистра. Проверим это. Так как файл был создан заново, включим в него опять пользователя USER1 и попробуем под ним подключиться:

SQL> grant sysdba to user1;

Grant succeeded.

SQL> connect user1/pass as sysdba
Connected.

SQL> connect user1/PASS as sysdba
Connected.

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