Sunteți pe pagina 1din 40

Database Security

Database

An organized collection of data

Data is typically organized using a data model

ER model

Relational model

DBMS

A software designed to allow definition, creation,

querying, update and administration of databases

Functions of a DBMS

Query Processing

Transaction Management

Storage Management

Metadata Management

Database Integrity

Fault Tolerance

Security

Security Policies for Database Systems

A set of rules that enforce security

Divided into two classes

Mandatory Security policies

Have to be followed strictly irrespective of the applications

Discretionary Security policies

Policies specified by the administrator

Variable in nature

Discretionary Security Policies

Access Control Policies

Control access to data

Authorization Policies

Users are granted access based on authorization rules

Various types of authorization policies

Positive authorization

Negative authorization

Conflict resolution

Strong and weak authorization

Propagation of authorization rules

Content and context based rules

Role based access control

Grant access to users depending on their roles and functions

Users need access to data depending on their

roles

Data accessible to one class of users may or may

not be available to another class of users

Eg. In an organization, the president can have access to all the information about the

organization, the financial head can access all the

finance related information, a team leader can access data pertaining to only the employees in

his/her team etc.

Administration Policies

Specify who is to administer the database

Administration duties usually performed by the Database Administrator (DBA) include keeping the data current, making sure that the metadata is updated etc.

Security related tasks may be performed by a

System Security Officer (SSO)

Identification and authentication

Users must identify themselves using user ID and

password

Authentication involves the verification of the user

credentials to ensure the identity of the user

Password based schemes are susceptible to attacks

Many modern systems use biometric techniques like face and voice recognition

Database views for security

Database views can be used to restrict the data exposed to the user

Eg. A relation Employee stores details relating to

the employees in a company. Some personal information like healthcare records, salary etc.

should not be viewed by other employees. This

can be done by defining a view on the Employee

relation that excludes these attributes.

Policy Enforcement

Mechanism to enforce security policies Three aspects to policy enforcement

Policy specification

Policy implementation

Policy visualization

SQL extensions for security

SQL is designed to access and manipulate data in a database

Security features embedded in SQL include the

GRANT and REVOKE functions which control access to the data for users

Eg:- GRANT JOHN EMPLOYEE READ, REVOKE JOHN

DEPT WRITE etc.

Extensions can be made to SQL to enforce certain security policies

Eg:- User John has read access to the name and salary attributes in a relation EMP separately, but never together. This can be specified in SQL as

access to the name and salary attributes in a relation EMP separately, but never together. This

Query modification

Database queries can be modified based on constraints to enforce security

Eg: Consider a query by the user John to retrieve all tuples from EMP. If John only has read access to all the tuples in EMP where salary is less than 30K, and the employee is not in Security department, then the query

to all the tuples in EMP where salary is less than 30K, and the employee is

Database functions affected by discretionary security measures

Query optimization

Transaction management

Storage management

Visualization of policies

Visualization tools are used by users to better understand the data in the databases

Visualization tools are useful when integrating

security policies of different databases

Visualizing the effects of dynamically varying

security policies are helpful in designing secure

databases

Mandatory Security Policies

Specify the access that users have to various database

objects

Uses Multi Level Security (MLS)

Based on Bell and LaPadula model of security

The various database objects are assigned security levels

which include Unclassified, Confidential, Secret and

TopSecret

The hierarchy of the security levels is Unclassified < Confidential < Secret < TopSecret

Subjects are assigned clearance levels for accessing data

Subjects can access data on levels upto and including their clearance level

The rules of the Bell and LaPadula model are

Simple security policy: A subject has read access

to an object if its level dominates the level of the object

* - Property: A subject has write access to an object if the subject’s security level is dominated by that of the object

For database systems, the *-property is modified such that a subject has write access to an object if the subject’s level is that of the object

A subject can modify relations at its own level

Security Architectures for MLS Databases

Integrity Lock

Contains an untrusted back end DBMS, an untrusted front end

that communicates with the user and a trusted filter component

that performs encryption

The untrusted components are isolated from each other and can communicate only through the trusted component

Multiple instantiations are maintained for the front end,

corresponding to each user level

Every tuple that is inserted into the database has associated with it a security label (also called a sensitivity label) and a cryptographic checksum.

Checksums are computed by the trusted filter on insertion and

recomputed during retrieval.

