Какое имя группы пользователей windows использует oracle для администраторов

Подтверждение идентичности пользователей баз данных с помощью пользовательских имен и паролей Windows

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

Существует возможность настраивать серверы баз данных таким образом, чтобы они использовали средства аутентификации операционной системы (по терминологии Oracle — средства внешней аутентификации), аналогичные встроенной функции аутентификации SQL Server. Но прежде чем приступить к использованию средств аутентификации Windows при предоставлении доступа к базе данных Oracle, следует разобраться, какие последствия будут иметь эти действия с точки зрения безопасности данных. Надо сказать, что детали авторизации пользователей Oracle, зарегистрированных на сервере Oracle, существенно отличаются от деталей авторизации пользователей Oracle, зарегистрированных на удаленных клиентах, поэтому в данной статье я рассматриваю оба сценария.

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 для разрешения псевдонима строки соединения. Например, когда в окне командной строки я ввожу символы

sqlplus /@test9

утилита 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 при наличии следующей настройки:

SQLNET.AUTHENTICATION_SERVICES=(NTS)

В системе 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 следующие изменения:

SQLNET.AUTHENTICATION_SERVICES= (NONE,NTS)

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

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

set oracle_sid=test9
sqlplus «/ as sysdba»

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

Значение ORACLE_SID, представленное в нашем примере в первой командной строке (оно равно test9), предоставляет альтернативный вариант строки соединения с базой данных, который файл sqlplus.exe будет использовать для подключения к экземпляру базы данных Oracle. Во второй командной строке указываются учетные данные для аутентификации. Двойные кавычки необходимы для того, чтобы программа SQL*Plus воспринимала всю строку соединения, включая пробелы, как один параметр командной строки. Синтаксическая конструкция as sysdba указывает на то, что клиент хотел бы подключиться к базе данных Oracle как зарегистрированный в системе Windows пользователь с привилегиями SYSDBA. Когда я ввел обе эти команды на своей клиентской машине Oracle, система возвратила результаты, представленные на экране 2. Если при установлении соединения пользователя с привилегиями SYSDBA программе SQL*Plus будут предъявлены имя пользователя и пароль Oracle, SQL*Plus просто проигнорирует эти данные. И такая реакция не будет нарушением правил безопасности, поскольку сервер Oracle выполнил процедуру аутентификации не по учетным данным Oracle, а по данным Windows.

Членство в группе 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, нужно выполнить следующие операции.

1. Убедитесь в существовании или создайте соответствующие группы Windows (такие, как ORA_DBA, ORA_SID_DBA, ORA_OPER, ORA_SID_OPER), необходимые для обеспечения требуемого уровня доступа к серверу базы данных Oracle.
2. Введите пользователей в соответствующие группы.
3. Позаботьтесь о том, чтобы служба 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-аутентификация на сервере без группы

А что если администратор базы данных, зарегистрированный на сервере базы данных, хочет получить при подключении к Oracle меньший объем полномочий, чем это предусмотрено для пользователя SYSDBA? Сокращение объема собственных прав — это рациональный подход, позволяющий свести к минимуму ущерб, который может быть нанесен в случае ошибочных действий администратора. В рамках нашего примера допустим, что пользователь Windows WinUser в домене PENTON зарегистрировался на сервере Windows, где установлено программное обеспечение Oracle. Обратите внимание на то, что при стандартной установке пользователь Windows, подключившийся к системе как пользователь SYSDBA, не может создавать соединения с меньшим объемом полномочий. Так, если я наберу строку

sqlplus /

система возвратит результаты, показанные на экране 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 и выполнить следующие команды:

create user «PENTONWINUSER»
 identified externally;
grant create session to «PENTONWINUSER»;

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

os_authent_prefix = «»

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

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

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

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

REMOTE_OS_AUTHENT=TRUE

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

create user «PENTONWINUSER»
 identified externally;
grant create session to «PENTONWINUSER»;

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

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

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

Джон Пол Кук (johnpaulcook@email.com) — проектировщик баз данных и информационных систем в Хьюстоне, Техас. Имеет ряд сертификатов Microsoft и Oracle. Консультирует крупные компании по SQL Server, Oracle и .NET Framework.

---

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

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

sqlplus

Версия инструмента с графическим интерфейсом размещается среди прочих программ группы Oracle Application Development. Так, если в сети каталог Oracle Home (т. е. каталог, в который устанавливается Oracle с помощью программы Oracle Universal Installer) называется OraHome92, для доступа к нему необходимо в меню Start последовательно выбрать элементы All Programs, Oracle — OraHome92, Application Development и SQL Plus. Для установки SQL*Plus на клиенте можно использовать комплект Oracle 9i Release 2, который можно загрузить на Web-узле Oracle Technology Network по адресу http://technet.oracle.com/software/products/ oracle9i/index.html.

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

---

---

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

Автоматическая безопасная конфигурация

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

• Параметры безопасности, связанные с паролем. База данных будет принудительно прекращать действие пароля и реализовывать другие политики, связанные с паролями, которые активизируют встроенную проверку сложности в используемом по умолчанию профиле пароля, назначаемом пользователям.
• Аудит. База данных по умолчанию активизирует аудит определенных полномочий. Эти полномочия, вроде полномочий подключения к БД, считаются жизненно важными для безопасности базы данных. По умолчанию база данных хранит записи аудита в таблице AUD$
  и устанавливает параметр инициализации audit_trail в db.

