УСТАНОВЛЕНИЕ ПОЛИТИКИ ЗАЩИТЫ
 
 Имея многие типы механизмов для поддержания безопасности в базе
 данных ORACLE, вы должны сознательно выработать и реализовать
 политику защиты, чтобы были определены следующие аспекты:
 
 * степень защиты на уровне приложения
 
 * политика аудитинга
 
 * системные и объектные привилегии
 
 * роли базы данных
 
 * политика назначения и отзыва привилегий и ролей
 
 * политика создания, изменения и удаления ролей
 
 * политика контроля за использованием ролей
 
 Данная глава рассматривает эти вопросы и дает рекомендации по
 выработке политики защиты.
 
 Если вы используете Trusted ORACLE, вы должны рассмотреть
 дополнительные вопросы защиты; обратитесь к документу Trusted
 ORACLE7 Server Administrator's Guide.
 
 
 
Политика защиты приложений
 
 Разрабатывайте политику защиты для каждого приложения.
 Например, каждое создаваемое приложение базы данных (такое, как
 программа прекомпилятора или форма SQL*Forms) должно иметь одну
 или несколько ролей приложения, чтобы предоставлять различные
 степени защиты при исполнении этого приложения. Роли приложений
 могут назначаться ролям пользователей, либо непосредственно
 конкретным именам пользователей.
 
 Для тех приложений, которые потенциально могут позволять
 неограничиваемое исполнение предложений SQL (например, SQL*Plus
 или SQL*ReportWriter), дополнительно требуется жесткий контроль,
 чтобы предотвратить злонамеренный доступ к важным или
 конфиденциальным объектам схем.
 
 
Администраторы приложений
-------------------------
 
 В больших базах данных, имеющих много приложений (например,
 приложений прекомпиляторов, приложений SQL*Forms), вы можете
 захотеть иметь специальных администраторов приложений.
 Администратор приложений отвечает за следующие типы задач:
 
 * создание ролей для приложения и управление привилегиями
 для каждой роли этого приложения
 
 * создание и сопровождение объектов, используемых
  приложением базы данных
 
 * сопровождение и обновление кода приложения и связанных с
 ним процедур и пакетов ORACLE
 
 Во многих случаях администратором приложения является
 разработчик, создавший это приложение. Однако эти задачи могут
 и не входить в обязанности разработчика, и могут быть возложены
 на другое лицо, знакомое с приложением базы данных.
 
 
Роли и управление привилегиями приложений
-----------------------------------------
 
 Так как большинство приложений базы данных требуют множества
 разнообразных привилегий на различные объекты схем, отслеживание
 того, какие привилегии требуются для каждого приложения, может
 быть непростым делом. Кроме того, авторизация пользователей для
 работы с приложением может потребовать большого количества
 операций GRANT. Чтобы упростить управление привилегиями
 приложений, для каждого приложения необходимо создать роль и
 назначить ей все привилегии, требуемые для выполнения
 приложения. На самом деле, приложение может иметь несколько
 ролей, каждую с собственным набором привилегий, дающим больше
 или меньше возможностей при работе с приложением.
 
 
Пример
 
 Предположим, что все помощники администратора должны иметь
 возможность работать с приложением Vacation, чтобы
 регистрировать отпуска, в которые уходят сотрудники отдела. Вы
 должны:
 
 1. Создать роль VACATION.
 
 2. Назначить роли VACATION все привилегии, требуемые приложению
 Vacation.
 
 3. Назначить роль VACATION всем помощникам администратора (или
 их роли, скажем, ADMIN_ASSISTS, если она ранее определена).
 
 Группирование привилегий приложения в одну роль облегчает
 управление привилегиями. Рассмотрите следующие административные
 возможности:
 
 * Вы можете назначать пользователям, работающим с
 приложением, одну роль, а не множество иднивидуальных
 привилегий. По мере того, как обязанности сотрудников
 изменяются, необходимо выполнить всего одну операцию
 REVOKE или GRANT для роли, вместо многочисленных операций
 для индивидуальных привилегий.
 
 * Если нужно изменить привилегии, ассоциированные с
  приложением, это необходимо сделать лишь с привилегиями,
 назначенными одной роли, а не с привилегиями, которые
 были назначены всем пользователям этого приложения.
 
 * Вы можете определить, какие привилегии необходимы для
 выполнения конкретного приложения, опросив обзоры словаря
 данных ROLE_TAB_PRIVS и ROLE_SYS_PRIVS.
 
 * Вы можете определить, какие пользователи имеют привилегии
 для тех или иных приложений, опросив обзор словаря данных
 DBA_ROLE_PRIVS.
 
 
