Страницы

пятница, 3 апреля 2015 г.

ПРАКТИЧЕСКОЕ АДМИНИСТРИРОВАНИЕ. ФАЙЛ ПАРОЛЕЙ

Администратору базы данных Oracle часто приходиться выполнять специальные операции, например, такие, как завершение или запуск базы данных. Поскольку исполнять их должен только он, а никто другой, его учётная запись требует безопасной аутентификации. Существует несколько способов аутентификации. Кроме использования стандартной аутентификации по словарю, для администратора базы данных доступны ещё три способа:
  • Аутентификация операционной системы
  • Аутентификация на основе файла паролей
  • Устойчивая аутентификация на основе сетевой службы, такой как, например Oracle Internet Directory
Все три последних метода аутентифицируют административного пользователя даже тогда, когда база данных ещё не запущена.
Как известно, административные привилегии, которые требуются для выполнения основных операций с базой данных, предоставляются через две специальных системных привилегии 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.
Как видно подключение прошло успешно в не зависимости от того, в каком регистре пароль был набран.









Ограничение количества пользователей в файле паролей

В документации к Oracle указано, что имеется ограничение на количество пользователей включаемых в файл паролей. Оно зависит от размера блока операционной системы и кратно четырём. Так, например, для блока размером в 512 байт количество пользователей, которые могут храниться в файле паролей равно четырём. Попробуем на примере проверить так ли это на самом деле. Постепенно будем добавлять в файл паролей новых пользователей и посмотрим, что произойдёт.
Два пользователя SYS и USER1 в файле паролей у нас уже есть. Добавляем остальных:
SQL> grant sysdba to user2 identified by pass;     

Grant succeeded.

SQL> grant sysdba to user3 identified by pass;

Grant succeeded.

SQL> grant sysdba to user4 identified by pass;

Grant succeeded.

SQL> grant sysdba to user5 identified by pass;

grant sysdba to user5 identified by pass
*
ERROR at line 1:
ORA-01996: GRANT failed: password file
'/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapworcl' is full
При включении пользователя USER5 вышла ошибка, сигнализирующая о том, что файл паролей полон. Вроде все, так как и описано в документации. Правда, с пользователем SYS это уже будет 5 пользователей, но всё равно это уже ближе к истине. Так почему же именно такое количество пользователей может находиться в файле паролей по умолчанию и как можно расширить этот предел? Попробуем разобраться в этом на примерах.
Вновь создаваемый файл паролей по умолчанию всегда имеет определённый размер 1536 байт. Почему именно такой размер, а не другой? Попробуем разделить это число на 512. Получиться 3. Значит, файл паролей условно можно разделить на три блока по 512 байт. Вроде многовато места будет для хранения только 5 пользователей. Заглянем внутрь файла. Для начала выведем первые 512 байт файла:
[oracle@ora11g dbs]$ xxd -l 512 orapworcl

0000000: 0000 0000 0002 0000 0200 0000 5d5c 5b5a  ............]\[Z
0000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
Как видно это блок почти пуст, добавленных пользователей здесь нет. Поэтому заглянем во второй блок:
[oracle@ora11g dbs]$ xxd -s 512 -l 512 orapworcl

0000200: 4f52 4143 4c45 2052 656d 6f74 6520 5061  ORACLE Remote Pa
0000210: 7373 776f 7264 2066 696c 6500 0000 1b00  ssword file.....
0000220: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000230: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000240: 0100 0000 0000 0000 0000 0000 0000 0000  ................
0000250: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000260: 494e 5445 524e 414c 0000 0000 0000 0000  INTERNAL........
0000270: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000280: 0800 0000 3933 3645 3435 3532 3241 3642  ....936E45522A6B
0000290: 3937 3833 0000 0000 0000 0000 0000 0000  9783............
00002a0: 0000 0000 1000 0000 1f6a a782 7f29 eb49  .........j...).I
00002b0: 87eb a03e 49e3 7285 c1ab 9f2b 884d 2e79  ...>I.r....+.M.y
00002c0: e0c2 e4f4 a8a4 d100 5359 5300 0000 0000  ........SYS.....
00002d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00002e0: 0000 0000 0000 0000 0300 0000 3836 4331  ............86C1
00002f0: 3534 3034 4331 4142 3230 4130 0000 0000  5404C1AB20A0....
0000300: 0000 0000 0000 0000 0000 0000 1000 0000  ................
0000310: 1f41 78c1 a301 dd68 176b 2daf 02f8 fbd3  .Ax....h.k-.....
0000320: 5c25 29c0 75ad ed6e 5e16 b3e7 4810 0500  \%).u..n^...H...
0000330: 0000 0000 0000 0000 0000 0000 5553 4552  ............USER
0000340: 3100 0000 0000 0000 0000 0000 0000 0000  1...............
0000350: 0000 0000 0000 0000 0000 0000 0500 0000  ................
0000360: 4238 4345 4646 4342 4138 3835 3139 3435  B8CEFFCBA8851945
0000370: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000380: 1000 0000 1b23 4ba7 ff77 1857 0845 7072  .....#K..w.W.Epr
0000390: d2e0 4b00 243f 663c 276e b2ae df8f 1ca6  ..K.$?f<'n......
00003a0: 51b3 ce00 0000 0000 0000 0000 0000 0000  Q...............
00003b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00003c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00003d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00003e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00003f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
Здесь уже интереснее. Во втором блоке можно обнаружить пользователей SYS и USER1. Нетрудно догадаться так же, что остальные пользователи будут находиться в третьем блоке.
[oracle@ora11g dbs]$ xxd -s -512 orapworcl

