0% found this document useful (0 votes)
19 views

Chapter 8 - Database Security and Integrity

This document discusses database integrity constraints and security. It describes four main types of integrity constraints - domain constraints, entity integrity constraints, referential integrity constraints, and key constraints. It also discusses restrictions on parallel DML statements with integrity constraints and different aspects of database security like confidentiality, authentication, and authorization.

Uploaded by

kalpana
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
19 views

Chapter 8 - Database Security and Integrity

This document discusses database integrity constraints and security. It describes four main types of integrity constraints - domain constraints, entity integrity constraints, referential integrity constraints, and key constraints. It also discusses restrictions on parallel DML statements with integrity constraints and different aspects of database security like confidentiality, authentication, and authorization.

Uploaded by

kalpana
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 16

E

C
l
f
R
K
I
m
D
a
s
o
c
r
g
e
y
i
t
n
Integrity constraints
Chapter 8
Database Security and Integrity

Integrity constraints in Database Management Systems (DBMS) are a set of rules that are
applied on the table columns or relationships to ensure that the overall validity, integrity, and
consistency (i.e. the quality) of the data present in the database table is maintained. Each and
every time a table insert, update, delete, or alter operation is performed, it is evaluated against
the terms or rules mentioned in the integrity constraint. The data is inserted, updated, deleted,
or altered only if the result of the constraint comes out to be True. Thus, integrity constraint
prevents accidental damage to the database by an authorized user. Integrity constraint is used
to guard against accidental damage to the database.

Types of Integrity constraints


In relational DBMS, we primarily have four types of integrity constraints, namely :

1.
Domain constraints
Domain constraints can be defined as the definition of a valid set of values for an attribute.The
data type of domain includes string, character, integer, time, date, currency, etc. The value of
the attribute must be available in the corresponding domain.

Example:
2. Entity integrity constraints
The entity integrity constraint states that primary key value can't be null. This is because the
primary key value is used to identify individual rows in relation and if the primary key has a null
value, then we can't identify those rows. A table can contain a null value other than the primary
key field.

Example:

3. Referential Integrity Constraints


A referential integrity constraint is specified between two tables. In the Referential integrity
constraints, if a foreign key in Table 1 refers to the Primary Key of Table 2, then every value of
the Foreign Key in Table 1 must be null or be available in Table 2.

Example:
4. Key constraints
o Keys are the entity set that is used to identify an entity within its entity set uniquely.
o An entity set can have multiple keys, but out of which one key will be the primary key. A
primary key can contain a unique and null value in the relational table.

Example:

Restrictions on integrity constraints

This section describes the interactions of integrity constraints and parallel DML statements.

NOT NULL and CHECK

NOT NULL and CHECK integrity constraints are allowed. They are not a problem for parallel DML
because they are enforced on the column and row level, respectively.
UNIQUE and PRIMARY KEY

UNIQUE and PRIMARY KEY integrity constraints are allowed.

FOREIGN KEY (Referential Integrity)

Restrictions for referential integrity occur whenever a DML operation on one table could cause
a recursive DML operation on another table. These restrictions also apply when, to perform an
integrity check, it is necessary to see simultaneously all changes made to the object being
modified. Below Table lists all of the operations that are possible on tables that are involved in
referential integrity constraints.

DML Statements Issued on Parents Issued on Child Self - Referential


INSERT (Not Applicable) Not Parallelized Not Parallelized
MERGE (Not Applicable) Not Parallelized Not Parallelized
UPDATE No Action Supported Supported Not Parallelized
DELETE No Action Supported Supported Not Parallelized
DELETE Cascade Not Parallelized (Not Applicable) Not Parallelized

Delete Cascade

Deletion on tables having a foreign key with delete cascade is not parallelized because parallel
execution servers attempt to delete rows from multiple partitions (parent and child tables).

Self-Referential Integrity

DML on tables with self-referential integrity constraints is not parallelized if the referenced keys
(primary keys) are involved. For DML on all other columns, parallelism is possible.

Deferrable Integrity Constraints

If any deferrable constraints apply to the table being operated on, the DML operation is not
executed in parallel.

