Advanced DBMS: CISY 423

Department of Computer Information Systems

KEMU

Database Security

OBJECTIVES

• Security and • Database Users • Creating Users/Accounts in commercial DBMS • Discretionary Access Control o Subject-Based Security o Object-Based Security • Mandatory Access Control • The SQL GRANT and REVOKE Statements • Security under Shared MS Access

Database Security and Authorization

• Three very broad issues in DB security: 1. Legal and Ethical considerations - Who has the right to read What information ? 2. Policy issues - Who should enforce security (government, corporations) ? 3. System-Level issues - Where should security be enforced in the system and How ? • As database practitioners, we must provide a means of preventing unauthorized use of data in a database. Three areas are considered: 1. Access Control: Who should be allowed access to which databases. This is typically enforced using system level accounts with passwords. 2. We will investigate: 1. Discretionary Access Control 2. Mandatory Access Control 3. Authorization: for the purposes of: Reading Data - Such as reading another employee's salary (using a SELECT statement for example). Writing Data - Such as changing a value in a database (using UPDATE or DELETE). 4. Statistical Information: Enforcing who should be allowed access to information derived from underlying databases (Census example). • Here we will focus on the Authorization and Access control aspects.

Database Users

• Most commercial DBMS include a security subsystem that manages access to schemas and their contents • There is a notion of a user that possesses some authority to access and manipulate schema objects. • A special user called the System Manager, System Administrator or (DBA) possesses the authority to perform any operations on any object.

DBMS DBA user Oracle SYSTEM Sybase sa MS SQL-Server sa DB2 db2admin or db2inst (the instance owner)

• This is similar to the superuser in an operating system ( root in UNIX or administrator in Windows NT/2000) • Responsibilities of the DBA include: o Creating accounts (adding users) o Granting and revoking privileges o Assigning security clearance levels (in MAC) • Before a user can access database objects, they must be authenticated in the DBMS. • Typically, this involves supplying a valid user name and password to the DBMS. All account information is stored within the DBMS • Another option is using an operating system level login to authenticate a user to the DBMS. e.g., if you have been authenticated by the OS on the server, then you are OK to use the DBMS. • A third option is to use a distributed mechanism such as Kerberos or some form of Directory Services (e.g., Novell or LDAP) to provide a "single login" for all network, OS and DBMS services. • Once a user has been authenticated to the DBMS, a log-in session is established. The session remains in effect until it is terminated by the user or by some kind of failure (DBMS, server, network, client) • All major DBMS allow auditing of log-in sessions (date/time, username, client info (IP address, application, etc.)) Creating Users/Accounts in commercial DBMS

1. MS SQL Server o Can use the operating system (NT) to authenticate o Add users with the sp_addlogin procedure o sp_addlogin @loginame= 'newlogin', o @passwd= 'newpassword', o @defdb= 'database', o @deflanguage= 'language', o @sid= 'sid', o @encryptopt= 'encryption_option' Where @defdb is the default database to be used, @deflanguage is the default language character set to use, @sid is a unique system identifier (auto generated if not given) and @encryptopt is an option to encrypt the password before it is stored in the system tables.

2. SQL Server Provides a nice graphical user interface (Enterprise Manager) to create users among other things:

3. Oracle o In Oracle, the CREATE USER statement can be used to create new users: o CREATE USER newuser o IDENTIFIED BY newpassword o DEFAULT TABLESPACE tablespace o TEMPORARY TABLESPACE temptablespace o QUOTA xM on tablespace;

Where tablespace is an existing tablespace in the DBMS, temptablespace is an existing temporary tablespace in the DBMS, and x is some number of megabytes of quota to allocate to the user. o After the user is created, CONNECT and CREATE SESSION privileges must be granted: o GRANT CONNECT, CREATE SESSION TO newuser;

o To remove a user, the DROP USER statement can be employed. o If the user has tables or other objects in their schema, the DROP USER username CASCADE statement can be employed.

Oracle also provides a graphical user interface to create users (part of the Oracle Enterprise Manager):

Discretionary Access Control

• Typically security for database authorization purposes is implemented in an authorization subsystem that monitors every transaction in the database. This is part of the DBMS. • Authorization rules take into account a few main ideas: 1. Subjects: Individuals who perform some activity on the database. Might include specific people (e.g., user tanondo on cis.kemu.edu) or a group of users (faculty on cisnet). 2. Objects: Database units that require authorization in order to manipulate. Database units might include an entire , specific columns in a table, specific rows in a table, etc. 3. Actions: Any action that might be performed on an object by a subject. For example: Read, Modify, Insert, Write, Delete, Grant (the ability to grant to others) 4. Constraint: A more specific rule regarding an aspect of the object and action. • These elements are commonly combined into an authorization table

