Download Database Security

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Corecursion wikipedia , lookup

Transcript
Security in Databases
Outline
•
•
•
•
•
review of databases
reliability & integrity
protection of sensitive data
protection against inference
multi-level security
2
Database
DB Administrator
DBMS
users
3
Database concepts
• database
– data + rules
• components of data
– records: composed of fields / elements
• logical structure  schema
• attribute  name of a column
• relation  a set of columns
4
DB should deliver (advantages)
•
•
•
•
•
shared access
minimal redundancy
data consistency
data integrity
controlled access
5
Security requirements
•
•
•
•
•
•
•
physical DB integrity
logical DB integrity
element (field) integrity
auditability
access control
user authentication
availability
– (integrity, confidentiality & availability)
6
Reliability & integrity
• three dimensions:
– database integrity
– element integrity
– element accuracy
• various techniques
–
–
–
–
–
2-phase update
introducing redundancy
recovery
concurrency/consistency control
using monitors
7
2-phase update (commit)
• phase-1: Intent
– gathering info & resources
– no harm in the case of failure
• phase-2: commit
– adding commit flag to the database
– causing permanent changes
– may repairable in the case of failure
8
2-Phase Update (Example)
• Suppose DB query asks to add 1 to fields X and
Y.
• Phase 1 (Intent):
– Compute updated values in temporary “Shadow”
variables Xnew and Ynew:
> Xnew := X + 1, Ynew := Y + 1
• Phase 2 (Commit):
– Set “Commit” flag (i.e. DB changes started, do not
repeat Intent phase!)
– Copy shadow values into DB:
> X := Xnew, Y := Ynew
– Write “Update Complete”, Clear Commit flag.
9
Redundancy
• using error detection / correction codes
– entire database
– records
– fields / elements
• shadow fields
– duplication of attributes / records
10
Recovery
• one way to achieve this is to have a log
file for all recent changes (since last
backup)
11
Concurrency/Consistency
• In a multi-user/process/client environment,
concurrency and consistency control is vitally
important.
• Basic techniques
– using “atomic operation”
> Read-then-(if OK)Write: A Write query to a field is
conditioned on its current contents being as specified
(in case it was modified recently by someone else)
– using “locking” mechanisms
> Read queries to a record are blocked while a write is
performed to the record by someone else
12
Monitors
• checking the structural consistency of data
entered or modified
– range comparison -- field specific
– state constraints
> describe of the condition of entire DB
> (Properties which should be satisfied by DB contents at
all times)
– transition constraints
> describe the conditions necessary before a change can
be made
• (Properties which should be satisfied by DB
contents so that a change to DB is valid)
Collectively called Integrity Constraints
13
On sensitive data
• factors that make data sensitive
–
–
–
–
–
inherently sensitive
from a sensitive source
declared sensitive
of a sensitive attribute or a sensitive record
sensitive in relation to previously disclosed
information
• sensitivity of data in a DB may vary !
14
Access decisions on sensitive data
• factors to be considered when permitting “user
x to access data y”
– availability of data
> Record is blocked from read while it is modified
– acceptability of access
> No disclosure (even ‘partial’) of sensitive values to
unauthorized users
– assurance of authenticity of user
> Limit access based on other considerations (time of
access, previous accesses,…)
15
Types of disclosure of sensitive data
• exact data (field = x)
• Bounds
– x < field < y
• negative result
– field is not equal to x
• Existence
– an Attribute of a field exists in DB
• probable value
– reducing the number of possible values for a field,
Improving knowledge of their relative likelihoods.
16
Inference Problem
• definition:
– infer or derive sensitive data from nonsensitive or (seemingly) un-related data
• “inference” is a subtle vulnerability in
database security
17
A sample database
NAME
SEX AID
FINES
DRUGS DORM
Adams
Bailey
Chin
Dewitt
Earhart
Fein
M
M
F
M
F
F
45.0
0.0
20.0
35.0
95.0
15.0
1
0
0
3
1
0
5000
0
3000
1000
2000
1000
Holmes
Grey
West
Grey
Holmes
West
18
Direct attack
• list NAME where
SEX = M & DRUGS = 1
• list NAME where
(SEX = M & DRUGS = 1) |
(SEX != M & SEX != F) |
(DORM != East)
19
Indirect attack (statistical inference)
• Sum
sum of financial aid by dorm & sex
Holmes Grey West Total
M
5000 1000 0
6000
F
2000
0 4000 6000
Total 7000 1000 4000 12000
20
Indirect attack (cont.)
• Count
– count of students by dorm & sex
Holmes Grey West Total
M
1
2
0
3
F
1
0
2
3
Total 2
2
2
6
– can be used in combination with “sum”
21
Indirect attack (cont.)
• Median
lowest value
for
attribute 2
highest value for
attribute 1
median for
attribute 1 &
median for
attribute 2
highest
value
for
attribute 2
lowest value for
attribute 1
22
revealing Earhart’s fine
• Earhart is the only person who has the
median of AID and DRUGS, so if data on
AID is known, the following query
reveals Earhart’s DRUGS:
p = median (DRUGS where AID=2000)
23
Indirect attack (cont.)
• Linear system attack
– by solving a set of equations
e.g.
q1 = c1 + c2 + c3
q2 =
q3 = c1 +
c2 + c3
c3
24
Controls for statistical inference
• 2 types of control
– applied to queries --- very hard !
– applied to data items --- relatively easy
> suppression --- sensitive data are not
provided
> concealing --- precise data are not provided
25
Summary of inference
• no perfect solution to inference problem
• 3 common approaches
– suppress obviously sensitive data  fairly
easy
– track what the user knows  costly
– disguise data  may result in incorrect or
wrong responses to legitimate queries
26
Multi-level security
• The 2 level security model, sensitive or nonsensitive, is inadequate in many practical
applications:
– The security of a data element may be different from
that of other elements in the same row or column.
– In practice many grades of security may be needed.
– The security of an aggregate may be different from
that of the individual elements
27
Realising Multi-level Security
• Partitioning
– each sub-database corresponds to a security level
• Encryption
– each record (or field) can be encrypted using a
different key
•
•
•
•
Integrity
Trusted Front End
Commutative Filter
Window/View
28