For insertions, the trusted filter computes the checksum and the untrusted back-end DBMS takes the data (i.e., the tuple) and associated label and checksum and stores them in the database

On retrieval, the back end retrieves the data tuples and passes

them to the trusted filter which recomputes the checksum

based on the tuple and label retrieved.

Operating System Providing Access Control

Also known as the HinkeSchaefer approach

Utilizes the underlying trusted operating system to perform the access-control mediation

No access-control mediation is performed by the DBMS

The DBMS objects (e.g., tuples) are aligned with the underlying operating system objects (e.g., files)

Thus, Secret tuples are stored in Secret files and

Top Secret tuples are stored in Top Secret files

Kernel Extensions Architecture

The underlying operating system is utilized to provide

the basic MAC and DAC mediation

However, the MLS/DBMS will supplement this access mediation by providing some additional access- control mediation

For example, the MLS/DBMS might provide context-

dependent DAC on views

Trusted Subject Architecture

Does not depend on the underlying operating system

to perform access control

the DBMS is considered to be a trusted subject hosted on top of the operating system

access to DBMS records is mediated by the trusted

DBMS

Distributed Architecture

Multiple untrusted back-end DBMSs and a single trusted front-end DBMS

Communication between the back-end DBMSs occurs

through the front-end DBMS Two approaches

Partitioned approach - Each back-end DBMS has data at a particular level and operates at that level

Replicated approach - Lower-level data is replicated at the

higher levels

With the partitioned approach the trusted front end is responsible for ensuring that the query is directed to

the correct back-end DBMS

For the replicated approach the trusted front end ensures that the query is directed to a single DBMS, which is has the same security level as the user

Multilevel Relational Data Models

Developed to support MLS/DBMS

The data in a relational database may be classified on several levels

Granularity of classification in a DBMS Database level

relational database may be classified on several levels • Granularity of classification in a DBMS –

Classifying relations

• Classifying relations • Classifying attributes

Classifying attributes

• Classifying relations • Classifying attributes

Classification of tuples

• Classification of tuples • Element level classification

Element level classification

• Classification of tuples • Element level classification

Classification of Views

• Classification of Views

Classification of Metadata

• Classification of Metadata

Polyinstantiation

A technique used in relational databases to represent the fact that users at different levels have different views of the same entity

For example, at the TopSecret level Mary’s salary would be 40K but at the Secret level it would be 30K, at the Confidential level

it would be 20K, and at the Unclassified level it would be 10K

the Secret level it would be 30K, at the Confidential level it would be 20K, and

Polyinstantiation violates the properties of the relational model

Every entity should have a unique representation in the relational model; in polyinstantiated model an entity has multiple representations

Polyinstantiation is required to eliminate covert channels

Eg. John has a salary of 70K, which is the real value and

therefore maintained as Top Secret. There is no other value for

the salary of John maintained at Secret, Confidential or Unclassified levels. A user at these levels when querying for John’s salary will not get an answer since no value is provided. The lack of answer, therefore, signals to the user about the

existence of a salary value for John maintained at a higher

security level. This information can be exploited by malicious users or processes to gain access and perform unauthorized modification of higher level data. The absence of data values at the different security level, therefore creates a covert channel

for accessing and modifying higher level data

Impact of security on database functions

Impact on query processing

The trust placed on the query processor depends

on the architecture of the entire system like integrity locking, extended kernel etc.

Query modification is a means of enforcing security; Irrespective of the security architecture followed, the part of the DBMS that performs this function should be a trusted component

Query optimization is also impacted by security

measures

Impact on transaction processing

Traditional transaction concurrency control algorithms

like locking can cause covert channels

A covert channel is created when a process operating at a higher level of security interferes with a low security level process

As an example, Consider the case where there are two

transactions operating at the Secret and Unclassified

levels Suppose the Secret transaction reads an Unclassified object while the Unclassified transaction

attempts to update the object. Then the Unclassified

transaction will not be able to update the object. This

provides information to the Unclassified transaction about the existence of the Secret transaction. A malicious process can exploit this information and

gain unauthorized access to the data in the database

Solution for this problem proposed by the author

For every Unclassified database object O, there is a Secret object which is a duplicate of O, say, O’ and a Secret object, say, O” that is only updated by the Secret process or transaction. Therefore, when an Unclassified transaction updates O, the duplicate O’ gets updated. The Secret transaction

reads from O’ and writes into O”. This way the

