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

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

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

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

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

—Можно так

grant connect to CU_1;

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

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

grant resource to CU_1;

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

alter user CU_1 default tablespace users;

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

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

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

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

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

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

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

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

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

Источник

Как узнать роли пользователя oracle

Какого-то юзера
select * from dba_role_privs
where grantee=:user

Свои (текущего юзера)
select * from user_role_privs

Допустим мне необходимо проверить роль IMP_FULL_DATABASE у пользователя у которого есть только роль DBA. Как добавить в список все роли закрепленных за другими ролями и т.д., так что бы получился полный список ролей закрепленных за пользователем.

Похоже только рекурсивно выбирать все роли для уже выбранных ролей, ибо connect by на запросе к dba_role_privs не проходит.

> [4] KygECHuK © (28.07.06 09:54)

Я ж говорю, одним запросом с connect by дает ошибку.

← →
roottim © ( 2006-07-28 10:35 ) [7]

все действующие в сессии роли тут:
select * from session_roles

Представь что ты выполняеш все операторы ddl, dml в работающую схему..
какие операторы? Достаточно взглянуть в экспортный dump.
Т.е почистить схему надо бы: drop user balda cascade

← →
Desdechado © ( 2006-07-28 15:44 ) [11]

Источник

АУДИТ ПОЛЬЗОВАТЕЛЕЙ ORACLE БАЗЫ ДАННЫХ ШТАТНЫМИ СРЕДСТВАМИ

Добрый день! Сегодняшняя статья посвящена аудиту пользователей в БД. Все примеры работают на БД Oracle, но используемые алгоритмы и срезы проверок, вероятно, есть во всех распространенных базах, просто немного иначе реализуются.

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

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

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

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

Итак, начну с последнего и наиболее простого с точки зрения реализации пункта – мониторинга привилегий пользователей на каждый объект БД. Для создания этого представления хватило системной таблицы dba_tab_privs, в которой содержатся все пользователи и их полномочия, а также те, кто выдал эти полномочия. Итак, запустим следующий код:

Результат этого кода показывает, к каким объектам БД (OWNER, TABLE_NAME, TYPE) имеет доступ конкретный пользователь (GRANTEE), и какие полномочия у него есть для работы с каждым объектом БД (PRIVS_TO_OBJECT_BD):

Иными словами, суть представления – показать доступные действия пользователя для каждого объекта БД (в данном случае связка Пользователь БД + Объект БД – уникальна).

Отлично, двигаемся дальше. Теперь рассмотрим код для сбора различных системных атрибутов по каждому пользователю БД. Ввиду сложности кода разобьём его на составные части (для удобства выделим связанные атрибуты в SQL-блоки “with”). Так, сначала определимся с перечнем пользователей, по которым будем собирать аналитику. В нашем случае мы исключили пользователей, которые в качестве default_tablespace используют системные пространства БД:

Данный код использует системное представление dba_users и собирает некоторые атрибуты, например, текущий статус пользователя (открыт/заблокирован/…), дату блокировки пользователя, а также профайл пользователя (администратор/пользователь/технологическая учетная запись):

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

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

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

Результат исполнения кода:

Обратите внимание, дополнительно оконная sql-функция считает количество ПК, с которых осуществлялся вход под выбранным пользователем (атрибут PC_CNT).

Далее — в рамках оценки активности пользователей необходимо понимать их период активности, актуальность «учетки» в текущем году, а также количество успешных авторизаций на сервере. Эти задачи исполняет следующий код:

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

Обратите внимание, атрибут ACTIVE_IN_CURRENT_YEAR использует не статичный год, а год из системной даты (to_char(TIMESTAMP, ‘YYYY’)). Столбец LOGONS_CNT – количество успешных авторизаций пользователя на сервере.

Далее, выделим права каждого пользователя, для этого используем 2 таблицы Oracle DB: dba_role_privs и dba_tab_privs:

И второй код, для dba_tab_privs:

В столбце CNT_ROLE_PRIVELEGES – количество ролей каждого пользователя. Здесь можно отследить критичные. Например, для нас возможность пользователя просматривать содержимое всех таблиц на сервере – недопустима, поэтому все роли “select any table” были заменены на “select table”, что позволяет выводить содержимое только созданных пользователем таблиц. В принципе готово, осталось собрать все блоки “with” в одно представление с помощью конструкции JOIN:

Результат итогового представления (для наглядности показан в виде single record view):

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

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

Источник

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

Стас Белков

Автор статьи. Известный специалист в мире IT. Консультант по продуктам и решениям Oracle. Практикующий программист и администратор баз данных. Подробнее.

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

Права в базе данных Oracle

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

На заметку! Управление пользователями можно осуществлять с помощью интерфейса Database Control, перейдя на страницу: Database Control Home Page => Administration => Users (Домашняя страница управления базой данных =>Администрирование => Пользователи) в разделе Users and Privileges (Пользователи и права).

Системные права

Предоставление системных прав

Совет. Для выдачи или отзыва системных прав можно использовать интерфейс OEM Database Control либо SQL-операторы.

Например, чтобы предоставить системные права CREATE SESSION пользователю hr, разрешив ему входить в базу данных Oracle, потребуется выполнить следующий оператор:

Права CREATE SESSION позволяют пользователю входить в базу данных Oracle.

Совет. Все системные права (кроме SELECT ANY DICTIONARY) можно выдать пользователю, указывая ALL PRIVILEGES в операторе GRANT , например:

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

После предоставления прав CREATE SESSION пользователю PUBLIC все пользователи смогут регистрироваться в базе данных без выдачи им прав CREATE SESSION в индивидуальном порядке. Как видите, предоставление прав пользователю PUBLIC сопряжено с риском, поскольку все пользователи будут располагать такими полномочиями.

Выдать системные права пользователю можно при удовлетворении одного из перечисленных ниже условий.

Вот пример использования конструкции WITH ADMIN OPTION при предоставлении системных прав:

Отзыв системных прав

Можно использовать также системные права SELECT ANY DICTIONARY, чтобы предоставить пользователю (обычно разработчику) полномочия на выбор данных из любого объекта схемы SYS.

Системные права SYSDBA и SYSOPER SYSASM

Существуют два мощных набора административных прав — SYSDBA и SYSOPER. В связи с огромными возможностями, предоставляемыми этими полномочиями, на управление ими наложены определенные ограничения. Для назначения этих ролей нельзя использовать опцию WITH ADMIN OPTION. Только пользователь, подключенный в качестве SYSDBA, может выдавать (или отзывать) эти права другим пользователям. Кроме того, эти системные права нельзя предоставлять какой-то роли.

Системные права SYSDBA включают в себя полномочия RESTRICTED SESSION и содержат все системные права, помеченные опцией WITH ADMIN OPTION, в том числе, системные права SYSOPER. Полномочия SYSDBA позволяет решать следующие задачи.

Полномочия SYSOPER также включают в себя права RESTRICTED SESSION и позволяют выполнять следующее.

Совет. Несколько обычных операций с базой данных требуют, чтоб пользователи постоянно запрашивали таблицы словаря данных. Поэтому при разработке баз данных разработчикам целесообразно предоставлять набор основных прав, назначая им роль SELECT_CATALOG_ROLE. Эта роль выдает права выбора данных во всех представлениях словарей данных.

Кроме прав SYSDBA и SYSOPER существуют также права SYSASM, которые можно использовать для администрирования экземпляров ASM (Automatic Storage Management — Автоматическое управление хранилищем). Хотя с экземплярами ASM можно работать, используя права SYSDBA, Oracle рекомендует разделять администрирование базы данных и администрирование ASM.

Объектные права

Объектные права — это полномочия по отношению к различным типам объектов базы данных. Объектные права дают пользователю возможность выполнять действия с конкретной таблицей, представлением, материализованным представлением, последовательностью, процедурой, функций или пакетом. Следовательно, всем пользователям базы данных нужны объектные права, даже если они не нуждаются в системных полномочиях. Существует ряд обычных системных прав, которые применяются ко всем объектам базы данных, и набор прав, применяемых только к определенным объектам. Для выдачи объектных прав можно использовать следующие SQL-операторы:

В следующем перечне приведены различные типы объектных прав базы данных Oracle, основные объектные права каждого типа и примеры каждого объектного типа.

Совет. Полномочия INSERT и UPDATE можно предоставлять на уровне столбца. Ниже приведен пример предоставления прав INSERT для столбца salary таблицы persons: SQL> GRANT INSERT (salary) ON persons to salapati; Чтобы предоставить права на уровне строки, можно использовать виртуальную приватную базу данных Oracle или функцию безопасности меток Oracle.

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

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

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

На заметку! Объектные полномочия не могут быть предоставлены для некоторых объектов схемы, таких как кластеры, индексы, триггеры и связи базы данных. Управление этими типами объектов выполняется посредством системных прав. Например, чтобы изменить кластер, пользователь должен быть владельцем кластера или обладать системными полномочиями ALTER ANY CLUSTER.

Владелец объекта может добавить к оператору GRANT дополнительную конструкцию ALL, чтобы выдать все возможные полномочия для данного объекта. Например, следующие два оператора GRANT эквивалентны:

Владелец схемы может предоставить один или сразу все типы прав в отношении любого отдельного объекта. Вот несколько примеров, которые иллюстрируют предоставление объектных прав:

Пользователь ODS может выдавать любые полномочия (SELECT, INSERT, UPDATE и DELETE) на таблице ods_servers пользователю tester, используя команду GRANT ALL. Но ему не удается предоставить пользователю tester полномочия INSERT ANY TABLE, поскольку для этого требуются системные полномочия (INSERT ANY TABLE), которыми пользователь ODS не располагает. Однако обратите внимание, что пользователь system может успешно выдать эти полномочия, как видно в следующем примере:

Если владелец объекта предоставляет пользователю объектные полномочия посредством конструкции WITH GRANT, получивший полномочия получает право выдавать эти же объектные полномочия другим пользователям. Например:

Объектные полномочия на уровне столбца

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

Отзыв объектных прав

Отзыв объектных прав аналогичен выдаче полномочий. Нужно просто выполнить оператор REVOKE для каждого объектного полномочия, которое необходимо отозвать.

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

Полномочия GRANT ANY OBJECT

Пользователь, обладающий системными полномочиями GRANT ANY OBJECT, может предоставлять и отзывать любые объектные полномочия, как если бы он являлся действительным владельцем объекта. При подключении в качестве SYSDBA (пользователя SYS) эта роль предоставляется автоматически с применением конструкции WITH ADMIN OPTION.

Права вызывающего и права определяющего

Созданная хранимая процедура в Oracle выполняется с применением полномочий ее создателя. Это поведение определено по умолчанию, и принято говорить, что хранимая процедура создана с правами определяющего. Когда пользователь выполняет процедуру, она выполняется с объектными полномочиями создателя (определяющего), а не конкретного пользователя. Но возможно несколько ситуаций, когда нежелательно, чтобы все пользователи могли выполнять процедуру с одинаковыми правами. Возможность доступа к процедуре можно настраивать, создавая ее с правами вызывающего — т.е. процедура будет выполняться с полномочиями пользователя, а не создателя, процедуры.

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

Конструкция AUTHID в операторе CREATE PROCEDURE указывает, что данная процедура создается с правами пользователя или вызывающего, а не с используемыми по умолчанию правами владельца или определяющего. Например:

Конструкция AUTHID в строке 3 определяет, что процедура будет выполняться с полномочиями пользователя current_user — пользователя, вызывающего процедуру. Очевидно, что для успешного выполнения процедуры пользователь должен обладать явными объектными полномочиями DELETE в таблице emp.

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

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