Включение ролей приложений
--------------------------
 
 Каждый пользователь может использовать много приложений и
 ассоциированных ролей. Однако вы должны разрешать пользователю
 иметь в каждый момент лишь те привилегии, которые ассоциированы
 с ролью текущего приложения, с которым работает этот
 пользователь. Например, рассмотрим следующий сценарий:
 
  * Роль ORDER (для приложения ORDER) содержит привилегию
 UPDATE для таблицы INVENTORY.
 
 * Роль INVENTORY (для приложения INVENTORY) содержит
 привилегию SELECT для таблицы INVENTORY.
 
 * Нескольким клеркам в отделе приема заказов были назначены
 обе роли, ORDER и INVENTORY.
 
 Следовательно, клерк, которому были назначены обе эти роли, при
 работе с приложением INVENTORY сможет обновлять таблицу
 INVENTORY, воспользовавшись привилегией UPDATE, которую он имеет
 благодаря роли ORDER. Однако обновление таблицы INVENTORY при
 работе с приложением INVENTORY не является санкционированной
 операцией.
 
 Чтобы избежать таких проблем, в начале каждого приложения
 выдавайте команду SET ROLE, чтобы автоматически включить
 ассоциированную с этим приложением роль, и, как следствие,
 выключить все остальные роли. С помощью команды SET ROLE каждое
 приложение динамически включает конкретные привилегии для
 пользователя лишь тогда, когда они требуются. Пользователь
 сможет воспользоваться привилегиями приложения только при работе
 с этим приложением, и не сможет (преднамеренно или нет)
 воспользоваться этими привилегиями вне контекста данного
 приложения.
 
 Предложение SET ROLE упрощает управление привилегиями тем, что,
 помимо установления контроля  над информацией, доступной
 пользователю, оно позволяет вам контролировать и то, КОГДА
 пользователь может осуществлять этот доступ. Кроме того,
 предложение SET ROLE удерживает пользователя в хорошо
  определенном домене привилегий: если пользователь получает все
 привилегии через роли, то он не сможет комбинировать эти
 привилегии, чтобы осуществить несанкционированные операции. Для
 дополнительной информации обратитесь к секции "Включение и
 выключение ролей" на странице 10-9.
 
Защита ролей приложений от пользователей разовых запросов
---------------------------------------------------------
 
 Специально написанные приложения базы данных явно контролируют
 все потенциальные действия пользователя, в том числе, включают
 или выключают те или иные роли пользователя во время работы с
 приложением. Напротив, инструменты разовых запросов, такие как
 SQL*Plus, позволяют пользователю запустить любое предложение SQL
 (которое может быть успешным или нет), в том числе, включить или
 выключить любую роль, назначенную этому пользователю. Это может
 создать серьезную проблему защиты; если не принять необходимых
 мер предосторожности, пользователь какого-нибудь приложения
 может преднамеренно или непреднамеренно выполнить операции SQL,
 разрушительные для таблиц базы данных, используя в инструменте
 разовых запросов  те привилегии, которые он получил через роль
 приложения.
 
 Например, рассмотрим следующий сценарий:
 
 * Приложение Vacation имеет соответствующую роль VACATION.
 
 * Роль VACATION включает привилегии для выполнения
 предложений SELECT, INSERT, UPDATE и DELETE по таблице
 EMP.
 
 * Приложение Vacation управляет использованием привилегий,
 полученных через роль VACATION; иными словами, приложение
  контролирует, когда выдаются те или иные предложения.
 
 Теперь рассмотрим пользователя, которому была назначена роль
 VACATION. Однако, вместо того чтобы работать с приложением
 Vacation, этот пользователь вызывает SQL*Plus. В этот момент
 пользователь имеет все привилегии, назначенные ему явно или
 через роли, в том числе через роль VACATION. Поскольку SQL*Plus
 является инструментом разовых запросов, пользователь не
 ограничен набором предопределенных действий, как это имеет место
 в целевых приложениях базы данных. Следовательно, пользователь
 может опрашивать или модифицировать данные в таблице EMP, как
 ему заблагорассудится.
 
 Чтобы избежать потенциальных проблем такого типа,
 придерживайтесь следующей политики для ролей приложений:
 
 1. Каждое приложение должно иметь несколько различных ролей:
 
 * Одна роль должна содержать ВСЕ привилегии,  необходимые
 для успешной работы приложения. В зависимости от
 ситуации, может быть несколько таких ролей, каждая из
 которых содержит больше или меньше привилегий для
 обеспечения той или иной степени защиты при работе с
 приложением. Каждая роль приложения должна быть
 защищена паролем (или должна авторизовываться
 операционной системой), чтобы предотвратить ее
 несанкционированное использование.
 
 * Другая роль должна содержать только неразрушающие
 привилегии, ассоциированные с приложением (т.е.
 привилегии SELECT для конкретных таблиц или обзоров,
 используемых в приложении). Такая "только-читающая"
 роль позволит пользователю приложения генерировать
 заказные отчеты по данным приложения с помощью
  инструментов разовых запросов, таких как SQL*Plus,
 SQL*Graph, SQL*ReportWriter и т.п.; однако, эта роль не
 позволит пользователю модифицировать данные таблиц вне
 самого приложения. Роль, назначаемая для разовых
 запросов, может быть защищена или не защищена паролем
 (или операционной системой).
 
 2. При своем запуске каждое приложение должно выдавать команду
 SET ROLE, включающую одну  из ролей, ассоциированных с этим
 приложением. Если для авторизации роли требуется пароль, то
 этот пароль должен быть включен в предложение SET ROLE внутри
 приложения (если возможно, приложение должно хранить его в
  зашифрованной форме); если авторизация роли выполняется
 операционной системой, то системный администратор должен так
 устанавливать учетные имена пользователей и приложения, чтобы
 пользователи получали необходимые привилегии операционной
 системы при вызове приложения.
 
 3. При завершении работы, каждое приложение должно выключать
 ранее включенную роль приложения.
 
 4. Пользователям приложения должны быть назначены (GRANT) все
 необходимые роли этого приложения. Администратор может
 запретить пользователю использовать данные приложения с
 инструментами разовых запросов, не назначая этому
 пользователю даже неразрушающей роли приложения.
 
 При этом подходе, каждое приложение включает подходящую роль при
 запуске приложения, и выключает ее при завершении приложения.
 Если пользователь приложения захочет использовать инструмент
 разовых запросов, он сможет включить лишь неразрушающую роль,
 предназначенную для работы с таким инструментом.
 
 Помимо этого, вы можете:
 
 * Специфицировать роли, включаемые, когда пользователь
 запускает SQL*Plus, через таблицу PRODUCT_USER_PROFILE.
 Это аналогично тому, как программа прекомпилятора или
 приложение OCI при своем запуске выдает предложение SET
 ROLE, чтобы включить конкретные роли.
 
  * Запретить использование команды SET ROLE пользователю
 SQL*Plus через таблицу PRODUCT_USER_PROFILE. Это оставит
 пользователю SQL*Plus лишь те привилегии, которые он
 имеет через роли, включенные к моменту запуска SQL*Plus.
 
 Другие инструменты разовых запросов и отчетов, такие как
 SQL*ReportWriter, SQL*Graph и т.д., также могут использовать
 таблицу PRODUCT_USER_PROFILE, чтобы ограничивать роли и команды,
  которые каждый пользователь может использовать в среде этого
 продукта. Для дополнительной информации об этих средствах
 обратитесь к документации по соответствующему инструменту.
 
 
