Chapter 7-2

Database Security- Part 2

Database Security and the

DBA
 7.1 Database Security and the
DBA
 The database administrator (DBA) is the
central authority for managing a database
system.
 The DBA’s responsibilities include
 granting privileges to users who need to use the
system
 classifying users and data in accordance with the
policy of the organization

 The DBA is responsible for the overall security

of the database system.
 7.1 Database Security and the
DBA

 The DBA has a DBA account in the DBMS, Sometimes

these are called a system or superuser account
 These accounts provide powerful capabilities such as:
1. Account creation (access control)
2. Privilege granting (Discretionary Access Control - DAC )
3. Privilege revocation (Discretionary Access Control - DAC)
4. Security level assignment (Mandatory Access Control -
MAC)
 7.2 Access Protection, User
Accounts, and Database Audits

 Whenever a person or group of person s need to

access a database system, the individual or group
must first apply for a user account.
 The DBA will then create a new account id and
password for the user if he/she deems there is a
legitimate need to access the database
 The user must log in to the DBMS by entering
account id and password whenever database
access is needed.
7.2 Access Protection, User
Accounts, and Database Audits(2)

 The database system must also keep track of all

operations on the database that are applied by a
certain user throughout each login session.
 To keep a record of all updates applied to the database
and of the particular user who applied each update, we
can modify system log, which includes an entry for each
operation applied to the database that may be required
for recovery from a transaction failure or system crash.
7.2 Access Protection, User
Accounts, and Database Audits(3)

 If any tampering with the database is suspected, a

database audit is performed
 A database audit consists of reviewing the log to
examine all accesses and operations applied to the
database during a certain time period.
 A database log that is used mainly for security
purposes is sometimes called an audit trail.
7.3 Discretionary Access Control
Based on Granting and Revoking
Privileges
The typical method of enforcing
discretionary access control in a
database system is based on the
granting and revoking privileges.
Types of Discretionary
Privileges
 The account level:
 At this level, the DBA specifies the particular privileges
that each account holds independently of the relations
in the database.
 The relation level (or table level):
 At this level, the DBA can control the privilege to access
each individual relation or view in the database.
Types of Discretionary
Privileges(2)
 The privileges at the account level apply to the
capabilities provided to the account itself and can
include
 the CREATE SCHEMA or CREATE TABLE privilege, to
create a schema or base relation;
 the CREATE VIEW privilege;
 the ALTER privilege, to apply schema changes such
adding or removing attributes from relations;
 the DROP privilege, to delete relations or views;
 the MODIFY privilege, to insert, delete, or update
tuples;
 and the SELECT privilege, to retrieve information from
the database by using a SELECT query.
Types of Discretionary
Privileges(3)
 The second level of privileges applies to the relation
level
 This includes base relations and virtual (view) relations.
 The granting and revoking of privileges generally
follow an authorization model for discretionary
privileges known as the access matrix model where
 The rows of a matrix M represents subjects (users,
accounts, programs)
 The columns represent objects (relations, records,
columns, views, operations).
 Each position M(i,j) in the matrix represents the types
of privileges (read, write, update) that subject i holds
on object j.
Types of Discretionary
Privileges(4)
 To control the granting and revoking of relation
privileges, each relation R in a database is
assigned and owner account, which is typically
the account that was used when the relation
was created in the first place.
 The owner of a relation is given all privileges on
that relation.
 In SQL2, the DBA can assign and owner to a
whole schema by creating the schema and
associating the appropriate authorization
identifier with that schema, using the CREATE
SCHEMA command.
 The owner account holder can pass privileges
on any of the owned relation to other users by
granting privileges to their accounts.
Types of Discretionary
Privileges(5)
 In SQL the following types of privileges can be
granted on each individual relation R:
 SELECT (retrieval or read) privilege on R:
 Gives the account retrieval privilege.
 In SQL this gives the account the privilege to use the
SELECT statement to retrieve tuples from R.
 MODIFY privileges on R:
 This gives the account the capability to modify tuples
of R.
 In SQL this privilege is further divided into UPDATE,