Совет. Роль DBA, которая предварительно определена в базах данных Oracle, является набором системных прав WITH ADMIN OPTION — т.е. пользователь, обладающий этой ролью, может также предоставлять эти полномочия другим пользователям. В большинстве случаев эту роль назначают группе пользователей, которые выполняют администрирование базы данных.

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

Существуют также еще две предопределенных роли — EXP_FULL_DATABASE и IMP_FULL_DATABASE, — которые позволяют пользователю выполнять операции потокового экспорта и импорта (Data Pump Export и Data Pump Import) на уровне базы данных.

Традиционно роль DBA назначается всем сотрудникам организации, которые занимаются задачами администрирования базы данных. Однако в Oracle предупредили, что в последующих версиях роли DBA, CONNECT и RESOURCE могут отсутствовать и потому вместо них рекомендуется создать собственные роли.

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

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

При наличии предоставленной роли DBA либо специальных системных прав CREATE ROLE, роль может быть создана следующим образом:

Только что созданная роль new_dba не имеет никаких присоединенных к ней прав, поэтому теперь ей нужно предоставить требуемые полномочия. Ей даже можно назначить другие предопределенные роли. Роли — это пустые “сосуды”, которые можно наполнять любым количеством системных и объектных полномочий.

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

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

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

Авторизация роли

В примере, приведенном в предыдущем разделе, для использования роли пароль не требовался. Однако можно потребовать авторизацию роли перед тем, как она сможет быть использована. Авторизация роли может быть указана несколькими способами.

Предоставление роли с использованием конструкции WITH ADMIN OPTION

Если роль присваивается с использованием конструкции WITH ADMIN OPTION, получивший ее может выполнять следующие действия.

Предоставление роли другой роли

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

Группа пользователей и роли PUBLIC

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

Отключение и включение роли

Роль пользователя можно отключить, вставляя соответствующую строку в таблицу Product_User_Profile схемы SYSTEM. В листинге 12.10 показана вставка строки в эту таблицу для отключения роли TEST123, присвоенной пользователю TESTER.

Как видите, после отключения роли TEST123 пользователь TESTER лишается права выбора из таблиц базы данных и при попытке выполнения оператора SELECT выдается сообщение об ошибке.

Чтобы снова включить роль TEST123, достаточно удалить соответствующую строку из таблицы Product_User_Profile:

Удаление роли

Удаление роли не представляет особой сложности. Для этого достаточно воспользоваться командой DROP ROLE:

Использование представлений и хранимых процедур для управления правами

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

Использование представлений DBA для управления пользователями, ролями и правами

Диспетчер OEM очень удобен при управлении пользователями в базе данных. Однако время от времени может возникать необходимость использования SQL-сценария для сбора информации о пользователях. Специфичные представления словаря данных могут помочь в получении информации о том, кому присвоены те или иные роли, и какими полномочиями обладает определенная роль. Можно также выяснить, какие системные и объектные полномочия выданы определенному пользователю. Основные представления словаря данных, которые можно применять для управления пользователями, полномочиями и ролями в базе данных, перечислены в таблице ниже.

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

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

Для обеспечения детального управления безопасностью внутри базы данных в Oracle используются два связанных между собой механизма: контекст приложения (application context) и политику детального контроля доступа (fine-grained access control — FGAC). Для обозначения реализации политик детального контроля доступа посредством контекстов приложений в Oracle применяется термин виртуальная приватная база данных (virtual private database). Часто понятия “детальный контроль доступа”, “виртуальная приватная база данных” и “безопасность на уровне строки” используют взаимозаменяемо для ссылки на возможность Oracle обеспечения безопасности на уровне отдельной строки, а не на уровне таблицы.

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

Oracle позволяет управлять доступом к объектам базы данных на уровне строк с помощью средства виртуальной приватной базы данных (virtual private database — VPD). Применение концепции VPD позволяет ограничивать возможность просмотра данных таблицы каждым пользователем только определенной частью. Эта безопасность на уровне строк реализуется путем связывания политики безопасности непосредственно с объектом базы данных, таким как таблица, представление или синоним. Независимо от средства доступа к базе данных, применяемого пользователем (SQL*Plus, специализированная программа запросов или программа составления отчетов), пользователь не в состоянии обойти эту защиту на уровне строк, реализуемую сервером базы данных. Поскольку база данных реализует концепцию VPD, она обеспечивает значительно более надежную защиту, чем безопасность на основе приложения.

Для ограничения доступа пользователей к определенным строкам таблиц и представлений VPD использует своего рода переписывание запросов. Политика безопасности связывается с таблицей или таблицами, доступ к которым нужно контролировать, а соответствующие хранимые процедуры служат для изменения любых SQL-операторов, выполняемых в отношении интересующих таблиц. При выдаче пользователем оператора UPDATE применительно к таблице с такой политикой безопасности, Oracle будет динамически дополнять его предикатом (конструкцией WHERE) для ограничения доступа пользователя к данной таблице.

Например, если пользователь, являющийся сотрудником отдела продаж, выполняет оператор UPDATE EMPLOYEE SET salary=salary*1.10, политики безопасности, связанные с таблицей EMPLOYEE, вызовут дополнение оператора конструкцией функции детального контроля безопасности WHERE dept=’SALES‘, обеспечивая применение изменения только к записям сотрудников отдела продаж. Иначе говоря, если исходный запрос имеет вид:

то измененный оператор выглядит следующим образом:

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

На заметку! Политики VPD могут применяться к операторам SELECT, INSERT, UPDATE, INDEX и DELETE.

Контекст приложения

Контекст приложения позволяет определять набор атрибутов приложения (обычно набор переменных среды сеанса), которые можно применять для управления доступом приложения к базе данных. Используя атрибуты приложения, можно предоставлять соответствующие значения предиката для политик детального контроля доступа. Oracle использует встроенное пространство имен контекста приложений USERENV, содержащее набор предопределенных атрибутов сеанса. Эти предопределенные атрибуты применяются Oracle для контроля доступа. Когда пользователь регистрируется, база данных автоматически извлекает из контекста приложения USERENV основные атрибуты сеанса, такие как имя пользователя, имя компьютера и IP-адрес.

Связанную с сеансом информацию о любом пользователе можно получить через контекст приложения USERENV, как показано в примерах листинга ниже. В первом примере атрибут TERMINAL отображает имя терминала, с которого пользователь обращается к базе данных. Во втором примере атрибут OS_USER отображает имя учетной записи операционной системы, применяемое пользователем базы данных. Третий пример извлекает аутентификационное имя текущего пользователя из атрибута SESSION_USER.

Кроме атрибутов TERMINAL, CURRENT_USER и SESSION_USER, приведенных в примерах листинга выше, пространство имен USERENV содержит еще несколько важных предопределенных атрибутов. Некоторые из часто используемых предопределенных атрибутов перечислены в таблице ниже.

При регистрации пользователя полезно идентифицировать тип пользователя и перехватить определенные основные атрибуты пользователя. Впоследствии эту информацию можно использовать в политиках безопасности, связанных с объектами базы данных. Встроенное пространство имен USERENV идеально подходит для перехвата такой информации.

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

Создание пакета для установки контекста

Чтобы установить контекст приложения для пользователя hr, необходимо создать пакет PL/SQL. В листинге ниже демонстрируется создание простого пакета HR_CONTEXT для установки контекста приложения. Пакет включает в себя единственную процедуру, которая выбирает значение столбца employee_id в переменную empnum. Поскольку этот оператор SELECT создан на основе конструкции WHERE, определяющей атрибут last_name на основе значения атрибута SESSION_USER, значение employee_id будет соответствовать имени пользователя, по которому текущий пользователь был аутентифицирован базой данных.

Создание контекста приложения

Контекст приложения — это именованный набор пар переменная=значение, специфичный для сеанса. После создания пакета (HR_CONTEXT), облегчающего установку контекста приложения, можно двигаться дальше и создать сам контекст приложения, как показано ниже. Обратите внимание, что пользователь hr применяет созданный в предыдущем разделе пакет для создания контекста приложения employee_info.