Схемы
-----
 
 Каждое имя пользователя в базе данных считается СХЕМОЙ - доменом
 защиты, который может содержать объекты схемы. Доступ к базе
 данных и ее объектам контролируется привилегиями, назначенными
 каждой схеме.
 
 Большинство схем можно рассматривать как имена пользователей,
 т.е. учетные имена, которые позволяют пользователям соединяться
 с базой данных и обращаться к объектам в базе данных. Однако
 некоторые схемы могут не позволять соединения с базой данных, но
 используются для хранения связанных наборов объектов. Схемы
 такого сорта создаются как обычные пользователи, но им не
 назначается системная привилегия CREATE SESSION (ни явно, ни
 через роль). Однако вы должны временно назначать такой схеме
 привилегию CREATE SESSION, если хотите использовать команду
 CREATE SCHEMA, чтобы создать несколько таблиц и обзоров в одной
 транзакции.
 
 Например, можно создать такую схему для хранения объектов
 определенного приложения. Пользователи этого приложения могут
 соединяться с базой данных через свои учетные имена, вызывать
 приложение с работать с его объектами, если они имеют
  соответствующие привилегии. Однако никакой пользователь не
 сможет подключиться к базе данных под именем этой схемы, и, тем
 самым, не сможет получить бесконтрольный доступ ко всем объектам
 в этой схеме. Такая конфигурация дает дополнительный слой
 защиты для объектов базы данных.
 
 
Управление привилегиями и ролями
 
 Как часть проектирования вашего приложения, вы должны
 определить, какие типы пользователей будут работать с этим
  приложением, и какой уровень доступа должен быть позволен этим
 пользователям для выполнения их задач. Вы должны распределить
 этих пользователей по ролевым группам, а затем определить
 привилегии, которые должны быть назначены каждой роли
 приложения.
 
 Обычно через роль приложения конечным пользователям назначаются
 объектные привилегии. Объектная привилегия позволяет
 пользователю выполнять определенное действие на конкретной
 таблице, обзоре, последовательности, процедуре, функции или
 пакете. В зависимости от типа объекта, существуют различные
 типы объектных привилегий. Табл.10-1 суммирует объектные
 привилегии, которые возможны для каждого типа объекта.
 
Табл.10-1
Объектные привилегии
 
 г============T===========T===========T===========T=============¬
 ¦ Привилегия ¦ TABLE ¦ VIEW ¦ SEQUENCE ¦ PROCEDURE(1)¦
 ¦============+===========+===========+===========+=============¦
 ¦ ALTER ¦ + ¦ ¦ + ¦ ¦
 ¦------------+-----------+-----------+-----------+-------------¦
 ¦ DELETE ¦ + ¦ + ¦ ¦ ¦
 ¦------------+-----------+-----------+-----------+-------------¦
 ¦ EXECUTE ¦ ¦ ¦ ¦ + ¦
 ¦------------+-----------+-----------+-----------+-------------¦
 ¦ INDEX ¦ + (2) ¦  ¦ ¦ ¦
 ¦------------+-----------+-----------+-----------+-------------¦
 ¦ INSERT ¦ + ¦ + ¦ ¦ ¦
 ¦------------+-----------+-----------+-----------+-------------¦
 ¦ REFERENCES ¦ + (2) ¦ ¦ ¦ ¦
 ¦------------+-----------+-----------+-----------+-------------¦
 ¦ SELECT ¦ + ¦ + (3) ¦ + ¦ ¦
 ¦------------+-----------+-----------+-----------+-------------¦
 ¦ UPDATE ¦ + ¦ + ¦ ¦ ¦
 L============¦===========¦===========¦===========¦=============-
 
 (1) Включает независимые хранимые процедуры и функции, а также
  общие конструкты пакетов.
 (2) Привилегия не может быть назначена роли.
 (3) Может также назначаться снимкам.
 
 Табл.10-2 перечисляет предложения SQL, которые позволяются
 объектными привилегиями, приведенными в табл.10-1.
 
 Написав и отладив ваше приложение, вы должны создать каждую из
 его ролей и проверить сценарий работы для каждой роли, чтобы
 убедиться, что пользователи приложения будут иметь надлежащий
 доступ к базе данных. Закончив эти проверки, вы должны
 согласовать с администратором приложения, чтобы каждому
 пользователю были назначены должные роли.
 
 
