Database Security

BBIT2 Database Systems 2
Database Security
Database Management
McFadden & Hoffer, Chapter 9
Database Systems
Connolly, Begg & Strachan, Chapter 16
Fundamentals of Database Systems

Elmasri/Navathe, Chapter 22
The Cuckoo’s Egg

Stoll
© Stephen Mc Kearney, 2001. 1

Overview
• Definition
– Reasons for security
– Issues
• Types of security
– Effective security
– System Requirements
• Database Security
– Questions to ask when considering security
– Database-independent measures
– Database-dependent measures
– Security in SQL
2

Database Security
• Definition
– “Security protects data from intentional or
accidental misuse or destruction, by controlling
access to the data.”
• Stamper & Price
– “Database security is concerned with the ability of
the system to enforce a security policy governing
the disclosure, modification or destruction of
information.”
• Pangalos

Reasons for Security

• Moral/Ethical
• Legal requirements
• Commercial security
• Fraud/Sabotage
• Mistakes
Moral/Ethical
There may be moral reasons for controlling who has access to
information. For example, medical records are confidential because
of people’s right to privacy.
Legal Requirements
The Data Protection Act requires companies to register personal data
with the data protection registrar. The act imposes constraints on how
information may be used and who may have access to it. Information
about individuals must be correct, up-to-date and available for
inspection by the individuals concerned.
Commercial Security
Information held by companies is a valuable resource which may be
useful to competitors. For example, a list of customers who have
bought insurance policies may be valuable to other insurance
companies.
Fraud/Sabotage
Information may be misused, for example, insider dealing, or used to
mislead.
Mistakes
Many problems are not malicious but are caused by users accidentally
changing the data.

Issues
• Confidentiality
– information is only disclosed to authorised users
• Integrity
– information is only modified by authorised users
• Availability
– information is accessible by authorised users

Types of Security
• Authorisation Policies
– Disclosure and modification of data
• Data Consistency Policies
– Consistency and correctness of data
• Availability Policies
– Availability of information to users
• Identification/Authentication/Audit Policies
– Authorising users to access data

Effective Security - Assumptions

• Correct User Identification
– It should not be possible to fool the DBMS
• e.g. usernames, passwords, etc
• Unanticipated Observers
– It should not be possible to gain access to DBMS
through components (disks, tapes, network, etc)
• e.g. encryption
• User/Privilege information protected
– It should not be possible to access user information
• e.g. passwords
7

System Requirements
• S/W and H/W around the database
– All aspects of the system must be considered
• Data Integrity
– All data must be correct and consistent
– User must trust database content
• Data Availability
– Fault tolerance, redundancy, etc
• Auditing
– Useful but not excessive
8

Constraints
• Security constraints
– Authorisation controls
– Stored in the data dictionary
– DBMS monitors constraints
• Integrity constraints
– Consistent controls
– Stored in the data dictionary
– DBMS monitors integrity
Security constraints in a database are concerned with controlling and

authorising access to the data. For example,
(a) Who may insert data into a table?
(b) Who may create a table?
Integrity constraints are concerned with maintaining the database in a
consistent/correct state. For example,
(a) Employees’ salaries may not increase by more than 5% per
year,
(b) All employees must work on a project.
Security and integrity are related concepts. Both are:
(a) Stored in the data dictionary,
(b) Enforced by the DBMS.

Security Questions
• How valuable is the data?
• Which data must be secured?
• What will illegal access to the data cost?
• What are the implications of changed/destroyed
data?
• Will security measures affect the proper
functioning of the database?
• How can unauthorised access occur?
10
We ask a set of questions about the database when we are selecting the type
of security to impose.
How valuable is the data?
Different types of data need different levels of security.
Publicly available data, for example, stock prices, do not
require the same level of security as private data, for example,
employee salaries.
What will illegal access to the data cost?
If a piece of data has a high value, for example, information
about the performance of a company, then illegal access may
be very costly. The cost of ‘losing’ the data determines how
much security is required.
What are implications of changed/destroyed data?
If losing a piece of data has disastrous consequences then the
security must be higher. For example, if a sales person builds
up a customer list over many years then losing the list to a
competitor could be very costly.
Will security measures affect the proper functioning of the database?
If security stops legitimate individuals from accessing the
data, then it may not be suitable.

