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

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:

Database Security and Auditing

3

– Specific functions – Row-level security, fine-grained access (FGA)

Giới thiệu về Virtual Private Database

Pag. 4 Database Security and Auditing

Giới thiệu về Virtual Private Database

Ví dụ

Pag. 5 Database Security and Auditing

Giới thiệu về Virtual Private Database

Ví dụ

Pag. 6 Database Security and Auditing

Giới thiệu về Virtual Private Database

Ví dụ

Pag. 7 Database Security and Auditing

Overview of Virtual Private Databases (continued)

Database Security and Auditing

8

Thực thi VPD là sự kết hợp của 2 kỹ thuật: • Fine-grained access control (FGAC) • Application Context

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.

Database Security and Auditing

9

• 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.

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

Database Security and Auditing

10

• 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.

Row-level Security

Database Security and Auditing

11

• 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.

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 Auditing

12

Row-level Security

của package DBMS_RLS được

chứa

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 trong file thư_mục_cài_đặt_Oracle\Oracle\RDBMS\ADMIN\dbmsrlsa.s ql).

phải là duy nhất.

Database Security and Auditing

13

• Sự kết hợp của object_schema, object_name, và policy_name

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.

sách bảo mật nào.

Database Security and Auditing

14

• Tuy nhiên, account SYS không bị ảnh hưởng bởi bất kỳ chính

• 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.

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.

Database Security and Auditing

15

• 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.

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.

Database Security and Auditing

16

• Để 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).

Setting op a Virtual Private Databases

Database Security and Auditing

17

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

Tạo User trong SQL Server

Database Security and Auditing

18

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ó

• •

•

• Có thể tạo user mới từ Enterprise Manager

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.

Tạo User trong Oracle

Database Security and Auditing

20

Cấp quyền cho User trong Oracle

Database Security and Auditing

21

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;

Database Security and Auditing

22

CREATE USER schemaowner IDENTIFIED BY schemaowner DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp; GRANT connect, resource TO schemaowner;

Setup Test Environment

CREATE USER user1 IDENTIFIED BY user1 DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp;

GRANT connect, resource TO user2;

GRANT connect, resource TO user1; CREATE USER user2 IDENTIFIED BY user2 DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp;

Database Security and Auditing

23

GRANT EXECUTE ON DBMS_RLS TO PUBLIC;

CONN schemaowner/schemaowner@service

Setup Test Environment

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 Auditing

24

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 an Application Context

create the context and context package.

• Grant CREATE ANY CONTEXT to the schema owner then

CONNECT sys/password@service AS SYSDBA;

TO schemaowner;

GRANT create any context, create public synonym

CONNECT schemaowner/schemaowner@service;

CREATE CONTEXT SCHEMAOWNER USING

SCHEMAOWNER.context_package;

Database Security and Auditing

25

CREATE OR REPLACE PACKAGE context_package

AS PROCEDURE set_context;

END;

Create an Application Context

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');

Database Security and Auditing

26

END set_context; END context_package; / SHOW ERRORS

Next we create the context_package body which will actually set the user context. CREATE OR REPLACE PACKAGE BODY context_package IS

Create an Application Context

CREATE PUBLIC SYNONYM context_package FOR SCHEMAOWNER.context_package;

Database Security and Auditing

27

Next we make sure that all users have access to the Context_Package. GRANT EXECUTE ON SCHEMAOWNER.context_package TO PUBLIC;

Create Login Trigger

Next we must create a trigger to fire after the user logs onto the database.

CREATE OR REPLACE TRIGGER SCHEMAOWNER.set_security_context AFTER LOGON ON DATABASE BEGIN SCHEMAOWNER.context_package.set_context; END; --SHOW ERRORS

Database Security and Auditing

28

CONNECT sys/password@service AS SYSDBA;

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.

interactions with the specified table.

Database Security and Auditing

29

• This package will tell the database how to treat any

Create Security Policies

CONNECT schemaowner/schemaowner@service;

CREATE OR REPLACE PACKAGE

user_data_insert_security(owner VARCHAR2,

security_package AS FUNCTION

objname VARCHAR2) RETURN VARCHAR2;

VARCHAR2, objname VARCHAR2) RETURN

FUNCTION user_data_select_security(owner

VARCHAR2;

Database Security and Auditing

30

END security_package;

Create Security Policies

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

Database Security and Auditing

31

IF; RETURN predicate; END user_data_select_security;

• Next we create the security_package body.

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 Auditing

32

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 Auditing

33

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');

Database Security and Auditing

34

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;

Database Security and Auditing

35

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;

Test VPD

CONNECT schemaowner/schemaowner@service

SELECT * FROM schemaowner.user_data;

CONNECT user1/user1@Service;

SELECT * FROM schemaowner.user_data;

schemaowner.user_data;

Database Security and Auditing

36

CONNECT user2/user2@Service SELECT * FROM

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.

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 Auditing

37

ORA-28115: policy with check option violation • Once the inserts are finished, there will be two rows in

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 Auditing

38

Quyền EXEMPT ACCESS POLICY

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).

• Tuy RLS cung cấp một kỹ thuật bảo mật rất tốt, nhưng nó

• 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

Database Security and Auditing

39

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.

•

Giám sát quyền EXEMPT ACCESS POLICY

• 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 đó.

• 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)

trừ khỏi các chính sách RLS không bị lạm dụng..

Database Security and Auditing

40

• Auditing là một cách hiệu quả để đảm bảo quyền miễn

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';

Database Security and Auditing

41

GRANTEE ------------------------------ SYSTEM

Xử lý các Exception về Policy Function

• 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 Auditing

42

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).

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 Auditing

43

.

Implementing Oracle Virtual Private Databases (continued)

Database Security and Auditing

44

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 Auditing

45

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 Auditing

46

Implementing Oracle Virtual Private Databases (continued)

Database Security and Auditing

47

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

Database Security and Auditing

48

to execute DBMS_SESSION

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 Auditing

49

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 Auditing

50

Implementing Oracle Virtual Private Databases (continued)

Database Security and Auditing

51

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 Auditing

52

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 Auditing

53

Viewing VPD Policies and Applications Context Using the Data Dictionary

Database Security and Auditing

54

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 Auditing

55

Viewing VPD Policies and Applications Context Using Policy Manager (continued)

Database Security and Auditing

56

Viewing VPD Policies and Applications Context Using Policy Manager (continued)

Database Security and Auditing

57

Viewing VPD Policies and Applications Context Using Policy Manager (continued)

Database Security and Auditing

58

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

Database Security and Auditing

59

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

Database Security and Auditing

60

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

Database Security and Auditing

view to retrieve data 61

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

Database Security and Auditing

62

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

Database Security and Auditing

63

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

Database Security and Auditing

64

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

Database Security and Auditing

65

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

Database Security and Auditing

66

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

Database Security and Auditing

67

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

Database Security and Auditing

68

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

Database Security and Auditing

69

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)

Database Security and Auditing

70