Subject Object Action Constraint Ed Employee Read None Ed Employee Insert None Ed Employee Modify None Ed Employee Grant None Bill Employee Read Salary < 50,000 Sally PurchaseOrder Insert Total < 1,000 Sally PurchaseOrder Modify Total < 1,000 PayrollClerks Employee Read None

• What happens as the number of subjects and objects grows ? • Presently, no commercial DBMS supports this level of authorization flexibility. • A DBMS supports some basic authorization models. Application developers must provide more complex constraint enforcement.

Subject-Based Security

• Subjects are individually defined in the DBMS and each object and action is specified. • For example, user SMITH (a Subject) has the following authorizations:

Objects

Actions EMPLOYEES ORDERS PRODUCTS ... Read Y Y Y ... Insert N Y N ... Modify N Y Y ... Delete N N N ... Grant N N N ...

Object-Based Security

• Objects are individually defined in the DBMS and each subject and action is specified. • For example, the EMPLOYEES table (an Object) has the following authorizations:

Subjects

Actions SMITH JONES GREEN DBA ... Read Y Y N Y ... Insert N N N Y ... Modify N N N Y ... Delete N N N Y ... Grant N N N Y ...

Mandatory Access Control

• Used in government and other high-security environments. • Also called: Multilevel security (MLS) • Objects are given a security class or level. For example: o Top-Secret o Secret o Public • Subjects are given a security clearance: Top-secret, Secret, Public • Two main rules are enforced: 1. No subject can read an object at a higher level. e.g., a subject with Secret clearance may not read an object at Top-secret level. 2. No subject can write an object at a lower level (No write-down). e.g., a subject with top-secret clearance may not write a secret document. In a DBMS, an MLS can be implemented by classifying every column, table, etc. and then supplying clearances to each user. For example: Trusted Oracle Be aware of covert channels . For example: o Salaries of employees making more than $50,000 are secret o Salaries of others are public o A user with public clearance poses a query to the database. Any records that do not appear indicate employees who make more than $50,000.

The SQL GRANT and REVOKE Statements

• SQL provides two main statements for setting up authorization. • GRANT is used to grant an action on an object to a subject . • GRANT action1, action2 ... • ON object1, object2, ... • TO subject1, subject2 ... • • Another option of the GRANT statement is WITH GRANT OPTION. This allows the grantee to propagate the authorization to another subject. • For example, assume we have a database with Tables: employees, departments, orders, products Users: smith, jones, green, dba • GRANT INSERT, DELETE, UPDATE, SELECT • ON employees, departments • TO smith ; • • GRANT INSERT, SELECT ON orders TO smith ; • • GRANT SELECT ON products TO smith ; • • • GRANT SELECT • ON employees, departments • TO jones ; • • • GRANT INSERT, DELETE, UPDATE, SELECT • ON employees, departments, orders, products • TO dba • WITH GRANT OPTION ; • Grants can also be done on specific columns in a table: • GRANT SELECT ON products TO jones ; • • GRANT UPDATE ON products (price) TO jones ; • If no GRANT statement is issued, it is assumed that no authorization is given (e.g., user GREEN above). • REVOKE is used to revoke authorizations from subjects. • REVOKE action1, action2, ... • ON object1, object2, ... • FROM subject1, subject2, ... • If Ms. Smith leaves the company, then we should: • REVOKE INSERT, DELETE, UPDATE, SELECT • ON employees, departments • FROM smith ; • • REVOKE INSERT, SELECT ON orders FROM smith ; • • REVOKE SELECT ON products FROM smith ; • Many RDBMS have an ALL PRIVILEGES option that will revoke all of the privileges on an object from a subject: • REVOKE ALL PRIVILEGES • ON employees, departments, orders, products • FROM smith ; • Note: Oracle only supports granting a set of privileges/actions on one object to one subject within a single statement. • GRANT action1, action2 ... • ON object • TO subject ; • • We can group users into ROLES or GROUPS and grant or revoke privileges from the collection. • In Oracle we can do something like: • CREATE ROLE purchasing_clerks; • GRANT SELECT ON vendors TO purchasing_clerks; • GRANT SELECT, INSERT, UPDATE, DELETE • ON purchase_orders • TO purchasing_clerks; • GRANT SELECT, INSERT, UPDATE, DELETE • ON po_items • TO purchasing_clerks; • • GRANT purchasing_clerks TO smith; • GRANT purchasing_clerks TO jones; • GRANT purchasing_clerks TO green;

Security under Shared MS Access databases

Here is a comprehensive guide to how MS Access accomplishes this: http://support.microsoft.com/default.aspx?scid=/support/access/content/secfaq.asp