Применение функции автоматической безопасной конфигурации гарантирует соответствие базы данных характеристикам безопасности, рекомендуемым по результатам эталонных тестов центра Интернет-безопасности (Center for Internet Security — CIS).

Учетные записи пользователей

В Oracle рекомендуют блокировать и признавать утратившими силу все определенные по умолчанию учетные записи пользователей за исключением, естественно, учетных записей SYS и SYSTEM, а также других необходимых учетных записей наподобие DBSNMP, SYSMAN и MGMT_VIEW.

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

Пароли

Пароли пользователей Oracle не следует жестко кодировать в сценарии оболочки. В противном случае пароли пользователей можно выяснить, выдав простую команду ps -ef | grep во время выполнения процесса.

Изменяйте пароли всех созданных по умолчанию учетных записях пользователей немедленно после создания базы данных. Пароли пользователей SYS и SYSTEM следует устанавливать во время создания базы данных, хотя это и не обязательно.

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

Аутентификация операционной системой

Два параметра инициализации открывают доступ к базе данных Oracle посредством аутентификации на уровне операционной системы. Один из них — хорошо известный параметр OS_AUTHENT_PREFIX, который многие применяют для создания учетной записи OPS$, предназначенной для использования в сценариях оболочки и других местах. Разумеется, использование учетной записи OPS$ подразумевает зависимость от средств аутентификации и обеспечения безопасности операционной системы.

Второй параметр инициализации, оказывающий влияние на аутентификацию пользователей операционной системой — REMOTE_OS_AUTHENT, который позволяет пользователям, выполняющим свою аутентификацию не на сервере, а на удаленной рабочей станции, получать доступ к базе данных. Могут возникать исключительные ситуации, когда будет требоваться применение этого средства. Однако в общем случае заданное по умолчанию значение этого параметра, которым является false, необходимо оставлять без изменения. В противном случае посредством авторизации удаленной операционной системой пользователь из удаленной системы сможет входить в базу данных, применяя незащищенные протоколы. И, вероятно, еще более важно то, что любой пользователь сможет создавать на своем компьютере учетную запись, имя которой совпадает с именем внешне идентифицируемого пользователя базы данных.

Аудит базы данных

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

Аудиту Oracle следует подвергать все неудачные попытки входа в базу данных. Кроме того, аудиту можно подвергать действия любого пользователя, подключившегося в качестве SYSDBA или SYSOPER. Чтобы активизировать аудит всех операций, выполняемых пользователями SYSDBA и SYSOPER, необходимо установить следующий параметр инициализации:  AUDIT_SYS_OPERATIONS=TRUE

---

На заметку! Установка параметра AUDIT_SYS_OPERATIONS = TRUE ведет к записи всех действий пользователей SYSDBA и SYSOPER в журнал аудита операционной системы, а не в журнал аудита базы данных. В результате журнал аудита не может быть искажен пользователями, обладающими большими полномочиями внутри базы данных.

---

Предоставление прав

Для уменьшения уязвимости базы данных Oracle настоятельно рекомендует избегать предоставления прав пользователям Oracle типа ANY, таких как права на удаление ANY (т.е. любой) таблицы. Этой проблемы можно вообще избежать, отказавшись от выдачи объектных прав непосредственно пользователям. Кроме того, следует избегать предоставлять полномочия WITH ADMIN OPTION. Полномочия WITH ADMIN OPTION означают, что пользователь, которому они выданы, может, в свою очередь, предоставлять полномочия другим пользователям. В результате администратор баз данных может очень быстро потерять контроль над тем, кому и какие полномочия выдавались.

Непосредственно пользователям следует предоставлять роли, а не полномочия. Это значительно облегчает администрирование базы данных Oracle с большим количеством пользователей, в которой трудно проверить, какие полномочия были выданы непосредственно тому или иному пользователю. PUBLIC — это роль, используемая по умолчанию для каждого пользователя, созданного в базе данных. Удостоверьтесь, что этой роли не назначены никакие лишние роли или полномочия, поскольку каждый пользователь, в том числе такие создаваемые по молчанию пользователи, как DBSNMP и OUTLN, будет автоматически наследовать эти роли и полномочия.

Следующий запрос показывает, что роль PUBLIC имеет более 12 000 полномочий объектного уровня:

SQL> SELECT COUNT(*) FROM dba_tab_privs
   2 WHERE grantee='PUBLIC';

COUNT(*)
-------------
12814

SQL>

Из более чем 12 000 объектных полномочий, предоставленных роли PUBLIC, свыше 100 являются полномочиями на выполнение пакетов DBMS, таких как DBMS_JOB, DBMS_METADATA, DBMS_SNAPSHOT, DBMS_DDL, DBMS_SPACE и DBMS_OBFUSCATION_TOOLKIT. Отзовите все важные полномочия выполнения у роли PUBLIC. Выдавайте важные полномочия пользователям посредством продуманного использования ролей.

Полномочия SYSDBA наделяют пользователя очень большими возможностями, включая удаление объектов базы данных и изменение таблиц словаря данных. Не стоит и говорить, что полномочия SYSDBA следует предоставлять очень расчетливо.

