Где хранятся пароли пользователей в oracle

Обновлено: 10.01.2025

таблица, на которую ссылаются все вышеприведенные представления.

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

Подмена пакетов

Разрешение имен в БД Oracle производится в следующей последовательности:

Если имеется объект с таким названием в текущей схеме, то используется он

Если имеется приватный синоним с таким названием в текущей схеме, то используется он.

Если в БД имеется общедоступный синоним с таким названием, то используется он.

Бороться с подменой пакетом можно

путем полной адресации объекта, например

SQL > exec SYS.dbms_crypto …

REVOKE EXECUTE ON UTL_SMTP FROM PUBLIC;

REVOKE EXECUTE ON UTL_TCP FROM PUBLIC;

REVOKE EXECUTE ON UTL_FILE FROM PUBLIC;

REVOKE EXECUTE ON DBMS_RANDOM FROM PUBLIC;

Обнаружение потенциальных злоумышленников производится запросом:

SELECT * FROM DBA_TAB_PRIVS

AND GRANTEE = 'PUBLIC'

SELECT GRANTEE AS USERNAME, PRIVILEGE, ADMIN_OPTION

PRIVILEGE LIKE '% ANY %'

OR PRIVILEGE LIKE '%DATABASE LINK%'

OR PRIVILEGE LIKE '%UNLIMITED%'

OR PRIVILEGE = 'BECOME USER'

OR ADMIN_OPTION = 'YES'

