Oracle создание пользователя и настройка прав доступа
Продолжаем работать с SQL Plus! Попробуем сделать следующее, войти пользователем SYSTEM с паролем manager, а затем не закрывая плюс сменим действующего пользователя.
Запускаем плюс, вводим пользователя, пароль и название сетевой службы (proba! или что-то еще!), получилось? Замечательно! Теперь проделаем примерно следующее:
В предыдущем случае мы зашли в схему(пользователя) SCOTT с паролем доступа TIGER с помощью сетевой службы PROBA. Берите сразу на заметку или на память: в Oracle Server в паролях доступа не допускаются цифровые символы! Так же созданный пользователь, создает схему в экземпляре БД и понятие схема и пользователь в Oracle практически тождественны! Сама строка подключения, вами еще не однократно, будет использоваться в дальнейшем! Теперь, я думаю пришло время, создать собственную схему, тем более она нам понадобиться, в дальнейшем, для того, что бы научиться использовать PL/SQL! Первое и самое простое, действие, для создания нашей схемы, ввести следующее:
Для начала заходим на сервер, как администратор.
Вводим ниже приведенную строку, которая создает пользователя MILLER с паролем в системе KOLOBOK (можете написать свое!), который будет жить в табличном пространстве USER владея им целиком и захватив в свое распоряжение еще кусочек табличного пространства TEMP, так на всякий случай, пригодится.
После нажатия Enter на последней строке видим, что все прошло удачно!
Но, это только полдела, теперь этому пользователю, нужно, дать ряд прав и первостепенное, это создавать сессию с сервером! Теперь введем нижеследующее: Можно по очереди или целиком! Главное, чтобы сработал последний опреатор COMMIT. Иначе наши старания пройдут бесследно!
В результате получим кучу сообщений типа: «Привилегии предоставлены.»
И последнее: «Фиксация обновлений завершена.»
Операторы GRANT предоставляют пользователю, определенные привилегии. В типах привилегий пока, предметно разбираться не будем, скажу только, что данное мероприятие можно проделать еще проще, если собрать все строки, которые мы вводили в файл, затем использовав команду START или операцию «@»! Можете проделать это сами, предварительно введя, находясь в схеме SYSTEM:
Затем соберите все строки, в файл, скажем CrMiller.sql, поместите его в каталог, например, Temp, и введите следующее:
Выскочит множество надписей, последняя из которых должна быть: «Фиксация обновлений завершена.» Значит, все прошло нормально и пользователь создан! Дальше в схеме MILLER, мы развернем, ряд оьбектов БД и посмотрим как это будет происходить!
Так же на заметку в заключении SQL Plus, есть еще много внутренних команд, например, очень полезной может оказаться SET TIME ON приглашение примет вот такой вид:
Например, можно оценивать время на запрос из таблицы!
Если ввести SET TIME OFF, то все станет по прежнему. Например, если написать SHOW USER (мне напоминает Cisco IOS!), то увидим примерно следующее:
По ходу дела, мы познакомимся с большинством из них!
Oracle создание пользователя и настройка прав доступа
К слову сказать, в чем мы далее и убедимся. Для того, чтобы запросы пользователей могли создавать временные сегменты в табличном пространстве TEMP, им не нужны квоты на дисковое пространство. Попробуем создать пользователя! Запускайте SQL*Plus с пользователем SYS или SYSTEM пароли администраторов смотрите в шаге 5! Из всего выше сказанного, запишем вот такую конструкцию:
Здесь мы создаем пользователя (схему) DUMMY с паролем DUMB и позволяем ему резвится на 100 Мб пространства USERS и еще немного выделяем из пространства TEMP. Получаем в результате:
Ок! Пользователь (схема) создан. Наверное, можно уже подключится и начать создавать объекты! Пробуем!
Именное такой синтаксис подключения можно использовать, он еще называется строка коннекта и расписывается вот так:
Даем пользователю право создавать сессию с сервером:
Вот теперь можно немного перевести дух. Итак, мы создали пользователя, определили ему табличные пространства, назначили квоты на них. И даже позволили создавать сессию с сервером. Давайте убедимся, что пользователь создан и чувствует себя нормально. Производим переконнект на админа БД:
Дадим такой запрос к представлению DBA_USERS:
Вот теперь он может не только создавать эти объекты, но и изменять их! А, что если пользователю необходимо будет удалить какой-либо объект или удалить записи из таблиц? Тогда нужно добавить права на удаление объектов БД вот так:
Уфф! Ну вот теперь кажется все! Пользователь действительно полноценный и может работать! Помните в шаге 6 мы с вами это уже проделывали, но тогда я не вдавался в подробности, так как было не до того! А, вот теперь давайте разберемся более детально и продолжим далее.
Создание и управление пользовательскими аккаунтами
Когда пользователь подключается к БД, он подключается используя пользовательский аккаунт (user account) указывая имя аккаунта и метод аутентификации. Пользовательский аккаунт определяет первоначальные права доступа и атрибуты сессии. С пользовательским аккаунтам свзязывается схема (schema). Термины пользователь, пользовательский аккаунт и схема часто используется вместо друг друга в окружении Oracle, но это не одно и тоже. Пользователь – это человек который подключается к пользовательскому аккаунту устанавливая сессию к экземпляру БД и авторизуется используя имя аккаунта. Схема – это набор объектов принадлежащих пользовательскому аккаунту и мы рассмотрим детальнее в следующей главе. В зависимости от того как создался аккаунт будут установлены определнные аттрибуты для сесиий, некоторые из которых могут быть изменены позднее, во время существования сессии. Некоторые аккаунты создаются во время создания БД и DBA затем создаёт остальные аккаунты.
В некоторых приложениях, каждый пользователь использует свой аккаунт. Т.е. БД знает кто именно владелец каждой сессии. Такая модель хорошо работает для небольших систем но практически невозможна для среды в которой с БД работают сотник и тысячи пользователей. В больших системах пользователи подключаются к БД используя один аккаунт, и это добавляет сложностей для обеспечения безопаности сессии и аудита БД. Мы будем рассматривать модель где каждый пользователь имеет свой аккаунт.
Аттрибуты пользовательского аккаунта
У аккаунта сущуествует набор аттрибутов которые задаются при создании. Эти значения используются для сессии, и некоторые могут быть изменены либо самой сессией, либо DBA изменит значение во время существования сессии. Этими атрибутами являются
Все эти аттрибуты должны указываться в момент создания аккаунта, несмотря на то что только имя и метод аутентификации являются обязательными а для остальных существуют значения по умолчанию.
Имя аккаунта
В первом примере создается аккаунт JOHN. Имя было введено строчными буквами но было преобразовано в прописные как видно в результате выполнения запроса. Второй аккаунт был создан с использованием того же имени и двойных кавычек. Третий и четвертый пример показывают что можно обойти правила неиспользуемых символов и зарезервированных слов используя кавычки.
Имя не может быть изменено после создания. Если необходимо изменить его, то можно удалить старый аккаунт и создать новый. Это критическое действие так как все объекты в схеме аккаунта будут удалены.
Табличные пространтсва по умолчанию и лимиты
У каждого аккаунта есть табличное пространство по умолчанию. Это табличное пространство где создаются объекты схемы (такие как таблицы, индексы) создаваемые этим аккаунтом. Аккаунт может создать объекты (быть владельцем) во всех табличных пространствах к которым у него есть лимит (квота), но если явно не указывать табличное пространтсво при создании объекта – будет использователья табличное пространство аккаунта по умолчанию.
Существует значение по умолчанию для БД которое будет использоваться для всех пользователей созданных без указания табличное пространства. Это значение можно установить во время создания БД или изменить выполнив команду
ALTER DATABASE DEFAULT TABLESPACE tablespace_name ;
Если у БД нет табличного пространства по умолчанию – используется SYSTEM.
Лимит (quota) — это размер пространства которое объекты схемы аккаунта могут использовать. Вы можете создавать объекты и выделять экстенты пока не достигните лимита. Если у вас нет квоты для табличного пространтсва – вы не можете создавать объекты. Квоты можно изменять в любое время если у вас есть права для этого. Если квота пользователя была изменена в меньшую сторону, а объекты уже занимают больше места – то существующие объекты можно будет использовать,но нельзя добавить элементы или создать новые объекты.
На рисунке 6-2 отображено как проверять и устанавливать лимиты
Первая команда проверяет представление DBA_USERS и определяет табличные пространства пользователя JOHN. DBA_USERS хранит по одной строке для каждого пользователя БД. Пользователь JOHN получил значения временного и табличного пространства из значения по умолчанию БД (которые видны в результате выполнения запроса к database_properties).
Before you can create a table, you must have both permission to
execute CREATE TABLE and quota on a tablespace in which to create it.
Most users will not need any quotas, because they will never create
objects. They will only have permissions against objects owned by other
schemas. The few object-owning schemas will probably have QUOTA
UNLIMITED on the tablespaces where their objects reside.
Временное табличное пространтсво
Постоянные объекты (такие как таблицы) хранятся в постоянных табличных пространствах; временные объекты хранятся во временном табличном пространстве. Сессии нужно место во временном табличном пространстве если будет использоваться места больше чем доступно в PGA сессии. Операции которым нужно временное место (в памяти если хватает PGA или во временном таблично пространтсве) включают в себя: сортировку строк, объекдинение таблиц, построение индексов и использование временных таблиц. Каждому аккаунту выделяется временное табличное пространство и все пользовательские сессии подключенные к аккаунту будут использовать одно и тоже временное табличное пространство.
Запрос к представлению DBA_USERS на рисунке 6-2 показывает временное пространство пользователя JOHN, которое также является временным табличным простратсвном по умолчанию для БД.
Управление пространством во временных табличных пространствах полностью автоматическое. Объекты создаются и удаляются при необходимости самой БД. Пользователю не нужен лимит на временное таблично пространство, так как все объекты создаются (и он же является владельцем) аккаунтом SYS, у которого неограниченные лимиты для всех табличных пространств.
Users do not need a quota on their temporary tablespace.
Для изменения временного пространства польователя (что затронет все сессии которые подключается в будущем используя этот аккаунт) используйте команду ALTER USER
ALTER USER username TEMPORARY TABLESPACE tablespace_name;
If many users are logging on to the same user account, they will share the
use of one temporary tablespace. This can be a performance bottleneck, which
may be avoided by using temporary tablespace groups.
Профили
Пользовательские профили управляют настройками паролей и позволяют контролировать использование ресурсов. Более детально профили рассмотрим чуть ниже.
Профили полезны для управления паролями и ресурсами но могут использоваться только в среде где у каждого пользователя свой аккаунт. Если много пользователей подключаются к БД под одним аккаунтом, вы не захотите чтобы аккаунт блокировался если ввёл пароль несколько раз один пользователь, потому что этим вы заблокируете доступ всем остальным пользователям. Так же и использование ресурсов часто лучше управлять на уровне сессии а не на уровне аккаунта в целом.
Статус аккаунта
Каждый аккаунт имеет определённый статус, и значение можно увидеть в столбце ACCOUNT_STATUS представления DBA_USERS. Всего существует 9 статусов
Для блокировки или разблокирования аккаунта используются команды
ALTER USER username ACCOUNT LOCK;
ALTER USER username ACCOUNT UNLOCK;
Для запроса изменения пароля пользователем при подключении можно выполнить команду
ALTER USER username PASSWORD EXPIRE;
Эта команда автоматически установит грейс пероид, принуждая пользователя изменить пароль при следующей попытке подключения. Нет команды UNEXPIRE. Единственный способ восстановить аккаунт – это изменить пароль.
Методы аутентификации
Аккаунт должен иметь определённый метод аутентификации: что-то что позволяет определить БД есть ли у пользователя пытающегося создать сессию доступ к аккаунту. Самый простой метод это использование пароля который совпадает с паролем хранящемся в БД, но есть и альтернативы. Возможнные варианты это
Первые два метода используются только администраторами, последняя требует установленного LDAP сервера.
Аутентификация ОС и файлом паролей
Для разрешения аккаунту использования этих методов аутентификации (эти два типа используется вместе) необходимо назначить аккаунта расширенные права SYSDBA или SYSOPER
GRANT [sysdba|sysoprt] TO username;
Назначение этих прав скопирует пароль аккаунта из словаря данных во внешний файл паролей, откуда он может быть считан экземпляром даже если БД ещё не открыта. Это также позволит экземпляру аутентифицировать пользователей путём проверки принадлежит ли пользователь группе-владельцу программ Oracle. После установки БД единственный аккаунт с этими правами – это SYS.
Для использования файла паролей можно использоуть следующий синтаксис
CONNECT username/password[@db_alias] AS [SYSOPER|SYSDBA];
Аутентификация с помощью файла паролей можно использовать для подключения к удалённой БД используя Oracle Net
Чтобы использовать авторизацию ОС пользователсь должен быть авторизован ОС с доступом к исполняемым файлам Oracle и затем можно выполнить команду
CONNECT / AS [SYSOPER|SYSDBA]
Пароли ОС не хранятся Oracle и поэтому не может быть проблем со сменой пароля.
Эквивалентом этой команды может быть подключения через Database Control при выбранном значении SYSDBA в списке Connect As. Для определения у кого есть пава SYSDBA и SYSOPER можно выполнить запрос к представлению V$PWFILE_USERS. Подключение с использованием аутентифкации файлом паролей или ОС всегда доступно вне зависимости от состояния экземпляра и БД и такой вид подключения необходим для выполнения команд STARTUP и SHUTDOWN.
Третий вид привилегий SYSASM но это выходит за рамки этого курса.
Аутентификация паролем
Синтаксис для подключения используя аутентификацию паролем используя SQL *Plus
Или в Database Control выбрать NORMAL в списке Connect As. Когда подключение происходит используя аутентифкацию паролем, экземпляр проверит пароль в строке подключения с паролем который хранится для этого аккаунта в словаре данных. Для того чтобы был доступен такой метод аутентификации БД должна быть открыта; и используя этот метод невозможно выполнять команды STARTUP и SHUTDOWN.Пользователь SYS не имеет прав подключения используя аутентификацию паролем – только через файл паролей, аутентификацию ОС или LDAP.
Начиная с версии 11g пароли чувствительны к регистру. Пароль хранится именно так как был введён без всяких преобразований регистра.
Когда подключение происходит по сети, 11g всегда использует шифрование перед передачей данных. Для шифрованя данных между пользовательским процессом и серверным процессом необходимо Advanced Security Option, но шифрование пароля включено по умолчанию.
Любой пользователь может изменить пароль аккаунта в любое время, а аккаунт с расширенными правами может изменить пароль любого пользователя. Синтаксис команды
ALTER USER username IDENTIFIED BY password;
Внешняя аутентификация
Если аккаунт был создан с директивой внешней аутентификации, Oracle делегирует аутентифкацию внешнему сервису; т.е. не будет запрошен пароль. Если куплена Advanced Security Option, то внешним сервисом может быть сервер Kerberos, сервер RADIUS или сервис аутентификации Windows. Когда пользователь пытается подключиться к аккаунту, вместо аутентификации пользователя, БД будет разрешать (или не разрешать) подключение в зависимости от того авторизован или пользователь во внешнем сервисе. Например если используется Kerberos – БД проверит существует ли у пользователя валидный Kerberos токен. Без Advanced Security Option – единственно доступной формой внешней аутентификации будет аутентификация ОС. Это требует прав SYSDBA или SYSOPER (как описано выше) но может быть использовано и для обычных аккаунтов. Необходимо создать пользователя Oracle с таким же именем как и аккаунт ОС с префиксом указанном в параметре OS_AUTHENT_PREFIX. По умолчанию значение OPS$. Для проверки значения можно использовать запрос
select value from v$parameter where name=’os_authent_prefix’
В Linux/Unix внешняя аутентификация ОС работает очень просто. Предполагая что значение OS_AUTHENT_PREFIX осталось по умолчанию и есть пользователь ОС с именем jwatson, можно создать пользователя Oracle и дать права подключения следующим образом
create user ops$jwatson identified externally;
grant create session to ops$jwatson;
Пользователь подключенный к ОС как jwatson сможет подключиться к БД выполнив команду
из командной строки ОС и будет подключен к БД как пользователь ops$jwatson.
В Windows обычно используется домен и тогда команда создания пользователя будет вида
create user «OPS$JWACER\JOHN WATSON» identified externally;
Using external authentication can be very useful, but only if the users
actually log on to the machine hosting the database. Users will rarely do this,
so the technique is more likely to be of value for accounts used for running
maintenance or batch jobs.
Глобальная аутентификация
Стандартом для управления идентификацией признано использование LDAP серверов. Под глобальным пользователем (global user) подразумевается пользователь определённый в LDAP директории, и глобальная аутентификация (global authentification) значит делегирование аутентификации пользователя серверам LDAP.
Существует два метода для глобальной аутентификации
Если всё настроено как надо подключение будет создано без запроса пароля.
Создание аккаунтов
У команды CREATE USER всего два обязательных параметра: имя и метод аутентификации. Дополнительно, можно указать табличное пространство по умолчанию и временное табличное пространство, лимиты, профили и команды блокировки аккаута и управления паролем. Пример команды (номера строк добавлены для удобства)
1 create user scott identified by tiger
2 default tablespace users temporary tablespace temp
3 quota 100m on users, quota unlimited on example
4 profile developer_profile
Только первая строка обязательна – существуют значения по умолчанию для всего остального. Рассмотрим пример построчно
Каждый параметр может быть изменён командой ALTER USER кроме имени. Для смены пароля выполните команду
alter user scott identified by lion;
Смена табличных пространств
alter user scott default tablespace store_data temporary tablespace temp;
alter user scott quota unlimited on store_data, quota 0 on users;
alter user scott profile prod_profile;
Бывает необходимо удалить аккаунт, используется команда
Эта команда будет выполнена успешно только если у аккаунта нет объектов: схема пуста. Если вы не хотите вначале удалять все объекты пользователя, можно использовать директиву CASCADE
drop user scott cascade;
Для управления пользователя в Database Control из домашней страницы перейдите на вкладку Server и перейдите по ссылке Users в секции Security. В новом окне отобразятся все пользователи остортированные по дате создания. Для сортировки по какому либо столбцу нажмите на заголовок столбца. На рисунке 6-3 отображается окно Database Control
рисунок 6-3 Окно управления пользователя в Database Control
Первый аккаунт на рисунке – PUBLIC. Это формальный пользователь которому необходимо назначить права для применения прав ко всем пользователям. Кнопки CREATE и DELETE позволяют создавать и удалять пользователей.
Для изменения аттрибутов аккаунта можно выделить пользователя и нажать EDIT. Октроется окно Edit User, показанное на рисунке 6-4. Это окно можно использовать для изменения аттрибутов кроме лимитов табличных пространств. Для этого есть отдельное окно. Также здесь можно назначать и удалять права и роли.
Рисунок 6-4 Редактирование аккаунта
В данной статье рассмотрим права доступа, роли, учетные записи в Oracle
В некоторых примерах используется ранее созданная таблица test_regexp
Права в Oracle назначаются командой GRANT, отнимаются командой REVOKE
Изначально существуют аккаунты администраторов SYS и SYSTEM
Системные права
Часть из них влияет на действия c данными (создание таблиц, пользователей и т.п.)
Часть из них влияет на БД (табличные пространства, параметры БД, создание сессий)
Приведем наиболее часто используемые:
CREATE SESSION – право подключения к БД
ALTER DATABASE – право изменения БД
CREATE TABLESPACE – право создавать табличное пространтсво
ALTER TABLESPACE – право изменять табличное пространтсво
DROP TABLESPACE – право удалять табличное пространтсво
CREATE TABLE – право создавать, изменять, удалять таблицы в своей схеме
INSERT ANYTABLE – право добавлять данные в таблиц, которые не принадлежат учетной записи
UPDATE ANYTABLE – право изменять данные в таблиц, которые не принадлежат учетной записи
DELETE ANYTABLE – право удалять данные в таблиц, которые не принадлежат учетной записи
SELECT ANYTABLE – право выборки данных из таблиц, которые не принадлежат учетной записи
Синтаксис назначения прав:
GRANT privilege [,privilege…] TO User_Name;
Пример создания учетной записи (схемы) User_Name
С паролем User_Pass
Разрешаем занимаемое пространство в 10мб. от пространства по умолчанию USERS
CREATE USER User_Name IDENTIFIED BY User_Pass
DEFAULT TABLESPACE USERS QUOTA 10M ON USERS;
Пример, назначение всех основных привилегий для учетной записи:
GRANT CREATE SESSION, ALTER SESSION,
CREATE TABLE, CREATE VIEW, CREATE TRIGGER, CREATE PROCEDURE,
CREATE CLUSTER, CREATE DATABASE LINK,
CREATE SYNONYM, CREATE SEQUENCE, CREATE TYPE, CREATE OPERATOR
TO User_Name ;
В примере выше разрешено подключаться, настраивать сессию, создавать объекты в БД
Создавать объекты разрешено только в схеме аккаунта
Отсутствуют права к схемам других аккаунтов
Пример предоставления табличного пространства USERS по умолчанию для учетной записи User_Name:
ALTER USER User_Name DEFAULT TABLESPACE USERS
Создание ролей, учетных записей, пароля, связь ролей и учетных записей
Предоставление привилегий
Синтаксис:
GRANT privilege ON [schema.]object TO username [WITH GRANT OPTION];
Информация о имеющихся привилегиях
Отмена, удаление привилегий, ролей, четных записей
Пользователи 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, перечислены ниже.
Совет. Если вес для любого из четырех названных параметров не указан, он будет игнорироваться при вычислении параметра COMPOSITE_LIMIT.
Параметры паролей пользователей
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 позволяет реализовать следующие возможности по защите паролей.
Ниже показано, как с применением оператора 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.