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

Pag. 1 Chương VIII Pag. 2 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 Database Security and Auditing3 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, fine-grained access (FGA) Pag. 4 Giới thiệu về Virtual Private Database Database Security and Auditing Pag. 5 Giới thiệu về Virtual Private Database Database Security and Auditing Ví dụ Pag. 6 Giới thiệu về Virtual Private Database Database Security and Auditing Ví dụ Pag. 7 Giới thiệu về Virtual Private Database Database Security and Auditing Ví dụ Database Security and Auditing8 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 Database Security and Auditing9 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. Database Security and Auditing10 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. Database Security and Auditing11 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. Database Security and Auditing12 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. Database Security and Auditing13 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. Database Security and Auditing14 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. Database Security and Auditing15 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. Database Security and Auditing16 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). Database Security and Auditing17 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 Database Security and Auditing18 Tạo User trong SQL Server 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 Database Security and Auditing20 Tạo User trong Oracle Database Security and Auditing21 Cấp quyền cho User trong Oracle Database Security and Auditing22 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; Database Security and Auditing23 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@service Database Security and Auditing24 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; Database Security and Auditing25 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; END; Database Security and Auditing26 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'); END set_context; END context_package; / SHOW ERRORS Database Security and Auditing27 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; Database Security and Auditing28 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 Database Security and Auditing29 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. Database Security and Auditing30 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; Database Security and Auditing31 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; Database Security and Auditing32 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 Database Security and Auditing33 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; Database Security and Auditing34 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'); END; / Database Security and Auditing35 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; Database Security and Auditing36 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; Database Security and Auditing37 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. Database Security and Auditing38 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 Database Security and Auditing39 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. • Database Security and Auditing40 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.. Database Security and Auditing41 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 Database Security and Auditing42 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. Database Security and Auditing43 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. . Database Security and Auditing44 Implementing Oracle Virtual Private Databases (continued) Database Security and Auditing45 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 Database Security and Auditing46 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 Database Security and Auditing47 Implementing Oracle Virtual Private Databases (continued) Database Security and Auditing48 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_SESSION Database Security and Auditing49 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 Database Security and Auditing50 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 Database Security and Auditing51 Implementing Oracle Virtual Private Databases (continued) Database Security and Auditing52 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 Database Security and Auditing53 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 Database Security and Auditing54 Viewing VPD Policies and Applications Context Using the Data Dictionary Database Security and Auditing55 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 Database Security and Auditing56 Viewing VPD Policies and Appli