AND GRANTEE NOT IN (

'SYS', 'SYSTEM', 'OUTLN', 'DBSNMP',

'DBA', 'CONNECT', 'RESOURCE',

'AQ_ADMINISTRATOR_ROLE', 'OEM_MONITOR', 'CTXSYS', 'IFSSYS',

'IFSSYS$CM', 'MDSYS', 'ORDPLUGINS', 'ORDSYS',

'TIMESERIES_DBA', 'WKSYS', 'SYSMAN', 'OLAPSYS',

'OLAP_DBA', 'EXFSYS', 'SCHEDULER_ADMIN', 'WMSYS',

'SI_INFORMTN_SCHEMA', 'JAVADEBUGPRIV', 'MDDATA',

AND GRANTEE NOT IN (

WHERE ACCOUNT_STATUS != 'OPEN'

А обнаружение потенциальных Троянов производится запросом:

SELECT * FROM DBA_SYNONYMS

WHERE OWNER = 'PUBLIC'

AND NOT TABLE_OWNER IN ('SYS','SYSMAN','SYSTEM','WMSYS','EXFSYS','ORDSYS','MDSYS', 'XDB');

Пароли в трассировочных файлах

Получить пользовательские пароли можно из трассировочных файлов.

Так, например, если установить трассировку пользовательской сессии, то можно увидеть, как пользователь выполняет:

SQL >alter system set wallet open identified by 'tiger';

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

alter system set wallet open identified by 'tiger'

Пароли и OEM Grid Control

OEM Grid Control - основное средство, предлагаемое корпорацией для мониторинга и управления базами данных Oracle. Этот инструмент способен мониторить и управлять не только БД, но и OAS, хосты и сети между всем этим, способен подключаться к металинку за новым ПО. OEM Grid Control (OEMGC) хранит

пароли к базам данных (системные пользователи, наделенные наиболее сильными привилегиями),

пароли к хостам (чтобы подключаться, когда БД не стартована)

логин и пароль на металинк.

Злоумышленник, получивший доступ к этому средству, автоматически получит информацию и средство управления всеми БД, листенерами, OAS'ами, хостами и доступом на металинк. Таким образом, OEM Grid Control - один из наиболее интересных для злоумышленника участков и наиболее сильная болевая точка ИС на основе Oracle.

OEMGC'у соответствует схема SYSMAN. Пароли хранятся в таблицах

Вообще-то, таблиц больше, чем три:

select object_name,object_type from dba_objects where object_name like '%CREDENTIAL%' and owner = 'SYSMAN'

Урну с водой уронив, об утес ее дева разбила.
Дева печально сидит, праздный держа черепок.
Чудо! не сякнет вода, изливаясь из урны разбитой:
Дева над вечной струей вечно печальна сидит.

Александр Сергеевич Пушкин

Чуда не вижу я тут. Генерал-лейтенант Захаржевский,
В урне той дно просверлив, воду провел чрез нее.

Аннотация

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

Введение

СУБД Oracle, подобно всем, реально конкурирующим с ней, является старой системой, создание которой происходило, как и продолжается ныне развитие, в рыночных условиях. В этой СУБД, как и у конкурентов, есть целый ряд конструктивных решений, принятых в свое время второпях, и со временем ставших неудовлетворительными. Что-то удается усовершенствовать: например механизмы выделения динамической памяти для текущих нужд СУБД, регулирования доступа к общим ресурсам СУБД или буферизации блоков данных. Однако некоторые заложенные на ранних стадиях развития механизмы или же не удается изменить вовсе (недоразвитое понятие схемы БД) или удается, но с большим запозданием. К числу последних относится механизм парольной защиты пользователей (user) и ролей (role). Особенности парольной защиты Oracle, способствующие несанкционированному проникновению в БД, затронуты в этой статье.

Реализация парольной защиты в Oracle

Основным принятым средством аутентификации (проверки подлинности) пользователя Oracle и включаемой/выключаемой роли является указание пароля. Так, пароль указывается при выполнении соединения с СУБД (например, в SQL*Plus в команде CONNECT), в предложении SQL создании пользователя или в полном определении связи с посторонней БД (database link).

Хранение пароля

Заданный для пользователя Oracle командой CREATE/ALTER USER пароль подвергается преобразованию и попадает в словарь-справочник в виде свертки (password hash). При указании пароля в момент установления соединения с СУБД Oracle заново вычислит свертку и сравнит ее с хранимой в БД. В открытом виде пароли в БД не хранятся.

Увидеть свертки логически можно, выдав например:

Последняя строка в приведенной выдаче является иллюстрацией применения недокументированной, но широко известной возможности Oracle занести в БД на место свертки в БД непосредственное значение:

Фактически это обесценивает привилегию CREATE SESSION, если таковая имеется (соединение все равно невозможно). Возможность занести в БД непосредственно свертку позволяет обладателю привилегии ALTER USER подменить на время пароль, чтобы за законных основаниях войти в систему под чужим именем. Однако если это пользователь SYS, замененный таким образом ему "пароль" не фиксируется в файле PWD.ORA, так что особой проблемы с доступностью это свойство не создает.

Если параметр СУБД O7_DICTIONARY_ACCESSIBILITY имеет значение TRUE (умолчание в версии 8), к трем указанным таблицам может обратиться любой обладатель системной привилегии SELECT ANY DICTIONARY; в противном случае - только владелец SYS.

Алгоритм вычисления свертки пароля

К имени пользователя приклеивается справа текст пароля.
В получившейся строке буквам повышается регистр.
Символы строки переводятся в двухбайтовый формат дополнением слева нулевым значением 0x00 (для символов ASCII), и справа строка дописывается нулевыми байтами до общей длины 80.
Получившаяся строка шифруется алгоритмом DES в режиме сцепления блоков шифротекста (CBC) ключом 0x0123456789ABCDEF.
Из последнего блока результата удаляются разряды четности и полученная строка (56 разрядов) используется для нового шифрования исходной строки тем же способом.
Последний блок результата переводится в знаки шестнадцатиричной арифметики и объявляется конечным результатом - сверткой.

Свертка не зависит от регистра букв. Например, пары SCOTT/TIGER, Scott/Tiger, scoTT/TigeR дадут одну и ту же свертку F894844C34402B67.
Одинаковые склеенные пары имя_пользователя/пароль дают одинаковую свертку. Например, пары SCOTT/TIGER, SCOT/TTIGER, SCOTTTIG/ER дадут одну и ту же свертку F894844C34402B67.
Свертка не зависит от БД. Например, где бы мы ни создавали БД Oracle, свертка для пользователя SCOTT и пароля TIGER всегда будет F894844C34402B67.
Используется шифрование DES.

Обход парольной защиты

Не следует забывать, что подсоединение к СУБД может быть выполнено в обход проверки подлинности паролем. В Unix доверительное подключение пользователя SYS, не требующее указания пароля, возможно при работе от имени пользователя ОС, входящего в группу ОС dba, а в Windows - входящего в группу ORA_DBA, но еще при дополнительном условии, что в файлах sqlnet.ora на клиентской машине и на сервере имеется значение NTS для параметра SQLNET.AUTHENTICATION_SERVICES. При заведении ПО Oracle на Windows это значение этого параметра устанавливается автоматически, что часто игнорируется начинающими администраторами Oracle на Windows и составляет одну из наиболее популярных ошибок.

Возможно беспарольное подключение и других пользователей при условии, что имена таких пользователей в Oracle соотнесены именам пользователей ОС или же употреблены в справочнике каталогов LDAP. Устанавливаются такие свойства командами типа:

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

Пользователи Oracle с подобными свойствами тоже могут обладать привилегией SELECT ANY TABLE, позволяющей читать любые свертки (с учетом оговорки, сделанной выше).

Взлом пароля

Подбор пароля в Oracle облегчается свойствами принятого алгоритма вычисления свертки ([1]).

А) Сведение алфавита к одним только большим буквам существенно упрощает перебор. Имея в виду 26 больших букв латинского алфавита и 10 цифр, разных паролей длиною n может быть 36n; если же буквы могуг быть и большие, и маленькие, их полное число становится 52, и паролей может быть 62n. (Может показаться, что эти числа чуть преувеличены, так как Oracle не позволяет начинать пароль с цифры, однако такую проверку СУБД делает в момент установления пароля, а это легко нейтрализовать:

Но даже если бы такое ограничение существовало, оно бы не делало погоды в сокращении объемов перебора).

Б) Знание свертки и имени пользователя позволяет сократить перебор вариантов.

