Case Study

Case Study: Oracle Label ... • For example, an authorized user can raise the level of a data row that has a level lower than his own minimum level...

0 downloads 226 Views 806KB Size
Case Study:  Case Study: Oracle Label Security

1

Oracle O ac e Label abe Essential sse t a Co Concepts cepts • Oracle Label Securityy enables row-level access control,, based on the virtual private database technology of Oracle Enterprise Edition • It controls t l access to t the th contents t t off a row by b comparing i that row's label with a user's label and privileges row restrictive policies • Administrators can add selective row-restrictive to existing databases • Developers can add label-based access control to their O l applications Oracle li ti

2

Oracle Label Architecture

3

Label policy features • Oracle label controls the access to data by using 3 factors: – The label of the data row to which access is requested – The label of the user session requesting access – The policy privileges for that user session

4

Data Labels • Every label contains three components: – a single level (sensitivity) ranking – zero or more horizontal compartments or categories – zero or more hierarchical groups

5

Data Labels

Example: Confidential (10) Highly g y Confidential (20) ( ) Sensitive (30)

The more sensitive the information, the higher its level. The less sensitive the information, the lower its level.

NOTE: Labels have a character form and a numeric form

6

Data Labels: Compartments p • Compartments identify areas that describe the sensitivity of the labeled data,, pprovidingg a finer level of ggranularityy within a level • The compartment component is not hierarchical

Example: Confidential (10) Highly g y Confidential (20) ( ) Sensitive (30)

Departments: Finance (it has sensitive and highly confidential data) Chemical ((it has sensitive data)) Operation (it has sensitive, highly confidential and confidential data) 7

Data Labels: Compartments p Levels: Sensitive HC Confidential

Compartments: Financial Chemical Financial

Operation Operation

• Note that some data in the protected table may not belong to any compartment. • If compartments are specified, then a user whose level would normally permit access to a row's data will nevertheless be prevented from such access unless the user user'ss label also contains all the compartments appearing in that row's label.

8

Data Labels: Groups p • The group component is hierarchical and is used to reflect ownershipp • EXAMPLE: suppose one has two groups of users, Finance and Engineering. Users with the label Finance cannot access to data l b l d Engineering labeled E i i (and ( d vice i versa), ) because b they th are “at “ t the th same level” • Suppose pp that one has a ggroup p Board of Directors ((BoD). ) Users in this group must be allowed to access the data of both Finance and Engineering group. • To T this thi end, d one can establish t bli h a group hierarchy, hi h where h BoD B D is i the group “parent” of Finance and Engineering groups

9

Data Labels: Groups p

Example: Confidential (10) Highly g y Confidential (20) ( ) Sensitive (30)

Departments: Finance Chemical Operation

Groups: BoD

Finance

Engineering

10

Data Labels • A label can be any one of the following four combinations of components: – a single level component, with no groups or compartments, such as U:: – a level and a set of compartments with no groups, such as U:Alpha Beta: U:Alpha, – a level and a set of groups with no compartments, such as U::FIN, ASIA – a level with both compartments and groups, such as U:Beta,Psi:ASIA,FIN

11

Examples p

12

User Labels • A user label specifies p that user's sensitivityy level pplus anyy compartments and groups that constrain the user's access to labeled data. • Each E h user is i assigned i d a range off levels, l l compartments, t t andd groups, and each session can operate within that authorized range to access labeled data within that range.

13

User Labels and level authorizations

User Default Level: The level that is assumed by default when connecting to Oracle User Default Row Level: The level that is used by default when inserting data into Oracle 14

User Labels and compartments

The administrator Th d i i specifies ifi the h list li off compartments that h a user can place l in i her h session i label. l b l Write access must be explicitly given for each compartment The Row designation indicates whether the compartment should be used as part of the default y inserted data. row label for newly A user cannot directly insert, update, or delete a row that contains a compartment that she does not have authorization to write. 15

User Labels and  authorized groups authorized groups

The administrator specifies the list of groups that a user can place in  The administrator specifies the list of groups that a user can place in her session label. Write access must be explicitly given for each group listed. Row designation indicates whether the group should be used as Row designation indicates whether the group should be used as  part of the default row label for newly inserted data. 16