Data security
Database security is the technique that protects and secures the database against intentional or
accidental threats. Security concerns will be relevant not only to the data resides in an
organization's database: the breaking of security may harm other parts of the system, which
may ultimately affect the database structure. Consequently, database security includes
hardware parts, software parts, human resources, and data. To efficiently do the uses of
security needs appropriate controls, which are distinct in a specific mission and purpose for the
system. The requirement for getting proper security while often having been neglected or
overlooked in the past days; is now more and more thoroughly checked by the different
organizations.
We consider database security about the following situations:

 Theft and fraudulent.


 Loss of confidentiality or secrecy.
 Loss of data privacy.
 Loss of data integrity.
 Loss of availability of data.
These listed circumstances mostly signify the areas in which the organization should focus on
reducing the risk that is the chance of incurring loss or damage to data within a database. In
some conditions, these areas are directly related such that an activity that leads to a loss in one
area may also lead to a loss in another since all of the data within an organization are
interconnected.

Data Security Risks


We have seen that the database security is the concern of the entire organization. The
organization should identify all the risk factors and weak elements from the database security
Perspective and find solutions to counter and neutralize each such threat.
A threat is any situation, event or personnel that will adversely affect the database security
and the smooth and efficient functioning of the organization. A threat may be caused by a
situation or event involving a person, action or circumstance that is likely to bring harm to the
organization. The harm may be tangible, such as loss of data, damage to hardware, loss of
software or intangible such as loss of customer goodwill or credibility and so on.
Complex user management requirements

Dimensions of security

Data security requirements


We should use technology to ensure a secure computing environment for the organization.
Although it is not possible to find a technological solution for all problems, most of the security
issues could be resolved using appropriate technology. The basic security standards which
technology can ensure are confidentiality, integrity and availability.
Confidentiality

A secure system ensures the confidentiality of data. This means that it allows individuals to see
only the data they are supposed to see. Confidentiality has several aspects like privacy of
communications, secure storage of sensitive data, authenticated users and authorization of
users.
Privacy of Communications

The DBMS should be capable of controlling the spread of confidential personal information
such as health, employment, and credit records. It should also keep the corporate data such as
trade secrets, proprietary information about products and processes, competitive analyses, as
well as marketing and sales plans secure and away from the unauthorized people.
Secure Storage of Sensitive Data

Once confidential data has been entered, its integrity and privacy must be protected on the
databases and servers wherein it Resides.
Authentication

One of the most basic concepts in database security is authentication, which is quite simply the
process by which it system verifies a user’s identity, A user can respond to a request to
authenticate by providing a proof of identity, or an authentication token
You’re probably already familiar with concept. If you have ever been asked to show a photo ID
(for example, when opening a bank account), you have been presented with a request for
authentication. You proved your identity by showing your driver’s license (or other photo ID).
In this case, your driver’s license served as your authentication token.
Despite what you see in the movies, most software programs cannot use futuristic systems
such as face recognition for authentication. Instead most authentication requests ask you to
provide a user ID and a password. Your user ID represents your claim to being a person
authorized to access the environment, and the password is protected and you are the only
person who knows it.
Authorization

An authenticated user goes through the second layer of security, authorization. Authorization
is the process through which system obtains information about the authenticated user,
including which database operations that user may perform and which data objects that user
may access.
Your driver’s license is a perfect example of an authorization document. Though it can be used
for authentication purposes, it also authorizes you to drive a certain class of car. Furthermore,
the type of authorization you have gives you more or fewer privileges as far as driving a vehicle
goes.
A user may have several forms of authorization on parts of the database. There are the
following authorization rights.
 Read authorization allows reading, but not modification, of data.
 Insert authorization allows insertion of new data, but not modification of existing data.
 Update authorization allows modification, but not deletion of data.
 Delete authorization allows deletion of data.
A user may be assigned all, none, ‘or a combination of these types of authorization. In addition
to these forms of authorization for access to data, a user may be granted authorization to
modify the database schema:
 Index authorization allows the creation and deletion of indexes.
 Resource authorization allows the creation of new relations.
 Alteration authorization allows the addition or deletion of attributes in a relation.
 Drop authorization allows the deletion of relations.