Табл.10-2
Предложения SQL, допускаемые объектными привилегиями базы данных
 г============T=================================================¬
 ¦ Привилегия ¦ Допустимые предложения SQL ¦
 ¦============+=================================================¦
 ¦ ALTER ¦ ALTER объект (таблица или последовательность) ¦
 ¦ ¦ CREATE TRIGGER ON объект (только для таблиц) ¦
 ¦------------+-------------------------------------------------¦
 ¦ DELETE ¦ DELETE FROM объект (таблица или обзор) ¦
 ¦------------+-------------------------------------------------¦
 ¦ EXECUTE ¦ EXECUTE объект (процедура или функция) ¦
 ¦ ¦ Обращения к общим переменным в пакете ¦
 ¦------------+-------------------------------------------------¦
 ¦ INDEX ¦ CREATE INDEX ON объект (только таблицы) ¦
 ¦------------+-------------------------------------------------¦
 ¦ INSERT ¦ INSERT INTO объект (таблица или обзор) ¦
 ¦------------+-------------------------------------------------¦
 ¦ REFERENCES ¦ Предложение CREATE или ALTER TABLE, определяющее¦
 ¦ ¦ ограничение целостности FOREIGN KEY по объекту ¦
 ¦ ¦ (только таблицы) ¦
 ¦------------+-------------------------------------------------¦
 ¦ SELECT ¦ SELECT ... FROM объект (таблица, обзор, снимок) ¦
 ¦ ¦ Предложения SQL, использующие последовательность¦
 ¦------------+-------------------------------------------------¦
 ¦ UPDATE ¦ UPDATE объект (таблица или обзор) ¦
 L============¦=================================================-
 
Создание роли
-------------
 Использование роли может быть защищено ассоциированным паролем,
 как в следующем примере:
 
 CREATE ROLE clerk IDENTIFIED BY bicentennial;
 
 Если вам назначена роль, защищенная паролем, то вы можете
 включать или отключать эту роль, лишь предоставляя правильный
 пароль в команде SET ROLE. Для дополнительной информации см.
 страницу 10-11.
 Альтернативно, роль может быть создана так, что ее авторизация
 будет осуществляться операционной системой. Для дополнительной
 информации об этих возможностях обратитесь к документу ORACLE7
 Server Administrator's Guide.
 Если роль создана без защиты, то она может быть включена или
 выключена любым пользователем, которому она назначена.
 Приложения базы данных обычно используют средства авторизации
 ролей для того, чтобы принудительно включать роль приложения и
 выключать все остальные роли пользователя. Благодаря этому
 пользователь не сможет использовать привилегии (из роли),
 предназначенные для другого приложения. В инструментах разовых
 запросов (таких как SQL*Plus или SQL*DBA) пользователь может
 явно включать лишь те  роли, для которых он авторизован (т.е.
 либо знает пароль, либо авторизация была осуществлена
 операционной системой). Для дополнительной информации
 обратитесь к странице 10-4.
 
 Создаваемая роль должна иметь уникальное имя среди существующих
 имен пользователей и других ролей в базе данных. Роли не
 содержатся в схемах пользователей.
 Непосредственно после своего создания роль не имеет никаких
 привилегий, ассоциированных с ней. Чтобы ассоциировать
 привилегии с новой ролью, ей нужно назначить привилегии или
 другие роли.
 
Привилегии, требуемые для создания ролей
 
 Для создания роли вы должны иметь системную привилегию CREATE
 ROLE.
 
Включение и выключение ролей
----------------------------
 
 Хотя пользователю может быть назначена роль, этого недостаточно.
 Для того, чтобы привилегии, ассоциированные с этой ролью, стали
 доступными в текущей сессии пользователя, эта роль должна быть
 включена. В каждый момент времени могут быть включены
 некоторые, все или ни одной из ролей, назначенных пользователю.
 Следующие секции обсуждают, когда следует включать и выключать
 роли, и различные способы включения и выключения ролей.
 
Когда включать роли
 
 В общем, домен защиты пользователя должен всегда позволять ему
 выполнять текущую задачу, и в то же время не давать ему тех
 привилегий, которые не нужны для текущей работы. Например,
 пользователь должен иметь все привилегии, необходимые для работы
 с текущим используемым приложением базы данных, но не должен
 иметь никаких привилегий, требуемых для других приложений.
 Избыточные привилегии могут позволить пользователям работать с
 информацией несанкционированными методами.
 
 Привилегии, назначенные пользователю непосредственно, всегда
 доступны ему; поэтому непосредственно назначенные привилегии не
 могут выборочно включаться или выключаться в зависимости от
 текущей задачи. Напротив, привилегии, назначенные роли, могут
 быть выборочно сделаны доступными пользователю, которому
 назначена эта роль. Включение ролей НИКОГДА не затрагивает тех
 привилегий, которые были назначены пользователю явно. Следующие
 секции объясняют, как можно выборочно включать и выключать роли
 пользователя.
 
