BISQL – Laymen to SQL Developer # 45 – Security & Integrity #2 – Authorization, Granting of Privileges, Security Specification in SQL

Hi Folks,

This post is part of Series Database Management Systems

Currently running topic for this series is listed as below :

Series of Database Management Systems

>>Chapter 1 : DBMS [Database Management Systems]

>>Chapter 2 : Database Core Concepts and  Applications

>>Chapter 3 : Record Storage and Primary File Organization

>>Chapter 4 : Index Structures of Files

>>Chapter 5 : Entity-Relationship Model

>>Chapter 6 : Relational Algebra

>>Chapter 7 : SQL

>>Chapter 8 : Functional Dependencies and  Normalization For Relational Databases

>>Chapter 9 : Transaction Processing

>>Chapter 10 : Concurrency Control Techniques

>>Chapter 11 : Recovery Techniques

>>Chapter 12 : Distributed Databases

>>Chapter 13 : Relational Databases

>>Chapter 14 : Security & Integrity<You are Here>

Continuing from my previous post on this series.

We are going to Cover the Following Points in this article

• Authorization
• Granting of Privileges
• Security Specification in SQL

Authorization

A user may have several forms of authorization on parts of the database. Among them are the following:

· 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

· Index authorization allows the creation and deletion of indices.

· Resource authorization allows the addition or deletion of attributes in a relation

· Drop authorization allows the deletion of relations.

The ultimate form of authority is that given to the database administrator. The database administrator may authorize new users.

Authorization and views:

A view can hide data that a user does not need to see. Views play a very important role in providing data security, and it simplifies the complex queries so that users concentrate only on required portion of the relations (tables). It prevents users from direct access to a relation; they can only view portions of the table.

E.g.: Create view V_emp as select emp_no. Ename, Sal from Emp; then select * from V_emp;

Here clerks are not authorized to see salary information directly from employee relation. But he must be granted access to the view V_emp. It provides a security on relation emp. A view V_emp must have read authorization on employee.

Granting of Privileges

A user who has been granted some form of authorization may be allowed to pass all or part of his/her rights to another user.

Consider an example, the granting of update authorization on the loan relation of the bank database. Assume that, initially, the database administrator grants update authorization on loan to users U1, U2, and U3, who may in turn pass on this authorization to other users. The passing of authorization form one user to another can be represented by an authorization graph. The nodes of this graph are the users. An edge U1 Uj is included in graph, if Ui grants update authorization to Uj. The root of the graph is the database administrator. Observe that user U5 is granted authorization by both U1 and U2; U4 is granted authorization by only U1.

A user has an authorization if and only if there is a path from the root of the authorization graph down to the node representing the user.

Suppose that the database administrator decides to revoke or cancel the authorization of a user U1, but U4 and U5 have been granted authorization from U1. Before revoking authorization from U4, U1 has to be revoked. But there is no need to revoke permissions from U5 because U5 was granted permissions from U1 and U2. Both U1 and U2 are still granting authorization to U5 who retains update authorization on loan.

To properly revoke access rights, all paths in the authorization group must start from the authorizer.

Security Specification in SQL

The SQL data definition language includes commands to grant and revoke privileges. The SQL standard includes delete, insert, and update privilege. The select privilege corresponds to the read privilege.

The grant statement is used to give authorization. The syntax is as follows:

grant<privilege list>on <relation name or view name>to<user list>

The privilege list allows the granting of several privileges in one command. The following grant statement grants users U1, U2 and U3 select authorization on the branch relation.

Grant select on branch to U1, U2, U3.

The update, insert authorization may be given either on all attributes of the relation or on only some.

Grant update (amount) on loan to U1, U2, and U3.

If we wish to grant a privilege and to allow the recipient to pass the privilege on to other users, we append the with grant option clause to the appropriate grant command.

If we wish to allow U1 the select privilege on branch and allow U1 to grant this privilege to others. We write:

Grant select on branch to U1 with grant option.

To revoke an authorization, we use the revoke statement. It takes a form almost identical to that of grant:

Revoke <privilege list>on<relation name or view name>

From<user list> [restrict | cascade]

Thus, to revoke the privilege that we granted previously, we write: Revoke select on branch from U1, U2, U3 cascade

Revoke update (amount) on loan from U1, U2, U3

Revoke references (branch-name) on branch from U1

ENCRYPTION:

Cryptography has been practiced to provide sufficient protection for highly sensitive data. It is not possible for encrypted data to be read unless the reader knows how to decrypt it.

In a distributed environment, translating highly confidential information between remote sites, which is with the increasing use of public communication facility to transmit data, it is most important to secure data. Otherwise it leads to leakage. There is a vast number of techniques for the encryption of data. Consider an e.g.: Substitution of each character with the next character in the alphabet this.

Hello

Becomes IFMMP

A good encryption technique should be relatively simple. It should be difficult to determine the encryption key for an unauthorized person.

An encryption technique developed by the US National Bureau of Standard (NBS) is called data encryption standard (DES), does both a substitution of characters and a rearrangement of their order on the basis of an encryption key. We must keep the encryption key secret.

However, the drawback in this key scheme is that the encryption key has to be transmitted to the recipient before a message can be transmitted.

Public key encryption is an alternative scheme that avoids some of the problems that we face with the DES.

It is based on two keys:

Public key and private key: This allows anyone to send a message in a coded form. However, decryption key is secret and only the rightful recipient can decode the message. It is more secure and it is expensive.

Hope you will like Series of Database Management Systems series !

If you have not yet subscribe this Blog , Please subscribe it from “follow me” tab !

So that you will be updated @ real time and all updated knowledge in your mail daily for free without any RSS subscription OR news reading !!

Happy Learning and Sharing !!

For More information related to BI World visit our all Mentalist networks Blog

SQL Server Mentalist … SQL Learning Blog

Business Intelligence Mentalist … Business Intelligence World

Microsoft Mentalist … MVC,ASP.NET, WCF & LinQ

MSBI Mentalist … MS BI and SQL Server

NMUG Bloggers …Navi Mumbai User Group Blog

Architectural Shack … Architectural implementation and design patterns

DBA Mentalist …Advance SQL Server Blog

MVC Mentalist … MVC Learning Blog

Link Mentalist … Daily Best link @ your email

Infographics Mentalist … Image worth explaining thousand Words

Hadoop Mentalist … Blog on Big Data

BI Tools Analysis … BI Tools

Connect With me on

| Facebook |Twitter | LinkedIn| Google+ | Word Press | RSS | About Me |