Database-Independent Security Mechanisms
• Usernames and passwords

• Physically secure hardware
• Data encryption
• Hardware/User profiles
– e.g. login times, CPU usage
• Program security
• Audit Trails
11
Database-independent security mechanisms can be applied to any database

system:
• Operating systems use usernames and passwords to control
access. A DBMS also uses usernames and passwords to restrict
access to the data. This is an unreliable method of controlling
systems.
• Hardware can be physically secured (to avoid damage to the
machine) by placing it in a secure room. A machine which is
attached to a network may be insecure because access can be
gained across the network.
• Data encryption is often used when information is transmitted
across a network. A DBMS can also encode the data so that it is
unreadable without accessing it through a query language. This
stops users accessing the data by reading the data files and,
therefore, by-passing the DBMS security measures.
• Profiles describe different categories of user who have the same
privileges. For example, all project leaders may have access to
project data during working hours.
• In a client/server environment it is not sufficient to secure the
client without securing the database. The clients can provide a
first level of security but should not be the only means of
securing the system.
• Audit trails provide a complete history of all interactions with
the database including who accessed the system, what was
accessed, when it was accessed, etc.

Database-Dependent Security Mechanisms
• Controlling access
– Users and roles
• Username/password
• Groups
– Schemas
• Set of tables, etc. owned by a user
• Controlling behaviour
– Privileges
• Rights to access the DBMS
• Controlling integrity
– Integrity constraints 12
• Declaring primary keys, etc.

Database-dependent security mechanisms refer to security features provided
by specific database management systems. There are three parts to database
specific security measures:
• Controlling access to the database
• Most database systems provide a method of setting up users.
By allocating to each person who accesses the system a user
name the database administrator can monitor who is accessing
the system.
• Oracle allows groups of users to have one or more roles. A
role provides a group of users with a set of privileges which are
required by someone with the allocated role. For example, all
BBIT2 students have the role ‘BBITers’ and have permission
to create simple tables.
• Schemas are sets of tables which belong to particular users.
Each user can only see their own schema, or set of tables. A
user may give permission to another user to view or change
their schema.
• Controlling behaviour while connected to the database
• The behaviour of each user who is connected to the database
can be controlled by allocating or removing the privileges
owned by a user.
• Controlling integrity of data in the database
• Integrity constraints impose limits on the type of data which
may be entered into the DBMS. For example, by declaring a
primary key a user requires that a set of data has a unique
identifier.

Controlling Access
• Discretionary Access Control
– Users
• A name that can connect and access objects in the
database
• Users log in using a name (and password)
– Schema
• A collection of objects associated with a user
– e.g. tables, views, indexes, procedures, etc.
• Access to a schema is granted at the discretion of the user
• Many databases, including Oracle, use discretionary access control to

manage the security of the database. Users of the database can grant
permission to use database objects to other users. Each user has the
discretionary to allow other users to use their data.
• The two main methods of implementing discretionary access control in
the database are:
• Users Users are names that the database recognises as being
allowed to access the database. A user logs into the database by
giving the DBMS a valid username. Users are often required to
also provide a password. Once the DBMS knows the name of the
user they can then allow that user to access the data.
• Schema The schema is a set of database objects that have been
created in the database. Each user can have one or more schemas.

Controlling Behaviour
• Privileges
– “the right to execute a particular SQL statement or
to access another user’s object”
• Oracle Concepts Manual
• Types
– Connecting to the DBMS
– Creating objects
• Tables, views, etc.
– Accessing/changing data
– Executing procedures
• We can give users the right to access data in the database by allocating
privileges to the user. There are many different types of privileges that
can be given to a user. For example, most users must be given the
privilege to connect to the database and to create tables in the database.

