security stud

8/3/2019 Security Stud

1/54

Security

Security - protection from malicious attempts tosteal or modify data. Database system level

Authentication and authorization mechanisms to allowspecific users access only to required data

We concentrate on authorization in the rest of this chapter Operating system level

Operating system super-users can do anything they want tothe database! Good operating system level security isrequired.

Network level: must use encryption to prevent Eavesdropping (unauthorized reading of messages)

Masquerading (pretending to be an authorized user orsending messages supposedly from authorized users)


2/54

Security (Cont.)

Physical level

Physical access to computers allows destruction of data by

intruders; traditional lock-and-key security is needed

Computers must also be protected from floods, fire, etc. More in Chapter 17 (Recovery)

Human level

Users must be screened to ensure that an authorized users

do not give access to intruders

Users should be trained on password selection and secrecy


3/54

Authorization and Views Users can be given authorization on views, without

being given any authorization on the relations used

in the view definition

Ability of views to hide data serves both

a. to simplify usage of the system

b. to enhance security by allowing users access only to data they need

for their job

A combination or relational-level security and

view-level security can be used to limit a usersaccess to precisely the data that user needs.


4/54

AuthorizationForms of authorization on parts of the database: Read - allows reading, but not modification of data.

Insert - allows insertion of new data, but not modification ofexisting data.

Update - allows modification, but not deletion of data.

Delete - allows deletion of data.

Forms of authorization to modify the database schema

Index - allows creation and deletion of indices.

Resources- allows creation of new relations.

Alteration- allows addition or deletion of attributes in a relation. Drop- allows deletion of relations.


5/54

Authorization Specification in SQL

The gran

t statement is used to confer authorizationgrant

on to

is: a user-id

public, which allows all valid users the privilege granted A role

Granting a privilege on a view does not imply grantingany privileges on the underlying relations.

The grantor of the privilege must already hold theprivilege on the specified item (or be the databaseadministrator).


6/54

6

Roles

Roles permit common privileges for a class of users can bespecified just once by creating a corresponding role

Privileges can be granted to or revoked from roles

Roles can be assigned to users, and even to other roles

SQL:1999 supports rolescreate role tellercreate role manager

grant select onbranch to tellergrant update (balance) onaccounttotellergrant all privilegesonaccounttomanager

grant tellertomanager

grant tellertoalice, bobgrant manager to avi


7/54

Privileges in SQL

select: allows read access to relation,or theability to query using the view Example: grant users U1, U2, and U3 select

authorization on the branch relation:

grant select onbranch toU1, U2, U3 insert: the ability to insert tuples update: the ability to update using the SQL

update statement

delete: the ability to delete tuples.

all privileges: used as a short form for all theallowable privileges


8/54

Revoking Authorization in SQL

The revoke statement is used to revokeauthorization.revoke

on from

Example:

revoke select onbranch fromU1, U2, U3 All privileges that depend on the privilege being

revoked are also revoked.

may be all to revoke all privileges

the revokee may hold. If the same privilege was granted twice to the

same user by different grantees, the user mayretain the privilege after the revocation.


9/54

Limitations of SQL Authorization SQL does not support authorization at a tuple level

E.g. we cannot restrict students to see only (the tuples storing) their own grades

With the growth in Web access to databases, database accesses comeprimarily from application servers.

End users don't have database user ids, they are all mapped to the same databaseuser id

All end-users of an application (such as a web application) may be mapped to

a single database user The task of authorization in above cases falls on the application program, with

no support from SQL

Benefit: fine grained authorizations, such as to individual tuples, can beimplemented by the application.

Drawback: Authorization must be done in application code, and may be dispersedall over an application

Checking for absence of authorization loopholes becomes very difficult since itrequires reading large amounts of application code


10/54

Audit Trails An audit trail is a log of all changes

(inserts/deletes/updates) to the database along withinformation such as which user performed thechange, and when the change was performed.

Used to track erroneous/fraudulent updates. Can be implemented using triggers, but many

database systems provide direct support.


11/54

Encryption

Data may be encryptedwhen databaseauthorization provisions do not offer sufficientprotection.

Properties of good encryption technique: Relatively simple for authorized users to encrypt and

decrypt data.

Encryption scheme depends not on the secrecy of thealgorithm but on the secrecy of a parameter of the

algorithm called the encryption key. Extremely difficult for an intruder to determine the

encryption key.


12/54

