Transcript 0216_accessControlx

Access Control
Li Xiong
CS573 Data Privacy and Security
What is Access Control?
 Security Engineering by Ross Anderson,
2001

Its function is to control which principles
(persons, processes, machines, …) have
access to which resources in the system –
which files they can read, which programs
they can execute, and how they share data
with other principles, and so on.
 Access control is pervasive
 OS (unix, windows), databases, Java
Night Club Example
 Authentication
 ID Check
 Access Control
 Over 18 - allowed in
 Over 21 - allowed to drink
 On VIP List - allowed to access VIP area
 Enforcement Mechanism
 Walls, Doors, Locks, Bouncers
Access control and other security
services
 Identification and Authentication – establishing and
verifying the identity of the user
 Something you know, such as a password or a
personal identification number (PIN).
 Something you have, such as a smart card or
security token.
 Something you are, such as fingerprint, voice,
retina, or iris characteristics.
 Where you are, for example on or off campus,
inside or outside a company firewall
 Access control determines which subject can access
what resources after identification and authentication
Access control and other security
services
 Enforcement mechanisms
 Auditing – posteriori analysis of all the
requests and activities of users in the system


Deterrent – users may be discouraged from
attempting violations
Means to analyze users behavior to detect
possible violations
Access control and other security
services
Access control
 Access control mechanisms – low level
software functions that can be used to
implement a policy


Access matrix model
Implementation approaches
 Access control policies – high level guidelines
that determine how accesses are controlled
Discretionary access control (DAC)
 Mandatory access control (MAC)
 Role based access control (RBAC)
 Attribute based access control (ABAC)

Access Matrix Model
 A set of subjects S
 A set of objects O
 A set of rights R
 An access control matrix
 One row for each subject
 One column for each subject/object
 Elements are right of subject on an another
subject or object
Access matrix
Implementation approaches
 Access control lists (ACLs)
 Capabilities
 Authorization relation or table
Access control lists (ACLs)
 Each object is associated with an ACL
 Storing the matrix in columns
 Modern OS typically take the ACL approach
Capabilities
 Each subject is associated with a capability list
 Storing the matrix in rows
Authorization relation
 Each row, or tuple, specifies one access right
of a subject to an object
 Relational databases typically use it
Access control
 Access control mechanisms – low level
software functions that can be used to
implement a policy


Access matrix model
Implementation approaches
 Access control policies – high level guidelines
that determine how accesses are controlled
Discretionary access control (DAC)
 Mandatory access control (MAC)
 Role based access control (RBAC)

Discretionary AC
 Restricts access to objects based solely on
the identity of users who are trying to
access them
 No restrictions on information flow
Individuals
Resources
database 1
database 2
database 3
Application
Access List
Name Access
Tom
Yes
John
No
Cindy
Yes
Mandatory AC
 Governs access based on the classification of subjects and
objects
 Assign a security level to all information – sensitivity of
information
 Assign a security level to each user – security clearance
 Military and government: Top secret (TS) > secret (S) >
confidential (C) > unclassified (U)
 Access principles
 Read Down – a subject’s clearance must dominate the
security level of the object being read
 Write Up – a subject’s clearance must be dominated by
the security level of the object being written

Mandatory AC (cont)
 Information can only flow upwards or within the same
class
Individuals
Write up
TS
S
Read down
Resources/Information
Database 1
DS
Database 2
S
Database 3
C
C
U
Role-Based AC
 Governs the access based on roles
 Access authorizations on objects are specified for roles
 Users are given authorizations to adopt roles
 A user has access to an object based on the roles
Role-Based AC
Individuals
Roles
Role 1
Role 2
Role 3
User’s change frequently, Roles don’t
Resources
Database 1
Database 2
Database 3
Role-based Access Control
Benefits
 Authorization management – assigning users to roles




and assigning access rights to roles
Hierarchical roles – Inheritance of privileges based
on hierarchy of roles
Least privilege – allow a user to sign on with least
privilege required for a particular task
Separation of duties – no single user should be given
enough privileges
Object classes – objects can be grouped based on
classifications
RBAC Reference Model (Sandhu ‘96)
 RBAC0, minimum requirement
 RBAC1, RBAC0 + role hierarchies
 RBAC2, RBAC0 + constraints
 RBAC3, RBAC1 + RBAC2