Умалчиваемые роли
 
 Умалчиваемая роль - это роль, которая автоматически включается
 для пользователя, когда он создает сессию. Список умалчиваемых
 ролей пользователя должен включать те роли, которые
  соответствуют его типичным служебным обязанностям.
 
 Каждый пользователь имеет список из нуля, одной или нескольких
 умалчиваемых ролей. Любая роль, непосредственно назначенная
 пользователю, может потенциально быть умалчиваемой ролью этого
 пользователя; косвенно назначенная роль (т.е. роль, назначенная
 роли) не может быть умалчиваемой ролью; лишь непосредственно
 назначенные роли могут быть умалчиваемыми ролями пользователя.
 Количество умалчиваемых ролей для пользователя не должно
 превышать максимального числа включенных ролей, которое
 допускается для пользователя (как специфицируется параметром
 инициализации MAX_ENABLED_ROLES); если число умалчиваемых ролей
 для пользователя превышает этот максимум, то при попытке
 соединения пользователю будет возвращена ошибка.
 
 Замечание: Умалчиваемая роль автоматически включается для
 пользователя, когда он создает сессию. Помещение роли в список
 умалчиваемых ролей пользователя обходит механизм авторизации
 этой роли, независимо от того, защищена ли эта роль паролем или
 операционной системой.
 
 Список умалчиваемых ролей пользователя устанавливается и
 изменяется с помощью команды SQL ALTER USER. Если список
 умалчиваемых ролей пользователя специфицирован как ALL, то
 каждая роль, назначенная пользователю, автоматически добавляется
 в его список умалчиваемых ролей. Лишь последующая модификация
 списка умалчиваемых ролей пользователя может удалить вновь
 назначенные роли из списка умалчиваемых ролей пользователя.
 
 Модификации списка умалчиваемых ролей пользователя действуют
 лишь на сессии, которые будут создаваться впоследствии; ни
 изменение пользователя (ALTER USER), ни назначения ролей не
 изменяют список умалчиваемых ролей, действующий в текущей
 сессии.
 
 
Явное включение ролей
 
 Пользователь (или приложение) может явно включить роль с помощью
 команды SQL SET ROLE. Предложение SET ROLE включает все
 специфицированные в нем роли, при условии, что они были
 назначены пользователю. Все назначенные пользователю роли,
 которые явно не специфицированы в предложении SET ROLE,
 выключаются, независимо от того, были ли они включены в этот
 момент.
 
 Если роль защищена паролем, то она может быть включена только
 путем указания пароля этой роли в предложении SET ROLE. Если
 роль не защищена паролем, то в предложении SET ROLE не требуется
 никакого пароля для этой роли. Например, предположим, что домен
 защиты пользователя Morris определен следующим образом:
 
 * Ему назначены три роли: PAYROLL_CLERK (пароль
 BICENTENNIAL), ACCTS_PAY (пароль GARFIELD) и ACCTS_REC
  (идентифицируется операционной системой). Роль
 PAYROLL_CLERK включает косвенно назначенную роль
 PAYROLL_REPORT (идентифицируемую операционной системой).
 
 * Его единственной умалчиваемой ролью является
 PAYROLL_CLERK.
 
 После создания сессии, текущей включенной ролью пользователя
 Morris будет роль PAYROLL_CLERK. Чтобы выключить эту роль и
 включить вместо нее роли ACCTS_PAY и ACCTS_REC, введите
 следующее предложение:
 
 SET ROLE accts_pay IDENTIFIED BY garfield, accts_rec;
 
 Заметьте, что в предложении SET ROLE можно специфицировать
 несколько ролей. Существуют также опции ALL и ALL EXCEPT
 предложения SET ROLE, которые тоже позволяют одновременно
 включить несколько назначенных пользователю ролей, например:
 
 SET ROLE ALL EXCEPT payroll_clerk;
 
 Это предложение демонстрирует использование опции ALL EXCEPT
 команды SET ROLE. Используйте эту опцию только тогда, когда вы
 хотите включить большинство из ролей пользователя. Следующее
 предложение включает все роли, назначенные пользователю Morris:
 
 SET ROLE ALL;
 
 Когда вы используете опцию ALL или ALL EXCEPT команды SET ROLE,
 все включаемые роли должны быть определены без паролей
 (например, они могут авторизовываться операционной системой).
 Если любая из включаемых таким способом ролей требует пароля, то
 предложение SET ROLE с опцией ALL или ALL EXCEPT откатывается, и
 возвращается ошибка.
 Пользователь может также явно включать любые косвенные роли,
 которые были назначены ему через явное назначение других ролей.
 Например, Morris может выдать следующее предложение:
 
 SET ROLE payroll_report;
 
Привилегии, требуемые для явного включения ролей
 
 Любой пользователь может использовать команду SET ROLE, чтобы
  включать любые назначенные ему роли, при условии, что тот, кто
 назначал ему эти роли, сообщил этому пользователю их пароли,
 если они требуются.
 