Контекст приложения для пользователя можно установить двумя способами. Первый — реализация контекста приложения самого по себе, без применения детального контроля доступа. Для этого достаточно создать триггер события для входа пользователя в базу данных, чтобы пользователь вызывал процедуру SELECT_EMP_NO из пакета HR_CONTEXT при входе в базу данных. Триггер входа для установки начального контекста для пользователя создается следующим образом:

Приведенный триггер входа использует процедуру SELECT_EMP_NO из ранее созданного пакета HR_CONTEXT для захвата значения employee_id пользователя и сохранения его в переменной emp_num.

Второй способ установки или ссылки на контекст приложения — выполнение этой задачи в виде интегральной части VPD, используя функцию политики, которая реализует детальный контроль доступа. Этот способ подробно рассматривается в следующем разделе.

Детальный контроль доступа

Традиционно политики безопасности применялись к приложениям в целом. Пользователям присваивались роли или полномочия, в соответствии с которыми они могли получать доступ к таблицам приложения. При этом всегда оставалась возможность обхода протоколов безопасности и изменения данных в таблицах БД пользователями, применяющими средства вроде SQL*Plus. Более того, реализация безопасности на уровне приложения означала, что приходилось управлять политикой предоставления/ отзыва прав доступа каждого пользователя системы ко всем таблицам базы данных.

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

Детальный контроль доступа (fine-grained access control — FGAC) позволяет ограничивать возможности пользователей Oracle так, чтобы они могли использовать только те данные, к которым им нужно обращаться и изменять. FGAC реализуется путем применения функций политик, связываемых с таблицами или представлениями, которые нужно защитить. Детальный контроль доступа использует динамически изменяемые операторы для ограничения пользователей определенными фрагментами таблицы, представления или синонима. При синтаксическом анализе SQL-операторов, выполняемых пользователем, FGAC вынуждает Oracle автоматически анализировать функции политик (таблица может быть связана с более чем одной политикой). При необходимости Oracle выполнит запрос пользователя после его динамического изменения.

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

FGAC подразумевает выполнение следующих действий.

Пакет, реализующий функцию безопасности, будет динамически добавлять предикат ко всем операторам SELECT, выполняемым применительно к таблице ORDERS, возвращая только те заказы, которые соответствуют клиентскому номеру (cust_no) пользователя.

2. Пользователь вводит оператор, подобный следующему:

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

4. Oracle использует имя пользователя, возвращенное SYS_CONTEXT(‘USERENV’, ‘SESSION_USER‘), и выполняет измененный первоначальный запрос, тем самым ограничивая данные, возвращенные из таблицы ORDERS, данными только определенного клиента.

Создание пакета, который будет обращаться к контексту

Рассмотрим простой пакет FGAC. Эта реализация FGAC будет использовать политику, которая позволяет сотруднику просматривать в таблице сотрудников только соответствующие данные.

Вначале создадим пакет hr_security, который впоследствии будет применяться для доступа к контексту приложения. Этот пакет — основной элемент обеспечения безопасности на низком уровне, поскольку он генерирует предикаты динамического доступа к таблице. В листинге 12.13 демонстрируется создание пакета hr_security.

Пакет hr_security, созданный в листинге 12.13, будет использовать контекст employee_info (который был создан ранее в разделе “Создание контекста приложения”) для извлечения переменной emp_num. Как было сказано в предыдущем разделе, контекст приложения employee_info извлекает переменную emp_num из пространства имен USERENV (атрибут SESSION_USER пространства имен USERENV).

Предикат d_predicate в пакете hr_security задает преобразование, которое должно быть применено к любым запросам, выполняемым любым сотрудником, чей employee_id совпадает с переменной emp_num, полученной из контекста employee_info. Например, если пользователь salapati выдает следующую команду:

предикат (d_predicate) преобразует ее следующим образом:

Создание политики безопасности