Models
Hierarchies
Constraints
RBAC0
No
No
RBAC1
Yes
No
RBAC2
No
Yes
RBAC3
Yes
Yes
Core RBAC System
(UA)
User Assignment
USERS
(PA)
Permission
Assignment
ROLES
OPS
OBS
PERMISSIONS
user_sessions
session_roles
SESSIONS
USERS
Process
Intelligent Agent
Person
ROLES
A role is a job function with some associated semantics
regarding responsibility and authority (permissions).
Director
Developer
Budget
Manager
Help Desk
Representative
MTM relation between
USERS & PRMS
Permissions
 A permission is an approval of a particular
access to one or more objects
 Database – Update Insert Append Delete
 Locks – Open Close
 Reports – Create View Print
 Applications - Read Write Execute
SQL
UA (user assignment)
USERS set
A user can be assigned to
one or more roles
ROLES set
Developer
A role can be assigned
to one or more users
Help Desk Rep
PA (permission assignment)
PRMS set
A prms can be assigned to
one or more roles
ROLES set
Create
Delete
Drop
Admin.DB1
View
Update
Append
A role can be assigned
to one or more prms
User.DB1
SESSIONS
Each session is a mapping of one user to possibly
many roles
USER
SESSION
FIN1.report1
SQL
DB1.table1
APP1.desktop
Role Hierarchy RBAC
(RH)
Role Hierarchy
(UA)
User Assignment
USERS
(PA)
Permission
Assignment
ROLES
OPS
OBS
PERMISSIONS
user_sessions
session_roles
SESSIONS
Tree Hierarchies
Production
Engineer 1
Quality
Engineer 1
Production
Engineer 2
Engineer 1
Quality
Engineer 2
Engineer 2
Engineering Dept
Director
Project Lead 1
Production
Engineer 1
Quality
Engineer 1
Project Lead 2
Production
Engineer 2
Quality
Engineer 2
Lattice Hierarchy
Director
Project Lead 1
Production
Engineer 1
Project Lead 2
Quality
Engineer 1
Production
Engineer 2
Engineer 1
Quality
Engineer 2
Engineer 2
Engineering Dept
Constrained RBAC
SSD
(RH)
Role Hierarchy
(UA)
User Assignment
USERS
(PA)
Permission
Assignment
ROLES
OPS
OBS
PERMISSIONS
user_sessions
session_roles
SESSIONS
DSD
Static mutual exclusion constraints
 Two mutually exclusive roles: cannot both have the
same user as members
 Two mutually exclusive roles: cannot both have the
same permissions
 Two mutually exclusive permissions: one role cannot
have both permissions
Cardinality constraints
 On user-role assignment
 At most k users can belong to the role
 At least k users must belong to the role
 Exactly k users must belong to the role
Dynamic Constraints
 At most k users can activate the same role in one
session
 No user is allowed to activate n or more roles in one
session
Constraints with Role Hierarchies
 Two roles can be mutually exclusive only if neither
one inherits the other
 If two roles are mutually exclusive, no roles can
inherit from both
 If two roles are mutually exclusive, there can be no
“root” or “super users”
Separation of Duty
 Constraints is a means rather than an end
 Separation of duty is the goal
 No single user possesses all the permissions needed
to accomplish a sensitive task
 Permission assignment problem
Attribute based Access Control
(ABAC)
 Access control decisions are made based on a set of
characteristics, or attributes, associated with the
requestor and/or the resource
 A requester provides a set of attributes, they are
checked against permissible attributes
 E.g. a person in UltraMegaCorp tries to access an
administration interface for customer data in Atlanta must
present credentials with a division attribute of “customer
relations division” and a title of “senior manager” and a
location attribute of “Atlanta”
 No need for predefined list of roles or permissions
References
 Access control: principle and practice,
Sandhu, 1994
 Role-based Access Control Models, Sandhu,
1996
Coming up
 Hippocratic databases
 Fine-grained access control
 Policy management and enforcement