Security Fall 2009McFadyen ACS-49021 How do we protect the database from unauthorized access? Who...

Security

Fall 2009 McFadyen ACS-4902 1

How do we protect the database from unauthorized access?

Who can see employee salaries, student grades, … ?

Who can update … ?

Techniques include/involve:

•accounts - system (DBA), user

•passwords

•log-in process - new entry for the log: {who, where, when}

•privileges

•roles

•encryption

Security


Control mechanisms:

•Discretionary access control (DAC)

•Text: 23.2

•Mandatory access control (MAC)

•Text: 23.3

•Role-based access control (RBAC)

•Text: 23.3.2

•NIST. An introduction to Role Based Access Control

•R. S. Sandhu, E.J. Coyne, H.L. Feinstein, C.E. Youman, Role-Based Access Control Models

Security


Other references:

http://en.wikipedia.org/wiki/Access_control

http://www.oracle.com/technology/products/applications/security/OracleUserManagementWhitePaper.pdf

http://www.oracle.com/technology/deploy/security/seceval/pdf/seceval_wp.pdf

http://www.businessandit.uoit.ca/pst2006/files/presentations/rjaibi.pdf

http://www.computerwoche.de/index.cfm?pid=360&pk=3203&opv=tb&p=3

Security


Discretionary access control (DAC)

•privileges such as read, write, update are granted to users/accounts

•a certain amount of discretion is given to the owner or anyone else with appropriate authority

Security


Mandatory access control (MAC)

•multilevel security is applied to data and users

•controlled by a central authority, not by owners of an object

•the owner/creator of an object does not decide who has clearance to see the object

Security


Role-based access control (RBAC)

•involves users, roles, operations, permissions, sessions

•permissions such as read, write, update are applied to objects/resources

•for a database we could have

•database-level – connect, …

•table/column level – update, …

•stored procedures – execute, …

•users are persons

•users interact with system during sessions, during a session the user invokes one or more roles

•roles are collections of job functions

RBAC

Security


Role Example:

•a role Specialist could contain the roles of Doctor and Intern. This means that members of the role Specialist are implicitly associated with the operations associated with the roles Doctor and Intern without the administrator having to explicitly list the Doctor and Intern operations

•roles Cardiologist and Rheumatologist could each contain the Specialist role

RBAC

Security


RBAC

Example from a paper on RBACWe might have drawn this as:

cardiologist rheumatologist

specialist

doctor

intern

Security


Example:

A teller and an accounting supervisor in a bank.Teller: read/write access to records.Supervisor: perform correction (also need read/write access).

Rule #1: Supervisor cannot initiate deposits or withdrawals, but can only perform corrections after the fact.Rule #2: Teller can only initiate deposits or withdrawals, but cannot perform corrections once the transaction has been completed.

RBAC

Security


Example:

See class discussion•Create the database from ER/Studio•Populate database•Create views•Give users access to the database•Create roles in the database•Add users to the roles•Add permissions to the roles

RBAC

Security


RBAC

Some variations of RBAC allow lattices for roles…. What change is needed for the ERD?

Security


Security principles:

•Least privilege

•Separation of duties

•Data abstraction

RBAC

Security


Least privilege

•user must be given no more privilege than is necessary to perform the job.

•concept of least privilege requires identifying the user's job functions, determining the minimum set of privileges required to perform that function, and restricting the user to a domain with those privileges and nothing more

RBAC

Security


Separation of duties – mutually exclusive

•Example: requiring an accounting clerk and account manager to participate in issuing a cheque

•These two roles must be mutually exclusive to deter fraudulent activities

RBAC

Security


Data abstraction :

•Permission can be defined at a higher level, rather than on read/write/ execute. For example, permissions can be defined on credit, debit for an account object

•This is in contrast to the more conventional and less intuitive process of attempting to administer lower-level access control mechanisms directly (e.g., access control lists, capabilities) on an object-by-object basis

RBAC

Security


MAC / DAC:

•US DoD has four basic divisions for systems: A, B, C, D

•lowest to highest is D, C1, C2, B1, B2, B3, A1

•C1, C2, B1, B2, B3, A1 require DAC

