4урок по oracle sql, пользователи, роли, привилегии

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

—Работа с пользователями, ролями и привилегиями

—Создание пользователей с аутентификацией по паролю
CREATE USER CU_1 IDENTIFIED BY cupass;

—Изменение пароля
ALTER USER CU_1 IDENTIFIED BY new_cupass;

—Предоставление привилегий
—Создавать сессию с сервером
GRANT CREATE SESSION TO CU_1;

—Можно так

grant connect to CU_1;

—Создание основных лбъектов базы данных
GRANT
CREATE TABLE,
CREATE PROCEDURE,
CREATE TRIGGER,
CREATE VIEW,
CREATE SEQUENCE
TO CU_1;

—Предоставление права создавать базовые таблицы

grant resource to CU_1;

—Предоставление табличного пространства по умолчанию

alter user CU_1 default tablespace users;

—Права на ALTER(изменение объектов)
GRANT ALTER ANY TABLE TO CU_1;
GRANT ALTER ANY PROCEDURE TO CU_1;
GRANT ALTER ANY TRIGGER TO CU_1;
GRANT ALTER PROFILE TO CU_1;
—Права на удаление объектов и записей
GRANT DELETE ANY TABLE TO CU_1;
GRANT DROP ANY TABLE TO CU_1;
GRANT DROP ANY PROCEDURE TO CU_1;
GRANT DROP ANY TRIGGER TO CU_1;
GRANT DROP ANY VIEW TO CU_1;
GRANT DROP PROFILE TO CU_1;

—Создание ролей
CREATE ROLE cu_role;
—ПРедоставление привилегий роли
GRANT
CREATE TABLE,
CREATE PROCEDURE,
CREATE TRIGGER,
CREATE VIEW,
CREATE SEQUENCE
TO cu_role;
—Связь роли с пользователем
GRANT cu_role TO CU_1;

—Предоставление объектных привилегий
—На оператор SELECT для пользователя и роли
GRANT SELECT ON HR.EMPLOYEES TO CU_1, cu_role;
—На оператор UPDATE к определенным столбцам
GRANT UPDATE(FIRST_NAME, LAST_NAME) ON HR.EMPLOYEES TO CU_1, cu_role;
—На INSERT с возможностью пользователя передавать другим эту привилегию
GRANT INSERT ON HR.EMPLOYEES TO CU_1 WITH GRANT OPTION;
—Для всех пользователей на чтение
GRANT SELECT ON HR.EMPLOYEES TO PUBLIC;

—Системные привилегии для ролей
SELECT * FROM ROLE_SYS_PRIVS;
—Привилегии на таблицы для ролей
SELECT * FROM ROLE_TAB_PRIVS;
—Роли, доступные пользователю
SELECT * FROM USER_ROLE_PRIVS;
—Объектные привилегии доступные пользователю
SELECT * FROM USER_TAB_PRIVS_RECD;

—Отмена привилегий
REVOKE CREATE VIEW FROM CU_1;
REVOKE INSERT ON HR.EMPLOYEES FROM CU_1;

—Удаление роли
DROP ROLE cu_role;

—Удаление пользователя
DROP USER CU_1;

—Роли, доступные определенному пользователю
SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE = ‘CU_1’;

—Отнять роль у пользователя
REVOKE CU_ROLE FROM CU_1;

На этом — все, видео можно посмотреть на моем канале в YouTube

Источник

mirsovetov.net

Андрощук Александр, ИТ решения, советы, заметки…

Oracle список пользователей

1. Нужно вывести список пользователей которые созданы в Oracle.
2. Вывести список пользователей которые подключены и работают в данный момент

Инструментарий: Oracle 10, Oracle 11

• Для того чтобы получить список пользователей которые созданы в Oracle — нужно выполнить следующий запрос:

select
username, —Логин
account_status, —Статус аккаунта
lock_date —дата блокировки(если пользователь заблокирован)
from dba_users;

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

username	account_status	lock_date
SYS	OPEN	(null)
ANONYMOUS	EXPIRED & LOCKED	25.06.2013 12:16:22