В) Свертка вычисляется только на основе имени и пароля, так что сам подбор можно осуществлять в собственной базе, "на стороне", не оставляя следов в исходной базе и не испытывая проблем соединения с ней.

Г) Хотя сложность взлома шифрования DES достаточно велика, по нынешним меркам этот алгоритм уже не считается достаточно стойким.

Ответ фирмы Oracle на слабости парольной защиты

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

Пример функции проверки выставляемых паролей давно имеется в штатной поставке Oracle в файле utlpwdmg.sql. Пример употребления может выглядеть так:

(Сценарий utlpwdmg.sql не только заводит функцию SYS.VERIFY_FUNCTION проверки выбираемого пользователем пароля, но и определяет парольные параметры профиля DEFAULT, в частности PASSWORD_REUSE_TIME. Чтобы отменить их действие, потребуется выставить командой ALTER PROFILE default : значения парольных параметров в UNLIMITED).

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

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

В этом же пояснении фирмы приводится ссылка на находящийся в открытом доступе документ с названием "Oracle Database Security Checklist", говорящем за себя. Документ датирован уже январем 2007 года; знакомство с ним систематизирует многое из рассмотренного выше.

Неизменным пока остается самое уязвимое место в парольной защите Oracle: алгоритм вычисления свертки. Вероятное решение этой проблемы - дождаться версии 11 СУБД Oracle. По неофициальным сведениям в этой версии будет-таки введено различие больших и малых букв в пароле и алгоритм DES заменен на более современный, SHA-1 или AES. Обработка паролей в версиях вплоть до 10.2, вероятно, меняться не будет.

1 Оба стихотворения маститых поэтов, написанные с разрывом в несколько десятков лет, посвящены одной и той же статуе, доныне сидящей в парке близ Екатерининского дворца в Царском селе, расположенном неподалеку от кажется большого города, но без названия, вместо которого на карте находится другой город, всего за 300 лет пять раз принимавший четыре разных исторических названия, два из которых пока что русские, а два - немецкие. Одна из рекомендаций, приводимых в статье - почаще и разнообразнее менять пароли пользователей.

