9-1 David M. Kroenke’s Chapter Nine: Managing Multiuser Databases Database Processing: Fundamentals, Design, and Implementation.

9-1

David M. Kroenke’s

Chapter Nine:Managing Multiuser Databases

Database Processing:Fundamentals, Design, and Implementation

9-2

Database Administration

• All databases need some form of database administration– Data administration refers to a function

concerning all of an organization’s data assets

– Database administration (DBA) refers to a person or office specific to a single database and its applications

9-3

DBA Tasks

• Managing database structure• Controlling concurrent processing• Developing database security

– Managing processing rights and responsibilities

• Providing for database recovery• Maintaining the DBMS• Maintaining the data repository

9-4

Managing Database Structure

• DBA’s tasks:– Participate in database and application development

• Assist in requirements stage and data model creation• Play an active role in database design and creation

– Facilitate changes to database structure• Seek community-wide solutions

– Assess impact on all users

• Maintenance• Maintain documentation

9-5

Concurrency Control

• This ensures that one user’s actions do not inappropriately affect another user’s work– No single concurrency control technique is ideal for all

circumstances– Trade-offs need to be made between level of

protection and throughput

• Resource locking prevents multiple users or applications from obtaining copies of the same record when that record is about to be changed

9-6

Privacy and Security

• Privacy– the right of individuals to have some control

over information about themselves– protected by law in many countries

• Security– protecting the database from unauthorized

access, modification, or destruction

• The right to privacy can be protected by good database security

9-7

Databases as tools of privacy abuse

• Why are databases so vulnerable for use as instruments of privacy abuse?

9-8

They’re used in ways they weren’t intended…

• Accidental uses

• Unauthorized uses– Accidental– Deliberate

• Unanticipated uses– What design practices facilitate unanticipated

uses of the database?

9-9

Accidental Security Threats

• User errors– User unintentionally requests object or operation for which

he/she should not be authorized

• Communications system errors– User sent a message that should be sent to another user – System connects a user to a session that belongs to another

user with different access privileges

• OS errors– Accidentally overwrites files and destroys part of database– Fetches the wrong files and sends them to the user– Fails to erase files that should be erased

9-10

Deliberate Security Threats

• User intentionally gains unauthorized access to data in the database – Disgruntled employee familiar with the

organization's computer system seeks revenge

– Industrial spies seek information for competitors

– Criminals exploit lax security practices

9-11

Deliberate Security Threats• Wiretapping/electronic eavesdropping • Reading unsupervised display screens or printouts• Impersonating authorized users • Writing programs to bypass the DBMS and access database

data directly• Writing applications programs to perform unauthorized

operations • Deriving information about hidden data by clever querying • Removing physical storage devices from the computer facility• Making copies of stored files without going through the DBMS• Bribing, blackmailing or influencing authorized users to obtain

information or damage the database

9-12

SQL Injection Attack

• This occurs when data from the user is used to modify a SQL statement

• User input can modify a SQL statement – It must be carefully edited to ensure that only valid

input has been received

• Ex: users prompted to enter their names into a form textbox– User input: Benjamin Franklin ' OR TRUE '

SELECT * FROM EMPLOYEEWHERE EMPLOYEE.Name = 'Benjamin Franklin' OR TRUE;

– What’s the result here?

9-13

Treatment of sensitive data

• Don’t collect if you don’t need it

• If you do need it…– Be proactive in your protection of privacy!

9-14

Don’t collect if you don’t need it

• How do you know it is sensitive?– Stakeholder analysis

• How do you know if you need it or not?– Review client specifications / ask the client

again (…and again)– Consider unanticipated uses enabled by the

data being collected

9-15

If you do need it…

• Identify sensitive attributes at the conceptual (ER) level

• Flag or mark sensitive attributes for future protection

• Consider privacy protection issues during the normalization process

• Test the accessibility of privacy-sensitive data during the query-testing phase

• Create views/encrypt/restrict or log access• Apply other privacy protections…• Be proactive in your protection of privacy!

– Have a security plan!

9-16

DBMS Security Guidelines - 1

• Run DBMS behind firewall; plan as if firewall has been breached

• Apply latest operating system and DBMS patches

• Use the least functionality possible– Support the fewest network protocols possible– Delete unnecessary or unused stored procedures– Disable default logins and guest users– Limit allowing users to log on to the DBMS interactively

• Protect the computer that runs the DBMS– Keep it physically secured behind locked doors – All users work remotely – Log all access to the room containing the DBMS computer