Encryption (Cont.) Data Encryption Standard(DES) substitutes characters and rearranges

their order on the basis of an encryption key which is provided toauthorized users via a secure mechanism. Scheme is no more securethan the key transmission mechanism since the key has to be shared.

Advanced Encryption Standard (AES) is a new standard replacing DES,and is based on the Rijndael algorithm, but is also dependent on shared

secret keys Public-key encryption is based on each user having two keys:

public key publicly published key used to encrypt data, but cannotbe used to decrypt data

private key-- key known only to individual user, and used todecrypt data.

Need not be transmitted to the site doing encryption.Encryption scheme is such that it is impossible or extremely hard todecrypt data given only the public key.

The RSA public-key encryption scheme is based on the hardness offactoring a very large number (100's of digits) into its primecomponents.


13/54

Authentication Password based authentication is widely used, but is susceptible

to sniffing on a network Challenge-response systems avoid transmission ofpasswords

DB sends a (randomly generated) challenge string to user

User encrypts string and returns result.

DB verifies identity by decrypting result

Can use public-key encryption system by DB sending a messageencrypted using users public key, and user decrypting and sendingthe message back

Digital signatures are used to verify authenticity of data E.g. use private key (in reverse) to encrypt data, and anyone can

verify authenticity by using public key (in reverse) to decrypt data.Only holder ofprivate key could have created the encrypted data.

Digital signatures also help ensure nonrepudiation: sendercannot later claim to have not created the data


14/54

Digital Certificates Digital certificatesare used to verify authenticity ofpublic keys.

Problem: when you communicate with a web site, how do youknow if you are talking with the genuine web site or an imposter? Solution: use the public key of the web site Problem: how to verify if the public key itself is genuine?

Solution: Every client (e.g. browser) has public keys of a few root-level

certification

autho

rities

A site can get its name/URL and public key signed by a certificationauthority: signed document is called a certificate

Client can use public key of certification authority to verify certificate Multiple levels of certification authorities can exist. Each certification

authority presents its own public-key certificate signed by a

higher level authority, and Uses its private key to sign the certificate of other web sites/authorities


15/54


16/54

Closure of a Set of Functional

Dependencies Given a set Fset of functional dependencies, there are certain

other functional dependencies that are logically implied by F. E.g. If A p B and B p C, then we can infer that A p C

The set of all functional dependencies logically implied by F is theclosure ofF.

We denote the closure ofFby F+.

We can find all of F+ by applying Armstrongs Axioms: ifF E, then E p F (reflexivity)

ifE p F, then K E p K F (augmentation)

ifE p F, andF p K, then E p K (transitivity)

These rules are

sound (generate only functional dependencies that actually hold)and

complete (generate all functional dependencies that hold).


17/54

Additional rules

IfE p F and E p K, then E p F K (union)

IfE p F K, then E p F and E p K (decomposition)

IfE p F and K F p H, then E K p H(pseudotransitivity)

The above rules can be inferred from Armstrongs

axioms.


18/54

Example R = (A, B, C, G, H, I)

F= {A p BA p CCG p HCG p I

B p H}

some members ofF+A p H

by transitivity fromA p B and B p H

AG p I by augmentingA p Cwith G, to getAG p CG

and then transitivity with CG p I CG p HI

from CG p H and CG p I : union rule can be inferredfrom

definition of functional dependencies, or Augmentation ofCG p I to infer CG p CGI, augmentation of

CG p H to infer CGI p HI, and then transitivity


19/54


20/54

CONSTRAINTS


21/54

Integrity Constraints


22/54

ReviewThree things managed by a DBMS1. Data organization

E/R Model Relational Model

2. Data Retrieval Relational Algebra Relational Calculus SQL

3. Data Integrity and Database Design Integrity Constraints

Functional Dependencies Normalization


23/54


Purpose: prevent semantic inconsistencies in data

cname svngs check total

John 100 200 250e.g.:

cname bname

Jones Kenmore

Turner Main St

Smith Union

4 kinds ofICs:

1. Key Constraints2. Attribute Constraints

3. Referential Integrity Constraints

4. Global Constraints

bname bcity

Main St BostonUnion NY

Union NY

e.g.:

No entry for Kenmore...

???


24/54

ICsWhat are they? predicates on the database must always be true (:, checked whenever db

gets updated)

There are the following 4 types ofICs:Key constraints (1 table)e.g., 2 accts cant share the same acct_no

Attribute constraints (1 table)e.g., accts must have nonnegative balance

Referential Integrity constraints ( 2 tables)E.g. bnames associated w/ loans must be names of

real branches


25/54

Key Constraints

SQL examples:

1. Primary Key:

CREATE TABLE branch(

bname CHAR(15) PRIMARY KEY,

bcity CHAR(20),

assets INT);

orCREATE TABLE depositor(

cname CHAR(15),

acct_no CHAR(5),

PRIMARY KEY(cname, acct_no));

2. Candidate Keys:

CREATE TABLE customer (ssn CHAR(9) PRIMARY KEY,

cname CHAR(15),

address CHAR(30),

city CHAR(10),

UNIQUE (cname, address, city);


26/54

Key ConstraintsEffect of SQL Key declarations

PRIMARY (A1, A2, .., An) orUNIQUE (A1, A2, ..., An)

Insertions: check if any tuple has same values for A1, A2, .., An as any

inserted tuple. If found, reject insertion

Updates to any of A1, A2, ..., An: treat as insertion of entire tuple

Primary vs Unique (candidate)

1. 1 primary key per table, several unique keys allowed.

2. Only primary key can be referenced by foreign key (ref integrity)

3. DBMS may treat primary key differently

(e.g.: implicitly create an index on PK)4. NULL values permitted in UNIQUE keys but not in PRIMARY KEY


27/54

Attribute ConstraintsIdea:

Attach constraints to values of attributes

Enhances types system (e.g.: >= 0 rather than integer)In SQL:

1. NOT NULL

e.g.: CREATE TABLE branch(

bname CHAR(15) NOT NULL,

....)

Note: declaring bname as primary key also prevents null values

2. CHECK

e.g.: CREATE TABLE depositor(

....balance int NOT NULL,

CHECK( balance >= 0),

....

)

affect insertions, update in affected columns


28/54

Referential Integrity ConstraintsIdea: prevent dangling tuples (e.g.: a loan with a bname of Kenmore

when no Kenmore tuple is not in branch table)

Referencing

Relation

(e.g. loan)

Referenced

Relation

(e.g. branch)

foreign key

bname primary key

bname

RefIntegrity:ensure that:

foreign key value primary key value

(note: need not to ensure , i.e., not all branches have to have loans)


29/54

Referential Integrity Constraints

Referencing

Relation

(e.g. loan)

Referenced

Relation(e.g. branch)

bname bnamex

x x

In SQL:

CREATE TABLE branch(bname CHAR(15) PRIMARY KEY

....)

CREATE TABLE loan (

.........

FOREIGN KEY bname REFERENCES branch);

Affects:

1) Insertions, updates of referencing relation

2) Deletions, updates of referenced relation