Включение и выключение ролей в режиме OS_ROLES = TRUE
 
 Если параметр инициализации OS_ROLES установлен в TRUE, то любая
 роль, назначенная операционной системой, может быть динамически
 включена с помощью команды SET ROLE; если эта роль была
 определена с идентификацией (через пароль или через операционную
 систему), то эта идентификация будет осуществлена. Однако в
 предложении SET ROLE нельзя указывать никакой роли, не
 идентифицированной для учетного имени в операционной системе,
 даже если эта роль была в свое время назначена предложением
 GRANT в режиме OS_ROLES = FALSE. (Если вы специфицируете такую
 роль, ORACLE игнорирует ее.)
 
 Когда OS_ROLES = TRUE, пользователь может включить столько
 ролей, сколько специфицировано параметром MAX_ENABLED_ROLES.
 Для дополнительной информации об использовании операционной
 системы для авторизации ролей обратитесь к документу ORACLE7
 Server Administrator's Guide.
 
Удаление ролей
--------------
 
 Когда вы удаляете роль, домены защиты всех пользователей и
 ролей, которым была назначена удаляемая роль, немедленно отразят
 отсутствие привилегий этой роли. Все роли, косвенно
 назначавшиеся через удаленную роль, также будут удалены из
 затрагиваемых доменов защиты. Удаление роли автоматически
 удаляет ее из списков умалчиваемых ролей всех пользователей.
 Поскольку создание объектов не зависит от привилегий, полученных
 через роль, при удалении роли не возникает никаких каскадных
 эффектов, касающихся других объектов (в частности, таблицы и
 другие объекты не удаляются при удалении роли).
 
 Для удаления роли используйте команду SQL DROP ROLE, как
 показывает следующий пример:
 
 DROP ROLE clerk;
 
Привилегии, требуемые для удаления ролей
 
 Для удаления роли вы должны либо иметь системную привилегию DROP
 ANY ROLE, либо данная роль должна была быть вам назначена с
 опцией ADMIN OPTION.
 
Назначение и отзыв привилегий и ролей
-------------------------------------
 
 Эта секция объясняет, как назначать и отзывать системные
 привилегии, роли и объектные привилегии.
 
 
Назначение системных привилегий и ролей
 
 Для назначения системных привилегий и ролей другим ролям и
 пользователям используйте команду SQL GRANT, как показано в
 следующем примере:
 
 GRANT create session, accts_pay
 TO jward, finance;
 
 Объектные привилегии НЕЛЬЗЯ назначать вместе в системными
 привилегиями и ролями в одном предложении GRANT.
 
 
 ОПЦИЯ ADMIN. Системная привилегия или роль может быть назначена
  с опцией ADMIN OPTION. (Нельзя включать опцию ADMIN OPTION в
 предложение GRANT, назначающее роль другой роли.) Пользователь,
 получивший эту специальную опцию, имеет несколько расширенных
 возможностей:
 
 * Он может назначать или отзывать эту системную привилегию
 или роль у ЛЮБОГО пользователя или роли в базе данных.
 (Однако он не может отозвать эту роль у самого себя.)
 
 * Он может далее назначать эту системную привилегию или
 роль с опцией ADMIN OPTION.
 
 * Если это роль, он может изменить или удалить эту роль.
 
 Пользователь, не получивший опцию ADMIN OPTION, не может
 выполнять таких операций.
 
 Когда пользователь создает роль, эта роль автоматически
 назначается ее создателю с опцией ADMIN OPTION.
 
 Предположим, что администратор защиты назначает роль NEW_DBA
 пользователю MICHAEL с помощью следующего предложения:
 
 GRANT new_dba TO michael WITH ADMIN OPTION;
 
 Пользователь MICHAEL может теперь не только использовать все
 привилегии, подразумеваемые ролью NEW_DBA, но может также
 назначать, отзывать или удалять роль NEW_DBA по  своему
 усмотрению.
 
Привилегии, требуемые для назначения системных привилегий или ролей
 
 Для назначения системной привилегии или роли пользователю
 требуется опция ADMIN OPTION для всех назначаемых им системных
 привилегий и ролей. Кроме того, пользователь с системной
 привилегией GRANT ANY ROLE может назначать любую роль в базе
 данных.
 
Назначение объектных привилегий
 
 Объектные привилегии могут назначаться ролям и пользователям с
 помощью команды SQL GRANT. Например, следующее предложение
 назначает объектные привилегии SELECT, INSERT и DELETE для всех
 столбцов таблицы EMP пользователям JWARD и TSMITH:
 
 GRANT select, insert, delete ON emp TO jward, tsmith;
 
 Чтобы назначить объектную привилегию INSERT только для столбцов
 ENAME и JOB таблицы EMP тем же пользователям, введите следующее
 предложение:
 
 GRANT insert(ename, job) ON emp TO jward, tsmith;
 
 Чтобы назначить все объектные привилегии по обзору SALARY
 пользователю WALLEN, используйте групповое обозначение ALL:
 
 GRANT ALL ON salary TO wallen;
 
 Объектные привилегии НЕЛЬЗЯ назначать вместе с системными
 привилегиями и ролями в одном предложении GRANT.
 
 ОПЦИЯ GRANT OPTION. Объектная привилегия может быть назначена
 пользователю с опцией GRANT OPTION. Пользователь, получивший
 эту специальную опцию, имеет несколько расширенных возможностей:
 
 * Он может назначать эту объектную привилегию любому
 пользователю или роли в базе данных.
 
 * Он может далее назначать эту объектную привилегию с
 опцией GRANT OPTION или без таковой.
 
 * Если он получил объектные привилегии для таблицы с опцией
 GRANT OPTION, и он имеет системную привилегию CREATE VIEW
 или CREATE ANY VIEW, то он может создавать обзоры по этой
 таблице, и назначать соответствующие привилегии по этому
 обзору любому пользователю или роли в базе данных.
 
 Пользователь, схема которого содержит объект, автоматически
 имеет все ассоциированные объектные привилегии для этого объекта
  с опцией GRANT OPTION.
 
 Особо заметьте, что опция GRANT OPTION недопустима при
 назначении объектной привилегии РОЛИ. ORACLE предотвращает
 распространение объектных привилегий через роли, так что
 получатели роли не могут дальше продвигать свои объектные
 привилегии, полученные через роли.
 
 