9-17

DBMS Security Guidelines - 2

• Manage accounts and passwords– Use a low privilege user account for the DBMS service– Protect database accounts with strong passwords– Monitor failed login attempts– Frequently check group and role memberships– Audit accounts with null passwords– Assign accounts the lowest privileges possible– Limit DBA account privileges

• Planning– Develop a security plan for preventing and detecting security

problems– Create procedures for security emergencies and practice them

9-18

Application Security

• Provide additional security code for application programs– Internet application security is often provided on the

Web server computer

• However, use the DBMS security features first– The closer the security enforcement is to the data, the

less chance there is for infiltration– DBMS security features are faster, cheaper, and

probably result in higher quality than homegrown ones

9-19

Security Plan

• Includes physical security measures for the building-physical barriers, control access, require badges, sign-in etc.

• Then more physical security for the computer facilities - e.g. locked door

• Additional security control for database

• Authentication

• Authorization

9-20

Authentication

• User authentication– verifying the identity of users

• Operating system uses – user profiles, user ids, passwords,

authentication procedures, badges, keys, physical characteristics of the user

• Additional authentication can be required to access the database– additional user ids, passwords

9-21

Authentication Issues

• Limitations of password security – users write them down– choose words that are easy to guess– share them

• Physical security– Can require users to insert badges or keys to log on to a

workstation– Voice, fingerprints, retina scans, or other biometric measures

• Series of questions– Takes longer but is more difficult to reproduce than password– Authentication can be required for workstation access and again

for database access– User may be required to produce an additional password to

access the database

9-22

Authorization

• Multiple user DBMS’s have security subsystems to provide for authorization– users are assigned rights to use particular

database objects

• Authorization rules – An authorization language allows the DBA

to write rules specifying the kind of access given users have to specified database objects

9-23

Security Mechanisms

• Views - simple method for access control• Security log - journal for storing records of

attempted security violations• Audit trail - records all access to the database -

requestor, operation performed, workstation used, time, data items and values involved

• Triggers can be used to set up an audit trail• Encryption of database data also protects it

9-24

Encryption

• Uses a system that consists of – Encryption algorithm that converts plaintext

into ciphertext through the use of an encrypting key

– Decryption algorithm uses decryption key reproduces plaintext from ciphertext

9-25

SQL Authorization Language

• GRANT statement used for authorization• REVOKE statement used de-authorization• Privileges can be given to

– users directly– a role (classification of users)

• The role is given to users

• System keeps track of authorizations using a grant diagram, or authorization graph

9-26

DBMS Security Model

9-27

Examples of Grant

• Granting privileges to a user U101:GRANT SELECT ON Student TO U101 WITH GRANT OPTION;

• Creating and granting privileges to a role

– Creating the role: CREATE ROLE AdvisorRole;

– Granting privileges to the role GRANT SELECT ON Student TO AdvisorRole;

– Assign a role to a userGRANT AdvisorRole to U999;

– To assign a role to another role• GRANT FacultyRole TO AdvisorRole;

– Allows inheritance of role privileges

9-28

Statistical Databases

• Support statistical analysis on populations– Used for data mining operations

• Data itself may contain facts about individuals, but is not meant to be retrieved on an individual basis

• Users are permitted to access statistical information - totals, counts, or averages - but not information about individuals

9-29

Statistical DB Security

• Requires special precautions so that users are not able to deduce data about individuals

• Even if all queries must involve count, sum or average, a user might get away with using WHERE clauses to narrow the population down to one individual – The system can refuse any query for which only one record

satisfies the predicate

• Can restrict queries– Require that the number of records satisfying the query is above

some threshold– Require that the number of records satisfying a pair of queries

simultaneously cannot exceed some limit– Can disallow sets of queries that repeatedly involve the same

records

9-30

Privacy impact study

• Once the database is deployed, whose privacy will be at risk?

• Analyze privacy/security mechanisms– Are they adequate?

• Full disclosure– Be honest & clear about

• which populations are most vulnerable• possible additional uses of the database (not in the

original plan)

9-31

Database Recovery

• In the event of system failure, the database must be restored to a usable state as soon as possible

9-32

Maintaining the DBMS

• DBA’s Responsibilities– Generate database application performance reports– Investigate user performance complaints– Assess need for changes in database structure or

application design– Modify database structure– Evaluate and implement new DBMS features– Tune the DBMS