таблица, на которую ссылаются все вышеприведенные представления.

Подмена пакетов

Разрешение имен в БД Oracle производится в следующей последовательности:

Если имеется объект с таким названием в текущей схеме, то используется он

Если имеется приватный синоним с таким названием в текущей схеме, то используется он.

Если в БД имеется общедоступный синоним с таким названием, то используется он.

Бороться с подменой пакетом можно

путем полной адресации объекта, например

SQL > exec SYS.dbms_crypto …

REVOKE EXECUTE ON UTL_SMTP FROM PUBLIC;

REVOKE EXECUTE ON UTL_TCP FROM PUBLIC;

REVOKE EXECUTE ON UTL_FILE FROM PUBLIC;

REVOKE EXECUTE ON DBMS_RANDOM FROM PUBLIC;

Обнаружение потенциальных злоумышленников производится запросом:

SELECT * FROM DBA_TAB_PRIVS

AND GRANTEE = 'PUBLIC'

SELECT GRANTEE AS USERNAME, PRIVILEGE, ADMIN_OPTION

PRIVILEGE LIKE '% ANY %'

OR PRIVILEGE LIKE '%DATABASE LINK%'

OR PRIVILEGE LIKE '%UNLIMITED%'

OR PRIVILEGE = 'BECOME USER'

OR ADMIN_OPTION = 'YES'

