Bài giảng Bảo mật cơ sở dữ liệu - Chương 8: Virtual private database cung cấp cho người học các nội dung: Giới thiệu về Virtual private database, Row-level security, kỹ thuật làm việc với policy function, quyền Exempt Access Policy, giám sát quyền Exempt Access Policy, xử lý các Exception về Policy Function,... Mời các bạn cùng tham khảo.
Trang 1Pag 1
Chương VIII
Trang 2Pag 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
Trang 3Database Security and Auditing
3
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)
Trang 4Pag 4
Giới thiệu về Virtual Private Database
Database Security and Auditing
Trang 5Pag 5
Giới thiệu về Virtual Private Database
Database Security and Auditing
Ví dụ
Trang 6Pag 6
Giới thiệu về Virtual Private Database
Database Security and Auditing
Ví dụ
Trang 7Pag 7
Giới thiệu về Virtual Private Database
Database Security and Auditing
Ví dụ
Trang 8Database Security and Auditing
8
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
Trang 9Database Security and Auditing
9
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áchbảo mật và liên kết các chính sách bảo mật đó với cáctable, view hoặc synonym
• Việc gán các chính sách như vậy khiến cho những ngườidù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 chobất kỳ user nào truy xuất đến table đó mà không cầnngười quản trị phải gán chính sách cho từng user
Trang 10Database Security and Auditing
• 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.
Trang 11Database Security and Auditing
11
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ộtchính sách bảo mật mô tả các quy định quản lý việc truyxuất các dòng dữ liệu
Trang 12Database Security and Auditing
• 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.
Trang 13Database Security and Auditing
13
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 haysynonym 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ậpvào: object_name, policy_name, policy_function (Mô tả chitiết của package DBMS_RLS được chứa trong filethư_mục_cài_đặt_Oracle\Oracle\RDBMS\ADMIN\dbmsrlsa.sql)
• Sự kết hợp của object_schema, object_name, và policy_name
phải là duy nhất.
Trang 14Database Security and Auditing
14
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ántiếp vào đối tượng được bảo vệ, RLS engine sẽ được gọi mộtcá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 theophép AND
Trang 15Database Security and Auditing
15
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
• 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.
Trang 16Database Security and Auditing
16
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ảntrị bảo mật Điều này quan trọng vì việc truy xuất vào cácpolicy 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ácpolicy 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áchhiệu quả, thông thường người ta sử dụng kết hợp RLS vớiApplication 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ụngchính sách bảo mật nào là dựa trên người dùng thuộcDepartment số mấy)
Trang 17Database Security and Auditing
17
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
Trang 18Database Security and Auditing
18
Tạo User trong SQL Server
Trang 19Tạ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
• ‘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
Trang 20Database Security and Auditing
20
Tạo User trong Oracle
Trang 21Database Security and Auditing
21
Cấp quyền cho User trong Oracle
Trang 22Database Security and Auditing
22
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;
Trang 23Database Security and Auditing
23
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
Trang 24Database Security and Auditing
24
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;
Trang 25Database Security and Auditing
25
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
Trang 26Database Security and Auditing
26
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
END set_context; END context_package; / SHOW ERRORS
Trang 27Database Security and Auditing
27
Create an Application Context
Next we make sure that all users have access to the
Trang 28Database Security and Auditing
28
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
Trang 29Database Security and Auditing
29
Create Security Policies
• In order for the context package to have any effect onthe users interaction with the database, we need todefine a security_package for use with the securitypolicy
• This package will tell the database how to treat anyinteractions with the specified table
Trang 30Database Security and Auditing
Trang 31Database Security and Auditing
31
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;
Trang 32Database Security and Auditing
32
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
Trang 33Database Security and Auditing
33
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;
Trang 34Database Security and Auditing
34
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; /
Trang 35Database Security and Auditing
35
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;
Trang 36Database Security and Auditing
SELECT * FROM schemaowner.user_data;
CONNECT user2/user2@Service SELECT * FROM
schemaowner.user_data;
Trang 37Database Security and Auditing
• 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
Trang 38Database Security and Auditing
38
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
Trang 39Database Security and Auditing
39
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
•
Trang 40Database Security and Auditing
40
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
Trang 41Database Security and Auditing
41
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
Trang 42Database Security and Auditing
42
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 đượcrecompile và thực thi Ví dụ, lỗi này sẽ xảy ra khi policytruy vấn đến một table không tồn tại Lỗi về chính sáchcũ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ụcADD_POLICY)
• Chuỗi trả về của policy function khi được thêm vào câulệnh SQL truy vấn trên đối tượng được bảo vệ gây ra lỗicâu lệnh SQL không hợp lệ Có rất nhiều lý do khiếncho việc này xảy ra
Trang 43Database Security and Auditing
43
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
Trang 44
Database Security and Auditing
44
Implementing Oracle Virtual
Private Databases (continued)
Trang 45Database Security and Auditing
45
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
Trang 46Database Security and Auditing
46
Implementing Oracle Virtual
Private Databases (continued)
Trang 47Database Security and Auditing
47
Implementing Oracle Virtual
Private Databases (continued)
Trang 48Database Security and Auditing
48
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
Trang 49Database Security and Auditing
49
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
Trang 50Database Security and Auditing
50
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