actions of the Secret transaction do not interfere with those of the Unclassified transaction

Impact on Storage Management

Storage management in a DBMS includes two major

aspects and they are designing efficient access methods

and indexing strategies

In a MLS/DBMS storage management involves the storing of multilevel data

The trust placed on the DBMS for the secure storage of

data is directed by the security architecture followed

If the operating system provides access control, then the DBMS is untrusted and therefore the access methods and

indexing algorithms are also untrusted

If the system is based on trusted subject architecture, then we need to determine the trust placed on the access- control and indexing algorithms

Developing secure storage, indexing and access methods

for databases is an active area of research

Impact on metadata management

Like data, metadata also has to be managed securely

It must be ensured that metadata is queried securely

If database transactions update metadata, it must be

ensured that higher level transactions do not interfere with lower level transactions

Metadata has to be stored and accessed securely

If the operating system is to provide access control to metadata, then metadata management functions may

be untrusted. If the DBMS controls access then

metadata management may be trusted.

Distributed Database Systems

The developments in computer networking technology and

database systems technology resulted in the development

of distributed databases

A distributed database is a database that is distributed across multiple sites

A distributed database system includes a Distributed Database Management System (DDBMS), a distributed database, and a network for interconnection.

Distributed database system functions include distributed query management, distributed transaction processing,

distributed metadata management, and enforcing security

and integrity across the multiple nodes

Discretionary Security for Distributed

Database Systems

Discretionary Security measures for distributed databases are

similar to those followed for non distributed databases

Access Control Policies

The access-control rules enforced in a distributed environment may be distributed, centralized, or replicated.

If the rules are centralized, then the central server needs to check all

accesses to the database. If the rules are distributed, then appropriate rules need to be located and enforced for a particular access. If the rules are replicated, meaning copies of the rules are stored at every site, any change in the rules made at one location should be reflected at all other locations where a copy of these rules are stored

As an example, suppose there is a rule that states that John has access

only to the employee salaries if the employees are in the math department. Suppose the database has two relations EMP and DEPT

where EMP is stored in site A and has attributes E#, Ename, Salary, and D#. DEPT is stored in site B and has attributes D#, Dname, and Mgr.

Now to access the salary values in EMP, one needs to do a join

between EMP and DEPT at different sites and make the connection between Salary and Dname. If the Dname is MATH, then John has access to the salary values of the employees in the math department.

Role based access control

In a distributed database environment users may have different roles at different nodes and may try to access the distributed database to carry out their functions.

The ideas developed for a centralized system can be extended for a distributed environment.

In the simple case, the user’s role is verified in a

distributed environment by contacting the local authority, and access is then granted.

In a multiorganizational environment, there may be some additional concerns. A user may have one role in one

organization and another role in another organization. For

example, in department A he may be a manager and in department B he may be a project leader. Therefore, he may have access to certain data in department A and certain other data in department B. His roles in different

departments will have to be verified before granting his

access

Identification and authentication

Identification and authentication in distributed databases may be performed either by a

centralized authority or a distributed authority

Having a single site to authenticate the user means that if that site fails then the user cannot

be authenticated

If every site is given the capability to authenticate the users, as users can log in from anywhere, then

it is required to ensure that the password

information is protected at all sites

Security Policy Integration

The schema of individual databases constituting a

distributed database system can be merged to obtain

a global schema

When performing such database schema integration, the security policies defined on the individual

databases has to be merged to define a global security

policy For example, in one database one could enforce a policy where the salary values of the relation EMP

cannot be accessed by John. In another database, one

could enforce a policy where the healthcare record of the relation MEDICAL cannot be accessed by John. Therefore, at the global level one enforces a policy where John does not have access to salaries in EMP or

healthcare records in MEDICAL.

Query modification

With query modification, the query is modified based on the access-control rules

The query is modified according to the access-

control rules enforced by a distributed database system

If the access-control rules are replicated, the

query modification can be performed at the site where the query is posed

If the access-control rules are distributed, then

the query is modified at each site according to the

rules enforced at that site and then the pieces are combined to form the final modified query

View mechanism

Views are essentially virtual relations and are computed from the base relations

In a distributed database environment, views may

be computed from relations and fragments stored at multiple sites

Users are then granted access to the resulting views

For example, EMP could be stored at site A and DEPT at site B and a view may be formed

consisting of employee names and their

managers. Access may be granted on this view and access denied on the base relations