Привилегии, требуемые для назначения объектных привилегий
 
 Чтобы назначить кому-либо объектную привилегию, вы должны
 удовлетворять одному из следующих условий:
 
 * Владеть соответствующим объектом.
 
 * Иметь для объектных привилегий, которые вы хотите
 назначить, опцию GRANT OPTION.
 
Отзыв системных привилегий и ролей
 
 Для отзыва системных привилегий и ролей используйте команду SQL
 REVOKE, как показано в следующем примере:
 
 REVOKE create table, accts_rec FROM tsmith, finance;
 
 Нельзя выборочно отобрать лишь опцию ADMIN OPTION для системной
 привилегии или роли, не отбирая самой этот системной привилегии
 или роли; чтобы сделать это, отзовите системную привилегию или
 роль и заново назначьте ее без опции ADMIN OPTION.
 
 
Привилегии, требуемые для отзыва системных привилегий и ролей
 
 Любой пользователь, имеющий опцию ADMIN OPTION для системной
 привилегии или роли, может отозвать эту системную привилегию или
 роль у любого пользователя или роли базы данных (не требуется,
 чтобы пользователь, у которого отзывается привилегия или роль, в
 свое время получил ее у отзывающего пользователя). Кроме того,
 любой пользователь с системной привилегией GRANT ANY ROLE может
 отозвать любую роль.
 
 
Отзыв объектных привилегий
 
 Объектные привилегии можно отзывать с помощью команды SQL
 REVOKE. Например, предполагая, что вы предоставляли эти
 привилегии, чтобы отозвать привилегии SELECT и INSERT по таблице
 EMP от пользователей JWARD и TSMITH, введите следующее
 предложение:
 
 REVOKE select, insert ON emp
 FROM jward, tsmith;
 
 Вы можете также отозвать все привилегии по таблице DEPT (даже
  если вы назначали лишь одну привилегию), назначенные вами роли
 HUMAN_RESOURCES, введя следующее предложение:
 
 REVOKE ALL ON dept FROM human_resources;
 
 Это предложение отзовет лишь те привилегии, на которые вы имеете
 соответствующие полномочия, но не все привилегии, которые были
 назначены другими. Нельзя выборочно отозвать опцию GRANT
 OPTION, не отзывая привилегию на объект; чтобы сделать это,
 следует отозвать объектную привилегию и заново назначить ее без
 опции GRANT OPTION. Пользователь не может отозвать объектную
 привилегию у самого себя.
 
 
Отзыв выборочных объектных привилегий для столбцов
 
 Хотя пользователи могут назначать выборочные привилегии SELECT,
 UPDATE и REFERENCES по отдельным столбцам таблиц и обзоров, они
 не могут выборочно отзывать такие привилегии аналогичным
 предложением REVOKE. Вместо этого, следует сначала отозвать
 объектную привилегию по всем столбцам таблицы или обзора, а
 затем вновь выборочно назначить привилегии по тем столбцам,
 которые должны остаться.
 
 Например, предположим, что роли HUMAN_RESOURCES была назначена
 привилегия UPDATE по столбцам DEPTNO и DNAME таблицы DEPT.
 Чтобы отозвать привилегию UPDATE по столбцу DEPTNO и оставить ее
 по столбцу DNAME, вы должны ввести следующие два предложения:
 
 REVOKE UPDATE ON dept FROM human_resources;
 GRANT UPDATE (dname) ON dept TO human_resources;
 
 Здесь предложение REVOKE отзывает привилегию UPDATE по всем
 столбцам таблицы DEPT от роли HUMAN_RESOURCES. Предложение
 GRANT заново назначает привилегию UPDATE по столбцу DNAME для
 этой роли.
 
 
Отзыв объектной привилегии REFERENCES
 
 Если пользователь, получивший привилегию REFERENCES, использовал
 эту привилегию для создания ограничения внешнего ключа (которое
 существует в данный момент), то пользователь, назначавший эту
 привилегию, может отозвать ее, лишь специфицировав в предложении
 REVOKE опцию CASCADE CONSTRAINTS, например:
 
 REVOKE REFERENCES ON dept FROM jward CASCADE CONSTRAINTS;
 
 Когда специфицирована опция CASCADE CONSTRAINTS, все ограничения
 внешних ключей, использующие отзываемую привилегию REFERENCES,
 удаляются.
 
Привилегии, требуемые для отзыва объектных привилегий
 
 Для отзыва объектной привилегии требуется, чтобы вы были тем
  лицом, которое назначало эту объектную привилегию.
 
 
