Создание и управление ролями

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

Создание и назначение ролей

Роль – это не объект схемы: у них нет владельца и поэтому нет префикса владельца. Но они используют ту же область хранения как и пользователи: поэтому невозможно создать роль с именем уже существующего пользователя и наоборот.

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

CREATE ROLE rolename;

Затем права назначаются для роли используя обычные синтаксис команд включая WITH ADMIN или WITH GRANT OPTION если нобходимо.

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

create role hr_junior;

grant create session to hr_junior;

grant select on hr.regions to hr_junior;

grant select on hr.locations to hr_junior;

grant select on hr.countries to hr_junior;

grant select on hr.departments to hr_junior;

grant select on hr.job_history to hr_junior;

grant select on hr.jobs to hr_junior;

grant select on hr.employees to hr_junior;

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

create role hr_senior;

grant hr_junior to hr_senior with admin option;

grant insert, update, delete on hr.employees to hr_senior;

grant insert, update, delete on hr.job_history to hr_senior;

Эта роль вначале наследует роль HR_JUNIOR (можно наследовать роль от роли) с возможностью назначать роль junior другим аккаунтам или ролям. Затем назначаются права на выполнение DML команд для двух таблиц. И наконец создадим роль топ менеджмента, которая может изменять все таблицы

create role hr_manager;

grant hr_senior to hr_manager with admin option;

grant all on hr.regions to hr_manager;

grant all on hr.locations to hr_manager;

grant all on hr.countries to hr_manager;

grant all on hr.departments to hr_manager;

grant all on hr.job_history to hr_manager;

grant all on hr.jobs to hr_manager;

grant all on hr.employees to hr_manager;

Третья роль наследует роль HR_SENIOR с возможностью назначения, и затем получает контроль над данными во всех таблицах. Единственная системная привелегия для этой роли это CREATE_SESSION, полученная от HR_SENIOR, которая в свою очередь получила этот доступ от HR_JUNIOR. Даже эта роль не может создавать или удалять таблицы: это может быть сделано либо аккаунтом HR, либо аккаунтом с правами CREATE ANY TALBE или DROP ANY TABLE.

Синтаксис WITH ADMIN OPTION работает так же как и для системных прав. Не хранится кто назначил эту роль и для кого и удаление не будет каскадным.

И назначение ролей для аккаунтов может быть к примеру таким: если SCOTT это топ-менеджер, SUE – менеджер среднего звена и JON и ROOP рядовые сотрудники, то назначение ролей может быть как показано на рисунке 6-8.

Предопределённые роли

Существует как минимум 50 предопределённых ролей в БД (может быть и больше в зависимости от установки). Роли которые должен знать каждый DBA это

CONNECT – эта роль существует только для обратной совместимости. Раньше эта роль содержала системные привелении необходимые для хранения объектов. Теперь у этой роли только CREATE SESSION права.

RESOURCES – также используетя для обратной совместимости. Эта роль может создавать объекты и PL/SQL объекты. Также эта роль влючает UNLIMITED TABLESPACE права.

DBA – роль с наибольшим количеством системных привилегий, и некоторыми объектными правами и ролями. Любой пользователь с ролью DBA может управлять работой БД, за исключением команд STARTUP и SHUTDOWN.

SELECT_CATALOG_ROLE – роль имеет более двух тысяч объектных прав над словарём данных, но не имеет системных привилегий и привилегий над пользовательскими данными. Используется для младшего административного персонала к примеру выполнения задач мониторинга и отчётности.

SCHEDULER_ADMIN – роль владеет системными правами необходимыми для управления выполнением задач по расписанию.

Также существует предопределённая роль PUBLIC, которая назначается по умолчанию всем аккаунтам БД. Отсюда и следует что если права назначены для PUBLIC, то эти права автоматически доступны всем пользователям. После выполнение команды

grant select on hr.regions to public;

все пользователи смогут выполнять select к таблице HR.REGIONS.

 

TIP

The PUBLIC role is treated differently from any other role. It does not,

for example, appear in the view DBA_ROLES. This is because the source code

for DBA_ROLES, which can be seen in the cdsec.sql script called by the

catalog.sql script, specifically excludes it.

Включение ролей

По умолчанию если пользователю была назначена роль, то эта роль будет доступна (enabled).  Это значит что когда сессия создаётся (подключается аккаунт) все права (и другие роли) назначенные роли будут доступны. Такое поведение можно изменить установив роль в значение «не по-умолчанию».  Согласно правам с прошлых примеров

JON назначена роль HR_JUNIOR. У него нет прав на назначение этой роли другим пользователям, но это его роль по умолчанию – ему будет назначена эта роль при любом подключении. Такой вариант событий может быть не совсем вам нужным. Напирмер JON должен иметь доступ к данным в таблицах HR, но это не значит что вы хотите чтобы он мог смотреть данные к примеру из дома, в полночь. Вы хотите ограничить доступ таким образом, чтобы он мог иметь доступ к данным только из офиса, запуская специальную программу в рабочее время.

Чтобы изменить назначение ролей по умолчанию выполните команду

alter user jon default role none;

Теперь когда JON попробует подключиться к БД у него не будет никаких ролей по умолчанию. Но это значит что он даже не сможет подключиться – только роль HR_JUNIOR давала JON права на подключение к БД. Легко исправимо

Теперь когда JON подключится к БД у него будет подключен с ролью CONNECT – и текщая версия роли CONNECT даёт только доступ к созданию сессии. Команда для смены роли для сессии

SET ROLE rolename;

и может быть вызвана пользователем в любое время. Т.е. всё ещё не безопасно, но если роль была создана с помощью команды

CREATE ROLE rolename IDENTIFIED USING procedure_name ;

то эта роль может быть активирована только выполнение процедуры PL/SQL указанной в procedure_name. Эта процедура может делать какие –угодно проверки: проверка макси сети, имени процесса, времени и т.п. Встраивание вызовов процедур для проверки ролей в приложении может включать роли и отключать их по необходимости, оставляя их выключенными при работе в SQL *PLUS или других приложениях.

 

TIP

It can be very difficult to work out why you can see certain data. You may

have been granted the SELECT privilege on specific objects; you may have

been granted the ALL privilege; you may have SELECT ANY; SELECT may have

been granted to PUBLIC; or you may have a role to which SELECT has been

granted. You may have all of these, in which case they would all have to be

revoked to prevent you from seeing the data.