Среды с несколькими администраторами баз данных

Если вы — единственный администратор баз данных Oracle в организации, то должны обладать всеми системными полномочиями, чтобы управлять базой данных. Однако, при наличии группы администраторов БД Oracle, которые управляют множеством баз данных, не стоит предоставлять каждому из них один и тот же тип полномочий (такой как SYSDBA) и один и тот же тип ролей (наподобие DBA). Следует создать собственные специализированные роли, каждая из которых должна содержать конкретный набор полномочий для решения определенных задач управления базой данных. В результате администратор БД, ответственный за оказание разработчикам помощи в создании новых объектов, не сможет выполнять определенные задачи, связанные с восстановлением, и наоборот. Затем эти роли можно назначить администраторам БД, тем самым обеспечив четкое разделение обязанностей.

Защита словаря данных

Пользователи, которым предоставлены системные полномочия ANY , могут удалять таблицы словаря данных. Чтобы защитить словарь данных, конфигурационный параметр 07_DICTIONARY_ACCESSIBILITY в файле параметров необходимо установить в FALSE. Это ограничит выдачу полномочий ANY только тем пользователям, которые регистрируются с полномочиями SYSDBA.

Настройка разрешений

Настраивайте соответствующие разрешения доступа к файлам на уровне операционной системы, поскольку на этом уровне часто могут существовать бреши в системе безопасности. В большинстве систем UNIX созданному файлу по умолчанию присваиваются разрешения rw-rw-rw. Это означает, что любые пользователи, которые допущены к серверу UNIX, могут читать или копировать все файлы, в том числе файлы базы данных. Переменную UMASK нужно установить в 022, чтобы только имя пользователя Oracle имело право выполнять чтение и запись в файлах базы данных.

Незамедлительно удаляйте SETUID из всех файлов Oracle. Некоторые файлы SETUID в системах UNIX могут разрешать выполнение сценариев от имени привилегированного пользователя.

Пакет UTL_FILE позволяет осуществлять запись в файлы операционной системы из программы PL/SQL. При использовании параметра UTL_FILE_DIR никогда не применяйте в качестве его значения символ *, который означает, что пакет мог бы выводить файлы в любой каталог файловой системы ОС. Ограничьте множество таких каталогов некоторыми общеизвестными расположениями, которые полностью отделены от выходных файлов UTL_FILE.

Удаляйте функциональную возможность EXTPROC в PL/SQL, если она не требуется. Вначале удалите ссылки на EXTPROC и в файле  listener.ora на сервере, и в файле tnsnames.ora на клиенте. После этого исполняемые файлы EXTPROC можно удалить из каталога $ORACLE_HOME/bin.

Как правило, система содержит пару исполняемых файлов — extproc и extproc0. Функция EXTPROC предоставляет взломщикам возможность проникновения в операционную систему без какой-либо аутентификации. Если функциональные возможности EXTPROC все же требуются, ознакомьтесь со статьей Note 175429.1 на сайте MetaLink компании Oracle.

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

---

На заметку! Сайт Питера Финнегана (Peter Finnegan), посвященный вопросам безопасности Oracle,  предлагает несколько интересных и полезных статей и сценариев, связанных с безопасностью Oracle, в том числе обсуждение способов обнаружения внедрения SQL-кода и множества других вопросов о безопасности Oracle. Всеобъемлющий список Oracle Database Checklist (Контрольный перечень базы данных Oracle), доступный на сайте Финнегана, предназначен для аудита инсталляций Oracle и достаточно полно отражает все аспекты безопасности базы данных Oracle.

---

Сеть и служба слушателя

Сеть и служба слушателя (TNS Listener) — уязвимые места системы безопасности Oracle. Существует множество возможностей неумышленного оставления открытых путей для атаки базы данных. Вначале рассмотрим способы укрепления службы слушателя.

Защита слушателя

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

Можно также запретить пользователю применять команду SET для вмешательства в функции слушателя. Для этого потребуется добавить следующую строку в файл конфигурации listener.ora: 

ADMIN_RESTRICTIONS=ON

По умолчанию этот параметр установлен в значение false. Следует также избегать удаленного управления службой слушателя, поскольку ее пароль не шифруется при передаче по сети. Пароль слушателя хранится в файле listener.ora, поэтому нужно защитить этот файл.

Защита сети

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

В дополнение к обычному брандмауэру можно использовать службу Oracle Net для создания дополнительного уровня защиты, названного серверными средствами контроля доступа. Серверные средства контроля доступа ограничивают возможность адреса в плане подключения к базе данных посредством службы слушателя. Существуют два способа ограничения адресов, через которые возможна установка подключений. В файле sqlnet.ora можно перечислить приглашенные (принимаемые) адреса, равно как и исключенные адреса. Всем сетевым адресам, перечисленным в списке приглашенных, подключение разрешено, а всем адресам в списке исключенных узлов доступ запрещен.

При запуске служба слушателя считывает файл sqlnet.ora и предоставляет доступ в соответствии с указанными средствами контроля доступа. Для активизации серверных средств контроля доступа при указании приглашенных адресов в файл sqlnet.ora нужно добавить следующие строки: 

tcp.validnode_checking = yes
tcp.invited_nodes = (server1.us.wowcompany.com, 172.14.16.152)