The drop and delete authorization differ in that delete authorization allows deletion of tuples
only. If a user deletes all tuples of a relation, the relation still exists, but it is empty. If a relation
is dropped it no longer exists. The ability to create new relations is regulated through resource
authorization. A user with resource authorization who creates a relation is given a privilege on
that relation automatically. Index authorization is given to user to get the fast access of data on
the bases of some key field.
Integrity

A secure system en sums that the data it contains is valid. Data integrate means that data is
protected from deletion and corruption, both while it resides within the data-case, and while it
is being transmitted over the network. The detailed discussion on Integrity is un next section.
Availability

A secure system makes data available to authorized users, without delay. Denial of service
attacks are attempts to block authorized users’ ability to access and use the system when
needed.

Database users
Database users are categorized based up on their interaction with the data base.
These are seven types of data base users in DBMS.

1. Database Administrator (DBA) :


Database Administrator (DBA) is a person/team who defines the schema and also controls
the 3 levels of database.
The DBA will then create a new account id and password for the user if he/she need to
access the data base. DBA is also responsible for providing security to the data base and he
allows only the authorized users to access/modify the data base.
 DBA also monitors the recovery and back up and provide technical support.
 The DBA has a DBA account in the DBMS which called a system or superuser account.
 DBA repairs damage caused due to hardware and/or software failures.

2. Naive / Parametric End Users :


Parametric End Users are the unsophisticated who don’t have any DBMS knowledge but they
frequently use the data base applications in their daily life to get the desired results.
For examples, Railway’s ticket booking users are naive users. Clerks in any bank is a naive
user because they don’t have any DBMS knowledge but they still use the database and
perform their given task.
3. System Analyst :
System Analyst is a user who analyzes the requirements of parametric end users. They check
whether all the requirements of end users are satisfied.

4. Sophisticated Users :
Sophisticated users can be engineers, scientists, business analyst, who are familiar with the
database. They can develop their own data base applications according to their requirement.
They don’t write the program code but they interact the data base by writing SQL queries
directly through the query processor.

5. Data Base Designers :


Data Base Designers are the users who design the structure of data base which includes
tables, indexes, views, constraints, triggers, stored procedures. He/she controls what data
must be stored and how the data items to be related.

6. Application Program :
Application Program are the back end programmers who writes the code for the application
programs.They are the computer professionals. These programs could be written in
Programming languages such as Visual Basic, Developer, C, FORTRAN, COBOL etc.

7. Casual Users / Temporary Users :


Casual Users are the users who occasionally use/access the data base but each time when
they access the data base they require the new information, for example, Middle or higher
level manager.

Protecting data within the database


Authorization is permission given “to user, program, or process to access an object or set of
objects. The type of data access granted to a user can be read-only, or read and write.
Privileges specify the type of Data Manipulation Language (DML) operations like SELECT,
INSERT, UPDATE, DELETE, etc., which the user can perform upon data.
The two methods by which the access control is done are by using privileges and roles.
 Privilege
 Roles

PRIVILEGES
A privilege is permission to access a named object in a prescribed manner; for example,
permission to query a table. Privileges can be granted enable a particular user to connect to
the database (create a session); select rows from someone else’s table; or execute someone
else’s stored procedure.
Database privileges
A privilege is a right to execute a particular type of SQL statement or to access another user’s
object. Some examples of privileges include:
• The right to connect to the database (create a session)
• The right to create a table
• The right to select rows from another user’s table
• The right to execute another user’s stored procedure
Privileges are granted to users so that these can accomplish tasks required for their job. You
should grant a privilege only to user who absolutely requires the privilege to accomplish
necessary work. Excessive granting of unnecessary privileges can lead to compromised security.
System privileges

A system privilege is the right to perform a particular action, on a particular type of object. For
example, the privileges to create tables and to delete the OWS of any table in a database are
system privileges. In many commercial database management systems there are hundreds of
distinct system privileges.
Object privileges

