Распространенное заблуждение администраторов баз данных состоит в том, что защита базы данных 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.
MetaLink и критичные обновления и исправления ошибок
Важной составляющей управления безопасностью является своевременное ознакомление с последними новостями относительно уязвимостей и установка заплат для их устранения. Компания 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 NETBSA\SAlapati sqlplusw.exe
10 4072 NETBSA\SAlapati sqlplusw.exe
10 rows selected.
SQL>Сценарий в листинге выше отображает номера потоков, связанные с каждым пользователем Oracle. Как только номера потоков получены, сеанс пользователя можно прервать, используя приведенную ниже команду (предполагается, что номером потока является 2948):
C:> orakill 2948В этой статье была дана обширная информация касательно создания пользователей, предоставления полномочий и ролей, аудита базы данных Oracle, механизмов безопасности (в том числе концепции виртуальной приватной базы данных), методам аутентификации и шифрованию данных. Для более подробного ознакомления с механизмами управления пользователями и обеспечения безопасности Oracle обращайтесь к руководству Oracle Database Security Guide (Руководство по безопасности баз данных Oracle).