Для исключения адресов необходимо добавить следующую строку:

tcp.excluded_nodes = (server1.us.wowcompany.com, 172.14.16.152)

---

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

---

Запрет аутентификации удаленным клиентом

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

REMOTE_OS_AUTHENT=FALSE

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

Установка параметров инициализации, связанных с безопасностью

Кроме параметра инициализации SEC_CASE_SENSITIVE_LOGON, для усиления безопасности базы данных Oracle можно использовать также следующие параметры.

• sec_protocol_error_further_action

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

• sec_protocal_error_trace_action

  Позволяет указывать вид действий, которые должны предприниматься для отслеживания ошибки. Например, можно выполнять трассировку ошибки или отправлять предупреждение об ошибке.

• sec_max_failed_login_attempts

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

• ldap_directory_sysauth

  Активизирует строгую аутентификацию (использующую мандаты Kerberos или сертификаты через протокол защищенных сокетов (Secure Sockets Layer — SSL)).

Детальный контроль сетевого доступа

Связанные с сетью пакеты, такие как UTL_TCP, UTL_SMTP, UTL_MAIL, UTL_HTTP и UTL_INADDR, могут создавать бреши в безопасности, поскольку во всех этих пакетах пользователь PUBLIC обладает полномочиями выполнения. Через один из этих пакетов злоумышленник может легко проникнуть в базу данных. Для контроля доступа пользователей к базе данных через внешние сетевые службы можно применять функцию детального контроля сетевого доступа Oracle. Например, можно ограничить доступ пользователей к базам данных из определенных узлов.

Пакеты DBMS_NETWORK_ACL_ADMIN и DBMS_NETWORK_ACL_UTILITY применяются для создания так называемых списков контроля доступа (access control list — ACL). Список контроля доступа — это список пользователей и выданных им полномочий. Списками ACL можно управлять посредством Oracle XML DB. База данных хранит списки ACL в форме XML-документа в папке /sys/acl в Oracle XML DB.

Создание списка контроля доступа

Для создания списка ACL используйте процедуру CREATE_ACL пакета DBMS_NETWORK_ADMIN, как показано в следующем примере:

SQL> begin
        dbms_network_acl_admin.create_acl (
                acl                    => 'my_xml',
                description            => 'Permissions for my network',
                principal              => 'APPOWNER',
                is_grant               => 'TRUE',
                privilege              => 'connect');
     end;
SQL> 

Процедура create_acl принимает описанные ниже параметры.

• acl

  Указывает имя XML-файла, который содержит имена пользователей и полномочия, перечисленные в списке ACL.

• prinicpal

  Указывает имя пользователя и должен совпадать с именем пользователя сеанса.

• is_grant

  Показывает, выдано или запрещено данное полномочие.

• privilege

  Указывает сетевые полномочия, которые требуется предоставить или запретить. В качестве значений параметра полномочий можно указывать CONNECT
  либо RESOLVE. Пользователю нужно выдать полномочия CONNECT, если ему необходимо подключаться к базе данных посредством любого сетевого пакета PL/SQL, такого как, например, UTL_MAIL. Полномочия RESOLVE помогают получать имя хоста по заданному IP-адресу и наоборот с помощью пакета UTL_INADDR.

После создания списка ACL в него можно добавлять пользователей или полномочия, выполняя процедуру ADD_PRIVILEGE: 

SQL> begin
        dbms_network_acl_admin.add_privilege (
                acl => 'test.xml',
                prinicpal => 'test_users',
                is_grant => true,
                privilege => 'connect')
     end;
SQL>

Если список ACL, указанный в процедуре add_privilege, не существует, база данных создаст его.

Назначение списка контроля доступа хосту

Чтобы связать только что созданный список ACL с сетевым хостом, используйте процедуру ASSIGN_ACL, как показано в следующем примере: 

SQL> begin
        dbms_network_acl_admin.assign_acl (
        acl                 => 'test.xml',
        host                => '*.us.mycompany.com',
        lower_port          => 80,
        upper_port          => null);
     end;
SQL>

Списки ACL можно назначать хосту, домену или подсети IP. При этом в случае необходимости можно указывать диапазон портов TCP. При выполнении процедуры ASSIGN_ACL следует иметь в виду перечисленные ниже моменты.

• Каждому хосту, домену или подсети IP можно присваивать только один список ACL.
• При замене старого списка ACL новым база данных не удаляет старый список автоматически. Для удаления списка ACL понадобится выполнить процедуру DROP_ACL.
• Назначение списка контроля доступа можно отменить с помощью процедуры UNASSIGN_ACL.

Порядок следования хост-компьютеров

При указании символа групповой подстановки в имени хоста, такового как *, база данных присваивает список контроля всем хостам указанного домена. Списки ACL оценивают имена хостов в следующем порядке:

• полностью определенные имена хостов с указанными портами;
• полностью определенные имена хостов;
• поддомены внутри домена.

Аналогично, списки ACL, присвоенные отдельным IP-адресам, получают приоритет над ACL, присвоенными подсетям.

Проверка полномочий и назначений хостов

Для выяснения того, какие полномочия предоставлены пользователю в списке ACL, применяйте функцию CHECK_PRIVIELGE, как показано в следующем примере: 