An object privilege is a privilege or right to perform a particular action on a specific table, view,
sequence, procedure, function, or package. For example, the privilege to delete rows from the
table DEPT is an object privilege.
Object privileges granted for a table, view, sequence, procedure, function, or package apply
whether referencing the base object by name or using a synonym.
ROLES
A role is a mechanism that can be used to provide authorization. A single person or a group of
people can be granted a role or a group of roles. One role can be granted in turn to other
roles. By defining different types of roles, administrators can manage access privileges much
more easily.
Database management systems provide for easy and controlled privilege management
through roles. Roles are named groups of related privileges that you grant to users or other
roles. Roles are designed to ease the administration of end-user system and object privileges.
The following properties of roles allow for easier privilege management within a database:
 Reduced privilege administration – Rather them explicitly granting the same set of
privileges to several uses, you can grant the privileges for a group of related users to a
role. Then, only the role needs to be granted to each member of the group.
 Dynamic privilege management – If the privileges of a group must change, only the
privileges of the role need to be modified.
 Selective availability of privileges – You can selectively enable or disable the roles
granted to a user. This allows specific control of a user’s privileges in any given
situation.
 Application-specific security – you can protect role use with a password. Applications
can be created specifically to enable a role when supplied the correct password. Users
cannot enable the role if they do not know the password.

Granting and revoking privileges and roles


You grant or revoke privileges and roles from users or other roles using the SQL commands
GRANT and REVOKE. Who can grant and revoke the privileges and roles? The answer is “it
depends on the DBMS”. For example, in Oracle, a with the GRANT ANY ROLE system privilege
can grant or revoke any role to or from other users or roles of the database most database
management systems, the Database Administrators (DBAs) and Security Officers will have the
necessary powers to grant and revoke the privileges and roles to the users.
GRANT Command

The GRANT command gives users privileges to base tables and views.
The syntax of this command is as follows:
GRANT privileges ON object to users [with GRANT Option]
Here, object is either a base table or a view. If ‘with GRANT Option’ is specified, it means that
the recipient has authority to grant the privileges that were granted to him to another user.
Examples:-
Grant the SELECT authority on the EMP table to all users.
GRANT SELECT ON EMP TO PUBLIC;
Grant the SELECT, DELETE and UPDATE authority on DEPT table to user 'AJAY'.
GRANT SELECT, DELETE, UPDATE ON DEPT TO AJAY;
Grant the SELECT.' DELETE and UPDATE authority with the capability to
grant those privileges to others users on DEPT table to user 'AJAY'.
GRANT SELECT, UPDATE ON DEPT TO AJAY WITH GRANT OPTION;
Grant ALL privileges on EMP table to user 'DEEP'.
GRANT ALL ON EMP TO DEEP;
Give the system privileges for creating tables and views to ‘AJAY’.
GRANT CREATE TABLE, CREATE VIEW TO AJAY
Grant the UPDATE authority on the SAL column of the EMP to user 'AJAY'.
GRANT UPDATE (SAL) ON EMP TO AJAY;
REVOKE Command
REVOKE is a complementary command to GRANT that allows the withdrawal of privileges. The
syntax of the REVOKE command is as follows:
REVOKE [GRANT OPTION FOR] privileges
ON object FROM users {Restrict I Cascade}
The command can be used to REVOKE either a privilege or just the GRANT option on a privilege
(by using the optional GRANT OPTION FOR Clause). When a user executes a REVOKE command
with the CASCADE keyword, the effect is to withdraw the named privileges or GRANT option
from all users who currently hold these privileges solely through a GRANT command that was
previously executed by the same user who is now executive the REVOKE command. If these
users received the privileges with the GRANT option and passed it along, those recipients will
also lose their privileges as a consequence of the REVOKE command unless they also received
these privileges independently. RESTRICT keyword is a complementary to CASCADE keyword.

Examples:-
Revoke the system privileges for creating table from 'AJAY';
REVOKE CREATE TABLE FROM AJAY;
Revoke the SELECT privileges on EMP table from ‘AJAY’;
REVOKE SELECT ON EMP FROM AJAY;
Revoke the UPDATE privileges on EMP table from all users.
REVOKE UPDATE ON EMP FROM PUBLIC;
Remove ALL privileges on EMP table from user 'AJAY';
REVOKE ALL ON EMP FROM AJAY;
Remove DELETE and UPDATE authority on the SAL and
JOB columns of the EMP table from user 'AJAY'.
REVOKE DELETE, UPDATE (SAL, JOB) ON EMP FROM AJAY;

