Безопасность SQL*Plus

Помимо обязательного требования указывать имя пользователя и пароль для работы с интерфейсом 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, и любые из ограниченных команд, которые используются, перестают работать.

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

Требования к безопасности и ау...
Требования к безопасности и ау... 2016 просмотров Дэйзи ак-Макарова Tue, 21 Nov 2017, 13:28:01
Аудит Oracle: безопасность баз...
Аудит Oracle: безопасность баз... 6344 просмотров Александров Попков Tue, 21 Nov 2017, 13:18:05
Рекомендации по безопасности б...
Рекомендации по безопасности б... 6106 просмотров Александров Попков Sun, 11 Aug 2019, 12:31:16
Внедрение SQL - брешь в безопа...
Внедрение SQL - брешь в безопа... 1535 просмотров Александров Попков Tue, 21 Nov 2017, 13:28:01

Войдите чтобы комментировать