Upload
bethany-walsh
View
220
Download
5
Embed Size (px)
Citation preview
Database Security
DB Security subsystem
• Authentication - ensures that a user is who he or she claims to be.
• Authorization - allows the user access to various resources based on the user's identity (a.k.a. permission, access right, privilege)
• Privacy - DBMS should provide confidentiality
Database Security
• Different aspects of database security – data encryption– allow retrieval of statistical information – Access control for a whole DBMS
• account numbers and passwords– Access control for portions of a database
• DB security and authorization subsystems secure portions of a DB against unauthorized access (4 approaches)
– Discretionary Access Control (DAC) – Mandatory Access Control (MAC) – Role Based Access Control (RBAC)– Attribute Based Access Control (ABAC)
Discretionary Access Control
DAC – from the beginning of time ...
Discretionary Access Control
• Based on granting and revoking privileges
• 2 levels for assigning privileges – account level (subject)
• independent of the relations • create schema, create table, create view
– relation level (object)
on a particular base relation or view
Access (authorization) matrix model• row - subject • column - object • M(i,j) -> read, write, update • for example M(a,B) = read means that subject a
holds read privilege on object B • Owner of the relation (typically the creator) is
assigned the owner account for that relation and is given all privileges on that relation
Grant/Revoke SQL statement
• Grant {privileges} on {table | view} to {user | public | role}
Grant select, delete on Employee, Department to Smith
• Revoke {privilege} on {table | view} from {user | public | role}
Revoke delete on Department from Smith
Using Views for Security
• Create view EMP as select Fname, Lname, address from Employee where dno=5;
Grant select on EMP to all;
Mandatory Access Control
MAC
Proposed in Mid 1980’s
Mandatory Access Control• Users have security clearances, data has security
classifications
• Need to restrict the access according to security level of user and data
• Useful for environments with hierarchical propagation of information
• Each subject and object are classified into one of the security classifications
• Security classes example:
– TS(Top Secret), S (Secret), C(Classified), U (Unclassified)
TS > S > C > U
Evolution of MLS models
• One way to utilize classification levels:– multilevel relation (MLS) schema– We will look at different MLS models to see
problems with each model and how these were addressed by the next model
Security Levels
• Properties: First must decide who can see which security level(s)?
Bell-LaPadulla properties
• All MLS Models are based on this
• Restrictions on data access –– simple property: No READ UP – star (*) property: No WRITE DOWN (write at
own level)
• Necessary but not sufficient conditions
• Still have problems – for example, covert channel
Designing MLS models
• How would you include different security levels in the data itself?– Add a classification level to PK?– Add a classification level to every attribute?
• Let us assume we have added a level for each column
MLS Relation Example
Vessel(PK) Objective Destination
Micra U Shipping U Moon U
Vision U Spying U Saturn U
Avenger C Spying C Mars C
Logos S Shipping S Venus S
Who sees what?
Vessel(PK) Objective Destination
Micra U Shipping U Moon U
Vision U Spying U Saturn U
Avenger C Spying C Mars C
Logos S Shipping S Venus S
MLS Insert
• What if a U user wants to insert a tuple with vessel = Avenger?
• 2 solutions:1. reject the insert, but?
• Covert channel
Covert Chanel
• Indirect downward flow of information– must be avoided since it allows downward
flow of information– Can occur if reject update– Can be used maliciously (higher level user
can signal lower level user)
MLS Insert
• What if a U user wants to insert a tuple with vessel = Avenger?2. Insert another Avenger
• Will have 2 avengers – problems?• 2 tuples with the same PK - Violates
uniqueness of relational model
MLS Relation
Vessel Objective Destination
Micra U Shipping U Moon U
Vision U Spying U Saturn U
Avenger U Shipping U Mars U
Avenger C Spying C Mars C
Logos S Shipping S Venus S
MLS Insert
• What does it mean to have 2 tuples with the same PK?– Does this mean there are 2 different Avengers– Or 1 Avenger with different info at different
classification levels?
MLS Update• What if the S level wants to update one of the
tuples at the U level? (Vision)
Update Vision so Destination is Venus• U should not see the update• Solutions
–Replicate the tuple – polyinstantiation
1. Put a null for the value at the U level?
2. Keep the old value at the U level?
Solution 1.
Vessel Objective Destination
Micra U Shipping U Moon U
Vision U Spying U Null U
Avenger U Shipping U Moon U
Avenger C Spying C Mars C
Vision U Spying U Venus S
Logos S Shipping S Venus S
Solution 2.
Vessel Objective Destination
Micra U Shipping U Moon U
Vision U Spying U Saturn U
Avenger U Shipping U Moon U
Avenger C Spying C Mars C
Vision U Spying U Venus S
Logos S Shipping S Venus S
MLS - Jajodia-Sandhu Model (JS)
• Jajodia-Sandhu was one of the first MLS models
• multilevel relation (MLS) schema – For each attribute, classification attribute C – Added a tuple classification TC
• Lowest user level that can see tuple
R(A1, C1, A2, C2, ...An, Cn, TC)
JS Relation Example
Vessel(PK) Objective Destination TC
Micra U Shipping U Moon U U
Vision U Spying U Saturn U U
Avenger C Spying C Mars C C
Logos S Shipping S Venus S S
JS Insert
• What if a U user wants to insert a tuple with vessel = Avenger? Insert another Avenger
JS Insert
Vessel Objective Destination TC
Micra U Shipping U Moon U U
Vision U Spying U Saturn U U
Avenger U Shipping U Mars U U
Avenger C Spying C Mars C C
Logos S Shipping S Venus S S
JS Insert
• JS model did not answer the question below:– Does this mean there are two different
Avengers or one Avenger with different info at different classification levels?
JS Update
• What if the S level wants to update Enterprise destination to Rigel?
JS Update
Vessel Objective Destination TCEnterprise U Exploration U Talos U U
S-user updates Enterprise destination to Rigel
Vessel Objective Destination TC
Enterprise U Exploration U null U U
Enterprise U Exploration U Rigel S S
What is view to U-user? S-user?
What does the null mean? Problem!
Covert channel?
JS Update
• U user wants to set Destination = Talos where Starship = ‘Enterprise”
JS UpdateVessel Objective Destination TCEnterprise U Exploration U null U UEnterprise U Exploration U Rigel S S
U user wants to set Destination = Talos where Starship = ‘Enterprise”
U view:Vessel Objective Destination TCEnterprise U Exploration U Talos U U
S View:Vessel Objective Destination TCEnterprise U Exploration U Talos U UEnterprise U Exploration U Rigel S S
JS Update
• Suppose S users want to update objective=spying where starship = ‘Enterprise” and destination =Rigel
JS UpdateU view:Vessel Objective Destination TCEnterprise U Exploration U Talos U U
S View:Vessel Objective Destination TCEnterprise U Exploration U Talos U UEnterprise U Exploration U Rigel S S
Suppose S users want to update objective=spying where starship = ‘Enterprise” and destination =‘Rigel’
S View:Vessel Objective Destination TCEnterprise U Exploration U Talos U UEnterprise U Spying S Rigel S S
JS Update
• Suppose U users want to update objective=spying where starship = ‘Enterprise” – There are 2 Enterprise tuples – both of which
have objective =Exploration at the U level– Should it only update the tuple with TC=U?
JS UpdateU view:Vessel Objective Destination TCEnterprise U Exploration U Talos U U
S View:Vessel Objective Destination TCEnterprise U Exploration U Talos U UEnterprise U Exploration U Rigel S S
U users want to update objective=Spying where starship = ‘Enterprise” S View:Vessel Objective Destination TCEnterprise U Spying U Talos U UEnterprise U Exploration U Rigel S S
JS Update
• Should the other Spying U be updated as well? • Should the Exploration change from U to S?• Not addressed in their early work • What does this mean?• Confusing?
Jajodia Sandhu MLS Model
• Entity integrity– What is the primary key?
• PK is now called the Apparent Key
• CAK is the classification of the PK
AK, CAK, Ci -> Ai
– Implies Primary key in MLS is:• AK U CAK U CR
• AK are data in PK, CAK is class of PK data, CR is data not in AK
JS model Integrity Constraints
• Entity integrity rule – all attributes that are members of the apparent key must not be
null and must have the same security classification within each individual tuple
• Null integrity– Nulls are classified at the level of the key– One tuple does not subsume another (null values subsumed by
non-null values)
• Inter-Instance Integrity– User can only see portion of relation for which is cleared (use
filters)– Data not cleared is set to null– Eliminate subsumed tuples
Examples of Polyinstantiation Integrity – JS model
Legal instance:Vessel Objective Destination TCEnterprise U Exploration U Talos U UVoyager U Exploration U Talos U UVoyager U Spying S Mars S S
Illegal instance: Why?Vessel Objective Destination TCVoyager U Exploration S Talos S SVoyager U Spying S Mars S S
JS Insert
Suppose S wants to insert (Enterprise, Spying, Rigel) into:
Vessel Objective Destination TCEnterprise U Exploration U Talos U U
After Insert
Vessel Objective Destination TCEnterprise U Exploration U Talos U UEnterprise S Spying S Rigel S S
Are these different or the same? Problem!
JS Insert
• But what does it all mean to have tuples at different classification levels?
• In the Jajodia Sandhu early model, this was not made clear
Winslett Smith Belief Model• Addressed some of these problems
– Tuples at user’s level believe info– See info at lower levels– Simplified: only 2 classification level columns
• KC and TC
R(K, KC, A1, A2, ... An, TC)• PK is K, KC and TC
– Important: Every tuple has a base tuple – level at which first inserted
Winslett Smith Belief ModelCan distinguish between different beliefs
Vessel Objective Destination TCEnterprise U Exploration Talos UEnterprise S Spying Rigel S
U believes and sees:
Enterprise U Exploration Talos U
S sees U’s tuples, but believes the following:
Enterprise S Spying Rigel S
Winslett Smith Belief Model
Can distinguish between different entities, and the same entities•Different entities (different CAK):
Vessel Objective Destination TCEnterprise U Exploration Talos UEnterprise S Spying Rigel S
•The same entities (same CAK):
Vessel Objective Destination TCEnterprise U Exploration Talos UEnterprise U Spying Rigel S
MLR Model Sandhu Chen
• Relational operations still messy in Winslett/Smith– What about joins – if at different levels?
• Try to eliminate semantic ambiguity• Borrowing to indicate belief in lower level
tuples – Does it mean T or F?– Cannot indicate disbelief
Extensions to MLS model
• Belief consistent model (Jukic-Vrbsky)– Can easily see what others believe at lower
levels– Can assert if one level believes lower level
belief is false– Reduces tuple propagation– Useful for: e-Business and Customer
Relationship Modeling (CRM).
Belief consistent model
• Labels are positive or negative, positive means believes the value is true, negative means a false belief
Vessel Objective Destination TCEnterprise US Exploration US Talos U-S U-SEnterprise US Exploration U Rigel S S
• Enterprise US means one Enterprise• -S means destination Talos is not believed by the S level• If a classification level is not listed, it means it has no
belief
S has no belief in the Exploration U
• Too many labels for each column – confusing!
MLS Model
• MLS models never really became popular
• Why??
• However, in Oracle– Oracle Label Security in 10g
• Sensitivity labels and security clearances
Role Based Access Control
RBAC
Mid 1990’s-now
Motivation
• Many organizations:– Base access control in role of individual users– Want to centrally control and maintain access
rights– Access control needs are unique
• commercially available products lack flexibility
Motivation
• Roles define individuals and extent of resource access• Combination of users and permissions can change
– E.g. user membership in roles
• Permissions associated with roles stable• Administration of roles rather than permissions• Role permission predefined
– Easier to add/remove users membership than create new roles/permissions
• Roles part of SQL3 • Supported by many software products
– Roles used in Windows NT, XP (system admin)
Roles
• Role-based access control (RBAC)• Sandhu, R., Coyne, Feinstein, Youman: “Role-Based Access Contro
l Models”
– Semantic construct – System administrator creates roles according to job
functions
• Role – Specific task competency, duty assignments– Embody authority and responsibility
• Grant permissions to roles and users– Permissions & Roles, Roles & Users
Role hierarchies
• More powerful roles at top, less powerful on bottom
• Inherits up– Inheritance transitive– Multiple inheritance– Partial order - reflexive, transitive,
antisymmetric– Can create private roles not inherited
Constraints
• Mutually exclusive roles– User at most 1 role in ME set– Combinations of roles and permissions can be
prohibited
• Cardinality– Maximum number of members in a role– Minimum cardinality difficult to implement
• Prerequisite role– User assigned to role B, only if assigned to A– Permission p assigned to role only if role has
permission q
In Oracle
• Rather than grant privileges to individual users, can grant them to groups using roles
Create role role_name [identified by pw] Grant {privilege} [on {table}] to role_name
Grant role_name to user
The user must enable the role if a pw is specified with the command: Set role role_name identified by pw
DAC, MAC vs. RBAC
• DAC vs. MAC emerged from defense security research
• RBAC independent of access control
• RBAC can be used to implement DAC, MAC
Attribute Based Access Control
ABAC
Mid 2000’s
Why ABAC? – Web sharing
• No longer have stove-piped info systems • Instead: collaboration and info sharing• Must balance accessibility with protection• Currently
– Firewall, intrusion detection (HTTP) – can have potential attacks not detectable
– Need set of known users – may not be feasible– Simple, static, coarse grained (roles) – doesn’t take
into account current threat level, community of interest
ABAC
• Attribute Based Access Control– Motivation – web based services technologies
and service oriented architectures• Dynamic and adhoc
– Based on subject, object and environment attributes
• Supports MAC and DAC needs
– Slides based on: “Attribute Based Access Control ABAC for Web Services,” E. Yuan, J. Tong, ICWS’05.
ABAC
• Access granted based on attributes of user not rights of subject associated with user
• User must prove claims about his attributes
Standards
• Industry Standards– Security Assertions Markup Language (SAML)– Authentication/authorization represented as XML assertions– XML Access Control Markup Language (XACML) defined
architecture and policy language for access control– Web Services Security (WSS) foundation for Simple Object
Access Protocol (SOAP)• Security tokens, XML digital signature, XML encryption
• Standards focused on defining wire format not service-level semantics, different parties interface with each other, need end-to-end security
Definition of ABAC
• ABAC
– Policy model – defines ABAC policies
– Architecture model – applies policies
• Attributes
– Subject – entity (user, application, process) that acts on a resource
• Attributes: subject’s ID, name, organization, job title
– Resource – entity acted upon by subject
• Title, subject, date, author, ownership (extracted from metadata)
– Environment – operational, technical, situational• Current date/time, virus/hacker activities, network security
level– Not associated with a particular subject or resource
• Evaluation of policy rules – first order logic, forward chaining
Attributes
• ATTR(s) SA1 X SA2 X … X SAk
• ATTR(r) RA1 X RA2 X … X RAk
• ATTR(s) EA1 X EA2 X … X Eak
– Subjects have a Role, User ID and can be Customer with an address and credit rating or a Manager with a store and ssn)
– Resources have Owners and have names such as Previous purchases, NewPurchase, ApprovePurchase)
• Assign attributes to s, r, e– Role(s) = “Service Consumer”– ServiceOwner(r) = “XYZ, Inc.”– CurrentDate(e) = “01-23-2005”
Rules
• Rule : can_access (s, r, e) ← f(ATTR(s), ATTR(r), ATTR(e))
• Policy rules– Rule1: can_access(s, r, e) ← (Role(s)=‘Manager’) ^
(Name(r)=‘ApprovePurchase’) // RBAC– Rule2: can_access(s, r, e) ← (UserID(s) = ResourceOwner(r))
// resource can only be accessed by owner
ABAC vs RBAC:
• Example
RBAC– 3 roles: adult, juvenile, child– 3 permissions: can view R-rated movies, PG-
13 movies, G-rated movies– Adult all 3 permissions, juvenile 2, child 1
Example
ABAC
•Age is s attribute, rating r attribute
•Eliminates definition/management of static roles
Expand example
• Suppose expand to include new, old release
Changes to RBAC Changes to ABAC
Authorization Architecture• Attribute Authorities AA
– creating, managing attributes for s, r, e
– Binding attributes to entity of interest
• Policy Enforcement Point PEP
– requesting and enforcing authorization
decisions
– Point of presence for access control, cannot be bypassed
• Policy Decision Point PDP
– Evaluating policies and making authorization decisions
– When policy references s, r, or e, contacts AA to retrieve attribute values
• Policy Authority PA
– Create/manages access control policies
Securing Web Services
Implementation
• JAX-RPC message handlers to intercept SOAP request messages
• Policy decision services implemented using Apache Axis
• Policy stored and retrieved in XACML
Advantages of ABAC
• Intuitive to model• More flexible and powerful• Management of security can be distributed over
network (AA, PA)• ABAC can be used to implement DAC, MAC,
RBAC