Privileges - SQL
• GRANT command
– Provides privileges to access data
– Format
GRANT {SELECT, INSERT, UPDATE, DELETE}
ON tablename TO username
– Example
• Grant privileges to Smith to select or insert in dept
GRANT SELECT, INSERT

ON dept TO smith
15
The main two commands in SQL for implementing security restrictions on a

database are the GRANT and REVOKE commands.
The GRANT command gives permissions to users to access and change data.
• A user may be given permission to select from, insert to, delete
from or update a table.
Other forms of the GRANT command allow a user to create tables or views.

Privileges - SQL
• REVOKE command
– Removes privileges to access a table
– Format
REVOKE {SELECT, INSERT, UPDATE, DELETE}
ON tablename FROM username
– Example
• Remove privileges from Smith to insert or delete from emp
REVOKE INSERT, DELETE

ON emp FROM smith
16
The REVOKE command removes permissions from users to access and

change data.

Managing Privileges
• Problem
– Large numbers of users
• Each with many privileges
– Cannot add privileges to every individual
• Roles
– Named groups of related privileges that are granted
to users
– Allocate roles to users
• Example
– role BBIT2A allows users to create tables, add data
– role BBIT4A allows users to create create procedures
• If there are many users of the database it can become impractical to

allocate privileges to individual users. Instead, we can create roles that
contain groups of privileges. We can then allocate the roles the individual
users.
• A role might allow a user to query and modify data in tables but not to
create new tables. We give this role a name, for example,
UPDATE_USER, and allocate the role to each user that should be able to
query and modify data but not create new tables.
• If we change the privileges allocated to a role then the privileges of all the
users who have the specified role also change.

Roles

Controlling Integrity
• Integrity Constraints
– Keys
– Value checks
• e.g. salary < 50000
• Declaring Primary/Foreign Keys
CREATE TABLE employee ( empno NUMBER,
ename CHAR(20),
salary NUMBER,
deptno NUMBER
PRIMARY KEY ( empno )
FOREIGN KEY ( deptno ) REFERENCES department
);
19
• In Oracle one of the major constraints we can declare are primary keys
and foreign keys.
• The primary key declaration requires that each tuple in a relation is
uniquely identifiable by the declared primary key. That is, all rows in the
table must have a unique primary key. Oracle enforces this constraint and
will produce an error if an attempt is made to add a record with a primary
key value which already exists.
• The foreign key declaration requires that each value of the foreign key
attribute must exist in the primary key of another table. In the above
example, employees can only belong to departments which already exist
in the department table.

Changing the Appearance of the Database

• Why?
– Hide data
– Simplify the structure
• Normalised databases can be difficult to understand
– Hide the location of data
• Physical independence
• Methods
– Views
– Synonyms
20
• Often we wish to hide information from certain users or to make the

database easier to use. If a database has a very complex structure then we
may wish to make the database simpler to use for certain users.
• In the three-schema architecture external schemas are created to provide
each user group with a view of the database.
• There are many methods available to do this but the most important is the
view and synonym.

Views
• Create a table that is derived from another table
– Views do not exist
– Database executes a query when a view is accessed
• Why?
– Restrict the rows that are visible
– Reduce the number of columns
– Simplify the database
• Create calculated fields
• Hide complex joins
– Simplify complete queries
21
• A view is a table which is created by executing a query on the database.

A view may be used in place of a normal table.
• For example, a view dept30 (above) may limit the employee table to all
employees in department 30. Any query which accesses the view dept30
will only see employees in department 30.
• A view can be used to restrict the information which a set of users can
access. For example, if a company requires that employees may only see
data about their own department then it can set up the view dept30 and
restrict all direct access to the employee table.
• The DBMS does not store any data when a view is created but simply
stores the query which creates the view. This information is stored in the
data dictionary.
• When a user queries a view, the DBMS executes the view’s query and
then executes the user’s query upon the result of the view.

Views - Example
CREATE VIEW staff (empno, ename, job, mgr, deptno)
AS
SELECT empno, ename, job, mgr, deptno FROM emp;