0000400: 5553 4552 3200 0000 0000 0000 0000 0000  USER2...........
0000410: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000420: 0500 0000 3331 3633 3444 3530 3144 3342  ....31634D501D3B
0000430: 4244 3331 0000 0000 0000 0000 0000 0000  BD31............
0000440: 0000 0000 1000 0000 1b3c 9fe8 725e 4ea1  .........f
0000460: 7487 c495 5ed1 b800 5553 4552 3300 0000  t...^...USER3...
0000470: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000480: 0000 0000 0000 0000 0500 0000 4235 3734  ............B574
0000490: 3132 3338 3330 4546 3232 3936 0000 0000  123830EF2296....
00004a0: 0000 0000 0000 0000 0000 0000 1000 0000  ................
00004b0: 1bcc fb1f 6184 a10b 6619 2b27 5854 a364  ....a...f.+'XT.d
00004c0: 380c ba30 8c89 18f6 2f29 817b 4ffd 6a00  8..0..../).{O.j.
00004d0: 5553 4552 3400 0000 0000 0000 0000 0000  USER4...........
00004e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00004f0: 0500 0000 3430 3044 4437 4443 3743 4232  ....400DD7DC7CB2
0000500: 3938 3646 0000 0000 0000 0000 0000 0000  986F............
0000510: 0000 0000 1000 0000 1ba4 00b3 152f b1ca  ............./..
0000520: e9b4 c3f6 bc58 f305 f00a 8bb9 b774 e24c  .....X.......t.L
0000530: 4dcd c436 f259 f200 0000 0000 0000 0000  M..6.Y..........
0000540: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000550: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000560: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000570: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000580: 8000 0000 0000 0000 0000 0000 0000 0000  ................
0000590: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00005a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00005b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00005c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00005d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00005e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00005f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
В последний блок влезли данные только о трёх пользователях. Пользователь USER5 здесь явно не поместился, хотя место для него имеется. Получается, что в документации отражены неверные сведения о четырёх пользователей в 512 байтном блоке? Проясним этот вопрос.
Ясно, что для того чтобы добавить ещё пользователей, придётся расширять файл паролей, то есть создавать его заново. Для этого в утилите ORAPWD есть опция ENTRIES, в которой, задаётся число планируемых пользователей в файле паролей. Попробуем пересоздать файл с этой опцией. В параметре укажем пять пользователей, так четыре пользователя (не считая SYS) у нас уже есть:
[oracle@ora11g dbs]$ orapwd file=orapworcl force=y entries=5

Enter password for SYS:
Посмотрим на размер файла:
[oracle@ora11g dbs]$ ls -l orapworcl

-rw-r-----. 1 oracle oinstall 2048 Янв 32 11:56 orapworcl
Он прибавил в размере. Причём на 512 байт, один блок. Повторим добавление в файл паролей пользователей USER1 – USER4 и попробуем создать и добавить пользователя USER5:
SQL> grant sysdba to user1, user2, user3, user4;

Grant succeeded.

SQL> grant sysdba to user5 identified by pass;

Grant succeeded.
Пользователь добавился. Попробуем добавить ещё одного:
SQL> grant sysdba to user6 identified by pass;

Grant succeeded.
Добавление так же прошло успешно. Почему? Ведь при создании файла было введено ограничение на 5 пользователей. Ответ на это найдём в документации Oracle. В ней сказано, что пользователи будут добавляться в файл паролей до тех пор, пока блок не будет заполнен полностью. Так как выше было выяснено, что в последнем блоке из 512 байт размещается 3 пользователя, в файл паролей можно будет добавить ещё одного пользователя USER7, после чего этот файл потребуется ещё раз пересоздать с новым значением ENTRIES:
SQL> grant sysdba to user7 identified by pass;

Grant succeeded.

SQL> grant sysdba to user8 identified by pass;

Grant succeeded.
Почему в файл паролей добавился пользователь USER8? Ведь по умолчанию в последнем блоке файла паролей помещалось только три пользователя. Оказывается, документация Oracle не соврала. В блоке из 512 байт действительно помещается 4 пользователя, правда только не в самом последнем блоке. Проверим это. Попробуем добавить ещё одного пользователя USER9:
SQL> grant sysdba to user9 identified by pass;

grant sysdba to user9 identified by pass
*
ERROR at line 1:
ORA-01996: GRANT failed: password file
'/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapworcl' is full
Возникла ошибка. И так, файл паролей, состоящий из 4 блоков по 512 байт, на данный момент времени содержит восемь пользователей. Первый, из них, всегда располагается во втором блоке, четыре других в третьем и три последних пользователя в четвёртом. Такое расположение пользователей в файле паролей следует учитывать при задании опции ENTRIES. В приведённом примере можно задавать любое значение этой опции 6, 7, 8. Результат будет одинаковый. По сути, данная опция служит только для ограничения выделяемого пространства для файла паролей и лишь косвенно влияет на количество пользователей в нём.

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

Со временем может понадобиться исключить того или иного пользователя из файла паролей. Если пользователь удаляется из системы, Oracle автоматически удаляет его и из файла паролей:
SQL> select * from v$pwfile_users 
 
USERNAME SYSDBA SYSOPER SYSASM
-------- ------ ------- ------
SYS      TRUE   TRUE    FALSE 
USER1    TRUE   FALSE   FALSE 
USER2    TRUE   FALSE   FALSE 
USER3    TRUE   FALSE   FALSE 
USER4    TRUE   FALSE   FALSE 
USER5    TRUE   FALSE   FALSE 
USER6    TRUE   FALSE   FALSE 
USER7    TRUE   FALSE   FALSE 
USER8    TRUE   FALSE   FALSE 

SQL> drop user user8;

User dropped.

SQL> select * from v$pwfile_users WHERE USERNAME = 'USER8'
 
USERNAME SYSDBA SYSOPER SYSASM
-------- ------ ------- ------
 
Выбрано: 0 строк
Если пользователю нужно только запретить аутентификацию с помощью файла паролей, то для этого достаточно отобрать у него привилегии SYSDBA и SYSOPER Пользователь будет удалён из файла пароля, когда у него не будет ни одной из этих привилегий:
SQL> grant sysoper to user7;

Grant succeeded.

SQL> select * from v$pwfile_users WHERE USERNAME = 'USER7'
 
USERNAME SYSDBA SYSOPER SYSASM
-------- ------ ------- ------
USER7    TRUE   TRUE    FALSE

SQL> revoke sysdba from user7;

Revoke succeeded.

SQL> select * from v$pwfile_users WHERE USERNAME = 'USER7'
 
USERNAME SYSDBA SYSOPER SYSASM
-------- ------ ------- ------
USER7    FALSE  TRUE    FALSE

SQL> revoke sysoper from user7;

Revoke succeeded.
SQL> select * from v$pwfile_users WHERE USERNAME = 'USER7'
 
USERNAME SYSDBA SYSOPER SYSASM
-------- ------ ------- ------
 
Выбрано: 0 строк
Исключение пользователя из файла паролей не изменяет его размер. Информация о нём сохраняется в файле, но пространство им занимаемое становиться доступно для перезаписи другим включаемым пользователям. Продемонстрируем это. В предыдущем примере пользователи USER7 и USER 8 были «исключены» из файла паролей. Причём пользователь USER8 был удалён. В файле паролей эти пользователи находились в четвёртом последнем 512 байтном блоке. Выведем его содержимое:
[oracle@ora11g dbs]$ xxd -s -512 orapworcl

0000600: 5553 4552 3600 0000 0000 0000 0000 0000  USER6...........
0000610: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000620: 0500 0000 3144 3332 4131 3831 3035 3543  ....1D32A181055C
0000630: 3445 4436 0000 0000 0000 0000 0000 0000  4ED6............
0000640: 0000 0000 1000 0000 1b31 6ab3 5d3e 925a  .........1j.]>.Z
0000650: b736 2e69 c8cd 0f53 8d59 42da 3096 21bb  .6.i...S.YB.0.!.
0000660: 4d59 8978 24da fa00 5553 4552 3700 0000  MY.x$...USER7...
0000670: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000680: 0000 0000 0000 0000 0500 0000 3745 4137  ............7EA7
0000690: 3641 3733 4541 3038 3234 3630 0000 0000  6A73EA082460....
00006a0: 0000 0000 0000 0000 0000 0000 1000 0000  ................
00006b0: 1874 c741 6392 1a9e 74fe 3d04 ed19 0550  .t.Ac...t.=....P
00006c0: a382 b987 904f 569b 7b94 4dd5 2bfd 3e00  .....OV.{.M.+.>.
00006d0: 5553 4552 3800 0000 0000 0000 0000 0000  USER8...........
00006e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00006f0: 0500 0000 4235 3237 4446 3346 3844 4132  ....B527DF3F8DA2
0000700: 3341 4632 0000 0000 0000 0000 0000 0000  3AF2............
0000710: 0000 0000 1000 0000 1a34 e3d5 3b84 0a48  .........4..;..H
0000720: 265c c770 0da9 2da9 bba1 a962 35b0 3b0e  &\.p..-....b5.;.
0000730: 8c3a ea2a 4943 6f00 0000 0000 0000 0000  .:.*ICo.........
0000740: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000750: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000760: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000770: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000780: 8000 0000 0000 0000 0000 0000 0000 0000  ................
0000790: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00007a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00007b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00007c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00007d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00007e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00007f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
Как видно информация о пользователях сохранилась. Таким образом, понятие «исключение из файла паролей» скорее логическое, чем физическое.

Безопасность

Если посмотреть дамп второго блока файла паролей, то среди его содержимого можно найти интересного пользователя INTERNAL. Представление V$PWFILE_USERS его не показывает, но он действительно включён в файл паролей. Данный пользователь применялся в качестве административного пользователя в предыдущих релизах Oracle (до 8.2 версии). Его предназначение в старших релизах Oracle неизвестно.
Почему данный пользователь не виден в представлении V$PWFILE_USERS? Ответ становиться очевиден, если заглянуть в исходный код представления:
SQL> select view_definition from v$fixed_view_definition WHERE view_name LIKE 
'GV$PWFILE_USERS';

VIEW_DEFINITION
------------------------------------------------------------
select inst_id,username,decode(sysdba,1,'TRUE','FALSE'),
decode(sysoper,1,'TRUE','FALSE'),
decode(sysasm,1,'TRUE','FALSE')  from x$kzsrt where valid=1
and username != 'INTERNAL'
Информация о пользователях, включённых в файл паролей, выводится из динамической таблицы. X$KZSRT. Пользователь INTERNAL отсекается на уровне представления.
Кстати, таким образом можно исключить вывод в представлении V$PWFILE_USERS любого пользователя включённого в файл паролей. Этим могут воспользоваться злоумышленники, оставляющие потайные входы в базу данных. Поэтому стоит время от времени делать запрос непосредственно к таблице X$KZSRT на факт выявления несанкционированных пользователей.
Пользователи, включённые в файл паролей – это пользователя обладающие очень большими возможностями, поэтому не стоит бездумно предоставлять привилегии SYSDBA и SYSOPER каждому пользователю.
Стоит так же ограничивать доступ к файлу паролей и на уровне операционной системы. Даже если файл доступен только для чтения, в нём хранятся хэши паролей, зная которые можно при наличии специальных инструментов получит пароль привилегированных пользователей.

Выводы

Сделаем некоторые выводы из изложенной информации:
  • Аутентификация операционной системой имеет приоритет перед аутентификацией по файлу паролей.
  • Утилита ORAPWD всегда создаёт файл заново. Пользователи, хранившиеся в предыдущем файле, теряются.
  • Включение пользователей в файл паролей, синхронизация паролей при их изменении, удаление пользователей из файлов паролей осуществляется ORACLE автоматически при выполнении соответствующих SQL команд.
  • Пароли пользователей размещённых в файле паролей, начиная с версии 11G, зависят от регистра. Причём на эту зависимость никак не влияет значение параметра SEC_CASE_SENSITIVE_LOGON.
  • Пароли файла паролей можно сделать не зависящим от регистра символов, если при создании файла утилитой ORAPWD использовать опцию IGNORECASE.
  • Опция ENTRIES утилиты ORAPWD влияет только на размер (в 512 байтных блоках) создаваемого файла паролей.
  • В последнем блоке файла паролей размещается три пользователя, а не четыре. Первый пользователь всегда размещается во втором блоке вместе с пользователем SYS. Это следует учитывать при задании опции ENTRIES.
  • При удалении пользователя из файла паролей, место, им занимаемое, не освобождается, но доступно для другого пользователя. Таки образом пользователь физически не удаляется из файла паролей.





Автор: на

Комментариев нет:

Отправить комментарий

Подписаться на: Комментарии к сообщению (Atom)