Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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