Bài giảng Bảo mật cơ sở dữ liệu - Chương VIII: Virtual Private Database

70 trang phuongnguyen 2940

Download

Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Bảo mật cơ sở dữ liệu - Chương VIII: Virtual Private Database", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

bai_giang_bao_mat_co_so_du_lieu_chuong_viii_virtual_private.pdf

Nội dung text: Bài giảng Bảo mật cơ sở dữ liệu - Chương VIII: Virtual Private Database

Chương VIII Pag. 1
Nội Dung 1) Giới thiệu về Virtual Private Database 2) Row-level security 3) Kỹ thuật làm việc với policy function 4) Quyền EXEMPT ACCESS POLICY 5) Giám sát quyền EXEMPT ACCESS POLICY 6) Xử lý các Exception về Policy Function 7) Column Sensitive VPD 8) Example Pag. 2
Virtual Private Databases • Cơ sở dữ liệu riêng ảo (Virtual Private Databases-VPD) cho phép nhiều người dùng truy cập vào một lược đồ duy nhất và ngăn chặn họ truy cập vào dữ liệu mà không liên quan đến họ. • VPD điều khiển việc truy xuất dữ liệu tại mức dòng (row) và cột (column) • SQL Server: use VIEW data object • Oracle10g: – Specific functions – Row-level security, fine3-grained access Database(FGA) Security and Auditing
Giới thiệu về Virtual Private Database DatabasePag. 4 Security and Auditing
Giới thiệu về Virtual Private Database Ví dụ DatabasePag. 5 Security and Auditing
Giới thiệu về Virtual Private Database Ví dụ DatabasePag. 6 Security and Auditing
Giới thiệu về Virtual Private Database Ví dụ DatabasePag. 7 Security and Auditing
Overview of Virtual Private Databases (continued) Thực thi VPD là sự kết hợp của 2 kỹ thuật: • Fine-grained access control (FGAC) • Application Context 8 Database Security and Auditing
Overview of Virtual Private Databases (continued) • Fine-grained access control (FGAC): cho phép người quản trị dùng các function để hiện thực các chính sách bảo mật và liên kết các chính sách bảo mật đó với các table, view hoặc synonym. • Việc gán các chính sách như vậy khiến cho những người dùng với quyền hạn khác nhau sẽ thấy được những “khung nhìn” khác nhau đối với đối tượng được bảo vệ. • Đồng thời chính sách bảo mật đó sẽ được áp dụng cho bất kỳ user nào truy xuất đến table đó mà không cần người quản trị phải gán chính sách cho từng user. 9 Database Security and Auditing
Overview of Virtual Private Databases (continued) • Application Context: cung cấp một nơi lưu trữ bảo mật cho những giá trị ngữ cảnh ứng dụng. Sử dụng Application Context sẽ nâng cao hiệu quả thực hiện của FGAC • Lưu ý: bởi vì đây là 1 phương pháp hiệu quả và phổ biến để hiện thực việc bảo mật ở mức dòng dữ liệu trong Oracle, nên người ta thường dùng thuật ngữ Row-level security (RLS) để thay cho Fine-grained access control hoặc Virtual Private Database. 10 Database Security and Auditing
Row-level Security • Row-level security (RLS) cho phép giới hạn việc truy xuất các hàng (record) dựa trên một chính sách bảo mật (security policy) được hiện thực bằng PL/SQL. Một chính sách bảo mật mô tả các quy định quản lý việc truy xuất các dòng dữ liệu. 11 Database Security and Auditing
Row-level Security Cơ chế thực hiện • Để thực hiện RLS, đầu tiên ta tạo 1 hàm PL/SQL (PL/SQL function) trả về một chuỗi (string). Chuỗi string này chứa các điều kiện của chính sách bảo mật mà ta muốn hiện thực. • Hàm PL/SQL vừa được tạo ở trên sau đó được đăng ký cho các table, view mà ta muốn bảo vệ bằng cách dùng package PL/SQL DBMS_RLS. • Khi có một câu truy vấn của bất kỳ user nào trên đối tượng được bảo vệ, Oracle sẽ nối chuỗi được trả về từ hàm nêu trên vào mệnh đề WHERE của câu lệnh SQL ban đầu (nếu trong câu lệnh SQL ban đầu không có mệnh đề WHERE thì Oracle sẽ tự động tạo thêm mệnh đề WHERE để đưa chuỗi điều kiện vào), nhờ đó sẽ lọc được các hàng dữ liệu theo các điều kiện của chính sách bảo mật. 12 Database Security and Auditing
Row-level Security Các lưu ý khi làm việc với RLS • Các hàm PL/SQL được đăng ký cho các table, view hay synonym bằng cách gọi thủ tục DBMS_RLS.ADD_POLICY. • Thủ tục ADD_POLICY đòi hỏi ít nhất phải có 3 tham số nhập vào: object_name, policy_name, policy_function. (Mô tả chi tiết của package DBMS_RLS được chứa trong file thư_mục_cài_đặt_Oracle\Oracle\RDBMS\ADMIN\dbmsrlsa.s ql). • Sự kết hợp của object_schema, object_name, và policy_name phải là duy nhất. 13 Database Security and Auditing
Row-level Security Các lưu ý khi làm việc với RLS • Mặc định, policy sẽ được áp dụng cho tất cả các lệnh DML. Người quản trị có thể dùng tham số STATEMENT_TYPES để chỉ ra policy áp dụng cho loại câu lệnh nào. • Bất cứ khi nào 1 user truy xuất một cách trực tiếp hay gián tiếp vào đối tượng được bảo vệ, RLS engine sẽ được gọi một cách tự động, hàm PL/SQL đã đăng ký sẽ được thực thi, và rồi lệnh SQL của user sẽ được chỉnh sửa và thực thi. • Tuy nhiên, account SYS không bị ảnh hưởng bởi bất kỳ chính sách bảo mật nào. • Nhiều policy cũng có thể áp dụng cho cùng 1 đối tượng. Khi đó CSDL sẽ kết hợp tất cả các policy đó lại với nhau theo phép AND. 14 Database Security and Auditing
Row-level Security Các lưu ý khi làm việc với RLS • Quyền sử dụng package DBMS_RLS không được gán cho mọi người dùng. Những người quản trị cần được gán quyền EXECUTE ON DBMS_RLS để có thể sử dụng được nó. • Tất cả các policy function mà ta tạo ra đều phải có đúng 2 tham số truyền vào. • Tham số đầu tiên là tên của schema sở hữu đối tượng mà chính sách RLS đó bảo vệ. • Tham số thứ hai là tên của đối tượng được bảo vệ. Hai tham số này rất hữu ích vì 1 policy function có thể được áp dụng cho nhiều đối tượng khác nhau trong nhiều schema khác nhau. • Các tham số sẽ được dùng để xác định đối tượng nào mà chính sách đó được gọi cho nó. Kiểu của 2 tham số truyền vào và của giá trị trả về phải là kiểu VARCHAR2.15 Database Security and Auditing
Row-level Security Các lưu ý khi làm việc với RLS • Policy function cần được tạo ra trong schema của người quản trị bảo mật. Điều này quan trọng vì việc truy xuất vào các policy function cần được bảo vệ. Các user khác không nên có quyền thực thi hay quyền alter hoặc quyền drop trên các policy function này. • Để hiện thực được các chính sách bảo mật phức tạp một cách hiệu quả, thông thường người ta sử dụng kết hợp RLS với Application Context. Nhờ đó các chính sách bảo mật sẽ được áp dụng theo các điều kiện linh hoạt hơn (ví dụ: áp dụng chính sách bảo mật nào là dựa trên người dùng thuộc Department số mấy). 16 Database Security and Auditing
Setting op a Virtual Private Databases Setting up a VPD involves the following steps. • Setup Test Environment • Create an Application Context • Create Login Trigger • Create Security Policies • Apply Security Policies to Tables • Test VPD • What Next 17 Database Security and Auditing
Tạo User trong SQL Server 18 Database Security and Auditing
Tạo user cho DB hiện hành • Để thêm 1 tài khoản (ID) cho 1 user mới vào DB hiện hành • Cú pháp: • sp_adduser [ @loginame = ] 'login' [ , [ @name_in_db = ] 'user' ] [ , [ @grpname = ] 'group' ] • Chú ý: chỉ có thể tạo user mới cho những user nào đã có tài khoản đăng nhập (login ID) • ‘login‘: xác định login id của user • 'user‘ là tên của user mới. Nếu tuỳ chọn này không được xác định, tên của user sẽ chính là tên login id của user đó. Có thể tạo ra tài khoản user khác với tên login id của user đó. • 'group‘ là nhóm hay role mà user mới này sẽ tự động trở thành thành viên của nhóm. • Có thể tạo user mới từ Enterprise Manager
Tạo User trong Oracle 20 Database Security and Auditing
Cấp quyền cho User trong Oracle 21 Database Security and Auditing
Setup Test Environment First we must create a user to act as the schema owner for this example. Obviously, you will perform the following tasks using your current schema owner.Setup Test Environment CONNECT sys/password@service AS SYSDBA; CREATE USER schemaowner IDENTIFIED BY schemaowner DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp; GRANT connect, resource TO schemaowner; 22 Database Security and Auditing
Setup Test Environment CREATE USER user1 IDENTIFIED BY user1 DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp; GRANT connect, resource TO user1; CREATE USER user2 IDENTIFIED BY user2 DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp; GRANT connect, resource TO user2; GRANT EXECUTE ON DBMS_RLS TO PUBLIC; CONN schemaowner/schemaowner@service23 Database Security and Auditing
Setup Test Environment CREATE TABLE users (id NUMBER(10) NOT NULL, ouser VARCHAR2(30) NOT NULL, first_name VARCHAR2(50) NOT NULL, last_name VARCHAR2(50) NOT NULL); CREATE TABLE user_data (column1 VARCHAR2(50) NOT NULL, user_id NUMBER(10) NOT NULL); INSERT INTO users VALUES (1,'USER1','User','One'); INSERT INTO users VALUES (2,'USER2','User','Two'); COMMIT; GRANT SELECT, INSERT ON user_data TO user1, user2; 24 Database Security and Auditing
Create an Application Context • Grant CREATE ANY CONTEXT to the schema owner then create the context and context package. CONNECT sys/password@service AS SYSDBA; GRANT create any context, create public synonym TO schemaowner; CONNECT schemaowner/schemaowner@service; CREATE CONTEXT SCHEMAOWNER USING SCHEMAOWNER.context_package; CREATE OR REPLACE PACKAGE context_package AS PROCEDURE set_context;25 Database Security and Auditing END;
Create an Application Context Next we create the context_package body which will actually set the user context. CREATE OR REPLACE PACKAGE BODY context_package IS PROCEDURE set_context IS v_ouser VARCHAR2(30); v_id NUMBER; BEGIN DBMS_SESSION.set_context('SCHEMAOWNER','SETUP','TRUE'); v_ouser := SYS_CONTEXT('USERENV','SESSION_USER'); BEGIN SELECT id INTO v_id FROM users WHERE ouser = v_ouser; DBMS_SESSION.set_context('SCHEMAOWNER','USER_ID', v_id); EXCEPTION WHEN NO_DATA_FOUND THEN DBMS_SESSION.set_context('SCHEMAOWNER','USER_ID', 0); END; DBMS_SESSION.set_context('SCHEMAOWNER','SETUP','FALSE'); 26 Database Security and Auditing END set_context; END context_package; / SHOW ERRORS
Create an Application Context Next we make sure that all users have access to the Context_Package. GRANT EXECUTE ON SCHEMAOWNER.context_package TO PUBLIC; CREATE PUBLIC SYNONYM context_package FOR SCHEMAOWNER.context_package; 27 Database Security and Auditing
Create Login Trigger Next we must create a trigger to fire after the user logs onto the database. CONNECT sys/password@service AS SYSDBA; CREATE OR REPLACE TRIGGER SCHEMAOWNER.set_security_context AFTER LOGON ON DATABASE BEGIN SCHEMAOWNER.context_package.set_context; END; SHOW ERRORS 28 Database Security and Auditing
Create Security Policies • In order for the context package to have any effect on the users interaction with the database, we need to define a security_package for use with the security policy. • This package will tell the database how to treat any interactions with the specified table. 29 Database Security and Auditing
Create Security Policies CONNECT schemaowner/schemaowner@service; CREATE OR REPLACE PACKAGE security_package AS FUNCTION user_data_insert_security(owner VARCHAR2, objname VARCHAR2) RETURN VARCHAR2; FUNCTION user_data_select_security(owner VARCHAR2, objname VARCHAR2) RETURN VARCHAR2; END security_package; 30 Database Security and Auditing
Create Security Policies • Next we create the security_package body. CREATE OR REPLACE PACKAGE BODY Security_Package IS FUNCTION user_data_select_security(owner VARCHAR2, objname VARCHAR2) RETURN VARCHAR2 IS predicate VARCHAR2(2000); BEGIN predicate := '1=2'; IF (SYS_CONTEXT('USERENV','SESSION_USER') = 'SCHEMAOWNER') THEN predicate := NULL; ELSE predicate := 'USER_ID = SYS_CONTEXT(''SCHEMAOWNER'',''USER_ID'')'; END IF; RETURN predicate; END user_data_select_security;31 Database Security and Auditing
Create Security Policies FUNCTION user_data_insert_security(owner VARCHAR2, objname VARCHAR2) RETURN VARCHAR2 IS predicate VARCHAR2(2000); BEGIN predicate := '1=2'; IF (SYS_CONTEXT('USERENV','SESSION_USER') = 'SCHEMAOWNER') THEN predicate := NULL; ELSE predicate := 'USER_ID = SYS_CONTEXT(''SCHEMAOWNER'',''USER_ID'')'; END IF; RETURN Predicate; END user_data_insert_security; END security_package; SHOW ERRORS 32 Database Security and Auditing
Create Security Policies Next we make sure that all users have access to the Security_Package. • GRANT EXECUTE ON SCHEMAOWNER.security_package TO PUBLIC; • CREATE PUBLIC SYNONYM security_package FOR SCHEMAOWNER.security_package; 33 Database Security and Auditing
Apply Security Policies to Tables The DBMS_RlS package is used to apply the security policay, implemented by security_package, to the the relevant tables. • BEGIN DBMS_RLS.add_policy('SCHEMAOWNER', 'USER_DATA', 'USER_DATA_INSERT_POLICY', 'SCHEMAOWNER', 'SECURITY_PACKAGE.USER_DATA_INSERT_SECURITY', 'INSERT', TRUE); DBMS_RLS.add_policy('SCHEMAOWNER', 'USER_DATA', 'USER_DATA_SELECT_POLICY', 'SCHEMAOWNER', 'SECURITY_PACKAGE.USER_DATA_SELECT_SECURITY' , 'SELECT'); 34 Database Security and Auditing END; /
Test VPD Finally, test that the VPD is working correctly. CONNECT user1/user1@service; INSERT INTO schemaowner.user_data (column1, user_id) VALUES ('User 1', 1); INSERT INTO schemaowner.user_data (column1, user_id) VALUES ('User 2', 2); COMMIT; CONNECT user2/user2@service INSERT INTO schemaowner.user_data (column1, user_id) VALUES ('User 1', 1); INSERT INTO schemaowner.user_data (column1, user_id) VALUES ('User 2', 2); COMMIT; 35 Database Security and Auditing
Test VPD CONNECT schemaowner/schemaowner@service SELECT * FROM schemaowner.user_data; CONNECT user1/user1@Service; SELECT * FROM schemaowner.user_data; CONNECT user2/user2@Service SELECT * FROM schemaowner.user_data; 36 Database Security and Auditing
Test VPD Notice that: • When connected to USER1, only the first insert will work. • When connected to USER2, only the second insert will work. • The failing inserts produce the following error. ORA-28115: policy with check option violation • Once the inserts are finished, there will be two rows in the table, as seen when connected as SCHEMAOWNER. When connected as USER1 or USER2, only the single row they inserted will be visible. 37 Database Security and Auditing
Implementing a VPD Using Views • Quyền EXEMPT ACCESS POLICY • Giám sát quyền EXEMPT ACCESS POLICY • Xử lý các Exception về Policy Function • Column Sensitive VPD 38 Database Security and Auditing
Quyền EXEMPT ACCESS POLICY • Tuy RLS cung cấp một kỹ thuật bảo mật rất tốt, nhưng nó cũng dẫn đến một sự khó chịu khi thực hiện các tác vụ quản trị CSDL (ví dụ: tác vụ backup dữ liệu). • Nếu người chủ của một bảng nào đó hoặc một DBA thực hiện backup dữ liệu của bảng đó trong khi các chính sách bảo mật trên nó vẫn có tác dụng, rất có thể file backup sẽ không có dữ liệu nào hết. • Vì lý do này (và một số lý do khác nữa), Oracle cung cấp quyền EXEMPT ACCESS POLICY. Người được cấp quyền này sẽ được miễn khỏi tất cả các function RLS. Người quản trị CSDL có nhiệm vụ thực hiện backup cần có quyền này để đảm bảo rằng tất cả các dữ liệu sẽ được backup lại. • 39 Database Security and Auditing
Giám sát quyền EXEMPT ACCESS POLICY • Do đây là quyền rất mạnh, không chỉ định trên cụ thể một schema hay object nào nên ta cần cẩn trọng trong việc quản lý xem ai được phép nắm giữ quyền này. Mặc định, những user có các quyền SYSDBA sẽ có quyền này (account SYS) • Ta không thể ngăn cản các user được cấp quyền khỏi việc lạm dụng quyền được cấp. Ta chỉ có thể theo dõi xem họ làm gì với quyền được cấp đó. • Auditing là một cách hiệu quả để đảm bảo quyền miễn trừ khỏi các chính sách RLS không bị lạm dụng 40 Database Security and Auditing
Giám sát quyền EXEMPT ACCESS POLICY • Kiểm tra xem ai được cấp quyền EXEMPT ACCESS POLICY bằng câu lệnh sau: sec_mgr@KNOX10g> SELECT grantee FROM dba_sys_privs WHERE PRIVILEGE = 'EXEMPT ACCESS POLICY'; GRANTEE SYSTEM 41 Database Security and Auditing
Xử lý các Exception về Policy Function Nói chung có 2 loại error có thể khiến cho một chính sách RLS bị thất bại: • Policy function không hợp lệ cho nên nó không được recompile và thực thi. Ví dụ, lỗi này sẽ xảy ra khi policy truy vấn đến một table không tồn tại. Lỗi về chính sách cũng có thể xảy ra nếu policy function không tồn tại (việc này thường do policy function đã bị drop hoặc nó đã được đăng ký không đúng trong thủ tục ADD_POLICY). • Chuỗi trả về của policy function khi được thêm vào câu lệnh SQL truy vấn trên đối tượng được bảo vệ gây ra lỗi câu lệnh SQL không hợp lệ. Có rất nhiều lý do khiến cho việc này xảy ra. 42 Database Security and Auditing
Column Sensitive VPD • Oracle Database 10g cung cấp thêm 1 tính năng mới cho VPD gọi là Column Sensitive VPD. Mục đích của tính năng này là thực hiện các chính sách bảo mật khi cột cần bảo vệ được tham khảo. . 43 Database Security and Auditing
Implementing Oracle Virtual Private Databases (continued) 44 Database Security and Auditing
Implementing Oracle Virtual Private Databases (continued) • Create table for customer users: – Create the CUSTOMERS table – Insert rows into the CUSTOMERS table – Create three users for testing, VPD_CLERK1, VPD_CLERK2, and VPD_CLERK3 – Grant the necessary privileges on the CUSTOMERS table to use each test • ROW_OWNER security: row-level security based on user that owns row 45 Database Security and Auditing
Implementing Oracle Virtual Private Databases (continued) • Steps: – Create a policy function to add a predicate to the WHERE clause – Using DBMS_RLS add the VPD policy: Oracle-supplied package – Log in as VPD_CLERK1; display number of records that this user can see – Disable this policy 46 Database Security and Auditing
Implementing Oracle Virtual Private Databases (continued) 47 Database Security and Auditing
Implementing Oracle Virtual Private Databases (continued) • APPLICATION-CONTEXT security: allows specific users to see only rows for a specific sales representative • Steps: – Create the DBSEC_CUSTOMERS_APP_CONTEXT table – Insert rows into this table – Create a trusted package that allows DBSEC to execute DBMS_SESSION48 Database Security and Auditing
Implementing Oracle Virtual Private Databases (continued) • Steps (continued): – Create an application context for this policy – Create a new VPD function policy to add a WHERE clause predicate – Add a VPD policy for the CUSTOMERS table – Create an after-logon trigger – Now log on as VPD_CLERK2 49 Database Security and Auditing
Implementing Oracle Virtual Private Databases (continued) • ROLE SECURITY LEVEL: – Detects the role of the user – A predicate is used to filter the rows that can be seen by each user • Steps: – Disable any policies on the CUSTOMERS table – Disable the AFTER LOGON database trigger – Create three new roles 50 Database Security and Auditing
Implementing Oracle Virtual Private Databases (continued) 51 Database Security and Auditing
Implementing Oracle Virtual Private Databases (continued) • Steps (continued): – Create application context for the security level – Create application context package to set the application context – Create a policy function to implement row- level security (VPD) – Create a policy to enforce a WHERE clause predicate 52 Database Security and Auditing
Implementing Oracle Virtual Private Databases (continued) • Steps (continued): – Application logs on as VPD_CLERK3; run PKG_DBSEC_ROLE_SECURITY_LEVEL package – Repeat last step, this time use VPD_CLERK1 • VPD policies can be grouped for organizational purposes • Oracle enforces row-level security using all the DML statements 53 Database Security and Auditing
Viewing VPD Policies and Applications Context Using the Data Dictionary 54 Database Security and Auditing
Viewing VPD Policies and Applications Context Using Policy Manager • Graphical tool called Policy Manage • Use SYSTEM credentials to log in • FGA control policies are divided into two parts: – Policy groups – Application context 55 Database Security and Auditing
Viewing VPD Policies and Applications Context Using Policy Manager (continued) 56 Database Security and Auditing
Viewing VPD Policies and Applications Context Using Policy Manager (continued) 57 Database Security and Auditing
Viewing VPD Policies and Applications Context Using Policy Manager (continued) 58 Database Security and Auditing
Implementing Row- and Column- level Security with SQL Server • SQL Server 2000 does not support VPDs; you can mimic their functionality • Use views and expand security models 59 Database Security and Auditing
Row-based Security Using Access Levels • Variation of both: – Application table-based security model – Application function-based security model • Access levels: – 0 = No access – 1 = select – 2 = select, insert – 3 = select, insert, update 60 Database Security and Auditing
Row-based Security Using Access Levels (continued) • Access levels (continued): – 4 = select, insert, update, delete – 5 = administrator access • Steps: – Create the APPLICATION USERS table – Alter the CUSTOMER table to include the ACCESS CONTROL column – With the security structure in place use a view to retrieve data 61 Database Security and Auditing
Row-based Security Using Application Functions • Steps (continued): apply privileges • Drawbacks: it allows insertion, update, and deletion of records • Alternatives: – Use stored procedures – Use application functions: access table list a function instead of a level 62 Database Security and Auditing
Column-based Security • VPD and Column Access Using Oracle steps: – Log in as VPD_CLERK2 and view rows and columns in the CUSTOMERS table – Log in as the DBSEC user and recreate the policy on customers – Log in as VPD_CLERK2 and query the CUSTOMERS table 63 Database Security and Auditing
Column-based Security • Column privileges in Oracle steps: – Log in as DBSEC and create a table called TEST – Grant SELECT on the TEST table to SCOTT – Grant UPDATE only on the column TEXT in the TEST table to SCOTT – Insert a row into the TEST table and save it – Log in as SCOTT and query the TEST table owned by DBSEC 64 Database Security and Auditing
Column-based Security (continued) • Column privileges in Oracle steps (continued): – Update the TEXT column in the TEST table – Try to update the NUM column in the TEST table 65 Database Security and Auditing
Column-based Security (continued) • Access-level control with SQL Server steps: – Create the APP_TABLES table – Create the APP_COLUMNS columns – All access to the tables must be performed with stored procedures 66 Database Security and Auditing
Column-based Security (continued) • Column Privileges with SQL Server steps: set update permissions for sam on the column phone in the Customer table • Customized column-access control facilitates management 67 Database Security and Auditing
Summary • A virtual private database allows or prevents data access at the row or column level; implemented using VIEW database object • VPDs are also referred to as row-level security (RLS) or fine-grained access (FGA) • SQL Server does not support VPDs • Microsoft SQL Server 2000 system 68 Database Security and Auditing function of USER
Summary (continued) • Oracle Application context: – Allows setting of database application be retrieved by database sessions – SYS_CONTEXT function – PL/SQL package DBMS_SESSION – SET_CONTEXT procedure • Use Oracle-supplied package DBMS_RLS to add the VPD policy • Oracle data dictionary views 69 Database Security and Auditing
Summary (continued) • Oracle Policy Manager: graphical tool used to administer VPD policies • Oracle has the capability to restrict updates or inserts on columns, using GRANT UPDATE(column) and INSERT(column) 70 Database Security and Auditing