Chapter 6 - Database Security
Download
Report
Transcript Chapter 6 - Database Security
Chapter 6 – Database Security
Integrity for databases: record
integrity, data correctness, update
integrity
Security for databases: access
control, inference, and aggregation
Multilevel secure databases:
partitioned, cryptographically sealed,
filtered
Introduction to Databases
Database – collection of data and set
of rules that organize the data by
specifying certain relationships
among the data
Database administrator (DBA)
Database management system
(DBMS) – database manager, frontend
Introduction to Databases
Records – contain related group of
data
Fields (elements) – elementary data
items
Schema – logical structure of
database
Subschema – view into database
Introduction to Databases
Relational
• Rows (relation); columns (attributes)
• DB2, Oracle, Access
Hierarchical
• IMS
Object-oriented
Introduction to Databases
Queries
• SELECT NAME = ‘ADAMS’
• SELECT (ZIP = ‘43210’) ^ (NAME = ‘ADAMS’)
Project
• SHOW FIRST WHERE (ZIP = ‘43210’) ^ (NAME
= ‘ADAMS’)
Join
• SHOW NAME, AIRPORT WHERE
NAME.ZIP = AIRPORT.ZIP
Advantages of Using Databases
Shared access
Minimal redundancy
Data consistency
Data integrity
Controlled access
Security Requirements
Physical database integrity
Logical database integrity
Element integrity
Auditability
Access control
User authentication
Availability
Integrity of the Database
Users must be able to trust the
accuracy of the data values
Updates are performed by authorized
individuals
Integrity is the responsibility of the
DBMS, the OS, and the computing
system manager
Must be able to reconstruct the
database at the point of a failure
Element Integrity
Correctness or accuracy of elements
Field checks
Access control
Maintain a change log – list every
change made to the database
Auditability & Access Control
Desirable to generate an audit record
of all access to the database
(reads/writes)
Pass-through problem – accessing
a record or element without
transferring the data received to the
user (no reads/writes)
Databases separated logically by
user access privileges
Other Security Requirements
User Authentication
Confidentiality
Availability
Reliability and Integrity
Database integrity
Element integrity
Element accuracy
Some protection from OS
• File access
• Data integrity checks
Two-Phase Update
Failure of computing system in
middle of modifying data
Intent Phase – gather resources
needed for update; write commit
flag to the database
Update Phase – make permanent
changes
Redundancy / Internal Consistency
Error detection / Correction codes
(parity bits, Hamming codes, CRCs)
Shadow fields
Log of user accesses and changes
Concurrency/Consistency
Access by two users sharing the same
database must be constrained (lock)
Monitors –check entered values to ensure
consistency with rest of DB
Range Comparisons
State Constraints – describes condition of
database (unique employee #)
Transition Constraints – conditions before
changes are applied to DB
Sensitive Data
Data that should not be made public
What if some but not all of the
elements of a DB are sensitive
• Inherently sensitive
• From a sensitive source
• Declared sensitive
• Part of a sensitive attribute or record
• Sensitive in relation to previously
disclosed information
Access Decisions
Need an access policy (programmed
into DBMS)
Availability – blocking; permanent
blocking
Acceptability of Access (sensitive
data)
Assurance of Authenticity
Types of Disclosures
Exact Data
Bounds
Negative Results
Existence of Data
Probable Values
Security vs. Precision
Aim to protect all sensitive data
while revealing as much nonsensitive
data as possible
Want to maintain perfect
confidentiality with maximum
precision
Inference
Way to infer / derive sensitive data
from nonsensitive data
Direct Attack
• List NAME where SEX=M ^ DRUGS=1
• List NAME where (SEX=M ^ DRUGS=1)
v (SEX#M ^ SEX#F) v (DORM=AYRES)
Indirect Attack
Sum
• Show STUDENT-AID WHERE SEX=F ^
DORM=Grey
Count
• Show Count, STUDENT-AID WHERE SEX=M ^
DORM=Holmes
• List NAME where (SEX=M ^ DORM=Holmes)
Median
Tracker Attacks – using additional queries
that produce small results
Controls
Suppression – don’t provide
sensitive data
Concealing – don’t provide actual
values (“close to”)
Limited Response Suppression
• n-item k-percent rule eliminates low
frequency elements from being
displayed (may need to suppress
additional rows/columns)
Controls
Combined Results
• Sums
• Ranges
• Rounding
Random Sample
Random Data Perturbation
Query Analysis – “should the result
be provided”
Conclusion on the Inference
Problem
Suppress obviously sensitive
information
Track what the user knows
Disguise the data
Aggregation
Building sensitive results from less
sensitive inputs
Data mining – process of sifting
through multiple databases and
correlating multiple data elements to
find useful information
Multilevel Databases
Differentiated Security
• Security of single element may be
different from security of other elements
• Two levels – sensitive and nonsensitive
are inadequate to represent some
security situations
• Security of an aggregate (sum, count,…)
may be different from security of the
individual elements
Granularity
Security Issues
Integrity
• *-property for access control
• Either process cleared at a high level cannot
write to a lower level or process must be a
“trusted process”
Confidentiality
• Different users at different levels may get
different query results
• Polyinstantiation – record can appear more
than once with different levels of
confidentiality
Proposals for Multilevel Security
Separation
• Partitioning – divide DB into separate
DBs with own level of sensitivity
• Encryption (time consuming)
• Integrity Lock – each data item contains
a sensitivity label and a checksum
Sensitivity label must be unforgeable,
unique, concealed
Checksum must be unique
Sensitivity lock
Design of Multilevel Secure
Databases
Integrity Lock – not efficient
(space/time)
Trusted Front-end (Guard) – does
authentication and filtering
Commutative Filters –
• screen user’s requests, reformats, so
that only appropriate data is returned
Design of Multilevel Secure
Databases
Distributed (federated) database
• Trusted front-end controls access to two
DBMSs – one for high-sensitivity data
and one for low-sensitivity data
• Very complex
Window/View
• Subset of a database containing exactly
the information that the user is entitled
to access