Transcript Lecture 23 - Goldsmiths, University of London

Data security
Data security
1
Data security
Overview
 generalities
 discretionary access control
 mandatory access control
 data encryption
2
Data security
The problem of security
 aspects
 origins of security rules
 social - legal, ethical, political, strategic, ...
 operational problems
 are the computers “safe”?
 does the operating system have a security system
(passwords, storage protection keys ...)?
 ...
 does the DBMS have a concept of data ownership?
3
Data security
disregard
4
Data security
DBMS approaches to data security
 discretionary
 users access data according to their privileges
/ authorities which are explicitly stated for
each user and data object in part
 mandatory
 each data object is given a classification level
and each user has a certain clearance level; a
given data object can be accessed only by the
users with a certain clearance level
5
Data security
The DBMS’s security mechanism
 security rules:
 made known to the system
 appropriate definitional language
 remembered by the system
 security / authorisation rules stored in the catalogue
 checked by the system
 security / authorisation subsystem
6
Data security
Discretionary access control
 example in a pseudo-code
CREATE SECURITY RULE Rule1
GRANT RETRIEVE ( S_id, S_name, City ) , DELETE
ON Suppliers WHERE City  ‘London’
TO Jim, Fred, Mary
ON ATTEMPTED VIOLATION Reject ;
7
Data security
Discretionary access control
 components of a security rule





name (Rule1) (why?)
privileges (RETRIEVE on certain attributes, ...)
scope (ON … WHERE …)
users (user IDs)
violation response (procedure)
8
Data security
General format of a rule (pseudo-code)
CREATE SECURITY RULE <name>
GRANT
<list of privileges>
ON
<expression>
TO
<list of userIDs>
[ ON ATTEMPTED VIOLATION <action> ] ;
9
Data security
Clarifications
 possible privileges are:
 RETRIEVE [ ( <attribute-list> ) ]
 INSERT
 UPDATE [ ( <attribute-list> ) ]
 DELETE
 ALL
 data definition operations
 ...
10
Data security
Clarifications
 <expression>
 is an expression of relational algebra
 target: (one range variable which should refer to) only
one relation; i.e. the scope of the rule is a subset of of
the tuples of a single relation
• this restriction is somehow ad-hoc; though, it induces in simplicity
 <action>
 default: reject
 but it could be on any complexity, in theory
• examples - what would it be needed?
11
Data security
SQL’s GRANT and REVOKE
GRANT
<list of privileges>
ON
<data object>
TO
<list of userIDs> | PUBLIC
[ WITH GRANT OPTION ]
REVOKE [ GRANT OPTION FOR] <list of privileges>
ON
<data object>
FROM
<list of userIDs> <option>
12
Data security
Clarifications
 privileges
 USAGE (for domains), SELECT, INSERT (column
specific), UPDATE (column specific), DELETE,
REFERENCES (for integrity constraint definitions)
 <data object>
 DOMAIN <domain>
 [ TABLE ] <table> (a base table or a view)
 <option>
 RESTRICT | CASCADE
13
Data security
Example #1
CREATE VIEW View1 AS
SELECT S_id, S_name, Status, City
FROM Suppliers
WHERE City = ‘Paris’
GRANT SELECT, INSERT,
UPDATE ( S_name, Status ), DELETE
ON View1
TO Mark, Spencer
14
Data security
Example #2
CREATE VIEW View2 AS
SELECT S_id, S_name, Status, City FROM S
WHERE
EXISTS
( SELECT * FROM SP
WHERE EXISTS
(SELECT * FROM P
WHERE S.S_id = SP.S_id AND
P.P_id = SP.P_id AND P.City = ‘Rome’ )) ;
GRANT SELECT ON View2 TO John
15
Data security
Example #3
CREATE VIEW View3 AS
SELECT P_id, ( SELECT SUM (Contracts.Qty)
FROM Contracts
WHERE Contracts.P_id = Parts.P_id )
AS Quantity
FROM Parts;
GRANT SELECT ON View3 TO Bill
16
Data security
Other issues
 context-independent rules
 the previous examples
 context-dependent rules
 date(), day(), time(), user(), terminal()
specified within
the rule
17
Data security
Example #4
GRANT INSERT
ON Transactions
WHERE Day() NOT IN (‘Saturday’, ‘Sunday’) AND
Time() > ’ 9:00’ AND Time() < ‘17:00’
TO Till;
--Till is a group of users
18
Data security
Other issues
 logical “OR” between security rules
 anything not explicitly allowed is implicitly
prohibited
 audit trial - for critical data
 request (text), terminal, user, date and time, data objects
affected, old values, new values
19
Data security
Mandatory access control
 each data object has a classification level
 each user has a clearance level
 rules
 user U can see object O if the clearance level of U
is greater or equal to the classification level of O
 user U can modify object O only if the clearance
level of U is equal to the classification level of O
 used for DBs with a static and rigid classification
structure
20
Data security
Data encryption - generalities
 when the system was bypassed
 plain-text
 original data
 encryption
 encryption algorithm, encryption key
 cipher-text
 encrypted text
21
Data security
An encryption algorithm
 divide text into blocks of length equal to the
encryption key
 replace each character by a corresponding integer
(blank=00, a=01, …, z=26)
 repeat for the encryption key
 for each block, sum modulo 27 the corresponding
integers with those of the encryption key
 replace each integer with the corresponding
character
22
Data security
Example
 plaintext: we all like databases
 key: ursu
 [we_a][ll-l][ike-][data][base][s---]
 23050001 12120012 09110500 04012001 02011905 19000000
 21181921
 17231922 06031906 …
--exercise
 qwsv fcsf …
 decoding algorithm?
23
Data security
Objective
 the cost of breaking the coding algorithm
should be greater than the potential payoff of
accessing (illegally) the encoded data
 usually, the encryption algorithm is made public but
the encryption key is kept secret
 the breaking of the coding (find the encryption key),
usually, is done on the bases of some available
cipher-texts and their corresponding plain-texts
24
Data security
Encryption algorithms
 data encryption standard
 not truly secure
 public-key encryption
 a modern approach
25
Data security
Data encryption standard
 64 bit key (actually only 256 possible keys)
 permutation + 16 substitution steps + permutation
 each substitution step is based on a new key that is
computed from the current value of the block and the
initial value of the key
 the decryption algorithm is almost identical to the
encryption one
26
Data security
Public-key encryption
makes public
- encryption algorithm
- encryption key
keeps
- decryption key
27
Data security
Principles for public key encryption
 the decryption key cannot feasibly be
deduced from the encryption key
 there is a fast algorithm of determining whether a
given number is prime
 e.g. for a no of 130 digits - 7 minutes
 there is no fast algorithm for finding the factors of
a given non-prime number
 e.g. for a product of two prime no of 63 digits - 4 * 1016
years
28
Data security
“Signed” public key encryption
publishes encryption algorithm E1
and encryption key
corresponding decryption algorithm
(key) D1 is kept secret
publishes encryption algorithm E2
and encryption key
corresponding decryption algorithm
(key) D2 is kept secret
E2(D1(Original))
E1(D2(Received)) =
E1(D2(E2(D1(Original)))) =
E1(D1(Original)=
Original
29
Data security
Conclusions
 decisions on security issues
 dictated by policy
 various aspects to the security problem
 database security mechanisms
 discretionary
 mandatory
 data encryption
 for cases when the security system was bypassed
30