Synonyms
• An alias for a table or view
– Give the table or view another name
• Use
– Hide the owner of the table
• Users do not have to know who owns the data
– Hide the location of the data
• Allows data to be physically moved
• Synonyms are aliases that can be used to give a new name to a table in the
database.
• It is common for data in a database to be owned by many different users
and accessing the data may involve remembering all the user’s names.
Synonyms allow us to give tables simple names so that we do not have to
remember where the data is stored.
• Synonyms also help to provide physical independence because they can
be used to hide where the data is actually stored.

Synonyms - Example
• Table emp is owned by scott
– Should query it as:
• SELECT * FROM scott.emp;
– If emp was stored in another database:
• SELECT * FROM scott.emp@anotherdatabase.com;
• Hiding owner/location of emp
– Create a public synonym
• CREATE PUBLIC SYNONYM emp
FOR scott.emp@anotherdatabase.com;
– Query synonym
• SELECT * FROM emp;
• Tables that are belong to another user or are stored in another location
(database) can be made easier to access by creating synonyms that give
the table a simpler name.
• In the above example, the synonym emp actually points to the table
scott.emp but we can simply use the name emp. If we move the data to
another user then we only need to change the synonym and not all the
queries that access the table.

Security Example - Scenario

• Tables
– transactions( tid, tdate, custid, amount, traderid )
• Assume the system has two types of user:
– Traders
• Access own transactions but not others
• Access total transactions for all customers
– Managers
• All transactions for traders they manage

Security Example - Users

• Create a database user for each user
CREATE USER trader1 IDENTIFIED BY password1;
….
CREATE USER manager1 IDENTIFIED BY
password4;
CREATE USER manager2 IDENTIFIED BY
password5;
• Create a database user to store the data
– CREATE USER traderdata IDENTIFIED BY p6;

Security Example - Roles

• Create a role for each type of user
– CREATE ROLE trader_role;
– CREATE ROLE manager_role;
• Assign roles to users
– GRANT trader_role to trader1;
– GRANT trader_role to trader2;
– ….
– GRANT manager_role to manager1;
– GRANT manager_role to manager2;

Security Example - Views

• “Traders can access their own transactions”
– Create a table containing traderid and username
traders( traderid, username )
– Create a view restricting transactions
CREATE VIEW trader_transactions
AS
SELECT * FROM transactions, traders
WHERE transactions.traderid = traders.traderid
AND username = USER
WITH CHECK OPTION
– USER is a special variable = user name


• “Traders can access total transactions”
– Create a view totalling all transactions
CREATE VIEW total_transactions
AS
SELECT custid, SUM(amount) FROM transactions
GROUP BY custid


• “Managers can view their trader’s transactions”
– Create a table containing managerid and traderid
and manager’s username
managing( managerid, username, traderid )
– Create a view restricting transactions
CREATE VIEW manager_transactions
AS
SELECT * FROM transactions, managing
WHERE transactions.traderid = managing.traderid
AND username = USER
WITH CHECK OPTION

Security Examples - Synonyms

• Create synonyms for views
CREATE PUBLIC SYNONYM total_transactions

FOR tradedata.total_transactions;
CREATE PUBLIC SYNONYM trader_transactions

FOR traderdata.trader_transactions;

Security Example - Privileges

• Grant privileges to roles
– Traders can query total transactions
GRANT SELECT
ON total_transactions
TO trader_role;
– Traders can update their transactions
GRANT SELECT, INSERT, DELETE, UPDATE
ON trader_transactions
TO trader_role;

Data Protection Act

• “The Act gives rights to individuals about
whom information is recorded on computer.”
• “They may find out information about
themselves, challenge it if appropriate and
claim compensation in certain circumstances.”
• Users of personal data must be:
– Open about the use made of data
– Follow sound and proper practices
33

Data Protection Principles

• Personal data shall:
– be obtained and processed fairly and lawfully
– be held only for lawful purposes described in register
– be used/disclosed for those purposes
– be adequate, relevant and not excessive in relation to the
purpose
– be accurate and kept up to date
– be held no longer than necessary
– be secure
34