•B1, B2, B3, A1 require MAC

Security


Discretionary access control

•based on granting and revoking of privileges based on a users identity or group they belong to

Discretionary

Security



•example

•grant createtab to A1 ;

if A1 creates a table X, then A1 owns X, and has all privileges on table X, and A1 can grant privileges to others

Discretionary

Security



•access matrix model:

subject1

object1 object2 object3

subject2

subject3

read/write/updateUsers/accounts/programs

Relations/records/columns/views/operations

Discretionary

Security


Discretionary access control: suppose A1 executes:

•create table employee (…);•create table department (…);•grant insert, delete on employee, department to A2;•grant select on employee, department to A3;•grant update on employee(salary) to A4;

A1

employee department

A2

A3

all

insert, delete

select

all

insert, delete

select

employee.salary

A4 update

Discretionary

access matrix

Security


Discretionary access control: Views

•suppose A1 executes:

create view EmployeesInDiv5 asselect name, position, manager from employee e, department dwhere d.div=5 and e.deptno=d.deptno;

grant select on EmployeesInDiv5 to A4;

employee department

A4

all

select

all

EmployeesInDiv5

A1 all

Discretionary

Security


Mandatory access control for multilevel security

Bell LaPadula model:

•specifies the allowable paths of information flow

•set of subjects S, and a set of objects O

•each s in S and o in O has a fixed security class

C(s) a clearance

C(o) a classification level

•security classes are ordered by <=

e.g. public <= sensitive <= top secret

Mandatory

Security



Two properties of the Bell LaPadula model:

•Simple Security Property

a subject s is not allowed read access to an object o unless

C(s) >= C(o)

Mandatory

To see something, your clearance must be at least that of what you want

In the military model, the security clearance of someone receiving a piece of information must be at least as high as the classification of the information

Security



Second property of the Bell LaPadula model:

•Star Property

a subject s is not allowed write access to an object o unless

C(s) <= C(o)

Mandatory

In the military model, a person receiving some information at one level may pass that information along only to people at levels no lower than the level of the information

To create/update something, your clearance must be no greater than the object you are creating/updating

Security



Implementation of the Bell LaPadula model:

•for each original attribute in a relation, add a classification attribute

•add a classification attribute for the tuple (row) - value is maximum of all classifications within the tuple

•these classification attributes are transparent to the user

Mandatory

Security



Implementation example: suppose U <= C <= S

Mandatory

Employee relation

Smith 40,000 Fair

Brown 80,000 Good

Name Salary JobPerformance The user view without MAC

Smith U 40,000 C Fair S S

Brown C 80,000 S Good C S

Name C1 Salary C2 JobPerformance C3 TC system view with MAC

Security



Implementation example:

Mandatory

Stored Rows:

we store only the required tuples that then allow us to materialize tuples for lower levels

For example,

allows us to materialize tuples for Classes U, C, and S:

U:

C:

S:


Smith null null

Smith 40,000 null

Smith 40,000 Fair

Security




Mandatory

What does a class C user see if he/she executes

Select * from Employee

Smith 40,000 null

Name Salary JobPerformance



Name C1 Salary C2 JobPerformance C3 TC

Brown null Good

The result is

filtered

Security




Mandatory

What happens if a class C user executes

Update Employee set Salary=100,000







Brown C 100,000 C Good C C

Class C attribute

is updated

Class S attribute

forces

polyinstantiation

Let’s assume the result

is to be class C.

Security




Mandatory

Stored Rows:

our update example required a row to be polyinstantiated

For example, updating the Salary field in

requires two rows for us to be able to materialize records for classes S, C




Two rows with

the same key!

Security




Mandatory

What does a class C user see if he/she executes

Select * from Employee

The result is

filteredSmith U 100,000 C Fair S S




Smith 100,000 null

Name Salary JobPerformance

Brown 100,000 Good

Only the row with TC=C is used

Security Fall 2009McFadyen ACS-49021 How do we protect the database from unauthorized access? Who...

Documents

Transcript of Security Fall 2009McFadyen ACS-49021 How do we protect the database from unauthorized access? Who...