System viability Factors

Authenticating users to the database

A basic security requirement is that you must know your users. You must identify them before
you can determine their privileges and access rights, and so that you can audit their actions
upon the data.
Users can be authenticated in a number of different ways before they are allowed to create a
database session. In database authentication, you can define users such that the database
performs both identification and authentication of users. In external authentication, you can
define users such that authentication is performed by the operating system or network service.
Alternatively, you can define users such that they are authenticated by the Secure Sockets
Layer (SSL). For enterprise users, an enterprise directory can be used to authorize their access
to the database through enterprise roles. Finally, you can specify users who are allowed to
connect through a middle-tier server. The middle-tier server authenticates and assumes the
identity of the user and is allowed to enable specific roles for the user. This is called proxy
authentication.

Passwords for Authentication

Passwords are one of the basic forms of authentication. A user must provide the correct
password when establishing a connection to prevent unauthorized use of the database. In this
way, users attempting to connect to a database can be authenticated by using information
stored in that database. Passwords are assigned when users are created. A database can store a
user's password in the data dictionary in an encrypted format. Users can change their
passwords at any time.

Database security systems that are dependent on passwords require that passwords be kept
secret at all times. But, passwords are vulnerable to theft, forgery, and misuse. A number of
steps can strengthen the basic password feature and provide greater control over database
security:

 Password management policy can be controlled by DBAs and security officers through
user profiles.
 The DBA can establish standards for password complexity, such as minimum password
length.
 Passwords should be words that cannot be found in the dictionary. They should not
consist of people's names or birthdates.
 Passwords can be timed out, expiring after a certain amount of time. This requires users
to change the value periodically.
 Reuse of passwords can be prohibited for a certain amount of time.
 When a particular user exceeds a designated number of failed login attempts, the server
can automatically lock that user's account.

Strong Authentication

Having a central facility authenticate all members of the network (clients to servers, servers to
servers, users to both clients and servers) is one effective way to address the threat of nodes on
a network falsifying their identities. Strong authentication can also be established by using two-
factor authentication: the combination of something a user knows (such as a PIN), and
something the user has (such as a token card).

Strong authentication has important advantages:

 More choices of authentication mechanism are available, such as smart cards, Kerberos,
or the operating system.
 Many network authentication services, such as Kerberos and DCE, support single sign-
on. This means that users have fewer passwords to remember.
 If you already use some external mechanism for authentication, then there may be less
administrative overhead to use that mechanism with the database as well.

The following strong authentication methods that can be used in a distributed environment:

 Kerberos and CyberSafe


 RADIUS
 Token Cards
 Smart Cards
 Distributed Computing Environment (DCE)
 Biometrics
 PKI and Certificate-Based Authentication

Proxy Authentication and Authorization

In multitier environments, such as a transaction processing monitor, it is necessary to control


the security of middle-tier applications by preserving client identities and privileges through all
tiers, and auditing actions taken on behalf of clients. Proxy authentication permits you to do
this. For example, this feature enables the identity of someone using a Web application (also
known as a proxy) to be passed through the application to the database server. This has several
ramifications:

 It permits the application to validate the credentials of a user by passing them to the
database server, in some cases.
 It enables the database administrator to regulate which users are allowed to access the
database server through a given application.
 It enables the administrator to audit actions of the application acting on behalf of a
given user.

Since each middle tier can be delegated ability to authenticate and act on behalf of a specific
set of users, and with a specific set of roles, proxy authentication supports a limited trust model
for the middle-tier server, and avoids the problem of an all-privileged middle tier. It is also
possible to give more privilege to a trusted middle tier (for example, one that is within the
corporate firewall) than to a less-trusted middle tier (for example, one that is outside the
firewall and thus more vulnerable to compromise). Moreover, because the identity of both
middle tier and user are passed to the database through a lightweight user session, this feature
makes it easier to audit the actions of users in a three-tier system, and thus improves
accountability.

