1. Trang chủ
  2. » Công Nghệ Thông Tin

Bài giảng Bảo mật cơ sở dữ liệu: Chương 8 - Trần Thị Kim Chi

70 86 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 70
Dung lượng 1,24 MB

Nội dung

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 1

Pag 1

Chương VIII

Trang 2

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

Trang 3

Database 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 4

Pag 4

Giới thiệu về Virtual Private Database

Database Security and Auditing

Trang 5

Pag 5

Giới thiệu về Virtual Private Database

Database Security and Auditing

Ví dụ

Trang 6

Pag 6

Giới thiệu về Virtual Private Database

Database Security and Auditing

Ví dụ

Trang 7

Pag 7

Giới thiệu về Virtual Private Database

Database Security and Auditing

Ví dụ

Trang 8

Database 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 9

Database 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 10

Database 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 11

Database 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 12

Database 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 13

Database 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 14

Database 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 15

Database 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 16

Database 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 17

Database 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 18

Database Security and Auditing

18

Tạo User trong SQL Server

Trang 19

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

• ‘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 20

Database Security and Auditing

20

Tạo User trong Oracle

Trang 21

Database Security and Auditing

21

Cấp quyền cho User trong Oracle

Trang 22

Database 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 23

Database 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 24

Database 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 25

Database 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 26

Database 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 27

Database Security and Auditing

27

Create an Application Context

Next we make sure that all users have access to the

Trang 28

Database 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 29

Database 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 30

Database Security and Auditing

Trang 31

Database 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 32

Database 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 33

Database 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 34

Database 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 35

Database 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 36

Database Security and Auditing

SELECT * FROM schemaowner.user_data;

CONNECT user2/user2@Service SELECT * FROM

schemaowner.user_data;

Trang 37

Database 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 38

Database 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 39

Database 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 40

Database 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 41

Database 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 42

Database 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 43

Database 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 45

Database 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 46

Database Security and Auditing

46

Implementing Oracle Virtual

Private Databases (continued)

Trang 47

Database Security and Auditing

47

Implementing Oracle Virtual

Private Databases (continued)

Trang 48

Database 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 49

Database 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 50

Database 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

Ngày đăng: 30/01/2020, 13:15

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w