MOD 5 Part2
MOD 5 Part2
and Authorization
Introduction to Database Security Issues
◼ Types of Security
◼ Legal and ethical issues regarding right to access certain information.
◼ Policy issues at governmental, institutional or corporate level as to
what kind of information should not be made available.
◼ System-related issues such as the system levels at which various
security functions should be enforced.
◼ The need to identify multiple security levels and to categorize the data
and users based on these classification.
Slide 23- 2
Introduction to Database Security Issues (2)
◼ Threats to databases
◼ Loss of integrity
◼ Loss of availability
◼ Loss of confidentiality
Slide 23- 3
Access Control
◼ Security mechanism of a DBMS must provide provisions for
restricting access to the database system as a whole it is called
access control.
◼ It is handled by creating user accounts and passwords to control
the login process.
Inference Control
◼ For the case of statistical database about human population
statistics may provide statistics based on age groups, income
levels, household size, education levels and other criteria.
◼ Statistical db users such as govt statistitians or market research
firms are allowed to access the db to retrieve statistical information
about a population but not to access the detailed confidential
information about specific individuals.
◼ The corresponding control measures are called inference control.
Flow Control
◼ Which prevents information from flowing in such a way that it
reaches unauthorized users.
◼ Channels that are pathways for information to flow implicitly in ways
that violate the security policy of an organization are called covert
channels.
Data Encryption
▪ Which is used to protect sensitive data(such as credit card numbers)
that is transmitted via some type of communication network.
▪ Data is encoded using some algorithm.
◼ An unauthorized user who access encoded data will have
Slide 23- 8
Database Security and the DBA (2)
◼ 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
◼ 2. Privilege granting
◼ 3. Privilege revocation
◼ 4. Security level assignment
◼ Action 1 is access control, whereas 2 and 3 are discretionary and 4 is used to
control mandatory authorization
Slide 23- 9
Access Protection, User Accounts, and Database Audits
Slide 23- 10
Access Protection, User Accounts, and Database
Audits(2)
Slide 23- 11
Access Protection, User Accounts, and Database
Audits(3)
Slide 23- 12
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.
Slide 23- 13
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.
Slide 23- 14
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.
Slide 23- 15
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.
Slide 23- 16
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.
Slide 23- 17
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.
Slide 23- 18
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.
Slide 23- 19
Specifying Privileges Using Views
◼ The mechanism of views is an important discretionary authorization
mechanism in its own right. For example,
◼ If the owner A of a relation R wants another account B to be able to retrieve only
some fields of R, then A can create a view V of R that includes only those
attributes and then grant SELECT on V to B.
◼ The same applies to limiting B to retrieving only certain tuples of R; a view V’ can
be created by defining the view by means of a query that selects only those tuples
from R that A wants to allow B to access.
Slide 23- 20
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.
Slide 23- 21
Propagation of Privileges using the GRANT OPTION
◼ Whenever the owner A of a relation R grants a privilege on R to another
account B, privilege can be given to B with or without the GRANT OPTION.
◼ If the GRANT OPTION is given, this means that B can also grant that privilege
on R to other accounts.
◼ Suppose that B is given the GRANT OPTION by A and that B then grants the
privilege on R to a third account C, also with GRANT OPTION. In this way,
privileges on R can propagate to other accounts without the knowledge of the
owner of R.
◼ If the owner account A now revokes the privilege granted to B, all the privileges
that B propagated based on that privilege should automatically be revoked by the
system.
Slide 23- 22
2.5 An Example
◼ 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;
Slide 23- 23
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;
Slide 23- 24
2.5 An Example(3)
Slide 23- 25
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
Slide 23- 26
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.
Slide 23- 27