SQL> SELECT DECODE(dbms_network_acl_admin.check_privilege (
                         test.xml', 'hr','resolve'),
                         1, 'granted', 0, 'denied', null) privilege
     FROM DUAL;

Выполнение этой функции приведет к возврату значения 0, если полномочие было запрещено, и значения 1 — если оно было предоставлено. Если полномочие не было ни предоставлено, ни запрещено, функция возвращает значение NULL.

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

Регулярно публикуемые предупреждения об угрозах безопасности Oracle можно найти на следующей странице. Новости о брешах в системе безопасности можно также найти в разделе News & Notes (Новости и замечания) сайта MetaLink. При желании Oracle будет присылать предупреждения о новых проблемах безопасности по электронной почте. На эту бесплатную услугу можно подписаться, зарегистрировавшись на веб-странице.

Ежеквартально Oracle выпускает обновления Critical Patch Updates (Критичные обновления и исправления ошибок), о чем клиенты Oracle ставятся в известность посредством MetaLink, страницы OTN Security Alerts (Предупреждения безопасности OTN) и Oracle Security RSS. Если вы уже являетесь подписчиком MetaLink, то автоматически подписались на получение обновлений Critical Patch Updates. Если заплата устраняет серьезную угрозу, Oracle не будет дожидаться квартального выпуска Critical Patch Update, чтобы прислать файлы заплаты. В подобных случаях Oracle через сайт MetaLink опубликует внеплановое предупреждение о безопасности и позволит немедленно загрузить заплату. Эта заплата будет включена также в следующий квартальный выпуск обновлений Critical Patch Update. Однако в большинстве случаев обновления Critical Patch Updates будут основным способом распространения большинства заплат компанией Oracle.

Critical Patch Updates — это всеобъемлющий набор заплат, которые устраняют серьезные бреши в безопасности и включают в себя пригодные для применения исправления, необходимые предпосылки для устранения брешей в безопасности либо то и другое. В результате администраторы получают в свое распоряжение поквартальный график применения заплат в системе. Применение единой заплаты один раз в квартал удобнее использования множества заплат, которые нуждаются в тщательном тестировании и могут конфликтовать друг с другом.

Наряду с ежеквартальным обновлением Critical Patch Updates также представлена новая таблица рисков (Risk Matrix). Таблица Risk Matrix позволяет клиентам оценить область и серьезность каждой уязвимости, устраненной каждым обновлением Critical Patch Update. Матрица Risk Matrix указывает угрозу, существующую для конфиденциальности, целостности и доступности данных, и рассматривает условия, при которых система становится наиболее уязвимой. Это позволяет оценить риск, существующий для конкретных систем, и определить приоритет применения заплат к этим системам.

Опция Advanced Security Oracle

Oracle не требует использования своей опции Advanced Security (Расширенная безопасность) для защиты баз данных. Однако эта опция предлагает настолько много мощных функций обеспечения безопасности, что ее применение целесообразно, если бизнес-деятельность нуждается в наивысшей степени безопасности данных и сети.

Ниже перечислены некоторые дополнительные функции безопасности, доступные при использовании опции Advanced Security Oracle.

• Шифрование сетевого трафика между клиентами, серверами приложений и базами данных.
• Развитые методы аутентификации пользователей.
• Централизованное управление пользователями.
• Поддержка инфраструктуры открытых ключей (Public Key Infrastructure — PKI).

Безопасность приложения

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

Предоставление полномочий посредством ролей

Мы уже рассмотрели использование ролей для инкапсуляции полномочий вместо их выдачи непосредственно различным пользователям. Необходимо минимизировать количество прямо предоставляемых объектных полномочий, делая средством выдачи операторов DML пользователями хранимый код, такой как процедуры и пакеты. Затем можно просто предоставить пользователю полномочия по выполнению определенного пакета или процедуры для выполнения любых действий DML. По завершении работы пакета или процедуры пользователь лишится полномочий на выполнения любых действий DML извне хранимого кода.

Отключение ролей

Все роли приложений должны использовать оператор SET ROLE для активизации ролей, назначенных пользователям. Роли должны предоставляться пользователям приложений только для конкретных целей, и они должны отзываться, когда больше не нужны.

Владельцы приложений должны подумать о создании безопасных ролей приложения, которые включаются с помощью пакетов PL/SQL. Как только безопасная роль приложения создана и назначена пользователю, она будет автоматически присваиваться пользователю при его входе в базу данных.

Ограничение использования SQL*Plus

Одна из первых задач, которую необходимо выполнить при открытии базы данных для широкой публики — это жесткое ограничение возможности применения интерфейса SQL*Plus пользователями. Возможности пользователя по применению SQL*Plus можно ограничить с помощью таблицы product_user_profile.

Полезные методики управления пользователями

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

Изменение профилей

Следующий код демонстрирует изменение профиля пользователя:

SQL> ALTER PROFILE fin_user
   2 LIMIT
   3 FAILED_LOGIN_ATTEMPTS 5
   4 PASSWORD_LOCK_TIME 1;
     
   Profile altered.
SQL>

Вывод информации о пользователе

Для получения довольно большого объема информации о пользовательском “населении” базы данных можно обратиться к представлению DBA_USERS. Типичный запрос к представлению DBA_USERS выглядит следующим образом: 

SQL> SELECT username, profile, account, status
FROM dba_users;

USERNAME     PROFILE    ACCOUNT_STATUS
----------   --------   ---------------
SYS          DEFAULT    OPEN
SYSTEM       DEFAULT    OPEN
OUTLN        DEFAULT    OPEN
DBSNMP       DEFAULT    OPEN
HARTSTEIN    DEFAULT    OPEN
FINANCE      DEFAULT    OPEN

SQL>

Выяснение SQL-запроса, выполняемого пользователем в данный момент

Запрос, приведенный в листинге ниже и соединяющий таблицы V$SESSION и V$SQLTEXT, можно использовать для получения текста SQL-кода, выполняемого пользователем в конкретный момент времени.

---

SQL> SELECT a.sid,a.username,
   2 s.sql_text
   3 FROM v$session a,v$sqltext s
   4 WHERE a.sql_address = s.address
   5 AND a.sql_hash_value = s.hash_value
   6 AND a.username LIKE 'HR%'
   7 * ORDER BY a.username,a.sid,s.piece;

SID        USERNAME    SQL_TEXT
--------   ---------   -----------------------------------
8          HR          BEGIN dbms_stats.gather_table_stats
                       ('HR','REGIONS'); END;
SQL>

---

Регистрация в качестве другого пользователя

Иногда для выполнения определенных действий необходимо зарегистрироваться в качестве другого администратора БД. Однако даже пользователь DBA Oracle не имеет доступа к паролям пользователей, которые хранятся в зашифрованном виде. Можно было бы применить оператор ALTER USER, чтобы изменить пароль пользователя, но нежелательно создавать неудобства пользователю, изменяя пароль без нужды.

В подобных случаях можно временно изменить пароль и воспользоваться новым паролем для входа в базу данных в качестве этого пользователя. Прежде чем изменять пароль, извлеките исходный шифрованный пароль, который затем можно будет применить для восстановления пароля пользователя. Шифрованные пароли всех пользователей можно извлечь из представления USER$, например:

SQL> SELECT 'alter user tester identified by values '||password||';'
   2 FROM user$
   3 * WHERE username='TESTER';
     'ALTERUSERTESTERIDENTIFIEDBYVALUES'||';'

---------------------------------------------------------
alter user tester identified by values 1825ACAA229030F1;

SQL>

Теперь измените пароль пользователя tester, чтобы можно было зарегистрироваться под именем этого пользователя:

SQL> ALTER USER tester IDENTIFIED BY newpassword; 

По завершении применения учетной записи пользователя tester снова введите оператор ALTER USER, чтобы вернуть пароль этого пользователя к исходному значению. Не забудьте заключить шифрованный пароль в одинарные кавычки. 

SQL> ALTER USER tester IDENTIFIED BY VALUES '1825ACAA229030F1';
     User altered.
SQL>

Прерывание сеанса пользователя

Команда ALTER SYSTEM служит для прерывания сеанса любого пользователя. Вначале понадобится запросить представление V$SESSION на предмет значений SID (идентификатор сеанса) и serial# (последовательный номер) пользователя. Затем, имея полученные значения идентификатора сеанса и последовательного номера, можно прервать сеанс данного пользователя. Например: 

SQL> SELECT sid, serial# FROM v$session
   2 * WHERE username='SALAPATI';

SID   SERIAL#
----------------
10        32

SQL> ALTER SYSTEM KILL SESSION '10,32';

System altered.

SQL>

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

Прерывание UNIX-процесса пользователя, скорее всего, приведет и к прерыванию сеанса Oracle, но это — не самый изящный способ завершения сеанса. Если требуется прервать сеанс UNIX пользователя, а команда KILL SESSION Oracle не работает или занимает длительное время, можно достаточно быстро прервать сеанс, воспользовавшись командой kill из UNIX. Обратите внимание, что команду kill можно применять как саму по себе, так и с ключом -9, но в большинстве случаев для прерывания сеанса UNIX пользователей Oracle достаточно простой команды kill: 

$ kill 345678 или $ kill -9 345678

Следующий сценарий позволяет извлечь из динамического представления V$SESSION номер процесса (а также SID и порядковый номер):

SQL> SELECT process, sid, serial# FROM v$session
WHERE username='&user';

Enter value for user: SALAPATI

old 2: username='&user'
new 2: username='SALAPATI'

PROCESS     SID    SERIAL#
---------   ----   -------
2920:2836   10     34
SQL>

В системах Windows концепция процессов не используется, но все процессы пользователей являются потоками одного и того же процесса .exe Oracle. Для прерывания сеанса пользователя Oracle в системе Windows можно применить утилиту ORAKILL, которая завершит конкретный поток в процессе .exe Oracle.

Предположим, что нужно прервать сеанс пользователя. Как же выяснить поток этого пользователя? В листинге ниже демонстрируется применение простого запроса для идентификации потока любого пользователя в системе Windows.

---

SQL> SELECT sid, spid as thread, osuser, s.program
   2 FROM v$process p, v$session s
   3 * WHERE p.addr = s.paddr;

SID         THREAD     OSUSER           PROGRAM
---------   --------   ------           ---------------------
1           1192       SYSTEM           ORACLE.EXE
2           1420       SYSTEM           ORACLE.EXE
3           1524       SYSTEM           ORACLE.EXE
4           1552       SYSTEM           ORACLE.EXE
5           1528       SYSTEM           ORACLE.EXE
6           1540       SYSTEM           ORACLE.EXE
7           1580       SYSTEM           ORACLE.EXE
8           1680       SYSTEM           ORACLE.EXE
9           2948       NETBSASAlapati  sqlplusw.exe
10          4072       NETBSASAlapati  sqlplusw.exe

10 rows selected.

SQL>

---

Сценарий в листинге выше отображает номера потоков, связанные с каждым пользователем Oracle. Как только номера потоков получены, сеанс пользователя можно прервать, используя приведенную ниже команду (предполагается, что номером потока является 2948): 

C:> orakill 2948

В этой статье была дана обширная информация касательно создания пользователей, предоставления полномочий и ролей, аудита базы данных Oracle, механизмов безопасности (в том числе концепции виртуальной приватной базы данных), методам аутентификации и шифрованию данных. Для более подробного ознакомления с механизмами управления пользователями и обеспечения безопасности Oracle обращайтесь к руководству Oracle Database Security Guide (Руководство по безопасности баз данных Oracle).

1. Пользователи STU не создают таблицу разрешения → нуждаются в SYS или системных пользователей для расширения возможностей

Система по умолчанию: менеджер

Sys по умолчанию: config_on_install

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

Но если это пользователь SYS, пароль должен быть добавлен в виде SYSDBA, то есть полный пароль: config_on_install as sysdba

SQLPLUS: ALTER USER DBANAMA NACK Unlock; разблокировать учетную запись входа

SQLPLUS: ALTER USER DBANAME ACCALL LOCK SCALL; замораживание входа в систему

SQLPLUS: ALTER USER DBANAME, идентифицируемый «паролем»; изменить пароль учетной записи входа

2, System / Manager Войти, WolatiLized Независимо от пользователя, в основном подключаются к выбору SYSDBA, подсказку: недостаточные привилегии;

Используйте SQLPLUS, чтобы работать с недостаточными привилегиями,

(Поиск местоположения файла sqlplus.exe, расположенный в e: myoracle Oracle product 11.2.0 dbhome_1 bin;

Администратор запускает CMD для ввода этого каталога;

Откройте командную строку SQLPLPLUS так, чтобы не войти в систему: SQLPLUS / Nog;

Подключите командную строку экземпляра базы данных как DBA: Connect / AS Sysdba, на этот раз ошибка

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

User sys as sysdba password change_on_install, подсказку: предоставить отклоненный пароль, главное влияние — это ключевое слово в имени пользователя: как sysdba будет вызвать подсказку

3, 2 проблемы могут быть четыре случая:

1. Проверьте, является ли SQLNET.ORA (под каталог% Oracle_Home% / Network / Admin под файлом% Oracle_Home% / Network / Admin в $ Oracle_Home / Network / admin / Add): sqlnet.authentication_services = (NTS), нет слов,

Мой файл Расположение:E: myoracle Oracle Product 11.2.0 dbhome_1 Network admin, глобальный поиск будет повторяться, является одним из сотен байтов

2. Проверьте, чтобы войти в пользователей Windows (использование пользователя при использовании Oracle) входит в группу ORACLE) в группе ORA_DBA, пользователь домена может иметь это явление, когда пользователь домена даже не подключается к серверу верхнего домена.

3. Чтобы убедиться, что параметры remust_Login_PasswordFile = Exclusive.

SQL> show parameter password; NAME TYPE VALUE ———————————— ———— —————————— remote_login_passwordfile string EXCLUSIVE (Это решение очень очаровано методом просмотра с использованием командной строки. Он не может войти в SYS.

4. См. Если вам нужно использовать ORAPASSW для создания файла пароля, изменить файл пароля под $ Oracle_Home / DBS

Ночная экземпляра Пароль файла PWDORCL.ORA Расположение: E: Myoracle Oracle Product 11.2.0 dbhome_1 База данных все искажена

orapwd file=orapw$ORACLE_SID  password=orcl  entries=5; 

Если вы несколько экземпляров, установите набор Oracle_SID =

Просмотр разрешений с Sysdba

SQL> select * from v$pwfile_users; 

USERNAME                       SYSDB SYSOP SYSAS                                

—————————— —— —— ——                                

SYS                            TRUE  TRUE  FALSE 

4, ORA_DBA — это уникальный пользователь Oracle, с привилегиями Super Administrator, который имеет DBA, которая имеет наибольшее разрешение на управление базой данных. Для вышеуказанной серой линии 2 нет никакой конфигурации пользователя и группы или выше и не может быть реализован. Попробуйте решить ее с DOS:

1. Вход в систему администратора, проверьте текущую систему пользователя: Net User, показать все текущие пользователи

2, чистая локальная группа посмотреть группу пользователей

3, Net LocalGroup ORA_DBA Просмотр определенных пользователей под группой пользователей ORA_DBA, результат не показывает местных пользователей

 

4, добавьте этот аппарат администратора в группу пользователя ORA_DBA: чистая локальная группа ORA_DBA Administrator / Add Add, ах, обратите внимание на пространство, пользователь добавил неправильно на скриншоте, должен перейти к S, обратите внимание на предыдущие пользователи машины в конце

Теперь убедитесь, что ORA_DBA будет иметь пользователь локального администратора.

5, выполнить sqlplus / как sysdba в это время

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

Затем поиск пост также оsqlnet.oraКонфигурация файла, упомянутьSqlnet.authentication_services = (NTS) не обязательно устанавливается, поэтому я пытался прокомментировать,

#SQLNET.AUTHENTICATION_SERVICES= (NTS)

Возьми! Но принцип последнего шага не был понят.

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

Учетные записи пользователей

Учетные записи пользователей – это уникальные имена и пароли, которые используются для определения пользователя или клиентского приложения, подключившегося к базе данных. В ArcGIS учетные записи определяют, кто какими данными владеет. Учетные записи пользователя также являются способом управления типом доступа (если имеется) пользователя или клиентского приложения к базе данных или базе геоданных и их наборам данных.

В Oracle вы можете создавать учетные записи пользователей базы данных или создать учетные записи базы данных на основе сетевых учетных записей или учетных записей операционной системы.

Не используйте разделители, такие как кавычки, для создания имени пользователя или группы, содержащего символы или регистр, не поддерживающиеся базой данных. Если объект базы данных, например, имя пользователя, создан с использованием разделителей, их также следует использовать при запросе к данному объекта. ArcGIS не использует разделители вокруг имен объектов при запросах к базе данных. Поэтому если база данных не поддерживает символы учетной записи или имени группы, указанные без разделителей, установить подключение из ArcGIS к базе данных не удастся.

Владение данными

В ArcGIS пользователь, создающий таблицы, классы объектов и представления базы геоданных или базы данных, является владельцем этих наборов данных. Например, если администратор базы геоданных создает базу геоданных, то он является владельцем системных таблиц базы геоданных, которые создаются в СУБД в это время. Поэтому пользователь, который создает класс объектов, является его владельцем.

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

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

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

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

Доступ пользователей

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

При работе с базами данных Oracle используются два типа аутентификации: аутентификация средствами операционной системы и аутентификация в базе данных.

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

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

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

Предоставляемые пользователям типы прав доступа зависят от типа работы, которую им требуется выполнять. Некоторым пользователям необходимо только подключение к базе данных для просмотра определенных данных. Другим пользователям необходимо создавать новые наборы данных. В следующем разделе объясняется, как учетные записи пользователей могут быть сгруппированы для упрощения управления правами доступа.

Группы пользователей и роли

Большинство систем управления базами данных предоставляют администратору базы данных способы группировки пользователей с учетом их потребностей в доступе к данным и предоставления прав группе. Это позволяет уменьшить временные потери, вызванные изменениями прав отдельных пользователей, и упрощает управление большим числом прав доступа сразу для нескольких пользователей. Поэтому вы можете использовать группы (которые также называются ролями, типами или уровнями доступа в СУБД), которые предоставляют права пользователям, исходя из их рабочих обязанностей.

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

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

Кроме того, большинство СУБД имеют предустановленные группы. Одна из таких ролей – роль PUBLIC.

Группа или роль PUBLIC по существу является переменной, которая приравнивается к любому пользователю, подключившемуся к базе данных, поэтому любое право, предоставленное группе PUBLIC, предоставляется любому пользователю, подключенному к базе данных. Могут возникнуть ситуации, когда все пользователи требуют предоставления определенного права. Например, для подключения к базе данных SQL Server или DB2 пользователь должен иметь право CONNECT. Поскольку всем пользователям необходимо это право для подключения, SQL Server и DB2 выдают его группе PUBLIC по умолчанию.

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

Для изучения других предустановленных групп обратитесь к документации вашей СУБД.

Советы по группировке пользователей

Ниже дается несколько советов по группировке пользователей в СУБД:

• Создайте отдельные группы (роли) с правами доступа к системе и к объектам. Это позволит администратору базы геоданных управлять правами доступа к базе данных путем выдачи их системным группам, а владельцам данных управлять правами доступа к своим наборам данных путем выдачи их группам.
• Выберите правила именования, которые отражают тип каждой группы (роли). Например, группу, которая имеет возможность редактировать все данные земельных участков, можно назвать LANDBASE_EDITORS.
• Предоставьте права непосредственно администратору базы геоданных, а другим пользователям предоставляйте права через группы (роли). Учетная запись администратора базы геоданных является особенной. В большинстве случаев в любой базе геоданных существует только один такой пользователь, и он не участвует в логической группе пользователей. Опытные администраторы баз данных назначают права доступа учетной записи администратора напрямую. В отличие от них, неадминистраторские учетные записи должны получать права через группы, которые отображают описание их работы, степени ответственности за выполнение проекта или другую логическую классификацию в пределах организации.
• Старайтесь не смешивать роли с непосредственно предоставленными правами с учетными записями остальных пользователей. Если неадминистраторская учетная запись получает права напрямую и через роль, хорошо спланированная модель безопасности превращается в неуправляемую структуру, требующую большого количества времени и усилий на ее восстановление. Задавайте правила для владельцев данных при предоставлении доступа к их данным.

  В редких случаях, когда неадминистратор действительно нуждается в особых мерах безопасности, можно напрямую предоставить ему некоторые права, чтобы не усложнять модель безопасности на основе ролей. Такие случаи необходимо документировать; они должны быть исключением из правил.