• Чтобы вывести список всех сессий можно воспользоваться запросом:

SELECT USERNAME
FROM v$session
WHERE username IS NOT NULL
GROUP BY USERNAME;

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

username

SYS

ANONYMOUS

• Чтобы вывести список всех АКТИВНЫХ сессий можно воспользоваться запросом:

SELECT USERNAME
FROM v$session
WHERE username IS NOT NULL AND STATUS = ‘ACTIVE’
GROUP BY USERNAME;

Источник

Oracle PL/SQL •MySQL •MariaDB •SQL Server •SQLite

Базы данных

Поиск пользователя в Oracle/PLSQL

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

Описание

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

ALL_USERS

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

Синтаксис

Синтаксис для извлечения пользовательской информации из таблицы ALL_USERS в Oracle/PLSQL:

Таблица ALL_USERS содержит следующие столбцы:

Столбец	Описание
USERNAME	Имя пользователя
USER_ID	Числовой идентификатор, присвоенный пользователю
CREATED	Дата, когда пользователь был создан

DBA_USERS

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

Синтаксис для извлечения пользовательской информации из таблицы DBA_USERS в Oracle/PLSQL:

Таблица DBA_USERS содержит следующие столбцы:

Источник

oracle — список пользователей, имеющих доступ к определенным таблицам

Я уверен, что это было задано раньше, но я не могу найти соответствующие данные для следующего.

Есть ли какая-то подготовленная таблица, которая может сделать следующее (я использовал dba_tab_privs, но он ограничен и не отвечает всем моим потребностям), если у кого-нибудь нет некоторых запросов для ответа на следующее?

1. Список всех пользователей, которым была назначена определенная роль?
2. Список всех ролей, предоставленных пользователю?
3. Список всех привилегий, предоставленных пользователю?
4. Укажите, какие таблицы предоставляют определенную роль для доступа к SELECT?
5. Список всех таблиц, из которых пользователь может выбрать SELECT?
6. Список всех пользователей, которые могут выбрать SELECT на определенной таблице (либо через соответствующую роль, либо через прямой грант (т. е. выбрать выделение по возможности для joe))? Результат этого запроса также должен показать, через какую роль пользователь имеет этот доступ или был ли он прямым грантом.

2 ответа

Список всех пользователей, которым была назначена определенная роль

Список всех ролей, предоставленных пользователю

Список всех привилегий, предоставляемых пользователю

Укажите, какие таблицы определенную роль предоставляет доступ к SELECT?

Список всех таблиц, из которых пользователь может выбрать:

Список всех пользователей, которые могут выбрать SELECT в определенной таблице (либо через соответствующую роль, либо через прямой грант (т. е. выбрать выделение по возможности для joe))? Результат этого запроса также должен показать, через какую роль пользователь имеет этот доступ или был ли он прямым грантом.

Существует множество способов получить нужную информацию:

просмотр словаря данных

присутствует в оракуле.

Вы можете просто запросить представления и получить детали: Например:

выберите * из DBA_COL_PRIVS;

выберите * из ALL_COL_PRIVS;

выберите * из USER_COL_PRIVS;

Это говорит вам:

DBA-представление описывает все гранты объектов столбца в базе данных. ВСЕ просмотр описывает все гранты объекта столбца, для которых текущий пользователь или PUBLIC является владельцем объекта, лицом, предоставляющим право, или грантополучателем. Представление USER описывает столбцы, для которых текущий пользователь является владельцем объекта, лицо, предоставляющее право, или грантополучатель.

Для получения дополнительной информации проверьте это

Источник

Пользователи Oracle: управление и безопасность базы данных

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

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

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

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

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

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

• Управление доступом к данным (авторизация).
• Ограничение доступа легальных пользователей (аутентификация).
• Обеспечение подотчетности пользователей (аудит).
• Защита основных данных в базе данных (шифрование).
• Управление безопасностью всей организационной информационной инфраструктуры (безопасность предприятия).

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

Управление пользователями базы Oracle

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

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

Временное и заданное по умолчанию табличные пространства

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

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