Каскадные эффекты отзыва привилегий
 
 В зависимости от типа привилегии, может иметь или не иметь место
 каскадный эффект при отзыве этой привилегии. Следующие секции
 объясняют несколько случаев каскадных эффектов.
 
 
 СИСТЕМНЫЕ ПРИВИЛЕГИИ. При отзыве системной привилегии,
 относящейся к операции DDL, каскадных эффектов не бывает,
 независимо от того, была ли эта привилегия назначена с опцией
 ADMIN OPTION. Например, предположим следующее:
 
 1. Вы назначаете пользователю JWARD системную привилегию CREATE
 TABLE с опцией ADMIN OPTION.
 
 2. JWARD создает таблицу.
 
 3. JWARD назначает системную привилегию CREATE TABLE
 пользователю TSMITH.
 
 4. TSMITH создает таблицу.
 
 5. Вы отзываете у пользователя JWARD системную привилегию CREATE
 TABLE.
 
 6. Таблица пользователя JWARD продолжает существовать. TSMITH
 по-прежнему имеет системную привилегию CREATE TABLE, и его
 таблица по-прежнему существует.
 
 Каскадные эффекты можно наблюдать при отзыве системной
 привилегии, связанной с операцией DML. Например, если
 пользователю назначена привилегия SELECT ANY TABLE, и этот
 пользователь создал какие-либо процедуры, то все процедуры в
 схеме этого пользователя должны быть заново откомпилированы
 после отзыва этой привилегии, прежде чем их можно будет
 использовать вновь.
 
 
 ОБЪЕКТНЫЕ ПРИВИЛЕГИИ. Отзыв объектной привилегии может привести
 к нескольким типам каскадных эффектов, которые должны быть
 исследованы перед тем, как будет выдано предложение REVOKE:
 
 * При отзыве объектной привилегии DML могут быть затронуты
 определения объектов, зависящих от этой объектной
 привилегии DML. Например, предположим, что тело процедуры
 TEST включает предложение SQL, которое опрашивает таблицу
 EMP. Если привилегия SELECT по таблице EMP будет отозвана
 у владельца таблицы EMP, то процедура перестанет успешно
 выполняться.
 
 * Определения объектов, требующие объектных привилегий DDL
 ALTER и INDEX, не затрагиваются при отзыве этих объектных
 привилегий ALTER и INDEX. Например, при отзыве
 привилегии INDEX у пользователя, создавшего индекс по не
 своей таблице, этот индекс будет по-прежнему
 существовать.
 
 * При отзыве у пользователя привилегии REFERENCES по
 таблице, все ограничения  внешних ключей, которые были
 созданы с использованием этой привилегии, автоматически
 удаляются. Например, предположим, что пользователь JWARD
 получил привилегию REFERENCES по столбцу DEPTNO таблицы
  DEPT, и создал внешний ключ по столбцу DEPTNO таблицы
 EMP, ссылающийся на столбец DEPT.DEPTNO. При отзыве
 привилегии REFERENCES по столбцу DEPTNO таблицы DEPT
 ограничение внешнего ключа по столбцу DEPTNO таблицы EMP
 будет автоматически удалено той же операцией.
 
 * Гранты (назначения) объектных привилегий, которые были
 распространены с помощью опции GRANT OPTION,
 автоматически отзываются при отзыве объектной привилегии
 у того, кто имел опцию GRANT OPTION. Например,
 предположим, что пользователь USER1 получил объектную
 привилегию SELECT с опцией GRANT OPTION, и назначил
 привилегию SELECT по таблице EMP пользователю USER2.
 Впоследствии привилегия SELECT у пользователя USER1
 отзывается. Этот отзыв каскадно распространяется и на
 пользователя USER2. Все объекты, которые зависели от
 отозванных привилегий SELECT пользователей USER1 и USER2,
 будут также затронуты.
 
Назначение и отзыв привилегий и ролей для группы PUBLIC
-------------------------------------------------------
 
 Привилегии и роли можно также назначать и отзывать у группы
 пользователей PUBLIC. Поскольку группа PUBLIC доступна каждому
 пользователю базы данных, все привилегии и роли, назначенные
 PUBLIC, доступны каждому пользователю базы данных.
 
 Вы должны назначать группе PUBLIC лишь те привилегии и роли,
 которые действительно необходимы каждому пользователю. Эта
 рекомендация согласуется с общим правилом, согласно которому в
 любой момент каждый пользователь базы данных должен иметь лишь
 те привилегии, которые требуются ему для успешного выполнения
 текущей задачи.
 
 Отзыв прав у PUBLIC может повлечь за собой значительные
 каскадные эффекты, в зависимости от того, какая привилегия
 отзывается. Если у PUBLIC отзывается любая привилегия,
 связанная с операцией DML (например, SELECT ANY TABLE, UPDATE
 ON, и т.п.), то все процедуры в базе данных (включая функции и
 пакеты) должны быть заново авторизованы, прежде чем их можно
 будет использовать снова. Поэтому будьте осторожны, назначая
 группе PUBLIC привилегии, связанные с операциями DML.
 
 
Когда имеют эффект назначения и отзывы?
---------------------------------------
 
 В зависимости от того, что назначается или отзывается, эффект
 этой операции может проявляться в различные моменты:
 
 * Все назначения/отзывы привилегий (системных и объектных)
 кому угодно (пользователям, ролям, PUBLIC) наблюдаются
 немедленно.
 
 * Все назначения/отзывы ролей кому угодно (пользователям,
 ролям, PUBLIC) наблюдаются лишь после того, как текущая
 сессия пользователя выдаст предложение SET ROLE для
 повторного включения роли, или при создании новой сессии
 пользователя.