Security
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
Fall 2006
McFadyen
ACS-4902
1
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
Fall 2006
McFadyen
ACS-4902
2
Security
Other references:
http://en.wikipedia.org/wiki/Access_control
http://www.oracle.com/technology/products/applications/se
curity/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=32
03&opv=tb&p=3
Fall 2006
McFadyen
ACS-4902
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
Fall 2006
McFadyen
ACS-4902
4
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
Fall 2006
McFadyen
ACS-4902
5
Security
RBAC
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
•roles are collections of job functions
Fall 2006
McFadyen
ACS-4902
6
Security
RBAC
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
Fall 2006
McFadyen
ACS-4902
7
Security
Fall 2006
McFadyen
ACS-4902
RBAC
8
Security
RBAC
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.
Fall 2006
McFadyen
ACS-4902
9
Security
Fall 2006
McFadyen
ACS-4902
RBAC
10
Security
RBAC
Security principles:
•Least privilege
•Separation of duties
•Data abstraction
Fall 2006
McFadyen
ACS-4902
11
Security
RBAC
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
Fall 2006
McFadyen
ACS-4902
12
Security
RBAC
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
Fall 2006
McFadyen
ACS-4902
13
Security
RBAC
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
Fall 2006
McFadyen
ACS-4902
14
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
Fall 2006
McFadyen
ACS-4902
15
Security
Discretionary
Discretionary access control
(in the context of relational systems)
•based on granting and revoking of privileges
•privileges are assigned at two levels:
•account (user) - each account can be assigned
privileges (rights or capabilities)
•relation - the privilege to access a particular relation is
controlled (restricted)
Fall 2006
McFadyen
ACS-4902
16
Security
Discretionary
Discretionary access control
•account level
•create - schema, table, view
•alter - indexes, table (attributes, indexes)
•drop - table, index, view
•example
•grant createtab to A1 ;
if A1 now creates a table X, then A1 owns X, and has all
privileges on table X, and A1 can grant privileges to
others
Fall 2006
McFadyen
ACS-4902
17
Security
Discretionary
Discretionary access control
•relation level
•type of access
•object that is restricted
•access matrix model:
Relations/records/columns/views/operations
object1
Users/
accounts/
programs
Fall 2006
subject1
subject2
subject3
object2
object3
read/write/update
McFadyen
ACS-4902
18
Security
Discretionary
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;
employee
department
A1
all
all
A2
insert, delete
insert, delete
A3
select
select
employee.salary
update
A4
Fall 2006
McFadyen
ACS-4902
19
Security
Discretionary
Discretionary access control: Views
•suppose A1 executes:
create view EmployeesInDiv5 as
select name, position, manager
from employee e, department d
where d.div=5 and e.deptno=d.deptno;
grant select on EmployeesInDiv5 to A4;
employee
A1
all
department
EmployeesInDiv5
all
all
select
A4
Fall 2006
McFadyen
ACS-4902
20
Security
Mandatory
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
Fall 2006
McFadyen
ACS-4902
21
Security
Mandatory
Mandatory access control for multilevel 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)
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
Fall 2006
McFadyen
ACS-4902
22
Security
Mandatory
Mandatory access control for multilevel 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)
To create/update something, your
clearance must be no greater than the
object you are creating/updating
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
Fall 2006
McFadyen
ACS-4902
23
Security
Mandatory
Mandatory access control for multilevel 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
Fall 2006
McFadyen
ACS-4902
24
Security
Mandatory
Mandatory access control for multilevel security
Implementation example: suppose U <= C <= S
Employee relation
Name
Salary
JobPerformance
Smith
Brown
40,000
80,000
Fair
Good
The user view
without MAC
Name C1 Salary C2 JobPerformance C3 TC
Smith U 40,000 C Fair
Brown C 80,000 S Good
Fall 2006
McFadyen
S
C
ACS-4902
S
S
system view
with MAC
25
Security
Mandatory
Mandatory access control for multilevel security
Implementation example:
Stored Rows:
we store only the required tuples that then allow us to
materialize tuples for lower levels
For example,
Smith U 40,000 C Fair
S
S
allows us to materialize tuples for Classes U, C, and S:
U:
Smith
null
null
C:
Smith
40,000
null
S:
Smith
40,000
Fair
Fall 2006
McFadyen
ACS-4902
26
Security
Mandatory
Mandatory access control for multilevel security
Implementation example:
What does a class C user see if he/she executes
Select * from Employee
Name C1 Salary C2 JobPerformance C3 TC
Smith U 40,000 C Fair
Brown C 80,000 S Good
S
C
Name
S
S
Salary
Smith
40,000
Brown null
Fall 2006
McFadyen
ACS-4902
JobPerformance
null
Good
27
Security
Mandatory
Mandatory access control for multilevel security
Implementation example:
What happens if a class C user executes
Update Employee set Salary=100,000
Name C1 Salary C2 JobPerformance C3 TC
Smith U 40,000 C Fair
Brown C 80,000 S Good
S
C
S
S
Name C1 Salary C2 JobPerformance C3 TC
Smith U 100,000 C Fair
S S
Brown C 80,000 S Good
C S
Brown C 100,000 C Good
Fall 2006
McFadyen
ACS-4902
C
C
28
Security
Mandatory
Mandatory access control for multilevel security
Implementation example:
Stored Rows:
our update example required a row to be polyinstantiated
For example, updating the Salary field in
Brown C 80,000 S Good
C
S
requires two rows for us to be able to materialize records for
classes S, C, and U
Fall 2006
Brown C 80,000 S Good
C
S
Brown C 100,000 C Good
C
C
McFadyen
ACS-4902
29
Security
Mandatory
Mandatory access control for multilevel security
Implementation example:
What does a class C user see if he/she executes
Select * from Employee
Name C1 Salary C2 JobPerformance C3 TC
Smith U 100,000 C Fair
S S
Brown C 80,000 S Good
C S
Brown C 100,000 C Good
C
C
Name Salary
JobPerformance
Smith 100,000 null
Brown 100,000 Good
Fall 2006
McFadyen
ACS-4902
30