Внимание! Если конкретное табличное пространство не назначено в качестве заданного по умолчанию, им станет табличное пространство System. Если пользователь создает очень большой объект в табличном пространстве System, он может занять весь его объем, препятствуя привилегированному пользователю SYS в создании в нем любых новых объектов, что приведет к останову базы данных. Именно по этой причине нужно всегда создавать заданное по умолчанию табличное пространство для каждого пользователя.

Создание нового пользователя

Для создания пользователя служит оператор CREATE USER. Рекомендуется каждому новому пользователю назначать как заданное по умолчанию временное, так и заданное по умолчанию постоянное табличное пространство. Если исходить из предположения, что оба эти табличных пространства уже созданы при создании базы данных, оператор CREATE USER может быть очень простым, как показано в следующем примере:

Этот оператор создает нового пользователя salapati, который имеет пароль sammyy1. Пользователю не обязательно присваивать заданное по умолчанию временное или постоянное табличное пространство (при условии, что эти табличные пространства были созданы для базы данных при ее создании). Для установки заданного по умолчанию временного табличного пространства после создания базы данных можно использовать оператор ALTER TABLESPACE DEFAULT TEMPORARY TABLESPACE. Для выяснения текущих значений заданных по умолчанию табличных пространств следует запросить представление DATABASE_PROPERTIES.

Следующий запрос отображает заданное по умолчанию постоянное (DEFAULT_TABLESPACE) и временное (TEMPORARY_TABLESPACE) табличные пространства нового пользователя:

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

Чтобы пользователь salapati мог подключиться к базе и начать обмен данными с ней, ему нужно предоставить системные полномочия CREATE SESSION, как показано в следующем примере:

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

Предположим, что заданное по умолчанию постоянное табличное пространство USERS было назначено всем пользователям. Поскольку пользователь salapati не указал табличное пространство для создания новой таблицы xyz, Oracle пытается создать ее в заданном по умолчанию постоянном табличном пространстве, т.е. USERS. Однако пользователю не была предоставлена какая-либо квота в этом табличном пространстве. По умолчанию пользователям не предоставляются никакие квоты на использование дискового пространства в любых табличных пространствах. Поскольку табличное пространство USERS назначено пользователю, но квота в нем не выделена, пользователь не может создавать какие-либо объекты в USERS. Квоты табличных пространств нужно явно выделять пользователям.

Конкретные квоты табличных пространств принято присваивать во время создания пользователя. Вот как это делается:

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

Как только новому пользователю предоставлена квота в табличном пространстве, он сможет создавать объекты базы данных, такие как таблицы и индексы. По умолчанию любые объекты, созданные пользователем, будут помещаться в заданное по умолчанию постоянное табличное пространство пользователя (в рассматриваемом примере это USERS). Однако пользователь может создавать объекты в любом табличном пространстве, если только обладает в нем квотой дискового пространства. Если требуется, чтобы пользователь имел неограниченные права использования во всех табличных пространствах, ему нужно выдать полномочия UNLIMITED TABLESPACE:

Если желаете, чтобы пользователь создавал собственные табличные пространства, это потребуется разрешить с помощью команды GRANT CREATE TABLESPACE TO имя_пользователя. Аналогично, нужно предоставить полномочия DROP TABLESPACE. Если впоследствии пользователь пожелает создать объекты в созданном им табличном пространстве, никаких квот в нем ему не понадобится. Индивидуальные квоты в дисковом пространстве, выделенные конкретному пользователю, можно просмотреть через представление DBA_TS_QUOTAS:

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

Поскольку они не являются обязательными, можно создать базу данных без заданного по умолчанию временного или постоянного табличного пространства. В подобном случае оба табличных пространства можно назначать явно при создании нового пользователя. Квоту можно присваивать также в заданном по умолчанию постоянном табличном пространстве. Ниже приведен пример создания пользователя с явным указанием заданных по умолчанию табличных пространств (временного и постоянного). Конструкция GRANT QUOTA предоставляет пользователю 500 Мбайт дискового пространства в табличном пространстве USERS, что даст пользователю возможность создавать в нем объекты:

Если опустить конструкцию QUOTA, новый пользователь не сможет использовать какой-либо объем в табличном пространстве USERS, которое является для него пространством по умолчанию. Если заданное по умолчанию постоянное табличное пространство было создано, как рекомендуют в Oracle, конструкцию DEFAULT TABLESPACE можно опустить. В противном случае ее нужно указать — или же новому пользователю в качестве заданного по умолчанию будет присвоено табличное пространство System, что не очень хорошая идея, поскольку нежелательно, чтобы пользователи имели возможность создавать объекты в этом табличном пространстве.

Изменение пользователя

Оператор ALTER USER предназначен для изменения пользователя в базе данных. С его помощью можно выполнять следующие действия:

• изменять пароль пользователя;
• присваивать квоты табличных пространств;
• устанавливать и изменять заданное по умолчанию (постоянное) и временное таб-
• личные пространства;
• назначать профили и заданные по умолчанию роли.

Ниже приведен пример того, как администратор БД (или сам пользователь) может использовать команду ALTER USER для изменения пароля пользователя:

Только администратор БД или другой пользователь, которому были выданы полномочия ALTER USER, может изменять пароли с помощью оператора ALTER USER. Пользователи могут также изменять свои пароли с помощью команды PASSWORD в интерфейсе SQL*Plus, как показано в следующем примере:

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

Удаление пользователя

Для удаления пользователя служит оператор DROP USER:

Этот оператор удалит только пользователя из базы данных, но все принадлежащие этому пользователю объекты останутся незатронутыми. Если другие объекты в базе данных зависят от данного пользователя, простую команду DROP USER нельзя будет использовать — потребуется применить оператор DROP USER. CASCADE, который удаляет пользователя, объекты схемы пользователя и любые зависимые объекты. Например:

Позже в моем блоге будет рассказано о новой корзине Oracle Recycle Bin, которая предохраняет базу данных от безвозвратного удаления таблицы при выполнении оператора DROP TABLE. Это позволяет при необходимости восстановить “удаленную” таблицу. Однако при удалении пользователя без применения корзины все таблицы и другие объекты в схеме этого пользователя будут безвозвратно удалены! Поэтому, если вы не уверены, потребуются ли объекты пользователя в будущем, но хотите лишить его доступа, просто оставьте пользователя и его схему без изменений, но запретите ему доступ к базе данных, воспользовавшись следующим оператором:

Поскольку полномочия CREATE SESSION могут быть предоставлены пользователю посредством другой роли, такой, например, как CONNECT, в Oracle рекомендуют применять оператор ALTER USER имя_пользователя ACCOUNT LOCK, чтобы гарантировать блокирование пользователя от доступа в базу данных.

Создание и использование профилей пользователя

Мы уже создали нового пользователя, присвоили ему заданное по умолчанию и временное табличные пространства, а также предоставили полномочия на подключение к базе данных. Но каков предельный объем ресурсов базы данных, который может использовать этот пользователь? Что, если он нечаянно запустит SQL-программу, которая активно поглощает ресурсы ЦП и ставит систему буквально “на колени”?

Индивидуальные ограничения на использование ресурсов в Oracle можно устанавливать с помощью профилей. Профиль (profile) — это коллекция атрибутов, связанных с использованием ресурсов и паролей, которая может быть назначена пользователю. Несколько пользователей могут разделять один и тот же профиль, и в базе данных Oracle может существовать неограниченное количество профилей. Профили накладывают жесткие ограничения на потребление ресурсов различными пользователями в базе данных и помогают ограничивать число одновременно отрытых пользователем сеансов, их продолжительность и использование ЦП и других ресурсов. Вот пример профиля, названного miser (поскольку он ограничивает использование ресурсов минимальными значениями):

При подключении пользователя, которому присвоен профиль miser, база данных разрешит поддержание соединения в течение минимум 120 секунд и осуществит выход пользователя из базы данных, если он будет бездействовать более 60 секунд. Одновременно пользователь может поддерживать не более двух открытых сеансов. Если три попытки регистрации пользователя окажутся неудачными, его учетные записи будут заблокированы на указанный период времени или до тех пор, пока администратор БД не разблокирует их вручную.

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

