Database security and recovery

In order to maintain the consistency of the data in the database, database security is needed.. • Due to the advancement of internet, data are accessed through World Wide Web, to protect

Chapter 07: Database Security and

Recovery

Database Security

• Database security issues are often lumped together with data integrity issues, but the two concepts are really quite distinct Security refers to the

protection of data against unauthorized disclosure, alteration, or destruction; integrity refers to the

accuracy or validity of that data

• To put it a little glibly:

– Security means protecting the data against unauthorized users.

– Integrity means protecting the data against authorized users.

Need for Database Securit

• In the case of shared data, multiple users try to

access the data at the same time In order to

maintain the consistency of the data in the

database, database security is needed

• Due to the advancement of internet, data are

accessed through World Wide Web, to protect the data against hackers, database security is needed

• The plastic money (Credit card) is more popular The money transaction has to be safe More

specialized software both to enter the system

illegally to extract data and to analyze the

information obtained is available

General Considerations

• There are numerous aspects to the security

problem, some of them are:

– Legal, social, and ethical aspects

– Physical controls

– Policy questions

– Operational problems

– Hardware control

– Operating system support

– Issues that are the specific concern of the

Database Security System

Database Security Goals and Threats

• Security threat can be broadly classified into

accidental, intentional according to the way they occur

• The accidental threats include human errors, errors

in software, and natural or accidental disasters:

– Human errors include giving incorrect input, incorrect use of applications.

– Errors in software include incorrect application of

security policies, denial of access to authorized users – Natural or accidental disasters include the damage of

Classification of Database Security

• Physical security

– Physical security refers to the security of the hardware associated with the system and the protection of the site where the computer

resides Natural events such as fire, floods, and earthquakes can be considered as some of the physical threats

• Logical security

– Logical security refers to the security measures residing in the operating system or the DBMS designed to handle threats to the data

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

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 ;

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)

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> ] ;

• <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?

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>

• privileges

• USAGE (for domains), SELECT, INSERT (column specific), UPDATE (column specific), DELETE, REFERENCES (for integrity constraint definitions)

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

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

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

Example #3

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

Example #4

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

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

Data encryption - generalities

• when the system was bypassed

• 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

Database Recovery

• Concept: Logical unit of work and logical unit of recovery

• Definition: The execution of a program

that accesses or changes the contents of the database.

Example Transaction

Transaction Support

• Can have one of two outcomes:

– Success - transaction commits and database reaches

a new consistent state

– Failure - transaction aborts, and database must be

restored to consistent state before it started

– Such a transaction is rolled back or undone

• Committed transaction cannot be aborted.

• Aborted transaction that is rolled back can be restarted later.

• Transforms database from one consistent

state to another, although consistency may be violated during transaction

• Application program is series of

transactions with non-database processing in between

Isolation - Actions are not visible to other

transactions until it is committed Data used during execution of transaction

cannot be used by second transaction

until first one is completed, i.e

transaction’s updates concealed until

after commit

Durability (permanency)- Indicates the

permanence of the database’s consistent state After commit, changes can’t be

lost

• If nothing ever goes wrong there is no

need for recovery.

that is known to be correct after some

incorrect.

– A database is correct iff it satisfies the logical

Recovery Facilities

• DBMS should provide following facilities to

assist with recovery:

– Backup mechanism, which makes periodic

backup copies of database.

– Logging facilities, which keep track of current

state of transactions and database changes.

– Checkpoint facility, which enables updates to

database in progress to be made permanent.

– Recovery manager, which allows DBMS to

restore the database to a consistent state following a failure.

– read checking balance

– subtract $500 from checking balance

– write checking balance

– read savings balance

– add $500 to savings balance

– write savings balance

Log file

• Transaction records contain:

– Transaction identifier.

– Type of log record, (transaction start, insert, update,

delete, abort, commit).

– Identifier of data item affected by database action

(insert, delete, and update operations).

– Before-image of data item.

– After-image of data item.

– Log management information.

Checkpoint

Point of synchronization between database and log file All buffers are force-written to secondary storage.

• Checkpoint record is created containing identifiers

of all active transactions.

• When failure occurs, redo all transactions that committed since the checkpoint and undo all transactions active at time of crash.

Transactions in the Log

• States

– Read / Write

– Commit / Abort

• Checkpoints & Force Writes

– Suspend execution of transactions temporarily

– Force-write all update operations of committed

transactions from main memory buffers to disk

– Write a record to the log and force-write the log to the disk

– Resume executing transactions

System Failures

• Contents of main memory (buffers) lost

• If precise state of transaction unknown, then transaction must be UNDONE

• If transaction completed but updates not

transferred to disk, then transaction must be REDONE

• For each of the following transactions

should the system do a REDO or UNDO?

T2 - started prior to checkpoint, completed after checkpoint but before crash

Recovery Process

• Start with 2 lists of transactions, UNDO list and REDO list Set UNDO list equal to list of all transactions given in the most

recent checkpoint record; set REDO list to empty

• Search forward through the log, starting from checkpoint record

• If a BEGIN TRANSACTION log entry found for transaction, T add T to UNDO list.

• If COMMIT log entry is found for transaction, T, move from UNDO list to REDO list.

• When end of log is reached, UNDO and REDO lists identify transactions to be undone and redone, respectively.

Shadow Paging

• Maintain two page tables during life of a

transaction: current page and shadow page table

• When transaction starts, two pages are the same

• Shadow page table is never changed thereafter and

is used to restore database in event of failure

• During transaction, current page table records all updates to database.

• When transaction completes, current page table becomes shadow page table.

Recovery Plans

• Variety of natural or human activities can damage or render vital information assets inoperable.

– Examples of natural disasters

– Examples of human error disasters

• Recovery plans deal with potential

situations in which risk of loss varies from high to low

• What is necessary to put in a recovery plan?