Distributed Database Systems

Week 14

Securities Issues in DDB, Integrity Constraints

Distribution of Authorization
Global view Mechanism

The AUP
1
Goals of DB Security

• Integrity: Only authorized users should be allowed to modify

data.
• Availability: Making data available to the authorized users and
application programs.
• Secrecy (or Confidentiality): Protection of data from
unauthorized disclosure.

2
Data and Access Control

3
View Management

4
 View Management in Centralized DB/1

EMP
View – virtual relation
ENO ENAME TITLE
• generated from base relation(s) by a query
• not stored as base relations E1 J. Doe Elect. Eng
E2 M. Smith Syst. Anal.
E3 A. Lee Mech. Eng.
E4 J. Miller Programmer
Example : The view of system analysts derived from E5 B. Casey Syst. Anal.
relation EMP E6 L. Chu Elect. Eng.
E7 R. Davis Mech. Eng.
CREATE VIEW SYSAN(ENO,ENAME) E8 J. Jones Syst. Anal.
AS SELECT ENO,ENAME
SYSAN
FROM EMP
ENO ENAME
WHERE TITLE= "Syst. Anal."
E2 M.Smith
E5 B.Casey
E8 J.Jones
View Management in Centralized DB/2:
Query Modification
Queries expressed on views are translated into

Queries expressed on base relations

Example : Find the names of all the system analyst with their project
number and responsibility
SELECT ENAME, PNO, RESP
FROM SYSAN, ASG
WHERE SYSAN.ENO = ASG.ENO
is translated into ENAME PNO RESP

SELECT ENAME,PNO,RESP M.Smith P1 Analyst

FROM EMP, ASG M.Smith P2 Analyst

B.Casey P3 Manager
WHERE EMP.ENO = ASG.ENO
J.Jones P4 Manager
AND TITLE = "Syst. Anal."
View Management in Centralized DB/3

7
View Management in Centralized DB/4

8
View Management in DDBs/1

9
View Management in DDBs/2
• Views derived from distributed relations may be costly to
evaluate
• Optimizations are important, e.g., snapshots
• A snapshot is a static view
• does not reflect the updates to the base relations
• can be managed as temporary relations
• is subject to periodic recalculation
• Materialized views store the computed result of a view in a DB
relation, to improve performance.
• Updates of views are made faster by making materialized views.
Uses in On Line Analytical Processing (OLAP) applications in data
warehousing.

10
 Data Security/1
• Data protection
• Prevents the physical content of data to be understood by unauthorized users
• Uses encryption/decryption techniques (Public key) -> cryptography
• Access control
• Only authorized users perform operations they are allowed to on database
objects.
• The centralized or distributed DBMS must thus be able to restrict the access
of a subset of the database to a subset of the users.
• Discretionary access control (DAC)
• Also called authorization control; access rights (select, update). Long
been provided by DBMS with authorization rules.
• Mandatory or Multilevel access control (MAC)
• Increases security with security levels or restricting access to
classified data
 Discretionary Access Control /2
• Main actors
• Subjects (users, groups of users) who execute operations
• Operations (in queries or application programs)
• Objects, on which operations are performed
• Authorization control checks whether a given triple (subject, operation,
object) can be allowed to proceed (subject may perform an op. on an
object)
• Authorization= (subject, op. type, object def.)
• Defined using GRANT OR REVOKE
• Centralized: one single user class (admin.) may grant or revoke
• Decentralized, with op. type GRANT
• More flexible but recursive revoking process which needs the
hierarchy of grants
Problem with DAC /3

13
Problem with DAC /4

• A malicious user can access unauthorized data through an

authorized user
• Example
• User A has authorized access to R and S
• User B has authorized access to S only
• B somehow manages to modify an application program used
by A so it writes R data in S
• Then B can read unauthorized data (in S) without violating
authorization rules
• Solution: multilevel security based on the famous Bell and
Lapaduda model for OS security
 Multilevel Access Control/5

• Different security levels (clearances)

• Top Secret > Secret > Confidential > Unclassified
• Access controlled by 2 rules:
• No read up
• subject S is allowed to read an object of level L only if level(S) ≥ L
• Protect data from unauthorized disclosure, e.g. a subject with secret
clearance cannot read top secret data
• No write down:
• subject S is allowed to write an object of level L only if level(S) ≤ L
• Protect data from unauthorized change, e.g. a subject with top secret
clearance can only write top secret data but not secret data (which
could then contain top secret data)
MAC in Relational DB/6

• A relation can be classified at different levels:

• Relation: all tuples have the same clearance
• Tuple: every tuple has a clearance
• Attribute: every attribute has a clearance
• A classified relation is thus multilevel
• Appears differently (with different data) to subjects with
different clearances
 Example /7

PROJ*: classified at attribute level

PNO SL1 PNAME SL2 BUDGET SL3 LOC SL4
P1 C Instrumentation C 150000 C Montreal C
P2 C DB Develop. C 135000 S New York S
P3 S CAD/CAM S 250000 S New York S

PROJ* as seen by a subject with confidential clearance

PNO SL1 PNAME SL2 BUDGET SL3 LOC SL4
P1 C Instrumentation C 150000 C Montreal C
P2 C DB Develop. C Null C Null C
Authorization Control /1

18
Authorization Control /2

19
Authorization Control /3

20
Distributed Authorization Control /1

21
Distributed Authorization Control /2

22
Integrity Constraints /1
• A database is consistent if it satisfies a set of constraints, called
integrity constraints.
• The DDBMS must ensure that such constraints are always
satisfied.
• Two main types of constraints can be distinguished:
• Structural constraints: basic semantic properties inherent to a
data model e.g., unique key constraint in relational model
• Behavioral constraints: regulate application behavior e.g.,
dependencies (functional, inclusion) in the relational model
• An integrity control system has 2 components:
• Integrity constraint specification
• Integrity constraint enforcement

23
Integrity constraints specification/1

• 3 types of integrity constraints are distinguished:

• Predefined
• Precompiled
• General constraints
• In the following examples we use the following relations:
• EMP(ENO, ENAME, TITLE)
• PROJ(PNO, PNAME, BUDGET)
• ASG(ENO, PNO, RESP, DUR)

24
Integrity constraints specification/2

25
Integrity constraints specification/3

26
Integrity constraints specification/4

• General constraints may involve more than one relation

• Constraint with aggregate function:

• e.g., The total duration for all employees in the CAD project is less
than 100
CHECK ON g:ASG, j:PROJ
SUM(g.DUR WHERE g.PNO = j.PNO) < 100
IF j.PNAME = 'CAD/CAM' )

27
Integrity Constraints in SQL

28
Integrity Constraints Enforcement /1

29
Integrity Constraints Enforcement /2

30
Distributed Integrity Constraints

31