Параметры и предельные значения профиля

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

Параметры ресурсов

Основная причина использования параметров ресурсов — стремление предотвратить монополизацию ресурсов базы данных и сервера одним пользователем или группой пользователей. Наиболее важные параметры ресурсов, которые можно устанавливать в базе данных Oracle Database 11g, перечислены ниже.

• CONNECT_TIME. Указывает общее время (в минутах), в течение которого сеанс может оставаться подключенным к базе данных.
• CPU_PER_CALL. Ограничивает время ЦП, используемое каждым вызовом внутри транзакции (для операций анализа, выполнения и выборки).
• CPU_PER_SESSION. Ограничивает общее время ЦП, используемое во время сеанса.
• SESSIONS_PER_USER. Указывает максимальное количество сеансов, которые могут быть параллельно открыты пользователем.
• IDLE_TIME. Ограничивает время, в течение которого сеанс может оставаться бездействующим (когда никакие действия не выполняются по его инициативе).
• LOGICAL_READS_PER_SESSION. Ограничивает общее количество считываний блоков данных (из области памяти SGA и чтений с диска).
• LOGICAL_READS_PER_CALL. Ограничивает общее количество логических считываний для каждого вызова сеанса (анализа, выполнения и выборки).
• PRIVATE_SGA. Указывает пределы пространства, выделенного сеансу в компоненте разделяемого пула SGA (этот параметр применим только к системам с архитектурой разделяемого сервера).
• COMPOSITE_LIMIT. Устанавливает общий предел на использование ресурсов. Составной предел — это предел суммарного значения нескольких ранее описанных параметров ресурсов, измеряемый в сервисных единицах. Этим ресурсам назначаются веса в соответствие с их важностью. Для вычисления взвешенного значения параметра COMPOSITE_LIMIT Oracle учитывает четыре параметра: CPU_PER_SESSION, CONNECT_TIME, LOGICAL_READS_PER_SESSION и PRIVATE_SGA. Вес каждого из этих четырех параметров можно установить оператором ALTER RESOURCE COST, как показано в следующем примере.

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

Параметры паролей пользователей

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

• FAILED_LOGIN_ATTEMPTS. Указывает количество последовательных попыток регистрации, которые пользователь может предпринять, прежде чем будет заблокирован.
• PASSWORD_LIFE_TIME. Устанавливает временной предел использования конкретного пароля. Если пароль не будет изменен в течение указанного времени, срок его действия истечет.
• PASSWORD_GRACE_TIME. Устанавливает период времени, в течение которого пользователь будет предупреждаться о том, что срок действия его пароля истек. По истечении этого периода подключение к БД с помощью данного пароля будет невозможно.
• PASSWORD_LOCK_TIME. Указывает количество дней, в течение которых пользователь будет заблокирован после достижения максимального числа неудачных попыток регистрации.
• PASSWORD_REUSE_TIME. Указывает количество дней, которые должны пройти, прежде чем можно будет снова использовать тот же пароль.
• PASSWORD_REUSE_MAX. Определяет количество обязательных смен пароля перед тем, как можно будет снова использовать конкретный пароль.
• PASSWORD_VERIFY_FUNCTION. Позволяет указать предоставленную Oracle функцию проверки паролей для установки механизма автоматической проверки паролей.

Профиль, заданный по умолчанию

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

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

Результаты запроса таблицы DBA_PROFILES относительно атрибутов профиля default приведены в листинге 12.1.

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

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

Назначение профиля пользователю

Профиль можно назначить пользователю при его создании. Например:

Профиль можно назначить пользователю в любое время с помощью оператора ALTER USER, как показано в следующем примере:

Оператор ALTER USER можно использовать для установки начального профиля или для замены текущего профиля другим.

Изменение профиля пользователя

Профиль можно изменять с применением оператора ALTER PROFILE:

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

Функция управления паролями пользователей Oracle