parent

child


30/54

Referential Integrity Constraintsc c

x

x x

A B

what happens when

we try to delete

this tuple?

ti

tj

Ans: Oracle allows the following possibilities

No action

RESTRICT: reject deletion/ update

SET TO NULL: set ti [c], tj[c] = NULL

SET TO DEFAULT: set ti [c], tj[c] = default_val

CASCADE: propagate deletion/update

DELETE: delete ti, tj

UPDATE: set ti[c], tj[c] to updated values

parent

child


31/54

Referential Integrity Constraintsc c

x

x x

Emp Dept

what happens when

we try to delete

this tuple?

ti

tj

ALTER TABLED

ept ADD

Primary Key (deptno);

ALTER TABLE Emp ADD FOREIGN KEY (Deptno)

REFERENCES Dept(Deptno) [ACTION];

Action: 1) ON DELETE NO ACTION left blank (deletion/update rejected)

2) ON DELETE SET NULL/ ON UPDATE SET NULL

sets ti[c] = NULL, tj[c] = NULL

3) ON DELETE CASCADE

deletes ti, tj

ON UPDATE CASCADE

sets ti[c], tj[c] to new key values


32/54

Global ConstraintsIdea: two kinds

1) single relation (constraints spans multiple columns)E.g.: CHECK (total = svngs + check) declared in theCREATE TABLE

Example: All Bkln branches must have assets > 5M

CREATE TABLE branch (

..........

bcity CHAR(15),

assets INT,

CHECK (NOT(bcity = Bkln) OR assets > 5M))

Affects:insertions into branch

updates of bcity or assets in branch

2) Multiple Relations: NOT supported in Oracle

Need to be implemented as a Trigger


33/54

Global Constraints

Issues:

1) How does one decide what global constraint

