Помимо обязательного требования указывать имя пользователя и пароль для работы с интерфейсом SQL*Plus, в Oracle также предусмотрен дополнительный механизм защиты, действие которого заключается в применении специальной таблицы product_user_profile. Владеет этой таблицей пользователь System, являющийся одним из двух суперпользователей базы данных Oracle. С помощью этой таблицы такой пользователь может ограничивать доступ к командам SQL*Plus, SQL и PL/SQL.
Когда тот или иной пользователь входит в сеанс SQL*Plus, SQL*Plus проверяет таблицу product_user_profile для выяснения того, какие ограничения должны применяться к этому пользователю на протяжении его сеанса. То, как Oracle администрирует этот уровень защиты, выглядит немного запутанно. Пользователь может обладать привилегией на выполнение в базе данных операций вставки или удаления, но из-за того, что привилегии SQL*Plus переопределяют такую привилегию, Oracle может отказать пользователю в праве пользоваться данной привилегией.
После создания базы данных для обеспечения поддержки механизма безопасности SQL*Plus требуется выполнить специальный сценарий pupbld.sql. Этот сценарий находится в каталоге $ORACLE_HOME/sql/admin и должен выполняться от имени пользователя System. Именно он и будет приводить к построению таблицы product_user_profile, которая представляет собой синоним для sqlplus_product_user_profile.
В листинге ниже показан формат этой таблицы.
SQL> DESC product_user_profile Name Null? Type ------------------------------ -------- ---------------------- PRODUCT NOT NULL VARCHAR2(30) USERID VARCHAR2(30) ATTRIBUTE VARCHAR2(240) SCOPE VARCHAR2(240) NUMERIC_VALUE NUMBER(15,2) CHAR_VALUE VARCHAR2(240) DATE_VALUE DATE LONG_VALUE LONG SQL>
На заметку! По умолчанию SQL*Plus не накладывает ограничений по использованию ни на каких пользователей, поэтому при первоначальном создании таблицы product_user_profile в ней не присутствует ни одной строки. При необходимости ограничить возможности каких-то пользователей в SQL*Plus в product_user_profile нужно явно вставить соответствующие строки от имени пользователя System. Вообще с помощью этой таблицы пользователя можно лишать возможности выполнять такие команды, как ALTER, BEGIN, CONNECT, DECLARE,EXEC, EXECUTE, GRANT, HOST, INSERT, SELECT и UPDATE. В случае получения ошибок вида INVALID COMMAND (недопустимая команда) при выполнении пользователем одного из этих операторов, даже если таблица product_user_profile пуста, нужно запустить от имени пользователя System сценарий pupbld.sql.
В листинге ниже показано, как с помощью таблицы product_user_profile лишить пользователя OE возможности удалять, вставлять и обновлять данные в базе.
SQL> INSERT INTO product_user_profile
VALUES
('SQL*PLUS','OE','INSERT',NULL,NULL,NULL,NULL,NULL);
1 row created.
SQL> INSERT INTO product_user_profile
VALUES
('SQL*PLUS','OE','DELETE',NULL,NULL,NULL,NULL,NULL);
1 row created.
SQL> INSERT INTO product_user_profile
VALUES
('SQL*PLUS','OE','UPDATE',NULL,NULL,NULL,NULL,NULL);
1 row created.
SQL> COMMIT;
Commit complete.
SQL>Просмотреть записи, касающиеся пользователя OE, можно с помощью следующего запроса к таблице product_user_profile:
SQL> SELECT product, attribute FROM product_user_profile WHERE userid='OE'; PRODUCT ATTRIBUTE ------------------------------------- SQL*PLUS INSERT SQL*PLUS DELETE SQL*PLUS UPDATE SQL>
Если пользователь OE попытается удалить данные из таблицы, это приведет к появлению следующей ошибки, даже несмотря на то, что таблица ORDERS принадлежит схеме пользователя OE:
SQL> CONNECT oe/oe Connected. SQL> DELETE FROM oe.orders; SP2-0544: invalid command: delete SQL>
Предоставить пользователю OE право удалять данные через SQL*Plus можно, удалив соответствующую строку из таблицы product_user_profile:
SQL> DELETE FROM product_user_profile WHERE userid='OE' and attribute = 'DELETE'; 1 row deleted. SQL> COMMIT; Commit complete. SQL>
Команды ALTER, BEGIN, DECLARE, EXECUTE и GRANT относятся к языкам DDL (Data Definition Language — язык определения данных) и PL/SQL, а команды INSERT, SELECT и UPDATE — к языку DML (Data Manipulation Language — язык манипулирования данными). Команда HOST применяется в SQL*Plus для получения доступа к операционной системе и запуска команд операционной системы. Наличие у пользователей возможности выполнять команды операционной системы с помощью HOST является совершенно не нужным, поэтому чтобы лишить этой опасной привилегии, например, пользователя salapati, в таблице product_user_profile потребуется сделать вот что:
SQL> INSERT INTO product_user_profile
(product,userid,attribute)
VALUES
('SQL*Plus','salapati','HOST');
1 row created.
SQL>
При желании вернуть пользователю salapati право выдавать команду HOST, удалите только что добавленную строку. В частности, чтобы вернуть пользователю salapati привилегию HOST, потребуется выполнить следующую команду:
SQL> DELETE FROM product_user_profile WHERE userid='SALAPATI';
На заметку! Не забывайте, что у пользователей будут сохраняться любые предоставляемые им привилегии, даже если они не смогут ими пользоваться в сеансе SQL*Plus. Это означает, что можно легко предоставлять владельцам приложений привилегии на доступ к объектам данных во время использования пакетов и процедур, которые хранятся и выполняются в базе данных,и при этом одновременно лишать их этих же привилегий во время работы в сеансе SQL*Plus.
Управление безопасностью с помощью команды set role
Как вам уже, возможно, известно, существует несколько причин, по которым предоставлять привилегии и лишать их лучше не напрямую, а за счет применения ролей.В подходе с ролями, однако, кроется потенциальная угроза безопасности, поскольку любой пользователь может изменять свою роль, выдав в SQL*Plus команду set role.С помощью таблицы product_user_profile эту опасную лазейку в системе безопасности легко устранить, лишив любого пользователя возможности применять команду set role.
Использование команды RESTRICT для отключения команд
Помимо таблицы product_user_profile, для лишения пользователей возможности выдавать определенные команды операционной системы можно также применять команду RESTRICT. В целом эффект получается такой же, как и при использовании таблицы product_user_profile, за исключением того, что RESTRICT отключает команды даже там, где нет никаких подключений к серверу.
Команду RESTRICT можно применять на трех уровнях — 1, 2 или 3. Ниже приведен пример применения команды RESTRICT на уровне 1:
$ sqlplus -RESTRICT 1
В таблице ниже показаны команды, к отключению которых приводит применение команды RESTRICT, и отличия между тремя уровнями ограничения, которые она поддерживает.
| Команда | Уровень 1 | Уровень 2 | Уровень 3 |
| EDIT | Отключена | Отключена | Отключена |
| GET | Отключена | ||
| HOST | Отключена | Отключена | Отключена |
| SAVE | Отключена | Отключена | |
| SPOOL | Отключена | Отключена | |
| START | Отключена | ||
| STORE | Отключена | Отключена |
В случае выполнения команды RESTRICT -3 Oracle не считывает сценарий login.sql.Вместо этого читается сценарий glogin.sql, и любые из ограниченных команд, которые используются, перестают работать.