Session Labels • The session label is the particular combination of level, compartments, and groups at which a user works at any given time. • The user can change the session label to any combination of components for which he is authorized. • When a user writes data without specifying its label, a row label is assigned automatically, using the user's session label. 17

How Data Labels and User Labels Work Together b l k h • Each Oracle Label Security user can only access data within  the range of his or her own label authorizations. • Each user has: – Maximum and minimum levels – A set of authorized compartments – A set of authorized groups (and, implicitly, authorization for any  subgroups) – For each compartment and group, a specification of read‐only  access, or read/write access

• Example: – if a user is assigned a maximum level of Highly Confidential,  then the user potentially has access to Highly Confidential, and  Confidential data. The user has no access to Sensitive data.

18

How Data Labels and User Labels Work Together b l k h

WR

WR_SAL

19

Policy Privileges Policy Privileges • The policy privileges enable a user or a stored program unit to bypass some aspects of the labelbased access control policy • The administrator can also authorize the user or program unit to perform specific actions, such as the ability of one user to assume the authorizations of a different user • Privileges can be granted to program units, authorizing the procedure, rather than the user, to perform privileged operations 20

Privileges in Oracle Label Security Policies Security Policies • Oracle Label Security supports special privileges that allow authorized users to bypass certain parts of the policy. policy

21

Privileges in Oracle Label Security Policies Security Policies •

READ – A user with READ privilege can read all data protected by the policy, regardless of his authorizations or session label. The user does not even need to have label authorizations. – A user with READ privilege can write to any data rows for which he or she has write access, based on any label authorizations. – The READ privilege enables optimal performance on SELECTs, since the system behaves as though the Oracle Label Security policy were not even present. – Useful U f l • for system administrators who need to export data, but who should not be allowed to change data. • for people who must run reports and compile information, information but not change data. data



FULL – The FULL privilege has the same effect and benefits as the READ privilege, privilege with one difference: a user with FULL privilege can also write to all the data. 22

Privileges in Oracle Label Security Policies Security Policies COMPACCESS • The Th COMPACCESS privilege i il allows ll a user to access ddata bbased d on the row label's compartments, independent of the row label's g p groups. • If a row label has no compartments, then access is determined by the group authorizations. However, when compartments do exist, and access to them is authorized authorized, then the group authorization is bypassed. • This allows a pprivileged g user whose label matches all the compartments of the data to access any data in any particular compartment, independent of what groups may own or otherwise be allowed access to the data data. 23

Label Evaluation Process for Read  Access with COMPACCESS Privilege Access with COMPACCESS Privilege

24

Privileges in Oracle Label Security Policies Security Policies PROFILE_ACCESS • The PROFILE_ACCESS privilege allows a session to change its session labels and session privileges to those of a different user. • This is a very powerful privilege, since the user can potentially i ll become b a user with i h FULL privileges. i il • This privilege cannot be granted to a trusted stored program unit. it

25

Special Row Label Privileges  p g • Once the label on a row has been set, Oracle Label  S Security privileges are required to modify the label. i i il i d dif h l b l • These privileges include WRITEUP, WRITEDOWN,  and WRITEACROSS. d WRITEACROSS

26

Special Row Label Privileges  p g • WRITEUP – The WRITEUP privilege enables the user to raise the level of data within a row, without compromising the compartments or groups. – The user can raise the level up p to his or her maximum authorized level. •

For example, an authorized user can raise the level of a data row that has a level lower than his own minimum level. If a row is UNCLASSIFIED and the user's maximum level is SENSITIVE, he can raise the row's level to SENSITIVE.

– H He can raise i the th level l l above b his hi currentt session i level, l l but b t cannott change the compartments.

27

Special Row Label Privileges  p g • WRITEDOWN – The WRITEDOWN privilege enables the user to lower the level of data within a row, without changing the compartments or groups. The user can lower the level to any level equal to or greater than his or her minimum authorized level. • WRITEACROSS – The WRITEACROSS privilege allows the user to change the compartments and groups of data, data without altering its sensitivity level.

28

Documentation • Oracle Oracle® Label Security Administrator Label Security Administrator’ss Guide Guide • 11g Release 2 (11.2) E10745‐02 – http://docs.oracle.com/cd/E11882_01/network.1 htt //d l / d/E11882 01/ t k1 12/e10745.pdf

29