Предлагаемый Oracle сценарий utlpwdmg.sql (из каталога $ORACLE_HOME/rdbms/admin) можно использовать для реализации различных функций управления паролями, таких как установка применяемых по умолчанию ограничений ресурсов паролей. Этот сценарий позволяет создавать функцию проверки паролей verify_function_11g. Функция verify_function_11g помогает обеспечить в базе данных требуемый уровень сложности паролей и позволяет настраивать ее для обеспечения проверки заданной сложности паролей. Функция verify_function_11g позволяет реализовать следующие возможности по защите паролей.

• Обеспечение того, чтобы все пароли содержали, по меньшей мере, восемь символов.
• Обеспечение того, чтобы каждый пароль содержал, по меньшей мере, один цифровой и один алфавитный символ.
• Обеспечение того, чтобы пароль отличался от предыдущего хотя бы тремя символами.
• Проверку того, что пароли не являются простой перестановкой символов имен пользователей.
• Проверку того, чтобы пароли не совпадали и или не были подобны имени сервера.
• Проверку того, что пароль не является набором общеизвестных или распространенных паролей, таких как “welcome1” или “database1”.

Ниже показано, как с применением оператора ALTER PROFILE в сценарии utlpwdmg.sql вначале создать функцию verify_function_11g, а затем изменить профиль default, который поставляется с базой данных и автоматически назначается всем пользователям, не имеющим другого присвоенного профиля.

Как только функция verify_function_11g создана, как показано в этом примере, база данных будет автоматически выполнять ее каждый раз, когда администратор БД или пользователь создает или изменяет пароль. Функция обеспечивает соответствие паролей указанным ею требованиям. Разумеется, функцию можно изменять для реализации более строгих проверок паролей в базе данных.

Когда изменения профиля вступают в действие?

Если установленное по умолчанию значение false параметра инициализации RESOURCE_LIMIT не будет изменено, выполненные изменения профиля никогда не будут применены. Параметр RESOURCE_LIMIT определяет, действуют ли ограничения ресурсов в профилях базы данных. Поэтому необходимо установить этот параметр в true в файле init.ora и перезапустить базу данных, или же воспользоваться командой ALTER SYSTEM, как показано ниже:

Совет. Чтобы ограничения ресурсов, установленные профилями, действовали, параметр инициализации RESOURCE_LIMIT должен быть установлен в true. В противном случае Oracle будет игнорировать ограничения, установленные в операторе CREATE PROFILE или ALTER PROFILE. Атрибуты профиля, связанные с паролями, не зависят от параметра RESOURCE_LIMIT — они автоматически активизируются при создании профиля.

Удаление профиля пользователя

Удаление профиля не представляет сложности. Например, профиль test можно удалить следующим образом:

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

Что происходит при достижении ограничений, установленных в профиле?

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

Как определить оптимальные ограничения профиля?

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

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

Постарайтесь собрать определенную информацию на основе тестовых выполнений тех или иных задач. При отсутствии надежных ретроспективных данных воспользуйтесь оператором AUDIT SESSION для сбора данных базовой линии для нескольких параметров, вроде времени подключения и количества логических чтений. Для сбора данных можно применять также OEM (Oracle Enterprise Manager — Диспетчер предприятия Oracle). Кроме того, могут пригодиться отзывы (или нарекания) самих пользователей по поводу программ, которые дают сбои из-за ограничений на использование ресурсов или требуют более длительного подключения к серверу базы данных.

Управление ресурсами

При наличии большого числа пользователей управление ресурсами становится важной задачей. Ресурсы сервера строго ограничены, и администратор должен располагать определенными средствами распределения скудных ресурсов между пользователями. Oracle предлагает мощный инструмент — Database Resource Manager (Диспетчер ресурсов базы данных), — который позволяет точно управлять использованием ресурсов базы данных.

Для управления использованием ресурсов в базе данных можно применять профили пользователей, описанные в предыдущем разделе, или Database Resource Manager. Профили пользователей эффективны при управлении использованием ресурсов отдельными пользователями, но специалисты Oracle предпочитают применять профили в основном только для управления паролями. Управлять использованием ресурсов в Oracle рекомендуют с помощью Database Resource Manager.

Источник