DELETE, and INSERT privileges to apply the
corresponding SQL command to R.
 In addition, both the INSERT and UPDATE privileges
can specify that only certain attributes can be
updated by the account.
Types of Discretionary
Privileges(6)

 In SQL the following types of privileges can be granted

on each individual relation R (contd.):
 REFERENCES privilege on R:
 This gives the account the capability to reference relation R
when specifying integrity constraints.
 The privilege can also be restricted to specific attributes of R.

 Notice that to create a view, the account must have

SELECT privilege on all relations involved in the view
definition.
Revoking Privileges

 In some cases it is desirable to grant a privilege to a

user temporarily. For example,
 The owner of a relation may want to grant the SELECT
privilege to a user for a specific task and then revoke that
privilege once the task is completed.
 Hence, a mechanism for revoking privileges is needed. In
SQL, a REVOKE command is included for the purpose of
canceling privileges.
An Example 1

 Suppose that the DBA creates four accounts

 A1, A2, A3, A4
 and wants only A1 to be able to create
base relations. Then the DBA must issue the
following GRANT command in SQL
GRANT CREATETAB TO A1;

 In SQL2 the same effect can be

accomplished by having the DBA issue a
CREATE SCHEMA command as follows:
CREATE SCHAMA EXAMPLE
AUTHORIZATION A1;
Privilege Matrix- Multi-system
level
Privilege Matrix- Module
level
2.5 An Example (2)

 User account A1 can create tables under the

schema called EXAMPLE.
 Suppose that A1 creates the two base relations
EMPLOYEE and DEPARTMENT
 A1 is then owner of these two relations and
hence all the relation privileges on each of
them.
 Suppose that A1 wants to grant A2 the privilege
to insert and delete tuples in both of these
relations, but A1 does not want A2 to be able to
propagate these privileges to additional
accounts:
GRANT INSERT, DELETE ON
EMPLOYEE, DEPARTMENT TO A2;
2.5 An Example (3)
2.5 An Example (4)

 Suppose that A1 wants to allow A3 to retrieve

information from either of the two tables and
also to be able to propagate the SELECT
privilege to other accounts.
 A1 can issue the command:
GRANT SELECT ON EMPLOYEE, DEPARTMENT
TO A3 WITH GRANT OPTION;
 A3 can grant the SELECT privilege on the
EMPLOYEE relation to A4 by issuing:
GRANT SELECT ON EMPLOYEE TO A4;
 Notice that A4 can’t propagate the SELECT
privilege because GRANT OPTION was not given
to A4
2.5 An Example (5)

 Suppose that A1 decides to revoke the SELECT

privilege on the EMPLOYEE relation from A3; A1 can
issue:

REVOKE SELECT ON EMPLOYEE FROM

A3;
 The DBMS must now automatically revoke the SELECT
privilege on EMPLOYEE from A4, too, because A3
granted that privilege to A4 and A3 does not have the
privilege any more.
2.5 An Example (6)
 Suppose that A1 wants to give back to A3 a limited
capability to SELECT from the EMPLOYEE relation and
wants to allow A3 to be able to propagate the
privilege.
 The limitation is to retrieve only the NAME, BDATE,
and ADDRESS attributes and only for the tuples
with DNO=5.
 A1 then create the view:
CREATE VIEW A3EMPLOYEE AS
SELECT NAME, BDATE, ADDRESS
FROM EMPLOYEE
WHERE DNO = 5;
 After the view is created, A1 can grant SELECT on the
view A3EMPLOYEE to A3 as follows:
GRANT SELECT ON A3EMPLOYEE TO A3
WITH GRANT OPTION;
2.5 An Example (7)

 Finally, suppose that A1 wants to allow A4 to

update only the SALARY attribute of EMPLOYEE;
 A1 can issue:
GRANT UPDATE ON EMPLOYEE (SALARY) TO
A4;

 The UPDATE or INSERT privilege can specify

particular attributes that may be updated or
inserted in a relation.
 Other privileges (SELECT, DELETE) are not
attribute specific.