Exemptions
• Personal data held by an individual for personal,
family or recreational purposes
• Personal data held for calculating wages, pensions,
accounts, orders.
• Personal data used for distributing information (eg
name and address).
– Must ask individual if they object.
• Personal data held by unincorporated members club
• Personal data required by law to be public
• Personal data required by national security
35

Data Protection Register

• All personal data must be registered.
• Content
– Data user’s name and address
– The personal data that is held
– The purposes for which the data is held
– The sources for the data
– The people to whom data may be supplied
– Overseas countries to which the data may be transferred
• Criminal offense to not comply
36

Rights of the Individual

• Compensation
– due to loss, unauthorised destruction, unauthorised
disclosure of personal data
• Correction or deletion
• Subject access
– entitled to access for a fee
– may not always apply (e.g. criminal records)
37

Rights of Disclosure
• The Act does not stop disclosure of
personal data.
– Disclosures must be registered
– But individuals cannot stop disclosure
38

References
• Database Security
– “A Tutorial on Secure Database
Systems”, Pangalos
• Data Protection Act
– http://www.open.gov.uk/dpr/guide.htm
39

Database Security

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Database Security

Caricato da

Copyright:

Formati disponibili

BBIT2 Database Systems 2

Fundamentals of Database Systems

The Cuckoo’s Egg

© Stephen Mc Kearney, 2001. 1

© Stephen Mc Kearney, 2001. 2

© Stephen Mc Kearney, 2001. 3

Reasons for Security

© Stephen Mc Kearney, 2001. 4

© Stephen Mc Kearney, 2001. 5

© Stephen Mc Kearney, 2001. 6

Effective Security - Assumptions

© Stephen Mc Kearney, 2001. 7

© Stephen Mc Kearney, 2001. 8

Security constraints in a database are concerned with controlling and

© Stephen Mc Kearney, 2001. 9

© Stephen Mc Kearney, 2001. 10

Database-Independent Security Mechanisms

• Usernames and passwords

Database-independent security mechanisms can be applied to any database

© Stephen Mc Kearney, 2001. 11

Database-Dependent Security Mechanisms

• Declaring primary keys, etc.

© Stephen Mc Kearney, 2001. 12

• Many databases, including Oracle, use discretionary access control to

© Stephen Mc Kearney, 2001. 13

© Stephen Mc Kearney, 2001. 14

GRANT SELECT, INSERT

The main two commands in SQL for implementing security restrictions on a

© Stephen Mc Kearney, 2001. 15

REVOKE INSERT, DELETE

The REVOKE command removes permissions from users to access and

© Stephen Mc Kearney, 2001. 16

• If there are many users of the database it can become impractical to

© Stephen Mc Kearney, 2001. 17

© Stephen Mc Kearney, 2001. 18

© Stephen Mc Kearney, 2001. 19

Changing the Appearance of the Database

• Often we wish to hide information from certain users or to make the

© Stephen Mc Kearney, 2001. 20

• A view is a table which is created by executing a query on the database.

© Stephen Mc Kearney, 2001. 21

© Stephen Mc Kearney, 2001. 22

© Stephen Mc Kearney, 2001. 23

© Stephen Mc Kearney, 2001. 24

Security Example - Scenario

© Stephen Mc Kearney, 2001. 25

Security Example - Users

© Stephen Mc Kearney, 2001. 26

Security Example - Roles

© Stephen Mc Kearney, 2001. 27

Security Example - Views

© Stephen Mc Kearney, 2001. 28

Security Example - Views

© Stephen Mc Kearney, 2001. 29

Security Example - Views

© Stephen Mc Kearney, 2001. 30

Security Examples - Synonyms

CREATE PUBLIC SYNONYM total_transactions

CREATE PUBLIC SYNONYM trader_transactions

© Stephen Mc Kearney, 2001. 31

Security Example - Privileges

© Stephen Mc Kearney, 2001. 32

Data Protection Act