AND GRANTEE NOT IN (

'SYS', 'SYSTEM', 'OUTLN', 'DBSNMP',

'DBA', 'CONNECT', 'RESOURCE',

'AQ_ADMINISTRATOR_ROLE', 'OEM_MONITOR', 'CTXSYS', 'IFSSYS',

'IFSSYS$CM', 'MDSYS', 'ORDPLUGINS', 'ORDSYS',

'TIMESERIES_DBA', 'WKSYS', 'SYSMAN', 'OLAPSYS',

'OLAP_DBA', 'EXFSYS', 'SCHEDULER_ADMIN', 'WMSYS',

'SI_INFORMTN_SCHEMA', 'JAVADEBUGPRIV', 'MDDATA',

AND GRANTEE NOT IN (

WHERE ACCOUNT_STATUS != 'OPEN'

А обнаружение потенциальных Троянов производится запросом:

SELECT * FROM DBA_SYNONYMS

WHERE OWNER = 'PUBLIC'

AND NOT TABLE_OWNER IN ('SYS','SYSMAN','SYSTEM','WMSYS','EXFSYS','ORDSYS','MDSYS', 'XDB');

Пароли в трассировочных файлах

Получить пользовательские пароли можно из трассировочных файлов.

SQL >alter system set wallet open identified by 'tiger';

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

alter system set wallet open identified by 'tiger'

Пароли и OEM Grid Control

пароли к базам данных (системные пользователи, наделенные наиболее сильными привилегиями),

пароли к хостам (чтобы подключаться, когда БД не стартована)

логин и пароль на металинк.

OEMGC'у соответствует схема SYSMAN. Пароли хранятся в таблицах

Вообще-то, таблиц больше, чем три:

select object_name,object_type from dba_objects where object_name like '%CREDENTIAL%' and owner = 'SYSMAN'

Пароли, необходимые для доступа к базам данных Oracle, обычно хранятся на серверах базы данных. Администраторов баз данных такой порядок вполне устраивает, однако есть у него и свои недостатки. Если пользователь, скажем, забыл пароль и возникла необходимость его поменять, без администратора никак не обойтись. Или другой пример: синхронизацию паролей Windows и паролей баз данных Oracle можно осуществлять только вручную. А вот в системе Microsoft SQL Server встроенная функция защиты позволяет обеспечивать безопасный доступ к базе данных с помощью имен пользователей и паролей Windows. И когда пользователям нужно переустанавливать свои пароли, администратор SQL Server может поручить выполнение этой задачи сотрудникам службы поддержки.

Windows-аутентификация группы на сервере базы данных

При установке Oracle на сервере Windows система создает группу Windows ORA_DBA и автоматически включает в эту группу учетную запись Windows, использовавшуюся в ходе установки Oracle. Затем администратор базы данных может включить в эту группу других пользователей Windows, которым требуется полный набор привилегий администратора базы данных Oracle. Но нужно действовать осторожно: входящие в группу ORA_DBA локальные и доменные пользователи Windows не обязаны предъявлять пользовательские имена и пароли Oracle. В свойстве Description группы ORA_DBA указывается, что члены группы могут создавать соединения с базой данных Oracle в качестве администраторов базы данных без предъявления паролей.

Для того чтобы база данных Oracle воспринимала пользователей группы ORA_DBA как прошедших процедуру аутентификации, необходимо должным образом сконфигурировать файл sqlnet.ora, показанный на экране 1. В системах Oracle9i и Oracle8i данный файл размещается в папке \%ORACLE_HOME% etworkadmin folder, где %ORACLE_HOME% означает маршрут, используемый при установке серверных компонентов Oracle. Модифицируя файл sqlnet.ora, администратор может указывать, каким образом будут устанавливаться соединения с сервером Oracle.

Параметр NAMES.DIRECTORY_PATH файла sqlnet.ora определяет методы, используемые клиентами Oracle для разрешения псевдонима строки соединения. Например, когда в окне командной строки я ввожу символы

утилита SQL*Plus пытается разрешить псевдоним test9 с помощью записей NAMES.DIRECTORY_PATH в файле sqlnet.ora. Описание средства SQL*Plus, а также информация о том, как его можно получить, содержится во врезке «Программа SQL*Plus для управления Oracle». В соответствии с инструкциями представленного на экране 1 эталонного файла sqlnet.ora, клиент сначала пытается разрешить имя Oracle с помощью текстового файла tnsnames.ora, который размещается либо локально, либо на общем сетевом ресурсе. Если в файле tnsnames.ora данного имени нет, клиент пытается разрешить его через сервер Oracle Names (в настоящее время Oracle рекомендует вместо серверов Oracle Names использовать протокол LDAP — Lightweight Directory Access Protocol). Если же и этот метод не дает результата, клиент пытается разрешить данное имя с помощью метода разрешения имени главной машины, такого как DNS или Network Information Service (NIS).

Параметр SQLNET.AUTHENTICATION_SERVICES файла sqlnet.ora указывает, какую службу аутентификации должна применять база данных Oracle в случае, если пользователь пытается установить соединение с сервером Oracle. По умолчанию системы Oracle9i и Oracle8i активизируют службу аутентификации Windows при наличии следующей настройки:

В системе Windows NT аутентификация всегда осуществляется с помощью диспетчера NT LAN Manager (NTLM). Что же касается систем Windows Server 2003, Windows XP и Windows 2000, то в тех случаях, когда клиентская машина Oracle находится в домене Windows 2003 или Windows 2000, применяется механизм аутентификации Kerberos; в других случаях используется аутентификация NTLM. Стандартную установку, предусматривающую аутентификацию только средствами Windows, нельзя задействовать при работе с приложениями, в которых применяется стандартный метод аутентификации Oracle. И надо сказать, что в прикладных программах многих независимых поставщиков при подключении к системам Oracle применяются стандартные имена пользователей и пароли Oracle. Чтобы иметь возможность пользоваться средствами аутентификации как Oracle, так и Windows, нужно внести в указанный ниже параметр службы аутентификации серверного файла sqlnet.ora следующие изменения:

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

Группа ORA_DBA — это группа Windows, поэтому сервер базы данных Oracle обращается к ней лишь в тех случаях, когда служба SQLNET.AUTHENTICATION_SERVICES выполняет процедуру аутентификации средствами Windows. Например, если активизированы средства аутентификации Windows и в окне командной строки вводится

я могу создать привилегированное соединение SYSDBA без предъявления пользовательского имени и пароля Oracle.

Членство в группе ORA_DBA обеспечивает пользователю SYSDBA права доступа ко всем хранящимся на сервере экземплярам Oracle, потому что Windows-группа ORA_DBA владеет ролью Oracle SYSDBA. Роль SYSDBA эквивалентна роли системного администратора (systems administrator, sa) в системе SQL Server. Чтобы предоставлять права доступа с большей степенью детализации, можно создать отдельные группы общего формата ORA_SID_DBA, где SID — это набранный прописными буквами идентификатор Oracle SID, который обеспечивает пользователю SYSDBA права доступа не к определенным базам данных, а к конкретным серверам. Так, в приведенном примере значением идентификатора SID является test9, а это значит, что вы можете создать группу с именем ORA_TEST9_DBA. И теперь все пользователи Windows, которые будут включены в группу ORA_TEST9_DBA, но не войдут в группу ORA_DBA, будут иметь права доступа SYSDBA только к экземпляру базы данных Oracle TEST9.

Подобным же образом можно управлять членством пользователей в группах ORA_OPER и ORA_SID_OPER, которые соответствуют используемой в Oracle роли SYSOPER, чтобы предоставлять привилегии SYSOPER тем или иным пользователям Windows. SYSOPER располагает ограниченным подмножеством привилегий пользователя SYSDBA; аналогичный объем привилегий предоставляется роли db_backupoperator в системе SQL Server.

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

Убедитесь в существовании или создайте соответствующие группы Windows (такие, как ORA_DBA, ORA_SID_DBA, ORA_OPER, ORA_SID_OPER), необходимые для обеспечения требуемого уровня доступа к серверу базы данных Oracle.
Введите пользователей в соответствующие группы.
Позаботьтесь о том, чтобы служба SQLNET.AUTHENTICATION_SERVICES применяла средства Windows (например, NTS) для аутентификации как клиентов, так и серверов.

В системе Oracle предусмотрен графический интерфейс (см. экран 3), предназначенный для добавления пользователей в группы ORA_DBA и ORA_OPER. Если таких групп нет, их можно создать средствами графического интерфейса пользователя. Для обращения к интерфейсу необходимо нажать кнопку Start и в открывшемся списке выбрать элементы All Programs, Oracle — OraHome92, Configuration and Migration Tools, Oracle Administration Assistant for Windows NT. Чтобы добавить пользователя в Windows-группу ORA_OPER, следует щелкнуть правой клавишей мыши на узле OS Database Operators — Computer и в контекстном меню выбрать пункт Add/Remove. Когда на экране появится диалоговое окно OS Database Operators, требуется выбрать нужный домен, затем пользователя, далее щелкнуть на кнопке Add и, наконец, на кнопке OK. Система создаст группу ORA_OPER, если раньше ее не было, и включит в нее указанных пользователей.

Кстати, при выполнении аутентификации средствами Windows нужно иметь в виду следующее обстоятельство: если когда-либо в будущем потребуется воссоздать файл паролей Oracle (в папке \%ORACLE_HOME%database), обратитесь к документации Oracle и проверьте значение настройки REMOTE_LOGIN_PASSWORD в файле init.ora. Как указывается в руководстве Oracle9i Database Administrator?s Guide, значение REMOTE_LOGIN_PASSWORD определяет, как функционирует система аутентификации Oracle, что в свою очередь может повлиять на функционирование приложений, использующих механизм аутентификации Oracle.

Windows-аутентификация на сервере без группы

система возвратит результаты, показанные на экране 4. Причина сбоя в том, что клиент уже не будет пытаться подключиться к базе данных Oracle в качестве члена Windows-группы ORA_DBA. В результате объем полномочий пользователя Windows уже не соотносится автоматически с ролью Oracle через его членство в группе Windows и, следовательно, пользователь не получает авторизации в системе Oracle. Мы не используем членство в группах для аутентификации пользователя, поэтому учетная запись пользователя Windows, WinUser, передается в систему Oracle и проходит авторизацию средствами Oracle. Но Oracle предоставляет пользователю Windows определенный объем полномочий лишь в том случае, если данному пользователю соответствует пользователь Oracle. В нашем примере полностью определенное доменное имя пользователя (Fully Qualified Domain Name, FQDN) — PENTONWinUser. Чтобы этот пользователь Windows мог пройти авторизацию в базе данных Oracle, мы должны создать пользователя Oracle PENTONWinUser. Когда пользователю Windows соответствует пользователь Oracle, объем полномочий, предоставляемых данному пользователю Windows, соответствует объему полномочий определенного пользователя Oracle. При создании пользователя Oracle необходимо, чтобы имя FQDN состояло только из прописных букв и было заключено в двойные кавычки, как в приведенном ниже примере. С помощью SQL*Plus или другого клиентского инструмента мы можем подключиться к базе данных Oracle с полномочиями SYSDBA и выполнить следующие команды:

В системе Oracle предусмотрен параметр, оказывающий влияние на то, как Oracle устанавливает соответствие между именем пользователя Windows и именем пользователя Oracle. Он применяется в ситуациях, когда членство пользователя в группах Windows не указывается. В ранних версиях Oracle использовался префикс OPS$, который ставился перед именем пользователя Oracle, применяемого во внешней аутентификации. Имена пользователей в Oracle могут состоять не более чем из 30 знаков, поэтому применение префикса OPS$, в сущности, ограничивало длину имени пользователя до оставшихся 26 знаков. Чтобы не пришлось использовать префикс OPS$, содержащий параметры базы данных Oracle, файл init.ora (который хранится в папке \%ORACLE_HOME%database) должен содержать следующую настройку (она создается по умолчанию при установке систем Oracle9i и Oracle8i):

Этот параметр используется для обеспечения обратной совместимости. Oracle не рекомендует добавлять к именам префиксы, поэтому и используется приведенный выше стандартный «пустой» параметр. Чтобы система начала применять измененный параметр OS_AUTHENT_PREFIX, необходимо остановить и вновь инициализировать экземпляр базы данных Oracle.

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

Аутентификация удаленных клиентов Windows

Надо отметить, что аутентификацией клиентов Windows, использующих средства аутентификации Windows для доступа к функционирующему в той же сети удаленному серверу Oracle, операционная система этого сервера не занимается. Процедура аутентификации таких пользователей выполняется операционными системами клиентов. Чтобы активизировать средства дистанционной аутентификации, нужно в файл init.ora для данного экземпляра базы данных добавить указанную ниже запись, после чего остановить и вновь запустить базу данных:

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

Теперь представьте себе, что может произойти, если к сети подключится хакерская машина с именем PENTON. Злоумышленник может создать на своей машине локального пользователя Windows с именем WinUser, и этот пользователь будет проходить процедуру аутентификации под именем PENTONWinUser. Далее имя данного пользователя может быть передано на сервер Oracle как PENTONWinUser. Сервер Oracle не сумеет отличить доменное имя PENTON от имени PENTON, присвоенного хакерской машине, поэтому, выполняя процедуру дистанционной аутентификации, он подтвердит полномочия машины злоумышленника. По представлениям сервера Oracle, PENTONWinUser относится к категории пользователей, поэтому он наделяет этого пользователя всем объемом полномочий, причитающихся PENTONWinUser. Если доступ к сети могут получать посторонние клиентские машины, это означает, что средства дистанционной аутентификации Windows открывают среду баз данных для несанкционированного доступа.

Знакомая модель

Программа SQL*Plus для управления Oracle

SQL*Plus — утилита, позволяющая формировать запросы, модифицировать объекты базы данных Oracle и манипулировать ими, а также выполнять операции по обслуживанию баз данных. SQL*Plus инсталлируется по умолчанию при установке сервера Oracle. По набору функций версия программы с командной строкой напоминает утилиту Osql системы SQL Server. Для запуска этой версии SQL*Plus необходимо ввести в окне командной строки:

Читайте также: