В контексте этой статьи владелец схемы представляет пользователя Oracle, которому принадлежат все ваши объекты базы данных, в то время как пользователи приложения - пользователи Oracle, которые должны получить доступ к этим объектам схемы.
Разрешение для приложений создавать прямые подключения к владельцу схемы данных является плохой идеей, потому что оно дает этим приложениям слишком много полномочий, которые могут легко привести к повреждению ваших данных и объектов базы данных. Вместо этого лучше определить пользователей приложения и предоставить этим пользователям необходимые полномочия на объекты владельца схемы.
Эта статья представляет две методики для того, чтобы достигнуть этого разделения и рассматривает их за и против. Для простоты я определил только две роли, но вы можете определить так много ролей, как вы желаете, делая безопасность настолько необходимую, насколько вы нуждаетесь для каждого типа пользователя приложения.
Подход CURRENT_SCHEMA
Этот метод использует атрибут сеанса CURRENT_SCHEMA, чтобы автоматически указать на пользователей приложения.
Во-первых, мы создаем владельца схемы и пользователя приложения.
CONN sys/password AS SYSDBA
-- Remove existing users and roles with the same names.
DROP USER schema_owner CASCADE;
DROP USER app_user CASCADE;
DROP ROLE schema_rw_role;
DROP ROLE schema_ro_role;
-- Schema owner.
CREATE USER schema_owner IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON users;
GRANT CONNECT, CREATE TABLE TO schema_owner;
-- Application user.
CREATE USER app_user IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp;
GRANT CONNECT TO app_user;
Заметьте, что пользователь приложения может соединиться, но он не имеет никаких квот табличной области или полномочий создать объекты.
Затем, мы создаем некоторые роли, чтобы разрешить доступ для чтения-записи и доступ только для чтения.
CREATE ROLE schema_rw_role;
CREATE ROLE schema_ro_role;
Мы хотим дать наш пользовательский доступ для чтения-записи приложения к объектам схемы, таким образом, мы предоставляем соответствующую роль.
GRANT schema_rw_role TO app_user;
Мы должны удостовериться, что у пользователя приложения есть его схема по умолчанию, указывающая на владельца схемы, таким образом, мы создаем AFTER LOGON триггер, чтобы он сделал это для нас.
CREATE OR REPLACE TRIGGER app_user.after_logon_trg
AFTER LOGON ON app_user.SCHEMA
BEGIN
DBMS_APPLICATION_INFO.set_module(USER, 'Initialized');
EXECUTE IMMEDIATE 'ALTER SESSION SET current_schema=SCHEMA_OWNER';
END;
/
Теперь мы готовы создать объект у владельца схемы.
CONN schema_owner/password
CREATE TABLE test_tab (
id NUMBER,
description VARCHAR2(50),
CONSTRAINT test_tab_pk PRIMARY KEY (id)
);
GRANT SELECT ON test_tab TO schema_ro_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON test_tab TO schema_rw_role;
Заметьте, как полномочия предоставляют соответствующим ролям. Без этого объекты не были бы видимы пользователю приложения. У нас теперь есть функционирующий владелец схемы и пользователь приложения.
SQL> CONN app_user/password
Connected.
SQL> DESC test_tab
Name Null? Type
----------------------------------------------------- -------- ------------------------------------
ID NOT NULL NUMBER
DESCRIPTION VARCHAR2(50)
SQL>
Этот метод идеален, если пользователь приложения - просто альтернативная точка входа к основной схеме, не требующая никаких собственных объектов. Это просто и не требует управления тысячами синонимов. Я не считаю это очень полезным для разработчиков, которые должны сделать копии или изменить объекты схемы во время разработки.
Метод синонимов
Этот метод полагается на синонимы, принадлежавшие пользователю приложения, чтобы указать на корректное расположение объектов схемы.
Во-первых, мы создаем пользователей похожим способом в предыдущем примере.
CONN sys/password AS SYSDBA
-- Remove existing users and roles with the same names.
DROP USER schema_owner CASCADE;
DROP USER app_user CASCADE;
DROP ROLE schema_rw_role;
DROP ROLE schema_ro_role;
-- Schema owner.
CREATE USER schema_owner IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON users;
GRANT CONNECT, CREATE TABLE TO schema_owner;
-- Application user.
CREATE USER app_user IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp;
GRANT CONNECT, CREATE SYNONYM TO app_user;
Пользователь приложения может соединиться, но не имеет никаких квот табличной области. Различие здесь в том, что у пользователя приложения действительно есть полномочие создать синонимы.
Затем, мы создаем некоторые роли, чтобы разрешить доступ для чтения-записи и доступ только для чтения и предоставить роль чтения-записи пользователю приложения.
CREATE ROLE schema_rw_role;
CREATE ROLE schema_ro_role;
GRANT schema_rw_role TO app_user;
Теперь мы готовы создать объект для владельца схемы таким же образом, мы сделали в предыдущем примере.
CONN schema_owner/password
CREATE TABLE test_tab (
id NUMBER,
description VARCHAR2(50),
CONSTRAINT test_tab_pk PRIMARY KEY (id)
);
GRANT SELECT ON test_tab TO schema_ro_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON test_tab TO schema_rw_role;
Если мы теперь соединяемся пользователем приложения, то мы не в состоянии видеть объект, не квалифицируя его с именем схемы. Мы можем или продолжить пользоваться этим способом, или использовать синоним, чтобы указать на корректный объект.
SQL> CONN app_user/password
Connected.
SQL> DESC test_tab
ERROR:
ORA-04043: object test_tab does not exist
SQL> DESC schema_owner.test_tab
Name Null? Type
----------------------------------------------------- -------- ------------------------------------
ID NOT NULL NUMBER
DESCRIPTION VARCHAR2(50)
SQL> CREATE SYNONYM test_tab FOR schema_owner.test_tab;
Synonym created.
SQL> DESC test_tab
Name Null? Type
----------------------------------------------------- -------- ------------------------------------
ID NOT NULL NUMBER
DESCRIPTION VARCHAR2(50)
SQL>
Я считаю этот метод довольно громоздким из-за большого числа требуемых синонимов, особенно когда существует большое количество пользователей приложения. Очевидно, что возможно использовать общедоступные синонимы, но это может быть проблематично, когда у вас есть множество схем приложения на единственном экземпляре. Я использую этот метод только тогда, когда у меня есть разработчики, которые должны создавать их собственные объекты схемы для тестирования.
| < Предыдущая | Следующая > |
|---|