Proxy authentication can potentially support:

 Database users
 Enterprise users
 Application users not known to the database

One advantage of a middle tier is connection pooling, which enables multiple users to access a
data server without each of them needing a separate connection. In such environments, you
need to be able to set up and break down connections very quickly. For these environments,
lightweight sessions are important. These lightweight sessions enable each user to be
authenticated by a database password without the overhead of a separate database
connection, and they preserve the identity of the real user through the middle tier.

Single sign-on

Intranet users are commonly required to use a separate password to authenticate themselves
to each server they need to access in the course of their work. Multiple passwords, however,
present several problems. Users have difficulty keeping track of different passwords, tend to
choose poor ones, and tend to record them in obvious places. Administrators must keep track
of a separate password database on each server and must address potential security problems
arising from the fact that passwords are routinely and frequently sent over the network.

Single sign-on (SSO) does away with these problems. It enables a user to log in to different
servers using a single password to obtain authenticated access to all servers she is authorized to
access. It eliminates the need for multiple passwords. In addition, it simplifies management of
user accounts and passwords for system administrators.

You can implement SSO in different ways, as described in the following sections:

 Server-Based Single sign-on


 Middle Tier Single Sign-On

Server-Based Single sign-on

A centralized directory server can be used to store user, administration, and security
information. This enables the administrator to modify information in only one location, namely,
the directory. This centralization lowers the cost of administration and makes the enterprise
more secure.
A directory server can be used to provide centralization of user account, user role, and
password information. A database server authenticates a user with the information stored in
the directory. Once authenticated, a user can access the databases configured to use enterprise
user security.

Middle Tier Single Sign-On

Oracle9iAS Single Sign-On server is part of the Oracle9i infrastructure and provides Web-based
single sign-on and integration with legacy applications. With single sign-on, users need maintain
only a single strong user name/password account for accessing all Web applications throughout
the enterprise.

Applications integrated with Oracle9iAS Single Sign-On securely delegate the user
authentication process. Among other things, this enforces password rules, account lockouts
based on repeated login failures, and auditing. The Single Sign-On server also has the ability to
authenticate a user by means of an external repository such as LDAP or a database user
repository, or by local authentication.

The first time that a user tries to access an application using Single Sign-On, the server:

 Authenticates the user by means of user name and password


 Passes the client's identity to the Single Sign-On enabled applications
 Marks the client being authenticated with an encrypted login cookie

In subsequent user logins, the login cookie provides the Single Sign-On Server with the user's
identity and indicates that authentication has already been performed.

Design and Development of Database Applications on Commercial RDBMS


Platforms
 Virtually all real-world user interaction with databases is indirect — it is mediated through an
application
 A database application effectively adds additional layers over the database
 User interface — presentation of data, interaction
 Business logic — rules, control flow, restrictions, validation/verification of data
 In the end, a database application is like any other application — it just has persistent storage
underneat

Steps to Know
 how to specify, document, and design a relational database (E-R/UML, object-relational
mapping, functional dependencies, normal forms)
 how to add/modify/delete and, most of all, retrieve information from that database (relational
algebra, SQL)
 how to communicate with that database programmatically (JDBC) using a recommended design
pattern (DAO)

Database Application Issues

 Databases are most useful when shared — issues and additional knowledge requirements ensue
 Network structure and protocols
 Security concerns
 Concurrency and transaction management
 Resource management — databases, network bandwidth, and server capacity are all
finite
 Very prevalent “special case” — Web applications
 So, in order to write a decent end-user application for your database, you also need to know
 How to write a decent non-database end-user application to begin with
 Standalone application: Java/Swing, others
 Web application: XHTML, CSS, JavaScript, CGI/scripting,Web containers
(JSP,ASP, etc.)
 Other useful technologies: XML, computer graphics creation and programming
(paint programs, Java2D, maybe OpenGL), application packaging/deployment
(standalone downloads, Java WebStart)
 How different processes running potentially on different machines can interact and
communicate
 Then,“just add database”
 What we’ve said before, plus additional tools that may make the database part easier
(BeanUtils, Hibernate)

You might also like