Scribd
Upload
96 views21 pages

Chapter 6

The document discusses database security requirements including physical and logical integrity, element integrity, auditability, access control, authentication, and availability. It then covers the SQL security model which implements discretionary access control based on users, actions, and objects. Finally, it examines using views and application programming to implement row-level security through discretionary access controls in a case study on a medical records database.

Uploaded by

elshaday desalegn
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
96 views21 pages

Chapter 6

The document discusses database security requirements including physical and logical integrity, element integrity, auditability, access control, authentication, and availability. It then covers the SQL security model which implements discretionary access control based on users, actions, and objects. Finally, it examines using views and application programming to implement row-level security through discretionary access controls in a case study on a medical records database.

Uploaded by

elshaday desalegn
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 21

Module 6: Database Security

Security Requirements
• Physical database integrity
• Logical database integrity
• Element integrity
• Auditability
• Access control
• User authentication
• Availability
Security Requirements…
• Physical database integrity
– immunity to physical catastrophe, such as power
failures, media failure
• physical securing hardware, UPS
• regular backups

• Logical database integrity


– reconstruction Ability
• maintain a log of transactions
• replay log to restore the systems to a stable point
Security Requirements…
• Element integrity
– integrity of specific database elements is their correctness or accuracy
• field checks
– allow only acceptable values
• access controls
– allow only authorized users to update elements
• change log
– used to undo changes made in error
• referential Integrity (key integrity concerns)
• two phase locking process

• Auditability
– log read/write to database
Security Requirements…
• Access Control (similar to OS)
– logical separation by user access privileges
– more complicated than OS due to complexity of DB
(granularity/inference/aggregation)
• User Authentication
– may be separate from OS
– can be rigorous
• Availability
– concurrent users
• granularity of locking
– reliability
SQL Security Model
• SQL security model implements DAC based on
– users: users of database - user identity checked during login process;
– actions: including SELECT, UPDATE, DELETE and INSERT;
– objects: tables (base relations), views, and columns (attributes) of
tables and views
• Users can protect objects they own
– when object created, a user is designated as ‘owner’ of object
– owner may grant access to others
– users other than owner have to be granted privileges to access object
SQL Security Model…
• Components of privilege are
– grantor, grantee, object, action, grantable
– privileges managed using GRANT and REVOKE operations
– the right to grant privileges can be granted
• Issues with privilege management
– each grant of privileges is to an individual or to “Public”
– makes security administration in large organizations difficult
– individual with multiple roles may have too many privileges for one of
the roles
– SQL3 is moving more to role based privileges
SQL Security Model…
• Authentication & identification mechanisms
– CONNECT <user> USING<password>
– DBMS may chose OS authentication
– or its own authentication mechanism
• Kerberose
• PAM
SQL Security Model
• Access control through views
– many security policies better expressed by granting privileges to views
derived from base relations

– example
CREATE VIEW AVSAL(DEPT, AVG)
AS SELECT DEPT, AVG(SALARY)
FROM EMP GROUP BY DEPT
• access can be granted to this view for every dept mgr

– example
CREATE VIEW MYACCOUNT AS
SELECT * FROM Account
WHERE Customer = current_user()
• view containing account info for current user
SQL Security Model
• Advantages of views
– views are flexible, and allow access control to be
defined at a description level appropriate to
application
– views can enforce context and data-dependent
policies
– data can easily be reclassified
SQL Security Model
• Disadvantages of views
– access checking may become complex
– views need to be checked for correctness (do they
properly capture policy?)
– completeness and consistency not achieved
automatically - views may overlap or miss parts of
database
– security-relevant part of DBMS may become very
large
SQL Security Model
• Inherent weakness of DAC
– DAC allows subject to be written to any other
object which can be written by that subject
– trojan horses to copy information from one object
to another
SQL Security Model
• Mandatory access controls (MAC)
– no read up, no write down
– traditional MAC implementations in RDBMS have
focused solely on MLS
– there have been three commercial MLS RDBMS
offerings
• trusted Oracle ,Informix OnLine/Secure, Sybase Secure
SQL Server
SQL Security Model
• Enforce MAC using security labels
– assign security levels to all data
• label associated with a row
– assign a security clearance to each users
• label associated with the user
– DBMS enforces MAC
• access to a row based upon
– the label associated with that row and the label associated
with the user accessing that row.
RECORDID CLIENTNO DEPTNO
Case Study
ALLOCATION_DATE LAST_UPDATE MEDICAL_HISTORY RISK_FACTOR

0010 K108341 K01 2006/01/05 2006/02/05 Diabetes 0

0020 K104546 K01 2006/10/20 2006/11/05 Arthritis 2

0030 S245987 S02 2006/09/01 2006/10/05 High Blood 3


Pressure

0040 S245456 S02 2006/06/26 2006/07/05 Asthma 1

– Medical record analyst


• READ all records
• WRITE all records
– Managers
• READ client records of their department
• READ only non-confidential columns
• No WRITE access
Case Study

• Columns
– medical record analysts have READ/WRITE access to confidential
columns
– managers have READ access to non-confidential columns
• Rows:
– medical record analysts can read and update all the records
– managers can read but not update client records for their department
Case Study: DAC Solution

Three approaches used to provide row level security


using DAC (Discretionary Access Control)
• application views
• programming logic embedded in the application
• physical separation using one or more databases
Case Study: DAC Solution

• Application views
– Widely used approach
– Views provide the ability to
filter data.
Case Study: DAC Solution
Create view manager_K01 as
select recordid, clientno,
deptno, allocation_date,
last_update,risk_factor
from Med_records
where Dept = ‘K01’;

Create view manager_S01 as


select recordid, clientno, deptno,
allocation_date, last_update, risk_factor
from Med_records
where Dept = ‘S01’;

Create view med_rec_analyst as


select * from Med_records;
Case Study: DAC Solution
• Application views
– number of views required is sometimes large as
application ages
– directing application users to the correct view
becomes management burden
– application complexity tends to increase due to
unforeseen security requirements
Presentation Topics
• MAC and DAC, MAC Vs DAC
• DAC & RBAC use in MS-SQL DBMS
• DAC & RBAC use in Oracle DBMS
• Statistical Database Security

You might also like