Созданный в предыдущем разделе пакет hr_security позволяет присоединять динамический предикат (WHERE employee_id = SYS_CONTEXT (‘EMPLOYEE_INFO‘, ‘EMP_NUM‘)) к любым SQL-операторам, которые могут применяться сотрудниками, чей employee_id совпадает с emp_num, полученным в результате использования контекста приложения employee_info. Однако мы еще не связали политику безопасности с таблицей сотрудников. То есть теперь нужно указать, к каким SQL-операторам и к каким именно таблицам должен применяться пакет hr_security.

В предшествующих версиях Oracle все политики безопасности были динамическими — т.е. база данных должна была выполнять функцию политики для каждого оператора DML. Естественно, повторяющееся выполнение функций политики требовало дополнительных системных ресурсов и могло отрицательно сказываться на производительности в загруженной базе данных OLTP. Теперь Oracle предлагает несколько возможностей выбора типа политики, которую можно использовать. С помощью параметра POLICY_TYPE процедуры DBMS_RLS.ADD_POLICY можно задавать следующие пять типов политик безопасности.

Политику безопасности можно добавлять в базу данных с использованием пакета DBMS_RLS (RLS — это аббревиатура row-level security (безопасность на уровне строк)), предоставляемого Oracle. Этот пакет позволяет управлять политиками безопасности — т.е. добавлять и удалять политики, группы политик или контексты приложений. При этом необходимо указать имя таблицы, представления или синонима, к которому требуется применить политику безопасности, а также политику безопасности для реализации FGAC. Необходимо также указать конкретный тип SQL-операторов, к которым будет применяться политика, такой как операторы SELECT, INSERT, UPDATE, DELETE, CREATE INDEX или ALTER INDEX.

Ниже перечислены основные процедуры пакета DBMS_RLS:

Политику безопасности можно создать с помощью процедуры DBMS_RLSADD_POLICY, как показано в следующем примере:

Обратите внимание, что приведенный оператор можно было бы также выполнить следующим образом; результат будет эквивалентным:

Успешность создания новой политики можно проверить, выполнив следующий запрос:

Чтобы сделать функции политики безопасности доступными группе PUBLIC, чтобы ее использовали все пользователи, обращающиеся к базе данных, можно выполнить следующее предоставление прав:

VPD на уровне столбцов

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

Создание политики безопасности на уровне столбцов почти идентично созданию обычных политик безопасности — в процедуру DBMS_RLS.ADD_POLICY достаточно добавить дополнительный оператор SEC_RELEVANT_COLS для указания соответствующих столбов, к которым должна применяться политика безопасности. Для создания политики безопасности на уровне столбцов процедура DBMS_RLS.ADD_POLICY применяется следующим образом.

Политика VPD на уровне столбца вступает в действие при появлении в запросе ссылки на столбец salary. При этом функция безопасности, реализующая политику безопасности на уровне столбца, возвращает предикат WHERE salary =’my_salary’, тем самым преобразуя запрос к следующему виду:

Группы политики

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

Использование диспетчера политик Oracle

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

При использовании OEM для создания политики VPD приходится создавать контекст приложения и указывать имя таблицы (или представления либо синонима), имя политики, имя функции, генерирующей предикат, а также типы операторов, к которым применяется политика (SELECT, INSERT, UPDATE или DELETE). Oracle Policy Manager выполняет функцию DBMS_RLS.ADD_POLICY для создания политики FGAC, поддерживающей VPD.

Контроль доступа на основе меток

Oracle позволяет помечать части данных и предоставлять пользователям полномочия для доступа к данным с определенными метками. Политики безопасности реализуются применительно к одному столбцу, который представляет метку. Средство Oracle Label Security (Безопасность меток Oracle), основанное на предшествующем программном продукте Trusted Oracle, построена на основе тех же компонентов, которые помогают создавать VPD. С ее помощью можно легко создавать метки для ограничения доступа к строкам определенной таблицы и использовать авторизацию и полномочия с применением меток для определения политики безопасности на основе меток. Графический интерфейс Oracle Policy Manager предназначен в основном для создания и администрирования политик Oracle Label Security.

Источник