to impose?2) How does one minimize the cost of checking

the global constraints?

Ans: Functional dependencies.

but before we go there


34/54

Summary: Integrity ConstraintsConstraint Type Where declared Affects... In Oracle ?

Key Constraints CREATE TABLE

(PRIMARY KEY, UNIQUE)

Insertions, Updates Yes

Attribute Constraints CREATE TABLE

CREATE DOMAIN

(Not NULL, CHECK)

Insertions, Updates Yes

CREATE DOMAIN notsupported in Oracle

Referential Integrity Table Tag

(FOREIGN KEY ....

REFERENCES ....)

1.Insertions intoreferencing reln

2. Updates ofreferencing reln ofrelevant attrs

3. Deletions fromreferenced reln

4. Update of referencedreln

Yes

Possible Actions:

-- Update/delete no aciton

-- delete CASCADE

-- delete SET NULL, SETDEFAULT,

Global Consraints Table Tag (CHECK)

or

outside table

(CREATE ASSERTION)

1. For single relnconstraint, withinsertion, deletion ofrelevant attrs

2. For assesrtions w/every db modification

Assertions, domains notsupported in Oracle.


35/54

Functional Dependencies

A B C D

a E 1 U

a E 1 V

a F 5 W

b F 3 W

b F 3 W

A B C

AB determines C

two tuples with the same values for A and B

will also have the same value for C

Constraints that will hold on all legal instances of the database for the

specific business application.

In most cases, specified by a database designer/business architect


36/54

Functional Dependencies

A B C D

a E 1 U

a E 1 U

a F 5 W

b F 3 W

b F 3 W

Shorthand:

C BD same as C B

C D

Be careful!AB C not the same as AC

BC

Not true


37/54

Functional DependenciesExample:

suppose R = { A, B, C, D, E, H} and we determine that:

F = { A

BC,B CE,

A E,

AC H,

D B}

Then we determine the canonical cover of F:Fc = { A BH,

B CE,

D B}

ensuring that F and Fc are equivalent

Note: F requires 5 assertionsFc requires 3 assertions

Canonical cover (or minimal cover) algorithm: In the book

(not covered here).


38/54

Functional DependenciesEquivalence of FD sets:

FD sets F and G are equivalent if the imply the same set of FDse.g. A B and B C : implies A C

equivalence usually expressed in terms of closures

Closures:

For any FD set, F, F+ is the set of all FDs implied by F.

can calculate in 2 ways:

(1) Attribute Closure

(2) Armstrongs axioms

Both techniques tedious-- will do only for toy examples

F equivalent to G iff F+ = G+


39/54

Armstrongs AxiomsA. Fundamental Rules (W, X, Y, Z: sets of attributes)

1. Reflexivity

If Y X then X Y

2. Augmentation

If X Y then WX WY

3. Transitivity

If X Y and Y Z then XZB. Additional rules (can be proved from A)

4. UNION: If X Y and X Z then X YZ

5. Decomposition: If X YZ then X Y, X Z

6. Pseudotransitivity: If X Y and WY Z then WX Z

Proving 4.(sketch): X Y => XXXY =>XXY

XYYZ=> X YZ

For every step we used the rules from A.

a2 3

osures s ng rms rong s


40/54

osures s ng rms rong s

AxiomsGiven;

F = { A BC, (1)

B CE, (2)A E, (3)

AC H, (4)

D B} (5)

Exhaustively apply Armstrongs axioms to generate F+

F+ = F 1. { A B, A C}: decomposition on (1)

2. { A CE}: transitivity to 1.1 and (2)

3. { B C, B E}: decomp to (2)

4. { A C, A E} decomp to 2

5. { A H}pseudotransitivity to 1.2 and (4)


41/54

Attribute ClosuresGiven;

R = { A, B, C, D, E, H,I} and:

F = { A

BC,C D,

CE,

AH I}

What is the closure of A (A+) ?

Algorithm att-closure (X: set of Attributes)

Result X

repeat until stable

for each FD in F, Y Z, do

if Y Result then

Result Result Z

Attribute closure A

Iteration Result-----------------------------------

0 A

1 A B C

2 A B C D

3 A B C D E

Better to determine if a set of attributes is a key


42/54

Functional dependenciesOur goal:

given a set of FD set, F, find an alternative FD set, G that is:smaller

equivalent

Bad news:

Testing F=G (F+ = G+) is computationally expensive

Good news:

Canonical Cover algorithm:

