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

Стас Белков

Стас Белков

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

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

 

 

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

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

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


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


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

Системные права позволяют пользователю выполнить конкретное действие в базе данных либо действие с любым объектом схемы конкретного типа. Хороший пример первого типа системных полномочий — права, которые позволяют подключаться к базе данных, носящие название прав CONNECT. Другими правами этого типа являются права CREATE TABLESPACE, CREATE USER, DROP USER и ALTER USER. Второй класс системных прав предоставляет пользователям право на выполнение операций, которые влияют на объекты в любой схеме. Примерами этого типа системных прав служат ANALYZE ANY TABLE, GRANT ANY PRIVILEGE, NSERT ANY TABLE, GRANT ANY PRIVILEGE, INSERT ANY TABLE, DELETE ANY TABLE и т.п. Как видите, системные права являются очень мощным средством и выдача их не тому пользователю может оказать разрушительное влияние на базу данных. Ниже перечислены некоторые наиболее часто используемые права базы данных Oracle:

 

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

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


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


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

SQL> GRANT CREATE SESSION TO hr;
Grant succeeded.
SQL>

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


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

SQL> GRANT ALL PRIVILEGES TO salapati;
Grant succeeded.
SQL> 

Сама по себе конструкция ALL PRIVILEGES не является системными полномочиями — она служит удобным способом предоставления всех прав в одном действии. Все системные права можно отозвать аналогично с помощью оператора REVOKE ALL PRIVILEGES.


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

SQL> GRANT CREATE SESSION TO public;
Grant succeeded.
SQL>

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

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

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

SQL> GRANT CREATE SESSION TO salapati WITH ADMIN OPTION;
Grant succeeded.
SQL>

Права GRANT ANY OBJECT — специальные системные права, которые позволяют выдавать (и отзывать) объектные права для объектов в любой схеме. Интересно отметить, что когда получивший эти права предоставляет любые права для любого объекта, создается впечатление, будто бы права были выданы владельцем схемы (это видно из представления DBA_TAB_PRIVS). Однако если провести аудит использования оператора GRANT, станет ясно, какой именно пользователь выполнил этот оператор. Все пользователи, располагающие полномочиями SYSDBA, автоматически получают права GRANT ANY OBJECT.

 

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

Для отзыва системных прав служит оператор REVOKE. Отзыв прав вступает в действие немедленно. Например: 

SQL> REVOKE DELETE ANY TABLE FROM pasowner;
Revoke succeeded.
SQL>

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

Только пользователи, обладающие полномочиями SYSDBA, или те, кому были явно предоставлены объектные права, могут получать доступ к объектам в схеме SYS. Доступ к объектам, принадлежащим схеме SYS, можно разрешить также другим пользователям, назначая им одну из следующих трех ролей. (Роли — это именованные наборы прав)

Можно использовать также системные права 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, основные объектные права каждого типа и примеры каждого объектного типа.

GRANT DELETE ON bonuses TO hr 

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


      GRANT SELECT, UPDATE
      ON emp_view TO PUBLIC; 
      GRANT SELECT
      ON oe.customers_seq TO hr; 
      GRANT EXECUTE ON employee_pkg TO hr; 
      GRANT QUERY REWRITE TO hr 
      GRANT READ ON DIRECTORY bfile_dir TO hr 

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

Например:

SQL> GRANT DELETE ON bonuses TO hr WITH GRANT OPTION;

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

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


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


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

SQL> GRANT SELECT,INSERT,UPDATE,DELETE on EMPLOYEES TO oe;
SQL> GRANT ALL ON EMPLOYEES TO oe;

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

SQL> GRANT SELECT ON ods_process TO tester;
Grant succeeded.
SQL> GRANT INSERT ON ods_process TO tester;
Grant succeeded.
SQL> GRANT ALL ON ods_servers TO tester;
Grant succeeded.
SQL> GRANT INSERT ANY TABLE TO tester;
grant insert any table to tester
*
ERROR at line 1:
ORA-01031: insufficient privileges
недостаточно привилегий
SQL>

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

SQL> CONNECT system/manager@finance1
Connected.
SQL> SHOW USER
USER is "SYSTEM"
SQL> GRANT INSERT ANY TABLE TO tester;
Grant succeeded.
SQL>

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

SQL> GRANT INSERT ANY TABLE TO tester WITH GRANT OPTION

 

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

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

SQL> GRANT UPDATE (product_id) ON sales01 TO salapati;
Grant succeeded.
SQL>

 

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

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

SQL> CONNECT ods/ods@finance1;
Connected.
SQL> REVOKE SELECT, INSERT ON ods_process FROM tester;
Revoke succeeded.
SQL>

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

SQL> REVOKE UPDATE (hostname) ON ods_process FROM tester;
revoke update(hostname) on ods_process from tester
*
ERROR at line 1:
ORA-01750: UPDATE/REFERENCES may only
be revoked from the whole table, not by column
полномочия UPDATE/REFERENCES могут быть
отозваны только для целой таблицы, а не для столбца
SQL> REVOKE UPDATE ON ods_process FROM tester;
Revoke succeeded.
SQL>

 

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

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

 

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

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

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

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

SQL> CREATE OR REPLACE PROCEDURE delete_emp
2 (p_emp_id number)
3 AUTHID current_user IS
4 BEGIN
5 DELETE FROM emp WHERE
6 emp_id = p_emp_id;
7 COMMIT;
8* END;
Procedure created.
SQL>

Конструкция 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, роль может быть создана следующим образом:

SQL> CREATE ROLE new_dba;
Role created.
SQL> 

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

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


 

SQL> GRANT CONNECT TO new_dba;
Grant succeeded.
SQL> GRANT SELECT ANY TABLE TO new_dba;
Grant succeeded.
SQL> GRANT UPDATE ANY TABLE TO new_dba;
Grant succeeded.
SQL> GRANT select_catalog_role TO new_dba;
Grant succeeded.
SQL> GRANT exp_full_database TO new_dba;
Grant succeeded.
SQL> GRANT imp_full_database TO new_dba;
Grant succeeded.
SQL>

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

SQL> GRANT new_dba TO salapati;
Grant succeeded.
SQL> 

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

 

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

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

      CREATE ROLE clerk IDENTIFIED BY password; 
      CREATE ROLE admin_role IDENTIFIED USING hr.admin;
      CREATE ROLE accts_rec IDENTIFIED EXTERNALLY;
      CREATE ROLE supervisor IDENTIFIED GLOBALLY;

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

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

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

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

 

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

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

 

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

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


 

SQL> INSERT INTO PRODUCT_USER_PROFILE(PRODUCT,userid,attribute,char_value)
2* VALUES('SQL*Plus','TESTER','ROLES','TEST123');
1 row created.
SQL> COMMIT;
Commit complete.
SQL> CONNECT tester/tester@finance1
Connected.
SQL> SELECT * FROM hr.regions;;
select * from hr.regions
*ERROR at line 1:
ORA-00942: table or view does not exist
таблица или представление не существует

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

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

SQL> DELETE FROM product_user_profile
2 WHERE userid='TESTER'
3* AND char_value = 'TEST123';
1 row deleted.
SQL> commit;
Commit complete.

 

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

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

SQL> DROP ROLE admin_user;
Role dropped.
SQL>

 

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

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

 

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

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

 Представление словаря данных  Описание
 DBA_USERS  Предоставляет информацию о пользователях.
 DBA_ROLES  Отображает все роли в базе данных.
 DBA_COL_PRIVS  Отображает полномочия, предоставленные на уровне столбцов.
 DBA_ROLE_PRIVS  Отображает пользователей и их роли.
 DBA_SYS_PRIVS  Отображает пользователей, которым предоставлены системные полномочия.
 DBA_TAB_PRIVS  Отображает пользователей и их полномочия в таблицах.
 ROLE_ROLE_PRIVS  Отображает роли, предоставленные ролям.
ROLE_SYS_PRIVS Отображает системные роли, предоставленные ролям.
ROLE_TAB_PRIVS Отображает табличные полномочия, предоставленные ролям.
SESSION_PRIVS Отображает полномочия, которые в данный момент включены для текущего сеанса.
SESSION_ROLES Отображает роли, которые в данный момент включены для текущего сеанса.

 

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

Традиционные средства обеспечения безопасности данных (с помощью прав, ролей, представлений и т.п.) действуют достаточно успешно, но имеют определенные ограничения. Главным недостатком этого подхода является то, что большинство средств поддержки безопасности носят общий характер. Это ведет к излишнему ограничению возможностей пользователей, в то время как основная цель — обеспечение пользователям свободного доступа к необходимой им информации. В дополнение к традиционным концепциям ролей и прав 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', обеспечивая применение изменения только к записям сотрудников отдела продаж. Иначе говоря, если исходный запрос имеет вид: 

UPDATE EMPLOYEE SET salary=salary*1.10

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

UPDATE EMPLOYEE SET salary=salary*1.10 WHERE dept='SALES' 

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


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


 

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

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

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


 

SQL> CONNECT system/system_passwd;
Connected.
SQL>
SQL> SELECT sys_context ('USERENV', 'TERMINAL')
2 FROM DUAL;
SYS_CONTEXT('USERENV','TERMINAL')
----------------------------------
NTL-ALAPATISAM
SQL>
SQL> SELECT sys_context ('USERENV', 'OS_USER') FROM DUAL;
SYS_CONTEXT('_USERENV','CURRENT_USER')
-------
oracle
SQL>
SQL> CONNECT fay/fay1;
Connected.
SQL>
SQL> SELECT first_name,last_name,employee_id FROM employees
2 WHERE UPPER(last_name)=sys_context('USERENV', 'SESSION_USER');
3
FIRST_NAME LAST_NAME EMPLOYEE_ID
-------------- --------- ------------
Pat Fay 202
1 row selected.
SQL>

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

 Атрибут  Описание
 instance  Идентификатор экземпляра
 entryID  Идентификатор записи аудита
 current_user  Имя пользователя, запустившего сеанс
 session_user  Аутентификационное имя текущего пользователя базы данных
 db_name  Имя базы данных
 host  Имя компьютера, на котором действует база данных
 os_user  Имя учетной записи в операционной системе
terminal Клиентский терминал, с которого осуществляется доступ к базе данных
 ip_address  IP-адрес клиентского компьютера
 external_name  Внешнее имя пользователя базы данных

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

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

  1. Создайте пакет PL/SQL, устанавливающий контекст с помощью функций.
  2. Создайте контекст приложения, который использует созданный пакет.

 

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

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


 

SQL> CONNECT hr/hr
Connected.
SQL> CREATE OR REPLACE PACKAGE hr_context AS
2 PROCEDURE select_emp_no ;
3* END;
SQL> /
Package created.
SQL> CREATE OR REPLACE PACKAGE BODY hr_context as
2 PROCEDURE select_emp_no IS
3 empnum number;
4 BEGIN
5 SELECT employee_id INTO empnum FROM employees WHERE
6 UPPER(last_name) =
7 sys_context('USERENV', 'SESSION_USER');
8 dbms_session.set_context('employee_info', 'emp_num', empnum);
9 END select_emp_no;
10* END;
SQL> /
Package body created.
SQL>

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

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

SQL> CONNECT system/system_passwd;
Connected.
SQL> GRANT CREATE ANY CONTEXT TO hr;
Grant succeeded.
SQL> CONNECT hr/hr;
Connected.
SQL> CREATE CONTEXT employee_info USING hr.context;
Context created.
SQL>

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

SQL> CREATE OR REPLACE TRIGGER hr.security_context
2 AFTER LOGON ON DATABASE
3 BEGIN
4 hr_context.select_emp_no;
5* END;
SQL> /
Trigger created.
SQL>

Приведенный триггер входа использует процедуру 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 подразумевает выполнение следующих действий.

1. Вы создаете функцию политики, которая будет автоматически добавлять предикат в оператор DML пользователя. Предикат представляет собой конструкцию WHERE, построенную с использованием некоторой операции (=, !=, IS, IS NOT, >, >=, EXIST, BETWEEN, IN, NOT IN и т.д.). Вот пример такой функции: 

cust_no = (SELECT custno FROM orders
WHERE custname = SYS_CONTEXT ('USERENV','SESSION_USER'))

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

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

SELECT * FROM orders;

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

SELECT * FROM orders WHERE custno = (
SELECT custno FROM customers
WHERE custname = SYS_CONTEXT('USERENV', 'SESSION_USER'))

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

 

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

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

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


 

SQL> CREATE OR REPLACE PACKAGE hr_security AS
2 FUNCTION empnum_sec (A1 VARCHAR2, A2 VARCHAR2)
3 RETURN varchar2;
4 END;
5*/
Package created.
SQL> CREATE OR REPLACE PACKAGE BODY hr_security AS
2 FUNCTION empnum_sec (A1 VARCHAR2, A2 VARCHAR2)
3 RETURN varchar2
4 IS
5 d_predicate varchar2 (2000);
6 BEGIN
7 d_predicate:= 'employee_id =
8 SYS_CONTEXT("EMPLOYEE_INFO","EMP_NUM")';
9 RETURN d_predicate;
10 END empnum_sec;
11 END hr_security;
12* /
Package body created.
SQL>

Пакет 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 выдает следующую команду: 

SQL> SELECT * FROM employees;

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

SQL> SELECT * FROM employees
2* WHERE employee_id = SYS_CONTEXT ('EMPLOYEE_INFO', 'EMP_NUM'); 

 

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

Созданный в предыдущем разделе пакет 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, как показано в следующем примере: 

SQL> CONNECT system/system_passwd
Connected.
SQL> EXECUTE dbms_rls.add_policy('hr','employees','manager_policy','hr',-
'hr_security.empnum_sec','select');
PL/SQL procedure successfully completed.

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

SQL> BEGIN
2 dbms_rls.add_policy
3 (object_schema => 'hr',
4 object_name => 'employees',
5 policy_name => 'manager_policy',
6 function_schema => 'hr',
7 policy_function => 'hr_security.empnum_sec',
8 statement_types => 'select');
9* END;
SQL> /

Процедура DBMS_RLS.ADD_POLICY в приведенных операторах создает политику manager_policy в схеме hr. Эта политика безопасности в действительности реализуется функцией empnum_sec, которая является частью ранее созданного пакета hr_security. Политика безопасности указывает, что она применяется ко всем операциям SELECT, выполняемым в таблице employees.

Проще говоря, новая созданная нами политика безопасности (manager_policy) будет ограничивать все операторы SELECT, выполняемые применительно к таблице hr.employees, информацией, относящейся к employee_id того пользователя, который выдал запрос.

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

SQL> SELECT object_name, policy_name, sel, ins, upd, del, enable
FROM all_policies;
OBJECT_NAME  POLICY_NAME     SEL   INS  UPD   DEL   ENABLED
-----------  --------------  ----  ---  ----  ----  --------
EMPLOYEES    MANAGER_POLICY  YES   NO   NO    NO    YES
SQL>

Вывод запроса показывает, что теперь все операторы SELECT, выполняемые применительно к таблице employees, управляются политикой безопасности manager_policy.

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

SQL> GRANT EXECUTE ON hr_security TO public;
Grant succeeded.

 

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

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

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

SQL> BEGIN
2    dbms_rls.add_policy
3       (object_schema => 'hr',
4        object_name => 'employees',
5        policy_name => 'manager_policy',
6        function_schema => 'hr',
7        policy_function => 'hr_security.empnum_sec',
8        statement_types => 'select,insert',
9       sec_relevant_cols => 'salary'); 
10 END;
SQL> /

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

SQL> SELECT fname, lname, salary FROM employees;

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

SQL> SELECT fname, lname, salary FROM employees 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.

Вас заинтересует / Intresting for you:

Создание базы данных Oracle
Создание базы данных Oracle 34262 просмотров Александров Попков Wed, 14 Nov 2018, 12:44:39
Oracle и непроцедурный доступ ...
Oracle и непроцедурный доступ ... 8510 просмотров Antoni Tue, 21 Nov 2017, 13:32:50
Видеокурс по администрированию...
Видеокурс по администрированию... 10719 просмотров Илья Дергунов Mon, 14 May 2018, 05:08:47
СУБД Oracle: обзор характерист...
СУБД Oracle: обзор характерист... 15793 просмотров Antoni Fri, 24 Nov 2017, 07:35:05
Печать
Войдите чтобы комментировать

Oracle_Admin аватар
Oracle_Admin ответил в теме #10418 2 года 1 мес. назад

Благодарю за статью. Доступна описан механизм прав доступа СУБД Oracle. Понятно, как с ними работать.
Присоединяюсь!
admin аватар
admin ответил в теме #10343 2 года 2 мес. назад
Благодарю за статью. Доступна описан механизм прав доступа СУБД Oracle. Понятно, как с ними работать.