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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 9-7 Databases as tools of privacy abuse Why are databases so vulnerable for use as instruments of privacy abuse?

8. 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-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

10. 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

11. 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

12. 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 EMPLOYEE WHERE EMPLOYEE.Name = 'Benjamin Franklin' OR TRUE; –What’s the result here?

13. 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!

14. 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

15. 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!

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 9-26 DBMS Security Model

27. 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 user GRANT AdvisorRole to U999; –To assign a role to another role GRANT FacultyRole TO AdvisorRole; –Allows inheritance of role privileges

28. 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

29. 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

30. 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)

31. 9-31 Database Recovery In the event of system failure, the database must be restored to a usable state as soon as possible

32. 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