given a set of FD, F, finds minimal FD set equivalent to F

Minimal: cant find another equivalent FD set w/ fewer FDs


43/54

FD so far...1. Canonical Cover algorithm result (Fc) guaranteed to be the minimal FD set equivalent to F

2. Closure Algorithms

a. Armstrongs Axioms:

more common use: test for extraneous attributes

in C.C. algorithm

b. Attribute closure:more common use: test for superkeys

3. Purposes

a. minimize the cost of global integrity constraints

so far: min gics = |Fc|

In fact.... Min gics = 0

(FDs for normalization)


44/54

Another use of FDs: Schema DesignExample: bname bcity assets cname lno amtDowntown Bkln 9M Jones L-17 1000

Downtown Bkln 9M Johnson L-23 2000

Mianus Horse 1.7M Jones L-93 500

Downtown Bkln 9M Hayes L-17 1000

R =

R: Universal relationtuple meaning: Jones has a loan (L-17) for $1000 taken out at the Downtown

branch in Bkln which has assets of $9M

Design:

+ : fast queries (no need for joins!)

- : redudancy:

update anomalies examples?

deletion anomalies


45/54

Domain Constraints

Dom

ain

cons

train

ts

are the most elementary formof integrity constraint. They test values inserted inthe database, and test queries to ensure that thecomparisons make sense.

New domains can be created from existing data

types Example: create domain Dollars numeric(12, 2)

create domain Pounds numeric(12,2)

We cannot assign or compare a value of type Dollars

to a value of type Pounds. However, we can convert type as below

(cast r.A as Pounds)(Should also multiply by the dollar-to-poundconversion-rate)


46/54


Integrity constraints guard againstaccidental damage to the database,by ensuring that authorized changesto the database do not result in a

loss of data consistency. A checking account must have a

balance greater than $10,000.00

A salary of a bank employee must be at

least $4.00 an hour A customer must have a (non-null)

phone number

l l


47/54

Constraints on a Single Relation

not null

primary key

unique

check(P), where P is a predicate

ll


48/54

Not Null Constraint

Declare branch_name for branch is not nullbranch_name char(15) not null

Declare the domainD

ollars to be not null

create domain Dollars numeric(12,2) not null

h i C i


49/54

The Unique Constraint

unique (A1,A2, ,Am)

The unique specification states that the

attributes

A1,A2, Amform a candidate key.

Candidate keys are permitted to be null (in

contrast to primary keys).

Th h k l


50/54

The check clause

check(P), where P is a predicateExample: Declare branch_name as the primary key for branchand ensure that the values ofassets are non-negative.

create table branch

(branch_name char(15),

branch_city char(30),

assets integer,

primary key (branch_name),

check (assets >= 0))


51/54

The check clause (Cont.)

The check clause in SQL-92 permits domains tobe restricted:

Use check clause to ensure that an hourly_wage

domain allows only values greater than a specified

value.create domain hourly_wage numeric(5,2)

constraint value_testcheck(value > = 4.00)

The domain has a constraint that ensures that the

hourly_wage is greater than 4.00 The clause constraint value_testis optional; useful to

indicate which constraint an update violated.


52/54

Referential Integrity Ensures that a value that appears in one relation for a

given set of attributes also appears for a certain set ofattributes in another relation. Example: If Perryridge is a branch name appearing in one

of the tuples in the accountrelation, then there exists a tuplein the branch relation for branch Perryridge.

Primary and candidate keys and foreign keys can bespecified as part of the SQL create table statement: The primary key clause lists attributes that comprise the

primary key.

The unique key clause lists attributes that comprise acandidate key.

The foreign key clause lists the attributes that comprise theforeign key and the name of the relation referenced by theforeign key. By default, a foreign key references the primarykey attributes of the referenced table.

f


53/54

Referential Integrity in SQL Example

create table customer(customer_name char(20),customer_street char(30),customer_city char(30),primary key (customer_name ))

create table branch(branch_name char(15),branch_city char(30),assets numeric(12,2),

prim

arykey (branch_name ))


54/54

Referential Integrity in SQL Example (Cont.)

create table account

(account_number char(10),branch_name char(15),balance integer,primary key (account_number),foreignkey (branch_name) referencesbranch )

create table depositor

(customer_name char(20),account_number char(10),primary key (customer_name, account_number),foreignkey (account_number) referencesaccount,foreignkey (customer_name ) referencescustomer)

security stud

Documents